JP5171775B2 - 宿泊予約管理システム - Google Patents

Description

本発明は、オンラインでの宿泊予約を管理する仕組みに関し、特に、複数種類の宿泊プランの一括予約を受け付ける機能に関するものである。

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

＜先行技術２＞
オンラインショッピングモールにおいて、複数種類の商品の一括注文を受け付ける機能が提供されている（例えば、非特許文献２参照)。
具体的には、ショップごとに設けられた「買い物かご」にユーザが選択した商品を順次追加していく手順と、「買い物かご」に入っている商品の一括注文を受け付ける手順とを経て、複数種類の商品の一括注文が成立する。

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

［１．従来の宿泊予約サービス］
図１を参照し、従来の宿泊予約サービスの概要を説明する。
例えば、「２００９年１１月１日」〜「２００９年１１月２日」の予定で「ＡＡＡホテル」の客室２部屋を予約する場合、「ＡＡプラン」を注文数２で一括予約することは可能であった（図１（ａ））。
一方、同様に２部屋を予約する場合であっても、「ＡＡプラン」の予約と「ＢＢプラン」の予約は、別個の手続により各別に行う必要があった（図１（ｂ））。

その結果、「ＡＡプラン」の予約と「ＢＢプラン」の予約との間には、必然的にタイムラグが発生する。そのため、例えば、「ＡＡプラン」の予約が成立した後「ＢＢプラン」の予約が成立するまでの間に、他のユーザによる「ＢＢプラン」の予約が成立すると、「ＢＢプラン」の在庫数しだいでは「ＢＢプラン」の予約ができなくなってしまう。
この場合、「ＡＡプラン」を予約したユーザは、２部屋を確保することを前提として予約手続を開始したものの、「ＢＢプラン」に係る１部屋を確保することができない。したがって、「ＡＡプラン」に係る予約も無駄になってしまう可能性がある。

［２．従来の宿泊予約管理システム］
このように、従来の宿泊予約サービス（例えば、上記＜先行技術１＞のサービス）では、宿泊プランが同一でない場合、宿泊プランごとに別個の予約手続が要求される。
これは、従来の宿泊予約管理システムが、例えば次のような事情により、複数種類の宿泊プランの一括予約に対応していないからである。
（ａ）客室ごとに異なる宿泊条件を設定して複数の客室を検索する、という検索態様に検索エンジンが対応していない。そのため、複数種類の宿泊プランの一括予約に対応したシステムを構築するための前提がそもそもなかった。

（ｂ）各宿泊プランには、固定のパラメータ（部屋情報，食事情報等）が関連付けられている。そのため、従来のシステムは、単一の固定パラメータが入ってくるという前提のもとで構築された。
（ｃ）次のような宿泊プランの特性上、在庫管理が複雑で一括予約になじまない。そのため、複数種類の商品の一括注文を受け付ける機能（例えば、上記＜先行技術２＞の機能）を、宿泊の予約を管理するシステムに単純に適用することができず、システム構築の難易度が高かった。
・宿泊プランの在庫（客室の空室）の絶対数が当初から少なく、補充が容易でない。
・宿泊プランの内容に、日程情報，施設情報，部屋情報等が組み込まれている。
・１の客室に対して複数の宿泊プランが設定されている場合がある等、宿泊プランの在庫数と客室の空室数とが必ずしも１対１で対応していない。

［３．発明が解決しようとする課題］
本発明が解決しようとする課題は、オンライン宿泊予約サイトのユーザに対し、複数種類の宿泊プランの一括予約を受け付ける機能を提供する、という点である。

上記課題を解決するため、本発明は、ユーザの端末と接続して宿泊予約管理システムを構成するサーバシステムであって、宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段とを有し、第１の宿泊プランの指定情報を前記端末から受信し、該第１の宿泊プランの識別情報を前記宿泊予定記憶手段に書き込む宿泊予定保存手段と、第２の宿泊プランの指定情報を前記端末から受信し、前記第１の宿泊プランの識別情報を前記宿泊予定記憶手段より読み出し、該第１の宿泊プランの情報と該第２の宿泊プランの情報とを配置した予約申請ページを生成する予約申請ページ生成手段と、前記生成した予約申請ページを前記端末に送信する予約申請ページ送信手段と、前記予約申請ページを介して、前記第１及び／又は前記第２の宿泊プランを指定した予約申請を受信する予約申請受信手段と、前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録手段とを備えることを特徴とする。

