Data management device and data management method

Abstract

When a control device (21) of a client server (2) updates component data (D12) to component data (D13), a record (Age [3]) including hash values of the component data (D13) is created in a first evidence chain (distributed ledger 51). Then, the control device (21) generates an end hash value, which is a hash value of an end record (Age [3]) of the first chain of evidence. The control device (21) stores the generated end hash value in a record of a second chain of evidence (distributed book (52)), and associates the distributed book (51) with the distributed book (52).

Description

Technical Field

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

[0002] In Japanese Patent Publication No. 6694204 (Patent Document 1), a data management system is disclosed. In this data management system, for each Key (ID) for identifying a management object, a distributed ledger (asset) having a DAG (Directed Acyclic Graph) structure is configured, and information is managed for each ID.

[0003] Prior Art Documents

[0004] Patent Documents

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

[0006] Problems to be Solved by the Invention

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

[0008] Here, there are times when it is desired to prove the order indicating which of the data stored in the asset prepared for a certain ID and the data stored in the asset prepared for another ID exists first. For example, every time each asset is updated, it is considered to prove the order by obtaining a timestamp token for the latest asset record. However, in this case, there is a possibility that the cost of obtaining the timestamp token increases or the system load increases.

[0009] The present disclosure has been made to solve the above problems, and an object of the present disclosure is to be able to easily prove the order of data between distributed ledgers in a system having a plurality of distributed ledgers.

[0010] Technical Means for Solving the Problems

[0011] (1) A data management device according to an aspect of the present disclosure is a data management device that manages data using distributed ledger technology. The data management device includes a storage device that stores a distributed ledger in which records containing information related to data are stored in time series, and a control device that appends records to the distributed ledger. The data includes first data and second data. The distributed ledger includes a first distributed ledger in which records containing first information related to the first data are stored in time series, and a second distributed ledger in which records containing second information related to the second data are stored in time series. If the first data is updated at a first time point, the control device stores a record containing the first information in the first distributed ledger, generates a first end value containing the information of the record, and stores a record containing the first end value in the second distributed ledger.

[0012] According to the above structure, at the first time point, the first end value is stored in the second distributed ledger. Thus, the first distributed ledger is associated with the second distributed ledger based on the first time point. Therefore, it is possible to prove the sequential existence of the first data updated at the first time point and the second data based on the first time point.

[0013] (2) In a certain embodiment, the first end value is a hash value of a record stored in the first distributed ledger at the first time point.

[0014] According to the above structure, since the hash value of the record in the first distributed ledger is stored in the record of the second distributed ledger, it is possible to associate the first distributed ledger with the second distributed ledger without excessive increase in data capacity.

[0015] (3) In a certain embodiment, the first information is a hash value of the first data. The second information is a hash value of the second data.

[0016] According to the above structure, the records stored in the first distributed ledger and the second distributed ledger contain the hash value of the first data and the hash value of the second data, so it is possible to conceal the first data and the second data themselves.

[0017] (4) In a certain embodiment, the control device stores a record containing the first end value in the second distributed ledger based on a request from a user.

[0018] According to the above structure, the user can associate the first distributed ledger with the second distributed ledger at an arbitrary timing.

[0019] (5) In a certain embodiment, the data management device further includes a communication device configured to be able to communicate with the time certification authority. At a second time point after the first time point, the control device transmits, via the communication device, a second end value including information of a record at the end of the second distributed ledger to the time certification authority, and obtains a time stamp token for the second end value from the time certification authority.

[0020] According to the above structure, after storing the record including the first end value in the second distributed ledger, a time stamp token is obtained for the second end value. Thereby, the sequentiality of the first data and the second data can be proved based on the first time point, and the timeliness of the first data and the second data can be proved based on the second time point.

[0021] (6) In a certain embodiment, the control device obtains a time stamp token based on a request from a user.

[0022] According to the above structure, the user can obtain a time stamp token at an arbitrary timing.

[0023] (7) The data management method of other aspects of the present disclosure is a data management method of a data management device that manages data using distributed ledger technology. The data management device includes a storage device that stores a distributed ledger in which records including information related to data are stored in time series, and a control device that appends a record to the distributed ledger. The data includes first data and second data. The distributed ledger includes a first distributed ledger that stores records including first information related to the first data in time series and a second distributed ledger that stores records including second information related to the second data in time series. The data management method includes the following steps: if the first data is updated at a predetermined time point, the control device stores a record including the first information in the first distributed ledger and generates a first end value including information of the record, and stores a record including the first end value in the second distributed ledger.

[0024] Advantages of the Invention

[0025] According to the present disclosure, in a system having a plurality of distributed ledgers, it is possible to easily prove the sequentiality of data between the distributed ledgers. Brief Description of the Drawings

[0026] Figure 1 It is a diagram showing a schematic structure of the data management system of Embodiment 1.

[0027] Figure 2 It is a diagram showing an example of the structure of a distributed ledger set (Part 1).

[0028] Figure 3It is a diagram for explaining the establishment of the association between two distributed ledgers.

[0029] Figure 4 It is a diagram (part two) showing an example of the structure of a distributed ledger set.

[0030] Figure 5 It is a functional block diagram of a control device for performing processing in response to a first operation.

[0031] Figure 6 It is a functional block diagram of a control device for performing processing in response to a second operation.

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

[0033] Figure 8 It is a functional block diagram of a control device for obtaining a timestamp token.

[0034] Figure 9 It is a flowchart showing the order of processing for generating transaction data when a first request is received.

[0035] Figure 10 It is a flowchart showing the order of processing for generating transaction data when a second request is received.

[0036] Figure 11 It is a flowchart showing the order of processing performed when transaction data is received.

[0037] Figure 12 It is a flowchart showing the order of processing for obtaining a timestamp token.

[0038] Figure 13 It is a diagram showing the schematic structure of the data management system according to Embodiment 2.

[0039] Figure 14 It is a diagram showing an example of the structure of a ledger set.

[0040] Figure 15 It is a diagram for explaining an example of the structure of a suspension form.

[0041] Figure 16 It is a diagram for explaining an example of the structure of a submission form.

[0042] Figure 17 It is a flowchart showing the order of processing performed by the data management system when an update request (first request, second request) is received.

[0043] Figure 18 It is a flowchart showing the order of processing for obtaining a timestamp token in Embodiment 2.

[0044] (Explanation of symbols)

[0045] 1, 1A: Data management system; 2, 3: Client servers; 4: Database; 5, 6: Platform servers; 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; 39: Bus; 50: Distributed ledger set; 51, 52: Distributed ledgers; 60: Ledger set; 61: Control device; 62: ROM; 63: RAM; 64: Communication device; 65: Storage device; 67, 68: Ledgers; 69: Bus; 271: Secret key; 272: Multiple public keys; 371: Secret key; 372: Verification data; 373: Pause table; 374: Submission table; 375, 376: Submission data; 651: Multiple public keys; 2101: Information acquisition unit; 2102: Hash generation unit; 2103: Random number generation unit; 2104: Electronic signature unit; 2105: Transaction data generation unit; 2106: Transaction data sending unit; 2111: Information acquisition unit; 2112: End hash generation unit; 2113: Random number generation unit; 2114: Electronic signature unit; 2115: Transaction data generation unit; 2116: Transaction data sending unit; 2121: Transaction data acquisition unit; 2122: Signature verification unit; 2123: Record production unit; 2124: Ledger update unit; 2125: Output unit; 2131: Information acquisition unit; 2132: Record hash production unit; 2133: Timestamp token acquisition unit; 2134: Output unit; NW: Network. Detailed implementation manners

