Currency processing device, currency processing method, and program

Abstract

This currency processing device efficiently implements a variable denomination system by including: a depth calculation unit configured to calculate a depth of an NNL tree including a specific number or more of leaf nodes, the specific number being obtained by dividing an amount to be transferred by the minimum unit of electronic currency; a root node determination unit configured to determine, in a first NNL tree added to first electronic currency, a root node of a second NNL tree, which is a partial tree of the first NNL tree, on the basis of the depth; a random number calculation unit configured to calculate a random number corresponding to the root node on the basis of a Seed of the first NNL tree; a leaf node determination unit configured to determine a range of leaf nodes corresponding to the amount from among the leaf nodes; and a currency addition information generation unit configured to generate information indicating the random number, the depth, and the range as information to be added to second electronic currency.

Description

Currency processing device, currency processing method and program

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

[0002] Research into electronic cash has been ongoing for many years, and various governments are also considering electronic currency. Research into electronic cash has included a token-type electronic cash system in which each currency unit is signed by the issuing bank, allowing transactions to be completed only between users.

[0003] There are two types of token-based electronic cash systems: a "fixed face value system" in which the value of the token as electronic currency is fixed, and a "variable face value system" in which the value of the token is allowed to fluctuate by dividing or combining tokens, etc.

[0004] International Publication No. 2022 / 254624

[0005] The above-mentioned prior art assumes a fixed denomination system, and has the problem that it cannot efficiently realize a variable denomination system.

[0006] The present invention has been made in view of the above points, and has as its object to make it possible to efficiently realize a variable denomination system.

[0007] In order to solve the above problem, a currency processing device has a depth calculation unit configured to calculate the depth of an NNL tree that includes leaf nodes whose number is equal to or greater than the value obtained by dividing the amount to be transferred by the smallest unit of electronic currency; a root node determination unit configured to determine the root node of a second NNL tree that is a subtree of the first NNL tree based on the depth in the first NNL tree added to the first electronic currency; a random number calculation unit configured to calculate a random number corresponding to the root node based on the seed of the first NNL tree; a leaf node determination unit configured to determine a range of leaf nodes among the leaf nodes that will correspond to the amount; and a currency additional information generation unit configured to generate information indicating the random number, the depth, and the range as information to be added to the second electronic currency.

[0008] It is possible to efficiently realize a variable denomination system.

[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 a 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 for explaining an example of the processing procedure for generating a currency ID when issuing currency. FIG. 10 is a sequence diagram for explaining an example of the flow of a withdrawal processing. FIG. 11 is a sequence diagram for explaining an example of the processing procedure for dividing currency. FIG. 12 is a sequence diagram for explaining an example of the flow of a payment processing. FIG. 13 is a sequence diagram for explaining an example of the flow of an exchange processing. FIG. 14 is a sequence diagram for explaining an example of the flow of a credit processing. FIG. 15 is a sequence diagram for explaining an example of the flow of a deposit processing. FIG. 16 is a sequence diagram for explaining an MHTree function of a Merkle tree according to the second embodiment. FIG. 17 is a first diagram for explaining the MHPath function of a Merkle tree according to the second embodiment. FIG. 18 is a diagram for explaining the MHVer function of a Merkle tree according to the second embodiment. FIG. 19 is a diagram showing a state where there are eight currency coins. Fig. 10 is a diagram showing a state in which currency additional information including the same signature is added to eight bills Fig. 11 is a diagram showing 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, a fixed face value system in 1 yen units is adopted, thereby (effectively) realizing a variable face value system (token division).

[0014] To guarantee the authenticity of each currency, a signature from the issuing bank's server is affixed to each currency as described above. If currency is represented by a set of 1 yen coins, for example, 10,000 signatures must be issued when issuing 10,000 yen. In this case, the cost of generating and verifying signatures at the time of issuance, payment, etc. becomes unrealistic. Therefore, in this embodiment, the amount of one currency is represented by a single tree structure with the smallest unit (1 yen) as a leaf node, so that signatures are generated and verified only once at the time of issuance, payment, etc.

[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, 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, the ID (random number) corresponding to node n1, which is the ancestor node of all ID1 to ID4, becomes the root node of the subtree (NNL tree) corresponding to the 4 yen after division. Therefore, 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. In this case, the currency issued by the issuing bank (T, described later) ０ ) 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 ０ ) and verifying it has the advantage of being computationally efficient.

[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, and a refunded currency storage unit 107.

[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 107. 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 refunded currency storage unit 107 stores the currency for which the refund acceptance unit 105 has accepted the refund (hereinafter referred to as the refunded currency).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0097] (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 , ....

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

[0099] 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

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

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

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

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

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

[0105] 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:

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

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

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

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

[0110] 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:

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

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

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

[0114] 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 ｉ )) and stores it in the financial institution public key certificate issuance information storage unit 116.

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

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

[0117] 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 ｉ ) (step S117). 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 generates 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.

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

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

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

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

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

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

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

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

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

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

[0128] 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: ∑ ...

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

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

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

[0132] 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

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

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

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

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

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

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

[0139] Next, the withdrawal reception unit 205 determines the start and end points of the leaf nodes of the NNL tree to be split, which correspond to the face value v (S214). The method for determining such leaf nodes may be the same as the method described in step S123 of Figure 10.

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

[0141] 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 (S215).

[0142] 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 (S217). 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.

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

[0144] 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:

[0145] 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:

[0146] 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

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

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

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

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

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

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

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

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

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

[0156] 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 ０ If the credit result indicates a successful credit acknowledgment, the credit result indicating the successful credit acknowledgment is sent to the user terminal 30 (step S503).

[0157] 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

