Data management device and data management method

Abstract

To easily prove the existence time of data stored in a plurality of distributed ledgers in a system having the distributed ledgers.SOLUTION: When a second operation to simultaneously perform update of component data D12 to component data D13 and update of component data D21 to component data D22 is performed, a control unit of a client server generates a record RA3 including a hash value of the component data D13 in a first evidence chain (distributed ledger 51), and generates a record RB2 including a hash value of the component data D22 in a second evidence chain (distributed ledger 52). The control unit of the client server generates a terminal hash value including a record hash value of the record RA3 and a record hash value of the record RB2, and acquires a time stamp token for the terminal hash value.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to a data management device and a data management method that manage data using distributed ledger technology. [Background technology]

[0002] Japanese Patent No. 6694204 (Patent Document 1) discloses a data management system that configures a distributed ledger (asset) having a Directed Acyclic Graph (DAG) structure for each key (ID) for identifying the managed object, and manages information for each ID. [Prior art documents] [Patent documents]

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

[0004] In the data management system disclosed in Patent Document 1, for example, when data of an object managed by a certain ID is updated, the data is added to the assets prepared for that certain ID. Also, when data of an object managed by another ID is updated, data is added to the assets prepared for that other ID.

[0005] Here, in order to prove the existence time of data added to each asset, it is conceivable to obtain a timestamp token for the latest asset record each time each asset is updated. However, if a timestamp token is obtained for each asset, the cost of obtaining the timestamp token may increase and the system load may increase.

[0006] The present disclosure has been made to solve the above-mentioned problems, and an objective of the present disclosure is to make it possible to easily prove the existence time of data stored in multiple distributed ledgers in a system having multiple distributed ledgers. [Means for solving the problem]

[0007] (1) A data management device according to an aspect of the present disclosure 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, a control device that adds records to the distributed ledger, and a communication device configured to be able to communicate with a time stamp authority. 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 generates a terminal value that includes information about a record at the end of the first distributed ledger and information about a record at the end of the second distributed ledger, and obtains a time stamp token for the terminal value from the time stamp authority via the communication device.

[0008] According to the above configuration, a timestamp token is obtained for an end value including information of an end record of the first distributed ledger and information of an end record of the second distributed ledger. By obtaining a timestamp token for the end value, it is possible to collectively obtain proofs of existence of the first information stored in the first distributed ledger and the second information stored in the second distributed ledger at the time indicated by the timestamp token.

[0009] (2) In one embodiment, the control device stores a record including the timestamp token in at least one of the first distributed ledger and the second distributed ledger.

[0010] According to the above configuration, since the time stamp token is stored in at least one of the first distributed ledger and the second distributed ledger, it is possible to improve the tamper resistance of the time stamp token.

[0011] (3) In an embodiment, the communication device is further configured to be able to communicate with an external server different from the data management device. The control device stores the time stamp token in the storage device and transmits the time stamp token to the external server via the communication device.

[0012] According to the above configuration, the time stamp token is managed by the data management device and also by the external server. In order to tamper with the time stamp token, both the time stamp token managed by the data management device and the time stamp token managed by the external server must be tampered with. By managing the time stamp token also by the external server, it is possible to improve the tamper resistance of the time stamp token compared to a case where the time stamp token is managed only by the data management device.

[0013] (4) In one embodiment, the control device generates a terminal value when it stores a record including the first information in the first distributed ledger and stores a record including the second information in the second distributed ledger in response to updates to the first data and the second data.

[0014] According to the above configuration, a user of the data management device can obtain a time stamp token for the terminal value by a user operation of updating the first data and the second data.

[0015] (5) In one embodiment, the control device generates a termination value when a predetermined time has elapsed since the previous timestamp token was obtained.

[0016] According to the above configuration, a time stamp token for the terminal value can be automatically obtained every time a predetermined time elapses.

[0017] (6) In one embodiment, the information of the end record of the first distributed ledger is a hash value of the end record of the first distributed ledger, and the information of the end record of the second distributed ledger is a hash value of the end record of the second distributed ledger.

[0018] According to the above configuration, the record information included in the termination value is the hash value of the record, so the record itself is not sent to the TSA. Therefore, the record itself can be kept secret when obtaining a time stamp token.

[0019] (7) In one embodiment, the first information is a hash value of the first data, and the second information is a hash value of the second data.

[0020] According to the above configuration, the records stored in the first distributed ledger and the second distributed ledger include a hash value of the first data and a hash value of the second data, respectively. Since the first data and the second data are not stored in the first distributed ledger and the second distributed ledger, the first data and the second data themselves can be kept secret from other data management devices that form the distributed ledger network.

[0021] (8) A data management method according to another aspect of the present disclosure 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, a control device that adds records to the distributed ledger, and a communication device configured to be able to communicate with a time stamp authority. 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 the steps of generating a terminal value including information about a record at the end of the first distributed ledger and information about a record at the end of the second distributed ledger, and obtaining a time stamp token for the terminal value from the time stamp authority via the communication device. Effect of the Invention

[0022] According to the present disclosure, in a system having multiple distributed ledgers, it is possible to easily prove the existence time of data stored in multiple distributed ledgers. [Brief description of the drawings]

[0023] [Figure 1] FIG. 1 is a diagram showing a schematic configuration of a data management system according to a first embodiment. [Diagram 2] FIG. 1 shows an example of the configuration of a distributed ledger set (part 1). [Diagram 3] FIG. 13 is a diagram for explaining the existence proof process. [Figure 4] FIG. 2 shows an example of the configuration of a distributed ledger set (part 2). [Diagram 5] FIG. 4 is a functional block diagram of a control device for executing a process responsive to a first operation. [Figure 6] FIG. 11 is a functional block diagram of a control device for executing a process responsive to a second operation. [Figure 7] FIG. 4 is a functional block diagram of a control device for executing received transaction data. [Figure 8] 13 is a flowchart showing a procedure for generating transaction data when a first request is received. [Figure 9] 13 is a flowchart showing a procedure for generating transaction data when a second request is received. [Figure 10] 11 is a flowchart showing a procedure of a process executed when transaction data is received. [Figure 11] FIG. 11 is a diagram showing a schematic configuration of a data management system according to a second embodiment. [Figure 12] FIG. 13 is a diagram showing an example of the configuration of a distributed ledger set relating to embodiment 2. [Figure 13] FIG. 11 is a diagram for explaining the existence proof processing in the second embodiment. [Figure 14] FIG. 11 is a functional block diagram of a control device for executing an existence proof process in the second embodiment. [Figure 15] 13 is a flowchart showing a procedure for a process of acquiring a time stamp token. [Figure 16] FIG. 11 is a diagram showing a schematic configuration of a data management system according to a third embodiment. [Figure 17] A diagram showing an example of the configuration of a ledger set. [Figure 18] 4A and 4B are diagrams illustrating an example of a configuration of a suspension table. [Figure 19] FIG. 13 is a diagram illustrating an example of the configuration of a commit table. [Figure 20] 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. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference characters, and the description thereof will not be repeated.

[0025] [Embodiment 1] <Overall configuration of the data management system> 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 "network") NW among a plurality of companies and managing data using distributed ledger technology. The data management system 1 according to the first embodiment manages data of parts that constitute a vehicle (hereinafter also simply referred to as "parts data"). The parts data may be, for example, a specification sheet of the parts. Note that the data managed by the data management system 1 is not limited to data of parts that constitute a vehicle, and may be various types of data.

[0026] 1, a 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 (for example, company A, company B, company C, and company D).

[0027] The platform server 5 manages the network NW. The platform server 5 accepts applications for participation in the network NW from each client server 2. The platform server 5 permits the client server 2 to participate in the network NW based on an operation by an administrator of the platform server 5 to permit participation or based on the result of judging a predetermined condition. In the first embodiment, four client servers 2 belonging to each of companies A, B, C, and D are permitted to participate in the network NW.

[0028] The four client servers 2 form a network NW, and store hash values ​​of part data in each distributed ledger. Distributed ledger platform software is installed in each of the client servers 2, and the installed distributed ledger platform software functions so that each client server 2 functions as a node. In the following, the client server 2 of company A will be described as a representative example, but the client servers of companies B, C, and 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.

