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

Description

本発明に係るいくつかの態様は、情報処理システム、情報処理方法、及びプログラムに関する。

近年、いわゆるスマートフォン等の携帯型端末を利用した電子チケット発券システムが考えられている（例えば特許文献１参照）。特許文献１には、イベントのチケット購入を希望する際に、チケット購入ページにアクセスしてチケット購入決済処理を行うと、サーバが、イベントのチケットデータを購入者の携帯型端末に送信することが開示されている。

特許第５２５６３７２号

ここで、チケットの購入者が、スケジュールの変更などでチケットを利用できなくなる場合がある。しかしながら、特許文献１では、このような場合について何ら考慮されていない。

本発明のいくつかの態様は前述の課題等に鑑みてなされたものであり、ユーザによるチケットの好適な利用形態を提供することのできる情報処理システム、情報処理方法、及びプログラムを提供することを目的とする。

本発明に係る情報処理システムは、複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データを管理する管理手段と、売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信する手段と、前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認する手段と、前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とする手段と、購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信する手段と、売却申請中である１以上の売却対象チケットを、前記購入希望ユーザに販売するか否かを決める決定手段と、前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新する手段とを備える。

本発明に係る情報処理方法は、複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データを管理するステップと、売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信するステップと、前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認するステップと、前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とするステップと、購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信するステップと、売却申請中である１以上の売却対象チケットを、前記購入希望ユーザに販売するか否かを決めるステップと、前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新するステップとを情報処理システムが行う。

本発明に係るプログラムは、複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データを管理する処理と、売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信するステップと、前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認する処理と、前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とする処理と、購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信する処理と、売却申請中である１以上の売却対象チケットを、前記購入希望ユーザに販売するか否かを決める処理と、前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新する処理とを情報処理システムに実行させる。

なお、本発明において、「部」や「手段」、「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」、「システム」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「手段」、「装置」、「システム」の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、ユーザによるチケットの好適な利用形態を提供することのできる情報処理システム、情報処理方法、及びプログラムを提供することができる。

実施形態に係るチケットシステムの構成例を示す図である。 実施形態に係る管理サーバの機能構成の具体例を示す図である。 実施形態に係るチケットアプリの機能構成の具体例を示す図である。 実施形態に係るチケットシステムの処理の流れの具体例を示すフローチャートである。 実施形態に係るチケットシステムの処理の流れの具体例を示すフローチャートである。 実施形態に係るチケットシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るチケットシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るチケットシステムの処理の流れの具体例を示すフローチャートである。 実施形態に係る管理サーバのハードウェア構成の具体例を示す図である。 実施形態に係る携帯型端末のハードウェア構成の具体例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、以下の図面の記載において、同一または類似の部分には同一または類似の符号を付して表している。図面は模式的なものであり、必ずしも実際の寸法や比率等とは一致しない。図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることがある。

図１乃至図９は、実施形態を説明するための図である。以下、これらの図を参照しながら、以下の流れに沿って実施形態を説明する。まず、「１」で実施形態に係るチケットシステムの概要を説明する。続いて「２」で当該チケットシステムで使用される管理サーバ及びチケットアプリの機能構成を説明し、「３」でチケットシステムの処理の流れを説明する。「４」では、チケットシステムに含まれる管理サーバ及び携帯型端末を実装可能なハードウェア構成の具体例を説明する。最後に、「５」以降で、本実施形態に係る効果などを説明する。

（１． 概要）
まず、図１を参照しながら、実施形態に係るチケットシステム１の構成及び処理の概要を説明する。チケットシステム１は、例えば、チケットの購入及び使用が可能なユーザＵＡ及びＵＢ（以下、総称してユーザＵともいう。）の使用する携帯型端末１００Ａ及び１００Ｂ（以下、総称して携帯型端末１００ともいう。）と、チケットサービスを提供するサービス事業者により管理される管理サーバ２００とを含む。携帯型端末１００と、管理サーバ２００とは、それぞれネットワークＮを介して有線又は無線により、相互に通信可能である。

本チケットシステム１において、ユーザＵは携帯型端末１００にインストールされたチケットアプリケーション（以下、チケットアプリとも呼ぶ。また、以下アプリケーションプログラムを、単に「アプリ」とも呼ぶ。）を用いて、電子チケットサービスを受けることができる。具体的には、予めユーザＵは、サッカーや野球等の競技場、遊園地や動物園等の各種施設、ライブ会場等（以下、これらを総称して単に「会場」と呼ぶ。）へ入場するためのチケットを購入し、当該チケットに係る電子チケットデータを携帯型端末１００の電子チケットアプリがダウンロードする。ユーザＵは、当該電子チケットを表示した表示画面を、会場の係員に提示する。当該係員により、当該表示画面に対して所定の操作（例えば、特定のパターンのなぞり操作やスワイプ操作等）を入力したり、特定のパターンを有する電子的なスタンプ部材を画面に押印（タッチパネルへの接触操作等）したりされると、チケットアプリは、当該電子チケットを使用済みとするもぎり処理（消込処理）を行う。またチケットアプリは、当該電子チケットが使用済みであることを管理サーバ２００へと通知する。なお、以下、電子チケットを使用済みとするために、特定の操作を入力したり、スタンプ部材を画面に押印（タッチパネルへの接触操作等）したりする操作を、もぎり操作ともいう。

なお、もぎり操作は、必ずしも会場の係員が行う必要はない。例えば、会場の入場ゲートに電子チケットを使用済みとするための入場管理用装置を配置し、当該入場管理装置によりもぎり処理を行うことも考えられる。この場合、例えば、ユーザが携帯型端末１００を当該入場管理用装置に近接させる操作を行うことで、携帯型端末１００と入場用管理装置との間で近接無線通信（ＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が行われ、携帯型端末１００のチケットアプリが電子チケットを使用済みとするもぎり処理を行えば良い。

携帯型端末１００には、前述のとおりチケットアプリがインストールされており、当該チケットアプリを使用することで、ユーザＵはチケットサービスの提供を受けることができる。具体的には、携帯型端末１００は、ユーザＵが購入した電子チケットデータを管理サーバ２００からダウンロードし、電子チケットに係る表示画面を表示することができる。また、当該電子チケットの表示画面においてもぎり操作が入力されると、携帯型端末１００は電子チケットが使用済みであることを管理サーバ２００へと通知する。携帯型端末１００は、例えばフィーチャーフォンやいわゆるスマートフォンと呼ばれる携帯電話、タブレット型端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、携帯型ゲーム機等により実現することができる。

以下の説明では、携帯型端末１００に、チケットアプリをインストールした上で、当該チケットアプリに電子チケットデータをダウンロードする例を中心に説明する。

管理サーバ２００は、電子チケットの販売及び管理を行うサーバである。なお、管理サーバ２００の機能は、必ずしも物理的に１台のサーバにより実現される必要はなく、複数台のサーバにより実現することも可能である。

管理サーバ２００は、例えば、チケット販売サイトを提供する。ユーザＵは、携帯型端末１００や、その他の情報処理端末上でブラウザを操作することで、当該チケット販売サイトへとアクセスし、当該チケット販売サイト上でチケットの購入を申込む（以下、購入の申請、又は申出ともいう。）ことができる。本実施形態においてはこの際、ユーザＵはチケットをダウンロード（受領）する携帯型端末１００の端末情報（例えば、電話番号）を登録する。管理サーバ２００は、当該チケット購入申込に係る情報において、ユーザＵの識別情報、及び、チケットを受領する端末（以下、チケット受領端末ともいう。）の端末情報を紐づけて管理する。その後、例えば抽選などの結果、ユーザＵがチケットの購入権を取得した後、ユーザＵが携帯型端末１００のチケットアプリを起動し、当該チケットアプリが管理サーバ２００へアクセスすると、管理サーバ２００は、当該携帯型端末１００の端末情報が、チケット受領端末として登録された端末情報と一致するか否かを確認する。その結果、端末情報がもし一致すれば、管理サーバ２００は電子チケットデータを携帯型端末１００へと送信する。また、管理サーバ２００は、当該電子チケットが使用された旨の情報を携帯型端末１００から受信すると、当該電子チケットに係るステータス情報を使用済みに更新する。

