JP7367948B2 - ノンファンジブルトークン生成システム及びノンファンジブルトークン生成方法 - Google Patents

Description

本開示は、ノンファンジブルトークン生成システム及びノンファンジブルトークン生成方法に関する。本出願は、２０２１年３月２６日出願の日本出願第２０２１－０５３５３５号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用する。

特許文献１は、ブロックチェーンの一例であるＥｔｈｅｒｅｕｍ（イーサリアム）を開示している。イーサリアムで使用される暗号資産（仮想通貨）をイーサ（Ｅｔｈｅｒ）という。イーサは、法定通貨と同様に代替性（ｆｕｎｇｉｂｌｅ；ファンジブル）を有する。つまり、イーサは、ファンジブルトークン（代替性トークン）の一種である。

イーサリアムなどのブロックチェーンにおいて使用可能なトークンとしては、ファンジブルトークンの他に、ノンファンジブルトークン（Ｎｏｎ-Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ；代替性トークン、以下「ＮＦＴ」ということがある）がある。ＮＦＴは、例えば、Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＥＲＣ）７２１規格に従って発行されたトークンである。ＥＲＣ７２１規格に準拠したＮＦＴは、ＮＦＴ－７２１トークンと呼ばれる。

特開２０１９－１６０３１６号公報

ＮＦＴの販売等のために、要求に応じてＮＦＴが提供されることがある。例えば、ＮＦＴを販売するシステムは、ＮＦＴの購入希望者等からの要求に応じて、購入希望者等へ、購入されたＮＦＴを送信するよう構成される。この場合、システムは、多数のＮＦＴが購入されることに備えて、多数のＮＦＴを、在庫として、予め保有している必要がある。

システムが、在庫としてのＮＦＴを保有する場合、在庫管理が煩雑となる。例えば、在庫となるＮＦＴが少ないと在庫切れのおそれがある。逆に、在庫切れを回避しようとすると、システムの管理者は、予め膨大な数のＮＦＴを予め生成しておいて、システムに格納しておく必要がある。システムに在庫となるＮＦＴを多く保有させる場合、システムの管理者は、膨大な数のＮＦＴを予め生成する作業負担を負うことになる。とりわけ、システムが、複数の種類のＮＦＴを提供するよう構成されている場合、ＮＦＴの種類毎に多数のＮＦＴを準備する必要が生じ、非常に煩雑である。

また、ＮＦＴを提供する必要が生じてから、必要なＮＦＴの生成作業を行うことも考えられるが、どのようなＮＦＴを生成すべきかの情報を入手するのが容易ではないこともある。このため、ＮＦＴ生成に時間を要するおそれがあり、煩雑さが生じる可能性がある。

したがって、ＮＦＴの提供を容易にするため、上記のような煩雑さの回避が望まれる。

本開示のある側面は、ノンファンジブルトークン生成システムである。開示のシステムは、識別情報を有するノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて、生成すべき目的ノンファンジブルトークンの種類を識別し、識別した種類の前記目的ノンファンジブルトークンを生成し、生成された前記目的ノンファンジブルトークンを送信する、ことを実行するよう構成されており、複数の種類の目的ノンファンジブルトークンを生成可能である。開示のシステムは、ノンファンジブルトークンを生成する処理を実行するよう構成されたノンファンジブルトークン生成システムであって、複数の素材データを備えるデータベースを備え、前記ノンファンジブルトークンを生成する前記処理は、識別情報を有するノンファンジブルトークン要求を受信し、前記データベースが備える複数の素材データの中から、受信した前記識別情報に基づいて選択されたデータを用いて、ノンファンジブルトークンを生成する、ことを備え得る。

本開示の他の側面は、ファンジブルトークン生成システムによって実行されるノンファンジブルトークン生成方法である。開示の方法は、識別情報を有するノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて識別された種類の目的ノンファンジブルトークンを生成し、生成された前記目的ノンファンジブルトークンを送信する、ことを備える。開示の方法は、ノンファンジブルトークン生成システムによって実行されるノンファンジブルトークン生成方法であって、前記ノンファンジブルトークン生成システムは、複数の素材データを備えるデータベースを備え、前記方法は、識別情報を有するノンファンジブルトークン要求を受信し、前記データベースが備える複数の素材データの中から、受信した前記識別情報に基づいて選択されたデータを用いて、ノンファンジブルトークンを生成する、ことを備え得る。

更なる詳細は、後述の実施形態として説明される。

図１は、第１実施形態に係るノンファンジブルトークン生成システムの構成図である。 図２は、ボックスＮＦＴ、パックＮＦＴ、カードＮＦＴの関係の説明図である。 図３は、ＮＦＴ生成処理に関するタイミングチャートである。 図４は、ユーザ端末における操作画面である。 図５は、ユーザ端末におけるＮＦＴ要求のための操作及び操作手順を示すフローチャートである。 図６は、目的ＮＦＴ生成処理のフローチャートである。 図７は、スマートコントラクトの構成図である。 図８は、第１モジュールによる処理のフローチャートである。 図９は、第２モジュールによる処理のフローチャートである。 図１０は、第３モジュールによる処理のフローチャートである。 図１１は、第４モジュールによる処理のフローチャートである。 図１２は、第５モジュールによる処理のフローチャートである。 図１３は、第２実施形態に係るノンファンジブルトークン生成システムの構成図である。 図１４は、第２実施形態に係るスマートコントラクトによる処理のフローチャートである。 図１５は、第３実施形態に係るノンファンジブルトークン生成システムの構成図である。 図１６は、第３実施形態に係るスマートコントラクトによる処理のフローチャートである。 図１７は、目的ノンファンジブルトークン生成の説明図である。 図１８は、第５実施形態に係るノンファンジブルトークン生成システムの構成図である。 図１９は、第６実施形態に係るノンファンジブルトークン生成システムの構成図である。 図２０は、第７実施形態に係るノンファンジブルトークン生成システムの構成図である。 図２１は、第８実施形態に係るノンファンジブルトークン生成システムの構成図である。

＜１．ノンファンジブルトークン生成システム及びノンファンジブルトークン生成システムによって実行される方法の概要＞

（１）実施形態に係るノンファンジブルトークン生成システム（以下、単に「システム」ということがある）は、ノンファンジブルトークンを生成するよう構成されている。ノンファンジブルトークン及びファンジブルトークンは、ブロックチェーンにおいて取引が記録され得る。ノンファンジブルトークンの所有者は、ブロックチェーンにおいて記録され得る。ブロックチェーンにおいて記録されたノンファンジブルトークンは、ブロックチェーンにおいて公開され得るものであって、参照可能であり得る。ノンファンジブルトークンは、例えば、コンピュータゲームにおいて取引されるアイテム若しくはキャラクタ、デジタルトレーディングカード、デジタルチケット、デジタル証書又はその他のデジタルデータとして用いられ得る。デジタルトレーディングカードは、デジタルコレクタブルカードとも呼ばれる。ノンファンジブルトークンは、一例として、Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＥＲＣ）７２１規格に従って発行されたトークンであり得る。ノンファンジブルトークンは、他のノンファンジブルトークンとは区別される独自の価値を有することがある。このため、ノンファンジブルトークンは、他のノンファンジブルトークンとの区別を可能にするための固有の識別子を有する。ＮＦＴの識別子は、例えば、ブロックチェーンにおいてノンファンジブルトークンを示すアドレス又はその他の識別子である。ＮＦＴの識別子は、ＮＦＴ－ＩＤとも呼ばれる。

実施形態に係るシステムは、一つのコンピュータによって構成されてもよいし、複数のコンピュータからなるコンピュータネットワークによって構成されていてもよい。コンピュータネットワークは、例えば、インターネットであり得る。コンピュータネットワークは、Ｐ２Ｐコンピュータネットワークであり得る。Ｐ２Ｐコンピュータネットワークは、例えば、インターネットによって複数のコンピュータが接続されたネットワークである。システムは、ブロックチェーンを構成するコンピュータネットワークを含み得る。

システムによるノンファンジブルトークンの提供は、例えば、ノンファンジブルトークンの販売、譲渡、又は他のノンファンジブルトークンとの交換のために行われる。販売、譲渡、又は交換等のために、システムから提供されるノンファンジブルトークンを、目的ノンファンジブルトークンという。システムが目的ノンファンジブルトークンを送信することで、目的ノンファンジブルトークンが提供される。

実施形態に係るシステムは、一例として、ノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求に応じた目的ノンファンジブルトークンを生成し、前記目的ノンファンジブルトークンを送信する、ことを実行するよう構成され得る。生成される目的ノンファンジブルトークンは、１個でもよいし、複数でも良い。システムは、ノンファンジブルトークン要求を受信したことをトリガとして、目的ノンファンジブルトークンを生成することができる。システムは、ノンファンジブルトークン要求を受信する度に、ノンファンジブルトークン要求に応じた目的ノンファンジブルトークンを生成することができる。システムは、ノンファンジブルトークン要求を受信する前の時点において、ノンファンジブルトークン要求に応じた目的ノンファンジブルトークンを非保有でよい。すなわち、システムは、提供すべき目的ノンファンジブルトークンの在庫を保有する必要がない。

前記ノンファンジブルトークン要求は、例えば、目的ノンファンジブルトークンの送信をシステムに要求するコマンドである。前記ノンファンジブルトークン要求は、例えば、目的ノンファンジブルトークンの購入又は譲受の希望を示すコマンド、又は、あるノンファンジブルトークンから目的ノンファンジブルトークンへの交換の希望を示すコマンドである。ノンファンジブルトークン要求は、目的ノンファンジブルトークンの送信をシステムに対して明示的に要求するものであってもよいし、明示的な要求を示してはいないが、システムが、その受信に対する応答として、目的ノンファンジブルトークンの送信が必要であると判断し得るコマンドであってもよい。例えば、システムは、トークンの受信をノンファンジブルトークン要求であるとみなすように構成されていていてもよい。ノンファンジブルトークン要求であるとみなされるトークンを「要求送信トークン」という。要求送信トークンは、例えば、ファンジブルトークン又はノンファンジブルトークンである。また、ノンファンジブルトークン要求は、要求送信トークンと、トークン以外の情報と、を含んでも良い。要求送信トークンは、ノンファンジブルトークン要求としてのコマンドととともに送信されてもよい。

前記ノンファンジブルトークン要求は、ネットワークを介して、システムへ送信され得る。ノンファンジブルトークン要求の送信元は、例えば、目的ノンファンジブルトークンの提供を受けるユーザの端末、目的ノンファンジブルトークンの提供を受けるユーザのために動作する第三者のコンピュータ、その他目的ノンファンジブルトークンを受信することになるコンピュータである。前記ノンファンジブルトークン要求の送信が、要求送信トークンの送信を含む場合、その要求送信トークンの送信元は、要求送信トークンの所有者であるユーザのアカウント（ブロックチェーンにおけるユーザのアドレス）である。なお、目的ノンファンジブルトークンの送信先は、ノンファンジブルトークン要求の送信元であってもよいし、ノンファンジブルトークン要求の送信元以外であってもよい。目的ノンファンジブルトークンの送信先は、例えば、要求送信トークンの所有者であるユーザのアカウント（ブロックチェーンにおけるユーザのアドレス）であり得る。

システムは、一つのノンファンジブルトークン要求に応じて、一つの目的ノンファンジブルトークンを生成し、送信し得る。また、システムは、一つのノンファンジブルトークン要求に応じて、複数の目的ノンファンジブルトークンを生成し、送信し得る。この場合、システムは、複数の目的ノンファンジブルトークンを一括提供できる。

システムは、複数の種類の目的ノンファンジブルトークンを生成可能である。この場合、システムは、様々な種類の目的ノンファンジブルトークンを提供できる。また、システムは、一つのノンファンジブルトークン要求に応じて、複数の種類の目的ノンファンジブルトークンを生成し得る。この場合、システムは、複数の種類の目的ノンファンジブルトークンを一括提供し得る。目的ノンファンジブルトークンの種類（タイプ）は、例えば、後述の目的ノンファンジブルトークンのＮＦＴのタイプのほか、目的ノンファンジブルトークンのカテゴリ又はジャンルであってもよい。目的ノンファンジブルトークンの種類は、システムによって識別され得る。カテゴリは、例えば、後述のカードＮＦＴに設定された区分を示す。タイプは、例えば、後述のカードＮＦＴ、パックＮＦＴ、ボックスＮＦＴといった区分を示す。目的ノンファンジブルトークンの種類は、後述のチケットＮＦＴの種類であってもよいし、後述の証書ＮＦＴの種類であってもよい。

なお、ここでの「種類」は、ノンファンジブルである一つ一つのノンファンジブルトークンの違いによって区別されるものであってもよいが、好ましくは、２以上のノンファンジブルトークンに共通する性質としてシステムによって識別され得るものである。複数のノンファンジブルトークンにおいて、ノンファンジブルトークンの種類が同じである場合、ノンファンジブルトークンを構成する構成データの少なくとも一部が共通であり得る。逆に、ノンファンジブルトークンの種類が異なる場合、目的ノンファンジブルトークンを構成する構成データが異なり得る。

前記ノンファンジブルトークン要求は、識別情報を有することができる。識別情報は、生成すべき目的ノンファンジブルトークンの種類を識別するために用いられ得る。ノンファンジブルトークン要求が前記識別情報を有することで、システムは、ノンファンジブルトークン要求を受信すると、生成すべき目的ノンファンジブルトークンの種類を識別し、要求に応じた適切な目的ノンファンジブルトークンを生成することができる。したがって、ノンファンジブルトークン要求を受信するシステムは、自律的に、適切な種類の目的ノンファンジブルトークンを生成できる。

前記識別情報は、ノンファンジブルトークン要求自体であり得る。例えば、ノンファンジブルトークン要求のためのコマンドが、目的ノンファンジブルトークンの複数の種類に応じて、複数用意されている場合、ノンファンジブルトークン要求自体が、目的ノンファンジブルトークンの種類を識別するために用いられ得る。

前記識別情報は、ノンファンジブルトークン要求に含まれる情報であり得る。例えば、複数の種類の目的ノンファンジブルトークン要求のために共通して用いられるコマンドが、目的ノンファンジブルトークンの種類を示すパラメータを含んでいても良い。

前記識別情報は、ノンファンジブルトークン要求とともに送信された情報であり得る。例えば、ノンファンジブルトークン要求とともに送信さる情報は、例えば、目的ノンファンジブルトークンに交換されるノンファンジブルトークン、ファンジブルトークン、又はその他のデジタルデータである。ここで、「ノンファンジブルトークン要求とともに送信」とは、ノンファンジブルトークン要求と完全に同時に送信される必要はなく、多少時間が前後しても、ノンファンジブルトークン要求と関連付け又は対応付けられており、ノンファンジブルトークン要求とともに送信されたと実質的にみなせる情報であれば足りる。前記識別情報は、前記要求送信トークンの数又は種類であり得る。

ノンファンジブルトークン要求が要求送信トークンを含む場合、前記識別情報は、例えば、要求送信トークンの数であってもよい。要求送信トークンは、例えば、目的ノンファンジブルトークンを購入するための対価として用いられるファンジブルトークンである。この場合、要求送信トークンとしてのファンジブルトークンの数に応じて、目的ノンファンジブルトークンの種類が識別され得る。要求送信トークンとしてのノンファンジブルトークンの数は、目的ノンファンジブルトークンの値段に相当し得る。なお、前記識別情報は、要求送信トークンとしてのノンファンジブルトークンの数であってもよい。前記識別情報は、要求送信トークンの種類であってもよい。要求送信トークンは、例えば、目的ノンファンジブルトークンと交換される他のノンファンジブルトークンである。この場合、要求送信トークンとしてのノンファンジブルトークンの種類に応じて、目的ノンファンジブルトークンの種類が識別され得る。前記識別情報は、前記要求送信トークンがノンファンジブルトークンであるか、ファンジブルトークンであるか、の違いで示される情報あってもよい。この場合、例えば、前記要求送信トークンがノンファンジブルトークンである場合には、目的ノンファンジブルトークンが第１の種類であると識別され、前記要求送信トークンがファンジブルトークンであるか場合には、目的ノンファンジブルトークンが第２の種類であると識別され得る。

前記識別情報は、前述した識別情報のいずれか１つ単独又は２つ以上の組み合わせであってもよい。２つ以上の情報の組み合わせを用いることで、様々な種類の中から、適切な種類を識別するのが容易になる。

前記目的ノンファンジブルトークンを生成することは、前記識別情報に基づいて識別された種類の前記目的ノンファンジブルトークンを生成することを備え得る。この場合、システムは、ノンファンジブルトークン要求が有する識別情報に基づいて識別された適切な種類の目的ノンファンジブルトークンを生成することができる。したがって、システムは、種類毎の目的ノンファンジブルトークンを予め保有しておく必要がない。システムは、ノンファンジブルトークン要求を受信する前から、システムが有している素材データを用いてノンファンジブルトークンを生成することができる。システムは、ノンファンジブルトークン生成に用いられる素材データを、識別情報に基づいて決定することができる。

（２）前記ノンファンジブルトークン要求を受信することは、ファンジブルトークン又はノンファンジブルトークンである要求送信トークンを受信することを含み、前記目的ノンファンジブルトークンの種類は、前記要求送信トークンの数又は種類を前記識別情報として用いて識別されるのが好ましい。

（３）システムは、前記要求送信トークンとしてファンジブルトークン及びノンファンジブルトークンのいずれも受信可能に構成されているのが好ましい。前記要求送信トークンとして前記ファンジブルトークンを受信した場合、前記目的ノンファンジブルトークンの種類は、前記要求送信トークンとして受信した前記ファンジブルトークンの数に基づいて識別され、前記要求送信トークンとして前記ノンファンジブルトークンを受信した場合、前記目的ノンファンジブルトークンの種類は、前記要求送信トークンとして受信した前記ノンファンジブルトークンの種類に基づいて識別されるのが好ましい。

（４）システムは、ブロックチェーンにおけるスマートコントラクトを実行するコントラクトコンピュータを備えることができる。スマートコントラクトは、ブロックチェーンを構成するコンピュータによって実行されるソフトウェア（コンピュータプログラム）である。スマートコントラクトは、例えば、システムの管理者によって、ブロックチェーンにおいて実行されるように、ブロックチェーンに実装される。コントラクトコンピュータは、ブロックチェーンを構成するコンピュータネットワークシステムを構成するいずれかのコンピュータである。ブロックチェーンを構成するコンピュータネットワークを構成する複数のコンピュータのうち、コントラクトコンピュータとして機能するコンピュータは、動的に変動し得る。

