JP7796004B2 - Token management device, token management method, and token management system - Google Patents

Description

The present invention relates to a token management device, a token management method, and a token management system.

Due to growing awareness of ESG (Environment, Social, Governance), buyers at the top of the supply chain (for example, large manufacturing companies) are increasingly working to reduce greenhouse gas emissions throughout the supply chain.

However, suppliers below the buyer level may not be proactive in taking steps 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 result in a return that is commensurate with the costs. Even if a company manufactures 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.

Patent Document 1 describes a technology for promoting the reduction of greenhouse gas emissions, namely, 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. The system measures the received electricity of the equipment and controls the proportion of renewable energy electricity contained in the received electricity relative to the received electricity of at least one piece of equipment measured by a power meter. This allows the proportion of renewable energy electricity in the received electricity of that equipment to be controlled on an equipment-by-equipment basis, making it possible to implement environmental activities more easily and inexpensively than when environmental activities can only be implemented across the entire corporate activities.

Japanese Patent Application Laid-Open No. 2020-170484

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

The present invention was made in light of these 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.

One aspect of the present invention for solving the above problem is a token management device comprising: a storage device that stores tokens that record the content of work requested directly or indirectly by a requester to a requestee; and a control device that receives a reward request from an information processing device associated with the requestee, the reward request being accompanied by information regarding the amount of greenhouse gas emissions generated to accomplish the work 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 that sets information about the reward from the requester to the requestee in the information processing device or a device associated with the information processing device.

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 the token based on the issuance request; and a token management device including 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 that sets 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.

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.

FIG. 1 is a diagram illustrating an example of a configuration of a token management system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating a configuration of a product and parts assumed in this embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of each information processing device in the token management system. FIG. 10 is a sequence diagram illustrating an example of a token management process. FIG. 10 is a sequence diagram illustrating an example of a token management process. FIG. 10 is a diagram illustrating an example of first order information. FIG. 10 is a diagram illustrating an example of second order information. FIG. 10 is a diagram illustrating an example of third order information. FIG. 10 is a diagram illustrating an example of token management information. FIG. 10 is a diagram illustrating an example of token issuance request information. FIG. 10 is a diagram illustrating an example of token issuance notification information. FIG. 10 is a diagram illustrating an example of first token transfer request information. FIG. 10 is a diagram illustrating an example of first token transfer notification information. FIG. 10 is a diagram illustrating an example of second token transfer request information. FIG. 10 is a diagram illustrating an example of second token transfer notification information. FIG. 10 is a diagram showing an example of monetization request data. FIG. 10 is a diagram showing an example of certified procurement information. FIG. 10 is a diagram showing an example of low discharge process information. FIG. 10 is a flow diagram illustrating the details of the monetization process. 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. FIG. 10 is a diagram illustrating an example of a method for determining the identity of a financial request.

Embodiments of the present invention will be described in detail below with reference to the drawings.

Figure 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 is configured to include, with respect to product manufacturing operations, a buyer terminal 10 (first information processing device) managed by a buyer (a party requesting the manufacture of a 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 client of the requester) who hierarchically receives orders for the manufacture or procurement of products or their component parts corresponding to the order contents, and a token management device 40 that mediates order transactions between these buyers and sellers.

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 described below, the first supplier terminal 20 has a function compatible with 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.

The buyer terminal 10 and the token management device 40, and the first supplier terminal 20 or the second supplier terminal 30 and the token management device 40 are connected by a wired or wireless communication network 5, such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line.

In this embodiment, a business supply chain is formed with multiple contractors and orderers. That is, there are hierarchical structures of contractors, including contractors that directly receive orders from buyers (orders to manufacture products; primary orders), contractors that receive orders from those contractors (orders to manufacture parts (child parts) that directly constitute the product; secondary orders), contractors that receive orders from those contractors (orders to manufacture grandchild parts that directly constitute the child parts; tertiary orders), and contractors that receive orders from those contractors (orders to manufacture or procure great-grandchild parts (general-purpose items such as screws) that directly constitute the grandchild parts; quaternary orders).

Here, Figure 2 is a diagram explaining the product and part configuration 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.

