Token management device, token management method, and token management system

Abstract

To provide a token management device, a token management method, and a token management system that facilitate the reduction of greenhouse gas emissions without requiring prior agreement by parties relating to greenhouse gas emissions.SOLUTION: A token management device 40 comprises a controller that receives a reward request from a memory device that stores a token that records the content of a work requested directly or indirectly from a requester to a request destination and from an information processor (supplier terminal) associated with the request destination, the reward request accompanied by information on the amount of greenhouse gas emissions generated for the accomplishment of the work indicated by the token, determines whether the amount of greenhouse gas emissions generated meets the target conditions based on the received reward request, and if it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, executes the reward setting process to set the information on the reward from the requester to the request destination in the above information processor or in a device associated with the above information processor.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a token management device, a token management method, and a token management system. [Background technology]

[0002] With the growing awareness of ESG (Environment, Social, Governance), Buyers at the top of the chain (for example, large manufacturing companies) are increasingly working to reduce greenhouse gas emissions throughout their supply chains.

[0003] However, suppliers below the buyer level may not be proactive in taking on initiatives to reduce greenhouse gas emissions. The reason for this is, for example, that unless the parties have a specific contract regarding greenhouse gas emissions, it is unclear whether reducing greenhouse gas emissions will provide a return that is commensurate with the costs. Even if a company manufactures products in a way that reduces greenhouse gas emissions or uses suppliers (other suppliers) that procure parts in a way that reduces greenhouse gas emissions, it is unclear whether a return that is commensurate with the costs will be obtained, which carries business risks.

[0004] Here, Patent Document 1 describes, as a technology for promoting the reduction of greenhouse gas emissions, an electricity-derived management system that manages the origin of the electricity received by one or more pieces of equipment, and an electricity-derived management method executed by the electricity-derived management system, which measures the received electricity of the equipment and controls the proportion of renewable energy electricity contained in the received electricity to the received electricity of at least one piece of equipment measured by a power meter, thereby controlling the proportion of renewable energy electricity in the received electricity of that equipment on an equipment-by-equipment basis, making it possible to carry out environmental activities more easily and cheaply than when environmental activities can only be carried out across the entire corporate activities. [Prior art documents] [Patent documents]

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

[0006] However, Patent Document 1 requires that a target value for the proportion of renewable energy electricity be set in advance between the power utility and the consumer through a contract, etc. However, in a supply chain with multiple (many) parties, it is extremely difficult to reach an agreement on greenhouse gas emissions through such advance contracts, etc.

[0007] The present invention has been made in consideration of the above circumstances, and its purpose is to provide a token management device, a token management method, and a token management system that can promote the reduction of greenhouse gas emissions without requiring prior agreement between the parties regarding greenhouse gas emissions. [Means for solving the problem]

[0008] One aspect of the present invention for solving the above problem is a storage device that stores tokens that record the details of work that a requester has directly or indirectly requested of a requestee, and a device that receives, from an information processing device associated with the requestee, a remuneration request accompanied by information about the amount of greenhouse gas emissions generated in order to accomplish the work indicated by the token, and performs a remuneration calculation based on the received remuneration request. and a control device that determines whether the amount of greenhouse gas emissions generated satisfies a target condition, and if it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, executes a reward setting process that sets reward information from the requester to the requestee in the information processing device or a device associated with the information processing device.

[0009] Another aspect of the present invention for solving the above problem is a token management system comprising: a first information processing device managed by a requester that transmits a token issuance request recording the details of a task directly or indirectly requested by the requester to a requestee; a second information processing device managed by the requestee; a storage device that stores a token based on the issuance request; and a token management device that includes a control device that receives from the second information processing device a reward request accompanied by information regarding the amount of greenhouse gas emissions generated to accomplish the task indicated by the token, determines based on the received reward request whether the amount of greenhouse gas emissions generated satisfies a target condition, and if it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, executes a reward setting process to set information about the reward from the requester to the requestee in the first information processing device or a device associated with the first information processing device. [Effects of the Invention]

[0010] According to the present invention, it is possible to promote the reduction of greenhouse gas emissions without requiring prior agreement between the parties regarding greenhouse gas emissions. Configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a token management system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating a configuration of a product and parts assumed in this embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of each information processing device in the token management system. [Figure 4] FIG. 10 is a sequence diagram illustrating an example of a token management process. [Figure 5] FIG. 10 is a sequence diagram illustrating an example of a token management process. [Figure 6] FIG. 10 is a diagram showing an example of first order information. [Figure 7] FIG. 10 is a diagram showing an example of second order information. [Figure 8] FIG. 10 is a diagram showing an example of third order information. [Figure 9] FIG. 10 is a diagram illustrating an example of token management information. [Figure 10] FIG. 10 is a diagram illustrating an example of token issuance request information. [Figure 11] FIG. 10 is a diagram illustrating an example of token issuance notification information. [Figure 12] FIG. 10 is a diagram showing an example of first token transfer request information. [Figure 13] FIG. 10 is a diagram showing an example of first token transfer notification information. [Figure 14] FIG. 10 is a diagram showing an example of second token transfer request information. [Figure 15] FIG. 10 is a diagram showing an example of second token transfer notification information. [Figure 16] FIG. 10 is a diagram showing an example of monetization request data. [Figure 17] FIG. 10 is a diagram showing an example of certified procurement information. [Figure 18] FIG. 10 is a diagram showing an example of low discharge process information. [Figure 19] FIG. 10 is a flow diagram illustrating the details of the monetization process. [Figure 20] FIG. 1 is a diagram illustrating an example of a token management system that allows multiple parties to issue tokens for the same business transaction or transaction. [Figure 21] FIG. 10 is a diagram illustrating an example of a method for determining the identity of a financial request. DETAILED DESCRIPTION OF THE INVENTION

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

[0013] 1 is a diagram showing an example of the configuration of a token management system 1 according to this embodiment. The token management system 1 includes, with respect to a product manufacturing operation, a buyer terminal 10 (first information processing device) managed by a buyer (a party requesting the manufacture of the product) who places an order for the manufacture of the product, a first supplier terminal 20 or a second supplier terminal 30 (second information processing device) managed by each supplier (each direct or indirect requestee of the requester) who hierarchically receives orders for the manufacture or procurement of the product or its component parts corresponding to the order contents, and a token management device 40 that mediates order placement and receipt transactions between these buyers and sellers.

[0014] There may be zero or more first supplier terminals 20 and zero or more second supplier terminals 30 (the total number of first supplier terminals 20 and second supplier terminals 30 is at least one). As will be described later, the first supplier terminal 20 has a function corresponding to the electronic data interchange (EDI) system provided in the token management device 40, but the second supplier terminal 30 does not have such a function.

[0015] Between the buyer terminal 10 and the token management device 40, and between the first supplier terminal 20 or the second supplier terminal 30 and the token management device 40, a wired or wireless communication such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line may be used. They are connected by a wired communication network 5.

[0016] In this embodiment, a business supply chain is formed by a plurality of contractors and orderers. That is, the contractors exist in a hierarchical structure, including contractors who directly receive orders from buyers (orders for the manufacture of products; primary orders), contractors who receive orders from those contractors (orders for the manufacture of parts (child parts) that directly constitute the product; secondary orders), contractors who receive orders from those contractors (orders for the manufacture of grandchild parts that directly constitute the child parts; tertiary orders), and contractors who receive orders from those contractors (orders for the manufacture or procurement of great-grandchild parts (general-purpose items such as screws) that directly constitute the grandchild parts; quaternary orders).

[0017] 2 is a diagram illustrating the configuration of a product and parts assumed in this embodiment. This product 51 (product A) is made up of child parts 52 (parts A1, A2, and A3) that directly constitute this product 51, and the child parts 52 are made up of grandchild parts 53 (parts A1-1 and A1-2) that directly constitute the child parts 52, and the grandchild parts 53 are made up of great-grandchild parts 54 (motor R, gear HG A1, great-grandchild parts) that directly constitute the grandchild parts 53. The great-grandchild parts 54 are, for example, general-purpose products.

