Distributed ledger cooperation method, distributed ledger cooperation system, terminal, and monitoring terminal

Abstract

Provided is a distributed ledger cooperation method in which: a distributed ledger cooperation system that includes two or more distributed ledger systems (the distributed ledger systems each including one or more terminals) registers a log of events between two or more users; and the terminals each execute a step for registering a log of the event including a prescribed key in a distributed ledger of a distributed ledger system in which the relevant terminal is included. The prescribed key includes: an event source identifier, which is an identifier for identifying a user who transmits data about the event; an event destination identifier, which is an identifier for identifying a user who receives the data about the event; and an event identifier, which is an identifier for identifying the event. The prescribed key includes either an event source identifier or an event destination identifier for identifying each of the two or more users.

Description

Distributed ledger linkage method, distributed ledger linkage system, terminal, monitoring terminal

[0001] The present invention relates to distributed ledger technology.

[0002] A distributed ledger is a database that is shared, replicated, and synchronized among users of a distributed network, and records the history of transactions (e.g., contracts) between users without the intervention of a specific third party. Here, a distributed network is a system in which there is no central server that manages the network, and users are connected to each other in an equal relationship (peer-to-peer relationship). By recording transaction history in a distributed ledger, the authenticity of the transaction is guaranteed. For example, Patent Document 1 discloses a technology for recording transaction history in a distributed ledger.

[0003] JP 2017-220710 A

[0004] Currently, there are multiple distributed ledgers for different purposes, and it is possible that users intending to conduct a transaction may not be using the same distributed ledger. Even in such cases, it is preferable to ensure the authenticity of a transaction by recording the transaction history in the distributed ledger currently used by the users involved in the transaction without the need for a specific third party. In addition, it is preferable to have a mechanism to detect fraudulent registration of transaction history by a party not involved in the transaction, and a mechanism to prevent fraudulent registration itself.

[0005] Therefore, the objective of the present invention is to provide distributed ledger technology that can record the history of transactions between users who do not use the same distributed ledger.

[0006] One aspect of the present invention is a distributed ledger linkage method in which a distributed ledger linkage system including two or more distributed ledger systems (wherein each distributed ledger system includes one or more terminals) registers a log of an event between two or more users, wherein the terminal executes a step of registering the event log including a predetermined key in the distributed ledger of the distributed ledger system in which the terminal is included, wherein the predetermined key includes an event source identifier which is an identifier for identifying a user sending data of the event, an event destination identifier which is an identifier for identifying a user receiving data of the event, and an event identifier which is an identifier for identifying the event, and the predetermined key includes either an event source identifier or an event destination identifier for identifying each of the two or more users.

[0007] According to the present invention, it is possible to record the history of transactions between users who do not use the same distributed ledger.

[0008] FIG. 1 is a diagram showing an example of an event log. FIG. 1 is a block diagram showing the configuration of distributed ledger federation system 10. FIG. 2 is a block diagram showing the configuration of terminal 100. FIG. 3 is a block diagram showing the configuration of monitoring terminal 200. FIG. 4 is a sequence diagram showing the operation of distributed ledger federation system 10. FIG. 5 is a sequence diagram showing the operation of distributed ledger federation system 10. FIG. 6 is a sequence diagram showing the operation of distributed ledger federation system 10. FIG. 7 is a diagram showing an example of the functional configuration of a computer that realizes each device in an embodiment of the present invention.

[0009] Hereinafter, an embodiment of the present invention will be described in detail. Note that components having the same functions are given the same numbers and redundant explanations will be omitted.

[0010] <Technical Background> In an embodiment of the present invention, a key having a predetermined format is used when registering a transaction history in a distributed ledger, and the history of one transaction is registered using one key that is common among the users who are parties to the transaction.

[0011] Hereafter, a system for operating a single distributed ledger will be referred to as a distributed ledger system. Users of a distributed ledger system have an equal relationship with each other, and the system is operated by sharing, replicating, and synchronizing the distributed ledger among users of the distributed ledger system. Furthermore, a transaction between multiple parties, such as a contract, is called an event, and its history is called a log.

[0012] The problem addressed in an embodiment of the present invention will be formulated. Consider a transaction (event X) between user α of distributed ledger system A and user β of distributed ledger system B (different from distributed ledger system A). Assume that the data required for the transaction is sent and received between user α and user β as part of the transaction. Here, we assume that user α of distributed ledger system A sends data for event X to user β of distributed ledger system B, and that user α registers a log of event X, LogA_X, in the distributed ledger of distributed ledger system A, and user β registers a log of event X, LogB_X, in the distributed ledger of distributed ledger system B.

