Transfer Management System, Transfer Management Method, and Program

Abstract

To provide a technique for managing, on a blockchain, transfer of possession of an article using cross-referenced data having a hierarchical structure.SOLUTION: A transfer management system for managing transfer of possession of an article includes a blockchain in which cross-referenced tokens having a parent-child relationship are recorded, the tokens including a child token associated with the article and a parent token associated with a management unit for transfer of possession of one or more articles, and includes a transaction issuing section which is configured to issue, to the blockchain, a transaction for implementing management of transfer of possession of the article.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to a transfer management system, a transfer management method, and program to the muscle .

Background Art

[0002] In recent years, in the field of the supply chain, the importance of sharing the possession transfer history among stakeholders has been recognized for the purpose of ensuring traceability in the event of a defect in an article such as a product or a commodity. The possession transfer history is, for example, a record of what, when, and from where to where something has moved in a certain unit (that is, a record of when each article has been transferred from which possessor to which possessor in a certain unit).

[0003] For example, as one of the prior arts, Patent Document 1 describes realizing a traceability system for resource objects by means of a blockchain composed of a plurality of nodes.

[0004] By the way, pallets, containers, etc. are often used when transporting articles. At this time, for example, when an article is being transported using a pallet, a parent-child relationship with the article as the child and the pallet as the parent can be considered. Similarly, when an article is being transported using a container, a parent-child relationship with the article as the child and the container as the parent can be considered. Therefore, it is necessary that the information for managing the possession transfer of articles, pallets, containers, etc. also has a parent-child relationship and that it can be mutually referable between the parent and the child.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, conventionally, it has not been possible to manage the transfer of possession on a blockchain that has a parent-child relationship (i.e., a hierarchical structure) and allows mutual reference between the parent and the child with information related to the transfer of possession.

[0007] The present disclosure has been made in view of the above points, and an object thereof is to provide a technique for managing the transfer of possession of an article on a blockchain with data having a hierarchically-structured relationship that allows mutual reference.

Means for Solving the Problems

[0008] A transfer management system according to an aspect of the present disclosure is a transfer management system for managing the transfer of possession of an object, including a blockchain in which tokens associated with the object are recorded as children and tokens associated with a management unit in the case of performing the transfer of possession of one or more objects are recorded as parents, having a parent-child relationship that allows mutual reference, and a transaction issuing unit configured to issue a transaction for realizing the management of the transfer of possession of the object to the blockchain.

Advantages of the Invention

[0009] A technique for managing the transfer of possession of an article on a blockchain with data having a hierarchically-structured relationship that allows mutual reference is provided.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Modes for Carrying Out the Invention

[0011] Hereinafter, an embodiment of the present invention will be described.

[0012] [First Embodiment] First, the first embodiment will be described.

[0013] <Occupant> An occupant is a natural person, a legal person, or a space or other object under their control and management that temporarily or non-temporarily controls and manages a physical object (a tangible thing) or a service (an intangible thing such as a license or electronic content). It should be noted that in this embodiment, a space or the like that temporarily or non-temporarily controls and manages a product is also included in the occupant.

[0014] Specific examples of an occupant include, for example, a transport vehicle such as a truck that can transport goods by means of a loading platform or the like, a train that can transport goods, a warehouse or factory that can store goods, a store that sells goods, etc. Note that a single truck, a single train, a single warehouse, a single store, etc. may include a plurality of occupants. For example, when there are a plurality of rooms in a warehouse, each room may be regarded as one occupant, or a predetermined two or more rooms may be regarded as one occupant. Similarly, when there are a plurality of floors in a warehouse, each floor may be regarded as one occupant, or a predetermined two or more floors may be regarded as one occupant. The same applies when a transport vehicle has a plurality of loading platforms or when a train is composed of a plurality of vehicles.

[0015] <Transportation of Goods in Logistics> When transporting goods such as products or merchandise in logistics, it is common to store them in containers in units of cases containing a plurality of products and transport them, or load them on pallets and transport them. For example, as shown in FIG. 1, a case containing goods shipped from a manufacturer is stored in a container and transported to a logistics base such as Warehouse A in units of containers. Thereafter, at Warehouse A, the cases are reloaded onto pallets according to the destination and transported to a logistics base such as Warehouse B in units of pallets. At Warehouse B, for example, the cases on the pallet are further reloaded according to the destination and transported to a logistics base such as Warehouse C in units of pallets. Then, at Logistics Base C, the cases on the pallet are transported to the store in units of cases.

[0016] Thus, when transporting goods in logistics, cases are stored in relatively large-capacity containers or the like and shipped. After that, at intermediate logistics bases, they are loaded onto pallets according to the destination, or the cases are transferred between pallets, and finally, they are generally transported to stores in case units. Therefore, while transporting goods in container or pallet units, the number of transactions can be suppressed by recording the transfer of possession in container or pallet units instead of case units. That is, while transporting goods in container or pallet units, the number of transactions can be suppressed by managing the transfer of possession in those units. Hereinafter, a plurality of goods such as containers and pallets are collectively transported or managed, and the object in which the transfer of possession is performed in container or pallet units is also referred to as a "management unit".

[0017] Here, since a plurality of cases are stored in a container, it can be said that there is a parent-child relationship between the container and the cases. Similarly, since a plurality of cases are placed on a pallet, it can be said that there is a parent-child relationship between the pallet and the cases. Also, since a plurality of pallets may be stored in a container, there may be a parent-child relationship between the container and the pallet and between the pallet and the cases respectively. That is, there is a parent-child relationship between the object transported in logistics and the transport containers such as containers and pallets used for the transport, with the transport container as the parent and the object stored in the transport container as the child. Also, when one transport container is included in another transport container among the transport containers, there is a parent-child relationship.

[0018] Therefore, more generally, when recording the transfer of possession of a certain object, if there is a parent for that object, the number of transactions can be suppressed by recording the transfer of possession in the unit of the topmost parent (that is, the parent located at the topmost position when tracing the parent of the object).

[0019] <Prior art capable of managing parent-child relationship and transfer of possession on blockchain> As an existing technology that can manage parent-child relationships and the transfer of possession of items on a blockchain (hereinafter also referred to as BC), there is a standard called ERC (Ethereum Request for Comments) 998. ERC998 is a standard for tokens that hierarchically organize non-fungible tokens (NFTs) defined in ERC721 and can collectively change owners. Using this standard, for example, by associating non-fungible tokens with items, transport containers, etc. through RFID (Radio Frequency Identification) tags, QR codes (registered trademarks), etc., the transfer of possession of these can be managed on the BC. However, in ERC998, it is not possible to mutually reference between a parent and a child, and it is necessary to issue a transaction every time the parent-child relationship is associated or disassembled, which may require a large number of transactions.

[0020] Therefore, for example, as shown in FIG. 2, when manufacturer A stores 4 cases in 1 container, a total of 4 transactions are required to create a parent-child relationship where the container token is the parent and the case tokens are the children. The same applies to manufacturer B.

[0021] Similarly, for example, as shown in FIG. 2, when 4 cases are taken out of a container at a central warehouse, a total of 4 transactions are required to disassociate the parent-child relationship where the container token is the parent and the case tokens are the children.

[0022] Also, for example, as shown in FIG. 2, when transporting a container or a pallet from a central warehouse to a regional warehouse, even if they have the same destination, it is necessary to issue a transaction for transferring the possession of the container token and a transaction for transferring the possession of the pallet token respectively.

[0023] In this way, in ERC998, a parent-child relationship is established between the token of an object such as a case of an item and the token of the transport container used for its transport, and the transfer of possession of the child tokens can be collectively performed in units of the parent token. On the other hand, the parent token and the child tokens cannot refer to each other, and when associating and disassociating the parent-child relationship, a transaction needs to be issued for each child token. Furthermore, even when multiple parent tokens are transferred in possession to the same possessor, a transaction needs to be issued for the transfer of possession of each of these parent tokens. Therefore, it cannot be said that the suppression of the number of transactions issued is sufficient. For example, at a logistics base where a large amount of goods come and go, the load associated with the transfer of possession is still considered to be high. Also, in ERC998, the parent token and the child tokens cannot refer to each other, and the child tokens cannot refer to the parent token. Therefore, for example, when confirming information regarding the transfer of possession of an item, it is not possible to identify the container that transported the item. Thus, below, a method that enables mutual reference between a parent and a child and can further suppress the number of transactions issued will be proposed.

[0024] Note that the method proposed below does not conform to the ERC721 and ERC998 standards. However, it should be noted that for blockchains (BCs) aimed at ensuring logistics traceability, they are generally constructed as consortium networks or private networks of multiple companies. Therefore, in the case of BCs aimed at ensuring logistics traceability, there are no inconveniences regarding non-compliance with the ERC721 and ERC998 standards.

[0025] <Proposed Method> When using this proposed method, it is possible to easily confirm information (such as information regarding the transfer of possession) of another item that has a parent-child relationship with a certain item. Also, for example, as shown in Figure 3, when Manufacturer A stores four cases in one container, the association of the parent-child relationship with the container token as the parent and the case tokens as the children can be performed in one transaction. The same applies to Manufacturer B.

[0026] Similarly, for example, as shown in FIG. 3, when taking out four cases from a container in the central warehouse, the association between the token of the container as the parent and the tokens of the cases as the children can be released in one transaction.

[0027] Also, for example, as shown in FIG. 3, when transporting containers or pallets from the central warehouse to the regional warehouse, if the destination is the same, multiple transfers of possession can be carried out in one transaction.

[0028] Define a data structure for tokens and a contract method (hereinafter also simply referred to as "method") that realizes transactions to realize the above-mentioned association / disassociation of parent-child relationships and transfer of possession.

[0029] <<Data Structure of Tokens>> Hereinafter, for example, define a data structure of tokens associated with articles, cases containing one or more articles, transport containers, etc. Hereinafter, the article itself, cases containing one or more articles, etc. will be collectively referred to as "articles". In addition, tokens and real existing articles and transport containers can be associated with each other by a token ID described later, for example, using an ID (identifier) for managing real existing articles and transport containers, an RFID tag, a QR code, etc. attached to real existing articles and transport containers. Also, for example, when the object to be managed for transfer of possession is an intangible object such as a license or electronic content, it can be associated with a token ID described later using an ID (identifier) given to the object.

[0030] A token is a collection of properties (attributes) that can be uniquely identified by a token ID, and has properties of "token ID", "parent token ID", "list of child token IDs", "list of transfer permission destinations", and "token type". That is, a token is represented in the following data format.

[0031] {Token ID, Parent Token ID, Owner, List of Child Token IDs, List of Transfer Permitted Destinations, Token Type} Here, in the Token ID property, an ID (Token ID) that uniquely identifies the token is set. In the Parent Token ID property, if there is a parent token for the token, the Token ID of the parent token is set, and if there is no parent token, an empty string (for example, "", NULL, etc.) is set. In the Owner property, if there is a parent token for the token, 0 is set, and if there is no parent token, the BC address of the owner of the token is set. In the List of Child Token IDs property, if there are child tokens for the token, a list (array) of the Token IDs of the child tokens is set, and if there are no child tokens, an empty array is set. In the List of Transfer Permitted Destinations property, a list of BC addresses that the current owner of the token has permitted as transfer destinations (however, if there is no BC address permitted by the current owner as a transfer destination, an empty array) is set. In the Token Type property, information (0 or 1) indicating the token type is set. Note that the token may be provided with a Meta Information property in which meta information supplementing its properties is set. Note that in addition to these properties, the token may have various properties.

[0032] ·Regarding the parent - child relationship The parent - child relationship is expressed by the Parent Token ID property and the List of Child Token IDs property of the token. As an example, the parent - child relationship of the token is shown in Figure 4. Note that in the example shown in Figure 4, only some properties (Token ID, Owner, Parent Token ID, and List of Child Token IDs) are illustrated for simplicity.

[0033] As shown in Figure 4, the token in the proposed method has a Parent Token ID property and a List of Child Token IDs property, and can represent a two - way association of the parent - child relationship (that is, it is possible to mutually reference between the parent token and the child token).

