History data management program, information processing device, and information processing system

Abstract

To reduce the number of write times in registering history data.SOLUTION: A computer receives first history data indicating first processing for object data. The computer predicts whether to receive, after the first history data, second history data indicating second processing for the object data. When predicting the reception of the second history data, the computer obtains an identifier for identifying the second history data before receiving the second history data; adds the identifier to the first history data; and registers the first history data with the identifier in a database.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present invention relates to a history data management program, an information processing device, and an information processing system. [Background technology]

[0002] An information processing system may register historical data in a database so that the authenticity of the historical data can be confirmed later. The database used to manage historical data may be a database that is difficult to tamper with after registration, such as a blockchain.

[0003] In addition, a blockchain generation method has been proposed that reduces the amount of data in the blockchain by deleting intermediate blocks when the importance of historical data contained in blocks prior to the final block is low. Also, a data block recording method has been proposed that waits for a certain amount of unrecorded transaction data to accumulate before recording it, instead of recording transaction data in the blockchain as it occurs.

[0004] In addition, a relationship recording method has been proposed in which relationship information indicating the relationship between different users is encrypted and the ciphertext is written to the blockchain. Also, a data management method has been proposed in which a transfer record indicating the transfer of data between different systems is written to the blockchain. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2020 / 120054 [Patent Document 2] International Publication No. 2020 / 169061 [Patent Document 3] US Patent Application Publication No. 2020 / 0327240 [Patent Document 4] US Patent Application Publication No. 2021 / 0089497 Summary of the Invention [Problem to be solved by the invention]

[0006] The information processing system may manage the state of the target data by registering history data indicating processing of the target data in a database. For example, the information processing system may manage the distribution state of important data and protect the important data by registering history data indicating transmission and reception of important data in a database.

[0007] In managing history data, the information processing system may want to search for subsequent history data indicating processing performed after a certain piece of history data. In order to efficiently search for the subsequent history data, the information processing system may add an identifier of the subsequent history data to the previous history data.

[0008] However, modifying previous history data every time new history data is registered in a database increases the number of writes to the database, which may increase the load. For example, when using a database in which registered history data is difficult to tamper with, such as a blockchain, the information processing system may re-register the entire modified history data in the database. Therefore, in one aspect, the present invention aims to reduce the number of writes when registering history data. [Means for solving the problem]

[0009] In one aspect, there is provided a history data management program that causes a computer to execute the following processes: Accept first history data indicating a first process on target data; Predict whether second history data indicating a second process on the target data will be accepted after the first history data; If it is predicted that the second history data will be accepted, obtain an identifier that identifies the second history data before accepting the second history data, add the identifier to the first history data, and register the first history data with the added identifier in a database.

[0010] In one aspect, an information processing device is provided having a storage unit and a processing unit.In another aspect, an information processing system is provided having a first information processing device and a second information processing device. Effect of the Invention

[0011] In one aspect, the number of writes required to register historical data is reduced. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an information processing system according to a first embodiment. [Diagram 2] FIG. 11 illustrates an example of an information processing system according to a second embodiment. [Diagram 3] 2 is a block diagram showing an example of hardware of a history management server; [Figure 4] FIG. 11 is a diagram illustrating an example of the registration timing of history data. [Diagram 5] FIG. 13 is a diagram illustrating a first example of writing history data to a blockchain. [Figure 6] FIG. 11 is a diagram illustrating a second example of writing history data to a blockchain. [Figure 7] FIG. 11 is a sequence diagram showing an example of a continuous write pattern. [Figure 8] FIG. 11 is a sequence diagram showing an example of writing history data. [Figure 9] FIG. 2 is a block diagram illustrating an example of functions of the information processing system. [Figure 10] 13 is a flowchart illustrating an example of a procedure for history management. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] The present embodiment will be described below with reference to the drawings. [First embodiment] A first embodiment will be described.

[0014] FIG. 1 is a diagram illustrating an information processing system according to a first embodiment. The information processing system of the first embodiment includes information processing devices 10 and 20. The information processing device 10 manages history data indicating processing of target data. For example, the information processing device 10 manages history data indicating transmission and reception of target data between users. The information processing device 20 transmits history data to the information processing device 10 and requests registration of the history data. For example, the information processing device 20 is an information processing device used by a user who transmits and receives target data.

[0015] The information processing devices 10 and 20 may be client devices or server devices. The information processing devices 10 and 20 may be called computers. The information processing device 10 may be called a history data management device or a database device. In the first embodiment, the information processing device 20 transmits history data to the information processing device 10, but a user may input history data to the information processing device 10.

[0016] The information processing device 10 has a storage unit 11 and a processing unit 12. The information processing device 20 may have the same hardware as the information processing device 10. The storage unit 11 may be a volatile semiconductor memory such as a random access memory (RAM). The storage unit 11 may also be a non-volatile storage such as a hard disk drive (HDD) or a flash memory.

[0017] The processing unit 12 is, for example, a processor such as a central processing unit (CPU), a graphics processing unit (GPU), or a digital signal processor (DSP). However, the processing unit 12 may include an electronic circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The processor executes a program stored in a memory such as a RAM (which may be the storage unit 11). A collection of processors may be called a multiprocessor or simply a "processor."

[0018] The storage unit 11 stores a database 13. Historical data is registered in the database 13. The database 13 may be a database in which registered historical data is difficult to tamper with, such as a blockchain. The historical data indicates processing performed on target data that is to be protected. The target data may be important data that is circulated among users under certain protection conditions, such as so-called big data.

