Transaction program and transaction system

Abstract

To provide a transaction program and transaction system capable of achieving an original purpose of protecting the natural environment while promoting circulation of credits generated through project certification.SOLUTION: A transaction server 14, after receiving an issue request from a parent terminal 18, issues a CC-NFT (12) including project information 54 relating to a project or associated with the project information 54, and outputs transaction data D1 representing content of the transaction processing to a block chain (BC) each time transaction processing relating to the CC-NFT (12) is performed. The CC-NFT (12) is data representing an ownership transfer right, the right to request a guardian to transfer ownership of the credit generated through project certification in a register managed by a certification organization.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a trading program and a trading system. [Background technology]

[0002] Recently, various efforts have been made to protect the natural environment as part of the Sustainable Development Goals. For example, Japan is making efforts to contribute to the reduction of greenhouse gas emissions by utilizing the J-Credit Scheme. The J-Credit Scheme is a system in which the government certifies the amount of greenhouse gas emissions reductions and absorptions achieved through initiatives such as the introduction of energy-saving equipment and forest management as carbon credits (greenhouse gas emission rights). As a result, various technologies related to the electronic trading of carbon credits have been proposed.

[0003] Patent Document 1 discloses a trading system configured to provide carbon credits from a service provider to a purchaser when the purchase of carbon credits is made through an intermediary.

[0004] Patent document 2 discloses a computer that calculates an index indicating the degree of difficulty in achieving carbon dioxide emission reduction targets for each company that wishes to purchase credits, and extracts companies as potential buyers of credits in order of increasing difficulty. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2023-026906 [Patent Document 2] Japanese Patent Publication No. 2022-171104 Summary of the Invention [Problem to be solved by the invention]

[0006] Incidentally, in order to promote distribution and transparency, it is expected that carbon credits will be tokenized as non-fungible tokens (hereinafter referred to as "NFTs") and managed on a blockchain. However, if the value of carbon credits is transferred to tokens on a blockchain, the location of that value and offset history cannot be managed in the registry managed by the certification organization, and therefore many carbon credit certification organizations, including J-Credit, prohibit tokenization.

[0007] Furthermore, natural resource protectors incur significant costs in the application and monitoring required to generate carbon credits, and are forced to manage them at risk because there is no guarantee that the generated carbon credits will be sold. Therefore, simply tokenizing and promoting distribution may not achieve the original purpose of "protecting the natural environment."

[0008] The present invention was made in consideration of these problems, and its purpose is to provide a trading program and trading system that can promote the circulation of credits created as a result of project certification while achieving the original purpose of protecting the natural environment. [Means for solving the problem]

[0009] A trading program in a first aspect of the present invention causes one or more computers to execute the following steps: a receiving step of receiving an authorization signal to authorize the issuance of a non-fungible token before a natural resource protector applies to a certification body for certification of a project to protect the natural environment, or before the certification body certifies the project; an issuance step of issuing the non-fungible token, which includes project information related to the project or is linked to the project information, at least after receiving the authorization signal; and an output step of outputting transaction data indicating the content of the transaction to a blockchain each time a transaction process related to the issued non-fungible token occurs, wherein the non-fungible token is data indicating a title transfer right, which is a right to request the protector to change the name of a credit created as a result of the certification of the project, in a registry managed by the certification body.

[0010] A trading system in a second aspect of the present invention comprises a guardian terminal owned by a guardian of natural resources and a trading server capable of communicating with the guardian terminal, wherein the trading server executes the following steps: a reception step of receiving from the guardian terminal an authorization signal to authorize the issuance of a non-fungible token before the guardian applies to a certification body for certification of a project to protect the natural environment, or before the certification body certifies the project; an issuance step of issuing the non-fungible token that includes project information related to the project or is linked to the project information, at least after receiving the authorization signal; and an output step of outputting transaction data indicating the contents of the transaction process to a blockchain each time a transaction process is performed regarding the issued non-fungible token, wherein the non-fungible token is data indicating a name change right, which is a right to request the guardian to change the name of the credit created upon certification of the project, in a registry managed by the certification body. [Effects of the Invention]