[0013] In this case, the following mechanism must be implemented:

[0014] (1) User α can register the log of event X, LogA_X, in the distributed ledger of distributed ledger system A, and user β can register the log of event X, LogB_X, in the distributed ledger of distributed ledger system B. In this case, it is necessary to be able to confirm that the logs, LogA_X and LogB_X, relate to a single transaction.

[0015] (2) Prevent user γ of distributed ledger system C, who is not a party to the transaction, from registering the log of event X, LogC_X, in the distributed ledger of distributed ledger system C. Alternatively, if user γ registers the log of event X, LogC_X, in the distributed ledger of distributed ledger system C, make it possible to detect an unauthorized registration. Here, distributed ledger system C may be a distributed ledger system different from either distributed ledger system A or distributed ledger system B, or it may be either distributed ledger system A or distributed ledger system B.

[0016] To realize the mechanism of (1), it is necessary to be able to identify the log LogB_X from the log LogA_X, and conversely, it is also necessary to be able to identify the log LogA_X from the log LogB_X.

[0017] To realize the above mechanism, a key including an event source identifier, an event destination identifier, and an event identifier is adopted as the key used when registering transaction history in the distributed ledger.

[0018] Here, the event source identifier is an identifier for identifying the user who sends the event data, the event destination identifier is an identifier for identifying the user who receives the event data, and the event identifier is an identifier for identifying the event. For example, both the event source identifier and the event destination identifier can be a combination of an identifier indicating the distributed ledger system and an identifier indicating the user. Note that for an event to occur, the sum of the number of event sources and the number of event destinations must be 2 or greater. Therefore, the sum of the number of event source identifiers and the number of event destination identifiers included in the key must be 2 or greater. However, it is acceptable for either the number of event source identifiers or the number of event destination identifiers to be 0.

[0019] The event log then contains a key and information about the event to be logged.

[0020] An example will be used below. Let the identifier of distributed ledger system A be <distributed ledger system A ID>, the identifier of user α be <user α ID>, the identifier of distributed ledger system B be <distributed ledger system B ID>, the identifier of user β be <user β ID>, and the event identifier be <event ID>. Then, the event source identifier is <distributed ledger system A ID><user α ID>, the event destination identifier is <distributed ledger system B ID><user β ID>, and the key for registering the log of event X, LogA_X, in the distributed ledger of distributed ledger system A and the key for registering the log of event X, LogB_X, in the distributed ledger of distributed ledger system B are both <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>. Figure 1 shows an example of an event log. In addition to the key, the log of event X, LogA_X, and the log of event X, LogB_X, in Figure 1 contain information about the event X to be logged. Because logs LogA_X and LogB_X contain the same key, it can be confirmed that logs LogA_X and LogB_X relate to the same transaction (event X), and as a result, it can be confirmed that a transaction took place between user α and user β. Note that users α and β must agree on the key to be used for registration before registering in the distributed ledger, and must share information regarding the event source identifier, event destination identifier, and event identifier.

[0021] Furthermore, if the identifier of distributed ledger system C is <distributed ledger system C ID> and the identifier of user γ is <user γ ID>, the key used by user γ as a party to event X to register the log of event X, LogC_X, in the distributed ledger of distributed ledger system C will be, for example, <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID> or <distributed ledger system C ID><user γ ID><distributed ledger system B ID><user β ID><event ID> if user γ includes information identifying the user, and will be, for example, <distributed ledger system A ID><user α ID><event ID> or <distributed ledger system B ID><user β ID><event ID> if user γ does not include information identifying the user. When information identifying itself is included, the key will not match the key of the event log registered in the distributed ledger of distributed ledger system A or the key of the event log registered in the distributed ledger of distributed ledger system B, so a log corresponding to log LogC_X will not be found in the distributed ledger of distributed ledger system A or distributed ledger system B, and it will be possible to detect that the registration of log LogC_X is invalid. On the other hand, when information identifying itself is not included, the key will not meet the key format used for registration in the distributed ledger of distributed ledger system C, so log LogC_X cannot be registered in the first place (i.e., it cannot be recorded in the distributed ledger of distributed ledger system C).

