Electronic currency system, currency processing device, currency processing method, and program

Abstract

This electronic currency system includes a determination unit configured to determine, in response to withdrawing of a first electronic currency assigned with information indicating a range corresponding to the face value of the first electronic currency in a space expressing the face value of a certain electronic currency, the presence or absence of double spending of the first electronic currency on the basis of whether or not information on a range at least a part of which overlaps the range corresponding to the face value of the first electronic currency is stored in a withdrawn currency storage unit that stores information indicating a withdrawn range in the space, thereby more efficiently detecting double spending of the electronic currency.

Description

Electronic currency system, currency processing device, currency processing method and program

[0001] The present invention relates to an electronic currency system, a currency processing device, a currency processing method, and a program.

[0002] Research into electronic currency has been ongoing for many years. Experiments are being conducted in which legal tender issuing banks, such as the Bank of Japan, issue electronic currency and circulate it over the Internet through financial institutions. In research into electronic cash, a token-based electronic cash system has been proposed, in which a signature is placed by the issuing bank for each unit of electronic currency, allowing transactions to be completed only between users.

[0003] In token-based electronic cash systems, it is difficult (univocally) to detect duplicate use of electronic currency due to duplication until the currency is returned to the issuing bank, so a system for detecting duplicate use has been proposed (for example, Patent Document 1).

[0004] Okuda, et al., "Considerations on Formal Verification of Double-Spending Detection and Privacy of Token-Based Electronic Cash Systems," Information Processing Society of Japan, Research Report Computer Security (CSEC), 2023-CSEC-100(66), 1-8 (2023-02-27), 2188-8655

[0005] However, in conventional technology, when electronic currency is withdrawn, it is necessary to manage the withdrawn electronic currency in electronic currency units (e.g., 1 yen) in order to check for double-spending, which is not efficient in terms of the size of the database required for such management and the calculation costs for checking for double-spending.

[0006] The present invention has been made in view of the above points, and aims to improve the efficiency of detecting duplicate use of electronic currency.

[0007] In order to solve the above problem, the electronic currency system has a determination unit that is configured to determine whether or not a first electronic currency has been double-spended in response to the redemption of the first electronic currency, based on whether or not information indicating a range that at least partially overlaps with the range corresponding to the face value of the first electronic currency is stored in a redeemed currency memory unit that stores information indicating the redeemed range in the space representing the face value of the first electronic currency.

[0008] This can make it possible to more efficiently detect double-spending of electronic currency.

[0009] 1 is a diagram for explaining an NNL tree. FIG. 1 is a diagram for explaining a method of applying an NNL tree to currency in this embodiment. FIG. 2 is a diagram showing an example of the system configuration of an electronic currency system. FIG. 3 is a functional configuration diagram of an issuing bank server. FIG. 4 is a functional configuration diagram of a root certificate authority server. FIG. 5 is a functional configuration diagram of a financial institution server. FIG. 6 is a functional configuration diagram of an intermediate certificate authority server. FIG. 7 is a functional configuration diagram of a user terminal. FIG. 8 is a sequence diagram showing an example of the flow of currency issuance processing. FIG. 9 is a flowchart showing an example of the processing procedure for generating a currency ID when issuing currency. FIG. 10 is a sequence diagram showing an example of the flow of a withdrawal processing. FIG. 11 is a flowchart showing an example of the processing procedure for currency division processing. FIG. 12 is a sequence diagram showing an example of the flow of a payment processing. FIG. 13 is a sequence diagram showing an example of the flow of an exchange processing. FIG. 14 is a sequence diagram showing an example of the flow of a credit processing. FIG. 15 is a sequence diagram showing an example of the flow of a deposit processing. FIG. 16 is a sequence diagram showing an example of the flow of a withdrawal processing. FIG. 10 is a diagram illustrating an example of the configuration of the refunded currency storage unit 108 in the second embodiment. FIG. 11 is a diagram illustrating an MHTree function of a Merkle tree according to the third embodiment. FIG. 12 is a first diagram illustrating an MHPath function of a Merkle tree according to the third embodiment. FIG. 13 is a diagram illustrating an MHVer function of a Merkle tree according to the third embodiment. FIG. 14 is a diagram illustrating a state where there are eight currencies. FIG. 15 is a diagram illustrating a state where currency additional information including the same signature is added to eight currencies. FIG. 16 is a diagram illustrating an example of the hardware configuration of a computer.

[0010] Hereinafter, an embodiment of the present invention 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.

[0011] (Overview of the First Embodiment) The electronic currency system according to the first embodiment is a system for electronic currency issued by a specific issuing bank. It is proposed that the value of the electronic currency is guaranteed to be the same as that of legal tender. The following explanation will be given using an example of electronic currency with the same value as the Japanese yen, but this is not limiting and the electronic currency may be one with the same value as legal tender in another country, or it may not be one with the same value as legal tender.

[0012] In the electronic currency system according to the first embodiment, a server managed by an issuing bank issues electronic currency (hereinafter simply referred to as currency) with a signature. Transaction history data is managed by a financial institution other than the issuing bank (e.g., a commercial bank). In transactions between users, the users' terminals communicate directly with each other to execute the transaction processing.

[0013] In this embodiment, the amount of currency is expressed as a set of the smallest unit (for example, 1 yen). Decomposition of currency into units smaller than the smallest unit is not permitted. If the smallest unit is 1 yen, expressing the currency as a set of 1 yen units in a fixed denomination system can (effectively) realize a variable denomination system (token division).

[0014] To ensure the authenticity of each currency, a signature from the issuing bank's server is added to each currency, as described above. If currency is represented by a set of 1 yen coins, for example, issuing 10,000 yen requires 10,000 signatures. In this case, the cost of signature generation and verification at the time of issuance, payment, etc. becomes unrealistic. Furthermore, to enable detection of duplicate currency usage, it is conceivable to store already withdrawn currency and, when a new currency is withdrawn, check whether the currency is stored as already withdrawn currency. However, depending on the amount of withdrawal, the number of currency to be withdrawn becomes enormous, and the burden of the confirmation process for duplicate usage also becomes large. Therefore, in this embodiment, a space representing the face value of one currency is constructed using a single tree structure with the smallest unit (1 yen) as a leaf node. This reduces the number of signature generation and verification times at the time of issuance, payment, etc. to one time, and also streamlines currency management for detecting duplicate usage.

[0015] In this embodiment, an NNL tree (reference document [1]) is used as such a tree structure, and a signature is issued only once, and the data size is compressed nonlinearly.

[0016] 1 is a diagram for explaining an NNL tree. In FIG. 1, a pseudo-random number generator G: {0, 1} generates a random number twice as long as an input random number for an ID (an n-bit random number in FIG. 1) as a seed. ｎ →{0, 1} ２ｎ In this example, a 2n-bit ID is generated by applying a pseudo-random number generator G to the first n bits and the last n bits of the 2n bits to generate further 2n-bit random numbers, resulting in a total of four n-bit IDs (random numbers).

[0017] According to the NNL tree, anyone can find the four IDs as long as they know the Seed (in the NNL tree, the random number of each node can be calculated from the random number (Seed) of the root node), so the information of the four IDs (4n bits) can be transmitted using only n bits of information (Seed).

[0018] Although FIG. 1 shows an example in which there are four leaf nodes, the depth of the NNL tree is not limited to a specific one.

[0019] FIG. 2 is a diagram for explaining a method of applying an NNL tree to currency in this embodiment.

[0020] As described above, in this embodiment, currency amounts are represented by an NNL tree. Specifically, a leaf node of an NNL tree corresponds to the smallest unit (e.g., 1 yen), and the number of leaf nodes belonging to a certain NNL tree determines the currency amount corresponding to the NNL tree. However, assuming that the NNL tree is a binary tree, this allows only amounts in powers of 2 to be expressed. Therefore, the leaf node corresponding to a currency can be specified. Specifically, by making it possible to specify information indicating a range of leaf nodes corresponding to a currency among all leaf nodes of the NNL tree, it is possible to express that the currency corresponding to the NNL tree is the number of all leaf nodes included in the range × 1 yen. In this embodiment, an example is shown in which the start point and end point of the range are used as information indicating such a range. The start point refers to the leaf node that is the start position of the range. The end point refers to the leaf node that is the end position of the range. It is assumed that either the start point or the end point is the leaf node at the end (first or last) in the order of the leaf nodes. However, the information indicating the range is not limited to the start point and the end point. For example, all leaf nodes belonging to the range may be specified, or the start point and the size of the range (i.e., the amount) or the end point and the size of the range may be specified.

[0021] For example, in a binary NNL tree with a depth of 10, the number of leaf nodes is 1024. To represent 1000 yen, for example, the start point can be set to 1 and the end point to 1000.

[0022] As described above, anyone can derive all leaf nodes of an NNL tree if they know the seed and depth. Therefore, in this embodiment, the amount of one currency is expressed by a set of four parameters.

[0023] {Seed of NNL tree, depth of the NNL tree, start point, end point} Hereinafter, a set of these four parameters will be referred to as a "currency ID."

[0024] A signature for a currency (e.g., a signature by an issuer or a divider) is realized by signing in units of seeds in the NNL tree corresponding to the currency. Therefore, the number of signatures can be set per currency (NNL tree) rather than per minimum unit of currency (e.g., 1 yen).

[0025] For example, if the start point of the NNL tree in FIG. 2 is ID1 and the end point is ID8, the NNL tree represents 8 yen. If it is desired to divide 4 yen from ID1 to ID4 from this 8 yen, it is conceivable to use the ID (random number) corresponding to node n1, which is the ancestor node of all ID1 to ID4, as the root node of the subtree (NNL tree) corresponding to the 4 yen after division. In this case, the currency ID of the 4 yen currency after division will be as follows: {01110...1, 2, ID1, ID4} By calculating the seed of the root node of the subtree after division, it is possible to reduce the number of times to calculate the random number corresponding to each node of the subtree thereafter. In this case, the currency issued by the issuing bank (T ０ ) can be traced based on the signature history.

[0026] However, the root node of the original NNL tree may be used as the root node of the NNL tree after division. In this case, the currency ID of the 4 yen currency after division will be as follows: {01010...1, 3, ID1, ID4} In this case, the currency issued by the issuing bank (T ０ ) for verification, the calculation efficiency is good. In this embodiment, the case where the latter (the root node of the original NNL tree is used as the root node of the NNL tree after division) is described, but the former (the smallest NNL tree including a leaf node after division is used as the NNL tree after division) may also be used.