宿泊プランの識別情報に対応させて、宿泊施設及び宿泊日程を記憶している宿泊プラン記憶手段をさらに有し、前記予約申請ページ生成手段は、前記第１及び前記第２の宿泊プランの宿泊施設及び宿泊日程がそれぞれ互いに一致するか否かを前記宿泊プラン記憶手段を参照して判定し、一致する場合に限り、前記第１及び前記第２の宿泊プランの同時指定が可能となるように前記予約申請ページを生成するとよい。
前記予約申請ページ生成手段は、前記第１及び前記第２の宿泊プランの宿泊施設及び宿泊日程がそれぞれ互いに一致する場合には、該第１の宿泊プランの情報が強調表示されるように前記予約申請ページを生成してもよい。
前記予約申請ページ生成手段は、前記第１及び前記第２の宿泊プランの宿泊施設及び宿泊日程がそれぞれ互いに一致する場合には、前記第１及び前記第２の宿泊プランがデフォルトで同時指定されているように前記予約申請ページを生成してもよい。

また、上記課題を解決するため、本発明は、ユーザの端末とサーバシステムとが接続した宿泊予約管理システムにおける宿泊一括予約方法であって、宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段とを有する前記サーバシステムが、第１の宿泊プランの指定情報を前記端末から受信し、該第１の宿泊プランの識別情報を前記宿泊予定記憶手段に書き込む宿泊予定保存ステップと、第２の宿泊プランの指定情報を前記端末から受信し、前記第１の宿泊プランの識別情報を前記宿泊予定記憶手段より読み出し、該第１の宿泊プランの情報と該第２の宿泊プランの情報とを配置した予約申請ページを生成する予約申請ページ生成ステップと、前記生成した予約申請ページを前記端末に送信する予約申請ページ送信ステップと、前記予約申請ページを介して、前記第１及び／又は前記第２の宿泊プランを指定した予約申請を受信する予約申請受信ステップと、前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録ステップとを実行することを特徴とする。

また、上記課題を解決するため、本発明は、ユーザの端末とサーバシステムとが接続した宿泊予約管理システムにおける宿泊一括予約プログラムであって、宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段とを有する前記サーバシステムに、第１の宿泊プランの指定情報を前記端末から受信し、該第１の宿泊プランの識別情報を前記宿泊予定記憶手段に書き込む宿泊予定保存ステップと、第２の宿泊プランの指定情報を前記端末から受信し、前記第１の宿泊プランの識別情報を前記宿泊予定記憶手段より読み出し、該第１の宿泊プランの情報と該第２の宿泊プランの情報とを配置した予約申請ページを生成する予約申請ページ生成ステップと、前記生成した予約申請ページを前記端末に送信する予約申請ページ送信ステップと、前記予約申請ページを介して、前記第１及び／又は前記第２の宿泊プランを指定した予約申請を受信する予約申請受信ステップと、前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録ステップとを実行させる。

本発明のサーバシステムとユーザの端末とを接続して構成した宿泊予約管理システムを利用すれば、宿泊の予約手続を行うユーザ（例えば、宿泊予定者を代表して宿泊の予約手続を行う宿泊代表者）は、複数種類の宿泊プランを一括で予約することができる。

宿泊予約サービスの概要の説明図である。（従来例） 宿泊一括予約機能の概要の説明図である。（実施形態） システム構成を示すブロック図である。（実施形態） データベースのデータ項目の説明図である。（実施形態） 宿泊の一括予約手順を示すフロー図である。（実施形態） 宿泊の一括予約手順を示すフロー図である。（実施形態） 予約申請ページの表示例である。（実施形態） 受信するデータ項目の説明図である。（実施形態） （追加更新後）予約申請ページの表示例である。（実施形態） （変更更新後）予約申請ページの表示例である。（実施形態）

