JP5648042B2 - 申込受付システム、申込受付システムの制御方法、及びプログラム - Google Patents

Description

本発明は申込受付システム、申込受付システムの制御方法、及びプログラムに関する。

商品又はサービスの予約又は購入の申込みを受け付けるシステムが知られている。例えば、特許文献１には、処理負荷が所定範囲を超えている場合に、端末からの接続要求を拒絶して予約し、処理負荷が所定範囲内になった場合に、予約済みの端末からの接続を認めるようなシステムが開示されている。

特開２００３−０５８４９９号公報

上記のようなシステムでは、商品又はサービスの残数に比較して多くのユーザがアクセスしてくる場合がある。例えば、商品の残数が５０個である状態でこの商品を購入しようとする１００名のユーザがアクセスしてくる場合がある。

このような場合、何らかの措置を講じなければ、商品を購入できるか否かは、例えば購入確定ボタンを押下したタイミング等によって左右される。その結果、商品購入のために要求される各種情報を入力し終えたにもかかわらず、商品を購入できないという事態も生じ得る。

また、このような場合には、購入申込みの受付を一旦中止し、例えば「多数のアクセスが集中しております。少し時間が経ってから再度アクセスして下さい。」等のメッセージをユーザに提示することも考えられる。しかしながら、この場合、ユーザは頃合いを見計らって再度システムにアクセスしなければならない。

いずれにしても上記のような場合にはユーザが円滑に購入や予約を行うことができず、不満を感じてしまう場合があった。

なお、特許文献１に記載のシステムは、処理負荷が高くなってしまった場合の対処に関するものであり、商品又はサービスの残数と、システムにアクセスしているユーザの数と、のつり合いが取れていない場合の対処に関するものではないため、上記のようなユーザの不満を解消するものにはなっていない。

本発明は上記課題に鑑みてなされたものであって、その目的は、商品又はサービスの残数と、この商品又はサービスを購入又は予約するべくシステムにアクセスしているユーザの数と、のつり合いが取れていないような場合であっても、ユーザが円滑に購入又は予約を行えるようにすることが可能な申込受付システム、申込受付システムの制御方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明に係る申込受付システムは、同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定手段と、前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定手段と、前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける第１の受付手段と、前記所望ユーザの人数が前記上限人数以下であると判定された場合、各前記所望ユーザから申込みを受け付ける第２の受付手段と、を含むことを特徴とする。

また、本発明に係る申込受付システムの制御方法は、同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定ステップと、前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定ステップと、前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける第１の受付ステップと、前記所望ユーザの人数が前記上限人数以下であると判定された場合、各前記所望ユーザから申込みを受け付ける第２の受付ステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定手段、前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定手段、前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける第１の受付手段、及び、前記所望ユーザの人数が前記上限人数以下であると判定された場合、各前記所望ユーザから申込みを受け付ける第２の受付手段、としてコンピュータを機能させるためのプログラムである。

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

また、本発明の一態様では、前記判定手段は、前記商品又はサービスの残数に基づいて、前記上限人数を設定する上限人数設定手段を含むようにしてもよい。

また、本発明の一態様では、前記上限人数設定手段は、前記商品又はサービスの残数と、一人のユーザが申込み可能な前記商品又はサービスの上限数と、に基づいて、前記上限人数を設定するようにしてもよい。

また、本発明の一態様では、前記所望ユーザが所望する前記商品又はサービスの数量を、当該所望ユーザからの申込みの受付が開始される前において取得する数量取得手段を含み、前記閾値設定手段は、前記商品又はサービスの残数と、前記数量取得手段の取得結果と、に基づいて、前記上限人数を設定するようにしてもよい。

また、本発明の一態様では、前記第１の受付手段は、前記受付対象として選出されたユーザからの申込みの受付が終了した場合に、前記受付対象として選出されていない前記所望ユーザのうちから前記受付対象を前記受付順序に基づいて新たに選出し、前記受付対象として新たに選出されたユーザからの申込みを受け付けるようにしてもよい。

本発明によれば、商品又はサービスの残数と、この商品又はサービスを購入又は予約するべくシステムにアクセスしているユーザの数と、のつり合いが取れていないような場合であっても、ユーザが円滑に購入又は予約を行えるようにすることが可能になる。

本発明の実施形態に係る申込受付システムの全体構成の一例を示す図である。 受付制御サーバ及び申込受付サーバのハードウェア構成の一例を示す図である。 チケット選択画面の一例を示す図である。 申込画面の一例を示す図である。 待機画面の一例を示す図である。 受付順序、待ち時間、及び受付開始予定日時について説明するための図である。 開始画面の一例を示す図である。 ユーザテーブルの一例を示す図である。 イベントテーブルの一例を示す図である。 チケットテーブルの一例を示す図である。 受付状況テーブルの一例を示す図である。 申込受付システムの機能ブロック図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムで実行される処理の一例を示す図である。 申込受付システムの変形例について説明するための図である。

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

図１は、本発明の実施形態に係る申込受付システムの全体構成の一例を示す。申込受付システム１は商品又はサービスの予約又は購入の申込みを受け付けるためのシステムである。図１に示すように、本実施形態に係る申込受付システム１は受付制御サーバ１０、申込受付サーバ１２、及びデータベース１４を含む。

申込受付サーバ１２はユーザからの申込みを受け付けるためのサーバであり、受付制御サーバ１０は受付を制御するためのサーバである。受付制御サーバ１０は、ユーザ端末３から申込受付サーバ１２へのアクセスを制御する。

図２は受付制御サーバ１０及び申込受付サーバ１２の各々のハードウェア構成の一例を示す。図２に示すように、受付制御サーバ１０及び申込受付サーバ１２の各々は制御部２０、記憶部２２、光ディスクドライブ部２４、及び通信部２６を含む。

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

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

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

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

受付制御サーバ１０と申込受付サーバ１２との間では相互にデータ通信することが可能である。なお、受付制御サーバ１０と申込受付サーバ１２とは一つのサーバコンピュータによって実現されるようにしてもよい。

受付制御サーバ１０及び申込受付サーバ１２はデータベース１４にアクセスすることが可能である。データベース１４は、受付制御サーバ１０及び申込受付サーバ１２とは別のサーバコンピュータに構築されていてもよいし、受付制御サーバ１０及び申込受付サーバ１２のいずれかに構築されていてもよい。例えば、商品又はサービスの予約又は購入の申込みを受け付けるために必要なデータがデータベース１４に記憶される。データベース１４に記憶されるデータについては後述する（図９〜図１２参照）。

ユーザ端末３は、ユーザが商品又はサービスの予約又は購入を申し込むために使用する情報処理装置である。ユーザ端末３は、例えば携帯電話、携帯情報端末、又はパーソナルコンピュータ等である。受付制御サーバ１０とユーザ端末３との間では通信ネットワーク２を介してデータ通信することが可能である。申込受付サーバ１２とユーザ端末３との間でも通信ネットワーク２を介してデータ通信することが可能である。

例えば、受付制御サーバ１０及び申込受付サーバ１２の各々ではＨＴＴＰデーモンが起動される。また、受付制御サーバ１０及び申込受付サーバ１２の間ではセッションを共有できるようになっている。一方、ユーザ端末３ではブラウザが起動される。ブラウザを介して処理要求（ＨＴＴＰリクエスト）がユーザ端末３から受付制御サーバ１０又は申込受付サーバ１２に送信される。また、上記の処理要求に対応する処理結果（ＨＴＴＰレスポンス）が受付制御サーバ１０又は申込受付サーバ１２からユーザ端末３に送信される。例えば、ウェブページ記述言語で記述されたページデータがユーザ端末３に送信される。ユーザ端末３では、このページデータに基づいて、処理結果に基づく画面が表示部に表示される。

なお、ここでは、ユーザ端末３と受付制御サーバ１０又は申込受付サーバ１２との間の通信がＨＴＴＰに則って実行されることとして説明するが、ユーザ端末３と受付制御サーバ１０又は申込受付サーバ１２との間の通信方式は、ＨＴＴＰに則った通信方式以外の通信方式であってもよい。

上記の申込受付システム１では商品又はサービスの予約又は購入の申込みが受け付けられる。特に申込受付システム１では、チケットの残数とチケットを購入しようとしているユーザの数とのつり合いが取れていないような場合であっても、ユーザが購入を円滑に行えるようになっている。例えば、購入のために要求される各種情報を入力し終えたにもかかわらず、チケットを購入できないという事態が生じないようになっている。また例えば、購入申込みの受付を一旦中止し、かつ、例えば「多数のアクセスが集中しております。少し時間が経ってから再度アクセスして下さい。」等のメッセージをユーザに提示するような場合には、ユーザが頃合いを見計らって再度システムにアクセスしなければならなくなるが、申込受付システム１では、頃合いを見計らって申込受付システム１にアクセスする必要がなくなるようになっている。以下、上記機能について説明する。

