WO2025220103A1 - 分散台帳連携方法、分散台帳連携システム、端末、監視端末 - Google Patents

分散台帳連携方法、分散台帳連携システム、端末、監視端末

Info

Publication number
WO2025220103A1
WO2025220103A1 PCT/JP2024/015094 JP2024015094W WO2025220103A1 WO 2025220103 A1 WO2025220103 A1 WO 2025220103A1 JP 2024015094 W JP2024015094 W JP 2024015094W WO 2025220103 A1 WO2025220103 A1 WO 2025220103A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
distributed ledger
identifier
log
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/015094
Other languages
English (en)
French (fr)
Inventor
盛徳 大橋
一凡 張
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
NTT Inc USA
Original Assignee
Nippon Telegraph and Telephone Corp
NTT Inc USA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp, NTT Inc USA filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2024/015094 priority Critical patent/WO2025220103A1/ja
Publication of WO2025220103A1 publication Critical patent/WO2025220103A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present invention relates to distributed ledger technology.
  • 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.
  • 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).
  • the present invention therefore aims to provide distributed ledger technology that can record the history of transactions between users who do not use the same distributed ledger.
  • 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 (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 in which the terminal is included, the predetermined key including 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.
  • This invention makes it possible to record the history of transactions between users who do not use the same distributed ledger.
  • FIG. 10 illustrates an example of an event log.
  • FIG. 1 is a block diagram showing the configuration of a distributed ledger linkage system 10.
  • FIG. 2 is a block diagram showing the configuration of a terminal 100.
  • FIG. 2 is a block diagram showing the configuration of a monitoring terminal 200.
  • FIG. 1 is a sequence diagram showing the operation of the distributed ledger linkage system 10.
  • FIG. 1 is a sequence diagram showing the operation of the distributed ledger linkage system 10.
  • FIG. 1 is a sequence diagram showing the operation of the distributed ledger linkage system 10.
  • FIG. 1 is a sequence diagram showing the operation of the distributed ledger linkage system 10.
  • FIG. 1 is a sequence diagram showing the operation of the distributed ledger linkage system 10.
  • FIG. 2 is a diagram illustrating an example of the functional configuration of a computer that realizes each device according to an embodiment of the present invention.
  • a key having a predetermined format is used when registering transaction history in a distributed ledger, and the history of one transaction is registered using a single key common to the users who are parties to the transaction.
  • 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 distributed ledger system is operated by users sharing, replicating, and synchronizing the distributed ledger.
  • a transaction between multiple parties, such as a contract is called an event, and its history is called a log.
  • Event X a transaction between user ⁇ of distributed ledger system A and user ⁇ of distributed ledger system B (different from distributed ledger system A).
  • the transaction involves sending and receiving the data necessary for the transaction between user ⁇ and user ⁇ .
  • user ⁇ of distributed ledger system A sends event X data to user ⁇ of distributed ledger system B, and that user ⁇ registers event X log LogA_X in the distributed ledger of distributed ledger system A, and user ⁇ registers event X log LogB_X in the distributed ledger of distributed ledger system B.
  • 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.
  • distributed ledger system C 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.
  • 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.
  • 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.
  • a key including an event source identifier, an event destination identifier, and an event identifier is used as the key used when registering transaction history in the distributed ledger.
  • an event source identifier is an identifier used to identify the user sending event data
  • an event destination identifier is an identifier used to identify the user receiving event data
  • an event identifier is an identifier used to identify the event.
  • both the event source identifier and the event destination identifier can be a pair of an identifier indicating the distributed ledger system and an identifier indicating the user.
  • 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 a 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.
  • the event log then contains a key and information about the event you want to log.
  • the identifier of distributed ledger system A is ⁇ distributed ledger system A ID>
  • the identifier of user ⁇ is ⁇ user ⁇ ID>
  • the identifier of distributed ledger system B is ⁇ distributed ledger system B ID>
  • the identifier of user ⁇ is ⁇ user ⁇ ID>
  • the event identifier is ⁇ event ID>
  • the event source identifier is ⁇ distributed ledger system A ID> ⁇ user ⁇ ID>
  • the event destination identifier is ⁇ distributed ledger system B ID> ⁇ user ⁇ ID>
  • 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.
  • 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 recorded as a log. 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 prior to registration in the distributed ledger, and must share information regarding the event source identifier, event destination identifier, and event identifier.
  • 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 information identifying the user is included, 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 information identifying the user is not included.
  • the key 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.
  • the key 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).
  • 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>.
  • a hash value obtained by applying a hash function to the identifier may be used instead of each identifier.
  • an identifier indicating the agent program may be used instead of an identifier indicating the user.
  • the agent program is a smart contract
  • the address of the smart contract may be used as the identifier indicating the agent program.
  • 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 users of one distributed ledger system 20 and users of a distributed ledger system 20 different from the one in question.
  • FIG. 10 is a block diagram showing the configuration of distributed ledger linkage system 10.
  • Figure 3 is a block diagram showing the configuration of terminal 100.
  • Figure 4 is a block diagram showing the configuration of monitoring terminal 200.
  • the distributed ledger federation system 10 includes two or more distributed ledger systems 20.
  • the distributed ledger federation system 10 illustrated in Figure 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.
  • a terminal 100 is a terminal that records the distributed ledger.
  • a monitoring terminal 20 is associated with each distributed ledger system 20.
  • the monitoring terminal 20 monitors the operational status of the corresponding distributed ledger system 20.
  • the terminals 100 included in a distributed ledger system 20 and the monitoring terminal 200 for monitoring that 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 monitoring terminals 200 to communicate with each other, and the Internet, for example, may be used.
  • a distributed ledger system 20 is configured to be able to communicate with other distributed ledger systems 20 via the network 900.
  • 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.
  • the 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.
  • the transmission/reception unit 285 is a component for transmitting and receiving information necessary for processing by the monitoring terminal 200 via the network 900.
  • the recording unit 290 is a component for appropriately recording information necessary for processing by the monitoring terminal 200.
  • 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 operation of the distributed ledger system 20 at S120 to S130 (see Figures 5, 7, and 9), the operation of the distributed ledger system 20 at S140 (see Figures 6 and 7), the operation of the distributed ledger system 20 at S210 to S170 (see Figures 6 and 7), and the operation of the distributed ledger system 20 at 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.
  • a distributed ledger integration protocol such as Hyperledger Cacti can be used to operate the distributed ledger system 20 at S150 to S160.
  • FIG. 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).
  • the event data is, for example, data necessary for concluding a contract.
  • terminal 100-1 and terminal 100-2 have already agreed on the key to be used for event log registration, and that the identifiers included in the key have already been exchanged.
  • the operation of the distributed ledger linkage system 10 when registering an event log consists of the following three operations:
  • the event data generation unit 110 of terminal 100-1 generates event data from the event-related data entered by the user, and the transmission/reception unit 185 of terminal 100-1 transmits the event data to terminal 100-2.
  • the transmission/reception unit 185 of terminal 100-2 receives the event data.
  • the registration request unit 120 of terminal 100-1 generates an event log containing a key for registering the log of the event of S110 and information about the event of S110 to be recorded as a log (e.g., the time the event occurred, an outline of the event), and generates a registration request containing the event log.
  • the transceiver 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 transceiver 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 log LogA_X described in ⁇ Technical Background> (see Figure 1).
  • the registration request unit 120 of terminal 100-2 generates an event log containing a key for registering the log of the S110 event and information about the S110 event to be recorded as a log (e.g., the time the event occurred, an overview of the event), generates a registration request containing the event log, and the transceiver 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 transceiver 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 Figure 1).
  • 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 transmission/reception unit 185 of the terminal 100 included in the distributed ledger system 20-1 transmits the registration result to the other terminals 100 other than its own terminal.
  • the transmission/reception unit 185 of the terminal 100 receives the registration result.
  • 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.
  • 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 other than its own terminal. The transceiver unit 185 of the terminal 100 receives the registration result.
  • 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.
  • the registration notification generation unit 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 transmission/reception unit 185 of terminal 100 included in distributed ledger system 20-1 sends the registration notification to monitoring terminal 200-1.
  • the transmission/reception unit 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>.
  • the registration confirmation request unit 210 of monitoring terminal 200-1 generates a first confirmation request to confirm whether or not the event log containing 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>.
  • 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 the 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>.
  • 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 sends this 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 this key is registered in the distributed ledger, the first confirmation result becomes information indicating that an event log containing this key has been registered.
  • the confirmation result generation unit 170 of the terminal 100 included in the distributed ledger system 20-1 generates a second confirmation result based on the first confirmation result received in S160, and the transmission/reception unit 185 of the terminal 100 included in the distributed ledger system 20-1 transmits the second confirmation result to the monitoring terminal 200-1.
  • the transmission/reception unit 185 of the 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.
  • the result confirmation unit 220 of 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 distributed ledger system 20-2, and then terminates processing.
  • FIGS. 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.
  • distributed ledger system 20-3 is a distributed ledger system that operates a distributed ledger in which the event log is registered
  • 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.
  • the operation of the distributed ledger linkage system 10 when an invalid event log entry occurs when there is no inconsistency in the event log keys consists of the following five operations.
  • the registration confirmation unit 160 of the terminal 100 included in the distributed ledger system 20-3 confirms whether or not 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-3, and if not registered, generates information indicating that an event log containing 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.
  • 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.
  • the confirmation result generation unit 170 of the terminal 100 included in the distributed ledger system 20-4 generates a second confirmation result based on the first confirmation result received in S160, and the transmission/reception unit 185 of the terminal 100 included in the distributed ledger system 20-4 transmits the second confirmation result to the monitoring terminal 200-4.
  • the transmission/reception unit 185 of the 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 the key has not been registered.
  • 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.
  • monitoring terminal 220-4 returns to processing S210. Then, processing from S210 to S220 is repeated by monitoring terminal 220-4, distributed ledger system 20-4, and distributed ledger system 20-3.
  • the fraudulent registration detection unit 230 of monitoring terminal 200-4 cannot confirm that the event log containing the key included in the registration notification received in S140 has been registered in the distributed ledger of distributed ledger system 20-3 even after repeatedly executing 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 notification 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>.
  • the fraudulent registration notification generation unit 240 of monitoring terminal 200-4 generates a fraudulent registration notification based on the fraudulent registration detection result generated in S230, indicating that the event log registration 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>.
  • the registration request unit 250 of monitoring terminal 200-4 In S250, based on the fraudulent registration detection result generated in S230, the registration request unit 250 of monitoring terminal 200-4 generates a fraudulent registration log containing information indicating that the registration of the event log containing the key included in the registration notification received in S140 is a fraudulent registration, and generates a registration request containing the fraudulent registration log.
  • the transmitter/receiver unit 185 of monitoring terminal 200-4 sends the registration request to terminal 100-4 included in distributed ledger system 20-4.
  • the transmitter/receiver unit 185 of terminal 100-4 included in distributed ledger system 20-4 receives the registration request.
  • the fraudulent registration log contains the keys ⁇ distributed ledger system A ID> ⁇ user ⁇ ID> ⁇ distributed ledger system C ID> ⁇ user ⁇ ID> ⁇ event ID> included in the registration notification received in S140.
  • 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 the 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 the monitoring terminal 200-4.
  • the transmission/reception unit 185 of monitoring terminal 200-4 receives the registration result.
  • FIG 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.
  • 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.
  • Event log registration (S120 to S130) The following describes each of steps S120 to S130. Since the operation of S120 in Fig. 9 is the same as the operation of S120 in Fig. 7, only step S130 will be described.
  • 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.
  • the number of parties in the transaction is described as two, but as explained in the ⁇ Technical Background> section, it may be more than two.
  • the terminal 100 and monitoring terminal 200 can be summarized as follows:
  • 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 an event log including a predetermined key in the distributed ledger of the distributed ledger system 20 that the terminal 100 is included in, 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.
  • 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 event logs between two or more users includes a fraudulent registration detection unit 230 that determines that an event log has been fraudulently registered if it cannot confirm that the 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 20 to which the monitoring terminal 200 is associated;
  • the predetermined keys included in a legitimate event log include 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;
  • the predetermined keys included in a legitimate event log include either an event source identifier or an event destination identifier that are used to identify each of the two or more users involved in the event.
  • 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.
  • 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 programs stored in memory.
  • a circuit, unit, or means refers to hardware that is programmed to realize or executes the described functions.
  • the hardware may be any hardware disclosed in this specification or any hardware known to be programmed to realize or execute the described functions.
  • the hardware is a processor, which is considered to be a type of circuitry
  • the circuitry, means, or unit is the combination of the hardware and the software used to configure the hardware and/or processor.
  • the program describing this processing can be recorded on a computer-readable recording medium.
  • Examples of computer-readable recording media include magnetic recording devices, optical disks, magneto-optical recording media, and semiconductor memory.
  • this program may be distributed, for example, by selling, transferring, or lending portable recording media such as DVDs or CD-ROMs on which the program is recorded.
  • the program may be stored in a storage device on a server computer, and then transferred from the server computer to other computers via a network, thereby distributing the program.
  • a computer that executes such a program for example, first stores the program recorded on a portable recording medium or transferred from a server computer in its own storage device. Then, when executing processing, the computer reads the program stored in its storage device and executes processing in accordance with the read program.
  • the computer may read the program directly from the portable recording medium and execute processing in accordance with that program, or it may execute processing in accordance with the received program each time a program is transferred to this computer from the server computer.
  • the server computer may not transfer the program to this computer, but rather executes processing using a so-called ASP (Application Service Provider) type service, which realizes processing functions simply by issuing execution instructions and obtaining results.
  • ASP Application Service Provider
  • the computer may be configured to execute terminal processing using a so-called SaaS (Software as a Service) type service, which allows users to use part of a server computer along with the program.
  • 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 command to a computer but has properties that dictate computer processing).
  • the device is configured by executing a specific program on a computer, but at least part of the processing may also be implemented in hardware.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Debugging And Monitoring (AREA)