[0034] ·Regarding the owner In the token possessor property, the BC address of the possessor is set only when there is no parent, and 0 is set when there is a parent. The possessor property of a token that has a parent token can be obtained as the possessor property of the topmost parent token by following the parent token ID property of that token.

[0035] ·Regarding possession transfer Possession transfer is carried out in units of the topmost parent token (that is, token units representing a certain management unit), and the child tokens associated with that parent token are not changed. For example, in the example shown in Figure 4, possession transfer is performed in the token unit of token ID "T01", and its child tokens (token IDs "T02", "T03", "T04", "T05") are not changed. That is, even when the possession of the parent token is transferred, the possessor property of its child tokens remains set to "0". This is because the possessor of the child token is also represented by the possessor property of the parent token.

[0036] ·Regarding token types There are package tokens and item tokens as token types. Assume that if "0" is set in the token type property, it is a package token, and if "1" is set, it is an item token.

[0037] An item token is a token associated with an object to be tracked for transfer of possession (such as an article, etc.). On the other hand, a package token is a token associated with an administrative unit such as a transport container (e.g., a container, a pallet, etc.). A package token is a token that is the parent of an item token or another package token. Here, for a token whose token type is a package token, one transport section may be regarded as a life cycle. That is, for a token whose token type is a package token, it may be generated and amortized in units of one transport section. Note that one transport section refers to a time interval until possession is transferred from one possessor to another. For example, it is a time interval until an article is transported from one base to another base, or a time interval from when an article is carried into one base until the article is carried out to another base.

[0038] ≪Contract Method≫ The following six are defined as methods for realizing transactions for generating tokens, associating / dissociating parent-child relationships, permitting transfer of possession, transferring possession, and amortizing tokens.

[0039] · Mint method · Pack method · Approve method · Transfer method · Unpack method · Burn method ≪Event≫ The following eight are defined as events issued upon execution of the contract method. The events include various parameters, execution results, operation type, etc. at the time of contract method execution. The operation type represents the type at the time of transaction execution. For example, when it is "0", it represents "user execution", and when it is "1", it represents "system execution". User execution indicates that a general user has executed the contract method, and system execution indicates that the system has automatically executed the contract method according to certain conditions.

[0040] · Mint Event · Pack Event · Packed Event · Unpack Event · Unpacked Event · Transfer Event · Approve Event · Burn Event In addition, regarding the above methods and events, when there is no risk of confusion with each other, the terms "method" and "event" may be omitted. For example, when it is clear that it is a method, the Mint method is simply denoted as Mint. The same applies to events.

[0041] The details of the above six methods will be described below. Regarding events, they will be described together during the description of the details of the methods.

[0042] ≪Mint Method≫ The Mint method is a method for executing a transaction to generate one or more tokens.

[0043] Arguments: The following are specified as arguments for the Mint method.

[0044] · Token ID list · Token type · Owner Here, in the token ID list, a list with the token IDs of the tokens to be generated as elements is set. The token ID list may be set with a list of elements represented in the form (token ID, meta information). In the token type, information indicating the token type of the token to be generated is set. When "0" is set in the token type, a package token is generated, and when "1" is set, an item token is generated. In the owner, the BC address of the owner of the token to be generated is set.

[0045] Limit: When the Mint method is executed, it is checked whether the following conditions are met within the method. If any of the conditions are not met, an error occurs.

[0046] a: The transaction issuer must match the possessor specified as an argument. b: Each element of the token ID list specified as an argument must not point to a token that exists in a valid state on the BC. Here, not existing in a valid state on the BC means that the token is either unissued or redeemed.

[0047] Process: For each element of the token ID list specified as an argument, perform the following Step11~Step12.

[0048] Step11) Register a token that has the possessor and token type specified as arguments as properties, associated with the token ID included in the element. At this time, the parent token ID property is an empty string, the child token ID list property is an empty array, and the transfer permission destination list property is an empty array. As a result, a token is generated. If meta information is included, associate the token ID and meta information included in the element with the token.

[0049] Step12) Issue a Mint event.

[0050] Here, the Mint event is an event that represents that a token has been generated. The Mint event includes, for example, the token ID of the token generated by the Mint method, the possessor (BC address) of the token, the transaction issuer (BC address) of the Mint method, the token type of the token, and the operation type.

[0051] Specific example: Assume that the Mint method with the following arguments is executed by the transaction issuer "0x111".

[0052] Token ID list = ["T01", "T02", "T03"] Token type: 1 (Item token) Owner: 0x111 In this case, three tokens with the following properties are generated.

[0053] {Token ID: "T01", Parent token ID: "", Owner: 0x111, Child token ID list: [], Transfer permission destination list: [], Token type: 1 (Item token)} {Token ID: "T02", Parent token ID: "", Owner: 0x111, Child token ID list: [], Transfer permission destination list: [], Token type: 1 (Item token)} {Token ID: "T03", Parent token ID: "", Owner: 0x111, Child token ID list: [], Transfer permission destination list: [], Token type: 1 (Item token)} Note that [] represents an empty array.

[0054] ≪Pack method≫ The Pack method is a method for executing a transaction that associates one or more tokens as children and another token as the parent, linking the child tokens to the parent token. Also, at this time, if the parent token does not exist, the Pack method automatically generates the parent token of the package token.

[0055] Arguments: The following are specified as arguments for the Pack method.

[0056] · Parent token ID · Child token ID list Here, the parent token ID is set to the token ID of the parent token to be associated. The child token ID list is set to a list whose elements are the token IDs of the child tokens to be associated.

[0057] Limitations: When the Pack method is executed, it is checked within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0058] a: The transaction issuer is identical to the possessor property of the token pointed to by the parent token ID specified as an argument. b: The possessor property of the token pointed to by the parent token ID specified as an argument is identical to the possessor property of each token pointed to by each element of the child token ID list specified as an argument. c: The parent token ID property of each token pointed to by each element of the child token ID list specified as an argument is an empty string. d: The transfer destination list property of the token pointed to by the parent token ID specified as an argument is an empty array (when there is a further parent token for the parent token (this is determined by the parent token ID property), recursively check the transfer destination list property up to the topmost parent token, and all transfer destination list properties are empty arrays). e: The parent token ID specified as an argument does not match the token ID of each element of the child token ID list specified as an argument. Processing: Execute the following Step21 to Step23.

[0059] Step21) If the token pointed to by the parent token ID specified as an argument does not exist in a valid state on the BC, generate a token with the said parent token ID and token type "0" (package token) using the Mint method. When the Mint method is executed, a Mint event is issued, and the operation type at that time shall be "1" (system execution).

[0060] Step22) For each token pointed to by each element of the child token ID list specified as an argument, execute the following Step22-1 to Step22-3.

[0061] Step22-1) If an array other than an empty array is set in the transfer destination list property of the token, clear the transfer destination list property (that is, set an empty array in the transfer destination list property).

[0062] Step22-2) Set the parent token ID specified as an argument in the parent token ID property of the token. Also, set "0" (0x0) in the possessor property of the token.

[0063] Step22-3) Issue a Packed event.

[0064] Here, the Packed event is an event indicating that a child token is associated with a parent token. The Packed event includes, for example, the token ID of the child token, the possessor (BC address) of the child token, the transaction issuer (BC address) of the Pack method, the token type of the child token, the operation type of the transaction of the Pack method, the parent token ID indicating the token ID of the parent token associated with the child token, and the list of child token IDs of the child token.

[0065] Step23) Execute the following Step23-1 to Step23-2 for the token pointed to by the parent token ID specified as an argument.

[0066] Step23-1) Add the token ID included in the list of child token IDs specified as an argument to the list of child token IDs property of the token.

[0067] Step23-2) Issue a Pack event.

[0068] Here, the Pack event represents an event where a new child token is associated with a parent token. The Pack event includes, for example, the token ID of the parent token to which the new child token is associated, the possessor (BC address) of the parent token, the transaction issuer (BC address) of the Pack method, the token type of the parent token, the operation type of the transaction of the Pack method, the parent token ID of the parent token, the list of child token IDs of the parent token, and the difference in the list of child token IDs. The difference in the list of child token IDs refers to the difference in the list property of the child token IDs held by the parent token before and after the execution of the Pack method.

[0069] Specific example: Assume there are four tokens with the following properties.

[0070] {token ID: "T01", parent token ID: "", possessor: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T02", parent token ID: "", possessor: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T03", parent token ID: "", possessor: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T04", parent token ID: "", possessor: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 0 (package token)} At this time, assume that the Pack method with the following arguments was executed by the transaction issuer "0x111".

[0071] parent token ID = "T04" list of child token IDs = ["T01", "T02", "T03"] In this case, the above four tokens will be as follows.

[0072] {Token ID: "T01", Parent Token ID: "T04", Owner: 0x0, List of Child Token IDs: [], List of Transfer Permission Destinations: [], Token Type: 1 (Item Token)} {Token ID: "T02", Parent Token ID: "T04", Owner: 0x0, List of Child Token IDs: [], List of Transfer Permission Destinations: [], Token Type: 1 (Item Token)} {Token ID: "T03", Parent Token ID: "T04", Owner: 0x0, List of Child Token IDs: [], List of Transfer Permission Destinations: [], Token Type: 1 (Item Token)} {Token ID: "T04", Parent Token ID: "", Owner: 0x111, List of Child Token IDs: ["T01", "T02", "T03"], List of Transfer Permission Destinations: [], Token Type: 0 (Package Token)} ≪Approve Method≫ The Approve method is a method for executing a transaction that grants permission to transfer ownership of one or more tokens to a certain BC address.

[0073] Arguments: The following are specified as arguments for the Approve method.

[0074] · List of Transfer Permission Information Here, the list of transfer permission information is composed of a list of elements that includes a list of transfer permission destination BC addresses, which is a list with elements of the token ID to be transferred and the BC addresses to be added to the transfer permission destination list property of the token pointed to by that token ID. That is, the list of transfer permission information is set with a list of elements in the form of (token ID, list of transfer permission destination BC addresses). The transfer permission destination list property enables the transfer of the token owner to the BC address if the transaction issuer of the Transfer method described later is the BC address existing in the transfer permission destination list property.

[0075] Limitations: When the Approve method is executed, it is checked whether the following conditions are met within the method. If any of the conditions are not met, an error occurs.

[0076] a: The token ID of each element in the transfer permission information list specified as an argument matches the owner property of the token pointed to by the token ID. b: The parent token ID property of the token pointed to by the token ID of each element in the transfer permission information list specified as an argument is an empty string. Note that the second condition above is a necessary condition for ownership transfer to be performed at the top-level parent token unit.

[0077] Processing: Execute the following Step31.

[0078] Step31) Repeat the following Step31-1 to Step31-2 for each element in the transfer permission information list specified as an argument.

[0079] Step31-1) Add the BC address set in the transfer permission destination BC address list included in the element to the transfer permission destination list property of the token pointed to by the token ID included in the element.

[0080] Step31-2) Issue an Approve event.

[0081] Here, the Approve event is an event indicating that ownership transfer permission has been granted to a certain token. The Approve event includes, for example, the token ID of the token to which ownership transfer permission has been granted, the owner (BC address) of the token, the transaction issuer (BC address) of the Approve method, the token type of the token, the operation type of the transaction of the Approve method, and the list of child token IDs of the token.

[0082] Specific example: Assume that there are two tokens with the following properties.

[0083] {Token ID: "T04", Parent Token ID: "", Owner: 0x111, Child Token ID List: ["T01", "T02", "T03"], Transfer Permission Destination List: [], Token Type: 0 (Package Token)} {Token ID: "T05", Parent Token ID: "", Owner: 0x111, Child Token ID List: [], Transfer Permission Destination List: [], Token Type: 1 (Item Token)} At this time, assume that the Approve method with the following arguments was executed by the transaction issuer "0x111".

