WO2025248756A1 - 代行装置、電子通貨システム、代行処理方法、及びプログラム - Google Patents

代行装置、電子通貨システム、代行処理方法、及びプログラム

Info

Publication number
WO2025248756A1
WO2025248756A1 PCT/JP2024/020029 JP2024020029W WO2025248756A1 WO 2025248756 A1 WO2025248756 A1 WO 2025248756A1 JP 2024020029 W JP2024020029 W JP 2024020029W WO 2025248756 A1 WO2025248756 A1 WO 2025248756A1
Authority
WO
WIPO (PCT)
Prior art keywords
agent
remittance
currency
payment
money
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/020029
Other languages
English (en)
French (fr)
Inventor
皓羽 金城
哲矢 奥田
俊之 宮澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
NTT Inc USA
Original Assignee
Nippon Telegraph and Telephone Corp
NTT Inc USA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp, NTT Inc USA filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2024/020029 priority Critical patent/WO2025248756A1/ja
Publication of WO2025248756A1 publication Critical patent/WO2025248756A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof

Definitions

  • the present invention relates to the technical field of electronic currency systems.
  • Central bank digital currencies are being considered in various countries around the world, and the Bank of Japan has stated that digital currencies must meet the following characteristics (1) to (5). Digital currencies may also be called “electronic currencies.” (1) Universal access (2) Security (3) Robustness (4) Instant payment (5) Interoperability To meet the requirements of robustness and instant payment, the currency must be circulated through user-to-user payments (offline payments without a central server). Furthermore, because currency has the tendency to be traded between users multiple times (transferability), authentication of transaction and traceability of fraud are essential from a security perspective.
  • the present invention was made in consideration of the above points, and aims to provide technology in an electronic currency system that allows remittance senders to safely entrust payments to an agent.
  • an agent device used in an electronic currency system including a remittance device, an agent device, and a remittance receiving device, the agent device comprising: a storage unit for storing the transaction details agreed upon between the money receiving device and the money remittance device; and an agent processing unit that receives currency from the remittance device, verifies whether the payment amount in the currency is correct based on the transaction details, and determines whether to continue processing based on the verification result.
  • the disclosed technology provides a technology that allows remittance senders to safely entrust payments to an agent.
  • FIG. 1 is a diagram for explaining a conventional electronic currency system.
  • 1 is a diagram illustrating an example of the configuration of an electronic currency system according to an embodiment of the present invention.
  • FIG. 1 illustrates a payment procedure based on the basic protocol.
  • FIG. 1 is a diagram for explaining a problem.
  • 1 is a diagram for explaining an overview of a technique according to an embodiment of the present invention;
  • FIG. 10 is a diagram showing a processing sequence when agreeing on transaction details.
  • FIG. 10 is a diagram showing a processing sequence when making a payment.
  • FIG. 1 is a diagram for explaining an overview of a first embodiment.
  • FIG. 10 is a diagram for explaining an overview of a second embodiment.
  • FIG. 10 is a diagram for explaining an overview of a third embodiment.
  • FIG. 10 is a diagram illustrating a processing sequence when agreeing on transaction details in the first embodiment.
  • FIG. 10 is a diagram showing a processing sequence when making a payment in the first embodiment.
  • FIG. 10 is a diagram showing a processing sequence when agreeing on transaction details in the second embodiment.
  • FIG. 10 is a diagram showing a processing sequence when making a payment in the second embodiment.
  • FIG. 11 is a diagram showing a processing sequence when agreeing on transaction details in Example 3.
  • FIG. 11 is a diagram showing a processing sequence when making a payment in the third embodiment.
  • FIG. 2 illustrates an example of a functional configuration of an agent device.
  • FIG. 2 is a diagram illustrating an example of the functional configuration of a user device (remittance device, receipt device).
  • FIG. 2 illustrates an example of a hardware configuration of the apparatus.
  • FIG. 1 A conventional electronic currency system will be described based on the system shown in FIG. 1.
  • electronic currency may also be simply referred to as "currency.”
  • the currency is issued by a central bank, and the central bank is the zeroth holder of the currency (hereinafter referred to as "holder 0").
  • the i-th (i ⁇ 1) user of the currency e.g., a commercial bank, store, company, general consumer, etc.
  • user i is also the i-th holder of the currency (hereinafter also referred to as "holder i").
  • FIG. 1 shows the format of currency held by holder n+1.
  • message M0 When a currency is issued, the central bank generates a message M0 containing currency information and sends the message M0 and its corresponding signature ⁇ 0 to user 1.
  • message M0 contains currency information such as the currency ID and face value, and a verification key vk1 of user 1 who is the recipient of the remittance.
  • message M0 is also called a "token", etc.
  • message M i When currency is circulated, user i (i ⁇ 1) generates a message M i called additional information etc. and a corresponding signature ⁇ i , and sends it to the next user i+1 after adding (M i , ⁇ i ) to ((M 0 , ⁇ 0 ), (M 1 , ⁇ 1 ), ..., (M i - 1 , ⁇ i-1 )).
  • message M i includes the verification key vk i+ 1 of the next user i+1 to whom the currency is to be sent, the hash value H(M i-1 , ⁇ i-1 ) of the message M i-1 and signature ⁇ i-1 , etc.
  • each M i contains H(M i-1 , ⁇ i-1 ), it can be said that each M i represents transaction information up to now.
  • the verification key vk i (i ⁇ 0) is information for verifying (M i , ⁇ i ) and is public information.
  • FIG. 1 is a diagram showing an example of verification of the validity of electronic currency in conventional technology.
  • each (M i , ⁇ i ) included in ((M 0 , ⁇ 0 ), (M 1 , ⁇ 1 ), ..., ( M n , ⁇ n )) is verified using a verification key vk i to check for any fraudulent transactions (in other words, whether M i has been tampered with, etc.). Furthermore, if currency is issued or remitted in duplicate, it is also possible to identify the fraudulent user who issued or remitted the currency in duplicate.
  • FIG. 2 is a diagram showing an example of the configuration of an electronic currency system according to this embodiment.
  • the electronic currency system includes an issuing bank server 20 and multiple user devices 10.
  • the issuing bank server 20 and each user device 10 are connected via a network such as the Internet (whether wired or wireless). Note that only some of the user devices 10 may be able to communicate with the issuing bank server 20.
  • electronic currency may also be called electronic cash.
  • the issuing bank server 20 is one or more computers managed by the issuing bank that issues the currency.
  • the issuing bank server 20 issues the currency and accepts currency withdrawals.
  • the user device 10 is a computer used by a user of the currency.
  • a server computer a PC, a tablet terminal, a smartphone, etc. may be used as the user device 10.
  • a currency user is anyone (individual or organization) who sends or receives currency during the currency circulation process.
  • Examples of users include financial institutions other than the issuing bank (e.g., commercial banks), companies, stores, and general consumers.
  • Each user device 10 acts as either a remitter or a remitter depending on the transaction situation using the currency.
  • the remitter is the party that sends the currency
  • the remitter is the party that receives the currency.
  • Transfers include, for example, withdrawals from financial institutions other than the issuing bank (e.g., commercial banks), deposits to financial institutions, and payments in commercial transactions.
  • financial institutions other than the issuing bank (e.g., commercial banks)
  • deposits to financial institutions e.g., deposits to financial institutions, and payments in commercial transactions.
  • the user device 10 managed by the financial institution is the sender, and the user device 10 used by the person receiving the withdrawn currency is the recipient.
  • the user device 10 used by the person depositing currency at the financial institution is the sender
  • the user device 10 managed by the financial institution is the recipient.
  • the user device 10 used by the person making the payment is the sender
  • the user device 10 used by the person receiving the payment is the recipient.
  • the sender and recipient have a relative relationship.
  • a user device 10 used by a user of an electronic currency system can be the sender in one transaction and the recipient in another.
  • the user device 10 may also be an agent device. Details of agent devices will be described later.
  • the basic protocol for currency circulation (hereinafter referred to as the "basic protocol") conforms to "4. Protocol to be verified" in Non-Patent Document 1 and Non-Patent Document 2.
  • a public key and private key pair is issued to the issuing bank server 20 and each user device 10 in advance, and the issuing bank server 20 and each user device 10 store the public key and private key pair.
  • T0 currency at the time of issuance (immediately after issuance)
  • T0 includes d, v, y, pkUi, and S0.
  • id is the currency ID.
  • the currency ID is a value unique to each currency. Note that the currency ID may not be included.
  • v is the face value of the currency. The face value of the currency may be the smallest unit (for example, 1 yen) or may be different for each currency.
  • y is the year the currency was issued.
  • pkUi is the public key of the user to whom the currency is issued.
  • the issuer of the currency is, for example, a financial institution.
  • T0 may also include Ui, which is information about the issuer of the currency. If the issuer of the currency is a bank, Ui may be written as Bi.
  • S0 is an electronic signature (hereinafter simply referred to as "signature") using the private key of the issuing bank server 20 for the hash value of (id, v, y, pkUi).
  • the issued currency is transferred from the user device 10 acting as the sender to the user device 10 acting as the recipient in accordance with the transaction.
  • the basic protocol when a currency is transferred from the user device 10 of user i (referred to as “user device 10i") to the user device 10 of user i+1 (referred to as “user device 10i+1"), information including (pkUi+1, Si) (referred to as “additional information”) is added (recorded) to the currency by the user device 10i acting as the sender.
  • pkUi+1 is the public key of user device 10i+1, the recipient of the remittance.
  • Si is the signature of the hash value of (pkUi+1, T0, ..., Ti) using the private key of user i, the sender.
  • an electronic currency API for a payment agent or the like will be made public.
  • an agent makes an API public, and a user uses the API to make a payment request to the agent.
  • the agent makes a payment to the payee on behalf of the user.
  • an authorization protocol is required in which the agent takes responsibility for the payment.
  • conventional technologies do not provide such an authorization protocol. Therefore, conventional technologies have a problem in that a remitter cannot safely entrust a payment to an agent.
  • Fig. 5 shows elements added to Fig. 3 showing the basic protocol of the prior art.
  • the user devices 10 will be referred to by names according to their roles, such as remittance device, agent device, and remittance receiving device. They will also be given symbols such as Uj, Ua, and Uk. That is, they will be referred to as remittance device Uj, agent device Ua, and remittance receiving device Uk. They may also be referred to as remitter (Uj), agent (Ua), and remittance receiver (Uk).
  • a remittance device Uj e.g., a user device of a consumer
  • an agent device Ua e.g., a user device of a service/application provider
  • a remittance device Uk e.g., a user device of a store
  • the proxy device Ua and the money receiving device Uk share their public keys (pkUa/pkUk) in advance.
  • step 101 the deposit device Uk sends a payment request (amount X yen) to the agent device Ua.
  • the agent device Ua sends a payment request (Uk: X yen) to the remittance device Uj, indicating that the remittance device Uk has requested a payment of X yen.
  • the remittance device Uj receives the payment request (Uk: X yen).
  • the remitter has agreed to the transaction details.
  • the decision as to whether to agree to the transaction details may be made by a person (the remitter) or automatically by the remittance device Uj.
  • the remittance device Uj sends a payment details agreement notification to the agent device Ua.
  • the agent device Ua sends a payment details agreement notification to the remittance device Uk.
  • the agent device Ua stores the transaction details in a storage unit (memory unit).
  • the transaction details are information indicating, for example, that "the remitter (Uj) pays X yen to the recipient (Uk)."
  • the remittance device Uj sends currency T0 and certificate Auth(pkUj) to the agent device Ua.
  • the agent device Ua transmits the recipient's public key pkUk and the agent's public key pkUa to the remittance device Uj.
  • the remittance device Uj verifies the public key pkUk and the agent's public key pkUa, respectively, and confirms the legitimacy of the agent (billing destination) and the remittance recipient.
  • the remittance device Uj transmits Tn, ..., T1 to the agent device Ua.
  • the agent device Ua verifies Tn, ..., T1, and if the verification is successful, generates a signature ⁇ for the transaction content M using its own private key skUa.
  • the transaction content M is information indicating, for example, "The sender (Uj) pays X yen to the recipient (Uk)."
  • the agent device Ua transmits Tn, ..., T0, M, and ⁇ to the money receiving device Uk.
  • the money depositing device Uk verifies M and ⁇ .
  • the money depositing device Uk checks whether the agreed-upon transaction details and M are consistent (whether there are any discrepancies).
  • signature verification is performed using pkUa. Here, it is assumed that the verification is successful.
  • the money depositing device Uk can verify Tn, ..., T0 as needed.
  • the money depositing device Uk stores Tn, ..., T0.
  • the user's payments include a purchase price payment to Payee A and a fee payment to Payee B.
  • the user requests these payments from an agent.
  • the agent confirms the transaction details (confirms the total payment amount) and makes payments to Payee A and Payee B.
  • user A makes a payment to user B via an agent
  • user B makes a payment to user A via an agent
  • the agent e.g., a transaction manager
  • Example 1 Agreement on transaction details
  • Example 1 Agreement on transaction details
  • a remittance device Uj an agent device Ua
  • a deposit device Uk a payment destination device Uk1 and a payment destination device Uk2 are connected to the deposit device Uk, and payments are made to each of the payment destination device Uk1 and the payment destination device Uk2.
  • the payment destination device Uk1 and the payment destination device Uk2 each communicate with the agent device Ua via the deposit device Uk.
  • the "payment destination device” is an example of a "deposit device.”
  • the payment destination device Uk1 and the payment destination device Uk2 may each communicate with the agent device Ua without going through the money receiving device Uk.
  • the agent device Ua, the payment destination device Uk1, and the payment destination device Uk2 share their public keys (pkUa/pkUk1, pkUk2) in advance.
  • the deposit device Uk (payment destination device Uk1, payment destination device Uk2) sends a payment request (Uk1: X yen, Uk2: Y yen) to the agent device Ua.
  • the agent device Ua sends a payment request (Uk1: X yen, Uk2: Y yen) to the remittance device Uj, indicating that the payment destination device Uk1 has requested a payment of X yen, and the payment destination device Uk2 has requested a payment of Y yen.
  • the remittance device Uj receives the payment request (Uk1: X yen, Uk2: Y yen).
  • the remitter has agreed to the transaction details.
  • the remittance device Uj sends a payment details agreement notification to the agent device Ua.
  • the agent device Ua sends a payment details agreement notification to the remittance device Uk (payment destination device Uk1, payment destination device Uk2).
  • the agent device Ua stores the transaction details agreed upon as described above in the storage unit.
  • Example 1 Payment
  • the remittance device Uj sends currency T0 for the payment destination device Uk1, currency T'0 for the payment destination device Uk2, and certificate Auth(pkUj) to the agent device Ua.
  • the agent device Ua transmits the recipient's public keys pkUk1 and pkUk2 and the agent's public key pkUa to the remittance device Uj.
  • the remittance device Uj verifies each of pkUk1, pkUk2, and pkUa, and confirms the legitimacy of the agent (billing destination) and the payment destination.
  • the remittance device Uj transmits Tn, ..., T1, T'n, ..., T'1 to the agent device Ua.
  • the agent device Ua verifies Tn, ..., T1, T'n, ..., T'1, and if the verification is successful, generates a signature ⁇ for the transaction content M using its own private key skUa.
  • the transaction content M is information indicating, for example, "The remitter (Uj) pays X yen to the payee (Uk1) and Y yen to the payee (Uk2)."
  • the agent device Ua transmits Tn, ..., T0, T'n, ..., T'0, M, and ⁇ to the payment device Uk (payment destination device Uk1, payment destination device Uk2).
  • the payment destination device Uk1 and the payment destination device Uk2 each verify M and ⁇ .
  • the payment destination device Uk1 and the payment destination device Uk2 each check whether the agreed-upon transaction details and M are consistent (whether there are any discrepancies).
  • signature verification is performed using pkUa. Here, it is assumed that the verification is successful.
  • the payment destination device Uk1/payment destination device Uk2 Since verification of Tn, ..., T0 and T'n, ..., T'0 has already been performed by the agent device Ua, the payment destination device Uk1/payment destination device Uk2 only need to verify Tn, ..., T0/T'n, ..., T'0 as necessary.
  • the payment destination device Uk1 stores Tn, ..., T0, and the payment destination device Uk2 stores T'n, ..., T'0.
  • Example 2 Agreement on transaction details
  • the processing sequence for agreeing on transaction details in Example 2 will be described with reference to Fig. 13.
  • Fig. 13 there are a remittance device Uj, an agent device Ua, and a receivable device Uk.
  • consumer devices Uj1 and Uj2 are connected to the remittance device Uj, and consumer devices Uj1 and Uj2 each make payments. That is, consumer devices Uj1 and Uj2 each communicate with the agent device Ua via the remittance device Uj.
  • the "consumer device” is an example of a "remittance device.”
  • consumer device Uj1 and the consumer device Uj2 may each communicate with the agent device Ua without going through the remittance device Uj.
  • the proxy device Ua and the money receiving device Uk share their public keys (pkUa/pkUk) in advance.
  • the deposit device Uk sends a payment request (amount X yen) to the agent device Ua.
  • the agent device Ua sends a payment request (Uk: X yen) to the remittance device Uj (consumer device Uj1, consumer device Uj2) indicating that the payment request for X yen has been made by the remittance device Uk.
  • Consumer device Uj1 and consumer device Uj2 each receive the payment request (Uk: X yen).
  • each consumer agrees on the payment details and decides to split the bill. Specifically, consumer (Uj1) decides to pay T0 yen, and consumer (Uj2) decides to pay T'0 yen.
  • the remittance device Uj (consumer device Uj1, consumer device Uj2) sends a payment agreement and a request to split the bill (Uj1: T0 yen, Uj2: T'0 yen) to the agent device Ua.
  • the "payment agreement" here may include the agreement information of consumer device Uj1 and consumer device Uj2, or it may be a single agreement information that combines the agreement information of consumer device Uj1 and consumer device Uj2.
  • the agent device Ua stores the contents of the payment request received in S501 in a storage unit.
  • the agent device Ua sends a payment details agreement notification to the money receiving device Uk.
  • the agent device Ua stores the transaction details agreed upon as described above (consumer (Uj1) pays T0 yen, and consumer (Uj2) pays T'0 yen for X yen) in the storage unit.
  • the consumer device Uj1 sends currency T0 and certificate Auth(pkUj1) to the agent device Ua.
  • the consumer device Uj2 sends currency T'0 and certificate Auth(pkUj2) to the agent device Ua.
  • the agent device Ua confirms the payment amount. That is, for the consumer device Uj1, if T0 is not the notified split amount, the agent device Ua cancels the transaction, but if it is the notified split amount, the agent device Ua continues processing. Similarly, for the consumer device Uj2, if T'0 is not the notified split amount, the agent device Ua cancels the transaction, but if it is the notified split amount, the agent device Ua continues processing.
  • the agent device Ua transmits the payee's public key pkUk and the agent's public key pkUa to the consumer device Uj1. Similarly, the agent device Ua transmits the payee's public key pkUk and the agent's public key pkUa to the consumer device Uj2.
  • the consumer device Uj1 verifies the public key pkUk and the agent's public key pkUa, respectively, and confirms the legitimacy of the agent (billing destination) and the payee.
  • the consumer device Uj2 verifies the public key pkUk and the agent's public key pkUa, respectively, and confirms the legitimacy of the agent (billing destination) and the payee.
  • the consumer device Uj1 transmits Tn, ..., T1 to the proxy device Ua.
  • the consumer device Uj2 transmits T'n, ..., T'1 to the proxy device Ua.
  • the agent device Ua verifies Tn, ..., T1, T'n, ..., T'1, and if the verification is successful, generates a signature ⁇ for the transaction content M using its own private key skUa.
  • the transaction content M may be a combination of the transaction content between consumer (Uj1) and consumer (Uj2), or it may be divided into transaction content M1 of consumer (Uj1) and transaction content M2 of consumer (Uj2).
  • the transaction content M is a combination of the transaction content between consumer (Uj1) and consumer (Uj2).
  • the proxy device Ua transmits Tn, ..., T0, T'n, ..., T'0, M, and ⁇ to the money receiving device Uk.
  • the depositing device Uk verifies M and ⁇ .
  • verifying M it checks whether the agreed-upon transaction details and M are consistent (whether there are any discrepancies).
  • ⁇ it performs signature verification using pkUa. Here, it is assumed that the verification is successful.
  • the money depositing device Uk can verify Tn, ..., T0, T'n, ..., T'0 as needed.
  • the money depositing device Uk stores Tn, ..., T0, T'n, ..., T'0.
  • Example 3 Agreement on transaction details
  • remittance device Uj1 and remittance device Uj2 are each capable of receiving payments.
  • remittance device Uj1 makes a payment request of X1 yen to remittance device Uj2 via agent device Ua, and the transaction details are agreed upon.
  • remittance device Uj2 makes a payment request of X2 yen to remittance device Uj1 via agent device Ua, and the transaction details are agreed upon.
  • the agent device Ua monitors and records the transaction (S703). For example, in the case of the above transaction, the agent device Ua records the agreed-upon transaction details: "X1 will be paid from remittance device Uj1 to remittance device Uj2, and X2 will be paid from remittance device Uj2 to remittance device Uj1.”
  • the agent device Ua determines the balance of the transaction. In the above example, the agent device Ua calculates the balance of Uj1 as "X2 - X1" and the balance of Uj2 as "X1 - X2.” The agent device Ua notifies the balance values to both remittance device Uj1 and remittance device Uj2.
  • the balance of remittance device Uj1 is "-X yen," and the balance of remittance device Uj2 is "+X yen.”
  • the balance of remittance device Uj1 is "-X yen”
  • the balance of remittance device Uj2 is "+X yen.”
  • Example 3 Payment
  • Figure 16 shows the case where X yen is paid from remittance device Uj1 to remittance device Uj2 as described above.
  • a financial institution device 30 is used.
  • the remittance device Uj1 sends currency T0 and certificate Auth(pkUj1) to the agent device Ua.
  • the agent device Ua sends the public key pkUj2 of the remittance device Uj2 (recipient) and the agent's public key pkUa to the remittance device Uj1.
  • the remittance device Uj1 verifies the public key pkUj2 and the agent's public key pkUa, respectively, and confirms the legitimacy of the agent (billing destination) and the remittance recipient.
  • the remittance device Uj1 transmits Tn, ..., T1 to the agent device Ua.
  • the agent device Ua verifies Tn, ..., T1, and if the verification is successful, generates a signature ⁇ for the transaction content M using its own private key skUa.
  • the transaction content M is information indicating, for example, content such as "remitter (Uj1) pays X yen to remitter (Uj2)."
  • the transaction content M may include multiple transaction contents that ultimately indicate "remitter (Uj1) pays X yen to remitter (Uj2)."
  • the agent device Ua sends M and ⁇ to the financial institution device 30.
  • the financial institution device 30 verifies M and ⁇ and stores the transaction details M.
  • the agent device Ua transmits Tn, ..., T0, M, and ⁇ to the remittance device Uj2.
  • the remittance device Uj2 verifies M and ⁇ .
  • the remittance device Uj2 checks whether the agreed-upon transaction details and M are consistent (whether there are any discrepancies).
  • signature verification is performed using pkUa. Here, it is assumed that the verification is successful.
  • the remittance device Uj2 can verify Tn, ..., T0 as necessary.
  • the remittance device Uj2 stores Tn, ..., T0.
  • Fig. 17 shows an example of the functional configuration of the agent device Ua described above.
  • the agent device Ua has an agent processing unit 110 and a storage unit 120.
  • the agent processing unit 110 includes an agreement processing unit 111 and a payment processing unit 112.
  • the agreement processing unit 111 executes processing related to the agreement on the transaction details described in the basic example and the examples.
  • the payment processing unit 112 executes processing related to the payment described in the basic example and the examples.
  • the storage unit 110 stores the transaction details, etc. processed by the proxy processing unit 110.
  • Figure 18 shows an example of the functional configuration of a user device 10 that can function as both a remittance device and a remittance receiving device.
  • the user device 10 has an agreement processing unit 210, a remittance processing unit 220, a remittance processing unit 230, and a storage unit 240.
  • the agreement processing unit 210 executes processing related to the agreement on transaction details as described in the basic example and the examples.
  • the remittance processing unit 220 executes processing related to remittance as described in the basic example and the examples.
  • the deposit processing unit 230 executes processing related to deposits as described in the basic example and the examples.
  • the storage unit 240 stores information used in the processing of the agreement processing unit 210, remittance processing unit 220, and deposit processing unit 230.
  • any of the devices described in this embodiment can be realized by, for example, running a program on a computer.
  • This computer may be a physical computer or a virtual machine on the cloud.
  • the device can be realized by using hardware resources such as the CPU and memory built into the computer to execute a program corresponding to the processing performed by the device.
  • the program can be recorded on a computer-readable recording medium (such as portable memory) and then saved or distributed.
  • the program can also be provided via a network such as the Internet or email.
  • FIG. 19 is a diagram showing an example of the hardware configuration of the computer.
  • the computer in FIG. 19 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B.
  • the computer may also be equipped with a GPU.
  • the program that realizes processing on the computer is provided by a recording medium 1001, such as a CD-ROM or memory card.
  • a recording medium 1001 such as a CD-ROM or memory card.
  • the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000.
  • the program does not necessarily have to be installed from the recording medium 1001; it can also be downloaded from another computer via a network.
  • the auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.
  • the memory device 1003 When an instruction to start a program is received, the memory device 1003 reads and stores the program from the auxiliary storage device 1002.
  • the CPU 1004 implements the functions related to the device in accordance with the program stored in the memory device 1003.
  • the interface device 1005 is used as an interface for connecting to a network, etc.
  • the display device 1006 displays a GUI (Graphical User Interface) based on the program, etc.
  • the input device 1007 is composed of a keyboard, mouse, buttons, touch panel, etc., and is used to input various operational instructions.
  • the output device 1008 outputs the results of calculations.
  • An agent device used in an electronic currency system including a remittance device, an agent device, and a remittance receiving device, a storage unit for storing the transaction details agreed upon between the money receiving device and the money remittance device; an agent processing unit that receives currency from the remittance device, confirms whether the payment amount in the currency is correct based on the transaction details, and determines whether to continue processing based on the confirmation result.
  • the agent device according to claim 1 wherein the agent processing unit, when continuing the processing, transmits the public key of the remittance device and the public key of the agent device to the remittance device.
  • agent processing unit verifies the currency, generates a signature for the transaction details, and transmits the transaction details and the signature to the depositing device.
  • agent processing unit verifies whether the total of payment amounts in a plurality of currencies received from a plurality of remittance devices is correct.
  • agent processing unit verifies whether the payment amount in the currency received from the remittance device is correct based on the balance determined in multiple transactions between the remittance device and the remittance receiving device.
  • An electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, the money receiving device and the money remitting device agree on a transaction via the agent device;
  • the agent device stores the transaction details agreed upon between the money receiving device and the money remittance device in a storage unit, an agent device receives currency from the remittance device, confirms whether the payment amount in the currency is correct based on the transaction details, and determines whether to continue processing based on the confirmation result.
  • An agent processing method used in an electronic currency system including a remittance device, an agent device, and a remittance receiving device, the agent processing method being executed by the agent device, comprising: storing the transaction details agreed upon between the money receiving device and the money remittance device in a storage unit; an agency processing step of receiving currency from the remittance device, confirming whether the payment amount in the currency is correct based on the transaction details, and determining whether to continue the processing based on the confirmation result.
  • a non-transitory storage medium storing a program for causing a computer to function as each unit in the proxy device according to any one of appended claims 1 to 5.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置において、前記着金装置と前記送金装置との間で合意した取引内容を格納する格納部と、前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理部とを備える。

Description

代行装置、電子通貨システム、代行処理方法、及びプログラム
　本発明は、電子通貨システムの技術分野に関連するものである。
　中央銀行デジタル通貨（ＣＢＤＣ：Central Bank Digital Currency）の検討が世界各国で進んでおり、日本銀行ではデジタル通貨について、以下の（１）～（５）の特性を具備する必要があるとしている。なお、デジタル通貨は「電子通貨」等と呼ばれてもよい。
（１）ユニバーサルアクセス
（２）セキュリティ
（３）強靭性
（４）即時決済性
（５）相互運用性
　このうち、強靭性、即時決済性を満たすためには、ユーザ間での決済（中央サーバを仲介しない形／オフライン決済）で通貨を流通させる必要がある。更に、通貨はユーザ間で何度もやり取りされる性質（転々流通性）があるため、取引トランザクションの認証と不正のトレーサビリティはセキュリティの観点で必須である。
　オフラインでのデジタル通貨では改ざん検知が困難なため、不正検知のために署名を連鎖させ、預入の際に一括検証する方式が知られている。この時、従来の電子通貨送付プロトコルでは、送金者が着金者に対して直接に支払いを行うことを想定してる。
奥田, 他, "トークン型電子現金方式の形式検証手法に関する初期検討",研究報告電子化知的財産・社会基盤（EIP）, 2022-EIP-98, 24, pp.1-8, 2022/12/15 奥田, 他, "トークン型電子現金方式の二重使用検知およびプライバシーに関する形式検証の考察",研究報告コンピュータセキュリティ（CSEC）, 2023-CSEC-100, 66, pp.1-8, 2023/2/27
　電子通貨システムにおいて、支払い代行等のＡＰＩが公開されることが想定される。このような状況では、代行者が支払いの代行に責任をもつ承認プロトコルが必要となる。しかし、従来技術では、そのような承認プロトコルは提供されていない。従って、従来技術では、送金者が、代行者に安全に支払いを任せることができないという課題があった。
　本発明は上記の点に鑑みてなされたものであり、電子通貨システムにおいて、送金者が、代行者に安全に支払いを任せることを可能とする技術を提供することを目的とする。
　開示の技術によれば、送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置であって、
　前記着金装置と前記送金装置との間で合意した取引内容を格納する格納部と、
　前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理部と
　を備える代行装置が提供される。
　開示の技術によれば、送金者が、代行者に安全に支払いを任せることを可能とする技術が提供される。
従来技術における電子通貨の方式を説明するための図である。 本発明の実施の形態における電子通貨システムの構成例を示す図である。 基本プロトコルに基づく支払い手順を示す図である。 課題を説明するための図である。 本発明の実施の形態に係る技術の概要を説明するための図である。 取引内容の合意を行う場合の処理シーケンスを示す図である。 支払いを行う場合の処理シーケンスを示す図である。 実施例１の概要を説明するための図である。 実施例２の概要を説明するための図である。 実施例３の概要を説明するための図である。 実施例１における取引内容の合意を行う場合の処理シーケンスを示す図である。 実施例１における支払いを行う場合の処理シーケンスを示す図である。 実施例２における取引内容の合意を行う場合の処理シーケンスを示す図である。 実施例２における支払いを行う場合の処理シーケンスを示す図である。 実施例３における取引内容の合意を行う場合の処理シーケンスを示す図である。 実施例３における支払いを行う場合の処理シーケンスを示す図である。 代行装置の機能構成例を示す図である。 ユーザ装置（送金装置、着金装置）の機能構成例を示す図である。 装置のハードウェア構成例を示す図である。
　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。以下ではまず、本実施の形態に係る技術の理解を容易にするために、従来技術について説明し、その後に、本実施の形態に係る技術を説明する。
　（従来技術における電子通貨の方式）
　図１に示す方式に基づいて、従来技術における電子通貨の方式について説明する。以下、電子通貨を単に「通貨」とも呼ぶ場合がある。また、図１の例では、中央銀行が通貨を発行するものとして、中央銀行は、通貨の０番目の所持者（以下、「所持者０」と表す。）であるものとする。更に、その通貨をｉ（ｉ≧１）番目に利用する利用者（例：市中銀行、店舗、企業、一般消費者等）を「利用者ｉ」として、利用者ｉは、通貨のｉ番目の所持者（以下、「所持者ｉ」とも表す。）でもあるものとする。図１は、所持者ｎ＋１が所持する通貨の形式を示している。
　通貨が発行される場合、中央銀行は、通貨情報が含まれるメッセージＭ０を生成し、メッセージＭ０とそれに対する署名σ０とを利用者１に送信する。ここで、メッセージＭ０には、通貨ＩＤや通貨の額面等の通貨情報、送金先となる利用者１の検証鍵ｖｋ１等が含まれる。なお、メッセージＭ０は「トークン」等とも呼ばれる。
　通貨が流通される場合、利用者ｉ（ｉ≧１）は、付加情報等と呼ばれるメッセージＭｉとそれに対する署名σｉとを生成し、（（Ｍ０，σ０），（Ｍ１，σ１），・・・，（Ｍｉ－１，σｉ－１））に対して（Ｍｉ，σｉ）を付加した上で次の利用者ｉ＋１に送信する。ここで、メッセージＭｉには、送金先となる次の利用者ｉ＋１の検証鍵ｖｋｉ＋１、メッセージＭｉ－１及び署名σｉ－１のハッシュ値Ｈ（Ｍｉ－１，σｉ－１）等が含まれる。これにより、ｉ＋１番目の所持者ｉ＋１は、（（Ｍ０，σ０），（Ｍ１，σ１），・・・，（Ｍｉ，σｉ））という形式の電子通貨を所持することになる。なお、各ＭｉにはＨ（Ｍｉ－１，σｉ－１）が含まれているため、各Ｍｉは、これまでの取引情報を表しているとも言える。
　なお、検証鍵ｖｋｉ（ｉ≧０）は（Ｍｉ，σｉ）を検証するための情報であり、公開情報である。
　このとき、所持者ｎ＋１が中央銀行である場合（つまり、例えば、通貨が還収された場合等）、中央銀行により通貨の正当性検証が行われる。例えば、非特許文献２に記載されている技術を含む従来技術における電子通貨の正当性検証について、図１を参照しながら説明する。図１は、従来技術における電子通貨の正当性検証の一例を示す図である。
　図１に示すように、従来技術では、（（Ｍ０，σ０），（Ｍ１，σ１），・・・，（Ｍｎ，σｎ））に含まれる各（Ｍｉ，σｉ）をそれぞれ検証鍵ｖｋｉにより検証することにより、不正な取引がないか（言い換えれば、Ｍｉが改ざんされていないか等）を確認している。また、通貨が重複して発行・送金等された場合には、重複した発行・送金等をした不正な利用者を特定することもできる。
　（システム構成）
　以下、図面に基づいて本実施の形態に係る技術を説明する。図２は、本実施の形態における電子通貨システムの構成例を示す図である。図２において、電子通貨システムは、発行銀行サーバ２０及び複数のユーザ装置１０を含む。発行銀行サーバ２０及び各ユーザ装置１０は、インターネット等のネットワーク（有線又は無線は問わない）を介して接続される。なお、一部のユーザ装置１０のみが発行銀行サーバ２０と通信可能であってもよい。なお、電子通貨を電子現金と呼んでもよい。
　発行銀行サーバ２０は、通貨を発行する発行銀行が管理する１以上のコンピュータである。発行銀行サーバ２０は、通貨を発行したり、通貨の還収を受け付けたりする。
　ユーザ装置１０は、通貨のユーザが利用するコンピュータである。例えば、サーバコンピュータ、ＰＣ、タブレット端末又はスマートフォン等がユーザ装置１０として利用されてもよい。
　通貨のユーザとは、通貨の流通過程において通貨を送金又は着金する全ての者（個人又は組織）である。例えば、発行銀行以外の金融機関（例えば市中銀行）、企業、店舗、及び一般消費者等がユーザの一例である。
　各ユーザ装置１０は、通貨を利用した取引の場面に応じて、送金元又は送金先になる。送金元とは通貨を送信する側をいい、送金先とは通貨を着金する側をいう。
　送金とは、例えば、発行銀行以外の金融機関（例えば市中銀行）からの引出、金融機関への預入、商取引における支払等である。
　例えば、金融機関からの引出の場合、当該金融機関が管理するユーザ装置１０が送金元であり、引出した通貨を受け取る者が利用するユーザ装置１０が送金先である。金融機関への預入の場合、当該金融期間に通貨を預ける者が利用するユーザ装置１０が送金元であり、当該金融機関が管理するユーザ装置１０が送金先である。支払の場合、支払を行う者（商品又はサービスの購入者）が利用するユーザ装置１０が送金元であり、支払を受ける者（商品又はサービスの販売者）が利用するユーザ装置１０が送金先である。このように、送金元及び送金先は相対的な関係にある。すなわち、電子通貨システムの利用者が利用するユーザ装置１０は、或る取引において送金元になり別の取引において送金先になりうる。また、ユーザ装置１０は、代行装置であってもよい。代行装置の詳細については後述する。
　なお、本実施の形態において、通貨の流通に関する基本的なプロトコル（以下、「基本プロトコル」という。）は、非特許文献１及び非特許文献２の「４．検証対象プロトコル」に準ずる。発行銀行サーバ２０及び各ユーザ装置１０には予めそれぞれの公開鍵及び秘密鍵のペアが発行され、発行銀行サーバ２０及び各ユーザ装置１０は公開鍵及び秘密鍵のペアを記憶している。
　本実施の形態において前提とされる基本プロトコルの概要について説明する。
　通貨は発行銀行サーバ２０によって発行される。通貨の発行とは、通貨としてのトークン（データ）を新たに生成することである。本実施の形態では、発行時（発行直後）の通貨をＴ０と表記する。基本プロトコルにおいて、Ｔ０は、例えば「Ｔ０：＝（ｉｄ，ｖ，ｙ，ｐｋＵｉ，Ｓ０）」という構造を持つ。
　つまり、Ｔ０は、ｄ、ｖ、ｙ、ｐｋＵｉ、及びＳ０を含む。ｉｄは、通貨ＩＤである。通貨ＩＤは、通貨ごとに一意な値である。なお、通貨ＩＤが含まれないこととしてもよい。ｖは通貨の額面である。通貨の額面は、最小単位（例えば、１円）としてもよいし、通貨ごとに異なっていてもよい。ｙは、通貨の発行年である。ｐｋＵｉは、通貨の発行先のユーザの公開鍵である。通貨の発行先は、例えば、金融機関である。また、Ｔ０に通貨の発行先の情報であるＵｉが含まれていてもよい。通貨の発行先が銀行である場合、ＵｉをＢｉと表記してもよい。
　Ｓ０は、（ｉｄ，ｖ，ｙ，ｐｋＵｉ）のハッシュ値に対する発行銀行サーバ２０の秘密鍵を用いた電子署名（以下、単に「署名」という。）である。
　発行された通貨は、取引に応じて送金元としてのユーザ装置１０から送金先としてのユーザ装置１０へ送金される。基本プロトコルにおいて、ユーザｉのユーザ装置１０（「ユーザ装置１０ｉ」とする）からユーザｉ＋１のユーザ装置１０（「ユーザ装置１０ｉ＋１」とする）に或る通貨が送金される場合には、（ｐｋＵｉ＋１，Ｓｉ）を含む情報（「付加情報」と呼ぶ）が送金元のユーザ装置１０ｉによって当該通貨に付加（記録）される。
　ここで、ｐｋＵｉ＋１は、送金先であるユーザ装置１０ｉ＋１の公開鍵である。Ｓｉは、（ｐｋＵｉ＋１，Ｔ０，...，Ｔｉ）のハッシュ値に対する、送金元のユーザｉの秘密鍵による署名である。
　発行直後の１回目の送金による付加情報をＴ１とし、ｎ回目の付加情報をＴｎとすると、発行後にｎ回の送金が行われた通貨は、「（Ｔｎ，Ｔｎ－１，・・・・，Ｔ１，Ｔ０）」という構造を有する。このように、送金が行われるたびに付加情報が通貨に付加される。
　図３は、上記の基本プロトコルに基づく、送金者Ｕｊ（＝ユーザ装置１０ｊ）から着金者Ｕｋ（＝ユーザ装置１０ｋ）への送金（支払い）の手順を示している。図３に示すとおり、より具体的には、公開鍵の証明書が検証のために使用される。
　（課題について）
　上記のような電子通貨システムが使用される場合において、支払い代行等の電子通貨ＡＰＩが公開されることが想定される。例えば図４に示すように、代行者がＡＰＩを公開し、ユーザが当該ＡＰＩを用いて代行者に対して支払い依頼を行う。代行者はユーザに代わって支払先への支払を行う。上記のような支払い代行が行われる場合、代行者が支払いの代行に責任をもつ承認プロトコルが必要となる。しかし、従来技術では、そのような承認プロトコルは提供されていない。従って、従来技術では、送金者が、代行者に安全に支払いを任せることができないという課題がある。
　（実施の形態の概要）
　図５を参照して、上記の課題を解決するための、本実施の形態に係る技術の概要を説明する。図５は、従来技術である基本プロトコルを示す図３に対して追加される要素を示している。
　図５に示すように、基本プロトコルにおける送金者Ｕｊと着金者Ｕｋとの間に中間者としての代行者Ｕａ（＝ユーザ装置１０ａ）が入り、代行者Ｕａが、取引内容の整合性確認と確認内容への署名を行うこととする。
　以下、より具体的な処理内容を、シーケンス図を用いて説明する。以降で説明するシーケンスにおいては、ユーザ装置１０を、送金装置、代行装置、着金装置などと、その役割に応じた名前で呼ぶことにする。また、符号として、Ｕｊ、Ｕａ、Ｕｋなどを付することにする。つまり、送金装置Ｕｊ、代行装置Ｕａ、着金装置Ｕｋなどの表記を用いる。また、送金者（Ｕｊ）、代行者（Ｕａ）、着金者（Ｕｋ）などの表記も使用する場合がある。
　以下ではまず、基本的な処理内容を基本例として説明し、その後に、より具体的な使用場面を想定した実施例１～３を説明する。
　（基本例：取引内容の合意）
　図６を参照して、取引内容の合意を行う処理シーケンスを説明する。図６に示すように、送金装置Ｕｊ（例えば消費者のユーザ装置）、代行装置Ｕａ（例えばサービス／アプリ提供者のユーザ装置）、及び、着金装置Ｕｋ（例えば店舗のユーザ装置）が存在する。
　処理の前提として、代行装置Ｕａと着金装置Ｕｋとの間で、事前に互いの公開鍵を共有（ｐｋＵａ／ｐｋＵｋ）しておく。
　Ｓ１０１（ステップ１０１）において、着金装置Ｕｋは、代行装置Ｕａに対して、支払い要求（金額Ｘ円）を送信する。
　Ｓ１０２において、代行装置Ｕａは、送金装置Ｕｊに対して、着金装置ＵｋからＸ円の支払い要求がされていることを示す支払い要求（Ｕｋ：Ｘ円）を送信する。送金装置Ｕｊは、支払い要求（Ｕｋ：Ｘ円）を受信する。
　ここでは、送金者は取引内容に合意したものとする。なお、取引内容を合意するかどうかの判断は、人（送金者）が行ってもよいし、送金装置Ｕｊが自動的に行ってもよい。
　Ｓ１０３において、送金装置Ｕｊは、代行装置Ｕａに対して、支払い内容合意通知を送信する。Ｓ１０４において、代行装置Ｕａは、着金装置Ｕｋに対して、支払い内容合意通知を送信する。
　上記のように取引内容の合意が行われた場合、代行装置Ｕａは、取引内容を格納部（記憶部）に格納する。ここでの取引内容は、例えば、「送金者（Ｕｊ）が着金者（Ｕｋ）に対してＸ円を支払う」といった内容を示す情報である。
　（基本例：支払い）
　続いて、図７を参照して、取引内容の合意が取れた後に、支払いを行う場合の処理シーケンスを説明する。
　Ｓ２０１において、送金装置Ｕｊは、代行装置Ｕａに対して、通貨Ｔ０、及び、証明書Ａｕｔｈ（ｐｋＵｊ）を送信する。
　Ｓ２０２において、代行装置Ｕａは、格納しておいた取引内容に基づいて、Ｔ０の金額（支払い額）の確認を行い、Ｔ０＝Ｘでなければ取引を中止し、Ｔ０＝Ｘであれば処理を継続する。ここではＴ０＝Ｘであるとする。
　Ｓ２０３において、代行装置Ｕａは、送金装置Ｕｊに対して、着金者の公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａを送信する。
　Ｓ２０４において、送金装置Ｕｊは、公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａのそれぞれを検証し、代行者（請求先）と着金者それぞれの正当性を確認する。また、送金装置Ｕｊは、基本プロトコルに従って、Ｔｎ：＝（ｐｋＵｋ，Ｓｎ）を計算する。
　Ｓ２０５において、送金装置Ｕｊは、代行装置Ｕａに対して、Ｔｎ，…，Ｔ１を送信する。
　Ｓ２０６において、代行装置Ｕａは、Ｔｎ，…，Ｔ１を検証し、検証に成功すれば、自身の秘密鍵ｓｋＵａを用いて取引内容Ｍに対する署名σを生成する。取引内容Ｍは、例えば、「送金者（Ｕｊ）が着金者（Ｕｋ）に対してＸ円を支払う」といった内容を示す情報である。
　Ｓ２０７において、代行装置Ｕａは、着金装置Ｕｋに対して、Ｔｎ，…，Ｔ０，Ｍ，σを送信する。
　Ｓ２０８において、着金装置Ｕｋは、Ｍ、及びσを検証する。Ｍの検証については、着金装置Ｕｋは、合意した取引内容とＭとが整合するかどうか（齟齬がないかどうか）を確認する。σについては、ｐｋＵａを用いて署名検証を行う。ここでは検証に成功したとする。
　Ｔｎ，…，Ｔ０については、代行装置Ｕａにおいて検証が既に行われていることから、着金装置Ｕｋは、必要に応じて、Ｔｎ，…，Ｔ０を検証すればよい。着金装置Ｕｋは、Ｔｎ，…，Ｔ０を格納する。
　以下、より具体的な例として、実施例１～実施例３を説明する。まず、各実施例の概要を説明し、その後に、各実施例の詳細を説明する。
　（実施例１の概要）
　図８を参照して、実施例１の概要を説明する。基本例で説明した承認プロトコルを使用することにより、ユーザの支払いが複数ある場合において、ユーザ側視点で１つの決済にまとめることができる。
　図８の例では、ユーザの支払いとして、支払先Ａへの購入代金の支払いと、支払先Ｂへの手数料の支払いがある。ユーザは、代行者に対して、これらの支払いの依頼を行う。代行者は、取引内容の確認（支払額の合計の確認）を行って、支払先Ａと支払先Ｂそれぞれに対する支払いを行う。
　（実施例２の概要）
　図９を参照して、実施例２の概要を説明する。基本例で説明した承認プロトコルを使用することにより、複数のユーザが支払いを行う場合に、代行者が、各ユーザの支払い分を確認してから決済をすることが可能である。
　図９の例では、支払いを行うユーザとして、ユーザＡとユーザＢが存在し、これら２ユーザにより、支払先Ａへの購入代金の支払いを行う。ユーザＡとユーザＢはそれぞれ、代行者に対して、支払いの依頼を行う。代行者は、取引内容の確認（支払額の合計の確認）を行って、支払先Ａに対する支払いを行う。代行者が介在することで、ユーザＡが支払い、ユーザＢが支払わない、といった状況を防ぐことができる。
　（実施例３の概要）
　図１０を参照して、実施例３の概要を説明する。基本例で説明した承認プロトコルを使用することにより、連続する取引を処理することが可能となり、これにより金融機関の負荷を軽減することができる。
　図１０の例では、ユーザＡがユーザＢに対して代行者を介して支払いを行うとともに、ユーザＢがユーザＡに対して代行者を介して支払いを行う。代行者（例えば取引管理者）は、金融機関に対して取引情報を送信する。以下、各実施例を、処理シーケンスを用いて詳細に説明する。
　（実施例１：取引内容の合意）
　図１１を参照して、実施例１における取引内容の合意を行う処理シーケンスを説明する。図１１に示すように、送金装置Ｕｊ、代行装置Ｕａ、及び、着金装置Ｕｋが存在する。実施例１では、着金装置Ｕｋに、支払先装置Ｕｋ１と支払先装置Ｕｋ２が接続されており、支払先装置Ｕｋ１と支払先装置Ｕｋ２のそれぞれに対して支払いが行われるものとする。すなわち、支払先装置Ｕｋ１と支払先装置Ｕｋ２はそれぞれ、着金装置Ｕｋを経由して代行装置Ｕａと通信を行う。また、「支払先装置」は「着金装置」の例である。
　なお、着金装置Ｕｋを介さずに、支払先装置Ｕｋ１と支払先装置Ｕｋ２がそれぞれ代行装置Ｕａと通信を行うこととしてもよい。
　処理の前提として、代行装置Ｕａと、支払先装置Ｕｋ１と支払先装置Ｕｋ２のそれぞれとの間で、事前に互いの公開鍵を共有（ｐｋＵａ／ｐｋＵｋ１、ｐｋＵｋ２）しておく。
　Ｓ３０１において、着金装置Ｕｋ（支払先装置Ｕｋ１、支払先装置Ｕｋ２）は、代行装置Ｕａに対して、支払い要求（Ｕｋ１：Ｘ円、Ｕｋ２：Ｙ円）を送信する。
　Ｓ３０２において、代行装置Ｕａは、送金装置Ｕｊに対して、支払先装置Ｕｋ１からＸ円の支払い要求がされ、支払先装置Ｕｋ２からＹ円の支払い要求がされていることを示す支払い要求（Ｕｋ１：Ｘ円、Ｕｋ２：Ｙ円）を送信する。送金装置Ｕｊは、支払い要求（Ｕｋ１：Ｘ円、Ｕｋ２：Ｙ円）を受信する。ここでは、送金者は取引内容に合意したものとする。
　Ｓ３０３において、送金装置Ｕｊは、代行装置Ｕａに対して、支払い内容合意通知を送信する。Ｓ３０４において、代行装置Ｕａは、着金装置Ｕｋ（支払先装置Ｕｋ１、支払先装置Ｕｋ２）に対して、支払い内容合意通知を送信する。代行装置Ｕａは、上記のように合意された取引内容を格納部に格納する。
　（実施例１：支払い）
　続いて、図１２を参照して、取引内容の合意が取れた後に、支払いを行う場合の処理シーケンスを説明する。
　Ｓ４０１において、送金装置Ｕｊは、代行装置Ｕａに対して、支払先装置Ｕｋ１向けの通貨Ｔ０、支払先装置Ｕｋ２向けの通貨Ｔ´０、及び、証明書Ａｕｔｈ（ｐｋＵｊ）を送信する。
　Ｓ４０２において、代行装置Ｕａは、Ｔ０とＴ´０の金額（支払い額）の確認を行い、Ｔ０＝ＸかつＴ´０＝Ｙでなければ取引を中止し、Ｔ０＝ＸかつＴ´０＝Ｙであれば処理を継続する。ここではＴ０＝ＸかつＴ´０＝Ｙであるとする。
　Ｓ４０３において、代行装置Ｕａは、送金装置Ｕｊに対して、着金者の公開鍵ｐｋＵｋ１、ｐｋＵｋ２、及び、代行者の公開鍵ｐｋＵａを送信する。
　Ｓ４０４において、送金装置Ｕｊは、ｐｋＵｋ１、ｐｋＵｋ２、及びｐｋＵａのそれぞれを検証し、代行者（請求先）と支払先それぞれの正当性を確認する。また、送金装置Ｕｊは、基本プロトコルに従って、Ｔｎ：＝（ｐｋＵｋ１，Ｓｎ）、Ｔ´ｎ：＝（ｐｋＵｋ２，Ｓ´ｎ）、を計算する。
　Ｓ４０５において、送金装置Ｕｊは、代行装置Ｕａに対して、Ｔｎ，…，Ｔ１、Ｔ´ｎ，…，Ｔ´１を送信する。
　Ｓ４０６において、代行装置Ｕａは、Ｔｎ，…，Ｔ１、Ｔ´ｎ，…，Ｔ´１を検証し、検証に成功すれば、自身の秘密鍵ｓｋＵａを用いて取引内容Ｍに対して署名σを生成する。取引内容Ｍは、例えば、「送金者（Ｕｊ）が、支払先（Ｕｋ１）に対してＸ円を支払い、支払先（Ｕｋ２）に対してＹ円を支払う」といった内容を示す情報である。
　Ｓ４０７において、代行装置Ｕａは、着金装置Ｕｋ（支払先装置Ｕｋ１、支払先装置Ｕｋ２）に対して、Ｔｎ，…，Ｔ０，Ｔ´ｎ，…，Ｔ´０，Ｍ，σを送信する。
　Ｓ４０８において、支払先装置Ｕｋ１と支払先装置Ｕｋ２はそれぞれ、Ｍ、及びσを検証する。Ｍの検証については、支払先装置Ｕｋ１と支払先装置Ｕｋ２はそれぞれ、合意した取引内容とＭとが整合するかどうか（齟齬がないかどうか）を確認する。σについては、ｐｋＵａを用いて署名検証を行う。ここでは検証に成功したとする。
　Ｔｎ，…，Ｔ０及びＴ´ｎ，…，Ｔ´０については、代行装置Ｕａにおいて検証が既に行われていることから、支払先装置Ｕｋ１／支払先装置Ｕｋ２は、必要に応じて、Ｔｎ，…，Ｔ０／Ｔ´ｎ，…，Ｔ´０を検証すればよい。支払先装置Ｕｋ１は、Ｔｎ，…，Ｔ０を格納し、支払先装置Ｕｋ２は、Ｔ´ｎ，…，Ｔ´０を格納する。
　（実施例２：取引内容の合意）
　図１３を参照して、実施例２における取引内容の合意を行う処理シーケンスを説明する。図１３に示すように、送金装置Ｕｊ、代行装置Ｕａ、及び、着金装置Ｕｋが存在する。
　実施例２では、送金装置Ｕｊに、消費者装置Ｕｊ１と消費者装置Ｕｊ２が接続されており、消費者装置Ｕｊ１と消費者装置Ｕｊ２のそれぞれが支払いを行うものとする。すなわち、消費者装置Ｕｊ１と消費者装置Ｕｊ２はそれぞれ、送金装置Ｕｊを経由して代行装置Ｕａと通信を行う。「消費者装置」は「送金装置」の例である。
　なお、送金装置Ｕｊを介さずに、消費者装置Ｕｊ１と消費者装置Ｕｊ２がそれぞれ代行装置Ｕａと通信を行うこととしてもよい。
　処理の前提として、代行装置Ｕａと着金装置Ｕｋとの間で、事前に互いの公開鍵を共有（ｐｋＵａ／ｐｋＵｋ）しておく。
　Ｓ５０１において、着金装置Ｕｋは、代行装置Ｕａに対して、支払い要求（金額Ｘ円）を送信する。
　Ｓ５０２において、代行装置Ｕａは、送金装置Ｕｊ（消費者装置Ｕｊ１、消費者装置Ｕｊ２）に対して、着金装置ＵｋからＸ円の支払い要求がされていることを示す支払い要求（Ｕｋ：Ｘ円）を送信する。消費者装置Ｕｊ１と消費者装置Ｕｊ２はそれぞれ、支払い要求（Ｕｋ：Ｘ円）を受信する。
　ここでは、各消費者は支払内容に合意するとともに、割り勘を行うことを決定する。具体的には、消費者（Ｕｊ１）はＴ０円を支払い、消費者（Ｕｊ２）はＴ´０円を支払うことを決定する。
　Ｓ５０３において、送金装置Ｕｊ（消費者装置Ｕｊ１、消費者装置Ｕｊ２）は、代行装置Ｕａに対して、支払い内容合意、及び割り勘依頼（Ｕｊ１：Ｔ０円，Ｕｊ２：Ｔ´０円）を送信する。ここでの「支払い内容合意」は、消費者装置Ｕｊ１と消費者装置Ｕｊ２のそれぞれの合意情報が含まれるものであってもよいし、消費者装置Ｕｊ１と消費者装置Ｕｊ２の２つの合意情報をとりまとめた１つの合意情報であってもよい。
　代行装置Ｕａは、Ｓ５０１で受信した支払い要求の内容を格納部に保持している。Ｓ５０４において、代行装置Ｕａは、支払い要求に対して支払い額が合っているか否かの確認を行う。つまり、代行装置Ｕａは、Ｔ０＋Ｔ´０＝Ｘとなるか否かを確認する。ここでは、Ｔ０＋Ｔ´０＝Ｘであるとする。
　Ｓ５０５において、代行装置Ｕａは、着金装置Ｕｋに対して、支払い内容合意通知を送信する。
　代行装置Ｕａは、上記のようにして合意された取引内容（Ｘ円に対して、消費者（Ｕｊ１）はＴ０円を支払い、消費者（Ｕｊ２）はＴ´０円を支払う）を格納部に格納する。
　（実施例２：支払い）
　続いて、図１４を参照して、取引内容の合意が取れた後に、支払いを行う場合の処理シーケンスを説明する。ここでは、割り勘の合意に基づいて、消費者装置Ｕｊ１と消費者装置Ｕｊ２のそれぞれが、代行装置Ｕａに対して支払を行うものとする。図示の便宜上、図１４において、消費者装置Ｕｊ１／Ｕｊ２と代行装置Ｕａとの間のシーケンスについては、消費者装置Ｕｊ１についての情報のみを記載している。
　Ｓ６０１において、消費者装置Ｕｊ１は、代行装置Ｕａに対して、通貨Ｔ０、及び、証明書Ａｕｔｈ（ｐｋＵｊ１）を送信する。同様に、消費者装置Ｕｊ２は、代行装置Ｕａに対して、通貨Ｔ´０、及び、証明書Ａｕｔｈ（ｐｋＵｊ２）を送信する。
　Ｓ６０２において、代行装置Ｕａは、支払い額の確認を行う。すなわち、代行装置Ｕａは、消費者装置Ｕｊ１に関して、Ｔ０が、事前に通知された割り勘額でなければ取引中止し、事前に通知された割り勘額であれば処理を継続する。同様に、代行装置Ｕａは、消費者装置Ｕｊ２に関して、Ｔ´０が、事前に通知された割り勘額でなければ取引中止し、事前に通知された割り勘額であれば処理を継続する。
　Ｓ６０３において、代行装置Ｕａは、消費者装置Ｕｊ１に対して、着金者の公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａを送信する。同様に、代行装置Ｕａは、消費者装置Ｕｊ２に対して、着金者の公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａを送信する。
　Ｓ６０４において、消費者装置Ｕｊ１は、公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａのそれぞれを検証し、代行者（請求先）と着金者それぞれの正当性を確認する。また、消費者装置Ｕｊ１は、基本プロトコルに従って、Ｔｎ：＝（ｐｋＵｋ，Ｓｎ）を計算する。
　同様に、消費者装置Ｕｊ２は、公開鍵ｐｋＵｋと代行者の公開鍵ｐｋＵａのそれぞれを検証し、代行者（請求先）と着金者それぞれの正当性を確認する。また、消費者装置Ｕｊ２は、基本プロトコルに従って、Ｔ´ｎ：＝（ｐｋＵｋ，Ｓ´ｎ）を計算する。
　Ｓ６０５において、消費者装置Ｕｊ１は、代行装置Ｕａに対して、Ｔｎ，…，Ｔ１を送信する。同様に、消費者装置Ｕｊ２は、代行装置Ｕａに対して、Ｔ´ｎ，…，Ｔ´１を送信する。
　Ｓ６０６において、代行装置Ｕａは、Ｔｎ，…，Ｔ１、Ｔ´ｎ，…，Ｔ´１を検証し、検証に成功すれば、自身の秘密鍵ｓｋＵａを用いて取引内容Ｍに対して署名σを生成する。取引内容Ｍは、消費者（Ｕｊ１）と消費者（Ｕｊ２）の取引内容をまとめたものであってもよいし、消費者（Ｕｊ１）の取引内容Ｍ１と消費者（Ｕｊ２）の取引内容Ｍ２とに分かれていてもよい。ここでは、取引内容Ｍは、消費者（Ｕｊ１）と消費者（Ｕｊ２）の取引内容をまとめたものであるとする。
　Ｓ６０７において、代行装置Ｕａは、着金装置Ｕｋに対して、Ｔｎ，…，Ｔ０，Ｔ´ｎ，…，Ｔ´０，Ｍ，σを送信する。
　Ｓ６０８において、着金装置Ｕｋは、Ｍ、及びσを検証する。Ｍの検証については、合意した取引内容とＭとが整合するかどうか（齟齬がないかどうか）を確認する。σについては、ｐｋＵａを用いて署名検証を行う。ここでは検証に成功したとする。
　Ｔｎ，…，Ｔ０及びＴ´ｎ，…，Ｔ´０については、代行装置Ｕａにおいて検証が既に行われていることから、着金装置Ｕｋは、必要に応じて、Ｔｎ，…，Ｔ０、Ｔ´ｎ，…，Ｔ´０を検証すればよい。着金装置Ｕｋは、Ｔｎ，…，Ｔ０、Ｔ´ｎ，…，Ｔ´０を格納する。
　（実施例３：取引内容の合意）
　図１５を参照して、実施例３における、取引内容の合意を行う処理シーケンスを説明する。図１５に示すように、送金装置Ｕｊ１、代行装置Ｕａ、及び、送金装置Ｕｊ２が存在する。ここでは、送金装置Ｕｊ１と送金装置Ｕｊ２はそれぞれ、着金（支払いを受けること）を行うことも可能である。
　図１５において、送金装置Ｕｊ１と送金装置Ｕｊ２との間で、代行装置Ｕａを介して連続する複数の取引が行われる（Ｓ７０１、Ｓ７０２）。例えば、基本例のプロトコルに従って、送金装置Ｕｊ１から送金装置Ｕｊ２に対して、代行装置Ｕａを介して、Ｘ１円の支払い要求がなされ、それに対する取引内容合意がなされる。また、並行して、送金装置Ｕｊ２から送金装置Ｕｊ１に対して、代行装置Ｕａを介して、Ｘ２円の支払い要求がなされ、それに対する取引内容合意がなされる。
　代行装置Ｕａは、取引を監視し、記録している（Ｓ７０３）。例えば、上記の取引内容であれば、代行装置Ｕａは、「送金装置Ｕｊ１から送金装置Ｕｊ２に対してＸ１が支払われ、送金装置Ｕｊ２から送金装置Ｕｊ１に対してＸ２が支払われる」という、合意がなされた取引内容を記録している。
　Ｓ７０４において、取引が終了すると、代行装置Ｕａは、取引の収支を確定する。上記の例であれば、代行装置Ｕａは、Ｕｊ１の収支を「Ｘ２－Ｘ１」とし、Ｕｊ２の収支を「Ｘ１－Ｘ２」と算出する。代行装置Ｕａは、収支の値を送金装置Ｕｊ１と送金装置Ｕｊ２のそれぞれに通知する。
　図１５の例では、送金装置Ｕｊ１の収支が「－Ｘ円」であり、送金装置Ｕｊ２の収支が「＋Ｘ円」である。つまり、送金装置Ｕｊ１がＸ円を送金装置Ｕｊ２へ支払うことで、複数回の取引に係る支払い／着金を、１回の支払いで済ませることができる。
　（実施例３：支払い）
　続いて、図１６を参照して、図１５の処理の後に、支払いを行う場合の処理シーケンスを説明する。図１６は、上記のように、送金装置Ｕｊ１から送金装置Ｕｊ２へＸ円を支払う場合を示している。また、実施例３では、金融機関装置３０が使用される。
　Ｓ８０１において、送金装置Ｕｊ１は、代行装置Ｕａに対して、通貨Ｔ０、及び、証明書Ａｕｔｈ（ｐｋＵｊ１）を送信する。
　Ｓ８０２において、代行装置Ｕａは、Ｔ０の金額（支払い額）の確認を行い、Ｔ０＝Ｘでなければ取引を中止し、Ｔ０＝Ｘであれば処理を継続する。ここではＴ０＝Ｘであるとする。
　Ｓ８０３において、代行装置Ｕａは、送金装置Ｕｊ１に対して、送金装置Ｕｊ２（着金者）の公開鍵ｐｋＵｊ２と代行者の公開鍵ｐｋＵａを送信する。
　Ｓ８０４において、送金装置Ｕｊ１は、公開鍵ｐｋＵｊ２と代行者の公開鍵ｐｋＵａのそれぞれを検証し、代行者（請求先）と着金者それぞれの正当性を確認する。また、送金装置Ｕｊ１は、基本プロトコルに従って、Ｔｎ：＝（ｐｋＵｊ２，Ｓｎ）を計算する。
　Ｓ８０５において、送金装置Ｕｊ１は、代行装置Ｕａに対して、Ｔｎ，…，Ｔ１を送信する。
　Ｓ８０６において、代行装置Ｕａは、Ｔｎ，…，Ｔ１を検証し、検証に成功すれば、自身の秘密鍵ｓｋＵａを用いて取引内容Ｍに対して署名σを生成する。取引内容Ｍは、例えば、「送金者（Ｕｊ１）が送金者（Ｕｊ２）に対してＸ円を支払う」といった内容を示す情報である。取引内容Ｍは、結果として「送金者（Ｕｊ１）が送金者（Ｕｊ２）に対してＸ円を支払う」ことを示す複数の取引内容が含まれていてもよい。
　Ｓ８０７において、代行装置Ｕａは、金融機関装置３０に対してＭとσを送信する。Ｍとσを受信した金融機関装置３０は、Ｍ及びσを検証し、取引内容Ｍを保管する。
　Ｓ８０８において、代行装置Ｕａは、送金装置Ｕｊ２に対して、Ｔｎ，…，Ｔ０，Ｍ、σを送信する。
　Ｓ８０９において、送金装置Ｕｊ２は、Ｍ、及びσを検証する。Ｍの検証については、送金装置Ｕｊ２は、合意した取引内容とＭとが整合するかどうか（齟齬がないかどうか）を確認する。σについては、ｐｋＵａを用いて署名検証を行う。ここでは検証に成功したとする。
　Ｔｎ，…，Ｔ０については、代行装置Ｕａにおいて検証が既に行われていることから、送金装置Ｕｊ２は、必要に応じて、Ｔｎ，…，Ｔ０を検証すればよい。送金装置Ｕｊ２は、Ｔｎ，…，Ｔ０を格納する。
　（装置構成例）
　図１７に、これまでに説明した代行装置Ｕａの機能構成例を示す。図１７に示すように、代行装置Ｕａは、代行処理部１１０及び格納部１２０を有する。代行処理部１１０は、合意処理部１１１と支払処理部１１２を含む。
　合意処理部１１１は、基本例及び実施例で説明した取引内容の合意に関わる処理を実行する。支払処理部１１２は、基本例及び実施例で説明した支払いに関わる処理を実行する。格納部１１０は、代行処理部１１０により処理された取引内容等を格納する。
　図１８に、送金装置及び着金装置のいずれにもなることができるユーザ装置１０の機能構成例を示す。
　図１８に示すように、ユーザ装置１０は、合意処理部２１０、送金処理部２２０、着金処理部２３０、及び格納部２４０を有する。
　合意処理部２１０は、基本例及び実施例で説明した取引内容の合意に関わる処理を実行する。送金処理部２２０は、基本例及び実施例で説明した送金に関わる処理を実行する。着金処理部２３０は、基本例及び実施例で説明した着金に関わる処理を実行する。格納部２４０は、合意処理部２１０、送金処理部２２０、及び着金処理部２３０の処理に使用する情報を格納する。
　（ハードウェア構成例）
　本実施の形態で説明したいずれの装置（代行装置、送金装置、着金装置、ユーザ装置等）も、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。
　すなわち、当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
　図１９は、上記コンピュータのハードウェア構成例を示す図である。図１９のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、当該コンピュータは、更にＧＰＵを備えてもよい。
　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワーク等に接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。
　（実施の形態の効果）
　以上説明したとおり、本実施の形態で説明した技術により、電子通貨送金プロトコルの中間者として代行者が入り、取引内容の整合性確認と確認内容への署名を行うこととしたので、代行者に安全に支払いを任せることができる。
　以上の実施形態に関し、更に以下の付記を開示する。
　＜付記＞
（付記項１）
　送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置であって、
　前記着金装置と前記送金装置との間で合意した取引内容を格納する格納部と、
　前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理部と
　を備える代行装置。
（付記項２）
　前記代行処理部は、前記処理を継続する場合において、前記着金装置の公開鍵と、前記代行装置の公開鍵を前記送金装置に送信する
　付記項１に記載の代行装置。
（付記項３）
　前記代行処理部は、前記通貨についての検証を行い、前記取引内容に対する署名を生成し、前記取引内容と前記署名とを前記着金装置に送信する
　付記項１に記載の代行装置。
（付記項４）
　前記代行処理部は、複数の送金装置から受信した複数の通貨における支払い額の合計が正しいか否かを確認する
　付記項１に記載の代行装置。
（付記項５）
　前記代行処理部は、前記送金装置と前記着金装置との間の複数回の取引で確定した収支に基づいて、前記送金装置から受信した前記通貨による支払い額が正しいか否かを確認する
　付記項１に記載の代行装置。
（付記項６）
　送金装置、代行装置、及び着金装置を備える電子通貨システムであって、
　前記着金装置と前記送金装置とが、前記代行装置を介して取引の合意を行い、
　前記代行装置が、前記着金装置と前記送金装置との間で合意した取引内容を格納部に格納し、
　前記代行装置が、前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する
　電子通貨システム。
（付記項７）
　送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置が実行する代行処理方法であって、
　前記着金装置と前記送金装置との間で合意した取引内容を格納部に格納するステップと、
　前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理ステップと
　を備える代行処理方法。
（付記項８）
　コンピュータを、付記項１ないし５のうちいずれか１項に記載の代行装置における各部として機能させるためのプログラムを記憶した非一時的記憶媒体。
　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　ユーザ装置
２０　発行銀行サーバ
３０　金融機関装置
１１０　代行処理部
１１１　合意処理部
１１２　支払処理部
１２０　格納部
２１０　合意処理部
２２０　送金処理部
２３０　着金処理部
２４０　格納部
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インタフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims (8)

  1. 　送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置であって、
    　前記着金装置と前記送金装置との間で合意した取引内容を格納する格納部と、
    　前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理部と
    　を備える代行装置。
  2. 　前記代行処理部は、前記処理を継続する場合において、前記着金装置の公開鍵と、前記代行装置の公開鍵を前記送金装置に送信する
    　請求項１に記載の代行装置。
  3. 　前記代行処理部は、前記通貨についての検証を行い、前記取引内容に対する署名を生成し、前記取引内容と前記署名とを前記着金装置に送信する
    　請求項１に記載の代行装置。
  4. 　前記代行処理部は、複数の送金装置から受信した複数の通貨における支払い額の合計が正しいか否かを確認する
    　請求項１に記載の代行装置。
  5. 　前記代行処理部は、前記送金装置と前記着金装置との間の複数回の取引で確定した収支に基づいて、前記送金装置から受信した前記通貨による支払い額が正しいか否かを確認する
    　請求項１に記載の代行装置。
  6. 　送金装置、代行装置、及び着金装置を備える電子通貨システムであって、
    　前記着金装置と前記送金装置とが、前記代行装置を介して取引の合意を行い、
    　前記代行装置が、前記着金装置と前記送金装置との間で合意した取引内容を格納部に格納し、
    　前記代行装置が、前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する
    　電子通貨システム。
  7. 　送金装置、代行装置、及び着金装置を備える電子通貨システムにおいて使用される前記代行装置が実行する代行処理方法であって、
    　前記着金装置と前記送金装置との間で合意した取引内容を格納部に格納するステップと、
    　前記送金装置から通貨を受信し、前記取引内容に基づいて、前記通貨による支払い額が正しいか否かを確認し、確認結果に基づいて、処理を継続するか否かを判断する代行処理ステップと
    　を備える代行処理方法。
  8. 　コンピュータを、請求項１ないし５のうちいずれか１項に記載の代行装置における各部として機能させるためのプログラム。
PCT/JP2024/020029 2024-05-31 2024-05-31 代行装置、電子通貨システム、代行処理方法、及びプログラム Pending WO2025248756A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/020029 WO2025248756A1 (ja) 2024-05-31 2024-05-31 代行装置、電子通貨システム、代行処理方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/020029 WO2025248756A1 (ja) 2024-05-31 2024-05-31 代行装置、電子通貨システム、代行処理方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2025248756A1 true WO2025248756A1 (ja) 2025-12-04

Family

ID=97869934

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/020029 Pending WO2025248756A1 (ja) 2024-05-31 2024-05-31 代行装置、電子通貨システム、代行処理方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2025248756A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020240771A1 (ja) * 2019-05-30 2020-12-03 日本電気株式会社 仮想通貨システム、端末、サーバ、仮想通貨の取引方法及びプログラム
US20220300953A1 (en) * 2019-06-04 2022-09-22 Algorand, Inc. Auditing digital currency transactions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020240771A1 (ja) * 2019-05-30 2020-12-03 日本電気株式会社 仮想通貨システム、端末、サーバ、仮想通貨の取引方法及びプログラム
US20220300953A1 (en) * 2019-06-04 2022-09-22 Algorand, Inc. Auditing digital currency transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BANK OF JAPAN: "Report on the results of the "Proof of Concept Phase 2" demonstration experiment on central bank digital currency", BANK OF JAPAN, PAYMENT AND SETTLEMENT SYSTEMS DEPARTMENT DOCUMENT, BANK OF JAPAN, JP, 1 April 2023 (2023-04-01), JP, pages 1 - 27, XP093377146, Retrieved from the Internet <URL:https://www.boj.or.jp/paym/digital/dig230417a.pdf> *

Similar Documents

Publication Publication Date Title
JP7244537B2 (ja) 即時オフラインのブロックチェイントランザクションのセキュリティを高めるのに適しているコンピュータにより実装されるシステム及び方法
EP3635665B1 (en) Linked multiple blockchain system
US20200013048A1 (en) Blockchain-based secure payment system
US11245653B2 (en) Methods and systems for creating and using massless currency
CN102982441B (zh) 一种处理信息的方法及电子支付设备
JP6363254B1 (ja) 支払支援システム及び支払支援方法
CN111144862A (zh) 数字货币双离线支付的实现方法、装置、设备、存储介质
US20170221053A1 (en) Digital asset conversion
JP6521421B1 (ja) 通貨情報処理装置および通貨情報処理システム
EP3475903A1 (en) Digital asset account management
JPH0954808A (ja) オンライン決済システム、電子小切手の発行システム及び検査システム
US20240127232A1 (en) Systems and methods for improved electronic transfer of resources via a blockchain
CN110033370B (zh) 账户创建方法及装置、电子设备、存储介质
US20240257243A1 (en) A system and method for trading cryptocurrencies, tokenized assets and/or fiat currencies on a single distributed ledger system with multiple issuing institutions
JP2024501883A5 (ja)
de Carvalho Ferreira et al. A scheme for analyzing electronic payment systems
US20200242573A1 (en) Cryptographic transactions supporting real world requirements
JP2020052652A (ja) 仮想通貨を用いて貿易取引の管理を行う為の貿易取引管理システム、貿易取引管理方法および貿易取引管理プログラム
WO2021117515A1 (ja) 電子資産管理方法、及び電子資産管理装置
JP2022089542A (ja) 処理システム、処理装置、処理方法及び処理プログラム
WO2025243538A1 (ja) 電子通貨システム、電子通貨処理装置、電子通貨処理方法及びプログラム
WO2021071464A1 (en) Dynamic provisioning of wallets in a secure payment system
WO2025243481A1 (ja) 電子通貨システム、送金装置、送金方法及びプログラム
JP4067522B2 (ja) 電子小切手の決済方法、代金決済方法、及び発行人コンピュータ
WO2025243376A1 (ja) 電子通貨システム、情報処理装置、方法、及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24941641

Country of ref document: EP

Kind code of ref document: A1