Information processing device and control method thereof

Abstract

To provide a technique to suppress increase in a block chain data region by enabling destruction of documents archived by using block chain technology.SOLUTION: An information processing device stores a plurality of block chain distribution ledgers including registration block chain distribution ledgers that perform new transaction registration processing and registered transaction acquisition processing, and reference block chain distribution ledgers that perform registered transaction acquisition processing without performing new transaction registration. In response to an instruction to remove a reference block chain distribution ledger, the information processing device removes the reference block chain distribution ledger.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to document storage using blockchain technology. [Background technology]

[0002] Countries and companies hold important documents, such as official documents and management documents, but tampering with these important documents has become a problem, and a system that can prevent document tampering or detect tampering is needed. For this reason, it is known to use the hash value of digitized document files to determine whether or not an electronic document file has been tampered with. In addition, documents held by countries and companies are kept for a set period of time, and documents that exceed this period are destroyed.

[0003] On the other hand, blockchain technology is known to be highly tamper-resistant. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2020-178240 Summary of the Invention [Problem to be solved by the invention]

[0005] However, because blockchain technology manages stored data in a chained manner, data cannot be deleted once it has been stored. Therefore, if blockchain technology is simply applied to stored documents, the stored documents cannot be discarded in the future, and as a result, the storage area for blockchain data will continue to expand, and the management costs for operation will also increase.

[0006] The present invention aims to provide a technology that suppresses the expansion of the blockchain data area by making it possible to discard documents stored using blockchain technology. [Means for solving the problem]

[0007] In order to solve the above problem, the information processing device of the present invention includes: a storage means for storing a plurality of blockchain distributed ledgers, including a registration blockchain distributed ledger that performs new transaction registration processing and registered transaction acquisition processing, and a reference blockchain distributed ledger that does not perform new transaction registration processing but performs registered transaction acquisition processing; A deletion means for deleting the reference blockchain distributed ledger upon receiving an instruction to delete the reference blockchain distributed ledger. and a registration means for registering a hash value of the final block of the reference blockchain distributed ledger as a transaction of the registration blockchain distributed ledger when deleting the reference blockchain distributed ledger; The present invention is characterized in that the information processing device has the above-mentioned. [Effects of the Invention]

[0008] According to the present invention, by making it possible to discard documents stored using blockchain technology, it is possible to suppress the expansion of the blockchain data area. [Brief explanation of the drawings]

[0009] [Figure 1] System configuration diagram according to an embodiment [Figure 2] Hardware configuration diagram of a blockchain device and a client PC according to an embodiment [Figure 3] Functional configuration diagram of a blockchain device according to an embodiment [Figure 4] Diagram of distributed ledger group, distributed ledger, and transaction structure according to an embodiment [Figure 5] Functional configuration diagram of a client PC according to an embodiment [Figure 6] Diagram of the distributed ledger group management screen for the first and second embodiments [Figure 7] Flowchart for generating a distributed ledger group according to the first and second embodiments [Figure 8] Flowchart for switching distributed ledgers according to an embodiment [Figure 9] Flowchart for deleting a distributed ledger according to an embodiment [Figure 10] Transaction operation screen configuration diagram according to the first and second embodiments [Figure 11] Flowchart for registering a transaction according to the first embodiment [Figure 12] Flowchart for acquiring a transaction according to the first embodiment [Figure 13] Flowchart for registering a transaction according to the second embodiment [Figure 14] Flowchart for acquiring a transaction according to the second embodiment [Figure 15] Functional configuration diagram of a blockchain device according to a third embodiment [Figure 16] Structural diagram of distributed ledger group management according to embodiment 3 [Figure 17] Diagram of the distributed ledger group management screen for the third embodiment [Figure 18] Flowchart for adding a distributed ledger group according to the third embodiment [Figure 19] Transaction operation screen configuration diagram according to the third embodiment [Figure 20] Flowchart for registering a transaction according to the third embodiment [Figure 21] Flowchart for acquiring a transaction according to the third embodiment [Figure 22] Flowchart for updating a transaction according to the third embodiment [Figure 23] Distributed Ledger Group according to the embodiment DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0011] <Embodiment 1> FIG. 1 is an overall diagram of a system related to a blockchain device 111. In this embodiment, a PC 101 is connected to a LAN 100 and exists within an intranet, and communicates with the blockchain device 111 via the Internet 110. The PC 101 is used to use the functions of the blockchain device 111 using a web browser. In this embodiment, a single PC 101 is used to explain the functions, but this does not restrict multiple PCs 101 from connecting to the blockchain device 111 via the LAN 100. Here, the blockchain device 111 and PC 101 will be described, but both are information processing devices.

[0012] The blockchain device 111 is a device for managing information using a highly tamper-resistant blockchain method by accepting information generated by the PC 101 as a transaction and managing it as a block. This blockchain device 111 can also be configured with multiple devices. In this embodiment, the intranet LAN 100 and the Internet 110 are configured separately, but this does not limit the configuration to one in which all devices are directly connected to the Internet or to the LAN 100.

[0013] Figure 2 is a block diagram showing the hardware configuration of the computers PC 101 and blockchain device 111.

[0014] The central processing unit (CPU) 202 controls the entire device. The CPU 202 executes application programs, the OS, and other programs stored on the hard disk (HDD) 205. It also controls the temporary storage of information, files, and other information required for program execution in the random access memory (RAM) 203. The read-only memory (ROM) 204 is a storage unit (storage section) that stores various data, such as basic I / O programs. The RAM 203 is a temporary storage unit and functions as the CPU 202's main memory and work area. The HDD 205 is an external storage unit that functions as a large-capacity memory and stores application programs, such as office applications and web browsers, the OS, and related programs. The display 206 is a display unit that displays commands entered via the keyboard / mouse 207, which is an instruction input unit. The interface 208 is an external device interface that connects printers, USB devices, and peripheral devices. The system bus 201 controls the flow of data within the device. A network interface card (hereinafter referred to as NIC) 209 exchanges data with external devices via the LAN 100. Note that the above-described computer configuration is an example and is not limited to the configuration example of FIG. 2. For example, the storage location of data and programs can be changed to ROM 204, RAM 203, HDD 205, etc. depending on the characteristics of the data and programs. Unless otherwise specified in this embodiment, various processes are realized by loading programs stored in ROM 204, etc. into RAM 203, etc. and executing them by CPU 202.

[0015] 3 is a block diagram showing the software configuration related to the present invention in the blockchain device 111. Unless otherwise specified, each processing unit is a control program stored in the ROM 204 of the blockchain device 111.

[0016] The distributed ledger data storage unit 301 is a memory area for storing data related to the distributed ledger shown later in Figure 4. This data is stored in the form of a database, file, or other format on the HDD 205. The distributed ledger processing control unit 302 controls distributed ledger processing using the data in the distributed ledger data storage unit 301 described above, and realizes the functionality of the blockchain.

[0017] The distributed ledger management data storage unit 303 is a storage area that holds information for managing the distributed ledger implemented in this embodiment. Like the distributed ledger data storage unit 301, this data is stored in the HDD 205 in the form of a database, file, or the like.

[0018] The distributed ledger management processing control unit 304 controls the management processing of the distributed ledger using the data in the aforementioned distributed ledger management data storage unit 303. The communication control unit 305 receives processing requests sent from the web browser of the external device, PC 101, via the Internet 110. It then starts the specified processing of the distributed ledger management processing control unit 304 and returns the processing results to PC 101, the source of the request, acting as a liaison with other network devices.