[0084] Transfer Permission Information List = {Token ID: "T04", Transfer Permission Destination BC Address List: [0x222, 0x333]}, {Token ID: "T05", Transfer Permission Destination BC Address List: [0x222, 0x444]}] In this case, the above two tokens are as follows.

[0085] {Token ID: "T04", Parent Token ID: "", Owner: 0x111, Child Token ID List: ["T01", "T02", "T03"], Transfer Permission Destination List: [0x222, 0x333], Token Type: 0 (Package Token)} {Token ID: "T05", Parent Token ID: "", Owner: 0x111, Child Token ID List: [], Transfer Permission Destination List: [0x222, 0x444], Token Type: 1 (Item Token)} ≪Transfer Method≫ The Transfer method is a method for executing a transaction that transfers (transfers ownership) one or more tokens to a single transfer destination.

[0086] Arguments: The following are specified as arguments for the Transfer method.

[0087] · List of Token IDs to be Transferred · Transfer destination BC address Here, in the transfer target token ID list, a list having the token IDs of the tokens to be subject to the transfer of possession as elements is set. In the transfer destination BC address, the BC address of the possessor who is the transfer destination of the transfer of possession is set.

[0088] Restriction: When the Transfer method is executed, it is checked within the method whether the following conditions are satisfied. If any of the conditions is not satisfied, an error occurs.

[0089] a: The transaction issuer matches the transfer destination BC address specified as an argument b: The parent token ID property of the token pointed to by each element of the transfer target token ID list specified as an argument is an empty string c: The transfer destination BC address specified as an argument exists in the transfer permission destination list property of the token pointed to by each element of the transfer target token ID list specified as an argument Processing: Execute the following Step41.

[0090] Step41) For each token pointed to by an element of the transfer target token ID list specified as an argument, repeat the following Step41-1 to Step41-3.

[0091] Step41-1) Change the possessor property of the token to the transfer destination BC address specified as an argument.

[0092] Step41-2) Clear the transfer permission destination list property of the token (that is, set an empty array in the transfer permission destination list property).

[0093] Step41-3) Issue a Transfer event.

[0094] Here, the Transfer event represents an event indicating that the possessor of a certain token has been transferred. The Transfer event includes, for example, the token ID of the token for which the transfer of possession has occurred, the possessor (BC address) of the token after the transfer of possession, the transaction issuer (BC address) of the Transfer method, the token type of the token, the operation type of the transaction of the Transfer method, and the list of child token IDs of the token.

[0095] Specific example: Assume there are two tokens with the following properties.

[0096] {token ID: "T04", parent token ID: "", possessor: 0x111, list of child token IDs: ["T01", "T02", "T03"], list of transfer permission destinations: [0x222, 0x333], token type: 0 (package token)} {token ID: "T05", parent token ID: "", possessor: 0x111, list of child token IDs: [], list of transfer permission destinations: [0x222, 0x444], token type: 1 (item token)} At this time, assume that the Transfer method with the following arguments is executed by the transaction issuer "0x222".

[0097] List of token IDs to be transferred = ["T04", "T05"] Destination BC address = 0x222 In this case, the above two tokens become as follows.

[0098] {token ID: "T04", parent token ID: "", possessor: 0x222, list of child token IDs: ["T01", "T02", "T03"], list of transfer permission destinations: [], token type: 0 (package token)} {token ID: "T05", parent token ID: "", possessor: 0x222, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} ≪Unpack Method≫ The Unpack method is a method for executing a transaction that releases the association with one or more child tokens for a parent token having one or more child tokens. At this time, when there are no more child tokens for a parent token of token type "0" (package token), the Unpack method recursively amortizes the parent token.

[0099] Arguments: The following are specified as arguments for the Unpack method.

[0100] · Parent token ID · List of child token IDs Here, the parent token ID is set to the token ID of the parent token whose association with the child token is to be released. The list of child token IDs is set to a list having, as elements, the token IDs of the child tokens whose association with the said parent token is to be released.

[0101] Restrictions: When executing the Unpack method, it is checked within the method whether the following conditions are satisfied. If any of the conditions is not satisfied, an error occurs.

[0102] a: The transaction issuer matches the owner property of the token pointed to by the parent token ID specified as an argument (when there is a further parent token for the parent token (this is determined by the parent token ID property), the transaction issuer matches the owner property of the topmost parent token recursively obtained by the parent token ID property) Processing: Execute the following Step51~Step52.

[0103] Step51) For each token pointed to by each element of the list of child token IDs specified as an argument, repeat the following Step51-1~Step51-3.

[0104] Step51-1) Set an empty string to the parent token ID property of the said token.

[0105] Step51-2) Set the possessor of the token having the parent token ID specified as an argument in the possessor property of the token. At this time, if there is a parent token for the token pointed to by the parent token ID specified as an argument (this is determined by the parent token ID property), set the possessor property of the topmost parent token.

[0106] Step51-3) Issue an Unpacked event.

[0107] Here, the Unpacked event is an event indicating that the association between the child token and the parent token has been released. The Unpacked event includes, for example, the token ID of the token whose association with the parent token has been released, the possessor (BC address) of the token, the transaction issuer (BC address) of the Unpack method, the token type of the token, the operation type of the transaction of the Unpack method, the token ID of the parent token whose association with the token has been released, and the list of child token IDs of the token.

[0108] Step52) Execute the following Step52-1 to Step52-3 for the token pointed to by the parent token ID specified as an argument.

[0109] Step52-1) Delete the token ID included in the list of child token IDs specified as an argument from the list of child token ID properties of the token.

[0110] Step52-2) Issue an Unpack event.

[0111] Here, the Unpack event is an event indicating that the association with one or more child tokens has been released. The Unpack event includes, for example, the token ID of the parent token whose association with one or more child tokens has been released, the owner (BC address) of the parent token, the transaction issuer (BC address) of the Unpack method, the token type of the parent token, the operation type of the transaction of the Unpack method, the parent token ID of the parent token, the list of child token IDs of the parent token, and the difference in the list of child token IDs. The difference in the list of child token IDs refers to the difference in the list property of the child token IDs held by the parent token before and after the execution of the Unpack method.

[0112] Step52-3) When the token type property of the token is "0" (package token) and the list property of the child token IDs of the token is an empty array, the token is amortized by the Burn method. When the Burn method is executed, a Burn event is issued, and the operation type at that time is set to "1" (system execution). Also, at this time, if there is a further parent token for the parent token (this is judged by the parent token ID property), Steps 52-1 to 52-3 are recursively executed for this parent token.

[0113] Specific example: Assume that there are three tokens with the following properties.

[0114] {token ID: "T01", parent token ID: "T04", owner: 0x0, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T02", parent token ID: "T04", owner: 0x0, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {Token ID: "T04", Parent Token ID: "", Owner: 0x222, Child Token ID List: ["T01", "T02", "T03"], Transfer Permission Destination List: [], Token Type: 0 (Package Token)} At this time, assume that the Unpack method with the following arguments was executed by the transaction issuer "0x222".

[0115] Parent Token ID = "T04" Child Token ID List = ["T01", "T02"] In this case, the above token is as follows.

[0116] {Token ID: "T01", Parent Token ID: "", Owner: 0x222, Child Token ID List: [], Transfer Permission Destination List: [], Token Type: 1 (Item Token)} {Token ID: "T02", Parent Token ID: "", Owner: 0x222, Child Token ID List: [], Transfer Permission Destination List: [], Token Type: 1 (Item Token)} {Token ID: "T04", Parent Token ID: "", Owner: 0x222, Child Token ID List: ["T03"], Transfer Permission Destination List: [], Token Type: 0 (Package Token)} ≪Burn Method≫ The Burn method is a method for executing a transaction to amortize one or more tokens. Also, at this time, when there are no child tokens in the parent token of token type "0" (package token), the Burn method recursively amortizes the parent token.

[0117] Arguments: The following are specified as arguments for the Burn method.

[0118] · List of Token IDs to be amortized Here, in the list of token IDs to be amortized, a list with the token IDs of the tokens to be amortized as elements is set.

[0119] Limitations: When the Burn method is executed, it is checked within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0120] a: The transaction issuer is identical to the owner property of the token pointed to by each element of the token ID list specified as an argument (when there is a parent token for the token to be amortized (this is determined by the parent token ID property), the transaction issuer is identical to the owner property of the topmost parent token recursively obtained by the parent token ID property). b: The child token ID list property of the token pointed to by each element of the amortization target token ID list specified as an argument is an empty array. Processing: Execute the following Step61~Step62.

[0121] Step61) For each token pointed to by each element of the amortization target token ID list specified as an argument, repeat the following Step61-1~Step61-2.

[0122] Step61-1) Clear each property of the token.

[0123] Step61-2) Issue a Burn event.

[0124] Here, the Burn event is an event indicating that a certain token has been amortized. The Burn event includes, for example, the token ID of the amortized token, the owner of the token, the transaction issuer (BC address) of the Burn method, the token type of the token, the operation type of the transaction of the Burn method, and the parent token ID of the token.

[0125] Step62) If there is a parent token for the amortized token (this is determined by the parent token ID property), execute the following Step62-1~Step62-3.

[0126] Step62-1) Delete the token ID of the amortized token from the child token ID list property of the parent token.

[0127] Step62-2) Issue an Unpack event.

[0128] Step62-3) When the token type property of the parent token is "0" (package token) and the child token ID list property of the parent token becomes an empty array, amortize the parent token by the Burn method. When the Burn method is executed, a Burn event is issued, and the operator type at that time shall be "1" (system execution). Also, at this time, if there is a further parent token for the parent token (this is judged by the parent token ID property), execute Steps 62-1 to 62-3 recursively for this parent token.

[0129] Specific example: Assume that there are three tokens with the following properties.

[0130] {token ID: "T01", parent token ID: "", possessor: 0x222, child token ID list: [], transfer permission destination list: [], token type: 1 (item token)} {token ID: "T02", parent token ID: "T04", possessor: 0x0, child token ID list: [], transfer permission destination list: [], token type: 1 (item token)} {token ID: "T04", parent token ID: "", possessor: 0x222, child token ID list: ["T02,T03"], transfer permission destination list: [], token type: 0 (package token)} At this time, assume that the Burn method with the following arguments is executed by the transaction issuer "0x222".

[0131] Amortization target token ID list = ["T01", "T02"] In this case, the tokens with the above token IDs "T01" and "T02" are amortized and the properties are cleared (assuming 0 is the default value).

[0132] {token ID:"", parent token ID:"", owner:0x0, list of child token IDs:[], list of transfer permission destinations:[], token type:0} Also, the above token ID "T04" is as follows.

[0133] {token ID:"T04", parent token ID:"", owner:0x222, list of child token IDs:["T03"], list of transfer permission destinations:[], token type:0 (package token)} This means that the tokens with token IDs "T01" and "T02" are amortized, and the association between the token with token ID "T04" and the token with token ID "T02" is released.

[0134] <Reuse of Token ID> Token IDs must not overlap while tokens associated with actual existing items, transport containers, etc. exist on the BC (that is, from the generation of the token to its amortization). This is because the token ID uniquely associates the actual item (e.g., an item or a transport container, etc.) with the token. However, as the number of token IDs increases, there is a problem that the quantity of storage media such as RFID tags and QR codes for associating tokens with actual items becomes enormous and the management cost becomes high.

[0135] On the other hand, after the token is amortized, even if a token with the same token ID as this token is newly generated, there is no problem in updating the information representing the token.

[0136] Therefore, after a token is amortized, it is possible to reuse the token ID of the token and an identifier such as an RFID tag or a QR code for identifying an article, a transport container, etc. that is a management target associated with the token. Thereby, for example, it is possible to reuse RFID tags and QR codes attached to real objects without rewriting them. In particular, since the purchase cost of RFID tags is high compared to the cost of printing QR codes, etc., the reuse of RFID tags is effective for cost reduction.

[0137] The proposed method enables the reuse of token IDs. Therefore, hereinafter, the reuse of the token ID of a token whose token type is a package token and the reuse of the token ID of a token whose token type is an item token will be described.