＜定義＞
・宿泊プラン…オンライン宿泊予約サイトにおける予約対象（注文対象）の単位。特定の客室（又は特定の部屋タイプの客室）における少なくとも１泊分の宿泊サービスを必須の要素とし、食事等の付随的なサービスを任意に含む。
・宿泊予定…注文予定として一時的に保存されている宿泊プラン，注文数（部屋数），宿泊人数（合計，大人，子供）等の組。

＜実施形態＞
［１．概要］
本実施形態のシステムは、オンラインで宿泊の予約を受け付けるサービス（宿泊予約サービス）を管理するシステムであり、複数種類の宿泊プランの一括予約を受け付ける機能（宿泊一括予約機能）を提供する。
図２を参照し、宿泊一括予約機能の概要を説明する。
図２に示すように、本実施形態のシステムを利用すれば、例えば、「２００９年１１月１日」〜「２００９年１１月２日」の予定で「ＡＡＡホテル」の客室２部屋を予約する場合、「ＡＡプラン」の予約と「ＢＢプラン」の予約を同一の手続により一括して行うことができる。

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

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

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

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

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

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

図４（ｄ−１）に、宿泊予定管理情報の主要な項目を示す。
図４（ｄ−１）に示すように、１件の宿泊予定管理情報は、「宿泊予定ＩＤ」，「宿泊予定識別データ」及び「次番号」を含んでいる。
ここで、「宿泊予定識別データ」は、宿泊予定を識別可能なデータであり、本実施形態では「セションＩＤ」を利用する。「次番号」は、次に追加される宿泊予定情報（後述）に付すべき番号である。
なお、「セションＩＤ」を「宿泊予定ＩＤ」として利用してもよい。

図４（ｄ−２）に、宿泊予定情報の主要な項目を示す。
図４（ｄ−２）に示すように、１件の宿泊予定情報は、「宿泊予定ＩＤ」，「シリアルＩＤ」，「宿泊プランＩＤ」，宿泊プランの「注文数」，その宿泊予定に係る「宿泊人数」（合計，大人，子供）及び「ステータス」を含んでいる。
ここで、「シリアルＩＤ」は、宿泊予定情報を識別するための識別情報であり、本実施形態では追加登録された順に連番の番号を付している。「ステータス」は、宿泊予定情報の状態（例えば、「選択中」（初期値），「予約済」，「未確定」，「削除」等）を区分する情報である。

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

図４（ｅ−１）に、予約情報の主要な項目を示す。
図４（ｅ−１）に示すように、１件の予約情報は、「予約番号」，宿泊代表者の「ユーザＩＤ」，「宿泊プランＩＤ」，宿泊プランの「注文数」，その予約に係る「宿泊人数」（合計，大人，子供）及び「一括予約ＩＤ」を含んでいる。
ここで、「一括予約ＩＤ」は、一括予約に係る複数の予約番号を関連付けて記憶している一括予約情報（後述）の識別情報であり、その予約が一括予約に係る予約でない場合はｎｕｌｌ値とする。

図４（ｅ−２）に、一括予約情報の主要な項目を示す。
図４（ｅ−２）に示すように、１件の一括予約情報は、「一括予約ＩＤ」及び一括予約に係る複数の「予約番号」を含んでいる。

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

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

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

［３．宿泊の一括予約］
［（ａ）宿泊の一括予約手順］
図５〜６に、宿泊の一括予約手順を示す。
図５〜６に示すように、サーバシステム１０は、下記〔１１〕〜〔１８〕の手順により宿泊の一括予約を受け付ける。
ここでは、ユーザ（宿泊代表者）がユーザ端末２０を操作して、宿泊条件（日程，地域，人数，部屋数等）を設定し、サーバシステム１０に送信した後の手順を説明する。