[0018] The token management device 40 mediates between the orderer and the order recipient, and also mediates the issuance and transfer of tokens based on the business related to the manufacture of products carried out based on each order. This business includes, for example, the manufacture of products by the order recipient (supplier) in response to an order from the orderer (other supplier or buyer), as well as the manufacture, procurement, and assembly of each component part of the product.

[0019] The token is data representing the right to claim compensation (in this embodiment, funding) from the buyer in accordance with the amount by which greenhouse gas emissions fall below a predetermined standard amount when such business operations are performed. The token has quantity data. Specifically, a predetermined quantity is set for the tokens to be issued. Thereafter, a portion of the tokens is divided and transferred sequentially from the purchaser to the contractor in accordance with the content of the orders (in this embodiment, the order amount) placed by each purchaser to each contractor in a series of steps in the commercial flow.

[0020] These tokens contain information about the order that caused their issuance or transfer. Therefore, the tokens in this embodiment can be divided into tokens issued at the most upstream of the supply chain (upstream tokens) and tokens obtained by division and transfer downstream of the upstream tokens in the supply chain (downstream tokens).

[0021] That is, an upstream token is a token that includes at least the details of the product and its constituent parts (child parts) in the manufacture of the product, which is the most upstream business requested by a buyer to a supplier. A downstream token is associated with an upstream token and is a token that includes the details of the product and child parts, as well as the details of the constituent parts and their further constituent parts (grandchild parts, great-grandchild parts, ...) in the manufacture of the constituent parts of the product, which is the business requested by each supplier to other suppliers (manufacturing child parts, manufacturing grandchild parts, ...). Next, the function of each device in the token management system 1 will be described.

[0022] As shown in FIG. 1, the buyer terminal 10 has the following functional units: an order placing unit 11, a token issuance requesting unit 12, and a token monetization receiving unit 13.

[0023] The order function unit 11 requests the token management device 40 to register information relating to an order (order information) that is compatible with the token management device 40's EDI.

[0024] The token issuance request function unit 12 requests the token management device 40 to issue a token to a direct order recipient (the first supplier terminal 20 or the second supplier terminal 30). The owner of the issued token is the direct order recipient, but due to the divided transfer of the token, ownership of a portion of the token is transferred to a further downstream order recipient.

[0025] The token monetization reception function unit 13 receives token-based monetization requests (reward requests) from each contractor (first supplier terminal 20 or second supplier terminal 30), including direct contractors, and provides funds in accordance with these monetization requests.

[0026] Next, the first supplier terminal 20 includes an order placing and receiving function unit 21, a token transfer receiving function unit 22, and a token monetization request function unit 23.

[0027] The order receiving and placing function unit 21 processes data related to order receiving and placing, delivery, etc., corresponding to the EDI of the token management device 40. For example, the order receiving and placing function unit 21 performs processing related to receiving an order from an orderer (the buyer terminal 10, another first supplier terminal 20, or the second supplier terminal 30).

[0028] The token transfer reception function unit 22 performs processing related to receiving tokens issued to itself (the first supplier terminal 20) and transferring a portion of the received tokens to another party (transfer to another first supplier terminal 20 or a second supplier terminal 30).

[0029] The token fund- ization request function unit 23 transmits a fund- ization request to the token management device 40 based on the tokens that it (the first supplier terminal 20) owns.

[0030] Next, the second supplier terminal 30 has a token transfer receiving function unit 31 and a token monetization request function unit 32 similar to those of the first supplier terminal 20. Note that the second supplier terminal 30 does not have an order placing and receiving function unit.

[0031] Next, the token management device 40 has the following functional units: an order management unit 41, a token issuance management unit 42, and a monetization unit 43 (remuneration setting processing unit).

[0032] The order management function unit 41 realizes the function of EDI. The order management function unit 41 registers an order based on the order information received from the orderer (the buyer terminal 10, the first supplier terminal 20, or the second supplier terminal 30). The order management function unit 41 also receives confirmation of the order from the order recipient (the first supplier terminal 20 or the second supplier terminal 30).

[0033] The token issuance management function unit 42 registers the issuance of a token (registers ownership to the issue destination). In addition, the token issuance management function unit 42 registers the transfer of a token from a transfer source (the buyer terminal 10, the first supplier terminal 20, or the second supplier terminal 30) to a transfer destination (the first supplier terminal 20 or the second supplier terminal 30) (registers the transfer of ownership).

[0034] The monetization function unit 43 performs monetization processing based on a reward request (monetization request) from the owner of the token (the first supplier terminal 20 or the second supplier terminal 30).

[0035] Specifically, the monetization function unit 43 receives a reward request from the supplier terminal (first supplier terminal 20 or second supplier terminal 30) that is the token owner, accompanied by information regarding the amount of greenhouse gas emissions generated to complete the work specified in the order indicated by the token, and determines based on the received reward request whether the amount of greenhouse gas emissions generated meets the target conditions (in this embodiment, whether the amount of greenhouse gas emissions generated is below the standard emissions), and if it determines that the amount of greenhouse gas emissions generated meets the target conditions, sets the reward information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a specified payment device associated with the supplier terminal.

[0036] In this embodiment, the remuneration request is accompanied by certification information of the amount of greenhouse gas emissions. That is, the monetization function unit 43 determines whether the information regarding greenhouse gas emissions in the remuneration request is authentic based on the certification information of the remuneration request, and if it determines that the information regarding greenhouse gas emissions is authentic, it determines whether the generated greenhouse gas emissions satisfy the target conditions, and if it determines that the generated greenhouse gas emissions satisfy the target conditions, it sets the remuneration information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a predetermined settlement device associated with the supplier terminal. Note that the certification information includes certified procurement information and low emission process information, as will be described later.

[0037] The token management device 40 also stores order configuration information 100 and token management information 200.

[0038] The order configuration information 100 includes each piece of order information received from the buyer terminal 10, the first supplier terminal 20, and the second supplier terminal 30. The order information includes information on the order contents, including the product and the product configuration.

[0039] The token management information 200 includes information about the contents of the token (for example, the history of token ownership transfers and information about order details linked to the token). The token management information 200 is stored in a relational database or other types of databases (for example, a key-value database) in the auxiliary storage device 93 described below. Alternatively, the token management information 200 may be recorded in a blockchain (or a distributed database). In this case, data on the blockchain may be distributed and recorded in multiple information processing devices (which may or may not include the token management device 40 itself).

[0040] Next, FIG. 3 shows each information processing device (first supplier terminal) in the token management system 1. 20, the second supplier terminal 30, and the token management device 40. Each information processing device is controlled by a central processing unit (CPU) or the like. a control device 91, a main memory device 92 such as a RAM (Random Access Memory) or a ROM (Read Only Memory), an auxiliary memory device 93 such as a HDD (Hard Disk Drive) or an SSD (Solid State Drive), an input device 94 such as a keyboard, a mouse, or a touch panel, an output device 95 such as a display or a touch panel, an NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Interface) module, or a serial communication and a communication device 96 configured with modules and the like. When the token management information 200 is recorded as a block chain (or a distributed database), the token management device 40 may be configured by a plurality of information processing devices, each having the configuration shown in Fig. 3. However, in the following, it is assumed that the token management device 40 is configured by a single information processing device.

[0041] The functions of the functional units of each information processing device in the token management system 1 described above are realized by the control device 91 reading out a program from the main storage device 92 or the auxiliary storage device 93. Each program can be recorded on, for example, a portable or fixed recording medium and distributed. Note that all or part of these programs may be realized using virtual information processing resources provided using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. Also, all or part of these programs may be realized by a service provided by a cloud system via an API (Application Programming Interface), for example. Next, the processing performed by the token management system 1 will be described.

[0042] <Token management process> 4 and 5 are sequence diagrams illustrating an example of a token management process related to the ordering and receipt of manufacturing orders for products or parts and the associated issuance and transfer of tokens (separated into two figures due to space limitations). The token management process is started, for example, after the token management device 40 is started.

