Data management device and data management method

Abstract

When a control device (21) of a client server (2) performs a second operation for simultaneously updating component data (D12) to component data (D13) and updating component data (D21) to component data (D22), a record (RA3) including hash values of the component data (D13) is created in a first evidence chain (distributed ledger 51), and a record (RA4) including hash values of the component data (D13) is created in a second evidence chain (distributed ledger 52). A record (RB2) including hash values of the component data (D22) is created. A control device (21) generates an end hash value including a record hash value of a record (RA3) and a record hash value of a record (RB2), and acquires a timestamp token for the end hash value.

Description

Technical Field

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

[0002] Patent Gazette No. 6694204 (Patent Document 1) discloses a data management system that constructs a distributed ledger (asset) having a DAG (Directed Acyclic Graph) structure for each Key (ID) used to identify a management object, and manages information for each ID.

[0003] Prior art literature

[0004] Patent Literature

[0005] Patent Document 1: Japanese Patent No. 6694204 Summary of the invention

[0006] Problems to be solved by the invention

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

[0008] Here, in order to prove the existence time of the data added to each asset, it is considered to obtain a timestamp token for the latest asset record every time each asset is updated. However, if a timestamp token is obtained for each asset, there is a possibility that the acquisition cost of the timestamp token will increase or the system load will increase.

[0009] The present disclosure is made to solve the above-mentioned problems, and an object of the present disclosure is to easily prove the existence time of data stored in multiple distributed ledgers in a system having multiple distributed ledgers.

[0010] Technical solutions to solve problems

[0011] (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 comprises a storage device that stores a distributed ledger that stores records containing information related to the data in time series, a control device that appends records to the distributed ledger, and a communication device that is configured to communicate with a time authentication agency. The data comprises first data and second data. The distributed ledger comprises a first distributed ledger that stores records containing first information related to the first data in time series, and a second distributed ledger that stores records containing second information related to the second data in time series. The control device generates an end value including information of the records at the end of the first distributed ledger and information of the records at the end of the second distributed ledger, and obtains a timestamp token for the end value from the time authentication agency via the communication device.

[0012] According to the above structure, a timestamp token for the end value of the information including the record at the end of the first distributed ledger and the record at the end of the second distributed ledger is obtained. By obtaining the timestamp token for the end value, it is possible to collect and obtain the existence proof 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.

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

[0014] According to the above configuration, the time stamp token is stored in at least one of the first distributed ledger and the second distributed ledger, so that the tamper resistance of the time stamp token can be improved.

[0015] (3) In one 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 causes the storage device to store the time stamp token and transmits the time stamp token to the external server via the communication device.

[0016] According to the above structure, the time stamp token is managed by the data management device and also managed 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 also managing the time stamp token by the external server, the tamper resistance of the time stamp token can be improved compared with the case where the time stamp token is managed only by the data management device.

[0017] (4) In one embodiment, the control device generates a terminal value when, in response to updates of the first data and the second data, the control device 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.

[0018] According to the above configuration, the user of the data management device can obtain the time stamp token for the end value through a user operation such as updating the first data and the second data.

[0019] (5) In one embodiment, the control device generates an end value when a predetermined time has passed since the time when the time stamp token was last acquired.

[0020] According to the above configuration, a time stamp token for the end value can be automatically acquired every time a predetermined time elapses.

[0021] (6) In one embodiment, the information of the record at the end of the first distributed ledger is a hash value of the record at the end of the first distributed ledger, and 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.

[0022] According to the above configuration, the information of the record included in the terminal value is the hash value of the record, so the record itself is not transmitted to the time authentication authority. Therefore, when the time stamp token is obtained, the record itself can be kept secret.

[0023] (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.

[0024] According to the above structure, the records stored in the first distributed ledger and the second distributed ledger include the hash value of the first data and the 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 hidden from other data management devices forming the distributed ledger network.

[0025] (8) Another aspect of the data management method disclosed herein is a data management method for 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 stores records containing information related to the data in time series, a control device that appends records to the distributed ledger, and a communication device that is configured to communicate with a time authentication agency. The data includes first data and second data. The distributed ledger includes a first distributed ledger that stores records containing first information related to the first data in time series, and a second distributed ledger that stores records containing second information related to the second data in time series. The data management method includes the steps of generating an end value of information containing records at the end of the first distributed ledger and information containing records at the end of the second distributed ledger, and the step of obtaining a timestamp token for the end value from the time authentication agency via the communication device.

[0026] Effects of the Invention

[0027] According to the present disclosure, in a system having multiple distributed ledgers, it is possible to easily certify the existence time of data stored in the multiple distributed ledgers. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a diagram showing a schematic configuration of a data management system according to the first embodiment.

[0029] Figure 2 This is a diagram (part 1) showing an example of the structure of a distributed ledger set.

[0030] Figure 3 This is a diagram used to illustrate the existence proof processing.

[0031] Figure 4 This is a diagram showing an example of the structure of a distributed ledger set (part 2).

[0032] Figure 5 This is a functional block diagram of a control device for executing a process in response to a first operation.

[0033] Figure 6 This is a functional block diagram of a control device for executing a process in response to a second operation.

[0034] Figure 7 It is a functional block diagram of a control device for executing received transaction data.

[0035] Figure 8 This is a flowchart showing the procedure of a process for generating transaction data when the first request is received.

[0036] Fig. 9 This is a flowchart showing the procedure of processing for generating transaction data when the second request is received.

[0037] Fig.10 is a flowchart showing the order of processing performed when transaction data is received.

[0038] Fig.11 This is a diagram showing a schematic structure of a data management system according to the second embodiment.

[0039] Fig.12 This is a diagram showing an example of the structure of a distributed ledger set according to Implementation Example 2.

[0040] Fig.13 This is a diagram used to illustrate the existence proof processing in Implementation Example 2.

[0041] Fig.14 This is a functional block diagram of a control device for performing proof of existence processing in Implementation Example 2.

[0042] Fig.15This is a flowchart showing the procedure of the process of obtaining a time stamp token.

[0043] Fig.16 This is a diagram showing a schematic structure of a data management system according to the third embodiment.

[0044] Fig.17 This is a diagram showing an example of the structure of a ledger set.

[0045] Fig.18 This is a diagram for explaining an example of the structure of the pause table.

[0046] Fig.19 This is a diagram for explaining an example of the structure of a submission form.

[0047] Fig. 20 This is a flowchart showing the procedure of processing executed by the data management system when an update request (first request, second request) is received.

[0048] (Explanation of symbols)

[0049] 1, 1A, 1B: data management system; 2, 2A, 3: client server; 4: database; 5, 6: platform server; 7: user terminal device; 8: time authentication agency; 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 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: secret key; 272: multiple public keys; 371: secret key key; 372: verification data; 373: pause form; 374: submission form; 375, 376: submission data; 651: multiple public keys; 2101: information acquisition unit; 2102: hash generation unit; 2103: random number generation unit; 2104: electronic signature unit; 2105: transaction data generation unit; 2106: transaction data transmission unit; 2111: information acquisition unit; 2112: record appending unit; 2113: terminal hash generation unit; 2114: Machine number generation unit; 2115: timestamp token acquisition unit; 2116: electronic signature unit; 2117: transaction data generation unit; 2118: transaction data sending unit; 2121: transaction data acquisition unit; 2122: signature verification unit; 2123: record preparation unit; 2124: ledger update unit; 2125: output unit; 2131: information acquisition unit; 2132: terminal hash generation unit; 2133: timestamp token acquisition unit; 2134: output unit; NW: network. DETAILED DESCRIPTION

[0050] Hereinafter, the embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In addition, the same reference numerals are attached to the same or corresponding parts in the drawings, and their description will not be repeated.

[0051] [Implementation Method 1]

[0052] <Overall structure of data management system>

[0053] Figure 11 is a diagram showing a schematic structure of a data management system 1 according to Embodiment 1. The data management system 1 according to Embodiment 1 is a system for forming an alliance network (hereinafter also referred to as a "network") NW between a plurality of enterprises and managing data using a distributed ledger technology. The data management system 1 according to Embodiment 1 manages data of components constituting a vehicle (hereinafter also referred to as "component data"). The component data may be, for example, a specification sheet of a component. In addition, the data managed by the data management system 1 is not limited to data of components constituting a vehicle, but may be various data.

[0054] Reference Figure 1 The data management system 1 has four client servers 2, a platform server 5 and a time certification agency (TSA: Time Stamp Authority) 8. The four client servers 2 are servers belonging to different companies (for example, Company A, Company B, Company C and Company D).

[0055] 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 of permitting participation performed by an administrator of the platform server 5 or based on a determination result of a predetermined condition. In the first embodiment, four client servers 2 belonging to Company A, Company B, Company C, and Company D are permitted to participate in the network NW.

[0056] The four client servers 2 form a network NW and store the hash value of the component data in their respective distributed ledgers. By importing the distributed ledger-based software into each client server 2, the imported distributed ledger-based software functions, so that each client server 2 functions as a node. Below, the client server 2 of company A is representatively described, but the client servers of companies B, C, and D also have the same structure and function. In addition, the client server 2 is equivalent to an example of the "data management device" disclosed in the present invention.

[0057] 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) lent to employees of Company A, a notebook PC, a tablet terminal, a smartphone, or other information processing terminal having a communication function.

[0058] In addition, a database 4 is connected to the client server 2. The database 4 stores component data. The database 4 stores or updates the component 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, etc.) can request to update the component 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 component 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.

