JP2011034351A - グループ予約支援システム - Google Patents

Abstract

【課題】グループを代表して宿泊予約手続を行うユーザに対し、宿泊先を確保しつつ参加メンバを募集する仕組みを提供する。
【解決手段】〔１〕幹事から仮予約申請を受け付け、メンバに承認を依頼し、メンバから承認依頼に対する回答を受け付け、仮予約番号，メンバ及び回答内容を順次識別する。〔２〕識別した回答が「承認」であれば（Ｓ１１２２でＹｅｓ）、「参加決定済メンバ数」に１を加算する（Ｓ１１２４）。〔３〕参加決定済メンバ数が定員の倍数であるとき（Ｓ２０２６でＹｅｓ）、「予約成立プラン数」に１を加算し（Ｓ２０２８）、新たな予約番号を付与して、予約ＤＢ１４に注文数１の予約情報を登録する（Ｓ２０３０）。
【選択図】図２０

Description

本発明は、オンラインでの宿泊予約を管理する仕組みに関し、特に、グループを代表するユーザによる宿泊予約手続を支援する機能に関するものである。

＜先行技術１＞
サービスの予約に至る呼び掛けのプロセスを支援する仕組みが知られている（例えば、特許文献１参照）。
同仕組みは、各種構成体（サークル，同好会，部署等）を代表するメンバ（代表者，幹事等）が、各種サービス（スポーツ施設の貸出，コンペの企画，宿泊施設の提供，会議室の貸出等）を構成体単位で予約する場面を想定している（同文献［０００２］〜［０００４］）。なお、前提として、「参加者が一定数以上であること」が当該各種サービスの利用条件となっている。

具体的には、概ね次の手順により予約が成立する（同文献図１１，［００５３］〜［００５４］参照）。
（１）クライアント装置から仮予約の申請を受け付ける（Ｓ１１）。
（２）構成体マスタファイルから仮予約申請に係る構成体の他の所属メンバの接続先データ等を取り込み、それらの所属メンバの保有するクライアント装置に対して仮予約案内通知を出す（Ｓ１５，図９）。
（３）他の所属メンバのクライアント装置から回答を受信し、サービスの提供を受ける旨の回答をした者が一定数以上存在するかなど、一定の条件を充足しているか否を判断する（Ｓ１７）。
（４）条件を充足している場合には、利用するサービスのＩＤ、構成体のＩＤ、所属メンバのＩＤ等を予約登録ファイルに登録する（Ｓ１８）。

＜先行技術２＞
Ｗｅｂページ中の入力フォームに入力された複数のメールアドレス宛に、同報メールを送信する仕組みが知られている（例えば、特許文献２参照）。
具体的には、次の手順により同報メールを送信する（同文献図３参照）。
（１）ユーザが、Ｗｅｂページ中の所定の入力欄に、相手の名前，宛先のメールアドレス，メッセージ等を入力する（図４，［０００９］）。
（２）ユーザ端末が、上記（１）で入力されたデータをサーバに送信する。
（３）サーバ装置が、上記（２）で受信したデータを基に電子メールを生成し、入力されたメールアドレス宛に送信する。

＜先行技術３＞
宴会の参加予定者数を表示する機能を備えた宴会予約支援システムが知られている（例えば、特許文献３参照）。
具体的には、宴会の幹事から同システムを介して相談を受けた参加者候補が同システムを介して参加の可否を回答するごとに参加予定者数をカウントし、所定の記憶手段に記憶していく（同文献［００５７］参照）。その上で、幹事又は参加者から要求を受けるごとに参加予定者数を集計し、その集計値を途中経過（又は結果）としてグラフ形式で表示する（同文献［００５８］，図５参照）。

＜先行技術４＞
オンライン宿泊予約サイトにおいて、宿泊施設を検索するサービス、宿泊の予約を受け付けるサービスが提供されている（例えば、非特許文献１参照）。
同サイトを利用すれば、例えば、希望する宿泊条件（日程・地域・予算・人数等）を入力して、「空室がある部屋」を検索することができる（非特許文献２，非特許文献３参照）。また、オンラインで宿泊の予約をすることができる（同）。

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

楽天トラベル株式会社、「楽天トラベル」、[online]、インターネット<URL: http://travel.rakuten.co.jp/index.html> 楽天トラベル株式会社、「楽天トラベルの使い方−国内宿泊予約の流れ」、[online]、インターネット<URL: http://travel.rakuten.co.jp/howto/domestic.html> 楽天トラベル株式会社、「ヘルプ−国内宿泊予約」、[online]、インターネット<URL: http://travel.rakuten.co.jp/help/kokunai/hotel/01.html>

［１．グループ単位の宿泊予約］
図１に、従来のオンライン宿泊予約サイトを利用した宿泊予約の手順を示す。
図１に示すように、同サイトを利用するユーザ（申請者）が端末を操作して、宿泊プランを検索し（Ｓ１０５）、申請者情報を入力し（Ｓ１１０）、予約又は手配（以下、単に「予約」という。）を申請する（Ｓ１１５）ことにより、予約が成立する。
したがって、宿泊プランを検索し所望のプランを選択する時点で、宿泊条件（日程・宿泊先・予算・人数等）が確定している必要がある。

また、宿泊施設の客室には、それぞれ定員（宿泊人数の上限）が設定されているのが通常である。そのため、複数のメンバから成るグループ単位で宿泊を予約する場合には、宿泊するメンバの数が確定しなければ、確保すべき客室の数が確定せず、宿泊プランの検索を有効に行うことができない。
その一方で、グループの各メンバは、日程・宿泊先・予算等がある程度決まっていなければ、宿泊に参加するか否かを判断することができない。

上記事情により、複数のメンバから成るグループの幹事は、宿泊を予約するに当たり、例えば、次のような手順を踏まざるを得ない。
（１）オンライン宿泊予約サイトの検索機能を利用して、日程・宿泊先・予算等の候補を設定する。
（２）上記（１）で設定した候補を電子メール等で各メンバに通知し、参加の可否をメール等で個別に回答してもらう。
（３）上記（２）の回答を手作業で集計し、宿泊条件（日程・宿泊先・予算・人数等）を確定する。
（４）上記（３）で確定した宿泊条件のもと、オンライン宿泊予約サイトを利用して宿泊プランを再度検索し（Ｓ１０５）、予約が可能であれば、申請者情報を入力した上で（Ｓ１１０）、予約を申請する（Ｓ１１５）。

［２．先行技術の限界］
上記＜先行技術１＞の仕組みは、本予約前に「仮予約」を受け付け、参加者を募集する期間を確保している。また、参加者の募集，募集に対する回答の受付，参加者数の集計等の手順を自動化している。
ただし、上記＜先行技術１＞の仕組みは、「参加者が一定数以上であること」が利用条件となっているサービスを予約する場面を想定したものである。そのため、仮予約中に集まった参加者の数は、本予約の可否（サービスの利用条件を具備しているか否か）を判定するためのデータに過ぎない。
つまり、上記＜先行技術１＞は、参加者数によってサービスの注文数が変動することを予定した仕組みではない。

［３．本発明が解決しようとする課題］
本発明が解決しようとする課題は、グループを代表して宿泊予約手続を行うユーザに対し、宿泊先を確保しつつ参加メンバを募集する仕組みを提供する、という点である。

上記課題を解決するため、本発明は、複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムのサーバシステムであって、宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段とを有し、前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信手段と、前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録手段と、前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定手段と、前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信手段と、前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付手段と、前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定手段と、予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録手段とを備えることを特徴とする。

前記回答受付手段は、さらに、前記識別した仮予約番号に対応する仮注文数を前記仮予約情報記憶手段より読み出し、前記更新後の参加決定済メンバ数が宿泊プランの定員と該仮注文数との積に等しいとき、該仮予約番号に係る仮予約について回答の受付を打ち切ってもよい。

所定の条件を満たすとき、特定した仮予約番号に対応する参加決定済メンバ数を前記仮予約情報記憶手段より読み出し、該参加決定済メンバ数が宿泊プランの定員の倍数でなければ注文数１の予約が成立すると判定する第二の予約成否判定手段をさらに備えていてもよい。

前記仮予約情報記憶手段は、予約成立プラン数をさらに記憶することが可能であり、前記仮予約情報記憶手段に記憶している前記予約が成立すると判定された仮予約に係る仮予約番号に対応する予約成立プラン数に１を加算する予約成立数計数手段と、前記所定の条件を満たすとき、さらに、前記特定した仮予約番号に対応する宿泊プランの識別情報と、仮注文数と、予約成立プラン数とを前記仮予約情報記憶手段より読み出し、該仮予約情報記憶手段に記憶している該宿泊プランの識別情報に対応する在庫数に、該仮注文数と該予約成立プラン数との差を加算する予約一部解除手段とをさらに備えていてもよい。

