Transfer management method, program, and data structure

Abstract

To provide a technique that can manage the transfer of occupation of goods on a blockchain using data with hierarchical structure in which cross-reference can be made.SOLUTION: A transfer management system according to one aspect of the present disclosure is a transfer management method for managing the transfer of occupation of an object, in which a computer capable of communicating with a blockchain, in which tokens are recorded having a parent-child relationship that can be cross-referenced setting a token associated with the object as a child and a token associated with a management unit when the transfer of occupation of one or more objects is made as a parent, executes a transaction issuance procedure to issue a transaction for realizing management of the transfer of occupation of the object to the blockchain.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to a transfer management method, program, and data structure.

Background Art

[0002] In recent years, in the field of 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 defects in certain articles such as goods and products. The possession transfer history is, for example, a record of what has moved, when, and from where to where 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 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.

[0007] In view of the above points, the present disclosure aims to provide a technology capable of managing the transfer of possession of an article on a blockchain with a hierarchically structured data 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 method for managing the transfer of possession of an object, and a computer communicable with a blockchain on which tokens having a parent-child relationship that can be mutually referred to are recorded, with the token associated with the object as the child and the token associated with the management unit in the case of transferring the possession of one or more objects as the parent, executes a transaction issuance procedure for issuing a transaction for realizing the management of the transfer of possession of the object to the blockchain, and the transaction includes a token generation transaction for generating a token associated with the object or the management unit, and a possession transfer transaction for realizing the transfer of possession of one or more objects in the management unit by recording the transfer of possession of the token associated with the management unit on the blockchain, and 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 to the token, and 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 the possession transfer is performed in the management unit with the token associated with the management unit, and 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, and a token amortization transaction for amortizing the token associated with the object or the management unit, and includes at least one of them.

Effects of the Invention

[0009] A technique is provided that can manage the transfer of possession of an article on a blockchain using data with a hierarchically referable structure.

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

Mode 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 an object to be controlled and managed such as a space under their control and management that temporarily or non-temporarily controls and manages a physical object (thing (tangible thing)) or a service (intangible thing (intangible thing) such as a license or electronic content). It should be noted that in this embodiment, a space that temporarily or non-temporarily controls and manages a commodity is also included in the occupant.

[0014] Specific examples of possessors include, for example, transport vehicles such as trucks that can transport goods by means of a loading platform or the like, trains that can transport goods, warehouses and factories that can store goods, stores that sell goods, etc. Note that a single truck, a single train, a single warehouse, a single store, etc. may include a plurality of possessors. For example, when there are a plurality of rooms in a warehouse, each of the rooms may be regarded as a single possessor, or a predetermined two or more rooms may be regarded as a single possessor. Similarly, when there are a plurality of floors in a warehouse, each of the floors may be regarded as a single possessor, or a predetermined two or more floors may be regarded as a single possessor. The same applies when a transport vehicle is equipped with a plurality of loading platforms or when a train is composed of a plurality of vehicles.

[0015] <Transport of Goods in Logistics> When transporting goods such as commodities and products in logistics, it is common to store them in containers in units of cases containing a plurality of goods and transport them, or to place them on pallets and transport them. For example, as shown in FIG. 1, cases containing goods shipped from a manufacturer are stored in containers 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 pallets 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 pallets are transported to the store in units of cases.

[0016] Thus, when transporting goods in logistics, the cases are stored in relatively large-capacity containers or the like and shipped. After that, at intermediate logistics bases, they are stacked on pallets according to the destination, or the cases are transferred between pallets, and finally, they are generally transported to the store in units of cases. Therefore, while transporting goods in units of containers or pallets, the number of transactions can be suppressed by recording the transfer of possession in units of containers or pallets instead of in units of cases. That is, while transporting goods in units of containers or pallets, 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 that are transported or managed together and for which the transfer of possession is performed in units of containers or pallets 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 also be a parent-child relationship between the container and the pallet and between the pallet and the cases. That is, there is a parent-child relationship between the object being transported in logistics and the transport containers such as the 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 a parent exists for that object, the number of transactions can be suppressed by recording the transfer of possession in units 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, transportation 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 each time a parent-child relationship is associated or disassembled, a transaction needs to be issued, which may require a large number of transactions.