このように、本実施形態に係るチケットシステム１においては、チケットを受領するチケット受領端末の情報を、チケット購入の申込みの際にユーザＵに登録させる。これにより、ユーザＵは、チケット受領端末として登録された端末でしか、電子チケットを受領／使用できない。この結果、電子チケットが自由に転売等されることを抑制することができる。

ネットワークＮは、先述の通り携帯型端末１００及び管理サーバ２００を相互に通信可能に接続する。ネットワークＮは、例えばインターネット等により実現することができ、内部に無線ＬＡＮのアクセスポイントや携帯電話の基地局等を含むこともできる。

また、本実施形態にかかるチケットシステム１では、ユーザＵＡが保有するチケットを、管理サーバ２００による管理のもとで、他のユーザＵＢに売却することが可能である。これにより、例えばユーザＵＡがチケットに係るイベントに行けなくなった場合であっても、当該チケットが無駄になることはない。また、あくまでも管理サーバ２００による管理のもとでのチケットの売却であるため、不正に金額を釣り上げてチケットが転売されることを防ぐことが可能である。例えば、定価、又は定価に手数料を付加した価格でのチケットの売買を保証することができる。

更に、本実施形態に係る管理サーバ２００は、発行済の各チケット（電子チケットのみならず、紙チケットも含むことができる）と、各チケットを保有するユーザとを管理するチケット管理データを管理する。これにより、各ユーザがチケット売却を申請した際に、当該ユーザが、正当にチケットを保有している（サービス事業者を介さずにチケットを取得したわけではない）ことを確認することが可能である。もし紙チケットを正当に有しているユーザＵがチケットを売却する場合には、例えば、当該ユーザＵは、管理サーバ２００の提供するウェブサイト上で、チケット売却を申請すると共に、サービス事業者に対して紙チケットを郵送する。管理サーバ２００は、当該売却を申請したユーザが、チケット管理データ上で管理されているチケット保有者のデータと一致した場合には、当該チケットを、他のユーザに販売する。この際、管理サーバ２００が販売するチケットは、必ずしも紙チケットである必要はなく、電子チケットとして販売することも可能である。なお、販売した時点でチケット売却申請者から紙チケットを受領していない場合には、管理サーバ２００は、購入者に販売した電子チケットの券面に、使用できない状態である旨を表示する。その後、チケット売却者から紙チケットを受領すると、購入者の電子チケットの券面に、座席情報を表示するなどすれば、同一座席のチケットの重複使用をさけることができる。

ユーザ間で売買されるチケットの購入希望者（購入申請者ともいう。）は、通常のチケット購入時と同様に、あるイベントに関して販売されているチケット（但し、他のユーザが保有し、売却が申請されているチケット）の購入を申込む。この時、購入希望者であるユーザＵは、電子チケットを受領する携帯型端末１００の端末情報（例えば電話番号）を登録する。売却希望者から売却を申請されているチケットをどの購入希望者に販売するかは、例えば、管理サーバ２００が抽選により決定することができる。このとき、例えば連番の複数席を希望するか否かやチケット種別（例えば、ファンクラブの会員のみが利用可能なチケットであるか否か）等を考慮してもよい。

ここで、チケット購入希望者が購入を申込む際、チケット売却希望者が売却しようとしている個別のチケットに対して行うのではなく、同種のチケット全体に対して申込むようにしても良い。例えば、○月×日に会場「○×」で開催されるイベント「○○○○」のＳＳ席について、複数の売却申請者から、合計１０枚の売却申請が行われている場合を考える。この場合には、例えば当該イベントのＳＳ席１枚の購入を希望する各購入希望者は、それぞれ、この１０枚のチケットに対して、購入申請を行うことができる。これにより、チケットを購入する際に、購入希望者は、同じ公演に対して何度も購入申請（エントリー）を行わずに済む。

なお、チケットの売却の申請、及び売却の申請がなされているチケットへの購入の申請は、例えば、ユーザＵの携帯型端末１００にインストールされたブラウザ上で行うことができる。また、電子チケットを使用するためのチケットアプリがインストールされた携帯型端末１００ではない、他の情報処理装置（例えば、パーソナルコンピュータ（ＰＣ）等）のブラウザ上で申請することも考えられる。

以下の例では、ユーザＵＡが、自身の保有する携帯型端末１００Ａのブラウザでチケットの売却を申請し、ユーザＵＢが、自身の保有する携帯型端末１００Ｂのブラウザでチケットの購入を申請する場合を中心に説明する。この場合、ユーザＵＡは売却希望ユーザ、ユーザＵＢは購入希望ユーザとなる。

（２． 機能構成）
以下、図２及び図３を参照しながら、本実施形態に係る管理サーバ２００、及び携帯型端末１００にインストールされるチケットアプリ３００の機能構成を説明する。

（２．１ 管理サーバ２００の機能構成）
まず、図２を参照しながら、管理サーバ２００の機能構成を説明する。図２は、管理サーバ２００の機能構成の具体例を示す機能ブロック図である。管理サーバ２００は、大きく分けて、ウェブサイト提供部２１０、チケットステータス変更部２３０、抽選部２４０、チケット取得要求受信部２５０、チケットデータ送信部２６０、メッセージ送信部２７０、及びデータベース（ＤＢ）２８０を含む。なお、先述の通り、管理サーバ２００の機能構成は、必ずしも１台のサーバにより実現する必要はなく、複数台のサーバにより実現することも考えられる。

ウェブサイト提供部２１０は、電子チケットサービスを提供するためのウェブサイトを、例えばインターネットであるネットワークＮ上で提供する。当該ウェブサイトは、販売しているチケット等の各種情報を提供したり、チケットを実際に販売したり、ユーザＵが保有しているチケットの売却の申請を受け付けたり、他のユーザが売却を希望しているチケットへの購入の申請を受け付けたりすることができる。このためにウェブサイト提供部２１０は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等で記述されたウェブページを、ユーザＵの使用する携帯型端末１００へ送信すると共に、ユーザＵによる入力結果等を、携帯型端末１００から受信する。ウェブサイト提供部２１０は、ユーザ画面送信部２１１、認証部２１３、購入可能チケット情報取得部２１５、チケット購入申請受信部２１７、決済情報受信部２１９、保有チケット情報取得部２２１、チケット売却申請受信部２２３、チケットステータス確認部２２５を含む。

ユーザ画面送信部２１１は、ユーザＵの操作する携帯型端末１００に対して、適当なウェブページを作成の上で送信する。具体的には、例えば販売対象のチケットの一覧画面（サービス事業者又はイベント主催者が販売しているチケットや、売却希望ユーザＵＡから売却が申請されているチケットの一覧）、チケットの購入や売却を申請する申請画面、各種注意事項／確認事項を示す画面等に係る各種ウェブページを、ユーザ画面送信部２１１は携帯型端末１００のブラウザへ送信する。