The token management device 40 mediates orders between purchasers and sellers, and also mediates the issuance and transfer of tokens based on operations related to the manufacture of products carried out based on each order. This operation includes, for example, the manufacture of products by a seller (supplier) in response to an order from a purchaser (another supplier or buyer), as well as the manufacture, procurement, and assembly of each component part of the product.

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 work is performed. The token also contains quantity data. Specifically, a predetermined quantity is set for the tokens issued. Subsequently, a portion of the tokens are divided and transferred sequentially from the purchaser to the contractor, depending on the order content (in this embodiment, the order amount) placed by each purchaser to each contractor in the course of the commercial flow.

These tokens contain information about the order content that caused their issuance or transfer. Therefore, the tokens in this embodiment can be distinguished into tokens issued at the most upstream of the supply chain (upstream tokens) and each token in the supply chain downstream of the upstream tokens that is obtained by dividing and transferring them (downstream tokens).

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 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.

As shown in FIG. 1, the buyer terminal 10 has the following functional units: an order function unit 11, a token issuance request function unit 12, and a token monetization reception function unit 13.

The order function unit 11 requests the token management device 40 to register information about the order (order information) that corresponds to the token management device 40's EDI.

The token issuance request function unit 12 requests the token management device 40 to issue a token to the direct contractor (first supplier terminal 20 or second supplier terminal 30). The owner of the issued token is the direct contractor, but due to the token split transfer, ownership of part of the token is transferred to a contractor further downstream.

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.

Next, the first supplier terminal 20 has an order placement and receipt function unit 21, a token transfer and receipt function unit 22, and a token monetization request function unit 23.

The order placement and receipt function unit 21 processes data related to orders, deliveries, etc., corresponding to the EDI of the token management device 40. For example, the order placement and receipt function unit 21 processes orders received in response to orders from the purchaser (buyer terminal 10, another first supplier terminal 20, or second supplier terminal 30).

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 (to another first supplier terminal 20 or a second supplier terminal 30).

The token fundraising request function unit 23 sends a fundraising request to the token management device 40 based on the tokens owned by itself (the first supplier terminal 20).

Next, the second supplier terminal 30 has a token transfer receipt 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 placement and receipt function unit.

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 (reward setting processing unit).

The order management function unit 41 realizes the function of EDI.
registers an order based on 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).

The token issuance management function unit 42 registers the issuance of tokens (registers ownership to the issuer). The token issuance management function unit 42 also registers the transfer of tokens from the transfer source (buyer terminal 10, first supplier terminal 20, or second supplier terminal 30) to the transfer destination (first supplier terminal 20 or second supplier terminal 30) (registers transfer of ownership).

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

Specifically, the monetization function unit 43 receives a remuneration request from the token owner supplier terminal (first supplier terminal 20 or second supplier terminal 30) that includes 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 remuneration 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 amount of emissions), and if it determines that the amount of greenhouse gas emissions generated meets the target conditions, sets the remuneration information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a specified settlement device associated with the supplier terminal.