〔１１〕ユーザが設定した宿泊条件を満たす宿泊プランを宿泊プランＤＢ１３において検索し、ユーザ端末２０に宿泊プラン選択ページを送信する（Ｓ５０５）。
〔１２〕宿泊プラン選択ページを介してユーザ端末２０から宿泊プランの選択情報を受信する（Ｓ５１０）と、選択された宿泊プランに係る宿泊予定情報を宿泊予定ＤＢ１４に追加（登録）し（Ｓ５１５）、同一の宿泊予定に係る全ての宿泊予定情報を抽出する（Ｓ５２０）。
〔１３〕選択された宿泊プランに係る予約申請ページを生成し（Ｓ５２５）、ユーザ端末２０に送信する（Ｓ５３０，図７）。

〔１４〕予約申請ページ（図７，図９等）を介してユーザ端末２０から応答（図８）を受信し（Ｓ５３５）、「識別コード」により応答の内容を判定する（Ｓ５４０）。応答が「継続申請」であれば（Ｓ５４０で「継続」）、上記〔１１〕に戻る。
〔１５〕応答が「更新申請」（追加，変更，削除）であれば（Ｓ５４０で「更新」）、宿泊予定情報を更新し（Ｓ５４５）、更新した予約申請ページを生成し（Ｓ５５０）、ユーザ端末２０に送信し（Ｓ５５５，例えば図９，図１０）、上記〔１４〕に戻る。
〔１６〕応答が「予約申請」であれば（Ｓ５４０で「予約」）、ユーザ（宿泊代表者）を識別し（Ｓ５６０）、予約情報及び必要に応じて一括予約情報を予約ＤＢ１５に登録する（Ｓ５６５）。

〔１７〕予約手続（一括予約手続）が完了した旨等を電子メールでユーザ（宿泊代表者）のメールアドレス宛に送信する（Ｓ５７０）。なお、ユーザのメールアドレスは、ユーザＤＢ１１より抽出する。
〔１８〕一括予約に係る各予約の予約内容を電子メールで施設のメールアドレス宛に送信する（Ｓ５７５）。なお、施設のメールアドレスは、施設ＤＢ１２より抽出する。また、一括予約に係る予約番号は、予約ＤＢ１５の一括予約情報より抽出する。

［（ｂ）宿泊予定情報の追加］
上記手順〔１２〕において、サーバシステム１０は、選択された宿泊プランに係る宿泊予定情報を宿泊予定ＤＢ１４に追加（登録）する（Ｓ５１５）。
具体的には、ユーザ端末２０から受信したセションＩＤに対応する宿泊予定管理情報が宿泊予定ＤＢ１４に登録されていれば、当該宿泊予定に係る「次番号」を「シリアルＩＤ」として、選択された宿泊プランに係る宿泊予定情報を宿泊予定ＤＢ１４に追加する。また、当該「次番号」を更新する（インクリメントする）。
一方、対応する宿泊予定管理情報が宿泊予定ＤＢ１４に登録されていなければ、宿泊予定管理情報を新たに宿泊予定ＤＢ１４に登録するとともに、選択された宿泊プランに係る宿泊予定情報を宿泊予定ＤＢ１４に登録する。

［（ｃ）宿泊予定情報の抽出］
上記手順〔１２〕において、サーバシステム１０は、同一の宿泊予定に係る全ての宿泊予定情報を抽出する（Ｓ５２０）。
具体的には、ユーザ端末２０から受信したセションＩＤに対応する宿泊予定ＩＤを宿泊予定ＤＢ１４の宿泊予定管理情報を参照して特定し、当該宿泊予定ＩＤに対応する全ての宿泊予定情報に係る「宿泊プランＩＤ」，「注文数」及び各「宿泊人数」を宿泊予定ＤＢ１４より抽出する。
なお、選択された宿泊プランに係る宿泊予定情報を新規に登録した場合（Ｓ５１５で新規登録の場合）には、他の宿泊予定情報は存在しない。この場合、新規に登録した宿泊予定情報に係る「宿泊プランＩＤ」等のみを抽出する。