[0059] If the client server 2 stores / updates the component data to the database 4, a hash value of the component data is generated, and transaction data for storing the hash value in the distributed ledger is generated. The client server 2 then sends the generated transaction data to other client servers 2 forming the network NW, i.e., the client servers 2 of Enterprise B, Enterprise C, and Enterprise D. The distributed ledger stores the hash value of the component data in a time series, forming a chain of evidence for proving the existence of the component data. In addition, in the data management system 1 of Implementation Example 1, an example is described in which four client servers are included in the network NW, but the number of client servers 2 included in the network NW is arbitrary, for example, it can be less than four or more than five.

[0060] The time authentication agency 8 includes a server belonging to the authentication authority that issues the time stamp token. The time authentication agency issues the time stamp token in response to the time stamp issuance request from the applicant (the client server 2 in the first embodiment). More specifically, the time authentication agency sends the time stamp token obtained by combining the time information based on the time source that has the ability to track the international standard time with the data received from the applicant (the terminal hash value described later in the first embodiment) to the applicant.

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

[0062] The control device 21 is composed of, for example, an integrated circuit including a CPU (Central Processing Unit). The control device 21 expands and executes various programs stored in the ROM 22 in the RAM 23. The various programs include an operating system, etc. The RAM 23 functions as a working memory and temporarily stores various data required to execute various programs. As described in detail later, the control device 21 has the function of updating component data recorded in the database 4, or generating transaction data for updating a distributed ledger, or obtaining a timestamp token.

[0063] The communication device 24 is configured to be able to communicate with external devices. The external devices include, for example, other client servers 2, user terminal devices 7, and time authentication agencies 8. The communication device 24 communicates with the external devices 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 a combination thereof.

[0064] The input device 25 includes an input device. The input device is, for example, a mouse, a keyboard, a touch panel, and / or other devices capable of accepting user operations.

[0065] The display device 26 includes a display. The display device 26 displays various images on the display according to the 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 devices.

[0066] The storage device 27 is composed of a storage medium such as a hard disk or a flash memory. The storage device 27 stores a secret key 271 , a plurality of public keys 272 , and a distributed ledger set 50 .

[0067] The secret key 271 is the secret key of the company A. For example, when the client server 2 first joins the network NW, the control device 21 generates a secret key and a public key. Then, the control device 21 sends the generated public key to the certification body (not shown) and receives certification. The certification body is a certification authority that issues electronic certificates. The certification body issues an electronic certificate containing information about the public key. The control device 21 causes the storage device 27 to store the secret key 271 corresponding to the authenticated public key. In addition, the control device 21 sends the authenticated public key (electronic certificate) 272 to the client servers 2 of the companies B, C, and D.

[0068] The plurality of public keys 272 include the public key of Company B, the public key of Company C, and the public key of Company D. The control device 21 causes the storage device 27 to store the public key received from the other client servers 2. The storage device 27 may also store the public key of itself (Company A).

[0069] The distributed ledger set 50 includes a plurality of distributed ledgers. A distributed ledger is prepared for each component constituting the vehicle. Figure 2 is a diagram showing an example of the structure of a distributed ledger set 50. In Implementation 1, an example is described in which two components (a first component and a second component) constituting a vehicle are managed by a data management system 1. That is, the distributed ledger set 50 includes a distributed ledger 51 that stores the update status of the component data of the first component in a time series and serves as a chain of evidence for the component data of the first component, and a distributed ledger 52 that stores the update status of the component data of the second component in a time series and serves as a chain of evidence for the component data of the second component. In addition, if the number of components constituting a vehicle managed by the data management system 1 is N (a natural number greater than 2), the distributed ledger set 50 includes N distributed ledgers. Below, the components whose data are managed by the distributed ledger are also referred to as "object components". That is, the object components in Implementation 1 are the first component and the second component.

[0070] The distributed ledger 51 stores records including hash values ​​of component data of the first component in time series. The records include information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

[0071] Key is information indicating the ID of the target component (first component). The first component is assigned an ID of k1.

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

[0073] Obj-HV is a hash value of the component data of the first component. For example, if the component data of the first component registered in the database 4 is updated, a hash value of the updated component data is generated (for example, Figure 2 The hash value is a numerical value obtained as a result of hashing the component data using a hash function. The details are described later. In Obj-HV, a timestamp token (for example, Figure 4 TM).

[0074] Nonce is a random value indicating the number of transaction data. That is, when the component data of the first component stored in the database 4 is updated, for example, the client server 2 (control device 21) generates a hash value of the updated component data as the number of the process stored in the distributed ledger 51. The random value is a hash value that is not prone to collision in cryptography.

[0075] Sig is an electronic signature created using the secret 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 component data of the first component) with the secret key 271. Alternatively, the electronic signature may also be created, for example, by encrypting Nonce (random value) with the secret key 271. Furthermore, the electronic signature may also be created, for example, by encrypting Obj-HV and Nonce with the secret key 271.

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

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

[0078] For example Figure 2 As shown, if we focus on the latest (end) record of the distributed ledger 51 (the record of Age "2"), the Prev-HV of the end record is the HV of the parent record (Age "1"), that is, "H2". Next, when the component data of the first component is updated and the record of Age "3" is appended, the Prev-HV of the record of Age "3" becomes the HV of the record of Age "2", that is, "H3". In this way, the end record becomes a structure containing the record hash value of the parent record. In other words, the chain of records is achieved between the Prev-HV of the end record and the HV of the parent record. In this way, the distributed ledger 51 constitutes a DAG structure.

[0079] The distributed ledger 52 stores records containing hash values ​​of component data of the second component in time series. The records contain information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV". Their details are the same as those of the records of the distributed ledger 51, so they will not be described repeatedly.

[0080] When the client server 2 (control device 21) receives the update operation of the component data via the input device 25 or the user terminal device 7, for example, the component data stored in the database 4 is updated. Then, the client server 2 (control device 21) generates transaction data for appending a record containing the hash value of the updated component data to the distributed ledger set 50 (distributed ledger 51 or distributed ledger 52). The transaction data includes information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV" and "HV".

[0081] The transaction data may also include information on the time when the transaction data is broadcast to the network NW (sent to the network NW) and information on the sender of the transaction data. The time information may be, for example, information indicating the time when the component data of the object component is recorded in the database 4. The sender information may be, for example, information indicating Company A. In addition, in more detail, the sender information of the transaction data may be information indicating a job position (a department of Company A) that has performed an operation of sending the transaction data to the network NW, or information indicating an individual (an employee of Company A) that has performed an operation of sending the transaction data to the network NW.

[0082] <Momentary proof>

[0083] Here, sometimes it is desired to prove the order of which data exists first between the component data of the first component and the component data of the second component, and the time when these data exist. As a method of proving the order and time, for example, consider that each time a record is appended to the distributed ledger 51, 52, respectively, a timestamp token is obtained for the record hash value of the appended record (end record) to prove the time when the record is appended, and the order and time of the two data are proved. However, in this method, each time a record is appended to the distributed ledger 51, 52, a timestamp token must be obtained, which increases the man-hours and costs. In addition, the processing load consumed by the data management system 1 also increases.

[0084] Therefore, in the data management system 1 of implementation mode 1, it is possible to generate a terminal hash value including a hash value of a record of a distributed ledger 51 and a hash value of a record of a distributed ledger 52, and obtain a timestamp token for the terminal hash value. By obtaining the timestamp token for the terminal hash value, it is possible to simultaneously prove the temporality of the component data of the first component and the component data of the second component at the time point when the timestamp token is obtained. Furthermore, in the data management system 1 of implementation mode 1, it is possible to incorporate the above-mentioned timestamp token into the record of at least one of the distributed ledgers 51, 52. By incorporating the timestamp token obtained for the terminal hash value into the record of at least one of the distributed ledgers 51, 52, it is possible to improve the tamper-resistance of the timestamp token. Next, using Figure 3 In addition, below, the process of generating a terminal hash value and obtaining a timestamp token for the terminal hash value is also referred to as "existence proof processing".

[0085] Figure 3 is a diagram used to illustrate the existence proof processing. Figure 3 The upper part of the diagram schematically shows the evidence chain of the first component, i.e., the distributed ledger 51. Figure 3 The lower part of the diagram schematically shows the evidence chain of the second component, that is, the distributed ledger 52. Hereinafter, the evidence chain of the first component is also referred to as the "first evidence chain", and the evidence chain of the second component is also referred to as the "second evidence chain".

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