[0019] Figure 4 is a block diagram showing the data structures of transactions 401, blocks 411, distributed ledger 421, and distributed ledger groups 431, which are data units held by the blockchain device 111. The blockchain device 111 is a device that manages data using a method called blockchain. In this blockchain method, information is handled in units called transactions 401, as shown in Figure 4(a). A transaction consists of a key 402 that uniquely represents the transaction and data 403 that is linked to the stored key 402. The data format that can be held in transaction 401 can be defined by the user, so there are no particular restrictions on the format of key 402 or the structure of data 403. As a structure for managing this transaction 401, blocks 411 and distributed ledger 421 shown in Figure 4(b) are formed.

[0020] Block 411 is composed of multiple transactions 401 (five in this embodiment) and block management data: a distributed ledger ID 412, a block hash value 413, and a previous block hash value 414. In this diagram, the relationship between blocks is explained using blocks 415 and 416, which have the same configuration as block 411. The distributed ledger ID 412 is a value that defines the distributed ledger 421 to which block 411 belongs as the first digit. The block hash value 413 is a hash value created using all transactions when the transactions included in the block are confirmed. In this diagram, a hash value calculated from five transactions, including transaction 401(a) and transaction 401(b), is stored. By storing this value, it is possible to detect tampering with the contents of transaction 401 in block 411. The previous block hash value 414 stores the block hash value 413 of block 411, which was confirmed before the current block.

[0021] In this embodiment, because block 411 is the first block registered in the distributed ledger, NULL (no value) is set as the previous block hash value 414. Block 415 has the block hash value 413 of block 411 as its previous block hash value. Block 416 also has the block hash value 413 of block 415 as its previous block hash value. This results in a chain of blocks in the order of block 411, block 415, and block 416, which requires processing to maintain consistency for all blocks in the event of tampering with some of the blocks, resulting in a configuration with strong tamper-resistance.

[0022] In this embodiment, as shown in Figure 4(c), a distributed ledger group 431 is used as a unit for managing multiple distributed ledgers 421. This distributed ledger group 431 manages multiple distributed ledgers, from distributed ledger 421(a) to distributed ledger 421(c), in a configuration in which they are linked in the order in which they were created. To achieve this, the position of the aforementioned transaction 401(a), which is the beginning of the first block 411 of the distributed ledger 421, is configured to hold information for linking the distributed ledgers 421. Specifically, the first transaction 432(a) of the first distributed ledger 421(a) in the distributed ledger group 431 is the first distributed ledger 421 in the distributed ledger group, so a transaction 401 with the following value is registered:

[0023] Key 402: RELATED_DATA (fixed) Data 403: NULL (no value) Distributed ledger 421(b) is the distributed ledger that follows distributed ledger 421(a), and for the first transaction 432(b), a transaction 401 that holds the following value is generated and registered in a block.

[0024] Key 402: RELATED_DATA (fixed) Data 403: Block hash value 413 of the last block 411 recorded in the previous distributed ledger 421(a) Similarly, the block hash value 413 held by the last block 411 of the distributed ledger 421(b) is registered as transaction 432(c) in the distributed ledger 421(c). This forms a distributed ledger group 431 by linking the distributed ledgers 421. To manage this distributed ledger group 431, information is stored in the format of Table 1 and Table 2 in the distributed ledger management data storage unit 303.

[0025] [Table 1]

[0026] Table 1 is a table that stores definition information representing the distributed ledger group itself. The distributed ledger group name is the name of the distributed ledger group 431 presented to users. This information is used for display on screens, etc. The data validity period is information indicating the period during which transaction data 401 registered in the distributed ledger group 431 is considered valid. Transaction data 401 that has passed this period is treated as non-existent or invalid. The distributed ledger retention period is information indicating the period during which the distributed ledger 421 belonging to the distributed ledger group 431 is held. The value that can be set for this distributed ledger retention period is the same as or greater than the data validity period. This period cannot be shorter in order to ensure that the aforementioned data validity period determines whether a transaction 401 is valid. In this embodiment, the data validity period and distributed ledger retention period are described as being in years, but other units such as months or days can also be used. The URL is information that uniquely represents the distributed ledger group used to access the distributed ledger group.

[0027] [Table 2]

[0028] Table 2 is a table that stores information representing the distributed ledgers 421 that make up the distributed ledger group 431.

[0029] The distributed ledger ID is information that uniquely identifies the distributed ledger 421. In this embodiment, it is issued when the distributed ledger 421 is created, and is set in the distributed ledger ID 412 of each block 411 that constitutes it.

[0030] The ledger type is information that indicates the role of the constituent distributed ledger 421. In this embodiment, three types are used: "preparation," "registration," and "reference." In this embodiment, the distributed ledger 421 is operated as follows. First, when the distributed ledger 421 is created, information is registered as the "preparation" ledger type. Next, when preparation for use is complete, the ledger changes to the "registration" type, becoming a distributed ledger 421 that registers new transactions 401 (a registration blockchain distributed ledger). A "registration" type distributed ledger changes to the "reference" type through the distributed ledger switching process described later in Figure 8, becoming a distributed ledger 421 that only provides owned transaction information (a reference blockchain distributed ledger). The usage start date is information that indicates the date on which each distributed ledger begins to be used. The type change date is information that indicates the date on which the ledger type was changed. The URL is information that uniquely identifies the distributed ledger used when accessing the distributed ledger. The registration blockchain distributed ledger is capable of performing new transaction registration processing and registered transaction retrieval processing. In addition, the reference blockchain distributed ledger does not register new transactions but performs a registered transaction acquisition process. In this embodiment, the hash value of the last block of the reference blockchain distributed ledger is registered as the first transaction of a blockchain distributed ledger different from the reference blockchain distributed ledger.

[0031] Figure 5 is a block diagram showing the functional configuration of the PC 101 that accesses the blockchain device 111. Unless otherwise specified, each processing unit is a control program stored in the ROM 204 of the PC 101. The transaction data storage unit 501 is a storage area for transaction data obtained by accessing the blockchain device 111. This is saved in the HDD 205 in the form of a database, file, or the like. The blockchain access control unit 502 performs processing for accessing the blockchain device 111. In this embodiment, the blockchain device 111 is accessed via a web browser, so it has the functions of web browser control, display, and data communication, and connects to the blockchain device 111 via a communication control unit 503, which will be described later. The communication control unit 503 is connected to the LAN 100 and controls communication with the blockchain device 111 via the Internet 110.

[0032] The blockchain management screen 600 in Figure 6 is an example screen for managing the distributed ledger group 431 and distributed ledger 421 of the blockchain device 111, and provides a UI and functions for performing various tasks on the blockchain device 111.

[0033] The blockchain management screen 600 is configured as a web browser, and a description of the standard features of a web browser, such as menus and URL display, will be omitted. The display area 601 is an area that displays the components of the management screen. Although not shown, if there is a lot of content to display and it cannot all be displayed in the area, up, down, left, and right scroll bars are displayed to allow all of it to be displayed. The input area 602 is an area for displaying / inputting the configuration information of the blockchain device 111, and in this embodiment, it consists of a distributed ledger group name 603, a data validity period 604, a distributed ledger retention period 605, and a usage start date 606. The distributed ledger group name 603 is an area for specifying and displaying the distributed ledger group name information in Table 1 above. The data validity period 604 is an area for specifying and displaying the data validity period information in Table 1 above. In this embodiment, the settable period is in years. The distributed ledger retention period 605 is an area for specifying and displaying the distributed ledger retention expiration information in Table 1 above. In this embodiment, the settable period is in years. The usage start date 606 is an area where the usage start date of the distributed ledger group to be created is specified and displayed. When this screen is displayed, the blockchain access control unit 502 requests the communication control unit 305 of the blockchain device 111 via the communication control unit 503 to obtain distributed ledger group information. Upon receiving the request, the communication control unit 305 instructs the distributed ledger management processing control unit 304 to obtain the distributed ledger group information. The distributed ledger management processing control unit 304 obtains the data in Table 1 stored in the distributed ledger management data storage unit 303 and provides it via the communication control unit 305. Upon receiving the information, this screen displays the contents in each element of the input area 602.

