JP2011039865A - 予約システム - Google Patents

Abstract

【課題】複数の予約希望に対して、要求するサービス内容に基づいて優先度を判断して勝者を確定し、敗者についてはサービス内容を含む代替条件を考慮して予約を調整する予約システムを提供する。
【解決手段】属性が異なる予約対象を複数有するサービスに対して、予約希望を先着順に調整して割り当てる予約システム１００であって、予約希望を受け付けて受付状況ＤＢ１０１に記録する予約受付部１１０と、優先度を算出し、予約希望の利用順位を決定して予約状況ＤＢ１０２に記録する予約処理部１２０と、予約表示部１４０とを有し、予約受付部１１０は、予約希望を受付状況ＤＢ１０１に記録する際に代替条件の指定を合わせて記録し、予約処理部１２０は、利用順位を決定する際に全ての予約希望の所要時間が予約対象のサービス提供可能量を超える場合は、最後尾の予約希望の内容を代替条件のサービスの内容に限定し、なお超える場合は他の予約対象に振り替える。
【選択図】図１

Description

本発明は、美容室など、属性がそれぞれ異なる予約対象を複数有するサービスに対する利用予約を受け付ける技術に関し、特に、同一の予約対象に対する複数の予約希望に対して、利用者（予約者）の要求するサービス内容に基づいて予約を調整して割り当てる予約システムに適用して有効な技術に関するものである。

例えばレストランやマッサージなどのサービスについては、利用者はできるだけ早期の利用を求めて利用予約（利用順位の予約）を行う場合がある。この場合、一般的には、現在の待ち人数と標準利用時間等からおおよその予約時間（利用可能時間）を決定して予約者に提示することが行われる。また、美容室や会議室など、できるだけ早期の利用という要求に加えて特定の日時を指定してサービスの利用予約が行われる場合がある。

これらにおいて、予約を受け付けるサービス提供者では、予約を手動により管理するかシステム的に管理するかに関わらず、同一の予約対象（および同一の時間帯）に対する予約希望については先着順に予約（利用順位）を割り当てるのが一般的である。このとき、後から予約を行う利用者は、所望の予約対象（および時間帯）が既に予約されている場合は、空いている他の予約対象（もしくは他の時間帯）を選択して予約するか、利用をあきらめることになる。

これに対し、例えば、再公表２００５−９８７００号公報（特許文献１）には、予約サーバが予約者端末から予約情報を受信すると、予約希望の商品を指定する予約希望候補の数や予約を確定する期限を指定する予約決定希望時間に基づいて割り引いた予約価格を算出し、予約希望候補の内の１つを暫定的な仮予約に割り当て、他の候補を更に暫定的な予備予約に割り当てる。仮予約割当に対して予約決定希望時間までに、後着の予約希望者から割増設定された予約価格での予約希望があった場合には、仮予約割当を予備予約割当の候補の１つに変更し、元の仮予約割当を後着の予約希望者の予約割当とすることにより、予約希望者の予約希望や先着の予約状況に応じて適切な予約価格が提示され、予約者が希
望する商品の予約を行うことができる予約処理を実現する方法および予約処理システムが記載されている。

再公表２００５−９８７００号公報

従来技術の予約方法では、予約対象について受け入れ可能な他の候補を指定した予約希望を可能とし、割増価格（もしくは特別の会員など）による後着の予約希望があった場合は、こちらを優先させるとともに、先着の予約希望については他の予約希望候補に割り当てる。また、予約希望者の数に応じて標準予約価格を変動させる。これらにより、需要と供給の調整と適切な価格の設定を行うことができる。

しかしながら、従来技術では、競合する先着と後着の予約対象は例えばホテルの部屋など基本的に同一であるのに対し、例えば、美容室の予約などのように、同じ予約対象（美容師）に対する先着と後着の重複する予約であっても、そのサービス内容（カット、パーマ等）や全体の時間帯はそれぞれ異なる場合がある。このような場合、例えば、一つの予約であっても、特定のサービス内容だけは最低限希望するなど受け入れ可能な代替条件が存在する場合があり、このような予約希望を他の候補に割り当てる際には、代替条件の内容に応じて柔軟な割り当てが可能な場合もある。

そこで本発明の目的は、属性がそれぞれ異なる予約対象（例えば美容師など）を複数有するサービスに対する利用予約を受け付ける際に、同一の予約対象に対する複数の予約希望に対して、利用者（予約者）の要求するサービス内容（利用者の属性、利用料金を含む）に基づいて優先度を判断して勝者を確定し、敗者についてはサービス内容を含む代替条件を考慮して予約（利用順位位）を調整し割り当てる予約システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による予約システムは、属性がそれぞれ異なる予約対象を複数有するサービスに対して、複数の利用者からの予約希望を受け付け、これらの予約希望を先着順に調整して予約を割り当てる予約システムであって、以下の特徴を有するものである。

すなわち、前記利用者からの前記予約対象に対する前記予約希望を受け付け、前記予約希望の内容を受付状況データベースに記録し、さらに、クライアント端末を利用した前記利用者からの要求に対して、前記受付状況データベースから現在の前記利用者による前記予約希望の内容を取得して前記クライアント端末に出力する予約受付部と、前記受付状況データベースに記録された前記予約希望に係る前記利用者の情報、および前記予約希望の内容に基づいて、所定の基準により前記予約希望についての優先度を算出し、前記優先度の値に応じて、前記予約対象についての前記各予約の中での前記予約希望の利用順位を決定して、前記利用順位の位置に新たな前記予約として挿入して割り当て、割り当てた結果に基づいて予約状況データベースに記録する予約処理部と、前記クライアント端末を利用した前記利用者からの要求に対して、前記予約状況データベースから現在の前記予約対象毎の前記予約の状況を取得して前記クライアント端末に出力する予約表示部とを有する。

また、前記予約受付部は、前記予約希望を受け付けて前記受付状況データベースに記録する際に、前記予約希望が満たされなかった場合に代替として最低限希望するサービスの内容を含む代替条件の指定を合わせて記録し、前記予約処理部は、第１の予約希望についての前記利用順位を決定して新たな前記予約として挿入して割り当てる際に、前記第１の予約希望に係る第１の予約対象について当該時点で割り当てられている全ての前記予約希望に係るサービスの総量が前記第１の予約対象のサービス提供可能量を超える場合は、前記利用順位の最後尾の前記予約者に係る第２の予約希望の内容を、前記受付状況データベースに記録された前記代替条件のサービスの内容に限定し、限定した内容によってもなお前記第１の予約対象について当該時点で割り当てられている全ての前記予約希望に係るサービスの総量が前記第１の予約対象のサービス提供可能量を超える場合は、前記第２の予約希望を他の第２の予約対象に振り替えることを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、予約対象に対して利用者ができるだけ早期の利用を求めて利用予約を行う場合に、従来の先着順での利用順位の決定に加えて、利用者・予約者毎に優先度を決定し、優先度が高い利用者が後着で予約を行った場合には、当該利用者よりも優先度が低い予約者に優先して早い利用順位を割り当てることができる。

