Information processing program, information processing method, and information processing device

Abstract

To flexibly update data.SOLUTION: As shown in a code 1010, in a pseudo manner, a block E1 is connected just before reproduction of a block C1. For example, an information processor for managing the block C1 controls a lineage so that reproduction of the block C1 is generated and is added to the lineage, and the reproduction of the block C1 is connected just after the block E1. For example, the information processor for managing the block D1 controls the lineage so that reproduction of the block D1 is generated and is added to the lineage, and the reproduction of the block D1 is connected just after the reproduction of the block C1.SELECTED DRAWING: Figure 10

Description

Technical Field

[0001] The present invention relates to an information processing program, an information processing method, and an information processing apparatus.

Background Art

[0002] Conventionally, there is a system called CDL (Chain Data Lineage) that generates a series of data blocks each formed to include identifiers of other blocks that exist before and after the block in question for data blocks recording the content of processing and the like. The series of blocks is also called, for example, a hash chain. Each block may be managed by, for example, different computers.

[0003] As a prior art, for example, when executing a first process on first data, there is one that stores pointer information associating a source identifier, which is an identifier of the history of the process on the first data performed before the execution of the first process, and a next identifier, which is an identifier of the history of the first process.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in the prior art, there are cases where the hash chain cannot be updated flexibly. For example, due to the hash chain specification, only at the time of block generation, the identifiers of other blocks existing before the block can be recorded in the block, so it is not possible to connect other blocks after the fact before the block.

[0006] In one aspect, an object of the present invention is to enable flexible updating of data. [Means for solving the problem]

[0007] According to one embodiment, an information processing program, information processing method, and information processing device are proposed to control a plurality of blocks, each of which is formed to include identifiers of other blocks that are linked before and after it, such that the device receives a first request to newly link a second block before a first block managed by the device, and when the first request is received, adds a copy of the first block to the plurality of blocks and links it after the second block.

[0008] According to one embodiment, an information processing program, information processing method, and information processing device are proposed to control a plurality of blocks, each of which is formed to include identifiers of other blocks connected before and after it, such that the device receives a request to invalidate a first block managed by the device, and when the request is received, adds a second block indicating that the first block should be invalidated to the plurality of blocks and connects it after the first block. [Effects of the Invention]

[0009] In one embodiment, it becomes possible to make data flexibly updatable. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is an explanatory diagram showing one embodiment of the information processing method according to the embodiment. [Figure 2] Figure 2 is an explanatory diagram showing an example of the information processing system 200. [Figure 3] Figure 3 is an explanatory diagram (part 1) showing an example of the CDL300. [Figure 4] Figure 4 is an explanatory diagram (part 2) showing an example of the CDL300. [Figure 5] Figure 5 is an explanatory diagram (part 3) showing an example of the CDL300. [Figure 6]FIG. 6 is an explanatory diagram (part 4) showing an example of CDL300. [Figure 7] FIG. 7 is a block diagram showing an example of the hardware configuration of the information processing apparatus 100. [Figure 8] FIG. 8 is a block diagram showing an example of the functional configuration of the information processing apparatus 100. [Figure 9] FIG. 9 is a block diagram showing a specific example of the functional configuration of the information processing system 200. [Figure 10] FIG. 10 is an explanatory diagram showing a first example of the operation of the information processing apparatus 100. [Figure 11] FIG. 11 is an explanatory diagram showing a second example of the operation of the information processing apparatus 100. [Figure 12] FIG. 12 is an explanatory diagram showing an example of registering new data in the first specific example. [Figure 13] FIG. 13 is a flowchart showing an example of the company registration processing procedure in the first specific example. [Figure 14] FIG. 14 is a flowchart showing an example of the new registration processing procedure in the first specific example. [Figure 15] FIG. 15 is a flowchart showing an example of the modification registration processing procedure in the first specific example. [Figure 16] FIG. 16 is an explanatory diagram showing an example of the lineage 1600 representing a branch. [Figure 17] FIG. 17 is an explanatory diagram showing an example of storing the connection state of the lineage 1600. [Figure 18] FIG. 18 is an explanatory diagram showing an example of the lineage 1800 representing a confluence. [Figure 19] FIG. 19 is an explanatory diagram showing an example of storing the connection state of the lineage 1800. [Figure 20] FIG. 20 is an explanatory diagram showing an example of forming a lineage representing a confluence. [Figure 21] FIG. 21 is an explanatory diagram showing an example of the JSON format 2100 for registering replicated data. [Figure 22]FIG. 22 is a flowchart showing an example of the duplicate registration processing procedure in the first specific example. [Figure 23] FIG. 23 is an explanatory diagram showing an example of invalidation. [Figure 24] FIG. 24 is an explanatory diagram showing an example of the lineage 2400 representing invalidation. [Figure 25] FIG. 25 is an explanatory diagram showing an example of storing the connection state of the lineage 2400. [Figure 26] FIG. 26 is an explanatory diagram showing a specific example of invalidating registration data. [Figure 27] FIG. 27 is an explanatory diagram showing an example of the JSON format 2700 for registering invalidation data. [Figure 28] FIG. 28 is a flowchart showing an example of the branch registration processing procedure. [Figure 29] FIG. 29 is a flowchart showing an example of the first invalidation processing procedure. [Figure 30] FIG. 30 is a flowchart showing an example of the second invalidation processing procedure. [Figure 31] FIG. 31 is an explanatory diagram (part 1) showing another example of invalidation. [Figure 32] FIG. 32 is an explanatory diagram (part 2) showing another example of invalidation. [Figure 33] FIG. 33 is an explanatory diagram showing another specific example of invalidating registration data. <000011​​​​​​​​​​​​​​​​Figure 39 is a flowchart showing an example of the visualization process. [Figure 40] Figure 40 is an explanatory diagram showing an example of a horizontal chain 4000. [Figure 41] Figure 41 is an explanatory diagram showing an example of a vertical chain 4100. [Figure 42] Figure 42 is an explanatory diagram showing a specific example of a block 4200 of a horizontal chain 4000. [Figure 43] Figure 43 is an explanatory diagram showing a specific example of a block 4300 of a vertical chain 4100. [Figure 44] Figure 44 is an explanatory diagram showing an example of registering new data in the second specific example. [Figure 45] Figure 45 is a flowchart showing an example of the in-house registration process in the second specific example. [Figure 46] Figure 46 is a flowchart showing an example of the new registration process in the second specific example. [Figure 47] Figure 47 is a flowchart showing an example of the modification registration process in the second specific example. [Figure 48] Figure 48 is an explanatory diagram showing an example of the data structure of various notifications. [Figure 49] Figure 49 is an explanatory diagram showing an example of the data structure of the unregistered list 4900. [Figure 50] Figure 50 is an explanatory diagram showing an example of the data structure of the registered list 5000. [Figure 51] Figure 51 is an explanatory diagram showing an example of a lineage formation representing a merger. [Figure 52] Figure 52 is a flowchart showing an example of the replication registration process procedure in the first specific example. [Modes for carrying out the invention]

[0011] Embodiments of the information processing program, information processing method, and information processing apparatus according to the present invention will be described in detail below with reference to the drawings.

[0012] (An embodiment of the information processing method according to the embodiment) Figure 1 is an explanatory diagram showing one embodiment of the information processing method according to the embodiment. The information processing device 100 is a computer that enables flexible updating of target data. The information processing device 100 is, for example, a server or a PC (Personal Computer).

[0013] The target data includes, for example, multiple blocks. Specifically, the target data includes a series of blocks formed by concatenating two or more different blocks. The multiple blocks form, for example, one or more hash chains. Specifically, the multiple blocks form one or more CDLs. The actual target data may be stored in, for example, one or more computers other than the information processing device 100. The information processing device 100 manages, for example, at least one of the multiple blocks included in the target data.

[0014] For example, if it is requested to add a new block after an existing block in a hash chain, the ID of the existing block is obtained, and a new block containing the ID of the existing block is created and added after it. The ID is an identification. In addition, the ID of the newly added block is stored in the existing block as a result of adding a new block. In this way, the hash chain is formed and updated by adding new blocks.

[0015] However, conventional methods sometimes fail to flexibly update the hash chain. For example, due to the specifications of the hash chain, the IDs of existing blocks preceding the new block can only be stored in the new block when the new block is created. Therefore, even if one attempts to retroactively concatenate another block before an existing block, it is not possible to store the IDs of those other blocks in the existing block. Consequently, it is not possible to retroactively concatenate another block before an existing block.

[0016] For example, due to the specifications of the hash chain, it is not possible to delete existing blocks, and deleting an existing block does not invalidate it. Therefore, when a new block is retrospectively concatenated after the first existing block in a sequence of two existing blocks, replacing the second existing block, it is not possible to represent the invalidation of the second existing block on the hash chain.

[0017] Therefore, this embodiment describes an information processing method that enables flexible updating of target data.

[0018] In Figure 1, there is target data that includes multiple blocks. A block is a collection of one or more data points. A block includes, for example, identifiers of other blocks that are linked before and after it. Multiple blocks are formed such that, for example, each block includes identifiers of other blocks that are linked before and after it.

[0019] Multiple blocks form, for example, a hash chain. Specifically, multiple blocks form a CDL. The information processing device 100 manages at least one of the multiple blocks. For example, the information processing device 100 manages the first block among the multiple blocks.

[0020] In the example in Figure 1, the target data includes Block A, Block B, Block C, and Block D. For example, Block B is concatenated after Block A. Block C is concatenated after Block B. For example, Block D exists independently of the other blocks. The actual target data may be stored in a distributed manner by one or more computers other than the information processing device 100.

[0021] (1-1) The information processing device 100 receives a first request to newly add a second block before the first block. The information processing device 100 receives the first request, for example, by receiving the first request from another computer. The other computer is, for example, a computer that has generated a second block and added the second block to multiple blocks. In the example in Figure 1, the information processing device 100 receives a first request to newly add a block D before block B, as shown by reference numeral 101.

[0022] (1-2) When the information processing device 100 receives the first request, it controls multiple blocks to add a copy of the first block to the multiple blocks and link it after the second block. In the example in Figure 1, as shown by reference numeral 102, the information processing device 100 decides to link a copy of block B after block D, thereby effectively linking block D before block B, and controls multiple blocks.

[0023] Specifically, the information processing device 100 controls one of the computers that stores the actual data of the target in a distributed manner, such that, instead of block B, a copy of block B is concatenated after block D. Specifically, one of the computers, in accordance with the control of the information processing device 100, generates a copy of block B in place of block B, adds it to multiple blocks, and concatenates the copy of block B after block D, as shown in reference numeral 103.

[0024] As a result, if it is difficult to link the second block before the first block due to the specifications of the multiple blocks, the information processing device 100 can use a copy of the first block to represent the hierarchical relationship between the first block and the second block. Therefore, the information processing device 100 can use a copy of the first block to refer to the hierarchical relationship between the first block and the second block and flexibly update the target data. For example, the information processing device 100 can make it possible to retrospectively link the second block before an existing first block.

[0025] Here, we have described a case in which the information processing device 100 receives a first request to newly link a second block before the first block, but it is not limited to this. For example, the information processing device 100 may also receive a second request to invalidate a third block, which is managed by the device itself, among the multiple blocks.

[0026] In this case, the information processing device 100 can control multiple blocks so that a fourth block indicating the invalidation of the third block is added to the multiple blocks and linked after the third block. This allows the information processing device 100 to express the invalidation of the third block by using the fourth block indicating the invalidation of the third block when it is difficult to delete the third block due to the specifications of the multiple blocks. Therefore, the information processing device 100 can flexibly update the target data.

[0027] Here, we have described the case where the information processing device 100 operates independently, but it is not limited to this. For example, the information processing device 100 may collaborate with other computers to realize the functions of the information processing device 100 described above. For example, multiple computers may realize the functions of the information processing device 100 described above. Specifically, the functions of the information processing device 100 described above may be realized on the cloud.

[0028] (An example of information processing system 200) Next, using Figure 2, we will describe an example of an information processing system 200 to which the information processing device 100 shown in Figure 1 is applied.

[0029] Figure 2 is an explanatory diagram showing an example of an information processing system 200. In Figure 2, the information processing system 200 includes one or more information processing devices 100, one or more lineage management devices 201, and one or more client devices 202.

[0030] In the information processing system 200, the information processing device 100 and the lineage management device 201 are connected via a wired or wireless network 210. The network 210 is, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet. In the information processing system 200, the information processing device 100 and the client device 202 are connected via a wired or wireless network 210.

[0031] The information processing device 100 is a computer that allows for flexible updating of target data. The target data includes multiple blocks. The multiple blocks form, for example, one or more hash chains. Specifically, the multiple blocks include a series of blocks that form a hash chain. Specifically, the multiple blocks form one or more CDLs. More specifically, the multiple blocks include a series of blocks that form a CDL. In the following description, the target data specifically includes multiple blocks that form one CDL. An example of a CDL will be described later using Figures 3 to 6.

[0032] The information processing device 100 is capable of controlling the CDL. For example, the information processing device 100 is capable of controlling at least one of the multiple blocks that make up the CDL. Specifically, the information processing device 100 is capable of controlling the CDL by controlling one of the lineage management devices 201 that manages at least one of the multiple blocks that make up the CDL. More specifically, the information processing device 100 is capable of controlling the CDL to add a new block to the CDL by controlling the lineage management device 201.

[0033] The information processing device 100 receives an update request from the client device 202 to update the CDL. The update request is, for example, a linking request to newly link one block to one of the existing blocks in a group of blocks. The update request is, for example, a deactivation request to deactivate one of the existing blocks in a group of blocks. The information processing device 100 receives, for example, a linking request or a deactivation request from the client device 202.

[0034] The information processing device 100 controls the CDL in response to an update request. For example, the information processing device 100 controls one of the lineage management devices 201 that manages at least one of the blocks of the plurality of blocks that make up the CDL in response to an update request. The information processing device 100 controls the CDL and adds a new block to the CDL by controlling the lineage management device 201 in response to an update request.

[0035] The information processing device 100 may receive a display request from the client device 202 to display the CDL. In response to the received display request, the information processing device 100 generates display content representing the CDL. For example, the information processing device 100 generates display content that clearly indicates the sequential relationships of multiple blocks forming the CDL. The information processing device 100 transmits the generated display content representing the CDL to the client device 202. The information processing device 100 is used by the system operator. The information processing device 100 is, for example, a server or a PC.

[0036] The Lineage Management Device 201 is a computer for storing at least one of the blocks that make up the CDL. For example, the Lineage Management Device 201 stores and manages one of the blocks that it is responsible for among multiple blocks that make up the CDL. The Lineage Management Device 201 updates the CDL according to the control of the Information Processing Device 100. For example, the Lineage Management Device 201 adds a new block to the CDL according to the control of the Information Processing Device 100. The Lineage Management Device 201 is used by the system operator. The Lineage Management Device 201 is, for example, a server or a PC.

[0037] The client device 202 is a computer used by a system user. Based on the system user's input, the client device 202 generates an update request to update the CDL and sends it to the information processing device 100. Based on the system user's input, the client device 202 generates a display request to display the CDL and sends it to the information processing device 100. The client device 202 receives the display content representing the CDL from the information processing device 100 and outputs it so that the system user can refer to it. The client device 202 is, for example, a PC, a tablet terminal, or a smartphone.

[0038] Here, we have described a case where the information processing device 100 is a different device from the Lineage Management Device 201, but this is not limited to that case. For example, the information processing device 100 may have the functionality of a Lineage Management Device 201 and may also operate as a Lineage Management Device 201.

[0039] Here, we have described a case where the information processing device 100 is a different device from the client device 202, but this is not limited to that case. For example, the information processing device 100 may have the functionality of a client device 202 and may operate as a client device 202.

[0040] (Examples of using Information Processing System 200) Next, we will describe an example of the use of the information processing system 200. The information processing system 200 may be used, for example, to manage a supply chain. In this case, the lineage management device 201 is used by each participant in the supply chain. The participants correspond to the system operators mentioned above. Participants may be individuals or organizations. In this case, the CDL is formed by multiple blocks, such as a block corresponding to the final product, a block corresponding to the parts of the final product, and a block corresponding to the materials of the parts. The CDL then manages, for example, the manufacturing process of the product.

[0041] (An example of CDL300) Next, an example of the CDL300 will be explained using Figures 3 to 6.

[0042] Figures 3 to 6 are explanatory diagrams showing an example of CDL300. As shown in Figure 3, CDL300 includes one or more blocks 301 connected to each other in a first direction, and one or more blocks 302 connected to block 301 in a second direction. Block 301 is stored by the lineage management device 201. Block 302 is stored by the lineage management device 201.

[0043] Block 301 contains data ID 303, the previous ID 304, the next ID 305, hash value 306, and hash value 307. Data ID 303 is the identification information that identifies block 301. The previous ID 304 is the data ID 303 of another block 301 that is concatenated immediately before block 301. The next ID 305 is the data ID 303 of another block 301 that is concatenated after block 301.

[0044] One hash value 306 is the hash value of another block 301 that is linked directly to the current block 301, and is an element that enables the formation of a hash chain in the first direction. The other hash value 307 is the hash value of another block 302 that is linked to the current block 301, and is an element that enables the formation of a hash chain in the second direction.

[0045] One or more blocks 301 each form a hash chain in the first direction using the hash value 306 of each block 301. Each block 301 and the block 302 linked to it form a hash chain in the second direction using the hash value 307 of each block 301.

[0046] Block 301 corresponds, for example, to a participant in the supply chain. Block 301 is a global block containing data to be made public to all participants. This data may, for example, be data relating to the final product, parts, or materials. Block 302 is concatenated after Block 301. Block 302 is a local block containing data to be made public to a specified participant. This data may, for example, be data relating to the final product, parts, or materials.

[0047] When Lineage Management Device 201 adds a new block 301 to CDL300, it sets the data ID 303 of the other block 301 linked immediately before the new block 301 as the previous ID 304. When Lineage Management Device 201 adds a new block 301 to CDL300, it sets the ID of the new block 301 as the next ID 305 of the other block 301 linked immediately before the new block 301.

[0048] CDL300 may include, for example, branching or merging of block 301. The information processing system 200 can improve tamper resistance by forming a hash chain with one or more blocks 301 in the first direction and a hash chain with block 301 and block 302 in the second direction. Next, we will move on to the explanation of Figure 4.

[0049] As shown in Figure 4, CDL300 concatenates block 301 for data ID 303 "#02" and block 301 for data ID 303 "#03" after block 301 for data ID 303 "#01". In the example in Figure 4, CDL300 branches from block 301 for data ID 303 "#01" to block 301 for data ID 303 "#02" and block 301 for data ID 303 "#03". CDL300 may also include merging of blocks 301, etc.