[0034] The Create Group button 607 is a button for performing the process of creating a new distributed ledger group, and pressing it executes the flowchart in Figure 7. This button is only available for pressing if no data was received at the time of the above display.

[0035] The distributed ledger switch button 608 is a button for performing the process to switch the role of the distributed ledger, and pressing it executes the flowchart in Figure 8, which will be described later. The distributed ledger deletion button 609 is a button for performing the process to delete a distributed ledger whose retention period has expired, and pressing it executes the flowchart in Figure 9, which will be described later.

[0036] FIG. 7 is a flowchart showing the process of generating a distributed ledger group 431 in the blockchain device 111.

[0037] In this embodiment, a procedure is described in which a user uses the distributed ledger group generation process of the blockchain device 111 via a web browser on the PC 101. However, the process of this flowchart is not limited to, for example, scheduling and periodically executing it on the blockchain device 111. In this flowchart, when the group generation button 607 is pressed on the blockchain management screen 600, a generation process request is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. The generation process request received by the communication control unit 305 is passed to the distributed ledger management process control unit 304 and executed by the CPU 201. At this time, the values ​​of the distributed ledger group name 603, data validity period 604, distributed ledger retention period 605, and usage start date 606 entered on the blockchain management screen 600 are passed from the PC 101 to the blockchain device 111.

[0038] In step S701, the distributed ledger group name 603, data validity period 604, and distributed ledger retention period 605 received from PC 101 are stored in the distributed ledger management data storage unit 303 in the format of Table 1, generating a distributed ledger group 431. In step S702, a distributed ledger 421 to be registered in the generated distributed ledger group 431 is generated, and the following information is set as the distributed ledger information in Table 2.

[0039] Distributed ledger ID: Distributed ledger ID 412 set when the distributed ledger 421 was created Ledger type: "Preparation" Start date: Value of start date 606 Type change date: Setting date URL: Access URL to the distributed ledger The generation of the distributed ledger itself in a blockchain depends on the platform used, and in this embodiment, the generation procedure will not be described.

[0040] In step S703, the following transactions, which were also explained in FIG. 4(c), are registered in the generated distributed ledger 421.

[0041] Key 402: RELATED_DATA (fixed) Data 403: NULL (no value) In step S704, since the distributed management ledger is now ready for use, the following information in the distributed ledger definition is changed.

[0042] Ledger type: "Registration" Type change date: Setting date After the processing of this flowchart is completed, the results are notified to the PC 101 that requested the processing. Upon receiving the notification, the PC 101 displays the processing results on its screen.

[0043] Figure 8 is a flowchart showing the process of generating a new distributed ledger 421 in the blockchain device 111 and switching an existing registered distributed ledger to a reference distributed ledger.

[0044] This embodiment describes a case where a user uses the distributed ledger switching process of the blockchain device 111 via a web browser on the PC 101. The processing of this flowchart can also be implemented in a form where the blockchain device 111 automatically executes the process periodically in accordance with the data validity period information of the distributed ledger group definition information in Table 1. In this case, it is possible to schedule the start date of use of distributed ledger information whose ledger type is "Registered" plus the data validity period of the distributed ledger group definition information. In this flowchart, when the distributed ledger switch button 608 is pressed on the blockchain management screen 600, the communication control unit 503 of the PC 101 notifies the communication control unit 305 of the blockchain device 111 of a distributed ledger switching process request. The distributed ledger switching process request received by the communication control unit 305 is passed to the distributed ledger management process control unit 304 and executed by the CPU 201.

[0045] In step S801, the distributed ledger group definition information in Table 1 and the distributed ledger information in Table 2 are obtained from the distributed ledger management data storage unit 303. In step S802, a distributed ledger 421 is generated to be added to the distributed ledger group 431 described in the distributed ledger group definition information obtained in step S801, and the following information is set as the distributed ledger information in Table 2.

[0046] Distributed ledger ID: Distributed ledger ID 412 set when the distributed ledger 421 was created (here, "DL-004") Ledger type: "Preparation" ·Start date of use: Setting date Type change date: Setting date URL: Access URL to the distributed ledger Note that the generation of the distributed ledger itself in a blockchain depends on the platform used, and in this embodiment, the description of the generation procedure will be omitted.

[0047] In step S803, distributed ledger information whose ledger type is "registered" is obtained, and the ledger type is changed to "reference." In step S804, the last block 411 of the distributed ledger 421 indicated by the distributed ledger ID of the distributed ledger information obtained in step S803 is confirmed, and the block hash value 413 is calculated and set. As a result, the distributed ledger 421 processed in this step becomes a distributed ledger that will no longer be registered.

[0048] In step S805, the management transaction 401 using the block hash value 413 calculated in step S804 is registered in the distributed ledger 421 with the distributed ledger ID DL-004 generated in step S802.

[0049] Key 402: RELATED_DATA (fixed) Data 403: Block hash value 413 calculated in step S804 In step S806, the ledger type and type change date registered as distributed ledger information in Table 2 in step S802 are updated with the following information.

[0050] Ledger type: "Registration" Start date: Date of change Type change date: Date of change This completes the process. Execution of this flowchart switches the distributed ledger to which the transaction is registered.

[0051] Figure 9 is a flowchart showing the process of deleting the distributed ledger 421 in the blockchain device 111. In this embodiment, a case will be described in which a user uses the distributed ledger deletion process of the blockchain device 111 via a web browser on the PC 101. However, the process of this flowchart can also be realized in a form in which it is performed in conjunction with the distributed ledger switching process of Figure 8, for example, or is automatically executed periodically.

[0052] The Delete distributed ledger button 609 is pressed on the blockchain management screen 600. As a result, in this flowchart, a request for a distributed ledger deletion process is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. The request for a distributed ledger deletion process received by the communication control unit 305 is passed to the distributed ledger management process control unit 304 and executed by the CPU 201.

[0053] In step S901, the distributed ledger group definition information in Table 1 and the distributed ledger information in Table 2 are obtained from the distributed ledger management data storage unit 303. In step S902, one piece of data that has not yet been selected in this step and whose ledger type indicates "reference" is selected from the distributed ledger information obtained in step S901. In step S903, if the distributed ledger information was obtained in step S902, the process proceeds to the next step, S904. If there is no target information to obtain, this flowchart ends.

[0054] In step S904, the remaining retention period of the target distributed ledger 421 is calculated using the distributed ledger group definition information acquired in step S901 and the distributed ledger information selected in step S902 using the following formula.

[0055] Remaining storage period = Start date of use + Distributed ledger storage period - Execution date of this flowchart In step S905, it is determined whether the retention period has expired based on whether the remaining retention period calculated in step S904 indicates a negative value. If it indicates a negative value and the retention period has expired, the process proceeds to step S906, and if it has not expired, the process returns to step S902.