[0043] 4, the buyer terminal 10, which is the orderer of the product, transmits information (first order information) regarding the supplier and order contents of the primary order to the token management device 40 (s1). The order management function unit 41 of the token management device 40 receives the first order information and stores the received first order information in the order configuration information 100.

[0044] Thereafter, the supplier terminal (here, T1 terminal, which is one of the first supplier terminals 20) indicated by the supplier information included in the first order information transmits information approving the order (primary order) from the buyer terminal 10 to the token management device 40 (s3), and the order management function unit 41 of the token management device 40 stores this information. Note that when the order management function unit 41 receives the first order information from the buyer terminal 10, it may transmit a notification of receipt of the first order information to the supplier terminal.

[0045] (First Order Information) 6 is a diagram showing an example of the first order information 600. The first order information 600 is information in accordance with the data format (EDI format) managed by the order management function unit 41 of the token management device 40.

[0046] That is, the first order information 600 consists of basic information 610 and configuration information 620. The basic information 610 includes an order source 611 (here, the buyer terminal 10 that is the orderer), an order recipient 612 (here, the T1 terminal), an order amount 613, an item 614 to be ordered (here, product A), an order It includes information on the target order quantity 615 and delivery date 616. The configuration information 620 includes information on the product to be ordered and the name 621 of the component parts that make up this product, the type 622 of the product or component part, the configuration 623 of the product or component part, and the required quantity 624 of the part.

[0047] Thereafter, the T1 terminal places an order (secondary order) for the manufacture of parts (child parts) that directly constitute the product via the token management device 40. That is, the T1 terminal receives input from the user associated with the T1 terminal of the supplier (here, the T2a terminal, which is one of the other first supplier terminals 20) that will place an order for the manufacture of the child parts of the product indicated by the first order information 600, and the order contents (for example, the child parts to be ordered and the order amount).

[0048] Then, the T1 terminal transmits the order information (second order information) including the input information on the supplier and order contents to the token management device 40 (s5). The order management function unit 41 of the token management device 40 stores the received second order information in the order configuration information 100.

[0049] Thereafter, the supplier terminal (terminal T2a) indicated by the supplier information included in the second order information transmits information approving the order (secondary order) from terminal T1 to the token management device 40 (s7), and the order management function unit 41 of the token management device 40 stores this information. Note that when the order management function unit 41 receives the second order information from terminal T1, it may transmit a notification of receipt of the second order information to terminal T2a.

[0050] (Second Order Information) 7 is a diagram showing an example of the second order information 700. The second order information 700 is information in accordance with the data format (EDI format) managed by the order management function unit 41 of the token management device 40.

[0051] That is, the second order information 700 consists of basic information 710 and configuration information 720. The basic information 710 includes information on an order source 711 (here, terminal T1, which is the orderer of the secondary order), an order recipient 712 (here, terminal T2a), an order amount 713, an item 714 to be ordered (here, part A1, which is a sub-part), an order quantity 715 of the item to be ordered, and a delivery date 716. The configuration information 720 includes information on the product name 721 of the sub-part to be ordered and each of the constituent parts that further constitute this sub-part, the type 722 of the sub-part or constituent part, the configuration 723 of the sub-part or constituent part, and the required quantity 724 of the part.

[0052] The configuration of each part in the configuration information 720 of the second order information 700 becomes, for example, a part of the configuration of each part in the configuration information 620 of the first order information 600. The order amount 713 is, for example, an amount within the range of the order amount 613 in the first order information 600.

[0053] Thereafter, the T2a terminal places an order (tertiary order) for the manufacture of a part (grandchild part) that directly constitutes the child part directly to the second supplier terminal 30 associated with the order recipient, without going through the token management device 40, and the second supplier terminal 30 accepts the order (s9).

[0054] Specifically, the T2a terminal receives input from a user associated with the T2a terminal of a supplier (here, the T3a terminal, which is one of the second supplier terminals 30) that will place an order for the manufacture of a grandchild part for a child part indicated by the second order information 700, and the order details (for example, the grandchild part to be ordered and the order amount).The T2a terminal then transmits information (third order information) including the supplier and the order details to the second supplier terminal 30 (T3a terminal) associated with the supplier.

[0055] (Third Order Information) 8 is a diagram showing an example of third order information. Third order information 800 is order information that includes all or part of the order details indicated by second order information 700. However, third order information 800 is information in a data format different from the data formats of first order information 600 and second order information 700.

[0056] That is, the third order information 800 is made up of basic information 810. The basic information 810 includes information on an order source 811 (here, terminal T2a, which is the orderer of the third-level order), a supplier 812 (here, terminal T3a), an order amount 813, an item 814 to be ordered (here, part A1-1, which is a grandchild part), an order quantity 815, and a delivery date 816.

[0057] (Token management information) 9 is a diagram showing an example of the token management information 200 when the processing up to s9 has been completed. The token management information 200 is information that includes, in one record, each data item: a token ID 201, a token issuer 202, a quantity 203 related to the issuance or transfer of tokens, an owner 204 resulting from the issuance or transfer, order details 205 related to the token, a token expiration date 206, and a token exchange rate 207.

[0058] The first record 210 is a record of a token based on the first order information 600. For example, the owner 204 of the first record 210 is the first supplier terminal 20 (T1 terminal), the quantity 203 is the issued quantity of tokens (40,000), and the owner 204 is the T1 terminal that is the recipient of the primary order.

[0059] The second record 211 to the fifth record 214 are records relating to the transfer of tokens based on each piece of order information (secondary orders) such as the second order information 700. For example, the quantity 203 of the third record 212 is the transfer quantity (12,000) of tokens from the T1 terminal to the T2a terminal based on the second order information 700 (secondary order for part A), and the owner of the tokens is the supplier (terminal T2a) who is the transfer destination. Similarly, the quantities 203 of the fourth record 213 and the fifth record 214 are the transfer quantities (12,000 each) of tokens from the T1 terminal to the T2b terminal and from the T1 terminal to the T2c terminal based on the order information (secondary orders for parts A2 and A3), respectively, and the owners of the tokens are the supplier (terminal T2b, terminal T2c) who is the transfer destination, respectively. The quantity 203 of the second record 211 is the remaining quantity of tokens (40000-12000-12000-12000=4000) based on this order information. This remaining quantity corresponds to the quantity of tokens related to the manufacturing work of the product that the ordering party (T1 terminal) will carry out itself based on these delivered sub-components.

[0060] The sixth record 215 to the eighth record 217 are records related to the transfer of tokens based on each piece of order information (tertiary orders) such as the third order information 800. For example, the quantity 203 of the seventh record 216 is the transfer quantity (8000) of tokens from the T2a terminal to the T3a terminal based on the third order information 800 (tertiary order for grandchild part A1-1), and the owner of the tokens is the transferee, the supplier (T3a terminal). Similarly, the quantity 203 of the eighth record 217 is the transfer quantity (2000) of tokens from the T2a terminal to the T3b terminal based on the order information (tertiary order for part A1-2), and the owner of the tokens is the transferee, the supplier (T3b terminal). And the quantity 203 of the sixth record 215 is the remaining quantity of tokens (12000-8000-2000=2000) based on these order information. This remaining quantity corresponds to the number of tokens related to the manufacturing work of child parts that the ordering source (T2a terminal) will carry out itself based on these delivered sub-child parts.

[0061] Thereafter, as shown in FIG. 4, the buyer terminal 10 transmits token issuance request information, which is information requesting the issuance of a token (i.e., an upstream token) corresponding to the first order information 600, to the token management device 40 (s11). When the information is received, the token management device 40 issues (generates) a token by assigning an ID (token ID) to the received token issuance request information. The token management device 40 transmits token issuance notification information, which is information notifying that the token has been issued together with its contents, to the order destination (here, the T1 terminal) of the first order information 600 (s13).

