Method and system for implementing electronic currency infrastructure

Abstract

This method which is for implementing an electronic currency infrastructure and which is executed by a computer comprises: a step for generating an electronic file to which a predetermined property value is imparted; a step for adding, to the electronic file, first signature data generated by using a secret key of a central bank; a step for adding, to the electronic file, second signature data generated by using a secret key of a first entity in order to transfer the electronic file from the first entity to a second entity after the first signature data is added; a step for recording at least a part of the content of the electronic file in a ledger; and a step for determining, on the basis of at least the content recorded in the ledger, whether there is an unauthorized transfer of the electronic file.

Description

Method and system for implementing an electronic currency infrastructure

[0001] The present disclosure relates to methods and systems for implementing an electronic currency infrastructure.

[0002] In addition to transactions using real money, transactions are also being conducted using various virtual currencies. One example of such a virtual currency is known as Bitcoin. For example, Japanese Patent No. 5871347 (Patent Document 1) discloses a configuration for providing a virtual currency with little fluctuation in value that can continue to pay rewards to miners indefinitely.

[0003] Japanese Patent No. 5871347

[0004] Bitcoin is based on a network of cryptographic proofs, which require large commitments and are resource-intensive, making cryptocurrency transactions expensive and slow, and not possible to transfer cryptocurrency directly.

[0005] The present disclosure provides an electronic currency infrastructure that can realize safe currency circulation without consuming large amounts of resources such as networks.

[0006] According to one embodiment of the present disclosure, there is provided a computer-implemented method for implementing an electronic currency infrastructure, the method including the steps of: generating an electronic file having a predetermined financial value assigned thereto; adding first signature data generated using a private key of a central bank to the electronic file; adding second signature data generated using a private key of a first entity to the electronic file after the first signature data has been added, in order to transfer the electronic file from the first entity to a second entity; recording at least a portion of the contents of the electronic file in a ledger; and determining whether or not there has been an unauthorized transfer of the electronic file based at least on the contents recorded in the ledger.

[0007] Determining whether there has been an unauthorized transfer of the electronic file may include determining whether there are records associated with the electronic file of each transfer of the electronic file from the first entity to a plurality of entities.

[0008] The method may further include a step of, after transmitting the electronic file from the first entity to the second entity, deleting the electronic file stored by the first entity when the first entity receives the electronic file from the second entity to which third signature data generated using the private key of the second entity has been added.

[0009] The method may further include the step of the second entity verifying second signature data included in the electronic file using the public key of the first entity.

[0010] The electronic file may include an expiration date. The method may further include, prior to transferring the electronic file from the first entity to the second entity, at least one of the first entity and the second entity verifying that the expiration date of the electronic file has not expired.

[0011] The method may further include a step, performed after the second entity receives the electronic file from the first entity, of matching the contents of the electronic file with the contents recorded in the ledger.

[0012] The method may further comprise the step of the central bank retrieving the electronic file if the electronic file has expired.

[0013] According to another embodiment of the present disclosure, there is provided a system for realizing an electronic currency infrastructure, the system including: means for generating an electronic file assigned a predetermined financial value; means for adding first signature data generated using a private key of a central bank to the electronic file; means for adding second signature data generated using a private key of a first entity to the electronic file after the first signature data has been added, in order to transfer the electronic file from the first entity to a second entity; a ledger for recording at least a portion of the contents of the electronic file; and means for determining whether or not the electronic file has been transferred fraudulently based on at least the contents recorded in the ledger.

[0014] According to the present disclosure, safe currency circulation can be achieved without consuming large amounts of resources such as networks.

[0015] FIG. 1 is a schematic diagram showing an example of the configuration of an electronic currency infrastructure according to the present embodiment. FIG. 1 is a schematic diagram showing an example of the hardware configuration of an information processing device used in the electronic currency infrastructure according to the present embodiment. FIG. 2 is a schematic diagram showing an example of the hardware configuration of a mobile device used in the electronic currency infrastructure according to the present embodiment. FIG. 3 is a diagram for explaining an example of circulation of electronic currency in the electronic currency infrastructure according to the present embodiment. FIG. 4 is a schematic diagram showing an example of the data structure of electronic currency according to the present embodiment. FIG. 5 is a schematic diagram showing an example of an chain of trust in the electronic currency infrastructure according to the present embodiment. FIG. 6 is a schematic diagram showing an example of the data structure of a trust control section (trust authentication section) of electronic currency according to the present embodiment. FIG. 7 is a schematic diagram showing an example of the data structure of transaction data in a transaction control section of electronic currency according to the present embodiment. FIG. 8 is a schematic diagram showing an example of the data structure of checkpoint data in a special section of electronic currency according to the present embodiment. FIG. 9 is a schematic diagram showing an example of the data structure of a ledger in the electronic currency infrastructure according to the present embodiment. FIG. 10 is a diagram for explaining an example of basic processing procedures for transfer of electronic currency between entities in the electronic currency infrastructure according to the present embodiment. FIG. 11 is a diagram for explaining an example of basic processing procedures for transfer of electronic currency including planning in the electronic currency infrastructure according to the present embodiment. FIG. 12 is a sequence diagram showing processing procedures for circulation of electronic currency in the electronic currency infrastructure according to the present embodiment. It is a sequence diagram showing another processing procedure of the circulation of electronic currency in the electronic currency infrastructure according to the present embodiment. It is a flowchart showing an example of a processing procedure in the ledger of the electronic currency infrastructure according to the present embodiment. It is a diagram for explaining an example of verification of consistency in the ledger of the electronic currency infrastructure according to the present embodiment.

[0016] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will be described in detail with reference to the accompanying drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals and the description thereof will not be repeated.

[0017] <A. Terminology> In this specification, "currency" includes not only currencies recognized as legal tender by a country (legal tender), but also electronic money that has the same value as legal tender. "Currency" may also include virtual currencies or crypto assets, which have financial value.

[0018] B. Overview This disclosure includes a computer-implemented method and system for implementing an electronic currency infrastructure. First, an overview of the electronic currency infrastructure 1 according to this embodiment will be described. In the electronic currency infrastructure 1, electronic currency 10, which has the same financial value as physical currency such as banknotes and coins, is circulated. The electronic currency 10 can also be referred to as digital currency. Each electronic currency 10 may be a single electronic file.

[0019] In the electronic currency infrastructure 1, electronic currency 10 is a unit of currency recognized by a central bank, and its authenticity and reliability in circulation are guaranteed by a digital signature. The financial value assigned to each electronic currency 10 may be one of a predetermined number of denominations, as with physical currency, or there may be more denominations than physical currency.

[0020] Fig. 1 is a schematic diagram showing an example of the configuration of an electronic currency infrastructure 1 according to this embodiment. Referring to Fig. 1, the electronic currency infrastructure 1 includes, for example, one or more issuing authorities 2, a central bank 3, one or more financial institutions 4, one or more sellers 5, and one or more consumers 6. In the electronic currency infrastructure 1, the central bank 3 is the entity that guarantees the authenticity of electronic currency 10.

[0021] The issuing authority 2 is an institution that issues electronic currency 10. The issuing authority 2 corresponds to an issuer of electronic currency trusted by the central bank 3. The issuing authority 2 has a key pair 22 consisting of a private key 22A and a public key 22B. The issuing authority 2 generates an electronic file that is the substance of the electronic currency 10 according to predetermined conditions or in accordance with instructions from the central bank 3 or the like.

[0022] The generated electronic file is assigned a predetermined financial value. The generated electronic file (electronic currency 11) may include initial data as described below. The generated electronic currency 11 is transferred from the issuing authority 2 to the central bank 3 (step S1). The issuing authority 2 corresponds to a printing authority or a mint in comparison with the infrastructure through which physical currency circulates.

