JP7216770B2 - チケットシステム、プログラム、および方法。 - Google Patents

Description

本開示は、チケットシステム、プログラム、および方法に関する。

従来から、イベントのチケットを発券するシステムが知られている。
特許文献１には、イベントのチケットの購入により特典を提供することで、チケットの購入を促すシステムが開示されている。

特開２０２０－９８６４５号公報

しかしながら、従来のチケットを発券するシステムでは、チケット購入者に特典を付与する。このため、例えば特典が希少価値の高いものである場合には、特典を得るためだけの目的でチケットを購入し、特典の提供を受けた後にチケットを転売するといった行為が行われることがある。この場合には、実際の来場を希望している人にチケットが行き届かず、仮にチケットがたくさん売れた場合であっても、イベント会場への来場者が少なくなることがあった。
また、このような課題を解決するために、来場者に記念品等の現物の特典を付与する場合には、当該物品の管理の手間がかかるという問題があった。

ところで、イベントの主催者の立場としては、イベント会場への来場者が多いことは、イベントの盛り上がり向上、イベントの出演者の知名度向上、イベント自体の話題性向上、関連物販の販売促進、スポンサーシップ獲得等の直接的な利益が多い。このため、チケットが売れさえすれば、来場者が少なくてもよいとはならず、イベント会場への来場者が多いことが、イベントの主催者にとって望ましい状況となる。このため、イベントへの参加の動機付けを効果的に行うことが求められていた。

本開示の目的は、イベントへの参加の動機付けを効果的に行うことができるシステムを提供することにある。

本開示の一態様に係るチケット管理プログラムは、コンピュータのプロセッサに、チケットの使用を検出するステップと、チケットの使用の検出に応じて、チケットの所有者に対して、所有権が明確化可能なトークンを付与するステップと、を実行させるプログラム。

本開示によれば、イベントへの参加の動機付けを効果的に行うことができるシステムを提供する

本実施形態のチケットシステムの構成を示すブロック図である。 本実施形態のユーザ端末の構成を示すブロック図である。 本実施形態のチケット管理サーバの構成を示すブロック図である。 本実施形態の検札システムの構成を示すブロック図である。 本実施形態の検札システムに接続可能な入力デバイスの構成の一例を示すブロック図である。 本実施形態のトークン管理台帳の構成を示す図である。 本実施形態の概要の説明図である。 チケット管理サーバが記憶するイベントデータベース、ユーザデータベース、およびチケットデータベースのデータ構造の一例を示す図である。 外部サーバが記憶するアカウントデータベース、およびトークンデータベースのデータ構造の一例を示す図である。 トークン管理台帳のデータ構造の一例を示す図である。 本実施形態のユーザ登録処理のフローチャートである。 本実施形態の発券処理のフローチャートである。 本実施形態の検札処理のフローチャートである。 本実施形態のトークン付与の処理のフローチャートである。 チケット管理サーバが記憶する特典チケットデータベース、および外部サーバが記憶する引換コードデータベースのデータ構造の一例を示す図である。 特典チケットをユーザが引き換える処理のフローチャートである。 本実施形態の第１画面例および第２画面例を示す図である。 本実施形態の第３画面例および第４画面例を示す図である。 本実施形態の第５画面例および第６画面例を示す図である。 変形例１に係るトークン管理台帳４０のデータ構造を示す図である。 変形例２に係るトークン付与の処理のフローチャートである。

以下、本発明の一実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。

（１）チケットシステム１の構成
チケットシステム１の構成について説明する。図１は、本実施形態のチケットシステム１の構成を示すブロック図である。

図１に示すように、チケットシステム１は、ユーザ端末１０と、チケット管理サーバ２０と、検札システム３０と、を備える。
ユーザ端末１０、チケット管理サーバ２０、および検札システム３０はネットワーク（例えば、インターネットまたはイントラネット）ＮＷを介して接続されている。
チケットシステム１は、トークン管理台帳４０および外部サーバ５０とネットワークＮＷを介して接続されている。

ユーザ端末１０は、情報処理装置である。ユーザ端末１０は、チケット管理サーバ２０に対して興行に関するチケット情報を要求するように構成される。ユーザ端末１０は、チケット購入端末と言い換えることもできる。この点において、ユーザ端末１０は、チケットの購入者本人が所持する情報処理装置であってもよいし、チケット販売所に設置された情報処理装置であってもよい。

以降の説明において、情報処理装置は、例えば、スマートフォン、タブレット端末、パーソナルコンピュータ、サーバコンピュータ（例えば、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ、またはそれらの組み合わせ）、ウェアラブルデバイス（例えば、スマートウォッチ、またはスマートグラス）、などの種々のコンピュータを含み得る。本実施形態では、ユーザ端末１０は、ネットワークＮＷに接続可能なモバイルコンピュータであるスマートフォンを例に挙げて説明する。

チケット情報は、チケットに関する情報である。具体的には、チケット情報は、チケットを識別する情報、チケットが証明する権限に関する情報（例えば、チケットの対象となる興行に関する情報）、チケットの購入者の氏名、特徴量（例えば、顔の特徴量）に関する情報、チケットの購入者に関する情報（例えばユーザＩＤ）、もしくはそれらの組み合わせ、またはそれらを符号化したコード情報（例えば、ＱＲコード（登録商標）、または他の１次元もしくは２次元コード）を含み得る。

チケットは、ユーザが保持するユーザ端末１０に表示されたチケット情報の画像（つまり電子チケット）であってもよい。或いは、チケットは、チケット情報が印刷された紙またはその他の媒体であってもよい。
チケットとしては、各種のイベントに参加するためのチケット、店舗において各種のサービスの提供を受けるためのチケット、鉄道や航空機等の交通機関を利用するためチケット、又はオンラインイベントを視聴するためのチケット等が含まれる。

チケット管理サーバ２０は、情報処理装置である。チケット管理サーバ２０は、ユーザ端末１０からの要求に応じて、発券（つまりチケット情報の発行）を行うように構成される。また、チケット管理サーバ２０は、発行したチケット情報を管理するように構成される。

検札システム３０は、例えば、興行が各種のイベント会場で開催されるイベントである場合には、検札所に配置される情報処理装置である。検札所は、イベント会場とその外部空間との境界に相当する。検札システム３０は、イベント会場に対して入場しようとする人物（以降、「来場者」とする）によって提示されたチケットの保持するチケット情報を参照し、来場者の入場の可否を判定するように構成される。

ここで、イベント会場は、屋内であってもよいし、屋外であってもよい。例えば、対象空間は、興行会場（例えば、コンサート会場、観劇会場、試合会場、展覧会場、店舗またはそれらの組み合わせ）、公共交通機関、オフィス、または店舗であり得る。

また検札システム３０は、例えば、興行がサーバ空間において公開されるオンラインイベントである場合には、当該イベントへのアクセスを管理する情報処理装置である。検札システム３０は、オンラインイベントを視聴する人物（以降、「来場者」とする）によって提示されたチケットの保持するチケット情報を参照し、来場者の視聴の可否を判定するように構成される。

（１－１）ユーザ端末１０の構成
ユーザ端末１０の構成について説明する。図２は、本実施形態のチケット購入端末の構成を示すブロック図である。

図２に示すように、ユーザ端末１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４と、を備える。ユーザ端末１０は、入力デバイス１５および出力デバイス１６の少なくとも１つと接続可能である。

記憶装置１１は、プログラムおよびデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）

プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、ユーザ端末１０の機能を実現するように構成される。プロセッサ１２は、コンピュータの一例である。

入出力インタフェース１３は、入力デバイス１５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス１６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。

入力デバイス１５は、例えば、キーボード、ポインティングデバイス、タッチパネル、物理ボタン、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。

出力デバイス１６は、例えば、ディスプレイ、スピーカ、印刷装置、またはそれらの組み合わせである。

通信インタフェース１４は、ユーザ端末１０と外部装置（例えば、チケット管理サーバ２０、検札システム３０、トークン管理台帳４０、または外部サーバ５０の少なくとも１つ）との間の通信を制御するように構成される。

（１－２）チケット管理サーバ２０の構成
チケット管理サーバ２０の構成について説明する。図３は、本実施形態のチケット管理サーバ２０の構成を示すブロック図である。

図３に示すように、チケット管理サーバ２０は、記憶装置２１と、プロセッサ２２と、入出力インタフェース２３と、通信インタフェース２４とを備える。チケット管理サーバ２０は、入力デバイス２５および出力デバイス２６の少なくとも１つと接続可能である。

記憶装置２１は、プログラムおよびデータを記憶するように構成される。記憶装置２１は、例えば、ＲＯＭ、ＲＡＭ、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果

プロセッサ２２は、記憶装置２１に記憶されたプログラムを起動することによって、チケット管理サーバ２０の機能を実現するように構成される。プロセッサ２２は、コンピュータの一例である。

入出力インタフェース２３は、入力デバイス２５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス２６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。

入力デバイス２５は、例えば、キーボード、ポインティングデバイス、タッチパネル、センサ、または、それらの組合せである。

出力デバイス２６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。

通信インタフェース２４は、チケット管理サーバ２０と外部装置（例えば、ユーザ端末１０、検札システム３０、トークン管理台帳４０、または外部サーバ５０の少なくとも１つ）との間の通信を制御するように構成される。

（１－３）検札システム３０の構成
検札システム３０の構成について説明する。図４は、本実施形態の検札システム３０の構成を示すブロック図である。図５は、本実施形態の検札システム３０に接続可能な入力デバイス３５の構成の一例を示すブロック図である。

図４に示すように、検札システム３０は、記憶装置３１と、プロセッサ３２と、入出力インタフェース３３と、通信インタフェース３４とを備える。検札システム３０は、入力デバイス３５および出力デバイス３６の少なくとも１つと接続可能である。

記憶装置３１は、プログラムおよびデータを記憶するように構成される。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、および、ストレージの組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ

プロセッサ３２は、記憶装置３１に記憶されたプログラムを起動することによって、検札システム３０の機能を実現するように構成される。プロセッサ３２は、コンピュータの一例である。

入出力インタフェース３３は、入力デバイス３５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス３６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。

入力デバイス３５は、例えば、キーボード、ポインティングデバイス、タッチパネル、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。図５に示すように、入力デバイス３５としては、例えば可視光カメラ３５２が含まれる。

入力デバイス３５は、単独で、またはプロセッサ３２との協同により、少なくとも、認証情報取得手段を実現する。

認証情報取得手段は、来場者によるチケットの提示時に、来場者の入場可否の判定に必要な情報（以下、「認証情報」とする）を読み取る。認証情報は、例えば、以下の少なくとも１つを含む。
・チケット情報
・来場者の特徴量（例えば、顔の特徴量/声紋/掌紋）に関する情報

