JP2023167674A - 情報処理方法、プログラム及び情報処理システム - Google Patents

Abstract

【課題】チケットＮＦＴにおけるイベントの入場の許否を判定することが可能な情報処理方法等を提供すること。【解決手段】一つの側面に係る情報処理方法は、イベントに参加するためのチケットＮＦＴをブロックチェーンシステム上に発行し、発行したチケットＮＦＴの保有者の端末装置から送信された、前記保有者のウォレットアドレス及び前記端末装置で発生された乱数を、システムで受信し、前記端末装置で生成された、前記ウォレットアドレス及び前記乱数を含む２次元コードを、前記システムで取得し、受信したウォレットアドレス及び乱数と、取得した２次元コードに含まれるウォレットアドレス及び乱数とに基づいて、前記イベントの入場の許否を判定する処理を実行させることを特徴とする。【選択図】図７

Description

本発明は、情報処理方法、プログラム及び情報処理システムに関する。

近年、施設またはイベント等への入場の許否を判定する技術の開発が盛んに進められている。特許文献１には、ゲート管理装置が備える時計装置から出力される現在時刻データと、認証データに含まれる現在時刻データとを比較して、両現在時刻データの差が事前に規定された基準値以下であり、かつ、イベントの発券記録中にチケットデータが存在している場合に、入場希望者の入場を許可する入場許可認証方法が開示されている。

特開２０２０－０７７０３１号公報

しかしながら、特許文献１に係る発明は、ブロックチェーンシステム上に発行されたチケットＮＦＴにおけるイベントの入場の許否を判定することができないという問題がある。

一つの側面では、チケットＮＦＴにおけるイベントの入場の許否を判定することが可能な情報処理方法等を提供することを目的とする。

一つの側面に係る情報処理方法は、イベントに参加するためのチケットＮＦＴをブロックチェーンシステム上に発行し、発行したチケットＮＦＴの保有者の端末装置から送信された、前記保有者のウォレットアドレス及び前記端末装置で発生された乱数を、システムで受信し、前記端末装置で生成された、前記ウォレットアドレス及び前記乱数を含む２次元コードを、前記システムで取得し、受信したウォレットアドレス及び乱数と、取得した２次元コードに含まれるウォレットアドレス及び乱数とに基づいて、前記イベントの入場の許否を判定する処理を実行させることを特徴とする。

一つの側面では、チケットＮＦＴにおけるイベントの入場の許否を判定することが可能となる。

入場管理システムの概要を示す説明図である。 サーバの構成例を示すブロック図である。 イベントＤＢ及びチケットＤＢのレコードレイアウトの一例を示す説明図である。 保有者ＤＢ及び入場履歴ＤＢのレコードレイアウトの一例を示す説明図である。 ブロックチェーンのノードの構成例を示すブロック図である。 保有者端末及びリーダ端末の構成例を示すブロック図である。 入場管理システムの処理動作を説明する説明図である。 チケットＮＦＴの一覧画面の一例を示す説明図である。 チケットＮＦＴにおける入場用の２次元コードの生成画面の一例を示す説明図である。 チケットＮＦＴを発行する際の処理手順を示すフローチャートである。 ウォレットアドレス及び乱数を記憶する際の処理手順を示すフローチャートである。 イベントの入場の許否を判定する際の処理手順を示すフローチャートである。 イベントの入場の許否を判定する処理のサブルーチンの処理手順を示すフローチャートである。 実施形態２におけるサーバの構成例を示すブロック図である。 販売商品ＤＢ及び購入履歴ＤＢのレコードレイアウトの一例を示す説明図である。 販売商品を購入する際の処理手順を示すフローチャートである。 第１統計情報の表示画面の一例を示す説明図である。 第１統計情報を出力する際の処理手順を示すフローチャートである。 第２統計情報の表示画面の一例を示す説明図である。 第２統計情報を出力する際の処理手順を示すフローチャートである。 チケットＮＦＴの保有者に所定の仮想通貨量を付与する際の処理手順を示すフローチャートである。 ＮＦＴの保有者に特典ＮＦＴを発行する際の処理手順を示すフローチャートである。 チケットＮＦＴの譲渡の場合に入場管理システムの処理動作を説明する説明図である。 チケットＮＦＴを譲渡する際の処理手順を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。

（実施形態１）
実施形態１は、イベントの入場の許否を判定する形態に関する。図１は、入場管理システムの概要を示す説明図である。本実施形態のシステムは、情報処理装置１、ブロックチェーンシステム２、情報処理端末３及び入場リーダ端末４を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。

情報処理装置１は、種々の情報に対する処理、記憶及び送受信を行う情報処理装置である。情報処理装置１は、例えばサーバ装置、パーソナルコンピュータまたは汎用のタブレットＰＣ（パソコン）等である。本実施形態において情報処理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。

ブロックチェーンシステム２は、分散型台帳技術又は分散型ネットワークである。ブロックチェーンシステム２は、コンセンサス処理を実行する複数のノード２１により構成される。ノード２１の各々は、当該コンセンサス処理の実行を通じて、ブロックチェーンデータのコピーを保持する。ブロックチェーンシステム２は、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、鎖のように連結していくことによりデータを保管する。

ブロックチェーンシステム２は、ピアツーピア（Peer to Peer）ネットワークと分散型タイムスタンプサーバの使用により自律的に管理される。鎖状に保存しているため、ブロック内のデータを一度記録した場合、該データを遡及的に変更することが難しい。なお、ブロックチェーンシステム２は、パブリック型、プライベート型、コンソーシアム型のいずれであっても良い。データの単位はブロックではなく個々のトランザクションであっても良い。また、データの保存は鎖状以外にも有向非巡回グラフ等の保存形式であっても良い。以下では簡潔のため、ブロックチェーンシステム２をブロックチェーン２と読み替える。

情報処理端末３は、イベントに参加するためのチケットＮＦＴ（Non-Fungible Token；非代替性トークン）の受信、当該イベントに対する入場用の２次元コードの生成及び表示等を行う端末装置である。情報処理端末３は、例えばスマートフォン、携帯電話、アップルウォッチ（Apple Watch:登録商標）等のウェアラブルデバイス、タブレット、パーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末３を保有者端末３と読み替える。

入場リーダ端末４は、入場用の２次元コードの読取及び送信、並びに、入場の許否の判定結果の受信及び表示等を行う端末装置である。入場リーダ端末４は、例えば１次元コード若しくは２次元コードを読み込むコードリーダ、非接触型ＩＣカードに記憶された情報を読み込むＩＣカードのリーダ、またはリーダ機能を有するスマートフォン、携帯電話、タブレット若しくはパーソナルコンピュータ端末等の情報処理機器である。

なお、入場リーダ端末４は、通信機能を有するＣＣＤ(Charge Coupled Device)カメラ若しくはＣＭＯＳ（Complementary Metal Oxide Semiconductor）カメラ等の撮影装置であっても良い。なお、入場リーダ端末４は、ゲートを備える設置型のコード読取端末であっても良い。ゲートを備える設置型のコード読取端末を利用することにより、入場受付の無人化を実現することが可能となる。

以下では簡潔のため、入場リーダ端末４をリーダ端末４と読み替える。

本実施形態に係るサーバ１は、ブロックチェーン２を通じて、イベントに参加するためのチケットＮＦＴを発行する。なお、チケットＮＦＴに関しては後述する。サーバ１は、発行したチケットＮＦＴを、当該チケットＮＦＴの保有者の保有者端末３に送信する。保有者端末３は、保有者のウォレットアドレスを取得し、乱数を発生する。保有者端末３は、取得した保有者のウォレットアドレス、及び発生した乱数をサーバ１に送信する。サーバ１は、保有者端末３から送信された保有者のウォレットアドレス及び乱数を記憶部に記憶する。

保有者端末３は、チケットＮＦＴの保有者によるイベントへの入場要求を受け付けた場合、保有者のウォレットアドレス及び発生された乱数を含む２次元コードを生成する。保有者端末３は、生成した２次元コードを画面に表示する。リーダ端末４は、保有者端末３上に表示されている２次元コードを読み取る。リーダ端末４は、読み取った２次元コードから保有者のウォレットアドレス及び乱数を取得する。リーダ端末４は、取得した保有者のウォレットアドレス及び乱数をサーバ１に送信する。

サーバ１は、リーダ端末４から送信された保有者のウォレットアドレス及び乱数を受信する。サーバ１は、記憶部に記憶した保有者のウォレットアドレス及び乱数と、受信した保有者のウォレットアドレス及び乱数とに基づいて、チケットＮＦＴの保有者に対してイベントの入場の許否を判定する。

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、入力部１４、表示部１５、読取部１６及び大容量記憶部１７を含む。各構成はバスＢで接続されている。

制御部１１はＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）、または量子プロセッサ等の演算処理装置を含む。制御部１１は、記憶部１２に記憶された制御プログラム１Ｐ（プログラム製品）を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。

なお、制御プログラム１Ｐは、単一のコンピュータ上で、または１つのサイトにおいて配置されるか、もしくは複数のサイトにわたって分散され、通信ネットワークによって相互接続された複数のコンピュータ上で実行されるように展開することができる。なお、図２では制御部１１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。

記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要な制御プログラム１Ｐ又はデータ等を記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部１３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して保有者端末３またはリーダ端末４等との間で情報の送受信を行う。

入力部１４は、マウス、キーボード、タッチパネルまたはボタン等の入力デバイスであり、受け付けた操作情報を制御部１１へ出力する。表示部１５は、液晶ディスプレイ又は有機ＥＬ（electroluminescence）ディスプレイ等であり、制御部１１の指示に従い各種情報を表示する。

読取部１６は、ＣＤ（Compact Disc）－ＲＯＭ又はＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読取部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１７に記憶しても良い。また、ネットワークＮ等を介して他のコンピュータから制御部１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１７に記憶しても良い。さらにまた、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでも良い。

大容量記憶部１７は、例えばＨＤＤ（Hard disk drive:ハードディスク）、ＳＳＤ(Solid State Drive:ソリッドステートドライブ)等の記録媒体を備える。大容量記憶部１７は、イベントＤＢ（データベース：database）１７１、チケットＤＢ１７２、保有者ＤＢ１７３及び入場履歴ＤＢ１７４を含む。

イベントＤＢ１７１は、イベントに関する情報を記憶している。チケットＤＢ１７２は、イベントに参加するためのチケットＮＦＴに関する情報を記憶している。保有者ＤＢ１７３は、チケットＮＦＴを保有する保有者に関する情報を記憶している。入場履歴ＤＢ１７４は、チケットＮＦＴの保有者の入場履歴を記憶している。

なお、本実施形態において記憶部１２及び大容量記憶部１７は一体の記憶装置として構成されていても良い。また、大容量記憶部１７は複数の記憶装置により構成されていても良い。更にまた、大容量記憶部１７はサーバ１に接続された外部記憶装置であっても良い。

サーバ１は、種々の情報処理及び制御処理等をコンピュータ単体で実行しても良いし、複数のコンピュータで分散して実行しても良い。また、サーバ１は、１台のサーバ内に設けられた複数の仮想マシンによって実現されても良いし、クラウドサーバを用いて実現されても良い。