[0019] The processing of the target data may include original registration, data processing, data transmission, data reception, etc. The history data indicating original registration may include a hash value of the target data in an initial state. The history data indicating data processing may include a hash value of the processed target data. The history data indicating data transmission may include the name of a sender who sent the target data. The history data indicating data reception may include the name of a recipient of the target data.

[0020] The processing unit 12 accepts history data 14 indicating processing on target data. In the first embodiment, the information processing device 10 receives the history data 14 from the information processing device 20. However, the history data 14 may be input to the information processing device 10 by a user. Typically, the processing unit 12 accepts history data 14 indicating that a certain processing has been executed after the processing has been executed on the target data. However, the processing unit 12 may accept history data 14 indicating the processing during or immediately before the execution of the processing.

[0021] When history data 14 is received, processing unit 12 predicts whether history data 15 will be received after history data 14. History data 15 indicates a process for the same target data as history data 14, but different from history data 14. Usually, the process indicated by history data 15 (second process) is executed after the process indicated by history data 14 (first process). At the time history data 14 is received, the process indicated by history data 15 may not have been executed yet, or may have already been executed.

[0022] Regarding the above prediction, it can also be said that the processing unit 12 determines whether or not there is a plan to receive the history data 15 after the history data 14. It can also be said that the processing unit 12 predicts whether or not there is a plan to receive the second process after the first process. It can also be said that the processing unit 12 determines whether or not there is a plan to receive the second process after the first process. The processing unit 12 may also predict whether or not there will be consecutive receipt of the history data 15 within a short period of time after receipt of the history data 14.

[0023] For example, the processing unit 12 predicts whether or not to accept the history data 15 based on the type of processing indicated by the history data 14. When the history data 14 indicates data transmission, the processing unit 12 may predict that the history data 15 indicating data reception will be accepted. Also, for example, the processing unit 12 predicts that the history data 15 will be accepted when a sequence of processing types indicated by a certain number of most recent history data including the history data 14 matches a certain pattern.

[0024] Also, for example, the processing unit 12 predicts whether or not to accept the history data 15 based on a flag received together with the history data 14. The flag may indicate whether or not the second process is executed after the first process, and may be set by a user. For example, the information processing device 10 receives a flag together with the history data 14 from the information processing device 20. When the processing unit 12 receives an ON flag together with the history data 14 indicating data processing, the processing unit 12 may predict that the history data 15 indicating data transmission will be accepted.

[0025] When it is predicted that the history data 15 will be accepted, the processing unit 12 acquires an identifier 17 for identifying the history data 15 before accepting the history data 15. The history data 15 may be received from the information processing device 20, may be received from another information processing device, or may be input to the information processing device 10 by a user. The identifier 17 may be a numerical value expressed by a certain number of bits (for example, 128 bits).

[0026] The processing unit 12 may acquire an identifier 16 for identifying the history data 14 together with the identifier 17. The identifiers 16 and 17 may be acquired so as to satisfy a certain relationship. For example, the identifier 17 is a numerical value obtained by adding 1 to the identifier 16. The processing unit 12 may newly generate the identifiers 16 and 17 in response to receiving the history data 14.

[0027] When the identifier 17 is acquired, the processing unit 12 adds the identifier 17 to the history data 14. The processing unit 12 may insert the identifier 17 into the history data 14. Then, the processing unit 12 registers the history data 14 with the identifier 17 added in the database 13. The processing unit 12 may register the history data 14 using the identifier 16, or may add the identifier 16 to the history data 14 in addition to the identifier 17.

[0028] The identifier 17 added to the history data 14 is intended to point to the history data next to the history data 14. The identifier 17 added to the history data 14 may be used in a forward search to search for subsequent history data from the history data 14. However, at the time the history data 14 is registered, the history data 15 indicated by the identifier 17 does not yet exist.

[0029] After registering the history data 14, the processing unit 12 may receive history data 15. In this case, the processing unit 12 registers the received history data 15 in the database 13. The processing unit 12 may register the history data 15 using an identifier 17, or may add the identifier 17 to the history data 15. In this case, if the identifier 17 has already been added to the history data 14, the processing unit 12 does not need to modify the history data 14.

[0030] The processing unit 12 may receive, together with the history data 15, an identifier 16 of the history data 14 on which the history data 15 depends. The processing unit 12 may reproduce the identifier 17 from the identifier 16 based on the above-mentioned certain relationship. For example, the processing unit 12 reproduces the identifier 17 by adding 1 to the received identifier 16. However, the processing unit 12 may read out the history data 14 from the database 13 and check the identifier 17 added to the history data 14.

[0031] If the processing unit 12 does not predict that the history data 15 will be received after the history data 14, the processing unit 12 may register the history data 14 without the identifier 17 in the database 13. If the processing unit 12 receives the history data 15 thereafter, the processing unit 12 obtains the identifier 17 for identifying the history data 15 and registers the history data 15 in the database 13. At this time, the processing unit 12 may add the identifier 17 to the history data 14 that has already been registered.

[0032] Depending on the structure of the database 13, the subsequent addition of the identifier 17 to the history data 14 may be implemented as a re-registration of the history data 14. For example, when the database 13 is a blockchain, the processing unit 12 reads the history data 14 from the database 13 and modifies the history data 14 by adding the identifier 17 to the history data 14. The processing unit 12 writes the entirety of the modified history data 14 to the database 13 as new history data. The history data 14 before the modification may be treated as invalid data.

[0033] As described above, the information processing device 10 of the first embodiment accepts history data 14 indicating processing on target data. The information processing device 10 predicts whether or not history data 15 indicating another processing on the target data will be accepted after the history data 14. When the information processing device 10 predicts that the history data 15 will be accepted, the information processing device 10 obtains an identifier 17 that identifies the history data 15 before accepting the history data 15, adds the identifier 17 to the history data 14, and registers the history data 14 with the identifier 17 added in the database 13.