[0062] (Token issuance request information) 10 is a diagram showing an example of token issuance request information. The token issuance request information 900 includes information on a token issuer 901 who is the orderer, a token supplier 902 (here, the T1 terminal) who will be the owner of the token, the number of tokens 903, order details 904 for products related to the tokens, an expiration date 905 of the tokens, and a cash conversion rate 906 which is the value per unit of the tokens.

[0063] In this embodiment, the token quantity 903 is calculated based on the order amount 613 in the first order information 600, a coefficient for converting the order amount into greenhouse gas emissions (hereinafter referred to as the emission intensity), and a coefficient for converting greenhouse gas emissions into the number of tokens (hereinafter referred to as the token conversion coefficient). That is, the token quantity 903 is calculated by multiplying the order amount by the emission intensity and the token conversion coefficient. The emission intensity varies depending on the ordered item 614. For example, the emission intensity is calculated based on a predetermined value corresponding to the content of the type 622 in the configuration information 620. Note that the correspondence between such emission intensity and the corresponding value is, for example, made public in advance or distributed for a fee.

[0064] The token issuance request information 900 may be generated by the buyer terminal 10 receiving input of each piece of information from the purchaser, or may be automatically generated by the token management device 40 from the first order information 600. The token management device 40 may also transmit a notification of token issuance to the buyer terminal 10.

[0065] (Token issuance notification information) 11 is a diagram showing an example of token issuance notification information. The token issuance notification information 1000 includes information on a token issuer 1001 who is the orderer, a supplier 1002 of the token who will be the owner, the number of tokens 1003, order details 1004 of the product related to the token, a token expiration date 1005, a token ID 1006, and a cash conversion rate 1007. The information other than the token ID 1006 is the same as that of the token issuance request information 900.

[0066] 4, the T1 terminal corresponding to the supplier of the first order information 600 transmits to the token management device 40 (s15) information (first token transfer request information) requesting the transfer of ownership of part of the tokens issued in the processes of s11 to s13 in accordance with the content of the order (order from the T1 terminal to the T2a terminal) indicated by the second order information 700. The token management device 40 registers the transfer of ownership of the tokens (i.e., downstream tokens) indicated by the received first token transfer request information, and transmits information (first token transfer notification information) notifying the supplier (T2a terminal) indicated by the second order information 700 that the ownership of (part of) the tokens has been transferred and the details of the transfer (s17).

[0067] (First token transfer request information) 12 is a diagram showing an example of first token transfer request information. The first token transfer request information 1100 includes each piece of information: a token ID 1101, a token transfer source 1102 (here, terminal T1), a transfer destination 1103 of the token to be owned (here, terminal T2a), a transfer quantity 1104 of the token to be transferred from the transfer source 1102 to the transfer destination 1103, and order details 1105 (corresponding to the item 714 of the second order information 700) that is the basis for the transfer quantity 1104.

[0068] The transfer quantity 1104 is calculated by multiplying the order amount 713 of the second order information 700 by the emission intensity and the token conversion coefficient. For example, if the order amount for part A1-1 is 3 million yen (order amount 713 of the second order information 700), the emission intensity is 4 t-CO2eq per 1 million yen of order amount, and the token conversion coefficient is 1,000 tokens per 1 t-CO2eq, the transfer quantity 1104 is 3 million yen x 4 / 1,000 = 12,000 tokens.

[0069] (First token transfer notification information) 13 is a diagram showing an example of first token transfer notification information. The first token transfer notification information 1200 includes information on a token ID 1201, a token transfer source 1202 (here, the T1 terminal), a transfer destination 1203 (here, the T2a terminal) of the token to be owned, a transfer quantity 1204 of tokens to be transferred from the transfer source 1202 to the transfer destination 1203, order details 1205 that are the basis for the transfer quantity 1204, and a cash conversion rate 1206 (similar to the cash conversion rates 906, 1007 of the token issuance request information 900 and the token issuance notification information 1000). Each piece of information other than the cash conversion rate 1206 is the same as each piece of information in the first token transfer request information 1100. Note that the first token transfer notification information 1200 does not include information on parties (e.g., the buyer terminal 10) other than the parties to the token transfer (the parties to the order placement and purchase).

[0070] 4, the T2a terminal corresponding to the supplier of the second order information 700 transmits to the token management device 40 (s19) information (second token transfer request information) requesting the transfer of ownership of part of the tokens transferred in the processes of s15 to s17 in accordance with the content of the order (order from the T2a terminal to the T3a terminal) indicated by the third order information 800. The token management device 40 registers the transfer of ownership of the tokens indicated by the received second token transfer request information (i.e., the further downstream tokens relative to the downstream tokens of s15), and transmits information (second token transfer notification information) notifying the supplier (T3a terminal) indicated by the third order information 800 that the ownership of (part of) the tokens has been transferred and the details of the transfer (s21).

[0071] (Second token transfer request information) 14 is a diagram showing an example of second token transfer request information. The second token transfer request information 1300 is made up of token information 1310 and configuration information 1320. The token information 1310 has each piece of information: a token ID 1311, a token transfer source 1312 (here, terminal T2a), a transfer destination 1313 of the token to be owned (here, terminal T3a), and a transfer quantity 1314 of the token to be transferred from the transfer source 1312 to the transfer destination 1313.

[0072] The configuration information 1320 exists because the second supplier terminal 30 related to the token transfer destination 1313 (here, the T3a terminal) does not have an order placement and receipt function unit. That is, the configuration information 1320 is information in the same data format as the configuration information 620, 720 of the first order information 600 or the second order information 700. The configuration information 1320 includes information on the grandchild part, which is the item 814 to be ordered in the third order information 800, and the product name 1321 (here, part A1-1) of each component part (great-grandchild part) that makes up the grandchild part, the type 1322 of the grandchild part or great-grandchild part, the configuration 1323 of the grandchild part or great-grandchild part, and the required quantity 1324 of the part.

[0073] Here, the transfer quantity 1314 of the second token transfer request information 1300 is calculated by multiplying the order amount 813 of the third order information 800 by the emission intensity and the token conversion coefficient. For example, if the order amount of part A1-1 is 2 million yen (order amount 813 of the third order information 800), the emission intensity is 4 t-CO2eq, and the token conversion coefficient is 1000 tokens per 1 t-CO2eq, the transfer quantity 1314 is 2 million yen x 4 / 1000 = 8000 tokens.

[0074] (Second Token Transfer Notification Information) 15 is a diagram showing an example of second token transfer notification information. The second token transfer notification information 1400 includes information on a token ID 1401, a token transfer source 1402 (here, the T2a terminal), a transfer destination 1403 (here, the T3a terminal) of the token to be owned, a transfer quantity 1404 of tokens to be transferred from the transfer source 1402 to the transfer destination 1403, order details 1405 that are the basis for the transfer quantity 1404, and a cash conversion rate 1406 (similar to the cash conversion rate 1206 of the first token transfer notification information 1200). The data format of each piece of information other than the cash conversion rate 1406 is the same as the data format of each piece of information in the first token transfer request information 1100. Note that the second token transfer notification information 1400 does not include information on parties (e.g., the buyer terminal 10, the T1 terminal) other than the parties to the token transfer (the parties to the order placement and receipt).

[0075] Here, as shown in Figure 4, after processing s9, the T3a terminal places a fourth order for the manufacture or procurement of great-grandchild parts based on the third order information 800 directly to another second supplier terminal 30 related to the supplier without going through the token management device 40, and the second supplier terminal 30 accepts the order (s23).

[0076] Specifically, the T3a terminal receives input from a user associated with the T3a terminal of the supplier (here, the T4 terminal, which is one of the second supplier terminals 30) that will place an order for the manufacture or procurement of the great-grandchild parts indicated in the third order information 800, and the order details (for example, the great-grandchild parts to be ordered and the order amount).The T3a terminal then transmits information (fourth order information) including the supplier and the order details to the second supplier terminal 30 (T4 terminal) associated with the supplier.The fourth order information has the same data format as the third order information.