[0056] In step S906, the distributed ledger group containing the distributed ledger to be deleted is modified. Specifically, a transaction indicating that the distributed ledger to be deleted has been deleted is registered in the distributed ledger group 431 to which it belongs. Figure 23 shows a schematic diagram of the distributed ledger group 431 illustrating this process. Figure 23 explains the parts related to this step when deleting a distributed ledger, based on the distributed ledger configuration of the distributed ledger group 431 shown in Figure 4(c).

[0057] In Figure 23, the target for deletion is the reference distributed ledger 421(a), and the last block hash value 2301 of this reference distributed ledger 421(a) is added as transaction 2302 to the registered distributed ledger 421(c) of the same distributed ledger group 431.

[0058] The information of the transaction 2301 registered in this step is as follows:

[0059] Key 402: DELETED_DATA (fixed) Data 403: Block hash value 413 of the last block 411 recorded in the reference distributed ledger 421(a) to be deleted This makes it possible to prove that the value of the first transaction 411, which indicates the linkage of distributed ledgers registered in the distributed ledger 421 that becomes the first after deleting the reference distributed ledger in step S907 described below, is that of the deleted distributed ledger. As a result, it is possible to verify that there are no data inconsistencies in the distributed ledger group 43. In step S907, the distributed ledger 421 that matches the distributed ledger ID of the distributed ledger information selected in step S902 is deleted. In this step, the distributed ledger management processing control unit 304 requests the distributed ledger processing control unit 302 to perform distributed ledger deletion processing by specifying the distributed ledger ID. The distributed ledger processing control unit 302 deletes the target distributed ledger in accordance with the procedures of the blockchain platform used. In step S908, the distributed ledger information selected in step S902 is deleted from Table 2 of the distributed ledger management data storage unit 303.

[0060] As a result, it is possible to safely delete retained data that is no longer needed in data management using the blockchain, which is a feature of this embodiment.

[0061] Figure 10 is an example of a transaction operation screen. The blockchain access screen 1000 is an example of a screen provided to the user by the blockchain device 111 to register or acquire a transaction 401. The blockchain access screen 1000 is configured as a web browser, and explanations of the standard features of a web browser, such as menus and URL displays, will be omitted. The display area 1001 is an area that displays the components of the access screen. Although not shown, if there is too much content to display in the area, scroll bars on the top, bottom, left, and right are displayed to allow all of the content to be displayed.

[0062] The components of this display area 1001 can be obtained by accessing the URLs held by the blockchain device 111 in Table 1.

[0063] Key information 1002 is a location for inputting or displaying information that uniquely represents information to be registered as a transaction. In this embodiment, it is assumed that a hash value calculated from the document file to be registered is input. Registration data 1003 is a location for inputting or displaying information to be linked to the information uniquely represented by the key information 1002 described above. In this embodiment, it is assumed that bibliographic data held by the document file (e.g., creator, creation location, document file name, etc.) is input. Validity period 1004 displays a value indicating the period for which information will be held in this distributed ledger group 431. In this embodiment, the retention period is determined when the distributed ledger group 431 is created, so it is provided as a function that simply displays the set value.

[0064] The register button 1005 is a button for executing the registration process of the transaction 401, which will be described later in Fig. 11, and is enabled when values ​​are entered in the above-mentioned key information 1002 and registration data 1003. The acquire button 1006 is a button for executing the acquisition process of the transaction 401, which will be described later in Fig. 12, and is enabled when a value is entered in the above-mentioned key information 1002.

[0065] FIG. 11 is a flowchart showing the process of registering a transaction 401 in the distributed ledger 421 in the blockchain device 111. In this embodiment, a user requests registration of the transaction 401 in the distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be implemented in a manner in which it is executed in cooperation with another system, and the processing form is not limited. Key information 1002 and registration data 1003 are entered on the blockchain access screen 1000, and the register button 1005 is pressed. As a result, this flowchart shows that a transaction registration process request is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. At this time, the values ​​of the key information 1002 and registration data 1003 entered on the blockchain access screen 1000 are also transmitted. The transaction registration processing request received by communication control unit 305 and the input values ​​of key information 1002 and registration data 1003 are passed to distributed ledger management processing control unit 304 and executed by CPU 201.

[0066] In step S1101, the key information 1002 and registration data 1003 entered via the web browser of PC 101 are obtained. In step S1102, distributed ledger data with a ledger type of "registration" from the distributed ledger information in Table 2 is obtained from the distributed ledger management data storage unit 303. In step S1103, it is determined whether the distributed ledger management data obtained in step S1102 exists. If it exists, proceed to step S1104; if it does not exist, proceed to step S1106.

[0067] In step S1104, the distributed ledger ID of the distributed ledger data obtained in step S1102, and the key information 1002 and registration data 1003 obtained in step S1101 are passed to the distributed ledger processing control unit 302 to request registration processing of transaction 401. The distributed ledger processing control unit 302 creates and registers the following transaction 401 in the distributed ledger with the corresponding split ledger ID.

[0068] Key 402: Key information 1002 Data 403: Registration Data 1003 The process of registering a transaction in a distributed ledger depends on the platform used, and in this embodiment, the registration procedure will not be described here.

[0069] In step S1105, the transaction registration result in step S1104 is notified to PC 101. In step S1106, an error is notified to PC 101 to the effect that the distributed ledger to be registered does not exist.

[0070] After this flowchart is completed, the registration results and errors are displayed on the screen of PC101, but this is done using a standard dialog (not shown) provided by the OS and web browser, and explanations thereof will be omitted in this embodiment.

[0071] FIG. 12 is a flowchart showing the process of acquiring registration data from a specific distributed ledger 421 in the blockchain device 111. In this embodiment, a user requests the acquisition of a transaction 401 from the distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be implemented in a manner in which it is executed in cooperation with another system, and the processing form is not limited. Key information 1002 is entered on the blockchain access screen 1000, and the acquire button 1006 is pressed. As a result, this flowchart shows that a transaction acquisition processing request is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. At this time, the PC 101 also transmits the value of the key information 1002 entered on the blockchain access screen 1000. The transaction acquisition processing request and the input value of the key information 1002 received by the communication control unit 305 are passed to the distributed ledger management processing control unit 304 and executed by the CPU 201.

[0072] In step S1201, the key information 1002 entered via the web browser of PC 101 is obtained. In step S1202, all distributed ledger data whose ledger type is "registration" or "reference" from the distributed ledger group definition information in Table 1 and the distributed ledger information in Table 2 is obtained from the distributed ledger management data storage unit 303 and stored in RAM 203.

[0073] In step S1203, one piece of distributed ledger data with the most recent type change date is selected from the distributed ledger information acquired in step S1202 and stored in RAM 203. In step S1204, a determination is made as to whether the distributed ledger data to be selected in step S1203 exists, and if it exists, the process proceeds to step S1205; if it does not exist, the process proceeds to step S1208. In step S1205, the distributed ledger ID of the distributed ledger data selected in step S1203 and the key information 1002 acquired in step S1201 are passed to the distributed ledger processing control unit 302, and a request is made to acquire transaction 401. The distributed ledger processing control unit 302 searches the distributed ledger with the corresponding split ledger ID for transaction 401 whose key 402 has the value of key information 1002, and if a match is found, the search is passed to the distributed ledger management processing control unit 304.

[0074] The transaction search process in the distributed ledger processing control unit 302 depends on the blockchain platform used, and in this embodiment, the description of the search procedure will be omitted.