[0029] 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 having a communication function, loaned to an employee of the A company.

[0030] A database 4 is also connected to the client server 2. The database 4 stores part data. The database 4 stores and updates the part data in accordance with a control signal from the client server 2. For example, a user of the client server 2 (e.g., an employee of Company A) can request an update of the part data by operating an input device 25 (described later) of the client server 2, or by operating a user terminal device 7. The client server 2 (control device 21) generates a control signal for storing / updating the part data in accordance with 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.

[0031] 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. Then, the client server 2 transmits the generated transaction data to other client servers 2 forming the network NW, i.e., the client servers 2 of company B, company C, and company D. The distributed ledger stores the hash values ​​of the part data in chronological order and forms 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.

[0032] 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 (client server 2 in the first embodiment). More specifically, the time-stamp authority transmits to the applicant a time-stamp token that combines data received from the applicant (a terminal hash value, described later, in the first embodiment) with time information based on a time source that is traceable to international standard time.

[0033] 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.

[0034] The control device 21 is configured, for example, by an integrated circuit including a CPU (Central Processing Unit). The control device 21 loads various programs stored in the ROM 22 into the RAM 23 and executes them. The various programs include an operating system and the like. The RAM 23 functions as a working memory and temporarily stores various data required for executing the various programs. The control device 21 has functions to update the part data recorded in the database 4, generate transaction data for updating the distributed ledger, and acquire timestamp tokens, which will be described in detail later.

[0035] The communication device 24 is configured to be capable of communicating with external devices. The external devices include, for example, other client servers 2, user terminal devices 7, and time stamping authorities 8. The communication between the communication device 24 and the 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.

[0036] The input device 25 includes an input device, such as a mouse, a keyboard, a touch panel, and / or other device capable of receiving a user's operation.

[0037] The display device 26 includes a display. The display device 26 displays various images on the display according to a control signal from the control device 21. The display is, for example, a liquid crystal display, an organic EL (Electro Luminescence) display, or other display device.

[0038] 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.

[0039] The private key 271 is the private key of company A. For example, when the client server 2 first joins the network NW, the control device 21 generates a private key and a public key. Then, the control device 21 transmits the generated public key to a certification authority (not shown) for authentication. The certification authority is a certification organization that issues electronic certificates. The certification authority issues an electronic certificate including information on the public key. The control device 21 stores the private key 271 corresponding to the authenticated public key in the storage device 27. The control device 21 also transmits the authenticated public keys (electronic certificates) 272 to the client servers 2 of companies B, C and D.