前記スマートコントラクトは、前記識別情報を有するノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて、生成すべき前記目的ノンファンジブルトークンの種類を識別し、識別された種類の前記目的ノンファンジブルトークンを生成し、生成された前記目的ノンファンジブルトークンを送信する、ことを前記コントラクトコンピュータに実行させるよう構成されているのが好ましい。前記コントラクトコンピュータは、複数の種類の目的ノンファンジブルトークンを生成可能であるのが好ましい。システムにおいては、ユーザの選択操作を受け付けるユーザ用コンピュータが利用され得る。前記ユーザ用コンピュータは、前記ユーザの前記選択操作による選択に応じて前記要求送信トークンの数又は種類を特定し、特定された数又は種類の前記要求送信トークンを前記スマートコントラクトへ送信させるよう構成されているのが好ましい。この場合、ユーザの選択操作に応じた要求送信トークンの数又は種類が特定され、その要求送信トークンの数又は種類が前記識別情報となり得る。要求送信トークンの送信元は、例えば、前記ブロックチェーンにおける前記ユーザのアカウント（ブロックチェーンにおけるユーザのアドレス）であり、この場合、ユーザ用コンピュータは、ユーザのために、要求送信トークンの送信処理を実行することになる。なお、ユーザ用コンピュータは、例えば、後述のサーバ３５０又はユーザ端末３００である。ユーザ用コンピュータは、ユーザのために動作するコンピュータであれば足り、ユーザによって所有されている必要はない。つまり、ユーザ用コンピュータは、ユーザ端末３００である必要はなく、ユーザ以外の者（例えば、システムの管理者）によって所有又は管理されているサーバであってもよい。

（５）前記ノンファンジブルトークンを生成することは、複数の素材データの中から、受信した前記識別情報に基づいて選択されたデータを用いて、前記目的ノンファンジブルトークンを生成することを含むのが好ましい。前記識別情報に基づいて選択されたデータを用いることは、選択された素材データ自体を用いることであってもよいし、選択された素材データの複製データを用いることであってもよい。前記ノンファンジブルトークンを生成することは、ブロックチェーンにおけるノンファンジブルトークン発行処理を実行することで発行される初期ノンファンジブルトークンに、構成データを組み込むことを備えるのが好ましい。前記構成データは、前記識別情報に基づいて生成されるのが好ましい。なお、素材データは、システムにおいて、識別情報に対応付けて保存されているか、識別情報に基づいて識別される種類に対応付けて保存されているのが好ましい。

ブロックチェーンにおけるノンファンジブルトークン発行処理は、例えば、ノンファンジブルトークン発行のためのコマンドを実行することによって行われる。ノンファンジブルトークン発行のためのコマンドは、例えば、ノンファンジブルトークンが発行されるブロックチェーンにおいて用意されている。ノンファンジブルトークン発行処理は、ブロックチェーンを構成するコンピュータにおいて実行される。ノンファンジブルトークン発行処理によって発行されたノンファンジブルトークンには、ノンファンジブルトークンの識別子（ＮＦＴ－ＩＤ）が付与される。ノンファンジブルトークンの識別子は、ノンファンジブルトークンをユニークに識別するためにノンファンジブルトークン毎に付与される。ノンファンジブルトークンの識別子は、ブロックチェーンにおけるノンファンジブルトークンのアドレスであってもよいし、それ以外の識別子であってもよい。システムは、発行されたノンファンジブルトークンの識別子を取得し得る。

初期ノンファンジブルトークンは、ノンファンジブルトークン発行処理によって発行されるトークンであり、構成データが組み込まれていない状態の未完成のノンファンジブルトークンであり得る。初期ノンファンジブルトークンに構成データが組み込まれて、目的ノンファンジブルトークンが完成する。初期ノンファンジブルトークンは、少なくとも、ノンファンジブルトークンの識別子を有している。初期ノンファンジブルトークンは、識別子以外に、その他の必要な情報を含んでも良い。構成データの組み込みは、初期ノンファンジブルトークンの発行とほぼ同時に行われても良いし、初期ノンファンジブルトークンの発行後に行われても良い。

前記構成データは、例えば、画像データ、音データ、及び文字データの少なくともいずれか一つである。前記構成データは、一つのデータであってもよいし、複数のデータの組み合わせであってもよい。画像データ及び文字データは、ノンファンジブルトークンを保有するユーザ又は第三者の端末において、保有するノンファンジブルトークンを画面表示するために用いられ得る。音データは、ノンファンジブルトークンを保有するユーザ又は第三者の端末において、画像データ又は文字データの表示とともに、出力され得る。画像データは、動画データであってもよいし、静止画データであってもよい。画像データは、後述のトレーディングカードにおける題材、後述のチケットの内容、又は後述の保証証書の内容若しくは保証対象の製品に対応したものであってもよい。

前記構成データは、前記識別情報に基づいて識別された前記種類に基づいて生成され得るため、前記種類に応じた適切な構成データが、初期ノンファンジブルトークンに組み込まれ得る。同じ種類の目的ノンファンジブルトークンには、その種類に対応した少なくとも１つの共通データが前記構成データとして組み込まれ得る。つまり、複数の目的ノンファンジブルトークンが同じ種類である場合、それらの目的ノンファンジブルトークンは、少なくとも１つの共通する構成データを有し得る。また、複数の目的ノンファンジブルトークンが異なる種類である場合、それらの目的ノンファンジブルトークンには、種類の違いに応じた構成データの違いが存在し得る。このような目的ノンファンジブルトークンの種類の違いがあっても、システムは、ノンファンジブルトークン要求から種類を識別して、適切な構成データを決定し得る。

（６）前記目的ノンファンジブルトークンは、選択された前記データの複製データを示す識別子を有するのが好ましい。

前記複製データを示す識別子は、前記複製データを示すユニフォームリソースアイデンティファイアであるのが好ましい。なお、前記ノンファンジブルトークン発行処理は、前記ノンファンジブルトークン要求を受信した後に行われるのが好ましい。この場合、初期ノンファンジブルトークンをノンファンジブルトークン要求の受信前に発行しておいて予め在庫として準備しておく必要がない。前記構成データは、他の構成データの生成にも用いられ得る複数の素材データの中から前記識別情報を用いて決定された素材データを用いて、前記目的ノンファンジブルトークンのためのユニークなデータとして生成されるのが好ましい。この場合、目的ノンファンジブルトークンに組み込まれた構成データは、個々の目的ノンファンジブルトークンについてユニークなデータとなり、稀少価値を生じさせ易い。構成データは、他の構成データの生成にも共通して用いられる素材データを複製して生成され得る。ある構成データは、他の構成データとは異なるファイル名で保存又は他の構成データとは異なる位置に保存されることで、仮にそのデータ内容が同じであっても、他の構成データとは区別し得るユニークなものとなる。構成データは、素材データを複製して得られたものに、シリアル番号・その他の文字若しくは記号又は画像データなどのデータが付加されていることで、他の構成データと区別がより容易なものとなる。前記初期ノンファンジブルトークンに前記構成データを組み込むことは、前記初期ノンファンジブルトークンに、前記構成データの識別子を対応付けることを備えるのが好ましい。前記構成データの識別子は、例えば、前記構成データのユニフォームリソースアイデンティファイア（ＵＲＩ）である。ＵＲＩは、例えば、ユニフォームリソースロケータ（ＵＲＬ）である。生成された構成データは、例えば、インターネット上のデータサーバに格納され、ＵＲＩ又はＵＲＬは、そのデータサーバに格納された構成データを示す識別子として機能し得る。なお、ＵＲＩは、ユニフォームリソースネーム（ＵＲＮ）であってもよい。

（８）前記システムは、前記識別情報に基づいて、生成すべき前記目的ノンファンジブルトークンの個数を識別することを更に実行するよう構成されているのが好ましい。この場合、前記識別情報は、生成すべき目的ノンファンジブルトークンの個数を識別するための情報としても用いられる。

システムは、第１コンピュータと、第２コンピュータと、を備えて構成されていてもよい。第１コンピュータ及び第２コンピュータは、それぞれ、１台のコンピュータによって構成されていてもよいし、ネットワークを介して接続された複数のコンピュータによって構成されていてもよい。第１コンピュータは、ブロックチェーンを構成するコンピュータネットワークシステムであってもよい。前記第１コンピュータと第２コンピュータとは、ネットワークを介して接続されているのが好ましい。第２コンピュータは、前記構成データの候補又は元となる複数の素材データを備えているのが好ましい。

前記第１コンピュータは、前記ノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求が有する前記情報を用いて前記種類を識別し、前記ノンファンジブルトークン発行処理を実行することで、前記初期ノンファンジブルトークンを発行する、ことを少なくとも備える第１処理を実行するよう構成されているのが好ましい。第１処理は、ブロックチェーンにおけるノンファンジブルトークン発行処理を備えるため、ブロックチェーンに実装されたスマートコントラクトによって実行されるのが好ましい。

前記第２コンピュータは、前記第１コンピュータが識別した前記種類に応じて、前記複数の素材データの中から前記構成データとなる素材データを選択する第２処理を実行するよう構成されているのが好ましい。第２処理は、選択された素材データの複製を前記構成データとして保存することを更に含んでも良い。保存された前記構成データを示すＵＲＩ（ＵＲＬ）は、第２コンピュータから、スマートコントラクト（第１コンピュータ）に与えられ、スマートコントラクト（第１コンピュータ）は、そのＵＲＩ（ＵＲＬ）を初期ノンファンジブルトークンに対応付けることができる。第２コンピュータは、ブロックチェーンとは別に設けられたコンピュータであるのが好ましい。第２コンピュータは、例えば、システムの管理者によって管理されるサーバコンピュータである。

第１処理と第２処理とを別々のコンピュータで実行することにより、それぞれの処理を分けて管理でき、管理が容易になる。特に、第２処理は、多種多様になり得る素材データを扱うため、第１処理とは分離することで、素材データの変更等があっても、第１処理側の変更を回避、又は、変更を少なくできる。また、スマートコントラクトは、記述できるプログラムコード量（記述できる工程数）に制約が設けられていることがあるため、第１処理がスマートコントラクトによって実行される場合、第１処理と第２処理とを分離しておくことで、第１処理の工程数の増大を回避するのが容易である。

前記第２処理は、前記第１コンピュータが前記初期ノンファンジブルトークンを発行したことを、前記第２コンピュータが検出した場合に実行されるのが好ましい。この場合、前記第１コンピュータが前記初期ノンファンジブルトークンを発行したことをトリガとして、第２処理を開始することができる。第２コンピュータは、第１コンピュータが初期ノンファンジブルトークンを発行したことを、第１コンピュータからの通知の受信によって検出してもよい。また、第２コンピュータは、第１コンピュータ（第１処理を実行するスマートコントラクト）の挙動を監視し、初期ノンファンジブルトークンが発行されたことを、第１コンピュータからの通知なしで第２コンピュータが自発的に検出してもよい。なお、ノンファンジブルトークンの発行及び発行されたノンファンジブルトークンの内容は、ブロックチェーンにおいて参照可能に記録されているため、第２コンピュータは、ブロックチェーンにおけるノンファンジブルトークン発行状況及びその内容を確認することで、第１コンピュータによる初期ノンファンジブルトークンの発行を検出してもよい。

第１コンピュータ（スマートコントラクト）は、目的ノンファンジブルトークンの種類を示す情報を有する初期ノンファンジブルトークンを発行してもよい。この場合、第２コンピュータは、ブロックチェーンにおいて、発行された初期ノンファンジブルトークンが有する情報を参照し、目的ノンファンジブルトークンの種類を識別し、その種類に応じた適切な構成データを決定し、その構成データを初期ノンファンジブルトークンに組み込むことができる。

前記第２コンピュータは、前記第１コンピュータから、前記目的ノンファンジブルトークンの前記種類を示す情報を備える生成条件を取得するよう構成されていてもよい。

（９）前記ノンファンジブルトークン要求を受信することは、ノンファンジブルトークンである要求送信トークンを受信することを含むことができる。前記要求送信トークンであるノンファンジブルトークンは、生成すべき前記目的ノンファンジブルトークンの種類を識別するために用いられる前記識別情報を有するのが好ましい。前記要求送信トークンであるノンファンジブルトークンが有する前記識別情報は、例えば、前記要求送信トークンであるノンファンジブルトークンの種類を示す情報である。システムは、前記要求送信トークンであるノンファンジブルトークンが有する前記識別情報に基づいて、生成すべき目的ノンファンジブルトークンを識別することができる。前記識別情報は、前記目的ノンファンジブルトークンに組み込まれる構成データとして用いられる情報を有していても良い。この場合、システムは、前記要求送信トークンであるノンファンジブルトークンが有する情報を、目的ノンファンジブルトークンに組み込まれる構成データの少なくとも一部として用いて、目的ノンファンジブルトークンを生成できる。

（１０）前記ノンファンジブルトークン要求が有する前記識別情報は、前記複数の素材データのいずれかを示すデータを含むのが好ましい。前記システムは、前記目的ノンファンジブルトークンを生成するための生成用プライベートキーを備え、前記生成用プライベートキーを用いて前記目的ノンファンジブルトークンを生成するよう構成されているのが好ましい。

実施形態に係る方法は、ノンファンジブルトークン生成システムによって実行されるノンファンジブルトークン生成方法であり得る。前記方法は、識別情報を有するノンファンジブルトークン要求を受信し、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて識別された種類の目的ノンファンジブルトークンを生成し、生成された前記目的ノンファンジブルトークンを送信する、ことを備える。また、実施形態に係る方法は、ノンファンジブルトークン生成システムによって実行されるノンファンジブルトークン生成方法であって、前記ノンファンジブルトークン生成システムは、複数の素材データを備えるデータベースを備え得る。前記方法は、識別情報を有するノンファンジブルトークン要求を受信し、前記データベースが備える複数の素材データの中から、受信した前記識別情報に基づいて選択されたデータを用いて、ノンファンジブルトークンを生成する、ことを備え得る。実施形態に係るシステムは、ノンファンジブルトークンを生成する処理を実行するよう構成されたノンファンジブルトークン生成システムであって、複数の素材データを備えるデータベースを備え得る。前記ノンファンジブルトークンを生成する前記処理は、識別情報を有するノンファンジブルトークン要求を受信し、前記データベースが備える複数の素材データの中から、受信した前記識別情報に基づいて選択されたデータを用いて、ノンファンジブルトークンを生成する、ことを備え得る。前記システムは、前記ノンファンジブルトークンを生成するための生成用プライベートキーを備え、前記プライベートキーを用いて前記ノンファンジブルトークンを生成するよう構成されているのが好ましい。

実施形態に係るコンピュータプログラムは、開示の処理のすくなくともいずれか１つをプロセッサに実行させる。コンピュータプログラムは、コンピュータ読み取り可能な、非一時的な記憶媒体に格納される。

＜２．ノンファンジブルトークン生成システム及びノンファンジブルトークン生成システムによって実行される方法の例＞

以下、図面を参照して、好適な実施形態を説明する。以下の説明は、好適な実施形態の一例を示すものであり、本発明を限定するものではない。

＜２．１ 第１実施形態：カードＮＦＴ生成システム＞

図１は、第１実施形態に係るノンファンジブルトークン生成システム１０（ＮＦＴ生成システム）の一例を示している。第１実施形態に係るシステム１０は、ブロックチェーン等のコンピュータネットワークシステム１００に実装されたスマートコントラクト１０１を備え得る。スマートコントラクト１０１は、ブロックチェーン等のコンピュータネットワークシステム１００（第１コンピュータ）に実装されたソフトウェア（コンピュータプログラム）であり、所定のプロトコルを自動的に実行する。実施形態に係るスマートコントラクト１０１は、ブロックチェーンにおけるアドレスであるコントラクトアドレスを有する。スマートコントラクト１０１は、コントラクトアドレスに格納されている。スマートコントラクト１０１は、他のコンピュータによって呼び出されることで実行される。スマートコントラクト１０１を呼び出すコンピュータは、例えば、ユーザのために動作するサーバ３５０、又は、ユーザ端末３００である。サーバ３５０は、例えば、ユーザ端末３００によってアクセスされるアプリケーションサーバである。サーバ３５０は、システム１０を構成し得る。サーバ３５０は、インターネット等のネットワーク上に設けられ得る。スマートコントラクト１０１は、実施形態に係るＮＦＴ生成処理（第１処理）を実行するよう構成されている。ブロックチェーンは、図１に示すように、複数のコンピュータが相互に接続されたＰ２Ｐのコンピュータネットワークによって構成されている。スマートコントラクト１０１は、コンピュータネットワークシステム１００を構成する複数のコンピュータのいずれかによって実行され得る。

第１実施形態に係るシステム１０は、サーバ２００（第２コンピュータ）を備える。サーバ２００は、例えば、スマートコントラクト１０１における処理（第１処理；ＮＦＴ生成処理）処理を補助する。サーバ２００は、後述のユーザ端末３００における処理を補助してもよい。サーバ２００は、その他、システム１０の管理のための処理を行っても良い。システム１０は、前述のサーバ３５０を、システム１０の構成要素の一つとして備えても良い。

サーバ２００（第２コンピュータ）は、インターネット等のネットワークを介して、スマートコントラクト１０１が実装されたコンピュータネットワークシステム１００（第１コンピュータ）と接続されている。サーバ２００とスマートコントラクト１０１とは相互に通信可能である。

サーバ２００は、プロセッサ２１０及びメモリ２２０を備えるコンピュータによって構成されている。前述のサーバ３５０も同様である。サーバ２００及びサーバ３５０は複数のコンピュータによって構成されてもよい。メモリ２２０は、プロセッサ２１０に接続されている。メモリ２２０は、例えば、一次記憶装置及び二次記憶装置を備える。一次記憶装置は、例えば、ＲＡＭである。二次記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ）又はソリッドステートドライブ（ＳＳＤ）である。メモリ２２０は、プロセッサ２１０によって実行されるコンピュータプログラム２６０を備える。プロセッサ２１０は、メモリ２２０に格納されたコンピュータプログラム２６０を読み出して実行する。コンピュータプログラム２６０は、サーバ２００が実行する処理のためのプログラムコードを有する。サーバ２００が実行する処理は、例えば、後述のＮＦＴ構成データ組込処理２１２（第２処理）を含む。