[0138] ≪Reuse of Token ID of Package Token≫ Package tokens are associated with transportation containers and the like, and are assumed to be reused multiple times in the logistics supply chain. At this time, when managing the transfer of possession across multiple transportation segments, it is assumed that operational difficulties will arise. For example, if items loaded on a pallet are transported from warehouse A to warehouse B and these items are unloaded at warehouse B, and if the transporter returns only the pallet to warehouse A without transferring the possession of the token associated with the pallet, then the owner of the pallet remains as warehouse B on the blockchain, and thus no operations can be performed on the token of the pallet at warehouse A with respect to the blockchain. On the other hand, if the owner of the token associated with the pallet is transferred from warehouse B to warehouse A when the pallet is returned to warehouse A, operations at warehouse A become possible, but the number of transactions increases. Also, if package tokens are generated and amortized within a single transportation segment, the number of token IDs for package tokens becomes large, and the number of transactions further increases. Therefore, for tokens whose token type is a package token, they may be generated and amortized in units of a single transportation segment, and tokens may be issued (generated) as belonging to a new owner. In this case, the token can be amortized when all associations with child tokens are released from the token associated with the pallet at warehouse B, and thereafter, the token can be regenerated using the same token ID.

[0139] By using the contract method described above, tokens are automatically generated if they do not exist when the Pack method is executed, and tokens are automatically amortized when there are no more child tokens in the Unpack method. Therefore, the token ID associated with the package token can be automatically reused.

[0140] Also, package tokens are used to transfer the possession of multiple tokens collectively. That is, a package token does not track its own transfer of possession. For this reason, when regenerating a package token, the RFID tag or QR code already attached to the transportation container associated with the token is reused.

[0141] As a result, the ID (identifier) recorded on the RFID tag or QR code attached to the transport container can be used as it is without being rewritten. Therefore, for example, it is possible to reduce the purchase cost of RFID tags, the printing cost of QR codes, and the operational costs required for re-attaching RFID tags and QR codes. In addition, by reusing the token ID, the possibility of the token ID being exhausted can be reduced.

[0142] Here, an example of reusing the token ID of the package token is shown in FIG. 5. The example shown in FIG. 5 shows an example in which the package token with the token ID "T01" is reused. Note that the block number is the number of the block that constitutes the distributed ledger on the BC.

[0143] ≪Reuse of Token ID of Item Token≫ Since the item token is associated with the item to be tracked, even after the token's life cycle ends, for example, it is necessary to keep the token information on the BC in a state where it can be immediately retrieved for a certain period for identifying the scope of influence when a problem occurs with the item. On the other hand, since the frequency of immediate tracking required over time decreases, it is considered that the token ID may be reused after a certain period (for example, a period determined by law, contract, agreement of BC participants, etc.).

[0144] Regarding the reused token ID, if it is desired to track the information of the token before reuse, etc., such tracking is also possible by referring to the event and past blocks.

[0145] <Overall Configuration Example of Logistics Management System 1> Hereinafter, a logistics management system 1 that manages an object to be tracked (e.g., goods, etc.) during logistics by generating tokens, associating / dissociating parent-child relationships, permitting transfer of possession, transferring possession, and amortizing tokens according to the above-described proposed method will be described. An example of the overall configuration of the logistics management system 1 according to the first embodiment is shown in FIG. 6. As shown in FIG. 6, the logistics management system 1 according to the first embodiment includes a plurality of nodes 10 that constitute a blockchain (BC) and a plurality of terminals 20 used by users. These are communicably connected via a communication network including, for example, an inter-enterprise network or the like.

[0146] The node 10 is a general-purpose server, a PC (personal computer), or the like that constitutes the BC. Each node 10 is distributed on the BC network and is connected to each other in a P2P (Peer to Peer) manner. Further, each node 10 has a distributed ledger shared among each other and has a smart contract in which the above-described respective methods (Mint method, Pack method, Approve method, Transfer method, Unpack method, and Burn method) are implemented, and executes transactions and the like.

[0147] The terminal 20 is various terminals (e.g., a PC, a smartphone, a tablet terminal, a wearable device, etc.) used by a user who performs token generation, parent-child relationship association / dissociation, possession transfer permission, possession transfer, token amortization, and the like. Hereinafter, when distinguishing each of the plurality of terminals 20, it is denoted as "terminal 20-1", "terminal 20-2", etc. Also, the terminal 20 used by the user is denoted as "user terminal 21". This is for distinguishing it from the administrator terminal 22 described later.

[0148] Note that the example of the overall configuration of the logistics management system 1 shown in FIG. 6 is merely an example and is not limited thereto. For example, in addition to the nodes 10 and the terminals 20, devices, apparatuses, or the like that realize some functions may be included in the logistics management system 1.

[0149] <Functional configuration example of the nodes 10 and the terminals 20 included in the logistics management system 1> Hereinafter, a functional configuration example of the node 10 and the terminal 20 included in the logistics management system 1 according to the first embodiment will be described.

[0150] ≪Node 10≫ A functional configuration example of the node 10 according to the first embodiment is shown in FIG. 7. As shown in FIG. 7, the node 10 according to the first embodiment has a transaction execution unit 101. The transaction execution unit 101 is realized by a process in which a smart contract implemented on the blockchain platform of the node 10 is executed by a processor such as a CPU (Central Processing Unit) or a GPU (Graphic Processing Unit). Further, the node 10 according to the first embodiment has a storage unit 102. The storage unit 102 is realized by an auxiliary storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory, for example.

[0151] The transaction execution unit 101 executes a transaction for generating a token, associating / dissociating a parent-child relationship, permitting transfer of possession, transferring possession, or burning a token by the above-described respective methods (Mint method, Pack method, Approve method, Transfer method, Unpack method, and Burn method).

[0152] The storage unit 102 stores a distributed ledger. The distributed ledger is composed of blocks in which information representing transactions, each event (Mint event, Pack event, Packed event, Unpack event, Unpacked event, Transfer event, Approve event, and Burn event) (hereinafter, this information is also referred to as "event information"), information representing each token (hereinafter, this information is also referred to as "token storage information"), etc. are recorded. Note that, in addition to the distributed ledger, the storage unit 102 may store various information necessary for token generation, parent-child relationship association / dissociation, transfer of possession permission, transfer of possession, or token burning.

[0153] ≪Terminal 20≫ Fig. 8 shows a functional configuration example of the terminal 20 according to the first embodiment. As shown in Fig. 8, the terminal 20 according to the first embodiment has a transaction issuing unit 201. The transaction issuing unit 201 is realized, for example, by a process executed by a processor such as a CPU for one or more programs installed in the terminal 20. Further, the terminal 20 according to the first embodiment has a storage unit 202. The storage unit 202 is realized, for example, by an auxiliary storage device such as an HDD, an SSD, or a flash memory.

[0154] The transaction issuing unit 201 issues a transaction for generating a token, associating / dissociating a parent-child relationship, permitting transfer of possession, transferring possession, and amortizing a token.

[0155] The storage unit 202 stores information necessary for issuing a transaction (for example, the BC address of the user who uses the terminal 20). In addition to these, the storage unit 202 may store various other information necessary for issuing a transaction by reading an ID from an RFID tag or a QR code attached to an article or the like.

[0156] <Example of Transaction Issuing and Execution Processing> Hereinafter, the flow of the process of issuing and executing a transaction for generating a token, associating / dissociating a parent-child relationship, permitting transfer of possession, transferring possession, or amortizing a token will be described with reference to Fig. 9.

[0157] The transaction issuing unit 201 of the terminal 20 issues a transaction for generating a token, associating / dissociating a parent-child relationship, permitting transfer of possession, transferring possession, or amortizing a token (step S101). That is, the transaction issuing unit 201 of the terminal 20 issues a transaction as follows.

[0158] · When generating a token, issue a transaction specifying the Mint method and its arguments.

[0159] · When performing parent - child relationship linking, issue a transaction specifying the Pack method and its arguments.

[0160] · When performing transfer - of - possession permission, issue a transaction specifying the Approve method and its arguments.

[0161] · When performing transfer of possession, issue a transaction specifying the Transfer method and its arguments.

[0162] · When performing unlinking of the parent - child relationship, issue a transaction specifying the Unpack method and its arguments.

[0163] · When performing token amortization, issue a transaction specifying the Burn method and its arguments.

[0164] Next, the transaction issuing unit 201 of the terminal 20 transmits the transaction issued in the above step S101 to a certain node 10 (for example, a node 10 predetermined for the terminal 20) (step S102).

[0165] When the transaction execution unit 101 of the node 10 receives a transaction, it executes this transaction (step S103). That is, the transaction execution unit 101 of the node 10 executes the transaction as follows.

[0166] · When receiving a transaction specifying the Mint method and its arguments, execute the Mint method with the specified arguments.

[0167] · When receiving a transaction specifying the Pack method and its arguments, execute the Pack method with the specified arguments.

[0168] ·When receiving a transaction with the Approve method and its arguments specified, execute the Approve method with the specified arguments.

[0169] ·When receiving a transaction with the Transfer method and its arguments specified, execute the Transfer method with the specified arguments.

[0170] ·When receiving a transaction with the Unpack method and its arguments specified, execute the Unpack method with the specified arguments.

[0171] ·When receiving a transaction with the Burn method and its arguments specified, execute the Burn method with the specified arguments.

[0172] Note that the event information of the transaction executed in step S103 above and the events issued during the execution of the method that realizes the transaction is recorded in the blocks that make up the distributed ledger.

[0173] As described above, in the logistics management system 1 according to the first embodiment, an efficient transfer of possession can be realized by using the parent-child relationship between the tracking target (e.g., articles, etc.) during logistics and its transport container. That is, the parent-child relationship can be mutually referable, and its association / dissociation can be realized in one transaction, and it is possible to transfer the possession of the children at a lower level than the parent unit in one transaction collectively. Also, if the transfer destination of possession is the same, it is possible to transfer the possession of a plurality of tokens in one transaction collectively at the parent unit. For this reason, it is possible to easily refer to the information of another object that has a parent-child relationship with a certain object, and the number of issued transactions is reduced, and the load (e.g., the workload of the operator due to issuing transactions, the network resource / server resource load required for verification / synchronization of each node on the blockchain, etc.) can be reduced when recording the transfer of possession of the tracking target in the BC.

[0174] [Second Embodiment] Next, the second embodiment will be described. In the second embodiment, mainly the differences from the first embodiment will be described, and the description of the points that may be the same as those in the first embodiment will be omitted.

[0175] <Record omission of occupancy transfer> In the logistics supply chain, there may be a record omission of occupancy transfer due to the operator's mistake. In this case, a deviation of the occupant will occur between the token on the BC and the actual item. On the other hand, the token on the BC cannot transfer its occupancy unless it is the occupant or the person who has been granted permission to transfer the occupancy.

[0176] For example, as users, there are A (BC address: 0x111), B (BC address: 0x222), and C (BC address: 0x333). As shown in FIG. 10, for the token with the token ID "T01", it is assumed that user A has granted user B permission to transfer occupancy (transaction issuer: A, occupant: A). After that, although user B should originally transfer the occupancy to himself / herself and grant user C permission to transfer the occupancy, it is assumed that there is a record omission of that transaction. At this time, even if user C issues a transaction for transferring the occupancy to himself / herself, that transaction cannot be executed. This is because due to the above-mentioned record omission, the BC address "0x333" of user C is not included in the transfer permission destination list property of the token on the BC.

[0177] Therefore, in order to resume the record of occupancy transfer on the BC, it is necessary to temporarily suspend the logistics of the item with the deviation of the occupant, and then execute the occupancy transfer that each user should originally perform since the time when the record omission of the occupancy transfer occurred, and record the transaction in the distributed ledger on the BC. However, the longer the period of the record omission, the more users (hereinafter also referred to as related parties) are involved, and as a result, the time for suspending the logistics becomes longer. Therefore, such a corrective measure is unrealistic. Therefore, below, a method that allows the administrator to act on behalf of the occupancy transfer when the record omission occurs will be proposed.