[0011] According to the present invention, it is possible to achieve the original purpose of protecting the natural environment while promoting the circulation of credits created as a result of the certification of a project. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is an overall configuration diagram of a trading system according to one embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram of the trading server shown in FIG. 1. [Figure 3] FIG. 2 is a diagram showing an example of a transaction conducted through the trading system of FIG. 1. [Figure 4] 3 is a flowchart showing an example of a trading operation by the trading server of FIGS. 1 and 2. [Figure 5] 3 is a diagram showing an example of a data structure of a state table in FIG. 2. FIG. [Figure 6] 3 is a diagram illustrating an example of a data structure of an authority table in FIG. 2. FIG. [Figure 7] FIG. 2 is a first sequence diagram of the operation of the trading system shown in FIG. [Figure 8] FIG. 2 is a second sequence diagram of the operation of the trading system shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. To facilitate understanding of the description, the same components in each drawing will be denoted by the same reference numerals as much as possible, and duplicate explanations will be omitted. Furthermore, the term "part" may be replaced with other terms such as unit, module, device, or element.

[0014] [Configuration of Trading System 10] <Overall structure> 1 is a diagram showing the overall configuration of a trading system 10 according to one embodiment of the present invention. The trading system 10 is configured to be able to provide a "trading support service" for supporting carbon credit (hereinafter simply referred to as "credit") trading while utilizing a blockchain BC.

[0015] "Carbon credits" are environmental values ​​that indicate the reduction effect (amount of reduction or absorption) of greenhouse gases, including carbon dioxide, and can be traded. Examples of carbon credit systems include J-Credit, VSC (Verified Carbon Standard), and "Gold Standard."

[0016] A blockchain BC is a database that directly connects terminals (so-called blockchain nodes) on a network NW and processes and records data indicating transaction details (hereinafter referred to as "transaction data D1") in a distributed manner using cryptographic technology. The type of blockchain BC may be public, private, or consortium.

[0017] The transaction data D1 includes a non-fungible token (hereinafter referred to as "CC-NFT12") related to the trading of carbon credits. This CC-NFT12 is data indicating the right to request the protector to change the name of the credits created upon the certification of the project in a registry managed by the certification authority, known as the "title transfer right." This CC-NFT12 is bought and sold in predetermined units (specifically, one ton of carbon dioxide) using virtual currency or legal tender such as Japanese yen.

[0018] Specifically, the trading system 10 includes a trading server 14 , a trader terminal 16 , a guardian terminal 18 , an administrator terminal 20 , and an authentication authority server 22 .

[0019] The trading server 14 is a computer that performs overall control over the above-mentioned trading support services, and may be either a cloud-based or on-premise type. Here, the trading server 14 is illustrated as a single computer, but the trading server 14 may instead be a group of computers that form a distributed system. The specific device configuration of the trading server 14 will be described in detail later with reference to FIG. 2.

[0020] The trader terminal 16 is a computer owned by a trader of CC-NFT 12. The trader terminal 16 may be a portable device such as a tablet, laptop, smartphone, or wearable device, or a stationary device such as a personal computer. Specifically, the trader terminal 16 includes a processor 31, a memory 32, an input device 33, an output device 34, and a communication unit 35. A user interface (UI) is constructed by combining the input function of the input device 33 and the output function of the output device 34.

[0021] The guardian terminal 18 is a computer owned by a guardian of natural resources, and may have a similar or different device configuration to the trader terminal 16. The guardian is an organization that promotes an environmental value project (hereinafter simply referred to as a "project") to protect natural resources, such as a company, a university, a local government, a country, or a consortium.

[0022] The administrator terminal 20 is a computer owned by the administrator of the above-mentioned transaction support service, and has a device configuration similar to or different from that of the trader terminal 16. The administrator can take necessary actions related to the transaction support service (for example, registering and updating information on natural resources as a substitute for a guardian, changing user information, etc.) via the administrator terminal 20.

[0023] The certification authority server 22 is a computer owned by the certification authority of the project, and may have a similar or different device configuration to the trader terminal 16. The certification authority server 22 manages the created credits in a web-based registry. The certification authority may be, for example, a country, a company, a non-profit organization (NPO), a non-governmental organization (NGO), or a consortium.

[0024] <Configuration of trading server 14> Fig. 2 is a block diagram of the trading server 14 shown in Fig. 1. The trading server 14 includes a communication unit 40, a control unit 42, and a storage unit 44.

[0025] The communication unit 40 is an interface for transmitting and receiving electrical signals to and from external devices, which allows the trading server 14 to transmit transaction data D1 to the blockchain BC and metadata D2 to the trader terminal 16.