[0034] This improves the efficiency of forward searches for searching for history data 15 from history data 14. Furthermore, when registering history data 15 in database 13, information processing device 10 does not need to modify already registered history data 14. This reduces the number of times data is written to database 13, and the burden of managing history data is lightened. Furthermore, even if database 13 is a database in which it is difficult to overwrite and modify history data 14, it is not necessary to re-register history data 14, and this prevents the amount of data in database 13 from expanding.

[0035] If the information processing device 10 does not predict that it will receive the history data 15, it may register the history data 14 to which the identifier 17 is not added in the database 13. If the information processing device 10 subsequently receives the history data 15, it may obtain the identifier 17 and add the identifier 17 to the history data 14 registered in the database 13. This reduces the risk of an inconsistency, in which the history data 15 that the identifier 17 should point to does not actually exist, being left unattended for a long period of time, compared to a case in which the identifier 17 is always added when the history data 14 is registered. This reduces errors when searching for or displaying history data.

[0036] Furthermore, the information processing device 10 may predict whether or not to accept the history data 15 based on the type of processing indicated by the history data 14. This covers typical uses of target data in which the history data 14 and the history data 15 are successively registered. Furthermore, when accepting the history data 14, the information processing device 10 may further accept a flag indicating whether or not a second processing is scheduled to be performed after the first processing, and may predict whether or not to accept the history data 15 based on the flag. This covers cases in which the history data 14 and the history data 15 are successively registered due to processing by the same user.

[0037] Furthermore, when registering the history data 14, the information processing device 10 may obtain an identifier 16 for identifying the history data 14 and output the identifier 16. The identifier 16 and the identifier 17 may be obtained so as to have a certain relationship. The information processing device 10 may then receive the history data 15 and the identifier 16, reproduce the identifier 17 from the identifier 16 based on the certain relationship, and register the history data 15 using the reproduced identifier 17. This eliminates the need for the information processing device 10 to read out the history data 14 from the database 13 when receiving the history data 15, thereby reducing the number of times the database 13 is accessed.

[0038] [Second embodiment] Next, a second embodiment will be described. FIG. 2 illustrates an example of an information processing system according to the second embodiment.

[0039] The information processing system according to the second embodiment manages the distribution of target data among multiple companies. The target data is, for example, big data used to analyze customer purchasing behavior, and may include customer purchase records and customer product evaluation results.

[0040] The information processing system includes user devices 31, 32, and 33 and a history management server 100. The user devices 31, 32, and 33 and the history management server 100 are connected to a network 30. The network 30 may include a wide area data communication network such as the Internet, or may include a LAN (Local Area Network).

[0041] User devices 31, 32, and 33 are computers used by different companies. User devices 31, 32, and 33 may be client computers or server computers. User device 31 corresponds to information processing device 20 of the first embodiment. User device 31 is used by company C. User device 32 is used by company D. User device 33 is used by company E. Companies C, D, and E are participating companies that have agreed to protect and distribute the target data.

[0042] The user devices 31, 32, and 33 transmit and receive target data using application software for data protection. A client application may be installed in the user devices 31, 32, and 33. The user devices 31, 32, and 33 may transmit and receive target data directly to each other, or may transmit and receive target data via a server device (not shown). The client application may include a Web client such as a Web browser. When a process such as transmitting and receiving target data is performed, the user devices 31, 32, and 33 automatically transmit history data indicating the performed process to the history management server 100.

[0043] The history management server 100 is a server computer that manages history data using a blockchain. The history management server 100 corresponds to the information processing device 10 of the first embodiment. The history management server 100 receives history data from user devices 31, 32, and 33. The history management server 100 writes the received history data into the blockchain.

[0044] Furthermore, the history management server 100 searches for history data from the blockchain in response to a request from the user devices 31, 32, and 33, and transmits the read history data to the user device that issued the request. The history management server 100 may visualize history data indicating different processes on the same target data in a tree-like form and provide it to the user devices 31, 32, and 33. It is difficult to tamper with the history data written in the blockchain secretly. For this reason, the history management server 100 provides reliability to information indicating the distribution state of the target data.

[0045] FIG. 3 is a block diagram showing an example of hardware of the history management server. The history management server 100 has a CPU 101, a RAM 102, a HDD 103, a GPU 104, an input interface 105, a medium reader 106, and a communication interface 107, all connected via a bus. The CPU 101 corresponds to the processing unit 12 in the first embodiment. The RAM 102 or the HDD 103 corresponds to the storage unit 11 in the first embodiment. The user devices 31, 32, and 33 may each have the same hardware as the history management server 100.

[0046] The CPU 101 is a processor that executes instructions of a program. The CPU 101 loads the program and data stored in the HDD 103 into the RAM 102, and executes the program. The history management server 100 may have multiple processors.

[0047] The RAM 102 is a volatile semiconductor memory that temporarily stores the programs executed by the CPU 101 and data used in the calculations by the CPU 101. The history management server 100 may have a type of volatile memory other than the RAM.

[0048] The HDD 103 is a non-volatile storage that stores software programs such as an operating system (OS), middleware, and application software, as well as data. The history management server 100 may also have other types of non-volatile storage, such as a flash memory or a solid state drive (SSD).

[0049] The GPU 104 performs image processing in cooperation with the CPU 101, and outputs an image to a display device 111 connected to the history management server 100. The display device 111 is, for example, a CRT (Cathode Ray Tube) display, a liquid crystal display, an organic EL (Electro Luminescence) display, or a projector. Other types of output devices, such as a printer, may be connected to the history management server 100.