[0020] For this reason, for example, as shown in FIG. 2, when Manufacturer A stores 4 cases in 1 container, a total of 4 transactions are required to issue transactions for associating the container token as the parent and the case tokens as the children. The same applies to Manufacturer B.

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

[0022] Also, for example, as shown in FIG. 2, when transporting a container or a pallet from the central warehouse to a regional warehouse, even if it is 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 carried out in units of the parent token. On the other hand, the parent token and the child tokens cannot be mutually referable, and when associating and disassociating the parent-child relationship, a transaction needs to be issued for each child token. Furthermore, even when a plurality of parent tokens are transferred in possession to the same possessor, a transaction needs to be issued for the transfer of possession of each of those 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, since the parent token and the child tokens cannot be mutually referable and the child tokens cannot refer to the parent token, for example, when confirming information regarding the transfer of possession of a certain item, the container that transported the item cannot be identified. Therefore, 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 a BC aimed at ensuring logistics traceability, it is often constructed as a consortium network or a private network of multiple companies. Therefore, in a BC aimed at ensuring logistics traceability, there will be no inconvenience regarding non-compliance with the ERC721 and ERC998 standards.

[0025] <Proposed Method> When using this proposed method, information (such as information regarding the transfer of possession) of another entity in a parent-child relationship with a certain entity can be easily confirmed. 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 carried out 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 container token as the parent and the case tokens 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 a regional warehouse, if the destination is the same, multiple transfers of possession can be performed in one transaction.

[0028] Define a token data structure and a contract method (hereinafter also simply referred to as "method") for realizing the above-mentioned association / dissociation of the parent-child relationship and transfer of possession.

[0029] <<Token Data Structure>> Hereinafter, for example, define the data structure of a token associated with an article, a case containing one or more articles, a transport container, etc. Hereinafter, the article itself, a case containing one or more articles, etc. will be collectively referred to as "article". Note that tokens and real existing articles and transport containers can be associated 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 by a token ID described later using an ID (identifier) etc. given to the object.

[0030] A token is a collection of properties (attributes) that can be uniquely identified by a token ID, and has "token ID", "parent token ID", "list of child token IDs", "list of transfer permission destinations", and "token type" as properties. 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, for the Token ID property, an ID (Token ID) that uniquely identifies the token is set. For 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 (e.g., "", NULL, etc.) is set. For 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. For 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. For the List of Transfer Permitted Destinations property, a list of the BC addresses that the current owner of the token has permitted as transfer destinations (however, if there are no BC addresses permitted by the current owner as transfer destinations, an empty array) is set. For 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 for setting meta information that supplements its properties. Note that in addition to these properties, the token may have various other properties.

[0032] ·Regarding the parent-child relationship The parent-child relationship is represented by associating 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 FIG. 4. Note that in the example shown in FIG. 4, only some properties (Token ID, Owner, Parent Token ID, and List of Child Token IDs) are illustrated for simplicity.

[0033] As shown in FIG. 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 refer 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 transfer of possession Transfer of possession 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, transfer of possession is carried out 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 transfer of possession of the parent token is carried out, the value "0" remains set in the possessor property of its child tokens. This is because the possessor of the child tokens is also represented by the possessor property of the parent token.

