CN120077379A

CN120077379A - Data management device and data management method

Info

Publication number: CN120077379A
Application number: CN202280101160.8A
Authority: CN
Inventors: 山室直树; 深津航
Original assignee: Skyla Co ltd; Toyota Motor Corp
Current assignee: Skyla Co ltd; Toyota Motor Corp
Priority date: 2022-10-25
Filing date: 2022-10-25
Publication date: 2025-05-30
Also published as: WO2024089773A1

Abstract

If the control device (21) of the client server (2) updates the component data (D12) to the component data (D13), a record (Age[3]) containing the hash value of the component data (D13) is created in the first evidence chain (distributed ledger 51). Then, the control device (21) generates a hash value of the terminal record (Age[3]) of the first evidence chain, i.e., a terminal hash value. The control device (21) stores the generated terminal hash value in the record of the second evidence chain (distributed ledger 52), and associates the distributed ledger (51) with the distributed ledger (52).

Description

Data management device and data management method

Technical Field

The present disclosure relates to a data management apparatus and a data management method for managing data using a distributed ledger technique.

Background

Patent No. 6694204 (patent document 1) discloses a data management system that constructs a distributed ledger (asset) having a DAG (DIRECTED ACYCLIC GRAPH) structure for each Key (ID) for identifying a management object, and manages information for each ID.

Prior art literature

Patent literature

Patent document 1, patent publication 6694204

Disclosure of Invention

Problems to be solved by the invention

In the data management system disclosed in patent document 1, for example, if data of an object managed with a certain ID is updated, the data is added to an asset prepared for the certain ID. In addition, regarding the object managed with the other ID, if the data of the object managed with the other ID is updated, the data is added to the asset prepared for the other ID.

Here, it is sometimes intended to prove a sequential nature indicating which of the data stored in the asset prepared for a certain ID and the data stored in the asset prepared for other IDs exists first. For example, consider that each time a respective asset is updated, the ordering is demonstrated by taking a timestamp token for the latest asset record. However, in this case, there is a possibility that the acquisition cost of the time stamp token increases or the system load increases.

The present disclosure has been made to solve the above-described problems, and an object of the present disclosure is to enable easy verification of the sequence of data between distributed ledgers in a system having a plurality of distributed ledgers.

Means for solving the problems

(1) The data management device according to an aspect of the present disclosure is a data management device that manages data using a distributed ledger technique. The data management device includes a storage device for storing a distributed ledger in which a record including information related to data is stored in time series, and a control device for adding the record to the distributed ledger. The data includes data 1 and data 2. The distributed ledger includes a1 st distributed ledger that stores a record including 1 st information related to 1 st data in time series and a2 nd distributed ledger that stores a record including 2 nd information related to 2 nd data in time series. If the 1 st data is updated at the 1 st time point, the control device stores a record containing the 1 st information in the 1 st distributed ledger, and generates a1 st end value of the information containing the record, and stores the record containing the 1 st end value in the 2 nd distributed ledger.

According to the above configuration, at the 1 st time point, the 1 st end value is stored in the 2 nd distributed ledger. Thus, the 1 st distributed ledger is associated with the 2 nd distributed ledger with the 1 st point in time as a reference. Therefore, the presence of the 1 st data and the 2 nd data updated at the 1 st time point can be confirmed with the 1 st time point as a reference.

(2) In one embodiment, the 1 st end value is a hash value of the record stored at the 1 st distributed ledger at the 1 st point in time.

According to the above configuration, since the hash value of the record of the 1 st distributed ledger is stored in the record of the 2 nd distributed ledger, the 1 st distributed ledger and the 2 nd distributed ledger can be associated without excessively increasing the data capacity.

(3) In one embodiment, the 1 st information is a hash value of the 1 st data. The 2 nd information is a hash value of the 2 nd data.

According to the above configuration, the 1 st data and the 2 nd data can be hidden because the 1 st data hash value and the 2 nd data hash value are included in the records stored in the 1 st and 2 nd distributed ledgers.

(4) In one embodiment, the control device stores a record including the 1 st end value in the 2 nd distributed ledger based on a request from the user.

According to the above configuration, the user can associate the 1 st distributed ledger with the 2 nd distributed ledger at an arbitrary timing.

(5) In one embodiment, the data management device further includes a communication device configured to be capable of communicating with the time authentication mechanism. The control device transmits, via the communication device, the 2 nd end value including the information recorded at the end of the 2 nd distributed ledger to the time certification authority at the 2 nd time point which is the time point after the 1 st time point, and acquires the time stamp token for the 2 nd end value from the time certification authority.

According to the above configuration, after storing the record including the 1 st end value in the 2 nd distributed ledger, the timestamp token is acquired for the 2 nd end value. Thus, the sequence of the 1 st data and the 2 nd data can be verified with the 1 st time point as a reference, and the timeliness of the 1 st data and the 2 nd data can be verified with the 2 nd time point as a reference.

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

According to the above configuration, the user can acquire the time stamp token at an arbitrary timing.

(7) A data management method according to another aspect of the present disclosure is a data management method of a data management apparatus that manages data using a distributed ledger technique. The data management device includes a storage device for storing a distributed ledger in which a record including information related to data is stored in time series, and a control device for adding the record to the distributed ledger. The data includes data 1 and data 2. The distributed ledger includes a1 st distributed ledger that stores a record including 1 st information related to 1 st data in time series and a 2 nd distributed ledger that stores a record including 2 nd information related to 2 nd data in time series. The data management method includes the steps of, if the 1 st data is updated at a predetermined point in time, the control device storing a record containing the 1 st information in the 1 st distributed ledger and generating a1 st end value of the information containing the record, and storing the record containing the 1 st end value in the 2 nd distributed ledger.

Effects of the invention

According to the present disclosure, in a system having a plurality of distributed ledgers, it is possible to easily perform attestation of the sequency of data between the distributed ledgers.

Drawings

Fig. 1 is a diagram showing a schematic configuration of a data management system according to embodiment 1.

Fig. 2 is a diagram (one of them) showing an example of the structure of a distributed ledger set.

Fig. 3 is a diagram for explaining association establishment of 2 distributed ledgers.

Fig. 4 is a diagram showing an example of the structure of a distributed ledger set (second).

Fig. 5 is a functional block diagram of a control device for executing processing in response to operation 1.

Fig. 6 is a functional block diagram of a control device for executing processing in response to operation 2.

Fig. 7 is a functional block diagram of a control device for executing received transaction data.

Fig. 8 is a functional block diagram of a control device for retrieving a timestamp token.

Fig. 9 is a flowchart showing the order of processing of generating transaction data in the case of receiving the 1 st request.

Fig. 10 is a flowchart showing the order of processing of generating transaction data in the case where the 2 nd request is received.

Fig. 11 is a flowchart showing the order of processing performed in the case where transaction data is received.

Fig. 12 is a flowchart showing the order of processing of retrieving a time stamp token.

Fig. 13 is a diagram showing a schematic configuration of the data management system according to embodiment 2.

Fig. 14 is a diagram showing an example of the structure of the ledger-board set.

Fig. 15 is a diagram for explaining an example of the structure of the pause table.

Fig. 16 is a diagram for explaining an example of the structure of the commit table.

Fig. 17 is a flowchart showing the order of processing performed by the data management system in the case where an update request (1 st request, 2 nd request) is received.

Fig. 18 is a flowchart showing the procedure of the process of acquiring a time stamp token in embodiment 2.

(Symbol description)