認証部２１３は、ウェブサイト提供部２１０のウェブサイトにアクセスしてきたユーザＵに対する認証処理を行う。より具体的には、例えば、ユーザＩＤ及びパスワードの入力をユーザＵに求め、ユーザＵから入力されたユーザＩＤ及びパスワードが、ＤＢ２８０にユーザ情報２８１として管理されているものと一致するか否かを認証部２１３は確認する。なお、ユーザＵによるユーザ登録がなされていない場合には、認証部２１３は、ウェブサイト提供部２１０の提供するウェブサイトの表示画面を通じて、ユーザＵに対して新規会員登録を促す。当該画面において、ユーザＵがユーザ登録を行うと、認証部２１３はユーザＵに対してユーザＩＤを割当て、例えばウェブサイト提供部の提供するウェブサイトの表示画面上や、或いはメッセージ送信部２７０の発行するメッセージを通じて、当該ユーザＩＤを携帯型端末１００に通知する。この場合、割り当てたユーザＩＤ等のユーザＵに係る各種情報は、ユーザ情報２８１としてＤＢ２８０に格納される。

購入可能チケット情報取得部２１５は、ユーザＵが購入可能なチケットの情報を、ＤＢ２８０のチケット管理データ２８３及びチケットステータス情報２８５から取得する。ユーザＵが購入可能なチケットには、サービス事業者又はチケット主催者が販売しているチケットの他、売却希望ユーザＵＡから売却が申請されているチケットが含まれる。購入可能チケット情報取得部２１５が取得した、ユーザＵが購入可能なチケットの情報は、ユーザ画面送信部２１１により加工された上で、ウェブページとしてユーザＵの携帯型端末１００へ送信される。

チケット購入申請受信部２１７は、ユーザＵの携帯型端末１００から、ユーザＵの選択したチケットの購入申請を受け付ける。この際、購入を申請したユーザＵがチケットの購入権を得た（例えばチケットに当選した）場合に当該チケットを電子チケットとして受領する端末の端末情報（例えば電話番号）の入力も、チケット購入申請受信部２１７は受け付ける。このように、電子チケットを受領する端末の端末情報を、チケットの購入権をユーザＵが取得する前に入力させることで、チケットの購入権（チケットを受領する権利）が他のユーザに不正に転売されることを防ぐことができる。チケット購入申請受信部２１７が受け付けた各種情報は、チケット購入申請者情報２８７としてＤＢ２８０に格納される。

決済情報受信部２１９は、ユーザＵの携帯型端末１００から、ユーザＵがチケットを購入する際に使用する決済情報を受け付ける。決済情報には、例えば、決済手段（コンビニエンスストアでの支払い、クレジットカード決済等）、クレジットカード番号等の情報、コンビニエンスストアの種別等を含むことができる。なお、ユーザＵからの決済情報の入力は、チケットの購入申請の際でも、ユーザがチケットを購入できるようになった際（例えば、チケットに当選した後）でも、どちらでも良い。しかしながら、チケット購入申請時に決済情報の入力を受け付けておけば、特にユーザＵがクレジットカード決済を希望する場合には、ユーザＵのチケット当選が決まった段階で、すぐにユーザＵがチケットを受領できる。

保有チケット情報取得部２２１は、ウェブサイト提供部２１０が提供するウェブサイトにアクセスしてきた各ユーザＵが保有しているチケットの情報を、ＤＢ２８０のチケット管理データ２８３を参照することにより取得する。当該ユーザＵが保有するチケットの情報は、ユーザ画面送信部２１１により加工された上で、ウェブページとしてユーザＵの携帯型端末１００へ送信される。

チケット売却申請受信部２２３は、ユーザＵの携帯型端末１００から、ユーザＵが保有するチケットの売却申請を受け付ける。チケット売却を申請したユーザＵの情報は、チケット売却申請者情報２８９としてＤＢ２８０に格納される。

チケットステータス確認部２２５は、チケットステータス情報２８５を参照することで、各チケットのステータスを確認する。当該チケットステータス情報２８５には、発行されたチケットの媒体（例えば、紙チケットであるか、電子チケットであるか）、チケットが売却申請中であるか否か、チケットを使用済みであるか否か、電子チケットをチケットアプリにダウンロード済みであるか否か等の情報が含まれる。よって、例えば、ユーザからチケットの売却申請がなされた場合には、チケットステータス確認部２２５は、チケットが電子チケットとして発行されているか否かや、電子チケットとして発行されている場合、その電子チケットデータはユーザＵのチケットアプリにダウンロードされているか否かを確認することができる。

チケットステータス変更部２３０は、必要に応じてチケットステータス情報２８５の内容を変更する。例えば、チケットの購入者による決済が終了した場合や、電子チケットデータのダウンロードが完了した場合、チケットの売却申請がなされた場合等に、チケットステータス変更部２３０は、チケットステータス情報２８５を変更する。

抽選部２４０は、販売されている各々のチケットに対して、当該チケットの購入を希望しているどの購入希望ユーザに購入権を与えるかを決める。この際、抽選部２４０は、例えば連番の複数枚のチケット購入を希望しているか否かや、購入希望者がファンクラブの会員であるか否かを考慮することができる。例えば、同一のイベントについて、ファンクラブの会員のみしか利用できないチケットと、ファンクラブの会員でなくとも利用できるチケットとがある場合には、購入希望者がファンクラブの会員である場合には、いずれのチケットも対象として抽選を行い、ファンクラブの会員でない場合には、ファンクラブの会員でなくとも利用できるチケットのみを対象に抽選を行えば良い。この場合、ファンクラブの会員であるか否かの情報は、例えばチケット購入の申込み（申請）の際や、ユーザ情報２８１の登録時に、ユーザに登録させることができる。

チケット取得要求受信部２５０は、携帯型端末１００のチケットアプリから、チケットデータの取得要求を受信する。この際、チケット取得要求受信部２５０は、ユーザを識別するためのユーザ情報や、携帯型端末１００の端末情報、チケットを受け取るための引換番号の情報を、受け付けることができる。

チケットデータ送信部２６０は、チケットデータを携帯型端末１００に送信する。このときチケットデータ送信部２６０は、チケット取得要求と共に受信した引換番号が正当なものであり、且つ、当該引換番号に係るチケットの購入権を得たユーザにより、事前にチケット受領端末として登録されている端末情報と受信した端末情報とが一致する場合に、チケットデータを携帯型端末１００に送信する。

メッセージ送信部２７０は、チケットの販売等に係る各種メッセージを、メールやメッセンジャーアプリのメッセージとしてユーザＵに通知する。例えば、ユーザＵが、購入を申請していたチケットに当選した場合には、メッセージ送信部２７０は、当選した旨や、当選したチケットを受領するための引換番号等の情報を、メールやメッセンジャーアプリのメッセージとして、ユーザＵに報知する。また、ユーザＵが売却を申請していたチケットが他のユーザにより購入された場合には、売却が完了した旨を、メッセージ送信部２７０はユーザＵに通知する。以下では、メッセージ送信部２７０がメールでメッセージを通知する場合を中心に説明する。

ＤＢ２８０は、ユーザ情報２８１、チケット管理データ２８３、チケットステータス情報２８５、チケット購入申請者情報２８７、及びチケット売却申請者情報２８９を管理する。

ユーザ情報２８１は、管理サーバ２００が提供するチケットサービスを利用する各ユーザＵに関する様々な情報である。ユーザ情報２８１には、ユーザＵの氏名や住所、性別、決済に用いるクレジットカード等の情報、認証に使用するユーザＩＤやパスワード、使用する携帯型端末１００に係る識別情報、購入したチケットの情報等を含むことができる。また、ユーザＵが所属しているファンクラブの情報（例えばアーティスト「○×○×」のファンクラブ会員等）、会員種別（プラチナ会員、ゴールド会員等）、等の各種ユーザ種別に関する情報をユーザ情報２８１に含むこともできる。

