Method and system for implementing electronic currency infrastructure - Patents.com

Abstract

A computer-implemented method for realizing an electronic currency infrastructure includes generating an electronic file having a predetermined financial value assigned thereto; appending first signature data generated using a private key of a central bank to the electronic file; after the first signature data has been appended, appending second signature data generated using the private key of the first entity to the electronic file 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 on at least the contents recorded in the ledger.

Description

[Technical field]

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

[0002] In addition to transactions using real money, transactions using various virtual currencies are also being conducted. One example of such a virtual currency is known as Bitcoin. For example, Japanese Patent Publication 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. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent No. 5871347 Summary of the Invention [Problem to be solved by the invention]

[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 cryptocurrency cannot be exchanged directly.

[0005] The present disclosure provides an electronic currency infrastructure that can achieve safe currency circulation without significant consumption of resources such as networks. [Means for solving the problem]

[0006] According to an embodiment of the present disclosure, a computer-implemented method for implementing an electronic currency infrastructure is provided, the method including the steps of: generating an electronic file with a predetermined financial value attached thereto, appending first signature data generated using a private key of a central bank to the electronic file, appending second signature data generated using a private key of the first entity to the electronic file after the first signature data has been appended, 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 upon receiving 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 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 recalling 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 with a predetermined property value assigned thereto; 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 part of the contents of the electronic file; and means for determining whether or not the electronic file has been transferred illegally based on at least the contents recorded in the ledger. Effect of the Invention

[0014] According to the present disclosure, safe currency circulation can be achieved without significant consumption of resources such as networks. [Brief description of the drawings]

[0015] [Figure 1] FIG. 2 is a schematic diagram showing a configuration example of an electronic currency infrastructure according to the present embodiment. [Diagram 2] 1 is a schematic diagram showing an example of a hardware configuration of an information processing device used in an electronic currency platform according to an embodiment of the present invention; [Diagram 3] 2 is a schematic diagram showing an example of the hardware configuration of a mobile device used in the electronic currency platform according to the present embodiment. FIG. [Figure 4] 1 is a diagram for explaining an example of the circulation of electronic currency in an electronic currency platform according to an embodiment of the present invention. FIG. [Diagram 5] 2 is a schematic diagram showing an example of a data structure of electronic currency according to the present embodiment. FIG. [Figure 6] 1 is a schematic diagram showing an example of a chain of trust in an electronic currency infrastructure according to an embodiment of the present invention; [Figure 7] 2 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. [Figure 8] 2 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. [Figure 9] 10 is a schematic diagram showing an example of the data structure of checkpoint data of a special section of electronic currency according to the present embodiment. FIG. [Figure 10] 1 is a schematic diagram showing an example of a data structure of an electronic currency-based ledger according to the present embodiment; FIG. [Figure 11] 1 is a diagram for explaining an example of a basic processing procedure for transferring electronic currency between entities in an electronic currency infrastructure according to an embodiment of the present invention. [Figure 12] FIG. 13 is a diagram for explaining an example of a basic processing procedure for transferring electronic currency including planning in the electronic currency infrastructure according to the present embodiment. [Figure 13] 11 is a sequence diagram showing a processing procedure for circulating electronic currency in the electronic currency platform according to the present embodiment. FIG. [Figure 14] FIG. 11 is a sequence diagram showing another processing procedure for circulating electronic currency in the electronic currency infrastructure according to the present embodiment. [Figure 15] 13 is a flowchart showing an example of a processing procedure in an electronic currency-based ledger according to the present embodiment. [Figure 16] 11 is a diagram for explaining an example of verification of consistency in a ledger based on electronic currency according to the present embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Embodiments according to the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals and their description will not be repeated.

[0017] <A. Terms> In this specification, "currency" includes electronic money having the same value as legal tender (currency) whose legal tender power is recognized by a country, in addition to legal tender. Also, "currency" may include property value referred to as virtual currency or cryptocurrency.

[0018] <B. Overview> The present disclosure includes a method and a system executed by a computer for realizing an electronic currency infrastructure. First, an overview of the electronic currency infrastructure 1 according to the present embodiment will be described. In the electronic currency infrastructure 1, electronic currency 10 having the same property value as physical currency such as banknotes and coins circulates. The electronic currency 10 can also be referred to as digital currency. Each of the electronic currencies 10 may be one electronic file.

[0019] In the electronic currency infrastructure 1, the electronic currency 10 is in a unit of currency recognized by the central bank, and its authenticity and reliability of circulation are guaranteed by an electronic signature. The property value given to each of the electronic currencies 10 may be any of a predetermined denomination, similar to physical currency, or there may be more types of denominations than physical currency.

[0020] FIG. 1 is a schematic diagram showing a configuration example of the electronic currency infrastructure 1 according to the present 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 an entity (subject) that guarantees the authenticity of the 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 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 bureau or a mint in comparison with the infrastructure through which physical currency circulates.

[0023] The central bank 3 provides electronic currency 10 to the market, collects electronic currency 10 from the market, and manages the total amount of electronic currency 10 circulating in the market. 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 via, for example, one or more financial institutions 4 (step S2).

[0024] In this way, the central bank 3 (its computer) adds 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 configuration example shown in Fig. 1, the issuing authority 2 generates electronic currency 10 (electronic file) to which a predetermined financial value has been assigned. The generation of the electronic currency 10 (electronic file) is not limited to (its computer) of the issuing authority 2, but may also be (its computer) of the central bank 3, or (its 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 / her deposit 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 transaction data described below, the financial institution 4 adds information for verifying the transfer of the electronic currency 10 (hereinafter also referred to as "checkpoint data") 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 electronic currency 10 serves as evidence that completely guarantees the distribution route of electronic currency 10 up to that point. For this reason, signature data of the entity handling electronic currency 10 is added to the checkpoint data. The signature data included in checkpoint data 31 ensures non-repudiation of the transfer of 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 / 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 accepts the notified amount, the consumer 6 adds checkpoint data 32, in addition to the transaction data, to the electronic currency 13 having a financial value of the accepted amount.

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

[0032] The financial value of the 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 transmit multiple amounts of electronic currency 10 to the seller 5 in one transaction so that the amount of the necessary consideration is reached, just as when paying with physical currency. Alternatively, the seller 5 may transmit 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 he owns into cash or deposit the financial value of the electronic currency 10 he owns into his 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 their electronic currency 10 into cash or deposit the financial value of their electronic currency 10 into their own savings account.

[0037] In this way, after the central bank 3 adds signature data (first signature data) generated by the central bank 3 using the private key 23A of the central bank 3 to the electronic currency 10, each of the financial institution 4 (its computer), the seller 5 (its computer), and the consumer 6 (its computer) adds signature data (second signature data) generated by the central bank 3 using the private key 23A of the central bank 3 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. Electronic currency 10 that has expired 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 the distribution of electronic currency 10, etc. For example, the length of the expiration date may be set to about six months from the date of issue 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 validity period of the electronic currency 10 has expired, when there is a shortage of space for recording the checkpoint data of the electronic currency 10, etc.

[0040] When the electronic currency 10 is no longer able to circulate in the market, the central bank 3 collects the electronic currency 10. In this way, when the validity period of the electronic currency 10 has expired, the central bank 3 collects the electronic currency 10.

[0041] A financial institution 4 can deposit the financial value of the electronic currency 10 it owns into its own deposit account at the central bank 3 at any time. For example, when the central bank 3 approves the deposit, the financial institution 4 adds 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 of 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 in sequence, 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] Additionally, the financial institution 4 may provide 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 merchants 5. The ledger 8 may be managed by the issuing authorities 2 and / or the central bank 3.

[0046] FIG. 1 illustrates one ledger 8, but a distributed ledger composed of a plurality of servers may be adopted. Also, a master ledger 8 may be prepared, and one or more ledgers 8 serving as clones or slaves may be prepared.

[0047] Each of the one or more issuing offices 2, the central bank 3, the one or more financial institutions 4, and the one or more sellers 5 stores information indicating the details of the transaction in the ledger 8 when receiving the electronic currency 10 from another entity and when providing the electronic currency 10 to another entity. The ledger 8 records at least a part of the content of the electronic currency 10 (electronic file). Note that not all sellers 5 may be able to access the ledger 8 via the network.

[0048] To simplify the explanation, in FIG. 1, regarding the transfer of the electronic currency 10 from the issuing office 2 to the central bank 3 and the transfer of the electronic currency 10 from the central bank 3 to the financial institution 4, checkpoint data is not added to the electronic currency 10, but when the electronic currency 10 is transferred between entities, checkpoint data may be added to the electronic currency 10.

[0049] At least some entities of the electronic currency infrastructure 1 can determine the presence or absence of an illegal transfer of the electronic currency 10 (electronic file) based on at least the content recorded in the ledger 8. Different from virtual currency, by referring to the ledger 8 at any timing, the presence or absence of an illegal transfer of the electronic currency 10 can be determined, so resources such as the network are not consumed significantly. On the other hand, since an illegal transfer of the electronic currency 10 can be surely detected, safe currency circulation can be realized.

[0050] <C. Hardware Configuration Example> Next, a hardware configuration example used in the electronic currency infrastructure 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 platform 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, the ledger 8, and the like.

[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, with a central processing unit (CPU). 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 a processing circuitry.

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

[0056] As used herein, the term "memory" encompasses memory and storage. Various programs and various data are stored in the storage 110. The processor 102 reads out designated portions or computer-readable instructions from the programs stored in the storage 110, expands them on the memory 104, and executes them sequentially to realize various processes as described below.

[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 platform 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 for the information processing device 100. The input unit 106 may be, for example, a keyboard, a mouse, a touch panel arranged in correspondence with the display unit 108, or a switch arranged at any position 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 by the processor 102. The display unit 108 may be, for example, a Liquid Crystal Display (LCD) 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 port, a Universal Serial Bus (USB) port, a serial port such as IEEE1394, 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 the present embodiment. The mobile device 200 shown in FIG. 3 is used to execute information processing in each of, for example, a merchant 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] A camera 220 is provided on the housing of the mobile device 200 and captures still 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 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 a non-transitory medium on which the computer-readable instructions and / or data are stored. The medium may be, for example, an optical medium such as a Digital Versatile Disc (DVD) or a semiconductor medium 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] It should be noted that any computing resource can be used to realize the processes required for the electronic currency infrastructure 1. The computing resources are not limited to the hardware configuration examples shown in Figs. 2 and 3, and any hardware can be used.

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

[0072] Furthermore, the term "entity" may include a computer whose decision is made by AI (Artificial Intelligence).

[0073] Many of the processes described below are started and executed according to the will determined by an individual, a corporation, or AI. However, the process of handling the electronic currency 10 itself is realized by a computer.

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

[0075] FIG. 4 is a diagram for explaining an example of the circulation of the electronic currency 10 in the electronic currency infrastructure 1 according to the present embodiment. In FIG. 4, the range accessible to the network in the ledger 8 is referred to as the networked zone 60, and the range inaccessible to the network in the ledger 8 is referred to as the non-network zone 62.

[0076] Entities existing in the networked zone 60 can record the content of the electronic currency 10 in the ledger 8 and can also refer to the content of the electronic currency recorded in the ledger 8. Therefore, along with the circulation of the electronic currency 10, a history including checkpoint data is added to the electronic currency 10 itself, and the content of the checkpoint data of the electronic currency 10 is sequentially reflected in the ledger 8 as well.

[0077] On the other hand, since entities existing in the non-network zone 62 cannot access the network in the ledger 8, the circulation of the electronic currency 10 is based on the trust inferred between other users or entities held by other users. Therefore, the history including the checkpoint data of the electronic currency 10 is added only to the electronic currency 10 itself. However, the content of the electronic currency 10 can be reflected in the ledger 8 at any timing.

[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 required for the electronic currency 10, and generates an electronic file including 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 part 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 a file name for 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 reflects the information of the received electronic currency 10 in the ledger 8 (step S54). In this manner, the financial institution 4 records at least a part 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 private key 24A of financial institution 4 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 private key 24A of financial institution 4 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 the information on the electronic currency 10 transferred to the consumer 6A (step S56). In this manner, 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. It is assumed that seller 5 is 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 details of the electronic currency 10 offered by the consumer 6B in the ledger 8 (step S59). In this manner, the seller 5 records at least a part of the details 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). In this way, after the seller 5 (second entity) receives the electronic currency 10 (electronic file) from the consumer 6B (first entity), the seller 5 compares the contents of the electronic currency 10 with the contents recorded in the ledger 8. At this time, 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 of 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 on at least the contents recorded in the ledger 8.

[0089] If there is no problem with consistency with the information recorded in the ledger 8, the seller 5 responds to consumer 6B that it accepts consumer 6B's offer (step S61). Consumer 6B deletes the electronic currency 10 held by consumer 6B. 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 the seller 5 (second entity). The transfer of electronic currency 10 from consumer 6B to seller 5 completes the payment using electronic currency 10.

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

[0091] In addition, even when the seller 5 exchanges the electronic currency 10 for cash, the same process is executed. In the case of exchange, the financial institution 4 delivers to the seller 5 the cash corresponding to the amount of the electronic currency 10 received from the seller 5.

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

[0093] After that, the financial institution 4 returns the electronic currency 10 received from the seller 5 to the central bank 3. Specifically, the financial institution 4 adds the 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 deposit account of the financial institution 4 held at the central bank 3 according to the amount of the electronic currency 10 received from the financial institution 4. Alternatively, the central bank 3 may deliver new electronic currency 10 to the financial institution 4 according to the amount of the electronic currency 10 received from the financial institution 4.

[0094] Finally, when a predetermined condition is satisfied, the central bank 3 discards the electronic currency 10 collected from the financial institution 4 (step S64). The discarding of the electronic currency 10 may be the deletion of the electronic file itself or the management so as not to allow the electronic currency 10 to be re-circulated.

[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] FIG. 5 is a schematic diagram showing an example of the data structure of the electronic currency 10 according to the present embodiment. Referring to FIG. 5, the 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 for each section may include, as header information, a section type indicating the type of the section, a section flag indicating the state of the section, and a section length indicating the length of the section.

[0097] (e1:Document Root Control Section 40) The document route control section 40 of the electronic currency 10 generated by the issuing authority 2 may contain initial data 41 including settings such as: (a) Creation Time (e.g., TAI64N format) (b) Spent at Time (e.g., TAI64N format) (c) Currency code (3 bytes according to ISO 4217, for example USD or JPY) (d) Currency Denomination (e.g., a nonzero unsigned integer) (e) Sequential Identifier (e.g., 13 bytes) (f) Decimal Place (number of digits indicating the decimal point position or the 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 (e.g., a hash string calculated from a specific keyword) (j) The serial number of the electronic currency 10 (e.g., the hash value of the initial data (1) to (9)) (e2: Trust Control Section 42) The trust control section 42 includes a trust authorization section (TAS) 43. 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 the present 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 utilize 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 signer may be supported by signatures of intermediate institutions (eg, local issuing authorities, departments of state and treasury, notaries, etc.) that extend trust to the central bank 3.

[0100] FIG. 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. A second intermediate entity (INTERMEDIATE L1) is connected to the first intermediate entity. The second intermediate entity may include, for example, a financial institution 4 and a notary public 54. A user is connected to the second intermediate entity. The user may include, for example, an ATM 56, a merchant 5, a consumer 6, and a government agency 55.

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

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

[0103] The validity period start time 431 has 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 older 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 newer than the validity period start time 431, it is 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 acting as the first intermediate entity is trusted towards the central bank 3 acting as the root.

[0106] The issuer public key 434 is the public key of the central bank 3 which acts as the root. Entity public key 435 is the public key of the entity demonstrating trust, which may be an entity belonging to 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 authentication 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) by using a private key that pairs with the entity public key 435. That is, the signature data 436 is generated by inputting the information included in the trust authentication section 43 (excluding the signature data 436) into a hash function to calculate a hash value, and encrypting the hash value by using the private key that pairs with the entity public key 435.

[0108] A third party can check and verify the trust chain 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 trust chain shown in Fig. 6. It is preferable to generate the trust authentication section 43 for all links constituting the trust chain shown in Fig. 6, but the trust authentication section 43 may be generated only for some of the links.

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

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

[0111] Fig. 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] Offer entry 451 includes type 453 of “Offer”, a transaction ID 454, and an entity public key 455. Accept entry 452 includes 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 an entity receiving electronic currency 10 when accepting an offer to transfer electronic currency 10. Thus, entity public key 455 is 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 put into further circulation and is only permitted to be returned to the central bank 3.