チケットには、チケット情報の読み取りのためのチケット情報領域が定められている。チケット情報領域には、チケット情報が表示、または印刷されている。

認証情報取得手段は、可視光カメラ３５２と、当該可視光カメラ３５２によって撮影された画像を解析してチケット情報の画像を抽出し、かつ当該チケット情報の画像からチケット情報を復元するアプリケーションとの組み合わせにより、チケット情報を取得できる。チケット情報の取得において、ＯＣＲ（Optical Character Recognition）処理、または復号処理などの情報処理が必要に応じて行われる。

認証情報取得手段は、可視光カメラ３５２と、当該可視光カメラ３５２によって撮影された画像を解析して来場者の顔の画像を抽出し、かつ当該来場者の顔の画像から特徴量を計算するアプリケーションとの組み合わせにより、来場者の顔の特徴量に関する情報を取得できる。

チケットおよび来場者は、同一の可視光カメラ３５２によって同時にまたは順次撮影されてもよいし、一方が可視光カメラ３５２によって撮影され他方が図示されない他の可視光カメラによって撮影されてもよい。

出力デバイス３６は、例えば、ディスプレイ、スピーカ、警報装置、電動式のゲート、またはそれらの組み合わせである。

通信インタフェース３４は、検札システム３０と外部装置（例えば、ユーザ端末１０、またはチケット管理サーバ２０、トークン管理台帳４０、または外部サーバ５０の少なくとも１つ）との間の通信を制御するように構成される。

（１－４）トークン管理台帳４０の構成
図６は、トークン管理台帳４０の構成を示す図である。トークン管理台帳４０は、ノードとして機能する信号処理装置４０Ａ～４０Ｅを備える、分散型システムである。

信号処理装置４０Ａ～４０Ｅは、ネットワークにそれぞれ接続された、例えば、パーソナルコンピュータである。本実施形態では、ネットワークは、ＬＡＮであってもよく、インターネット、および通信事業者が提供する通信網等の公開されているネットワークであってもよい。信号処理装置４０Ａ～４０Ｅは、ネットワークと、例えば、有線または無線により接続されている。信号処理装置４０Ａ～４０Ｅは、ピア・ツー・ピア方式を利用して互いに通信する。

信号処理装置４０Ａ～４０Ｅは、トークン管理台帳４０を、ブロックチェーン技術を用いて実現している。また、信号処理装置４０Ａ～４０Ｅは、例えば、信号処理装置４０Ａ～４０Ｅのいずれか１つの信号処理装置４０Ａは、記録すべきトークンの取引に関するデータを取得する。信号処理装置４０Ａは、取得したデータを含むブロックを作成し、ブロックチェーンに追加する。信号処理装置４０Ａは、追加したブロックの情報を他の信号処理装置４０Ａへ送信する。他の信号処理装置４０Ｂ～４０Ｅは、受信したブロックの正しさを検証し、正しさが検証されると、ブロックチェーンに追加する。信号処理装置４０Ａ～４０Ｅは、例えば、連結されるブロックの数（承認数）に従ってブロックチェーンを確定する。これにより、信号処理装置４０Ａ～４０Ｅで、同一のトークン管理台帳４０が保存されることになる。なお、保存されるデータは、適宜に暗号化されてもよい。

なお、トークン管理台帳４０の構成は、図６に示されるものに限定されない。例えば、トークン管理台帳４０が備える信号処理装置４０Ａの台数は、２台以上であれば何台でも構わない。

信号処理装置４０Ａは、記憶装置４１と、プロセッサ４２と、入出力インタフェース４３と、通信インタフェース４４と、を備える。信号処理装置４０Ａは、入力デバイス４５および出力デバイス４６の少なくとも１つと接続可能である。

記憶装置４１は、プログラムおよびデータを記憶するように構成される。記憶装置４１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）

プロセッサ４２は、記憶装置４１に記憶されたプログラムを起動することによって、信号処理装置４０Ａの機能を実現するように構成される。プロセッサ４２は、コンピュータの一例である。

入出力インタフェース４３は、入力デバイス４５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス４６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。

入力デバイス４５は、例えば、キーボード、ポインティングデバイス、タッチパネル、物理ボタン、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。

出力デバイス４６は、例えば、ディスプレイ、スピーカ、印刷装置、またはそれらの組み合わせである。

通信インタフェース４４は、信号処理装置４０Ａと外部装置（例えば、ユーザ端末１０、チケット管理サーバ２０、検札システム３０、又は外部サーバ５０の少なくとも１つ）との間の通信を制御するように構成される。

（１－５）外部サーバ５０の構成
図１に示す外部サーバ５０は、少なくとも記憶部と、通信インタフェースと、を備えている。外部サーバ５０は、例えば分散アプリケーション（ＤＡｐｐ）により実現される記憶装置である。
記憶部には、トークンを構成するデジタルコンテンツが格納されている。外部サーバ５０は、例えばデジタルコンテンツの運営を行うコンテンツ運営会社により管理される。
通信インタフェースは、外部サーバ５０と外部装置（ユーザ端末１０、チケット管理サーバ２０、検札システム３０、又はトークン管理台帳４０の少なくとも１つ）との間の通信を制御するように構成される。
なお、外部サーバ５０の機能をチケット管理サーバ２０が実現してもよい。

（２）実施形態の概要
本実施形態の概要について説明する。図７は、本実施形態の概要の説明図である。

図７に示すように、検札システム３０は、検札所に配置される。検札所では、複数の人物が行列を成しており、個々の人物に対して検札が順次行われる。

可視光カメラ３５２は、来場者ＴＰによるチケットＴＣの提示時に当該可視光カメラ３５２の撮像範囲に入っている来場者ＴＰとチケットＴＣとを撮影する。検札システム３０（具体的にはプロセッサ３２）は、可視光カメラ３５２によって撮影された画像から、チケットＴＣのチケット情報と、来場者ＴＰの特徴量（例えば顔の特徴量）とを取得する。

次に、検札システム３０は、チケット情報の確認を行い、適切なチケットを提示した来場者に対して来場の許可を通知するとともに、チケット管理サーバ２０にその旨を通知する。チケット管理サーバ２０は、チケットを使用済みの状態にする。チケットを使用済みとすることを、「もぎる」とも呼ぶ。すなわち、チケットの使用の検出は、チケットが、イベント会場で開催されるイベントに関するものである場合には、イベント会場への来場時に行われるチケットのもぎりにより実行される。
なお、チケットの使用とは、チケットを用いてユーザがイベント会場に来場することを指す。

検札システム３０は、可視光カメラ３５２から取得した来場者ＴＰの顔の特徴量と、チケット管理サーバ２０が予め記憶しているチケットの所有者の顔の特徴量と、を比較し、チケットの所有者と使用者が一致していることを確認する。チケットの所有者と使用者の同一性が確認できた場合には、チケット管理サーバ２０は、チケットの所有者に対して、トークンを付与する。

すなわち、チケットシステム１では、使用が検出されたチケットの所有者に対して、所有権が明確化されているトークンを付与する。トークンとは資産価値のあるデータであって、チケットの特典としてチケットの所有者（言い換えればチケットの使用者すなわち来場者）に対して付与されるデータを指す。そして、本実施形態におけるトークンは、後述するトークン管理台帳４０において所有者が記録され、その所有権が明確化可能となっている。本発明のトークンは、代替性を備えたトークンと、非代替性を備えたトークン（Non-Fungible Token）と、を含む。

代替性を備えたトークンとしては、例えば仮想通貨やポイントのような金銭と等価の資産として扱われるデータを指す。

非代替性を備えたトークンとしては、例えばＳＮＳ（Social Networking Service）上でコメントされたテキストデータ等も含まれる。この場合、テキストデータ自体は第３者が任意に複写することができる。一方、当該ＳＮＳ上におけるテキストデータの元データは、テキストデータ自体が複写されて転用されたとしても、所有権が変わることはない。トークンとしては、例えば特典として付与されるデジタル画像、デジタル動画、デジタル音源のようなデジタルコンテンツが含まれる。このようなデジタルコンテンツが、図１に示す外部サーバ５０に格納されている。本実施形態では、トークンとして非代替性トークンを扱う構成を例に挙げて説明する。

本発明のトークンは、ユーザ同士の合意に基づいて、任意に譲渡することができる。トークンの譲渡においては、他のトークンとの交換、または金銭その他の価値の供与とともに行われてもよい。

このように、チケットシステム１が、チケットの使用者（来場者）に対してトークンを付与するので、トークンの付与を希望するユーザはチケットを購入するだけでは足らず、イベント会場への来場が必要となる。このため、トークンを収集したいユーザの来場が促される。また、チケットシステム１では、来場者と所有者との同一性がチェックされるので、チケットの購入によりトークンを取得し、その後にチケットを他人に譲渡するといった転売行為を抑制する。

（３）データ構造
本実施形態のデータベースについて説明する。以下のデータベースは、チケット管理サーバ２０の記憶装置２１、および外部サーバ５０に記憶される。ただし、以下のデータベースの少なくとも一部の複製が、検札システム３０の記憶装置３１にも記憶されてもよい。

（３－１）イベントデータベース
イベントデータベースの構成例について説明する。図８は、チケット管理サーバ２０が記憶するイベントデータベース、ユーザデータベース、およびチケットデータベースのデータ構造の一例を示す図である。

図８Ａに示すイベントデータベースには、イベント情報が格納される。
図８に示すように、イベントデータベースは、「イベントＩＤ」フィールドと、「開催日時」フィールドと、「イベント名称」フィールドと、「運営会社」フィールドと、「出演者」フィールドと、「イベント種別」フィールドと、「トークンの内容」フィールドと、を含む。

「イベントＩＤ」フィールドには、イベントＩＤが格納される。イベントＩＤは、各種のイベントを識別する情報である。

「開催日時」フィールドには、開催日時が格納される。開催日時は、イベントＩＤによって識別されるイベントが開催される日時を示す情報である。

「イベント名称」フィールドは、イベント名称が格納される。イベント名称は、イベントＩＤによって識別されるイベントの名称を示す情報である。

「運営会社」フィールドには、運営会社に関する情報が格納される。運営会社に関する情報とは、イベントＩＤによって識別されるイベントの運営会社を示す情報である。運営会社に関する情報は、運営会社の名称の他、運営会社の所在地や担当者の連絡先の情報を含んでもよい。

「出演者」フィールドには、出演者情報が格納される。出演者情報は、イベントＩＤによって識別されるイベントへの出演者を示す情報である。出演者情報には、個人または団体（グループ名、チーム名、バンド名等）が含まれる。

