JP2023177593A - プログラム、方法、およびシステム - Google Patents

Abstract

【課題】実際にチケットを使用するユーザへのチケットの販売を促進するプログラム、方法及びシステムを提供する。【解決手段】情報処理システム１において、プログラムを実行するチケット管理サーバ２０は、チケットの取引に関する費用の決済を検出し、取引に係るチケットの所有者に関する情報を、販売者からチケットを購入した他のユーザに変更する。そして、取引における売上のうちの少なくとも一部に相当する、取引における回収費用をチケットが使用されたことに応答して増加するように販売者に支払う処理を実行する。【選択図】図１

Description

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

各種イベントのチケットの流通において、ユーザ間での転売が広く行われている。
例えば、特許文献１には、電子チケットの転売におけるユーザ間のマッチングを促すシステムが開示されている。このシステムでは、電子チケットを転売したいユーザから入力された情報を、購入したいユーザに開示することで、電子チケットの取引の円滑化を図っている。

特開２００３－０５０８８９号公報

ところで、チケットの転売が活発に行われると、転売による利益を得る目的で大量のチケットを買い占めてチケット価格を高騰させる悪質な転売業者が出現するようになる。このような悪質な転売業者による転売が横行すると、チケットの価格が極端に高騰することで実際にイベントに参加したいユーザがチケットを入手しにくくなる。これにより、仮にチケット自体が大量に売れたとしても、使用を予定していない転売業者が買い占めている状態に過ぎず、実際にチケットを使用する人がいない状態となり、イベントが盛り上がらないという事態に陥ることがあった。

本開示の目的は、実際にチケットを使用するユーザへのチケットの販売を促進するシステムを提供することを目的とする。

本開示の一態様のプログラムは、コンピュータのプロセッサに、チケットの取引に関する費用の決済を検出するステップと、取引に係るチケットの所有者に関する情報を、販売者からチケットを購入した他のユーザに変更するステップと、取引における売上のうちの少なくとも一部に相当する、取引における回収費用を販売者に支払うステップと、を実行させ、販売者に支払われる回収費用の額は、チケットが使用されたことに応答して増加する。

第１実施形態における情報処理システムの構成を示すブロック図である。 第１実施形態における端末装置の構成を示すブロック図である。 第１実施形態におけるチケット管理サーバの構成を示すブロック図である。 第１実施形態における分散型台帳システムの構成を示す図である。 第１実施形態における分散型台帳システムが管理する分散型台帳のデータ構造の一例を示す図である。 チケットの流通を説明する図である。 第１実施形態におけるユーザ間でのチケットの流通価格を説明する図である。 ユーザデータベースのデータ構造の一例を示す図である。 イベントデータベースのデータ構造の一例を示す図である。 チケットマスタデータベースのデータ構造の一例を示す図である。 チケットデータベースのデータ構造の一例を示す図である。 取引履歴データベースのデータ構造の一例を示す図である。 第１実施形態において取引に係るチケットが使用された場合の処理を説明する図である。 第１実施形態において取引に係るチケットが使用されなかった場合の処理を説明する図である。 変形例に係るチケットが使用された場合の処理を説明する図である。 第２実施形態に係るシステムが適用されるチケットの流通を説明する図である。 第２実施形態に係るチケットの流通価格を説明する図である。 第２実施形態に係る取引履歴データベースのデータ構造の一例を示す図である。

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

（１）情報処理システム１の構成
本実施形態に係る情報処理システム１（以下、単にシステム１という）の構成について説明する。図１は、第１実施形態に係るシステム１の構成を示すブロック図である。

図１に示すように、システム１は、端末装置１０（１０Ａおよび１０Ｂを含む）と、チケット管理サーバ２０と、分散型台帳システム５０と、を備える。
端末装置１０、チケット管理サーバ２０、および分散型台帳システム５０は、ネットワーク（例えば、インターネット）ＮＷを介して接続される。

端末装置１０は、チケット管理サーバ２０又は分散型台帳システム５０にリクエストを送信する情報処理装置の一例である。端末装置１０は、例えば、スマートフォン、タブレット端末、又は、パーソナルコンピュータである。システム１は複数の端末装置１０を含む。なお、端末装置としては、以下の端末を含んでもよい。
・ＩｏＴデバイス
・ウェアラブルデバイス（スマートグラス、スマートウォッチ、スマートスピーカー、ヘッドマウントゴーグル、スマート家電、スマートウエア、スマートウィッグ等のユーザの身体に装着されて使用される端末）
・インプランタブルデバイス（ナノボット、スマートアイ、スマートコンタクトレンズ等のユーザの身体に内蔵されて使用される端末）

チケット管理サーバ２０は、情報処理装置の一例である。チケット管理サーバ２０は、端末装置１０から送信されたリクエストに応じたレスポンスを端末装置１０に提供する。チケット管理サーバ２０は、例えば、ウェブサーバである。チケット管理サーバ２０は、後述する発行者が使用する端末と通信接続されている。

分散型台帳システム５０は、端末装置１０、又はチケット管理サーバ２０からの要求に応じて、分散型台帳を管理する。

（１－１）端末装置１０の構成
端末装置１０の構成について説明する。図２は、第１実施形態に係る端末装置１０の構成を示すブロック図である。

図２に示すように、端末装置１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４とを備える。端末装置１０は、ディスプレイ１５に接続される。

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

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

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

プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、端末装置１０の機能を実現するコンピュータである。プロセッサ１２は、例えば、以下の少なくとも１つである。
・ＣＰＵ（Central Processing Unit）
・ＧＰＵ（Graphic Processing Unit）
・ＡＳＩＣ（Application Specific Integrated Circuit）
・ＦＰＧＡ（Field Programmable Array）

入出力インタフェース１３は、端末装置１０に接続される入力デバイスから情報（例えば、ユーザの指示）を取得し、かつ、端末装置１０に接続される出力デバイスに情報（例えば、画像）を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイ１５、スピーカ、又は、それらの組合せである。

通信インタフェース１４は、端末装置１０と外部装置（例えば、チケット管理サーバ２０、又は分散型台帳システム５０）との間の通信を制御するように構成される。

ディスプレイ１５は、画像（静止画、又は動画）を表示するように構成される。ディスプレイ１５は、例えば、液晶ディスプレイ、又は有機ＥＬディスプレイである。

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

図３に示すように、チケット管理サーバ２０は、記憶装置２１と、プロセッサ２２と、入出力インタフェース２３と、通信インタフェース２４とを備える。

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

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

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

プロセッサ２２は、記憶装置２１に記憶されたプログラムを起動することによって、チケット管理サーバ２０の機能を実現するコンピュータである。プロセッサ２２は、例えば、以下の少なくとも１つである。
・ＣＰＵ
・ＧＰＵ
・ＡＳＩＣ
・ＦＰＧＡ

入出力インタフェース２３は、チケット管理サーバ２０に接続される入力デバイスから情報（ユーザの指示）を取得し、かつ、チケット管理サーバ２０に接続される出力デバイスに情報（例えば画像）を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイ、スピーカ、又は、それらの組合せである。

通信インタフェース２４は、チケット管理サーバ２０と外部装置（例えば、端末装置１０、および分散型台帳システム５０）との間の通信を制御するように構成される。

（１－３）分散型台帳システム５０の構成
分散型台帳システム５０の構成について説明する。図５は、第１実施形態に係る分散型台帳システム５０の構成を示す図である。

図５に示すように、分散型台帳システム５０は、複数のノードコンピュータ５５－１～５５－４を備える。