[0050] By following the ID 304 preceding each block 301, it is possible to traverse two or more linked blocks 301 in the forward direction. By following the ID 305 following each block 301, it is possible to traverse each block 301 in the backward direction. In this way, the CDL 300 represents the sequential relationship between blocks 301 and stores the sequential correspondence between the data in blocks 301 in a tamper-proof manner. Next, we will move on to explaining Figures 5 and 6 and describe the specific contents of block 301.

[0051] As shown in Figure 5, each block 301 that makes up the CDL 300 includes a header 501, an event 502, a tag 503, a tamper-evident 504, and a digital signature 505. Here, we assume that the CDL is made up of three blocks 301.

[0052] In the following explanation, the first block 301 of CDL300 may be referred to as "block 301-1". Similarly, the second block 301 of CDL300 may be referred to as "block 301-2". Furthermore, the last block 301 of CDL300 may be referred to as "block 301-3".

[0053] The header 501 of block 301-1 includes, for example, an event ID, a lineage ID, a group of previous event IDs, a group of next event IDs, history registrant information, and history registration time. The event ID is the ID of the current block 301. The event ID corresponds to, for example, a data ID. The lineage ID is the ID of CDL300.

[0054] The previous event ID group includes the ID of another block 301 that is linked immediately before the current block 301, corresponding to the "previous ID 304" mentioned above. The previous event ID group is determined when the current block 301 is created. Since block 301-1 is the first block 301, the previous event ID group is empty in block 301-1. The next event ID group includes the ID of another block 301 that is linked immediately after the current block 301, corresponding to the "next ID 305" mentioned above. The next event ID group is empty when the current block 301 is created, and the ID of block 301-2 is set when block 301-2 is created.

[0055] The history registrant information is information indicating the supply chain participant who requested the creation and addition of block 301. The history registration time is the time when block 301 was added to CDL300. The event 502 of block 301-1 includes, for example, user-defined data indicating the event, specified by the participant. This user-defined data may be, for example, information about the final product, part, or material. The event 502 of block 301-1 corresponds to, for example, a global block. The tag 503 of block 301-1 includes, for example, user-defined data that will serve as a tag, specified by the participant. The tag 503 of block 301-1 corresponds to, for example, a local block.

[0056] The tamper-proofing 504 of block 301-1 includes a SHA (Secure Hash Algorithm) 256 hash value for tamper-proofing. The tamper-proofing 504 includes, for example, the hash value of the event ID in header 501, the hash value of the lineage ID in header 501, and the hash values ​​of the previous event IDs in header 501.

[0057] Tamper verification 504 includes, for example, the hash value of the history registrant information in header 501 and the hash value of the history registration time in header 501. Tamper verification 504 also includes, for example, the hash value of event 502 and the hash value of tag 503. Tamper verification 504 may also include, for example, the tamper verification 504 of other block 301 groups that are linked immediately before the current block 301. Since block 301-1 is the first block 301, tamper verification 504 in block 301-1 does not need to include the tamper verification 504 of other block 301 groups.

[0058] The digital signature 505 of block 301-1 is a digital signature to the tamper-proof 504. The authenticity of the tamper-proof 504 can be verified by verifying the digital signature 505. The authenticity of the header 501, event 502, and tag 503 can be verified by verifying the tamper-proof 504. If there is another group of blocks 301 concatenated immediately before the current block 301, the authenticity of that other group of blocks 301 can be verified by verifying the tamper-proof 504.

[0059] The header 501 of block 301-2 includes, for example, an event ID, a lineage ID, a group of previous event IDs, a group of next event IDs, history registrant information, and the history registration time. The event ID is the ID of the current block 301. The lineage ID is the ID of CDL300.

[0060] The previous event ID group includes the ID of the other block 301 that is linked immediately before the current block 301, corresponding to the "previous ID 304" mentioned above. The previous event ID group is determined when the current block 301 is created. Since block 301-2 is the second block 301, in block 301-2, the previous event ID group is set to the ID of block 301-1. The next event ID group includes the ID of the other block 301 that is linked immediately after the current block 301, corresponding to the "next ID 305" mentioned above. The next event ID group is empty when the current block 301 is created, and when block 301-3 is created, the ID of block 301-3 is set.

[0061] The history registrant information is information indicating the supply chain participant who requested the creation and addition of block 301. The history registration time is the time when block 301 was added to CDL300. The event 502 of block 301-2 includes, for example, user-defined data indicating an event, specified by the participant. This user-defined data may be, for example, information about a final product, part, or material. The tag 503 of block 301-2 includes user-defined data that will serve as a tag, specified by the participant.

[0062] The tamper verification 504 of block 301-2 includes a SHA256 hash value for tamper verification. The tamper verification 504 includes, for example, the hash value of the event ID in header 501, the hash value of the lineage ID in header 501, and the hash values ​​of the previous event IDs in header 501.

[0063] Tamper verification 504 includes, for example, the hash value of the history registrant information in header 501 and the hash value of the history registration time in header 501. Tamper verification 504 also includes, for example, the hash value of event 502 and the hash value of tag 503. Tamper verification 504 may also include, for example, the tamper verification 504 of other block 301 groups that are concatenated one block prior to its own block 301. Since block 301-2 is the second block 301, in block 301-2, tamper verification 504 includes the tamper verification 504 of the first block 301-1.

[0064] The digital signature 505 of block 301-2 is a digital signature to the tamper-proof 504. The authenticity of the tamper-proof 504 can be verified by verifying the digital signature 505. The authenticity of the header 501, event 502, and tag 503 can be verified by verifying the tamper-proof 504. If there is another group of blocks 301 concatenated immediately before the current block 301, the authenticity of that other group of blocks 301 can be verified by verifying the tamper-proof 504. Next, we will move on to the explanation of Figure 6.

[0065] As shown in Figure 6, the header 501 of block 301-3 includes, for example, an event ID, a lineage ID, a group of previous event IDs, a group of next event IDs, history registrant information, and history registration time. The event ID is the ID of the current block 301. The lineage ID is the ID of CDL300.

[0066] The previous event ID group includes the ID of the other block 301 that is linked immediately before the current block 301, corresponding to the "previous ID 304" mentioned above. The previous event ID group is determined when the current block 301 is created. Since block 301-3 is the third block 301, in block 301-3, the previous event ID group is set to the ID of block 301-2. The next event ID group includes the ID of the other block 301 that is linked immediately after the current block 301, corresponding to the "next ID 305" mentioned above. The next event ID group is empty when the current block 301 is created. Since block 301-3 is the third block 301, in block 301-3, the next event ID group is empty.

[0067] The history registrant information is information indicating the supply chain participant who requested the creation and addition of block 301. The history registration time is the time when block 301 was added to CDL300. The event 502 of block 301-3 includes, for example, user-defined data indicating an event, specified by the participant. This user-defined data may be, for example, information about a final product, part, or material. The tag 503 of block 301-3 includes user-defined data that will serve as a tag, specified by the participant.

[0068] The tamper verification 504 in block 301-3 includes a SHA256 hash value for tamper verification. The tamper verification 504 includes, for example, the hash value of the event ID in header 501, the hash value of the lineage ID in header 501, and the hash values ​​of the previous event IDs in header 501.

[0069] Tamper verification 504 includes, for example, the hash value of the history registrant information in header 501 and the hash value of the history registration time in header 501. Tamper verification 504 also includes, for example, the hash value of event 502 and the hash value of tag 503. Tamper verification 504 may also include, for example, the tamper verification 504 of other block 301 groups that are concatenated immediately before the current block 301. Since block 301-3 is the third block 301, in block 301-3, tamper verification 504 includes the tamper verification 504 of the first block 301-1.

[0070] The digital signature 505 of block 301-3 includes a digital signature for tamper verification 504. When CDL300 is read, the digital signature 505 of block 301-3 has a SHA256 hash value added to it so that it includes the SHA256 hash value for tamper verification 504. The authenticity of tamper verification 504 can be verified by verifying the digital signature 505. The authenticity of header 501, event 502, and tag 503 can be verified by verifying the tamper verification 504, if there is another group of blocks 301 concatenated immediately before its own block 301.

[0071] Thus, because the tamper-proofing 504 of block 301 forming CDL300 includes the hash value of the previous event ID group when block 301 is generated, updating the previous event ID group retrospectively makes it difficult to guarantee the authenticity of block 301 itself. Therefore, it is difficult to retrospectively concatenate another block 301 immediately before block 301. On the other hand, it is possible to retrospectively concatenate another block 301 immediately after block 301.

[0072] (Example of hardware configuration of information processing device 100) Next, an example of the hardware configuration of the information processing device 100 will be described using Figure 7.

[0073] Figure 7 is a block diagram showing an example of the hardware configuration of the information processing device 100. In Figure 7, the information processing device 100 includes a CPU (Central Processing Unit) 701, memory 702, network interface 703, recording medium interface 704, and recording medium 705. Each component is connected by a bus 700.

[0074] Here, the CPU 701 is responsible for the overall control of the information processing device 100. The memory 702 includes, for example, ROM (Read Only Memory), RAM (Random Access Memory), and flash ROM. Specifically, for example, flash ROM and ROM store various programs, and RAM is used as the work area for the CPU 701. Programs stored in memory 702 are loaded into the CPU 701, causing the CPU 701 to execute the coded processes.

[0075] The network interface 703 is connected to network 210 via a communication line, and then connects to other computers via network 210. The network interface 703 manages the internal interface with network 210 and controls the input and output of data from other computers. The network interface 703 is, for example, a modem or a LAN adapter.

[0076] The recording medium interface (I / F) 704 controls the reading and writing of data to the recording medium 705 according to the control of the CPU 701. The recording medium interface (I / F) 704 is, for example, a disk drive, an SSD (Solid State Drive), or a USB (Universal Serial Bus) port. The recording medium 705 is a non-volatile memory that stores the data written under the control of the recording medium interface (I / F) 704. The recording medium 705 is, for example, a disk, semiconductor memory, or USB memory. The recording medium 705 may be detachable from the information processing device 100.

[0077] In addition to the components described above, the information processing device 100 may also have, for example, a keyboard, mouse, display, printer, scanner, microphone, speaker, etc. Furthermore, the information processing device 100 may have multiple recording medium interfaces 704 and recording mediums 705. Alternatively, the information processing device 100 may not have recording medium interfaces 704 and recording mediums 705.

[0078] (Example hardware configuration for Lineage Management Device 201) The hardware configuration example of the Lineage Management Device 201 is specifically the same as the hardware configuration example of the Information Processing Device 100 shown in Figure 7, so a detailed explanation will be omitted.

[0079] (Example hardware configuration for client device 202) The hardware configuration example for client device 202 is specifically the same as the hardware configuration example for information processing device 100 shown in Figure 7, so a detailed explanation is omitted.

[0080] (An example of the functional configuration of the information processing device 100) Next, an example of the functional configuration of the information processing device 100 will be described using Figure 8.

[0081] Figure 8 is a block diagram showing an example of the functional configuration of the information processing device 100. The information processing device 100 includes a storage unit 800, an acquisition unit 801, an update unit 802, and an output unit 803.

[0082] The storage unit 800 is implemented by a storage area such as the memory 702 or recording medium 705 shown in Figure 7. The following description will focus on the case where the storage unit 800 is included in the information processing device 100, but is not limited to this case. For example, the storage unit 800 may be included in a device different from the information processing device 100, and the contents of the storage unit 800 may be accessible from the information processing device 100.

[0083] The acquisition unit 801 to the output unit 803 function as an example of a control unit. Specifically, the acquisition unit 801 to the output unit 803 realize their functions, for example, by having the CPU 701 execute a program stored in a storage area such as the memory 702 or recording medium 705 shown in Figure 7, or by using the network interface 703. The processing results of each functional unit are stored in a storage area such as the memory 702 or recording medium 705 shown in Figure 7.

[0084] The storage unit 800 stores various types of information that are referenced or updated during processing in each functional unit. The storage unit 800 may store at least one of the blocks included in a plurality of blocks. The plurality of blocks are formed such that each block includes identifiers of other blocks that are linked before and after it.

[0085] Multiple blocks are, for example, one or more hash chains. Multiple blocks are, for example, one or more CDLs. The storage unit 800 stores, for example, the blocks that it is responsible for among the multiple blocks. Multiple blocks may be stored by other computers other than the information processing device 100. Multiple blocks may be stored in a distributed manner by, for example, one or more lineage management devices 201.

[0086] The storage unit 800 may store the sequential relationships between blocks. For example, the storage unit 800 may store the sequential relationships between blocks for which it is responsible for multiple blocks. The storage unit 800 may also store the sequential relationships between blocks for all of the multiple blocks.

[0087] The acquisition unit 801 acquires various types of information used in the processing of each functional unit. The acquisition unit 801 stores the acquired information in the storage unit 800 or outputs it to each functional unit. The acquisition unit 801 may also output the information stored in the storage unit 800 to each functional unit. The acquisition unit 801 acquires various types of information, for example, based on the operation input of the user of the device. The acquisition unit 801 may also receive various types of information from a device other than the information processing device 100, for example.

[0088] The acquisition unit 801 receives, for example, a request to perform a specific process on multiple blocks. Specifically, the acquisition unit 801 receives a first request. The first request asks for a second block to be newly linked before the first block managed by the device, among the multiple blocks. The second block is a block already included in the multiple blocks. The second block may also be a block not yet included in the multiple blocks. More specifically, the acquisition unit 801 acquires the first request by receiving it from another computer. More specifically, the acquisition unit 801 acquires the first request by receiving input for the first request based on the operation input of the device user.

[0089] Specifically, the acquisition unit 801 receives the second request. The second request requests the invalidation of the third block, which is managed by the device, among multiple blocks. More specifically, the acquisition unit 801 acquires the second request by receiving it from another computer. More specifically, the acquisition unit 801 acquires the second request by receiving input for the second request based on the operation input of the device user.

[0090] Specifically, the acquisition unit 801 receives the third request. The third request requests the generation of a second block and the addition of the generated second block to multiple blocks. More specifically, the acquisition unit 801 acquires the third request by receiving it from another computer. More specifically, the acquisition unit 801 acquires the third request by receiving input for the third request based on the operation input of the user of its own device.

[0091] Specifically, the acquisition unit 801 receives display requests for all or part of multiple blocks. More specifically, the acquisition unit 801 acquires display requests by receiving them from other computers. More specifically, the acquisition unit 801 acquires display requests by receiving input of display requests based on operation input from the user of its own device.

[0092] The acquisition unit 801 may receive a start trigger to initiate processing in any of the functional units. A start trigger may be, for example, a predetermined operation input by a user of the device. A start trigger may also be, for example, the receipt of predetermined information from another computer. A start trigger may also be, for example, the output of predetermined information by any of the functional units.

[0093] Specifically, the acquisition unit 801 may receive the first request, the second request, or the third request as a start trigger to begin processing in the update unit 802. Specifically, the acquisition unit 801 may receive the display request as a start trigger to begin processing in the output unit 803.

[0094] When the update unit 802 receives the first request from the acquisition unit 801, it controls multiple blocks to add a copy of the first block to multiple blocks and link it after the second block. The update unit 802 also controls, for example, another computer that manages the first block, and controls multiple blocks to add a copy of the first block to multiple blocks and link it after the second block. The other computer is, for example, the lineage management device 201.

[0095] The update unit 802 may, for example, control multiple blocks to add a copy of the first block to multiple blocks stored in the storage unit 800 and link it after the second block. This allows the update unit 802 to effectively link the second block retrospectively before the first block. The update unit 802 can appropriately represent the sequential relationship between the first block and the second block in the multiple blocks.

[0096] In this case, the update unit 802 may add a copy of the first block to multiple blocks, including a copy flag indicating that it is a copy of the first block. The update unit 802 controls, for example, another computer that manages the first block, and controls multiple blocks to add a copy of the first block to multiple blocks, including a copy flag indicating that it is a copy of the first block. The other computer is, for example, the lineage management device 201.

[0097] The update unit 802 may control multiple blocks, for example, to add a copy of the first block to multiple blocks stored in the storage unit 800, including a copy flag indicating that it is a copy of the first block. This makes it possible for the update unit 802 to identify that a copy of the first block is a copy of the first block. The update unit 802 can also easily identify the sequential relationship between the first block and the second block in the multiple blocks.

[0098] When the update unit 802 receives the second request from the acquisition unit 801, it controls multiple blocks to add a fourth block indicating that the third block should be invalidated, and to link it after the third block. The update unit 802 also controls, for example, another computer that manages the third block, and controls multiple blocks to add a fourth block indicating that the third block should be invalidated, and to link it after the third block. The other computer is, for example, the Lineage Management Device 201.

[0099] The update unit 802 may control multiple blocks, for example, to add a fourth block indicating the invalidation of the third block to multiple blocks stored in the storage unit 800 and link it after the third block. In this way, the update unit 802 can effectively invalidate the third block. The update unit 802 can appropriately represent the invalidation of the third block even when it is difficult to delete the third block.

[0100] When the update unit 802 receives a third request from the acquisition unit 801, it generates a second block and controls multiple blocks to add the generated second block to multiple other blocks. The update unit 802 controls, for example, another computer to control multiple blocks to add the second block to multiple other blocks. The other computer is, for example, the lineage management device 201.

[0101] The update unit 802 may, for example, control multiple blocks to add a second block to multiple blocks stored in the storage unit 800. This allows the update unit 802 to appropriately update multiple blocks. The update unit 802 can enable the addition of new blocks to multiple blocks.

[0102] The output unit 803 outputs the processing result of at least one of the functional units. The output format can be, for example, display on a screen, print to a printer, transmit to an external device via the network interface 703, or store in a storage area such as the memory 702 or recording medium 705. This allows the output unit 803 to notify the user of the device of the processing result of at least one of the functional units, thereby improving the usability of the information processing device 100.

[0103] The output unit 803 outputs all or part of the multiple blocks. For example, when the output unit 803 receives a display request, it displays all or part of the multiple blocks. Specifically, the output unit 803 displays all or part of the multiple blocks in a manner that allows the sequential relationships between the blocks to be identified. This allows the output unit 803 to enable system users to understand the sequential relationships between the blocks.

[0104] The output unit 803, for example, when displaying all or part of multiple blocks, identifies a copy of the first block based on a copy flag. The output unit 803 then displays the identified copy of the first block as the original first block from which the copy was made, or displays it in a way that allows for the identification of its correspondence with the original first block from which the copy was made. This makes it easier for system users to intuitively understand that the second block has been concatenated before the first block.

[0105] The output unit 803, for example, identifies the third block based on the fourth block when displaying all or part of multiple blocks. The output unit 803 then, for example, excludes the identified third block from the display target or displays it in a display mode corresponding to its invalidation. This makes it easier for system users to intuitively understand that the third block has been invalidated.

[0106] (Specific example of the functional configuration of information processing system 200) Next, using Figure 9, we will explain a specific example of the functional configuration of the information processing system 200.

[0107] Figure 9 is a block diagram showing a specific example of the functional configuration of the information processing system 200. In Figure 9, the information processing system 200 is used by multiple organizations, each participating in the supply chain. These multiple organizations have a contextual relationship.

