Proxy device, electronic currency system, proxy processing method, and program

Abstract

Provided is an electronic currency system comprising: a remittance device; a proxy device; and a money-receiving device. The proxy device used in this system comprises: a storage unit that stores transaction content agreed upon between the money-receiving device and the remittance device; and a proxy processing unit that receives currency from the remittance device, confirms, on the basis of the transaction content, whether a payment amount based on the currency is correct, and determines whether to continue processing on the basis of the confirmation result.

Description

Agent device, electronic currency system, agent processing method, and program

[0001] The present invention relates to the technical field of electronic currency systems.

[0002] Central bank digital currencies (CBDCs) are being considered around the world, and the Bank of Japan has stated that digital currencies must meet the following five characteristics: (1) universal access, (2) security, (3) resilience, (4) instantaneous settlement, and (5) interoperability. To meet the requirements of resilience and instantaneous settlement, the currency must be circulated through user-to-user settlement (offline settlement without a central server). Furthermore, because currency is subject to repeated transactions between users (transferability), transaction authentication and fraud traceability are essential from a security perspective.

[0003] Since it is difficult to detect tampering with offline digital currencies, a method is known in which signatures are chained and verified in bulk at the time of deposit to detect fraud. In this case, conventional electronic currency sending protocols assume that the sender makes the payment directly to the recipient.

[0004] Okuda, et al., "Initial Study on Formal Verification Methods for Token-Based Electronic Cash Systems," Research Report, Electronic Intellectual Property and Infrastructure (EIP), 2022-EIP-98, 24, pp.1-8, 2022 / 12 / 15; Okuda, et al., "Considerations on Formal Verification of Double-Spending Detection and Privacy for Token-Based Electronic Cash Systems," Research Report, Computer Security (CSEC), 2023-CSEC-100, 66, pp.1-8, 2023 / 2 / 27

[0005] It is expected that APIs for payment agents and the like will be made public in electronic currency systems. In such a situation, an authorization protocol is required in which the agent is responsible for the payment on behalf of the recipient. However, the prior art does not provide such an authorization protocol. Therefore, the prior art has a problem in that the remitter cannot safely entrust the payment to the agent.

[0006] The present invention has been made in consideration of the above points, and aims to provide a technology in an electronic currency system that enables a remitter to safely entrust payments to an agent.

[0007] According to the disclosed technology, there is provided an agent device used in an electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, the agent device comprising: a storage unit that stores transaction details agreed upon between the remittance device and the remittance receiving 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.

[0008] The disclosed technology provides a technology that allows a remitter to safely entrust payments to an agent.

[0009] FIG. 1 is a diagram for explaining an electronic currency system in the prior art. FIG. 1 is a diagram for explaining an example of the configuration of an electronic currency system in an embodiment of the present invention. FIG. 2 is a diagram for explaining a payment procedure based on a basic protocol. FIG. 3 is a diagram for explaining the problem. FIG. 4 is a diagram for explaining an overview of a technology related to an embodiment of the present invention. FIG. 5 is a diagram for explaining a processing sequence when agreeing on transaction details. FIG. 6 is a diagram for explaining a processing sequence when making a payment. FIG. 7 is a diagram for explaining an overview of Example 1. FIG. 8 is a diagram for explaining an overview of Example 2. FIG. 9 is a diagram for explaining an overview of Example 3. FIG. 10 is a diagram for explaining a processing sequence when agreeing on transaction details in Example 1. FIG. 11 is a diagram for explaining a processing sequence when making a payment in Example 1. FIG. 12 is a diagram for explaining a processing sequence when agreeing on transaction details in Example 2. FIG. 13 is a diagram for explaining a processing sequence when making a payment in Example 2. FIG. 14 is a diagram for explaining a processing sequence when agreeing on transaction details in Example 3. FIG. 15 is a diagram for explaining a processing sequence when making a payment in Example 3. FIG. 16 is a diagram for explaining an example of the functional configuration of an agent device. FIG. 17 is a diagram for explaining an example of the functional configuration of a user device (remittance device, remittance device). FIG. 18 is a diagram for explaining an example of the hardware configuration of a device.