図３は、イベントＤＢ１７１及びチケットＤＢ１７２のレコードレイアウトの一例を示す説明図である。
イベントＤＢ１７１は、イベントＩＤ列、イベント名称列、開催日時列、開催場所列及び画像列を含む。イベントＩＤ列は、各イベントを識別するために、一意に特定されるイベントのＩＤを記憶している。イベント名称列は、イベントの名称を記憶している。開催日時列は、イベントを開催する日時情報を記憶している。開催場所列は、イベントを開催する場所を記憶している。画像列は、イベントを示す画像またはサムネイル画像を記憶している。

チケットＤＢ１７２は、チケットＩＤ列、イベントＩＤ列、チケットＮＦＴ列、保有者ＩＤ列、ウォレットアドレス列、乱数列及びタイムスタンプ列を含む。チケットＩＤ列は、各チケットを識別するために、一意に特定されるチケットのＩＤを記憶している。イベントＩＤ列は、イベントを特定するイベントＩＤを記憶している。

チケットＮＦＴ列は、ブロックチェーン２上で発行されたチケットＮＦＴを記憶している。例えば、ブロックチェーン２上で、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用し、鑑定書等のようにその「真正性」または「価値」を証明することができるチケットＮＦＴを発行しても良い。ＥＲＣ７２１が利用された場合、チケットＮＦＴには、トークン（Token）ＩＤ、所有者アドレス及びトークンＵＲＩ（Uniform Resource Identifier）等が含まれる。

また、チケットＮＦＴの所有者アドレスは、保有者のウォレットアドレスに対応付けられている。保有者が複数のチケットＮＦＴを保有している場合、保有者のウォレットアドレスに基づき、当該ウォレットアドレスに対応付けられた各チケットＮＦＴの所有者アドレスを取得することができる。

例えばチケットＮＦＴ列には、チケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩ等を含むブロックチェーン２でのインデックスが記憶されている。なお、チケットＮＦＴの発行時に、チケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩ等がブロックチェーン２上で記憶される。トークンＵＲＩは、チケットＮＦＴに対するメタデータの場所を示す属性である。メタデータの場所は、例えばメタデータ（画像または動画等）のＵＲＬ（Uniform Resource Locator）等である。なお、メタデータそのものは、例えばＪＳＯＮ（JavaScript Object Notation）形式で外部のデータベース装置に記憶されても良い。

保有者ＩＤ列は、チケットＮＦＴの保有者を特定する保有者ＩＤを記憶している。ウォレットアドレス列は、保有者のウォレットアドレスを記憶している。ウォレットアドレスは、取引ごとに作成された仮想通貨（暗号資産）用の口座番号であり、文字列又はＱＲコード（登録商標）として表示する。ウォレットアドレスは、ブロックチェーン２で利用されている公開鍵暗号を基にして、数学的に導出されたアドレスである。また、ウォレットアドレスはブロックチェーン２に記録され、ブロックチェーン２のシステムが維持し続ける限り改ざんされない。

乱数列は、発生した乱数を記憶している。タイムスタンプ列は、保有者のウォレットアドレス及び乱数を送信した日時を記憶している。

図４は、保有者ＤＢ１７３及び入場履歴ＤＢ１７４のレコードレイアウトの一例を示す説明図である。
保有者ＤＢ１７３は、保有者ＩＤ列、氏名列、年齢列、性別列及びウォレットアドレス列を含む。保有者ＩＤ列は、各保有者を識別するために、一意に特定される保有者のＩＤを記憶している。氏名列は、保有者の氏名を記憶している。年齢列は、保有者の年齢を記憶している。性別列は、保有者の性別を記憶している。ウォレットアドレス列は、保有者のウォレットアドレスを記憶している。

入場履歴ＤＢ１７４は、チケットＩＤ列、イベントＩＤ列、保有者ＩＤ列及び入場日時列を含む。チケットＩＤ列は、チケットを特定するチケットＩＤを記憶している。イベントＩＤ列は、イベントを特定するイベントＩＤを記憶している。保有者ＩＤ列は、保有者を特定する保有者ＩＤを記憶している。入場日時列は、チケットＮＦＴの保有者がイベントに入場した日時情報を記憶している。

なお、上述した各ＤＢの記憶形態は一例であり、データ間の関係が維持されていれば、他の記憶形態であっても良い。

図５は、ブロックチェーン２のノード２１の構成例を示すブロック図である。ブロックチェーン２のノード２１は、制御部２１１、記憶部２１２、通信部２１３、受付部２１４、出力部２１５、ブロック生成部２１６、ブロック検証部２１７及びブロック共有部２１８を含む。各構成はバスＢで接続されている。

制御部２１１は、他ノード２１（端末）の制御部と自律分散的に協調して、常に最新のブロックチェーン（台帳：ブロックチェーンデータのコピー）を記憶部２１２に保持する。記憶部２１２には、分散型のネットワークへブロードキャストされたトランザクションが含まれたブロックチェーン（台帳）、及びブロック内の情報の検証処理に必要となる情報等が記憶される。

通信部２１３は、通信に関する処理を行うための通信モジュールである。受付部２１４は、外部ノードから、ブロックチェーン２である分散型のネットワークに記録する情報を受け付ける。出力部２１５は、外部ノードからの要求に応じて、自身が保持するブロックチェーン２の情報を出力する。

ブロック生成部２１６は、受付部２１４が受け付けた情報を基に、ブロックチェーン２に追加するブロックを生成する。ブロック生成部２１６は、前ブロックに基づく情報と受付部２１４が受け付けた情報とを含むブロックを生成する。

また、ブロック生成部２１６は、自身が生成したブロックまたは後述するブロック共有部２１８を介して他のノード２１が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理または署名を付与する処理を行った上で、自身が管理するブロックチェーン２にブロックを追加する。なお、ブロック生成部２１６が生成したブロックに対して、複数のノード２１が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン２に追加されるブロックとなる。

ブロック検証部２１７は、自身が保持するブロックチェーン２にブロックを追加する際に、該ブロック内の情報の検証を行う。通常、追加対象とされるブロックは、自ノード２１を含むノード２１群において最も早く規則が満たされたブロックであるが、悪意のあるノード２１が含まれていた場合等を考慮して、実際に規則が満たされているか等を検証しても良い。

ブロック共有部２１８は、ブロックチェーン２に属するノード２１間で情報交換を行う。ブロック共有部２１８は、より具体的には、受付部２１４が受け付けた情報、ブロック生成部２１６が生成したブロック、及び他のノード２１から受け付けたブロック等を、適宜他のノード２１に送信する。これにより、可能な限り全てのノード２１でこれらの情報および最新のブロックチェーン２を共有する。

なお、図５の構成はあくまで一例であって、ブロックチェーン２のノード２１は、改ざんが困難なブロックチェーン２を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて分散型のネットワークへの情報追加、及び分散型のネットワークに記録された情報の参照が可能なノードであれば、具体的な構成は問わない。

なお、サーバ１は、ブロックチェーン２のノード２１であっても良い。

図６は、保有者端末３及びリーダ端末４の構成例を示すブロック図である。
保有者端末３は、制御部３１、記憶部３２、通信部３３、入力部３４及び表示部３５を含む。各構成はバスＢで接続されている。

制御部３１はＣＰＵ、ＭＰＵ等の演算処理装置を含み、記憶部３２に記憶された制御プログラム３Ｐ（プログラム製品）を読み出して実行することにより、保有者端末３に係る種々の情報処理、制御処理等を行う。なお、図６では制御部３１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。

記憶部３２はＲＡＭ、ＲＯＭ等のメモリ素子を含み、制御部３１が処理を実行するために必要な制御プログラム３Ｐ又はデータ等を記憶している。また、記憶部３２は、制御部３１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部３３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、サーバ１等と情報の送受信を行う。

入力部３４は、キーボード、マウスまたは表示部３５と一体化したタッチパネルでも良い。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイ等であり、制御部３１の指示に従い各種情報を表示する。

リーダ端末４は、制御部４１、記憶部４２、通信部４３、入力部４４、表示部４５、コード読取部４６及びスピーカ４７を含む。各構成はバスＢで接続されている。なお、リーダ端末４の制御部４１、記憶部４２、通信部４３、入力部４４及び表示部４５に関しては、保有者端末３の制御部３１、記憶部３２、通信部３３、入力部３４及び表示部３５と同様であるため、説明を省略する。コード読取部４６は、バーコードまたは２次元コード等を読み取るための読取専用モジュールである。スピーカ４７は、電気信号を音に変換する装置である。

図７は、入場管理システムの処理動作を説明する説明図である。なお、理解の便宜のために、イベントのチケットの購入段階おける保有者端末３を購入者端末３と読み替える。

チケットを購入する購入者の購入者端末３は、購入者によるチケットの購入要求を受け付けた場合、受け付けた購入要求をサーバ１に送信する。購入要求には、購入者の氏名、年齢、性別、ウォレットアドレスまたはイベントＩＤ等が含まれる。なお、イベントの開催者の端末（図示なし）またはＮＦＴ取引所の端末（図示なし）等を通じて、購入者の購入要求がサーバ１に送信されても良い。

サーバ１は、購入者端末３から送信された購入要求に応じて、ブロックチェーン２を通じて、イベントに参加するためのチケットＮＦＴを発行する。ＮＦＴは、鑑定書または所有証明書付きのデジタルデータであり、仮想通貨と同様にデータ管理にブロックチェーン技術が用いられ、改ざん・偽造ができない仕組みである。チケットＮＦＴは、ブロックチェーン２上で発行され、チケットとＮＦＴとを紐付けることで当該チケットの所有権を持っているという証明である。

例えば、ブロックチェーン２がＥｔｈｅｒｅｕｍである場合、サーバ１は、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用してチケットＮＦＴを発行する。ＥＲＣ７２１規格を用いれば、ブロックチェーン２上の全てのチケットＮＦＴを開示しているが、改ざんすることはできないため、所有者または帰属情報等を付けることが可能となる。発行されたチケットＮＦＴのトークンＩＤ、所有者（チケットＮＦＴの保有者）アドレス及びトークンＵＲＩ等がブロックチェーン２上で記憶される。

なお、チケットＮＦＴを管理者に発行した場合、管理者は保有する当該チケットＮＦＴを対象購入者に譲渡する。この場合、ブロックチェーン２は、チケットＮＦＴのトークンＩＤ及びトークンＵＲＩ（メタデータの場所）を引き継ぐようにする。ブロックチェーン２は、チケットＮＦＴの所有者アドレスを、管理者の所有者アドレスから対象購入者の所有者アドレスに変更する。ブロックチェーン２は、譲渡後のチケットＮＦＴのトークンＩＤ（変更なし）、変更後の所有者アドレス、及びトークンＵＲＩ（変更なし）等を記録する。

また、チケットＮＦＴの所有者は、チケットＮＦＴの売買または移転により、暗号資産と同様にチケットＮＦＴを自由に取引できる。

