JP2005084867A - チケット割当システムとそれを実現するためのコンピュータプログラムとその方法 - Google Patents

Abstract

【目的】コンサート等のチケット購入者がこだわりの座席ゾーン、好みの座席ゾーンを指定することを可能にするシステム等を提供する。
【解決手段】興行会場の複数の座席領域（ゾーン）を記憶する記憶装置とチケットの管理を行うサーバー１とからなる。サーバー１は興行チケット購入のための申請データをＰＣ２から受付ける。申請データには購入者と購入者が希望する前記座席領域を特定する希望領域とが含まれる。サーバー１は申請データに含まれる希望領域に購入者をチケット権利者として割当てる。また、サーバー１は、座席領域を変更する変更申請データを受付け、それに基づいて希望領域の変更も行い、座席の割当を行う。
【選択図】図２

Description

本発明は、電子チケットの販売に関するシステム等に関するものである。

現在、コンサートやスポーツなどの興行は各所で数多く催されている。これら興行のチケットの販売は一般的にチケット販売会社が購入希望者から直接電話を受付てチケットを販売している。また、最近ではインターネットを利用して電子チケットを販売するケースも増えている。
チケット販売会社は電話やインターネットでチケット申込を受付けると、購入者に所定の座席を割当ててチケットを販売している。
また、チケット販売会社は人気が高いコンサートなどにおいてチケットの申込が定員をオーバーした場合は抽選を行い、当選者にのみチケットを販売している。

特願平１１−３１０７２２

しかし、これまでの方法では、どの座席に誰を割当てるかは興行主催者側が一方的に決めているため、購入者の様々な「こだわり」を満足させることが出来なかった。即ち、チケット購入者には各々こだわりの座席や座席ゾーン（ステージに近い位置を希望する人、これとは逆にステージから離れた位置を希望する人、通路沿いの席を希望する人、二階席の最前列を希望する人などのこだわり）をもっており、これら購入者のこだわりまでを満足させることが出来なかった。
また、人気の高い興行においてはチケット購入の申込が殺到するため抽選を行うが、従来の方法では購入者は当選するか落選するかをただ運に委ねるしかなかなく、自ら当選する確率を高めることは出来なかった。
本発明はこのような問題に鑑みなされたものであり、座席ゾーンという概念を導入することにより、チケット購入者がこだわりのゾーンを指定することを可能にすると共に抽選において自ら当選率を高めことをも可能にするシステム等を提供するものである。

本発明は、例えば、次のような手段を備えるシステム、方法、コンピュータを次のように機能させるコンピュータプログラムである。
（１） 興行会場の複数の座席領域を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付け、前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる。
（２） 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて前記申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第一割当処理を行う。
（３） 前記混雑状況閲覧処理は前記申請データ受付処理の後に行われる。
（４） 前記変更申請受付処理は前記混雑状況閲覧処理の後に行われる。
（５） 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、申請数が許容人数に満たない座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行い、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行い、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる。
（６） 前記第二割当処理は前記申請データ受付処理の後に行われる。
（７） 前記人数更新処理は前記第二割当処理の後に行われる。
（８） 前記混雑状況閲覧処理は前記人数更新処理の後に行われる。
（９） 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われる。
（１０） 前記第二割当処理は前記変更データ受付処理の後に行われる。
（１１） 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、申請数が前記記憶手段に記憶された割当実行条件に適合する座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行い、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行い、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行う。
（１２） 前記第二割当処理は前記申請データ受付処理の後に行われる。
（１３） 前記人数更新処理は前記第二割当処理の後に行われる。
（１４） 前記混雑状況閲覧処理は前記人数更新処理の後に行われる。
（１５） 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われる。
（１６） 前記第二割当処理は前記変更データ受付処理の後に行われる。

本発明には次のような効果がある。
（１）本発明を利用すれば、購入者はこだわりのゾーン、好みのゾーンでコンサート等を観覧できる。これにより顧客満足度が高まるのである。
（２）本発明では一旦希望したゾーンを後から変更できるので、自ら当選確率を上げることが出来るのである。
（３）第一申請データ受付後に割当処理を行えば、取り敢ず第１申請データ受付処理では申請データを送らないで様子見をし、予約状況を閲覧した後に第２申請データ受付処理において申請データを送信するケースを防止でき、第１申請データ受付処理において送信データを送信した人との公平性も確保できる。また、第２申請データ受付処理に申請データが集中することもなく、サーバー１への負荷を軽減することも出来る。