[0046] Next, with reference to the accompanying drawings, the implementation manners of the present disclosure will be described in detail. In addition, the same or corresponding parts in the drawings are attached with the same symbols, and their descriptions will not be repeated.

[0047] [Embodiment 1]

[0048] <Overall structure of the data management system>

[0049] Figure 1This is a diagram showing the schematic structure of the 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 simply referred to as "network") NW among multiple enterprises and managing data using distributed ledger technology. The data management system 1 according to Embodiment 1 manages data of components constituting a vehicle (hereinafter also simply referred to as "component data"). The component data may be, for example, a specification manual of the component. In addition, the data managed by the data management system 1 is not limited to the data of components constituting a vehicle and may be various types of data.

[0050] Referring to Figure 1 , the data management system 1 includes four client servers 2, a platform server 5, and a time stamp authority (TSA: Time Stamp Authority) 8. Each of the four client servers 2 is a server belonging to a different enterprise (for example, Enterprise A, Enterprise B, Enterprise C, and Enterprise D).

[0051] The platform server 5 manages the network NW. The platform server 5 accepts participation applications from each client server 2 to the network NW. The platform server 5 permits the client server 2 to participate in the network NW based on an operation of permitting participation implemented by the administrator of the platform server 5 or based on the determination result of a predetermined condition. In Embodiment 1, four client servers 2 belonging to Enterprise A, Enterprise B, Enterprise C, and Enterprise D respectively are permitted to participate in the network NW.

[0052] The four client servers 2 form the network NW and store the hash value of the component data in their respective distributed ledgers. By importing distributed ledger-based software into each client server 2, the imported distributed ledger-based software functions, and thus each client server 2 functions as a node. Hereinafter, the client server 2 of Enterprise A will be representatively described, but the client servers of Enterprise B, Enterprise C, and Enterprise D also have the same structure and functions. In addition, the client server 2 is an example of the "data management device" in the present disclosure.

[0053] The client server 2 is configured to be able to communicate with the user terminal device 7. The user terminal device 7 is, for example, a desktop PC (Personal Computer), a notebook PC, a tablet terminal, a smart phone, or other information processing terminals with communication functions lent to employees of Enterprise A.

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

[0055] If the client server 2 stores / updates the component data in the database 4, it generates a hash value of the component data, and generates transaction data for storing the hash value in the distributed ledger. Then, the client server 2 sends the generated transaction data to other client servers 2 forming the network NW, that is, the client servers 2 of Company B, Company C, and Company D. The distributed ledger stores the hash values of the component data in chronological order, forming an evidence chain for proving the existence of the component data. In addition, in the data management system 1 of Embodiment 1, an example in which 4 client servers are included 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 5 or more.

[0056] The time authentication authority 8 includes a server belonging to the authentication authority that issues timestamp tokens. The time authentication authority issues a timestamp token according to a timestamp issuance request from an applicant (the client server 2 in Embodiment 1). More specifically, the time authentication authority sends a timestamp token obtained by combining the time information of a time source that is traceable to the international standard time with the data received from the applicant (the recorded hash value described later in Embodiment 1) to the applicant.

[0057] The client server 2 includes a control device 21, a ROM (Read Only Memory), 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.

[0058] The control device 21 is constituted by, 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. Among the various programs, an operating system and the like are included. The RAM 23 functions as a working memory and temporarily stores various data required for executing the various programs. As will be described in detail later, the control device 21 has a function of updating the component data recorded in the database 4, or generating transaction data for updating the distributed ledger, or acquiring a timestamp token.

[0059] The communication device 24 is configured to be able to communicate with external devices. The external devices include, for example, other client servers 2, user terminal devices 7, and time authentication authorities 8 and the like. The communication between the communication device 24 and the external devices is performed using the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet (registered trademark) network, a public network, a private network, a wired network, a wireless network, or a combination thereof.

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

[0061] The display device 26 includes a display. The display device 26 causes the display to display various images in accordance with a control signal from the control device 21. The display is, for example, a liquid crystal display, an organic EL (Electro Luminescence) display, or other display devices.

[0062] The storage device 27 is constituted by including, for example, 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.

[0063] The secret key 271 is the secret key of Company A. For example, when the client server 2 first participates in 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 an authentication authority (not shown) and receives authentication. The authentication authority is an authentication agency that issues electronic certificates. The authentication authority issues an electronic certificate including information of the public key. The control device 21 causes the storage device 27 to store the secret key 271 corresponding to the public key that has been authenticated. In addition, the control device 21 sends the authenticated public key (electronic certificate) 272 to the client servers 2 of Company B, Company C, and Company D.

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

[0065] The distributed ledger set 50 includes multiple distributed ledgers. The distributed ledgers are prepared for each component that makes up the vehicle. Figure 2 This is a diagram showing an example of the structure of the distributed ledger set 50. In Embodiment 1, an example of managing two components (the first component and the second component) that make up the vehicle by the data management system 1 is described. That is, the distributed ledger set 50 includes a distributed ledger 51 that stores the update status of the component data of the first component in chronological order and forms an evidence chain of the component data of the first component, and a distributed ledger 52 that stores the update status of the component data of the second component in chronological order and forms an evidence chain of the component data of the second component. In addition, if the number of components that make up the vehicle is N (a natural number of 2 or more), the distributed ledger set 50 includes N distributed ledgers. Hereinafter, the component for which the distributed ledger manages data will also be referred to as the "target component". That is, the target components in Embodiment 1 are the first component and the second component.

[0066] The distributed ledger 51 stores records including the hash value of the component data of the first component in chronological order. The records include information such as "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

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

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

[0069] Obj-HV is the hash value of the component data of the first component. For example, if the component data of the first component registered in the database 4 is updated, the hash value of the updated component data is generated and set as Obj-HV. The hash value is a value obtained as a result of hashing the component data using a hash function.

[0070] A nonce is a random value representing the number of transaction data. That is, for example, when the component data of the first component stored in the database 4 is updated, the client server 2 (control device 21) generates a hash value of the updated component data as the number for the process of storing it in the distributed ledger 51. The random value is a hash value that is less likely to collide cryptographically.

[0071] Sig is an electronic signature made using the secret key 271 of the client server 2 that issued the transaction data. The electronic signature is made, for example, by encrypting Obj-HV (that is, the hash value of the component data of the first component) with the secret key 271. Alternatively, the electronic signature can also be made, for example, by encrypting the nonce (random value) with the secret key 271.

[0072] Prev-HV is the hash value of the previous generation's record (parent record) of the latest (end) record. That is, Prev-HV is the HV of the parent record.

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

[0074] For example, as Figure 2 shown, if we focus on the latest (end) record (the record with Age "2") of the distributed ledger 51, the Prev-HV of the end record is the HV of the parent record (Age "1"), which is "H2". Next, when updating the component data of the first component and adding a record with Age "3", the Prev-HV of the record with Age "3" becomes the HV of the record with Age "2", which is "H3". In this way, the end record becomes a structure that includes the record hash value of the parent record. In other words, a chain of records is realized between the Prev-HV of the end record and the HV of the parent record. By doing so, the distributed ledger 51 forms a DAG structure.

[0075] The distributed ledger 52 stores records containing the hash value of the component data of the second component in chronological order. The records contain information such as "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV". The detailed content of these is the same as that of the records in the distributed ledger 51, so no repeated explanation will be given.

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

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

