特許 7510732 取引プログラム及び取引システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-06-26

(45)【発行日】2024-07-04

(54)【発明の名称】取引プログラム及び取引システム

(51)【国際特許分類】

   G06Q 40/04 20120101AFI20240627BHJP

【ＦＩ】

G06Q40/04

【請求項の数】 7

(21)【出願番号】P 2024038527

(22)【出願日】2024-03-13

【審査請求日】2024-04-17

【新規性喪失の例外の表示】特許法第３０条第２項適用 令和５年８月２３日、ウェブサイト ｈｔｔｐｓ：／／ｐｏｒｔａｌ．ｓｉｎｒａ．ａｐｐ／ 等にて公開

【早期審査対象出願】

(73)【特許権者】

【識別番号】523434203

【氏名又は名称】株式会社ｐａｒａｍｉｔａ

(74)【代理人】

【識別番号】100176072

【弁理士】

【氏名又は名称】小林 功

(74)【代理人】

【識別番号】100169225

【弁理士】

【氏名又は名称】山野 明

(72)【発明者】

【氏名】大澤 哲也

【審査官】塩田 徳彦

(56)【参考文献】

【文献】特許第７４４５２２６（ＪＰ，Ｂ１）

【文献】特許第７２０２５１３（ＪＰ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

自然資源の保護者が自然環境を保護するためのプロジェクトの認証を認証機関に申請する前に、又は、前記認証機関が前記プロジェクトを認証する前に、非代替性トークンの発行を許可するための許可信号を受け付ける受付ステップと、
少なくとも前記許可信号を受け付けた後、前記プロジェクトに関するプロジェクト情報を含み又は前記プロジェクト情報に紐付けされた前記非代替性トークンを発行する発行ステップと、
前記プロジェクトの認証に伴って創出されるクレジットの前記認証機関による管理とは別に行われる、発行された前記非代替性トークンの取引に関する取引処理が発生する度に、前記取引処理の内容を示す取引データをブロックチェーンに出力する出力ステップと、
前記非代替性トークンの持ち主が所有する取引者端末からの申請に応じて、前記認証機関が管理する登録簿にて、前記プロジェクトの認証に伴って創出済みの前記クレジットの名義を前記持ち主に書き換えるための要求信号を、前記保護者が所有する保護者端末に送信する要求ステップと、
を１つ又は複数のコンピュータに実行させる、取引プログラム。

【請求項2】

前記取引処理に関与するユーザを特定する特定ステップと、
特定された前記ユーザに対して、前記プロジェクトの認証状態に応じて異なる取引権限を付与する付与ステップと、
を前記１つ又は複数のコンピュータに実行させる、
請求項１に記載の取引プログラム。

【請求項3】

前記ユーザが、前記持ち主である場合、
前記持ち主には、前記クレジットの創出前に前記クレジットの移転を申請する権限が付与されない一方、前記クレジットの創出後に前記クレジットの移転を申請する権限が付与される、
請求項２に記載の取引プログラム。

【請求項4】

前記ユーザが、前記保護者である場合、
前記保護者には、前記持ち主による前記クレジットの移転の申請を承認する権限が付与される、
請求項３に記載の取引プログラム。

【請求項5】

前記１つ又は複数のコンピュータは、
前記出力ステップでは、前記プロジェクトの認証に関する認証情報を前記非代替性トークンに保持させるように、前記取引データを出力する、
請求項１に記載の取引プログラム。

【請求項6】

前記認証情報は、前記プロジェクトの申請番号、前記プロジェクトの認証番号、又は前記プロジェクトに関するモニタリングの評価結果を含む、
請求項５に記載の取引プログラム。

【請求項7】

自然資源の保護者が所有する保護者端末と、
前記保護者端末との間で通信可能な取引サーバと、を備え、
前記取引サーバは、
前記保護者が自然環境を保護するためのプロジェクトの認証を認証機関に申請する前に、又は、前記認証機関が前記プロジェクトを認証する前に、非代替性トークンの発行を許可するための許可信号を、前記保護者端末から受け付ける受付ステップと、
少なくとも前記許可信号を受け付けた後、前記プロジェクトに関するプロジェクト情報を含み又は前記プロジェクト情報に紐付けされた前記非代替性トークンを発行する発行ステップと、
前記プロジェクトの認証に伴って創出されるクレジットの前記認証機関による管理とは別に行われる、発行された前記非代替性トークンの取引に関する取引処理が行われる度に、前記取引処理の内容を示す取引データをブロックチェーンに出力する出力ステップと、
前記非代替性トークンの持ち主が所有する取引者端末からの申請に応じて、前記認証機関が管理する登録簿にて、前記プロジェクトの認証に伴って創出済みの前記クレジットの名義を前記持ち主に書き換えるための要求信号を、前記保護者端末に送信する要求ステップと、
を実行する、取引システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、取引プログラム及び取引システムに関する。

【背景技術】

【0002】

近時、持続可能な開発目標の一環として、自然環境を保護するための様々な取り組みが行われている。例えば日本国では、Ｊ－クレジット制度を活用して、温室効果ガスの排出量の削減に寄与する取り組みがなされている。「Ｊ－クレジット制度」とは、省エネルギー機器の導入や森林経営などの取り組みによる、温室効果ガスの排出削減量や吸収量をカーボンクレジット（温室効果ガス排出権）として国が認証する制度である。そこで、カーボンクレジットの電子商取引に関する様々な技術が提案されている。

