JP2014126959A - チケット処理システム、チケット処理システムの制御方法、及びプログラム - Google Patents

Abstract

【課題】チケットの転売にかかるトラブルを防止し、キャンセルされたチケットの有効活用を実現することが可能なチケット処理システムを提供すること。
【解決手段】第１の受付部７０は、物理的又は電子チケットの購入の申込みをユーザから受け付ける。購入処理実行部７２は、チケットの購入の申込みが受け付けられた場合に、チケットの購入処理を実行する。第２の受付部７４は、チケットのキャンセル又は譲渡の申込みを、チケットを購入した購入ユーザから受け付ける。出品処理実行部７６は、チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、チケットをオークションサービスに出品するための出品処理を実行する。
【選択図】図１３

Description

本発明はチケット処理システム、チケット処理システムの制御方法、及びプログラムに関する。

コンサートやスポーツの試合等のチケットを販売するためのシステムが知られている。例えば、特許文献１は電子チケットをユーザに発行するシステムについて開示している。

特開２０１２−７３８９０号公報

一般的に、コンサートやスポーツの試合等のチケットのキャンセルは認められていないため、チケットの購入者がコンサート又はスポーツの試合等に行くことができなくなった場合、チケットが無駄になってしまうことがある。そこで、例えば購入者がチケットをオークションサービスに出品することで、チケットを購入し損ねた者がチケットを購入できるようになり、その結果、チケットが無駄にならなくなり、チケットの有効活用が実現できるようになる。

しかしながら、チケットの転売は詐欺に繋がる等の理由から、興行主はチケットをオーションサービスに出品することを禁じていることが多い。また仮に、チケットをオークションサービスに出品することが許容されたとしても、チケットを購入し損ねた者は、出品されたチケットや出品者の正当性を信じることができず、オークションサービスでチケットを購入することをためらってしまう場合がある。これらの理由より、キャンセルされたチケットの有効活用を実現することは困難であった。

本発明は上記課題に鑑みてなされたものであって、その目的は、チケットの転売にかかるトラブルを防止し、キャンセルされたチケットの有効活用を実現することが可能なチケット処理システム、チケット処理システムの制御方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明に係るチケット処理システムは、物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付手段と、前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行手段と、前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付手段と、前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行手段と、を含むことを特徴とする。

また、本発明に係るチケット処理システムの制御方法は、物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付ステップと、前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行ステップと、前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付ステップと、前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行ステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付手段、前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行手段、前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付手段、及び、前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行手段、としてコンピュータを機能させるためのプログラムである。

また、本発明に係る情報記憶媒体は、上記プログラムを記録したコンピュータ読み取り可能な情報記憶媒体である。

また、本発明の一態様では、前記オークションサービスに出品された前記チケットが落札された場合、前記チケットのキャンセル又は譲渡の申込みを行った前記購入ユーザから徴収する料金を、前記購入ユーザが前記チケットを購入した場合の購入価格と、前記オークションサービスにおける前記チケットの落札価格と、に基づいて決定する徴収料金決定手段を含むようにしてもよい。

また、本発明の一態様では、前記徴収料金決定手段は、前記購入価格に基づいて決定される基準価格よりも前記落札価格が高いか否かの判定結果に基づいて、前記購入ユーザから徴収する料金を決定するようにしてもよい。

また、本発明の一態様では、前記徴収料金決定手段は、前記落札価格が前記基準価格よりも高い場合に、前記購入ユーザから徴収する料金を零に決定するようにしてもよい。

また、本発明の一態様では、前記購入処理実行手段は、前記購入ユーザに電子チケットを発行するための処理を実行する手段を含み、前記チケット処理システムは、前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記購入ユーザに発行された前記電子チケットの利用を不可にするための処理を実行する手段と、前記オークションサービスに出品された前記チケットが落札された場合に、前記チケットを落札したユーザに新たな電子チケットを発行するための処理を実行する手段と、を含むようにしてもよい。

また、本発明の一態様では、下限価格を決定する手段と、前記オークションサービスにおいて、前記下限価格よりも低い落札価格で前記チケットが落札されることを制限する手段と、を含むようにしてもよい。

また、本発明の一態様では、前記オークションサービスに出品された前記チケットの価格を時間経過に伴って下げていく価格制御手段と、前記オークションサービスに出品された前記チケットの落札の申込みをユーザから受け付ける手段と、前記チケットの落札の申込みが受け付けられた時点における価格を前記落札価格として決定する手段と、を含み、前記価格制御手段は、前記チケットが示す日における前記価格の下落速度を、前記チケットが示す前記日以前における前記価格の下落速度よりも大きく設定する手段と、前記チケットが示す日時以降における前記価格の下落速度を、前記チケットが示す前記日時以前における前記価格の下落速度よりも大きく設定する手段と、の少なくとも一方を含むようにしてもよい。

また、本発明の一態様では、前記オークションサービスに出品された前記チケットが落札されなかった場合に、前記購入ユーザと所定の関係を有するユーザに前記チケットを譲渡する処理を実行する手段を含むようにしてもよい。

本発明によれば、販売者と転売者とが同一又は信頼関係にある者同士で構成されれば、チケットの信頼性を確保しつつ、キャンセルされたチケットの有効活用を実現することが可能になる。特に電子チケットの場合、その処理も極めて容易になる。

本発明の実施形態に係るチケット処理システムの全体構成の一例を示す図である。 チケット処理サーバのハードウェア構成の一例を示す図である。 購入画面の一例を示す図である。 購入履歴画面の一例を示す図である。 入札画面の一例を示す図である。 落札手数料、キャンセル手数料、及び、チケットをキャンセルしたユーザへの返金額の例について示す図である。 ユーザテーブルの一例を示す図である。 イベントテーブルの一例を示す図である。 チケットテーブルの一例を示す図である。 出品テーブルの一例を示す図である。 入札履歴テーブルの一例を示す図である。 課金履歴テーブルの一例を示す図である。 チケット処理システムの機能ブロック図である。 チケット処理システムで実行される処理の一例を示す図である。 チケット処理システムで実行される処理の一例を示す図である。 チケット処理システムで実行される処理の一例を示す図である。 チケット処理システムで実行される処理について説明するための図である。

以下、本発明の実施形態の例について図面に基づき詳細に説明する。

図１は、本発明の実施形態に係るチケット処理システムの全体構成の一例を示す。図１に示すように、本実施形態に係るチケット処理システム１はチケット処理サーバ１０、オークションサーバ２０、及びデータベース３０を含む。

チケット処理サーバ１０はチケット販売サービスを提供するサーバである。チケット処理サーバ１０は、ユーザ端末３からの要求に応じて、チケット販売サービスに関する処理を実行する。なお、チケット販売サービスは、チケットを物理的に発行せず、ＩＤ管理するような所謂電子チケットをユーザに発行するようなものであってもよいし、紙媒体のチケットに代表される物理的チケットをユーザに発行するものであってもよい。

以下では、電子チケットをユーザに発行するようなチケット販売サービスがチケット処理サーバ１０によって提供される場合について主に説明する。このチケット販売サービスでは、例えば、ユーザ端末３をチケットとして機能させるためのデータがユーザ端末３に送信され、ユーザ端末３がチケットとして用いられることになる。なお、ユーザ端末３をチケットとして機能させるための方式としては、例えば、コード画像（バーコード又はＱＲコード（登録商標）等）をユーザ端末３の表示部に表示させるような方式を採用してもよいし、ユーザ端末３に備えられるＮＦＣ非接触ＩＣカード機能を利用するような方式を採用してもよい。

図２はチケット処理サーバ１０のハードウェア構成の一例を示す。図２に示すように、チケット処理サーバ１０は制御部１１、記憶部１２、光ディスクドライブ部１３、及び通信部１４を含む。