まず、ユーザが商品又はサービスの予約又は購入を申し込む場合の手順について説明する。なお、以下では、スポーツの試合やコンサート等の各種イベントのチケットの購入の申込みを受け付ける場合を例として上記手順について説明する。すなわち、商品が「チケット」である場合を例として上記手順について説明する。

まず、ユーザはユーザ端末３を用いて申込受付システム１にアクセスし、所望のイベントを選択する。ユーザが所望のイベントを選択した場合、チケットを選択するためのチケット選択画面がユーザ端末３の表示部に表示される。

図３はチケット選択画面の一例を示す。図３は、所望のイベントとしてプロ野球の試合が選択された場合のチケット選択画面３０について示している。このイベントでは、二つのプロ野球チームの対戦が行われ、先に４勝利したチームが勝者となる。このイベントでは、引き分けがない限り、最大で７試合が行われる。

チケット選択画面３０において、ユーザは、いずれかのオプションボタン３２を選択することによって、７試合のうちの所望の試合と、座席種類と、を選択する。なお、ここでは、説明の簡便のため、一つの試合及び一つの座席種類のみを選択できることとして説明するが、複数の試合又は複数の座席種類を選択できるようにしてもよい。

いずれかのオプションボタン３２を選択した後、ユーザは申込画面ボタン３４を押下する。申込画面ボタン３４が押下された場合、申込受付システム１にアクセスしているユーザのうちの、チケット選択画面３０で選択されたチケットと同じチケットを所望しているユーザの人数に基づいて、チケット購入の申込みを直ちに受け付けるか否かが決定される。

チケット購入の申込みを直ちに受け付けると決定された場合について説明する。この場合、チケットの購入を申し込むための申込画面が表示される。図４は申込画面の一例を示す。図４に示す申込画面４０は申込制限時間欄４１、枚数欄４２、決済方法欄４４、引取方法欄４６、及び申込ボタン４８を含む。

申込受付システム１では、ユーザが申込手続きを完了するまでの制限時間（例えば１０分）が定められており、申込制限時間が経過するまでの残り時間が申込制限時間欄４１に表示される。申込制限時間欄４１に表示される時間は所定の時間間隔で更新される。例えば、上記の時間間隔は１秒に設定され、申込制限時間欄４１に表示される時間は時間経過とともに例えば１秒ずつ減少していく。この場合、申込制限時間欄４１はカウントダウンタイマーに相当することになる。なお、上記の時間間隔は申込受付システム１の管理者が任意に設定できるようにしてもよい。

ユーザは所望のチケットの枚数を枚数欄４２において指定する。また、ユーザは決済方法や引取方法を決済方法欄４４及び引取方法欄４６において指定する。なお、申込画面４０にはイベント会場の座席表を表示するようにしてもよい。また、ユーザが座席表のうちから一又は複数の座席を指定することによって、所望の座席を指定できるようにしてもよい。

申込ボタン４８が押下された場合、チケットの購入処理が実行される。例えば、決済処理やチケットの発行処理が実行される。なお、チケットの発行処理は、電子チケットをユーザに発行するための処理であってもよいし、紙媒体のチケットをユーザに発行するための処理であってもよい。チケットの購入処理が実行された後、例えば、ユーザの購入処理が完了したことを示す画面（図示せず）がユーザ端末３の表示部に表示される。

なお、上述の「申込制限時間」とは、申込画面４０の申込ボタン４８が押下されるまでの制限時間である。このため、ユーザは申込制限時間が経過するまでに申込ボタン４８を押下する必要がある。なお、申込制限時間が経過するまでにユーザが申込ボタン４８を押下しなかった場合、申込手続きは中止され、その旨がユーザに通知される。

チケット購入の申込みを直ちに受け付けないと決定された場合について説明する。この場合、申込みの受付が開始されるのを待つための待機画面がユーザ端末３の表示部に表示される。

図５は待機画面の一例を示す。図５に示すように、待機画面５０は受付状況欄５２、受付順序欄５４、受付開始予定日時欄５６、及び待ち時間欄５８を含んでいる。

申込受付システム１では、同じチケットを希望している複数のユーザに関し、それらのユーザからの申込みを受け付ける順序が決定されるようになっている。受付状況欄５２には、現在何番目のユーザの申込みを受け付けているのかが表示される。受付順序欄５４には、ユーザに割り当てられた受付順序が表示される。受付開始予定日時欄５６には、ユーザからの申込みの受付が開始される予定日時が表示される。待ち時間欄５８には、ユーザの申込みの受付が開始されるまでの待ち時間が表示される。待ち時間欄５８に表示される待ち時間は所定の時間間隔で更新される。例えば、上記の時間間隔は１秒に設定され、待ち時間欄５８に表示される待ち時間は時間経過に伴って１秒ごとに減少していく。この場合、待ち時間欄５８はカウントダウンタイマーに相当することになる。なお、上記の時間間隔は申込受付システム１の管理者が任意に設定できるようにしてもよい。

ここで、受付順序、受付開始予定日時、及び待ち時間についてもう少し詳しく説明しておく。図６は受付順序、受付開始予定日時、及び待ち時間について説明するための図である。図６は同じチケットを希望するユーザが１５人いる場合を示している。

図６に示すように、この場合、これらの１５人のユーザに「１」〜「１５」の受付順序が割り当てられる。チケットを購入する意思を早く示したユーザほど、早い受付順序が割り当てられる。すなわち、チケットを購入する意思を第ｉ（ｉ：１以上の整数）番目に示したユーザの受付順序は「第ｉ番目」に設定される。なお例えば、チケット選択画面３０の申込画面ボタン３４を押下した場合に、チケットを購入する意思を示したとみなされる。

申込みの受付は受付順序が早いユーザから順番に開始される。ただし、申込受付システム１では、同じチケットを希望している上限人数内のユーザからの申込みが同時に並行して受け付けられるようになっている。

例えば、チケットの残数が「５０」であり、１人のユーザが購入することが可能なチケットの上限枚数が「５」である場合、１０人のユーザが５枚ずつこのチケットを購入すると、チケットの残数は零になる。このようなチケットの購入の申込みを１１人以上のユーザから同時に並行して受け付けてしまうと、所望の枚数のチケットを購入できないユーザが生じてしまう可能性がある。そこで、このような不都合が生じないようにすべく、申込受付システム１では、このような場合に上限人数が「１０人」に設定されるようになっている。

図６に示す状況では、受付順序が「１」及び「２」であるユーザは申込手続きをすでに完了している。また、受付順序が「３」〜「１２」であるユーザは申込手続き中であり、かつ、受付順序が「１３」〜「１５」であるユーザは待機中である。なお、図６において「残り時間」とは、申込制限時間が経過するまでの残り時間を意味している。

図６に示す状況の場合、申込手続き中のユーザのうちで、受付順序が「３」であるユーザの残り時間は「３分３０秒」になっており、最も少なくなっている。このような場合、待機中のユーザのうちで受付順序が最も早いユーザ、すなわち受付順序が「１３」であるユーザは最大で３分３０秒待てば、申込みの受付が開始されることになる。このため、受付順序が「１３」であるユーザの待ち時間は「３分３０秒」になる。また、この場合、現時点から当該待ち時間（３分３０秒）が経過する時点が、受付順序が「１３」であるユーザの受付開始予定日時になる。

同様に、申込手続き中のユーザのうちで、受付順序が「４」であるユーザの残り時間は「３分５０秒」になっており、第二番目に少なくなっている。このような場合、待機中のユーザのうちで受付順序が第二番目に早いユーザ、すなわち受付順序が「１４」であるユーザは最大で３分５０秒待てば、申込みの受付が開始されることになる。このため、受付順序が「１４」であるユーザの待ち時間は「３分５０秒」になる。また、この場合、現時点から当該待ち時間（３分５０秒）が経過する時点が、受付順序が「１４」であるユーザの受付開始予定日時になる。

このように、待機中のユーザのうちで受付順序が第ｉ番目に早いユーザの待ち時間は、申込手続き中のユーザのうちで受付順序が第ｉ番目に早いユーザの残り時間になる。また、待機中のユーザのうちで受付順序が第ｉ番目に早いユーザの受付開始予定日時は、現時点から上記の待ち時間が経過する時点、すなわち、申込手続き中のユーザのうちで受付順序が第ｉ番目に早いユーザの申込制限時間が経過する時点になる。