[0087] In the first chain of evidence (distributed ledger 51), records containing hash values ​​of component data of the first component are stored in time series. If the first operation is performed, the component data D10 of the first component is registered to the database 4 for the first time, and the record RA0 containing the hash value of the component data D10 of Age "0" is stored in the distributed ledger 51. Next, if the first operation is performed to update the component data of the first component, and the updated component data D11 is registered to the database 4, the record RA1 containing the hash value of the updated component data D11 and Age "0", i.e., the record hash value of the parent record RA0, is stored in the distributed ledger 51. Furthermore, if the first operation is performed to update the component data of the first component, and the updated component data D12 is registered to the database 4, the record RA2 containing the hash value of the updated component data D12 and Age "1", i.e., the record hash value of the parent record RA1, is stored in the distributed ledger 51.

[0088] In the second chain of evidence (distributed ledger 52), records containing hash values ​​of component data of the second component are stored in time series. If the first operation is performed and the component data D20 of the second component is registered to the database 4 for the first time, the record RB0 containing Age "0" of the hash value of the component data D20 is stored in the distributed ledger 52. Next, if the first operation is performed to update the component data of the second component and the updated component data D21 is registered to the database 4, the record RB1 containing the hash value of the updated component data D21 and Age "0", i.e., Age "1", which is the hash value of the parent record RB0, is stored in the distributed ledger 52.

[0089] Here, as described above, it is assumed that in the distributed ledger 51, the record RA2 of Age "2" is the latest (end) record, and in the distributed ledger 52, the record RB1 of Age "1" is the latest (end) record. Then, it is assumed that in this state, the second operation of simultaneously updating the component data of the first component and the component data of the second component is performed on the input device 25 or the user terminal device 7. In the first embodiment, when the second operation is performed, the existence proof processing is executed. In other words, the second operation becomes the execution condition of the existence proof processing.

[0090] The second operation may be, for example, an operation of inputting the IDs (Keys) of two object components in the display screen of the display device 26 or the user terminal device 7 and selecting the displayed update button. Furthermore, in the display screen for performing the second operation, for example, there is an "object input field" for inputting the ID (Key) of the object component into which the acquired timestamp token is to be incorporated. For example, if k1 is input into the object input field, the timestamp token acquired through the proof of existence processing is incorporated into the record of the first chain of evidence (distributed ledger 51). For example, if k2 is input into the object input field, the timestamp token acquired through the proof of existence processing is incorporated into the record of the second chain of evidence (distributed ledger 52). For example, if k1 and k2 are input into the object input field, the timestamp token acquired through the proof of existence processing is incorporated into the record of the first chain of evidence (distributed ledger 51) and the record of the second chain of evidence (distributed ledger 52). Figure 3 In the example shown, it is assumed that k2 is input into the object input field.

[0091] Reference Figure 2 and Figure 3, if the second operation of simultaneously updating the component data of the first component and the component data of the second component is performed, the control device 21 first updates the component data D12 of the first component stored in the database 4 to the component data D13, and updates the component data D21 of the second component to the component data D22. In addition, when the component data D10 of the first component is stored in the database 4 for the first time, the control device 21 can make the database 4 newly store the component data of the first component. Similarly, when the component data D20 of the second component is stored in the database 4 for the first time, the control device 21 can make the database 4 newly store the component data of the second component.

[0092] Next, the control device 21 creates a record RA3 of Age "3" including the hash value of the component data D13 and the record hash value of the parent record RA2, and stores it in the distributed ledger 51. In addition, the control device 21 generates transaction data (hereinafter also referred to as "transaction data A") for appending the record RA3 to the distributed ledger 51. In addition, the control device 21 creates a record RB2 of Age "2" including the hash value of the component data D22 and the record hash value of the parent record RB1, and stores it in the distributed ledger 52. In addition, the control device 21 generates transaction data (hereinafter also referred to as "transaction data B") for appending the record RB2 to the distributed ledger 52. The control device 21 sends the generated transaction data A and B to the client servers 2 of the B company, the C company, and the D company via the communication device 24. By executing the transaction processing of the transaction data A by each client server 2 of the B company, the C company, and the D company, the record RA3 is stored in the distributed ledger 51 of each client server 2. By executing the transaction processing of the transaction data B by each client server 2 of the company B, the company C, and the company D, the record RB2 is stored in the distributed ledger 52 of each client server 2. In addition, the transaction data A and B may be generated as one transaction data.

[0093] If the control device 21 stores the records RA3 and RB2 in the distributed ledgers 51 and 52, respectively, the record hash value of the record RA3 and the record hash value of the record RB2 are generated. 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 sends the terminal hash value to the time authentication authority 8 via the communication device 24, and obtains a timestamp token for the terminal hash value from the time authentication authority 8.

[0094] Then, the control device 21 creates a record RB3 including a timestamp token and a record hash value of the record RB2 (parent record) of the distributed ledger 52, and stores it in the distributed ledger 52. In addition, the control device 21 generates transaction data for appending the record RB3 to the distributed ledger 52. The control device 21 transmits the generated transaction data to the client servers 2 of the B company, the C company, and the D company via the communication device 24. The client servers 2 of the B company, the C company, and the D company perform transaction processing on the transaction data, thereby storing the record RB3 in the distributed ledger 52 of each client server 2.

[0095] If it is shown with Figure 3 An example of the structure of the corresponding specific distributed ledger 52 is as follows Figure 4 shown. Figure 4 is a diagram showing an example of the structure of the distributed ledger set 50. By simultaneously performing the second operation of updating the component data D12 to the component data D13 and the component data D21 to the component data D22, the record RA3 of Age "3" is added to the distributed ledger 51, and the record RB2 of Age "2" is added to the distributed ledger 52. Then, the record RB3 of Age "3" storing the timestamp token obtained for the terminal hash value is added to the distributed ledger 52. In the record RB3 of Age "3" of the distributed ledger 52, the timestamp token TM is included as Obj-HV.

[0096] As described above, if an operation (second operation) is performed to simultaneously update the component data of the first component and the component data of the second component, specifically, the operation of simultaneously updating the component data D12 to the component data D13 and the component data D21 to the component data D22 is performed, the control device 21 appends the record RA3 containing the hash value of the component data D13 to the distributed ledger 51, and appends the record RB2 containing the hash value of the component data D22 to the distributed ledger 52. Then, the control device 21 generates a terminal hash value containing the record hash value of the record RA3 and the record hash value of the record RB2. The control device 21 sends the terminal hash value to the moment authentication agency 8 and obtains a timestamp token for the terminal hash value. By obtaining the timestamp token for the terminal hash value containing the record hash value of the record RA3 and the record hash value of the record RB2, it is possible to prove that the component data D10 to D13 of the first component already existed and the component data D20 to D22 of the second component already existed at the moment authenticated by the timestamp token. In addition, if Figure 3As shown, after the time point of obtaining the timestamp token, the component data D13 is updated to the component data D14, and the component data D22 is updated to the component data D23. As described above, by obtaining the timestamp token for the terminal hash value, it is possible to prove that the component data D14 and the component data D23 are registered after the time point of obtaining the timestamp token. Compared with the case where the timestamp token is obtained for the records RA3 and RB2 of the distributed ledgers 51 and 52, the man-hours, costs, system load, etc. can be reduced.

[0097] In addition, the tamper resistance of the timestamp token can be improved by incorporating the timestamp token into the records of the distributed ledger 52. In addition, the timestamp token can be incorporated into the records of the distributed ledger 51, or into the records of the distributed ledger 51 and the records of the distributed ledger 52.

[0098] Furthermore, when the component data of the first component is further updated to D13 to D14, a record RA4 of Age “4” including a hash value of the component data D14 and a record hash value of the record RA3 is added to the distributed ledger 51. Similarly, when the component data of the second component is further updated to D22 to D23, a record RB4 of Age “4” including a hash value of the component data D23 and a record hash value of the record RB3 is added to the distributed ledger 52.

[0099] <Functional Module>

[0100] Figure 5 2 is a functional block diagram of the control device 21 for executing a process in response to the first operation. Figure 5 The control device 21 includes an information acquisition unit 2101, a hash generation unit 2102, a random number generation unit 2103, an electronic signature unit 2104, a transaction data generation unit 2105, and a transaction data transmission unit 2106. The control device 21 functions as the information acquisition unit 2101, the hash generation unit 2102, the random number generation unit 2103, the electronic signature unit 2104, the transaction data generation unit 2105, and the transaction data transmission unit 2106 by, for example, executing a program stored in the ROM 22. In addition, the information acquisition unit 2101, the hash generation unit 2102, the random number generation unit 2103, the electronic signature unit 2104, the transaction data generation unit 2105, and the transaction data transmission unit 2106 may also be implemented by, for example, dedicated hardware (electronic circuit).

[0101] When a first operation for updating component data of a target component (first component or second component) is performed on the input device 25 or the user terminal 7, the input device 25 or the user terminal 7 outputs a first request indicating that the first operation has been performed.