さらに、新規予約の受け付けにより予約対象のサービス提供可能量を超える場合は、利用順位が最後尾の予約者について担当者の変更・振り替えを行うことができ、その際に、予約者が希望するサービスの代替条件を考慮して、サービス単位で分割して他の担当者に振り替えることができる。これらにより、予約対象についての需要と供給のバランスを調整して待ち時間の緩和を図りつつ、利用者・予約者の要望により一層柔軟に応えた形で予約を割り当てることが可能となる。

本発明の実施の形態１である予約システムの構成例の概要を示した図である。 本発明の実施の形態１における、ある１営業日の現在時刻以降の利用順位の予約の調整・割り当ての例について概要を示した図である。 本発明の実施の形態１におけるユーザＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態１におけるサービスＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態１における予約対象ＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態１における受付状況ＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態１における予約状況ＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態１における利用順位の予約の調整・割り当ての処理の例について示したフローチャートである。 本発明の実施の形態２における、ある１営業日の利用時間帯の予約の調整・割り当ての例について概要を示した図である。 本発明の実施の形態２における受付状況ＤＢのデータ構成と具体的なデータの例を示した図である。 本発明の実施の形態２における利用時間帯の予約の調整・割り当ての処理の例について示したフローチャートである。 本発明の実施の形態２における利用時間帯が競合する場合の処理の詳細な例について示したフローチャートである。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜実施の形態１＞
本発明の実施の形態１である予約システムは、属性がそれぞれ異なる予約対象を複数有するサービス（物の利用を含む）として、例えばマッサージ（マッサージ担当者）やカラオケボックス（個々の部屋）など、利用者ができるだけ早期の利用を求めて利用予約（利用順位の予約）を行うものに対して、複数の利用者からの予約希望を受け付け、これらの予約希望を調整して予約を割り当てるシステムである。

本実施の形態では基本的に、従来の予約方法と同様に予約対象（例えばマッサージ担当者）毎に先着順にて予約を割り当てる。このとき、例えば、現在の待ち人数とサービスの標準的な利用時間等からおおよその予約時間（利用可能時間）を決定して予約者に提示してもよい。

さらに、本実施の形態では、利用者・予約者毎に優先度を決定し、優先度が高い利用者が後着で予約を行った場合には、当該利用者よりも優先度が低い予約者に優先して早い利用順位を割り当てることを可能とする。また、利用順位が低下した予約者については、さらに割増料金を払うなどにより優先度を上げて利用順位を上げることを可能とする。

［概要］
図２は、本実施の形態の予約システムにおける、ある１営業日の現在時刻以降の利用順位の予約の調整・割り当ての例について概要を示した図である。ここではマッサージ店を例として、属性（例えば提供可能なサービスメニューやスキル）が異なる担当者Ａ（例えば上級のマッサージ師）、Ｂ（例えば通常のマッサージ師）に対してａ、ｂ、ｃ、…の各利用者がそれぞれ利用順位の予約を行うものとする。

上段の図では、まず、１〜５の数字で示された順に各利用者が新規予約を行った状況を示している。ここでは、ａ〜ｅの各予約者は、それぞれ担当者Ａ、Ｂについての標準の利用料金を支払うものとして予約しており、他の属性を考慮しても各予約者の優先度は全て「低」で同じであるものとしている。従って、ここでは先着順で利用順位を決定している。なお、図２の例では優先度を「高」、「中」、「低」として区分しているが、これに限らず、例えば利用料金や要求するサービスの内容、利用者が常連であるかなどの利用者の属性等を考慮して点数化して判断してもよい。

中段の図では、上段の図で先頭の利用順位であった予約者ａとｃがそれぞれサービスの提供を受けており、そこに６番目の処理として優先度が「高」である利用者ｆが新規予約を行っている。利用者ｆについては当該時点での他の予約者（ｂ、ｄ）よりも優先度が高いため、先頭の利用順位を割り当てている。また、７番目の処理として優先度が「低」の利用者ｇが新規予約を行っている。また、８番目の処理として優先度が「中」の利用者ｈが新規予約を行っている。利用者ｈについては当該時点での他の予約者（ｂ、ｄ、ｇ）よりも優先度が高いが、予約者ｆよりも優先度が低いため、予約者ｆの次の利用順位を割り当てている。また、９番目の処理として優先度が「低」の利用者ｉが新規予約を行っている。

下段の図では、中段の図で先頭の利用順位であった予約者ｆ、ｅがそれぞれサービスの提供を受けており、そこで１０番目の処理として低順位であった予約者ｄが割増料金を支払う申し込みをして優先度を「低」から「高」に上げている。これにより予約者ｄについては当該時点での他の予約者（ｈ、ｂ、ｇ）よりも優先度が高くなるため、先頭の利用順位を割り当てている。また、１１番目の処理として優先度が「低」の利用者ｋが新規予約を行っている。

さらに１２番目の処理としてＶＩＰ会員であり優先度が「高」である利用者ｊが新規予約を行っている。利用者ｊについては利用者ｄよりも優先度が高いと判断し、先頭の利用順位を割り当てている。このとき、利用順位の最後尾の予約者ｋについては、担当者Ａのある１営業日でのサービス提供可能量を超えてオーバーフローしている。従って、予約者ｋについては特に要望がない限り、別の担当者Ｂに担当者を変更して利用順位を割り当てる。

ここで、例えば、予約者ｋが担当者Ａ以外は許容しないという場合は、予約を不可として取り消す等の処理を行う。また、例えば、担当者Ｂの予約者の数が一定期間所定のレベルより少ないような場合は、担当者Ｂの標準利用料金を所定の基準に従って下げるなどの処理を行うことも可能である。

［システム構成］
図１は、本実施の形態の予約システムの構成例の概要を示した図である。予約システム１００は、コンピュータシステムによって構成されるサーバによって実現され、例えば、ソフトウェアプログラムによって実装された予約受付部１１０、予約処理部１２０、イベント監視部１３０、予約表示部１４０の各部と、受付状況ＤＢ１０１、予約状況ＤＢ１０２、ユーザＤＢ１０３、サービスＤＢ１０４、予約対象ＤＢ１０５の各データベースを有する。