[0108] Multiple organizations may, for example, receive products from other organizations, use products from other organizations to manufacture their own products, or provide their own products to other organizations. These multiple organizations have a chain of relationships through the provision or use of products. In the following explanation, the organization that manufactures its own products using products from other organizations may be treated as "downstream" compared to the other organization.

[0109] The information processing system 200 manages a series of interconnected blocks that represent a supply chain. In the following description, this series of interconnected blocks may be referred to as a "lineage." For example, the information processing system 200 manages a series of interconnected blocks that represent the relationships between the products of each participant in the supply chain. These blocks are, for example, product data.

[0110] The information processing system 200 includes a higher-level application 900 for each organization, a CDL infrastructure control unit 910 corresponding to the organization, and a CDL infrastructure 920 corresponding to the organization. The higher-level application 900 is implemented, for example, by a client device 202. The CDL infrastructure control unit 910 is implemented, for example, by an information processing device 100. The CDL infrastructure 920 is implemented, for example, by a lineage management device 201. Specifically, the CDL infrastructure 920 is implemented by an agent of the lineage management device 201.

[0111] The higher-level application 900 includes a GUI (Graphical User Interface) 901. The GUI 901 accepts, for example, operation inputs requesting data registration. The GUI 901 accepts, for example, operation inputs requesting data modification. The GUI 901 accepts, for example, operation inputs requesting data invalidation due to design changes, etc. The GUI 901 accepts, for example, operation inputs requesting the display of lineage representing the supply chain. The GUI 901 sends, for example, processing requests corresponding to the received operation inputs to the CDL base control unit 910.

[0112] The CDL infrastructure control unit 910 includes a notification detection unit 911, a lineage control unit 912, a lineage visualization unit 913, and a registration notification generation unit 914. The notification detection unit 911 detects data registration notifications addressed to the local organization. The notification detection unit 911 transmits the detected data registration notifications addressed to the local organization to the lineage control unit 912. The notification detection unit 911 detects visualization requests addressed to the local organization. The notification detection unit 911 transmits the detected visualization requests addressed to the local organization to the lineage visualization unit 913.

[0113] The Lineage Control Unit 912 notifies the higher-level application 900 of the data registration notification from the preceding organization. The Lineage Control Unit 912 registers data in the CDL infrastructure 920 triggered by input from the higher-level application 900 or the data registration notification from the preceding organization. When registering data for the second time or later due to a data registration notification from the preceding organization, the Lineage Control Unit 912 generates a copy of the already registered data. In response to receiving an invalidation notification, the Lineage Control Unit 912 adds an invalidation history to the already registered data. After registering the data, the Lineage Control Unit 912 notifies the registration notification generation unit of the information necessary for the next organization to register the data.

[0114] The Lineage Visualization Unit 913 receives a visualization request from the higher-level application 900. The Lineage Visualization Unit 913 retrieves the Lineage data in response to the visualization request. The Lineage Visualization Unit 913 removes invalidated data and duplicate data from the Lineage data. The Lineage Visualization Unit 913 returns the Lineage data. The Registration Notification Generation Unit 914 generates a registration notification based on the information obtained from the Lineage Control Unit 912. The Registration Notification Generation Unit 914 sends the generated registration notification to the subsequent organization.

[0115] The CDL infrastructure 920 includes a history registration unit 921, a history search unit 922, a lineage acquisition unit 923, and a policy setting unit 924. The history registration unit 921 registers history data in the lineage system under the control of the lineage control unit 912. The history search unit 922 searches for history data contained in the lineage system under the control of the lineage control unit 912 and returns it to the lineage control unit 912. The lineage acquisition unit 923 returns the lineage system to the lineage visualization unit 913 under the control of the lineage visualization unit 913. The policy setting unit 924 sets policies.

[0116] (First example of the operation of the information processing device 100) Next, using Figure 10, we will explain a first example of the operation of the information processing device 100. The first example shows how the information processing device 100 operates when merging branches in Lineage. A branch is a flow that connects blocks.

[0117] Figure 10 is an explanatory diagram showing a first example of the operation of the information processing device 100. In Figure 10, initially, the lineage is assumed to include block A1, block B1, block C1, block D1, and block E1. Blocks A1, B1, C1, and D1 are assumed to be connected in order. Blocks A1 and E1 are assumed to be connected in order.

[0118] In contrast, it is sometimes desirable to control the lineage so that the first branch from block B1 to block C1 and the second branch from block E1 to block C1 merge. In this case, as shown by reference numeral 1000, it is difficult to retrospectively link block E1 one block before block C1, and therefore it is difficult to merge the first and second branches. Accordingly, as shown by reference numeral 1010, we will artificially link block E1 one block before the copy of block C1.

[0119] For example, the information processing device 100 that manages block C1 generates a copy of block C1 and adds it to the lineage, and controls the lineage to link the copy of block C1 one position after block E1. For example, the information processing device 100 that manages block D1 generates a copy of block D1 and adds it to the lineage, and controls the lineage to link the copy of block D1 one position after the copy of block C1.

[0120] As a result, the information processing device 100 can simulate the merging of the first and second branches, even in situations where it is difficult to retrospectively link another block one block prior to the current block due to the specifications of the CDL. The information processing device 100 can represent the merging of the first and second branches in Lineage.

[0121] (Second example of the operation of the information processing device 100) Next, Figure 11 will be used to describe a second example of the operation of the information processing device 100. The second example shows how the information processing device 100 operates when disabling a Lineage block.

[0122] Figure 11 is an explanatory diagram showing a second example of the operation of the information processing device 100. In Figure 11, initially, the lineage is assumed to include block A1, block B1, block C1, and block D1. Blocks A1, B1, C1, and D1 are assumed to be connected in order.

[0123] In contrast, there are cases where it is desirable to add blocks E1, F1, and G1 after block A1 instead of blocks B1, C1, and D1. In this case, blocks B1, C1, and D1 will be invalidated. For example, blocks B1, C1, and D1 can be invalidated by adding a block indicating invalidation one block after each of them.

[0124] For example, the information processing device 100 that manages block B1 controls the lineage to generate block E1 and add it to the lineage, as shown by reference numeral 1100, and to link it one block after block A1. Also, the information processing device 100 that manages block B1 controls the lineage to generate a block representing invalidation and add it to the lineage, as shown by reference numeral 1111, and to link the block representing invalidation one block after block B1.

[0125] For example, the information processing device 100 that manages block C1 controls the lineage to generate block F1 and add it to the lineage, as shown by reference numeral 1100, and to link it one block after block E1. Also, the information processing device 100 that manages block C1 controls the lineage to generate a block representing invalidation and add it to the lineage, as shown by reference numeral 1111, and to link the block representing invalidation one block after block C1.

[0126] For example, the information processing device 100 that manages block D1 controls the lineage to generate block G1 and add it to the lineage, as shown by reference numeral 1100, and to link it one block after block F1. Also, the information processing device 100 that manages block D1 controls the lineage to generate a block representing invalidation and add it to the lineage, as shown by reference numeral 1111, and to link the block representing invalidation one block after block D1.

[0127] As a result, the information processing device 100 can disable blocks even in situations where it is difficult to delete blocks due to the specifications of the CDL. The information processing device 100 can represent the disabling of blocks in Lineage.

[0128] The information processing device 100 may have both the function to implement the first example described above and the function to implement the second example described above. The information processing device 100 may have only one of the functions to implement the first example described above or the function to implement the second example described above.

[0129] (First specific example of the operation of the information processing device 100) Next, we will explain a first specific example of the operation of the information processing device 100 using Figures 12 to 39. In this first example, we assume that there are companies A, B, and C, which are participants in the supply chain. In the following explanation, the information processing device 100 corresponding to company X may be referred to as "information processing device 100X". X = A, B, C, ...

[0130] In the following explanation, the higher-level application 900 corresponding to Company X may be referred to as "higher-level application 900X". In the following explanation, the CDL base control unit 910 corresponding to Company X may be referred to as "CDL base control unit 910X". In the following explanation, the CDL base 920 corresponding to Company X may be referred to as "CDL base 920X". First, using Figure 12, we will explain an example in which the CDL base control unit 910 of the information processing device 100 registers new data in Lineage in the first specific example.

[0131] Figure 12 is an explanatory diagram showing an example of registering new data in the first specific example. In Figure 12, (12-1) suppose a user of Company A wants to register data for Company A's product using Company B's product in Lineage. Based on the user's input from Company A, the higher-level application 900A sends a data registration request to the CDL infrastructure control unit 910A, which includes Company ID, Company Product ID, Supplier ID, Supplier Product ID, and product information.

[0132] Here, the Company ID is identification information that identifies Company A. The Company Product ID is identification information that identifies Company A's product for which data is registered. The Supplier ID is identification information that identifies Company B, which orders third-party products used in Company A's products. The Supplier Product ID is identification information that identifies Company B's product. The Product Information is data for Company A's product. The Product Information includes, for example, the attributes of Company B's product used in Company A's product. Attributes include, for example, quantity or price.

[0133] (12-2) The CDL infrastructure control unit 910A receives a data registration request. The CDL infrastructure control unit 910A obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910A refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 38.

[0134] Here, the CDL infrastructure control unit 910A determines that the data is new. Since the CDL infrastructure control unit 910A is at the very bottom of the chain, it sets the previous data ID to empty. Because the CDL infrastructure control unit 910A has determined that the data is new, it generates a registration JSON (Java® Script Object Notation) format that includes the registration data (product information) that is the target of the data registration request, and the set previous data ID (empty).

[0135] The registration JSON format is a combination of a global block containing, for example, a previous data ID=empty, and a local block containing registration data=product information. The CDL infrastructure control unit 910A uses the generated registration JSON format to execute a registration API on the CDL infrastructure 920A.

[0136] (12-3) The CDL infrastructure 920A accepts the registration JSON format via the registration API. The CDL infrastructure 920A generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920A calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920A adds the registration JSON format to the lineage. The CDL infrastructure 920A sends a response containing the generated data ID to the CDL infrastructure control unit 910A.

[0137] (12-4) When the CDL infrastructure control unit 910A receives a response containing the data ID, it determines that the registration data has been registered in the lineage because a local block containing the registration data, which is associated with the global block, is added to the lineage. Since the registration data has been registered in the lineage, the CDL infrastructure control unit 910A retrieves the data ID included in the response. The CDL infrastructure control unit 910A sends a registration notification containing the retrieved company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910B.

[0138] (12-5) When the CDL base control unit 910B receives a registration notification from the preceding CDL base control unit 910A, it outputs an alarm to the user of Company B. The user of Company B refers to the alarm and understands that they are using Company B's product with Company A's product.

[0139] (12-6) A user of Company B wishes to register data of Company B's product using Company C's product in Lineage. Based on the user's input, the higher-level application 900B sends a data registration request to the CDL infrastructure control unit 910B, which includes Company ID, Company Product ID, Supplier ID, Supplier Product ID, and product information.

[0140] Here, the Company ID is the identification information that identifies Company B. The Company Product ID is the identification information that identifies Company B's product for which data is registered. The Supplier ID is the identification information that identifies Company C, which orders third-party products used in Company B's products. The Supplier Product ID is the identification information that identifies Company C's product. The Product Information is the data for Company B's product. The Product Information includes, for example, the attributes of Company C's product used in Company B's product. Attributes include, for example, quantity or price.

[0141] (12-7) The CDL infrastructure control unit 910B receives a data registration request. The CDL infrastructure control unit 910B obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910B refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 38.

[0142] Here, the CDL infrastructure control unit 910B determines that the data is new. Since the CDL infrastructure control unit 910B is not at the very bottom of the supply chain, it extracts the data ID from the registration notification and obtains it as the previous data ID. Because the CDL infrastructure control unit 910B has determined that the data is new, it generates a registration JSON format that includes the registration data (product information) that is the target of the data registration request and the set previous data ID (data ID from the registration notification).

[0143] The registration JSON format is a combination of a global block containing, for example, the previous data ID = the data ID of the registration notification, and a local block containing the registration data = product information. The CDL infrastructure control unit 910B uses the generated registration JSON format to execute the registration API on the CDL infrastructure 920B.

[0144] (12-8) The CDL infrastructure 920B accepts the registration JSON format via the registration API. The CDL infrastructure 920B generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920B calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920B adds the registration JSON format to the lineage. The CDL infrastructure 920B sends a response containing the generated data ID to the CDL infrastructure control unit 910B.

[0145] (12-9) When the CDL infrastructure control unit 910B receives a response containing the data ID, it determines that the registration data has been registered in the lineage because a local block containing the registration data, which is associated with the global block, is added to the lineage. Since the registration data has been registered in the lineage, the CDL infrastructure control unit 910B retrieves the data ID included in the response. The CDL infrastructure control unit 910B sends a registration notification containing the retrieved company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910C.

[0146] (12-10) When the CDL base control unit 910C receives a registration notification from the preceding CDL base control unit 910B, it outputs an alarm to the user of Company C. The user of Company C refers to the alarm and understands that they are using Company C's product with Company B's product.

[0147] (12-11) A user of Company C wishes to register data of Company C's product using a product of Company D (not shown) in Lineage. Based on the user's input, the higher-level application 900C sends a data registration request to the CDL base control unit 910C, which includes Company ID, Company Product ID, Supplier ID, Supplier Product ID, and product information.

[0148] Here, the Company ID is identification information that identifies Company C. The Company Product ID is identification information that identifies Company C's product for which data is registered. The Supplier ID is identification information that identifies Company D, which orders third-party products used in Company C's products. The Supplier Product ID is identification information that identifies Company D's product. The Product Information is data for Company C's product. The Product Information includes, for example, the attributes of Company D's product used in Company C's product. Attributes include, for example, quantity or price.

[0149] (12-12) The CDL infrastructure control unit 910C receives a data registration request. The CDL infrastructure control unit 910C obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910C refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 38.

[0150] Here, the CDL infrastructure control unit 910C determines that the data is new. Since the CDL infrastructure control unit 910C is not at the very bottom of the chain, it extracts the data ID from the registration notification and obtains it as the previous data ID. Because the CDL infrastructure control unit 910C has determined that the data is new, it generates a registration JSON format that includes the registration data (product information) that is the target of the data registration request and the set previous data ID (data ID from the registration notification).

[0151] The registration JSON format is a combination of a global block containing, for example, the previous data ID = the data ID of the registration notification, and a local block containing the registration data = product information. The CDL infrastructure control unit 910C uses the generated registration JSON format to execute the registration API on the CDL infrastructure 920C.

[0152] (12-13) The CDL infrastructure 920C accepts the registration JSON format via the registration API. The CDL infrastructure 920C generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920C calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920C adds the registration JSON format to the lineage. The CDL infrastructure 920C sends a response containing the generated data ID to the CDL infrastructure control unit 910C.

[0153] (12-14) When the CDL infrastructure control unit 910C receives a response containing the data ID, it determines that the registration data has been registered in the lineage by adding a local block containing the registration data, which is associated with the global block, to the lineage. Since the registration data has been registered in the lineage, the CDL infrastructure control unit 910C obtains the data ID included in the response. The CDL infrastructure control unit 910C sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910D (not shown).

[0154] In this way, the information processing system 200 can register new data in Lineage. For example, the information processing system 200 can add local blocks containing new data, which are associated with global blocks, to Lineage. The process flow for the CDL infrastructure control unit 910 to register new data in Lineage will be described later using Figure 14.

[0155] This section describes the case where the CDL infrastructure control unit 910 registers new data in Lineage, but it is not limited to this case. For example, the CDL infrastructure control unit 910 may also update registered data in Lineage with modified data. The process flow for the CDL infrastructure control unit 910 updating registered data in Lineage with modified data will be described later using Figure 15.

[0156] (In-house registration processing procedure) Next, using Figure 13, an example of a self-registration processing procedure executed by the CDL base control unit 910 will be described. The self-registration processing is realized, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0157] Figure 13 is a flowchart illustrating an example of the in-house registration processing procedure in the first specific example. In Figure 13, the CDL base control unit 910 receives a data registration request from the in-house higher-level application 900 via an API (step S1301). The data registration request includes the in-house ID, in-house product ID, supplier ID, supplier product ID, and registration data. The registration data includes, for example, product information.

[0158] The CDL base control unit 910 determines whether the registration data specified by the data registration request is new data (step S1302). If it is new data (step S1302: Yes), the CDL base control unit 910 proceeds to the process in step S1303. On the other hand, if it is not new data but modified data (step S1302: No), the CDL base control unit 910 proceeds to the process in step S1304.

[0159] In step S1303, the CDL base control unit 910 executes the new registration process described later in Figure 14 (step S1303). Then, the CDL base control unit 910 terminates the in-house registration process.

[0160] In step S1304, the CDL base control unit 910 executes the modification registration process described later in Figure 15 (step S1304). Then, the CDL base control unit 910 terminates the in-house registration process.

[0161] (New registration process procedure) Next, using Figure 14, an example of a new registration process procedure executed by the CDL base control unit 910 will be described. The new registration process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0162] Figure 14 is a flowchart illustrating an example of the new registration processing procedure in the first specific example. In Figure 14, if the CDL infrastructure control unit 910 receives a registration notification from the preceding CDL infrastructure control unit 910 for the company's product ID in the data registration request, it obtains the data ID of the registration notification as the previous data ID (step S1401). The registration notification includes the company ID, company product ID, supplier ID, supplier product ID, and data ID.

[0163] Here, the CDL infrastructure control unit 910 records and manages the company ID of the registration notification as the notifying organization ID in the unregistered list. The CDL infrastructure control unit 910 also records and manages the company product ID of the registration notification as the notifying product ID in the unregistered list. The CDL infrastructure control unit 910 also records and manages the previous data ID in the unregistered list.

[0164] Next, the CDL infrastructure control unit 910 refers to the unregistered list and generates a registration JSON format using the registration data of the data registration request and the acquired previous data ID (step S1402). Then, the CDL infrastructure control unit 910 executes the registration API using the registration JSON format (step S1403).

[0165] Next, the CDL infrastructure control unit 910 obtains the response from the registration API, clears the unregistered list, and adds the response data ID to the registered list (step S1404). Then, the CDL infrastructure control unit 910 generates a registration notification including the company ID, company product ID, supplier ID, supplier product ID, and response data ID, and sends the registration notification to the subsequent CDL infrastructure control unit 910 (step S1405). After that, the CDL infrastructure control unit 910 terminates the new registration process.

[0166] (Procedure for correcting and registering) Next, an example of a modification registration process procedure executed by the CDL base control unit 910 will be described using Figure 15. The modification registration process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0167] Figure 15 is a flowchart showing an example of the modification registration process procedure in the first specific example. In Figure 15, the CDL base control unit 910 refers to the registered list and searches for registered data using the company's product ID of the data registration request as the key (step S1501).

[0168] Next, the CDL infrastructure control unit 910 obtains the data ID of the most recent registered data from the searched registered data as the previous data ID (step S1502). Then, the CDL infrastructure control unit 910 generates a registration JSON format using the registration data of the data registration request and the obtained previous data ID (step S1503).