1. 1A is a data management system, 2, 3 is a client server, 4 is a database, 5, 6 is a platform server, 7 is a user terminal device, 8 is a time authentication mechanism, 9 is an external server, 21 is a control device, 22 is a ROM, 23 is a RAM, 24 is a communication device, 25 is an input device, 26 is a display device, 27 is a storage device, 29 is a bus, 31 is a control device, 32 is a ROM, 33 is a RAM, 34 is a communication device, 35 is an input device, 36 is a display device, 37 is a storage device, 39 is a bus, 50 is a distributed account set, 51, 52 is a distributed account set, 60 is a account set, 61 is a control device, 62 is a ROM, 63 is a RAM, 64 is a communication device, 65 is a storage device, 67, 68 is a account set, 69 is a bus, 271 is a secret key, 371 is a plurality of public keys, 372 is a secret key, 372 is a verification data 373 is a table is suspended, and is a table is used, 375, 376 is a data, 210is a plurality of public keys, 2101 is a random account is a transmission part, 212 is a random account set, 212 is a transmission part, 2 is a random account number is a transmission part, 212 is a random account set, 2112 is a transmission part, and a random account number is generated, and a random account is generated 2 is a transmission part, and a random account is generated 2 is a transmission part is a master, and a master is stored, and is a master, and is stored.

Detailed Description

Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The same or corresponding portions in the drawings are denoted by the same reference numerals, and description thereof will not be repeated.

Embodiment 1

< Overall Structure of data management System >

Fig. 1 is a diagram showing a schematic configuration of a data management system 1 according to embodiment 1. The data management system 1 of embodiment 1 is a system for forming a federation network (hereinafter also simply referred to as "network") NW between a plurality of enterprises and managing data using a distributed ledger technique. The data management system 1 of embodiment 1 manages data (hereinafter also simply referred to as "component data") of components constituting a vehicle. The component data may be, for example, a specification of the component. The data managed by the data management system 1 is not limited to the data constituting the components of the vehicle, and may be various data.

Referring to fig. 1, the data management system 1 includes 4 client servers 2, a platform server 5, and a time certification Authority (TSA: TIME STAMP Authority, time stamp issuing Authority) 8. The 4 client servers 2 are servers belonging to different enterprises (e.g., a-enterprise, B-enterprise, C-enterprise, and D-enterprise) each.

The platform server 5 manages the network NW. The platform server 5 receives a participation request from each client server 2 to participate in 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 by a manager of the platform server 5 or based on a determination result of a predetermined condition. In embodiment 1, 4 client servers 2 belonging to each of a, B, C, and D enterprises participate in the network NW.

The 4 client servers 2 form a network NW and store hash values of the component data in the respective distributed ledgers. By importing the 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. In the following, the client server 2 of the a enterprise is representatively described, but the client servers of the B enterprise, the C enterprise, and the D enterprise have the same structure and function. The client server 2 corresponds to an example of the "data management device" of the present disclosure.

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 terminal having a communication function, which is lent to an employee of the a enterprise.

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 the control signal from the client server 2. For example, a user of the client server 2 (for example, an employee of the a corporation or the like) can request update of the component data by an operation of an input device 25 (described later) of the client server 2, or can request update of the component data by an operation of the 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 the control signal to the database 4.

The client server 2 generates a hash value of the component data if the component data is stored/updated to the database 4, and generates transaction data for storing the hash value in the distributed ledger. The client server 2 then transmits the generated transaction data to the client servers 2 of the other client servers 2 forming the network NW, i.e., the B-enterprise, C-enterprise, D-enterprise. The distributed ledger stores hash values of the component data in time series, forming a chain of evidence for proving the existence of the component data. In the data management system 1 according to embodiment 1, an example is described in which 4 client servers are included in the network NW, but the number of client servers 2 included in the network NW is arbitrary, and for example, the number of client servers may be lower than 4 or 5 or more.

The time certification authority 8 contains a server belonging to the certification authority that issued the time stamp token. The time certification authority issues a request based on a timestamp from the applicant (the client server 2 in embodiment 1), and issues a timestamp token. More specifically, the time certification authority transmits to the applicant a time stamp token obtained by combining time information based on a time source having traceability to the international standard time with data (a record hash value described later in embodiment 1) received from the applicant.

The client server 2 includes a control device 21, a ROM (Read Only Memory) 22, a RAM (Random Access Memory ) 23, a communication device 24, an input device 25, a display device 26, and a storage device 27. The control device 21, ROM22, RAM23, communication device 24, input device 25, display device 26, and storage device 27 are connected to a bus 29.

The control device 21 is constituted by an integrated circuit including a CPU (Central Processing Unit ), for example. The control device 21 expands and executes various programs stored in the ROM22 in the RAM 23. The various programs include an operating system and the like. The RAM23 functions as a working memory, and temporarily stores various data necessary for executing various programs. As will be described in detail later, the control device 21 has a function of updating component data recorded in the database 4, generating transaction data for updating the distributed ledger, or acquiring a time stamp token.

The communication device 24 is configured to be capable of communication with an external apparatus. The external devices include, for example, other client servers 2, user terminal apparatuses 7, time certification authorities 8, and the like. The communication between the communication device 24 and the external device is performed using the internet, a Wide Area Network (WAN), a Local Area Network (LAN), an ethernet (registered trademark) network, a public network, a private network, a wired network, a wireless network, or the like, or a combination thereof.

The input means 25 comprises an input device. The input device is, for example, a mouse, a keyboard, a touch panel, and/or other devices capable of accepting a user's operation.

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, electroluminescent) display, or other display device.

The storage device 27 is configured to include a storage medium such as a hard disk or a flash memory, for example. Storage 27 stores secret key 271, a plurality of public keys 272, and distributed ledger set 50.

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

The plurality of public keys 272 includes a public key of B corporation, a public key of C corporation, and a public key of D corporation. The control device 21 causes the storage device 27 to store the public key received from the other client server 2. The storage device 27 may store a public key of itself (a corporation).

Distributed ledger set 50 includes a plurality of distributed ledgers. The distributed ledger is prepared for each component constituting the vehicle. Fig. 2 is a diagram showing an example of the structure of distributed ledger 50. In embodiment 1, an example in which 2 members (1 st member, 2 nd member) constituting a vehicle are managed by the data management system 1 will be described. That is, the distributed ledger set 50 includes a distributed ledger 51 that stores the update state of the component data of the 1 st component in time series and becomes the evidence chain of the component data of the 1 st component, and a distributed ledger 52 that stores the update state of the component data of the 2 nd component in time series and becomes the evidence chain of the component data of the 2 nd component. Further, if the members constituting the vehicle are N (natural number of 2 or more), the distributed ledger 50 includes N distributed ledgers. Hereinafter, a component of the data managed by the distributed ledger will also be referred to as an "object component". That is, the target members in embodiment 1 are the 1 st member and the 2 nd member.

The distributed ledger 51 stores a record of hash values of component data including the 1 st component in time series. The record contains information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

Key is information indicating the ID of the target member (1 st member). The 1 st member is assigned with the ID of k 1.

Age is information indicating the generation of the record. In the first record stored in the 1 st component of the distributed ledger 51, age is 0. If the 1 st component is updated and additionally recorded, age is increased.

Obj-HV is a hash value of the component data of the 1 st component. For example, if the component data of the 1 st component registered in the database 4 is updated, a hash value of the updated component data is generated and set to Obj-HV. The hash value is a numerical value obtained as a result of hashing the component data with a hash function.

Nonces are random values representing the numbers of transaction data. That is, for example, when the component data of the 1 st component stored in the database 4 is updated, the client server 2 (the control device 21) generates a hash value of the updated component data as the number of the process stored in the distributed ledger 51. The random value is a hash value that is cryptographically less subject to collisions.

Sig is an electronic signature created using the secret key 271 of the client server 2 that sent out the transaction data. The electronic signature is produced, for example, by encrypting Obj-HV (i.e., a hash value of the component data of the 1 st component) with the secret key 271. Or the electronic signature may be created by encrypting Nonce (random value) with secret key 271, for example.