[0050] The GPU 104 may be used as a general purpose computing on graphics processing unit (GPGPU). The GPU 104 may execute a program in response to an instruction from the CPU 101. The history management server 100 may include a volatile semiconductor memory other than the RAM 102 as a GPU memory.

[0051] The input interface 105 receives an input signal from an input device 112 connected to the history management server 100. The input device 112 is, for example, a mouse, a touch panel, or a keyboard. A plurality of input devices may be connected to the history management server 100.

[0052] The medium reader 106 is a reading device that reads the program and data recorded on the recording medium 113. The recording medium 113 is, for example, a magnetic disk, an optical disk, or a semiconductor memory. The magnetic disk includes a flexible disk (FD) and a HDD. The optical disk includes a compact disc (CD) and a digital versatile disc (DVD). The medium reader 106 copies the program and data read from the recording medium 113 to another recording medium such as the RAM 102 or the HDD 103. The read program may be executed by the CPU 101.

[0053] The recording medium 113 may be a portable recording medium. The recording medium 113 may be used for distributing programs and data. The recording medium 113 and the HDD 103 may be called computer-readable recording media.

[0054] The communication interface 107 communicates with the user devices 31, 32, and 33 via the network 30. The communication interface 107 may be a wired communication interface connected to a wired communication device such as a switch or a router, or a wireless communication interface connected to a wireless communication device such as a base station or an access point.

[0055] Next, we will explain how to write historical data to the blockchain. FIG. 4 is a diagram showing an example of the registration timing of history data. Processing that a company may perform on target data includes original registration, data processing, data transmission, and data reception. Original registration is to identify the original target data as a target for distribution. Historical data indicating the original registration includes a commitment generated from the original target data. The commitment may be used to verify the identity of the target data. The commitment may be, for example, a hash value of the target data.

[0056] Data processing is the manipulation of target data. Data processing is sometimes carried out to limit the information provided to other companies. Data processing may involve deleting some records from the target data, or deleting some data items (columns) from the target data. Data processing may also involve converting the values ​​of some or all of the data items contained in the target data into simplified values ​​with greater granularity. Historical data indicating data processing includes commitments generated from the processed target data.

[0057] Data transmission is when one company sends target data to another company. Historical data indicating data transmission includes the name of the sender and the name of the destination. Data reception is when one company receives target data from another company. Historical data indicating data reception includes the name of the receiver and the name of the sender. Each historical data also includes the name of the registrant, the date and time the processing was performed, and a historical type indicating the type of processing.

[0058] As an example, consider a case where company C has original target data, company C provides the target data to company D, and company D further provides the target data to company E. User device 31 executes original registration 141. User device 31 transmits history data indicating original registration 141 to history management server 100. History management server 100 writes the history data of original registration 141 into the blockchain.

[0059] The user device 31 executes data transmission 142 after original registration 141. The data transmission 142 transmits the target data indicated by the original registration 141 to the user device 32. The original registration 141 may be performed as a pre-processing for providing the target data. Therefore, the original registration 141 and the data transmission 142 may be performed consecutively within a short period of time. The user device 31 transmits history data indicating the data transmission 142 to the history management server 100. The history management server 100 writes the history data of the data transmission 142 to the blockchain.

[0060] The user device 32 executes data reception 143 after data transmission 142. The data reception 143 receives target data from the user device 31. The data transmission 142 and the data reception 143 are usually executed consecutively within a short period of time. The user device 32 transmits history data indicating the data reception 143 to the history management server 100. The history management server 100 writes the history data of the data reception 143 into the blockchain.

[0061] The user device 32 executes data processing 144 after data reception 143. The data processing 144 processes the target data received in data reception 143. The user device 32 transmits history data indicating the data processing 144 to the history management server 100. The history management server 100 writes the history data of the data processing 144 into the blockchain.

[0062] The user device 32 executes data transmission 145 after data processing 144. The data transmission 145 transmits the processed target data to the user device 33. The data processing 144 may be performed as a pre-processing for providing the target data. Therefore, the data processing 144 and the data transmission 145 may be performed consecutively within a short period of time. The user device 32 transmits history data indicating the data transmission 145 to the history management server 100. The history management server 100 writes the history data of the data transmission 145 to the blockchain.

[0063] The user device 33 executes data reception 146 after data transmission 145. The data reception 146 receives target data from the user device 32. The data transmission 145 and the data reception 146 are usually executed consecutively within a short period of time. The user device 33 transmits history data indicating the data reception 146 to the history management server 100. The history management server 100 writes the history data of the data reception 146 into the blockchain.

[0064] The history management server 100 manages a series of history data derived from original target data in association with each other. The history management server 100 may perform a backward search to search for history data older than a certain piece of history data. The history management server 100 may also perform a forward search to search for history data newer than a certain piece of history data. For this reason, the history management server 100 sets a node ID for identifying each piece of history data. The history management server 100 also sets a previous node ID indicating the previous piece of history data and a next node ID indicating the next piece of history data for each piece of history data. This makes both backward and forward searches more efficient.

[0065] FIG. 5 is a diagram illustrating a first example of writing history data to a blockchain. The history management server 100 receives the history data indicating the original registration. In addition, the history management server 100 receives the node ID (node ​​X) indicating the previous history data related to the history data together with the history data.

[0066] The history management server 100 then generates a node ID (node ​​A) to identify the received history data, and adds the node ID to the history data. The history management server 100 also sets the previous node ID to the received node ID (node ​​X). The history management server 100 also sets the next node ID to null. The previous node ID and next node ID are inserted into the history data. The history management server 100 then writes the history data into block 151. The history management server 100 also notifies the user device that sent the history data of the node ID of the written history data.

