(57)【特許請求の範囲】
【請求項１】
イベントの参加権の当選者を抽選により決定する抽選装置であって、
前記抽選の応募者の会員識別情報を、前記イベントの識別情報及び当選したかどうかを表す情報に対応付けて記憶する応募情報ＤＢと、
前記参加権の購入者の会員識別情報を、前記イベントの識別情報に対応付けて記憶する購入履歴ＤＢと、
前記抽選への応募を受け付け、対象となるイベントの識別情報及び応募者の会員識別情報を前記応募情報ＤＢに記録する抽選受付手段と、
１以上の条件に基づき、前記応募情報ＤＢに記録されている応募者を優先度の異なる複数のグループに分類し、優先度の高いグループから順に抽選を行って当選者を決定し、前記応募情報ＤＢの記憶内容を更新する抽選手段と、
前記参加権の代金の支払いが確認された場合に、該当する当選者の会員識別情報を購入者の会員識別情報として前記購入履歴ＤＢに記録する手段と、
を備え、前記１以上の条件は、前記購入履歴ＤＢの記憶内容に基づき、過去の参加権の購入回数が閾値以下であるという条件を含み、
前記購入履歴ＤＢは、前記購入者の会員識別情報を、さらに当該購入者が参加権を転売したかどうかを表す情報に対応付けて記憶し、
さらに前記参加権の転売依頼、及び転売対象となる参加権の購入依頼を受け付け、前記購入履歴ＤＢの記憶内容に基づき、購入依頼者が同じイベントの参加権を重複して保有することとならないことを条件に参加権の転売が成立したと判断し、前記購入履歴ＤＢに対し、転売依頼者については、参加権を転売したことを表す情報を記録し、購入依頼者については、参加権の購入者として、会員識別情報を当該参加権に対応するイベントの識別情報に対応付けて記録する転売手段を備え、
前記１以上の条件は、前記購入履歴ＤＢの記憶内容に基づき、参加権の転売回数が閾値以下であるという条件を含む、抽選装置。
【請求項２】
前記抽選手段は、抽選を行ったグループから生じた落選者を、次の優先度のグループへ追加したうえで、当該次の優先度のグループの抽選を行う、請求項１に記載の抽選装置。
【請求項３】
前記購入履歴ＤＢから、参加権を転売していない購入者の会員識別情報及び当該参加権に対応するイベントの識別情報を抽出し、イベント参加者に関する確定情報としてチケット販売システムへ送信する確定情報送信手段を備える、請求項１に記載の抽選装置。
【請求項４】
前記確定情報送信手段は、さらに、前記確定情報を、対象となるイベントの会場に設置された端末に対し、来場者を認証するための情報として送信する、請求項３に記載の抽選装置。
【請求項５】
アーティストごとのファンクラブの会員情報を記憶するＤＢにアクセスする手段を備え、
前記イベントの識別情報は、イベントごとのアーティストの識別情報を含み、
前記１以上の条件は、前記抽選の応募者が応募対象イベントのアーティストのファンクラブ会員であるという条件を含む、請求項１乃至４のいずれか１項に記載の抽選装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、各種イベントの参加権の当選者を抽選により決定する技術に関する。
【背景技術】
【０００２】
従来、イベントなどのチケットを買い求める際には、インターネットや電話を通じて、チケット販売会社で所望のコンサートのチケットを予約したり、購入したりするのが一般的である。
【０００３】
ところが、例えば人気の高いアーティストのコンサートチケットについては、購入希望者が殺到したり、転売益を得ることを目的として購入する者が存在するなどの理由から、そのアーティストの音楽を本当に愛するファンであっても、入手が困難な状況となっている。
【０００４】
このため、下記特許文献１において、会員登録されている投票者（抽選応募者）を優先的に当選者とする抽選方法が知られているように、各アーティストのファンクラブでは、会員登録を行った者に対してチケット購入権を優先的に入手できる機会を与えている場合がある。なお、チケット購入権を入手した会員は、代金を支払ってチケット購入権とチケットとを引き換えることができる。
【特許文献１】特開２００３−４４６２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、最近では、ファンクラブの会員数が多い場合や、何らかの方法でファンクラブを通じてチケット購入権を大量に入手する者が存在する場合があり、ファンクラブに会員登録をしてもチケットの入手が困難な場合が生じている。
【０００６】
以上の課題を踏まえ、本発明は、複数のイベントを通して、できるだけ多くの異なる人に参加権を入手させるための抽選装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成すべく、本発明の抽選装置は、イベントの参加権の当選者を抽選により決定する装置であって、前記抽選の応募者の会員識別情報を、前記イベントの識別情報及び当選したかどうかを表す情報に対応付けて記憶する応募情報ＤＢと、前記参加権の購入者の会員識別情報を、前記イベントの識別情報に対応付けて記憶する購入履歴ＤＢと、前記抽選への応募を受け付け、対象となるイベントの識別情報及び応募者の会員識別情報を前記応募情報ＤＢに記録する抽選受付手段と、１以上の条件に基づき、前記応募情報ＤＢに記録されている応募者を優先度の異なる複数のグループに分類し、優先度の高いグループから順に抽選を行って当選者を決定し、前記応募情報ＤＢの記憶内容を更新する抽選手段と、前記参加権の代金の支払いが確認された場合に、該当する当選者の会員識別情報を購入者の会員識別情報として前記購入履歴ＤＢに記録する手段と、を備え、前記１以上の条件は、前記購入履歴ＤＢの記憶内容に基づき、過去の参加権の購入回数が閾値以下であるという条件を含むことを特徴とする。
【０００８】
本発明の実施形態では、前記抽選手段は、抽選を行ったグループから生じた落選者を、次の優先度のグループへ追加したうえで、当該次の優先度のグループの抽選を行うものとする。
【０００９】
本発明の別の実施形態では、前記購入履歴ＤＢは、前記購入者の会員識別情報を、さらに当該購入者が参加権を転売したかどうかを表す情報に対応付けて記憶し、前記参加権の転売依頼、及び転売対象となる参加権の購入依頼を受け付け、前記購入履歴ＤＢの記憶内容に基づき、購入依頼者が同じイベントの参加権を重複して保有することとならないことを条件に参加権の転売が成立したと判断し、前記購入履歴ＤＢに対し、転売依頼者については、参加権を転売したことを表す情報を記録し、購入依頼者については、参加権の購入者として、会員識別情報を当該参加権に対応するイベントの識別情報に対応付けて記録する転売手段を備えるようにしてもよい。
【００１０】
また別の実施形態では、前記１以上の条件は、前記購入履歴ＤＢの記憶内容に基づき、参加権の転売回数が閾値以下であるという条件を含むことができる。
【００１１】
さらに別の実施形態では、前記購入履歴ＤＢから、参加権を転売していない購入者の会員識別情報及び当該参加権に対応するイベントの識別情報を抽出し、イベント参加者に関する確定情報としてチケット販売システムへ送信する確定情報送信手段を備えるようにしてもよい。この場合、前記確定情報送信手段は、さらに、前記確定情報を、対象となるイベントの会場に設置された端末に対し、来場者を認証するための情報として送信するように構成されてもよい。
【００１２】
さらにまた別の実施形態では、アーティストごとのファンクラブの会員情報を記憶するＤＢにアクセスする手段を備え、前記イベントの識別情報は、イベントごとのアーティストの識別情報を含み、前記１以上の条件は、前記抽選の応募者が応募対象イベントのアーティストのファンクラブ会員であるという条件を含むのが好ましい。
【発明の効果】
【００１３】
本発明によれば、会員ごとの過去の参加権の購入履歴を管理し、参加権の購入回数が少ない会員を他の会員よりも優先して参加権の抽選に当選させることにより、複数のイベントを通じて、できるだけ多くの異なる会員に対してイベントへの参加機会を提供することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の抽選装置に関する実施例を図面を参照して説明する。なお、実施例においては、抽選装置は、ネットワークを介して他の装置と通信可能に構成されており、抽選サーバと称するものとする。
【００１５】
図１は、抽選サーバ３を用いて構成したチケット取引システム１の構成を示す。
【００１６】
チケット取引システム１は、本システム１の会員を対象として、イベント（例えば、コンサート）への参加権を、インターネット等のネットワークを通じて取引するためのシステムである。また、本実施例においては、インベントへの参加権のことを「チケット」と呼ぶものとする。「チケット」は、紙等で具現化されたチケットのみならず、そのようなチケットを購入する権利（いわゆるチケット購入権）を含むものとする。
【００１７】
チケット取引システム１は、ネットワークを介して相互通信可能に接続された抽選サーバ３、ＦＣサーバ５、チケット販売会社サーバ７、会場端末９、及びユーザ端末１１ａ，１１ｂ，１１ｃを含んで構成されている。
【００１８】
抽選サーバ３は、チケット取引システム１において主要な役割を果たす装置であり、ユーザ登録されている会員のなかから、イベントごとにチケットを購入するための抽選への応募者を募り、応募者を対象として抽選を行って当選者を決定する機能、当選者に関する情報をチケット販売システムであるチケット販売会社サーバ７へ送信する機能、及びチケット代金が支払われた（チケットが購入された）と判断した場合に、当該チケット購入者と他のユーザとの間におけるチケットの取引（転売）を支援する機能などを提供する。
【００１９】
ＦＣサーバ５は、歌手や芸能人等のイベントにおける対象アーティストごとのファンクラブのホームページを管理する装置であり、ファンクラブ会員の登録状況を管理する機能なども有する。また、ＦＣサーバ５は、説明の便宜上１つを示したが、アーティストごとに複数設置されてもよい。
【００２０】
チケット販売会社サーバ７は、イベント主催者からチケットの販売の依頼を受けたチケット販売会社が管理する装置であり、本システム１においては、抽選サーバ３が行う抽選の当選者に対してチケットを販売する機能を有する装置である。また、チケット販売会社サーバ７についても、説明の便宜上１つを示したが、複数設定されてもよい。
【００２１】
会場端末９は、イベント会場に設置される装置であり、来場予定者の情報を、来場者の認証情報として管理する。会場端末についても、各イベント会場にそれぞれ設置され得る。
【００２２】
ユーザ端末１１ａ，１１ｂ，１１ｃは、本システム１において会員登録されているユーザが操作する装置であり、抽選サーバ３が行う抽選に応募する際や、抽選サーバ３において提供される転売情報にアクセスして転売対象となるチケットの購入を申し込む際などに使用される。ユーザ端末１１ａ〜１１ｃについても、会員登録されているユーザの数に応じて複数存在し得る。
【００２３】
図２は、抽選サーバ３、ＦＣサーバ５、チケット販売会社サーバ７、会場端末９、及びユーザ端末１１ａ〜１１ｃのハードウェア構成を示す。これらの装置は、いずれも、中央処理装置（ＣＰＵ）２００、ＲＡＭ等のメモリ２０１、ハードディスクドライブ（ＨＤＤ）２０２、キーボード・マウス等の入力装置２０３、ディスプレイ等の出力装置２０４、ＬＡＮアダプタ等の通信装置２０５がバスを介して接続される一般的な情報処理装置により実現され得る。なお、会場端末９の入力装置２０３には、ＩＣカード等の情報可搬媒体に記録されている情報を短距離無線通信により読み出す読み取り装置（例えば、カードリーダ）が含まれる。また、ユーザ端末１１ａ〜１１ｃは、携帯電話機やＰＤＡ等の可搬型の情報処理装置であってもよい。
【００２４】
図３は、抽選サーバ３の構成を示すブロック図である。
【００２５】
抽選サーバ３は、イベントのチケットの当選者を抽選により決定するといった機能を実現するため、
ユーザ登録されている会員の情報を記憶する会員データＤＢと、
ユーザ登録されている会員の顔の画像ファイルを記憶する顔画像ＤＢと、
抽選の応募者の会員識別情報（抽選サーバ３が付与するユーザＩＤ）を、イベントの識別情報（例えば、アーティストの識別情報を含む後述の公演コード）、及び当選したかどうかを表す情報に対応付けて記憶する応募情報ＤＢと、
チケットの購入者の会員識別情報を、イベントの識別情報及び当該購入者がチケットを転売したかどうかを表す情報に対応付けて記憶する購入履歴ＤＢと、
チケットの購入者の会員識別情報を、当該購入者が実際に会場に来場したかどうかを表す情報に対応付けて記憶する来場履歴ＤＢ、
という各種のデータベースを備える。これらのＤＢは、例えば、ＨＤＤ２０２に格納される。これらＤＢのデータ構造については、図４を参照して後述する。なお、顔画像ＤＢは、ユーザ登録を希望するユーザから受け付けた画像ファイルを記憶するためのＤＢであるため、そのデータ構造については図示を省略する。
【００２６】
また、抽選サーバ３は、抽選や転売等の各種の機能を提供するため、例えばＨＤＤ２０２に記憶されている所定のプログラムをＣＰＵ２００が実行することにより機能的に実現される手段として、
ユーザ登録に必要な情報を受け付けてユーザ登録を行い、会員データＤＢの記憶内容を更新するユーザ登録手段３０１と、
チケット販売会社サーバ７からイベントごとのチケットの情報を受信し、購入履歴ＤＢの記憶内容を更新するチケット情報受付手段３０２と、
ユーザ端末１１ａ〜１１ｃから送信されるユーザの要求に応じて、応募を受け付けている抽選の対象となるイベントの情報を提示（送信）するイベント情報提示手段３０３と、
ユーザ端末１１ａ〜１１ｃから送信されるユーザの要求に応じて抽選への応募を受け付け、対象となるイベントの識別情報及び応募者の会員識別情報を応募情報ＤＢに記録する抽選受付手段３０４と、
１以上の条件に基づき、応募情報ＤＢに記録されている応募者を優先度の異なる複数のグループに分類し、優先度の高いグループから順に抽選を行って当選者を決定し、応募情報ＤＢの記憶内容を更新したり、ＦＣサーバ５に備えられたファンクラブの会員情報を管理する後述のＦＣ会員ＤＢにアクセスする抽選手段３０５と、
チケットの代金の支払いが確認された場合に、該当する当選者の会員識別情報を購入者の会員識別情報として購入履歴ＤＢに記録する購入者情報記録手段３０６と、
チケットの転売依頼、及び転売対象となるチケットの購入依頼を受け付け、購入履歴ＤＢの記憶内容に基づき、購入依頼者が同じイベントのチケットを重複して保有することとならないことを条件にチケットの転売が成立したと判断し、購入履歴ＤＢに対し、転売依頼者については、チケットを転売したことを表す情報を記録し、購入依頼者については、チケットの購入者として、会員識別情報を当該チケットに対応するイベントの識別情報に対応付けて記録する転売手段３０７と、
購入履歴ＤＢから、チケットを転売していない購入者（チケット保有者）の会員識別情報及び当該チケットに対応するイベントの識別情報を抽出し、イベント参加者に関する確定情報としてチケット販売会社サーバ７へ送信したり、その確定情報を、対象となるイベントの会場に設置された会場端末９に対し、来場者を認証するための情報として送信する確定情報送信手段３０８と、
必要に応じて来場履歴ＤＢの記憶内容を更新する来場履歴更新手段３０９と、
を備えている。
【００２７】
これらの手段による処理の詳細な内容については、図１０〜１５を参照して後述する。
【００２８】
図４（Ａ）は、抽選サーバ３に備えられている会員データＤＢのデータ構造を示す。
【００２９】
図示のように、会員データＤＢは、会員登録されたユーザごとに、ログインＩＤ、ログインパスワード（ＰＷ）、ユーザＩＤ、ニックネーム、住所、氏名、電話番号（ＴＥＬ）、電子メールアドレス（Ｅ−Ｍａｉｌ）、クレジットカードの番号（クレジット番号）、顔画像のファイル名（顔画像）、会員ステータス、及びチェックフラグを格納する。
【００３０】
顔画像の欄には、会員登録を行ったユーザから受け付けた顔画像のファイル名が格納される。具体的には、ユーザ登録手段３０１は、例えば、受け付けた画像ファイルの名称（例えば、abcdefg.jpg）を、対応するユーザのユーザＩＤを用いてリネイム（例えば、200806190003.jpgに変更）して顔画像の欄に格納し、その画像ファイルを顔画像ＤＢに格納する。
【００３１】
会員ステータスの欄には、会員登録されたユーザごとに、チケット取引システム１を利用するための年会費を支払っているかに応じて、以下の値が記録される。
【００３２】
（１）支払有…１
（２）支払無…０
具体的には、例えば、ユーザ登録手段３０１は、ユーザが会員登録を行った時点で又はクレジット番号の欄に格納されたクレジットカード番号に対応するクレジット会社からの入金が確認できた時点で、該当するユーザに関する会員ステータスの欄に１を記録する。
【００３３】
なお、年会費の入金方法は、クレジット決済に限らず、銀行振込みなどの他の方法でもよく、ユーザ登録手段３０１は、前述と同様に、入金が確認できた時点で最初の会員登録を行い及び会員登録を継続させる。
【００３４】
チェックフラグの欄には、会員登録されたユーザごとに、ユーザの種類に応じて以下の値が記録される。
【００３５】
（１）規約違反者…９
チケット取引システム１の利用規約（例えば、オークションシステム等の他のシステムを介してチケットを転売してはいけないという規約など）に違反しているユーザである。
【００３６】
（２）注意会員…１
システム管理者が、将来的に規約違反者になるおそれがあると判断したユーザである。例えば、チケット取引システム１におけるチケットの転売回数が非常に多い（例えば、１年で転売を５回以上行っている）ユーザや、会員登録の情報（例えば、住所など）を頻繁に変更しているユーザが注意会員として登録される。
【００３７】
（３）通常会員…０
規約違反者又は注意会員ではない一般的なユーザである。
【００３８】
具体的には、ユーザ登録手段３０１は、最初の会員登録の時点では、各ユーザに関して０を設定する。また、ユーザ登録手段３０１は、ユーザが会員登録後に規約違反者又は注意会員に該当するに至った場合には、入力装置２０３（キーボードなど）を介して行われるシステム管理者からの指示に従い、当該ユーザに関するチェックフラグの値を変更する。
【００３９】
図４（Ｂ）は、抽選サーバ３に備えられている購入履歴ＤＢのデータ構造を示す。
【００４０】
図示のように、購入履歴ＤＢは、チケットの購入者のユーザＩＤに対応付けて、公演コード、公演日、申込日、申込枚数、申込種別、ステータス、席種、座席番号、及びチケット価格を記憶する。
【００４１】
公演コードは、イベントの識別情報であり、例えば、アーティストの識別情報と、コンサートの開催年を表す情報と、そのコンサートが含まれるコンサートツアーの開催回を表す情報とを組み合わせて構成される。具体的には、アーティストの識別情報がaaaa、コンサートの開催年が2008年、そのコンサートに対応するコンサートツアーが2008年における２回目のツアーに該当する場合には、公演コードはaaaa2008002となる。
【００４２】
申込日は、例えば、チケットの購入者が抽選の当選者の場合には、抽選に応募した日であり、チケットの購入者が転売によってチケットを購入した者である場合には、チケットを転売により購入した日である。
【００４３】
申込枚数は、例えば、チケットの購入者が抽選の当選者の場合には、本人のチケットの枚数（１枚）と、抽選の応募時に申し込んだ同伴者のチケットの枚数（例えば、０〜３枚）の合計である。また、チケットの購入者が同伴者や転売によってチケットを購入した者である場合には、購入者本人のチケットの枚数（１枚）である。
【００４４】
申込種別の欄には、チケット購入者の種類に応じて、以下の値が設定される。
【００４５】
（１）購入者…１
抽選の当選者であり、現在もチケットを保有しているユーザである。
【００４６】
（２）同伴者…２
抽選の当選者の同伴者であり、現在もチケットを保有しているユーザである。
【００４７】
（３）転売者…３
チケットを転売したユーザである。
【００４８】
（４）転売購入者…４
チケットを転売により購入したユーザである。
【００４９】
（５）無効設定者…５
チケットを購入した後に、規約違反者となったユーザである。
【００５０】
具体的には、チケットの最初の保有者となるのは、抽選の当選者及びその同伴者であるため、申込種別の欄に最初に設定される値は、１（購入者）と２（同伴者）のいずれかである。この値は、購入者情報記録手段３０６によって設定される。また、チケットの転売が成立した場合には、転売手段３０７によって、３（転売者）と４（転売購入者）のいずれかが設定される。さらに、ユーザ登録手段３０１は、会員データＤＢのチェックフラグに９（規約違反者）を設定する場合、該当するユーザのレコード（公演日前のイベントに関するレコードに限る）が購入履歴ＤＢに存在する場合には、そのレコードに含まれる申込種別の値を５（無効設定者）に設定する。
【００５１】
ステータスの欄には、ユーザがチケットを転売したかどうかなどに応じて、以下の値が記録される。
【００５２】
（１）有効…１
ユーザがチケットを保有しており（転売しておらず）、且つ当該ユーザが無効設定者ではない場合である。
【００５３】
（２）転売中…２
ユーザがチケットを転売中（抽選サーバ３に対して転売を依頼している場合）である。
【００５４】
（３）転売済…３
ユーザがチケットを転売した場合である。
【００５５】
（４）無効…４
ユーザが無効設定者の場合である。
【００５６】
ステータスの欄に最初に設定される値は１（有効）である。この値は、購入者情報記録手段３０６によって設定される。また、チケットの転売依頼があった場合及び転売が成立した場合には、転売手段３０７によって２（転売中）と３（転売済）のいずれかが設定される。さらに、ユーザ登録手段３０１は、申込種別の値を５（無効設定者）に設定する場合に、ステータスの欄に４（無効）を設定する。
【００５７】
図４（Ｃ）は、抽選サーバ３に備えられている応募情報ＤＢのデータ構造を示す。
【００５８】
図示のように、応募情報ＤＢは、抽選の応募者本人のユーザＩＤに対応付けて、公演コード、公演日、申込日、申込枚数、当落ステータス、同伴者ｉｄ及びグループを記憶する。
【００５９】
申込日の欄には、抽選に応募した日が記録される。
【００６０】
申込枚数の欄には、応募者が単独で抽選に応募した場合は１、同伴者のチケットも併せて（同伴者ｉｄを入力して）応募した場合には２以上の値（本実施例では２〜４）が記録される。なお、同伴者分として応募できるチケットの枚数は、応募者が、応募対象イベントのアーティストのファンクラブが運営するパソコン用ホームページと携帯電話機用ホームページのいずれか一方の会員となっている場合は、最大で１枚であり、両方の会員となっている場合は、最大で３枚としてもよい。
【００６１】
当落ステータスの欄には、当選したかどうかを表す情報として、以下の値が設定される。
【００６２】
（１）０
落選した場合である。
【００６３】
（２）１
当選した場合である。
【００６４】
同伴者ｉｄの欄には、応募者が入力した同伴者のユーザＩＤが記録される。従って、同伴者もチケット取引システム１において会員登録している必要がある。
【００６５】
グループの欄には、ユーザごとに抽選手段３０５によって決定されたグループを表す情報が格納される。本実施例では、７種類のグループを定義するものとし、各グループを表す情報として優先度を表す数字を用いる（例えば、優先度が最も低いグループは７で表わされ、優先度が最も高いグループは１で表わされる。）ものとする。
【００６６】
図４（Ｄ）は、抽選サーバ３に備えられている来場履歴ＤＢのデータ構造を示す。
【００６７】
図示のように、来場履歴ＤＢは、チケットの購入者確定者のユーザＩＤに対応付けて、公演コード、公演日、来場日時、及び来場ステータスを記憶する。購入確定者とは、抽選又は転売を通じてチケットを購入したユーザのうち、予め定められたチケットの転売可能期間を経過した時点においてチケットを有効に保有しているユーザのことである。
【００６８】
来場日時の欄には、購入確定者がイベント会場に訪れた日時が記録される。具体的には、例えば、会場において認証がとれた日時が記録される。
【００６９】
来場ステータスの欄には、購入確定者が実際に入場したかどうかを表す情報として、以下の値が設定される。
【００７０】
（１）０
未入場の場合（来場していない場合）である。
【００７１】
（２）１
入場済みの場合である。
【００７２】
図５は、ＦＣサーバ５の構成を示すブロック図である。
【００７３】
ＦＣサーバ５は、アーティストのファンクラブ会員を管理するためのＦＣ会員ＤＢを備える。
【００７４】
ＦＣ会員ＤＢは、例えば、ＦＣサーバ５のＨＤＤ２０２に格納される。
【００７５】
また、ＦＣサーバ５は、例えばＨＤＤ２０２に記憶されている所定のプログラムをＣＰＵ２００が実行することにより機能的に実現される手段として、
ファンクラブへの会員登録を行い、ＦＣ会員ＤＢの記憶内容を更新するＦＣ会員登録手段５０１と、
ファンクラブへの会員登録を行う際に、登録の対象となるユーザに関し、抽選サーバ３に対して、抽選サーバ３で管理されているユーザＩＤを問い合わせるユーザＩＤ問合せ手段５０２と、
抽選サーバ３からの要求に応じて、抽選サーバ３が行う抽選の対象となるユーザがファンクラブ会員かどうかを検査し、検査結果を抽選サーバ３へ送信するＦＣ会員登録検査手段５０３と、
を備える。
【００７６】
上記の各手段による処理の詳細な内容については、図１０及び図１２を参照して後述する。
【００７７】
図６は、ＦＣサーバ５に備えられているＦＣ会員ＤＢのデータ構造を示す。
【００７８】
図示のように、ＦＣ会員ＤＢは、ファンクラブが運営するホームページにログインするためのＩＤ（ＦＣログインＩＤ）に対応付けて、ログイン用のパスワード（ＦＣパスワード）、ユーザＩＤ、及び対象サイトを記憶する。
【００７９】
ユーザＩＤの欄には、抽選サーバ３で会員登録する際に発行されるユーザＩＤが記録される。
【００８０】
対象サイトの欄には、会員登録の対象となるホームページの種類を表す情報として、以下の値が設定される。
【００８１】
（１）１
パソコン用のホームページにおいて会員登録している場合である。
【００８２】
（２）２
携帯電話用のホームページにおいて会員登録している場合である。
【００８３】
（３）３
パソコン用のホームページと携帯電話用のホームページの両方において会員登録している場合である。
【００８４】
図７は、チケット販売会社サーバ７の構成を示すブロック図である。
【００８５】
チケット販売会社サーバ７は、
チケット販売会社サーバ７で販売しているすべてのイベントのチケットに関する情報を管理するチケットマスタＤＢと、
抽選サーバ３から受信した抽選の当選者に関する情報を管理する当選者情報ＤＢと、
抽選サーバ３から受信した購入確定者に関する情報及び当該購入確定者が購入したチケットに関する情報（これらの情報を纏めて「購入者確定情報」という。）を管理する確定情報ＤＢと、
を備える。
【００８６】
上記の各ＤＢは、例えば、チケット販売会社サーバ７のＨＤＤ２０２に格納される。
【００８７】
また、例えばＨＤＤ２０２に記憶されている所定のプログラムをＣＰＵ２００が実行することにより機能的に実現される手段として、
抽選対象となるチケットの情報を抽選サーバ３に対して送信するチケット情報送信手段７０１と、
チケット代金の入金が確認できた場合に、当選者情報ＤＢの記憶内容のうち、該当する当選者に関する記憶内容を更新する当選者情報更新手段７０２と、
抽選サーバ３から受信した購入者確定情報に基づき、購入者情報ＤＢの記憶内容を更新する確定情報ＤＢ更新手段７０３と、
確定情報ＤＢに記録されている購入確定者に対し、チケットを発行（印刷又は電子チケットを送信）するチケット発行手段７０４と、
を備える。
【００８８】
本実施例では、チケット情報送信手段７０１は、抽選サーバ３に対し、チケットの情報として、公演コードや公演日等のイベントに関する情報だけでなく、席種、座席番号、価格等の座席に関する情報も送信するものとするが、指定席のないイベント（立ち見席や自由席だけのイベント）の場合には、座席に関する情報を送信しなくてもよい。また、上記の各手段による処理の詳細な内容については、図１１、図１３、及び図１４を参照して後述する。
【００８９】
図８（Ａ）は、チケット販売会社サーバ７に備えられているチケットマスタＤＢのデータ構造を示す。
【００９０】
図示のように、チケットマスタＤＢは、公演コードに対応付けて、公演日、席種、座席番号、価格、及び募集代理店を記憶する。
【００９１】
募集代理店の欄には、チケット販売会社サーバ７で取り扱われているチケットの購入者を募集する又は抽選の応募者を募集する代理店に関する情報が記録される。例えば、チケット販売会社サーバ７が、あるイベントに関して１万枚のチケットを扱っている場合において、その全てのチケットに関する当選者の選定を抽選サーバ３に任せる場合には、そのイベントに関する全てのレコードにおける募集代理店の欄に、抽選サーバ３を表す情報が格納される。
【００９２】
図８（Ｂ）は、チケット販売会社サーバ７に備えられている当選者情報ＤＢのデータ構造を示す。
【００９３】
図示のように、当選者情報ＤＢは、ユーザＩＤに対応付けて、公演コード、公演日、申込日、申込枚数、同伴者ｉｄ、及び入金を記憶する。
【００９４】
ユーザＩＤ〜同伴者ｉｄの欄に記録される値は、抽選サーバ３に備えられている応募情報ＤＢ（図６）の記憶内容と同様である。
【００９５】
入金の欄には、チケット代金の入金の有無に応じて、以下の値が設定される。
【００９６】
（１）０
未入金であることを表す値であり、当選者情報ＤＢに新規レコードが作成される時点で設定される。
【００９７】
（２）１
入金が確認できたことを表す値である。
【００９８】
図８（Ｃ）は、チケット販売会社サーバ７に備えられている確定情報ＤＢのデータ構造を示す。
【００９９】
図示のように、確定情報ＤＢは、ユーザＩＤに対応付けて、公演コード、公演日、席種、座席番号、住所、及び氏名を記憶する。
【０１００】
図９は、会場端末９の構成を示すブロック図である。
【０１０１】
会場端末９は、抽選サーバ３から受信した購入者確定情報を、来場者を認証するための認証情報として記憶する認証情報ＤＢを備える。
【０１０２】
認証情報ＤＢは、例えば、会場端末９のＨＤＤ２０２に格納される。また、このＤＢのデータ構造は、チケット販売会社サーバ７に備えられている確定情報ＤＢ（図８（Ｃ））のデータ構造と同様である。
【０１０３】
さらに、会場端末９は、例えばＨＤＤ２０２に記憶されている所定のプログラムをＣＰＵ２００が実行することにより機能的に実現される手段として、
会場端末９は、抽選サーバ３に対し、購入者確定情報の送信を要求する確定情報要求手段９０１と、
カードリーダを介してＩＣカードに記録されている情報を取得するＩＣデータ取得手段９０２と、
来場者と購入確定者の間で認証を行った結果に関する情報を受け付ける認証結果受付手段９０３と、
を備える。
【０１０４】
なお、上記の各手段による処理の詳細については、図１５を参照して後述する。
【０１０５】
図１０〜図１５は、チケット取引システム１における情報処理の流れを表すフローチャートである。以下、こられらの図を参照して、かかる情報処理の流れを説明する。
【０１０６】
図１０（Ａ）は、ＦＣサーバ５におけるＦＣ会員登録処理、及びＦＣサーバ５からの問い合わせに対する抽選サーバ３の応答処理のフローチャートを示す。
【０１０７】
まず、チケット取引システム１における会員登録を希望するユーザは、抽選サーバ３による抽選の対象となるイベントのアーティストのファンクラブに会員登録（ＦＣ会員登録）するため、ユーザ端末（例えば、１１ａ）を操作し、ＦＣサーバ５に対してＦＣ会員登録申込データを送信する（ＳＴ１５０１）。
【０１０８】
ＦＣ会員登録申込データには、ＦＣ会員ＤＢ（図６）に格納される情報として、例えば、ファンクラブが運営するホームページにログインするために必要なＦＣログインＩＤ、ＦＣパスワード、及び会員登録を希望する対象サイトに関する情報が含まれる。例えば、ＦＣログインＩＤ及びＦＣパスワードは、チケット取引システム１で会員登録する際に用いるログインＩＤ及びパスワードと同一でもよい。また、ＦＣログインＩＤ及びＦＣパスワードが本システム１で登録済みのログインＩＤ及びパスワードと異なる場合には、ユーザは、抽選サーバ３に対してユーザＩＤを問い合わせるために、本システム１のログインＩＤ及びパスワードもＦＣ会員登録申込データとして送信するように構成しておく。
【０１０９】
ＦＣサーバ５のＦＣ会員登録手段５０１は、ＦＣ会員登録申込データを受信すると（ＳＴ１５０２）、そのデータの一部（ＦＣログインＩＤ、ＦＣパスワード、及び対象サイト）をＦＣ会員ＤＢに記録することによりＦＣ会員登録を行う（ＳＴ１５０３）。
【０１１０】
ＦＣ会員登録申込データがＦＣ会員ＤＢに記録されると、ユーザＩＤ問合せ手段５０２は、抽選サーバ３に対し、ユーザ端末１１ａから受信したＦＣ会員登録申込データに含まれているＦＣログインＩＤとＦＣパスワードを用いて、ユーザＩＤの問い合わせデータを送信する（ＳＴ１５０４）。なお、ＦＣログインＩＤ及びＦＣパスワードが本システム１に登録済みのログインＩＤ及びパスワードと異なる場合には、本システム１のログインＩＤ及びパスワードが用いられるものとする。ユーザＩＤの問い合わせデータに含まれるログインＩＤ及びパスワードを、「問い合わせ用ログインＩＤ」及び「問い合わせ用パスワード」という。
【０１１１】
また、ＦＣサーバ５は、既にＦＣサーバ５においてＦＣ会員登録を済ませているユーザについては、ＦＣ会員登録の処理（ＳＴ１５０３の処理）を省略し、問い合わせ用ログインＩＤ及び問い合わせ用パスワードを当該ユーザから受け付け、ユーザＩＤの問い合わせデータとして抽選サーバ３に送信するように構成しておくのが好ましい。
【０１１２】
抽選サーバ３のユーザ登録手段３０１は、ＦＣサーバ５から問い合わせデータを受信すると（ＳＴ１５０５）、受信した問い合わせデータに含まれている問い合わせ用ログインＩＤと問い合わせ用パスワードを用いて、会員データＤＢ（図４（Ａ））内でユーザＩＤを検索する（ＳＴ１５０６）。
【０１１３】
具体的には、問い合わせ用ログインＩＤと問い合わせ用パスワードを検索キーとして、会員データＤＢのログインＩＤの欄とログインＰＷの欄を検索し、問い合わせ用ログインＩＤと問い合わせ用パスワードの両方に一致するレコードが見つかった場合には、該当するレコードからユーザＩＤを抽出する。
【０１１４】
ユーザ登録手段３０１は、上記の検索の結果、ユーザＩＤが見つかったかどうかを判断し（ＳＴ１５０７）、ユーザＩＤが見つからなかった場合（ＳＴ１５０７の判断がＮｏの場合）、すなわち会員登録されていない場合には、新たにユーザＩＤを発行（生成）し（ＳＴ１５０８）、会員データＤＢにレコードを新規作成して、発行したユーザＩＤ、受信したログインＩＤ、及び受信したパスワードを記録することにより、仮会員登録を行う（ＳＴ１５０９）。
【０１１５】
ユーザ登録手段３０１は、上記の検索の結果、ユーザＩＤが見つかった場合（ＳＴ１５０７の判断がＹｅｓの場合）、すなわち既に会員登録されている場合には抽出したユーザＩＤを、又はＳＴ１５０８で発行したユーザＩＤを、問い合わせ結果としてＦＣサーバ１５１１に対して送信する（ＳＴ１５１０）。
【０１１６】
ＦＣサーバ５のＦＣ会員登録手段５０１は、抽選サーバ３からユーザＩＤを受信すると（ＳＴ１５１１）、そのユーザＩＤを用いてＦＣ会員ＤＢの記憶内容のうち該当するユーザに関する情報を更新する（ＳＴ１５１２）。
【０１１７】
図１０（Ｂ）は、抽選サーバ３による会員登録処理のフローチャートを示す。
【０１１８】
次に、ユーザは、ユーザ端末１１ａを操作し、抽選サーバ３に対して会員登録申込データを送信する（ＳＴ１５１３）。
【０１１９】
会員登録申込データには、会員データＤＢ（図４（Ａ））に格納される情報として、ユーザが希望するログインＩＤ、ユーザが希望するログインパスワード、ニックネーム、住所、氏名、電話番号、電子メールアドレス、クレジットカード番号、及び顔の画像ファイルが含まれる。なお、既にＦＣサーバ５でＦＣ会員登録を済ませたユーザは、問い合わせ用ログインＩＤ及び問い合わせ用パスワードを、ログインＩＤ及びログインパスワードとして送信するのがよい。
【０１２０】
抽選サーバ３のユーザ登録手段３０１は、ユーザ端末１１ａから会員登録申込データを受信すると（ＳＴ１５１４）、仮会員登録されているかどうかを判断する（ＳＴ１５１５）。
【０１２１】
上記判断の結果、仮会員登録されていない場合（ＳＴ１５１５の結果がＮｏの場合）、すなわち会員登録申込データに含まれるログインＩＤとログインパスワードに一致するレコードが会員データＤＢに存在しない場合には、ユーザ登録手段３０１は、ユーザＩＤを新たに発行し（ＳＴ１５１６）、受信した会員登録申込データ及び発行したユーザＩＤを用いて会員データＤＢと顔画像ＤＢの記憶内容を更新（レコードを新たに作成）することにより、会員登録を行う（ＳＴ１５１７）。
【０１２２】
一方、ＳＴ１５１５において仮会員登録されていると判断した場合（ＳＴ１５１５の判断がＹｅｓの場合）、すなわち会員登録申込データに含まれるログインＩＤとパスワードに一致するレコードが会員データＤＢに存在する場合には、受信した会員登録申込データのうちログインＩＤとパスワード以外のデータを用いて、該当するレコードの内容を更新することにより会員登録を行う（ＳＴ１５１７）。
【０１２３】
ユーザ登録手段３０１は、ＳＴ１５１７で会員登録を行った後、ユーザ端末１１ａに対して申込結果を通知し（ＳＴ１５１８）、ユーザ端末１１ａは申込結果を受領する（ＳＴ１５１９）。
【０１２４】
申込結果には、例えば、会員登録申込データに含まれるログインＩＤとパスワードを用いて会員登録が行われたことを表す情報や、会員登録の内容を確認するためのホームページのＵＲＬ及びそのページにアクセスして確認ボタンをクリックしなければ本登録されないことを表す情報を含めることができる。後者の情報を含む場合には、ユーザ登録手段３０１は、ユーザがそのページにアクセスして確認ボタンをクリックしたことを条件に、会員登録が有効なものとして取り扱うことが考えられる。
【０１２５】
チケット取引システム１では、会員登録が完了すると、そのユーザに対して、ＩＣカードが発行され、会員データＤＢに記録された住所及び氏名を宛先としてＩＣカードが送付される。また、そのＩＣカードは、暗号化されたユーザＩＤ及び顔画像を表す情報を記憶しており、イベント会場へ入場する際に参照される。
【０１２６】
図１１（Ａ）は、抽選サーバ３によるチケット情報の格納処理のフローチャートを示す。
【０１２７】
まず、チケット販売会社サーバ５は、チケットマスタＤＢ（図８（Ａ））で管理しているチケット情報（イベントの情報を含む）のうち、抽選サーバ３に割り当てられている情報を抽選サーバ３に対して所定のタイミング（例えば、チケットマスタＤＢに情報が追加されたタイミング）で送信する（ＳＴ１５２０）。
【０１２８】
抽選サーバ３のチケット情報受付手段３０２は、チケット販売会社サーバ５からチケット情報を受信すると（ＳＴ１５２１）、その情報を用いて購入履歴ＤＢ（図４（Ｂ））の記憶内容を更新する（ＳＴ１５２２）。
【０１２９】
具体的には、購入履歴ＤＢの記憶内容のうち、公演コード、公演日、席種、座席番号、及び価格に関する情報が記録される。このようにして、チケット取引システム１における抽選の対象となるチケット情報が抽選サーバ３に蓄積される。
【０１３０】
図１１（Ｂ）は、抽選サーバ３による抽選の応募者データの格納処理のフローチャートを示す。
【０１３１】
このフロチャートは、チケット取引システム１で会員登録済みのユーザが、チケットの抽選に応募してから、チケットの抽選及び転売が行われ、購入確定者が決定し、チケットが発行されるまでの処理の流れを示す。
【０１３２】
まず、ユーザは、ユーザ端末（例えば、１１ｂ）を操作し、抽選サーバ３に蓄積されている抽選対象となるチケットに関する情報の提示要求を抽選サーバ３に対して送信する（ＳＴ１５２３）。なお、ユーザは、ログインＩＤとログインパスワードを用いて抽選サーバ３にログインしているものとする。
【０１３３】
チケット情報の提示要求としては、抽選に応募できるすべてのチケット情報の提示を要求する情報、特定のアーティストに関するチケット情報の提示を要求する情報、特定の日に開催されるイベントの情報の提示を要求する情報、又は特定の価格帯で購入できるチケット情報の提示を要求する情報などが考えられる。
【０１３４】
抽選サーバ３のイベント情報提示手段３０３は、ユーザ端末１１ｂからチケット情報の提示要求を受信すると（ＳＴ１５２４）、該当するチケット情報を購入履歴ＤＢから抽出し（ＳＴ１５２５）、ユーザ端末１１ｂに対して送信する（ＳＴ１５２６）。
【０１３５】
ユーザ端末１１ｂは、抽選サーバ３からチケット情報を受信すると（Ｔ１５２７）、ディスプレイ等の出力装置２０４に出力し、チケット情報をユーザに提示する。これにより、ユーザは、抽選に応募するイベントを選択することができる。
【０１３６】
そして、ユーザ端末１１ｂは、ユーザによって選択されたイベントの情報（席種や座席番号等のチケットの情報を含まない。）、チケットの申込枚数、及び同伴者ｉｄを、抽選応募データとして抽選サーバ３に対して送信する（ＳＴ１５２８）。なお、抽選応募データには、チケットに関する情報を含めることも可能である。
【０１３７】
抽選サーバ３の抽選受付手段３０４は、ユーザ端末１１ｂから抽選応募データを受信すると（ＳＴ１５２９）、その情報を用いて応募情報ＤＢの記憶内容を更新する（ＳＴ１５３０）。
【０１３８】
抽選受付手段３０４は、イベントごとに予め設定された所定の応募期限が経過したかどうかを判断し（ＳＴ１５３１）、応募期限が経過するまでユーザからの抽選への応募を受け付ける。
【０１３９】
図１２は、抽選サーバ３による抽選応募者の分類処理、及び抽選サーバ３からの問い合わせに対するＦＣサーバ５の応答処理のフローチャートを示す。
【０１４０】
応募期限が経過すると（ＳＴ１５３１の判断がＹｅｓの場合）、抽選手段３０５は、抽選応募者のデータを応募情報ＤＢから抽出し（ＳＴ１５３２）、応募者ごとに１以上の所定の条件を満たすかどうかを応募順（応募情報ＤＢへの登録順）に判断し、応募者を優先度の異なる複数のグループに分類する（ＳＴ１５３３〜ＳＴ１５５７）。
【０１４１】
抽選手段３０５が適用する１以上の所定の条件としては、例えば以下の条件が採用され得る。
【０１４２】
（１）過去のチケットの購入回数が閾値以下（例えば、過去２年以内の購入回数が０回）であるという条件
この条件は、これまでイベントに参加したことのないユーザ又はイベントへの参加回数が少ないユーザを優先的に当選させることにより、イベントへの参加を希望するユーザに対して平等な参加機会を提供する趣旨の条件である。この条件は、購入履歴ＤＢの記憶内容に基づいて判断される。
【０１４３】
（２）チケットの転売回数が閾値以下（例えば、過去２年以内の転売回数が０回）であるという条件
この条件は、チケットの転売回数が少ないユーザを優良なユーザであると判断し、他のユーザよりも優先的に当選させるという趣旨の条件である。この条件は、購入履歴ＤＢの記憶内容に基づいて判断される。
【０１４４】
（３）抽選の応募者が応募対象イベントのアーティストのファンクラブ会員であるという条件
この条件は、抽選対象となるイベントのアーティストのファンクラブに会員登録しているユーザを、他のユーザよりも優先するという趣旨の条件である。なお、この条件は、例えば、イベントのアーティストのファンクラブや所属事務所から、ファンクラブ会員を優先して欲しいという意向があった場合に適用されるようにしてもよい。
【０１４５】
（４）抽選の応募者が注意会員ではないという条件
この条件は、システム管理者が、将来的に規約違反者になるおそれのあるユーザ（注意会員）よりも、その他の優良なユーザを優先させるという趣旨の条件である。
【０１４６】
（５）抽選の応募者が規約違反者ではないという条件
この条件は、規約違反者の当選確率を下げることにより、純粋なファンに対して高い確率で参加機会を提供するという趣旨の条件である。
【０１４７】
（６）抽選の応募者が年会費を支払っているという条件
システムの年会費を支払っていないユーザよりも、その他のユーザを優先するという趣旨の条件である。
【０１４８】
（７）抽選の応募者が、過去に、チケットを購入したが、イベント会場に来場しなかったという記録がないという条件
来場しないおそれのあるユーザよりも、その他のユーザを優先するという趣旨の条件である。
【０１４９】
なお、上記の条件は、全てを適用する必要はなく、少なくとも１つ以上適用されるように構成するのがよい。また、２つ以上の条件を適用する場合には、条件の適用順序を適宜変更することができる。
【０１５０】
まず、抽選手段３０５は、会員データＤＢを参照し、分類対象となるユーザが年会費を支払っているかどうかを判断し（ＳＴ１５３３）、支払っている場合（ＳＴ１５３３の判断がＹｅｓの場合）、すなわち会員データＤＢの会員ステータスの欄に１（支払有）が設定されている場合には、さらに会員データＤＢを参照し、規約違反者かどうかを判断する（ＳＴ１５３４）。
【０１５１】
分類対象のユーザが規約違反者ではない場合（ＳＴ１５３４の判断がＮｏの場合）、すなわち会員データＤＢのチェックフラグの欄に０（通常会員）又は１（注意会員）が設定されている場合には、抽選手段３０５は、来場履歴ＤＢ（図４（Ｄ））を参照し、過去に、チケットを購入したが、イベント会場に来場しなかったという記録があるかどうかを判断する（ＳＴ１５３５）。
【０１５２】
抽選手段３０５は、ＳＴ１５３３において分類対象のユーザが年会費を支払っていない場合（判断がＮｏの場合）、ＳＴ１５３４において分類対象のユーザが規約違反者の場合（判断がＹｅｓの場合）、又はＳＴ１５３５において分類対象のユーザに関して来場しなかったという記録がある場合（判断がＹｅｓの場合）には、分類対象のユーザを落選者として取り扱い、抽選結果を応募情報ＤＢに記録する（ＳＴ１５３６）。
【０１５３】
具体的には、応募情報ＤＢの当落ステータスの欄に０（落選）が設定される。
【０１５４】
一方、抽選手段３０５は、ＳＴ１５３５において分類対象のユーザに関して来場しなかったという記録がない場合（判断がＮｏの場合）には、会員データＤＢを参照し、分類対象のユーザが注意会員かどうかを判断する（ＳＴ１５３７）。具体的には、会員データＤＢのチェックフラグの欄に１（注意会員）が設定されているかどうかが判断される。
【０１５５】
上記判断の結果、分類対象のユーザが注意会員である場合（ＳＴ１５３７の判断がＹｅｓの場合）、抽選手段３０５は、応募情報ＤＢにおいて該当するレコードのグループの欄に７（優先度＝７）を設定することにより、当該ユーザを第７グループに分類する（ＳＴ１５３８）。なお、グループの欄には、分類後のグループの優先度を識別し得る情報であれば、任意の情報（例えば、aから始まるアルファベットを用いて優先度を識別するようにしてもよい）が格納され得る。
【０１５６】
一方、抽選手段３０５は、分類対象のユーザが注意会員ではない場合（ＳＴ１５３７の判断がＮｏの場合）、ＦＣサーバ５に備えられているＦＣ会員ＤＢにアクセスし、分類対象のユーザが抽選の対象イベントのアーティストのファンクラブ会員であるかどうかを検査する（ＳＴ１５３９）。具体的には、抽選手段３０５は、ＦＣサーバ５に対し、分類対象のユーザのユーザＩＤを、ＦＣ会員登録の問い合わせデータとして送信する。
【０１５７】
ＦＣサーバ５のＦＣ会員登録検査手段５０３は、抽選サーバ３からＦＣ会員登録の問い合わせデータを受信すると（ＳＴ１５４０）、ＦＣ会員ＤＢのユーザＩＤの欄を参照し、問い合わせデータに含まれるユーザＩＤが存在するかどうかを検査して（ＳＴ１５４１）、問い合わせ結果（ＦＣ会員登録の有無）を抽選サーバ３に対して送信する（ＳＴ１５４２）。
【０１５８】
抽選サーバ３の抽選手段３０５は、ＦＣサーバ５から問い合わせ結果を受信すると（ＳＴ１５４３）、分類対象のユーザが抽選対象のイベントのアーティストのファンクラブ会員（ＦＣ会員）かどうかを判断する（ＳＴ１５４４）。具体的には、ＦＣサーバ５から受信した問い合わせ結果が、ＦＣ会員登録されているという内容と、ＦＣ会員登録されていないという内容のどちらであるかが判断される。
【０１５９】
上記の判断の結果、分類対象のユーザがＦＣ会員である場合（ＳＴ１５４４の判断がＹｅｓの場合）、抽選手段３０５は、購入履歴ＤＢ（図５）を参照し、過去２年以内のチケットの購入回数が０回かどうかを判断する（ＳＴ１５４５）。具体的には、分類対象ユーザのユーザＩＤが、購入履歴ＤＢの２年以内のレコードのユーザＩＤの欄に存在しているかどうかが判断される。
【０１６０】
上記の判断の結果、過去２年以内のチケットの購入回数が１回以上の場合（ＳＴ１５４５の判断がＮｏの場合）、抽選手段３０５は、購入履歴ＤＢを参照し、過去２年以内のチケットの転売回数が０回かどうかを判断する（ＳＴ１５４６）。具体的には、分類対象ユーザのユーザＩＤが、購入履歴ＤＢの２年以内のレコードのユーザＩＤの欄に存在し、且つ、該当するレコードのステータスの欄に３（転売済）が設定されているかどうかが判断される。
【０１６１】
抽選手段３０５は、過去２年以内の購入回数が０回の場合（ＳＴ１５４５の判断がＹｅｓの場合）、又は過去２年以内の転売回数が０回の場合（ＳＴ１５４６の判断がＹｅｓの場合）には、応募情報ＤＢのグループの欄に１（優先度＝１）を設定することにより、分類対象のユーザを第１グループに分類する（ＳＴ１５４７）。
【０１６２】
一方、過去２年以内の転売回数が１回以上の場合（ＳＴ１５４６の判断がＮｏの場合）には、抽選手段３０５は、応募情報ＤＢのグループの欄に２（優先度＝２）を設定することにより、分類対象のユーザを第２グループに分類する（ＳＴ１５４８）。
【０１６３】
また、抽選手段３０５は、ＳＴ１５４４の判断において、分類対象のユーザがＦＣ会員ではない場合（判断がＮｏの場合）には、購入履歴ＤＢを参照し、過去２年以内のチケットの購入回数が０回かどうかを判断する（ＳＴ１５４９）。判断方法は、ＳＴ１５４５と同様である。
【０１６４】
上記の判断の結果、過去２年以内の購入回数が０回の場合（ＳＴ１５４９の判断がＹｅｓの場合）には、抽選手段３０５は、購入履歴ＤＢを参照し、過去２年以内のチケットの転売回数が０回かどうかを判断する（ＳＴ１５５０）。判断方法は、ＳＴ１５４６と同様である。
【０１６５】
抽選手段３０５は、過去２年以内の転売回数が０回の場合（ＳＴ１５５０の判断がＹｅｓの場合）には、応募情報ＤＢのグループの欄に３（優先度＝３）を設定することにより、分類対象のユーザを第３グループに分類する（ＳＴ１５５１）。
【０１６６】
一方、過去２年以内の転売回数が１回以上の場合（ＳＴ１５５０の判断がＮｏの場合）には、抽選手段３０５は、応募情報ＤＢのグループの欄に４（優先度＝３）を設定することにより、分類対象のユーザを第４グループに分類する（ＳＴ１５５２）。
【０１６７】
また、抽選手段３０５は、ＳＴ１５４９の判断において、過去２年以内の購入回数が１回以上の場合（判断がＮｏの場合）には、購入履歴ＤＢを参照し、過去２年以内のチケットの転売回数が０回かどうかを判断する（ＳＴ１５５３）。判断方法は、ＳＴ１５４６と同様である。
【０１６８】
上記の判断の結果、過去２年以内の転売回数が０回の場合（ＳＴ１５５３の判断がＹｅｓの場合）には、応募情報ＤＢのグループの欄に５（優先度＝５）を設定することにより、分類対象のユーザを第５グループに分類する（ＳＴ１５５４）。
【０１６９】
一方、過去２年以内の転売回数が１回以上の場合（ＳＴ１５５３の判断がＮｏの場合）には、抽選手段３０５は、応募情報ＤＢのグループの欄に６（優先度＝６）を設定することにより、分類対象のユーザを第６グループに分類する（ＳＴ１５５５）。
【０１７０】
以上のように、抽選手段３０５は、分類対象のユーザを、第１〜第７のグループのいずれかに分類すると、応募者全員を分類したかどうかを判断し（ＳＴ１５５６）、分類が完了していない場合（判断がＮｏの場合）には、次の応募者を分類対象として選択し（ＳＴ１５５７）、ＳＴ１５３３に戻る。
【０１７１】
図１３（Ａ）は、抽選サーバ３による抽選処理、及びチケット販売会社サーバ１３による当選者情報の格納処理のフローチャートを示す。
【０１７２】
抽選手段３０５は、抽選への応募者全員の分類が完了した場合（ＳＴ１５５６の判断がＹｅｓの場合）には、各グループごとに当選枠（Ｎm）を設定する（ＳＴ１５５８）。当選枠は、購入履歴ＤＢに格納されている抽選対象イベントのチケットの総数を、各グループに均等配分することにより設定されてもよいし、各グループごとに予め定義されたチケット総数に占める当選枠の比率に基づいて設定されてもよいし、システム管理者によって手作業で任意に設定されてもよい。本実施例では、当選枠は、チケットの総数を各グループに均等配分することにより設定されるものとする。従って、例えば、チケットの総数が７，０００枚の場合には、各グループの当選枠Ｎmは１，０００枚に設定される。
【０１７３】
次に、抽選手段３０５は、応募情報ＤＢを参照し、第ｍグループの応募者データを抽出する（ＳＴ１５５９）。本実施例では、優先度の高いグループ（ｍ＝１のグループ）から順に抽出されるものとする。
【０１７４】
応募者データを抽出すると、抽選手段３０５は、申込枚数の合計が当選枠を超えているかどうかを判断する（ＳＴ１５６０）。なお、同伴者のチケットも併せて応募しているユーザが存在する場合には、応募者のレコード数よりも申込枚数の合計が大きくなる。
【０１７５】
上記の判断の結果、当選枠を超えていない場合（ＳＴ１５６０の判断がＮｏの場合）には、抽選手段３０５は、抽選対象となる応募者全員を当選者とす（ＳＴ１５６１）。
【０１７６】
なお、この場合には、当選枠の余剰分（当選枠Ｎm−申込数の合計）が生じていると思われるため、その余剰分が、抽選手段３０５によって次の優先度のグループの当選枠Ｎm+1に加算されるように構成するのがよい。
【０１７７】
一方、申込数の合計が当選枠を超えている場合（ＳＴ１５６０の判断がＹｅｓの場合）には、抽選手段３０５は、抽選を行い、当選枠Ｎmと同数の当選者を決定する（ＳＴ１５６２）。
【０１７８】
抽選を行った後、抽選手段３０５は、ｍ＝７かどうか、すなわち抽選対象のグループが最終グループかどうかを判断する（ＳＴ１５６３）。
【０１７９】
上記の判断の結果、抽選対象のグループが最終グループではない場合（ＳＴ１５６３の判断がＮｏの場合）には、抽選手段３０５は、ＳＴ１５６２の抽選により生じた落選者を、第ｍ＋１のグループに追加する（ＳＴ１５６４）。
【０１８０】
具体的には、抽選手段３０５は、応募情報ＤＢの記憶内容のうち、ＳＴ１５６２の抽選により生じた落選者に関するレコードのグループの欄に、次の優先度のグループを表す情報（ｍ＋１）を記録する。
【０１８１】
一方、ＳＴ１５６１の後、ＳＴ１５６４の後、又は抽選対象のグループが最終グループである場合（ＳＴ１５６３の判断がＹｅｓの場合）には、抽選手段３０５は、抽選結果を応募情報ＤＢに記録する（ＳＴ１５６５）。なお、抽選対象のグループが最終グループである場合、落選者は、次の優先度のグループに追加されないため、落選が確定することになる。
【０１８２】
ＳＴ１５６５の際には、抽選手段３０５は、応募情報ＤＢの記憶内容のうち、当選者についてはステータスの値を１に設定し、落選が確定した応募者についていはステータスの値を０に設定する。
【０１８３】
次に、抽選手段３０５は、ｍの値をインクリメント（ｍ＝ｍ＋１）し（ＳＴ１５６６）、ｍ＝８かどうか、すなわち最終グループの抽選が終了したかどうかを判断する（ＳＴ１５６７）。
【０１８４】
上記の判断の結果、最終グループの抽選が終了していない場合（ＳＴ１５６７の判断がＮｏの場合）には、次の優先度のグループを対象として抽選処理ＳＴ１５５９〜ＳＴ１５６７が実行される。
【０１８５】
このように、抽選を行ったグループから生じた落選者を、次の優先度のグループへ追加したうえで、当該次の優先度のグループの抽選を行うことにより、予め優先度の高いグループに分類されたユーザは、一度落選しても、抽選機会が再度与えられるため、他のユーザに比べて当選確率が高くなる。
【０１８６】
一方、最終グループの抽選が終了した場合（ＳＴ１５６７の判断がＹｅｓの場合）には、抽選手段３０５は、応募者の操作する各ユーザ端末に対して抽選結果を通知する（ＳＴ１５６８）。
【０１８７】
各応募者の操作するユーザ端末１１ａ〜１１ｃは、抽選サーバ３から抽選結果を受領し（ＳＴ１５６９）、ディスプレイ等の出力装置２０４を介して各応募者に抽選結果を提示する。
【０１８８】
抽選サーバ３では、抽選手段３０５は、応募情報ＤＢの当落ステータスを参照し、当選者情報を抽出し（ＳＴ１５７０）、チケット販売会社サーバ７に対して送信する（ＳＴ１５７１）。当選者情報には、ユーザＩＤ、公演コード、公演日、申込日、申込枚数、及び同伴者ｉｄが含まれる。
【０１８９】
チケット販売会社サーバ７の当選者情報更新手段７０２は、抽選サーバ３から当選者情報を受信すると（ＳＴ１５７２）、その情報を用いて当選者情報ＤＢ（図８（Ｂ））の記憶内容を更新する（ＳＴ１５７３）。
【０１９０】
具体的には、当選者ごとに、当選者情報及び入金ステータスの値（０）が当選者情報ＤＢに記録される。
【０１９１】
図１３（Ｂ）は、チケット販売会社サーバ７による購入者情報の送信処理、及び抽選サーバ３によるチケット情報の送信処理のフローチャートを示す。
【０１９２】
当選したユーザは、例えば、ユーザ端末（例えば、１１ｃ）を操作し、チケット販売会社に対してチケット購入代金の入金処理を行うことができる（ＳＴ１５７４）。具体的には、ユーザは、チケット販売会社サーバ７が指定する所定のＵＲＬにアクセスし、クレジットカード番号を入力することにより、或いはそのＵＲＬにアクセスした場合に表示される納付書と現金をコンビニ等の収納代理店へ持参することにより、チケット購入代金を支払うことができる。
【０１９３】
チケット販売会社サーバ７の当選者情報更新手段７０２は、購入代金の入金情報を受領すると（ＳＴ１５７５）、当選者情報ＤＢの記憶内容を更新する（ＳＴ１５７６）。
【０１９４】
具体的には、該当する当選者に関するレコードの入金の欄に１が設定される。なお、購入代金の入金情報は、入金されたことを表す情報であり、例えば、クレジット決済の場合は、クレジット会社のシステムから送信される態様が考えられる。また、銀行振り込みの場合は、チケット販売会社サーバ７の管理者によって手作業で入力される態様や銀行のシステムから送信される態様が考えられる。
【０１９５】
当選者情報更新手段７０２は、予め設定されたチケット購入代金の支払期限が経過したかどうかを判断し（ＳＴ１５７７）、期限が切れていない場合（判断がＮｏの場合）には、上記の処理ＳＴ１５７５〜ＳＴ１５７７を繰り返す。
【０１９６】
一方、期限が切れた場合（ＳＴ１５７７の判断がＹｅｓの場合）、当選者情報ＤＢから購入者情報を抽出し（ＳＴ１５７８）、抽選サーバ３に対して送信する（ＳＴ１５７９）。なお、購入者情報は、例えば、当選者情報ＤＢに記録されている当選者のうち、チケット購入代金の支払いが確認された当選者に関するユーザＩＤである。
【０１９７】
抽選サーバ３の購入者情報記録手段３０６は、チケット販売会社サーバ７から購入者情報を受信すると（ＳＴ１５８０）、その情報（ユーザＩＤ）に基づき、応募情報ＤＢから該当するユーザが購入したチケットの情報を抽出し、購入履歴ＤＢの記憶内容を更新する（ＳＴ１５８１）。
【０１９８】
具体的には、当選者本人については、チケット販売会社サーバ７から受信したユーザＩＤに基づき、応募情報ＤＢに記録されている当選（購入）したチケットに関するレコードを参照することにより、購入履歴ＤＢにおいて該当するレコードのユーザＩＤ、申込日、申込枚数、申込種別、及びステータスの情報が更新される。
【０１９９】
また、同伴者については、チケット販売会社サーバ７から受信したユーザＩＤに基づき、応募情報ＤＢに記録されている当選（購入）したチケットに関するレコード及び該レコードの同伴者ｉｄの値を参照することにより、購入履歴ＤＢにおいて該当するレコードのユーザＩＤ、申込日、申込枚数、申込種別、及びステータスの情報が更新される。
【０２００】
さらに、イベントが指定席で構成されている場合には、購入者情報記録手段３０６は、購入履歴ＤＢを更新する際に、購入者ごとに席種及び座席番号を割り当てるようにしてもよい。具体的には、例えば、応募情報ＤＢのグループの欄の値が小さい（優先度が高い）ユーザには良い席（例えば、中央寄りの席やステージに近い席）が割り当てられるようにすることができる。
【０２０１】
そして、購入者情報記録手段３０６は、各購入者の操作するユーザ端末に対し、チケット情報を送信し（ＳＴ１５８２）、各ユーザ端末は抽選サーバ３から受信したチケット情報をユーザに対して提示する（ＳＴ１５８３）。チケット情報には、公演コード、公演日、チケット枚数、席種、及び座席番号が含まれる。
【０２０２】
図１４（Ａ）は、抽選サーバ３による転売依頼受付処理のフローチャートを示す。
【０２０３】
まず、チケットを購入したユーザのうち、転売を希望するユーザ（転売依頼者）は、ユーザ端末（例えば、１１ａ）を操作し、抽選サーバ３に対し、転売依頼データを送信する（ＳＴ１５８４）。
【０２０４】
転売依頼データには、例えば、ユーザＩＤ、公演コード、及び転売希望枚数が含まれる。なお、本実施例では、抽選への応募者本人は、同伴者のチケットも転売できるものとし、同伴者は、自分のチケット（１枚）のみ転売できるものとする。転売依頼者が抽選への応募者本人と同伴者のどちらに該当するかについては、購入履歴ＤＢの申込種別の欄の値を参照することで確認することができる。
【０２０５】
抽選サーバ３の転売手段３０７は、ユーザ端末１１ａから転売依頼データを受信すると（ＳＴ１５８５）、会員データＤＢを参照し、転売依頼者が規約違反者かどうかを判断し（ＳＴ１５８６）、購入履歴ＤＢの記憶内容を更新する（ＳＴ１５８９）。
【０２０６】
具体的には、ＳＴ１５８６の結果、転売依頼者が規約違反者ではない場合、転売手段３０７は、転売対象となるチケットの転売依頼を受付け、購入履歴ＤＢの記憶内容のうち、転売の対象となるチケットに関するステータスの欄の値が２（転売中）に変更される。
【０２０７】
一方、転売依頼者が規約違反者である場合、購入履歴ＤＢの記憶内容のうち、転売の対象となるチケットに関する申込種別の欄の値が５（無効設定者）に変更され、ステータスの欄の値が０（無効）に変更され、転売対象となるチケットが無効とされる。なお、この場合には、抽選の当選者本人と同伴者のすべてのチケットが無効になるように購入履歴ＤＢの記憶内容を更新するのがよい。
【０２０８】
そして、転売手段３０７は、依頼結果をユーザ端末１１ａに送信する（ＳＴ１５８８）。
【０２０９】
依頼結果としては、転売依頼者が規約違反者ではない場合には、転売依頼を受け付けたことを表す情報を送信することが考えられる。一方、転売依頼者が規約違反者の場合には、転売依頼が受け付けられなかったことを表す情報、及びチケットが無効になったことを表す情報を送信することが考えられる。
【０２１０】
また、チケットごとの転売回数を制限することも可能である。例えば、チケットごとの転売回数を１回に制限する場合、転売によりチケットを購入したユーザは、そのチケットを転売することができないということになる。具体的な処理としては、例えば、転売手段３０７は、ＳＴ１５８５で転売依頼データを受信した後、購入履歴ＤＢを参照し、申込種別の欄の値が４（転売購入者）に設定されている場合には、チケットの転売ができないことを表す依頼結果をユーザ端末に送信することが考えられる。
【０２１１】
ユーザ端末１１ａは、抽選サーバ３から依頼結果を受信し（ＳＴ１５８９）、ディスプレイ等の出力装置２０４を介してユーザに依頼結果を提示する。
【０２１２】
以上のように、転売手段３０７がＳＴ１５８４〜ＳＴ１５８９の処理を繰り返すことにより、転売対象となるチケットの情報が購入履歴ＤＢに蓄積される。
【０２１３】
図１４（Ｂ）は、本システム１における転売処理のフローチャートを示す。
【０２１４】
転売対象となるチケットの購入を希望するユーザ（購入依頼者）は、ユーザ端末（例えば、１１ｂ）を操作し、抽選サーバ３に対して転売情報の提示要求を送信する（ＳＴ１５９０）。
【０２１５】
転売情報の提示要求としては、例えば、転売対象となる全てのチケットの情報の提示を要求する情報、転売対象となるチケットの情報のうち特定のアーティストに関する情報の提示を要求する情報、転売対象となるチケットの情報のうち特定の日に開催されるイベントの情報の提示を要求する情報、又は転売対象となるチケットの情報のうち特定の価格帯に属する情報の提示を要求する情報などが考えられる。
【０２１６】
抽選サーバ３の転売手段３０７は、転売情報の提示要求を受信すると（ＳＴ１５９１）、購入履歴ＤＢを参照し、該当する転売情報を抽出して（ＳＴ１５９２）、ユーザ端末１１ｂへ送信する（ＳＴ１５９３）。
【０２１７】
転売情報には、例えば、公演コード、公演日、チケットの枚数、席種、座席番号、及び価格が含まれる。なお、本実施例では、転売対象となるチケットの価格は、購入履歴ＤＢの価格の欄に設定されている値（固定値）であるものとする。これにより、チケットが高額で売買されるのを防止することができる。
【０２１８】
ユーザ端末１１ｂは、抽選サーバ３から転売情報を受信すると（ＳＴ１５９４）、ディスプレイ等の出力装置２０４を介してユーザに転売情報を提示する。これにより、ユーザは、転売により購入できるチケットの情報を把握し、購入するチケットを選択することができる。
【０２１９】
次に、転売情報から購入するチケットを選択したユーザは、ユーザ端末１１ｂを操作し、抽選サーバ３に対して購入依頼データを送信する（ＳＴ１５９５）。
【０２２０】
購入依頼データには、例えば、購入依頼者のユーザＩＤ、公演コード、購入枚数（本実施例では１枚に限定する）、席種、及び座席番号が含まれる。
【０２２１】
抽選サーバ３の転売手段３０７は、購入依頼データを受信すると（ＳＴ１５９６）、購入履歴ＤＢを参照し、購入依頼者がチケット保有者かどうかを判断する（ＳＴ１５９７）。
【０２２２】
具体的には、購入依頼者が同じイベントのチケットを重複して保有することとならないように、購入依頼者のユーザＩＤが、購入履歴ＤＢにおいて、転売対象となるイベントの公演コードに対応するレコードに含まれているかどうかが判断される。
【０２２３】
上記の判断の結果、購入依頼者がチケット保有者ではない場合（ＳＴ１５９７の判断がＮｏの場合）には、転売手段３０７は、会員データＤＢを参照し、購入依頼者が規約違反者かどうかを判断する（ＳＴ１５９８）。
【０２２４】
上記の判断の結果、購入依頼者が規約違反者ではない場合（ＳＴ１５９８の判断がＮｏの場合）には、転売手段３０７は、チケットの転売が成立したと判断し、購入履歴ＤＢの記憶内容を更新する（ＳＴ１５９９）。
【０２２５】
具体的には、転売手段３０７は、購入履歴ＤＢに対し、転売依頼者については、チケットを転売したことを表す情報として、申込種別の欄の値を３（転売者）に変更し、且つステータスの欄の値を３（転売済）に変更する。また、購入依頼者については、レコードを新たに作成し、チケットの購入者として、ユーザＩＤ、当該チケットに対応する公演コード、公演日、申込日（購入依頼日）、申込枚数（１枚）、申込種別（４（転売購入者））、ステータス（１（有効））、席種、座席番号、及び価格を対応付けて記録する。
【０２２６】
そして、転売手段３０７は、ＳＴ１５９９で購入履歴ＤＢの記憶内容を更新した場合、ＳＴ１５９７の判断で購入依頼者がチケット保有者であると判断された場合（判断がＹｅｓの場合）、又はＳＴ１５９８の判断で購入依頼者が規約違反者であると判断された場合（判断がＹｅｓの場合）には、依頼結果をユーザ端末１１ｂに対して送信する（ＳＴ１６００）。
【０２２７】
依頼結果としては、ＳＴ１５９９において転売が成立したものと判断された場合には、購入したチケットに関する情報（公演コード、公演日、枚数、席種、座席番号、及び価格など）とチケット代金の支払い方法に関する情報を送信することが考えられる。一方、チケットの転売が成立しなかった場合、すなわちＳＴ１５９７又はＳＴ１６９８の判断結果がＹｅｓの場合には、転売が不成立だったことを表す情報を送信することが考えられる。
【０２２８】
ユーザ端末１１ｂは、抽選サーバ３から依頼結果を受信すると（ＳＴ１６０１）、ディスプレイ等の出力装置２０４を介して依頼結果をユーザに対して提示する。ユーザは、依頼結果の内容として、購入したチケットに関する情報とチケット代金の支払い方法に関する情報を見て、転売依頼者に対してチケット代金を支払うものとする。また、抽選サーバ３は、会員データＤＢで管理しているユーザごとのクレジット番号に基づき、転売依頼者の代わりにチケット購入代金を収納することも可能である。この場合、ユーザごとに口座を会員データＤＢで管理しておき、代わりに収納したチケット購入代金を、その口座へ入金することにより、転売依頼者へ代金を渡すようにすればよい。
【０２２９】
また、抽選サーバ３の転売手段３０７は、イベントごとに予め設定された転売期限が経過したかどうかを判断し（ＳＴ１６０２）、期限切れになるまで、ユーザからの要求に応じて転売処理（ＳＴ１５９６〜ＳＴ１５９９）を繰り返す。
【０２３０】
予め設定された転売期限が経過した場合（ＳＴ１６０２の判断がＹｅｓの場合）には、確定情報送信手段３０８は、会員データＤＢ及び購入履歴ＤＢを参照し、チケットを転売していない購入者（購入確定者）のユーザＩＤ、当該チケットに対応するイベントの公演コード、公演日、席種、座席番号、住所、及び氏名を抽出し（ＳＴ１６０３）、イベント参加者に関する購入者確定情報としてチケット販売会社サーバ７へ送信する（ＳＴ１６０４）。
【０２３１】
また、確定情報送信手段３０８は、さらに、上記購入者確定情報を用いて、来場履歴ＤＢの記憶内容を更新する（ＳＴ１６０５）。
【０２３２】
具体的には、来場履歴ＤＢには、購入確定者ごとにレコードが作成され、ユーザＩＤ、公演コード、公演日、及びステータス（０）が記録される。
【０２３３】
チケット販売会社サーバ７の確定情報ＤＢ更新手段７０３は、抽選サーバ３から購入者確定情報を受信すると（ＳＴ１６０６）、受信した情報を用いて確定情報ＤＢの記憶内容を更新し（ＳＴ１６０７）、所定のタイミングで購入確定者に対してチケットを発行（例えば、印刷）する（ＳＴ１６０８）。
【０２３４】
本実施例では、チケットには、例えば、公演コード、公演日、席種、座席番号、及び購入確定者の氏名が印字されるものとする。或いは、これらの情報を表すバーコードやＱＲコード等の二次元コードを印刷してもよい。そして、チケットは、チケット販売会社サーバ７の管理者によって購入確定者宛てに送付（郵送や電子メールで送信）される。
【０２３５】
図１５（Ａ）は、会場端末９による購入者確定情報の格納処理、及び会場端末９からの要求に対する抽選サーバ３による応答処理のフローチャートを示す。
【０２３６】
まず、イベント会場に設置された会場端末９の確定情報要求手段９０１は、所定のタイミング（例えば、開場の１日前や１時間前などのタイミング）で抽選サーバ３に対し、購入者確定情報の提示要求を送信する（ＳＴ１６０９）。
【０２３７】
抽選サーバ３の確定情報送信手段３０８は、会場端末９から購入者確定情報の提示要求を受信すると（ＳＴ１６１０）、会員データＤＢ及び購入履歴ＤＢを参照し、該当する購入者確定情報を抽出して（ＳＴ１６１１）、来場者を認証するための情報として会場端末９へ送信する（ＳＴ１６１２）。
【０２３８】
購入者確定情報は、前述のとおり、購入確定者のユーザＩＤ、公演コード、公演日、席種、座席番号、住所、及び氏名を含む情報である。
【０２３９】
会場端末９は、抽選サーバ３から購入者確定情報を受信すると（ＳＴ１６１３）、認証情報ＤＢに購入者確定情報を格納する（ＳＴ１６１４）。
【０２４０】
図１５（Ｂ）は、会場端末９による認証情報の受付処理、及び抽選サーバ３による来場履歴ＤＢの更新処理のフローチャートを示す。
【０２４１】
以下、イベント当時における、イベント会場で行われる来場者の認証処理について説明する。
【０２４２】
まず、来場者は、予め発行されたＩＣカードとチケットをイベントスタッフに提示すると、イベントスタッフは、会場端末９に備えられたＩＣカードリーダを操作して、ＩＣカードに記憶されている顔写真データ及びユーザＩＤを読み取る。
【０２４３】
これにより、会場端末９のＩＣデータ取得手段９０２は、ＩＣカードリーダが読み出した顔写真データ及びユーザＩＤを取得し（ＳＴ１６１５）、認証情報ＤＢを参照して、購入者確定情報のうち、ＩＣカードリーダが読み出したユーザＩＤに対応する情報を抽出する（ＳＴ１６１６）。
【０２４４】
そして、ＩＣデータ取得手段９０２は、顔写真データと、認証情報ＤＢから抽出した情報とをディスプレイ（出力装置２０４）に表示する（ＳＴ１６１７）。なお、ＳＴ１６１６において、ユーザＩＤに対応する購入者確定情報が見つからなかった場合には、ＩＣデータ取得手段９０２は、該当する購入確定者が存在しないことを表す情報を表示することが考えられる。
【０２４５】
イベントスタッフは、ディスプレイに表示された内容と、チケットの内容及び来場者の顔とを見比べて、来場者と購入確定者が同一人物かどうかを判断し、キーボード及びマウス等の入力装置２０３を操作して、認証結果を入力する。
【０２４６】
具体的には、ディスプレイに表示された顔写真と来場者の顔が一致するかどうか、ディスプレイに表示された公演コード、席種、座席番号、住所、及び氏名等の情報とチケットに表示されている情報が一致するかどうかがチェックされる。
【０２４７】
会場端末９の認証結果受付手段９０３は、イベントスタッフによって入力された認証結果を受け付け（ＳＴ１６１８）、認証ＯＫかどうか、すなわちイベントスタッフによって、来場者と購入確定者が同一であるという認証結果が入力されたかどうかを判断する（ＳＴ１６１９）。
【０２４８】
上記の判断の結果、認証ＯＫの場合（ＳＴ１６１９の判断がＹｅｓの場合）には、認証結果受付手段９０３は、抽選サーバ３に対し、来場者のユーザＩＤと公演コードとともに、来場履歴ＤＢ（図７）の更新要求を送信する（ＳＴ１６２０）。
【０２４９】
ＳＴ１６２０の後、又はＳＴ１６１９で認証ＮＧの場合（判断がＮｏの場合）には、認証結果受付手段９０３は、認証結果をディスプレイに表示する（ＳＴ１６２１）。
【０２５０】
例えば、認証ＯＫの場合には、その旨を表す情報を表示し、認証ＮＧの場合には、その旨及び入場させてはいけない旨を表す情報を表示することが考えられる。イベントスタッフは、ディスプレイに認証ＯＫの旨を表す情報が表示されたことを確認し、その来場者の入場を促すものとする。
【０２５１】
一方、抽選サーバ３の来場履歴更新手段３０９は、会場端末９から、ユーザＩＤ、公演コードとともに、来場履歴ＤＢの更新要求を受信すると（ＳＴ１６２２）、来場履歴ＤＢの記憶内容を更新する（ＳＴ１６２３）。
【０２５２】
具体的には、来場履歴ＤＢの記憶内容のうち、受信したユーザＩＤ及び公演コードに対応するレコードのステータスの欄の値が１（入場済み）に変更される。
【０２５３】
以上、本発明の実施例形態を説明したが、本発明は上述の実施例に限定されるものではなく、発明の要旨の範囲内で数々の変形が可能である。
［変形例］
以下、本発明の変形例を説明する。
【０２５４】
例えば、実施例では、イベントの例としてコンサートを挙げているが、一般にチケット（電子チケットを含む）の有無で参加の可否が決定する、野球やサッカー等のスポーツイベント、演劇やミュージカル等のステージイベント、自動車レースやテレビ局における公開収録や映画等のその他イベントなど、各種のイベントが対象となり得る。
【０２５５】
実施例では、抽選手段３０５が抽選処理の際に用いる１以上の条件として、抽選の応募者が応募対象イベントのアーティストのファンクラブ会員であるという条件を採用しているが、そのアーティストのファンクラブがパソコン用のホームページと携帯電話機用のホームページをそれぞれ開設している場合には、両方のホームページにおいてＦＣ会員登録を行っているという条件を採用してもよい。アーティストへの愛着がより強いファンを優先するという趣旨である。
【０２５６】
ＤＢは、抽選サーバ３、ＦＣサーバ５、チケット販売会社サーバ７、会場端末９のいずれかの装置に適宜備えられているが、それぞれの装置と通信可能に接続されたネットワーク上に又は他の装置に備えられる構成（例えば、会員データＤＢが、抽選サーバ３と通信可能に接続されたネットワーク上に或いはＦＣサーバなどに備えられている構成）であってもよい。
【０２５７】
抽選サーバ３、ＦＣサーバ５、チケット販売会社サーバ７、及び会場端末９には、各装置の用途に応じた機能的手段がそれぞれ備えられているが、各装置に備えられている機能的手段は、そのいくつかの手段を一纏めにして構成されていてもよいし、一つの手段をさらに複数の手段に分割して構成されていてもよい。
【０２５８】
抽選サーバ３、ＦＣサーバ５、及びチケット販売会社サーバ７は、実施例では別々に存在するが、二つ又は全部を一纏めにして構成されてもよい。その場合、例えば、ＦＣサーバ５の機能及びチケット販売会社サーバ７の機能を抽選サーバ３に包含させればよい。
【０２５９】
実施例では、転売対象となるチケットの購入を希望するユーザは、原則としてチケットを１枚のみ購入できるものとしたが、購入依頼データとして、同伴者ｉｄも送信する構成を採用し、ＳＴ１５９７及びＳＴ１５９８の処理において、購入依頼者及び同伴者の両者に関して判断を行うようにすれば、複数のチケットを転売で購入できる態様も可能となる。この場合には、購入履歴ＤＢ及び確定者情報ＤＢには、購入依頼者及び同伴者の両者に関するレコードが作成されるようにするのがよい。
【０２６０】
抽選サーバ３による抽選応募者の分類処理において、抽選手段３０５は、分類対象のユーザが、年会費を支払っていない場合（ＳＴ１５３３の判断がＮｏの場合）、規約違反者の場合（ＳＴ１５３４の判断がＹｅｓの場合）、過去に来場しなかったという経緯がある場合（ＳＴ１５３５の判断がＹｅｓの場合）には、当該ユーザを落選者として扱っている（ＳＴ１５３６）が、これらのユーザを例えば第８のグループに分類し、第７グループの次の抽選を行うようにしてもよい。
【図面の簡単な説明】
【０２６１】
【図１】実施例の抽選サーバを用いて構成したチケット取引システムの構成を示す図。
【図２】抽選サーバ、ＦＣサーバ、チケット販売会社サーバ、会場端末、及びユーザ端末のハードウェア構成を示す図。
【図３】抽選サーバの構成を示すブロック図。
【図４】（Ａ）は、抽選サーバに備えられている会員データＤＢのデータ構造を示す図、（Ｂ）は、抽選サーバに備えられている購入履歴ＤＢのデータ構造を示す図、（Ｃ）は、抽選サーバに備えられている応募情報ＤＢのデータ構造を示す図、（Ｄ）は、抽選サーバに備えられている来場履歴ＤＢのデータ構造を示す図。
【図５】ＦＣサーバの構成を示すブロック図。
【図６】ＦＣサーバに備えられているＦＣ会員ＤＢのデータ構造を示す図。
【図７】チケット販売会社サーバの構成を示すブロック図。
【図８】（Ａ）は、チケット販売会社サーバに備えられているチケットマスタＤＢのデータ構造を示す図、（Ｂ）は、チケット販売会社サーバに備えられている当選者情報ＤＢのデータ構造を示す図、（Ｃ）は、チケット販売会社サーバに備えられている確定情報ＤＢのデータ構造を示す図。
【図９】会場端末９の構成を示すブロック図。
【図１０】（Ａ）は、ＦＣサーバにおけるＦＣ会員登録処理、及びＦＣサーバからの問い合わせに対する抽選サーバの応答処理のフローチャート、（Ｂ）は、抽選サーバによる会員登録処理のフローチャート。
【図１１】（Ａ）は、抽選サーバによるチケット情報の格納処理のフローチャート、（Ｂ）は、抽選サーバによる抽選の応募者データの格納処理のフローチャート。
【図１２】抽選サーバによる抽選応募者の分類処理、及び抽選サーバからの問い合わせに対するＦＣサーバの応答処理のフローチャート。
【図１３】（Ａ）は、抽選サーバによる抽選処理、及びチケット販売会社サーバによる当選者情報の格納処理のフローチャート、（Ｂ）は、チケット販売会社サーバによる購入者情報の送信処理、及び抽選サーバによるチケット情報の送信処理のフローチャート。
【図１４】（Ａ）は、抽選サーバによる転売依頼受付処理のフローチャート、（Ｂ）は、本システムにおける転売処理のフローチャート。
【図１５】（Ａ）は、会場端末による購入者確定情報の格納処理、及び会場端末からの要求に対する抽選サーバによる応答処理のフローチャート、（Ｂ）は、会場端末による認証情報の受付処理、及び抽選サーバによる来場履歴ＤＢの更新処理のフローチャート。
【符号の説明】
【０２６２】
１      チケット取引システム
３      抽選サーバ
３０１  ユーザ登録手段
３０２  チケット情報受付手段
３０３  イベント情報提示手段
３０４  抽選受付手段
３０５  抽選手段
３０６  購入者情報記録手段
３０７  転売手段
３０８  確定情報送信手段
３０９  来場履歴更新手段
５      ＦＣサーバ
５０１  ＦＣ会員登録手段
５０２  ＩＤ問合せ手段
５０３  ＦＣ会員登録検査手段
７      チケット販売会社サーバ
７０１  チケット情報送信手段
７０２  当選者情報更新手段
７０３  確定情報ＤＢ更新手段
７０４  チケット発行手段
９      会場端末
９０１  確定情報要求手段
９０２  ＩＣデータ取得手段
９０３  認証結果受付手段
１１ａ，１１ｂ，１１ｃ  ユーザ端末
【図１】
0005192918.tif 000002
【図２】
0005192918.tif 000003
【図３】
0005192918.tif 000004
【図４】
0005192918.tif 000005
【図５】
0005192918.tif 000006
【図６】
0005192918.tif 000007
【図７】
0005192918.tif 000008
【図８】
0005192918.tif 000009
【図９】
0005192918.tif 000010
【図１０】
0005192918.tif 000011
【図１１】
0005192918.tif 000012
【図１２】
0005192918.tif 000013
【図１３】
0005192918.tif 000014
【図１４】
0005192918.tif 000015
【図１５】
0005192918.tif 000016