[0158] 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 exchange money (step S601).

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

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

[0161] 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

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

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

[0164] The refund acceptance unit 105 of the issuing bank server 10 accepts the refund (step S702). Specifically, the refund acceptance unit 105 stores the received currency data in the refunded currency storage unit 107. At this time, the refund acceptance unit 105 may verify the validity of the currency for which the refund has been accepted by verifying the signature included in each currency additional information. For example, when the currency additional information T ｎ The signature S contained in ｎ is the currency additional information T ｎ－１ It can be verified using the public key contained in

[0165] (Effects of the First Embodiment) As described above, according to the first embodiment, it is possible to efficiently realize a floating denomination system. Specifically, while the minimum unit of currency is fixed, it is possible to issue currency in multiples of the minimum unit, and it is possible to perform signatures and verification in currency units rather than in units of the minimum unit. Furthermore, by adopting the NNL tree method, it is possible to reduce the number of hash calculations.

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

[0167] 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 second embodiment, a method for reducing this burden is disclosed.

[0168] The second embodiment differs from the first embodiment in that a hash tree of currencies is generated and the root of the hash tree is signed to sign all of the target currencies together. In the following description of the second 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.

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

[0170] 18 is a diagram illustrating the MHTree function of a Merkle tree according to the second embodiment. The MHTree function is a function that generates a hash tree from a data set.

[0171] 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. 18 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.

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

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

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

[0175] Specifically, the MHVer function is a function that verifies sub-data D' (D' = {d0, d4, d5} in the case of FIG. 20) from the path AP (h001, h01, h11 in FIG. 20) 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.

[0176] (Example of Operation of Electronic Currency System According to Second 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 second 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 bill 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.

[0177] 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 22. １ 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.

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

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

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

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

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

[0183] As described above, according to the second embodiment, it is possible to reduce the signature costs and verification costs when transferring multiple currencies.

[0184] (Hardware Configuration Example) A hardware configuration example common to the first and second embodiments will be described. Each part of each device provided 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.

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

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

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

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

[0189] (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 withdrawal acceptance unit 205 and the payment request unit 306 are examples of the depth calculation unit, root node determination unit, random number calculation unit, leaf node determination unit and currency additional information generation unit in claim 1, and the Merkle tree generation unit and addition unit in claim 3. The currency issuing unit 104 is an example of the depth calculation unit, random number generation unit, leaf node determination unit, and currency additional information generation unit in claim 2. The financial institution server 20, the user terminal 30, and the issuing bank server 10 are an example of a currency processing device.

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

[0191] 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 issuance unit 105 Withdrawal acceptance unit 106 Currency issuance key storage unit 107 Withdrawn currency storage unit 111 Root certification 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 certification 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 / 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 Exchange / 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. A currency processing device comprising: a depth calculation unit configured to calculate the depth of an NNL tree including leaf nodes whose number is equal to or greater than the value obtained by dividing the amount to be transferred by the smallest unit of electronic currency; a root node determination unit configured to determine a root node of a second NNL tree, which is a subtree of the first NNL tree, based on the depth in a first NNL tree added to a first electronic currency; a random number calculation unit configured to calculate a random number corresponding to the root node based on a seed of the first NNL tree; a leaf node determination unit configured to determine a range of leaf nodes among the leaf nodes to correspond to the amount; and a currency additional information generation unit configured to generate information indicating the random number, the depth, and the range as information to be added to the second electronic currency.

2. A currency processing device comprising: a depth calculation unit configured to calculate the depth of an NNL tree containing leaf nodes whose number is equal to or greater than the value obtained by dividing the amount of electronic currency to be issued by the smallest unit of electronic currency; a random number generation unit configured to generate a random number that will become the seed of the NNL tree; a leaf node determination unit configured to determine a range of leaf nodes among the leaf nodes that will correspond to the amount; and a currency additional information generation unit configured to generate information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued.

3. A currency processing device comprising: a Merkle tree generation unit configured to generate a Merkle tree based on the hash values ​​of each of a plurality of electronic currencies to be transferred; and an attachment unit configured to attach the hash value of the root node of the Merkle tree and a signature for the hash value to each of the plurality of electronic currencies.

4. A currency processing method executed by a computer, comprising: a depth calculation step of calculating the depth of an NNL tree including leaf nodes whose number is equal to or greater than the value obtained by dividing the amount to be transferred by the smallest unit of electronic currency; a root node determination step of determining a root node of a second NNL tree, which is a subtree of the first NNL tree, based on the depth in a first NNL tree added to a first electronic currency; a random number calculation step of calculating a random number corresponding to the root node based on a seed of the first NNL tree; a leaf node determination step of determining a range of leaf nodes among the leaf nodes to correspond to the amount; and a currency additional information generation step of generating information indicating the random number, the depth, and the range as information to be added to the second electronic currency.

5. A currency processing method in which a computer executes the following steps: a depth calculation step for calculating the depth of an NNL tree that includes leaf nodes whose number is equal to or greater than the amount of the electronic currency to be issued divided by the smallest unit of the electronic currency; a random number generation step for generating a random number that will become the seed of the NNL tree; a leaf node determination step for determining a range of leaf nodes among the leaf nodes that will correspond to the amount; and a currency additional information generation step for generating information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued.

6. A currency processing method, the method comprising: a Merkle tree generation step of generating a Merkle tree based on the hash values ​​of each of a plurality of electronic currencies to be transferred; and an attachment step of attaching a hash value of a root node of the Merkle tree and a signature for the hash value to each of the plurality of electronic currencies, the method comprising:

7. A program for causing a computer to execute the currency processing method according to any one of claims 4 to 6.

Images