メモリ２２０は、データベース２３０を備える。データベース２３０は、例えば、ＮＦＴ用素材データ２４０（素材データのデータベース）を備える。データベース２３０は、複数の素材データを備える。システム１０は、複数の素材データの中から選択されたデータを用いて、ノンファンジブルトークンを生成し得る。データベース２３０は、さらに、ＮＦＴ生成規則２５０を備え得る。ＮＦＴ用素材データ２４０及びＮＦＴ生成規則２５０については後述される。データベース２３０は、後述のノンファンジブルトークン要求（ＮＦＴ要求）を受信する前から、素材データを備える。したがって、システム１０は、ＮＦＴの生成の際に、既に有している素材データを、システム１０外部から、受信する必要がない。

第１実施形態に係るシステム１０は、デジタルカードＮＦＴの販売及び交換サービスを提供するため、デジタルカードＮＦＴを生成する。システム１０は、デジタルカードＮＦＴを無償配布するサービスを提供してもよい。システム１０は、デジタルカードＮＦＴの購入又は交換を希望するユーザが有する端末３００（ユーザ端末）との間で、ネットワークを介して、通信可能である。ユーザ端末３００は、例えば、ユーザが有するスマートフォン、タブレット、ウェアラブルデバイス、パーソナルコンピュータ、又はその他のコンピュータである。第１実施形態に係るシステム１０は、複数の種類のＮＦＴ（デジタルカードＮＦＴ；目的ＮＦＴ）を生成可能に構成されている。第１実施形態に係るシステム１０は、ＮＦＴの取得を希望するユーザの操作に基づいて生成されたノンファンジブルトークン要求を受信すると、ＮＦＴを生成し、生成したＮＦＴの所有者が前記ユーザであることをブロックチェーンに記録する処理を実行するよう構成されている。例えば、第１実施形態に係るシステム１０は、複数の種類のＮＦＴの中からユーザが選択した種類のＮＦＴを生成し、ユーザ（ブロックチェーンにおけるユーザアカウント）へ送信する。データベース２３０は、複数の種類それぞれに対応した素材データを備え得る。システム１０は、データベース２３０が備える複数の素材データの中から、作成すべきＮＦＴの種類に対応した素材データを選択し、選択されたデータを用いて、ＮＦＴを生成し得る。なお、システム１０は、素材データのほか、システム１０外部から受信したデータも用いてＮＦＴを生成してもよい。

第１実施形態に係るシステム１０によって提供されるデジタルカードＮＦＴは、例えば、デジタルトレーディングカードをＮＦＴ化したものである。ＮＦＴ化とは、データ又はデータを直接的又は間接的に示すＵＲＩ等の識別子をブロックチェーンにおけるトークンとして記録することである。デジタルカードは、デジタル化されたトレーディングカードである。デジタルトレーディングカードは、コンピュータ画面上に表示される。以下では、デジタルカードＮＦＴを、カードＮＦＴ（cardNFT）という。カードＮＦＴは、任意の第三者との間で、取引可能である。カードＮＦＴの取引記録及び過去及び現在のカードＮＦＴの所有者は、ブロックチェーンにおいて記録される。カードＮＦＴ及びその他のＮＦＴは、システム１０外の取引所コンピュータにおいても取引可能である。

トレーディングカードは、コレクタブルカードとも呼ばれる。トレーディングカードは、そのトレーディングカードにおける題材に対応した様々な画像を有し、収集又は交換のために、販売される。題材となる画像は、例えば、芸能人、歌手、スポーツ選手、その他著名人、漫画・ゲーム・アニメーションなどのキャラクタ、ゲームのアイテム、乗物、機械、器具、動物、植物などの画像である。画像は、カードＮＦＴの表示のため、カードＮＦＴの保有者のコンピュータ又はそのカードＮＦＴを参照できる第三者のコンピュータの画面に表示される。トレーディングカードは、題材となる画像等によって、異なる価値を有することがある。発行数の少ないトレーディングカードは、稀少価値を有することがある。

図２に示すように、実施形態に係るカードＮＦＴには、カードＮＦＴの題材となる画像データＤ１，Ｄ２，Ｄ３等が組み込まれて構成されている。また、実施形態に係るカードＮＦＴには、複数のカテゴリＣ１，Ｃ２，Ｃ３が設定されている。カテゴリＣ１，Ｃ２，Ｃ３は、システム管理者によって設定されたカードＮＦＴの種類であり、カードＮＦＴのランク、ジャンル、又は性質などを示す。同じ画像データＤ１，Ｄ２，Ｄ３を有するカードＮＦＴであっても、そのカードに付与されたカテゴリＣ１，Ｃ２，Ｃ３が異なれば、異なる種類のカードＮＦＴとして扱われる。したがって、カテゴリの数がＭ個であり、システム１０に用意された題材となる画像データの数がＮ個である場合、カードＮＦＴの種類はＭ×Ｎとなり得る。したがって、非常に多種類のカードＮＦＴが存在し得ることになり、ユーザによるカードＮＦＴの収集・交換の楽しみが増加する。

実施形態において、カードＮＦＴは、パック（pack）と呼ばれる単位で販売又は取引され得る。１個のパックは、システム１０を利用することで、１又は複数のカードＮＦＴと交換可能である。つまり、パックの保有者は、パックを１又は複数のカードＮＦＴと引き換える権利を有する。ただし、ユーザは、パックがどのようなカードＮＦＴと交換されるかは、実際に交換されるまで知り得ない。第１実施形態においては、パックもＮＦＴ化されている。ＮＦＴ化されたパックをパックＮＦＴ（packNFT）という。

実施形態において、パックＮＦＴは、１又は複数のカードＮＦＴと交換可能であることを示すだけであり、交換される前の時点においては、そのパックＮＦＴが実際にどのようなカードＮＦＴと交換されるかを示さない。また、パックＮＦＴは、そのパックＮＦＴと交換されるカードＮＦＴを備えているわけではなく、そのパックＮＦＴと交換されるカードＮＦＴに関する情報を有しているわけではない。したがって、ユーザは、パックＮＦＴを保有していても、そのパックＮＦＴがどのようなカードＮＦＴと交換されるかは、実際に交換されるまで知り得ない。この結果、パックＮＦＴを保有するユーザは、現物の未開封パックを有しているのと同様の体験（Experience）が得られる。すなわち、現物のトレーディングカードが封入された現物の未開封パックは、開封するまで、どのようなトレーディングカードがはいっているかわからないという楽しみがある。同様に、パックＮＦＴにおいてもカードＮＦＴに交換するまで、どのようなカードＮＦＴが得られるかわからないという楽しみが得られる。

パックＮＦＴは、任意の第三者との間で、取引可能である。取引記録及び過去及び現在のカードＮＦＴの所有者は、ブロックチェーンにおいて記録される。パックＮＦＴも取引可能であるため、パックＮＦＴの転売も可能である。特定の種類のパックＮＦＴが限定販売である場合、稀少価値が期待できる。

図２に示すように、パックＮＦＴとしては、一例として、６枚のカードＮＦＴと交換されるｐａｃｋ６ＮＦＴと、３枚のカードＮＦＴと交換されるｐａｃｋ３ＮＦＴと、がある。複数の種類のパックＮＦＴが容易されていることでユーザの利便性が向上する。

実施形態において、パックＮＦＴは、ボックス（box）と呼ばれる単位で販売又は取引され得る。１個のボックスは、システムを利用することで、複数のパックＮＦＴと交換される。ここでは、一例として、図２に示すように、１個のボックスは、６個のｐａｃｋ６ＮＦＴと交換される。つまり、ボックスの保有者は、ボックスを６個のパックと引き換える権利を有する。第１実施形態においては、ボックスもＮＦＴ化されている。ＮＦＴ化されたボックスをボックスＮＦＴ（boxNFT）という。

実施形態において、ボックスＮＦＴは、複数のパックＮＦＴと交換可能であることを示すだけであり、交換される前の時点においては、そのボックスＮＦＴが実際にどのパックＮＦＴと交換されるかを示さない。また、ボックスＮＦＴは、そのボックスＮＦＴと交換されるパックＮＦＴを備えているわけではなく、そのボックスＮＦＴと交換されるパックＮＦＴに関する情報を有しているわけではない。

ボックスＮＦＴは、任意の第三者との間で、取引可能である。取引記録及び過去及び現在のボックスＮＦＴの所有者は、ブロックチェーンにおいて記録される。ボックスＮＦＴも取引可能であるため、ボックスＮＦＴの転売も可能である。特定の種類のボックスＮＦＴが限定販売である場合、稀少価値が期待できる。

以上のように、第１実施形態に係るシステム１０によって提供されるＮＦＴには、カードＮＦＴ、パックＮＦＴ、ボックスＮＦＴの３つのタイプがある。すなわち、第１実施形態に係るシステム１０によって提供されるＮＦＴには、少なくとも３つの種類がある。また、第１実施形態に係るシステム１０によって提供されるカードＮＦＴには、Ｍ個のカテゴリがある。すなわち、第１実施形態に係るシステム１０によって提供されるカードＮＦＴには、少なくともＭ個の種類がある。このように、第１実施形態に係るシステム１０は、複数の種類のＮＦＴをユーザに提供できる。実施形態において、各ＮＦＴに設定された種類（タイプ又はカテゴリ）は、各ＮＦＴが有する識別情報によって、システム１０によって識別され得る。識別情報は、各ＮＦＴが有する画像データであってもよく、この場合、画像データの種類が、ＮＦＴの種類を表す。また、識別情報は、その識別情報を有するＮＦＴの種類を表す文字又は記号であってもよい。なお、要求送信トークンであるＮＦＴが、そのＮＦＴの種類を示す識別情報を有することで、要求送信トークンであるＮＦＴ自体を、目的ＮＦＴの種類を識別するための識別情報として用いることができる。具体的には、要求送信トークンであるＮＦＴが有する識別情報が、生成すべき目的ノンファンジブルトークンの種類を識別するための識別情報として用いられ得る。

また、カードＮＦＴに組み込まれる画像データの種類がＮであれば、第１実施形態に係るシステム１０によって提供されるカードＮＦＴには、少なくともＮ個の種類がある。さらに、カードＮＦＴのカテゴリ及びカードＮＦＴに組み込まれる画像データの種類を総合すると、カードＮＦＴには、Ｍ×Ｎ個の種類があり得る。なお、パックＮＦＴ及びボックスＮＦＴにも、複数の種類があってもよい。種類に応じて、交換により得られるカードＮＦＴ及びパックＮＦＴに違いを設けることもできる。

ボックスＮＦＴ及びパックＮＦＴは、システム１０によって、目的ノンファンジブルトークンに交換され得る要求送信トークン（要求送信ノンファンジブルトークン）として機能し得る。すなわち、システム１０が受信した要求送信トークンが、ボックスＮＦＴ及びパックＮＦＴによって、生成される目的ノンファンジブルトークンの種類が異なるものとなる。

図３は、システム１０によって実行されるＮＦＴ生成処理の流れを示している。なお、図３に示すＮＦＴ生成処理は、スマートコントラクト１０１によって実行されるが、サーバ２００が、その処理の一部（第２処理）を担う。ＮＦＴ生成処理のうち、スマートコントラクト１０１（第１コンピュータ；コントラクトコンピュータ）によって実行される処理を第１処理といい、サーバ２００（第２コンピュータ）によって実行される処理を第２処理という。なお、ここで説明するスマートコントラクト１０１とサーバ２００との役割分担の仕方は、一例であり、役割分担の仕方が特に限定されるわけではなく、役割分担されなくてもよい。

図３に示すＮＦＴ生成処理においては、まず、ユーザ端末３００などのコンピュータから、ノンファンジブルトークン要求（ＮＦＴ要求）が、システム１０へ送信される（ステップＳ１１）。ＮＦＴ要求は、例えば、スマートコントラクト１０１によって受信される（ステップＳ２１）。ＮＦＴ要求は、サーバ３５０からスマートコントラクト１０１へ送信されてもよいし、ユーザ端末３００からサーバ３５０を介してスマートコントラクト１０１へ送信されてもよい。なお、ユーザは、ブロックチェーンを利用するためブロックチェーンアドレスを有する。ブロックチェーンアドレスは、例えば、０ｘ０００００のように表記され得る。ブロックチェーンアドレスは、ブロックチェーンアカウントとも呼ばれる。ユーザは、ブロックチェーンアカウントに対応するプライベートキー（秘密鍵）を有する。プライベートキーは、例えば、ユーザ端末３００又は他の装置に保存される。プライベートキーは、ブロックチェーンに記録されるトランザクションの電子署名に用いられる。

図４は、ユーザ端末３００（ユーザ用コンピュータ）におけるＮＦＴ要求のための操作画面３１０を示している。ユーザ端末３００には、ＮＦＴの購入・交換・管理のためのユーザ用アプリケーションプログラムがインストールされている。図４に示す操作画面３１０は、ユーザ用アプリケーションプログラムによってユーザ端末３００のディスプレイに表示される。なお、ユーザ用アプリケーションプログラムは、ユーザが保有するＮＦＴ又は購入・交換しようとするＮＦＴを、ユーザ端末３００に画面表示することもできる。図４に示す操作画面３１０は、ユーザ端末３００がアクセスしたサーバ３５０（ユーザ用コンピュータ）によってユーザ端末３００のディスプレイに表示されてもよい。

図４に示すように、操作画面３１０は、ボタン３１１，３１２，３１３，３１４，３１５を備える。ボタン３１１は、パック６個入りのボックス（ボックスＮＦＴ）購入操作を受け付ける。ボタン３１２は、カード６枚入りパック（ｐａｃｋ６ＮＦＴ）購入操作を受け付ける。ボタン３１３は、カード３枚入りパック（ｐａｃｋ３ＮＦＴ）購入操作を受け付ける。ボタン３１４は、ボックスＮＦＴをカード６枚入りパック（ｐａｃｋ６ＮＦＴ）に交換する操作を受け付ける。ボックスＮＦＴをカード６枚入りパック（ｐａｃｋ６ＮＦＴ）に交換する操作は、ボックスＮＦＴの開封操作（openbox操作）と呼んでも良い。ボタン３１５は、パックＮＦＴ（ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴ）を、６枚又は３枚のカードＮＦＴに交換する操作である。

ここでは、操作画面３１０において、ユーザがボタン３１１を選択する操作を「第１タイプ要求の操作」といい、ボタン３１２を選択する操作を「第２タイプ要求の操作」といい、ボタン３１３を選択する操作を「第３タイプ要求の操作」といい、ボタン３１４を選択する操作を「第４タイプ要求の操作」といい、ボタン３１５を選択する操作を「第５タイプ要求の操作」という。このように、ユーザは、操作画面３１０において、ボタン３１１，３１２，３１３，３１４，３１５の選択操作をすることができる。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザの選択操作を受け付けることができる。

第１実施形態において、第１タイプ要求はボックスＮＦＴの要求であり、第２タイプ要求はｐａｃｋ６ＮＦＴの要求であり、第３タイプ要求はｐａｃｋ３ＮＦＴの要求であり、第４タイプ要求はｐａｃｋ６ＮＦＴの要求であり、第５タイプ要求はカードＮＦＴの要求である。なお、ここでの要求は、システム１０に対して、ＮＦＴの送信を要求することである。

第１タイプ要求は、必要数のファンジブルトークンとボックスＮＦＴとの交換要求でもある。ファンジブルトークンは、例えば、イーサリアム又はビットコインのような暗号資産（仮想通過）である。以下では、ファンジブルトークンを「ＦＴ」ともいう。

第２タイプ要求は、必要数のＦＴとｐａｃｋ６ＮＦＴとの交換要求でもある。第３タイプ要求は、必要数のＦＴとｐａｃｋ３ＮＦＴとの交換要求でもある。ＦＴの必要数は、交換されるＮＦＴの種類によって異なり得る。このように、要求は、ＦＴと引き換えにＮＦＴの提供をシステム１０に求めるものであってもよい。

第４タイプ要求は、ボックスＮＦＴとｐａｃｋ６ＮＦＴとの交換要求でもある。第５タイプ要求は、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴとカードＮＦＴとの交換要求でもある。このように、要求は、ある種類のＮＦＴをシステム１０に渡す代わりに、他の種類のＮＦＴの提供をシステム１０求めるものであってもよい。この場合、システム１０から提供されるＮＦＴの種類は、システム１０に渡されるＮＦＴの種類によって決まり得る。

前述のように、実施形態においては、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザのボタン選択操作による選択に応じて要求送信トークンとして送信すべきファンジブルトークン数又はノンファンジブルトークンの種類を特定し、特定された数又は種類の要求送信トークンをスマートコントラクト１０１へ送信させるよう構成されている。

実施形態において、スマートコントラクト１０１は、一例として、所定の数のトークン又は所定の種類のトークン（要求送信トークン）を受信したときだけ目的ノンファンジブルトークンの生成・送信を実行するよう構成されている。すなわち、スマートコントラクト１０１は、所定の数以外の数のトークンを受信しても目的ノンファンジブルトークンの生成・送信をしないよう構成され、所定の種類以外のトークンを受信しても目的ノンファンジブルトークンの生成・送信を実行しないよう構成されている。そこで、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザの選択操作による選択に応じて、適切な要求送信トークンだけをスマートコントラクト１０１へ送信するよう機能する。

図５は、ユーザ端末３００におけるＮＦＴ要求のための操作及びＮＦＴ要求のための手順を示している。なお、図５に示す手順の一部又は全部は、ユーザ端末３００がアクセスしたサーバ３５０によって実行されてもよい。ユーザは、ボックスＮＦＴの購入を希望する場合、ボタン３１１を選択する操作、すなわち、第１タイプ要求の操作を行う（ステップＳ５１）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、第１タイプ要求の操作を受け付けると、第１タイプ要求をスマートコントラクト１０１へ送信する（図３のステップＳ１１参照）。第１タイプ要求の操作が行われた場合、ＮＦＴ要求の送信は、スマートコントラクト１０１において第１タイプ要求に対応する第１モジュール１１１（図７参照）を呼び出すとともに、ボックスＮＦＴを取得するため必要な数のＦＴを、スマートコントラクト１０１へ送信することを含む（図５のステップＳ５６）。ＦＴの送信は、例えば、ブロックチェーンにおけるユーザのアドレス（ブロックチェーンにおけるユーザアカウント）からスマートコントラクト１０１のコントラクトアドレスへ、ＦＴを送信することによって行われる。ユーザアカウントからスマート０１へのＦＴの送信は、例えば、サーバ３５０によって実行され得る。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、操作画面３１０におけるユーザの選択（ボタン３１１の選択）に応じて、送信すべきトークン（要求送信トークン）がＦＴであること、及びそのＦＴの必要数を特定し、特定された数のＦＴをスマートコントラクト１０１へ送信させる。