ノードコンピュータ５５は、ネットワーク（図１のネットワークＮＷを含み得る）を介して互いに接続される。本実施形態では、ネットワークは、公衆網、プライベートネットワーク、専用線、ＶＰＮ（Virtual Private Network）、又はそれらの組み合わせを含み得る。ノードコンピュータ５５は、ネットワークと、例えば、有線又は無線により接続されている。ノードコンピュータ５５は、ピア・ツー・ピア方式で互いに通信する。

ノードコンピュータ５５は、例えばブロックチェーン技術を用いて分散型台帳を管理する。
具体的には、いずれかのノードコンピュータ５５は、記録すべきトークンの取引に関するデータを取得する。ノードコンピュータ５５は、取得したデータを含むブロックを作成し、ブロックチェーンに追加する。ノードコンピュータ５５は、追加したブロックの情報を他のノードコンピュータ５５へ送信する。他のノードコンピュータ５５は、受信したブロックの正しさを検証し、検証に成功すると、ブロックチェーンに当該ブロックを追加する。ノードコンピュータ５５は、例えば、連結されるブロックの数（承認数）に従ってブロックチェーンを確定する。これにより、分散型台帳システム５０を構成する複数のノードコンピュータ５５に亘って、同一の分散型台帳が保存されることになる。なお、保存されるデータは、適宜に暗号化される。

分散型台帳システム５０の構成は、図５に示されるものに限定されない。例えば、分散型台帳システム５０は、５台以上のノードコンピュータ５５を備えていてもよいし、２台又は３台のノードコンピュータ５５を備えていてもよい。また、分散型台帳システム５０を構成するノードコンピュータ５５の数は、時間とともに変動してもよい。

ノードコンピュータ５５のハードウェア構成は、前述したいずれかの端末又はサーバと同一又は類似であってよいので詳細な説明を省略する。一例として、ノードコンピュータ５５は、プロセッサ、記憶装置、入出力インタフェース、通信インタフェース、入力デバイス、出力デバイス、又はそれらの組み合わせを備える。

次に、本実施形態に係る分散型台帳のデータ構造について説明する。図５は、分散型台帳のデータ構造の一例を示す図である。
図５に示すように、システム１における分散型台帳では、トークンに記録される情報が、分散型台帳に格納されている。分散型台帳には、取引の履歴であるトランザクションに関する情報と紐づけられて、台帳ＩＤに紐づく固有の情報が格納されている。台帳ＩＤに紐づく固有の情報としては、例えば、以下が挙げられる。なお、台帳ＩＤは、チケットＩＤと同義であり、同じ識別情報を共用してもよい。
・チケットＩＤ…チケットの識別情報であり、台帳ＩＤを共用する場合は不要
・発行日時…トークンが発行された日時
・発行者情報…トークンを最初に発行（ＭＩＮＴ）した者の情報
・デジタルコンテンツアドレス…デジタルコンテンツのデータが格納されるアドレス情報

なお、チケットの所有者に関する情報は、台帳ＩＤに紐づくブロックチェーンにおける最新のブロックのトランザクションデータに記録されている。そして、過去の取引履歴については、全てのブロックのトランザクションデータとして蓄積されている。
なお、デジタルコンテンツのデータは、図示のとおり、ブロックチェーンの内部に記憶されてもよいし、外部のサーバに記憶されてもよい。

また、分散型台帳は、予め設定されたルールに従う処理を自動で実行するコントラクトデータを搭載している。コントラクトデータは、記録されたソースコードに設定されたアルゴリズムに従って、入力された情報に対して演算を行い、その結果を出力するコンピュータプロトコルである。
例えば、スマートコントラクトは、チケットの所有者に関する情報の変更に関する操作を入力として、当該チケットの取引の対価の授受を自動で実行してもよい。また、スマートコントラクトは、チケットの取引の対価の授受に関する操作を入力として、当該チケットの所有者に関する情報の変更を自動で実行してもよい。

また、スマートコントラクトは、チケットの使用の検出を入力として、当該チケットの使用に関する報酬の支払いを実行してもよい。チケットの使用に関する報酬については後述する。
また、スマートコントラクトは、チケットの使用期限の徒過の検出を入力として、当該チケットの使用に関する報酬として予定されていた額を、主催者に支払ってもよい。
このように、分散型台帳システム５０が管理する分散型台帳は、予め設定されたルールに従う処理を自動で実行するコントラクトデータを搭載し、分散型台帳システム５０は、チケットの取引に関する費用の支払いに関する処理を自動で行うことができる。

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

（２）実施形態の概要
第１実施形態に係る概要について説明する。
システム１が管理するチケットの対象であるイベントは、例えば以下が含まれる。
・コンサート、ライブなどの音楽イベント
・球技、水泳、格闘技などのスポーツイベント（プロリーグ、アマチュア競技会を含む）
・現実のイベント会場で行われるゲーム大会
・舞台演劇、漫才、落語、その他の芸能を含む演芸イベント
・見本市、物産展、フリーマーケットなどの展示会
・万博、地方博覧会などの博覧会
・美術展、博物展などの展覧会
・公営賭博
・地域での祭り、記念行事のような自治体主催のイベント
・学園祭、サークルや団体の発表会
・アミューズメントパークで行われる各種のイベント
・デパート又は公共エリアにおいて期間限定で開催される催事
なお、イベントの内容としては上記に限定されない。またイベントは、定期的に継続して行われてもよいし、不定期で行われてもよいし、常に開催されていてもよい。
以下の説明では、イベントとして、コンサートを例にあげて説明する。

（２－１）チケット流通の実際と課題
図６は、チケットの流通を説明する模式図である。図６に示すように、各種のイベントのチケット（紙チケットおよび電子チケットを含む）は、イベント主催者からチケットの販売を委託されたチケット販売代行業者により、チケットの購入を希望するユーザに対して販売される。この場合、ユーザへのチケットの正規の販売価格は、定価としてイベント主催者によって設定されることが一般的である。

そして、チケットの流通経路には図示のとおり、複数のケースが生じる。
・ケース１：チケットを使用する予定のユーザが購入する場合（チケットＡ）
この流通経路は、自身が使用するチケットを購入して、実際に使用するケースであり、最も一般的なケースである。この流通経路での取引は、チケットの販売枚数が来場見込み数になるため、イベント主催者にとって望ましい状況となる。

・ケース２：友人、知人のチケットをまとめて購入するケース（チケットＢ～Ｄ）
この流通経路は、例えば同伴者のチケットをまとめて購入するケースであり、紙チケットに限られず、電子チケットにおいても一般的に行われている。この流通経路での取引は、チケットの販売枚数が来場見込み数になるため、イベント主催者にとって望ましい状況となる。

・ケース３：専ら転売を目的とする転売者（転売業者を含む）が転売を行うケース（チケットＥ～Ｉ）
この流通経路は、専ら転売による利益を得る目的でチケットの取引に関わる転売者が取引の主体となるケースである。このパターンでは、転売者が大量のチケットを購入することが想定される。そして、仮に極端に取引価格を高騰させたによりチケットが売り切れなかった場合には、売れ残ったチケットが使用されないこととなる。このため、チケットの販売枚数と来場見込み数に乖離が生じる原因となる。
また、大量の買い占めおよびチケット価格の高騰が行われると、本来イベントへの参加を希望していたユーザへのチケットの流通が阻害される。このように、悪質な転売者が流通経路に介在することは、イベントへの参加者を減らす温床となりえるため、この流通経路での取引は、イベント主催者にとって望ましくない状況といえる。