申込手続き中のユーザのいずれかが申込手続きを完了すると、待機中のユーザのうちで、受付順序が最も早いユーザの申込みの受付が開始される。図６に示す状況において、例えば、受付順序が「５」であるユーザが申込手続きを完了すると、待機中のユーザのうちで受付順序が最も早い、受付順序が「１３」であるユーザの申込みの受付が開始される。

この場合、申込みの受付が開始された旨を通知する開始画面がユーザ端末３の表示部に表示される。図７は開始画面の一例を示す。図７に示すように、開始画面６０は申込制限時間欄６１及び申込画面ボタン６２を含む。申込画面４０の申込制限時間欄４１と同様、申込制限時間が経過するまでの残り時間が申込制限時間欄６１に表示される。申込制限時間欄６１に表示される時間は時間経過とともに例えば１秒ずつ減少していく。申込画面ボタン６２が押下された場合、申込画面４０がユーザ端末３の表示部に表示される。

なお、受付順序が「１３」であるユーザの申込みの受付が開始された場合、受付順序が「１４」であるユーザは、待機中のユーザのうちで受付順序が最も早いユーザになる。このため、受付順序が「１４」であるユーザの待ち時間は「３分３０秒」に短縮される。同様に、受付順序が「１５」であるユーザは、待機中のユーザのうちで受付順序が第二番目に早いユーザになる。このため、受付順序が「１５」であるユーザの待ち時間は「３分５０秒」に短縮される。

以上に説明した申込受付システム１では、チケットの残数とチケットを購入しようとしているユーザの数とのつり合いが取れていないような場合であっても、ユーザが購入を円滑に行えるようになっている。例えば、購入のために要求される各種情報を入力し終えたにもかかわらず、チケットを購入できないという事態が生じないようになっている。また例えば、購入申込みの受付を一旦中止し、かつ、例えば「多数のアクセスが集中しております。少し時間が経ってから再度アクセスして下さい。」等のメッセージをユーザに提示するような場合には、ユーザが頃合いを見計らって再度システムにアクセスしなければならなくなるが、申込受付システム１によれば、頃合いを見計らって申込受付システム１にアクセスする必要がなくなる。

また、申込受付システム１では、ユーザは待機画面５０に表示される情報を頼りに、申込みの受付が開始されるまでにどのぐらいの時間待てばよいのかをユーザが把握できるようになる。

また、申込受付システム１では、申込手続きを完了するまでの申込制限時間（例えば１０分間）が定められているため、受付開始予定日時や待ち時間の精度を高めることが可能になる。すなわち、受付開始予定日時になっても受付が開始されないという事態が発生しないように担保されている。

また、申込受付システム１では、待機画面５０に表示される情報が、ユーザよりも受付順序が前である他のユーザの申込みの受付完了状況に基づいて更新される。例えば、他のユーザが申込制限時間よりも短い時間で申込手続きを完了した場合には、ユーザに提示される受付開始予定日時及び待ち時間が短縮されるようになっている。

以下、以上に説明したような申込受付システム１を実現するための構成について説明する。まず、データベース１４に記憶されるデータの一例について説明する。図８〜図１１はデータベース１４に記憶されるデータの一例について示す。

図８はユーザテーブルの一例を示す。ユーザテーブルは、申込受付システム１を利用するユーザの一覧を示す。例えば、ユーザテーブルは「ユーザＩＤ」、「パスワード」、「氏名」、「メールアドレス」、及び「クレジットカード情報」フィールドを含む。

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

図９はイベントテーブルの一例を示す。イベントテーブルは、申込受付システム１においてチケットが販売されているイベントの一覧を示す。例えば、イベントテーブルは「イベントＩＤ」、「イベント名」、「カテゴリ」、「日時」、及び「会場」フィールドを含む。

「イベントＩＤ」フィールドは、イベントを一意に識別するための情報（イベントＩＤ）を示す。「イベント名」フィールドはイベントの名称を示す。「カテゴリ」フィールドはイベントのカテゴリを示す。「日時」及び「会場」フィールドはイベントの開催日時及び開催会場を示す。

図１０はチケットテーブルの一例を示す。チケットテーブルは各イベントのチケットに関する情報を示す。チケットテーブルは「チケットＩＤ」、「イベントＩＤ」、「種別」、「価格」、「全数」、「販売済数」、及び「残り数」フィールドを含む。

「チケット」ＩＤフィールドは、チケットの種類を一意に識別するための識別情報（チケットＩＤ）を示す。なお以下では、チケットＩＤが同じであるチケットのことを同じチケットと記載する。「イベントＩＤ」フィールドはイベントテーブルの「イベントＩＤ」フィールドと同様である。「種別」フィールドは座席の種別を示す。「価格」フィールドは販売価格を示す。

「全数」フィールドはチケットの全数を示す。「販売済数」フィールドはチケットの販売済み数を示す。「残り数」フィールドはチケットの残り数（販売可能な残り数）を示す。なお、「残り数」フィールドの値は、「全数」及び「販売済数」フィールドの値から取得することができるため、「販売済数」及び「残り数」フィールドの一方を省略するようにしてもよい。

なお、チケットが指定席のチケットである場合には、どの座席がどのユーザによって購入されたかを管理するためのテーブルがチケットテーブルの他にデータベース１４に記憶されるが、ここでは省略する。また、チケットの購入履歴を示すテーブルもデータベース１４に記憶されるが、ここでは省略する。

図１１は受付状況テーブルの一例を示す。受付状況テーブルは、チケットの購入申込みの受付状況を示すテーブルである。例えば、受付状況テーブルは「イベントＩＤ」、「チケットＩＤ」、「受付順序」、「ＩＤ」、「申込状態フラグ」、「受付開始予定日時」、及び「受付開始日時」フィールドを含む。

「イベントＩＤ」及び「チケットＩＤ」フィールドは、ユーザが購入しようとしているチケットのイベントＩＤ及びチケットＩＤを示す。なお、ユーザが購入しようとしているチケットはチケットＩＤのみによって特定することができるため、「イベントＩＤ」フィールドは省略するようにしてもよい。

「受付順序」フィールドは、ユーザに割り当てられた受付順序を示す。「ＩＤ」フィールドは、ユーザを一意に識別するための識別情報を示す。例えば、セッションＩＤが「ＩＤ」フィールドに登録される。

「申込状態フラグ」フィールドは、ユーザからの申込みの受付状態を示す。例えば、「０」、「１」、「２」、又は「３」が「申込状態フラグ」フィールドに登録される。値「０」は、申込みの受付が開始されていないことを示す。つまり、値「０」はユーザが待機中であることを示す。値「１」は、申込みの受付が開始されていることを示す。つまり、値「１」はユーザが申込手続き中であることを示す。値「２」は、申込手続きが正常に完了したことを示す。値「３」は、申込手続きが完了する前に申込制限時間が経過したことによって、申込みの受付が中止されたことを示す。

「受付開始予定日時」フィールドは、ユーザからの申込みの受付が開始される予定の日時を示す。「受付開始日時」フィールドは、ユーザからの申込みの受付が実際に開始された日時を示す。

次に、申込受付システム１で実現される機能ブロックについて説明する。図１２は、申込受付システム１で実現される機能ブロックのうちの、本発明に関連する機能ブロックを示す機能ブロック図である。

図１２に示すように、申込受付システム１は判定部７０（判定手段）、受付順序設定部７４（受付順序設定手段）、第１の受付部７６（第１の受付手段）、及び第２の受付部７８（第２の受付手段）を含む。図１２に示す各機能ブロックは受付制御サーバ１０又は申込受付サーバ１２によって実現される。受付制御サーバ１０及び申込受付サーバ１２の制御部２０がプログラムに従って処理を実行することによって、図１２に示す各機能ブロックが実現される。

判定部７０について説明する。判定部７０は、同一商品又はサービスの予約又は購入の申込みを所望しているユーザ（以下「所望ユーザ」と記載する。）の人数が上限人数以下であるか否かを判定する。

判定部７０は上限人数設定部７２（上限人数設定手段）を含む。上限人数設定部７２は商品又はサービスの残数に基づいて上限人数を設定する。

例えば、「商品」がチケットＡである場合、判定部７０は、チケットＡの購入申込みを所望しているユーザ（所望ユーザ）の人数が上限人数以下であるか否かを判定する。この場合、上限人数設定部７２は、チケットＡの残数と、１人のユーザが申込み可能なチケットＡの上限数と、に基づいて、上限人数を設定する。例えば、チケットＡの残数が「５０」であり、１人のユーザが購入可能なチケットＡの上限数が「５」である場合、チケットＡの購入申込みを１１名以上のユーザから同時に並行して受け付けてしまうと、所望の枚数のチケットＡを購入できないユーザが生じてしまう可能性がある。そこで、このような不都合が生じないようにすべく、このような場合には上限人数が「１０名」に設定される。