ユーザは、ｐａｃｋ６ＮＦＴの購入を希望する場合、ボタン３１２を選択する操作、すなわち、第２タイプ要求の操作を行う（ステップＳ５２）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、第２タイプ要求の操作を受け付けると、第２タイプ要求をスマートコントラクト１０１へ送信する（図３のステップＳ１１参照）。第２タイプ要求の操作が行われた場合、ＮＦＴ要求の送信は、スマートコントラクト１０１において第２タイプ要求に対応する第２モジュール１１２（図７参照）を呼び出すとともに、ｐａｃｋ６ＮＦＴを取得するために必要な数のＦＴをスマートコントラクト１０１へ送信することを含む（図５のステップＳ５６）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザがボタン３１２を選択したことに応じて、送信すべきトークン（要求送信トークン）がＦＴであること、及びそのＦＴの必要数を特定し、特定された数のＦＴをスマートコントラクト１０１へ送信させる。

ユーザは、ｐａｃｋ３ＮＦＴの購入を希望する場合、ボタン３１３を選択する操作、すなわち、第３タイプ要求の操作を行う（ステップＳ５３）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、第３タイプ要求の操作を受け付けると、第３タイプ要求をスマートコントラクト１０１へ送信する（図３のステップＳ１１参照）。第３タイプ要求の操作が行われた場合、ＮＦＴ要求の送信は、スマートコントラクト１０１において第３タイプ要求に対応する第３モジュール１１３（図７参照）を呼び出すとともに、ｐａｃｋ３ＮＦＴを取得するために必要な数のＦＴをスマートコントラクト１０１へ送信することを含む（図５のステップＳ５６）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザがボタン３１３を選択したことに応じて、送信すべきトークン（要求送信トークン）がＦＴであること、及びそのＦＴの必要数を特定し、特定された数のＦＴをスマートコントラクト１０１へ送信させる。

ユーザは、ボックスＮＦＴからｐａｃｋ６ＮＦＴへの交換を希望する場合、ボタン３１４を選択する操作、すなわち、第４タイプ要求の操作を行う（ステップＳ５４）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、第４タイプ要求の操作を受け付けると、第４タイプ要求をスマートコントラクト１０１へ送信する（図３のステップＳ１１参照）。第４タイプ要求の操作が行われた場合、ＮＦＴ要求の送信は、スマートコントラクト１０１において第４タイプ要求に対応する第４モジュール１１４（図７参照）を呼び出すとともに、ボックスＮＦＴをスマートコントラクト１０１へ送信することを含む（図５のステップＳ５７）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザがボタン３１４を選択したことに応じて、送信すべきトークン（要求送信トークン）の種類がボックスＮＦＴであることを特定し、特定されたボックスＮＦＴをスマートコントラクト１０１へ送信させる。

ユーザは、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴからカードＮＦＴへの交換を希望する場合、ボタン３１５を選択する操作、すなわち、第５タイプ要求の操作を行う（ステップＳ５５）。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、第５タイプ要求の操作を受け付けると、第５タイプ要求をスマートコントラクト１０１へ送信する（図３のステップＳ１１参照）。第５タイプ要求の操作が行われた場合、ＮＦＴ要求の送信は、スマートコントラクト１０１において第５タイプ要求に対応する第５モジュール１１５（図７参照）を呼び出すとともに、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴをスマートコントラクト１０１へ送信することである（図５のステップＳ５８）。ｐａｃｋ６ＮＦＴ及びｐａｃｋ３ＮＦＴのうち、いずれが送信されるかは、ユーザの選択操作によって選択され得る。なお、第５タイプ要求の操作は、ユーザが所有するｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴを選択する操作であってもよい。ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０は、ユーザの選択操作に応じて、送信すべきトークン（要求送信トークン）の種類がｐａｃｋ６ＮＦＴ及びｐａｃｋ３ＮＦＴであることを特定し、特定されたｐａｃｋ６ＮＦＴ及びｐａｃｋ３ＮＦＴをスマートコントラクト１０１へ送信させる。

図３に戻り、システム１０は、ユーザ端末３００から送信されたＮＦＴ要求を受信すると（ステップＳ２１）、ＮＦＴ要求に応じて、目的ノンファンジブルトークン（目的ＮＦＴ）を生成する（ステップＳ２２）。システム１０は、目的ＮＦＴを生成するために用いられる生成用プライベートキー（秘密鍵）を有し、その生成用プライベートキーを用いて、目的ＮＦＴを生成する。例えば、システム１０は、生成用プライベートキーを用いて、目的ＮＦＴ生成のためのトランザクションに電子署名する。電子署名が付加されたトランザクションは、ブロックチェーンに記録される。システム１０は、生成用プライベートキーを有しているため、目的ＮＦＴを取得することになるユーザのプライベートキーを用いなくても、当該ユーザが取得するＮＦＴを生成できる。そして、システム１０は、生成した目的ＮＦＴを、ユーザ端末３００（ユーザアカウント）へ送信する（ステップＳ２３）。送信された目的ＮＦＴはユーザ端末３００によって受信される（ステップＳ１２）。なお、目的ＮＦＴの送信は、ブロックチェーンにおいて、目的ＮＦＴの所有者がユーザに変更され、ユーザのアカウントに目的ＮＦＴが保有されている状態にする操作であれば足りる。すなわち、システム１０は、生成した目的ＮＦＴの所有者が前記ユーザであることをブロックチェーンに記録するよう構成されていれば足りる。

つまり、目的ＮＦＴは、ユーザ端末３００という特定の装置に向けて現実に送信される必要はなく、ユーザが端末３００を介してアクセスできるユーザアカウント（ユーザのブロックチェーンアドレス）に送信されれば足りる。ユーザアカウントは、例えば、ブロックチェーンにおけるアカウントであり、そのようなアカウントは、ブロックチェーンにおけるユニークなアドレスによって識別され得る。ユーザアカウントへ送信された目的ＮＦＴの所有者は、当該ユーザとなり、当該ユーザは、目的ＮＦＴをユーザ端末３００に表示させて参照できる。なお、システム１０は、ＮＦＴ要求の送信元を、前述のようなユーザアカウントによって認識してもよく、目的ＮＦＴの送信先も、前述のようなユーザアカウントによって認識し得る。システム１０は、ＮＦＴ要求の送信元を、目的ＮＦＴの送信先として認識し得る。つまり、システム１０は、目的ＮＦＴを、ＮＦＴ要求の送信元へ送信し得る。システム１０は、目的ＮＦＴの送信先を示すデータを、ＮＦＴ要求を受信すると同時に取得してもよいし、ＮＦＴ要求を受信した後に取得してもよい。

図６は、前述の目的ＮＦＴを生成する処理（ステップＳ２２）を示している。システム１０は、受信したＮＦＴ要求が有する情報（識別情報）を用いて、生成すべき目的ＮＦＴの種類を識別する（ステップＳ６１）。ここでは、目的ＮＦＴの種類を識別するために用いられる「識別情報」は、ＮＦＴ要求自体である。つまり、ＮＦＴ要求の種類が、第１タイプ要求、第２タイプ要求、第３タイプ要求、第４タイプ要求、及び第５タイプ要求のいずれかであるかによって、生成すべき目的ＮＦＴの種類が識別される。また、「識別情報」は、要求送信トークンの数又は種類であってもよく、要求送信トークンの数又は種類によって、生成すべき目的ＮＦＴの種類が識別され得る。「識別情報」は、ＮＦＴ要求が有するその他のデータであってもよい。

また、システム１０は、識別された種類に応じて、目的ＮＦＴの生成条件決定する（ステップＳ６１）。生成条件は、目的ＮＦＴの生成の際に用いられる。生成条件は、例えば、どのような目的ＮＦＴが生成されるべきかを示す。生成条件は、生成される目的ＮＦＴの個数（発行数）を示してもよい。前述の「識別情報」は、生成される目的ＮＦＴの個数を示し得る。生成条件については後述される。

システム１０は、生成条件に従って、初期ＮＦＴを発行する（ステップＳ６２）。例えば、システム１０は、生成条件が示す発行数に応じた数の初期ＮＦＴを発行する。初期ＮＦＴの発行は、システム１０によって用いられるブロックチェーンにおいて用意されたＮＦＴ発行コマンドを実行することによって達成される。ブロックチェーンにおいてＮＦＴ発行コマンドが実行されると、ブロックチェーンを構成するコンピュータは、ＮＦＴ発行コマンドを受け付けると、ブロックチェーンにおけるＮＦＴの発行の処理を実行する。発行されたＮＦＴは、ブロックチェーンにおける台帳に記録され、その記録は公開される。ブロックチェーンにおいて発行されたＮＦＴには、そのＮＦＴにユニークな識別子（ＮＦＴのアドレス又はＮＦＴ－ＩＤ）が付与される。システム１０は、初期ＮＦＴ発行のためのＮＦＴ発行コマンドの実行後、ブロックチェーンにおいて初期ＮＦＴの発行がなされるまで待機する。その待機時間は、ブロックチェーンにおいて異なるが、短い方が好ましい。待機時間を経て、システム１０は、発行された初期ＮＦＴの識別子を取得することができる。

続いて、システム１０は、ＮＦＴ構成データ組込処理２１２を実行する（図２及び図６参照）。ＮＦＴ構成データ組込処理２１２は、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、初期ＮＦＴの識別子に、生成条件（例えば、目的ＮＦＴの種類）に応じたＮＦＴ構成データを対応付ける。ＮＦＴ構成データの候補となる複数のＮＦＴ用素材データ２４０は、データベース２３０に格納されている。ＮＦＴ構成データ組込処理２１２において、システム１０は、生成条件に従って、複数のＮＦＴ用素材データ２４０の中から、目的ＮＦＴの種類に応じたものを決定し、その素材データを用いて構成データを生成する。なお、決定された素材データをそのまま構成データとして用いても良い。構成データは、例えば、画像データ及び文字データである。システム１０は、生成した構成データを、初期ＮＦＴの識別子と対応付ける処理を行う。これによって、初期ＮＦＴと構成データとが一体化され、目的ＮＦＴが生成される。以上によって目的ＮＦＴの生成が完了する（ステップＳ６３）。なお、組込処理２１２は、スマートコントラクト１０１（スマートコントラクト１０１を実行するコントラクトコンピュータ；第１コンピュータ）によって実行されてもよいし、サーバ２００（第２コンピュータ）によって実行されてもよい。

なお、ここでは、一例として、ステップＳ２１，Ｓ２２，Ｓ２３を第１処理といい、処理２１２を第２処理という。一例として、第１処理は、図１におけるスマートコントラクト１０１（第１コンピュータ）によって実行され、第２処理は、サーバ２００（第２コンピュータ）によって実行される。また、ここでは、一例として、目的ＮＦＴを生成する処理（ステップＳ２２）のうち、ステップＳ６１，Ｓ６２，Ｓ６３は、第１処理であり、組込処理２１２は、第２処理である。

ＮＦＴ構成データ組込処理２１２は、サーバ２００が、スマートコントラクト１０１による初期ＮＦＴの発行を検出した場合に、実行される。ＮＦＴの発行の検出は、例えば、スマートコントラクト１０１におけるＮＦＴ発行イベントの発生を、サーバ２００が監視することによって行われる。すなわち、処理２１２は、イベントドリブン型の処理である。ＮＦＴ発行イベントは、例えば、スマートコントラクト１０１がＮＦＴ発行コマンドを実行することによってスマートコントラクト１０１に生じる動作である。

サーバ２００は、ＮＦＴ発行コマンドの発生を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得する。生成条件及び初期ＮＦＴの識別子は、スマートコントラクト１０１から取得され得る。サーバ２００は、取得した生成条件にしたがって、複数のＮＦＴ用素材データ２４０の中から、目的ＮＦＴの種類に応じたものを決定し、構成データを生成する。サーバ２００は、生成した構成データを、スマートコントラクト１０１によって保有されている初期ＮＦＴの識別子に対応付ける処理を実行し、目的ＮＦＴを完成させる。つまり、システム１０は、複数の素材データ２４０の中から、識別情報に基づいて選択されたデータを用いて、目的ＮＦＴを生成する。識別情報に基づいてデータを選択することは、識別情報に基づいて識別された目的ＮＦＴの種類に基づいてデータを選択することを含み得る。生成した目的ＮＦＴには、構成データが組み込まれている。構成データが組み込まれたＮＦＴは、例えば、構成データを示すユニフォームリソースアイデンティファイア（ＵＲＩ）を有する。ここで、構成データを示すＵＲＩは、ＮＦＴのメタデータに備えられていてもよい。また、メタデータを示すＵＲＩは、ＮＦＴのインデックスデータに備えられていてもよい。なお、初期ＮＦＴの発行（ステップＳ６２）と組込処理２１２とは、別々に行われる必要はなく、ステップＳ６２において、構成データが組み込まれたＮＦＴを生成してもよい。サーバ２００は、処理２１２が完了すると、組込完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、目的ＮＦＴの生成が完了（ステップＳ６３）したことを認識し、目的ＮＦＴを送信する（図３のステップＳ２３）。目的ＮＦＴの送信は、目的ＮＦＴの新たな所有者が送信先（ユーザアカウント）になるように、ブロックチェーンにおいて所有者を記録する動作を伴う。つまり、目的ＮＦＴの送信は、目的ＮＦＴの譲渡又は販売となる。

実施形態においては、一例として、スマートコントラクト１０１は、図１及び図７に示すように、第１スマートコントラクト１１０と、第２スマートコントラクト１２０と、を備える。すなわち、実施形態においては、第１スマートコントラクト１１０を構成するソフトウェア及び第２スマートコントラクトを構成するソフトウェアそれぞれが、ブロックチェーンのためのコンピュータネットワークシステムにおいて実行されるように、ブロックチェーンに実装されている。第１スマートコントラクト１１０及び第２スマートコントラクト１２０は互いに通信可能である。

図７に示す第１スマートコントラクト１１０は、一例として、第１モジュール１１１、第２モジュール１１２、第３モジュール１１３、第４モジュール１１４、ファンジブルトークン数判定モジュール１１６（ＦＴ数判定モジュール）、及びＮＦＴタイプ判定モジュール１１７を備える。図７に示す第２スマートコントラクト１２０は、一例として、第５モジュール１１５を備える。なお、ここでの「モジュール」は、ソフトウェアとしてのモジュールであり得る。「モジュール」は、例えば、コンピュータプログラム上で定義される関数、プロシージャ又はサブルーチンである。各モジュールは、ブロックチェーンを構成するコンピュータネットワークにおけるいずれかのコンピュータによって実行され得る。

第１モジュール１１１は、ボックスＮＦＴ購入のための処理が規定されたｂｏｘＮＦＴ購入モジュールである。第２モジュール１１２は、ｐａｃｋ６ＮＦＴ購入のための処理が規定されたｐａｃｋ６ＮＦＴ購入モジュールである。第３モジュール１１３は、ｐａｃｋ３ＮＦＴ購入のための処理が規定されたｐａｃｋ６ＮＦＴ購入モジュールである。第４モジュール１１４は、ボックスＮＦＴをカード６枚入りパック（ｐａｃｋ６ＮＦＴ）に交換する処理が規定されたボックス交換モジュールである。第５モジュール１１５は、パックＮＦＴ（ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴ）を、６枚又は３枚のカードＮＦＴに交換する処理が規定されたバック交換モジュールである。

ＦＴ数判定モジュール１１６は、スマートコントラクト１０１（第１スマートコントラクト１１０）が受信したＦＴの数が、目的ＮＦＴ購入のためのＦＴ必要数と一致するか否かを判定する際に呼び出されるモジュールである。ＮＦＴタイプ判定モジュール１１７は、スマートコントラクト１０１（第１スマートコントラクト１１０又は第２スマートコントラクト１２０）が受信したＮＦＴのタイプ（種類）を判定する際に呼び出されるモジュールである。ＮＦＴタイプ判定モジュール１１７は、受信したトークンがＦＴであるかＮＦＴであるかといったトークンの種類を判定するトークン判定モジュールとして機能してもよい。

実施形態においては、ＮＦＴ要求が第１タイプ要求であれば第１モジュール１１１が呼び出され、第２タイプ要求であれば第２モジュール１１２が呼び出され、第３タイプ要求であれば第３モジュール１１３が呼び出され、第４タイプ要求であれば第４モジュール１１４が呼び出され、第５タイプ要求であれば第５モジュール１１５が呼び出される。つまり、ＮＦＴ要求の種類に応じて、呼び出されるモジュールが決まる。また、スマートコントラクト１０１へ送信された要求送信トークンの数又は種類に応じて、呼び出されるモジュールが決まっても良い。このように、システム１０は、ＮＦＴ要求の種類を識別し、実行されるモジュール１１１，１１２，１１３，１１４，１１５を選択する。システム１０は、ＮＦＴ要求が第１タイプ要求であれば第１モジュール１１１を実行し、第２タイプ要求であれば第２モジュール１１２を実行し、第３タイプ要求であれば第３モジュール１１３を実行し、第４タイプ要求であれば第４モジュール１１４を実行し、第５タイプ要求であれば第５モジュール１１５を実行する。

図８は、第１モジュール１１１（ボックスＮＦＴ購入モジュール）における処理手順を示している。まず、第１スマートコントラクト１１０は、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０から第１タイプ要求を受信する。第１タイプ要求とともに、必要数のＦＴも受信される。ボックスＮＦＴのための必要数のＦＴの受信をしたことが第１タイプ要求の受信とみなされてもよい。第１モジュール１１１及び他のモジュール１１２，１１３へのＦＴの送信は、ＦＴの所有者を送信元（ユーザアカウント）からスマートコントラクト１０１又はスマートコントラクト１０１の管理者のアカウントへ変更する操作を伴う。つまり、ＦＴが、ユーザから支払われたことになる。所有者変更はブロックチェーンにおいて記録される。