[0010] Hereinafter, an embodiment of the present invention (the present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment. First, in order to facilitate understanding of the technology related to the present embodiment, the conventional technology will be described below, and then the technology related to the present embodiment will be described.

[0011] (Electronic Currency Method in Prior Art) An electronic currency method in prior art will be described based on the method shown in FIG. 1. Hereinafter, electronic currency may also be simply referred to as "currency." In the example of FIG. 1, 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"). Furthermore, the i-th (i≧1) user of the currency (e.g., a commercial bank, store, company, general consumer, etc.) is referred to as "user i," and 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.

[0012] When a currency is issued, the central bank sends a message M ０ and generates a message M ０ and its signature σ ０ and is sent to user 1. Here, message M ０ The verification key vk of the user 1 who is the remittance destination is included in the １ etc. Note that the message M ０ is also called a "token".

[0013] When currency is circulated, a user i (i≧1) sends a message M ｉ and its signature σ ｉ and generate ((M ０ , σ ０ ), (M １ , σ １ ), ..., (M ｉ－１ , σ ｉ－１ )) to (M ｉ , σ ｉ ) and then transmits it to the next user i+1. ｉThe verification key vk of the next user i+1 to whom the remittance is to be made is ｉ＋１ , message M ｉ－１ and signature σ ｉ－１ The hash value H(M ｉ－１ , σ ｉ－１ ) and so on. As a result, the i+1th owner i+1 can ０ , σ ０ ), (M １ , σ １ ), ..., (M ｉ , σ ｉ )) format of electronic currency. ｉ H (M ｉ－１ , σ ｉ－１ ) is included, so each M ｉ It can be said that this represents transaction information up to now.

[0014] In addition, the verification key vk ｉ (i≧0) is (M ｉ , σ ｉ ) and is public information.

[0015] In this case, if holder n+1 is a central bank (i.e., for example, when the currency is withdrawn), the central bank verifies the validity of the currency. Verification of the validity of electronic currency in conventional technology, including the technology described in Non-Patent Document 2, will be described with reference to Figure 1. Figure 1 is a diagram showing an example of verification of the validity of electronic currency in conventional technology.