[0026] The control unit 42 is configured by a processor including a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit). The control unit 42 reads and executes programs and data stored in the storage unit 44, thereby functioning as a browsing processing unit 50, an operation receiving unit 52, and a transaction processing unit 54.

[0027] The browsing processing unit 50 generates display data including various screen information related to the above-mentioned transaction support service, and instructs an external device including the trader terminal 16 to display various screens indicated by the display data. When a web application is used, the display data includes text data written in accordance with HTML (Hyper Text Markup Language) and CSS (Cascading Style Sheets).

[0028] The operation reception unit 52 receives various operations from external devices, including the trader terminal 16. Examples of these operations include: [1] an operation to request project registration; [2] an operation to authorize the issuance of a CC-NFT 12; [3] an operation to request viewing of the CC-NFT 12 that is the subject of the transaction; [4] an operation to request the purchase or sale of a CC-NFT 12; [5] an application or approval for the transfer of credits; or [6] an operation to consume credits.

[0029] The transaction processing unit 54 performs various data processing related to transactions of CC-NFTs 12. Specifically, the transaction processing unit 54 includes a transaction management unit 56, a data generation unit 58, and a data output unit 60.

[0030] The transaction management unit 56 detects events related to the transaction of CC-NFTs 12 (hereinafter referred to as "transaction events") and manages transaction processing for each transaction event. Examples of transaction events include [1] issuance of a CC-NFT 12, [2] data update of a CC-NFT 12, [3] purchase or sale of a CC-NFT 12, [4] invalidation or revocation of a CC-NFT 12, or [5] transfer of credits.

[0031] The transaction management unit 56 manages the certification status of a project or the existence status of a CC-NFT 12 by successively updating the status table 66. Examples of starting points for identifying a certification status include [1] when a project applies for certification, [2] when a monitoring evaluation is reported, [3] when a project is certified, [4] when a credit transfer application is made, or [5] when a credit transfer is approved. Examples of existence statuses include unissued, valid, expired, or expired.

[0032] The transaction management unit 56 refers to the status table 66 and the authorization table 68 and grants transaction authorization for the transaction of the corresponding CC-NFT 12 to users involved in the transaction event. This transaction authorization differs depending on the type of user. For example, if the user type is a "trader," the trader is granted the authorization to view, purchase, and sell CC-NFTs 12, or the authorization to request and consume credit transfers. For example, if the user type is a "guardian," the guardian is granted the authorization to issue CC-NFTs 12, view CC-NFTs 12, and approve credit transfers.

[0033] The data generation unit 58 generates various data related to credit transaction support, specifically, a CC-NFT 12, transaction data D1, and metadata D2. The CC-NFT 12 includes project information 64, which will be described later, or is linked to the project information 64. When the CC-NFT 12 holds project information 64, the project information 64 may include, for example, a project application number, a project certification number, or monitoring evaluation results related to the project.

[0034] The data generation unit 58 issues (or generates or mints) a CC-NFT 12 at least after receiving a signal authorizing the issuance of the CC-NFT 12 (hereinafter referred to as the authorization signal). Examples of the timing of issuance include [1] the time when the authorization signal is received, or [2] the time when a purchase request signal is received from the trader terminal 16.

[0035] The data output unit 60 outputs the transaction data D1 generated by the data generation unit 58 to the blockchain BC. In addition, when the data output unit 60 receives a viewing request from an external device including the trader terminal 16, it outputs the metadata D2 generated by the data generation unit 58 to the external device.

[0036] The storage unit 44 stores programs and data necessary for the control unit 42 to control each component. The storage unit 44 is a non-transitory, computer-readable recording medium. In the example of Fig. 2, the storage unit 44 stores user information 62, project information 64, a status table 66, and an authority table 68 in addition to the transaction data D1 and metadata D2.

[0037] The user information 62 includes various information about users of the transaction support service. Examples of the user information 62 include [1] personal information including name, title, and address, [2] network information including terminal host name, email address, and nickname, or [3] service information including account name and user attributes.

[0038] The project information 64 includes various information about the project. Examples of the project information 64 include the project application number, implementing body, name, scheme, implementation period, progress status, certification number, certification body, the amount of environmental value that is expected to be created through the project, or the amount of environmental value that has actually been created by the project.

[0039] The state table 66 is data in a table format that describes the authentication state of the project or the existence state of the CC-NFT 21. A specific example of the state table 66 will be described in detail later with reference to FIG.