前記仮予約情報記憶手段は、前記仮予約番号に対応させて、回答期限をさら記憶することが可能であり、前記仮予約申請情報受信手段は、回答期限をさらに受信し、前記仮予約情報登録手段は、前記受信した回答期限を前記仮予約番号に対応付けて前記仮予約情報記憶手段にさらに書き込み、前記第二の予約成否判定手段は、前記仮予約情報記憶手段に記憶しているいずれかの仮予約番号に対応する回答期限が経過しているとき、該回答期限が経過している仮予約番号を特定し、該特定した仮予約番号に対応する予約の成否を判定してもよい。

前記予約情報記憶手段は、各予約番号を対応する仮予約番号に関連付けて記憶することが可能であり、前記予約情報一部登録手段は、前記予約が成立すると判定された仮予約に係る仮予約番号と前記新たな予約番号とを関連付けて前記予約情報記憶手段に登録してもよい。

また、上記課題を解決するため、本発明は、複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムにおけるグループ予約支援方法であって、宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段とを有するサーバシステムが、前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信ステップと、前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録ステップと、前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定ステップと、前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信ステップと、前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付ステップと、前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定ステップと、予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録ステップとを実行することを特徴とする。

また、上記課題を解決するため、本発明は、複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムにおけるグループ予約支援プログラムであって、宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段とを有するサーバシステムに、前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信ステップと、前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録ステップと、前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定ステップと、前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信ステップと、前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付ステップと、前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定ステップと、予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録ステップとを実行させる。

本発明のサーバシステムは、幹事から仮予約申請を受け付け、メンバに承認を依頼し、メンバから承認依頼に対する回答を受け付ける。そして、宿泊への参加者数が仮予約に係る宿泊プランの定員の倍数に達するごとに、注文数１の予約を成立させる。
したがって、本発明のサーバシステムを利用すれば、グループを代表して宿泊予約手続を行う幹事は、宿泊先を確保しつつ参加メンバを募集することができる。一方、参加者にしても、承認すれば確実に参加することができる。

宿泊予約の手順を示すフロー図である。（従来例） 宿泊予約の手順を示すフロー図である。（実施形態） システム構成を示すブロック図である。（実施形態） データベースのデータ項目の説明図である。（実施形態） データベースのデータ項目の説明図である。（実施形態） 仮予約申請の受付手順を示すフロー図である。（実施形態） 送受信するデータ項目の説明図である。（実施形態） メンバ登録時の仮予約確認ページの表示例である。（実施形態） 承認依頼メールの表示例である。（実施形態） 回答の受付手順を示すフロー図である。（実施形態） 回答の受付手順を示すフロー図である。（実施形態） 回答前の仮予約確認ページの表示例である。（実施形態） 回答後の仮予約確認ページの表示例である。（実施形態） 回答状況の確認手順を示すフロー図である。（実施形態） 追加メンバ登録前の仮予約確認ページの表示例である。（実施形態） 追加メンバ登録時の仮予約確認ページの表示例である。（実施形態） 追加メンバ登録後の仮予約確認ページの表示例である。（実施形態） バッチ処理の手順を示すフロー図である。（実施形態） 抽出条件・注文数・解除数の説明図である。（実施形態） 回答の受付手順を示すフロー図である。（他の実施形態） バッチ処理の手順を示すフロー図である。（他の実施形態）

＜定義＞
・宿泊プラン…オンライン宿泊予約サイトにおける予約対象（注文対象）の単位。特定の客室（又は特定の部屋タイプの客室）における少なくとも１泊分の宿泊サービスを必須の要素とし、食事等の付随的なサービスを任意に含む。なお、本実施形態では、宿泊プランと部屋タイプとが「１対１」又は「多対１」で対応しているものとする。
・仮予約…一定の条件の範囲内で宿泊プランを優先的に確保すること。予約に至らない場合には、その全部又は一部を解除することができる。
・本予約…通常の予約と同義。「仮予約」との対比のため、特に「本予約」と表現する場合がある。

・グループ…複数のユーザにより構成される集団。例えば、クラブ，サークル，同好会，ゼミ，研究室，部署等。
・メンバ…グループを構成するユーザ。
・幹事…グループを代表するメンバ。本実施形態では、グループを代表して宿泊予約手続を行うメンバ。

＜実施形態＞
［１．概要］
本実施形態のシステムは、オンライン宿泊予約サイトを管理するシステムであり、宿泊の予約を受け付けるサービス（宿泊予約サービス）をユーザに提供する。主要な特徴は、宿泊の予約（本予約）の前にメンバ全員を許容できる内容で「仮予約」を受け付け、幹事が指定したｎ人（ｎは自然数）のメンバから承認を得た上で宿泊の予約を成立させる点にある。
したがって、本実施形態のシステムを利用すれば、グループを代表して宿泊予約手続を行う幹事は、宿泊先を確保しつつ参加メンバを募集することができる。

図２に、本実施形態のシステムを利用した宿泊予約の手順を示す。
図２に示すように、幹事が端末を操作して、宿泊プランを検索し（Ｓ１０５）、申請者情報を入力し（Ｓ１１０）、仮予約を申請し（Ｓ２１５）、メンバに承認を依頼する（Ｓ２２０）。その後、承認を依頼された各メンバが承認すること等により、予約が成立する。
なお、図２において図１と同一の符号が付されている処理は、同様の処理である。また、予約成立後の処理は、従来例（例えば、＜先行技術４＞）と同様である。

［２．システム構成］
図３に、本実施形態のシステムの構成を示す。
図３に示すように、本実施形態のシステムは、全体として、サーバシステム１０，幹事のユーザ端末２０，幹事以外のメンバのユーザ端末３０（１〜ｎ）及び施設端末４０により構成される。また、サーバシステム１０は、ユーザＤＢ１１，施設ＤＢ１２，宿泊プランＤＢ１３，予約ＤＢ１４及び仮予約ＤＢ１５を有している。
サーバシステム１０と、ユーザ端末２０，ユーザ端末３０（１〜ｎ）及び施設端末４０とは、通信ネットワーク（本実施形態では、インターネット５０）を介してそれぞれ互いに接続している。

［２−１．サーバシステム］
図３において、サーバシステム１０は、宿泊予約サービスを管理するサーバ群である。
サーバシステム１０は、例えば、Ｗｅｂページの生成・送信機能を有するＷｅｂサーバ，電子メールの生成・送信機能を有するメールサーバ，データベースを管理するＤＢサーバ，バッチ処理を実行するバッチ処理サーバ及びその他の必要なＡＰサーバを含む。

［（ａ）ユーザＤＢ］
図３において、ユーザＤＢ１１は、宿泊予約サービスを利用するユーザの情報を記憶するデータベースである。
図４（ａ）に、ユーザ情報の主要な項目を示す。
図４（ａ）に示すように、１件のユーザ情報は、「ユーザＩＤ」，「パスワード」及び「メールアドレス」を含んでいる。

［（ｂ）施設ＤＢ］
図３において、施設ＤＢ１２は、宿泊予約サービスにおいて客室を提供する宿泊施設に関連する情報を記憶するデータベースである。
本実施形態では、施設基本情報，客室基本情報，客室割当情報及び空室管理情報をそれぞれ複数件ずつ記憶しており、これらはキー項目を介して対応しているものとする。

図４（ｂ−１）に、施設基本情報の主要な項目を示す。
図４（ｂ−１）に示すように、１件の施設基本情報は、「施設ＩＤ」，「パスワード」，「メールアドレス」，「仮予約可能期間」及び「仮予約禁止期間」を含んでいる。
ここで、「仮予約可能期間」は、仮予約の成立から本予約の成否の判定までの最大日数である。「仮予約禁止期間」は、宿泊日直前の仮予約を禁止する期間の日数である。本実施形態では、これらの期間を各施設が各別に設定できるようにしている。

図４（ｂ−２）に、客室基本情報の主要な項目を示す。
図４（ｂ−２）に示すように、１件の客室基本情報は、「施設ＩＤ」，「部屋タイプ」及び「収容人数」を含んでいる。
ここで、「部屋タイプ」は、客室の部屋タイプ（和室／洋室の別，広さ等）を示すコードである。

図４（ｂ−３）に、客室割当情報の主要な項目を示す。
図４（ｂ−３）に示すように、１件の客室割当情報は、「施設ＩＤ」，「宿泊日」，「部屋タイプ」，「宿泊プランＩＤ」及び「割当数」を含んでいる。
ここで、「割当数」は、宿泊日ごとに各部屋タイプの客室をどの宿泊プランにどれだけ割り当てているかを示す。