Prev-HV is the hash value of the record (parent record) of the previous generation of the latest (end) record. That is, prev-HV is the HV of the parent record.

HV is the hash value of the latest (end) record. Specifically, HV is a hash value (hereinafter also referred to as "record hash value") of recorded information (Key, age, obj-HV, nonce, sig and Prev-HV) other than HV.

For example, as shown in fig. 2, if looking at the latest (end) record (record of Age "2") of the distributed ledger 51, prev-HV of the end record is HV of the parent record (Age "1"), that is, "H2". Next, when the component data of the 1 st component is updated and the record of Age "3" is added, prev-HV of the record of Age "3" becomes "H3" which is HV of the record of Age "2". Thus, the end record becomes a construct containing the record hash value of the parent record. In other words, a linkage of records is achieved between the Prev-HV of the end record and the HV of the parent record. By doing so, distributed ledger 51 constitutes a DAG structure.

The distributed ledger 52 stores a record of hash values of component data including the 2 nd component in time series. The record contains information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV". The details thereof are the same as those of the distributed ledger 51, and therefore, description thereof will not be repeated.

The client server 2 (control device 21) updates the component data stored in the database 4, for example, if accepting 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). The transaction data includes information of "Key", "Age", "Obj-HV", "Nonce", "Sig", "Prev-HV", and "HV".

The transaction data may further include time information for broadcasting (transmitting) the transaction data to the network NW and sender information of the transaction data. The time information may be information indicating, for example, the time at which the component data of the target member is recorded in the database 4. The sender information is, for example, information indicating a corporation. In more detail, the sender information of the transaction data may be information indicating a work (a department of a corporation) that has performed an operation of transmitting the transaction data to the network NW, or information indicating a person (an employee of the corporation) that has performed an operation of transmitting the transaction data to the network NW.

< Demonstration of sequence >

Here, it is sometimes intended to prove which one of the component data of the 1 st component and the component data of the 2 nd component exists first. That is, it is sometimes desirable to prove the sequential nature of the component data of the 1 st component and the component data of the 2 nd component. As a method of proving the sequentiality, for example, consider that each time a record is added to the distributed ledger 51, 52, a time stamp token is acquired for a record hash value of the added record (end record) to certify the time when the record is added, and the sequentiality of 2 pieces of data is certified. However, in this method, each time a record is added to the distributed ledgers 51, 52, a time stamp token must be acquired, and man-hours and costs increase. In addition, the processing load consumed by the data management system 1 increases.

Therefore, in the data management system 1 of embodiment 1, it is possible to incorporate the record hash value of one distributed ledger (e.g., distributed ledger 51) into the record of another distributed ledger (e.g., distributed ledger 52). Thus, the 2 distributed ledgers 51, 52 are associated.

Fig. 3 is a diagram for explaining association establishment of 2 distributed ledgers 51 and 52. In the upper part of fig. 3, a distributed ledger 51, which is the evidence chain of the 1 st element, is schematically shown, and in the lower part of fig. 3, a distributed ledger 52, which is the evidence chain of the 2 nd element, is schematically shown. Hereinafter, the evidence strand of the 1 st element is also referred to as "1 st evidence strand", and the evidence strand of the 2 nd element is also referred to as "2 nd evidence strand".

In the 1 st evidence chain (distributed ledger 51), hash values of component data of the 1 st component are stored in time series. If the component data of the 1 st component is first registered in the database 4, 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 1 st 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 1 st 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.

In the 2 nd evidence chain (distributed ledger 52), hash values of the component data of the 2 nd component are stored in time series. If the component data of the 2 nd component is first registered in the database 4, 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 2 nd 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 2 nd 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.

Here, as described above, it is assumed that the record of Age "2" is the latest (end) record in the distributed ledger 51 and the distributed ledger 52, respectively. Then, it is assumed that in this state, the 1 st operation of updating the component data of the 1 st component is performed on the input device 25 or the user terminal device 7. Further, it is assumed that the input device 25 or the user terminal device 7 is subjected to the 2 nd operation of associating the 1 st evidence chain with the 2 nd evidence chain in addition to the 1 st operation. The operation (1 st operation) for updating the component data may be, for example, an operation of inputting the ID (Key) of the target component on the display screen of the display device 26 or the user terminal device 7 and selecting the displayed update button. In addition, the operation (operation 2) of associating evidence chains with each other may be an operation of inputting IDs (keys) of 2 object members and selecting a displayed association button. In the display screen for performing the 2 nd operation, for example, a "production object input field" for inputting an ID (Key) of an object member to be produced as a record hash value and a "merging object input field" for inputting an ID (Key) of an object member to be merged as a record hash value are provided. For example, if k1 is input to the production object input field and k2 is input to the merge object input field, the record hash value of the 1 st evidence chain (distributed ledger 51) is merged into the record of the 2 nd evidence chain (distributed ledger 52). Here, it is assumed that k1 is input to the production object input field, and k2 is input to the integration object input field. The display screen for performing the 1 st operation and the display screen for performing the 2 nd operation may be displayed in the same screen at the same time.

Referring to fig. 2 and 3, if 2 operations of the 1 st operation and the 2 nd operation are performed, the control device 21 first updates the component data D12 of the 1 st component stored in the database 4 to the component data D13 in response to the 1 st operation. In the case where the 1 st component data D10 is stored in the database 4 for the first time, the control device 21 may cause the database 4 to newly store the 1 st component data. 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 the record in the distributed ledger 51. Further, control device 21 generates transaction data for appending the record of Age "3" to distributed ledger 51. The control device 21 transmits the generated transaction data to the client servers 2 of the B-enterprise, the C-enterprise, and the D-enterprise via the communication device 24. By performing a transaction process for executing the transaction data by each client server 2, a record of Age "3" is stored in the distributed ledger 51 of each client server 2.

Next, in response to the 2 nd operation, the control device 21 generates a hash value of the end record (Age "3") of the distributed ledger 51 as "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") including the generated end hash value and the record hash value of the parent record (Age "2") of the distributed ledger 52, and stores the record hash value in the distributed ledger 52. Distributed ledger 51 is associated with distributed ledger 52 by incorporating the end hash value of distributed ledger 51 into the record of distributed ledger 52 (Age "3"). In addition, control device 21 generates transaction data for appending the record of Age "3" to distributed ledger 52. The control device 21 transmits the generated transaction data to the client servers 2 of the B-enterprise, the C-enterprise, and the D-enterprise via the communication device 24. By performing a transaction for executing the transaction data by each client server 2, distributed ledgers 51 and 52 are associated with each other in distributed ledger set 50 of each client server 2.

If an example of the construction of a particular distributed ledger 52 is shown, it is shown in FIG. 4. Fig. 4 is a diagram showing an example of the structure of distributed ledger 50. The record of Age "3" of the distributed ledger 52 contains the hash value Hc and the hash value H4 as Pre-HV. The hash value Hc is a record hash value of the parent record (Age "2"), and the hash value H4 is a record hash value (end hash value) of the record (Age "3") of the distributed ledger 51.

As described above, by incorporating the end hash value of distributed ledger 51 into the recorded Pre-HV of distributed ledger 52, distributed ledger 51 is associated with distributed ledger 52 (the 1 st evidence chain is associated with the 2 nd evidence chain). This can prove the sequential nature of the component data of the 1 st component and the component data of the 2 nd component. Referring to fig. 3, for example, it can be demonstrated that the component data D13 of the 1 st component is registered to the database 4 after registering the component data D22 of the 2 nd component to the database 4 and before registering the component data D23 of the 2 nd component to the database 4.