[0075] In step S1206, it is determined whether the transaction 401 acquired in step S1205 exists, and if it does exist, the process proceeds to the next step S1207. If it does not exist, the process returns to step S1203 to search for the next distributed ledger. At this time, the distributed ledger data selected in S1203 is deleted from RAM 203.

[0076] In step S1207, the acquired data 403 of transaction 401 is notified to PC 101. In step S1208, PC 101 is notified of an error that transaction data matching the specified key information 1002 does not exist. After this flowchart is completed, if data 403 was successfully acquired, it is displayed in registered data 1003 on the screen of PC 101. If an error notification is received, the content to that effect is displayed in a standard dialog box (not shown) of the OS or web browser, as in the flowchart of FIG. 11.

[0077] In steps S1203 to S1206, the search is performed starting from the distributed ledger with the most recent type change date, but it is also possible to search the distributed ledgers sequentially based on a predetermined rule.

[0078] As described above, according to the first embodiment, when managing data with a retention period using a blockchain, transaction data whose retention period has expired can be deleted while safely operating a distributed ledger. This makes it possible to reduce the amount of data stored in the blockchain, thereby reducing operational costs.

[0079] <Embodiment 2> In this embodiment, an embodiment will be described in which the transaction acquisition method is different from that of embodiment 1. In this embodiment, the distributed ledger management part shown in Figures 1 to 10 has the same configuration, so the explanation will be omitted, and the difference between them, the transaction registration process and the transaction acquisition process, will be explained using Figures 13 and 14.

[0080] FIG. 13 is a flowchart showing the process of registering a transaction 401 in the distributed ledger 421 in the blockchain device 111. In this embodiment, a user requests registration of the transaction 401 in the distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be implemented in a manner in which it is executed in cooperation with another system, and the processing form is not limited. Key information 1002 and registration data 1003 are entered on the blockchain access screen 1000, and the register button 1005 is pressed. As a result, this flowchart shows that a transaction registration process request is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. At this time, the values ​​of the key information 1002 and registration data 1003 entered on the blockchain access screen 1000 are also transmitted. The transaction registration processing request received by communication control unit 305 and the input values ​​of key information 1002 and registration data 1003 are passed to distributed ledger management processing control unit 304 and executed by CPU 201.

[0081] In step S1301, the key information 1002 and registration data 1003 entered via the web browser of PC 101 are obtained. In step S1302, distributed ledger data whose ledger type is "registration" from the distributed ledger information in Table 2 is obtained from the distributed ledger management data storage unit 303.

[0082] In step S1303, it is determined whether the distributed ledger management data obtained in step S1302 exists. If it exists, proceed to step S1304; if it does not exist, proceed to step S1307.

[0083] In step S1304, the distributed ledger ID of the distributed ledger data obtained in step S1302, and the key information 1002 and registration data 1003 obtained in step S1301 are passed to the distributed ledger processing control unit 302 to request registration processing of transaction 401. The distributed ledger processing control unit 302 creates and registers the following transaction 401 in the distributed ledger 421 that has the distributed ledger ID in question.

[0084] Key 402: Key information 1002 Data 403: Registration Data 1003 The process of registering a transaction in a distributed ledger depends on the platform used, and in this embodiment, the registration procedure will not be described here.

[0085] In step S1305, in order to improve the efficiency of transaction processing, an access information key is generated by adding the registered distributed ledger ID to the key information 1002 specified at the time of registration.

[0086] Access information key = distributed ledger ID + key information 1002 In this embodiment, the access information key is explained as being formed by concatenating two pieces of data, but it may also be configured so that the access information key information can be concealed by processing the information as long as it is in a format that can be decrypted.

[0087] In step S1306, the access information key generated in step S1305 is notified to PC 101. In step S1307, an error is notified to PC 101, indicating that the distributed ledger to be registered does not exist.

[0088] After this flowchart is completed, the registration results and errors are displayed on the screen of PC101, but this is done using a standard dialog (not shown) provided by the OS and web browser, and explanations thereof will be omitted in this embodiment.

[0089] FIG. 14 is a flowchart showing the process of acquiring registration data from a specific distributed ledger 421 in the blockchain device 111. In this embodiment, a user requests the acquisition of a transaction 401 from the distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be implemented in a manner in which it is executed in cooperation with another system, and the processing form is not limited. Key information 1002 is entered on the blockchain access screen 1000, and the acquire button 1006 is pressed. As a result, this flowchart shows that a transaction acquisition processing request is sent from the communication control unit 503 of the PC 101 to the communication control unit 305 of the blockchain device 111. At this time, the PC 101 also transmits the value of the key information 1002 entered on the blockchain access screen 1000. The transaction acquisition processing request and the input value of the key information 1002 received by the communication control unit 305 are passed to the distributed ledger management processing control unit 304 and executed by the CPU 201. In this embodiment, the key information 1002 is entered by the user as the key information 1002 entered by the user at the time of registration in step S1301 of Figure 13 described above, or data in the form of the access information key generated in step S1305.

[0090] In step S1401, the key information 1002 entered via the web browser of PC 101 is acquired. In step S1402, the acquired key information 1002 is split into the distributed ledger ID of the access information key and the format of the key information 1002. Then, in the next step S1403, it is determined whether or not the split was successful as the access information key format. If the split was successful, the process proceeds to step S1404; if the split was not successful, the process proceeds to step S1406.

[0091] In step S1404, the distributed ledger data that matches the split distributed ledger ID is obtained from the distributed ledger information in Table 2 and stored in RAM 203. Then, in the next step S1405, it is determined whether the distributed ledger data was obtained. If it was obtained, proceed to step S1407; if it was not obtained, proceed to step S1406.

[0092] In step S1406, distributed ledger data whose ledger type is "registration" or "reference" is obtained from the distributed ledger group definition information in Table 1 and the distributed ledger information in Table 2 from the distributed ledger management data storage unit 303 and stored in RAM 203. In step S1407, one piece of distributed ledger data with the most recent type change date is selected from the distributed ledger data obtained in step S1404 or step S1406 and stored in RAM 203.

[0093] In step S1408, it is determined whether the distributed ledger data selected in step S1407 exists, and if it exists, proceed to step S1409, and if it does not exist, proceed to step S1412. In step S1409, a request is made to acquire transaction 401. The distributed ledger ID of the distributed ledger data selected in step S1407 and the key information extracted from the access information key in step S1402, or if extraction was not possible, the key information 1002 acquired in step S1401, are passed to the distributed ledger processing control unit 302. Then, a request is made to acquire transaction 401. The distributed ledger processing control unit 302 searches the distributed ledger with the corresponding split ledger ID for transaction 401 whose key 402 has the value of key information 1002, and if a match is found, it is passed to the distributed ledger management processing control unit 304.

[0094] The transaction search process in the distributed ledger processing control unit 302 depends on the blockchain platform used, and in this embodiment, the description of the search procedure will be omitted.

[0095] In step S1410, it is determined whether the transaction 401 obtained in step S1409 exists, and if it does exist, the process proceeds to the next step S1411. If it does not exist, the distributed ledger data selected in step S1407 is deleted from RAM 203 in order to search the next distributed ledger, and then the process returns to step S1407.

[0096] In step S1411, the acquired data 403 of the transaction 401 is notified to the PC 101.

[0097] In step S1412, the PC 101 is notified of an error that transaction data matching the specified key information 1002 does not exist.