[0022] In some cases, instead of using a combination of an identifier indicating the distributed ledger system and an identifier indicating the user as the event source identifier and the event destination identifier, only an identifier indicating the distributed ledger system may be used. In this case, the key for registering event X in the distributed ledger of distributed ledger system A or distributed ledger system B may be, for example, <distributed ledger system A ID><distributed ledger system B ID><event ID>.

[0023] Also, instead of each identifier, a hash value obtained by applying a hash function to the identifier may be used.

[0024] When an agent program executes a transaction on behalf of a user, an identifier indicating the agent program may be used instead of an identifier indicating the user. For example, when the agent program is a smart contract, the address of the smart contract may be used as the identifier indicating the agent program.

[0025] <First embodiment> The distributed ledger linkage system 10 includes two or more distributed ledger systems 20, and is a system for recording the history of transactions between a user of one distributed ledger system 20 and a user of a distributed ledger system 20 different from the distributed ledger system 20.

[0026] [Configuration of distributed ledger linkage system 10] The configuration of distributed ledger linkage system 10 will be described below with reference to Fig. 2 to Fig. 4. Fig. 2 is a block diagram showing the configuration of distributed ledger linkage system 10. Fig. 3 is a block diagram showing the configuration of terminal 100. Fig. 4 is a block diagram showing the configuration of monitoring terminal 200.

[0027] As illustrated in FIG. 2, the distributed ledger federation system 10 includes two or more distributed ledger systems 20. The distributed ledger federation system 10 illustrated in FIG. 2 includes three distributed ledger systems 20. A distributed ledger system 20 is a system for operating one distributed ledger and includes one or more terminals 100. The terminals 100 are terminals that record the distributed ledger. A monitoring terminal 20 is associated with each distributed ledger system 20. The monitoring terminals 20 monitor the operational status of the corresponding distributed ledger system 20. The terminals 100 included in a distributed ledger system 20 and the monitoring terminals 200 for monitoring the distributed ledger system 20 are each connected to a network 900. The network 900 may be any network configured to allow the terminals 100 and the monitoring terminals 200 to communicate with each other, such as the Internet. Furthermore, a distributed ledger system 20 is configured to be able to communicate with other distributed ledger systems 20 via the network 900.

[0028] 3, the terminal 100 includes an event data generation unit 110, a registration request unit 120, a first log registration unit 130, a registration notification generation unit 140, a registration confirmation request unit 150, a registration confirmation unit 160, a confirmation result generation unit 170, a second log registration unit 180, a transmission / reception unit 185, and a recording unit 190. The transmission / reception unit 185 is a component for transmitting and receiving information necessary for processing by the terminal 100 via the network 900. The recording unit 190 is a component for appropriately recording information necessary for processing by the terminal 100. The recording unit 190 records, for example, the distributed ledger of the distributed ledger system 20 including the terminal 100.

[0029] 4, monitoring terminal 200 includes a registration confirmation request unit 210, a result confirmation unit 220, an improper registration detection unit 230, an improper registration notification generation unit 240, a registration request unit 250, a transmission / reception unit 285, and a recording unit 290. Transmitting / receiving unit 285 is a component for transmitting and receiving information necessary for processing by monitoring terminal 200 via network 900. Recording unit 290 is a component for appropriately recording information necessary for processing by monitoring terminal 200.

[0030] [Operation of distributed ledger linkage system 10] Here, the operation of distributed ledger linkage system 10 will be described with reference to Figures 5 to 9. Specifically, the operation of distributed ledger linkage system 10 will be described in three cases: (1) event log registration, (2) fraudulent event log registration when there is no inconsistency in the event log key, and (3) fraudulent event log registration when there is an inconsistency in the event log key.

[0031] The distributed ledger system 20 realizes several operations required for the operation of a distributed ledger through the cooperative operation of one or more terminals 100 that make up the system. Specifically, the operations of the distributed ledger system 20 in S120 to S130 (see Figures 5, 7, and 9), the operations of the distributed ledger system 20 in S140 (see Figures 6 and 7), the operations of the distributed ledger system 20 in S210 to S170 (see Figures 6 and 7), and the operations of the distributed ledger system 20 in S240 to S180 (see Figure 8) are realized through the cooperative operation of one or more terminals 100 that make up the system. Existing distributed ledger protocols can be used to operate the distributed ledger system 20. For example, a distributed ledger integration protocol such as Hyperledger Cacti can be used to operate the distributed ledger system 20 in S150 to S160.