図４（ｂ−４）に、空室管理情報の主要な項目を示す。
図４（ｂ−４）に示すように、１件の空室管理情報は、「施設ＩＤ」，「宿泊日」，「部屋タイプ」，「空室数」，「予約済部屋数」及び「仮予約中部屋数」を含んでいる。
ここで、「空室数」は、予約及び仮予約の対象となっていない客室の数である。「予約済部屋数」，「仮予約中部屋数」は、それぞれ予約，仮予約の対象となっている客室の数である。

［（ｃ）宿泊プランＤＢ］
図３において、宿泊プランＤＢ１３は、宿泊予約サービスにおいて予約（注文）の対象となる宿泊プランの情報を記憶するデータベースである。
本実施形態では、宿泊プラン基本情報及び在庫管理情報をそれぞれ複数件ずつ記憶しており、これらはキー項目を介して対応しているものとする。

図４（ｃ−１）に、宿泊プラン基本情報の主要な項目を示す。
図４（ｃ−１）に示すように、１件の宿泊プラン基本情報は、「宿泊プランＩＤ」，「施設ＩＤ」，「宿泊日」，「部屋タイプ」及び「定員」を含んでいる。
ここで、「定員」は、その宿泊プランに対応する部屋タイプの最大宿泊人数であり、客室基本情報（図４（ｂ−２））の「収容人数」に対応する。

図４（ｃ−２）に、在庫管理情報の主要な項目を示す。
図４（ｃ−２）に示すように、１件の在庫管理情報は、「宿泊プランＩＤ」及び「在庫数」を含んでいる。
ここで、「在庫数」は、予約及び仮予約の対象となっていない宿泊プランの数である。

［（ｄ）予約ＤＢ］
図３において、予約ＤＢ１４は、宿泊予約サービスの予約情報を記憶するデータベースである。
図５（ｄ）に、予約情報の主要な項目を示す。
図５（ｄ）に示すように、１件の予約情報は、「予約番号」，「仮予約番号」，幹事の「ユーザＩＤ」，「宿泊プランＩＤ」及び「注文数」を含んでいる。
なお、本実施形態では、特に断りがある点を除き、予約ＤＢ１４に予約情報が登録された後の扱いは、従来例（上記＜先行技術４＞）のオンライン予約サイトと同様である。

［（ｅ）仮予約ＤＢ］
図３において、仮予約ＤＢ１５は、宿泊予約サービスにおける仮予約に関連する情報を記憶するデータベースである。
本実施形態では、仮予約基本情報，仮予約管理情報，メンバ基本情報及びメンバ管理情報をそれぞれ複数件ずつ記憶しており、これらはキー項目を介して対応しているものとする。

図５（ｅ−１）に、仮予約基本情報の主要な項目を示す。
図５（ｅ−１）に示すように、１件の仮予約基本情報は、「仮予約番号」，幹事の「ユーザＩＤ」，「宿泊プランＩＤ」，「仮注文数」，「定員」，「回答期限」，「メッセージファイルのパス」及び「仮予約識別データ」を含んでいる。
ここで、「定員」は、その仮予約に係る宿泊プランの定員であり、宿泊プラン基本情報（図４（ｃ−１））の「定員」に対応する。「仮予約識別データ」は、仮予約番号を識別するデータ（暗号データ，ハッシュ値等）である。
なお、仮予約基本情報に「定員」を記憶せず、必要となるごとに宿泊プラン基本情報（図４（ｃ−１））の「定員」を読み出すように構成してもよい。

図５（ｅ−２）に、仮予約管理情報の主要な項目を示す。
図５（ｅ−２）に示すように、１件の仮予約管理情報は、「仮予約番号」，「参加決定済メンバ数」，「予約成立プラン数」，「未回答メンバ数」及び「仮予約ステータス」を含んでいる。
ここで、「参加決定済メンバ数」は、その仮予約に係る宿泊への参加が決定したメンバの数である。「仮予約ステータス」は、仮予約に係る処理の進捗を示す区分（「依頼中」（初期値），「確認中」，「終了」，「閉鎖」，「キャンセル」等）である。
本実施形態では、「参加決定済メンバ数」の初期値を１として、参加者数に予め幹事を含めている。なお、「参加決定済メンバ数」の初期値を０として、幹事からも参加の承認を得るようにしてもよい。また、「参加決定済メンバ数」を読み出す際に、１を加算してもよい。

図５（ｅ−３）に、メンバ基本情報の主要な項目を示す。
図５（ｅ−３）に示すように、１件のメンバ基本情報は、「仮予約番号」，「メンバＩＤ」，「ニックネーム」，「メールアドレス」及び「メンバ識別データ」を含んでいる。
ここで、「メンバ識別データ」は、メンバを特定する情報（例えば、「メンバＩＤ」，「ニックネーム」又は「メールアドレス」）を識別するデータ（暗号データ，ハッシュ値等）である。
なお、「ニックネーム」又は「メールアドレス」を「メンバＩＤ」として利用してもよい。

図５（ｅ−４）に、メンバ管理情報の主要な項目を示す。
図５（ｅ−４）に示すように、１件のメンバ管理情報は、「仮予約番号」，「メンバＩＤ」，「回答フラグ」及び「承認フラグ」を含んでいる。
ここで、「回答フラグ」は、そのメンバが回答済みであるか否かを示すフラグであり、有意のとき回答済みを示す。「承認フラグ」は、そのメンバが承認したか否かを示すフラグであり、有意のとき承認を示す。「回答フラグ」及び「承認フラグ」の組合せにより、未回答，非承認，承認は次のように表される。
・「回答フラグ」が有意でなければ未回答。
・「回答フラグ」が有意であり、かつ「承認フラグ」が有意でなければ非承認。
・「回答フラグ」及び「承認フラグ」がいずれも有意であれば承認。

［２−２．ユーザ端末］
図３において、ユーザ端末２０，ユーザ端末３０（１〜ｎ）は、宿泊予約サービスを利用する幹事，幹事以外のメンバがそれぞれ使用する端末である。
ユーザ端末２０及びユーザ端末３０は、Ｗｅｂブラウザを有しており、サーバシステム１０から受信したＷｅｂページ（ＨＴＭＬ形式のデータ等）をディスプレイに表示することができる。また、ユーザ端末２０及びユーザ端末３０は、メーラを有しており、サーバシステム１０から受信した電子メールをディスプレイに表示することができる。
なお、ユーザ端末２０及びユーザ端末３０は、通信機能を有する既存の情報処理端末（例えば、パソコン等の電子計算機，携帯電話端末等）でよい。

［２−３．施設端末］
図３において、施設端末４０は、宿泊予約サービスに客室を提供する施設で使用される端末である。
施設端末４０は、Ｗｅｂブラウザを有しており、サーバシステム１０から受信したＷｅｂページ（ＨＴＭＬ形式のデータ等）をディスプレイに表示することができる。また、施設端末４０は、メーラを有しており、サーバシステム１０から受信した電子メールをディスプレイに表示することができる。
なお、施設端末４０は、通信機能を有する既存の情報処理端末（例えば、パソコン等の電子計算機等）でよい。

［３．データ処理］
本実施形態のシステムにおけるデータ処理は、主として次の４とおりに大別される。
（１）仮予約申請の受付
（２）回答の受付
（３）回答状況の確認
（４）バッチ処理

［３−１．仮予約申請の受付］
サーバシステム１０による仮予約申請の受付手順を、図６〜図９（特に、図６のフロー図）を参照して説明する。
図６中には、参照すべき他の図面の番号が付記されている。必要に応じて、当該他の図面を参照されたい。

［（ａ）仮予約申請の受付手順］
図６に、仮予約申請の受付手順を示す。
ここでは、仮予約情報の登録に引き続き、メンバ情報の登録・承認依頼メールの送信を実行する場合を例として説明する。なお、メンバ情報の登録は、仮予約情報の登録後、仮予約期間（仮予約可能期間内、かつ、仮予約禁止期間外で、幹事が設定した期間又は自動的に設定された期間）中の任意の時期に行うことができるものとする。
図６に示すように、サーバシステム１０は、下記〔１１〕〜〔１２〕の手順により仮予約申請を受け付ける。

〔１１〕ユーザ端末２０から仮予約申請情報を受信する（Ｓ６０５，図７（ａ））と、宿泊プランＤＢ１３の在庫管理情報を参照して、申請に係る宿泊プランの在庫数が仮注文数以上か否かを判定する（Ｓ６１０）。在庫数が仮注文数以上であるとき（Ｓ６１０でＹｅｓ）、新たな仮予約番号を付与して仮予約ＤＢ１５に仮予約情報を登録する（Ｓ６１５）。また、このとき、宿泊プランＤＢ１３の在庫管理情報において、申請に係る宿泊プランの在庫数から仮注文数を減算する。一方、在庫数が仮注文数未満であるとき（Ｓ６１０でＮｏ）、仮予約申請を受け付けられない旨等を表示した上で、仮注文数又は宿泊プランの変更を推奨する。