[0040] The authority table 68 is data in a table format that describes rules for granting transaction authority. A specific example of the authority table 68 will be described in detail later with reference to FIG.

[0041] The transaction data D1 includes transaction information indicating the details of the transaction processing performed by the transaction processing unit 54. Examples of transaction information include [1] transaction history including transaction date and time, purchase quantity, and unit price, [2] party information including seller and purchaser, or [3] token information including CC-NFT12.

[0042] The metadata D2 includes various information associated with the CC-NFT 12. Examples of the metadata D2 include [1] the name and description of the CC-NFT 12, [2] location information including a uniform resource locator (URL), or [3] part of the project information 64.

[0043] [Operation of Trading System 10] The trading system 10 in this embodiment is configured as described above. Next, the operation of the trading system 10 will be described with reference to FIGS.

[0044] FIG. 3 is a diagram showing an example of a transaction conducted through the trading system 10 of FIG. 1. In the example of FIG. 3, the timeline of the transaction is divided into three phases from left to right. The upper part of FIG. 3 shows the transaction on the certification authority's registry, and the lower part of FIG. 3 shows the transaction on the trading system 10. Here, we will explain an example in which a "protector" of natural resources, an individual trader "Mr. A," and a corporate trader "Company B" are involved in the transaction.

[0045] (First phase: J-Credit not yet created) Prior to applying for project certification, the guardian applies for the issuance of a CC-NFT 12 via the trading system 10. This results in the issuance of an uncertified CC-NFT 12. The guardian then applies for project certification to a certification body, and after the project undergoes monitoring and evaluation, the project can be certified. Once issued, this CC-NFT 12 can be sold to a third party on the trading system 10 (equivalent to a "primary sale"). Below, we will assume that Person A purchases an uncertified CC-NFT 12 through this primary sale.

[0046] (Phase 2: J-Credits already generated) After the project is certified, the guardian applies for an addition to the CC-NFT 12 via the trading system 10. This changes the status of the CC-NFT 12 from "uncertified" to "certified." As in the first phase, the certified CC-NFT 12 can be sold to a third party on the trading system 10 (equivalent to a secondary sale). Below, we will assume that Person A sells the certified CC-NFT 12 to Company B through this secondary sale.

[0047] (Phase 3: Offset) Company B applies for the consumption of credits corresponding to the authenticated CC-NFT 12 via the trading system 10. The guardian approves the application from Company B and rewrites the name of the credits in the registry managed by the authentication authority. Furthermore, upon the above approval, the state of the CC-NFT 12 transitions from "active" (transferable) to "passive" (non-transferable). Company B then exercises the carbon offset by consuming the credits under legitimate ownership.

[0048] FIG. 4 is a flowchart showing an example of a trading operation by the trading server 14 of FIGS.

[0049] In step SP10, the transaction processing unit 54 (more specifically, the transaction management unit 56) detects an event related to the transaction of the CC-NFT 12 (that is, a transaction event).

[0050] In step SP12, the transaction management unit 56 identifies the CC-NFTs 12 and users involved in the transaction event detected in step SP10. Hereinafter, the identified CC-NFTs 12 will be referred to as the "relevant tokens," and the identified users will be referred to as the "relevant users."

[0051] In step SP14, the transaction management unit 56 reads and acquires the latest status table 66 and authority table 68 from the storage unit 44.

[0052] Fig. 5 is a diagram showing an example of the data structure of the status table 66 in Fig. 2. This status table 66 is data in a table format showing the correspondence between [1] identification information of the CC-NFT 12 (hereinafter, token ID), [2] "metadata" of the CC-NFT 12, and [3] "status" indicating the authentication status of the project or the survival status of the CC-NFT 12. In the example of Fig. 5, the status is defined by status values ​​indicating ST1 to ST6.

[0053] "ST1" indicates a state where a project has not yet applied for certification. "ST2" indicates a state where a project has applied for certification but has not yet been certified. "ST3" indicates a state where a project has been certified but no credits have yet been transferred. "ST4" indicates a state where credits have yet to be consumed but have been transferred. "ST5" indicates a state where the CC-NFT12 has expired. "ST6" indicates a state where a CC-NFT12 has expired.