Abstract

２以上の分散台帳システム（ただし、各分散台帳システムは１以上の端末を含む）を含む分散台帳連携システムが２以上のユーザ間でのイベントのログを登録する分散台帳連携方法であって、前記端末が、所定のキーを含む前記イベントのログを当該端末が含まれる分散台帳システムの分散台帳に登録するステップを実行するものであり、前記所定のキーは前記イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、前記イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、前記イベントを特定するための識別子であるイベント識別子とを含むものであり、前記所定のキーには前記２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている。

Description

分散台帳連携方法、分散台帳連携システム、端末、監視端末
　本発明は、分散台帳技術に関する。
　分散台帳は、分散ネットワークのユーザ間で共有、複製、同期されるデータベースであり、特定の第三者を介することなくユーザ間の取引（例えば、契約）に関する履歴を記録する。ここで、分散ネットワークとは、ネットワークを管理する中央サーバが存在せず、ユーザがそれぞれ対等な関係（Peer to Peerな関係）でつながっているシステムである。分散台帳に取引の履歴を記録することで、取引の真正性が担保される。分散台帳に取引の履歴を記録する技術として、例えば特許文献１の技術が存在する。
特開２０１７－２２０７１０号
　現在、用途ごとに複数の分散台帳が乱立する状態となっており、取引を行おうと考えているユーザが同一の分散台帳を利用していない場合も考えられる。このような場合であっても、特定の第三者を必要とすることなく取引の履歴を当該取引の当事者となるユーザが現在利用している分散台帳に記録し、取引の真正性が担保されるのが好ましい。加えて、取引に関係のない者により取引の履歴の不正登録が実行された場合に不正登録が実行されたことを検出する仕組みや不正登録そのものが実行できないようにする仕組みがあるのが好ましい。
　そこで本発明では、同一の分散台帳を利用していないユーザ間の取引の履歴を記録することができる分散台帳技術を提供することを目的とする。
　本発明の一態様は、２以上の分散台帳システム（ただし、各分散台帳システムは１以上の端末を含む）を含む分散台帳連携システムが２以上のユーザ間でのイベントのログを登録する分散台帳連携方法であって、前記端末が、所定のキーを含む前記イベントのログを当該端末が含まれる分散台帳システムの分散台帳に登録するステップを実行するものであり、前記所定のキーは前記イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、前記イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、前記イベントを特定するための識別子であるイベント識別子とを含むものであり、前記所定のキーには前記２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている。
　本発明によれば、同一の分散台帳を利用していないユーザ間の取引の履歴を記録することが可能となる。
イベントログの一例を示す図である。 分散台帳連携システム１０の構成を示すブロック図である。 端末１００の構成を示すブロック図である。 監視端末２００の構成を示すブロック図である。 分散台帳連携システム１０の動作を示すシークエンス図である。 分散台帳連携システム１０の動作を示すシークエンス図である。 分散台帳連携システム１０の動作を示すシークエンス図である。 分散台帳連携システム１０の動作を示すシークエンス図である。 分散台帳連携システム１０の動作を示すシークエンス図である。 本発明の実施形態における各装置を実現するコンピュータの機能構成の一例を示す図である。
　以下、本発明の実施形態について、詳細に説明する。なお、同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。
＜技術的背景＞
　本発明の実施形態では、分散台帳に取引の履歴を登録する際に用いるキーとして所定の形式を有するものを採用し、取引の当事者であるユーザ間で共通する１つのキーを用いて１つの取引の履歴の登録を行う。
　以下、１つの分散台帳を運用するためのシステムのことを分散台帳システムという。分散台帳システムのユーザは互いに対等な関係であり、分散台帳システムのユーザ間で分散台帳を共有、複製、同期することで、分散台帳システムは運用される。また、例えば契約のような複数当事者による取引のことをイベント、その履歴をログという。
　本発明の実施形態で扱う問題を定式化する。分散台帳システムAのユーザαと（分散台帳システムAと異なる）分散台帳システムBのユーザβとの間である取引（イベントX）をすることを考える。取引に伴いユーザαとユーザβとの間で取引に必要なデータの送受信が行われるものとする。ここでは、分散台帳システムAのユーザαから分散台帳システムBのユーザβに対してイベントXのデータが送信されるものとし、ユーザαがイベントXのログLogA_Xを分散台帳システムAの分散台帳に登録、ユーザβがイベントXのログLogB_Xを分散台帳システムBの分散台帳に登録することを考える。
　このとき、以下の仕組みを実現する必要がある。
（１）ユーザαがイベントXのログLogA_Xを分散台帳システムAの分散台帳に、ユーザβがイベントXのログLogB_Xを分散台帳システムBの分散台帳に登録できるようにする。その際、ログLogA_XとログLogB_Xが1つの取引に関するものであることが確認できる必要がある。
（２）取引の当事者ではない分散台帳システムCのユーザγがイベントXのログLogC_Xを分散台帳システムCの分散台帳に登録できないようにする。または、ユーザγがイベントXのログLogC_Xを分散台帳システムCの分散台帳に登録した場合には不正な登録であることを検出できるようにする。ここで、分散台帳システムCは、分散台帳システムA、分散台帳システムBのいずれとも異なる分散台帳システムであってもよいし、分散台帳システムA、分散台帳システムBのいずれかであってもよいものとする。
　（１）の仕組みが実現されるためには、ログLogA_XからログLogB_Xを特定することができる必要がある。また、逆にログLogB_XからログLogA_Xを特定することができる必要もある。
　上記仕組みを実現するために、分散台帳に取引の履歴を登録する際に用いるキーとしてイベント元識別子、イベント先識別子、イベント識別子を含むキーを採用する。
　ここで、イベント元識別子とはイベントデータを送信するユーザを特定するための識別子、イベント先識別子とはイベントデータを受信するユーザを特定するための識別子、イベント識別子とはイベントを特定するための識別子のことである。例えば、イベント元識別子、イベント先識別子はいずれも分散台帳システムを示す識別子とユーザを示す識別子の組とすることができる。なお、イベントが発生するためにはイベント元の数とイベント先の数の和が２以上であればよい。したがって、キーに含まれるイベント元識別子の数とイベント先識別子の数の和は２以上となる。ただし、イベント元識別子の数、イベント先識別子の数のいずれかが0であってもよいものとする。
　そのうえで、イベントログはキーとログとして記録したいイベントに関する情報とを含むものとする。
　以下、例を用いて説明する。分散台帳システムAの識別子を<分散台帳システムA ID>、ユーザαの識別子を<ユーザα ID>、分散台帳システムBの識別子を<分散台帳システムB ID>、ユーザβの識別子を<ユーザβ ID>、イベント識別子を<イベントID>とすると、イベント元識別子は<分散台帳システムA ID><ユーザα ID>、イベント先識別子は<分散台帳システムB ID><ユーザβ ID>となり、分散台帳システムAの分散台帳にイベントXのログLogA_Xを登録するためのキー、分散台帳システムBの分散台帳にイベントXのログLogB_Xを登録するためのキーは、いずれも<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>となる。図１はイベントログの一例を示す図である。図１のイベントXのログLogA_X、イベントXのログLogB_Xは、キーの他にログとして記録したいイベントXに関する情報を含んでいる。ログLogA_X、ログLogB_Xが同一のキーを含むことから、ログLogA_XとログLogB_Xが同一の取引（イベントX）に関するものであることが確認でき、その結果ユーザαとユーザβの間で取引があったことが確認できる。なお、ユーザαとユーザβは分散台帳への登録に先立って登録に用いるキーに関して合意し、イベント元識別子、イベント先識別子、イベント識別子に関する情報を共有しておく必要がある。
　また、分散台帳システムCの識別子を<分散台帳システムC ID>、ユーザγの識別子を<ユーザγ ID>とすると、ユーザγがイベントXの当事者として分散台帳システムCの分散台帳にイベントXのログLogC_Xを登録するためのキーは、自らを示す情報を含める場合は例えば<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>または<分散台帳システムC ID><ユーザγ ID><分散台帳システムB ID><ユーザβ ID><イベントID>、自らを示す情報を含めない場合は例えば<分散台帳システムA ID><ユーザα ID><イベントID>または<分散台帳システムB ID><ユーザβ ID><イベントID>となる。自らを示す情報を含める場合のキーは、分散台帳システムAの分散台帳に登録されているイベントログのキーや分散台帳システムBの分散台帳に登録されているイベントログのキーと一致しないため、分散台帳システムAの分散台帳や分散台帳システムBの分散台帳の中にログLogC_Xに対応するログが見つからず、ログLogC_Xの登録が不正なものであることを検出することができる。一方、自らを示す情報を含めない場合のキーは、分散台帳システムCの分散台帳への登録に用いられるキーの書式を満たさないため、そもそもログLogC_Xを登録する（つまり、分散台帳システムCの分散台帳に記録する）ことができない。
　なお、場合によっては、イベント元識別子、イベント先識別子として分散台帳システムを示す識別子とユーザを示す識別子の組の代わりに分散台帳システムを示す識別子のみを用いるようにしてもよい。この場合、分散台帳システムAの分散台帳や分散台帳システムBの分散台帳にイベントXを登録するためのキーは例えば<分散台帳システムA ID><分散台帳システムB ID><イベントID>となる。
　また、各識別子の代わりに、識別子にハッシュ関数を適用して得られるハッシュ値を用いるようにしてもよい。
　ユーザの代わりにエージェントプログラムが取引を実行する場合は、ユーザを示す識別子の代わりにエージェントプログラムを示す識別子を用いてもよい。例えば、エージェントプログラムがスマートコントラクトである場合、エージェントプログラムを示す識別子として例えばスマートコントラクトのアドレスを用いることができる。
＜第１実施形態＞
　分散台帳連携システム１０は、２以上の分散台帳システム２０を含むものであり、ある分散台帳システム２０のユーザと当該分散台帳システム２０とは異なる分散台帳システム２０のユーザとの間での取引の履歴を記録するためのシステムである。
［分散台帳連携システム１０の構成］
　以下、図２～図４を参照して分散台帳連携システム１０の構成について説明する。図２は、分散台帳連携システム１０の構成を示すブロック図である。図３は、端末１００の構成を示すブロック図である。図４は、監視端末２００の構成を示すブロック図である。
　分散台帳連携システム１０は、図２に例示するように、２以上の分散台帳システム２０を含む。図２に例示する分散台帳連携システム１０は、３つの分散台帳システム２０を含む。分散台帳システム２０は、１つの分散台帳を運用するためのシステムであり、１以上の端末１００を含む。端末１００は、分散台帳を記録する端末である。また、各分散台帳システム２０には、監視端末２０が対応付けられている。監視端末２０は、対応する分散台帳システム２０の運用状況を監視する。分散台帳システム２０に含まれる端末１００及び当該分散台帳システム２０を監視するための監視端末２００はそれぞれネットワーク９００に接続される。ネットワーク９００は、端末１００、監視端末２００が相互に通信可能なように構成されたネットワークであればよく、例えばインターネットを用いることができる。さらに、分散台帳システム２０はネットワーク９００を介して他の分散台帳システム２０と通信可能なように構成される。
　端末１００は、図３に例示するように、イベントデータ生成部１１０と、登録要求部１２０と、第１ログ登録部１３０と、登録通知生成部１４０と、登録確認要求部１５０と、登録確認部１６０と、確認結果生成部１７０と、第２ログ登録部１８０と、送受信部１８５と、記録部１９０を含む。送受信部１８５は、ネットワーク９００を介して端末１００の処理に必要な情報を送受信するための構成部である。記録部１９０は、端末１００の処理に必要な情報を適宜記録する構成部である。記録部１９０は、例えば、端末１００を含む分散台帳システム２０の分散台帳を記録する。
　監視端末２００は、図４に例示するように、登録確認要求部２１０と、結果確認部２２０と、不正登録検出部２３０と、不正登録通知生成部２４０と、登録要求部２５０と、送受信部２８５と、記録部２９０を含む。送受信部２８５は、ネットワーク９００を介して監視端末２００の処理に必要な情報を送受信するための構成部である。記録部２９０は、監視端末２００の処理に必要な情報を適宜記録する構成部である。
［分散台帳連携システム１０の動作］
　ここでは、図５～図９を参照して分散台帳連携システム１０の動作について説明する。具体的には、（１）イベントログ登録、（２）イベントログのキーに不整合がない場合のイベントログ不正登録、（３）イベントログのキーに不整合がある場合のイベントログ不正登録という３つの場面における分散台帳連携システム１０の動作について説明する。
　分散台帳システム２０は、当該システムを構成する１以上の端末１００が協調動作することによって、分散台帳の運用に必要ないくつかの動作を実現する。具体的には、Ｓ１２０～Ｓ１３０における分散台帳システム２０の動作（図５、図７、図９参照）、Ｓ１４０における分散台帳システム２０の動作（図６、図７参照）、Ｓ２１０～Ｓ１７０における分散台帳システム２０の動作（図６、図７参照）、Ｓ２４０～Ｓ１８０における分散台帳システム２０の動作（図８参照）は、当該システムを構成する１以上の端末１００が協調動作することによって実現される。分散台帳システム２０の動作には、既存の分散台帳に関するプロトコルを用いることができる。例えば、Ｓ１５０～Ｓ１６０における分散台帳システム２０の動作にはHyperledger Cactiのような分散台帳連携に関するプロトコルを用いることができる。
（１）イベントログ登録
　以下、図５～図６を参照してイベントログ登録時の分散台帳連携システム１０の動作について説明する。図５、図６は、分散台帳連携システム１０の動作を示すシーケンス図の一例であり、２つの図で分散台帳連携システム１０における一連の動作を示すものである。図５、図６は、２つの分散台帳システム２０（以下、分散台帳システム２０－１、分散台帳システム２０－２とする）による分散台帳連携システム１０の動作を示す図であり、分散台帳システム２０－１に含まれる端末１００－１はイベントデータの送信端末（つまり、イベント元）、分散台帳システム２０－２に含まれる端末１００－２はイベントデータの受信端末（つまり、イベント先）である。ここで、イベントデータは、例えば契約締結に必要なデータである。
　端末１００－１と端末１００－２の間では予めイベントログ登録に用いるキーに関する合意が取れており、キーに含まれる識別子の交換は済んでいるものとする。
　イベントログ登録時の分散台帳連携システム１０の動作は、以下の３つの動作から構成される。
（１）イベントデータの交換（Ｓ１１０）
（２）イベントログの登録（Ｓ１２０～Ｓ１３０）
（３）イベントログの登録確認（Ｓ１４０～Ｓ２２０）
　以下、Ｓ１１０～Ｓ２２０の各ステップについて説明する。
　Ｓ１１０において、端末１００－１のイベントデータ生成部１１０は、ユーザが入力したイベントに関するデータからイベントデータを生成し、端末１００－１の送受信部１８５は、当該イベントデータを端末１００－２に送信する。端末１００－２の送受信部１８５は、イベントデータを受信する。
　Ｓ１２０において、端末１００－１の登録要求部１２０は、Ｓ１１０のイベントのログを登録するためのキーとログとして記録したいＳ１１０のイベントの情報（例えば、イベントの発生時刻、イベントの概要）とを含むイベントログを生成し、当該イベントログを含む登録要求を生成し、端末１００－１の送受信部１８５は、当該登録要求を分散台帳システム２０－１に含まれる端末１００－１以外の端末１００に送信する。分散台帳システム２０－１に含まれる端末１００－１以外の端末１００の送受信部１８５は、登録要求を受信する。イベントログの一例は、＜技術的背景＞で説明したログLogA_Xである（図１参照）。
　同様に、端末１００－２の登録要求部１２０は、Ｓ１１０のイベントのログを登録するためのキーとログとして記録したいＳ１１０のイベントの情報（例えば、イベントの発生時刻、イベントの概要）とを含むイベントログを生成し、当該イベントログを含む登録要求を生成し、端末１００－２の送受信部１８５は、当該登録要求を分散台帳システム２０－２に含まれる端末１００－２以外の端末１００に送信する。分散台帳システム２０－２に含まれる端末１００－２以外の端末１００の送受信部１８５は、登録要求を受信する。イベントログの一例は、＜技術的背景＞で説明したログLogB_Xである（図１参照）。
　Ｓ１３０において、分散台帳システム２０－１に含まれる端末１００の第１ログ登録部１３０は、Ｓ１２０の登録要求に含まれるイベントログのキーの整合性を確認し、キーの整合性に問題がない場合はイベントログを記録部１９０に記録（分散台帳システム２０－１の分散台帳に登録）し、イベントログの登録が完了したことを示す情報を登録結果として生成し、分散台帳システム２０－１に含まれる端末１００の送受信部１８５は当該登録結果を自端末を除くその他の端末１００に送信する。端末１００の送受信部１８５は、登録結果を受信する。イベントログがログLogA_Xである場合、キーは<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>であり、事前に合意している形式を満たす（つまり、整合している）ため、ログLogA_Xは分散台帳に記録される。
　同様に、分散台帳システム２０－２に含まれる端末１００の第１ログ登録部１３０は、Ｓ１２０の登録要求に含まれるイベントログのキーの整合性を確認し、キーの整合性に問題がない場合はイベントログを記録部１９０に記録（分散台帳システム２０－２の分散台帳に登録）し、イベントログの登録が完了したことを示す情報を登録結果として生成し、分散台帳システム２０－２に含まれる端末１００の送受信部１８５は当該登録結果を自端末を除くその他の端末１００に送信する。端末１００の送受信部１８５は、登録結果を受信する。イベントログがログLogA_Bである場合、キーは<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>であり、事前に合意している形式を満たす（つまり、整合している）ため、ログLogB_Xは分散台帳に記録される。
　Ｓ１４０において、分散台帳システム２０－１に含まれる端末１００の登録通知生成部１４０は、Ｓ１３０においてイベントログが分散台帳システム２０－１の分散台帳に登録された場合、イベントログの登録があったことを示す情報を登録通知として生成し、分散台帳システム２０－１に含まれる端末１００の送受信部１８５は当該登録通知を監視端末２００－１に送信する。監視端末２００－１の送受信部１８５は、登録通知を受信する。登録通知は、Ｓ１３０で登録されたイベントログに含まれるキーを含む。したがって、イベントログがログLogA_Xである場合、登録通知はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>を含むものとなる。
　Ｓ２１０において、監視端末２００－１の登録確認要求部２１０は、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログが分散台帳システム２０－２の分散台帳に登録されているか否かを確認するための第１確認要求を生成し、監視端末２００－１の送受信部１８５は当該第１確認要求を分散台帳システム２０－１に含まれる端末１００に送信する。分散台帳システム２０－１に含まれる端末１００の送受信部１８５は、第１確認要求を受信する。第１確認要求は、Ｓ１４０で受信した登録通知に含まれるキーを含む。したがって、第１確認要求はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>を含むものとなる。
　Ｓ１５０において、分散台帳システム２０－１に含まれる端末１００の登録確認要求部１５０は、Ｓ２１０で受信した第１確認要求に含まれるキーを含むイベントログが分散台帳システム２０－２の分散台帳に登録されているか否かを確認するための第２確認要求を生成し、分散台帳システム２０－１に含まれる端末１００の送受信部１８５は当該第２確認要求を分散台帳システム２０－２に含まれる端末１００に送信する。分散台帳システム２０－２に含まれる端末１００の送受信部１８５は、第２確認要求を受信する。第２確認要求は、Ｓ２１０で受信した第１確認要求に含まれるキーを含む。したがって、第２確認要求はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>を含むものとなる。
　Ｓ１６０において、分散台帳システム２０－２に含まれる端末１００の登録確認部１６０は、Ｓ１５０で受信した第２確認要求に含まれるキーを含むイベントログが分散台帳システム２０－２の分散台帳に登録されているか否かを確認し、登録されている場合はＳ１５０で受信した第２確認要求に含まれるキーを含むイベントログが登録されていることを示す情報を第１確認結果として生成し、分散台帳システム２０－２に含まれる端末１００の送受信部１８５は当該第１確認結果を分散台帳システム２０－１に含まれる端末１００に送信する。分散台帳システム２０－１に含まれる端末１００の送受信部１８５は、第１確認結果を受信する。Ｓ１５０で受信した第２確認要求はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>を含むものであり、当該キーを含むイベントログLogB_Xが分散台帳に登録されているため、第１確認結果は当該キーを含むイベントログが登録されていることを示す情報となる。
　Ｓ１７０において、分散台帳システム２０－１に含まれる端末１００の確認結果生成部１７０は、Ｓ１６０で受信した第１確認結果に基づいて第２確認結果を生成し、分散台帳システム２０－１に含まれる端末１００の送受信部１８５は当該第２確認結果を監視端末２００－１に送信する。監視端末２００－１の送受信部１８５は、第２確認結果を受信する。第１確認結果はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムB ID><ユーザβ ID><イベントID>を含むイベントログが登録されていることを示す情報であるため、第２確認結果は当該キーを含むイベントログが登録されていることを示す情報となる。
　Ｓ２２０において、監視端末２００－１の結果確認部２２０は、Ｓ１７０で受信した第２確認結果に基づいて、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログが分散台帳システム２０－２の分散台帳に登録されていることを確認し、処理を終了する。
　Ｓ１４０からＳ２２０までの処理は、分散台帳システム２０－２においても同様に実行される（図６参照）。
（２）イベントログのキーに不整合がない場合のイベントログ不正登録
　以下、図７～図８を参照してイベントログのキーに不整合がない場合のイベントログ不正登録時の分散台帳連携システム１０の動作について説明する。図７、図８は、分散台帳連携システム１０の動作を示すシーケンス図であり、２つの図で分散台帳連携システム１０における一連の動作を示すものである。図７、図８は、２つの分散台帳システム２０（以下、分散台帳システム２０－３、分散台帳システム２０－４とする）による分散台帳連携システム１０の動作を示す図であり、分散台帳システム２０－３はイベントログを登録した分散台帳を運用する分散台帳システム（図５～図６の例でいえば分散台帳システム２０－１または分散台帳システム２０－２）、分散台帳システム２０－４は当該イベントログのイベントに関するイベントログを不正に登録しようとする端末１００－４を含む分散台帳システムである。
　イベントログのキーに不整合がない場合におけるイベントログ不正登録時の分散台帳連携システム１０の動作は、以下の５つの動作から構成される。
（１）イベントログの登録（Ｓ１２０～Ｓ１３０）
（２）イベントログの登録確認（Ｓ１４０～Ｓ２２０）
（３）不正登録の検出（Ｓ２３０）
（４）不正登録検出の通知（Ｓ２４０）
（５）不正登録検出への対応（Ｓ２５０～Ｓ１８０）
　以下、Ｓ１２０～Ｓ１８０の各ステップについて説明する。図７におけるＳ１２０～Ｓ１５０までの動作は、図５～図６におけるＳ１２０～Ｓ１５０までの動作と同様であるので、Ｓ１６０以降のステップについて説明する。なお、ここでは分散台帳システム２０－３が分散台帳システム２０－１であるものとして、説明していく。
　Ｓ１６０において、分散台帳システム２０－３に含まれる端末１００の登録確認部１６０は、Ｓ１５０で受信した第２確認要求に含まれるキーを含むイベントログが分散台帳システム２０－３の分散台帳に登録されているか否かを確認し、登録されていない場合はＳ１５０で受信した第２確認要求に含まれるキーを含むイベントログが登録されていないことを示す情報を第１確認結果として生成し、分散台帳システム２０－３に含まれる端末１００の送受信部１８５は当該第１確認結果を分散台帳システム２０－４に含まれる端末１００に送信する。分散台帳システム２０－４に含まれる端末１００の送受信部１８５は、第１確認結果を受信する。分散台帳システム２０－３が分散台帳システム２０－１である場合、Ｓ１５０で受信した第２確認要求はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>を含むものであり、当該キーを含むイベントログLogA_Xは分散台帳に登録されていないため、第１確認結果は当該キーを含むイベントログが登録されていないことを示す情報となる。
　Ｓ１７０において、分散台帳システム２０－４に含まれる端末１００の確認結果生成部１７０は、Ｓ１６０で受信した第１確認結果に基づいて第２確認結果を生成し、分散台帳システム２０－４に含まれる端末１００の送受信部１８５は当該第２確認結果を監視端末２００－４に送信する。監視端末２００－４の送受信部１８５は、第２確認結果を受信する。第１確認結果はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>を含むイベントログが登録されていないことを示す情報であるため、第２確認結果は当該キーを含むイベントログが登録されていないことを示す情報となる。
　Ｓ２２０において、監視端末２００－４の結果確認部２２０は、Ｓ１７０で受信した第２確認結果に基づいて、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログが分散台帳システム２０－３の分散台帳に登録されていないことを確認する。
　そこで、監視端末２２０－４はＳ２１０の処理に戻る。そして、監視端末２２０－４、分散台帳システム２０－４、分散台帳システム２０－３によるＳ２１０～Ｓ２２０までの処理が繰り返される。
　Ｓ２３０において、監視端末２００－４の不正登録検出部２３０は、Ｓ２１０～Ｓ２２０までの処理を所定の回数だけ繰り返し実行しても、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログが分散台帳システム２０－３の分散台帳に登録されていることが確認できない場合は、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログの登録が不正登録であることを示す情報を不正登録検出結果として生成する。不正登録検出結果はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>を含むものとなる。
　Ｓ２４０において、監視端末２００－４の不正登録通知生成部２４０は、Ｓ２３０で生成された不正登録検出結果に基づいて、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログの登録が不正登録であることを示す情報を不正登録通知として生成し、監視端末２００－４の送受信部１８５は当該不正登録通知を端末１００－４に送信する。端末１００－４の送受信部１８５は、不正登録通知を受信する。不正登録通知はキー<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>を含むものとなる。
　Ｓ２５０において、監視端末２００－４の登録要求部２５０は、Ｓ２３０で生成された不正登録検出結果に基づいて、Ｓ１４０で受信した登録通知に含まれるキーを含むイベントログの登録が不正登録であることを示す情報を不正登録ログとして生成し、当該不正登録ログを含む登録要求を生成し、監視端末２００－４の送受信部１８５は当該登録要求を分散台帳システム２０－４に含まれる端末１００－４に送信する。分散台帳システム２０－４含まれる端末１００－４の送受信部１８５は、登録要求を受信する。不正登録ログは、Ｓ１４０で受信した登録通知に含まれるキー<分散台帳システムA ID><ユーザα ID><分散台帳システムC ID><ユーザγ ID><イベントID>を含むものとなる。
　Ｓ１８０において、分散台帳システム２０－４含まれる端末１００－４の第２ログ登録部１８０は、Ｓ２５０で受信した不正登録ログを記録部１９０に記録（分散台帳システム２０－４の分散台帳に登録）し、不正登録ログの登録が完了したことを示す情報を登録結果として生成し、分散台帳システム２０－４に含まれる端末１００－４の送受信部１８５は当該登録結果を監視端末２００－４に送信する。監視端末２００－４の送受信部１８５は、登録結果を受信する。
（３）イベントログのキーに不整合がある場合のイベントログ不正登録
　以下、図９を参照してイベントログのキーに不整合がある場合のイベントログ不正登録時の分散台帳連携システム１０の動作について説明する。図９は、分散台帳連携システム１０の動作を示すシーケンス図である。図９は、２つの分散台帳システム２０（以下、分散台帳システム２０－５、分散台帳システム２０－６とする）による分散台帳連携システム１０の動作を示す図であり、分散台帳システム２０－５はイベントログを登録した分散台帳を運用する分散台帳システム（図５～図６の例でいえば分散台帳システム２０－１または分散台帳システム２０－２）、分散台帳システム２０－６は当該イベントログのイベントに関するイベントログを不正に登録しようとする端末１００－６を含む分散台帳システムである。
　イベントログのキーに不整合がある場合におけるイベントログ不正登録時の分散台帳連携システム１０の動作は、以下の１つの動作から構成される。
（１）イベントログの登録（Ｓ１２０～Ｓ１３０）
　以下、Ｓ１２０～Ｓ１３０の各ステップについて説明する。図９におけるＳ１２０の動作は、図７におけるＳ１２０の動作と同様であるので、Ｓ１３０のステップについて説明する。
　Ｓ１３０において、分散台帳システム２０－６に含まれる端末１００の第１ログ登録部１３０は、Ｓ１２０の登録要求に含まれるイベントログのキーの整合性を確認し、キーの整合性に問題がある場合はイベントログを記録部１９０に記録（分散台帳システム２０－６の分散台帳に登録）することなく、処理を終了する。イベントログがログLogC_Xである場合、キーは<分散台帳システムC ID><ユーザγ ID><イベントID>であり、事前に合意している形式を満たさない（つまり、整合しない）ため、ログLogC_Xは分散台帳に記録されない。
　本実施形態では、取引の当事者の数は２であるものとして説明したが、＜技術的背景＞で説明したように、２以上であってもよい。
　端末１００、監視端末２００は、以下のようにまとめることができる。
　２以上のユーザ間でのイベントのログを登録する分散台帳連携システム１０に含まれる２以上の分散台帳システム２０のいずれかに含まれる端末１００は、所定のキーを含むイベントのログを当該端末１００が含まれる分散台帳システム２０の分散台帳に登録する第１ログ登録部１３０を含むものであり、所定のキーは当該イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、当該イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、当該イベントを特定するための識別子であるイベント識別子とを含むものであり、所定のキーには２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている。
　２以上のユーザ間でのイベントのログを登録する分散台帳連携システム１０に含まれる２以上の分散台帳システム２０のいずれかに対応付けられる監視端末２００は、登録が正当なものであるか否かを確認したいイベントのログに含まれるキーが、当該監視端末２００が対応付けられている分散台帳システム２０の分散台帳に登録されている、正当なイベントのログに含まれる所定のキーのいずれとも一致することが確認できない場合は、当該イベントのログは不正登録されたものであると判断する不正登録検出部２３０を含むものであり、正当なイベントのログに含まれる所定のキーは当該イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、当該イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、当該イベントを特定するための識別子であるイベント識別子とを含むものであり、正当なイベントのログに含まれる所定のキーには当該イベントの当事者である２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている。
　本発明の実施形態によれば、同一の分散台帳を利用していないユーザ間の取引の履歴を記録することが可能となる。また、取引の当事者ではないユーザによる不正登録を防ぐことが可能となる。さらに、取引の当事者ではないユーザによる登録は不正なものであることを検出することが可能となる。
＜補記＞
　本明細書中に記載されている構成要素により実現される機能は、当該記載された機能を実現するようにプログラムされた、汎用プロセッサ、特定用途プロセッサ、集積回路、ＡＳＩＣｓ(Application Specific Integrated Circuits)、ＣＰＵ(Central Processing Unit)、従来型の回路、および／又はそれらの組合せを含む、circuitry又はprocessing circuitryにおいて実装されてもよい。プロセッサは、トランジスタやその他の回路を含み、circuitry又はprocessing circuitryとみなされる。プロセッサは、メモリに格納されたプログラムを実行する、programmed processorであってもよい。
　本明細書において、circuitry、ユニット、手段は、記載された機能を実現するようにプログラムされたハードウェア、又は実行するハードウェアである。当該ハードウェアは、本明細書に開示されているあらゆるハードウェア、又は、当該記載された機能を実現するようにプログラムされた、又は、実行するものとして知られているあらゆるハードウェアであってもよい。
　当該ハードウェアがcircuitryのタイプであるとみなされるプロセッサである場合、当該circuitry、手段、又はユニットは、ハードウェアと、当該ハードウェア及び又はプロセッサを構成する為に用いられるソフトウェアの組合せである。
　上述の各種の処理は、図１０に示すコンピュータ２０００の記録部２０２０に、上記方法の各ステップを実行させるプログラムを読み込ませ、制御部２０１０、入力部２０３０、出力部２０４０、表示部２０５０などに動作させることで実施できる。
　この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。
　また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ－ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
　このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記憶装置に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって処理を実行する構成としてもよい。さらには、サーバコンピュータの一部をプログラムと共にユーザに使用させる、いわゆるＳａａＳ（Software as a Service）型のサービスを利用して、端末の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
　また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
　本発明は上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。また、上記実施形態において説明した処理は、記載の順に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されるとしてもよい。