【0003】

特許文献１には、カーボンクレジットの購入が仲介者を介して行われる場合、サービスプロバイダから購入者に対してカーボンクレジットを提供するように構成される取引システムが開示されている。

【0004】

特許文献２には、クレジットの購入を希望する企業のそれぞれについて、二酸化炭素の排出削減の目標を達成するための困難度を示す指標を算出し、困難度が大きい順に、クレジットの売却先として企業を抽出するコンピュータが開示されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０２３－０２６９０６号公報

【文献】特開２０２２－１７１１０４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

ところで、流通の促進及び透明化を図るべく、カーボンクレジットを非代替性トークン（Non-Fungible Token；以下、「ＮＦＴ」ともいう）としてトークン化し、ブロックチェーン上で管理することが想定される。ところが、カーボンクレジットの価値をブロックチェーン上のトークンに移転した場合、認証機関が管理する登録簿上でその価値の所在やオフセット履歴が管理できないため、Ｊ－クレジットを含む多くのカーボンクレジット認証機関ではトークン化を禁止している事例が多い。
また、自然資源の保護者はカーボンクレジットを創出するために申請やモニタリングなどで多大な費用が掛かるにもかかわらず、創出されたカーボンクレジットの販売が約束されていないため、リスクを背負った管理を強いられている。そのため、単にトークン化して流通を促進させただけでは「自然環境の保護」という本来の目的を達成できないおそれがある。

【0007】

本発明はこのような問題に鑑みてなされたものであり、その目的は、プロジェクトの認証に伴って創出されるクレジットの流通を促進しつつも、自然環境を保護する本来の目的を達成可能な取引プログラム及び取引システムを提供することにある。

【課題を解決するための手段】

【0008】

本発明の第１態様における取引プログラムは、自然資源の保護者が自然環境を保護するためのプロジェクトの認証を認証機関に申請する前に、又は、前記認証機関が前記プロジェクトを認証する前に、非代替性トークンの発行を許可するための許可信号を受け付ける受付ステップと、少なくとも前記許可信号を受け付けた後、前記プロジェクトに関するプロジェクト情報を含み又は前記プロジェクト情報に紐付けされた前記非代替性トークンを発行する発行ステップと、発行された前記非代替性トークンに関する取引処理が発生する度に、前記取引処理の内容を示す取引データをブロックチェーンに出力する出力ステップと、を１つ又は複数のコンピュータに実行させ、前記非代替性トークンは、前記認証機関が管理する登録簿にて、前記プロジェクトの認証に伴って創出されるクレジットの名義を書き換えるように、前記保護者に対して請求する権利である名義書換権を示すデータである。

【0009】

本発明の第２態様における取引システムは、自然資源の保護者が所有する保護者端末と、前記保護者端末との間で通信可能な取引サーバと、を備え、前記取引サーバは、前記保護者が自然環境を保護するためのプロジェクトの認証を認証機関に申請する前に、又は、前記認証機関が前記プロジェクトを認証する前に、非代替性トークンの発行を許可するための許可信号を、前記保護者端末から受け付ける受付ステップと、少なくとも前記許可信号を受け付けた後、前記プロジェクトに関するプロジェクト情報を含み又は前記プロジェクト情報に紐付けされた前記非代替性トークンを発行する発行ステップと、発行された前記非代替性トークンに関する取引処理が行われる度に、前記取引処理の内容を示す取引データをブロックチェーンに出力する出力ステップと、を実行し、前記非代替性トークンは、前記認証機関が管理する登録簿にて、前記プロジェクトの認証に伴って創出されるクレジットの名義を書き換えるように、前記保護者に対して請求する権利である名義書換権を示すデータである。

【発明の効果】

【0010】

本発明によれば、プロジェクトの認証に伴って創出されるクレジットの流通を促進しつつも、自然環境を保護する本来の目的を達成することができる。

【図面の簡単な説明】

【0011】

【図1】本発明の一実施形態における取引システムの全体構成図である。

【図2】図１に示す取引サーバのブロック図である。

【図3】図１の取引システムを通じて行われる取引の一例を示す図である。

【図4】図１及び図２の取引サーバによる取引動作の一例を示すフローチャートである。

【図5】図２の状態テーブルが有するデータ構造の一例を示す図である。

【図6】図２の権限テーブルが有するデータ構造の一例を示す図である。

【図7】図１に示す取引システムの動作に関する第１シーケンス図である。

【図8】図１に示す取引システムの動作に関する第２シーケンス図である。

【発明を実施するための形態】

【0012】

以下、添付図面を参照しながら本発明の実施形態について説明する。説明の理解を容易にするため、各図面において同一の構成要素に対しては可能な限り同一の符号を付して、重複する説明は省略する。また、「部」の文言は、例えば、ユニット、モジュール、デバイス、又は要素などの他の文言と置き換えられてもよい。

【0013】

［取引システム１０の構成］
＜全体構成＞
図１は、本発明の一実施形態における取引システム１０の全体構成図である。取引システム１０は、ブロックチェーンＢＣを利用しながら、カーボンクレジット（以下、単に「クレジット」ともいう）の取引を支援するための「取引支援サービス」を提供可能に構成される。