[0178] <Proposed method> The following describes the proposed method. Note that, except where otherwise noted, it may be the same as the first embodiment.

[0179] <<Execution authority of contract method>> Assume that there is at least one "user" with general authority and one "administrator" with privileged authority. The administrator may be, for example, the person who deploys the contract in which the above contract method is implemented to each node 10, a user who has been granted administrator authority by another administrator, etc. Also, there does not have to be only one administrator, and there may be multiple administrators.

[0180] Also, in each contract method, the transaction issuer determines whether it matches specific properties of the token to be updated (such as the possessor property, transfer permission destination list property, etc.) and restricts access (described in "a" of the "restriction" of the method). Here, the restriction "a" is changed so that access is possible if the transaction issuer is the user described in restriction "a" or the "administrator" user described above. <<Operation type of event>> Add "2", which represents "administrator execution", as an operation type representing the type of the transaction issuer. That is, the operation type is represented by "0" (general user execution), "1" (system execution), and "2" (administrator execution).

[0181] <<Supplementary history list map>> The contract shall have a supplementary list map as storage information. Here, the supplementary history list map associates the token ID of the token for which a recording omission of the transfer of possession occurred with the block number of the block in which the transaction for performing a special transfer of possession described later was recorded, and stores the supplementary history list. The supplementary history list includes a plurality of supplementary histories. In the supplementary history, the BC address of the transferor of the transfer of possession (hereinafter also referred to as the transferor BC address), the BC address of the transferee of the transfer of possession (hereinafter referred to as the transferee BC address), a transferor approval category indicating whether the user having the transferor BC address has approved the supplementary history, a transferee approval category indicating the approval status of the supplementary history of the user having the transferee BC address, etc. are set. It is assumed that the transferor approval category and the transferee approval category are "not approved" when "0" is set, "approved" when "1" is set, and "denied" when "2" is set. For example, the supplementary history list map is represented in the following data format.

[0182] Supplementary history list map[token ID][block number]=[{transferor BC address, transferee BC address, transferor approval category, transferee approval category}] Note that this is just an example, and the supplementary history may further include, for example, the reason why the administrator carried out the special transfer of possession.

[0183] The above supplementary history is approved or denied by the relevant parties. This is to enhance the reliability by seeking approval or denial from the user (relevant party) who actually caused the recording omission because the administrator is acting on behalf of the transfer of possession.

[0184] ≪Contract method≫ Hereinafter, when a manager substitutes for a transfer of possession, it is called "special transfer of possession", and a method for realizing a transaction for performing a special transfer of possession is defined. Also, a method for realizing a transaction for a related party to approve or deny a supplementary history (hereinafter, also referred to as "supplementary history approval"), and a method for realizing a transaction for a manager to update a supplementary history (hereinafter, also referred to as "supplementary history update") are defined. Furthermore, events issued within these methods are defined.

[0185] As methods, the following three are defined.

[0186] · SpecialTransfer method · Confirm method · UpdateSupplementalHistory method ≪Events≫ As events, the following two are defined.

[0187] · Notice event · Confirm event Hereinafter, the details of the above three methods will be described. Regarding events, they will be described together in the process of explaining the details of the methods.

[0188] ≪SpecialTransfer method≫ The SpecialTransfer method is a method for forcibly transferring the possession of one or more tokens with administrator authority and executing a transaction for creating a supplementary history of the transfer of possession (that is, a transaction for performing a special transfer of possession).

[0189] Arguments: The following are specified as arguments for the SpecialTransfer method.

[0190] · Token ID list · Transfer path list · Reason Here, in the token ID list, a list with the token IDs of the tokens subject to special possession transfer as elements is set. In the transfer path list, a list storing the BC addresses of the possessors in the order of the original possession transfer flow is set. For the reason, the reason for special possession transfer is set as necessary.

[0191] Restriction: When the SpecialTransfer method is executed, it is checked within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0192] · The transaction issuer is an administrator Process: Execute the following Step71.

[0193] Step71) For each element of the token ID list specified as an argument, repeat the following Step71-1 to Step71-4.

[0194] Step71-1) As arguments of the Transfer method, specify the token ID of the element in the destination token ID list and the BC address at the end of the transfer path list specified as an argument of the SpecialTransfer method as the destination BC address, and execute the Transfer method. When the Transfer method is executed, a Transfer event is issued, and the operation type at that time is set to "2" (administrator execution).

[0195] Step71-2) Create a supplementary history list for each transfer path using the token ID, the BC address before the change in Step71-1 above, and the BC addresses included in the specified transfer path list as arguments. That is, create the first supplementary history with the BC address before the change in Step71-1 above as the source BC address and the first BC address included in the transfer path list as the destination BC address. Also, for n = 1, ···, N - 1 (where N is the number of BC addresses included in the transfer path list), create the (n + 1)-th supplementary history with the n-th BC address included in the transfer path list as the source BC address and the (n + 1)-th BC address included in the transfer path list as the destination BC address. As a result, a supplementary history list consisting of N supplementary histories as elements is created. Here, the token ID of all supplementary histories is set to the token ID (i.e., the token ID used in the current iteration of Step71-1 to Step71-4), and the block number of the distributed ledger in which the transaction of the special occupancy transfer is recorded is set to the block number. Also, for the source approval classification and destination approval classification of all supplementary histories, for example, "0" indicating unapproved is set.

[0196] Step71-3) Add the supplementary history list created in Step71-2 above to the supplementary history list map using the token ID of the token and the block number in which the transaction of the special occupancy transfer is recorded as keys.

[0197] Step71-4) Issue a Notice event.

[0198] Here, the Notice event is an event that notifies that a special possession transfer or supplemental history update has been performed. The Notice event includes, for example, the token ID of the token for which the special possession transfer or supplemental history update has been performed, the possessor of the token, the transaction issuer (BC address) of the SpecialTransfer method or UpdateSupplementalHistory method, the token type of the token, the operation type of the transaction of the SpecialTransfer method or UpdateSupplementalHistory method, the special possession transfer block number representing the block number of the distributed ledger in which the transaction of the special possession transfer or supplemental history update is recorded, the notification type, and the reason. For the notification type, for example, "0" is set for special possession transfer and "1" is set for supplemental history update. Also, for the reason, the reason specified as an argument is set.

[0199] Specific example: Assume the following tokens exist.

[0200] {token ID: "T01", parent token ID: "", possessor: 0x111, child token ID list: [], transfer permission destination list: [], token type: 1 (item token)} At this time, assume that the SpecialTransfer method with the following arguments is executed by the administrator and recorded at block number 100.

[0201] token ID list = ["T01"] transfer route list = [0x222, 0x333] reason = "due to omission of recording of possession transfer" In this case, the above token becomes as follows.

[0202] {token ID: "T01", parent token ID: "", possessor: 0x333, child token ID list: [], transfer permission destination list: [], token type: 1 (item token)} The supplemental history list map becomes as follows.

[0203] Supplementary History List Map ["T01"]

[0100] = {Transfer source BC address: 0x111, Transfer destination BC address: 0x222, Transfer source approval classification: 0 (unapproved), Transfer destination approval classification: 0 (unapproved)}, {Transfer source BC address: 0x222, Transfer destination BC address: 0x333, Transfer source approval classification: 0 (unapproved), Transfer destination approval classification: 0 (unapproved)}] ≪Confirm method≫ The Confirm method is a method for executing a transaction in which a person concerned approves or disapproves of the supplementary history of a special possession transfer (that is, a transaction for performing supplementary history approval).

[0204] Arguments: The following are specified as arguments for the Confirm method.

[0205] · Supplementary history information list · Supplementary history approval flag Here, the supplementary history information list is set with a list of elements composed of the token ID of the token to be approved or disapproved, the block number of the distributed ledger in which the transaction of the special possession transfer is recorded, and the index number of the supplementary history to be approved or disapproved in the supplementary history list. That is, the supplementary history information list is set with a list of elements represented in the form of (token ID, block number, index number). The index number represents the number indicating the position of the supplementary history to be approved or disapproved from the top of the supplementary history list. For example, it represents the number with the top supplementary history of the supplementary history list as the 0th. The supplementary history approval flag is set to either "0" (approved) or "1" (disapproved).

[0206] Restrictions: When the Confirm method is executed, it is checked within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0207] · The transaction issuer is a user who has the transfer source BC address or the transfer destination BC address of the supplementary history to be approved or denied. Process: Execute the following Step81.

[0208] Step81) Repeat the following Step81-1 to Step81-3 for each element of the supplementary history information list specified as an argument.

[0209] Step81-1) Obtain the supplementary history list from the supplementary history list map using the token ID, block number, and index number included in the element as keys.

[0210] Step81-2) Update the transfer source approval classification or the transfer destination approval classification of each supplementary history included in the supplementary history list obtained in Step81-1 according to the supplementary history approval flag specified as an argument and whether the transaction issuer is the user of the transfer source BC address or the user of the transfer destination BC address. That is, when the supplementary history approval flag is "0", if the transaction issuer is the user of the transfer source BC address, update the transfer source approval classification to "1" (approved); if the transaction issuer is the user of the transfer destination BC address, update the transfer destination approval classification to "1" (approved). On the other hand, when the supplementary history approval flag is "1", if the transaction issuer is the user of the transfer source BC address, update the transfer source approval classification to "2" (denied); if the transaction issuer is the user of the transfer destination BC address, update the transfer destination approval classification to "2" (denied).

[0211] Note that the reason for setting the transfer source approval classification and the transfer destination approval classification as the approval classifications is that it is considered that the reliability of the special possession transfer can be enhanced by the approval of each of the transfer source user and the transfer destination user.

[0212] Step81-3) Issue a Confirm event.

[0213] Here, the Confirm event is an event indicating the approval or rejection of the supplementary history. The Confirm event includes, for example, the token ID of the token to be approved or rejected, the possessor of the token, the transaction issuer (BC address) of the Confirm event, the token type of the token, the operation type of the transaction of the Confirm event, the supplementary history index number indicating the position of the approved or rejected supplementary history from the top of the supplementary history list, the supplementary history transfer source indicating the transfer source BC address of the approved or rejected supplementary history, the supplementary history transfer destination indicating the transfer destination BC address of the approved or rejected supplementary history, and the supplementary history approval flag indicating whether the supplementary history is approved or rejected.

[0214] Specific example: Assume that the following supplementary history list map exists.

[0215] Supplementary history list map ["T01"]

[0100] = {Transfer source BC address: 0x111, transfer destination BC address: 0x222, transfer source approval classification: 0 (unapproved), transfer destination approval classification: 0 (unapproved)}, {Transfer source BC address: 0x222, transfer destination BC address: 0x333, transfer source approval classification: 0 (unapproved), transfer destination approval classification: 0 (unapproved)}] At this time, assume that the Confirm method with the following arguments is executed by the transaction issuer "0x222".

[0216] Supplementary history information list= {Token ID: "T01", block number: 100, index number: 0}, {Token ID: "T01", block number: 100, index number: 1}] Supplementary history approval flag = 1 (rejected) In this case, the above supplementary history list map becomes as follows.

[0217] Supplementary history list map ["T01"]

[0100] = {Source BC Address: 0x111, Destination BC Address: 0x222, Source Approval Status: 0 (Unapproved), Destination Approval Status: 2 (Denied)}, {Source BC Address: 0x222, Destination BC Address: 0x333, Source Approval Status: 2 (Denied), Destination Approval Status: 0 (Unapproved)}] ≪UpdateSupplementalHistory Method≫ The UpdateSupplementalHistory method is a method for executing a transaction (i.e., a transaction for updating the supplementary history) that updates the transfer path of the supplementary history list of special occupancy transfers with administrator privileges. When this method is executed, the approval status of each supplementary history is reset.

[0218] Arguments: The following are specified as arguments for the UpdateSupplementalHistory method.

[0219] · Supplementary history information list · Transfer path list Here, the supplementary history information list is set with a list of elements composed of the token ID of the token to be approved or denied and the block number of the distributed ledger where the transaction of the special occupancy transfer is recorded. That is, the supplementary history information list is set with a list of elements represented in the form of (token ID, block number). The transfer path list is set with a list storing the BC addresses of the possessors in the order of the original occupancy transfer flow.