受付順序設定部７４について説明する。受付順序設定部７４は、所望ユーザから申込みを受け付ける場合の受付順序を設定する。

受付順序設定部７４は、予約又は購入の意思を早く示した所望ユーザから順番に申込みの受付が開始されるように、受付順序を設定する。なお、受付順序設定部７４は、申込受付システム１の特定画面（例えばチケット選択画面３０）に早くアクセスした所望ユーザから順番に申込みの受付が開始されるように、受付順序を設定するようにしてもよい。

また、受付順序設定部７４は各商品又はサービスごとに受付順序を設定する。例えば、受付順序設定部７４は各チケットごとに受付順序を設定する。

例えば、チケットＡを所望しているユーザのうちで、ユーザＸがチケットＡの購入意思を第ｉ番目に示していた場合、受付順序設定部７４はユーザＸの受付順序を「第ｉ番目」に設定する。なお例えば、チケット選択画面３０においてチケットＡが選択された状態で申込画面ボタン３４が押下された場合に、受付順序設定部７４は、チケットＡの購入意思が示されたとみなす。

第１の受付部７６について説明する。判定部７０によって所望ユーザの人数が上限人数以下でないと判定された場合に、第１の受付部７６は、受付順序設定部７４によって設定された受付順序に基づいて、所望ユーザのうちから、上限人数以下のユーザを受付対象として選出する。第１の受付部７６は、受付対象として選出された各ユーザから申込みを受け付ける。なお、本実施形態の場合、申込状態フラグが「１」であるユーザ、すなわち、申込手続き中のユーザが「受付対象」として選出されたユーザに相当する。

例えば、「商品」がチケットＡである場合、第１の受付部７６は、各ユーザの受付順序に基づいて、チケットＡを所望しているユーザのうちから上限人数のユーザを受付対象として選出する。例えば、第１の受付部７６は、チケットＡを所望しているユーザのうちから、上限人数のユーザを、受付順序の早いユーザから順に選出する。

受付対象として選出されたユーザからの申込みの受付が終了した場合、第１の受付部７６は、受付順序設定部７４によって設定された受付順序に基づいて、受付対象として選出されていない所望ユーザのうちから受付対象を新たに選出する。そして、第１の受付部７６は、受付対象として新たに選出されたユーザから申込みを受け付ける。

例えば、チケットＡの申込手続き中のユーザのいずれかが申込手続きを終了し、その結果として、チケットＡの申込手続き中のユーザの人数が上限人数未満になった場合、チケットＡの申込手続き中のユーザの人数が上限人数となるように、第１の受付部７６は、チケットＡの申込みを待機中のユーザのうちのいずれかを、受付順序の早いユーザから順に選出する。そして、第１の受付部７６は、選出されたユーザからのチケットＡの申込みを受け付ける。

第２の受付部７８について説明する。判定部７０によって所望ユーザの人数が上限人数以下であると判定された場合に、第２の受付部７８は各所望ユーザから申込みを受け付ける。すなわち、第２の受付部７８はすべての所望ユーザから申込みを受け付ける。

チケットＡの購入申込みを所望しているユーザ（所望ユーザ）の人数が上限人数以下である場合、第２の受付部７８はチケットＡの購入申込みを所望している全ユーザから申込みを受け付ける。

なお、申込受付システム１は、第１の受付部７６及び第２の受付部７８の両方の機能を備える一つの受付部を含むようにしてもよい。この場合、受付部は、判定部７０の判定結果に基づいて、ユーザからの申込みの受付処理に実行することになる。すなわち、所望ユーザの人数が上限人数以下でないと判定された場合、判定部７０はその旨を示す情報（例えばフラグ情報）を記憶部に記憶する。そして、所望ユーザの人数が上限人数以下でないことを示す情報が記憶されている場合、受付部は、受付順序設定部７４によって設定された受付順序に基づいて、所望ユーザのうちから、上限人数以下のユーザを受付対象として選出し、当該受付対象として選出された各ユーザから申込みを受け付ける。一方、所望ユーザの人数が上限人数以下であると判定された場合、判定部７０はその旨を示す情報（例えばフラグ情報）を記憶部に記憶する。そして、所望ユーザの人数が上限人数以下であることを示す情報が記憶されている場合、受付部は各所望ユーザから申込みを受け付ける。

次に、申込受付システム１で実行される処理について説明する。図１３は、受付制御サーバ１０で所定時間（例えば１分）ごとに実行される処理の一例を示す。図１３に示す処理は受付状況テーブルを更新するための処理である。

図１３に示すように、受付制御サーバ１０の制御部２０は受付状況テーブルにアクセスし、申込手続き中のユーザのうちに、申込制限時間が経過したユーザが存在するか否かを判定する（Ｓ１０１）。

なお、「申込手続き中のユーザ」とは申込状態フラグが「１」であるユーザである。また、申込制限時間が経過したか否かは、受付開始日時から申込制限時間（例えば１０分間）が経過しているか否かを判定することによって判定することが可能である。

申込制限時間が経過したユーザが存在すると判定された場合、制御部２０は、そのユーザからの申込みの受付を中止する。すなわち、制御部２０は受付状況テーブルにアクセスし、そのユーザの申込状態フラグを「３」に更新する（Ｓ１０２）。

図１４〜図１６は、チケット選択画面３０の申込画面ボタン３４が押下された場合に実行される処理の一例を示す。受付制御サーバ１０及び申込受付サーバ１２の各々の制御部２０がプログラムに従って図１４〜図１６に示す処理を実行することによって、図１２に示す機能ブロックが実現される。

チケット選択画面３０の申込画面ボタン３４が押下された場合、図１４に示すように、ユーザ端末３の制御部は申込画面４０の画面データを受付制御サーバ１０に要求する（Ｓ２０１）。この場合、ユーザが所望しているチケットのイベントＩＤ及びチケットＩＤが受付制御サーバ１０に送信される。なお、以降に説明する処理においても、ユーザ端末３から受付制御サーバ１０又は申込受付サーバ１２へのアクセスが行われる場合には、ユーザが所望しているチケットのイベントＩＤ及びチケットＩＤが送信されるようになっている。

上記要求が受付制御サーバ１０によって受信された場合、受付制御サーバ１０の制御部２０（受付順序設定部７４）はユーザの受付順序を設定する（Ｓ２０２）。また、制御部２０はユーザの申込状態フラグを「０」に初期設定する（Ｓ２０３）。

ステップＳ２０２，Ｓ２０３において、制御部２０は新たなレコードを受付状況テーブルに追加する。そして、制御部２０は新たに追加したレコードの各フィールドに下記情報を登録する。

すなわち、制御部２０は、ユーザが所望しているチケットのイベントＩＤ及びチケットＩＤを「イベントＩＤ」及び「チケットＩＤ」フィールドに登録する。また、制御部２０は、ユーザが所望しているチケットと同じチケットを所望しているユーザのうちで、受付順序が最も遅いユーザの受付順序を取得し、その受付順序の一つ後の受付順序を「受付順序」フィールドに登録する。さらに、制御部２０はセッションＩＤを「ＩＤ」フィールドに登録し、値「０」を「申込状態フラグ」フィールドに登録する。

また、制御部２０は受付状況テーブルを参照し、ユーザが所望しているチケットの申込手続き中のユーザの人数（Ｎ）を取得する（Ｓ２０４）。すなわち、制御部２０は、ユーザが所望しているチケットのイベントＩＤ及びチケットＩＤが「イベントＩＤ」及び「チケットＩＤ」フィールドに登録され、かつ、値「１」が「申込状態フラグ」フィールドに登録されているレコードの数を上記人数（Ｎ）として取得する。

そして、制御部２０（判定部７０）は上記人数（Ｎ）が閾値（Ｎｍａｘ）未満であるか否かを判定する（Ｓ２０５）。先述したように、申込受付システム１では、同じチケットの申込みを同時に上限人数以内のユーザから並行して受け付けられるようになっており、この上限人数が閾値（Ｎｍａｘ）として設定される。

例えば、チケットＡの残数が「５０」であり、１人のユーザが購入することが可能なチケットＡの上限数が「５」である場合、制御部２０（上限人数設定部７２）は「１０」をチケットＡの閾値（Ｎｍａｘ）として設定する。なお、チケットの残数はチケットごとに異なるため、閾値（Ｎｍａｘ）はチケットごとに設定される。また、１人のユーザが購入することが可能なチケットの上限数もチケットごとに異なる場合がある。