なお、ＥＲＣ７２１規格の他、ＥＲＣ２０規格、ＥＲＣ１１５５規格、またはソラナ（Solana）等の他のＮＦＴ標準規格に準拠するＮＦＴを利用しても良い。

サーバ１は、チケットを購入した購入者を、当該チケットに対応するチケットＮＦＴの保有者とし、当該保有者（購入者）に関する情報を保有者ＤＢ１７３に記憶する。具体的には、サーバ１は保有者ＩＤを割り振る。サーバ１は、割り振った保有者ＩＤに対応付けて、保有者の氏名、年齢、性別及びウォレットアドレスを一つのレコードとして保有者ＤＢ１７３に記憶する。

サーバ１は、ブロックチェーン２上に発行されたチケットＮＦＴに対してチケットＩＤを割り振る。サーバ１は、割り振ったチケットＩＤに対応付けて、ブロックチェーン２上で発行されたチケットＮＦＴ（トークンＩＤ、所有者アドレスまたはトークンＵＲＩ等）をチケットＤＢ１７２に記憶する。具体的には、サーバ１は、チケットＩＤに対応付けて、イベントＩＤ、チケットＮＦＴ及び保有者ＩＤを一つのレコードとしてチケットＤＢ１７２に記憶する。

サーバ１は保有者ＩＤに基づき、チケットＩＤ及びイベントＩＤに対応付けてブロックチェーン２上に発行されたチケットＮＦＴを、該当する保有者端末３に送信する。保有者端末３は、サーバ１から送信されたチケットＩＤ、イベントＩＤ及びチケットＮＦＴを受信する。保有者端末３は、受信したチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ）を画面に表示する。

保有者端末３は、記憶部３２に記憶された保有者のウォレットアドレスを取得する。保有者端末３は、例えば、既知の疑似乱数発生アルゴリズム、または物理乱数発生装置といった公知の手段を用いて乱数を発生する。なお、保有者端末３は、比較的簡易な数式等を利用して乱数を発生しても良い。なお、乱数の発生タイミングは特に限定されない。例えば、チケット購入時、チケットＮＦＴ発行時、または入場用の２次元コード生成時に乱数を発生しても良い。

保有者端末３は、発生した乱数をチケットＩＤ及びイベントＩＤに対応付けて記憶部３２に記憶する。保有者端末３は、チケットＩＤ及びイベントＩＤに対応付けて、取得した保有者のウォレットアドレス、及び発生した乱数をサーバ１に送信する。

サーバ１は、保有者端末３から送信されたチケットＩＤ、イベントＩＤ、保有者のウォレットアドレス及び乱数を受信する。サーバ１は、受信した保有者のウォレットアドレス及び乱数を、チケットＩＤ及びイベントＩＤに対応付けてチケットＤＢ１７２に記憶する。

保有者端末３は、チケットＮＦＴの保有者によるイベントへの入場要求を受け付けた場合、記憶部３２に記憶された保有者のウォレットアドレス及び乱数を取得する。保有者端末３は、２次元コードの生成ライブラリを利用し、保有者のウォレットアドレス及び乱数を含む２次元コードを生成する。保有者端末３は、生成した２次元コードを画面に表示する。なお、本実施形態では、２次元コードの例を示しているが、バーコード等であっても良い。

イベントへの入場受付の場合、リーダ端末４は、コード読取部４６を介して、保有者端末３上に表示されている２次元コードを読み取る。リーダ端末４は、２次元コードの解析ライブラリを利用し、読み取った２次元コードから保有者のウォレットアドレス及び乱数を取得する。リーダ端末４は、取得した保有者のウォレットアドレス及び乱数をサーバ１に送信する。

サーバ１は、リーダ端末４から送信された保有者のウォレットアドレス及び乱数を受信する。サーバ１は、受信した保有者のウォレットアドレス及び乱数に基づき、チケットＤＢ１７２に記憶されたチケットデータから、一致する保有者のウォレットアドレス及び乱数が存在しているか否かを判定する。

サーバ１は、一致する保有者のウォレットアドレス及び乱数が存在していると判定した場合、チケットＮＦＴの保有者の入場履歴を入場履歴ＤＢ１７４に記憶する。サーバ１は、保有者のイベントの入場許可の旨をリーダ端末４に送信する。リーダ端末４は、サーバ１から送信された入場許可の旨を受信して画面に表示する。

サーバ１は、一致する保有者のウォレットアドレス及び乱数が存在していないと判定した場合、保有者のイベントの入場拒否の旨をリーダ端末４に送信する。リーダ端末４は、サーバ１から送信された入場拒否の旨を受信して画面に表示する。

更に、上述したイベントの入場許否の判定処理の他、例えばサーバ１は、リーダ端末４から送信された保有者のウォレットアドレスに基づき、ブロックチェーン２を通じて入場許否の判定処理を行っても良い。

具体的には、サーバ１は、保有者のウォレットアドレスをブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、サーバ１から送信された保有者のウォレットアドレスに基づき、記憶部２１２に記憶された単一または複数のチケットＮＦＴを取得する。チケットＮＦＴには、トークンＩＤ、所有者アドレス及びトークンＵＲＩ等が含まれる。ノード２１は、取得したチケットＮＦＴをサーバ１に送信する。

サーバ１は、ノード２１から送信されたチケットＮＦＴのトークンＩＤ及び所有者アドレスを、チケットＤＢ１７２に記憶されたチケットＮＦＴのデータに照合する。サーバ１は、ノード２１から送信されたチケットＮＦＴのトークンＩＤ及び所有者アドレスと一致するチケットＮＦＴのトークンＩＤ及び所有者アドレスが存在していると判定した場合、保有者のイベントの入場許可の旨をリーダ端末４に送信する。サーバ１は、一致するチケットＮＦＴのトークンＩＤ及び所有者アドレスが存在していないと判定した場合、保有者のイベントの入場拒否の旨をリーダ端末４に送信する。

なお、サーバ１は、保有者のウォレットアドレスに基づき、ブロックチェーン２のノード２１からチケットＮＦＴを取得できない場合、保有者のイベントの入場拒否の旨をリーダ端末４に送信する。

図８は、チケットＮＦＴの一覧画面の一例を示す説明図である。当該画面は、チケットＮＦＴ表示欄１０ａ及び表示ボタン１０ｂを含む。チケットＮＦＴ表示欄１０ａは、チケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩ等を表示する表示欄である。表示ボタン１０ｂは、チケットＮＦＴにおける入場用の２次元コードの生成画面（図９）に遷移するボタンである。

保有者端末３は、保有者のウォレットアドレス（暗号ウォレット）により、当該保有者が所有しているすべてのチケットＮＦＴをブロックチェーン２のノード２１から取得する。なお、保有者端末３は、保有者のウォレットアドレスにより、当該保有者が所有しているすべてのチケットＮＦＴをサーバ１から取得しても良い。取得されたチケットＮＦＴには、トークンＩＤ、所有者アドレス及びトークンＵＲＩ（メタデータの場所）等が含まれる。

トークンＵＲＩは、例えば、イベントと関連する動画もしくは画像等のコンテンツ配信・閲覧、イベントに関する販売商品、または特別グッズ（例えば、書籍、雑誌またはギフトカード）等のＵＲＬであっても良い。

保有者端末３は、当該チケットＮＦＴに対応するイベントＩＤに基づき、イベント画像をサーバ１のイベントＤＢ１７１から取得する。保有者端末３は、取得した各チケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩ、並びに、イベント画像を該当するチケットＮＦＴ表示欄１０ａに表示する。

保有者端末３は、表示ボタン１０ｂのタッチ操作を受け付けた場合、該当するチケットＮＦＴのトークンＩＤ、所有者アドレス、トークンＵＲＩ及びイベント画像を取得する。保有者端末３は、取得したトークンＩＤ、所有者アドレス、トークンＵＲＩ及びイベント画像を、チケットＮＦＴにおける入場用の２次元コードの生成画面（図９）に受け渡し、当該入場用の２次元コードの生成画面に遷移する。

図９は、チケットＮＦＴにおける入場用の２次元コードの生成画面の一例を示す説明図である。生成画面は、イベント情報表示欄１１ａ、チケットＮＦＴ表示欄１１ｂ、入場受付ボタン１１ｃ及び２次元コード表示欄１１ｄを含む。

イベント情報表示欄１１ａは、イベントに関する情報を表示する表示欄である。チケットＮＦＴ表示欄１１ｂは、チケットＮＦＴの保有者が保有するチケットＮＦＴを表示する表示欄である。入場受付ボタン１１ｃは、イベントへの入場を受け付けるボタンである。２次元コード表示欄１１ｄは、入場用の２次元コードを表示する表示欄である。なお、図９では、ＱＲコードの例を説明するが、他の種類の２次元コードにも同様に適用することができる。

保有者端末３は、チケットＮＦＴの一覧画面（図８）から受け渡されたチケットのトークンＩＤ、所有者アドレス、トークンＵＲＩ及びイベント画像をチケットＮＦＴ表示欄１１ｂに表示する。保有者端末３は、当該チケットＮＦＴに対応するイベントＩＤに基づき、イベントの名称、開催日時及び開催場所を含むイベント情報をサーバ１のイベントＤＢ１７１から取得する。保有者端末３は、取得したイベント情報をイベント情報表示欄１１ａに表示する。

図示のように、イベントの名称、開催日時及び開催場所がイベント情報表示欄１１ａに表示される。チケットＮＦＴのトークンＩＤ、所有者アドレス、トークンＵＲＩ及びイベント画像がチケットＮＦＴ表示欄１１ｂに表示される。なお、チケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩは非表示でも良い。

トークンＵＲＩは、例えばチケットＮＦＴに付与した特典（例えば、画像または動画）を示す特典ページのＵＲＬである。保有者端末３は、トークンＵＲＩのタッチ操作を受け付けた場合、特典ページのＵＲＬで指定されるサイトに掲載されている画像または動画を表示する。

保有者端末３は、入場受付ボタン１１ｃのタッチ（クリック）操作を受け付けた場合、入場用の２次元コードを生成する。具体的には、保有者端末３は、保有者のウォレットアドレスを記憶部３２から取得する。保有者端末３は、チケットＩＤ及びイベントＩＤに対応付けられた、サーバ１に送信済みの乱数を記憶部３２から取得する。保有者端末３は、２次元コードの生成ライブラリを利用し、取得した保有者のウォレットアドレス及び乱数を含む２次元コードを生成する。保有者端末３は、生成した２次元コードを２次元コード表示欄１１ｄに表示する。

図１０は、チケットＮＦＴを発行する際の処理手順を示すフローチャートである。保有者端末３（購入者端末３）の制御部３１は、購入者によるチケットの購入要求を入力部３４により受け付ける（ステップＳ３０１）。購入要求には、購入者の氏名、年齢、性別、ウォレットアドレスまたはイベントＩＤ等が含まれる。制御部３１は、受け付けた購入要求を通信部３３によりサーバ１に送信する（ステップＳ３０２）。