第１タイプ要求は、第１モジュール１１１の呼び出しであるため、第１モジュール１１１が動作開始される。第１モジュール１１１における処理においては、まず、第１タイプ要求とともに受信したＦＴの数量が、ボックスＮＦＴ購入の必要数に合致しているか否かが判定される（ステップＳ８１）。この判定は、ＦＴ数判定モジュール１１６によって行われる。なお、ボックスＮＦＴ購入の必要数は、予めユーザ端末へ通知されている。

ＦＴの数量が、ボックスＮＦＴ購入の必要数に合致していない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ８２）。この場合、第１モジュール１１１における処理は終了する。スマートコントラクト１０１は、ボックスＮＦＴを取得するための必要数のＦＴを受信したことで、動作開始すべきモジュールが第１モジュール１１１であることを特定し、特定された第１モジュール１１１を動作開始させてもよい。つまり、ＦＴの数が、識別情報を表し、識別情報としてのＦＴの数が生成条件を決定する。この場合、ステップＳ８１，Ｓ８２は省略可能であり、ステップＳ８３から実行される。また、実施形態のように、スマートコントラクト１０１がＦＴ及びＮＦＴのいずれも受信可能である場合、スマートコントラクト１０１は、受信したトークン（要求送信トークン）が、ＦＴであるかＮＦＴであるかを判別する機能を有していても良い。

ＦＴの数量が、ボックスＮＦＴ購入の必要数に合致している場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ８３）。ここでは、生成条件として、目的ＮＦＴの発行数Ｐ＝１、及び、目的ＮＦＴの種類Ｔ＝第１タイプ（ｂｏｘ）が決定される。この生成条件は、目的ＮＦＴとして、第１タイプであるボックスＮＦＴが１個発行されるべきことを示す。生成条件は、受信したＦＴの数に応じて決定され得る。

続いて、生成条件に従って、Ｐ個（１個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ８４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝第１タイプ（ｂｏｘ）などの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるボックスＮＦＴを生成する（ステップＳ８５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「初期ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。

ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝第１タイプ（ｂｏｘ）に従い、複数のＮＦＴ用素材データ２４０の中から、ボックスＮＦＴのための構成データ（例えば、ボックスＮＦＴのための画像データ、ボックスＮＦＴの名称等を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、第１タイプ（ｂｏｘ）であるボックスＮＦＴのための素材データを含む。システム１０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、構成データとなる素材データを選択し得る。素材データ２４０以外のその他のデータ（例えば、ボックスＮＦＴのシリアル番号）が構成データに付加されてもよい。そして、ボックスＮＦＴのための構成データが初期ＮＦＴに組み込まれ、ボックスＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。ボックスＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、ボックスＮＦＴの生成の完了を認識し（ステップＳ８６）、ボックスＮＦＴを、ＦＴの送信元であるユーザアカウントへ送信する（ステップＳ８７）。

以上のようにして、ユーザは、ＦＴの支払いと引き換えに、ボックスＮＦＴを入手できる。実施形態に係るシステム１０は、ＦＴが支払われた後にボックスＮＦＴを生成するため、ＦＴが支払われる前において、ユーザに渡すべきボックスＮＦＴを保有する必要がない。システム１０が生成すべきＮＦＴが、ボックスＮＦＴであることは、スマートコントラクト１０１へ送信されたＦＴの数によって識別され得る。

図９は、第２モジュール１１２（ｐａｃｋ６ＮＦＴ購入モジュール）における処理手順を示している。まず、第１スマートコントラクト１１０は、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０から第２タイプ要求を受信する。第２タイプ要求とともに、必要数のＦＴも受信される。ｐａｃｋ６ＮＦＴのための必要数のＦＴの受信をしたことが第２タイプ要求の受信とみなされてもよい。

第２タイプ要求は、第２モジュール１１２の呼び出しであるため、第２モジュール１１２が動作開始される。第２モジュール１１２における処理においては、まず、第２タイプ要求とともに受信したＦＴの数量が、ｐａｃｋ６ＮＦＴ購入の必要数に合致しているか否かが判定される（ステップＳ９１）。この判定は、ＦＴ数判定モジュール１１６によって行われる。なお、ｐａｃｋ６ＮＦＴ購入の必要数は、予めユーザ端末へ通知されている。

ＦＴの数量が、ｐａｃｋ６ＮＦＴ購入の必要数に合致していない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ９２）。この場合、第２モジュール１１２における処理は終了する。スマートコントラクト１０１は、ｐａｃｋ６ＮＦＴを取得するための必要数のＦＴを受信したことで、動作開始すべきモジュールが第２モジュール１１２であることを特定し、特定された第２モジュール１１２を動作開始させてもよい。つまり、ＦＴの数が、識別情報を表し、識別情報としてのＦＴの数が生成条件を決定する。この場合、ステップＳ９１，Ｓ９２は省略可能であり、ステップＳ９３から実行される。

ＦＴの数量が、ｐａｃｋ６ＮＦＴ購入の必要数に合致している場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ９３）。ここでは、生成条件として、目的ＮＦＴの発行数Ｐ＝１、及び、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）が決定される。この生成条件は、目的ＮＦＴとして、第２タイプであるｐａｃｋ６ＮＦＴが１個発行されるべきことを示す。生成条件は、受信したＦＴの数に応じて決定され得る。

続いて、生成条件に従って、Ｐ個（１個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ９４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）などの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるｐａｃｋ６ＮＦＴを生成する（ステップＳ９５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「目的ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）に従い、複数のＮＦＴ用素材データ２４０の中から、ｐａｃｋ６ＮＦＴのための構成データ（例えば、ｐａｃｋ６ＮＦＴのための画像データ、ｐａｃｋ６ＮＦＴの名称等を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、第２タイプ（ｐａｃｋ６）であるｐａｃｋ６ＮＦＴのための素材データを含む。システム１０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、構成データとなる素材データを選択し得る。素材データ２４０以外のその他のデータ（例えば、ｐａｃｋ６ＮＦＴのシリアル番号）が構成データに付加されてもよい。そして、ｐａｃｋ６ＮＦＴのための構成データが初期ＮＦＴに組み込まれ、ｐａｃｋ６ＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。ｐａｃｋ６ＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、ｐａｃｋ６ＮＦＴの生成の完了を認識し（ステップＳ９６）、ｐａｃｋ６ＮＦＴを、ＦＴの送信元であるユーザアカウントへ送信する（ステップＳ９７）。

以上のようにして、ユーザは、ＦＴの支払いと引き換えに、ｐａｃｋ６ＮＦＴを入手できる。実施形態に係るシステム１０は、ＦＴが支払われた後にｐａｃｋ６ＮＦＴを生成するため、ＦＴが支払われる前において、ユーザに渡すべきｐａｃｋ６ＮＦＴを保有する必要がない。システム１０が生成すべきＮＦＴが、ｐａｃｋ６ＮＦＴであることは、スマートコントラクト１０１へ送信されたＦＴの数によって識別され得る。

図１０は、第３モジュール１１３（ｐａｃｋ３ＮＦＴ購入モジュール）における処理手順を示している。まず、第１スマートコントラクト１１０は、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０から第３タイプ要求を受信する。第３タイプ要求とともに、必要数のＦＴも受信される。ｐａｃｋ３ＮＦＴのための必要数のＦＴの受信をしたことが第３タイプ要求の受信とみなされてもよい。

第３タイプ要求は、第３モジュール１１３の呼び出しであるため、第３モジュール１１３が動作開始される。第３モジュール１１３における処理においては、まず、第３タイプ要求とともに受信したＦＴの数量が、ｐａｃｋ３ＮＦＴ購入の必要数に合致しているか否かが判定される（ステップＳ１０１）。この判定は、ＦＴ数判定モジュール１１６によって行われる。なお、ｐａｃｋ３ＮＦＴ購入の必要数は、予めユーザ端末へ通知されている。

ＦＴの数量が、ｐａｃｋ３ＮＦＴ購入の必要数に合致していない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ１０２）。この場合、第３モジュール１１３における処理は終了する。スマートコントラクト１０１は、ｐａｃｋ３ＮＦＴを取得するための必要数のＦＴを受信したことで、動作開始すべきモジュールが第３モジュール１１３であることを特定し、特定された第３モジュール１１３を動作開始させてもよい。つまり、ＦＴの数が、識別情報を表し、識別情報としてのＦＴの数が生成条件を決定する。この場合、ステップＳ１０１，Ｓ１０２は省略可能であり、ステップＳ１０３から実行される。

ＦＴの数量が、ｐａｃｋ３ＮＦＴ購入の必要数に合致している場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ１０３）。ここでは、生成条件として、目的ＮＦＴの発行数Ｐ＝１、及び、目的ＮＦＴの種類Ｔ＝第３タイプ（ｐａｃｋ３）が決定される。この生成条件は、目的ＮＦＴとして、第３タイプであるｐａｃｋ３ＮＦＴが１個発行されるべきことを示す。生成条件は、受信したＦＴの数に応じて決定され得る。

続いて、生成条件に従って、Ｐ個（１個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ１０４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝第３タイプ（ｐａｃｋ３）などの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるｐａｃｋ３ＮＦＴを生成する（ステップＳ１０５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「目的ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝第３タイプ（ｐａｃｋ３）に従い、複数のＮＦＴ用素材データ２４０の中から、ｐａｃｋ３ＮＦＴのための構成データ（例えば、ｐａｃｋ３ＮＦＴのための画像データ、ｐａｃｋ３ＮＦＴの名称等を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、第３タイプ（ｐａｃｋ３）であるｐａｃｋ３ＮＦＴのための素材データを含む。システム１０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、構成データとなる素材データを選択し得る。素材データ２４０以外のその他のデータ（例えば、ｐａｃｋ３ＮＦＴのシリアル番号）が構成データに付加されてもよい。そして、ｐａｃｋ３ＮＦＴのための構成データが初期ＮＦＴに組み込まれ、ｐａｃｋ３ＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。ｐａｃｋ３ＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、ｐａｃｋ３ＮＦＴの生成の完了を認識し（ステップＳ１０６）、ｐａｃｋ３ＮＦＴを、ＦＴの送信元であるユーザアカウントへ送信する（ステップＳ１０７）。

以上のようにして、ユーザは、ＦＴの支払いと引き換えに、ｐａｃｋ３ＮＦＴを入手できる。実施形態に係るシステム１０は、ＦＴが支払われた後にｐａｃｋ３ＮＦＴを生成するため、ＦＴが支払われる前において、ユーザに渡すべきｐａｃｋ３ＮＦＴを保有する必要がない。システム１０が生成すべきＮＦＴが、ｐａｃｋ３ＮＦＴであることは、スマートコントラクト１０１へ送信されたＦＴの数によって識別され得る。

図１１は、第４モジュール１１４（ボックス交換モジュール）における処理手順を示している。まず、第１スマートコントラクト１１０は、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０から第４タイプ要求を受信する。第４タイプ要求とともに、ＮＦＴ（ボックスＮＦＴ）も受信される。第４モジュール１１４のボックスＮＦＴの送信は、ボックスＮＦＴの所有者を送信元（ユーザアカウント）からスマートコントラクト１０１又はスマートコントラクト１０１の管理者のアカウントへ変更する操作を伴う。つまり、ボックスＮＦＴが、ユーザからスマートコントラクトへ譲渡されたことになる。ＮＦＴの所有者の変更は、ブロックチェーンにおいて記録される。ボックスＮＦＴをしたことが第４タイプ要求の受信とみなされてもよい。

第４タイプ要求は、第４モジュール１１４の呼び出しであるため、第４モジュール１１４が動作開始される。第４モジュール１１４における処理においては、まず、第４タイプ要求とともに受信したＮＦＴの種類が、ボックスＮＦＴであるか否かが判定される（ステップＳ１１１）。この判定は、ＮＦＴタイプ判定モジュール１１７によって行われる。なお、ＮＦＴの種類の判定は、例えば、判定対象のＮＦＴに含まれる種類Ｔを示す情報、又はブロックチェーンにおける判定対象ＮＦＴの記録が示す種類Ｔに基づいて行われる。

受信したＮＦＴの種類が、ボックスＮＦＴではない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ１１２）。この場合、第４モジュール１１４における処理は終了する。スマートコントラクト１０１は、ボックスＮＦＴを受信したことで、動作開始すべきモジュールが第４モジュール１１４であることを特定し、特定された第４モジュール１１４を動作開始させてもよい。つまり、受信したＮＦＴの種類（ボックスＮＦＴ）が、識別情報を表し、識別情報としてのＮＦＴの種類が生成条件を決定する。この場合、ステップＳ１１１，Ｓ１１２は省略可能であり、ステップＳ１１３から実行される。

受信したＮＦＴの種類が、ボックスＮＦＴである場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ１１３）。ここでは、生成条件として、目的ＮＦＴの発行数Ｐ＝６、及び、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）が決定される。この生成条件は、目的ＮＦＴとして、第２タイプであるｐａｃｋ６ＮＦＴが６個発行されるべきことを示す。つまり、ボックスＮＦＴは、６個のｐａｃｋ６ＮＦＴと交換される。生成条件は、受信したＮＦＴの種類がボックスＮＦＴであることに応じて決定され得る。

続いて、生成条件に従って、Ｐ個（６個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ１１４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）などの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるｐａｃｋ６ＮＦＴを生成する（ステップＳ１１５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「目的ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝第２タイプ（ｐａｃｋ６）に従い、複数のＮＦＴ用素材データ２４０の中から、ｐａｃｋ６ＮＦＴのための構成データ（例えば、ｐａｃｋ６ＮＦＴのための画像データ、ｐａｃｋ６ＮＦＴの名称等を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、第２タイプ（ｐａｃｋ６）であるｐａｃｋ６ＮＦＴのための素材データを含む。システム１０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、構成データとなる素材データを選択し得る。素材データ２４０以外のその他のデータ（例えば、ｐａｃｋ６ＮＦＴのシリアル番号）が構成データに付加されてもよい。構成データは、６個のＮＦＴ分生成される。そして、６個の初期ＮＦＴそれぞれに、ｐａｃｋ６ＮＦＴのための構成データが組み込まれ、６個のｐａｃｋ６ＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。６個のｐａｃｋ６ＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、６個のｐａｃｋ６ＮＦＴの生成の完了を認識し（ステップＳ１１６）、ｐａｃｋ６ＮＦＴを、ボックスＮＦＴの送信元であるユーザアカウントへ送信する（ステップＳ１１７）。

以上のようにして、ユーザは、ボックスＮＦＴを引き渡す代わりに、６個のｐａｃｋ６ＮＦＴを入手できる。つまり、ユーザは、６個のｐａｃｋが含まれるボックスを開封したのと同様の体験が得られる。実施形態に係るシステム１０は、ボックスＮＦＴが引き渡された後にｐａｃｋ６ＮＦＴを生成するため、ボックスＮＦＴが引き渡される前において、ユーザに渡すべきｐａｃｋ６ＮＦＴを保有する必要がない。システム１０が生成すべきＮＦＴが、ｐａｃｋ６ＮＦＴであることは、スマートコントラクト１０１へ送信されたＮＦＴの種類がボックスＮＦＴであることによって識別され得る。

図１２は、第５モジュール１１５（パック交換モジュール）における処理手順を示している。まず、第１スマートコントラクト１１０は、ユーザ用コンピュータであるユーザ端末３００又はサーバ３５０から第５タイプ要求を受信する。第５タイプ要求とともに、ＮＦＴ（ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴ）も受信される。第５モジュール１１５のパックＮＦＴの送信は、パックＮＦＴの所有者を送信元（ユーザアカウント）からスマートコントラクト１０１又はスマートコントラクト１０１の管理者のアカウントへ変更する操作を伴う。つまり、パックＮＦＴが、ユーザからスマートコントラクトへ譲渡されたことになる。ＮＦＴの所有者の変更は、ブロックチェーンにおいて記録される。ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴをしたことが第５タイプ要求の受信とみなされてもよい。

また、第５タイプ要求の送信の際には、送信されるｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴと交換される複数のｃａｒｄＮＦＴそれぞれのカテゴリＣ１，Ｃ２，Ｃ３，・・・の組み合わせを示す情報（組み合わせ情報）も送信される。

実施形態においては、サーバ２００は、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴと交換される複数のｃａｒｄＮＦＴの種類を決定するためのＮＦＴ生成規則２５０を備える。ＮＦＴ生成規則２５０は一例として、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴと交換される複数のｃａｒｄＮＦＴそれぞれのカテゴリＣ１，Ｃ２，Ｃ３，・・・の組み合わせである。カテゴリＣ１，Ｃ２，Ｃ３の組み合わせパターンが、ＮＦＴ生成規則２５０が多数設定されている。例えば、ｐａｃｋ６ＮＦＴのための組み合わせパターンの一例は、カテゴリＣ１のカードＮＦＴが２枚、カテゴリＣ３のカードＮＦＴが２枚、カテゴリＣ４のカードＮＦＴが１枚、カテゴリＣ６のカードＮＦＴが１枚である。ｐａｃｋ３ＮＦＴのための組み合わせパターンの一例は、カテゴリＣ２のカードＮＦＴが１枚、カテゴリＣ４のカードＮＦＴが１枚、カテゴリＣ５のカードＮＦＴが１枚である。ＮＦＴ生成規則２５０において発生頻度の低いカテゴリのカードＮＦＴは、レアカードとして扱われる可能性がある。

実施形態においては、一例として、ユーザ端末３００（のアプリケーションプログラム）又はサーバ３５０は、第５タイプ要求を送信する際に、サーバ２００にアクセスし、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴと交換される複数のｃａｒｄＮＦＴそれぞれのカテゴリＣ１，Ｃ２，Ｃ３，・・・の組み合わせを示す情報（組み合わせ情報）を取得する。取得した組み合わせ情報は、目的ＮＦＴの種類を識別するために用いられる情報として、第５タイプ要求とともに、スマートコントラクト１０１へ送信される。

第５タイプ要求は、第２スマートコントラクト１２０における第５モジュール１１５の呼び出しであるため、スマートコントラクト１０１が第５タイプ要求を受信すると、第５モジュール１１５が動作開始される。第５モジュール１１５における処理においては、まず、第５タイプ要求とともに受信したＮＦＴの種類が、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴであるか否かが判定される（ステップＳ１２１）。この判定は、ＮＦＴタイプ判定モジュール１１７によって行われる。