チケット管理データ２８３は、イベント主催者／サービス事業者が発行する各チケットを、例えばイベント毎に管理するためのデータである。特に、発行媒体が紙チケットであるか電子チケットであるかに関わらず、全チケットの保有者の情報をチケット管理データ２８３で管理することができる。チケット管理データ２８３を参照することにより、どのチケットをどのユーザＵが正当に保有しているかを確認することが可能である。この他、チケット管理データ２８３には、チケットに関する各種情報である、公演名、会場名、チケット種別、使用者の属性等に基づくチケット券種、各種期限、チケットを受け取るための引換番号等の情報も含むことができる。

チケットステータス情報２８５は、発行済のチケットの各種状態を管理するデータである。チケットステータス情報２８５には、発行された各チケットの媒体（例えば紙チケットであるか、電子チケットであるか）、チケットが売却申請中であるか否か、チケットを使用済みであるか否か、電子チケットをチケットアプリにダウンロード済みであるか否か、等の情報が含まれる。

チケット購入申請者情報２８７は、チケット購入を申請したチケット購入申請者に係る各種情報である。チケット購入申請者情報２８７には、例えば、チケットの購入権をユーザＵが獲得した際（例えば、チケット購入に係る抽選の当選など）にユーザＵが用いる決済に係る各種情報が含まれる。当該決済にかかる情報には、例えば、決済手段（例えば、宅配便での代引、クレジットカード決済、コンビニエンスストアでの支払い等）、クレジットカード決済を行う場合のクレジットカード番号等の決済情報、受取手段（電子チケット、コンビニエンスストアでの受取り、宅配便等）、等の情報が含まれる。この他、チケット購入申請者情報２８７には、チケット購入申請者、及び、当該チケット購入申請者が同伴する同伴者が、電子チケットを受領する際に用いる携帯型端末１００の端末情報も含むことができる。なお、端末情報には、例えば携帯型端末１００に固有に割当てられた識別情報や、チケットアプリに個別に割り当てた識別情報、携帯型端末１００に割当てられた電話番号等を用いることができる。本実施形態では、端末情報として、電話番号を用いる場合を中心に説明する。

チケット売却申請者情報２８９は、チケット売却を申請したチケット売却申請者に係る各種情報である。チケット売却申請者情報２８９には、例えば、チケットの売却が成立した際にユーザＵが当該売却金額を受領する決済にかかる各種情報が含まれる。

（２．２ チケットアプリ３００の機能構成）
次に、図３を参照しながら、携帯型端末１００にインストールされるチケットアプリ３００の機能構成を説明する。図３は、チケットアプリ３００の機能構成の具体例を示す機能ブロック図である。チケットアプリ３００は、認証部３１０、端末情報取得部３２０、チケット取得部３３０、チケット売却申請部３４０、メッセージ表示部３５０、ブラウザ起動部３６０、及びデータベース（ＤＢ）３７０を含む。

認証部３１０は、例えばチケットアプリ３００の起動時に、ユーザＵのユーザＩＤやパスワード等のユーザ情報を用いて、管理サーバ２００との間で認証処理を行う。当該認証に用いるユーザ情報３７１は、ユーザＵから起動時に入力を求めても良いし、或いは、２回目以降の起動時には、予めＤＢ３７０に記憶されたものを読み込んでも良い。

端末情報取得部３２０は、携帯型端末１００を識別するための情報、例えば電話番号等を含み得る端末情報３７３を取得する。端末情報３７３の取得方法としては、例えば、ＯＳから読み込んだり、ユーザＵから入力を受けてＤＢ３７０に端末情報３７３として登録したり、予めＤＢ３７０に登録されている端末情報３７３を読み込んだりすることが考えられる。

チケット取得部３３０は、起動時や、チケット受取りに係るユーザＵからの操作入力（例えば、チケット購入権を得たユーザに通知されるチケット引換番号の入力等）に応じて、管理サーバ２００へチケットデータの送信要求を送信し、当該ユーザＵが受取可能なチケットデータを管理サーバ２００から受信する。当該送信要求には、ユーザＵや携帯型端末１００を識別するための、ユーザ情報３７１や端末情報３７３の一部の情報を含むことができる。受信したチケットデータは、チケット情報３７５としてＤＢ３７０に格納される。

チケット売却申請部３４０は、例えばユーザ操作等に応じて、ＤＢ３７０にチケット情報３７５として格納されている電子チケットの売却を管理サーバ２００に対して申請する。当該申請を行うと、ＤＢ３７０のチケット情報３７５のステータスが売却申請中となり、ユーザＵは当該申請を取り消さないかぎり、当該電子チケットを使用することはできなくなる。

メッセージ表示部３５０は、ユーザＵに対して各種警告や確認にかかるメッセージを表示する。例えば、チケット売却を申請中である旨や、本当に売却を行うか否かの確認するメッセージ等を、メッセージ表示部３５０は表示する。

ブラウザ起動部３６０は、携帯型端末１００においてブラウザを起動する。例えば、チケット売却申請部３４０がチケットの売却申請を管理サーバ２００に対して行った後、ブラウザ起動部３６０がブラウザを起動させ、ブラウザがウェブページとして取引説明画面や最終確認画面を表示することができる。

ＤＢ３７０は、ユーザ情報３７１、端末情報３７３、チケット情報３７５を含む各種情報を管理する。

ユーザ情報３７１は、チケットアプリ３００を使用するユーザＵのユーザアカウント等に関する情報である。ユーザ情報３７１としては、例えば、ユーザＩＤやパスワード等の情報を含むことができる。先述の通り認証部３１０は、当該ユーザ情報３７１を使用して管理サーバ２００との間で認証を行う。

端末情報３７３は、携帯型端末１００、又はチケットアプリ３００に対して一意に割当てられた識別情報である。管理サーバ２００は、当該端末情報３７３を参照することで、ユーザＵの使用する携帯型端末１００を識別することが可能である。本実施形態では先述の通り、端末情報３７３として電話番号を使用する。チケットの購入申請の際、ユーザＵに予めチケット受領端末の電話番号を登録させておくことで、チケット受領の際、電話番号が異なる携帯型端末１００にチケットデータが受信されることを防ぐことができる。

チケット情報３７５は、ユーザＵが使用可能若しくは使用した電子チケットに関する各種情報である。チケット情報３７５には、例えば、公演名、会場名、チケット種別、使用対象者の属性等に基づく券種、電子チケットとして表示する画像や、有効期間等の情報を含むことができる。加えて、チケット情報３７５には、もぎり処理を行うためのもぎり操作のパターンや認証情報等を含むこともできる。先述の通り、チケット情報３７５はチケット取得部３３０が管理サーバ２００から取得する。

（３ 処理の流れ）
以下、チケットシステム１の処理の流れを、図４、図５及び図７を参照しながら説明する。図４及び図５は、本実施形態に係るチケットシステム１の処理の流れを示すフローチャートである。

なお、後述の各処理ステップは、処理内容に矛盾を生じない範囲で、任意に順番を変更して若しくは並列に実行することができ、また、各処理ステップ間に他のステップを追加しても良い。更に、便宜上１つのステップとして記載されているステップは複数のステップに分けて実行することもでき、便宜上複数に分けて記載されているステップを１ステップとして実行することもできる。

（３．１ 電子チケットの売却申請時の処理）
まず、保有する電子チケットの売却申請に係る処理の流れを、図４を参照しながら説明する。図４は、電子チケットの売却申請に係るチケットシステム１の処理の流れを示すフローチャートである。

なお、図４の例において、携帯型端末１００にはブラウザ１１０及びチケットアプリ３００がインストールされている。また、ユーザＵは１以上の電子チケットを既に購入済みであるものとする。なお、前述のとおり、ユーザＵが電子チケット売却申請の際に使用するブラウザ１１０は、必ずしもチケットアプリ３００がインストールされた携帯型端末１００上である必要はない。例えば、パーソナルコンピュータ（ＰＣ）のブラウザを用いて、予め購入済みのチケットに係る売却申請を行うことも考えられる。