〔１２〕仮予約確認ページを生成し（Ｓ６２０）、ユーザ端末２０に送信する（Ｓ６２５，図８）。仮予約確認ページを介してユーザ端末２０からメンバ登録情報を受信する（Ｓ６３０，図７（ｂ））と、仮予約ＤＢ１５にメンバ情報を登録し（Ｓ６３５）、承認依頼メールを生成して各メンバのメールアドレス宛に送信する（Ｓ６４０，図９）。以上の処理の完了後、仮予約の申請手続が完了した旨等をユーザ端末２０に通知する（Ｓ６４５）。通知の手段は、例えば、電子メールである。

［（ｂ）仮予約申請情報］
図７（ａ）に、仮予約申請情報の主要な項目を示す。
図７（ａ）に示すように、１件の仮予約申請情報は、幹事の「ユーザＩＤ」，「宿泊プランＩＤ」，「仮注文数」及び「回答期限」を含んでいる。
ここで、「回答期限」は、仮予約期間（仮予約可能期間内、かつ、仮予約禁止期間外で設定された期間）の末日である。
なお、仮予約申請情報の項目は、一括で受信してもよいし、各別に受信してもよい。

［（ｃ）仮予約確認ページ］
図８に、メンバ登録時の仮予約確認ページの表示例を示す。
図８に示すように、仮予約確認ページ８００は、エリア８１０，８２０及び８３０を含んでいる。
エリア８１０には、仮予約に関連する情報が表示される。表示される情報は、例えば、仮予約に係る宿泊施設（又は客室）の詳細ページへのリンク，費用の合計，仮予約期間等である。
エリア８２０には、仮予約中の客室の情報が表示される。

エリア８３０では、参加予定のメンバに対する承認依頼メールを作成し、送信を要求することができる。承認依頼メールの送信要求手順は、次のとおりである。
（１）入力欄８３１に、メンバのニックネーム及びメールアドレスを入力する。
（２）必要に応じてボタン８３２をクリックし、入力欄８３１に新たな欄を追加する。
（３）入力欄８３３に、承認依頼メールに記載するメッセージを入力する。
（４）ボタン８３４をクリックし、メンバ情報の登録及び承認依頼メールの送信を要求する。または、ボタン８３５をクリックし、メンバ情報の登録のみを要求する。

［（ｄ）メンバ登録情報］
図７（ｂ）に、メンバ登録情報の主要な項目を示す。
図７（ｂ）に示すように、１件のメンバ登録情報は、「仮予約番号」，「メッセージ」，メンバ（１，２，…）の「ニックネーム」及び「メールアドレス」を含んでいる。
なお、仮予約番号を特定することが可能な情報（例えば、クッキーのセションＩＤ等）により仮予約番号を特定する場合には、上記「仮予約番号」が含まれていなくてもよい。

［（ｅ）承認依頼メール］
図９に、承認依頼メールの表示例を示す。
図９に示すように、承認依頼メール９００は、差出人情報９１０，件名９２０及び本文９３０を含んでいる。
差出人情報９１０は、差出人（ここでは、宿泊予約サービス）のメールアドレス等である。
件名９２０には、例えば、幹事（「Ａ」）からの勧誘である旨を明示する。
本文９３０には、幹事（「Ａ」）からのメッセージ９３１，仮予約に関連する情報９３２及び回答のためのＵＲＬ９３３等が表示される。

ＵＲＬ９３３は、いずれも「仮予約識別データ」及び「メンバ識別データ」をパラメータとして含んでいる。また、ＵＲＬ９３３の一部は、さらに回答コード（パラメータ）をパラメータとして含んでいる。メンバは、ＵＲＬ９３３のいずれかをクリックすることにより、幹事からの承認依頼に対して回答することができる。
本文中の表示と回答コードとの対応関係は、次のとおりである。
・「参加する」 …「承認」を示す回答コードを含む
・「参加しない」 …「非承認」を示す回答コードを含む
・「他のメンバの回答を見る」 …回答コードを含まない

［３−２．回答の受付］
サーバシステム１０による回答の受付手順を、図１０〜図１３（特に、図１０及び図１１のフロー図）を参照して説明する。
図１０，図１１中には、参照すべき他の図面の番号が付記されている。必要に応じて、当該他の図面を参照されたい。

［（ａ）回答の受付手順］
図１０及び図１１に、回答の受付手順を示す。
ここでは、仮予約情報の更新に引き続き、回答内容及び回答数に基づく条件判定を経て予約情報の登録を実行する場合を例として説明する。この手順により、回答期限が未だ経過していなくても、仮予約期間中の比較的早い時期に予約を成立させることができる。また、例えば定員の合計（仮注文数＊定員）を上回る数の参加者を募集した場合に、先着順で参加者を決定することができる。なお、回答内容及び回答数に基づく条件判定処理，予約情報の登録処理は、省略してもよい。
図１０及び図１１に示すように、サーバシステム１０は、下記〔２１〕〜〔２６〕の手順により回答を受け付ける。

〔２１〕ユーザ端末３０からページ送信要求を受信する（Ｓ１００２，図７（ｃ）又は（ｄ））と、仮予約ＤＢ１５の仮予約基本情報を参照して仮予約識別データに対応する仮予約番号を識別する（Ｓ１００４）。続いて、仮予約ＤＢ１５のメンバ基本情報を参照してメンバ識別データに対応するメンバを識別する（Ｓ１００６）。なお、次のいずれかの場合には、それぞれ理由を示して回答の受付を拒否するとよい。
・回答期限が経過している場合（識別した仮予約番号に対応する仮予約ステータスが「依頼中」でない場合）。
・回答済みである場合（識別したメンバに対応する「回答フラグ」が有意である場合）
〔２２〕受信したページ送信要求に回答識別コードが含まれているか否かを判定する（Ｓ１００８）。回答識別コードが含まれていないとき（Ｓ１００８でＮｏ）、仮予約確認ページを生成し（Ｓ１０１０）、ユーザ端末３０に送信し（Ｓ１０１２，図１２）、当該仮予約確認ページを介してユーザ端末３０から回答識別コードを受信し（Ｓ１０１４）、回答（承認／非承認）を識別する（Ｓ１０１６）。一方、回答識別コードが含まれているとき（Ｓ１００８でＹｅｓ）、直ちに回答（承認／非承認）を識別する（Ｓ１０１６）。

〔２３〕仮予約ＤＢ１５のメンバ管理情報を更新する。ここでは、「回答フラグ」を立てるとともに、識別した回答が「承認」であれば「承認フラグ」を立てる（Ｓ１０１８）。続いて、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「未回答メンバ数」から１を減算する（Ｓ１０２０）。
〔２４〕識別した回答が「承認」であるか否かを判定する（Ｓ１１２２）。回答が「承認」であるとき（Ｓ１１２２でＹｅｓ）、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「参加決定済メンバ数」に１を加算する（Ｓ１１２４）。続いて、参加決定済メンバ数が定員の合計に等しいか否かを判定する（Ｓ１１３２）。なお、定員の合計は、仮予約ＤＢ１５の仮予約基本情報中、「仮注文数」と「定員」との積である。参加決定済メンバ数が定員の合計に等しくないとき（Ｓ１１３２でＮｏ）、又は、識別した回答が「承認」でないとき（Ｓ１１２２でＮｏ）、未回答メンバ数が０であるか否かを判定する（Ｓ１１３４）。

〔２５〕参加決定済メンバ数が定員の合計に等しいとき（Ｓ１１３２でＹｅｓ）、又は、未回答メンバ数が０であるとき（Ｓ１１３４でＹｅｓ）、注文数を確定し（Ｓ１１３６）、新たな予約番号を付与して確定した注文数の予約情報を登録する（Ｓ１１３８）。なお、登録される予約情報の「注文数」は、仮予約管理情報の「仮注文数」に等しい。続いて、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「仮予約ステータス」を「終了」に変更する（Ｓ１１４０）。
〔２６〕未回答メンバ数が０でないとき（Ｓ１１３４でＮｏ）、又は、仮予約ステータスの更新後、仮予約確認ページを生成し（Ｓ１１４２）、ユーザ端末３０に送信する（Ｓ１１４４，図１３）。また、仮予約ＤＢ１５の仮予約管理情報に変動があった旨等を電子メールでユーザ端末２０に通知する（Ｓ１１４６）。