［（ｄ）予約申請ページ］
図７に、予約申請ページの表示例を示す。
図７に示すように、予約申請ページ７００は、エリア７１０，エリア７２０，ボタン７３０及びエリア７４０を含んでいる。
エリア７１０には、ステータスが「選択中」の宿泊予定（予約対象の宿泊予定）の内容が表示される。なお、宿泊プランの内容は、宿泊プランＤＢ１３の宿泊プラン情報より抽出する。

ユーザがエリア７２０においてユーザＩＤ及びパスワードを入力し、ボタン７２１をクリックすると、ユーザ端末２０はサーバシステム１０に予約申請（図８（ａ））を送信する。
ユーザがボタン７３０をクリックすると、ユーザ端末２０はサーバシステム１０に、宿泊プラン選択の継続申請（図８（ｂ））を送信する。

エリア７４０には、ステータスが「未確定」の宿泊予定の内容が表示される。特に、ステータスが「選択中」の宿泊予定（エリア７１０に表示されている予約対象の宿泊予定）と宿泊施設及び宿泊日程が同一の宿泊予定の内容を強調して表示する。図７の表示例では、網掛け表示になっている。
エリア７４０内の要素と更新申請（図８（ｃ））との関係は、次のとおりである。
・ユーザがリンク７４１ｂ又は７４２ｂをクリックすると、ユーザ端末２０はサーバシステム１０に、予約対象追加の更新申請を送信する。
・ユーザがボタン７４１ａ〜７４３ａのいずれかをクリックすると、ユーザ端末２０はサーバシステム１０に、予約対象変更の更新申請を送信する。
・ユーザが「削除」と表示されているリンク（最右欄）のいずれかをクリックすると、ユーザ端末２０はサーバシステム１０に、宿泊予定削除の更新申請を送信する。

［（ｅ）送受信されるデータ］
図８（ａ）に、予約申請の主要な項目を示す。
図８（ａ）に示すように、１件の予約申請は、「セションＩＤ」（宿泊予定識別データ），応答内容の「識別コード」，「ユーザＩＤ」及び「パスワード」を含んでいる。
なお、「識別コード」は、応答の内容が「予約」の申請であることを識別するためのコードである。

図８（ｂ）に、継続申請の主要な項目を示す。
図８（ｂ）に示すように、１件の継続申請は、「セションＩＤ」（宿泊予定識別データ）及び応答内容の「識別コード」を含んでいる。
なお、「識別コード」は、応答の内容が「継続」の申請であることを識別するためのコードである。

図８（ｃ）に、更新申請の主要な項目を示す。
図８（ｃ）に示すように、１件の更新申請は、「セションＩＤ」（宿泊予定識別データ），応答内容の「識別コード」及び「シリアルＩＤ」を含んでいる。
なお、「識別コード」は、応答の内容が「更新」（予約対象追加，予約対象変更又は宿泊予定削除）の申請であることを識別するためのコードである。

［（ｆ）宿泊予定情報の更新］
上記手順〔１５〕において、サーバシステム１０は、宿泊予定情報を更新する（Ｓ５４５）。
具体的には、受信した「セションＩＤ」に対応する「宿泊予定ＩＤ」を特定した上で、当該「宿泊予定ＩＤ」に対応する宿泊予定情報を次のとおり更新する。
・（追加の場合）追加対象の「シリアルＩＤ」に係る宿泊予定情報の「ステータス」を「選択中」に更新する。
・（変更の場合）「ステータス」が「選択中」である宿泊予定情報の「ステータス」を「未確定」に更新するとともに、変更対象の「シリアルＩＤ」に係る宿泊予定情報の「ステータス」を「選択中」に更新する。
・（削除の場合）削除対象の「シリアルＩＤ」に係る宿泊予定情報の「ステータス」を「削除」に更新する。

［（ｇ）更新後の予約申請ページ］
図９に、更新後の予約申請ページの表示例を示す。
図９に示すように、予約申請ページ９００は、エリア９１０，エリア９２０，ボタン９３０及びエリア９４０を含んでいる。これらは、予約申請ページ７００（図７）のエリア７１０，エリア７２０，ボタン７３０及びエリア７４０にそれぞれ対応する。
なお、予約申請ページ９００は、予約申請ページ７００（図７）においてリンク７４１ｂをクリックしたときにユーザ端末２０に表示される予約申請ページの表示例であり、予約申請の対象に「ＢＢプラン」が追加されている。