上記人数（Ｎ）が閾値（Ｎｍａｘ）未満であると判定された場合、制御部２０は、ステップＳ２０２で設定されたユーザの受付順序が、ユーザが所望しているチケットの申込みを待機中のユーザのうちで何番目に早いかを判断する（Ｓ２０６）。ここで、「申込手続き中のユーザ」とは申込状態フラグが「０」であるユーザである。なお、このステップＳ２０６では、ユーザの受付順序が、ユーザが所望しているチケットの申込を待機中のユーザのうちで第ｉ番目に早いと判断されたこととして、以降の処理を説明する。

そして、制御部２０は、ｉ≦Ｎｍａｘ−Ｎの関係が成立しているか否かを判定する（Ｓ２０７）。ｉ≦Ｎｍａｘ−Ｎの関係が成立していると判定された場合、制御部２０（第２の受付部７８）は、ユーザからの申込みの受付を開始するための処理を実行する。

すなわち、制御部２０はユーザの申込状態フラグを「１」に設定し（Ｓ２０８）、ユーザの受付開始日時として現在日時を登録する（Ｓ２０９）。すなわち、制御部２０は受付状況テーブルにアクセスし、セッションＩＤが「ＩＤ」フィールドに登録されているレコードの「申込状態フラグ」フィールドに値「１」を登録し、「受付開始日時」フィールドに現在日時を登録する。

その後、図１５に示すように、制御部２０は申込画面４０の画面データへのリンク情報をユーザ端末３に通知する（Ｓ２１０）。そして、ユーザ端末３の制御部はリンク情報に従って申込画面４０の画面データを申込受付サーバ１２に要求する（Ｓ２１１）。上記要求が申込受付サーバ１２によって受信された場合、申込受付サーバ１２の制御部２０は申込画面４０の画面データをユーザ端末３に送信する（Ｓ２１２）。

なお、申込画面４０の画面データ（ページデータ）には、申込制限時間が経過するまでの残り時間を申込制限時間欄４１に表示するための情報が組み込まれる。例えば、受付開始日時と申込制限時間との組合せが上記情報として組み込まれる。または、申込制限時間が経過する日時が上記情報として組み込まれる。あるいは、現時点から申込制限時間が経過するまでの残り時間が上記情報として組み込まれる。

また、申込画面４０の画面データ（ページデータ）には、申込制限時間欄４１に表示される時間を所定時間（例えば１秒）ごとに更新するためのプログラムが組み込まれる。申込画面４０がユーザ端末３の表示部に表示されている場合には、このプログラムが実行されることによって、申込制限時間欄４１に表示される時間が所定時間（例えば１秒）ごとに更新される。

申込画面４０の画面データがユーザ端末３において受信された場合、ユーザ端末３の制御部は申込画面４０を表示部に表示する（Ｓ２１３）。

図１４のステップＳ２０５において、上記人数（Ｎ）が閾値（Ｎｍａｘ）以上であると判定された場合、又は、ステップＳ２０７において、ｉ≦Ｎｍａｘ−Ｎの関係が成立していないと判定された場合、制御部２０（第１の受付部７６）は、ユーザからの申込みの受付開始を待機させるための処理を実行する。

すなわち、図１６に示すように、制御部２０はユーザの待ち時間を取得する（Ｓ２１４）。例えば、ユーザの受付順序が、ユーザが所望しているチケットの申込みの待機中のユーザのうちで第ｉ番目に早い場合、制御部２０は受付状況テーブルにアクセスし、ユーザが所望しているチケットの申込手続き中のユーザのうちで、受付順序が第ｉ番目に早いユーザの残り時間を、ユーザの待ち時間として取得する。なお、ここで、「残り時間」とは、申込制限時間が経過するまでの残り時間のことを意味している。

また、制御部２０はユーザの受付開始予定日時を取得する（Ｓ２１５）。例えば、制御部２０は、ステップＳ２１４で取得された待ち時間が現在日時から経過する日時を受付開始予定日時として取得する。この場合、制御部２０は受付状況テーブルにアクセスし、セッションＩＤが「ＩＤ」フィールドに登録されているレコードの「受付開始予定日時」フィールドに、取得された受付開始予定日時を登録する。

その後、制御部２０は待機画面５０の画面データをユーザ端末３に送信する（Ｓ２１６）。この場合、待機画面５０の受付順序欄５４にはユーザの受付順序がセットされる。また、受付開始予定日時欄５６にはステップＳ２１５で取得された受付開始所定日時がセットされ、待ち時間欄５８にはステップＳ２１４で取得された待ち時間がセットされる。また、受付状況欄５２には、ユーザが所望しているチケットの申込手続き中のユーザのうちで、受付順序が最も遅いユーザの受付順序がセットされる。

待機画面５０の画面データがユーザ端末３において受信された場合、ユーザ端末３の制御部は待機画面５０を表示部に表示する（Ｓ２１７）。

図１７は、待機画面５０が表示されている場合に実行される処理の一例を示す。待機画面５０の画面データ（ページデータ）には、所定時間（例えば１分）ごとに待機画面５０の更新を受付制御サーバ１０に要求するためのプログラムが埋め込まれている。このため、待機画面５０が表示されている場合、ユーザ端末３の制御部は所定時間ごとに待機画面５０の更新を受付制御サーバ１０に要求する（Ｓ３０１）。

上記要求が受付制御サーバ１０によって受信された場合、受付制御サーバ１０の制御部２０は受付状況テーブルを参照し、ユーザが所望しているチケットの申込手続き中のユーザの人数（Ｎ）を取得する（Ｓ３０２）。そして、制御部２０は上記人数（Ｎ）が閾値（Ｎｍａｘ）以上であるか否かを判定する（Ｓ３０３）。これらのステップＳ３０２，Ｓ３０３は図１４のステップＳ２０４，Ｓ２０５と同様である。

上記人数（Ｎ）が閾値（Ｎｍａｘ）未満であると判定された場合、制御部２０は、ユーザの受付順序が、ユーザが所望しているチケットの申込みを待機中のユーザのうちで何番目に早いかを判断する（Ｓ３０４）。そして、制御部２０は、ｉ≦Ｎｍａｘ−Ｎの関係が成立しているか否かを判定する（Ｓ３０５）。これらのステップＳ３０４，Ｓ３０５は図１４のステップＳ２０６，Ｓ２０７と同様である。

一方、ステップＳ３０３において、上記人数（Ｎ）が閾値（Ｎｍａｘ）以上であると判定された場合や、ステップＳ３０５において、ｉ≦Ｎｍａｘ−Ｎの関係が成立していないと判定された場合、制御部２０は図１６に示す処理（Ｓ２１４〜Ｓ２１６）を実行し、その結果として、ユーザ端末３の表示部に表示される待機画面５０が更新される（Ｓ２１７）。この場合、受付順序がユーザよりも前の他のユーザの申込みの受付完了状況に基づいて、ユーザの待ち時間及び受付開始予定日時が更新され、更新後の待ち時間及び受付開始予定日時がユーザに提示される。

例えば図６に示す状況の場合において、受付順序が「４」であるユーザが受付順序が「３」であるユーザよりも先に申込み手続きを完了すると、受付順序が「１３」であるユーザの申込みの受付が開始される。この場合、受付順序が「１４」であるユーザは待機中のユーザの中で受付順序が最も早くなる。その結果、受付順序が「１４」であるユーザの待ち時間は「３分３０秒」に短縮されることになる。

ステップＳ３０５において、ｉ≦Ｎｍａｘ−Ｎの関係が成立していると判定された場合、制御部２０はユーザの申込状態フラグを「１」に更新し（Ｓ３０６）、ユーザの受付開始日時として現在日時を設定する（Ｓ３０７）。これらのステップＳ３０６，Ｓ３０７は図１４のステップＳ２０８，Ｓ２０９と同様である。

その後、制御部２０は、申込みの受付が開始されたことを通知するための開始画面６０の画面データをユーザ端末３に送信する（Ｓ３０８）。

なお、申込画面４０の画面データと同様、開始画面６０の画面データ（ページデータ）にも、申込制限時間が経過するまでの残り時間を申込制限時間欄６１に表示するための情報や、申込制限時間欄６１に表示される時間を所定時間（例えば１秒）ごとに更新するためのプログラムが組み込まれる。

開始画面６０の画面データがユーザ端末３において受信された場合、ユーザ端末３の制御部は開始画面６０を表示部に表示する（Ｓ３０９）。

開始画面６０が表示されている間、ユーザ端末３の制御部は申込画面ボタン６２が押下されたか否かを監視する。図１８は申込画面ボタン６２が押下された場合に実行される処理の一例を示す。

