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

Abstract

【課題】グループを代表して宿泊の予約手続を行うユーザに対し、予約中の宿泊内容を柔軟に変更する仕組みを提供する。
【解決手段】〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。〔２〕上記グループにメンバＧが加入し、合計人数が７人になる。〔３〕予約中の宿泊プランに係る宿泊施設・宿泊日程と施設・日程がそれぞれ同一であり、かつ、定員が４以上の客室に対応する宿泊プランを検索する。〔４〕検索された宿泊プランの中から所望のプランを追加で予約するとともに、メンバＤ〜Ｆが割り当てられていた２部屋目の客室に係る宿泊プランの予約を削除（キャンセル）する（図１（ｂ））。
【選択図】図１

Description

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

＜先行技術１＞
オンライン宿泊予約サイトにおいて、宿泊施設を検索するサービス、宿泊の予約を受け付けるサービスが提供されている（例えば、非特許文献１参照）。
同サイトを利用すれば、例えば、「日程」，「キーワード」（施設名・特徴・観光地等），「地域」，「目的・条件」（地域名・駅名・空港名等）等から、空室がある部屋（在庫のある宿泊プラン）を検索し、予約（又は手配）をすることができる。

楽天トラベル株式会社、「楽天トラベル」、[online]、インターネット<URL: http://travel.rakuten.co.jp/index.html>

宿泊施設の客室には、それぞれ定員（宿泊人数の上限）が設定されているのが通常である。そのため、複数のメンバから成るグループ単位で宿泊を予約する場合には、合計人数に応じて必要な客室を確保する必要がある。
とりわけ、予約中の宿泊の内容を柔軟に変更できれば、予約後に合計人数が変動する場合にも対応することができる。

しかしながら、従来のオンライン宿泊予約システムは、予約後の宿泊内容の変更に対応していない。
したがって、予約後に宿泊プラン（客室）を追加したり、予約中の宿泊プラン（客室）の一部又は全部を他の宿泊プラン（異なる部屋タイプの客室）に変更したりすることはできない。

本発明が解決しようとする課題は、グループを代表して宿泊の予約手続を行うユーザに対し、予約中の宿泊内容を柔軟に変更する仕組みを提供する、という点である。

上記課題を解決するため、本発明は、複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末と接続して、グループ予約支援システムを構成するサーバシステムであって、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有し、前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定手段と、宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信手段と、前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録手段とを備えることを特徴とする。

宿泊プランの識別情報に対応させて、該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段をさらに有し、前記宿泊プラン情報記憶手段を参照して、前記指定された宿泊プランの在庫の有無を確認する在庫確認手段と、前記宿泊プラン情報記憶手段に記憶している、前記登録した追加予約情報に係る宿泊プランの在庫数を更新する在庫数更新手段とをさらに備え、前記追加予約情報登録手段は、前記指定された宿泊プランの在庫がある場合に限り、前記追加予約情報を前記予約情報記憶手段に登録してもよい。

前記特定した予約番号に係る予約中の宿泊プランの予約をキャンセルする当初予約キャンセル手段をさらに備え、前記在庫数更新手段は、さらに、前記キャンセルした宿泊プランの在庫数を更新してもよい。

前記幹事の端末からの要求に応じて、前記特定した予約番号に係る予約中の各宿泊プランの情報を配置した予約修正ページを生成し、該幹事の端末に送信する予約修正ページ生成送信手段と、前記予約修正ページを介して宿泊プランの選択情報を前記幹事の端末から受信する選択情報受信手段とをさらに備え、前記当初予約キャンセル手段は、前記受信した選択情報に対応する１又は複数の宿泊プランの予約のみをキャンセルしてもよい。

前記宿泊プラン情報記憶手段は、宿泊プランの識別情報に対応させて、宿泊施設及び宿泊日程をさらに記憶しており、前記特定した予約番号に係る予約中の宿泊プランの宿泊施設及び宿泊日程と施設及び日程がそれぞれ同一の宿泊プランの識別情報を前記宿泊プラン情報記憶手段より抽出する宿泊プラン検索手段と、前記抽出した宿泊プランの識別情報及び／又はこれに対応する情報を配置した検索結果ページを生成し、前記幹事の端末に送信する検索結果出力手段とをさらに備え、前記追加予約申請受信手段は、前記検索結果ページを介して選択指定された宿泊プランの追加予約申請を受信してもよい。

前記在庫確認手段は、さらに、前記特定した予約番号に係る予約中の宿泊プランの宿泊施設及び宿泊日程と施設及び日程がそれぞれ同一の宿泊プランの在庫の有無を確認し、前記宿泊プラン検索手段は、在庫のある宿泊プランの識別情報のみを抽出してもよい。