[0027] 2, for convenience, random numbers corresponding to each node are shown, but the random numbers corresponding to each node do not need to be managed until the currency (NNL tree) is divided. In other words, when dividing, the random number of the seed after division may be calculated from the seed of the NNL tree before division.

[0028] Furthermore, the NNL tree is not limited to a binary tree, but may be a 2-, 5-, or 10-ary tree. By repeating 2-branch / 5-branch..., it is possible to generate an NNL tree whose number of leaf nodes exactly matches the amount of cash in everyday life, such as 5,000 yen / 1,000 yen. In this case, at the 5-branch point, the pseudo-random number generator G ５ : {0, 1} ｎ →{0, 1} ５ｎ At the 10-branch point, a pseudorandom number generator G １０ : {0, 1} ｎ →{0, 1} １０ｎ Just use

[0029] The configuration and operation of the first embodiment will be described below.

[0030] (Details of the First Embodiment) Figure 3 is a diagram showing an example of the system configuration of an electronic currency system. The electronic currency system 1 according to the first embodiment includes an issuing bank server 10, a root certificate authority server 11, a financial institution server 20, an intermediate certificate authority server 25, and a user terminal 30. These devices are connected to each other so as to be able to communicate with each other via a communication network such as the Internet.

[0031] The issuing bank server 10 is an information processing device managed by the issuing bank that issues the currency. The issuing bank server 10 adds signature data to message data indicating the issuance of currency and transmits the message data to the financial institution server 20. The issuing bank server 10 also has a function to accept a refund request from the financial institution server 20.

[0032] The root certification authority server 11 is an information processing device that has the function of a root certification authority in cryptographic communication. The root certification authority server 11 may be realized by the same hardware as the issuing bank server 10, and is assumed to be managed by the issuing bank, but is not limited to this.

[0033] As a preparation step for issuing currency, the root certification authority server 11 generates a root certification key, issues a root certificate, and transmits it to the intermediate certification authority server 12. The root certification authority server 11 also authenticates each financial institution, generates financial institution public key certificate issuance information, and transmits the generated financial institution public key certificate issuance information to the issuing bank server 10.

[0034] The financial institution server 20 is an information processing device managed by a financial institution (for example, a commercial bank). The financial institution server 20 is authenticated by the root certification authority server 11 and receives a request for currency issuance from the issuing bank server 10.

[0035] The financial institution server 20 also accepts transaction requests such as withdrawals, currency exchange, deposits, and credit from the user terminal 30. Furthermore, the financial institution server 20 requests the issuing bank server 10 to make a refund.

[0036] In the following description, when distinguishing between the financial institution servers 20, the financial institution servers 20 will be referred to as financial institution server 20-1, financial institution server 20-2, and so on.

[0037] The intermediate certification authority server 25 is an information processing device that has the function of an intermediate certification authority in cryptographic communication. The intermediate certification authority server 25 may be realized by the same hardware as the financial institution server 20, and is assumed to be managed by the financial institution, but is not limited to this.

[0038] As a preparation step for issuing the currency, the intermediate certificate authority server 25 generates an intermediate authentication key, issues an intermediate certificate, and transmits it to the user terminal 30. The intermediate certificate authority server 25 also authenticates each user and generates user public key certificate issuance information.

[0039] In the following description, when distinguishing between the intermediate certification authority servers 25, the intermediate certification authority servers 25 will be referred to as intermediate certification authority server 25-1, intermediate certification authority server 25-2, and so on.

[0040] The user terminal 30 is an information processing device used by users (individual consumers, stores, etc.) who use currency. Before starting a transaction, the user terminal 30 is authenticated by the intermediate certificate authority server 25. The user terminal 30 also requests transactions such as withdrawals, currency exchanges, deposits, and credit from the financial institution server 20.

[0041] In the following description, when distinguishing between the user terminals 30, the user terminals 30 will be referred to as user terminal 30-1, user terminal 30-2, and so on.

[0042] A user terminal 30 (e.g., user terminal 30-1) requests payment from another user terminal 30 (e.g., user terminal 30-2) or accepts a payment request. Here, a payment request means a request to accept execution of a "payment" transaction in which a user pays a counterparty, but does not mean a request from the counterparty to make payment to the user.

[0043] (Example of Functional Configuration of Each Device According to First Embodiment) Next, an example of the functional configuration of each device according to the first embodiment will be described.

[0044] 4 is a functional block diagram of the issuing bank server 10. The issuing bank server 10 includes a currency issuance key generation unit 101, a currency issuance certificate issuance unit 102, a financial institution public key certificate issuance information acquisition unit 103, a currency issuing unit 104, a refund acceptance unit 105, a currency issuance key storage unit 106, an issued currency storage unit 107, and a refunded currency storage unit 108.

[0045] The currency issuance key generation unit 101 generates cryptographic key data (hereinafter referred to as a currency issuance key) for verifying the validity of message data indicating the issuance of currency (hereinafter referred to as a currency issuance message). The currency issuance key includes a private key and a public key.

[0046] The currency issuance certificate issuing unit 102 generates data indicating a certificate for certifying the public key of the currency issuance key (hereinafter referred to as the currency issuance certificate), and transmits the generated currency issuance certificate to each financial institution server 20 and each user terminal 30.

[0047] The financial institution public key certificate issuance information acquisition unit 103 acquires financial institution public key certificate issuance information from the root certification authority server 11. The financial institution public key certificate issuance information will be described later.

[0048] The currency issuing unit 104 generates a currency issuance message using the currency issuance key and the financial institution public key certificate issuance information, and transmits the generated currency issuance message to the financial institution server 20 .

[0049] The refund receiving unit 105 receives refunds from the financial institution server 20 and stores the refunded currency in the refunded currency storage unit 108. A refund is a transaction in which each financial institution deposits currency that it will not use for the time being with the issuing bank and returns it to circulation.

[0050] The currency issuing key storage unit 106 stores the currency issuing key generated by the currency issuing key generation unit 101 .

[0051] The issued currency storage unit 107 stores information about the currency related to the currency issuance message generated by the currency issuing unit 104 (i.e., the currency to be issued).

[0052] The refunded currency storage unit 108 stores the currency for which the refund acceptance unit 105 has accepted the refund (hereinafter referred to as the refunded currency).

[0053] 5 is a functional block diagram of the root certification authority server 11. The root certification authority server 11 includes a root certification key generation unit 111, a root certificate issuance unit 112, a financial institution authentication unit 113, a financial institution public key certificate issuance information transmission unit 114, a root certification key storage unit 115, and a financial institution public key certificate issuance information storage unit 116.

[0054] The root certification key generator 111 generates encryption key data (hereinafter referred to as a root certification key) for verifying the legitimacy of the root certification authority. The root certification key includes a private key and a public key.

[0055] The root certificate issuance unit 112 issues certificate data (hereinafter referred to as a root certificate) for verifying the legitimacy of certificate data (hereinafter referred to as an intermediate certificate) for verifying the legitimacy of an intermediate certification authority, and transmits the certificate data to each intermediate certification authority server 25.

[0056] The financial institution authentication unit 113 receives encryption key data (hereinafter referred to as the financial institution key) for verifying the legitimacy of each financial institution from the financial institution server 20 and accepts an authentication request. The financial institution authentication unit 113 then generates data indicating a certificate for certifying the public key of the financial institution key (hereinafter referred to as the financial institution public key certificate) and transmits the generated financial institution public key certificate to the financial institution server 20 that requested authentication. Furthermore, the financial institution authentication unit 113 generates information indicating the issuance of the financial institution public key certificate (hereinafter referred to as the financial institution public key certificate issuance information).

[0057] Financial institution public key certificate issuance information transmitter 114 transmits the generated financial institution public key certificate issuance information to issuing bank server 10. Note that if issuing bank server 10 and root certification authority server 11 are realized by the same hardware, financial institution public key certificate issuance information transmitter 114 is not necessary.

[0058] The root authentication key storage unit 115 stores the root authentication key generated by the root authentication key generation unit 111 .

[0059] The financial institution public key certificate issuance information storage unit 116 stores the financial institution public key certificate issuance information generated by the financial institution authentication unit 113 .

[0060] 6 is a functional block diagram of the financial institution server 20. The financial institution server 20 includes a currency issuance certificate issuance acceptance unit 201, a financial institution key generation unit 202, a financial institution authentication request unit 203, a currency issuance acceptance unit 204, a withdrawal acceptance unit 205, an update processing unit 206, a currency exchange / deposit acceptance unit 207, a payment request unit 208, a payment acceptance unit 209, a credit acceptance unit 210, a refund request unit 211, a currency issuance certificate storage unit 212, a financial institution key storage unit 213, a financial institution public key certificate storage unit 214, an unused currency storage unit 215, a currency in use storage unit 216, an updated currency storage unit 217, and a used currency storage unit 218.

[0061] The currency issuance certificate issuance reception unit 201 receives a request for the issuance of a currency issuance certificate from the issuing bank server 10 .

[0062] The financial institution key generation unit 202 generates a financial institution key, which includes a private key and a public key.

[0063] The financial institution authentication request unit 203 transmits the financial institution key to the root certification authority server 11 to request authentication of the financial institution, and receives a financial institution public key certificate from the root certification authority server 11 .

[0064] The currency issuance reception unit 204 receives a currency issuance request from the issuing bank server 10. Specifically, the currency issuance reception unit 204 receives a currency issuance message from the issuing bank server 10 and verifies the signature of the received currency issuance message using the public key included in the currency issuance certificate.

[0065] The withdrawal acceptance unit 205 accepts a withdrawal request from the user terminal 30 and transmits currency to the user terminal 30 .

[0066] The update processing unit 206 updates used currency (hereinafter referred to as used currency) as necessary in response to a withdrawal request from the user terminal 30. Specifically, the update processing unit 206 deletes information (currency additional information) added to the used currency. The currency additional information is added by a payment transaction, which will be described later. The withdrawal acceptance unit 205 transmits unused currency (hereinafter referred to as unused currency) or the currency updated by the update processing unit 206 to the user terminal 30.