Further, if the time stamp token is acquired for the record hash value of Age "3" of the distributed ledger 52, it can be verified that the component data D10 to D13 of the 1 st component and the component data D20 to D22 of the 2 nd component exist at the time verified by the time stamp token. The man-hour, the cost, the system load, and the like can be reduced as compared with the case where the time stamp tokens are acquired for the records of the distributed ledgers 51 and 52. That is, if the timestamp token is acquired 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, the existence order and timeliness of the component data of the 1 st component and the component data of the 2 nd component can be ensured.

In addition, in the case where the component data of the 1 st component is further updated to D13 to D14, a record (Age "4") containing the hash value of the component data D14 and the record hash value of Age "3" of the distributed ledger 51 is added to the distributed ledger 51. Similarly, in the case where the component data of the 2 nd component is further updated to D22 to D23, a record (Age "4") containing the hash value of the component data D23 and the record hash value of Age "3" of the distributed ledger 52 is added to the distributed ledger 52.

< Functional Module >

Fig. 5 is a functional block diagram of the control device 21 for executing processing in response to the 1 st operation. Referring to fig. 5, the control device 21 includes an information acquisition unit 2101, a hash generation unit 2102, a random number generation unit 2103, an electronic signature unit 2104, a transaction data generation unit 2105, and a transaction data transmission unit 2106. The control device 21 functions as 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 by executing a program stored in the ROM22, for example. 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 be implemented by dedicated hardware (electronic circuits), for example.

If the 1 st operation of updating the component data of the 1 st 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 a1 st request indicating that the 1 st operation is performed.

The information acquisition unit 2101 acquires the 1 st request from the input device 25 or the user terminal device 7. For example, if the user of the client server 2 operates the input device 25 to save (register/update) the component data of the target component in the database 4, the 1 st request is input to the information acquisition unit 2101. The 1 st request includes an ID (Key) for specifying the target member. When the 1 st request is acquired, the information acquisition unit 2101 outputs the 1 st request to the hash generation unit 2102 and the random number generation unit 2103.

The hash generation unit 2102, upon receiving the 1 st request, reads out the component data of the target component from the database 4, for example, and generates a hash value of the component data. The hash generation section 2102 outputs the generated hash value and the ID of the target member to the electronic signature section 2104 and the transaction data generation section 2105.

The random number generation unit 2103 generates a random number if it receives the 1 st request. The random value is a hash value that is cryptographically less subject to collisions. The random number generation unit 2103 outputs the generated random number and the ID of the target member to the transaction data generation unit 2105. In the case where the random number is used to create an electronic signature, the random number generation unit 2103 may output the random number and the ID of the target member to the electronic signature unit 2104.

The electronic signature unit 2104 reads the secret key 271 from the storage device 27. The electronic signature unit 2104 encrypts the hash value received from the hash generation unit 2102 with the secret key 271 to create an electronic signature. The electronic signature unit 2104 outputs the generated electronic signature and the ID of the target member to the transaction data generation unit 2105. The electronic signature unit 2104 may encrypt the random number received from the random number generation unit 2103 with the secret key 271 to create an electronic signature. The electronic signature unit 2104 may encrypt the hash value and the random number value with the secret key 271 to create an electronic signature.

The transaction data generation unit 2105 generates transaction data for transmission to the network NW. For example, the transaction data generation unit 2105 generates transaction data including Key, age, obj-HV, nonce, sig, prev-HV and HV information. The transaction data generation unit 2105 checks Key in the distributed ledger set 50 to identify the Age of the parent record, and increases the Age of the parent record to be the Age of the record to be added. The transaction data generating unit 2105 sets the hash value generated by the hash generating unit 2102 to Obj-HV, the random value generated by the random number generating unit 2103 to Nonce, and the electronic signature generated by the electronic signature unit 2104 to Sig. The transaction data generation unit 2105 sets the record hash value of the parent record to Prev-HV. The transaction data generation unit 2105 hashes Key, age, obj-HV, nonce, sig and the information of Prev-HV, and sets the result as HV. The transaction data may further include time information for broadcasting (transmitting) the transaction data to the network NW and sender information of the transaction data. The transaction data generation unit 2105 outputs the generated transaction data to the transaction data transmission unit 2106.

The transaction data transmitting unit 2106 outputs a control signal for transmitting transaction data to the network NW to the communication device 24. Thereby, the transaction data is transmitted to the network NW via the communication device 24.

Fig. 6 is a functional block diagram of the control device 21 for executing processing in response to the 2 nd operation. Referring to fig. 6, the control device 21 includes an information acquisition unit 2111, an end 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 transmission unit 2116. The control device 21 functions as an information acquisition unit 2111, an end 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 transmission unit 2116 by executing programs stored in the ROM22, for example. 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 transmission unit 2116 may be realized by dedicated hardware (electronic circuit), for example.

If the input device 25 or the user terminal device 7 is subjected to the 2 nd operation of associating the 1 st evidence chain (distributed ledger 51) with the 2 nd evidence chain (distributed ledger 52), the input device 25 or the user terminal device 7 outputs the 2 nd request indicating that the 2 nd operation is performed.

The information acquisition unit 2111 acquires the 2 nd 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, selects an association establishment button (if the 2 nd operation is performed) that associates evidence chains with each other in addition to the 1 st operation, the 2 nd request is input to the information acquisition section 2111. The 2 nd request includes an ID (for example, k 1) of the target member to be the generation target of the end hash value and an ID (for example, k 2) of the target member to be the incorporation target of the end hash value. When the information acquisition unit 2111 acquires the 2 nd request, the 2 nd request is output to the terminal hash generation unit 2112 and the random number generation unit 2113.

The end hash generation unit 2112 generates, as an end hash value, a hash value of the latest record (record at the end of the evidence chain) of the distributed ledger (for example, the distributed ledger 51) specified by the ID of the target member to be the production target of the end hash value. The end hash generation section 2112 outputs the generated end hash value and the ID (for example, k 2) of the target member that becomes the incorporation target of the end hash value to the electronic signature section 2114 and the transaction data generation section 2115.

The random number generation unit 2113 generates a random number if the 2 nd request is received. The random number generation unit 2113 outputs the generated random number value and the ID (for example, k 2) of the target member to be the incorporation target of the end hash value to the transaction data generation unit 2115. In the case where the random number is used to create the electronic signature, the random number generation unit 2113 may output the random number and the ID (for example, k 2) of the target member to be the destination of the terminal hash value to the electronic signature unit 2114.

The electronic signature unit 2114 reads the secret key 271 from the storage device 27. The electronic signature section 2114 generates an electronic signature by encrypting the terminal hash value received from the terminal hash generation section 2112 with the secret key 271. The electronic signature unit 2114 outputs the generated electronic signature and the ID (for example, k 2) of the target member to be the target of the incorporation of the end hash value to the transaction data generation unit 2115. The electronic signature unit 2114 may encrypt the random number received from the random number generation unit 2113 with the secret key 271 to create an electronic signature. The electronic signature unit 2114 may encrypt the terminal hash value and the random number value with the secret key 271 to create an electronic signature.

The transaction data generation unit 2115 generates transaction data for transmission to the network NW. For example, the transaction data generation unit 2115 generates transaction data including Key, age, obj-HV, nonce, sig, prev-HV and HV information. The transaction data generation unit 2115 sets the ID (for example, k 2) of the target member to be the incorporation target of the end hash value as the Key. The transaction data generation unit 2115 sets the end hash value generated by the end hash generation unit 2112 to Obj-HV. The other functions of the transaction data generation unit 2115 are substantially the same as those of the transaction data generation unit 2105 described with reference to fig. 5.

The transaction data transmitting unit 2116 outputs a control signal for transmitting the transaction data to the network NW to the communication device 24. Thereby, the transaction data is transmitted to the network NW via the communication device 24.

