Data management device and data management method

Abstract

When a control device (21) of a client server (2) stores a record (RA1) in a distributed ledger book (51), a timestamp token (T0) is acquired for a record hash value (RH1), and a record (RB0) including the timestamp token (T0) is stored in a distributed ledger book (52). Next, if the record (RA2) is stored in the distributed ledger (51), the control device (21) acquires a timestamp token (T1) for the record hash value (RH2) of the record (RA2). Then, the control device (21) stores, in a distributed ledger (52), a record (RB2) including the timestamp token (T1) and a record hash value of the record (RB0).

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] Conventionally, by obtaining a timestamp token for electronic data, it is possible to prove that the electronic data existed at the time when the timestamp token was recorded (proof of existence) and that the electronic data has not been tampered with after that time (proof of integrity).

[0003] Here, the time stamp token has an expiration date, so a method of proving the existence and integrity of the time stamp token beyond its expiration date is being studied.

[0004] For example, Japanese Patent Publication No. 2014-42214 discloses a data certification system that uses a time stamp technology to perform processing to extend the validity period of a long-term signature. The data certification system creates an ESR table that is obtained by summarizing original certification information (ES-A) that proves that multiple original files have not been tampered with, and performs processing to extend the validity period of the ESR table. As a result, the processing load is reduced compared to the case where the processing to extend the validity period is performed for each ES-A (see Patent Document 1).

[0005] Prior art literature

[0006] Patent Literature

[0007] Patent Document 1: Japanese Patent Application Publication No. 2014-42214 Summary of the invention

[0008] Problems to be solved by the invention

[0009] In the data certification system disclosed in Patent Document 1, although measures are taken to reduce the processing load of the system, improvement of the tamper resistance of the time stamp token is not considered.

[0010] The present disclosure is made to solve the above-mentioned problems, and an object of the present disclosure is to prove the validity of a time stamp token that has exceeded its validity period and to improve the tamper resistance of the time stamp token.

[0011] Technical solutions to solve problems

[0012] (1) A data management device according to an aspect of the present disclosure is a data management device that manages data using distributed ledger technology. The data management device includes a storage device that stores a distributed ledger, a control device that updates the distributed ledger, and a communication device that is configured to communicate with a time authentication agency that assigns a time stamp token. The distributed ledger includes a first distributed ledger that stores records containing information related to the data in time series, and a second distributed ledger that stores records containing time stamp tokens obtained from the time authentication agency in time series. The control device obtains a first time stamp token, which is a time stamp token for information related to an end record of the first distributed ledger, from the time authentication agency via the communication device, and stores the record containing the first time stamp token in the second distributed ledger.

[0013] According to the above structure, the first time stamp token obtained for the information related to the terminal record of the first distributed ledger is managed by the second distributed ledger. In order to tamper with the first time stamp token stored in the second distributed ledger, all subsequent records of the record containing the time stamp token must be tampered with, and it is difficult to tamper with the first time stamp token. In addition, even if the validity period of a first time stamp token stored in the second distributed ledger expires, it can be proved that the first time stamp token whose validity period has expired has not been tampered with by the subsequent records of the record containing the first time stamp token. Therefore, even if the validity period of the first time stamp token expires, its validity can be proved.

[0014] (2) In one embodiment, the information related to the terminal record of the first distributed ledger is a hash value of the terminal record.

[0015] According to the above structure, the time stamp token is obtained for the hash value of the end record stored in the first distributed ledger. That is, the record itself stored in the first distributed ledger is not transmitted to the time authentication authority, so when the time stamp token is obtained, the record itself can be concealed.

[0016] (3) In one embodiment, the first time stamp token is acquired based on a user operation on the data management device.

[0017] According to the above configuration, the user can obtain the first time stamp token at an arbitrary timing and store the first time stamp token in the second distributed ledger.

[0018] (4) In one embodiment, when adding a record to the first distributed ledger, the control device obtains a first timestamp token for the record.

[0019] According to the above configuration, each time a record is added to the first distributed ledger, the first time stamp token can be automatically acquired and stored in the second distributed ledger.

[0020] (5) In one embodiment, the control device obtains a second time stamp token, which is a time stamp token for information related to an end record of the second distributed ledger, from the time authentication authority via the communication device, and stores the record including the second time stamp token in the second distributed ledger.

[0021] According to the above structure, by obtaining the second timestamp token for the information related to the terminal record of the second distributed ledger, it is possible to prove the existence and integrity of the information related to the terminal record. If the existence and integrity of the information related to the terminal record can be proved, it can be proved that the record (i.e., the timestamp token) stored in the second distributed ledger before the terminal record has not been tampered with.

[0022] (6) In one embodiment, the control device obtains the second time stamp token based on a user operation on the data management device.

[0023] According to the above configuration, the user can obtain the second time stamp token at an arbitrary timing and store the second time stamp token in the second distributed ledger.

[0024] (7) In one embodiment, the control device acquires the second time stamp token when a predetermined time has passed since the last acquisition time of the second time stamp token.

[0025] According to the above configuration, every time a predetermined time has passed, the second time stamp token can be automatically acquired and stored in the second distributed ledger.

[0026] (8) 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 transmits information related to the terminal record of the second distributed ledger at a predetermined time point to the external server via the communication device.

[0027] According to the above structure, the information related to the terminal record of the second distributed ledger is separated from the data management device and is also managed in the external server. In order to tamper with the timestamp token (the first timestamp token and / or the second timestamp token) managed by the second distributed ledger, both the timestamp token managed by the data management device and the information related to the terminal record managed by the external server must be tampered with. In this way, the tamper resistance of the timestamp token can be improved.

[0028] (9) In one embodiment, the information related to the terminal record of the second distributed ledger is a hash value of the terminal record.

[0029] According to the above structure, the time stamp token is obtained for the hash value of the end record stored in the second distributed ledger. That is, the record itself stored in the second distributed ledger is not transmitted to the time authentication agency, so when the time stamp token is obtained, the record itself can be concealed.

[0030] (10) Another aspect of the data management method disclosed herein is a data management method using a data management device that manages data using a distributed ledger technology. The data management device includes a storage device that stores a distributed ledger, a control device that updates the distributed ledger, and a communication device that is configured to communicate with a time authentication agency that assigns a time stamp token. The distributed ledger includes a first distributed ledger that stores records containing information related to data in a time series, and a second distributed ledger that stores records containing time stamp tokens obtained from a time authentication agency in a time series. The data management method includes the steps of obtaining a first time stamp token, which is a time stamp token for information related to an end record of the first distributed ledger, from the time authentication agency via a communication device, and storing the record containing the first time stamp token in a second distributed ledger.

[0031] (11) In one embodiment, the method further includes the step of obtaining a second time stamp token, which is a time stamp token for information related to an end record of a second distributed ledger, from a time authentication authority via a communication device, and the step of storing the record including the second time stamp token in the second distributed ledger.

[0032] Effects of the Invention