申込画面ボタン６２が押下された場合、図１８に示すように、ユーザ端末３の制御部は申込画面４０の画面データを受付制御サーバ１０に要求する（Ｓ４０１）。この場合、受付制御サーバ１０の制御部２０は申込画面４０の画面データへのリンク情報をユーザ端末３に通知する（Ｓ４０２）。そして、ユーザ端末３の制御部はリンク情報に従って申込画面４０の画面データを申込受付サーバ１２に要求する（Ｓ４０３）。

上記要求が申込受付サーバ１２によって受信された場合、申込受付サーバ１２の制御部２０はユーザの申込状態フラグが「３」であるか否かを判定する（Ｓ４０４）。

ここで、ユーザの申込状態フラグが「３」である場合とは、開始画面６０の申込画面ボタン６２を押下する前に申込制限時間が経過してしまったことによって、図１３に示す処理によって申込状態フラグが「３」に更新されてしまった場合である。このような場合、制御部２０は、申込みの受付が中止されたことを通知するための中止画面の画面データをユーザ端末３に送信する（Ｓ４０５）。この場合、ユーザ端末３の制御部は中止画面を表示部に表示する（Ｓ４０７）。

一方、ユーザの申込状態フラグが「３」でないと判定された場合、制御部２０は申込画面４０の画面データをユーザ端末３に送信する（Ｓ４０６）。この場合、ユーザ端末３の制御部は申込画面４０を表示部に表示する（Ｓ４０７）。これらのステップＳ４０６，Ｓ４０７は図１５のステップＳ２１２，Ｓ２１３と同様である。

申込画面４０がユーザ端末３の表示部に表示されている間、ユーザ端末３の制御部は申込ボタン４８が押下されたか否かを監視する。図１９は、申込ボタン４８が押下された場合に実行される処理の一例を示す。

申込ボタン４８が押下された場合、図１９に示すように、ユーザ端末３の制御部はチケットの購入処理を申込受付サーバ１２に要求する（Ｓ５０１）。

上記要求が申込受付サーバ１２で受信された場合、申込受付サーバ１２の制御部２０は、ユーザの申込状態フラグが「３」であるか否かを判定する（Ｓ５０２）。

ここで、ユーザの申込状態フラグが「３」である場合とは、申込画面４０の申込ボタン４８を押下する前に申込制限時間が経過してしまったことによって、図１３に示す処理によって申込状態フラグが「３」に更新されてしまった場合である。このような場合、制御部２０は、申込みの受付が中止されたことを通知するための中止画面の画面データをユーザ端末３に送信する（Ｓ５０３）。この場合、ユーザ端末３の制御部は中止画面を表示部に表示する（Ｓ５０７）。

一方、ユーザの申込状態フラグが「３」でないと判定された場合、制御部２０はチケットの購入処理を実行する（Ｓ５０４）。例えば、制御部２０はチケットの発行処理や決済処理を実行する。また、制御部２０はチケットテーブルにアクセスし、チケットの販売済数及び残数を更新する。

その後、制御部２０はユーザの申込状態フラグを「２」に更新する（Ｓ５０５）。すなわち、制御部２０は受付状況テーブルにアクセスし、セッションＩＤが「ＩＤ」フィールドに登録されているレコードの「申込状態フラグ」フィールドの値を「１」から「２」に更新する。

また、制御部２０は、チケットの購入処理の結果を示す結果画面の画面データをユーザ端末３に送信する（Ｓ５０６）。この場合、ユーザ端末３の制御部は結果画面を表示部に表示する（Ｓ５０７）。

以上に説明した申込受付システム１によれば、チケットの残数とチケットを購入しようとしているユーザの数とのつり合いが取れていないような場合であっても、ユーザが購入を円滑に行えるようになっている。例えば、購入のために要求される各種情報を入力し終えたにもかかわらず、チケットを購入できないという事態が生じないようになっている。また例えば、購入申込みの受付を一旦中止し、かつ、例えば「多数のアクセスが集中しております。少し時間が経ってから再度アクセスして下さい。」等のメッセージをユーザに提示するような場合には、ユーザが頃合いを見計らって再度システムにアクセスしなければならなくなるが、申込受付システム１によれば、頃合いを見計らって申込受付システム１にアクセスする必要がなくなる。また、申込を受け付ける側の者にとって、購入のために要求される各種情報を入力し終えたにもかかわらずチケットを購入できないことや、頃合いを見計らって再度システムにアクセスしなければならないこと等に起因する不満をユーザに感じせないように図ることが可能になり、その結果として、ユーザの満足度を向上できるようになるという利点がある。

また、申込受付システム１では、ユーザは待機画面５０に表示される情報を頼りに、申込みの受付が開始されるまでにどのぐらいの時間待てばよいのかを把握できるようになる。すなわち、申込受付システム１によれば、ユーザにとって、申込みの受付が開始されるまでにどのぐらいの時間待てばよいのかが分かるようになるという利点がある。また、申込を受け付ける側の者にとって、申込みの受付が開始されるまでにどのぐらいの時間待てばよいのかが分からないことに起因する不満をユーザに感じせないように図ることが可能になり、その結果として、ユーザの満足度を向上できるようになるという利点がある。

また、申込受付システム１では、ユーザが申込手続きを完了するまでの申込制限時間（例えば１０分間）が定められているため、受付開始予定日時や待ち時間の精度を高めることが可能になる。申込受付システム１によれば、受付開始予定日時になっても受付が開始されないという事態が発生しないように担保されるようになる。

また、申込受付システム１では、待機画面５０に表示される情報が、ユーザよりも受付順序が前である他のユーザからの申込みの受付完了状況に基づいて更新される。例えば、他のユーザが申込制限時間よりも短い時間で申込み手続きを完了した場合には、ユーザに提示される受付開始予定日時及び待ち時間が更新されるようになっている。

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

［１］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている場合において、商品又はサービスの残数に関する情報をユーザに提示するようにしてもよい。例えば、受付制御サーバ１０は、ユーザが所望しているチケットの残数を待機画面５０に表示するようにしてもよい。このようにすれば、受付が開始されるのを待っている間にユーザは所望のチケットの残数を把握できるようになる。

［２］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている場合において、受付順序がユーザよりも前である他のユーザの申込内容に関する情報をユーザに提示するようにしてもよい。例えば、受付制御サーバ１０は、受付順序がユーザよりも前である他のユーザによって購入された、ユーザが所望しているチケットの合計枚数を待機画面５０に表示するようにしてもよい。このようにすれば、受付が開始されるのを待っている間にユーザは所望のチケットの売れ行きを把握できるようになる。

［３］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている場合において、当該ユーザの申込内容に応じた情報を当該ユーザに提示するようにしてもよい。例えば、受付制御サーバ１０は、ユーザが所望しているチケットと同じカテゴリのチケットに関する情報をユーザに提示するようにしてもよい。このようにすれば、受付が開始されるのを待っている間の時間をユーザが有効に活用できるようになる。

［４］例えば、受付制御サーバ１０は、ユーザの待ち時間が閾値以下になった場合にユーザに通知するようにしてもよい。

例えば、受付制御サーバ１０は、ユーザの待ち時間が閾値以下になった場合に、その旨を示す電子メール等をユーザに送信するようにしてもよい。なお、この場合、待機画面５０においてユーザがメールアドレスを入力できるようにすればよい。そして、ユーザによって入力されたメールアドレスに上記の電子メールを送信するようにすればよい。

また例えば、受付制御サーバ１０は、ユーザの待ち時間が閾値以下になった場合にその旨を示すメッセージを表示するようなプログラムを待機画面５０の画面データに組み込んでおくようにしてもよい。

［５］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている間において、当該ユーザが商品又はサービスを予約又は購入することが可能であるか否かを、当該ユーザの受付順序と、当該商品又は当該サービスの残数と、に基づいて判定するようにしてもよい。また、受付制御サーバ１０は判定結果をユーザに通知するようにしてもよい。

［５−１］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている間において、当該ユーザが商品又はサービスを予約又は購入することが可能であるか否かを、当該ユーザの受付順序と、当該商品又は当該サービスの残数と、各ユーザが申し込むことが可能な当該商品又は当該サービスの上限数と、に基づいて判定するようにしてもよい。

例えば、図６に示す状況において、ユーザの受付順序が「１５」である場合を想定する。また、一人のユーザが購入可能なチケットの上限枚数が５枚である場合を想定する。

この場合、申込手続き中のユーザは１０人であり、待機中のユーザのうち、受付順序が「１５」よりも早いユーザの人数は２人である。すなわち、ユーザよりも早くチケットを購入することが可能なユーザの人数は１２人であるため、ユーザよりも先に購入され得る最大枚数は６０枚である。