Fig. 7 is a functional block diagram of the control device 21 for executing the received transaction data. Referring to fig. 7, control device 21 includes transaction data acquisition unit 2121, signature verification unit 2122, record creation unit 2123, ledger update unit 2124, and output unit 2125. The control device 21 functions as a transaction data acquisition unit 2121, a signature verification unit 2122, a record creation unit 2123, a ledger update unit 2124, and an output unit 2125 by executing a program stored in the ROM22, for example. The transaction data acquisition unit 2121, the signature verification unit 2122, the record creation unit 2123, the ledger update unit 2124, and the output unit 2125 may be realized by dedicated hardware (electronic circuit), for example.

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

The signature verification unit 2122 verifies the validity of the electronic signature (Sig) included in the transaction data. First, the signature verification unit 2122 identifies the client server 2 that is the transmission source of the transaction data based on the sender information included in the transaction data. Then, the signature verification unit 2122 reads out the determined public key (1 of the plurality of public keys 272) of the client server 2 from the storage device 27. The signature verification unit 2122 decrypts the electronic signature included in the transaction data by 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 with the secret key of the client server 2 as the transmission source. The signature verification unit 2122 compares the decrypted value with Obj-HV (hash value or end hash value) included in the transaction data. By confirming that the two match, the signature verification unit 2122 recognizes the validity of the electronic signature.

When the validity of the electronic signature is confirmed, the record creation unit 2123 creates a record added to the distributed ledger set 50 based on the transaction data. The record creating unit 2123 reads Key, age, obj-HV, nonce, sig, prev-HV and HV information from the transaction data, and creates a record including these information.

Ledger update unit 2124 adds the record created by record creation unit 2123 to distributed ledger set 50, and updates distributed ledger set 50. Specifically, ledger update unit 2124 refers to the Key of the created record and determines the distributed ledger to which the record is added. For example, the transaction data generated according to the 1 st operation of updating the 1 st component data described above has "k1" indicating the ID of the 1 st component as the Key. A record made based on the transaction data also has "k1" as a Key. Therefore, ledger update unit 2124 adds this record to distributed ledger 51, which is a chain of evidence of component data of 1 st component. In addition, the transaction data generated from the 2 nd operation of associating the 1 st evidence chain with the 2 nd evidence chain described above has "k2" indicating the ID of the 2 nd component as a Key. A record made based on the transaction data also has "k2" as a Key. Therefore, ledger update unit 2124 adds this record to distributed ledger 52, which is a chain of evidence of component data of component 2.

If the update of distributed ledger 50 is completed, ledger update unit 2124 outputs the result to output unit 2125.

The output unit 2125 outputs a control signal for transmitting a case where processing (transaction processing) of executing transaction data is completed to the client server 2 which is a transmission source of the transaction data, to the communication device 24. Thereby, the report of the completion of the transaction is transmitted to the client server 2 as the transmission source of the transaction data via the communication device 24.

Fig. 8 is a functional block diagram of the control device 21 for acquiring the time stamp token. Referring to fig. 8, the control device 21 includes an information acquisition unit 2131, a record hash generation unit 2132, a timestamp token acquisition unit 2133, and an output unit 2134. The control device 21 functions as an information acquisition unit 2131, a record hash generation unit 2132, a timestamp token acquisition unit 2133, and an output unit 2134 by executing a program stored in the ROM22, for example. The information acquisition unit 2131, the record hash generation unit 2132, the timestamp token acquisition unit 2133, and the output unit 2134 may be implemented by dedicated hardware (electronic circuit), for example.

If the input device 25 or the user terminal device 7 is subjected to the 3 rd operation requesting the acquisition of the time stamp token, the input device 25 or the user terminal device 7 outputs the 3 rd request indicating that the 3 rd operation is performed.

The information acquiring unit 2131 acquires the 3 rd 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, the ID of the object for acquiring the time stamp token is input on the display screen of the display device 26, and the time stamp token acquisition button displayed on the display device 26 is selected (if the 3 rd operation is performed), the 3 rd request is input to the information acquisition unit 2131. In the 3 rd request, an ID (Key) for specifying the target member is included. If the information acquisition unit 2131 acquires the 3 rd request, it outputs the 3 rd request to the record hash generation unit 2132.

The record hash generation unit 2132 identifies the ID of the target component from the 3 rd request, and identifies the distributed ledger to which the time stamp token (the record hash value is generated) is to be acquired. For example, when the 3 rd request includes "k2" which is the ID of the 2 nd component, the record hash generation unit 2132 generates a record hash value of the latest record (end record) of the distributed ledger 52. The record hash generation unit 2132 outputs the generated record hash value to the timestamp token acquisition unit 2133.

The time stamp token obtaining unit 2133 outputs a control signal for transmitting the record hash value received from the record hash generation unit 2132 to the time authentication mechanism 8 to the communication device 24. Thereby, the record hash value is transmitted to the time certification authority 8 via the communication device 24.

The time of day certification authority 8, having received the record hash value, sends the time stamp token back to the client server 2.

The time stamp token obtaining unit 2133 receives the time stamp token from the time certification authority 8 via the communication device 24. The time stamp token obtaining unit 2133 outputs the obtained time stamp token to the output unit 2134.

The output unit 2134 causes the storage device 27 to store the time stamp tokens received from the time stamp token obtaining unit 2133. Alternatively, the output unit 2134 may cause the database 4 to store the time stamp tokens received from the time stamp token obtaining unit 2133. This makes it possible to obtain proof of the presence time.

The output unit 2134 may cause the distributed ledger 50 to hold the timestamp tokens received from the timestamp token acquisition unit 2133. For example, if a timestamp token is obtained for the record hash value of the distributed ledger 52, the output unit 2134 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 being Obj-HV, and outputs a control signal for transmitting the transaction data to the client server 2 participating in the network NW to the communication device 24. Thereby, the time stamp token is appended to the distributed ledger set 50 of each client server 2.

The output unit 2134 may output a control signal for transmitting the time stamp token received from the time stamp token obtaining 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 the a enterprise, the B enterprise, the C enterprise, and the D enterprise. In order to tamper with the time stamp token, the time stamp token managed by the external server 9 must also be tampered with. By further managing the time stamp token by the external server 9, tamper resistance of the time stamp token can be improved.

< Flow sheet >

Fig. 9 is a flowchart showing the order of processing of generating transaction data in the case of receiving the 1 st request. The processing of the flowchart shown in fig. 9 is executed by the control device 21 upon receiving the 1 st request from the input device 25 or the user terminal device 7. Note that, although the steps of the flowcharts shown in fig. 9 and fig. 10, 11, and 12 described later (hereinafter, the steps are abbreviated as "S") are described as being implemented by a software process executed by the control device 21, a part or all of the steps may be implemented by hardware (electronic circuit) manufactured in the control device 21.

In S1, the control device 21 generates a random number. The random number is used as the number of the transaction data.

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

In S3, the control device 21 reads the secret key 271 from the storage device 27, and encrypts the hash value generated in S2 using the secret key 271 to create an electronic signature. The control device 21 may encrypt the random number generated in S1 by using the secret key 271 to create an electronic signature. The control device 21 may encrypt the hash value generated in S2 and the random number generated in S1 by using the secret key 271 to create an electronic signature.

In S4, the control device 21 generates transaction data containing Key, age, obj-HV, nonce, sig, prev-HV and HV information. Specifically, the control device 21 sets the ID of the target member included in the 1 st request as Key. 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. In addition, control device 21 checks Key in distributed ledger set 50 to identify the Age of the parent record, and sets the Age obtained by adding the Age of the parent record as the Age. The control device 21 also sets the record hash of the parent record to Prev-HV. The control device 21 hashes Key, age, obj-HV, nonce, sig and Prev-HV information other than HV information, and sets the hashed information as HV. The control device 21 may include time information for broadcasting the transaction data to the network NW and/or sender information of the transaction data in the transaction data.

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