本発明は、電子チケットの販売に関するシステム等に関するものである。以下、図面に基づいて説明する。

本発明の第一実施形態を図に基づいて説明する。図１は本発明の実施に必要なハードウェアとそのハードウェアの結びつきを表した概略図である。
これらハードウェアは、サーバー１とＰＣ２（パーソナルコンピュータ）とからなる。
サーバー１とＰＣ２とはインターネット３（或は、その他の通信手段）によりデータの送受信が可能なものとなっている。
サーバー１、ＰＣ２はデータを記憶するための記憶装置とデータを送受信するためのデータ送信部並びにデータ受信部とを各々内蔵し、それらを用いてデータの送受信を行う。

各々の記憶装置には本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、サーバー１、ＰＣ２はこのコンピュータプログラムの処理命令に従って所定の処理を行う。ＰＣ２には、データを表示するための表示モニタ１１とデータを入力するためのキーボード１２が備えられている。
なお、本実施形態では、サーバー１がチケット管理手段としての役割を果し、ＰＣ２がチケット申請手段としての役割を果し、サーバー１に備えられている記憶装置が記憶手段としての役割を果し、ＰＣ２に備えられている表示モニタ１１が入力手段としての役割を果し、キーボード１２が出力手段としての役割を果す。

次に、本発明を実現するための処理手順について説明する。本発明の処理手順は図２＜処理フローＡ＞の通りであり、＜第１申請データ受付：ＳＴＥＰ１−１＞→＜抽選及び座席割当：ＳＴＥＰ１−２＞の手順で行う。なお、点線で結ばれた処理は類似した処理同士であることを表す。以下、これら処理について説明する。

＜第１申請データ受付：ＳＴＥＰ１＞
東京都在住の山田太郎さんはある人気歌手のコンサートを観覧しようと考えている。山田さんはチケット（電子チケット）を予約申込をするためあるチケット販売会社のホームページにアクセスした。これによりＰＣ２の表示モニタ１１には図３のような内容が表示される。即ち、このコンサート会場の座席は３つのゾーン（ゾーンＡ、ゾーンＢ、ゾーンＣ）に分れており、チケット購入者は自分がどのゾーンの座席を希望するかを指定出来るようになっている。なお、山田さんは既にこのチケット販売会社の会員になっており、住所や氏名などは登録済であり、この会社の顧客としてのＩＤ（顧客ＩＤ）も既に取得済であるとする。
山田さんは、表示画面に従って自分の顧客ＩＤと希望ゾーン（ゾーンＡ）を入力し、画面下の「送信」をクリックする。これによりＰＣ２は第１申請データ（図４）「顧客ＩＤ：９７１５、希望ゾーン：ゾーンＡ、人数：１」を作成し、これをサーバー１に送信する。なお、本来であれば、ここで観覧を希望するコンサートのＩＤや観覧希望日なども送信すべきものであるが、これらは本発明とは関連性が薄い部分なのでここでは省略する。また、本実施形態では第一申請データが申請データとしての役割を果し、この申請データに含まれる顧客ＩＤが購入者（購入者を特定するための購入者特定情報）としての役割を果し、この申請データに含まれる希望ゾーンが希望領域としての役割を果す。

第１申請データを受信した（受付けた）サーバー１はこれを記憶装置に記憶する。
次に、サーバー１は受信した申請データに基づいてゾーン管理ファイルを更新（作成）するための処理を行う。サーバー１の記憶装置には各ゾーンを管理するためのゾーン管理ファイル（図５）「ゾーン名：ゾーンＡ、許容人数：５０、申請数：０、申請者ＩＤ：情報なし／ゾーン名：ゾーンＢ、許容人数：７０、申請数：０、申請者ＩＤ：情報なし／ゾーン名：ゾーンＣ、許容人数：９０、申請数：０、申請者ＩＤ：情報なし」が記憶されている。これはゾーン名、そのゾーンが許容する人数、そのゾーンに対する申請数、申請者ＩＤとが関連（対応）づけられているゾーン管理レコード（複数のレコード）からなるものである。このファイルを利用すればゾーンに関する管理をすることができるのである。