[0023] The central bank 3 provides the electronic currency 10 to the market, collects the electronic currency 10 from the market, and manages the total amount of the electronic currency 10 in circulation. The central bank 3 may be a Federal Reserve Bank. The central bank 3 has a key pair 23 consisting of a private key 23A and a public key 23B. Before the electronic currency 11 is provided to the market, signature data generated using the public key 23B of the central bank 3 is added to the electronic currency 11 (electronic currency 12). The electronic currency 12 is provided to the market, for example, via one or more financial institutions 4 (step S2).

[0024] In this way, the central bank 3 (its computer) adds the signature data (first signature data) generated using the private key 23A of the central bank 3 to the electronic currency 10 (electronic file).

[0025] In the example configuration shown in Fig. 1, the issuing authority 2 generates electronic currency 10 (electronic file) to which a predetermined financial value has been assigned. The electronic currency 10 (electronic file) may not only be generated by (the computer of) the issuing authority 2, but also by (the computer of) the central bank 3, or by (the computer of) another institution delegated by the central bank 3.

[0026] The financial institution 4 provides electronic currency 10 to sellers 5 and consumers 6, collects electronic currency 10 from sellers 5 and consumers 6, and performs various payments to sellers 5 and consumers 6. The financial institution 4 has a key pair 24 consisting of a private key 24A and a public key 24B.

[0027] For example, when a consumer 6 requests the financial institution 4 to withdraw a specified amount from his or her savings account, the financial institution 4 provides the consumer 6 with electronic currency 13 having a financial value of the specified amount (step S3). The financial institution 4 has a key pair 24 consisting of a private key 24A and a public key 24B. In addition to the transaction data described below, the financial institution 4 adds information (hereinafter also referred to as "checkpoint data") for verifying the transfer of the electronic currency 10 to the electronic currency 12 (checkpoint data 31). As described below, the checkpoint data 31 includes signature data generated using the private key 24A of the financial institution 4.

[0028] The checkpoint data included in the electronic currency 10 serves as evidence that completely guarantees the distribution path of the electronic currency 10 up to that point. For this reason, signature data of the entity handling the electronic currency 10 is added to the checkpoint data. The signature data included in the checkpoint data 31 ensures non-repudiation of the transfer of the electronic currency 10.

[0029] The electronic currency 13 with the added checkpoint data 31 is provided to the consumer 6. When the consumer 6 withdraws a specified amount from his or her deposit account, an ATM (Automatic Teller Machine) or the like may be used, or the computer of the financial institution 4 and the computer of the consumer 6 may receive the electronic currency 10 via a network.

[0030] The consumer 6 provides the seller 5 with electronic currency 13 provided by the financial institution 4 as payment for the purchase of goods and services. For example, the consumer 6 notifies the seller 5 of the amount of payment for the goods or services the seller 5 wishes to purchase. When the consumer 6 approves the notified amount, the consumer 6 adds checkpoint data 32, in addition to the transaction data, to the electronic currency 13 having the financial value of the approved amount.

[0031] The electronic currency 14 with the added checkpoint data 32 is transferred from the consumer 6 to the seller 5 (step S4). The checkpoint data 32 includes signature data generated using the consumer 6's private key 26A.

[0032] The financial value of electronic currency 10 may be determined when it is issued by the issuing authority 2. Therefore, the consumer 6 does not necessarily own electronic currency 10 having the same financial value as the consideration. In such a case, the consumer 6 may send multiple electronic currency 10 to the seller 5 in a single transaction so that the amount of the necessary consideration is equal to the amount of physical currency, just as when paying with physical currency. Alternatively, the seller 5 may send electronic currency 10 equivalent to "change" to the consumer 6.

[0033] The seller 5 has a key pair 24 consisting of a private key 25A and a public key 25B. The seller 5 can convert the electronic currency 10 in his / her possession into cash or deposit the financial value of the electronic currency 10 in his / her possession into his / her own savings account at any time. For example, when the financial institution 4 approves the conversion or deposit, the seller 5 adds checkpoint data 33 to the electronic currency 14 in addition to the transaction data.

[0034] The electronic currency 15 with the added checkpoint data 33 is transferred from the seller 5 to the financial institution 4 (step S5). The checkpoint data 33 includes signature data generated using the seller 5's private key 25A.

[0035] The financial institution 4 provides the seller 5 with physical currency equivalent to the financial value of the received electronic currency 15, or adds the financial value of the received electronic currency 15 to the balance of the seller's 5 deposit account.

[0036] Similarly, consumers 6 can convert the electronic currency 10 they own into cash, or deposit the financial value of the electronic currency 10 they own into their own savings account.

[0037] In this way, each of the financial institution 4 (its computer), the seller 5 (its computer), and the consumer 6 (its computer) adds signature data (first signature data) generated by the central bank 3 using the central bank's 3 private key 23A to the electronic currency 10, and then adds signature data (second signature data) generated using their own private key to the electronic file in order to transfer the electronic currency 10 from themselves to another entity.

[0038] In the electronic currency infrastructure 1, an expiration date (validity date and time) is set for the electronic currency 10. When the expiration date set for the electronic currency 10 expires (when the set validity date and time arrives), the electronic currency 10 can no longer be circulated in the market. The expired electronic currency 10 is returned to the central bank 3. The central bank 3 (or the issuing authority 2) issues new electronic currency 10. The expiration date may be determined arbitrarily based on the central bank 3's policy for distributing the electronic currency 10, etc. For example, the length of the expiration date may be set to about six months from the date of issuance of the electronic currency 10.

[0039] The electronic currency 10 provided to the market by the central bank 3 will circulate among financial institutions 4, sellers 5, consumers 6, etc. until certain conditions are met. The certain conditions include, for example, when the expiration date of the electronic currency 10 has expired, or when there is insufficient space to record checkpoint data of the electronic currency 10, etc.

[0040] When the electronic currency 10 can no longer be circulated in the market, the central bank 3 withdraws the electronic currency 10. In this way, when the expiration date of the electronic currency 10 has expired, the central bank 3 withdraws the electronic currency 10.

[0041] At any time, financial institutions 4 can deposit the financial value of the electronic currency 10 they own into their own savings account at the central bank 3. For example, when the central bank 3 approves the deposit, financial institutions 4 add checkpoint data 34 to the electronic currency 15. The checkpoint data 34 includes signature data generated using the private key 24A of the financial institution 4.

[0042] The electronic currency 16 including the checkpoint data 34 is transferred from the financial institution 4 to the central bank 3 (step S6). The central bank 3 adds the financial value of the received electronic currency 16 to the balance of the deposit account at the financial institution 4.

[0043] For the sake of convenience, an example has been described in which the transfer of electronic currency 10 from the financial institution 4 to the consumer 6, the transfer of electronic currency 10 from the consumer 6 to the seller 5, and the transfer of electronic currency 10 from the seller 5 to the financial institution 4 are carried out sequentially, but generally, transactions mediated by electronic currency 10 are repeated between the seller 5 and the consumer 6. Therefore, electronic currency 10 may be transferred multiple times between one or more sellers 5 and one or more consumers 6.

[0044] Also, the financial institution 4 may provide the electronic currency 10 received from the merchant 5 or consumer 6 back to the merchant 5 or consumer 6 upon request, rather than transferring it to the central bank 3.

[0045] The electronic currency infrastructure 1 includes a ledger 8. The ledger 8 stores historical information regarding transactions or transfers of electronic currency 10. In the example configuration shown in Figure 1, the ledger 8 is network accessible to one or more issuing authorities 2, a central bank 3, one or more financial institutions 4, and one or more sellers 5. The ledger 8 may be managed by the issuing authorities 2 and / or the central bank 3.

[0046] 1 illustrates a single ledger 8, a distributed ledger consisting of multiple servers may also be used. Also, a master ledger 8 may be prepared, and one or more clone or slave ledgers 8 may be prepared.

[0047] When one or more issuing authorities 2, a central bank 3, one or more financial institutions 4, and one or more sellers 5 receive electronic currency 10 from another entity, or when they provide electronic currency 10 to another entity, they each store information indicating the details of the transaction in a ledger 8. The ledger 8 records at least a portion of the contents of the electronic currency 10 (electronic file). Note that not all sellers 5 need have network access to the ledger 8.