また、予約システム１００には、インターネット等のネットワーク２００を介してＰＣや携帯電話等のクライアント端末３００が接続されている。サービスの利用予約を行う利用者は、これらクライアント端末３００上で、例えばＷｅｂブラウザ等のソフトウェアを利用して、予約システム１００上の図示しないＷｅｂサーバプログラムを介して予約受付部１１０や予約表示部１４０にアクセスし、サービスの予約状況などを確認しながら利用予約を行う。また、サービス提供者（例えばマッサージ店など）の担当者等は、クライアント端末３００もしくは予約システム１００が有する図示しない入出力装置等を利用して予約状況の確認等を行う。

予約受付部１１０は、各利用者からの予約希望を受け付け、予約の内容（希望担当者やサービスの内容など）を受付状況ＤＢ１０１に記録する。また、例えばクライアント端末３００からの利用者・予約者からの要求に対して、受付状況ＤＢ１０１から現在の当該利用者・予約者の予約希望の内容を取得して出力する。予約処理部１２０は、受付状況ＤＢ１０１に記録された予約希望について、上述の図２に示したように利用順位や担当者を調整して予約の割り当てを行い、割り当てた予約を担当者毎に予約状況ＤＢ１０２に記録する。

イベント監視部１３０は、予約処理部１２０が受付状況ＤＢ１０１に記録された予約希望についての調整・割り当てを行う際のトリガを生成する。例えば、予約処理部１２０が予約希望についての調整を例えば所定の時間間隔毎に締めて行うような場合に、タイマー等を監視して所定のタイミングで予約処理部１２０に対してトリガを発生する。予約表示部１４０は、例えばクライアント端末３００を利用した利用者・予約者からの要求に対して、予約状況ＤＢ１０２から現在の担当者毎の予約状況を取得して出力する。

なお、ユーザＤＢ１０３は、予約システム１００を利用してオンライン予約をすることができる登録ユーザ（利用者）の情報を保持しているマスタテーブルである。また、サービスＤＢ１０４は、利用者がオンライン予約することができるサービスの内容（メニュー）の情報を保持しているマスタテーブルである。同様に、予約対象ＤＢ１０５は、利用者がサービスのオンライン予約の際に指定することができる予約対象（本実施の形態では各担当者）の情報を保持しているマスタテーブルである。

［データ構成］
図３は、ユーザＤＢ１０３のデータ構成と具体的なデータの例を示した図である。ユーザＤＢ１０３は、例えば、ユーザＩＤ、ユーザ名、優先ポイント、および最終来店日時などの項目を有する。ユーザＩＤ、ユーザ名の項目は、予約システム１００を利用してオンライン予約をすることができるようユーザ登録している利用者を識別する情報を保持する。

優先ポイントの項目は、対象のユーザの優先度をポイントとして計算したものを保持する。この優先ポイントは、例えば来店回数や利用料金に応じた加算や、他の条件によって加算されるようにすることができ、ＶＩＰ会員等の利用者であるか否かの判定にも利用することができる。また、最終来店日時の項目は、前回の来店時についての情報を保持する。例えば、最終来店日時と今回の来店日時との差分によって来店頻度を判断し、優先ポイントを加算してもよい。なお、来店頻度を判断する手法はこれに限らず、一定期間の来店回数など、他の項目を保持してこれらの情報を利用することも当然可能である。

図４は、サービスＤＢ１０４のデータ構成と具体的なデータの例を示した図である。サービスＤＢ１０４は、例えば、サービスＩＤ、サービス名、標準所要時間、標準料金、およびランクなどの項目を有する。サービスＩＤ、サービス名の項目は、予約システム１００を利用して利用者がオンライン予約することができるサービスを識別する情報を保持する。標準所要時間、標準料金の項目は、対象のサービスの提供に要する標準の所要時間、および標準の料金の情報を保持する。また、ランクの項目は、対象のサービスを提供する際における難易度等をランク付けした情報を保持する。このランクにより、例えば、対象のサービスを提供可能な担当者を限定することができる。

図５は、予約対象ＤＢ１０５のデータ構成と具体的なデータの例を示した図である。予約対象ＤＢ１０５は、例えば、担当者ＩＤ、担当者名、可能サービス、およびランクなどの項目を有する。担当者ＩＤ、担当者名の項目は、予約システム１００を利用して利用者がサービスをオンライン予約する際に指定することができる担当者を識別する情報を保持する。可能サービスの項目は、対象の担当者毎の提供可能なサービスの種別の情報を保持する。また、ランクの項目は、対象の担当者のスキルレベル等をランク付けした情報を保持する。このランクにより、例えば、図２の下段の図で示したように予約希望の担当者を変更する際に、できるだけランクの近い（もしくは高い）担当者に変更するというようなことも可能である。

図６は、受付状況ＤＢ１０１のデータ構成と具体的なデータの例を示した図である。受付状況ＤＢ１０１は、予約受付部１１０によって各利用者から受け付けた予約希望の内容を保持するデータベースである。受付状況ＤＢ１０１は、例えば、受付ＩＤ、ユーザＩＤ、予約内容としての、日付、担当者、サービス、追加料金の各項目、代替条件としての日付、担当者、サービスの各項目、および予約結果などの項目を有する。

受付ＩＤは、予約受付部１１０によって受け付けた各予約希望を識別する情報を保持する。ユーザＩＤの項目は、対象の予約希望の予約を行った利用者のユーザＩＤの情報を保持する。予約内容の項目は、対象の予約希望の内容を示す情報を保持する。日付、担当者、サービスの各項目は、予約対象の希望日、指定する担当者、希望するサービスの情報を保持する。ここで、例えば担当者の項目での「＊」の指定は、個別の担当者を指定する要望が特にない、すなわちいずれの担当者でもよいことを示す。このような指定は予約内容や代替条件における他の項目でも適用することが可能である。

追加料金の項目は、サービスを受けるに際しての追加の指名料や、図２の下段の図で示したような利用順位を上げるための割増料金の情報を保持する。この情報は、図３で示したユーザＤＢ１０３に保持する優先ポイントにさらに加算して、対象の予約希望についての最終的な優先ポイントを算出する際に利用される。

代替条件の項目は、対象の予約希望が希望通りに割り当てられなかった場合に、代替として振り替える予約内容として許容する条件（図６の例では日付、担当者、サービスの内容）の情報を保持する。ここで、各項目での「−」の指定は、代替を許容しないことを示し、「＊」の指定は、代替の場合には要望が特にない、すなわちいずれの条件でもよいことを示す。例えば、日付についての「−」の指定は、当該日付で予約が取れない場合は予約をあきらめることを示す。また、サービスについては最低限希望するサービスのみを指定するということが可能である。

