[go: up one dir, main page]

WO2024089773A1 - データ管理装置およびデータ管理方法 - Google Patents

データ管理装置およびデータ管理方法 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)
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.)
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/ja
Publication of WO2024089773A1 publication Critical patent/WO2024089773A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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

クライアントサーバ(2)の制御装置(21)は、部品データ(D12)を部品データ(D13)に更新すると、第1証拠チェーン(分散型台帳51)に、部品データ(D13)のハッシュ値を含めたレコードを作成する(Age[3])。そして、制御装置(21)は、第1証拠チェーンの終端レコード(Age[3])のハッシュ値である終端ハッシュ値を生成する。制御装置(21)は、生成された終端ハッシュ値を第2証拠チェーン(分散型台帳52)のレコードに格納し、分散型台帳(51)と分散型台帳(52)とを関連付ける。

Description

データ管理装置およびデータ管理方法
 本開示は、分散型台帳技術を用いてデータを管理するデータ管理装置およびデータ管理方法に関する。
 特許第6694204号公報(特許文献1)には、管理対象を識別するためのKey(ID)毎に、DAG(Directed Acyclic Graph)構造を有する分散型台帳(アセット)を構成し、ID毎に情報を管理するデータ管理システムが開示されている。
特許第6694204号公報
 特許文献1に開示されたデータ管理システムでは、たとえば、あるIDで管理される対象のデータが更新されると、当該あるIDに対して用意されたアセットにデータが追加されていく。また、他のIDで管理される対象についても、他のIDで管理される対象のデータが更新されると、当該他のIDに対して用意されたアセットにデータが追加されていく。
 ここで、あるIDに対して用意されたアセットに格納されているデータと、他のIDに対して用意されたアセットに格納されているデータとの、いずれが先に存在していたのかを示す順序性を証明したい場合がある。たとえば、それぞれのアセットが更新される毎に、最新のアセットレコードに対してタイムスタンプトークンを取得することで、順序性を証明することが考えられる。しかしながら、この場合には、タイムスタンプトークンの取得費用が嵩んだり、システム負荷が増加したりする可能性がある。
 本開示は、上記課題を解決するためになされたものであり、本開示の目的は、複数の分散型台帳を有するシステムにおいて、分散型台帳間におけるデータの順序性の証明を容易に行なうことができるようにすることである。
 (1)本開示のある局面に係るデータ管理装置は、分散型台帳技術を用いてデータを管理するデータ管理装置である。このデータ管理装置は、データに関する情報を含むレコードを時系列に格納する分散型台帳を記憶する記憶装置と、分散型台帳にレコードを追加する制御装置とを備える。データは、第1データおよび第2データを含む。分散型台帳は、第1データに関する第1情報を含むレコードを時系列に格納する第1分散型台帳と、第2データに関する第2情報を含むレコードを時系列に格納する第2分散型台帳とを含む。第1の時点において、第1データを更新すると、制御装置は、第1情報を含むレコードを第1分散型台帳に格納するとともに、当該レコードの情報を含む第1終端値を生成し、第1終端値を含むレコードを第2分散型台帳に格納する。
 上記構成によれば、第1の時点において、第1終端値が第2分散型台帳に格納される。これにより、第1の時点を基準として、第1分散型台帳と第2分散型台帳とが関連付けられる。それゆえに、第1の時点を基準として、第1の時点に更新された第1データと、第2データとの存在の順序性を証明することができる。
 (2)ある実施の形態においては、第1終端値は、第1の時点において第1分散型台帳に格納されたレコードのハッシュ値である。
 上記構成によれば、第1分散型台帳のレコードのハッシュ値を、第2分散型台帳のレコードに格納するので、データ容量を過度に増加させることなく、第1分散型台帳と第2分散型台帳とを関連付けることができる。
 (3)ある実施の形態においては、第1情報は、第1データのハッシュ値である。第2情報は、第2データのハッシュ値である。
 上記構成によれば、第1分散型台帳および第2分散型台帳に格納されるレコードには、第1データのハッシュ値および第2データのハッシュ値が含まれるので、第1データおよび第2データ自体を秘匿しておくことができる。
 (4)ある実施の形態においては、制御装置は、ユーザからの要求に基づいて、第1終端値を含むレコードを第2分散型台帳に格納する。
 上記構成によれば、ユーザは、任意のタイミングで第1分散型台帳と第2分散型台帳とを関連付けることができる。
 (5)ある実施の形態においては、データ管理装置は、時刻認証局との通信が可能に構成された通信装置をさらに備える。制御装置は、第1の時点よりも後の時点である第2の時点において、通信装置を介して、第2分散型台帳の終端のレコードの情報を含む第2終端値を時刻認証局に送信して、当該時刻認証局から第2終端値に対するタイムスタンプトークンを取得する。
 上記構成によれば、第1終端値を含むレコードが第2分散型台帳に格納された後において、第2終端値に対してタイムスタンプトークンが取得される。これによって、第1の時点を基準とした、第1データと第2データとの順序性の証明を可能としつつ、第2の時点を基準とした第1データおよび第2データの時刻性の証明を可能とすることができる。
 (6)ある実施の形態においては、制御装置は、ユーザからの要求に基づいて、タイムスタンプトークンを取得する。
 上記構成によれば、ユーザは、任意のタイミングでタイムスタンプトークンを取得することができる。
 (7)本開示の他の局面に係るデータ管理方法は、分散型台帳技術を用いてデータを管理するデータ管理装置のデータ管理方法である。データ管理装置は、データに関する情報を含むレコードを時系列に格納する分散型台帳を記憶する記憶装置と、分散型台帳にレコードを追加する制御装置とを備える。データは、第1データおよび第2データを含む。分散型台帳は、第1データに関する第1情報を含むレコードを時系列に格納する第1分散型台帳と、第2データに関する第2情報を含むレコードを時系列に格納する第2分散型台帳とを含む。データ管理方法は、所定の時点において第1データを更新すると、制御装置が、第1情報を含むレコードを第1分散型台帳に格納するとともに、当該レコードの情報を含む第1終端値を生成するステップと、第1終端値を含むレコードを第2分散型台帳に格納するステップとを含む。
 本開示によれば、複数の分散型台帳を有するシステムにおいて、分散型台帳間におけるデータの順序性の証明を容易に行なうことができる。