[0102] The information acquisition unit 2101 acquires the first request from the input device 25 or the user terminal device 7. For example, when the user of the client server 2 operates the input device 25 to save (register / update) the component data of the target component to 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 component. When the information acquisition unit 2101 acquires the first request, it outputs the first request to the hash generation unit 2102 and the random number generation unit 2103.

[0103] Upon receiving the first request, the hash generation unit 2102 reads component data of the target component from the database 4 and generates a hash value of the read component data. The hash generation unit 2102 outputs the generated hash value and the ID of the target component to the electronic signature unit 2104 and the transaction data generation unit 2105.

[0104] The random number generation unit 2103 generates a random value when receiving the first request. The random value is a hash value that is not prone to collision in cryptography. The random number generation unit 2103 outputs the generated random value and the ID of the object component to the transaction data generation unit 2105. In addition, when the random value is used to create an electronic signature, the random number generation unit 2103 may also output the random value and the ID of the object component to the electronic signature unit 2104.

[0105] The electronic signature unit 2104 reads the secret key 271 from the storage device 27. The electronic signature unit 2104 generates an electronic signature by encrypting the hash value received from the hash generation unit 2102 with the secret key 271. The electronic signature unit 2104 outputs the generated electronic signature and the ID of the target component to the transaction data generation unit 2105. In addition, the electronic signature unit 2104 may generate an electronic signature by encrypting the random value received from the random number generation unit 2103 with the secret key 271. In addition, the electronic signature unit 2104 may generate an electronic signature by encrypting the hash value and the random value with the secret key 271.

[0106] The transaction data generation unit 2105 generates transaction data for sending to the network NW. For example, the transaction data generation unit 2105 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV and HV. The transaction data generation unit 2105, for example, identifies the Age of the parent record by checking the Key in the distributed ledger set 50, increases the Age of the parent record, and sets it as the Age of the appended record. The transaction data generation unit 2105 sets the hash value generated by the hash generation unit 2102 as Obj-HV, the random value generated by the random number generation unit 2103 as Nonce, and the electronic signature produced 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 and sets it as HV. The transaction data may further include information on the time when the transaction data is broadcasted to the network NW (sent to the network NW) and information on the sender of the transaction data. The transaction data generation unit 2105 outputs the generated transaction data to the transaction data transmission unit 2106 .

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

[0108] Figure 6 2 is a functional block diagram of the control device 21 for executing a process in response to the second operation. Figure 6 The control device 21 includes an information acquisition unit 2111, a record appending unit 2112, a terminal hash generation unit 2113, a random number generation unit 2114, a time stamp token acquisition unit 2115, an electronic 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 appending unit 2112, the terminal hash generation unit 2113, the random number generation unit 2114, the time stamp token acquisition unit 2115, the electronic signature unit 2116, the transaction data generation unit 2117, and the transaction data transmission unit 2118 by executing a program stored in the ROM 22, for example. In addition, the information acquisition unit 2111, the record appending unit 2112, the terminal hash generation unit 2113, the random number generation unit 2114, the timestamp token acquisition unit 2115, the electronic signature unit 2116, the transaction data generation unit 2117 and the transaction data sending unit 2118 can also be implemented by dedicated hardware (electronic circuit), for example.

[0109] When a second operation for simultaneously updating the component data of the first component and the component data of the second component is performed on the input device 25 or the user terminal 7, the input device 25 or the user terminal 7 outputs a second request indicating that the second operation has been performed.

[0110] The information acquisition unit 2111 acquires the second request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2 operates the input device 25 to save (register / update) the component data of the first component and the second component to 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 component and an ID (e.g., k2) of the target component to be incorporated into the time stamp token input into the target input field. If the information acquisition unit 2111 acquires the second request, it outputs the second request to the record appending unit 2112.