[0016] As shown in FIG. 1, in the prior art, ０ , σ ０ ), (M １ , σ １ ), ..., (M ｎ , σ ｎ Each (M ｉ , σ ｉ ) are the verification keys vk ｉ By verifying this, it is possible to check whether there are any fraudulent transactions (in other words, ｉ In addition, if duplicate currency is issued or transferred, it is possible to identify the fraudulent user who issued or transferred the duplicate currency.

[0017] (System Configuration) The technology according to this embodiment will be described below with reference to the drawings. FIG. 2 is a diagram showing an example of the configuration of an electronic currency system according to this embodiment. In FIG. 2, 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. Note that electronic currency may also be called electronic cash.

[0018] 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 withdrawals of the currency.

[0019] The user device 10 is a computer used by a user of the currency. For example, a server computer, a PC, a tablet terminal, a smartphone, or the like may be used as the user device 10.

[0020] A currency user is any person (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.

[0021] Each user device 10 acts as a remitter or a remittance destination depending on the situation of the transaction using the currency. The remitter is the party that sends the currency, and the remittance destination is the party that receives the currency.

[0022] Remittances include, for example, withdrawals from financial institutions other than the issuing bank (for example, commercial banks), deposits to financial institutions, and payments in commercial transactions.

[0023] For example, in the case of a withdrawal from a financial institution, the user device 10 managed by the financial institution is the remitter, and the user device 10 used by the person receiving the withdrawn currency is the remitter. In the case of a deposit at a financial institution, the user device 10 used by the person depositing currency at the financial institution is the remitter, and the user device 10 managed by the financial institution is the remitter. In the case of a payment, the user device 10 used by the person making the payment (the purchaser of the product or service) is the remitter, and the user device 10 used by the person receiving the payment (the seller of the product or service) is the remitter. In this way, the remitter and the remitter are in a relative relationship. In other words, the user device 10 used by a user of the electronic currency system can be the remitter in one transaction and the remitter in another transaction. The user device 10 may also be an agent device. Details of the agent device will be described later.

[0024] In this embodiment, 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 pair of a public key and a private key is issued in advance to the issuing bank server 20 and each user device 10, and the issuing bank server 20 and each user device 10 store the pair of the public key and the private key.

[0025] An outline of the basic protocol that is a prerequisite for this embodiment will be described.

[0026] Currency is issued by the issuing bank server 20. Issuing currency means newly generating a token (data) as currency. In this embodiment, currency at the time of issuance (immediately after issuance) is denoted as T0. In the basic protocol, T0 has a structure such as "T0:=(id, v, y, pkUi, S0)," for example.

[0027] That is, 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 of issue of the currency. 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.

[0028] 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).

[0029] The issued currency is remitted from the user device 10 as the remitter to the user device 10 as the recipient in accordance with the transaction. In the basic protocol, when a certain currency is remitted 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 as the remitter.

[0030] Here, pkUi+1 is the public key of the user device 10i+1, which is the recipient of the remittance, and Si is a signature of the hash value of (pkUi+1, T0, ..., Ti) using the private key of the user i, who is the sender of the remittance.

[0031] If the additional information for the first remittance immediately after issuance is T1 and the additional information for the nth remittance is Tn, then a currency that has been remitted n times since issuance will have the structure "(Tn, Tn-1, ..., T1, T0)." In this way, additional information is added to the currency each time a remittance is made.

[0032] Figure 3 shows the procedure for sending (paying) money from a sender Uj (=user device 10j) to a receiver Uk (=user device 10k) based on the above basic protocol. More specifically, as shown in Figure 3, a public key certificate is used for verification.

[0033] (Problems) When an electronic currency system such as the one described above is used, it is assumed that an electronic currency API for payment agency or the like will be made public. For example, as shown in FIG. 4, 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. When such a payment agency is used, an authorization protocol is required in which the agent takes responsibility for acting as an agent for the payment. However, the prior art does not provide such an authorization protocol. Therefore, the prior art has a problem in that a remitter cannot safely entrust a payment to an agent.

[0034] (Outline of the embodiment) An outline of the technology according to the present embodiment for solving the above problems will be described with reference to Fig. 5. Fig. 5 shows elements added to Fig. 3 showing the basic protocol of the prior art.

[0035] As shown in Figure 5, in the basic protocol, an agent Ua (=user device 10a) acts as an intermediary between the sender Uj and the receiver Uk, and the agent Ua verifies the consistency of the transaction details and signs the confirmation details.

[0036] The following describes the specific processing details using sequence diagrams. In the sequences described below, the user devices 10 will be referred to by names according to their roles, such as remittance device, agent device, and remittance receiving device. Also, symbols such as Uj, Ua, and Uk will be used. That is, notations such as remittance device Uj, agent device Ua, and remittance receiving device Uk will be used. Notations such as remitter (Uj), agent (Ua), and remittance receiving device (Uk) may also be used.

[0037] In the following, first, the basic processing contents will be explained as a basic example, and then Examples 1 to 3 will be explained assuming more specific usage scenarios.

[0038] (Basic Example: Agreement on Transaction Details) The processing sequence for agreeing on transaction details will be described with reference to Fig. 6. As shown in Fig. 6, there are 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), and a remittance device Uk (e.g., a user device of a store).

[0039] As a prerequisite for the process, the agent device Ua and the money receiving device Uk share their public keys (pkUa / pkUk) in advance.

[0040] In S101 (step 101), the money receiving device Uk transmits a payment request (amount X yen) to the agent device Ua.

[0041] In S102, the agent device Ua transmits 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).

[0042] Here, it is assumed that the remitter agrees 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.

[0043] In S103, the remittance device Uj transmits a payment agreement notice to the agent device Ua, and in S104, the agent device Ua transmits a payment agreement notice to the remittance device Uk.