この場合、チケットの残数が上記最大枚数より多ければ、ユーザはチケットを購入することが可能であるため、受付制御サーバ１０は、チケットを購入可能である旨をユーザに通知するようにしてもよい。

一方、チケットの残数が上記最大枚数以下であれば、ユーザがチケットを購入できなくなる可能性があるため、受付制御サーバ１０は、チケットを購入できない可能性がある旨をユーザに通知するようにしてもよい。なお、この場合、チケットの残数と上記最大枚数との差が大きいほど、ユーザがチケットを購入できない可能性が高くなる。このため、チケットの残数と上記最大枚数との差に基づいて、ユーザがチケットを購入できなくなる可能性の高さを示す指標をユーザに提示するようにしてもよい。

［５−２］例えば、受付制御サーバ１０は、ユーザからの申込みの受付が待機されている間において、当該ユーザが商品又はサービスを予約又は購入することが可能であるか否かを、当該ユーザの受付順序と、当該商品又は当該サービスの残数と、各ユーザが申し込むことが可能な当該商品又は当該サービスの下限数と、に基づいて判定するようにしてもよい。

例えば、図６に示す状況において、ユーザの受付順序が「１５」である場合を想定する。また、一人のユーザが購入可能なチケットの下限枚数が１枚である場合を想定する。

この場合、申込手続き中のユーザは１０人であり、待機中のユーザのうち、受付順序が「１５」よりも早いユーザの人数は２人である。すなわち、ユーザよりも早くチケットを購入することが可能なユーザの人数は１２人であるため、ユーザよりも先に購入され得る最小枚数は１２枚である。

この場合、チケットの残数が上記最小枚数以下であれば、ユーザはチケットを購入することができないため、受付制御サーバ１０は、チケットを購入することができない旨をユーザに通知するようにしてもよい。

一方、チケットの残数より上記最小枚数より多ければ、ユーザはチケットを購入できる可能性があるため、受付制御サーバ１０は、チケットを購入できる可能性がある旨をユーザに通知するようにしてもよい。なお、この場合、チケットの残数と上記最小枚数との差が大きいほど、ユーザがチケットを購入できる可能性が高くなる。このため、チケットの残数と上記最小枚数との差に基づいて、ユーザがチケットを購入できる可能性の高さを示す指標をユーザに提示するようにしてもよい。

［６］例えば、ユーザからの申込みの受付が開始される前において、受付制御サーバ１０（数量取得手段）は、ユーザが所望する数量（商品又はサービスの数量）を取得するようにしてもよい。すなわち、受付制御サーバ１０は、ユーザが所望するチケットの枚数を当該ユーザから取得するようにしてもよい。例えば、チケット選択画面３０においてユーザが所望の枚数も指定できるようにしてもよい。または、待機画面５０においてユーザが所望の枚数を指定できるようにしてもよい。

［６−１］例えば、受付制御サーバ１０は、ユーザが所望しているチケットの残数と、ユーザが所望している枚数と、の差が所定の閾値以下になった場合に、その旨をユーザに通知するようにしてもよい。このようにすれば、受付が開始されるのを待っている間において、ユーザが所望しているチケットの残数がユーザが所望している枚数に近づいていることをユーザは把握できるようになる。

［６−２］また例えば、受付制御サーバ１０は、ユーザが所望しているチケットの残数と、ユーザが所望している枚数と、残っている座席の隣接状況と、に基づいて、ユーザへの通知を実行するようにしてもよい。すなわち、受付制御サーバ１０は、ユーザが所望している数の隣り合う座席（すなわち、ユーザが所望している数の横一列に連続して並んだ座席）が残っているか否かを判定し、その判定結果をユーザに通知するようにしてもよい。

複数のチケットを所望するユーザは複数の隣り合う座席を希望するのが一般的である。この点、以上のようにすれば、受付が開始されるのを待っている間において、ユーザが所望している数の隣り合う座席が残っているか否かをユーザは把握できるようにすることが可能になる。

［６−３］例えば、上限人数設定部７２は、同じチケットの購入申込みを同時に並行して受け付けることが可能なユーザの上限人数を、申込みの受付が開始される前において指定されるユーザの所望の枚数に基づいて変化させるようにしてもよい。

ここで、図２０に示すような状況を想定する。なお、チケットの残数は５０枚であると想定する。図２０において、「所望枚数」は、チケット選択画面３０（又は待機画面５０）において各ユーザが指定した所望の枚数である。

この場合、申込手続き中の１０人のユーザが事前に指定した所望の枚数の合計は４２枚である。また、待機中の３人のユーザのうち、受付順序が最も高いユーザが事前に指定した所望の枚数は４枚であり、受付順序が第２番目に高いユーザが事前に指定した所望の枚数は３枚である。これらの枚数の合計は４９枚であり、チケットの残数（５０枚）よりも少ない。

このような場合、上限人数設定部７２は、上限人数を１０人よりも１２人に増やすことによって、受付順序が「１３」及び「１４」であるユーザからの申込みの受付も開始されるようにしてもよい。すなわち、上限人数設定部７２は、所望の枚数の合計がチケットの残数以下になるようにして、上記上限人数を増やすようにしてもよい。

また、この場合、受付制御サーバ１０は、受付開始予定日時及び待ち時間を上記上限人数の変化に基づいて更新するようにしてもよい。

例えば、上述の場合、受付順序が「１３」及び「１４」であるユーザからの申込みの受付が開始されることによって、受付順序が「１５」であるユーザは、待機中のユーザのうちで受付順序が最も高いユーザになる。このため、受付制御サーバ１０は、受付順序が「１５」であるユーザを待ち時間を「４分１５秒」から「３分３０秒」に更新するようにしてもよい。

［６−４］また例えば、上限人数設定部７２は、同じチケットの購入申込みを同時に並行して受け付けることが可能なユーザの上限人数を、申込みの受付が開始される前において指定されるユーザの所望の枚数と、残っている座席の隣接状況と、に基づいて変化させるようにしてもよい。

例えば、上限人数設定部７２は、所望の枚数を購入できるユーザの数が最も多くなるようにして、ユーザの上限人数を設定するようにしてもよい。

ここで、１３個の隣り合う座席（すなわち、横一列に連続して並んだ１３個の座席）が残っており、１枚のチケットを所望する５人のユーザと、２枚のチケットを所望する６人のユーザとが存在している場合を想定する。なお、各ユーザに割り当てる座席は申込受付システム１側で自動的に決定されるものとする。

このような場合、１枚のチケットを所望する１人のユーザと、２枚のチケットを所望する６人のユーザとがチケットを購入することが可能である（ケースＡ）。または、１枚のチケットを所望する３人のユーザと、２枚のチケットを所望する５人のユーザとがチケットを購入することも可能である（ケースＢ）。あるいは、２枚のチケットを所望する４人のユーザと、１枚のチケットを所望する５人のユーザとがチケットを購入することも可能である（ケースＣ）。

ケースＡでは７人のユーザがチケットを購入できることになり、ケースＢでは８人のユーザがチケットを購入できることになる。また、ケースＣでは９人のユーザがチケットを購入できることになる。

このような場合、上限人数設定部７２は、所望の枚数を購入できるユーザの数が最も多くなるようにして、ユーザの上限人数を設定するようにしてもよい。すなわち、上記の例の場合には、上限人数設定部７２は、所望の枚数を購入できるユーザの数が最も多くなるようにして、ユーザの上限人数を「９」に設定するようにしてもよい。

また、上記のような場合、受付順序設定部７４は、所望の枚数を購入できるユーザの数が最も多くなるようにして、ユーザの受付順序を設定することになる。すなわち、上記の例の場合には、受付順序設定部７４は、２枚のチケットを所望する４人のユーザと、１枚のチケットを所望する５人のユーザとの受付順序を他のユーザよりも早く設定することになる。

なお、ユーザが所望の座席を指定できるようになっている場合には、１枚のチケットを所望するユーザ達が１つの座席が間に入るようにして座席を選択してしまう場合があり、その結果として、２枚のチケットを所望するユーザが２つの隣り合う座席のチケットを購入できなくなってしまう場合がある。このため、上記の例の場合に、受付順序設定部７４は、２枚のチケットを所望する４人のユーザの受付順序を、１枚のチケットを所望する５人のユーザよりも早く設定するようにしてもよい。そして、２枚のチケットを所望する４人のユーザの申込手続きが完了した後で、１枚のチケットを所望する５人のユーザからの申込みの受付を開始するようにしてもよい。なお、各ユーザに割り当てる座席が申込受付システム１側で自動的に決定されるようになっている場合には、このような受付順序の設定について考慮する必要はない。

以上のようにすれば、なるべく多くのユーザが所望の枚数のチケットを購入できるようにすることが可能になる。