[0033] According to the present disclosure, the validity of a time stamp token that has exceeded its validity period can be proved, and the tamper resistance of the time stamp token can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0035] Figure 2 This is a diagram showing an example of the structure of a distributed ledger set.

[0036] Figure 3 is a diagram for illustrating updates to a set of distributed ledgers.

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

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

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

[0040] Figure 7 This is a functional block diagram of a control device for executing a process in response to a fourth operation.

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

[0042] Fig. 9 This is a flowchart showing the procedure of a process for generating transaction data when the first request is received.

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

[0044] Fig.11 This is a flowchart showing the procedure of processing for generating transaction data when the third request is received.

[0045] Fig.12 This is a flowchart showing the processing procedure when the fourth request is received.

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

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

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

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

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

[0051] Fig.18 is a flowchart showing the sequence of processing performed by the data management system when an update request is received.

[0052] Fig.19 This is a flowchart showing the processing procedure when the fourth request is received in the second embodiment.

[0053] (Explanation of symbols)

[0054] 1.1A: data management system; 2.3: client server; 4: database; 5.6: platform server; 7: user terminal device; 8: time authentication agency; 9: external server; 21: control device; 22: ROM; 23: RAM; 24: communication device; 25: input device; 26: display device; 27: storage device; 29: bus; 31: control device; 32: ROM; 33: RAM; 34: communication device; 35: input device; 36: display device; 37: storage device storage device; 39: bus; 50: distributed ledger set; 51, 52: 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; 372: verification data; 373: pause form; 374: submit form; 375, 376: submit data; 651: multiple public keys; 210 1: 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 hash generation unit; 2113: Random number generation unit; 2114: Timestamp token acquisition unit; 2115: Electronic signature unit; 2116: Transaction data generation unit; 2117: Transaction data transmission unit; 2121: Information acquisition unit; 2122: Record hash generation unit Generation unit; 2123: Random number generation unit; 2124: Timestamp token acquisition unit; 2125: Electronic signature unit; 2126: Transaction data generation unit; 2127: Transaction data sending unit; 2131: Information acquisition unit; 2132: Record hash generation unit; 2133: Client certificate preparation unit; 2134: Sending unit; 2141: Transaction data acquisition unit; 2142: Signature verification unit; 2143: Record preparation unit; 2144: Ledger update unit; 2145: Output unit; NW: Network. DETAILED DESCRIPTION

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

[0056] [Implementation Method 1]

[0057] <Overall structure of data management system>

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

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

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

[0061] 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 2 of Company B, Company C, and Company D also have the same structure and function. In addition, the client server 2 is equivalent to an example of the "data management device" of the present disclosure. In addition, in the data management system 1 of Implementation Example 1, an example of including four client servers in the network NW is described, but the number of client servers 2 included in the network NW is arbitrary, for example, it can be less than 4 or more than 5.

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

[0063] In addition, the database 4 is connected to the client server 2. The database 4 stores component data. The database 4 registers or updates the component data according to the control signal from the client server 2. For example, the user of the client server 2 (for example, an employee of Company A, etc.) can request to update the component data by operating the input device 25 (described later) of the client server 2, or by operating the user terminal device 7. The client server 2 (control device 21) generates a control signal for storing (registering / updating) the component data according to the input to the input device 25 or the request from the user terminal device 7, and outputs it to the database 4.

[0064] When the client server 2 stores (registers / updates) the component data in 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 time series, forming an evidence chain for proving the existence of the component data.

[0065] 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 record hash value described later in the first embodiment) to the applicant.

[0066] The external server 9 is a server managed by a management entity that is not any of Company A, Company B, Company C, and Company D. The external server 9 is configured to be able to communicate with the client server 2. The external server 9 receives a client certificate described later from the client server 2, and manages the received client certificate.

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

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

[0069] 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, time authentication agencies 8, and external servers 9. 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.

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

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

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

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

[0074] 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).

[0075] The distributed ledger set 50 includes a plurality of distributed ledgers. Figure 2 1 is a diagram showing an example of the structure of a distributed ledger set 50. In the first embodiment, an example in which a component constituting a vehicle is managed by the data management system 1 is described. Hereinafter, a component whose data is managed by a distributed ledger is also referred to as an "object component". In addition, component data of an object component is also referred to as "object data".

[0076] The distributed ledger set 50 includes two distributed ledgers 51 and 52. The distributed ledger 51 stores the update status of the object data in time series and functions as a chain of evidence of the object data (hereinafter also referred to as the "first chain of evidence"). The distributed ledger 52 stores the timestamp token in time series and functions as a chain of evidence of the timestamp token (hereinafter also referred to as the "second chain of evidence").

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

[0078] Key is information indicating the ID of the object component. The ID k1 is assigned to the object component. In addition, Key can also be said to be an ID for identifying distributed ledgers 51 and 52. Distributed ledger 51 stores records containing Key k1 in time series, and distributed ledger 52 stores records containing Key k2 in time series.

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

[0080] Obj-HV is a hash value of the object data. For example, if the object data stored in the database 4 is updated, a hash value of the updated object data is generated and set as Obj-HV. The hash value is a numerical value obtained as a result of hashing the object data using a hash function.

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

[0082] 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 object data) using the secret key 271. Alternatively, the electronic signature may also be created, for example, by encrypting Nonce (random value) using the secret key 271.

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

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

[0085] 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 (Directed Acyclic Graph) structure.

[0086] The distributed ledger 52 stores records including time stamp tokens in time series. The records include information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV" and "HV". The details of the information of "Age", "Nonce", "Sig", "Prev-HV" and "HV" are the same as those of the records of the distributed ledger 51, so they will not be described repeatedly.

[0087] Key is information indicating the ID of the time stamp token obtained from the time authentication authority 8. An ID of k2 is assigned to the time stamp token.

[0088] Obj-HV is the value of the timestamp token. In Obj-HV, as described later, the timestamp token obtained for the hash value of the record in the distributed ledger 51 or the timestamp token obtained for the hash value of the record in the distributed ledger 52 is stored.

[0089] The control device 21 of the client server 2 has a function of responding to the first to fourth operations described below.

[0090] <Operation 1>

[0091] Reference Figure 1 and Figure 2 For example, the user of the client server 2 can perform an operation on the input device 25 or the user terminal device 7 to register the object data in the database 4 or to update the object data registered in the database 4. In addition, the above-mentioned operation for registration and the operation for update are collectively referred to as "first operation" below.

[0092] If the first operation is performed, the input device 25 or the user terminal device 7 outputs a first request indicating that the first operation has been performed in response to the first operation. The client server 2 (control device 21) registers the object data in the database 4 or updates the object data stored in the database 4 in response to the first request. Then, the client server 2 (control device 21) generates transaction data for appending a record including a hash value of the registered or updated object data to the distributed ledger 51. The transaction data includes information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

[0093] 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 object data 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.

[0094] By processing the transaction data, a record including the hash value of the registered or updated target data is added to the distributed ledger 51 .

[0095] <Operation 2>