[0044] When the transaction details are agreed upon as described above, the agent device Ua stores the transaction details in a storage unit (memory unit). The transaction details here are, for example, information indicating that "the remitter (Uj) will pay X yen to the recipient (Uk)."

[0045] (Basic Example: Payment) Next, with reference to FIG. 7, a processing sequence for making a payment after agreement on the transaction details will be described.

[0046] In S201, the remittance apparatus Uj transmits the currency T0 and the certificate Auth(pkUj) to the agent apparatus Ua.

[0047] In S202, the agent device Ua confirms the amount of T0 (payment amount) based on the stored transaction details, and if T0=X, cancels the transaction, but if T0=X, continues processing. Here, it is assumed that T0=X.

[0048] In S203, the agent apparatus Ua transmits the public key pkUk of the recipient and the public key pkUa of the agent to the remittance apparatus Uj.

[0049] In S204, the remittance device Uj verifies the public key pkUk and the public key pkUa of the agent to confirm the legitimacy of the agent (billing destination) and the remittance recipient. The remittance device Uj also calculates Tn:=(pkUk, Sn) according to the basic protocol.

[0050] In S205, the remittance apparatus Uj transmits Tn, . . . , T1 to the agent apparatus Ua.

[0051] In S206, the agent device Ua verifies Tn, ..., T1, and if the verification is successful, uses its own private key skUa to generate a signature σ for the transaction content M. The transaction content M is information indicating, for example, content such as "the remitter (Uj) pays X yen to the recipient (Uk)."

[0052] In S207, the agent apparatus Ua transmits Tn, . . . , T0, M, and σ to the money receiving apparatus Uk.

[0053] In S208, the money depositing device Uk verifies M and σ. For the verification of M, the money depositing device Uk checks whether M is consistent with the agreed-upon transaction details (whether there are any discrepancies). For σ, signature verification is performed using pkUa. Here, it is assumed that the verification is successful.

[0054] Since verification of Tn, ..., T0 has already been performed by the agent device Ua, the money depositing device Uk can verify Tn, ..., T0 as needed. The money depositing device Uk stores Tn, ..., T0.

[0055] As more specific examples, Examples 1 to 3 will be described below. First, an overview of each example will be described, and then the details of each example will be described.

[0056] (Outline of First Embodiment) An outline of the first embodiment will be described with reference to Fig. 8. By using the approval protocol described in the basic example, multiple user payments can be consolidated into a single settlement from the user's perspective.

[0057] In the example of Figure 8, the user's payments include a payment of the purchase price to Payee A and a payment of a handling fee to Payee B. The user requests the agent to make these payments. The agent confirms the transaction details (confirms the total payment amount) and makes the payments to Payee A and Payee B, respectively.

[0058] (Outline of Example 2) An outline of Example 2 will be described with reference to Fig. 9. By using the approval protocol described in the basic example, when multiple users make payments, an agent can confirm the payment amount of each user before making the settlement.

[0059] In the example of Figure 9, there are two users making payments: User A and User B, who together pay the purchase price to Payee A. User A and User B each request payment from an agent. The agent then confirms the transaction details (the total payment amount) and makes the payment to Payee A. By using an agent as an intermediary, it is possible to prevent situations where User A pays but User B does not.

[0060] (Outline of Example 3) An outline of Example 3 will be described with reference to Fig. 10. By using the approval protocol described in the basic example, it becomes possible to process successive transactions, thereby reducing the load on financial institutions.

[0061] In the example of Figure 10, User A makes a payment to User B via an agent, and User B makes a payment to User A via an agent. The agent (e.g., a transaction manager) sends transaction information to a financial institution. Each embodiment will be described in detail below using a processing sequence.

[0062] (Example 1: Agreement on transaction details) With reference to Figure 11, the processing sequence for agreeing on transaction details in Example 1 will be described. As shown in Figure 11, there are a remittance device Uj, an agent device Ua, and a deposit device Uk. In Example 1, 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. In other words, the payment destination device Uk1 and the payment destination device Uk2 each communicate with the agent device Ua via the deposit device Uk. Furthermore, the "payment destination device" is an example of a "deposit device".