[0040] The multiple public keys 272 include a public key of company B, a public key of company C, and a public key of company D. The control device 21 stores public keys received from other client servers 2 in the storage device 27. The storage device 27 may also store its own (company A's) public key.

[0041] 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. In the first embodiment, an example will be described in which two parts (first part, second part) that constitute a vehicle are managed by the data management system 1. That is, 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. If the number of parts that constitute a vehicle that are managed by the data management system 1 is N (a natural number equal to or greater than 2), the distributed ledger set 50 includes N distributed ledgers. Hereinafter, 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.

[0042] Distributed ledger 51 stores records including hash values ​​of part data of the first part in chronological order. The records include information on “Key”, “Age”, “Obj-HV”, “Nonce”, “Sig”, “Prev-HV”, and “HV”.

[0043] The key is information indicating the ID of the target part (first part). The first part is assigned an ID of k1.

[0044] Age is information indicating the generation of a record. In the first record of the first part stored in the distributed ledger 51, Age is 0. When the first part is updated and a record is added, Age is incremented.

[0045] Obj-HV is a 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 (e.g., "OH2" in FIG. 2) 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. As will be described in detail later, a time stamp token (e.g., "TM" in FIG. 4 described later) may also be stored in Obj-HV.

[0046] Nonce is a nonce value indicating the number of transaction data. That is, for example, when part data of a first part stored in the database 4 is updated, the nonce value is generated by the client server 2 (control device 21) as a processing number for storing a 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.

[0047] 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. Alternatively, the electronic signature may be created, for example, by encrypting Nonce (a nonce value) with the private key 271. Furthermore, the electronic signature may be created, for example, by encrypting Obj-HV and Nonce with the private key 271.

[0048] Prev-HV is the hash value of the record (parent record) of the generation immediately before the latest (end) record. In other words, Prev-HV is the HV of the parent record.

[0049] The HV is the hash value of the latest (end) record. Specifically, the HV is the hash value of the record information excluding the HV (Key, Age, Obj-HV, Nonce, Sig, and Prev-HV) (hereinafter also referred to as the "record hash value").

[0050] For example, as shown in FIG. 2, when focusing on the latest (terminal) record (record with Age "2") of the distributed ledger 51, the Prev-HV of the terminal record is "H2", which is the HV of the parent record (Age "1"). Next, when the part data of the first part is 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". In this way, the terminal record has a structure including the record hash value of the parent record. In other words, a record chain 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.

[0051] Distributed ledger 52 stores records including hash values ​​of part data of the second part in chronological order. The records include information on "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 repeatedly.

[0052] 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. Then, the client server 2 (control device 21) generates transaction data for adding a record including a hash value of the updated part data to the distributed ledger set 50 (distributed ledger 51 or distributed ledger 52). This transaction data includes information on "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

[0053] The transaction data may further include time information at which the transaction data is broadcast to the network NW (transmitted to the network NW), and sender information of the transaction data. The time information may be, for example, information indicating the time at which the part data of the target part was recorded in the database 4. The sender information is, for example, information indicating Company A. In addition, the sender information of the transaction data may be, in more detail, information indicating the department (a division of Company A) that performed the operation of transmitting the transaction data to the network NW, or information indicating an individual (an employee of Company A) that performed the operation of transmitting the transaction data to the network NW.

[0054] <Proof of time> Here, there are cases where it is desired to prove the order indicating which data existed first between the part data of the first part and the part data of the second part, and the time indicating the time of existence of these data. As a method for proving the order and time, for example, every time a record is added to each of the distributed ledgers 51 and 52, 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 and time of the two data. However, in this method, a timestamp token must be obtained every time a record is added to the distributed ledgers 51 and 52, which increases the man-hours and costs. In addition, the processing load on the data management system 1 also increases.

[0055] Therefore, in the data management system 1 according to the first embodiment, a terminal hash value including a record hash value of the distributed ledger 51 and a record hash value of the distributed ledger 52 is generated, and a time stamp token for the terminal hash value can be obtained. By obtaining a time stamp token for the terminal hash value, the time of the part data of the first part and the part data of the second part at the time when the time stamp token is obtained can be simultaneously proven. Furthermore, in the data management system 1 according to the first embodiment, the above-mentioned time stamp token can be incorporated into at least one record of the distributed ledgers 51 and 52. By incorporating the time stamp token obtained for the terminal hash value into at least one record of the distributed ledgers 51 and 52, the tamper resistance of the time stamp token can be improved. A specific description will be given below with reference to FIG. 3. In the following, the process of generating a terminal hash value and obtaining a time stamp token for the terminal hash value is also referred to as an "existence proof process".

[0056] Fig. 3 is a diagram for explaining the existence proof process. The upper part of Fig. 3 shows a schematic distributed ledger 51 which is the evidence chain of the first part, and the lower part of Fig. 3 shows a schematic distributed ledger 52 which is the evidence chain of the second part. Hereinafter, the evidence chain of the first part will also be referred to as the "first evidence chain", and the evidence chain of the second part will also be referred to as the "second evidence chain".

[0057] In the following description, an operation of updating only one of the part data of the first part and the part data of the second part is also referred to as a “first operation.” An operation of simultaneously updating the part data of the first part and the part data of the second part is also referred to as a “second operation.”

[0058] In the first evidence chain (distributed ledger 51), records including hash values ​​of part data of the first part are stored in chronological order. When the first operation is performed and part data D10 of the first part is initially registered in the database 4, a record RA0 with an age of "0" including the hash value of the part data D10 is stored in the distributed ledger 51. Next, when the first operation is performed and the part data of the first part is updated and the updated part data D11 is registered in the database 4, a record RA1 with an age of "1" including the hash value of the updated part data D11 and the record hash value of the parent record RA0 with an age of "0" is stored in the distributed ledger 51. Furthermore, when the first operation is performed and the part data of the first part is updated and the updated part data D12 is registered in the database 4, a record RA2 with an age of "2" including the hash value of the updated part data D12 and the record hash value of the parent record RA1 with an age of "1" is stored in the distributed ledger 51.

[0059] The second evidence chain (distributed ledger 52) stores records in chronological order, each including a hash value of part data of the second part. When the first operation is performed and part data D20 of the second part is initially registered in the database 4, a record RB0 with an age of "0" that includes the hash value of the part data D20 is stored in the distributed ledger 52. Next, when the first operation is performed and the part data of the second part is updated and the updated part data D21 is registered in the database 4, a record RB1 with an age of "1" that includes the hash value of the updated part data D21 and the record hash value of the parent record RB0 with an age of "0" is stored in the distributed ledger 52.

[0060] Here, as described above, it is assumed that in distributed ledger 51, record RA2 with Age "2" is the latest (terminal) record, and in distributed ledger 52, record RB1 with Age "1" is the latest (terminal) record. In this state, it is assumed that a second operation for simultaneously updating the part data of the first part and the part data of the second part has been performed on input device 25 or user terminal device 7. In the first embodiment, when the second operation is performed, the existence proof process is executed. In other words, the second operation is a condition for executing the existence proof process.

[0061] The second operation may be, for example, an operation of inputting IDs (Keys) of two target parts on a display screen of the display device 26 or the user terminal device 7 and selecting a displayed update button. Furthermore, the display screen for performing the second operation may be provided with, for example, a "target input field" for inputting an ID (Key) of a target part into which the acquired time stamp token is to be incorporated. For example, if k1 is input into the target input field, the time stamp token acquired by the existence proof process is incorporated into a record of the first evidence chain (distributed ledger 51). For example, if k2 is input into the target input field, the time stamp token acquired by the existence proof process is incorporated into a record of the second evidence chain (distributed ledger 52). For example, if k1 and k2 are input into the target input field, the time stamp token acquired by the existence proof process is incorporated into a record of the first evidence chain (distributed ledger 51) and a record of the second evidence chain (distributed ledger 52). In the example shown in FIG. 3, it is assumed that k2 is input into the target input field.

[0062] 2 and 3, when a second operation for simultaneously updating the part data of the first part and the part data of the second part is performed, the control device 21 first updates the part data D12 of the first part stored in the database 4 to part data D13, and updates the part data D21 of the second part to part data D22. When the part data D10 of the first part is stored in the database 4 first, the control device 21 only needs to newly store the part data of the first part in the database 4. Similarly, when the part data D20 of the second part is stored in the database 4 first, the control device 21 only needs to newly store the part data of the second part in the database 4.

[0063] Next, the control device 21 creates a record RA3 with an age of "3" including the hash value of the part data D13 and the record hash value of the parent record RA2, and stores the record in the distributed ledger 51. The control device 21 also generates transaction data (hereinafter also referred to as "transaction data A") for adding the record RA3 to the distributed ledger 51. The control device 21 also creates a record RB2 with an age of "2" including the hash value of the part data D22 and the record hash value of the parent record RB1, and stores the record in the distributed ledger 52. The control device 21 also generates transaction data (hereinafter also referred to as "transaction data B") for adding the record RB2 to the distributed ledger 52. The control device 21 transmits the generated transaction data A and B to the client servers 2 of the B, C, and D companies via the communication device 24. The transaction process for executing the transaction data A is performed in each of the client servers 2 of the B, C, and D companies, and the record RA3 is stored in the distributed ledger 51 of each of the client servers 2. As a result of transaction processing for executing transaction data B being performed by each of the client servers 2 of company B, company C, and company D, record RB2 is stored in the distributed ledger 52 of each of the client servers 2. Note that transaction data A and B may be generated as one transaction data.

[0064] When the control device 21 stores the records RA3 and RB2 in the distributed ledgers 51 and 52, respectively, it generates a record hash value of the record RA3 and a record hash value of the record RB2. Then, the control device 21 generates a terminal hash value including the record hash value of the record RA3 and the record hash value of the record RB2. The control device 21 transmits the terminal hash value to the TSA 8 via the communication device 24, and obtains a timestamp token for the terminal hash value from the TSA 8.

[0065] Then, the control device 21 creates record RB3 including the timestamp token and the record hash value of record RB2 (parent record) in the distributed ledger 52, and stores it in the distributed ledger 52. The control device 21 also generates transaction data for adding record RB3 to the distributed ledger 52. The control device 21 transmits the generated transaction data to the client servers 2 of companies B, C, and D via the communication device 24. Transaction processing for executing this transaction data is performed in each of the client servers 2 of companies B, C, and D, whereby record RB3 is stored in the distributed ledger 52 of each client server 2.

[0066] An example of a specific structure of the distributed ledger 52 corresponding to FIG. 3 is shown in FIG. 4. FIG. 4 is a diagram showing an example of the configuration of the distributed ledger set 50. By a second operation in which part data D12 is updated to part data D13 and part data D21 is updated to part data D22 at the same time, a record RA3 with an age of "3" is added to the distributed ledger 51, and a record RB2 with an age of "2" is added to the distributed ledger 52. Then, a record RB3 with an age of "3" in which a timestamp token obtained for the terminal hash value is stored is added to the distributed ledger 52. The record RB3 with an age of "3" in the distributed ledger 52 includes a timestamp token TM as Obj-HV.

[0067] As described above, when an operation (second operation) for simultaneously updating the part data of the first part and the part data of the second part, specifically, an operation for simultaneously updating the part data D12 to the part data D13 and updating the part data D21 to the part data D22, is performed, the control device 21 adds a record RA3 including a hash value of the part data D13 to the distributed ledger 51, and adds a record RB2 including a hash value of the part data D22 to the distributed ledger 52. Then, the control device 21 generates a terminal hash value including the record hash value of the record RA3 and the record hash value of the record RB2. The control device 21 transmits the terminal hash value to the time stamp authority 8 and obtains a time stamp token for the terminal hash value. By obtaining a time stamp token for the terminal hash value including the record hash value of the record RA3 and the record hash value of the record RB2, it can be proved that the part data D10 to D13 of the first part existed and the part data D20 to D22 of the second part existed at the time certified by the time stamp token. 3, part data D13 has been updated to part data D14, and part data D22 has been updated to part data D23 after the time stamp token was acquired. As described above, by acquiring a time stamp token for the terminal hash value, it is possible to prove that part data D14 and part data D23 were registered after the time stamp token was acquired. Compared to acquiring a time stamp token for each of records RA3 and RB2 in distributed ledgers 51 and 52, it is possible to reduce the number of steps, costs, system load, and the like.

[0068] Furthermore, the tamper resistance of the timestamp token can be improved by incorporating the timestamp token into the record of the distributed ledger 52. Note that the timestamp token may be incorporated into the record of the distributed ledger 51, or may be incorporated into the record of the distributed ledger 51 and the record of the distributed ledger 52.

[0069] When the part data of the first part is further updated from D13 to D14, a record RA4 with an age of "4" that includes the hash value of the part data D14 and the record hash value of the record RA3 is added to the distributed ledger 51. Similarly, when the part data of the second part is further updated from D22 to D23, a record RB4 with an age of "4" that includes the hash value of the part data D23 and the record hash value of the record RB3 is added to the distributed ledger 52.

[0070] <Function block> Fig. 5 is a functional block diagram of control device 21 for executing a process in response to a first operation. With reference to Fig. 5, 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. Note that 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).