[0067] The currency exchange / deposit reception unit 207 accepts requests for currency exchange or deposits from the user terminal 30. Specifically, when the currency exchange / deposit reception unit 207 accepts a request for currency exchange from the user terminal 30, the payment reception unit 209 accepts payment of the amount to be exchanged, and the payment request unit 208 requests multiple payments that total the amount to be exchanged. Also, when the currency exchange / deposit reception unit 207 accepts a request for deposit, the payment reception unit 209 accepts payment of the amount to be deposited.

[0068] The credit acceptance unit 210 accepts a credit request by receiving currency from the user terminal 30. The credit acceptance unit 210 determines whether the currency is a currency in use (hereinafter referred to as a currency in use) and transmits the determination result to the user terminal 30.

[0069] The refund request unit 211 sends the currency to the issuing bank server 10 to request a refund.

[0070] The currency issuance certificate storage unit 212 stores the currency issuance certificate whose issuance has been accepted by the currency issuance certificate issuance acceptance unit 201 .

[0071] The financial institution key storage unit 213 stores the financial institution key generated by the financial institution key generation unit 202 .

[0072] The financial institution public key certificate storage unit 214 stores the financial institution public key certificate that the financial institution authentication request unit 203 receives from the root certification authority server 11 .

[0073] The unused currency storage unit 215 stores the currency accepted for issuance by the currency issuance acceptance unit 204 as unused currency.

[0074] The currency in use storage unit 216 stores the currency for which the withdrawal acceptance unit 205 accepts a withdrawal as a currency in use.

[0075] The updated currency storage unit 217 stores the currency updated by the update processing unit 206 (hereinafter referred to as updated currency) in the state before the update.

[0076] The used currency storage unit 218 stores currencies that have been used but are not currently in use. Specifically, the used currency storage unit 218 stores, as used currency, the currency that is received when the exchange / deposit receiving unit 207 receives a request for exchange or deposit and the payment receiving unit 209 receives payment.

[0077] 7 is a functional block diagram of the intermediate certification authority server 25. The intermediate certification authority server 25 includes an intermediate authentication key generation unit 251, an intermediate certificate issuance unit 252, a user authentication unit 253, an intermediate authentication key storage unit 254, and a user public key certificate issuance information storage unit 255.

[0078] The intermediate authentication key generation unit 251 generates encryption key data (hereinafter referred to as intermediate authentication key) for verifying the legitimacy of the intermediate certificate authority. The intermediate authentication key includes a private key and a public key.

[0079] The intermediate certificate issuing unit 252 issues an intermediate certificate and transmits it to each user terminal 30 .

[0080] The user authentication unit 253 receives encryption key data (hereinafter referred to as user key) for verifying the legitimacy of each user from the user terminal 30 and accepts an authentication request. The user authentication unit 253 then generates data indicating a certificate for certifying the public key of the user key (hereinafter referred to as user public key certificate) and transmits the generated user public key certificate to the user terminal 30 that requested authentication. Furthermore, the user authentication unit 253 generates information indicating the issuance of the user public key certificate (hereinafter referred to as user public key certificate issuance information).

[0081] The intermediate authentication key storage unit 254 stores the intermediate authentication key generated by the intermediate authentication key generation unit 251 .

[0082] The user public key certificate issuance information storage unit 255 stores the user public key certificate issuance information generated by the user authentication unit 253 .

[0083] 8 is a functional configuration diagram of user terminal 30. User terminal 30 includes currency issuance certificate issuance acceptance unit 301, intermediate certificate issuance acceptance unit 302, user key generation unit 303, user authentication request unit 304, withdrawal request unit 305, payment request unit 306, payment acceptance unit 307, exchange / deposit request unit 308, credit request unit 309, currency issuance certificate storage unit 310, intermediate certificate storage unit 311, user key storage unit 312, user public key certificate storage unit 313, and user currency storage unit 314.

[0084] The currency issuance certificate issuance acceptance unit 301 accepts the issuance of a currency issuance certificate from the issuing bank server 10 .

[0085] The intermediate certificate issuance acceptance unit 302 accepts the issuance of an intermediate certificate from the intermediate certificate authority server 25 .

[0086] The user key generation unit 303 generates a user key, which includes a private key and a public key.

[0087] The user authentication request unit 304 transmits the user key to the intermediate certification authority server 25 to request authentication of the user, and receives the user public key certificate from the intermediate certification authority server 25 .

[0088] The withdrawal request unit 305 specifies the face value and requests a withdrawal from the financial institution server 20. The withdrawal request unit 305 receives the withdrawn currency from the financial institution server 20.

[0089] The payment request unit 306 transmits the currency to be paid and requests payment from the financial institution server 20 or another user terminal 30 .

[0090] The payment acceptance unit 307 receives the currency to be paid and accepts the payment from the financial institution server 20 or another user terminal 30 .

[0091] The exchange / deposit request unit 308 requests exchange or deposit from the financial institution server 20. Specifically, when the exchange / deposit request unit 308 requests exchange and the financial institution server 20 accepts the request, the payment request unit 306 transmits the currency of the face value to be exchanged and requests payment from the financial institution server 20, and the payment acceptance unit 307 accepts from the financial institution server 20 a plurality of payments whose total is the face value to be exchanged. Furthermore, when the exchange / deposit request unit 308 requests a deposit and the financial institution server 20 accepts the request, the payment request unit 306 transmits the currency to be deposited and requests payment from the financial institution server 20.

[0092] The credit request unit 309 transmits currency to request credit from the financial institution server 20 and receives the credit result.

[0093] The currency issuance certificate storage unit 310 stores the currency issuance certificate whose issuance has been accepted by the currency issuance certificate issuance acceptance unit 301 .

[0094] The intermediate certificate storage unit 311 stores the intermediate certificate whose issuance has been accepted by the intermediate certificate issuance acceptance unit 302 .

[0095] The user key storage unit 312 stores the user key generated by the user key generation unit 303 .

[0096] The user public key certificate storage unit 313 stores the user public key certificate received by the user authentication request unit 304 .

[0097] The user currency storage unit 314 stores the currency currently used by the user. Specifically, the user currency storage unit 314 stores the currency that the withdrawal request unit 305 received from the financial institution server 20 and the currency that the payment acceptance unit 307 received from the financial institution server 20 or another user terminal 30.

[0098] (Operation of the Electronic Currency System According to the First Embodiment) Next, the operation of the electronic currency system 1 according to the first embodiment will be described. ０ , each financial institution B ｉ (B ０ , B １ , ...), root certification authority A ０ , each intermediate certification authority A ｉ (A ０ , A １ , ...), each user is a U ｊ (U ０ , U １ The concept will be explained using symbols such as , ....

[0099] 9 is a sequence diagram showing an example of the flow of currency issuing processing. The currency issuing processing is started periodically or in response to an operation by a person in charge.

[0100] The currency issuing key generation unit 101 of the issuing bank server 10 generates a currency issuing key (step S101). Specifically, the currency issuing key generation unit 101 generates a currency issuing key pair (secret key skB ０ｖｙ and the public key pkB ０ｖｙ ) to generate the

[0101] Then, the currency issuance certificate issuing unit 102 issues the public key pkB ０ｖｙ Certificate of issuance of currency CERT (pkB) ０ｖｙ ) to each financial institution server 20 (step S102), and then to each user terminal 30 (step S103). The currency issuance certificate issuance acceptance unit 201 of each financial institution server 20 sends the currency issuance certificate CERT(pkB ０ｖｙ ) and stores it in the currency issuance certificate storage unit 212. In addition, the currency issuance certificate issuance reception unit 301 of each user terminal 30 receives the currency issuance certificate CERT(pkB ０ｖｙ) and stores it in the currency issuance certificate storage unit 310.

[0102] The issuance amount v is a multiple of the smallest unit (for example, 1 yen). For example, when issuing currency of 10,000 yen in 2021, the currency issuance certificate issuing unit 102 issues a currency issuance certificate CERT(pkB ０（１００００円）（２０２１年） ) to each financial institution server 20 and each user terminal 30.

[0103] The currency issuance certificate issuing unit 102 issues the currency issuance certificate CERT(pkB ０ｖｙ ) does not have to be sent directly to each financial institution server 20 and each user terminal 30, but may be uploaded to a server device or the like that is publicly available on a communication network, and then downloaded to each financial institution server 20 and each user terminal 30.

[0104] Next, the root authentication key generation unit 111 of the root authentication authority server 11 generates a root authentication key (step S104). ０ and the public key pkA ０ Next, the root certificate issuing unit 112 generates the private key skA. ０ and sign it as root certificate Auth(pkA ０ ) and transmits it to each financial institution server 20 (step S105).

[0105] The root certificate issuing unit 112 directly issues the root certificate Auth(pkA ０ ) does not have to be transmitted to each financial institution server 20, but may be uploaded to a server device or the like that is publicly available on a communication network and then downloaded to each financial institution server 20.

[0106] Next, the intermediate authentication key generation unit 251 of the intermediate authentication authority server 25 generates an intermediate authentication key (step S106). ｉ and the public key pkA ｉ Includes.