各施設のメールアドレスを記憶している施設情報記憶手段をさらに有し、予約の修正内容を含む通知メールを生成し、前記特定した予約番号に係る当初の予約又は該予約番号に関連付けられている追加の予約に係る宿泊施設のメールアドレスを前記施設情報記憶手段より抽出し、該通知メールを該メールアドレス宛に送信する通知メール生成送信手段をさらに備えていてもよい。

前記追加予約申請受信手段は、前記幹事の端末から、前記追加予約申請とともに隣接部屋リクエストをさらに受信し、前記通知メール生成送信手段は、前記追加の予約に係る客室を前記当初の予約に係る客室に隣接させるよう依頼する旨をさらに記載した前記通知メールを生成してもよい。

前記幹事の端末から受信したデータを基に、前記各メンバのメールアドレスを特定するメールアドレス特定手段と、予約の修正内容を含む共有メールを生成し、前記特定した各メールアドレス宛に送信する共有メール生成送信手段とをさらに備えていてもよい。

また、上記課題を解決するため、本発明は、複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末とサーバシステムとを接続して構成したグループ予約支援システムにおけるグループ予約支援方法であって、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有するサーバシステムが、前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定ステップと、宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信ステップと、前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録ステップとを実行することを特徴とする。

また、上記課題を解決するため、本発明は、複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末とサーバシステムとを接続して構成したグループ予約支援システムにおけるグループ予約支援プログラムであって、予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有するサーバシステムに、前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定ステップと、宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信ステップと、前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録ステップとを実行させる。

本発明のサーバシステムとユーザの端末とを接続して構成したグループ予約支援システムを利用すれば、グループを代表して宿泊の予約手続を行うユーザは、予約中の宿泊内容を柔軟に変更することができる。

宿泊修正機能の概要の説明図である。（実施形態） システム構成を示すブロック図である。（実施形態） データベースのデータ項目の説明図である。（実施形態） 予約の修正手順を示すフロー図である。（実施形態） 予約の修正手順を示すフロー図である。（実施形態） 予約確認ページの表示例である。（実施形態） 予約修正ページの表示例である。（実施形態） 予約修正要求のデータ項目の説明図である。（実施形態） 検索結果ページの表示例である。（実施形態） 追加予約申請ページの表示例である。（実施形態） 宿泊修正機能の概要の説明図である。（他の使用例） 宿泊修正機能の概要の説明図である。（他の使用例） 予約データベースのデータ項目の説明図である。（変形例１） 予約データベースのデータ項目の説明図である。（変形例２）

＜定義＞
・宿泊プラン…オンライン宿泊予約サイトにおける予約対象（注文対象）の単位。特定の客室（又は特定の部屋タイプの客室）における少なくとも１泊分の宿泊サービスを必須の要素とし、食事等の付随的なサービスを任意に含む。
・グループ…複数のユーザにより構成される集団。例えば、クラブ，サークル，同好会，ゼミ，研究室，部署等。
・メンバ…グループを構成するユーザ。
・幹事…グループを代表するメンバ。本実施形態では、グループを代表して宿泊予約手続を行うメンバ。

＜実施形態＞
［１．概要］
本実施形態のシステムは、宿泊の予約を受け付けるサービス（宿泊予約サービス）を管理するシステムであり、予約中の宿泊の内容を修正する機能（宿泊修正機能）を提供する。
宿泊修正機能は、例えば次のような修正の態様に対応している。したがって、本実施形態のシステムを利用すれば、グループを代表して宿泊の予約手続を行う幹事は、予約中の宿泊内容を柔軟に変更することができる。

（ａ）宿泊人数を変更する（宿泊プランは変更しない）。
（ｂ）予約中の宿泊プランと同一の宿泊プランを追加する。
（ｃ）予約中の宿泊プランと異なる宿泊プランを追加する。
（ｄ）予約中の宿泊プランの一部を削除（キャンセル）する。
（ｅ）予約中の宿泊プランの一部又は全部を、異なる宿泊プランに変更する。

図１に、修正前後の宿泊内容を例示する。
ここでは、宿泊プランの一部を変更する場合の使用例（上記（ｅ））を説明する。
〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。
〔２〕上記グループにメンバＧが加入し、合計人数が７人になる。
〔３〕予約中の宿泊プランに係る宿泊施設・宿泊日程と施設・日程がそれぞれ同一であり、かつ、定員が４以上の客室に対応する宿泊プランを検索する。
〔４〕検索された宿泊プランの中から所望のプランを追加で予約するとともに、メンバＤ〜Ｆが割り当てられていた２部屋目の客室に係る宿泊プランの予約を削除（キャンセル）する（図１（ｂ））。

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

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

［（ａ）ユーザＤＢ］
図２において、ユーザＤＢ１１は、宿泊予約サービスを利用するユーザの情報を記憶しているデータベースである。
本実施形態では、ユーザ情報及び仲間情報をそれぞれ複数件ずつ記憶しており、これらはキー項目を介して対応しているものとする。