実施の形態1に係るデータ管理システムの概略的な構成を示す図である。 分散型台帳セットの構成の一例を示す図(その1)である。 2つの分散型台帳の関連付けを説明するための図である。 分散型台帳セットの構成の一例を示す図(その2)である。 第1操作に応答する処理を実行するための制御装置の機能ブロック図である。 第2操作に応答する処理を実行するための制御装置の機能ブロック図である。 受信したトランザクションデータを実行するための制御装置の機能ブロック図である。 タイムスタンプトークンを取得するための制御装置の機能ブロック図である。 第1要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。 第2要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。 トランザクションデータを受信した場合に実行される処理の手順を示すフローチャートである。 タイムスタンプトークンを取得する処理の手順を示すフローチャートである。 実施の形態2に係るデータ管理システムの概略的な構成を示す図である。 台帳セットの構成の一例を示す図である。 サスペンションテーブルの構成の一例を説明するための図である。 コミットテーブルの構成の一例を説明するための図である。 更新要求(第1要求,第2要求)を受けた場合にデータ管理システムで実行される処理の手順を示すフローチャートである。 実施の形態2において、タイムスタンプトークンを取得する処理の手順を示すフローチャートである。
 以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付して、その説明は繰り返さない。
 [実施の形態1]
 <データ管理システムの全体構成>
 図1は、実施の形態1に係るデータ管理システム1の概略的な構成を示す図である。実施の形態1に係るデータ管理システム1は、複数の企業間でコンソーシアムネットワーク(以下、単に「ネットワーク」とも称する)NWを形成し、分散型台帳技術を用いてデータを管理するためのシステムである。実施の形態1に係るデータ管理システム1は、車両を構成する部品のデータ(以下、単に「部品データ」とも称する)を管理する。部品データは、たとえば、部品の仕様書であってもよい。なお、データ管理システム1が管理するデータは、車両を構成する部品のデータに限られるものではなく、種々のデータであってよい。
 図1を参照して、データ管理システム1は、4台のクライアントサーバ2と、プラットフォームサーバ5と、時刻認証局(TSA:Time Stamp Authority)8とを備える。4台のクライアントサーバ2の各々は、異なる企業(たとえば、A企業、B企業、C企業およびD企業)に帰属するサーバである。
 プラットフォームサーバ5は、ネットワークNWを管理する。プラットフォームサーバ5は、各クライアントサーバ2からのネットワークNWへの参加申請を受け付ける。プラットフォームサーバ5は、プラットフォームサーバ5の管理者による参加を許可する操作に基づき、または、所定の条件の判定結果に基づき、クライアントサーバ2のネットワークNWへの参加を許可する。実施の形態1では、A企業、B企業、C企業およびD企業のそれぞれに帰属する4台のクライアントサーバ2に対して、ネットワークNWへの参加が許可されている。
 4台のクライアントサーバ2は、ネットワークNWを形成し、部品データのハッシュ値を各々の分散型台帳に記憶している。クライアントサーバ2の各々には、分散型台帳基盤のソフトウェアが導入されており、導入された分散型台帳基盤のソフトウェアが機能することにより、クライアントサーバ2の各々がノードとして機能する。以下においては、A企業のクライアントサーバ2について代表的に説明するが、B企業、C企業およびD企業のクライアントサーバも同様の構成および機能を有する。なお、クライアントサーバ2は、本開示に係る「データ管理装置」の一例に相当する。
 クライアントサーバ2は、ユーザ端末装置7と通信可能に構成されている。ユーザ端末装置7は、たとえば、A企業の従業員に貸与された、デスクトップ型のPC(Personal Computer)、ノート型のPC、タブレット端末、スマートフォン、または、通信機能を有するその他の情報処理端末である。
 また、クライアントサーバ2には、データベース4が接続されている。データベース4は、部品データを記憶している。データベース4は、クライアントサーバ2からの制御信号に従って、部品データを記憶したり、更新したりする。たとえば、クライアントサーバ2のユーザ(たとえば、A企業の従業員等)は、クライアントサーバ2の入力装置25(後述)への操作により部品データの更新を要求したり、ユーザ端末装置7への操作により部品データの更新を要求したりすることができる。クライアントサーバ2(制御装置21)は、入力装置25への入力、あるいは、ユーザ端末装置7からの要求に応じて、部品データを記憶/更新するための制御信号を生成し、データベース4に出力する。
 クライアントサーバ2は、データベース4に部品データを記憶/更新すると、当該部品データのハッシュ値を生成し、当該ハッシュ値を分散型台帳に格納するためのトランザクションデータを生成する。そして、クライアントサーバ2は、生成されたトランザクションデータを、ネットワークNWを形成する他のクライアントサーバ2、すなわち、B企業,C企業,D企業のクライアントサーバ2に送信する。分散型台帳は、部品データのハッシュ値を時系列に格納し、部品データの存在を証明するための証拠チェーンを形成する。なお、実施の形態1に係るデータ管理システム1においては、ネットワークNWに4台のクライアントサーバが含まれる例について説明するが、ネットワークNWに含まれるクライアントサーバ2の台数は任意であり、たとえば、4台未満であってもよいし、5台以上であってもよい。
 時刻認証局8は、タイムスタンプトークンを発行する認証機関に帰属するサーバを含む。時刻認証局は、申請者(実施の形態1においては、クライアントサーバ2)からのタイムスタンプ発行要求に応じて、タイムスタンプトークンを発行する。より具体的には、時刻認証局は、申請者から受信したデータ(実施の形態1においては、後述のレコードハッシュ値)に、国際標準時に追跡性がある時刻源に基づく時刻情報を結合させたタイムスタンプトークンを、申請者に送信する。
 クライアントサーバ2は、制御装置21と、ROM(Read Only Memory)22と、RAM(Random Access Memory)23と、通信装置24と、入力装置25と、表示装置26と、記憶装置27とを備える。制御装置21、ROM22、RAM23、通信装置24、入力装置25、表示装置26、および、記憶装置27は、バス29に接続されている。
 制御装置21は、たとえば、CPU(Central Processing Unit)を含む集積回路によって構成される。制御装置21は、ROM22に格納されている各種プログラムをRAM23に展開して実行する。各種プログラムには、オペレーティングシステム等が含まれる。RAM23は、ワーキングメモリとして機能し、各種プログラムの実行に必要な各種データを一時的に格納する。制御装置21は、後に詳しく説明するが、データベース4に記録されている部品データを更新したり、分散型台帳を更新するためのトランザクションデータを生成したり、タイムスタンプトークンを取得したりする機能を有する。
 通信装置24は、外部の機器との通信が可能に構成される。外部の機器は、たとえば、他のクライアントサーバ2、ユーザ端末装置7、および時刻認証局8等を含む。通信装置24と外部の機器との通信は、インターネット、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、イーサネット(登録商標)ネットワーク、パブリックネットワーク、プライベートネットワーク、有線ネットワークまたは無線ネットワーク等、あるいは、これらの組み合わせを用いて行なわれる。
 入力装置25は、入力デバイスを含む。入力デバイスは、たとえば、マウス、キーボード、タッチパネル、および/または、ユーザの操作を受け付けることが可能なその他の装置である。
 表示装置26は、ディスプレイを含む。表示装置26は、制御装置21からの制御信号に従って、ディスプレイに各種の画像を表示させる。ディスプレイは、たとえば、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ、または、その他の表示機器である。
 記憶装置27は、たとえば、ハードディスクまたはフラッシュメモリ等の記憶媒体を含んで構成される。記憶装置27は、秘密鍵271、複数の公開鍵272および分散型台帳セット50を記憶している。
 秘密鍵271は、A企業の秘密鍵である。たとえば、クライアントサーバ2がネットワークNWに最初に参加するにあたり、制御装置21は、秘密鍵および公開鍵を生成する。そして、制御装置21は、生成された公開鍵を認証局(図示せず)に送信して、認証を受ける。認証局は、電子証明書を発行する認証機関である。認証局は、公開鍵の情報を含めた電子証明書を発行する。制御装置21は、認証を受けた公開鍵に対応する秘密鍵271を記憶装置27に記憶させる。また、制御装置21は、認証を受けた公開鍵(電子証明書)272を、B企業、C企業およびD企業のクライアントサーバ2に送信する。
 複数の公開鍵272は、B企業の公開鍵、C企業の公開鍵およびD企業の公開鍵を含む。制御装置21は、他のクライアントサーバ2から受信した公開鍵を記憶装置27に記憶させる。また、記憶装置27は、自身(A企業)の公開鍵を記憶していてもよい。
 分散型台帳セット50は、複数の分散型台帳を含む。分散型台帳は、車両を構成する部品毎に用意されている。図2は、分散型台帳セット50の構成の一例を示す図である。実施の形態1では、車両を構成する2個の部品(第1部品,第2部品)がデータ管理システム1で管理される例を説明する。すなわち、分散型台帳セット50は、第1部品の部品データの更新状態を時系列に記憶し、第1部品の部品データの証拠チェーンとなる分散型台帳51と、第2部品の部品データの更新状態を時系列に記憶し、第2部品の部品データの証拠チェーンとなる分散型台帳52とを含む。なお、車両を構成する部品がN(2以上の自然数)個であれば、分散型台帳セット50は、N個の分散型台帳を含む。以下では、分散型台帳でデータが管理される部品を「対象部品」とも称する。すなわち、実施の形態1における対象部品は、第1部品および第2部品である。
 分散型台帳51は、第1部品の部品データのハッシュ値を含むレコードを時系列に記憶している。レコードは、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報を含む。
 Keyは、対象部品(第1部品)のIDを示す情報である。第1部品には、k1のIDが割り当てられている。
 Ageは、レコードの世代を示す情報である。分散型台帳51に格納された、第1部品の最初のレコードでは、Ageは0である。第1部品の更新が行なわれ、レコードが追加されると、Ageはインクリメントされる。
 Obj-HVは、第1部品の部品データのハッシュ値である。たとえば、データベース4に登録された第1部品の部品データが更新されると、更新された部品データのハッシュ値が生成され、Obj-HVとされる。ハッシュ値は、ハッシュ関数を用いて部品データをハッシュ化した結果として得られる数値である。
 Nonceは、トランザクションデータの番号を示すナンス値である。つまり、ナンス値は、たとえば、データベース4に記憶された第1部品の部品データが更新された場合に、当該更新された部品データのハッシュ値を分散型台帳51に格納する処理の番号として、クライアントサーバ2(制御装置21)により生成される。ナンス値は、暗号学的に衝突が困難なハッシュ値である。
 Sigは、トランザクションデータを発行したクライアントサーバ2の秘密鍵271を用いて作成された電子署名である。電子署名は、たとえば、Obj-HV(すなわち、第1部品の部品データのハッシュ値)を秘密鍵271により暗号化することにより作成される。あるいは、電子署名は、たとえば、Nonce(ナンス値)を秘密鍵271により暗号化することにより作成されてもよい。
 Prev-HVは、最新(終端)レコードの1つ前の世代のレコード(親レコード)のハッシュ値である。すなわち、Prev-HVは、親レコードのHVである。
 HVは、最新(終端)レコードのハッシュ値である。具体的には、HVは、HVを除くレコードの情報(Key、Age、Obj-HV、Nonce、SigおよびPrev-HV)のハッシュ値(以下「レコードハッシュ値」とも称する)である。
 たとえば、図2に示されるように、分散型台帳51の最新(終端)レコード(Age「2」のレコード)に着目すると、終端レコードのPrev-HVは、親レコード(Age「1」)のHVである「H2」である。次に第1部品の部品データが更新されて、Age「3」のレコードが追加される場合には、Age「3」のレコードのPrev-HVは、Age「2」のレコードのHVである「H3」となる。このように、終端レコードは、親レコードのレコードハッシュ値を含む構造となっている。換言すると、終端レコードのPrev-HVと、親レコードのHVとの間でレコードの連鎖が実現されている。このようにして、分散型台帳51は、DAG構造を成している。
 分散型台帳52は、第2部品の部品データのハッシュ値を含むレコードを時系列に記憶している。レコードは、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報を含む。これらの詳細は、分散型台帳51のレコードと同様であるため、繰り返し説明しない。
 クライアントサーバ2(制御装置21)は、たとえば、入力装置25を介して、あるいは、ユーザ端末装置7を介して部品データの更新操作を受けると、データベース4に記憶された部品データを更新する。そして、クライアントサーバ2(制御装置21)は、更新された部品データのハッシュ値を含むレコードを分散型台帳セット50(分散型台帳51または分散型台帳52)に追加するためのトランザクションデータを生成する。このトランザクションデータには、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報が含まれる。
 トランザクションデータには、さらに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする(ネットワークNWへ送信する)時刻情報、および、当該トランザクションデータの送信者情報が含まれてもよい。時刻情報は、たとえば、対象部品の部品データがデータベース4に記録された時刻を示す情報であってもよい。送信者情報は、たとえば、A企業を示す情報である。なお、トランザクションデータの送信者情報は、さらに詳細に、ネットワークNWへトランザクションデータを送信する操作を実行した部署(A企業の一部門)を示す情報であってもよいし、ネットワークNWへトランザクションデータを送信する操作を実行した個人(A企業の従業員)を示す情報であってもよい。
 <順序性の証明>
 ここで、第1部品の部品データと、第2部品の部品データとの間で、いずれのデータが先に存在したのかを証明したい場合がある。すなわち、第1部品の部品データと、第2部品の部品データとの順序性を証明したい場合がある。順序性を証明する手法として、たとえば、分散型台帳51,52の各々にレコードが追加される毎に、追加されたレコード(終端レコード)のレコードハッシュ値に対してタイムスタンプトークンを取得することで、レコードが追加された時刻を証明し、2つのデータの順序性を証明することが考えられる。しかしながら、当該手法では、分散型台帳51,52にレコードが追加される毎にタイムスタンプトークンを取得しなければならず、工数およびコストが増大してしまう。また、データ管理システム1にかかる処理負荷も増大してしまう。
 そこで、実施の形態1に係るデータ管理システム1では、一方の分散型台帳(たとえば分散型台帳51)のレコードハッシュ値を、他方の分散型台帳(たとえば分散型台帳52)のレコードに組み込むことを可能とする。これにより、2つの分散型台帳51,52を関連付ける。
 図3は、2つの分散型台帳51,52の関連付けを説明するための図である。図3の上段には、第1部品の証拠チェーンである分散型台帳51が模式的に示されており、図3の下段には、第2部品の証拠チェーンである分散型台帳52が模式的に示されている。以下では、第1部品の証拠チェーンを「第1証拠チェーン」とも称し、第2部品の証拠チェーンを「第2証拠チェーン」とも称する。
 第1証拠チェーン(分散型台帳51)には、第1部品の部品データのハッシュ値が時系列に記憶されている。第1部品の部品データが最初にデータベース4に登録されると、その部品データのハッシュ値が含まれるレコード(Age「0」)が分散型台帳51に格納される。次に、第1部品の部品データが更新され、更新された部品データがデータベース4に登録されると、更新された部品データのハッシュ値と、親レコード(Age「0」)のレコードハッシュ値とを含むレコード(Age「1」)が分散型台帳51に格納される。さらに第1部品の部品データが更新され、更新された部品データがデータベース4に登録されると、更新された部品データのハッシュ値と、親レコード(Age「1」)のレコードハッシュ値とを含むレコード(Age「2」)が分散型台帳51に格納される。
 第2証拠チェーン(分散型台帳52)には、第2部品の部品データのハッシュ値が時系列に記憶されている。第2部品の部品データが最初にデータベース4に登録されると、その部品データのハッシュ値が含まれるレコード(Age「0」)が分散型台帳52に格納される。次に、第2部品の部品データが更新され、更新された部品データがデータベース4に登録されると、更新された部品データのハッシュ値と、親レコード(Age「0」)のレコードハッシュ値とを含むレコード(Age「1」)が分散型台帳52に格納される。さらに第2部品の部品データが更新され、更新された部品データがデータベース4に登録されると、更新された部品データのハッシュ値と、親レコード(Age「1」)のレコードハッシュ値とを含むレコード(Age「2」)が分散型台帳52に格納される。
 ここで、上記のように、分散型台帳51および分散型台帳52の各々において、Age「2」のレコードが最新(終端)のレコードであることを想定する。そして、この状態において、入力装置25またはユーザ端末装置7に対して、第1部品の部品データを更新する第1操作が行なわれたことを想定する。さらに、第1操作に加えて、入力装置25またはユーザ端末装置7に対して、第1証拠チェーンを第2証拠チェーンに関連付ける第2操作が行なわれたことを想定する。なお、部品データを更新するための操作(第1操作)は、たとえば、表示装置26またはユーザ端末装置7の表示画面において、対象部品のID(Key)を入力し、表示されている更新ボタンを選択する操作であってもよい。また、証拠チェーン同士を関連付ける操作(第2操作)は、2つの対象部品のID(Key)を入力し、表示されている関連付けボタンを選択する操作であってもよい。第2操作を行なうための表示画面には、たとえば、レコードハッシュ値の作成対象となる対象部品のID(Key)を入力する「作成対象入力欄」、および、レコードハッシュ値の組み込み先となる対象部品のID(Key)を入力する「組み込み対象入力欄」が設けられる。たとえば、作成対象入力欄にk1を入力し、組み込み対象入力欄にk2を入力すれば、第1証拠チェーン(分散型台帳51)のレコードハッシュ値が、第2証拠チェーン(分散型台帳52)のレコードに組み込まれる。ここでは、作成対象入力欄にk1が入力され、かつ、組み込み対象入力欄にk2が入力されたことを想定する。なお、第1操作を行なうための表示画面と、第2操作を行なうための表示画面とは、同一の画面内に同時に表示されてもよい。
 図2および図3を参照して、第1操作および第2操作の2つの操作が行なわれると、制御装置21は、まず、第1操作に応答して、データベース4に記憶されている第1部品の部品データD12を部品データD13に更新する。なお、第1部品の部品データD10が最初にデータベース4に記憶される場合には、制御装置21は、データベース4に第1部品の部品データを新たに記憶させればよい。制御装置21は、部品データD13のハッシュ値と、親レコード(Age「2」)のレコードハッシュ値とを含むレコード(Age「3」)を作成して、分散型台帳51に格納する。また、制御装置21は、Age「3」のレコードを分散型台帳51に追加するためのトランザクションデータを生成する。制御装置21は、通信装置24を介して、生成されたトランザクションデータを、B企業、C企業およびD企業のクライアントサーバ2に送信する。このトランザクションデータを実行するトランザクション処理が各クライアントサーバ2で行なわれることにより、各クライアントサーバ2の分散型台帳51にAge「3」のレコードが格納される。
 次いで、制御装置21は、第2操作に応答して、分散型台帳51の終端レコード(Age「3」)のハッシュ値を「終端ハッシュ値」として生成する。終端ハッシュ値は、終端レコード(Age「3」)のレコードハッシュ値である。制御装置21は、生成された終端ハッシュ値と、分散型台帳52の親レコード(Age「2」)のレコードハッシュ値とを含むレコード(Age「3」)を作成して、分散型台帳52に格納する。分散型台帳52のレコード(Age「3」)に、分散型台帳51の終端ハッシュ値が組み込まれることで、分散型台帳51と分散型台帳52とが関連付けられる。また、制御装置21は、Age「3」のレコードを分散型台帳52に追加するためのトランザクションデータを生成する。制御装置21は、通信装置24を介して、生成されたトランザクションデータを、B企業、C企業およびD企業のクライアントサーバ2に送信する。このトランザクションデータを実行するトランザクション処理が各クライアントサーバ2で行なわれることにより、各クライアントサーバ2の分散型台帳セット50において、分散型台帳51,52同士が関連付けられる。
 具体的な分散型台帳52の構造の一例を示すと、図4のようになる。図4は、分散型台帳セット50の構成の一例を示す図である。分散型台帳52のAge「3」のレコードには、ハッシュ値Hcとハッシュ値H4とがPre-HVとして含まれている。ハッシュ値Hcが親レコード(Age「2」)のレコードハッシュ値であり、ハッシュ値H4が、分散型台帳51のレコード(Age「3」)のレコードハッシュ値(終端ハッシュ値)である。
 上記のように、分散型台帳52のレコードのPre-HVに、分散型台帳51の終端ハッシュ値が組み込まれることにより、分散型台帳51と分散型台帳52とが関連付けられる(第1証拠チェーンと第2証拠チェーンとが関連付けられる)。これによって、第1部品の部品データと第2部品の部品データとの順序性を証明することができる。図3を参照して、たとえば、第1部品の部品データD13は、第2部品の部品データD22がデータベース4に登録にされた後、かつ、第2部品の部品データD23がデータベース4に登録にされる前にデータベース4に登録されていることを証明することができる。
 さらに、分散型台帳52のAge「3」のレコードハッシュ値に対してタイムスタンプトークンを取得しておけば、タイムスタンプトークンにより証明される時刻に第1部品の部品データD10~D13が存在したこと、および、第2部品の部品データD20~D22が存在したことを証明することができる。分散型台帳51,52の各々のレコードに対してタイムスタンプトークンを取得する場合に比べて、工数、費用およびシステム負荷等を低減させることができる。すなわち、分散型台帳51の終端ハッシュ値が組み込まれた分散型台帳52のAge「3」のレコードのレコードハッシュ値に対してタイムスタンプトークンを取得しておけば、第1部品の部品データと第2部品の部品データとの存在の順序性および時刻性を担保することができる。
 なお、第1部品の部品データがD13からD14にさらに更新された場合には、部品データD14のハッシュ値と、分散型台帳51のAge「3」のレコードハッシュ値とを含むレコード(Age「4」)が分散型台帳51に追加される。同様に、第2部品の部品データがD22からD23にさらに更新された場合には、部品データD23のハッシュ値と、分散型台帳52のAge「3」のレコードハッシュ値とを含むレコード(Age「4」)が分散型台帳52に追加される。
 <機能ブロック>
 図5は、第1操作に応答する処理を実行するための制御装置21の機能ブロック図である。図5を参照して、制御装置21は、情報取得部2101と、ハッシュ生成部2102と、ナンス生成部2103と、電子署名部2104と、トランザクションデータ生成部2105と、トランザクションデータ送信部2106とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104トランザクションデータ生成部2105、および、トランザクションデータ送信部2106として機能する。なお、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104、トランザクションデータ生成部2105、および、トランザクションデータ送信部2106は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
 入力装置25あるいはユーザ端末装置7に対して、第1部品の部品データを更新する第1操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第1操作が行なわれたことを示す第1要求を出力する。
 情報取得部2101は、入力装置25あるいはユーザ端末装置7から、第1要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25を操作して、対象部品の部品データをデータベース4に保存(登録/更新)すると、第1要求が情報取得部2101に入力される。第1要求には、対象部品を特定するためのID(Key)が含まれている。情報取得部2101は、第1要求を取得すると、第1要求をハッシュ生成部2102およびナンス生成部2103に出力する。
 ハッシュ生成部2102は、第1要求を受けると、たとえばデータベース4から対象部品の部品データを読み出して部品データのハッシュ値を生成する。ハッシュ生成部2102は、生成されたハッシュ値および対象部品のIDを、電子署名部2104およびトランザクションデータ生成部2105に出力する。
 ナンス生成部2103は、第1要求を受けると、ナンス値を生成する。ナンス値は、暗号学的に衝突が困難なハッシュ値である。ナンス生成部2103は、生成されたナンス値および対象部品のIDを、トランザクションデータ生成部2105に出力する。なお、電子署名の作成にナンス値が用いられる場合には、ナンス生成部2103は、ナンス値および対象部品のIDを電子署名部2104に出力してもよい。
 電子署名部2104は、記憶装置27から秘密鍵271を読み出す。電子署名部2104は、ハッシュ生成部2102から受けたハッシュ値を秘密鍵271により暗号化することで電子署名を作成する。電子署名部2104は、作成された電子署名および対象部品のIDをトランザクションデータ生成部2105に出力する。また、電子署名部2104は、ナンス生成部2103から受けたナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。また、電子署名部2104は、ハッシュ値およびナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。
 トランザクションデータ生成部2105は、ネットワークNWへ送信するためのトランザクションデータを生成する。たとえば、トランザクションデータ生成部2105は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。トランザクションデータ生成部2105は、たとえば、分散型台帳セット50にKeyを照会させることで親レコードのAgeを認識し、親レコードのAgeをインクリメントして、追加するレコードのAgeとする。トランザクションデータ生成部2105は、ハッシュ生成部2102により生成されたハッシュ値をObj-HVとし、ナンス生成部2103により生成されたナンス値をNonceとし、電子署名部2104により作成された電子署名をSigとする。また、トランザクションデータ生成部2105は、親レコードのレコードハッシュ値をPrev-HVとする。トランザクションデータ生成部2105は、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HVの情報をハッシュ化して、HVとする。トランザクションデータには、さらに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする(ネットワークNWへ送信する)時刻情報、および、当該トランザクションデータの送信者情報が含まれてもよい。トランザクションデータ生成部2105は、生成されたトランザクションデータをトランザクションデータ送信部2106に出力する。
 トランザクションデータ送信部2106は、トランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
 図6は、第2操作に応答する処理を実行するための制御装置21の機能ブロック図である。図6を参照して、制御装置21は、情報取得部2111と、終端ハッシュ生成部2112と、ナンス生成部2113と、電子署名部2114と、トランザクションデータ生成部2115と、トランザクションデータ送信部2116とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2111、終端ハッシュ生成部2112、ナンス生成部2113、電子署名部2114、トランザクションデータ生成部2115、および、トランザクションデータ送信部2116として機能する。なお、情報取得部2111、終端ハッシュ生成部2112、ナンス生成部2113、電子署名部2114、トランザクションデータ生成部2115、および、トランザクションデータ送信部2116は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
 入力装置25あるいはユーザ端末装置7に対して、第1証拠チェーン(分散型台帳51)と第2証拠チェーン(分散型台帳52)とを関連付ける第2操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第2操作が行なわれたことを示す第2要求を出力する。
 情報取得部2111は、入力装置25あるいはユーザ端末装置7から、第2要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25を操作して、第1操作に加えて、証拠チェーン同士を関連付ける関連付けボタンを選択すると(第2操作をすると)、第2要求が情報取得部2111に入力される。第2要求には、終端ハッシュ値の作成対象となる対象部品のID(たとえばk1)と、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)とが含まれている。情報取得部2111は、第2要求を取得すると、第2要求を終端ハッシュ生成部2112およびナンス生成部2113に出力する。
 終端ハッシュ生成部2112は、終端ハッシュ値の作成対象となる対象部品のIDにより特定される分散型台帳(たとえば分散型台帳51)の最新のレコード(証拠チェーンの終端のレコード)のハッシュ値を終端ハッシュ値として生成する。終端ハッシュ生成部2112は、生成された終端ハッシュ値、および、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)を、電子署名部2114およびトランザクションデータ生成部2115に出力する。
 ナンス生成部2113は、第2要求を受けると、ナンス値を生成する。ナンス生成部2113は、生成されたナンス値、および、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)を、トランザクションデータ生成部2115に出力する。なお、電子署名の作成にナンス値が用いられる場合には、ナンス生成部2113は、ナンス値、および、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)を電子署名部2114に出力してもよい。
 電子署名部2114は、記憶装置27から秘密鍵271を読み出す。電子署名部2114は、終端ハッシュ生成部2112から受けた終端ハッシュ値を秘密鍵271により暗号化することで電子署名を作成する。電子署名部2114は、作成された電子署名、および、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)をトランザクションデータ生成部2115に出力する。また、電子署名部2114は、ナンス生成部2113から受けたナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。また、電子署名部2114は、終端ハッシュ値およびナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。
 トランザクションデータ生成部2115は、ネットワークNWへ送信するためのトランザクションデータを生成する。たとえば、トランザクションデータ生成部2115は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。トランザクションデータ生成部2115は、終端ハッシュ値の組み込み先となる対象部品のID(たとえばk2)をKeyとする。また、トランザクションデータ生成部2115は、終端ハッシュ生成部2112により生成された終端ハッシュ値をObj-HVとする。トランザクションデータ生成部2115のその他の機能は、図5で説明したトランザクションデータ生成部2105と基本的に同様である。
 トランザクションデータ送信部2116は、トランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
 図7は、受信したトランザクションデータを実行するための制御装置21の機能ブロック図である。図7を参照して、制御装置21は、トランザクションデータ取得部2121と、署名検証部2122と、レコード作成部2123と、台帳更新部2124と、出力部2125とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、トランザクションデータ取得部2121、署名検証部2122、レコード作成部2123、台帳更新部2124、および、出力部2125として機能する。なお、トランザクションデータ取得部2121、署名検証部2122、レコード作成部2123、台帳更新部2124、および、出力部2125は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
 トランザクションデータ取得部2121は、他のクライアントサーバ2から送信されたトランザクションデータを取得する。トランザクションデータ取得部2121は、取得されたトランザクションデータを署名検証部2122に出力する。
 署名検証部2122は、トランザクションデータに含まれる電子署名(Sig)の有効性を検証する。まず、署名検証部2122は、トランザクションデータに含まれる送信者情報に基づいて、当該トランザクションデータの送信元のクライアントサーバ2を特定する。そして、署名検証部2122は、特定されたクライアントサーバ2の公開鍵(複数の公開鍵272のうちの1つ)を記憶装置27から読み出す。署名検証部2122は、読み出された公開鍵を用いて、トランザクションデータに含まれる電子署名を復号する。上述のとおり、電子署名は、部品データのハッシュ値または終端ハッシュ値が、送信元のクライアントサーバ2の秘密鍵を用いて暗号化されたものである。署名検証部2122は、復号した値と、トランザクションデータに含まれているObj-HV(ハッシュ値または終端ハッシュ値)とを比較する。両者が一致することを確認することにより、署名検証部2122は、電子署名の有効性を認める。
 レコード作成部2123は、電子署名の有効性が認められた場合に、トランザクションデータに基づいて、分散型台帳セット50に追加するレコードを作成する。レコード作成部2123は、トランザクションデータから、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HV、および、HVの情報を読み出して、これらの情報を含むレコードを作成する。
 台帳更新部2124は、レコード作成部2123により作成されたレコードを分散型台帳セット50に追加し、分散型台帳セット50を更新する。具体的には、台帳更新部2124は、作成されたレコードのKeyを参照し、当該レコードを追加する分散型台帳を特定する。たとえば、上述した、第1部品の部品データを更新する第1操作に応じて生成されたトランザクションデータは、第1部品のIDを示す「k1」をKeyとして有している。このトランザクションデータに基づいて作成されたレコードも、「k1」をKeyとして有する。よって、台帳更新部2124は、当該レコードを、第1部品の部品データの証拠チェーンである分散型台帳51に追加する。また、上述した、第1証拠チェーンを第2証拠チェーンに関連付ける第2操作に応じて生成されたトランザクションデータは、第2部品のIDを示す「k2」をKeyとして有している。このトランザクションデータに基づいて作成されたレコードも、「k2」をKeyとして有する。よって、台帳更新部2124は、当該レコードを、第2部品の部品データの証拠チェーンである分散型台帳52に追加する。
 台帳更新部2124は、分散型台帳セット50の更新が完了すると、その旨を出力部2125に出力する。
 出力部2125は、トランザクションデータを実行する処理(トランザクション処理)が完了したことを、トランザクションデータの送信元のクライアントサーバ2に送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクション処理の完了の報告が、トランザクションデータの送信元のクライアントサーバ2に送信される。
 図8は、タイムスタンプトークンを取得するための制御装置21の機能ブロック図である。図8を参照して、制御装置21は、情報取得部2131と、レコードハッシュ作成部2132と、タイムスタンプトークン取得部2133と、出力部2134とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2131、レコードハッシュ作成部2132、タイムスタンプトークン取得部2133、および、出力部2134として機能する。なお、情報取得部2131、レコードハッシュ作成部2132、タイムスタンプトークン取得部2133、および、出力部2134は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
 入力装置25あるいはユーザ端末装置7に対して、タイムスタンプトークンの取得を要求する第3操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第3操作が行なわれたことを示す第3要求を出力する。
 情報取得部2131は、入力装置25あるいはユーザ端末装置7から、第3要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25を操作して、表示装置26の表示画面上で、タイムスタンプトークンを取得する対象のIDを入力し、表示装置26に表示されたタイムスタンプトークン取得ボタンを選択すると(第3操作をすると)、第3要求が情報取得部2131に入力される。第3要求には、対象部品を特定するためのID(Key)が含まれている。情報取得部2131は、第3要求を取得すると、第3要求をレコードハッシュ作成部2132に出力する。
 レコードハッシュ作成部2132は、第3要求から対象部品のIDを特定し、タイムスタンプトークンを取得する(レコードハッシュ値を作成する)対象となる分散型台帳を特定する。たとえば、第3要求に第2部品のIDである「k2」が含まれている場合には、レコードハッシュ作成部2132は、分散型台帳52の最新のレコード(終端レコード)のレコードハッシュ値を作成する。レコードハッシュ作成部2132は、作成されたレコードハッシュ値をタイムスタンプトークン取得部2133に出力する。
 タイムスタンプトークン取得部2133は、レコードハッシュ作成部2132から受けたレコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。
 レコードハッシュ値を受信した時刻認証局8は、クライアントサーバ2にタイムスタンプトークンを返信する。
 タイムスタンプトークン取得部2133は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを受信する。タイムスタンプトークン取得部2133は、取得されたタイムスタンプトークンを出力部2134に出力する。
 出力部2134は、タイムスタンプトークン取得部2133から受けたタイムスタンプトークンを記憶装置27に記憶させる。あるいは、出力部2134は、タイムスタンプトークン取得部2133から受けたタイムスタンプトークンをデータベース4に記憶させてもよい。これにより、存在時刻の証明を取得することができる。
 また、出力部2134は、タイムスタンプトークン取得部2133から受けたタイムスタンプトークンを、分散型台帳セット50に保持させてもよい。たとえば、出力部2134は、分散型台帳52のレコードハッシュ値に対してタイムスタンプトークンを取得した場合であれば、タイムスタンプトークンを含めたレコードを作成し、当該レコードを分散型台帳52に追加する。そして、出力部2134は、タイムスタンプトークンをObj-HVとしたトランザクションデータを生成して、当該トランザクションデータをネットワークNWに参加するクライアントサーバ2に送信するための制御信号を、通信装置24に出力する。これにより、タイムスタンプトークンが各クライアントサーバ2の分散型台帳セット50に追加される。
 また、出力部2134は、タイムスタンプトークン取得部2133から受けたタイムスタンプトークンを外部サーバ9に送信するための制御信号を、通信装置24に出力してもよい。外部サーバ9は、A企業、B企業、C企業およびD企業のいずれでもない管理主体によって管理されるサーバである。タイムスタンプトークンを改ざんするためには、外部サーバ9で管理されているタイムスタンプトークンも改ざんしなければならない。タイムスタンプトークンを外部サーバ9でも管理することによって、タイムスタンプトークンの耐改ざん性を高めることができる。
 <フローチャート>
 図9は、第1要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図9に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第1要求を受けた際に、制御装置21によって実行される。なお、図9および後述する図10,11,12に示すフローチャートの各ステップ(以下ステップを「S」と略す)は、制御装置21によるソフトウェア処理によって実現される場合について説明するが、その一部あるいは全部が制御装置21内に作製されたハードウェア(電子回路)によって実現されてもよい。
 S1において、制御装置21は、ナンス値を生成する。このナンス値は、トランザクションデータの番号として用いられる。
 S2において、制御装置21は、データベース4から対象部品の部品データを読み出して部品データのハッシュ値を生成する。
 S3において、制御装置21は、記憶装置27から秘密鍵271を読み出し、秘密鍵271を用いて、S2で生成されたハッシュ値を暗号化して電子署名を作成する。なお、制御装置21は、秘密鍵271を用いて、S1で生成されたナンス値を暗号化して電子署名を作成してもよい。また、制御装置21は、秘密鍵271を用いて、S2で生成されたハッシュ値およびS1で生成されたナンス値を暗号化して電子署名を作成してもよい。
 S4において、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。具体的には、制御装置21は、第1要求に含まれる対象部品のIDをKeyとする。また、制御装置21は、S1で生成されたナンス値をNonceとし、S2で生成されたハッシュ値をObj-HVとし、S3で作成された電子署名をSigとする。また、制御装置21は、分散型台帳セット50にKeyを照会させて親レコードのAgeを認識し、親レコードのAgeをインクリメントしたものをAgeとする。また、制御装置21は、親レコードのレコードハッシュをPrev-HVとする。また、制御装置21は、HVの情報を除く、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HVの情報をハッシュ化して、HVとする。また、制御装置21は、トランザクションデータに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする時刻情報、および/または、当該トランザクションデータの送信者情報を含めてもよい。
 S5において、制御装置21は、S4で生成されたトランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
 図10は、第2要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図10に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第2要求を受けた際に、制御装置21によって実行される。
 S11において、制御装置21は、ナンス値を生成する。このナンス値は、トランザクションデータの番号として用いられる。
 S12において、制御装置21は、分散型台帳の最新のレコード(証拠チェーンの終端レコード)をハッシュ化して、終端ハッシュ値を作成する。上述のとおり、第2操作を行なうための表示画面には、終端ハッシュ値の作成対象となる対象部品のIDを入力する「作成対象入力欄」、および、終端ハッシュ値の組み込み先となる対象部品のIDを入力する「組み込み対象入力欄」が設けられている。たとえば、作成対象入力欄にk1、組み込み対象入力欄にk2が入力された場合には、制御装置21は、分散型台帳51の最新のレコードをハッシュ化して、終端ハッシュ値を作成する。
 S13において、制御装置21は、記憶装置27から秘密鍵271を読み出し、秘密鍵271を用いて、S12で生成された終端ハッシュ値を暗号化して電子署名を作成する。なお、制御装置21は、秘密鍵271を用いて、S11で生成されたナンス値を暗号化して電子署名を作成してもよい。また、制御装置21は、秘密鍵271を用いて、S12で生成された終端ハッシュ値およびS11で生成されたナンス値を暗号化して電子署名を作成してもよい。
 S14において、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。制御装置21は、「組み込み対象入力欄」に入力されたID(上記の例ではk2)をKeyとする。また、制御装置21は、S12で生成された終端ハッシュ値をObj-HVとする。S14における、その他の処理は、図9のS4の処理と基本的に同様であるため、繰り返し説明しない。
 S15において、制御装置21は、S14で生成されたトランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
 図11は、トランザクションデータを受信した場合に実行される処理の手順を示すフローチャートである。図11に示すフローチャートの処理は、トランザクションデータを受信した際に、制御装置21によって実行される。
 S21において、制御装置21は、受信したトランザクションデータに含まれる送信者情報に基づいて、当該トランザクションデータの送信元のクライアントサーバ2を特定する。
 S22において、制御装置21は、S21で特定されたクライアントサーバ2の公開鍵を記憶装置27から読み出す。
 S23において、制御装置21は、S22で読み出された公開鍵を用いて、トランザクションデータに含まれる電子署名を復号する。
 S24において、制御装置21は、S23で復号した電子署名の有効性を検証する。具体的には、制御装置21は、電子署名を復号した値と、トランザクションデータに含まれているハッシュ値(あるいは終端ハッシュ値)とを比較する。両者が一致しなかった場合には、制御装置21は、電子署名の有効性を認めず(S24においてNO)、処理をS25に進める。両者が一致した場合には、制御装置21は、電子署名の有効性を認め(S24においてYES)、処理をS26に進める。
 S25において、制御装置21は、電子署名が有効なものでないため、今回受信したトランザクションデータを破棄し、処理を終了する。なお、制御装置21は、トランザクションデータが改ざんされた可能性がある旨を表示装置26に表示させてもよい。
 S26において、制御装置21は、受信したトランザクションデータからKey、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を読み出して、これらの情報を含むレコードを作成する。
 S27において、制御装置21は、S26で作成されたレコードのKeyに基づいて、当該レコードを追加する分散型台帳を特定する。そして、制御装置21は、特定された分散型台帳にレコードを追加する。これにより、分散型台帳セット50が更新される。
 S28において、制御装置21は、トランザクション処理が完了したことを示す通知(完了報告)を、トランザクションデータの送信元のクライアントサーバ2に送信する。
 図12は、タイムスタンプトークンを取得する処理の手順を示すフローチャートである。図12に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第3要求を受けた際に、制御装置21によって実行される。
 S31において、制御装置21は、第3要求に含まれている対象部品のIDに基づいて、タイムスタンプトークンを取得する対象となる分散型台帳(分散型台帳51または分散型台帳52)を特定する。
 S32において、制御装置21は、S31で特定された分散型台帳の最新のレコード(終端レコード)のレコードハッシュ値を生成する。
 S33において、制御装置21は、S32で生成されたレコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。
 S34において、制御装置21は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを受信する。これにより、対象部品の部品データの存在時刻の証明が取得される。
 S35において、制御装置21は、S34で取得されたタイムスタンプトークンを記憶装置27に記憶させる。なお、制御装置21は、タイムスタンプトークンをデータベース4に記憶させてもよい。さらに、制御装置21は、タイムスタンプトークンを分散型台帳セット50に保持させてもよい。
 S36において、制御装置21は、S34で取得されたタイムスタンプトークンを外部サーバ9に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、外部サーバ9にタイムスタンプトークンが送信される。なお、制御装置21は、タイムスタンプトークンを分散型台帳セット50に追加するためのトランザクションデータを生成し、当該トランザクションデータをネットワークNWに送信するための制御信号を、通信装置24に出力してもよい。
 以上のように、実施の形態1に係るデータ管理システム1において、クライアントサーバ2は、2つの分散型台帳51,52を含む分散型台帳セット50を保持する。分散型台帳51は、第1部品の部品データの存在を証明するための証拠チェーンであり、分散型台帳52は、第2部品の部品データの存在を証明するための証拠チェーンである。クライアントサーバ2は、ユーザからの求めに応じて、2つの分散型台帳51,52を関連付ける機能を有する。クライアントサーバ2は、一方の分散型台帳の終端ハッシュ値を、他方の分散型台帳のレコードに組み込む。終端ハッシュ値が組み込まれたレコードを基準として、第1部品の部品データと、第2部品の部品データとの存在の順序性を証明することができる。
 また、クライアントサーバ2は、終端ハッシュ値が組み込まれたレコードに対してタイムスタンプトークンを取得する。終端ハッシュ値が組み込まれたレコードに対してタイムスタンプトークンを取得すれば、第1部品の部品データおよび第2部品の部品データの存在時刻の証明(すなわち、タイムスタンプトークンが示す時刻よりも前に部品データが存在していたことの証明)を取得することができる。終端ハッシュ値が組み込まれたレコードに対してタイムスタンプトークンを取得すれば、分散型台帳51,52のそれぞれに対してタイムスタンプトークンを取得する場合に比べ、工数、コスト、および、システム負荷を低減させることができる。
 また、クライアントサーバ2は、タイムスタンプトークンを外部サーバ9に送信する。タイムスタンプトークンを外部サーバ9でも管理することにより、タイムスタンプトークンの耐改ざん性を高めることができる。
 [変形例1]
 実施の形態1では、ユーザ操作(第2操作)に起因する第2要求に応じて2つの証拠チェーンの関連付けが行なわれる例について説明したが、2つの証拠チェーンの関連付けは、自動で行なわれてもよい。たとえば、対象部品の部品データの更新がM(自然数)回実行される毎に、当該対象部品の証拠チェーン(分散型台帳)の終端ハッシュ値を、他の証拠チェーン(分散型台帳)のレコードに組み込むようにしてもよい。このような構成であっても、実施の形態1と同様の効果を奏することができる。
 [実施の形態2]
 実施の形態1では、プラットフォームサーバ5が、ネットワークNWへの参加を許可する機能を有する例について説明した。そして、トランザクションデータのファイナリティは、ネットワークNWへの参加が許可されたクライアントサーバ2間で電子署名の有効性の確認することにより与えられた。実施の形態2では、プラットフォームサーバ6が、ネットワークNWへの参加を許可する機能に加えて、トランザクションデータにファイナリティを与える機能を有する例について説明する。
 図13は、実施の形態2に係るデータ管理システム1Aの概略的な構成を示す図である。データ管理システム1Aは、4台のクライアントサーバ3と、プラットフォームサーバ6と、時刻認証局8とを備える。実施の形態1と同様に、4台のクライアントサーバ3の各々は、異なる企業(たとえば、A企業、B企業、C企業およびD企業)に帰属するサーバである。以下においては、A企業のクライアントサーバ3について代表的に説明するが、B企業、C企業およびD企業のクライアントサーバ3も同様の機能を有する。
 プラットフォームサーバ6は、実施の形態1に係るプラットフォームサーバ5と同様に、ネットワークNWを管理し、各クライアントサーバ3からのネットワークNWへの参加申請を受け付ける。プラットフォームサーバ6は、プラットフォームサーバ6の管理者による参加を許可する操作に基づき、または、所定の条件の判定結果に基づき、クライアントサーバ3のネットワークNWへの参加を許可する。実施の形態2においても、A企業、B企業、C企業およびD企業のそれぞれに帰属する4台のクライアントサーバ3に対して、ネットワークNWへの参加が許可されている。
 4台のクライアントサーバ3およびプラットフォームサーバ6は、ネットワークNWを形成している。クライアントサーバ3の各々には、分散型台帳基盤のソフトウェアが導入されており、導入された分散型台帳基盤のソフトウェアが機能することにより、クライアントサーバ3の各々がノードとして機能する。クライアントサーバ3は、実施の形態1に係るクライアントサーバ2と同様に、ユーザ端末装置7と通信可能に構成されている。
 また、クライアントサーバ3には、実施の形態1に係るクライアントサーバ2と同様に、データベース4が接続されている。クライアントサーバ3(制御装置31)は、入力装置35への入力、あるいは、ユーザ端末装置7からの要求に応じて、部品データを記憶/更新するための制御信号を生成し、データベース4に出力する。
 クライアントサーバ3は、データベース4に部品データを記憶/更新すると、当該部品データのハッシュ値を作成し、当該ハッシュ値を、プラットフォームサーバ6に保有される台帳、および、各クライアントサーバ3に保有される分散型台帳に格納するためのトランザクションデータを生成する。そして、クライアントサーバ3は、生成されたトランザクションデータをプラットフォームサーバ6に送信する。
 プラットフォームサーバ6は、トランザクションデータにファイナリティを与える機能を有する。プラットフォームサーバ6は、台帳セット60を保有し、クライアントサーバ3から受けるトランザクションデータを処理して、台帳セット60を更新する。プラットフォームサーバ6は、台帳セット60を更新すると、更新により台帳に追加されたレコードのサマリ(後述のプルーフレコード)を、ネットワークNWに参加する全てのクライアントサーバ3に送信する。クライアントサーバ3はコミットレコードを格納するコミットテーブル374を記憶する。コミットテーブル374は、本開示に係る「分散型台帳」の一例に相当する。
 図14は、台帳セット60の構成の一例を示す図である。台帳セット60は、台帳67と、台帳68とを含む。台帳67は、実施の形態1に係る分散型台帳51と同様に、第1部品の部品データの更新状態を時系列に記憶し、第1部品の部品データの証拠チェーンを形成する。台帳68は、実施の形態1に係る分散型台帳52と同様に、第2部品の部品データの更新状態を時系列に記憶し、第2部品の部品データの証拠チェーンを形成する。台帳セット60、台帳67および台帳68は、実施の形態1に係る分散型台帳セット50、分散型台帳51および分散型台帳52とそれぞれ同様の構成を有する。そのため、これらの詳細な説明は繰り返さない。
 再び図13を参照し、クライアントサーバ3は、制御装置31と、ROM32と、RAM33と、通信装置34と、入力装置35と、表示装置36と、記憶装置37とを備える。制御装置31、ROM32、RAM33、通信装置34、入力装置35、表示装置36、および、記憶装置37は、バス39に接続されている。ROM32、RAM33、通信装置34、入力装置35、および、表示装置36は、基本的に、実施の形態1に係るクライアントサーバ2のROM22、RAM23、通信装置24、入力装置25、および、表示装置26とそれぞれ同様の構成であるため、その説明は繰り返さない。
 記憶装置37は、秘密鍵371およびプルーフデータ372を記憶している。秘密鍵371は、A企業の秘密鍵である。たとえば、クライアントサーバ3がネットワークNWに最初に参加するにあたり、制御装置31は、秘密鍵および公開鍵を生成する。そして、制御装置31は、生成された公開鍵を認証局(図示せず)に送信して、認証を受ける。認証局は、公開鍵の情報を含めた電子証明書を発行する。制御装置31は、認証を受けた公開鍵に対応する秘密鍵371を記憶装置37に記憶させる。また、制御装置31は、認証を受けた公開鍵(電子証明書)651を、プラットフォームサーバ6に送信する。
 プルーフデータ372は、サスペンションテーブル373と、コミットテーブル374とを含む。図15は、サスペンションテーブル373の構成の一例を説明するための図である。図16は、コミットテーブル374の構成の一例を説明するための図である。サスペンションテーブル373およびコミットテーブル374は、対象部品毎にレコードを有する。
 図15を参照し、サスペンションテーブル373は、未使用のトランザクションデータに含まれる所定種類の情報を含む。具体的には、サスペンションテーブル373は、たとえば、KeyおよびNonceの情報を含んだサスペンションレコードを記憶する。制御装置31は、第1要求または第2要求に応答して生成されるトランザクションデータに含まれる情報のうちの、KeyおよびNonceの情報をサスペンションレコードとして、サスペンションテーブル373に格納する。入力装置35あるいはユーザ端末装置7からクライアントサーバ3が受ける第1要求および第2要求には、対象部品のIDが含まれている。たとえば、第1要求の対象が第1部品であれば「k1」を示すIDが、第1要求の対象が第2部品であれば「k2」を示すIDが、第1要求に含まれている。すなわち、第1要求または第2要求に含まれている対象部品のIDがKeyとなる。また、第1要求または第2要求を受けると制御装置31は、ナンス値を生成する。当該ナンス値は、第1要求または第2要求の番号(すなわち、トランザクションデータの番号)を表わす。制御装置31は、KeyおよびNonceの情報を含むサスペンションレコードを作成し、当該サスペンションレコードをサスペンションテーブル373に登録する。図15には、サスペンションテーブル373に、k1のKeyを含むサスペンションレコードが登録されている例が示されている。なお、以下では、第1要求と第2要求とを特に区別しない場合には、両者を総称して「更新要求」とも称する。
 更新要求に応答する処理が実行されると(すなわち、トランザクションデータが使用されると)、制御装置31は、トランザクション処理の実行に使用されたトランザクションデータに含まれるKeyと同様のKeyの情報を含むサスペンションレコードを、サスペンションテーブル373から削除する。
 サスペンションテーブル373には、同じKeyの情報を含むサスペンションレコードが重複して登録されない。サスペンションレコードをサスペンションテーブル373に登録するにあたり、制御装置31は、登録対象のサスペンションレコードに含まれるKeyと一致するKeyを含んだサスペンションレコードが既にサスペンションテーブル373に登録されているか否かを判断する。制御装置31は、登録対象のサスペンションレコードが含むKeyと一致するKeyを含んだサスペンションレコードがサスペンションテーブル373に登録されていなければ、サスペンションレコードをサスペンションテーブル373に登録する。制御装置31は、登録対象のサスペンションレコードが含むKeyと一致するKeyを含んだサスペンションレコードがサスペンションテーブル373に登録されていれば、一致するKeyを含んだサスペンションレコードがサスペンションテーブル373から削除されるのを待つ。つまり、図15に示す例においては、サスペンションテーブル373に、k2のKeyを含むサスペンションレコードは登録できるが、k1のKeyを含むサスペンションレコードは登録できない。
 コミットテーブル374は、使用済みのトランザクションデータに含まれる所定種類の情報を含む。具体的には、コミットテーブル374は、Key、Age、HV、および、Nonceの情報を含むコミットレコードを記憶する。コミットテーブル374は、k1のKeyを有するコミットレコードを格納するコミットデータ375と、k2のKeyを有するコミットレコードを格納するコミットデータ376とを含む。
 プラットフォームサーバ6は、トランザクション処理を実行して、台帳セット60の台帳を更新すると、プルーフレコードを作成し、当該プルーフレコードをネットワークNWに参加する全てのクライアントサーバ3に送信する。プルーフレコードは、たとえば、トランザクションデータを使用して実行されたトランザクション処理により台帳に追加されたレコードのうちの、Key、Age、HV、および、Nonceの情報を含んで構成されたレコードである。
 プルーフレコードを受けると、制御装置31は、当該プルーフレコードをコミットレコードとして、コミットテーブル374(コミットデータ375またはコミットデータ376)に追加する。そして、制御装置31は、追加したコミットレコードに含まれるKeyと同様のKeyを含むサスペンションレコードを、サスペンションテーブル373から削除する。
 プラットフォームサーバ6は、制御装置61と、ROM62と、RAM63と、通信装置64と、記憶装置65とを備える。制御装置61、ROM62、RAM63、通信装置64、および、記憶装置65は、バス69に接続されている。
 制御装置61は、CPUを含む集積回路によって構成される。制御装置61は、ROM62に格納されている各種プログラムをRAM63に展開して実行する。各種プログラムには、オペレーティングシステム等が含まれる。RAM63は、ワーキングメモリとして機能し、各種プログラムの実行に必要な各種データを一時的に格納する。制御装置61は、クライアントサーバ3からトランザクションデータを受信し、トランザクション処理を実行する。
 通信装置64は、ネットワークNWに参加しているクライアントサーバ3との通信が可能に構成される。
 記憶装置65は、複数の公開鍵651および台帳セット60を記憶している。複数の公開鍵651は、ネットワークNWに参加しているクライアントサーバ3を管理する企業の公開鍵を含む。具体的には、複数の公開鍵651は、A企業の公開鍵、B企業の公開鍵、C企業の公開鍵およびD企業の公開鍵を含む。
 台帳セット60は、上述のとおり、実施の形態1に係る分散型台帳セット50と同様の構成を有するため、繰り返し説明しない。
 以下、フローチャートを示しながら、実施の形態2における第1要求、第2要求および第3要求への応答の処理について順に説明する。
 図17は、更新要求(第1要求,第2要求)を受けた場合にデータ管理システム1Aで実行される処理の手順を示すフローチャートである。図17に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から更新要求(第1要求,第2要求)を受けた際に、クライアントサーバ3の制御装置31によって開始される。
 S40において、クライアントサーバ3の制御装置31は、ナンス値を生成する。このナンス値は、更新要求に応じて生成されるトランザクションデータの番号として用いられる。
 S41において、クライアントサーバ3の制御装置31は、サスペンションレコードを生成する。具体的には、クライアントサーバ3の制御装置31は、更新要求に含まれている対象部品のIDを読み出してKeyの情報とし、S40で生成されたナンス値をNonceの情報として、サスペンションレコードを生成する。
 S42において、クライアントサーバ3の制御装置31は、S41で生成されたサスペンションレコードをサスペンションテーブル373に登録できるか否かを判断する。S41で生成されたサスペンションレコードと同様のKeyの情報を有するサスペンションレコードがサスペンションテーブル373に登録されている場合、クライアントサーバ3の制御装置31は、否定判断をして(S42においてNO)、サスペンションテーブル373から同様のKeyの情報を有するサスペンションレコードが削除されるのを待つ。一方、S41で生成されたサスペンションレコードと同様のKeyの情報を有するサスペンションレコードがサスペンションテーブル373に登録されていない場合、クライアントサーバ3の制御装置31は、肯定判断をして(S42においてYES)、処理をS43に進める。
 S43において、クライアントサーバ3の制御装置31は、サスペンションテーブル373にサスペンションレコードを登録する。
 S44において、クライアントサーバ3の制御装置31は、更新要求に応じるためのトランザクションデータを生成する。具体的には、クライアントサーバ3の制御装置31は、更新要求が第1要求である場合には、図9において説明したS2~S5の処理と同様の処理を実行してトランザクションデータを生成し、更新要求が第2要求である場合には、図10において説明したS12~S15の処理と同様の処理を実行してトランザクションデータを生成する。各処理の詳細については、図9および図10において説明したとおりであるので、繰り返し説明しない。
 S45において、クライアントサーバ3の制御装置31は、S44で生成したトランザクションデータをプラットフォームサーバ6に送信するための制御信号を通信装置34に出力する。これにより、通信装置34を介して、トランザクションデータがプラットフォームサーバ6に送信される。
 S50において、プラットフォームサーバ6の制御装置61は、受信したトランザクションデータに含まれる電子署名の有効性を検証するために、電子署名を復号する。具体的には、プラットフォームサーバ6の制御装置61は、図11において説明したS21~S23の処理と同様の処理を実行して、電子署名を復号する。各処理の詳細については、図11において説明したとおりであるので、繰り返し説明しない。
 S51において、プラットフォームサーバ6の制御装置61は、S50で復号した電子署名の有効性を検証する。具体的には、プラットフォームサーバ6の制御装置61は、電子署名を復号した値と、トランザクションデータに含まれているハッシュ値(第1要求に応じて生成されたトランザクションデータにおいては、対象部品の部品データのハッシュ値であり、第2要求に応じて生成されたトランザクションデータにおいては、終端ハッシュ値である)とを比較する。両者が一致しなかった場合には、プラットフォームサーバ6の制御装置61は、電子署名の有効性を認めず(S51においてNO)、処理をS52に進める。両者が一致した場合には、プラットフォームサーバ6の制御装置61は、電子署名の有効性を認め(S51においてYES)、処理をS53に進める。
 S52において、プラットフォームサーバ6の制御装置61は、クライアントサーバ3から受けたトランザクションデータに改ざんの可能性があると判断して、トランザクションデータを破棄し、改ざんの可能性があることを示す異常報告を作成する。そして、プラットフォームサーバ6の制御装置61は、処理をS56に進める。
 S53において、プラットフォームサーバ6の制御装置61は、トランザクション処理を実行する。具体的には、プラットフォームサーバ6の制御装置61は、図11において説明したS26,S27の処理と同様の処理を実行し、トランザクションデータに含まれるKeyの情報により特定される台帳のレコードを生成して、当該台帳に生成されたレコードを追加し、台帳セット60を更新する。
 S54において、プラットフォームサーバ6の制御装置61は、プルーフレコードを生成する。プルーフレコードは、台帳に追加されたレコードに含まれる情報のうちの、Key、Age、HV、および、Nonceの情報を含む。
 S55において、プラットフォームサーバ6の制御装置61は、台帳セット60の更新が完了したこと(すなわち、トランザクションデータを処理したこと)を示す正常報告を作成する。プラットフォームサーバ6の制御装置61は、正常報告にプルーフレコードを含める。
 S56において、プラットフォームサーバ6の制御装置61は、S52において作成された異常報告、または、S55において作成された正常報告をクライアントサーバ3に送信するための制御信号を通信装置64に出力する。これにより、通信装置64を介して、異常報告または正常報告がクライアントサーバ3に送信される。
 また、S56において、プラットフォームサーバ6の制御装置61は、プルーフレコードを、トランザクションデータの送信元以外の他のクライアントサーバ3(たとえば、B企業,C企業、D企業のクライアントサーバ3)に送信するための制御信号を通信装置64に出力する。これにより、通信装置64を介して、プルーフレコードが他のクライアントサーバ3に送信される。
 S46において、クライアントサーバ3の制御装置31は、プラットフォームサーバ6から正常報告を受信したか否かを判断する。正常報告を受信したと判断すると(S46においてYES)、クライアントサーバ3の制御装置31は、処理をS47に進める。一方、正常報告を受信していない、すなわち異常報告を受信したと判断すると(S46においてNO)、クライアントサーバ3の制御装置31は、処理をS49に進める。
 S47において、クライアントサーバ3の制御装置31は、正常報告に含まれるプルーフレコードをコミットレコードとしてコミットテーブル374に追加する。具体的には、クライアントサーバ3の制御装置31は、プルーフレコードのKeyの情報に基づいて、コミットレコードを追加する対象がコミットデータ375であるかコミットデータ376であるかを判断する。そして、クライアントサーバ3の制御装置31は、対象のコミットデータにコミットレコードを追加する。
 S48において、クライアントサーバ3の制御装置31は、追加したコミットレコードと同じKeyの情報を有するサスペンションレコードを、サスペンションテーブル373から削除する。
 S49において、クライアントサーバ3の制御装置31は、更新要求に対する処理の結果を、たとえば、表示装置36に表示させたり、ユーザ端末装置7に送信したりする。
 なお、S56において送信されたプルーフレコードを受信した他のクライアントサーバ3(B企業,C企業、D企業のクライアントサーバ3)も、同様にプルーフレコードをコミットテーブル374に追加することで、コミットテーブル374が更新される。
 図18は、実施の形態2において、タイムスタンプトークンを取得する処理の手順を示すフローチャートである。図18に示すフローチャートの処理は、入力装置35あるいはユーザ端末装置7から第3要求を受けた際に、制御装置31によって実行される。
 S61において、制御装置31は、第3要求に含まれている対象部品のIDに基づいて、タイムスタンプトークンを取得する対象となるコミットデータ(コミットデータ375またはコミットデータ376)を特定する。
 S62において、制御装置31は、S61で特定されたコミットデータの最新のコミットレコードのハッシュ値を生成する。
 S63において、制御装置31は、S62で生成されたハッシュ値を時刻認証局8に送信するための制御信号を、通信装置34に出力する。これにより、通信装置34を介して、時刻認証局8にハッシュ値が送信される。
 S64において、制御装置31は、通信装置34を介して、時刻認証局8からタイムスタンプトークンを受信する。これにより、対象部品の部品データの存在時刻の証明が取得される。
 S65において、制御装置31は、S64で取得されたタイムスタンプトークンを記憶装置37に記憶させる。なお、制御装置31は、タイムスタンプトークンをデータベース4に記憶させてもよい。
 S66において、制御装置21は、S34で取得されたタイムスタンプトークンを外部サーバ9に送信するための制御信号を、通信装置34に出力する。これにより、通信装置34を介して、外部サーバ9にタイムスタンプトークンが送信される。さらに、制御装置31は、タイムスタンプトークンをコミットテーブル374に追加するために、台帳セット60にタイムスタンプトークンを含めるためのトランザクションデータを生成し、当該トランザクションデータをプラットフォームサーバ6に送信するための制御信号を、通信装置34に出力してもよい。
 以上のように、実施の形態2に係るデータ管理システム1Aにおいては、プラットフォームサーバ6がトランザクションデータにファイナリティを与える。プラットフォームサーバ6は、2つの台帳67,68を含む台帳セット60を保持する。台帳67には、第1部品の部品データの更新状態が時系列に記憶され、台帳68には、第2部品の部品データの更新状態が時系列に記憶される。そして、台帳セット60が更新されると、台帳セット60に追加されたレコードのサマリであるプルーフレコードがプラットフォームサーバ6から各クライアントサーバ3に送られ、クライアントサーバ3の各々は、プルーフレコードをコミットレコードとして、コミットテーブル374に追加する。コミットテーブル374が実施の形態1に係る分散型台帳セット50に相当する。実施の形態2に係るデータ管理システム1Aの構成においても、一方の台帳(たとえば台帳67)の終端ハッシュ値を、他方の台帳(たとえば台帳68)のレコードに組み込んで関連付けておけば、そのサマリであるコミットデータ同士も関連付けられる。これによって、実施の形態1と同様に、終端ハッシュ値が組み込まれたコミットレコードを基準として、第1部品の部品データと、第2部品の部品データとの存在の順序性を証明することができる。
 また、各クライアントサーバ3がコミットテーブル374を持ち合うことで、コミットテーブル374の耐改ざん性が高められる。
 また、クライアントサーバ3は、終端ハッシュ値が組み込まれたコミットデータのレコードに対してタイムスタンプトークンを取得する。終端ハッシュ値が組み込まれたレコードに対してタイムスタンプトークンを取得すれば、第1部品の部品データおよび第2部品の部品データの存在時刻の証明(すなわち、タイムスタンプトークンが示す時刻よりも前に部品データが存在していたことの証明)を取得することができる。
 また、クライアントサーバ3は、タイムスタンプトークンを外部サーバ9に送信する。タイムスタンプトークンを外部サーバ9でも管理することにより、タイムスタンプトークンの耐改ざん性を高めることができる。
 [変形例2]
 実施の形態2では、コミットテーブル374は、台帳セット60に含まれる情報のうちの一部を有する例について説明した。具体的には、コミットテーブル374のコミットデータ375,376の各々は、台帳セット60の台帳67,68の各々が有する、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報のうちの、Key、Age、HV、および、Nonceの情報を含んで構成された。しかしながら、コミットデータ375,376の各々は、台帳67,68と同じ情報、すなわち、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含んで構成されてもよい。この場合には、プルーフレコードもKey、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含むように生成される。上記のような構成によっても、実施の形態2と同様の効果を奏することができる。
 今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本開示により示される技術的範囲は、上記した実施の形態の説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
 1,1A データ管理システム、2,3 クライアントサーバ、4 データベース、5,6 プラットフォームサーバ、7 ユーザ端末装置、8 時刻認証局、9 外部サーバ、21 制御装置、22 ROM、23 RAM、24 通信装置、25 入力装置、26 表示装置、27 記憶装置、29 バス、31 制御装置、32 ROM、33 RAM、34 通信装置、35 入力装置、36 表示装置、37 記憶装置、39 バス、50 分散型台帳セット、51,52 分散型台帳、60 台帳セット、61 制御装置、62 ROM、63 RAM、64 通信装置、65 記憶装置、67,68 台帳、69 バス、271 秘密鍵、272 複数の公開鍵、371 秘密鍵、372 プルーフデータ、373 サスペンションテーブル、374 コミットテーブル、375,376 コミットデータ、651 複数の公開鍵、2101 情報取得部、2102 ハッシュ生成部、2103 ナンス生成部、2104 電子署名部、2105 トランザクションデータ生成部、2106 トランザクションデータ送信部、2111 情報取得部、2112 終端ハッシュ生成部、2113 ナンス生成部、2114 電子署名部、2115 トランザクションデータ生成部、2116 トランザクションデータ送信部、2121 トランザクションデータ取得部、2122 署名検証部、2123 レコード作成部、2124 台帳更新部、2125 出力部、2131 情報取得部、2132 レコードハッシュ作成部、2133 タイムスタンプトークン取得部、2134 出力部、NW ネットワーク。