予約結果の項目には、対象の予約希望が、予約処理部１２０での処理の結果どのように処理されたかを示す情報を保持する。例えば、「○」は希望通り予約が割り当てられたことを示し、「×」は代替条件も含めて予約が割り当てられなかったことを示す。また、「△」は代替条件で予約が割り当たられたことを示す。

図７は、予約状況ＤＢ１０２のデータ構成と具体的なデータの例を示した図である。予約状況ＤＢ１０２は、予約処理部１２０によって実際に割り当てられた、現在の担当者毎の予約の状況を保持するデータベースである。予約状況ＤＢ１０２は、例えば、担当者ＩＤ、日付、開始時間、終了時間、受付ＩＤ、サービス、および優先ポイントなどの項目を有する。

担当者ＩＤの項目は、予約を割り当てられた担当者の担当者ＩＤを保持する。日付、開始時間、終了時間の項目は、対象の担当者に割り当てられた予約の時間帯についての情報を保持する。受付ＩＤは、対象の担当者および時間帯に対して割り当てられた予約希望を識別する、受付状況ＤＢ１０１の受付ＩＤの情報を保持する。サービスの項目は、対象の担当者および時間帯の予約希望に対して実際に割り当てられたサービスの内容の情報を保持する。この情報と、サービスＤＢ１０４のサービス毎の標準所要時間の情報とに基づいて、予約処理部１２０によって当ＤＢの終了時間の項目が設定される。優先ポイントの項目は、ユーザＤＢ１０３に保持する対象の利用者の優先ポイントに、さらに対象の予約の内容等に基づいて加算した最終的な優先ポイントの情報を保持する。

［処理フロー］
図８は、本実施の形態の予約システム１００における利用順位の予約の調整・割り当ての処理の例について示したフローチャートである。まず、予約受付部１１０は、予約システム１００上の図示しないＷｅｂサーバプログラム等を介して利用者のクライアント端末３００上のＷｅｂブラウザ等に予約入力用の画面を提示し、利用者からの予約希望を受け付けて受付状況ＤＢ１０１に記録する（Ｓ１０１）。予約希望の内容は、例えば、日付、担当者、サービスの種別、指名料や追加料金など、さらに、代替条件としての日付、担当者、サービスの種別などである。

予約受付部１１０にて予約希望を受け付けると、次に、予約処理部１２０は、当該予約希望に対しての優先度を示す優先ポイントを計算する（Ｓ１０２）。優先ポイントは、例えば、ユーザＤＢ１０３に記録された当該利用者の優先ポイントに対して、予約希望の内容に基づいて所定の基準により加算して計算する。例えば、来店頻度や、予約希望におけるサービスの種別等に基づいて優先ポイントを加算してもよい。次に、予約状況ＤＢ１０２から、その時点における担当者毎の予約の状況として各予約者の利用順位と優先ポイントの情報を取得する（Ｓ１０３）。

その後、ステップＳ１０２で算出した当該利用者の優先ポイントと、ステップＳ１０３で取得した各予約者の利用順位と優先ポイントの情報に基づいて、対象の予約対象（担当者等）についての当該利用者の利用順位を決定する（Ｓ１０４）。さらに、その位置に当該予約希望の内容を挿入して予約を割り当て、その結果に基づいて受付状況ＤＢ１０１および予約状況ＤＢ１０２の内容を更新する（Ｓ１０５）。次に、ステップＳ１０５で当該予約希望を挿入した結果、利用順位が最後尾の予約者についての予約が、対象の担当者のサービス提供可能量を超えてオーバーフローしていないかを判定する（Ｓ１０６）。

ステップＳ１０６でオーバーフローしている場合は、最後尾の予約者について受付状況ＤＢ１０１から代替条件を取得し、代替条件の範囲内で他の担当者に予約希望の内容を変更して（Ｓ１０７）、ステップＳ１０２に戻って上記の一連の処理を実行することにより、最後尾の予約者について新たな利用順位を決定する。ステップＳ１０６でオーバーフローしていない場合は、予約表示部１４０は、新たに予約を割り当てた結果として、予約状況ＤＢ１０２から当該利用者の予約希望に対応する内容を取得して、クライアント端末３００に対して表示し（Ｓ１０８）、処理を終了する。

なお、ステップＳ１０４で対象の予約希望についての利用順位を決定する際に、予約希望の条件に許容範囲がある場合（例えば担当者の希望が「＊」として指定されているなど）は、これを考慮して割り当てが可能な担当者を選択するようにしてもよい。また、ステップＳ１０６で利用順位が最後尾の予約者についての予約がオーバーフローする場合に、ステップＳ１０７で取得した代替条件を考慮して、例えば、当該予約者が最低限希望するサービスに限定すればオーバーフローしないような場合には、予約内容を分割して希望の担当者に対する予約を維持することも可能である。また、このとき、分割したサービスについては取り消してもよいし他の担当者に変更するようにしてもよい。

上記の処理によって、後着の新規予約が優先ポイントに従って利用順位の最後尾ではなく中間に挿入された場合は、利用順位が低下した他の先着の予約者は、図２で示したように、さらに割増料金やサービスメニューの追加等により利用料金を上げるなどの対応によって優先ポイントを上げ、利用順位を上げることが可能である。

例えば、クライアント端末３００を利用して予約システム１００にアクセスし、予約表示部１４０を介して現在の予約状況ＤＢ１０２の内容を確認して、自身の利用順位が低下していることを知った予約者は、予約受付部１１０を介して予約内容の変更を行う。このとき、例えば、受付状況ＤＢ１０１に記録された以前の予約希望の内容を参照して新たな予約希望の入力を行い、この内容に基づいて上記の一連の処理により利用順位を決定し、予約表示部１４０によって表示する。予約者は表示された内容を確認し、当該内容に予約を変更するか否かを決定する。このとき予約処理部１２０は、当該予約者によって採用されなかった方の予約希望について、受付状況ＤＢ１０１および予約状況ＤＢ１０２から削除して取り消すようにしてもよい。

また、本実施の形態では、予約受付部１１０による利用者からの予約の受け付けの都度、予約処理部１２０による利用順位の決定と予約の割り当てを行っているが、例えば、後述するように、イベント監視部１３０によって所定の時間間隔毎に生成されたトリガのタイミングで予約の受け付けを締め、それまでに受付状況ＤＢ１０１に記録された複数の予約希望に対してまとめて利用順位の決定と予約の割り当てを行うようにしてもよい。また、イベント監視部１３０によって生成されたトリガのタイミングで各担当者の予約者数の状況を確認し、予約者の数が一定期間所定の数より少ない予約対象については、料金を順次下げていくなどにより、特定の担当者に対する予約者の集中を回避することも可能である。

