WO2025094279A1 - Currency processing device, currency processing method, and program - Google Patents

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

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

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 a signature is placed by the issuing bank for each unit of currency, allowing transactions to be completed only between users.

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.

International Publication No. 2022/254624

The above conventional technology was designed with a fixed denomination system in mind, and had the problem of being unable to efficiently implement a variable denomination system.

The present invention was made in consideration of the above points, and aims to make it possible to efficiently implement the floating denomination system.

In order to solve the above problem, the 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, which 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 the range of leaf nodes among the leaf nodes that are to correspond to the amount; 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 the second electronic currency.

　It will be possible to efficiently implement the floating denomination method.

FIG. 1 is a diagram for explaining an NNL tree. 1 is a diagram for explaining a method of applying an NNL tree to currency in this embodiment. FIG. FIG. 1 is a diagram illustrating an example of a system configuration of an electronic currency system. FIG. 2 is a functional configuration diagram of an issuing bank server. FIG. 2 is a functional configuration diagram of a root certificate authority server. FIG. 2 is a functional configuration diagram of a financial institution server. FIG. 2 is a functional configuration diagram of an intermediate certificate authority server. FIG. 2 is a functional configuration diagram of a user terminal. FIG. 11 is a sequence diagram showing an example of the flow of a currency issuing process. 11 is a flowchart illustrating an example of a procedure for generating a currency ID when issuing currency. FIG. 11 is a sequence diagram showing an example of the flow of a withdrawal process. 13 is a flowchart illustrating an example of a procedure for currency division processing. FIG. 11 is a sequence diagram showing an example of the flow of a payment process. FIG. 11 is a sequence diagram showing an example of the flow of a currency exchange process. FIG. 11 is a sequence diagram showing an example of the flow of a credit process. A sequence diagram showing an example of the flow of a deposit process. FIG. 11 is a sequence diagram showing an example of the flow of a return process. FIG. 11 is a diagram for explaining an MHTree function of a Merkle tree according to the second embodiment; FIG. 11 is a first diagram for explaining an MHPath function of a Merkle tree according to the second embodiment. FIG. 13 is a diagram for explaining an MHVer function of a Merkle tree according to the second embodiment. This is a diagram showing a state in which there are eight pieces of currency. FIG. 13 is a diagram showing a state in which currency additional information including the same signature is added to eight bills. FIG. 2 illustrates an example of a hardware configuration of a computer.