制御部１１は例えば１又は複数のマイクロプロセッサを含み、記憶部１２に記憶されたオペレーティングシステム又はプログラムに従って処理を実行する。記憶部１２は主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭであり、補助記憶部はハードディスク又はソリッドステートドライブ等である。

光ディスクドライブ部１３は、光ディスク（情報記憶媒体）に記録されたプログラムやデータを読み出す。プログラムやデータは光ディスクを介して記憶部１２に供給される。すなわち、光ディスクに記憶されたプログラムやデータが光ディスクドライブ部１３によって読み出され、記憶部１２に記憶される。

チケット処理サーバ１０は、光ディスク以外の情報記憶媒体（例えばメモリカード）に記憶されたプログラム又はデータを読み出すための構成要素を含むようにしてもよい。そして、光ディスク以外の情報記憶媒体を介してプログラムやデータが記憶部１２に供給されるようにしてもよい。

通信部１４は通信ネットワーク２を介してデータ通信を行うためのものである。プログラム及びデータは通信ネットワーク２を介して記憶部１２に供給されるようにしてもよい。

オークションサーバ２０はオンラインオークションサービスを提供するサーバである。オークションサーバ２０は、ユーザ端末３又はチケット処理サーバ１０からの要求に応じて、オークションサービスに関する処理を実行する。

オークションサーバ２０のハードウェア構成はチケット処理サーバ１０と同様である。チケット処理サーバ１０とオークションサーバ２０との間では相互にデータ通信することが可能である。なお、チケット処理サーバ１０とオークションサーバ２０とは一つのサーバコンピュータによって実現されるようにしてもよい。

ところで、図１では、チケット販売サービスとオークションサービスとが同一の業者によって提供される場合を想定しているため、オークションサーバ２０がチケット処理システム１に含まれている。しかしながら、チケット販売サービスとオークションサービスとは別の業者によって提供されるようにしてもよい。すなわち、オークションサーバ２０はチケット処理システム１に含まれていなくてもよく、オークションサーバ２０はチケット処理システム１外にあってもよい。この場合、通常チケット販売サービス業者とオークションサービス業者とは、そのチケットの扱いに関する信頼関係が確立されているのが一般的である。

チケット処理サーバ１０及びオークションサーバ２０はデータベース３０にアクセスすることが可能である。データベース３０は、チケット処理サーバ１０及びオークションサーバ２０とは別のサーバコンピュータに構築されていてもよいし、チケット処理サーバ１０及びオークションサーバ２０のいずれかに構築されていてもよい。例えば、チケット販売サービスを提供するために必要なデータや、オークションサービスを提供するために必要なデータがデータベース３０に記憶される。データベース３０に記憶されるデータについては後述する（図７〜１２参照）。

なお、チケット販売サービスとオークションサービスとが別の業者によって提供される場合には、チケット販売サービスを提供するために必要なデータを記憶するためのデータベースと、オークションサービスを提供するために必要なデータを記憶するためのデータベースとを別々に構築するようにしてもよい。チケット販売サービスとオークションサービスとが同一の業者によって提供される場合であっても、上記のデータベースを別々に構築するようにしてもよい。

ユーザ端末３はユーザによって使用される情報処理装置である。ユーザ端末３は、例えば携帯電話、携帯情報端末、又はパーソナルコンピュータ等である。チケット処理サーバ１０とユーザ端末３との間では通信ネットワーク２を介してデータ通信することが可能である。オークションサーバ２０とユーザ端末３との間でも通信ネットワーク２を介してデータ通信することが可能である。

チケット販売サービスを利用する場合にユーザが行う手順について説明する。まず、ユーザはユーザ登録の手続きを行う。例えば、ユーザは、チケット処理サーバ１０によって提供されるユーザ登録用のウェブページにユーザ端末３からアクセスする。そして、ユーザ端末３の表示部に表示されるユーザ登録画面において、ユーザは自らの情報（例えばパスワード、メールアドレス、及びクレジットカード情報等）を入力する。

ユーザ登録画面において入力された情報はチケット処理サーバ１０に送信され、データベース３０に記憶される。この際、ユーザを一意に識別するためのユーザＩＤが生成され、ユーザ登録画面において入力された情報はこのユーザＩＤに関連づけて記憶される。なお、ユーザＩＤはユーザが指定できるようにしてもよい。

チケット販売サービスにおいてチケットを購入したいユーザはチケット処理サーバ１０にユーザ端末３からアクセスする。ユーザ認証が完了した後、ユーザは、チケット販売サービスにおいて提供されているチケットのうちから所望のチケットを選択する。所望のチケットがユーザによって選択された場合、そのチケットを購入するための購入画面がユーザ端末３の表示部に表示される。

図３は購入画面の一例を示す。購入画面４０には、ユーザが選択したチケットに関する情報（イベント名、日時、場所、座席、及び価格）が表示される。また、購入画面４０には枚数欄４２及び購入ボタン４４が表示される。ユーザはチケットに関する情報を確認した後、枚数欄４２において枚数を指定し、購入ボタン４４をクリックする。

購入ボタン４４がクリックされた場合、チケットの購入処理が実行される。例えば、決済処理や電子チケットの発行処理が実行される。これらの処理が実行された後、例えば、ユーザの購入履歴を示す購入履歴画面がユーザ端末３の表示部に表示される。

図４は購入履歴画面の一例を示す。購入履歴画面５０にはユーザが購入したチケットのリストが表示される。購入履歴画面５０では表示ボタン５２及び印刷ボタン５４が各チケットに関連づけて表示される。

表示ボタン５２がクリックされた場合、チケットの識別情報（チケットＩＤ）を示すコード画像がユーザ端末３の表示部に表示される。この場合、ユーザ端末３がチケットとして機能することになる。すなわち、イベント当日にイベント会場に入場する際にユーザはユーザ端末３の表示部に表示されたコード画像を提示する。この場合、ユーザ端末３の表示部に表示されたコード画像が読み取られ、ユーザが当該イベントのチケットを購入した者であるか否かが確認されることになる。

印刷ボタン５４がクリックされた場合、チケットの識別情報（チケットＩＤ）を示すコード画像が、ユーザ端末３と通信可能なプリンタから印刷される。この場合、コード画像が印刷された用紙がチケットとして機能することになる。すなわち、イベント当日にイベント会場に入場する際にユーザは用紙に印刷されたコード画像を提示する。この場合、用紙に印刷されたコード画像が読み取られ、ユーザが当該イベントのチケットを購入した者であるか否かが確認されることになる。

また購入履歴画面５０では、キャンセル（譲渡）することが可能な各チケットに関連づけて、キャンセル（譲渡）ボタン５６が表示される。キャンセル（譲渡）ボタン５６はチケットをキャンセルするためのボタンである。後述するように、チケット処理システム１では、キャンセルされたチケットがオークションサーバ２０によって提供されるオークションサービスに出品され、落札者に譲渡されるようになっている。このため、キャンセル（譲渡）ボタン５６は、チケットをオークションサービスに出品するためのボタンであるということもできるし、チケットを他人に譲渡するためのボタンでもあるということもできる。

キャンセル（譲渡）ボタン５６がクリックされた場合、チケット処理サーバ１０はチケットをオークションに出品することをオークションサーバ２０に要求する。オークションサーバ２０は、チケット処理サーバ１０からの要求に応じて、チケットをオークションに出品する。この場合、チケットをキャンセルしたユーザではなく、チケット販売会社（チケット販売サービスの提供者）がチケットの出品者として設定される。

例えば、チケット販売サービスにおいて所望のチケットを購入し損ねてしまったユーザは、オークションに出品されたチケットを落札することによってチケットを入手することができる。

ここで、オークションに出品されているチケットを落札するためにユーザが行う手順について説明する。チケット処理システム１では、チケット販売サービスとオークションサービスとでユーザ情報が共有されるようになっており、チケット販売サービスを利用するためのユーザ登録を完了しているユーザはオークションサービスを利用することができる。なお、チケット販売サービスとオークションサービスとでユーザ情報が共有されていないような場合には、ユーザは、チケット販売サービスを利用するためのユーザ登録の手続きとは別に、オークションサービスを利用するためのユーザ登録の手続きを行う必要がある。