[0169] Next, the CDL infrastructure control unit 910 executes the registration API using the generated registration JSON format (step S1504). Then, the CDL infrastructure control unit 910 terminates the modification registration process.

[0170] Next, using Figure 16, we will explain an example of Lineage 1600 representing branching. In the following explanation, global blocks may sometimes be simply referred to as "blocks."

[0171] Figure 16 is an explanatory diagram showing an example of Lineage 1600 representing branching. As shown in Figure 16, Lineage 1600 includes, for example, a block with data ID #01, a block with data ID #02, a block with data ID #03, a block with data ID #04, and a block with data ID #05.

[0172] In Lineage 1600, for example, the block with data ID #01 is a branching point. Specifically, Lineage 1600 branches from the block with data ID #01 into a branch to the block with data ID #02 and a branch to the block with data ID #04. Next, using Figure 17, an example of how the CDL infrastructure control unit 910 stores the connection status of Lineage 1600 will be described.

[0173] Figure 17 is an explanatory diagram showing an example of how the connection status of Lineage 1600 is stored. As shown in Figure 17, the CDL base control unit 910 stores the connection status of Lineage 1600 using the Lineage management table 1700.

[0174] The lineage management table 1700 has fields for data ID, previous data ID, and next data ID. Lineage management information is stored as a record in the lineage management table 1700 by setting information in each field for each block that makes up the lineage.

[0175] The Data ID field is set to the Data ID of the block. The Previous Data ID field is set to the Data ID of the other block that is linked immediately before the above block. The Next Data ID field is set to the Data ID of the other block that is linked immediately after the above block.

[0176] Lineage Management Table 1700 can represent that Lineage 1600 branches from the block with data ID #01 to the block with data ID #02 and to the block with data ID #04.

[0177] Next, using Figure 18, we will explain an example of Lineage 1800 that represents a merge.

[0178] Figure 18 is an explanatory diagram showing an example of Lineage 1800 representing a merge. As shown in Figure 18, Lineage 1800 includes, for example, a block with data ID #01, a block with data ID #02, a block with data ID #03, a block with data ID #04, a block with data ID #05, and a block with data ID #06.

[0179] In Lineage 1800, for example, the block with data ID #02 is a pseudo-merging point. Specifically, Lineage 1800 makes the block with data ID #02 a pseudo-merging point by concatenating the block with data ID #05, which is a duplicate of the block with data ID #02, after the block with data ID #04.

[0180] More specifically, Lineage 1800 simulates merging the branch from the block with data ID #01 to the block with data ID #02, and the branch from the block with data ID #04 to the block with data ID #02. Next, using Figure 19, an example of how the CDL infrastructure control unit 910 stores the connection status of Lineage 1800 will be described.

[0181] Figure 19 is an explanatory diagram illustrating an example of how the connection status of Lineage 1800 is stored. As shown in Figure 19, the CDL infrastructure control unit 910 stores the connection status of Lineage 1800 using the Lineage Management Table 1900. The data structure of the Lineage Management Table 1900 is the same as that of the Lineage Management Table 1700, so its explanation is omitted.

[0182] Lineage Management Table 1900 can represent that Lineage 1800 concatenates a block with data ID #05, which is a duplicate of the block with data ID #02, after the block with data ID #04.

[0183] Next, using Figure 20, an example of how the information processing system 200 forms a lineage representing a merge will be explained. Specifically, the CDL base control unit 910 will control the lineage by adding block duplicates to it in order to represent a merge.

[0184] Figure 20 is an explanatory diagram illustrating an example of forming a lineage representing a merger. In Figure 20, (20-1) suppose a user of Company A wants to register data for Company A's product A2, which uses Company B's product B1, into the lineage. Let's assume that Company B's product B1 is also used for Company A's product A1. Therefore, it is desirable to form a lineage representing a merger. Based on the user's input from Company A, the higher-level application 900A sends a data registration request to the CDL base control unit 910A, which includes Company ID, Company product ID, supplier ID, supplier product ID, and product information.

[0185] (20-2) The CDL infrastructure control unit 910A receives a data registration request. The CDL infrastructure control unit 910A obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910A refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 38.

[0186] Here, the CDL infrastructure control unit 910A determines that the data is new. Since the CDL infrastructure control unit 910A is at the very bottom of the chain, it sets the previous data ID to empty. Because the CDL infrastructure control unit 910A has determined that the data is new, it generates a registration JSON format that includes the registration data (product information) that is the target of the data registration request, and the set previous data ID (empty).

[0187] The registration JSON format is a combination of a global block containing, for example, a previous data ID=empty, and a local block containing registration data=product information. The CDL infrastructure control unit 910A uses the generated registration JSON format to execute a registration API on the CDL infrastructure 920A.

[0188] (20-3) The CDL infrastructure 920A accepts the registration JSON format via the registration API. The CDL infrastructure 920A generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920A calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920A adds the registration JSON format to the lineage. The CDL infrastructure 920A sends a response containing the generated data ID to the CDL infrastructure control unit 910A.

[0189] (20-4) When the CDL infrastructure control unit 910A receives a response containing the data ID, it determines that the registration data has been registered in the lineage because a local block containing the registration data, which is associated with the global block, is added to the lineage. Since the registration data has been registered in the lineage, the CDL infrastructure control unit 910A retrieves the data ID included in the response. The CDL infrastructure control unit 910A sends a registration notification containing the retrieved company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910B.

[0190] (20-5) The CDL base control unit 910B receives a registration notification from the preceding CDL base control unit 910A. The CDL base control unit 910B uses the ordering product ID of the registration notification as a key to search the registered list for a product ID that matches the ordering product ID of the registration notification.

[0191] Here, the CDL infrastructure control unit 910B outputs an alarm to B company's users if it does not find a product ID that matches the supplier product ID in the registration notification. On the other hand, if the CDL infrastructure control unit 910B finds a product ID that matches the supplier product ID in the registration notification, it determines to generate a copy of the existing block to indicate a merger and continues processing without outputting an alarm to B company's users. Here, let's assume that the CDL infrastructure control unit 910B has found a product ID that matches the supplier product ID in the registration notification.

[0192] (20-6) The CDL infrastructure control unit 910B reads and retrieves the source data ID, company product ID, supplier ID, and supplier product ID from the registered list using the discovered product ID as the key. The source data ID is the data ID corresponding to the discovered product ID. The company product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910B retrieves the company ID.

[0193] (20-7) Since the CDL infrastructure control unit 910B is not at the very bottom of the chain, it extracts the data ID from the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910B generates a JSON format for registering the replicated data, which includes the set previous data ID = the data ID from the registration notification, and a copy of the local block representing the replicated data that is attached to the block of the source data ID. An example of the JSON format for registering the replicated data will be described later using Figure 21.

[0194] The registration JSON format is a combination of a global block containing, for example, the previous data ID = the data ID of the registration notification and with the replication flag set to 1, and a local block copy associated with the source data ID block. The CDL infrastructure control unit 910B uses the generated registration JSON format to execute the registration API to the CDL infrastructure 920B.

[0195] (20-8) The CDL infrastructure 920B accepts the registration JSON format via the registration API. The CDL infrastructure 920B generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920B calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920B adds the registration JSON format to the lineage. The CDL infrastructure 920B sends a response containing the generated data ID to the CDL infrastructure control unit 910B.

[0196] (20-9) When the CDL infrastructure control unit 910B receives a response containing the data ID, it determines that the replicated data has been registered in the lineage because a local block containing the replicated data, which is associated with the global block, has been added to the lineage. The CDL infrastructure control unit 910B determines that the merge has been represented in the lineage because the replicated data has been registered in the lineage. The CDL infrastructure control unit 910B obtains the data ID included in the response because the replicated data has been registered in the lineage. The CDL infrastructure control unit 910B sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910C.

[0197] (20-10) The CDL base control unit 910C receives a registration notification from the preceding CDL base control unit 910B. The CDL base control unit 910C uses the ordering product ID of the registration notification as a key to search the registered list for a product ID that matches the ordering product ID of the registration notification.

[0198] Here, the CDL infrastructure control unit 910C outputs an alarm to the user of Company C if it does not find a product ID that matches the supplier product ID in the registration notification. On the other hand, if the CDL infrastructure control unit 910C finds a product ID that matches the supplier product ID in the registration notification, it determines to generate a copy of the existing block to indicate a merger and continues processing without outputting an alarm to the user of Company C. Here, let's assume that the CDL infrastructure control unit 910C has found a product ID that matches the supplier product ID in the registration notification.

[0199] (20-11) The CDL infrastructure control unit 910C reads and retrieves the source data ID, company product ID, supplier ID, and supplier product ID from the registered list using the discovered product ID as the key. The source data ID is the data ID corresponding to the discovered product ID. The company product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910C retrieves the company ID.

[0200] (20-12) The CDL infrastructure control unit 910C, since it is not at the very bottom of the chain, extracts the data ID from the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910C generates a JSON format for registering the replicated data, which includes the set previous data ID = the data ID from the registration notification, and a copy of the local block representing the replicated data that is attached to the block of the source data ID.

[0201] The registration JSON format is a combination of a global block containing, for example, the previous data ID = the data ID of the registration notification and with the replication flag set to 1, and a local block copy associated with the source data ID block. The CDL infrastructure control unit 910C uses the generated registration JSON format to execute the registration API to the CDL infrastructure 920C.

[0202] (20-13) The CDL infrastructure 920C accepts the registration JSON format via the registration API. The CDL infrastructure 920C generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920C calculates the hash values ​​for the global block and the local block of the registration JSON format and sets them in the global block. Then, the CDL infrastructure 920C adds the registration JSON format to the lineage. The CDL infrastructure 920C sends a response containing the generated data ID to the CDL infrastructure control unit 910C.

[0203] (20-14) When the CDL infrastructure control unit 910C receives a response containing a data ID, it determines that the replicated data has been registered in the lineage because a local block containing the replicated data, which is associated with the global block, has been added to the lineage. The CDL infrastructure control unit 910C determines that a merge has been represented in the lineage because the replicated data has been registered in the lineage. The CDL infrastructure control unit 910C obtains the data ID included in the response because the replicated data has been registered in the lineage. The CDL infrastructure control unit 910C sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910D (not shown).

[0204] Thus, the information processing system 200 can simulate branch merging even when it is difficult to directly represent branch merging in Lineage. Therefore, the information processing system 200 can flexibly update the CDL. The information processing system 200 can represent branch merging without outputting alarms to users of company B and users of company C. Therefore, the information processing system 200 can reduce the workload on users. Next, an example of the JSON format 2100 for registering duplicate data will be explained using Figure 21.

[0205] Figure 21 is an explanatory diagram showing an example of the JSON format 2100 for registering duplicate data. As shown in Figure 21, the JSON format 2100 for registering duplicate data includes a global block with the duplicate flag: 1 set. The duplicate flag, for example, indicates that it is a duplicate if its value is 1. The global block in the JSON format 2100 for registering duplicate data may have different data IDs, previous data IDs, etc., from the original global block.

[0206] The JSON format 2100 for registering duplicate data includes a copy of the local block associated with the original global block. The JSON format 2100 for registering duplicate data does not include the next data ID, the hash value for the global block, or the hash value for the local block.

[0207] The next data ID, the hash value for the global block, and the hash value for the local block are set by the CDL infrastructure 920. Once the next data ID, the hash value for the global block, and the hash value for the local block are set, the specific global block 2101 and local block 2102 to be added to Lineage are generated.

[0208] (Procedure for registering copies) Next, an example of a replication registration process procedure performed by the CDL base control unit 910 will be described using Figure 22. The replication registration process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0209] Figure 22 is a flowchart showing an example of the replication registration process procedure in the first specific example. In Figure 22, the CDL base control unit 910 receives a registration notification from the preceding CDL base control unit 910 (step S2201). The registration notification includes the company ID, company product ID, supplier ID, supplier product ID, and data ID.

[0210] Next, the CDL base control unit 910 refers to the registered list and determines whether the data ID of the registration notification is already registered (step S2202). If it is not already registered (step S2202: No), the CDL base control unit 910 proceeds to the process in step S2203. On the other hand, if it is already registered (step S2202: Yes), the CDL base control unit 910 proceeds to the process in step S2204.

[0211] In step S2203, the CDL infrastructure control unit 910 records the data ID of the registration notification in the unregistered list (step S2203). The CDL infrastructure control unit 910 records and manages, for example, the company ID, company product ID, and data ID of the registration notification in the unregistered list. Then, the CDL infrastructure control unit 910 terminates the replication registration process.

[0212] In step S2204, the CDL infrastructure control unit 910 retrieves the registered data contained in the local block using the registered data ID as the key (step S2204). Next, the CDL infrastructure control unit 910 retrieves the duplicated data, which is a copy of the registered data, and generates a registration JSON format for the retrieved duplicated data (step S2205). Then, the CDL infrastructure control unit 910 executes the registration API using the registration JSON format of the duplicated data (step S2206).

[0213] Next, the CDL infrastructure control unit 910 obtains the response from the registration API, clears the unregistered list, and adds the response data ID to the registered list (step S2207). Then, the CDL infrastructure control unit 910 generates a registration notification including the company ID, company product ID, supplier ID, supplier product ID, and response data ID, and sends it to the subsequent CDL infrastructure control unit 910 (step S2208). Finally, the CDL infrastructure control unit 910 terminates the replication registration process.

[0214] Next, using Figure 23, we will explain an example of how the CDL infrastructure control unit 910 invalidates registered Lineage data.

[0215] Figure 23 is an explanatory diagram illustrating an example of disabling. In Figure 23, Lineage 2300 is assumed to include, for example, a block with data ID #01, a block with data ID #02, and a block with data ID #03. Now, suppose we add, for example, a block with data ID #04 and a block with data ID #05 to Lineage 2300.

[0216] In Lineage 2300, instead of adding blocks with data ID #04 and data ID #05, it may be desirable to invalidate the registration data for blocks with data ID #02 and data ID #03. Therefore, blocks with data ID #02 and data ID #03 containing registration data will be invalidated, and the branch from block with data ID #02 to block with data ID #03 will be invalidated.

[0217] In this case, for example, the CDL infrastructure control unit 910 that manages the block with data ID #01 may send an invalidation notification to the CDL infrastructure control unit 910 that manages the block with data ID #02.

[0218] For example, the CDL infrastructure control unit 910, which manages the block with data ID #02, controls the lineage in response to the invalidation notification to concatenate the block with data ID #07, which has an invalidation flag of 1, one block after the block with data ID #02. The CDL infrastructure control unit 910 sets the data ID of the concatenated block with data ID #07 as the next data ID after the block with data ID #02. The CDL infrastructure control unit 910 sends the invalidation notification to the CDL infrastructure control unit 910 that manages the subsequent block with data ID #03.

[0219] Similarly, for example, the CDL infrastructure control unit 910, which manages the block with data ID #03, controls the lineage in response to the invalidation notification to concatenate the block with data ID #07, which has an invalidation flag of 1, one block after the block with data ID #03. The CDL infrastructure control unit 910 sets the data ID #07 of the concatenated block with data ID #07 as the next data ID after the block with data ID #03. In this way, the information processing system 200 can invalidate registered data in the lineage without deleting the block containing the registered data. Next, an example of a lineage 2400 representing invalidation will be described using Figure 24.

[0220] Figure 24 is an explanatory diagram illustrating an example of Lineage 2400 representing invalidation. As shown in Figure 24, Lineage 2400 may include, for example, a block with data ID #01, a block with data ID #02, and a block with data ID #03. Here, there may be cases where it is desirable to invalidate blocks with data ID #02 and data ID #03 instead of adding, for example, blocks with data ID #04 and blocks with data ID #05 to Lineage 2400.

[0221] Specifically, Lineage 2400 represents the invalidation of the data ID #02 block by concatenating the data ID #06 block, which represents invalidation, one block after the data ID #02 block. Similarly, Lineage 2400 represents the invalidation of the data ID #03 block by concatenating the data ID #07 block, which represents invalidation, one block after the data ID #03 block. Next, an example of how the CDL base control unit 910 stores the connection status of Lineage 2400 will be explained using Figure 25.

[0222] Figure 25 is an explanatory diagram illustrating an example of how the connection status of Lineage 2400 is stored. As shown in Figure 25, the CDL infrastructure control unit 910 stores the connection status of Lineage 2400 using the Lineage management table 2500. The data structure of the Lineage management table 2500 is the same as that of the Lineage management table 1700, so its explanation is omitted.

[0223] For example, Lineage Management Table 2500 can represent that Lineage 2400 concatenates the block with data ID #06 one block after the block with data ID #02. Lineage Management Table 2500 can represent that Lineage 2400 concatenates the block with data ID #07 one block after the block with data ID #03.

[0224] Next, using Figure 26, a specific example of how the information processing system 200 invalidates registered data will be explained. Specifically, the CDL base control unit 910 will control the lineage to add a new block representing invalidation in order to indicate that the registered data is being invalidated.

[0225] Figure 26 is an explanatory diagram illustrating a specific example of invalidating registered data. In Figure 26, (26-1) suppose a user of Company A no longer uses Company B's product B1 with Company A's product A1, and therefore wishes to invalidate the registered data for Company B's product B1. For this reason, it is desirable to invalidate the block containing the registered data for Company B's product B1. Based on the user's input from Company A, the higher-level application 900A sends a cancellation request including the supplier ID and supplier product ID to the CDL base control unit 910A.

[0226] (26-2) The CDL infrastructure control unit 910A receives the cancellation request. The CDL infrastructure control unit 910A obtains the supplier ID and the supplier product ID from the cancellation request. The CDL infrastructure control unit 910A obtains its own company ID as the ordering company ID. The CDL infrastructure control unit 910A obtains its own company product ID as the ordering company product ID. The CDL infrastructure control unit 910A sends a cancellation notification containing the obtained ordering company ID, ordering company product ID, supplier ID, and supplier product ID to the subsequent CDL infrastructure control unit 910B.

[0227] (26-3) The CDL base control unit 910B receives a cancellation notification from the preceding CDL base control unit 910A. The CDL base control unit 910B uses the ordered product ID of the cancellation notification as a key to search the registered list for a product ID that matches the ordered product ID of the cancellation notification.

[0228] Here, the CDL infrastructure control unit 910B outputs an alarm to the user of Company B if it does not find a product ID that matches the ordered product ID in the cancellation notice. On the other hand, if the CDL infrastructure control unit 910B finds a product ID that matches the ordered product ID in the cancellation notice, it sets the block containing the registered data corresponding to the found product ID to be invalidated. Here, let's assume that the CDL infrastructure control unit 910B has found a product ID that matches the ordered product ID in the cancellation notice.