「イベント種別」フィールドには、イベント種別に関する情報が格納される。イベント種別に関する情報は、イベントＩＤによって識別されるイベントの概要を示す情報である。例えば、イベント種別として、「プロ野球」「アニメ試写会」「オンラインライブ」等が挙げられる。

（３－２）ユーザデータベース
ユーザデータベースの構成例について説明する。
図８Ｂに示すユーザデータベースには、ユーザ情報が格納される。
図８Ｂに示すように、ユーザデータベースは、「ユーザＩＤ」フィールドと、「ログインＰＡＳＳ」フィールドと、「ユーザ氏名」フィールドと、「ユーザ属性」フィールドと、「連絡先」フィールドと、「特徴量」フィールドと、を含む。

「ユーザＩＤ」フィールドには、ユーザＩＤが格納される。ユーザＩＤは、ユーザを識別する情報である。

「ログインＰＡＳＳ」フィールドには、ユーザがチケット管理サーバ２０にログインをする際に入力が要求されるログインパスワードに関する情報が格納される。

「ユーザ氏名」フィールドには、ユーザＩＤに対応するユーザの氏名が格納される。

「ユーザ属性」フィールドには、ユーザＩＤに対応するユーザの属性を示す情報が格納される。ユーザの属性としては、年齢、生年月日、性別、職業、国籍、居住地区、またはそれらの組み合わせ等を含む。

「連絡先」フィールドには、ユーザＩＤに対応するユーザの連絡先を示す情報が格納される。連絡先情報としては、例えば、メールアドレス、電話番号、ＳＮＳ（Social Networking Service）もしくは他のメッセージング可能なアプリケーションのアカウント情報、またはそれらの組み合わせである。連絡先情報は、ここで挙げた例に限られず、ユーザ端末１０を介して来場者にリアルタイムに通知を送信するために利用可能な任意の種別の情報を含むことができる。

「特徴量」フィールドは、ユーザＩＤに対応するユーザの顔の特徴量が格納される。ユーザの顔の特徴量は、ユーザの顔を撮影した画像から抽出される。

（３－３）チケットデータベース
チケットデータベースの構成例について説明する。

図８Ｃに示すチケットデータベースには、チケット情報が格納される。
図８Ｃに示すように、ユーザデータベースは、「チケットＩＤ」フィールドと、「イベントＩＤ」フィールドと、「座席番号」フィールドと、「トークンＩＤ」フィールドと、「シリアルコード」フィールドと、「所有者ＩＤ」フィールドと、「ステータスＩＤ」フィールドと、を含む。

「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケットを識別するための情報である。

「イベントＩＤ」フィールドには、チケットＩＤに対応するイベントのイベントＩＤが格納される。

「座席番号」フィールドには、チケットＩＤに対応する座席を識別する情報が格納される。座席番号とは、イベント会場において割り当てられた座席（「区域」の一例）に関する情報である。なお、オンラインイベントのように座席がない場合には、座席番号ＩＤはなくてもよい。

「トークンＩＤ」フィールドには、チケットＩＤに対応するチケットの特典として付与されるトークンを識別するトークンＩＤが格納される。

「シリアルコードＩＤ」フィールドには、トークンＩＤに対応するトークンの付与を受けるために入力が要求されるシリアルコードが格納される。シリアルコードは、トークンの付与を承認するために設定された、所定の文字列で構成された識別子である。

「所有者ＩＤ」フィールドには、チケットＩＤに対応するチケットの所有者を示すユーザＩＤが格納される。チケット所有者とは、原始的にはチケット購入者を指す。チケット所有者は、チケットの購入後の譲渡により、譲渡先のユーザになる。

「ステータスＩＤ」フィールドには、チケットＩＤに対応するチケットの状態を示す情報が格納される。チケットの状態としては、「使用前」、「使用後」が含まれる。チケットのもぎり後に、チケットの状態は「使用後」に書き換えられる。

（３－４）アカウントデータベース
図９は、外部サーバ５０が記憶するアカウントデータベース、およびトークンデータベースのデータ構造の一例を示す図である。

図９Ａは、外部サーバ５０が記憶するアカウントデータベースのデータ構造の一例を示す図である。
図９Ａに示すアカウントデータベースには、ユーザがトークンの付与を受けるために用いられるアカウント情報が格納される。

図９Ａに示すように、アカウントデータベースは、「ユーザ氏名」フィールドと、「ユーザ属性」フィールドと、「連絡先」フィールドと、「外部サーバログインＩＤ」フィールドと、「外部サーバログインＰＡＳＳ」フィールドと、「管理台帳ログインＩＤ」フィールドと、「管理台帳ＰＡＳＳ」フィールドと、を含む。

「ユーザ氏名」フィールドには、ユーザの氏名が格納される。

「ユーザ属性」フィールドには、ユーザ氏名に対応するユーザの属性を示す情報が格納される。ユーザの属性としては、年齢、生年月日、性別、職業、国籍、居住地区、またはそれらの組み合わせ等を含む。

「連絡先」フィールドには、ユーザ氏名に対応するユーザの連絡先を示す情報が格納される。連絡先情報としては、例えば、メールアドレス、電話番号、ＳＮＳ（Social Networking Service）もしくは他のメッセージング可能なアプリケーションのアカウント情報、またはそれらの組み合わせである。連絡先情報は、ここで挙げた例に限られず、ユーザ端末１０を介して来場者にリアルタイムに通知を送信するために利用可能な任意の種別の情報を含むことができる。

「外部サーバログインＩＤ」フィールドには、ユーザ氏名に対応するユーザの外部サーバ５０におけるユーザＩＤが格納される。すなわち、「外部サーバログインＩＤ」は、当該ユーザが外部サーバ５０にログインする際に入力が要求されるログインＩＤである。

「外部サーバＰＡＳＳ」フィールドには、ユーザ氏名に対応するユーザの外部サーバ５０にログインする際に入力が要求されるログインパスワードが格納される。

「管理台帳ログインＩＤ」フィールドには、ユーザ氏名に対応するユーザのトークン管理台帳４０におけるユーザＩＤが格納される。すなわち、「管理台帳ログインＩＤ」は、当該ユーザ又は外部サーバ５０が、トークン管理台帳４０にログインする際に入力が要求されるログインＩＤである。

「管理台帳ＰＡＳＳ」フィールドには、ユーザからの入力に基づいて、外部サーバ５０が、トークン管理台帳４０の内容を書き換える際に、外部サーバ５０がトークン管理台帳４０に入力するパスワードが格納される。また、ユーザ自身が、管理台帳ログインＩＤおよび管理台帳ＰＡＳＳを用いて、直接トークン管理台帳４０の書き換えを行うこともできる。

（３－５）トークンデータベース
図９Ｂは、外部サーバ５０が記憶するトークンデータベースのデータ構造の一例を示す図である。
図９Ｂに示すトークンデータベースには、トークンに関する情報が格納される。
図９Ｂに示すように、イベントデータベースは、「トークンＩＤ」フィールドと、「トークンの内容」フィールドと、「台帳ＩＤ」と、「シリアルコード」フィールドと、「ステータス」フィールドと、を含む。

「トークンＩＤ」フィールドには、トークンＩＤが格納される。トークンＩＤは、トークンを識別するための情報である。トークンＩＤは、トークンの内容に対して一つ付与される番号である。例えば野球選手Ａの選手画像がトークンにおけるデジタルコンテンツとして設定されている場合、選手Ａの選手画像に対して、一つのトークンＩＤが設定されている。これに対して、後述する台帳ＩＤは、このトークンが付与される数量に対応する数量設定される。このため、一つのトークンＩＤに対して、複数の台帳ＩＤが設定される。

「トークンの内容」フィールドには、トークンＩＤに対応するトークンの内容を示す情報が挙げられる。トークンの内容を示す情報は、イベントIＤによって識別されるイベントのチケットの特典として付与されるトークンの内容を示す情報である。例えば、トークンの内容としては、「選手画像/動画」「キャラクター画像/動画」「特典音源」等が挙げられる。

「台帳ＩＤ」には、トークン管理台帳４０における管理台帳としての管理ＩＤが格納される。すなわち、「台帳ＩＤ」は、トークンの所有権ごとに設定されるＩＤである。「台帳ＩＤ」は、本実施形態ではブロックチェーンＩＤと言い換えることもできる。「台帳ＩＤ」は、トークンの所有権ごとにユニークな値が設定される。

「シリアルコードＩＤ」フィールドには、トークンの付与を受けるために入力が要求されるシリアルコードが格納される。

「ステータス」フィールドには、台帳ＩＤに対応する台帳に記録されたトークンの状態を示す情報が格納される。トークンの状態とは、トークンが既に使用されたかどうかを示す情報である。トークンの使用とは、トークンを、予め設定されている特典に引き換えることを指す。トークンを特典と引き換える際には、トークンの移転を伴ってもよいし、伴わなくてもよい。トークンの特典への引き換えについては後述する。

（３－５）トークン管理台帳４０および外部サーバ５０
図１０に示すように、トークン管理台帳４０は、外部サーバ５０に記録されたデジタルコンテンツと関連付けられている。トークン管理台帳４０は、分散管理台帳であるブロックチェーンにより実現されている。言い換えれば、トークンは分散管理台帳により管理されている。トークンは、後述する所有権の移転に伴う取引履歴を参照可能となっている。あるトークンに関する全ての取引履歴を参照することで、当該トークンの所有者を特定することができる。

ブロックチェーンは、コントラクトデータを構成するブロックと、ハッシュ値およびトランザクションデータを少なくとも含むブロックと、により構成されている。ユーザ間でのトークンの移転に伴い、新たなトランザクションデータが生成され、図６に示す信号処理装置４０Ａ～４０Ｅによる検証の後に、新たなブロックが追加される。
なお、ブロックチェーンは、パブリックなブロックチェーンとプライベートなブロックチェーンとを用い、通常の取引はプライベートなブロックチェーン上で取引履歴を記録し、定期的にパブリックなブロックチェーンに対して最新情報を反映するなど、複数階層を伴うような構成であってもよい。

（４）チケット処理
本実施形態のチケット処理について説明する。

（４－１）ユーザの登録処理
本実施形態の発券処理について説明する。図１１は、本実施形態のユーザ登録のフローチャートである。
図１１に示すように、まず、ユーザ端末１０を操作して、ユーザが氏名などの本人情報を入力して、ユーザ登録の申請を行う（ステップＳ１００）。

ステップＳ１００の後に、チケット管理サーバ２０は、ユーザ登録の申請を受け付ける（ステップＳ１０１）。
ステップＳ１０１の後に、チケット管理サーバ２０は、ユーザＩＤおよびログインパスワードを発行する（ステップＳ１０２）。この際、チケット管理サーバ２０は、ユーザから入力された本人情報と、ユーザＩＤおよびパスワードをユーザデータベースにおける新たなレコードとして記録する。