図３（ａ−１）に、ユーザ情報の主要な項目を示す。
図３（ａ−１）に示すように、１件のユーザ情報は、「ユーザＩＤ」，「パスワード」及び「メールアドレス」を含んでいる。
図３（ａ−２）に、仲間情報の主要な項目を示す。
図３（ａ−２）に示すように、１件の仲間情報は、「ユーザＩＤ」，「仲間ＩＤ」，「ニックネーム」及び「メールアドレス」を含んでいる。
なお、仲間のユーザは、ユーザ情報がユーザＤＢ１１に登録されているユーザでもよいし、登録されていないユーザでもよい。

［（ｂ）施設ＤＢ］
図２において、施設ＤＢ１２は、宿泊予約サービスにおいて客室を提供する宿泊施設に関連する情報を記憶しているデータベースである。
図３（ｂ）に、施設情報の主要な項目を示す。
図３（ｂ）に示すように、１件の施設情報は、「施設ＩＤ」，「パスワード」及び「メールアドレス」を含んでいる。

［（ｃ）宿泊プランＤＢ］
図２において、宿泊プランＤＢ１３は、宿泊予約サービスにおいて予約（注文）の対象となる宿泊プランの情報を記憶しているデータベースである。
図３（ｃ）に、宿泊プラン情報の主要な項目を示す。
図３（ｃ）に示すように、１件の宿泊プラン情報は、「宿泊プランＩＤ」，「宿泊日」，「施設ＩＤ」，「部屋タイプ」，「定員」及び「在庫数」を含んでいる。
ここで、「在庫数」は、予約（注文）可能な宿泊プランの数であり、予約の成立・キャンセル等により随時更新される。

［（ｄ）予約ＤＢ］
図２において、予約ＤＢ１４は、宿泊予約サービスにおける予約に関連する情報を記憶するデータベースである。
本実施形態では、予約情報，メンバ情報及び追加予約情報をそれぞれ複数件ずつ記憶することが可能であり、これらはキー項目を介して対応させることができる。

図３（ｄ−１）に、予約情報の主要な項目を示す。
図３（ｄ−１）に示すように、１件の予約情報は、「予約番号」，幹事の「ユーザＩＤ」，「宿泊プランＩＤ」，宿泊プランの「注文数」，その予約に係る「宿泊人数」，「ステータス」及び「追加フラグ」を含んでいる。
ここで、「ステータス」は、その予約の状態（例えば、「予約中」（初期値），「宿泊終了」，「キャンセル」等）を示す区分である。「追加フラグ」は、その予約について関連する追加の予約があるか否かを示すフラグであり、有意のとき追加の予約があることを示す。

図３（ｄ−２）に、メンバ情報の主要な項目を示す。
図３（ｄ−２）に示すように、１件のメンバ情報は、「予約番号」，「メンバＩＤ」，「ニックネーム」，「メールアドレス」及び「不参加フラグ」を含んでいる。
ここで、「不参加フラグ」は、そのメンバが宿泊に不参加であるか否かを示すフラグであり、有意のとき不参加であることを示す。

図３（ｄ−３）に、追加予約情報の主要な項目を示す。
図３（ｄ−３）に示すように、１件の追加予約情報は、「予約番号」，「追加予約番号」及び「隣接部屋リクエストフラグ」を含んでいる。
ここで、「予約番号」は当初の予約に係る予約番号である。「追加予約番号」は追加の予約に係る予約番号である。「隣接部屋リクエストフラグ」は、「追加予約番号」に係る客室を「予約番号」に係る客室に隣接した客室にする旨のリクエストがあるか否かを示すフラグであり、有意のときリクエストがあることを示す。

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

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

なお、各宿泊施設の担当者は、施設端末４０を操作してサーバシステム１０にアクセスし、施設ＩＤとパスワードを入力して認証を受けることにより、与えられた権限の範囲内で予約情報の管理等を行うことができる。
この点は、従来例（例えば、＜先行技術１＞）と同様である。

［３．予約の修正］
宿泊修正機能は、上述のとおり、例えば次のような修正の態様に対応している。
ここでは、宿泊プランの一部を変更する場合の使用例（下記（ｅ））を説明する。
（ａ）宿泊人数を変更する（宿泊プランは変更しない）。
（ｂ）予約中の宿泊プランと同一の宿泊プランを追加する。
（ｃ）予約中の宿泊プランと異なる宿泊プランを追加する。
（ｄ）予約中の宿泊プランの一部を削除（キャンセル）する。
（ｅ）予約中の宿泊プランの一部又は全部を、異なる宿泊プランに変更する。