[0032] (1) Event Log Registration The operation of the distributed ledger linkage system 10 when registering an event log will be described below with reference to Figures 5 to 6. Figures 5 and 6 are example sequence diagrams showing the operation of the distributed ledger linkage system 10, and the two figures show a series of operations in the distributed ledger linkage system 10. Figures 5 and 6 are diagrams showing the operation of the distributed ledger linkage system 10 using two distributed ledger systems 20 (hereinafter referred to as distributed ledger system 20-1 and distributed ledger system 20-2), with terminal 100-1 included in distributed ledger system 20-1 being the sending terminal of the event data (i.e., the event source), and terminal 100-2 included in distributed ledger system 20-2 being the receiving terminal of the event data (i.e., the event destination). Here, the event data is, for example, data necessary for concluding a contract.

[0033] It is assumed that terminal 100-1 and terminal 100-2 have already agreed on the key to be used for event log registration, and have already exchanged the identifier included in the key.

[0034] The operation of the distributed ledger linkage system 10 when registering an event log consists of the following three operations.

[0035] (1) Exchange of event data (S110) (2) Registration of event log (S120 to S130) (3) Confirmation of event log registration (S140 to S220) Each of steps S110 to S220 will be described below.

[0036] In S110, event data generation section 110 of terminal 100-1 generates event data from data relating to the event input by the user, and transmission / reception section 185 of terminal 100-1 transmits the event data to terminal 100-2. Transmission / reception section 185 of terminal 100-2 receives the event data.

[0037] In S120, the registration request unit 120 of terminal 100-1 generates an event log including a key for registering the log of the event of S110 and information about the event of S110 to be recorded as a log (for example, the time the event occurred and an outline of the event), generates a registration request including the event log, and the transmission / reception unit 185 of terminal 100-1 sends the registration request to terminals 100 other than terminal 100-1 included in the distributed ledger system 20-1. The transmission / reception unit 185 of terminals 100 other than terminal 100-1 included in the distributed ledger system 20-1 receives the registration request. An example of an event log is the log LogA_X described in <Technical Background> (see FIG. 1).

[0038] Similarly, the registration request unit 120 of terminal 100-2 generates an event log including a key for registering the log of the event of S110 and information about the event of S110 to be recorded as a log (for example, the time the event occurred and an outline of the event), generates a registration request including the event log, and the transmission / reception unit 185 of terminal 100-2 sends the registration request to terminals 100 other than terminal 100-2 included in the distributed ledger system 20-2. The transmission / reception unit 185 of terminals 100 other than terminal 100-2 included in the distributed ledger system 20-2 receives the registration request. An example of an event log is the log LogB_X described in <Technical Background> (see FIG. 1).

[0039] In S130, the first log registration unit 130 of the terminal 100 included in the distributed ledger system 20-1 checks the consistency of the event log key included in the registration request of S120, and if there is no problem with the key consistency, records the event log in the recording unit 190 (registers it in the distributed ledger of the distributed ledger system 20-1), generates information indicating that the event log registration has been completed as a registration result, and the transceiver unit 185 of the terminal 100 included in the distributed ledger system 20-1 transmits the registration result to the other terminals 100 except for its own terminal. The transceiver unit 185 of the terminal 100 receives the registration result. If the event log is log LogA_X, the key is <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>, which satisfies the pre-agreed format (i.e., is consistent), so log LogA_X is recorded in the distributed ledger.

[0040] Similarly, the first log registration unit 130 of the terminal 100 included in the distributed ledger system 20-2 checks the consistency of the event log key included in the registration request of S120, and if there is no problem with the key consistency, records the event log in the recording unit 190 (registers it in the distributed ledger of the distributed ledger system 20-2), generates information indicating that the event log registration has been completed as a registration result, and the transceiver unit 185 of the terminal 100 included in the distributed ledger system 20-2 sends the registration result to the other terminals 100 except for its own terminal. The transceiver unit 185 of the terminal 100 receives the registration result. If the event log is log LogA_B, the key is <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>, which satisfies the pre-agreed format (i.e., is consistent), so log LogB_X is recorded in the distributed ledger.