Below, an embodiment of the present invention (present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applicable is not limited to the embodiment described below.

(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. Below, an example of electronic currency with the same value as the Japanese yen will be described, but this is not limiting, and electronic currency with the same value as legal tender in other countries may be used, or may not be the same value as legal tender.

In the electronic currency system according to the first embodiment, a server managed by the issuing bank issues electronic currency (hereafter simply called currency) with a signature. Furthermore, transaction history data is managed by a financial institution other than the issuing bank (e.g. a commercial bank). Furthermore, when transactions occur between users, the users' terminals communicate directly with each other to execute the processing required for the transaction.

In this embodiment, the amount of currency is expressed as a collection of the smallest unit (e.g., 1 yen). Decomposition of currency into units smaller than the smallest unit is not permitted. If the smallest unit is 1 yen, a fixed denomination system in 1 yen units is adopted, thereby (effectively) realizing a variable denomination system (token division).

To guarantee the authenticity of each currency, a signature is added to each currency by the issuing bank's server as described above. If currency is represented by a collection of 1 yen coins, for example, 10,000 signatures must be made when issuing 10,000 yen. In this case, the cost of generating and verifying signatures at the time of issuance and payment 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 the leaf node, so that signatures are generated and verified only once at the time of issuance and payment.

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

Fig. 1 is a diagram for explaining an NNL tree. In Fig. 1, a pseudorandom number generator G: {0,1} ⁿ → {0,1} ²ⁿ that generates a random number twice as long as an input random number is applied to an ID (an n-bit random number in Fig. 1) as a seed to generate a 2n-bit ID. An example is shown in which a pseudorandom number generator G is applied to the first n bits and the second n bits of the 2n bits to generate further 2n-bit random numbers, generating a total of four n-bit IDs (random numbers).

According to the NNL tree, anyone can find the four IDs as long as they know the Seed, so the information for the four IDs (4n bits) can be transmitted using only n bits of information (Seed).

Note that while Figure 1 shows an example with four leaf nodes, the depth of the NNL tree is not limited to any particular value.

Figure 2 is a diagram explaining how to apply an NNL tree to currency in this embodiment.

As described above, in this embodiment, the amount of currency is represented by an NNL tree. Specifically, the leaf node of the NNL tree corresponds to the smallest unit (for example, 1 yen), and the amount of currency corresponding to a certain NNL tree is determined by the number of leaf nodes belonging to that NNL tree. However, if it is assumed that the NNL tree is a binary tree, in this state, only amounts in powers of 2 can be expressed. Therefore, it is made possible to specify the leaf node corresponding to the currency. Specifically, by making it possible to specify information indicating the range of leaf nodes corresponding to the 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 end point. For example, all leaf nodes that belong 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.

For example, if you have a binary NNL tree with a depth of 10, the number of leaf nodes is 1024. If you want to represent 1000 yen, you can specify the start point as 1 and the end point as 1000.

Also, as mentioned above, anyone can derive all the leaf nodes of an NNL tree if they know the seed and depth. Therefore, in this embodiment, the amount of one currency is represented by a set of four parameters.

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

Signatures for currencies (e.g., signatures by the issuer or splitter) are implemented in units of seeds in the NNL tree corresponding to the currency. Therefore, the number of signatures can be determined per number of currencies (NNL trees) rather than per smallest unit of the currency (e.g., 1 yen).

For example, if the start point of the NNL tree in Figure 2 is ID1 and the end point is ID8, the NNL tree represents 8 yen. If you want to split 4 yen pieces, ID1 to ID4, from this 8 yen, for example, the ID (random number) corresponding to node n1, which is the ancestor node of all of ID1 to ID4, becomes the root node of the subtree (NNL tree) corresponding to the 4 yen pieces after the split. Therefore, in this case, the currency ID of the 4 yen pieces after the split will be as follows:
{01110...1,2,ID1,ID4}
By calculating the seed of the root node of the subtree after division, the number of times to calculate random numbers corresponding to each node of the subtree can be reduced. In this case, the currency issued by the issuing bank (T ₀ described later) can be traced based on the signature history.

However, the root node of the original NNL tree may be 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, there is an advantage that the calculation efficiency for verifying by tracing back to the currency issued by the issuing bank (T ₀ described later) is good.

Note that for convenience, Figure 2 shows random numbers corresponding to each node, but the random numbers corresponding to each node do not need to be managed until the currency (NNL tree) is split. In other words, when splitting, the random number of the seed after splitting can be calculated from the seed of the original NNL tree.

Furthermore, the NNL tree is not limited to a binary tree, and 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 that of 5,000 yen/1,000 yen, which are close to everyday cash. In this case, a pseudorandom number generator _G5 : {0,1} ⁿ →{0,1} ⁵ⁿ is used at the 5-branch location, and a pseudorandom number generator _G10 : {0,1} ⁿ →{0,1} ¹⁰ⁿ is used at the 10-branch location.

The configuration and operation of the first embodiment are described below.

(Details of the First Embodiment)
3 is a diagram showing an example of the system configuration of the 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.

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 the currency and transmits it to the financial institution server 20. In addition, the issuing bank server 10 has a function of accepting a withdrawal request from the financial institution server 20.

The root certification authority server 11 is an information processing device that has the functionality 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.

As a preparation step for issuing currency, the root certification authority server 11 generates a root certification key, issues a root certificate, and sends 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 sends the generated financial institution public key certificate issuance information to the issuing bank server 10.

The financial institution server 20 is an information processing device managed by a financial institution (e.g., a commercial bank). The financial institution server 20 is authenticated by the root certification authority server 11 and accepts the issuance of currency from the issuing bank server 10.

The financial institution server 20 also accepts requests for transactions such as withdrawals, currency exchange, deposits, and credit from the user terminal 30. Furthermore, the financial institution server 20 requests refunds from the issuing bank server 10.

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, etc.

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.

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

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, etc.

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 authentication authority server 25. In addition, the user terminal 30 requests transactions such as withdrawals, currency exchanges, deposits, and credit from the financial institution server 20.

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, etc.

A user terminal 30 (e.g., user terminal 30-1) requests payment from another user terminal 30 (e.g., user terminal 30-2) and accepts a payment request. Here, a payment request is a request to accept the execution of a "payment" transaction in which the user makes payment to the other party, and is not a request for the other party to make payment to the user.

(Example of functional configuration of each device according to the first embodiment)
Next, an example of the functional configuration of each device according to the first embodiment will be described.

FIG. 4 is a functional block diagram of the issuing bank server. 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.

The currency issuance key generation unit 101 generates cryptographic key data (hereafter referred to as the currency issuance key) for guaranteeing the validity of message data indicating the issuance of currency (hereafter referred to as the currency issuance message). The currency issuance key includes a private key and a public key.

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.

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.

The currency issuance unit 104 uses the currency issuance key and the financial institution public key certificate issuance information to generate a currency issuance message and transmits the generated currency issuance message to the financial institution server 20.

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 be using for the time being with the issuing bank, returning it to circulation.

The currency issuance key storage unit 106 stores the currency issuance key generated by the currency issuance key generation unit 101.

The refunded currency storage unit 107 stores the currency that has been accepted for refund by the refund acceptance unit 105 (hereinafter referred to as refunded currency).

FIG. 5 is a functional block diagram of the root certification authority server. 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.

The root authentication key generation unit 111 generates cryptographic key data (hereinafter referred to as the root certification key) for verifying the legitimacy of the root certification authority. The root certification key includes a private key and a public key.

The root certificate issuing unit 112 issues certificate data (hereafter referred to as a root certificate) for verifying the validity of certificate data (hereafter referred to as an intermediate certificate) for verifying the validity of an intermediate certification authority, and transmits it to each intermediate certification authority server 25.

The financial institution authentication unit 113 receives encryption key data (hereinafter referred to as the financial institution key) for guaranteeing 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).

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

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

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.

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

The currency issuance certificate issuance reception unit 201 receives the issuance of a currency issuance certificate from the issuing bank server 10.

The financial institution key generation unit 202 generates a financial institution key. The financial institution key includes a private key and a public key.

The financial institution authentication request unit 203 sends a 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.

The currency issuance reception unit 204 accepts the issuance of currency 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.

The withdrawal reception unit 205 accepts withdrawal requests from the user terminal 30 and transmits currency to the user terminal 30.

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 addition information) added to the used currency. Note that currency addition 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.

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. In addition, when the currency exchange/deposit reception unit 207 accepts a request for a deposit, the payment reception unit 209 accepts payment of the amount to be deposited.