すなわち、イベント主催者にとって望ましくない状況である、チケット販売数とイベント参加者数との間の乖離を生じさせないためには、実際にチケットを使用する予定のユーザに対するチケットの販売を促進することが有効である。
このような課題を解決するために、システム１では、ユーザ間で取引可能なチケット（紙チケットを含む）に関する情報を、非代替性トークン（Non-Fungible Token）として管理することで、実際にチケットを使用する予定のユーザに対するチケットの販売を促進する機能を実現する。また、システム１により、ユーザ間での取引における流通価格の適正化も期待できる。システム１は、図６に示すように、転売を含むユーザ間でのチケットの取引を主な適用範囲としている。なお、主催者からチケット販売代行業者への一次流通にシステム１を適用してもよい。

ここで、トークンとは資産価値のあるデータであって、本実施形態では、電子チケット、又は紙チケットに関する情報を構成するデータを指す。
本実施形態におけるトークンは、分散型台帳システム５０で管理される分散型台帳において所有者に関する情報が記録され、当該チケットの所有者が誰であるかが常に明確にされている。

一般に、代替性を備えたトークン（Fungible Token）としては、例えば仮想通貨やポイントのような金銭と等価の資産として扱われるデータを指す。
一方、非代替性を備えたトークンには、例えばＳＮＳ（Social Networking Service）上でコメントされたテキストデータ等のデジタルコンテンツのデータ、又は当該デジタルコンテンツデータが格納されたアドレスを示すアドレス情報（ＵＲＬ等）が含まれる。この場合、デジタルコンテンツに関するデータ自体は、第３者が任意に複写することができる。
一方、当該ＳＮＳ上におけるテキストデータの元データは、テキストデータ自体が複写されて転用されたとしても、分散型台帳において所有者が誰であるかが記録されているので、その持ち主を明確にすることができる。

本発明では、トークンに含まれるデジタルコンテンツとしては、例えば電子チケットの情報を示すデジタル画像（例えばチケット券面画像）、当該チケットの特典となるデジタル動画、デジタル音源のようなデジタルコンテンツが含まれる。券面画像には、電子チケットの所有により参加が認められる各種のイベントに関する情報が表示されていてもよい。
このように、トークンと紐づけられたデジタルコンテンツは、例えば、分散型台帳の内部に格納されてもよいし、デジタルコンテンツを管理する外部のサーバに格納されてもよい。
本発明ではこのように、チケットに関する情報を構成するトークンとして、非代替性トークンを扱う態様を例に挙げて説明する。

また、トークンは、分散型台帳システム５０の外部に存在するシステム（例えば、プライベートチェーン、又はセカンドレイヤーと呼ばれることがある）上で取引されてもよい。この場合のチケットの取引では、ユーザが保有するチケットが事実上取引されているシステムを特定可能な情報と、当該システムにおける当該顧客のウォレット情報と、を用いて行うことができる。

（２－２）システム１におけるチケットの流通価格
次に、システム１を用いたユーザ間での流通（転売）におけるチケットの流通価格について説明する。
図７は、第１実施形態におけるユーザ間でのチケットの流通価格を説明する図である。
図７に示すように、システム１を用いたチケットの販売では、（１）チケットが使用された場合と、（２）チケットが使用されなかった場合について、取引に関与した者の取り分が変化する。

まず、流通価格（転売における販売価格）に対して、予め設定された手数料率に基づいて、後述する各費目により構成される手数料が課される。流通価格と手数料との差額（売上基準額）は、取引の成立に応じて販売者に支払われる。
図示の例では、手数料は流通価格に対して４０％として設定されている。なお、手数料率は任意に変更することができる。

次に手数料の内訳について、チケット使用の有無により場合分けをして説明する。まず、チケットが使用された場合の手数料の内訳について説明する。

（１）チケットが使用された場合の手数料の内訳
・主催者徴収額：主催者の取り分、図示の例では無料
・システム使用料：システム１を管理、提供するシステム提供者に対して、予め設定されたシステム使用料率に基づいて支払われる費用（図示の例では流通価格の１０％）
・使用者への還元費用：チケットを使用したことを評価して、予め設定された還元率に基づいて、報酬としてチケット使用者に支払われる費用（図示の例では流通価格の１０％）
・使用評価額：販売したチケットが使用されたことを評価して、予め設定された支払比率に基づいて、報酬として当該チケットの販売者に支払われる費用（図示の例では流通価格の２０％）
すなわち、この場合において、販売者が取引によって回収できる回収費用は、売上基準額と使用評価額となる。

なお、前述したシステム使用料率、還元率、および支払比率の値については、あくまで一例であり、手数料の範囲内において、これらの比率は任意に変更可能である。すなわち、これらの比率を変更することで、チケットが使用された場合において、主催者徴収額が発生してもよい。また、システム使用料率および還元率のいずれかを０％にしてもよい。

つぎに、チケットが使用されなかった場合の手数料の内訳について説明する。
（２）チケットが使用されなかった場合の手数料の内訳
・主催者徴収額：主催者の取り分、図示の例では３０％
・システム使用料：同上、変化なし
・使用者への還元費用：なし
・使用評価額：なし
すなわち、チケットが使用された場合において、使用者へ支払われる予定であった還元費用、および販売者へ支払われる予定であった使用評価額が、チケットが使用されなかった場合には、主催者に支払われる。この場合において、販売者が取引によって回収できる回収費用は、売上基準額のみとなる。

なお、例えば、チケットが使用されなかった場合のシステム使用料を、チケットが使用された場合と異ならせてもよい。
また、チケットが使用されなかった場合に、手数料の一部のうち、使用評価額よりも少ない額を、追加支払費用として販売者に支払ってもよい。

例えば図７の下段の表に示す例では、ユーザＡ（転売者）が、４０００円で購入したチケットを、ユーザＢ（購入者）に対して６０００円で転売している。この場合において、チケットが使用された場合の各費用は以下のとおりである。
・取引に係る流通価格…６０００円
・売上基準額…３６００円（販売者の取り分）
・システム使用料…６００円（システム提供者の取り分）
・還元費用…６００円（使用者の取り分）
・使用評価額…１２００円（販売者の取り分）
・主催者徴収額…０円（主催者の取り分）
すなわち、チケットが使用された場合は、販売者であるユーザＡには、回収費用として、売上基準額と使用評価額の合計である４８００円が支払われる。この金額と前回の流通価格に相当する仕入れ値となる４０００円とを比較すると、ユーザＡは、この取引により８００円の利益を得ることになる。
一方、ユーザＢは、従来の転売では得られない利益として、還元費用に相当する６００円の支払いを受けることができる。

一方、図７の下段の表に示す例において、チケットが使用されなかった場合の各費用は以下のとおりである。
・取引に係る流通価格…６０００円
・売上基準額…３６００円（販売者の取り分）
・システム使用料…６００円（システム提供者の取り分）
・還元費用…無し（使用者の取り分）
・使用評価額…無し（販売者の取り分）
・主催者徴収額…１８００円（主催者の取り分）
すなわち、チケットが使用されなかった場合には、販売者であるユーザＡには、回収費用として、売上基準額である３６００円が支払われる。この金額と前回の流通価格に相当する仕入れ値となる４０００円とを比較すると、ユーザＡは、４００円の損失が生じることとなる。
一方、主催者には、従来の転売では得られない利益として、主催者徴収額に相当する１８００円の支払いを受けることができる。