ユーザＵは、携帯型端末１００のブラウザ１１０を用いて、管理サーバ２００の提供するチケットサービスサイトへとアクセスする（Ｓ４０１）。管理サーバ２００のウェブサイト提供部２１０は当該アクセスを受けて、アクセスを受けたＵＲＬに応じたウェブページを携帯型端末１００へと送信する（Ｓ４０３）。例えば、当該ウェブページ上でのユーザ操作等に応じて、携帯型端末１００のブラウザ１１０は、管理サーバ２００との間でログイン処理を行う（Ｓ４０５及びＳ４０７）。より具体的には、例えばブラウザ１１０上でユーザＵからユーザＩＤ及びパスワードの入力を受け、それを受信した管理サーバ２００が、ユーザ情報２８１上で管理しているユーザＩＤ及びパスワードを照合すれば良い。この際、もしユーザＵが当該チケットサービスへのユーザ登録を行っていなければ、管理サーバ２００はユーザＵの会員登録処理を行えば良い。

この後、例えばブラウザ１１０上でのユーザＵの操作に応じて、管理サーバ２００がユーザＵの保有チケットの一覧画面の閲覧要求を携帯型端末１００から受信すると、保有チケット情報取得部２２１が当該ユーザの保有チケットの情報をチケット管理データ２８３から抽出する。ユーザ画面送信部２１１は、当該保有チケットの情報をリスト化した一覧画面に係るウェブページを生成した上で、携帯型端末１００へと送信する（Ｓ４０９）。当該一覧画面のウェブページを受信したブラウザ１１０は、当該一覧画面をディスプレイに表示させる（Ｓ４１１）。

その後、当該一覧画面や個別チケットの詳細画面において、ユーザＵから売却申請対象のチケットの選択をブラウザ１１０上で受けると（Ｓ４１３）、ブラウザ１１０は管理サーバ２００に対して当該チケットのステータスの問合せを行う（Ｓ４１５）。管理サーバ２００のチケットステータス確認部２２５は、当該問合せを受けて、売却対象とされたチケットが電子チケットであるか、電子チケットである場合には、チケットアプリ３００で受信済みか確認し、確認結果をユーザ画面送信部２１１がウェブページとして携帯型端末１００へ返信する（Ｓ４１７）。

チケットアプリ３００で電子チケットを受信していない場合には（紙チケットとしてチケットが発行されている場合も含む。Ｓ４１９のＮｏ）、ブラウザ１１０は管理サーバ２００に対してチケット売却申請を要求する（Ｓ４２１）。管理サーバ２００のチケット売却申請受信部２２３は当該要求を受信すると、当該ユーザが正当なチケットの保有者であるか否かをチケットステータス情報２８５を参照して確認した上で、該当するチケットに係るチケットステータス情報２８５を、売却申請受付中に変更する（Ｓ４２３）。

一方、チケットアプリ３００で電子チケットを受信している場合には（Ｓ４１９のＹｅｓ）、ブラウザ１１０は、チケットアプリ３００の起動をユーザＵに即すメッセージを、管理サーバ２００からのウェブページに基づき表示する（Ｓ４２５）。当該メッセージを受けたユーザＵによる操作に応じてチケットアプリ３００が起動し、ログイン処理が完了した上で（Ｓ４２７）、ユーザＵからチケット売却を申請する操作入力を受けると、チケットアプリ３００のチケット売却申請部３４０は管理サーバ２００に対してチケット売却申請を要求する（Ｓ４２９）。管理サーバ２００のチケット売却申請受信部２２３は当該要求を受けて、該当するチケットに係るチケットステータス情報２８５を、売却申請受付中に変更する（Ｓ４２３）。チケットの売却申請要求後、チケットアプリ３００のブラウザ起動部３６０はブラウザ１１０を起動させる（Ｓ４３１）。

ブラウザ１１０上、又はチケットアプリ３００上でチケットの売却申請を行うと、管理サーバ２００は取引説明画面や最終確認画面のウェブページを携帯型端末１００へ送信し（Ｓ４３３）、ブラウザ１１０はそれらの画面をディスプレイに表示させる（Ｓ４３５）。当該最終確認画面においてユーザが確認ボタンを選択すると、ブラウザ１１０は管理サーバ２００に対して正式な売却申請を行う（Ｓ４３７）。当該売却申請を受信した管理サーバ２００は、チケットステータス情報２８５で管理する該当チケットのステータスを、売却申請受付中から売却申請中に更新する（Ｓ４３９）。その上で管理サーバ２００は、売却申請の完了画面に係るウェブページを携帯型端末１００へ送信する（Ｓ４４１）。ブラウザ１１０は当該受信したウェブページに基づき、売却申請の完了画面をディスプレイに表示させる（Ｓ４４３）。また、管理サーバ２００は、予め登録されたユーザＵのメールアドレスやメッセージの送付先に、売却送信完了のメールやメッセージを送信する（Ｓ４４５）。

（３．２ 電子チケットの購入申請時の処理）
次に、ユーザＵによる電子チケットの購入申請に係る処理の流れを、図５を参照しながら説明する。図５は、電子チケットの購入申請に係るチケットシステム１の処理の流れを示すフローチャートである。

以下の説明では、他のユーザが売却を申請しているチケットをユーザＵが購入する際の処理の流れを中心に説明する。なお、購入申請の処理は、他のユーザが保有し、売却を申請しているチケットのみでなく、イベント主催者やサービス事業者が販売しようとしているチケットでも同様に適用できる。

なお、前述のとおり、ユーザＵが電子チケット購入申請の際に使用するブラウザ１１０は、必ずしも携帯型端末１００上である必要はない。例えば、パーソナルコンピュータのブラウザを用いて、購入申請を行うことも考えられる。

ユーザＵは、携帯型端末１００のブラウザ１１０を用いて、管理サーバ２００の提供するチケットサービスサイトへとアクセスする（Ｓ５０１）。管理サーバ２００のウェブサイト提供部２１０は当該アクセスを受けて、アクセスを受けたＵＲＬに応じたウェブページを携帯型端末１００へと送信する（Ｓ５０３）。例えば、当該ウェブページ上でのユーザ操作等に応じて、携帯型端末１００のブラウザ１１０は、管理サーバ２００との間でログイン処理を行う（Ｓ５０５及びＳ５０７）。より具体的には、例えばブラウザ１１０上でユーザＵからユーザＩＤ及びパスワードの入力を受け、それをブラウザ１１０から受信した管理サーバ２００が、ユーザ情報２８１上で管理しているユーザＩＤ及びパスワードを照合すれば良い。この際、もしユーザＵが当該チケットサービスへのユーザ登録を行っていなければ、ユーザＵの会員登録処理をブラウザ１１０と管理サーバ２００との間で行えば良い。

この後、例えばブラウザ１１０上でのユーザＵの操作に応じて、購入可能チケットの一覧画面の閲覧要求を携帯型端末１００から管理サーバ２００が受信すると、購入可能チケット情報取得部２１５が、当該ユーザＵが購入可能なチケットの情報をチケット管理データ２８３から抽出する。この際、ユーザＵが購入可能なチケットには、イベント主催者やサービス事業者が販売するチケットと、チケットを保有する他のユーザが売却を申請しているチケットとのいずれか、又は両者を含むことができる。また、この際、ユーザＵのユーザ種別に応じて、購入可能なチケットを変えることもできる。具体的には、例えばユーザＵに係るユーザ情報２８１を参照した上で、当該ユーザＵがある特定のミュージシャンのファンクラブの会員であれば、当該ミュージシャンのファンクラブ限定イベントのチケットと、一般向けのチケットとを当該ユーザＵが購入可能なチケットとすることができる。一方、当該ファンクラブの会員ではないユーザＵは、当該ファンクラブ限定イベント以外の一般向けのチケットのみを購入可能なチケットとすれば良い。ユーザ画面送信部２１１は、購入可能チケット情報取得部２１５が取得したユーザＵの購入可能なチケットの情報をリスト化した一覧画面に係るウェブページを生成した上で、携帯型端末１００へと送信する（Ｓ５０９）。当該一覧画面のウェブページを受信したブラウザ１１０は、当該一覧画面をディスプレイに表示させる（Ｓ５１１）。