[0111] The record appending unit 2112 has Figure 5 Specifically, the record appending unit 2112 performs the same operation as described above on the object component identified by the ID. Figure 5 The same processing as shown in the figure is performed to generate a record (for example Figure 3 The record RA3) is appended to the transaction data A of the distributed ledger 51 and the record (for example Figure 3 The record appending unit 2112 adds the transaction data A and B to the distributed ledger 52 and sends them to the network NW. If the transaction data A and B are sent to the network NW, the record appending unit 2112 outputs the second request to the terminal hash generation unit 2113 and the random number generation unit 2114.

[0112] The terminal hash generation unit 2113 generates the latest (terminal) record (e.g. Figure 3 The record hash value of the record RA3) and the latest (end) record of the distributed ledger 52 (e.g. Figure 3 The terminal hash value of the record hash value of the record RB2) is obtained by the terminal hash generation unit 2113. The terminal hash value generated and the ID of the object component (for example, k2) to be incorporated into the time stamp token are output to the time stamp token acquisition unit 2115.

[0113] Upon receiving the second request, the random number generator 2114 generates a random value. The random number generator 2114 outputs the generated random value and the ID of the target component to be incorporated into the time stamp token (e.g., k2) to the transaction data generator 2117. In addition, when the random value is used to create an electronic signature, the random number generator 2114 may also output the random value and the ID of the target component to be incorporated into the time stamp token (e.g., k2) to the electronic signature unit 2116.

[0114] The time stamp token acquisition unit 2115 acquires the time stamp token for the terminal hash value received from the terminal hash generation unit 2113. Specifically, the time stamp token acquisition unit 2115 outputs a control signal for sending the terminal hash value to the time authentication unit 8 to the communication device 24. As a result, the terminal hash value is sent to the time authentication unit 8 via the communication device 24. The time authentication unit 8 that has received the terminal hash value returns the time stamp token to the client server 2 that is the source of the terminal hash value. The time stamp token acquisition unit 2115 acquires the time stamp token from the time authentication unit 8 via the communication device 24. The time stamp token acquisition unit 2115 outputs the time stamp token and the ID of the object component that is the target of incorporation of the time stamp token (for example, k2) to the electronic signature unit 2116 and the transaction data generation unit 2117.

[0115] The electronic signature unit 2116 reads the secret key 271 from the storage device 27. The electronic signature unit 2116 generates an electronic signature by encrypting the time stamp token received from the time stamp token acquisition unit 2115 with the secret key 271. The electronic signature unit 2116 outputs the generated electronic signature and the ID (e.g., k2) of the target component to be incorporated into the time stamp token to the transaction data generation unit 2117. In addition, the electronic signature unit 2116 may generate an electronic signature by encrypting the random value received from the random number generation unit 2114 with the secret key 271. In addition, the electronic signature unit 2116 may generate an electronic signature by encrypting the time stamp token and the random value with the secret key 271.

[0116] The transaction data generation unit 2117 generates transaction data (hereinafter also referred to as "transaction data C") for transmission to the network NW. For example, the transaction data generation unit 2117 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2117 sets the ID of the object component (e.g., k2) to be incorporated into the timestamp token as Key. In addition, the transaction data generation unit 2117 sets the timestamp token as Obj-HV. Other functions of the transaction data generation unit 2117 are the same as those in Figure 5 The transaction data generation unit 2105 described in is basically the same.

[0117] 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. Thus, the transaction data C is transmitted to the network NW via the communication device 24.

[0118] Figure 7 2 is a functional block diagram of the control device 21 for executing received transaction data. Figure 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 by, for example, executing a program stored in the ROM 22. In addition, 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 also be implemented by, for example, dedicated hardware (electronic circuit).

[0119] The transaction data acquisition unit 2121 acquires transaction data transmitted from another client server 2. The transaction data acquisition unit 2121 outputs the acquired transaction data to the signature verification unit 2122.

[0120] The signature verification unit 2122 verifies the validity of the electronic signature (Sig) contained in the transaction data. First, the signature verification unit 2122 determines the client server 2 as the sending source of the transaction data based on the sender information contained in the transaction data. Then, the signature verification unit 2122 reads the public key (one of the multiple public keys 272) of the determined client server 2 from the storage device 27. The signature verification unit 2122 uses the read public key to decrypt the electronic signature contained in the transaction data. As described above, the electronic signature is obtained by encrypting the hash value or timestamp token of the component data using the secret key of the client server 2 as the sending source. The signature verification unit 2122 compares the decrypted value with the Obj-HV (hash value or timestamp token) contained in the transaction data. By confirming that the two are consistent, the signature verification unit 2122 determines the validity of the electronic signature.

[0121] When the validity of the electronic signature is confirmed, 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.

[0122] The ledger update unit 2124 appends the record created by the record creation unit 2123 to the distributed ledger set 50, and updates the distributed ledger set 50. Specifically, the ledger update unit 2124 refers to the key of the created record and determines the distributed ledger to which the record is to be appended. For example, the transaction data generated according to the first operation of updating the component data of the first component has "k1" representing the ID of the first component as a key. The record created based on the transaction data also has "k1" as a key. Therefore, the ledger update unit 2124 appends the record to the evidence chain of the component data of the first component, that is, the distributed ledger 51.

[0123] In addition, the transaction data A generated according to the second operation has "k1" representing the ID of the first component as a key. The record made based on the transaction data A also has "k1" as a key. Therefore, the ledger update unit 2124 appends the record to the evidence chain of the component data of the first component, that is, the distributed ledger 51. In addition, the transaction data B generated according to the second operation has "k2" representing the ID of the second component as a key. The record made based on the transaction data B also has "k2" as a key. Therefore, the ledger update unit 2124 appends the record to the evidence chain of the component data of the second component, that is, the distributed ledger 52. In addition, the transaction data C generated according to the second operation has "k2" representing the ID of the second component as a key in the above example. The record made based on the transaction data C also has "k2" as a key. Therefore, the ledger update unit 2124 appends the record to the evidence chain of the component data of the second component, that is, the distributed ledger 52. As a result, the record containing the timestamp token is stored in the distributed ledger 52.

[0124] When the update of the distributed ledger set 50 is completed, the ledger update unit 2124 outputs a notification to that effect to the output unit 2125 .

[0125] The output unit 2125 outputs a control signal for notifying the client server 2, which is the source of the transaction data, that the process of executing the transaction data (transaction processing) is completed to the communication device 24. Thus, a report on the completion of the transaction processing is sent to the client server 2, which is the source of the transaction data, via the communication device 24.

[0126] <Flowchart>

[0127] Figure 8 This is a flowchart showing the procedure of a process for generating transaction data when the first request is received. Figure 8 The processing of the flowchart shown in FIG. 1 is executed by the control device 21 when the first request is received from the input device 25 or the user terminal device 7. Figure 8 and the following Fig. 9 ,10 Each step of the flowchart shown (hereinafter abbreviated as "S") is described as being implemented by software processing performed by the control device 21, but part or all of it can also be implemented by hardware (electronic circuit) manufactured in the control device 21.

[0128] In S1, the control device 21 generates a random value. The random value is used as a number for transaction data.

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

[0130] In S3, the control device 21 reads the secret key 271 from the storage device 27, and uses the secret key 271 to encrypt the hash value generated in S2 to create an electronic signature. In addition, the control device 21 can also use the secret key 271 to encrypt the random value generated in S1 to create an electronic signature. In addition, the control device 21 can also use the secret key 271 to encrypt the hash value generated in S2 and the random value generated in S1 to create an electronic signature.

[0131] In S4, the control device 21 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV and HV. Specifically, the control device 21 sets the ID of the object component included in the first request as Key. In addition, the control device 21 sets the random value generated in S1 as Nonce, the hash value generated in S2 as Obj-HV, and the electronic signature produced in S3 as Sig. In addition, the control device 21 verifies the Age of the parent record by checking the Key in the distributed ledger set 50, and sets the Age after increasing the Age of the parent record as Age. In addition, the control device 21 sets the record hash (HV) of the parent record as Prev-HV. In addition, the control device 21 hashes the information of Key, Age, Obj-HV, Nonce, Sig and Prev-HV except the information of HV, and sets it as HV. Furthermore, the control device 21 may include, in the transaction data, information on the time when the transaction data is broadcast to the network NW and information on the sender of the transaction data.

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

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

[0134] In S11, the control device 21 executes a process of sending transaction data for adding records corresponding to updates of the component data of the first component and the component data of the second component to the distributed ledgers 51 and 52, respectively. Figure 8 The control device 21 performs the same processing as described in the above, and outputs a control signal to the communication device 24, which is used to generate transaction data A that adds a record of the update of the component data of the first component to the distributed ledger 51 and sends the transaction data A to the network NW. In addition, the control device 21 performs the same processing as in Figure 8 The same processing as that described in the above is performed, and a control signal is output to the communication device 24, which is used to generate transaction data B that adds a record of the update of the component data of the second component to the distributed ledger 52 and sends the transaction data B to the network NW.

[0135] In S12, the control device 21 generates a random number. This random number is used as a number of transaction data generated in S16 described later.

[0136] In S13, the control device 21 creates a terminal hash value, which includes the record hash value of the terminal record of the distributed ledger 51 (i.e., the record appended to the distributed ledger 51 by executing 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 appended to the distributed ledger 52 by executing the transaction data B sent in S11).

[0137] In S14, the control device 21 outputs a control signal for transmitting the terminal hash value generated in S13 to the time authentication mechanism 8 to the communication device 24. As a result, the terminal hash value is transmitted to the time authentication mechanism 8 via the communication device 24. The time authentication mechanism 8 that receives the terminal hash value returns the time stamp token to the client server 2 that is the transmission source of the terminal hash value. The control device 21 obtains the time stamp token from the time authentication mechanism 8 via the communication device 24.

[0138] In S15, the control device 21 reads the secret key 271 from the storage device 27, and uses the secret key 271 to encrypt the time stamp token obtained in S14 to create an electronic signature. In addition, the control device 21 can also use the secret key 271 to encrypt the random value generated in S12 to create an electronic signature. In addition, the control device 21 can also use the secret key 271 to encrypt the time stamp token obtained in S14 and the random value generated in S12 to create an electronic signature.

[0139] In S16, the control device 21 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The control device 21 sets the ID (k2 in the above example) input to the "object input field" as Key. In addition, the control device 21 sets the timestamp token obtained in S14 as Obj-HV. The other processing in S16 is the same as Figure 8 The processing of S4 is basically the same, so it will not be repeated.

[0140] 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. Thus, the transaction data is transmitted to the network NW via the communication device 24.

[0141] Fig.10 is a flowchart showing the order of processing performed when transaction data is received. Fig.10 The processing of the flowchart shown is executed by the control device 21 when transaction data is received.

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

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

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

[0145] In S24, the control device 21 verifies the validity of the electronic signature decrypted in S23. Specifically, the control device 21 compares the value obtained by decrypting the electronic signature with the Obj-HV (hash value or timestamp token) contained in the transaction data. If the two are inconsistent, the control device 21 does not recognize the validity of the electronic signature ("No" in S24), and the processing proceeds to S25. If the two are consistent, the control device 21 recognizes the validity of the electronic signature ("Yes" in S24), and the processing proceeds to S26.

[0146] In S25, the control device 21 discards the transaction data received this time because the electronic signature is not valid, and ends the processing. In addition, the control device 21 may also cause the display device 26 to display the meaning that there is a possibility that the transaction data has been tampered with. In addition, the control device 21 may also send the meaning that there is a possibility that the transaction data has been tampered with to the client server 2 that is the transmission source of the transaction data.

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

[0148] In S27, the control device 21 determines the distributed ledger to which the record is to be added based on the key of the record created in S26. Then, the control device 21 adds the record to the determined distributed ledger. Thus, the distributed ledger set 50 is updated.

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

[0150] As described above, in the data management system 1 of implementation mode 1, the client server 2 maintains a distributed ledger set 50 including two distributed ledgers 51 and 52. The distributed ledger 51 is a chain of evidence for proving the existence of the component data of the first component, and the distributed ledger 52 is a chain of evidence for proving the existence of the component data of the second component. If a second operation is performed to simultaneously update the component data of the first component and the component data of the second component, the client server 2 appends a record containing a hash value of the updated component data of the first component to the distributed ledger 51, and appends a record containing a hash value of the updated component data of the second component to the distributed ledger 52. Then, the client server 2 generates a terminal hash value including a record hash value of the record appended to the distributed ledger 51 and a record hash value of the record appended to the distributed ledger 52. Then, the client server 2 obtains a timestamp token for the terminal hash value. By obtaining a timestamp token for the terminal hash value, for example, Figure 3 As in the example, it can be proved that the component data D10 to D13 of the first component already existed and the component data D20 to D22 of the second component already existed at the time proved by the timestamp token. In addition, it can be proved that the component data D14 and the component data D23 were registered after the time point of obtaining the timestamp token. That is, after the component data D10 to D13 and the component data D20 to D22 are saved, it can be proved that the component data D14 and the component data D23 exist. According to the data management system 1 of embodiment 1, compared with the case where a timestamp token is obtained for the record hash value of the record each time a record is appended to the distributed ledgers 51 and 52, the man-hours, costs, system load, etc. can be reduced.

[0151] In addition, by incorporating the time stamp token into the record of at least one distributed ledger included in the distributed ledger set 50, the tamper resistance of the time stamp token can be improved.

[0152] [Modification 1]

[0153] In Implementation 1, proof of existence processing, i.e., processing for generating a terminal hash value and obtaining a timestamp token, is performed when a second operation of simultaneously updating the component data of the first component and the component data of the second component is performed. That is, in Implementation 1, proof of existence processing is performed due to a user operation. However, proof of existence processing may also be performed automatically. For example, proof of existence processing may also be performed when a predetermined time has passed since the last time a timestamp token was obtained. That is, proof of existence processing may also be performed at predetermined intervals. Then, the obtained timestamp token may also be stored in a record of at least one distributed ledger of the distributed ledger set 50. Even the structure of Modification 1 can achieve the same effect as Implementation 1.

[0154] [Implementation Method 2]

[0155] In the data management system 1 of the first embodiment, an example is described in which the time stamp token obtained for the terminal hash value is stored in the distributed ledger set 50 (at least one of the distributed ledgers 51 and 52). As a result, the tamper resistance of the time stamp token is improved. In the second embodiment, an example of improving the tamper resistance of the time stamp token by other methods is described.

[0156] Fig.11 1 is a diagram showing a schematic configuration of a data management system 1A according to Embodiment 2. The data management system 1A is different from the data management system 1 according to Embodiment 1 in that the client server 2 is changed to a client server 2A and further includes an external server 9. The other configurations of the data management system 1A are the same as those of the data management system 1 according to Embodiment 1, and therefore, the description thereof will not be repeated.

[0157] The client server 2A is different from the client server 2 of the first embodiment in that the control device 21 is changed to a control device 21A, the communication device 24 is changed to a communication device 24A, and the distributed ledger set 50 included in the storage device 27 is changed to a distributed ledger set 55. The other structures of the client server 2A are the same as those of the client server 2 of the first embodiment, and therefore, the description thereof will not be repeated.

[0158] Fig.12 1 is a diagram showing an example of the structure of the distributed ledger set 55 according to the second embodiment. Fig.12, the distributed ledger set 55 includes a distributed ledger 56 that stores the update status of the component data of the first component in time series and serves as a chain of evidence for the component data of the first component, and a distributed ledger 57 that stores the update status of the component data of the second component in time series and serves as a chain of evidence for the component data of the second component. Distributed ledgers 56 and 57 store records containing information including "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV" in time series, similarly to the distributed ledgers 51 and 52 of the first embodiment.

[0159] Reference Fig.11 and Fig.12 , the timing of executing the proof of existence processing (processing of generating a terminal hash value and obtaining a timestamp token) by client server 2A is different from that of client server 2. Client server 2 of implementation mode 1 executes the proof of existence processing in response to the second request indicating that the second operation of simultaneously updating the component data of the first component and the component data of the second component has been performed. Client server 2A of implementation mode 2 executes the proof of existence processing in response to the third request indicating that the third operation of requesting to obtain a timestamp token has been performed.

[0160] The client server 2A (control device 21A) executes the process described in the first embodiment for the first request and the second request. Figure 8 , and appends the record to the distributed ledger 56 or / and the distributed ledger 57. More specifically, if the control device 21A updates the database 4 in response to the first operation of updating the component data of the first component, for example, the record containing the hash value of the component data of the first component updated is added to the distributed ledger 56. In addition, if the control device 21A updates the database 4 in response to the first operation of updating the component data of the second component, for example, the record containing the hash value of the component data of the second component updated is added to the distributed ledger 57. Further, if the control device 21A updates the database 4 in response to the second operation of simultaneously updating the component data of the first component and the second component, for example, the record containing the hash value of the component data of the first component updated is added to the distributed ledger 56, and the record containing the hash value of the component data of the second component updated is added to the distributed ledger 57. The client server 2A of the second embodiment does not generate a terminal hash value and obtain a timestamp token in response to the second request. Regarding the processing of the first request and the second request in the second embodiment, as in the first embodiment Figure 5 , 8 As described in the above, the details will not be repeated. In addition, the processing when receiving transaction data from other client servers 2A in the second embodiment is also the same as in the first embodiment. Figure 7 ,10 As has been explained in, the details will not be repeated.

[0161] Fig.13 This is a diagram for explaining the existence proof processing in Implementation 2. Fig.13 The upper part of the diagram schematically shows the evidence chain of the first component, i.e., the distributed ledger 56. Figure 3 In the lower part, the evidence chain of the second component, namely the distributed ledger 57, is schematically shown.

[0162] In the first evidence chain (distributed ledger 56), records containing hash values ​​of component data of the first component are stored in time series. In the second evidence chain (distributed ledger 57), records containing hash values ​​of component data of the second component are stored in time series. Fig.13 As shown, it is assumed that in the distributed ledger 56, the record RA3 of Age "3" is the latest (end) record, and in the distributed ledger 52, the record RB2 of Age "2" is the latest (end) record. Then, it is assumed that in this state, the third operation of requesting to obtain the timestamp token is performed on the input device 25 or the user terminal device 7.

[0163] If 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 displayed on the display screen of the display device 26 or the user terminal device 7 requesting to obtain a timestamp token. If the control device 21A receives the third request, it generates a terminal hash value including a record hash value of the record RA3 at the end of the distributed ledger 56 and a record hash value of the record RB2 at the end of the distributed ledger 57. Then, the control device 21A sends the terminal hash value to the time authentication agency 8 via the communication device 24A. The time authentication agency 8 sends the timestamp token obtained by combining the time information based on the time source that has traceability to the international standard time with the terminal hash value to the client server 2A. The control device 21A causes the storage device 27 to store the timestamp token as a time certificate. In the second embodiment, the timestamp token is also obtained by the end hash value of the record hash value of the record RA3 at the end of the distributed ledger 56 and the record hash value of the record RB2 at the end of the distributed ledger 57, so that it can be proved that the component data D10 to D13 of the first component already existed and the component data D20 to D22 of the second component already existed at the time proved by the timestamp token. In addition, when the record is appended to the distributed ledgers 56 and 57 after the timestamp token is obtained, it can be proved that the component data corresponding to the record is registered after the time proved by the timestamp token. Compared with the case where the timestamp token is obtained for the record hash value of the record each time the record is appended to the distributed ledgers 56 and 57, the man-hours, costs, system load, etc. can be reduced.

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

[0165] The external server 9 is a server separated from the network NW (i.e., a server not participating in the network NW), and is managed by a management subject that is not any of the companies A, B, C, and D. By having the storage device 27 store the time certificate for management, and the external server 9 also managing the time certificate, the tamper resistance of the time certificate (i.e., the time stamp token) can be improved.

[0166] Fig.14 2 is a functional block diagram of a control device 21A for executing the existence certification process in Embodiment 2. Fig.14The 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 by, for example, executing a program stored in the ROM 22. In addition, 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).