[0054] FIG. 6 is a diagram showing an example of the data structure of the authority table 68 in FIG. 2. This authority table 68 is a table-formatted data showing the correspondence between [1] "user attributes" indicating the type of user, [2] "status" indicating the authentication status of the project or the existence status of the CC-NFT 12, and [3] the presence or absence of each trading authority. In the example of FIG. 6, the user attributes include trader or guardian. Also, in the example of FIG. 6, the trading authorities include the authority to issue, view, and buy / sell CC-NFTs 12, as well as the authority to request, approve, and consume credit transfers.

[0055] According to this authority table 68, "token issuance authority" is granted to traders in status "ST1." "Token viewing authority" is granted to traders and guardians in all statuses. In addition, in statuses "ST4 to ST6," to distinguish them from "ST1 to ST3," computer-generated art (i.e., generative art) is displayed. "Token buying and selling authority" is granted to traders in statuses "ST1 to ST2."

[0056] According to this authority table 68, "transfer application authority" is granted to a transactor whose status is "ST3." "transfer approval authority" is granted to a guardian whose status is "ST3." "credit consumption authority" is granted to a transactor whose status is "ST4."

[0057] 4, the transaction management unit 56 grants the user transaction authority for trading the token identified in step SP12. Specifically, the transaction management unit 56 refers to the status table 66 and the authority table 68 acquired in step SP14, and selects the transaction authority for the token corresponding to the current status.

[0058] In step SP18, the transaction processing unit 54 processes the transaction in accordance with the user authority granted in step SP16. Specifically, the data generation unit 58 generates transaction data D1 according to the content of the transaction. The data output unit 60 outputs the transaction data D1 generated by the data generation unit 58 to the blockchain BC.

[0059] In step SP20, the transaction processing unit 54 (more specifically, the transaction management unit 56) updates the contents of the status table 66 as necessary. Thereafter, the transaction processing unit 54 can sequentially perform transaction processing related to the CC-NFT 12 by repeatedly executing the flowchart shown in FIG.

[0060] <Specific action> Next, specific operations of the trading system 10 will be described with reference to the sequence diagrams of Figures 7 and 8. The order in which the steps of these sequences are executed may be changed as needed.

[0061] 7 is a first sequence diagram relating to the operation of the trading system 10. This first sequence shows a series of operations relating to the issuance and purchase of CC-NFTs 12.

[0062] In step SP30, the parent terminal 18 starts a Web application and displays a registration screen (not shown) provided by the transaction server 14.

[0063] In step SP32, the parent terminal 18 accepts a predetermined input operation (i.e., a permission operation) for registering the project via the registration screen being displayed in step SP30. Then, the parent terminal 18 transmits a signal for permitting the issuance of the CC-NFT 12, which signal includes the user information 62 and the project information 64 (hereinafter, a permission signal), to the trading server 14.

[0064] In step SP34, the transaction server 14 receives the permission signal sent in step SP32 and thereby accepts the permission signal for issuance.

[0065] In step SP36, the trading server 14 acquires the project information 64 contained in the permission signal received in step SP34. The trading server 14 updates the project information 64 and the status table 66, thereby registering a new project.

[0066] In step SP38, the trader terminal 16 launches a web application and displays a trading screen (not shown) provided by the trading server 14. On this trading screen, the CC-NFT 12 corresponding to the project registered in step SP36 is displayed as the trading target.

[0067] In step SP40, the trader terminal 16 accepts a predetermined input operation (i.e., a purchase operation) for purchasing the CC-NFT 12 via the transaction screen displayed in step SP38. The trader terminal 16 then transmits to the trading server 14 a signal requesting the purchase of the CC-NFT 12, which signal includes the purchase conditions and user information 62 (hereinafter, a purchase request signal).

[0068] In step SP42, the transaction server 14 issues CC-NFTs 12 for the purchase quantity in accordance with the purchase conditions included in the purchase request signal transmitted in step SP40.

[0069] In step SP44, the transaction server 14 generates transaction data D1 indicating that the CC-NFT 12 was issued in step SP42, and outputs the transaction data D1 to the blockchain BC.

[0070] In step SP46, the transaction server 14 performs accounting processing for the CC-NFT 12 purchased through steps SP40 to SP44 between the transactor terminal 16 and the guardian terminal 18. In this way, the issuance and purchase of the CC-NFT 12 is carried out according to the first sequence in FIG.

[0071] 8 is a sequence diagram relating to a second operation of the transaction system 10. More specifically, this sequence shows a series of operations relating to the consumption of credits.