[0071] When a first operation for updating part data of a target part (first part or second 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.

[0072] 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. Upon acquiring the first request, the information acquisition unit 2101 outputs the first request to the hash generation unit 2102 and the nonce generation unit 2103.

[0073] When the hash generation unit 2102 receives the first request, it reads out part data of the target part from, for example, the database 4, and generates a hash value of the read out 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.

[0074] Upon receiving the first request, the nonce generation unit 2103 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. 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.

[0075] The electronic signature unit 2104 reads out 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.

[0076] The transaction data generation unit 2105 generates transaction data to be sent to the network NW. For example, the transaction data generation unit 2105 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. For example, 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. In addition, the transaction data generation unit 2105 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.

[0077] The transaction data transmission unit 2106 outputs a control signal for transmitting the transaction data to the network NW to the communication device 24. As a result, the transaction data is transmitted to the network NW via the communication device 24.

[0078] Fig. 6 is a functional block diagram of the control device 21 for executing a process in response to a second operation. Referring to Fig. 6, the control device 21 includes an information acquisition unit 2111, a record addition unit 2112, a terminal hash generation unit 2113, a nonce generation unit 2114, a time stamp token acquisition unit 2115, a digital signature unit 2116, a transaction data generation unit 2117, and a transaction data transmission unit 2118. The control device 21 functions as the information acquisition unit 2111, the record addition unit 2112, the terminal hash generation unit 2113, the nonce generation unit 2114, the time stamp token acquisition unit 2115, the digital signature unit 2116, the transaction data generation unit 2117, and the transaction data transmission unit 2118, for example, by executing a program stored in the ROM 22. In addition, the information acquisition unit 2111, record addition unit 2112, termination hash generation unit 2113, nonce generation unit 2114, timestamp token acquisition unit 2115, electronic signature unit 2116, transaction data generation unit 2117, and transaction data transmission unit 2118 may be realized, for example, by dedicated hardware (electronic circuitry).

[0079] When a second operation for simultaneously updating the part data of the first part and the part data of the second 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 second request indicating that the second operation has been performed.

[0080] 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 save (register / update) the part data of the first part and the second part in the database 4, the second request is input to the information acquisition unit 2111. The second request includes an ID (k1 and k2) for identifying the target part, and an ID (e.g., k2) of the target part into which the timestamp token is to be embedded, which is input in the target input field. Upon acquiring the second request, the information acquisition unit 2111 outputs the second request to the record addition unit 2112.

[0081] The record adding unit 2112 has the same function as the function described in Fig. 5. Specifically, the record adding unit 2112 executes the same process as the process shown in Fig. 5 for the target part identified by the ID, generates transaction data A for adding a record including a hash value of part data of the first part (e.g., record RA3 in Fig. 3) to the distributed ledger 51, and transaction data B for adding a record including a hash value of part data of the second part (e.g., record RB2 in Fig. 3) to the distributed ledger 52, and transmits these to the network NW. Upon completing the transmission of the transaction data A and B to the network NW, the record adding unit 2112 outputs a second request to the termination hash generating unit 2113 and the nonce generating unit 2114.

[0082] The terminal hash generator 2113 generates a terminal hash value that includes the record hash value of the latest (terminal) record (e.g., record RA3 in FIG. 3) in the distributed ledger 51 and the record hash value of the latest (terminal) record (e.g., record RB2 in FIG. 3) in the distributed ledger 52. The terminal hash generator 2113 outputs the generated terminal hash value and the ID (e.g., k2) of the target component into which the timestamp token is to be embedded to the timestamp token acquirer 2115.

[0083] Upon receiving the second request, the nonce generation unit 2114 generates a nonce value. The nonce generation unit 2114 outputs the generated nonce value and an ID (e.g., k2) of the target part into which the timestamp token is to be embedded to the transaction data generation unit 2117. When a nonce value is used to create a digital signature, the nonce generation unit 2114 may output the nonce value and an ID (e.g., k2) of the target part into which the timestamp token is to be embedded to the digital signature unit 2116.

[0084] The timestamp token acquisition unit 2115 acquires a timestamp token for the termination hash value received from the termination hash generation unit 2113. Specifically, the timestamp token acquisition unit 2115 outputs a control signal for transmitting the termination hash value to the TSTA 8 to the communication device 24. As a result, the termination hash value is transmitted to the TSTA 8 via the communication device 24. The TSTA 8 that has received the termination hash value returns the timestamp token to the client server 2 that transmitted the termination hash value. The timestamp token acquisition unit 2115 acquires the timestamp token from the TSTA 8 via the communication device 24. The timestamp token acquisition unit 2115 outputs the timestamp token and an ID (e.g., k2) of the target part into which the timestamp token is to be embedded to the digital signature unit 2116 and the transaction data generation unit 2117.

[0085] The electronic signature unit 2116 reads out the private key 271 from the storage device 27. The electronic signature unit 2116 creates an electronic signature by encrypting the time stamp token received from the time stamp token acquisition unit 2115 with the private key 271. The electronic signature unit 2116 outputs the created electronic signature and the ID (e.g., k2) of the target component into which the time stamp token is to be embedded to the transaction data generation unit 2117. The electronic signature unit 2116 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2114 with the private key 271. The electronic signature unit 2116 may also create an electronic signature by encrypting the time stamp token and the nonce value with the private key 271.

[0086] The transaction data generation unit 2117 generates transaction data (hereinafter also referred to as "transaction data C") to be transmitted to the network NW. For example, the transaction data generation unit 2117 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2117 sets the ID (e.g., k2) of the target component into which the time stamp token is to be embedded as the Key. In addition, the transaction data generation unit 2117 sets the time stamp token as Obj-HV. Other functions of the transaction data generation unit 2117 are basically similar to those of the transaction data generation unit 2105 described in FIG. 5.

[0087] The transaction data transmission unit 2118 outputs a control signal for transmitting the transaction data C to the network NW to the communication device 24. As a result, the transaction data C is transmitted to the network NW via the communication device 24.

[0088] Fig. 7 is a functional block diagram of the control device 21 for executing received transaction data. Referring to Fig. 7, 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. Note that 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 by, for example, dedicated hardware (electronic circuitry).

[0089] The transaction data acquisition unit 2121 acquires transaction data transmitted from other client servers 2. The transaction data acquisition unit 2121 outputs the acquired transaction data to the signature verification unit 2122.

[0090] 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 is the sender of the transaction data based on the sender information included in the transaction data. Then, the signature verification unit 2122 reads out 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 decrypts the electronic signature included in the transaction data using the read public key. As described above, the electronic signature is obtained by encrypting the hash value or timestamp token of the part data using the private key of the sender client server 2. The signature verification unit 2122 compares the decrypted value with Obj-HV (hash value or timestamp token) included in the transaction data. By confirming that the two match, the signature verification unit 2122 recognizes the validity of the electronic signature.

[0091] If the validity of the electronic signature is recognized, 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.

[0092] The ledger updating unit 2124 adds the record created by the record creating unit 2123 to the distributed ledger set 50, and updates the distributed ledger set 50. Specifically, the ledger updating 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 that updates the part data of the first part has "k1" indicating the ID of the first part as a key. The record created based on this transaction data also has "k1" as a key. Therefore, the ledger updating unit 2124 adds the record to the distributed ledger 51, which is the evidence chain of the part data of the first part.

[0093] Moreover, the above-mentioned transaction data A generated in response to the second operation has "k1" indicating the ID of the first part as a key. The record created based on the transaction data A also has "k1" as a 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. Moreover, the above-mentioned transaction data B generated in response to the second operation has "k2" indicating the ID of the second part as a key. The record created based on the transaction data B also has "k2" as a key. Therefore, the ledger update unit 2124 adds the record to the distributed ledger 52, which is the evidence chain of the part data of the second part. Moreover, the above-mentioned transaction data C generated in response to the second operation has "k2" indicating the ID of the second part as a key in the above example. The record created based on the transaction data C also has "k2" as a key. Therefore, the ledger update unit 2124 adds the record to the distributed ledger 52, which is the evidence chain of the part data of the second part. This causes a record containing the timestamp token to be stored in the distributed ledger 52.

[0094] When the ledger update unit 2124 completes the update of the distributed ledger set 50, it outputs a message to that effect to the output unit 2125.

[0095] The output unit 2125 outputs a control signal to the communication device 24 to notify the client server 2 that is the sender of the transaction data that the process of executing the transaction data (transaction process) has been completed. As a result, a report of the completion of the transaction process is transmitted via the communication device 24 to the client server 2 that is the sender of the transaction data.

[0096] <Flowchart> Fig. 8 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. 8 is executed by the control device 21 when a first request is received from the input device 25 or the user terminal device 7. Note that each step (hereinafter, steps are abbreviated as "S") of the flowcharts shown in Fig. 8 and Figs. 9 and 10 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.

[0097] In S1, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.

[0098] In S2, the control device 21 reads out part data of the target part from the database 4 based on the ID for identifying the target part included in the first request, and generates a hash value of the part data.

[0099] In S3, 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.

[0100] 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 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 incremented Age of the parent record. The control device 21 also sets the record hash (HV) 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 information on HV, to HV. Furthermore, the control device 21 may include, in the transaction data, time information for broadcasting the transaction data onto the network NW and sender information of the transaction data.

[0101] In S5, the control device 21 outputs a control signal for transmitting the transaction data generated in S4 to the network NW to the communication device 24. As a result, the transaction data is transmitted to the network NW via the communication device 24.

[0102] 9 is a flowchart showing a process for generating transaction data when a second request is received. The process of the flowchart shown in FIG. 9 is executed by the control device 21 when a second request is received from the input device 25 or the user terminal device 7.

[0103] In S11, the control device 21 executes a process of transmitting transaction data for adding records in response to the update of the part data of the first part and the part data of the second part to the distributed ledgers 51 and 52, respectively. Specifically, the control device 21 executes a process similar to the process described in FIG. 8 to generate transaction data A for adding a record in response to the update of the part data of the first part to the distributed ledger 51, and outputs a control signal for transmitting the transaction data A to the network NW to the communication device 24. The control device 21 also executes a process similar to the process described in FIG. 8 to generate transaction data B for adding a record in response to the update of the part data of the second part to the distributed ledger 52, and outputs a control signal for transmitting the transaction data B to the network NW to the communication device 24.

[0104] In S12, the control device 21 generates a nonce value. This nonce value is used as a number for transaction data generated in S16, which will be described later.

[0105] In S13, the control device 21 creates a terminal hash value that includes the record hash value of the terminal record of the distributed ledger 51 (i.e., the record added to the distributed ledger 51 by execution of the transaction data A sent in S11) and the record hash value of the terminal record of the distributed ledger 52 (i.e., the record added to the distributed ledger 52 by execution of the transaction data B sent in S11).

[0106] In S14, the control device 21 outputs a control signal to the communication device 24 for transmitting the termination hash value generated in S13 to the TSA 8. As a result, the termination hash value is transmitted to the TSA 8 via the communication device 24. The TSA 8 that has received the termination hash value returns a time stamp token to the client server 2 that transmitted the termination hash value. The control device 21 obtains the time stamp token from the TSA 8 via the communication device 24.

[0107] In S15, the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the timestamp token acquired in S14 to create an electronic signature. The control device 21 may also use the private key 271 to encrypt the nonce value generated in S12 to create an electronic signature. The control device 21 may also use the private key 271 to encrypt the timestamp token acquired in S14 and the nonce value generated in S12 to create an electronic signature.

[0108] In S16, 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 "target input field" (k2 in the above example) as the Key. The control device 21 also sets the timestamp token acquired in S14 as the Obj-HV. Other processes in S16 are basically similar to those in S4 of Fig. 8, and therefore will not be described repeatedly.

[0109] In S17, the control device 21 outputs a control signal for transmitting the transaction data generated in S16 to the network NW to the communication device 24. As a result, the transaction data is transmitted to the network NW via the communication device 24.

[0110] Fig. 10 is a flowchart showing the procedure of the process executed when transaction data is received. The process of the flowchart shown in Fig. 10 is executed by the control device 21 when transaction data is received.

[0111] In S21, the control device 21 identifies the client server 2 that is the sender of the received transaction data, based on sender information included in the transaction data.

[0112] In S22, the control device 21 reads from the storage device 27 the public key of the client server 2 identified in S21.

[0113] In S23, the control device 21 decrypts the electronic signature included in the transaction data using the public key read in S22.

[0114] In S24, 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 Obj-HV (hash value or timestamp token) 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.

[0115] In S25, since the electronic signature is not valid, the control device 21 discards the currently received transaction data and ends the process. Note that the control device 21 may cause the display device 26 to display a message indicating that the transaction data may have been tampered with. The control device 21 may also transmit a message indicating that the transaction data may have been tampered with to the client server 2 that is the source of the transaction data.

[0116] In S26, the control device 21 reads out the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV from the received transaction data, and creates a record including this information.

[0117] In S27, the control device 21 identifies the distributed ledger to which the record is to 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.

[0118] In S28, the control device 21 transmits a notification (completion report) indicating that the transaction processing has been completed to the client server 2 that is the transmission source of the transaction data.

[0119] As described above, in the data management system 1 according to the first embodiment, the client server 2 holds a distributed ledger set 50 including two distributed ledgers 51 and 52. The distributed ledger 51 is an evidence chain for proving the existence of the part data of the first part, and the distributed ledger 52 is an evidence chain for proving the existence of the part data of the second part. When a second operation for simultaneously updating the part data of the first part and the part data of the second part is performed, the client server 2 adds a record including a hash value of the updated part data of the first part to the distributed ledger 51, and adds a record including a hash value of the updated part data of the second part to the distributed ledger 52. Then, the client server 2 generates a terminal hash value including the record hash value of the record added to the distributed ledger 51 and the record hash value of the record added to the distributed ledger 52. Then, the client server 2 acquires a timestamp token for the terminal hash value. By acquiring a time stamp token for the termination hash value, for example, as in the example of FIG. 3, it can be proven that the part data D10 to D13 of the first part existed and the part data D20 to D22 of the second part existed at the time proven by the time stamp token. In addition, it can be proven that the part data D14 and the part data D23 were registered after the time stamp token was acquired. In other words, it can be proven that the part data D14 and the part data D23 existed after the part data D10 to D13 and the part data D20 to D22 were saved. According to the data management system 1 according to the first embodiment, it is possible to reduce the man-hours, costs, system load, and the like, compared to the case where a time stamp token is acquired for the record hash value of each record added to each of the distributed ledgers 51 and 52.

[0120] In addition, the tamper-resistance of the timestamp token can be increased by incorporating the timestamp token into the record of at least one distributed ledger included in the distributed ledger set 50.

[0121] [Variation 1] In the first embodiment, the existence proof process, i.e., the process of generating a termination hash value and acquiring a time stamp token, is executed when the second operation is performed to simultaneously update the part data of the first part and the part data of the second part. That is, in the first embodiment, the existence proof process is executed due to a user operation. However, the existence proof process may be executed automatically. For example, the existence proof process may be executed when a predetermined time has elapsed since the previous time stamp token was acquired. That is, the existence proof process may be executed every predetermined time. Then, the acquired time stamp token may be stored in at least one of the distributed ledger records of the distributed ledger set 50. Even with the configuration of the first modification, the same effect as that of the first embodiment can be achieved.

[0122] [Embodiment 2] In the data management system 1 according to the first embodiment, an example has been described in which a time stamp token obtained for a terminal hash value is stored in the distributed ledger set 50 (at least one of the distributed ledgers 51 and 52). This improves the tamper resistance of the time stamp token. In the second embodiment, an example will be described in which the tamper resistance of the time stamp token is improved by another method.

[0123] 11 is a diagram showing a schematic configuration of a data management system 1A according to embodiment 2. In data management system 1A, the client server 2 in data management system 1 according to embodiment 1 is changed to a client server 2A, and an external server 9 is further provided. Other configurations of data management system 1A are similar to those of data management system 1 according to embodiment 1, and therefore description thereof will not be repeated.

[0124] Client server 2A is a configuration obtained by changing control device 21 to control device 21A, communication device 24 to communication device 24A, and distributed ledger set 50 included in storage device 27 to distributed ledger set 55. The rest of the configuration of client server 2A is similar to that of client server 2 according to embodiment 1, and therefore description thereof will not be repeated.

[0125] Fig. 12 is a diagram showing an example of the configuration of a distributed ledger set 55 according to the second embodiment. Referring to Fig. 12, the distributed ledger set 55 includes a distributed ledger 56 that stores the update state of the part data of a first part in chronological order and serves as an evidence chain for the part data of the first part, and a distributed ledger 57 that stores the update state of the part data of a second part in chronological order and serves as an evidence chain for the part data of the second part. The distributed ledgers 56 and 57 store records including information on "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV" in chronological order, similar to the distributed ledgers 51 and 52 according to the first embodiment.

[0126] 11 and 12, the client server 2A and the client server 2 have different timings for executing the existence proof process (the process of generating a termination hash value and obtaining a time stamp token). The client server 2 according to the first embodiment executes the existence proof process in response to a second request indicating that a second operation for simultaneously updating the part data of the first part and the part data of the second part has been performed. The client server 2A according to the second embodiment executes the existence proof process in response to a third request indicating that a third operation for requesting the acquisition of a time stamp token has been performed.

[0127] For the first and second requests, the client server 2A (control device 21A) executes the process of FIG. 8 described in the first embodiment, and adds a record to the distributed ledger 56 and / or the distributed ledger 57. More specifically, when the control device 21A updates the database 4 in response to the first operation for updating the part data of the first part, for example, the control device 21A adds a record including a hash value of the updated part data of the first part to the distributed ledger 56. Also, when the control device 21A updates the database 4 in response to the first operation for updating the part data of the second part, for example, the control device 21A adds a record including a hash value of the updated part data of the second part to the distributed ledger 57. Furthermore, when the control device 21A updates the database 4 in response to the second operation for simultaneously updating the part data of the first and second parts, for example, the control device 21A adds a record including a hash value of the updated part data of the first part to the distributed ledger 56, and adds a record including a hash value of the updated part data of the second part to the distributed ledger 57. In response to the second request, the client server 2A according to the second embodiment does not generate a termination hash value or obtain a time stamp token. The processing for the first and second requests in the second embodiment is as described in FIGS. 5 and 8 in the first embodiment, and therefore the details will not be repeated. In addition, the processing when transaction data is received from another client server 2A in the second embodiment is as described in FIGS. 7 and 10 in the first embodiment, and therefore the details will not be repeated.

[0128] Fig. 13 is a diagram for explaining the existence proof process in embodiment 2. The upper part of Fig. 13 shows a schematic diagram of a distributed ledger 56 which is an evidence chain of the first part, and the lower part of Fig. 3 shows a schematic diagram of a distributed ledger 57 which is an evidence chain of the second part.

[0129] The first evidence chain (distributed ledger 56) stores records including hash values ​​of the part data of the first part in chronological order. The second evidence chain (distributed ledger 57) stores records including hash values ​​of the part data of the second part in chronological order. Here, as shown in FIG. 13, it is assumed that in the distributed ledger 56, record RA3 with Age "3" is the latest (terminal) record, and in the distributed ledger 52, record RB2 with Age "2" is the latest (terminal) record. In this state, it is assumed that a third operation has been performed on the input device 25 or the user terminal device 7 to request acquisition of a timestamp token.

[0130] When the third operation is accepted, the input device 25 or the user terminal device 7 outputs a third request indicating that the third operation has been performed. The third operation may be, for example, an operation of selecting a button that requests acquisition of a time stamp token displayed on the display device 26 or the display screen of the user terminal device 7. When the control device 21A accepts the third request, it generates an end hash value including the record hash value of the end record RA3 of the distributed ledger 56 and the record hash value of the end record RB2 of the distributed ledger 57. Then, the control device 21A transmits the end hash value to the time stamp authority 8 via the communication device 24A. The time stamp authority 8 transmits to the client server 2A a time stamp token in which the end hash value is combined with time information based on a time source that is traceable to international standard time. The control device 21A stores the time stamp token in the storage device 27 as a time certificate. In the second embodiment, by acquiring a time stamp token for an end hash value including the record hash value of the end record RA3 of the distributed ledger 56 and the record hash value of the end record RB2 of the distributed ledger 57, it is possible to prove that the part data D10 to D13 of the first part existed and that the part data D20 to D22 of the second part existed at the time proven by the time stamp token. Furthermore, if a record is added to the distributed ledgers 56 and 57 after acquiring the time stamp token, it is possible to prove that the part data corresponding to the record was registered after the time proven by the time stamp token. Compared to the case where a time stamp token is acquired for the record hash value of the record every time a record is added to each of the distributed ledgers 56 and 57, it is possible to reduce the man-hours, costs, system load, and the like.

[0131] Furthermore, the communication device 24A is configured to be able to communicate with the external server 9. The control device 21A transmits a time certificate to the external server 9 via the communication device 24A.

[0132] External server 9 is a server separated from network NW (i.e., a server not participating in network NW) and is managed by a management entity that is not any of companies A, B, C, or D. By storing and managing time certificates in storage device 27 and also managing the time certificates in external server 9, it is possible to increase the resistance to tampering of the time certificates (i.e., time stamp tokens).

[0133] Fig. 14 is a functional block diagram of the control device 21A for executing the existence proof process in the second embodiment. With reference to Fig. 14, the control device 21A includes an information acquisition unit 2131, a terminal hash generation unit 2132, a time stamp token acquisition unit 2133, and an output unit 2134. The control device 21A functions as the information acquisition unit 2131, the terminal hash generation unit 2132, the time stamp token acquisition unit 2133, and the output unit 2134, for example, by executing a program stored in the ROM 22. Note that the information acquisition unit 2131, the terminal hash generation unit 2132, the time stamp token acquisition unit 2133, and the output unit 2134 may be realized by, for example, dedicated hardware (electronic circuit).

[0134] When a third operation 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 third request indicating that the third operation has been performed.

[0135] 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 2A operates the input device 25 to select a button requesting acquisition of a timestamp token on the display screen of the display device 26 (performs a third operation), the third request is input to the information acquisition unit 2131. Upon acquiring the third request, the information acquisition unit 2131 outputs the third request to the termination hash generation unit 2132.

[0136] Upon receiving the third request, the end hash generator 2132 generates a record hash value of the latest (end) record stored in the distributed ledger 56 and a record hash value of the latest (end) record stored in the distributed ledger 57, and generates an end hash value including these. The end hash generator 2132 outputs the generated end hash value to the timestamp token acquirer 2133.

[0137] The time stamp token acquisition unit 2133 outputs a control signal for transmitting the termination hash value received from the termination hash generation unit 2132 to the time stamp authority 8 to the communication device 24A. As a result, the termination hash value is transmitted to the time stamp authority 8 via the communication device 24A.

[0138] The time stamp authority 8 that receives the termination hash value returns a time stamp token to the client server 2 .

[0139] The time stamp token acquisition unit 2133 receives a time stamp token from the time stamp authority 8 via the communication device 24A. The time stamp token acquisition unit 2133 outputs the acquired time stamp token to the output unit 2134.

[0140] The output unit 2134 stores the time stamp token received from the time stamp token acquisition unit 2133 in the storage device 27. Alternatively, the output unit 2134 may store the time stamp token received from the time stamp token acquisition unit 2133 in the database 4. This makes it possible to acquire proof of the existence time of the part data of the first part and the part data of the second part.

[0141] Furthermore, the output unit 2134 transmits the time certificate received from the time certificate acquisition unit 2133 to the external server 9. Specifically, the output unit 2134 outputs a control signal for transmitting the time certificate to the external server 9 to the communication device 24A. As a result, the time certificate is transmitted to the external server 9 via the communication device 24A, and the time certificate is managed by the external server 9. For example, in order to tamper with the time certificate, in addition to the time certificate managed by the client server 2A, the time certificate (time stamp token) managed by the external server 9 must also be tampered with. By managing the time certificate also by the external server 9, the tamper-resistance of the time stamp token can be improved.

[0142] 15 is a flowchart showing a procedure of a process for acquiring a time stamp token. The process of the flowchart shown in FIG.

[0143] In S31, the control device 21A generates a record hash value of the latest (terminal) record stored in the distributed ledger 56.

[0144] In S32, the control device 21A generates a record hash value of the latest (terminal) record stored in the distributed ledger 57.

[0145] In S33, the control device 21A generates a terminal hash value that includes the record hash values ​​generated in S31 and S32.

[0146] In S34, the control device 21A obtains a time stamp token for the termination hash value generated in S33. Specifically, the control device 21A outputs a control signal for transmitting the termination hash value to the TSA 8 to the communication device 24A. As a result, the record hash value is transmitted to the TSA 8 via the communication device 24A. Then, the control device 21A obtains a time stamp token for the termination hash value from the TSA 8 via the communication device 24A.

[0147] In S35, the control device 21A stores the time stamp token acquired in S34 in the storage device 27. The control device 21A may store the time stamp token in the database 4.

[0148] In S36, the control device 21A transmits the time stamp token acquired in S34 as a time certificate to the external server 9. Specifically, the control device 21A outputs a control signal for transmitting the time certificate to the external server 9 to the communication device 24A. As a result, the time certificate is transmitted to the external server 9 via the communication device 24A.

[0149] As described above, in the data management system 1A according to the second embodiment, in response to the third operation, the client server 2A acquires a time stamp token for an end hash value including the record hash values ​​of the latest (end) records of the two distributed ledgers 56, 57. The client server 2A then stores the time stamp token in the storage device 27 and transmits the time stamp token (time certificate) to the external server 9. By also managing the time stamp token in the external server 9, it is possible to improve the tamper resistance of the time stamp token.

[0150] [Embodiment 3] In the first embodiment, an example has been described in which the platform server 5 has a function of permitting participation in the network NW. The finality of the transaction data is given by confirming the validity of the electronic signature between the client servers 2 permitted to participate in the network NW. In the third embodiment, an example will be described in which the platform server 6 has a function of granting finality to the transaction data in addition to the function of permitting participation in the network NW.

[0151] FIG. 16 is a diagram showing a schematic configuration of a data management system 1B according to the third embodiment. The data management system 1B has the same functions as the data management system 1 according to the first embodiment. The data management system 1B includes four client servers 3, a platform server 6, and a time-stamping authority 8. As in the first embodiment, 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). In the following, 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 have similar functions.