[0048] For simplicity of explanation, FIG. 1 does not include checkpoint data added to electronic currency 10 for transfers of electronic currency 10 from issuing authority 2 to central bank 3, and for transfers of electronic currency 10 from central bank 3 to financial institution 4, but checkpoint data may be added to electronic currency 10 whenever electronic currency 10 is transferred between entities.

[0049] At least some entities of the electronic currency infrastructure 1 can determine whether or not there has been an unauthorized transfer of electronic currency 10 (electronic file) based on at least the contents recorded in the ledger 8. Unlike virtual currency, the presence or absence of an unauthorized transfer of electronic currency 10 can be determined by referring to the ledger 8 at any time, so there is no significant consumption of network resources, etc. At the same time, since unauthorized transfer of electronic currency 10 can be reliably detected, safe currency circulation can be achieved.

[0050] <C. Example of Hardware Configuration> Next, an example of the configuration of hardware used in the electronic currency platform 1 according to the present embodiment will be described.

[0051] 2 is a schematic diagram showing an example of the hardware configuration of an information processing device 100 used in the electronic currency infrastructure 1 according to this embodiment. The information processing device 100 shown in FIG. 2 is used to execute information processing in, for example, the issuing authority 2, the central bank 3, the financial institution 4, the seller 5, and the ledger 8.

[0052] Referring to FIG. 2, the information processing device 100 conforms to a known computer architecture and includes one or more processors 102 , a memory 104 , an input unit 106 , a display unit 108 , a storage 110 , and a network interface 120 .

[0053] The processor 102 sequentially reads and executes computer-readable instructions. The processor 102 is configured, for example, by a CPU (Central Processing Unit). The processor 102 may have multiple cores.

[0054] In this specification, the term "processor" includes at least a CPU, a GPU (Graphics Processing Unit), an ASIC (Application Specific Integrated Circuit), and an FPGA (Field-Programmable Gate Array). Furthermore, in this specification, the term "processor" also includes an SoC (System on Chip). "Processor" can also be referred to as processing circuitry.

[0055] The memory 104 is a volatile storage device such as a dynamic random access memory (DRAM) or a static random access memory (SRAM). The storage 110 is a non-volatile storage device such as a hard disk drive (HDD) or a solid state drive (SSD).

[0056] In this specification, the term "memory" encompasses both memory and storage. Various programs and various data are stored in storage 110. Processor 102 reads designated portions or computer-readable instructions from the programs stored in storage 110, expands them in memory 104, and executes them sequentially to realize various processes, as will be described later.

[0057] The storage 110 stores, for example, an OS 112, an application program 114, and a key pair 116. The OS 112 is a program that provides an environment for executing various processes in the information processing device 100. The application program 114 includes computer-readable instructions for executing processes required for the electronic currency infrastructure 1 according to this embodiment. The key pair 116 may be stored in a secure area of ​​the storage 110, or may be stored in a secure device (not shown) separate from the storage 110.

[0058] The input unit 106 accepts user operations and the like on the information processing device 100. The input unit 106 may be, for example, a keyboard, a mouse, a touch panel arranged in association with the display unit 108, or a switch arranged somewhere on the housing of the information processing device 100. The input unit 106 may include an interface for communicating with the input device.

[0059] The display unit 108 visualizes the processing results of the processor 102. The display unit 108 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display. The display unit 108 may include an interface for communicating with a display device.

[0060] The network interface 120 mediates communication with other devices. The network interface 120 may be, for example, an Ethernet (registered trademark) port, a Universal Serial Bus (USB) port, a serial port such as IEEE 1394, a legacy parallel port, etc. The network interface 120 may include a processing circuit and an antenna for wireless communication.

[0061] 3 is a schematic diagram showing an example of the hardware configuration of a mobile device 200 used in the electronic currency platform 1 according to this embodiment. The mobile device 200 shown in FIG. 3 is used to execute information processing in each of, for example, a seller 5 and a consumer 6.

[0062] Referring to FIG. 3, the mobile device 200 conforms to a known computer architecture and includes one or more processors 202, memory 204, an input unit 206, a display unit 208, storage 210, a camera 220, a speaker 222, a wireless communication unit 224, and a near-field communication unit 226.

[0063] The processor 202, memory 204, input unit 206, display unit 208, and storage 210 are similar to the processor 102, memory 204, input unit 206, display unit 208, and storage 210 shown in Figure 2, respectively, so detailed descriptions will not be repeated.

[0064] The storage 210 stores, for example, an OS 212, an application program 214, and a key pair 216.

[0065] The camera 220 is provided on the housing of the mobile device 200 and captures still images and moving images.

[0066] The speaker 222 is provided on the housing of the mobile device 200 and generates sound according to instructions from the processor 202 .

[0067] The wireless communication unit 224 mediates communication with other information processing devices, etc., via a public line, etc. The wireless communication unit 224 may be, for example, 5G, 4G, LTE, 3G, etc.

[0068] The short-range communication unit 226 mediates communication with other mobile devices present in the vicinity of the mobile device 200. The short-range communication unit 226 may be, for example, an interface conforming to a communication standard such as wireless LAN, Bluetooth (registered trademark), or ZigBee (registered trademark).

[0069] The information processing device 100 and / or the mobile device 200 may further include a component for reading computer-readable instructions and / or data from non-transitory media on which the computer-readable instructions and / or data are stored. The media may be, for example, optical media such as a digital versatile disc (DVD) or semiconductor media such as a USB memory. The information processing device 100 and / or the mobile device 200 may obtain the necessary computer-readable instructions and / or data from a distribution server on a network.

[0070] The processing required for the electronic currency infrastructure 1 can be realized using any computing resource. The computing resource is not limited to the hardware configuration examples shown in Figures 2 and 3, and any hardware can be used.

[0071] In the following description, the term "entity" includes any individual or corporation that can express its intentions related to the electronic currency infrastructure 1 (including the issuing authority 2, the central bank 3, the financial institution 4, the seller 5, and the consumer 6), as well as computers used by individuals or corporations (including the information processing device 100 and / or the mobile device 200). In other words, each entity encompasses the concept of an individual or corporation that can express its intentions and a computer used by the individual or corporation.

[0072] Additionally, the term "entity" may encompass computers that make decisions through AI (Artificial Intelligence).

[0073] Many of the processes described below are initiated and executed according to the will of an individual, corporation, or AI, although the processes that handle electronic currency 10 are themselves realized by a computer.

[0074] <D. Example of Circulation of Electronic Currency> Next, an example of circulation of electronic currency 10 in electronic currency infrastructure 1 according to the present embodiment will be described.

[0075] 4 is a diagram illustrating an example of the circulation of electronic currency 10 in the electronic currency platform 1 according to this embodiment. In FIG. 4, the area where the ledger 8 is accessible via a network is referred to as a networked zone 60, and the area where the ledger 8 is not accessible via a network is referred to as a non-networked zone 62.

[0076] Entities present in networked zone 60 can record the contents of electronic currency 10 in ledger 8 and can also refer to the contents of electronic currency recorded in ledger 8. Therefore, as electronic currency 10 circulates, a history including checkpoint data is added to electronic currency 10 itself, and the contents of the checkpoint data of electronic currency 10 are sequentially reflected in ledger 8.

[0077] On the other hand, entities residing in the non-network zone 62 do not have network access to the ledger 8, so the circulation of electronic currency 10 is based on inferred trust between other users or entities held by those users. Therefore, the history of electronic currency 10, including checkpoint data, is added only to the electronic currency 10 itself. However, the contents of electronic currency 10 may be updated in the ledger 8 at any time.

[0078] The checkpoint data of the electronic currency 10 includes signature data for ensuring non-repudiation of actions (transfer of the electronic currency 10) by the entity that owns the electronic currency 10.

[0079] 4, first, the issuing authority 2 issues electronic currency 10 (step S51). Specifically, the issuing authority 2 generates information necessary for the electronic currency 10 and generates an electronic file containing the generated information. The issuing authority 2 generates electronic currency 10 (electronic file) to which a predetermined financial value has been assigned.