サーバー１は、第１申請データに含まれる「顧客ＩＤ：９７１５、希望ゾーン：ゾーンＡ」に基づいてゾーン管理ファイルを更新する。即ち、図５ゾーンＡの申請数に１を加え、ゾーンＡの申請者ＩＤの項目に「９７１５」を代入する。これにより、ゾーン管理ファイルは図６のように更新される。なお、このゾーン管理ファイルが申請状況管理情報としての役割を果す。
サーバー１は、このようにして一定期間複数の顧客から複数の第１申請データを受付け、同様の処理によりゾーン管理ファイルを更新する。これにより、ゾーン管理ファイルは図７のようになったとする。なお、ゾーン管理ファイルに含まれる申請数とはサーバー１が申請データに含まれる人数をゾーン毎に集計したものである。

＜抽選及び座席割当：ＳＴＥＰ２＞
次に、サーバー１は抽選処理を行う。まず、サーバー１は各ゾーンの申請数が許容人数を上回るか否かを判断し、上回る場合はそのゾーンについて抽選処理を行う。即ち、ゾーンＡについては許容人数「５０」を大幅に上回る申請数「７９」があったので、サーバー１は抽選により、５０人を当選者とし、残りの２９人を落選者とする。一方、ゾーンＢとゾーンＣは許容人数を申請者数が下回ったので抽選処理は行わない。なお、この抽選処理は既知のものであり、例えばサーバー１に備えられている乱数発生機能などを用いて申請者（申請者ＩＤ）７９人の中から任意の５０人を抽出するものである。即ち、サーバー１は抽選処理により当選者と落選者とを決め、当選者のＩＤのみをゾーン管理ファイルの申請者ＩＤの項目に残し、落選者のＩＤは削除するのである（落選者のＩＤは落選者データ「ゾーンＡ落選者：３３３１、２８８８、…」などを別途作成して記憶しておけばよい）。なお、この他抽選処理の例は特開２００１−１５５２０３号等でも示されている。

次に、サーバー１は各座席を申込者（当選者）に割当てるための処理（割当処理）を行う。即ち、希望ゾーンに購入者（顧客ＩＤにより特定される購入者）をチケット権利者として割当てるための処理を行う。サーバー１の記憶装置には図８のような座席管理ファイルが記憶されている。これは、座席番号とその権利者のＩＤとを対応づけるものであり、図左がゾーンＡ、中央がゾーンＢ、右がゾーンＣのファイルである。図８『ゾーンＡ「Ａ００１：情報なし／Ａ００２：情報なし／Ａ００３：情報なし／…／Ａ０４９：情報なし／Ａ０５０：情報なし」、ゾーンＢ「Ｂ００１：情報なし／Ｂ００２：情報なし／Ｂ００３：情報なし／…／Ｂ０６６：情報なし／Ｂ０６７：情報なし／Ｂ０６８：情報なし／Ｂ０６９：情報なし／Ｂ０７０：情報なし」、ゾーンＣ「Ｃ００１：情報なし／Ｃ００２：情報なし／Ｃ００３：情報なし／…／Ｃ０４７：情報なし／Ｃ０４８：情報なし／Ｃ０４９：情報なし／…／Ｃ０８８：情報なし／Ｃ０８９：情報なし／Ｃ０９０：情報なし」』の通り、いまのところ誰がどの座席を確保するかは全く決っていない。
サーバー１は、図７のゾーン管理ファイルにゾーン毎に記憶されている申請者ＩＤを図８の権利者ＩＤにゾーン毎に代入する。これにより、座席管理ファイルは図９のような内容に更新される。

この後、サーバー１は座席毎に電子チケット（チケットデータ：図１０）「興行ＩＤ：Ｔ００８、権利者ＩＤ：９７１５、興行名：○○○コンサート、日付・会場：○月○日 ○○スタジアム、座席：Ａ００１」を作成し、それを各顧客に発行する。なお、興行ＩＤなどは記憶装置に記憶されている別のファイルを参照して得られたものとする。
このようにすれば、チケットを購入する者は好みのゾーン（こだわりのゾーン）のチケットを入手することができ、コンサートを好みのゾーンで観覧することが出来る。

本発明の第二実施形態について説明する。本実施形態は、チケット購入者が一旦指定したゾーンを後に変更できるようにしたものである。即ち、第一実施形態では、ゾーンＡに申込が集中し多くの落選者が出たが、それとは逆にゾーンＣには多くの空席が残った。そして、もしゾーンＡの落選者が当初の希望ゾーン（ゾーンＡ）をゾーンＣに変更することが出来れば、その人はそのコンサートのチケットを入手することが出来たはずである。本実施形態はこのような場合に対応するものであり、チケット購入者が一旦指定したゾーンを後に変更できるようにしたものである。