[0107] Next, the intermediate certificate issuing unit 252 issues the private key skA ｉ and the root certificate Auth(pkA ０) to authenticate the intermediate certificate Auth(pkA ｉ , pkA ０ ) is generated. ｉ , pkA ０ ) is Auth(pkA ｉ Then, the intermediate certificate issuance unit 252 generates the intermediate certificate Auth(pkA ｉ ) to each user terminal 30 (step S107). The intermediate certificate issuance acceptance unit 302 of each user terminal 30 transmits the intermediate certificate Auth(pkA ｉ ) and stores it in the intermediate certificate storage unit 311.

[0108] The intermediate certificate issuing unit 252 directly issues the intermediate certificate Auth(pkA ｉ ) does not have to be transmitted to each user terminal 30, but may be uploaded to a server device or the like that is publicly available on a communication network, and then downloaded to each user terminal 30.

[0109] Next, the user key generation unit 303 of the user terminal 30 generates a user key (step S108). ｊ and the public key pkU ｊ Next, the user authentication request unit 304 receives the public key pkU ｊ to request user authentication from the intermediate certification authority server 25 (step S109).

[0110] The user authentication unit 253 of the intermediate certificate authority server 25 authenticates the root certificate Auth(pkA ０ ) and intermediate certificate Auth(pkA ｉ ) to obtain the user public key certificate Auth(pkU ｊ , pkA ｉ , pkA ０ ) is generated (step S110). Hereinafter, the user public key certificate Auth(pkU ｊ , pkA ｉ , pkA ０ ) is Auth(pkU ｊ The user authentication unit 253 generates the user public key certificate Auth(pkU ｊ) to the user terminal 30 (step S111). ｊ and the public key pkU ｊ and the user public key certificate Auth(pkU ｊ ) is held.

[0111] Furthermore, the user authentication unit 253 receives user public key certificate issuance information (U ｊ , pkU ｊ , Auth(pkU ｊ )) and store it in the user public key certificate issuance information storage unit 255. ｊ , pkU ｊ , Auth(pkU ｊ )) is the personal information of the user ｊ Contains:

[0112] Next, the financial institution key generation unit 202 of the financial institution server 20 generates a financial institution key (step S112). ｉ and the public key pkB ｉ Next, the financial institution authentication request unit 203 receives the public key pkB ｉ to request financial institution authentication from the root certification authority server 11 (step S113).

[0113] The financial institution authentication unit 113 of the root certificate authority server 11 receives the root certificate Auth(pkA ０ ) to obtain the financial institution public key certificate Auth(pkB ｉ , pkA ０ ) is generated (step S114). ｉ , pkA ０ ) is Auth(pkB ｉ The financial institution authentication unit 113 generates the financial institution public key certificate Auth(pkB ｉ ) to the financial institution server 20 (step S115). ｉ and the public key pkB ｉ and financial institution public key certificate Auth(pkB ｉ ) is held.

[0114] Furthermore, the financial institution authentication unit 113 receives financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) is generated and stored in the financial institution public key certificate issuance information storage unit 116. ｉ , pkB ｉ , Auth(pkB ｉ )) is the institution information B about financial institutions ｉ Then, the financial institution public key certificate issuance information sending unit 114 sends the financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) is sent to the issuing bank server 10 (step S116).

[0115] The financial institution public key certificate issuance information acquisition unit 103 of the issuing bank server 10 acquires the financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) to get the

[0116] The order of the processes from step S108 to step S111 and the processes from step S112 to step S116 is merely an example, and may be reversed. The processes from step S108 to step S111 are executed individually by each user terminal 30. The processes from step S112 to step S116 are executed individually by each financial institution server 20.

[0117] Furthermore, the user terminal 30 may execute the processes from step S108 to step S111 multiple times to add a user key.

[0118] Next, the currency issuing unit 104 of the issuing bank server 10 issues the financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) and the currency ID based on the issued amount v. ０ , Issue year y, Financial institution B ｉ A currency issuance message (id０ , y, B ｉ , pkB ｉ ) and generate a currency ID id ０ is recorded in the issued currency storage unit 107 (step S117). Therefore, a currency ID is recorded in the issued currency storage unit 107 for each issued currency. The structure of the currency ID is as explained in FIG. 2, and the method of generating the currency ID will be described later. Here, the currency issuing unit 104 records the private key skB of the currency issuing key stored in the currency issuing key storage unit 106. ０ｖｙ Using (id ０ , y, B ｉ , pkB ｉ The currency issuing unit 104 signs the signature S ０ The currency issuance message (id ０ , y, B ｉ , pkB ｉ ) to the financial institution server 20 (step S118). As will be apparent from the following description, the currency issuance message is used to generate the currency to be issued. Therefore, generating the currency issuance message essentially corresponds to issuing the currency.

[0119] The currency issuance acceptance unit 204 of the financial institution server 20 issues the signature S ０ The currency issuance message (id ０ , y, B ｉ , pkB ｉ ) and stores the currency issuance certificate CERT(pkB ０ｖｙ ) public key pkB ０ｖｙ Use the signature S ０ Then, the currency issuance acceptance unit 204 verifies the currency T ０ :=(id ０ , y, B ｉ , pkB ｉ , S ０ ) is generated and stored in the unused currency storage unit 215.

[0120] 9 illustrates an example in which the root authentication key, intermediate authentication key, user key, financial institution key, and certificates for these public keys are generated in conjunction with the issuance of currency, but these keys and certificates may be generated at a time other than the issuance of currency. These keys and certificates may be generated only once or may be updated periodically. In other words, the same keys and certificates may be used for multiple currencies.

[0121] The generation of the currency ID in the generation of the currency issuance message in step S117 will be described.

[0122] FIG. 10 is a flowchart illustrating an example of a processing procedure for generating a currency ID when issuing currency.

[0123] In step S121, the currency issuing unit 104 calculates the depth of the smallest NNL tree that includes leaf nodes equal to or greater than the number corresponding to the issuance amount v. Calculating this depth essentially corresponds to generating the structure of the NNL tree. Leaf nodes equal to or greater than the number corresponding to the issuance amount v refer to leaf nodes whose number can represent the issuance amount v, and refer to leaf nodes whose number is equal to or greater than the value obtained by dividing the issuance amount v by the smallest unit (e.g., 1 yen). If the smallest unit is 1 yen and v = 8 yen, eight leaf nodes are required. If the NNL tree is a binary tree, the depth of a binary tree that can include eight leaf nodes is 3 or greater. Therefore, 3, the smallest value among values ​​equal to or greater than 3, becomes the depth of the NNL tree.

[0124] Next, the currency issuing unit 104 generates a random number to be used as a seed for the NNL tree (S122).

[0125] Next, the currency issuing unit 104 determines the start point and end point of a leaf node corresponding to the issuance amount v among the leaf nodes of the NNL tree (S123). The start point and end point are determined so that one of the start point and end point is a leaf node at the end of the NNL tree, and the set of consecutive leaf nodes from the start point to the end point matches the issuance amount v. Note that the values ​​of the start point and end point may be expressed by values ​​indicating the order in the leaf nodes of the NNL tree. In other words, random numbers corresponding to the start point and end point in the NNL tree do not need to be calculated.

[0126] Next, the currency issuing unit 104 generates a set of {Seed, depth, start point, end point} as a currency ID.

[0127] FIG. 11 is a sequence diagram showing an example of the flow of a withdrawal process. ｊ The process is started in response to an operation instructing withdrawal of the card.

[0128] The withdrawal request unit 305 of the user terminal 30 receives the denomination information indicating the denomination v of the withdrawal and the public key pkU of the user key stored in the user key storage unit 312. ｊ and requests the financial institution server 20 to withdraw the money (step S201).

[0129] The withdrawal acceptance unit 205 of the financial institution server 20 accepts the withdrawal (step S202). Specifically, the withdrawal acceptance unit 205 receives unused currency T ０ and obtain the currency additional information T １ :=(id １ , pkU ｊ , S １ ) added to the currency in use (T １ , T ０ ) and stored in the currency-in-use storage unit 216. １ is the private key skB of the financial institution key ｉ (id １ , pkU ｊ , T ０ ) is a signature for id １ is the currency in use (T １ , T ０ Currency ID of the currency to be transferred, based on the face value of the currency T ０ If id matches the value v, １ The value of is the currency T ０ id, which is the currency ID of ０ Also, multiple currencies T ０ If the set of currencies T ０ Currency (T １ , T ０ ) can be generated. １ ID １ The value of the corresponding id １It can be the same as above.

[0130] On the other hand, currency T ０ If the face value of v exceeds the face value of v, or if multiple currencies T ０ If the set of currency T exceeds the face value v, the withdrawal acceptance unit 205 ０ Part of the currency (T １ , T ０ For example, if the face value v is 1000 yen and the currency T ０ is 5,000 yen, the withdrawal acceptance unit 205 ０ Divide 1000 yen from the amount and make 1000 yen currency (T １ , T ０ ) is generated. For example, if the face value v is 7000 yen, ０ is 5,000 yen, the withdrawal acceptance unit 205 ０ Divide 2000 yen from one of the two and get 2000 yen currency (T １ , T ０ ) to generate the currency T ０ The division of the currency T ０ Contains id ０ This is realized by dividing the NNL tree as follows: ∑ ...

[0131] In this way, each time currency is transferred by withdrawal, payment, etc., currency additional information signed by the transfer source is cumulatively added to the currency. Therefore, the currency additional information can be said to be information indicating the history of currency transfers.

[0132] Next, the withdrawal acceptance unit 205 receives the current currency (T １ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the current currency (T １ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) and verify the currency in use (T １ , T ０ ) is stored in the user currency storage unit 314.１ , T ０ ) may be called unused currency.

[0133] In step S202, the withdrawal acceptance unit 205 may use used currency stored in the used currency storage unit 218 instead of unused currency stored in the unused currency storage unit 215, as necessary. In this case, the update processing unit 206 updates the used currency to a currency from which the currency additional information has been deleted. The withdrawal acceptance unit 205 determines whether to use used currency in accordance with predetermined conditions. For example, the withdrawal acceptance unit 205 may use used currency when the amount of data of used currency reaches or exceeds a threshold.

[0134] For example, the withdrawal acceptance unit 205 receives the used currency (T ｎ , ..., T ０ ) is used for withdrawal, the update processing unit 206 updates the currency before the update (T ｎ , ..., T ０ ) in the updated currency storage unit 217. Then, the update processing unit 206 stores the used currency (T ｎ , ..., T ０ ) and currency additional information (T ｎ , ..., T １ ) has been removed from the currency T ０ Then, the withdrawal acceptance unit 205 updates the updated currency T ０ Currency information added to T ｎ＋１ :=(id ｎ＋１ , pkU ｊ , S ｎ＋１ ) added to the currency in use (T ｎ＋１ , T ０ ) is stored in the currency in use storage unit 216. ｎ＋１ The value (content) of T ｎ The currency ID may be the same as that included in

[0135] Next, the withdrawal acceptance unit 205 receives the current currency (T ｎ＋１ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the current currency (Tｎ＋１ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) and verify the currency in use (T ｎ＋１ , T ０ ) is stored in the user currency storage unit 314.

[0136] The update processing unit 206 may also update a currency that has already been updated one or more times. In this case, the update processing unit 206 updates the currency (T ｎ , ...T １ , T ０ ) to the currency before this update (T ｎ＋ｋ , ..., T ｎ＋１ , T ０ ) combined currency (T ｎ＋ｋ , ..., T １ , T ０ ) is stored in the updated currency storage unit 217.

[0137] The currency division process executed when currency division is necessary in step S202 will be described in detail below. Fig. 12 is a flowchart illustrating an example of the procedure for currency division process.

[0138] In step S211, the withdrawal receiving unit 205 calculates the depth of the smallest NNL tree (hereinafter referred to as the "destination NNL tree") that contains leaf nodes whose number is equal to or greater than the withdrawal denomination v. The method for calculating the depth is the same as in step S121 of FIG.

[0139] Next, the withdrawal acceptance unit 205 determines a node to be the root node of the split NNL tree from among the nodes of the NNL tree (hereinafter referred to as the "original NNL tree") that serves as the currency ID of the currency to be split (S212). Here, the original NNL tree is a subtree of the original NNL tree. Since the depth of the original NNL tree has been calculated, it is possible to identify which layer of the original NNL tree the root node of the split NNL tree belongs to. The withdrawal acceptance unit 205 determines the node located at the end of the layer (the ancestor of the starting point of the original NNL tree) as the root node of the split NNL tree. For example, if the split described in FIG. 2 is performed, node N2 in FIG. 2 is determined to be the root node of the split NNL tree.

[0140] Next, the withdrawal acceptance unit 205 calculates a random number corresponding to the root node (i.e., the seed of the NNL tree to be split) based on the seed of the original NNL tree (S213). Specifically, as described in Fig. 1, the seed of the NNL tree to be split can be calculated by recursively applying the pseudo-random number generator G to the seed of the original NNL tree.

[0141] In step S211, the withdrawal reception unit 205 determines the start and end points of the leaf node of the NNL tree that corresponds to the face value v as the currency ID of the currency to be divided (S211). The method for determining such a leaf node may be the same as the method described in step S123 of Figure 10.

[0142] Next, the withdrawal acceptance unit 205 transfers the set of {Seed of the original NNL tree, depth of the original NNL tree, start point, end point} to the currency ID of the destination currency (i.e., the currency additional information T １ :=(id １ , pkU ｊ , S １ ) id １ (S212).

[0143] Next, the withdrawal acceptance unit 205 receives the currency from which the money is to be divided (the T ０) corresponds to the balance (amount minus face value v), the next leaf node that is the end point of the currency to be divided is identified in the original NNL tree (S213).

[0144] Next, the withdrawal acceptance unit 205 associates {Seed of the original NNL tree, depth of the original NNL tree, the next leaf node, and end point of the original NNL tree} with the original currency as a temporary currency ID (S214). This temporary currency ID is used as the currency ID of the currency additional information when the remaining amount of the original currency is transferred by withdrawal, payment, etc.

[0145] FIG. 13 is a sequence diagram showing an example of the flow of the payment process (transmission process from the remitter to the recipient) according to the first embodiment. ｊ User U on the receiving side ｋ It is initiated in response to an operation instructing payment to.

[0146] The user terminal 30-1 is a user U ｊ The user terminal 30-2 is operated by the user U ｋ The payment request unit 306 of the user terminal 30-1 receives a payment amount v or more in a currency (T ｎ－１ , ..., T ０ ) from the currency T ０ And, T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ), and the user public key certificate Auth(pkU ｊ ) to request payment from the user terminal 30-2 (step S301). ０ is the currency (T ｎ－１ , ..., T ０ It does not represent the current face value of the currency (T ｎ－１ , ..., T ０ )'s current face value is T ｎ－１ ID ｎ－１ It can be derived from the start and end points of the NNL tree as:

[0147] The payment acceptance unit 307 of the user terminal 30-2 accepts the payment (step S302). ０ And, T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ) S ｎ－１ and the user public key certificate Auth(pkU ｊ ) is verified. Here, the payment acceptance unit 307 verifies the signature data included in the currency when verifying the currency. For example, the payment acceptance unit 307 verifies the signature data included in the currency. ０ :=(id ０ , y, B ｉ , pkB ｉ , S ０ ) signature S ０ In addition, the payment acceptance unit 307 verifies T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ) S ｎ－１ wo pkU ｊ Verify using:

[0148] Next, the payment acceptance unit 307 receives the public key pkU of the user key stored in the user key storage unit 312 of the user terminal 30-2. ｋ The payment request unit 306 of the user terminal 30-1 sends the id as a currency ID to the user terminal 30-1 (step S303). ｎ Generate an id ｎ and the received public key pkU ｋ and currency data (e.g., T ｎ－１ , or T ｎ－１ The information including the hash value of the user key skU is stored in the user key storage unit 312 of the user terminal 30-1. ｊ Sign using ｎ ) and calculate the currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ ) is generated (step S304). The currency additional information may be called currency data. ｎ is the currency that will be generated (T ｎ , ..., T ０) is a currency ID based on the face value of the currency (T ｎ－１ , ..., T ０ ) matches the payment amount v, then id ｎ The value of is the currency (T ｎ－１ , ..., T ０ ) T ｎ－１ id, which is the currency ID of ｎ－１ It can be the same as multiple currencies (T ｎ－１ , ..., T ０ ) matches the payment amount v, the payment request component 306 ｎ－１ , ..., T ０ ) for each currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ In this case, the id of each Tn ｎ The value of the corresponding id ｎ－１ The same as the currency (T ｎ , ..., T ０ ) is the currency (T ｎ－１ , ..., T ０ ) is generated every

[0149] On the other hand, currency (T ｎ－１ , ..., T ０ ) exceeds the payment amount v, or multiple currencies (T ｎ－１ , ..., T ０ ) ０ If the set of ｎ－１ , ..., T ０ ) and divide it into id ｎ That is, in this case, the id ｎ is the currency (T ｎ－１ , ..., T ０ ) in ｎ－１ id, which is the currency ID of ｎ－１ The NNL tree {Seed, depth, start point, end point} of the NNL tree obtained by dividing the payment amount v by the payment request unit 306 using the NNL tree as the division source. The processing procedure for executing such division is as explained in FIG. 12. That is, in step S304, the payment request unit 306 executes the processing procedure of FIG. 12 to obtain idｎ Generate.