その後、当該一覧画面や、或いは個別チケットの詳細画面において、ユーザＵから購入申請対象のチケットの選択をブラウザ１１０上で受けると、ブラウザ１１０は管理サーバ２００に対してその旨を通知する（Ｓ５１３）。管理サーバ２００のチケット購入申請受信部２１７が当該通知を受信すると、ユーザ画面送信部２１１は、購入希望者、及び、必要に応じて同伴者に関する情報の登録画面に係るウェブページを携帯型端末１００へ送信する（Ｓ５１５）。携帯型端末１００のブラウザ１１０は、当該購入希望者及び／又は同伴者の情報の登録画面を表示する（Ｓ５１７）。

図６ａ及び図６ｂに、購入希望者（応募者）情報及び同伴者情報の登録画面６０ａ及び６０ｂ（以下、総称して登録画面６０ともいう。）の具体例を示す。図６ａは購入希望者情報の登録画面６０ａ、図６ｂは同伴者情報の登録画面６０ｂの具体例である。図６ａ及び図６ｂに示すように、各登録画面には、購入希望者や同伴者のメールアドレス、氏名（姓名）及びその読み仮名が、それぞれテキストボックス６１ａ及び６１ｂ、６３ａ及び６３ｂ、並びに６５ａ及び６５ｂに入力できるようになっている。またこれと併せて、電話番号もテキストボックス６７ａ及び６７ｂに登録できるようになっている。この電話番号の情報は、購入したチケットを電子チケットとして受領する携帯型端末１００を特定するための端末情報である。このように電話番号の登録を、応募時に受けることで、チケットの当選後、第三者にユーザアカウントごと転売等されることを防ぐことが可能となる。

このような購入希望者情報や同伴者情報の登録画面６０においてユーザＵが、購入希望者であるユーザＵに係る各種情報、及びチケット受領端末に係る電話番号と、同伴者のチケットも購入する場合には、当該同伴者に係る各種情報、及びチケット受領端末に係る電話番号との登録を行うと、ブラウザ１１０はそれらの情報を管理サーバ２００へ送信する（Ｓ５１９）。それらの情報を受信した管理サーバ２００のチケット購入申請受信部２１７は、チケット購入申請受信部２１７で受信した情報をチケット購入申請者情報２８７としてＤＢ２８０に登録する（Ｓ５２１）。

また、管理サーバ２００のユーザ画面送信部２１１は、チケットが当選した場合にユーザＵが用いる決済情報の登録を促す決済情報登録画面に係るウェブページを携帯型端末１００へ送信する（Ｓ５２３）。ブラウザ１１０は、受信したウェブページに基づき、決済情報登録画面を表示し（Ｓ５２５）、ユーザＵから決済情報の入力を受ける（Ｓ５２７）。決済情報には、チケットが当選した場合にユーザＵが用いる決済の種類（宅配便の代引、クレジットカード決済、コンビニエンスストアでの支払等）、クレジットカード決済を行う場合のクレジットカード番号や有効期限等の情報、コンビニエンスストアでの支払いを行う場合にコンビニエンスストアの系列情報、等を含むことができる。

ユーザが当該決済情報登録画面において、例えばユーザＵが登録ボタンを押すと、入力された決済情報をブラウザ１１０が管理サーバ２００へ送信する（Ｓ５２７）。管理サーバ２００の決済情報受信部２１９は、受信した決済情報を、チケット購入申請者情報２８７の一部としてＤＢ２８０に登録する（Ｓ５２９）。

このようにして、１以上のユーザＵからチケットの購入申込み（申請）を受けた後、所定の抽選時期が到来すると（Ｓ５３１）、管理サーバ２００の抽選部２４０は、どのチケットの購入権をどのユーザＵに付与するかを決めるための抽選を行う（Ｓ５３３）。その上で、各購入申請者であるユーザＵに、例えば登録画面６０において予め登録されたメールアドレスに対して抽選結果を通知するメールを送信する（Ｓ５３５）。この際メッセージ送信部２７０は、チケットの当選者であるユーザＵへ送信するメールには、チケットを受領する際に必要となる引換番号の情報を記載することができる。なお、必ずしもメッセージの送信手段は電子メールである必要はなく、例えば、リアルタイムでのメッセージの送受信が可能なメッセンジャーアプリのメッセージであっても良い。

その後、決済が完了すると（Ｓ５３７のＹｅｓ）、管理サーバ２００は、チケット管理データ２８３におけるチケットの所有者を、チケット売却申請者から、チケット購入申請者に変更する（Ｓ５３９）。なお、決済の完了は、例えばクレジットカード決済の場合には、予め決済情報として登録されたクレジットカード番号等を用いて決済会社の提供する決済サービスとの決済処理の完了や、コンビニエンスストアや宅配便業者の決済サーバからその旨の通知を受信することにより、管理サーバ２００は把握することが可能である。また、チケット売却申請者には、チケット売却代金（手数料が差し引かれても良い）が支払われる。

（３．３ 電子チケットの受取処理）
ユーザＵが、当選した（購入権を得た）チケットを電子チケットとして受領する際の処理の流れを、図７を参照しながら説明する。図７は、電子チケットの受領に係るチケットシステム１の処理の流れを示すフローチャートである。

ユーザＵ操作等に応じて、携帯型端末１００のチケットアプリ３００が起動すると（Ｓ７０１）、チケットアプリ３００の認証部３１０は、管理サーバ２００の認証部２１３との間で認証処理を行う（Ｓ７０３及びＳ７０５）。この際、チケットアプリ３００の認証部３１０は、必要に応じてユーザＵからユーザＩＤやパスワードの入力を受けても良いし、ＤＢ３７０に予めユーザ情報３７１として登録されていたユーザＩＤやパスワードの情報を用いても良い。

その後、例えばユーザＵがチケット受取ボタン等を操作すると、チケットアプリ３００はチケットの受け取り処理を開始する（Ｓ７０７のＹｅｓ）。具体的には、まずチケット取得部３３０は、チケット引換番号の入力をユーザＵに求める（Ｓ７０９）。また、電話番号（端末情報）がチケットアプリ３００のＤＢ３７０に登録されていない場合には、端末情報取得部３２０は、携帯型端末１００の電話番号を取得する（Ｓ７１３）。具体的には、ＯＳから電話番号の情報が取得できる場合には、端末情報取得部３２０はＯＳから電話番号の情報を取得する。また、ＯＳから電話番号の情報を読み込めない場合には、端末情報取得部３２０は、当該携帯型端末１００の電話番号の入力をユーザＵに求めれば良い。また、その際に入力された電話番号に対してＳＭＳ（ショートメッセージサービス）を用いて電話番号の有効性を確認すると良い。

引換番号及び電話番号の情報が揃うと、チケットアプリ３００のチケット取得部３３０はそれらの情報及びユーザ情報を含むチケット取得要求を管理サーバ２００に対して送信する。管理サーバ２００のチケット取得要求受信部２５０は、当該チケット取得要求を受信すると（Ｓ７１７）、引換番号に対応するチケットの当選者に係るＤＢ２８０のチケット購入申請者情報２８７を読み込む（Ｓ７１９）。その結果、予めチケット受領用の端末に係るものとして登録されていた電話番号（端末情報）及びユーザ情報と、受信した電話番号及びユーザ情報とが一致するか否かをチケットデータ送信部２６０は確認する（Ｓ７２１）。もし電話番号やユーザ情報が一致しなかった場合には（Ｓ７２１のＮｏ）、チケットデータ送信部２６０はエラーメッセージを携帯型端末１００へ送信する（Ｓ７２３）。チケット取得要求において受信した電話番号やユーザ情報と、予めチケット受領用の端末に係るものとして登録されていた電話番号やユーザ情報とが一致する場合には（Ｓ７２１のＹｅｓ）、チケットデータ送信部２６０はチケットデータを送信する（Ｓ７２５）。