[0080] When the central bank 3 receives the electronic currency 10 issued by the issuing authority 2, it adds a record of the received electronic currency 10 to the ledger 8 (step S52). In this way, the central bank 3 records at least a portion of the contents of the electronic currency 10 in the ledger 8. The added record includes identification information for identifying the electronic currency 10. The identification information of the electronic currency 10 may be used as the file name of the electronic currency 10.

[0081] The central bank 3 provides the electronic currency 10 to the market. Specifically, the central bank 3 adds signature data generated using the private key 23A of the central bank 3 to the electronic currency 10 (step S53). In this way, the central bank 3 adds the signature data generated using the private key 23A of the central bank 3 to the electronic currency 10 (electronic file).

[0082] When the financial institution 4 receives the electronic currency 10 from the central bank 3, it updates the ledger 8 with the information about the received electronic currency 10 (step S54). In this way, the financial institution 4 records at least a portion of the contents of the electronic currency 10 in the ledger 8.

[0083] In response to a request from consumer 6A, who is a depositor at financial institution 4, financial institution 4 pays out a specified amount of electronic currency 10 from consumer 6A's deposit to consumer 6A. Specifically, financial institution 4 adds signature data generated using financial institution 4's private key 24A to electronic currency 10, and then transfers electronic currency 10 to consumer 6A (step S55). In this way, financial institution 4 adds signature data generated using financial institution 4's private key 24A to electronic currency 10 in order to transfer electronic currency 10 from financial institution 4 (first entity) to consumer 6A (second entity).

[0084] The financial institution 4 also updates the ledger 8 with information about the electronic currency 10 transferred to the consumer 6A (step S56). In this way, the financial institution 4 records at least a portion of the contents of the electronic currency 10 in the ledger 8.

[0085] Next, assume that consumer 6A hands over electronic currency 10 to consumer 6B. In this case, consumer 6A adds signature data generated using consumer 6A's private key 26AA to electronic currency 10, and then transfers electronic currency 10 to consumer 6B (step S57). In this way, consumer 6A adds signature data generated using consumer 6A's private key 26AA to electronic currency 10 in order to transfer electronic currency 10 from consumer 6A (first entity) to consumer 6B (second entity). Note that the transfer of electronic currency 10 at this point is based on the trust between consumer 6A and consumer 6B.

[0086] Next, assume that consumer 6B pays seller 5 with the electronic currency 10 received from consumer 6A as payment for the purchase of goods and services. Seller 5 is assumed to be located in networked zone 60. In this case, consumer 6B offers to pay seller 5 with electronic currency 10. Specifically, consumer 6B adds checkpoint data and then transmits the electronic currency 10 to be paid to seller 5 (step S58).

[0087] The seller 5 reflects the content of the electronic currency 10 offered by the consumer 6B in the ledger 8 (step S59). In this way, the seller 5 records at least a part of the content of the electronic currency 10 in the ledger 8.

[0088] The seller 5 obtains the result of the information being reflected in the ledger 8 (step S60). After the seller 5 (second entity) receives the electronic currency 10 (electronic file) from the consumer 6B (first entity) in this way, the seller 5 compares the contents of the electronic currency 10 with the contents recorded in the ledger 8. If the contents of the electronic currency 10 recorded in the ledger 8 do not match the contents of the electronic currency 10 offered by the consumer 6B, the seller 5 may reject the offer from the consumer 6B. In other words, the seller 5 determines whether or not there has been an unauthorized transfer of the electronic currency 10 based at least on the contents recorded in the ledger 8.

[0089] If there is no problem with consistency with the information recorded in ledger 8, seller 5 responds to consumer 6B that it accepts consumer 6B's offer (step S61). Consumer 6B deletes the electronic currency 10 that consumer 6B holds. In this way, consumer 6B adds signature data generated using consumer 6B's private key 26AB to the electronic currency 10 in order to transfer the electronic currency 10 from consumer 6B (first entity) to seller 5 (second entity). When electronic currency 10 is transferred from consumer 6B to seller 5, payment using electronic currency 10 is completed.

[0090] Thereafter, seller 5 deposits the electronic currency 10 received from consumer 6B and others into seller 5's deposit account at financial institution 4. Specifically, seller 5 adds signature data generated using seller 5's private key 25A to the electronic currency 10, and then transfers the electronic currency 10 to financial institution 4 (step S62). Financial institution 4 updates the balance of seller 5's deposit account according to the amount of electronic currency 10 received from seller 5.

[0091] The seller 5 also executes the same process when exchanging the electronic currency 10 for cash. In the case of currency exchange, the financial institution 4 provides the seller 5 with cash equivalent to the amount of the electronic currency 10 received from the seller 5.

[0092] The financial institution 4 may also reuse the electronic currency 10 received from the merchant 5 for disbursement to the consumer 6 and / or the merchant 5 .

[0093] The financial institution 4 then returns the electronic currency 10 received from the seller 5 to the central bank 3. Specifically, the financial institution 4 adds signature data generated using the private key 24A of the financial institution 4 to the electronic currency 10, and then transfers the electronic currency 10 to the central bank 3 (step S63). The central bank 3 updates the balance of the financial institution 4's deposit account at the central bank 3 in accordance with the amount of electronic currency 10 received from the financial institution 4. Alternatively, the central bank 3 may provide new electronic currency 10 to the financial institution 4 in accordance with the amount of electronic currency 10 received from the financial institution 4.

[0094] Finally, when predetermined conditions are met, the central bank 3 discards the electronic currency 10 collected from the financial institution 4 (step S64). Discarding the electronic currency 10 may involve deleting the electronic file itself, or managing the electronic currency 10 so that it is not recirculated.

[0095] E. Data Structure Next, an example of the file format of the electronic currency 10 (electronic file) will be described. The electronic currency 10 may be stored in binary format.

[0096] 5 is a schematic diagram showing an example of the data structure of electronic currency 10 according to this embodiment. Referring to FIG. 5, electronic currency 10 may include, for example, the following sections: (1) Document root control section 40 (2) Trust control section 42 (3) Transaction control section 44 (4) Special section 46 The data of each section may include, as header information, a section type indicating the type of the section, a section flag indicating the status of the section, and a section length indicating the length of the section.

[0097] (e1: Document Route Control Section 40) The document route control section 40 of the electronic currency 10 generated by the issuing authority 2 may include initial data 41 including the following settings: (a) Creation Time (e.g., TAI64N format) (b) Expiry Date (Spent at Time) (e.g., TAI64N format) (c) Currency Code (e.g., 3 bytes according to ISO 4217, such as USD or JPY) (d) Currency Denomination (e.g., a non-zero unsigned integer) (e) Sequential Identifier (e.g., 13 bytes) (f) Decimal Place (number of digits indicating the decimal point position or subunit indicator position: for example, 2 is set for USD and 0 is set for JPY) (g) Public Key of Issuing Authority 2 (h) Signature data for the central bank 3 to approve the public key of the issuing authority 2 (a random nonce may be added) (i) A hash value of a key string of the electronic currency 10 (for example, a hash string calculated from a specific keyword) (j) A serial number of the electronic currency 10 (for example, a hash value of the initial data (1) to (9)) (e2: Trust Control Section 42) The trust control section 42 includes a trust authorization section 43 (TAS). The trust authorization section 43 may be metadata, and may store information for linking the public key to the central bank 3 (the root of the electronic currency 10).

[0098] In the electronic currency infrastructure 1 according to this embodiment, a complete chain of trust for electronic currency 10 is formed using digital signatures including financial institutions 4, merchants 5, and consumers 6 that use currency provided to the public by a central bank 3. The formed chain of trust includes entities involved in the circulation of electronic currency 10.

[0099] The integrity of the signatory may be supported by the signature of an intermediary (e.g., local issuing authority, Department of State, Department of Treasury, notary public, etc.) that extends trust to the Central Bank 3.