[0098] After this flowchart is completed, if data 403 is successfully acquired, it is displayed in registered data 1003 on the screen of PC 101. If an error notification is received, the content of the error is displayed in a standard dialog box (not shown) of the OS or web browser, similar to the flowchart in FIG.

[0099] As described above, according to the second embodiment, in addition to the first embodiment, an item that can identify the registered distributed ledger is added and provided to the user. This allows transactions to be searched efficiently, and performance can be improved when used by users.

[0100] <Embodiment 3> In this embodiment, in addition to the above-mentioned embodiments 1 and 2, an embodiment for managing multiple distributed ledger groups 431 will be described. This embodiment enables data management corresponding to the retention period of each individual document. This embodiment will be described as a difference from embodiments 1 and 2, and parts not described here are the same as embodiment 1 or 2.

[0101] Figure 15 is a block diagram showing the software configuration of the blockchain device 111 in this embodiment. Unless otherwise specified, each processing unit is a control program stored in the ROM 204 of the blockchain device 111. The distributed ledger data storage unit 1501, distributed ledger processing control unit 1502, and communication control unit 1505 are the same as the distributed ledger data storage unit 301, distributed ledger processing control unit 302, and communication control unit 305 in Figure 3 of embodiment 1. The difference in this embodiment is that the storage and control of the distributed ledger group information that was previously held in the fixed distributed ledger management data storage unit 303 are now separated.

[0102] The distributed ledger management data storage unit 1503 is a storage area that holds information for managing the distributed ledger implemented in this embodiment. Like the distributed ledger data storage unit 1501, this data is stored in the form of a database, file, or the like on the HDD 205. The distributed ledger management processing control unit 1504 controls the processing for managing the distributed ledger using the data in the distributed ledger management data storage unit 1503 described above.

[0103] The group management data storage unit 1506 is a storage area that holds information for managing distributed ledger groups. Like the distributed ledger data storage unit 1501 and the distributed ledger temporary data storage unit 1503, this is stored in the form of a database or file on the HDD 205. The group management processing control unit 1507 controls the processing for managing distributed ledger groups using the data in the group management data storage unit 1506 described above.

[0104] 16 is a diagram showing the data structure of the distributed ledger group management 1601 held by the blockchain device 111. In this embodiment, the distributed ledger group management 1601 will be explained as including two groups: a distributed ledger group 431(a) and a distributed ledger group 431(b).

[0105] [Table 3]

[0106] Table 3 is a table that stores the information that makes up the distributed ledger group management 1601. It is held in the group management data storage unit 1506 mentioned above, and data manipulation is performed by the group management processing control unit 1507. The distributed ledger group management ID is information that uniquely represents the distributed ledger group management 1601. The distributed ledger group management name is the name of the distributed ledger group management used to present the distributed ledger group management 1601 to users. The URL is unique connection information for access from users at the distributed ledger group management unit.

[0107] In this embodiment, data for managing one distributed ledger group is presented, but it is also possible to manage multiple data with different distributed ledger group management IDs. Furthermore, in order to manage distributed ledger groups, information is added to Tables 1 and 2 in Figure 4, as explained in the first embodiment, and the information is stored in the form of Tables 4 and 5.

[0108] [Table 4]

[0109] Table 4 is a table that stores definition information representing a distributed ledger group 431. It is stored in the group management data storage unit 1506 described above, and data manipulation is performed by the group management processing control unit 1507. Unlike embodiment 1, this embodiment manages multiple distributed ledger groups 431, and therefore has a distributed ledger group management ID and a distributed ledger group ID in addition to the configuration of Table 1 in embodiment 1 to identify each distributed ledger group 431. All other items are the same as those in Table 1, so explanation will be omitted. The distributed ledger group management ID indicates which distributed ledger group management it belongs to, possessing one of the distributed ledger group management IDs in Table 3 described above. The distributed ledger group ID is information that uniquely identifies a distributed ledger group 431. In this embodiment, a distributed ledger group 431 can be identified by this distributed ledger group ID alone, but it may also be uniquely identified by combining it with the distributed ledger group management ID described above.

[0110] In this embodiment, there are two distributed ledger groups, G-001 and G-002, with different data validity periods. G-001 is a distributed ledger group with a data validity period set to one year, and G-002 is a distributed ledger group with a data validity period set to three years.

[0111] [Table 5]

[0112] Table 5 is a table that stores information representing the distributed ledgers 421 that make up the distributed ledger group 431, and is stored in the distributed ledger management data storage unit 1503 described above, with data manipulation performed by the distributed ledger management processing control unit 1504. In this embodiment, since there are multiple distributed ledger groups, a distributed ledger group ID for identifying the distributed ledger group to which it belongs is added to the configuration of Table 2 in embodiment 1. The other items have the same meanings as in Table 2, so explanations will be omitted.

[0113] The distributed ledger group ID is information that uniquely identifies the distributed ledger group 431 to which each distributed ledger 421 belongs. In this embodiment, it can be seen that the four distributed ledgers 421 belong to one of two distributed ledger groups, G-001 and G-002. In this embodiment, G-001 switches distributed ledgers 421 every year of the data validity period. There is DL-003, which has a ledger type of "registration" and is the destination for new data registration, and DL-002 and DL-001, which have a ledger type of "reference" and have been in use for more than one year. Although DL-001 has already passed its data validity period, it remains retained because the distributed ledger retention period is set to two years. G-002 is in a distributed ledger group with a data validity period of three years, so it is configured to store three years' worth of data in a single distributed ledger 421. As of 2021, three years have not yet passed since the start of use in 2019, so there are no ledger types that have been switched to "reference." In this embodiment, G-002 is described as switching the distributed ledger every data validity period, but this does not limit it to switching the distributed ledger every year and holding three years' worth of data like G-001.

[0114] The blockchain management screen 1700 in Figure 17 is an example of a screen for managing the distributed ledger group management 1501, distributed ledger group 431, and distributed ledger 421 of the blockchain device 111 in this embodiment. It also provides a UI and functions for performing various tasks on the blockchain device 111. The blockchain management screen 1700 is configured as a web browser, as in embodiment 1, and a description of the standard features of a web browser, such as menus and URL display, will be omitted.

[0115] The display area 1701 is an area that displays the components of the management screen. Although not shown, if there is too much content to display in the area, scroll bars on the top, bottom, left, and right are displayed to allow all of the content to be displayed. The distributed ledger group management area 1702 is an area that displays the distributed ledger group management and distributed ledger group data configurations in Tables 3 and 4 above in a tree structure. Since the distributed ledger group management in this embodiment is GM-001, the first level of the tree displays the name of one distributed ledger group management, but if there are multiple distributed ledger group managements, multiple distributed ledger group management names are displayed in the first level. In addition, the second level displays the names of the distributed ledger groups that belong to the distributed ledger group management. The names of the displayed tree levels can be selected. The input field 1703, distributed ledger group name 1704, data validity period 1705, distributed ledger retention period 1706, and usage start date 1707 are the same as the input field 602, distributed ledger group name 603, data validity period 604, distributed ledger retention period 605, and usage start date 606. Therefore, explanation will be omitted.

[0116] The Add Group Management button 1708 is a button for creating new distributed ledger group management data. Pressing it at any time will display a standard dialog with a text input area and a confirm button, allowing the user to enter a distributed ledger group management name. Pressing the OK button will generate group management information by creating the following data in Table 3.

[0117] Distributed ledger group management ID: A unique ID in Table 3 is automatically issued. Distributed ledger group management name: String entered in the text input area URL: A unique URL in Table 3 is automatically generated. After generation, the distributed ledger group management name is displayed in the first layer of the distributed ledger group management area 1702.