[0096] In addition, the user of the client server 2 can perform an operation on the input device 25 or the user terminal device 7 to obtain a timestamp token for the terminal record of the distributed ledger 51 (hereinafter also referred to as “second operation”).

[0097] If the second operation is performed, the input device 25 or the user terminal device 7 responds to the second operation and outputs a second request indicating that the second operation has been performed. In response to the second request, the client server 2 (control device 21) generates a record hash value of the end record of the distributed ledger 51 and obtains a timestamp token for the record hash value. Then, the client server 2 (control device 21) generates transaction data for appending the record containing the timestamp token to the distributed ledger 52. The transaction data includes information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV" and "HV". In addition, the transaction data may also include time information and sender information. By processing the transaction data, the record containing the timestamp token obtained by the record hash value of the end record of the distributed ledger 51 is appended to the distributed ledger 52.

[0098] In addition, the client server 2 (control device 21) can also be configured to automatically execute the processing in response to the second request when a new record is detected to be added to the distributed ledger 51. That is, if the client server 2 (control device 21) detects that a new record is added to the distributed ledger 51, it generates a record hash value of the record and obtains a timestamp token for the record hash value. Then, the client server 2 (control device 21) generates transaction data for adding the record including the timestamp token to the distributed ledger 52.

[0099] <Operation 3>

[0100] Furthermore, the user of the client server 2 can perform an operation on the input device 25 or the user terminal device 7 to obtain a timestamp token for the terminal record of the distributed ledger 52 (hereinafter also referred to as “the third operation”).

[0101] If the third operation is performed, the input device 25 or the user terminal device 7 responds to the third operation and outputs a third request indicating that the third operation has been performed. In response to the third request, the client server 2 (control device 21) generates a record hash value of the end record of the distributed ledger 52 and obtains a timestamp token for the record hash value. Then, the client server 2 (control device 21) generates transaction data for appending the record containing the timestamp token to the distributed ledger 52. The transaction data includes information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV" and "HV". In addition, the transaction data may also include time information and sender information.

[0102] <Operation 4>

[0103] Furthermore, the user of the client server 2 can perform an operation for generating a client certificate (hereinafter also referred to as "the fourth operation") on the input device 25 or the user terminal device 7. The client certificate is data including a record hash value of the terminal record of the distributed ledger 52 at the time when the fourth operation is performed.

[0104] If the fourth operation is performed, the input device 25 or the user terminal device 7 responds to the fourth operation and outputs a fourth request indicating that the fourth operation has been performed. In response to the fourth request, the client server 2 (control device 21) generates a record hash value of the terminal record of the distributed ledger 52 and creates a client certificate including the record hash value. Then, the client server 2 (control device 21) sends the client certificate to the external server 9 via the communication device 24.

[0105] <Updates to the Distributed Ledger Collection>

[0106] Figure 3 is a diagram for explaining the update of the distributed ledger set 50. Figure 3 The first evidence chain, i.e., the distributed ledger 51, is schematically shown in the upper part of Figure 3 The lower part of the diagram schematically shows the second evidence chain, i.e., the distributed ledger 52.

[0107] In the first evidence chain (distributed ledger 51), hash values ​​of component data (object data) of an object component are stored in time series. If the object data D0 is first registered to the database 4 by an operation for registering the object data (first operation), a record RA0 of Age "0" containing the hash value of the object data D0 is stored in the distributed ledger 51. Next, the object data is updated by an operation for updating the object data (first operation). If the updated object data D1 is registered to the database 4, a record RA1 of Age "1" containing the hash value of the updated object data D1 and Age "0", i.e., the record hash value of the parent record RA0, is stored in the distributed ledger 51. Furthermore, the object data is updated by an operation for updating the object data (first operation). If the updated object data D2 is registered to the database 4, a record RA2 of Age "2" containing the hash value of the updated object data D2 and Age "1", i.e., the record hash value of the parent record RA1, is stored in the distributed ledger 51. Likewise, each time the object data is updated to D3 or D4 , records RA3 or RA4 including the hash values ​​of the object data D3 or D4 are stored in the distributed ledger 51 .

[0108] In the second chain of evidence (distributed ledger 52), timestamp tokens are stored in time series. Imagine the following scenario: the distributed ledger 51 is updated for the first time, and record RA1 is appended to the distributed ledger 51. Record RA1 is the end record of the distributed ledger 51. If the second operation is performed in this scenario, a record hash value RH1 of record RA1 is generated. Then, the timestamp token T0 for the record hash value RH1 is obtained, and the record RB0 containing Age "0" of the timestamp token T0 is stored in the distributed ledger 52. Next, imagine the following scenario: the distributed ledger 51 is updated, and record RA2 is appended to the distributed ledger 51. If the second operation is performed in this scenario, a record hash value RH2 of record RA2 is generated. Then, the timestamp token T1 for the record hash value RH2 is obtained, and the record RB1 containing Age "0" or Age "1" of the record hash value of the parent record RB0 is stored in the distributed ledger 52. Furthermore, as described above, when a record is added to the distributed ledger 51, a timestamp token for the record hash value of the record may be automatically obtained.

[0109] In addition, the user can perform the second operation at any timing. That is, in the above, an example is shown in which the second operation is performed every time a record is added to the distributed ledger 51, but the second operation may not be performed every time a record is added to the distributed ledger 51. For example, the second operation may be performed every predetermined number of times a record is added to the distributed ledger 51, or may be performed when a first predetermined time has passed since the second operation was last performed. The first predetermined time may also be set in consideration of the validity period of the timestamp token, for example.

[0110] Assume that the end record of the distributed ledger 52 is the record RB1. In this case, if the third operation (operation for obtaining the timestamp token for the end record of the distributed ledger 52) is performed on the input device 25 or the user terminal device 7, a record hash value RH3 of the end record RB1 of the distributed ledger 52 is generated. Then, the timestamp token T2 for the record hash value RH3 is obtained, and the record RB2 of Age "2" containing the timestamp token T2 and the record hash value of the parent record RB1 is stored in the distributed ledger 52. The third operation can be performed at any timing of the user. In addition, regardless of the third operation, when the second predetermined time has passed since the record was last appended to the distributed ledger 52, the timestamp token is obtained for the record hash value of the end record of the distributed ledger 52. The second predetermined time can also be set, for example, in consideration of the validity period of the timestamp token. The second predetermined time can be set to the same time as the above-mentioned first predetermined time, or it can be set to a different time.

[0111] Next, it is assumed that the end record of the distributed ledger 52 is the record RB2. In this case, if the fourth operation (operation for creating a client certificate) is performed on the input device 25 or the user terminal device 7, a record hash value RH4 of the end record RB2 of the distributed ledger 52 is generated. Then, a client certificate CP including the record hash value RH4 is created. The client certificate CP is managed separately from the client server 2. For example, the client certificate CP is transmitted to the external server 9 via the communication device 24.