[0167] When the third operation is performed on the input device 25 or the user terminal 7, the input device 25 or the user terminal 7 outputs a third request indicating that the third operation has been performed.

[0168] The information acquisition unit 2131 acquires the third request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2A operates the input device 25 and selects a button for requesting acquisition of a timestamp token on the display screen of the display device 26 (if the third operation is performed), the third request is input to the information acquisition unit 2131. If the information acquisition unit 2131 acquires the third request, it outputs the third request to the terminal hash generation unit 2132.

[0169] When receiving the third request, the terminal hash generation unit 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 a terminal hash value including them. The terminal hash generation unit 2132 outputs the generated terminal hash value to the time stamp token acquisition unit 2133.

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

[0171] The time authentication authority 8 which receives the terminal hash value sends the time stamp token back to the client server 2 .

[0172] The time stamp token acquisition unit 2133 receives the time stamp token from the time authentication 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.

[0173] The output unit 2134 causes the storage device 27 to store the time stamp token received from the time stamp token acquisition unit 2133. Alternatively, the output unit 2134 may cause the database 4 to store the time stamp token received from the time stamp token acquisition unit 2133. In this way, proof of the existence time of the component data of the first component and the component data of the second component can be obtained.

[0174] Furthermore, the output unit 2134 sends the time stamp token received from the time stamp token acquisition unit 2133 as a time certificate to the external server 9. Specifically, the output unit 2134 outputs a control signal for sending the time certificate to the external server 9 to the communication device 24A. Thus, the time certificate is sent 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 stamp token, in addition to tampering with the time stamp token managed by the client server 2A, it is necessary to tamper with the time certificate (time stamp token) managed by the external server 9. By also managing the time certificate by the external server 9, the tamper resistance of the time stamp token can be improved.

[0175] Fig.15 This is a flowchart showing the procedure of the process of obtaining a time stamp token. Fig.15 The process of the flowchart shown is executed by the control device 21A when the third request is received from the input device 25 or the user terminal device 7 .

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

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

[0178] In S33, the control device 21A generates an end hash value including the record hash values ​​generated in S31 and S32.

[0179] In S34, the control device 21A obtains the time stamp token for the terminal hash value generated in S33. Specifically, the control device 21A outputs a control signal for sending the terminal hash value to the time authentication mechanism 8 to the communication device 24A. As a result, the record hash value is sent to the time authentication mechanism 8 via the communication device 24A. Then, the control device 21A obtains the time stamp token for the terminal hash value from the time authentication mechanism 8 via the communication device 24A.

[0180] In S35, the control device 21A causes the storage device 27 to store the time stamp token acquired in S34. In addition, the control device 21A may cause the database 4 to store the time stamp token.

[0181] In S36, the control device 21A transmits the time stamp token obtained 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. Thus, the time certificate is transmitted to the external server 9 via the communication device 24A.

[0182] As described above, in the data management system 1A of the second embodiment, the client server 2A, in response to the third operation, obtains a time stamp token for the end hash value of the record hash value of the latest (end) record of the two distributed ledgers 56 and 57. Then, the client server 2A causes the storage device 27 to store the time stamp token, and transmits the time stamp token (time certificate) to the external server 9. By also managing the time stamp token by the external server 9, the tamper resistance of the time stamp token can be improved.