[0063] It is also possible for the payment destination device Uk1 and the payment destination device Uk2 to communicate with the agent device Ua individually, without going through the money receiving device Uk.

[0064] As a prerequisite for the process, the public keys (pkUa / pkUk1, pkUk2) of the agent apparatus Ua, the payment destination apparatus Uk1, and the payment destination apparatus Uk2 are shared in advance.

[0065] In S301, the money receiving apparatus Uk (payment destination apparatus Uk1, payment destination apparatus Uk2) transmits a payment request (Uk1: X yen, Uk2: Y yen) to the agent apparatus Ua.

[0066] In S302, 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 requests (Uk1: X yen, Uk2: Y yen). Here, it is assumed that the remitter agrees to the transaction details.

[0067] In S303, the remittance device Uj sends a payment details agreement notice to the agent device Ua. In S304, the agent device Ua sends a payment details agreement notice 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 a storage unit.

[0068] (First Embodiment: Payment) Next, with reference to FIG. 12, a processing sequence for making a payment after agreement on the transaction details is reached will be described.

[0069] In S401, the remittance apparatus Uj transmits currency T0 for the payment destination apparatus Uk1, currency T'0 for the payment destination apparatus Uk2, and a certificate Auth(pkUj) to the agent apparatus Ua.

[0070] In S402, the agent device Ua confirms the amounts T0 and T'0 (payment amounts), and if T0=X and T'0=Y are not satisfied, the agent device Ua cancels the transaction, and if T0=X and T'0=Y, the agent device Ua continues processing. Here, it is assumed that T0=X and T'0=Y.

[0071] In S403, the agent apparatus Ua transmits the public keys pkUk1 and pkUk2 of the recipient and the public key pkUa of the agent to the remittance apparatus Uj.

[0072] In S404, the remittance device Uj verifies pkUk1, pkUk2, and pkUa, respectively, and confirms the legitimacy of the agent (billing destination) and the payee. The remittance device Uj also calculates Tn:=(pkUk1, Sn), T'n:=(pkUk2, S'n) according to the basic protocol.

[0073] In S405, the remittance apparatus Uj transmits Tn, ..., T1, T'n, ..., T'1 to the agent apparatus Ua.

[0074] In S406, 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, content such as "the remitter (Uj) pays X yen to the payee (Uk1) and Y yen to the payee (Uk2)."

[0075] In S407, the agent apparatus Ua transmits Tn, ..., T0, T'n, ..., T'0, M, and σ to the payment receiving apparatus Uk (payment receiving apparatus Uk1, payment receiving apparatus Uk2).

[0076] In S408, the payment destination device Uk1 and the payment destination device Uk2 each verify M and σ. For the verification of M, 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). For σ, signature verification is performed using pkUa. Here, it is assumed that the verification is successful.

[0077] 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.

[0078] (Example 2: Agreement on transaction details) A processing sequence for agreeing on transaction details in Example 2 will be described with reference to Fig. 13. As shown in Fig. 13, there are a remittance device Uj, an agent device Ua, and a receivable device Uk.

[0079] In Example 2, consumer devices Uj1 and Uj2 are connected to the remittance device Uj, and each of the consumer devices Uj1 and Uj2 makes a payment. That is, the consumer devices Uj1 and Uj2 each communicate with the agent device Ua via the remittance device Uj. The "consumer device" is an example of the "remittance device."

[0080] Alternatively, the consumer device Uj1 and the consumer device Uj2 may each communicate with the agent device Ua without going through the remittance device Uj.

[0081] As a prerequisite for the process, the agent device Ua and the money receiving device Uk share their public keys (pkUa / pkUk) in advance.

[0082] In S501, the money receiving device Uk transmits a payment request (amount X yen) to the agent device Ua.

[0083] In S502, the agent device Ua transmits 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. The consumer device Uj1 and consumer device Uj2 each receive the payment request (Uk: X yen).

[0084] Here, 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.