図１０に、更新後の予約申請ページの表示例を示す。
図１０に示すように、予約申請ページ１０００は、エリア１０１０，エリア１０２０，ボタン１０３０及びエリア１０４０を含んでいる。これらは、予約申請ページ７００（図７）のエリア７１０，エリア７２０，ボタン７３０及びエリア７４０にそれぞれ対応する。
なお、予約申請ページ１０００は、予約申請ページ７００（図７）においてリンク７４２ａをクリックしたときにユーザ端末２０に表示される予約申請ページの表示例であり、予約申請の対象が「ＣＣプラン」に変更されている。

［（ｈ）予約情報の登録］
上記手順〔１６〕において、サーバシステム１０は、予約情報及び必要に応じて一括予約情報を予約ＤＢ１５に登録する（Ｓ５６５）。
具体的には、下記〔２１〕〜〔２４〕の手順のとおりである。
〔２１〕予約対象を特定する。ここでは、受信した「セションＩＤ」に対応する「宿泊予定ＩＤ」を特定し、当該「宿泊予定ＩＤ」に対応する宿泊予定情報のうち「ステータス」が「選択中」の宿泊予定情報を予約対象とする。

〔２２〕予約情報を登録する。ここでは、予約対象として特定した宿泊予定情報に係る宿泊プランＩＤ及び宿泊条件（注文数（部屋数），宿泊人数（合計，大人及び子供））を、各々に予約番号を付与して予約ＤＢ１５に登録する。
〔２３〕予約対象が複数であれば、一括予約情報を登録する。ここでは、各予約情報に係る予約番号を、一括予約ＩＤを付与して予約ＤＢ１５に登録する。また、当該一括予約ＩＤを各予約情報に追加する。
〔２４〕ステータス情報を更新する。ここでは、予約対象として特定した宿泊予定情報の「ステータス」を「予約済」に更新する。

［４．変形例］
［（変形例１）宿泊プラン選択情報の受信形態の変形例］
上述の実施形態では、宿泊プラン選択ページを介して１種類の宿泊プランの選択情報を受信し（図５のＳ５１０）、当該選択された宿泊プランの予約申請ページを送信している（図５のＳ５３０）。また、これらの手順を繰り返すことにより複数種類の宿泊プランを宿泊予定ＤＢ１４に登録している（図５のＳ５４０で「継続」の場合を参照）。
これに対し、宿泊プラン選択ページを介して複数種類の宿泊プランの選択情報を一括で受信してもよい。

例えば、宿泊プラン選択ページに各宿泊プランに対応するチェックボックスを配置し、チェックが入っている宿泊プランの識別情報を受信するとよい。
この場合、選択された宿泊プランの中から施設及び日程がそれぞれ共通する複数種類の宿泊プランを一括予約申請の対象として選択し、当該選択した複数種類の宿泊プランに係る予約申請ページを送信するとよい。

［（変形例２）一括予約申請の対象に追加可能な他の宿泊プランの表示形態の変形例］
上述の実施形態では、予約申請ページにおいて、ステータスが「選択中」の宿泊予定と施設及び日程が同一の宿泊予定の内容を、表示態様を変更して表示している（予約申請ページ７００（図７）のエリア７４０等参照）。
これに対し、ステータスが「選択中」の宿泊予定と施設及び日程が同一の宿泊予定の内容を、ステータスが「選択中」の宿泊予定の内容とともに、デフォルトの予約対象として表示してもよい。

例えば、予約申請ページ７００（図７）のエリア７１０に、選択された「ＡＡプラン」に係る宿泊予定の内容とともに、施設及び日程が同一の「ＢＢプラン」及び「ＣＣプラン」に係る宿泊予定の内容を表示するとよい。これにより、一括予約の手続を、よりスムーズに完了させることが可能になる。
なお、この場合、エリア７１０に一緒に表示する宿泊予定に係る「ステータス」を「選択中」に更新するとよい。また、エリア７１０において、宿泊予定を予約申請の対象から除外することができるように構成するとよい。