このように、システム１ではチケットが使用されることにより、チケットの取引において販売者が受け取る回収費用が増加する。このため、実際に使用してくれる蓋然性が高いユーザに対して販売するという動機づけをチケットの販売者に与えることができる。
また、転売の利益の一部がチケット使用者に還元されるため、チケットを購入したユーザに対して、チケットの使用を促すことができる。また、転売の利益の一部がチケット使用者に還元されるため、仮に転売によりチケット価格が高騰した場合でも、還元費用によりその一部を補填することで、実際にイベントに参加したいユーザ（チケットを使用したいユーザ）を優遇することができる。

また、従来の転売であれば、チケットの使用の有無に関わらず、転売による利益は販売者（図７の例ではユーザＡ）が流通価格の差額である２０００円を受け取っていた。一方、システム１では、主催者および使用者（ユーザＢ）に転売により生じた利益の一部が分配されされ得る。このため、極端なチケットの流通価格の高騰を実質的に抑えることができ、チケット取引の健全化に寄与することが期待できる。

（３）データベース
第１実施形態に係る各データベースについて説明する。

（３－１）ユーザデータベース２１１
第１実施形態に係るユーザデータベース（ＤＢ）２１１について説明する。図８は、第１実施形態に係るユーザＤＢ２１１のデータ構造を示す図である。ユーザＤＢ２１１は、チケット管理サーバ２０の記憶装置２１に記憶される。

ユーザＤＢ２１１は、ユーザに関する情報を記憶し管理するデータベースである。ユーザＤＢ２１１は、ユーザのシステム１への加入により、新たなレコードが記録される。ユーザＤＢ２１１は、項目「ユーザＩＤ」、項目「氏名」、項目「ユーザ属性情報」、項目「連絡先」、項目「販売者スコア」、項目「使用者スコア」を含む。
なお、ユーザＤＢ２１１２１１に含まれるデータ項目は任意に変更することができる。

項目「ユーザＩＤ」は、ユーザを識別するための識別情報を記憶する項目である。ユーザＩＤは、ユーザごとにユニークな値が設定されている項目である。

項目「氏名」は、ユーザＩＤに対応するユーザの氏名を記憶する項目である。

項目「ユーザ属性情報」は、ユーザＩＤに対応するユーザの属性情報（性別、年齢、職業、居住地、国籍、使用言語）を記憶する項目である。

項目「連絡先」は、ユーザＩＤに対応するユーザへの連絡手段（メールアドレス等）を記憶する項目である。

項目「販売者」スコアは、ユーザＩＤに対応するユーザについて、チケット販売者としての実績を評価したスコアを記憶する項目である。販売者スコアは、過去のチケットの取引実績、および販売したチケットが実際に使用された使用実績率のうち、少なくともいずれかの値を基に算出される。販売者スコアは、ユーザのチケット販売の実績に応じて変化する属性である。

ユーザのチケット販売の実績を評価したい背景として、主催者としては、実際に使用してくれるユーザに対して販売を行う販売者を優遇したいという動機がある。すなわち、チケット販売数が多い販売者を優遇したいという側面と、仮に、チケット販売数は少なくても、使用されない歩留まりとなるチケットを生じさせない販売者と優遇したいという側面がある。このため、手数料および支払比率を、販売の実績に応じて自動で設定することで、主催者にとって好適な販売を行う販売者を優遇することができる。

販売者のスコアリング方法としては、例えば以下が挙げられる。
・大量に販売している販売者には、支払比率を上げる
・販売したチケットのうち、使用されたチケットの割合が多い場合に、支払比率を上げる
・新規ユーザへの販売実績が多い場合に、支払比率を上げる
・上記の実績を組み合わせて支払比率を調整する。

項目「使用者」スコアは、ユーザＩＤに対応するユーザについて、チケット使用者としての実績を評価したスコアを記憶する項目である。使用者スコアは、過去のチケットの購入実績、および過去のチケットの使用実績のうち、少なくともいずれかの値を基に算出される。使用者スコアは、ユーザのチケット使用の実績に応じて変化する属性である。

ユーザのチケット使用の実績を評価したい背景として、主催者としては、実際に使用してくれるユーザに対してチケットを購入してもらいたいという動機がある。すなわち、チケットを購入して使用する頻度が高い上客を優遇することで、より活発なイベント参加を促したいという動機がある。このため、チケットの使用により得られる還元率を、チケット使用の実績に応じて自動で設定することで、主催者にとって優良なチケット使用者を優遇することができる。

（３－２）イベントデータベース２１２
第１実施形態に係るイベントデータベース（ＤＢ）２１２について説明する。図９は、第１実施形態に係るイベントＤＢ２１２のデータ構造を示す図である。イベントＤＢ２１２は、チケット管理サーバ２０の記憶装置２１に記憶される。

イベントＤＢ２１２は、イベントに関する情報を記憶し管理するデータベースである。イベントＤＢ２１２は、イベントの主催者が新たなイベントを主催することにより、新たなレコードが記録される。イベントＤＢ２１２は、項目「イベントＩＤ」、項目「イベント種別」、項目「イベント名称」、項目「主催者」、項目「出演者」、項目「開催日」、項目「開催場所」、項目「スケジュール情報」を含む。
なお、イベントＤＢ２１２に含まれるデータ項目は任意に変更することができる。

項目「イベント」は、イベントを識別するための識別情報を記憶する項目である。イベントＩＤは、イベントごとにユニークな値が設定されている項目である。

項目「イベント種別」は、イベントＩＤに対応するイベントの種別を記憶する項目である。イベントの種別としては、例えば、「コンサート」、「スポーツ」、「展示会」、「音楽フェス」などが含まれる。

項目「イベント名称」は、イベントＩＤに対応するイベントの名称を記憶する項目である。

項目「主催者」は、イベントＩＤに対応するイベントの主催者に関する情報を記憶する項目である。

項目「出演者」は、イベントＩＤに対応するイベントの出演者に関する情報を記憶する項目である。例えば、イベントがコンサートの場合は、出演するアーティストの名称が格納される。

項目「開催日」は、イベントＩＤに対応するイベントの開催日を記憶する項目である。

項目「開催場所」は、イベントＩＤに対応するイベントの開催場所を記憶する項目である。

項目「スケジュール情報」は、イベントＩＤに対応するイベントの当日の各種のスケジュールに関する情報を記憶する項目である。当日の各種のスケジュールには、開場時間、開演時間、終演時間、閉場時間などが含まれる。

（３－３）チケットマスタデータベース２１３
第１実施形態に係るチケットマスタデータベース（ＤＢ）２１３について説明する。図１０は、第１実施形態に係るチケットマスタＤＢ２１３のデータ構造を示す図である。チケットマスタＤＢ２１３は、チケット管理サーバ２０の記憶装置２１に記憶される。

チケットマスタＤＢ２１３は、チケットデータを作成するうえで基礎となるチケットの種類ごとの内容に関するマスタデータを記憶し管理するデータベースである。チケットマスタＤＢ２１３は、イベントに対して販売されるチケットの内容を主催者が決めるにより、新たなレコードが記録される。
チケットマスタＤＢ２１３は、項目「チケットタイプＩＤ」、項目「イベントＩＤ」、項目「座席情報」、項目「卸値」、項目「定価」、項目「手数料率」、項目「還元率」、項目「還元率」、項目「システム使用料率」を含む。
なお、チケットマスタＤＢ２１３に含まれるデータ項目は任意に変更することができる。

項目「チケットタイプＩＤ」は、チケットの種類を識別するための識別情報を記憶する項目である。チケットタイプＩＤは、チケットの種類ごとにユニークな値が設定されている項目である。