オークションに出品されているチケットを落札したいユーザはオークションサーバ２０にユーザ端末３からアクセスする。ユーザ認証が完了した後、ユーザは、オークションに出品されているチケットのうちから所望のチケットを選択する。所望のチケットがユーザによって選択された場合、そのチケットに入札するための入札画面がユーザ端末３の表示部に表示される。

図５は入札画面の一例を示す。入札画面６０には、オークションに出品された商品に関する情報が表示される。図５に示す入札画面６０は、オークションに出品されたチケットに入札するための画面であるため、チケットに関する情報が表示されている。

入札画面６０には入札ボタン６２が表示される。入札ボタン６２がクリックされた場合、入札価格（希望購入価格）を指定するための画面がユーザ端末３の表示部に表示される。この画面においてユーザは入札価格を指定する。

オークションサービスでは、入札受付期間内において最も高い入札価格を提示したユーザが落札者として決定される。落札者として決定されたユーザは自らが提示した入札価格で商品を入手することができる。このため、商品を落札したいユーザは他のユーザよりも高い入札価格を提示する必要がある。

なお、オークションサービスの方式は上記の方式に限られない。例えば、オークションサービスでは、出品された商品の価格を最初に上限価格に設定し、時間経過に伴って商品の価格を上限価格から徐々に自動的に下げていくようにしてもよい。そして、いずれかのユーザが入札した場合にはそのユーザを落札者として決定するようにしてもよい。この場合、落札者として決定されたユーザは、入札した時点の価格で商品を入手することができる。この場合、商品を落札したいユーザは商品の価格が所望の価格まで下がった時点で入札を行うことになる。またこの場合、商品を落札したいユーザは他のユーザよりも早く入札を行う必要がある。

オークションに出品されたチケットを落札したユーザは、落札価格に手数料（以下「落札手数料」と記載する。）を加えた金額をオークション会社（オークションサービスの提供者）に支払う必要がある。落札手数料は落札価格に基づいて決定される。例えば、落札価格に所定のパーセント値（例えば１０％）を乗じることによって得られる金額が落札手数料として決定される。

また、チケットを購入したユーザがキャンセルしたチケットがオークションで落札された場合、原則として、落札価格に相当する金額が、チケットをキャンセルしたユーザに返金される。ただし、ユーザがチケット販売サービスでチケットを購入した際の購入価格（言い換えれば、チケット販売サービスにおける販売価格）よりも落札価格の方が高い場合には、購入価格に相当する金額がユーザに返金される。この場合、落札価格と購入価格との差額はチケット販売会社に納められる。

また、原則として、チケットをキャンセルしたユーザは、チケットをキャンセルしたことに起因する手数料（以下「キャンセル手数料」と呼ぶ。）をチケット販売会社に支払う必要がある。キャンセル手数料はチケットの購入価格に基づいて決定される。例えば、購入価格に所定のパーセント値（例えば１０％）を乗じることによって得られる金額がキャンセル手数料として決定される。

図６は、落札手数料、キャンセル手数料、及び、チケットをキャンセルしたユーザ（キャンセル者）への返金額の例について示す図である。なお図６では、図３に示すチケット（すなわち、チケット販売サービスにおいて５０００円で購入されたチケット）がオークションで落札された場合を想定している。また図６では、上記の「所定のパーセント値」が１０％である場合を想定している。

落札価格が３０００円である場合について説明する。この場合の落札手数料は３００円であり、チケットを落札したユーザは３３００円を支払う必要がある。この場合、落札価格が購入価格（５０００円）以下であるため、落札価格に相当する金額（３０００円）がチケットをキャンセルしたユーザに返金される。また、この場合のキャンセル手数料は５００円である。このため、実質的な返金額は落札価格から手数料を引いた金額（２５００円）となる。

落札価格が５０００円である場合について説明する。この場合の落札手数料は５００円であり、チケットを落札したユーザは５５００円を支払う必要がある。この場合、落札価格が購入価格（５０００円）以下であるため、落札価格に相当する金額（５０００円）がチケットをキャンセルしたユーザに返金される。また、この場合のキャンセル手数料は５００円である。このため、実質的な返金額は落札価格から手数料を引いた金額（４５００円）となる。

落札価格が５３００円である場合について説明する。この場合の落札手数料は５３０円であり、チケットを落札したユーザは５８３０円を支払う必要がある。この場合、落札価格が購入価格（５０００円）よりも高いため、購入価格に相当する金額（５０００円）がチケットをキャンセルしたユーザに返金される。なお、落札価格と購入価格との差額（３００円）はチケット販売会社に納められる。また、この場合のキャンセル手数料は５００円である。このため、実質的な返金額は購入価格から手数料を引いた金額（４５００円）となる。

落札価格が５５００円である場合について説明する。この場合の落札手数料は５５０円であり、チケットを落札したユーザは６０５０円を支払う必要がある。この場合、落札価格が購入価格（５０００円）よりも高いため、購入価格に相当する金額（５０００円）がチケットをキャンセルしたユーザに返金される。なお、落札価格と購入価格との差額（５００円）はチケット販売会社に納められる。

ところで、この場合、上記差額（５００円）はキャンセル手数料（５００円）と等しい。このような場合、チケット処理システム１ではキャンセル手数料が免除される。その結果、チケットをキャンセルしたユーザには購入価格に相当する金額（５０００円）がそっくりそのまま返金されることになる。

落札価格が７０００円である場合について説明する。この場合の落札手数料は７００円であり、チケットを落札したユーザは７７００円を支払う必要がある。この場合、落札価格が購入価格（５０００円）よりも高いため、購入価格に相当する金額（５０００円）がチケットをキャンセルしたユーザに返金される。なお、落札価格と購入価格との差額（２０００円）はチケット販売会社に納められる。

ところで、この場合、上記差額（２０００円）はキャンセル手数料（５００円）よりも高い。このような場合、チケット処理システム１ではキャンセル手数料が免除される。その結果、チケットをキャンセルしたユーザには購入金額（５０００円）がそっくりそのまま返金されることになる。

なお、以上では、上記差額が通常のキャンセル手数料（５００円）以上になった場合にキャンセル手数料が免除されるようになっていたが、上記差額が通常のキャンセル手数料（５００円）未満である場合にもキャンセル手数料が軽減されるようにしてもよい。例えば、落札価格が５３００円である場合の上記差額は３００円である。この場合、通常のキャンセル手数料（５３００円）から上記差額（３００円）を引くことによって得られる金額（２００円）がキャンセル手数料として徴収されるようにしてもよい。

以上に説明したようなチケット処理システム１によれば、ユーザがキャンセルしたチケットがチケット販売会社によってオークションに出品される。このようなチケット処理システム１では、チケットの転売が詐欺に繋がるおそれがないため、興行主もオークションへのチケットの出品を許容することが期待できる。また、オークションに出品されたチケットを落札しようとするユーザも、出品されたチケットや出品者の正当性を心配する必要がなくなる。これらの理由より、チケット処理システム１によれば、キャンセルされたチケットの有効活用を実現することが可能になる。

以下、以上のようなチケット処理システム１を実現するための構成について説明する。まず、データベース３０に記憶されるデータの一例について説明する。図７〜図１２はデータベース３０に記憶されるデータの一例について示す。

図７はユーザテーブルの一例を示す。ユーザテーブルは、チケット販売サービス及びオークションサービスを利用するユーザの一覧を示す。例えば、ユーザテーブルは「ユーザＩＤ」、「パスワード」、「メールアドレス」、及び「クレジットカード情報」フィールドを含む。