［（ｂ）ページ送信要求］
図７（ｃ）に、ページ送信要求Ａの主要な項目を示す。
図７（ｃ）に示すように、１件のページ送信要求Ａは、「仮予約識別データ」，「メンバ識別データ」及び「回答識別コード」を含んでいる。
図７（ｄ）に、ページ送信要求Ｂの主要な項目を示す。
図７（ｄ）に示すように、１件のページ送信要求Ｂは、「仮予約識別データ」及び「メンバ識別データ」を含んでいるが、「回答識別コード」を含んでいない。
なお、ページ送信要求（Ａ，Ｂ）はＨＴＴＰリクエストであり、「仮予約識別データ」，「メンバ識別データ」及び「回答識別コード」はＵＲＬパラメータである（図９の９３３参照）。

［（ｃ）仮予約確認ページ］
図１２に、回答前の仮予約確認ページの表示例を示す。
図１２に示すように、仮予約確認ページ１２００は、エリア１２１０，１２２０及び１２３０を含んでいる。また、メンバは、回答のためのボタン１２４１又は１２４２をクリックすることにより、幹事からの承認依頼に対して回答することができる。
エリア１２１０には、仮予約に関連する情報が表示される。表示される情報は、例えば、仮予約に係る宿泊施設（又は客室）の詳細ページへのリンク，１人当たりの費用等である。

エリア１２２０には、仮予約中の客室の情報が表示される。ここでは、参加決定済メンバ数を定員で除して得られる商以下で最大の整数を宿泊プランの確定見込数とし、確定見込数分の客室の表示態様を変更して表示する。図１２の表示例では、参加決定済メンバ数３（「Ａ」，「Ｄ」，「Ｅ」の３名）を定員２で除して得られる商以下で最大の整数１が確定見込数であり、「１部屋目」の表示態様が変更されている。
このように、仮予約確認ページに宿泊プランの確定見込数に関する情報を表示することにより、メンバが参加の有無を判断しやすくなる。

エリア１２３０には、メンバの情報が表示される。ここでは、全メンバの名前又はニックネームと、参加／不参加／未回答の別が表示される。参加／不参加／未回答の別は、メンバ管理情報の「回答フラグ」，「承認フラグ」により特定することができる。図１２の表示例では、参加決定済のメンバ（「Ａさん」，「Ｄさん」，「Ｅさん」）の表示態様が変更されている。
このように、仮予約確認ページに各メンバの回答状況に関する情報を表示することにより、メンバが参加の有無を判断しやすくなる。

図１３に、回答後の仮予約確認ページの表示例を示す。仮予約確認ページ１３００は、メンバ（「Ｂ」）が、承認依頼メール９００（図９）中のＵＲＬ９３３（「参加する」に対応するもの）、又は仮予約確認ページ１２００（図１２）中のボタン１２４１（「参加する」と表示されているもの）をクリックし、回答（承認）した直後の表示例である。
仮予約確認ページ１３００の構成は、回答のためのボタンが配置されない点を除き、仮予約確認ページ１２００（図１２）と同様である。

エリア１３２０には、仮予約中の客室の情報が表示される。図１３の表示例では、参加決定済メンバ数４（「Ａ」，「Ｂ」，「Ｄ」，「Ｅ」の４名）を定員２で除して得られる商以下で最大の整数２が確定見込数であり、「２部屋目」の表示態様がさらに変更されている（１３２１）。
エリア１３３０には、メンバの情報が表示される。図１３の表示例では、新たに参加が決定したメンバ（「Ｂさん」）の表示態様がさらに変更されている（１３３１）。

［３−３．回答状況の確認］
サーバシステム１０を利用した回答状況の確認手順を、図１４〜図１７（特に、図１４のフロー図）を参照して説明する。
図１４中には、参照すべき他の図面の番号が付記されている。必要に応じて、当該他の図面を参照されたい。

［（ａ）回答状況の確認手順］
図１４に、回答状況の確認手順を示す。
ここでは、回答状況の提示に引き続き、幹事の操作に応じて追加メンバの登録・承認依頼メールの送信を実行する場合を例として説明する。この手順により、例えば参加メンバに欠員が生じることが判明した場合に、新たなメンバを追加募集することが可能である。
図１４に示すように、サーバシステム１０は、下記〔３１〕〜〔３４〕の手順により回答を受け付ける。

〔３１〕ユーザ端末２０からページ送信要求を受信する（Ｓ１４０５）と、仮予約番号を識別し（Ｓ１４１０）、幹事のユーザＩＤを識別する（Ｓ１４１５）。ここでは、ユーザＩＤ及びパスワードを用いて予め幹事を認証しているものとし、ページ送信要求とともに受信した仮予約を指定する情報（ここでは、仮予約番号）により仮予約を識別し、同じくメンバを特定する情報（ここでは、クッキーのセションＩＤ）により幹事のユーザＩＤを識別するものとする。なお、仮予約情報の変動の通知（図１１のＳ１１４６で送信する電子メール）に仮予約及び幹事を識別する情報をパラメータとして含むＵＲＬを記載しておき、ユーザ端末２０から当該パラメータを含むＵＲＬを指定したページ送信要求を受信してもよい。

〔３２〕識別した仮予約番号に係る仮予約確認ページを生成し（Ｓ１４２０）、ユーザ端末２０に送信する（Ｓ１４２５，図１５）。
〔３３〕仮予約確認ページ（図１６）を介してユーザ端末２０から追加メンバ登録情報を受信し（Ｓ１４３０）たとき、仮予約ＤＢ１５に追加メンバ情報を登録し（Ｓ１４３５）、承認依頼メールを生成して追加メンバのメールアドレス宛に送信する（Ｓ１４４０，図９）。
〔３４〕仮予約確認ページを生成し（Ｓ１４４５）、ユーザ端末２０に送信する（Ｓ１４５０，図１７）。

［（ｂ）仮予約確認ページ］
図１５に、追加メンバ登録前の仮予約確認ページの表示例を示す。
図１５に示すように、仮予約確認ページ１５００は、エリア１５１０，１５２０及び１５３０を含んでいる。また、幹事は、ボタン１５４１，１５４２をクリックすることにより、回答を打ち切って直ちに予約を確定し、又は、仮予約をキャンセルすることができる。
エリア１５１０には、仮予約に関連する情報が表示される。表示される情報は、例えば、仮予約に係る宿泊施設（又は客室）の詳細ページへのリンク，費用の合計，仮予約期間等である。

エリア１５２０には、仮予約中の客室の情報が表示される。ここでは、参加決定済メンバ数を定員で除して得られる商以下で最大の整数を宿泊プランの確定見込数とし、確定見込数分の客室の表示態様を変更して表示する（仮予約確認ページ１２００（図１２）のエリア１２２０と同様）。
このように、仮予約確認ページに宿泊プランの確定見込数に関する情報を表示することにより、幹事が仮予約の進捗を把握しやすくなる。

エリア１５３０には、メンバの情報が表示される。ここでは、幹事を除くメンバのニックネームと、参加／不参加／未回答の別が表示される。参加／不参加／未回答の別は、メンバ管理情報の「回答フラグ」，「承認フラグ」により特定することができる。
このように、仮予約確認ページに各メンバの回答状況に関する情報を表示することにより、幹事が各メンバの回答状況を把握しやすくなる。
また、エリア１５３０では、メッセージ欄にメッセージを入力し、ボタン１５３１をクリックすることにより、未回答のメンバに対して承認依頼メールを再送信し、回答期限が迫っている旨等の注意を喚起することができる。

エリア１５３０では、メンバを追加し、承認依頼メールを送信することができる。
追加メンバに対する承認依頼メールの送信手順は、次のとおりである。
（１）ボタン１５３２をクリックし、ニックネーム及びメールアドレスの入力欄、並びに追加メンバへのメール送信ボタンを追加する（図１６）。なお、これらの処理は、仮予約確認ページ１５００に組み込んだスクリプト（ＪａｖａＳｃｒｉｐｔ等）により制御する。
（２）追加された入力欄１５３３に、追加メンバのニックネームとメールアドレスとを入力する。
（３）必要に応じて、承認依頼メールに記載するメッセージを変更し又は入力する。なお、メッセージの入力欄には、当初のメンバに送信した承認依頼メール９００（図９）に記載したメッセージがデフォルトで入力されているものとする。
（４）ボタン１５３４をクリックし、追加メンバ情報の登録及び承認依頼メールの送信を要求する。

また、仮予約確認ページ（例えば、仮予約確認ページ１５００（図１５））において、幹事が端末を操作することにより、確定済み（確定見込み）の部屋に対し、参加が決定したメンバのグルーピング（部屋割り）を行うことができる。
図１５の表示例では、確定済み（確定見込み）の部屋（「１部屋目」・「２部屋目」）に対し、参加決定済みのメンバ（「Ａさん」（幹事）並びに「Ｂさん」，「Ｄさん」及び「Ｅさん」）の部屋割りを決定することができるようにするとよい。具体的には、「１部屋目」に「Ａさん」（幹事）と「Ｄさん」を割り当て、「２部屋目」に「Ｅさん」と「Ｂさん」を割り当てることができるように構成するとよい。