[0078] <Proof of Sequentiality>

[0079] Here, sometimes it is desired to prove which of the component data of the first component and the component data of the second component existed earlier. That is, sometimes it is desired to prove the sequentiality of the component data of the first component and the component data of the second component. As a method of proving sequentiality, for example, consider obtaining a timestamp token for the record hash value of the appended record (the end record) each time a record is appended to the distributed ledgers 51 and 52 to prove the time when the record was appended, and prove the sequentiality of the two data. However, in this method, a timestamp token must be obtained each time a record is appended to the distributed ledgers 51 and 52, increasing the man-hours and costs. In addition, the processing load consumed by the data management system 1 also increases.

[0080] Therefore, in the data management system 1 of Embodiment 1, the record hash value of one distributed ledger (for example, distributed ledger 51) can be incorporated into the record of another distributed ledger (for example, distributed ledger 52). Thus, the two distributed ledgers 51 and 52 are associated.

[0081] Figure 3 is a diagram for explaining the establishment of the association between the two distributed ledgers 51 and 52. In Figure 3 the upper part, the evidence chain of the first component, i.e., the distributed ledger 51, is schematically shown. In Figure 3Below the [specific part], the evidence chain of the second component, i.e., the distributed ledger 52, is schematically shown. Hereinafter, the evidence chain of the first component is also referred to as the "first evidence chain", and the evidence chain of the second component is also referred to as the "second evidence chain".

[0082] In the first evidence chain (distributed ledger 51), the hash values of the component data of the first component are stored in chronological order. If the component data of the first component is registered in the database 4 for the first time, a record (Age "0") containing the hash value of the component data is stored in the distributed ledger 51. Next, if the component data of the first component is updated and the updated component data is registered in the database 4, a record (Age "1") containing the hash value of the updated component data and the record hash value of the parent record (Age "0") is stored in the distributed ledger 51. If the component data of the first component is further updated and the updated component data is registered in the database 4, a record (Age "2") containing the hash value of the updated component data and the record hash value of the parent record (Age "1") is stored in the distributed ledger 51.

[0083] In the second evidence chain (distributed ledger 52), the hash values of the component data of the second component are stored in chronological order. If the component data of the second component is registered in the database 4 for the first time, a record (Age "0") containing the hash value of the component data is stored in the distributed ledger 52. Next, if the component data of the second component is updated and the updated component data is registered in the database 4, a record (Age "1") containing the hash value of the updated component data and the record hash value of the parent record (Age "0") is stored in the distributed ledger 52. If the component data of the second component is further updated and the updated component data is registered in the database 4, a record (Age "2") containing the hash value of the updated component data and the record hash value of the parent record (Age "1") is stored in the distributed ledger 52.

[0084] Here, as described above, it is assumed that in the distributed ledger 51 and the distributed ledger 52 respectively, the record with Age "2" is the latest (end) record. Then, in this state, it is assumed that a first operation of updating the component data of the first component is performed on the input device 25 or the user terminal device 7. Further, it is assumed that in addition to the first operation, a second operation of associating the first evidence chain with the second evidence chain is also performed on the input device 25 or the user terminal device 7. In addition, the operation (first operation) for updating the component data can also be, for example, an operation of inputting the ID (Key) of the target component in the display screen of the display device 26 or the user terminal device 7 and selecting the displayed update button. Further, the operation of associating the evidence chains with each other (second operation) can also be an operation of inputting the IDs (Keys) of two target components and selecting the displayed association establishment button. In the display screen for performing the second operation, for example, there are provided a "production target input field" for inputting the ID (Key) of the target component that becomes the production object of the record hash value and an "incorporation target input field" for inputting the ID (Key) of the target component that becomes the incorporation target of the record hash value. For example, if k1 is input into the production target input field and k2 is input into the incorporation target input field, the record hash value of the first evidence chain (distributed ledger 51) is incorporated into the record of the second evidence chain (distributed ledger 52). Here, it is assumed that k1 is input into the production target input field and k2 is input into the incorporation target input field. In addition, the display screen for performing the first operation and the display screen for performing the second operation can also be displayed on the same screen at the same time.

[0085] Refer to Figure 2 and Figure 3 , if the two operations of the first operation and the second operation are performed, the control device 21 first updates the component data D12 of the first component stored in the database 4 to the component data D13 in response to the first operation. In addition, when the component data D10 of the first component is first stored in the database 4, the control device 21 only needs to make the database 4 newly store the component data of the first component. The control device 21 creates a record (Age "3") including the hash value of the component data D13 and the record hash value of the parent record (Age "2"), and stores it in the distributed ledger 51. In addition, the control device 21 generates transaction data for appending the record of Age "3" to the distributed ledger 51. The control device 21 sends the generated transaction data to the client servers 2 of Company B, Company C, and Company D via the communication device 24. By performing the transaction processing of the transaction data by each client server 2, the record of Age "3" is stored in the distributed ledger 51 of each client server 2.

[0086] Next, in response to the second operation, the control device 21 generates the hash value of the end record (Age "3") of the distributed ledger 51 as the "end hash value". The end hash value is the record hash value of the end record (Age "3"). The control device 21 creates a record (Age "3") that includes the generated end hash value and the record hash value of the parent record (Age "2") of the distributed ledger 52, and stores it in the distributed ledger 52. By incorporating the end hash value of the distributed ledger 51 into the record (Age "3") of the distributed ledger 52, the distributed ledger 51 is associated with the distributed ledger 52. In addition, the control device 21 generates transaction data for appending the record of Age "3" to the distributed ledger 52. The control device 21 sends the generated transaction data to the client servers 2 of Company B, Company C, and Company D via the communication device 24. By performing the transaction processing of the transaction data by each client server 2, the distributed ledgers 51 and 52 are associated with each other in the distributed ledger sets 50 of the respective client servers 2.

[0087] If an example of the structure of the specific distributed ledger 52 is shown, it is as Figure 4 shown. Figure 4 This is a diagram showing an example of the structure of the distributed ledger set 50. In the record of Age "3" of the distributed ledger 52, the hash value Hc and the hash value H4 are included as the Pre-HV. The hash value Hc is the record hash value of the parent record (Age "2"), and the hash value H4 is the record hash value (end hash value) of the record (Age "3") of the distributed ledger 51.

[0088] As described above, by incorporating the end hash value of the distributed ledger 51 into the Pre-HV of the record of the distributed ledger 52, the distributed ledger 51 is associated with the distributed ledger 52 (the first evidence chain is associated with the second evidence chain). Thereby, the sequentiality of the component data of the first component and the component data of the second component can be proven. Referring to Figure 3 , for example, it can be proven that the component data D13 of the first component was registered in the database 4 after the component data D22 of the second component was registered in the database 4 and before the component data D23 of the second component was registered in the database 4.

[0089] Further, if a timestamp token is obtained for the record hash value of Age "3" of the distributed ledger 52, it is possible to prove the existence of the component data D10 to D13 of the first component and the existence of the component data D20 to D22 of the second component at the moment proven by the timestamp token. Compared with the case of obtaining timestamp tokens for the records of the distributed ledgers 51 and 52 respectively, it is possible to reduce man-hours, costs, system load, etc. That is, if a timestamp token is obtained for the record hash value of the record of Age "3" of the distributed ledger 52 incorporating the end hash value of the distributed ledger 51, it is possible to ensure the sequentiality and timeliness of the existence of the component data of the first component and the component data of the second component.