［（ａ）予約の修正手順］
図４〜５に、予約の修正手順を示す。
図４〜５に示すように、サーバシステム１０は、下記〔１１〕〜〔１６〕の手順により勧誘メールを送信する。
なお、幹事は、従来例（例えば、＜先行技術１＞）と同様のシステムを利用して当初の予約を既に行っているものとする。また、予約ＤＢ１４には、当該幹事に係る予約情報が既に登録されているものとする。
以下の説明は、幹事がユーザ端末２０を操作して、ユーザＩＤ及びパスワードにより宿泊予約サービスにログインし、自らが手続をした当初の予約に係る予約確認ページ（図６）を表示させた後の手順である。

〔１１〕予約確認ページ（図６）を介してユーザ端末２０から予約修正ページの送信要求を受信する（Ｓ４０５）と、予約ＤＢ１４を参照して指定された予約番号に係る予約修正ページを生成し（Ｓ４１０）、ユーザ端末２０に送信する（Ｓ４１５，図７）。
〔１２〕予約修正ページ（図７）を介してユーザ端末２０から予約修正要求（図８）を受信する（Ｓ４２０）と、修正の内容に応じて宿泊プランの検索条件を設定し（Ｓ４２５）、当該検索条件を満たす宿泊プランを宿泊プランＤＢ１３において検索する（Ｓ４３０）。続いて、検索結果を基に検索結果ページを生成し（Ｓ４３５）、ユーザ端末２０に送信する（Ｓ４４０，図９）。

〔１３〕検索結果ページ（図９）を介してユーザ端末２０から宿泊プランの選択情報を受信する（Ｓ４４５）と、当該選択された宿泊プランに係る追加予約申請ページを生成し（Ｓ４５０）、ユーザ端末２０に送信する（Ｓ４５５，図１０）。
〔１４〕追加予約申請ページ（図１０）を介してユーザ端末２０から追加予約申請を受信する（Ｓ４６０）と、予約ＤＢ１４に予約情報及び追加予約情報を登録し（Ｓ４６５）、予約の修正手続が完了した旨等を電子メールでユーザ端末２０に通知する（Ｓ４７０）。
〔１５〕修正後の予約内容等を記載した通知メールを生成し、修正に係る宿泊施設のメールアドレス宛に送信する（Ｓ４７５）。
〔１６〕予約の修正があった旨等を記載した共有メールを生成し、修正に係る予約に関係するメンバのメールアドレス宛に通知する（Ｓ４８０）。

［（ｂ）予約確認ページ］
図６に、予約確認ページの表示例を示す。
図６に示すように、予約確認ページ６００は、エリア６１０〜６３０及びボタン６４０〜６６０を含んでいる。
エリア６１０には、予約中の宿泊プランに係る宿泊施設及び宿泊日程が表示される。エリア６２０には、予約中の宿泊プランの情報（定員，特徴，人数，料金等）が表示される。エリア６３０には、メンバの情報が表示される。
なお、当初の予約に関連付けられている追加の予約があれば（予約ＤＢ１４の予約情報において「追加フラグ」が有意であれば）、当該追加の予約に係る予約中の宿泊プランの情報も、エリア６２０に表示するとよい。

幹事がボタン６５０をクリックすると、ユーザ端末２０はサーバシステム１０に予約修正ページの送信要求を送信する。
なお、幹事はボタン６４０をクリックすることにより、予約中の宿泊プランを特定して、指定したユーザを宿泊に勧誘する手続を行うことができる。また、幹事はボタン６６０をクリックすることにより、予約全体（全ての宿泊プランの予約）をキャンセルする手続を行うことができる。

［（ｃ）予約修正ページ］
図７に、予約修正ページの表示例を示す。
図７に示すように、予約修正ページ７００は、エリア７１０〜７４０を含んでいる。
エリア７１０〜７３０の表示は、予約確認ページ６００（図６）のエリア６１０〜６３０に対応している。幹事はボタン７３１をクリックすることにより、メンバの追加手続を行うことができる。

エリア７４０では、修正後の合計人数及び合計部屋数を指定した上で、修正の態様を選択することができる。例えば、ボタン７４１〜７４５は、それぞれ次の修正態様に対応している。
（ａ）ボタン７４１…宿泊人数を変更する（宿泊プランは変更しない）。
（ｂ）ボタン７４２…予約中の宿泊プランと同一の宿泊プランを追加する。
（ｃ）ボタン７４３…予約中の宿泊プランと異なる宿泊プランを追加する。
（ｄ）ボタン７４４…予約中の宿泊プランの一部を削除（キャンセル）する。
（ｅ）ボタン７４５…予約中の宿泊プランの一部又は全部を、異なる宿泊プランに変更する。

