(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023177593
(43)【公開日】2023-12-14
(54)【発明の名称】プログラム、方法、およびシステム
(51)【国際特許分類】
G06Q 10/02 20120101AFI20231207BHJP
G06Q 30/0601 20230101ALI20231207BHJP
G06Q 30/04 20120101ALI20231207BHJP
【FI】
G06Q10/02
G06Q30/06 300
G06Q30/04
【審査請求】未請求
【請求項の数】14
【出願形態】OL
(21)【出願番号】P 2022090333
(22)【出願日】2022-06-02
(71)【出願人】
【識別番号】517201127
【氏名又は名称】playground株式会社
(74)【代理人】
【識別番号】110002815
【氏名又は名称】IPTech弁理士法人
(72)【発明者】
【氏名】伊藤 圭史
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA03
5L049BB11
5L049BB53
(57)【要約】 (修正有)
【課題】実際にチケットを使用するユーザへのチケットの販売を促進するプログラム、方法及びシステムを提供する。
【解決手段】情報処理システム1において、プログラムを実行するチケット管理サーバ20は、チケットの取引に関する費用の決済を検出し、取引に係るチケットの所有者に関する情報を、販売者からチケットを購入した他のユーザに変更する。そして、取引における売上のうちの少なくとも一部に相当する、取引における回収費用をチケットが使用されたことに応答して増加するように販売者に支払う処理を実行する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
コンピュータのプロセッサに、
チケットの取引に関する費用の決済を検出するステップと、
前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更するステップと、
前記取引における流通価格の一部に相当する、前記取引における回収費用を前記販売者に支払うステップと、を実行させ、
前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、プログラム。
【請求項2】
前記回収費用は、
前記流通価格に対して所定の手数料率に基づいて算出される手数料を控除して得られる売上基準額と、
前記取引に係る前記チケットの使用に応じて支払われ、前記手数料に対して所定の支払比率に基づいて算出される使用評価額と、を含む、請求項1に記載のプログラム。
【請求項3】
前記回収費用を前記販売者に支払うステップは、分割して実行されることが許容され、
前記売上基準額は、前記取引の成立に応答して前記販売者に支払われ、
前記使用評価額は、前記取引に係る前記チケットの使用の検出に応答して前記販売者に支払われる、請求項2に記載のプログラム。
【請求項4】
前記手数料率は、前記取引の条件又は実績に応じて変化する属性として管理されるチケットスコア、および前記販売者の前記チケットの販売実績に応じて変化する属性として管理される販売者スコアのうち、少なくとも一方を用いて設定される、請求項2に記載のプログラム。
【請求項5】
前記支払比率は、前記取引の条件又は実績に応じて変化する属性として管理されるチケットスコア、および前記販売者の前記チケットの販売実績に応じて変化する属性として管理される販売者スコアのうち、少なくとも一方を用いて設定される、請求項2に記載のプログラム。
【請求項6】
前記チケットスコアは、前記チケットの一次流通における販売価格である定価、取引回数、販売枚数、売上枚数、販売開始からの経過時間、および販売終了までの残り時間のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される、請求項4又は5に記載のプログラム。
【請求項7】
前記販売者スコアは、前記販売者における過去の取引実績、および販売した前記チケットが実際に使用された割合を示す使用実績率のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される、請求項4又は5に記載のプログラム。
【請求項8】
前記プロセッサに、
前記取引に係る前記チケットの使用の検出に応答して、前記手数料に対して所定の還元率に基づいて算出される還元費用を、当該チケットの使用者に支払うステップを実行させる、請求項2に記載のプログラム。
【請求項9】
前記還元率は、前記使用者の前記チケットの使用実績に応じて変化する属性として管理される使用者スコアを用いて設定される、請求項8に記載のプログラム。
【請求項10】
前記使用者スコアは、過去の前記チケットの購入実績、および過去の前記チケットの使用実績のうち、少なくともいずれかで決まる、請求項9に記載のプログラム。
【請求項11】
前記プロセッサに、
前記取引の成立に応答して、前記手数料の少なくとも一部を、当該チケットの発行元に支払うステップを実行させる、請求項2に記載のプログラム。
【請求項12】
前記プロセッサに、
前記取引に係る前記チケットが使用されない場合において、当該チケットの使用期限が徒過したことに応答して、前記手数料の少なくとも一部を、当該チケットの発行元に支払うステップを実行させる、請求項2に記載のプログラム。
【請求項13】
コンピュータのプロセッサが、
チケットの取引に関する費用の決済を検出するステップと、
前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更するステップと、
前記取引における売上のうちの少なくとも一部に相当する、前記取引における回収費用を前記販売者に支払うステップと、を実行し、
前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、方法。
【請求項14】
コンピュータのプロセッサが、
チケットの取引に関する費用の決済を検出する手段と、
前記取引に係る前記チケットの所有者に関する情報を、販売者から前記チケットを購入した他のユーザに変更する手段と、
前記取引における売上のうちの少なくとも一部に相当する、前記取引における回収費用を前記販売者に支払う手段と、を備え、
前記販売者に支払われる前記回収費用の額は、前記チケットが使用されたことに応答して増加する、システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、プログラム、方法、およびシステムに関する。
【背景技術】
【0002】
各種イベントのチケットの流通において、ユーザ間での転売が広く行われている。
例えば、特許文献1には、電子チケットの転売におけるユーザ間のマッチングを促すシステムが開示されている。このシステムでは、電子チケットを転売したいユーザから入力された情報を、購入したいユーザに開示することで、電子チケットの取引の円滑化を図っている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、チケットの転売が活発に行われると、転売による利益を得る目的で大量のチケットを買い占めてチケット価格を高騰させる悪質な転売業者が出現するようになる。このような悪質な転売業者による転売が横行すると、チケットの価格が極端に高騰することで実際にイベントに参加したいユーザがチケットを入手しにくくなる。これにより、仮にチケット自体が大量に売れたとしても、使用を予定していない転売業者が買い占めている状態に過ぎず、実際にチケットを使用する人がいない状態となり、イベントが盛り上がらないという事態に陥ることがあった。
【0005】
本開示の目的は、実際にチケットを使用するユーザへのチケットの販売を促進するシステムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本開示の一態様のプログラムは、コンピュータのプロセッサに、チケットの取引に関する費用の決済を検出するステップと、取引に係るチケットの所有者に関する情報を、販売者からチケットを購入した他のユーザに変更するステップと、取引における売上のうちの少なくとも一部に相当する、取引における回収費用を販売者に支払うステップと、を実行させ、販売者に支払われる回収費用の額は、チケットが使用されたことに応答して増加する。
【図面の簡単な説明】
【0007】
【
図1】第1実施形態における情報処理システムの構成を示すブロック図である。
【
図2】第1実施形態における端末装置の構成を示すブロック図である。
【
図3】第1実施形態におけるチケット管理サーバの構成を示すブロック図である。
【
図4】第1実施形態における分散型台帳システムの構成を示す図である。
【
図5】第1実施形態における分散型台帳システムが管理する分散型台帳のデータ構造の一例を示す図である。
【
図7】第1実施形態におけるユーザ間でのチケットの流通価格を説明する図である。
【
図8】ユーザデータベースのデータ構造の一例を示す図である。
【
図9】イベントデータベースのデータ構造の一例を示す図である。
【
図10】チケットマスタデータベースのデータ構造の一例を示す図である。
【
図11】チケットデータベースのデータ構造の一例を示す図である。
【
図12】取引履歴データベースのデータ構造の一例を示す図である。
【
図13】第1実施形態において取引に係るチケットが使用された場合の処理を説明する図である。
【
図14】第1実施形態において取引に係るチケットが使用されなかった場合の処理を説明する図である。
【
図15】変形例に係るチケットが使用された場合の処理を説明する図である。
【
図16】第2実施形態に係るシステムが適用されるチケットの流通を説明する図である。
【
図17】第2実施形態に係るチケットの流通価格を説明する図である。
【
図18】第2実施形態に係る取引履歴データベースのデータ構造の一例を示す図である。
【発明を実施するための形態】
【0008】
<第1実施形態>
以下、本発明の第1実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。
【0009】
(1)情報処理システム1の構成
本実施形態に係る情報処理システム1(以下、単にシステム1という)の構成について説明する。
図1は、第1実施形態に係るシステム1の構成を示すブロック図である。
【0010】
図1に示すように、システム1は、端末装置10(10Aおよび10Bを含む)と、チケット管理サーバ20と、分散型台帳システム50と、を備える。
端末装置10、チケット管理サーバ20、および分散型台帳システム50は、ネットワーク(例えば、インターネット)NWを介して接続される。
【0011】
端末装置10は、チケット管理サーバ20又は分散型台帳システム50にリクエストを送信する情報処理装置の一例である。端末装置10は、例えば、スマートフォン、タブレット端末、又は、パーソナルコンピュータである。システム1は複数の端末装置10を含む。なお、端末装置としては、以下の端末を含んでもよい。
・IoTデバイス
・ウェアラブルデバイス(スマートグラス、スマートウォッチ、スマートスピーカー、ヘッドマウントゴーグル、スマート家電、スマートウエア、スマートウィッグ等のユーザの身体に装着されて使用される端末)
・インプランタブルデバイス(ナノボット、スマートアイ、スマートコンタクトレンズ等のユーザの身体に内蔵されて使用される端末)
【0012】
チケット管理サーバ20は、情報処理装置の一例である。チケット管理サーバ20は、端末装置10から送信されたリクエストに応じたレスポンスを端末装置10に提供する。チケット管理サーバ20は、例えば、ウェブサーバである。チケット管理サーバ20は、後述する発行者が使用する端末と通信接続されている。
【0013】
分散型台帳システム50は、端末装置10、又はチケット管理サーバ20からの要求に応じて、分散型台帳を管理する。
【0014】
(1-1)端末装置10の構成
端末装置10の構成について説明する。
図2は、第1実施形態に係る端末装置10の構成を示すブロック図である。
【0015】
図2に示すように、端末装置10は、記憶装置11と、プロセッサ12と、入出力インタフェース13と、通信インタフェース14とを備える。端末装置10は、ディスプレイ15に接続される。
【0016】
記憶装置11は、プログラムおよびデータを記憶するように構成される。記憶装置11は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)、および、ストレージ(例えば、フラッシュメモリ又はハードディスク)の組合せである。
【0017】
プログラムは、例えば、以下のプログラムを含む。
・OS(Operating System)のプログラム
・情報処理を実行するアプリケーション(例えば、ウェブブラウザ)のプログラム
【0018】
データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ(つまり、情報処理の実行結果)
【0019】
プロセッサ12は、記憶装置11に記憶されたプログラムを起動することによって、端末装置10の機能を実現するコンピュータである。プロセッサ12は、例えば、以下の少なくとも1つである。
・CPU(Central Processing Unit)
・GPU(Graphic Processing Unit)
・ASIC(Application Specific Integrated Circuit)
・FPGA(Field Programmable Array)
【0020】
入出力インタフェース13は、端末装置10に接続される入力デバイスから情報(例えば、ユーザの指示)を取得し、かつ、端末装置10に接続される出力デバイスに情報(例えば、画像)を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイ15、スピーカ、又は、それらの組合せである。
【0021】
通信インタフェース14は、端末装置10と外部装置(例えば、チケット管理サーバ20、又は分散型台帳システム50)との間の通信を制御するように構成される。
【0022】
ディスプレイ15は、画像(静止画、又は動画)を表示するように構成される。ディスプレイ15は、例えば、液晶ディスプレイ、又は有機ELディスプレイである。
【0023】
(1-2)チケット管理サーバ20の構成
チケット管理サーバ20の構成について説明する。
図3は、第1実施形態に係るチケット管理サーバ20の構成を示すブロック図である。
【0024】
図3に示すように、チケット管理サーバ20は、記憶装置21と、プロセッサ22と、入出力インタフェース23と、通信インタフェース24とを備える。
【0025】
記憶装置21は、プログラムおよびデータを記憶するように構成される。記憶装置21は、例えば、ROM、RAM、および、ストレージ(例えば、フラッシュメモリ又はハードディスク)の組合せである。
【0026】
プログラムは、例えば、以下のプログラムを含む。
・OSのプログラム
・情報処理を実行するアプリケーションのプログラム
【0027】
データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果
【0028】
プロセッサ22は、記憶装置21に記憶されたプログラムを起動することによって、チケット管理サーバ20の機能を実現するコンピュータである。プロセッサ22は、例えば、以下の少なくとも1つである。
・CPU
・GPU
・ASIC
・FPGA
【0029】
入出力インタフェース23は、チケット管理サーバ20に接続される入力デバイスから情報(ユーザの指示)を取得し、かつ、チケット管理サーバ20に接続される出力デバイスに情報(例えば画像)を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイ、スピーカ、又は、それらの組合せである。
【0030】
通信インタフェース24は、チケット管理サーバ20と外部装置(例えば、端末装置10、および分散型台帳システム50)との間の通信を制御するように構成される。
【0031】
(1-3)分散型台帳システム50の構成
分散型台帳システム50の構成について説明する。
図5は、第1実施形態に係る分散型台帳システム50の構成を示す図である。
【0032】
図5に示すように、分散型台帳システム50は、複数のノードコンピュータ55-1~55-4を備える。
【0033】
ノードコンピュータ55は、ネットワーク(
図1のネットワークNWを含み得る)を介して互いに接続される。本実施形態では、ネットワークは、公衆網、プライベートネットワーク、専用線、VPN(Virtual Private Network)、又はそれらの組み合わせを含み得る。ノードコンピュータ55は、ネットワークと、例えば、有線又は無線により接続されている。ノードコンピュータ55は、ピア・ツー・ピア方式で互いに通信する。
【0034】
ノードコンピュータ55は、例えばブロックチェーン技術を用いて分散型台帳を管理する。
具体的には、いずれかのノードコンピュータ55は、記録すべきトークンの取引に関するデータを取得する。ノードコンピュータ55は、取得したデータを含むブロックを作成し、ブロックチェーンに追加する。ノードコンピュータ55は、追加したブロックの情報を他のノードコンピュータ55へ送信する。他のノードコンピュータ55は、受信したブロックの正しさを検証し、検証に成功すると、ブロックチェーンに当該ブロックを追加する。ノードコンピュータ55は、例えば、連結されるブロックの数(承認数)に従ってブロックチェーンを確定する。これにより、分散型台帳システム50を構成する複数のノードコンピュータ55に亘って、同一の分散型台帳が保存されることになる。なお、保存されるデータは、適宜に暗号化される。
【0035】
分散型台帳システム50の構成は、
図5に示されるものに限定されない。例えば、分散型台帳システム50は、5台以上のノードコンピュータ55を備えていてもよいし、2台又は3台のノードコンピュータ55を備えていてもよい。また、分散型台帳システム50を構成するノードコンピュータ55の数は、時間とともに変動してもよい。
【0036】
ノードコンピュータ55のハードウェア構成は、前述したいずれかの端末又はサーバと同一又は類似であってよいので詳細な説明を省略する。一例として、ノードコンピュータ55は、プロセッサ、記憶装置、入出力インタフェース、通信インタフェース、入力デバイス、出力デバイス、又はそれらの組み合わせを備える。
【0037】
次に、本実施形態に係る分散型台帳のデータ構造について説明する。
図5は、分散型台帳のデータ構造の一例を示す図である。
図5に示すように、システム1における分散型台帳では、トークンに記録される情報が、分散型台帳に格納されている。分散型台帳には、取引の履歴であるトランザクションに関する情報と紐づけられて、台帳IDに紐づく固有の情報が格納されている。台帳IDに紐づく固有の情報としては、例えば、以下が挙げられる。なお、台帳IDは、チケットIDと同義であり、同じ識別情報を共用してもよい。
・チケットID…チケットの識別情報であり、台帳IDを共用する場合は不要
・発行日時…トークンが発行された日時
・発行者情報…トークンを最初に発行(MINT)した者の情報
・デジタルコンテンツアドレス…デジタルコンテンツのデータが格納されるアドレス情報
【0038】
なお、チケットの所有者に関する情報は、台帳IDに紐づくブロックチェーンにおける最新のブロックのトランザクションデータに記録されている。そして、過去の取引履歴については、全てのブロックのトランザクションデータとして蓄積されている。
なお、デジタルコンテンツのデータは、図示のとおり、ブロックチェーンの内部に記憶されてもよいし、外部のサーバに記憶されてもよい。
【0039】
また、分散型台帳は、予め設定されたルールに従う処理を自動で実行するコントラクトデータを搭載している。コントラクトデータは、記録されたソースコードに設定されたアルゴリズムに従って、入力された情報に対して演算を行い、その結果を出力するコンピュータプロトコルである。
例えば、スマートコントラクトは、チケットの所有者に関する情報の変更に関する操作を入力として、当該チケットの取引の対価の授受を自動で実行してもよい。また、スマートコントラクトは、チケットの取引の対価の授受に関する操作を入力として、当該チケットの所有者に関する情報の変更を自動で実行してもよい。
【0040】
また、スマートコントラクトは、チケットの使用の検出を入力として、当該チケットの使用に関する報酬の支払いを実行してもよい。チケットの使用に関する報酬については後述する。
また、スマートコントラクトは、チケットの使用期限の徒過の検出を入力として、当該チケットの使用に関する報酬として予定されていた額を、主催者に支払ってもよい。
このように、分散型台帳システム50が管理する分散型台帳は、予め設定されたルールに従う処理を自動で実行するコントラクトデータを搭載し、分散型台帳システム50は、チケットの取引に関する費用の支払いに関する処理を自動で行うことができる。
【0041】
分散型台帳は、コントラクトデータを構成するブロックと、ハッシュ値およびトランザクションデータを少なくとも含むブロックと、により構成されている。ユーザ間でのトークンの移転に伴い、新たなトランザクションデータが生成され、
図5に示す複数のノードコンピュータ55-1~55-4による検証の後に、新たなブロックが追加される。
なお、ブロックチェーンである分散型台帳は、パブリックなブロックチェーンとプライベートなブロックチェーンとを用いてもよい。すなわち、通常の取引はプライベートなブロックチェーン上で取引履歴を記録し、定期的にパブリックなブロックチェーンに対して最新情報を反映するなど、複数階層を伴うような構成であってもよい。
【0042】
(2)実施形態の概要
第1実施形態に係る概要について説明する。
システム1が管理するチケットの対象であるイベントは、例えば以下が含まれる。
・コンサート、ライブなどの音楽イベント
・球技、水泳、格闘技などのスポーツイベント(プロリーグ、アマチュア競技会を含む)
・現実のイベント会場で行われるゲーム大会
・舞台演劇、漫才、落語、その他の芸能を含む演芸イベント
・見本市、物産展、フリーマーケットなどの展示会
・万博、地方博覧会などの博覧会
・美術展、博物展などの展覧会
・公営賭博
・地域での祭り、記念行事のような自治体主催のイベント
・学園祭、サークルや団体の発表会
・アミューズメントパークで行われる各種のイベント
・デパート又は公共エリアにおいて期間限定で開催される催事
なお、イベントの内容としては上記に限定されない。またイベントは、定期的に継続して行われてもよいし、不定期で行われてもよいし、常に開催されていてもよい。
以下の説明では、イベントとして、コンサートを例にあげて説明する。
【0043】
(2-1)チケット流通の実際と課題
図6は、チケットの流通を説明する模式図である。
図6に示すように、各種のイベントのチケット(紙チケットおよび電子チケットを含む)は、イベント主催者からチケットの販売を委託されたチケット販売代行業者により、チケットの購入を希望するユーザに対して販売される。この場合、ユーザへのチケットの正規の販売価格は、定価としてイベント主催者によって設定されることが一般的である。
【0044】
そして、チケットの流通経路には図示のとおり、複数のケースが生じる。
・ケース1:チケットを使用する予定のユーザが購入する場合(チケットA)
この流通経路は、自身が使用するチケットを購入して、実際に使用するケースであり、最も一般的なケースである。この流通経路での取引は、チケットの販売枚数が来場見込み数になるため、イベント主催者にとって望ましい状況となる。
【0045】
・ケース2:友人、知人のチケットをまとめて購入するケース(チケットB~D)
この流通経路は、例えば同伴者のチケットをまとめて購入するケースであり、紙チケットに限られず、電子チケットにおいても一般的に行われている。この流通経路での取引は、チケットの販売枚数が来場見込み数になるため、イベント主催者にとって望ましい状況となる。
【0046】
・ケース3:専ら転売を目的とする転売者(転売業者を含む)が転売を行うケース(チケットE~I)
この流通経路は、専ら転売による利益を得る目的でチケットの取引に関わる転売者が取引の主体となるケースである。このパターンでは、転売者が大量のチケットを購入することが想定される。そして、仮に極端に取引価格を高騰させたによりチケットが売り切れなかった場合には、売れ残ったチケットが使用されないこととなる。このため、チケットの販売枚数と来場見込み数に乖離が生じる原因となる。
また、大量の買い占めおよびチケット価格の高騰が行われると、本来イベントへの参加を希望していたユーザへのチケットの流通が阻害される。このように、悪質な転売者が流通経路に介在することは、イベントへの参加者を減らす温床となりえるため、この流通経路での取引は、イベント主催者にとって望ましくない状況といえる。
【0047】
すなわち、イベント主催者にとって望ましくない状況である、チケット販売数とイベント参加者数との間の乖離を生じさせないためには、実際にチケットを使用する予定のユーザに対するチケットの販売を促進することが有効である。
このような課題を解決するために、システム1では、ユーザ間で取引可能なチケット(紙チケットを含む)に関する情報を、非代替性トークン(Non-Fungible Token)として管理することで、実際にチケットを使用する予定のユーザに対するチケットの販売を促進する機能を実現する。また、システム1により、ユーザ間での取引における流通価格の適正化も期待できる。システム1は、
図6に示すように、転売を含むユーザ間でのチケットの取引を主な適用範囲としている。なお、主催者からチケット販売代行業者への一次流通にシステム1を適用してもよい。
【0048】
ここで、トークンとは資産価値のあるデータであって、本実施形態では、電子チケット、又は紙チケットに関する情報を構成するデータを指す。
本実施形態におけるトークンは、分散型台帳システム50で管理される分散型台帳において所有者に関する情報が記録され、当該チケットの所有者が誰であるかが常に明確にされている。
【0049】
一般に、代替性を備えたトークン(Fungible Token)としては、例えば仮想通貨やポイントのような金銭と等価の資産として扱われるデータを指す。
一方、非代替性を備えたトークンには、例えばSNS(Social Networking Service)上でコメントされたテキストデータ等のデジタルコンテンツのデータ、又は当該デジタルコンテンツデータが格納されたアドレスを示すアドレス情報(URL等)が含まれる。この場合、デジタルコンテンツに関するデータ自体は、第3者が任意に複写することができる。
一方、当該SNS上におけるテキストデータの元データは、テキストデータ自体が複写されて転用されたとしても、分散型台帳において所有者が誰であるかが記録されているので、その持ち主を明確にすることができる。
【0050】
本発明では、トークンに含まれるデジタルコンテンツとしては、例えば電子チケットの情報を示すデジタル画像(例えばチケット券面画像)、当該チケットの特典となるデジタル動画、デジタル音源のようなデジタルコンテンツが含まれる。券面画像には、電子チケットの所有により参加が認められる各種のイベントに関する情報が表示されていてもよい。
このように、トークンと紐づけられたデジタルコンテンツは、例えば、分散型台帳の内部に格納されてもよいし、デジタルコンテンツを管理する外部のサーバに格納されてもよい。
本発明ではこのように、チケットに関する情報を構成するトークンとして、非代替性トークンを扱う態様を例に挙げて説明する。
【0051】
また、トークンは、分散型台帳システム50の外部に存在するシステム(例えば、プライベートチェーン、又はセカンドレイヤーと呼ばれることがある)上で取引されてもよい。この場合のチケットの取引では、ユーザが保有するチケットが事実上取引されているシステムを特定可能な情報と、当該システムにおける当該顧客のウォレット情報と、を用いて行うことができる。
【0052】
(2-2)システム1におけるチケットの流通価格
次に、システム1を用いたユーザ間での流通(転売)におけるチケットの流通価格について説明する。
図7は、第1実施形態におけるユーザ間でのチケットの流通価格を説明する図である。
図7に示すように、システム1を用いたチケットの販売では、(1)チケットが使用された場合と、(2)チケットが使用されなかった場合について、取引に関与した者の取り分が変化する。
【0053】
まず、流通価格(転売における販売価格)に対して、予め設定された手数料率に基づいて、後述する各費目により構成される手数料が課される。流通価格と手数料との差額(売上基準額)は、取引の成立に応じて販売者に支払われる。
図示の例では、手数料は流通価格に対して40%として設定されている。なお、手数料率は任意に変更することができる。
【0054】
次に手数料の内訳について、チケット使用の有無により場合分けをして説明する。まず、チケットが使用された場合の手数料の内訳について説明する。
【0055】
(1)チケットが使用された場合の手数料の内訳
・主催者徴収額:主催者の取り分、図示の例では無料
・システム使用料:システム1を管理、提供するシステム提供者に対して、予め設定されたシステム使用料率に基づいて支払われる費用(図示の例では流通価格の10%)
・使用者への還元費用:チケットを使用したことを評価して、予め設定された還元率に基づいて、報酬としてチケット使用者に支払われる費用(図示の例では流通価格の10%)
・使用評価額:販売したチケットが使用されたことを評価して、予め設定された支払比率に基づいて、報酬として当該チケットの販売者に支払われる費用(図示の例では流通価格の20%)
すなわち、この場合において、販売者が取引によって回収できる回収費用は、売上基準額と使用評価額となる。
【0056】
なお、前述したシステム使用料率、還元率、および支払比率の値については、あくまで一例であり、手数料の範囲内において、これらの比率は任意に変更可能である。すなわち、これらの比率を変更することで、チケットが使用された場合において、主催者徴収額が発生してもよい。また、システム使用料率および還元率のいずれかを0%にしてもよい。
【0057】
つぎに、チケットが使用されなかった場合の手数料の内訳について説明する。
(2)チケットが使用されなかった場合の手数料の内訳
・主催者徴収額:主催者の取り分、図示の例では30%
・システム使用料:同上、変化なし
・使用者への還元費用:なし
・使用評価額:なし
すなわち、チケットが使用された場合において、使用者へ支払われる予定であった還元費用、および販売者へ支払われる予定であった使用評価額が、チケットが使用されなかった場合には、主催者に支払われる。この場合において、販売者が取引によって回収できる回収費用は、売上基準額のみとなる。
【0058】
なお、例えば、チケットが使用されなかった場合のシステム使用料を、チケットが使用された場合と異ならせてもよい。
また、チケットが使用されなかった場合に、手数料の一部のうち、使用評価額よりも少ない額を、追加支払費用として販売者に支払ってもよい。
【0059】
例えば
図7の下段の表に示す例では、ユーザA(転売者)が、4000円で購入したチケットを、ユーザB(購入者)に対して6000円で転売している。この場合において、チケットが使用された場合の各費用は以下のとおりである。
・取引に係る流通価格…6000円
・売上基準額…3600円(販売者の取り分)
・システム使用料…600円(システム提供者の取り分)
・還元費用…600円(使用者の取り分)
・使用評価額…1200円(販売者の取り分)
・主催者徴収額…0円(主催者の取り分)
すなわち、チケットが使用された場合は、販売者であるユーザAには、回収費用として、売上基準額と使用評価額の合計である4800円が支払われる。この金額と前回の流通価格に相当する仕入れ値となる4000円とを比較すると、ユーザAは、この取引により800円の利益を得ることになる。
一方、ユーザBは、従来の転売では得られない利益として、還元費用に相当する600円の支払いを受けることができる。
【0060】
一方、
図7の下段の表に示す例において、チケットが使用されなかった場合の各費用は以下のとおりである。
・取引に係る流通価格…6000円
・売上基準額…3600円(販売者の取り分)
・システム使用料…600円(システム提供者の取り分)
・還元費用…無し(使用者の取り分)
・使用評価額…無し(販売者の取り分)
・主催者徴収額…1800円(主催者の取り分)
すなわち、チケットが使用されなかった場合には、販売者であるユーザAには、回収費用として、売上基準額である3600円が支払われる。この金額と前回の流通価格に相当する仕入れ値となる4000円とを比較すると、ユーザAは、400円の損失が生じることとなる。
一方、主催者には、従来の転売では得られない利益として、主催者徴収額に相当する1800円の支払いを受けることができる。
【0061】
このように、システム1ではチケットが使用されることにより、チケットの取引において販売者が受け取る回収費用が増加する。このため、実際に使用してくれる蓋然性が高いユーザに対して販売するという動機づけをチケットの販売者に与えることができる。
また、転売の利益の一部がチケット使用者に還元されるため、チケットを購入したユーザに対して、チケットの使用を促すことができる。また、転売の利益の一部がチケット使用者に還元されるため、仮に転売によりチケット価格が高騰した場合でも、還元費用によりその一部を補填することで、実際にイベントに参加したいユーザ(チケットを使用したいユーザ)を優遇することができる。
【0062】
また、従来の転売であれば、チケットの使用の有無に関わらず、転売による利益は販売者(
図7の例ではユーザA)が流通価格の差額である2000円を受け取っていた。一方、システム1では、主催者および使用者(ユーザB)に転売により生じた利益の一部が分配されされ得る。このため、極端なチケットの流通価格の高騰を実質的に抑えることができ、チケット取引の健全化に寄与することが期待できる。
【0063】
(3)データベース
第1実施形態に係る各データベースについて説明する。
【0064】
(3-1)ユーザデータベース211
第1実施形態に係るユーザデータベース(DB)211について説明する。
図8は、第1実施形態に係るユーザDB211のデータ構造を示す図である。ユーザDB211は、チケット管理サーバ20の記憶装置21に記憶される。
【0065】
ユーザDB211は、ユーザに関する情報を記憶し管理するデータベースである。ユーザDB211は、ユーザのシステム1への加入により、新たなレコードが記録される。ユーザDB211は、項目「ユーザID」、項目「氏名」、項目「ユーザ属性情報」、項目「連絡先」、項目「販売者スコア」、項目「使用者スコア」を含む。
なお、ユーザDB211211に含まれるデータ項目は任意に変更することができる。
【0066】
項目「ユーザID」は、ユーザを識別するための識別情報を記憶する項目である。ユーザIDは、ユーザごとにユニークな値が設定されている項目である。
【0067】
項目「氏名」は、ユーザIDに対応するユーザの氏名を記憶する項目である。
【0068】
項目「ユーザ属性情報」は、ユーザIDに対応するユーザの属性情報(性別、年齢、職業、居住地、国籍、使用言語)を記憶する項目である。
【0069】
項目「連絡先」は、ユーザIDに対応するユーザへの連絡手段(メールアドレス等)を記憶する項目である。
【0070】
項目「販売者」スコアは、ユーザIDに対応するユーザについて、チケット販売者としての実績を評価したスコアを記憶する項目である。販売者スコアは、過去のチケットの取引実績、および販売したチケットが実際に使用された使用実績率のうち、少なくともいずれかの値を基に算出される。販売者スコアは、ユーザのチケット販売の実績に応じて変化する属性である。
【0071】
ユーザのチケット販売の実績を評価したい背景として、主催者としては、実際に使用してくれるユーザに対して販売を行う販売者を優遇したいという動機がある。すなわち、チケット販売数が多い販売者を優遇したいという側面と、仮に、チケット販売数は少なくても、使用されない歩留まりとなるチケットを生じさせない販売者と優遇したいという側面がある。このため、手数料および支払比率を、販売の実績に応じて自動で設定することで、主催者にとって好適な販売を行う販売者を優遇することができる。
【0072】
販売者のスコアリング方法としては、例えば以下が挙げられる。
・大量に販売している販売者には、支払比率を上げる
・販売したチケットのうち、使用されたチケットの割合が多い場合に、支払比率を上げる
・新規ユーザへの販売実績が多い場合に、支払比率を上げる
・上記の実績を組み合わせて支払比率を調整する。
【0073】
項目「使用者」スコアは、ユーザIDに対応するユーザについて、チケット使用者としての実績を評価したスコアを記憶する項目である。使用者スコアは、過去のチケットの購入実績、および過去のチケットの使用実績のうち、少なくともいずれかの値を基に算出される。使用者スコアは、ユーザのチケット使用の実績に応じて変化する属性である。
【0074】
ユーザのチケット使用の実績を評価したい背景として、主催者としては、実際に使用してくれるユーザに対してチケットを購入してもらいたいという動機がある。すなわち、チケットを購入して使用する頻度が高い上客を優遇することで、より活発なイベント参加を促したいという動機がある。このため、チケットの使用により得られる還元率を、チケット使用の実績に応じて自動で設定することで、主催者にとって優良なチケット使用者を優遇することができる。
【0075】
(3-2)イベントデータベース212
第1実施形態に係るイベントデータベース(DB)212について説明する。
図9は、第1実施形態に係るイベントDB212のデータ構造を示す図である。イベントDB212は、チケット管理サーバ20の記憶装置21に記憶される。
【0076】
イベントDB212は、イベントに関する情報を記憶し管理するデータベースである。イベントDB212は、イベントの主催者が新たなイベントを主催することにより、新たなレコードが記録される。イベントDB212は、項目「イベントID」、項目「イベント種別」、項目「イベント名称」、項目「主催者」、項目「出演者」、項目「開催日」、項目「開催場所」、項目「スケジュール情報」を含む。
なお、イベントDB212に含まれるデータ項目は任意に変更することができる。
【0077】
項目「イベント」は、イベントを識別するための識別情報を記憶する項目である。イベントIDは、イベントごとにユニークな値が設定されている項目である。
【0078】
項目「イベント種別」は、イベントIDに対応するイベントの種別を記憶する項目である。イベントの種別としては、例えば、「コンサート」、「スポーツ」、「展示会」、「音楽フェス」などが含まれる。
【0079】
項目「イベント名称」は、イベントIDに対応するイベントの名称を記憶する項目である。
【0080】
項目「主催者」は、イベントIDに対応するイベントの主催者に関する情報を記憶する項目である。
【0081】
項目「出演者」は、イベントIDに対応するイベントの出演者に関する情報を記憶する項目である。例えば、イベントがコンサートの場合は、出演するアーティストの名称が格納される。
【0082】
項目「開催日」は、イベントIDに対応するイベントの開催日を記憶する項目である。
【0083】
項目「開催場所」は、イベントIDに対応するイベントの開催場所を記憶する項目である。
【0084】
項目「スケジュール情報」は、イベントIDに対応するイベントの当日の各種のスケジュールに関する情報を記憶する項目である。当日の各種のスケジュールには、開場時間、開演時間、終演時間、閉場時間などが含まれる。
【0085】
(3-3)チケットマスタデータベース213
第1実施形態に係るチケットマスタデータベース(DB)213について説明する。
図10は、第1実施形態に係るチケットマスタDB213のデータ構造を示す図である。チケットマスタDB213は、チケット管理サーバ20の記憶装置21に記憶される。
【0086】
チケットマスタDB213は、チケットデータを作成するうえで基礎となるチケットの種類ごとの内容に関するマスタデータを記憶し管理するデータベースである。チケットマスタDB213は、イベントに対して販売されるチケットの内容を主催者が決めるにより、新たなレコードが記録される。
チケットマスタDB213は、項目「チケットタイプID」、項目「イベントID」、項目「座席情報」、項目「卸値」、項目「定価」、項目「手数料率」、項目「還元率」、項目「還元率」、項目「システム使用料率」を含む。
なお、チケットマスタDB213に含まれるデータ項目は任意に変更することができる。
【0087】
項目「チケットタイプID」は、チケットの種類を識別するための識別情報を記憶する項目である。チケットタイプIDは、チケットの種類ごとにユニークな値が設定されている項目である。
【0088】
項目「イベントID」は、チケットタイプIDに対応する種類のチケットが対象となるイベントのを記憶する項目である。
【0089】
項目「座席情報」は、チケットタイプIDに対応する種類のチケットにより使用が許可される座席に関する情報を記憶する項目である。なお、座席情報には、入場可能なエリアを含んでもよい。
【0090】
項目「卸値」は、チケットタイプIDに対応する種類のチケットの主催者からチケット販売を委託された販売代行業者(プレイガイド)への卸値を記憶する項目である。
【0091】
項目「定価」は、チケットタイプIDに対応する種類のチケットにおける主催者が設定した販売価格の初期値を記憶する項目である。なお、定価については、例えば主催者により決定される。
【0092】
項目「手数料率」は、チケットタイプIDに対応する種類のチケットにおいて、取引において流通価格に対して徴収される手数料の比率を記憶する項目である。手数料率は予め設定されている。
【0093】
項目「支払比率」は、チケットタイプIDに対応する種類のチケットにおいて、取引されたチケットが使用された際に、チケットの販売者に対して支払われる使用評価額の算出に用いられ、流通価格に対する比率を記憶する項目である。支払比率は予め設定されている。
【0094】
項目「還元率」は、チケットタイプIDに対応する種類のチケットにおいて、チケットの使用者に対して支払われる還元費用の算出に用いられ、流通価格に対する比率を記憶する項目である。還元率は、予め設定されている。
【0095】
項目「システム使用料率」は、システム提供者に対するシステム1の使用料の算出に用いられる、流通価格に対する比率を記憶する項目である。システム使用料率は、予め設定されている。
【0096】
(3-4)チケット個品データベース214
第1実施形態に係るチケット個品データベース(DB)214について説明する。
図11は、第1実施形態に係るチケット個品DB214のデータ構造を示す図である。チケット個品DB214は、チケット管理サーバ20の記憶装置21に記憶される。
【0097】
チケット個品DB214は、チケットに関する情報を記憶し管理するデータベースである。チケット個品DB214は、販売予定のチケットの設定により、新たなレコードが記録される。チケット個品DB214は、項目「チケットID」、項目「チケットタイプID」、項目「販売ステータス」、項目「検札ステータス」、項目「台帳ID」、項目「デジタルコンテンツアドレス」を含む。
なお、チケット個品DB214に含まれるデータ項目は任意に変更することができる。
【0098】
項目「チケットID」は、チケットを識別するための識別情報を記憶する項目である。チケットIDは、チケットごとにユニークな値が設定されている項目である。
【0099】
項目「チケットタイプID」は、チケットIDに対応するチケットの種類についての識別情報を記憶する項目である。
【0100】
項目「販売ステータス」は、チケットIDに対応するチケットの販売に関するステータスを記憶する項目である。チケットの販売に関するステータスとしては、「販売前」、「販売中」、「販売終了」などがある。
【0101】
項目「検札ステータス」は、チケットIDに対応するチケットの使用状況を記憶する項目である。チケットの使用状況としては、「使用前」、「使用済み」がある。
【0102】
項目「台帳ID」は、チケットIDに対応するチケットの所有者の情報が登録される分散管理台帳の識別情報を記憶する項目である。チケットIDと台帳IDが共用される場合は、この項目は省略される。
【0103】
項目「デジタルコンテンツアドレス」は、チケットIDに対応するチケットと紐づけられているデジタルコンテンツのデータが格納されたサーバのアドレス情報を記憶する項目である。
【0104】
(3-5)取引履歴データベース215
第1実施形態に係る取引履歴データベース(DB)215について説明する。
図12は、第1実施形態に係る取引履歴DB215のデータ構造を示す図である。取引履歴DB215は、チケット管理サーバ20の記憶装置21に記憶される。
【0105】
取引履歴DB215は、チケットの取引に関する情報を記憶し管理するデータベースである。取引履歴DB215は、ユーザ間においてチケットの取引が行われることにより、新たなレコードが記録される。
取引履歴DB215は、項目「取引ID」、項目「チケットID」、項目「販売ユーザID」、項目「購入ユーザID」、項目「取引回数」、項目「流通価格」、項目「手数料」、項目「売上基準額」、項目「使用評価額」、項目「支払費用」、項目「取引日時」、項目「チケットスコア」を含む。
なお、取引履歴DB215に含まれるデータ項目は任意に変更することができる。
【0106】
項目「取引ID」は、ユーザ間での取引を識別するための識別情報を記憶する項目である。取引IDは、ユーザ間での取引ごとにユニークな値が設定されている項目である。
【0107】
項目「チケットID」は、取引IDに対応する取引の対象となるチケットの識別情報を記憶する項目である。
【0108】
項目「販売ユーザID」は、取引IDに対応する取引においてチケットを販売したユーザの識別情報を記憶する項目である。
【0109】
項目「購入ユーザID」は、取引IDに対応する取引においてチケットを購入したユーザの識別情報を記憶する項目である。
【0110】
項目「取引回数」は、チケットIDに該当するチケットが、取引IDに対応する取引において、ユーザ間での何回目の取引に該当するかを記憶する項目である。
【0111】
項目「流通価格」は、チケットIDに該当するチケットにおける、今回の取引での流通価格を記憶する項目である。
【0112】
項目「手数料」は、取引IDに対応する取引において、徴収される手数料を記憶する項目である。手数料は、流通価格に手数料率を乗じた額として算出される。
【0113】
項目「売上基準額」は、取引IDに対応する取引において、取引の成立に応じてチケットの販売者に支払われる費用の額を記憶する項目である。売上基準額は、流通価格と手数料との差額に相当する金額として算出される。
【0114】
項目「使用評価額」は、取引IDに対応する取引に係るチケットの使用の検出に応じてチケットの販売者に支払われる費用の額を記憶する項目である。使用評価額は、流通価格に支払比率を乗じた額として算出される。
【0115】
項目「還元費用」は、チケットIDに該当するチケットを使用したユーザに対して還元される費用を記憶する項目である。還元費用の額は、流通価格に還元率を乗じた額として算出される。
【0116】
項目「取引日時」は、取引IDに対応する取引において、取引に関する決済処理が成立した日時を記憶する項目である。
【0117】
項目「チケットスコア」は、取引IDに対応する取引に係るチケットに関する属性として管理されている項目である。チケットスコアは、チケット定価、取引回数、販売枚数、売上枚数、および販売開始からの経過時間のうち、少なくともいずれか一つの値を基に算出される。チケットスコアは、チケットの取引の条件又は実績に応じて変化する属性である。
【0118】
(4)情報処理
第1実施形態に係る情報処理について説明する。
【0119】
(4-1)取引に係るチケットが使用された場合の処理
第1実施形態に係るチケットの取引のうち、取引に係るチケットが使用された場合の処理について説明する。
図13は、第1実施形態において取引に係るチケットが使用された場合の処理を説明する図である。この図において、販売者であるユーザは、正規の販売について主催者から委託されたチケット販売代行業者から、定価でチケットを購入して、他のユーザにチケットを転売する者とする。
【0120】
まず、チケットの譲渡について説明する。
図13に示すように、チケット譲渡の処理は、例えばユーザ間での合意に基づいて開始し得る。なお、チケット譲渡に関するユーザ間での合意の取り方については、以下に示す各種の手法が想定される。
・オークションによる購入者および流通価格の決定
・販売者が指定した流通価格に対する購入希望ユーザからの購入申請
・購入希望ユーザからの譲渡依頼に対する販売者からの販売申請
また、購入希望ユーザの使用者スコアを販売者に公開することで、販売者が実際に使用してくれそうなユーザを譲渡先として選択できてもよい。この場合には、購入希望ユーザのこれまでの使用実績に応じて、積極的にチケットを使用しているユーザを優遇することができる。
【0121】
チケットの譲渡において、販売者であるユーザは、購入者を希望するユーザに対してチケットを送付する(ステップS101)。
具体的には、販売者であるユーザが、端末装置10を操作して、分散型台帳システム50に対して自身が保有するチケットの所有者を、購入を希望するユーザに変更する指示を入力する。
【0122】
すなわち、端末装置10は分散型台帳システム50に対して、チケット個品DB214における台帳IDに該当するブロックチェーンに記録されたチケットの所有者の情報を、ユーザに関する情報から、購入を希望するユーザに関する情報に変更する旨を指示する。
ここで、ユーザに関する情報とは、例えば分散型台帳において販売者を特定する販売者のウォレット情報である。
また、購入を希望するユーザに関する情報とは、例えば分散型台帳において購入を希望するユーザを特定する当該ユーザのウォレット情報である。
【0123】
これにより、分散型台帳システム50は、チケットの所有者の情報を変更する。
具体的には、分散型台帳システム50は、台帳IDに該当するブロックチェーンに記録されたトークンの所有者の情報を、ユーザに関する情報から、購入を希望するユーザに関する情報に変更する。分散型台帳システム50は、チケットの所有者の情報を変更した旨を購入者であるユーザに通知する。
これにより、購入者であるユーザがチケットに関する情報(チケット券面にアクセスするURL等)を受領する。
【0124】
次に、取引の対価の授受について説明する。
図13に示すように、取引の対価の授受は、取引の成立に応答して開始される。取引の対価の授受において、購入者であるユーザは、取引に係る費用を支払う(ステップS201)。
取引に係る費用の支払いは、チケットの送付に応答して、分散型台帳システム50において運用される暗号資産(代替性トークン)を用いて自動で実行されてもよい。
【0125】
ステップS201では、システム提供者に対して、システム使用料を含む手数料の少なくとも一部が支払われる(ステップS202)。
具体的には、分散型台帳システム50は、システム使用料を含む手数料の少なくとも一部に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、システム提供者のウォレット情報に変更する。なお、
図7の例では、手数料の全部がシステム提供者に支払われる。すなわち、
図7の例では、システム使用料、チケットの使用者への還元費用、およびチケットの使用により販売者に支払われる使用評価額が、一時的にシステム提供者に対して支払われる。
【0126】
また、ステップS201では、主催者に対して、手数料のうち、取引の成立に応じて主催者が徴収する一次徴収額に相当する金銭が支払われる(ステップS203)。
具体的には、分散型台帳システム50は、一次徴収額に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、システム提供者のウォレット情報に変更する。
図7の例では、一次徴収額は0となっているため、この支払は行われない。
【0127】
また、ステップS201では、販売者に対して、売上基準額に相当する金銭が支払われる(ステップS204)。
具体的には、分散型台帳システム50は、売上基準額に相当する暗号資産の所有者の情報を、購入者であるユーザのウォレット情報から、販売者であるユーザのウォレット情報に変更する。
これにより、取引の対価の授受が終了する。
なお、チケットの譲渡の処理の前に、取引の対価の授受の処理が行われてもよい。
【0128】
次に、報酬の支払いについて説明する。
図13に示すように、手数料の分配は、購入者であるユーザによるチケットの使用(ステップ301)に応答して開始される。手数料の分配において、主催者は、例えばイベント会場に来場したユーザに対する検札処理により、チケットの使用を検知する(S302)。
【0129】
ステップS302の後に、システム1は、チケットの使用に関する報酬の支払いを行う(ステップS303)。具体的には、システム1は、分散型台帳システム50により、還元費用に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、使用者のウォレット情報に変更する。これにより、チケットの使用者(購入者)であるユーザに対して、還元費用が支払われる(ステップS304)。
【0130】
また、ステップS303において。システム1は、分散型台帳システム50により、使用評価額に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、販売者のウォレット情報に変更する。これにより、チケットの販売者であるユーザに対して、使用評価額が支払われる(ステップS305)。
以上により、報酬の支払い処理が終了する。
【0131】
(4-2)取引に係るチケットが使用されなかった場合の処理
第1実施形態に係るチケットの取引のうち、取引に係るチケットが使用されなかった場合の処理について説明する。
図14は、第1実施形態において取引に係るチケットが使用されなかった場合の処理を説明する図である。この図において、チケットの譲渡の処理および対価の授受の処理については、
図14と同一であるため、その説明を省略する。
【0132】
主催者による手数料の追加支払について説明する。
主催者による手数料の追加支払は、チケットの使用期限の徒過に応答して行われる。まず、主催者はチケットの使用期限の徒過を検出する(ステップS401)。ここで、チケットの使用期限とは、例えばイベント会場への入場時間が終了する時刻、又はオンラインイベントにおける視聴可能時間が終了する時刻のように、スケジュール情報として予め設定されている情報である。
【0133】
ステップS401の後に、システム1は、チケットの手数料について、主催者への支払いを行う(ステップS402)。具体的には、システム1は、分散型台帳システム50により、還元費用および使用評価額に相当する暗号資産の所有者の情報を、システム提供者のウォレット情報から、主催者のウォレット情報に変更する。すなわち、チケットが使用されなかったため、販売者および使用者に対して支払われる報酬に相当する額は、手数料として主催者に支払われる。主催者は追加で支払われた手数料を受領する(ステップS403)。
これにより、主催者に対する手数料の追加支払が完了する。
【0134】
(4-3)変形例に係る処理
変形例に係るシステム1の処理について説明する。
図15は、変形例に係るチケットが使用された場合の処理を説明する図である。この図において、チケットの譲渡の処理および対価の授受の処理の流れは、
図13と同一であるため、その説明を省略する。
【0135】
一方、対価の授受について支払われる額は、前述した
図13の例とは異なっている。
図15に示すステップS202Bにおいて、システム提供者に支払われる額は、システム使用料のみに留まる。そして、ステップS203Bにおいて、主催者に支払われる額には、還元費用と使用評価額とに相当する額が含まれる。
【0136】
報酬の支払いにおいて、ユーザがチケットを使用すると(ステップS501)、主催者は、例えばイベント会場に来場したユーザに対する検札処理により、チケットの使用を検知する(S502)。
【0137】
ステップS502の後に、システム1は、チケットの使用に関する報酬の支払いを行う(ステップS503)。具体的には、システム1は、分散型台帳システム50により、還元費用に相当する暗号資産の所有者の情報を、主催者のウォレット情報から、使用者のウォレット情報に変更する。これにより、チケットの使用者(購入者)であるユーザに対して、還元費用が支払われる(ステップS504)。
【0138】
また、ステップS503において。システム1は、分散型台帳システム50により、使用評価額に相当する暗号資産の所有者の情報を、主催者のウォレット情報から、販売者のウォレット情報に変更する。これにより、チケットの販売者であるユーザに対して、使用評価額が支払われる(ステップS505)。
以上により、報酬の支払い処理が完了する。
【0139】
また、この変形例では、取引の成立に応じて、主催者に手数料のうち、システム使用料を控除した額を一度に支払っているので、仮にチケットが使用されなかった場合には、追加の支払いを行う必要がない。このため、
図14に示したように、使用評価額および還元費用をシステム提供者に一時的に支払う態様と比較して、金銭の支払い処理の手間を省くことができる。
【0140】
なお、金銭の支払いの処理については、これらの例に限られない。例えば、販売者に対する回収費用の支払いは、一度に行ってもよい。すなわち、チケットの使用期限の徒過を判断の基準として、チケットが使用された場合には、売上基準額および使用評価額に相当する金銭を、販売者に一括して支払いってもよい。また、チケットが使用されなかった場合には、売上基準額に相当する金銭のみを、販売者に一括して支払ってもよい。
【0141】
また、チケット譲渡の取引の成立に応じて、還元費用を前払いとしてチケットの購入者に対して支払い、仮に購入者がチケットを使用しなかった場合に、購入者から主催者に対して還元費用に相当する金銭の支払いを行ってもよい。
また、チケット譲渡の取引の成立に応じて、使用評価額を前払いとしてチケットの販売者に対して支払い、仮に購入者がチケットを使用しなかった場合に、販売者から主催者に対して使用評価額に相当する金銭の支払いを行ってもよい。
【0142】
(5)小括
以上説明したように、システム1では、チケットが使用されることにより、販売者のチケットの取引に係る回収費用が増加する。このため、実際にチケットを使用しそうなユーザに対してチケットを販売する動機付けを与えることが可能になり、イベントの主催者にとって望ましい、イベントへの参加者が増加するという状況を実現することができる。これにより、実際にチケットを使用するユーザへのチケットの販売を促進することができる。
【0143】
また、回収費用が、売上基準額と使用評価額とを含むので、チケットが使用されなかった場合であっても、販売者は売上基準額については回収できるため、チケットの取引において、販売者が過度な負担を強いられるのを防ぐことができる。
【0144】
また、売上基準額は、取引の成立に応答して販売者に支払われ、使用評価額は、取引に係るチケットの使用の検出に応答して販売者に支払われる。このため、販売者は、取引の成立に応答して、回収費用の一部について支払いを受けることができる。
【0145】
また、手数料率が、チケットスコア、および販売者スコアのうち、少なくとも一方を用いて設定されるので、イベントの人気や話題性、および販売者の過去の取引実績を考慮して、最適な手数料率を設定することができる。
【0146】
また、支払比率が、チケットスコア、および販売者スコアのうち、少なくとも一方を用いて設定されるので、イベントの人気や話題性、および販売者の過去の取引実績を反映した最適な支払比率を設定することができる。
【0147】
また、チケットスコアが、チケットの定価、取引回数、販売枚数、売上枚数、販売開始からの経過時間、および販売終了までの残り時間のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される。このため、チケットの価格や売れ行きを反映した評価指標をチケットに与えることができる。
【0148】
また、販売者スコアが、販売者における過去の取引実績、および販売したチケットが実際に使用された割合を示す使用実績率のうち、少なくともいずれか一つを変数として予め設定された算出式により決定される。このため、販売者の過去の取引が主催者のイベント活動に貢献した程度を反映した評価指標を販売者に与えることができる。
【0149】
また、チケットの使用の検出に応答して、還元費用をチケットの使用者に支払う。このため、仮に転売によりチケット価格が高騰したとしても、チケットの購入者はチケットを使用することで還元費用の支払いを受けることが可能になり、実際にチケットを使用したいユーザを優遇することができる。
【0150】
また、還元率が、使用者スコアを用いて設定されるので、ユーザのチケット使用の実績を反映して、ユーザへの還元の比率を設定することができる。
【0151】
また、使用者スコアが、過去のチケットの購入実績、および過去のチケットの使用実績のうち、少なくともいずれかで決定される。このため、ユーザのチケットの使用実績を反映した評価指標をチケット購入者に与えることができる。
【0152】
また、取引の成立に応答して、手数料の少なくとも一部を、当該チケットの発行元である主催者に支払う。このため、転売により生じた利益の一部を主催者が回収することができる。
【0153】
また、取引に係るチケットが使用されない場合において、当該チケットの使用期限が徒過したことに応答して、手数料の少なくとも一部を、当該チケットの発行元である主催者に支払う。このため、使用者への還元費用および販売者への追加支払費用を主催者が回収することができる。
【0154】
<第2実施形態>
以下、本発明の第2実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。
図16は第2実施形態に係るシステム2が適用チケットの流通を説明する図である。
【0155】
図16に示すように、本実施形態では、主催者(チケットの発行元)からチケット販売代行業者への一次販売までも、システム2の主な適用範囲となっている。また、一次流通の取引に一般ユーザが関わることもできる。
【0156】
図17は、第2実施形態におけるチケットの流通価格を説明する図である。
図17に示すように、システム2では、販売価格と仕入れ値の差額である粗利に対して、還元費用が設定される。具体的には、販売価格が仕入れ値を超えるかどうかにより、場合分けをして説明する。
【0157】
(1)販売価格が仕入れ値を超える場合
・システム使用料…予め設定された定額
・還元費用…粗利に対して還元率を乗じた額として設定される
・回収費用…チケットが使用されない場合は、仕入れ値相当額(チケットが使用された場合は、仕入れ値+販売利益)
・販売利益…粗利-(システム使用料+還元費用)
還元費用および販売利益は、チケットが使用されない場合には、手数料として主催者に徴収される。
【0158】
(2)販売価格が仕入れ値を超えない場合
・システム使用料…予め設定された定額
・還元費用…なし
・回収費用…チケットの使用に関わらず、販売価格からシステム使用料を控除した額
【0159】
図18は、第2実施形態における取引履歴DB216のデータ構造の一例を示す図である。
図18に示すように、取引履歴DB216は、第1実施形態の取引履歴DB215と異なるデータ項目として、項目「仕入れ値」、項目「販売価格」、項目「粗利」、項目「システム使用料」、項目「還元費用」、項目「販売利益」を備えている。
【0160】
項目「仕入れ値」には、販売者におけるチケットの購入額が格納される。仕入れ値は、一次流通においては発行元からの卸値を指す。
【0161】
項目「販売価格」には、取引における流通価格が格納される。
【0162】
項目「粗利」は、販売価格と仕入れ値の差額が格納される。
【0163】
項目「システム使用料」には、予め設定された手数料額が格納される。
【0164】
項目「還元費用」には、粗利に対して還元率を乗じた額が格納される。
【0165】
項目「販売利益」には、粗利からシステム使用料と還元費用を控除した額が格納される。
【0166】
また、システム2では、チケットの発行元からの流通である一次流通を含むことに特化した処理が行われてもよい。
例えば、販売者スコアが所定の閾値を超えるユーザに対して、チケット販売の権限(一定数以上のチケットを購入する権限)を付与してもよい。
【0167】
また、システム2では、流通の段階により、販売価格が異なっていてもよい。
例えば、二次流通では販売価格の上限と下限が設定され、三次流通以降では、価格を自由に設定できてもよい。
【0168】
また、システム2では、販売価格の上限値と下限値が予め設定されていてもよい。この背景として、極端なチケット価格の高騰は、投機的な目的での転売が増加し、最終的に売れ残ることで、実際に使用されなくなるおそれが生じやすくなる。一方、極端なチケット価格の下落は、対象となるイベントに出演するアーティストのブランドが毀損される。このため、主催者としては、適正な範囲の価格帯ではチケットが販売されることが望ましい。
そして、販売価格の上限値と下限値が予め設定されていることにより、主催者により流通価格をある程度コントロールすることが可能になる。
【0169】
また、システム2では、売れ残りそうなチケットを主催者が回収する処理を行ってもよい。例えば、イベント開始までの期間が一定以内(例えば2週間等)に迫ったチケットに対して、主催者が引き取り価格で引き取る処理を行ってもよい。この背景として、主催者は、前述したブランドの毀損という観点において、販売者による極端な安売りを避けたい一方で、イベント会場の来場者率が少なくなることも避けたいという課題を抱えている。このため、主催者は売れ残ったチケットを回収して、協賛企業や優良顧客に対して回収したチケットを無料(又は優遇価格)で配布することで、ブランドの毀損を防ぎながら、来場者を確保することができる。
また、主催者によるチケットの引き取り価格は、時間の経過又はチケットの売れ行きに伴って変化させてもよい。例えば、引き取り価格を、イベント当日に向けて次第に下落させてもよい。
【0170】
また、一次流通を含むシステム2では、回収費用に対して最低保証額を設定してもよい。最低保証額とは、チケットの使用の有無に関わらず、チケットの取引に応じた最低限の支払いとして保証されている金額を指す。最低保証額としては、予め設定された絶対値(例えば3000円等)、販売者の当該チケットの仕入れ値、又はチケットの流通価格に対して予め設定された比率に応じた額(例えば流通価格の60%等)のように、任意に設定することができる。
【0171】
(8)その他の変形例
記憶装置11は、ネットワークNWを介して、端末装置10と接続されてもよい。ディスプレイ15は、端末装置10に内蔵されてもよい。記憶装置21は、ネットワークNWを介して、チケット管理サーバ20と接続されてもよい。
上記の情報処理の各ステップは、処理に矛盾が生じない範囲において、その順序を変更することができる。
【0172】
また、還元率を、チケットの流通価格に対して累進的に変化させてもよい。具体的には、流通価格の増加に伴って還元率が増加し、これに応じて販売者への支払比率が減少するように、流通価格の価格帯に応じた還元率および支払比率の設定を行ってもよい。例えば、還元率および支払比率は、以下のように設定することができる。
・流通価格が1万円以内の場合
還元率:流通価格の10%
支払比率:流通価格の20%
・流通価格が1万円~1万5千円の場合
還元率:流通価格の15%
支払比率:流通価格の20%
・流通価格が1万5千円を超える場合
還元率:流通価格の20%
支払比率:流通価格の10%
これにより、チケットの流通価格の増加に伴って、販売者への支払比率が減少するので、販売者が極端にチケット価格を高騰させることを抑制することができる。
【0173】
また、チケットが使用されなかった場合に、手数料の一部のうち、使用評価額よりも少ない額を、追加支払費用として販売者に支払う場合には、回収費用は売上基準額および追加支払額となる。そして、チケットが使用された場合との回収費用を比較すると、以下の関係が成り立つ。
・(売上基準額+使用評価額)>(売上基準額+追加支払額)
すなわち、チケットが使用された場合の回収費用が、チケットが使用されなかった場合の回収費用よりも高額となる。
【0174】
また、各種の手数料、使用評価額、および還元費用の額を、定額としてもよい。
また、チケットの流通において設定された定価、手数料率、還元率などの値を、チケット販売者に対して公開してもよい。チケット販売者は、公開されている値を見て、該当するチケットを仕入れるかどうかを決めることができる。
【0175】
上記説明では、イベントのチケットを例に挙げて説明したが、システム1、2が扱うチケットは、イベント(行事、催し物)に限られない。すなわち、以下の要件を満たすサービスに対して、システム1、2を適用することができる。
・サービスの対象が、ファンを有する特定の概念に立脚すること
・当該サービスの提供を受けるための対価の支払いの証票として、チケットが発行されること
このような条件を満たすその他のサービスとしては、映画館、美術館、博物館、劇場、アミューズメントパーク、交通機関、飲食店、ブランドショップなどが挙げられる。また、これらに関連するサービスのうち、電気通信回線を介して提供されるサービスに関するチケットにシステム1、2を適用してもよい。
【0176】
以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態および変形例は、組合せ可能である。
【符号の説明】
【0177】
1、2 :情報処理システム
10 :端末装置10
11 :記憶装置
12 :プロセッサ
20 :チケット管理サーバ
21 :記憶装置
22 :プロセッサ
40 :トークン管理・商材引換サーバ
41 :記憶装置
42 :プロセッサ
50 :分散型台帳システム
55 :ノードコンピュータ