[0036] ·Regarding token type There are package tokens and item tokens as token types. It is assumed 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 (such as a container or 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, generation and amortization may be performed 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 possessor. 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, etc.

[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 along with the 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 some 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, if 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 in the process of explaining 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, execute the following Step11~Step12.

[0048] Step11) Register a token with the possessor and token type specified as arguments, associated with the token ID included in the element, as properties. 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. This generates a token. 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 indicating 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 was 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 to 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 having the token IDs of the child tokens to be associated as elements.

[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 owner property of the token pointed to by the parent token ID specified as an argument. b: The owner property of the token pointed to by the parent token ID specified as an argument is identical to the owner property of 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 the transfer permission destination list property of the token is set to something other than an empty array, clear the transfer permission destination list property (that is, set an empty array in the transfer permission 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 child token ID list specified as an argument to the child token ID list 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 with the new child token associated, the owner (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 of child token ID properties of 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: "", owner: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T02", parent token ID: "", owner: 0x111, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T03", parent token ID: "", owner: 0x111, 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: [], 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 gives permission to transfer the 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 set to a list of elements composed of a list of transfer permission destination BC addresses, which is a list having as elements the token ID to be permitted for transfer and the BC address 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 to 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 when 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 within the method whether the following conditions are met. If any of the conditions are not met, an error occurs.

[0076] a: The token ID of each element of 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 of the transfer permission information list specified as an argument is an empty string. Note that the second of the above conditions is a necessary condition for transfer of ownership to occur 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 of 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 transfer of ownership permission has been given to a certain token. The Approve event includes, for example, the token ID of the token to which transfer of ownership permission has been given, 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 one 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 as elements the token IDs of the tokens to be subject to the transfer of possession 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 Process: 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 that 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 transfer target token IDs = ["T04", "T05"] Transfer 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. Also, 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 the Unpack 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.

[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 a child token and its 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 that represents the dissociation of the association with one or more child tokens. The Unpack event includes, for example, the token ID of the parent token whose association with one or more child tokens has been dissociated, the possessor (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", possessor: 0x0, list of child token IDs: [], list of transfer permission destinations: [], token type: 1 (item token)} {token ID: "T02", parent token ID: "T04", possessor: 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 having 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 token issuer is identical to the possessor 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 topmost parent token's possessor property recursively obtained by the parent token ID property is identical to the transaction issuer). 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 to 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 to 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 possessor 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 to 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) If the token type property of the parent token is "0" (package token) and the child token ID list property of the parent token is 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 was 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 items, transport containers, etc. exist on the BC (i.e., from the generation to the amortization of the token). This is because the token ID uniquely associates the actual object (e.g., an item or a transport container) 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 objects 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 identifiers such as RFID tags and QR codes for identifying articles, transport containers, etc. that are the management targets 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 in 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≫ The package token is associated with a transport container or the like and is assumed to be reused multiple times in the logistics supply chain. At this time, when managing the transfer of possession across multiple transport sections, a situation where operational handling becomes difficult is assumed. 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 since the possessor of the pallet remains as warehouse B on the BC, no operation can be performed on the token of the pallet at warehouse A on the BC. On the other hand, if the possessor 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 the package token is generated and amortized within one transport section, the number of token IDs of the package token 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 one transport section, and a token may be issued (generated) as belonging to a new possessor. 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, a token is automatically generated if it does not exist when the Pack method is executed, and the token is automatically amortized when the child tokens disappear in the Unpack method, so that the token ID associated with the package token can be automatically reused.

[0140] Also, the package token is used to transfer the possession of multiple tokens collectively. That is, the package token does not track its own transfer of possession. Therefore, when regenerating the package token, the RFID tag or QR code already attached to the transport 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. For this reason, 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 reattaching RFID tags and QR codes. In addition, by reusing the token ID, the possibility of the token ID being depleted 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 being 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 has ended, for example, it is necessary to keep the token's information on the BC in a state where it can be immediately retrieved for a certain period of time, such as to identify 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 among BC participants, etc.).

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

[0145] <Overall Configuration Example of Logistics Management System 1> Next, a logistics management system 1 that manages tracking targets (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 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.

[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. In addition, each node 10 has a distributed ledger shared among each other and has a smart contract in which the above-described 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., PC, smartphone, tablet terminal, wearable device, etc.) used by users who perform token generation, parent-child relationship association / dissociation, possession transfer permission, possession transfer, token amortization, etc. Hereinafter, when distinguishing each of the plurality of terminals 20, it is denoted as "terminal 20-1", "terminal 20-2", etc. In addition, the terminal 20 used by the user is denoted as "user terminal 21". This is for distinguishing 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 just an example and is not limited thereto. For example, in addition to the nodes 10 and the terminals 20, devices, equipment, etc. that realize some functions may be included in the logistics management system 1.

[0149] <Functional Configuration Example of Nodes 10 and Terminals 20 Included in 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"), and the like are recorded. Note that, in addition to the distributed ledger, the storage unit 102 may store various information necessary for token generation, association / dissociation of a parent-child relationship, permission for transfer of possession, transfer of possession, or burning of a token.

[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 includes 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 includes 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 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 Process> Hereinafter, the flow of a process for 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 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, the 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 block that constitutes 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., goods, etc.) in the 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. Also, it is possible to transfer the possession of children at a lower level than the parent unit in one transaction collectively. Further, 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 in the parent unit. Therefore, it is possible to easily refer to the information of another object that has a parent - child relationship with a certain object, reduce the number of issued transactions, and reduce the load (e.g., the workload of the operator due to transaction issuance, the network resource and server resource load required for verification and synchronization of each node on the blockchain, etc.) 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] <Recording omission of possession transfer> In the logistics supply chain, there may be a recording omission of possession transfer due to the operator's mistake. In this case, a divergence of the possessor will occur between the token on the BC and the actual item. On the other hand, the token on the BC cannot transfer its possession unless it is the possessor or a person who has been granted permission to transfer possession.

[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, regarding the token with the token ID "T01", it is assumed that user A has given user B permission to transfer possession (transaction issuer: A, possessor: A). After that, although user B should originally transfer possession to himself / herself and give user C permission to transfer possession, it is assumed that a recording omission of that transaction has occurred. At this time, even if user C issues a transaction for transferring possession to himself / herself, that transaction cannot be executed. This is because due to the above recording 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 recording of possession transfer on the BC, it is necessary to temporarily suspend the logistics of the item with the divergence of the possessor, and then, starting from the time when the recording omission of possession transfer occurred, each user should perform the possession transfer that should have been originally carried out, and record the transaction in the distributed ledger on the BC. However, the longer the period of recording omission, the more users (hereinafter also referred to as related parties) are involved, and as a result, the longer the time to suspend the logistics, so such a corrective measure is unrealistic. Therefore, hereinafter, a method by which the administrator can act on behalf of the possession transfer when a recording 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≫ It is assumed that there is at least a "user" with general authority and an "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 given administrator authority from 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 (owner property, transfer permission destination list property, etc.) of the token to be updated and restricts access (described in "a" of "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≫ As an operation type representing the type of the transaction issuer, "2" representing "administrator execution" is added. That is, the operation type is expressed as "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, and the block number of the block in which the transaction for performing a special transfer of possession described later is 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 transfer source of the transfer of possession (hereinafter also referred to as the transfer source BC address), the BC address of the transfer destination of the transfer of possession (hereinafter referred to as the transfer destination BC address), a transfer source approval category indicating whether the user having the transfer source BC address has approved the supplementary history, a transfer destination approval category indicating the approval status of the supplementary history of the user having the transfer destination BC address, etc. are set. It is assumed that the transfer source approval category and the transfer destination 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]=[{Transfer source BC address, Transfer destination BC address, Transfer source approval category, Transfer destination 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 the administrator substitutes for the transfer of possession, it is called "special transfer of possession", and a method for realizing a transaction for performing the special transfer of possession is defined. Also, a method for realizing a transaction for the related party to approve or deny the supplementary history (hereinafter, also referred to as "supplementary history approval"), and a method for realizing a transaction for the administrator to update the 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 to be subject to special transfer of possession as elements is set. In the transfer route list, a list storing the BC addresses of the possessors in the order of the original flow of possession transfer is set. For the reason, the cause of special transfer of possession is set as required.

[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, it will be an error.

[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 route 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 shall be "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 existence of the following tokens.

[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 path 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] = {Source BC Address: 0x111, Destination BC Address: 0x222, Source Approval Classification: 0 (Unapproved), Destination Approval Classification: 0 (Unapproved)}, {Source BC Address: 0x222, Destination BC Address: 0x333, Source Approval Classification: 0 (Unapproved), Destination Approval Classification: 0 (Unapproved)}] ≪Confirm Method≫ The Confirm method is a method for executing a transaction in which a related party 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 in the supplementary history list being 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) For each element of the supplementary history information list specified as an argument, repeat the following Step81-1 to Step81-3.

[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), and 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), and 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 providing 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 each of the transfer source user and the transfer destination user approving.

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

[0213] Here, the Confirm event is an event indicating that the supplementary history has been approved or denied. The Confirm event includes, for example, the token ID of the token to be approved or denied, 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 denied supplementary history from the top of the supplementary history list, the supplementary history transfer source representing the transfer source BC address of the approved or denied supplementary history, the supplementary history transfer destination representing the transfer destination BC address of the approved or denied supplementary history, and the supplementary history approval flag indicating whether the supplementary history has been approved or denied.

[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 (denial) In this case, the above supplementary history list map will be 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 administrative 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 Process: 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 a 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 a supplementary history 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] Step 91-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 becomes 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> For the overall configuration example of the logistics management system 1 that performs special occupancy transfer, supplementary history approval, and supplementary history update according to the above proposed method, it 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, in addition to each part described in the first embodiment, the terminal 20 according to the second embodiment includes an occupancy transfer agency request section 203 and a supplementary history list acquisition section 204. Each of these parts 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.

[0233] When the user of the terminal 20 wishes to have the occupancy transfer agency (that is, when the terminal 20 is the user terminal 21 of the user who wishes to have the occupancy transfer agency), the occupancy transfer agency request section 203 requests the administrator terminal 22 for the occupancy transfer agency.

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

[0235] <Special Occupancy Transfer, Supplementary History Approval, and Supplementary History Update Processing> Hereinafter, the processing flow for performing special occupancy transfer, supplementary history approval, and supplementary history update will be described with reference to FIG. 12. Hereinafter, the terminal 20 of the user who requests the occupancy transfer agency from the administrator 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-of-possession 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-of-possession agency request includes, for example, a token ID list, a transfer route list, and a reason specified as arguments of the SpecialTransfer method. Note that the transfer-of-possession agency request section 203 may make the transfer-of-possession agency request by a predetermined means (e.g., email, messaging application, etc.). However, this is just an example, and the transfer-of-possession 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 that specifies the SpecialTransfer method and its arguments (e.g., the token ID list, the transfer route list, and the reason included in the transfer-of-possession 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 the 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. Thereby, 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, a 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 specified with 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 list of supplementary history information 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 specified with 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 transfer of possession occurs, the administrator can record the transfer of possession on behalf. Also, at this time, by having the possessor (interested party) after the recording omission occur approve the transfer of possession (special transfer of possession) by the administrator, the reliability of the special transfer of possession 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 tracking target can be managed on the BC, for example, there is a parent-child relationship between tokens, and reuse of the token ID and special possession transfer by the administrator can be performed. Therefore, when creating the 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 the token ID, the special possession transfer by the administrator, etc. Therefore, hereinafter, the case of creating a possession transfer history considering the parent-child relationship between tokens, the reuse of the token ID, the special possession transfer by the administrator, 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 the token ID, the special possession transfer by the administrator, 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 database server 30 in addition to a plurality of nodes 10 and a plurality of terminals 20. Note that 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, or the like that creates and manages an occupancy transfer history considering the parent-child relationship between tokens, reuse of token IDs, special occupancy transfers by an administrator, and the like. 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 example of the node 10, terminal 20, and database server 30 included in the logistics management system 1> Hereinafter, a functional configuration example 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 processing 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 specified 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≫ An example of the functional configuration of the database server 30 according to the third embodiment is shown in FIG. 15. 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. Further, the database server 30 according to the third embodiment 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 token IDs, special occupancy transfers by an administrator, etc.) using the token storage information, event information, etc. acquired from the BC. Further, the occupancy transfer history creation unit 301 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 subject of history creation, for example, every predetermined period (for example, one day, etc.). Note that the token IDs to be the subject of history creation may be, for example, all token IDs, or may be a predetermined part of token IDs, or may be the token IDs of 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 the reuse of the token ID and the special transfer of possession by the administrator have occurred. At this time, the process flow when creating the transfer history of the token ID "T01" will be described with reference to FIG. 17.

[0264] The transfer history creation unit 301 of the database server 30 acquires event information regarding the token ID for which the history is to be created (here, as an example, the token ID "T01") from the 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 is 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 is 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) For each element (set list) included in the eventFilterList, repeat the following Step 111-1 to Step 111-3.

[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 inside the list), and then sort the elements of the eventInfoList in ascending order with the block number (blockNo) as the first sorting key and the log order (logIndex) as the second sorting 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 Due 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 referred to as the "first eventInfoList" and the "second eventInfoList", respectively.

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

[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: {···}}] Step112) If the length of the parentFilterList (that is, the number of elements (set lists) included in the parentFilterList) is greater than 0, update the eventFilterList by overwriting it with the parentFilterList and then return to Step111 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 when, for example, the reuse of token IDs or special transfer of ownership by the administrator is not performed, it is possible to create a transfer history in the same manner.

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

[0304] The visualization unit 205 of the 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, a user (user or administrator) who uses the terminal 20.

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

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

[0307] The ownership transfer history providing unit 302 of the database server 30 returns the ownership 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). Thereby, 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, the 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 description of the claims.

Explanation of Reference Numerals

[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 Entrusting unit for possession transfer 204 Supplementary history list acquisition unit 205 Visualization unit 301 Possession transfer history creation unit 302 Possession transfer history providing unit 303 Possession transfer history DB 500 Computer 501 Input device 502 Display device 503 External I / F 503a Recording medium 504 Communication I / F 505 RAM 506 ROM 507 Auxiliary storage device 508 Processor 509 Bus

Claims

1. A transfer management method for managing the transfer of possession of an object, a computer communicable with a blockchain in which tokens recorded have a parent-child relationship that can be cross-referenced, with the token associated with the object as the child and the token associated with the management unit in the case of transferring the possession of one or more objects as the parent, executes a transaction issuance procedure for issuing a transaction for realizing the management of the transfer of possession of the object to the blockchain, wherein the transaction includes a token generation transaction for generating a token associated with the object or the management unit, a possession transfer transaction for realizing the transfer of possession of one or more objects in the management unit by recording the transfer of possession of the token associated with the management unit on the blockchain, 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 to the token, a parent-child relationship linking transaction for linking, as child tokens, one or more tokens each associated with one of the one or more objects for which possession transfer is performed in the management unit, to the token associated with the management unit, a parent-child relationship unlinking transaction for unlinking the token associated with the management unit from one or more child tokens linked as children to the token, a token amortization transaction for amortizing the token associated with the object or the management unit, and includes at least one of them, the transfer management method.

2. A transfer management method for managing the transfer of possession of an object, a computer communicable with a blockchain in which tokens recorded have a parent-child relationship that can be cross-referenced, with the token associated with the object as the child and the token associated with the management unit in the case of transferring the possession of one or more objects as the parent, executes a transaction issuance procedure for issuing a transaction for realizing the management of the transfer of possession of the object to the blockchain, wherein the transaction includes a history approval transaction for causing a user who should have recorded the possession transfer to approve the possession transfer recorded on the blockchain with administrative authority for a recording omission of the possession transfer, the transfer management method.

3. A transfer management method for managing the transfer of possession of an object, A computer communicable with a blockchain in which tokens associated with an object are recorded as children, and tokens associated with a management unit in the case of transferring possession of one or more objects are recorded as parents, having a parent-child relationship that can be mutually referenced. A transaction issuing procedure for issuing a transaction for realizing management of the transfer of possession of the object to the blockchain. An acquisition procedure for acquiring information on a token having a token ID that is a creation target of a transfer of possession history representing the history of the transfer of possession from the blockchain, and using the acquired information on the token, creating a transfer of possession history considering at least the parent-child relationship between the token having the token ID and other tokens. A transfer management method for executing.

4. A program for causing a computer to execute the transfer management method according to any one of Claims 1 to 3.

5. A data structure of a token for managing the transfer of possession of an object on a blockchain, including 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, used in processing executed by a transaction for realizing the transfer of possession of the object, among the transactions, a transaction for transferring the possession of an object associated with a child token of a token associated with the management unit, if the token ID of the parent token is not included in the token associated with the management unit, is a transaction for changing the possessor information included in the token associated with the management unit to the possessor information after the transfer. Data structure.

Images