[0152] Like the platform server 5 according to the first and second embodiments, the platform server 6 manages the network NW and accepts applications for participation in the network NW from each client server 3. The platform server 6 permits the client server 3 to participate in the network NW based on an operation by the administrator of the platform server 6 to permit participation or based on the result of judging a predetermined condition. In the third embodiment as well, four client servers 3 belonging to each of companies A, B, C, and D are permitted to participate in the network NW.

[0153] 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 by the operation of the installed distributed ledger infrastructure software. The client servers 3 are configured to be able to communicate with a user terminal device 7, similar to the client server 2 according to the first embodiment.

[0154] Similarly to the client server 2 according to the first embodiment, 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 an input device 35 or a request from a user terminal device 7, and outputs the control signal to the database 4.

[0155] When the client server 3 stores / updates part data in the database 4, it creates a hash value of 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. Then, the client server 3 transmits the generated transaction data to the platform server 6.

[0156] The platform server 6 has a 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. When the platform server 6 updates the ledger set 60, it transmits records (proof records described below) added to the ledger by the update to all client servers 3 participating in the network NW. The client server 3 stores a commit table 374 that stores commit records, and stores the proof records received from the platform server 6 in the commit table 374 as commit records. The commit table 374 corresponds to an example of a "distributed ledger" according to the present disclosure.