［（ｃ）追加メンバ登録情報］
図７（ｅ）に、追加メンバ登録情報の主要な項目を示す。
図７（ｅ）に示すように、１件の追加メンバ登録情報は、「仮予約番号」，「メッセージ」，追加メンバ（１，２，…）の「ニックネーム」及び「メールアドレス」を含んでいる。
なお、仮予約番号を特定することが可能な情報（例えば、クッキーのセションＩＤ）により仮予約番号が特定できる場合には、上記「仮予約番号」が含まれていなくてもよい。

［（ｄ）仮予約確認ページ］
図１７に、追加メンバ登録後の仮予約確認ページの表示例を示す。仮予約確認ページ１７００は、メンバ（「Ｇ」）が追加された直後の状態を示す。
仮予約確認ページ１７００の構成は、仮予約確認ページ１５００（図１５）と同様である。
図１７の表示例では、エリア１７３０内に、新たなメンバ（「Ｇ」）が「未回答」のメンバとして追加されている（１７３５）。

［３−４．バッチ処理］
サーバシステム１０によるバッチ処理の手順を、図１８及び図１９（特に、図１８のフロー図）を参照して説明する。
図１８中には、参照すべき他の図面の番号が付記されている。必要に応じて、当該他の図面を参照されたい。

ここでは、次の３段階の処理手順を例として説明する。本実施形態では、夜間バッチ処理により、下記の（ａ），（ｂ），（ｃ）の順に実行するものとする。
（ａ）回答受付の打切…回答期限が経過している仮予約の回答受付を打ち切る。
（ｂ）予約情報の登録…注文数未確定の仮予約に係る注文数を確定し、予約情報を登録する。
（ｃ）予約成立の通知…予約が成立した旨の情報を、施設，幹事を含むメンバにそれぞれ通知する。
なお、上記（ｃ）の処理のみ、バッチ処理を起動する間隔を短く設定してもよい。これにより、回答期限の経過以外の理由により回答受付が打ち切られた場合（例えば、図１１のＳ１１４０の処理で回答受付が打ち切られた場合等）に、予約の成立をより早い時期に通知することができる。

［（ａ）回答受付の打切］
図１８（ａ）に、回答受付の打切手順を示す。
図１８（ａ）に示すように、サーバシステム１０は、下記〔４１〕〜〔４２〕の手順により回答受付を打ち切る。
〔４１〕所定の抽出条件を満たす仮予約番号を抽出する（Ｓ１８０５ａ）。ここでは、図１９（ａ）に示すように、仮予約ステータスが「依頼中」であり（条件Ａ１）、かつ、回答期限が既に経過している（条件Ａ２）仮予約に係る仮予約番号を抽出する。
〔４２〕仮予約ステータスを「確認中」に更新する（Ｓ１８１０ａ）。

［（ｂ）予約情報の登録］
図１８（ｂ）に、予約情報の登録手順を示す。
図１８（ｂ）に示すように、サーバシステム１０は、下記〔５１〕〜〔５４〕の手順により予約情報を登録する。
〔５１〕所定の抽出条件を満たす仮予約番号を抽出する（Ｓ１８０５ｂ）。ここでは、図１９（ｂ）に示すように、仮予約ステータスが「確認中」である（条件Ｂ）仮予約に係る仮予約番号を抽出する。
〔５２〕注文数を確定し（Ｓ１８１０ｂ）、新たな予約番号を付与して、確定した注文数の予約情報を予約ＤＢ１４に登録する（Ｓ１８２０ｂ）。ここでは、図１９（ｃ）に示すように、参加決定済メンバ数を定員で除して得られる商以上で最小の自然数を、予約情報の「注文数」とする。
〔５３〕予約不成立の仮予約を解除する（Ｓ１８２５ｂ）。ここでは、図１９（ｄ）に示すように、仮予約基本情報の「仮注文数」から上記〔５２〕で確定した「注文数」を減じて得られる差を、仮予約の「解除数」とする。
〔５４〕仮予約ステータスを「終了」に更新する（Ｓ１８３０ｂ）。

［（ｃ）予約成立の通知］
図１８（ｃ）に、予約成立の通知手順を示す。
図１８（ｃ）に示すように、サーバシステム１０は、下記〔６１〕〜〔６３〕の手順により予約の成立を通知する。
〔６１〕所定の抽出条件を満たす仮予約番号を抽出する（Ｓ１８０５ｃ）。ここでは、図１９（ｅ）に示すように、仮予約ステータスが「終了」である（条件Ｃ）仮予約に係る仮予約番号を抽出する。
〔６２〕予約が成立した旨等を電子メールで通知する（Ｓ１８１０ｃ）。ここでは、通知先を幹事，幹事以外のメンバ及び仮予約に係る宿泊施設とする。宛先のメールアドレスは、ユーザＤＢ１１のユーザ情報（図４（ａ）），仮予約ＤＢ１５のメンバ基本情報（図５（ｅ−３）），施設ＤＢ１２の施設基本情報（図４（ｂ−１））からそれぞれ抽出する。
〔６３〕仮予約ステータスを「閉鎖」に更新する（Ｓ１８１５ｃ）。

［４．変形例］
［（ａ）メンバ情報の扱い］
上述の実施形態では、ユーザ端末２０からメンバ登録情報を受信して、仮予約ＤＢ１５にメンバ情報を登録している（図６のＳ６３０，Ｓ６３５）。
これに対し、各メンバから情報の登録（又はメールの送信）について承認が得られた場合に限りメンバ情報を登録することとしてもよい。メンバから承認が得られない場合には、仮予約及び予約に係る電子メールを送信しない。

また、メンバ情報を一切登録しないこととしてもよい。
メンバ情報を登録しない場合には、上述の実施形態を次のように変形するとよい。
・承認依頼メール（図９）に、承認（宿泊への参加）に対応するＵＲＬのみを記載する。このＵＲＬのパラメータには、仮予約識別データと複数回の回答を排除するための識別データのみが含まれる。
・仮予約確認ページの送信要求を受信したとき、仮予約番号を識別し、当該識別した仮予約番号に対応する「参加決定済メンバ数」（図５（ｅ−２））に１を加算する。ここでは、全ての回答を「承認」とみなしている。なお、複数回の回答を排除するための識別データを識別し、同一のメンバからの２回目以降の回答であると判定したときは、「参加決定済メンバ数」を更新しない。
・「参加決定済メンバ数」が定員の合計に等しければ、注文数の確定処理以降（図１１のＳ１１３６）と同様の処理を実行する。
・メンバごとの回答内容（未回答／参加／不参加の別）を記憶しない。仮予約確認ページ（図１２，図１５等）には、メンバの情報として参加決定済メンバ数等を表示する。

一方、他の予約又は仮予約の際に登録済みのメールアドレスがあれば、そのメールアドレスを幹事に選択させてもよい。この場合、幹事はメールアドレスの入力を省略することができる。
サーバシステム１０は、例えば次の手順により、メンバのメールアドレスを特定する。なお、ユーザＩＤごとに、仲間（メンバ）の情報（メールアドレスを含む）が登録してあるものとする。
（１）登録されている仲間（メンバ）のリストを所定のページに表示する。
（２）ユーザ端末２０から、上記リスト中の１又は複数のメンバを指定する情報を受信する。
（３）受信した情報によりメンバのメールアドレスを特定する。

［（ｂ）回答の受付］
「仮予約識別データ」，「メンバ識別データ」，「回答識別コード」を電子メールにより受信してもよい。
例えば、承認依頼メールの返信先（Ｒｅｐｌｙ−Ｔｏ）に所定のメールアドレスを設定しておき、承認依頼メールに対する返信メールにより「仮予約識別データ」，「メンバ識別データ」，「回答識別コード」等を受信する。サーバシステム１０は、受信した返信メールから「仮予約識別データ」，「メンバ識別データ」，「回答識別コード」を抽出し、仮予約番号，メンバ，回答を識別するとよい。
なお、上記の場合には、「メンバ識別データ」に代えて、返信メールの送信元メールアドレスによりメンバを識別することもできる。

［（ｃ）回答期限の注意喚起］
注意喚起のため、回答期限の数日前に、幹事に対し電子メールを送信してもよい。これにより、幹事はユーザ端末２０を操作して、未回答のメンバに対し承認依頼メールを再度送信する機会を得ることができる。なお、承認依頼メールの再送信要求は、図１５のエリア１５３０から行う。
また、同様に注意喚起のため、回答期限の数日前に、未回答メンバに対し電子メールを送信してもよい。