以上に説明したように、本発明の実施の形態１によれば、予約対象に対して利用者ができるだけ早期の利用を求めて利用予約（利用順位の予約）を行う場合に、従来の先着順での利用順位の決定に加えて、利用者・予約者毎に優先度を決定し、優先度が高い利用者が後着で予約を行った場合には、当該利用者よりも優先度が低い予約者に優先して早い利用順位を割り当てることができる。また、利用順位が低下した予約者については、さらに割増料金を払うなどにより優先度を上げて利用順位を上げることができる。

さらに、新規予約の受け付けにより予約対象（担当者等）のサービス提供可能量を超える場合は、利用順位が最後尾の予約者について担当者の変更・振り替えを行うことができ、その際に、予約者が希望するサービスの代替条件を考慮して、サービス単位で分割して他の担当者に振り替えることができる。また、予約者が少ない予約対象については、料金を順次下げていくなどにより、特定の担当者に対する予約者の集中を回避することも可能である。これらにより、予約対象についての需要と供給のバランスを調整して待ち時間の緩和を図りつつ、利用者・予約者の要望により一層柔軟に応えた形で予約を割り当てることが可能となる。

＜実施の形態２＞
本発明の実施の形態２である予約システムは、属性がそれぞれ異なる予約対象を複数有するサービスとして、例えば美容室（美容師）や会議室（個々の部屋）など、利用者ができるだけ早期の利用を求めて利用予約（利用順位の予約）を行うのに加えて、利用を希望する特定の日時を指定してサービスの利用予約を行う場合があるものに対して、複数の利用者からの予約希望を受け付け、これらの予約希望を調整して予約を割り当てるシステムである。

本実施の形態も基本的な動作は実施の形態１と同様であり、基本的には予約対象（例えば美容師）毎に先着順にて予約を割り当てる。さらに、利用者・予約者毎に優先度を決定し、優先度が高い利用者が後着で予約を行った場合には、当該利用者よりも優先度が低い予約者に優先して希望の予約対象に予約を割り当てることを可能とする。

また、予約を振り替えられた他の予約者については、さらに割増料金を払うなどにより優先度を上げて希望する予約対象・時間帯に予約を振り替えることを可能とする。また、新規の予約希望の受け付けによって、予約対象についての全ての予約希望に係るサービスの総量が予約対象のサービス提供可能量を超える場合は、利用順位が最後尾の予約者について予約対象の変更・振り替えを行う。

さらに、本実施の形態の予約システムでは、利用者は、予約希望の日付および予約対象だけではなく、希望の時間についても指定することができる。ここで、同一の予約対象および時間帯で予約希望が競合する場合は、優先度が高い利用者に対して予約を割り当て、優先度が低い他の利用者については、他の予約対象もしくは時間帯に予約を振り替えることを可能とする。なお、システム構成については実施の形態１と同様であるため説明は省略する。

［概要］
図９は、本実施の形態の予約システムにおける、ある１営業日の利用時間帯の予約の調整・割り当ての例について概要を示した図である。ここでは美容室を例として、属性（例えば提供可能なサービスメニューやスキル）が異なる担当者（トップスタイリストＡ、スタイリストＢ）に対して時間の指定がある場合とない場合とが混在して各利用者がそれぞれ利用予約を行うものとする。

上段の図では、まず、１〜５の数字で示された順に各利用者が新規予約を行った状況を示している。ここでは、各予約者は全てトップスタイリストＡ、スタイリストＢについての標準の利用料金を支払うものとして予約しており、他の属性を考慮しても各予約者の優先度は全て同じであるものとする。ここでは、１番目と４番目の処理として、利用者がそれぞれ時間指定（トップスタイリストＡで１４：００、およびスタイリストＢで１６：００）をして新規予約を行った状況を示している。また、２番目、３番目、５番目の処理として、利用者がトップスタイリストＡについて時間指定なしで新規予約を行った状況を示している。この場合は、実施の形態１の場合と同様に、先着順で早い時間から順に予約を割り当てる。

下段の図では、まず６番目の処理として、希望サービスが多く、追加で指名料も支払うため利用料金が高い利用者、すなわち優先度の高い利用者が時間指定（トップスタイリストＡで１０：００）をして後着の新規予約を行っている。このとき、先着の予約は代替条件を考慮して別の担当者（スタイリストＢ）に振り替える（図中の６’および６”の処理）。なお、ここでの処理のように、時間帯の単位（本実施の形態では１時間）を複数要する予約希望については、対象の複数の時間帯に割り当てられている複数の予約希望の優先度を合算したものとの間で優先度を比較するようにしてもよい。

その後、７番目の処理として、スタイリストＢに振り替えられた予約者のうち、１２：００に割り当てられている予約者は、トップスタイリストＡによるサービスを希望し、サービス内容を追加（「ヘッドスパ」を追加）して利用料金を上げることで優先度を上げ、時間指定なしとして予約希望を変更している。これにより、当初１６：００に割り当てられていた予約者よりも優先度が高くなったため、実施の形態１の場合と同様に、利用順位を当初１６：００に割り当てられていた予約者に優先させ、１６：００に予約を割り当てる（図中の７および７’の処理）。

さらに、８番目の処理として、ＶＩＰ会員であり優先度が高い利用者が時間指定（トップスタイリストＡで１４：００）をして後着の新規予約を行っている。ここで、ＶＩＰ会員の予約希望については、当初１４：００に割り当てられていた予約者よりも優先度が高いため、希望通り１４：００に割り当てる。このとき、当初割り当てられていた予約者については、代替条件を考慮して担当者をスタイリストＢに振り替える。

ここでは、例えば、希望するサービスを全てスタイリストＢに振り替えてもよいし、優先度の高い予約希望と重複するサービスのみを分割してスタイリストＢに振り替えるようにしてもよい。また、一定のサービスについては最低限でもトップスタイリストＡを希望するような場合には、それ以外のサービスのみを分割してスタイリストＢに振り替えるようにしてもよい。また、トップスタイリストＡ以外は許容しないという場合は、予約を不可として取り消す等の処理を行ってもよい。

また、実施の形態１と同様に、例えば、スタイリストＢの予約者が一定期間所定の数より少ないような場合は、スタイリストＢの標準利用料金を所定の基準に従って下げるなどの処理を行うことも可能である。