[0229] (26-4) The CDL infrastructure control unit 910B reads and obtains the data ID, supplier ID, and supplier product ID corresponding to the discovered product ID from the registered list, using the discovered product ID as the key. The supplier ID is the notification destination organization ID corresponding to the discovered product ID. The supplier product ID is the notification destination product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910C may also obtain the next data ID using the discovered product ID as the key.

[0230] (26-5) The CDL base control unit 910B obtains the data ID corresponding to the product ID as the previous data ID. The CDL base control unit 910B generates a JSON format for registering invalidation data, including the set previous data ID. An example of the JSON format for registering invalidation data will be described later using Figure 27.

[0231] The JSON format for registering invalid data includes, for example, a global block containing the previous data ID and setting the invalid flag to 1. The JSON format for registering invalid data does not necessarily have to include, for example, a local block. The CDL infrastructure control unit 910B uses the generated JSON format for registering invalid data to execute a registration API to the CDL infrastructure 920B.

[0232] (26-6) The CDL infrastructure 920B accepts the registration JSON format for invalidation data via the registration API. The CDL infrastructure 920B generates a new data ID and sets it in the accepted registration JSON format for invalidation data. The CDL infrastructure 920B calculates a hash value for the global block in the registration JSON format for invalidation data and sets it in the global block. Then, the CDL infrastructure 920B adds the registration JSON format for invalidation data to the lineage. The CDL infrastructure 920B sends a response containing the generated data ID to the CDL infrastructure control unit 910B.

[0233] (26-7) When the CDL base control unit 910B receives a response including a data ID, it determines that an existing block in Lineage has been invalidated by adding a block of invalidation data to Lineage. The CDL base control unit 910B determines that because the existing block has been invalidated, the invalidation of the registered data of the existing block has been represented in Lineage.

[0234] The CDL infrastructure control unit 910B sends a cancellation notification, including the ordering party ID, ordering party product ID, supplier ID, and supplier product ID, to the subsequent CDL infrastructure control unit 910C. The ordering party ID is the company's own ID. The ordering party product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID.

[0235] (26-8) The CDL base control unit 910C receives a cancellation notification from the preceding CDL base control unit 910B. The CDL base control unit 910C uses the ordered product ID of the cancellation notification as a key to search the registered list for a product ID that matches the ordered product ID of the cancellation notification.

[0236] Here, the CDL infrastructure control unit 910C outputs an alarm to the user of Company C if it does not find a product ID that matches the ordered product ID in the cancellation notice. On the other hand, if the CDL infrastructure control unit 910C finds a product ID that matches the ordered product ID in the cancellation notice, it sets the block containing the registered data corresponding to the found product ID to be invalidated. Here, let's assume that the CDL infrastructure control unit 910C has found a product ID that matches the ordered product ID in the cancellation notice.

[0237] (26-9) The CDL infrastructure control unit 910C reads and obtains the data ID, supplier ID, and supplier product ID corresponding to the discovered product ID from the registered list, using the discovered product ID as the key. The supplier ID is the notification destination organization ID corresponding to the discovered product ID. The supplier product ID is the notification destination product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910C may also obtain the next data ID using the discovered product ID as the key.

[0238] (26-10) The CDL base control unit 910C obtains the data ID corresponding to the product ID as the previous data ID. The CDL base control unit 910C generates a JSON format for registering invalidation data, including the set previous data ID. An example of the JSON format for registering invalidation data will be described later using Figure 27.

[0239] The JSON format for registering invalid data includes, for example, a global block containing the previous data ID and setting the invalid flag to 1. The JSON format for registering invalid data does not necessarily have to include, for example, a local block. The CDL infrastructure control unit 910C uses the generated JSON format for registering invalid data to execute a registration API to the CDL infrastructure 920C.

[0240] (26-11) The CDL infrastructure 920C accepts the registration JSON format for invalidation data via the registration API. The CDL infrastructure 920C generates a new data ID and sets it in the accepted registration JSON format for invalidation data. The CDL infrastructure 920C calculates a hash value for the global block in the registration JSON format for invalidation data and sets it in the global block. Subsequently, the CDL infrastructure 920C adds the registration JSON format for invalidation data to the lineage. The CDL infrastructure 920C sends a response containing the generated data ID to the CDL infrastructure control unit 910C.

[0241] (26-12) When the CDL base control unit 910C receives a response including a data ID, it determines that an existing block in Lineage has been invalidated by adding a block of invalidation data to Lineage. The CDL base control unit 910C determines that because the existing block has been invalidated, the invalidation of the registered data of the existing block has been represented in Lineage.

[0242] The CDL infrastructure control unit 910C sends a cancellation notification, including the ordering party ID, ordering party product ID, supplier ID, and supplier product ID, to the subsequent CDL infrastructure control unit 910D (not shown). The ordering party ID is the company's own ID. The ordering party product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID.

[0243] Thus, the information processing system 200 can represent the invalidation of registered block data even when it is difficult to directly delete a block in Lineage. Therefore, the information processing system 200 can make CDLs (Common Data Lists) flexibly updatable. The information processing system 200 can represent the invalidation of registered block data without issuing alarms to users of Company B and users of Company C. Therefore, the information processing system 200 can reduce the workload on users. Next, an example of the JSON format 2700 for registering invalidation data will be explained using Figure 27.

[0244] Figure 27 is an explanatory diagram showing an example of the JSON format 2700 for registering invalid data. As shown in Figure 27, the JSON format 2700 for registering invalid data includes a global block with the invalid flag: 1 set. The invalid flag, for example, if its value is 1, indicates that the registered data of the preceding concatenated block is invalid. The JSON format 2700 for registering invalid data does not necessarily have to include local blocks.

[0245] The JSON format 2700 for registering invalidation data does not include the next data ID, the hash value for the global block, or the hash value for the local block. The hash value for the global block is set by the CDL infrastructure 920. Setting the hash value for the global block generates the specific global block 2701 to be added to Lineage.

[0246] (Branch registration processing procedure) Next, an example of a branch registration processing procedure executed by the CDL base control unit 910 will be described using Figure 28. The branch registration processing is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0247] Figure 28 is a flowchart showing an example of a branch registration processing procedure. In Figure 28, the CDL base control unit 910 receives a branch request (step S2801). The branch request includes, for example, the company's product ID to be branched, the supplier ID for the additional component, and the supplier product ID for the additional component.

[0248] Next, the CDL base control unit 910 extracts the company's product ID to be branched, the supplier ID for additional components, and the supplier product ID from the branching request parameters (step S2802). Then, using the company's product ID as the key, the CDL base control unit 910 extracts a data ID that makes it possible to identify the block that will be the branching point (step S2803).

[0249] Next, the CDL base control unit 910 adopts the extracted data ID as the previous data ID, generates corrected data to modify information about an existing branch destination block rather than a new branch destination block, and adds it to the lineage (step S2804). Specifically, the corrected data is added to the lineage by the correction registration process described above.

[0250] The CDL base control unit 910 then acquires the extracted data ID or the data ID included in the response of the modification registration process as the previous data ID. The CDL base control unit 910 transmits the acquired previous data ID, along with the supplier ID of the additional component and the company's own product ID, to the next CDL base control unit 910 (step S2805). After that, the CDL base control unit 910 terminates the branch registration process.

[0251] (First deactivation procedure) Next, an example of the first deactivation process procedure executed by the CDL base control unit 910 will be described using Figure 29. The first deactivation process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0252] FIG. 29 is a flowchart showing an example of the first invalidation processing procedure. In FIG. 29, the CDL base control unit 910 receives an invalidation request from the company's upper application 900 (step S2901).

[0253] The invalidation request includes, for example, an order source product ID that enables identification of a block including registered data of the order source product, which is the starting point of a branch formed by a block including registered data of the invalidation target, and an order source ID. The invalidation request includes, for example, an order destination ID corresponding to the registered data of the invalidation target, and an order destination product ID corresponding to the registered data of the invalidation target.

[0254] Next, the CDL base control unit 910 extracts the order source ID, order source product ID, order destination ID, and order destination product ID from the parameters of the invalidation request (step S2902). Then, the CDL base control unit 910 searches for the registered data using the obtained order destination product ID as a key, and extracts the data ID, order destination ID, and order destination product ID of the discovered registered data (step S2903).

[0255] Next, the CDL base control unit 910 adopts the extracted data ID as the previous data ID, generates correction data for correcting information on the block that becomes the existing branch destination, and adds it to the lineage (step S2904). Specifically, the correction data is added to the lineage by the above-described correction registration process.

[0256] Then, the CDL base control unit 910 transmits an invalidation notification to the subsequent CDL base control unit 910 based on the extracted order source ID, order source product ID, order destination ID, and order destination product ID (step S2905). The invalidation notification includes the order source ID, order source product ID, order destination ID, and order destination product ID. The CDL base control unit 910 ends the first invalidation process.

[0257] (Second Invalidation Processing Procedure) Next, an example of a second deactivation process procedure executed by the CDL base control unit 910 will be described using Figure 30. The second deactivation process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0258] Figure 30 is a flowchart showing an example of the second deactivation process. In Figure 30, the CDL base control unit 910 refers to the registered list and searches for registered data using the ordering product ID and the ordering product ID of the deactivation notice received from the preceding CDL base control unit 910 as keys (step S3001). The deactivation notice includes, for example, the ordering ID, ordering product ID, ordering ID, and ordering product ID.

[0259] Next, the CDL infrastructure control unit 910 refers to the registered list and obtains the data ID, notification recipient organization ID, and notification recipient product ID of the most recent registered data from the searched registered data (step S3002). The CDL infrastructure control unit 910 adopts the ordering party ID and ordering party product ID of the invalidation notification as the next ordering party ID and the next ordering party product ID. The CDL infrastructure control unit 910 adopts the obtained notification recipient organization ID and notification recipient product ID as the next ordering party ID and the next ordering party product ID.

[0260] Then, the CDL infrastructure control unit 910 adopts the acquired data ID as the previous data ID, and registers the invalidation data in Lineage using the adopted previous data ID, ordering company ID, ordering company product ID, supplier ID, and supplier product ID (step S3003). For example, the CDL infrastructure control unit 910 uses the previous data ID, ordering company ID, ordering company product ID, supplier ID, and supplier product ID to generate a JSON format for registering invalidation data, executes the registration API, and registers the invalidation data in Lineage.

[0261] Next, the CDL base control unit 910 sends a deactivation notice to the subsequent CDL base control unit 910 based on the adopted ordering ID, ordering product ID, supplier ID, and supplier product ID (step S3004). The deactivation notice includes the ordering ID, ordering product ID, supplier ID, and supplier product ID. Then, the CDL base control unit 910 terminates the second deactivation process.

[0262] Next, using Figures 31 and 32, we will describe another example of how the CDL infrastructure control unit 910 invalidates registered Lineage data.

[0263] Figures 31 and 32 are explanatory diagrams illustrating another example of invalidation. As shown in Figure 31, it is desired to invalidate the blocks with data ID #02, data ID #03, and data ID #04 in Lineage 3100.

[0264] In contrast, the CDL infrastructure control unit 910 may use the invalidation management table 3101 to indicate that the blocks with data ID #02, data ID #03, and data ID #04 are invalidated. In this case, the CDL infrastructure control unit 910 does not need to concatenate a block indicating invalidation to the blocks with data ID #02, data ID #03, and data ID #04.

[0265] The deactivation management table 3101 has fields for data ID and deactivation flag. The deactivation management table 3101 stores deactivation management information as records by setting information in each field for each block that makes up the lineage.

[0266] The Data ID field is set to the block's data ID. The Invalid Flag field is set to an invalid flag indicating whether or not to invalidate the block. For example, a value of 1 indicates invalidation. For example, a value of 0 indicates not to invalidate. Next, we will move on to the explanation of Figure 32.

[0267] In the example shown in Figure 31, the CDL infrastructure control unit 910 manages the deactivation status of all blocks in Lineage 3100 using the deactivation management table 3101. In contrast, as shown in Figure 32, the CDL infrastructure control unit 910 may also manage the deactivation status of blocks in Lineage 3200 that correspond to the company's own operations using deactivation management tables 3201 to 3204, etc.

[0268] As shown in Figure 32, in Lineage 3200, block with data ID #01 is assumed to correspond to company A. Blocks with data ID #02 and data ID #05 in Lineage 3200 are assumed to correspond to company B. Blocks with data ID #03 and data ID #06 in Lineage 3200 are assumed to correspond to company C. Blocks with data ID #04 and data ID #07 in Lineage 3200 are assumed to correspond to company D. Now, let's assume it is desired to disable blocks with data ID #02, data ID #03, and data ID #04 in Lineage 3200.

[0269] In response, Company B's CDL control unit 910B uses the invalidation management table 3202 to indicate that the block with data ID #02 will be invalidated. Company C's CDL control unit 910C uses the invalidation management table 3203 to indicate that the block with data ID #03 will be invalidated. Company D's CDL control unit 910D uses the invalidation management table 3204 to indicate that the block with data ID #04 will be invalidated.

[0270] The data structure of invalidation management tables 3201 to 3204 is specifically the same as the data structure of invalidation management table 3101, so its explanation is omitted. In this way, the information processing system 200 can invalidate registered Lineage data without deleting blocks containing registered data.

[0271] Next, using FIG. 33, another specific example in which the information processing system 200 invalidates registered data will be described. Specifically, it will be expressed that the CDL base control unit 910 invalidates the registered data using the invalidation management table.

[0272] FIG. 33 is an explanatory diagram showing another specific example of invalidating registered data. In FIG. 33, (33-1) For example, a user of Company A has stopped using Product B1 of Company B in Product A1 of Company A, and thus wishes to invalidate the registered data of Product B1 of Company B. Therefore, it is desired to invalidate the block including the registered data of Product B1 of Company B. The upper application 900A transmits a cancellation request including the order destination ID and the order destination product ID to the CDL base control unit 910A based on the operation input of the user of Company A.

[0273] (33-2) The CDL base control unit 910A receives the cancellation request. The CDL base control unit 910A acquires the order destination ID and the order destination product ID from the cancellation request. The CDL base control unit 910A transmits a cancellation notice including the acquired order destination ID and the order destination product ID to the subsequent CDL base control unit 910B.

[0274] (33-3) The CDL base control unit 910B receives the cancellation notice from the previous CDL base control unit 910A. The CDL base control unit 910B searches the registered list for a product ID that matches the order destination product ID of the cancellation notice using the order destination product ID of the cancellation notice as a key.

[0275] Here, if the CDL base control unit 910B does not find a product ID that matches the order destination product ID of the cancellation notice, it outputs an alarm to the user of Company B. On the other hand, when the CDL base control unit 910B finds a product ID that matches the order destination product ID of the cancellation notice, it sets the block including the registered data corresponding to the found product ID as the target to be invalidated. Here, it is assumed that the CDL base control unit 910B has found a product ID that matches the order destination product ID of the cancellation notice.

[0276] (33-4) The CDL infrastructure control unit 910B reads and obtains the data ID, supplier ID, and supplier product ID corresponding to the discovered product ID from the registered list, using the discovered product ID as the key. The supplier ID is the notification destination organization ID corresponding to the discovered product ID. The supplier product ID is the notification destination product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910B may also obtain the next data ID using the discovered product ID as the key.

[0277] (33-5) The CDL infrastructure control unit 910B stores the acquired data ID in association with the invalidation flag: 1 using the company's own invalidation management table 3300B. In this way, the CDL infrastructure control unit 910B indicates that the registered data in the block of the acquired data ID will be invalidated.

[0278] (33-6) The CDL infrastructure control unit 910B sends a cancellation notification, including the supplier ID and the supplier product ID, to the subsequent CDL infrastructure control unit 910C. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID.

[0279] (33-7) The CDL base control unit 910C receives a cancellation notification from the preceding CDL base control unit 910B. The CDL base control unit 910C uses the ordered product ID of the cancellation notification as a key to search the registered list for a product ID that matches the ordered product ID of the cancellation notification.

[0280] Here, the CDL infrastructure control unit 910C outputs an alarm to the user of Company C if it does not find a product ID that matches the ordered product ID in the cancellation notice. On the other hand, if the CDL infrastructure control unit 910C finds a product ID that matches the ordered product ID in the cancellation notice, it sets the block containing the registered data corresponding to the found product ID to be invalidated. Here, let's assume that the CDL infrastructure control unit 910C has found a product ID that matches the ordered product ID in the cancellation notice.

[0281] (33-8) The CDL infrastructure control unit 910C reads and obtains the data ID, supplier ID, and supplier product ID corresponding to the discovered product ID from the registered list, using the discovered product ID as the key. The supplier ID is the notification destination organization ID corresponding to the discovered product ID. The supplier product ID is the notification destination product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910C may also obtain the next data ID using the discovered product ID as the key.

[0282] (33-9) The CDL infrastructure control unit 910C stores the acquired data ID in association with the invalidation flag: 1 using the company's invalidation management table 3300C. In this way, the CDL infrastructure control unit 910C indicates that the registered data in the block of the acquired data ID will be invalidated.

[0283] (33-10) The CDL infrastructure control unit 910C sends a cancellation notification, including the supplier ID and the supplier product ID, to the subsequent CDL infrastructure control unit 910D. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID.

[0284] Thus, the information processing system 200 can represent the invalidation of registered block data even when it is difficult to directly delete a block in Lineage. Therefore, the information processing system 200 can make CDLs (Common Data Lists) flexibly updatable. The information processing system 200 can represent the invalidation of registered block data without issuing alarms to users of company B and users of company C. Therefore, the information processing system 200 can reduce the workload on users.

[0285] (Third deactivation procedure) Next, an example of a third disabling process procedure executed by the CDL base control unit 910 will be described using Figure 34. The third disabling process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703. The third disabling process is executed, for example, in place of the first disabling process.

[0286] Figure 34 is a flowchart showing an example of the third deactivation process. In Figure 34, the CDL base control unit 910 receives a deactivation request from the company's higher-level application 900 (step S3401).

[0287] The invalidation request includes, for example, a customer product ID that identifies the block containing the customer product's registered data, which serves as the starting point for a branch formed by the block containing the registered data to be invalidated. The invalidation request also includes, for example, a supplier ID corresponding to the registered data to be invalidated, and a supplier product ID corresponding to the registered data to be invalidated.

[0288] Next, the CDL base control unit 910 extracts the ordering product ID, the supplier ID, and the supplier product ID from the parameters of the invalidation request (step S3402). Then, the CDL base control unit 910 searches the registered data using the ordering product ID as the key and extracts the data ID, supplier ID, and supplier product ID of the found registered data (step S3403).

[0289] Next, the CDL base control unit 910 adopts the extracted data ID as the previous data ID, generates corrected data to modify the information about the existing branch destination block, and adds it to the lineage (step S3404). Specifically, the corrected data is added to the lineage by the correction registration process described above.

[0290] Then, the CDL base control unit 910 sends a deactivation notice to the subsequent CDL base control unit 910 based on the extracted ordering party ID, ordering party product ID, supplier ID, and supplier product ID (step S3405). The deactivation notice includes the ordering party ID, ordering party product ID, supplier ID, and supplier product ID. The CDL base control unit 910 then terminates the third deactivation process.