[0085] In S503, the remittance device Uj (consumer device Uj1, consumer device Uj2) transmits a payment agreement and a split request (Uj1: T0 yen, Uj2: T'0 yen) to the agent device Ua. The "payment agreement" here may include the respective agreement information of the consumer device Uj1 and the consumer device Uj2, or may be a single agreement information that combines the two agreement information of the consumer device Uj1 and the consumer device Uj2.

[0086] The agent device Ua stores the contents of the payment request received in S501 in a storage unit. In S504, the agent device Ua checks whether the payment amount is correct for the payment request. In other words, the agent device Ua checks whether T0 + T'0 = X. Here, it is assumed that T0 + T'0 = X.

[0087] In S505, the agent apparatus Ua transmits a payment details agreement notice to the money receiving apparatus Uk.

[0088] The agent device Ua stores the transaction details agreed upon as described above (for X yen, the consumer (Uj1) pays T0 yen, and the consumer (Uj2) pays T'0 yen) in the storage unit.

[0089] (Example 2: Payment) Next, with reference to Figure 14, we will explain the processing sequence when making a payment after agreeing on the transaction details. Here, based on the agreement to split the bill, the consumer device Uj1 and the consumer device Uj2 each make a payment to the agent device Ua. For convenience of illustration, in Figure 14, only information about the consumer device Uj1 is shown for the sequence between the consumer devices Uj1 / Uj2 and the agent device Ua.

[0090] In S601, the consumer device Uj1 transmits the currency T0 and the certificate Auth(pkUj1) to the agent device Ua. Similarly, the consumer device Uj2 transmits the currency T'0 and the certificate Auth(pkUj2) to the agent device Ua.

[0091] In S602, the agent device Ua confirms the payment amount. That is, for the consumer device Uj1, the agent device Ua cancels the transaction if T0 is not the notified split amount in advance, and continues processing if it is. Similarly, for the consumer device Uj2, the agent device Ua cancels the transaction if T'0 is not the notified split amount in advance, and continues processing if it is the notified split amount in advance.

[0092] In S603, the agent device Ua transmits the public key pkUk of the payee and the public key pkUa of the agent to the consumer device Uj1. Similarly, the agent device Ua transmits the public key pkUk of the payee and the public key pkUa of the agent to the consumer device Uj2.

[0093] In S604, the consumer device Uj1 verifies the public key pkUk and the public key pkUa of the agent to confirm the legitimacy of the agent (billing destination) and the payee. The consumer device Uj1 also calculates Tn:=(pkUk, Sn) according to the basic protocol.

[0094] Similarly, the consumer device Uj2 verifies the public key pkUk and the public key pkUa of the agent to confirm the legitimacy of the agent (billing destination) and the payee. The consumer device Uj2 also calculates T'n:=(pkUk, S'n) according to the basic protocol.

[0095] In S605, the consumer device Uj1 transmits Tn, ..., T1 to the agent device Ua. Similarly, the consumer device Uj2 transmits T'n, ..., T'1 to the agent device Ua.

[0096] In S606, 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 the consumer (Uj1) and the consumer (Uj2), or may be divided into the transaction content M1 of the consumer (Uj1) and the transaction content M2 of the consumer (Uj2). Here, it is assumed that the transaction content M is a combination of the transaction content between the consumer (Uj1) and the consumer (Uj2).

[0097] In S607, the agent apparatus Ua transmits Tn, ..., T0, T'n, ..., T'0, M, and σ to the money receiving apparatus Uk.

[0098] In S608, the money receiving device Uk verifies M and σ. M is verified by checking whether the agreed upon transaction details and M are consistent (whether there are any discrepancies). For σ, signature verification is performed using pkUa. Here, it is assumed that the verification is successful.

[0099] Since verification of Tn, ..., T0 and T'n, ..., T'0 has already been performed by the agent device Ua, the money depositing device Uk only needs to verify Tn, ..., T0, T'n, ..., T'0 as necessary. The money depositing device Uk stores Tn, ..., T0, T'n, ..., T'0.

[0100] (Example 3: Agreement on transaction details) The processing sequence for agreeing on transaction details in Example 3 will be described with reference to Figure 15. As shown in Figure 15, there are remittance device Uj1, agent device Ua, and remittance device Uj2. Here, remittance device Uj1 and remittance device Uj2 are each capable of receiving payments.

[0101] 15, multiple consecutive transactions are carried out between remittance device Uj1 and remittance device Uj2 via agent device Ua (S701, S702). For example, according to the protocol of the basic example, 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. In parallel, 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.

[0102] 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, such as "remittance device Uj1 pays X1 to remittance device Uj2, and remittance device Uj2 pays X2 to remittance device Uj1."

[0103] In S704, when the transaction is completed, 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 the remittance device Uj1 and the remittance device Uj2.

[0104] In the example of Figure 15, the balance of remittance device Uj1 is "-X yen," and the balance of remittance device Uj2 is "+X yen." In other words, by remittance device Uj1 paying X yen to remittance device Uj2, payments / deposits related to multiple transactions can be completed with a single payment.

[0105] (Example 3: Payment) Next, referring to Figure 16, we will explain the processing sequence when making a payment after the processing of Figure 15. Figure 16 shows the case where X yen is paid from remittance device Uj1 to remittance device Uj2 as described above. In Example 3, a financial institution device 30 is used.

[0106] In S801, the remittance apparatus Uj1 transmits the currency T0 and the certificate Auth(pkUj1) to the agent apparatus Ua.

[0107] In S802, the agent device Ua confirms the amount of T0 (payment amount), and if T0=X, cancels the transaction, but if T0=X, continues the processing. Here, it is assumed that T0=X.

[0108] In S803, the agent apparatus Ua transmits the public key pkUj2 of the remittance apparatus Uj2 (recipient) and the public key pkUa of the agent to the remittance apparatus Uj1.

[0109] In S804, the remittance device Uj1 verifies the public key pkUj2 and the public key pkUa of the agent to confirm the legitimacy of the agent (billing destination) and the remittance recipient. The remittance device Uj1 also calculates Tn:=(pkUj2, Sn) according to the basic protocol.

[0110] In S805, the remittance apparatus Uj1 transmits Tn, . . . , T1 to the agent apparatus Ua.

[0111] In S806, 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 "the remitter (Uj1) pays X yen to the remitter (Uj2)." The transaction content M may include multiple transaction contents that ultimately indicate "the remitter (Uj1) pays X yen to the remitter (Uj2)."

[0112] In S807, the agent device Ua transmits M and σ to the financial institution device 30. Upon receiving M and σ, the financial institution device 30 verifies M and σ and stores the transaction details M.

[0113] In S808, the agent apparatus Ua transmits Tn, . . . , T0, M, and σ to the remittance apparatus Uj2.

[0114] In S809, the remittance apparatus Uj2 verifies M and σ. For the verification of M, the remittance apparatus Uj2 checks whether the agreed-upon transaction details and M are consistent (whether there are any discrepancies). For σ, signature verification is performed using pkUa. Here, it is assumed that the verification is successful.

[0115] Since the agent device Ua has already verified Tn, ..., T0, the remittance device Uj2 can verify Tn, ..., T0 as needed. The remittance device Uj2 stores Tn, ..., T0.

[0116] (Device Configuration Example) Fig. 17 shows an example of the functional configuration of the agent device Ua described above. As shown in Fig. 17, 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.

[0117] The agreement processing unit 111 executes processing related to the agreement on the transaction details described in the basic example and the embodiment. The payment processing unit 112 executes processing related to the payment described in the basic example and the embodiment. The storage unit 110 stores the transaction details processed by the agent processing unit 110.

[0118] FIG. 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.

[0119] As shown in FIG. 18, the user device 10 includes an agreement processing unit 210, a remittance processing unit 220, a deposit processing unit 230, and a storage unit 240.

[0120] The agreement processing unit 210 executes processing related to 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 deposit as described in the basic example and the examples. The storage unit 240 stores information used in processing by the agreement processing unit 210, the remittance processing unit 220, and the deposit processing unit 230.

[0121] (Hardware Configuration Example) Any of the devices described in this embodiment (agent device, remittance device, remittance device, user device, etc.) can be realized, for example, by running a program on a computer. This computer may be a physical computer or a virtual machine on the cloud.

[0122] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0123] Fig. 19 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 19 includes 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 further include a GPU.