Claims (4)

  1. 　２以上の分散台帳システム（ただし、各分散台帳システムは１以上の端末を含む）を含む分散台帳連携システムが２以上のユーザ間でのイベントのログを登録する分散台帳連携方法であって、
    　前記端末が、所定のキーを含む前記イベントのログを当該端末が含まれる分散台帳システムの分散台帳に登録するステップを実行するものであり、
    　前記所定のキーは前記イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、前記イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、前記イベントを特定するための識別子であるイベント識別子とを含むものであり、前記所定のキーには前記２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている
    　分散台帳連携方法。
  2. 　２以上のユーザ間でのイベントのログを登録する、２以上の分散台帳システム（ただし、各分散台帳システムは１以上の端末を含む）を含む分散台帳連携システムであって、
    　前記端末は、所定のキーを含む前記イベントのログを当該端末が含まれる分散台帳システムの分散台帳に登録する第１ログ登録部を含むものであり、
    　前記所定のキーは前記イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、前記イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、前記イベントを特定するための識別子であるイベント識別子とを含むものであり、前記所定のキーには前記２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている
    　分散台帳連携システム。
  3. 　２以上のユーザ間でのイベントのログを登録する分散台帳連携システムに含まれる２以上の分散台帳システムのいずれかに含まれる端末であって、
    　所定のキーを含む前記イベントのログを当該端末が含まれる分散台帳システムの分散台帳に登録する第１ログ登録部を含み、
    　前記所定のキーは前記イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、前記イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、前記イベントを特定するための識別子であるイベント識別子とを含むものであり、前記所定のキーには前記２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている
    　端末。
  4. 　２以上のユーザ間でのイベントのログを登録する分散台帳連携システムに含まれる２以上の分散台帳システムのいずれかに対応付けられる監視端末であって、
    　登録が正当なものであるか否かを確認したいイベントのログに含まれるキーが、当該監視端末が対応付けられている分散台帳システムの分散台帳に登録されている、正当なイベントのログに含まれる所定のキーのいずれとも一致することが確認できない場合は、前記イベントのログは不正登録されたものであると判断する不正登録検出部を含み、
    　前記正当なイベントのログに含まれる所定のキーは当該イベントのデータを送信するユーザを特定するための識別子であるイベント元識別子と、当該イベントのデータを受信するユーザを特定するための識別子であるイベント先識別子と、当該イベントを特定するための識別子であるイベント識別子とを含むものであり、前記正当なイベントのログに含まれる所定のキーには当該イベントの当事者である２以上のユーザの各ユーザを特定するためのイベント元識別子、イベント先識別子のいずれかが含まれている
    　監視端末。