サーバ１の制御部１１は、保有者端末３から送信された購入要求を通信部１３により受信する（ステップＳ１０１）。制御部１１は、チケットＮＦＴの生成要求を通信部１３によりブロックチェーン２のいずれかのノード２１に送信する（ステップＳ１０２）。ブロックチェーン２のノード２１の制御部２１１は、通信部２１３を介して、サーバ１から送信されたチケットＮＦＴの生成要求を受信する（ステップＳ２０１）。

ノード２１の制御部２１１は、受信したチケットＮＦＴの生成要求に応じて、例えばＥＲＣ７２１を利用し、チケットＮＦＴを生成する（Ｓ２０２）。制御部２１１は、生成したチケットＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩを記憶部２１２に記憶する（ステップＳ２０３）。制御部２１１は、生成したチケットＮＦＴを通信部２１３によりサーバ１に送信する（ステップＳ２０４）。

サーバ１の制御部１１は、ブロックチェーン２のノード２１から送信されたチケットＮＦＴを通信部１３により受信する（ステップＳ１０３）。制御部１１は、保有者情報及びチケットＮＦＴを大容量記憶部１７に記憶する（ステップＳ１０４）。

具体的には、制御部１１は保有者ＩＤを割り振る。制御部１１は、割り振った保有者ＩＤに対応付けて、保有者の氏名、年齢、性別及びウォレットアドレスを一つのレコードとして保有者ＤＢ１７３に記憶する。制御部１１は、ブロックチェーン２上に発行されたチケットＮＦＴに対してチケットＩＤを割り振る。制御部１１は、割り振ったチケットＩＤに対応付けて、イベントＩＤ、チケットＮＦＴ（トークンＩＤ、所有者アドレスまたはトークンＵＲＩ等）及び保有者ＩＤを一つのレコードとしてチケットＤＢ１７２に記憶する。

制御部１１は保有者ＩＤに基づき、ブロックチェーン２上に発行されたチケットＮＦＴを通信部１３により保有者端末３に送信する（ステップＳ１０５）。保有者端末３の制御部３１は、サーバ１から送信されたチケットＮＦＴを通信部３３により受信する（ステップＳ３０３）。制御部３１は、受信したチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）を表示部３５により表示し（ステップＳ３０４）、処理を終了する。

図１１は、ウォレットアドレス及び乱数を記憶する際の処理手順を示すフローチャートである。保有者端末３の制御部３１は、記憶部３２に記憶された保有者のウォレットアドレスを取得する（ステップＳ３１１）。制御部３１は、例えば疑似乱数発生アルゴリズムを用いて乱数を発生する（ステップＳ３１２）。制御部３１は、発生した乱数をチケットＩＤ及びイベントＩＤに対応付けて記憶部３２に記憶する（ステップＳ３１３）。制御部３１は、チケットＩＤ、イベントＩＤ、取得した保有者のウォレットアドレス、及び発生した乱数を通信部３３によりサーバ１に送信する（ステップＳ３１３）。

サーバ１の制御部１１は、保有者端末３から送信されたチケットＩＤ、イベントＩＤ、保有者のウォレットアドレス及び乱数を通信部１３により受信する（ステップＳ１１１）。制御部１１は、受信した保有者のウォレットアドレス及び乱数を、チケットＩＤ及びイベントＩＤに対応付けて大容量記憶部１７のチケットＤＢ１７２に記憶し（ステップＳ１１２）、処理を終了する。

図１２は、イベントの入場の許否を判定する際の処理手順を示すフローチャートである。保有者端末３の制御部３１は、通信部３３を介して、保有者のウォレットアドレスにより、当該保有者が所有しているすべてのチケットＮＦＴをブロックチェーン２のノード２１から取得する（ステップＳ３２１）。各チケットＮＦＴには、トークンＩＤ、所有者アドレス及びトークンＵＲＩ等が含まれる。

制御部３１は、表示部３５を介して、取得した各チケットＮＦＴを一覧表示する（ステップＳ３２２）。制御部３１は、複数のチケットＮＦＴから、チケットＮＦＴの保有者による対象チケットＮＦＴの選択を入力部３４により受け付ける（ステップＳ３２３）。制御部３１は、チケットＮＦＴの保有者によるイベントの入場要求を入力部３４により受け付ける（ステップＳ３２４）。

制御部３１は、記憶部３２に記憶された保有者のウォレットアドレスを取得する（ステップＳ３２５）。制御部３１は、チケットＩＤ及びイベントＩＤに対応付けられた乱数を記憶部３２から取得する（ステップＳ３２６）。制御部３１は、２次元コードの生成ライブラリを利用し、取得した保有者のウォレットアドレス及び乱数を含む２次元コードを生成する（ステップＳ３２７）。制御部３１は、生成した２次元コードを表示部３５により表示する（ステップＳ３２８）。

リーダ端末４の制御部４１は、コード読取部４６を介して、保有者端末３上に表示されている２次元コードを読み取る（ステップＳ４２１）。制御部４１は、２次元コードの解析ライブラリを利用し、読み取った２次元コードから保有者のウォレットアドレス及び乱数を取得する（ステップＳ４２２）。制御部４１は、イベントを特定するイベントＩＤと、取得した保有者のウォレットアドレス及び乱数とを通信部４３によりサーバ１に送信する（ステップＳ４２３）。

サーバ１の制御部１１は、リーダ端末４から送信されたイベントＩＤ、保有者のウォレットアドレス及び乱数を通信部１３により受信する（ステップＳ１２１）。制御部１１は、受信したイベントＩＤ、保有者のウォレットアドレス及び乱数に基づき、チケットＮＦＴの保有者に対してイベントの入場の許否を判定する処理のサブルーチンを実行する（ステップＳ１２２）。なお、イベントの入場許否判定処理のサブルーチンに関しては後述する。

制御部１１は、入場許否判定処理のサブルーチンから得られた判定結果を通信部１３によりリーダ端末４に送信する（ステップＳ１２３）。リーダ端末４の制御部４１は、サーバ１から送信された判定結果を通信部４３により受信する（ステップＳ４２４）。制御部４１は、受信した判定結果を表示部４５により表示し（ステップＳ４２５）、処理を終了する。

具体的には、制御部４１は判定結果に基づき、保有者に対してイベントの入場を許可したと判定した場合、入場許可の旨を表示部４５により表示する。制御部４１は判定結果に基づき、保有者に対してイベントの入場を拒否したと判定した場合、入場拒否の旨を表示部４５により表示する。

また、判定結果に基づいて効果音を出力することができる。例えば制御部４１は、保有者に対してイベントの入場を許可した場合、入場許可を示す効果音をスピーカ４７から出力する。または、制御部４１は、保有者に対してイベントの入場を拒否した場合、入場拒否を示す効果音をスピーカ４７から出力する。

図１３は、イベントの入場の許否を判定する処理のサブルーチンの処理手順を示すフローチャートである。サーバ１の制御部１１は、ステップＳ１２１で受信したイベントＩＤ、ウォレットアドレス及び乱数を取得する（ステップＳ０１）。制御部１１は、取得したイベントＩＤ、ウォレットアドレス及び乱数に基づき、チケットＤＢ１７２に記憶されたチケットデータに照合する（ステップＳ０２）。

制御部１１は、照合結果に基づき、受信したウォレットアドレス及び乱数と一致する保有者のウォレットアドレス及び乱数が存在しているか否かを判定する（ステップＳ０３）。制御部１１は、一致する保有者のウォレットアドレス及び乱数が存在していると判定した場合（ステップＳ０３でＹＥＳ）、イベントへの入場許可と判定する（ステップＳ０４）。

制御部１１は、チケットＮＦＴの保有者の入場履歴を大容量記憶部１７の入場履歴ＤＢ１７４に記憶する（ステップＳ０５）。具体的には、制御部１１は、チケットＩＤに対応付けて、イベントＩＤ、保有者ＩＤ及び入場日時を一つのレコードとして入場履歴ＤＢ１７４に記憶する。制御部１１は、入場許否判定処理のサブルーチンを終了してリターンする。

制御部１１は、一致する保有者のウォレットアドレス及び乱数が存在していないと判定した場合（ステップＳ０３でＮＯ）、イベントへの入場拒否と判定する（ステップＳ０６）。制御部１１は、入場許否判定処理のサブルーチンを終了してリターンする。

本実施形態によると、イベントに参加するためのチケットＮＦＴをブロックチェーン２上に発行することが可能となる。

本実施形態によると、ウォレットアドレス及び乱数を含む２次元コードを読み取ることにより、イベントの入場の許否を判定することが可能となる。

＜変形例１＞
ウォレットアドレス、乱数及びタイムスタンプを含む２次元コードを読み取ることにより、イベントの入場の許否を判定する処理を説明する。

保有者端末３は、保有者のウォレットアドレスを記憶部３２から取得する。保有者端末３は、例えば疑似乱数発生アルゴリズムを用いて乱数を発生する。保有者端末３は、チケットＩＤ及びイベントＩＤに対応付けて、取得した保有者のウォレットアドレス、発生した乱数、並びに、ウォレットアドレス及び乱数の送信日時であるタイムスタンプをサーバ１に送信する。保有者端末３は、乱数及びタイムスタンプを記憶部３２に記憶する。なお、タイムスタンプは、ウォレットアドレス及び乱数の送信日時に限らず、例えば、チケットの購入日時、チケットＮＦＴの発行日時、または乱数を発生した日時等であっても良い。

サーバ１は、保有者端末３から送信されたチケットＩＤ、イベントＩＤ、保有者のウォレットアドレス、乱数及びタイムスタンプを受信する。サーバ１は、受信した保有者のウォレットアドレス、乱数及びタイムスタンプを、チケットＩＤ及びイベントＩＤに対応付けてチケットＤＢ１７２に記憶する。

保有者端末３は、チケットＮＦＴの保有者によるイベントへの入場要求を受け付けた場合、記憶部３２に記憶された保有者のウォレットアドレス、乱数及びタイムスタンプを取得する。保有者端末３は、２次元コードの生成ライブラリを利用し、保有者のウォレットアドレス、乱数及びタイムスタンプを含む２次元コードを生成する。保有者端末３は、生成した２次元コードを画面に表示する。

イベントへの入場受付の場合、リーダ端末４は、コード読取部４６を介して、保有者端末３上に表示されている２次元コードを読み取る。リーダ端末４は、２次元コードの解析ライブラリを利用し、読み取った２次元コードから保有者のウォレットアドレス、乱数及びタイムスタンプを取得する。リーダ端末４は、取得した保有者のウォレットアドレス、乱数及びタイムスタンプをサーバ１に送信する。

サーバ１は、リーダ端末４から送信された保有者のウォレットアドレス、乱数及びタイムスタンプを受信する。サーバ１は、受信した保有者のウォレットアドレス、乱数及びタイムスタンプに基づき、チケットＤＢ１７２に記憶されたチケットデータから、一致する保有者のウォレットアドレス、乱数及びタイムスタンプが存在しているか否かを判定する。