[0072] In step SP50, the trader terminal 16 starts the Web application and displays an application screen (not shown) provided by the trading server 14.

[0073] In step SP52, the trader terminal 16 accepts a predetermined input operation (i.e., an application operation) for applying for a credit transfer via the application screen being displayed in step SP50. Then, the trader terminal 16 transmits to the trading server 14 a signal (hereinafter, an application signal) for applying for a credit transfer, which signal includes the application conditions and user information 62.

[0074] In step SP54, the transaction server 14 accepts the application signal sent in step SP52 and sends a signal (hereinafter referred to as an approval request signal) to the parent terminal 18 requesting approval of the application, the signal including the application conditions and user information 62.

[0075] In step SP56, the parent terminal 18 performs an operation to approve the credit transfer on an approval screen (not shown) in response to the approval request signal transmitted in step SP54. Then, the parent terminal 18 transmits a signal approving the credit transfer (hereinafter, "approval signal") to the transaction server 14.

[0076] In step SP58, if the transaction server 14 receives the approval signal sent in step SP56, it restricts the transfer of the CC-NFT 12.

[0077] In step SP60, the transaction server 14 generates transaction data D1 indicating that the transfer of CC-NFT12 has been restricted in step SP60, and outputs the transaction data D1 to the blockchain BC.

[0078] In step SP62, the parent terminal 18 performs a "name change process" to request the authentication institution server 22 to change the name of the credit whose transfer was approved in step SP56. The name change process may be performed automatically via the parent terminal 18 or the transaction server 14, or may be performed manually through an input operation via the parent terminal 18.

[0079] In step SP64, after the name change process in step SP62 is completed, the trader terminal 16 accepts a predetermined input operation (i.e., a notification operation) via an approval screen (not shown). Then, the trader terminal 16 transmits a signal indicating that the credit transfer has been completed (hereinafter, a completion notification signal) to the trading server 14.

[0080] In step SP66, the transaction server 14 transmits a signal indicating that the transfer of credits has been completed (that is, a completion notification signal) to the trader terminal 16 in response to the completion notification signal transmitted in step SP64.

[0081] In step SP68, after receiving the completion notification signal in step SP66, the trader terminal 16 performs a "consumption process" to request the authentication institution server 22 to consume credits at a desired timing. The consumption process may be performed automatically via the trader terminal 16, or may be performed manually through an input operation via the trader terminal 16. In this way, the credits are consumed according to the second sequence of FIG. 8.

[0082] [Summary of the embodiment] As described above, the trading system 10 in this embodiment is composed of a trader terminal 16 owned by the trader, a guardian terminal 18 owned by the guardian of the natural resource, and a trading server 14 capable of communicating with the trader terminal 16 and the guardian terminal 18.

[0083] The transaction server 14 includes an operation receiving unit 52 that receives an authorization signal from the parent terminal 18 to authorize the issuance of a CC-NFT 12 before the parent applies for project certification to a certification body or before the certification body certifies the project, a data generation unit 58 that issues a CC-NFT 12 that includes project information 64 related to the project or is linked to the project information 64 at least after receiving the authorization signal, and a data output unit 60 that outputs transaction data D1 indicating the contents of the transaction process to the blockchain BC each time a transaction process related to the issued CC-NFT 12 occurs.

[0084] According to the trading method and trading program of this embodiment, one or more computers (here, trading server 14) execute a receiving step (SP34 in FIG. 7) of receiving an authorization signal to authorize the issuance of a CC-NFT12 before the guardian applies to the certification body for project certification or before the certification body certifies the project, an issuing step (SP42 in FIG. 7) of issuing a CC-NFT12 at least after receiving the authorization signal, and an output step (SP44 in FIG. 7, SP60 in FIG. 8) of outputting transaction data D1 indicating the contents of the transaction process to the blockchain BC each time a transaction process related to the issued CC-NFT12 occurs.

[0085] CC-NFT12 is data representing the transfer right, which is the right to request the protector to change the name of the credits created upon project certification in a registry managed by the certification authority. By capitalizing the credit transfer right using a non-fungible token and restricting its use, it is possible to ensure that the creation and consumption of credits are managed in the certification authority's registry, while also ensuring transparency in the transactions and use of the transfer right on the blockchain (BC). This facilitates the promotion of the circulation of credits created upon project certification while achieving the original goal of protecting the natural environment.