ステップＳ１０２の後に、ユーザ端末１０は、発行されたユーザＩＤおよびログインパスワードを受領する（ステップＳ１０３）。

ステップＳ１０２の後に、チケット管理サーバ２０は、ユーザ端末１０に向けて特徴量の入力を要求する（ステップＳ１０４）。具体的には、チケット管理サーバ２０は、ユーザの顔を撮影した画像の入力を要求する。

ステップＳ１０４の後に、ユーザは、ユーザ端末１０を操作して、特徴量を取得する（ステップＳ１０５）。具体的にはユーザは、ユーザ端末１０の入力デバイス１５（可視光カメラ）を用いて、自身の顔を撮影する。プロセッサ１２は、取得した画像データに対して演算を行うことで、チケットの購入者の特徴量（例えば顔の特徴量）を取得する。
ステップＳ１０５の後に、ユーザ端末１０は、取得した特徴量、すなわちユーザの顔画像をチケット管理サーバ２０に向けて送信する（ステップＳ１０６）。

ステップＳ１０６の後に、チケット管理サーバ２０は、ユーザ端末１０から送信された特徴量を受信する（ステップＳ１０７）。
ステップＳ１０７の後に、チケット管理サーバ２０は、受信した特徴量を、ユーザデータベースに登録する（ステップＳ１０８）
以上により、ユーザ登録の処理が終了する。

（４－２）発券処理
図１２は、本実施形態の発券処理のフローチャートである。

図１２に示すように、ユーザ端末１０は、購入操作の受付（Ｓ１１０）を実行する。
具体的には、プロセッサ１２は、入力デバイス１５に対してなされた購入操作を、入出力インタフェース１３を介して受け付ける。
ユーザ端末１０の操作者は、チケットの購入者に限られず、購入者の代わりにユーザ端末１０を操作する者（例えばチケット販売所の係員）であってもよい。
購入操作は、例えば、ユーザＩＤの入力、興行の選択、日時の選択、座席種別の選択、購入ボタン（ボタンオブジェクトまたは物理ボタン）の押下、またはそれらの組み合わせを含み得る。

ステップＳ１１１の後に、ユーザ端末１０は、発券の要求（Ｓ１１１）を実行する。
具体的には、プロセッサ１２は、ステップＳ１１０において受け付けた購入操作の内容と、ステップＳ１１１において取得した特徴量とを参照して発券要求を生成する。発券要求は、一例として発券を要求するチケットの種別を特定する情報（例えば、興行、日時および座席種別を特定する情報）と、チケットの購入者の特徴量およびユーザＩＤとを含む。プロセッサ１２は、通信インタフェース１４を介して、チケット管理サーバ２０へ発券要求を送信する。

ステップＳ１１１の後に、チケット管理サーバ２０は、発券処理（ステップＳ１２０）を行う。具体的には、チケット管理サーバ２０のプロセッサ２２は、ユーザ端末１０から送信された購入者の情報に基づいて、販売するチケットを割り当てる。

ステップＳ１２０の後に、チケット管理サーバ２０は、データベースの更新（Ｓ１２１）を実行する。
具体的には、プロセッサ２２は、未発行のチケットＩＤに関連付けて、発券要求に含まれるユーザＩＤと、ステップＳ１２０において特定した参照特徴ＩＤとをチケットデータベース（図８Ｃ）に新規登録する。これにより、チケットＩＤを元に、チケットの購入者と参照特徴量とを特定することが可能となる。
また、プロセッサ２２は、ユーザ端末１０から送信された購入者の特徴量を用いて、ユーザデータベース（図８Ｂ）を更新する。なお、既にユーザの特徴量が記憶されている場合には、この処理は省略してもよい。

ステップＳ１２１の後に、チケット管理サーバ２０は、チケット情報の提供（Ｓ１２２）を実行する。
具体的には、プロセッサ２２は、ステップＳ１２１におけるデータベースの更新内容を参照して、チケット情報を生成する。チケット情報は、ステップＳ１２１において新規登録したチケットＩＤを含む。さらに、チケット情報は、ステップＳ１２１において特定した参照特徴ＩＤ、およびチケット購入者のユーザＩＤの少なくとも１つを含むことができる。チケット情報に含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。プロセッサ２２は、生成したチケット情報を、チケットの購入者に提供する。一例として、プロセッサ２２は、通信インタフェース２４を介してユーザ端末１０へ送信する。

ステップＳ１２２の後に、ユーザ端末１０は、チケット情報の保存（Ｓ１１２）を実行する。
具体的には、プロセッサ１２は、ステップＳ１２２において提供されたチケット情報を取得する。プロセッサ１２は、取得したチケット情報を記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、チケット情報を表示できる。さらに、プロセッサ１２は、オプションとして、以下の少なくとも１つを実行してもよい。
・出力デバイス１６（印刷装置）に、チケット情報を紙またはその他の媒体へ印刷させる。
・通信インタフェース１４に、チケット情報をチケットの購入者のユーザ端末１０へ送信させる。

（４－３）検札処理
本実施形態の検札処理について説明する。図１３は、本実施形態の検札処理のフローチャートである。

図１３に示すように、イベント会場に来場したユーザは、ユーザ端末１０を操作して、ユーザ端末１０にチケットを表示させる（ステップＳ１１４）。
具体的には、ユーザ端末１０のプロセッサ１２が、記憶装置１１に記憶したチケット情報を表示する。

ステップＳ１１４の後に、検札システム３０は、チケットの読み取り（Ｓ１３０）を実行する。
具体的には、来場者によるチケットの提示時に、プロセッサ３２は、可視光カメラ３５２と協同して、チケット情報を読み取る（認証情報取得手段）。
ステップＳ１３０において、プロセッサ３２は、可視光カメラ３５２の撮影した画像を来場者向けに出力デバイス３６（ディスプレイ）に表示してもよい。これにより、来場者に、チケットが撮影されている様子をフィードバックし、チケットの位置や姿勢の微調整を促すことができる。

また、検札システム３０は、特徴量の取得（Ｓ１３１）を実行する。
具体的には、来場者によるチケットの提示時に、プロセッサ３２は、可視光カメラ３５２と協同して、当該来場者の特徴量（例えば顔の特徴量）を取得する。
ステップＳ１３１において、プロセッサ３２は、可視光カメラ３５２の撮影した画像を来場者向けに出力デバイス３６（ディスプレイ）に表示してもよい。これにより、来場者に、自らが撮影されている様子をフィードバックし、自らの位置や姿勢の微調整を促すことができる。

検札システム３０は、ステップＳ１３０、およびステップＳ１３１を図１３とは異なる順序で実行してもよい。一例として、検札システム３０は、これらのステップのうち複数を同時に実行してもよい。

ステップＳ１３０およびステップＳ１３１の後に、検札システム３０は、入場可否の判定（Ｓ１３２）を実行する。
具体的には、プロセッサ３２は、ステップＳ１３０において読み取ったチケット情報を参照して、来場者の入場可否を判定する。
具体的には、読み取ったチケット情報をチケットデータベースに照会し、チケット情報が入場する権限のある適切なチケット情報であるかどうかを判定する。また、この際、プロセッサ３２は、来場者とチケット所有者の同一性を確認する。すなわち、チケットデータベースに記録されたチケットの所有者ＩＤを参照し、ユーザデータベースに登録されたユーザＩＤとひもづくユーザの特徴量と、の比較を行い、チケット所有者（購入者）が来場しているかどうかを判定する。

ステップＳ１３３において、読み取ったチケット情報が適切なチケット情報ではない場合、又は来場者とチケット所有者の同一性が確認できない場合（ステップＳ１３３のＮｏ）には、検札システム３０は、入場エラー処理（Ｓ１３４）を実行する。
具体的には、プロセッサ３２は、ステップＳ１３３において来場者の入場を拒否すると判定した場合に、以下の少なくとも１つの処理を行う。
・警報の発報（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が拒否されたことを本人および係員に知覚させるとともに、係員にアフターケアを促す）
・ゲートの閉鎖（例えば、電動式のゲートのバー、またはフラップドアを閉じて来場者の入場を物理的に阻害する）
なお、検札システム３０付近の滞留を防ぐ観点から、係員によるアフターケアは、来場者を対象空間に便宜的に入場させてから行われてもよい。係員によるアフターケアは、来場者がチケットの真の購入者であるか否かを判断するためのやり取りを含むことができる。一例として、係員は、来場者の属性情報、来場者の連絡先情報、チケットの購入場所、チケットの購入時期、またはそれらの組み合わせを来場者から聞き取り、チケット情報と照合してもよい。
ステップＳ１３４の後に、図１３の検札処理は終了する。

ステップＳ１３３において、読み取ったチケット情報が適切なチケット情報であり、かつ来場者とチケット所有者の同一性が確認できた場合（ステップＳ１３３のＹｅｓ）には、検札システム３０は、入場の許可（Ｓ１３５）、いわゆる「もぎり処理」を実行する。
具体的には、プロセッサ３２は、ステップＳ１３３において来場者の入場を許可すると判定した場合に、以下の少なくとも１つの処理を行う。
・入場が許可されたことの報知（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が許可されたことを本人および係員に知覚させる）
・ゲートの開放（例えば、電動式のゲートのバー、またはフラップドアを開いて来場者の進入を促す）

プロセッサ３２は、ステップＳ１３５の際に、チェックインリストを作成、または更新してもよい。
チェックインリストは、各来場者に対する検札処理の結果一覧に関する情報である。チェックインリストは、一例として以下の要素の少なくとも１つを含む。
・チェックイン時刻
・来場者の提示したチケットのチケットＩＤ
・チケットＩＤに関連付けられるユーザＩＤ
・ユーザＩＤに関連付けられるユーザ名
・入場可否の判定（ステップＳ１３３）の結果（入場許可／入場拒否）
・対象空間においてユーザに割り当てられた区域（例えば指定席）

（４－４）トークン付与の処理
本実施形態のトークン付与の処理について説明する。図１４は、本実施形態のトークン付与の処理のフローチャートである。
トークンの付与では、まず、チケット管理サーバ２０に対して、シリアルコードの付与を申請する（ステップＳ１３９）。シリアルコードの付与の申請は、チケットが使用済みとなったことの通知（もぎり通知）とともに行われてもよい。
具体的には、検札システム３０のプロセッサ３２は、チケット所有者のユーザＩＤ、および使用されたチケットＩＤを特定し、当該ユーザに対するシリアルコードの付与の要求をチケット管理サーバ２０に送信する。