[0041] In S140, if an event log was registered in the distributed ledger of distributed ledger system 20-1 in S130, the registration notification generator 140 of terminal 100 included in distributed ledger system 20-1 generates information indicating that the event log has been registered as a registration notification, and the transmitter / receiver 185 of terminal 100 included in distributed ledger system 20-1 sends the registration notification to monitoring terminal 200-1. The transmitter / receiver 185 of monitoring terminal 200-1 receives the registration notification. The registration notification includes the key included in the event log registered in S130. Therefore, if the event log is log LogA_X, the registration notification will include the key <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>.

[0042] In S210, the registration confirmation request unit 210 of monitoring terminal 200-1 generates a first confirmation request to confirm whether or not an event log including the key included in the registration notification received in S140 has been registered in the distributed ledger of distributed ledger system 20-2, and the transmission / reception unit 185 of monitoring terminal 200-1 sends the first confirmation request to terminal 100 included in distributed ledger system 20-1. The transmission / reception unit 185 of terminal 100 included in distributed ledger system 20-1 receives the first confirmation request. The first confirmation request includes the key included in the registration notification received in S140. Therefore, the first confirmation request includes the key<distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>.

[0043] In S150, the registration confirmation request unit 150 of the terminal 100 included in the distributed ledger system 20-1 generates a second confirmation request to confirm whether or not an event log including the key included in the first confirmation request received in S210 has been registered in the distributed ledger of the distributed ledger system 20-2, and the transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-1 sends the second confirmation request to the terminal 100 included in the distributed ledger system 20-2. The transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-2 receives the second confirmation request. The second confirmation request includes the key included in the first confirmation request received in S210. Therefore, the second confirmation request includes the key <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>.

[0044] In S160, the registration confirmation unit 160 of the terminal 100 included in the distributed ledger system 20-2 confirms whether an event log containing the key included in the second confirmation request received in S150 is registered in the distributed ledger of the distributed ledger system 20-2. If it is registered, the registration confirmation unit 160 generates information indicating that an event log containing the key included in the second confirmation request received in S150 has been registered as a first confirmation result, and the transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-2 transmits the first confirmation result to the terminal 100 included in the distributed ledger system 20-1. The transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-1 receives the first confirmation result. The second confirmation request received in S150 contains the key <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID>, and since an event log LogB_X containing that key is registered in the distributed ledger, the first confirmation result becomes information indicating that an event log containing that key has been registered.

[0045] In S170, the confirmation result generator 170 of terminal 100 included in distributed ledger system 20-1 generates a second confirmation result based on the first confirmation result received in S160, and the transmitter / receiver 185 of terminal 100 included in distributed ledger system 20-1 transmits the second confirmation result to monitoring terminal 200-1. The transmitter / receiver 185 of monitoring terminal 200-1 receives the second confirmation result. Since the first confirmation result is information indicating that an event log containing the key <distributed ledger system A ID><user α ID><distributed ledger system B ID><user β ID><event ID> has been registered, the second confirmation result is information indicating that an event log containing that key has been registered.

[0046] In S220, the result confirmation unit 220 of the monitoring terminal 200-1 confirms, based on the second confirmation result received in S170, that the event log containing the key included in the registration notification received in S140 has been registered in the distributed ledger of the distributed ledger system 20-2, and then terminates the processing.

[0047] The processes from S140 to S220 are similarly executed in the distributed ledger system 20-2 (see Figure 6).

[0048] (2) Fraudulent Event Log Registration When There is No Inconsistency in the Event Log Key Below, we will explain the operation of the distributed ledger linkage system 10 when there is a fraudulent event log registration when there is no inconsistency in the event log key, with reference to Figures 7 to 8. Figures 7 and 8 are sequence diagrams showing the operation of the distributed ledger linkage system 10, and the two figures show a series of operations in the distributed ledger linkage system 10. Figures 7 and 8 show the operation of the distributed ledger linkage system 10 using two distributed ledger systems 20 (hereinafter referred to as distributed ledger system 20-3 and distributed ledger system 20-4), where distributed ledger system 20-3 is a distributed ledger system that operates a distributed ledger in which the event log is registered (in the examples of Figures 5 to 6, distributed ledger system 20-1 or distributed ledger system 20-2), and distributed ledger system 20-4 is a distributed ledger system that includes terminal 100-4 that attempts to fraudulently register an event log related to an event in the event log.

[0049] The operation of the distributed ledger linkage system 10 when an incorrect event log registration occurs when there is no inconsistency in the event log keys consists of the following five operations.