[0077] Thereafter, as shown in FIG. 5, the recipient of the fourth order corresponding to the T4 terminal manufactures or procures the ordered parts and delivers the manufactured or procured products to the ordering party corresponding to the T3 terminal (s25).

[0078] Here, the contractor of this fourth order is assumed to have manufactured or procured the parts with less greenhouse gas emissions than usual, based on the instructions of the ordering party. The T4 terminal transmits information (emissions certification information) certifying this greenhouse gas emission amount to the T3a terminal (s27).

[0079] Thereafter, the orderer of the great-grandchild parts associated with terminal T3a manufactures the parts (grandchild parts) indicated by the third order information 800 based on the delivered great-grandchild parts and delivers them to the orderer of the grandchild parts associated with terminal T2a (s29). The orderer of the grandchild parts associated with terminal T2a manufactures child parts based on the delivered grandchild parts and delivers them to the orderer of the child parts associated with terminal T1 (s31). The orderer of the child parts associated with terminal T1 manufactures a product based on the delivered child parts and delivers it to the orderer of the buyer terminal 10 (s33).

[0080] The third-tier order recipient (T3a terminal) was then able to procure the great-grandchild parts with less greenhouse gas emissions than the standard case, as a necessary operation for the completion of its own business of manufacturing the grandchild parts, as described above. Based on the tokens transferred to it in s21, the T3 terminal transmits a monetization request including information on the reduced greenhouse gas emissions to the token management device 40 (s35).

[0081] The monetization request is accompanied by one or more pieces of monetization request evidence data, which is data that proves the reduction of greenhouse gas emissions. The monetization request includes only information about the requesting entity, i.e., the current token owner (here, the T3a terminal), as information about the parties involved in the order placement and receipt. The monetization request is set, for example, for each business.

[0082] (Funding Request Data) FIG. 16 is a diagram showing an example of the monetization request data. The monetization request data 1600 is The information includes the token ID 1601 of the token that is the basis for the monetization request, the owner 1602 of the token (i.e., the T3a terminal), the quantity 1603 of tokens held by the owner 1602, the amount of greenhouse gases reduced (emission reduction amount 1604), and the monetization request basis data 1605.

[0083] Certification information is included in the funding request basis data 1605. In this embodiment, there are two types of certification information: certified procurement information and certification information.

[0084] Certified procurement information is information that certifies that a process that reduced greenhouse gas emissions was carried out by an entity other than the contractor (the contractor) based on the contractor's instructions. Specifically, certified procurement information is information that certifies the amount of greenhouse gas emissions reduced by a supplier, to whom the supplier placed an order for parts based on the contractor's instructions to complete the contractor's business (for example, manufacturing parts), by carrying out a business process such as manufacturing or procuring the parts.

[0085] Low-emission process information is certification information that proves that the contractor (the contractor) has implemented a process that reduces greenhouse gas emissions. Specifically, low-emission process information is information that proves the amount of greenhouse gas emissions reduced by the process of work that the contractor implemented based on the parts delivered by the contractor (for example, the process of manufacturing parts, such as assembling components manufactured or procured by the contractor).

[0086] The certified procurement information and low-emission process information each include information indicating how much greenhouse gas emissions in each process have been reduced based on or by the supplier's instructions compared to the standard case.

[0087] (Certified Procurement Information) 17 is a diagram showing an example of certified procurement information. Certified procurement information 1700 includes: product name 1701 of a product or part whose greenhouse gas emissions have been reduced in its manufacturing or procurement; entity 1702 that manufactured or procured the product (here, the contractor corresponding to the T4 terminal); delivery date 1703 on which entity 1702 delivered the product; standard emission amount 1704 that is the standard amount of greenhouse gas emissions in the manufacturing or procurement process; actual emission amount 1705 that is the amount of greenhouse gas actually emitted; emission reduction amount 1706 that is the difference between standard emission amount 1704 and actual emission amount 1705 (the amount of greenhouse gas reduced); verifier 1707 that verified and certified actual emission amount 1705; and verification information 1708 based on the emission certification information.

[0088] The verifier 1707 is an entity other than the entity 1702 that carried out the manufacturing or procurement process (the entity that emitted the greenhouse gas whose emissions have been reduced). The verification information 1708 is, for example, data of a verification document that has been digitally certified by the verifier 1707. The standard emission amount 1704 is calculated, for example, from the amount of money involved in manufacturing.

[0089] In the example shown, certified procurement information 1700 indicates that the supplier manufactured motor R with reduced greenhouse gas emissions.

[0090] (Low emission process information) 18 is a diagram showing an example of low discharge process information 1800. Low discharge process information 1800 includes equipment discharge information 1810 and operation history information 1820.

[0091] The equipment emission information 1810 is information on the manufacturing equipment related to the process that was carried out. The equipment emission information 1810 includes the equipment name 1811 of the manufacturing equipment for the product or part for which the greenhouse gas emissions have been reduced, the name 1812 of the manufacturing process for the product or part by the manufacturing equipment, and the name 1813 of the process for the manufacturing of the product or part. The verification information 1816 includes a standard emission amount per unit process 1813, an actual emission amount per unit process 1814, an emission reduction amount per unit process 1815, a verifier 1816, and verification information 1817.

[0092] The operation history information 1820 is a log of operation data acquired by each manufacturing device. The operation history information 1820 includes the name of the manufacturing device (data source 1821) of the product or part for which greenhouse gas emissions have been reduced, the date and time 1822 when the manufacturing device operated, the number of processes 1823 performed by the manufacturing device, and the name 1824 of the product or part manufactured by the manufacturing device.

[0093] FIG. 18 shows that the client manufactured part A1-1 using manufacturing equipment X and motor R as material in a total of 10 steps of process KT01.

[0094] Here, the total amount of reduced greenhouse gases is calculated by adding up the product of the emission reduction amount 1815 and the number of processes 1823 and the emission reduction amount 1706 in the certified procurement information 1700 .

[0095] 5, the token management device 40, having received the fundraising request data 1600, executes a fundraising process s37 in which the token management device 40 calculates a reward corresponding to the fundraising request data 1600 and determines whether to fund it. The fundraising process s37 will be described in detail later.

[0096] When the token management device 40 decides to monetize the tokens, it transmits a notification to the buyer terminal 10 that the tokens will be monetized (s39).

[0097] When the buyer terminal 10 receives the notification to the effect that monetization will be performed, it transmits information to the token management device 40 indicating that payment (grant of reward) corresponding to the monetization request data 1600 is permitted (s41).

[0098] Upon receiving the notification of the intention to perform monetization, the token management device 40 executes the payment corresponding to the monetization request data 1600 (s43).

[0099] For example, the token management device 40 transmits a request to a predetermined settlement device to pay the reward calculated in the monetization process s37 from the account related to the buyer terminal 10 to the account related to the supplier terminal that transmitted the monetization request data 1600, and the settlement device performs settlement processing in response to this request. Also, for example, the token management device 40 sets reward information (e.g., points) in the supplier terminal that transmitted the monetization request data 1600.

[0100] The token management device 40 may transmit information indicating that the payment has been made to the buyer terminal 10.

[0101] <Monetization processing> FIG. 19 is a flow diagram illustrating the details of the monetization process s37. The funding function unit 43 receives funding request data 1600 accompanied by one or more funding request basis data 1605 from the first supplier terminal 20 or the second supplier terminal 30 (in this embodiment, the T3a terminal which is the second supplier terminal 30) (s101).

[0102] The fundraising function unit 43 determines whether the entity that transmitted the fundraising request data 1600 is the owner of the token (s103). Specifically, the fundraising function unit 43 searches each record in the token management information 200 and determines whether there is a record in which the token ID 201, the quantity 203, and the owner 204 correspond to the token ID 1601, the owner 1602, and the quantity 1603 of the fundraising request data 1600, respectively. Furthermore, the fundraising function unit 43 The financialization function unit 43 determines whether the deadline 206 of the record is after the current time (is within the deadline). At this time, the financialization function unit 43 acquires the order details 205 of the record to identify the order details related to the financialization request data 1600.