In this embodiment, the remuneration request is accompanied by certification information of the amount of greenhouse gas emissions.
That is, the financial function unit 43 determines whether the information regarding greenhouse gas emissions in the remuneration request is authentic based on the certification information in 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.

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

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 product configuration, etc.

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 type of database (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, the data on the blockchain may be distributed and recorded across multiple information processing devices (which may or may not include the token management device 40 itself).

3 is a diagram showing an example of the hardware configuration of each information processing device (the first supplier terminal 20, the second supplier terminal 30, and the token management device 40) in the token management system 1. Each information processing device includes a control device 91 such as a CPU (Central Processing Unit), a main storage device 92 such as a RAM (Random Access Memory) or a ROM (Read Only Memory), an auxiliary storage 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, and a communication device 96 configured from a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Interface) module, a serial communication module, or the like.
When the token management information 200 is recorded as a blockchain (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.

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. 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. All or part of these programs may be realized by a service provided by the cloud system via an API (Application Programming Interface), for example.
Next, the processing performed by the token management system 1 will be described.

<Token management process>
4 and 5 are sequence diagrams illustrating an example of a token management process for placing and receiving orders for the manufacture of products or parts and the associated issuance and transfer of tokens (separated into two diagrams due to space limitations). The token management process is initiated, for example, after the token management device 40 is started.

First, as shown in FIG. 4, the buyer terminal 10, which is the party placing the product order, sends information regarding the supplier and order contents of the primary order (first order information) 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.

Then, the supplier terminal indicated by the supplier information included in the first order information (here, the T1 terminal, which is one of the first supplier terminals 20) sends 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 send a notification of receipt of the first order information to the supplier terminal.

(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.

That is, the first order information 600 consists of basic information 610 and configuration information 620. The basic information 610 includes information on 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 to be ordered 614 (here, product A), an order quantity 615 of the item to be ordered, and a 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.

Then, the T1 terminal places an order (secondary order) for the manufacture of the parts (sub-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 sub-parts of the product indicated in the first order information 600, and the order details (for example, the sub-parts to be ordered and the order amount).

Then, the T1 terminal transmits order information (second order information) including the input information on the supplier and order details 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.

Then, the supplier terminal (T2a terminal) indicated by the supplier information included in the second order information transmits information approving the order (secondary order) from the T1 terminal 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 the T1 terminal, it may also transmit a notification of receipt of the second order information to the T2a terminal.

(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.

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

Note that the configuration of each part in the configuration information 720 of the second order information 700 becomes, for example, part of the configuration of each part in the configuration information 620 of the first order information 600. Also, the order amount 713 is, for example, an amount within the range of the order amount 613 in the first order information 600.

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

Specifically, the T2a terminal receives input from a user associated with the T2a terminal about the 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 the child part indicated in the second order information 700, and the order details (e.g., the grandchild part to be ordered and the order amount). The T2a terminal then transmits information including the supplier and order details (third order information) to the second supplier terminal 30 (T3a terminal) associated with the supplier.

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

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

(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.

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, which is the recipient of the primary order.

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 transferee, the supplier (T2a terminal). 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, respectively, based on the order information (secondary orders for parts A2 and A3), and the owners of the tokens are the transferee, the supplier (T2b terminal, T2c terminal), respectively. The quantity 203 in the second record 211 is the remaining number of tokens (40,000 - 12,000 - 12,000 - 12,000 = 4,000) based on this order information. This remaining number corresponds to the number of tokens related to the manufacturing work that the ordering party (T1 terminal) will carry out itself based on these delivered sub-components.

The sixth record 215 to the eighth record 217 are records related to the transfer of tokens based on each order information (tertiary order) such as the third order information 800. For example, the quantity 203 of the seventh record 216 is the transfer quantity (8,000) 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 token is the transferee (the supplier, T3a terminal). Similarly, the quantity 203 of the eighth record 217 is the transfer quantity (2,000) 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 token is the transferee (the supplier, T3b terminal). The quantity 203 of the sixth record 215 is the remaining quantity of tokens (12,000 - 8,000 - 2,000 = 2,000) based on this order information. This remaining quantity corresponds to the number of tokens for the child part manufacturing operations that the ordering party (T2a terminal) will carry out itself based on these delivered sub-child parts.

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). Upon receiving the token issuance request information, 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 the fact 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).

(Token issuance request information)
10 is a diagram showing an example of token issuance request information 900. The token issuance request information 900 includes information on a token issuer 901 who places the order, a token supplier 902 (here, a T1 terminal) who will be the owner of the token, a quantity 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.

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. The correspondence between such emission intensity and the corresponding value is, for example, made public in advance or distributed for a fee.

The token issuance request information 900 may be generated by the buyer terminal 10 accepting 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 send a notification of token issuance to the buyer terminal 10.

(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 token supplier 1002 who will be the owner of the token, the number of tokens 1003, order details 1004 for products related to the tokens, 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.

Thereafter, as shown in FIG. 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 some of the tokens issued in steps s11 to s13 in accordance with the order details (order from the T1 terminal to the T2a terminal) indicated in the second order information 700. The token management device 40 then registers the transfer of ownership of the tokens (i.e., downstream tokens) indicated in the received first token transfer request information, and transmits information (first token transfer notification information) notifying the supplier (T2a terminal) indicated in the second order information 700 that ownership of (some of) the tokens has been transferred and the details of this transfer (s17).

(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 information such as 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.

The transfer quantity 1104 is calculated by multiplying the order amount 713 in the second order information 700 by the emissions intensity and the token conversion coefficient. For example, if the order amount for part A1-1 is 3 million yen (order amount 713 in the second order information 700), the emissions 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.

(First token transfer notification information)
13 is a diagram showing an example of the first token transfer notification information. The first token transfer notification information 1200 includes the following information: 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 and 1007 of the token issuance request information 900 and the token issuance notification information 1000). The information other than the cash conversion rate 1206 is the same as the information of the first token transfer request information 1100. The first token transfer notification information 1200 does not include information of parties (e.g., the buyer terminal 10) other than the parties to the token transfer (the parties to the order placement and receipt).

Thereafter, as shown in FIG. 4, terminal T2a, which corresponds to the supplier associated with second order information 700, transmits to the token management device 40 (s19) information (second token transfer request information) requesting the transfer of ownership of some of the tokens transferred in steps s15 to s17, in accordance with the order details (order from terminal T2a to terminal T3a) indicated in third order information 800. The token management device 40 then registers the transfer of ownership of the tokens indicated in the received second token transfer request information (i.e., the tokens further downstream from the downstream token of step s15), and transmits information (second token transfer notification information) notifying the supplier (terminal T3a) indicated by the third order information 800 that ownership of (some of) the tokens has been transferred and the details of this transfer (s21).

(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 information such as a token ID 1311, a token transfer source 1312 (terminal T2a in this case), a transfer destination 1313 (terminal T3a in this case) of the token that will become the owner, and a transfer quantity 1314 of the token to be transferred from the transfer source 1312 to the transfer destination 1313.

Configuration information 1320 exists because the second supplier terminal 30 associated with the token transfer destination 1313 (here, a T3a terminal) does not have an order placement and receipt function. In other words, configuration information 1320 is information in the same data format as configuration information 620, 720 of first order information 600 or second order information 700. Configuration information 1320 includes information on the product name 1321 (here, part A1-1) of the grandchild part, which is the item 814 to be ordered in third order information 800, and each of the constituent parts (great-grandchild parts) that make up that 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 that part.

Here, the transfer quantity 1314 in the second token transfer request information 1300 is calculated by multiplying the order amount 813 in the third order information 800 by the emissions intensity and the token conversion coefficient. For example, if the order amount for part A1-1 is 2 million yen (order amount 813 in the third order information 800), the emissions intensity is 4 t-CO2eq, and the token conversion coefficient is 1,000 tokens per 1 t-CO2eq, the transfer quantity 1314 is 2 million yen x 4/1,000 = 8,000 tokens.

(Second token transfer notification information)
15 is a diagram illustrating 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).

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

Specifically, the T3a terminal accepts 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 including the supplier and order details (fourth order information) 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.

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

Here, the contractor for this fourth order, based on the instructions of the ordering party, manufactures or procures parts with lower greenhouse gas emissions than usual. The T4 terminal sends information certifying this greenhouse gas emission amount (emissions certification information) to the T3a terminal (s27).

Then, the orderer of the great-grandchild parts associated with terminal T3a manufactures the part (grandchild part) indicated in the third order information 800 based on the delivered great-grandchild parts and delivers it to the orderer of the grandchild parts associated with terminal T2a (s29). The orderer of the grandchild parts associated with terminal T2a manufactures a child part based on the delivered grandchild part and delivers it to the orderer of the child part associated with terminal T1 (s31). The orderer of the child part associated with terminal T1 manufactures a product based on the delivered child parts and delivers it to the orderer of terminal T10 (s33).

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 task for completing its own business of manufacturing the grandchild parts, as described above. Based on the tokens transferred to it in s21, T3 terminal then sends a monetization request to the token management device 40, including information about the reduced greenhouse gas emissions (s35).

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

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

The funding request basis data 1605 includes certification information. In this embodiment, there are two types of certification information: certified procurement information and certification information.

Certified procurement information is certification 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 a supplier has placed an order for parts necessary for the completion of a contracted business (e.g., the manufacture of parts) based on the contractor's instructions, carrying out a business process such as the manufacture or procurement of those parts.

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

The certified procurement information and low-emissions process information each include information showing how much greenhouse gas emissions at each process have been reduced, based on or by the company's instructions, compared to the standard case.

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

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). Furthermore, the verification information 1708 is, for example, data on 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.

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

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

The equipment emission information 1810 is information about the manufacturing equipment related to the executed process. The equipment emission information 1810 includes an equipment name 1811 of the manufacturing equipment for the product or part for which greenhouse gas emissions have been reduced, a manufacturing process name 1812 of the product or part using the manufacturing equipment, a standard emission amount per unit process in the manufacture of the product or part 1813, an actual emission amount per unit process 1814, an emission reduction amount per unit process 1815, a verifier 1816, and verification information 1817.

Operation history information 1820 is a log of operation data acquired by each manufacturing device. Operation history information 1820 includes the name of the manufacturing device (data source 1821) for the product or part with reduced greenhouse gas emissions, 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.

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

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

Next, as shown in FIG. 5, upon receiving the fundraising request data 1600, the token management device 40 executes a fundraising process s37 in which the token management device 40 calculates the reward corresponding to the fundraising request data 1600 and determines whether to fund it. Details of the fundraising process s37 will be described later.

If the token management device 40 decides to monetize, it sends a notification to the buyer terminal 10 that monetization will be carried out (s39).

When the buyer terminal 10 receives the notification to fund the transaction, it sends information to the token management device 40 permitting payment (granting of reward) corresponding to the fund the transaction request data 1600 (s41).

When the token management device 40 receives notification of the intention to monetize, it executes the payment corresponding to the monetization request data 1600 (s43).

For example, the token management device 40 transmits a request to a specific payment 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 payment device performs payment 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.

In addition, the token management device 40 may send information indicating that the payment has been made to the buyer terminal 10.

<Monetization process>
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).

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 to determine whether there is a record whose token ID 201, quantity 203, and owner 204 correspond to the token ID 1601, owner 1602, and quantity 1603 of the fundraising request data 1600, respectively. Furthermore, the fundraising function unit 43 determines whether the expiration date 206 of that record is after the current time (within the expiration date). At this time, the fundraising function unit 43 acquires the order details 205 of this record to identify the order details related to the fundraising request data 1600.

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

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

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

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.

Specifically, the funding function unit 43 checks whether the item name 1701 in 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.

If the part to be certified is a part that the token owner ordered to complete their own business (s111: OK), the monetization function unit 43 executes the process of s115; if the part to be certified is not a part that the token owner ordered to complete their own business (s111: NG), the monetization process s37 ends (s113).

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.

For example, the funding function unit 43 decrypts the verification information 1708 of the certified procurement information 1700 using a specified encryption key, etc., to confirm that the verification information 1708 was authentically created by the verifier 1707.

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

In s117, the financial function unit 43 identifies the amount of greenhouse gas emissions reduced in the procurement or manufacturing carried out by the supplier. Specifically, the financial function unit 43 obtains the amount of emissions reduced 1706 from the certified procurement information 1700. Then, processing in s129 is performed.

On the other hand, in s119, if the funding request basis data 1605 is low emission process information 1800, the funding 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 its component part, for which the owner of the token identified in s101 (here, the T3a terminal) has received an order to manufacture.

Specifically, the financialization function unit 43 checks whether the item name 1824 in 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.

If the part to be certified is a product or part or a component thereof for which the token owner has received an order to manufacture (s119: OK), the monetization function unit 43 executes the process of s125. If the part to be certified is not a product or part or a component thereof for which the token owner has received an order to manufacture (s119: NG), the monetization process s37 ends (s123).

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

For example, the monetization function unit 43 decrypts the verification information 1817 of the device discharge information 1810 using a predetermined encryption key, etc., to confirm that the verification information 1817 was authentically created by the verifier 1816.

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

In s127, the monetization function unit 43 identifies the amount of greenhouse gas emission reduction. Specifically, the monetization function unit 43 obtains the emission reduction amount 1815 from the equipment emission information 1810, and multiplies the obtained emission reduction amount 1815 by the total value (total number of processes) of the number of processes 1823 for all records in the operation history information 1820. Then, processing in s129 is performed.

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

In s131, the monetization function unit 43 totals all of the greenhouse gas emission reduction amounts identified in the previous processes (s117, s127).

Then, the monetization function unit 43 checks whether the total value calculated in s131 matches the emission reduction amount 1604 in the monetization request data 1600 (s133). If the total value calculated in s131 matches the emission reduction amount 1604 in the monetization request data 1600 (s133: OK), the monetization function unit 43 executes the processing of s135. If the total value calculated in s131 does not match the emission reduction amount 1604 in the monetization request data 1600 (s133: NG), the monetization processing s37 ends (s137).

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

Specifically, the monetization function unit 43 further multiplies the product of the quantity 1603 and the emission reduction amount 1604 in the monetization request data 1600 by the conversion rate 207 of the record related to the order content 205 acquired in s103 in the token management information 200. The monetization function unit 43 transmits notification information to which this multiplication value, i.e., payment amount (remuneration) information, 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).

<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).

