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

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

Info

Publication number
WO2025220136A1
WO2025220136A1 PCT/JP2024/015182 JP2024015182W WO2025220136A1 WO 2025220136 A1 WO2025220136 A1 WO 2025220136A1 JP 2024015182 W JP2024015182 W JP 2024015182W WO 2025220136 A1 WO2025220136 A1 WO 2025220136A1
Authority
WO
WIPO (PCT)
Prior art keywords
currency
unit
electronic currency
issuance
refunded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/015182
Other languages
English (en)
French (fr)
Inventor
哲矢 奥田
俊之 宮澤
和輝 山村
正幸 阿部
利徳 福永
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
NTT Inc USA
Original Assignee
Nippon Telegraph and Telephone Corp
NTT Inc USA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp, NTT Inc USA filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2024/015182 priority Critical patent/WO2025220136A1/ja
Publication of WO2025220136A1 publication Critical patent/WO2025220136A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the present invention relates to an electronic currency system, a currency processing device, a currency processing method, and a program.
  • Patent Document 1 With token-based electronic cash systems, it is (univocally) difficult to detect duplicate use due to duplicating electronic currency until the currency is returned to the issuing bank, so methods for detecting duplicate use have been proposed (for example, Patent Document 1).
  • the present invention was made in consideration of the above points, and aims to improve the efficiency of detecting duplicate use of electronic currency.
  • FIG. 1 is a diagram for explaining an NNL tree.
  • FIG. 10 is a diagram for explaining a method of applying an NNL tree to currency in this embodiment.
  • 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. 10 is a functional configuration diagram of an intermediate certificate authority server.
  • FIG. 2 is a functional configuration diagram of a user terminal.
  • FIG. 10 is a sequence diagram showing an example of the flow of a currency issuance process.
  • 10 is a flowchart illustrating an example of a processing procedure for generating a currency ID when issuing currency.
  • FIG. 10 is a flowchart illustrating an example of a processing procedure for generating a currency ID when issuing currency.
  • FIG. 10 is a sequence diagram illustrating an example of the flow of a withdrawal process.
  • 10 is a flowchart illustrating an example of a procedure for dividing currency.
  • FIG. 10 is a sequence diagram showing an example of the flow of a payment process.
  • FIG. 10 is a sequence diagram showing an example of the flow of a currency exchange process.
  • FIG. 10 is a sequence diagram showing an example of the flow of a credit process.
  • FIG. 10 is a sequence diagram showing an example of the flow of a refund process.
  • 10 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use has occurred in the first embodiment.
  • FIG. 10 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use has occurred in the first embodiment.
  • FIG. 10 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use has occurred in the
  • FIG. 2 is a diagram illustrating an example of the configuration of a refunded currency storage unit 108 in the first embodiment.
  • FIG. 10 is a diagram for explaining a method of expressing a range of currency denominations in the second embodiment.
  • 10 is a flowchart illustrating an example of a process procedure for determining whether or not a dual use has occurred in the second embodiment.
  • FIG. 10 is a diagram illustrating an example of the configuration of a refunded currency storage unit 108 in the second embodiment.
  • FIG. 11 is a diagram for explaining an MHTree function of a Merkle tree according to the third embodiment.
  • FIG. 11 is a first diagram for explaining an MHPath function of a Merkle tree according to the third embodiment.
  • FIG. 11 is a diagram for explaining the MHVer function of a Merkle tree according to the third embodiment. This is a diagram showing a state where there are eight coins.
  • FIG. 10 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 the hardware configuration of a computer.
  • 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 be 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.
  • a server managed by the issuing bank issues electronic currency (hereafter simply referred to as currency) with a signature.
  • transaction history data is managed by a financial institution other than the issuing bank (for example, a commercial bank).
  • the users' terminals communicate directly with each other to execute the processing required for the transaction.
  • the amount of currency is expressed as a collection 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, then by expressing the currency as a collection of 1 yen units using a fixed denomination system, it is possible to (effectively) realize a variable denomination system (token division).
  • a signature from the issuing bank's server is affixed to each currency. If currency is represented by a collection of 1 yen coins, for example, the issuance of 10,000 yen requires 10,000 signatures. In this case, the cost of generating and verifying signatures at the time of issuance and payment becomes unrealistic. Furthermore, to enable detection of duplicate currency use, it is conceivable to store already withdrawn currency and, when new currency is withdrawn, check whether that currency is stored as already withdrawn currency. However, depending on the amount of the withdrawal, the number of currency to be withdrawn becomes enormous, and the burden of the confirmation process for duplicate use also becomes heavy.
  • a space representing the face value of one currency is constructed using a single tree structure with the smallest unit (1 yen) as the leaf node. This reduces the number of signature generation and verification times at the time of issuance and payment to one, and also streamlines currency management for double use detection.
  • an NNL tree (reference document [1]) is used as such a tree structure, and when issuing a signature, it is issued only once, and the data size is compressed nonlinearly.
  • Fig. 1 is a diagram illustrating an NNL tree.
  • a pseudo-random number generator G ⁇ 0, 1 ⁇ n ⁇ ⁇ 0, 1 ⁇ 2n , which generates a random number twice as long as the 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.
  • the pseudo-random number generator G is applied to each of the first n bits and the second n bits of the 2n bits to generate further 2n-bit random numbers, resulting in a total of four n-bit IDs (random numbers).
  • an NNL tree anyone can find the four IDs as long as they know the Seed (in an NNL tree, the random number for each node can be calculated from the random number (Seed) of the root node), so the information for the four IDs (4n bits) can be transmitted using only n bits of information (Seed).
  • 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.
  • currency amounts are represented by an NNL tree.
  • the leaf nodes of an NNL tree correspond to the smallest unit (for example, 1 yen), and the number of leaf nodes belonging to a certain NNL tree determines the currency amount corresponding to that NNL tree.
  • the NNL tree is a binary tree, this allows only amounts in powers of 2 to be represented. Therefore, it is made possible to specify the leaf nodes corresponding to a currency.
  • the currency corresponding to that NNL tree is the number of all leaf nodes included in that range x 1 yen.
  • the start and end points 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. Either the start point or the end point is assumed to be the leaf node at the end (first or last) in the order of the leaf nodes.
  • the information indicating the range is not limited to the start point and 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.
  • 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.
  • the amount of one currency is represented by a set of four parameters.
  • Signatures for currencies are implemented by signing in units of seeds in the NNL tree corresponding to the currency. Therefore, the number of signatures can be determined per currency (NNL tree) rather than per smallest unit of currency (e.g., 1 yen).
  • the NNL tree represents 8 yen. If you want to split 4 yen pieces, ID1 to ID4, from this 8 yen, you can consider using the ID (random number) corresponding to node n1, which is the ancestor node of all ID1 to ID4, as the root node of the subtree (NNL tree) corresponding to the 4 yen pieces after splitting.
  • the currency ID of the 4 yen pieces after splitting will be as follows: ⁇ 01110...1,2,ID1,ID4 ⁇
  • the number of times to calculate the random numbers corresponding to each node of the subtree can be reduced.
  • the currency issued by the issuing bank (T 0 described below) can be traced based on the signature history.
  • the root node of the original NNL tree may be used as the root node of the NNL tree after division.
  • the currency ID of the 4 yen currency after division will be as follows: ⁇ 01010...1,3,ID1,ID4 ⁇ This has the advantage of being computationally efficient for verifying by tracing back to the currency issued by the issuing bank (T 0 , described later).
  • the case where the latter (the root node of the original NNL tree is used as the root node of the NNL tree after division) is described, but the former (the smallest NNL tree including a leaf node after division is used as the NNL tree after division) may also be used.
  • 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.
  • NNL tree currency
  • 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 that of everyday cash, such as 5,000 yen/1,000 yen.
  • a pseudorandom number generator G5 ⁇ 0,1 ⁇ n ⁇ ⁇ 0,1 ⁇ 5n can be used at the 5-branch location
  • a pseudorandom number generator G10 ⁇ 0,1 ⁇ n ⁇ ⁇ 0,1 ⁇ 10n can be used at the 10-branch location.
  • the electronic currency system 1 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 currency and transmits it to the financial institution server 20.
  • the issuing bank server 10 has the function of accepting refund requests 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 encrypted communications.
  • the root certification authority server 11 may be implemented using 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.
  • the root certification authority server 11 As a preparation step for issuing currency, the root certification authority server 11 generates a root certification key and issues a root certificate, which it then sends 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 transaction requests 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.
  • the individual financial institution servers 20 when distinguishing between the individual financial institution servers 20, the individual 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 functionality of an intermediate certification authority in encrypted communications.
  • the intermediate certification authority server 25 may be implemented using the same hardware as the financial institution server 20, and is expected to be managed by the financial institution, but is not limited to this.
  • the intermediate certification authority server 25 As a preparation step for issuing currency, the intermediate certification authority server 25 generates an intermediate authentication key, issues an intermediate certificate, and sends it to the user terminal 30.
  • the intermediate certification authority server 25 also authenticates each user and generates user public key certificate issuance information.
  • intermediate certification authority servers 25 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. The user terminal 30 also requests transactions such as withdrawals, currency exchange, deposits, and credit from the financial institution server 20.
  • the individual user terminals 30 when distinguishing between the individual user terminals 30, the individual user terminals 30 will be referred to as user terminal 30-1, user terminal 30-2, etc.
  • a user terminal 30 requests payment from another user terminal 30 (e.g., user terminal 30-2) or accepts a payment request.
  • a payment request means a request to accept the execution of a "payment" transaction in which the user pays the other party, and does not mean a request from the other party to pay the user.
  • FIG 4 is a functional configuration diagram of the issuing bank server.
  • the issuing bank server 10 comprises 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 issuance unit 104, a refund acceptance unit 105, a currency issuance key storage unit 106, an issued currency storage unit 107, and a refunded currency storage unit 108.
  • the currency issuance key generation unit 101 generates cryptographic key data (hereinafter referred to as the currency issuance key) to ensure the validity of message data indicating the issuance of currency (hereinafter 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. Financial institution public key certificate issuance information will be described later.
  • the currency issuance unit 104 uses the currency issuance key and 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 acceptance unit 105 accepts refunds from the financial institution server 20 and stores the refunded currency in the refunded currency storage unit 108.
  • a refund is a transaction in which each financial institution deposits currency that it will not be using for the time being with the issuing bank and returns 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 issued currency storage unit 107 stores information about the currency related to the currency issuance message generated by the currency issuing unit 104 (i.e., the currency to be issued).
  • the refunded currency storage unit 108 stores the currency for which the refund acceptance unit 105 has accepted the refund (hereinafter referred to as the refunded currency).
  • the root certificate issuance unit 112 issues certificate data (hereinafter referred to as “root certificate”) to guarantee the legitimacy of certificate data (hereinafter referred to as “intermediate certificate”) that guarantees the legitimacy of the intermediate certification authority, and transmits it to each intermediate certification authority server 25.
  • root certificate certificate data
  • intermediate certificate certificate data
  • 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 a request for authentication.
  • 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 sends the generated financial institution public key certificate to the financial institution server 20 that requested authentication.
  • 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 implemented using 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 configuration diagram of the financial institution server.
  • the financial institution server 20 comprises 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 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 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.
  • 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 sends 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 (additional currency information) added to used currency. Note that additional currency information is added through payment transactions, which will be described later.
  • the withdrawal acceptance unit 205 transmits unused currency (hereinafter referred to as unused currency) or currency updated by the update processing unit 206 to the user terminal 30.
  • the exchange/deposit acceptance unit 207 accepts requests for exchange or deposit from the user terminal 30. Specifically, when the exchange/deposit acceptance unit 207 accepts a request for exchange from the user terminal 30, the payment acceptance 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. Furthermore, when the exchange/deposit acceptance unit 207 accepts a request for deposit, the payment acceptance 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 the 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 currency issuance certificates whose issuance has been accepted 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 received by the financial institution authentication request unit 203 from the root certification authority server 11.
  • the unused currency storage unit 215 stores the currency 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 accepts payment.
  • FIG. 7 is a functional configuration diagram of the intermediate certification authority server.
  • the intermediate certification authority server 25 comprises 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 encryption key data (hereinafter referred to as the intermediate authentication key) to ensure the legitimacy of the intermediate certification authority.
  • the intermediate authentication key includes a private key and a public key.
  • the intermediate certificate issuance 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 verifying the legitimacy of each user from the user terminal 30 and accepts a request for authentication.
  • 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 sends the generated user public key certificate to the user terminal 30 that requested authentication.
  • 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 configuration diagram of the user terminal 30.
  • the user terminal 30 comprises a currency issuance certificate issuance acceptance unit 301, an intermediate certificate issuance acceptance 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 acceptance 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 acceptance unit 302 accepts 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 from the financial institution server 20 multiple payments that total the face value to be exchanged. Furthermore, 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 sends currency to request credit from the financial institution server 20 and receives the credit result.
  • the user currency storage unit 314 stores the currency currently being used by the user. Specifically, the user currency storage unit 314 stores the currency received by the withdrawal request unit 305 from the financial institution server 20 and the currency received by the payment acceptance unit 307 from the financial institution server 20 or another user terminal 30.
  • FIG. 9 is a sequence diagram showing an example of the flow of the currency issuance process.
  • the currency issuance process is initiated periodically or in response to an operation by a person in charge.
  • 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 then transmits it to each user terminal 30 (step S103).
  • the currency issuance certificate issuance accepting 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.
  • the currency issuance certificate issuance accepting 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).
  • 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.
  • 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, but may, for example, upload it to a server device or the like that is publicly available on a communication network and have it downloaded to each financial institution server 20 and each user terminal 30.
  • 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 skA0 and a public key pkA0 .
  • the root certificate issuance unit 112 generates a root certificate Auth( pkA0 ) by signing with the private key skA0 and transmits it to each financial institution server 20 (step S105).
  • the root certificate issuing unit 112 does not have to send the root certificate Auth(pkA 0 ) directly to each financial institution server 20, but may instead upload it to a server device or the like that is publicly available on a communication network and have it downloaded to each financial institution server 20.
  • the intermediate authentication key generating unit 251 of the intermediate certification 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 .
  • the intermediate certificate issuance unit 252 signs with the private key skA i and generates an intermediate certificate Auth(pkA i , pkA 0 ) using the root certificate Auth(pkA 0 ) .
  • the intermediate certificate Auth(pkA i , pkA 0 ) will be referred to as Auth(pkA i ).
  • 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.
  • the intermediate certificate issuing unit 252 does not have to send the intermediate certificate Auth(pkA i ) directly to each user terminal 30, but may instead upload it to a server device or the like that is publicly available on a communication network and have it downloaded to each user terminal 30.
  • the user key generation unit 303 of the user terminal 30 generates a user key (step S108).
  • the user key includes a private key skU j and a public key pkU j .
  • the user authentication request unit 304 sends the public key pkU j 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).
  • the user public key certificate Auth( pkUj , pkAi , pkA0 ) will be referred to 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 ).
  • 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 the user's personal information Uj .
  • 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 pkBi .
  • the financial institution authentication request unit 203 transmits the public key pkBi 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 0 ) using the root certificate Auth(pkA 0 ) (step S114).
  • the financial institution public key certificate Auth(pkB i , pkA 0 ) 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 ).
  • 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.
  • the financial institution public key certificate issuance information transmission unit 114 then 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 )).
  • the user terminal 30 may execute the processes from step S108 to step S111 multiple times to add a user key.
  • 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 0 , y, B i , pkB i ) specifying id 0 , which is a currency ID based on the issuance amount v, the issuance year y, and the financial institution B i, and records the currency ID id 0 in the issued currency storage unit 107 (step S117). Therefore, a currency ID is recorded for each issued currency in the issued currency storage unit 107.
  • a currency ID is recorded for each issued currency in the issued currency storage unit 107.
  • the currency issuing unit 104 signs (id 0 , 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 0 , y, B i , pkB i ) with the signature S 0 attached to the financial institution server 20 (step S118).
  • 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.
  • the currency issuing unit 104 determines the start and end points of the leaf nodes of the NNL tree that correspond to the issuance amount v (S123).
  • One of the start and end points is a leaf node at the end of the NNL tree, and the start and end points are determined so that the set of consecutive leaf nodes from the start to the end point matches the issuance amount v.
  • the values of the start and end points may be expressed by values that indicate the order of the leaf nodes in the NNL tree. In other words, it is not necessary to calculate random numbers that correspond to the start and end points in the NNL tree.
  • 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 the withdrawal process, which is started in response to an operation by user Uj to instruct withdrawal.
  • the withdrawal request unit 305 of the user terminal 30 sends denomination information indicating the denomination v of the withdrawal and the public key pkU j of the user key stored in the user key memory unit 312 to request a withdrawal from the financial institution server 20 (step S201).
  • S1 is a signature for ( id1 , pkUj , T0 ) using the private key skBi of the financial institution key.
  • id1 is the currency ID of the currency to be transferred based on the face value of the currency in use ( T1 , T0 ).
  • the value of id1 may be the same as id0 , which is the currency ID of currency T0 . Furthermore, if 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 .
  • the withdrawal acceptance unit 205 divides a portion of currency T0 to generate currency ( T1 , T0 ). For example, if face value v is 1,000 yen and currency T0 is 5,000 yen, the withdrawal acceptance unit 205 divides 1,000 yen from currency T0 to generate currency ( T1 , T0 ) of 1,000 yen. Also, for example, if face value v is 7,000 yen and each currency T0 is 5,000 yen, the withdrawal acceptance unit 205 divides 2,000 yen from one of the two currencies T0 to generate currency ( T1 , T0 ) of 2,000 yen.
  • the division of currency T0 is realized by dividing the NNL tree as id0 included in currency T0 . This is because the NNL tree also represents the amount of currency. Such currency splitting procedures are described below.
  • additional currency information signed by the transfer source is cumulatively added to the currency. Therefore, additional currency information can be said to be information that indicates the history of currency transfers.
  • the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T 1 , T 0 ) 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 1 , T 0 ) and the financial institution public key certificate Auth(pkB i ), and stores the currency in use (T 1 , T 0 ) in the user currency storage unit 314.
  • (T 1 , T 0 ) may also be called unused currency.
  • the withdrawal acceptance unit 205 may, if necessary, 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.
  • 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 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.
  • the update processing unit 206 stores the currency (T n , ..., T 0 ) in its pre-update state in the updated currency storage unit 217. Then, the update processing unit 206 updates the used currency (T n , ..., T 0 ) to currency T 0 from which the currency additional information (T n , ..., T 1 ) has been deleted.
  • the value (contents) of id n+1 may be the same as the currency ID included in T n .
  • the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T n+1 , T 0 ) 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 0 ) and the financial institution public key certificate Auth(pkB i ), and stores the currency in use (T n+1 , T 0 ) 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.
  • the update processing unit 206 stores in the updated currency storage unit 217 a currency ( Tn +k , ..., T1 , T0 ) that is obtained by combining the currency (Tn, ..., T1 , T0 ) in the state before the previous update with the currency (Tn +k , ..., Tn+ 1 , T0 ) in the state before the current update.
  • step S202 the currency split process that is executed when currency splitting is necessary will be described in detail.
  • Figure 12 is a flowchart illustrating an example of the processing procedure for currency splitting.
  • step S211 the withdrawal acceptance 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 for calculating this depth is the same as in step S121 in Figure 10.
  • the withdrawal acceptance unit 205 determines a node to be the root node of the destination NNL tree from among the nodes of the NNL tree serving as the currency ID of the currency to be split (hereinafter referred to as the "original NNL tree") (S212).
  • the destination NNL tree is a subtree of the original NNL tree. Because the depth of the destination NNL tree has been calculated, it is possible to identify at which level of the original NNL tree the root node of the destination NNL tree is a node.
  • the withdrawal acceptance unit 205 determines the node located at the end of the level (the ancestor of the starting point of the original NNL tree) as the root node of the destination NNL tree. For example, if the split described in Figure 2 is performed, node N2 in Figure 2 is determined to be the root node of the destination NNL tree.
  • 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 explained in Figure 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.
  • the withdrawal acceptance unit 205 associates ⁇ Seed of the original NNL tree, depth of the original NNL tree, next leaf node, end point of the original NNL tree ⁇ with the original currency as a temporary currency ID (S214).
  • This temporary currency ID is used as the currency ID of the currency additional information when the remaining amount of the original currency is transferred by withdrawal, payment, etc.
  • User terminal 30-1 is a user terminal 30 operated by user Uj on the remittance side.
  • User terminal 30-2 is a user terminal 30 operated by user Uk on the receipt side.
  • 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 0 ) can be derived from the start and end points of the NNL tree as id n-1 of T n-1 .
  • the currency additional information may also be referred to as currency data.
  • id n is a currency ID based on the face value of the currency (T n , ..., T 0 ) to be generated. If a currency (T n-1 , ..., T 0 ) 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 0 ).
  • the value of id n for each Tn may be the same as the corresponding id n-1
  • currencies (T n , ..., T 0 ), described below, are generated for each currency (T n-1 , ..., T 0 ).
  • the payment request unit 306 divides a portion 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 the payment request unit 306 dividing the NNL tree as id n-1 , which is the currency ID of T n-1 in the currencies (T n-1 , ..., T 0 ), by the payment amount v.
  • the processing procedure for performing 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 .
  • FIG. 14 is a sequence diagram showing an example of the flow of the exchange process, which is started in response to an operation by a user Uj to instruct exchange.
  • the exchange/deposit request unit 308 of the user terminal 30 sends face value information indicating the exchange face value v 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/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).
  • the payment request unit 306 requests payment from the financial institution server 20 in accordance with the payment process shown in FIG. 13 (step S404).
  • the payment request unit 208 of the financial institution server 20 requests payment from the user terminal 30 for each of v 1 , ..., v x in accordance with the payment process shown in Figure 13 (steps S405-1, S405-2).
  • 15 is a sequence diagram showing an example of the flow of the credit processing, which is started in response to an operation of the user Uj instructing credit.
  • the credit request unit 309 of the user terminal 30 transmits the currency T0 for which the user wishes to confirm its applicability, 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 the currently used currency storage unit 216 for the currency T0 , and if a record including T0 , for example ( T1 , T0 ), is found, it transmits a credit result indicating a credit success ack to the user terminal 30 (step S503).
  • FIG. 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 by a user Uj to instruct a deposit.
  • the exchange/deposit request unit 308 of the user terminal 30 sends face value information indicating the face value v of the deposit and the public key pkU j of the user key stored in the user key memory unit 312 to request a deposit from the financial institution server 20 (step S601).
  • 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).
  • the payment request unit 306 requests payment from the financial institution server 20 in accordance with the payment process shown in FIG. 13 (step S604).
  • 17 is a sequence diagram showing an example of the flow of the refund process, which is started in response to an operation of the financial institution Bi to instruct 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.
  • 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.
  • the refund request unit 211 extracts the used currency (T n , ..., T 0 ) 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 0 ) has been updated, the refund request unit 211 reads the currency additional information (T k , ..., T 1 ) before the update from the updated currency storage unit 217, combines it with the used currency (T m , ..., T k+1 , T 0 ), and transmits the combined currency (T m , ..., T 0 ) 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 determines whether the currency to be refunded (hereinafter referred to as "currency (T n , . . . , T 0 )") is a case of double spending, and if it is not a case of double spending, stores information about the currency in the refunded currency storage unit 108. At this time, the refund acceptance unit 105 may confirm the legitimacy of the currency for which the refund was accepted by verifying the signature included in each currency additional information of the refunded currency data. 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 .
  • step S702 we will explain in detail the process of determining whether the currency to be refunded has been used twice in step S702.
  • FIG. 18 is a flowchart illustrating an example of the processing steps for determining whether a device is being used twice in the first embodiment.
  • step S801 the refund acceptance unit 105 accepts the refund of currency (T n , ..., T 0 ).
  • this currency will be referred to as the "target currency T n .”
  • step S801 is the same step as step S702 in FIG. 17.
  • the target currency T n may be a currency into which a portion of the face value of the currency at the time of issuance (hereinafter referred to as the "original currency") T 0 has been divided, or may be a currency that has not been divided from the original currency T 0 .
  • FIG 19 is a diagram showing an example configuration of the refunded currency storage unit 108 in the first embodiment.
  • the refunded currency storage unit 108 stores, for each refunded currency (hereinafter referred to as "refunded currency"), the currency ID at issue, the currency ID at refund, the depth, the start point, and the end point, etc.
  • the currency ID at issue is the currency ID when the original currency of the refunded currency was issued. If the refunded currency is split during the circulation process, there may be multiple currencies with the same currency ID at issue.
  • the currency ID at refund is the currency ID when the refunded currency is refunded. If the refunded currency is not split during the circulation process, the currency ID at refund matches the currency ID at issue.
  • the depth, start point, and end point of the currency ID at refund differ from the currency ID at issue.
  • the depth, start point, and end point are the depth, start point, and end point included in the currency ID at refund.
  • the refunded currency storage unit 108 stores information indicating the refunded range in an NNL tree (binary tree), which is a space representing the face value of the original currency.
  • the public key pkUx included in idx which is the currency ID of Tx
  • the public key pkUx included in idx is the public key of the person X who received Tx . Therefore, it is possible to identify X as the person who made the double-spent.
  • the number of comparisons of withdrawn currency with previously withdrawn currency can also be reduced. For example, if 10,000 yen is withdrawn, it is not necessary to handle 10,000 records. Therefore, detection of double spending of electronic currency can be made more efficient.
  • the range of currency denominations at the time of redemption was specified by the start and end points. In other words, whether or not the start and end points overlap was used to determine whether or not double-spending occurred.
  • the denomination of a certain currency is converted into the form of a sum of powers of 2
  • the range of denominations of that certain currency is expressed by a list of random numbers at nodes corresponding to each of the powers of 2 that make up that sum in an NNL tree (binary tree), which is a space that represents the denomination of the original currency.
  • whether or not double-spending occurred is determined by whether or not such random numbers overlap (or collide).
  • Figure 20 is a diagram for explaining the method of representing a range of currency denominations in the second embodiment.
  • the binary tree in Figure 20 is an NNL tree, which is a space representing currency denominations.
  • the code beginning with r assigned to each node is an identifier for each node and also a random number assigned to each node. If the smallest unit of currency is 1 yen, then one leaf node of the NNL tree in Figure 20 corresponds to 1 yen. Therefore, the NNL tree in Figure 20 can represent a maximum of 8 yen.
  • the exponent 3 corresponds to the position (depth) of the node in the NNL tree (binary tree).
  • the node with a depth of 3 is the node that corresponds to the range of 8. Therefore, in Figure 20, the range of 8 yen is the root node r.
  • 8 yen can be replaced with a list of random numbers called random number ⁇ r ⁇ .
  • random number list Such a representation of face value using a list of random numbers will be referred to as a "random number list" hereinafter.
  • node r is a node whose descendants are only leaf nodes corresponding to 8 yen.
  • node r01 corresponds to 2 yen, but the subtree whose root is node r01 is part of the subtree whose root is node r0. Therefore, ⁇ r0, r01 ⁇ is equivalent to ⁇ r0 ⁇ and would represent 4 yen, not 6 yen. Therefore, a list of random numbers such as ⁇ r0, r01 ⁇ will not be generated.
  • FIG. 21 is a flowchart illustrating an example of the processing steps for determining whether a device is being used twice in the second embodiment.
  • the random number list is a set of random numbers corresponding to the root nodes of each subtree in the set of subtrees that includes only the list of leaf nodes.
  • the refund acceptance unit 105 executes a loop process including steps S855 to S857 for each random number included in the random number list ⁇ r_1, ..., r_b ⁇ .
  • the random number being processed in this loop process will be referred to as "r_x" hereinafter.
  • step S855 the refund acceptance unit 105 determines whether r_x has already been refunded. Specifically, the refund acceptance unit 105 determines whether r_x has already been stored in the refunded currency storage unit 108.
  • FIG. 22 is a diagram showing an example of the configuration of the refunded currency storage unit 108 in the second embodiment.
  • the refunded currency storage unit 108 stores an associated currency ID at the time of issue and a refunded random number.
  • the currency ID at the time of issue is the currency ID at the time the currency from which the refunded currency is derived (the original currency) was issued.
  • the refunded random number is a random number corresponding to the range of the refunded face value of the original currency. If the original currency is refunded without being divided during the circulation process, the random number (seed value) of the currency ID of the original currency is stored as the refunded random number. If part of the face value of the original currency is divided during the circulation process, a random number corresponding to the range of that part is stored as the refunded random number.
  • step S855 the refund acceptance unit 105 determines whether r_x is stored as a refunded random number in the refunded currency storage unit 108.
  • the refund acceptance unit 105 determines that the range of r_x in the target currency T n is a double spend (S856). In this case, the refund acceptance unit 105 may output information indicating the double spend. Furthermore, as described in step S806 of FIG. 18, the refund acceptance unit 105 may identify the timing of the double spend or the person who made the double spend, and output the identification result.
  • the refund candidate list refers to list-format data for storing random numbers that are candidates for registration in the refunded currency storage unit 108 as refunded random numbers.
  • the reason r_x is not registered in the refunded currency storage unit 108 at the time of step S857 is because it has not been confirmed that there is no double use in the range corresponding to r_x. Specifically, it is possible that the random number corresponding to a descendant node of r_x or the random number corresponding to an ancestor of r_x has already been registered in the refunded currency storage unit 108 as a refunded random number. If the random number corresponding to a descendant node of r_x is a refunded random number, then part of the range corresponding to r_x is double used.
  • step S857 r_x is registered in the recovery candidate list, as there is at least no exact duplicated use of r_x, and from step S858 onwards, processing is executed to detect duplicated use that cannot be detected by loop processing.
  • step S858 the refund acceptance unit 105 determines whether the refund candidate list is empty. If the refund candidate list is empty (No in S858), the processing in Figure 21 ends.
  • the refund acceptance unit 105 acquires a list of refunded random numbers associated with the currency ID of the original currency T0 of the target currency Tn (hereinafter referred to as the "refunded random number list") from the refunded currency storage unit 108 (FIG. 22) (S859).
  • the refund acceptance unit 105 determines whether the refunded random number list is empty (i.e., whether one or more corresponding refunded random numbers have been acquired) (S860). If the refunded random number list is empty (No in S860), the descendant or ancestor random numbers of each random number included in the refund candidate list have not yet been refunded, so the process proceeds to step S866.
  • the refund acceptance unit 105 If the refunded random number list contains one or more refunded random numbers (No in S860), the refund acceptance unit 105 generates a binary tree (NNL tree) based on the random number and depth of the original currency T0 (S861). At this time, the random number of each node of the binary tree is also calculated. Note that the entire binary tree does not need to be generated. To reduce the amount of calculation, it is sufficient to identify the random number of the node on the path from the node corresponding to the random number to the root node and the random number of the node on the path from the random number to the leaf node for each random number included in the refund candidate list.
  • the refund acceptance unit 105 determines whether any of the random numbers included in the refund candidate list conflict with the list of refunded random numbers (S862).
  • a random number that conflicts with a certain random number refers to a random number that is an ancestor or descendant of that random number.
  • the refund acceptance unit 105 obtains a list of the random numbers that are ancestors or descendants of that random number in the binary tree generated in step S861, and determines whether any of the random numbers included in the list are included in the list of refunded random numbers.
  • step S862 If there are no random numbers included in the list of candidates for redemption that conflict with the list of already-recovered random numbers (hereinafter referred to as "colliding random numbers") (No in S862), proceed to step S866. In this case, there is no double use of any of the random numbers included in the list of candidates for redemption.
  • the refund acceptance unit 105 determines that the range of the conflicting random number in the target currency T n is a double-spend (S863). In this case, the refund acceptance unit 105 may output information indicating the double-spend. Furthermore, as described in step S806 of FIG. 18, the refund acceptance unit 105 may identify the timing of the double-spend or the person who committed the double-spend, and output the identification result. Next, the refund acceptance unit 105 deletes the conflicting random number from the refund candidate list (S864). Next, the refund acceptance unit 105 determines whether the refund candidate list is empty. If the refund candidate list is empty (No in S865), the processing of FIG. 21 ends. If one or more random numbers are stored in the refund candidate list (Yes in S865), the processing proceeds to step S866.
  • step S866 the refund acceptance unit 105 registers each random number included in the refund candidate list as a refunded random number in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the original currency T0 of the target currency Tn (S866).
  • the range corresponding to the random numbers included in the refund candidate list at this point is the range in which no double use has been detected.
  • step S867 onwards is intended to reorganize the refunded currency storage unit 108 ( Figure 22) and reduce storage capacity consumption.
  • step S867 the refund receiving unit 105 acquires a list of refunded random numbers stored in the refunded currency storage unit 108 in association with the currency ID of the original currency T0 of the target currency Tn .
  • the refund acceptance unit 105 determines whether the entire range of the face value of the original currency T0 (all leaf nodes from the start point to the end point of the original currency T0 ) is covered by the set of refunded random numbers (S868). In other words, it determines whether the sum of the ranges corresponding to each refunded random number matches the entire range of the face value of the original currency T0 .
  • the refund acceptance unit 105 determines that the entire range of denominations of the original currency T0 has been refunded (S869). Subsequently, the refund acceptance unit 105 registers the random numbers of the original currency T0 as refunded random numbers in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the original currency T0 (S870). At this time, the refund acceptance unit 105 may reduce the amount of information stored in association with the original currency T0 by deleting other refunded random numbers stored in the refunded currency storage unit 108 (FIG. 22) in association with the currency ID of the original currency T0 .
  • the second embodiment can also achieve the same effects as the first embodiment.
  • the third embodiment differs from the first embodiment in that a hash tree of currencies is generated and the root of the hash tree is signed, thereby signing all the target currencies together.
  • components that have the same functional configuration as the first embodiment are assigned the same reference numerals as used in the description of the first embodiment, and their description will be omitted.
  • FIG. 23 is a diagram explaining the MHTree function of a Merkle tree according to the third embodiment.
  • the MHTree function is a function that generates a hash tree from a dataset.
  • the vertex h is called the root.
  • MHTree(D)->L it is written as MHTree(D)->L.
  • the value of each leaf node is the hash value of the data corresponding to that leaf node.
  • the seventh and eighth leaf nodes are filled with "00" to enable the construction of a binary tree.
  • FIG 24 is the first diagram illustrating the MHPath function of a Merkle tree according to the third embodiment.
  • the MHPath function is a function that generates the path required to authenticate a partial data set.
  • FIG. 25 is a diagram illustrating the MHVer function of a Merkle tree according to the third embodiment.
  • the MHVer function is a function that performs verification using the authentication path of a partial data set.
  • D' ⁇ d0, d4, d5 ⁇
  • 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.
  • FIG. 26 shows a state in which there are eight T0_t , each of which is 10,000 yen.
  • each T 0 _t is not limited to a currency immediately after issuance, but may be a currency that has been transferred after issuance (i.e., to which currency additional information has been added).
  • the currency may be a currency that has been divided (i.e., a division of the NNL tree of the currency ID) during the transfer process.
  • the hash tree L1 is a hash tree generated by assigning each T0_t that constitutes T0 to its leaf nodes.
  • AP_t is the path required for authenticating RH obtained by MHPath(T 0 _t, L 1 ) -> (AP_t, RH).
  • the value of each id 1 _t may be the same as the corresponding id 0 _t. This state is shown in FIG. 27.
  • each T 1 _t is the same S 1.
  • the set of currencies (T 1 _t, T 0 _t) (here, eight sets) will be referred to as (T 1 , T 0 ).
  • the withdrawal acceptance unit 205 transmits the currency data set of the currency set in use (T 1 , T 0 ) 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 in use (T 1 , T 0 ) and the financial institution public key certificate Auth(pkB i ), and stores the currency set in use (T 1 , T 0 ) in the user currency storage unit 314.
  • the withdrawal request unit 305 needs to verify only one currency (T 1 _t, T 0 _t) of ( T 1 , T 0 ).
  • T 1 _t it is verified that MHver(AP_t, RH, T 0 ) is T, and it is also verified that S 1 is included in that T 1 _t.
  • the withdrawal request unit 305 simply confirms that they include the same S 1 as the T 1 _t being verified.
  • the user of the user terminal 30 can individually (separately) use each of (T 1 _t, T 0 _t) that constituted the withdrawn currency set (T 1 , T 0 ). This is because, like the currency additional information in the first embodiment, T 1 _t indicates the history of the currency owner (circulation process), and the authenticity of each currency is individually guaranteed, except that it includes RH and AP_t to reduce the signature and verification costs of the currency set.
  • the third embodiment reduces the signature and verification costs when transferring multiple currencies.
  • Each unit of each device included in the electronic currency system 1 can be realized, for example, by having a computer execute a program that describes the processing content described in this embodiment.
  • this "computer” may be a physical machine or a virtual machine on the cloud.
  • the "hardware” described here is virtual hardware.
  • the above program can be recorded on a computer-readable recording medium (such as portable memory) and stored or distributed.
  • the above program can also be provided via a network, such as the Internet or email.
  • FIG. 28 is a diagram showing an example of the hardware configuration of the computer.
  • the computer in FIG. 28 has a drive device 1000, auxiliary storage device 1002, memory device 1003, CPU 1004, interface device 1005, display device 1006, input device 1007, output device 1008, etc., all of which are interconnected via bus B.
  • the program that realizes processing on the computer is provided by a recording medium 1001, such as a CD-ROM or memory card.
  • a recording medium 1001 such as a CD-ROM or memory card.
  • the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000.
  • the program does not necessarily have to be installed from the recording medium 1001; it can also be downloaded from another computer via a network.
  • the auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.
  • the memory device 1003 reads and stores the program from the auxiliary storage device 1002.
  • the CPU 1004 implements the functions of 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 GUI (Graphical User Interface) or the like according to the program.
  • the input device 1007 is composed of a keyboard, mouse, buttons, touch panel, etc., and is used to input various operation instructions.
  • the output device 1008 outputs the results of calculations.
  • 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 this case, processing may be shared, with the GPU or TPU executing processing that requires special calculations, such as neural networks, and the CPU 1004 executing other processing.