【0014】

「カーボンクレジット」とは、二酸化炭素を含む温室効果ガスの削減効果（削減量又は吸収量）を示す環境価値であり、取引の対象物になり得る。カーボンクレジット制度の一例として、Ｊ－クレジット、ＶＳＣ（Verified Carbon Standard）、”Ｇｏｌｄ Ｓｔａｎｄａｒｄ”などが挙げられる。

【0015】

ブロックチェーンＢＣは、ネットワークＮＷ上にある端末（いわゆる、ブロックチェーンノード）同士を直接接続して、取引内容を示すデータ（以下、「取引データＤ１」という）を暗号技術を用いて分散的に処理・記録するデータベースである。ブロックチェーンＢＣの種類は、パブリック型、プライベート型、又はコンソーシアム型のいずれであってもよい。

【0016】

上記した取引データＤ１には、カーボンクレジットの取引に関わる非代替性トークン（以下、「ＣＣ－ＮＦＴ１２」という）が含まれる。このＣＣ－ＮＦＴ１２は、認証機関が管理する登録簿にて、プロジェクトの認証に伴って創出されるクレジットの名義を書き換えるように、保護者に対して請求する権利、いわゆる「名義書換権」を示すデータである。このＣＣ－ＮＦＴ１２は、例えば、所定の単位量（具体的には、二酸化炭素１トン単位）で、仮想通貨や日本円などの法定通貨を通じて売買される。

【0017】

この取引システム１０は、具体的には、取引サーバ１４と、取引者端末１６と、保護者端末１８と、管理者端末２０と、認証機関サーバ２２と、を含んで構成される。

【0018】

取引サーバ１４は、上記した取引支援サービスに関する統括的な制御を行うコンピュータであり、クラウド型あるいはオンプレミス型のいずれであってもよい。ここで、取引サーバ１４を単体のコンピュータとして図示しているが、取引サーバ１４は、これに代わって分散システムを構築するコンピュータ群であってもよい。取引サーバ１４の具体的な装置構成については、図２を参照しながら後で詳しく説明する。

【0019】

取引者端末１６は、ＣＣ－ＮＦＴ１２の取引者が所有するコンピュータである。取引者端末１６は、例えば、タブレット・ラップトップ・スマートフォン・ウェアラブルデバイスを含む携帯型の装置、又は、パーソナルコンピュータを含む据置型の装置から構成される。取引者端末１６は、具体的には、プロセッサ３１、メモリ３２、入力デバイス３３、出力デバイス３４、及び通信ユニット３５を含んで構成される。入力デバイス３３の入力機能及び出力デバイス３４の出力機能を組み合わせることで、ユーザ・インターフェース（ＵＩ）が構築される。

【0020】

保護者端末１８は、自然資源の保護者が所有するコンピュータであり、取引者端末１６と同様の又は異なる装置構成を有する。保護者は、自然資源を保護するための環境価値プロジェクト（以下、単に「プロジェクト」ともいう）を推進する団体であり、例えば、企業、大学、地方自治体、国又はコンソーシアムである。

【0021】

管理者端末２０は、上記した取引支援サービスの管理者が所有するコンピュータであり、取引者端末１６と同様の又は異なる装置構成を有する。管理者は、管理者端末２０を介して、取引支援サービスに関わる必要な対処（例えば、保護者の代替としての自然資源の情報登録・更新、ユーザー情報の変更など）を行うことができる。

【0022】

認証機関サーバ２２は、プロジェクトの認証機関が所有するコンピュータであり、取引者端末１６と同様の又は異なる装置構成を有する。認証機関サーバ２２は、創出されたクレジットをウェブ上の登録簿にて管理している。認証機関は、例えば、国、企業、非営利団体（ＮＰＯ）、非政府団体（ＮＧＯ）又はコンソーシアムである。

【0023】

＜取引サーバ１４の構成＞
図２は、図１に示す取引サーバ１４のブロック図である。取引サーバ１４は、通信部４０と、制御部４２と、記憶部４４と、を含んで構成される。

【0024】

通信部４０は、外部の装置に対して電気信号を送受信するインターフェースである。これにより、取引サーバ１４は、取引データＤ１をブロックチェーンＢＣに送信可能であるとともに、メタデータＤ２を取引者端末１６に送信可能である。

【0025】

制御部４２は、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）を含むプロセッサによって構成される。制御部４２は、記憶部４４に格納されたプログラム及びデータを読み出して実行することで、閲覧処理部５０、操作受付部５２、及び取引処理部５４として機能する。

【0026】

閲覧処理部５０は、上記した取引支援サービスに関わる様々な画面情報を含む表示用データを生成し、当該表示用データが示す様々な画面の表示を、取引者端末１６を含む外部装置に指示する。Ｗｅｂアプリケーションを利用する場合、表示用データには、ＨＴＭＬ（Hyper Text Markup Language）やＣＳＳ（Cascading Style Sheets）に従って記述されたテキストデータが含まれる。

【0027】