[0118] The Add Group button 1709 is a button for creating new distributed ledger group data. It becomes pressable when a distributed ledger management group at the first level is selected in the distributed ledger group management area 1702. In this state, each input field in the input area 1703 is displayed as blank. Pressing this button after entering desired values ​​in each input field starts the distributed ledger group creation process described later in Figure 18. When the distributed ledger group creation process is successfully completed, the registered distributed ledger group name is displayed in the second level in the distributed ledger group management area 1702. The Switch Distributed Ledger button 1710 is a button for switching the role of the distributed ledger. The processing performed when this button is pressed is the same as the distributed ledger switching processing flow described in Figure 8 of the first embodiment. The Delete Distributed Ledger button 1711 is a button for deleting distributed ledgers whose retention period has expired. The processing performed when this button is pressed is the same as the distributed ledger deletion processing flow described in Figure 9 of the first embodiment.

[0119] FIG. 18 is a flowchart showing the process of generating a distributed ledger group 431 of the blockchain device 111 in this embodiment. In this embodiment, a procedure will be described in which a user uses the distributed ledger group generation process of the blockchain device 111 via a web browser on the PC 101. However, the process of this flowchart is not limited to, for example, scheduling and periodically executing the process on the blockchain device 111. The Add Group button 1709 is pressed on the blockchain management screen 1700. As a result, this flowchart notifies the communication control unit 503 of the PC 101 of a group generation process request to the communication control unit 1505 of the blockchain device 111. The generation process request received by the communication control unit 1505 is passed to the group management process control unit 1507 and executed by the CPU 201. At this time, the information input to the blockchain management device 1700 is passed from the PC 101 to the blockchain device 111. The information passed is the distributed ledger group name 1704, data validity period 1705, distributed ledger retention period 1706, usage start date 1707, and the distributed ledger group management ID selected in the distributed ledger group management area 1702.

[0120] In step S1801, the distributed ledger group information in Table 4 that matches the distributed ledger group management ID received from PC101 is obtained from the group management data storage unit 1506. In step S1802, a check is made to see if the distributed ledger group names in the distributed ledger group information obtained in step S1801 contain the same name as the distributed ledger group name 1704 received from PC101. If they do not exist, the process proceeds to the next step S1803, and if they do exist, the process proceeds to step S1806. In step S1803, a check is made to see if the data validity period in the distributed ledger group information obtained in step S1801 contains the same validity period value as the data validity period 1705 received from PC101. If they do not exist, the process proceeds to the next step S1804, and if they do exist, the process proceeds to step S1806.

[0121] In step S1804, the distributed ledger group generation process is performed using the distributed ledger group name 1704, data validity period 1705, distributed ledger retention period 1706, usage start date 1707, and distributed ledger group management ID received from PC101. This process is omitted here because it is the same as the processing flow explained in Figure 7 except for the additional setting of the distributed ledger group management ID in Table 4. In step S1805, the results of the distributed ledger group generation process in step S1804 are notified to PC101, the process requester.

[0122] In step S1806, the result that the group generation process has failed is notified to the PC 101 that requested the process. After the process of this flowchart is completed, the PC 101 that has received the notification may display the process result on the screen.

[0123] The blockchain access screen 1900 in Figure 19 is an example of a screen that the blockchain device 111 provides to the user to register or retrieve a transaction 401.

[0124] The blockchain access screen 1900 is configured as a web browser, and we will not explain the standard features of a web browser, such as menus and URL displays. To display this screen, enter the URL of the distributed ledger group management information listed in Table 3 into the address bar of the web browser.

[0125] Display area 1901 is an area for displaying the components of the access screen. Although not shown, if there is too much content to display in the area, scroll bars on the top, bottom, left, and right are displayed to allow all of the content to be displayed. Key information 1902 and registered data 1903 are the same as key information 1002 and registered data 1003 in Fig. 10, and therefore a description thereof will be omitted.

[0126] The validity period 1904 is the validity period of the transaction specified when registering, and the distributed ledger group to be saved is determined based on this period.

[0127] The register button 1905 is a button that is enabled when values ​​are entered in the above-mentioned key information 1902, registration data 1903, and validity period 1904, and pressing it executes the registration process of transaction 401, which will be described later in Fig. 20. The acquire button 1906 is a button that is enabled when a value is entered in the above-mentioned key information 1902, and executes the acquisition process of transaction 401, which will be described later in Fig. 21. During this acquisition process, an access information key, which will be described later in Fig. 21, may be specified for the key information 1902. The update button 1907 is a button that is enabled when values ​​are displayed in the above-mentioned key information 1902, registration data 1903, and validity period 1904, and pressing it executes the update process of transaction 401, which will be described later in Fig. 22.

[0128] FIG. 20 is a flowchart showing the process of registering a transaction 401 in the distributed ledger 421 of the blockchain device 111 in this embodiment. In this embodiment, a user requests registration of the transaction 401 in the distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be implemented in a manner in which it is executed in cooperation with another system, and the processing format is not limited. Key information 1902, registration data 1903, and validity period 1904 are entered on the blockchain access screen 1900, and the register button 1905 is pressed. As a result, this flowchart shows that a transaction registration processing request is sent from the communication control unit 503 of the PC 101 to the communication control unit 1505 of the blockchain device 111. The transaction registration processing request and the input values ​​of the key information 1902, registration data 1903, and validity period 1904 received by the communication control unit 1505 are passed to the group management processing control unit 1507 and executed by the CPU 201.

[0129] In step S2001, the validity period 1904 received from PC101 is obtained. In step S2002, the target distributed ledger group management ID in Table 3 is obtained from the group management data storage unit 1506 from the URL that received the request. Then, the distributed ledger group information in Table 4 that matches the obtained distributed ledger group management ID is obtained from the group management data storage unit 1506. In step S2003, the data validity period of the distributed ledger group information obtained in step S2002 is compared with the value of validity period 1904 obtained in step S2001. If a matching value exists, proceed to step S2004; if a matching value does not exist, proceed to step S2008.

[0130] In step S2004, the distributed ledger group ID of the distributed ledger group information that matched in the comparison in step S2003 is obtained. In step S2005, the key information 1902 and registration data 1903 are passed to the distributed ledger group with the distributed ledger group ID obtained in step S2004 to perform the registration process for transaction 401. This process is executed by a request from the group management process control unit 1507 to the distributed ledger management process control unit 1504, but is omitted here as it is the same as the transaction registration process flow described in Figure 13 of embodiment 2. After the process is completed, the generated access information key is received.

[0131] In step S2006, group information is further added to the access information key received as a result of the processing in step S2005 to generate a new access information key.

[0132] New access information key = distributed ledger group ID + access information key received in step S2005 As a result, the access information key in this embodiment includes the following three elements.

[0133] Distributed ledger group ID ·Distributed ledger ID Key information 1902 In this embodiment, this access information key is explained by concatenating three pieces of data, but as in embodiment 2, it may be configured to conceal the access information key information by processing the information as long as it is in a format that can be decrypted.

[0134] In step S2007, the access information key generated in step S2006 is notified to PC 101. In step S2008, an error is notified to PC 101 that the distributed ledger to be registered does not exist. After this flowchart is completed, the registration results and errors are displayed on the screen of PC 101; this is done using a standard dialog (not shown) provided by the OS or web browser, and a description thereof will be omitted in this embodiment.