図１（ａ）に示す予約の内容を、図１（ｂ）に示す予約の内容に変更する手順は、例えば、次のとおりである。
〔２１〕幹事が、ボタン７３１をクリックして仲間リスト（図示せず）を表示させ、当該リストの中からメンバになっていない仲間を選択し、メンバに追加する。図７の表示例では、幹事の仲間としてユーザＤＢ１１に仲間情報が登録されているユーザＧがエリア７３０に追加されている。なお、エリア７３０等に所定の入力欄（図示せず）を設けて、追加メンバのニックネーム及びメールアドレスを幹事に直接入力させてもよい。
〔２２〕幹事が、エリア７３０において、不参加のメンバの選択を解除する（チェックを外す）。
〔２３〕幹事が、エリア７２０において、予約中の宿泊プランのうち２部屋目の宿泊プランを選択する（チェックを入れる）。
〔２４〕幹事が、エリア７４０において、合計人数を「７人」に変更し、合計部屋数の「２部屋」を確認し、ボタン７４５をクリックする。
〔２５〕ユーザ端末２０が、サーバシステム１０に予約修正要求を送信する。

［（ｄ）予約修正要求］
図８に、予約修正要求の主要な項目を示す。
図８に示すように、１件の予約修正要求は、予約番号の「識別データ」，修正態様の「識別コード」，修正後の「合計人数」，修正後の「合計部屋数」，「メンバ（１，２，…）の選択フラグ」及び「部屋（１，２，…）の選択フラグ」を含んでいる。
ここで、「識別データ」は、修正対象の予約番号を識別するためのデータであり、本実施形態ではユーザ端末２０内のクッキーファイルに記憶している「セションＩＤ」を利用する。「識別コード」は、修正態様を識別するためのコードであり、予約修正ページ７００（図７）のボタン７４１〜７４５のいずれかに対応する。

［（ｅ）検索処理］
上記手順〔１２〕において、サーバシステム１０は、修正の内容に応じて宿泊プランの検索条件を設定し（Ｓ４２５）、当該検索条件を満たす宿泊プランを宿泊プランＤＢ１３において検索する（Ｓ４３０）。
予約修正要求（図８）を受信すると、サーバシステム１０はまず、必要な部屋数及びその部屋の定員を計算する。
例えば、図７の表示例では、修正前及び修正要求の合計人数及び合計部屋数は次のとおりであるから、定員４以上の部屋を１部屋分検索すればよい。
（修正前） 合計人数６人，合計部屋数２部屋（各３名１室）
（修正要求） 合計人数７人，合計部屋数２部屋，変更対象の宿泊プラン数１
（検索条件） 宿泊人数４人，部屋数１部屋（定員４以上）

続いて、サーバシステム１０は、次の検索条件を設定し、当該検索条件を満たす宿泊プランを宿泊プランＤＢ１３において検索する。
（ａ）選択された宿泊プラン（予約修正ページ７００（図７）のエリア７２０で選択された宿泊プラン）の宿泊施設・宿泊日程と施設・日程が同一である。
（ｂ）当該選択された宿泊プランと異なる。
（ｃ）必要な人数（ここでは、４人）が宿泊可能である（定員≧４）。
（ｄ）必要な部屋数（ここでは、１部屋）の空室がある（在庫数≧１）。

［（ｆ）検索結果ページ］
図９に、検索結果ページの表示例を示す。図９は、予約修正ページ７００（図７）においてボタン７４５をクリックしたときにユーザ端末２０に送信される検索結果ページの表示例である。
図９に示すように、検索結果ページ９００は、エリア９１０及び９２０を含んでいる。

エリア９１０には、現在の検索条件が表示される。図９の表示例では、宿泊施設の条件（ＡＡＡホテル），日程の条件（２００９年１１月１日〜２００９年１１月１日），定員の条件（４名１室で宿泊可能），部屋数の条件（在庫が１以上）が反映されている。
エリア９２０には、検索結果が表示される。各宿泊プランのプラン名部分は、詳細ページへのリンクになっている。
幹事がボタン９２１〜９２３のいずれかをクリックすると、ユーザ端末２０はサーバシステム１０に宿泊プランの選択情報を送信する。

［（ｇ）追加予約申請ページ］
図１０に、追加予約申請ページの表示例を示す。図１０は、検索結果ページ９００（図９）においてボタン９２２をクリックしたときにユーザ端末２０に送信される追加予約申請ページの表示例である。
図１０に示すように、追加予約申請ページ１０００は、エリア１０１０，１０２０及び１０３０を含んでいる。なお、本実施形態の追加予約申請ページは、エリア１０２０が追加されている点を除き、従来例（例えば、＜先行技術１＞）の予約申請ページと同様である。

エリア１０１０には、追加予約申請に係る詳細が表示される。エリア１０２０では、隣接部屋リクエストをするか否かを選択することができる。
追加予約申請ページ１０００を介した追加予約の申請手順は、次の通りである。
〔３１〕幹事が、エリア１０１０において追加予約申請に係る詳細を確認する。
〔３２〕幹事が、エリア１０２０において隣接部屋リクエストの有無を選択する。
〔３３〕幹事が、エリア１０３０においてユーザＩＤ及びパスワードを入力し、ボタン１０３１をクリックする。
〔３４〕ユーザ端末２０が、サーバシステム１０に追加予約申請を送信する。