[0090] In addition, when the component data of the first component is further updated from D13 to D14, a record (Age "4") including the hash value of the component data D14 and the record hash value of Age "3" of the distributed ledger 51 is appended to the distributed ledger 51. Similarly, when the component data of the second component is further updated from D22 to D23, a record (Age "4") including the hash value of the component data D23 and the record hash value of Age "3" of the distributed ledger 52 is appended to the distributed ledger 52.

[0091] <Function module>

[0092] Figure 5 is a functional block diagram of the control device 21 for performing processing in response to the first operation. Refer to Figure 5 As shown, 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 executing a program stored in the ROM 22, for example. 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 dedicated hardware (electronic circuits), for example.

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

[0094] The information acquisition unit 2101 acquires the first request from the input device 25 or the user terminal device 7. For example, if a user of the client server 2 operates the input device 25 to save (register / update) the component data of the target component to the database 4, the first request is input to the information acquisition unit 2101. The first request includes an ID (Key) for identifying the target component. If 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.

[0095] If the hash generation unit 2102 receives the first request, it reads out, for example, the component data of the target component from the database 4 and generates a hash value of the component data. The hash generation unit 2102 outputs the generated hash value and the ID of the target component to the electronic signature unit 2104 and the transaction data generation unit 2105.

[0096] If the random number generation unit 2103 receives the first request, it generates a random number value. The random number value is a hash value that is not likely to collide cryptographically. The random number generation unit 2103 outputs the generated random number value and the ID of the target component to the transaction data generation unit 2105. In addition, when the random number value is used to create an electronic signature, the random number generation unit 2103 may also output the random number value and the ID of the target component to the electronic signature unit 2104.

[0097] The electronic signature unit 2104 reads out 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 of the target component to the transaction data generation unit 2105. Additionally, the electronic signature unit 2104 may also create an electronic signature by encrypting the random number value received from the random number generation unit 2103 with the secret key 271. Additionally, the electronic signature unit 2104 may also create an electronic signature by encrypting the hash value and the random number value with the secret key 271.