[0086] In particular, by issuing CC-NFT12 before a project applies for certification, protectors will be able to more easily raise funds to advance their projects through trading CC-NFT12, even before credits are created.

[0087] The trading server 14 may further execute an identification step (SP12 in FIG. 4) of identifying users involved in the trading process, and an assignment step (SP16) of assigning different trading privileges to the identified users depending on the authentication status of the project, thereby enabling the users to perform trading appropriate to the authentication status of the project.

[0088] Additionally, if a user is a trader of a CC-NFT 12, the trader may not be authorized to request a transfer of credits before the credits are created, but may be authorized to request a transfer of credits after the credits are created, thereby preventing confusion over the rights between the credits and the CC-NFT 12 if the credits are not created.

[0089] Additionally, if the user is a natural resource protector, the protector may be authorized to approve a trader's request for credit transfer, allowing the protector to, for example, determine the trader's eligibility and then make a decision on whether or not to transfer credits.

[0090] In addition, in the output steps (SP40, SP60), the trading server 14 may output the transaction data D1 so that authentication information regarding the authentication of the project is stored in the CC-NFT 12. The authentication information may also include the project application number, the project authentication number, or the monitoring evaluation results for the project. By analyzing the CC-NFT 12, the authentication status of the project can be directly identified.

[0091] [Variations] The present invention is not limited to the above-described embodiments, and can be freely modified without departing from the spirit and scope of the present invention. Alternatively, the respective configurations may be arbitrarily combined within the scope of no technical contradiction. Alternatively, the execution or execution order of each step constituting the flowchart or sequence diagram may be changed within the scope of no technical contradiction.

[0092] In the above embodiment, the case where the non-fungible token is linked to a carbon credit has been described as an example, but the non-fungible token may be linked to various credits created through the certification of a project by a certification body. Examples of credits include blue carbon credits and biodiversity credits (more specifically, ecosystem credits or species credits). [Explanation of symbols]

[0093] 10...Trading system, 12...CC-NFT (non-fungible token), 14...Trading server, 16...Trader terminal, 18...Guardian terminal, 50...Viewing processing unit, 52...Operation reception unit, 54...Trading processing unit, 64...Project information, 66...Status table, 68...Authorization table, BC...Blockchain, D1...Transaction data, D2...Metadata

Claims

1. a receiving step of receiving an authorization signal to authorize the issuance of non-fungible tokens before a natural resource protector applies to a certification body for certification of a project for protecting the natural environment or before the certification body certifies the project; an issuance step of issuing the non-fungible token including project information related to the project or linked to the project information after receiving at least the permission signal; an output step of outputting transaction data indicating the content of the transaction to a blockchain each time a transaction process related to the issued non-fungible token occurs; on one or more computers, A trading program in which the non-fungible token is data indicating a title transfer right, which is a right to request the guardian to change the title of credits created upon certification of the project in a registry managed by the certification authority.

2. an identifying step of identifying a user involved in the transaction process; an granting step of granting different transaction authorities to the identified user depending on the authentication status of the project; causing the one or more computers to execute The trading program of claim 1.

3. If the user is a transactor of the non-fungible token, The trader is not authorized to request a transfer of the credits before the credits are created, but is authorized to request a transfer of the credits after the credits are created; 3. The trading program of claim 2.

4. If the user is the guardian, The guardian is authorized to approve the trader's request for the transfer of the credit; 4. The trading program of claim 3.

5. The one or more computers In the output step, the transaction data is output so that authentication information regarding authentication of the project is held in the non-fungible token. The trading program of claim 1.

6. The certification information includes the application number of the project, the certification number of the project, or the results of monitoring evaluations related to the project; 6. The trading program of claim 5.

7. a guardian terminal owned by the natural resource guardian; a transaction server capable of communicating with the parent terminal, The trading server: a receiving step of receiving, from the guardian terminal, a permission signal for permitting the issuance of non-fungible tokens before the guardian applies to a certification body for certification of a project for protecting the natural environment, or before the certification body certifies the project; an issuance step of issuing the non-fungible token including project information related to the project or linked to the project information after receiving at least the permission signal; an output step of outputting transaction data indicating the content of the transaction to a blockchain each time a transaction process related to the issued non-fungible token is performed; Run A trading system in which the non-fungible token is data indicating a title transfer right, which is a right to request the guardian to change the title of credits created upon certification of the project in a registry managed by the certification authority.

Images