サーバ１は、一致する保有者のウォレットアドレス、乱数及びタイムスタンプが存在していると判定した場合、保有者のイベントの入場許可の旨をリーダ端末４に送信する。リーダ端末４は、サーバ１から送信された入場許可の旨を受信して画面に表示する。サーバ１は、一致する保有者のウォレットアドレス、乱数及びタイムスタンプが存在していないと判定した場合、保有者のイベントの入場拒否の旨をリーダ端末４に送信する。リーダ端末４は、サーバ１から送信された入場拒否の旨を受信して画面に表示する。

なお、チケットＮＦＴの発行処理、入場許否判定用のデータ（ウォレットアドレス、乱数及びタイムスタンプ）の記憶処理、及びイベントへの入場許否判定処理の手順を示すフローチャートに関しては、図１０～図１２の処理手順を示すフローチャートと同様であるため、説明を省略する。

本変形例によると、ウォレットアドレス、乱数及びタイムスタンプを含む２次元コードを読み取ることにより、イベントの入場の許否を判定することが可能となる。

本変形例によると、タイムスタンプに基づく入場許否の判定処理によって、記憶されたタイムスタンプに時間的な差分が生じた場合に異なるチケットＮＦＴであると判定できるため、信頼性を高めることが可能となる。

（実施形態２）
実施形態２は、チケットＮＦＴの保有者に、当該チケットＮＦＴに対応するイベントに関連する販売商品の購入を許可する形態に関する。なお、実施形態１と重複する内容については説明を省略する。

所定のチケットＮＦＴの保有者に対し、イベントに関連する販売商品を提供することができる。所定のチケットＮＦＴは、特定されたイベント（例えば、コンサートＡ）に対応するチケットＮＦＴであっても良く、または、複数のイベント（例えば、イベントＡ１～Ａ３）に対し、いずれかのイベントに対応するチケットＮＦＴであっても良い。更にまた、所定のチケットＮＦＴは、あらゆるチケットＮＦＴであっても良い。例えば、コンサートＡのチケットＮＦＴの保有者は、当該コンサートＡのグッズを購入することができる。コンサートＡのグッズは、例えば、公演記念カレンダー、公演記念パンフレット、キーホルダーまたは会場で応援用のライト等を含む。

図１４は、実施形態２におけるサーバ１の構成例を示すブロック図である。なお、図２と重複する内容については同一の符号を付して説明を省略する。大容量記憶部１７には、販売商品ＤＢ１７５及び購入履歴ＤＢ１７６が含まれる。販売商品ＤＢ１７５は、イベントに関連する販売商品の情報を記憶している。購入履歴ＤＢ１７６は、販売商品の購入履歴を記憶している。

図１５は、販売商品ＤＢ１７５及び購入履歴ＤＢ１７６のレコードレイアウトの一例を示す説明図である。
販売商品ＤＢ１７５は、商品ＩＤ列、イベントＩＤ列、商品名列、商品画像列、チケットＮＦＴ限定列及び価格列を含む。商品ＩＤ列は、各販売商品を識別するために、一意に特定される販売商品のＩＤを記憶している。イベントＩＤ列は、販売商品に対応するイベントを特定するイベントＩＤを記憶している。商品名列は、販売商品の名称を記憶している。商品画像列は、販売商品の画像またはサムネイル画像を記憶している。

チケットＮＦＴ限定列は、チケットＮＦＴの保有者に対する限定商品であるか否かを示す情報を記憶している。例えば、チケットＮＦＴの保有者に対する限定商品である場合、チケットＮＦＴ限定列には「○」が記憶される。または、チケットＮＦＴの保有者に対する限定商品でない場合、チケットＮＦＴ限定列には「×」が記憶される。価格列は、販売商品の価格を記憶している。

購入履歴ＤＢ１７６は、履歴ＩＤ列、商品ＩＤ列、購入者ＩＤ列、数量列、金額列及び購入日時列を含む。履歴ＩＤ列は、各履歴データを識別するために、一意に特定される履歴データのＩＤを記憶している。商品ＩＤ列は、販売商品を特定する商品ＩＤを記憶している。

購入者ＩＤ列は、販売商品を購入した購入者を特定する購入者ＩＤを記憶している。なお、ＮＦＴの保有者が販売商品を購入した場合、購入者ＩＤ列には保有者ＩＤが記憶される。数量列は、販売商品の購入数量を記憶している。金額列は、販売商品の購入金額を記憶している。購入日時列は、販売商品を購入した日時情報を記憶している。

図１６は、販売商品を購入する際の処理手順を示すフローチャートである。保有者端末３の制御部３１は、通信部３３を介して、販売商品に関する情報をサーバ１の販売商品ＤＢ１７５から取得する（ステップＳ３３１）。販売商品に関する情報は、商品ＩＤ、商品名、商品画像、チケットＮＦＴ限定情報及び価格を含む。制御部３１は、取得した販売商品に関する情報を表示部３５により表示する（ステップＳ３３２）。

制御部３１は、保有者による対象販売商品の購入要求を入力部３４により受け付ける（ステップＳ３３３）。制御部３１は、受け付けた購入要求に応じて、保有者ＩＤ及び購入情報を通信部３３によりサーバ１に送信する（ステップＳ３３４）。購入情報は、販売商品ＩＤ、購入数量、購入金額または支払情報等を含む。サーバ１の制御部１１は、保有者端末３から送信された保有者ＩＤ及び購入情報を通信部１３により受信する（ステップＳ１３１）。

制御部１１は、受信した購入情報に基づき、当該販売商品がチケットＮＦＴ限定商品であるか否かを判定する（ステップＳ１３２）。例えば制御部１１は、受信した購入情報に含まれる販売商品ＩＤに基づき、チケットＮＦＴの保有者に対する限定商品であるか否かを示す情報を大容量記憶部１７の販売商品ＤＢ１７５のチケットＮＦＴ限定列から取得する。例えば制御部１１は、チケットＮＦＴ限定列から「○」を取得した場合、当該販売商品がチケットＮＦＴ限定商品であると判定する。または、制御部１１は、チケットＮＦＴ限定列から「×」を取得した場合、当該販売商品がチケットＮＦＴ限定商品でないと判定する。

制御部１１は、当該販売商品がチケットＮＦＴ限定商品でないと判定した場合（ステップＳ１３２でＮＯ）、後述するステップＳ１３６の処理に遷移する。制御部１１は、当該販売商品がチケットＮＦＴ限定商品であると判定した場合（ステップＳ１３２でＹＥＳ）、所定のチケットＮＦＴを特定する（ステップＳ１３３）。具体的には、制御部１１は、商品ＩＤに基づき、対象となる販売商品に対応するイベントＩＤを大容量記憶部１７の販売商品ＤＢ１７５から取得する。制御部１１は、取得したイベントＩＤに基づき、該当するイベントに対応するチケットＮＦＴを特定する。

制御部１１は、特定したチケットＮＦＴを、保有者が所有しているか否かを判定する（ステップＳ１３４）。具体的には、制御部１１は商品ＩＤに基づき、当該販売商品に対応するイベントＩＤを販売商品ＤＢ１７５から取得する。制御部１１は、保有者ＩＤ及びイベントＩＤに基づき、チケットＮＦＴを大容量記憶部１７のチケットＤＢ１７２から取得できるか否かを判定する。例えば、制御部１１は、チケットＮＦＴをチケットＤＢ１７２から取得できない場合、保有者がチケットＮＦＴを所有していないと判定する。制御部１１は、チケットＮＦＴをチケットＤＢ１７２から取得できた場合、保有者がチケットＮＦＴを所有していると判定する。

更に、上述したチケットＮＦＴの所有判定処理の他、例えばサーバ１は、保有者のウォレットアドレスに基づき、ブロックチェーン２を通じてチケットＮＦＴの所有判定処理を行っても良い。

具体的には、制御部１１は、保有者ＩＤに基づき、保有者のウォレットアドレスを大容量記憶部１７の保有者ＤＢ１７３から取得する。制御部１１は、取得した保有者のウォレットアドレスを通信部１３によりブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、サーバ１から送信された保有者のウォレットアドレスに基づき、記憶部２１２に記憶された単一または複数のチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）を取得する。ノード２１は、取得したチケットＮＦＴをサーバ１に送信する。

サーバ１の制御部１１は、ノード２１から送信されたチケットＮＦＴのトークンＩＤ及び所有者アドレスを、チケットＤＢ１７２に記憶されたチケットＮＦＴのデータに照合する。制御部１１は、ノード２１から送信されたチケットＮＦＴのトークンＩＤ及び所有者アドレスと一致するチケットＮＦＴのトークンＩＤ及び所有者アドレスが存在していると判定した場合、保有者がチケットＮＦＴを所有していると判定する。制御部１１は、一致するチケットＮＦＴのトークンＩＤ及び所有者アドレスが存在していないと判定した場合、保有者がチケットＮＦＴを所有していないと判定する。

なお、制御部１１は、保有者のウォレットアドレスに基づき、ブロックチェーン２のノード２１からチケットＮＦＴを取得できない場合、保有者がチケットＮＦＴを所有していないと判定する。

制御部１１は、保有者が当該チケットＮＦＴを所有していないと判定した場合（ステップＳ１３４でＮＯ）、当該販売商品における購入不可の旨を含むメッセージを通信部１３により保有者端末３に送信する（ステップＳ１３５）。保有者端末３の制御部３１は、サーバ１から送信された購入不可メッセージを通信部３３により受信する（ステップＳ３３５）。保有者端末３の制御部３１は、受信した購入不可メッセージを表示部３５により表示する（ステップＳ３３６）。

制御部１１は、保有者が当該チケットＮＦＴを所有していると判定した場合（ステップＳ１３４でＹＥＳ）、保有者に対して当該販売商品の購入を許可する（ステップＳ１３６）。制御部１１は購入情報に基づき、例えば決済用システムまたはプラットフォームを通じて、当該販売商品に対して決済処理を行う（ステップＳ１３７）。

制御部１１は、購入履歴を大容量記憶部１７の購入履歴ＤＢ１７６に記憶する（ステップＳ１３８）。具体的には、制御部１１は履歴ＩＤを割り振り、割り振った履歴ＩＤに対応付けて、商品ＩＤ、保有者ＩＤ（購入者ＩＤ）、購入数量、購入金額及び購入日時を一つのレコードとして購入履歴ＤＢ１７６に記憶する。

制御部１１は、決済完了の旨を含むメッセージを通信部１３により保有者端末３に送信する（ステップＳ１３９）。保有者端末３の制御部３１は、サーバ１から送信された決済完了メッセージを通信部３３により受信する（ステップＳ３３７）。保有者端末３の制御部３１は、受信した決済完了メッセージを表示部３５により表示し（ステップＳ３３８）、処理を終了する。

続いて、販売商品の第１統計情報を出力する処理を説明する。サーバ１は、販売商品の購入回数または購入数量等を含む第１統計情報を生成する。サーバ１は、グラフまたは表等の容易に理解できる形式で、生成した第１統計情報を出力する。

図１７は、第１統計情報の表示画面の一例を示す説明図である。当該画面は、商品選択欄１２ａ、統計ボタン１２ｂ及び統計情報表示欄１２ｃを含む。商品選択欄１２ａは、統計対象となる販売商品の選択を受け付ける欄である。統計ボタン１２ｂは、選択された販売商品の第１統計情報を生成するボタンである。統計情報表示欄１２ｃは、第１統計情報を表示する表示欄である。