[0119] Checkpoint data is stored sequentially in checkpoint data 48. The 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 the checkpoint data 48 is discarded if the following requirements are not met. (1) The signer's public key is registered in Transaction Control Section 44. (2) The processing time 481 of the newly generated checkpoint data 48 is newer than the processing time 481 of the previously generated checkpoint data 48. (3) The processing time 481 of the newly generated checkpoint data 48 does not exceed the validity period end time 432. (4) The processing time 481 of the 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 receives 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 the present embodiment. With reference 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 was generated. The random nonce 482 is used in combination with the processing time 481 to increase security strength.

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

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

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

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

[0127] For example, the file name of the electronic currency 10 with a face value of 10,000 Japanese yen can be set to "JPY-10000-5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.snote". Also, the file name of the electronic currency 10 with a face value of 100.00 US dollars can be set to "USD-10000-48ae15fd45c3ae607e41a72d153d6c051f267c42f5ea11f26e1b33b183eaf0e8.snote". At this time, since the minimum unit of the US dollar is cents, 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 this embodiment will be described.

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

[0130] The ledger 8 records the content of the document root control section 40, the trust control section 42, the transaction control section 44, and the special section 46 included in each of the electronic currencies 10.

[0131] An entity arranged in the networked zone 60 records the content of the received electronic currency 10 in the ledger 8 triggered by receiving the electronic currency 10 from another entity.