受信したＮＦＴの種類が、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴではない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ１２２）。この場合、第５モジュール１１５における処理は終了する。スマートコントラクト１０１は、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴを受信したことで、動作開始すべきモジュールが第５モジュール１１５であることを特定し、特定された第５モジュール１１５を動作開始させてもよい。つまり、受信したＮＦＴの種類（ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴ）が、識別情報を表し、識別情報としてのＮＦＴの種類が生成条件を決定する。この場合、ステップＳ１２１，Ｓ１２２は省略可能であり、ステップＳ２１３から実行される。

受信したＮＦＴの種類が、ｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴである場合、受信したＮＦＴの種類及び組み合わせ情報に応じて、目的ＮＦＴの生成条件が決定される（ステップＳ１２３）。ここでは、受信したＮＦＴが、ｐａｃｋ６ＮＦＴである場合、ＮＦＴ生成条件として、目的ＮＦＴの発行数Ｐ＝６、及び、目的ＮＦＴの種類Ｔ＝第４タイプ（ｃａｒｄ）、生成される目的カードＮＦＴのカテゴリと枚数、が決定される。生成されるカードＮＦＴのカテゴリと枚数は、受信した組み合わせ情報のとおり決定される。この生成条件は、目的ＮＦＴとして、第４タイプであるｃａｒｄＮＦＴが６個発行されるべきことを示す。つまり、ｐａｃｋ６ＮＦＴは、６個のｃａｒｄＮＦＴと交換される。また、この生成条件は、生成される６個のｃａｒｄＮＦＴのカテゴリとカテゴリ毎の枚数を示す。カテゴリとカテゴリ毎の枚数は、例えば、前述のとおり、カテゴリＣ１のカードＮＦＴが２枚、カテゴリＣ３のカードＮＦＴが２枚、カテゴリＣ４のカードＮＦＴが１枚、カテゴリＣ６のカードＮＦＴが１枚である。

受信したＮＦＴが、ｐａｃｋ３ＮＦＴである場合、ＮＦＴ生成条件として、目的ＮＦＴの発行数Ｐ＝３、及び、目的ＮＦＴの種類Ｔ＝第４タイプ（ｃａｒｄ）、生成されるカードＮＦＴのカテゴリと枚数、が決定される。この生成条件は、目的ＮＦＴとして、第４タイプであるｃａｒｄＮＦＴが３個発行されるべきことを示す。つまり、ｐａｃｋ３ＮＦＴは、３個のｃａｒｄＮＦＴと交換される。また、この生成条件は、生成される６個のｃａｒｄＮＦＴのカテゴリとカテゴリ毎の枚数を示す。カテゴリとカテゴリ毎の枚数は、例えば、前述のとおり、カテゴリＣ２のカードＮＦＴが１枚、カテゴリＣ４のカードＮＦＴが１枚、カテゴリＣ５のカードＮＦＴが１枚である。

なお、生成される目的カードＮＦＴのカテゴリと枚数は、スマートコントラクト１２０が、サーバ２００から取得してもよい。

続いて、生成条件に従って、Ｐ個（６個又は３個）の初期ＮＦＴ発行処理が実行され、Ｐ個の初期ＮＦＴの識別子が得られる（ステップＳ１２４）。発行される初期ＮＦＴそれぞれに、目的ＮＦＴの種類Ｔ＝第４タイプ（ｃａｒｄ）及びカテゴリなどの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるｃａｒｄＮＦＴを生成する（ステップＳ１２５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴそれぞれの記録を参照することで、各初期ＮＦＴの「目的ＮＦＴの種類Ｔ」及び「カテゴリ」などの生成条件を取得してもよい。ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝第４タイプ（ｃａｒｄ）及び「カテゴリ」に従い、複数のＮＦＴ用素材データ２４０の中から、ｃａｒｄＮＦＴのための構成データが選択される。データベース２３０が備える複数の素材データ２４０は、第４タイプ（ｃａｒｄ）であるｃａｒｄＮＦＴのための素材データを含む。システム１０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、構成データとなる素材データを選択し得る。ｃａｒｄＮＦＴのための構成データは、例えば、ｃａｒｄＮＦＴのカテゴリＣ１，Ｃ２，Ｃ３，・・を示す画像データ、ｃａｒｄＮＦＴのカテゴリ名称を示す文字データ、ｃａｒｄＮＦＴの題材に応じた画像データＤ１，Ｄ２，Ｄ３，・・・などを含む。カテゴリの名称は、例えば、プラチナ、ゴールド、又はシルバーといったランクを示す。

ｃａｒｄＮＦＴのカテゴリＣ１，Ｃ２，Ｃ３，・・を示す画像データ、及び、ｃａｒｄＮＦＴのカテゴリ名称を示す文字データは、生成条件が示す「カテゴリ」に従って、複数のＮＦＴ用素材データ２４０の中から選択される。ｃａｒｄＮＦＴの題材に応じた画像データＤ１，Ｄ２，Ｄ３，・・・は、例えば、ｃａｒｄＮＦＴの題材に応じた画像データの候補となる素材データの中から、サーバ２００によってランダムに決定される。例えば、ｃａｒｄＮＦＴの題材が、あるスポーツチームの選手である場合、そのスポーツチームに所属する複数の選手の画像データが、ｃａｒｄＮＦＴの題材に応じた画像データＤ１，Ｄ２，Ｄ３の候補として、登録されている。サーバ２００は、その候補の中から、ランダムに、ｃａｒｄＮＦＴの題材に応じた画像データを決定する。なお、ｃａｒｄＮＦＴの題材は、ｐａｃｋ６又はｐａｃｋ３の種類に応じて決定されてもよい。例えば、チームＡの選手のカードＮＦＴと交換されるチームＡ用ｐａｃｋ６ＮＦＴと、チームＢの選手のカードＮＦＴと交換されるチームＢ用ｐａｃｋ６ＮＦＴと、が存在してもよい。この場合、システム１０は、チームＡ用ｐａｃｋ６ＮＦＴを受信した場合、チームＡの選手の複数の画像データの中から選択された画像データを用いて、チームＡに属するある選手のカードＮＦＴを生成し得る。また、システム１０は、チームＢ用ｐａｃｋ６ＮＦＴを受信した場合、チームＢの選手の複数の画像データの中から選択された画像データを用いて、チームＢに属するある選手のカードＮＦＴを生成し得る。

実施形態においては、題材に応じた画像データとは別に、カテゴリに応じた画像データも、カードＮＦＴに付与されるため、カードＮＦＴのバリエーションが多くなり、収集の楽しみが大きくなっている。例えば、同じ選手の画像データが付与されたｃａｒｄＮＦＴであっても、カテゴリＣ１の画像が付与されたものと、カテゴリＣ２の画像が付与されたものとでは、異なる種類のものとして認識され得る。例えば、ある選手の同じ画像データを有する複数のｃａｒｄＮＦＴであっても、カテゴリＣ１である「プラチナ」を示す文字及び「プラチナ」に関する画像を有するものと、カテゴリＣ２である「ゴールド」を示す文字及び「ゴールド」に関する画像を有するものとでは、異なる種類のものとして認識され得る。同じ選手の画像データを有するｃａｒｄＮＦＴであっても、カテゴリが異なるため、ｃａｒｄＮＦＴの価値は異なり得る。

このようにして、Ｐ個（６個又は３個）のＮＦＴ分の構成データが生成される。そして、Ｐ個の初期ＮＦＴそれぞれに、ｃａｒｄＮＦＴのための構成データが組み込まれ、Ｐ個（６個又は３個）のｃａｒｄＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。Ｐ個のｃａｒｄＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０１へ送信する。スマートコントラクト１０１は、組込完了通知を受信すると、Ｐ個のｃａｒｄＮＦＴの生成の完了を認識し（ステップＳ１２６）、ｃａｒｄＮＦＴを、パックＮＦＴの送信元であるユーザアカウントへ送信する（ステップＳ１２７）。なお、構成データは、ｃａｒｄＮＦＴのシリアル番号など、個々のｃａｒｄＮＦＴを、他のｃａｒｄＮＦＴから区別してユニークにするための識別情報を含んでも良い。ｃａｒｄＮＦＴをユニークにするための識別情報を有していることで、あるｃａｒｄＮＦＴが、他のｃａｒｄＮＦＴにも用いられ得る共通の素材データを有していても、稀少価値を高め得る。

以上のようにして、ユーザは、ボックスＮＦＴを引き渡す代わりに、Ｐ個のｃａｒｄＮＦＴを入手できる。つまり、ユーザは、６枚又は３枚のカードが含まれるパックを開封したのと同様の体験が得られる。実施形態に係るシステム１０は、パックＮＦＴが引き渡された後にｃａｒｄＮＦＴを生成するため、パックＮＦＴが引き渡される前において、ユーザに渡すべきｃａｒｄＮＦＴを保有する必要がない。特に、実施形態に係るシステム１０においては、Ｍ×Ｎ個（カテゴリの数Ｍ×題材に応じた画像データＮ）という多くの種類のｃａｒｄＮＦＴが存在し得るが、そのような多種類のｃａｒｄＮＦＴを予め生成し、システム１０に保有させておく必要がない。

また、実施形態に係るシステム１０では、ｃａｒｄＮＦＴと交換されるｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴは、どのような種類のｃａｒｄＮＦＴと交換されるかは、予め決まっていない。したがって、販売される多数のｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴそれぞれに、交換されるｃａｒｄＮＦＴを予め割り当てておく作業が不要である。システム１０が生成すべきＮＦＴが、ｃａｒｄＮＦＴであることは、スマートコントラクト１０１へ送信されたＮＦＴの種類がｐａｃｋ６ＮＦＴ又はｐａｃｋ３ＮＦＴであることによって識別され得る。また、実施形態のスマートコントラクト１０１は、受信した要求送信トークンの数又は種類によって、どのような目的ノンファンジブルトークンを生成すべきかを識別して、適切な目的ノンファンジブルトークンを生成することができる。

以上のように、実施形態に係るスマートコントラクト１０１は、受信した要求送信トークンとして何を受信したかによって、どのような目的ＮＦＴを生成して送信するかが設定されている。そして、実施形態においては、スマートコントラクト１０１の動作開始（アクティブ化）の契機は、ユーザがスマートコントラクト１０１に何かを送ったことである。より具体的には、スマートコントラクト１０１の動作開始（アクティブ化）の契機は、ユーザがスマートコントラクト１０１に何らかのトークン（要求送信トークン）を送信したことである。

＜２．２ 第２実施形態：チケットＮＦＴ生成システム＞

図１３は、第２実施形態に係るシステム２０の一例を示している。第２実施形態において特に説明しない点については、第１実施形態に係るシステム１０と同様である。

第２実施形態に係るシステム２０は、ブロックチェーン等のコンピュータネットワークシステムに実装されたスマートコントラクト１０２と、サーバ２００と、を備える。第２実施形態に係るシステム２０は、デジタルチケットＮＦＴの販売又は発行サービスを提供するため、デジタルチケットＮＦＴを生成する。システム２０は、デジタルチケットＮＦＴの購入又は発行を希望するユーザが有する端末３００（ユーザ端末）との間で、ネットワークを介して、通信可能である。

第２実施形態に係るスマートコントラクト１０２は、チケットＮＦＴ生成処理を実行するよう構成されている。第２実施形態に係るサーバ２００は、ＮＦＴ構成データ組込処理２１２を実行するよう構成されている。また、第２実施形態に係るサーバ２００は、チケットＮＦＴ発行のため、ユーザからの予約受付処理２１５を実行し得る。

第２実施形態に係るシステム２０によって提供されるデジタルチケットＮＦＴは、チケットをＮＦＴ化したものである。デジタルチケットＮＦＴは、コンピュータ画面上に表示される。以下では、デジタルチケットＮＦＴを、チケットＮＦＴという。チケットＮＦＴも、任意の第三者との間で、取引可能である。

チケットは、例えば、コンサート・ライブ・劇・映画・セミナーなどのイベントへの参加のためのチケット、美術館・博物館などの施設への入場のためのチケット、鉄道・飛行機・バスなどの交通機関を利用するためのチケットで、商品・サービスの提供を受けるための引換チケット又は商品券である。チケットは、商品・サービス購入のための割引クーポンを含み得る。

実施形態に係るチケットＮＦＴは、ブロックチェーンにおいて発行されたＮＦＴに、チケットであることを示す画像データ又は文字データなどの構成データを組み込んで構成されている。構成データが組み込まれたＮＦＴは、例えば、構成データ自体又は構成データを示す直接的又は間接的に示すＵＲＩを有する。ＵＲＩは、構成データを直接的に示してもよいし間接的に示してもよい。例えば、イベントのためのチケットＮＦＴであれば、イベントのための画像データ又は文字データが組み込まれている。チケットＮＦＴに組み込まれる構成データは、チケットＮＦＴの目的（例えば、特定のイベント）毎に異なり得る。したがって、チケットＮＦＴの種類は、複数存在し得る。

第２実施形態に係るシステム２０は、イベントの種類・目的等に応じた種類のチケットＮＦＴを生成して、ユーザに提供できる。図１３に示すように、第２実施形態に係るシステム２０は、ユーザ用コンピュータであるユーザ端末３００等からのチケットＮＦＴ要求（ＮＦＴ要求）を受信し、目的ＮＦＴとして、チケットＮＦＴをユーザのアカウントへ送信する。ここでのチケットＮＦＴ要求は、チケット発行スマートコントラクト１０２の呼び出しとして行われる。チケット発行スマートコントラクト１０２は、呼び出されると、チケットＮＦＴ生成処理を実行する。

図１４は、チケット発行スマートコントラクト１０２におけるチケットＮＦＴ生成処理の手順を示している。まず、スマートコントラクト１０２は、ユーザ用コンピュータであるユーザ端末３００等から、ＮＦＴ要求を受信する。ＮＦＴ要求は、ユーザ用コンピュータであるサーバから受信してもよい。ここでのＮＦＴ要求は、チケットＮＦＴの発行の要求である。ＮＦＴ要求のため、チケットＮＦＴ購入代金としてのＦＴが受信される。ＦＴの送信は、ＦＴの所有者を送信元（ユーザアカウント）からスマートコントラクト１０１又はスマートコントラクト１０１の管理者のアカウントへ変更する操作を伴う。つまり、チケットＮＦＴ購入代金としてのＦＴが、ユーザから支払われたことになる。所有者変更はブロックチェーンにおいて記録される。チケットＮＦＴ要求の受信は、チケットＮＦＴと交換されるＮＦＴ（チケット引き換えＮＦＴ）の受信として行われても良い。チケット引き換えＮＦＴは、後述のチケット情報を有していてもよい。スマートコントラクト１０２は、チケット引き換えＮＦＴが有するチケット情報を用いて、チケットＮＦＴを生成することができる。

また、スマートコントラクト１０２は、ＮＦＴ要求とともに、チケット情報も受信する。チケット情報は、例えば、チケット番号、イベント名、予約された座席情報、イベントの日付、イベントの名前等を含む。チケット情報は、例えば、サーバ２００の予約受付処理２１５によって生成され、予約受付成立によって生成されたチケット情報が、ユーザ端末のチケット予約アプリケーションプログラムへ送信される。チケット予約アプリケーションプログラムは、受信したチケット情報とともにＮＦＴ要求をスマートコントラクト１０２へ送信する処理を、ユーザ用コンピュータであるユーザ端末３００（コンピュータ）等に実行させることができる。チケット情報は、目的ＮＦＴであるチケットＮＦＴの種類を識別するための識別情報として用いられ得る。生成すべきチケットＮＦＴの種類は、スマートコントラクト１０２が受信した要求送信トークンとしてのＦＴ又はＮＦＴ（チケット引き換えＮＦＴ）の数又は種類によって表されても良い。

スマートコントラクト１０２は、ＮＦＴ要求を受信すると、受信したＦＴの数量が、要求されたチケットＮＦＴ購入の必要数に合致しているか否かを判定する（ステップＳ１４１）。この判定は、ＦＴ数判定モジュール１１６によって行われる。なお、チケットＮＦＴ購入の必要数は、予めユーザ端末へ通知されている。

ＦＴの数量が、チケットＮＦＴ購入の必要数に合致していない場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ１４２）。この場合、チケット発行処理は終了する。

ＦＴの数量が、チケットＮＦＴ購入の必要数に合致している場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ１４３）。ここでは、生成条件として、受信したチケット情報に基づき、目的ＮＦＴの発行数Ｐ＝１、及び、目的ＮＦＴの種類Ｔ＝Ｅイベントが決定される。この生成条件は、目的ＮＦＴとして、ＥイベントのためのチケットＮＦＴが１個発行されるべきことを示す。生成条件は、スマートコントラクト１０２が受信した要求送信トークンとしてのＦＴ又はＮＦＴ（チケット引き換えＮＦＴ）の数又は種類によって決定されてもよい。

続いて、生成条件に従って、Ｐ個（１個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ１４４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝Ｅイベントなどの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴであるチケットＮＦＴを生成する（ステップＳ１４５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「初期ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。

ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝Ｅイベントに従い、複数のＮＦＴ用素材データ２４０の中から、Ｅイベントのための構成データ（例えば、Ｅイベントのための画像データ、Ｅイベントの名称、チケット番号、座席、日付等を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、イベントの種類が複数あることに応じて、複数の素材データを有する。つまり、データベース２３０は、Ｅイベントのための素材データを備える。システム２０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、複数の素材データの中から、構成データとなる素材データを選択し得る。ここでは、識別情報として受信したチケット情報（Ｅイベント）は、複数の素材データのいずれかを示すため、システム２０は、識別情報（Ｅイベント）に基づいて、複数の素材データの中から、ＮＦＴに組み込まれるデータを選択できる。そして、Ｅイベントのための構成データが初期ＮＦＴに組み込まれ、ＥイベントのためのチケットＮＦＴが完成する。Ｅイベントの名称等は、他の構成データの生成にも用いられ得る共通の素材データであり、チケット番号等は、構成データを、ユニークなデータとするための情報である。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。システム２０は、チケットＮＦＴを生成するために用いられるプライベートキーを有し、そのプライベートキーを用いて、チケットＮＦＴを生成する。システム１０は、ＮＦＴ生成用のプライベートキーを有しているため、ユーザのプライベートキーを用いなくても、チケットＮＦＴを生成できる。チケットＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０２へ送信する。スマートコントラクト１０２は、組込完了通知を受信すると、チケットＮＦＴの生成の完了を認識し（ステップＳ１４６）、チケットＮＦＴを、ＦＴの送信元であるユーザアカウントへ送信する（ステップＳ１４７）。