[0067] Next, the history management server 100 receives history data indicating data transmission and a node ID (node ​​A) indicating the previous history data. Then, the history management server 100 generates a node ID (node ​​B) that identifies the received history data, and adds the node ID to the history data. The history management server 100 also sets the previous node ID to the received node ID (node ​​A). The history management server 100 also sets the next node ID to null. The history management server 100 then writes the history data to block 152, which is after block 151. The history management server 100 also notifies the user device that transmitted the history data of the node ID of the written history data.

[0068] Here, the next node ID of the history data included in block 151 is still blank. Therefore, to enable a forward search using the next node ID, the history management server 100 sets the next node ID to the node ID (node ​​B) of the history data just written. However, due to the nature of the blockchain, it is difficult to directly overwrite the history data written in block 151. Therefore, the history management server 100 rewrites the entirety of the corrected history data as new history data.

[0069] Therefore, history management server 100 reads the previous history data from block 151, and changes the next node ID to node B. Then, history management server 100 writes the entirety of the corrected history data to block 153, which is after block 152. When searching for history data, old history data with the same node ID is determined to be invalid. However, the order of blocks 152 and 153 may be reversed. Also, although one block contains one piece of history data in FIG. 5, one block may contain multiple pieces of history data.

[0070] When searching for history data, for example, the history management server 100 receives a base node ID. The history management server 100 scans the history data included in the blockchain from new to old, and reads out the history data having the base node ID. The history management server 100 extracts the previous node ID or next node ID from the read out history data. The history management server 100 scans the history data from new to old, and reads out the history data having the extracted node ID.

[0071] The history management server 100 can identify the chain of history data by repeating the above process. However, the history management server 100 may hold an index that associates a node ID that identifies history data with a block ID that identifies a block that includes the history data. In that case, the history management server 100 may refer to the index and read out history data having a desired node ID from the blockchain.

[0072] Here, the history management server 100 may receive different history data for the same target data consecutively within a short period of time. For example, history data indicating data transmission and history data indicating data reception are likely to be received consecutively. In addition, when data processing is performed as a preparation for data transmission, history data indicating data processing and history data indicating data transmission may be received consecutively. Different history data for the same target data may be received within one minute.

[0073] On the other hand, if the method described in Fig. 5 is followed, the history management server 100 will write the history data to the blockchain twice every time it receives new history data. This may increase the load on the history management server 100. In addition, a lot of history data will become invalid later, increasing the amount of data in the blockchain.

[0074] Therefore, when history management server 100 receives history data, it determines whether there is a high possibility that next history data related to the same target data will be received consecutively. If it determines that there is a high possibility that next history data will be received consecutively, history management server 100 reserves a node ID that identifies the next history data. History management server 100 sets the next node ID of the received history data to the reserved node ID. In this way, when history management server 100 receives the next history data, it does not need to modify the written history data.

[0075] FIG. 6 is a diagram illustrating a second example of writing history data to the blockchain. The history management server 100 receives the history data indicating the original registration and the node ID (node ​​X) indicating the previous history data. At this time, the history management server 100 determines that there is a high possibility that the next history data will be received consecutively.

[0076] The history management server 100 then generates a node ID (node ​​A) to identify the received history data, and adds this node ID to the history data. The history management server 100 also sets the previous node ID to the received node ID (node ​​X). The history management server 100 also generates a node ID (node ​​B) to identify the next history data, and sets this node ID to the next node ID. The history management server 100 then writes the history data to block 154. The history management server 100 also notifies the user device that sent the history data of the node ID of the written history data.

[0077] Next, the history management server 100 receives history data indicating data transmission and a node ID (node ​​A) indicating the previous history data. The history management server 100 then adds the previously generated node ID (node ​​B) to the received history data. The history management server 100 also sets the previous node ID to the received node ID (node ​​A). The history management server 100 also sets the next node ID to null. The history management server 100 then writes the history data to block 155, which is after block 154. The history management server 100 also notifies the user device that transmitted the history data of the node ID of the written history data. At this time, the history management server 100 does not need to modify the history data included in block 154.

[0078] This reduces the number of times history data is written to the blockchain, and the load on the history management server 100 is reduced. Also, the amount of history data that becomes invalid later is reduced, and the amount of data in the blockchain is reduced. If it is determined that the next history data is not likely to be continuously received, it is preferable for the history management server 100 to write the history data using the basic method described in FIG. 5. This is because if an inconsistency in which history data that should be identified by the next node ID does not actually exist in the blockchain is left unchecked for a long period of time, problems may occur in searching for and displaying history data.

[0079] FIG. 7 is a sequence diagram showing an example of a continuous write pattern. The history management server 100 determines whether or not there is a high possibility of receiving history data consecutively, based on the history type indicated by the history data and the consecutive flag received from the user device.

[0080] The history management server 100 identifies the history type indicated by the current history data. Alternatively, the history management server 100 identifies a sequence of history types formed from the history type indicated by the current history data and the history type indicated by the most recent history data (e.g., the history data immediately before). The history types are, for example, original registration, data processing, data transmission, or data reception.

[0081] The history management server 100 compares the identified history type or the sequence of history types with a certain pattern prepared in advance. If the identified history type or the sequence of history types corresponds to a certain pattern, the history management server 100 determines that there is a high possibility of continuously receiving history data. An example of a pattern is a pattern in which the current history type is data transmission. Another example of a pattern is a pattern in which the previous history type was original registration and the current history type is data transmission. The determination based on the history type covers typical processes that are often executed continuously.