本実施形態の実施に必要なハードウェアとそのハードウェアの結びつきについては前述の第一実施形態と同様であり、図１と同じである。
次に、本発明を実現するための処理手順について説明する。本発明の処理手順は図２＜処理フローＢ＞の通りであり、＜第１申請データ受付：ＳＴＥＰ２−１＞→＜予約状況閲覧：ＳＴＥＰ２−２＞→＜第２申請データ受付：ＳＴＥＰ２−３＞→＜抽選及び座席割当：ＳＴＥＰ２−４＞の手順で行う。以下、これら処理について説明する。

＜第１申請データ受付：ＳＴＥＰ２−１＞
この処理は第一実施形態と同様である。即ち、図３から図７までに示す通り、サーバー１が複数の第１申請データを受信し、ゾーン管理ファイルを図７のように更新するところまでは第一実施形態と同様である。

＜予約状況閲覧（混雑状況閲覧処理）：ＳＴＥＰ２−２＞
次に、サーバー１は予約状況をチケット申込者に知らせるための処理を行う。即ち、各ゾーンの予約状況（ゾーンＡは申込が殺到していて落選する確率が高い、ゾーンＣは申込数が少なく確実にチケットを入手できる等の状況）をチケット申込者に閲覧させ、これによりゾーン変更を行うか否かの判断をチケット購入者に行わせるための処理を行う。
サーバー１の記憶装置には表示態様を決めるための表示態様ファイル（図１１）「条件（残り座席数）：０以下、表示態様：満席／条件（残り座席数）：１〜５、表示態様：残少／条件（残り座席数）：６以上、表示態様：残多」が記憶されている。これはゾーン毎の残席数に応じてどのような文言を表示するかを決めるためのものである。なお、この残席数は図７のゾーン管理ファイルにおける申請数と許容人数に基づいて（許容人数と申請数との差を求めることにより）算出されるものである。
サーバー１は各ゾーン毎の残席数を検索キーにしてこの表示態様ファイルを検索し、その結果に基づいて予約状況データ（図示せず）「ゾーンＡ：満席／ゾーンＢ：残少／ゾーンＣ：残多」を作成し、ＰＣ２からの予約状況要求に応じて予約状況データをＰＣ２に送信する。なお、この予約状況データが混雑状況としての役割を果す。

予約状況データを受信したＰＣ２はそれを記憶すると共に、図１２のように表示モニタ１１にそれを表示する。なお、この時点で、顧客ＩＤや希望ゾーンは入力されていないものとする。図１２をみた山田さんは自分が希望したゾーンＡが既に満席であること（落選してチケットを獲得できない可能性があること）を知った。山田さんは希望するゾーンはゾーンＡであるが座席がより確実に確保できるのであればゾーンＣでも構わないと考えた。そこで、山田さんは図１２に顧客ＩＤと希望ゾーンを入力し、画面下の「送信」をクリックした。
これによりＰＣ２は第２申請データ（図１３）「顧客ＩＤ：９７１５、希望ゾーン：ゾーンＣ、人数：１」を作成し、それをサーバー１に送信した。なお、この第２申請データが変更申請データとしての役割を果す。

＜第２申請データ受付（変更申請受付処理）：ＳＴＥＰ２−３＞
第２申請データを受信したサーバー１はそれを記憶装置に記憶すると共に、ゾーン管理ファイルの更新を行う。
そのため、まずサーバー１は第２申請データに含まれる「顧客ＩＤ：９７１５」を検索キーにして図７のゾーン管理ファイル（申請者ＩＤの項目）を検索する。これによりサーバー１は山田さんが当初はゾーンＡを希望していたが、それをゾーンＣ（第２申請データに含まれる「希望ゾーン：ゾーンＣ」）に変更することを特定する。サーバー１は図７の状態のゾーン管理ファイルにおいて、ゾーンＡの申請数を「１」減らし、ゾーンＡの申請者ＩＤの項目から「申請者ＩＤ：９７１５」（第２申請データに含まれる「顧客ＩＤ：９７１５」）を削除する。そして、ゾーンＣの申請数に「１」を加え、ゾーンＣの申請者ＩＤに「９７１５」を加える。これにより、ゾーン管理ファイルは図７の状態から図１４のようになる。
サーバー１はこのようにして一定期間複数の第２申請データを受付け、ゾーン管理ファイルの更新を繰返す。これによりゾーン管理ファイルは図１５のようになり、この後サーバー１は＜抽選及び座席割当：ＳＴＥＰ２−４＞を行う。