サーバ１は、商品ＩＤ及び商品名を含む販売商品の情報を販売商品ＤＢ１７５から取得する。サーバ１は、取得した販売商品の情報を、例えば管理者端末５（図示なし）に送信する。管理者端末５は、サーバ１から送信された販売商品の情報を受信して画面に表示する。図示のように、販売商品の商品名が商品選択欄１２ａに表示される。

管理者端末５は、管理者による商品選択欄１２ａの選択操作を受け付けた場合、選択された販売商品の商品ＩＤを取得する。管理者端末５は、統計ボタン１２ｂのタッチ操作を受け付けた場合、取得した商品ＩＤをサーバ１に送信する。サーバ１は、管理者端末５から送信された商品ＩＤを受信する。サーバ１は、受信した商品ＩＤ毎に販売商品の購入回数及び購入数量を購入履歴ＤＢ１７６から集計する。

サーバ１は、集計した集計結果に基づき、販売商品の購入回数及び購入数量等を含む第１統計情報のグラフを生成する。サーバ１は、生成したグラフを管理者端末５に送信する。管理者端末５は、サーバ１から送信されたグラフを受信して統計情報表示欄１２ｃに表示する。

図示のように、統計対象となる販売商品（商品Ａ、商品Ｂ及び商品Ｃ）ごとに、購入回数及び購入数量を統計した縦棒グラフが統計情報表示欄１２ｃに表示される。なお、図１７では縦棒グラフの形式としたが、これに限らず、その他のグラフ（例えば、円グラフ）または表の形式で表示するようにもかまわない。

図１８は、第１統計情報を出力する際の処理手順を示すフローチャートである。管理者端末５は、統計対象となる販売商品の第１統計情報の出力要求を受け付ける（ステップＳ５４１）。管理者端末５は、受け付けた第１統計情報の出力要求に応じて、統計対象となる販売商品の商品ＩＤをサーバ１に送信する（ステップＳ５４２）。サーバ１の制御部１１は、管理者端末５から送信された商品ＩＤを通信部１３により受信する（ステップＳ１４１）。

制御部１１は、受信した商品ＩＤ毎に販売商品の購入回数及び購入数量を大容量記憶部１７の購入履歴ＤＢ１７６から集計する（ステップＳ１４２）。制御部１１は、集計した集計結果に基づき、販売商品の購入回数及び購入数量等を含む第１統計情報のグラフを生成する（ステップＳ１４３）。制御部１１は、生成した第１統計情報のグラフを通信部１３により管理者端末５に送信する（ステップＳ１４４）。

管理者端末５は、サーバ１から送信された第１統計情報のグラフを受信し（ステップＳ５４３）、受信した第１統計情報のグラフを画面に表示し（ステップＳ５４４）、処理を終了する。なお、サーバ１は、集計結果のみを管理者端末５に送信しても良い。この場合、管理者端末５は、サーバ１から送信された集計結果に基づいて第１統計情報のグラフを生成する。

続いて、チケットＮＦＴの保有者のイベントの参加回数、または、保有者の属性を含む第２統計情報を出力する処理を説明する。保有者の属性は、保有者の年齢、性別または職種等を含む。

図１９は、第２統計情報の表示画面の一例を示す説明図である。当該画面は、第１グラフ表示欄１３ａ及び第２グラフ表示欄１３ｂを含む。第１グラフ表示欄１３ａは、保有者ごとのイベントの参加回数を統計した統計情報のグラフを表示するための表示欄である。第２グラフ表示欄１３ｂは、イベント（例えば、イベントＡ）における保有者の年齢及び性別ごとの参加者数を統計した統計情報のグラフを表示するための表示欄である。

先ず、サーバ１は、保有者ＩＤごとのイベントの参加回数を入場履歴ＤＢ１７４から集計する。サーバ１は、集計した集計結果に基づいて第１グラフを生成する。

次に、サーバ１は、イベントＩＤに基づき、該当するイベントに参加した各保有者の保有者ＩＤを入場履歴ＤＢ１７４から取得する。サーバ１は、取得した各保有者ＩＤに基づき、各保有者の年齢及び性別を保有者ＤＢ１７３から取得する。サーバ１は、取得した保有者の年齢及び性別ごとの当該イベントの参加者数を集計する。サーバ１は、集計した集計結果に基づいて第２グラフを生成する。

そして、サーバ１は、生成した第１グラフ及び第２グラフを、例えば管理者端末５に送信する。管理者端末５は、サーバ１から送信された第１グラフ及び第２グラフを受信する。管理者端末５は、受信した第１グラフを第１グラフ表示欄１３ａに表示し、受信した第２グラフを第２グラフ表示欄１３ｂに表示する。

図示のように、第１グラフには、保有者（例えば、保有者Ａ氏、保有者Ｂ氏及び保有者Ｃ氏）ごとに統計したイベントの参加回数が示されている。第２グラフには、イベント（例えば、イベントＡ）における保有者の年齢及び性別ごとに統計した参加者数が示されている。

図２０は、第２統計情報を出力する際の処理手順を示すフローチャートである。なお、図２０では、保有者の属性（年齢及び性別等）を含む第２統計情報の生成処理の例を説明するが、他の種類の第２統計情報にも同様に適用することができる。

管理者端末５は、イベントＩＤを含む第２統計情報の出力要求を受け付ける（ステップＳ５５１）。管理者端末５は、受け付けた第２統計情報の出力要求に応じて、当該イベントＩＤをサーバ１に送信する（ステップＳ５５２）。サーバ１の制御部１１は、管理者端末５から送信されたイベントＩＤを通信部１３により受信する（ステップＳ１５１）。

制御部１１は、受信したイベントＩＤに基づき、該当するイベントに参加した各保有者の保有者ＩＤを大容量記憶部１７の入場履歴ＤＢ１７４から取得する（ステップＳ１５２）。制御部１１は、取得した各保有者ＩＤに基づき、各保有者の年齢及び性別を大容量記憶部１７の保有者ＤＢ１７３から取得する（ステップＳ１５３）。制御部１１は、取得した保有者の年齢及び性別ごとの当該イベントの参加者数を集計する（ステップＳ１５４）。

制御部１１は、集計した集計結果に基づき、保有者の年齢及び性別ごとに集計した当該イベントの参加者数を含む第２統計情報のグラフを生成する（ステップＳ１５５）。制御部１１は、生成した第２統計情報のグラフを通信部１３により管理者端末５に送信する（ステップＳ１５６）。管理者端末５は、サーバ１から送信された第２統計情報のグラフを受信し（ステップＳ５５３）、受信した第２統計情報のグラフを画面に表示し（ステップＳ５５４）、処理を終了する。

本実施形態によると、チケットＮＦＴの保有者に、当該チケットＮＦＴに対応するイベントに関連する販売商品の購入を許可することが可能となる。

本実施形態によると、販売商品の購入回数または購入数量を含む第１統計情報を出力することが可能となる。

本実施形態によると、チケットＮＦＴの保有者のイベントの参加回数、または保有者の属性を含む第２統計情報を出力することが可能となる。

本実施形態によると、第１統計情報及び第２統計情報を出力することにより、マーケティングに役立つ情報を収集することが可能となる。

（実施形態３）
実施形態３は、チケットＮＦＴの保有者に所定のインセンティブを付与する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。インセンティブは、仮想通貨（暗号資産）、電子マネー、クーポンまたはポイント等を使用することが可能な価値に係る情報である。なお、以下では、インセンティブが仮想通貨である例を説明するが、他の形式のインセンティブにも同様に適用することができる。

サーバ１は、チケットＮＦＴの保有者が、予め定められた複数のイベントにおける全てのチケットＮＦＴを有しているか否かを判定する。サーバ１は、保有者が全てのチケットＮＦＴを有していると判定した場合、ブロックチェーン２を通じて、当該保有者に所定の仮想通貨を付与する。仮想通貨の付与量は、予め決められた仮想通貨量（例えば、１００コイン）であっても良く、または、チケット料金の所定割合（例えば、５％）により算出された仮想通貨量であっても良い。

図２１は、チケットＮＦＴの保有者に所定の仮想通貨量を付与する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、対象となる複数のイベントＩＤを、例えば記憶部１２または大容量記憶部１７から取得する（ステップＳ１６１）。制御部１１は、複数の保有者ＩＤを大容量記憶部１７の保有者ＤＢ１７３から取得する（ステップＳ１６２）。制御部１１は、取得した複数の保有者ＩＤから、１つの保有者ＩＤを取得する（ステップＳ１６３）。

制御部１１は、取得した保有者ＩＤに対応する保有者が、対象となる複数のイベントにおける全てのチケットＮＦＴを有しているか否かを判定する（ステップＳ１６４）。具体的には、制御部１１は、取得した保有者ＩＤ及びイベントＩＤに基づき、該当するイベントに参加するためのチケットＮＦＴをチケットＤＢ１７２から取得できるか否かを判定する。例えば制御部１１は、全てのチケットＮＦＴをチケットＤＢ１７２から取得できた場合、保有者が全てのチケットＮＦＴを有していると判定する。または、制御部１１は、保有者が、対象となるチケットＮＦＴのいずれかを保有していない場合、保有者が全てのチケットＮＦＴを有していないと判定する。

制御部１１は、保有者が全てのチケットＮＦＴを有していないと判定した場合（ステップＳ１６４でＮＯ）、ステップＳ１６３の処理に戻る。制御部１１は、保有者が全てのチケットＮＦＴを有していると判定した場合（ステップＳ１６４でＹＥＳ）、保有者ＩＤに基づいて保有者のウォレットアドレスを大容量記憶部１７の保有者ＤＢ１７３から取得する（ステップＳ１６５）。

制御部１１は、所定の仮想通貨量（例えば、１００コイン）を保有者に付与するトランザクションを作成する（ステップＳ１６６）。トランザクションは、ブロックチェーン２における取引記録であり、ブロックチェーン２の参加者間での各種の情報及び価値の移転を記憶している。作成されたトランザクションは、保有者のウォレットアドレス、仮想通貨付与元（例えば、システムの運営者）のウォレットアドレス及び取引日時等を含む。

制御部１１は、ブロックチェーン２のいずれかのノード２１に、作成したトランザクションを通信部１３により送信する（ステップＳ１６７）。ブロックチェーン２のノード２１の制御部２１１は、サーバ１から送信されたトランザクションを通信部２１３により受信する（ステップＳ２６１）。ノード２１の制御部２１１は、受信したトランザクションに応じて、保有者のウォレットアドレス宛に所定の仮想通貨の付与処理を実行する（ステップＳ２６２）。

サーバ１の制御部１１は、当該保有者ＩＤが最後の保有者ＩＤであるか否かを判定する（ステップＳ１６８）。制御部１１は、当該保有者ＩＤが最後の保有者ＩＤでないと判定した場合（ステップＳ１６８でＮＯ）、ステップＳ１６３の処理に戻る。制御部１１は、当該保有者ＩＤが最後の保有者ＩＤであると判定した場合（ステップＳ１６８でＹＥＳ）、処理を終了する。