[0112] In addition, the fourth operation can be performed at any timing. For example, when the end record of the distributed ledger 52 is the record RB1, if the fourth operation is performed, a client certificate including the record hash value of the end record RB1 of the distributed ledger 52 is created. The client certificate can also be transmitted to the external server 9 via the communication device 24.

[0113] As described above, every time the object data is updated, a record including the hash value thereof is stored in the distributed ledger 51. By managing the hash value of the object data in the distributed ledger 51, the tamper resistance of the object data can be improved.

[0114] In addition, generally speaking, a validity period is specified for the timestamp token. In the timestamp token whose validity period has expired, it is impossible to prove the existence and integrity of the object data (hash value). Therefore, as described above, the timestamp token obtained for the end record of the distributed ledger 51 is stored in the distributed ledger 52. In the distributed ledger 52, the record hash value of the parent record is included to realize the chain of records. Therefore, in order to tamper with the timestamp token whose validity period has expired, all the timestamp tokens added to the distributed ledger 52 after the storage of the timestamp token whose validity period has expired must be tampered. By storing the timestamp token in the distributed ledger 52 in this way, the tamper resistance of the timestamp token can be improved. For example, even if the validity period of the timestamp token T0 stored in the record RB0 expires, it can be proved that the timestamp token T0 has not been tampered with through the subsequent records RB1 and RB2. In this way, the validity of the timestamp token T0 can be proved, so the validity period of the timestamp token T0 can be substantially extended. That is, through the timestamp token T0, the existence and integrity of the object data D1 can be proved.

[0115] Furthermore, at any timing, the timestamp token T2 is obtained for the record hash value RH3 of the end record RB1 of the distributed ledger 52. By obtaining the timestamp token T2 for the record hash value RH3 of the distributed ledger 52, it is possible to prove that the record RB1 existed at the time proved by the timestamp token T2 and that the record RB1 has not been tampered with after the time proved by the timestamp token T2. ​​Thus, it is possible to prove that the record RB1 existed at the time proved by the timestamp token T2 and that a series of timestamp tokens stored in the distributed ledger 52 have not been tampered with.

[0116] Furthermore, by storing the record RB2 including the timestamp token T2 obtained for the record hash value RH3 and the record hash value of the parent record RB1 in the distributed ledger 52, the tamper resistance of the timestamp token T3 can be improved.

[0117] In addition, the client certificate CP is separated from the client server 2 and managed by the external server 9. Therefore, even if all records of the distributed ledger set 50 are tampered with, the client certificate CP managed by the external server 9 can prove that the distributed ledger set 50 has been tampered with.

[0118] In addition, the first operation, the second operation, the third operation and the fourth operation may be, for example, operations in which the user selects respective request buttons (the first button, the second button, the third button and the fourth button) displayed on the display screen of the display device 26 or the user terminal device 7.

[0119] <Functional Module>

[0120] Figure 4 2 is a functional block diagram of the control device 21 for executing a process in response to the first operation. Figure 4 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).

[0121] When a first operation for registering or updating target data 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.

[0122] 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 performs the first operation on the input device 25, the first request is input to the information acquisition unit 2101. The first request includes ID (Key) information M1 for specifying the distributed ledger 51 to which the additional record is to be added. 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.

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

[0124] Upon receiving the first request, the random number generation unit 2103 generates a random value. The random value is a hash value that is cryptographically less likely to cause a collision. The random number generation unit 2103 outputs the generated random value and ID information M1 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 ID information M1 to the electronic signature unit 2104.

[0125] The electronic signature unit 2104 reads the secret key 271 from the storage device 27. The electronic signature unit 2104 creates an electronic signature by encrypting the hash value received from the hash generation unit 2102 with the secret key 271. The electronic signature unit 2104 outputs the created electronic signature and the ID information M1 to the transaction data generation unit 2105. In addition, the electronic signature unit 2104 may create 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 create an electronic signature by encrypting the hash value and the random value with the secret key 271.

