[go: up one dir, main page]

WO2024089773A1 - Dispositif de gestion de données et procédé de gestion de données - Google Patents

Dispositif de gestion de données et procédé de gestion de données Download PDF

Info

Publication number
WO2024089773A1
WO2024089773A1 PCT/JP2022/039769 JP2022039769W WO2024089773A1 WO 2024089773 A1 WO2024089773 A1 WO 2024089773A1 JP 2022039769 W JP2022039769 W JP 2022039769W WO 2024089773 A1 WO2024089773 A1 WO 2024089773A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
record
distributed ledger
control device
hash value
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.)
Ceased
Application number
PCT/JP2022/039769
Other languages
English (en)
Japanese (ja)
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.)
Toyota Motor Corp
Scalar Inc
Original Assignee
Toyota Motor Corp
Scalar Inc
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 Toyota Motor Corp, Scalar Inc filed Critical Toyota Motor Corp
Priority to CN202280101160.8A priority Critical patent/CN120077379A/zh
Priority to PCT/JP2022/039769 priority patent/WO2024089773A1/fr
Publication of WO2024089773A1 publication Critical patent/WO2024089773A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

  • This disclosure relates to a data management device and a data management method that manage data using distributed ledger technology.
  • Patent Document 1 discloses a data management system that configures a distributed ledger (asset) with a Directed Acyclic Graph (DAG) structure for each key (ID) used to identify managed objects, and manages information for each ID.
  • DAG Directed Acyclic Graph
  • the present disclosure has been made to solve the above problems, and the purpose of the disclosure is to make it easy to prove the ordering of data between distributed ledgers in a system that has multiple distributed ledgers.
  • a data management device is a data management device that manages data using distributed ledger technology.
  • the data management device includes a storage device that stores a distributed ledger that chronologically stores records including information about the data, and a control device that adds records to the distributed ledger.
  • the data includes first data and second data.
  • the distributed ledger includes a first distributed ledger that chronologically stores records including first information about the first data, and a second distributed ledger that chronologically stores records including second information about the second data.
  • the control device stores a record including the first information in the first distributed ledger, generates a first terminal value including information about the record, and stores a record including the first terminal value in the second distributed ledger.
  • the first terminal value is stored in the second distributed ledger.
  • the first terminal value is a hash value of a record stored in the first distributed ledger at a first time.
  • the hash value of a record in the first distributed ledger is stored in a record in the second distributed ledger, making it possible to associate the first distributed ledger with the second distributed ledger without excessively increasing data volume.
  • the first information is a hash value of the first data.
  • the second information is a hash value of the second data.
  • the records stored in the first distributed ledger and the second distributed ledger contain the hash value of the first data and the hash value of the second data, so that the first data and the second data themselves can be kept confidential.
  • control device stores a record including the first terminal value in the second distributed ledger based on a request from the user.
  • a user can associate the first distributed ledger with the second distributed ledger at any time.
  • the data management device further includes a communication device configured to be able to communicate with a time stamp authority.
  • the control device transmits a second terminal value including information about the record at the end of the second distributed ledger to the time stamp authority via the communication device, and obtains a time stamp token for the second terminal value from the time stamp authority.
  • a timestamp token is obtained for the second terminal value. This makes it possible to prove the order of the first data and the second data based on the first point in time, while also making it possible to prove the timestamp of the first data and the second data based on the second point in time.
  • control device obtains the timestamp token based on a request from a user.
  • the user can obtain a timestamp token at any time.
  • a data management method is a data management method of a data management device that manages data using distributed ledger technology.
  • the data management device includes a storage device that stores a distributed ledger that chronologically stores records including information about the data, and a control device that adds records to the distributed ledger.
  • the data includes first data and second data.
  • the distributed ledger includes a first distributed ledger that chronologically stores records including first information about the first data, and a second distributed ledger that chronologically stores records including second information about the second data.
  • the data management method includes a step in which, upon updating the first data at a predetermined time, the control device stores a record including the first information in the first distributed ledger and generates a first terminal value including information about the record, and stores a record including the first terminal value in the second distributed ledger.
  • FIG. 1 is a diagram showing a schematic configuration of a data management system according to a first embodiment
  • FIG. 1 is a diagram showing an example of the configuration of a distributed ledger set (part 1).
  • FIG. 1 is a diagram to explain the association of two distributed ledgers.
  • FIG. 2 is a diagram showing an example of the configuration of a distributed ledger set (part 2).
  • FIG. 4 is a functional block diagram of a control device for executing a process in response to a first operation.
  • FIG. 11 is a functional block diagram of a control device for executing a process in response to a second operation.
  • FIG. 4 is a functional block diagram of a control device for executing received transaction data.
  • FIG. 2 is a functional block diagram of a control device for acquiring a time stamp token.
  • FIG. 13 is a flowchart showing a procedure for generating transaction data when a first request is received.
  • 13 is a flowchart showing a procedure for generating transaction data when a second request is received.
  • 11 is a flowchart showing a procedure of a process executed when transaction data is received.
  • 13 is a flowchart showing a procedure for a process of acquiring a time stamp token.
  • FIG. 11 is a diagram showing a schematic configuration of a data management system according to a second embodiment.
  • 4A and 4B are diagrams illustrating an example of a configuration of a suspension table.
  • FIG. 13 is a diagram illustrating an example of the configuration of a commit table.
  • 13 is a flowchart showing a procedure of a process executed in the data management system when an update request (first request, second request) is received.
  • 13 is a flowchart showing a procedure of a process for acquiring a time stamp token in
  • FIG. 1 is a diagram showing a schematic configuration of a data management system 1 according to the first embodiment.
  • the data management system 1 according to the first embodiment is a system for forming a consortium network (hereinafter also simply referred to as a "network”) NW among a plurality of companies and managing data using a distributed ledger technology.
  • the data management system 1 according to the first embodiment manages data of parts constituting a vehicle (hereinafter also simply referred to as "parts data").
  • the parts data may be, for example, a specification of the parts.
  • the data managed by the data management system 1 is not limited to data of parts constituting a vehicle, and may be various types of data.
  • the data management system 1 includes four client servers 2, a platform server 5, and a Time Stamp Authority (TSA) 8.
  • Each of the four client servers 2 belongs to a different company (e.g., company A, company B, company C, and company D).
  • the platform server 5 manages the network NW.
  • the platform server 5 accepts applications from each client server 2 to join the network NW.
  • the platform server 5 permits the client server 2 to join the network NW based on an operation by the platform server 5 administrator to permit participation, or based on the results of judging predetermined conditions.
  • four client servers 2 belonging to each of companies A, B, C, and D are permitted to join the network NW.
  • the four client servers 2 form a network NW, and store hash values of part data in their respective distributed ledgers.
  • Distributed ledger platform software is installed in each of the client servers 2, and each client server 2 functions as a node as a result of the installed distributed ledger platform software functioning.
  • the client server 2 of Company A will be described as a representative example, but the client servers of Company B, Company C, and Company D also have the same configuration and function.
  • the client server 2 corresponds to an example of a "data management device" according to the present disclosure.
  • the client server 2 is configured to be able to communicate with a user terminal device 7.
  • the user terminal device 7 is, for example, a desktop PC (Personal Computer), a notebook PC, a tablet terminal, a smartphone, or any other information processing terminal with communication capabilities, loaned to an employee of Company A.
  • a database 4 is connected to the client server 2.
  • the database 4 stores part data.
  • the database 4 stores and updates the part data in accordance with control signals from the client server 2.
  • a user of the client server 2 e.g., an employee of Company A
  • the client server 2 (control device 21) generates a control signal for storing/updating the part data in response to an input to the input device 25 or a request from the user terminal device 7, and outputs the control signal to the database 4.
  • the client server 2 When the client server 2 stores/updates part data in the database 4, it generates a hash value of the part data and generates transaction data for storing the hash value in the distributed ledger. The client server 2 then transmits the generated transaction data to the other client servers 2 that form the network NW, i.e., the client servers 2 of companies B, C, and D.
  • the distributed ledger stores the hash values of the part data in chronological order, forming an evidence chain for proving the existence of the part data. Note that, in the data management system 1 according to the first embodiment, an example in which the network NW includes four client servers will be described, but the number of client servers 2 included in the network NW is arbitrary and may be, for example, less than four or five or more.
  • the time-stamp authority 8 includes a server belonging to a certification authority that issues time-stamp tokens.
  • the time-stamp authority issues a time-stamp token in response to a time-stamp issuance request from an applicant (in the first embodiment, the client server 2). More specifically, the time-stamp authority transmits to the applicant a time-stamp token that combines data received from the applicant (in the first embodiment, a record hash value, described below) with time information based on a time source that is traceable to international standard time.
  • the client server 2 includes a control device 21, a ROM (Read Only Memory) 22, a RAM (Random Access Memory) 23, a communication device 24, an input device 25, a display device 26, and a storage device 27.
  • the control device 21, the ROM 22, the RAM 23, the communication device 24, the input device 25, the display device 26, and the storage device 27 are connected to a bus 29.
  • the control device 21 is formed, for example, by an integrated circuit including a CPU (Central Processing Unit).
  • the control device 21 deploys various programs stored in the ROM 22 into the RAM 23 and executes them.
  • the various programs include an operating system, etc.
  • the RAM 23 functions as a working memory and temporarily stores various data required for the execution of the various programs.
  • the control device 21 has the function of updating part data recorded in the database 4, generating transaction data for updating the distributed ledger, and acquiring timestamp tokens.
  • the communication device 24 is configured to be capable of communicating with external devices.
  • External devices include, for example, other client servers 2, user terminal devices 7, and time certification authorities 8.
  • Communication between the communication device 24 and external devices is performed using the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet (registered trademark) network, a public network, a private network, a wired network, a wireless network, or the like, or a combination of these.
  • WAN wide area network
  • LAN local area network
  • Ethernet registered trademark
  • the input device 25 includes an input device.
  • the input device is, for example, a mouse, a keyboard, a touch panel, and/or other device capable of receiving user operations.
  • the display device 26 includes a display.
  • the display device 26 displays various images on the display in accordance with control signals from the control device 21.
  • the display is, for example, a liquid crystal display, an organic EL (Electro Luminescence) display, or other display device.
  • the storage device 27 includes a storage medium such as a hard disk or a flash memory.
  • the storage device 27 stores a private key 271, a plurality of public keys 272, and a distributed ledger set 50.
  • the private key 271 is the private key of Company A.
  • control device 21 when client server 2 first joins network NW, control device 21 generates a private key and a public key. Then, control device 21 sends the generated public key to a certification authority (not shown) for authentication.
  • a certification authority is a certification body that issues electronic certificates. The certification authority issues an electronic certificate that includes information about the public key.
  • Control device 21 stores private key 271 corresponding to the authenticated public key in storage device 27. Control device 21 also sends authenticated public keys (electronic certificates) 272 to client servers 2 of companies B, C, and D.
  • the multiple public keys 272 include the public key of Company B, the public key of Company C, and the public key of Company D.
  • the control device 21 stores the public keys received from the other client servers 2 in the storage device 27.
  • the storage device 27 may also store its own (Company A's) public key.
  • the distributed ledger set 50 includes multiple distributed ledgers.
  • a distributed ledger is prepared for each part that constitutes a vehicle.
  • FIG. 2 is a diagram showing an example of the configuration of the distributed ledger set 50.
  • the distributed ledger set 50 includes a distributed ledger 51 that stores the update state of the part data of the first part in chronological order and serves as an evidence chain for the part data of the first part, and a distributed ledger 52 that stores the update state of the part data of the second part in chronological order and serves as an evidence chain for the part data of the second part.
  • the distributed ledger set 50 includes N distributed ledgers.
  • the parts whose data are managed in the distributed ledger are also referred to as "target parts". That is, the target parts in the first embodiment are the first part and the second part.
  • the distributed ledger 51 stores records in chronological order, each record including a hash value of the part data of the first part.
  • the records include the following information: "Key”, “Age”, “Obj-HV”, “Nonce”, “Sig”, “Prev-HV”, and "HV”.
  • Key is information that indicates the ID of the target part (first part).
  • the first part is assigned an ID of k1.
  • Age is information that indicates the generation of a record.
  • Age is 0.
  • Age is incremented.
  • Obj-HV is the hash value of the part data of the first part. For example, when the part data of the first part registered in the database 4 is updated, a hash value of the updated part data is generated and used as Obj-HV.
  • the hash value is a numerical value obtained as a result of hashing the part data using a hash function.
  • Nonce is a nonce value that indicates the number of transaction data.
  • the nonce value is generated by the client server 2 (control device 21) as a processing number for storing the hash value of the updated part data in the distributed ledger 51.
  • the nonce value is a hash value that is cryptographically difficult to collide with.
  • Sig is an electronic signature created using the private key 271 of the client server 2 that issued the transaction data.
  • the electronic signature is created, for example, by encrypting Obj-HV (i.e., the hash value of the part data of the first part) with the private key 271.
  • Obj-HV i.e., the hash value of the part data of the first part
  • the electronic signature may be created, for example, by encrypting a Nonce (nonce value) with the private key 271.
  • Prev-HV is the hash value of the record (parent record) of the generation before the latest (end) record.
  • Prev-HV is the HV of the parent record.
  • HV is the hash value of the latest (end) record. Specifically, HV is the hash value (hereinafter also referred to as the "record hash value") of the record information excluding HV (Key, Age, Obj-HV, Nonce, Sig, and Prev-HV).
  • the Prev-HV of the terminal record is "H2", which is the HV of the parent record (Age "1"). If the part data for the first part is then updated and a record with Age "3" is added, the Prev-HV of the record with Age “3” becomes "H3", which is the HV of the record with Age "2".
  • the terminal record has a structure that includes the record hash value of the parent record. In other words, a chain of records is realized between the Prev-HV of the terminal record and the HV of the parent record. In this way, the distributed ledger 51 has a DAG structure.
  • Distributed ledger 52 stores records in chronological order, each of which includes a hash value of part data for the second part.
  • the records include the following information: "Key”, “Age”, “Obj-HV”, “Nonce”, “Sig”, “Prev-HV”, and “HV”. Details of these are similar to those of the records in distributed ledger 51, and will not be described again.
  • the client server 2 When the client server 2 (control device 21) receives an update operation for part data via, for example, the input device 25 or the user terminal device 7, it updates the part data stored in the database 4.
  • the client server 2 (control device 21) then generates transaction data for adding a record including the hash value of the updated part data to the distributed ledger set 50 (distributed ledger 51 or distributed ledger 52).
  • This transaction data includes the information "Key”, “Age”, “Obj-HV", “Nonce”, “Sig”, “Prev-HV", and "HV".
  • the transaction data may further include time information when the transaction data is broadcast to the network NW (sent to the network NW), and sender information of the transaction data.
  • the time information may be, for example, information indicating the time when the part data of the target part was recorded in database 4.
  • the sender information is, for example, information indicating Company A.
  • the sender information of the transaction data may be information indicating the department (a division of Company A) that performed the operation to send the transaction data to the network NW, or information indicating an individual (an employee of Company A) that performed the operation to send the transaction data to the network NW.
  • ⁇ Proof of ordering> there are cases where it is desired to prove which data existed first between the part data of the first part and the part data of the second part. That is, there are cases where it is desired to prove the order of the part data of the first part and the part data of the second part.
  • a timestamp token is obtained for the record hash value of the added record (terminal record), thereby proving the time when the record was added and proving the order of the two data.
  • a timestamp token must be obtained each time a record is added to the distributed ledgers 51 and 52, which increases the labor and cost.
  • the processing load on the data management system 1 also increases.
  • the data management system 1 it is possible to incorporate a record hash value of one distributed ledger (e.g., distributed ledger 51) into a record of the other distributed ledger (e.g., distributed ledger 52). This associates the two distributed ledgers 51 and 52.
  • distributed ledger 51 distributed ledger
  • distributed ledger 52 distributed ledger
  • Figure 3 is a diagram for explaining the association of two distributed ledgers 51, 52.
  • the upper part of Figure 3 shows a schematic representation of distributed ledger 51, which is the evidence chain of the first part
  • the lower part of Figure 3 shows a schematic representation of distributed ledger 52, which is the evidence chain of the second part.
  • the evidence chain of the first part is also referred to as the "first evidence chain”
  • the evidence chain of the second part is also referred to as the "second evidence chain.”
  • the first evidence chain stores hash values of the part data of the first part in chronological order.
  • a record (Age "0") containing the hash value of that part data is stored in the distributed ledger 51.
  • a record (Age "1") containing the hash value of the updated part data and the record hash value of the parent record (Age "0") is stored in the distributed ledger 51.
  • a record (Age "2") containing the hash value of the updated part data and the record hash value of the parent record (Age "1") is stored in the distributed ledger 51.
  • the second evidence chain stores hash values of the part data of the second part in chronological order.
  • a record (Age "0") containing the hash value of that part data is stored in the distributed ledger 52.
  • a record (Age "1") containing the hash value of the updated part data and the record hash value of the parent record (Age "0") is stored in the distributed ledger 52.
  • a record (Age "2") containing the hash value of the updated part data and the record hash value of the parent record (Age "1") is stored in the distributed ledger 52.
  • the record with Age "2" is the latest (end) record in each of distributed ledger 51 and distributed ledger 52. It is assumed that in this state, a first operation to update the part data of the first part has been performed on input device 25 or user terminal device 7. It is further assumed that in addition to the first operation, a second operation to associate the first evidence chain with the second evidence chain has been performed on input device 25 or user terminal device 7.
  • the operation to update the part data may be, for example, an operation of inputting the ID (Key) of the target part on the display screen of display device 26 or user terminal device 7 and selecting the displayed update button.
  • the operation to associate evidence chains may be an operation of inputting the IDs (Key) of two target parts and selecting the displayed association button.
  • the display screen for performing the second operation is provided with, for example, a "creation target input field" for inputting the ID (key) of the target part for which a record hash value is to be created, and an "incorporation target input field” for inputting the ID (key) of the target part into which the record hash value is to be incorporated.
  • k1 into the creation target input field and k2 into the incorporation target input field
  • the record hash value of the first evidence chain distributed ledger 51
  • k2 has been input into the incorporation target input field.
  • the display screen for performing the first operation and the display screen for performing the second operation may be displayed simultaneously on the same screen.
  • the control device 21 first updates the part data D12 of the first part stored in the database 4 to part data D13 in response to the first operation.
  • the control device 21 can newly store the part data of the first part in the database 4.
  • the control device 21 creates a record (Age "3") including the hash value of the part data D13 and the record hash value of the parent record (Age "2"), and stores it in the distributed ledger 51.
  • the control device 21 also generates transaction data for adding the record of Age "3" to the distributed ledger 51.
  • the control device 21 transmits the generated transaction data to the client servers 2 of the B, C, and D companies via the communication device 24. As the transaction processing that executes this transaction data is performed on each client server 2, a record with Age "3" is stored in the distributed ledger 51 of each client server 2.
  • the control device 21 generates a hash value of the terminal record (Age "3") of the distributed ledger 51 as a "terminal hash value".
  • the terminal hash value is the record hash value of the terminal record (Age "3").
  • the control device 21 creates a record (Age "3") including the generated terminal hash value and the record hash value of the parent record (Age "2") of the distributed ledger 52, and stores it in the distributed ledger 52.
  • the terminal hash value of the distributed ledger 51 is incorporated into the record (Age "3") of the distributed ledger 52, thereby associating the distributed ledger 51 with the distributed ledger 52.
  • the control device 21 also generates transaction data for adding the record of Age "3" to the distributed ledger 52.
  • the control device 21 transmits the generated transaction data to the client servers 2 of Company B, Company C, and Company D via the communication device 24.
  • the distributed ledgers 51 and 52 are associated with each other in the distributed ledger set 50 of each client server 2.
  • FIG 4 is a diagram showing an example of the configuration of distributed ledger set 50.
  • the record of Age "3" in distributed ledger 52 contains hash value Hc and hash value H4 as Pre-HV.
  • Hash value Hc is the record hash value of the parent record (Age "2")
  • hash value H4 is the record hash value (terminal hash value) of the record (Age "3") in distributed ledger 51.
  • distributed ledger 51 and distributed ledger 52 are associated (the first evidence chain and the second evidence chain are associated). This makes it possible to prove the ordering of the part data of the first part and the part data of the second part. With reference to FIG. 3, for example, it can be proven that part data D13 of the first part is registered in database 4 after part data D22 of the second part is registered in database 4 and before part data D23 of the second part is registered in database 4.
  • a timestamp token is obtained for the record hash value of Age "3" in distributed ledger 52, it can be proven that the component data D10-D13 of the first part existed and that the component data D20-D22 of the second part existed at the time proven by the timestamp token. This can reduce labor, costs, system load, etc. compared to the case where a timestamp token is obtained for each record in distributed ledger 51 and 52. In other words, if a timestamp token is obtained for the record hash value of the record of Age "3" in distributed ledger 52 into which the terminal hash value of distributed ledger 51 is incorporated, the order and time of the existence of the component data of the first part and the component data of the second part can be guaranteed.
  • a record (Age "4") containing the hash value of part data D14 and the record hash value of Age “3" in distributed ledger 51 is added to distributed ledger 51.
  • a record (Age "4") containing the hash value of part data D23 and the record hash value of Age "3" in distributed ledger 52 is added to distributed ledger 52.
  • Fig. 5 is a functional block diagram of control device 21 for executing a process in response to a first operation.
  • control device 21 includes information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106.
  • Control device 21 functions as information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106, for example, by executing a program stored in ROM 22.
  • information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106 may be realized by, for example, dedicated hardware (electronic circuit).
  • the input device 25 or the user terminal device 7 When a first operation for updating the part data of a first part is performed on the input device 25 or the user terminal device 7, the input device 25 or the user terminal device 7 outputs a first request indicating that the first operation has been performed.
  • the information acquisition unit 2101 acquires a first request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 operates the input device 25 to save (register/update) part data of a target part in the database 4, the first request is input to the information acquisition unit 2101.
  • the first request includes an ID (Key) for identifying the target part.
  • the information acquisition unit 2101 acquires the first request, it outputs the first request to the hash generation unit 2102 and the nonce generation unit 2103.
  • the hash generation unit 2102 When the hash generation unit 2102 receives the first request, it reads the part data of the target part from the database 4, for example, and generates a hash value of the part data. The hash generation unit 2102 outputs the generated hash value and the ID of the target part to the digital signature unit 2104 and the transaction data generation unit 2105.
  • the nonce generation unit 2103 When the nonce generation unit 2103 receives the first request, it generates a nonce value.
  • the nonce value is a hash value that is cryptographically unlikely to collide.
  • the nonce generation unit 2103 outputs the generated nonce value and the ID of the target part to the transaction data generation unit 2105. Note that when a nonce value is used to create a digital signature, the nonce generation unit 2103 may output the nonce value and the ID of the target part to the digital signature unit 2104.
  • the electronic signature unit 2104 reads the private key 271 from the storage device 27.
  • the electronic signature unit 2104 creates an electronic signature by encrypting the hash value received from the hash generation unit 2102 with the private key 271.
  • the electronic signature unit 2104 outputs the created electronic signature and the ID of the target part to the transaction data generation unit 2105.
  • the electronic signature unit 2104 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2103 with the private key 271.
  • the electronic signature unit 2104 may also create an electronic signature by encrypting the hash value and the nonce value with the private key 271.
  • the transaction data generation unit 2105 generates transaction data to be sent to the network NW.
  • the transaction data generation unit 2105 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
  • the transaction data generation unit 2105 recognizes the Age of the parent record by querying the distributed ledger set 50 for the Key, and increments the Age of the parent record to set it as the Age of the record to be added.
  • the transaction data generation unit 2105 sets the hash value generated by the hash generation unit 2102 as Obj-HV, the nonce value generated by the nonce generation unit 2103 as Nonce, and the electronic signature created by the electronic signature unit 2104 as Sig.
  • the transaction data generation unit 2105 also sets the record hash value of the parent record as Prev-HV.
  • the transaction data generation unit 2105 hashes the information of Key, Age, Obj-HV, Nonce, Sig, and Prev-HV to generate HV.
  • the transaction data may further include time information when the transaction data is broadcast (sent to the network NW) to the network NW, and sender information of the transaction data.
  • the transaction data generation unit 2105 outputs the generated transaction data to the transaction data transmission unit 2106.
  • the transaction data transmission unit 2106 outputs a control signal to the communication device 24 to transmit the transaction data to the network NW. As a result, the transaction data is transmitted to the network NW via the communication device 24.
  • FIG. 6 is a functional block diagram of the control device 21 for executing a process responsive to the second operation.
  • the control device 21 includes an information acquisition unit 2111, a terminal hash generation unit 2112, a nonce generation unit 2113, a digital signature unit 2114, a transaction data generation unit 2115, and a transaction data transmission unit 2116.
  • the control device 21 functions as the information acquisition unit 2111, the terminal hash generation unit 2112, the nonce generation unit 2113, the digital signature unit 2114, the transaction data generation unit 2115, and the transaction data transmission unit 2116, for example, by executing a program stored in the ROM 22.
  • the information acquisition unit 2111, the terminal hash generation unit 2112, the nonce generation unit 2113, the digital signature unit 2114, the transaction data generation unit 2115, and the transaction data transmission unit 2116 may be realized, for example, by dedicated hardware (electronic circuitry).
  • the input device 25 or the user terminal device 7 When a second operation is performed on the input device 25 or the user terminal device 7 to associate the first evidence chain (distributed ledger 51) with the second evidence chain (distributed ledger 52), the input device 25 or the user terminal device 7 outputs a second request indicating that the second operation has been performed.
  • the information acquisition unit 2111 acquires the second request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 operates the input device 25 to select an association button that associates evidence chains with each other in addition to the first operation (performing a second operation), the second request is input to the information acquisition unit 2111.
  • the second request includes the ID (e.g., k1) of the target part for which a terminal hash value is to be created, and the ID (e.g., k2) of the target part into which the terminal hash value is to be incorporated.
  • the information acquisition unit 2111 acquires the second request, it outputs the second request to the terminal hash generation unit 2112 and the nonce generation unit 2113.
  • the terminal hash generation unit 2112 generates, as a terminal hash value, a hash value of the latest record (the record at the end of the evidence chain) in a distributed ledger (e.g., distributed ledger 51) identified by the ID of the target component for which the terminal hash value is to be created.
  • the terminal hash generation unit 2112 outputs the generated terminal hash value and the ID of the target component into which the terminal hash value is to be incorporated (e.g., k2) to the electronic signature unit 2114 and the transaction data generation unit 2115.
  • the nonce generation unit 2113 When the nonce generation unit 2113 receives the second request, it generates a nonce value.
  • the nonce generation unit 2113 outputs the generated nonce value and the ID (e.g., k2) of the target component into which the terminal hash value is to be incorporated to the transaction data generation unit 2115.
  • the nonce generation unit 2113 may output the nonce value and the ID (e.g., k2) of the target component into which the terminal hash value is to be incorporated to the electronic signature unit 2114.
  • the electronic signature unit 2114 reads the private key 271 from the storage device 27.
  • the electronic signature unit 2114 creates an electronic signature by encrypting the terminal hash value received from the terminal hash generation unit 2112 with the private key 271.
  • the electronic signature unit 2114 outputs the created electronic signature and the ID (e.g. k2) of the target component into which the terminal hash value is to be incorporated to the transaction data generation unit 2115.
  • the electronic signature unit 2114 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2113 with the private key 271.
  • the electronic signature unit 2114 may also create an electronic signature by encrypting the terminal hash value and the nonce value with the private key 271.
  • the transaction data generation unit 2115 generates transaction data to be transmitted to the network NW. For example, the transaction data generation unit 2115 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2115 sets the ID (e.g., k2) of the target component into which the termination hash value is to be incorporated as the Key. The transaction data generation unit 2115 also sets the termination hash value generated by the termination hash generation unit 2112 as the Obj-HV. Other functions of the transaction data generation unit 2115 are basically the same as those of the transaction data generation unit 2105 described in FIG. 5.
  • the transaction data transmission unit 2116 outputs a control signal to the communication device 24 to transmit the transaction data to the network NW. As a result, the transaction data is transmitted to the network NW via the communication device 24.
  • FIG. 7 is a functional block diagram of the control device 21 for executing received transaction data.
  • the control device 21 includes a transaction data acquisition unit 2121, a signature verification unit 2122, a record creation unit 2123, a ledger update unit 2124, and an output unit 2125.
  • the control device 21 functions as the transaction data acquisition unit 2121, the signature verification unit 2122, the record creation unit 2123, the ledger update unit 2124, and the output unit 2125, for example, by executing a program stored in the ROM 22.
  • the transaction data acquisition unit 2121, the signature verification unit 2122, the record creation unit 2123, the ledger update unit 2124, and the output unit 2125 may be realized, for example, by dedicated hardware (electronic circuitry).
  • the transaction data acquisition unit 2121 acquires transaction data sent from other client servers 2.
  • the transaction data acquisition unit 2121 outputs the acquired transaction data to the signature verification unit 2122.
  • the signature verification unit 2122 verifies the validity of the electronic signature (Sig) included in the transaction data. First, the signature verification unit 2122 identifies the client server 2 that sent the transaction data based on the sender information included in the transaction data. Then, the signature verification unit 2122 reads the public key (one of the multiple public keys 272) of the identified client server 2 from the storage device 27. The signature verification unit 2122 uses the read public key to decrypt the electronic signature included in the transaction data. As described above, the electronic signature is obtained by encrypting the hash value or terminal hash value of the part data using the private key of the sending client server 2. The signature verification unit 2122 compares the decrypted value with the Obj-HV (hash value or terminal hash value) included in the transaction data. By confirming that the two match, the signature verification unit 2122 recognizes the validity of the electronic signature.
  • the Obj-HV hash value or terminal hash value
  • the record creation unit 2123 creates a record to be added to the distributed ledger set 50 based on the transaction data.
  • the record creation unit 2123 reads the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV from the transaction data, and creates a record including this information.
  • the ledger update unit 2124 adds the record created by the record creation unit 2123 to the distributed ledger set 50, and updates the distributed ledger set 50. Specifically, the ledger update unit 2124 refers to the key of the created record and identifies the distributed ledger to which the record is to be added. For example, the transaction data generated in response to the first operation of updating the part data of the first part described above has "k1" indicating the ID of the first part as the key. The record created based on this transaction data also has "k1" as the key. Therefore, the ledger update unit 2124 adds the record to the distributed ledger 51, which is the evidence chain of the part data of the first part.
  • the transaction data generated in response to the second operation of relating the first evidence chain to the second evidence chain described above has "k2" indicating the ID of the second part as the key.
  • the record created based on this transaction data also has "k2" as the key. Therefore, the ledger update unit 2124 adds the record to the distributed ledger 52, which is the evidence chain for the part data of the second part.
  • the ledger update unit 2124 When the ledger update unit 2124 has completed updating the distributed ledger set 50, it outputs a notification to that effect to the output unit 2125.
  • the output unit 2125 outputs a control signal to the communication device 24 to notify the client server 2 that transmitted the transaction data that the process of executing the transaction data (transaction processing) has been completed. As a result, a report of the completion of the transaction processing is transmitted via the communication device 24 to the client server 2 that transmitted the transaction data.
  • FIG. 8 is a functional block diagram of the control device 21 for acquiring a timestamp token.
  • the control device 21 includes an information acquisition unit 2131, a record hash creation unit 2132, a timestamp token acquisition unit 2133, and an output unit 2134.
  • the control device 21 functions as the information acquisition unit 2131, the record hash creation unit 2132, the timestamp token acquisition unit 2133, and the output unit 2134, for example, by executing a program stored in the ROM 22.
  • the information acquisition unit 2131, the record hash creation unit 2132, the timestamp token acquisition unit 2133, and the output unit 2134 may be realized, for example, by dedicated hardware (electronic circuitry).
  • the input device 25 or the user terminal device 7 When a third operation is performed on the input device 25 or the user terminal device 7 to request acquisition of a timestamp token, the input device 25 or the user terminal device 7 outputs a third request indicating that the third operation has been performed.
  • the information acquisition unit 2131 acquires the third request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 operates the input device 25 to input the ID of the target for which a timestamp token is to be acquired on the display screen of the display device 26 and selects the timestamp token acquisition button displayed on the display device 26 (performing the third operation), the third request is input to the information acquisition unit 2131.
  • the third request includes an ID (Key) for identifying the target part.
  • the information acquisition unit 2131 outputs the third request to the record hash creation unit 2132.
  • the record hash creation unit 2132 identifies the ID of the target part from the third request, and identifies the distributed ledger from which to obtain a timestamp token (create a record hash value). For example, if the third request contains "k2", which is the ID of the second part, the record hash creation unit 2132 creates a record hash value of the latest record (terminal record) in the distributed ledger 52. The record hash creation unit 2132 outputs the created record hash value to the timestamp token acquisition unit 2133.
  • the time stamp token acquisition unit 2133 outputs a control signal to the communication device 24 to transmit the record hash value received from the record hash creation unit 2132 to the time stamp authority 8. As a result, the record hash value is transmitted to the time stamp authority 8 via the communication device 24.
  • the time stamp authority 8 that receives the record hash value returns a time stamp token to the client server 2.
  • the timestamp token acquisition unit 2133 receives a timestamp token from the time-stamp authority 8 via the communication device 24.
  • the timestamp token acquisition unit 2133 outputs the acquired timestamp token to the output unit 2134.
  • the output unit 2134 stores the timestamp token received from the timestamp token acquisition unit 2133 in the storage device 27.
  • the output unit 2134 may store the timestamp token received from the timestamp token acquisition unit 2133 in the database 4. This makes it possible to obtain proof of existence time.
  • the output unit 2134 may also store the timestamp token received from the timestamp token acquisition unit 2133 in the distributed ledger set 50. For example, if the output unit 2134 acquires a timestamp token for a record hash value in the distributed ledger 52, it creates a record including the timestamp token and adds the record to the distributed ledger 52. The output unit 2134 then generates transaction data with the timestamp token as Obj-HV, and outputs a control signal to the communication device 24 to transmit the transaction data to the client servers 2 participating in the network NW. As a result, the timestamp token is added to the distributed ledger set 50 of each client server 2.
  • the output unit 2134 may also output to the communication device 24 a control signal for transmitting the timestamp token received from the timestamp token acquisition unit 2133 to the external server 9.
  • the external server 9 is a server managed by a management entity other than Company A, Company B, Company C, or Company D. In order to tamper with the timestamp token, the timestamp token managed by the external server 9 must also be tampered with. By managing the timestamp token also by the external server 9, the tamper-resistance of the timestamp token can be improved.
  • Fig. 9 is a flowchart showing the procedure of a process for generating transaction data when a first request is received.
  • the process of the flowchart shown in Fig. 9 is executed by the control device 21 when a first request is received from the input device 25 or the user terminal device 7.
  • steps are abbreviated as "S" of the flowcharts shown in Fig. 9 and Figs. 10, 11, and 12 described below will be described as being realized by software processing by the control device 21, but a part or all of the steps may be realized by hardware (electronic circuits) created within the control device 21.
  • control device 21 In S1, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.
  • control device 21 reads the part data of the target part from the database 4 and generates a hash value of the part data.
  • the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the hash value generated in S2 to create an electronic signature.
  • the control device 21 may also use the private key 271 to encrypt the nonce value generated in S1 to create an electronic signature.
  • the control device 21 may also use the private key 271 to encrypt the hash value generated in S2 and the nonce value generated in S1 to create an electronic signature.
  • the control device 21 In S4, the control device 21 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. Specifically, the control device 21 sets the ID of the target part included in the first request as Key. The control device 21 also sets the nonce value generated in S1 as Nonce, the hash value generated in S2 as Obj-HV, and the electronic signature created in S3 as Sig. The control device 21 also queries the distributed ledger set 50 for the Key to recognize the Age of the parent record, and sets the Age to the value obtained by incrementing the Age of the parent record. The control device 21 also sets the record hash of the parent record as Prev-HV.
  • the control device 21 also hashes the information on Key, Age, Obj-HV, Nonce, Sig, and Prev-HV, excluding the HV information, to HV.
  • the control device 21 may also include in the transaction data time information for broadcasting the transaction data to the network NW and/or sender information of the transaction data.
  • control device 21 outputs a control signal to the communication device 24 to transmit the transaction data generated in S4 to the network NW.
  • the transaction data is transmitted to the network NW via the communication device 24.
  • FIG. 10 is a flowchart showing the procedure for processing to generate transaction data when a second request is received.
  • the processing of the flowchart shown in FIG. 10 is executed by the control device 21 when a second request is received from the input device 25 or the user terminal device 7.
  • control device 21 In S11, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.
  • the control device 21 hashes the latest record in the distributed ledger (the terminal record of the evidence chain) to create a terminal hash value.
  • the display screen for performing the second operation is provided with a "creation target input field" for inputting the ID of the target part for which the terminal hash value is to be created, and an "incorporation target input field" for inputting the ID of the target part into which the terminal hash value is to be incorporated. For example, when k1 is entered in the creation target input field and k2 is entered in the incorporation target input field, the control device 21 hashes the latest record in the distributed ledger 51 to create a terminal hash value.
  • the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the terminal hash value generated in S12 to create an electronic signature.
  • the control device 21 may also use the private key 271 to encrypt the nonce value generated in S11 to create an electronic signature.
  • the control device 21 may also use the private key 271 to encrypt the terminal hash value generated in S12 and the nonce value generated in S11 to create an electronic signature.
  • the control device 21 In S14, the control device 21 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
  • the control device 21 sets the ID entered in the "Incorporation target input field" (k2 in the above example) as the Key.
  • the control device 21 also sets the terminal hash value generated in S12 as Obj-HV.
  • the other processes in S14 are basically the same as those in S4 of FIG. 9, so they will not be described repeatedly.
  • control device 21 outputs a control signal to the communication device 24 to transmit the transaction data generated in S14 to the network NW.
  • the transaction data is transmitted to the network NW via the communication device 24.
  • FIG. 11 is a flowchart showing the procedure of the process executed when transaction data is received. The process of the flowchart shown in FIG. 11 is executed by the control device 21 when transaction data is received.
  • control device 21 identifies the client server 2 that sent the transaction data based on the sender information included in the received transaction data.
  • control device 21 reads the public key of the client server 2 identified in S21 from the storage device 27.
  • control device 21 uses the public key read in S22 to decrypt the electronic signature included in the transaction data.
  • the control device 21 verifies the validity of the electronic signature decrypted in S23. Specifically, the control device 21 compares the decrypted value of the electronic signature with the hash value (or the terminal hash value) included in the transaction data. If the two do not match, the control device 21 does not recognize the validity of the electronic signature (NO in S24) and proceeds to S25. If the two match, the control device 21 recognizes the validity of the electronic signature (YES in S24) and proceeds to S26.
  • control device 21 discards the transaction data received this time because the electronic signature is invalid, and ends the process.
  • the control device 21 may also display on the display device 26 a message indicating that the transaction data may have been tampered with.
  • control device 21 reads the Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV information from the received transaction data, and creates a record containing this information.
  • control device 21 identifies the distributed ledger to which the record will be added based on the key of the record created in S26. The control device 21 then adds the record to the identified distributed ledger. This updates the distributed ledger set 50.
  • control device 21 sends a notification (completion report) indicating that the transaction processing has been completed to the client server 2 that sent the transaction data.
  • FIG. 12 is a flowchart showing the steps of the process for acquiring a timestamp token.
  • the process of the flowchart shown in FIG. 12 is executed by the control device 21 when a third request is received from the input device 25 or the user terminal device 7.
  • control device 21 identifies the distributed ledger (distributed ledger 51 or distributed ledger 52) from which to obtain the timestamp token based on the ID of the target part included in the third request.
  • control device 21 In S32, the control device 21 generates a record hash value of the latest record (terminal record) of the distributed ledger identified in S31.
  • control device 21 outputs a control signal to the communication device 24 to transmit the record hash value generated in S32 to the time-stamping authority 8.
  • the record hash value is transmitted to the time-stamping authority 8 via the communication device 24.
  • control device 21 receives a time stamp token from the time stamp authority 8 via the communication device 24. This provides proof of the existence time of the part data of the target part.
  • control device 21 stores the timestamp token acquired in S34 in the storage device 27.
  • the control device 21 may store the timestamp token in the database 4. Furthermore, the control device 21 may retain the timestamp token in the distributed ledger set 50.
  • control device 21 outputs a control signal to the communication device 24 to transmit the timestamp token acquired in S34 to the external server 9. As a result, the timestamp token is transmitted to the external server 9 via the communication device 24.
  • the control device 21 may also generate transaction data for adding the timestamp token to the distributed ledger set 50, and output a control signal to the communication device 24 to transmit the transaction data to the network NW.
  • the client server 2 holds a distributed ledger set 50 including two distributed ledgers 51, 52.
  • the distributed ledger 51 is an evidence chain for proving the existence of part data of a first part
  • the distributed ledger 52 is an evidence chain for proving the existence of part data of a second part.
  • the client server 2 has a function for associating the two distributed ledgers 51, 52 in response to a request from a user.
  • the client server 2 incorporates the terminal hash value of one distributed ledger into the record of the other distributed ledger. Based on the record into which the terminal hash value is incorporated, the order of the existence of the part data of the first part and the part data of the second part can be proven.
  • the client server 2 obtains a timestamp token for the record in which the terminal hash value is incorporated.
  • proof of the existence time of the part data of the first part and the part data of the second part i.e., proof that the part data existed before the time indicated by the timestamp token
  • the client server 2 also transmits the time stamp token to the external server 9.
  • the time stamp token also managed by the external server 9
  • the resistance of the time stamp token to tampering can be improved.
  • FIG. 13 is a diagram showing a schematic configuration of a data management system 1A according to the second embodiment.
  • the data management system 1A includes four client servers 3, a platform server 6, and a time authentication authority 8.
  • each of the four client servers 3 is a server belonging to a different company (for example, company A, company B, company C, and company D).
  • company A for example, company A, company B, company C, and company D.
  • company D for example, company A, company B, company C, and company D
  • the client server 3 of company A will be described as a representative example, but the client servers 3 of companies B, C, and D also have similar functions.
  • the platform server 6 manages the network NW and accepts applications from each client server 3 to participate in the network NW.
  • the platform server 6 permits the client server 3 to participate in the network NW based on an operation by the platform server 6 administrator to permit participation, or based on the result of judging a predetermined condition.
  • four client servers 3 belonging to each of companies A, B, C, and D are permitted to participate in the network NW.
  • the four client servers 3 and the platform server 6 form a network NW.
  • Distributed ledger infrastructure software is installed in each of the client servers 3, and each of the client servers 3 functions as a node as a result of the installed distributed ledger infrastructure software functioning.
  • the client servers 3 are configured to be able to communicate with a user terminal device 7, similar to the client server 2 in embodiment 1.
  • the client server 3 is connected to a database 4.
  • the client server 3 (control device 31) generates a control signal for storing/updating part data in response to an input to the input device 35 or a request from the user terminal device 7, and outputs the control signal to the database 4.
  • the client server 3 When the client server 3 stores/updates part data in the database 4, it creates a hash value for the part data and generates transaction data for storing the hash value in the ledger held by the platform server 6 and in the distributed ledger held by each client server 3. The client server 3 then transmits the generated transaction data to the platform server 6.
  • the platform server 6 has the function of providing finality to transaction data.
  • the platform server 6 holds a ledger set 60, processes transaction data received from the client server 3, and updates the ledger set 60.
  • the platform server 6 updates the ledger set 60 it transmits a summary of the records added to the ledger by the update (proof records, described below) to all client servers 3 participating in the network NW.
  • the client server 3 stores a commit table 374 that stores the commit records.
  • the commit table 374 corresponds to an example of a "distributed ledger" according to the present disclosure.
  • FIG. 14 is a diagram showing an example of the configuration of ledger set 60.
  • Ledger set 60 includes ledgers 67 and 68.
  • Ledger 67 like distributed ledger 51 according to embodiment 1, stores the update state of the part data of the first part in chronological order and forms an evidence chain for the part data of the first part.
  • Ledger 68 like distributed ledger 52 according to embodiment 1, stores the update state of the part data of the second part in chronological order and forms an evidence chain for the part data of the second part.
  • Ledger set 60, ledger 67, and ledger 68 have the same configuration as distributed ledger set 50, distributed ledger 51, and distributed ledger 52 according to embodiment 1, respectively. Therefore, detailed description thereof will not be repeated.
  • the client server 3 includes a control device 31, a ROM 32, a RAM 33, a communication device 34, an input device 35, a display device 36, and a storage device 37.
  • the control device 31, the ROM 32, the RAM 33, the communication device 34, the input device 35, the display device 36, and the storage device 37 are connected to a bus 39.
  • the ROM 32, the RAM 33, the communication device 34, the input device 35, and the display device 36 are basically configured in the same manner as the ROM 22, the RAM 23, the communication device 24, the input device 25, and the display device 26 of the client server 2 according to the first embodiment, respectively, and therefore the description thereof will not be repeated.
  • the storage device 37 stores a private key 371 and proof data 372.
  • the private key 371 is the private key of company A.
  • the control device 31 when the client server 3 first joins the network NW, the control device 31 generates a private key and a public key. The control device 31 then sends the generated public key to a certification authority (not shown) for authentication. The certification authority issues an electronic certificate including information about the public key.
  • the control device 31 stores the private key 371 corresponding to the authenticated public key in the storage device 37.
  • the control device 31 also sends the authenticated public key (electronic certificate) 651 to the platform server 6.
  • the proof data 372 includes a suspension table 373 and a commit table 374.
  • FIG. 15 is a diagram for explaining an example of the configuration of the suspension table 373.
  • FIG. 16 is a diagram for explaining an example of the configuration of the commit table 374.
  • the suspension table 373 and the commit table 374 have a record for each target part.
  • the suspension table 373 includes a predetermined type of information included in unused transaction data. Specifically, the suspension table 373 stores suspension records including, for example, key and nonce information.
  • the control device 31 stores the key and nonce information included in the transaction data generated in response to the first or second request as a suspension record in the suspension table 373.
  • the first and second requests received by the client server 3 from the input device 35 or the user terminal device 7 include the ID of the target part. For example, if the target of the first request is the first part, the first request includes an ID indicating "k1", and if the target of the first request is the second part, the first request includes an ID indicating "k2". In other words, the ID of the target part included in the first or second request becomes the key.
  • the control device 31 when the first or second request is received, the control device 31 generates a nonce value.
  • the nonce value indicates the number of the first or second request (i.e., the number of the transaction data).
  • the control device 31 creates a suspension record including the key and nonce information, and registers the suspension record in the suspension table 373.
  • FIG. 15 shows an example in which a suspension record including the key k1 is registered in the suspension table 373. In the following, when there is no particular distinction between the first request and the second request, both are collectively referred to as an "update request.”
  • the control device 31 When processing responding to the update request is executed (i.e., when the transaction data is used), the control device 31 deletes from the suspension table 373 the suspension record that contains information about a key that is the same as the key contained in the transaction data used to execute the transaction processing.
  • Duplicate suspension records containing the same key information are not registered in the suspension table 373.
  • the control device 31 judges whether a suspension record containing a key matching the key contained in the suspension record to be registered has already been registered in the suspension table 373. If a suspension record containing a key matching the key contained in the suspension record to be registered has not been registered in the suspension table 373, the control device 31 registers the suspension record in the suspension table 373. If a suspension record containing a key matching the key contained in the suspension record to be registered has been registered in the suspension table 373, the control device 31 waits for the suspension record containing the matching key to be deleted from the suspension table 373. In other words, in the example shown in FIG. 15, a suspension record containing a key k2 can be registered in the suspension table 373, but a suspension record containing a key k1 cannot be registered.
  • the commit table 374 contains a specific type of information contained in used transaction data. Specifically, the commit table 374 stores commit records containing information on the Key, Age, HV, and Nonce. The commit table 374 contains commit data 375 that stores a commit record having a key of k1, and commit data 376 that stores a commit record having a key of k2.
  • the platform server 6 executes transaction processing and updates the ledgers in the ledger set 60, it creates a proof record and transmits the proof record to all client servers 3 participating in the network NW.
  • the proof record is, for example, a record that includes information on the Key, Age, HV, and Nonce from among the records that were added to the ledger by the transaction processing executed using the transaction data.
  • control device 31 When the control device 31 receives the proof record, it adds the proof record to the commit table 374 (commit data 375 or commit data 376) as a commit record. The control device 31 then deletes from the suspension table 373 any suspension records that contain the same key as the key contained in the added commit record.
  • the platform server 6 includes a control device 61, a ROM 62, a RAM 63, a communication device 64, and a storage device 65.
  • the control device 61, the ROM 62, the RAM 63, the communication device 64, and the storage device 65 are connected to a bus 69.
  • the control device 61 is composed of an integrated circuit including a CPU.
  • the control device 61 loads various programs stored in the ROM 62 into the RAM 63 and executes them.
  • the various programs include an operating system, etc.
  • the RAM 63 functions as a working memory, and temporarily stores various data required for the execution of the various programs.
  • the control device 61 receives transaction data from the client server 3 and executes transaction processing.
  • the communication device 64 is configured to be able to communicate with the client server 3 participating in the network NW.
  • the storage device 65 stores multiple public keys 651 and ledger set 60.
  • the multiple public keys 651 include the public keys of companies that manage client servers 3 participating in the network NW.
  • the multiple public keys 651 include the public key of company A, the public key of company B, the public key of company C, and the public key of company D.
  • ledger set 60 has a similar configuration to distributed ledger set 50 according to embodiment 1, and therefore will not be described again.
  • FIG. 17 is a flowchart showing the steps of the process executed by the data management system 1A when an update request (first request, second request) is received.
  • the process of the flowchart shown in FIG. 17 is started by the control device 31 of the client server 3 when an update request (first request, second request) is received from the input device 25 or the user terminal device 7.
  • control device 31 of the client server 3 generates a nonce value.
  • This nonce value is used as the number of the transaction data that is generated in response to the update request.
  • the control device 31 of the client server 3 generates a suspension record. Specifically, the control device 31 of the client server 3 reads the ID of the target part included in the update request and sets it as Key information, and generates a suspension record using the nonce value generated in S40 as Nonce information.
  • the control device 31 of the client server 3 judges whether the suspension record generated in S41 can be registered in the suspension table 373. If a suspension record having the same key information as the suspension record generated in S41 is registered in the suspension table 373, the control device 31 of the client server 3 makes a negative judgment (NO in S42) and waits for the suspension record having the same key information to be deleted from the suspension table 373. On the other hand, if a suspension record having the same key information as the suspension record generated in S41 is not registered in the suspension table 373, the control device 31 of the client server 3 makes an affirmative judgment (YES in S42) and proceeds to S43.
  • control device 31 of the client server 3 registers the suspension record in the suspension table 373.
  • the control device 31 of the client server 3 generates transaction data to respond to the update request. Specifically, if the update request is a first request, the control device 31 of the client server 3 executes processes similar to the processes of S2 to S5 described in FIG. 9 to generate transaction data, and if the update request is a second request, the control device 31 of the client server 3 executes processes similar to the processes of S12 to S15 described in FIG. 10 to generate transaction data. Details of each process are as described in FIG. 9 and FIG. 10, so they will not be described repeatedly.
  • control device 31 of the client server 3 outputs a control signal to the communication device 34 to transmit the transaction data generated in S44 to the platform server 6.
  • the transaction data is transmitted to the platform server 6 via the communication device 34.
  • control device 61 of the platform server 6 decrypts the electronic signature included in the received transaction data to verify its validity. Specifically, the control device 61 of the platform server 6 executes the same processes as those of S21 to S23 described in FIG. 11 to decrypt the electronic signature. Details of each process are as described in FIG. 11, so they will not be described again.
  • the control device 61 of the platform server 6 verifies the validity of the electronic signature decrypted in S50. Specifically, the control device 61 of the platform server 6 compares the decrypted value of the electronic signature with the hash value included in the transaction data (the hash value of the part data of the target part in the transaction data generated in response to the first request, and the terminal hash value in the transaction data generated in response to the second request). If the two do not match, the control device 61 of the platform server 6 does not recognize the validity of the electronic signature (NO in S51) and proceeds to S52. If the two match, the control device 61 of the platform server 6 recognizes the validity of the electronic signature (YES in S51) and proceeds to S53.
  • control device 61 of the platform server 6 determines that the transaction data received from the client server 3 may have been tampered with, discards the transaction data, and creates an abnormality report indicating the possibility of tampering. The control device 61 of the platform server 6 then advances the process to S56.
  • control device 61 of the platform server 6 executes transaction processing. Specifically, the control device 61 of the platform server 6 executes processing similar to the processing of S26 and S27 described in FIG. 11, generates a ledger record identified by the key information included in the transaction data, adds the generated record to the ledger, and updates the ledger set 60.
  • the control device 61 of the platform server 6 generates a proof record.
  • the proof record includes the Key, Age, HV, and Nonce information contained in the record added to the ledger.
  • control device 61 of the platform server 6 creates a success report indicating that the update of the ledger set 60 has been completed (i.e., the transaction data has been processed).
  • the control device 61 of the platform server 6 includes a proof record in the success report.
  • control device 61 of the platform server 6 outputs a control signal to the communication device 64 to transmit the abnormality report created in S52 or the normality report created in S55 to the client server 3.
  • the abnormality report or normality report is transmitted to the client server 3 via the communication device 64.
  • control device 61 of the platform server 6 outputs a control signal to the communication device 64 to transmit the proof record to other client servers 3 other than the sender of the transaction data (for example, the client servers 3 of companies B, C, and D).
  • the proof record is transmitted to the other client servers 3 via the communication device 64.
  • the control device 31 of the client server 3 determines whether or not a normal report has been received from the platform server 6. If it determines that a normal report has been received (YES in S46), the control device 31 of the client server 3 advances the process to S47. On the other hand, if it determines that a normal report has not been received, i.e., that an abnormality report has been received (NO in S46), the control device 31 of the client server 3 advances the process to S49.
  • the control device 31 of the client server 3 adds the proof record included in the normal report as a commit record to the commit table 374. Specifically, the control device 31 of the client server 3 determines whether the target to which the commit record is to be added is commit data 375 or commit data 376, based on the key information of the proof record. Then, the control device 31 of the client server 3 adds the commit record to the target commit data.
  • control device 31 of the client server 3 deletes the suspension record that has the same key information as the added commit record from the suspension table 373.
  • control device 31 of the client server 3 displays the results of the processing for the update request on the display device 36 or transmits them to the user terminal device 7, for example.
  • client servers 3 that received the proof record sent in S56 also add the proof record to their commit tables 374 in a similar manner, thereby updating the commit tables 374.
  • FIG. 18 is a flowchart showing the procedure of the process for acquiring a timestamp token in embodiment 2. The process of the flowchart shown in FIG. 18 is executed by the control device 31 when a third request is received from the input device 35 or the user terminal device 7.
  • control device 31 identifies the commit data (commit data 375 or commit data 376) for which a timestamp token is to be obtained based on the ID of the target part included in the third request.
  • control device 31 In S62, the control device 31 generates a hash value of the latest commit record of the commit data identified in S61.
  • control device 31 outputs a control signal to the communication device 34 to transmit the hash value generated in S62 to the time-stamping authority 8. As a result, the hash value is transmitted to the time-stamping authority 8 via the communication device 34.
  • control device 31 receives a time stamp token from the time stamp authority 8 via the communication device 34. This provides proof of the existence time of the part data of the target part.
  • control device 31 stores the timestamp token acquired in S64 in the storage device 37.
  • the control device 31 may also store the timestamp token in the database 4.
  • control device 21 outputs a control signal to the communication device 34 to transmit the timestamp token acquired in S34 to the external server 9.
  • the timestamp token is transmitted to the external server 9 via the communication device 34.
  • control device 31 may generate transaction data for including the timestamp token in the ledger set 60 in order to add the timestamp token to the commit table 374, and output a control signal to the communication device 34 to transmit the transaction data to the platform server 6.
  • the platform server 6 provides finality to transaction data.
  • the platform server 6 holds a ledger set 60 including two ledgers 67 and 68.
  • the ledger 67 stores the update state of the part data of the first part in chronological order
  • the ledger 68 stores the update state of the part data of the second part in chronological order.
  • a proof record that is a summary of the records added to the ledger set 60 is sent from the platform server 6 to each client server 3, and each client server 3 adds the proof record to the commit table 374 as a commit record.
  • the commit table 374 corresponds to the distributed ledger set 50 according to the first embodiment.
  • the commit data that is the summary of the two ledgers can also be associated with each other. This makes it possible to prove the order of the existence of the part data of the first part and the part data of the second part, based on the commit record in which the terminal hash value is embedded, just like in the first embodiment.
  • each client server 3 has its own commit table 374, which increases the tamper resistance of the commit table 374.
  • the client server 3 also obtains a timestamp token for the record of the commit data in which the terminal hash value is embedded.
  • a timestamp token for the record in which the terminal hash value is embedded it is possible to obtain proof of the existence time of the part data of the first part and the part data of the second part (i.e., proof that the part data existed before the time indicated by the timestamp token).
  • the client server 3 also transmits the time stamp token to the external server 9.
  • the time stamp token also managed by the external server 9
  • the resistance of the time stamp token to tampering can be improved.
  • each of the commit data 375, 376 in the commit table 374 is configured to include the information of Key, Age, HV, and Nonce among the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV contained in each of the ledgers 67, 68 in the ledger set 60.
  • each of the commit data 375, 376 may be configured to include the same information as the ledgers 67, 68, i.e., the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
  • the proof record is also generated to include the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Lorsqu'un dispositif de commande (21) d'un serveur client (2) met à jour des données de composant (D12) en données de composant (D13), le dispositif de commande crée un enregistrement comprenant une valeur de hachage des données de composant (D13) dans une première chaîne de preuve (registre distribué 51) (âge [3]). Ensuite, le dispositif de commande (21) génère une valeur de hachage de terminal qui est une valeur de hachage d'un enregistrement de terminal (âge [3]) de la première chaîne de preuve. Le dispositif de commande (21) stocke la valeur de hachage de terminal générée dans un enregistrement d'une seconde chaîne de preuve (registre distribué 52) et associe le registre distribué (51) au registre distribué (52).
PCT/JP2022/039769 2022-10-25 2022-10-25 Dispositif de gestion de données et procédé de gestion de données Ceased WO2024089773A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280101160.8A CN120077379A (zh) 2022-10-25 2022-10-25 数据管理装置和数据管理方法
PCT/JP2022/039769 WO2024089773A1 (fr) 2022-10-25 2022-10-25 Dispositif de gestion de données et procédé de gestion de données

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/039769 WO2024089773A1 (fr) 2022-10-25 2022-10-25 Dispositif de gestion de données et procédé de gestion de données

Publications (1)

Publication Number Publication Date
WO2024089773A1 true WO2024089773A1 (fr) 2024-05-02

Family

ID=90830198

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/039769 Ceased WO2024089773A1 (fr) 2022-10-25 2022-10-25 Dispositif de gestion de données et procédé de gestion de données

Country Status (2)

Country Link
CN (1) CN120077379A (fr)
WO (1) WO2024089773A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10476665B1 (en) * 2016-12-28 2019-11-12 Wells Fargo Bank, N.A. Cryptographic algorithm status transition
JP2021505095A (ja) * 2017-12-01 2021-02-15 クアント ネットワーク リミテッド ブロックチェーン通信と順序付け
CN114490741A (zh) * 2022-04-18 2022-05-13 武汉龙津科技有限公司 基于可信区块链的时间排序方法、装置、电子设备及介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10476665B1 (en) * 2016-12-28 2019-11-12 Wells Fargo Bank, N.A. Cryptographic algorithm status transition
JP2021505095A (ja) * 2017-12-01 2021-02-15 クアント ネットワーク リミテッド ブロックチェーン通信と順序付け
CN114490741A (zh) * 2022-04-18 2022-05-13 武汉龙津科技有限公司 基于可信区块链的时间排序方法、装置、电子设备及介质

Also Published As

Publication number Publication date
CN120077379A (zh) 2025-05-30

Similar Documents

Publication Publication Date Title
JP7721244B2 (ja) Ｓｓｉを用いたブロックチェーンネットワークアイデンティティ管理
CN111434085B (zh) 用于在区块链系统中进行跨链交互的域名管理方案
CN111092737B (zh) 数字证书管理方法、装置及区块链节点
CN110489946B (zh) 基于区块链的版权认证方法、装置、设备和存储介质
US11811865B2 (en) Blockchain declarative descriptor for cross-network communication
US10681035B1 (en) Cryptographic services engine
CN110019009A (zh) 电子证照共享方法、服务器和可读存储介质
JP7525455B2 (ja) データ管理装置およびデータ管理方法
JP2006107247A (ja) タイムスタンプサービスシステム及びタイムスタンプ情報検証サーバ装置並びにコンピュータ・ソフトウエア
JP7670589B2 (ja) データ管理装置およびデータ管理方法
WO2024089773A1 (fr) Dispositif de gestion de données et procédé de gestion de données
JP7564071B2 (ja) データ管理装置およびデータ管理方法
WO2024089775A1 (fr) Dispositif de gestion de données et procédé de gestion de données
EP4362385A1 (fr) Appareil de gestion de données et procédé de gestion de données
JP7276539B2 (ja) データ管理装置およびデータ管理方法
WO2024089774A1 (fr) Dispositif de gestion de données et procédé de gestion de données
EP4362384A1 (fr) Appareil de gestion de données et procédé de gestion de données
CN111292184A (zh) 文件反馈的告警提示方法、装置及存储介质
EP4362383A1 (fr) Appareil de gestion de données et procédé de gestion de données
JP2023045520A (ja) サーバ装置
US20240330465A1 (en) Data management apparatus and data management method
JP7040648B1 (ja) データ管理装置およびデータ管理方法
US12445291B2 (en) Data management device, data management method, and non-transitory storage medium
JP2010197980A (ja) ソーシャルネット内の各ユーザの公開鍵の正当性を保証する認証局を設定する認証局設定装置
JP2004102552A (ja) ライセンスキー発行装置、ライセンスキー生成方法、プログラム実行装置、プログラム実行装置の制御方法及びプログラム

Legal Events

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

Ref document number: 22963425

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280101160.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 202280101160.8

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 22963425

Country of ref document: EP

Kind code of ref document: A1