［（ｈ）予約情報の登録］
上記手順〔１４〕において、サーバシステム１０は、予約ＤＢ１４に予約情報及び追加予約情報を登録する（Ｓ４６５）。
具体的な処理手順は、次の通りである。
〔４１〕幹事のユーザＩＤ，選択された宿泊プランの宿泊プランＩＤ，宿泊プランの注文数及び宿泊人数を、予約番号を付与して予約ＤＢ１４の予約情報に格納する。追加予約申請ページ１０００（図１０）のエリア１０１０に示す申請内容であれば、注文数は１，宿泊人数は４である。
〔４２〕宿泊プランＤＢ１３において、追加の予約に係る宿泊プランの在庫数を更新する（注文数を減算する）。

〔４３〕当初の予約の予約番号に対応させて、追加の予約の予約番号を予約ＤＢ１４の追加予約情報に格納する。このとき、隣接部屋リクエストがあれば、隣接部屋リクエストフラグを立てる。
〔４４〕予約ＤＢ１４において、当初の予約に係る予約情報を修正する。予約修正ページ７００（図７）に示す修正内容であれば、宿泊プランの注文数を１に変更し（キャンセル）、宿泊人数を３に変更し、追加フラグを立てる。
〔４５〕予約ＤＢ１４において、メンバ情報を更新する。予約修正ページ７００（図７）に示す修正内容であれば、追加で加入したメンバＧのメンバ情報を追加登録する。なお、不参加のメンバ（予約修正要求（図８）において、選択フラグが有意でないメンバ）がいれば、当該メンバの不参加フラグを立てる。
〔４６〕宿泊プランＤＢ１３において、当初の予約に係るキャンセルされた宿泊プランの在庫数を更新する（キャンセル数を加算する）。

［（ｉ）宿泊施設に対する通知］
上記手順〔１５〕において、サーバシステム１０は、修正後の予約内容等を記載した通知メールを生成し、修正に係る宿泊施設のメールアドレス宛に送信する（Ｓ４７５）。
例えば、次の内容を通知メールに記載するとよい。
・当初の予約の内容が修正された旨。
・（隣接部屋リクエストがある場合のみ）追加の予約に係る客室を、当初の予約に係る客室に隣接する客室にすることを、ユーザが希望している旨。
なお、施設端末４０に対する通知メールの送信は、定期的なバッチ処理により実行してもよい。ただし、宿泊施設側の事務処理（部屋割り等）の便宜のため、予約が修正された後、より早い時期に通知メールを送信するのが好ましい。

［（ｊ）メンバに対する通知］
上記手順〔１６〕において、サーバシステム１０は、予約の修正があった旨等を記載した共有メールを生成し、修正に係る予約に関係するメンバのメールアドレス宛に通知する（Ｓ４８０）。
例えば、次の内容を共有メールに記載するとよい。
・当初の予約の内容が修正された旨。
・参加するメンバ。
・宿泊施設，宿泊日程，宿泊プランの概要。
なお、ユーザ端末３０に対する共有メールの送信は、定期的なバッチ処理により実行してもよい。

［４．他の使用例］
宿泊修正機能は、上述のとおり、例えば次のような修正の態様に対応している。
（ａ）宿泊人数を変更する（宿泊プランは変更しない）。
（ｂ）予約中の宿泊プランと同一の宿泊プランを追加する。
（ｃ）予約中の宿泊プランと異なる宿泊プランを追加する。
（ｄ）予約中の宿泊プランの一部を削除（キャンセル）する。
（ｅ）予約中の宿泊プランの一部又は全部を、異なる宿泊プランに変更する。
以下では、修正態様のバリエーション及び処理手順の概要を簡単に示す。なお、修正前の予約内容は、図１（ａ）に示すとおりである。

［４−１．宿泊人数の変更］
図１１（ａ）に、宿泊人数の変更後の予約内容を示す。
〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。
〔２〕上記グループからメンバＢが脱退し、合計人数が５人になる。
〔３〕予約中の宿泊プランと同一の宿泊プラン（１部屋目の宿泊プラン）を、宿泊人数２で予約し直す（図１１（ａ））。
なお、「宿泊人数の変更」の手順は、上述の「宿泊プランの一部変更」の手順のうち、在庫の確認・宿泊プランの検索を省略した手順に相当する。

［４−２．同一プランの追加］
図１１（ｂ）に、同一プランの追加後の予約内容を示す。
〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。
〔２〕上記グループにメンバＧ，Ｈが加入し、合計人数が８人になる。
〔３〕予約中の宿泊プランと同一の宿泊プランの在庫を確認する。
〔４〕在庫があれば、当該プランを宿泊人数２で追加予約する（図１１（ｂ））。
なお、「同一プランの追加」の手順は、上述の「宿泊プランの一部変更」の手順のうち、宿泊プランの検索・宿泊プランの削除を省略した手順に相当する。