[0082] The history management server 100 also receives a successive flag together with the history data from the user device that transmits the history data. The successive flag indicates the user's judgment as to whether or not the next process is scheduled to be executed for the same target data. If the next process is scheduled to be executed, the user performs an operation to set the successive flag to ON, for example, on the screen of the application software. If the successive flag is ON, the history management server 100 determines that there is a high possibility of receiving the history data successively. The judgment based on the successive flag covers processes that may be executed successively within the same company.

[0083] If the history type falls within a certain pattern or if the consecutive flag = ON is received, the history management server 100 is likely to receive history data continuously, so it writes the history data using the method described in Fig. 6. On the other hand, if the history type does not fall within a certain pattern and the consecutive flag = ON is not received, the history management server 100 is not likely to receive history data continuously, so it writes the history data using the method described in Fig. 5.

[0084] As an example, the user device 31 transmits history data indicating original registration to the history management server 100 (S10). Next, the user device 31 transmits history data indicating data transmission to the history management server 100 (S11). When the original registration and data transmission are executed, the history management server 100 predicts that data reception will be executed immediately thereafter.

[0085] Therefore, the history management server 100 generates a node ID of the history data indicating data reception in advance and inserts it as a next node ID into the history data indicating data transmission. After that, the user device 32 receives the target data from the user device 31 and transmits the history data indicating the data reception to the history management server 100 (S12). The history management server 100 inserts the generated node ID into the history data indicating the data reception.

[0086] Furthermore, the user device 32 transmits history data indicating data processing and successive flag = ON to the history management server 100 (S13). Since the history management server 100 has received the successive flag = ON, it predicts that some processing will be executed immediately thereafter. Therefore, the history management server 100 generates a node ID for the next history data in advance and inserts it as the next node ID into the history data indicating data processing. The user device 32 then transmits history data indicating data transmission to the history management server 100 (S14). The history management server 100 inserts the generated node ID into the history data indicating data transmission.

[0087] Here, when the history management server 100 receives new history data and the node ID of the previous history data from the user device, it determines whether or not the previous history data needs to be modified. To make this determination efficiently, the history management server 100 assigns a node ID for successive writing, which is different from a normal node ID, to the earlier history data of a pair of history data that are continuously received. When the history management server 100 receives a node ID for successive writing, it omits modifying the history data indicated by that node ID.

[0088] Furthermore, when the history management server 100 receives a node ID for successive writing, it uses the next node ID included in the previous history data for the currently received history data. To efficiently obtain the current node ID, the history management server 100 assigns two node IDs having a certain relationship to a pair of continuously received history data. When the history management server 100 receives a node ID for successive writing, it reproduces the current node ID from the received node ID based on the above-mentioned certain relationship. This omits the need to read the next node ID from the previous history data.

[0089] For example, a node ID is an integer expressed in 128 bits. The least significant bit of this node ID is used to identify whether it is for continuous writing or not. The least significant bit of a normal node ID is 1, and the least significant bit of a node ID for continuous writing is 0. Therefore, normal node IDs are odd numbers, and node IDs for continuous writing are even numbers. When history management server 100 predicts that it will receive history data continuously, it assigns an even-numbered node ID to the current history data. In addition, history management server 100 assigns an odd number, which is the current node ID plus 1, to the next history data.

[0090] The above conditions for the node ID for successive writing are merely an example, and other conditions may be used to distinguish between normal node IDs and node IDs for successive writing. For example, the most significant bit may be used to identify whether or not a node ID is for successive writing. The above certain relationship is merely an example, and subsequent node IDs may be calculated from previous node IDs using other relationships.

[0091] FIG. 8 is a sequence diagram showing an example of writing history data. The user device 31 transmits history data indicating data transmission and a node ID (node ​​X) identifying the previous history data to the history management server 100 (S20). The history management server 100 determines that there is a high possibility that data reception will be performed after the data transmission. The history management server 100 then generates a node ID (node ​​A) identifying the current history data and a node ID (node ​​B) identifying the next history data (S21). Node A is a node ID for successive writing. Node B is a node ID that has a certain relationship with node A, and is, for example, an integer obtained by adding 1 to node A.

[0092] The history management server 100 adds node A to the current history data, sets the previous node ID to node X, and sets the next node ID to node B. The history management server 100 writes this history data to the blockchain (S22). The history management server 100 also notifies the user device 31 of node A that identifies the current history data (S23). The user device 31 transmits the target data itself and node A to the user device 32 (S24).

[0093] The user device 32 transmits history data indicating data reception and node A to the history management server 100 (S25). The history management server 100 determines that the received node A is a node ID for successive writing. The history management server 100 then reproduces node B from node A (S26). The history management server 100 then adds node B to the current history data, sets the previous node ID to node A, and sets the next node ID to blank. The history management server 100 writes this history data to the blockchain (S27). The history management server 100 also notifies the user device 32 of node B (S28).

[0094] Next, functions and processing procedures of the information processing system according to the second embodiment will be described. FIG. 9 is a block diagram illustrating an example of functions of the information processing system. The user device 31 has a data storage unit 131, a user communication unit 132, and a history communication unit 133. The data storage unit 131 is implemented using, for example, a RAM or a HDD. The user communication unit 132 and the history communication unit 133 are implemented using, for example, a CPU, a program, and a communication interface. The user devices 32 and 33 may have the same blocks as the user device 31.

[0095] The data storage unit 131 stores target data held by company C. The target data may be generated by the business of company C. The target data may be received from other companies, either for a fee or free of charge. The target data may be processed by company C. The data storage unit 131 also stores a node ID issued for the target data.

[0096] The user communication unit 132 communicates with the user devices 32 and 33. The user communication unit 132 may transmit target data to the user devices 32 and 33. The user communication unit 132 may also receive target data from the user devices 32 and 33. The latest node ID issued for the target data is transmitted together with the target data.