［データ構成］
予約状況ＤＢ１０２、ユーザＤＢ１０３、サービスＤＢ１０４、予約対象ＤＢ１０５の各データベースについては、実施の形態１の場合と同様であるため、説明は省略する。図１０は、受付状況ＤＢ１０１のデータ構成と具体的なデータの例を示した図である。図１０の例では、実施の形態１の図６で示した受付状況ＤＢ１０１のデータ構成に対して、予約内容および代替条件の項目に時間の項目が追加され、予約対象の時間（サービスの開始時間）を指定することができるようになっている。なお、予約結果の項目の値が「−」のものは、対象の予約希望を受け付けてはいるが、未だ予約処理部１２０による割り当ての処理が行われていない状態を示している。

［処理フロー］
図１１は、本実施の形態の予約システム１００における利用時間帯の予約の調整・割り当ての処理の例について示したフローチャートである。まず、予約受付部１１０は、予約システム１００上の図示しないＷｅｂサーバプログラム等を介して利用者のクライアント端末３００上のＷｅｂブラウザ等に予約入力用の画面を提示し、利用者からの予約希望を受け付けて受付状況ＤＢ１０１に記録する（Ｓ２０１）。予約希望の内容は、例えば、日付、時間、担当者、サービスの種別、指名料や追加料金など、さらに、代替条件としての日付、時間、担当者、サービスの種別などである。

ステップＳ２０１の予約受付の処理が他の利用者からの予約受付に対しても随時行われる一方、これとは非同期に、イベント監視部１３０では、タイマーのカウントやシステム時刻、予約の受付件数等を随時監視し（Ｓ２０２）、予約の締めとなる所定のイベントの発生を判定する（Ｓ２０３）。例えば、朝のサービスの開始前に予約を締めて、当日の全ての予約を割り当てるようにしてもよいし、サービスを提供する全時間帯を所定の間隔（例えば１時間）で区切り、各時間帯の開始時間より一定時間前の所定のタイミングでそれぞれ予約を締めて、対象の時間帯については予約を確定させるとともに、以降の時間帯については仮予約という形で予約を割り当てるようにしてもよい。

ステップＳ２０３で、イベント監視部１３０が予約の締めのイベントを検知した場合は、イベント監視部１３０は予約処理部１２０に対してトリガを生成する。このトリガを受けた予約処理部１２０は、その時点までに受け付けた予約希望のリストを受付状況ＤＢ１０１から取得する（Ｓ２０４）。なお、以降の処理では、ステップＳ２０４で取得した予約希望毎に処理を繰り返すものとする。

まず、対象の予約希望に対して、優先度を示す優先ポイントを計算する（Ｓ２０５）。実施の形態１の場合と同様に、優先ポイントは、例えば、ユーザＤＢ１０３に記録された対象の利用者の優先ポイントに対して、予約希望の内容に基づいて所定の基準により加算して計算する。次に、予約状況ＤＢ１０２から、その時点における担当者毎の予約の状況として各予約者の利用時間帯と優先ポイントの情報を取得する（Ｓ２０６）。

次に、対象の予約希望について、ステップＳ２０６で取得した各予約者の利用時間帯の情報に基づいて、他の予約希望と利用時間帯が競合するか否かを判定する（Ｓ２０７）。利用時間帯が競合しない場合は、対象の予約希望について希望通り予約を割り当てるものとし、ステップＳ２１１に進む。なお、このとき、原則として利用時間帯の希望がない予約者については、空いている時間帯のうち早い時間帯から順次割り当てていくものとする。

一方、ステップＳ２０７で利用時間帯が競合する場合、すなわち、既に予約希望の担当者および時間帯に割り当てられている先着の予約希望がある場合は、ステップＳ２０５で算出した対象の利用者の優先ポイントと、ステップＳ２０６で取得した各予約者の利用時間帯と優先ポイントの情報に基づいて、競合する時間帯について勝者となる利用者（予約者）を決定する（Ｓ２０８）。このとき、対象の予約希望もしくは競合する予約希望の少なくとも一方が時間帯の単位を複数要する場合は、この予約希望の優先ポイントと、対象の複数の時間帯に割り当てられる他の複数の予約希望の優先ポイントを合算したものとの間で比較して勝者を判断する。

なお、ステップＳ２０８で対象の利用者・時間帯について勝者を決定する際に、図９で説明したように、時間帯の中でサービス単位で重複を判断し、重複するサービスについてのみ優先ポイントによって勝者を決定してもよい。このとき、重複しないサービスについては分割して希望通り予約を割り当ててもよい。

また、重複の判断に際しては、サービスの提供順序を入れ替えるなどによってできるだけ重複しないように考慮することも可能である。例えば、病院の診療予約などでは、診療科目の順序をできるだけ重複しないように入れ替えることができる。一方、サービスの種類によっては提供順序が固定されるものや他の担当者に分割することができないものがあり、このようなサービスについては一つのまとまりとして取り扱う必要がある。これらの情報についてはサービスＤＢ１０４に項目を追加して保持することで参照することができる。

ステップＳ２０８で勝者となった利用者については対象の予約希望について希望通り予約を割り当てるものとする。一方、敗者となった利用者（予約者）については、受付状況ＤＢ１０１から代替条件を取得し（Ｓ２０９）、代替条件の範囲内で他の担当者や時間、サービス内容などに変更して新たな予約希望として受付状況ＤＢ１０１に記録するとともに、ステップＳ２０４で取得した予約希望のリストに加える（Ｓ２１０）。ステップＳ２０８〜Ｓ２１０における、ステップＳ２０７で利用時間帯が競合する場合の処理の詳細な例については後述する。

ステップＳ２１０で、代替の予約希望について受付状況ＤＢ１０１に記録する際に、予約希望の条件に許容範囲がある場合（例えば担当者の希望が「＊」として指定されているなど）は、これを考慮して割り当てが可能な担当者や時間帯を選択するようにしてもよい。またこのとき、予約希望のサービス全体で他の利用者・時間帯に振り替えてもよいし、重複するサービスや最低限希望するサービス以外のサービスのみ分割して振り替えるようにしてもよい。また、これらのサービスのみ分割して予約希望を取り消すようにしてもよい。

その後、ステップＳ２０７で競合する予約希望がなかった利用者、およびステップＳ２０８で勝者となった利用者（予約者）について、割り当てられた予約の内容に基づいて受付状況ＤＢ１０１および予約状況ＤＢ１０２の内容を更新する（Ｓ２１１）。ステップＳ２０４で取得した予約希望のリストについて上記の一連の処理を実行すると、予約表示部１４０は、新たに予約を割り当てた結果として、予約状況ＤＢ１０２から当該利用者の予約希望に対応する内容を取得して、クライアント端末３００に対して表示し（Ｓ２１２）、処理を終了する。