操作受付部５２は、取引者端末１６を含む外部装置からの様々な操作を受け付ける。この操作の一例として、［１］プロジェクトの登録を要求する操作、［２］ＣＣ－ＮＦＴ１２の発行を許可する操作、［３］取引対象であるＣＣ－ＮＦＴ１２の閲覧を要求する操作、［４］ＣＣ－ＮＦＴ１２の購入・売却を要求する操作、［５］クレジットの移転に関する申請・承認、又は［６］クレジットの消費を行使する操作などが挙げられる。

【0028】

取引処理部５４は、ＣＣ－ＮＦＴ１２の取引に関わる様々なデータ処理を行う。この取引処理部５４は、具体的には、取引管理部５６、データ生成部５８、及びデータ出力部６０を含んで構成される。

【0029】

取引管理部５６は、ＣＣ－ＮＦＴ１２の取引に関するイベント（以下、「取引イベント」という）を検出するとともに、取引イベント毎に取引処理の管理を行う。取引イベントの一例として、［１］ＣＣ－ＮＦＴ１２の発行、［２］ＣＣ－ＮＦＴ１２のデータ更新、［３］ＣＣ－ＮＦＴ１２の購入・売却、［４］ＣＣ－ＮＦＴ１２の無効化・失効化、又は［５］クレジットの移転などが挙げられる。

【0030】

取引管理部５６は、状態テーブル６６を逐次更新することにより、プロジェクトの認証状態又はＣＣ－ＮＦＴ１２の存続状態を管理する。認証状態を特定する起算時点の一例として、［１］プロジェクトの認証申請時、［２］モニタリング評価の報告時、［３］プロジェクトの認証時、［４］クレジットの移転申請時、又は［５］クレジットの移転承認時などが挙げられる。存続状態の一例として、未発行、有効、失効、又は有効期限切れなどが挙げられる。

【0031】

取引管理部５６は、状態テーブル６６及びを権限テーブル６８を参照し、取引イベントに関与するユーザに対して、該当するＣＣ－ＮＦＴ１２の取引に関する取引権限を付与する。この取引権限は、ユーザの種類に応じて異なっている。例えば、ユーザの種類が「取引者」である場合、当該取引者には、ＣＣ－ＮＦＴ１２の閲覧権限・購入権限・販売権限、又はクレジットの移転申請権限・消費権限などが付与される。例えば、ユーザの種類が「保護者」である場合、当該保護者には、ＣＣ－ＮＦＴ１２の発行権限、ＣＣ－ＮＦＴ１２の閲覧権限、クレジットの移転承認権限などが付与される。

【0032】

データ生成部５８は、クレジットの取引支援に関する様々なデータ、具体的には、ＣＣ－ＮＦＴ１２、取引データＤ１、及びメタデータＤ２を生成する。ＣＣ－ＮＦＴ１２は、後述するプロジェクト情報６４を含み、又は、プロジェクト情報６４に紐付けされている。ＣＣ－ＮＦＴ１２にプロジェクト情報６４が保持される場合、このプロジェクト情報６４は、例えば、プロジェクトの申請番号、プロジェクトの認証番号、又はプロジェクトに関するモニタリングの評価結果を含んでもよい。

【0033】

また、データ生成部５８は、少なくとも、ＣＣ－ＮＦＴ１２の発行を許可する信号（以下、許可信号）を受け付けた後、ＣＣ－ＮＦＴ１２を発行（あるいは、生成・鋳造）する。発行タイミングの一例として、［１］許可信号を受け付けた時点、又は［２］取引者端末１６からの購入要求信号を受け付けた時点などが挙げられる。

【0034】

データ出力部６０は、データ生成部５８により生成された取引データＤ１をブロックチェーンＢＣに出力する。また、データ出力部６０は、取引者端末１６を含む外部装置からの閲覧要求を受け付けた場合、データ生成部５８により生成されたメタデータＤ２を外部装置に出力する。

【0035】

記憶部４４は、制御部４２が各構成要素を制御するのに必要なプログラム及びデータを記憶している。記憶部４４は、非一過性であり、かつ、コンピュータ読み取り可能な記録媒体で構成されている。図２の例では、記憶部４４には、取引データＤ１及びメタデータＤ２の他に、ユーザ情報６２、プロジェクト情報６４、状態テーブル６６、及び権限テーブル６８が記憶されている。

【0036】

ユーザ情報６２は、取引支援サービスのユーザに関する様々な情報を含む。ユーザ情報６２の一例として、［１］氏名・名称・住所を含む個人情報、［２］端末のホスト名・メールアドレス・ニックネームを含むネットワーク情報、又は［３］アカウント名・ユーザ属性を含むサービス情報などが挙げられる。

【0037】

プロジェクト情報６４は、プロジェクトに関する様々な情報を含む。プロジェクト情報６４の一例として、プロジェクトの申請番号・実施主体・名称・スキーム・実施期間・進行状況・認証番号・認証機関、プロジェクトを通じて創出される予定の環境価値量、又はプロジェクトにより実際に創出された環境価値量などが挙げられる。

【0038】

状態テーブル６６は、プロジェクトの認証状態又はＣＣ－ＮＦＴ２１の存続状態を記述するテーブル形式のデータである。状態テーブル６６の具体例については、図５を参照しながら後で詳しく説明する。

【0039】