[0103] If the entity that sent the fundraising request data 1600 is the owner of the token (s103: owned), the fundraising function unit 43 executes the processing of s107, and if the entity that sent the fundraising request data 1600 is not the owner of the token (s103: not owned), the fundraising processing s37 ends (s105).

[0104] In s107, the capitalization function unit 43 selects one of the capitalization request basis data 1605 in the received capitalization request data 1600 and checks the type of the capitalization request basis data 1605 (s107). Specifically, the capitalization function unit 43 checks whether the capitalization request basis data 1605 attached to the capitalization request data 1600 is certified procurement information 1700 or low-emission process information 1800.

[0105] If the funding request basis data 1605 is the certified procurement information 1700 (s109: certified procurement information), the funding function unit 43 executes the process of s111, and if the funding request basis data 1605 is the low emission process information 1800 (s109: low emission process information), the funding function unit 43 executes the process of s119. Note that if the funding request basis data 1605 includes the certified procurement information 1700 and the low emission process information 1800, both processes are executed.

[0106] In s111, the funding function unit 43 confirms whether the certified part indicated in the certified procurement information 1700 is a part ordered by the owner of the token identified in s101 (here, the T3a terminal) to accomplish his or her own business.

[0107] Specifically, the funding function unit 43 checks whether the product name 1701 of the certified procurement information 1700 is set to any of the product and part configuration information in each order information related to the order content 205 identified in s103, which is stored in the order configuration information 100.

[0108] If the part to be certified is a part that the token owner has ordered to accomplish his / her own business (s111: OK), the monetization function unit 43 executes the processing of s115, and if the part to be certified is not a part that the token owner has ordered to accomplish his / her own business (s111: NG), the monetization processing s37 ends (s113).

[0109] In s115, the financing function unit 43 confirms whether the verification regarding the reduction of greenhouse gas emissions in the certified procurement information 1700 is authentic.

[0110] For example, the financialization function unit 43 verifies that the verification information 1708 of the certified procurement information 1700 has been authentically created by the verifier 1707 by decrypting the verification information 1708 using a predetermined encryption key or the like.

[0111] If the verification is authentic (s115: OK), the monetization function unit 43 executes the process of s129, and if the verification is not authentic (s115: NG), the monetization process s37 ends (s113).

[0112] In s117, the monetization function unit 43 identifies the amount of greenhouse gas emissions reduced in the procurement or manufacturing carried out by the contractor. Specifically, the monetization function unit 43 acquires the amount of emissions reduced 1706 from the certified procurement information 1700. Thereafter, the processing of s129 is carried out.

[0113] On the other hand, in s119, the funding request basis data 1605 is the low emission process information 1800. In some cases, the monetization function unit 43 confirms whether the part to be certified indicated by the operation history information 1820 of the low emission process information 1800 is a product or part, or a component thereof, for which the owner of the token identified in s101 (here, the T3a terminal) has received an order to manufacture.

[0114] Specifically, the financialization function unit 43 checks whether the product name 1824 of the operation history information 1820 is set to any of the product and part configuration information in each order information related to the order content 205 identified in s103, which is stored in the order configuration information 100.

[0115] If the part to be certified is a product or part or a component thereof that the token owner has received an order to manufacture (s119: OK), the monetization function unit 43 executes the processing of s125, and if the part to be certified is not a product or part or a component thereof that the token owner has received an order to manufacture (s119: NG), the monetization processing s37 ends (s123).

[0116] In s125, the monetization function unit 43 checks whether the verification regarding the reduction in greenhouse gas emissions in the equipment emission information 1810 is authentic.

[0117] For example, the financialization function unit 43 verifies that the verification information 1817 has been genuinely created by the verifier 1816 by decrypting the verification information 1817 of the device discharge information 1810 using a predetermined encryption key or the like.

[0118] If the verification is authentic (s125: OK), the monetization function unit 43 executes the process of s127, and if the verification is not authentic (s125: NG), the monetization process s37 ends (s123).

[0119] In s127, the monetization function unit 43 identifies the amount of reduction in greenhouse gas emissions. Specifically, the monetization function unit 43 acquires the amount of emission reduction 1815 from the equipment emission information 1810, and multiplies the acquired amount of emission reduction 1815 by the total value (total number of processes) of the number of processes 1823 of all records in the operation history information 1820. Thereafter, the processing of s129 is performed.

[0120] In s129, the monetization function unit 43 checks whether there is any unselected monetization request basis data 1605. If there is any unselected monetization request basis data 1605 (s129: no), the monetization function unit 43 executes the process of s107 to select one of the unselected monetization request basis data, and if there is no unselected monetization request basis data 1605 (s129: yes), the monetization function unit 43 executes the process of s133.

[0121] In s131, the monetization function unit 43 adds up all of the reductions in greenhouse gas emissions identified in the previous processes (s117, s127).

[0122] The monetization function unit 43 then checks (s133) whether the total calculated in s131 matches the emission reduction amount 1604 in the monetization request data 1600. If the total calculated in s131 matches the emission reduction amount 1604 in the monetization request data 1600 (s133: OK), the monetization function unit 43 executes the process of s135, but if the total calculated in s131 does not match the emission reduction amount 1604 in the monetization request data 1600 (s133: NG), the monetization process s37 ends (s137).

[0123] In s135, the financial function unit 43 calculates the funds (remuneration) corresponding to the amount of greenhouse gas reduction confirmed in s131, and sends a notification of the decision to provide (pay) the calculated funds to the supplier terminal that sent the financial request data 1600.

[0124] Specifically, the monetization function unit 43 receives the quantity 1603 and the amount of the payment in the monetization request data 1600. The multiplied value of the reduction amount 1604 is further multiplied by the cash conversion rate 207 of the record related to the order details 205 acquired in s103 in the token management information 200. The monetization function unit 43 transmits notification information to which this multiplied value, i.e., information on the payment amount (remuneration), is attached to the first supplier terminal 20 or second supplier terminal 30 that transmitted the monetization request data 1600. This completes the monetization process s37 (s139).

[0125] <When multiple types of tokens are mixed> In the token management system 1 described above, multiple parties can issue tokens for the same business or transaction (for example, a token for the manufacturing of a product and a token for the manufacturing of a component part of that product can be issued separately).

[0126] For example, as shown in FIG. 20, a buyer terminal 10 (buyer) issues a first token 2001 related to the manufacture of a product, and a portion of the first token 2001 is transferred to Tier 1, Tier 2, and Tier 3 (the first supplier terminal 20 or the second supplier terminal 30). On the other hand, Tier 1 can issue a second token 2003 related to the manufacture of a sub-component of the product separately from the first token 2001. In this case, a portion of the second token 2003 is transferred to Tier 2 and Tier 3 (the first supplier terminal 20 or the second supplier terminal 30).

[0127] This would allow Tier 3 to send the monetization request data 1600 for the first token 2001 and the monetization request data 1600 for the second token 2003 to the token management device 40, but this would mean that Tier 3 could make duplicate monetization requests for the same order processing, which is unreasonable.

[0128] Therefore, in such a case, when the token management device 40 receives multiple fundraising request data 1600 from the same entity, it uses the fundraising request basis data 1605 (certification information) of the fundraising request data 1600 to determine whether the fundraising request data 1600 are information relating to the same commercial flow, and if they are information relating to the same commercial flow, it does not process the fundraising request data 1600.

[0129] Specifically, first, the monetization function unit 43 of the token management device 40 receives a first reward request (monetization request) for a token that records a first content of a business (e.g., product manufacturing work) from the supplier terminal (first supplier terminal 20 or second supplier terminal 30) that is the token owner, and based on the received first reward request, sets reward information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a payment device associated with the supplier terminal.