携帯型端末１００のチケットアプリ３００がチケットデータを管理サーバ２００から受信すると（Ｓ７２７のＹｅｓ）、チケットの受取が完了した旨のメッセージをメッセージ表示部３５０が表示する（Ｓ７２９）。また、当該チケットが、他のユーザからの売却申請されたものであった場合には、当該他のユーザに対して、チケットが売却済みである旨をメール、またはチケットアプリ上のメッセージとして通知する。

一方、チケットアプリ３００がエラーメッセージを管理サーバ２００から受信した場合には（Ｓ７２７のＮｏ）、メッセージ表示部３５０は当該エラーメッセージを表示する（Ｓ７３１）。

（４ ハードウェア構成）
以下、管理サーバ２００及び携帯型端末１００を実現可能なハードウェア構成について、図８及び図９を参照しながら説明する。

（４．１ 管理サーバ２００）
まず、図８を参照しながら、管理サーバ２００を実現可能なハードウェア構成を説明する。図８は、管理サーバ２００を実現可能なハードウェア構成の具体例を示す図である。図８に示すように、管理サーバ２００は、制御部８０１と、通信Ｉ／Ｆ（インタフェース）部８０５と、記憶部８０７と、表示部８１１と、入力部８１３とを含み、各部はバスライン８１５を介して接続される。

制御部８０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ。図示せず。）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ。図示せず。）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８０３等を含む。制御部８０１は、記憶部８０７に記憶される制御プログラム８０９を実行することにより、一般的な情報処理装置としての機能に加え、上述したチケットサービスに係る処理を実現可能に構成される。例えば、図２を参照しながら説明したウェブサイト提供部２１０、チケットステータス変更部２３０、抽選部２４０、チケット取得要求受信部２５０、チケットデータ送信部２６０、メッセージ送信部２７０は、ＲＡＭ８０３に一時記憶された上で、ＣＰＵ上で動作する制御プログラム８０９として実現可能である。

またＲＡＭ８０３は、制御プログラム８０９に含まれるコードの他、図２に示したユーザ情報２８１、チケット管理データ２８３、チケットステータス情報２８５、チケット購入申請者情報２８７、及びチケット売却申請者情報２８９の一部又は全部を一時的に保持する。更にＲＡＭ８０３は、ＣＰＵが各種処理を実行する際のワークエリアとしても使用される。

通信Ｉ／Ｆ部８０５は、携帯型端末１００を含む外部の装置との間で、有線又は無線によるネットワークＮを介したデータ通信を行うためのデバイスである。図２で示したウェブサイト提供部２１０やチケット取得要求受信部２５０、チケットデータ送信部２６０、及びメッセージ送信部２７０が携帯型端末１００との間で行う通信は、全て通信Ｉ／Ｆ部８０５が行う。

記憶部８０７は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶部８０７は、一般的な情報処理装置としての機能を実現するためのオペレーションシステム（ＯＳ）及びデータ（図示せず）を記憶する。また記憶部８０７は、制御プログラム８０９及びＤＢ２８０を記憶する。

制御プログラム８０９は、上述のチケットサービスに係る処理を行うためのプログラムである。前述のとおり、図２に示したウェブサイト提供部２１０、チケットステータス変更部２３０、抽選部２４０、チケット取得要求受信部２５０、チケットデータ送信部２６０、メッセージ送信部２７０は、制御プログラム８０９に含まれ得る。

ＤＢ２８０は、電子チケットサービスの提供に必要な各種データ、例えばユーザ情報２８１、チケット管理データ２８３、チケットステータス情報２８５、チケット購入申請者情報２８７、及びチケット売却申請者情報２８９を含むことができる。ＤＢ２８０に含まれる各種データは、必要に応じてＲＡＭ８０３にロードされ、制御部８０１に含まれるＣＰＵから参照される。

表示部８１１は、サービス事業者に情報を提示するためのディスプレイ装置である。表示部８１１の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等が挙げられる。入力部８１３は、サービス事業者から入力を受け付けるためのデバイスである。入力部８１３の具体例としては、キーボードやマウス、タッチパネル等を挙げることができる。

なお、管理サーバ２００は、表示部８１１及び入力部８１３を必ずしも備える必要はない。また表示部８１１及び入力部８１３は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やディスプレイポート等の各種インタフェースを介して外部から管理サーバ２００に接続されても良い。

（４．２ 携帯型端末１００）
次に、図９を参照しながら、携帯型端末１００を実現可能なハードウェア構成を説明する。図９は、携帯型端末１００のハードウェア構成の具体例を示す図である。図９に示すように、携帯型端末１００は、制御部１５１と、通信インタフェース（Ｉ／Ｆ）部１５５と、記憶部１５７と、タッチパネルディスプレイ１５９と、入力部１６５とを含み、各部はバスライン１６７を介して接続される。

制御部１５１は、ＣＰＵ、ＲＯＭ、ＲＡＭ１５３等を含む。制御部１５１は、記憶部１５７に記憶されるチケットアプリ３００、ブラウザ１１０、及びメールアプリ１２０を実行可能である。これにより、携帯型端末１００は一般的な情報処理装置としての機能に加え、上述したチケットサービスに係る各種処理を実現可能である。

また、ＲＡＭ１５３は、チケットアプリ３００、ブラウザ１１０、及びメールアプリ１２０に含まれるコードの他、図３に示したユーザ情報３７１、端末情報３７３、及びチケット情報３７５の一部又は全部を一次的に保持する。更にＲＡＭ１５３は、ＣＰＵが各種処理を実行する際のワークエリアとしても使用される。

通信Ｉ／Ｆ部１５５は、管理サーバ２００を含む外部の装置との間で、有線又は無線によるネットワークＮを介したデータ通信を行うためのデバイスである。図３で示した認証部３１０、端末情報取得部３２０、チケット取得部３３０、及びチケット売却申請部３４０等が管理サーバ２００との間で行う通信は、全て通信Ｉ／Ｆ部１５５が行う。

記憶部１５７は、例えばＨＤＤやフラッシュメモリ等の不揮発性の記憶媒体である。記憶部１５７は、一般的な情報処理としての機能を実現するためのオペレーションシステム（ＯＳ）やアプリケーション及びデータ（図示せず）を記憶する。また記憶部１５７は、チケットアプリ３００やブラウザ１１０、メールアプリ１２０を記憶する。

ブラウザ１１０は、管理サーバ２００の提供するチケットサービスサイトを含むネットワークＮ上の各種ウェブサイトをユーザＵに閲覧可能とするためのアプリケーションプログラムである。

メールアプリ１２０は、ユーザＵが管理サーバ２００や他のユーザとの間でメッセージの送受信を行うためのアプリケーションプログラムである。なお、メールアプリ１２０の代わりに、もしくはメールアプリ１２０に加えて、比較的リアルタイム性が高く、短めのメッセージのやり取りを行うことのできるメッセンジャーアプリを記憶部１５７に記憶し、制御部１５１で実行可能としてもよい。
チケットアプリ３００については、図３を参照しながら先述したため、ここでは説明を省略する。