Fig. 10 is a flowchart showing the order of processing of generating transaction data in the case where the 2 nd request is received. The processing of the flowchart shown in fig. 10 is executed by the control device 21 upon receiving the 2 nd request from the input device 25 or the user terminal device 7.

In S11, the control device 21 generates a random number. The random number is used as the number of the transaction data.

In S12, the control device 21 hashes the latest record of the distributed ledger (the end record of the evidence chain), and creates an end hash value. As described above, in the display screen for performing the 2 nd operation, the "production object input field" for inputting the ID of the object member to be the production object of the end hash value and the "merging object input field" for inputting the ID of the object member to be the merging target of the end hash value are provided. For example, when k1 is input to the creation target input field and k2 is input to the integration target input field, the control device 21 hashes the latest record of the distributed ledger 51 and creates the end hash value.

In S13, the control device 21 reads the secret key 271 from the storage device 27, encrypts the terminal hash value generated in S12 using the secret key 271, and creates an electronic signature. The control device 21 may encrypt the random number generated in S11 by using the secret key 271 to create an electronic signature. The control device 21 may encrypt the terminal hash value generated in S12 and the random number generated in S11 by using the secret key 271 to create an electronic signature.

In S14, the control device 21 generates transaction data containing Key, age, obj-HV, nonce, sig, prev-HV and HV information. The control device 21 sets the ID (k 2 in the above example) input to the "merge object input field" as the Key. The control device 21 sets the end hash value generated in S12 to Obj-HV. The other processing in S14 is basically the same as the processing in S4 of fig. 9, and therefore, description thereof will not be repeated.

In S15, the control device 21 outputs a control signal for transmitting the transaction data generated in S14 to the network NW to the communication device 24. Thereby, the transaction data is transmitted to the network NW via the communication device 24.

Fig. 11 is a flowchart showing the order of processing performed in the case where transaction data is received. The processing of the flowchart shown in fig. 11 is executed by the control device 21 when transaction data is received.

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

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

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

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

In S25, the control device 21 discards the transaction data received this time because the electronic signature is not valid, and ends the process. The control device 21 may cause the display device 26 to display that there is a possibility that the transaction data has been tampered with.

In S26, the control device 21 reads Key, age, obj-HV, nonce, sig, prev-HV and HV information from the received transaction data, and creates a record containing these information.

In S27, control device 21 determines a distributed ledger to which the record is added, based on the Key of the record created in S26. Then, the control device 21 appends the record to the determined distributed ledger. Thereby, distributed ledger collection 50 is updated.

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

Fig. 12 is a flowchart showing the order of processing of retrieving a time stamp token. The processing of the flowchart shown in fig. 12 is executed by the control device 21 upon receiving the 3 rd request from the input device 25 or the user terminal device 7.

In S31, control device 21 determines a distributed ledger (distributed ledger 51 or distributed ledger 52) to be the object of acquiring the time stamp token based on the ID of the object component included in the 3 rd request.

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

In S33, the control device 21 outputs a control signal for transmitting the record hash value generated in S32 to the time authentication mechanism 8 to the communication device 24. Thereby, the record hash value is transmitted to the time certification authority 8 via the communication device 24.

In S34, the control device 21 receives the time stamp token from the time certification authority 8 via the communication device 24. Thereby, the proof of the existence time of the member data of the target member is obtained.

In S35, the control device 21 causes the storage device 27 to store the time stamp token acquired in S34. The control device 21 may cause the database 4 to store the time stamp token. Further, control device 21 may cause distributed ledger set 50 to hold a timestamp token.

In S36, the control device 21 outputs a control signal for transmitting the time stamp token acquired in S34 to the external server 9 to the communication device 24. Thereby, the time stamp token is sent to the external server 9 via the communication means 24. Further, control device 21 may generate transaction data for appending a time stamp token to distributed ledger set 50, and output a control signal for transmitting the transaction data to network NW to communication device 24.

As described above, in the data management system 1 of embodiment 1, the client server 2 holds the distributed ledger set 50 including 2 distributed ledgers 51, 52. The distributed ledger 51 is a chain of evidence for proving the presence of the component data of the 1 st component, and the distributed ledger 52 is a chain of evidence for proving the presence of the component data of the 2 nd component. The client server 2 has a function of associating the 2 distributed ledgers 51 and 52 according to a request from a user. Client server 2 incorporates the end hash value of one distributed ledger into the record of another distributed ledger. The existence of the component data of the 1 st component and the component data of the 2 nd component can be verified with the record incorporating the end hash value as a reference.

In addition, the client server 2 retrieves a timestamp token for the record incorporating the end hash value. If the time stamp token is acquired for a record incorporating the end hash value, a proof of the existence time of the component data of the 1 st component and the component data of the 2 nd component (i.e., a proof that the component data already exists before the time indicated by the time stamp token) can be acquired. If the time stamp token is acquired for the record incorporating the end hash value, man-hours, cost and system load can be reduced as compared with the case where the time stamp tokens are acquired for the distributed ledgers 51, 52, respectively.

In addition, the client server 2 transmits the time stamp token to the external server 9. By further managing the time stamp token by the external server 9, tamper resistance of the time stamp token can be improved.

Modification 1

In embodiment 1, an example in which association of 2 evidence links is performed in response to the 2 nd request generated by the user operation (2 nd operation) has been described, but association of 2 evidence links may be performed automatically. For example, each time the update of the component data of the object component is performed M (natural number) times, the end hash value of the evidence chain (distributed ledger) of the object component may be incorporated into the record of the other evidence chain (distributed ledger). Even with such a configuration, the same effects as those of embodiment 1 can be obtained.

Embodiment 2

In embodiment 1, an example is described in which the platform server 5 has a function of permitting participation in the network NW. The certainty of the transaction data is then provided by confirming the validity of the electronic signature between the client servers 2 that have been licensed to participate in the network NW. In embodiment 2, an example will be described in which the platform server 6 has a function of providing certainty to transaction data in addition to a function of permitting reference to the network NW.

Fig. 13 is a diagram showing a schematic configuration of a data management system 1A according to embodiment 2. The data management system 1A includes 4 client servers 3, a platform server 6, and a time certification authority 8. As in embodiment 1, the 4 client servers 3 are servers belonging to different enterprises (for example, a-enterprise, B-enterprise, C-enterprise, and D-enterprise). In the following, the client server 3 of the a enterprise is representatively described, but the client servers 3 of the B enterprise, the C enterprise, and the D enterprise also have the same function.

The platform server 6 manages the network NW in the same manner as the platform server 5 of embodiment 1, and receives a participation request from each client server 3 to the network NW. The platform server 6 permits the client server 3 to participate in the network NW based on an operation of permitting participation by a manager of the platform server 6 or based on a determination result of a predetermined condition. In embodiment 2, perhaps 4 client servers 3 belonging to a, B, C, and D enterprises respectively participate in the network NW.

The 4 client servers 3 and the platform server 6 form a network NW. By importing the distributed ledger-based software into each client server 3, the imported distributed ledger-based software functions, 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, similarly to the client server 2 of embodiment 1.

In addition, the database 4 is connected to the client server 3 in the same manner as the client server 2 of embodiment 1. The client server 3 (control device 31) generates a control signal for storing/updating the component data according to an input to the input device 35 or a request from the user terminal device 7 and outputs the control signal to the database 4.

If the client server 3 stores and updates the component data in the database 4, a hash value of the component data is created, and transaction data for storing the hash value in the ledger held by the platform server 6 and the distributed ledger held by each client server 3 is generated. The client server 3 then transmits the generated transaction data to the platform server 6.