［（変形例３）予約申請ページの形態の変形例］
上述の実施形態では、ユーザ端末２０から更新申請を受信するごとに、更新した予約申請ページを生成し、送信している（図５のＳ５４０〜Ｓ５５５）。
これに対し、更新申請に対応する要素のクリックをユーザ端末２０がイベントとして検出し、予約申請ページの一部のみをユーザ端末２０が更新してもよい。
なお、この予約申請ページの更新機能は、当該ページに組み込んだプログラム（例えば、ＪａｖａＳｃｒｉｐｔ形式のスクリプト）により実行する。

［（変形例４）予約申請対象の宿泊プランの指定形態の変形例］
上述の実施形態では、予約申請ページの更新申請を受信するごとに宿泊予定情報の「ステータス」を更新し、予約申請を受信したとき「ステータス」が「選択中」の宿泊予定情報に係る宿泊プランＩＤ等の予約情報を登録する（図６のＳ５６５）。
これに対し、予約申請の対象とする宿泊プランを予約申請ページにおいて選択可能としてもよい。この場合、予約申請ページにおいて選択された宿泊プランを識別するための情報（例えば、「シリアルＩＤ」）を受信し、当該選択された宿泊プランに係る予約情報を予約ＤＢ１５に登録するとよい。

［（変形例５）宿泊予定の保存形態の変形例］
上述の実施形態では、宿泊予定情報を宿泊予定ＤＢ１４に保存している（図４（ｄ−１），（ｄ−２）等参照）。
これに対し、宿泊予定ＤＢ１４を設けず、宿泊予定情報をメインメモリのみに保存してもよい。また、所定の記憶装置にファイル形式で保存してもよい。
なお、大量の注文を処理する可能性がある点，一定期間経過後（例えば、数日後）に予約手続が再開される可能性がある点，データ消失のリスクを回避する必要がある点，高速処理が要求されない点等を考慮すれば、宿泊予定の保存先として宿泊予定ＤＢ１４を設ける構成が好ましい。

［（変形例６）宿泊プランの在庫管理の変形例］
上述の実施形態では、客室（又は部屋タイプ）と宿泊プランとが１対１で対応している前提で（上記＜定義＞参照）、宿泊プランの在庫数を個別に管理している（図４（ｃ）参照）。
これに対し、特定の客室（又は特定の部屋タイプ）に対して複数種類の宿泊プランを重複して設定する場合には、客室の空室数を管理するとよい。
例えば、「タイプＡ」の客室（空室数５）に「プランＡＡ」と「プランＢＢ」とが重複して設定されている場合、「プランＡＡ」及び「プランＢＢ」の合計の注文可能数（＝空室数５）のみを管理すれば、「プランＡＡ」及び「プランＢＢ」の一括予約申請を受信したとき矛盾が生じない。

１０ サーバシステム
１１ ユーザＤＢ
１２ 施設ＤＢ
１３ 宿泊プランＤＢ
１４ 宿泊予定ＤＢ
１５ 予約ＤＢ
２０ ユーザ端末（宿泊代表者）
３０ 施設端末
４０ インターネット
７００ 予約申請ページ
９００ 予約申請ページ
１０００ 予約申請ページ

Claims (7)

1. ユーザの端末と接続して宿泊予約管理システムを構成するサーバシステムであって、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段と
   にアクセス可能であり、
   宿泊予定の識別情報を含む第１の宿泊プランの指定情報を前記端末から受信し、該受信した宿泊予定の識別情報と対応付けて前記宿泊予定記憶手段に記憶されている第１の宿泊プランとは異なる第２の宿泊プランを前記宿泊予定記憶手段より読み出し、該第１の宿泊プランと該第２の宿泊プランとを同時に指定可能な予約申請ページを生成する予約申請ページ生成手段と、
   前記生成した予約申請ページを前記端末に送信する予約申請ページ送信手段と、
   前記予約申請ページを介して、前記第１及び前記第２の宿泊プランを指定した予約申請を受信する予約申請受信手段と、
   前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録手段と
   を備える
   ことを特徴とするサーバシステム。