ステップＳ１３９の後に、チケット管理サーバ２０は、シリアルコードの付与申請を受領する（ステップＳ１２３）。具体的には、チケット管理サーバ２０のプロセッサ２２は、シリアルコードを付与する対象となるユーザＩＤを検札システム３から受信する。この際、チケット管理サーバ２０は、もぎられたチケットが使用済みである通知を同時に受け取る。チケット管理サーバ２０は、チケットデータベースにおける当該チケットの「ステータス」フィールドを、使用済みに変更する。

ステップＳ１２３の後に、チケット管理サーバ２０は、シリアルコードをユーザ端末１０に対して付与する（ステップＳ１２４）。具体的には、チケット管理サーバ２０のプロセッサ２２は、チケットデータベースを参照し、付与すべきトークンおよび付与すべきトークンに設定されたシリアルコードを特定する。プロセッサ２２は、特定したシリアルコードを、付与すべきユーザが使用するユーザ端末１０に対して送信する。

ステップＳ１２４の後に、ユーザ端末１０は、シリアルコードを受領する（ステップＳ１１５）。具体的には、ユーザ端末１０のプロセッサ１２は、付与されるトークンに対応するシリアルコードをチケット管理サーバ２０から受信する。なお、シリアルコードの付与は、例えば電子チケットの券面にシリアルコードを記載する態様であってもよい。つまり、電子チケットの券面が、シリアルコードを含むように書き換えられてもよい。

ステップＳ１１５の後に、ユーザは、ユーザ端末１０を操作して、外部サーバ５０にログインする（ステップＳ１１６）。具体的には、ユーザは、ユーザ端末１０を操作して、外部サーバログインＩＤおよび外部サーバログインＰＡＳＳを入力することで、外部サーバ５０にログインする。

ステップＳ１１６の後に、外部サーバ５０から出力された入力フォームに、シリアルコードを入力する（ステップＳ１１７）。

ステップＳ１１７の後に、ユーザ端末１０は、外部サーバ５０にシリアルコードを送信する。ユーザ端末１０のプロセッサ１２は、ユーザから入力されたシリアルコードをチケット管理サーバ２０に送信する。これにより、トークンの付与申請が行われる。

ステップＳ１１７の後に、外部サーバ５０は、シリアルコードを受領する（ステップＳ１５１）。この際、外部サーバ５０は、自身が保有するトークンデータベースを参照して、入力されたシリアルコードの照会を行う。

ステップＳ１５１において、シリアルコードが適切なコードである場合には、外部サーバ５０は、トークン管理台帳４０に向けて、トークン所有者の登録指示を送信する（ステップＳ１５２）。この際、外部サーバ５０は、アカウントデータベースを参照して、外部サーバログインＩＤに対応する管理台帳ログインＩＤおよび管理台帳ＰＡＳＳを参照し、これらの情報を用いてトークン管理台帳４０にアクセスし、管理台帳の書き換えを指示する。外部サーバＩＤは、シリアルコードに紐づいた台帳ＩＤの情報を書き換えの指示においてトークン管理台帳４０に送信する。

ステップＳ１５２の後に、トークン管理台帳４０は、トークンの所有者を登録する。この際、トークン管理台帳４０は、外部サーバ５０から入力された台帳ＩＤにより記録するべき台帳を特定し、外部サーバ５０から入力された管理台帳ログインＩＤにより、ユーザを特定する。これにより、ブロックチェーン上に新たなトランザクションデータとして、台帳ログインＩＤが記録されたブロックを追加する。
これにより、トークンの所有者が明確にされる。言い換えれば、この処理により、トークンがイベント会場に来場したユーザに付与される。
以上により、トークンの付与の処理が終了する。

（５）その他の機能
次に、チケットシステム１のその他の機能について説明する。
チケット管理サーバ２０は、トークンを所有するユーザに対して、トークンを引換券として、特典を提供する。特典とは、例えば、将来のイベントのチケットや特別な割引券、優先的なチケット購入権限、グッズである。このようなトークンを引換券とした特典として提供されるチケット（特典チケット）の引換処理について説明する。なお、特典チケットは、一般のチケットの一部が割り当てられる。すなわち、イベントのチケットの一部が、以下に示す引換処理により、ユーザに特典として提供される。

特典チケットは、トークンが付与されたチケットのイベントから一定の期間（例えば数か月や数年）の経過後に主催されるイベントのチケットである。この間に、ユーザはトークンを他のユーザに譲渡することができる。すなわち、チケットシステム１は、トークンを付与された所有者からの指示に応じて、トークンの所有者を、他のユーザに変更する。この際、外部サーバ５０を介して、トークン管理台帳４０の記録が書き換えられる。

図１５は、チケット管理サーバ２０が記憶する特典チケットデータベース、および外部サーバ５０が記憶する引換コードデータベースのデータ構造の一例を示す図である。これらのデータベースは、例えば、特典チケットが使用されるイベントの開催が近付いたタイミングで生成される。

図１５Ａは、チケット管理サーバ２０が記憶する特典チケットデータベースのデータ構造の一例を示す図である。
図１５Ａに示すように、特典チケットデータベースは、「チケットＩＤ」フィールドと、「イベントＩＤ」フィールドと、「座席番号」フィールドと、「引換コード」フィールドと、「所有者ＩＤ」フィールドと、「ステータス」フィールドと、を含む。

「チケットＩＤ」フィールドには、引換券と交換される特典である、チケットのＩＤが格納される。この説明では、特典チケットと称しているが、特典チケットは、一般チケットの一部が特典用のチケットとして割り当てられるような設計としてもよい。

「イベントＩＤ」フィールドには、チケットＩＤに対応するイベントのＩＤが格納される。この説明では、特典となるイベントのＩＤが格納される。

「座席番号」フィールドには、チケットＩＤに対応する特典チケットの座席番号が格納される。

「引換コード」フィールドには、ユーザが、チケットのＩＤに対応する特典チケットを引き換える際に、入力が要求される引換コードに関する情報が格納される。

「所有者ＩＤ」フィールドには、チケットＩＤに対応する特典チケットの所有者のユーザＩＤが格納される。

「ステータス」フィールドには、チケットＩＤに対応する特典チケットの状態が格納される。特典チケットの状態としては、「引き換え前」、「使用前」、「使用済」がある。ステータスが「引き換え前」とは、未だに特典チケットの引換が行われていない状態を指す。ステータスが「使用前」とは、特典チケットが使用されていない状態、すなわち、当該イベント会場に、特典チケットの所有者が来場していない状態を指す。ステータスが「使用済」とは、特典チケットが使用された状態、すなわち、当該イベント会場に特典チケットの所有者が来場し、もぎりが実行されたことを指す。

図１５Ｂは、外部サーバ５０が記憶する引換コードデータベースのデータ構造の一例を示す図である。
図１５Ｂに示すように、特典チケットデータベースは、「台帳ＩＤ」フィールドと、「トークンＩＤ」フィールドと、「トークンの内容」フィールドと、「引換コード」と、を含む。

「台帳ＩＤ」フィールドには、トークン管理台帳４０におけるトークンの管理ＩＤが格納される。

「トークンＩＤ」フィールドには、トークンの種別を管理するためのトークンＩＤが格納される。

「トークンの内容」フィールドには、台帳ＩＤと対応する台帳において所有権が管理されるトークンの内容が格納される。実際には、この図に示す「将来のチケット引換券」に代えて、「ｙｙｍｍｄｄ（日付）に開催予定の武道館ライブの引換券」や、「令和※年に開催予定の全国ツアー大阪公演の引換券」などというような具体的なイベント名称が格納される。或いは、「10周年ライブの優先購入権」「武道館ライブの引換券」「XX事務所が主催するどのライブでも1回だけ優先購入できる権利」「特別グッズの優先購入権」など、範囲に柔軟性を持った引換券としてもよい

「引換コード」フィールドには、ユーザが、チケットのＩＤに対応する特典チケットを引き換える際に、入力が要求される引換コードに関する情報が格納される。言い換えれば、トークンを引換券として特典チケットを取得する際のユーザの権能を示す情報が格納される。

次に、特典チケットをユーザが引き換える処理について説明する。図１６は、特典チケットをユーザが引き換える処理のフローチャートである。
図１６に示すように、特典チケットをユーザが引き換える処理では、まず、チケット管理サーバ２０が、特典チケットを発行する（ステップＳ２２１）。特典チケットの発行は、例えば将来のイベントの開催が具体的に決定したタイミングで行われる。

この際、チケット管理サーバ２０には、特典チケットデータベースが作成される。この時点において、特典チケットデータベースにおける「引換コード」フィールド、および所有者ＩＤ」フィールドは空欄となっている。また、この時点において、図１５Ａに示す特典チケットデータベースにおける「ステータス」フィールドは、全て「引き換え前」となっている。

図１６に示すように、ステップＳ２２１の後に、チケット管理サーバ２０は、外部サーバ５０に対して、特典チケットの発行通知を行う（ステップＳ２２２）。具体的には、チケット管理サーバ２０のプロセッサ２２は、特典チケットの発行が行われた旨を、外部サーバ５０に出力する。

ステップＳ２２２の後に、外部サーバ５０は、引換コードの発行を行う（ステップＳ２５１）。具体的には、外部サーバ５０は、チケット管理サーバ２０からの特典チケットの発行通知を受けて、図１５Ｂに示す引換コードデータベースを作成する。この際、台帳ＩＤに対して、引換コードを割り当てるように作成する。

図１６に示すステップＳ２５１の後に、外部サーバ５０は、チケット管理サーバ２０およびユーザ端末１０に対して、引換コードの発行通知を行う（ステップＳ２５２）。具体的には、外部サーバ５０は、チケット管理サーバ２０に対して、引換コードを通知する。これにより、チケット管理サーバ２０は、特典チケットデータベースにおける特典チケットのチケットＩＤに対して、引換コードを割り当てる。これにより、図１５Ａに示す特典チケットデータベースにおける「特典コード」フィールドに、特典コードが記録される。これにより、引換コードが、特典チケットデータベースにおける座席番号に対応するように割り振られる。なお、後述する引換コードの入力や受付終了をトリガーとして、引換コードに対して座席番号を割り振ってもよい。また、引換コードの入力時に、例えば先着順にユーザが座席番号を選択できるようにしてもよい。また、引き換えコードを受け付ける受付期限を設定し、受付期限の経過後に、まとめて抽選を行って引き換え対象のチケットを割り振っても良い。