＜抽選及び座席割当：ＳＴＥＰ２−４＞
次に、サーバー１は抽選処理を行う。即ち、本実施形態でもゾーンＡについては許容数を申請数が上回った（図１５）ため、サーバー１はゾーンＡについて抽選を行うのである。なお、この抽選処理は第一実施形態と同様なのでここでは説明を省略する。
次に、サーバー１は第２申請データ受付処理で更新したゾーン管理ファイルに基づいて割当処理（第一割当処理）を行う。この割当処理も第一実施形態と同様なのでここでは説明を省略する。この割当処理により各座席の権利者が図１６のように決定する。
以上のようにすれば、チケット購入者は希望ゾーンの変更が可能となり、自ら当選率を上げることが出来る。

本発明の第三実施形態について説明する。本実施形態は、ほぼ第二実施形態と同様であるが、第１申請データ受付後に第１回座席割当の処理を行う点で異なる。第二実施形態の場合、座席の割当は第２申請データ受付後に一回だけ行うが、これでは殆どの人が第１申請データ受付処理を無視して第２申請データ受付処理においてのみ申請データを送信してくる可能性がある。即ち、第二実施形態では第１申請データ受付処理で申請データを送信しなくても、第２申請データ受付処理において申請データを変更または送信できるので、敢えて第１申請データを送信する必要はない。よって、取り敢ず第１申請データ受付処理では申請データを送らないで様子見をするか、適当なデータを送り、予約状況を閲覧した後に第２申請データ受付処理において申請データを送信するケースが続発するおそれがある。しかし、これでは第１申請データ受付処理を設けた趣旨が損われてしまい、第１申請データ受付処理において申請データを送信した人にとっても公平感の欠けるものとなってしまう。また、第２申請データ受付処理に申請データが集中すると、サーバー１に負荷がかかり不測のトラブルが生じるおそれもある。最も想定されるのは第２申請データ受付処理の期限直前に申込が集中することである。そこで、本実施形態では第１申請データ受付処理の後に、申請数が許容人数に満たないものについては即座に座席を割当てる処理を行うことにしたものである。
以下、本実施形態について説明する。

本実施形態の実施に必要なハードウェアとそのハードウェアの結びつきについては前述の第一実施形態と同様であり、図１と同じである。

次に、本発明を実現するための処理手順について説明する。本発明の処理手順は図２＜処理フローＣ＞の通りであり、＜第１申請データ受付：ＳＴＥＰ３−１＞→＜第１回座席割当：ＳＴＥＰ３−２＞→＜予約状況閲覧：ＳＴＥＰ３−３＞→＜第２申請データ受付：ＳＴＥＰ３−４＞→＜抽選及び第２回座席割当：ＳＴＥＰ３−５＞の手順で行う。以下、これら処理について説明する。

＜第１申請データ受付：ＳＴＥＰ３−１＞
この処理は第一実施形態及び第二実施形態と同様である。即ち、図３から図７までに示す通り、サーバー１が複数の第１申請データを受信し、ゾーン管理ファイルを図７のように更新するところまでは第一実施形態及び第二実施形態と同様である。

＜第１回座席割当：ＳＴＥＰ３−２＞
次に、サーバー１は申請数が許容数に満たないゾーンについて座席の割当処理（第二割当処理）を行う。図７ではゾーンＢとゾーンＣについては申請数が許容数に満たないので、この二つのゾーンについては座席の割当を行う。なお、割当処理については第一実施形態及び第二実施形態と同様である。これによりゾーンＢについては申請数が「６７」なのでＢ００１からＢ０６７までの席が割当てられ（図１７）、ゾーンＣについては申請数が「４８」なのでＣ００１からＣ０４８までの席が割当てられる（図１７）。一方、ゾーンＡについては申請数が許容人数を上回っているので、ここでは割当処理は行わない。
次に、サーバー１はゾーン管理ファイル（図７）を更新するための処理（第二割当処理において割当てた人数に基づいてゾーン管理ファイルを更新する人数更新処理）を行う。当初、ゾーンＢの許容人数は「７０」であったが、前述の通りゾーンＢについては座席を６７まで割当てたので、サーバー１はゾーンＢの許容数を「３」とし、申請数を「０」とし、申請者ＩＤを情報なしにする（図１８）。また、これと同様にゾーンＣの許容人数を「４２」とし、申請数を「０」とし、申請者ＩＤを情報なしにする（図１８）。