For example, as shown in FIG. 20, a buyer terminal 10 (buyer) issues a first token 2001 related to the production of a product, and a portion of this first token 2001 is transferred to Tier 1, Tier 2, and Tier 3 (first supplier terminal 20 or second supplier terminal 30). Meanwhile, Tier 1 can issue a second token 2003 related to the production 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 (first supplier terminal 20 or second supplier terminal 30).

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.

In such a case, when the token management device 40 receives multiple pieces of 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 pieces of 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.

Specifically, first, the monetization function unit 43 of the token management device 40 receives a first remuneration 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 remuneration request, sets remuneration information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a payment device associated with the supplier terminal.

Then, when the monetization function unit 43 receives a second reward request (monetization request) from the same supplier terminal for a token recording 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, does it set the reward information from the buyer terminal 10 to the supplier terminal or the payment device associated with the supplier terminal based on the second reward request.

Figure 21 is a diagram illustrating an example of a method for determining the identity of funding request data 1600. As shown in the figure, if the funding function unit 43 previously received funding request data 1600 from a supplier terminal and funded it, and then receives funding request data 1600 from the same supplier terminal, it will check the certified procurement information 1700 and low-emission process information 1800 attached to the two funding requests.

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 each of 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 is not performed for the later received funding request data 1600.

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