権限テーブル６８は、取引権限を付与する規則を記述するテーブル形式のデータである。権限テーブル６８の具体例については、図６を参照しながら後で詳しく説明する。

【0040】

取引データＤ１は、取引処理部５４により行われる取引処理の内容を示す取引情報を含む。取引情報の一例として、［１］取引日時・購入数・単価を含む取引実績、［２］販売者・購入者を含む当事者情報、又は［３］ＣＣ－ＮＦＴ１２を含むトークン情報などが挙げられる。

【0041】

メタデータＤ２は、ＣＣ－ＮＦＴ１２に付随する様々な情報を含む。メタデータＤ２の一例として、［１］ＣＣ－ＮＦＴ１２の名称・説明、［２］ＵＲＬ（Uniform Resource Locator）を含む所在情報、又は［３］プロジェクト情報６４の一部などが挙げられる。

【0042】

［取引システム１０の動作］
この実施形態における取引システム１０は、以上のように構成される。続いて、取引システム１０の動作について、図３～図８を参照しながら説明する。

【0043】

図３は、図１の取引システム１０を通じて行われる取引の一例を示す図である。図３の例では、取引の時系列を、左側から右側に向かって、３つのフェーズに分けて示している。図３の上段は認証機関の登録簿上における取引を示すとともに、図３の下段は取引システム１０上の取引を示している。ここでは、自然資源の「保護者」、個人の取引者である「Ａさん」、及び法人の取引者である「Ｂ企業」が取引に関与する場合を例に挙げて説明する。

【0044】

（第１フェーズ：Ｊ－クレジット未作成）
保護者は、プロジェクトの認証申請に先立ち、取引システム１０を介して、ＣＣ－ＮＦＴ１２の発行を申請する。これにより、未認証のＣＣ－ＮＦＴ１２が発行される。その後、保護者は、認証機関に対してプロジェクトの認証を申請し、プロジェクトのモニタリング評価を経て、プロジェクトの認証を得ることができる。このＣＣ－ＮＦＴ１２は、発行後であれば取引システム１０上で第三者に販売可能である（「プライマリーセール」に相当）。以下、Ａさんが、このプライマリーセールを通じて、未認証のＣＣ－ＮＦＴ１２を購入した場合を想定する。

【0045】

（第２フェーズ：Ｊ－クレジット創出済）
保護者は、プロジェクトの認証後、取引システム１０を介して、ＣＣ－ＮＦＴ１２への追記を申請する。これにより、ＣＣ－ＮＦＴ１２の状態は、「未認証」から「認証済」に移行する。この認証後のＣＣ－ＮＦＴ１２は、第１フェーズの場合と同様に、取引システム１０上で第三者に販売可能である（セカンダリーセールに相当）。以下、Ａさんが、このセカンダリーセールを通じて、認証済のＣＣ－ＮＦＴ１２をＢ企業に販売した場合を想定する。

【0046】

（第３フェーズ：オフセット）
Ｂ企業は、取引システム１０を介して、認証済のＣＣ－ＮＦＴ１２に対応するクレジットの消費を申請する。保護者は、Ｂ企業からの申請を承認するとともに、認証機関が管理する登録簿上のクレジットの名義を書き換える。また、ＣＣ－ＮＦＴ１２の状態は、上記した承認を契機として、「アクティブ」（移転可能）から「パッシブ」（移転不可）に遷移される。その後、Ｂ企業は、正当な所有権の下でクレジットを消費することにより、カーボンオフセットが行使される。

【0047】

図４は、図１及び図２の取引サーバ１４による取引動作の一例を示すフローチャートである。

【0048】

ステップＳＰ１０において、取引処理部５４（より詳しくは、取引管理部５６）は、ＣＣ－ＮＦＴ１２の取引に関するイベント（つまり、取引イベント）を検出する。

【0049】

ステップＳＰ１２において、取引管理部５６は、ステップＳＰ１０で検出された取引イベントに関与するＣＣ－ＮＦＴ１２及びユーザを特定する。以下、特定されたＣＣ－ＮＦＴ１２を「該当トークン」といい、特定されたユーザを「該当ユーザ」という。

【0050】

ステップＳＰ１４において、取引管理部５６は、最新の状態テーブル６６及び権限テーブル６８を記憶部４４から読み出して取得する。

【0051】

図５は、図２の状態テーブル６６が有するデータ構造の一例を示す図である。この状態テーブル６６は、［１］ＣＣ－ＮＦＴ１２の識別情報（以下、トークンＩＤ）、［２］ＣＣ－ＮＦＴ１２の「メタデータ」、及び［３］プロジェクトの認証状態又はＣＣ－ＮＦＴ１２の存続状態を示す「ステータス」の対応関係を示すテーブル形式のデータである。図５の例では、ステータスは、ＳＴ１～ＳＴ６を示す状態値によって定義される。

【0052】

「ＳＴ１」は、プロジェクトの認証申請がなされていない状態を示す。「ＳＴ２」は、プロジェクトの認証申請後であって、まだプロジェクトの認証がなされていない状態を示す。「ＳＴ３」は、プロジェクトの認証後であって、まだクレジットの移転がなされていない状態を示す。「ＳＴ４」は、クレジットの移転後であって、まだクレジットの消費が行われていない状態を示す。「ＳＴ５」は、ＣＣ－ＮＦＴ１２の有効期限が切れた状態を示す。「ＳＴ６」は、ＣＣ－ＮＦＴ１２が失効になった状態を示す。