[0132] Ledger 8 may include an engine for verifying the value (the judgment result as to whether or not the expiration date of the electronic currency 10 has expired) stored in the invalid management section 47 included in the special section 46 of the electronic currency 10, 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 the verification process at the timing when new data is written to the ledger 8.

[0133] An example of the process for verifying the integrity of the checkpoint data 48 will be described later. <G. Processing Procedure> Next, an example of the processing procedure in the electronic currency infrastructure 1 according to the present embodiment will be described.

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

[0135] FIG. 11 is a diagram for explaining an example of the basic processing procedure of the transfer of the electronic currency 10 between entities in the electronic currency infrastructure 1 according to the present embodiment. FIG. 11 shows an example in which the ownership of the 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] Referring to FIG. 11, the source entity adds an Offer entry 451 (transaction data 45) to the electronic currency 10 to be transferred to the target entity, and adds checkpoint data 48A including signature data generated using the private key of the source entity (step S10). The source entity transmits the electronic currency 10 to which the Offer entry 451 and the checkpoint data 48A are 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 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] Through the above process, the transfer of electronic currency 10 from the source entity to the target entity is completed.

[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. In other words, an exchange including change may be required between the entities. In such cases, a process is executed between the entities to adjust in advance what combination of electronic currency 10 will be used to complete the transaction. Such an adjustment process is also referred to as "planning" hereinafter. In the planning process, multiple electronic currencies 10 to be transferred between the entities are determined. In addition, since the transfer of multiple electronic currencies 10 must be completed, a transaction ID is generated to manage the series of transfers.

[0142] Fig. 12 is a diagram for explaining an example of a basic processing procedure for the transfer of electronic currency 10, including planning, in the electronic currency platform 1 according to this embodiment. With reference 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 transaction data 45 (FIG. 8) added to each of electronic currencies 10-1, 10-6, and 10-7.

[0147] Associating multiple electronic currency 10 transfers with a common transaction ID ensures that transfers of electronic currency 10 are 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 electronic currencies 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 electronic currencies 10, and then it can be evaluated 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] In the planning, it is also verified that the electronic currency 10 to be targeted has not expired. Electronic currency 10 that has expired is excluded from the planning target. In other words, 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. Such verification makes it possible to prevent electronic currency 10 that cannot be circulated in the market from being selected as the target for transfer.