Note that the certification information used for the duplication check described here is just one example. Other certification information may be used as long as it can confirm the identity of the funding request data 1600.

As described above, the token management device 40 of this embodiment receives a monetization request from the device to which the work is being requested (for example, the first supplier terminal 20 or second supplier terminal 30 that has received an order directly or indirectly from the buyer terminal 10) that includes information about the greenhouse gas emissions generated by the work indicated by the issued token, 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, in the device to which the work is being requested or the payment device associated therewith, information about the reward from the buyer (buyer terminal 10), who is the party requesting the work (the party ordering the work), to the device to which the work is being requested.

In other words, if a contractor of a work reduces greenhouse gas emissions in the course of that work, the token management device 40 can provide an incentive to the contractor from the business orderer. This can encourage those who perform the work at their request (for example, those at the end of the supply chain) to reduce greenhouse gas emissions.

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.

In this way, the token management device 40 mediates token-related processing between the requester and the requestee. Therefore, when the requestee (each supplier terminal) reduces greenhouse gas emissions and claims compensation in the form of tokens, it does not need to provide the requester (buyer terminal 10) with any information other than information about greenhouse gas emissions (for example, information about the contracting parties), thereby ensuring the confidentiality of business operations.

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 registered in the token that represent the amount of greenhouse gas emissions according to the content of the work (in this embodiment, the order amount, emission unit, token conversion coefficient, etc.), calculates a remuneration based on the calculated amount of greenhouse gas emissions, and sets the remuneration information from the buyer (buyer terminal 10), who is the requester (business orderer), to the device to which the work is requested or the payment device associated with it, to the device to which the work is requested.