なお、上述した仮想通貨の付与処理に限るものではない。例えば、スマートコントラクトにより保有者に仮想通貨を付与しても良い。

本実施形態によると、保有者が、予め定められた複数のイベントにおける全てのチケットＮＦＴを有している場合、当該保有者に所定のインセンティブを付与することが可能となる。

本実施形態によると、保有者にインセンティブを付与することにより、各イベントに積極的に参加するように保有者を促すことが可能になる。

（実施形態４）
実施形態４は、ロイヤルティの高いチケットＮＦＴの保有者に特典ＮＦＴを発行する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。

サーバ１は、チケットＮＦＴの保有者から、ロイヤルティの高いチケットＮＦＴの保有者を、特典ＮＦＴの発行対象者として特定する。ロイヤルティが高い保有者は、例えば、所定期間（例えば、１年）内にイベントに参加した回数が所定の閾値以上である保有者であっても良く、または、イベントに関連する販売商品の購入回数若しくは購入数量が所定の閾値以上である保有者であっても良い。

サーバ１は、特定した対象者に特典ＮＦＴを発行する。特典ＮＦＴは、例えば、特別なイベントに参加するためのチケットＮＦＴ、またはイベントに関連する販売商品（公演記念書籍または雑誌等）に対応する販売商品ＮＦＴ等を含む。なお、サーバ１は、特定した対象者に、暗号資産、電子マネー、クーポンまたはポイント等を含むインセンティブを付与しても良い。

図２２は、ＮＦＴの保有者に特典ＮＦＴを発行する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、ロイヤルティの高いチケットＮＦＴの保有者を特典ＮＦＴの発行対象者として特定する（ステップＳ１７１）。

例えば制御部１１は、保有者ＩＤ毎にイベントの参加回数を大容量記憶部１７の入場履歴ＤＢ１７４から集計する。制御部１１は、集計した参加回数が所定の回数（例えば、３回）以上である場合、当該保有者が特典ＮＦＴの発行対象者として特定する。または、制御部１１は、保有者ＩＤ毎にイベントに関連する販売商品の購入数量を大容量記憶部１７の購入履歴ＤＢ１７６から集計する。制御部１１は、集計した購入数量が所定の数量（例えば、５回）以上である場合、当該保有者が特典ＮＦＴの発行対象者として特定する。

制御部１１は、予め決められた特典情報（例えば、コンサートのイベントＩＤ）を記憶部１２または大容量記憶部１７から取得する（ステップＳ１７２）。制御部１１は、特定した各対象者に対し、特典情報を含む特典ＮＦＴの生成要求を通信部１３によりブロックチェーン２のいずれかのノード２１に送信する（ステップＳ１７３）。

ブロックチェーン２のノード２１の制御部２１１は、通信部２１３を介して、サーバ１から送信された特典ＮＦＴの生成要求を受信する（ステップＳ２７１）。ノード２１の制御部２１１は、受信した特典ＮＦＴの生成要求に応じて、例えばＥＲＣ７２１を利用し、特典ＮＦＴを生成する（ステップＳ２７２）。制御部２１１は、生成した特典ＮＦＴのトークンＩＤ、所有者アドレス及びトークンＵＲＩを記憶部２１２に記憶する（ステップＳ２７３）。制御部２１１は、生成した特典ＮＦＴを通信部２１３によりサーバ１に送信する（ステップＳ２７４）。

サーバ１の制御部１１は、ブロックチェーン２のノード２１から送信された特典ＮＦＴを通信部１３により受信する（ステップＳ１７４）。制御部１１は保有者ＩＤに基づき、通信部１３を介して、ブロックチェーン２上に発行された特典ＮＦＴを該当する保有者の保有者端末３に送信する（ステップＳ１７５）。

保有者端末３の制御部３１は、サーバ１から送信された特典ＮＦＴを通信部３３により受信する（ステップＳ３７３）。制御部３１は、受信した特典ＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ）を表示部３５により表示し（ステップＳ３７４）、処理を終了する。

本実施形態によると、ロイヤルティの高いチケットＮＦＴの保有者に特典ＮＦＴを発行することが可能となる。

本実施形態によると、ロイヤルティ保有者に特典ＮＦＴを発行することにより、保有者のイベント参加のリピート率を向上することが可能となる。

（実施形態５）
実施形態５は、チケットＮＦＴの転売または譲渡の場合、イベントの入場の許否を判定する形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。なお、以下では、チケットＮＦＴの譲渡の例を説明するが、チケットＮＦＴの転売にも同様に適用することができる。

図２３は、チケットＮＦＴの譲渡の場合に入場管理システムの処理動作を説明する説明図である。なお、図７と重複する内容については説明を省略する。
サーバ１は、ブロックチェーン２上に発行されたチケットＮＦＴの譲渡要求を受け付けた場合、受け付けた譲渡要求に応じて、当該ブロックチェーン２を通じて譲渡処理を行う。譲渡要求には、譲渡対象となるチケットＮＦＴ、当該チケットＮＦＴに対応するチケットＩＤ、譲渡元情報及び譲渡先情報等を含む。

チケットＮＦＴには、トークンＩＤ、所有者（保有者）アドレス及びトークンＵＲＩ等が含まれる。譲渡元情報には、譲渡元となる保有者（例えば、保有者Ａ氏）の保有者ＩＤ及びウォレットアドレス等が含まれる。譲渡先情報には、譲渡先となる保有者（例えば、保有者Ｂ氏）の保有者ＩＤ及びウォレットアドレス等が含まれる。

チケットＮＦＴを保有する保有者Ａ氏が、当該チケットＮＦＴを保有者Ｂ氏に譲渡した場合、当該チケットＮＦＴを保有者Ａ氏から保有者Ｂ氏に譲渡する処理はブロックチェーン２上に行われる。

具体的には、サーバ１は、保有者Ａ氏が保有するチケットＮＦＴを保有者Ｂ氏に譲渡した譲渡要求を受け付けた場合、保有者Ａ氏から保有者Ｂ氏にチケットＮＦＴを譲渡するトランザクションを作成する。作成されたトランザクションは、保有者Ａ氏が保有するチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）、保有者Ａ氏のウォレットアドレス、保有者Ｂ氏のウォレットアドレス及び取引日時等を含む。

サーバ１は、ブロックチェーン２のいずれかのノード２１に、作成したトランザクションを送信する。ブロックチェーン２のノード２１は、サーバ１から送信されたトランザクションを受信する。ノード２１は、受信したトランザクションに応じて、対象となるチケットＮＦＴの譲渡処理を実行する。

具体的には、ノード２１は、チケットＮＦＴを保有する保有者のウォレットアドレスを、保有者Ａ氏のウォレットアドレスから保有者Ｂ氏のウォレットアドレスに変更する。ノード２１は、当該チケットＮＦＴのトークンＩＤ及びトークンＵＲＩ（メタデータの場所）を引き継ぐようにする。ノード２１は、チケットＮＦＴの所有者アドレスを、保有者Ａ氏の所有者アドレスから保有者Ｂ氏の所有者アドレスに変更する。ノード２１は、譲渡後の保有者のウォレットアドレス、並びに、譲渡後のチケットＮＦＴのトークンＩＤ（変更なし）、変更後の所有者アドレス、及びトークンＵＲＩ（変更なし）等を記録する。

ブロックチェーン２のノード２１は、保有者Ａ氏から保有者Ｂ氏に譲渡されたチケットＮＦＴをサーバ１に送信する。サーバ１は、ブロックチェーン２のノード２１から送信された譲渡後のチケットＮＦＴを受信する。サーバ１は、当該チケットＮＦＴに対応するチケットＩＤに基づき、譲渡後のチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）、及び譲渡先となる保有者の保有者ＩＤをチケットＤＢ１７２に更新する。

なお、譲渡情報を記憶するための譲渡ＤＢが設けられても良い。この場合、例えばサーバ１は、譲渡対象となるチケットＮＦＴ、譲渡元情報（譲渡元となる保有者の保有者ＩＤ及びウォレットアドレス等）、及び、譲渡先情報（譲渡先となる保有者の保有者ＩＤ及びウォレットアドレス等）を譲渡ＤＢに記憶しても良い。

以上の処理によって、保有者Ａ氏が保有するチケットＮＦＴを、当該保有者Ａ氏から保有者Ｂ氏に譲渡する。従って、保有者Ｂ氏はチケットＮＦＴを保有する。なお、本実施形態では、チケットＮＦＴのみを譲渡したが、チケットＮＦＴ及び当該チケットＮＦＴに対応するチケットを同時に譲渡することができる。

サーバ１は、譲渡先となる保有者Ｂ氏の保有者ＩＤに基づき、チケットＩＤ及びイベントＩＤに対応付けてブロックチェーン２上に譲渡されたチケットＮＦＴを、保有者Ｂ氏の保有者端末３に送信する。保有者Ｂ氏の保有者端末３は、サーバ１から送信されたチケットＩＤ、イベントＩＤ及びチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）を受信する。保有者Ｂ氏の保有者端末３は、受信したチケットＮＦＴを画面に表示する。

その後に、実施形態１及び変形例１での処理と同様に、保有者端末３は、乱数の発生処理、並びに、保有者のウォレットアドレス、乱数及びタイムスタンプをサーバ１に送信する処理等を行う。サーバ１は、チケットＩＤ及びイベントＩＤに対応付けて、保有者Ｂ氏の保有者端末３から送信されたウォレットアドレス、乱数及びタイムスタンプをチケットＤＢ１７２に更新する。

イベントへの入場受付の場合、リーダ端末４は、保有者Ｂ氏の保有者端末３上に表示されている２次元コードを読み取ることにより、保有者Ｂ氏のウォレットアドレス及び乱数を取得する。リーダ端末４は、取得した保有者Ｂ氏のウォレットアドレス及び乱数をサーバ１に送信する。サーバ１は、リーダ端末４から送信された保有者Ｂ氏のウォレットアドレス及び乱数と、記憶された保有者Ｂ氏のウォレットアドレス及び乱数とに基づいて、チケットＮＦＴの保有者Ｂ氏に対してイベントの入場の許否を判定する。

図２４は、チケットＮＦＴを譲渡する際の処理手順を示すフローチャートである。なお、図２４では、チケットＮＦＴを保有する保有者Ａ氏から保有者Ｂ氏に、当該チケットＮＦＴを譲渡する例を説明する。

保有者Ａ氏の保有者端末３の制御部３１は、記憶部３２に記憶された保有者Ａ氏のウォレットアドレスを取得する（ステップＳ３８１）。制御部３１は、例えば疑似乱数発生アルゴリズムを用いて乱数を発生する（ステップＳ３８２）。制御部３１は、発生した乱数をチケットＩＤ及びイベントＩＤに対応付けて記憶部３２に記憶する（ステップＳ３８３）。