[0157] FIG. 17 is a diagram showing an example of the configuration of the ledger set 60. The ledger set 60 includes a ledger 67 and a ledger 68. The ledger 67, like the distributed ledger 51 according to the first embodiment, stores the update state of the part data of the first part in chronological order, forming an evidence chain of the part data of the first part. The ledger 68, like the distributed ledger 52 according to the first embodiment, stores the update state of the part data of the second part in chronological order, forming an evidence chain of the part data of the second part. The ledger set 60, the ledger 67, and the ledger 68 have the same configuration as the distributed ledger set 50, the distributed ledger 51, and the distributed ledger 52 according to the first embodiment, respectively. Therefore, detailed description of these will not be repeated. Note that FIG. 17 shows the data structures of the ledgers 67 and 68 corresponding to the example shown in FIG. 3. That is, the ledgers 67 and 68 each store a record of Age "3" as the latest (terminal) record.

[0158] 16 again, 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 similar in configuration to 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.

[0159] The storage device 37 stores a private key 371 and proof data 372. The private key 371 is the private key of company A. For example, when the client server 3 first joins the network NW, the control device 31 generates a private key and a public key. Then, the control device 31 transmits the generated public key to a certification authority (not shown) and receives authentication. The certification authority issues an electronic certificate including information on 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 transmits the authenticated public key (electronic certificate) 651 to the platform server 6.