［７］例えば、受付制御サーバ１０は、イベント会場の座席表を待機画面５０に表示するようにしてもよい。また、受付制御サーバ１０はチケット（座席）の現在の購入状況を座席表に反映させるようにしてもよい。例えば、受付制御サーバ１０は、すでに購入された座席と、まだ購入されていない座席と、を区別して表示するようにしてもよい。なお、上述の変形例６のように、ユーザが所望する枚数を事前に取得する場合には、ユーザが所望する数の隣接する席を座席表において区別表示するようにしてもよい。このようにすれば、受付が開始されるのを待っている間の時間をユーザが有効に活用できるようになる。

［８］例えば、待機画面５０においてユーザが決済方法や引取方法を指定できるようにしてもよい。このようにしても、受付が開始されるのを待っている間の時間をユーザが有効に活用できるようになる。

［９］例えば、以上に説明した実施形態では、一人のユーザが購入可能なチケットの上限枚数（固定値：例えば５枚）を用いて、受付開始予定日時等を取得するようになっていたが、ユーザごとに、そのユーザが購入しそうな枚数をそのユーザの過去の購入履歴に基づいて推測するようにしてもよい。例えば、ユーザが過去に購入した枚数の統計値（例えば最大値又は平均値）を推測枚数として取得するようにしてもよい。そして、このようにして取得された推測枚数を上記上限枚数の代わりに用いるようにしてもよい。

［１０］例えば、以上に説明した実施形態では、申込制限時間（固定値：例えば１０分間）を用いて、受付開始予定日時等を取得するようになっていたが、ユーザごとに、申込手続きに要する時間をそのユーザの過去の購入履歴に基づいて推測するようにしてもよい。例えば、ユーザの過去の申込手続き時間の統計値（例えば最大値又は平均値等）を推測時間として取得するようにしてもよい。そして、このようにして取得された推測時間を上記申込制限時間の代わりに用いるようにしてもよい。ただし、この場合、各ユーザの過去の申込手続き時間の履歴をデータベース１４に保存しておく必要がある。

［１１］例えば、以上に説明した実施形態では、待機画面５０が表示されている間において、ユーザ端末３から受付制御サーバ１０に所定時間（例えば１分）ごとに待機画面５０の更新を要求するようになっていた。しかしながら、待機画面５０の更新が必要であるか否かを受付制御サーバ１０側で判断し、待機画面５０の更新が必要になったタイミングで、受付制御サーバ１０からユーザ端末３に待機画面５０の画面データをプッシュ送信するようにしてもよい。

［１２］なお、以上に説明した実施形態では、図１４のステップＳ２０５における閾値（Ｎｍａｘ）を、所望の枚数のチケットを購入できないユーザが生じてしまわないようにするとの観点によって設定するようになっていたが、申込受付システム１の処理負荷が大きくなりすぎないようにするとの観点によって上記閾値（Ｎｍａｘ）を設定するようにしてもよい。

［１３］例えば、受付順序設定部７４は、所定の属性条件を満足するユーザに優先的に早い順序を設定するようにしてもよい。または、受付順序設定部７４は、所定の属性条件を満足するユーザに遅い順序を設定するようにしてもよい。

ここで、「属性条件」とは、ユーザの属性情報（例えば、居住地、性別、職業、過去の申込回数、優先フラグ、ブラックリストフラグ等）に関する条件である。なお、「優先フラグ」は、優先すべきユーザであるか否かを示す情報であり、「ブラックリストフラグ」は、警戒又は注意を払うべきユーザであるか否かを示す情報である。

例えば、属性条件は申込受付システム１の管理者によって設定される。また例えば、属性条件は商品又はサービスの内容を考慮して設定される。

例えば、「過去の申込回数が閾値以上である」との属性条件が設定された場合、受付順序設定部７４は、過去の申込回数が閾値以上であるユーザの受付順序を、過去の申込回数が閾値未満であるユーザよりも早い順序に設定する。

また例えば、「居住地がイベントの開催地域である」との属性条件が設定された場合、受付順序設定部７４は、居住地がイベントの開催地域であるユーザの受付順序を、居住地がイベントの開催地域でないユーザよりも早い順序に設定する。

また例えば、「ブラックリストフラグがオンである」との属性条件が設定された場合、受付順序設定部７４は、ブラックリストフラグがオンであるユーザの受付順序を、ブラックリストフラグがオンでないユーザよりも遅い順序に設定する。

以上のような受付順序設定部７４によれば、特定のユーザからの申込みを優先的に受け付けるようにしたり、特定のユーザからの申込みを受け付け難くしたりすることが可能になる。なお、以上のような受付順序設定部７４を実現するためには、ユーザが属性条件を満足するか否かを判定するために必要な属性情報（例えば、居住地、性別、職業、過去の申込回数、優先フラグ、ブラックリストフラグ等）をデータベース１４に記憶しておく必要がある。

［１４］以上では、チケットの購入の申込みを受け付ける場合について主に説明したが、本発明は、チケット以外の商品の購入の申込みを受け付ける場合にも適用することが可能である。また、本発明は、商品の予約の申込みを受け付ける場合にも適用することが可能である。さらに、本発明は、サービスの購入又は予約の申込みを受け付ける場合にも適用することが可能である。

１ 申込受付システム、２ 通信ネットワーク、３ ユーザ端末、１０ 受付制御サーバ、１２ 申込受付サーバ、１４ データベース、２０ 制御部、２２ 記憶部、２４ 光ディスクドライブ部、２６ 通信部、３０ チケット選択画面、３２ オプションボタン、３４ 申込画面ボタン、４０ 申込画面、４２ 枚数欄、４４ 決済方法欄、４６ 引取方法欄、４８ 申込ボタン、５０ 待機画面、５２ 受付状況欄、５４ 受付順序欄、５６ 受付開始予定日時欄、５８ 待ち時間欄、６０ 開始画面、６１ 申込制限時間欄、６２ 申込画面ボタン、７０ 判定部、７２ 上限人数設定部、７４ 受付順序設定部、７６ 第１の受付部、７８ 第２の受付部。

Claims (7)

1. 同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定手段と、
   前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定手段と、
   前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける受付手段と、
   を含み、
   前記判定手段は、前記商品又はサービスの残数に基づいて、前記上限人数を設定する上限人数設定手段を含む、
   ことを特徴とする申込受付システム。
2. 請求項１に記載の申込受付システムにおいて、
   前記所望ユーザの人数が前記上限人数以下であると判定された場合、各前記所望ユーザから申込みを受け付ける手段を含む、
   ことを特徴とする申込受付システム。
3. 請求項１又は２に記載の申込受付システムにおいて、
   前記上限人数設定手段は、前記商品又はサービスの残数と、一人のユーザが申込み可能な前記商品又はサービスの上限数と、に基づいて、前記上限人数を設定する、
   ことを特徴とする申込受付システム。
4. 請求項１又は２に記載の申込受付システムにおいて、
   前記所望ユーザが所望する前記商品又はサービスの数量を、当該所望ユーザからの申込みの受付が開始される前において取得する数量取得手段を含み、
   前記上限人数設定手段は、前記商品又はサービスの残数と、前記数量取得手段の取得結果と、に基づいて、前記上限人数を設定する、
   ことを特徴とする申込受付システム。
5. 請求項１乃至４のいずれかに記載の申込受付システムにおいて、
   前記受付手段は、前記受付対象として選出されたユーザからの申込みの受付が終了した場合に、前記受付対象として選出されていない前記所望ユーザのうちから前記受付対象を前記受付順序に基づいて新たに選出し、前記受付対象として新たに選出されたユーザから申込みを受け付ける、
   ことを特徴とする申込受付システム。
6. 同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定ステップと、
   前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定ステップと、
   前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける受付ステップと、
   を含み、
   前記判定ステップは、前記商品又はサービスの残数に基づいて、前記上限人数を設定する上限人数設定ステップを含む、
   ことを特徴とする申込受付システムの制御方法。
7. 同一商品又はサービスの予約又は購入の申込みを所望している所望ユーザの人数が上限人数以下であるか否かを判定する判定手段、
   前記所望ユーザから申込みを受け付ける場合の受付順序を設定する受付順序設定手段、及び、
   前記所望ユーザの人数が前記上限人数以下でないと判定された場合、前記所望ユーザのうちから、前記受付順序に基づいて、前記上限人数以下のユーザを受付対象として選出し、前記受付対象として選出された各ユーザから申込みを受け付ける受付手段、
   としてコンピュータを機能させ、
   前記判定手段は、前記商品又はサービスの残数に基づいて、前記上限人数を設定する上限人数設定手段を含む、
   ことを特徴とするプログラム。

Images