【0053】

図６は、図２の権限テーブル６８が有するデータ構造の一例を示す図である。この権限テーブル６８は、［１］ユーザの種類を示す「ユーザ属性」、［２］プロジェクトの認証状態又はＣＣ－ＮＦＴ１２の存続状態を示す「ステータス」、及び［３］各々の取引権限の有無の対応関係を示すテーブル形式のデータである。図６の例では、ユーザ属性には、取引者又は保護者が含まれる。また、図６の例では、取引権限には、ＣＣ－ＮＦＴ１２の発行権限・閲覧権限・売買権限、及び、クレジットの移転申請権限・移転承認権限・消費権限が含まれる。

【0054】

この権限テーブル６８によれば、「トークン発行権限」は、ステータスが「ＳＴ１」における取引者に付与されている。「トークン閲覧権限」は、すべてのステータスにおける取引者及び保護者に付与されている。なお、ステータス「ＳＴ４～ＳＴ６」では、「ＳＴ１～ＳＴ３」と区別するため、コンピュータにより自動生成されるアート（つまり、ジェネラティブアート）が表示される。「トークン売買権限」は、ステータスが「ＳＴ１～ＳＴ２」における取引者に付与されている。

【0055】

この権限テーブル６８によれば、「移転申請権限」は、ステータスが「ＳＴ３」における取引者に付与されている。「移転承認権限」は、ステータスが「ＳＴ３」における保護者に付与されている。「クレジット消費権限」は、ステータスが「ＳＴ４」における取引者に付与されている。

【0056】

図４のステップＳＰ１６において、取引管理部５６は、ステップＳＰ１２で特定された該当トークンの取引に関する取引権限を該当ユーザに付与する。具体的には、取引管理部５６は、ステップＳＰ１４で取得された状態テーブル６６及び権限テーブル６８を参照し、現在のステータスに対応する該当トークンの取引権限を選択する。

【0057】

ステップＳＰ１８において、取引処理部５４は、ステップＳＰ１６で付与されたユーザ権限に従って取引処理を行う。具体的には、データ生成部５８は、取引の内容に応じた取引データＤ１を生成する。データ出力部６０は、データ生成部５８により生成された取引データＤ１をブロックチェーンＢＣに出力する。

【0058】

ステップＳＰ２０において、取引処理部５４（より詳しくは、取引管理部５６）は、必要に応じて、状態テーブル６６の内容を更新する。以下、取引処理部５４は、図４に示すフローチャートの反復実行を通じて、ＣＣ－ＮＦＴ１２に関する取引処理を逐次行うことができる。

【0059】

＜具体的動作＞
続いて、この取引システム１０の具体的動作について、図７及び図８のシーケンス図を参照しながら説明する。なお、これらのシーケンスの各ステップの実行順番は、必要に応じて適宜変更されてもよい。

【0060】

図７は、取引システム１０の動作に関する第１シーケンス図である。この第１シーケンスは、ＣＣ－ＮＦＴ１２の発行及び購入に関する一連の動作を示している。

【0061】

ステップＳＰ３０において、保護者端末１８は、Ｗｅｂアプリケーションを起動し、取引サーバ１４が提供する登録画面（不図示）を表示する。

【0062】

ステップＳＰ３２において、保護者端末１８は、ステップＳＰ３０にて表示中の登録画面を介して、プロジェクトを登録するための所定の入力操作（つまり、許可操作）を受け付ける。そうすると、保護者端末１８は、ＣＣ－ＮＦＴ１２の発行を許可するための信号であって、ユーザ情報６２及びプロジェクト情報６４を含む信号（以下、許可信号）を取引サーバ１４に送信する。

【0063】

ステップＳＰ３４において、取引サーバ１４は、ステップＳＰ３２にて送信された許可信号を受信することにより、発行の許可信号を受け付ける。

【0064】

ステップＳＰ３６において、取引サーバ１４は、ステップＳＰ３４にて受け付けた許可信号に含まれるプロジェクト情報６４を取得する。取引サーバ１４によるプロジェクト情報６４及び状態テーブル６６の更新動作を通じて、新たなプロジェクトが登録される。

【0065】

ステップＳＰ３８において、取引者端末１６は、Ｗｅｂアプリケーションを起動し、取引サーバ１４が提供する取引画面（不図示）を表示する。この取引画面内には、ステップＳＰ３６で登録されたプロジェクトに対応するＣＣ－ＮＦＴ１２が、取引対象として表示される。

【0066】

ステップＳＰ４０において、取引者端末１６は、ステップＳＰ３８にて表示中の取引画面を介して、ＣＣ－ＮＦＴ１２を購入するための所定の入力操作（つまり、購入操作）を受け付ける。そうすると、取引者端末１６は、ＣＣ－ＮＦＴ１２の購入を要求する信号であって、購入条件及びユーザ情報６２を含む信号（以下、購入要求信号）を取引サーバ１４に送信する。

【0067】

ステップＳＰ４２において、取引サーバ１４は、ステップＳＰ４０で送信された購入要求信号に含まれる購入条件に従って、購入数量分のＣＣ－ＮＦＴ１２を発行する。