[0160] The proof data 372 includes a suspension table 373 and a commit table 374. Fig. 18 is a diagram for explaining an example of the configuration of the suspension table 373. Fig. 19 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.

[0161] Referring to FIG. 18, the suspension table 373 includes a predetermined type of information included in unused transaction data. Specifically, the suspension table 373 stores a suspension record including, for example, information on a key and a nonce. The control device 31 stores, as a suspension record, information on the key and nonce, among information included in transaction data generated in response to the first request or the second request, in the suspension table 373. The first request and the second request received by the client server 3 from the input device 35 or the user terminal device 7 include an 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". The second request includes an ID indicating "k1" and an ID indicating "k2". That is, the ID of the target part included in the first request or the second request becomes the key. In addition, when the first request or the second request is received, the control device 31 generates a nonce value. The nonce value indicates the number of the process of the first request or the second request (that is, the number of the transaction data). The control device 31 creates a suspension record including information on the key and nonce, and registers the suspension record in the suspension table 373. Fig. 18 shows an example in which a suspension record including a key of 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."

[0162] 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 similar to the key contained in the transaction data used to execute the transaction processing.

[0163] In the suspension table 373, duplicate suspension records including information of the same key are not registered. When registering a suspension record in the suspension table 373, the control device 31 judges whether or not a suspension record including a key matching the key included in the suspension record to be registered has already been registered in the suspension table 373. If a suspension record including a key matching the key included 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 including a key matching the key included in the suspension record to be registered has been registered in the suspension table 373, the control device 31 waits for the suspension record including the matching key to be deleted from the suspension table 373. That is, in the example shown in FIG. 18, a suspension record including a key of k2 can be registered in the suspension table 373, but a suspension record including a key of k1 cannot be registered.

[0164] The commit table 374 includes a predetermined type of information included in used transaction data. Specifically, the commit table 374 stores a commit record including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. In the third embodiment, the commit record has the same information as the records in the ledger set 60. The commit table 374 includes 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.

[0165] When the platform server 6 executes a transaction process 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 a record that includes, for example, information on the Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV of a record that has been added to the ledger by a transaction process executed using the transaction data.

[0166] Upon receiving the proof record, the control device 31 adds the proof record as a commit record to the commit table 374 (commit data 375 or commit data 376). Then, the control device 31 deletes from the suspension table 373 any suspension records that include the same key as the key included in the added commit record.

[0167] 16 again, 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.

[0168] The control device 61 is configured by 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 and the like. The RAM 63 functions as a working memory and temporarily stores various data required for executing the various programs. The control device 61 receives transaction data from the client server 3 and executes transaction processing.

[0169] The communication device 64 is configured to be capable of communicating with the client server 3 participating in the network NW.

[0170] The storage device 65 stores a plurality of public keys 651 and a ledger set 60. The plurality of public keys 651 include public keys of companies that manage client servers 3 participating in the network NW. Specifically, the plurality of public keys 651 include a public key of company A, a public key of company B, a public key of company C, and a public key of company D.

[0171] As described above, the ledger set 60 has a similar configuration to the distributed ledger set 50 according to embodiment 1.

[0172] The process of responding to update requests (first request, second request) in the third embodiment will be described below in order with reference to flowcharts.

[0173] 20 is a flowchart showing the procedure of processing executed by the data management system 1B when an update request (first request, second request) is received. The processing of the flowchart shown in FIG. 20 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.

[0174] In S40, the control device 31 of the client server 3 generates a nonce value. This nonce value is used as the number of transaction data generated in response to an update request.

[0175] In S41, the control device 31 of the client server 3 generates a suspension record. Specifically, the control device 31 of the client server 3 reads out 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. Note that if the update request is a second request, the control device 31 generates a suspension record with the ID (k1) of the first part as Key information and a suspension record with the ID (k2) of the second part as Key information.

[0176] In S42, the control device 31 of the client server 3 judges whether or not 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.

[0177] In S 43 , the control device 31 of the client server 3 registers a suspension record in the suspension table 373 .