[0150] The payment request unit 306 receives the currency additional information (T ｎ－１ , ..., T １ ) and the generated currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ ) and currency additional information (T ｎ , ..., T １ ) to the user terminal 30-2 (step S305).

[0151] The payment acceptance unit 307 of the user terminal 30-2 receives the currency additional information (T ｎ , ..., T １ Specifically, the payment acceptance unit 307 verifies the public key pkU ｊ Using S ｎ The payment acceptance unit 307 may verify each signature data included in the currency additional information. For example, the payment acceptance unit 307 verifies the currency additional information T ｎ :=(id ｎ , pkU ｊ , S ｎ ) signature S ｎ The payment acceptance unit 307 verifies the received currency T ０ Currency information added to ｎ , ..., T １ ) added to the currency (T ｎ , ..., T ０ ) is stored in the user currency storage unit 314 of the user terminal 30-2.

[0152] FIG. 14 is a sequence diagram showing an example of the flow of the currency exchange process. ｊ The process is initiated in response to an operation instructing the exchange of currency.

[0153] The exchange / deposit request unit 308 of the user terminal 30 receives face value information indicating the face value v of the exchange and the public key pkU of the user key stored in the user key storage unit 312. ｊ and requests the financial institution server 20 to exchange money (step S401).

[0154] The exchange / deposit acceptance unit 207 of the financial institution server 20 accepts the exchange (step S402). The exchange / deposit acceptance unit 207 transmits exchange acceptance information indicating the acceptance of the exchange to the user terminal 30 (step S403).

[0155] When the exchange / deposit request unit 308 of the user terminal 30 receives the exchange acceptance information, the payment request unit 306 requests payment from the financial institution server 20 according to the payment process shown in FIG. 13 (step S404).

[0156] The payment request unit 208 of the financial institution server 20 calculates the amount v that totals up to the exchange amount v. １ , ..., v ｘ When exchanging to v １ , ..., v ｘ For each of the above, payment is requested from the user terminal 30 in accordance with the payment process shown in FIG. 13 (steps S405-1, S405-2).

[0157] FIG. 15 is a sequence diagram showing an example of the flow of the credit processing. ｊ The process is initiated in response to an operation instructing the credit of the customer.

[0158] The credit request unit 309 of the user terminal 30 receives the currency T whose availability is to be confirmed. ０ The credit acceptance unit 210 of the financial institution server 20 then accepts the credit request (step S502). ０ is searched from the currency in use storage unit 216, and T ０ Records containing, for example, (T １ , T ０ ) exists, the credit result indicating the credit success ack is transmitted to the user terminal 30 (step S503).

[0159] FIG. 16 is a sequence diagram showing an example of the flow of a deposit process. ｊ The deposit is initiated in response to an operation instructing the deposit of

[0160] The exchange / deposit request unit 308 of the user terminal 30 receives face value information indicating the face value v of the deposit and the public key pkU of the user key stored in the user key storage unit 312.ｊ and requests the financial institution server 20 to make a deposit (step S601).

[0161] The exchange and deposit acceptance unit 207 of the financial institution server 20 accepts the deposit (step S602). The exchange and deposit acceptance unit 207 transmits deposit acceptance information indicating the acceptance of the deposit to the user terminal 30 (step S603).

[0162] When the exchange / deposit request unit 308 of the user terminal 30 receives the deposit acceptance information, the payment request unit 306 requests payment from the financial institution server 20 according to the payment process shown in FIG. 13 (step S604).

[0163] FIG. 17 is a sequence diagram showing an example of the flow of the refund process. ｉ It is initiated in response to an operation instructing the withdrawal of

[0164] The refund request unit 211 of the financial institution server 20 transmits the currency data to be refunded and requests a refund from the issuing bank server 10 (step S701). The currency data to be refunded may be unused currency or used currency. When refunding unused currency, the refund request unit 211 sends the unused currency T ０ from the unused currency storage unit 215 and transmits it to the issuing bank server 10.

[0165] In addition, when refunding used currency, the refund request unit 211 returns the used currency (T ｎ , ..., T ０ ) is extracted from the used currency storage unit 218 and transmitted to the issuing bank server 10. ｍ , ..., T ｋ＋１ , T ０ ) has been updated, the refund request unit 211 retrieves the pre-update currency additional information (T ｋ , ..., T １ ) and read out the used currency (T ｍ , ..., T ｋ＋１ , T ０ ) and combine it with the combined currency (T ｍ , ..., T ０ ) is sent to the issuing bank server 10.