「ユーザＩＤ」フィールドには、ユーザを一意に識別するための情報（ユーザＩＤ）が登録される。「パスワード」フィールドには、ユーザによって指定されたパスワードが登録される。「メールアドレス」フィールドには、ユーザのメールアドレスが登録され、「クレジットカード情報」フィールドには、ユーザのクレジットカードに関する情報が登録される。

なお、チケット販売サービスとオークションサービスとの間でユーザ情報を共有しない場合には、チケット販売サービス用のユーザテーブルと、オークションサービス用のユーザテーブルとが別々に設けられることになる。この場合、チケット販売サービスにおけるユーザＩＤと、オークションサービスにおけるユーザＩＤとが異なるため、チケット販売サービスにおけるユーザＩＤと、オークションサービスにおけるユーザＩＤとの対応関係を示すデータが別途必要となる。

図８はイベントテーブルの一例を示す。イベントテーブルは、チケット販売サービスにおいてチケットが販売されているイベントの一覧を示す。例えば、イベントテーブルは「イベントＩＤ」、「イベント名」、「日時」、及び「会場」フィールドを含む。

「イベントＩＤ」フィールドには、イベントを一意に識別するための情報（イベントＩＤ）が登録される。「イベント名」フィールドにはイベントの名称が登録される。「日時」フィールドにはイベントの開催日時が登録され、「会場」フィールドにはイベントの開催会場が登録される。

図９はチケットテーブルの一例を示す。チケットテーブルは各イベントのチケットの購入状況を示す。チケットテーブルは「イベントＩＤ」、「座席」、「価格」、「購入者」、「チケットＩＤ」、「キャンセルフラグ」、及び「出品ＩＤ」フィールドを含む。例えば、各イベントの各座席に対応するレコードがチケットテーブルに含まれる。

「イベントＩＤ」フィールドはイベントテーブルの「イベントＩＤ」フィールドと同様である。「座席」フィールドには、座席を一意に識別する情報（例えば座席番号）が登録され、「価格」フィールドには販売価格が登録される。

「購入者」フィールドには、チケットを購入したユーザのユーザＩＤが登録される。「購入者」フィールドにユーザＩＤが登録されている座席は既に売れている座席であり、「購入者」フィールドにユーザＩＤが登録されていない座席は売れ残っている座席である。「チケットＩＤ」フィールドには、ユーザに発行された電子チケットを一意に識別するチケットＩＤが登録される。

「キャンセルフラグ」フィールドには、チケットを購入したユーザがチケットをキャンセルしたか否かを示す情報が登録される。例えば、値「０」又は「１」が「キャンセルフラグ」フィールドに登録される。値「０」は、ユーザがチケットをキャンセルしていないことを示し、値「１」は、ユーザがチケットをキャンセルしたことを示す。

「出品ＩＤ」フィールドには、キャンセルされたチケットがオークションに出品された場合にそのチケットの出品ＩＤが登録される。なお、出品ＩＤは、オークションに出品されている商品を一意に識別するための情報である。

図１０は出品テーブルの一例を示す。出品テーブルは、オークションに出品された商品の一覧を示す。例えば、出品テーブルは「出品ＩＤ」、「出品者」、「商品情報」、「開始価格」、「開始日時」、及び「終了日時」フィールドを含む。

「出品ＩＤ」フィールドには、オークションに出品されている商品を一意に識別するための情報（出品ＩＤ）が登録される。「出品者」フィールドには、出品者を一意に識別するための情報が登録される。例えば、キャンセルされたチケットが出品されている場合には、チケット販売会社の識別情報が「出品者」フィールドに登録される。

「商品情報」フィールドには、出品されている商品に関する情報が登録される。例えば、出品されている商品がチケットである場合には、イベント名、日時、会場、及び座席等が「商品情報」フィールドに登録される。

「開始価格」フィールドには開始価格が登録される。開始価格はオークションの開始時点における商品の価格である。オークションサービス（オークションサーバ２０）では、開始価格よりも低い落札価格で商品が落札されることが制限される。すなわち、ユーザは少なくとも開始価格以上の価格を入札価格として提示する必要がある。このため、開始価格は入札価格（落札価格）の下限に相当する。

「開始日時」及び「終了日時」フィールドにはオークションの開始日時及び終了日時が登録される。「開始日時」フィールドに登録された開始日時から「終了日時」フィールドに登録された終了日時までの期間がオークション期間（ユーザからの入札を受け付ける期間）である。

図１１は入札履歴テーブルの一例を示す。入札履歴テーブルは、オークションに出品されている各商品に対する入札状況を示す。例えば、入札履歴テーブルは「出品ＩＤ」、「入札者」、「入札日時」、及び「入札価格」フィールドを含む。

「出品ＩＤ」フィールドは出品テーブルの「出品ＩＤ」フィールドと同様である。「入札者」フィールドには、入札したユーザのユーザＩＤが登録される。「入札日時」フィールドには、入札が行われた日時が登録され、「入札価格」フィールドには、ユーザによって提示された入札価格が登録される。

図１２は課金履歴テーブルの一例を示す。課金履歴テーブルはユーザへの課金履歴を示す。例えば、課金履歴テーブルは「日時」、「ユーザＩＤ」、及び「金額」フィールドを含む。「日時」フィールドには、ユーザへの課金が行われた日時が登録される。「ユーザＩＤ」フィールドには、課金対象のユーザのユーザＩＤが登録される。「金額」フィールドには課金額が登録される。

次に、チケット処理システム１で実現される機能ブロックについて説明する。図１３は、チケット処理システム１で実現される機能ブロックのうちの、本発明に関連する機能ブロックを示す機能ブロック図である。

図１３に示すように、チケット処理システム１は第１の受付部７０（第１の受付手段）、購入処理実行部７２（購入処理実行手段）、第２の受付部７４（第２の受付手段）、出品処理実行部７６（出品処理実行手段）、及び徴収料金決定部７８（徴収料金決定手段）を含む。図１３に示す各機能ブロックは例えばチケット処理サーバ１０によって実現される。チケット処理サーバ１０の制御部１１がプログラムに従って処理を実行することによって、制御部１１が図１３に示す各機能ブロックとして機能するようになる。

第１の受付部７０について説明する。第１の受付部７０は、チケットの購入の申込みをユーザから受け付ける。例えば、購入画面４０で購入ボタン４４がクリックされた場合には、チケットの購入の申込みを示すデータがユーザ端末３からチケット処理サーバ１０に送信される。第１の受付部７０は、ユーザ端末３から送信される上記申込みデータを受信する。

購入処理実行部７２について説明する。チケットの購入の申込みが受け付けられた場合に、購入処理実行部７２はチケットの購入処理を実行する。例えば、購入処理実行部７２は、チケットを購入したユーザにチケットを発行するための処理や決済処理等を実行する。

第２の受付部７４について説明する。第２の受付部７４は、チケットを購入したユーザからチケットのキャンセル又は譲渡の申込みを受け付ける。例えば、購入履歴画面５０でキャンセル（譲渡）ボタン５６がクリックされた場合には、チケットのキャンセル（譲渡）の申込みを示すデータがユーザ端末３からチケット処理サーバ１０に送信される。第２の受付部７４は、ユーザ端末３から送信される上記申込みデータを受信する。

出品処理実行部７６について説明する。チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、出品処理実行部７６は、チケットをオークションに出品するための出品処理を実行する。例えば、出品処理実行部７６は、チケットをオークションに出品することをオークションサーバ２０に要求する。

徴収料金決定部７８について説明する。チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、徴収料金決定部７８は、チケットをキャンセルしたユーザから徴収する料金を、当該ユーザがチケットを購入した際の購入価格と、オークションに出品されたチケットの落札価格と、に基づいて決定する。

例えば、徴収料金決定部７８は、購入価格に基づいて決定される基準価格よりも落札価格が高いか否かを判定する。そして、徴収料金決定部７８は、その判定結果に基づいて、チケットをキャンセルしたユーザから徴収する料金を決定する。