The credit acceptance unit 210 receives currency from the user terminal 30 and accepts a credit request. 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.

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

The currency issuance certificate storage unit 212 stores the currency issuance certificate that has been accepted for issuance by the currency issuance certificate issuance acceptance unit 201.

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

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.

The unused currency storage unit 215 stores the currency that is accepted for issuance by the currency issuance acceptance unit 204 as unused currency.

The currency in use memory unit 216 stores the currency for which the withdrawal acceptance unit 205 accepts a withdrawal as the currency in use.

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

The used currency storage unit 218 stores currency that has been used but is not currently in use. Specifically, the used currency storage unit 218 stores as used currency the currency that is received when the exchange/deposit reception unit 207 receives a request for exchange or deposit and the payment reception unit 209 receives the payment.

FIG. 7 is a functional configuration diagram of the intermediate certification authority server. 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.

The intermediate authentication key generation unit 251 generates cryptographic key data (hereinafter referred to as intermediate authentication key) for guaranteeing the legitimacy of the intermediate certification authority. The intermediate authentication key includes a private key and a public key.

The intermediate certificate issuing unit 252 issues an intermediate certificate and sends it to each user terminal 30.

The user authentication unit 253 receives encryption key data (hereinafter referred to as user key) for guaranteeing 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).

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

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.

FIG. 8 is a functional block diagram of the user terminal 30. The user terminal 30 comprises a currency issuance certificate issuance reception unit 301, an intermediate certificate issuance reception unit 302, a user key generation unit 303, a user authentication request unit 304, a withdrawal request unit 305, a payment request unit 306, a payment reception unit 307, an exchange/deposit request unit 308, a credit request unit 309, a currency issuance certificate storage unit 310, an intermediate certificate storage unit 311, a user key storage unit 312, a user public key certificate storage unit 313, and a user currency storage unit 314.

The currency issuance certificate issuance reception unit 301 receives the issuance of a currency issuance certificate from the issuing bank server 10.

The intermediate certificate issuance reception unit 302 receives the issuance of an intermediate certificate from the intermediate certification authority server 25.

The user key generation unit 303 generates a user key. The user key includes a private key and a public key.

The user authentication request unit 304 sends a user key to the intermediate certification authority server 25 to request authentication of the user, and receives a user public key certificate from the intermediate certification authority server 25.

The withdrawal request unit 305 requests a withdrawal from the financial institution server 20 by specifying the face value. The withdrawal request unit 305 receives the currency withdrawn from the financial institution server 20.

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.

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.

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 it, 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 multiple payments from the financial institution server 20 that total the face value to be exchanged. Also, when the exchange/deposit request unit 308 requests a deposit and the financial institution server 20 accepts it, the payment request unit 306 transmits the currency to be deposited and requests payment from the financial institution server 20.

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

The currency issuance certificate storage unit 310 stores the currency issuance certificate that has been accepted for issuance by the currency issuance certificate issuance acceptance unit 301.

The intermediate certificate storage unit 311 stores intermediate certificates that have been accepted for issuance by the intermediate certificate issuance acceptance unit 302.

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

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

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