[0178] In S44, the control device 31 of the client server 3 generates transaction data to respond to the update request. Specifically, when the update request is the first request, the control device 31 of the client server 3 executes the same process as the process of S2 to S4 described in FIG. 8 to generate transaction data. When the update request is the second request, the control device 31 of the client server 3 executes the same process as the process of S11 described in FIG. 9 to generate transaction data corresponding to the updates of the first part and the second part. Furthermore, when the update request is the second request, the control device 31 of the client server 3 executes the same process as the process of S13 to S16 described in FIG. 9 to generate transaction data. Details of each process are as described in FIG. 8 and FIG. 9, so they will not be described repeatedly.

[0179] In S45, the control device 31 of the client server 3 outputs a control signal to the communication device 34 for transmitting the transaction data generated in S44 to the platform server 6. As a result, the transaction data is transmitted to the platform server 6 via the communication device 34.

[0180] In S50, the 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. 10 to decrypt the electronic signature. Details of each process are as described in Fig. 10 and will not be described repeatedly.

[0181] In S51, 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 a hash value included in the transaction data (a hash value of the part data of the target part in the transaction data generated in response to the first request, and a time stamp token 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.

[0182] In S52, the 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. Then, the control device 61 of the platform server 6 advances the process to S56.

[0183] In S53, the 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. 10, generates a ledger record specified by the key information included in the transaction data, adds the generated record to the ledger, and updates the ledger set 60.

[0184] In S54, the control device 61 of the platform server 6 generates a proof record. The proof record includes the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV included in the record added to the ledger.

[0185] In S55, the 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.

[0186] In S56, the control device 61 of the platform server 6 outputs a control signal to the communication device 64 for transmitting the abnormality report created in S52 or the normality report created in S55 to the client server 3 that is the sender of the transaction data. As a result, the abnormality report or normality report is transmitted to the client server 3 via the communication device 64.

[0187] Furthermore, in S56, the control device 61 of the platform server 6 outputs a control signal to the communication device 64 for transmitting 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). As a result, the proof record is transmitted to the other client servers 3 via the communication device 64.

[0188] In S46, the control device 31 of the client server 3 judges whether or not a normal report has been received from the platform server 6. If it judges 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 judges that a normal report has not been received, that is, that an abnormality report has been received (NO in S46), the control device 31 of the client server 3 advances the process to S49.

[0189] In S47, 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.

[0190] In S48, the control device 31 of the client server 3 deletes from the suspension table 373 the suspension record that has the same key information as the added commit record.

[0191] In S49, the 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.

[0192] In addition, the other client servers 3 (client servers 3 of companies B, C, and D) that received the proof record sent in S56 also add the proof record to their commit tables 374, thereby updating their commit tables 374.

[0193] As described above, in the data management system 1B according to the third embodiment, the platform server 6 provides finality to transaction data. The platform server 6 holds the 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, and the ledger 68 stores the update state of the part data of the second part in chronological order. When the ledger set 60 is updated, a proof record having information of the record added to the ledger set 60 is sent from the platform server 6 to each client server 3. 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. In the configuration of the data management system 1B according to the third embodiment, in response to the second request, record hash values ​​of the latest (terminal) records of the two commit data 375 and 376 are generated, and a terminal hash value including these is generated. Then, a timestamp token is obtained for the terminal hash value. By obtaining a timestamp token for the terminal hash value, it is possible to prove, for example, as in the example of Figure 3 of embodiment 1, that part data of the first part (for example, D10 to D13 in the example of Figure 3) existed and that part data of the second part (for example, D20 to D22 in the example of Figure 3) existed at the time proven by the timestamp token.

[0194] Furthermore, by incorporating the timestamp token into the record of at least one ledger included in the ledger set 60, the timestamp token is incorporated into at least one commit data included in the commit table 374. This can improve the tamper resistance of the timestamp token.

[0195] [Variation 2] In the third embodiment, an example has been described in which the commit table 374 has information similar to that contained in the ledger set 60. Specifically, each of the commit data 375, 376 in the commit table 374 has information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The commit table 374 may have a part of the information contained in the ledger set 60. For example, each of the commit data 375, 376 in the commit table 374 may be configured to include information on Key, Age, Obj-HV, HV, and Nonce from the information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV that each of the ledgers 67, 68 in the ledger set 60 has. In this case, the proof record is also generated to include information on Key, Age, Obj-HV, HV, and Nonce. That is, the commit data 375, 376 are summaries of the ledgers 67, 68. By making the commit data 375, 376 a summary of the ledgers 67, 68, the amount of data stored in the storage device 37 of the client server 3 can be reduced compared to a case in which the commit data 375, 376 and the ledgers 67, 68 have similar information.

[0196] [Variation 3] The third embodiment may be combined with the configuration of the second embodiment. That is, in the third embodiment, the existence proof process may be executed in response to the third request. Even in such a configuration, the same effects as those of the second embodiment can be achieved.

[0197] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is defined by the claims, not by the description of the embodiments described above, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0198] 1,1A,1B Data management system, 2,2A,3 Client server, 4 Database, 5,6 Platform server, 7 User terminal device, 8 Time stamping authority, 9 External server, 21,21A Control device, 22 ROM, 23 RAM, 24,24A Communication device, 25 Input device, 26 Display device, 27 Storage device, 29 Bus, 31 Control device, 32 ROM, 33 RAM, 34 Communication device, 35 Input device, 36 Display device, 37 Storage device, 39 Bus, 50 Distributed ledger set, 51,52 Distributed ledger, 55 Distributed ledger set, 56,57 Distributed ledger, 60 Ledger set, 61 Control device, 62 ROM, 63 RAM, 64 Communication device, 65 Storage device, 67,68 Ledger, 69 Bus, 271 Private key, 272 Multiple public keys, 371 Private key, 372 Proof data, 373 suspension table, 374 commit table, 375, 376 commit data, 651 multiple public keys, 2101 information acquisition unit, 2102 hash generation unit, 2103 nonce generation unit, 2104 electronic signature unit, 2105 transaction data generation unit, 2106 transaction data transmission unit, 2111 information acquisition unit, 2112 record addition unit, 2113 terminal hash generation unit, 2114 nonce generation unit, 2115 time stamp token acquisition unit, 2116 electronic signature unit, 2117 transaction data generation unit, 2118 transaction data transmission unit, 2121 transaction data acquisition unit, 2122 signature verification unit, 2123 record creation unit, 2124 ledger update unit, 2125 output unit, 2131 information acquisition unit, 2132 terminal hash generation unit, 2133 Time stamp token acquisition unit, 2134 output unit, NW network.

Claims

1. A data management device that manages data using distributed ledger technology, A storage device that stores a distributed ledger that chronologically stores records including information about the data; a control device for adding the record to the distributed ledger; A communication device configured to be able to communicate with a time stamp authority, 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 includes: Generate an end value that includes information of an end record of the first distributed ledger and information of an end record of the second distributed ledger; obtaining a time stamp token for the terminal value from the time stamp authority via the communication device; A data management device that stores a record including the timestamp token in at least one of the first distributed ledger and the second distributed ledger.

2. The communication device is further configured to be able to communicate with an external server different from the data management device, The data management device according to claim 1 , wherein the control device stores the time stamp token in the storage device and transmits the time stamp token to the external server via the communication device.

3. 3. The data management device according to claim 1, wherein the control device generates the terminal value when it stores a record including the first information in the first distributed ledger and stores a record including the second information in the second distributed ledger in response to updates of the first data and the second data.

4. 3. The data management device according to claim 1, wherein the control device generates the terminal value when a predetermined time has elapsed since the previous time stamp token was acquired.

5. The information of the end record of the first distributed ledger is a hash value of the end record of the first distributed ledger, The data management device according to claim 1 , wherein the information of the record at the end of the second distributed ledger is a hash value of the record at the end of the second distributed ledger.

6. the first information is a hash value of the first data, The data management device according to claim 1 , wherein the second information is a hash value of the second data.

7. A data management method for a data management device that manages data using distributed ledger technology, comprising: The data management device includes: A storage device that stores a distributed ledger that chronologically stores records including information about the data; a control device for adding the record to the distributed ledger; A communication device configured to be able to communicate with a time stamp authority, 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: generating an end value including information of an end record of the first distributed ledger and information of an end record of the second distributed ledger; obtaining a time stamp token for the terminal value from the time stamp authority via the communication device, and storing a record including the time stamp token in at least one of the first distributed ledger and the second distributed ledger.

Images