[0050] (1) Event log registration (S120-S130) (2) Event log registration confirmation (S140-S220) (3) Detection of fraudulent registration (S230) (4) Notification of fraudulent registration detection (S240) (5) Responding to fraudulent registration detection (S250-S180) Each step from S120 to S180 will be explained below. The operations from S120 to S150 in Figure 7 are the same as the operations from S120 to S150 in Figures 5 and 6, so only the steps from S160 onwards will be explained. Note that the explanation here will be given assuming that distributed ledger system 20-3 is distributed ledger system 20-1.

[0051] In S160, the registration confirmation unit 160 of the terminal 100 included in the distributed ledger system 20-3 confirms whether or not an event log including the key included in the second confirmation request received in S150 is registered in the distributed ledger of the distributed ledger system 20-3, and if it is not registered, generates information indicating that an event log including the key included in the second confirmation request received in S150 is not registered as a first confirmation result, and the transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-3 transmits the first confirmation result to the terminal 100 included in the distributed ledger system 20-4. The transmission / reception unit 185 of the terminal 100 included in the distributed ledger system 20-4 receives the first confirmation result. If distributed ledger system 20-3 is distributed ledger system 20-1, the second confirmation request received in S150 contains the key <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID>, and since the event log LogA_X containing that key is not registered in the distributed ledger, the first confirmation result will be information indicating that an event log containing that key is not registered.

[0052] In S170, the confirmation result generator 170 of terminal 100 included in distributed ledger system 20-4 generates a second confirmation result based on the first confirmation result received in S160, and the transmitter / receiver 185 of terminal 100 included in distributed ledger system 20-4 sends the second confirmation result to monitoring terminal 200-4. The transmitter / receiver 185 of monitoring terminal 200-4 receives the second confirmation result. Since the first confirmation result is information indicating that an event log containing the key <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID> has not been registered, the second confirmation result is information indicating that an event log containing that key has not been registered.

[0053] In S220, the result confirmation unit 220 of the monitoring terminal 200-4 confirms, based on the second confirmation result received in S170, that the event log containing the key included in the registration notification received in S140 has not been registered in the distributed ledger of the distributed ledger system 20-3.

[0054] Therefore, monitoring terminal 220-4 returns to the process of S210. Then, the processes of S210 to S220 are repeated by monitoring terminal 220-4, distributed ledger system 20-4, and distributed ledger system 20-3.

[0055] In S230, if the fraudulent registration detection unit 230 of monitoring terminal 200-4 cannot confirm that the event log containing the key included in the registration notice received in S140 has been registered in the distributed ledger of distributed ledger system 20-3 even after repeating the processes from S210 to S220 a predetermined number of times, it generates information indicating that the registration of the event log containing the key included in the registration notice received in S140 is a fraudulent registration as a fraudulent registration detection result. The fraudulent registration detection result will include the key <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID>.

[0056] In S240, based on the fraudulent registration detection result generated in S230, the fraudulent registration notification generation unit 240 of monitoring terminal 200-4 generates a fraudulent registration notification, which is information indicating that the registration of the event log including the key included in the registration notification received in S140 is a fraudulent registration, and the transmission / reception unit 185 of monitoring terminal 200-4 transmits the fraudulent registration notification to terminal 100-4. The transmission / reception unit 185 of terminal 100-4 receives the fraudulent registration notification. The fraudulent registration notification includes the key <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID>.

[0057] In S250, based on the fraudulent registration detection result generated in S230, the registration request unit 250 of monitoring terminal 200-4 generates an fraudulent registration log, which is information indicating that the registration of the event log including the key included in the registration notification received in S140 is a fraudulent registration, and generates a registration request including the fraudulent registration log, and the transmission / reception unit 185 of monitoring terminal 200-4 sends the registration request to terminal 100-4 included in distributed ledger system 20-4. The transmission / reception unit 185 of terminal 100-4 included in distributed ledger system 20-4 receives the registration request. The fraudulent registration log contains the keys included in the registration notification received in S140: <distributed ledger system A ID><user α ID><distributed ledger system C ID><user γ ID><event ID>.

[0058] In S180, the second log registration unit 180 of terminal 100-4 included in distributed ledger system 20-4 records the fraudulent registration log received in S250 in recording unit 190 (registers it in the distributed ledger of distributed ledger system 20-4), generates information indicating that registration of the fraudulent registration log has been completed as a registration result, and the transmission / reception unit 185 of terminal 100-4 included in distributed ledger system 20-4 transmits the registration result to monitoring terminal 200-4. The transmission / reception unit 185 of monitoring terminal 200-4 receives the registration result.