例えば、図６に示した例の場合であれば、購入価格（５０００円）と通常のキャンセル手数料（５００円）とを足した金額（５５００円）が「基準価格」に相当している。また、図６に示した例では、落札価格が基準価格（５５００円）よりも高い場合に、チケットをキャンセルしたユーザから徴収する手数料（キャンセル手数料）が零になっている。また、落札価格が基準価格（５５００円）と等しい場合にも、チケットをキャンセルしたユーザから徴収する手数料（キャンセル手数料）が零になっている。

次に、以上に説明した機能ブロックを実現するためにチケット処理システム１で実行される処理について説明する。図１４〜図１６はチケット処理システム１で実行される処理の一例を示す。図１７は図１４〜図１６に示す処理について説明するための図であり、チケットテーブルのあるレコードの変化の一例を示している。以下、図１７を参照しながら、図１４〜図１６に示す処理について説明する。チケット処理サーバ１０の制御部１１がプログラムに従って図１４〜図１６に示す処理を実行することによって、制御部１１が図１３に示す機能ブロックとして機能するようになる。

図１４は、購入画面４０で購入ボタン４４がクリックされた場合に実行される処理の一例を示す。

購入画面４０で購入ボタン４４がクリックされた場合、図１４に示すように、ユーザ端末３の制御部はチケットの購入をチケット処理サーバ１０に要求する（Ｓ１０１）。この場合、チケットを購入するユーザのユーザＩＤ、ユーザが選択したイベントのイベントＩＤ、及びユーザが指定した枚数がチケット処理サーバ１０に送信される。

上記の要求がチケット処理サーバ１０の制御部１１（第１の受付部７０）によって受け付けられた場合、チケット処理サーバ１０の制御部１１（購入処理実行部７２）は決済処理を実行する（Ｓ１０２）。例えば、ユーザ端末３から受信されたユーザＩＤに関連付けられたクレジットカード情報に基づいて、決済処理が実行される。

また、制御部１１（購入処理実行部７２）はチケットを購入したユーザに電子チケットを発行する（Ｓ１０３）。例えば、制御部１１はユーザに提供する座席を決定する。また制御部１１は、ユーザに提供する座席に関し、チケットＩＤを生成する。チケットＩＤは既存のチケットＩＤと重複しないようにして生成される。そして、制御部１１はチケットテーブルにアクセスし、生成されたチケットＩＤをユーザに提供する座席に関連付けて登録する。

例えば図１７（Ａ）に示す例では、イベント「Ｅ０００１」の座席「Ａ−３」がユーザ「Ｕ０００１」に提供する座席として決定されている。また図１７（Ａ）に示す例では「１２０５９８５６４」がチケットＩＤとして生成されており、チケットＩＤ「１２０５９８５６４」が座席「Ａ−３」に関連付けられている。

ステップＳ１０３が完了した後、制御部１１はチケットを購入したユーザに電子チケット情報を送信する（Ｓ１０４）。電子チケット情報は、ステップＳ１０３で発行された電子チケットに関する情報であり、例えば、電子チケットを取得するためのＵＲＬ情報や、電子チケットの発行が完了したことを示すメッセージ情報を含む。

電子チケット情報が受信されたユーザ端末３では、ユーザによって所定の操作が行われた場合に制御部１１が電子チケットをチケット処理サーバ１０に要求する（Ｓ１０５）。そして、上記の要求を受け付けたチケット処理サーバ１０では制御部１１が電子チケットをユーザ端末３に送信する（Ｓ１０６）。

例えば、ステップＳ１０４では、購入履歴画面５０のデータがユーザ端末３に送信される。また、電子チケットを取得するためのＵＲＬ情報を示す電子メールがユーザに送信される。そして、購入履歴画面５０の表示ボタン５２又は印刷ボタン５４がクリックされた場合や、電子メールに記載されたＵＲＬ情報が指定された場合に、上記の要求がユーザ端末３からチケット処理サーバ１０に送信される（Ｓ１０５）。この場合、チケット処理サーバ１０の制御部１１はチケットＩＤを示すコード画像を生成し、そのコード画像をユーザ端末３に送信する（Ｓ１０６）。そして、チケット処理サーバ１０から受信されたコード画像がユーザ端末３の表示部に表示されたり、ユーザ端末３と通信接続されたプリンタから出力されたりする。

イベント当日にイベント会場に入場する際、ユーザは上記のコード画像が表示されたユーザ端末３又は上記のコード画像が印刷された用紙を提示する。この場合、コード画像が読み取り装置によって読み取られ、そのコード画像が示すチケットＩＤがチケット処理サーバ１０に送信される。チケット処理サーバ１０ではチケットテーブルが参照され、チケットＩＤが有効なものであるか否かが確認される。チケットＩＤが有効なものであると確認されると、ユーザはイベント会場に入場できるようになる。

あるいは、ステップＳ１０４では、電子チケットの発行が完了したことを示すメッセージ情報が電子メール等によってユーザに送信される。上記の電子メールを受け取ったユーザは、例えば電子チケット用のアプリケーションプログラムをユーザ端末３において起動する。このアプリケーションプログラムは、例えば、ユーザ端末３に備えられるＮＦＣ非接触ＩＣカード機能を利用してユーザ端末３をチケットとして機能させるためのアプリケーションプログラムである。このアプリケーションプログラムが起動された場合、上記の要求がユーザ端末３からチケット処理サーバ１０に送信される（Ｓ１０５）。この場合、チケット処理サーバ１０の制御部１１はチケットＩＤをユーザ端末３に送信する（Ｓ１０６）。ユーザ端末３では上記のアプリケーションプログラムによってチケットＩＤが用いられることによって、ユーザ端末３がチケットとして機能するようになる。

イベント当日にイベント会場に入場する際、ユーザは上記のアプリケーションプログラムが起動されたユーザ端末３を提示する。この場合、上記のアプリケーションプログラムと読み取り装置との間でＮＦＣ非接触ＩＣカード機能を介してチケットＩＤが授受され、チケットＩＤがチケット処理サーバ１０に送信される。チケット処理サーバ１０ではチケットテーブルが参照され、チケットＩＤが有効なものであるか否かが確認される。チケットＩＤが有効なものであると確認されると、ユーザはイベント会場に入場できるようになる。以上で図１４に示す処理の説明を終了する。

図１５は、購入履歴画面５０においていずれかのチケットのキャンセル（譲渡）ボタン５６がクリックされた場合に実行される処理の一例を示す。

購入履歴画面５０においていずれかのチケットのキャンセル（譲渡）ボタン５６がクリックされた場合、ユーザ端末３の制御部は、キャンセル対象として選択されたケットのキャンセルをチケット処理サーバ１０に要求する（Ｓ２０１）。この場合、チケットをキャンセルしたユーザのユーザＩＤや、ユーザがキャンセル対象として選択したチケットのチケットＩＤがチケット処理サーバ１０に送信される。

上記の要求がチケット処理サーバ１０の制御部１１（第２の受付部７４）によって受け付けられた場合、チケット処理サーバ１０の制御部１１はチケットテーブルにアクセスし、ユーザ端末３から受信されたユーザＩＤ及びチケットＩＤが関連付けられていることを確認する。この確認が実行された後、制御部１１（出品処理実行部７６）はチケットをオークションに出品することをオークションサーバ２０に要求する（Ｓ２０２）。この場合、チケットに関する情報（例えばイベント名、日時、会場、座席、及び販売価格）がオークションサーバ２０に送信される。

なお、オークションサービスがチケット販売会社とは異なる業者によって提供されているような場合には、オークションへの出品を要求する業者が出品対象のチケットを販売した業者と同一であることを証明するデータもオークションサーバ２０に送信するようにすればよい。そして、オークションへの出品を要求する業者が出品対象のチケットを販売した業者と同一であることがオークションサーバ２０において確認された場合に限って、オークションへの出品要求を受け付けるようにしてもよい。