図１２は、図１１のステップＳ２０８〜Ｓ２１０における、ステップＳ２０７で利用時間帯が競合する場合の処理の詳細な例について示したフローチャートである。図１１のステップＳ２０７で利用時間帯が競合する場合に、まず、競合する各利用者（予約者）がともに予約希望において時間帯を指定しているか否かを判定する（Ｓ３０１）。両者とも時間帯を指定している場合は、図１１のステップＳ２０５で算出した各利用者の優先ポイントに基づいて、優先ポイントが高い利用者を勝者として決定する（Ｓ３０２）。

敗者となった利用者については、予約内容および受付状況ＤＢ１０１から取得した代替条件に基づいて、予約希望において担当者を指定しているか否かを判定する（Ｓ３０３）。担当者を指定していない場合は、敗者となった利用者の予約希望を当初と同じ時間帯で別の担当者に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１２）。一方、担当者を指定している場合は、予約希望を当初と同じ担当者の後ろの時間帯に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１３）。

ステップＳ３０１で、一方が時間帯を指定している場合（両者とも時間帯を指定していない場合は実施の形態１と同様の処理とすることができる）は、原則として時間帯を指定している利用者の予約希望を優先させる処理となる。まず、各利用者についていずれが優先ポイントが高いかを判定する（Ｓ３０４）。ここで時間帯を指定している利用者の方が優先ポイントが高い場合は、当該利用者をそのまま勝者として決定する（Ｓ３０５）。また、敗者については、時間帯を指定していないため、予約希望を当初と同じ担当者の後ろの時間帯に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１３）。

一方、ステップＳ３０４で、時間帯を指定していない利用者の方が優先ポイントが高い場合は、予約状況ＤＢ１０２を参照して、同じ時間帯で別の担当者に空きがあるか否かを判定する（Ｓ３０６）。ここで、別の担当者に空きがある場合は、時間帯を指定していない利用者（優先ポイントが高い利用者）を勝者として決定し（Ｓ３０７）、敗者となった利用者（時間帯を指定している利用者）の予約希望を当初と同じ時間帯で対象の別の担当者に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１２）。

ステップＳ３０６で、同じ時間帯で別の担当者に空きがない場合は、時間帯を指定していない利用者が担当者を指定しているか否かを判定する（Ｓ３０８）。担当者も指定していない場合は、予約状況ＤＢ１０２を参照して、当初の時間帯よりも前の時間帯で別の担当者に空きがあるか否かを判定する（Ｓ３０９）。ここで、前の時間帯で別の担当者に空きがある場合は、時間帯を指定している利用者（優先ポイントが低い利用者）を勝者として決定し（Ｓ３１０）、敗者となった利用者（時間帯を指定していない利用者）の予約希望を当初より前の時間帯で対象の別の担当者に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１４）。

ステップＳ３０８で、時間帯を指定していない利用者が担当者を指定している場合、もしくは、ステップＳ３０９で、当初の時間帯より前の時間帯で別の担当者に空きがない場合は、所定の基準に基づいて勝者となる利用者を決定し（Ｓ３１１）、敗者となった利用者の予約希望を当初と同じ担当者の後ろの時間帯に変更し、新たな予約希望として受付状況ＤＢ１０１に記録する（Ｓ３１３）。なお、ステップＳ３１１での基準としては、例えば、原則として時間帯を指定している利用者を優先させて勝者としつつ、優先ポイントの差が所定の閾値より大きい場合は、時間帯を指定していない利用者を勝者とする、などの基準とすることができる。以上の処理を行うことにより、利用者の希望（こだわり）を可能な限り反映させた予約の割り当てを行うことができる。

図１１、図１２に示した処理によって、例えば、後着の新規予約が優先ポイントに従って希望の担当者・時間帯に割り当てられた場合は、他の担当者・時間帯に振り替えられた先着の予約者は、図９で示したように、さらに割増料金やサービスメニューの追加等により利用料金を上げるなどの対応によって優先ポイントを上げ、予約の割り当てを変更することが可能である。

例えば、クライアント端末３００を利用して予約システム１００にアクセスし、予約表示部１４０を介して現在の予約状況ＤＢ１０２の内容を確認して、自身の予約の割り当てが予約希望から変更されていることを知った予約者は、予約受付部１１０を介して予約内容の変更を行う。このとき、例えば、受付状況ＤＢ１０１に記録された以前の予約希望の内容を参照して新たな予約希望の入力を行うことができる。

また、例えば、図９の下段の図における６番目の処理のように、時間帯の単位を複数要する予約希望（図中の６）によって、複数の先着の予約が振り替えられた（図中の６’および６”の処理）ような場合に、予約表示部１４０は、振り替えられた複数の予約についての各予約者からの予約状況の表示要求に対して、同様に振り替えられた他の予約者の情報を表示するようにしてもよい。これにより、同様に振り替えられた複数の予約者は、例えば、共同して指名料などの割増料金を支払ったり、サービス内容を追加したりするなどにより、複数の予約希望の合算での優先度を上げて予約の割り当てを復元させることが可能となる。

また、本実施の形態では、イベント監視部１３０によって生成されたトリガのタイミングで、受付状況ＤＢ１０１に記録された複数の予約希望に対して予約の調整と割り当てを行っているが、実施の形態１の場合のように、予約受付部１１０による利用者からの予約の受け付けの都度、予約処理部１２０による予約の調整と割り当てを行うようにしてもよい。

また、本実施の形態では、予約状況ＤＢ１０２には、予約対象（担当者）毎の予約の割り当て状況を保持し、この情報に基づいて予約希望の競合や空きを判断するものとしているが、予約対象（担当者）の実際の作業の進捗状況（実績）を反映させ、例えば、ある予約者に対する作業が前倒しで完了した場合には、その後に予約が割り当てられている予約者のうち、時間帯を指定していない予約者に対する作業を前倒しにする（予約の割り当てを変更する）ようにしてもよい。

また、予約状況ＤＢ１０２の内容から各予約対象（担当者）の空き時間の状況を判定し、例えば、当該予約対象（担当者）自身が優先ポイントの低い予約希望者となることで、自身の食事時間や休憩時間などを自動もしくは手動で割り振る（予約する）ようにしてもよい。

以上に説明したように、本発明の実施の形態２によれば、予約対象に対して利用者ができるだけ早期の利用を求めて利用予約を行う場合に加えて、利用を希望する特定の日時を指定してサービスの利用予約が行われる場合にも適用することができる。また、同一の担当者・時間帯に対して予約希望が競合した場合は、敗者について担当者・時間帯の変更・振り替えを行うことができ、その際に、予約者が希望するサービスの代替条件を考慮して、サービス単位で分割して他の担当者に振り替えることもできる。