[0126] 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 ID information M1 (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 created by the electronic signature unit 2104 as Sig. In addition, the transaction data generation unit 2105 sets the record hash value of the parent record as Prev-HV. The transaction data generation unit 2105 hashes the information of Key, Age, Obj-HV, Nonce, Sig and Prev-HV and sets it as HV. The transaction data may also include the time information of broadcasting the transaction data to the network NW (sending to the network NW) and the sender information of the transaction data. The transaction data generation unit 2105 outputs the generated transaction data to the transaction data sending unit 2106.

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

[0128] Figure 5 2 is a functional block diagram of the control device 21 for executing a process in response to the second operation. Figure 5The control device 21 includes an information acquisition unit 2111, a record hash generation unit 2112, a random number generation unit 2113, a time stamp token acquisition unit 2114, an electronic signature unit 2115, a transaction data generation unit 2116, and a transaction data transmission unit 2117. The control device 21 functions as the information acquisition unit 2111, the record hash generation unit 2112, the random number generation unit 2113, the time stamp token acquisition unit 2114, the electronic signature unit 2115, the transaction data generation unit 2116, and the transaction data transmission unit 2117 by, for example, executing a program stored in the ROM 22. In addition, the information acquisition unit 2111, the record hash generation unit 2112, the random number generation unit 2113, the time stamp token acquisition unit 2114, the electronic signature unit 2115, the transaction data generation unit 2116, and the transaction data transmission unit 2117 may be realized by, for example, dedicated hardware (electronic circuit).

[0129] If a second operation for acquiring a time stamp token for an end record of the distributed ledger 51 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.

[0130] 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 performs the second operation on the input device 25, the second request is input to the information acquisition unit 2111. The second request includes the ID information M2 for specifying the distributed ledger 51 to which the time stamp token is to be acquired and the ID information M3 for specifying the distributed ledger 52 to which the record is to be added. If the information acquisition unit 2111 acquires the second request, it outputs the second request to the record hash generation unit 2112 and the random number generation unit 2113.

[0131] Furthermore, the information acquisition unit 2111 may monitor the update status of the distributed ledger 51 and determine that the second request is to be acquired based on the addition of a record to the distributed ledger 51 in response to the first operation.

[0132] When receiving the second request, the record hash generation unit 2112 generates a record hash value of the latest (last) record of the distributed ledger 51 identified by the ID information M2. The record hash generation unit 2112 outputs the generated record hash value and the ID information M3 to the time stamp token acquisition unit 2114.

[0133] The random number generation unit 2113 generates a random value upon receiving the second request. The random number generation unit 2113 outputs the generated random value and the ID information M3 to the transaction data generation unit 2116. In addition, when the random value is used to create an electronic signature, the random number generation unit 2113 may also output the random value and the ID information M3 to the electronic signature unit 2115.

[0134] The time stamp token acquisition unit 2114 acquires the time stamp token for the record hash value received from the record hash generation unit 2112. Specifically, the time stamp token acquisition unit 2114 outputs a control signal for sending the record hash value to the time authentication unit 8 to the communication device 24. As a result, the record hash value is sent to the time authentication unit 8 via the communication device 24. The time authentication unit 8 that receives the record hash value returns the time stamp token to the client server 2 that is the source of the record hash value. The time stamp token acquisition unit 2114 acquires the time stamp token from the time authentication unit 8 via the communication device 24. The time stamp token acquisition unit 2114 outputs the time stamp token and the ID information M3 for identifying the distributed ledger 52 storing the time stamp token to the electronic signature unit 2115 and the transaction data generation unit 2116.

[0135] The electronic signature unit 2115 reads the secret key 271 from the storage device 27. The electronic signature unit 2115 generates an electronic signature by encrypting the time stamp token received from the time stamp token acquisition unit 2114 with the secret key 271. The electronic signature unit 2115 outputs the generated electronic signature and the ID information M3 to the transaction data generation unit 2116. In addition, the electronic signature unit 2115 may generate an electronic signature by encrypting the random value received from the random number generation unit 2113 with the secret key 271. In addition, the electronic signature unit 2115 may generate an electronic signature by encrypting the time stamp token and the random value with the secret key 271.

[0136] The transaction data generation unit 2116 generates transaction data for sending to the network NW. For example, the transaction data generation unit 2116 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2116 sets the ID information M3(k2) as Key. In addition, the transaction data generation unit 2116 sets the timestamp token as Obj-HV. Other functions of the transaction data generation unit 2116 are the same as those in Figure 4 The transaction data generation unit 2105 described in is basically the same.

[0137] The transaction data transmission unit 2117 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.

[0138] Figure 6 2 is a functional block diagram of the control device 21 for executing a process in response to the third operation. Figure 6 The control device 21 includes an information acquisition unit 2121, a record hash generation unit 2122, a random number generation unit 2123, a time stamp token acquisition unit 2124, an electronic signature unit 2125, a transaction data generation unit 2126, and a transaction data transmission unit 2127. The control device 21 functions as the information acquisition unit 2121, the record hash generation unit 2122, the random number generation unit 2123, the time stamp token acquisition unit 2124, the electronic signature unit 2125, the transaction data generation unit 2126, and the transaction data transmission unit 2127 by, for example, executing a program stored in the ROM 22. In addition, the information acquisition unit 2121, the record hash generation unit 2122, the random number generation unit 2123, the time stamp token acquisition unit 2124, the electronic signature unit 2125, the transaction data generation unit 2126, and the transaction data transmission unit 2127 may be realized by, for example, dedicated hardware (electronic circuit).

[0139] If the third operation for acquiring the time stamp token for the end record of the distributed ledger 52 is performed on the input device 25 or the user terminal device 7, the input device 25 or the user terminal device 7 outputs a third request indicating that the third operation has been performed.

[0140] The information acquisition unit 2121 acquires the third request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2 performs the third operation on the input device 25, the third request is input to the information acquisition unit 2121. The third request includes the ID information M4 for specifying the distributed ledger 52 that is the acquisition target of the time stamp token and the ID information M5 for specifying the distributed ledger 52 that stores the time stamp token. If the information acquisition unit 2121 acquires the third request, it outputs the third request to the record hash generation unit 2122 and the random number generation unit 2123.

[0141] Upon receiving the third request, the record hash generation unit 2122 generates a record hash value of the latest (last) record of the distributed ledger 52 identified by the ID information M4. The record hash generation unit 2122 outputs the generated record hash value and the ID information N5 to the time stamp token acquisition unit 2124.

[0142] The random number generation unit 2123 generates a random value upon receiving the third request. The random number generation unit 2123 outputs the generated random value and the ID information M5 to the transaction data generation unit 2126. In addition, when the random value is used to create an electronic signature, the random number generation unit 2123 may also output the random value and the ID information M5 to the electronic signature unit 2125.

[0143] The time stamp token acquisition unit 2124 acquires the time stamp token for the record hash value received from the record hash generation unit 2122. Specifically, the time stamp token acquisition unit 2124 outputs a control signal for sending the record hash value to the time authentication unit 8 to the communication device 24. As a result, the record hash value is sent to the time authentication unit 8 via the communication device 24. The time authentication unit 8 that receives the record hash value returns the time stamp token to the client server 2 that is the source of the record hash value. The time stamp token acquisition unit 2124 acquires the time stamp token from the time authentication unit 8 via the communication device 24. The time stamp token acquisition unit 2124 outputs the time stamp token and the ID information M5 for identifying the distributed ledger 52 storing the time stamp token to the electronic signature unit 2125 and the transaction data generation unit 2126.

[0144] The electronic signature unit 2125 reads the secret key 271 from the storage device 27. The electronic signature unit 2125 generates an electronic signature by encrypting the time stamp token received from the time stamp token acquisition unit 2124 with the secret key 271. The electronic signature unit 2125 outputs the generated electronic signature and the ID information M5 to the transaction data generation unit 2126. In addition, the electronic signature unit 2125 may generate an electronic signature by encrypting the random value received from the random number generation unit 2123 with the secret key 271. In addition, the electronic signature unit 2125 may generate an electronic signature by encrypting the time stamp token and the random value with the secret key 271.

[0145] The transaction data generation unit 2126 generates transaction data for sending to the network NW. For example, the transaction data generation unit 2126 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2126 sets the ID information M5(k2) as Key. In addition, the transaction data generation unit 2126 sets the timestamp token as Obj-HV. Other functions of the transaction data generation unit 2126 are the same as those in Figure 4 The transaction data generation unit 2105 described in is basically the same.

[0146] The transaction data transmission unit 2127 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.

[0147] Figure 7 2 is a functional block diagram of the control device 21 for executing a process in response to the fourth operation. Figure 7The control device 21 includes an information acquisition unit 2131, a record hash generation unit 2132, a client certificate creation unit 2133, and a sending unit 2134. The control device 21 functions as the information acquisition unit 2131, the record hash generation unit 2132, the client certificate creation unit 2133, and the sending unit 2134 by, for example, executing a program stored in the ROM 22. In addition, the information acquisition unit 2131, the record hash generation unit 2132, the client certificate creation unit 2133, and the sending unit 2134 may also be implemented by, for example, dedicated hardware (electronic circuit).

[0148] When the fourth operation for generating a client certificate is performed on the input device 25 or the user terminal 7 , the input device 25 or the user terminal 7 outputs a fourth request indicating that the fourth operation has been performed.

[0149] The information acquisition unit 2131 acquires the fourth request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2 performs the fourth operation on the input device 25, the fourth request is input to the information acquisition unit 2131. The fourth request includes the ID information M6 (k2) for specifying the distributed ledger 52 that is the target of generating the record hash value. If the information acquisition unit 2121 acquires the fourth request, it outputs the fourth request to the record hash generation unit 2132.

[0150] The record hash generation unit 2132 generates a record hash value of the latest (last) record of the distributed ledger 52 that is the target of generating the record hash value. The record hash generation unit 2132 outputs the generated record hash value to the client certificate creation unit 2133.

[0151] The client certificate generating unit 2133 generates a client certificate including the record hash value received from the record hash generating unit 2132. The client certificate may include information for identifying the client server 2 that generated the client certificate. The client certificate generating unit 2133 outputs the generated client certificate to the transmitting unit 2134.

[0152] The transmission unit 2134 outputs a control signal for transmitting the client certificate to the external server 9 to the communication device 24. As a result, the client certificate is transmitted to the external server 9 via the communication device 24.

[0153] Figure 8 2 is a functional block diagram of the control device 21 for executing received transaction data. Figure 8, the control device 21 includes a transaction data acquisition unit 2141, a signature verification unit 2142, a record creation unit 2143, a ledger update unit 2144, and an output unit 2145. The control device 21 functions as the transaction data acquisition unit 2141, the signature verification unit 2142, the record creation unit 2143, the ledger update unit 2144, and the output unit 2145, for example, by executing a program stored in the ROM 22. In addition, the transaction data acquisition unit 2141, the signature verification unit 2142, the record creation unit 2143, the ledger update unit 2144, and the output unit 2145 can also be implemented by dedicated hardware (electronic circuits), for example.

[0154] The transaction data acquisition unit 2141 acquires transaction data transmitted from another client server 2. The transaction data acquisition unit 2141 outputs the acquired transaction data to the signature verification unit 2142.

[0155] The signature verification unit 2142 verifies the validity of the electronic signature (Sig) contained in the transaction data. First, the signature verification unit 2142 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 2142 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 2142 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 object data using the secret key of the client server 2 as the sending source. The signature verification unit 2142 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 2142 determines the validity of the electronic signature.

[0156] When the validity of the electronic signature is confirmed, the record creation unit 2143 creates a record to be added to the distributed ledger set 50 based on the transaction data. The record creation unit 2143 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.

[0157] The ledger update unit 2144 adds the record created by the record creation unit 2143 to the distributed ledger set 50, and updates the distributed ledger set 50. Specifically, the ledger update unit 2144 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 registering / updating the object data mentioned above has "k1" as a key. Therefore, the ledger update unit 2144 appends the record to the distributed ledger 51 as the evidence chain of the object data. In addition, the transaction data generated according to the second operation for obtaining the timestamp token for the end record of the distributed ledger 51 and the third operation for obtaining the timestamp token for the end record of the distributed ledger 52 have "k2" as a key. Therefore, the ledger update unit 2144 appends the record to the distributed ledger 52 as the evidence chain of the timestamp token.

[0158] If the update of the distributed ledger set 50 is completed, the ledger update unit 2144 outputs the result to the output unit 2145 .

[0159] The output unit 2145 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.

[0160] <Flowchart>

[0161] Fig. 9 This is a flowchart showing the procedure of a process for generating transaction data when the first request is received. Fig. 9 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. Fig. 9 and the following Fig.10 , 11 , 12, and 13 (hereinafter abbreviated as "S"), illustrate the situation where each step of the flowchart shown in FIG. 1 is 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.

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

[0163] In S2 , the control device 21 reads the object data from the database 4 and generates a hash value of the object data.

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

[0165] 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 information M1 contained 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 made 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 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, and sets it as HV. In addition, the control device 21 may also include the time information of broadcasting the transaction data to the network NW and / or the sender information of the transaction data in the transaction data.

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

[0167] Fig.10 This is a flowchart showing the procedure of processing for generating transaction data when the second request is received. Fig.10 The process of the flowchart shown in FIG. 1 is executed by the control device 21 when the second request is received from the input device 25 or the user terminal device 7. In addition, when the control device 21 detects that a record is added to the distributed ledger 51, it can also execute Fig.10 The process of the flowchart shown.

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

[0169] In S12 , the control device 21 generates a record hash value of the end record of the distributed ledger 51 .

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

[0171] In S14, 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 S13 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 S11 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 S13 and the random value generated in S11 to create an electronic signature.

[0172] In S15, 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 information M3(k2) included in the second request as Key. In addition, the control device 21 sets the timestamp token obtained in S13 as Obj-HV. The other processing in S15 is the same as Fig. 9 The processing of S4 is basically the same, so it will not be repeated.

[0173] In S16, the control device 21 outputs a control signal for transmitting the transaction data generated in S15 to the network NW to the communication device 24. Thus, the transaction data is transmitted to the network NW via the communication device 24.

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

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

[0176] In S22 , the control device 21 generates a record hash value of the end record of the distributed ledger 52 .

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

[0178] In S24, 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 S23 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 S21 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 S23 and the random value generated in S21 to create an electronic signature.

[0179] In S25, 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 information M5(k2) included in the third request as Key. In addition, the control device 21 sets the timestamp token obtained in S23 as Obj-HV. The other processing in S25 is the same as Fig. 9 The processing of S4 is basically the same, so it will not be repeated.

[0180] In S26, the control device 21 outputs a control signal for transmitting the transaction data generated in S25 to the network NW to the communication device 24. Thus, the transaction data is transmitted to the network NW via the communication device 24.

[0181] Fig.12 This is a flowchart showing the processing procedure when the fourth request is received. Fig.12 The processing of the flowchart shown is executed by the control device 21 when the fourth request is received from the input device 25 or the user terminal device 7.

[0182] In S31 , the control device 21 generates a record hash value of the end record of the distributed ledger 52 .

[0183] In S32, the control device 21 creates a client certificate including the record hash value generated in S31. The control device 21 may include information for identifying itself (Company A) in the client certificate.

[0184] In S33, the control device 21 outputs a control signal for transmitting the client certificate created in S32 to the external server 9 to the communication device 24. As a result, the client certificate is transmitted to the external server 9 via the communication device 24.

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

[0186] In S41 , 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.

[0187] In S42 , the control device 21 reads out the public key of the client server 2 determined in S41 from the storage device 27 .

[0188] In S43, the control device 21 decrypts the electronic signature included in the transaction data using the public key read out in S42.

[0189] In S44, the control device 21 verifies the validity of the electronic signature decrypted in S43. Specifically, the control device 21 compares the value obtained by decrypting the electronic signature with 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 S44), and the processing proceeds to S45. If the two are consistent, the control device 21 recognizes the validity of the electronic signature ("Yes" in S44), and the processing proceeds to S46.