【0068】

ステップＳＰ４４において、取引サーバ１４は、ステップＳＰ４２にてＣＣ－ＮＦＴ１２が発行された旨を示す取引データＤ１を生成し、取引データＤ１をブロックチェーンＢＣに出力する。

【0069】

ステップＳＰ４６において、取引サーバ１４は、取引者端末１６及び保護者端末１８との間で、ステップＳＰ４０～ＳＰ４４を通じて購入されたＣＣ－ＮＦＴ１２に関する会計処理を行う。このようにして、図７の第１シーケンスに従って、ＣＣ－ＮＦＴ１２の発行及び購入が行われる。

【0070】

図８は、取引システム１０の第２動作に関するシーケンス図である。より詳しくは、このシーケンスは、クレジットの消費に関する一連の動作を示している。

【0071】

ステップＳＰ５０において、取引者端末１６は、Ｗｅｂアプリケーションを起動し、取引サーバ１４が提供する申請画面（不図示）を表示する。

【0072】

ステップＳＰ５２において、取引者端末１６は、ステップＳＰ５０にて表示中の申請画面を介して、クレジットの移転を申請するための所定の入力操作（つまり、申請操作）を受け付ける。そうすると、取引者端末１６は、クレジットの移転を申請する信号であって、申請条件及びユーザ情報６２を含む信号（以下、申請信号）を取引サーバ１４に送信する。

【0073】

ステップＳＰ５４において、取引サーバ１４は、ステップＳＰ５２で送信された申請信号を受け付けるとともに、申請の承認を要求するための信号であって、申請条件及びユーザ情報６２を含む信号（以下、承認要求信号）を保護者端末１８に送信する。

【0074】

ステップＳＰ５６において、保護者端末１８は、ステップＳＰ５４で送信された承認要求信号に応じて、図示しない承認画面上にてクレジットの移転を承認する操作を行う。そうすると、保護者端末１８は、クレジットの移転を承認する信号（以下、承認信号）を取引サーバ１４に送信する。

【0075】

ステップＳＰ５８において、取引サーバ１４は、ステップＳＰ５６で送信された承認信号を受け付けた場合、ＣＣ－ＮＦＴ１２の移転を制限する。

【0076】

ステップＳＰ６０において、取引サーバ１４は、ステップＳＰ６０でＣＣ－ＮＦＴ１２の移転が制限された旨を示す取引データＤ１を生成し、取引データＤ１をブロックチェーンＢＣに出力する。

【0077】

ステップＳＰ６２において、保護者端末１８は、ステップＳＰ５６にて移転が承認されたクレジットに関して、名義の書き換えを認証機関サーバ２２に要求する「名義書換処理」を行う。名義書換処理は、保護者端末１８又は取引サーバ１４を通じて自動で行われてもよいし、保護者端末１８を介する入力操作を通じて手動で行われてもよい。

【0078】

ステップＳＰ６４において、取引者端末１６は、ステップＳＰ６２の名義書換処理が完了した後、図示しない承認画面を介して所定の入力操作（つまり、通知操作）を受け付ける。そうすると、取引者端末１６は、クレジットの移転が完了したことを示す信号（以下、完了通知信号）を取引サーバ１４に送信する。

【0079】

ステップＳＰ６６において、取引サーバ１４は、ステップＳＰ６４で送信された完了通知信号に応じて、クレジットの移転が完了したことを示す信号（つまり、完了通知信号）を取引者端末１６に送信する。

【0080】

ステップＳＰ６８において、取引者端末１６は、ステップＳＰ６６にて完了通知信号を受信した後、所望のタイミングで、クレジットの消費を認証機関サーバ２２に要求する「消費処理」を行う。消費処理は、取引者端末１６を通じて自動で行われてもよいし、取引者端末１６を介する入力操作を通じて手動で行われてもよい。このようにして、図８の第２シーケンスに従って、クレジットの消費が行われる。

【0081】

［実施形態のまとめ］
以上のように、この実施形態における取引システム１０は、取引者が所有する取引者端末１６と、自然資源の保護者が所有する保護者端末１８と、取引者端末１６及び保護者端末１８と通信可能な取引サーバ１４と、を含んで構成される。

【0082】

取引サーバ１４は、保護者がプロジェクトの認証を認証機関に申請する前に、又は、認証機関がプロジェクトを認証する前に、ＣＣ－ＮＦＴ１２の発行を許可するための許可信号を保護者端末１８から受け付ける操作受付部５２と、少なくとも許可信号を受け付けた後、プロジェクトに関するプロジェクト情報６４を含み又はプロジェクト情報６４に紐付けされたＣＣ－ＮＦＴ１２を発行するデータ生成部５８と、発行されたＣＣ－ＮＦＴ１２に関する取引処理が発生する度に、取引処理の内容を示す取引データＤ１をブロックチェーンＢＣに出力するデータ出力部６０と、を備える。

【0083】