[0291] (Fourth deactivation procedure) Next, an example of the fourth deactivation process procedure executed by the CDL base control unit 910 will be described using Figure 35. The fourth deactivation process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703. The fourth deactivation process is executed, for example, in place of the second deactivation process.

[0292] Figure 35 is a flowchart showing an example of the fourth deactivation process. In Figure 35, the CDL base control unit 910 searches for records in the registered list using the ordering party ID, ordering party product ID, supplier ID, and supplier product ID of the deactivation notification received from the preceding CDL base control unit 910 as keys (step S3501).

[0293] Next, the CDL infrastructure control unit 910 sets the invalid flag: 1 to the data ID of the retrieved record and records it using the invalidation management table (step S3502). The CDL infrastructure control unit 910 adopts the supplier ID and supplier product ID of the invalidation notification as the next supplier ID and next supplier product ID. The CDL infrastructure control unit 910 adopts the notification recipient organization ID and notification recipient product ID of the retrieved record as the next supplier ID and next supplier product ID.

[0294] Then, the CDL base control unit 910 sends a deactivation notification to the subsequent CDL base control unit 910 based on the adopted ordering ID, ordering product ID, supplier ID, and supplier product ID (step S3503). After that, the CDL base control unit 910 terminates the fourth deactivation process.

[0295] Next, using Figures 36 to 38, we will explain an example of various data structures in the first specific example. First, using Figure 36, we will explain an example of the data structure for various notifications, such as data registration notifications and cancellation notifications.

[0296] Figure 36 is an explanatory diagram showing an example of the data structure of various notifications. As shown in Figure 36, notification 3600, which is used as a data registration notification or a cancellation notification, has fields for notification type, recipient organization ID, recipient product ID, source organization ID, source product ID, and previous data ID.

[0297] The Notification Type field contains flag information indicating whether Notification 3600 is a data registration notification or a cancellation notification. For example, a value of 0 indicates a data registration notification, while a value of 1 indicates a cancellation notification.

[0298] The Notification Recipient Organization ID field is set to the Notification Recipient Organization ID that identifies the recipient of Notification 3600. The Notification Recipient Product ID field is set to the Notification Recipient Product ID that identifies the product in the Notification Recipient of Notification 3600. The Notification Recipient Product ID identifies the product in the Notification Recipient of Notification 3600 that corresponds to a block added to Lineage by the Notification Recipient of Notification 3600. The Notification Recipient Product ID identifies the product in the Notification Recipient of Notification 3600 that is to be disabled.

[0299] The Notifying Organization ID field is set to the Notifying Organization ID, which identifies the source of notification 3600. The Notifying Organization ID field may be empty if notification 3600 is a cancellation notification. The Notifying Product ID field is set to the Notifying Product ID, which identifies the product in the source of notification 3600. The Notifying Product ID identifies, for example, the product corresponding to the block added to Lineage in the source of notification 3600. The Notifying Product ID field may be empty if notification 3600 is a cancellation notification.

[0300] The previous data ID field is set to the data ID of the block in the source of notification 3600. The previous data ID is, for example, the data ID of the block added to Lineage in the source of notification 3600. The previous data ID field may be empty if notification 3600 is a cancellation notification. Next, an example of the data structure of the unregistered list 3700 will be explained using Figure 37.

[0301] Figure 37 is an explanatory diagram showing an example of the data structure of the unregistered list 3700. As shown in Figure 37, the unregistered list 3700 has fields for the notified product ID, the notifying organization ID, the notifying product ID, and the previous data ID. The unregistered list 3700 stores unregistered data management information as a record by setting information in each field for each registered data.

[0302] In the "Notification Destination Product ID" field, the ordering product ID of the registration notification is set as the notification destination product ID. In the "Notification Source Organization ID" field, the ordering product ID of the registration notification is set as the notification destination organization ID. In the "Notification Source Product ID" field, the company's own product ID of the registration notification is set as the notification source product ID. In the "Previous Data ID" field, the data ID of the registration notification is set as the previous data ID. Next, an example of the data structure of the registered list 3800 will be explained using Figure 38.

[0303] Figure 38 is an explanatory diagram showing an example of the data structure of the registered list 3800. As shown in Figure 38, the registered list 3800 has fields for product ID, data ID, notifying organization ID, notifying product ID, previous data ID, notifying recipient organization ID, notifying recipient product ID, and registration type. The registered list 3800 stores registered data management information as a record by setting information in each field for each registered data.

[0304] The Product ID field is set to the Product ID corresponding to the registered data. The Data ID field is set to the Data ID corresponding to the registered data and set in the block containing the registered data. The Notifying Organization ID field is set to the company ID of the registration notification referenced when registering the registered data. The Notifying Product ID field is set to the company product ID of the registration notification referenced when registering the registered data.

[0305] The "Previous Data ID" field is set to the data ID of the block managed by the preceding CDL infrastructure control unit 910, which is the notification source, and which is linked one block before the block of registered data. The "Notification Destination Organization ID" field is set to the ordering party ID of the registration notification as the notification destination organization ID. The "Notification Destination Product ID" field is set to the ordering party product ID of the registration notification as the notification destination product ID.

[0306] The "Registration Type" field contains flag information indicating whether the registered data is a duplicate or not. For example, a value of 1 indicates that it is a duplicate. For example, a value of 0 indicates that it is the original data and not a duplicate. Original data is the original data that is not a copy of other data.

[0307] (Visualization processing procedure) Next, an example of a visualization processing procedure performed by the CDL base control unit 910 will be described using Figure 39. The visualization processing is realized, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0308] Figure 39 is a flowchart showing an example of a visualization processing procedure. In Figure 39, the CDL base control unit 910 receives a lineage acquisition request from the company's higher-level application 900 (step S3901). The lineage acquisition request includes, for example, a product ID that makes the lineage identifiable.

[0309] Next, the CDL base control unit 910 acquires a series of lineages using the product ID and other keys specified in the lineage acquisition request (step S3902). Then, the CDL base control unit 910 extracts the invalid flag: 1 blocks included in the acquired lineages and deletes the preceding block that is linked immediately before the extracted block from the acquired lineages (step S3903).

[0310] Next, the CDL base control unit 910 extracts the block of modified data included in the acquired Lineage, replaces the user-defined portion of the original data included in the user-defined portion of the latest data with the modified data, and then deletes the modified data (step S3904).

[0311] Next, the CDL infrastructure control unit 910 identifies product IDs that have duplicates among the product IDs included in the acquired lineage, based on the registered list, adopts the identified product IDs as confluence points, and updates the connection relationships of the acquired lineage (step S3905).

[0312] Then, the CDL base control unit 910 returns the lineage to the requester of the lineage acquisition request (step S3906). After that, the CDL base control unit 910 terminates the visualization process.

[0313] (A second specific example of the operation of the information processing device 100) Next, a second specific example of the operation of the information processing device 100 will be described using Figures 40 to 52. The first specific example is a case where user-defined information is included in a local block associated with a global block.

[0314] In contrast, the second specific example concerns a case where a local block associated with a global block does not directly contain user-defined information, but rather contains an identifier for user-defined information. This approach can suppress the increase in Lineage's data volume when generating copies of local blocks.

[0315] In the second specific example, the information processing system 200 utilizes a first lineage that represents the sequential relationships between products related to participants in the supply chain, and a second lineage that represents the change history of product information for each participant. In the following explanation, the first lineage may be referred to as the "horizontal chain." In the following explanation, the second lineage may be referred to as the "vertical chain." Now, we will move on to the explanation of Figure 40 and describe an example of the horizontal chain 4000.

[0316] Figure 40 is an explanatory diagram showing an example of a horizontal chain 4000. In Figure 40, since Company A's product A01 and Company A's product A02 use Company B's product B11, it is desirable that the horizontal chain 4000 represent the merging of branches. Accordingly, the horizontal chain 4000 includes a block for product A01 with data ID #H01, a block for product B11 with data ID #H02, a block for product C21 with data ID #H03, and a block for product A02 with data ID #H06.

[0317] Horizontal chain 4000 includes a block of product B11 with data ID #H07 and a block of product C21 with data ID #H08 to represent the merge. The block of product B11 with data ID #H07 is equivalent to a copy of the block of product B11 with data ID #H02. The block of product C21 with data ID #H08 is equivalent to a copy of the block of product C21 with data ID #H03.

[0318] Horizontal chain 4000 sequentially connects the block for product A01 with data ID #H01, the block for product B11 with data ID #H02, and the block for product C21 with data ID #H03. Horizontal chain 4000 sequentially connects the block for product A02 with data ID #H06, the block for product B11 with data ID #H07, and the block for product C21 with data ID #H08.

[0319] In this way, the horizontal chain 4000 can represent the merging of branches. Each block in the horizontal chain 4000 references a block in the vertical chain 4100 through a local block associated with that block. Next, an example of the vertical chain 4100 will be described using Figure 41.

[0320] Figure 41 is an explanatory diagram showing an example of a vertical chain 4100. As shown in Figure 41, the vertical chain 4100 includes a series of blocks corresponding to each product. For example, the vertical chain 4100 sequentially connects the block with data ID #V01 containing data VL01, the block with data ID #V09 containing data VL01, and the block with data ID #V16 containing data VL01.

[0321] For example, data VL01 corresponds to product A01. Data VL01 in the block with data ID #V09 is a modified version of data VL01 in the block with data ID #V01. Data VL01 in the block with data ID #V16 is a modified version of data VL01 in the block with data ID #V09.

[0322] The vertical chain 4100 sequentially connects, for example, the block with data ID #V02, the block with data ID #V10, the block with data ID #V17, and the block with data ID #V21. Each of the blocks with data ID #V02, data ID #V10, data ID #V17, and data ID #V21 contains data VL02.

[0323] For example, data VL02 corresponds to product A02. Data VL02 in the block with data ID#V10 is a modified version of data VL02 in the block with data ID#V02. Data VL02 in the block with data ID#V17 is a modified version of data VL02 in the block with data ID#V10. Data VL02 in the block with data ID#V21 is a modified version of data VL02 in the block with data ID#V17.

[0324] The vertical chain 4100 sequentially connects, for example, a block with data ID #V03 containing data VL03, a block with data ID #V11 containing data VL03, and a block with data ID #V18 containing data VL03.

[0325] Data VL03 corresponds to product B11. Data VL03 in the block with data ID #V11 is a modified version of Data VL03 in the block with data ID #V03. Data VL03 in the block with data ID #V18 is a modified version of Data VL03 in the block with data ID #V11.

[0326] The vertical chain 4100 includes, for example, a block with data ID #V05, which contains data VL05. Data VL05 is data corresponding to product C21. In this way, the vertical chain 4100 can represent the change history of information about each product. A series of blocks in the vertical chain 4100 are mapped to each block in the horizontal chain 4000 so that they can be referenced from that block. Next, a specific example of block 4200 in the horizontal chain 4000 will be described using Figure 42.

[0327] Figure 42 is an explanatory diagram showing a specific example of block 4200 in horizontal chain 4000. As shown in Figure 42, block 4200 is a global block. Block 4200 includes data ID, previous data ID, next data ID, organization ID, and product ID, etc. The data ID is identification information that identifies block 4200.

[0328] The previous data ID is identification information that identifies the other block linked immediately before block 4200. The next data ID is identification information that identifies the other block linked immediately after block 4200. The next data ID may be empty when block 4200 is added to the horizontal chain 4000. The organization ID is identification information that identifies the organization corresponding to block 4200. The product ID is identification information that identifies the product corresponding to block 4200.

[0329] Block 4200 is connected to the local block 4201. Block 4201 contains a notifying organization ID, a notifying product ID, n notifying destination organization IDs, n notifying destination product IDs, and a vertical chain ID. The notifying organization ID is identification information that identifies the organization corresponding to the block of the previous data ID. The notifying product ID is identification information that identifies the product corresponding to the block of the previous data ID.

[0330] The notification recipient organization ID is identification information that identifies the organization corresponding to the block of the next data ID. The notification recipient product ID is identification information that identifies the product corresponding to the block of the next data ID. The vertical chain ID is identification information that identifies the vertical chain 4100. Next, a specific example of block 4300 of the vertical chain 4100 will be explained using Figure 43.

[0331] Figure 43 is an explanatory diagram showing a specific example of block 4300 in vertical chain 4100. As shown in Figure 43, block 4300 is a global block. Block 4300 includes data ID, previous data ID, next data ID, vertical chain ID, organization ID, and product ID, etc. The data ID is identification information that identifies block 4300.

[0332] The previous data ID is identification information that identifies the other block linked immediately before block 4300. The next data ID is identification information that identifies the other block linked immediately after block 4300. The next data ID may be empty when block 4300 is added to vertical chain 4100. The vertical chain ID is identification information that identifies vertical chain 4100.

[0333] The Organization ID is identification information that identifies the organization corresponding to block 4300. The Product ID is identification information that identifies the product corresponding to block 4300. Block 4300 is connected to the local block 4301. Block 4301 contains user-defined data. User-defined data may include, for example, the number of parts used in the product corresponding to block 4300.

[0334] Next, using Figure 44, we will explain an example in which the CDL base control unit 910 of the information processing device 100 registers new data in Lineage in a second specific example.

[0335] Figure 44 is an explanatory diagram showing an example of registering new data in the second specific example. In Figure 44, (44-1) suppose a user of Company A wants to register data for Company A's product using Company B's product in Lineage. Based on the user's input from Company A, the higher-level application 900A sends a data registration request to the CDL infrastructure control unit 910A, which includes Company ID, Company Product ID, Supplier ID, Supplier Product ID, and product information.

[0336] Here, the Company ID is identification information that identifies Company A. The Company Product ID is identification information that identifies Company A's product for which data is registered. The Supplier ID is identification information that identifies Company B, which orders third-party products used in Company A's products. The Supplier Product ID is identification information that identifies Company B's product. The Product Information is data for Company A's product. The Product Information includes, for example, the attributes of Company B's product used in Company A's product. Attributes include, for example, quantity or price.

[0337] (44-2) The CDL infrastructure control unit 910A receives a data registration request. The CDL infrastructure control unit 910A obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910A refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 50.

[0338] Here, the CDL infrastructure control unit 910A determines that the data is new. Since the CDL infrastructure control unit 910A is at the bottom of the chain, it sets the previous data ID to empty. The CDL infrastructure control unit 910A obtains the vertical chain ID corresponding to the company's product ID. Since the CDL infrastructure control unit 910A has determined that the data is new, it generates a horizontal chain registration JSON format including the previous data ID = empty and the vertical chain ID, and a vertical chain registration JSON format including the registration data = product information.

[0339] The JSON format for horizontal chain registration is, for example, a combination of a global block containing the previous data ID = empty and a local block containing the vertical chain ID. The JSON format for vertical chain registration is, for example, a combination of a global block and a local block containing the registration data = product information. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated horizontal chain registration JSON format. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated vertical chain registration JSON format.

[0340] (44-3) The CDL infrastructure 920A accepts the registration JSON format for the horizontal chain via the registration API. The CDL infrastructure 920A generates a new data ID and sets it in the accepted registration JSON format for the horizontal chain. The CDL infrastructure 920A calculates the hash values ​​for the global block and the local block from the registration JSON format for the horizontal chain and sets them in the global block. Subsequently, the CDL infrastructure 920A adds the registration JSON format for the horizontal chain as a new block to the horizontal chain. The CDL infrastructure 920A sends a response to the CDL infrastructure control unit 910A that includes the generated data ID for the block added to the horizontal chain.

[0341] Similarly, the CDL infrastructure 920A accepts a registration JSON format for the vertical chain via the registration API. The CDL infrastructure 920A generates a new data ID and sets it in the accepted registration JSON format for the vertical chain. The CDL infrastructure 920A calculates the hash values ​​for the global block and the local block from the registration JSON format for the vertical chain and sets them in the global block. Subsequently, the CDL infrastructure 920A adds the registration JSON format for the vertical chain as a new block to the vertical chain. The CDL infrastructure 920A sends a response containing the generated data ID for the block added to the vertical chain to the CDL infrastructure control unit 910A.

[0342] (44-4) The CDL base control unit 910A receives a response containing a data ID for the block added to the horizontal chain. The CDL base control unit 910A receives a response containing a data ID for the block added to the vertical chain. When the CDL base control unit 910A receives both the response containing the data ID for the block added to the horizontal chain and the response containing the data ID for the block added to the vertical chain, it determines that the registration data has been registered in the vertical chain.

[0343] The CDL infrastructure control unit 910A obtains the data ID for the block added to the horizontal chain from the response containing the data ID for the block added to the horizontal chain, since the registration data has been registered in the vertical chain. The CDL infrastructure control unit 910A sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and the data ID for the block added to the horizontal chain to the subsequent CDL infrastructure control unit 910B.

[0344] (44-5) When the CDL base control unit 910B receives a registration notification from the preceding CDL base control unit 910A, it outputs an alarm to the user of Company B. The user of Company B refers to the alarm and understands that they are using Company B's product with Company A's product.

[0345] (44-6) A user of Company B wishes to register data of Company B's product using Company C's product in Lineage. Based on the user's input, the higher-level application 900B sends a data registration request to the CDL infrastructure control unit 910B, which includes Company B's ID, Company B's product ID, supplier ID, supplier product ID, and product information.

[0346] Here, the Company ID is the identification information that identifies Company B. The Company Product ID is the identification information that identifies Company B's product for which data is registered. The Supplier ID is the identification information that identifies Company C, which orders third-party products used in Company B's products. The Supplier Product ID is the identification information that identifies Company C's product. The Product Information is the data for Company B's product. The Product Information includes, for example, the attributes of Company C's product used in Company B's product. Attributes include, for example, quantity or price.

[0347] (44-7) The CDL infrastructure control unit 910B receives a data registration request. The CDL infrastructure control unit 910B obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910B refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 50.

[0348] Here, the CDL infrastructure control unit 910B determines that the data is new. Since the CDL infrastructure control unit 910B is not at the very bottom of the chain, it extracts the data ID from the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910B obtains the vertical chain ID corresponding to the company's product ID. Since the CDL infrastructure control unit 910B has determined that the data is new, it generates a horizontal chain registration JSON format including the previous data ID and the vertical chain ID, and a vertical chain registration JSON format including the registration data = product information.

[0349] The JSON format for horizontal chain registration is, for example, a combination of a global block containing the previous data ID and a local block containing the vertical chain ID. The JSON format for vertical chain registration is, for example, a combination of a global block and a local block containing the registration data = product information. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated horizontal chain registration JSON format. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated vertical chain registration JSON format.