オークションへの出品要求がオークションサーバ２０によって受け付けられた場合、オークションサーバ２０の制御部は、キャンセル対象として選択されたチケットをオークションに出品する（Ｓ２０３）。

例えば、制御部は出品テーブルにアクセスし、新たなレコードを出品テーブルに追加する。この場合、制御部は出品ＩＤを生成し、その出品ＩＤを上記レコードの「出品ＩＤ」フィールドに登録する。また、制御部は、チケット販売会社のＩＤを上記レコードの「出品者」フィールドに登録する。さらに、制御部は、チケット処理サーバ１０から受信された情報（例えばイベント名、日時、会場、座席、及び販売価格）を上記レコードの「商品情報」フィールドに登録する。

また制御部は開始価格（下限価格）を上記レコードの「開始価格」フィールドに登録する。例えば、予め定められた価格が「開始価格」フィールドに登録される。または、チケット販売サービスにおける販売価格（すなわち、チケット販売サービスにおいてチケットが購入された際の購入価格）に基づいて決定された価格が「開始価格」フィールドに登録される。例えば、販売価格に所定のパーセント値を乗じることによって得られる価格が「開始価格」フィールドに登録される。このように「開始価格」フィールドを設定することによって、チケットの落札価格が低くなりすぎてしまうことを防ぐことが可能になる。

あるいは、チケットをキャンセルするユーザによって開始価格（下限価格）として指定された価格が「開始価格」フィールドに登録されるようにしてもよい。例えば、キャンセル（譲渡）ボタン５６がクリックされた場合には、開始価格の指定を受け付けるための画面がユーザ端末３の表示部に表示されるようにしてもよい。また、チケットをキャンセルするユーザによって開始価格として指定された価格がチケット処理サーバ１０を介してオークションサーバ２０に送信されるようにしてもよい。そして、オークションサーバ２０では、以上のようにして送信された価格が取得され、「開始価格」フィールドに登録されるようにしてもよい。このようにすれば、チケットをキャンセルするユーザはチケットの落札価格が低くなりすぎてしまうことを防ぐことが可能になる。

また制御部は開始日時及び終了日時を上記レコードの「開始日時」及び「終了日時」フィールドに登録する。例えば、現在日時が「開始日時」フィールドに登録される。また、イベントの開催日時に基づいて決定される日時が「終了日時」フィールドに登録される。例えば、イベントの開催日時よりも所定時間前の日時が「終了日時」フィールドに登録される。なお、開始日時に基づいて決定される日時が「終了日時」フィールドに登録されるようにしてもよい。例えば、開始日時から所定時間後の日時が「終了日時」フィールドに登録されるようにしてもよい。

ステップＳ２０３が完了した後、制御部はオークションへの出品が完了したことをチケット処理サーバ１０に通知する（Ｓ２０４）。この場合、オークションに出品されたチケットの出品ＩＤがチケット処理サーバ１０に通知される。つまり、ステップＳ２０３において生成され、かつ、「出品ＩＤ」フィールドに登録された出品ＩＤがチケット処理サーバ１０に通知される。

上記の通知がチケット処理サーバ１０において受信された場合、チケット処理サーバ１０の制御部１１はチケットテーブルにアクセスし、チケットをキャンセルしたユーザに対して発行済みの電子チケットを無効にする（Ｓ２０５）。

ここで、例えば図１７（Ａ）に示すようなチケットＩＤが「１２０５９８５６４」であるチケットがオークションに出品された場合を想定する。この場合、図１７（Ｂ）に示すように、「チケットＩＤ」フィールドに「１２０５９８５６４」が登録されているレコードの「キャンセルフラグ」フィールドが「０」から「１」に更新される。また、オークションサーバ２０から通知された出品ＩＤが上記レコードの「出品ＩＤ」フィールドに登録される。

さらに、上記レコードの「チケットＩＤ」フィールドに登録されたチケットＩＤ（１２０５９８５６４）が消去される。その結果、チケットＩＤ「１２０５９８５６４」の利用は不可となる。例えば、チケットＩＤ「１２０５９８５６４」を示すコード画像がユーザ端末３に既に保存されていて、そのコード画像がイベント当日にイベント会場において提示されたとしても、チケットＩＤ「１２０５９８５６４」はチケットテーブルから消去されているため、チケットＩＤ「１２０５９８５６４」は有効なものであるとは判断されなくなる。すなわち、キャンセルされたチケットが悪用されないように担保され、チケットを落札したユーザが安心してチケットを利用できるように担保されるようになる。

ステップＳ２０５が完了した後、制御部１１は、キャンセルされたチケットが取り除かれた購入履歴画面５０のデータを生成し、そのデータをユーザ端末３に送信する（Ｓ２０６）。この場合、ユーザ端末３の制御部は、表示部に表示された購入履歴画面５０を、チケット処理サーバ１０から受信されたデータに基づいて更新する（Ｓ２０７）。以上で図１５に示す処理の説明を終了する。

図１６は、チケット処理サーバ１０からオークションサービスに出品されたチケットのオークション期間が終了した場合に実行される処理の一例を示す。

チケット処理サーバ１０からオークションに出品されたチケットのオークション期間が終了した場合、オークションサーバ２０の制御部は落札者を決定する（Ｓ３０１）。例えば、制御部は入札履歴テーブルにアクセスし、入札価格が最も高いユーザを落札者として決定する。また制御部は、落札者として決定されたユーザが提示した入札価格を落札価格として決定する。

なお、ここでは説明の簡便のために省略しているが、落札者を決定する前に、入札価格が最も高いユーザに対して、落札する意思があるか否かを確認するようにしてもよい。そして、入札価格が最も高いユーザが上記の意思を示した場合に限って、入札価格が最も高いユーザを落札者として決定するようにしてもよい。

ステップＳ３０１が完了した後、制御部はチケットを落札したユーザに関する決済処理を実行する（Ｓ３０２）。例えば、チケットを落札したユーザのユーザＩＤに関連付けられたクレジットカード情報に基づいて、制御部は、チケットを落札したユーザから、落札価格に相当する金額を徴収する。さらに、制御部は、チケットを落札したユーザから、落札価格の１０％に相当する金額を落札手数料として徴収する。

ところで、チケット販売会社とオークション会社とが異なる場合、オークション会社は落札価格に相当する金額をチケット販売会社に納めることになる。なお、この場合、オークション会社はチケット販売会社から手数料（入札手数料）を徴収するようにしてもよい。

ステップＳ３０２が完了した後、制御部は落札情報をチケット処理サーバ１０に送信する（Ｓ３０３）。例えば、チケットを落札したユーザのユーザＩＤと落札価格とが落札情報としてチケット処理サーバ１０に送信される。

落札情報がチケット処理サーバ１０において受信された場合、チケット処理サーバ１０の制御部１１は、チケットをキャンセルしたユーザに関する決済処理を実行する（Ｓ３０４）。

例えば、制御部１１は落札価格がチケット販売サービスにおける販売価格以下であるか否かを判定する。落札価格が販売価格以下である場合、制御部１１は、チケットをキャンセルしたユーザに落札価格に相当する金額を返金する。一方、落札価格が販売価格よりも高い場合、制御部１１は、チケットをキャンセルしたユーザに販売価格に相当する金額を返金する。

また、制御部１１は落札価格が基準価格よりも高いか否かを判定する。例えば、制御部１１は、チケット販売サービスにおける販売価格と通常のキャンセル手数料とに基づいて、基準価格を設定する。より具体的には、制御部１１は、チケット販売サービスにおける販売価格と通常のキャンセル手数料とを足すことによって得られる金額を基準価格として設定する。なお、通常のキャンセル手数料は、チケット販売サービスにおける販売価格に所定のパーセント値（例えば１０％）を乗じることによって得られる金額である。または、通常のキャンセル料は予め定められた金額であってもよい。