[0124] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0125] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes 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) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0126] (Effects of the embodiment) As explained above, the technology described in this embodiment allows an agent to act as an intermediary in the electronic currency remittance protocol, confirming the consistency of the transaction details and signing the confirmation details, so that payments can be safely entrusted to the agent.

[0127] The following additional notes are provided regarding the above-described embodiments.

[0128] <Additional Notes> (Additional Item 1) An agent device used in an electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, comprising: a storage unit that stores transaction details agreed upon between the remittance device and the remittance receiving device; and 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. (Additional Item 2) The agent device described in Additional Item 1, where the agent processing unit sends the public key of the remittance receiving device and the public key of the agent device to the remittance device if the processing continues. (Additional Item 3) The agent device described in Additional Item 1, where the agent processing unit verifies the currency, generates a signature for the transaction details, and sends the transaction details and the signature to the remittance device. (Additional Item 4) The agent device described in Additional Item 1, where the agent processing unit confirms whether the total payment amounts in multiple currencies received from multiple remittance devices is correct. (Supplementary Item 5) The agent device according to Supplementary Item 1, wherein the agent processing unit confirms whether the payment amount in the currency received from the remittance device is correct based on income and expenditure determined in multiple transactions between the remittance device and the remittance receiving device. (Supplementary Item 6) An electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, wherein the remittance receiving device and the remittance device agree on a transaction via the agent device, the agent device stores the details of the transaction agreed upon between the remittance device and the remittance receiving device in a storage unit, and the agent device receives currency from the remittance device, confirms whether the payment amount in the currency is correct based on the details of the transaction, and determines whether to continue processing based on the confirmation result. (Supplementary clause 7) An agency processing method executed by an agency device used in an electronic currency system comprising a remittance device, an agency device, and a remittance receiving device, comprising: a step of storing transaction details agreed upon between the remittance device and the remittance receiving device in a storage unit; and 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 processing based on the confirmation result.(Supplementary Item 8) 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 Supplementary Items 1 to 5.