[0220] Restrictions: When the UpdateSupplementalHistory method is executed, it is checked within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0221] · The transaction issuer is an administrator Processing: Execute the following Step91.

[0222] For each element of the supplementary history information specified as an argument, repeat the following Step91-1 to Step91-4.

[0223] Step91-1: Obtain the supplementary history list from the supplementary history list map using the token ID and block number included in the element as keys.

[0224] Step91-2: Create supplementary histories for each transfer path using the token ID, the source BC address of the first supplementary history included in the supplementary history list obtained in Step91-1 above, and the BC address included in the transfer path list specified as an argument. That is, create the first supplementary history with the BC address set in the source BC address of the first supplementary history included in the supplementary history list obtained in Step91-1 above as the source BC address and the first BC address included in the transfer path list as the destination BC address. Also, for n = 1, ···, N - 1 (where N is the number of BC addresses included in the transfer path list), create the (n + 1)-th supplementary history with the n-th BC address included in the transfer path list as the source BC address and the (n + 1)-th BC address included in the transfer path list as the destination BC address. As a result, N supplementary histories are created. Here, the token ID of all supplementary histories is set to the token ID included in the element (that is, the token ID used in the current iteration of Step91-1 to Step91-4), and the block number is set to the block number included in the element. Also, for the source approval classification and destination approval classification of all supplementary histories, for example, "0" indicating unapproved is set.

[0225] Step91-3: Clear the supplementary history list from the supplementary history list map using the token ID and block number included in the element as keys, and then add the supplementary history created in Step91-2 above to the supplementary history list map using the token ID and block number included in the element as keys.

[0226] Step91-4) Issue a Notice event.

[0227] Specific example: Assume that the following supplementary history list map exists.

[0228] Supplementary history list map ["T01"]

[0100] = {Source BC address: 0x111, Destination BC address: 0x222, Source approval category: 1 (Approved), Destination approval category: 2 (Denied)}, {Source BC address: 0x222, Destination BC address: 0x333, Source approval category: 2 (Denied), Destination approval category: 1 (Approved)} At this time, assume that the UpdateSupplementalHistory method with the following arguments specified was executed by the administrator.

[0229] Supplementary history information list = [{Token ID: "T01", Block number: 100}] Transfer path list = [0x444, 0x333] In this case, the above supplementary history list map will be as follows.

[0230] Supplementary history list map ["T01"]

[0100] = {Source BC address: 0x111, Destination BC address: 0x444, Source approval category: 0 (Unapproved), Destination approval category: 0 (Unapproved)}, {Source BC address: 0x444, Destination BC address: 0x333, Source approval category: 0 (Unapproved), Destination approval category: 0 (Unapproved)} <Overall configuration example of logistics management system 1> According to the above proposed method, the overall configuration example of the logistics management system 1 that performs special occupancy transfer, supplementary history approval, and supplementary history update may be the same as that of the first embodiment, so the description thereof is omitted. However, hereinafter, the terminal 20 used by the administrator is referred to as the "administrator terminal 22".

[0231] <Functional configuration example of node 10 and terminal 20 included in logistics management system 1> Hereinafter, a functional configuration example of the terminal 20 according to the second embodiment will be described. Since the functional configuration example of the node 10 according to the second embodiment may be the same as that of the first embodiment, the description thereof will be omitted.

[0232] ≪Terminal 20≫ A functional configuration example of the terminal 20 according to the second embodiment is shown in FIG. 11. As shown in FIG. 11, the terminal 20 according to the second embodiment has, in addition to each part described in the first embodiment, an occupancy transfer agency request part 203 and a supplementary history list acquisition part 204. Each of these parts is realized, for example, by a process in which one or more programs installed in the terminal 20 are executed by a processor such as a CPU.

[0233] When the user of the terminal 20 is a user who desires occupancy transfer agency (that is, when the terminal 20 is the user terminal 21 of the user who desires occupancy transfer agency), the occupancy transfer agency request part 203 requests the administrator terminal 22 for occupancy transfer agency.

[0234] When the user of the terminal 20 is a person related to the omission of occupancy transfer record (that is, when the terminal 20 is the user terminal 21 of the person (user) related to the omission of occupancy transfer record), the supplementary history list acquisition part 204 acquires the supplementary history list from the supplementary history list map in order to perform supplementary history approval.

[0235] <Special Occupancy Transfer, Supplementary History Approval, and Supplementary History Update Processing> Hereinafter, the flow of processing for performing special occupancy transfer, supplementary history approval, and supplementary history update will be described with reference to FIG. 12. In the following, the terminal 20 of the user who requests the administrator for occupancy transfer agency is referred to as the user terminal 21-1, and the terminal 20 of the user (person related) who has omitted the occupancy transfer record is referred to as the user terminal 21-2.

[0236] The transfer agency request section 203 of the user terminal 21-1 requests the administrator terminal 22 to act as an agent for the transfer of possession (step S201). Here, the transfer agency request includes, for example, a token ID list, a transfer route list, and a reason specified as an argument of the SpecialTransfer method. Note that the transfer agency request section 203 may make a transfer agency request by a predetermined means (e.g., email, messaging application, etc.). However, this is just an example, and the transfer agency request may be made by, for example, phone, orally, by letter, etc.

[0237] The transaction issuing section 201 of the administrator terminal 22 issues a transaction for performing a special transfer of possession (step S202). That is, the transaction issuing section 201 of the administrator terminal 22 issues a transaction specifying the SpecialTransfer method and its arguments (e.g., the token ID list, the transfer route list, and the reason included in the transfer agency request).

[0238] Next, the transaction issuing section 201 of the administrator terminal 22 transmits the transaction issued in step S202 above to a certain node 10 (e.g., a node 10 predetermined for the administrator terminal 22) (step S203).

[0239] When the transaction execution section 101 of the node 10 receives a transaction, it executes this transaction (step S204). That is, the transaction execution section 101 of the node 10 executes the SpecialTransfer method specified with the arguments specified in the received transaction. As a result, a special transfer of possession is performed, and a Notice event indicating that the special transfer of possession has been performed is issued.

[0240] The supplementary history list acquisition section 204 of the user terminal 21-2 acquires a supplementary history list from the supplementary history list map using the token ID and block number included in the Notice event issued in step S204 above as keys (step S205).

[0241] The following steps S206 to S208 are executed when the BC address of the user of the user terminal 21-2 exists in the supplementary history list acquired in the above step S205 (that is, when the source BC address or the destination BC address of at least one supplementary history in the supplementary history list is the BC address of the user of the user terminal 21-2).

[0242] The transaction issuing unit 201 of the user terminal 21-2 issues a transaction for supplementary history approval (step S206). That is, the transaction issuing unit 201 of the user terminal 21-2 issues a transaction specifying the Confirm method and its arguments. Note that the arguments of the Confirm method (that is, the supplementary history information list and the supplementary history approval flag) are specified by the user (the user of the user terminal 21-2) who has determined whether to approve or deny the supplementary history in which its own BC address is set as the source BC address or the destination BC address.

[0243] The transaction issuing unit 201 of the user terminal 21-2 transmits the transaction issued in the above step S206 to a certain node 10 (for example, the node 10 predetermined for the user terminal 21-2) (step S207).

[0244] When the transaction execution unit 101 of the node 10 receives a transaction, it executes this transaction (step S208). That is, the transaction execution unit 101 of the node 10 executes the Confirm method specifying the arguments specified in the received transaction. Thereby, supplementary history approval is performed and a Confirm event is issued.

[0245] The following steps S209 to S211 are executed when, for example, a certain supplementary history is denied by the user of the user terminal 21-2 due to an error in the supplementary history or the like, and the administrator updates the supplementary history.

[0246] The transaction issuing unit 201 of the administrator terminal 22 issues a transaction for updating the supplementary history (step S209). That is, the transaction issuing unit 201 of the administrator terminal 22 issues a transaction specifying the UpdateSupplementalHistory method and its arguments (that is, for example, a correct supplementary history information list and a transfer path list).

[0247] Next, the transaction issuing unit 201 of the administrator terminal 22 transmits the transaction issued in step S209 above to a certain node 10 (for example, a node 10 predetermined for the administrator terminal 22) (step S210).

[0248] When the transaction execution unit 101 of the node 10 receives the transaction, it executes this transaction (step S211). That is, the transaction execution unit 101 of the node 10 executes the UpdateSupplementalHistory method specifying the arguments specified in the received transaction. As a result, the supplementary history is updated and a Notice event is issued. In this case, it is executed again from step S205 above.

[0249] Note that the event information of the transaction executed in steps S204, S208, and S211 above and the event issued during the execution of the method that realizes the transaction is recorded in the block constituting the distributed ledger.

[0250] As described above, in the logistics management system 1 according to the second embodiment, even when a recording omission of the occupancy transfer occurs, the administrator can record the occupancy transfer on behalf. Also, at this time, by having the occupant (related person) after the recording omission approve the occupancy transfer (special occupancy transfer) by the administrator, the reliability of the special occupancy transfer can be enhanced.

[0251] [Third Embodiment] Next, a third embodiment will be described. The third embodiment may be based on only the first embodiment or both the first and second embodiments. Hereinafter, it will be mainly described based on both the first and second embodiments.

[0252] <Possession transfer history> In the logistics management system 1 according to the above first or second embodiment, although the possession transfer of the object to be tracked can be managed on the BC, for example, there is a parent-child relationship between tokens, and reuse of token IDs and special possession transfers by administrators can be performed. Therefore, when creating a possession transfer history, it is necessary to consider these. This is because the token storage information is only a history for each token on the BC, and an accurate possession transfer history cannot be obtained without considering the parent-child relationship between tokens, the reuse of token IDs, special possession transfers by administrators, etc. Therefore, hereinafter, a case of creating a possession transfer history considering the parent-child relationship between tokens, the reuse of token IDs, special possession transfers by administrators, etc., and visualizing this possession transfer will be described.

[0253] <Overall configuration example of the logistics management system 1> Hereinafter, a logistics management system 1 that can create a possession transfer history considering the parent-child relationship between tokens, the reuse of token IDs, special possession transfers by administrators, etc., and visualize this possession transfer will be described. An overall configuration example of the logistics management system 1 according to the third embodiment is shown in FIG. 13. As shown in FIG. 13, the logistics management system 1 according to the third embodiment includes a plurality of nodes 10, a plurality of terminals 20, and a database server 30. The database server 30 is communicably connected to the nodes 10 and the terminals 20 via a communication network including, for example, an inter-enterprise network.

[0254] The database server 30 is a general-purpose server, PC, etc. that creates and manages an occupancy transfer history considering the parent-child relationship between tokens, reuse of token IDs, special occupancy transfers by administrators, etc. The database server 30 creates an occupancy transfer history using the token storage information, event information, etc. obtained from the node 10, and provides the occupancy transfer history in response to a request from the terminal 20.

[0255] Note that the overall configuration example of the logistics management system 1 shown in FIG. 13 is merely an example and is not limited thereto. For example, one or more of the plurality of terminals 20 may function as the database server 30.

[0256] <Functional configuration examples of the node 10, terminal 20, and database server 30 included in the logistics management system 1> Hereinafter, functional configuration examples of the node 10, terminal 20, and database server 30 included in the logistics management system 1 according to the third embodiment will be described. Note that the functional configuration example of the node 10 may be the same as that in the first or second embodiment, and thus the description thereof will be omitted.

[0257] ≪Terminal 20≫ A functional configuration example of the terminal 20 according to the third embodiment is shown in FIG. 14. As shown in FIG. 14, the terminal 20 according to the third embodiment has a visualization unit 205 in addition to each unit described in the second embodiment. The visualization unit 205 is realized, for example, by a process executed by a processor such as a CPU for one or more programs installed in the terminal 20.