[0097] The history communication unit 133 communicates with the history management server 100. The history communication unit 133 detects processing performed on target data, generates history data indicating the processing performed, and transmits the history data to the history management server 100. For example, the history communication unit 133 detects data transmission or data reception by the user-to-user communication unit 132. The latest node ID issued for the target data is transmitted together with the history data. The history communication unit 133 may also receive an instruction from the user to set the successive flag to ON. In that case, the successive flag = ON is transmitted together with the history data and the node ID. The history communication unit 133 receives a new node ID from the history management server 100 in response to the history data.

[0098] Furthermore, the history communication unit 133 transmits a search request to search for history data to the history management server 100 in response to an instruction from a user. In the search request, a base node ID is specified. The history communication unit 133 displays the search results of the history data on a display device. The history communication unit 133 may receive history data having a specified node ID from the history management server 100. Furthermore, the history communication unit 133 may receive subsequent history data that can be traced back using a next node ID. Furthermore, the history communication unit 133 may receive past history data that can be traced back using a previous node ID. The history communication unit 133 may visualize the collection of received history data in a tree shape.

[0099] The history management server 100 includes a block chain 121, a pattern storage unit 122, a history communication unit 123, a successive writing determination unit 124, a history writing unit 125, and a history search unit 126. The block chain 121 and the pattern storage unit 122 are implemented, for example, using a RAM 102 or a HDD 103. The history communication unit 123, the successive writing determination unit 124, the history writing unit 125, and the history search unit 126 are implemented, for example, using a CPU 101, a program, and a communication interface 107.

[0100] The blockchain 121 is a database in which it is difficult to secretly tamper with written data later. The blockchain 121 includes multiple blocks. Each block includes the hash value of the previous block. By checking the consistency of hash values ​​between blocks, the authenticity of the data included in the block is guaranteed.

[0101] The pattern storage unit 122 stores a pattern of history types. The pattern indicates a typical type of processing that is often performed consecutively on the same target data. For example, the pattern indicates that data reception is performed immediately after data transmission. In this case, at the time of data transmission, it is predicted that the next processing will be performed within a short period of time.

[0102] The history communication unit 123 communicates with the user devices 31, 32, and 33. The history communication unit 123 receives history data and a node ID. The history communication unit 123 may further receive a consecutive flag = ON. The history communication unit 123 returns a new node ID generated by the history writing unit 125 to the user device that transmitted the history data. The history communication unit 123 also receives a search request. The history communication unit 123 returns the search results generated by the history search unit 126 to the user device that transmitted the search request.

[0103] The continuous writing determination unit 124 acquires the history type indicated by the current history data. When the pattern stored in the pattern storage unit 122 specifies a sequence of history types, the continuous writing determination unit 124 may acquire a sequence of history types including the history type of the most recent history data from the history writing unit 125. The continuous writing determination unit 124 may also acquire a continuous flag = ON. When the history type or the sequence of history types corresponds to a pattern, the continuous writing determination unit 124 determines that there is a high possibility that the next history data will be received continuously. When the continuous writing determination unit 124 acquires a continuous flag = ON, it determines that there is a high possibility that the next history data will be received continuously. In other cases, the continuous writing determination unit 124 determines that there is a low possibility that the next history data will be received continuously.

[0104] The history writing unit 125 obtains a determination result of whether or not the next history data is likely to be continuously received from the continuous writing determination unit 124. If the next history data is not likely to be continuously received, the history writing unit 125 generates a node ID for the current history data, adds the current node ID and the previous node ID to the history data, and sets the next node ID to null. If the next history data is likely to be continuously received, the history writing unit 125 generates a node ID for the next history data in addition to the node ID for the current history data, and adds the current node ID, the previous node ID, and the next node ID to the history data. The history writing unit 125 writes the history data to the blockchain 121.

[0105] Furthermore, if the next node ID included in the previous history data is blank, the history writing unit 125 changes the next node ID from blank to the current node ID. In practice, the history writing unit 125 reads the previous history data from the blockchain 121, modifies it, and writes the modified history data back to the blockchain 121.

[0106] The history search unit 126 searches for history data from the block chain 121 based on the base node ID included in the search request. The history search unit 126 may continuously read other related history data from the block chain 121 using the next node ID or previous node ID included in the read history data.

[0107] FIG. 10 is a flowchart showing an example of a procedure for history management. (S30) The history communication unit 123 receives the history data and the node ID (node ​​X). (S31) History writing unit 125 determines whether the node ID (node ​​X) in step S30 is a node ID for successive writing. If it is for successive writing, the process proceeds to step S40, and if it is for normal use, the process proceeds to step S32.

[0108] (S32) The successive writing determination unit 124 determines whether or not a successive flag=ON has been received in step S30. If a successive flag=ON has been received, the process proceeds to step S36, and if not, the process proceeds to step S33.

[0109] (S33) The continuous writing determination unit 124 identifies the history type of the received history data. Alternatively, the continuous writing determination unit 124 identifies a string of history types including the history type of the received history data and the history type of the history data indicated by the node ID (node ​​X) in step S30. The continuous writing determination unit 124 determines whether the identified history type or string of history types corresponds to a certain pattern. If it corresponds to the pattern, the process proceeds to step S36. If it does not correspond to the pattern, the process proceeds to step S34.

[0110] (S34) The history writing unit 125 generates a normal node ID (node ​​A). (S35) History writing unit 125 adds the node ID (node ​​A) of step S34 to the received history data. History writing unit 125 also adds the node ID (node ​​X) of step S30 to the history data as a previous node ID. History writing unit 125 also sets the next node ID of the history data to null. History writing unit 125 writes this history data to blockchain 121. Then, processing proceeds to step S38.