[0130] Thereafter, when the monetization function unit 43 receives a second reward request (monetization request) from the same supplier terminal for a token that records a second content of the same business (for example, the manufacturing business of a component part of the above-mentioned product), it determines whether the proof information of the received second reward request is identical to the proof information of the first reward request, and only if it determines that the proof information of the second reward request is not identical to the proof information of the first reward request, it sets the reward information from the buyer terminal 10 to the supplier terminal or to a payment device associated with the supplier terminal based on the second reward request.

[0131] 21 is a diagram illustrating an example of a method for determining the identity of the capitalization request data 1600. As shown in the diagram, if the capitalization function unit 43 has previously received capitalization request data 1600 from a supplier terminal and capitalized on it, and then receives new capitalization request data 1600 from the same supplier terminal, it checks the certified procurement information 1700 and low-emission process information 1800 attached to the two capitalization requests.

[0132] For example, if two funding requests are accompanied by certified procurement information 1700, the funding function unit 43 refers to the order number 1709 in the certified procurement information 1700, and if the order number 1709 is the same for the two funding request data 1600, the funding process s37 for the later received funding request data 1600 is not performed.

[0133] Furthermore, for example, if two capitalization requests are accompanied by operation history information 1820, the capitalization function unit 43 refers to the data source 1821 and date and time 1822 of the operation history information 1820, and performs capitalization processing s37 on the capitalization request data 1600 received later only if the data source 1821 and date and time 1822 are different between the two capitalization request data 1600.

[0134] The authentication information used for the duplication check described here is an example. Any other authentication information may be used as long as it can confirm the identity of the fundraising request data 1600.

[0135] As described above, the token management device 40 of this embodiment receives a monetization request accompanied by information regarding the greenhouse gas emissions generated by the business indicated by the issued token from the device to which the business is being requested (for example, the first supplier terminal 20 or the second supplier terminal 30 that has received an order directly or indirectly from the buyer terminal 10), and if it determines based on the received monetization request that the greenhouse gas emissions generated meet the target conditions (in this embodiment, they are below the standard emissions), it sets information regarding the reward from the buyer (buyer terminal 10), who is the requester of the business (the person ordering the business), to the device to which the business is being requested, in the payment device associated with the device to which the business is being requested.

[0136] That is, the token management device 40 allows the orderer of the work to give an incentive to the contractor when the contractor reduces greenhouse gas emissions in the work, etc. This can encourage the parties who perform the work at the request (for example, those at the end of the supply chain) to reduce greenhouse gas emissions.

[0137] In this way, the token management device 40 of this embodiment can promote the reduction of greenhouse gas emissions without requiring prior agreement between the parties regarding greenhouse gas emissions.

[0138] In this way, the token management device 40 mediates the processing related to tokens between the requester and the requestee. Therefore, when the requestee (each supplier terminal) reduces greenhouse gas emissions and claims rewards in tokens, it is not necessary to provide the requester (buyer terminal 10) with information other than information related to greenhouse gas emissions (for example, information related to the contracting parties), thereby ensuring confidentiality of the business.

[0139] Furthermore, when the amount of greenhouse gas emissions generated meets the target conditions, the token management device 40 of this embodiment calculates the amount of carbon dioxide emissions based on parameters (in this embodiment, order amount, emission unit, token conversion coefficient, etc.) registered in the token that represent the amount of greenhouse gas emissions according to the content of the work, calculates a reward according to the calculated amount of greenhouse gas emissions, and sets information on the reward from the buyer (buyer terminal 10), who is the requester (the person ordering the work), to the device to which the work is requested or the payment device associated with it.

[0140] This allows incentives to be given according to the amount of greenhouse gas reduction, thereby promoting reduction of greenhouse gas emissions.

[0141] In this embodiment, the upstream token includes at least the details of the component parts (child parts) of the product in the manufacturing of the product, which is a task requested by the requester (buyer terminal 10) to the requestee (supplier terminal). When the token management device 40 receives a remuneration request accompanied by information regarding the amount of greenhouse gas emissions generated to accomplish the task indicated by the upstream token, if it determines that the amount of greenhouse gas emissions generated meets the target condition, it sets the information of the remuneration from the buyer terminal 10 to the supplier terminal in the supplier terminal or a settlement device associated with the supplier terminal. The downstream token is associated with the upstream token and includes at least the details of the component parts (child parts) of the product and the details of the component parts (grandchild parts, great-grandchild parts, ...) of the component parts in the manufacturing of the component parts (manufacturing of child parts, manufacturing of grandchild parts, ...), which is a task requested by the requestee (supplier terminal) to another requestee (other supplier terminal). When the token management device 40 receives a reward request accompanied by information regarding the amount of greenhouse gas emissions generated in order to accomplish the business indicated by the downstream token, if it determines that the amount of greenhouse gas emissions generated meets the target conditions, it sets the reward information from the supplier terminal to other supplier terminals in the supplier terminal or a payment device associated with the supplier end.

[0142] In this way, the token management device 40 sets tokens for each task from upstream to downstream, which correspond to each other according to the order content (product or part configuration), and sets rewards according to each task. This makes it possible to track the entire sequence of orders related to product manufacturing tasks. This also makes it possible to motivate and provide incentives to each tier company, regardless of the commercial flow (upstream or downstream) in a supply chain involving multiple companies from upper tier companies to lower tier companies, to reduce greenhouse gas emissions. Furthermore, even when the ties between upper tier companies and lower tier companies are weak (for example, when no special contracts or agreements regarding greenhouse gas emission reductions have been made between the tier companies), these tokens can be used to motivate and provide incentives to each tier company to reduce greenhouse gas emissions.

[0143] In addition, the token management device 40 of this embodiment receives a reward request (monetization request) accompanied by emission certification information along with information regarding greenhouse gas emissions, and first determines whether the information regarding greenhouse gas emissions is authentic based on the certification information of the received reward request.If it determines that the information regarding greenhouse gas emissions is authentic, and if it determines that the generated greenhouse gas emissions satisfy the target conditions, it sets the reward information from the buyer (buyer terminal 10), who is the requester (business orderer), to the business recipient in the business recipient's management device or a device associated therewith.

[0144] In this way, by checking the authenticity of greenhouse gas emissions, rewards can be set only when they are merited.

[0145] In addition, the token management device 40 of this embodiment receives a remuneration request accompanied by certification information (certified procurement information 1700) that certifies that the process of reducing greenhouse gas emissions was carried out by an entity other than the requester of the remuneration request (the contractor of the work), and determines whether the information regarding greenhouse gas emissions is authentic based on the certification information of the received remuneration request.

[0146] This makes it possible to reliably confirm the authenticity of a work contractor's reduction of greenhouse gas emissions by procuring or ordering parts based on its own instructions.

[0147] In addition, the token management device 40 of this embodiment receives a remuneration request accompanied by certification information (low emission process information 1800) that proves that the requester of the remuneration request (the contractor of the work) has carried out a process that reduced greenhouse gas emissions, and determines whether the information regarding greenhouse gas emissions is authentic based on the certification information of the received remuneration request.

[0148] This makes it possible to reliably confirm the authenticity of any reduction in greenhouse gas emissions that has been achieved by the contractor himself.

[0149] In addition, the token management device 40 of this embodiment receives a first reward request from a supplier terminal related to a token that records first content in the product manufacturing work, and based on the received first reward request, sets reward information from the requester (buyer terminal 10) to the requested party (supplier terminal) in the supplier terminal or a payment device associated with the supplier terminal.If a second reward request is then received from the same supplier terminal related to a token that records second content in the product manufacturing work, only if it determines that the proof information of the second reward request is not identical to the proof information of the first reward request (for example, if it relates to the manufacture of different parts), does it set reward information from the requester (buyer terminal 10) to the requested party (supplier terminal) in the supplier terminal or a payment device associated with the supplier terminal.

[0150] This makes it possible to eliminate fraudulent remuneration claims, such as a supplier terminal claiming remuneration multiple times based on the same cause.