以上のようにして、ユーザは、ＦＴの支払いと引き換えに、チケットＮＦＴを入手できる。実施形態に係るシステム２０は、ＦＴが支払われた後にチケットＮＦＴを生成するため、ＦＴが支払われる前において、ユーザに渡すべき様々な種類のチケットＮＦＴを保有する必要がない。なお、チケットＮＦＴ要求は、チケットＮＦＴ購入代金の支払いを伴わなくてもよい。

＜２．３ 第３実施形態：証書ＮＦＴ生成システム＞

図１５は、第３施形態に係るシステム３０の一例を示している。第３実施形態において特に説明しない点については、第１実施形態に係るシステム１０及び第２実施形態に係るシステム２０と同様である。

第３実施形態に係るシステム３０は、ブロックチェーン等のコンピュータネットワークシステムに実装されたスマートコントラクト１０３と、サーバ２００と、を備える。第３実施形態に係るシステム３０は、保証証書ＮＦＴなどの証書ＮＦＴを提供するため、証書ＮＦＴを生成する。システム３０は、証書ＮＦＴの発行を希望するユーザが有する端末３００（ユーザ端末）等のユーザ用コンピュータとの間で、ネットワークを介して、通信可能である。

第３実施形態に係るスマートコントラクト１０３は、証書ＮＦＴ生成処理を実行するよう構成されている。第２実施形態に係るサーバ２００は、ＮＦＴ構成データ組込処理２１２を実行するよう構成されている。

第３実施形態に係るシステム３０によって提供される証書ＮＦＴは、保証証書などの証書をＮＦＴ化したものである。証書ＮＦＴは、コンピュータ画面上に表示される。証書ＮＦＴも、任意の第三者との間で、取引可能である。

保証証書は、例えば、日用品、宝飾品、電気製品、電子製品、機械製品、その他の商品、サービス又は権利関係（権利、義務、又は責任）についての何らかの保証を証明する文書である。証書は、前述の保証又はその他の事実を証明する文書である。

実施形態に係る保証証書ＮＦＴは、ブロックチェーンにおいて発行されたＮＦＴに、保証証書であることを示す画像データ又は文字データなどの構成データを組み込んで構成されている。構成データが組み込まれたＮＦＴは、例えば、構成データ自体又は構成データを示すＵＲＩを有する。ＵＲＩは、構成データを直接的に示してもよいし間接的に示してもよい。例えば、家電製品などの製品の不完全性・欠陥・故障についての修理等を保証する保証証書として機能する保証証書ＮＦＴであれば、その家電製品の画像データ及び保証内容を示す文字データが組み込まれている。証書ＮＦＴに組み込まれる構成データは、証書としての種類毎に異なり得る。したがって、保証証書ＮＦＴの種類は、複数存在し得る。

第３実施形態に係るシステム３０は、保証対象の製品の種類に応じた保証証書ＮＦＴを生成して、ユーザに提供できる。図１５に示すように、第３実施形態に係るシステム３０は、ユーザ端末３００からの証書ＮＦＴ要求を受信し、目的ＮＦＴとして、保証証書ＮＦＴを生成し、ユーザ端末３００（ユーザアカウント）へ送信する。保証対象の製品の保証期間は、製品の購入日を起算日（保証の起算日）としてもよいが、保証証書ＮＦＴをブロックチェーンにおいて発行した日を起算日（保証の起算日）としてもよい。

図１６は、保証証書発行スマートコントラクト１０３における保証証書発行処理の手順を示している。まず、スマートコントラクト１０３は、ユーザ端末３００から、ＮＦＴ要求を受信する。ここでのＮＦＴ要求は、保証証書ＮＦＴの発行の要求である。スマートコントラクト１０３は、ＮＦＴ要求とともに、保証対象製品の製品情報も受信する。製品情報は、製品名、製品の購入日時、製品の購入場所、及び製品固有記号（製品固有識別子）等の少なくとのもいずれか１つを含む。製品情報は、例えば、製品又は製品に付属した書類その他の物体に付された、機械読み取り可能なコード（例えば、２次元コード）に記録されているのが好ましい。例えば、ユーザ端末３００のカメラ（コード読み取り器）によって、２次元コードなどを読み取ることで、ユーザ端末３００は、製品情報を得られる。製品情報は、機械読み取り可能なコードによって示されるＵＲＩ（Uniform Resource Identifier）によって示される、ネットワーク上のコンピュータ（例えば、サーバ２００）に格納された電子データとして存在してもよい。この場合、ユーザ端末３００のカメラによってコードを読み取って、そのコードが示すＵＲＩへネットワークアクセスすることで、製品情報が得られる。

製品情報は、目的ＮＦＴである保証証書ＮＦＴの種類を識別するために用いられる。

スマートコントラクト１０３は、ＮＦＴ要求を受信すると、受信した製品情報の適否を判定する（ステップＳ１６１）。この判定は、例えば、製品固有記号が、実際に存在するか否かの判定である。

ＦＴの数量が、製品情報が不適である場合、その旨をユーザ端末３００へ通知するなどのエラー処理が行われる（ステップＳ１６２）。この場合、保証証書発行処理は終了する。

製品情報が適切である場合、続いて、目的ＮＦＴの生成条件が決定される（ステップＳ１６３）。ここでは、生成条件として、受信した製品情報に基づき、目的ＮＦＴの発行数Ｐ＝１、及び、目的ＮＦＴの種類Ｔ＝Ｇ製品が決定される。この生成条件は、目的ＮＦＴとして、Ｇ製品のための保証証書ＮＦＴが１個発行されるべきことを示す。

続いて、生成条件に従って、Ｐ個（１個）の初期ＮＦＴ発行処理が実行され、初期ＮＦＴの識別子が得られる（ステップＳ１６４）。発行される初期ＮＦＴに、目的ＮＦＴの種類Ｔ＝Ｇ製品などの生成条件を示すデータが含まれるように、初期ＮＦＴの発行処理が行われても良い。

サーバ２００は、初期ＮＦＴ発行を検出すると、目的ＮＦＴの生成条件及び初期ＮＦＴの識別子を取得し、ＮＦＴ構成データ組込処理を実行し、目的ＮＦＴである保証証書ＮＦＴを生成する（ステップＳ１６５）。サーバ２００は、ブロックチェーンにおける初期ＮＦＴの記録を参照することで、「初期ＮＦＴの種類Ｔ」などの生成条件を取得してもよい。

ＮＦＴ構成データ組込処理では、目的ＮＦＴの種類Ｔ＝Ｇ製品に従い、複数のＮＦＴ用素材データ２４０の中から、Ｇ製品のための構成データ（例えば、Ｇ製品のための画像データ、Ｇ製品の名称、Ｇ製品の購入日時、Ｇ製品の購入場所、及び製品固有記号（製品固有識別子）、保証期間を示す文字データ）が選択される。データベース２３０が備える複数の素材データ２４０は、製品の種類が複数あることに応じて、複数の素材データを有する。つまり、データベース２３０は、Ｇ製品のための素材データを備える。システム３０は、受信した識別情報に基づいて識別された種類Ｔに基づいて、複数の素材データの中から、構成データとなる素材データを選択し得る。ここでは、識別情報として受信した製品情報（Ｇ製品）は、複数の素材データのいずれかを示すため、システム３０は、識別情報（Ｇ製品）に基づいて、複数の素材データの中から、ＮＦＴに組み込まれるデータを選択できる。そして、Ｇ製品のための構成データが初期ＮＦＴに組み込まれることで、Ｇ製品のための保証証書ＮＦＴが完成する。なお、構成データは初期ＮＦＴの発行時に組み込まれてもよい。システム３０は、保証書ＮＦＴを生成するために用いられるプライベートキーを有し、そのプライベートキーを用いて、保証書ＮＦＴを生成する。システム１０は、ＮＦＴ生成用のプライベートキーを有しているため、ユーザのプライベートキーを用いなくても、保証書ＮＦＴを生成できる。保証証書ＮＦＴが完成すると、サーバ２００は、完了通知をスマートコントラクト１０３へ送信する。スマートコントラクト１０３は、組込完了通知を受信すると、保証証書ＮＦＴの生成の完了を認識し（ステップＳ１６６）、保証証書ＮＦＴを、ＮＦＴ要求の送信元であるユーザアカウントへ送信する（ステップＳ１６７）。Ｇ製品の名称等は、他の構成データの生成にも用いられ得る共通の素材データであり、製品固有記号等は、構成データを、ユニークなデータとするための情報である。

以上のようにして、ユーザは、保証証書ＮＦＴを入手できる。実施形態に係るシステム３０は、ＮＦＴ要求を受信した後に、保証証書ＮＦＴを生成するため、ＮＦＴ要求前（例えば、製品を製造してから販売されるまでの間）において、保証証書ＮＦＴを準備する必要がなく、販売されていない製品のための保証証書ＮＦＴ作成の手間を省略できる。

＜２．４ 第４実施形態：構成データの保存と参照＞

図１７は、前述及び後述の各実施形態において利用し得る、構成データの保存と参照方法を示している。素材データのデータベース２４０には、複数の素材データが格納されている。例えば、複数の素材データは、第１素材データを含み、第１素材データは、あるタレントの画像データであるとする。第１素材データは複製されて、第１構成データとしてサーバ２００の構成データのデータベース２４５に保存される。つまり、第１構成データは、第１素材データの複製データである。第１構成データは、第１素材データとは異なるファイル名を有すること又は異なる位置に保存されることで、第１素材データとは別個のデータとして存在する。インターネット等のネットワークにおける第１構成データは第１ＵＲＩ（第１ユニフォームリソースアイデンティファイア）によって示される。第１構成データが第１初期ＮＦＴに組み込まれることで、第１目的ＮＦＴが生成される。

また、第１素材データは、複製されて、第２構成データとしてサーバ２００の構成データのデータベース２４５に保存される。つまり、第２構成データは、第１素材データの複製データである。第２構成データは、第１素材データ及び第１構成データとは異なるファイル名を有すること又は異なる位置に保存されることで、第１素材データ及び第１構成データとは別個のデータとして存在する。インターネット等のネットワークにおける第２構成データは、第１ＵＲＩとは異なる第２ＵＲＩ（第２ユニフォームリソースアイデンティファイア）によって示される。第２構成データが、第１初期ＮＦＴとは異なる第２初期ＮＦＴに組み込まれることで、第２目的ＮＦＴが生成される。

したがって、第１目的ＮＦＴ及び第２目的ＮＦＴは、同じタレントの同じ画像データを構成データとして有している。つまり、第１目的ＮＦＴが有する第１構成データは、第２目的ＮＦＴが有する第２構成データの生成にも用いられた第１素材データから生成されている。しかし、構成データのデータベース２４５に保存された第１構成データ及び第２構成データは、それぞれ別個のデータである。つまり、第１構成データは、第１目的ＮＦＴのためのユニークなデータであり、第１目的ＮＦＴ以外のＮＦＴに組み込まれることはない。同様に、第２構成データは、第２目的ＮＦＴのためのユニークなデータであり、第２目的ＮＦＴに組み込まれることはない。したがって、第１目的ＮＦＴ及び第２目的ＮＦＴそれぞれを唯一無二のものとすることができる。したがって、例えば、第１目的ＮＦＴには、タレントのサイン画像を付加することで、第２目的ＮＦＴとの価値の相違を生じさせることができる。また、第１目的ＮＦＴの所有者履歴によって、第２目的ＮＦＴとの価値の相違を生じさせることができる。

第１目的ＮＦＴになる第１初期ＮＦＴに第１構成データを組み込むことは、例えば、第１初期ＮＦＴに、第１ＵＲＩ又は第１ＵＲＩに対応付けられた識別子を書き込むことであってもよい。第１ＵＲＩは、複製データである第１構成データを示す。第１目的ＮＦＴが第１ＵＲＩを有することで、サーバ２００は、第１ＵＲＩによるネットワークアクセスを受け付け、第１構成データを第１目的ＮＦＴの所有者の端末等に表示させることができる。第１ＵＲＩに対応付けられた識別子は、例えば、サーバ２００が、第１ＵＲＩを認識するために用いられる情報であれば足りる。又第１目的ＮＦＴが第１ＵＲＩに対応付けられた識別子を有することで、サーバ２００は、第１ＵＲＩに対応付けられた識別子を用いたネットワークアクセスを受け付け、その識別子から第１ＵＲＩを特定し、その第１ＵＲＩが示す第１構成データを第１目的ＮＦＴの所有者の端末等に表示させることができる。第２目的ＮＦＴについても同様である。

また、第１目的ＮＦＴになる第１初期ＮＦＴに、第１構成データを組み込むには、サーバ２００に、第１目的ＮＦＴ（第１初期ＮＦＴ）の識別子（ＮＦＴ－ＩＤ）と、第１ＵＲＩと、の対応関係を設定することであってもよい。サーバ２００は、第１目的ＮＦＴの識別子（ＮＦＴ－ＩＤ）を用いたネットワークアクセスを受け付け、第１目的ＮＦＴの識別子（ＮＦＴ－ＩＤ）から第１ＵＲＩを特定し、その第１ＵＲＩが示す第１構成データを第１目的ＮＦＴの所有者の端末等に表示させることができる。第２ＮＦＴについても同様である。

データベース２４６は、一例として、ＩＰＦＳ（ＩｎｔｅｒＰｌａｎｅｔａｒｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）によって構成され得る。ＩＰＦＳは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）分散ファイルシステムの一例である。ＩＰＦＳにおいて、保存されたデータ（コンテンツ）は、そのデータから求められたハッシュ値を用いたＵＲＩによって指定される。このＵＲＩは、構成データを示す識別子であり、コンテンツ識別子とも呼ばれる。ＮＦＴに構成データを組み込むには、例えば、ＩＰＦＳに保存された構成データ（コンテンツ）を指定するＵＲＩをＮＦＴに書き込めばよい。すなわち、ＮＦＴは、ＩＰＦＳに保存された構成データを示すＵＲＩを有し得る。なお、ＮＦＴは、構成データ（コンテンツ）と、構成データ（コンテンツ）を示すＵＲＩを含むメタデータと、メタデータを示すＵＲＩを含むインデックスデータと、を備え得る。インデックスデータは、ＮＦＴの識別子（ＮＦＴ－ＩＤ；トークン識別子）及びＮＦＴの所有者（所有者ブロックチェーンアドレス）を含み得る。一例として、インデックスデータは、ブロックチェーンに記録され、構成データ及びメタデータは、ＩＰＦＳに記録され得る。前述の初期ＮＦＴは、インデックスデータを有し、メタデータ及び構成データを有していてなくてもよい。メタデータ及び構成データは、構成データの組込処理によって、ＮＦＴに付加され得る。ブロックチェーンに記録されたインデックスデータは、ＩＰＦＳ等のブロックチェーン外に保存された構成データを直接的に示すＵＲＩを有していてもよいし、構成データを直接的に示すＵＲＩを含むメタデータを示すＵＲＩのように、間接的に構成データを示すＵＲＩを有していてもよい。このように、ＮＦＴは、その全てがブロックチェーンに記録されている必要はなく、インデックスデータなどの少なくとも一部のデータがブロックチェーンに記録されていれば足りる。

＜２．５ 第５実施形態＞

図１８は、第５実施形態に係るシステムシステム５０の一例を示している。第５実施形態において特に説明しない点については、前述の実施形態に係るシステム１０，２０，３０と同様である。

システム５０は、端末３００等のコンピュータから、画像Ｐ１を示すコードＣ１を有するＮＦＴ要求を受信し得る（ステップＳ１８１Ａ）。コードＣ１は、目的ＮＦＴの種類をシステム５０が識別するための識別情報であり得る。システム５０が備えるデータベース２３０は、複数の素材データＰ１，Ｐ２，Ｐ３を備え、各素材データＰ１，Ｐ２，Ｐ３にはコードＣ１，Ｃ２，Ｃ３が対応付けられている。素材データＰ１，Ｐ２，Ｐ３に対応付けられたコードＣ１は、対応する素材データＰ１，Ｐ２，Ｐ３を示す。システム５０は、ステップＳ１８１Ａにおいて受信したコードＣ１に対応する第１素材データＰ１を選択し、選択された第１素材データＰ１を用いて、目的ＮＦＴを生成する（ステップＳ１８２）。第１素材データＰ１を用いて生成された目的ＮＦＴは、「画像Ｐ１を有する」という種類のＮＦＴであり得る。第１素材データＰ１を用いて生成された目的ＮＦＴは、例えば、第１素材データの識別子（例えば、ＵＲＩ）、又は、第１素材データの複製データの識別子（例えば、ＵＲＩ）を備え得る。

また、システム５０は、端末３００等のコンピュータから、画像Ｐ２を示すコードＣ２を有するＮＦＴ要求を受信し得る（ステップＳ１８１Ｂ）。コードＣ２は、目的ＮＦＴの種類をシステム５０が識別するための識別情報であり得る。システム５０は、ステップＳ１８１Ｂにおいて受信したコードＣ２に対応する第２素材データＰ２を選択し、選択された第２素材データＰ２を用いて、目的ＮＦＴを生成する（ステップＳ１８２）。第２素材データＰ２を用いて生成された目的ＮＦＴは、「画像Ｐ２を有する」という種類のＮＦＴであり得る。第２素材データＰ２を用いて生成された目的ＮＦＴは、例えば、第２素材データの識別子（例えば、ＵＲＩ）、又は、第２素材データの複製データの識別子（例えば、ＵＲＩ）を備え得る。

システム５０は、ＮＦＴの生成に用いられる画像など素材データを有しているため、端末３００などの外部のコンピュータから、ＮＦＴの生成に用いられる素材データを取得しなくても、ＮＦＴを生成できる。ただし、システム５０は、ＮＦＴの生成に用いられる素材データの一部を外部のコンピュータから取得してもよい。システム５０は、ＮＦＴ要求を受信する（ステップＳ１８１Ａ，Ｓ１８１Ｂ）前から有している素材データＰ１，Ｐ２，Ｐ３を少なくとも用いて、ＮＦＴを生成することができる。

＜２．６ 第６実施形態＞

図１９は、第６実施形態に係るシステムシステム６０の一例を示している。第６実施形態において特に説明しない点については、前述の実施形態に係るシステム１０，２０，３０，５０と同様である。