PCT/JP2024/015094 2024-04-16 2024-04-16 分散台帳連携方法、分散台帳連携システム、端末、監視端末 Pending WO2025220103A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/015094 WO2025220103A1 (ja) 2024-04-16 2024-04-16 分散台帳連携方法、分散台帳連携システム、端末、監視端末

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2024/015094 WO2025220103A1 (ja) 2024-04-16 2024-04-16 分散台帳連携方法、分散台帳連携システム、端末、監視端末

Publications (1)

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

Family

ID=97403177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/015094 Pending WO2025220103A1 (ja) 2024-04-16 2024-04-16 分散台帳連携方法、分散台帳連携システム、端末、監視端末

Country Status (1)

Country Link
WO (1) WO2025220103A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020161092A (ja) * 2019-03-28 2020-10-01 株式会社日立製作所 システム間連携方法およびノード
JP7080410B1 (ja) * 2021-04-28 2022-06-03 三菱電機株式会社 データ検証装置、データ検証方法、及び、データ検証プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020161092A (ja) * 2019-03-28 2020-10-01 株式会社日立製作所 システム間連携方法およびノード
JP7080410B1 (ja) * 2021-04-28 2022-06-03 三菱電機株式会社 データ検証装置、データ検証方法、及び、データ検証プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHIKADA, MASAYOSHI ET AL.: "Cross-organizational document sharing system utilizing blockchains", IEICE TECHNICAL REPORT, vol. 119, no. 123 (LOIS2019-3 ), 10 July 2019 (2019-07-10), pages 7 - 12, XP009537069 *