(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. Below, the concept will be explained using symbols such as _B0 for the issuing bank, _Bi for each financial institution ( _B0 , _B1 , ...), _A0 for the root certificate authority, _Ai for each intermediate certificate authority ( _A0 , _A1 , ...), and _Uj for each user ( _U0 , _U1 , ...).

FIG. 9 is a sequence diagram showing an example of the flow of the currency issuance process. The currency issuance process is started periodically or in response to an operation by a person in charge.

The currency issuance key generation unit 101 of the issuing bank server 10 generates a currency issuance key (step S101). Specifically, the currency issuance key generation unit 101 generates a currency issuance key pair (private key skB _0vy and public key pkB _0vy ) corresponding to an issuance year y and an issuance amount v.

Then, the currency issuance certificate issuing unit 102 transmits the currency issuance certificate CERT (pkB _0vy ) certifying the public key pkB _0vy to each financial institution server 20 (step S102), and transmits it to each user terminal 30 (step S103). The currency issuance certificate issuance acceptance unit 201 of each financial institution server 20 receives the currency issuance certificate CERT (pkB _0vy ) and stores it in the currency issuance certificate storage unit 212. Also, the currency issuance certificate issuance acceptance unit 301 of each user terminal 30 receives the currency issuance certificate CERT (pkB _0vy ) and stores it in the currency issuance certificate storage unit 310.

The issuance amount v is a multiple of the smallest unit (e.g., 1 yen). For example, when issuing currency of 10,000 yen in the year 2021, the currency issuance certificate issuing unit 102 transmits the currency issuance certificate CERT(pkB _{0(10,000 yen)(2021)} ) to each financial institution server 20 and each user terminal 30.

It should be noted that the currency issuance certificate issuing unit 102 does not have to transmit the currency issuance certificate CERT(pkB _0vy ) directly to each financial institution server 20 and each user terminal 30. For example, it may upload the currency issuance certificate CERT(pkB 0vy) to a server device or the like that is publicly available on a communication network, and then have it downloaded to each financial institution server 20 and each user terminal 30.

Next, the root certification key generation unit 111 of the root certification authority server 11 generates a root certification key (step S104). The root certification key includes a private key skA ₀ and a public key pkA _0. Next, the root certificate issuance unit 112 generates a root certificate Auth(pkA ₀ ) by signing with the private key skA ₀ and transmits it to each financial institution server 20 (step S105).

In addition, the root certificate issuing unit 112 does not have to directly send the root certificate Auth(pkA ₀ ) to each financial institution server 20. For example, it may upload it to a server device or the like that is publicly available on a communication network, and then have it downloaded to each financial institution server 20.

Next, the intermediate authentication key generating unit 251 of the intermediate authentication authority server 25 generates an intermediate authentication key (step S106). The intermediate authentication key includes a secret key skA _i and a public key pkA _i .

Next, the intermediate certificate issuance unit 252 signs with the private key skA _i and generates an intermediate certificate Auth(pkA _i , pkA ₀ ) using the root certificate Auth(pkA 0 ). Hereinafter, the intermediate certificate Auth(pkA _i , pkA ₀ ) is written as Auth(pkA _i ). Then, the intermediate certificate issuance unit 252 transmits the generated intermediate certificate Auth(pkA _i ) to each user terminal 30 (step S107). _The intermediate certificate issuance acceptance unit 302 of each user terminal 30 receives the intermediate certificate Auth(pkA _i ) and stores it in the intermediate certificate storage unit 311.

In addition, the intermediate certificate issuance unit 252 does not have to directly transmit the intermediate certificate Auth(pkA _i ) to each user terminal 30. For example, it may upload the intermediate certificate Auth(pkA i ) to a server device or the like that is publicly available on a communication network, and then have the intermediate certificate Auth(pkA i ) downloaded to each user terminal 30.

Next, the user key generation unit 303 of the user terminal 30 generates a user key (step S108). The user key includes a secret key _skUj and a public key _pkUj . Next, the user authentication request unit 304 transmits the public key _pkUj to request user authentication from the intermediate certification authority server 25 (step S109).

The user authentication unit 253 of the intermediate certification authority server 25 generates a user public key certificate Auth(pkUj, _pkAi , _pkA0 ) using the root certificate Auth( _pkA0 ) and the intermediate certificate Auth( _pkAi ) (step S110 ₎ . Hereinafter, the user public key certificate Auth( _pkUj , _pkAi , _pkA0 ) will be written as Auth(pkUj ₎ . The user authentication unit 253 transmits the generated user public key certificate Auth( _pkUj ) to the user terminal 30 (step S111). The user terminal 30 holds the private key _skUj , the public key _pkUj , and the user public key certificate Auth( _pkUj ).

Furthermore, the user authentication unit 253 generates user public key certificate issuance information ( _Uj , _pkUj , Auth( _pkUj )) and stores it in the user public key certificate issuance information storage unit 255. The user public key certificate issuance information ( _Uj , _pkUj , Auth( _pkUj )) includes personal information _Uj of the user.

Next, the financial institution key generation unit 202 of the financial institution server 20 generates a financial institution key (step S112). The financial institution key includes a private key _skBi and a public key _pBi . Next, the financial institution authentication request unit 203 transmits the public key _pBi to request financial institution authentication from the root certification authority server 11 (step S113).

The financial institution authentication unit 113 of the root certification authority server 11 generates a financial institution public key certificate Auth(pkB _i , pkA ₀ ) using the root certificate Auth(pkA ₀ ) (step S114). Hereinafter, the financial institution public key certificate Auth(pkB _i , pkA ₀ ) will be referred to as Auth(pkB _i ). The financial institution authentication unit 113 transmits the generated financial institution public key certificate Auth(pkB _i ) to the financial institution server 20 (step S115). The financial institution server 20 holds the private key skB _i , the public key pkB _i and the financial institution public key certificate Auth(pkB _i ).

Furthermore, the financial institution authentication unit 113 generates financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) and stores it in the financial institution public key certificate issuance information storage unit 116. The financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) includes institution information B _i about the financial institution. Then, the financial institution public key certificate issuance information transmission unit 114 transmits the financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) to the issuing bank server 10 (step S116).

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 _i , pkB _i , Auth(pkB _i )) and stores it in the financial institution public key certificate issuance information storage unit 116 .

Note that the order of the processes from step S108 to step S111 and the processes from step S112 to step S116 is just 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.

In addition, the user terminal 30 may execute the process from step S108 to step S111 multiple times to add a user key.

Next, the currency issuing unit 104 of the issuing bank server 10 uses the financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) stored in the financial institution public key certificate issuance information storage unit 116 to generate a currency issuance message (id ₀ , y, B _i , pkB _i ) that specifies the currency ID id ₀ based on the issuance amount v, the issuance year y, and the financial institution B _i (step S117). Note that the structure of the currency ID is as described in FIG. 2, but the method of generating it will be described later. Here, the currency issuing unit 104 signs (id ₀ , y, B _i , pkB _i ) using the private key skB _0vy of the currency issuance key stored in the currency issuance key storage unit 106. The currency issuing unit 104 transmits the currency issuance message (id ₀ , y, B _i , pkB _i ) with the signature S ₀ attached 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, the generation of the currency issuance message essentially corresponds to the issuance of the currency.

The currency issuance acceptance unit 204 of the financial institution server 20 receives the currency issuance message (id ₀ , y, B _i , pkB _i ) with the signature S ₀ added, and verifies the signature S ₀ using the public key pkB _0vy included in the currency issuance certificate CERT (pkB _0vy ) stored in the currency issuance certificate memory unit 212. Then, the currency issuance acceptance unit 204 generates currency T ₀ := (id ₀ , y, B _i , pkB _i , S ₀ ) and stores it in the unused currency memory unit 215.