また、図１６に示すステップＳ２５２において、外部サーバ５０は、ユーザ端末１０に対して、引換コードが発行された旨、およびユーザに対応する引換コードを通知する。具体的には、外部サーバ５０は、台帳ＩＤにおいてトークンの所有者と記録されているユーザに対して、当該台帳ＩＤと対応する引換コードを通知する。これにより、ユーザは、特典チケットの引換を行えるようになる。
引換コードの通知は、外部サーバ５０が管理するアカウント情報データベース（図９Ａ参照）に記載されたユーザの連絡先（例えばメールアドレス）に連絡することで行われる。また、引換コードは、ユーザが、外部サーバ５０に外部サーバログインＩＤおよび外部サーバログインＰＡＳＳを用いてログインすることで、ユーザ端末１０に表示されてもよい。
また、引換コードの管理の方法として、トークン管理台帳４０で管理される台帳（ブロックチェーン）上に、引換コードを記載してもよい。

ステップＳ２５２の後に、ユーザは、ユーザ端末１０に対して通知された引換コードを入力する（ステップＳ２１１）。具体的には、ユーザが、ユーザ端末１０を操作してチケット管理サーバ２０にログインし、通知された引換コードを入力する。これにより、特典チケットの引換の申請が行われる。

ステップＳ２１１の後に、チケット管理サーバ２０は、ユーザから入力された引換コードを確認する（ステップＳ２２３）。具体的には、チケット管理サーバ２０のプロセッサ２２は、特典コードが適正な内容かどうかを、特典チケットデータベースを参照して確認する。

ステップＳ２２３の後に、チケット管理サーバ２０は、特典チケット情報を提供する（ステップＳ２２４）。具体的には、プロセッサ２２は、ユーザから入力された特典コードが適正である場合に、特典チケットデータベースにおける、対応する特典チケットの「所有者ＩＤ」フィールドに、当該ユーザのユーザＩＤを記録する。これにより、特典チケットの所有者が、特典チケットデータベースに記録される。またこの際、特典チケットデータベースにおける「ステータス」フィールドが、「引き換え前」から「使用前」に書き換えられる。
そして、プロセッサ２２は、特典チケットに関する情報（特典チケット情報）を生成してユーザ端末１０に提供する。特典チケット情報に含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。

ステップＳ２２４の後に、ユーザ端末１０は、特典チケット情報の保存（Ｓ２１２）を実行する。
具体的には、ユーザ端末１０のプロセッサ１２は、ステップＳ２２４において提供された特典チケット情報を取得する。プロセッサ１２は、取得した特典チケット情報を記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、特典チケット情報を表示できる。以上により、特典チケットの引換処理が終了する。

なお、上記の説明では、引換コードを、外部サーバ５０が管理する例を示したが、この態様に限られない。例えば、引換コードは、トークン管理台帳４０が管理する各台帳（ブロックチェーン）上で管理されてもよい。この場合には、引き換え処理を、トークンの所有権の移転により行ってもよい。すなわち、トークンの所有者を示す情報を、ユーザから興行主にブロックチェーン上で書き換えることにより、引き換え権利の消込をおこなってもよい。その際は、ユーザは特典引換の申込を引換コードの入力ではなく、興行主に対するトークンの送付（ブロックチェーンの移転）によって行ってもよい。

また、特典チケットを管理するチケット管理サーバ２０は、トークンの付与におけるシリアルコードを管理したチケット管理サーバ２０とは異なるサーバにより実現されてもよい。最初のイベントの開催時期から、将来のイベントの開催時期までの期間を考慮すると、異なるサーバを用いる方が有用かつ現実的であるためである。

また、特典チケットの使用により、再度新たなトークンをユーザに対して付与してもよい。この場合には、図１５Ａに示すチケットデータベースにおいて、トークンＩＤとシリアルコードが管理され、前述したチケットの使用からトークン付与の処理が、特典チケットの使用後に行われることとなる。

また、特典チケットは紙のチケットであってもよいし、トークンを引換券として付与される特典は、有体物であってもよい。例えば特典は、数量限定のオフィシャルグッズ（サイン等）のような希少性の高いアイテムである。すなわち、トークンの所有者は、所定のイベントに参加したことが証明される。そして、イベント参加の返礼として、電子チケットのようなデジタル情報ではない現物での特典の提供を行う。

また、チケット管理サーバ２０は、トークンの所有状態が予め設定された所定の条件を満たす場合に、追加トークンを付与する。追加トークンとは、例えばツアー公演のように所定のシリーズとして設定されたイベントに全て参加して、該当するトークンを全て所有したものに対して追加で付与されるトークンである。追加トークンを所有することは、所定のシリーズのイベントに全て参加したことの証明となる。このため、追加トークンは、ファン（ユーザ）の収集意欲に訴求する。

（６）画面例
次に、チケットシステム１におけるユーザ端末１０での画面例について説明する。図１７は、第１画面例および第２画面例を示す図である。図１７Ａに示す第１画面例は、チケットを購入する際（図１２におけるステップＳ１１０）の画面例である。
図１７Ａに示すように、チケットを購入する際には、イベント内容、購入対象物、および価格が表示されている。ユーザは個数を入力し、購入申請を行うことで、購入が行われる。

図１７Ｂに示す第２画面例は、発券が完了し、チケット情報を保存する際（図１２におけるステップＳ１１３）の画面例である。
図１７Ｂに示すように、チケット情報を保存する際には、購入したチケットの内容がユーザ端末１０に表示される。これにより、購入が適切に行われたことをユーザが確認できる。

図１８は、第３画面例および第４画面例を示す図である。図１８Ａに示す第３画面例は、トークンの付与を申請するためのシリアルコードを受領した際（図１４におけるステップＳ１１５）の画面例である。
図１８Ａに示すように、シリアルコードを受領すると、シリアルコードがユーザ端末１０に表示される。
なお、シリアルコードの送付は、例えばユーザ登録において登録されたメールアドレスや、電話番号へのＳＭＳにより送付してもよい。また、シリアルコードの送付は、チケット管理サーバ２０にユーザがログインした際に表示されるマイページ上に表示してもよい。

また、シリアルコードの送付は、シリアルコードの番号が記載された新たなチケットを発券する処理により行われてもよい。すなわち、シリアルコードの発行に際して、シリアルコードチケットとしてのチケットＩＤを付与し、チケットデータベースに新たなレコードとして記録してもよい。これにより、受領したシリアルコード自体が「チケット」と同様に流通可能となり、例えばユーザ間での取引の対象なることで、汎用性を高めることができる。

また、シリアルコードチケットの発券に際して、シリアルコードを直接表示するのではなく、入場チケットと同様に利用ボタンをタップするなど、「もぎり」処理と対応する動作を実行させてもよい。これにより、チケット自体が「使用済」となった際にのみシリアルコードを表示できるようにすることで、シリアルコードが「未使用」であることを担保することができる。

図１８Ｂに示す第４画面例は、トークンの付与を受けるために、所定のフォーム画面に遷移する前に表示されるログイン要求画面例である。ユーザがログインＩＤおよびパスワードを入力してログインすることで、シリアルコードを入力するための所定のフォーム画面が表示される。

図１９は、第５画面例および第６画面例を示す図である。図１９Ａに示す第５画面例は、シリアルコードの入力を行う際（図１４におけるステップＳ１１６）の画面例である。
図１９Ａに示すように、ユーザは、表示された所定の入力欄に、シリアルコードを入力し、実行ボタンをクリックする。

図１９Ｂに示す第６画面例は、トークンの所有者が記録された際（ステップＳ１２５）の画面例である。
図１９Ｂに示すように、トークンの所有者が記録されると、シリアルコードを入力したユーザに対して、その旨が表示され、トークンを構成するデジタルコンテンツとしての特典画像（この例ではプロ野球選手の画像）が表示される。

（７）効果
以上説明したように、チケットシステム１では、実際にチケットを使用したこと（＝イベント会場への来場、またはオンラインでのイベント視聴）により、使用者に対して特典となるコンテンツデータを提供することができる。このため、特典を得るためにチケットを購入して特典を得たのちに、チケットを転売するということができず、実際にチケットを使用してイベントに参加する必要がある。これにより、イベントへの参加の動機付けを効果的に行うことができる。

また、チケットの購入者と使用者の同一性を確認するので、トークンの付与を目的としたチケットの買い占めおよび転売行為を効果的に防止することができる。

また、チケットの所有者の顔を撮影した画像を用いて、チケットの所有者と使用者の同一性を確認するので、他人になりすまして使用するといったことが行いにくく、確認結果の精度を確保することができる。

また、トークンの所有者に対して識別子を発行した後に、識別子の入力を受け付けてトークンを付与するので、他人によるトークンの不正取得を効果的に防止することができる。

また、トークンをユーザ同士が個別に取引の対象とすることができるので、トークンの収集意欲を向上することができる。

また、トークンを所有する人に、イベントのチケット等の特典を提供することにより、トークンの価値をさらに高めることができる。

また、トークンの所有状態が所定の条件を満たす場合に、追加トークンを付与するので、トークンの収集意欲、ひいてはイベントへの参加意欲を一層効果的に向上することができる。

（８）変形例
本実施形態の変形例について説明する。
（８－１）変形例１
変形例１では、トークンとしてのコンテンツデータが前述した実施形態と異なっている。図２０は、コンテンツデータの他の構造例を示す図である。
図２０に示すように、変形例に係るコンテンツデータは、ブロックチェーンの一部として組み込まれている。この場合には、トークンおよびトークン管理台帳４０としての情報が、ブロックチェーンとして分散管理台帳に記録されていることとなる。

（８－２）変形例２
変形例２では、シリアルコードを付与することなく、トークンを付与する例を説明する。図２１は、変形例２に係るトークン付与の処理を説明する図である。この変形例では、ユーザデータベースにおいて、外部サーバ５０のユーザＩＤが記憶されている。なお、検札処理までのフローは実施形態と同様であり、その説明を省略する。

図２１に示すように、検札システム３０は、もぎり通知処理を実行する（ステップＳ１３９Ｂ）。具体的には、検札システム３０は、チケットが使用済みとなったことをチケット管理サーバ２０に送信する。

ステップＳ１３９Ｂの後に、チケット管理サーバ２０は、もぎり通知を受領する（ステップＳ１２５）。この際、チケット管理サーバ２０は、もぎり通知に基づき、当該チケットについてチケットデータベースの「ステータス」フィールドを使用済みに更新する。

ステップＳ１２５の後に、チケット管理サーバ２０は、トークン付与指示を実行する。（ステップＳ１２６）この際、チケット管理サーバ２０は、当該チケットに紐づいたトークンＩＤと、当該チケットの所有者であるユーザと紐づいた、外部サーバ５０におけるログインＩＤを用いて、トークン付与指示を外部サーバ５０に向けて送信する。