[0059] (3) Fraudulent Event Log Registration When There is an Inconsistency in the Event Log Key Below, we will explain the operation of the distributed ledger linkage system 10 when an incorrect event log is registered when there is an inconsistency in the event log key, with reference to Figure 9. Figure 9 is a sequence diagram showing the operation of the distributed ledger linkage system 10. Figure 9 is a diagram showing the operation of the distributed ledger linkage system 10, which consists of two distributed ledger systems 20 (hereinafter referred to as distributed ledger system 20-5 and distributed ledger system 20-6). Distributed ledger system 20-5 is a distributed ledger system that operates a distributed ledger in which the event log is registered (in the examples of Figures 5 and 6, distributed ledger system 20-1 or distributed ledger system 20-2), and distributed ledger system 20-6 is a distributed ledger system that includes terminal 100-6 that attempts to fraudulently register an event log related to an event in the event log.

[0060] The operation of the distributed ledger linkage system 10 when an incorrect event log is registered due to an inconsistency in the event log key consists of the following single operation.

[0061] (1) Event Log Registration (S120 to S130) Each of steps S120 to S130 will be described below. The operation of S120 in Fig. 9 is the same as the operation of S120 in Fig. 7, so only step S130 will be described.

[0062] In S130, the first log registration unit 130 of the terminal 100 included in the distributed ledger system 20-6 checks the consistency of the event log key included in the registration request of S120, and if there is a problem with the key consistency, it terminates the process without recording the event log in the recording unit 190 (registering it in the distributed ledger of the distributed ledger system 20-6). If the event log is log LogC_X, the key is <distributed ledger system C ID><user γ ID><event ID>, which does not satisfy the pre-agreed format (i.e., there is no consistency), so log LogC_X is not recorded in the distributed ledger.

[0063] In this embodiment, the number of parties in the transaction is two, but as explained in the <Technical Background>, the number may be two or more.

[0064] The terminal 100 and the monitoring terminal 200 can be summarized as follows.

[0065] A terminal 100 included in one of two or more distributed ledger systems 20 included in a distributed ledger linkage system 10 that registers logs of events between two or more users includes a first log registration unit 130 that registers a log of an event including a predetermined key in the distributed ledger of the distributed ledger system 20 that includes the terminal 100, and the predetermined key includes an event source identifier that is an identifier for identifying the user sending the event data, an event destination identifier that is an identifier for identifying the user receiving the event data, and an event identifier that is an identifier for identifying the event, and the predetermined key includes either the event source identifier or the event destination identifier for identifying each of the two or more users.

[0066] A monitoring terminal 200 associated with one of two or more distributed ledger systems 20 included in a distributed ledger linkage system 10 that registers logs of events between two or more users includes a fraudulent registration detection unit 230 that determines that the event log has been fraudulently registered if it cannot confirm that the key included in the log of an event whose registration it is desired to confirm whether it is legitimate matches any of the specified keys included in the log of a legitimate event registered in the distributed ledger of the distributed ledger system 20 to which the monitoring terminal 200 is associated, and the specified key included in the log of a legitimate event includes an event source identifier that is an identifier for identifying the user who sends the data of the event, an event destination identifier that is an identifier for identifying the user who receives the data of the event, and an event identifier that is an identifier for identifying the event, and the specified key included in the log of a legitimate event includes either an event source identifier or an event destination identifier for identifying each of the two or more users who are parties to the event.

[0067] According to an embodiment of the present invention, it is possible to record the history of transactions between users who are not using the same distributed ledger. It is also possible to prevent fraudulent registrations by users who are not parties to the transaction. Furthermore, it is possible to detect that registrations by users who are not parties to the transaction are fraudulent.

[0068] <Additional Notes> The functions performed by the components described herein may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in a memory.

[0069] In this specification, a circuitry, unit, or means is hardware that is programmed to realize or performs the described functions, which may be any hardware disclosed herein or any hardware known to be programmed to realize or perform the described functions.

[0070] If the hardware is a processor considered to be a type of circuitry, the circuitry, means, or unit is a combination of the hardware and software used to configure the hardware and / or processor.

[0071] The various processes described above can be implemented by loading a program that executes each step of the above method into the recording unit 2020 of the computer 2000 shown in Figure 10, and operating the control unit 2010, input unit 2030, output unit 2040, display unit 2050, etc.