[0098] The transaction data generation unit 2105 generates transaction data to be sent to the network NW. For example, the transaction data generation unit 2105 generates transaction data including information such as Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2105, for example, identifies the Age of the parent record by checking the Key in the distributed ledger set 50, increments the Age of the parent record, and sets it as the Age of the record to be appended. The transaction data generation unit 2105 sets the hash value generated by the hash generation unit 2102 as Obj-HV, sets the random number value generated by the random number generation unit 2103 as Nonce, and sets the electronic signature produced by the electronic signature unit 2104 as Sig. In addition, the transaction data generation unit 2105 sets the record hash value of the parent record as Prev-HV. The transaction data generation unit 2105 hashes the information of Key, Age, Obj-HV, Nonce, Sig, and Prev-HV, and sets it as HV. In the transaction data, it may also include the time information when the transaction data is broadcast to the network NW (sent 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.

[0099] The transaction data sending unit 2106 outputs a control signal for sending the transaction data to the network NW to the communication device 24. Thereby, the transaction data is sent to the network NW via the communication device 24.

[0100] Figure 6 It is a functional block diagram of the control device 21 for executing the process in response to the second operation. Refer to Figure 6 As shown in the figure, the control device 21 includes an information acquisition unit 2111, a terminal hash generation unit 2112, a random number generation unit 2113, an electronic signature unit 2114, a transaction data generation unit 2115, and a transaction data sending unit 2116. The control device 21 functions as the information acquisition unit 2111, the terminal hash generation unit 2112, the random number generation unit 2113, the electronic signature unit 2114, the transaction data generation unit 2115, and the transaction data sending unit 2116, for example, by executing the program stored in the ROM 22. In addition, the information acquisition unit 2111, the terminal hash generation unit 2112, the random number generation unit 2113, the electronic signature unit 2114, the transaction data generation unit 2115, and the transaction data sending unit 2116 may also be implemented by dedicated hardware (electronic circuits), for example.

[0101] If a second operation of associating the first evidence chain (distributed ledger 51) with the second evidence chain (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 second request indicating that the second operation has been performed.

[0102] The information acquisition unit 2111 acquires the second request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2 operates the input device 25 and, in addition to the first operation, also selects an association establishment button for establishing an association between evidence chains (if the second operation is performed), the second request is input to the information acquisition unit 2111. The second request includes the ID of the object component (e.g., k1) that is the production target of the terminal hash value and the ID of the object component (e.g., k2) that is the incorporation target of the terminal hash value. If the information acquisition unit 2111 acquires the second request, it outputs the second request to the terminal hash generation unit 2112 and the random number generation unit 2113.

[0103] The terminal hash generation unit 2112 generates the hash value of the latest record (the record at the end of the evidence chain) of the distributed ledger (e.g., the distributed ledger 51) determined by the ID of the object component that is the production target of the terminal hash value as the terminal hash value. The terminal hash generation unit 2112 outputs the generated terminal hash value and the ID of the object component (e.g., k2) that is the incorporation target of the terminal hash value to the electronic signature unit 2114 and the transaction data generation unit 2115.

[0104] If the random number generation unit 2113 receives the second request, it generates a random number value. The random number generation unit 2113 outputs the generated random number value and the ID of the object component (e.g., k2) that is the incorporation target of the terminal hash value to the transaction data generation unit 2115. In addition, in the case where the random number value is used for generating an electronic signature, the random number generation unit 2113 may also output the random number value and the ID of the object component (e.g., k2) that is the incorporation target of the terminal hash value to the electronic signature unit 2114.

[0105] The electronic signature unit 2114 reads the secret key 271 from the storage device 27. The electronic signature unit 2114 generates an electronic signature by encrypting the terminal hash value received from the terminal hash generation unit 2112 with the secret key 271. The electronic signature unit 2114 outputs the generated electronic signature and the ID of the object component (e.g., k2) that is the incorporation target of the terminal hash value to the transaction data generation unit 2115. In addition, the electronic signature unit 2114 may also generate an electronic signature by encrypting the random number value received from the random number generation unit 2113 with the secret key 271. In addition, the electronic signature unit 2114 may also generate an electronic signature by encrypting the terminal hash value and the random number value with the secret key 271.

[0106] The transaction data generation unit 2115 generates transaction data to be sent to the network NW. For example, the transaction data generation unit 2115 generates transaction data including information such as Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2115 sets the ID (such as k2) of the object component to be incorporated as the terminal hash value as Key. In addition, the transaction data generation unit 2115 sets the terminal hash value generated by the terminal hash generation unit 2112 as Obj-HV. Other functions of the transaction data generation unit 2115 are substantially the same as those of the transaction data generation unit 2105 described in Figure 5 are basically the same.

[0107] The transaction data sending unit 2116 outputs a control signal for sending the transaction data to the network NW to the communication device 24. Thereby, the transaction data is sent to the network NW via the communication device 24.

[0108] Figure 7 is a functional block diagram of the control device 21 for executing the received transaction data. Refer to Figure 7 , the control device 21 includes a transaction data acquisition unit 2121, a signature verification unit 2122, a record production unit 2123, a ledger update unit 2124, and an output unit 2125. The control device 21 functions as the transaction data acquisition unit 2121, the signature verification unit 2122, the record production unit 2123, the ledger update unit 2124, and the output unit 2125, for example, by executing a program stored in the ROM 22. In addition, the transaction data acquisition unit 2121, the signature verification unit 2122, the record production unit 2123, the ledger update unit 2124, and the output unit 2125 can also be implemented by dedicated hardware (electronic circuits), for example.

[0109] The transaction data acquisition unit 2121 acquires the transaction data sent from the other client server 2. The transaction data acquisition unit 2121 outputs the acquired transaction data to the signature verification unit 2122.

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

[0111] When the validity of the electronic signature is determined, the record creation unit 2123 creates a record to be appended to the distributed ledger set 50 based on the transaction data. The record creation unit 2123 reads out the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV from the transaction data and creates a record including this information.

[0112] The ledger update unit 2124 appends the record created by the record creation unit 2123 to the distributed ledger set 50 and updates the distributed ledger set 50. Specifically, the ledger update unit 2124 determines the distributed ledger to which the record is to be appended with reference to the Key of the created record. For example, the transaction data generated by the first operation of updating the component data of the first component has "k1" representing the ID of the first component as the Key. The record created based on this transaction data also has "k1" as the Key. Therefore, the ledger update unit 2124 appends this record to the evidence chain of the component data of the first component, i.e., the distributed ledger 51. In addition, the transaction data generated by the second operation of associating the first evidence chain with the second evidence chain has "k2" representing the ID of the second component as the Key. The record created based on this transaction data also has "k2" as the Key. Therefore, the ledger update unit 2124 appends this record to the evidence chain of the component data of the second component, i.e., the distributed ledger 52.

[0113] If the update of the distributed ledger set 50 is completed, the ledger update unit 2124 outputs this meaning to the output unit 2125.

[0114] The output unit 2125 outputs a control signal for sending the completion of the processing of the execution transaction data (transaction processing) to the client server 2, which is the source of the transaction data, to the communication device 24. Thereby, a report of 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.

[0115] Figure 8 It is a functional block diagram of the control device 21 for obtaining a timestamp token. Refer to Figure 8 , the control device 21 includes an information acquisition unit 2131, a record hash creation unit 2132, a timestamp token acquisition unit 2133, and an output unit 2134. The control device 21 functions as the information acquisition unit 2131, the record hash creation unit 2132, the timestamp token acquisition unit 2133, and the output unit 2134, for example, by executing a program stored in the ROM 22. In addition, the information acquisition unit 2131, the record hash creation unit 2132, the timestamp token acquisition unit 2133, and the output unit 2134 can also be implemented by dedicated hardware (electronic circuit), for example.

[0116] If a third operation of requesting to obtain a timestamp token 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.

[0117] The information acquisition unit 2131 acquires the third request from the input device 25 or the user terminal device 7. For example, if a user of the client server 2 operates the input device 25 and inputs the ID of the object for which the timestamp token is to be obtained on the display screen of the display device 26 and selects the timestamp token acquisition button displayed on the display device 26 (if the third operation is performed), the third request is input to the information acquisition unit 2131. The third request includes an ID (Key) for determining the object component. If the information acquisition unit 2131 acquires the third request, it outputs the third request to the record hash creation unit 2132.

[0118] The record hash creation unit 2132 determines the ID of the object component from the third request and determines the distributed ledger that is the object for obtaining the timestamp token (creating the record hash value). For example, when the ID of the second component, i.e., "k2", is included in the third request, the record hash creation unit 2132 creates the record hash value of the latest record (end record) of the distributed ledger 52. The record hash creation unit 2132 outputs the created record hash value to the timestamp token acquisition unit 2133.

[0119] The timestamp token acquisition unit 2133 outputs a control signal for sending the record hash value received from the record hash production unit 2132 to the time certification authority 8 to the communication device 24. Thus, the record hash value is sent to the time certification authority 8 via the communication device 24.

[0120] The time certification authority 8 that has received the record hash value sends the timestamp token back to the client server 2.

[0121] The timestamp token acquisition unit 2133 receives the timestamp token from the time certification authority 8 via the communication device 24. The timestamp token acquisition unit 2133 outputs the acquired timestamp token to the output unit 2134.

[0122] The output unit 2134 causes the storage device 27 to store the timestamp token received from the timestamp token acquisition unit 2133. Alternatively, the output unit 2134 may cause the database 4 to store the timestamp token received from the timestamp token acquisition unit 2133. Thus, proof of the existence time can be obtained.

[0123] In addition, the output unit 2134 may also cause the distributed ledger set 50 to hold the timestamp token received from the timestamp token acquisition unit 2133. For example, if the output unit 2134 has obtained a timestamp token for the record hash value of the distributed ledger 52, it creates a record including the timestamp token and appends the record to the distributed ledger 52. Then, the output unit 2134 generates transaction data with the timestamp token set as Obj-HV and outputs a control signal for sending the transaction data to the client server 2 participating in the network NW to the communication device 24. Thus, the timestamp token is appended to the distributed ledger set 50 of each client server 2.

[0124] In addition, the output unit 2134 may output a control signal for sending the timestamp token received from the timestamp token acquisition unit 2133 to the external server 9 to the communication device 24. The external server 9 is a server managed by a management entity that is not any one of enterprise A, enterprise B, enterprise C, and enterprise D. In order to tamper with the timestamp token, it is also necessary to tamper with the timestamp token managed by the external server 9. By also managing the timestamp token by the external server 9, the anti-tampering property of the timestamp token can be improved.

[0125] <Flowchart>

[0126] Figure 9 It is a flowchart showing the order of processing for generating transaction data when the first request is received. Figure 9 The processing of the shown flowchart is executed by the control device 21 when the first request is received from the input device 25 or the user terminal device 7. In addition, regarding Figure 9 and the followingFigure 10 , 11 For each step of the flowchart shown in FIG. 12 (hereinafter, the steps will be abbreviated as "S"), it is described that it is implemented by software processing performed by the control device 21, but a part or all of it may also be implemented by hardware (electronic circuit) manufactured within the control device 21.

[0127] In S1, the control device 21 generates a random value. This random value is used as the number of the transaction data.

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

[0129] 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 may also use the secret key 271 to encrypt the random value generated in S1 to create an electronic signature. Additionally, the control device 21 may 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.

[0130] In S4, the control device 21 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. Specifically, the control device 21 sets the ID of the target component included in the first request as Key. Additionally, 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 created in S3 as Sig. Additionally, the control device 21 checks Key in the distributed ledger set 50 to identify the Age of the parent record, and sets the Age after incrementing the Age of the parent record as Age. Additionally, the control device 21 sets the record hash of the parent record as Prev-HV. Additionally, the control device 21 hashes the information of Key, Age, Obj-HV, Nonce, Sig, and Prev-HV except for the information of HV and sets it as HV. Additionally, the control device 21 may also include the time information when the transaction data is broadcast to the network NW and / or the sender information of the transaction data in the transaction data.

[0131] In S5, the control device 21 outputs a control signal for sending the transaction data generated in S4 to the network NW to the communication device 24. Thereby, the transaction data is sent to the network NW via the communication device 24.

[0132] Figure 10 is a flowchart showing the order of processing for generating transaction data in the case where the second request is received. Figure 10The processing of the flowchart shown is executed by the control device 21 when the second request is received from the input device 25 or the user terminal device 7.

[0133] In S11, the control device 21 generates a random value. This random value is used as the number of the transaction data.

[0134] In S12, the control device 21 hashes the latest record (the end record of the evidence chain) of the distributed ledger and creates an end hash value. As described above, in the display screen for performing the second operation, there is a "production object input field" for inputting the ID of the object component that is the production object of the end hash value and an "incorporation object input field" for inputting the ID of the object component that is the incorporation target of the end hash value. For example, when k1 is input to the production object input field and k2 is input to the incorporation object input field, the control device 21 hashes the latest record of the distributed ledger 51 and creates an end hash value.

[0135] In S13, the control device 21 reads the secret key 271 from the storage device 27 and uses the secret key 271 to encrypt the end hash value generated in S12 to create an electronic signature. In addition, the control device 21 may also use the secret key 271 to encrypt the random value generated in S11 to create an electronic signature. Further, the control device 21 may also use the secret key 271 to encrypt the end hash value generated in S12 and the random value generated in S11 to create an electronic signature.

[0136] In S14, the control device 21 generates transaction data including information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The control device 21 sets the ID (k2 in the above example) input to the "incorporation object input field" as Key. In addition, the control device 21 sets the end hash value generated in S12 as Obj-HV. The other processing in S14 is basically the same as the processing of S4 in Figure 9 so the description will not be repeated.

[0137] In S15, the control device 21 outputs a control signal for sending the transaction data generated in S14 to the network NW to the communication device 24. Thereby, the transaction data is sent to the network NW via the communication device 24.

[0138] Figure 11 is a flowchart showing the order of processing executed when the transaction data is received. Figure 11 The processing of the flowchart shown is executed by the control device 21 when the transaction data is received.

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

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

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

[0142] In S24, the control device 21 verifies the validity of the electronic signature decrypted in S23. Specifically, the control device 21 compares the value obtained by decrypting the electronic signature with the hash value (or the terminal hash value) included in the transaction data. If the two do not match, the control device 21 does not recognize the validity of the electronic signature (in S24, it is "no"), and advances the process to S25. If the two match, the control device 21 recognizes the validity of the electronic signature (in S24, it is "yes"), and advances the process to S26.

[0143] In S25, since the electronic signature is not valid, the control device 21 discards the transaction data received this time and ends the process. In addition, the control device 21 may also cause the display device 26 to display a message indicating that there is a possibility that the transaction data has been tampered with.

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

[0145] In S27, the control device 21 determines the distributed ledger to which the record is to be appended based on the Key in the record created in S26. Then, the control device 21 appends the record to the determined distributed ledger. Thereby, the distributed ledger set 50 is updated.

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

[0147] Figure 12 It is a flowchart showing the order of the process of obtaining a timestamp token. Figure 12 The process of the shown flowchart is executed by the control device 21 when a third request is received from the input device 25 or the user terminal device 7.

[0148] In S31, the control device 21 determines the distributed ledger (distributed ledger 51 or distributed ledger 52) that is the object for obtaining the timestamp token based on the ID of the object component included in the third request.

[0149] In S32, the control device 21 generates a record hash value of the latest record (end record) of the distributed ledger determined in S31.

[0150] In S33, the control device 21 outputs a control signal for sending the record hash value generated in S32 to the time certification authority 8 to the communication device 24. Thereby, the record hash value is sent to the time certification authority 8 via the communication device 24.

[0151] In S34, the control device 21 receives a timestamp token from the time certification authority 8 via the communication device 24. Thereby, it obtains proof of the existence time of the component data of the object component.

[0152] In S35, the control device 21 causes the storage device 27 to store the timestamp token obtained in S34. In addition, the control device 21 may also cause the database 4 to store the timestamp token. Further, the control device 21 may also cause the distributed ledger set 50 to hold the timestamp token.

[0153] In S36, the control device 21 outputs a control signal for sending the timestamp token obtained in S34 to the external server 9 to the communication device 24. Thereby, the timestamp token is sent to the external server 9 via the communication device 24. In addition, the control device 21 may also generate transaction data for appending the timestamp token to the distributed ledger set 50 and output a control signal for sending the transaction data to the network NW to the communication device 24.

[0154] As described above, in the data management system 1 of Embodiment 1, the client server 2 holds the distributed ledger set 50 including two distributed ledgers 51 and 52. The distributed ledger 51 is an evidence chain for proving the existence of the component data of the first component, and the distributed ledger 52 is an evidence chain for proving the existence of the component data of the second component. The client server 2 has a function of associating the two distributed ledgers 51 and 52 according to a request from a user. The client server 2 incorporates the end hash value of one distributed ledger into the record of the other distributed ledger. It is possible to prove the sequentiality of the existence of the component data of the first component and the component data of the second component based on the record into which the end hash value is incorporated.

[0155] In addition, the client server 2 obtains a timestamp token for a record incorporated with an end hash value. If a timestamp token is obtained for a record incorporated with an end hash value, it is possible to obtain proof of the existence time of the component data of the first component and the component data of the second component (i.e., proof that the component data existed before the time indicated by the timestamp token). If a timestamp token is obtained for a record incorporated with an end hash value, compared with the case of obtaining timestamp tokens for the distributed ledgers 51 and 52 respectively, it is possible to reduce man-hours, costs, and system load.

[0156] In addition, the client server 2 sends the timestamp token to the external server 9. By also having the external server 9 manage the timestamp token, the anti-tampering property of the timestamp token can be improved.

[0157] [Modification Example 1]

[0158] In Embodiment 1, an example of establishing the association of two evidence chains according to the second request generated by the user operation (the second operation) is described, but the establishment of the association of the two evidence chains can also be performed automatically. For example, every time the update of the component data of the target component is executed M (natural number) times, the end hash value of the evidence chain (distributed ledger) of the target component can be incorporated into the record of another evidence chain (distributed ledger). Even with such a structure, the same effect as in Embodiment 1 can be achieved.

[0159] [Embodiment 2]

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

[0161] Figure 13 It is a diagram showing the schematic structure of the data management system 1A of Embodiment 2. The data management system 1A includes four client servers 3, a platform server 6, and a time certification authority 8. Similar to Embodiment 1, each of the four client servers 3 is a server belonging to different enterprises (for example, Enterprise A, Enterprise B, Enterprise C, and Enterprise D). Hereinafter, the client server 3 of Enterprise A will be representatively described, but the client servers 3 of Enterprise B, Enterprise C, and Enterprise D also have the same functions.

[0162] The platform server 6, similar to the platform server 5 in Embodiment 1, manages the network NW and accepts applications for joining the network NW from each client server 3. The platform server 6 permits the client server 3 to join the network NW based on the operation of permitting participation implemented by the administrator of the platform server 6 or based on the determination result of a predetermined condition. In Embodiment 2, four client servers 3 belonging to Enterprise A, Enterprise B, Enterprise C, and Enterprise D are also permitted to join the network NW.

[0163] The four client servers 3 and the platform server 6 form the network NW. By importing software based on a distributed ledger into each client server 3, the imported software based on the distributed ledger functions, and thus 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, similar to the client server 2 in Embodiment 1.

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

[0165] If the client server 3 stores / updates the component data in the database 4, it creates a hash value of the component data and generates transaction data for storing the hash value in the ledger held by the platform server 6 and the distributed ledger held by each client server 3. Then, the client server 3 sends the generated transaction data to the platform server 6.

[0166] The platform server 6 has a function of providing determinism for the transaction data. The platform server 6 holds a ledger set 60, processes the transaction data received from the client server 3, and updates the ledger set 60. If the platform server 6 updates the ledger set 60, it sends the digest of the record appended to the ledger by the update (a verification record described later) to all client servers 3 participating in the network NW. The client server 3 stores a submission form 374 for storing the submission record. The submission form 374 is an example of the "distributed ledger" in the present disclosure.

[0167] Figure 14This is a diagram showing an example of the structure of ledger set 60. Ledger set 60 includes ledger 67 and ledger 68. Similar to the distributed ledger 51 of Embodiment 1, ledger 67 stores the update status of the component data of the first component in chronological order, forming an evidence chain of the component data of the first component. Similar to the distributed ledger 52 of Embodiment 1, ledger 68 stores the update status of the component data of the second component in chronological order, forming an evidence chain of the component data of the second component. 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 Embodiment 1 respectively. Therefore, their detailed descriptions will not be repeated.

[0168] Refer again to Figure 13 , 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, ROM 32, RAM 33, communication device 34, input device 35, display device 36, and storage device 37 are connected to a bus 39. The ROM 32, RAM 33, communication device 34, input device 35, and display device 36 basically have the same structures as the ROM 22, RAM 23, communication device 24, input device 25, and display device 26 of the client server 2 of Embodiment 1 respectively. Therefore, their descriptions will not be repeated.

[0169] 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 a certification authority (not shown) for authentication. The certification authority issues an electronic certificate containing information of 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.

[0170] The verification data 372 includes a suspension form 373 and a submission form 374. Figure 15 This is a diagram showing an example of the structure of the suspension form 373. Figure 16 This is a diagram showing an example of the structure of the submission form 374. The suspension form 373 and the submission form 374 have records for each target component.

[0171] Refer to Figure 15, the suspension table 373 contains information of a predetermined type included in unused transaction data. Specifically, the suspension table 373 stores suspension records containing information such as Key and Nonce. The control device 31 stores the Key and Nonce information in the information included in the transaction data generated in response to the first request or the second request as a suspension record in the suspension table 373. In the first request and the second request received by the client server 3 from the input device 35 or the user terminal device 7, the ID of the target component is included. For example, if the target of the first request is the first component, the ID indicating "k1" is included in the first request, and if the target of the first request is the second component, the ID indicating "k2" is included in the first request. That is, the ID of the target component included in the first request or the second request becomes the Key. In addition, if the first request or the second request is received, the control device 31 generates a random value. This random value represents the number of the first request or the second request (i.e., the number of the transaction data). The control device 31 creates a suspension record containing the Key and Nonce information and registers this suspension record in the suspension table 373. In Figure 15 , an example of registering a suspension record containing the Key of k1 in the suspension table 373 is shown. In addition, hereinafter, without particularly distinguishing between the first request and the second request, both are collectively referred to as "update request".

[0172] If the process in response to the update request is executed (i.e., if the transaction data is used), the control device 31 deletes from the suspension table 373 the suspension record containing the information with the same Key as the Key included in the transaction data used for executing the transaction process.

[0173] In the suspension table 373, suspension records containing the same Key information are not registered repeatedly. When registering a suspension record in the suspension table 373, the control device 31 determines whether there is already a suspension record in the suspension table 373 that contains a Key consistent with the Key included in the suspension record to be registered. If the control device 31 does not find a suspension record in the suspension table 373 that contains a Key consistent with the Key included in the suspension record to be registered, it registers the suspension record in the suspension table 373. If the control device 31 finds a suspension record in the suspension table 373 that contains a Key consistent with the Key included in the suspension record to be registered, it waits for the suspension record containing the consistent Key to be deleted from the suspension table 373. That is, in Figure 15 the example shown, in the suspension table 373, a suspension record containing the Key of k2 can be registered, but a suspension record containing the Key of k1 cannot be registered.

[0174] Submission Form 374 contains information of a predetermined type included in the used transaction data. Specifically, Submission Form 374 stores submission records containing information such as Key, Age, HV, and Nonce. Submission Form 374 includes submission data 375 that stores submission records with Key of k1 and submission data 376 that stores submission records with Key of k2.

[0175] If the platform server 6 performs transaction processing and updates the ledger of the ledger set 60, it creates a verification record and sends the verification record to all client servers 3 participating in the network NW. The verification record is, for example, a record composed of information such as Key, Age, HV, and Nonce included in the record appended to the ledger through the transaction processing performed using the transaction data.

[0176] If the control device 31 receives a verification record, it appends the verification record as a submission record to Submission Form 374 (submission data 375 or submission data 376). Then, the control device 31 deletes from the suspension form 373 the suspension record containing the same Key as the Key included in the appended submission record.

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

[0178] 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 and executes them. Among the various programs, there is an operating system, etc. The RAM 63 functions as a working memory and temporarily stores various data required for executing the various programs. The control device 61 receives transaction data from the client server 3 and performs transaction processing.

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

[0180] 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 enterprises that manage the client servers 3 participating in the network NW. Specifically, the plurality of public keys 651 include the public key of Enterprise A, the public key of Enterprise B, the public key of Enterprise C, and the public key of Enterprise D.

[0181] Since the ledger set 60 has the same structure as the distributed ledger set 50 of Embodiment 1 as described above, the description will not be repeated.

[0182] Next, while showing a flowchart, the processing of responses to the first request, the second request, and the third request in Embodiment 2 will be sequentially described.

[0183] Figure 17 It is a flowchart showing the order of processing executed by the data management system 1A when an update request (the first request, the second request) is received. Figure 17 The processing of the shown flowchart is started by the control device 31 of the client server 3 when an update request (the first request, the second request) is received from the input device 25 or the user terminal device 7.

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

[0185] In S41, the control device 31 of the client server 3 generates a suspension record. Specifically, the control device 31 of the client server 3 reads out the ID of the object component included in the update request and sets it as the information of Key, and sets the random value generated in S40 as the information of Nonce, and generates a suspension record.

[0186] In S42, the control device 31 of the client server 3 determines whether the suspension record generated in S41 can be registered in the suspension table 373. When there is a suspension record registered in the suspension table 373 that has the same Key information as the suspension record generated in S41, the control device 31 of the client server 3 makes a negative determination (in S42, "no") and waits for the suspension record with the same Key information to be deleted from the suspension table 373. On the other hand, when there is no suspension record registered in the suspension table 373 that has the same Key information as the suspension record generated in S41, the control device 31 of the client server 3 makes an affirmative determination (in S42, "yes") and advances the processing to S43.

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

[0188] In S44, the control device 31 of the client server 3 generates transaction data corresponding to the update request. Specifically, when the update request is the first request, the control device 31 of the client server 3 executes the same processing as the processing of S2 to S5 described in Figure 9 to generate transaction data. When the update request is the second request, the control device 31 of the client server 3 executes the same processing as the processing of S12 to S15 described in Figure 10 to generate transaction data. Regarding the detailed content of each processing, as described in Figure 9 and Figure 10As described above, the description will not be repeated.

[0189] In S45, the control device 31 of the client server 3 outputs a control signal for sending the transaction data generated in S44 to the platform server 6 to the communication device 34. Thereby, the transaction data is sent to the platform server 6 via the communication device 34.

[0190] In S50, the control device 61 of the platform server 6 decrypts the electronic signature in order to verify the validity of the electronic signature included in the received transaction data. Specifically, the control device 61 of the platform server 6 performs the same processing as the processing of S21 to S23 described in Figure 11 to decrypt the electronic signature. Regarding the details of each process, as described in Figure 11 As described above, the description will not be repeated.

[0191] In S51, the control device 61 of the platform server 6 verifies the validity of the electronic signature decrypted in S50. Specifically, the control device 61 of the platform server 6 compares the value obtained by decrypting the electronic signature with the hash value included in the transaction data (the hash value of the component data of the object component in the transaction data generated according to the first request, and the terminal hash value in the transaction data generated according to the second request). If the two do not match, the control device 61 of the platform server 6 does not recognize the validity of the electronic signature (in S51, "no"), and advances the process to S52. If the two match, the control device 61 of the platform server 6 recognizes the validity of the electronic signature (in S51, "yes"), and advances the process to S53.

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

[0193] In S53, the control device 61 of the platform server 6 performs transaction processing. Specifically, the control device 61 of the platform server 6 performs the same processing as the processing of S26 and S27 described in Figure 11 to generate a record of the ledger determined by the information of the Key included in the transaction data, append the generated record to the ledger, and update the ledger set 60.

[0194] In S54, the control device 61 of the platform server 6 generates a verification record. The verification record includes the information of Key, Age, HV, and Nonce included in the information of the record appended to the ledger.

[0195] In S55, the control device 61 of the platform server 6 creates a normal report indicating the completion of the update of the ledger set 60 (i.e., the transaction data has been processed). The control device 61 of the platform server 6 includes the verification record in the normal report.

[0196] In S56, the control device 61 of the platform server 6 outputs a control signal for sending the abnormal report created in S52 or the normal report created in S55 to the client server 3 to the communication device 64. Thereby, the abnormal report or the normal report is sent to the client server 3 via the communication device 64.

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

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

[0199] In S47, the control device 31 of the client server 3 appends the verification record included in the normal report to the submission form 374 as a submission record. Specifically, the control device 31 of the client server 3 determines whether the object of appending the submission record 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 appends the submission record to the target submission data.

[0200] In S48, the control device 31 of the client server 3 deletes the suspension record having the same Key information as the appended submission record from the suspension form 373.

[0201] In S49, the control device 31 of the client server 3, for example, causes the display device 36 to display or sends the result of the process for the update request to the user terminal device 7.

[0202] In addition, the other client servers 3 (the client servers 3 of Company B, Company C, and Company D) that receive the verification record sent in S56 also update the submission form 374 by appending the verification record to the submission form 374 in the same manner.

[0203] Figure 18 This is a flowchart showing the order of the process of obtaining a timestamp token in Embodiment 2. Figure 18 The process of the shown flowchart is executed by the control device 31 when a third request is received from the input device 35 or the user terminal device 7.

[0204] In S61, the control device 31 determines the submission data (submission data 375 or submission data 376) of the object that becomes the object for obtaining the timestamp token based on the ID of the object component included in the third request.

[0205] In S62, the control device 31 generates a hash value of the latest submission record of the submission data determined in S61.

[0206] In S63, the control device 31 outputs a control signal for sending the hash value generated in S62 to the time certification authority 8 to the communication device 34. Thus, the hash value is sent to the time certification authority 8 via the communication device 34.

[0207] In S64, the control device 31 receives a timestamp token from the time certification authority 8 via the communication device 34. Thus, it obtains proof of the existence time of the component data of the object component.

[0208] In S65, the control device 31 causes the storage device 37 to store the timestamp token obtained in S64. In addition, the control device 31 may also cause the database 4 to store the timestamp token.

[0209] In S66, the control device 21 outputs a control signal for sending the timestamp token obtained in S34 to the external server 9 to the communication device 34. Thus, the timestamp token is sent to the external server 9 via the communication device 34. Further, in order to append the timestamp token to the submission form 374, the control device 31 may also generate transaction data for including the timestamp token in the ledger set 60 and output a control signal for sending the transaction data to the platform server 6 to the communication device 34.

[0210] As described above, in the data management system 1A of Embodiment 2, the platform server 6 provides determinism for transaction data. The platform server 6 maintains a ledger set 60 including two ledgers 67 and 68. In the ledger 67, the update status of the component data of the first component is stored in time series, and in the ledger 68, the update status of the component data of the second component is stored in time series. Then, if the ledger set 60 is updated, the check record, which is the digest of the record appended to the ledger set 60, is transmitted from the platform server 6 to each client server 3, and each client server 3 appends the check record to the submission form 374 as a submission record. The submission form 374 corresponds to the distributed ledger set 50 of Embodiment 1. In the structure of the data management system 1A of Embodiment 2, if the end hash value of one ledger (for example, ledger 67) is incorporated into the record of another ledger (for example, ledger 68) and associated, the submission data as its digest are also associated with each other. Thus, similarly to Embodiment 1, it is possible to prove the sequential existence of the component data of the first component and the component data of the second component based on the submission record incorporated with the end hash value.

[0211] In addition, by having each client server 3 hold the submission form 374, the tamper resistance of the submission form 374 is improved.

[0212] In addition, the client server 3 obtains a timestamp token for the record of the submission data incorporated with the end hash value. If a timestamp token is obtained for the record incorporated with the end hash value, it is possible to obtain proof of the existence time of the component data of the first component and the component data of the second component (that is, proof that the component data existed before the time indicated by the timestamp token).

[0213] In addition, the client server 3 sends the timestamp token to the external server 9. By also having the external server 9 manage the timestamp token, the tamper resistance of the timestamp token can be improved.

[0214] [Variant Example 2]

[0215] In Embodiment 2, an example in which the submission form 374 includes a part of the information included in the ledger set 60 has been described. Specifically, each of the submission data 375 and 376 of the submission form 374 is constituted by including the information of Key, Age, HV, and Nonce among the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV respectively possessed by the ledgers 67 and 68 of the ledger set 60. However, each of the submission data 375 and 376 may also be constituted by including the same information as the ledgers 67 and 68, that is, the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. In this case, the verification record is also generated in such a way as to include the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. With the above structure, the same effect as in Embodiment 2 can also be achieved.

[0216] It should be considered that the embodiments disclosed herein are exemplary in all respects and not restrictive. The technical scope represented by this disclosure is represented by the claims rather than the description of the above embodiments, and is intended to include all changes within the meaning and scope equivalent to the claims.

Claims

1. A data management device that manages data using distributed ledger technology, wherein, the data management device includes: a storage device that stores a distributed ledger storing records including information related to the data in time series; and a control device that appends the records to the distributed ledger, the data includes first data and second data, the distributed ledger includes a first distributed ledger storing records including first information related to the first data in time series and a second distributed ledger storing records including second information related to the second data in time series, if the first data is updated at a first time point, the control device stores the record including the first information in the first distributed ledger, generates a first end value of the information including the record, and stores the record including the first end value in the second distributed ledger.

2. The data management device according to claim 1, wherein, the first end value is a hash value of the record stored in the first distributed ledger at the first time point.

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

4. The data management device according to any one of claims 1 to 3, wherein, the control device stores the record including the first end value in the second distributed ledger based on a request from a user.

5. The data management device according to any one of claims 1 to 4, wherein, it further includes a communication device configured to be able to communicate with a time certification authority, at a second time point after the first time point, the control device sends a second end value of the information of the record including the end of the second distributed ledger to the time certification authority via the communication device, and obtains a time stamp token for the second end value from the time certification authority.

6. The data management device according to claim 5, wherein, the control device obtains the time stamp token based on a request from a user.

7. A data management method, which is a data management method of a data management device that manages data using distributed ledger technology, wherein, the data management device includes: a storage device that stores a distributed ledger storing records including information related to the data in time series; and a control device that appends the records to the distributed ledger, the data includes first data and second data, the distributed ledger includes a first distributed ledger storing records including first information related to the first data in time series and a second distributed ledger storing records including second information related to the second data in time series, the data management method includes the following steps, that is, if the first data is updated at a predetermined time point, the control device stores the record including the first information in the first distributed ledger, and generates a first end value of the information including the record; and Store the record containing the first end value in the second distributed ledger.

Images