落札価格が基準価格以下である場合、制御部１１（徴収料金決定部７８）はチケットをキャンセルしたユーザから通常のキャンセル手数料を徴収する。一方、落札価格が基準価格よりも高い場合、制御部１１（徴収料金決定部７８）はチケットをキャンセルしたユーザからキャンセル手数料を徴収しない。

ステップＳ３０４が完了した後、制御部１１はチケットを落札したユーザに新たな電子チケットを発行する（Ｓ３０５）。ステップＳ３０５は基本的に図１４のステップＳ１０３と同様である。

ここで、例えば図１７（Ｂ）に示すような出品ＩＤが「Ａ０００１」であるチケットがユーザ「Ｕ００５０」によって落札された場合を想定する。この場合、図１７（Ｃ）に示すように、「出品ＩＤ」フィールドに「Ａ０００１」が登録されたレコードの「ユーザＩＤ」フィールドが「Ｕ００５０」に更新される。また、チケットＩＤが新たに生成され、そのチケットＩＤが上記レコードの「チケットＩＤ」フィールドに登録される。さらに、上記レコードの「キャンセルフラグ」フィールドが「１」から「０」に更新され、上記レコードの「出品ＩＤ」フィールドに登録された出品ＩＤが消去される。

なお、図１５のステップＳ２０５を省略し、ステップＳ３０５において、上記レコードの「チケットＩＤ」フィールドを、元々のチケットＩＤ（すなわち、チケットをキャンセルしたユーザに対して発行されていたチケットＩＤ）から、新たに生成されたチケットＩＤ（すなわち、チケットを落札したユーザに対して新たに発行されたチケットＩＤ）に更新するようにしてもよい。

ステップＳ３０５が完了した後、制御部１１はチケットを落札したユーザのユーザ端末３に電子チケット情報を送信する（Ｓ３０６）。また、チケットを落札したユーザのユーザ端末３が電子チケットをチケット処理サーバ１０に要求した場合（Ｓ３０７）、チケット処理サーバ１０の制御部１１はチケットを落札したユーザのユーザ端末３に電子チケットを送信する（Ｓ３０８）。ステップＳ３０６〜Ｓ３０８はステップＳ１０４〜Ｓ１０６と同様であるため、ここでは説明を省略する。以上で図１６に示す処理の説明を終了する。

なお、チケットが落札されなかった場合（例えば、いずれのユーザも入札を行わなかった場合等）には、ステップＳ３０１〜Ｓ３０８の代わりに、下記に説明するような処理が実行される。

すなわち、チケットが落札されなかった場合、オークションサーバ２０の制御部は、出品ＩＤとともに、チケットが落札されなかった旨をチケット処理サーバ１０に通知する。

この場合、チケットのキャンセル（譲渡）に成功しなかったことになり、上記の通知を受け取ったチケット処理サーバ１０では、チケットの状態をキャンセル（譲渡）ボタン５６がクリックされる前の状態に戻すための処理が実行される。すなわち、チケットをユーザ（キャンセルしようとしたユーザ）にチケットを戻すための処理が実行される。具体的には、制御部１１はチケットテーブルにアクセスし、オークションサーバ２０から受信した出品ＩＤが「出品ＩＤ」フィールドに登録されているレコードを更新する。

すなわち、制御部１１は、チケットのキャンセル（譲渡）がかなわなかったユーザのためにチケットＩＤを生成し直し、そのチケットＩＤを上記レコードの「チケットＩＤ」に登録する。また、制御部１１は上記レコードの「キャンセルフラグ」フィールドを「１」から「０」に更新する。さらに、制御部１１は上記レコードの「出品ＩＤ」フィールドに登録された出品ＩＤを消去する。

また、制御部１１は、チケットのキャンセル（譲渡）に成功しなかったことを示すメッセージ情報を、発行し直された電子チケットに関する電子チケット情報（例えばＵＲＬ情報）とともに電子メール等によってユーザに送信する。

なお、以上に説明した処理では、チケットが落札されなかった場合、チケットのキャンセル（譲渡）がかなわなかったユーザにチケットを戻すようになっていたが、チケットをユーザに戻さないようにしてもよい。例えば、制御部１１はチケットをオークションサービスに再出品するようにしてもよい。または、制御部１１は、チケットをチケット販売サービスにおいて販売可能な状態に戻すようにしてもよい。なお、チケットをチケット販売サービスにおいて販売可能な状態に戻す場合、制御部１１はチケットテーブルにアクセスし、オークションサーバ２０から受信した出品ＩＤが「出品ＩＤ」フィールドに登録されているレコードを特定し、当該レコードの「購入者」、「チケットＩＤ」、「キャンセルフラグ」、及び「出品ＩＤ」フィールドに登録された情報を消去する。以上でチケットが落札されなかった場合に実行される処理の説明を終了する。

以上に説明したチケット処理システム１によれば、キャンセルされたチケットがチケット販売会社によってオークションに出品される。このようなチケット処理システム１によれば、チケットの転売が詐欺に繋がるおそれがないため、興行主もオークションへのチケットの出品を許容することが期待できる。また、オークションでチケットを落札しようとするユーザも、出品されたチケットや出品者の正当性を心配する必要がなくなる。チケット処理システム１によれば、キャンセルされたチケットの有効活用を実現することが可能になる。

また、チケット処理システム１では、オークションへのチケットの出品がチケット処理サーバ１０によって行われるため、ユーザはオークションにチケットを出品する必要がない。このため、チケット処理システム１によれば、オークションサービスにチケットを出品する手間を軽減することが可能になる。すなわち、チケット処理システム１によれば、ユーザによってキャンセルされたチケットの有効活用を、ユーザの手間を軽減しつつ実現することが可能になる。つまり、チケット処理システム１はユーザの手間を軽減するという技術的効果を奏するものである。

チケット処理システム１によれば、購入したチケットをやむを得ない理由によってキャンセルせざるを得ないユーザにとって、チケット代の全部又は一部が戻ってくる可能性があるという利点がある。また、キャンセル手数料が免除（又は軽減）される可能性があるという利点もある。さらに、上述したように、オークションサービスへの出品手続きを行う手間が不要になるという利点もある。

また、チケット処理システム１によれば、チケットを購入し損ねたユーザにとっては、出品されたチケットや出品者の正当性を心配することなく、オークションでチケットを入手できるようになるという利点がある。

さらに、チケット処理システム１によれば、チケットの有効活用が実現されることによってイベント会場において空席が生じ難くなるため、興行主にとっては、イベント会場において空席が生じ難くなるという利点がある。また、チケット販売会社又はオークション会社にとっては、自らのサービスを利用するユーザの満足度を向上できるようになるという利点や、手数料収入の増加を期待できるようになるという利点がある。

なお、本発明は以上に説明した実施形態に限定されるものではない。

［１］先述のように、オークションサービスでは、出品された商品の価格を上限価格より時間経過に伴って下げていくようにしてもよい。そして、商品の入札の申込みをユーザから受け付けた場合には、その時点における価格を落札価格として決定するようにしてもよい。

この場合、例えば、イベント当日においても、オークションサーバ２０はユーザからの入札を受け付けるようにしてもよい。また例えば、イベントが開始された後においても、オークションサーバ２０はユーザからの入札を受け付けるようにしてもよい。このようにすれば、チケットを入手したいユーザがイベント当日やイベントが開始された後においてもチケットを入手できるようにすることが可能になる。

なお、イベント当日においてユーザからの入札を受け付ける場合、オークションサーバ２０（価格制御手段）は、イベント当日（チケットが示す日）における価格の下落速度（単位時間当たりの価格の下げ具合）を、イベント当日以前における価格の下落速度よりも大きく設定するようにしてもよい。例えば、イベント当日以前においては、１日ごとに価格を５００円ずつ下げるようにし、イベント当日においては、１時間ごとに価格を１００円ずつ下げるようにしてもよい。