The following describes how the currency ID is generated when generating the currency issuance message in step S117.

FIG. 10 is a flowchart illustrating an example of the processing steps for generating a currency ID when issuing currency.

In step S121, the currency issuing unit 104 calculates the depth of the smallest NNL tree that contains leaf nodes equal to or greater than the issuance amount v. The calculation of the depth essentially corresponds to the generation of the structure of the NNL tree. A leaf node equal to or greater than the issuance amount v means a number of leaf nodes that can express the issuance amount v, and refers to a number of leaf nodes 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, then 8 leaf nodes are required. If the NNL tree is a binary tree, the depth of a binary tree that can contain 8 leaf nodes is 3 or greater. Therefore, 3, the smallest value among 3 or greater, becomes the depth of the NNL tree.

Next, the currency issuing unit 104 generates a random number that will become the seed of the NNL tree (S122).

Then, the currency issuing unit 104 determines the start point and end point of the leaf node of the NNL tree that corresponds to the issuance amount v (S123). One of the start point and end point is a leaf node at the end of the NNL tree, and the start point and end point are determined so that the set of consecutive leaf nodes from the start point to the end point matches the issuance amount v. The values of the start point and end point may be expressed by values that indicate 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.

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

11 is a sequence diagram showing an example of the flow of a withdrawal process. The withdrawal process is started in response to an operation of a user _Uj instructing a withdrawal.

The withdrawal request unit 305 of the user terminal 30 transmits denomination information indicating the denomination v of the withdrawal and the public key pkU _j of the user key stored in the user key storage unit 312 to request a withdrawal from the financial institution server 20 (step S201).

The withdrawal acceptance unit 205 of the financial institution server 20 accepts the withdrawal (step S202). Specifically, the withdrawal acceptance unit 205 acquires unused currency _T0 of face value v from the unused currency storage unit 215, and stores it in the currency storage unit 216 as the currency in use ( _T1 , _T0 ) to which currency additional information _T1 :=( _id1 , _pkUj , _S1 ) is added. _S1 is a signature for ( _id1 , _pkUj , _T0 ) using the private key _skBi of the financial institution key. In addition, _id1 is the currency ID of the currency to be transferred based on the face value of the currency in use ( _T1 , _T0 ). When the currency _T0 matches the face value v, the value of _id1 may be the same as _id0 , which is the currency ID of the currency _T0 . Also, when a set of multiple currencies _T0 matches the face value v, the withdrawal acceptance unit 205 may generate a currency ( _T1 , _T0 ) for each of these currencies _T0 . In this case, the value of _id1 of each _T1 may be the same as the corresponding _id1 .

On the other hand, when the currency _T0 exceeds the face value v, or when the set of multiple currencies _T0 exceeds the face value v, the withdrawal acceptance unit 205 divides a part of the currency _T0 to generate a currency ( _T1 , _T0 ). For example, when the face value v is 1000 yen and the currency _T0 is 5000 yen, the withdrawal acceptance unit 205 divides 1000 yen from the currency _T0 to generate a currency ( _T1 , _T0 ) of 1000 yen. Also, for example, when the face value v is 7000 yen and each currency _T0 is 5000 yen, the withdrawal acceptance unit 205 divides 2000 yen from one of the two currencies _T0 to generate a currency ( _T1 , _T0 ) of 2000 yen. The division of the currency _T0 is realized by dividing the NNL tree as the _id0 included in the currency _T0 . This is because the NNL tree also expresses the amount of the currency. The process of dividing such currency is described below.

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, currency additional information can be said to be information that indicates the history of currency transfers.

Next, the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T ₁ , T ₀ ) and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data of the currency in use (T ₁ , T ₀ ) and the financial institution public key certificate Auth(pkB _i ), and stores the currency in use (T ₁ , T ₀ ) in the user currency storage unit 314. (T ₁ , T ₀ ) may be called unused currency.

In step S202, the withdrawal acceptance unit 205 may use the used currency stored in the used currency storage unit 218 instead of the 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 decides whether to use the used currency in accordance with predetermined conditions. For example, the withdrawal acceptance unit 205 may use the used currency when the data volume of the used currency reaches or exceeds a threshold value.

For example, when the withdrawal acceptance unit 205 uses used currency (T _n , ..., T ₀ ) for withdrawal, the update processing unit 206 stores the currency (T _n , ..., T ₀ ) in the state before the update in the updated currency storage unit 217. Then, the update processing unit 206 updates the used currency (T _n , ..., T ₀ ) to currency T ₀ from which the currency additional information (T _n , ..., T ₁ ) has been deleted. Then, the withdrawal acceptance unit 205 stores the currency in use (T n+1 , T ₀ ) obtained by adding currency additional information T _n+1 := (id _{n +1} , pkU _j , S _n+1 ) to the updated currency T ₀ in the currency in use storage unit 216. At this time, the value (contents) of id _n+1 may be the same as the currency ID included in T _n .

Next, the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T _n+1 , T ₀ ) and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data of the currency in use (T _n+1 , T ₀ ) and the financial institution public key certificate Auth(pkB _i ), and stores the currency in use (T _n+1 , T ₀ ) in the user currency storage unit 314.

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 stores in the updated currency storage unit 217 a currency (Tn+ _k , ..., _T1 , _T0 ) that is obtained by combining a currency (Tn _, ..., _T1 , _T0 ) in a state before the previous update with a currency (Tn _+k , ..., Tn ₊₁ , _T0 ) in a state before the current update.