[0072] The program describing the processing contents can be recorded on a computer-readable recording medium, which may be, for example, a magnetic recording device, an optical disk, a magneto-optical recording medium, a semiconductor memory, or any other suitable recording medium.

[0073] The program may be distributed by, for example, selling, transferring, lending, etc. portable recording media such as DVDs and CD-ROMs on which the program is recorded. Furthermore, the program may be stored in a storage device of a server computer, and then transferred from the server computer to other computers via a network, thereby distributing the program.

[0074] A computer that executes such a program may first temporarily store the program recorded on a portable recording medium or transferred from a server computer in its own storage device. Then, when executing a process, the computer reads the program stored in its storage device and executes the process in accordance with the read program. Alternatively, the computer may read the program directly from a portable recording medium and execute the process in accordance with the program. Furthermore, the computer may execute the process in accordance with the program each time a program is transferred from a server computer to the computer. Alternatively, the server computer may not transfer the program to the computer, but may instead execute the process through a so-called ASP (Application Service Provider) service, which realizes the processing function by issuing an execution instruction and obtaining the results. Furthermore, the server computer may execute the process at the terminal using a so-called SaaS (Software as a Service) service, which allows users to use part of the server computer along with the program. In this embodiment, the program includes information used for processing by an electronic computer that is equivalent to a program (such as data that is not a direct instruction to a computer but has properties that dictate computer processing).

[0075] Furthermore, in this embodiment, the device is configured by executing a predetermined program on a computer, but at least a part of the processing contents may be realized by hardware.

[0076] The present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the spirit of the present invention. Furthermore, the processes described in the above embodiments may not only be executed in chronological order according to the order described, but may also be executed in parallel or individually depending on the processing capacity of the device that executes the processes or as needed.

Claims

1. A distributed ledger linkage method in which a distributed ledger linkage system including two or more distributed ledger systems (where each distributed ledger system includes one or more terminals) registers a log of an event between two or more users, wherein the terminal executes a step of registering the event log including a predetermined key in the distributed ledger of the distributed ledger system of which the terminal is included, wherein the predetermined key includes an event source identifier which is an identifier for identifying the user sending the event data, an event destination identifier which is an identifier for identifying the user receiving the event data, and an event identifier which is an identifier for identifying the event, and the predetermined key includes either the event source identifier or the event destination identifier for identifying each of the two or more users.

2. A distributed ledger linkage system comprising two or more distributed ledger systems (where each distributed ledger system comprises one or more terminals) that register logs of events between two or more users, wherein the terminal comprises a first log registration unit that registers the event log, including a predetermined key, in the distributed ledger of the distributed ledger system that the terminal comprises, wherein the predetermined key comprises an event source identifier that is an identifier for identifying the user sending the event data, an event destination identifier that is an identifier for identifying the user receiving the event data, and an event identifier that is an identifier for identifying the event, and the predetermined key includes either the event source identifier or the event destination identifier for identifying each of the two or more users.

3. A terminal included in one of two or more distributed ledger systems included in a distributed ledger linkage system that registers logs of events between two or more users, the terminal including a first log registration unit that registers the event log including a predetermined key in the distributed ledger of the distributed ledger system that the terminal is included in, the predetermined key including an event source identifier that is an identifier for identifying the user sending the event data, an event destination identifier that is an identifier for identifying the user receiving the event data, and an event identifier that is an identifier for identifying the event, and the predetermined key includes either the event source identifier or the event destination identifier for identifying each of the two or more users.

4. A monitoring terminal associated with one of two or more distributed ledger systems included in a distributed ledger linkage system that registers logs of events between two or more users, comprising: a fraudulent registration detection unit that determines that an event log has been fraudulently registered if it cannot be confirmed that a key included in the log of an event whose registration is to be confirmed as legitimate matches any of the predetermined keys included in legitimate event logs registered in the distributed ledger of the distributed ledger system to which the monitoring terminal is associated; wherein the predetermined key included in the legitimate event log includes an event source identifier that is an identifier for identifying the user sending the event data, an event destination identifier that is an identifier for identifying the user receiving the event data, and an event identifier that is an identifier for identifying the event; and wherein the predetermined key included in the legitimate event log includes either an event source identifier or an event destination identifier for identifying each of the two or more users who are parties to the event.

Images