[0100] 6 is a schematic diagram showing an example of a chain of trust in the electronic currency infrastructure 1 according to the present embodiment. Referring to FIG. 6 , a first intermediate entity (INTERMEDIATE L0) is connected to a central bank 3 functioning as a root (ROOT). The first intermediate entity may include, for example, a local issuing authority 51, a department of state 52, and a department of the treasury 53. The first intermediate entity is connected to a second intermediate entity (INTERMEDIATE L1). The second intermediate entity may include, for example, a financial institution 4 and a notary public 54. The second intermediate entity is connected to users. The users may include an ATM 56, a merchant 5, a consumer 6, and a government agency 55.

[0101] The integrity of the links that make up the chain of trust that represents the circulation of electronic currency 10 is guaranteed by signature data stored in trust authentication section 43. The links that make up the chain of trust are defined within electronic currency 10. As electronic currency 10 is transferred, the links that make up the chain of trust are updated or added as necessary.

[0102] 7 is a schematic diagram showing an example of the data structure of the trust control section 42 (trust authentication section 43) of the electronic currency 10 according to the present embodiment. Referring to FIG. 7, the trust authentication section 43 includes a validity period start time 431, a validity period end time 432, a role code 433, an issuer public key 434, an entity public key 435, and signature data 436.

[0103] The validity period start time 431 is the same value as the creation time included in the initial data 41. The processing time included in the checkpoint data of the electronic currency 10 must be on or after the validity period start time 431. In other words, if the processing time is earlier than the validity period start time 431, it is treated as an invalid procedure or process.

[0104] The validity period end time 432 is the same value as the expiration date included in the initial data 41. The processing time included in the checkpoint data of the electronic currency 10 must be on or before the validity period end time 432. In other words, if the processing time is later than the validity period start time 431, it will be treated as an invalid procedure or process.

[0105] The role code 433 includes information indicating which link in the chain of trust shown in Fig. 6 it corresponds to. For example, the role code 433 includes information indicating that the local issuing authority 51, which functions as the first intermediate entity, is trusted to the central bank 3, which functions as the root.

[0106] Issuer public key 434 is the public key of Central Bank 3, which acts as the root. Entity public key 435 is the public key of an entity that demonstrates trust. The entity that demonstrates trust may belong to either the first intermediate entity, the second intermediate entity, or the user.

[0107] The signature data 436 is generated from the information included in the trust certification section 43 (the validity period start time 431, the validity period end time 432, the role code 433, the issuer public key 434, and the entity public key 435) using the private key that pairs with the entity public key 435. In other words, the signature data 436 is generated by inputting the information included in the trust certification section 43 (excluding the signature data 436) into a hash function to calculate a hash value, and encrypting the hash value with the private key that pairs with the entity public key 435.

[0108] A third party can check and verify the chain of trust leading to the central bank 3 functioning as the root by referring to the information in the trust authentication section 43. The trust authentication section 43 is generated for each link constituting the chain of trust shown in Fig. 6. It is preferable to generate the trust authentication section 43 for all links constituting the chain of trust shown in Fig. 6, but the trust authentication section 43 may be generated for only some of the links.

[0109] However, as will be described later, the circulation of electronic currency 10 requires a public key registered in trust control section 42 .

[0110] (e3: Transaction Control Section 44) The transaction control section 44 includes transaction data 45, which is information about interactions between an entity that transfers electronic currency 10 and an entity that receives electronic currency 10. The transaction data 45 indicates, for example, the history of the transfer of electronic currency 10 from one entity to another.

[0111] 8 is a schematic diagram showing an example of the data structure of transaction data 45 in transaction control section 44 of electronic currency 10 according to the present embodiment. Referring to FIG. 8, transaction data 45 includes an Offer entry 451 and an Accept entry 452. As will be described later, Offer entry 451 and Accept entry 452 may be added by different entities at different times.

[0112] The Offer entry 451 includes a type 453 of "Offer", a transaction ID 454, and an entity public key 455. The Accept entry 452 includes a type 453 of "Accept", a transaction ID 454, and an entity public key 455.

[0113] Offer entry 451 is added by an entity that owns electronic currency 10 when the entity that owns electronic currency 10 offers to transfer electronic currency 10 to another entity. Thus, entity public key 455 is the public key of the entity that owns electronic currency 10.

[0114] Accept entry 452 is added by the entity receiving electronic currency 10 when accepting an offer to transfer electronic currency 10. Entity public key 455 is therefore the public key of the entity receiving electronic currency 10.

[0115] Transaction data 45 shown in FIG. 8 may be added to the transaction control section 44 for each transfer of electronic currency 10 .

[0116] Transaction control section 44 may contain information for providing electronic currency 10 with a known public key and for accepting electronic currency 10 with a new public key. For example, when an entity's key pair (public key) expires, a new key pair (public key) is issued. Transaction control section 44 may store information for updating such key pairs (public keys).

[0117] (e4: Special Section 46) The special section 46 includes an invalidation management section 47 and checkpoint data 48.

[0118] The invalidation management section 47 stores the result of the determination as to whether or not the validity period of the electronic currency 10 has expired. If the validity period of the electronic currency 10 has expired, the electronic currency 10 cannot be further circulated and is only permitted to be returned to the central bank 3.

[0119] Checkpoint data 48 stores checkpoint data sequentially. Signed checkpoint data indicates each point in the distribution path of electronic currency 10. That is, checkpoint data 48 is signed after a successful transfer of electronic currency 10.

[0120] The checkpoint data stored in checkpoint data 48 is discarded unless the following requirements are met: (1) The signer public key is registered in transaction control section 44. (2) The processing time 481 of newly generated checkpoint data 48 is newer than the processing time 481 of previously generated checkpoint data 48. (3) The processing time 481 of newly generated checkpoint data 48 has not passed the validity period end time 432. (4) The processing time 481 of newly generated checkpoint data 48 is older than the current time when the process for performing a series of verifications including (1) to (3) is executed. The above requirements (1) to (4) may be evaluated by the entity that received electronic currency 10, or may be evaluated in ledger 8.

[0121] 9 is a schematic diagram showing an example of the data structure of checkpoint data 48 in special section 46 of electronic currency 10 according to this embodiment. Referring to FIG. 9, checkpoint data 48 includes processing time 481, random nonce 482, signer public key 483, and signature data 484.

[0122] The processing time 481 is the time when the checkpoint data 48 is generated. The random nonce 482 is used in combination with the processing time 481 to enhance security strength.

[0123] The signer public key 483 stores the public key of the entity (source entity) that delivers the electronic currency 10 .

[0124] The signature data 484 is generated from the information included in the checkpoint data 48 (the processing time 481, the random nonce 482, and the signer public key 483) using the private key that pairs with the signer public key 483. That is, the signature data 484 is generated by inputting the information included in the signature data 484 (excluding the signature data 484) into a hash function, calculating a hash value, and encrypting the calculated hash value with the private key that pairs with the signer public key 483.

[0125] Checkpoint data 48 is generated each time electronic currency 10 is circulated between entities.

[0126] (e5: File name of electronic currency 10) The file name of electronic currency 10 may be composed of, for example, a string concatenating the currency code, face value (expressed as an integer multiple of the smallest unit), and serial number, and a file extension (e.g., "snote").

[0127] For example, the file name of electronic currency 10 representing a face value of 10,000 yen in Japanese yen can be set as "JPY-10000-5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.snote." Similarly, the file name of electronic currency 10 representing a face value of 100.00 dollars in U.S. dollars can be set as "USD-10000-48ae15fd45c3ae607e41a72d153d6c051f267c42f5ea11f26e1b33b183eaf0e8.snote." In this case, since the smallest unit of U.S. currency is the cent, the face value is expressed as an integer multiple of cents.

[0128] <F. Ledger 8> Next, the ledger 8 included in the electronic currency infrastructure 1 according to the present embodiment will be described.

[0129] 10 is a schematic diagram showing an example of the data structure of ledger 8 of electronic currency platform 1 according to this embodiment. Referring to FIG. 10, ledger 8 sequentially reflects the contents of electronic currency 10 provided to the market by central bank 3.