[0183] [Implementation method 3]

[0184] In Embodiment 1, an example is described in which the platform server 5 has a function of permitting participation in the network NW. Then, the certainty of transaction data is provided by confirming the validity of the electronic signature between the client server 2 that has been permitted to participate in the network NW. In Embodiment 3, an example is described in which the platform server 6 has a function of providing certainty for transaction data in addition to the function of permitting participation in the network NW.

[0185] Fig.16 1 is a diagram showing a schematic structure of a data management system 1B according to Embodiment 3. The data management system 1B has the same functions as the data management system 1 according to Embodiment 1. The data management system 1B includes four client servers 3, a platform server 6, and a time authentication mechanism 8. As in Embodiment 1, the four client servers 3 are servers belonging to different companies (for example, Company A, Company B, Company C, and Company D). The client server 3 of Company A is described below as a representative example, but the client servers 3 of Company B, Company C, and Company D also have the same functions.

[0186] The platform server 6 manages the network NW similarly to the platform server 5 in the first and second embodiments, 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 of permitting participation performed by the administrator of the platform server 6 or based on a determination result of a predetermined condition. In the third embodiment, four client servers 3 belonging to the A company, the B company, the C company, and the D company may participate in the network NW.

[0187] The four client servers 3 and the platform server 6 form a network NW. By importing the distributed ledger-based software into each client server 3, the imported distributed ledger-based software functions, so that each client server 3 functions as a node. The client server 3 is configured to be able to communicate with the user terminal device 7 in the same manner as the client server 2 of the first embodiment.

[0188] In addition, similarly to the client server 2 of Embodiment 1, the database 4 is connected to the client server 3. The client server 3 (control device 31) generates a control signal for storing / updating component data and outputs it to the database 4 based on input to the input device 35 or a request from the user terminal device 7.

[0189] When the client server 3 stores / updates the component data in the database 4, a hash value of the component data is created, and transaction data for storing the hash value in the ledger held by the platform server 6 and the distributed ledger held by each client server 3 is generated. Then, the client server 3 sends the generated transaction data to the platform server 6.

[0190] The platform server 6 has the function of providing certainty to transaction data. The platform server 6 maintains a ledger set 60, processes the transaction data received from the client server 3, and updates the ledger set 60. If the platform server 6 updates the ledger set 60, it sends the records added to the ledger by the update (the verification records described later) to all client servers 3 participating in the network NW. The client server 3 stores a submission table 374 for storing submission records, and stores the verification records received from the platform server 6 as submission records in the submission table 374. The submission table 374 is equivalent to an example of the "distributed ledger" of the present disclosure.

[0191] Fig.17 : is a diagram showing an example of the structure of a ledger set 60. The ledger set 60 includes a ledger 67 and a ledger 68. The ledger 67, like the distributed ledger 51 of Implementation Example 1, stores the update status of the component data of the first component in a time series to form a chain of evidence for the component data of the first component. The ledger 68, like the distributed ledger 52 of Implementation Example 1, stores the update status of the component data of the second component in a time series to form a chain of evidence for the component data of the second component. The ledger set 60, ledger 67, and ledger 68 have the same structures as the distributed ledger set 50, distributed ledger 51, and distributed ledger 52 of Implementation Example 1, respectively. Therefore, their detailed description will not be repeated. In addition, in Fig.17 In the figure, it is shown that Figure 3 The example shown corresponds to the data structure of the ledgers 67 and 68. That is, in the ledgers 67 and 68, a record of Age "3" is stored as the latest (last) record.

[0192] Refer again Fig.16 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 the same as the ROM 22, the RAM 23, the communication device 24, the input device 25, and the display device 26 of the client server 2 in the first embodiment, and therefore, their description will not be repeated.

[0193] The storage device 37 stores a secret key 371 and verification data 372. The secret key 371 is the secret key of Company A. For example, when the client server 3 first joins the network NW, the control device 31 generates a secret key and a public key. Then, the control device 31 sends the generated public key to the certification authority (not shown) and receives certification. The certification authority issues an electronic certificate containing information about the public key. The control device 31 causes the storage device 37 to store the secret key 371 corresponding to the authenticated public key. In addition, the control device 31 sends the authenticated public key (electronic certificate) 651 to the platform server 6.

[0194] Verification data 372 includes a suspension form 373 and a submission form 374 . Fig.18 This is a diagram for explaining an example of the structure of the pause table 373 . Fig.19 374 is a diagram for explaining an example of the structure of the submission table 374. The suspension table 373 and the submission table 374 have a record for each target component.

[0195] Reference Fig.18, the pause table 373 includes information of a predetermined type included in the unused transaction data. Specifically, the pause table 373 stores a pause record including information such as a Key and a Nonce. The control device 31 stores the information of the Key and the Nonce in the information included in the transaction data generated in response to the first request or the second request as a pause record in the pause 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 the ID of the object component. For example, if the object of the first request is the first component, the first request includes an ID indicating "k1", and if the object of the first request is the second component, the first request includes an ID indicating "k2". In the second request, an ID indicating "k1" and an ID indicating "k2" are included. That is, the ID of the object component included in the first request or the second request becomes a Key. In addition, if the first request or the second request is received, the control device 31 generates a random value. The random value indicates the number of the processing 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 the information of the Key and Nonce, and registers the suspension record in the suspension table 373. Fig.18 , an example is shown in which a suspension record including a key of k1 is registered in the suspension table 373. In addition, below, when the first request and the second request are not particularly distinguished, both are collectively referred to as an "update request".

[0196] If processing in response to an update request is executed (ie, if transaction data is used), the control device 31 deletes, from the suspension table 373 , the suspension record containing information of the same key as the key contained in the transaction data used to execute the transaction processing.

[0197] In the pause table 373, a pause record containing information of the same key is not repeatedly registered. When registering a pause record in the pause table 373, the control device 31 determines whether a pause record containing a key that is consistent with the key contained in the pause record that is the registration object has been registered in the pause table 373. If a pause record containing a key that is consistent with the key contained in the pause record that is the registration object is not registered in the pause table 373, the control device 31 registers the pause record in the pause table 373. If a pause record containing a key that is consistent with the key contained in the pause record that is the registration object is registered in the pause table 373, the control device 31 waits for the pause record containing the consistent key to be deleted from the pause table 373. That is, in Fig.18 In the example shown, in the suspension table 373 , a suspension record including a key of k2 can be registered, but a suspension record including a key of k1 cannot be registered.

[0198] The commit table 374 includes information of a predetermined type included in the used transaction data. Specifically, the commit table 374 stores a commit record including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. In Embodiment 3, the commit record has the same information as the record of the ledger set 60. The commit table 374 includes commit data 375 storing a commit record having a key of k1 and commit data 376 storing a commit record having a key of k2.

[0199] When the platform server 6 executes a transaction and updates the ledger of the ledger set 60, a verification record is created and sent to all client servers 3 participating in the network NW. The verification record is, for example, a record including information such as Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV of a record added to the ledger by a transaction executed using transaction data.

[0200] If the verification record is received, the control device 31 adds the verification record as a commit record to the commit table 374 (commit data 375 or commit data 376). Then, the control device 31 deletes the suspension record including the same key as the key included in the added commit record from the suspension table 373.

[0201] Refer again Fig.16 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 .

[0202] The control device 61 is composed of an integrated circuit including a CPU. The control device 61 expands various programs stored in the ROM 62 in the RAM 63 for execution. The various programs include an operating system, etc. The RAM 63 functions as a working memory and temporarily stores various data required for executing various programs. The control device 61 receives transaction data from the client server 3 and executes transaction processing.

[0203] The communication device 64 is configured to be able to communicate with the client server 3 participating in the network NW.

[0204] The storage device 65 stores a plurality of public keys 651 and a ledger set 60. The plurality of public keys 651 include the public keys of the enterprise managing the client server 3 participating in the network NW. Specifically, the plurality of public keys 651 include the public keys of the A enterprise, the B enterprise, the C enterprise, and the D enterprise.

[0205] As described above, the ledger set 60 has the same structure as the distributed ledger set 50 in the first embodiment.

[0206] Next, the processing of the response to the update request (first request, second request) in the third embodiment will be described in sequence, with reference to the flowchart.

[0207] Fig. 20 This 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. Fig. 20 The process of the flowchart shown 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 .

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

[0209] In S41, the control device 31 of the client server 3 generates a pause record. Specifically, the control device 31 of the client server 3 reads the ID of the target component included in the update request and sets it as the key information, sets the random value generated in S40 as the Nonce information, and generates a pause record. In addition, when the update request is the second request, the control device 31 generates a pause record of information that sets the ID (k1) of the first component as the key and a pause record of information that sets the ID (k2) of the second component as the key.

[0210] In S42, the control device 31 of the client server 3 determines whether the suspension record generated in S41 can be registered in the suspension table 373. When a suspension record having information of the same key 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 information of the same key to be deleted from the suspension table 373. On the other hand, when a suspension record having information of the same key 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 advances the processing to S43.