Landscapes

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

Abstract

電子通貨システムは、或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている判定部、を有することで、電子通貨の二重使用の検知を効率化する。

Description

電子通貨システム、通貨処理装置、通貨処理方法及びプログラム
　本発明は、電子通貨システム、通貨処理装置、通貨処理方法及びプログラムに関する。
　電子通貨については長年研究が行われている。日本銀行等の法定通貨の発行銀行が電子通貨を発行し、金融機関を通じてインターネット上で流通させる実験が行われている。電子現金の研究においては、電子通貨単位ごとに発行銀行による署名を打つことで、利用者間のみで取引を完結させることができるトークン型電子現金方式が提案されている。
　トークン型電子現金方式では通貨が発行銀行に還収されるまで、電子通貨の複製による二重使用の検知が（一義的には）困難であるため、二重使用検知を行う方式が提案されている（例えば、特許文献１）。
奥田, 他、"トークン型電子現金方式の二重使用検知およびプライバシーに関する形式検証の考察"、情報処理学会, 研究報告コンピュータセキュリティ（CSEC）,2023-CSEC-100(66),1-8 (2023-02-27) , 2188-8655
　しかしながら、従来技術では、電子通貨が還収された際に、電子通貨単位ごと（例えば、１円ごと）に二重使用の有無を確認するために、還収された電子通貨を電子通貨単位で管理する必要があり、斯かる管理を行うためのデータベースのサイズや二重使用の有無確認のための計算コストの面において効率的ではない。
　本発明は、上記の点に鑑みてなされたものであって、電子通貨の二重使用の検知を効率化することを目的とする。
　そこで上記課題を解決するため、電子通貨システムは、或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている判定部、を有する。
　電子通貨の二重使用の検知を効率化することができる。
ＮＮＬ木を説明するための図である。 本実施の形態における通貨に対するＮＮＬ木の適用方法を説明するための図である。 電子通貨システムのシステム構成の一例を示す図である。 発行銀行サーバの機能構成図である。 ルート認証局サーバの機能構成図である。 金融機関サーバの機能構成図である。 中間認証局サーバの機能構成図である。 利用者端末の機能構成図である。 通貨発行処理の流れの一例を示すシーケンス図である。 通貨発行時における通貨ＩＤの生成処理の処理手順の一例を説明するためのフローチャートである。 引出処理の流れの一例を示すシーケンス図である。 通貨の分割処理の処理手順の一例を説明するためのフローチャートである。 支払処理の流れの一例を示すシーケンス図である。 両替処理の流れの一例を示すシーケンス図である。 与信処理の流れの一例を示すシーケンス図である。 預入処理の流れの一例を示すシーケンス図である。 還収処理の流れの一例を示すシーケンス図である。 第１実施形態における二重使用の判定処理の処理手順の一例を説明するためのフローチャートである。 第１実施形態における還収済通貨記憶部１０８の構成例を示す図である。 第２実施形態における通貨の額面の範囲の表現方法を説明するための図である。 第２実施形態における二重使用の判定処理の処理手順の一例を説明するためのフローチャートである。 第２実施形態における還収済通貨記憶部１０８の構成例を示す図である。 第３実施形態に係るマークルツリーのＭＨＴｒｅｅ関数について説明するための図である。 第３実施形態に係るマークルツリーのＭＨＰａｔｈ関数について説明するための第一の図である。 第３実施形態に係るマークルツリーのＭＨＶｅｒ関数について説明するための図である。 ８枚の通貨が有る状態を示す図である。 ８枚の通貨に対して同じ署名を含む通貨付加情報が付加された状態を示す図である。 コンピュータのハードウェア構成例を示す図である。
　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
　（第１実施形態の概要）
　第１実施形態に係る電子通貨システムは、特定の発行銀行にて発行する電子通貨のシステムである。電子通貨の価値は法定通貨と同じ価値が保証されるものが提唱されている。以下、日本円と同価値の電子通貨を例に説明するが、これに限られず、他の国に法定通貨と同価値の電子通貨であっても良いし、法定通貨と同価値の電子通貨でなくても良い。
　第１実施形態に係る電子通貨システムでは、発行銀行が管理するサーバが署名をして電子通貨（以下、単に通貨という）を発行する。また、発行銀行以外の金融機関（例えば市中銀行）にて取引の履歴データを管理する。また、利用者同士の取引では、お互いの利用者の端末同士が直接通信して、取引のための処理を実行する。
　本実施の形態において、通貨の金額は、最小単位（例えば、１円）の集合として表現される。最小単位未満への通貨の分解は許容されない。最小単位が１円であれば、固定額面方式の１円単位の集合で通貨を表現することで、（実質的に）変動額面方式（トークンの分割）を実現することができる。
　各通貨の真正性を保証するため、上記したように各通貨には発行銀行のサーバによる署名が付加される。１円の集合で通貨を表現する場合、例えば、１００００円の発行の際には、１００００回の署名が行われる必要がある。この場合、発行時・支払時などの署名生成及び検証コストが非現実的となる。また、通貨の二重使用の検知を可能とするため、既に還収された通貨を記憶しておき、通貨が新たに還収された際に当該通貨が既に還収された通貨として記憶されているか否かを確認することが考えられるが、還収の金額に応じて、還収される通貨の数が膨大になるとともに、二重使用のための確認処理の負荷も大きくなる。そこで、本実施の形態では、最小単位（１円）をＬｅａｆ（葉ノード）とする１つの木構造で１つの通貨の額面を表現する空間を構成することで、発行時・支払時などの署名生成及び検証回数を１回とすると共に、二重使用の検知のための通貨の管理を効率化する。
　本実施の形態では、斯かる木構造としてＮＮＬ木（参考文献［１］）を採用し、発行時も署名を１回に、かつ、データサイズを非線形に圧縮する。
　図１は、ＮＮＬ木を説明するための図である。図１では、Ｓｅｅｄ（シード）としてのＩＤ（図１ではｎビットの乱数）に対して、入力された乱数から２倍の長さの乱数を生成する疑似乱数生成器Ｇ：｛０，１｝ｎ→｛０，１｝２ｎを適用して、２ｎビットのＩＤを生成する。その２ｎビットの前半のｎビットと後半のｎビットとのそれぞれに対して疑似乱数生成器Ｇを適用することで更に２ｎビットの乱数を生成し、合計で４つのｎビットのＩＤ（乱数）が生成される例が示されている。
　ＮＮＬ木よれば、Ｓｅｅｄさえ分かれば誰でも４つのＩＤを求めることができるため（ＮＮＬ木において、各ノードの乱数は、ルートノードの乱数（Ｓｅｅｄ）から算出可能であるため）、４つのＩＤ（４ｎビット）の情報をｎビットの情報（Ｓｅｅｄ）のみで伝達可能となる。
　なお、図１では、葉ノードが４つである例を示したが、ＮＮＬ木の深さは特定のものに限定されない。
　図２は、本実施の形態における通貨に対するＮＮＬ木の適用方法を説明するための図である。
　上記したように、本実施の形態において、通貨の金額はＮＮＬ木によって表現される。具体的には、ＮＮＬ木の葉ノードが最小単位（例えば、１円）に対応し、或るＮＮＬ木に属する葉ノードの数によって当該ＮＮＬ木に対応する通貨の金額が決まる。但し、このままでは、ＮＮＬ木が２分木であることを前提とした場合、２の冪乗での金額しか表現できない。そこで、通貨に対応する葉ノードを指定可能とする。具体的には、ＮＮＬ木の全葉ノードのうち、通貨に対応する葉ノードの範囲を示す情報を指定可能とすることで、当該ＮＮＬ木に対応する通貨が、当該範囲に含まれる全葉ノードの数×１円であることを表現可能とする。本実施の形態では、斯かる範囲を示す情報として当該範囲の開始点及び終了点が用いられる例を示す。開始点とは、当該範囲の開始位置となる葉ノードをいう。終了点とは、当該範囲の終了位置となる葉ノードをいう。開始点及び終了点のいずれか一方は、葉ノードの並び順において端（最初又は最後）の葉ノードであるとする。但し、当該範囲を示す情報は開始点及び終了点に限られない。例えば、当該範囲に属する全ての葉ノードが指定されてもよいし、開始点と当該範囲の大きさ（つまり、金額）又は終了点と当該範囲の大きさが指定されてもよい。
　例えば、深さが１０である２分木のＮＮＬ木であれば、葉ノードの数は１０２４個である。１０００円を表現したいのであれば、例えば、開始点を１とし、終了点を１０００と指定すればよい。
　また、上記したように、ＮＮＬ木は、Ｓｅｅｄと深さが分かれば、誰でも全ての葉ノードを導出することができる。そこで、本実施の形態では、１つの通貨の金額を４つのパラメータの組によって表現する。
　｛ＮＮＬ木のＳｅｅｄ、当該ＮＮＬ木の深さ、開始点、終了点｝
　以下、これら４つのパラメータの組を「通貨ＩＤ」という。
　通貨に対する署名（例えば、発行元又は分割元による署名）は、当該通貨に対応するＮＮＬ木のＳｅｅｄ単位で行うことで実現される。したがって、署名の数を通貨の最小単位（例えば、１円）ごとではなく、通貨（ＮＮＬ木）の数ごととすることができる。
　例えば、図２のＮＮＬ木の開始点がＩＤ１、終了点がＩＤ８である場合、当該ＮＮＬ木は８円を表現する。この８円から、ＩＤ１～ＩＤ４までの４円を分割したい場合、例えば、ＩＤ１～ＩＤ４までの全ての祖先ノードであるノードｎ１に対応するＩＤ（乱数）が分割後の４円に対応する部分木（ＮＮＬ木）のルートノードとすることが考えられる。この場合、分割後の４円の通貨の通貨ＩＤは以下のようになる。
｛０１１１０…１，２，ＩＤ１,ＩＤ４｝
　分割後の部分木のルートノードのＳｅｅｄを計算しておくことで、その後における当該部分木の各ノードに対応する乱数の計算回数を削減することができる。この場合、発行銀行によって発行された通貨（後述のＴ０）には署名の履歴に基づいて辿ることができる。
　但し、分割元のＮＮＬ木のルートノードを分割後のＮＮＬ木のルートノードとしてもよい。この場合、分割後の４円の通貨の通貨ＩＤは以下のようになる。
｛０１０１０…１，３，ＩＤ１,ＩＤ４｝
　この場合、発行銀行によって発行された通貨（後述のＴ０）まで辿って検証するための計算効率が良いという利点が有る。本実施の形態では、後者（分割元のＮＮＬ木のルートノードを分割後のＮＮＬ木のルートノードとする場合）を採用した場合について説明するが、前者（分割後の葉ノードを含む最小のＮＮＬ木を分割後のＮＮＬ木とする場合）が採用されてもよい。
　なお、図２には、便宜上、各ノードに対応する乱数が示されているが、各ノードに対応する乱数は、通貨（ＮＮＬ木）の分割が行われるまでは管理されなくてよい。換言すれば、分割の際に分割元のＮＮＬ木のＳｅｅｄから、分割後のＳｅｅｄの乱数が計算されればよい。
　また、ＮＮＬ木は２分木に限られず、２，５，１０分木でもよい。２分岐／５分岐・・・と繰り返せば、日常の現金に近い５０００円／１０００円等に葉ノードの数が完全に一致するＮＮＬ木を生成することができる。この場合、５分岐の箇所では疑似乱数生成器Ｇ５：｛０，１｝ｎ→｛０，１｝５ｎを使用し、１０分岐の箇所では疑似乱数生成器Ｇ１０：｛０，１｝ｎ→｛０，１｝１０ｎを使用すればよい。
　以下、第１実施形態に係る構成と動作を説明する。
　（第１実施形態の詳細）
　図３は、電子通貨システムのシステム構成の一例を示す図である。第１実施形態に係る電子通貨システム１は、発行銀行サーバ１０と、ルート認証局サーバ１１と、金融機関サーバ２０と、中間認証局サーバ２５と、利用者端末３０と、を備える。これらの各装置は、インターネット等の通信ネットワークを介して、互いに通信可能に接続されている。
　発行銀行サーバ１０は、通貨を発行する発行銀行が管理する情報処理装置である。発行銀行サーバ１０は、通貨の発行を示すメッセージデータに署名データを付加して金融機関サーバ２０に送信する。他に、発行銀行サーバ１０は、金融機関サーバ２０からの還収の要求を受け付ける機能を有する。
　ルート認証局サーバ１１は、暗号通信におけるルート認証局の機能を有する情報処理装置である。ルート認証局サーバ１１は、発行銀行サーバ１０と同一のハードウェアによって実現されても良く、発行銀行によって管理されることを想定するが、それに限られない。
　ルート認証局サーバ１１は、通貨の発行の準備段階として、ルート認証鍵を生成してルート証明書を発行し、中間認証局サーバ１２に送信する。また、ルート認証局サーバ１１は、各金融機関を認証し、金融機関公開鍵証明書発行情報を生成し、生成された金融機関公開鍵証明書発行情報を発行銀行サーバ１０に送信する。
　金融機関サーバ２０は、金融機関（例えば市中銀行）が管理する情報処理装置である。金融機関サーバ２０は、ルート認証局サーバ１１による認証を受けて、発行銀行サーバ１０から通貨の発行を受け付ける。
　また、金融機関サーバ２０は、利用者端末３０から、引出、両替、預入、与信などの取引の要求を受け付ける。さらに、金融機関サーバ２０は、発行銀行サーバ１０に還収を要求する。
　なお、以下の説明において各金融機関サーバ２０を区別する時は、各金融機関サーバ２０を金融機関サーバ２０－１、金融機関サーバ２０－２等のように記載する。
　中間認証局サーバ２５は、暗号通信における中間認証局の機能を有する情報処理装置である。中間認証局サーバ２５は、金融機関サーバ２０と同一のハードウェアによって実現されても良く、金融機関によって管理されることを想定するが、それに限られない。
　中間認証局サーバ２５は、通貨の発行の準備段階として、中間認証鍵を生成して中間証明書を発行し、利用者端末３０に送信する。また、中間認証局サーバ２５は、各利用者を認証し、利用者公開鍵証明書発行情報を生成する。
　なお、以下の説明において各中間認証局サーバ２５を区別する時は、各中間認証局サーバ２５を中間認証局サーバ２５－１、中間認証局サーバ２５－２等のように記載する。
　利用者端末３０は、通貨を利用する利用者（個人消費者、店舗等）が利用する情報処理装置である。利用者端末３０は、取引を開始する前に、中間認証局サーバ２５による認証を受ける。また、利用者端末３０は、引出、両替、預入、与信などの取引を金融機関サーバ２０に要求する。
　なお、以下の説明において各利用者端末３０を区別する時は、各利用者端末３０を利用者端末３０－１、利用者端末３０－２等のように記載する。
　利用者端末３０（例えば利用者端末３０－１）は、他の利用者端末３０（例えば利用者端末３０－２）に支払を要求したり、支払の要求を受け付けたりする。ここで、支払の要求とは、利用者が相手方に支払う「支払」取引の実行を受け付けるように要求することであり、相手方に利用者への支払いを要求することではない。
　（第１実施形態に係る各装置の機能構成例）
　次に、第１実施形態に係る各装置の機能構成例について説明する。
　図４は、発行銀行サーバの機能構成図である。発行銀行サーバ１０は、通貨発行鍵生成部１０１と、通貨発行証明書発行部１０２と、金融機関公開鍵証明書発行情報取得部１０３と、通貨発行部１０４と、還収受付部１０５と、通貨発行鍵記憶部１０６と、発行通貨記憶部１０７と、還収済通貨記憶部１０８と、を備える。
　通貨発行鍵生成部１０１は、通貨の発行を示すメッセージデータ（以下、通貨発行メッセージという）の正当性を保証するための暗号鍵データ（以下、通貨発行鍵という）を生成する。通貨発行鍵は、秘密鍵と公開鍵とを含む。
　通貨発行証明書発行部１０２は、通貨発行鍵の公開鍵を証明するための証明書を示すデータ（以下、通貨発行証明書という）を生成して、生成された通貨発行証明書を各金融機関サーバ２０および各利用者端末３０に送信する。
　金融機関公開鍵証明書発行情報取得部１０３は、ルート認証局サーバ１１から金融機関公開鍵証明書発行情報を取得する。金融機関公開鍵証明書発行情報については、後述する。
　通貨発行部１０４は、通貨発行鍵および金融機関公開鍵証明書発行情報を使用して、通貨発行メッセージを生成し、生成した通貨発行メッセージを金融機関サーバ２０に送信する。
　還収受付部１０５は、金融機関サーバ２０から還収を受け付けて、還収済通貨記憶部１０８に還収された通貨を格納する。還収とは、各金融機関が当面使用しない通貨を発行銀行に預け入れて、流通に戻す取引である。
　通貨発行鍵記憶部１０６は、通貨発行鍵生成部１０１によって生成された通貨発行鍵を記憶する。
　発行通貨記憶部１０７は、通貨発行部１０４が生成した通貨発行メッセージに係る通貨（すなわち、発行対象の通貨）に関する情報を記憶する。
　還収済通貨記憶部１０８は、還収受付部１０５が還収を受け付けた通貨（以下、還収済通貨という）を記憶する。
　図５は、ルート認証局サーバの機能構成図である。ルート認証局サーバ１１は、ルート認証鍵生成部１１１と、ルート証明書発行部１１２と、金融機関認証部１１３と、金融機関公開鍵証明書発行情報送信部１１４と、ルート認証鍵記憶部１１５と、金融機関公開鍵証明書発行情報記憶部１１６と、を備える。
　ルート認証鍵生成部１１１は、ルート認証局の正当性を保証するための暗号鍵データ（以下、ルート証明鍵という）を生成する。ルート証明鍵は、秘密鍵と公開鍵とを含む。
　ルート証明書発行部１１２は、中間認証局の正当性を保証するための証明書データ（以下、中間証明書）の正当性を保証するための証明書データ（以下、ルート証明書という）を発行して、各中間認証局サーバ２５に送信する。
　金融機関認証部１１３は、金融機関サーバ２０から各金融機関の正当性を保証するための暗号鍵データ（以下、金融機関鍵という）を受信して、認証の要求を受け付ける。そして、金融機関認証部１１３は、金融機関鍵の公開鍵を証明するための証明書を示すデータ（以下、金融機関公開鍵証明書という）を生成し、生成された金融機関公開鍵証明書を、認証を要求した金融機関サーバ２０に送信する。さらに、金融機関認証部１１３は、金融機関公開鍵証明書の発行を示す情報（以下、金融機関公開鍵証明書発行情報という）を、生成する。
　金融機関公開鍵証明書発行情報送信部１１４は、生成された金融機関公開鍵証明書発行情報を、発行銀行サーバ１０に送信する。なお、発行銀行サーバ１０とルート認証局サーバ１１とが同一のハードウェアによって実現される場合には、金融機関公開鍵証明書発行情報送信部１１４は不要である。
　ルート認証鍵記憶部１１５は、ルート認証鍵生成部１１１によって生成されたルート認証鍵を記憶する。
　金融機関公開鍵証明書発行情報記憶部１１６は、金融機関認証部１１３によって生成された金融機関公開鍵証明書発行情報を記憶する。
　図６は、金融機関サーバの機能構成図である。金融機関サーバ２０は、通貨発行証明書発行受付部２０１と、金融機関鍵生成部２０２と、金融機関認証要求部２０３と、通貨発行受付部２０４と、引出受付部２０５と、更新処理部２０６と、両替・預入受付部２０７と、支払要求部２０８と、支払受付部２０９と、与信受付部２１０と、還収要求部２１１と、通貨発行証明書記憶部２１２と、金融機関鍵記憶部２１３と、金融機関公開鍵証明書記憶部２１４と、未使用通貨記憶部２１５と、使用中通貨記憶部２１６と、更新済通貨記憶部２１７と、使用済通貨記憶部２１８と、を備える。
　通貨発行証明書発行受付部２０１は、発行銀行サーバ１０から通貨発行証明書の発行を受け付ける。
　金融機関鍵生成部２０２は、金融機関鍵を生成する。金融機関鍵は、秘密鍵と公開鍵とを含む。
　金融機関認証要求部２０３は、ルート認証局サーバ１１に、金融機関鍵を送信して金融機関の認証を要求し、ルート認証局サーバ１１から金融機関公開鍵証明書を受信する。
　通貨発行受付部２０４は、発行銀行サーバ１０から通貨の発行を受け付ける。具体的には、通貨発行受付部２０４は、発行銀行サーバ１０から通貨発行メッセージを受信し、受信した通貨発行メッセージの署名を、通貨発行証明書に含まれる公開鍵を用いて検証する。
　引出受付部２０５は、利用者端末３０から引出の要求を受け付けて、利用者端末３０に通貨を送信する。
　更新処理部２０６は、利用者端末３０からの引出の要求に対して、必要に応じて使用済みの通貨（以下、使用済通貨という）を更新する。具体的には、更新処理部２０６は、使用済通貨に付加された情報（通貨付加情報）を削除する。なお、通貨付加情報は、後述する支払の取引によって付加される。引出受付部２０５は、未使用の通貨（以下、未使用通貨という）または更新処理部２０６によって更新された通貨を利用者端末３０に送信する。
　両替・預入受付部２０７は、利用者端末３０から両替または預入の要求を受け付ける。具体的には、両替・預入受付部２０７が、利用者端末３０から両替の要求を受け付けると、支払受付部２０９が、両替する額面の支払を受け付けて、支払要求部２０８が、合計が両替する額面となる複数の支払いを要求する。また、両替・預入受付部２０７が、預入の要求を受け付けると、支払受付部２０９が、預け入れる額面の支払を受け付ける。
　与信受付部２１０は、利用者端末３０から通貨を受信して与信の要求を受け付ける。与信受付部２１０は、通貨が使用中の通貨（以下、使用中通貨という）であるか否かを判定し、判定結果を利用者端末３０に送信する。
　還収要求部２１１は、発行銀行サーバ１０に通貨を送信して、還収を要求する。
　通貨発行証明書記憶部２１２は、通貨発行証明書発行受付部２０１が発行を受け付けた通貨発行証明書を記憶する。
　金融機関鍵記憶部２１３は、金融機関鍵生成部２０２が生成した金融機関鍵を記憶する。
　金融機関公開鍵証明書記憶部２１４は、金融機関認証要求部２０３がルート認証局サーバ１１から受信した金融機関公開鍵証明書を記憶する。
　未使用通貨記憶部２１５は、通貨発行受付部２０４が発行を受け付けた通貨を未使用通貨として記憶する。
　使用中通貨記憶部２１６は、引出受付部２０５が引出を受け付けた通貨を使用中通貨として記憶する。
　更新済通貨記憶部２１７は、更新処理部２０６によって更新された通貨（以下、更新済通貨という）を更新前の状態で記憶する。
　使用済通貨記憶部２１８は、使用された通貨であって、使用中でない通貨を記憶する。具体的には、使用済通貨記憶部２１８は、両替・預入受付部２０７が両替または預入の要求を受け付けて、支払受付部２０９によって支払を受け付けて受信した通貨を、使用済通貨として記憶する。
　図７は、中間認証局サーバの機能構成図である。中間認証局サーバ２５は、中間認証鍵生成部２５１と、中間証明書発行部２５２と、利用者認証部２５３と、中間認証鍵記憶部２５４と、利用者公開鍵証明書発行情報記憶部２５５と、を備える。
　中間認証鍵生成部２５１は、中間認証局の正当性を保証するための暗号鍵データ（以下、中間認証鍵という）を生成する。中間認証鍵は、秘密鍵と公開鍵とを含む。
　中間証明書発行部２５２は、中間証明書を発行して、各利用者端末３０に送信する。
　利用者認証部２５３は、利用者端末３０から各利用者の正当性を保証するための暗号鍵データ（以下、利用者鍵という）を受信して、認証の要求を受け付ける。そして、利用者認証部２５３は、利用者鍵の公開鍵を証明するための証明書を示すデータ（以下、利用者公開鍵証明書という）を生成し、生成された利用者公開鍵証明書を、認証を要求した利用者端末３０に送信する。さらに、利用者認証部２５３は、利用者公開鍵証明書の発行を示す情報（以下、利用者公開鍵証明書発行情報という）を、生成する。
　中間認証鍵記憶部２５４は、中間認証鍵生成部２５１が生成した中間認証鍵を記憶する。
　利用者公開鍵証明書発行情報記憶部２５５は、利用者認証部２５３が生成した利用者公開鍵証明書発行情報を記憶する。
　図８は、利用者端末３０の機能構成図である。利用者端末３０は、通貨発行証明書発行受付部３０１と、中間証明書発行受付部３０２と、利用者鍵生成部３０３と、利用者認証要求部３０４と、引出要求部３０５と、支払要求部３０６と、支払受付部３０７と、両替・預入要求部３０８と、与信要求部３０９と、通貨発行証明書記憶部３１０と、中間証明書記憶部３１１と、利用者鍵記憶部３１２と、利用者公開鍵証明書記憶部３１３と、利用者通貨記憶部３１４と、を備える。
　通貨発行証明書発行受付部３０１は、発行銀行サーバ１０から通貨発行証明書の発行を受け付ける。
　中間証明書発行受付部３０２は、中間認証局サーバ２５から中間証明書の発行を受け付ける。
　利用者鍵生成部３０３は、利用者鍵を生成する。利用者鍵は、秘密鍵と公開鍵とを含む。
　利用者認証要求部３０４は、中間認証局サーバ２５に、利用者鍵を送信して利用者の認証を要求し、中間認証局サーバ２５から利用者公開鍵証明書を受信する。
　引出要求部３０５は、額面を指定して金融機関サーバ２０に引出を要求する。引出要求部３０５は、金融機関サーバ２０から引き出された通貨を受信する。
　支払要求部３０６は、支払う通貨を送信して、金融機関サーバ２０または他の利用者端末３０に支払を要求する。
　支払受付部３０７は、支払われる通貨を受信して、金融機関サーバ２０または他の利用者端末３０から支払を受け付ける。
　両替・預入要求部３０８は、金融機関サーバ２０に両替または預入を要求する。具体的には、両替・預入要求部３０８が両替を要求し、金融機関サーバ２０が受け付けると、支払要求部３０６が、両替する額面の通貨を送信して、金融機関サーバ２０に支払を要求し、支払受付部３０７が、合計が両替する額面となる複数の支払いを金融機関サーバ２０から受け付ける。また、両替・預入要求部３０８が預入を要求し、金融機関サーバ２０が受け付けると、支払要求部３０６が、預け入れる通貨を送信して、金融機関サーバ２０に支払を要求する。
　与信要求部３０９は、通貨を送信して金融機関サーバ２０に与信を要求し、与信結果を受信する。
　通貨発行証明書記憶部３１０は、通貨発行証明書発行受付部３０１が発行を受け付けた通貨発行証明書を記憶する。
　中間証明書記憶部３１１は、中間証明書発行受付部３０２が発行を受け付けた中間証明書を記憶する。
　利用者鍵記憶部３１２は、利用者鍵生成部３０３によって生成された利用者鍵を記憶する。
　利用者公開鍵証明書記憶部３１３は、利用者認証要求部３０４が受信した利用者公開鍵証明書を記憶する。
　利用者通貨記憶部３１４は、利用者が使用中の通貨を記憶する。具体的には、利用者通貨記憶部３１４は、引出要求部３０５が金融機関サーバ２０から受信した通貨と、支払受付部３０７が金融機関サーバ２０または他の利用者端末３０から受信した通貨と、を記憶する。
　（第１実施形態に係る電子通貨システムの動作）
　次に、第１実施形態に係る電子通貨システム１の動作について説明する。以下、発行銀行をＢ０、各金融機関をＢｉ（Ｂ０，Ｂ１，・・・）、ルート認証局をＡ０、各中間証明局をＡｉ（Ａ０，Ａ１，・・・）、各利用者をＵｊ（Ｕ０，Ｕ１，・・・）、という記号で概念を示しながら説明する。
　図９は、通貨発行処理の流れの一例を示すシーケンス図である。通貨発行処理は、定期的に、または担当者の操作等を受けて開始される。
　発行銀行サーバ１０の通貨発行鍵生成部１０１は、通貨発行鍵を生成する（ステップＳ１０１）。具体的には、通貨発行鍵生成部１０１は、発行年ｙと発行額ｖに対応する通貨発行鍵のペア（秘密鍵ｓｋＢ０ｖｙおよび公開鍵ｐｋＢ０ｖｙ）を生成する。
　そして、通貨発行証明書発行部１０２は、公開鍵ｐｋＢ０ｖｙを証明する通貨発行証明書ＣＥＲＴ（ｐｋＢ０ｖｙ）を各金融機関サーバ２０に送信し（ステップＳ１０２）、各利用者端末３０に送信する（ステップＳ１０３）。各金融機関サーバ２０の通貨発行証明書発行受付部２０１は、通貨発行証明書ＣＥＲＴ（ｐｋＢ０ｖｙ）を受信して、通貨発行証明書記憶部２１２に記憶させる。また、各利用者端末３０の通貨発行証明書発行受付部３０１は、通貨発行証明書ＣＥＲＴ（ｐｋＢ０ｖｙ）を受信して、通貨発行証明書記憶部３１０に記憶させる。
　発行額ｖは、最小単位（例えば、１円）の倍数である。例えば、２０２１年に１００００円の通貨を発行する場合、通貨発行証明書発行部１０２は、通貨発行証明書ＣＥＲＴ（ｐｋＢ０（１００００円）（２０２１年））を各金融機関サーバ２０および各利用者端末３０に送信する。
　なお、通貨発行証明書発行部１０２は、通貨発行証明書ＣＥＲＴ（ｐｋＢ０ｖｙ）を直接に各金融機関サーバ２０および各利用者端末３０に送信しなくても良く、例えば、通信ネットワークで公開されているサーバ装置等にアップロードし、各金融機関サーバ２０および各利用者端末３０にダウンロードさせるようにしても良い。
　次に、ルート認証局サーバ１１のルート認証鍵生成部１１１は、ルート認証鍵を生成する（ステップＳ１０４）。ルート認証鍵は、秘密鍵ｓｋＡ０および公開鍵ｐｋＡ０を含む。続いて、ルート証明書発行部１１２は、秘密鍵ｓｋＡ０で署名してルート証明書Ａｕｔｈ（ｐｋＡ０）を生成し、各金融機関サーバ２０に送信する（ステップＳ１０５）。
　なお、ルート証明書発行部１１２は、直接にルート証明書Ａｕｔｈ（ｐｋＡ０）を各金融機関サーバ２０に送信しなくても良く、例えば、通信ネットワークで公開されているサーバ装置等にアップロードし、各金融機関サーバ２０にダウンロードさせるようにしても良い。
　続いて、中間認証局サーバ２５の中間認証鍵生成部２５１は、中間認証鍵を生成する（ステップＳ１０６）。中間認証鍵は、秘密鍵ｓｋＡｉおよび公開鍵ｐｋＡｉを含む。
　次に、中間証明書発行部２５２は、秘密鍵ｓｋＡｉで署名し、ルート証明書Ａｕｔｈ（ｐｋＡ０）を使用して中間証明書Ａｕｔｈ（ｐｋＡｉ，ｐｋＡ０）を生成する。以下、中間証明書Ａｕｔｈ（ｐｋＡｉ，ｐｋＡ０）はＡｕｔｈ（ｐｋＡｉ）と表記する。そして、中間証明書発行部２５２は、生成した中間証明書Ａｕｔｈ（ｐｋＡｉ）を各利用者端末３０に送信する（ステップＳ１０７）。各利用者端末３０の中間証明書発行受付部３０２は、中間証明書Ａｕｔｈ（ｐｋＡｉ）を受信して、中間証明書記憶部３１１に記憶させる。
　なお、中間証明書発行部２５２は、直接に中間証明書Ａｕｔｈ（ｐｋＡｉ）を各利用者端末３０に送信しなくても良く、例えば、通信ネットワークで公開されているサーバ装置等にアップロードし、各利用者端末３０にダウンロードさせるようにしても良い。
　続いて、利用者端末３０の利用者鍵生成部３０３は、利用者鍵を生成する（ステップＳ１０８）。利用者鍵は、秘密鍵ｓｋＵｊおよび公開鍵ｐｋＵｊを含む。次に、利用者認証要求部３０４は、公開鍵ｐｋＵｊを送信して、利用者認証を中間認証局サーバ２５に要求する（ステップＳ１０９）。
　中間認証局サーバ２５の利用者認証部２５３は、ルート証明書Ａｕｔｈ（ｐｋＡ０）および中間証明書Ａｕｔｈ（ｐｋＡｉ）を用いて、利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ，ｐｋＡｉ，ｐｋＡ０）を生成する（ステップＳ１１０）。以下、利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ，ｐｋＡｉ，ｐｋＡ０）はＡｕｔｈ（ｐｋＵｊ）と表記する。利用者認証部２５３は、生成した利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ）を利用者端末３０に送信する（ステップＳ１１１）。利用者端末３０は、秘密鍵ｓｋＵｊおよび公開鍵ｐｋＵｊおよび利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ）を保持する。
　さらに、利用者認証部２５３は、利用者公開鍵証明書発行情報（Ｕｊ，ｐｋＵｊ，Ａｕｔｈ（ｐｋＵｊ））を生成し、利用者公開鍵証明書発行情報記憶部２５５に記憶させる。利用者公開鍵証明書発行情報（Ｕｊ，ｐｋＵｊ，Ａｕｔｈ（ｐｋＵｊ））は、利用者の個人情報Ｕｊを含んでいる。
　次に、金融機関サーバ２０の金融機関鍵生成部２０２は、金融機関鍵を生成する（ステップＳ１１２）。金融機関鍵は、秘密鍵ｓｋＢｉおよび公開鍵ｐｋＢｉを含む。次に、金融機関認証要求部２０３は、公開鍵ｐｋＢｉを送信して、金融機関認証をルート認証局サーバ１１に要求する（ステップＳ１１３）。
　ルート認証局サーバ１１の金融機関認証部１１３は、ルート証明書Ａｕｔｈ（ｐｋＡ０）を用いて、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ，ｐｋＡ０）を生成する（ステップＳ１１４）。以下、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ，ｐｋＡ０）はＡｕｔｈ（ｐｋＢｉ）と表記する。金融機関認証部１１３は、生成した金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）を金融機関サーバ２０に送信する（ステップＳ１１５）。金融機関サーバ２０は、秘密鍵ｓｋＢｉおよび公開鍵ｐｋＢｉおよび金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）を保持する。
　さらに、金融機関認証部１１３は、金融機関公開鍵証明書発行情報（Ｂｉ，ｐｋＢｉ，Ａｕｔｈ（ｐｋＢｉ））を生成し、金融機関公開鍵証明書発行情報記憶部１１６に記憶させる。なお、金融機関公開鍵証明書発行情報（Ｂｉ，ｐｋＢｉ，Ａｕｔｈ（ｐｋＢｉ））は、金融機関についての機関情報Ｂｉを含んでいる。そして、金融機関公開鍵証明書発行情報送信部１１４は、金融機関公開鍵証明書発行情報（Ｂｉ，ｐｋＢｉ，Ａｕｔｈ（ｐｋＢｉ））を発行銀行サーバ１０に送信する（ステップＳ１１６）。
　発行銀行サーバ１０の金融機関公開鍵証明書発行情報取得部１０３は、金融機関公開鍵証明書発行情報（Ｂｉ，ｐｋＢｉ，Ａｕｔｈ（ｐｋＢｉ））を取得する。
　なお、ステップＳ１０８からステップＳ１１１までの処理と、ステップＳ１１２からステップＳ１１６までの処理の順序は一例であって、逆でも良い。ステップＳ１０８からステップＳ１１１までの処理は、各利用者端末３０によってそれぞれ個別に実行される。またステップＳ１１２からステップＳ１１６までの処理は、各金融機関サーバ２０によってそれぞれ個別に実行される。
　また、利用者端末３０は、利用者鍵を追加するため、ステップＳ１０８からステップＳ１１１までの処理を複数回実行しても良い。
　次に、発行銀行サーバ１０の通貨発行部１０４は、金融機関公開鍵証明書発行情報記憶部１１６に記憶された金融機関公開鍵証明書発行情報（Ｂｉ，ｐｋＢｉ，Ａｕｔｈ（ｐｋＢｉ））を使用し、発行額ｖに基づく通貨ＩＤであるｉｄ０、発行年ｙ、金融機関Ｂｉを指定した通貨発行メッセージ（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ）を生成し、通貨ＩＤであるｉｄ０を発行通貨記憶部１０７に記録する（ステップＳ１１７）。したがって、発行通貨記憶部１０７には、発行された通貨ごとに通貨ＩＤが記録される。なお、通貨ＩＤの構造については図２において説明した通りであるが、その生成方法については後述される。ここで、通貨発行部１０４は、通貨発行鍵記憶部１０６に記憶された通貨発行鍵の秘密鍵ｓｋＢ０ｖｙを使用して（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ）に署名する。通貨発行部１０４は、署名Ｓ０が付加された通貨発行メッセージ（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ）を、金融機関サーバ２０に送信する（ステップＳ１１８）。なお、後述より明らかなように、通貨発行メッセージは、発行対象の通貨の生成に利用される。したがって、通貨発行メッセージの生成は、実質的に、通貨の発行に相当する。
　金融機関サーバ２０の通貨発行受付部２０４は、署名Ｓ０が付加された通貨発行メッセージ（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ）を受信して、通貨発行証明書記憶部２１２に記憶された通貨発行証明書ＣＥＲＴ（ｐｋＢ０ｖｙ）に含まれる公開鍵ｐｋＢ０ｖｙを使用して署名Ｓ０を検証する。そして、通貨発行受付部２０４は、通貨Ｔ０：＝（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ，Ｓ０）を生成して未使用通貨記憶部２１５に記憶させる。
　なお、図９では、ルート認証鍵、中間認証鍵、利用者鍵、及び金融機関鍵、並びにこれらの公開鍵の証明書が通貨の発行に伴って生成される例が示されているが、これらの鍵及び証明書は、通貨の発行とは異なるタイミングで生成されてもよい。これらの鍵及び証明書は、１回のみ生成されてもよいし、定期的に更新されてもよい。すなわち、複数の通貨に対して同一の鍵及び証明書が使用されてもよい。
　ステップＳ１１７の通貨発行メッセージの生成における通貨ＩＤの生成について説明する。
　図１０は、通貨発行時における通貨ＩＤの生成処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ１２１において、通貨発行部１０４は、発行額ｖに対応する数以上の葉ノードを含む最小のＮＮＬ木の深さを計算する。当該深さの計算は、実質的に、当該ＮＮＬ木の構造の生成に相当する。発行額ｖに対応する数以上の葉ノードとは、発行額ｖを表現可能な数の葉ノードをいい、発行額ｖを最小単位（例えば、１円）で除した値以上の数の葉ノードをいう。最小単位が１円であり、ｖ＝８円であれば、８個の葉ノードが必要となる。ＮＮＬ木を２分木とした場合、８個の葉ノードを含みうる２分木の深さは３以上である。したがって、３以上の中で最小の値である３が当該ＮＮＬ木の深さとなる。
　続いて、通貨発行部１０４は、当該ＮＮＬ木のＳｅｅｄとなる乱数を生成する（Ｓ１２２）。
　続いて、通貨発行部１０４は、当該ＮＮＬ木の葉ノードのうち、発行額ｖに対応させる葉ノードの開始点及び終了点を決定する（Ｓ１２３）。開始点及び終了点のいずれか一方が、当該ＮＮＬ木の端の葉ノードであり、開始点から終了点までの連続する葉ノードの集合が発行額ｖに一致するように、開始点及び終了点が決定される。なお、開始点及び終了点の値は、ＮＮＬ木の葉ノードにおける順番を示す値によって表現されればよい。すなわち、ＮＮＬ木において開始点及び終了点に対応する乱数は計算されなくてよい。
　続いて、通貨発行部１０４は、｛Ｓｅｅｄ，深さ，開始点，終了点｝のセットを通貨ＩＤとして生成する。
　図１１は、引出処理の流れの一例を示すシーケンス図である。引出処理は、利用者Ｕｊの引出を指示する操作に応じて開始される。
　利用者端末３０の引出要求部３０５は、引出の額面ｖを示す額面情報と、利用者鍵記憶部３１２に記憶された利用者鍵の公開鍵ｐｋＵｊと、を送信して、金融機関サーバ２０に引出を要求する（ステップＳ２０１）。
　金融機関サーバ２０の引出受付部２０５は、引出を受け付ける（ステップＳ２０２）。具体的には、引出受付部２０５は、未使用通貨記憶部２１５から額面ｖ分の未使用通貨Ｔ０を取得して、通貨付加情報Ｔ１：＝（ｉｄ１，ｐｋＵｊ，Ｓ１）を付加した使用中通貨（Ｔ１，Ｔ０）として、使用中通貨記憶部２１６に記憶させる。Ｓ１は、金融機関鍵の秘密鍵ｓｋＢｉを用いた（ｉｄ１，ｐｋＵｊ，Ｔ０）に対する署名である。また、ｉｄ１は使用中通貨（Ｔ１，Ｔ０）の額面に基づく、移転対象の通貨の通貨ＩＤである。通貨Ｔ０が額面ｖに一致する場合には、ｉｄ１の値は、通貨Ｔ０の通貨ＩＤであるｉｄ０と同じでよい。また、複数の通貨Ｔ０のセットが額面ｖに一致する場合には、引出受付部２０５は、これらの通貨Ｔ０ごとに通貨（Ｔ１，Ｔ０）を生成すればよい。この場合、各Ｔ１のｉｄ１の値は、対応するｉｄ１と同じでよい。
　一方、通貨Ｔ０が額面ｖを超える場合、又は複数の通貨Ｔ０のセットでは額面ｖを超える場合、引出受付部２０５は、通貨Ｔ０の一部を分割して通貨（Ｔ１，Ｔ０）を生成する。例えば、額面ｖが１０００円であり通貨Ｔ０が５０００円である場合、引出受付部２０５は、通貨Ｔ０から１０００円分を分割して１０００円としての通貨（Ｔ１，Ｔ０）を生成する。また、例えば、額面ｖが７０００円であり、各通貨Ｔ０が５０００円である場合、引出受付部２０５は、２枚の通貨Ｔ０のうちの一方から２０００円分を分割して２０００円としての通貨（Ｔ１，Ｔ０）を生成する。通貨Ｔ０の分割は、通貨Ｔ０が含むｉｄ０としてのＮＮＬ木の分割によって実現される。ＮＮＬ木は通貨の金額をも表現するからである。このような通貨の分割処理については後述される。
　このように、通貨が引出や支払等によって移転するたびに、当該通貨には移転元によって署名された通貨付加情報が累積的に付与される。したがって、通貨付加情報は、通貨の移転の履歴を示す情報であるともいえる。
　続いて、引出受付部２０５は、使用中通貨（Ｔ１，Ｔ０）の通貨データと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを利用者端末３０に送信する（ステップＳ２０３）。利用者端末３０の引出要求部３０５は、使用中通貨（Ｔ１，Ｔ０）の通貨データと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを検証し、使用中通貨（Ｔ１，Ｔ０）を利用者通貨記憶部３１４に記憶させる。（Ｔ１，Ｔ０）を未使用通貨と呼んでもよい。
　なお、ステップＳ２０２において、引出受付部２０５は、必要に応じて、未使用通貨記憶部２１５に記憶された未使用通貨ではなく使用済通貨記憶部２１８に記憶された使用済通貨を使用しても良い。この場合、更新処理部２０６が、使用済通貨を更新し、通貨付加情報が削除された通貨に更新する。引出受付部２０５は、使用済通貨を使用するか否かを、あらかじめ定められた条件にしたがって決定する。例えば、引出受付部２０５は、使用済通貨が閾値以上のデータ量になった場合に、使用済通貨を使用するようにしても良い。
　例えば、引出受付部２０５が使用済通貨（Ｔｎ，・・・，Ｔ０）を引出に対して利用する場合、更新処理部２０６は、更新前の状態の通貨（Ｔｎ，・・・，Ｔ０）を更新済通貨記憶部２１７に記憶させる。そして、更新処理部２０６は、使用済通貨（Ｔｎ，・・・，Ｔ０）を、通貨付加情報（Ｔｎ，・・・，Ｔ１）が削除された通貨Ｔ０に更新する。そして、引出受付部２０５は、更新された通貨Ｔ０に通貨付加情報Ｔｎ＋１：＝（ｉｄｎ＋１，ｐｋＵｊ，Ｓｎ＋１）を付加した使用中通貨（Ｔｎ＋１，Ｔ０）を、使用中通貨記憶部２１６に記憶させる。この際、ｉｄｎ＋１の値（内容）は、Ｔｎに含まれている通貨ＩＤと同じでよい。
　続いて、引出受付部２０５は、使用中通貨（Ｔｎ＋１，Ｔ０）の通貨データと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを利用者端末３０に送信する（ステップＳ２０３）。利用者端末３０の引出要求部３０５は、使用中通貨（Ｔｎ＋１，Ｔ０）の通貨データと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを検証し、使用中通貨（Ｔｎ＋１，Ｔ０）を利用者通貨記憶部３１４に記憶させる。
　また、更新処理部２０６は、すでに１回以上更新された通貨を再度更新しても良い。この場合、更新処理部２０６は、以前の更新前の状態の通貨（Ｔｎ，・・・Ｔ１，Ｔ０）に、今回の更新前の状態の通貨（Ｔｎ＋ｋ，・・・，Ｔｎ＋１，Ｔ０）を結合した通貨（Ｔｎ＋ｋ，・・・，Ｔ１，Ｔ０）を更新済通貨記憶部２１７に記憶させる。
　ステップＳ２０２において、通貨の分割が必要な場合に実行される通貨の分割処理の詳細について説明する。図１２は、通貨の分割処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ２１１において、引出受付部２０５は、引出の額面ｖに対応する数以上の葉ノードを含む最小のＮＮＬ木（以下、「分割先のＮＮＬ木」という。）の深さを計算する。斯かる深さの計算方法は、図１０のステップＳ１２１と同様である。
　続いて、引出受付部２０５は、分割対象の通貨の通貨ＩＤとしてのＮＮＬ木（以下、「分割元のＮＮＬ木」という。）のノードの中から、分割先のＮＮＬ木のルートノードとするノードを決定する（Ｓ２１２）。ここで、分割先のＮＮＬ木は、分割元のＮＮＬ木の部分木である。分割先のＮＮＬ木の深さが計算されているため、分割先のＮＮＬ木のルートノードが分割元のＮＮＬ木のどの階層のノードであるかが特定できる。引出受付部２０５は、当該階層に属するノードのうち、端に位置する（分割元のＮＮＬ木の開始点の祖先である）ノードを分割先のＮＮＬ木のルートノードとして決定する。例えば、図２において説明した分割が行われるのであれば、図２のノードＮ２が分割先のＮＮＬ木のルートノードとして決定される。
　続いて、引出受付部２０５は、当該ルートノードに対応する乱数（すなわち、分割先のＮＮＬ木のＳｅｅｄ）を、分割元のＮＮＬ木のＳｅｅｄに基づいて計算する（Ｓ２１３）。具体的には、図１において説明したように、分割元のＮＮＬ木のＳｅｅｄに対して疑似乱数生成器Ｇを再帰的に適用することで、分割先のＮＮＬ木のＳｅｅｄを算出することができる。
　ステップＳ２１１において、引出受付部２０５は、分割対象の通貨の通貨ＩＤとしてのＮＮＬ木の葉ノードのうち、額面ｖに対応させる葉ノードの開始点及び終了点を決定する（Ｓ２１１）斯かる葉ノードの決定方法は、図１０のステップＳ１２３において説明した方法と同様でよい。
　続いて、引出受付部２０５は、｛分割元のＮＮＬ木のＳｅｅｄ，分割元のＮＮＬ木の深さ，開始点，終了点｝のセットを分割先の通貨の通貨ＩＤ（つまり、ステップＳ２０２における通貨付加情報Ｔ１：＝（ｉｄ１，ｐｋＵｊ，Ｓ１）のｉｄ１として生成する（Ｓ２１２）。
　続いて、引出受付部２０５は、分割元の通貨（Ｓ２０２におけるＴ０）を残高（額面ｖを差し引いた額）に対応させるため、分割元のＮＮＬ木において、分割先の通貨の終了点となった次の葉ノードを特定する（Ｓ２１３）。
　続いて、引出受付部２０５は、｛分割元のＮＮＬ木のＳｅｅｄ，分割元のＮＮＬ木の深さ，当該次の葉ノード，分割元のＮＮＬ木の終了点｝を仮通貨ＩＤとして、分割元の通貨に関連付けておく（Ｓ２１４）。当該仮通貨ＩＤは、残高分の分割元の通貨が引出、支払等により移転する際に、通貨付加情報の通貨ＩＤとして利用される。
　図１３は、第１実施形態に係る支払処理（送金者から着金者への送信処理）の流れの一例を示すシーケンス図である。支払処理は、送金側の利用者Ｕｊによる着金側の利用者Ｕｋへの支払を指示する操作に応じて開始される。
　利用者端末３０－１は、送金側の利用者Ｕｊが操作する利用者端末３０である。利用者端末３０－２は、着金側の利用者Ｕｋが操作する利用者端末３０である。利用者端末３０－１の支払要求部３０６は、支払い額ｖ以上の通貨（Ｔｎ－１，・・・，Ｔ０）から通貨付加情報を除く通貨データである通貨Ｔ０と、Ｔｎ－１＝（ｉｄｎ－１，ｐｋＵｊ，Ｓｎ－１）と、利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ）とを送信して、支払を利用者端末３０－２に要求する（ステップＳ３０１）。なお、通貨Ｔ０は、通貨（Ｔｎ－１，・・・，Ｔ０）の現在の額面を示すものではない。通貨（Ｔｎ－１，・・・，Ｔ０）の現在の額面は、Ｔｎ－１のｉｄｎ－１としてのＮＮＬ木の開始点及び終了点から導出可能である。
　利用者端末３０－２の支払受付部３０７は、支払を受け付ける（ステップＳ３０２）。具体的には、支払受付部３０７は、通貨Ｔ０と、Ｔｎ－１＝（ｉｄｎ－１，ｐｋＵｊ，Ｓｎ－１）のＳｎ－１と、利用者公開鍵証明書Ａｕｔｈ（ｐｋＵｊ）とを検証する。ここで、支払受付部３０７は、通貨の検証においては、通貨に含まれる署名データを検証する。例えば、支払受付部３０７は、通貨Ｔ０：＝（ｉｄ０，ｙ，Ｂｉ，ｐｋＢｉ，Ｓ０）の署名Ｓ０を検証する。また、支払受付部３０７は、Ｔｎ－１＝（ｉｄｎ－１，ｐｋＵｊ，Ｓｎ－１）のＳｎ－１をｐｋＵｊを用いて検証する。
　次に、支払受付部３０７は、利用者端末３０－２の利用者鍵記憶部３１２に記憶された利用者鍵の公開鍵ｐｋＵｋを利用者端末３０－１に送信する（ステップＳ３０３）。利用者端末３０－１の支払要求部３０６は、通貨ＩＤとしてのｉｄｎを生成し、ｉｄｎと、受信した公開鍵ｐｋＵｋと、通貨データ（例えばＴｎ－１、あるいは、Ｔｎ－１のハッシュ値）を含む情報に、利用者端末３０－１の利用者鍵記憶部３１２に記憶された利用者鍵の秘密鍵ｓｋＵｊを使用して署名（Ｓｎ）を計算し、通貨付加情報Ｔｎ：＝（ｉｄｎ，ｐｋＵｋ，Ｓｎ）を生成する（ステップＳ３０４）。通貨付加情報を通貨データと呼んでもよい。ここで、ｉｄｎは、これから生成される通貨（Ｔｎ，・・・，Ｔ０）の額面に基づく通貨ＩＤである。通貨（Ｔｎ－１，・・・，Ｔ０）が支払い額ｖに一致する場合には、ｉｄｎの値は、通貨（Ｔｎ－１，・・・，Ｔ０）のＴｎ－１の通貨ＩＤであるｉｄｎ－１と同じでよい。また、複数の通貨（Ｔｎ－１，・・・，Ｔ０）のセットが支払い額ｖに一致する場合には、支払要求部３０６は、これらの通貨（Ｔｎ－１，・・・，Ｔ０）ごとに通貨付加情報Ｔｎ：＝（ｉｄｎ，ｐｋＵｋ，Ｓｎ）を生成すればよい。この場合、各Ｔｎのｉｄｎの値は、対応するｉｄｎ－１と同じでよく、後述される通貨（Ｔｎ，・・・，Ｔ０）は、通貨（Ｔｎ－１，・・・，Ｔ０）ごとに生成される。
　一方、通貨（Ｔｎ－１，・・・，Ｔ０）が支払い額ｖを超える場合、又は複数の通貨（Ｔｎ－１，・・・，Ｔ０）０のセットでは支払い額ｖを超える場合、支払要求部３０６は、通貨（Ｔｎ－１，・・・，Ｔ０）の一部を分割してｉｄｎを生成する。すなわち、この場合のｉｄｎは、通貨（Ｔｎ－１，・・・，Ｔ０）におけるＴｎ－１の通貨ＩＤであるｉｄｎ－１としてのＮＮＬ木を分割元として、支払要求部３０６が支払い額ｖだけ分割することで得られる分割先のＮＮＬ木の｛Ｓｅｅｄ，深さ，開始点，終了点｝である。斯かる分割を実行するための処理手順は、図１２において説明した通りである。すなわち、ステップＳ３０４において、支払要求部３０６は、図１２の処理手順を実行することでｉｄｎを生成する。
　支払要求部３０６は、通貨付加情報（Ｔｎ－１，・・・，Ｔ１）に、生成した通貨付加情報Ｔｎ：＝（ｉｄｎ，ｐｋＵｋ，Ｓｎ）を付加した通貨付加情報（Ｔｎ，・・・，Ｔ１）を、利用者端末３０－２に送信する（ステップＳ３０５）。
　利用者端末３０－２の支払受付部３０７は、通貨付加情報（Ｔｎ，・・・，Ｔ１）を検証する。具体的には、支払受付部３０７は、公開鍵ｐｋＵｊを用いてＳｎを検証する。支払受付部３０７は、通貨付加情報に含まれるそれぞれの署名データを検証してもよい。例えば、支払受付部３０７は、通貨付加情報Ｔｎ：＝（ｉｄｎ，ｐｋＵｊ，Ｓｎ）の署名Ｓｎを検証する。支払受付部３０７は、受信した通貨Ｔ０に通貨付加情報（Ｔｎ，・・・，Ｔ１）を付加した通貨（Ｔｎ，・・・，Ｔ０）を、利用者端末３０－２の利用者通貨記憶部３１４に記憶させる。
　図１４は、両替処理の流れの一例を示すシーケンス図である。両替処理は、利用者Ｕｊの両替を指示する操作に応じて開始される。
　利用者端末３０の両替・預入要求部３０８は、両替の額面ｖを示す額面情報と、利用者鍵記憶部３１２に記憶された利用者鍵の公開鍵ｐｋＵｊと、を送信して、金融機関サーバ２０に両替を要求する（ステップＳ４０１）。
　金融機関サーバ２０の両替・預入受付部２０７は、両替を受け付ける（ステップＳ４０２）。両替・預入受付部２０７は、両替の受付を示す両替受付情報を利用者端末３０に送信する（ステップＳ４０３）。
　利用者端末３０の両替・預入要求部３０８が、両替受付情報を受信すると、支払要求部３０６は、図１３に示される支払処理にしたがって、金融機関サーバ２０に支払を要求する（ステップＳ４０４）。
　また、金融機関サーバ２０の支払要求部２０８は、合計して両替額ｖとなる額ｖ１，・・・，ｖｘに両替する場合、ｖ１，・・・，ｖｘのそれぞれについて、図１３に示される支払処理にしたがって利用者端末３０に支払を要求する（ステップＳ４０５－１，Ｓ４０５－２）。
　図１５は、与信処理の流れの一例を示すシーケンス図である。与信処理は、利用者Ｕｊの与信を指示する操作に応じて開始される。
　利用者端末３０の与信要求部３０９は、利用可否を確認したい通貨Ｔ０を送信して、金融機関サーバ２０に与信を要求する（ステップＳ５０１）。金融機関サーバ２０の与信受付部２１０は、与信を受け付ける（ステップＳ５０２）。具体的には、与信受付部２１０は、通貨Ｔ０を使用中通貨記憶部２１６から検索して、Ｔ０を含むレコード、例えば（Ｔ１，Ｔ０）が存在すれば、与信成功ａｃｋを示す与信結果を利用者端末３０に送信する（ステップＳ５０３）。
　図１６は、預入処理の流れの一例を示すシーケンス図である。預入処理は、利用者Ｕｊの預入を指示する操作に応じて開始される。
　利用者端末３０の両替・預入要求部３０８は、預入の額面ｖを示す額面情報と、利用者鍵記憶部３１２に記憶された利用者鍵の公開鍵ｐｋＵｊと、を送信して、金融機関サーバ２０に預入を要求する（ステップＳ６０１）。
　金融機関サーバ２０の両替・預入受付部２０７は、預入を受け付ける（ステップＳ６０２）。両替・預入受付部２０７は、預入の受付を示す預入受付情報を利用者端末３０に送信する（ステップＳ６０３）。
　利用者端末３０の両替・預入要求部３０８が、預入受付情報を受信すると、支払要求部３０６は、図１３に示される支払処理にしたがって、金融機関サーバ２０に支払を要求する（ステップＳ６０４）。
　図１７は、還収処理の流れの一例を示すシーケンス図である。還収処理は、金融機関Ｂｉの還収を指示する操作に応じて開始される。
　金融機関サーバ２０の還収要求部２１１は、還収する通貨データを送信して、発行銀行サーバ１０に還収を要求する（ステップＳ７０１）。還収する通貨データは、未使用通貨でも使用済通貨でも良い。未使用通貨を還収する場合は、還収要求部２１１は、未使用通貨Ｔ０を未使用通貨記憶部２１５から抜き出して、発行銀行サーバ１０に送信する。
　また、使用済通貨を還収する場合は、還収要求部２１１は、使用済通貨（Ｔｎ，・・・，Ｔ０）を使用済通貨記憶部２１８から抜き出して、発行銀行サーバ１０に送信する。また、使用済通貨（Ｔｍ，・・・，Ｔｋ＋１，Ｔ０）が更新済みである場合には、還収要求部２１１は、更新済通貨記憶部２１７から更新前の通貨付加情報（Ｔｋ，・・・，Ｔ１）を読み出して、使用済通貨（Ｔｍ，・・・，Ｔｋ＋１，Ｔ０）に結合し、結合された通貨（Ｔｍ，・・・，Ｔ０）を発行銀行サーバ１０に送信する。
　発行銀行サーバ１０の還収受付部１０５は、還収を受け付ける（ステップＳ７０２）。具体的には、還収受付部１０５は、還収対象の通貨（以下、「通貨（Ｔｎ，・・・，Ｔ０）」という。）について二重使用に該当するか否かを判定し、二重使用に該当しない場合には、当該通貨に関する情報を還収済通貨記憶部１０８に記憶させる。この際、還収受付部１０５は、還収された通貨データの各通貨付加情報に含まれている署名を検証することで、還収を受け付けた通貨の正当性を確認してもよい。例えば、通貨付加情報Ｔｎに含まれている署名Ｓｎは、通貨付加情報Ｔｎ－１に含まれている公開鍵を用いて検証することができる。
　続いて、ステップＳ７０２における、還収対象の通貨の二重使用の判定処理の詳細について説明する。
　図１８は、第１実施形態における二重使用の判定処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ８０１において、還収受付部１０５は、通貨（Ｔｎ，・・・，Ｔ０）の還収を受け付ける。以下、当該通貨を「対象通貨Ｔｎ」という。なお、ステップＳ８０１は、図１７のステップＳ７０２と同一ステップである。対象通貨Ｔｎは、発行時の通貨（以下、「元通貨」という。）Ｔ０の額面の一部が分割された通貨であってもよいし、元通貨Ｔ０から分割が行われていない通貨であってもよい。
　続いて、還収受付部１０５は、対象通貨Ｔｎの元の（発行時の）通貨（以下、「元通貨」という。）であるＴ０の通貨ＩＤ（＝ｉｄ０）が発行通貨記憶部１０７に記憶されているか否かを判定する（Ｓ８０２）。ｉｄ０が発行通貨記憶部１０７に記憶されていない場合（Ｓ８０２でＮｏ）、還収受付部１０５は、対象通貨Ｔｎが偽造通貨であると判定し（Ｓ８０３）、図１８の処理を終了させる。
　ｉｄ０が発行通貨記憶部１０７に記憶されている場合（Ｓ８０２でＹｅｓ）、還収受付部１０５は、対象通貨Ｔｎの通貨ＩＤ＝ｉｄｎの乱数（Ｓｅｅｄ）と同一の乱数を含む還収済み通貨を還収済通貨記憶部１０８から取得する（Ｓ８０４）。
　図１９は、第１実施形態における還収済通貨記憶部１０８の構成例を示す図である。図１９において、還収済通貨記憶部１０８は、還収済みの通貨（以下、「還収済通貨」という。）ごとに、発行時通貨ＩＤ、還収時通貨ＩＤ、深さ、開始点及び終了点等を記憶する。発行時通貨ＩＤは、還収済通貨の元通貨が発行された際の通貨ＩＤである。還収済通貨が流通過程において分割されている場合、発行時通貨ＩＤが共通する通貨は複数存在しうる。還収時通貨ＩＤは、還収済通貨が還収された際の通貨ＩＤである。還収済通貨が流通過程において分割されていなければ、還収時通貨ＩＤは発行時通貨ＩＤに一致する。還収済通貨が流通過程において分割されている場合、還収時通貨ＩＤの深さ、開始点及び終了点は、発行時通貨ＩＤと異なる。深さ、開始点及び終了点は、還収時通貨ＩＤが含む深さ、開始点及び終了点である。すなわち、還収済通貨記憶部１０８は、元通貨の額面を表現する空間であるＮＮＬ木（二分木）において、還収済みの範囲を示す情報を記憶する。
　ステップＳ８０４では、対象通貨Ｔｎの通貨ＩＤ＝ｉｄｎの乱数（Ｓｅｅｄ）と同一の乱数を含む還収時通貨ＩＤに含む還収済通貨（つまり、元通貨をＴ０とする通貨）が還収済通貨記憶部１０８から取得される。
　続いて、還収受付部１０５は、取得された還収済通貨ごとに、Ｓ８０５を含むループ処理を実行する。当該ループ処理において処理対象とされている還収済通貨を、以下「対象還収済通貨」という。なお、ステップＳ８０４において還収済通貨が１つも取得されていない場合、当該ループ処理は実行されずにステップＳ８０７へ進む。
　ステップＳ８０５において、還収受付部１０５は、対象通貨Ｔｎの開始点から終了点までの範囲と、対象還収済通貨の開始点から終了点までの範囲との少なくとも一部が重複しているか否か（両者の間に重複部分が有るか否か）を判定する（Ｓ８０５）。具体的には、対象通貨Ｔｎの開始点が対象還収済通貨の終了点より大きい場合、又は対象通貨Ｔｎの終了点が対象還収済通貨の開始点より小さい場合には両者の間に重複部分は無く、そうでない場合には両者の間に重複部分が有ることになる。
　両者の間に重複部分が有る場合（Ｓ８０５でＮｏ）、還収受付部１０５は、対象通貨Ｔｎについて二重使用であると判定する（Ｓ８０６）。すなわち、重複部分において、対象通貨Ｔｎは二重に使用されたことになる。この場合、還収受付部１０５は、当該二重使用を示す情報を出力してもよい。また、還収受付部１０５は、対象通貨Ｔｎと対象還収済通貨との署名の連鎖の分岐を検知することで、二重使用が行われたタイミング又は二重使用を行った者と特定し、特定結果を出力してもよい。具体的には、対象通貨Ｔｎと対象還収済通貨との間で、（Ｔｘ，・・・，Ｔ０）までは共通していたとする。この場合、Ｔｘの通貨ＩＤであるｉｄｘに含まれている公開鍵ｐｋＵｘは、Ｔｘを受け取った者Ｘの公開鍵である。したがって、Ｘが二重使用を行った者であると特定することができる。
　ステップＳ８０４において取得された全ての還収済通貨との間で重複部分が無かった場合、還収受付部１０５は、対象通貨Ｔｎを還収済通貨記憶部１０８（図１９）に登録する（Ｓ８０７）。具体的には、Ｔ０の通貨ＩＤ＝ｉｄ０、対象通貨Ｔｎの通貨ＩＤ＝ｉｄｎ、ｉｄｎの深さ、ｉｄｎの開始点、ｉｄｎの終了点を含むレコードが還収済通貨記憶部１０８（図１９）に追加される。
　（第１実施形態の効果）
　上述したように、第１実施形態によれば、１つの通貨の額面が固定ではなく、分割可能な最小単位（例えば、１円）の集合（開始点から終了点までの範囲）によって指定されるため、通貨の還収の単位を、通貨の最小単位ごとではなく分割単位とすることができる。本願発明者が行ったシミュレーションによれば、市中における通貨の分割数は概ね３回程度であることが想定されており、分割単位は通貨の最小単位よりは大きいことが想定される。その結果、還収済通貨記憶部１０８（図１９）のレコード数を、通貨の発行額ではなく分割数に比例する程度に削減することができる。レコード数の削減に伴って、還収された通貨について、還収済みの通貨との比較回数（範囲の重複のチェックの回数）も減少させることができる。例えば、１万円が還収される場合、１万レコードの取り扱いが必要とはならない。したがって、電子通貨の二重使用の検知を効率化することができる。
　（第２実施形態）
　次に、第２実施形態について説明する。第２実施形態では第１実施形態と異なる点について説明する。第２実施形態において特に言及されない点については、第１実施形態と同様でもよい。
　第２実施形態では、二重使用の判定処理について、第１実施形態で説明した方法（図１８）とは異なる方法について説明する。
　第１実施形態では、開始点及び終了点によって、還収時における通貨の額面の範囲が特定される例を説明した。つまり、開始点及び終了点の重複の有無によって二重使用の有無が判定された。第２の実施の形態では、或る通貨の額面を２の冪乗の総和の形式に変換し、元通貨の額面を表現する空間であるＮＮＬ木（二分木）において当該総和を構成する２の冪乗のそれぞれに対応するノードの乱数の一覧によって、当該或る通貨の額面の範囲が表現される例について説明する。第２の実施の形態では、このような乱数の重複（又は衝突）の有無によって二重使用の有無が判定される。
　図２０は、第２実施形態における通貨の額面の範囲の表現方法を説明するための図である。図２０における２分木は、通貨の額面を表現する空間であるＮＮＬ木である。また、図２０において、各ノードに付与されているｒで始まる符号は、各ノードの識別子であると共に、各ノードに対して割り当てられた乱数であるとする。通貨の最小単位が１円であるとすると、図２０のＮＮＬ木の１つの葉ノードは１円に対応する。したがって、図２０のＮＮＬ木は最大で８円を表現可能である。
　ここで、８を２の冪乗の総和で表現すると、２３である。指数である３は、ＮＮＬ木（二分木）のノードの位置（深さ）に対応する。すなわち、深さが３であるノードが８の範囲に対応するノードということがいえる。したがって、図２０において、８円の範囲は、ルートノードｒということになる。つまり、８円は乱数｛ｒ｝という乱数の一覧に置き換えることができる。このような乱数の一覧による額面の表現を、以下「乱数一覧」という。なお、ノードｒは、８円に対応する葉ノードのみを子孫とするノードであるといえる。
　８円から６円が分割される場合、６円を２の冪乗の総和で表現すると、２２＋２１である。左側の葉ノードを優先的に分割対象とする場合、２２に対応するノードはノードｒ０であり、２１に対応するノードはノードｒ１０である。したがって、６円は、｛ｒ０，ｒ１０｝という乱数一覧に置き換えることができる。つまり、ノードｒ０に属する（ノードｒ０の子孫である）葉ノードの数は４であり、ノードｒ１０に属する葉ノードの数は２つである。したがって、｛ｒ０，ｒ１０｝４＋２＝６円に対応する。なお、ノードｒ０及びｒ１０は、６円に対応する葉ノードのみを子孫とするノードであるといえる。
　或る額面を乱数一覧に変換する場合、乱数一覧に含まれる乱数をルートノードとする部分木の間でノードの重複は許されない。例えば、図２０において、ノードｒ０１は２円に対応するが、ノードｒ０１をルートとする部分木は、ノードｒ０をルートとする部分木の一部である。したがって、｛ｒ０，ｒ０１｝は、｛ｒ０｝と等価となり、６円ではなく４円を表現することになってしまう。したがって、｛ｒ０，ｒ０１｝のような乱数一覧は生成されないこととする。
　図２１は、第２実施形態における二重使用の判定処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ８５１～Ｓ８５３は、図１８のＳ８０１～Ｓ８０３と同じである。すなわち、ステップＳ８５１において、還収受付部１０５は、対象通貨Ｔｎ＝（Ｔｎ，・・・，Ｔ０）還収を受け付ける。続いて、還収受付部１０５は、対象通貨Ｔｎの元通貨であるＴ０の通貨ＩＤ（＝ｉｄ０）が発行通貨記憶部１０７に記憶されているか否かを判定する（Ｓ８５２）。ｉｄ０が発行通貨記憶部１０７に記憶されていない場合（Ｓ８５２でＮｏ）、還収受付部１０５は、対象通貨Ｔｎが偽造通貨であると判定し（Ｓ８５３）、図２１の処理を終了させる。
　ｉｄ０が発行通貨記憶部１０７に記憶されている場合（Ｓ８５２でＹｅｓ）、還収受付部１０５は、対象通貨Ｔｎ（の額面）を、図２０において説明した乱数一覧｛ｒ＿１，・・・，ｒ＿ｂ｝に変換する（Ｓ８５４）。具体的には、還収受付部１０５は、対象通貨Ｔｎの通貨ＩＤであるｉｄｎ＝｛Ｔ０のＳｅｅｄ，Ｔ０のＮＮＬ木の深さ，Ｔｎの開始点，Ｔｎの終了点｝のうち、Ｔ０のＳｅｅｄ及びＴ０のＮＮＬ木の深さに基づいて特定されるＮＮＬ木（２分木）において、Ｔｎの開始点からＴｎの終了点の範囲に含まれる葉ノードの一覧を乱数一覧に変換する。当該乱数一覧は、当該葉ノードの一覧のみを含む部分木の集合における各部分木のルートノードに対応する乱数の集合である。
　続いて、還収受付部１０５は、乱数一覧｛ｒ＿１，・・・，ｒ＿ｂ｝に含まれる乱数ごとに、ステップＳ８５５～Ｓ８５７を含むループ処理を実行する。当該ループ処理において処理対象とされている乱数を、以下「ｒ＿ｘ」という。
　ステップＳ８５５において、還収受付部１０５は、ｒ＿ｘが既に還収されているか否かを判定する。具体的には、還収受付部１０５は、ｒ＿ｘが還収済通貨記憶部１０８に既に記憶されているか否かを判定する。
　図２２は、第２実施形態における還収済通貨記憶部１０８の構成例を示す図である。図２２に示されるように、第２実施形態において、還収済通貨記憶部１０８は、発行時通貨ＩＤと還収済み乱数とを対応付けて記憶する。発行時通貨ＩＤは、還収済通貨の元となる通貨（元通貨）が発行された際の通貨ＩＤである。還収済み乱数は、元通貨の額面のうち、還収された額面の範囲に対応する乱数である。元通貨が流通過程において分割されずに還収された場合、還収済み乱数には、元通貨の通貨ＩＤの乱数（Ｓｅｅｄ値）が記憶される。元通貨の額面の一部が流通過程において分割された場合、当該一部の範囲に対応する乱数が還収済み乱数として記憶される。
　ステップＳ８５５において、還収受付部１０５は、ｒ＿ｘが還収済み乱数として還収済通貨記憶部１０８に記憶されているか否かを判定する。
　ｒ＿ｘが還収済み乱数として還収済通貨記憶部１０８に記憶されている場合（Ｓ８５５でＹｅｓ）、還収受付部１０５は、対象通貨Ｔｎのうちｒ＿ｘの範囲について二重使用であると判定する（Ｓ８５６）。この場合、還収受付部１０５は、当該二重使用を示す情報を出力してもよい。また、還収受付部１０５は、図１８のステップＳ８０６において説明したように、当該二重使用が行われたタイミング又は当該二重使用を行った者と特定し、特定結果を出力してもよい。
　ｒ＿ｘが還収済み乱数として還収済通貨記憶部１０８に記憶されていない場合（Ｓ８５５でＮｏ）、還収受付部１０５は、ｒ＿ｘを還収候補リストに追加する（Ｓ８５７）。還収候補リストとは、還収済み乱数として還収済通貨記憶部１０８に登録する候補としての乱数を記憶しておくためのリスト形式のデータをいう。
　乱数一覧｛ｒ＿１，・・・，ｒ＿ｂ｝に含まれる全ての乱数についてループ処理が実行されると、ステップＳ８５８へ進む。
　なお、ステップＳ８５７の時点でｒ＿ｘが還収済通貨記憶部１０８に登録されないのは、ｒ＿ｘに対応する範囲について二重使用が無いことが確定したわけではないからである。具体的には、ｒ＿ｘの子孫のノードに対応する乱数、又はｒ＿ｘの祖先に対応する乱数が既に還収済み乱数として還収済通貨記憶部１０８に登録されている可能性も考えられる。ｒ＿ｘの子孫のノードに対応する乱数が還収済み乱数である場合、ｒ＿ｘに対応する範囲の一部が二重使用であることになる。ｒ＿ｘの祖先に対応する乱数が還収済み乱数である場合、ｒ＿ｘに対応する範囲の全部が二重使用であることになる。図２０を参照して具体的に説明する。ｒ＿ｘがｒ００である状況において、ｒ０００が還収済み乱数であるとすると、ｒ＿ｘに対応する葉ノードである｛ｒ０００，ｒ０００１｝のうち、ｒ０００が二重使用ということになる。又は、ｒ＿ｘがｒ００である状況において、ｒ０が還収済み乱数であるとすると、ｒ＿ｘに対応する葉ノードである｛ｒ０００，ｒ０００１｝の全部が二重使用ということになる。但し、ｒ０００及びｒ０はいずれもｒ００と異なる値であるため、ステップＳ８５５の判定では、このような二重使用を検知することはできない。そこで、ステップＳ８５７では、ｒ＿ｘについて少なくとも完全一致の二重使用は無かったとして還収候補リストにｒ＿ｘが登録され、ステップＳ８５８以降において、ループ処理では検知できない二重使用を検知するための処理が実行される。
　ステップＳ８５８において、還収受付部１０５は、還収候補リストが空であるか否かを判定する。還収候補リストが空である場合（Ｓ８５８でＮｏ）、図２１の処理は終了する。
　還収候補リストに１以上の乱数が格納されている場合（Ｓ８５８でＹｅｓ）、還収受付部１０５は、対象通貨Ｔｎの元通貨Ｔ０の通貨ＩＤに対応付けられている還収済み乱数の一覧（以下、「還収済み乱数一覧」という。）を還収済通貨記憶部１０８（図２２）から取得する（Ｓ８５９）。続いて、還収受付部１０５は、還収済み乱数一覧が空であるか否か（すなわち、該当の還収済み乱数が１以上取得できたか否か）を判定する（Ｓ８６０）。還収済み乱数一覧が空である場合（Ｓ８６０でＮｏ）、還収候補リストに含まれている各乱数の子孫又は祖先の乱数はまだ還収されていないため、ステップＳ８６６へ進む。
　還収済み乱数一覧に１以上の還収済み乱数が含まれている場合（Ｓ８６０でＮｏ）、還収受付部１０５は、元通貨Ｔ０の乱数及び深さに基づいて、二分木（ＮＮＬ木）を生成する（Ｓ８６１）。この際、当該二分木の各ノードの乱数も計算される。なお、当該二分木の全部が生成されなくてもよい。計算量の削減のため、当該二分木のうち、還収候補リストに含まれる乱数ごとに、当該乱数に対応するノードからルートノードまでの経路に係るノードの乱数及び当該乱数から葉ノードまでの経路に係るノードの乱数が特定されればよい。
　続いて、還収受付部１０５は、還収候補リストに含まれる乱数の中に還収済み乱数一覧と衝突する乱数は有るか否かを判定する（Ｓ８６２）。ここで或る乱数と衝突とする乱数とは、或る乱数の祖先又は子孫に該当する乱数をいう。すなわち、還収受付部１０５は、還収候補リストに含まれる乱数ごとに、ステップＳ８６１において生成した二分木において、当該乱数の祖先又は子孫の乱数の一覧を取得し、当該一覧の中に還収済み乱数一覧に含まれる乱数が有るか否かを判定する。
　還収候補リストに含まれる乱数の中に還収済み乱数一覧と衝突する乱数（以下、「衝突乱数」という。）が無い場合（Ｓ８６２でＮｏ）、ステップＳ８６６へ進む。この場合、還収候補リストに含まれる全ての乱数について二重使用は無いということになる。
　一方、衝突乱数が有る場合（Ｓ８６２でＹｅｓ）、還収受付部１０５は、対象通貨Ｔｎのうち衝突乱数の範囲について二重使用であると判定する（Ｓ８６３）。この場合、還収受付部１０５は、当該二重使用を示す情報を出力してもよい。また、還収受付部１０５は、図１８のステップＳ８０６において説明したように、当該二重使用が行われたタイミング又は当該二重使用を行った者と特定し、特定結果を出力してもよい。続いて、還収受付部１０５は、衝突乱数を還収候補リストから削除する（Ｓ８６４）。続いて、還収受付部１０５は、還収候補リストが空であるか否かを判定する。還収候補リストが空である場合（Ｓ８６５でＮｏ）、図２１の処理は終了する。還収候補リストに１以上の乱数が格納されている場合（Ｓ８６５でＹｅｓ）、ステップＳ８６６へ進む。
　ステップＳ８６６において、還収受付部１０５は、還収候補リストに含まれている各乱数を、還収済み乱数として対象通貨Ｔｎの元通貨Ｔ０の通貨ＩＤに対応付けて還収済通貨記憶部１０８（図２２）に登録する（Ｓ８６６）。すなわち、この時点において還収候補リストに含まれている乱数に対応する範囲は、二重使用が検知されなかった範囲である。
　続くステップＳ８６７以降の処理は、還収済通貨記憶部１０８（図２２）を整理して、記憶容量の消費量を削減するための処理である。
　ステップＳ８６７において、還収受付部１０５は、対象通貨Ｔｎの元通貨Ｔ０の通貨ＩＤに対応付けられて還収済通貨記憶部１０８に記憶されている還収済み乱数の一覧を取得する。
　続いて、還収受付部１０５は、元通貨Ｔ０の額面の全ての範囲（元通貨Ｔ０の開始点から終了点までの全ての葉ノード）が、当該還収済み乱数の集合によって網羅されているか否かを判定する（Ｓ８６８）。すなわち、各還収済み乱数に対応する範囲の総和が、元通貨Ｔ０の額面の全ての範囲に一致するか否かが判定される。
　元通貨Ｔ０の額面の全ての範囲が当該還収済み乱数の集合によって網羅されている場合（Ｓ８６８でＹｅｓ）、還収受付部１０５は、元通貨Ｔ０の額面の全ての範囲が還収されたと判定する（Ｓ８６９）。続いて、還収受付部１０５は、元通貨Ｔ０の乱数を還収済み乱数として、元通貨Ｔ０の通貨ＩＤに対応付けて還収済通貨記憶部１０８（図２２）に登録する（Ｓ８７０）。この際、還収受付部１０５は、元通貨Ｔ０の通貨ＩＤに対応付けて還収済通貨記憶部１０８（図２２）に記憶されている他の還収済み乱数を削除することで、元通貨Ｔ０に関連して記憶される情報量を削減してもよい。
　上述したように、第２の実施の形態によっても第１の実施の形態と同様の効果を得ることができる。
　（第３実施形態）
　次に、第３実施形態について説明する。第３実施形態では第１実施形態と異なる点について説明する。第３実施形態において特に言及されない点については、第１実施形態と同様でもよい。
　第１実施形態では、引出、支払等によって通貨が移転する際に、通貨単位で検証が行われる必要がある。したがって、例えば、２千円の通貨を２つ有している利用者が３千円を支払いたい場合、１つの２千円と、もう１つの２千円から分割した千円との２つの通貨を支払えばよいが、この場合、支払う側は通貨ごとに署名を生成し、支払を受ける側は通貨ごとに検証を行う必要がある。取引される通貨の数が多くなればなるほど、このような署名及び検証の負担は大きくなる。第３実施形態では、このような負担を軽減するための方法が開示される。
　第３実施形態では、通貨のハッシュ木を生成して、そのハッシュ木のルートに署名することによって、対象とする通貨をまとめて署名する点が第１実施形態と異なる。以下の第３実施形態の説明において、第１実施形態と同様の機能構成を有するものには、第１実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。
　（第３実施形態において使用する基本技術）
　まず、本実施例において使用する基本技術について説明する。本実施例においてマークルツリー（参考文献［２］）と呼ばれるハッシュ木を利用した３つの関数ＭＨＴｒｅｅ、ＭＨＰａｔｈ、ＭＨＶｅｒを使用する。
　図２３は、第３実施形態に係るマークルツリーのＭＨＴｒｅｅ関数について説明するための図である。ＭＨＴｒｅｅ関数は、データセットからハッシュ木を生成する関数である。
　具体的には、ＭＨＴｒｅｅ関数は、データセットＤを入力しＤを構成する各データのハッシュ値を葉ノードに対応付けることで生成される２分木であるハッシュツリーＬ＝｛（ｌｅａｆ＿ｉｄ，ｌｅａｆ＿ｖａｌ）｝を出力する関数である。ここで、頂点ｈをルートという。以下、ＭＨＴｒｅｅ（Ｄ）－＞Ｌのように記述する。なお、図２３は、ｎ＝６のデータセットである。各葉ノードの値は当該葉ノードに対応するデータのハッシュ値である。７番目と８番目の葉ノードには、２分木の構成を可能とするために"００"が補完されている。
　図２４は、第３実施形態に係るマークルツリーのＭＨＰａｔｈ関数について説明するための第一の図である。ＭＨＰａｔｈ関数は、部分データセットを認証するために必要なパスを生成する関数である。
　具体的には、ＭＨＰａｔｈ関数は、認証したい部分データセットＤ'（図２４の場合、Ｄ'＝｛ｄ０，ｄ４，ｄ５｝）を入力して、その認証に必要な認証用のパスＡＰ（図２４のｈ００１，ｈ０１，ｈ１１）とルートｈを出力する関数である。以下、ＭＨＰａｔｈ（Ｄ'，Ｌ）－＞（ＡＰ，ｈ）のように記述する。
　図２５は、第３実施形態に係るマークルツリーのＭＨＶｅｒ関数について説明するための図である。ＭＨＶｅｒ関数は、部分データセットの認証パスによる検証を行う関数である。
　具体的には、ＭＨＶｅｒ関数は、認証に必要なパスＡＰ（図２５のｈ００１，ｈ０１，ｈ１１）とルートｈから、サブデータＤ'（図２５の場合、Ｄ'＝｛ｄ０，ｄ４，ｄ５｝）を検証する関数である。以下、ＭＨｖｅｒ（ＡＰ，ｈ，Ｄ'）－＞Ｔ　ｏｒ　Ｆのように記述する。ＭＨｖｅｒ関数は、検証に成功した場合（Ｄ'が正しい場合）Ｔを出力し、検証に失敗した場合（Ｄ'が正しくない場合）Ｆを出力する。Ｄ'が正しいとは、Ｄ'に属する全てのデータが改ざんされていないことをいう。
　（第３実施形態に係る電子通貨システムの動作例）
　ここでは、図１１のステップＳ２０２において、額面ｖに一致する通貨が複数の通貨のセットＴ０：＝（Ｔ０＿ｔ）：＝（（ｉｄ０＿ｔ，ｙ＿ｔ，Ｂｉ，ｐｋＢｉ，Ｓ０＿ｔ），ｔ＝１，・・・，ｓ，Σｖ＿ｔ＝ｖ）であったとする。なお、ｖ＿ｔは、Ｔ０を構成する通貨セットのうちのｔ番目の通貨Ｔ０＿ｔの金額である。例えば、各ｖ＿ｔが１万円であり、８万円の引出を受け付けた場合、ｓ＝８である。図２６には、それぞれが１万円であるＴ０＿ｔが８枚有る状態が示されている。なお、例えば、金融機関サーバ２０の未使用通貨記憶部２１５に、１０万円の通貨しかない等のように、１万円×８の通貨が無い場合、引出受付部２０５は、図１２の処理を実行することで、既存の１０万円から８枚の１万円を分割すればよい。なお、第３実施形態において、各Ｔ０＿ｔは、発行直後の通貨に限らず、発行後の移転が行われた（つまり、通貨付加情報が付加された）通貨であってもよい。この場合、移転の過程において分割（つまり、通貨ＩＤのＮＮＬ木の分割）が行われた通貨であってもよい。
　金融機関サーバ２０の引出受付部２０５は、ハッシュ木Ｌ１＝ＭＨＴｒｅｅ（｛Ｔ０＿ｔ｝｛ｔ＝１，・・・，ｓ｝）を生成し、秘密鍵ｓｋＢｉを用いてハッシュ木Ｌ１のルートノードのハッシュ値ＲＨ（ＲｏｏｔＨａｓｈ）及びｐｋＵｊのセットに対する署名Ｓ１を生成する。すなわち、ハッシュ木Ｌ１はその葉ノードに対してＴ０を構成する各Ｔ０＿ｔを割り当てることで生成されるハッシュ木である。引出受付部２０５は、Ｔ０＿ｔごとに、当該Ｔ０＿ｔ対して通貨付加情報Ｔ１＿ｔ：＝（ｉｄ１＿ｔ，ｐｋＵｊ，ＲＨ，ＡＰ＿ｔ，Ｓ１）を付加することで使用中通貨（Ｔ１＿ｔ，Ｔ０＿ｔ）を生成し、使用中通貨記憶部２１６に記憶させる。ここで、ＡＰ＿ｔは、ＭＨＰａｔｈ（Ｔ０＿ｔ，Ｌ１）－＞（ＡＰ＿ｔ，ＲＨ）によって得られるＲＨの認証に必要なパスである。また、各ｉｄ１＿ｔの値は、それぞれに対応するｉｄ０＿ｔと同じでよい。この状態を図２７に示す。各Ｔ１＿ｔが含む署名は同じＳ１であることが分かる。以下、通貨（Ｔ１＿ｔ，Ｔ０＿ｔ）のセット（ここでは８個のセット）を（Ｔ１，Ｔ０）と記載する。
　続いて、引出受付部２０５は、使用中通貨セット（Ｔ１，Ｔ０）の通貨データセットと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを利用者端末３０に送信する（ステップＳ２０３）。利用者端末３０の引出要求部３０５は、使用中通貨セット（Ｔ１，Ｔ０）の通貨データセットと、金融機関公開鍵証明書Ａｕｔｈ（ｐｋＢｉ）とを検証し、使用中通貨セット（Ｔ１，Ｔ０）を利用者通貨記憶部３１４に記憶させる。この際、引出要求部３０５は、通貨セット（Ｔ１，Ｔ０）の検証に関しては、（Ｔ１，Ｔ０）のうちのいずれか１つの通貨（Ｔ１＿ｔ，Ｔ０＿ｔ）についてのみを検証すればよい。具体的には、いずれか１つのＴ１＿ｔについてＭＨｖｅｒ（ＡＰ＿ｔ，ＲＨ，Ｔ０）がＴであることを検証し、かつ、当該Ｔ１＿ｔが含むＳ１を検証する。引出要求部３０５は、他のＴ１＿ｔについては、検証対象としたＴ１＿ｔと同じＳ１を含むことを確認すればよい。
　なお、利用者端末３０の利用者は、通貨セットとして引き出した（Ｔ１，Ｔ０）を構成していた各（Ｔ１＿ｔ，Ｔ０＿ｔ）を個別に（バラバラに）利用することができる。Ｔ１＿ｔは、通貨セットの署名及び検証コストの軽減のためにＲＨ及びＡＰ＿ｔを含む点を除いて、第１実施形態における通貨付加情報と同様に通貨の持ち主（流通過程）の履歴を示すものであり、それぞれ個別に通貨の真正性が担保されているからである。
　なお、上記した処理は、図１３において、複数の貨幣のセットで支払が行われる際におけるステップＳ３０４及びＳ３０５においても実行される。
　また、図１４（両替時）及び図１６（預入時）から呼び出される図１３の処理においても実行される。
　更に、その他の全てのフェーズ（発行時及び還収時等）において図１３の処理は適用可能である。例えば、還収時であれば、還収対象の通貨の一括渡しを効率化することができる。
　上述したように、第３実施形態によれば、複数の通貨を移転する際の署名コスト及び検証コストを軽減することができる。
　（ハードウェア構成例）
　第１実施形態と第３実施形態に共通のハードウェア構成例を説明する。電子通貨システム１の備える各装置の各部は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。なお、この「コンピュータ」は、物理マシンであってもよいし、クラウド上の仮想マシンであってもよい。仮想マシンを使用する場合、ここで説明する「ハードウェア」は仮想的なハードウェアである。
　上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
　図２８は、上記コンピュータのハードウェア構成例を示す図である。図２８のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。
　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。なお、上記コンピュータは、ＣＰＵ１００４の代わりにＧＰＵ（Graphics Processing Unit）またはＴＰＵ（Tensor processing unit）を備えていても良く、ＣＰＵ１００４に加えて、ＧＰＵまたはＴＰＵを備えていても良い。その場合、例えばニューラルネットワーク等の特殊な演算が必要な処理をＧＰＵまたはＴＰＵが実行し、その他の処理をＣＰＵ１００４が実行する、というように処理を分担して実行しても良い。
　（参考文献）
　［１］Revocation and Tracing Schemes for Stateless Receivers, Dalit Naor, Moni Naor, and Jeff Lotspiech, CRYPTO2001
　［２］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.
　なお、上記各実施の形態において、発行銀行サーバ１０は、通貨処理装置の一例である。還収受付部１０５は、判定部の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１　電子通貨システム
１０　発行銀行サーバ
１１　ルート認証局サーバ
２０　金融機関サーバ
２５　中間認証局サーバ
３０　利用者端末
１０１　通貨発行鍵生成部
１０２　通貨発行証明書発行部
１０３　金融機関公開鍵証明書発行情報取得部
１０４　通貨発行部
１０５　還収受付部
１０６　通貨発行鍵記憶部
１０７　発行通貨記憶部
１０８　還収済通貨記憶部
１１１　ルート認証鍵生成部
１１２　ルート証明書発行部
１１３　金融機関認証部
１１４　金融機関公開鍵証明書発行情報送信部
１１５　ルート認証鍵記憶部
１１６　金融機関公開鍵証明書発行情報記憶部
２０１　通貨発行証明書発行受付部
２０２　金融機関鍵生成部
２０３　金融機関認証要求部
２０４　通貨発行受付部
２０５　引出受付部
２０６　更新処理部
２０７　両替・預入受付部
２０８　支払要求部
２０９　支払受付部
２１０　与信受付部
２１１　還収要求部
２１２　通貨発行証明書記憶部
２１３　金融機関鍵記憶部
２１４　金融機関公開鍵証明書記憶部
２１５　未使用通貨記憶部
２１６　使用中通貨記憶部
２１７　更新済通貨記憶部
２１８　使用済通貨記憶部
２５１　中間認証鍵生成部
２５２　中間証明書発行部
２５３　利用者認証部
２５４　中間認証鍵記憶部
２５５　利用者公開鍵証明書発行情報記憶部
３０１　通貨発行証明書発行受付部
３０２　中間証明書発行受付部
３０３　利用者鍵生成部
３０４　利用者認証要求部
３０５　引出要求部
３０６　支払要求部
３０７　支払受付部
３０８　両替・預入要求部
３０９　与信要求部
３１０　通貨発行証明書記憶部
３１１　中間証明書記憶部
３１２　利用者鍵記憶部
３１３　利用者公開鍵証明書記憶部
３１４　利用者通貨記憶部
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インタフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims (8)

  1. 　或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている判定部、
    を有することを特徴とする電子通貨システム。
  2. 　前記第１の電子通貨は、前記或る電子通貨の額面から一部の額面が分割された電子通貨であり、前記第１の電子通貨の額面に応じた範囲を示す情報は、前記一部の額面に応じた範囲である、
    ことを特徴とする請求項１記載の電子通貨システム。
  3. 　前記空間は、ルートノードに対する乱数に基づいて算出可能な乱数が各ノードに割り当てられ、当該額面に応じた数の葉ノードを含む二分木であり、
    　前記範囲を示す情報は、当該範囲に含まれる前記葉ノードを示す情報である、
    ことを特徴とする請求項１記載の電子通貨システム。
  4. 　前記空間は、ルートノードに対する乱数に基づいて算出可能な乱数が各ノードに割り当てられ、当該額面に応じた数の葉ノードを含む二分木であり、
    　前記判定部は、前記空間において還収済みの範囲に対応する葉ノードのみを子孫とする前記ノードの乱数を記憶する前記還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲に対応する葉ノードのみを子孫とする前記ノードの乱数が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている、
    ことを特徴とする請求項１記載の電子通貨システム。
  5. 　前記判定部は、前記空間において還収済みの範囲に対応する葉ノードのみを子孫とする前記ノードの乱数を記憶する前記還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲に対応する葉ノードのみを子孫とする前記ノードの祖先又は子孫のノードの乱数が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている、
    ことを特徴とする請求項４記載の電子通貨システム。
  6. 　或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定するように構成されている判定部、
    を有することを特徴とする通貨処理装置。
  7. 　或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定する判定手順、
    をコンピュータが実行することを特徴とする通貨処理方法。
  8. 　或る電子通貨の額面を表現する空間において第１の電子通貨の額面に応じた範囲を示す情報が付与されている前記第１の電子通貨の還収に応じ、前記空間において還収済みの範囲を示す情報を記憶する還収済通貨記憶部に前記第１の電子通貨の額面に応じた範囲と少なくとも一部が重複する範囲を示す情報が記憶されているか否かに基づいて、前記第１の電子通貨について二重使用の有無を判定する判定手順、
    をコンピュータに実行させるためのプログラム。