[0130] Ledger 8 records the contents of document root control section 40 , trust control section 42 , transaction control section 44 , and special section 46 contained in each electronic currency 10 .

[0131] When an entity located in the networked zone 60 receives electronic currency 10 from another entity, the entity is triggered to record the contents of the received electronic currency 10 in the ledger 8 .

[0132] The ledger 8 may include an engine for verifying the value stored in the invalidation management section 47 included in the special section 46 of the electronic currency 10 (the result of determining whether the expiration date of the electronic currency 10 has expired), and an engine for verifying the integrity of the checkpoint data 48 included in the special section 46 of the electronic currency 10. These engines may execute verification processing when new data is written to the ledger 8.

[0133] A description will be given later of an example of a process for verifying the consistency of the checkpoint data 48. <G. Processing Procedure> Next, an example of a processing procedure in the electronic currency platform 1 according to the present embodiment will be described.

[0134] (g1: Transfer of Electronic Currency 10 Between Entities) First, the transfer of electronic currency 10 between entities will be described.

[0135] 11 is a diagram illustrating an example of the basic processing procedure for transferring electronic currency 10 between entities in the electronic currency infrastructure 1 according to this embodiment. Fig. 11 shows an example in which ownership of electronic currency 10 is changed from one entity (hereinafter also referred to as the "source entity") to another entity (hereinafter also referred to as the "target entity").

[0136] 11, the source entity adds Offer entry 451 (transaction data 45) to electronic currency 10 to be delivered to the target entity, and also adds checkpoint data 48A including signature data generated using the source entity's private key (step S10). The source entity then transmits the electronic currency 10 to which Offer entry 451 and checkpoint data 48A have been added to the target entity (step S11).

[0137] When the target entity approves the transfer of the electronic currency 10 received from the source entity, it adds an Accept entry 452 (transaction data 45) to the received electronic currency 10, and also adds checkpoint data 48B including signature data generated using the target entity's private key (step S12). The target entity then transmits the electronic currency 10 with the Accept entry 452 and checkpoint data 48B added to it to the source entity (step S13).

[0138] When the source entity receives the electronic currency 10 including the Accept entry 452 and the checkpoint data 48B, it deletes the file of the electronic currency 10 stored in the source entity and the file of the electronic currency 10 received from the target entity (step S14).

[0139] In this way, after sending electronic currency 10 (electronic file) from a source entity (first entity) to a target entity (second entity), when the source entity receives electronic currency 10 from the target entity with added checkpoint data 48B (signature data) generated using the target entity's private key, the source entity deletes the electronic currency 10 stored by the source entity.

[0140] The above process completes the transfer of electronic currency 10 from the source entity to the target entity.

[0141] When electronic currency 10 is used as payment for purchasing goods and services, there may be cases where electronic currency 10 does not exist in an amount equal to the payment amount. In other words, there may be cases where an exchange including change is required between entities. In such cases, a process is performed between the entities to coordinate in advance what combination of electronic currency 10 will be used to complete the transaction. This coordination process is also referred to as "planning" hereinafter. In the planning process, multiple electronic currencies 10 to be transferred between the entities are determined. Furthermore, since all transfers of multiple electronic currencies 10 must be completed, a transaction ID is generated to manage the series of transfers.

[0142] 12 is a diagram illustrating an example of a basic processing procedure for transferring electronic currency 10, including planning, in the electronic currency infrastructure 1 according to this embodiment. Referring to FIG. 12, as an example, assume that entity 1 pays 800 yen to entity 2. However, entity 1 does not possess electronic currency 10 in an amount equal to 800 yen. Therefore, entity 1 and entity 2 perform planning.

[0143] As a result of planning, it is decided that entity 1 will transfer electronic currency 10-1 having a value of 1,000 yen to entity 2, and entity 2 will transfer electronic currency 10-6 and 10-7 each having a value of 100 yen to entity 1.

[0144] The transfers of electronic currency 10-1, 10-6, and 10-7 are associated with the same transaction ID.

[0145] For electronic currency 10-1, entity 1 is the source entity and the process shown in Fig. 11 is executed. On the other hand, for electronic currency 10-6 and 10-7, entity 2 is the source entity and the process shown in Fig. 11 is executed.

[0146] A common transaction ID is set in the transaction data 45 (FIG. 8) added to each of the electronic currencies 10-1, 10-6, and 10-7.

[0147] By associating multiple transfers of electronic currency 10 with a common transaction ID, transfers of electronic currency 10 can be reliably completed even in transactions that require change.

[0148] The transaction ID may be determined each time by any entity, or may be determined by sorting the serial numbers of one or more target electronic currencies 10 in a predetermined order, concatenating the sorted results, and calculating a hash value from the concatenated results as the transaction ID.

[0149] A transaction ID determined by the latter method can also be verified based on the contents recorded in the ledger 8. For example, one or more pieces of electronic currency 10 involved in a certain transaction can be extracted from the ledger 8, a transaction ID can be calculated based on the serial numbers of the extracted one or more pieces of electronic currency 10, and then an evaluation can be made as to whether the calculated transaction ID matches the transaction ID recorded in the ledger 8. By evaluating the transaction ID in this way, it can be determined whether or not there has been an unauthorized transfer of electronic currency 10.

[0150] The planning also verifies that the target electronic currency 10 has not expired. Electronic currency 10 that has expired is excluded from the planning process. That is, before transferring electronic currency 10 (electronic file) from a source entity (first entity) to a target entity (second entity), at least one of the source entity and the target entity verifies that the electronic currency 10 has not expired. This verification prevents electronic currency 10 that cannot be circulated in the market from being selected as a transfer target.

[0151] (g2: Circulation of Electronic Currency 10 in Networked Zone 60) Next, the circulation of electronic currency 10 provided to the market by the central bank 3 will be described.

[0152] 13 is a sequence diagram showing the processing procedure for circulating electronic currency 10 in electronic currency infrastructure 1 according to this embodiment. FIG. 13 shows an example of processing for transferring financial value from entity 1 to entity 2.

[0153] Typically, entity 1 is the source entity and entity 2 is the target entity. In the example process shown in Figure 13, entity 1 and entity 2 reside in networked zone 60.

[0154] Referring to FIG. 13, first, communication is established between entity 1 and entity 2 (sequence SQ100).

[0155] When at least one of entity 1 and entity 2 receives a designation of the financial value (amount) to be transferred (sequence SQ102), entity 1 and entity 2 determine, through planning, a transaction ID and one or more electronic currencies 10 to be transferred (sequence SQ104). In the planning, entity 1 and entity 2 also verify that the electronic currencies 10 to be transferred have not expired.

[0156] Entity 1 adds an Offer entry 451 and checkpoint data 48 to each of one or more pieces of electronic currency 10 to be transferred to Entity 2 (sequence SQ106). Entity 1 then transmits to Entity 2 the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added (sequence SQ108).

[0157] Entity 2 verifies the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 using entity 1's public key (sequence SQ110). If the signature data verification passes, entity 2 transmits the contents of the received one or more electronic currencies 10 to ledger 8 (sequence SQ112). After receiving electronic currencies 10 (electronic files) from entity 1, entity 2 compares the contents of the electronic currencies 10 with the contents recorded in ledger 8.

[0158] When entity 2 receives a notification from ledger 8 that there is a problem with the consistency of the contents of one or more electronic currencies 10 that it sent (YES in sequence SQ114), it notifies entity 1 to stop processing (sequence SQ116).

[0159] If entity 2 does not receive a notification from ledger 8 that there is a consistency problem with the contents of the one or more electronic currencies 10 that it sent (NO in sequence SQ114), it adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ118). Entity 2 sends the one or more electronic currencies 10 with the Accept entry 452 and checkpoint data 48 added to entity 1 (sequence SQ120).

[0160] If it is necessary to transfer one or more electronic currencies 10 from entity 2 to entity 1 as change, the processing of sequences SQ122 to SQ136 is also executed.