[0211] In S43 , the control device 31 of the client server 3 registers the suspension record in the suspension table 373 .

[0212] In S44, the control device 31 of the client server 3 generates transaction data corresponding to the update request. Specifically, when the update request is the first request, the control device 31 of the client server 3 executes the transaction data corresponding to the update request. Figure 8 The control device 31 of the client server 3 generates transaction data by performing the same processing as that of S2 to S4 described in the previous section. If the update request is the second request, the control device 31 of the client server 3 executes the same processing as that of S2 to S4 described in the previous section. Fig. 9 The same processing as the processing of S11 described in the above is performed to generate each transaction data corresponding to the update of the first component and the second component. Further, in the case where the update request is the second request, the control device 31 of the client server 3 executes the same processing as in Fig. 9 The transaction data is generated by the same processing as S13 to S16 described in the previous section. Figure 8 and Fig. 9 As has been explained in, it will not be repeated.

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

[0214] In S50, the control device 61 of the platform server 6 decrypts the electronic signature in order to verify the validity of the electronic signature contained in the received transaction data. Fig.10 The electronic signature is decrypted by performing the same processing as that of S21 to S23 described in the previous section. Fig.10 As has been explained in, it will not be repeated.

[0215] 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 value obtained by decrypting the electronic signature with the hash value contained in the transaction data (the hash value of the component data of the object component in the transaction data generated according to the first request, and the timestamp token in the transaction data generated according to the second request). If the two are inconsistent, the control device 61 of the platform server 6 does not recognize the validity of the electronic signature ("No" in S51), and the processing proceeds to S52. If the two are consistent, the control device 61 of the platform server 6 recognizes the validity of the electronic signature ("Yes" in S51), and the processing proceeds to S53.

[0216] In S52, the control device 61 of the platform server 6 determines that the transaction data received from the client server 3 may be tampered with, discards the transaction data, and generates an abnormality report indicating the possibility of tampering. Then, the control device 61 of the platform server 6 advances the process to S56.

[0217] In S53, the control device 61 of the platform server 6 performs transaction processing. Specifically, the control device 61 of the platform server 6 performs the transaction processing with Fig.10 The same processing as the processing of S26 and S27 described above is performed, and a record of the ledger identified by the information of the key included in the transaction data is generated, and the generated record is added to the ledger, and the ledger set 60 is updated.

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

[0219] In S55, the control device 61 of the platform server 6 generates a normal report indicating that the update of the ledger set 60 is completed (ie, the transaction data is processed). The control device 61 of the platform server 6 includes the verification record in the normal report.

[0220] In S56, the control device 61 of the platform server 6 outputs a control signal for sending the abnormal report prepared in S52 or the normal report prepared in S55 to the client server 3 as the transmission source of the transaction data to the communication device 64. Thus, the abnormal report or the normal report is sent to the client server 3 via the communication device 64.

[0221] In addition, in S56, the control device 61 of the platform server 6 outputs a control signal for sending the verification record to other client servers 3 (for example, client servers 3 of Enterprise B, Enterprise C, and Enterprise D) other than the transmission source of the transaction data to the communication device 64. Thus, the verification record is sent to the other client servers 3 via the communication device 64.

[0222] In S46, the control device 31 of the client server 3 determines whether a normal report is received from the platform server 6. If it is determined that a normal report is received ("Yes" in S46), the control device 31 of the client server 3 advances the process to S47. On the other hand, if it is determined that a normal report is not received, that is, an abnormal report is received ("No" in S46), the control device 31 of the client server 3 advances the process to S49.

[0223] In S47, the control device 31 of the client server 3 adds the verification record included in the normal report as a submission record to the submission table 374. Specifically, the control device 31 of the client server 3 determines whether the object of the submission record to be added is the submission data 375 or the submission data 376 based on the information of the key of the verification record. Then, the control device 31 of the client server 3 adds the submission record to the submission data as the object.

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

[0225] In S49 , the control device 31 of the client server 3 causes the display device 36 to display the result of the processing for the update request, for example, or transmits it to the user terminal device 7 .

[0226] Furthermore, the other client servers 3 (client servers 3 of Company B, Company C, and Company D) that have received the verification record transmitted in S56 also update the submission form 374 by adding the verification record to the submission form 374 in the same manner.

[0227] As described above, in the data management system 1B of implementation mode 3, the platform server 6 provides certainty for transaction data. The platform server 6 maintains a ledger set 60 including two ledgers 67 and 68. In the ledger 67, the update status of the component data of the first component is stored in time series, and in the ledger 68, the update status of the component data of the second component is stored in time series. Then, if the ledger set 60 is updated, a verification record having information of the record appended to the ledger set 60 is transmitted from the platform server 6 to each client server 3. The client servers 3 each append the verification record as a submission record to the submission form 374. The submission form 374 is equivalent to the distributed ledger set 50 of implementation mode 1. In the structure of the data management system 1B of implementation mode 3, in response to the second request, the record hash values ​​of the latest (end) records of the two submission data 375 and 376 are respectively generated, and the end hash value containing them is generated. Then, a timestamp token is obtained for the end hash value. By obtaining a timestamp token for the end hash value, for example, as in implementation mode 1 Figure 3 As in the example, it is possible to prove that the component data of the first component at the time certified by the timestamp token (for example, at Figure 3 In the example of D10 to D13) already exists and the component data of the second component (for example, in Figure 3 In the example, D20 to D22) already exist.

[0228] Furthermore, by incorporating the time stamp token into the record of at least one ledger included in the ledger set 60, the time stamp token is incorporated into at least one submission data included in the submission form 374. This can improve the tamper resistance of the time stamp token.

[0229] [Modification 2]

[0230] In Embodiment 3, an example is described in which the submission form 374 has the same information as the information contained in the ledger set 60. Specifically, the submission data 375 and 376 of the submission form 374 each have information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The submission form 374 may also have a portion of the information contained in the ledger set 60. For example, the submission data 375 and 376 of the submission form 374 may each also include the information of Key, Age, Obj-HV, HV, and Nonce in the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV of the ledgers 67 and 68 of the ledger set 60. In this case, the verification record is also generated in a manner that includes the information of Key, Age, Obj-HV, HV, and Nonce. That is, the submission data 375 and 376 become summaries of the ledgers 67 and 68. By setting the submitted data 375 and 376 as digests of the ledgers 67 and 68, the data capacity stored in the storage device 37 of the client server 3 can be reduced compared to the case where the submitted data 375 and 376 and the ledgers 67 and 68 have the same information.

[0231] [Variation 3]

[0232] In the third embodiment, the structure of the second embodiment can also be combined. That is, in the third embodiment, the existence certification process can also be executed in response to the third request. In such a structure, the same effect as that of the second embodiment can also be achieved.

[0233] The embodiments disclosed herein are illustrative in all aspects and are not restrictive. The technical scope of the present disclosure is not indicated by the description of the embodiments above but by the claims, and is intended to include all changes within the meaning and scope equivalent to the claims.

Claims

1. A data management device that uses distributed ledger technology to manage data, wherein, the data management device includes: a storage device that stores a distributed ledger storing records containing information related to the data in time series; a control device that appends the records to the distributed ledger; and a communication device configured to be able to communicate with a time certification authority, the data includes first data and second data, the distributed ledger includes a first distributed ledger storing records containing first information related to the first data in time series and a second distributed ledger storing records containing second information related to the second data in time series, the control device generates an end value including information of the record at the end of the first distributed ledger and information of the record at the end of the second distributed ledger, and obtains a timestamp token for the end value from the time certification authority via the communication device.

2. The data management device according to claim 1, wherein, the control device stores a record including the timestamp token in at least one of the first distributed ledger and the second distributed ledger.

3. The data management device according to claim 1, wherein, 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 timestamp token in the storage device and sends the timestamp token to the external server via the communication device.

4. The data management device according to any one of claims 1 to 3, wherein, if the control device responds to updates of the first data and the second data and stores a record containing the first information in the first distributed ledger and stores a record containing the second information in the second distributed ledger, the control device generates the end value.

5. The data management device according to any one of claims 1 to 3, wherein, if a predetermined time has elapsed since the time when the timestamp token was last obtained, the control device generates the end value.

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

7. The data management device according to any one of claims 1 to 6, wherein, the first information is the hash value of the first data, the second information is the hash value of the second data.

8. A data management method, which is a data management method of a data management device that uses distributed ledger technology to manage data, wherein, the data management device includes: a storage device that stores a distributed ledger storing records containing information related to the data in time series; a control device that appends the records to the distributed ledger; and a communication device configured to be able to communicate with a time certification authority, the data includes first data and second data, The distributed ledger includes a first distributed ledger that stores records containing first information related to the first data in a time series, and a second distributed ledger that stores records containing second information related to the second data in a time series. The data management method includes: a step of generating an end value including information on a record at the end of the first distributed ledger and information on a record at the end of the second distributed ledger; and a step of obtaining a timestamp token for the end value from the time authentication authority via the communication device.

Images