［４−３．異なるプランの追加］
図１２（ｃ）に、異なるプランの追加後の予約内容を示す。
〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。
〔２〕上記グループにメンバＧ〜Ｊが加入し、合計人数が１０人になる。
〔３〕予約中の宿泊プランに係る宿泊施設・宿泊日程と施設・日程がそれぞれ同一であり、かつ、定員が４以上の客室に対応する宿泊プランを検索する。
〔４〕検索された宿泊プランの中から所望のプランを宿泊人数４で追加予約する（図１２（ｃ））。
なお、「異なるプランの追加」の手順は、上述の「宿泊プランの一部変更」の手順のうち、宿泊プランの削除を省略した手順に相当する。

［４−４．宿泊プランの一部削除］
図１２（ｄ）に、宿泊プランの一部削除後の予約内容を示す。
〔１〕ユーザＡを幹事とするグループは、６人のメンバ（メンバＡ〜Ｆ）から成り、定員３の客室を２部屋予約している（図１（ａ））。
〔２〕上記グループからメンバＤ〜Ｆが脱退し、宿泊人数が３人になる。
〔３〕メンバＤ〜Ｆが割り当てられていた２部屋目の客室に係る宿泊プランの予約を削除（キャンセル）する（図１２（ｄ））。
なお、「宿泊プランの一部削除」の手順は、上述の「宿泊プランの一部変更」の手順のうち、在庫の確認・宿泊プランの検索・宿泊プランの追加を省略した手順に相当する。

［４−５．その他］
以上で説明した修正態様を組み合わせれば、予約内容をさらに柔軟に修正することができる。例えば、修正後の宿泊プランを、さらに修正することもできる。

［５．変形例］
上述の実施形態では、当初の予約に係る情報と追加の予約に係る情報とを、予約情報（図３（ｄ−１））として予約ＤＢ１４に登録し、関連する予約情報どうしを追加予約情報（図３（ｄ−３））により関連付けている。
これに対し、当初の予約に係る情報と追加の予約に係る情報との関連付けの態様には、例えば次に示す変形例を含め、種々のバリエーションがある。

［（変形例１）関連予約情報を設ける］
追加予約情報（図３（ｄ−３））に代えて、予約ＤＢ１４に関連予約情報を設けてもよい。
図１３に、関連予約情報を設ける場合における予約ＤＢ１４のデータ構成を示す。
図１３（ｃ）に示すように、１件の関連予約情報は、当初の予約に係る「予約番号」及び当該予約から派生した追加の予約に係る全ての「追加予約番号」（１，２，…）を含んでいる。
なお、図１３（ａ）の予約情報，図１３（ｂ）のメンバ情報は、それぞれ図３（ｄ−１）の予約情報，図３（ｄ−２）のメンバ情報と同様である。

［（変形例２）派生番号を利用する］
「予約番号」と「派生番号」との組を、予約情報のキー項目としてもよい。
図１４に、派生番号を利用する場合における予約ＤＢ１４のデータ構成を示す。
図１４（ａ）に示すように、１件の予約情報（変形例）は、「予約番号」，「派生番号」，幹事の「ユーザＩＤ」，「宿泊プランＩＤ」，宿泊プランの「注文数」及び予約に係る「宿泊人数」を含んでいる。
例えば、追加の予約には、当初の予約と共通の「予約番号」と、追加された順に１，２，…と連番の「派生番号」を付与するとよい。また、当初の予約の「派生番号」は、例えば０とするとよい。
なお、図１４（ｂ）のメンバ情報は、図３（ｄ−２）のメンバ情報と同様である。

１０ サーバシステム
１１ ユーザＤＢ
１２ 施設ＤＢ
１３ 宿泊プランＤＢ
１４ 予約ＤＢ
２０ ユーザ端末（幹事）
３０ ユーザ端末（メンバ）
４０ 施設端末
５０ インターネット
６００ 予約確認ページ
７００ 予約修正ページ
９００ 検索結果ページ
１０００ 追加予約申請ページ

Claims (11)

1. 複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末と接続して、グループ予約支援システムを構成するサーバシステムであって、
   予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有し、
   前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定手段と、
   宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信手段と、
   前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録手段と
   を備える
   ことを特徴とするサーバシステム。
2. 請求項１に記載のサーバシステムにおいて、
   宿泊プランの識別情報に対応させて、該宿泊プランの在庫数を記憶している宿泊プラン情報記憶手段をさらに有し、
   前記宿泊プラン情報記憶手段を参照して、前記指定された宿泊プランの在庫の有無を確認する在庫確認手段と、
   前記宿泊プラン情報記憶手段に記憶している、前記登録した追加予約情報に係る宿泊プランの在庫数を更新する在庫数更新手段と
   をさらに備え、
   前記追加予約情報登録手段は、前記指定された宿泊プランの在庫がある場合に限り、前記追加予約情報を前記予約情報記憶手段に登録する
   ことを特徴とするサーバシステム。