This will allow incentives to be given according to the amount of greenhouse gas reduction, thereby promoting the reduction of greenhouse gas emissions.

In addition, 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 reward request accompanied by information regarding the amount of greenhouse gas emissions generated in order to complete 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 reward information from the buyer terminal 10 to the supplier terminal in the supplier terminal or a payment 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, etc.) of the component parts in the manufacturing of the component parts (manufacturing of child parts, manufacturing of grandchild parts, etc.), which is a task requested by the requestee (supplier terminal) to another requestee (another supplier terminal). When the token management device 40 receives a reward request accompanied by information regarding the amount of greenhouse gas emissions generated to accomplish the work 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 the payment device associated with the supplier end.

In this way, the token management device 40 sets tokens for each task from upstream to downstream that correspond to the order details (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 the supply chain), in a supply chain involving multiple companies from top tier companies to bottom tier companies, to reduce greenhouse gas emissions. Furthermore, even when the ties between top tier companies and bottom tier companies are weak (for example, when no special contracts regarding greenhouse gas emission reductions have been made between tier companies), these tokens can be used to motivate and provide incentives to each tier company to reduce greenhouse gas emissions.

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.

In this way, by checking the authenticity of greenhouse gas emissions, rewards can be set only when they are deserving of consideration.

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 a process that reduced 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.