[0161] Entity 2 adds an Offer entry 451 and checkpoint data 48 to each of one or more pieces of electronic currency 10 to be transferred to Entity 1 (sequence SQ122). Entity 1 sends the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added to Entity 1 (sequence SQ124).

[0162] Entity 1 verifies the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 using entity 2's public key (sequence SQ126). If the signature data verification passes, entity 1 transmits the contents of the received one or more electronic currencies 10 to ledger 8 (sequence SQ128). After receiving electronic currencies 10 (electronic files) from entity 2, entity 1 compares the contents of the electronic currencies 10 with the contents recorded in ledger 8.

[0163] When entity 1 receives a notification from ledger 8 that there is a problem with the consistency of the contents of one or more electronic currencies 10 that it sent (YES in sequence SQ130), it notifies entity 2 to stop processing (sequence SQ132).

[0164] If entity 1 does not receive a notification from ledger 8 that there is a problem with the consistency of the content of the one or more electronic currencies 10 that it sent (NO in sequence SQ130), it adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ134). Entity 1 then sends the one or more electronic currencies 10 with the added Accept entry 452 and checkpoint data 48 to entity 2 (sequence SQ136).

[0165] If entity 1 receives a file with Accept entries 452 and checkpoint data 48 added for all of the one or more electronic currencies 10 to be transferred as determined in the planning (YES in sequence SQ138), it sends the contents of the one or more electronic currencies 10 to be transferred to ledger 8 (sequence SQ140) and deletes the one or more electronic currencies 10 to be transferred from entity 1's storage (sequence SQ142).

[0166] Similarly, if entity 2 receives a file with Accept entries 452 and checkpoint data 48 added for all of the one or more electronic currencies 10 to be transferred as determined in the planning (YES in sequence SQ144), it sends the contents of the one or more electronic currencies 10 to be transferred to ledger 8 (sequence SQ146) and deletes the one or more electronic currencies 10 to be transferred from entity 2's storage (sequence SQ148).

[0167] Through the above process, financial value is transferred from entity 1 to entity 2. Note that entity 1 and entity 2 may update the total amount of electronic currency 10 that each of them owns after the transfer of electronic currency 10.

[0168] (g3: Circulation of Electronic Currency 10 in Non-Network Zone 62) Next, the circulation of electronic currency 10 provided to the market by the central bank 3 will be described.

[0169] 14 is a sequence diagram showing another processing procedure for the circulation of electronic currency 10 in electronic currency infrastructure 1 according to this embodiment. FIG. 14 shows an example of a process for transferring financial value from entity 1 to entity 2.

[0170] Typically, entity 1 is the source entity and entity 2 is the target entity. In the processing example shown in Figure 14, entity 1 and entity 2 both reside in the non-network zone 62.

[0171] Referring to FIG. 14, first, communication is established between entity 1 and entity 2 (sequence SQ200).

[0172] When at least one of entity 1 and entity 2 receives a designation of the financial value (amount) to be transferred (sequence SQ202), entity 1 and entity 2 determine, through planning, a transaction ID and one or more electronic currencies 10 to be transferred (sequence SQ204). In the planning, entity 1 and entity 2 also verify that the electronic currencies 10 to be transferred have not expired.

[0173] Entity 1 adds an Offer entry 451 and checkpoint data 48 to each of one or more pieces of electronic currency 10 to be transferred to Entity 2 (sequence SQ206). Entity 1 then transmits to Entity 2 the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added (sequence SQ208).

[0174] Entity 2 uses entity 1's public key to verify the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 (sequence SQ210). If the verification of the signature data passes, entity 2 adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ212). Entity 2 then transmits the one or more electronic currencies 10 with the added Accept entry 452 and checkpoint data 48 to entity 1 (sequence SQ214).

[0175] If it is necessary to transfer one or more electronic currencies 10 from entity 2 to entity 1 as change, the processing of sequences SQ216 to SQ224 is also executed.

[0176] Entity 2 adds an Offer entry 451 and checkpoint data 48 to each of one or more pieces of electronic currency 10 to be transferred to Entity 1 (sequence SQ216). Entity 1 sends the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added to Entity 1 (sequence SQ218).

[0177] Entity 1 uses entity 2's public key to verify the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 (sequence SQ220). Entity 1 adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ222). Entity 1 then transmits the one or more electronic currencies 10 with the added Accept entry 452 and checkpoint data 48 to entity 2 (sequence SQ224).

[0178] If entity 1 receives a file with Accept entries 452 and checkpoint data 48 added for all of the electronic currency 10 or currencies 10 to be transferred as determined in the planning (YES in sequence SQ226), entity 1 deletes the electronic currency 10 or currencies 10 to be transferred from entity 1's storage (sequence SQ228).

[0179] Similarly, if entity 2 receives a file with Accept entries 452 and checkpoint data 48 added for all of the one or more electronic currencies 10 to be transferred as determined in the planning (YES in sequence SQ230), it deletes the one or more electronic currencies 10 to be transferred from entity 2's storage (sequence SQ232).

[0180] Through the above process, financial value is transferred from entity 1 to entity 2. Note that entity 1 and entity 2 may update the total amount of electronic currency 10 that each of them owns after the transfer of electronic currency 10.

[0181] (g4: Processing Procedure in Ledger 8) FIG. 15 is a flowchart showing an example of a processing procedure in ledger 8 of electronic currency infrastructure 1 according to the present embodiment.

[0182] Referring to FIG. 15, when ledger 8 receives a request from an entity (YES in step S100), it determines the type of the request (step S102).

[0183] If the request is for referencing the ledger 8 ("reference" in step S102), the ledger 8 responds with the registered contents corresponding to the electronic currency 10 specified by the sequential identifier or the like included in the initial data 41 (step S104). Then, the processing from step S100 onwards is repeated.

[0184] If the request is to add data to ledger 8 ("Add" in step S102), ledger 8 verifies the consistency between the registered content corresponding to electronic currency 10 specified by the serial identifier or the like included in initial data 41 and the data requested to be added (step S106). If there is a problem with the consistency (FAIL in step S106), ledger 8 responds that there is a problem with the consistency (step S108). Then, the processing from step S100 onwards is repeated.

[0185] If there is no problem with consistency (OK in step S106), the ledger 8 registers the requested data in association with the specified electronic currency 10 (step S110), and the processing from step S100 onwards is then repeated.

[0186] 16 is a diagram for explaining an example of verification of consistency in the ledger 8 of the electronic currency platform 1 according to this embodiment. FIG. 16 shows an example of double transfer of electronic currency 10.

[0187] Referring to FIG. 16A, it is assumed that entity A has given the same electronic currency 10 to entity B and entity C, respectively.

[0188] As shown in Figure 16 (B), in this case, checkpoint data 48-1 indicating the transfer of electronic currency 10 from entity A to entity B and checkpoint data 48-2 indicating the transfer of electronic currency 10 from entity A to entity C are generated in electronic currency 10.

[0189] When checkpoint data 48 is sorted based on processing time 481, signer public key 483 of checkpoint data 48-1 and signer public key 483 of checkpoint data 48-2 are the same. Based on the value of such signer public key 483, it is possible to detect the occurrence of a duplicate transfer of electronic currency 10. Furthermore, it is possible to identify the owner of the identical public key as the person who made the duplicate transfer.

[0190] In other words, the process of determining whether or not there has been an unauthorized transfer of electronic currency 10 includes a process of determining whether or not there exists a record (checkpoint data 48) associated with electronic currency 10 of the transfer of electronic currency 10 from one entity to multiple entities.

[0191] In this way, the ledger 8 or other entity verifies the consistency of the checkpoint data 48 based on multiple checkpoint data registered in the same electronic currency 10.

[0192] (g5: Expiry date of electronic currency 10) In the electronic currency infrastructure 1 according to this embodiment, an expiration date is set for the electronic currency 10. The central bank 3 (or the issuing authority 2) may issue new electronic currency 10 in response to electronic currency 10 whose expiration date has expired.