タッチパネルディスプレイ１５９は、情報を提示する表示装置であるディスプレイ部１６１と、操作入力がなされるタッチパネル部１６３とが重ね併せて実装される装置である。タッチパネルディスプレイ１５９を用いることによりユーザＵは、ディスプレイ部１６１に表示された表示内容に対して、直接操作を行っているような直感的な操作感を得ることができる。

入力部１６５は、ユーザＵからの操作入力を受け付けるための、タッチパネルディスプレイ１５９とは別に設けられたデバイスである。入力部１６５の具体例としては、例えば操作ボタンやキーボード、マウス等を挙げることができる。

なお、携帯型端末１００は、入力部１６５を必ずしも備える必要はない。また、入力部１６５は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やＢｌｕｅｔｏｏｔｈ（登録商標）等の各種インタフェースを介して外部から携帯型端末１００に接続されても良い。

（５． 本実施形態の効果）
以上説明したように、本実施形態に係るチケットシステム１では、チケット購入をユーザＵが申請する際に、電子チケットを受領する端末に係る端末情報の入力をユーザＵから受ける。つまり、チケットの購入権をユーザＵが取得する前に、当該チケットを受領することのできる端末が決まるため、チケットの購入権をユーザＵが取得した後、当該チケットの受領権を他のユーザに自由に転売等されることを防ぐことができる。

一方で、管理サーバ２００の提供するチケットサービス上では、購入済みのチケットの売却申請、及び他のユーザが売却申請を行っているチケットへの購入申請を行うことができる。これにより、例えばスケジュールの変更などによりユーザＵのチケットが不要となった場合であっても、他のユーザがそれを購入及び利用することができる。更にこの際、管理サーバ２００が売買を仲介することで、不当に高い値段でチケットの売買がなされることを防ぐことができる。

また、管理サーバ２００は、チケット管理データ２８３において、発行済のチケットの全保有者のデータを管理している。これにより、チケットが紙チケットであるか電子チケットであるか否かにかかわらず、チケットを売却しようとしているユーザＵが、正当なチケットの保有者であるか否かを確認することができる。

（６ 付記事項）
なお、上述の実施形態の構成は、組み合わせたり或いは一部の構成部分を入れ替えたりしてもよい。また、本発明の構成は上述の実施形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加えてもよい。

１ ：チケットシステム
１００ ：携帯型端末
２００ ：管理サーバ
２１０ ：ウェブサイト提供部
２１１ ：ユーザ画面送信部
２１３ ：認証部
２１５ ：購入可能チケット情報取得部
２１７ ：チケット購入申請受信部
２１９ ：決済情報受信部
２２１ ：保有チケット情報取得部
２２３ ：チケット売却申請受信部
２２５ ：チケットステータス確認部
２３０ ：チケットステータス変更部
２４０ ：抽選部
２５０ ：チケット取得要求受信部
２６０ ：チケットデータ送信部
２７０ ：メッセージ送信部
２８０ ：データベース（ＤＢ）
３００ ：チケットアプリ
３１０ ：認証部
３２０ ：端末情報取得部
３３０ ：チケット取得部
３４０ ：チケット売却申請部
３５０ ：メッセージ表示部
３６０ ：ブラウザ起動部
３７０ ：データベース（ＤＢ）
Ｎ ：ネットワーク

Claims (9)

1. ユーザ端末とネットワークを介して通信する情報処理サーバであって、
   利用可能なユーザのユーザ種別が異なる第１種別チケット及び第２種別チケットを含む複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データと、各々のユーザとそのユーザ種別とを対応付けるユーザ管理データとを管理する管理手段と、
   売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信する手段と、
   前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認する手段と、
   前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とする手段と、
   購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信する手段と、
   前記ユーザ管理データを参照することにより、前記購入希望ユーザのユーザ種別を判別する手段と、
   売却申請中である１以上の売却対象チケットを、当該売却対象チケットが対象とするユーザ種別に合致する前記購入希望ユーザに販売するか否かを決める決定手段と、
   前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新する手段と
   を備える情報処理サーバ。
2. 前記決定手段は、複数の前記売却希望ユーザからそれぞれ売却の申出を受けている複数の売却対象チケットを、それぞれ、１以上の前記購入希望ユーザのうちのいずれの購入希望ユーザに販売するかを決める、
   請求項１記載の情報処理サーバ。
3. 前記購入希望ユーザによるチケット購入の申出の際に、決済方法を特定するための決済情報の入力を受ける手段
   を更に備える請求項１又は請求項２記載の情報処理サーバ。
4. 前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記売却希望ユーザのユーザ端末へ、チケット売却済である旨を通知する手段
   を更に備える請求項１乃至請求項３のいずれか１項記載の情報処理サーバ。
5. 前記決定手段は、
   前記購入希望ユーザが特定のユーザ種別である場合に、前記第１種別チケット及び前記第２種別チケットを含む売却対象チケットを、前記購入希望ユーザに販売するか否かを決め、
   前記購入希望ユーザが前記特定のユーザ種別ではない場合に、前記第２種別チケットの売却対象チケットを、前記購入希望ユーザに販売するか否かを決める、
   請求項１記載の情報処理サーバ。
6. 前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記購入希望ユーザの操作するユーザ端末のアプリケーションに電子チケットデータを送信するチケット送信手段
   を更に備える請求項１乃至請求項５のいずれか１項記載の情報処理サーバ。
7. 前記購入希望ユーザによるチケット購入の申出の際に、前記電子チケットデータを受領するチケット受領端末を特定するための端末情報の入力を受け付ける手段と、
   前記購入希望ユーザの操作するユーザ端末から前記端末情報を受信する手段と
   を更に備え、
   前記チケット送信手段は、ユーザ端末から受信した前記端末情報が、前記購入希望ユーザにより特定されたチケット受領端末に係るものと合致する場合に、前記電子チケットデータを送信する、
   請求項６記載の情報処理サーバ。
8. ユーザ端末とネットワークを介して通信する情報処理サーバが、
   利用可能なユーザのユーザ種別が異なる第１種別チケット及び第２種別チケットを含む複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データと、各々のユーザとそのユーザ種別とを対応付けるユーザ管理データとを管理するステップと、
   売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信するステップと、
   前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認するステップと、
   前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とするステップと、
   購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信するステップと、
   前記ユーザ管理データを参照することにより、前記購入希望ユーザのユーザ種別を判別するステップと、
   売却申請中である１以上の売却対象チケットを、当該売却対象チケットが対象とするユーザ種別に合致する前記購入希望ユーザに販売するか否かを決めるステップと、
   前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新するステップと
   を行う、情報処理方法。
9. ユーザ端末とネットワークを介して通信する情報処理サーバに、
   利用可能なユーザのユーザ種別が異なる第１種別チケット及び第２種別チケットを含む複数のチケットと、各チケットを保有する複数のユーザとを対応付けるチケット管理データと、各々のユーザとそのユーザ種別とを対応付けるユーザ管理データとを管理する処理と、
   売却希望ユーザの操作するユーザ端末からチケット売却の申出を受信するステップと、
   前記チケット管理データを参照することにより、前記売却希望ユーザがチケットを正当に保有しているか否かを確認する処理と、
   前記売却希望ユーザが正当にチケットを保有している場合に、当該チケットを売却申請中とする処理と、
   購入希望ユーザの操作するユーザ端末からチケット購入の申出を受信する処理と、
   前記ユーザ管理データを参照することにより、前記購入希望ユーザのユーザ種別を判別するステップと、
   売却申請中である１以上の売却対象チケットを、当該売却対象チケットが対象とするユーザ種別に合致する前記購入希望ユーザに販売するか否かを決める処理と、
   前記購入希望ユーザへのチケット販売に係る決済手続が完了した場合に、前記チケット管理データにおいて、チケットの保有者の情報を更新する処理と
   を実行させるためのプログラム。

Images