ステップＳ１２６の後に、外部サーバ５０は、トークン付与指示を受領する（ステップＳ１５３）。
ステップＳ１５３の後に、外部サーバ５０は、トークン管理台帳４０に向けて、トークン所有者の登録指示を送信する（ステップＳ１５４）。この際、外部サーバ５０は、アカウント情報データベースを参照して、外部サーバ５０におけるログインＩＤと対応する管理台帳ログインＩＤおよび管理台帳ＰＡＳＳを参照する。そして、外部サーバ５０は、トークン管理台帳４０にログインし、トークンＩＤにユーザを登録する旨の指示を出す。

ステップＳ１５２の後に、トークン管理台帳４０は、トークンの所有者を登録する。この際、トークン管理台帳４０は、ブロックチェーン上に新たなトランザクションデータとして、外部サーバ５０のユーザＩＤが記録されたブロックを追加する。
これにより、トークンの所有者が明確にされる。言い換えれば、この処理により、トークンがイベント会場に来場したユーザに付与される。
以上により、トークンの付与の処理が終了する。

（９）その他の変形例
記憶装置１１は、ネットワークＮＷを介して、ユーザ端末１０と接続されてもよい。記憶装置２１は、ネットワークＮＷを介して、チケット管理サーバ２０と接続されてもよい。記憶装置３１は、ネットワークＮＷを介して、検札システム３０と接続されてもよい。

上記の検札処理は、図１３のように検札システム３０が単独で行ってもよいし、検札システム３０と他の装置（例えばチケット管理サーバ２０）とが協同して行ってもよい。

実施形態では、チケットの所有者とチケットの使用者（来場者）の同一性を確認したうえで、同一性が確認された際に、チケットの所有者に対してトークンを付与する構成を説明した。しかしながら、チケットシステム１は、チケットの所有者とチケットの使用者（来場者）の同一性を確認することなく、チケットの検札システム３０によるもぎり処理が行われた後、一定時間の経過後に、所有者に対して一律にトークンの付与を行ってもよい。また、管理者がトークン付与に関する指示をチケット管理サーバ２０に対して行うことで、トークンの付与が行われてもよい。
また、チケットの所有者と、来場者の同一性の確認は、入場可否の判定（ステップＳ１３２）では行わずに、シリアルコードの付与申請（ステップＳ１３９）の前のタイミングで行ってもよい。

また、チケットの所有者と、来場者の同一性の確認は、チケット情報へのアクセスの際に要求される本人認証により行ってもよい。具体的には、ユーザがチケット情報を表示させる際に入力するアカウント情報、ＳＭＳ認証、端末ＩＤ認証などにより、チケットの所有者と、来場者の同一性の確認を行ってもよい。

実施形態では、使用者がイベント会場に来場する態様について説明した。しかしながら、例えばイベントがオンラインイベントの場合には、使用者がユーザ端末１０に表示される視聴ボタンを押下することで、図１３に示すチケットの表示処理（ステップＳ１１４）が実行される。
すなわち、チケットが、情報通信を介して提供されるイベントに関するものである場合には、チケットを用いてユーザが情報通信の提供を受けることをチケットの使用と呼び、チケットの使用の検出は、情報通信の提供の開始により実行される。

また、検札システム３０は、入場可否の判定（図１３に示すステップＳ１３２）に代えて、視聴可否の判定を行う。この場合には、検札システム３０の可視光カメラ３５２に代えて、ユーザ端末１０により撮影した視聴者の顔写真を検札システム３０に送信するという処理を行ってもよい。

実施形態では、顔の特徴量を用いて来場者の入場の可否を判定する例を説明したが、顔の特徴量に代えて他のバイオメトリクス（例えば、指紋、掌紋、虹彩、静脈、筋電位など）に関する特徴量を用いて来場者の入場の可否を判定してもよい。
また、赤外線、RFID、音波、レーザ型の一次元バーコードリーダー等のその他のセンサにより、ユーザ固有の情報を取得してもよい。
また、複数種類の特徴量を用いて来場者の入場の可否を判定してもよい。

実施形態では、ユーザ登録の際に特徴量を取得する処理について説明したが、特徴量を取得するタイミングについては、この限りではない。例えば、チケット発券後に、ユーザ端末１０に表示されたチケット券面から特徴量の入力を行う画面に遷移する処理を行ってもよい。
また、チケット購入後、チケットの発券前に、ユーザ端末１０により取得した特徴量の入力を行ってもよい。

実施形態では、トークン管理台帳４０として、ブロックチェーンを利用する構成を示したが、このような態様に限られない。すなわち、トークン管理台帳４０は、トークンの管理に必要なカラムにより構成されるデータベースであってもよい。

実施形態では、チケットが、認証情報を担う認証情報担体である例を示した。しかしながら、認証情報担体は、来場者の生体であってもよい。具体的には、認証情報担体は、来場者の顔、または来場者の掌であってもよい。かかる認証情報担体は、来場者の特徴量に関する情報を認証情報として保持している。この場合に、検札システム３０は、来場者の特徴量を取得し、当該特徴量を手掛かりとして当該来場者の購入したチケットを識別するチケットＩＤを特定可能である。すなわち、チケットデータベースは、チケットＩＤに代えて、購入したユーザの生体情報（その特徴量を含む）を記憶することとなる。

実施形態では、チケット管理サーバ２０が、チケット情報をユーザ端末１０に送信する例を示した。しかしながら、チケット管理サーバ２０は、チケット情報の代わりに、当該チケット情報の保存されたリソースを参照するためのリソース情報（例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ））をユーザ端末１０へ送信してもよい。来場者は、自らのユーザ端末１０によってリソース情報の示すリソースにアクセスすることで、当該ユーザ端末１０のディスプレイにチケット情報を表示させることができる。

実施形態では、チケットの購入時に購入者の特徴量をチケット管理サーバ２０へ送信する例を示した。しかしながら、購入者の特徴量は、チケットの購入後にチケット管理サーバ２０へ送信されてもよい。これにより、複数の来場者のためのチケットを一括購入することが可能となる。なお、来場者の特徴量をチケット管理サーバ２０へ送信するための期限を定めておき、期限内に特徴量が登録されたチケットが提示された場合と、そうでないチケットが提示された場合とで、検札処理の内容が異なってもよい。

実施形態では、チケット情報に含まれる情報の一部または全部は例えばＱＲコード（登録商標）を含む二次元コード、または他のコード情報に符号化される例を示した。一例として、チケットは、チケットＩＤと参照用文字列とがＱＲコード（登録商標）を含むことができる。
チケット管理サーバ２０のプロセッサ２２は、発券処理時に、例えば、チケットＩＤ、イベントＩＤ（チケットの対象となるイベントを識別する情報）、およびチケットの購入者の顔の特徴量とを引数として所定の関数の演算を行うことで、参照用文字列を生成する。
検札システム３０の記憶装置３１には、検札の対象となる興行に対応する興行ＩＤと上記関数とが保存されている。検札システム３０のプロセッサ３２は、検札処理時に、チケットから読み取ったチケットＩＤと、記憶装置３１から読み出した興行ＩＤと、チケット使用者の顔の特徴量とを引数として、記憶装置３１から読み出した関数の演算を行うことで、認証対象文字列を生成する。検札システム３０は、チケットから読み取った参照用文字列を認証対象文字列と比較することで、チケットの使用者と所有者の同一性を判定する。
この例によれば、検札システム３０の記憶装置３１にユーザの個人的な情報を保存することなく、チケットの不正転売を抑制することができる。

実施形態では、シリアルコードの付与は、チケット管理サーバ２０から行われる処理について説明したが、この限りではない。
例えば、ユーザ端末１０内に事前にダウンロードされたチケットデータのなかにシリアルコードが非表示の状態で記載されており、検札システム３０によるもぎりが実行されたことをトリガーとして、ユーザ端末１０内でシリアルコードを表示させる処理をおこなってもよい。

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態および変形例は、組合せ可能、またはその一部を省略可能である。

（７）付記
実施形態および変形例で説明した事項を、以下に付記する。

（付記１）
コンピュータのプロセッサに、
チケットの使用を検出するステップ（ステップＳ１３５）と、
チケットの使用の検出に応じて、チケットの所有者に対して、所有権が明確化可能なトークンを付与するステップ（ステップＳ１４１）と、を実行させるプログラム。

（付記２）
チケットの使用を検出するステップ（ステップＳ１３５）は、
チケットの使用者がチケットに関するイベントが開催されるイベント会場において入場が許可されたことを検出することによりチケットの使用を検出する、（付記１）に記載のプログラム。

（付記３）
チケットの使用を検出するステップ（ステップＳ１３５）は、
チケットの使用者がチケットに関する映像または音声のオンライン視聴を開始したことを検出することによりチケットの使用を検出する、（付記１）に記載のプログラム。

（付記４）
トークンを付与するステップ（ステップＳ１４１）では、
チケットの使用者と、チケットの所有者と、の同一性が確認された際に、チケットの所有者に対して、トークンを付与する、（付記１）から（付記３）のいずれかに記載のプログラム。

（付記５）
トークンを付与するステップ（ステップＳ１３５）では、
チケットの情報へのアクセスの際に要求される本人認証により、使用者と、所有者と、の同一性を確認し、
両者の同一性が確認された際に、チケットの所有者に対して、トークンを付与する、（付記４）に記載のプログラム。

（付記６）
トークンを付与するステップ（ステップＳ１３５）では、
予め保存されている所有者の顔画像とチケットの使用時に撮影された使用者の顔画像とを用いて、使用者と、所有者と、の同一性を確認し、
両者の同一性が確認された際に、チケットの所有者に対して、トークンを付与する、（付記４）に記載のプログラム。

（付記７）
トークンを付与するステップ（ステップＳ１３５）では、
チケットの所有者に対して識別子を送信するステップ（ステップＳ１２４）と、
所有者からの識別子の入力を受け付けるステップ（ステップＳ１５１）と、を実行させる、（付記１）から（付記６）のいずれかに記載のプログラム。

（付記８）
トークンを付与するステップ（ステップＳ１４１）では、
チケットの券面に対して、識別子を記載するステップ（ステップＳ１２４）を実行する、（付記７）に記載のプログラム。

（付記９）
トークンを付与するステップ（ステップＳ１４１）では、
チケットの情報を管理するサーバにおけるユーザＩＤと紐づいた、トークンを管理するサーバ５０におけるユーザＩＤを用いて、チケットの使用に伴って、トークンを管理するサーバに対して、トークンの所有者を登録する、（付記１）から（付記８）に記載のプログラム。

（付記１０）
プロセッサに、
トークンを付与された所有者からの指示に応じて、トークンの所有者を、他のユーザに変更するステップを実行させる、（付記１）から（付記９）のいずれかに記載のプログラム。