The platform server 6 has a function of providing certainty to the transaction data. The platform server 6 holds the ledger 60, processes the transaction data received from the client server 3, and updates the ledger 60. If the platform server 6 updates the ledger set 60, a digest of the record added to the ledger by the update (a check record described later) is transmitted to all the client servers 3 that are participating in the network NW. The client server 3 stores a commit table 374 storing commit records. Commit table 374 corresponds to an example of a "distributed ledger" of the present disclosure.

Fig. 14 is a diagram showing an example of the structure of ledger 60. Ledger set 60 includes ledger 67 and ledger 68. Like the distributed ledger 51 of embodiment 1, the ledger 67 stores the update status of the component data of the 1 st component in time series, and forms a proof chain of the component data of the 1 st component. Like the distributed ledger 52 of embodiment 1, the ledger 68 stores the update status of the component data of the 2 nd component in time series, and forms a proof chain of the component data of the 2 nd component. Ledger 60, ledger 67, and ledger 68 have the same structures as distributed ledger 50, distributed ledger 51, and distributed ledger 52 of embodiment 1, respectively. Therefore, their detailed description is not repeated.

Referring again to fig. 13, the client server 3 includes a control device 31, a ROM32, a RAM33, a communication device 34, an input device 35, a display device 36, and a storage device 37. The control device 31, ROM32, RAM33, communication device 34, input device 35, display device 36, and storage device 37 are connected to a bus 39. The ROM32, RAM33, communication device 34, input device 35, and display device 36 are basically the same as the ROM22, RAM23, communication device 24, input device 25, and display device 26 of the client server 2 of embodiment 1, and therefore, the description thereof will not be repeated.

The storage means 37 stores a secret key 371 and verification data 372. Secret key 371 is the secret key of enterprise 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 transmits the generated public key to a certification authority (not shown), and accepts certification. The certification authority issues an electronic certificate containing information of the public key. The control device 31 causes the storage device 37 to store a secret key 371 corresponding to the authenticated public key. Further, the control device 31 transmits the authenticated public key 651 (electronic certificate) to the platform server 6.

The check data 372 contains a pause table 373 and a commit table 374. Fig. 15 is a diagram for explaining an example of the structure of the pause table 373. Fig. 16 is a diagram for explaining an example of the structure of the commit table 374. The pause table 373 and the submit table 374 have records for each object member.

Referring to fig. 15, the suspension table 373 contains predetermined kinds of information contained in unused transaction data. Specifically, the pause table 373 stores pause records containing information of Key and Nonce, for example. The control device 31 stores information of Key and Nonce in the information included in the transaction data generated in response to the 1 st request or the 2 nd request as a suspension record in the suspension table 373. The 1 st request and the 2 nd request received from the input device 35 or the user terminal device 7 by the client server 3 include the ID of the target component. For example, if the object of the 1 st request is the 1 st component, an ID indicating "k1" is included in the 1 st request, and if the object of the 1 st request is the 2 nd component, an ID indicating "k2" is included in the 1 st request. That is, the ID of the target member included in the 1 st request or the 2 nd request becomes Key. In addition, if the 1 st request or the 2 nd request is received, the control device 31 generates a random number value. The random number value represents the number of the 1 st request or the 2 nd request (i.e., the number of the transaction data). The control device 31 creates a pause record containing Key and Nonce information, and registers the pause record in the pause table 373. Fig. 15 shows an example in which a pause record including the Key of k1 is registered in the pause table 373. In the following, the 1 st request and the 2 nd request are collectively referred to as "update requests" unless they are distinguished.

If processing in response to the update request is performed (i.e., if the transaction data is used), the control device 31 deletes the suspension record containing information of the same Key as that contained in the transaction data for executing the transaction from the suspension table 373.

In the pause table 373, pause records containing information of the same Key are not repeatedly registered. When registering the pause record to the pause table 373, the control apparatus 31 determines whether or not a pause record containing a Key that coincides with a Key contained in the pause record that is the registration target has been registered in the pause table 373. The control device 31 registers the pause record to the pause table 373 if the pause record containing the Key that coincides with the Key contained in the pause record that is the registration target is not registered in the pause table 373. If a pause record containing a Key that matches a Key contained in a pause record that is a registration target is registered in the pause table 373, the control apparatus 31 waits for deletion of the pause record containing the matching Key from the pause table 373. That is, in the example shown in fig. 15, in the pause table 373, a pause record including the Key of k2 can be registered, but a pause record including the Key of k1 cannot be registered.

Commit table 374 contains a predetermined category of information contained in the transaction data that has been used. Specifically, commit table 374 stores commit records containing information of Key, age, HV and nonces. Commit table 374 contains commit data 375 storing commit records with keys of k1 and commit data 376 storing commit records with keys of k 2.

If the platform server 6 performs a transaction, updates the ledger of the ledger set 60, creates a check record and sends the check record to all client servers 3 that are participating in the network NW. The check record is, for example, a record formed by adding information including Key, age, HV and nonces to a record of the ledger by a transaction process performed using the transaction data.

If a check record is received, control device 31 appends the check record to commit table 374 (commit data 375 or commit data 376) as a commit record. Then, the control device 31 deletes the suspended record containing the same Key as the Key contained in the additional commit record from the suspended table 373.

The platform server 6 includes a control device 61, a ROM62, a RAM63, a communication device 64, and a storage device 65. The control device 61, ROM62, RAM63, communication device 64, and storage device 65 are connected to a bus 69.

The control device 61 is constituted by an integrated circuit including a CPU. The control device 61 expands and executes various programs stored in the ROM62 in the RAM 63. The various programs include an operating system and the like. The RAM63 functions as a working memory, and temporarily stores various data necessary for executing various programs. The control device 61 receives transaction data from the client server 3 and performs a transaction process.

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

Storage device 65 stores a plurality of public keys 651 and ledger sets 60. The plurality of public keys 651 contain public keys that manage enterprises of the client servers 3 participating in the network NW. Specifically, the plurality of public keys 651 includes a public key of a corporation, a public key of B corporation, a public key of C corporation, and a public key of D corporation.

Since ledger 60 has the same configuration as distributed ledger 50 of embodiment 1 as described above, description thereof will not be repeated.

Next, processing of responses to the 1 st request, the 2 nd request, and the 3 rd request in embodiment 2 will be described in order while showing a flowchart.

Fig. 17 is a flowchart showing the order of processing performed by the data management system 1A in the case of receiving an update request (1 st request, 2 nd request). The processing of the flowchart shown in fig. 17 is started by the control device 31 of the client server 3 upon receiving an update request (1 st request, 2 nd request) from the input device 25 or the user terminal device 7.

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

In S41, the control device 31 of the client server 3 generates a pause record. Specifically, the control device 31 of the client server 3 reads out the information in which the ID of the target member included in the update request is set as Key, sets the random number generated in S40 as Nonce, and generates the pause record.

In S42, the control device 31 of the client server 3 determines whether or not the pause record generated in S41 can be registered in the pause table 373. When a pause record having the same Key as the pause record generated in S41 is registered in the pause table 373, the control device 31 of the client server 3 makes a negative determination (no in S42) awaiting deletion of the pause record having the same Key as the information from the pause table 373. On the other hand, when the pause record having the information of the same Key as the pause record generated in S41 is not registered in the pause table 373, the control device 31 of the client server 3 makes an affirmative determination (yes in S42), and advances the process to S43.

In S43, the control device 31 of the client server 3 registers the pause record to the pause table 373.