[0151] Furthermore, the token management device 40 of this embodiment transmits information about the reward to the buyer terminal 10 when setting information about the reward from the request source (buyer terminal 10) to the request destination.

[0152] This allows the buyer to know that a reduction in greenhouse gas emissions related to their business has been achieved and that a reward will be provided or has been provided for this. This allows the buyer, for example, to confirm the provision of a reward in advance and to receive various reports (e.g., ESG (Environment, Social, Governance) reports) related to the reduction of greenhouse gas emissions. etc.) can be carried out.

[0153] In the token management system 1 of this embodiment, the buyer terminal 10 transmits a token issuance request, and the token management device 40 stores the token based on the issuance request. This allows the buyer to issue the token at a timing of their choice.

[0154] The present invention is not limited to the above-described embodiments, and can be implemented using any components within the scope of the present invention. The above-described embodiments and modifications are merely examples, and the present invention is not limited to these contents as long as the characteristics of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of ​​the present invention are also included within the scope of the present invention.

[0155] For example, part of the hardware provided in each device of this embodiment may be provided in another device.

[0156] Furthermore, each program of each device may be provided in another device, a program may consist of multiple programs, or multiple programs may be integrated into one program.

[0157] In addition, in this embodiment, the division of tokens (division of quantity) is performed according to the order amount, but it may be divided according to other criteria (for example, criteria determined for each orderer or contract). This may be done.

[0158] Furthermore, in this embodiment, the target condition for greenhouse gas emissions is whether the amount of greenhouse gases generated is below the standard emission amount, but other conditions (for example, below a standard set in advance by the parties involved) may also be set.

[0159] In this embodiment, the timing when the buyer terminal 10 requests the issuance of a token is after the order placement and receipt between the T2a terminal and the T3a terminal, but this is just an example and other timings are also possible. Also, the timing of the token transfer may be after delivery, not before delivery as in this embodiment, as long as the order placement and receipt is completed.

[0160] In addition, the timing at which the first supplier terminal 20 and the second supplier terminal 30 send token transfer request information (first token transfer request information, second token transfer request information) to the token management device 40 may be initiated when a specified input is made to the first supplier terminal 20 and the second supplier terminal 30, or may be performed automatically after the corresponding order is placed or received.

[0161] Furthermore, in this embodiment, the low discharge process information 1800 includes the equipment discharge information 1810 and the operation history information 1820, but it may include only one of them.

[0162] Furthermore, in this embodiment, an example of product manufacturing has been described as an example of a business relating to tokens, but the present invention can also be applied to other types of business. [Explanation of symbols]

[0163] 1 token management system, 10 buyer terminal, 20 first supplier terminal, 30 second supplier terminal, 40 token management device, 43 monetization function unit

Claims

1. a storage device that stores a token that records the content of a task that has been directly or indirectly requested by a request source to a request destination; and a control device that receives, from an information processing device associated with the request destination, a reward request accompanied by information on the amount of greenhouse gas emissions generated for accomplishing the task indicated by the token, determines whether the amount of greenhouse gas emissions generated satisfies a target condition based on the received reward request, and, when it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, executes a reward setting process that sets information on the reward from the request source to the request destination in the information processing device or a device associated with the information processing device. A token management device comprising:

2. the storage device stores a token including a parameter representing an amount of greenhouse gas emissions corresponding to the content of the business; In the reward setting process, when the generated greenhouse gas emissions satisfy the target condition, the control device calculates the carbon dioxide emissions based on the parameters of the token, calculates a reward according to the calculated greenhouse gas emissions, and sets information of the calculated reward in the information processing device or a device associated with the information processing device. The token management device according to claim 1 .

3. the control device stores in the storage device an upstream token including at least details of a component part of a product in the manufacture of the product, which is a task requested by the request source to the request destination, and a downstream token associated with the upstream token, which includes at least details of the component part and details of a component part of the component part in the manufacture of the component part, which is a task requested by the request destination to another request destination; In the reward setting process, the control device When a remuneration request accompanied by information regarding the amount of greenhouse gas emissions generated for the achievement of the task indicated by the upstream token is received from the information processing device associated with the requested destination, it is determined whether or not the amount of greenhouse gas emissions generated satisfies a target condition based on the received remuneration request, and when it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, it sets information regarding the remuneration from the request source to the requested destination in the information processing device associated with the requested destination or in a device associated with the information processing device; When a remuneration request accompanied by information about the amount of greenhouse gas emissions generated for accomplishing the task indicated by the downstream token is received from the information processing device associated with the other requested destination, it is determined whether or not the amount of greenhouse gas emissions generated satisfies a target condition based on the received remuneration request, and when it is determined that the amount of greenhouse gas emissions generated satisfies the target condition, it sets information about the remuneration from the request source to the other requested destination in the information processing device associated with the other requested destination or in a device associated with the information processing device. The token management device according to claim 1 .

4. In the reward setting process, the control device receives a reward request accompanied by certification information for the emissions together with information about the greenhouse gas emissions, determines whether the information about the greenhouse gas emissions is authentic based on the certification information of the received reward request, determines whether the generated greenhouse gas emissions satisfy the target conditions when it determines that the generated greenhouse gas emissions satisfy the target conditions, and executes a reward setting process to set information about the reward from the request source to the request recipient in the information processing device or a device associated with the information processing device when it determines that the generated greenhouse gas emissions satisfy the target conditions. The token management device according to claim 1 .

5. In the reward setting process, the control device receives a reward request accompanied by certification information that certifies that a process that reduced greenhouse gas emissions was carried out by an entity other than the requested party based on the requested party, and determines whether the information regarding greenhouse gas emissions is authentic based on the certification information of the received reward request. The token management device according to claim 4.

6. In the reward setting process, the control device receives a reward request accompanied by certification information that certifies that the requested party has carried out a process that reduced greenhouse gas emissions, and determines whether the information regarding the greenhouse gas emissions is authentic based on the certification information of the received reward request. The token management device according to claim 4.

7. In the reward setting process, the control device receiving a first reward request related to a token recording first content from the information processing device, and setting reward information from the request source to the request destination in the information processing device or a device associated with the information processing device based on the received first reward request; When a second reward request related to a token recording second content is further received from the information processing device, the authentication information of the received second reward request is determined to be identical to the authentication information of the received first reward request, and only when it is determined that the authentication information of the second reward request is not identical to the first reward request, information of the reward from the requester to the requestee is set in the information processing device or a device associated with the information processing device based on the received second reward request. The token management device according to claim 4.

8. When setting information on a reward from the request source to the request destination in the reward setting process, the control device transmits information on the reward to an information processing device associated with the request source. The token management device according to claim 1 .

9. The information processing device storing a token that records the content of a task directly or indirectly requested by a request source to a request destination; receive a reward request accompanied by information about the amount of greenhouse gas emissions generated for accomplishing the task indicated by the token from an information processing device associated with the requested destination, determine whether or not the amount of greenhouse gas emissions generated meets a target condition based on the received reward request, and if it is determined that the amount of greenhouse gas emissions generated meets the target condition, execute a reward setting process to set information about the reward from the requester to the requested destination in the information processing device or a device associated with the information processing device; Token management methods.

10. a first information processing device managed by a request source that transmits a token issuance request recording the content of a business requested directly or indirectly by the request source to a request destination; a second information processing device managed by the request destination; a storage device that stores a token based on the issuance request; and a request for remuneration accompanied by information on the amount of greenhouse gas emissions generated for accomplishing the task indicated by the token, and determining whether or not the amount of greenhouse gas emissions generated satisfies a target condition based on the received request for remuneration; and when determining that the amount of greenhouse gas emissions generated satisfies the target condition, transmitting the request from the request source to the first information processing device or a device associated with the first information processing device; a token management device including a control device that executes a reward setting process to set reward information for a request destination; 1. A token management system comprising:

11. The token management system according to claim 10 , comprising a plurality of the token management devices, the plurality of token management devices cooperating to store the tokens in a distributed manner.

Images