Claims (7)

  1.  分散型台帳技術を用いてデータを管理するデータ管理装置であって、
     前記データに関する情報を含むレコードを時系列に格納する分散型台帳を記憶する記憶装置と、
     前記分散型台帳に前記レコードを追加する制御装置とを備え、
     前記データは、第1データおよび第2データを含み、
     前記分散型台帳は、前記第1データに関する第1情報を含むレコードを時系列に格納する第1分散型台帳と、前記第2データに関する第2情報を含むレコードを時系列に格納する第2分散型台帳とを含み、
     第1の時点において、前記第1データを更新すると、前記制御装置は、
     前記第1情報を含むレコードを前記第1分散型台帳に格納するとともに、当該レコードの情報を含む第1終端値を生成し、
     前記第1終端値を含むレコードを前記第2分散型台帳に格納する、データ管理装置。
  2.  前記第1終端値は、前記第1の時点において前記第1分散型台帳に格納されたレコードのハッシュ値である、請求項1に記載のデータ管理装置。
  3.  前記第1情報は、前記第1データのハッシュ値であり、
     前記第2情報は、前記第2データのハッシュ値である、請求項1または請求項2に記載のデータ管理装置。
  4.  前記制御装置は、ユーザからの要求に基づいて、前記第1終端値を含むレコードを前記第2分散型台帳に格納する、請求項1から請求項3のいずれか1項に記載のデータ管理装置。
  5.  時刻認証局との通信が可能に構成された通信装置をさらに備え、
     前記制御装置は、前記第1の時点よりも後の時点である第2の時点において、前記通信装置を介して、前記第2分散型台帳の終端のレコードの情報を含む第2終端値を前記時刻認証局に送信して、当該時刻認証局から前記第2終端値に対するタイムスタンプトークンを取得する、請求項1から請求項4のいずれか1項に記載のデータ管理装置。
  6.  前記制御装置は、ユーザからの要求に基づいて、前記タイムスタンプトークンを取得する、請求項5に記載のデータ管理装置。
  7.  分散型台帳技術を用いてデータを管理するデータ管理装置のデータ管理方法であって、
     前記データ管理装置は、
      前記データに関する情報を含むレコードを時系列に格納する分散型台帳を記憶する記憶装置と、
      前記分散型台帳に前記レコードを追加する制御装置とを備え、
      前記データは、第1データおよび第2データを含み、
     前記分散型台帳は、前記第1データに関する第1情報を含むレコードを時系列に格納する第1分散型台帳と、前記第2データに関する第2情報を含むレコードを時系列に格納する第2分散型台帳とを含み、
     前記データ管理方法は、所定の時点において前記第1データを更新すると、前記制御装置が、
     前記第1情報を含むレコードを前記第1分散型台帳に格納するとともに、当該レコードの情報を含む第1終端値を生成するステップと、
     前記第1終端値を含むレコードを前記第2分散型台帳に格納するステップとを含む、データ管理方法。