The details of the currency split process that is executed in step S202 when currency splitting is necessary will be described. Figure 12 is a flowchart for explaining an example of the processing procedure for currency splitting.

In step S211, the withdrawal reception unit 205 calculates the depth of the smallest NNL tree (hereinafter referred to as the "destination NNL tree") that contains at least the number of leaf nodes corresponding to the withdrawal denomination v. The method of calculating the depth is the same as in step S121 of FIG. 10.

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

Then, the withdrawal reception 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 pseudorandom number generator G to the seed of the original NNL tree.

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

Next, the withdrawal acceptance unit 205 generates a set of {Seed of the NNL tree to be divided, depth of the NNL tree to be divided, start point, end point} as the currency ID of the currency to be divided (i.e., id ₁ of the currency additional information T ₁ := (id ₁ , pkU _j , S ₁ ) in step S202) (S215).

Next, the withdrawal acceptance unit 205 identifies the next leaf node in the original NNL tree that is the end point of the destination currency in order to match the original currency (T ₀ in S202) with the balance (amount minus the face value v) (S215).

Then, the withdrawal reception 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 addition information when the remaining amount of the original currency is transferred by withdrawal, payment, etc.

13 is a sequence diagram showing an example of the flow of payment processing (transmission processing from a remitter to a recipient) according to the first embodiment. The payment processing is started in response to an operation by a remitter user _Uj to instruct a payment to a recipient user _Uk .

The user terminal 30-1 is the user terminal 30 operated by the remittance user _Uj . The user terminal 30-2 is the user terminal 30 operated by the remittance user _Uk . The payment request unit 306 of the user terminal 30-1 transmits the currency T0, which is the currency data excluding the currency additional information from the currencies (Tn _{-1 ,} ..., _T0 ) whose payment amount is equal to or greater than v, Tn _-1 = (idn _-1 , _pkUj , Sn _-1 ), and the user public key certificate Auth( _pkUj ) to request payment from the user terminal 30-2 (step S301). Note that the currency _T0 does not indicate the current face value of the currencies (Tn _-1 , ..., _T0 ). The current denomination of a currency (T _n-1 , . . . , T ₀ ) can be derived from the start and end points of the NNL tree as id _n-1 of T _n-1 .

The payment acceptance unit 307 of the user terminal 30-2 accepts the payment (step S302). Specifically, the payment acceptance unit 307 verifies the currency T ₀ , S _n-1 of T n-1 = (id _n-1 , pkU _j , S _{n- 1} ), and the user public key certificate Auth(pkU _j ). Here, in verifying the currency, the payment acceptance unit 307 verifies the signature data included in the currency. For example, the payment acceptance unit 307 verifies the signature S ₀ of the currency T ₀ := (id ₀ , y, B _i , pkB _i , S ₀ ). In addition, the payment acceptance unit 307 verifies S n _-1 of T _n-1 = (id _n-1 , pkU _j , S _n-1 ) using pkU _j .

Next, the payment acceptance unit 307 transmits the public key pkU _k of the user key stored in the user key storage unit 312 of the user terminal 30-2 to the user terminal 30-1 (step S303). The payment request unit 306 of the user terminal 30-1 generates id _n as a currency ID, calculates a signature (S _n ) using the private key skU j of the user key stored in the user key storage unit 312 of the user terminal 30-1 for information including id n, the received public key pkU _k , and currency data (for example, T _{n -1 or} the hash value of T n _-1 ), and generates currency additional information T _n := (id _n , pkU _k , S _n ) (step S304). The currency additional information may be called currency data. Here, id _n is a currency ID based on the face value of the currency (T _n , ..., T ₀ ) to be generated. When a currency (T _n-1 , ..., T ₀ ) matches the payment amount v, the value of id _n may be the same as id _n-1 , which is the currency ID of T _n-1 of the currency (T _n-1 , ..., T ₀ ). Also, when a set of multiple currencies (T _n -1 , ..., T ₀ ) matches the payment amount v, the payment request unit 306 may generate currency additional information T _n := (id _n , pkU _k , S _n ) for each of these currencies ( _{T n-1} , ..., T ₀ ). In this case, the value of id _n for each Tn may be the same as the corresponding id _n-1 , and the currency (T _n , ..., T ₀ ) described below is generated for each currency (T _n-1 , ..., T ₀ ).

On the other hand, if the currency (T _n-1 , ..., T ₀ ) exceeds the payment amount v, or if the set of multiple currencies (T _n-1 , ..., T ₀ ) ₀ exceeds the payment amount v, the payment request unit 306 divides a part of the currency (T _n-1 , ..., T _{0 )} to generate id _n . That is, id _n in this case is {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 id _n-1 , which is the currency ID of T _n-1 in the currency (T n-1 , ..., T 0 ), as the division source. The processing procedure for executing such division is as described in FIG. 12. That is, in step S304, the payment request unit 306 generates id _n by executing the processing procedure of FIG. 12.

The payment request unit 306 sends the currency additional information (T _n , ..., T ₁ ) obtained by adding the generated currency additional information T _n := (id _n , pkU _k , S _n ) to the currency additional information (T _n -1 , ..., T ₁ ) to the user terminal 30-2 (step S305).

The payment acceptance unit 307 of the user terminal 30-2 verifies the currency additional information (T _n , ..., T ₁ ). Specifically, the payment acceptance unit 307 verifies S _n using the public key pkU _j . 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 signature S _n of the currency additional information T _n := (id _n , pkU _j , S _n ). The payment acceptance unit 307 stores the currency (T _n , ..., T ₀ ) obtained by adding the currency additional information (T _n , ..., T ₁ ) to the received currency T ₀ in the user currency storage unit 314 of the user terminal 30-2.

14 is a sequence diagram showing an example of the flow of a currency exchange process. The currency exchange process is started in response to an operation of a user _Uj instructing currency exchange.

The exchange/deposit request unit 308 of the user terminal 30 transmits denomination information indicating the denomination v of the exchange and the public key pkU _j of the user key stored in the user key memory unit 312 to request an exchange from the financial institution server 20 (step S401).

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

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).