［（ｄ）アフィリエイトプログラムの適用］
アフィリエイトとは、例えば、「オンラインサイトで販売されている商品をユーザ個人のブログ、ホームページ等で紹介し、その照会を通じて他のユーザがその商品を購入した場合に、その紹介をしたユーザに報酬を供与するサービス」と定義することができる。
上記の定義中、「商品」を「宿泊サービス」に、「ブログ、ホームページ等で紹介」を「電子メールで勧誘」に置き換えれば、本実施形態のシステムにより実現される宿泊予約手続の過程に上記アフィリエイトサービスをそのまま適用することができる。
具体的には、紹介者（勧誘者）である幹事を識別するためのパラメータを、回答のためのＵＲＬ（承認依頼メール９００（図９）のＵＲＬ９３３）に付加しておけばよい。

＜他の実施形態＞
上述の実施形態では、仮予約から予約に転換する宿泊プランの注文数を一定の条件が満たされた時点で確定し、予約情報を一括で登録している（図１１のＳ１１３６，Ｓ１１３８，図１８（ｂ）のＳ１８１０ｂ，Ｓ１８２０ｂ）。
これに対し、一定の条件が満たされるごとに一部の宿泊プランについての仮予約を予約に転換し、リアルタイムで予約情報を登録してもよい。

［（ａ）回答受付手順］
図２０に、回答受付手順の変形例を示す。
ここでは、図１０に示す手順による仮予約情報の更新に引き続き、図２０に示す手順による回答内容及び回答数に基づく条件判定を経て予約情報の登録を実行する場合を例として説明する。この手順により、回答期限が未だ経過していなくても、仮予約期間中のより早い時期に一部の宿泊プランを対象とする予約を成立させることができる。早期に予約の成否が決定するため、特に宿泊施設側にとって都合がよいと考えられる。
図２０に示すように、サーバシステム１０は、上記〔２１〕〜〔２３〕の手順（図１０のＳ１００２〜Ｓ１０２０）に引き続き、下記〔７１〕〜〔７５〕の手順により回答を受け付ける。
なお、図２０において図１１と同一の符号が付されている処理は、同様の処理である。

〔７１〕識別した回答が「承認」であるか否かを判定する（Ｓ１１２２）。回答が「承認」であるとき（Ｓ１１２２でＹｅｓ）、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「参加決定済メンバ数」に１を加算する（Ｓ１１２４）。
〔７２〕参加決定済メンバ数が定員の倍数であるか否かを判定する（Ｓ２０２６）。定員の倍数であるとき（Ｓ２０２６でＹｅｓ）、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「予約成立プラン数」に１を加算する（Ｓ２０２８）。続いて、新たな予約番号を付与して、予約ＤＢ１４に注文数１の予約情報を登録する（Ｓ２０３０）。

〔７３〕参加決定済メンバ数が定員の合計に等しいか否かを判定する（Ｓ１１３２）。なお、定員の合計は、仮予約ＤＢ１５の仮予約基本情報中、「仮注文数」と「定員」との積である。参加決定済メンバ数が定員の合計に等しくないとき（Ｓ１１３２でＮｏ）、又は、回答が「承認」でないとき（Ｓ１１２２でＮｏ）、又は、参加決定済メンバ数が定員の倍数でないとき（Ｓ２０２６でＮｏ）、未回答メンバ数が０であるか否かを判定する（Ｓ１１３４）。
〔７４〕参加決定済メンバ数が定員の合計に等しいとき（Ｓ１１３２でＹｅｓ）、又は、未回答メンバ数が０であるとき（Ｓ１１３４でＹｅｓ）、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「仮予約ステータス」を「終了」に変更する（Ｓ１１４０）。
〔７５〕未回答メンバ数が０でないとき（Ｓ１１３４でＮｏ）、又は、仮予約ステータスの更新後、仮予約確認ページを生成し（Ｓ１１４２）、ユーザ端末３０に送信する（Ｓ１１４４，図１３）。また、仮予約ＤＢ１５の仮予約管理情報に変動があった旨等を電子メールでユーザ端末２０に通知する（Ｓ１１４６）。なお、仮予約確認ページの表示は仮予約確認ページ１３００（図１３）と同様であるが、客室の情報を表示するエリア（図１３ではエリア１３２０）の「確定見込数」は、「予約成立プラン数」（すなわち、確定数）となる。

［（ｂ）バッチ処理］
図２１に、バッチ処理の変形例を示す。
図２１に示すバッチ処理は、図１８（ｂ）に示すバッチ処理の変形例である。したがって、図１８（ａ）に示すバッチ処理に引き続いて図２１に示すバッチ処理を実行し、図２１に示すバッチ処理に引き続いて図１８（ｃ）に示すバッチ処理を実行するものとする。
図２１に示すように、サーバシステム１０は、下記〔８１〕〜〔８４〕の手順により回答を受け付ける。
なお、図２１において図１８（ｂ）と同一の符号が付されている処理は、同様の処理である。

〔８１〕所定の抽出条件を満たす仮予約番号を抽出する（Ｓ１８０５ｂ）。ここでは、図１９（ｂ）に示すように、仮予約ステータスが「確認中」である（条件Ｂ）仮予約に係る仮予約番号を抽出する。
〔８２〕参加決定済メンバ数が定員の倍数であるか否かを判定する（Ｓ２１１０ｂ）。定員の倍数でないとき（Ｓ２１１０ｂでＮｏ）、仮予約ＤＢ１５の仮予約管理情報を更新する。ここでは、「予約成立プラン数」に１を加算する（Ｓ２１１５ｂ）。続いて、新たな予約番号を付与して、注文数１の予約情報を予約ＤＢ１４に登録する（Ｓ２１２０ｂ）。
〔８３〕参加決定済メンバ数が定員の倍数であるとき（Ｓ２１１０ｂでＹｅｓ）、又は、予約情報の登録後、予約不成立の仮予約を解除する（Ｓ１８２５ｂ）。ここでは、図１９（ｄ）に示すように、仮予約基本情報の「仮注文数」から仮予約管理情報の「予約成立プラン数」（＝注文数）を減じて得られる差を、仮予約の「解除数」とする。
〔８４〕仮予約ステータスを「終了」に更新する（Ｓ１８３０ｂ）。

［（ｃ）関連する予約情報の紐付け］
上述の実施形態では、仮予約から予約に転換する宿泊プランの注文数を一定の条件が満たされた時点で確定し、予約情報を一括で登録している（図１１のＳ１１３６，Ｓ１１３８）。そのため、１件の仮予約から転換した予約に係る予約情報は１件のみである。
これに対し、一定の条件が満たされるごとに一部の宿泊プランについての仮予約を予約に転換し、予約情報を順次登録する場合には、１件の仮予約から転換した予約に係る予約情報が複数件になる可能性もある。

そこで、同一の仮予約から転換した予約に係る予約情報を互いに関連付け、これらを団体宿泊の扱いにするとよい。
例えば、次のように対応するとよい。
・同一の仮予約から転換した予約に係る予約情報を、予約ＤＢ１４中で互いに関連付ける。例えば、予約情報において「仮予約番号」を必須項目とする（図５（ｄ）参照）。
・「予約成立プラン数」（仮予約ＤＢ１５の仮予約管理情報）が複数であれば、予約の確定を通知する電子メール（特に、宿泊施設のメールアドレス宛に送信するメール）等に団体宿泊扱いである旨等を記載して注意喚起する。このとき、予約ＤＢ１４において同一の仮予約番号を有する予約番号をすべて読み出し、リストにして宿泊施設に通知するとよい。

＜補足＞
本実施形態のシステム又は他の実施形態のシステムは、宿泊プランの「在庫数」と客室の「空室数」とを整合させるため、内部的に種々の処理を実行している。
なお、前提として、宿泊プランの「在庫数」と客室の「空室数」との関係は、次のようになっている。
・各施設は、宿泊日ごとに、部屋タイプの提供数を設定する。この提供数が、空室管理情報（図４（ｂ−４））の「空室数」の初期値に当たる。
・各施設は、宿泊日ごとに、特定の部屋タイプの客室を、上記「空室数」を上限として宿泊プランに割り当てる。ここで割り当てた数が、客室割当情報（図４（ｂ−３））の「割当数」である。なお、上記「空室数」を超えない限り、複数の宿泊プランに対し客室を重複して割り当てることができる。

内部処理の手順は、概ね次のとおりである。
［（ａ）仮予約情報の登録時］
（１）仮予約申請に係る「宿泊プランＩＤ」に対応する「在庫数」（図４（ｃ−２））から「仮注文数」を減算する。
（２）上記（１）で減算した「在庫数」→「宿泊プランＩＤ」（図４（ｃ−２））、「宿泊プランＩＤ」→「施設ＩＤ」・「宿泊日」・「部屋タイプ」（図４（ｃ−１））、「施設ＩＤ」・「宿泊日」・「部屋タイプ」→「空室数」（図４（ｂ−４））と辿り、「空室数」（図４（ｂ−４））から「仮注文数」を減算する。同時に、「仮予約中部屋数」（図４（ｂ−４））に「仮注文数」を加算する。
（３）上記（２）で減算した「空室数」→「施設ＩＤ」・「宿泊日」・「部屋タイプ」（図４（ｂ−４））、「施設ＩＤ」・「宿泊日」・「部屋タイプ」→「宿泊プランＩＤ」（図４（ｂ−３））、「宿泊プランＩＤ」→「在庫数」（図４（ｃ−２））と辿り、仮予約申請の対象でない「宿泊プランＩＤ」に対応する「在庫数」のうち、上記（２）で減算した「空室数」を上回る分を減算する。