[0258] The visualization unit 205 requests the database server 30 for the occupancy transfer history of the token having the token ID designated as the visualization target, and visualizes the occupancy transfer history provided from the database server 30 on a display device such as a display in response to this request.

[0259] ≪Database server 30≫ Fig. 15 shows a functional configuration example of the database server 30 according to the third embodiment. As shown in Fig. 15, the database server 30 according to the third embodiment includes an occupancy transfer history creation unit 301 and an occupancy transfer history providing unit 302. Each of these units is realized, for example, by a process in which one or more programs installed in the database server 30 are executed by a processor such as a CPU. The database server 30 according to the third embodiment also has an occupancy transfer history DB 303. The occupancy transfer history DB 303 is realized by an auxiliary storage device such as an HDD, an SSD, or a flash memory, for example.

[0260] The occupancy transfer history creation unit 301 creates an occupancy transfer history of a certain token ID (for example, an occupancy transfer history considering the parent-child relationship between tokens, the reuse of the token ID, special occupancy transfer by the administrator, etc.) using the token storage information, event information, etc. acquired from the BC. The occupancy transfer history creation unit 301 also stores the created occupancy transfer history in the occupancy transfer history DB 303. Here, the occupancy transfer history creation unit 301 creates an occupancy transfer history of each token ID to be the target of history creation, for example, every predetermined period (for example, one day, etc.). Note that the token IDs to be the target of history creation may be, for example, all token IDs, or may be a predetermined part of the token IDs, or may be the token IDs of the tokens associated with a predetermined tracking target.

[0261] The occupancy transfer history providing unit 302 provides the occupancy transfer history of the token ID specified in this request to the terminal 20 in response to a request from the terminal 20.

[0262] The occupancy transfer history DB 303 stores the occupancy transfer history created by the occupancy transfer history creation unit 301.

[0263] <Occupancy transfer history creation process> Hereinafter, as an example, it is assumed that the token with the token ID "T01" has a parent-child relationship and an event occurrence history as shown in FIG. 16. That is, it is assumed that the token with the token ID "T01" has a three-layer parent-child relationship, and token ID reuse and special possession transfer by the administrator have occurred. At this time, the process flow when creating the possession transfer history of the token ID "T01" will be described with reference to FIG. 17.

[0264] The possession transfer history creation unit 301 of the database server 30 acquires event information regarding the token ID for which history creation is to be performed (here, as an example, the token ID "T01") from BC, adds each event information as an element (record) to a list called eventInfoList, and then sorts the elements of eventInfoList in ascending order with the block number (blockNo) as the first sort key and the log order (logIndex) as the second sort key (step S301).

[0265] By the above step S301, for example, the following eventInfoList can be obtained.

[0266] eventInfoList = {blockNo: 100, event: Mint, logIndex: 0, ···}, {blockNo: 120, event: Packed, logIndex: 0, ···}, {blockNo: 150, event: Unpacked, logIndex: 0, ···}, {blockNo: 160, event: Approve, logIndex: 0, ···}, {blockNo: 170, event: Transfer, logIndex: 0, ···}, {blockNo: 180, event: Packed, logIndex: 1, ···}, {blockNo: 240, event: Burn, logIndex: 0, ···}, {blockNo:250, event: Mint, logIndex: 0, ···}, {blockNo:260, event: Burn, logIndex: 0, ···}] Here, the log order (logIndex) represents the order in which events are issued within a block. Note that in addition to the block number (blockNo), event name (event), and log order (logIndex), event information may include various other information such as the transaction issuer and operation type. However, only the necessary information is described above, and the rest is omitted.

[0267] Next, the occupancy transfer history creation unit 301 of the database server 30 acquires the token storage information of the token ID "T01" at the block number included in each element (event information) of the eventInfoList from BC, and adds the event information and the token storage information together as an element of a list called tokenHistoryList (step S302).

[0268] By the above step S302, for example, the following tokenHistoryList can be obtained.

[0269] tokenHistoryList = {blockNo:100, event: Mint, logIndex: 0, ···, tokenInfo:{···}}, {blockNo:120, event: Packed, logIndex: 0, ···, tokenInfo:{···}}, {blockNo:150, event: Unpacked, logIndex: 0, ···, tokenInfo:{···}}, {blockNo:160, event: Approve, logIndex: 0, ···, tokenInfo:{···}}, {blockNo:170, event: Transfer, logIndex: 0, ···, tokenInfo:{···}}, {blockNo:180, event: Packed, logIndex: 1, ···, tokenInfo: {···}}, {blockNo:240, event: Burn, logIndex: 0, ···, tokenInfo: {···}}, {blockNo:250, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo:260, event: Burn, logIndex: 0, ···, tokenInfo: {···}}] Here, tokenInfo represents token storage information.

[0270] Next, the occupancy transfer history creation unit 301 of the database server 30 creates data called a set list from each element of the eventInfoList, and adds these set lists as elements of a list called the eventFilterList (step S303). The set list is data composed of the token ID of the parent token at the time of issuing the Packed event, the block number and log order at the time of issuing the Packed event, and the block number and log order at the time of issuing the Unpacked or Burn event.

[0271] Here, the occupancy transfer history creation unit 301 creates a set list by the following Step101.

[0272] Step101) Repeat the following Step101-1 to Step101-4 for each element (event information) included in the eventInfoList.

[0273] Step101-1) If the event included in the element is "Packed", proceed to the next Step101-2; otherwise, skip Step101-2 to Step101-4 for the element.

[0274] Step101-2) Set the block number of the element (event information where the event is "Packed") to fromBlockNo and the log order to fromLogIndex.

[0275] Step101-3) In eventInfoList, set the block number of the nearest element that exists after the element (event information where the event is "Packed") and where the event is "Unpacked" or "Burn" to toBlockNo and the log order to toLogIndex. However, if there is no element where the event is "Unpacked" or "Burn" after the element (event information where the event is "Packed"), set the latest block number to toBlockNo and a predetermined maximum value (for example, the maximum value of an integer in the implementation program) to toLogIndex.

[0276] Step101-4) Then, for fromBlockNo, fromLogIndex, toBlockNo, and toLogIndex, associate the token ID of the parent token (the parent token of the token with token ID "T01") at the block number time point of the element (event information where the event is "Packed") as parentTokenId. As a result, a set list in the form of (parentTokenId, fromBlockNo, fromLogIndex, toBlockNo, toLogIndex) is created.

[0277] By the above step S303, for example, the following eventFilterList is obtained.

[0278] eventFilterList = {parentTokenId:T02,fromBlockNo:120,fromLogIndex:0,toBlockNo:150,toLogIndex:0}, {parentTokenId:T02,fromBlockNo:180,fromLogIndex:1,toBlockNo:240,toLogIndex:0}] Next, when the occupancy transfer history creation unit 301 of the database server 30 determines that the length of the eventFilterList (i.e., the number of elements (set lists) included in the eventFilterList) is greater than 0, it updates the tokenHistoryList according to the following Step 111 to Step 112 using the eventFilterList (step S304). When the length of the eventFilterList is 0, Steps 111 to 112 below are skipped, and the process proceeds to the next step S305.

[0279] Step 111) Repeat the following Step 111-1 to Step 111-3 for each element (set list) included in the eventFilterList.

[0280] Step 111-1) Recursively obtain the token storage information of the token ID set in the parentTokenId included in the element (set list) from the BC, and obtain the token ID of the topmost parent token.

[0281] As a result, for example, when the element (set list) is {parentTokenId:T02,fromBlockNo:120,fromLogIndex:0,toBlockNo:150,toLogIndex:0}, the token ID "T03" is obtained. Also, for example, when the element (set list) is {parentTokenId:T02,fromBlockNo:180,fromLogIndex:1,toBlockNo:240,toLogIndex:0}, the token ID "T02" is obtained.

[0282] Step111-2) Under the following conditions, obtain the event information of the top parent token (i.e., the top parent token ID when recursively obtaining the parent token ID in Step111-1 above), add this event information as an element of the eventInfoList that has been initialized (cleared within the list), and then sort the elements of the eventInfoList in ascending order with the block number (blockNo) as the first sort key and the log order (logIndex) as the second sort key.

[0283] Conditions: · Token ID: The token ID obtained in Step111-1 · Range of block numbers: Equal to or greater than the block number set in fromBlockNo included in the element (set list), and equal to or less than the block number set in toBlock · Event name: Approve, Transfer, Confirm, Notice, Packed, or Unpacked However, if the event information is one of the following A or B, do not add it to the eventInfoList.

[0284] A: The block number included in the event information is the same as the block number set in fromBlockNo, and the log order included in the event information is smaller than the log order set in FromLogIndex B: The block number included in the event information is the same as the block number set in toBlockNo, and the log order included in the event information is greater than the log order set in toLogIndex According to the above A and B, even for the same block, it is possible to add appropriate event information to the eventInfoList according to the magnitude of the log order.

[0285] By the above Step111-2, for example, when the set list is {parentTokenId:T02,fromBlockNo:120,fromLogIndex:0,toBlockNo:150,toLogIndex:0}, the following eventInfoList can be obtained.

[0286] eventInfoList= {blockNo:130,event:Approve,logIndex:0,···}, {blockNo:140,event:Transfer,logIndex:0,···}] Also, for example, when the set list is {parentTokenId:T02,fromBlockNo:180,fromLogIndex:1,toBlockNo:240,toLogIndex:0}, the following eventInfoList can be obtained.

[0287] eventInfoList= {blockNo:190,event:Approve,logIndex:0,···}, {blockNo:200,event:Transfer,logIndex:0,···}, {blockNo:210,event:Packed,logIndex:1,···}] Hereinafter, the above two eventInfoLists will be respectively referred to as the "first eventInfoList" and the "second eventInfoList".

[0288] Step111-3) Regarding each element (event information) of the eventInfoList obtained in the above Step111-2, when the event name included in the element is Approve, Transfer, Notice or Confirm, the following (1) is executed. On the other hand, when the event name included in the element is Packed, the following (2) is executed, and when it is Unpacked, the following (3) is executed.

[0289] (1) Obtain the token storage information of token ID "T01" at the block number time point included in the element (event information) from BC, add the event information and the token storage information together to tokenHistoryList, and sort each element included in tokenHistoryList in ascending order with the block number (blockNo) as the first sort key and the log order (logIndex) as the second sort key.

[0290] (2) Create a set list from the element (event information), and add this set list as an element of a list called parentFilterList. The set list is created according to the following (2-1) to (2-3).

[0291] (2-1) Set the block number of the element (event information) to fromBlockNo and the log order to fromLogIndex.

[0292] (2-2) Set the block number of the nearest element that exists after the element (event information) in eventInfoList and has an event of "Unpacked" to toBlockNo and the log order to toLogIndex. However, if there is no element with an event of "Unpacked" after the element (event information with an event of "Packed"), set toBlockNo and toLogIndex to the toBlockNo and toLogIndex of the element (set list) of eventFilterList used in the repetition of Step111-1 to Step111-3, respectively.

[0293] (2-3) Then, for fromBlockNo, fromLogIndex, toBlockNo, and toLogIndex, associate the token ID of the parent token at the block number time point of the element (event information where event is "Packed") as parentTokenId. As a result, a set list in the form of (parentTokenId, fromBlockNo, fromLogIndex, toBlockNo, toLogIndex) is created.

[0294] For example, for the element {blockNo: 210, event: Packed, logIndex: 0, ···} included in the second eventInfoList, the following parentFilterList is obtained.

[0295] parentFilterList = {parentTokenId: T03, fromBlockNo: 210, fromLogIndex: 0, toBlockNo: 240, toLogIndex: 1}] (3) Skip the element (do nothing).

[0296] When the above Step111-3 is executed for the first eventInfoList and the second eventInfoList, for example, the following tokenHistoryList is obtained.