次に、サーバー１は人数更新処理において更新されたゾーン管理ファイル（図１８）に基づいて予約状況を作成等する＜予約状況閲覧：ＳＴＥＰ３−３＞の処理を行うが、これら処理は第二実施形態と同様である。
次に、サーバー１は＜第２申請データ受付：ＳＴＥＰ３−４＞を行う。第２申請データの内容は第二実施形態の図１３と同じである。そして、この申請データを受付けたサーバー１はゾーン管理ファイルの更新を行う。具体的には、図１８から図１９へ更新する。
サーバー１は複数の第２申請データの受付を繰返し、第２申請データ受付処理終了後にはゾーン管理ファイルは図２０のように更新されているものとする。

次に、サーバー１は＜抽選及び第２座席割当：ＳＴＥＰ３−５＞の処理を行う。即ち、ゾーンＡについては第一実施形態及び第二実施形態と同様、抽選を行う。また、ゾーンＢも許容人数を申請数が上回ったので、抽選を行う。
そして、ゾーンＡについてはＡ００１からＡ０５０について座席を割当てる処理（第三割当処理）を行う（図２１）。また、ゾーンＢについては既にＢ０６７まで座席の割当が行われているので、残りのＢ０６８からＢ０７０までについて当選者を座席を割当てる（図２１）。ゾーンＣについては既にＣ０４８まで座席の割当が行われており、申請数は「１５」なので、残りのＣ０４９からＣ０６３までについて座席を割当てる（図２１：Ｃ０６４以降は申請者がいないので割当は行わず、空席となる）。
このように、第１申請データ受付処理の後に第１回割当処理を行えば、取り敢ず第１申請データ受付処理では申請データを送らないで様子見をし、予約状況を閲覧した後に第２申請データ受付処理において申請データを送信するケースを防止でき、第１申請データ受付処理において送信データを送信した人との公平性も確保できる。また、第２申請データ受付処理に申請データが集中することもなく、サーバー１への負荷を軽減することも出来る。

本発明の第四実施形態について説明する。本実施形態は、ほぼ第三実施形態と同様であるが、第１回割当処理（第二割当処理：ＳＴＥＰ３−２）を行う際の条件が異なる。即ち、第三実施形態では、申請数が許容人数に満たない場合にのみ第１回割当処理を行っていたが、本実施形態では申請数が許容人数を満たしていても（上回っていても）、申請数が割当実行条件に適合していれば第１回割当処理を行うものである。以下、これらについて説明する。

第一申請データ受付処理においてゾーン毎の申請数が集計されゾーン管理ファイルが図４−１のように更新されたとする（なお、この図４−１は第三実施形態における図７に相当する図であり、図７と図４−１との相違はゾーンＢの申請数が「７４」であり、許容人数「７０」を上回っている点にある）。
サーバー１は記憶装置に記憶されている割当実行条件「ゾーンＡ：５５人以下、ゾーンＢ：７７人以下、ゾーンＣ：９９人以下」（許容人数にその１０％を加算した人数：図示せず）が記憶されており、サーバー１は各ゾーンの申請数とこの割当実行条件とを比較して、この条件に適合したゾーン（ゾーンＢ、ゾーンＣ）についてのみ第１回割当処理を行う。即ち、ゾーンＢについては抽選により７０人の座席割当を行い、ゾーンＣについて抽選を行うことなく座席の割当を行うのである。

これにより座席管理ファイルは図４−２の通りとなり、ゾーンＢについてはすべての座席に顧客が割当てられ、ゾーンＣについては４８人について座席が割当てられる。そして、サーバー１は人数更新処理を行い、これによりゾーン管理ファイルは図４−３の通りとなる。即ち、ゾーンＢの許容人数は「０」に更新され、ゾーンＣの許容人数は「４２」に更新される。このように本実施形態は、申請数が許容人数に満たない場合のみならず、申請数が許容人数を僅かに上回ったゾーンについても優先的に座席を割当てるものである。
このようにすれば統計的に人気がないゾーンを希望する顧客（ニッチな顧客）は、そのニッチ（人気度）の度合いによって座席を獲得できる可能性が高くなる。顧客は自分の意志で人気の高いゾーン、人気の低いゾーンを選択することができるので抽選に外れた場合の納得性も高くなり、また取れたチケットのゾーンに対しても納得性が高くなる。つまり、この発明によって顧客満足度の高い抽選システムを提供することができる。なお、本実施形態では割当実行条件を許容人数の１０％としているがこれに限るものではない。