項目「イベントＩＤ」は、チケットタイプＩＤに対応する種類のチケットが対象となるイベントのを記憶する項目である。

項目「座席情報」は、チケットタイプＩＤに対応する種類のチケットにより使用が許可される座席に関する情報を記憶する項目である。なお、座席情報には、入場可能なエリアを含んでもよい。

項目「卸値」は、チケットタイプＩＤに対応する種類のチケットの主催者からチケット販売を委託された販売代行業者（プレイガイド）への卸値を記憶する項目である。

項目「定価」は、チケットタイプＩＤに対応する種類のチケットにおける主催者が設定した販売価格の初期値を記憶する項目である。なお、定価については、例えば主催者により決定される。

項目「手数料率」は、チケットタイプＩＤに対応する種類のチケットにおいて、取引において流通価格に対して徴収される手数料の比率を記憶する項目である。手数料率は予め設定されている。

項目「支払比率」は、チケットタイプＩＤに対応する種類のチケットにおいて、取引されたチケットが使用された際に、チケットの販売者に対して支払われる使用評価額の算出に用いられ、流通価格に対する比率を記憶する項目である。支払比率は予め設定されている。

項目「還元率」は、チケットタイプＩＤに対応する種類のチケットにおいて、チケットの使用者に対して支払われる還元費用の算出に用いられ、流通価格に対する比率を記憶する項目である。還元率は、予め設定されている。

項目「システム使用料率」は、システム提供者に対するシステム１の使用料の算出に用いられる、流通価格に対する比率を記憶する項目である。システム使用料率は、予め設定されている。

（３－４）チケット個品データベース２１４
第１実施形態に係るチケット個品データベース（ＤＢ）２１４について説明する。図１１は、第１実施形態に係るチケット個品ＤＢ２１４のデータ構造を示す図である。チケット個品ＤＢ２１４は、チケット管理サーバ２０の記憶装置２１に記憶される。

チケット個品ＤＢ２１４は、チケットに関する情報を記憶し管理するデータベースである。チケット個品ＤＢ２１４は、販売予定のチケットの設定により、新たなレコードが記録される。チケット個品ＤＢ２１４は、項目「チケットＩＤ」、項目「チケットタイプＩＤ」、項目「販売ステータス」、項目「検札ステータス」、項目「台帳ＩＤ」、項目「デジタルコンテンツアドレス」を含む。
なお、チケット個品ＤＢ２１４に含まれるデータ項目は任意に変更することができる。

項目「チケットＩＤ」は、チケットを識別するための識別情報を記憶する項目である。チケットＩＤは、チケットごとにユニークな値が設定されている項目である。

項目「チケットタイプＩＤ」は、チケットＩＤに対応するチケットの種類についての識別情報を記憶する項目である。

項目「販売ステータス」は、チケットＩＤに対応するチケットの販売に関するステータスを記憶する項目である。チケットの販売に関するステータスとしては、「販売前」、「販売中」、「販売終了」などがある。

項目「検札ステータス」は、チケットＩＤに対応するチケットの使用状況を記憶する項目である。チケットの使用状況としては、「使用前」、「使用済み」がある。

項目「台帳ＩＤ」は、チケットＩＤに対応するチケットの所有者の情報が登録される分散管理台帳の識別情報を記憶する項目である。チケットＩＤと台帳ＩＤが共用される場合は、この項目は省略される。

項目「デジタルコンテンツアドレス」は、チケットＩＤに対応するチケットと紐づけられているデジタルコンテンツのデータが格納されたサーバのアドレス情報を記憶する項目である。

（３－５）取引履歴データベース２１５
第１実施形態に係る取引履歴データベース（ＤＢ）２１５について説明する。図１２は、第１実施形態に係る取引履歴ＤＢ２１５のデータ構造を示す図である。取引履歴ＤＢ２１５は、チケット管理サーバ２０の記憶装置２１に記憶される。

取引履歴ＤＢ２１５は、チケットの取引に関する情報を記憶し管理するデータベースである。取引履歴ＤＢ２１５は、ユーザ間においてチケットの取引が行われることにより、新たなレコードが記録される。
取引履歴ＤＢ２１５は、項目「取引ＩＤ」、項目「チケットＩＤ」、項目「販売ユーザＩＤ」、項目「購入ユーザＩＤ」、項目「取引回数」、項目「流通価格」、項目「手数料」、項目「売上基準額」、項目「使用評価額」、項目「支払費用」、項目「取引日時」、項目「チケットスコア」を含む。
なお、取引履歴ＤＢ２１５に含まれるデータ項目は任意に変更することができる。

項目「取引ＩＤ」は、ユーザ間での取引を識別するための識別情報を記憶する項目である。取引ＩＤは、ユーザ間での取引ごとにユニークな値が設定されている項目である。

項目「チケットＩＤ」は、取引ＩＤに対応する取引の対象となるチケットの識別情報を記憶する項目である。

項目「販売ユーザＩＤ」は、取引ＩＤに対応する取引においてチケットを販売したユーザの識別情報を記憶する項目である。

項目「購入ユーザＩＤ」は、取引ＩＤに対応する取引においてチケットを購入したユーザの識別情報を記憶する項目である。

項目「取引回数」は、チケットＩＤに該当するチケットが、取引ＩＤに対応する取引において、ユーザ間での何回目の取引に該当するかを記憶する項目である。

項目「流通価格」は、チケットＩＤに該当するチケットにおける、今回の取引での流通価格を記憶する項目である。

項目「手数料」は、取引ＩＤに対応する取引において、徴収される手数料を記憶する項目である。手数料は、流通価格に手数料率を乗じた額として算出される。

項目「売上基準額」は、取引ＩＤに対応する取引において、取引の成立に応じてチケットの販売者に支払われる費用の額を記憶する項目である。売上基準額は、流通価格と手数料との差額に相当する金額として算出される。

項目「使用評価額」は、取引ＩＤに対応する取引に係るチケットの使用の検出に応じてチケットの販売者に支払われる費用の額を記憶する項目である。使用評価額は、流通価格に支払比率を乗じた額として算出される。

項目「還元費用」は、チケットＩＤに該当するチケットを使用したユーザに対して還元される費用を記憶する項目である。還元費用の額は、流通価格に還元率を乗じた額として算出される。

項目「取引日時」は、取引ＩＤに対応する取引において、取引に関する決済処理が成立した日時を記憶する項目である。

項目「チケットスコア」は、取引ＩＤに対応する取引に係るチケットに関する属性として管理されている項目である。チケットスコアは、チケット定価、取引回数、販売枚数、売上枚数、および販売開始からの経過時間のうち、少なくともいずれか一つの値を基に算出される。チケットスコアは、チケットの取引の条件又は実績に応じて変化する属性である。

（４）情報処理
第１実施形態に係る情報処理について説明する。

（４－１）取引に係るチケットが使用された場合の処理
第１実施形態に係るチケットの取引のうち、取引に係るチケットが使用された場合の処理について説明する。図１３は、第１実施形態において取引に係るチケットが使用された場合の処理を説明する図である。この図において、販売者であるユーザは、正規の販売について主催者から委託されたチケット販売代行業者から、定価でチケットを購入して、他のユーザにチケットを転売する者とする。