システム６０は、図示しない端末３００等のコンピュータから、ＮＦＴ要求を受信し得る（ステップＳ１９１）。ＮＦＴ要求は、生成される目的ＮＦＴのタイプを示すデータを有する。タイプを示すデータは、目的ＮＦＴの種類をシステム５０が識別するための識別情報であり得る。システム６０が備えるデータベース２３０は、複数のタイプに応じた素材データを備える。例えば、図１９に示すデータベース２３０は、第１タイプ（ＴＹＰＥ＿Ａ）のための複数の素材データＰ１１，Ｐ１２，Ｐ１３を備えるとともに、第２タイプ（ＴＹＰＥ＿Ｂ）のための複数の素材データＰ２１，Ｐ２２，Ｐ２３を備える。

システム６０は、第１タイプ（ＴＹＰＥ＿Ａ）を示すデータを識別情報として有するＮＦＴ要求を受信すると（ステップＳ１９１Ａ）、そのＮＦＴ要求に基づいてタイプが第１タイプ（ＴＹＰＥ＿Ａ）であることを識別する。さらに、システム６０は、識別したタイプに応じた複数の素材データＰ１１，Ｐ１２，Ｐ１３の中から、目的ＮＦＴの生成に用いられる素材データ（例えば、画像Ｐ１２）を選択する。目的ＮＦＴの生成に用いられる素材データは、識別されたタイプ（ＴＹＰＥ＿Ａ）に応じた複数の素材データＰ１１，Ｐ１２，Ｐ１３の中から、所定の規則又はランダムに選択される。システム６０は、選択された素材データを用いて、目的ＮＦＴを生成する（ステップＳ１９２）。生成された目的ＮＦＴは、ＴＹＰＥ＿Ａという種類のＮＦＴであり得る。

システム６０は、第２タイプ（ＴＹＰＥ＿Ｂ）を示すデータを識別情報として有するＮＦＴ要求を受信すると（ステップＳ１９１Ｂ）、そのＮＦＴ要求に基づいてタイプが第２タイプ（ＴＹＰＥ＿Ｂ）であることを識別する。さらに、システム６０は、識別したタイプに応じた複数の素材データＰ２１，Ｐ２２，Ｐ２３の中から、目的ＮＦＴの生成に用いられる素材データ（例えば、画像Ｐ２３）を選択する。目的ＮＦＴの生成に用いられる素材データは、識別されたタイプ（ＴＹＰＥ＿Ｂ）に応じた複数の素材データＰ２１，Ｐ２２，Ｐ２３の中から、所定の規則又はランダムに選択される。システム６０は、選択された素材データを用いて、目的ＮＦＴを生成する（ステップＳ１９２）。生成された目的ＮＦＴは、ＴＹＰＥ＿Ｂという種類のＮＦＴであり得る。

＜２．７ 第７実施形態＞

図２０は、第７実施形態に係るシステムシステム７０の一例を示している。第７実施形態において特に説明しない点については、前述の実施形態に係るシステム１０，２０，３０，５０，６０と同様である。

システム７０は、図示しないユーザ端末３００から、ＮＦＴ要求を受信し得る（ステップＳ１９１）。ＮＦＴ要求は、コードを有し得る。コードは、ＮＦＴの取得を希望するユーザに付与又は通知されたデータである。コードは、ユーザがＮＦＴを取得するための資格情報であり得る。例えば、第１ユーザは、第１ユーザに付与又は通知された第１コードをシステム７０に送信することで、ＮＦＴを受信することができる。また、第２ユーザは第２ユーザに付与又は通知された第２コードをシステム７０に送信することで、ＮＦＴを受信することができ、第３ユーザは、第３ユーザに付与又は通知された第３コードをシステム７０に送信することで、ＮＦＴを受信することができる。

コードは、目的ＮＦＴの種類をシステム７０が識別するための識別情報であり得る。コードは、システム７０が素材データのタイプを識別するためのデータであり得る。システム７０が備えるデータベース２３０は、複数のタイプに応じた素材データを備える。例えば、図２０に示すデータベース２３０は、第１タイプ（ＴＹＰＥ＿Ａ）のための複数の素材データＰ１１，Ｐ１２，Ｐ１３を備えるとともに、第２タイプ（ＴＹＰＥ＿Ｂ）のための複数の素材データＰ２１，Ｐ２２，Ｐ２３を備える。

システム７０は、受信する可能性のあるコードの一覧を示すコードリスト（図示省略）を有し得る。コードリストに含まれる複数のコードそれぞれには、タイプが対応付けられている。一例として、システム７０においては、第１コード及び第２コードは第１タイプ（ＴＹＰＥ＿Ａ）に対応付けられており、第３コードは、第２タイプ（ＴＹＰＥ＿Ｂ）に対応付けられている。この場合、システム７０は、第１コードを有するＮＦＴ要求を受信した場合（ステップＳ２０１Ａ）、又は、第２コードを有するＮＦＴ要求を受信した場合（ステップＳ２０１Ｂ）、受信したコードに基づいて、素材データのタイプが第１タイプ（ＴＹＰＥ＿Ａ）であることを識別する。システム７０は、第１タイプ（ＴＹＰＥ＿Ａ）用素材データＰ１１，Ｐ１２，Ｐ１３の中から、目的ＮＦＴの生成に用いられる素材データ（例えば、画像Ｐ１１）を選択する。目的ＮＦＴの生成に用いられる素材データは、識別されたタイプ（ＴＹＰＥ＿Ａ）に応じた複数の素材データＰ１１，Ｐ１２，Ｐ１３の中から、所定の規則又はランダムに選択される。システム７０は、選択された素材データを用いて、目的ＮＦＴを生成する（ステップＳ２０２）。生成された目的ＮＦＴは、ＴＹＰＥ＿Ａという種類のＮＦＴであり得る。

システム７０は、第３コードを有するＮＦＴ要求を受信した場合（ステップＳ２０１Ｃ）、受信したコードに基づいて、素材データのタイプが第２タイプ（ＴＹＰＥ＿Ｂ）であることを識別する。システム７０は、第２タイプ（ＴＹＰＥ＿Ｂ）用素材データＰ２１，Ｐ２２，Ｐ２３の中から、目的ＮＦＴの生成に用いられる素材データ（例えば、画像Ｐ２２）を選択する。目的ＮＦＴの生成に用いられる素材データは、識別されたタイプ（ＴＹＰＥ＿Ｂ）に応じた複数の素材データＰ２１，Ｐ２２，Ｐ２３の中から、所定の規則又はランダムに選択される。システム７０は、選択された素材データを用いて、目的ＮＦＴを生成する（ステップＳ２０２）。生成された目的ＮＦＴは、ＴＹＰＥ＿Ｂという種類のＮＦＴであり得る。

なお、ＮＦＴ要求が、コードなどの識別情報を有しない場合、システム１０，２０，３０，５０，６０，７０は、ＮＦＴ要求を受信すると、目的ＮＦＴの生成に用いられる素材データを、複数の識別データの中から、所定の規則に従って又はランダムに選択することができる。

＜２．７ 第７実施形態：プライベートキーの利用＞

図２１は、プライベートキーの取り扱いに関する技術を示している。図２１に示す技術は、第１実施形態のシステム１０及び他の実施形態のシステムにおいて採用可能である。ＮＦＴ要求（ステップＳ２１２）を受信したスマートコントラクト１１０，１２０は、スマートコントラクト１１０，１２０のサーバ２００が有する１又は複数のプライベートキーＫｅｙ１，Ｋｅｙ２，Ｋｅｙ３のいずれかを用いて、ＮＦＴ生成のためのトランザクションに電子署名する（ステップＳ２１３）。電子署名されたトランザクションは、ブロックチェーンに記録される。これによりＮＦＴが生成される（ステップＳ２１４）。第三者から参照可能なブロックチェーン上のスマートコントラクト１１０，１２０は、第三者が参照可能なため、プライベートキーを有していると、第三者にプライベートキーが知られるおそれがある。サーバ２００などの外部のコンピュータが、ＮＦＴ生成用プライベートキーＫｅｙ１，Ｋｅｙ２，Ｋｅｙ３を有していることで、プライベートキーＫｅｙ１，Ｋｅｙ２，Ｋｅｙ３を安全に保管できる。

スマートコントラクト１１０，１２０は、ＮＦＴ生成（ステップＳ２１４）の必要が生じた場合、その旨をサーバ２００へ通知し、電子署名のためのプライベートキーを取得する。サーバ２００は、複数のプライベートキーＫｅｙ１，Ｋｅｙ２，Ｋｅｙ３の中からＮＦＴ生成に用いられる一つのプライベートキーを適宜選択し、スマートコントラクト１１０，１２０に提供する。スマートコントラクト１１０，１２０は、取得したプライベートキーを用いて電子署名をする。すなわち、システム１０は、スマートコントラクト１１０，１２０によってＮＦＴを生成するが、スマートコントラクト１１０，１２０の外部のコンピュータ２００に保管されているプライベートキーを用いて、ＮＦＴを生成する。なお、電子署名は、サーバ２００がおこなってもよい。

図２１において、スマートコントラクト１１０，１２０は、Ｗｅｂサーバ３５０から、ＮＦＴ要求を受信し得る（ステップＳ２１２）。Ｗｅｂサーバ３５０は、図１に示すユーザ用コンピュータの一例である。Ｗｅｂサーバ３５０は、ユーザインターフェースをユーザ端末３００に提供し得る。ユーザインターフェースは、例えば、ＮＦＴ化される画像を表示するとともに、ＮＦＴの取得のためのユーザ操作を受け付けるＷｅｂサイトである。ユーザは、ユーザ端末３００を利用して、Ｗｅｂサイトにサインインし得る（ステップＳ２１１）。サインインには、ユーザのプライベートキー３０１が用いられる。ユーザは、プライベートキー３０１に対応するブロックチェーンアドレス３０２を有する。図２１において、ユーザのブロックチェーンアドレス３０２は、一例として、０ｘ１３５７９である。ブロックチェーンアドレス３０２は、プライベートキー３０１から生成され得る。

ユーザは、プライベートキー３０１を用いてＷｅｂサイトにサインインすることで、Ｗｅｂサイトを介して、ブロックチェーンの操作が可能となる。すなわち、Ｗｅｂサーバ３５０は、Ｗｅｂサイトにサインインしたユーザのために、ブロックチェーンに記録されるトランザクションにプライベートキー３０１を用いて電子署名することができる。なお、電子署名は、ユーザ端末３００が行ってもよい。

Ｗｅｂサーバ３５０によるブロックチェーンの操作は、一例として、スマートコントラクト１１１０，１２０の呼び出しである（ステップＳ２１２）。ここでのスマートコントラクトの呼び出しは、スマートコントラクトへのＮＦＴ要求の送信でもある。

スマートコントラクト１１０，１２０の呼び出しの際には、ユーザのブロックチェーンアドレス３０２がスマートコントラクト１１０，１２０へ送信される。スマートコントラクト３０２は、生成したＮＦＴを、受信したブロックチェーンアドレス３０２へ送信する。このように、スマートコントラクト１１０，１２０は、ＮＦＴ要求と生成したＮＦＴの送信先アドレス３０２とを受信し得る。なお、ブロックチェーンアドレス３０２は、スマートコントラクト１１０，１２０が呼び出された後に、スマートコントラクト１１０，１２０へ送信されてもよい。

図２１に示す技術によると、ユーザは、生成されたＮＦＴの送信先となるブロックチェーンアドレス３０２をシステム１０（例えば、スマートコントラクト１１０，１２０）に提供すればよく、ユーザは、ＮＦＴ生成のため、自身のプライベートキー３０１をシステム１０（例えば、スマートコントラクト１１０，１２０）に提供する必要がない。したがって、ユーザのプライベートキー３０１の秘匿性を確保しやすい。

ＮＦＴの生成に用いられるプライベートキーが、ユーザが有するプライベートキー３０１ではなく、システム１０が有するプライベートキーＫｅｙ１，Ｋｅｙ２，Ｋｅｙ３であるため、ＮＦＴを生成した時点において、ＮＦＴの所有者はシステム１０である。しかし、ＮＦＴは生成された後、ユーザのアドレス３０２へ送信されるため、生成されたＮＦＴの所有者はユーザになる。

本発明は、上記実施形態に限定されるものではなく、様々な変形が可能である。

実施形態に係るシステムは、次のとおりであってもよい。すなわち、実施形態に係るシステムは、ノンファンジブルトークンを生成する処理を実行するよう構成されたノンファンジブルトークン生成システムであって、複数の素材データを備えるデータベースを備え得る。前記ノンファンジブルトークンを生成する前記処理は、ノンファンジブルトークン要求を受信すると、前記データベースが備える複数の素材データの中から、所定の規則に従って又はランダムに、データを選択し、選択された前記データを用いて、ノンファンジブルトークンを生成する、ことを備え得る。

実施形態に係る方法は、次のとおりであってもよい。すなわち、実施形態に係る方法は、ノンファンジブルトークン生成システムによって実行されるノンファンジブルトークン生成方法であって、前記ノンファンジブルトークン生成システムは、複数の素材データを備えるデータベースを備え得る。前記方法は、ノンファンジブルトークン要求を受信すると、前記データベースが備える複数の素材データの中から、所定の規則に従って又はランダムに、データを選択し、選択された前記データを用いて、ノンファンジブルトークンを生成する、ことを備え得る。

１０ ：ノンファンジブルトークン生成システム
２０ ：ノンファンジブルトークン生成システム
３０ ：ノンファンジブルトークン生成システム
５０ ：ノンファンジブルトークン生成システム
６０ ：ノンファンジブルトークン生成システム
７０ ：ノンファンジブルトークン生成システム
１００ ：コンピュータネットワークシステム
１０１ ：スマートコントラクト
１０２ ：チケット発行スマートコントラクト
１０３ ：保証証書発行スマートコントラクト
１１０ ：第１スマートコントラクト
１１１ ：第１モジュール
１１２ ：第２モジュール
１１３ ：第３モジュール
１１４ ：第４モジュール
１１５ ：第５モジュール
１１６ ：ファンジブルトークン数判定モジュール
１１７ ：ＮＦＴタイプ判定モジュール
１２０ ：第２スマートコントラクト
２００ ：サーバ
２１０ ：プロセッサ
２１２ ：ＮＦＴ構成データ組込処理
２１５ ：予約受付処理
２２０ ：メモリ
２３０ ：データベース
２４０ ：ＮＦＴ用素材データ（素材データのデータベース）
２４５ ：構成データのデータベース
２５０ ：ＮＦＴ生成規則
２６０ ：コンピュータプログラム
３００ ：ユーザ端末（ユーザ用コンピュータ）
３０１ ：プライベートキー
３０２ ：ブロックチェーンアドレス
３１０ ：操作画面
３１１ ：ボタン
３１２ ：ボタン
３１３ ：ボタン
３１４ ：ボタン
３１５ ：ボタン
３５０ ：サーバ（アプリケーションサーバ；ユーザ用コンピュータ）
Ｃ１ ：カテゴリ
Ｃ２ ：カテゴリ
Ｃ３ ：カテゴリ
Ｄ１ ：画像データ
Ｄ２ ：画像データ
Ｄ３ ：画像データ
Ｍ ：カテゴリデータ数
Ｎ ：画像データ数
Ｐ ：発行数
Ｔ ：種類

Claims (7)

1. ノンファンジブルトークンをユーザに提供するために、コンピュータによって実行されるノンファンジブルトークン生成方法であって、
   ユーザの端末から、前記ユーザに提供すべきノンファンジブルトークンの種類を識別するための識別情報を有するノンファンジブルトークン要求を受信し、
   前記ユーザの前記端末から前記ノンファンジブルトークン要求を受信した後に、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて、前記ユーザに提供すべきノンファンジブルトークンの種類を識別し、識別された前記種類のノンファンジブルトークンを生成する
   ことを備える、ノンファンジブルトークン生成方法。
2. 識別された前記種類のノンファンジブルトークンは、識別された前記種類のノンファンジブルトークンの生成に用いられる複数の素材データの中から、ランダムに選択された素材データを用いて生成される
   請求項１に記載のノンファンジブルトークン生成方法。
3. ノンファンジブルトークンをユーザに提供するために、コンピュータによって実行されるノンファンジブルトークン生成方法であって、
   ユーザの端末からノンファンジブルトークン要求を受信し、
   前記ユーザの前記端末から前記ノンファンジブルトークン要求を受信した後に、ノンファンジブルトークンの生成に用いられる複数の素材データの中から、ランダムに選択された素材データを用いて、前記ユーザに提供すべきノンファンジブルトークンを生成する
   ことを備える、ノンファンジブルトークン生成方法。
4. 生成された前記ノンファンジブルトークンは、共通の素材データを有する他のノンファンジブルトークンと区別するためのシリアル番号を有し、前記シリアル番号は、生成されたノンファンジブルトークンが提供された前記ユーザの前記端末に表示される
   請求項２又は請求項３に記載のノンファンジブルトークン生成方法。
5. 生成された前記ノンファンジブルトークンは、他のノンファンジブルトークンと区別するためのシリアル番号を有し、前記シリアル番号は、生成されたノンファンジブルトークンが提供された前記ユーザの前記端末に表示される
   請求項１に記載のノンファンジブルトークン生成方法。
6. ユーザに提供すべきノンファンジブルトークンを生成するノンファンジブルトークン生成システムであって、
   ユーザの端末から、前記ユーザに提供すべきノンファンジブルトークンの種類を識別するための識別情報を有するノンファンジブルトークン要求を受信し、
   前記ユーザの前記端末から前記ノンファンジブルトークン要求を受信した後に、前記ノンファンジブルトークン要求が有する前記識別情報に基づいて、前記ユーザに提供すべきノンファンジブルトークンの種類を識別し、識別された前記種類のノンファンジブルトークンを生成する
   ことを実行するよう構成されている、ノンファンジブルトークン生成システム。
7. ユーザに提供すべきノンファンジブルトークンを生成するノンファンジブルトークン生成システムであって、
   ユーザの端末からノンファンジブルトークン要求を受信し、
   前記ユーザの前記端末から前記ノンファンジブルトークン要求を受信した後に、ノンファンジブルトークンの生成に用いられる複数の素材データの中から、ランダムに選択された素材データを用いて、前記ユーザに提供すべきノンファンジブルトークンを生成する
   ことを実行するよう構成されている、ノンファンジブルトークン生成システム。
   

Images