[0166] The refund acceptance unit 105 of the issuing bank server 10 accepts the refund (step S702). Specifically, the refund acceptance unit 105 accepts the currency to be refunded (hereinafter, "currency (T ｎ , ..., T ０ )) is judged whether it corresponds to double spending, and if it does not correspond to double spending, information about the currency is stored in the refunded currency storage unit 108. At this time, the refund acceptance unit 105 may confirm the legitimacy of the currency that has been accepted for refund by verifying the signature included in each currency additional information of the refunded currency data. For example, ｎ The signature S contained in ｎ is the currency additional information T ｎ－１ It can be verified using the public key contained in

[0167] Next, the process of determining whether the currency to be refunded has been used twice in step S702 will be described in detail.

[0168] FIG. 18 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use has occurred in the first embodiment.

[0169] In step S801, the refund acceptance unit 105 receives a currency (T ｎ , ..., T ０ ) will be accepted for redemption. Hereinafter, this currency will be referred to as the "Target Currency T ｎ ". Note that step S801 is the same step as step S702 in FIG. 17. ｎ is the currency at the time of issue (hereinafter referred to as the "original currency") T ０ The currency may be a currency into which a portion of the face value of the original currency T ０ It may also be a currency that has not been split.

[0170] Next, the refund acceptance unit 105 receives the target currency T ｎ The original (at the time of issue) currency of T (hereinafter referred to as the "original currency") ０ Currency ID (= id ０ ) is stored in the issued currency storage unit 107 (S802). ０is not stored in the issued currency storage unit 107 (No in S802), the refund acceptance unit 105 ｎ is determined to be a counterfeit currency (S803), and the process of FIG. 18 is terminated.

[0171] id ０ is stored in the issued currency storage unit 107 (Yes in S802), the refund acceptance unit 105 ｎ Currency ID = id ｎ The refunded currency containing the same random number as the random number (Seed) is obtained from the refunded currency storage unit 108 (S804).

[0172] FIG. 19 is a diagram illustrating an example of the configuration of the refunded currency storage unit 108 in the first embodiment. In FIG. 19, the refunded currency storage unit 108 stores, for each refunded currency (hereinafter referred to as "refunded currency"), the currency ID at issue, the currency ID at refund, the depth, the start point, and the end point, etc. The currency ID at issue is the currency ID when the original currency of the refunded currency was issued. If the refunded currency is divided during the circulation process, there may be multiple currencies with the same currency ID at issue. The currency ID at refund is the currency ID when the refunded currency is refunded. If the refunded currency is not divided during the circulation process, the currency ID at refund matches the currency ID at issue. If the refunded currency is divided during the circulation process, the depth, the start point, and the end point of the currency ID at refund differ from the currency ID at issue. The depth, the start point, and the end point are the depth, the start point, and the end point included in the currency ID at refund. That is, the refunded currency storage unit 108 stores information indicating the range of refunded currency in an NNL tree (binary tree), which is a space representing the face value of the original currency.

[0173] In step S804, the target currency T ｎ Currency ID = id ｎ The refunded currency (i.e., the original currency is T) included in the refund currency ID that contains the same random number as the random number (Seed) of ０ The currency to be redeemed is obtained from the refunded currency storage unit 108.

[0174] Next, the refund acceptance unit 105 executes a loop process including S805 for each of the obtained refunded currencies. The refunded currencies being processed in this loop process are hereinafter referred to as "target refunded currencies." Note that if no refunded currencies are obtained in step S804, this loop process is not executed and the process proceeds to step S807.

[0175] In step S805, the refund acceptance unit 105 receives the target currency T ｎ It is determined whether or not at least a part of the range from the start point to the end point of the target currency T overlaps with the range from the start point to the end point of the target currency T (whether or not there is an overlap between the two) (S805). ｎ If the start point of the target refunded currency is greater than the end point of the target currency T ｎ If the end point of the redeemed currency is smaller than the start point of the redeemed currency, there is no overlap between them, otherwise there is an overlap between them.

[0176] If there is an overlap between the two (No in S805), the refund acceptance unit 105 ｎ It is determined that the target currency T ｎ In this case, the refund receiving unit 105 may output information indicating the double use. ｎ By detecting a branch in the chain of signatures between the target currency T and the target refunded currency, the timing of the double spending or the person who made the double spending may be identified, and the identification result may be output. ｎ Between the target refunded currency and the target refunded currency, (T ｘ , ..., T ０ ) are common. In this case, T ｘ The public key pkU contained in idx, which is the currency ID of ｘ Is T ｘ The public key of the person who received the certificate is the public key of the person X. Therefore, it is possible to identify X as the person who performed the double spending.

[0177] If there is no overlapping portion among all the refunded currencies acquired in step S804, the refund acceptance unit 105 ｎ is registered in the refunded currency storage unit 108 (FIG. 19) (S807). ０ Currency ID = id ０ , target currency T ｎ Currency ID = id ｎ , id ｎ Depth, id ｎ The start point of id ｎ A record including the end point of the above is added to the refunded currency storage unit 108 (FIG. 19).

[0178] (Effects of the First Embodiment) As described above, according to the first embodiment, the denomination of a currency is not fixed but is specified by a set (a range from the start point to the end point) of the smallest divisible units (e.g., 1 yen). Therefore, the unit of currency withdrawal can be a division unit rather than a minimum unit of currency. According to a simulation conducted by the inventors of the present application, it is assumed that currency in circulation is divided approximately three times, and that the division unit is larger than the minimum unit of currency. As a result, the number of records in the withdrawn currency storage unit 108 ( FIG. 19 ) can be reduced to a degree proportional to the number of divisions rather than the amount of currency issued. As the number of records is reduced, the number of comparisons of withdrawn currency with previously withdrawn currency (the number of checks for overlapping ranges) can also be reduced. For example, if 10,000 yen is withdrawn, it is not necessary to handle 10,000 records. Therefore, detection of double spending of electronic currency can be made more efficient.

[0179] Second Embodiment Next, a second embodiment will be described. In the second embodiment, differences from the first embodiment will be described. Points not specifically mentioned in the second embodiment may be the same as those in the first embodiment.

[0180] In the second embodiment, a method for determining whether or not a dual use has occurred will be described, which is different from the method (FIG. 18) described in the first embodiment.

[0181] In the first embodiment, an example was described in which the range of currency denominations at the time of redemption was specified by the start point and the end point. In other words, whether or not the start point and the end point overlap was used to determine whether or not a double-spend occurred. In the second embodiment, an example is described in which the denomination of a certain currency is converted into the form of a sum of powers of two, and the range of denominations of the certain currency is expressed by a list of random numbers at nodes corresponding to each of the powers of two that make up the sum in an NNL tree (binary tree), which is a space representing the denomination of the original currency. In the second embodiment, whether or not a double-spend occurred is determined by whether or not such random numbers overlap (or collide).

[0182] FIG. 20 is a diagram for explaining a method for expressing a range of currency denominations in the second embodiment. The binary tree in FIG. 20 is an NNL tree, which is a space for expressing currency denominations. In addition, in FIG. 20, a code beginning with r assigned to each node is an identifier for each node and also a random number assigned to each node. If the smallest unit of currency is 1 yen, one leaf node of the NNL tree in FIG. 20 corresponds to 1 yen. Therefore, the NNL tree in FIG. 20 can express a maximum of 8 yen.

[0183] Here, if we express 8 as the sum of powers of 2, it becomes 2 ３ The exponent 3 corresponds to the node position (depth) in the NNL tree (binary tree). In other words, it can be said that the node with a depth of 3 is the node corresponding to the range of 8. Therefore, in FIG. 20, the range of 8 yen is the root node r. In other words, 8 yen can be replaced with a list of random numbers called random number {r}. Such a representation of face value using a list of random numbers will be referred to as a "random number list" hereinafter. It can be said that node r is a node whose descendants are only leaf nodes corresponding to 8 yen.

[0184] When 6 yen is divided from 8 yen, 6 yen can be expressed as the sum of powers of 2, which is 2 ２ +2 １ If the left leaf node is given priority for division, ２ The node corresponding to is node r0, and １The node corresponding to 6 yen is node r10. Therefore, 6 yen can be replaced with a list of random numbers {r0, r10}. In other words, the number of leaf nodes belonging to node r0 (which are descendants of node r0) is 4, and the number of leaf nodes belonging to node r10 is 2. Therefore, {r0, r10}4+2=6 yen corresponds. Note that nodes r0 and r10 can be said to be nodes whose descendants are only leaf nodes corresponding to 6 yen.

[0185] When converting a certain denomination into a list of random numbers, overlapping nodes are not allowed between subtrees whose root nodes are random numbers included in the list of random numbers. For example, in Figure 20, node r01 corresponds to 2 yen, but the subtree whose root is node r01 is part of the subtree whose root is node r0. Therefore, {r0, r01} is equivalent to {r0}, and would represent 4 yen instead of 6 yen. Therefore, a list of random numbers such as {r0, r01} will not be generated.

[0186] FIG. 21 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use is occurring in the second embodiment.

[0187] Steps S851 to S853 are the same as steps S801 to S803 in Fig. 18. That is, in step S851, the refund acceptance unit 105 receives the target currency T ｎ = (T ｎ , ..., T ０ ) The refund acceptance unit 105 then accepts the target currency T ｎ The original currency of ０ Currency ID (= id ０ ) is stored in the issued currency storage unit 107 (S852). ０ is not stored in the issued currency storage unit 107 (No in S852), the refund acceptance unit 105 ｎ is determined to be a counterfeit currency (S853), and the process of FIG. 21 is terminated.

[0188] id ０ is stored in the issued currency storage unit 107 (Yes in S852), the refund acceptance unit 105 ｎ20 (S854). Specifically, the refund acceptance unit 105 converts the target currency T ｎ id, which is the currency ID of ｎ = {T ０ Seed, T ０ The depth of the NNL tree, T ｎ The starting point of T ｎ end point of T ０ Seed and T ０ In the NNL tree (binary tree) specified based on the depth of the NNL tree of T ｎ From the starting point of T ｎ A list of leaf nodes included in the range of the end points of is converted into a list of random numbers. The list of random numbers is a set of random numbers corresponding to the root nodes of each subtree in a set of subtrees that includes only the list of leaf nodes.

[0189] Next, the refund acceptance unit 105 executes a loop process including steps S855 to S857 for each random number included in the random number list {r_1, ..., r_b}. The random number being processed in this loop process will be referred to as "r_x" hereinafter.

[0190] In step S855, the refund receiving unit 105 determines whether r_x has already been refunded. Specifically, the refund receiving unit 105 determines whether r_x has already been stored in the refunded currency storage unit 108.

[0191] FIG. 22 is a diagram showing an example of the configuration of the refunded currency storage unit 108 in the second embodiment. As shown in FIG. 22, in the second embodiment, the refunded currency storage unit 108 stores an at-issue currency ID and a refunded random number in association with each other. The at-issue currency ID is the currency ID at the time the currency (original currency) that is the basis of the refunded currency was issued. The refunded random number is a random number corresponding to the range of the refunded face value of the original currency. If the original currency is refunded without being divided during the circulation process, the random number (seed value) of the currency ID of the original currency is stored as the refunded random number. If a portion of the face value of the original currency is divided during the circulation process, a random number corresponding to the range of that portion is stored as the refunded random number.

[0192] In step S855, the refund acceptance unit 105 determines whether r_x is stored in the refunded currency storage unit 108 as a refunded random number.

[0193] If r_x is stored in the refunded currency storage unit 108 as a refunded random number (Yes in S855), the refund acceptance unit 105 ｎ 18 , the refund acceptance unit 105 determines that the range of r_x is double-used (S856). In this case, the refund acceptance unit 105 may output information indicating the double-usage. Furthermore, as described in step S806 of FIG. 18 , the refund acceptance unit 105 may identify the timing of the double-usage or the person who performed the double-usage, and output the identification result.

[0194] If r_x is not stored in the refunded currency storage unit 108 as a refunded random number (No in S855), the refund acceptance unit 105 adds r_x to a refund candidate list (S857). The refund candidate list refers to list-format data for storing random numbers that are candidates for registration in the refunded currency storage unit 108 as refunded random numbers.

[0195] When the loop process has been executed for all random numbers included in the random number list {r_1, . . . , r_b}, the process proceeds to step S858.

[0196] Note that r_x is not registered in the refunded currency storage unit 108 at step S857 because it has not been determined that there is no double spending in the range corresponding to r_x. Specifically, it is possible that a random number corresponding to a descendant node of r_x or a random number corresponding to an ancestor of r_x has already been registered in the refunded currency storage unit 108 as a refunded random number. If the random number corresponding to a descendant node of r_x is a refunded random number, then a portion of the range corresponding to r_x is a double-spending. If the random number corresponding to an ancestor of r_x is a refunded random number, then the entire range corresponding to r_x is a double-spending. A specific explanation will be given with reference to FIG. 20. In a situation where r_x is r00, if r000 is a refunded random number, then r000 is a double-spending among {r000, r0001}, which is the leaf node corresponding to r_x. Alternatively, if r_x is r00 and r0 is a recovered random number, all of the leaf nodes {r000, r0001} corresponding to r_x are double-used. However, because r000 and r0 are both different values ​​from r00, the determination in step S855 cannot detect such double-usage. Therefore, in step S857, r_x is registered in the recovery candidate list as there is at least no exact match for double-usage of r_x, and in steps S858 and onward, processing is executed to detect double-usage that cannot be detected by loop processing.

[0197] In step S858, the refund receiving unit 105 determines whether the refund candidate list is empty. If the refund candidate list is empty (No in S858), the process in FIG. 21 ends.

[0198] If one or more random numbers are stored in the refund candidate list (Yes in S858), the refund acceptance unit 105 ｎ The original currency of T ０The refund receiving unit 105 obtains a list of refunded random numbers associated with the currency ID (hereinafter referred to as the "refunded random number list") from the refunded currency storage unit 108 (FIG. 22) (S859). Next, the refund receiving unit 105 determines whether the refunded random number list is empty (i.e., whether one or more corresponding refunded random numbers have been obtained) (S860). If the refunded random number list is empty (No in S860), the descendant or ancestor random numbers of each random number included in the refund candidate list have not yet been refunded, so the process proceeds to step S866.

[0199] If the refunded random number list contains one or more refunded random numbers (No in S860), the refund acceptance unit 105 ０ A binary tree (NNL tree) is generated based on the random numbers and the depth (S861). At this time, the random numbers of each node of the binary tree are also calculated. Note that it is not necessary to generate the entire binary tree. To reduce the amount of calculation, it is sufficient to identify the random numbers of the nodes on the path from the node corresponding to the random number to the root node and the random numbers of the nodes on the path from the random number to the leaf node for each random number included in the recovery candidate list.

[0200] Next, the refund acceptance unit 105 determines whether any of the random numbers included in the refund candidate list conflict with the list of refunded random numbers (S862). Here, a random number that conflicts with a certain random number refers to a random number that is an ancestor or descendant of the certain random number. In other words, for each random number included in the refund candidate list, the refund acceptance unit 105 obtains a list of the random numbers that are ancestors or descendants of that random number in the binary tree generated in step S861, and determines whether any of the random numbers included in the list of refunded random numbers are included in the list.

[0201] If there are no random numbers included in the refund candidate list that collide with the list of already-recovered random numbers (hereinafter referred to as "colliding random numbers") (No in S862), proceed to step S866. In this case, there is no double use of any of the random numbers included in the refund candidate list.

[0202] On the other hand, if there is a collision random number (Yes in S862), the refund acceptance unit 105 ｎ21 , the refund acceptance unit 105 determines that the range of the collision random number among the above is a double use (S863). In this case, the refund acceptance unit 105 may output information indicating the double use. Furthermore, as described in step S806 of FIG. 18 , the refund acceptance unit 105 may identify the timing of the double use or the person who performed the double use, and output the identification result. Next, the refund acceptance unit 105 deletes the collision random number from the refund candidate list (S864). Next, the refund acceptance unit 105 determines whether the refund candidate list is empty. If the refund candidate list is empty (No in S865), the processing of FIG. 21 ends. If one or more random numbers are stored in the refund candidate list (Yes in S865), the processing proceeds to step S866.

[0203] In step S866, the refund acceptance unit 105 treats each random number included in the refund candidate list as a refunded random number and assigns it to the target currency T ｎ The original currency of T ０ The random numbers are registered in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the currency (S866). That is, the range corresponding to the random numbers included in the refund candidate list at this point is the range in which no double use has been detected.

[0204] The subsequent processing from step S867 onwards is processing for organizing the refunded currency storage unit 108 (FIG. 22) to reduce the amount of storage capacity consumed.

[0205] In step S867, the refund acceptance unit 105 receives the target currency T ｎ The original currency of T ０ A list of the refunded random numbers stored in the refunded currency storage unit 108 in association with the currency ID of the above is obtained.

[0206] Next, the refund acceptance unit 105 receives the original currency T ０ All range of denominations (original currency T ０ It is determined whether the set of refunded random numbers covers all the nodes in the original currency T (from the start point to the end point of the original currency T) (S868). ０ It is determined whether the range of denominations matches the range of denominations.

[0207] Original currency T ０If the entire range of denominations of the original currency T is covered by the set of refunded random numbers (Yes in S868), the refund acceptance unit 105 ０ The refund acceptance unit 105 then determines that the entire range of denominations of the original currency T ０ The random number of the original currency T is used as the recovered random number. ０ The refund acceptance unit 105 registers the original currency T in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the original currency T (S870). ０ By deleting other refunded random numbers stored in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the original currency T ０ This may reduce the amount of information stored in relation to the

[0208] As described above, the second embodiment can also provide the same effects as the first embodiment.

[0209] Third Embodiment Next, a third embodiment will be described. In the third embodiment, differences from the first embodiment will be described. Points not specifically mentioned in the third embodiment may be the same as those in the first embodiment.

[0210] In the first embodiment, when currency is transferred by withdrawal, payment, etc., verification must be performed on a currency-by-currency basis. Therefore, for example, if a user who has two 2,000 yen currency wishes to pay 3,000 yen, they can pay two currencies: one 2,000 yen currency and the other 1,000 yen currency divided from the 2,000 yen currency. In this case, however, the payer must generate a signature for each currency, and the payment recipient must verify each currency. The greater the number of currencies traded, the greater the burden of such signatures and verifications. In the third embodiment, a method for reducing this burden is disclosed.

[0211] The third embodiment differs from the first embodiment in that a hash tree of currencies is generated and the root of the hash tree is signed, thereby signing all of the target currencies together. In the following description of the third embodiment, components having the same functional configuration as those in the first embodiment are assigned the same reference numerals as those used in the description of the first embodiment, and descriptions thereof will be omitted.

[0212] (Basic Technology Used in the Third Embodiment) First, the basic technology used in this embodiment will be described. In this embodiment, three functions MHTree, MHPath, and MHVer that utilize a hash tree called a Merkle tree (Reference [2]) are used.

[0213] 23 is a diagram illustrating the MHTree function of a Merkle tree according to the third embodiment. The MHTree function is a function that generates a hash tree from a data set.

[0214] Specifically, the MHTree function is a function that inputs a dataset D and outputs a hash tree L={(leaf_id, leaf_val)}, which is a binary tree generated by associating the hash value of each piece of data that makes up D with a leaf node. Here, the vertex h is called the root. Hereinafter, it will be described as MHTree(D)->L. Note that FIG. 23 shows a dataset where n=6. The value of each leaf node is the hash value of the data that corresponds to that leaf node. The seventh and eighth leaf nodes are complemented with "00" to enable the construction of a binary tree.

[0215] 24 is a first diagram illustrating the MHPath function of a Merkle tree according to the third embodiment. The MHPath function is a function that generates a path required to authenticate a partial data set.

[0216] Specifically, the MHPath function is a function that inputs a partial data set D' to be authenticated (in the case of FIG. 24, D'={d0, d4, d5}) and outputs the authentication path AP (h001, h01, h11 in FIG. 24) and route h required for that authentication. Hereinafter, it is written as MHPath(D', L)->(AP, h).

[0217] 25 is a diagram illustrating the MHVer function of a Merkle tree according to the third embodiment. The MHVer function is a function that performs verification using an authentication path of a partial data set.

[0218] Specifically, the MHVer function is a function that verifies sub-data D' (D' = {d0, d4, d5} in the case of FIG. 25) from the path AP (h001, h01, h11 in FIG. 25) required for authentication and the route h. Hereinafter, it is written as MHver(AP, h, D') -> T or F. The MHver function outputs T if the verification is successful (if D' is correct), and outputs F if the verification fails (if D' is incorrect). D' being correct means that none of the data belonging to D' has been tampered with.

[0219] (Example of Operation of Electronic Currency System According to Third Embodiment) Here, in step S202 of FIG. 11, a set T of multiple currencies whose currency value matches v is selected. ０ :=(T ０ _t):=((id ０ _t, y_t, B ｉ , pkB ｉ , S ０ _t), t = 1, ..., s, Σv_t = v). Note that v_t is T ０ The t-th currency T ０ For example, if each v_t is 10,000 yen and a withdrawal of 80,000 yen is accepted, then s = 8. ０ 12. In the third embodiment, when there are eight 10,000 yen bills, such as when there is only 100,000 yen bill in the unused currency storage unit 215 of the financial institution server 20, the withdrawal acceptance unit 205 executes the process of FIG. 12 to divide the existing 100,000 yen bills into eight 10,000 yen bills. ０ _t is not limited to a currency immediately after issuance, but may be a currency that has been transferred after issuance (i.e., currency additional information has been added). In this case, it may be a currency that has been divided (i.e., the NNL tree of the currency ID has been divided) during the transfer process.

[0220] The withdrawal acceptance unit 205 of the financial institution server 20 calculates the hash tree L １ =MHTree({T ０ _t}{t=1,...,s}) and generate a private key skB ｉ Using the hash tree L １The hash value RH (RootHash) of the root node and pkU ｊ Signature S for the set １ That is, a hash tree L １ For that leaf node, T ０ Each T constituting ０ The withdrawal receiving unit 205 generates a hash tree by assigning T ０ For each _t, ０ Currency additional information T for _t １ _t:=(id １ _t, pkU ｊ ,RH,AP_t,S １ ) to add the currency in use (T １ _t, T ０ _t) is generated and stored in the currency-in-use storage unit 216. Here, AP_t is the MHPath(T ０ _t, L １ ) -> (AP_t, RH) is the path required for authenticating the RH. １ The value of _t is the corresponding id ０ This state is shown in Figure 27. １ The signature that _t contains is the same as S １ Below, we can see that the currency (T １ _t, T ０ _t) set (here, 8 sets) １ , T ０ ) should be written.

[0221] Next, the withdrawal acceptance unit 205 receives the current currency set (T １ , T ０ ) currency dataset and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the in-use currency set (T １ , T ０ ) currency dataset and financial institution public key certificate Auth(pkB ｉ ) and verify the currency set in use (T １ , T ０) is stored in the user currency storage unit 314. At this time, the withdrawal request unit 305 stores the currency set (T １ , T ０ Regarding the verification of (T １ , T ０ ) one of the currencies (T １ _t, T ０ Specifically, it is necessary to verify only one of T １ MHver(AP_t, RH, T ０ ) is T, and １ _t contains S １ The withdrawal request unit 305 verifies the other T １ For _t, the T that was the subject of verification １ Same as _t １ You just need to make sure it includes.

[0222] The user of the user terminal 30 withdraws the currency set (T １ , T ０ ) that constituted each (T １ _t, T ０ _t) can be used individually (separately). １ _t indicates the history of the currency owner (circulation process) in the same way as the currency additional information in the first embodiment, except that it includes RH and AP_t to reduce the signing and verification costs of the currency set, and the authenticity of each currency is guaranteed individually.

[0223] The above-described processing is also executed in steps S304 and S305 in FIG. 13 when a payment is made in a set of multiple coins.

[0224] It is also executed in the process of FIG. 13 called from FIG. 14 (when exchanging money) and FIG. 16 (when depositing money).

[0225] 13 can be applied to all other phases (such as when issuing or redeeming). For example, when redeeming, it is possible to efficiently transfer the currency to be redeemed in one lump sum.

[0226] As described above, according to the third embodiment, it is possible to reduce the signature cost and verification cost when transferring multiple currencies.

[0227] (Hardware Configuration Example) A hardware configuration example common to the first and third embodiments will be described. Each part of each device included in the electronic currency system 1 can be realized, for example, by having a computer execute a program that describes the processing content described in this embodiment. Note that this "computer" may be a physical machine or a virtual machine on the cloud. When a virtual machine is used, the "hardware" described here is virtual hardware.

[0228] The program can be stored and distributed by recording it on a computer-readable recording medium (such as a portable memory device).The program can also be provided via a network such as the Internet or email.

[0229] Fig. 28 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 28 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.

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

[0231] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when a program startup instruction is received. The CPU 1004 implements 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. The display device 1006 displays a program-based graphical user interface (GUI), etc. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operational instructions. The output device 1008 outputs calculation results. Note that the computer may include a GPU (Graphics Processing Unit) or a TPU (Tensor Processing Unit) instead of the CPU 1004, or may include a GPU or TPU in addition to the CPU 1004. In this case, processing may be shared, such as processing requiring special calculations such as neural networks being performed by the GPU or TPU, and other processing being performed by the CPU 1004.

[0232] (References) [1] Revocation and Tracing Schemes for Stateless Receivers, Dalit Naor, Moni Naor, and Jeff Lotspiech, CRYPTO2001 [2] Jakobsson M., Leighton T., Micali S., Szydlo M. (2003) Fractal Merkle Tree Representation and Traversal. In: Joye M. (eds) Topics in Cryptology - CT-RSA 2003. CT-RSA 2003. Lecture Notes in Computer Science, vol. 2612. Springer, Berlin, Heidelberg. In the above embodiments, the issuing bank server 10 is an example of a currency processing device. The refund acceptance unit 105 is an example of a determination unit.

[0233] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0234] 1 Electronic currency system 10 Issuing bank server 11 Root certification authority server 20 Financial institution server 25 Intermediate certification authority server 30 User terminal 101 Currency issuance key generation unit 102 Currency issuance certificate issuance unit 103 Financial institution public key certificate issuance information acquisition unit 104 Currency issuing unit 105 Withdrawal acceptance unit 106 Currency issuance key storage unit 107 Issued currency storage unit 108 Withdrawn currency storage unit 111 Root authentication key generation unit 112 Root certificate issuance unit 113 Financial institution authentication unit 114 Financial institution public key certificate issuance information transmission unit 115 Root authentication key storage unit 116 Financial institution public key certificate issuance information storage unit 201 Currency issuance certificate issuance acceptance unit 202 Financial institution key generation unit 203 Financial institution authentication request unit 204 Currency issuance acceptance unit 205 Withdrawal acceptance unit 206 Update processing unit 207 Currency exchange and deposit acceptance unit 208 Payment request unit 209 Payment acceptance unit 210 Credit acceptance unit 211 Refund request unit 212 Currency issuance certificate storage unit 213 Financial institution key storage unit 214 Financial institution public key certificate storage unit 215 Unused currency storage unit 216 Currency in use storage unit 217 Updated currency storage unit 218 Used currency storage unit 251 Intermediate authentication key generation unit 252 Intermediate certificate issuance unit 253 User authentication unit 254 Intermediate authentication key storage unit 255 User public key certificate issuance information storage unit 301 Currency issuance certificate issuance acceptance unit 302 Intermediate certificate issuance acceptance unit 303 User key generation unit 304 User authentication request unit 305 Withdrawal request unit 306 Payment request unit 307 Payment acceptance unit 308 Currency exchange and deposit request unit 309 Credit request unit 310 Currency issuance certificate storage unit 311 Intermediate certificate storage unit 312 User key storage unit 313 User public key certificate storage unit 314 User currency 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 electronic currency system comprising: a determination unit configured to, upon redemption of a first electronic currency to which information indicating a range corresponding to the face value of the first electronic currency is assigned in a space representing the face value of the first electronic currency, determine whether the first electronic currency has been double-spended based on whether information indicating a range that at least partially overlaps with the range corresponding to the face value of the first electronic currency is stored in a redeemed currency storage unit that stores information indicating the redeemed range in the space.

2. The electronic currency system according to claim 1, characterized in that the first electronic currency is an electronic currency in which a portion of the face value is separated from the face value of the certain electronic currency, and the information indicating the range corresponding to the face value of the first electronic currency is a range corresponding to the portion of the face value.

3. The electronic currency system described in claim 1, characterized in that the space is a binary tree in which each node is assigned a random number that can be calculated based on a random number for the root node, and the space includes leaf nodes whose number corresponds to the denomination, and the information indicating the range is information indicating the leaf nodes included in the range.

4. The electronic currency system described in claim 1, characterized in that the space is a binary tree in which each node is assigned a random number that can be calculated based on the random number for the root node, and the tree includes leaf nodes whose number corresponds to the face value, and the determination unit is configured to determine whether the first electronic currency has been double-spended based on whether the random number of the node whose descendants are only leaf nodes ... all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are all leaf nodes whose descendants are 5. The electronic currency system described in claim 4, characterized in that the judgment unit is configured to determine whether the first electronic currency has been double-spended based on whether the random numbers of the ancestor or descendant nodes of the node whose descendants are only leaf nodes corresponding to the range corresponding to the face value of the first electronic currency are stored in the redeemed currency memory unit, which stores random numbers of the node whose descendants are only leaf nodes corresponding to the redeemed range in the space.

6. A currency processing device comprising: a determination unit configured to determine whether or not a first electronic currency has been double-spended in response to the redemption of the first electronic currency, based on whether or not a redeemed currency storage unit that stores information indicating the redeemed range in the space representing the denomination of the first electronic currency stores information indicating a range that at least partially overlaps with the range corresponding to the denomination of the first electronic currency.

7. A currency processing method characterized by a computer executing a determination procedure for determining whether or not a first electronic currency has been double-spent upon redemption, based on whether or not a redeemed currency storage unit that stores information indicating a range that has been redeemed in a space representing the denomination of a certain electronic currency and that is assigned information indicating a range corresponding to the denomination of the first electronic currency stores information indicating a range that at least partially overlaps with the range corresponding to the denomination of the first electronic currency.

8. A program for causing a computer to execute a determination procedure for determining whether or not a first electronic currency has been double-spent in response to the redemption of said first electronic currency, to which information indicating a range corresponding to the face value of the first electronic currency is assigned in a space representing the face value of the first electronic currency, based on whether or not information indicating a range that at least partially overlaps with the range corresponding to the face value of the first electronic currency is stored in a redeemed currency storage unit that stores information indicating the redeemed range in said space.

Images