まず、チケットの譲渡について説明する。
図１３に示すように、チケット譲渡の処理は、例えばユーザ間での合意に基づいて開始し得る。なお、チケット譲渡に関するユーザ間での合意の取り方については、以下に示す各種の手法が想定される。
・オークションによる購入者および流通価格の決定
・販売者が指定した流通価格に対する購入希望ユーザからの購入申請
・購入希望ユーザからの譲渡依頼に対する販売者からの販売申請
また、購入希望ユーザの使用者スコアを販売者に公開することで、販売者が実際に使用してくれそうなユーザを譲渡先として選択できてもよい。この場合には、購入希望ユーザのこれまでの使用実績に応じて、積極的にチケットを使用しているユーザを優遇することができる。

チケットの譲渡において、販売者であるユーザは、購入者を希望するユーザに対してチケットを送付する（ステップＳ１０１）。
具体的には、販売者であるユーザが、端末装置１０を操作して、分散型台帳システム５０に対して自身が保有するチケットの所有者を、購入を希望するユーザに変更する指示を入力する。

すなわち、端末装置１０は分散型台帳システム５０に対して、チケット個品ＤＢ２１４における台帳ＩＤに該当するブロックチェーンに記録されたチケットの所有者の情報を、ユーザに関する情報から、購入を希望するユーザに関する情報に変更する旨を指示する。
ここで、ユーザに関する情報とは、例えば分散型台帳において販売者を特定する販売者のウォレット情報である。
また、購入を希望するユーザに関する情報とは、例えば分散型台帳において購入を希望するユーザを特定する当該ユーザのウォレット情報である。

これにより、分散型台帳システム５０は、チケットの所有者の情報を変更する。
具体的には、分散型台帳システム５０は、台帳ＩＤに該当するブロックチェーンに記録されたトークンの所有者の情報を、ユーザに関する情報から、購入を希望するユーザに関する情報に変更する。分散型台帳システム５０は、チケットの所有者の情報を変更した旨を購入者であるユーザに通知する。
これにより、購入者であるユーザがチケットに関する情報（チケット券面にアクセスするＵＲＬ等）を受領する。

次に、取引の対価の授受について説明する。
図１３に示すように、取引の対価の授受は、取引の成立に応答して開始される。取引の対価の授受において、購入者であるユーザは、取引に係る費用を支払う（ステップＳ２０１）。
取引に係る費用の支払いは、チケットの送付に応答して、分散型台帳システム５０において運用される暗号資産（代替性トークン）を用いて自動で実行されてもよい。

ステップＳ２０１では、システム提供者に対して、システム使用料を含む手数料の少なくとも一部が支払われる（ステップＳ２０２）。
具体的には、分散型台帳システム５０は、システム使用料を含む手数料の少なくとも一部に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、システム提供者のウォレット情報に変更する。なお、図７の例では、手数料の全部がシステム提供者に支払われる。すなわち、図７の例では、システム使用料、チケットの使用者への還元費用、およびチケットの使用により販売者に支払われる使用評価額が、一時的にシステム提供者に対して支払われる。

また、ステップＳ２０１では、主催者に対して、手数料のうち、取引の成立に応じて主催者が徴収する一次徴収額に相当する金銭が支払われる（ステップＳ２０３）。
具体的には、分散型台帳システム５０は、一次徴収額に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、システム提供者のウォレット情報に変更する。図７の例では、一次徴収額は０となっているため、この支払は行われない。

また、ステップＳ２０１では、販売者に対して、売上基準額に相当する金銭が支払われる（ステップＳ２０４）。
具体的には、分散型台帳システム５０は、売上基準額に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、販売者であるユーザのウォレット情報に変更する。
これにより、取引の対価の授受が終了する。
なお、チケットの譲渡の処理の前に、取引の対価の授受の処理が行われてもよい。

次に、報酬の支払いについて説明する。
図１３に示すように、手数料の分配は、購入者であるユーザによるチケットの使用（ステップ３０１）に応答して開始される。手数料の分配において、主催者は、例えばイベント会場に来場したユーザに対する検札処理により、チケットの使用を検知する（Ｓ３０２）。

ステップＳ３０２の後に、システム１は、チケットの使用に関する報酬の支払いを行う（ステップＳ３０３）。具体的には、システム１は、分散型台帳システム５０により、還元費用に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、使用者のウォレット情報に変更する。これにより、チケットの使用者（購入者）であるユーザに対して、還元費用が支払われる（ステップＳ３０４）。

また、ステップＳ３０３において。システム１は、分散型台帳システム５０により、使用評価額に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、販売者のウォレット情報に変更する。これにより、チケットの販売者であるユーザに対して、使用評価額が支払われる（ステップＳ３０５）。
以上により、報酬の支払い処理が終了する。

（４－２）取引に係るチケットが使用されなかった場合の処理
第１実施形態に係るチケットの取引のうち、取引に係るチケットが使用されなかった場合の処理について説明する。図１４は、第１実施形態において取引に係るチケットが使用されなかった場合の処理を説明する図である。この図において、チケットの譲渡の処理および対価の授受の処理については、図１４と同一であるため、その説明を省略する。

主催者による手数料の追加支払について説明する。
主催者による手数料の追加支払は、チケットの使用期限の徒過に応答して行われる。まず、主催者はチケットの使用期限の徒過を検出する（ステップＳ４０１）。ここで、チケットの使用期限とは、例えばイベント会場への入場時間が終了する時刻、又はオンラインイベントにおける視聴可能時間が終了する時刻のように、スケジュール情報として予め設定されている情報である。

ステップＳ４０１の後に、システム１は、チケットの手数料について、主催者への支払いを行う（ステップＳ４０２）。具体的には、システム１は、分散型台帳システム５０により、還元費用および使用評価額に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、主催者のウォレット情報に変更する。すなわち、チケットが使用されなかったため、販売者および使用者に対して支払われる報酬に相当する額は、手数料として主催者に支払われる。主催者は追加で支払われた手数料を受領する（ステップＳ４０３）。
これにより、主催者に対する手数料の追加支払が完了する。

（４－３）変形例に係る処理
変形例に係るシステム１の処理について説明する。図１５は、変形例に係るチケットが使用された場合の処理を説明する図である。この図において、チケットの譲渡の処理および対価の授受の処理の流れは、図１３と同一であるため、その説明を省略する。

一方、対価の授受について支払われる額は、前述した図１３の例とは異なっている。
図１５に示すステップＳ２０２Ｂにおいて、システム提供者に支払われる額は、システム使用料のみに留まる。そして、ステップＳ２０３Ｂにおいて、主催者に支払われる額には、還元費用と使用評価額とに相当する額が含まれる。

報酬の支払いにおいて、ユーザがチケットを使用すると（ステップＳ５０１）、主催者は、例えばイベント会場に来場したユーザに対する検札処理により、チケットの使用を検知する（Ｓ５０２）。

ステップＳ５０２の後に、システム１は、チケットの使用に関する報酬の支払いを行う（ステップＳ５０３）。具体的には、システム１は、分散型台帳システム５０により、還元費用に相当する暗号資産の所有者の情報を、主催者のウォレット情報から、使用者のウォレット情報に変更する。これにより、チケットの使用者（購入者）であるユーザに対して、還元費用が支払われる（ステップＳ５０４）。

また、ステップＳ５０３において。システム１は、分散型台帳システム５０により、使用評価額に相当する暗号資産の所有者の情報を、主催者のウォレット情報から、販売者のウォレット情報に変更する。これにより、チケットの販売者であるユーザに対して、使用評価額が支払われる（ステップＳ５０５）。
以上により、報酬の支払い処理が完了する。