[0350] (44-8) The CDL infrastructure 920B accepts the registration JSON format for the horizontal chain via the registration API. The CDL infrastructure 920B generates a new data ID and sets it in the accepted registration JSON format for the horizontal chain. The CDL infrastructure 920B calculates the hash values ​​for the global block and the local block from the registration JSON format for the horizontal chain and sets them in the global block. Subsequently, the CDL infrastructure 920B adds the registration JSON format for the horizontal chain as a new block to the horizontal chain. The CDL infrastructure 920B sends a response containing the generated data ID for the block added to the horizontal chain to the CDL infrastructure control unit 910B.

[0351] Similarly, the CDL infrastructure 920B accepts a registration JSON format for the vertical chain via the registration API. The CDL infrastructure 920B generates a new data ID and sets it in the accepted registration JSON format for the vertical chain. The CDL infrastructure 920B calculates the hash values ​​for the global block and the local block from the registration JSON format for the vertical chain and sets them in the global block. Subsequently, the CDL infrastructure 920B adds the registration JSON format for the vertical chain as a new block to the vertical chain. The CDL infrastructure 920B sends a response containing the generated data ID for the block added to the vertical chain to the CDL infrastructure control unit 910B.

[0352] (44-9) The CDL base control unit 910B receives a response containing a data ID for the block added to the horizontal chain. The CDL base control unit 910B receives a response containing a data ID for the block added to the vertical chain. When the CDL base control unit 910B receives both the response containing the data ID for the block added to the horizontal chain and the response containing the data ID for the block added to the vertical chain, it determines that the registration data has been registered in the vertical chain.

[0353] The CDL infrastructure control unit 910B obtains the data ID for the block added to the horizontal chain from the response containing the data ID for the block added to the horizontal chain, since the registration data has been registered in the vertical chain. The CDL infrastructure control unit 910B then sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and the data ID for the block added to the horizontal chain to the subsequent CDL infrastructure control unit 910C.

[0354] (44-10) When the CDL base control unit 910C receives a registration notification from the preceding CDL base control unit 910B, it outputs an alarm to the user of Company C. The user of Company C refers to the alarm and understands that they are using Company C's product with Company B's product.

[0355] (44-11) A user of Company C wishes to register data of Company C's product using Company D's product in Lineage. Based on the user's input, the higher-level application 900C sends a data registration request to the CDL infrastructure control unit 910C, which includes Company ID, Company Product ID, Supplier ID, Supplier Product ID, and product information.

[0356] Here, the Company ID is identification information that identifies Company C. The Company Product ID is identification information that identifies Company C's product for which data is registered. The Supplier ID is identification information that identifies Company D, which orders third-party products used in Company C's products. The Supplier Product ID is identification information that identifies Company D's product. The Product Information is data for Company C's product. The Product Information includes, for example, the attributes of Company D's product used in Company C's product. Attributes include, for example, quantity or price.

[0357] (44-12) The CDL infrastructure control unit 910C receives a data registration request. The CDL infrastructure control unit 910C obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910C refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 50.

[0358] Here, the CDL infrastructure control unit 910C determines that the data is new. Since the CDL infrastructure control unit 910C is not at the very bottom of the chain, it extracts the data ID from the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910C obtains the vertical chain ID corresponding to the company's product ID. Since the CDL infrastructure control unit 910C has determined that the data is new, it generates a horizontal chain registration JSON format including the previous data ID and the vertical chain ID, and a vertical chain registration JSON format including the registration data = product information.

[0359] The JSON format for horizontal chain registration is, for example, a combination of a global block containing the previous data ID and a local block containing the vertical chain ID. The JSON format for vertical chain registration is, for example, a combination of a global block and a local block containing the registration data = product information. The CDL infrastructure control unit 910B executes a registration API to the CDL infrastructure 920B using the generated horizontal chain registration JSON format. The CDL infrastructure control unit 910B executes a registration API to the CDL infrastructure 920B using the generated vertical chain registration JSON format.

[0360] (44-13) The CDL base 920C accepts the registration JSON format for the horizontal chain via the registration API. The CDL base 920C generates a new data ID and sets it in the accepted registration JSON format for the horizontal chain. The CDL base 920C calculates the hash values ​​for the global block and the local block from the registration JSON format for the horizontal chain and sets them in the global block. Subsequently, the CDL base 920C adds the registration JSON format for the horizontal chain as a new block to the horizontal chain. The CDL base 920C sends a response containing the generated data ID for the block added to the horizontal chain to the CDL base control unit 910C.

[0361] Similarly, the CDL infrastructure 920C accepts a registration JSON format for the vertical chain via the registration API. The CDL infrastructure 920C generates a new data ID and sets it in the accepted registration JSON format for the vertical chain. The CDL infrastructure 920C calculates the hash values ​​for the global block and the local block from the registration JSON format for the vertical chain and sets them in the global block. Subsequently, the CDL infrastructure 920C adds the registration JSON format for the vertical chain as a new block to the vertical chain. The CDL infrastructure 920C sends a response containing the generated data ID for the block added to the vertical chain to the CDL infrastructure control unit 910C.

[0362] (44-14) The CDL base control unit 910C receives a response containing a data ID for the block added to the horizontal chain. The CDL base control unit 910C receives a response containing a data ID for the block added to the vertical chain. When the CDL base control unit 910C receives both the response containing the data ID for the block added to the horizontal chain and the response containing the data ID for the block added to the vertical chain, it determines that the registration data has been registered in the vertical chain.

[0363] The CDL infrastructure control unit 910C obtains the data ID for the block added to the horizontal chain from the response containing the data ID for the block added to the horizontal chain, since the registration data has been registered in the vertical chain. The CDL infrastructure control unit 910C then sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and the data ID for the block added to the horizontal chain to the subsequent CDL infrastructure control unit 910D.

[0364] In this way, the information processing system 200 can register new data in Lineage. For example, the information processing system 200 can add new data to the vertical chain of Lineage. The process flow of the CDL base control unit 910 registering new data in Lineage will be described later with reference to Figure 46.

[0365] This section describes the case where the CDL infrastructure control unit 910 registers new data in Lineage, but it is not limited to this case. For example, the CDL infrastructure control unit 910 may also update registered data in Lineage with modified data. The process flow for the CDL infrastructure control unit 910 updating registered data in Lineage with modified data will be described later using Figure 47.

[0366] (In-house registration processing procedure) Next, using Figure 45, an example of a self-registration processing procedure executed by the CDL base control unit 910 will be described. The self-registration processing is realized, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0367] Figure 45 is a flowchart showing an example of the in-house registration processing procedure in the second specific example. In Figure 45, the CDL base control unit 910 receives a data registration request from the in-house higher-level application 900 via an API (step S4501). The data registration request includes the in-house ID, in-house product ID, supplier ID, supplier product ID, and registration data. The registration data includes, for example, product information.

[0368] The CDL base control unit 910 determines whether the registration data specified by the data registration request is new data or not (step S4502). If it is new data (step S4502: Yes), the CDL base control unit 910 proceeds to the process in step S4503. On the other hand, if it is not new data but modified data (step S4502: No), the CDL base control unit 910 proceeds to the process in step S4504.

[0369] In step S4503, the CDL base control unit 910 executes the new registration process described later in Figure 14 (step S4503). Then, the CDL base control unit 910 terminates the in-house registration process.

[0370] In step S4504, the CDL base control unit 910 executes the modification registration process described later in Figure 15 (step S4504). Then, the CDL base control unit 910 terminates the in-house registration process.

[0371] (New registration process procedure) Next, an example of a new registration process procedure executed by the CDL base control unit 910 will be described using Figure 46. The new registration process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0372] Figure 46 is a flowchart showing an example of the new registration processing procedure in the second specific example. In Figure 46, the CDL base control unit 910 determines whether or not its own device is responsible for the downstream process (step S4601). If it is responsible for the downstream process (step S4601: Yes), the CDL base control unit 910 proceeds to the process in step S4603. On the other hand, if it is not responsible for the downstream process (step S4601: No), the CDL base control unit 910 proceeds to the process in step S4602.

[0373] In step S4602, the CDL base control unit 910 obtains the previous data ID from the registration notification received from the previous CDL base control unit 910 for the product ID specified via the API (step S4602). The registration notification includes the company ID, company product ID, supplier ID, supplier product ID, and data ID. The CDL base control unit 910 then proceeds to the processing in step S4603.

[0374] In step S4603, the CDL infrastructure control unit 910 generates a JSON format for the vertical chain using the registration data of the data registration request and the acquired previous data ID (step S4603). Then, the CDL infrastructure control unit 910 executes a registration API for the vertical chain using the JSON format for the vertical chain (step S4604).

[0375] Next, the CDL infrastructure control unit 910 obtains the response to the registration API and obtains the registration data ID = vertical chain ID from the response (step S4605). Next, the CDL infrastructure control unit 910 generates a JSON format for the horizontal chain using the obtained registration data ID and the obtained previous data ID (step S4606). Then, the CDL infrastructure control unit 910 executes the registration API for the horizontal chain using the horizontal chain JSON format (step S4607).

[0376] Next, the CDL infrastructure control unit 910 obtains the response from the registration API, clears the unregistered list, and adds the registration data ID from the response to the registered list (step S4608). Then, the CDL infrastructure control unit 910 generates a registration notification including the company ID, company product ID, supplier ID, supplier product ID, and response data ID, and sends the registration notification to the subsequent CDL infrastructure control unit 910 (step S4609). After that, the CDL infrastructure control unit 910 terminates the new registration process.

[0377] (Procedure for correcting and registering) Next, an example of a modification registration processing procedure executed by the CDL base control unit 910 will be described using Figure 47. The modification registration processing is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0378] Figure 47 is a flowchart showing an example of the modification registration process procedure in the second specific example. In Figure 47, the CDL base control unit 910 refers to the registered list and searches for registered data using the company's product ID of the data registration request as the key, and obtains the vertical chain ID from the searched registered data (step S4701).

[0379] Next, the CDL infrastructure control unit 910 generates a registration JSON format using the acquired vertical chain ID and the registration data from the data registration request (step S4702). Then, the CDL infrastructure control unit 910 executes the registration API for the vertical chain (step S4703). After that, the CDL infrastructure control unit 910 terminates the modification registration process.

[0380] Next, Figures 48 to 50 are explanatory diagrams showing an example of the format in the second specific example. We will now explain an example of various data structures in the second specific example. First, using Figure 48, we will explain an example of the data structure for various notifications, such as data registration notifications and cancellation notifications.

[0381] Figure 48 is an explanatory diagram showing an example of the data structure of various notifications. As shown in Figure 48, notification 4800, which is used as a data registration notification or a cancellation notification, has fields for notification type, recipient organization ID, recipient product ID, source organization ID, source product ID, and previous data ID.

[0382] The Notification Type field contains flag information indicating whether Notification 4800 is a data registration notification or a cancellation notification. For example, a value of 0 indicates a data registration notification, while a value of 1 indicates a cancellation notification.

[0383] The Notification Recipient Organization ID field is set to the Notification Recipient Organization ID that identifies the recipient of Notification 4800. The Notification Recipient Product ID field is set to the Notification Recipient Product ID that identifies the product in the Notification Recipient of Notification 4800. The Notification Recipient Product ID identifies the product in the Notification Recipient of Notification 4800 that corresponds to a block added to Lineage by the Notification Source, for example. The Notification Recipient Product ID identifies the product in the Notification Recipient of Notification 4800 that is to be disabled, for example.

[0384] The Notifying Organization ID field is set to the Notifying Organization ID, which identifies the source of notification 4800. The Notifying Organization ID field may be empty if notification 4800 is a cancellation notification. The Notifying Product ID field is set to the Notifying Product ID, which identifies the product in the source of notification 4800. The Notifying Product ID identifies, for example, the product corresponding to the block added to Lineage in the source of notification 4800. The Notifying Product ID field may be empty if notification 4800 is a cancellation notification.

[0385] The previous data ID field is set to the data ID of the block in the source of notification 4800. The previous data ID is, for example, the data ID of the block added to Lineage in the source of notification 4800. The previous data ID field may be empty if notification 4800 is a cancellation notification. Next, an example of the data structure of the unregistered list 4900 will be explained using Figure 49.

[0386] Figure 49 is an explanatory diagram showing an example of the data structure of the unregistered list 4900. As shown in Figure 49, the unregistered list 4900 has fields for the notified product ID, the notifying organization ID, the notifying product ID, and the previous data ID. The unregistered data management information is stored as a record in the unregistered list 4900 by setting information in each field for each registered data.

[0387] In the "Notification Destination Product ID" field, the ordering destination product ID from the registration notification is set as the notification destination product ID. In the "Notification Source Organization ID" field, the ordering destination product ID from the registration notification is set as the notification destination organization ID. In the "Notification Source Product ID" field, the company's own product ID from the registration notification is set as the notification source product ID. In the "Previous Data ID" field, the data ID from the registration notification is set as the previous data ID. Next, an example of the data structure of registered list 5000 will be explained using Figure 50.

[0388] Figure 50 is an explanatory diagram showing an example of the data structure of Registered List 5000. As shown in Figure 50, Registered List 5000 has fields for Product ID, Data ID, Notifying Organization ID, Notifying Product ID, Previous Data ID, Notifying Organization ID, Notifying Product ID, and Vertical Chain ID. Registered data management information is stored as a record in Registered List 5000 by setting information in each field for each registered data.

[0389] The Product ID field is set to the Product ID corresponding to the registered data. The Data ID field is set to the Data ID set in the block corresponding to the registered data in the horizontal chain. Specifically, the Data ID field is set to the Data ID set in the block corresponding to the vertical chain containing the registered data in the horizontal chain. The Notifying Organization ID field is set to the company ID of the registration notification referenced when registering the registered data. The Notifying Product ID field is set to the company product ID of the registration notification referenced when registering the registered data.

[0390] The field for "Previous Data ID" is set to the data ID of the block managed by the preceding CDL infrastructure control unit 910, which is the notification source, and which is linked one block before the block of the above data ID. The field for "Notification Destination Organization ID" is set to the ordering party ID of the registration notification as the notification destination organization ID. The field for "Notification Destination Product ID" is set to the ordering party product ID of the registration notification as the notification destination product ID.

[0391] The Vertical Chain ID field is set with identification information that identifies the vertical chain containing the registered data. If there are multiple different records with the same Vertical Chain ID, the registered data corresponding to all but the oldest record among those multiple records corresponds to the duplicated data.

[0392] Next, using Figure 51, an example of how the information processing system 200 forms a lineage representing a merge will be described. Specifically, the CDL base control unit 910 will control the lineage by adding block duplicates to it in order to represent a merge.

[0393] Figure 51 is an explanatory diagram illustrating an example of forming a lineage representing a merger. In Figure 51, (51-1) suppose a user of Company A wishes to register data for Company A's product A2, which uses Company B's product B1, into the lineage. Let's assume that Company B's product B1 is also used in Company A's product A1. Therefore, it is desirable to form a lineage representing a merger. Based on the user's input from Company A, the higher-level application 900A sends a data registration request to the CDL base control unit 910A, which includes Company ID, Company product ID, supplier ID, supplier product ID, and product information.

[0394] (51-2) The CDL infrastructure control unit 910A receives a data registration request. The CDL infrastructure control unit 910A obtains the company ID, company product ID, supplier ID, supplier product ID, and product information from the data registration request. The CDL infrastructure control unit 910A refers to a registered list that makes it possible to identify registered data and determines whether the registration data = product information that is the target of the data registration request is new data to be registered for the first time, or modification data that modifies registered data. An example of the registered list will be described later with reference to Figure 38.

[0395] Here, the CDL infrastructure control unit 910A determines that the data is new. Since the CDL infrastructure control unit 910A is at the bottom of the chain, it sets the previous data ID to empty. The CDL infrastructure control unit 910A obtains the vertical chain ID corresponding to the company's product ID. Since the CDL infrastructure control unit 910A has determined that the data is new, it generates a horizontal chain registration JSON format including the previous data ID = empty and the vertical chain ID, and a vertical chain registration JSON format including the registration data = product information.

[0396] The JSON format for horizontal chain registration is, for example, a combination of a global block containing the previous data ID = empty and a local block containing the vertical chain ID. The JSON format for vertical chain registration is, for example, a combination of a global block and a local block containing the registration data = product information. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated horizontal chain registration JSON format. The CDL infrastructure control unit 910A executes a registration API to the CDL infrastructure 920A using the generated vertical chain registration JSON format.

[0397] (51-3) The CDL infrastructure 920A accepts the registration JSON format for the horizontal chain via the registration API. The CDL infrastructure 920A generates a new data ID and sets it in the accepted registration JSON format for the horizontal chain. The CDL infrastructure 920A calculates the hash values ​​for the global block and the local block from the registration JSON format for the horizontal chain and sets them in the global block. Subsequently, the CDL infrastructure 920A adds the registration JSON format for the horizontal chain as a new block to the horizontal chain. The CDL infrastructure 920A sends a response to the CDL infrastructure control unit 910A that includes the generated data ID for the block added to the horizontal chain.

[0398] (51-4) The CDL base control unit 910A receives a response containing a data ID for the block added to the horizontal chain. The CDL base control unit 910A receives a response containing a data ID for the block added to the vertical chain. When the CDL base control unit 910A receives both the response containing the data ID for the block added to the horizontal chain and the response containing the data ID for the block added to the vertical chain, it determines that the registration data has been registered in the vertical chain.

[0399] The CDL infrastructure control unit 910A obtains the data ID for the block added to the horizontal chain from the response containing the data ID for the block added to the horizontal chain, since the registration data has been registered in the vertical chain. The CDL infrastructure control unit 910A sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and the data ID for the block added to the horizontal chain to the subsequent CDL infrastructure control unit 910B.

[0400] (51-5) The CDL infrastructure control unit 910B receives a registration notification from the preceding CDL infrastructure control unit 910A. The registration notification includes the company ID, the company product ID, the supplier ID, the supplier product ID, and the data ID related to the block added to the horizontal chain. The CDL infrastructure control unit 910B uses the supplier product ID from the registration notification as a key to search the registered list for a product ID that matches the supplier product ID from the registration notification.

[0401] Here, the CDL infrastructure control unit 910B outputs an alarm to B company's users if it does not find a product ID that matches the supplier product ID in the registration notification. On the other hand, if the CDL infrastructure control unit 910B finds a product ID that matches the supplier product ID in the registration notification, it determines to generate a copy of the existing block to indicate a merger and continues processing without outputting an alarm to B company's users. Here, let's assume that the CDL infrastructure control unit 910B has found a product ID that matches the supplier product ID in the registration notification.

[0402] (51-6) The CDL infrastructure control unit 910B reads and retrieves the source data ID, company product ID, supplier ID, and supplier product ID from the registered list using the discovered product ID as the key. The source data ID is the data ID corresponding to the discovered product ID. The company product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910B retrieves the company ID.

[0403] (51-7) Since the CDL infrastructure control unit 910B is not at the bottom of the chain, it extracts the data ID of the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910B generates a horizontal chain registration JSON format that includes a global block containing the set previous data ID = registration notification data ID, and a copy of the local block associated with the copy source data ID block. The copy of the local block includes the vertical chain ID. The CDL infrastructure control unit 910B uses the generated horizontal chain registration JSON format to execute the registration API on the CDL infrastructure 920B.