[0190] In S45, 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.

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

[0192] In S47, 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 S46. Then, the control device 21 adds the record to the determined distributed ledger. In this way, the distributed ledger set 50 is updated.

[0193] In S48, 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.

[0194] As described above, in the data management system 1 of the first embodiment, 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 target data, and the distributed ledger 52 is a chain of evidence for proving the existence of the timestamp token.

[0195] In the distributed ledger 51, each time the object data is updated, a record containing its hash value is stored. Since the records containing the hash value of the object data are managed by the distributed ledger 51, the tamper resistance of the object data can be improved. In addition, the records stored in the distributed ledger 51 do not contain the object data itself, but the hash value of the object data. As a result, the object data itself can be hidden from other client servers 2 forming the network NW.

[0196] In addition, if a record is appended to the distributed ledger 51 and the second operation is performed, a timestamp token is obtained for the record hash value of the appended record (the end record of the distributed ledger 51), and the record containing the timestamp token is stored in the distributed ledger 52. By storing the timestamp token in the distributed ledger 52, the tamper resistance of the timestamp token can be improved. Then, by storing the timestamp token in the distributed ledger 52, even if there is a timestamp token with an expired validity period, it is possible to prove that the timestamp token with an expired validity period has not been tampered with by subsequent records of the record containing the timestamp token. In this way, the validity of the timestamp token with an expired validity period can be proved, so the validity period of the timestamp token can be substantially extended.