また、この変形例では、取引の成立に応じて、主催者に手数料のうち、システム使用料を控除した額を一度に支払っているので、仮にチケットが使用されなかった場合には、追加の支払いを行う必要がない。このため、図１４に示したように、使用評価額および還元費用をシステム提供者に一時的に支払う態様と比較して、金銭の支払い処理の手間を省くことができる。

なお、金銭の支払いの処理については、これらの例に限られない。例えば、販売者に対する回収費用の支払いは、一度に行ってもよい。すなわち、チケットの使用期限の徒過を判断の基準として、チケットが使用された場合には、売上基準額および使用評価額に相当する金銭を、販売者に一括して支払いってもよい。また、チケットが使用されなかった場合には、売上基準額に相当する金銭のみを、販売者に一括して支払ってもよい。

また、チケット譲渡の取引の成立に応じて、還元費用を前払いとしてチケットの購入者に対して支払い、仮に購入者がチケットを使用しなかった場合に、購入者から主催者に対して還元費用に相当する金銭の支払いを行ってもよい。
また、チケット譲渡の取引の成立に応じて、使用評価額を前払いとしてチケットの販売者に対して支払い、仮に購入者がチケットを使用しなかった場合に、販売者から主催者に対して使用評価額に相当する金銭の支払いを行ってもよい。

（５）小括
以上説明したように、システム１では、チケットが使用されることにより、販売者のチケットの取引に係る回収費用が増加する。このため、実際にチケットを使用しそうなユーザに対してチケットを販売する動機付けを与えることが可能になり、イベントの主催者にとって望ましい、イベントへの参加者が増加するという状況を実現することができる。これにより、実際にチケットを使用するユーザへのチケットの販売を促進することができる。

また、回収費用が、売上基準額と使用評価額とを含むので、チケットが使用されなかった場合であっても、販売者は売上基準額については回収できるため、チケットの取引において、販売者が過度な負担を強いられるのを防ぐことができる。

また、売上基準額は、取引の成立に応答して販売者に支払われ、使用評価額は、取引に係るチケットの使用の検出に応答して販売者に支払われる。このため、販売者は、取引の成立に応答して、回収費用の一部について支払いを受けることができる。

また、手数料率が、チケットスコア、および販売者スコアのうち、少なくとも一方を用いて設定されるので、イベントの人気や話題性、および販売者の過去の取引実績を考慮して、最適な手数料率を設定することができる。

また、支払比率が、チケットスコア、および販売者スコアのうち、少なくとも一方を用いて設定されるので、イベントの人気や話題性、および販売者の過去の取引実績を反映した最適な支払比率を設定することができる。

また、チケットスコアが、チケットの定価、取引回数、販売枚数、売上枚数、販売開始からの経過時間、および販売終了までの残り時間のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される。このため、チケットの価格や売れ行きを反映した評価指標をチケットに与えることができる。

また、販売者スコアが、販売者における過去の取引実績、および販売したチケットが実際に使用された割合を示す使用実績率のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される。このため、販売者の過去の取引が主催者のイベント活動に貢献した程度を反映した評価指標を販売者に与えることができる。

また、チケットの使用の検出に応答して、還元費用をチケットの使用者に支払う。このため、仮に転売によりチケット価格が高騰したとしても、チケットの購入者はチケットを使用することで還元費用の支払いを受けることが可能になり、実際にチケットを使用したいユーザを優遇することができる。

また、還元率が、使用者スコアを用いて設定されるので、ユーザのチケット使用の実績を反映して、ユーザへの還元の比率を設定することができる。

また、使用者スコアが、過去のチケットの購入実績、および過去のチケットの使用実績のうち、少なくともいずれかで決定される。このため、ユーザのチケットの使用実績を反映した評価指標をチケット購入者に与えることができる。

また、取引の成立に応答して、手数料の少なくとも一部を、当該チケットの発行元である主催者に支払う。このため、転売により生じた利益の一部を主催者が回収することができる。

また、取引に係るチケットが使用されない場合において、当該チケットの使用期限が徒過したことに応答して、手数料の少なくとも一部を、当該チケットの発行元である主催者に支払う。このため、使用者への還元費用および販売者への追加支払費用を主催者が回収することができる。

＜第２実施形態＞
以下、本発明の第２実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。図１６は第２実施形態に係るシステム２が適用チケットの流通を説明する図である。

図１６に示すように、本実施形態では、主催者（チケットの発行元）からチケット販売代行業者への一次販売までも、システム２の主な適用範囲となっている。また、一次流通の取引に一般ユーザが関わることもできる。

図１７は、第２実施形態におけるチケットの流通価格を説明する図である。
図１７に示すように、システム２では、販売価格と仕入れ値の差額である粗利に対して、還元費用が設定される。具体的には、販売価格が仕入れ値を超えるかどうかにより、場合分けをして説明する。

（１）販売価格が仕入れ値を超える場合
・システム使用料…予め設定された定額
・還元費用…粗利に対して還元率を乗じた額として設定される
・回収費用…チケットが使用されない場合は、仕入れ値相当額（チケットが使用された場合は、仕入れ値＋販売利益）
・販売利益…粗利－（システム使用料＋還元費用）
還元費用および販売利益は、チケットが使用されない場合には、手数料として主催者に徴収される。

（２）販売価格が仕入れ値を超えない場合
・システム使用料…予め設定された定額
・還元費用…なし
・回収費用…チケットの使用に関わらず、販売価格からシステム使用料を控除した額

図１８は、第２実施形態における取引履歴ＤＢ２１６のデータ構造の一例を示す図である。
図１８に示すように、取引履歴ＤＢ２１６は、第１実施形態の取引履歴ＤＢ２１５と異なるデータ項目として、項目「仕入れ値」、項目「販売価格」、項目「粗利」、項目「システム使用料」、項目「還元費用」、項目「販売利益」を備えている。

項目「仕入れ値」には、販売者におけるチケットの購入額が格納される。仕入れ値は、一次流通においては発行元からの卸値を指す。

項目「販売価格」には、取引における流通価格が格納される。

項目「粗利」は、販売価格と仕入れ値の差額が格納される。

項目「システム使用料」には、予め設定された手数料額が格納される。

項目「還元費用」には、粗利に対して還元率を乗じた額が格納される。

項目「販売利益」には、粗利からシステム使用料と還元費用を控除した額が格納される。

また、システム２では、チケットの発行元からの流通である一次流通を含むことに特化した処理が行われてもよい。
例えば、販売者スコアが所定の閾値を超えるユーザに対して、チケット販売の権限（一定数以上のチケットを購入する権限）を付与してもよい。

また、システム２では、流通の段階により、販売価格が異なっていてもよい。
例えば、二次流通では販売価格の上限と下限が設定され、三次流通以降では、価格を自由に設定できてもよい。

また、システム２では、販売価格の上限値と下限値が予め設定されていてもよい。この背景として、極端なチケット価格の高騰は、投機的な目的での転売が増加し、最終的に売れ残ることで、実際に使用されなくなるおそれが生じやすくなる。一方、極端なチケット価格の下落は、対象となるイベントに出演するアーティストのブランドが毀損される。このため、主催者としては、適正な範囲の価格帯ではチケットが販売されることが望ましい。
そして、販売価格の上限値と下限値が予め設定されていることにより、主催者により流通価格をある程度コントロールすることが可能になる。