制御部３１は、チケットＩＤ、イベントＩＤ、取得した保有者のウォレットアドレス、発生した乱数及びタイムスタンプ等を含む入場受付用情報を通信部３３によりサーバ１に送信する（ステップＳ３８４）。タイムスタンプは、例えばウォレットアドレス及び乱数の送信日時であっても良い。

サーバ１の制御部１１は、保有者Ａ氏の保有者端末３から送信された入場受付用情報を通信部１３により受信する（ステップＳ１８１）。制御部１１は、受信した入場受付用情報を大容量記憶部１７のチケットＤＢ１７２に記憶する（ステップＳ１８２）。具体的には、制御部１１は、受信した保有者のウォレットアドレス、乱数及びタイムスタンプを、チケットＩＤ及びイベントＩＤに対応付けてチケットＤＢ１７２に記憶する。

保有者Ａ氏の保有者端末３の制御部３１は、保有者Ａ氏が保有するチケットＮＦＴを保有者Ｂ氏に譲渡した譲渡要求を入力部３４により受け付ける（ステップＳ３８５）。制御部３１は、受け付けた譲渡要求を通信部３３によりサーバ１に送信する（ステップＳ３８６）。なお、譲渡先となる保有者Ｂ氏の保有者端末３は、譲渡要求をサーバ１に送信しても良い。

譲渡要求には、譲渡対象となるチケットＮＦＴ、当該チケットＮＦＴに対応するチケットＩＤ、譲渡元情報（例えば、保有者Ａ氏の保有者ＩＤ及びウォレットアドレス等）、及び、譲渡先情報（例えば、保有者Ｂ氏の保有者ＩＤ及びウォレットアドレス等）等を含む。

サーバ１の制御部１１は、保有者Ａ氏の保有者端末３から送信された譲渡要求を通信部１３により受信する（ステップＳ１８３）。制御部１１は、受信した譲渡要求に応じて、ブロックチェーン２を通じて当該チケットＮＦＴの譲渡処理を行う（ステップＳ１８４）。制御部１１は、当該チケットＮＦＴに対応するチケットＩＤ、または当該チケットＮＦＴのトークンＩＤに基づき、大容量記憶部１７のチケットＤＢ１７２に当該チケットＮＦＴが存在しているか否かを判定する（ステップＳ１８５）。

制御部１１は、当該チケットＮＦＴが存在していないと判定した場合（ステップＳ１８５でＮＯ）、当該チケットＮＦＴがチケットＤＢ１７２に存在していない旨を含むエラーメッセージを表示部１５により出力する（ステップＳ１８６）。なお、制御部１１は通信部１３を介して、エラーメッセージを保有者Ａ氏または保有者Ｂ氏の保有者端末３に送信しても良い。

制御部１１は、当該チケットＮＦＴが存在していると判定した場合（ステップＳ１８５でＹＥＳ）、譲渡後のチケットＮＦＴをチケットＤＢ１７２に更新する（ステップＳ１８７）。具体的には、制御部１１は、当該チケットＮＦＴに対応するチケットＩＤに基づき、譲渡後のチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）、及び保有者Ｂ氏の保有者ＩＤをチケットＤＢ１７２に更新する。

制御部１１は、保有者Ｂ氏の保有者ＩＤに基づき、ブロックチェーン２上に譲渡されたチケットＮＦＴを通信部１３により保有者Ｂ氏の保有者端末３に送信する（ステップＳ１８８）。保有者Ｂ氏の保有者端末３の制御部３１は、サーバ１から送信された譲渡後のチケットＮＦＴを通信部３３により受信する（ステップＳ３９１）。制御部３１は、受信した譲渡後のチケットＮＦＴ（トークンＩＤ、所有者アドレス及びトークンＵＲＩ等）を表示部３５により表示する（ステップＳ３９２）。

保有者Ｂ氏の保有者端末３の制御部３１は、ステップＳ３９３～Ｓ３９６の処理を実行する。なお、ステップＳ３９３～Ｓ３９６の処理に関しては、ステップＳ３８１～Ｓ３８４の処理と同様であるため、説明を省略する。

サーバ１の制御部１１は、保有者Ｂ氏の保有者端末３から送信された入場受付用情報（チケットＩＤ、イベントＩＤ、保有者Ｂ氏のウォレットアドレス、乱数及びタイムスタンプ）を通信部１３により受信する（ステップＳ１８９）。制御部１１は、受信した入場受付用情報を大容量記憶部１７のチケットＤＢ１７２に更新し（ステップＳ１９０）、処理を終了する。具体的には、制御部１１は、受信した保有者Ｂ氏のウォレットアドレス、乱数及びタイムスタンプを、チケットＩＤ及びイベントＩＤに対応付けてチケットＤＢ１７２に更新する。

上述の譲渡処理によって、譲渡対象となるチケットＮＦＴに対し、譲渡先となる保有者Ｂ氏のウォレットアドレス、乱数及びタイムスタンプを更新することができる。イベントへの入場受付の場合、例え譲渡元となる所有者Ａ氏に発行された入場用の２次元コードが提示されても、当該２次元コードに含まれる入場受付用情報と、チケットＤＢ１７２に記憶された入場受付用情報とが一致していないため、当該所有者Ａ氏の入場を拒否することができる。

本実施形態によると、チケットＮＦＴの転売または譲渡の場合でも、イベントの入場の許否を判定することが可能となる。

本実施形態によると、チケットＮＦＴの転売または譲渡の場合に、新たな保有者に対して乱数を再発生し、且つ、タイムスタンプを更新することにより、誤入場または不正入場を防止することが可能となる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

各実施形態に記載した事項は相互に組み合わせることが可能である。また、特許請求の範囲に記載した独立請求項及び従属請求項は、引用形式に関わらず全てのあらゆる組み合わせにおいて、相互に組み合わせることが可能である。さらに、特許請求の範囲には他の２以上のクレームを引用するクレームを記載する形式（マルチクレーム形式）を用いているが、これに限るものではない。マルチクレームを少なくとも一つ引用するマルチクレーム（マルチマルチクレーム）を記載する形式を用いて記載しても良い。

１ 情報処理装置（サーバ）
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 入力部
１５ 表示部
１６ 読取部
１７ 大容量記憶部
１７１ イベントＤＢ
１７２ チケットＤＢ
１７３ 保有者ＤＢ
１７４ 入場履歴ＤＢ
１７５ 販売商品ＤＢ
１７６ 購入履歴ＤＢ
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ ブロックチェーンシステム（ブロックチェーン）
２１ ノード
２１１ 制御部
２１２ 記憶部
２１３ 通信部
２１４ 受付部
２１５ 出力部
２１６ ブロック生成部
２１７ ブロック検証部
２１８ ブロック共有部
３ 情報処理端末（購入者端末；保有者端末）
３１ 制御部
３２ 記憶部
３３ 通信部
３４ 入力部
３５ 表示部
３Ｐ 制御プログラム
４ 入場リーダ端末（リーダ端末）
４１ 制御部
４２ 記憶部
４３ 通信部
４４ 入力部
４５ 表示部
４６ コード読取部
４７ スピーカ
５ 管理者端末

Claims (9)

1. イベントに参加するためのチケットＮＦＴをブロックチェーンシステム上に発行し、
   発行したチケットＮＦＴの保有者の端末装置から送信された、前記保有者のウォレットアドレス及び前記端末装置で発生された乱数を、システムで受信し、
   前記端末装置で生成された、前記ウォレットアドレス及び前記乱数を含む２次元コードを、前記システムで取得し、
   受信したウォレットアドレス及び乱数と、取得した２次元コードに含まれるウォレットアドレス及び乱数とに基づいて、前記イベントの入場の許否を判定する
   情報処理方法。
2. 前記端末装置から送信された、前記保有者のウォレットアドレス、前記乱数及びタイムスタンプを、前記システムで受信し、
   前記端末装置で生成された、前記ウォレットアドレス、前記乱数及び前記タイムスタンプを含む２次元コードを、前記システムで取得し、
   受信したウォレットアドレス、乱数及びタイムスタンプと、取得した２次元コードに含まれるウォレットアドレス、乱数及びタイムスタンプとに基づいて、前記イベントの入場の許否を判定する
   請求項１に記載の情報処理方法。
3. 所定のチケットＮＦＴを有しているか否かを判定し、
   所定のチケットＮＦＴを有していると判定した場合、前記チケットＮＦＴの保有者に前記イベントに関連する販売商品の購入を許可する
   請求項１又は２に記載の情報処理方法。
4. 前記販売商品の購入回数または購入数量を含む第１統計情報を生成し、
   生成した第１統計情報を出力する
   請求項３に記載の情報処理方法。
5. 前記チケットＮＦＴの保有者のイベントの参加回数、または前記保有者の属性を含む第２統計情報を生成し、
   生成した第２統計情報を出力する
   請求項１又は２に記載の情報処理方法。
6. 予め定められた複数のイベントにおける全てのチケットＮＦＴを有しているか否かを判定し、
   全てのチケットＮＦＴを有していると判定した場合に、前記チケットＮＦＴの保有者に所定のインセンティブを付与する
   請求項１又は２に記載の情報処理方法。
7. 前記チケットＮＦＴの保有者から、ロイヤルティの高いチケットＮＦＴの保有者を対象者として特定し、
   特定した対象者に特典ＮＦＴを発行する
   請求項１又は２に記載の情報処理方法。
8. イベントに参加するためのチケットＮＦＴをブロックチェーンシステム上に発行し、
   発行したチケットＮＦＴの保有者の端末装置から送信された、前記保有者のウォレットアドレス及び前記端末装置で発生された乱数を、システムで受信し、
   前記端末装置で生成された、前記ウォレットアドレス及び前記乱数を含む２次元コードを、前記システムで取得し、
   受信したウォレットアドレス及び乱数と、取得した２次元コードに含まれるウォレットアドレス及び乱数とに基づいて、前記イベントの入場の許否を判定する
   処理をコンピュータに実行させるプログラム。
9. 入場リーダ端末と、情報処理装置とを備える情報処理システムであって、
   前記情報処理装置は、
   イベントに参加するためのチケットＮＦＴをブロックチェーンシステム上に発行する発行部と、
   前記発行部が発行したチケットＮＦＴを、前記チケットＮＦＴの保有者の端末装置に送信する第１送信部と、
   前記端末装置から送信された前記保有者のウォレットアドレス及び前記端末装置で発生された乱数を受信する受信部と、
   前記受信部が受信した保有者のウォレットアドレス及び乱数を記憶する記憶部とを備え、
   前記入場リーダ端末は、
   前記端末装置で生成された、前記ウォレットアドレス及び前記乱数を含む２次元コードを読み取る読取部と、
   前記読取部が読み取った２次元コードから前記保有者のウォレットアドレス及び乱数を取得する取得部と、
   前記取得部が取得した保有者のウォレットアドレス及び乱数を前記情報処理装置に送信する第２送信部とを備え、
   前記情報処理装置は、
   前記第２送信部が送信した保有者のウォレットアドレス及び乱数と、前記記憶部が記憶した保有者のウォレットアドレス及び乱数とに基づいて、前記イベントの入場の許否を判定する判定部
   を備える情報処理システム。

Images