[0197] Furthermore, the timestamp token is obtained for the record hash value of the terminal record of the distributed ledger 52. Thus, the integrity of the record hash value can be proved, so by proving that the record hash value has not been tampered with, it can be proved that a series of timestamp tokens stored in the distributed ledger 52 have not been tampered with.

[0198] Furthermore, by storing a timestamp token obtained by using a record hash value of the end record of the distributed ledger 52 in the distributed ledger 52 , the tamper resistance of the timestamp token can be improved.

[0199] In addition, a client certificate including a record hash value of the terminal record of the distributed ledger 52 is created, and the client certificate is separated from the client server 2 and managed by the external server 9. Thus, even if all records of the distributed ledger set 50 are tampered with, the client certificate managed by the external server 9 can prove that the distributed ledger set 50 has been tampered with.

[0200] [Modification 1]

[0201] In Implementation Example 1, an example is described in which the component (component constituting the vehicle) managed by the data management system 1 is one. However, multiple components may be managed by the data management system 1. For example, N (a natural number greater than 2) components may be managed by the data management system 1. In this case, the distributed ledger set 50 includes N distributed ledgers that serve as the evidence chain of the N components and a distributed ledger that serves as the evidence chain of the timestamp token. In Modification Example 1, if one of the N distributed ledgers is updated and the second operation is performed, the timestamp token is obtained by the record hash value of the end record of the distributed ledger, and the record containing the timestamp token is stored in the distributed ledger that serves as the evidence chain of the timestamp token. Then, by responding to the third operation and the fourth operation in the same manner as Implementation Example 1, the same effect as Implementation Example 1 can be achieved.

[0202] [Implementation Method 2]

[0203] 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 2, 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.

[0204] Fig.14 1 is a diagram showing a schematic structure of a data management system 1A according to Embodiment 2. The data management system 1A includes four client servers 3, a platform server 6, a time authentication authority 8, and an external server 9. As in Embodiment 1, each of the four client servers 3 belongs to a different enterprise (e.g., Enterprise A, Enterprise B, Enterprise C, and Enterprise D). Hereinafter, the client server 3 of Enterprise A will be described as a representative example, but the client servers 3 of Enterprise B, Enterprise C, and Enterprise D also have the same functions.

[0205] The platform server 6 manages the network NW similarly to the platform server 5 in the first embodiment, 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 second 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.

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

[0207] 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 registering / updating the target data based on the input to the input device 35 or the request from the user terminal device 7 and outputs it to the database 4.

[0208] When the client server 3 registers / 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 (submission form described later) held by each client server 3 is generated. Then, the client server 3 sends the generated transaction data to the platform server 6.

[0209] The platform server 6 has a function of providing certainty to transaction data. The platform server 6 maintains a ledger set 60, processes 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 form 374 storing submission records. The submission form 374 is equivalent to an example of the "distributed ledger" of the present disclosure.

[0210] Fig.15: 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 stores the update status of the object data in a time series, similarly to the distributed ledger 51 of Implementation Example 1, to form a chain of evidence for the object data. The ledger 68 stores the timestamp tokens in a time series, similarly to the distributed ledger 52 of Implementation Example 1, to form a chain of evidence for the timestamp tokens. 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.15 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 "2" is stored as the latest (last) record.

[0211] Refer again Fig.14 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.

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

[0213] Verification data 372 includes a suspension form 373 and a submission form 374 . Fig.16 This is a diagram for explaining an example of the structure of the pause table 373 . Fig.17 374 is a diagram for explaining an example of the structure of the commit table 374. The pause table 373 and the commit table 374 have structures corresponding to the account book set 60.

[0214] Reference Fig.16The suspension table 373 includes predetermined types of information included in the unused transaction data. Specifically, the suspension table 373 stores suspension records including, for example, information of a key and a nonce. The control device 31 stores the information of the key and the nonce included in the transaction data generated in response to various requests (the first request to the third request) as a suspension record in the suspension table 373. In addition, below, when the first request to the third request are not particularly distinguished, the first request to the third request are collectively referred to as an "update request".

[0215] In the update request received by the client server 3 from the input device 35 or the user terminal device 7, information for determining the ID of the distributed ledger that is the object of the additional record is included. For example, in the first request, ID information M1 representing "k1" is included. In the second request, ID information M3 representing "k2" is included. In the third request, ID information M5 representing "k2" is included. That is, the ID contained in the update request for determining the distributed ledger that is the object of the additional record becomes the Key. In addition, if an update request is received, the control device 31 generates a random value. The random value represents the number of the update request (that is, the number of the transaction data). The control device 31 creates a pause record containing the Key and Nonce information, and registers the pause record in the pause table 373. In Fig.16 , an example is shown in which a suspension record including a Key of k1 is registered in the suspension table 373 .

[0216] If processing in response to an update request is performed (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 perform the transaction processing.

[0217] 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.16 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.

[0218] Reference Fig.17 , 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 the second embodiment, 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.

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

[0220] If a 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 containing the same key as the key contained in the added commit record from the suspension table 373.

[0221] Refer again Fig.14 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 .

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

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

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

[0225] As described above, the ledger set 60 has the same structure as the distributed ledger set 50 in the first embodiment, and therefore, the description thereof will not be repeated.

[0226] Next, the processing of the response to the update request in the second embodiment will be described in sequence, with reference to a flowchart.

[0227] Fig.18 1 is a flowchart showing the order of processing executed by the data management system 1A when an update request is received. Fig.18 The process of the flowchart shown is started by the control device 31 of the client server 3 when an update request is received from the input device 25 or the user terminal device 7 .

[0228] In S50, 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.

[0229] In S51, 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 distributed ledger to which the record included in the update request is to be added and sets it as the key information, sets the random value generated in S50 as the Nonce information, and generates a pause record.

[0230] In S52, the control device 31 of the client server 3 determines whether the suspension record generated in S51 can be registered in the suspension table 373. When a suspension record having information of the same key as the suspension record generated in S51 is registered in the suspension table 373, the control device 31 of the client server 3 makes a negative judgment ("No" in S52) 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 S51 is not registered in the suspension table 373, the control device 31 of the client server 3 makes an affirmative judgment ("Yes" in S52) and advances the processing to S53.

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

[0232] In S54, 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. Fig. 9 The transaction data is generated by the same processing as that of S2 to S4 described in the previous section. If the update request is the second request, the same processing as that in Fig.10The transaction data is generated by the same processing as that of S12 to S15 described in the previous section. If the update request is the third request, the same processing as that in Fig.11 The transaction data is generated by the same processing as S22 to S25 described in the previous section. Fig. 9 , Fig.10 and Fig.11 As has been explained in, it will not be repeated.

[0233] In S55, the control device 31 of the client server 3 outputs a control signal for transmitting the transaction data generated in S54 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.

[0234] In S60, 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.13 The electronic signature is decrypted by performing the same processing as that of S41 to S43 described in the previous section. Fig.13 As has been explained in, it will not be repeated.

[0235] In S61, the control device 61 of the platform server 6 verifies the validity of the electronic signature decrypted in S60. 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 object data in the transaction data generated according to the first request, and the timestamp token in the transaction data generated according to the second request and the third 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 S61), and the processing proceeds to S62. If the two are consistent, the control device 61 of the platform server 6 recognizes the validity of the electronic signature ("Yes" in S61), and the processing proceeds to S63.