2. 請求項１に記載のサーバシステムにおいて、
   宿泊プランの識別情報に対応させて、宿泊日程を記憶している宿泊プラン記憶手段をさらに有し、
   前記予約申請ページ生成手段は、前記宿泊プラン記憶手段を参照して前記第１及び前記第２の宿泊プランの宿泊日程が一致する場合に限り、前記第１及び前記第２の宿泊プランの同時指定が可能となるように前記予約申請ページを生成する
   ことを特徴とするサーバシステム。
3. 請求項２に記載のサーバシステムにおいて、
   前記宿泊プラン記憶手段は、宿泊プランの識別情報に対応させて、宿泊施設をさらに記憶し、
   前記予約申請ページ生成手段は、前記宿泊プラン記憶手段を参照して前記第１及び前記第２の宿泊プランの宿泊日程及び宿泊施設が一致する場合に限り、前記第１及び前記第２の宿泊プランの同時指定が可能となるように前記予約申請ページを生成する
   ことを特徴とするサーバシステム。
4. 請求項２又は３に記載のサーバシステムにおいて、
   前記予約申請ページ生成手段は、前記第１及び前記第２の宿泊プランの宿泊施設及び宿泊日程がそれぞれ互いに一致する場合には、該第１の宿泊プランの情報が強調表示されるように前記予約申請ページを生成する
   ことを特徴とするサーバシステム。
5. 請求項２又は３に記載のサーバシステムにおいて、
   前記予約申請ページ生成手段は、前記第１及び前記第２の宿泊プランの宿泊施設及び宿泊日程がそれぞれ互いに一致する場合には、前記第１及び前記第２の宿泊プランがデフォルトで同時指定されているように前記予約申請ページを生成する
   ことを特徴とするサーバシステム。
6. ユーザの端末とサーバシステムとが接続した宿泊予約管理システムにおける宿泊一括予約方法であって、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段と
   にアクセス可能な前記サーバシステムが、
   宿泊予定の識別情報を含む第１の宿泊プランの指定情報を前記端末から受信し、該受信
   した宿泊予定の識別情報と対応付けて前記宿泊予定記憶手段に記憶されている第１の宿泊プランとは異なる第２の宿泊プランを前記宿泊予定記憶手段より読み出し、該第１の宿泊プランと該第２の宿泊プランとを同時に指定可能な予約申請ページを生成する予約申請ページ生成ステップと、
   前記生成した予約申請ページを前記端末に送信する予約申請ページ送信ステップと、
   前記予約申請ページを介して、前記第１及び前記第２の宿泊プランを指定した予約申請を受信する予約申請受信ステップと、
   前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録ステップと
   を実行することを特徴とする宿泊一括予約方法。
7. ユーザの端末とサーバシステムとが接続した宿泊予約管理システムにおける宿泊一括予約プログラムであって、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を記憶することが可能な宿泊予定記憶手段と、
   宿泊予定の識別情報と対応付けて宿泊プランの識別情報を含む予約情報を記憶する予約情報記憶手段と
   にアクセス可能な前記サーバシステムに、
   宿泊予定の識別情報を含む第１の宿泊プランの指定情報を前記端末から受信し、該受信
   した宿泊予定の識別情報と対応付けて前記宿泊予定記憶手段に記憶されている第１の宿泊プランとは異なる第２の宿泊プランを前記宿泊予定記憶手段より読み出し、該第１の宿泊プランと該第２の宿泊プランとを同時に指定可能な予約申請ページを生成する予約申請ページ生成ステップと、
   前記生成した予約申請ページを前記端末に送信する予約申請ページ送信ステップと、
   前記予約申請ページを介して、前記第１及び前記第２の宿泊プランを指定した予約申請を受信する予約申請受信ステップと、
   前記予約申請において指定された各宿泊プランに係る予約情報を前記予約情報記憶手段にそれぞれ登録する予約情報登録ステップと
   を実行させるための宿泊一括予約プログラム。