また、イベントが開始された後においてユーザからの入札を受け付ける場合、オークションサーバ２０（価格制御手段）は、イベントの開始日時（チケットが示す日時）以降における価格の下落速度を、イベントの開始日時以前における価格の下落速度よりも大きく設定するようにしてもよい。例えば、イベントの開始前においては、１日ごとに価格を５００円ずつ下げるようにし、イベントの開始後においては、１０分ごとに価格を１００円ずつ下げるようにしてもよい。

また例えば、イベント当日以前においては、１日ごとに価格を５００円ずつ下げるようにし、イベント当日のイベントの開始前においては、１時間ごとに価格を１００円ずつ下げるようにし、イベントの開始後においては、１０分ごとに価格を１００円ずつ下げるようにしてもよい。

［２］また例えば、オークションサービスに出品されたチケットが落札されなかった場合、チケット処理サーバ１０は、チケットをキャンセルしたユーザと所定の関係にあるユーザにチケットを譲渡するようにしてもよい。なお、「チケットをキャンセルしたユーザと所定の関係にあるユーザ」とは、例えばチケットをキャンセルしたユーザと友人関係にあるユーザである。

上記のようなチケットの譲渡を実現するためには、所定の関係にあるユーザ同士を示すデータが必要になる。例えば、所定の関係にあるユーザのユーザＩＤの組み合わせを示すデータが必要となる。このようなデータはデータベース３０に記憶されていてもよいし、他のデータベースに記憶されていてもよい。例えば、ユーザ同士がコミュニケーションを図るためのコミュニケーションサービス（例えばソーシャルネットワークサービス等）を提供するコミュニケーションシステムに含まれるデータベースに上記のようなデータが存在している場合には、チケット処理サーバ１０は、コミュニケーションシステムに含まれるデータベースから上記のようなデータを取得するようにしてもよい。

チケットをキャンセルしたユーザと所定の関係にあるユーザにチケットを譲渡する場合には、新たな電子チケットが該ユーザに対して発行されることになる。この処理は図１６のステップＳ３０５と基本的に同様である。

また、上記のようなチケットの譲渡は無償で行うようにしてもよいし、有償で行うようにしてもよい。なお、チケットの譲渡を有償で行う場合には、チケットの価格を予め定められた価格としてもよいし、チケットをキャンセルしたユーザによって指定された価格（希望譲渡価格）としてもよい。また、後者の場合には、予め、チケットをキャンセルしたユーザと所定の関係にあるユーザに希望譲渡価格を通知するようにしてもよい。そして、通知を受け取ったユーザが希望譲渡価格を承諾した場合にチケットの譲渡が実行されるようにしてもよい。

［３］また例えば、オークションに出品されたチケットが落札されなかった場合の取り扱いをユーザが選択できるようにしてもよい。例えば、オークションに出品されたチケットが落札されなかった場合に自らと所定の関係にあるユーザにチケットを譲渡するか否かを、チケットをキャンセルしたユーザが選択できるようにしてもよい。

［４］また例えば、複数枚のチケットを購入したユーザがそれらのチケットをキャンセルする場合には、それら複数枚のチケットがまとめてオークションに出品されるようにしてもよいし、個々のチケットごとにオークションに出品されるようにしてもよい。

［５］以上では、電子チケットがユーザに発行するチケット処理システム１に本発明を適用する場合について主に説明したが、本発明は、従来の物理的チケット（例えば紙媒体のチケット）をユーザに発行するようなチケット処理システムにも適用することが可能である。

１ チケット処理システム、２ 通信ネットワーク、３ ユーザ端末、１０ チケット処理サーバ、１１ 制御部、１２ 記憶部、１３ 光ディスクドライブ部、１４ 通信部、２０ オークションサーバ、３０ データベース、４０ 購入画面、４２ 枚数欄、４４ 購入ボタン、５０ 購入履歴画面、５２ 表示ボタン、５４ 印刷ボタン、５６ キャンセル（譲渡）ボタン、６０ 入札画面、６２ 入札ボタン、７０ 第１の受付部、７２ 購入処理実行部、７４ 第２の受付部、７６ 出品処理実行部、７８ 徴収料金決定部。

Claims (10)

1. 物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付手段と、
   前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行手段と、
   前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付手段と、
   前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行手段と、
   を含むことを特徴とするチケット処理システム。
2. 請求項１に記載のチケット処理システムにおいて、
   前記オークションサービスに出品された前記チケットが落札された場合、前記チケットのキャンセル又は譲渡の申込みを行った前記購入ユーザから徴収する料金を、前記購入ユーザが前記チケットを購入した場合の購入価格と、前記オークションサービスにおける前記チケットの落札価格と、に基づいて決定する徴収料金決定手段を含む、
   ことを特徴とするチケット処理システム。
3. 請求項２に記載のチケット処理システムにおいて、
   前記徴収料金決定手段は、前記購入価格に基づいて決定される基準価格よりも前記落札価格が高いか否かの判定結果に基づいて、前記購入ユーザから徴収する料金を決定する、
   ことを特徴とするチケット処理システム。
4. 請求項３に記載のチケット処理システムにおいて、
   前記徴収料金決定手段は、前記落札価格が前記基準価格よりも高い場合に、前記購入ユーザから徴収する料金を零に決定する、
   ことを特徴とするチケット処理システム。
5. 請求項１乃至４のいずれかに記載のチケット処理システムにおいて、
   前記購入処理実行手段は、前記購入ユーザに電子チケットを発行するための処理を実行する手段を含み、
   前記チケット処理システムは、
   前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記購入ユーザに発行された前記電子チケットの利用を不可にするための処理を実行する手段と、
   前記オークションサービスに出品された前記チケットが落札された場合に、前記チケットを落札したユーザに新たな電子チケットを発行するための処理を実行する手段と、を含む、
   ことを特徴とするチケット処理システム。
6. 請求項１乃至５のいずれかに記載のチケット処理システムにおいて、
   下限価格を決定する手段と、
   前記オークションサービスにおいて、前記下限価格よりも低い落札価格で前記チケットが落札されることを制限する手段と、を含む、
   ことを特徴とするチケット処理システム。
7. 請求項１乃至６のいずれかに記載のチケット処理システムにおいて、
   前記オークションサービスに出品された前記チケットの価格を時間経過に伴って下げていく価格制御手段と、
   前記オークションサービスに出品された前記チケットの落札の申込みをユーザから受け付ける手段と、
   前記チケットの落札の申込みが受け付けられた時点における価格を前記落札価格として決定する手段と、を含み、
   前記価格制御手段は、
   前記チケットが示す日における前記価格の下落速度を、前記チケットが示す前記日以前における前記価格の下落速度よりも大きく設定する手段と、
   前記チケットが示す日時以降における前記価格の下落速度を、前記チケットが示す前記日時以前における前記価格の下落速度よりも大きく設定する手段と、の少なくとも一方を含む、
   ことを特徴とするチケット処理システム。
8. 請求項１乃至７のいずれかに記載のチケット処理システムにおいて、
   前記オークションサービスに出品された前記チケットが落札されなかった場合に、前記購入ユーザと所定の関係を有するユーザに前記チケットを譲渡する処理を実行する手段を含む、
   ことを特徴とするチケット処理システム。
9. 物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付ステップと、
   前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行ステップと、
   前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付ステップと、
   前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行ステップと、
   を含むことを特徴とするチケット販売システムの制御方法。
10. 物理的又は電子チケットの購入の申込みをユーザから受け付ける第１の受付手段、
    前記チケットの購入の申込みが受け付けられた場合に、前記チケットの購入処理を実行する購入処理実行手段、
    前記チケットのキャンセル又は譲渡の申込みを、前記チケットを購入した購入ユーザから受け付ける第２の受付手段、及び、
    前記チケットのキャンセル又は譲渡の申込みが受け付けられた場合に、前記チケットをオークションサービスに出品するための出品処理を実行する出品処理実行手段、
    としてコンピュータを機能させるためのプログラム。

Images