この実施形態における取引方法及び取引プログラムによれば、１つ又は複数のコンピュータ（ここでは、取引サーバ１４）が、保護者がプロジェクトの認証を認証機関に申請する前に、又は、認証機関がプロジェクトを認証する前に、ＣＣ－ＮＦＴ１２の発行を許可するための許可信号を受け付ける受付ステップ（図７のＳＰ３４）と、少なくとも許可信号を受け付けた後にＣＣ－ＮＦＴ１２を発行する発行ステップ（図７のＳＰ４２）と、発行されたＣＣ－ＮＦＴ１２に関する取引処理が発生する度に、取引処理の内容を示す取引データＤ１をブロックチェーンＢＣに出力する出力ステップ（図７のＳＰ４４，図８のＳＰ６０）を実行する。

【0084】

そして、ＣＣ－ＮＦＴ１２は、認証機関が管理する登録簿にて、プロジェクトの認証に伴って創出されるクレジットの名義を書き換えるように、保護者に対して請求する権利である名義書換権を示すデータである。このように、クレジットの名義書換権を非代替性トークンを用いて資産化し、かつその用途を制限することにより、認証機関の登録簿でクレジットの生成・消費を管理することを担保しつつ、ブロックチェーンＢＣ上にて名義書換権の取引及び用途の透明性が確保されやすくなる。これにより、プロジェクトの認証に伴って創出されるクレジットの流通を促進しつつも、自然環境を保護する本来の目的を達成することができる。

【0085】

特に、プロジェクトの認証の申請前にＣＣ－ＮＦＴ１２が発行されることにより、保護者は、クレジットが創出される前であっても、ＣＣ－ＮＦＴ１２の取引を通じて、プロジェクトを推進するための資金を調達しやすくなる。

【0086】

また、取引サーバ１４は、取引処理に関与するユーザを特定する特定ステップ（図４のＳＰ１２）と、特定されたユーザに対して、プロジェクトの認証状態に応じて異なる取引権限を付与する付与ステップ（ＳＰ１６）をさらに実行してもよい。これにより、ユーザは、プロジェクトの認証状態に適した取引を行うことができる。

【0087】

また、ユーザが、ＣＣ－ＮＦＴ１２の取引者である場合、取引者には、クレジットの創出前にクレジットの移転を申請する権限が付与されない一方、クレジットの創出後にクレジットの移転を申請する権限が付与されてもよい。これにより、クレジットが創出されなかった場合に、クレジットとＣＣ－ＮＦＴ１２の間の権利関係の錯綜を防止することができる。

【0088】

また、ユーザが、自然資源の保護者である場合、保護者には、取引者によるクレジット移転の申請を承認する権限が付与されてもよい。これにより、保護者は、例えば、取引者の適格性を判断した上で、クレジットの移転を行うべきか否かの意思決定をすることができる。

【0089】

また、取引サーバ１４は、出力ステップ（ＳＰ４０，ＳＰ６０）では、プロジェクトの認証に関する認証情報をＣＣ－ＮＦＴ１２に保持させるように取引データＤ１を出力してもよい。また、認証情報は、プロジェクトの申請番号、プロジェクトの認証番号、又はプロジェクトに関するモニタリングの評価結果を含んでもよい。ＣＣ－ＮＦＴ１２を解析することにより、プロジェクトの認証状態を直接的に識別することができる。

【0090】

［変形例］
なお、本発明は、上記した実施形態に限定されるものではなく、この発明の主旨を逸脱しない範囲で自由に変更できることは勿論である。あるいは、技術的に矛盾が生じない範囲で各々の構成を任意に組み合わせてもよい。あるいは、技術的に矛盾が生じない範囲でフローチャート又はシーケンス図を構成する各ステップの実行有無又は実行順を変更してもよい。

【0091】

上記した実施形態では、非代替性トークンがカーボンクレジットに紐付けされる場合を例に挙げて説明したが、非代替性トークンは、認証機関によるプロジェクトの認証を通じて創出される様々なクレジットに紐付けされてもよい。クレジットの一例として、ブルーカーボンクレジット、生物多様性クレジット（より詳しくは、生態系クレジット又は種クレジット）などが挙げられる。

【符号の説明】

【0092】

１０…取引システム、１２…ＣＣ－ＮＦＴ（非代替性トークン）、１４…取引サーバ、１６…取引者端末、１８…保護者端末、５０…閲覧処理部、５２…操作受付部、５４…取引処理部、６４…プロジェクト情報、６６…状態テーブル、６８…権限テーブル、ＢＣ…ブロックチェーン、Ｄ１…取引データ、Ｄ２…メタデータ

【要約】

【課題】プロジェクトの認証に伴って創出されるクレジットの流通を促進しつつも、自然環境を保護する本来の目的を達成可能な取引プログラム及び取引システムを提供する。
【解決手段】取引サーバ１４は、保護者端末１８からの発行要求を受け付けた後、プロジェクトに関するプロジェクト情報５４を含み又はプロジェクト情報５４に紐付けされたＣＣ－ＮＦＴ（１２）を発行し、ＣＣ－ＮＦＴ（１２）に関する取引処理が行われる度に、取引処理の内容を示す取引データＤ１をブロックチェーン（ＢＣ）に出力する。ＣＣ－ＮＦＴ（１２）は、認証機関が管理する登録簿にて、プロジェクトの認証に伴って創出されるクレジットの名義を書き換えるように、保護者に対して請求する権利である名義書換権を示すデータである。
【選択図】図２

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】