[0135] 21 is a flowchart showing the process of acquiring registration data from a predetermined distributed ledger 421 in the blockchain device 111. In this embodiment, a description is given of a form in which a user requests acquisition of a transaction 401 from a distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be realized in a form in which it is executed in cooperation with another system, and the processing form is not limited thereto.

[0136] Key information 1902 is entered on the blockchain access screen 1900, and the acquire button 1906 is pressed. As a result, in this flowchart, a transaction acquisition processing request is sent from the communication control unit 503 of PC 101 to the communication control unit 1505 of the blockchain device 111. At this time, PC 101 also transmits the value of key information 1902 entered on the blockchain access screen 1900. The transaction acquisition processing request received by the communication control unit 1505 and the input value of key information 1902 are passed to the group management processing control unit 1507 and executed by the CPU 201. In this embodiment, the key information 1902 is entered by the user at the time of registration in step S2001 of Figure 20 described above, or data in the format of the access information key generated in step S2006.

[0137] In step S2101, the key information 1902 received from PC 101 is acquired. In step S2102, the acquired key information 1902 is split into the distributed ledger group ID of the access information key and the access information key format including the distributed ledger ID and key information 1002. Then, in the next step S2103, it is determined whether the split was successful in the form of an access information key. If the split was successful, the process proceeds to step S2104; if the split was not successful, the process proceeds to step S2106.

[0138] In step S2104, the target distributed ledger group management ID in Table 3 is obtained from the group management data storage unit 1506 from the URL that received the request. Then, the distributed ledger group information in Table 4 that matches that distributed ledger group management ID and the distributed ledger group ID obtained in step S2102 is obtained from the group management data storage unit 1506 and stored in RAM 203. In step S2105, it is determined whether the distributed ledger group information was obtained. If it was obtained, proceed to step S2107; if it was not obtained, delete the distributed ledger group information stored in RAM 203 and proceed to step S2106.

[0139] In step S2106, the target distributed ledger group management ID in Table 3 is obtained from the URL that received the request from the group management data storage unit 1506. Then, all distributed ledger group information in Table 4 that matches that distributed ledger group management ID is obtained from the group management data storage unit 1506 and stored in RAM 203.

[0140] In step S2107, one item of distributed ledger group information obtained in step S2104 or step S2106 is obtained. Then, in step S2108, it is determined whether one item of distributed ledger group information was obtained. If it was obtained, the process proceeds to step S2109. If it was not obtained, there were no transactions 401 matching the specified key information, so the process proceeds to step S2112. In step S2109, the distributed ledger group ID is obtained from the distributed ledger group information obtained in step S2107. Then, if the access information key was able to be split in step S2102, the transaction search process is performed using the split access information key. If it was not able to be split, the transaction search process is performed using one of the key information 1902 received in step S2101 and the distributed ledger group ID. This process is the same as the transaction search process described in Figure 14 of embodiment 2, so it is omitted here. Here, after the process is completed, the transaction 401 as a search result is received.

[0141] In step S2110, it is determined whether the desired transaction 401 was obtained as a result of the search in step S2109. If it was obtained, the process proceeds to step S2111. If the transaction 401 was not obtained, the process proceeds to step S2107 to search the next distributed ledger group. In step S2111, the data 403 of the obtained transaction 401 is notified to PC 101. In step S2112, an error is notified to PC 101 that transaction data matching the specified key information 1902 does not exist.

[0142] 22 is a flowchart showing the process of updating the validity period of a transaction whose validity period has expired in the blockchain device 111. In this embodiment, a case will be described in which a user requests an update of the validity period of a transaction 401 from a distributed ledger managed by the blockchain device 111 via a web browser on the PC 101. However, this registration process can also be realized in a form in which it is executed in cooperation with another system, and the processing form is not limited thereto.

[0143] Key information 1902 is entered on the blockchain access screen 1900, and the update button 1907 is pressed. As a result, in this flowchart, a transaction validity period update processing request is notified from the communication control unit 503 of PC 101 to the communication control unit 1505 of the blockchain device 111. At this time, PC 101 also transmits the value of key information 1902 entered on the blockchain access screen 1900. The transaction validity period update processing request received by the communication control unit 1505 and the input value of key information 1902 are passed to the group management processing control unit 1507 and executed by the CPU 201. In this embodiment, the key information 1902 is entered by the user at the time of registration in step S2001 of Figure 20 described above, or data in the format of the access information key generated in step S2006.

[0144] The processing from step S2201 to step S2210 is the same as the processing from step S2101 to step S2110 in FIG. 21 described above, and therefore the description will be omitted in this flowchart.

[0145] In step S2211, transaction 401 is re-registered. The key information 402 and registration data 403 of transaction 401 obtained in step S2209 are passed to the distributed ledger group 431 that has the distributed ledger group ID of the distributed ledger group information obtained in step S2207. Then, transaction 401 is re-registered. This process is executed by a request from the group management process control unit 1507 to the distributed ledger management process control unit 1504, but as this is the same as step S2005 in Figure 20, its explanation will be omitted in this flowchart. This process results in a new transaction being registered in the distributed ledger 421 with a ledger type of "registration", thereby becoming an update process.

[0146] In step S2212, group information is further added to the access information key received as a result of the processing in step S2211 to generate a new access information key. This processing is also the same as step S2006, and therefore a description thereof will be omitted.

[0147] In step S2213, the access information key generated in step S2006 is notified to PC 101. In step S2214, an error in the validity period update process is notified to PC 101. After this flowchart is completed, the update process results and errors are displayed on the screen of PC 101, but this is done using a standard dialog (not shown) provided by the OS or web browser, and a description thereof will be omitted in this embodiment.

[0148] As explained above, according to the third embodiment, in addition to the first and second embodiments, a system is provided to users that is configured to manage multiple distributed ledger groups and centrally manage information with different validity periods, making it possible to apply the system to a wide range of user operations.

[0149] (Other embodiments) The present invention can also be realized by executing the following process. That is, software (programs) that realize the functions of the above-described embodiments are supplied to a system or device via a network or various storage media. Then, the computer (or CPU or MPU) of the system or device reads and executes the programs.

Claims

1. A storage means for storing a plurality of blockchain distributed ledgers, including a registration blockchain distributed ledger that performs new transaction registration processing and registered transaction acquisition processing, and a reference blockchain distributed ledger that does not perform new transaction registration processing but performs registered transaction acquisition processing; A deletion means for deleting the reference blockchain distributed ledger upon receiving an instruction to delete the reference blockchain distributed ledger; An information processing device characterized by having a registration means that, when deleting the reference blockchain distributed ledger, registers the hash value of the final block of the reference blockchain distributed ledger as a transaction in the registration blockchain distributed ledger.

2. 2. The information processing device according to claim 1, wherein the hash value of the final block of the reference blockchain distributed ledger is registered as the first transaction of a blockchain distributed ledger different from the blockchain distributed ledger.

3. An information processing device described in any one of claims 1 to 2, characterized in that the multiple blockchain distributed ledgers are each stored in association with validity period information of transaction data in the blockchain distributed ledger.

4. The storage means stores a plurality of reference blockchain distributed ledgers; The information processing device according to any one of claims 1 to 3, wherein the plurality of reference blockchain distributed ledgers have different validity periods for transaction data.

5. The storage means stores a plurality of registered blockchain distributed ledgers; The information processing device according to any one of claims 1 to 4, wherein the plurality of registered blockchain distributed ledgers have different validity periods for transaction data.

Images