（付記１１）
プロセッサに、
トークンを所有するユーザを特定するステップと、
トークンを引換券として、トークンを所有するユーザに対して、特典を提供するステップ（ステップＳ２２４）と、を実行させる、（付記１）から（付記１０）のいずれかに記載のプログラム。

（付記１２）
プロセッサに、
トークンの所有状態が所定の条件を満たすユーザを特定するステップと、
トークンの所有状態が所定の条件を満たすユーザに、追加トークンを付与する処理を実行させる、（付記１）から（付記１１）のいずれかに記載のプログラム。

（付記１３）
コンピュータのプロセッサが、
チケットの使用を検出するステップ（ステップＳ１３５）と、
チケットの使用の検出に応じて、チケットの所有者に対して、所有権が明確化可能なトークンを付与するステップ（ステップＳ１４１）と、を実行する方法。

（付記１４）
プロセッサを備え、
チケットの使用を検出する第１手段３０と、
チケットの使用の検出に応じて、チケットの所有者に対して、所有権が明確化可能なトークンを付与する第２手段４０と、を備えるシステム。

（付記１５）
トークンは、取引履歴を参照可能な管理台帳に関連付けられる、（付記１４）に記載のシステム。

（付記１６）
トークンは、分散管理台帳により管理される、（付記１４）又は（付記１５）に記載のシステム。

１ ：チケットシステム１
１０ ：チケット購入端末
１１ ：記憶装置
１２ ：プロセッサ
１３ ：入出力インタフェース
１４ ：通信インタフェース
１５ ：入力デバイス
１６ ：出力デバイス
２０ ：チケット管理サーバ
２１ ：記憶装置
２２ ：プロセッサ
２３ ：入出力インタフェース
２４ ：通信インタフェース
２５ ：入力デバイス
２６ ：出力デバイス
３０ ：検札システム
３１ ：記憶装置
３２ ：プロセッサ
３３ ：入出力インタフェース
３４ ：通信インタフェース
３５ ：入力デバイス
３６ ：出力デバイス
３５２ ：可視光カメラ

Claims (13)

1. 電子チケットに関するチケットシステムに処理を実行させるプログラムであって、
   前記チケットシステムは、
   ユーザが前記電子チケットを使用するユーザ端末と、
   前記電子チケットを管理するチケット管理サーバと、
   前記電子チケットの使用を検出する検札システムと、
   前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
   前記検札システムのプロセッサに、
   前記電子チケットの使用を検出するステップを実行させ、
   前記チケット管理サーバのプロセッサに、
   前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者として登録された連絡先に対して送信するステップを実行させ、
   前記ユーザ端末のプロセッサに、
   受信した前記識別子を表示させるステップと、
   表示された前記識別子の入力を受け付けるステップと、を実行させ、
   前記非代替性トークンを管理するサーバのプロセッサに、
   入力された前記識別子の照会を行うステップと、
   入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録させることで、前記非代替性トークンを前記電子チケットの所有者に付与するステップと、を実行させるプログラム。
2. 電子チケットに関するチケットシステムに処理を実行させるプログラムであって、
   前記チケットシステムは、
   ユーザが前記電子チケットを使用するユーザ端末と、
   前記電子チケットを管理するチケット管理サーバと、
   前記電子チケットの使用を検出する検札システムと、
   前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
   前記検札システムのプロセッサに、
   前記電子チケットの使用を検出するステップを実行させ、
   前記チケット管理サーバのプロセッサに、
   前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者が使用する前記ユーザ端末に対して送信するステップを実行させ、
   前記ユーザ端末のプロセッサに、
   受信した前記識別子が表示されるように、既に表示された前記電子チケットの券面を書き換えさせるステップと、
   表示された前記識別子の入力を受け付けるステップと、を実行させ、
   前記非代替性トークンを管理するサーバのプロセッサに、
   入力された前記識別子の照会を行うステップと、
   入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録させることで、前記非代替性トークンを前記電子チケットの所有者に付与するステップと、を実行させるプログラム。
3. 前記非代替性トークンを前記電子チケットの所有者に付与するステップでは、
   前記電子チケットの使用者と、前記電子チケットの所有者と、の同一性が確認された際に、前記電子チケットの所有者に対して、前記非代替性トークンを付与する、請求項１又は２に記載のプログラム。
4. 前記非代替性トークンを前記電子チケットの所有者に付与するステップでは、
   前記電子チケットの情報へのアクセスの際に要求される本人認証により、前記使用者と、前記所有者と、の同一性を確認し、
   両者の同一性が確認された際に、前記電子チケットの所有者に対して、前記非代替性トークンを付与する、請求項３に記載のプログラム。
5. 前記非代替性トークンを前記電子チケットの所有者に付与するステップでは、
   予め保存されている前記所有者の顔画像と前記電子チケットの使用時に撮影された前記使用者の顔画像とを用いて、前記使用者と、前記所有者と、の同一性を確認し、
   両者の同一性が確認された際に、前記電子チケットの所有者に対して、前記非代替性トークンを付与する、請求項４に記載のプログラム。
6. 前記非代替性トークンを前記電子チケットの所有者に付与するステップでは、
   前記電子チケットの情報を管理するサーバにおけるユーザＩＤと紐づいた、前記非代替性トークンを管理するサーバにおけるユーザＩＤを用いて、前記電子チケットの使用に伴って、前記非代替性トークンを管理するサーバに対して、前記非代替性トークンの所有者を登録する、請求項１から５のいずれか１項に記載のプログラム。
7. 前記プロセッサに、
   前記非代替性トークンを付与された所有者からの指示に応じて、前記非代替性トークンの所有者として、他のユーザの情報を登録することで、前記非代替性トークンの所有者を、他のユーザに変更するステップを実行させる、請求項１から６のいずれか１項に記載のプログラム。
8. 前記プロセッサに、
   前記非代替性トークンを所有するユーザを特定するステップと、
   前記非代替性トークンを引換券として、前記非代替性トークンを所有するユーザに対して、特典を提供するステップと、
   前記特典を提供した際に、前記非代替性トークンの所有者情報を前記分散管理台帳において書き加えることで、前記特典の引き換えの消込を行うステップと、を実行させる、請求項１から７のいずれか１項に記載のプログラム。
9. 前記プロセッサに、
   前記非代替性トークンの所有状態が所定の条件を満たすユーザを特定するステップと、
   前記非代替性トークンの所有状態が前記所定の条件を満たすユーザに、追加トークンを付与する処理を実行させる、請求項１から８のいずれか１項に記載のプログラム。
10. 電子チケットに関するチケットシステムに処理を実行させる方法であって、
    前記チケットシステムは、
    ユーザが前記電子チケットを使用するユーザ端末と、
    前記電子チケットを管理するチケット管理サーバと、
    前記電子チケットの使用を検出する検札システムと、
    前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
    前記検札システムのプロセッサが、
    前記電子チケットの使用を検出するステップを実行し、
    前記チケット管理サーバのプロセッサが、
    前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者として登録された連絡先に対して送信するステップを実行し、
    前記ユーザ端末のプロセッサが、
    受信した前記識別子を表示するステップと、
    表示された前記識別子の入力を受け付けるステップと、を実行し、
    前記非代替性トークンを管理するサーバのプロセッサが、
    入力された前記識別子の照会を行うステップと、
    入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録することで、前記非代替性トークンを前記電子チケットの所有者に付与するステップと、を実行する方法。
11. 電子チケットに関するチケットシステムであって、
    前記チケットシステムは、
    ユーザが前記電子チケットを使用するユーザ端末と、
    前記電子チケットを管理するチケット管理サーバと、
    前記電子チケットの使用を検出する検札システムと、
    前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
    前記検札システムのプロセッサが、
    前記電子チケットの使用を検出する手段を備え、
    前記チケット管理サーバのプロセッサが、
    前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者として登録された連絡先に対して送信する手段を備え、
    前記ユーザ端末のプロセッサが、
    受信した前記識別子を表示する手段と、
    表示された前記識別子の入力を受け付ける手段と、を備え、
    前記非代替性トークンを管理するサーバのプロセッサが、
    入力された前記識別子の照会を行う手段と、
    入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録することで、前記非代替性トークンを前記電子チケットの所有者に付与する手段と、を備えるシステム。
12. 電子チケットに関するチケットシステムに処理を実行させる方法であって、
    前記チケットシステムは、
    ユーザが前記電子チケットを使用するユーザ端末と、
    前記電子チケットを管理するチケット管理サーバと、
    前記電子チケットの使用を検出する検札システムと、
    前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
    前記検札システムのプロセッサが、
    前記電子チケットの使用を検出するステップを実行し、
    前記チケット管理サーバのプロセッサが、
    前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者が使用する前記ユーザ端末に対して送信するステップを実行し、
    前記ユーザ端末のプロセッサが、
    受信した前記識別子が表示されるように、既に前記ユーザ端末に表示された前記電子チケットの券面を書き換えるステップと、
    表示された前記識別子の入力を受け付けるステップと、を実行し、
    前記非代替性トークンを管理するサーバのプロセッサが、
    入力された前記識別子の照会を行うステップと、
    入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録することで、前記非代替性トークンを前記電子チケットの所有者に付与するステップと、を実行する方法。
13. 電子チケットに関するチケットシステムであって、
    前記チケットシステムは、
    ユーザが前記電子チケットを使用するユーザ端末と、
    前記電子チケットを管理するチケット管理サーバと、
    前記電子チケットの使用を検出する検札システムと、
    前記電子チケットの使用により、前記ユーザに付与される非代替性トークンを管理するサーバと、を備え、
    前記検札システムのプロセッサが、
    前記電子チケットの使用を検出する手段を備え、
    前記チケット管理サーバのプロセッサが、
    前記電子チケットの使用の検出に応じて、所有者情報が分散管理台帳に記録される非代替性トークンの付与の承認に用いられ、当該所有者情報が記録される前記非代替性トークン毎に固有の前記分散管理台帳を識別する台帳ＩＤと対応して設定された識別子を、前記電子チケットの所有者が使用する前記ユーザ端末に対して送信する手段を備え、
    前記ユーザ端末のプロセッサが、
    受信した前記識別子が表示されるように、既に前記ユーザ端末に表示された前記電子チケットの券面を書き換える手段と、
    表示された前記識別子の入力を受け付ける手段と、を備え、
    前記非代替性トークンを管理するサーバのプロセッサが、
    入力された前記識別子の照会を行う手段と、
    入力された前記識別子が適切である場合に、前記非代替性トークンの所有者として、前記電子チケットの所有者の情報を、前記台帳ＩＤに相当する前記分散管理台帳に登録することで、前記非代替性トークンを前記電子チケットの所有者に付与する手段と、を備えるシステム。

Images