PCT/JP2022/039769 2022-10-25 2022-10-25 データ管理装置およびデータ管理方法 Ceased WO2024089773A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280101160.8A CN120077379A (zh) 2022-10-25 2022-10-25 数据管理装置和数据管理方法
PCT/JP2022/039769 WO2024089773A1 (ja) 2022-10-25 2022-10-25 データ管理装置およびデータ管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/039769 WO2024089773A1 (ja) 2022-10-25 2022-10-25 データ管理装置およびデータ管理方法

Publications (1)

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

Family

ID=90830198

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/039769 Ceased WO2024089773A1 (ja) 2022-10-25 2022-10-25 データ管理装置およびデータ管理方法

Country Status (2)

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

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) Ssiを用いたブロックチェーンネットワークアイデンティティ管理
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 (ja) データ管理装置およびデータ管理方法
JP7564071B2 (ja) データ管理装置およびデータ管理方法
WO2024089775A1 (ja) データ管理装置およびデータ管理方法
EP4362385A1 (en) Data management apparatus and data management method
JP7276539B2 (ja) データ管理装置およびデータ管理方法
WO2024089774A1 (ja) データ管理装置およびデータ管理方法
EP4362384A1 (en) Data management apparatus and data management method
CN111292184A (zh) 文件反馈的告警提示方法、装置及存储介质
EP4362383A1 (en) Data management apparatus and data management method
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