[0297] tokenHistoryList = {blockNo: 100, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 120, event: Packed, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 130, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 140, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 150, event: Unpacked, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 160, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 170, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 180, event: Packed, logIndex: 1, ···, tokenInfo: {···}}, {blockNo: 190, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 200, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 240, event: Burn, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 250, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 260, event: Burn, logIndex: 0, ···, tokenInfo: {···}}] Step 112) If the length of the parentFilterList (i.e., the number of elements (set lists) included in the parentFilterList) is greater than 0, overwrite and update the eventFilterList with the parentFilterList and then return to Step 111 above. On the other hand, if the length of the parentFilterList is 0, proceed to the next step S305.

[0298] By the above step S304, for example, the following tokenHistoryList is finally obtained.

[0299] tokenHistoryList= {blockNo: 100, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 120, event: Packed, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 130, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 140, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 150, event: Unpacked, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 160, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 170, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 180, event: Packed, logIndex: 1, ···, tokenInfo: {···}}, {blockNo: 190, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 200, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 220, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 220, event: Notice, logIndex: 1, ···, tokenInfo: {···}}, {blockNo: 230, event: Confirm, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 240, event: Burn, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 250, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 260, event: Burn, logIndex: 0, ···, tokenInfo: {···}}] Finally, the occupancy transfer history creation unit 301 of the database server 30 divides the elements of the tokenHistoryList obtained in step S304 above, with the elements from the event name "Mint" to the element of "Burn" as one set (step S305). This is because the period from the issuance of the Mint event to the issuance of the Burn event is one life cycle, and by dividing in units of this life cycle, the life cycle of the token can be made explicit. The tokenHistoryList obtained in this step is the occupancy transfer history (in this specific example, the occupancy transfer history of the token ID "T01"), and this occupancy transfer history is associated with the token ID and stored in the occupancy transfer history DB 303.

[0300] By step S305 above, for example, the following tokenHistoryList is obtained.

[0301] tokenHistoryList = [{blockNo: 100, event: Mint, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 120, event: Packed, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 130, event: Approve, logIndex: 0, ···, tokenInfo: {···}}, {blockNo: 140, event: Transfer, logIndex: 0, ···, tokenInfo: {···}}, {blockNo:150, event: Unpacked, logIndex:0, ···, tokenInfo:{···}}, {blockNo:160, event: Approve, logIndex:0, ···, tokenInfo:{···}}, {blockNo:170, event: Transfer, logIndex:0, ···, tokenInfo:{···}}, {blockNo:180, event: Packed, logIndex:1, ···, tokenInfo:{···}}, {blockNo:190, event: Approve, logIndex:0, ···, tokenInfo:{···}}, {blockNo:200, event: Transfer, logIndex:0, ···, tokenInfo:{···}}, {blockNo:220, event: Transfer, logIndex:0, ···, tokenInfo:{···}}, {blockNo:220, event: Notice, logIndex:1, ···, tokenInfo:{···}}, {blockNo:230, event: Confirm, logIndex:0, ···, tokenInfo:{···}}, {blockNo:240, event: Burn, logIndex:0, ···, tokenInfo:{···}}], [{blockNo:250, event: Mint, logIndex:0, ···, tokenInfo:{···}}, {blockNo:260, event: Burn, logIndex:0, ···, tokenInfo:{···}}]] In the above example, it is divided into two parts: block numbers from "100" to "240" and block numbers from "250" to "260".

[0302] In the above example, a transfer history is created considering the parent-child relationship between tokens, the reuse of token IDs, and special transfer of ownership by the administrator. However, it goes without saying that even if, for example, the reuse of token IDs or the special transfer of ownership by the administrator is not performed, it is similarly possible to create a transfer history.

[0303] <Transfer history visualization processing> The following describes the process flow when visualizing the transfer history on a display device such as the display of terminal 20 with reference to FIG. 18.

[0304] The visualization unit 205 of terminal 20 accepts the specification of the token ID to be visualized (step S401). Note that the token ID to be visualized is specified by, for example, the user (user or administrator) who uses the terminal 20.

[0305] The visualization unit 205 of terminal 20 transmits a transfer history acquisition request including the token ID specified in step S401 above to the database server 30 (step S402).

[0306] When the transfer history providing unit 302 of the database server 30 receives the transfer history acquisition request, it acquires the transfer history associated with the token ID included in this transfer history acquisition request from the transfer history DB 303 (step S403).

[0307] The transfer history providing unit 302 of the database server 30 returns the transfer history acquired in step S403 above to the terminal 20 (step S404).

[0308] The visualization unit 205 of the terminal 20 visualizes the occupancy transfer history returned from the database server 30 on a display device such as a display (step S405). As a result, regarding the token having the token ID to be visualized, it is possible to visualize the occupancy transfer history in consideration of the parent-child relationship between tokens, the reuse of the token ID, special occupancy transfer by the administrator, etc. For this reason, since event information and token storage information can be confirmed from this occupancy transfer history, it becomes possible to know when, from where, and to where the occupancy of the tracking target associated with the token has been transferred. In addition, since information on other tokens in a parent-child relationship with the token can be easily confirmed, for example, when the token is associated with an article, information on the container or pallet that transported the article can be confirmed. Or, for example, when the token is associated with a container, information on a larger container that transported the container can be confirmed.

[0309] [Hardware Configuration Example] The node 10, the terminal 20, and the database server 30 described in each of the above embodiments can be realized by, for example, the hardware configuration of a computer 500 shown in FIG. 19. The computer 500 shown in FIG. 19 includes an input device 501, a display device 502, an external I / F 503, a communication I / F 504, a RAM (Random Access Memory) 505, a ROM (Read Only Memory) 506, an auxiliary storage device 507, and a processor 508. Further, these pieces of hardware are communicably connected to each other via a bus 509.

[0310] The input device 501 is, for example, a keyboard, a mouse, a touch panel, a physical button, or the like. The display device 502 is, for example, a display, a display panel, or the like. Note that the computer 500 may not have at least one of the input device 501 and the display device 502, for example.

[0311] The external I / F 503 is an interface with an external device such as a recording medium 503a. The computer 500 can read from and write to the recording medium 503a via the external I / F 503. Examples of the recording medium 503a include a flexible disk, a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), a USB (Universal Serial Bus) memory card, and the like.

[0312] The communication I / F 504 is an interface for the computer 500 to connect to a communication network or the like. The RAM 505 is a volatile semiconductor memory (storage device) that temporarily holds programs and data. The ROM 506 is a non-volatile semiconductor memory (storage device) that can hold programs and data even when the power is turned off. The auxiliary storage device 507 is a storage device (storage device) such as an HDD, an SSD, or a flash memory, for example. The processor 508 is an arithmetic device such as a CPU or a GPU.

[0313] The node 10, the terminal 20, and the database server 30 described in the above embodiments can realize the various processes described above by having, for example, the hardware configuration of the computer 500 shown in FIG. 19. Note that the hardware configuration of the computer 500 shown in FIG. 19 is an example and is not limited thereto. For example, the computer 500 may have a plurality of auxiliary storage devices 507 and a plurality of processors 508, may not have a part of the illustrated hardware, or may have various hardware other than the illustrated hardware.

[0314] The present invention is not limited to the specifically disclosed above embodiments, and various modifications, changes, combinations with known technologies, etc. are possible without departing from the scope of the claims.

Explanation of Signs

[0315] 1 Logistics management system 10 Nodes 20 Terminals 30 Database Servers 101 Transaction Execution Unit 102 Memory Unit 201 Transaction Issuance Unit 202 Memory Unit 203 Proxy Request Unit for Possession Transfer 204 Supplementary History List Acquisition Unit 205 Visualization Unit 301 Possession Transfer History Creation Unit 302 Possession Transfer History Provision Unit 303 Possession Transfer History DB 500 Computers 501 Input Devices 502 Display Devices 503 External I / F 503a Recording Media 504 Communication I / F 505 RAM 506 ROM 507 Auxiliary Storage Devices 508 Processors 509 Buses

Claims

1. A transfer management system for managing the transfer of possession of an object, comprising: a blockchain in which tokens associated with the object are recorded as children and tokens associated with a management unit in the case of performing possession transfer of one or more objects are recorded as parents, and the tokens have a parent-child relationship that can be mutually referenced; a transaction issuing unit configured to issue a possession transfer transaction for transferring the possession of the object to the blockchain, wherein the token includes a token ID for associating the object or the management unit with the token, a token ID of a parent token representing the parent of the token, possessor information representing the possessor of the object or the management unit associated with the token, a list of token IDs of child tokens representing the children of the token, and a token type indicating whether the token is associated with an object or a management unit; the possession transfer transaction is as follows: when the token ID of the parent token is not included in the token associated with the management unit, the possessor information included in the token associated with the management unit is changed to the possessor information after the transfer, and the possession transfer of the token associated with the management unit is recorded on the blockchain, thereby transferring the possession of the object associated with the child token of the token associated with the management unit. A transfer management system.

2. The transaction issuing unit is a token generation transaction for generating a token associated with the object or the management unit, a possession transfer permission transaction for setting one or more addresses permitted as the possession transfer destination of the token associated with the management unit in the token, a parent-child relationship association transaction for associating, as child tokens, one or more tokens associated with each of the one or more objects for which possession transfer is performed in the management unit with the token associated with the management unit, a parent-child relationship association release transaction for releasing the association between the token associated with the management unit and one or more child tokens associated as children with the token, configured to further issue at least one of a token amortization transaction for amortizing the token associated with the object or the management unit. The transfer management system according to claim 1.

3. The token generation transaction is The transfer management system according to claim 2, wherein when the token ID for identifying the token to be generated is unused, or when the token ID for identifying the token to be generated is the token ID of a token amortized by the token amortization transaction, the token to be generated is generated.

4. The transaction issuing unit The transfer management system according to claim 1, wherein when there is a recording omission of the transfer of possession on the blockchain, the special transfer of possession transaction for recording the transfer of possession where the recording omission has occurred on the blockchain with administrator authority is included.

5. The transaction issuing unit The transfer management system according to claim 4, wherein the transfer of possession recorded by the special transfer of possession transaction includes a history approval transaction for approving the transfer of possession to the user who should have recorded the transfer of possession.

6. A creation unit configured to obtain information about a token having a token ID that is a target for creating a transfer of possession history representing the history of the transfer of possession from the blockchain, and create a transfer of possession history considering at least the parent-child relationship between the token having the token ID and other tokens using the obtained information about the token. The transfer management system according to any one of claims 1 to 5.

7. A transfer management system for managing the transfer of possession of an object Executes a transaction issuing procedure for issuing a transfer of possession transaction for transferring the possession of the object to a blockchain in which tokens having a parent-child relationship that can be mutually referenced are recorded, with the token associated with the object as the child and the token associated with the management unit in the case of performing the transfer of possession of one or more objects as the parent. The token includes a token ID for associating the object or management unit with the token, a token ID of the parent token representing the parent of the token, possessor information representing the possessor of the object or management unit associated with the token, a list of token IDs of child tokens representing the children of the token, and a token type indicating whether the token is associated with an object or a management unit. The transfer of possession transaction When the token associated with the management unit does not contain the token ID of the parent token, change the possessor information contained in the token associated with the management unit to the possessor information after transfer, and record the transfer of possession of the token associated with the management unit in the blockchain, so as to transfer the possession of the object associated with the child token of the token associated with the management unit. A transfer management method.

8. In a transfer management system for managing the transfer of possession of an object, For a blockchain in which tokens associated with objects are recorded as children and tokens associated with management units in the case of transferring the possession of one or more objects are recorded as parents and have a parent-child relationship that can be mutually referenced, execute a transaction issuance procedure for issuing a possession transfer transaction for transferring the possession of the object, The token includes a token ID for associating an object or a management unit with the token, a token ID of a parent token representing the parent of the token, possessor information representing the possessor of the object or management unit associated with the token, a list of token IDs of child tokens representing the children of the token, and a token type indicating whether the token is associated with an object or a management unit. The possession transfer transaction is When the token associated with the management unit does not contain the token ID of the parent token, change the possessor information contained in the token associated with the management unit to the possessor information after transfer, and record the transfer of possession of the token associated with the management unit in the blockchain, so as to transfer the possession of the object associated with the child token of the token associated with the management unit. A program.

Images