［（ｂ）予約情報の登録時］
（１）予約情報に転換した仮予約情報に係る「仮予約番号」→「宿泊プランＩＤ」（図５（ｄ））、「宿泊プランＩＤ」→「施設ＩＤ」・「宿泊日」・「部屋タイプ」（図４（ｃ−１））、「施設ＩＤ」・「宿泊日」・「部屋タイプ」→「仮予約中部屋数」（図４（ｂ−４））と辿り、「仮予約中部屋数」（図４（ｂ−４））から「注文数」を減算する。
（２）「予約済部屋数」（図４（ｂ−４））に「注文数」を加算する。

［（ｃ）仮予約の解除時］
（１）一部解除に係る「宿泊プランＩＤ」に対応する「在庫数」（図４（ｃ−２））に「解除数」を加算する。
（２）上記（１）で加算した「在庫数」→「宿泊プランＩＤ」（図４（ｃ−２））、「宿泊プランＩＤ」→「施設ＩＤ」・「宿泊日」・「部屋タイプ」（図４（ｃ−１））、「施設ＩＤ」・「宿泊日」・「部屋タイプ」→「空室数」（図４（ｂ−４））と辿り、「空室数」（図４（ｂ−４））に「解除数」を加算する。同時に、「仮予約中部屋数」（図４（ｂ−４））から「解除数」を減算する。
（３）上記（２）で加算した「空室数」→「施設ＩＤ」・「宿泊日」・「部屋タイプ」（図４（ｂ−４））、「施設ＩＤ」・「宿泊日」・「部屋タイプ」→「宿泊プランＩＤ」（図４（ｂ−３））、「宿泊プランＩＤ」→「在庫数」（図４（ｃ−２））と辿り、解除の対象でない「宿泊プランＩＤ」に対応する「在庫数」に、「割当数」（図４（ｂ−３））を限度として「解除数」を加算する。

１０ サーバシステム
１１ ユーザＤＢ
１２ 施設ＤＢ
１３ 宿泊プランＤＢ
１４ 予約ＤＢ
１５ 仮予約ＤＢ
２０ ユーザ端末（幹事）
３０ ユーザ端末（メンバ）
４０ 施設端末
５０ インターネット
８００ 仮予約確認ページ
９００ 承認依頼メール
１２００ 仮予約確認ページ
１３００ 仮予約確認ページ
１５００ 仮予約確認ページ
１７００ 仮予約確認ページ

Claims (8)

1. 複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムのサーバシステムであって、
   宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、
   予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、
   仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段と
   を有し、
   前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信手段と、
   前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録手段と、
   前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定手段と、
   前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信手段と、
   前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付手段と、
   前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定手段と、
   予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録手段と
   を備える
   ことを特徴とするサーバシステム。
2. 請求項１に記載のサーバシステムにおいて、
   前記回答受付手段は、さらに、前記識別した仮予約番号に対応する仮注文数を前記仮予約情報記憶手段より読み出し、前記更新後の参加決定済メンバ数が宿泊プランの定員と該仮注文数との積に等しいとき、該仮予約番号に係る仮予約について回答の受付を打ち切る
   ことを特徴とするサーバシステム。
3. 請求項１又は２に記載のサーバシステムにおいて、
   所定の条件を満たすとき、特定した仮予約番号に対応する参加決定済メンバ数を前記仮予約情報記憶手段より読み出し、該参加決定済メンバ数が宿泊プランの定員の倍数でなければ注文数１の予約が成立すると判定する第二の予約成否判定手段をさらに備える
   ことを特徴とするサーバシステム。
4. 請求項３に記載のサーバシステムにおいて、
   前記仮予約情報記憶手段は、予約成立プラン数をさらに記憶することが可能であり、
   前記仮予約情報記憶手段に記憶している前記予約が成立すると判定された仮予約に係る仮予約番号に対応する予約成立プラン数に１を加算する予約成立数計数手段と、
   前記所定の条件を満たすとき、さらに、前記特定した仮予約番号に対応する宿泊プランの識別情報と、仮注文数と、予約成立プラン数とを前記仮予約情報記憶手段より読み出し、該仮予約情報記憶手段に記憶している該宿泊プランの識別情報に対応する在庫数に、該仮注文数と該予約成立プラン数との差を加算する予約一部解除手段と
   をさらに備える
   ことを特徴とするサーバシステム。
5. 請求項３又は４に記載のサーバシステムにおいて、
   前記仮予約情報記憶手段は、前記仮予約番号に対応させて、回答期限をさら記憶することが可能であり、
   前記仮予約申請情報受信手段は、回答期限をさらに受信し、
   前記仮予約情報登録手段は、前記受信した回答期限を前記仮予約番号に対応付けて前記仮予約情報記憶手段にさらに書き込み、
   前記第二の予約成否判定手段は、前記仮予約情報記憶手段に記憶しているいずれかの仮予約番号に対応する回答期限が経過しているとき、該回答期限が経過している仮予約番号を特定し、該特定した仮予約番号に対応する予約の成否を判定する
   ことを特徴とするサーバシステム。
6. 請求項１〜５のいずれかに記載のサーバシステムにおいて、
   前記予約情報記憶手段は、各予約番号を対応する仮予約番号に関連付けて記憶することが可能であり、
   前記予約情報一部登録手段は、前記予約が成立すると判定された仮予約に係る仮予約番号と前記新たな予約番号とを関連付けて前記予約情報記憶手段に登録する
   ことを特徴とするサーバシステム。
7. 複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムにおけるグループ予約支援方法であって、
   宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、
   予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、
   仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段と
   を有するサーバシステムが、
   前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信ステップと、
   前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録ステップと、
   前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定ステップと、
   前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信ステップと、
   前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付ステップと、
   前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定ステップと、
   予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録ステップと
   を実行することを特徴とするグループ予約支援方法。
8. 複数のメンバから成るグループを構成する各メンバの端末と、該グループを代表する幹事がＷｅｂページを介して行う宿泊プランの予約手続を支援するサーバシステムとが通信ネットワークを介して接続しているグループ予約支援システムにおけるグループ予約支援プログラムであって、
   宿泊プランの識別情報に対応させて、該宿泊プランの定員及び該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段と、
   予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び該宿泊プランの注文数を記憶することが可能な予約情報記憶手段と、
   仮予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報，該宿泊プランの仮注文数及び参加決定済メンバ数を記憶することが可能な仮予約情報記憶手段と
   を有するサーバシステムに、
   前記幹事の識別情報と、前記宿泊プランの識別情報と、該宿泊プランの仮注文数とを該幹事の端末から受信する仮予約申請情報受信ステップと、
   前記受信した宿泊プランの識別情報に対応する在庫数を前記宿泊プラン情報記憶手段より読み出し、該在庫数が前記受信した仮注文数以上であれば、該宿泊プラン情報記憶手段に記憶している該在庫数から該仮注文数を減算するとともに、前記受信した各項目を仮予約番号に対応付けて前記仮予約情報記憶手段に書き込む仮予約情報登録ステップと、
   前記幹事の端末から受信した情報により該幹事以外の各メンバのメールアドレスを特定するメンバ情報特定ステップと、
   前記仮予約番号に対応する仮予約識別データを少なくとも含む承認依頼メールを生成し、該承認依頼メールを前記特定した各メールアドレス宛に送信する承認依頼メール生成送信ステップと、
   前記幹事以外のメンバの端末から前記仮予約識別データを受信したとき、該仮予約識別データに対応する仮予約番号を識別し、前記仮予約情報記憶手段に記憶している該仮予約番号に対応する参加決定済メンバ数を更新する回答受付ステップと、
   前記更新後の参加決定済メンバ数が宿泊プランの定員の倍数となるごとに、注文数１の予約が成立すると判定する第一の予約成否判定ステップと、
   予約が成立すると判定された仮予約に係る仮予約番号に対応する幹事の識別情報と宿泊プランの識別情報とを前記仮予約情報記憶手段より読み出し、該幹事の識別情報と、該宿泊プランの識別情報と、注文数１とを新たな予約番号に対応させて前記予約情報記憶手段に書き込む予約情報一部登録ステップと
   を実行させるためのグループ予約支援プログラム。

Images