In addition, when exchanging amounts _v1 , ..., _vx that total up to an exchange amount v, the payment request unit 208 of the financial institution server 20 requests payment from the user terminal 30 for each of _v1 , ..., _vx in accordance with the payment process shown in FIG. 13 (steps S405-1, S405-2).

15 is a sequence diagram showing an example of the flow of a credit process. The credit process is started in response to an operation of a user _Uj instructing credit.

The credit request unit 309 of the user terminal 30 transmits the currency _T0 for which the availability of the currency is to be confirmed, and requests credit from the financial institution server 20 (step S501). The credit acceptance unit 210 of the financial institution server 20 accepts the credit (step S502). Specifically, the credit acceptance unit 210 searches for the currency _T0 in the currently used currency storage unit 216, and if a record including _T0 , for example ( _T1 , _T0 ), exists, the credit acceptance unit 210 transmits a credit result indicating a credit success ack to the user terminal 30 (step S503).

16 is a sequence diagram showing an example of the flow of a deposit process. The deposit process is started in response to an operation of a user _Uj instructing a deposit.

The currency exchange/deposit request unit 308 of the user terminal 30 transmits face amount information indicating the face amount v of the deposit and the public key pkU _j of the user key stored in the user key memory unit 312 to request currency exchange from the financial institution server 20 (step S601).

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

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).

17 is a sequence diagram showing an example of the flow of the refund process. The refund process is started in response to an operation of the financial institution _Bi to instruct a refund.

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 extracts unused currency _T0 from the unused currency storage unit 215 and transmits it to the issuing bank server 10.

Furthermore, when refunding used currency, the refund request unit 211 extracts the used currency (T _n , ..., T ₀ ) from the used currency storage unit 218 and transmits it to the issuing bank server 10. Furthermore, if the used currency (T _m , ..., T _k+1 , T ₀ ) has been updated, the refund request unit 211 reads out the currency additional information (T _k , ..., T ₁ ) before the update from the updated currency storage unit 217, combines it with the used currency (T _m , ..., T _k+1 , T ₀ ), and transmits the combined currency (T _m , ..., T ₀ ) to the issuing bank server 10.

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 confirm the validity of the currency for which the refund has been accepted by verifying the signature included in each currency additional information. For example, the signature S _n included in the currency additional information T _n can be verified using the public key included in the currency additional information T _n-1 .

(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 units of currency, not in units of the minimum unit. In addition, by adopting the NNL tree method, it is possible to reduce the number of hash calculations.

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.

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 deposits wishes to pay 3,000 yen, they can pay two currencies: one 2,000 yen deposit and one 1,000 yen deposit divided from the other 2,000 yen deposit. In this case, 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.

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 the target currencies at once. In the following description of the second embodiment, components having the same functional configuration as those in the first embodiment are given the same reference numerals as those used in the description of the first embodiment, and descriptions of these components are omitted.

(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 document [2]) are used.

FIG. 18 is a diagram for explaining 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.

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. Below, it is written as MHTree(D)->L. Note that Figure 18 shows a dataset with 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.

FIG. 19 is a first diagram for explaining 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.

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

FIG. 20 is a diagram for explaining the MHVer function of a Merkle tree according to the second embodiment. The MHVer function is a function that performs verification using the authentication path of a partial data set.

Specifically, the MHVer function is a function that verifies sub-data D' (in the case of Figure 20, D' = {d0, d4, d5}) from the path AP required for authentication (h001, h01, h11 in Figure 20) and the route h. Below, 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.

(Example of operation of electronic currency system according to the second embodiment)
Here, in step S202 of FIG. 11, it is assumed that the currency matching the face value v is a set of multiple currencies T ₀ :=(T ₀ _t ):=((id ₀ _t, y_t, B _i , pkB _i , S ₀ _t), t=1, ..., s, Σv_t=v). Note that v_t is the amount of the t-th currency T ₀ _t among the currency sets constituting T _0. For example, if each v_t is 10,000 yen and a withdrawal of 80,000 yen is accepted, then s=8. FIG. 21 shows a state in which there are eight T ₀ _t, each of which is 10,000 yen. Note that if there is no currency of 10,000 yen x 8, such as, for example, if there is only 100,000 yen currency in the unused currency storage unit 215 of the financial institution server 20, the withdrawal acceptance unit 205 can execute the process of FIG. 12 to divide the eight 10,000 yen coins from the existing 100,000 yen. In the second embodiment, each T ₀ _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, the currency may be a currency that has been divided (i.e., the NNL tree of the currency ID has been divided) during the transfer process.