なお、上記実施形態において座席ゾーンとしているが、これは必ずしも座席を有する場合に限らない。例えば、立見観覧の場合は座席は不要であるが、座席ゾーンとは立見の場合のように座席がない場合をも含むものである。また、座席ゾーンの許容人数は会場構成に合った形で自由に設定できるものである。よって、許容人数が「１」の場合もあり、この場合は座席ゾーンがそのまま座席となる。

上記実施形態おいては特定のケースについて説明したが、本発明はこれら特定のケースに限るものではない。例えば、次のようなケースであっても構わない。
（１）上記実施形態では、コンサートを例にして説明したが、本発明はこれに限るものではない。例えば、スポーツ観戦のためのチケットなどのあらゆるケースに利用できるものである。また、ゾーンについても上記実施形態ではゾーンＡをステージに近いゾーンとし、ゾーンＢを中間のゾーンとし、ゾーンＣをステージから最も遠いゾーンとしたがこれに限るものではない。通路側の座席を一つのゾーンとしてもよいし、二階席の最前列一つのゾーンにしてもよい。即ち、ゾーンの区切り方は自由にできるものである。
（２）データの内容は実施形態で説明したデータに限らない。即ち、同様の役割を果たすことができれば、他のどのようなデータであっても構わない。
（３）ハードウェアも実施形態で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのようなハードウェアであっても構わない。例えば、チケット申請手段としてはＰＣ（パーソナルコンピュータ）に限らず、携帯電話やＰＨＳ、携帯型の小型コンピュータなどを利用してもよい。
（４）処理の内容や手順についても実施形態で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのような処理内容・処理手順であっても構わない。
（５）上記実施形態に登場するデータ（データレコード、ファイル）のデータ（データ項目）は、原則として各々関連づけられて（対応づけられて）記憶装置に記憶されているものとする。図面に表されたものについても同様である。

本発明で利用するハードウェアの概略を示す図である。 処理フローを表した図である。 希望ゾーン申請を表した図である。 第１申請データを表した図である。 ゾーン管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 座席管理ファイルを表した図である。 座席管理ファイルを表した図である。 チケットデータを表した図である。 表示態様ファイルを表した図である。 希望ゾーン変更申請画面を表した図である。 第２申請データを表した図である。 ゾーン管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 座席管理ファイルを表した図である。 座席管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 ゾーン管理ファイルを表した図である。 座席管理ファイルを表した図である。

符号の説明

１ サーバー
２ ＰＣ（コンピュータ）
３ インターネット
１１ 表示モニタ
１２ リーダライタ

Claims (48)

1. 興行会場の複数の座席領域を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
   前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付け、前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てることを特徴とするチケット割当システム。
2. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
   前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて前記申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第一割当処理を行うことを特徴とするチケット割当システム。
3. 前記混雑状況閲覧処理は前記申請データ受付処理の後に行われることを特徴とする請求項２記載のチケット割当システム。
4. 前記変更申請受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項２乃至３記載のチケット割当システム。
5. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
   前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、申請数が許容人数に満たない座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行い、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行い、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行うことを特徴とするチケット割当システム。
6. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項５記載のチケット割当システム。
7. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項５乃至６記載のチケット割当システム。
8. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項５乃至７記載のチケット割当システム。
9. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項５乃至８記載のチケット割当システム。
10. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項５乃至９記載のチケット割当システム。
11. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段とチケットの管理を行うチケット管理手段とからなり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段は、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行い、前記申請データに基づいて座席領域毎の申請数を集計し、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成し、申請数が前記記憶手段に記憶された割当実行条件に適合する座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行い、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行い、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行い希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行い、その変更申請データに基づいて申請状況管理情報を更新し、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行うことを特徴とするチケット割当システム。
12. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項１１記載のチケット割当システム。
13. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項１１乃至１２記載のチケット割当システム。
14. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項１１乃至１３記載のチケット割当システム。
15. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項１１乃至１４記載のチケット割当システム。
16. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項１１乃至１５記載のチケット割当システム。
17. 興行会場の複数の座席領域を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付けさせ、前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てさせることを特徴とするチケット割当のためのコンピュータプログラム。
18. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて前記申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第一割当処理を行わせることを特徴とするチケット割当のためのコンピュータプログラム。
19. 前記混雑状況閲覧処理は前記申請データ受付処理の後に行われることを特徴とする請求項１８記載のチケット割当のためのコンピュータプログラム。
20. 前記変更申請受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項１８乃至１９記載のチケット割当のためのコンピュータプログラム。
21. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、申請数が許容人数に満たない座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行わせ、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行わせ、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行わせることを特徴とするチケット割当のためのコンピュータプログラム。
22. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項２１記載のチケット割当のためのコンピュータプログラム。
23. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項２１乃至２２記載のチケット割当のためのコンピュータプログラム。
24. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項２１乃至２３記載のチケット割当のためのコンピュータプログラム。
25. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項２１乃至２４記載のチケット割当のためのコンピュータプログラム。
26. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項２１乃至２５記載のチケット割当のためのコンピュータプログラム。
27. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、申請数が前記記憶手段に記憶された割当実行条件に適合する座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行わせ、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行わせ、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行わせることを特徴とするチケット割当のためのコンピュータプログラム。
28. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項２７記載のチケット割当のためのコンピュータプログラム。
29. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項２７乃至２８記載のチケット割当のためのコンピュータプログラム。
30. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項２７乃至２９記載のチケット割当のためのコンピュータプログラム。
31. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項２７乃至３０記載のチケット割当のためのコンピュータプログラム。
32. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項２７乃至３１記載のチケット割当のためのコンピュータプログラム。
33. 興行会場の複数の座席領域を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付けさせ、前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てさせることを特徴とするチケット割当方法。
34. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて前記申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第一割当処理を行わせることを特徴とするチケット割当方法。
35. 前記混雑状況閲覧処理は前記申請データ受付処理の後に行われることを特徴とする請求項３４記載のチケット割当方法。
36. 前記変更申請受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項３４乃至３５記載のチケット割当方法。
37. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、申請数が許容人数に満たない座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行わせ、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行わせ、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行わせることを特徴とするチケット割当方法。
38. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項３７記載のチケット割当方法。
39. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項３７乃至３８記載のチケット割当方法。
40. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項３７乃至３９記載のチケット割当方法。
41. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項３７乃至４０記載のチケット割当方法。
42. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項３７乃至４１記載のチケット割当方法。
43. 興行会場の複数の座席領域と各座席領域の許容人数を記憶する記憶手段を備えるチケット管理手段に処理を行わせるものであり、前記チケット管理手段は興行チケット購入のための申請データをチケット購入のための申請を行うチケット申請手段から受付けるものであり、
    前記チケット管理手段に、購入者と購入者が希望する前記座席領域を特定する希望領域とを含む前記申請データを受付ける申請データ受付処理を行わせ、前記申請データに基づいて座席領域毎の申請数を集計させ、前記申請データに基づいて前記購入者及び希望領域とからなる申請状況管理情報を作成させ、申請数が前記記憶手段に記憶された割当実行条件に適合する座席領域については前記申請データに含まれる前記希望領域に前記購入者をチケット権利者として割当てる第二割当処理を行わせ、前記割当処理により割当てた人数に基づいて前記許容人数及び申請数を更新する人数更新処理を行わせ、更新された前記申請数と前記許容人数に基づいて各座席領域の混雑状況を作成してその混雑状況を前記チケット申請手段に閲覧させる混雑状況閲覧処理を行わせ、希望領域を変更するためのデータであって前記購入者と前記希望領域を含む変更申請データを受付ける変更申請受付処理を行わせ、その変更申請データに基づいて申請状況管理情報を更新させ、更新された申請状況管理情報に含まれる前記希望領域に前記購入者をチケット権利者として割当てる第三割当処理を行わせることを特徴とするチケット割当方法。
44. 前記第二割当処理は前記申請データ受付処理の後に行われることを特徴とする請求項４３記載のチケット割当方法。
45. 前記人数更新処理は前記第二割当処理の後に行われることを特徴とする請求項４３乃至４４記載のチケット割当方法。
46. 前記混雑状況閲覧処理は前記人数更新処理の後に行われることを特徴とする請求項４３乃至４５記載のチケット割当方法。
47. 前記変更データ受付処理は前記混雑状況閲覧処理の後に行われることを特徴とする請求項４３乃至４６記載のチケット割当方法。
48. 前記第二割当処理は前記変更データ受付処理の後に行われることを特徴とする請求項４３乃至４７記載のチケット割当方法。

Images