PCT/JP2024/015182 2024-04-16 2024-04-16 電子通貨システム、通貨処理装置、通貨処理方法及びプログラム Pending WO2025220136A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/015182 WO2025220136A1 (ja) 2024-04-16 2024-04-16 電子通貨システム、通貨処理装置、通貨処理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/015182 WO2025220136A1 (ja) 2024-04-16 2024-04-16 電子通貨システム、通貨処理装置、通貨処理方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2025220136A1 true WO2025220136A1 (ja) 2025-10-23

Family

ID=97403091

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/015182 Pending WO2025220136A1 (ja) 2024-04-16 2024-04-16 電子通貨システム、通貨処理装置、通貨処理方法及びプログラム

Country Status (1)

Country Link
WO (1) WO2025220136A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH096880A (ja) * 1996-08-01 1997-01-10 Nippon Telegr & Teleph Corp <Ntt> 電子現金の分割使用方法
JPH1091697A (ja) * 1996-09-10 1998-04-10 Nippon Ginkou 発行機関分離型番号登録式電子現金方法および利用者装置
US20100094760A1 (en) * 2007-04-27 2010-04-15 Gemalto Sa Transaction method between two entities providing anonymity revocation for tree-based schemes without trusted party

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH096880A (ja) * 1996-08-01 1997-01-10 Nippon Telegr & Teleph Corp <Ntt> 電子現金の分割使用方法
JPH1091697A (ja) * 1996-09-10 1998-04-10 Nippon Ginkou 発行機関分離型番号登録式電子現金方法および利用者装置
US20100094760A1 (en) * 2007-04-27 2010-04-15 Gemalto Sa Transaction method between two entities providing anonymity revocation for tree-based schemes without trusted party

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OKUDA, TETSUYA: "Formal verification of double spend identification and privacy for transferable electronic cash system", IPSJ SIG TECHNICAL REPORT, 27 February 2023 (2023-02-27), pages 1 - 8, XP009563299 *