3. 請求項２に記載のサーバシステムにおいて、
   前記特定した予約番号に係る予約中の宿泊プランの予約をキャンセルする当初予約キャンセル手段をさらに備え、
   前記在庫数更新手段は、さらに、前記キャンセルした宿泊プランの在庫数を更新する
   ことを特徴とするサーバシステム。
4. 請求項３に記載のサーバシステムにおいて、
   前記幹事の端末からの要求に応じて、前記特定した予約番号に係る予約中の各宿泊プランの情報を配置した予約修正ページを生成し、該幹事の端末に送信する予約修正ページ生成送信手段と、
   前記予約修正ページを介して宿泊プランの選択情報を前記幹事の端末から受信する選択情報受信手段と
   をさらに備え、
   前記当初予約キャンセル手段は、前記受信した選択情報に対応する１又は複数の宿泊プランの予約のみをキャンセルする
   ことを特徴とするサーバシステム。
5. 請求項２〜４のいずれかに記載のサーバシステムにおいて、
   前記宿泊プラン情報記憶手段は、宿泊プランの識別情報に対応させて、宿泊施設及び宿泊日程をさらに記憶しており、
   前記特定した予約番号に係る予約中の宿泊プランの宿泊施設及び宿泊日程と施設及び日程がそれぞれ同一の宿泊プランの識別情報を前記宿泊プラン情報記憶手段より抽出する宿泊プラン検索手段と、
   前記抽出した宿泊プランの識別情報及び／又はこれに対応する情報を配置した検索結果ページを生成し、前記幹事の端末に送信する検索結果出力手段と
   をさらに備え、
   前記追加予約申請受信手段は、前記検索結果ページを介して選択指定された宿泊プランの追加予約申請を受信する
   ことを特徴とするサーバシステム。
6. 請求項５に記載のサーバシステムにおいて、
   前記在庫確認手段は、さらに、前記特定した予約番号に係る予約中の宿泊プランの宿泊施設及び宿泊日程と施設及び日程がそれぞれ同一の宿泊プランの在庫の有無を確認し、
   前記宿泊プラン検索手段は、在庫のある宿泊プランの識別情報のみを抽出する
   ことを特徴とするサーバシステム。
7. 請求項１〜６のいずれかに記載のサーバシステムにおいて、
   各施設のメールアドレスを記憶している施設情報記憶手段をさらに有し、
   予約の修正内容を含む通知メールを生成し、前記特定した予約番号に係る当初の予約又は該予約番号に関連付けられている追加の予約に係る宿泊施設のメールアドレスを前記施設情報記憶手段より抽出し、該通知メールを該メールアドレス宛に送信する通知メール生成送信手段をさらに備える
   ことを特徴とするサーバシステム。
8. 請求項７に記載のサーバシステムにおいて、
   前記追加予約申請受信手段は、前記幹事の端末から、前記追加予約申請とともに隣接部屋リクエストをさらに受信し、
   前記通知メール生成送信手段は、前記追加の予約に係る客室を前記当初の予約に係る客室に隣接させるよう依頼する旨をさらに記載した前記通知メールを生成する
   ことを特徴とするサーバシステム。
9. 請求項１〜８のいずれかに記載のサーバシステムにおいて、
   前記幹事の端末から受信したデータを基に、前記各メンバのメールアドレスを特定するメールアドレス特定手段と、
   予約の修正内容を含む共有メールを生成し、前記特定した各メールアドレス宛に送信する共有メール生成送信手段と
   をさらに備える
   ことを特徴とするサーバシステム。
10. 複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末とサーバシステムとを接続して構成したグループ予約支援システムにおけるグループ予約支援方法であって、
    予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有するサーバシステムが、
    前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定ステップと、
    宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信ステップと、
    前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録ステップと
    を実行する
    ことを特徴とするグループ予約支援方法。
11. 複数のメンバから成るグループを代表して宿泊プランの予約手続を行う幹事の端末とサーバシステムとを接続して構成したグループ予約支援システムにおけるグループ予約支援プログラムであって、
    予約番号に対応させて、幹事の識別情報，宿泊プランの識別情報及び宿泊人数を少なくとも１件分記憶している予約情報記憶手段を有するサーバシステムに、
    前記幹事の端末から受信したデータを基に、該幹事に係る予約中の予約番号を特定する当初予約特定ステップと、
    宿泊プランを指定した変動人数分の追加予約申請を前記幹事の端末から受信する追加予約申請受信ステップと、
    前記幹事の識別情報と前記指定された宿泊プランの識別情報とを含む追加予約情報を、前記特定した予約番号に関連付けて前記予約情報記憶手段に登録する追加予約情報登録ステップと
    を実行させるためのグループ予約支援プログラム。