This will ensure that when a contractor reduces greenhouse gas emissions by procuring or ordering parts based on their own instructions, the authenticity of the reduction can be confirmed.

In addition, the token management device 40 of this embodiment receives a remuneration request accompanied by certification information (low-emission process information 1800) that certifies 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.

This will ensure that if the contractor themselves reduces greenhouse gas emissions, the authenticity of the reduction can be confirmed.

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 they relate to the manufacture of different parts) does the token management device 40 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.

This eliminates fraudulent remuneration claims, such as when a supplier terminal claims remuneration multiple times for the same reason.

In addition, the token management device 40 of this embodiment transmits information regarding the reward to the buyer terminal 10 when setting information regarding the reward from the requester (buyer terminal 10) to the requestee.

This allows the buyer to know that a reduction in greenhouse gas emissions related to their own business has been achieved and that a reward will be or has been provided for this. This allows the buyer, for example, to confirm in advance that a reward will be provided and to submit various reports (e.g., ESG (Environment, Social, Governance) reports, etc.) regarding the reduction in greenhouse gas emissions.

In addition, 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 this issuance request. This allows the buyer to issue the token at the timing they desire.

The present invention is not limited to the above-described embodiments, and can be implemented using any components within the scope of the gist of the invention. The embodiments and modifications described above 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, while various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the technical spirit of the present invention are also included within the scope of the present invention.

For example, some of the hardware provided in each device in this embodiment may be provided in another device.

Furthermore, each program of each device may be provided on another device, a program may consist of multiple programs, or multiple programs may be integrated into a single program.

In addition, in this embodiment, the division of tokens (division of quantity) is performed according to the order amount, but the division may also be performed based on other criteria (for example, criteria determined by the purchaser/seller or contract).

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

In addition, in this embodiment, the timing at which 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 has been completed, but this is just one example and other timings are also possible. Furthermore, the timing of the token transfer may be after delivery, rather than before delivery as in this embodiment, as long as the order placement and receipt has been completed.

Furthermore, 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 placement or receipt has been made.

Furthermore, in this embodiment, the low-emission process information 1800 includes apparatus emission information 1810 and operation history information 1820, but it may also include only one of them.

Furthermore, in this embodiment, product manufacturing has been used as an example of a token-related business, but the present invention can also be applied to other types of business.

1 Token management system, 10 Buyer terminal, 20 First supplier terminal, 30 Second supplier terminal, 40 Token management device, 43 Monetization function unit

Claims (11)

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 token management device comprising: a control device that receives a reward request from an information processing device associated with the request recipient, the reward request being 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 determines that the amount of greenhouse gas emissions generated satisfies the target condition, executes a reward setting process in the information processing device or a device associated with the information processing device to set information regarding the reward from the requester to the request recipient. 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 . 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 . 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 . 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. 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. 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. 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 . 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. 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 token management 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 determines 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. The token management system of claim 10, comprising a plurality of token management devices, the plurality of token management devices working together to store the tokens in a distributed manner.