Similar Documents

Publication Publication Date Title
JP7244537B2 (ja) 即時オフラインのブロックチェイントランザクションのセキュリティを高めるのに適しているコンピュータにより実装されるシステム及び方法
US12014338B2 (en) Device for directly transmitting electronic coin data records to another device, and payment system
CN113994357B (zh) 在终端与支付系统之间直接传输电子硬币数据记录的方法
US20220116343A1 (en) Methods and Systems for Creating and Using Massless Currency
JP7128111B2 (ja) ブロックチェーンを介して資産関連活動を制御するシステム及び方法
CN102982441B (zh) 一种处理信息的方法及电子支付设备
CN113508409A (zh) 用于通过区块链网络实现转账的计算机实现的系统和方法
CN111062717B (zh) 一种数据转移处理方法、装置和计算机可读存储介质
JP2020071617A (ja) 取引方法、プログラム、検証装置及び生成方法
JP2002530723A (ja) 支払いを発効させる方法およびそのための装置
KR101951408B1 (ko) 보안성을 강화한 가상화폐 관리 시스템
JP7556464B2 (ja) 電子通貨システム、情報処理装置、電子通貨発行方法およびプログラム
KR20200021342A (ko) 블록체인 기반 결제 방법 및 시스템
CN113516461A (zh) 一种基于分布式账本的量子货币交易方法
CN108090751A (zh) 电子现金系统
CN116802662A (zh) 交互信道平衡
JP3599493B2 (ja) 発行機関分離型番号登録式電子現金方法および利用者装置
WO2025094279A1 (ja) 通貨処理装置、通貨処理方法及びプログラム
US11651354B2 (en) Efficient partially spendable e-cash
WO2025094278A1 (ja) 情報処理装置、情報システム、情報処理方法、及びプログラム
JP3171227B2 (ja) 信託機関付き電子紙幣実施方法
AU2015203621B2 (en) Dynamic electronic money
US12632840B2 (en) Electronic currency system, information processing apparatus, electronic currency issuing method and program
JP3329438B2 (ja) 監視機関つき電子現金方法及びそれを実施するための利用者装置及び監視機関装置
JP3435682B2 (ja) 電子現金預け入れ方法、その装置およびプログラム記録媒体

Legal Events

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

Ref document number: 24935941

Country of ref document: EP

Kind code of ref document: A1