[0129] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0130] REFERENCE SIGNS LIST 10 User device 20 Issuing bank server 30 Financial institution device 110 Agent processing unit 111 Agreement processing unit 112 Payment processing unit 120 Storage unit 210 Agreement processing unit 220 Remittance processing unit 230 Receipt processing unit 240 Storage unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. An agent device used in an electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, the agent device comprising: a storage unit that stores the details of a transaction agreed upon between the remittance device and the remittance receiving 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 details of the transaction, and determines whether to continue processing based on the verification result.

2. The agent device according to claim 1, wherein the agent processing unit, when continuing the processing, transmits the public key of the money receiving device and the public key of the agent device to the money remittance device.

3. The agent device according to claim 1, wherein the agent processing unit verifies the currency, generates a signature for the transaction details, and transmits the transaction details and the signature to the deposit device.

4. The agent device according to claim 1, wherein the agent processing unit verifies whether the total of payment amounts in multiple currencies received from multiple remittance devices is correct.

5. The agent device according to claim 1, wherein the 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.

6. An electronic currency system comprising a remittance device, an agent device, and a remittance receiving device, wherein the remittance receiving device and the remittance device agree on a transaction via the agent device, the agent device stores the details of the transaction agreed upon between the remittance receiving device and the remittance device in a storage unit, the agent device 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.

7. An agency processing method used in an electronic currency system comprising a remittance device, an agency device, and a remittance receiving device, the agency processing method comprising: a step of storing in a storage unit transaction details agreed upon between the remittance device and the remittance receiving device; and an agency processing step of receiving currency from the remittance device, confirming based on the transaction details whether the payment amount in the currency is correct, and determining based on the confirmation result whether to continue processing.

8. A program for causing a computer to function as each unit of the agent device according to any one of claims 1 to 5.

Images