The withdrawal acceptance unit 205 of the financial institution server 20 generates a hash tree _L1 = MHTree ({ _{T0_t} } {t = 1, ..., s}) and generates a signature _S1 for the set of the hash value RH (RootHash) of the root node of the hash tree _L1 and _pkUj using the private key skB _i . In other words, the hash tree _L1 is a hash tree generated by assigning each _{T0_t} constituting _T0 to its leaf nodes. For each _{T0_t} , the withdrawal acceptance unit 205 generates a currency in use ( _{T1_t} , _{T0_t} ) by adding currency additional information _{T1_t} : = ( _{id1_t} , _pkUj , RH, _{AP_t} , _S1 ) to the T0_t, and stores it in the currency in use memory unit 216. Here, AP_t is a path required for authenticating RH obtained by MHPath(T ₀ _t, L ₁ )->(AP_t, RH). The value of each id ₁ _t may be the same as the corresponding id ₀ _t. This state is shown in FIG. 22. It can be seen that each T ₁ _t contains the same signature S _1. Hereinafter, a set of currencies (T ₁ _t, T ₀ _t) (here, a set of eight) is written as (T ₁ , T ₀ ).

Next, the withdrawal acceptance unit 205 transmits the currency data set of the currency set (T ₁ , T ₀ ) in use and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data set of the currency set (T ₁ , T ₀ ) in use and the financial institution public key certificate Auth(pkB _i ), and stores the currency set (T ₁ , T ₀ ) in use in the user currency storage unit 314. At this time, the withdrawal request unit 305 needs to verify only one of the currencies (T _{1 _t} , T _{0 _t} ) in (T ₁ , T ₀ ) when verifying the currency set (T ₁ , T ₀ ). Specifically, for any one of T ₁ _t, MHver(AP_t, RH, T ₀ ) is verified to be T, and S ₁ included in the T ₁ _t is verified. For other T ₁ _t, the withdrawal request unit 305 only needs to confirm that they include the same S ₁ as the verified T ₁ _t.

The user of the user terminal 30 can use each of (T ₁ _t, T _{0 _t} ) that constituted the withdrawn currency set (T ₁ , T 0 ) individually (separately). This is because T ₁ _t indicates the history of the currency owner (circulation process) like the currency additional information in the first embodiment, except that it includes RH and AP_t to reduce the signature and verification costs of the currency set, and the authenticity of each currency is guaranteed individually.

The above process is also performed in steps S304 and S305 in FIG. 13 when a payment is made using a set of multiple coins.

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

Furthermore, the process in FIG. 13 can be applied in all other phases (such as at the time of issuance and at the time of redemption). For example, at the time of redemption, it is possible to efficiently transfer the currency to be redeemed in one lump sum.

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

(Hardware configuration example)
An example of a hardware configuration common to the first and second 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 describing the processing contents 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.

The above program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The above program can also be provided via a network, such as the Internet or e-mail.

FIG. 23 is a diagram showing an example of the hardware configuration of the computer. The computer in FIG. 23 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., all of which are interconnected via a bus B.

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 via the drive device 1000 into the auxiliary storage device 1002. 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.

When an instruction to start a program is received, the memory device 1003 reads out and stores the program from the auxiliary storage device 1002. The CPU 1004 realizes the functions related to the device according to 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 GUI (Graphical User Interface) or the like according to a program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, or the like, and is used to input various operation instructions. The output device 1008 outputs the results of calculations. Note that the above computer may be equipped with a GPU (Graphics Processing Unit) or TPU (Tensor processing unit) instead of the CPU 1004, or may be equipped with a GPU or TPU in addition to the CPU 1004. In that case, the processes may be shared and executed, for example, the GPU or TPU executes processes that require special calculations such as neural networks, and the CPU 1004 executes other processes.

(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 each of 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 examples of a currency processing device.

The above describes in detail the embodiments of the present invention, but the present invention is not limited to such specific embodiments, and various modifications and variations are possible within the scope of the gist of the present invention as described in the claims.

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 certification 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 (7)

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 amount to be transferred divided 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 the 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 to be associated with the amount among the leaf nodes;
a currency additional information generating unit configured to generate information indicating the random number, the depth, and the range as information to be added to the second electronic currency;
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 of electronic currency to be issued by the smallest unit of the electronic currency;
A random number generation unit configured to generate random numbers to be seeds of the NNL tree;
a leaf node determination unit configured to determine a range of leaf nodes to be associated with the amount among the leaf nodes;
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;
A currency processing device comprising: a Merkle tree generator configured to generate a Merkle tree based on hash values of each of a plurality of electronic currencies to be transferred;
an appender configured to append 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;
A currency processing device comprising: a depth calculation step for 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 for 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 the first electronic currency;
a random number calculation step for calculating a random number corresponding to the root node based on a seed of the first NNL tree;
a leaf node determination step for determining a range of leaf nodes to be associated with the amount among the leaf nodes;
a currency additional information generating step of generating information indicating the random number, the depth, and the range as information to be added to the second electronic currency;
A computer implemented currency processing method. 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 of electronic currency to be issued by the smallest unit of the electronic currency;
A random number generation procedure for generating random numbers to be seeds of the NNL tree;
a leaf node determination step for determining a range of leaf nodes to be associated with the amount among the leaf nodes;
a currency additional information generating step of generating information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued;
A computer implemented currency processing method. A Merkle tree generation step of generating a Merkle tree based on hash values of each of a plurality of electronic currencies to be transferred;
a hash value of a root node of the Merkle tree and a signature for the hash value are added to each of the plurality of electronic currencies;
A computer implemented currency processing method. A program for causing a computer to execute the currency processing method according to any one of claims 4 to 6.

Images