In S44, the control device 31 of the client server 3 generates transaction data for use in response to the update request. Specifically, the control device 31 of the client server 3 generates the transaction data by executing the same processing as the processing of S2 to S5 described in fig. 9 when the update request is the 1 st request, and generates the transaction data by executing the same processing as the processing of S12 to S15 described in fig. 10 when the update request is the 2 nd request. The details of each process are as already described in fig. 9 and 10, and therefore, the description thereof will not be repeated.

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

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 executes the same processing as the processing S21 to S23 described in fig. 11, and decrypts the electronic signature. The details of each process are as already described in fig. 11, and therefore, the description thereof will not be repeated.

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 member data of the target member in the transaction data generated in accordance with the 1 st request, and the end hash value in the transaction data generated in accordance with the 2 nd request). If the two do not match, the control device 61 of the platform server 6 does not recognize the validity of the electronic signature (no in S51), and the process proceeds to S52. If the two match, the control device 61 of the platform server 6 recognizes the validity of the electronic signature (yes in S51), and advances the process to S53.

In S52, the control device 61 of the platform server 6 determines that there is a possibility of tampering with the transaction data received from the client server 3, discards the transaction data, and creates an abnormality report indicating the possibility of tampering. Then, the control device 61 of the platform server 6 advances the process to S56.

In S53, the control device 61 of the platform server 6 performs a transaction. Specifically, control device 61 of platform server 6 performs the same processing as the processing of S26 and S27 described in fig. 11, generates a record of the ledger specified by the information of the Key included in the transaction data, adds the generated record to the ledger, and updates ledger set 60.

In S54, the control device 61 of the platform server 6 generates a verification record. The check record contains Key, age, HV and Nonce information among the information contained in the record appended to the ledger.

In S55, control device 61 of platform server 6 creates a normal report indicating that the update of ledger 60 is completed (i.e., transaction data is processed). The control means 61 of the platform server 6 includes the check record into the normal report.

In S56, the control device 61 of the platform server 6 outputs a control signal for transmitting the abnormality report produced in S52 or the normal report produced in S55 to the client server 3 to the communication device 64. Thereby, an abnormal report or a normal report is transmitted to the client server 3 via the communication device 64.

In S56, the control device 61 of the platform server 6 outputs a control signal for transmitting the verification record to the other client servers 3 (for example, the client servers 3 of the B-business, C-business, and D-business) other than the transmission source of the transaction data to the communication device 64. Thereby, the check record is transmitted to the other client server 3 via the communication means 64.

In S46, the control device 31 of the client server 3 determines whether or not a normal report is received from the platform server 6. If it is determined that the 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 the normal report is not received, that is, the abnormal report is received (no in S46), the control device 31 of the client server 3 advances the process to S49.

In S47, the control device 31 of the client server 3 appends the check record contained in the normal report as the commit record to the commit table 374. Specifically, the control device 31 of the client server 3 determines whether the object of the additional commit record is commit data 375 or commit data 376 based on the information of the Key of the check record. Then, the control device 31 of the client server 3 appends the commit record to the commit data as an object.

In S48, the control device 31 of the client server 3 deletes the pause record having the information of the same Key as the added commit record from the pause table 373.

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

In addition, the other client servers 3 (client servers 3 of B, C, D enterprises) that received the check record transmitted in S56 also update the commit table 374 by appending the check record to the commit table 374.

Fig. 18 is a flowchart showing the procedure of the process of acquiring a time stamp token in embodiment 2. The processing of the flowchart shown in fig. 18 is executed by the control device 31 upon receiving the 3 rd request from the input device 35 or the user terminal device 7.

In S61, the control device 31 determines the commit data (commit data 375 or commit data 376) that is the object to acquire the time stamp token, based on the ID of the object component included in the 3 rd request.

In S62, the control device 31 generates a hash value of the latest commit record of the commit data determined in S61.

In S63, the control device 31 outputs a control signal for transmitting the hash value generated in S62 to the time authentication mechanism 8 to the communication device 34. Thereby, the hash value is transmitted to the time certification authority 8 via the communication device 34.

In S64, the control device 31 receives the time stamp token from the time certification authority 8 via the communication device 34. Thereby, the proof of the existence time of the member data of the target member is obtained.

In S65, the control device 31 causes the storage device 37 to store the time stamp token acquired in S64. The control device 31 may cause the database 4 to store the time stamp token.

In S66, the control device 21 outputs a control signal for transmitting the time stamp token acquired in S34 to the external server 9 to the communication device 34. Thereby, the time stamp token is transmitted to the external server 9 via the communication means 34. Further, in order to append the time stamp token to the commit table 374, the control device 31 may also generate transaction data for including the time stamp token in the ledger 60 and output a control signal for transmitting the transaction data to the platform server 6 to the communication device 34.

As described above, in the data management system 1A of embodiment 2, the platform server 6 provides certainty to the transaction data. Platform server 6 maintains ledger 60 containing 2 ledgers 67, 68. In the ledger 67, the update state of the component data of the 1 st component is stored in time series, and in the ledger 68, the update state of the component data of the 2 nd component is stored in time series. Then, if ledger set 60 is updated, a digest of the record added to ledger set 60, i.e., a check record, is transferred from platform server 6 to each client server 3, and each client server 3 adds the check record as a commit record to commit table 374. Commit table 374 corresponds to distributed ledger collection 50 of embodiment 1. In the structure of the data management system 1A of embodiment 2, if the end hash value of one ledger (e.g., ledger 67) is incorporated into the record of another ledger (e.g., ledger 68) and an association is established, the submitted data as the digest thereof are also associated with each other. Thus, similarly to embodiment 1, the existence sequence of the component data of the 1 st component and the component data of the 2 nd component can be verified with the commit record incorporating the terminal hash value as a reference.

Further, by each client server 3 holding the commit table 374 with each other, tamper resistance of the commit table 374 is improved.

In addition, the client server 3 retrieves a timestamp token for the record of the commit data incorporating the end hash value. If the time stamp token is acquired for a record incorporating the end hash value, a proof of the existence time of the component data of the 1 st component and the component data of the 2 nd component (i.e., a proof that the component data already exists before the time indicated by the time stamp token) can be acquired.

In addition, the client server 3 sends the timestamp token to the external server 9. By further managing the time stamp token by the external server 9, tamper resistance of the time stamp token can be improved.

Modification 2

In embodiment 2, an example is described in which the submission form 374 has a part of the information included in the ledger set 60. Specifically, the submission data 375, 376 of the submission form 374 are each composed of Key, age, HV and Nonce information among Key, age, obj-HV, nonce, sig, prev-HV and HV information that each of the ledgers 67, 68 of the ledger 60 has. However, each of submittal data 375, 376 may also be composed of information that is the same as ledgers 67, 68, i.e., key, age, obj-HV, nonce, sig, prev-HV and HV. In this case, the verification record is also generated in a manner that contains Key, age, obj-HV, nonce, sig, prev-HV and HV information. The same effects as those of embodiment 2 can be obtained by the above configuration.

The presently disclosed embodiments are considered in all respects to be illustrative and not restrictive. The technical scope indicated by the present disclosure is indicated by the claims rather than by the description of the above embodiments, and all changes that come within the meaning and range of equivalency of the claims are intended to be embraced therein.

Claims

1. A data management device that manages data using distributed ledger technology, wherein the data management device comprises:

a storage device storing a distributed ledger storing records containing information related to the data in time series; and

The control device appends the record 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 the first time point, the control device stores a record including the first information in the first distributed ledger, generates a first end value including information of 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 a record including the first terminal 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:

further comprising a communication device configured to be able to communicate with a time authentication agency,

At a second time point after the first time point, the control device sends a second end value including information of a record of an end of the second distributed ledger to the time authentication agency via the communication device, and obtains a timestamp token for the second end value from the time authentication agency.

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 comprises:

The control device appends the record to the distributed ledger,

The data includes first data and second data,

The data management method comprises the following steps: if the first data is updated at a predetermined time point, the control device

storing a record including the first information in the first distributed ledger, and generating a first terminal value of the information including the record; and

The record including the first terminal value is stored in the second distributed ledger.