Similar Documents

Publication Publication Date Title
EP3629272B1 (en) Method and device for running chaincode
CN111144881B (zh) 对资产转移数据的选择性访问
CN112994892B (zh) 跨链交互方法、装置、系统和电子设备
CN108665372B (zh) 基于区块链的信息处理、查询、储存方法和装置
JP7672499B2 (ja) クロスチェーントランザクション処理方法と装置、電子機器及びコンピュータプログラム
CN101595668B (zh) 建立协调定时网络中的服务器之间的逻辑路径的方法和系统
US10833845B2 (en) Guarantee of ledger immutability
JP7228322B2 (ja) ブロックチェーン・ネットワークにおける自動コミット・トランザクション管理
JP2022524996A (ja) ブロックチェーンの使用方法
CN111798233B (zh) 令牌的链接
CN113689216A (zh) 跨链事务处理方法及装置、设备、存储介质、程序产品
CN114255031A (zh) 用于执行交易的跨区块链的系统、跨链交易方法及设备
CN111541784A (zh) 一种基于区块链一体机的交易处理方法及装置
CN111753009B (zh) 包括快速路径服务的分散式数据库中的信息管理
CN112612856B (zh) 基于区块链的数据处理方法和装置
JP7254585B2 (ja) システム間連携方法およびノード
US20200076608A1 (en) Guarantee of ledger immutability
US12450615B2 (en) Method, terminal, and coin register for transmitting electronic coin data sets
US20250106053A1 (en) Blockchain Network Management Method and Related Device
CN115983850B (zh) 基于区块链的设备控制方法和相关设备
US11769147B2 (en) Secure smart note
US20200074423A1 (en) Secure smart note
CN118797740B (zh) 数据交互系统以及数据交互方法
CN111198773B (zh) 基于消息的应用通信方法及设备
CN112053155A (zh) 社群决策方法、设备和存储介质

Legal Events

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

Ref document number: 24936016

Country of ref document: EP

Kind code of ref document: A1