[0404] (51-8) The CDL platform 920B accepts a JSON format for horizontal chain registration via the registration API. The CDL platform 920B generates a new data ID and sets it in the accepted registration JSON format. The CDL platform 920B calculates the hash values ​​for the global block and the local block from the horizontal chain registration JSON format and sets them in the global block.

[0405] Subsequently, the CDL base 920B adds the JSON format for registering the horizontal chain to the lineage. In this way, the CDL base 920B enables different blocks of the horizontal chain to share the vertical chain. The CDL base 920B sends a response containing the generated data ID to the CDL base control unit 910B.

[0406] (51-9) When the CDL infrastructure control unit 910B receives a response containing a data ID, it determines that a merge has been represented in Lineage. The CDL infrastructure control unit 910B obtains the data ID included in the response. The CDL infrastructure control unit 910B sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910C.

[0407] (51-10) The CDL infrastructure control unit 910C receives a registration notification from the preceding CDL infrastructure control unit 910B. The registration notification includes the company ID, the company product ID, the supplier ID, the supplier product ID, and the data ID related to the block added to the horizontal chain. The CDL infrastructure control unit 910C uses the supplier product ID from the registration notification as a key to search the registered list for a product ID that matches the supplier product ID from the registration notification.

[0408] Here, the CDL infrastructure control unit 910C outputs an alarm to the user of Company C if it does not find a product ID that matches the supplier product ID in the registration notification. On the other hand, if the CDL infrastructure control unit 910C finds a product ID that matches the supplier product ID in the registration notification, it determines to generate a copy of the existing block to indicate a merger and continues processing without outputting an alarm to the user of Company C. Here, let's assume that the CDL infrastructure control unit 910C has found a product ID that matches the supplier product ID in the registration notification.

[0409] (51-11) The CDL infrastructure control unit 910C reads and retrieves the source data ID, company product ID, supplier ID, and supplier product ID from the registered list using the discovered product ID as the key. The source data ID is the data ID corresponding to the discovered product ID. The company product ID is the discovered product ID. The supplier ID is the notification recipient organization ID corresponding to the discovered product ID. The supplier product ID is the notification recipient product ID corresponding to the discovered product ID. The CDL infrastructure control unit 910C retrieves the company ID.

[0410] (51-12) Since the CDL infrastructure control unit 910C is not at the bottom of the chain, it extracts the data ID of the registration notification and obtains it as the previous data ID. The CDL infrastructure control unit 910C generates a horizontal chain registration JSON format that includes a global block containing the set previous data ID = registration notification data ID, and a copy of the local block associated with the block of the source data ID. The copy of the local block includes the vertical chain ID. The CDL infrastructure control unit 910C uses the generated horizontal chain registration JSON format to execute the registration API to the CDL infrastructure 920C.

[0411] (51-13) The CDL infrastructure 920C accepts a JSON format for horizontal chain registration via the registration API. The CDL infrastructure 920C generates a new data ID and sets it in the accepted registration JSON format. The CDL infrastructure 920C calculates the hash values ​​for the global block and the local block from the horizontal chain registration JSON format and sets them in the global block.

[0412] Subsequently, the CDL base 920C adds the JSON format for registering the horizontal chain to the lineage. In this way, the CDL base 920C enables different blocks of the horizontal chain to share the vertical chain. The CDL base 920C sends a response containing the generated data ID to the CDL base control unit 910C.

[0413] (51-14) When the CDL infrastructure control unit 910C receives a response containing a data ID, it determines that a merge has been represented in Lineage. The CDL infrastructure control unit 910C obtains the data ID included in the response. The CDL infrastructure control unit 910C sends a registration notification containing the obtained company ID, company product ID, supplier ID, supplier product ID, and data ID to the subsequent CDL infrastructure control unit 910D (not shown).

[0414] Thus, the information processing system 200 can simulate branch merging even when it is difficult to directly represent it in Lineage. Therefore, the information processing system 200 can flexibly update the CDL. The information processing system 200 can represent branch merging without issuing alarms to users of company B and company C. Therefore, the information processing system 200 can reduce the workload on users.

[0415] (Procedure for registering copies) Next, an example of a replication registration process procedure performed by the CDL base control unit 910 will be described using Figure 52. The replication registration process is implemented, for example, by the CPU 701 shown in Figure 7, storage areas such as memory 702 and recording medium 705, and network I / F 703.

[0416] Figure 52 is a flowchart illustrating an example of the replication registration process procedure in the first specific example. In Figure 52, the CDL base control unit 910 receives a registration notification from the preceding CDL base control unit 910 (step S5201). The registration notification includes the company ID, company product ID, supplier ID, supplier product ID, and data ID.

[0417] Next, the CDL base control unit 910 refers to the registered list and determines whether the data ID of the registration notification is already registered (step S5202). If it is not already registered (step S5202: No), the CDL base control unit 910 proceeds to the process in step S5203. On the other hand, if it is already registered (step S5202: Yes), the CDL base control unit 910 proceeds to the process in step S5204.

[0418] In step S5203, the CDL infrastructure control unit 910 records the data ID of the registration notification in the unregistered list (step S5203). The CDL infrastructure control unit 910 records and manages, for example, the company ID, company product ID, and data ID of the registration notification in the unregistered list. Then, the CDL infrastructure control unit 910 terminates the replication registration process.

[0419] In step S5204, the CDL infrastructure control unit 910 obtains the notification destination organization ID, notification destination product ID, and vertical chain ID of the registered product ID from the registered list (step S5204).

[0420] Next, the CDL infrastructure control unit 910 duplicates the local portion of the horizontal chain and generates a JSON format for registration of the horizontal chain (step S5205). Then, the CDL infrastructure control unit 910 executes a registration API for the horizontal chain using the JSON format for registration of the horizontal chain (step S5206).

[0421] Next, the CDL infrastructure control unit 910 obtains the response from the registration API, clears the unregistered list, and adds the response data ID to the registered list (step S5207). Then, the CDL infrastructure control unit 910 generates a registration notification including the company ID, company product ID, supplier ID, supplier product ID, and response data ID, and sends the registration notification to the subsequent CDL infrastructure control unit 910 (step S5208). After that, the CDL infrastructure control unit 910 terminates the replication process.

[0422] As explained above, the information processing device 100 can receive a first request to newly link a second block before the first block managed by the device, among a group of blocks. When the information processing device 100 receives the first request, it can control multiple blocks to add a copy of the first block to the multiple blocks and link it after the second block. This allows the information processing device 100 to flexibly update multiple blocks. Even when it is difficult to directly link another block directly before a block, the information processing device 100 can pseudo-link another block directly before a block.

[0423] According to the information processing device 100, upon receiving a first request, it can control multiple blocks to add a copy of the first block, including a copy flag indicating that it is a copy of the first block, to multiple blocks and link it after the second block. This allows the information processing device 100 to distinguish between the first block and its copy. The information processing device 100 can also display the first block and its copy in a way that allows the user to distinguish between them.

[0424] According to the information processing device 100, it can receive a request to display all or part of multiple blocks. According to the information processing device 100, when a display request is received, it can identify a copy of the first block based on a copy flag when displaying all or part of the multiple blocks. According to the information processing device 100, it can display the copy of the first block as the original first block, or display it in a way that makes it possible to determine its correspondence with the original first block. As a result, the information processing device 100 can display the first block and its copy in a way that allows the user to intuitively distinguish between them.

[0425] According to the information processing device 100, a first request can be received to link a second block, which is included in multiple blocks, before the first block. This allows the information processing device 100 to link an existing second block before an existing first block.

[0426] According to the information processing device 100, it is possible to generate a second block and control multiple blocks so as to add the generated second block to multiple other blocks. This allows the information processing device 100 to concatenate a new second block in front of an existing first block.

[0427] According to the information processing device 100, it can receive a second request to invalidate a third block managed by the device, among several blocks. According to the information processing device 100, upon receiving the second request, it can control multiple blocks to add a fourth block indicating the invalidation of the third block and link it after the third block. In this way, the information processing device 100 can indicate that a block has been invalidated even when it is difficult to directly delete the block.

[0428] According to the information processing device 100, it can receive requests to display all or part of multiple blocks. According to the information processing device 100, when a display request is received, it can identify the third block based on the fourth block when displaying all or part of the multiple blocks. According to the information processing device 100, the third block can be excluded from the display target or displayed in a display mode corresponding to its invalidation. This allows the information processing device 100 to make it possible for users to intuitively understand that a block has been disabled.

[0429] According to the information processing device 100, multiple blocks can be implemented using a hash chain. This allows the information processing device 100 to ensure the tamper-proof nature of the multiple blocks.

[0430] According to the information processing device 100, multiple blocks can be controlled to connect copies of associated blocks, which are connected to the first block and contain related data related to the data in the first block, to the copies of the first block. This allows the information processing device 100 to properly replicate the related data.

[0431] According to the information processing device 100, multiple blocks can be controlled to connect copies of associated blocks, which are connected to the first block and contain identifiers for related data associated with the data in the first block, to the copies of the first block. This allows the information processing device 100 to suppress an increase in memory usage for storing the related data.

[0432] According to the information processing device 100, it can receive a request to invalidate a first block managed by itself, from among a plurality of blocks, each of which is formed to include identifiers of other blocks linked before and after it. According to the information processing device 100, upon receiving a request, it can control the plurality of blocks to add a second block indicating that the first block is to be invalidated, and link it after the first block. This allows the information processing device 100 to flexibly update the plurality of blocks. The information processing device 100 can also express that a block has been invalidated, even when it is difficult to directly delete the block.

[0433] The information processing method described in this embodiment can be implemented by executing a pre-prepared program on a computer such as a PC or workstation. The information processing program described in this embodiment is recorded on a computer-readable recording medium and executed by being read from the recording medium by the computer. The recording medium can be a hard disk, flexible disk, CD (Compact Disc)-ROM, MO (Magneto Optical Disc), DVD (Digital Versatile Disc), etc. Furthermore, the information processing program described in this embodiment may be distributed via a network such as the Internet.

[0434] With regard to the embodiments described above, the following additional information is disclosed.

[0435] (Note 1) Among a plurality of blocks formed such that each block includes identifiers of other blocks that are linked before and after the block, the device receives a first request to newly link a second block before the first block managed by the device. When the first request is received, the system controls the plurality of blocks to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing program characterized by having a computer perform the processing.

[0436] (Note 2) The control process described above is: The information processing program according to Appendix 1, characterized in that, upon receiving the first request, it controls the plurality of blocks to add a copy of the first block, including a copy flag indicating that it is a copy of the first block, to the plurality of blocks and concatenate it after the second block.

[0437] (Note 3) We accept requests to display all or part of the above-mentioned blocks. When the aforementioned display request is received, in displaying all or part of the multiple blocks, the duplicate of the first block is identified based on the duplicate flag, and it is displayed as the original first block, or the correspondence with the original first block is displayed in a way that can be determined. The information processing program described in Appendix 2, characterized in that it causes the computer to perform the processing.

[0438] (Appendix 4) The information processing program according to any one of Appendix 1 to 3, characterized in that the second block is a block included in the plurality of blocks.

[0439] (Note 5) Generate the second block and control the plurality of blocks so as to add the generated second block to the plurality of blocks. An information processing program according to any one of the appendices 1 to 3, characterized in that it causes the computer to perform the processing.

[0440] (Note 6) Upon receiving a second request to disable the third block managed by the device among the aforementioned multiple blocks, If the second request is received, the plurality of blocks are controlled to add a fourth block indicating that the third block should be invalidated, and to link it after the third block. An information processing program according to any one of the appendices 1 to 3, characterized in that it causes the computer to perform the processing.

[0441] (Note 7) We accept requests to display all or part of the above-mentioned blocks. When the aforementioned display request is received, in displaying all or part of the aforementioned multiple blocks, the third block is identified based on the fourth block and either excluded from the display target or displayed in a display manner corresponding to invalidation. The information processing program described in Appendix 6, characterized in that it causes the computer to perform the processing.

[0442] (Note 8) The information processing program according to any one of Notes 1 to 3, characterized in that the plurality of blocks are a hash chain.

[0443] (Note 9) Each of the aforementioned blocks is connected to an associated block containing related data related to the data of that block. The control process described above is: An information processing program according to any one of the appendices 1 to 3, characterized in that, upon receiving the first request, it adds a copy of the first block to the plurality of blocks and links it after the second block, and controls the plurality of blocks so that copies of the associated blocks connected to the first block are connected to the copies of the first block.

[0444] (Note 10) Each of the aforementioned blocks is connected to an associated block containing an identifier for related data associated with the data of that block. The control process described above is: An information processing program according to any one of the appendices 1 to 3, characterized in that, upon receiving the first request, it adds a copy of the first block to the plurality of blocks and links it after the second block, and controls the plurality of blocks so that copies of the associated blocks connected to the first block are connected to the copies of the first block.

[0445] (Note 11) Among a plurality of blocks formed such that each block includes identifiers of other blocks that are linked before and after the block, the device receives a first request to newly link a second block before the first block managed by the device. When the first request is received, the system controls the plurality of blocks to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing method characterized in that the processing is performed by a computer.

[0446] (Note 12) Among a plurality of blocks formed such that each block includes identifiers of other blocks that are linked before and after the block, the device receives a first request to newly link a second block before the first block managed by the device. When the first request is received, the system controls the plurality of blocks to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing device characterized by having a control unit.

[0447] (Note 13) Among a plurality of blocks formed such that each block includes identifiers of other blocks linked before and after the block, the device accepts a request to invalidate the first block managed by the device. If the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to link it after the first block. An information processing program characterized by having a computer perform the processing.

[0448] (Note 14) Among a plurality of blocks formed such that each block includes identifiers of other blocks linked before and after the block, the device accepts a request to invalidate the first block managed by the device. If the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to link it after the first block. An information processing method characterized in that the processing is performed by a computer.

[0449] (Note 15) Among a plurality of blocks formed such that each block includes identifiers of other blocks linked before and after the block, the device accepts a request to invalidate the first block managed by the device. If the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to link it after the first block. An information processing device characterized by having a control unit. [Explanation of Symbols]

[0450] 100 Information Processing Devices 101~103,1000,1010,1100,1111 Sign 200 Information Processing Systems 201 Lineage Management Device 202 Client Devices 210 Network 300 CDL Blocks 301, 302, 2101, 2102, 2701, 4200, 4201, 4300, 4301 303 Data ID 304,305 ID 306,307 hash values 501 Header 502 Events 503 tags 504 Verification 505 Digital Signatures 700 bus 701 CPU 702 memory 703 Network Interface 704 Recording medium interface 705 Recording media 800 Storage section 801 Acquisition Department 802 Update Department 803 Output section Top 900 Applications 901 GUI 910 CDL Base Control Unit 911 Notification Detection Unit 912 Lineage Control Department 913 Lineage Visualization Team 914 Registration Notification Generation Unit 920 CDL base 921 History Registration Section 922 History Search Section 923 Lineage Acquisition Section 924 Policy Settings Section 1600, 1800, 2300, 2400, 3100, 3200 Lineage 1700, 1900, 2500 Lineage Management Table 2100,2700 Registration JSON format 3101, 3201~3204, 3300B, 3300C Disable Management Table 3600,4800 notifications 3700,4900 Unregistered List 3800,5000 list 4000 horizontal chain 4100 Vertical Chain

Claims

1. Among a plurality of blocks formed such that each block contains identifiers of other blocks connected before and after it, the device receives a first request to newly connect a second block before the first block managed by the device. When the first request is received, the plurality of blocks are controlled to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing program characterized by having a computer perform the processing.

2. The control process described above is: The information processing program according to claim 1, characterized in that, upon receiving the first request, it controls the plurality of blocks to add a copy of the first block, including a copy flag indicating that it is a copy of the first block, to the plurality of blocks and concatenate it after the second block.

3. We accept requests to display all or part of the aforementioned multiple blocks. When the aforementioned display request is received, in displaying all or part of the multiple blocks, the duplicate of the first block is identified based on the duplicate flag, and it is displayed as the original first block, or the correspondence with the original first block is displayed in a way that can be determined. The information processing program according to claim 2, characterized in that it causes the computer to perform the processing.

4. Upon receiving a second request to disable the third block managed by the device, among the aforementioned multiple blocks, If the second request is received, the plurality of blocks are controlled to add a fourth block indicating that the third block should be invalidated, and to link it after the third block. An information processing program according to any one of claims 1 to 3, characterized in that it causes the computer to perform the processing.

5. We accept requests to display all or part of the aforementioned multiple blocks. When the aforementioned display request is received, in displaying all or part of the multiple blocks, the third block is identified based on the fourth block and either excluded from the display target or displayed in a display manner corresponding to invalidation. The information processing program according to claim 4, characterized in that it causes the computer to perform the processing.

6. Each of the aforementioned blocks is connected to an associated block containing related data related to the data of that block. The control process described above is: The information processing program according to any one of claims 1 to 3, characterized in that, upon receiving the first request, it adds a copy of the first block to the plurality of blocks and connects it after the second block, and controls the plurality of blocks so that copies of the associated blocks connected to the first block are connected to the copies of the first block.

7. Each of the aforementioned blocks is connected to an associated block containing an identifier for related data associated with the data of that block. The control process described above is: The information processing program according to any one of claims 1 to 3, characterized in that, upon receiving the first request, it adds a copy of the first block to the plurality of blocks and connects it after the second block, and controls the plurality of blocks so that copies of the associated blocks connected to the first block are connected to the copies of the first block.

8. Among a plurality of blocks formed such that each block contains identifiers of other blocks connected before and after it, the device receives a first request to newly connect a second block before the first block managed by the device. When the first request is received, the plurality of blocks are controlled to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing method characterized in that the processing is performed by a computer.

9. Among a plurality of blocks formed such that each block contains identifiers of other blocks connected before and after it, the device receives a first request to newly connect a second block before the first block managed by the device. When the first request is received, the plurality of blocks are controlled to add a copy of the first block to the plurality of blocks and link it after the second block. An information processing device characterized by having a control unit.

10. Among a plurality of blocks formed such that each block contains identifiers of other blocks linked before and after it, the device accepts a request to invalidate the first block managed by the device itself. When the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to be linked after the first block. An information processing program characterized by having a computer perform the processing.

11. Among a plurality of blocks formed such that each block contains identifiers of other blocks linked before and after it, the device accepts a request to invalidate the first block managed by the device itself. When the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to be linked after the first block. An information processing method characterized in that the processing is performed by a computer.

12. Among a plurality of blocks formed such that each block contains identifiers of other blocks linked before and after it, the device accepts a request to invalidate the first block managed by the device itself. When the aforementioned request is received, the plurality of blocks are controlled to add a second block indicating that the first block is to be invalidated, and to be linked after the first block. An information processing device characterized by having a control unit.

Images