[0111] (S36) History writing unit 125 generates a node ID for successive writing (node ​​A). In addition, history writing unit 125 generates a node ID having a certain relationship with the node ID for successive writing as a node ID for the next history data (node ​​B).

[0112] (S37) The history writing unit 125 adds the node ID (node ​​A) for successive writing generated in step S34 to the received history data. The history writing unit 125 also adds the node ID (node ​​X) of step S30 to the history data as the previous node ID. The history writing unit 125 also adds the other node ID (node ​​B) generated in step S36 to the history data as the next node ID. The history writing unit 125 writes this history data to the blockchain 121.

[0113] (S38) The history writing unit 125 reads out the history data having the node ID (node ​​X) of step S30 from the block chain 121. (S39) The history writing unit 125 sets the next node ID of the history data in step S38 to the node ID for successive writing (node ​​A) generated in step S34. The history writing unit 125 writes the history data with the corrected next node ID to the block chain 121. Then, the history management procedure ends.

[0114] (S40) History writing unit 125 reproduces the current node ID (node ​​A) from the node ID (node ​​X) of step S30 based on a certain relationship. (S41) The history writing unit 125 adds the node ID (node ​​A) of step S40 to the received history data. The history writing unit 125 also adds the node ID (node ​​X) of step S30 to the history data as the previous node ID. The history writing unit 125 also sets the next node ID of the history data to null. The history writing unit 125 writes this history data to the block chain 121.

[0115] As described above, the history management server 100 of the second embodiment uses a block chain to centrally manage history data related to the distribution of target data between companies. This improves the reliability of data distribution management. In addition, the history management server 100 adds a next node ID and a previous node ID to each piece of history data. This allows the history management server 100 to efficiently perform a forward search to search for a distribution state after a certain point in time, and a backward search to search for a distribution state before a certain point in time.

[0116] Furthermore, when there is a high possibility that different history data will be received consecutively, the history management server 100 reserves the node ID of the second history data when it receives the first history data, and adds the reserved node ID to the first history data. This eliminates the need for the history management server 100 to modify the first history data when it receives the second history data, and reduces the number of times the data is written to the blockchain. This reduces the load on the history management server 100, and also reduces invalid history data from the blockchain.

[0117] Furthermore, if there is a low possibility that different history data will be received consecutively, the history management server 100 sets the next node ID of the history data to null. This prevents inconsistencies in which the history data pointed to by the next node ID does not exist in the blockchain, and reduces the risk of problems occurring when searching or displaying history data.

[0118] Furthermore, the history management server 100 predicts consecutive reception of history data based on the history type indicated by the most recent history data. This covers typical processes that are often executed consecutively. Furthermore, the history management server 100 predicts consecutive reception of history data based on a consecutive flag designated by the user. This covers consecutive processes within the same company even if they do not fall under the typical processes described above.

[0119] Furthermore, when the history management server 100 predicts successive reception of history data, it assigns a node ID for successive writing to the first history data. This allows the history management server 100 to efficiently determine that the first history data does not need to be corrected when the second history data is received. Furthermore, the history management server 100 assigns a node ID that can be calculated from the node ID for successive writing to the second history data. This eliminates the need for the history management server 100 to read out the next node ID from the first history data when the second history data is received. [Explanation of symbols]

[0120] 10,20 Information processing device 11 Storage section 12 Processing section 13 Database 14,15 Historical Data 16,17 Identifiers

Claims

1. accepting first history data indicating a first process on the target data; predicting whether second history data indicating a second process for the target data will be accepted after the first history data; when it is predicted that the second history data will be accepted, an identifier for identifying the second history data is acquired before accepting the second history data, the identifier is added to the first history data, and the first history data to which the identifier is added is registered in a database; A history data management program that causes a computer to execute the processing.

2. When it is not predicted that the second history data will be accepted, the first history data without the identifier is registered in the database; When it is not predicted that the second history data will be received and the second history data is received after the first history data, the identifier is acquired and the identifier is added to the first history data registered in the database. causing the computer to further execute the process; 2. The history data management program according to claim 1.

3. whether or not to accept the second history data is predicted based on the type of the first process indicated by the first history data; 2. The history data management program according to claim 1.

4. The reception of the first history data includes a process of further receiving a flag indicating whether or not the second process is scheduled to be performed after the first process, whether or not to accept the second history data is predicted based on the flag; 2. The history data management program according to claim 1.

5. registering the first history data to which the identifier is added includes a process of obtaining another identifier for identifying the first history data and outputting the another identifier; The identifier and the other identifier are acquired so as to have a certain relationship; and further causing the computer to execute a process of receiving the second history data and the other identifier, reproducing the identifier from the other identifier based on the certain relationship, and registering the second history data in the database using the identifier.

2. The history data management program according to claim 1.

6. A storage unit that stores the database; a processing unit that receives first history data indicating a first process on target data, predicts whether or not second history data indicating a second process on the target data will be received after the first history data, and, when it is predicted that the second history data will be received, acquires an identifier that identifies the second history data before receiving the second history data, adds the identifier to the first history data, and registers the first history data with the identifier added in the database; An information processing device having the above configuration.

7. a first information processing device that transmits first history data indicating a first process for target data; a second information processing device that receives the first history data, predicts whether or not second history data indicating a second process on the target data will be received after the first history data, and, when predicting that the second history data will be received, acquires an identifier that identifies the second history data before receiving the second history data, adds the identifier to the first history data, and registers the first history data with the identifier added in a database; An information processing system having the above configuration.

Images