[0151] (g2: Circulation of electronic currency 10 in networked zone 60) Next, the circulation of electronic currency 10 provided to the public by the central bank 3 will be described.

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

[0153] Typically, Entity 1 is a source entity and Entity 2 is a target entity. In the example process shown in FIG.

[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 a 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 transmits the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added to Entity 2 (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 the public key of entity 1 (sequence SQ110). If the signature data verification passes, entity 2 transmits the contents of the received one or more electronic currencies 10 to the ledger 8 (sequence SQ112). After receiving electronic currency 10 (electronic file) from entity 1, entity 2 compares the contents of electronic currency 10 with the contents recorded in the ledger 8.

[0158] When entity 2 receives a notification from ledger 8 indicating that there is a problem with the consistency of the content of one or more pieces of electronic currency 10 that it has 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 problem with the consistency of the contents of the transmitted one or more electronic currencies 10 (NO in sequence SQ114), entity 2 adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ118). Entity 2 transmits to entity 1 the one or more electronic currencies 10 with the Accept entry 452 and checkpoint data 48 added (sequence SQ120).

[0160] If it is necessary to transfer one or more electronic currencies 10 as change from entity 2 to entity 1, 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 transmits 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 the public key of entity 2 (sequence SQ126). If there is no problem with the verification of the signature data, entity 1 transmits the contents of the received one or more electronic currencies 10 to the ledger 8 (sequence SQ128). After receiving the electronic currency 10 (electronic file) from entity 2, entity 1 compares the contents of the electronic currency 10 with the contents recorded in the ledger 8.

[0163] When entity 1 receives a notification from ledger 8 that there is a problem with the consistency of the content of one or more pieces of electronic currency 10 that it has 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 contents of the transmitted one or more electronic currencies 10 (NO in sequence SQ130), entity 1 adds an Accept entry 452 and checkpoint data 48 to each of the received one or more electronic currencies 10 (sequence SQ134). Entity 1 transmits to entity 2 the one or more electronic currencies 10 with the Accept entry 452 and checkpoint data 48 added (sequence SQ136).

[0165] If entity 1 receives a file with Accept entries 452 and checkpoint data 48 added for all of the electronic currencies 10 to be transferred that were determined in the planning (YES in sequence SQ138), it sends the contents of the electronic currencies 10 to be transferred to the ledger 8 (sequence SQ140) and deletes the 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 electronic currencies 10 to be transferred that were determined in the planning (YES in sequence SQ144), it sends the contents of the electronic currencies 10 to be transferred to the ledger 8 (sequence SQ146) and deletes the 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 public 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 the present embodiment. FIG. 14 shows an example of a process for transferring financial value from entity 1 to entity 2.

[0170] Typically, entity 1 is a source entity and entity 2 is a target entity. In the processing example shown in FIG.

[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 a 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 transmits the one or more pieces of electronic currency 10 with the Offer entry 451 and checkpoint data 48 added to Entity 2 (sequence SQ208).

[0174] Entity 2 verifies the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 using the public key of entity 1 (sequence SQ210). If the verification of the signature data is satisfactory, 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 transmits the one or more electronic currencies 10 with the Accept entry 452 and checkpoint data 48 added to entity 1 (sequence SQ214).

[0175] If one or more electronic currencies 10 need to be transferred as change from entity 2 to entity 1, 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 electronic currencies 10 to be transferred to Entity 1 (sequence SQ216). Entity 1 transmits the one or more electronic currencies 10 with the Offer entry 451 and checkpoint data 48 added to Entity 1 (sequence SQ218).

[0177] Entity 1 verifies the signature data included in the checkpoint data 48 of the received one or more electronic currencies 10 using the public key of entity 2 (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 transmits the one or more electronic currencies 10 with the Accept entry 452 and checkpoint data 48 added to entity 2 (sequence SQ224).

[0178] If entity 1 has received a file with Accept entries 452 and checkpoint data 48 added for all of the electronic currency 10 or currency items 10 to be transferred as determined in the planning (YES in sequence SQ226), entity 1 deletes the electronic currency 10 or currency items 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 electronic currency 10 or currency items 10 to be transferred as determined in the planning (YES in sequence SQ230), entity 2 deletes the electronic currency 10 or currency items 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 the ledger 8 of the electronic currency infrastructure 1 according to the present embodiment.

[0182] 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 to refer to the ledger 8 ("reference" in step S102), the ledger 8 responds with the registration contents corresponding to the electronic currency 10 specified by the sequence 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 registration contents corresponding to electronic currency 10 specified by the sequence 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), ledger 8 registers the requested data in association with the specified electronic currency 10 (step S110). Then, the processing from step S100 onwards is repeated.

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

[0187] Referring to FIG. 16(A), 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 the electronic currency 10.

[0189] When checkpoint data 48 is sorted based on processing time 481, signer public key 483 in checkpoint data 48-1 and signer public key 483 in checkpoint data 48-2 become identical. The occurrence of a duplicate transfer of electronic currency 10 can be detected based on the value of such signer public key 483. Furthermore, the owner of the identical public key can be identified as the person who made the duplicate transfer.

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

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

[0192] (g5: Expiration 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] The new electronic currency 10 may be issued at the timing of receiving the electronic currency 10 with an expired expiration date, or may be issued independently of such timing. For example, when receiving the electronic currency 10 with an expired expiration date, among the previously issued electronic currencies 10 (with a sufficient remaining expiration date), an electronic currency 10 with the corresponding amount may be selected and provided.

[0194] Note that the amount of the newly provided electronic currency 10 does not have to be the same as the amount of the electronic currency 10 with an expired expiration date. For example, some tax may be deducted in advance. In this case, the amount of the newly provided electronic currency 10 is the amount obtained by deducting a predetermined tax amount from the amount of the electronic currency 10 with an expired expiration date. Alternatively, it may reflect inflation, interest rates, etc. In this case, the amount of the newly provided electronic currency 10 is larger than the amount of the electronic currency 10 with an expired expiration date.

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

[0196] <H. Use of checkpoint data in the electronic currency infrastructure 1> In the electronic currency infrastructure 1 according to the present embodiment, the circulation of each electronic currency 10 can be completely traced. Therefore, for example, criminal acts or illegal acts such as money laundering can be prevented.

[0197] Also, by statistically processing the circulation of the electronic currency 10, it is also possible to estimate the state of economic activities in the market, etc. Furthermore, by anonymizing the entities involved in the circulation of the electronic currency 10 and generating statistical information, economic indicators, etc. can also be calculated. Also, the anonymized statistical information can be provided有偿 or free of charge.

[0198] In this way, in the electronic currency infrastructure 1 according to the present embodiment, different from conventional currency, the circulation of the electronic currency 10 can be completely traced, so economic analysis, etc. can be performed with higher accuracy.

[0199] For example, the central bank 3 may constantly monitor the ledger 8, and if an unauthorized transfer of electronic currency 10 is detected, the central bank 3 may immediately report the unauthorized transfer to a law enforcement agency (such as the police). The central bank 3 (or an institution entrusted by the central bank 3) may also generate and provide evidence for court cases (criminal and / or civil cases) based on the entries in the ledger 8.

[0200] Also, in order to prevent money laundering, information indicating the purpose of transfer, etc. 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 a user pays the electronic currency 10 as payment for the purchase of goods and services, the user may add a code indicating the goods or services to the electronic currency 10. Alternatively, the 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, 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 the combined information of the transaction ID and the code indicating the product or service (i.e., the purpose of use), it is possible to infer the possibility of money laundering, etc. Also, based on the code indicating the product or service, it is possible to infer the possibility of terrorism, etc.

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

[0204] In addition, the central bank 3 (or an institution commissioned by the central bank 3), or the institution responsible for the levy and collection of taxes, may levy taxes (such as value-added tax, excise tax, consumption tax, etc.) on the payment of consideration for goods and services based on the ledger 8. In the electronic currency infrastructure according to this embodiment, since the entities of the payer and payee of the consideration for goods and services can be managed, the amount of tax that each entity should pay can be calculated. Further, the central bank 3 or the institution responsible for levy and collection may collect the calculated amount of tax each time or for each institution. The collection of taxes may be carried out by debiting from the deposit account of each entity, or may be carried out in the form of requesting payment of the calculated amount of electronic currency to each entity.

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

[0206] <I. Advantages> According to the electronic currency infrastructure 1 according to this embodiment, at least some entities can determine the presence or absence of an illegal transfer of the electronic currency 10 based on at least the content recorded in the ledger 8. Different from virtual currency, by referring to the ledger 8 at any timing, the presence or absence of an illegal transfer of the electronic currency 10 can be determined, so that resources such as a network are not greatly consumed. On the other hand, since the presence or absence of an illegal transfer of the electronic currency 10 can be surely determined, safe currency circulation can be realized.

[0207] The embodiments disclosed this time should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Explanation of Reference Numerals

[0208] 1 Electronic Currency Infrastructure, 2 Issuing Authority, 3 Central Bank, 4 Financial Institution, 5 Merchant, 6, 6A, 6B Consumer, 8 Ledgers, 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 Root 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 section, 108, 208 display section, 110, 210 storage, 112, 212 OS, 114, 214 application program, 120 network interface, 200 mobile device, 220 camera, 222 speaker, 224 wireless communication section, 226 short-range communication section, 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. 1. A computer-implemented method for implementing an electronic currency infrastructure, comprising: generating an electronic file having a predetermined proprietary value attached thereto; adding a first signature data generated using a private key of a central bank to the electronic file; After the first signature data has been added, adding second signature data to the electronic file, the second signature data being generated using a private key of the first entity, 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 the electronic file has been fraudulently transferred based at least on the contents recorded in the ledger.

2. 2. The method of claim 1, wherein determining whether the electronic file has been transferred fraudulently includes determining whether there are records associated with the electronic file of transfers of the electronic file from the first entity to multiple entities, respectively.

3. 2. The method of claim 1, further comprising the 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.

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

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

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

7. The method according to any one of claims 1 to 3, 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, means for generating an electronic file having a predetermined property value attached thereto; 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 to the electronic file, the second signature data being generated using a private key of the first entity, in order to transfer the electronic file from the first entity to a second entity after the first signature data has been added; 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 fraudulently transferred based on at least the contents recorded in the ledger.

9. The system described in Claim 8, wherein the means for determining whether the electronic file has been transferred fraudulently determines whether there are records associated with the electronic file of the electronic file being transferred from the first entity to multiple entities.

10. The system described in claim 8, further comprising means for deleting the electronic file stored by the first entity when, after sending the electronic file from the first entity to the second entity, the first entity receives the electronic file from the second entity to which third signature data generated using the second entity's private key has been added.

11. A system described in any one of claims 8 to 10, further comprising means for the second entity to verify the second signature data contained in the electronic file using the public key of the first entity.

12. The electronic file includes an expiration date setting, The system of any one of claims 8 to 10, further comprising means for at least one of the first entity and the second entity to verify that the electronic file has not expired before transferring the electronic file from the first entity to the second entity.

13. A system described in any one of claims 8 to 10, further comprising means for comparing the contents of the electronic file with the contents recorded in the ledger, which is executed after the second entity receives the electronic file from the first entity.

14. A system as described in any one of claims 8 to 10, further comprising means for the central bank to retrieve the electronic file if the electronic file has expired.

Images