また、システム２では、売れ残りそうなチケットを主催者が回収する処理を行ってもよい。例えば、イベント開始までの期間が一定以内（例えば２週間等）に迫ったチケットに対して、主催者が引き取り価格で引き取る処理を行ってもよい。この背景として、主催者は、前述したブランドの毀損という観点において、販売者による極端な安売りを避けたい一方で、イベント会場の来場者率が少なくなることも避けたいという課題を抱えている。このため、主催者は売れ残ったチケットを回収して、協賛企業や優良顧客に対して回収したチケットを無料（又は優遇価格）で配布することで、ブランドの毀損を防ぎながら、来場者を確保することができる。
また、主催者によるチケットの引き取り価格は、時間の経過又はチケットの売れ行きに伴って変化させてもよい。例えば、引き取り価格を、イベント当日に向けて次第に下落させてもよい。

また、一次流通を含むシステム２では、回収費用に対して最低保証額を設定してもよい。最低保証額とは、チケットの使用の有無に関わらず、チケットの取引に応じた最低限の支払いとして保証されている金額を指す。最低保証額としては、予め設定された絶対値（例えば３０００円等）、販売者の当該チケットの仕入れ値、又はチケットの流通価格に対して予め設定された比率に応じた額（例えば流通価格の６０％等）のように、任意に設定することができる。

（８）その他の変形例
記憶装置１１は、ネットワークＮＷを介して、端末装置１０と接続されてもよい。ディスプレイ１５は、端末装置１０に内蔵されてもよい。記憶装置２１は、ネットワークＮＷを介して、チケット管理サーバ２０と接続されてもよい。
上記の情報処理の各ステップは、処理に矛盾が生じない範囲において、その順序を変更することができる。

また、還元率を、チケットの流通価格に対して累進的に変化させてもよい。具体的には、流通価格の増加に伴って還元率が増加し、これに応じて販売者への支払比率が減少するように、流通価格の価格帯に応じた還元率および支払比率の設定を行ってもよい。例えば、還元率および支払比率は、以下のように設定することができる。
・流通価格が１万円以内の場合
還元率：流通価格の１０％
支払比率：流通価格の２０％
・流通価格が１万円～１万５千円の場合
還元率：流通価格の１５％
支払比率：流通価格の２０％
・流通価格が１万５千円を超える場合
還元率：流通価格の２０％
支払比率：流通価格の１０％
これにより、チケットの流通価格の増加に伴って、販売者への支払比率が減少するので、販売者が極端にチケット価格を高騰させることを抑制することができる。

また、チケットが使用されなかった場合に、手数料の一部のうち、使用評価額よりも少ない額を、追加支払費用として販売者に支払う場合には、回収費用は売上基準額および追加支払額となる。そして、チケットが使用された場合との回収費用を比較すると、以下の関係が成り立つ。
・（売上基準額＋使用評価額）＞（売上基準額＋追加支払額）
すなわち、チケットが使用された場合の回収費用が、チケットが使用されなかった場合の回収費用よりも高額となる。

また、各種の手数料、使用評価額、および還元費用の額を、定額としてもよい。
また、チケットの流通において設定された定価、手数料率、還元率などの値を、チケット販売者に対して公開してもよい。チケット販売者は、公開されている値を見て、該当するチケットを仕入れるかどうかを決めることができる。

上記説明では、イベントのチケットを例に挙げて説明したが、システム１、２が扱うチケットは、イベント（行事、催し物）に限られない。すなわち、以下の要件を満たすサービスに対して、システム１、２を適用することができる。
・サービスの対象が、ファンを有する特定の概念に立脚すること
・当該サービスの提供を受けるための対価の支払いの証票として、チケットが発行されること
このような条件を満たすその他のサービスとしては、映画館、美術館、博物館、劇場、アミューズメントパーク、交通機関、飲食店、ブランドショップなどが挙げられる。また、これらに関連するサービスのうち、電気通信回線を介して提供されるサービスに関するチケットにシステム１、２を適用してもよい。

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

１、２ ：情報処理システム
１０ ：端末装置１０
１１ ：記憶装置
１２ ：プロセッサ
２０ ：チケット管理サーバ
２１ ：記憶装置
２２ ：プロセッサ
４０ ：トークン管理・商材引換サーバ
４１ ：記憶装置
４２ ：プロセッサ
５０ ：分散型台帳システム
５５ ：ノードコンピュータ

Claims (14)

1. コンピュータのプロセッサに、
   チケットの取引に関する費用の決済を検出するステップと、
   前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更するステップと、
   前記取引における流通価格の一部に相当する、前記取引における回収費用を前記販売者に支払うステップと、を実行させ、
   前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、プログラム。
2. 前記回収費用は、
   前記流通価格に対して所定の手数料率に基づいて算出される手数料を控除して得られる売上基準額と、
   前記取引に係る前記チケットの使用に応じて支払われ、前記手数料に対して所定の支払比率に基づいて算出される使用評価額と、を含む、請求項１に記載のプログラム。
3. 前記回収費用を前記販売者に支払うステップは、分割して実行されることが許容され、
   前記売上基準額は、前記取引の成立に応答して前記販売者に支払われ、
   前記使用評価額は、前記取引に係る前記チケットの使用の検出に応答して前記販売者に支払われる、請求項２に記載のプログラム。
4. 前記手数料率は、前記取引の条件又は実績に応じて変化する属性として管理されるチケットスコア、および前記販売者の前記チケットの販売実績に応じて変化する属性として管理される販売者スコアのうち、少なくとも一方を用いて設定される、請求項２に記載のプログラム。
5. 前記支払比率は、前記取引の条件又は実績に応じて変化する属性として管理されるチケットスコア、および前記販売者の前記チケットの販売実績に応じて変化する属性として管理される販売者スコアのうち、少なくとも一方を用いて設定される、請求項２に記載のプログラム。
6. 前記チケットスコアは、前記チケットの一次流通における販売価格である定価、取引回数、販売枚数、売上枚数、販売開始からの経過時間、および販売終了までの残り時間のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される、請求項４又は５に記載のプログラム。
7. 前記販売者スコアは、前記販売者における過去の取引実績、および販売した前記チケットが実際に使用された割合を示す使用実績率のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される、請求項４又は５に記載のプログラム。
8. 前記プロセッサに、
   前記取引に係る前記チケットの使用の検出に応答して、前記手数料に対して所定の還元率に基づいて算出される還元費用を、当該チケットの使用者に支払うステップを実行させる、請求項２に記載のプログラム。
9. 前記還元率は、前記使用者の前記チケットの使用実績に応じて変化する属性として管理される使用者スコアを用いて設定される、請求項８に記載のプログラム。
10. 前記使用者スコアは、過去の前記チケットの購入実績、および過去の前記チケットの使用実績のうち、少なくともいずれかで決まる、請求項９に記載のプログラム。
11. 前記プロセッサに、
    前記取引の成立に応答して、前記手数料の少なくとも一部を、当該チケットの発行元に支払うステップを実行させる、請求項２に記載のプログラム。
12. 前記プロセッサに、
    前記取引に係る前記チケットが使用されない場合において、当該チケットの使用期限が徒過したことに応答して、前記手数料の少なくとも一部を、当該チケットの発行元に支払うステップを実行させる、請求項２に記載のプログラム。
13. コンピュータのプロセッサが、
    チケットの取引に関する費用の決済を検出するステップと、
    前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更するステップと、
    前記取引における売上のうちの少なくとも一部に相当する、前記取引における回収費用を前記販売者に支払うステップと、を実行し、
    前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、方法。
14. コンピュータのプロセッサが、
    チケットの取引に関する費用の決済を検出する手段と、
    前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更する手段と、
    前記取引における売上のうちの少なくとも一部に相当する、前記取引における回収費用を前記販売者に支払う手段と、を備え、
    前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、システム。