また、時間帯の単位を複数要する予約希望については、対象の複数の時間帯に割り当てられている複数の予約希望の優先度を合算したものとの間で勝者を判断することができる。これらにより、予約対象についての需要と供給のバランスを調整して待ち時間の緩和を図りつつ、利用者・予約者の要望により一層柔軟に応えた形で予約を割り当てることが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、上述した実施の形態１、２では、属性がそれぞれ異なる予約対象を複数有するサービスとして、マッサージ店や美容室などのサービスを例として挙げたが、予約対象（担当者等）毎のサービスメニューやスキルなどが異なり、また、利用者の要望するサービスの内容もそれぞれ異なるものとして、例えば、銀行のローカウンターでの運用相談や、証券会社での資産管理コンサルティングなどの各種サービスにも適用することができる。これにより、担当者毎の得意分野などに応じた利用者からの指名予約や、希望する担当者の混雑時における、サービス内容等を考慮した他の担当者への振り替えによる待ち時間の緩和などを図ることができる。

本発明は、マッサージ店や美容室など、属性がそれぞれ異なる予約対象を複数有するサービスに対する利用予約を受け付ける予約システムに利用可能である。

１００…予約システム、１０１…受付状況ＤＢ、１０２…予約状況ＤＢ、１０３…ユーザＤＢ、１０４…サービスＤＢ、１０５…予約対象ＤＢ、１１０…予約受付部、１２０…予約処理部、１３０…イベント監視部、１４０…予約表示部、２００…ネットワーク、３００…クライアント端末。

Claims (6)

1. 属性がそれぞれ異なる予約対象を複数有するサービスに対して、複数の利用者からの予約希望を受け付け、これらの予約希望を先着順に調整して予約を割り当てる予約システムであって、
   前記利用者からの前記予約対象に対する前記予約希望を受け付け、前記予約希望の内容を受付状況データベースに記録し、さらに、クライアント端末を利用した前記利用者からの要求に対して、前記受付状況データベースから現在の前記利用者による前記予約希望の内容を取得して前記クライアント端末に出力する予約受付部と、
   前記受付状況データベースに記録された前記予約希望に係る前記利用者の情報、および前記予約希望の内容に基づいて、所定の基準により前記予約希望についての優先度を算出し、前記優先度の値に応じて、前記予約対象についての前記各予約の中での前記予約希望の利用順位を決定して、前記利用順位の位置に新たな前記予約として挿入して割り当て、割り当てた結果に基づいて予約状況データベースに記録する予約処理部と、
   前記クライアント端末を利用した前記利用者からの要求に対して、前記予約状況データベースから現在の前記予約対象毎の前記予約の状況を取得して前記クライアント端末に出力する予約表示部とを有し、
   前記予約受付部は、前記予約希望を受け付けて前記受付状況データベースに記録する際に、前記予約希望が満たされなかった場合に代替として最低限希望するサービスの内容を含む代替条件の指定を合わせて記録し、
   前記予約処理部は、第１の予約希望についての前記利用順位を決定して新たな前記予約として挿入して割り当てる際に、前記第１の予約希望に係る第１の予約対象について当該時点で割り当てられている全ての前記予約希望に係るサービスの総量が前記第１の予約対象のサービス提供可能量を超える場合は、前記利用順位の最後尾の前記予約者に係る第２の予約希望の内容を、前記受付状況データベースに記録された前記代替条件のサービスの内容に限定し、限定した内容によってもなお前記第１の予約対象について当該時点で割り当てられている全ての前記予約希望に係るサービスの総量が前記第１の予約対象のサービス提供可能量を超える場合は、前記第２の予約希望を他の第２の予約対象に振り替えることを特徴とする予約システム。
2. 請求項１に記載の予約システムにおいて、
   前記予約処理部は、前記第１の予約希望についての前記利用順位を決定して新たな前記予約として挿入して割り当てる際に、前記第１の予約希望に係る第１の予約対象について当該時点ですでに前記予約として割り当てられている他の第３の予約希望であって、前記利用順位が低下するものに係る前記予約者による、前記予約希望の内容の変更を受けて、前記第３の予約希望についての前記優先度を再度算出し、前記優先度の値に応じて、前記第１の予約対象についての前記各予約の中での前記第３の予約希望の利用順位を再度決定することを特徴とする予約システム。
3. 請求項１または２に記載の予約システムにおいて、
   前記予約処理部は、前記予約対象について割り当てられている前記予約希望が一定期間所定の数よりも少ない場合は、前記予約対象の利用料金を下げることを特徴とする予約システム。
4. 請求項１〜３のいずれか１項に記載の予約システムにおいて、
   前記予約受付部は、さらに前記予約希望の内容として前記予約対象の利用を開始する時間の情報を取得して前記受付状況データベースに記録することが可能であり、
   前記予約処理部は、複数の前記予約希望について、それぞれの利用希望の時間の情報と前記優先度の値に応じて、前記予約対象についての前記各予約希望についての時間帯を決定して前記予約として割り当て、割り当てた結果に基づいて前記予約状況データベースに記録し、
   新たな第４の予約希望についての時間帯を決定して前記予約として割り当てる際に、前記第４の予約希望と時間帯が重複し、前記優先度が前記第４の予約希望よりも低い第５の予約希望については、前記受付状況データベースに記録された前記代替条件のサービスの内容に基づいてサービス単位で分割して他の前記予約対象もしくは他の時間帯に振り替えることを特徴とする予約システム。
5. 請求項４に記載の予約システムにおいて、
   前記予約処理部は、前記第５の予約希望に該当するものが複数ある場合に、前記第４の予約希望の前記優先度と、複数の前記第５の予約希望の前記各優先度の合計との比較により、対象の時間帯に割り当てる前記予約希望を決定することを特徴とする予約システム。
6. 請求項５に記載の予約システムにおいて、
   前記予約処理部は、対象の時間帯に前記第４の予約希望を前記予約として割り当てた際に、前記第５の予約希望に係る前記各予約者に対して、前記第５の予約希望が希望通りに割り当てられなかった旨と、前記第５の予約希望に係る他の前記各予約者の情報を前記予約表示部を介して提示し、
   前記第５の予約希望に係る前記各予約者による、前記第５の予約希望の内容の変更を受けて、前記第５の予約希望についての前記優先度を再度算出し、前記第４の予約希望の前記優先度と、複数の前記第５の予約希望の前記各優先度の合計との比較により、対象の時間帯に割り当てる前記予約希望を再度決定することを特徴とする予約システム。