[0236] In S62, 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 S66.

[0237] In S63, 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.13The same processing as the processing of S46 and S47 described above is performed to generate a record of the ledger identified by the information of the key included in the transaction data, and the generated record is added to the ledger, thereby updating the ledger set 60.

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

[0239] In S65, 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.

[0240] In S66, the control device 61 of the platform server 6 outputs a control signal for sending the abnormality report prepared in S62 or the normality report prepared in S65 to the client server 3 to the communication device 64. Thus, the abnormality report or the normality report is sent to the client server 3 via the communication device 64.

[0241] In addition, in S66, 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 company B, company C, and company 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.

[0242] In S56, 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 S56), the control device 31 of the client server 3 advances the process to S57. On the other hand, if it is determined that a normal report is not received, that is, an abnormal report is received ("No" in S56), the control device 31 of the client server 3 advances the process to S59.

[0243] In S57, 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.

[0244] In S58 , 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 .

[0245] In S59 , 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 .

[0246] 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 S66 also update the submission form 374 by adding the verification record to the submission form 374 in the same manner.

[0247] Fig.19 This is a flowchart showing the processing procedure when the fourth request is received in the second embodiment. Fig.19 The processing of the flowchart shown is executed by the control device 31 when the fourth request is received from the input device 35 or the user terminal device 7 .

[0248] In S71 , the control device 31 generates a record hash value of the last record of the submission data 376 .

[0249] In S72, the control device 31 creates a client certificate including the record hash value generated in S71. The control device 31 may include information for identifying itself (Company A) in the client certificate.

[0250] In S73, the control device 31 outputs a control signal for transmitting the client certificate created in S72 to the external server 9 to the communication device 24. As a result, the client certificate is transmitted to the external server 9 via the communication device 24.

[0251] As described above, in the data management system 1A of the second embodiment, the platform server 6 provides certainty for the 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 object data is stored in time series, and in the ledger 68, the timestamp token 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 the first embodiment. By each client server 3 holding the submission form 374, the tamper resistance of the submission form 374 is improved.

[0252] Then, in the structure of the data management system 1A of implementation mode 2, in response to the second request, a timestamp token is obtained based on the record hash value of the end record of the submission data 375 (ledger 67). If a record containing a timestamp token is stored in the submission data 376 (ledger 68), then as in implementation mode 1, the validity of the timestamp token whose validity period has expired can be proved.

[0253] Furthermore, by obtaining the timestamp token for the record hash value of the end record of the submission data 376 (ledger 68), the integrity of the record hash value can be proved. Therefore, by proving that the record hash value has not been tampered with, it is possible to prove that a series of timestamp tokens stored in the submission data 376 (ledger 68) have not been tampered with.

[0254] Furthermore, by storing a timestamp token obtained by using a record hash value of the end record of the submission data 376 (ledger 68 ) in the submission data 376 (ledger 68 ), the tamper resistance of the timestamp token can be improved.

[0255] In addition, a client certificate including a record hash value of the terminal record of the submission data 376 is created, and the client certificate is separated from the client server 3 and managed by the external server 9. Thus, even if all records of the submission form 374 and the ledger set 60 are tampered with, it is possible to prove that the submission form 374 and the ledger set 60 have been tampered with by the client certificate managed by the external server 9.

[0256] [Modification 2]

[0257] In Embodiment 2, 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 have the same information as the ledgers 67 and 68.

[0258] 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. in, The data management device comprises: A storage device for storing a distributed ledger; A control device updates the distributed ledger; and The communication device is configured to communicate with a time authentication authority that assigns a time stamp token, The distributed ledger includes: a first distributed ledger storing records containing information related to the data in time series; and The second distributed ledger stores records including the timestamp token obtained from the time authentication authority in time series, The control device obtains a first time stamp token, which is a time stamp token for information related to an end record of the first distributed ledger, from the time authentication mechanism via the communication device, and stores the record including the first time stamp token in the second distributed ledger.

2. The data management device according to claim 1, in, The information related to the terminal record of the first distributed ledger is a hash value of the terminal record.

3. The data management device according to claim 1 or 2, in, The control device obtains the first time stamp token according to a user operation on the data management device.

4. The data management device according to claim 1 or 2, in, When a record is added to the first distributed ledger, the control device obtains the first timestamp token for the record.

5. The data management device according to any one of claims 1 to 4, in, The control device obtains, from the time authentication mechanism via the communication device, a second time stamp token which is a time stamp token for information related to an end record of the second distributed ledger, and stores the record including the second time stamp token in the second distributed ledger.

6. The data management device according to claim 5, in, The control device obtains the second time stamp token based on a user operation on the data management device.

7. The data management device according to claim 5, in, The control device acquires the second time stamp token when a predetermined time has passed since the last acquisition time of the second time stamp token.

8. The data management device according to any one of claims 1 to 7, in, The communication device is further configured to be able to communicate with an external server different from the data management device. The control device transmits information related to the terminal record of the second distributed ledger at a predetermined time point to the external server via the communication device.

9. The data management device according to any one of claims 5 to 8, in, The information related to the terminal record of the second distributed ledger is a hash value of the terminal record.

10. A data management method, comprising: using a data management device, wherein the data management device manages data using a distributed ledger technology. in, The data management device comprises: A storage device for storing a distributed ledger; A control device updates the distributed ledger; and The communication device is configured to communicate with a time authentication authority that assigns a time stamp token, The distributed ledger includes: a first distributed ledger storing records containing information related to the data in time series; and The second distributed ledger stores records including the timestamp token obtained from the time authentication authority in time series, The data management method comprises: A step of obtaining, via the communication device, a first timestamp token which is a timestamp token for information related to an end record of the first distributed ledger from the time authentication authority; as well as The step of storing a record including the first timestamp token in the second distributed ledger.

11. The data management method according to claim 10, in, Also includes: A step of obtaining, via the communication device, from the time authentication authority, a second time stamp token which is a time stamp token for information related to an end record of the second distributed ledger; as well as The step of storing a record including the second timestamp token in the second distributed ledger.

Images