[0193] New electronic currency 10 may be issued at the same time as receiving expired electronic currency 10, or may be issued independently of this timing. For example, when expired electronic currency 10 is received, electronic currency 10 of the corresponding amount may be selected from previously issued electronic currency 10 (which has sufficient remaining validity period) and provided.

[0194] The amount of the newly provided electronic currency 10 does not have to be the same as the amount of the expired electronic currency 10. For example, some tax may be deducted in advance. In this case, the amount of the newly provided electronic currency 10 will be the amount of the expired electronic currency 10 minus a predetermined tax amount. Alternatively, inflation or interest rates may be reflected. In this case, the amount of the newly provided electronic currency 10 will be greater than the amount of the expired electronic currency 10.

[0195] In this way, the central bank 3 (or issuing authority 2) can also manage the total amount of currency in circulation.

[0196] <H. Use of Checkpoint Data in Electronic Currency Infrastructure 1> In the electronic currency infrastructure 1 according to this embodiment, it is possible to completely trace the circulation of each electronic currency 10. This makes it possible to prevent the occurrence of criminal or illegal acts such as money laundering.

[0197] Furthermore, by statistically processing the circulation of electronic currency 10, it is possible to estimate the state of economic activity in the city. Furthermore, by generating statistical information after anonymizing the entities involved in the circulation of electronic currency 10, it is possible to calculate economic indicators, etc. Furthermore, it is possible to provide anonymized statistical information either for a fee or free of charge.

[0198] As described above, in the electronic currency platform 1 according to this embodiment, unlike conventional currencies, the circulation of the electronic currency 10 can be completely traced, and therefore economic analysis and the like can be performed with higher accuracy.

[0199] For example, the central bank 3 may constantly monitor the ledger 8, and if it detects any unauthorized transfer of electronic currency 10, it may immediately report the unauthorized transfer to law enforcement agencies (e.g., the police). Furthermore, the central bank 3 (or an institution entrusted by the central bank 3) may generate and provide evidence for legal proceedings (criminal and / or civil proceedings) based on the entries in the ledger 8.

[0200] Furthermore, to prevent money laundering and the like, information indicating the purpose of the transfer may be added to the electronic currency 10. For example, a code conforming to the International Standard Industrial Classification of All Economic Activities (ISIC) may be used. When paying with the electronic currency 10 as payment for goods and services, a user may add a code indicating the goods or services to the electronic currency 10. Alternatively, an entity receiving the electronic currency 10 may add a code indicating the goods or services to the electronic currency 10.

[0201] The code indicating the product or service is not limited to the ISIC described above, and any code system can be used. An internationally standardized code system or a code system applied in a specific country can be used.

[0202] By analyzing information that combines a transaction ID and a code indicating the product or service (i.e., the intended use), it is possible to infer the possibility of money laundering, etc. Furthermore, it is also possible to infer the possibility of terrorism, etc., based on the code indicating the product or service.

[0203] Furthermore, the central bank 3 (or an institution entrusted by the central bank 3) may analyze the status of products and services based on the registered contents of the ledger 8 and periodically output reports. Such reports provide useful information for analyzing economic conditions and trends.

[0204] Furthermore, the central bank 3 (or an institution entrusted by the central bank 3), or an institution in charge of tax assessment and collection, may levy taxes (e.g., value-added tax, commodity tax, consumption tax, etc.) on payments for goods and services based on the ledger 8. The electronic currency platform according to this embodiment can manage entities that are payers and recipients of goods and services, and therefore can calculate the amount of tax each entity must pay. Furthermore, the central bank 3 or an institution in charge of tax assessment and collection may collect the calculated amount of tax each time or for each institution. Tax collection may be carried out by debiting each entity's deposit account, or by requesting each entity to pay the calculated amount of electronic currency.

[0205] In this way, the electronic currency infrastructure according to this embodiment can at least support various administrative procedures and processes performed by government agencies.

[0206] <I. Advantages> According to the electronic currency infrastructure 1 according to this embodiment, at least some entities can determine whether or not there has been an unauthorized transfer of electronic currency 10, based at least on the contents recorded in the ledger 8. Unlike virtual currency, the presence or absence of an unauthorized transfer of electronic currency 10 can be determined by referring to the ledger 8 at any time, so resources such as a network are not significantly consumed. On the other hand, because it is possible to reliably determine whether or not there has been an unauthorized transfer of electronic currency 10, safe currency circulation can be achieved.

[0207] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above description, and is intended to include all modifications within the meaning and scope of the claims.

[0208] 1 Electronic Currency Infrastructure, 2 Issuing Authority, 3 Central Bank, 4 Financial Institution, 5 Merchant, 6, 6A, 6B Consumer, 8 Ledger, 10, 11, 12, 13, 14, 15, 16 Electronic Currency, 22, 23, 24, 116, 216 Key Pair, 22A, 23A, 24A, 25A, 26A, 26AA, 26AB Private Key, 22B, 23B, 24B, 25B Public Key, 31, 32, 33, 34, 48, 48A, 48B Checkpoint Data, 40 Document Route Control Section, 41 Initial Data, 42 Trust Control Section, 43 Trust Certification Section, 44 Transaction Control Section, 45 Transaction Data, 46 Special Section, 47 Revocation Management Section, 51 Local Issuing Authority, 52 Department of State, 53 Department of the Treasury, 54 Notary Public, 55 Government agency, 60 Networked zone, 62 Non-networked zone, 100 Information processing device, 102, 202 Processor, 104, 204 Memory, 106, 206 Input unit, 108, 208 Display unit, 110, 210 Storage, 112, 212 OS, 114, 214 Application program, 120 Network interface, 200 Mobile device, 220 Camera, 222 Speaker, 224 Wireless communication unit, 226 Near-field communication unit, 431 Validity period start time, 432 Validity period end time, 433 Role code, 434 Issuer public key, 435, 455 Entity public key, 436, 484 Signature data, 451 Offer entry, 452 Accept entry, 453 Type, 454 Transaction ID, 481 Processing time, 482 Random nonce, 483 signer public key.

Claims

1. A method executed by a computer for realizing an electronic currency infrastructure, the method comprising: generating an electronic file assigned a predetermined property value; adding first signature data generated using a private key of a central bank to the electronic file; after adding the first signature data, adding second signature data generated using a private key of the first entity to the electronic file for transferring the electronic file from the first entity to a second entity; recording at least a part of the content of the electronic file in a ledger; and determining whether there is an unauthorized transfer of the electronic file based at least on the content recorded in the ledger.

2. The method according to claim 1, wherein the step of determining whether there is an unauthorized transfer of the electronic file includes determining whether there is a record of transferring the electronic file from the first entity to a plurality of entities respectively, in association with the electronic file.

3. The method according to claim 1 or 2, further comprising, after transmitting the electronic file from the first entity to the second entity, deleting the electronic file stored by the first entity when receiving the electronic file with third signature data generated using a private key of the second entity added thereto.

4. The method according to any one of claims 1 to 3, further comprising the second entity verifying the second signature data included in the electronic file using a public key of the first entity.

5. The electronic file includes setting of an expiration date, and the method according to any one of claims 1 to 4 further comprises, before transferring the electronic file from the first entity to the second entity, at least one of the first entity and the second entity verifying that the expiration date of the electronic file has not expired.

6. The method according to any one of claims 1 to 5, further comprising, after the second entity receives the electronic file from the first entity, comparing the content of the electronic file with the content recorded in the ledger.

7. The method according to any one of claims 1 to 6, further comprising the step of the central bank retrieving the electronic file if the electronic file has expired.

8. A system for realizing an electronic currency infrastructure, comprising: means for generating an electronic file assigned a predetermined financial value; means for adding first signature data generated using a private key of a central bank to the electronic file; means for adding second signature data generated using the private key of the first entity to the electronic file after the first signature data has been added, in order to transfer the electronic file from a first entity to a second entity; a ledger for recording at least a portion of the contents of the electronic file; and means for determining whether or not the electronic file has been transferred fraudulently, based at least on the contents recorded in the ledger.

Images