JP6298564B1 - 予約管理装置、予約管理方法及びプログラム - Google Patents

Abstract

【課題】複数のＷｅｂサイトで受け付けられた予約の管理を容易にすることを可能とする。
【解決手段】予約管理装置１０は、ログイン処理部１２と、店舗管理画面生成部１３と、表示処理部１４とを具備する。ログイン処理部１２は、複数のＷｅｂサーバ装置にアクセスし、Ｗｅｂサーバ装置の各々によって管理されているＷｅｂサイトの各々で受け付けられた予約を示す予約情報を収集する。店舗管理画面生成部１３は、収集された予約情報を含む店舗管理画面を生成する。表示処理部は、生成された店舗管理画面を店舗端末に表示する。
【選択図】図２

Description

本発明は、予約管理装置、予約管理方法及びプログラムに関する。

近年では、ユーザによって利用されるユーザ端末をインターネットに接続し、例えばＷｅｂサイトを介して飲食店等の店舗（または施設）に対して予約を行うことが知られている。

この場合、ユーザは、パーソナルコンピュータ（ＰＣ）、スマートフォン及びタブレット端末等のユーザ端末から上記したＷｅｂサイトを管理するＷｅｂサーバ装置にアクセスし、予約に必要な情報を入力することによって、店舗に対する予約を行うことができる。

一方、Ｗｅｂサイトを介して予約される店舗には店舗端末（パーソナルコンピュータ等）が設置されており、当該店舗の従業員等は、当該店舗端末を介してＷｅｂサイトで受け付けられた予約（情報）を確認することができる。

特開２０１７−０８４２４１号公報

ところで、上記した店舗に対する予約を受け付けることが可能なＷｅｂサイトは多様化しており、様々なＷｅｂサイトが存在している。

この場合、店舗が多くの予約を獲得するためには、複数のＷｅｂサイトを介した予約を受ける必要がある。

しかしながら、Ｗｅｂサイト毎に予約の管理画面が異なるため、予約の状況を確認する際には各Ｗｅｂサイトの管理画面を順次確認する必要があり、手間が掛かる。

また、例えばＷｅｂサイトＡを介して予約を受けた場合、ＷｅｂサイトＢにおいて予約可能としている席またはテーブルの状況を更新する必要がある場合がある。この場合においても、店舗の従業員等は、ＷｅｂサイトＢの管理画面において更新の操作を行う必要がある。

そこで、本発明が解決しようとする課題は、複数のＷｅｂサイトで受け付けられた予約の管理を容易にすることが可能な予約管理装置、予約管理方法及びプログラムを提供することにある。

本発明の１つの態様によれば、店舗への予約を受け付けるための異なる第１及び第２のＷｅｂさ使徒の各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置が提供される。前記予約管理装置は、第１の取得手段と、第１の更新手段と、第２の取得手段と、第２の更新手段と、収集手段と、生成手段と、表示処理手段とを具備する。前記第１の取得手段は、前記第１のＷｅｂサイトにおいて設定されている第１のサイト受付時間を取得する。前記第１の更新手段は、前記取得された第１のサイト受付時間と前記予約管理装置において設定されているＷｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第１のサーバ装置内で管理されている、前記第１のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新する。前記第２の取得手段は、前記第２のＷｅｂサイトにおいて設定されている第２のサイト受付時間を取得する。前記第２の更新手段は、前記取得された第２のサイト受付時間と前記Ｗｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第２のサーバ装置内で管理されている、前記第２のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新する。前記収集手段は、前記第１及び第２のサーバ装置にアクセスし、前記第１及び第２のサーバ装置内で管理されている空席情報に基づいて前記第１及び第２のＷｅｂサイトの各々で受け付けられた予約を示す第１の予約情報を収集する。前記生成手段は、前記収集された第１の予約情報を含む店舗管理画面を生成する。前記表示処理手段は、前記生成された店舗管理画面を前記店舗端末に表示する。

本発明は、複数のＷｅｂサイトで受け付けられた予約の管理を容易にすることを可能とする。

本発明の実施形態に係る予約管理装置を含むネットワークシステムの構成の一例を示す図。 予約管理装置の主として機能構成を示すブロック図。 予約管理装置とＷｅｂサーバ装置との連携を開始させる際の予約管理装置の処理手順の一例を示すフローチャート。 ログイン情報登録画面の一例を示す図。 格納部に格納された席情報のデータ構造の一例を示す図。 格納部に格納された予約情報のデータ構造の一例を示す図。 店舗端末に表示された店舗管理画面の一例を示す図。 ユーザがＷｅｂサイトを介して対処店舗に対して新規予約を行った場合の予約管理装置の処理手順の一例を示すフローチャート。 ユーザがＷｅｂサイトで受け付けられた対象店舗への予約の内容を変更した場合の予約管理装置の処理手順の一例を示すフローチャート。 ユーザがＷｅｂサイトを介して対象店舗で受け付けられた予約をキャンセルした場合の予約管理装置の処理手順の一例を示すフローチャート。 店舗端末側で新規予約の登録が行われる場合の予約管理装置の処理手順の一例を示すフローチャート。 予約登録画面の一例を示す図。 店舗端末側で予約の変更が行われる場合の予約管理装置の処理手順の一例を示すフローチャート。 店舗端末側で予約のキャンセルが行われる場合の予約管理装置の処理手順の一例を示すフローチャート。 ユーザがＷｅｂサイトを介して対象店舗に対してリクエスト予約を行った場合の予約管理装置の処理手順の一例を示すフローチャート。 リクエスト予約が承諾される場合の予約管理装置の処理手順の一例を示すフローチャート。 リクエスト予約確認画面の一例を示す図。 リクエスト予約が拒否される場合の予約管理装置の処理手順の一例を示すフローチャート。 空席情報を調整する際の予約管理装置の処理手順の一例を示すフローチャート。 空席情報を調整する必要があるケース及び空席情報を調整する必要がないケースについて具体的に説明するための図。

以下、図面を参照して、本発明の実施形態について説明する。
図１は、本実施形態に係る予約管理装置を含むネットワークシステム（予約管理システム）の構成の一例を示す。本実施形態に係る予約管理装置は、複数のＷｅｂサイトを介して行われる例えば飲食店等の店舗への予約の一括管理（Ｗｅｂ予約管理）を実現するために用いられる。

図１に示すように、予約管理装置１０は、コンピュータ（サーバコンピュータ）１０ａ及び記憶装置１０ｂを備える。コンピュータ１０ａは、例えばＣＰＵ等のプロセッサを含む。記憶装置１０ｂは、例えばＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＲＯＭ（Read Only Memory）またはＲＡＭ（Random Access Memory）等を含む。

予約管理装置１０は、インターネットのようなネットワークを介して複数のＷｅｂサーバ装置と通信可能に接続される。図１においては複数のＷｅｂサーバ装置として便宜的にＷｅｂサーバ装置２０ａ及び２０ｂのみが示されているが、予約管理装置１０は、３以上のＷｅｂサーバ装置と通信可能に接続されても構わない。

Ｗｅｂサーバ装置２０ａ及び２０ｂは、店舗への予約を受けつけるためのＷｅｂサイトを管理し、当該Ｗｅｂサイトを介して各種店舗への予約を受け付けるサービス（以下、Ｗｅｂ予約サービスと表記）をユーザに提供する。なお、Ｗｅｂサーバ装置２０ａ及び２０ｂは、それぞれ異なるＷｅｂサイトを管理するものとする。

また、予約管理装置１０は、Ｗｅｂサーバ装置２０ａ及び２０ｂによって管理されているＷｅｂサイトの各々を介して予約可能な店舗に設置されている店舗端末３０とインターネットのようなネットワークを介して通信可能に接続される。

店舗端末３０は、当該店舗端末３０が設けられている店舗に対するＷｅｂ予約の状況を当該店舗の従業員等が確認するための店舗管理画面を表示するための端末であり、例えばパーソナルコンピュータ（ＰＣ）、スマートフォン及びタブレットコンピュータ等を含む。

なお、図１においては便宜的に１つの店舗端末３０のみが示されているが、予約管理装置１０は、上記したＷｅｂサーバ装置２０ａ及び２０ｂによって管理されるＷｅｂサイトを含む様々なＷｅｂサイトを介して予約を行うことができる複数の店舗の各々に設置されている店舗端末と通信可能に接続される。

以下の説明においては、店舗端末３０が設置されている店舗はＷｅｂサーバ装置２０ａ及び２０ｂの各々によって管理されている２つのＷｅｂサイトを介して予約可能であるものとする。この場合、便宜的に、Ｗｅｂサーバ装置２０ａによって管理されているＷｅｂサイトをＷｅｂサイトＡ、Ｗｅｂサーバ装置２０ｂによって管理されているＷｅｂサイトをＷｅｂサイトＢ、店舗端末３０が設置されている店舗を対象店舗と称する。

図２は、図１に示す予約管理装置１０の主として機能構成を示すブロック図である。図２に示すように、予約管理装置１０は、格納部１１、ログイン処理部１２、店舗管理画面生成部１３、表示処理部１４及びメール解析部１５を含む。

本実施形態において、格納部１１は、例えば上記した記憶装置１０ｂに格納されている。また、本実施形態において、ログイン処理部１２、店舗管理画面生成部１３、表示処理部１４及びメール解析部１５は、例えば図１に示すコンピュータ１０ａが記憶装置１０ｂに格納されているプログラムを実行すること（つまり、ソフトウェア）によって実現されるものとする。このプログラムは、コンピュータ読み取り可能な記憶媒体に予め格納して頒布されるものでもよいし、ネットワークを介して予約管理装置１０にダウンロードされるものであっても構わない。なお、これらの各部１２〜１５は、ハードウェア（例えば、ＩＣ等）によって実現されるものであってもよい。

格納部１１には、Ｗｅｂサーバ装置２０ａ及び２０ｂによって管理されているＷｅｂサイトＡ及びＢの各々にログインするための情報（以下、ログイン情報と表記）が格納されている。このログイン情報には、ログインＩＤ及びパスワードが含まれる。

ログイン処理部１２は、格納部１１に格納されているログイン情報を取得する。ログイン処理部１２は、Ｗｅｂサーバ装置２０ａ及び２０ｂにアクセスし、取得されたログイン情報を順次使用してＷｅｂサイトＡ及びＢにログインする。これにより、ログイン処理部１２は、ＷｅｂサイトＡで受け付けられた対象店舗への予約を示す予約情報を収集する。また、ログイン処理部１２は、ＷｅｂサイトＢで受け付けられた対象店舗への予約（の内容）を示す予約情報を収集する。ログイン処理部１２によって収集された予約情報は、格納部１１に格納される。

店舗管理画面生成部１３は、格納部１１に格納された予約情報を含む店舗管理画面を生成する。店舗管理画面は、上記したように対象店舗の従業員等が当該対象店舗に対する予約状況（Ｗｅｂ予約状況）を確認するための画面である。

表示処理部１４は、店舗管理画面生成部１３によって生成された店舗管理画面（データ）を店舗端末３０に対して送信することによって、当該店舗管理画面を当該店舗端末３０に表示する。

ここで、Ｗｅｂ予約サービスを利用するユーザは、ＷｅｂサイトＡ及びＢを介して対象店舗に対する新規予約、予約の変更及び予約のキャンセル等を行うことができる。これにより、例えばＷｅｂサイトＡで対象店舗に対する新規予約が受け付けられた場合、当該ＷｅｂサイトＡを管理するＷｅｂサーバ装置２０ａは、予め登録されている当該ユーザのメールアドレスに対してメールを送信する。なお、ＷｅｂサイトＡで予約の変更及び予約のキャンセルが受け付けられた場合についても同様に、その旨を通知するためのメールが送信される。ここでは、ＷｅｂサイトＡ（Ｗｅｂサーバ装置２０ａ）について説明したが、ＷｅｂサイトＢ（Ｗｅｂサーバ装置２０ｂ）についても同様である。

メール解析部１５は、Ｗｅｂサーバ装置２０ａ及び２０ｂによって送信されたメールを解析する。メール解析部１５は、解析結果に基づいて、新規予約、予約の変更または予約のキャンセルを受け付けたＷｅｂサイトを特定する。

この場合、ログイン処理部１２は、格納部１１に格納されているログイン情報を使用して、メール解析部１５によって特定されたＷｅｂサイトにログインする。ログイン処理部１２は、ログインしたＷｅｂサイトで受け付けられた対象店舗への新規予約、予約の変更または予約のキャンセルを示す情報を取得する。ここでログイン処理部１２によって取得された情報は、後述する他のＷｅｂサイトの空席情報の更新及び店舗管理画面の更新等に利用される。

以下、本実施形態に係る予約管理装置１０の動作について説明する。上記したように対象店舗への予約は、ＷｅｂサイトＡ及びＢで受け付け可能である。この場合、対象店舗には、ＷｅｂサイトＡ及びＢの各々から発行されたそれぞれ異なるログイン情報が割り当てられている。ログイン情報は、ＷｅｂサイトＡ及びＢにログインするための情報である。なお、このログイン情報にはログインＩＤ及びパスワードが含まれているが、当該ログインＩＤ及びパスワードは対象店舗側で指定したものであってもよい。

ここで、対象店舗が本実施形態に係る予約管理装置１０によるＷｅｂ予約管理を利用するためには、当該対象店舗に割り当てられているＷｅｂサイトＡ及びＢにログインするためのログイン情報（以下、単にＷｅｂサイトのログイン情報と表記）を登録し、当該予約管理装置１０とＷｅｂサーバ装置２０ａ及び２０ｂとの連携を開始させる必要がある。

まず、図３のフローチャートを参照して、予約管理装置１０とＷｅｂサーバ装置２０ａ及び２０ｂとの連携を開始させる際の予約管理装置１０の処理手順の一例について説明する。

この場合、予約管理装置１０に含まれる表示処理部１４は、各Ｗｅｂサイトのログイン情報を登録するための画面（以下、ログイン情報登録画面と表記）を店舗端末３０に表示する（ステップＳ１）。

ここで、図４は、ログイン情報登録画面の一例を示す。図４に示すログイン情報登録画面においては、ＷｅｂサイトＡ及びＢを含む複数のＷｅｂサイトのログイン情報を登録することができる。

図４に示すように、ログイン情報登録画面１００には、Ｗｅｂサイト毎にログインＩＤ欄１０１及びパスワード欄１０２が設けられている。

上記したように対象店舗はＷｅｂサイトＡ及びＢのログイン情報を有しているため、対象店舗の従業員等は、ＷｅｂサイトＡに対応するログインＩＤ欄１０１及びパスワード欄１０２にＷｅｂサイトＡのログインＩＤ及びパスワードを入力し、ＷｅｂサイトＢに対応するログインＩＤ欄１０１及びパスワード欄１０２にＷｅｂサイトＢのログインＩＤ及びパスワードを入力する。

なお、ＷｅｂサイトＡ及びＢ以外の他のＷｅｂサイトでも対象店舗への予約等が受け付け可能であり、当該他のＷｅｂサイトのログイン情報を有しているような場合には、当該他のＷｅｂサイトのログイン情報もログイン情報登録画面１００において登録することになる。

上記したようにログイン情報登録画面１００に対する入力が終了されると、当該ログイン情報登録画面１００において入力されたログイン情報（ここでは、ＷｅｂサイトＡ及びＢのログイン情報）は、店舗端末３０から予約管理装置１０に対して送信される。

図３に戻ると、予約管理装置１０は、店舗端末３０から送信されたログイン情報を受信する（ステップＳ２）。予約管理装置１０において受信されたログイン情報は、格納部１１に格納される。

次に、ログイン処理部１２は、格納部１１に格納された各ログイン情報に対して以下のステップＳ３〜Ｓ５の処理を実行する。ここでは、ＷｅｂサイトＡのログイン情報について主に説明する。

この場合、ログイン処理部１２は、ＷｅｂサイトＡのログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ３）。

ここで、ＷｅｂサイトＡ（を管理するＷｅｂサーバ装置２０ａ）においては、当該ＷｅｂサイトＡで予約の有無が管理されている対象店舗の席（テーブル）を示す席情報、当該席情報によって示される席のうち、ＷｅｂサイトＡで既に受け付けられた予約を示す予約情報及び現時点で予約を受け付けることが可能な席（つまり、空席）を示す空席情報等が保持されている。

ログイン処理部１２は、ステップＳ３においてログインしたＷｅｂサイトＡにおいて保持されている席情報及び予約情報を取得する（ステップＳ４）。

ステップＳ４において取得された席情報及び予約情報は、格納部１１に格納される（ステップＳ５）。

ここでは、ＷｅｂサイトＡのログイン情報について説明したが、ＷｅｂサイトＢのログイン情報についても同様の処理が実行され、格納部１１には、ＷｅｂサイトＢにおいて保持されている席情報及び予約情報が格納される。

ここで、図５は、格納部１１に格納された席情報のデータ構造の一例を示す。ここでは、ＷｅｂサイトＡから取得された席情報について説明する。

図５に示すように、席情報には、席ＩＤに対応づけて席の種類及び利用可能人数等が含まれている。

席ＩＤは、ＷｅｂサイトＡで予約の有無が管理されている対象店舗の席（つまり、ＷｅｂサイトＡに割り当てられている席）を識別するための識別情報である。

席の種類は、当該席の種類に対応づけられている席ＩＤによって識別される席の種類を示し、例えばテーブル、座敷及び円卓等が含まれる。

利用可能人数は、当該利用可能人数に対応づけられている席ＩＤによって識別される席（テーブル、座敷及び円卓等）を利用することができる人数（最大人数及び最小人数）を示す。

図５に示す例では、ＷｅｂサイトＡから取得された席情報には、席情報１１１ａ及び１１１ｂが含まれている。

席情報１１１ａには、席ＩＤ「１」に対応づけて席の種類「テーブル１」及び利用可能人数「４」が含まれている。この席情報１１１ａによれば、席ＩＤ「１」によって識別されるＷｅｂサイトＡで予約の有無が管理されている（つまり、ＷｅｂサイトＡに割り当てられている）席は「テーブル１」の席であり、当該テーブルの利用可能人数が４人であることが示されている。

席情報１１１ｂには、席ＩＤ「２」に対応づけて席の種類「テーブル２」及び利用可能人数「８」が含まれている。この席情報１１１ｂによれば、席ＩＤ「２」によって識別されるＷｅｂサイトＡで予約の有無が管理されている席は「テーブル２」の席であり、当該テーブルの利用可能人数が８であることが示されている。

ここでは席情報１１１ａ及び１１１ｂについてのみ説明したが、格納部１１には、ＷｅｂサイトＡから取得された全ての席情報が格納されている。

また、格納部１１にはＷｅｂサイトＢから取得された席情報についても格納されているが、当該席情報のデータ構造は、図５において説明したデータ構造と同様であるため、その詳しい説明を省略する。

なお、ＷｅｂサイトＡで予約の有無が管理されている対象店舗の席とＷｅｂサイトＢで予約の有無が管理されている対象店舗の席とは少なくとも一部が重複していてもよいし、重複しないようにＷｅｂサイトＡ及びＢに対してそれぞれ異なる席が割り当てられていてもよい。

上記したＷｅｂサイトＡで予約の有無が管理される対象店舗の席は、当該ＷｅｂサイトＡにおいて予め設定されている。同様に、ＷｅｂサイトＢで予約の有無が管理される対象店舗の席は、当該ＷｅｂサイトＢにおいて予め設定されている。なお、ＷｅｂサイトＡ及びＢで予約の有無が管理される対象店舗の席は、例えば店舗端末３０を操作する対象店舗の従業員等によって変更されることも可能である。

図６は、格納部１１に格納された予約情報のデータ構造の一例を示す。ここでは、ＷｅｂサイトＡから取得された予約情報について説明する。

図６に示すように、予約情報には、予約ＩＤに対応づけて、氏名、メールアドレス、利用日時、人数及び席ＩＤが含まれている。

予約ＩＤは、ＷｅｂサイトＡで受け付けられた予約に対して割り当てられた識別情報である。

氏名は、当該氏名に対応づけられている予約ＩＤによって識別される予約を行ったユーザの氏名である。

メールアドレスは、当該メールアドレスに対応づけられている予約ＩＤによって識別される予約を行ったユーザのメールアドレスである。

利用日時は、当該利用日時に対応づけられている予約ＩＤによって識別される予約においてユーザによって指定された対象店舗の利用開始日時（つまり、対象店舗への入店予定日時）である。

人数は、当該人数に対応づけられている予約ＩＤによって識別される予約においてユーザによって指定された対象店舗の利用人数である。

席ＩＤは、当該席ＩＤに対応づけられている予約ＩＤによって識別される予約においてユーザによって指定された対象店舗の席（つまり、予約席）を識別するための識別情報である。

図６に示す例では、ＷｅｂサイトＡから取得された予約情報には、予約情報１１２ａ及び１１２ｂが含まれている。

予約情報１１２ａには、予約ＩＤ「１」に対応づけて氏名「○○○○」、メールアドレス「メールアドレス１」、利用日時「５／２７ １９：００」、人数「４」及び席ＩＤ「１」が含まれている。この予約情報１１２ａによれば、対象店舗の席ＩＤ「１」によって識別される席を５月２７日の１９時から４名で利用する予約が、氏名が「○○○○」であるユーザによってされていることが示されている。また、このユーザのメールアドレスが「メールアドレス１」であることが示されている。

予約情報１１２ｂには、予約ＩＤ「２」に対応づけて氏名「××××」、メールアドレス「メールアドレス２」、利用日時「５／２７ １９：３０」、人数「６」及び席ＩＤ「２」が含まれている。この予約情報１１２ｂによれば、対象店舗の席ＩＤ「２」によって識別される席を５月２７日の１９時半から６名で利用する予約が、氏名が「××××」であるユーザによってされていることが示されている。また、このユーザのメールアドレスが「メールアドレス２」であることが示されている。

ここでは予約情報１１２ａ及び１１２ｂについてのみ説明したが、格納部１１にはＷｅｂサイトＡから取得された全ての予約情報が格納されている。

なお、図６においては予約情報が予約ＩＤ、氏名、メールアドレス、利用日時、人数及び席ＩＤを含むものとして説明したが、当該予約情報には他の情報が含まれていても構わない。具体的には、電話番号、予約時にユーザによって指定されたコース（料理）、または当該ユーザに関する情報（年齢及び性別等）が予約情報に含まれていてもよい。

また、格納部１１にはＷｅｂサイトＢから取得された予約情報についても格納されているが、当該予約情報のデータ構造は、図６において説明したデータ構造と同様であるため、その詳しい説明を省略する。

なお、上記した図５において説明した席情報及び図６において説明した予約情報によれば、対象店舗において用意されている席のうち、予約されている席及び当該席の利用日時等を把握することができる。

再び図３に戻ると、店舗管理画面生成部１３は、格納部１１に格納された席情報及び予約情報に基づいて、対象店舗に対する予約状況を表示するための店舗管理画面を生成する（ステップＳ６）。この場合、店舗管理画面生成部１３は、席情報（ＷｅｂサイトＡ及びＢの各々から取得された席情報）に基づいて、対象店舗において用意されている席の各々のタイムテーブルを生成する。店舗管理画面生成部１３は、生成されたタイムテーブルに対して予約情報（ＷｅｂサイトＡ及びＢの各々から取得された予約情報）によって示される予約を対応づけていくことによって店舗管理画面を生成する。

表示処理部１４は、ステップＳ６において生成された店舗管理画面を店舗端末３０に表示するために、当該店舗管理画面（データ）を店舗端末３０に送信する（ステップＳ７）。これにより、店舗端末３０には、店舗管理画面が表示される。

ここで、図７は、店舗端末３０に表示された店舗管理画面の一例を示す。図７に示すように、店舗管理画面２００には、日付表示領域２０１、席情報表示領域２０２及び予約情報表示領域２０３等が設けられている。

日付表示領域２０１には、例えば現在の日付が表示される。この場合、店舗管理画面２００においては、現在の日付（つまり、本日）の予約状況を確認することができる。

席情報表示領域２０２には、対象店舗（ここでは、店舗Ｘ）において用意されている席の一覧が表示される。

予約情報表示領域２０３には、対象店舗において用意されている席（つまり、席情報表示領域２０２に表示されている席）の各々に対する予約の有無が、日付表示領域２０１に表示されている日付の各時間帯に対応づけて表示される。

図７に示す例では、対象店舗において用意されている席のうち「テーブル１」の席は１９時から４名で予約がされていることが示されている。また、対象店舗において用意されている席のうち、「テーブル２」の席は１９時半から６名で予約がされていることが示されている。また、対象店舗において用意されている席のうち、「テーブル３」の席は現時点で予約がされていないことが示されている。また、対象店舗において用意されている席のうち、「座敷１」の席は２０時から１０名でリクエスト予約されていることが示されている。リクエスト予約については後述する。

ここで、予約情報表示領域２０３に表示されている予約（情報）のうち、実線で囲まれていてハッチングが付されている予約は、当該予約を行ったユーザ（を含むグループ）が既に入店済みであることを示す。一方、予約情報表示領域２０３に表示されている予約のうち、実線で囲まれていてハッチングが付されていない予約は、当該予約を行ったユーザ（を含むグループ）がまだ入店していないことを示す。なお、店舗管理画面２００に表示されている予約を行ったユーザが入店したか否かについては、店舗端末３０を操作することによって対象店舗の従業員が入力することができるものとする。

また、店舗管理画面２００においては、図７に示すように、予約情報表示領域２０３に表示されている予約の各々についての予約経路（例えば、ＷｅｂサイトＡ及びＢ等）の情報も付加されている。これによれば、例えばＷｅｂサイトＡ及びＢで受け付けられた予約の状況（つまり、当該ＷｅｂサイトＡ及びＢを利用した効果等）を容易に把握することができる。なお、予約経路の情報は、予約情報の取得先（ＷｅｂサイトＡ及びＢ等）により、当該予約情報に付加して格納部１１に格納しておくことが可能である。

なお、図７に示す店舗管理画面２００では、５月２７日（土）の１９時から２１時までの予約状況が表示されているが、当該店舗管理画面２００の予約情報表示領域２０３を左右にスクロールすることによって、他の時間帯の予約状況も表示することが可能である。また、店舗管理画面２００において例えば日付表示領域２０１を指定した場合には、カレンダーが表示されるものとし、当該カレンダーにおいて指定された日付の予約の情報を表示させることも可能である。

上記した店舗管理画面２００を確認することによって、対象店舗の従業員等は、複数のＷｅｂサイト（例えば、ＷｅｂサイトＡ及びＢ）の各々で受け付けられた予約を一括で管理及び把握することが可能となる。

ここで、Ｗｅｂ予約サービスを利用するユーザは、当該ユーザが所持するユーザ端末（パーソナルコンピュータ、スマートフォン及びタブレットコンピュータ等）を利用して、例えばＷｅｂサイトＡを介して対象店舗に対する新規予約を行うことができる。

以下、図８のフローチャートを参照して、例えばユーザがＷｅｂサイトＡを介して対象店舗に対して新規予約を行った場合の予約管理装置１０の処理手順について説明する。ここでは、店舗端末３０は上記した図３に示す処理が実行されることによって店舗管理画面が表示された状態であるものとする。

上記したようにユーザがＷｅｂサイトＡを介して対象店舗に対して新規予約を行った場合、当該新規予約の内容を示す情報（以下、新規予約情報と表記）がＷｅｂサイトＡにおいて保持されるとともに、当該新規予約が受け付けられた旨を通知するためのメール（以下、予約完了メールと表記）がＷｅｂサーバ装置２０ａからユーザに対して送信される。なお、新規予約情報は、上記した図６において説明した予約情報と同様に、例えば予約ＩＤに対応づけて氏名、メールアドレス、利用日時、人数及び席ＩＤ等を含む。また、予約完了メールには、対象店舗に対する予約を受け付けたＷｅｂ予約サービス（ここでは、ＷｅｂサイトＡ）を示す情報等が含まれる。上記したＷｅｂサーバ装置２０ａからユーザへの予約完了メールの送信には、新規予約情報に含まれるメールアドレスが用いられる。

なお、Ｗｅｂサーバ装置２０ａにおいては、当該Ｗｅｂサーバ装置２０ａからのメール（例えば、予約完了メール）の送信先として、予約管理装置１０のメールアドレスが登録されているものとする。これによれば、Ｗｅｂサーバ装置２０ａからのメールは、ユーザに加えて、予約管理装置１０に対しても送信される。ここでは、Ｗｅｂサーバ装置２０ａから送信されるメールについてのみ説明したが、Ｗｅｂサーバ装置２０ｂから送信されるメールについても同様である。

上記したようにＷｅｂサーバ装置２０ａから予約完了メールが送信された場合、予約管理装置１０は、当該予約完了メールを受信する（ステップＳ１１）。

メール解析部１５は、ステップＳ１１において受信された予約完了メールを解析する。これによれば、メール解析部１５は、予約完了メールに含まれるＷｅｂ予約サービスを示す情報からユーザが予約を行ったＷｅｂサイト（ここでは、ＷｅｂサイトＡ）を特定する（ステップＳ１２）。

次に、ログイン処理部１２は、ステップＳ１２において特定されたＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ１３）。なお、ステップＳ１３における処理（ログイン処理）は、クローラーまたはＡＰＩ等で実行されても構わない。以下、ＷｅｂサイトＡ及びＢにログインする処理については同様である。

ここで、上記したようにＷｅｂサイトＡには、新規予約の内容を示す新規予約情報が保持されている。このため、ログイン処理部１２は、ステップＳ１３においてログインしたＷｅｂサイトＡにおいて保持されている新規予約情報を取得する（ステップＳ１４）。

ステップＳ１４において取得された新規予約情報は、格納部１１に格納される（ステップＳ１５）。なお、ステップＳ１４において取得された新規予約情報が格納部１１に格納されている予約情報の形式（つまり、店舗管理画面に表示できる形式）と異なるような場合には、当該新規予約情報は適宜加工、編集等されても構わない。なお、以下に説明する格納部１１に格納される各種情報についても同様である。
ステップＳ１５の処理が実行された場合、以下に説明するステップＳ１６及びＳ１７の処理と、ステップＳ１８及びＳ１９の処理とが並列に実行される。
この場合、店舗管理画面生成部１３は、格納部１１に格納された新規予約情報（及び席情報、他の予約情報）に基づいて店舗管理画面を生成する（ステップＳ１６）。
ステップＳ１６の処理が実行されると、表示処理部１４は、当該ステップＳ１６において生成された店舗管理画面を店舗端末３０に表示するために、当該店舗管理画面（データ）を店舗端末３０に送信する（ステップＳ１７）。これにより、店舗端末３０に表示されている店舗管理画面は、新規予約情報が反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、ステップＳ１２において特定されたＷｅｂサイトＡとは別のＷｅｂサイト（ここでは、ＷｅｂサイトＢ）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＢにログインする（ステップＳ１８）。

ログイン処理部１２は、ステップＳ１４において取得された新規予約情報に基づいて、ステップＳ１８においてログインしたＷｅｂサイトＢにおいて保持されている空席情報（在庫情報）を更新する（ステップＳ１９）。

ここで、ＷｅｂサイトＢにおいて保持されている空席情報は、上記したように当該ＷｅｂサイトＢで予約の有無が管理される対象店舗の席のうち、まだ予約されていない空席を示す情報をいう。なお、空席情報によって示される席（空席）には、既に予約された席及び予約をすることができない席は含まれない。

ステップＳ１９の処理においては、例えば新規予約情報に含まれる席ＩＤによって識別される席（以下、ＷｅｂサイトＡの新規予約席と表記）がＷｅｂサイトＢにおいて保持されている席情報によって示される席（つまり、ＷｅｂサイトＢに割り当てられている席）であるか否かを判定する。換言すれば、ＷｅｂサイトＡの新規予約席がＷｅｂサイトＢでも予約の有無が管理されているか否かが判定される。
なお、ＷｅｂサイトＡ及びＷｅｂサイトＢにおいて同一の席が管理されている（割り当てられている）場合、当該ＷｅｂサイトＡ及びＷｅｂサイトＢにおいて管理されている同一の席は、紐付けられるように予め設定しておくことが可能であるものとする。

ＷｅｂサイトＡの新規予約席がＷｅｂサイトＢで管理されていない場合には、新規予約情報（によって示される新規予約）に応じてＷｅｂサイトＢにおいて保持されている空席情報を更新する必要はない。この場合、ステップＳ１９の処理は省略される。

一方、新規予約席がＷｅｂサイトＢで管理されている場合には、ログイン処理部１２は、新規予約情報の内容と同一の内容の予約がＷｅｂサイトＢでも受け付けられたものとして、当該新規予約席については予約ができないように空席情報を更新する。

このステップＳ１９の処理によれば、ＷｅｂサイトＡで新規予約が受け付けられた席（新規予約席）に対してＷｅｂサイトＢを介して重複した予約が行われないように、ＷｅｂサイトＢ（別のＷｅｂサイト）の空席情報を自動的に更新することが可能となる。

ここでは、例えばＷｅｂサイトＡで新規予約が受け付けられた場合には、ＷｅｂサイトＢでも新規予約席について予約ができないように空席情報を更新するものとして説明したが、例えば飲食店等の店舗の予約の場合、１つの席（テーブル及び座敷等）であっても時間帯が異なる場合には異なる予約を受け入れることが可能である。このため、空席情報は、時間の概念を考慮して管理されるものとする。

具体的には、ユーザは、新規予約を示す新規予約情報に含まれる利用日時から予め定められた時間（以下、利用期間と表記）、店舗を利用するものとする。なお、利用期間（滞在期間）については予め定められた期間であってもよいし、店舗端末３０を介して対象店舗の従業員等によって設定されてもよいし、当該新規予約においてコース（料理）が指定されている場合には当該コースに応じた期間としてもよい。

この場合、ＷｅｂサイトＡ及びＢにおいて予約を受け付けることが可能な時間帯から、新規予約情報に含まれる利用日時から始まる利用期間（以下、新規予約による利用期間と表記）を除外した際に、当該利用期間の長さで店舗を利用すると想定される予約を受け入れることが可能な時間（空き時間）が存在する場合には、新規予約席であっても当該空き時間において予約をすることができるものとして空席情報を更新する。一方、新規予約による利用期間を除外した場合に他の予約を受け入れる空き時間が存在しない場合には、新規予約席については予約をすることができないものとして空席情報を更新する。

ここでは、新規予約が受け付けられた場合について説明したが、ＷｅｂサイトＡ及びＢの空席情報の管理は、後述する他の場合であっても同様の概念で行われるものとする。

なお、例えばＷｅｂサイトＡ（Ｗｅｂサーバ装置２０ａ）の仕様によっては、上記した予約完了メールに新規予約に関する様々な情報（例えば、予約ＩＤ、ユーザの氏名、利用日時、人数及び席ＩＤ等）が記述されている場合がある。すなわち、メール解析部１５による予約完了メールの解析結果からステップＳ１４において取得される新規予約情報に相当する情報を取得することができる場合がある。この場合には、ステップＳ１３の処理を省略し、ＷｅｂサイトＡにログインすることなく、新規予約情報（に相当する情報）が取得される構成であっても構わない。

図８においてはユーザがＷｅｂサイトＡを介して対象店舗に対して新規予約を行った場合について説明したが、当該ユーザは、例えばＷｅｂサイトＡで受け付けられた対象店舗への予約の内容を変更するまたは当該予約をキャンセルすることも可能である。

以下、図９のフローチャートを参照して、例えばユーザがＷｅｂサイトＡで受け付けられた対象店舗への予約の内容を変更した場合の予約管理装置１０の処理手順について説明する。

上記したようにユーザがＷｅｂサイトＡで受け付けられた対象店舗への予約の内容を変更した場合、当該予約の変更内容を示す情報（以下、変更予約情報と表記）がＷｅｂサイトＡにおいて保持されるとともに、当該予約の変更が受け付けられた旨を通知するためのメール（以下、変更完了メールと表記）がＷｅｂサーバ装置２０ａからユーザに対して送信される。なお、変更予約情報は、上記した図６において説明した予約情報（つまり、ユーザによって行われた予約の内容を示す情報）の内容の一部を変更したものであり、例えば予約ＩＤに対応づけて氏名、メールアドレス、利用日時、人数及び席ＩＤ等を含む。また、変更完了メールには、対象店舗に対する予約の変更を受け付けたＷｅｂ予約サービス（ここでは、ＷｅｂサイトＡ）を示す情報等が含まれる。上記したＷｅｂサーバ装置２０ａからユーザへの変更完了メールの送信には、変更予約情報に含まれるメールアドレスが用いられる。

なお、上記した予約完了メールと同様に、Ｗｅｂサーバ装置２０ａからの変更完了メールは予約管理装置１０に対しても送信される。このため、予約管理装置１０は、このＷｅｂサーバ装置２０ａから変更完了メールを受信する（ステップＳ２１）。

メール解析部１５は、ステップＳ２１において受信された変更完了メールを解析する。これによれば、メール解析部１５は、変更完了メールに含まれるＷｅｂ予約サービスを示す情報からユーザが予約の変更を行ったＷｅｂサイト（ここでは、ＷｅｂサイトＡ）を特定する（ステップＳ２２）。

次に、ログイン処理部１２は、ステップＳ２２において特定されたＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ２３）。

ここで、上記したようにＷｅｂサイトＡには、予約の変更内容を示す変更予約情報が保持されている。このため、ログイン処理部１２は、ステップＳ２３においてログインしたＷｅｂサイトＡにおいて保持されている変更予約情報を取得する（ステップＳ２４）。なお、変更予約情報は、上記したように既に行われていた予約の内容を示す予約情報（以下、変更前の予約情報と表記）の一部、例えば利用日時、人数及び席ＩＤ等を変更した情報である。

格納部１１に格納されている変更前の予約情報（つまり、内容が変更される前の予約情報）は、ステップＳ２４において取得された変更予約情報に変更される（ステップＳ２５）。

ここで、ＷｅｂサイトＡにおいては複数の予約情報が保持されているが、上記したように変更予約情報は変更前の予約情報の一部の内容を変更した情報である。このため、例えば変更前の予約情報及び変更予約情報に含まれる予約ＩＤは一致する。よって、変更前の予約情報は、変更予約情報に含まれる予約ＩＤに基づいて特定することができる。
ステップＳ２５の処理が実行された場合、以下に説明するステップＳ２６及びＳ２７の処理と、ステップＳ２８及びＳ２９の処理とが並列に実行される。
この場合、店舗管理画面生成部１３は、格納部１１に格納された変更予約情報（及び席情報、他の予約情報）に基づいて店舗管理画面を生成する（ステップＳ２６）。
ステップＳ２６の処理が実行されると、表示処理部１４は、当該ステップＳ２６において生成された店舗管理画面を店舗端末３０に表示するために、当該店舗管理画面（データ）を店舗端末３０に送信する（ステップＳ２７）。これにより、店舗端末３０に表示されている店舗管理画面は、変更予約情報が反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、ステップＳ２２において特定されたＷｅｂサイトＡとは別のＷｅｂサイト（ここでは、ＷｅｂサイトＢ）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＢにログインする（ステップＳ２８）。

ログイン処理部１２は、ステップＳ２４において取得された変更予約情報に基づいて、ステップＳ２８においてログインしたＷｅｂサイトＢにおいて保持されている空席情報（在庫情報）を更新する（ステップＳ２９）。

以下、例えばユーザがＷｅｂサイトＡで予約していた席を変更した場合のステップＳ２９の処理について説明する。

ステップＳ２９の処理においては、例えば変更予約情報に含まれる席ＩＤによって識別される席（以下、ＷｅｂサイトＡの変更予約席と表記）がＷｅｂサイトＢにおいて保持されている席情報によって示される席（つまり、ＷｅｂサイトＢに割り当てられている席）であるか否かを判定する。換言すれば、ＷｅｂサイトＡの変更予約席がＷｅｂサイトＢでも予約の有無が管理されているか否かが判定される。

ＷｅｂサイトＡの変更予約席がＷｅｂサイトＢで管理されていない場合には、変更予約情報によってＷｅｂサイトＢにおいて保持されている空席情報を更新する必要はない。この場合、ステップＳ２９の処理は省略される。

一方、変更予約席がＷｅｂサイトＢでも管理されている場合には、ログイン処理部１２は、変更予約情報の内容と同一の内容の予約がＷｅｂサイトＢでも受け付けられたものとして、当該変更予約席については予約ができないように空席情報を更新する。

また、上記した変更前の予約情報に相当する予約情報に含まれる席ＩＤによって識別される席（変更前の予約席と表記）がＷｅｂサイトＢにおいて管理されている場合には、ログイン処理部１２は、ＷｅｂサイトＢにおいて管理されている変更前の予約席について予約ができるように空席情報を更新する。

このようなステップＳ２９の処理においては、上記したようにユーザがＷｅｂサイトＡで予約していた席を変更した場合に、変更された後の席（変更予約席）についてはＷｅｂサイトＢで予約することができないように空席情報を更新するとともに、変更前の予約席についてはＷｅｂサイトＢで予約することができるように空席情報を更新することが可能となる。なお、予約の変更において席の変更がないような場合には、空席情報の更新は行われなくてもよい。

すなわち、上記したステップＳ２９の処理によれば、ＷｅｂサイトＡで受け付けられた予約の内容が変更された場合であっても、ＷｅｂサイトＢの空席情報を自動的に更新することが可能となる。

なお、上記した予約完了メールと同様に、メール解析部１５による変更完了メールの解析結果からステップＳ２４において取得される変更予約情報に相当する情報を取得することができる場合には、ステップＳ２３の処理を省略し、ＷｅｂサイトＡにログインすることなく、変更予約情報（に相当する情報）が取得される構成であってもよい。

次に、図１０のフローチャートを参照して、例えばユーザがＷｅｂサイトＡを介して対象店舗で受け付けられた予約をキャンセルした場合の予約管理装置１０の処理手順について説明する。

上記したようにユーザがＷｅｂサイトＡで受け付けられた対象店舗への予約をキャンセルした場合、当該予約のキャンセルを示す情報（以下、予約キャンセル情報と表記）がＷｅｂサイトＡにおいて保持されるとともに、予約がキャンセルされた旨を通知するためのメール（以下、キャンセル完了メールと表記）がＷｅｂサーバ装置２０ａからユーザに対して送信される。なお、予約キャンセル情報は、例えばキャンセルされた予約の内容を示し、例えば予約ＩＤに対応づけて氏名、メールアドレス、利用日時、人数及び席ＩＤ等を含む。また、キャンセル完了メールには、対象店舗に対する予約のキャンセルを受け付けたＷｅｂ予約サービス（ここでは、ＷｅｂサイトＡ）を示す情報等が含まれる。上記したＷｅｂサーバ装置２０ａからユーザへのキャンセル完了メールの送信には、予約キャンセル情報に含まれるメールアドレスが用いられる。

なお、上記したようにＷｅｂサーバ装置２０ａからのキャンセル完了メールは予約管理装置１０に対しても送信される。このため、予約管理装置１０は、このＷｅｂサーバ装置２０ａからキャンセル完了メールを受信する（ステップＳ３１）。

メール解析部１５は、ステップＳ３１において受信されたキャンセル完了メールを解析する。これによれば、メール解析部１５は、キャンセル完了メールに含まれるＷｅｂ予約サービスを示す情報からユーザが予約のキャンセルを行ったＷｅｂサイト（ここでは、ＷｅｂサイトＡ）を特定する（ステップＳ３２）。

次に、ログイン処理部１２は、ステップＳ３２において特定されたＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ３３）。

ここで、上記したようにＷｅｂサイトＡには、キャンセルされた予約の内容を示す予約キャンセル情報が保持されている。このため、ログイン処理部１２は、ステップＳ３３においてログインしたＷｅｂサイトＡにおいて保持されている予約キャンセル情報を取得する（ステップＳ３４）。なお、予約キャンセル情報は、予約情報と同様に、例えば予約ＩＤ、氏名、メールアドレス、利用日時及び席ＩＤ等が含まれている。

ログイン処理部１２は、ステップＳ３４において取得された予約キャンセル情報に対応する予約情報を格納部１１からキャンセル（削除）する（ステップＳ３５）。なお、予約キャンセル情報に含まれる予約ＩＤはキャンセル前の予約情報に含まれる予約ＩＤと一致しているものとする。このため、予約キャンセル情報に対応する予約情報は、当該予約キャンセル情報に含まれる予約ＩＤに基づいて特定することが可能である。
ステップＳ３５の処理が実行された場合、以下に説明するステップＳ３６及びＳ３７の処理と、ステップＳ３８及びＳ３９の処理とが並列に実行される。
この場合、店舗管理画面生成部１３は、格納部１１においてキャンセルされた予約情報（及び席情報、他の予約情報）に基づいて店舗管理画面を生成する（ステップＳ３６）。
ステップＳ３６の処理が実行されると、表示処理部１４は、当該ステップＳ３６において生成された店舗管理画面を店舗端末３０に表示するために、当該店舗管理画面（データ）を店舗端末３０に送信する（ステップＳ３７）。これにより、店舗端末３０に表示されている店舗管理画面は、予約情報のキャンセルが反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、ステップＳ３２において特定されたＷｅｂサイトＡとは別のＷｅｂサイト（ここでは、ＷｅｂサイトＢ）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＢにログインする（ステップＳ３８）。

ログイン処理部１２は、ステップＳ３４において取得された予約キャンセル情報に基づいて、ステップＳ３８においてログインしたＷｅｂサイトＢにおいて保持されている空席情報（在庫情報）を更新する（ステップＳ３９）。

ステップＳ３９の処理においては、例えば予約キャンセル情報に含まれる席ＩＤによって識別される席（以下、ＷｅｂサイトＡのキャンセル席と表記）がＷｅｂサイトＢにおいて保持されている席情報によって示される席（つまり、ＷｅｂサイトＢに割り当てられている席）であるか否かを判定する。換言すれば、ＷｅｂサイトＡのキャンセル席がＷｅｂサイトＢでも予約の有無が管理されているか否かが判定される。

ＷｅｂサイトＡのキャンセル席がＷｅｂサイトＢで管理されていない場合には、予約キャンセル情報によってＷｅｂサイトＢにおいて保持されている空席情報を更新する必要はない。この場合、ステップＳ３９の処理は省略される。

一方、キャンセル席がＷｅｂサイトＢで管理されている場合には、例えば図８に示す処理によってＷｅｂサイトＢにおいてもキャンセル席は予約することができないような空席情報となっている。このため、ログイン処理部１２は、キャンセル席について予約ができるように空席情報を更新する。

このステップＳ３９の処理によれば、ＷｅｂサイトＡで予約がキャンセルされた席に対してはＷｅｂサイトＢでも予約が可能となるように、ＷｅｂサイトＢの空席情報を自動的に更新することが可能となる。

なお、上記した予約完了メールと同様に、メール解析部１５による変更完了メールの解析結果からステップＳ３４において取得される予約キャンセル情報に相当する情報を取得することができる場合には、ステップＳ３３の処理を省略し、ＷｅｂサイトＢにログインすることなく、予約キャンセル情報（に相当する情報）が取得される構成であってもよい。

上記したように例えばＷｅｂサイトＡで新規予約、予約の変更及び予約のキャンセルが受け付けられた場合には、ＷｅｂサイトＢにおいても自動的に空席情報を更新することができるとともに、店舗管理画面にも当該新規予約、予約の変更及び予約のキャンセルを反映させることができる。

ここでは、ＷｅｂサイトＡで新規予約、予約の変更及び予約のキャンセルが受け付けられた場合について主に説明したが、別のＷｅｂサイト（例えば、ＷｅｂサイトＢ）で新規予約、予約の変更及び予約のキャンセルが受け付けられた場合についても同様である。

なお、本実施形態においては上記したように個々の席を区別して予約が行われるものとして説明するが、当該席を区別することなく、対象店舗において用意されている予約可能な席数で管理する（つまり、単に席数を増減する）ような構成とすることも可能である。

ここで、新規予約については、ユーザが店舗に電話を掛けることによって行われる（つまり、店舗端末３０側で行われる）場合がある。このような電話による新規予約についても店舗管理画面で管理することともに、ＷｅｂサイトＡ及びＢの空席情報に反映させることが好ましい。

以下、図１１のフローチャートを参照して、店舗端末３０側で新規予約の登録が行われる場合の予約管理装置１０の処理手順について説明する。

この場合、表示処理部１４は、店舗端末３０に予約登録画面を表示する（ステップＳ４１）。

ここで、図１２は、予約登録画面の一例を示す。図１２に示す予約登録画面３００においては、来店日（利用日）、受付方法、状態、ご来店時間（利用開始時間）、人数、席及び氏名（お名前）及び電話番号を入力することが可能である。

なお、受付方法は、例えば「ＴＥＬ」及び「来店」を含む。「ＴＥＬ」は、予約登録画面３００において登録する新規予約が電話による予約であることを示す。ここでは、電話による新規予約を登録する場合について説明するが、例えばユーザが対象店舗に直接来店して予約を行った場合には「来店」が選択されるものとする。

状態は、予約登録画面３００において登録される新規予約の状態を示す。状態は、例えば「予約」、「入店済み」及び「キャンセル」等が含まれる。「予約」は、予約がされた（予約が成立した）状態にあることを示す。「入店済み」は、予約をしていたユーザ（を含むグループ）が入店したことを示す。なお、予約登録画面３００において新規予約が登録された後に当該新規予約の内容を編集する場合には、当該予約登録画面３００と同様の画面（予約編集画面）を表示することができる。予約をしていたユーザが入店した場合には、対象店舗の従業員等は、この予約編集画面で「入店」の項目を指定することによって当該ユーザが入店したことを店舗端末３０に入力することができる。本実施形態においては、図７において説明したように、ユーザが入店したか否かによって店舗管理画面上の予約情報の表示態様を変更することができる。

また、予約登録画面３００には、各種情報を入力することが可能な入力欄３０１〜３０６が設けられている。

入力欄３０１には、利用開始時間を入力することができる。入力欄３０１の右側に設けられている入力欄３０２には、上記した滞在期間が入力される。なお、この入力欄３０２に滞在期間が入力されない場合には、当該滞在期間は例えば予め定められた期間またはコースに応じた期間等に自動的に設定される。

入力欄３０３〜３０６には、それぞれ人数、席、氏名及び電話番号を入力することが可能である。

なお、予約登録画面３００においては、上記した以外に例えば料理のコース及び予約者の情報等が入力できるようにしてもよい。

上記したように予約登録画面３００に各種情報が入力された場合、当該入力された情報（例えば、氏名、電話番号、利用日時、人数及び席等）が店舗端末３０から予約管理装置１０に送信される。

再び図１１に戻ると、予約管理装置１０は、店舗端末３０からの情報を受信する。この場合、予約管理装置１０においては、受信された情報に基づいて新規予約情報が生成される（ステップＳ４２）。なお、この新規予約情報は上記した図８において説明した新規予約情報と同等の情報であるが、上記したように予約登録画面３００においてメールアドレスではなく電話番号が登録されている場合には、ステップＳ４２において生成される新規予約情報には、メールアドレスに代えて電話番が含まれるデータ構造であっても構わない。

ステップＳ４２において生成された新規予約情報は、格納部１１に格納される（ステップＳ４３）。これにより、電話等による新規予約が予約管理装置１０に登録される。
ステップＳ４３の処理が実行された場合、ステップＳ４４及びＳ４５の処理と、ステップＳ４６及びＳ４７の処理とが並列に実行される。
なお、ステップＳ４４及びＳ４５の処理は、図８に示すステップＳ１６及びＳ１７の処理に相当する。これにより、店舗端末３０に表示されている店舗管理画面は、店舗端末３０側で行われた新規予約が反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、例えばＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ４６）。

ログイン処理部１２は、ステップＳ４２において生成された新規予約情報に基づいて、ステップＳ４６においてログインしたＷｅｂサイトＡにおいて保持されている空席情報を更新する（ステップＳ４７）。なお、上記した図８に示すステップＳ１９においてはＷｅｂサイトＢにおいて保持されている空席情報の更新について説明しているが、このステップＳ４７の処理は、ＷｅｂサイトＢをＷｅｂサイトＡとしている以外は当該ステップＳ１９の処理と同様であるため、その詳しい説明を省略する。

また、ここではＷｅｂサイトＡにログインして当該ＷｅｂサイトＡの空席情報を更新するものとして説明したが、上記したステップＳ４６及びＳ４７の処理は、ＷｅｂサイトＡとは別のＷｅｂサイト（つまり、ＷｅｂサイトＢ）についても実行される。

すなわち、上記したように例えば予約登録画面３００を介して電話等による新規予約が登録された場合、当該新規予約（情報）に応じた空席情報の更新は、対象店舗への予約を受け付けることが可能な全てのＷｅｂサイト（つまり、ログイン情報が格納されている全てのＷｅｂサイト）に対して実行される。

なお、対象店舗の従業員等は、例えば上記した予約編集画面等を介して、店舗端末３０側で登録された予約の変更及びキャンセル等を行うことも可能である。

まず、図１３のフローチャートを参照して、店舗端末３０側で予約の変更が行われる場合の予約管理装置１０の処理手順について説明する。

この場合、表示処理部１４は、店舗端末３０に予約編集画面を表示する（ステップＳ５１）。この予約編集画面においては、既に受け付けられた予約に対して、上記した図１２に示す各項目（例えば、ご来店時間、人数及び席等）を変更する（つまり、予約の変更を行う）ことができる。

このように予約編集画面において予約の変更が行われた場合、当該変更された情報が店舗端末３０から予約管理装置１０に送信される。

予約管理装置１０は、店舗端末３０からの情報を受信する。この場合、予約管理装置１０においては、受信された情報に基づいて変更予約情報が生成される（ステップＳ５２）。なお、この変更予約情報は、上記した図９において説明した変更予約情報と同等の情報である。

ステップＳ５２の処理が実行されると、格納部１１に格納されている予約情報がステップＳ５２において生成された変更予約情報に変更される（ステップＳ５３）。なお、変更予約情報に変更される予約情報は、当該変更予約情報と同一の予約ＩＤを含む予約情報である。
ステップＳ５３の処理が実行された場合、ステップＳ５４及びＳ５５の処理と、ステップＳ５６及びＳ５７の処理とが並列に実行される。
なお、ステップＳ５４及びＳ５５の処理は、図９に示すステップＳ２６及びＳ２７の処理に相当する。これにより、店舗端末３０に表示されている店舗管理画面は、店舗端末３０側で行われた予約の変更が反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、例えばＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ５６）。

ログイン処理部１２は、ステップＳ５２において生成された変更予約情報に基づいて、ステップＳ５６においてログインしたＷｅｂサイトＡにおいて保持されている空席情報を更新する（ステップＳ５７）。なお、上記した図９に示すステップＳ２９においてはＷｅｂサイトＢにおいて保持されている空席情報の更新について説明しているが、このステップＳ５７の処理は、ＷｅｂサイトＢをＷｅｂサイトＡとしている以外は当該ステップＳ２９の処理と同様であるため、その詳しい説明を省略する。

また、ここではＷｅｂサイトＡにログインして当該ＷｅｂサイトＡの空席情報を更新するものとして説明したが、上記したステップＳ５６及びＳ５７の処理は、ＷｅｂサイトＡとは別のＷｅｂサイト（つまり、ＷｅｂサイトＢ）についても実行される。

次に、図１４のフローチャートを参照して、店舗端末３０側で予約のキャンセルが行われる場合の処理手順について説明する。

この場合、表示処理部１４は、店舗端末３０に予約編集画面を表示する（ステップＳ６１）。この予約編集画面においては、既に受け付けられた予約に対して上記した図１２に示す状態の「キャンセル」の項目を指定することによって、当該予約をキャンセルすることができるものとする。

このように予約編集画面において予約のキャンセルが行われた場合、当該キャンセルされた予約の情報が店舗端末３０から予約管理装置１０に送信される。

予約管理装置１０は、店舗端末３０からの情報を受信する。この場合、予約管理装置１０においては、受信された情報に基づいて予約キャンセル情報が生成される（ステップＳ６２）。なお、この予約キャンセル情報は、上記した図１０において説明した予約キャンセル情報と同等の情報である。

ステップＳ６２の処理が実行されると、予約キャンセル情報に対応する予約情報が格納部１１からキャンセル（削除）される（ステップＳ６３）。なお、格納部１１からキャンセルされる予約情報は、予約キャンセル情報にと同一の予約ＩＤを含む予約情報である。
ステップＳ６３の処理が実行された場合、ステップＳ６４及びＳ６５の処理と、ステップＳ６６及びＳ６７の処理が並列に実行される。
なお、ステップＳ６４及びＳ６５の処理は、図１０に示すステップＳ３６及びＳ３７の処理に相当する。これにより、店舗端末３０に表示されている店舗管理画面は、店舗端末３０側で行われた予約のキャンセルが反映された店舗管理画面に更新される。

一方、ログイン処理部１２は、例えばＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ６６）。

ログイン処理部１２は、ステップＳ６２において生成された予約キャンセル情報に基づいて、ステップＳ６６においてログインしたＷｅｂサイトＡにおいて保持されている空席情報を更新する（ステップＳ６７）。なお、上記した図１０示すステップＳ３９においてはＷｅｂサイトＢにおいて保持されている空席情報の更新について説明しているが、このステップＳ６７の処理は、ＷｅｂサイトＢをＷｅｂサイトＡとしている以外は当該ステップＳ３９の処理と同様であるため、その詳しい説明を省略する。

また、ここではＷｅｂサイトＡにログインして当該ＷｅｂサイトＡの空席情報を更新するものとして説明したが、上記したステップＳ６６及びＳ６７の処理は、ＷｅｂサイトＡとは別のＷｅｂサイト（つまり、ＷｅｂサイトＢ）についても実行される。

なお、ここでは店舗端末３０側で新規予約、予約の変更及び予約のキャンセルを行うことができるものとして説明したが、本実施形態に係る予約管理装置１０においてＷｅｂサイトで受け付けられた予約（Ｗｅｂ予約）の管理のみを行う場合には、上記した図１１、図１３及び図１４の処理は実行されない構成であっても構わない。

ここで、ＷｅｂサイトＡ及びＢにおいては、前述した通常の予約に加えて、リクエスト予約と称される形態の予約を行うことが可能であるものとする。

通常の予約はユーザによる予約の申し込みの完了と同時に予約が成立するのに対して、リクエスト予約は、ユーザによる予約の申し込みの完了後、当該予約を受けるか否かの店舗からユーザへの連絡によって予約の成否が確定する点が通常の予約とは異なる。

以下、図１５のフローチャートを参照して、ユーザがＷｅｂサイトＡを介して対象店舗に対してリクエスト予約を行った場合の予約管理装置１０の処理手順について説明する。

上記したようにユーザがＷｅｂサイトＡを介して対象店舗に対してリクエスト予約を行った場合、当該リクエスト予約の内容を示す情報（以下、リクエスト予約情報と表記）がＷｅｂサイトＡにおいて保持されるとともに、当該リクエスト予約が受け付けられた旨を通知するためのメール（以下、リクエスト予約メールと表記）がＷｅｂサーバ装置２０ａからユーザに対して送信される。なお、リクエスト予約情報は、例えばＷｅｂサイトＡで受け付けられたリクエスト予約に対して割り当てられたリクエスト予約ＩＤを含む。リクエスト予約情報のデータ構造は、予約ＩＤに代えてリクエスト予約ＩＤが含まれている点以外は、例えば図６において説明した予約情報と同様であるため、その詳しい説明を省略する。

なお、リクエスト予約は、例えばユーザの要望等を対象店舗に伝え、当該要望を実現できるか否かを対象店舗側で判断して、当該予約を受けるか否かを判断するような場合に用いられるため、当該リクエスト予約には当該要望等のテキストが含まれていてもよい。

また、上記したリクエスト予約メールには、対象店舗に対する予約を受け付けたＷｅｂ予約サービス（ここでは、ＷｅｂサイトＡ）を示す情報等が含まれる。上記したＷｅｂサーバ装置２０ａからユーザへのリクエスト予約メールの送信には、リクエスト予約情報に含まれるメールアドレスが用いられる。

なお、上記したようにＷｅｂサーバ装置２０ａからのリクエスト予約メールは、他のメールと同様に、予約管理装置１０に対しても送信される。このため、予約管理装置１０は、このＷｅｂサーバ装置２０ａからリクエスト予約メールを受信する（ステップＳ７１）。

メール解析部１５は、ステップＳ７１において受信されたリクエスト予約メールを解析する。これによれば、メール解析部１５は、リクエスト予約メールに含まれるＷｅｂ予約サービスを示す情報からユーザがリクエスト予約を行ったＷｅｂサイト（ここでは、ＷｅｂサイトＡ）を特定する（ステップＳ７２）。

次に、ログイン処理部１２は、ステップＳ７２において特定されたＷｅｂサイトＡのログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ７３）。

ここで、上記したようにＷｅｂサイトＡには、リクエスト予約の内容を示すリクエスト予約情報が保持されている。このため、ログイン処理部１２は、ステップＳ７３においてログインしたＷｅｂサイトＡにおいて保持されているリクエスト予約情報を取得する（ステップＳ７４）。

ステップＳ７４において取得されたリクエスト予約情報は、格納部１１に格納される（ステップＳ７５）。

ステップＳ７５の処理が実行された場合、ステップＳ７６及びＳ７７の処理と、ステップＳ７８及びＳ７９の処理とが並列に実行される。

この場合、店舗管理画面生成部１３は、格納部１１に格納されたリクエスト予約情報（及び席情報、他の予約情報）に基づいて店舗管理画面を生成する（ステップＳ７６）。

ステップＳ７６の処理が実行されると、表示処理部１４は、当該ステップＳ７６において生成された店舗管理画面を店舗端末３０に表示するために、当該店舗管理画面（データ）を店舗端末３０に送信する（ステップＳ７７）。これにより、店舗端末３０に表示されている店舗管理画面は、リクエスト予約情報が反映された店舗管理画面に更新される。なお、図７において説明したように、リクエスト予約（を示すリクエスト予約情報）は、通常の予約（を示す予約情報）とは異なる態様で表示される。このため、対象店舗の従業員等は、リクエスト予約の有無を容易に把握することが可能となる。
一方、ログイン処理部１２は、ステップＳ７２において特定されたＷｅｂサイトＡとは別のＷｅｂサイト（ここでは、ＷｅｂサイトＢ）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＢにログインする（ステップＳ７８）。
ログイン処理部１２は、ステップＳ７４において取得されたリクエスト予約情報に基づいて、ステップＳ７８においてログインしたＷｅｂサイトＢにおいて保持されている空席情報（在庫情報）を更新する（ステップＳ７９）。なお、上記した図８に示すステップＳ１９においては新規予約情報に基づいて空席情報が更新される場合について説明しているが、このステップＳ７９の処理は、新規予約情報をリクエスト予約情報としている点以外は当該ステップＳ１９の処理と同様であるため、その詳しい説明を省略する。

上記したように対象店舗に対するリクエスト予約が受け付けられた場合、当該対象店舗の従業員等は、店舗端末３０において当該リクエスト予約の内容を確認し、当該リクエスト予約を受けるか否か（つまり、承諾するか拒否するか）を回答する必要がある。以下、リクエスト予約が承諾される場合及び拒否される場合の予約管理装置１０の動作について説明する。

図１６のフローチャートは、リクエスト予約が承諾される場合の予約管理装置１０の処理手順について説明する。

まず、上記した図１５に示すステップＳ７７の処理が実行された場合、店舗端末３０には、例えば図７に示すようなリクエスト予約情報によって示されるリクエスト予約が表示された店舗管理画面が表示される。この店舗管理画面上でリクエスト予約を指定する操作が行われた場合、表示処理部１４は、店舗端末３０にリクエスト予約確認画面を表示する（ステップＳ８１）。

ここで、図１７は、リクエスト予約確認画面の一例を示す。図１７に示すように、リクエスト予約確認画面４００には、リクエスト予約情報によって示されるリクエスト予約の内容が表示されるとともに、「承諾する」ボタン４０１及び「拒否する」ボタン４０２が設けられている。

「承諾する」ボタン４０１は、リクエスト予約確認画面４００に表示されているリクエスト予約を承諾する際に指定されるボタンである。

「拒否する」ボタン４０２は、リクエスト予約確認画面４００に表示されているリクエスト予約を拒否する際に指定されるボタンである。

ここで、対象店舗の従業員等がリクエスト予約を承諾すると判断し、リクエスト予約確認画面４００上で「承諾する」ボタン４０１が指定された場合を想定する。この場合、店舗端末３０は、リクエスト予約を承諾する旨の指示（以下、リクエスト予約の承諾指示と表記）を予約管理装置１０に送信する。なお、リクエスト予約の承諾指示には、例えば当該リクエスト予約に対して割り当てられているリクエスト予約ＩＤが含まれている。

これにより、予約管理装置１０は、店舗端末３０からリクエスト予約の承諾指示を受信する（ステップＳ８２）。

次に、ログイン処理部１２は、例えば図１５に示すステップＳ７２において特定されているＷｅｂサイトＡ（つまり、リクエスト予約を受け付けたＷｅｂサイト）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ８３）。

ログイン処理部１２は、ＷｅｂサイトＡに保持されている、ステップＳ８２において受信されたリクエスト予約の承諾指示に含まれるリクエスト予約ＩＤを含むリクエスト予約情報のステータスを「成立（承諾）」に変更する（ステップＳ８４）。

ステップＳ８４の処理が実行されると、格納部１１に格納されているリクエスト予約情報（リクエスト予約の承諾指示に含まれるリクエスト予約ＩＤを含むリクエスト予約情報）は、例えば当該リクエスト予約情報に含まれるリクエスト予約ＩＤを予約ＩＤとする新規予約情報に変更される（ステップＳ８５）。これによれば、リクエスト予約情報によって示されるリクエスト予約の内容で予約が成立し、このリクエスト予約情報は新規予約情報と同様に扱われる。

ステップＳ８５の処理が実行された場合、図８に示すステップＳ１６及びＳ１７の処理に相当するステップＳ８６及びＳ８７の処理が実行される。これにより、店舗端末３０に表示されている店舗管理画面は、リクエスト予約が新規予約として成立したことが反映された店舗管理画面に更新される。

次に、図１８のフローチャートを参照して、リクエスト予約が拒否される場合の予約管理装置１０の処理手順について説明する。

まず、図１６に示すステップＳ８１の処理に相当するステップＳ９１の処理が実行される。

ここで、対象店舗の従業員等がリクエスト予約を拒否すると判断し、リクエスト予約確認画面４００上で「拒否する」ボタン４０２が指定された場合を想定する。この場合、店舗端末３０は、リクエスト予約を拒否する旨の指示（以下、リクエスト予約の拒否指示と表記）を予約管理装置１０に送信する。なお、リクエスト予約の拒否指示には、例えば当該リクエスト予約に対して割り当てられているリクエスト予約ＩＤが含まれている。

これにより、予約管理装置１０は、店舗端末３０からリクエスト予約の拒否指示を受信する（ステップＳ９２）。

次に、ログイン処理部１２は、例えば図１５に示すステップＳ７２において特定されているＷｅｂサイトＡ（つまり、リクエスト予約を受け付けたＷｅｂサイト）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＡにログインする（ステップＳ９３）。

ログイン処理部１２は、ＷｅｂサイトＡに保持されている、ステップＳ９２において受信されたリクエスト予約の拒否指示に含まれるリクエスト予約ＩＤを含むリクエスト予約情報のステータスを「キャンセル（拒否）」に変更する（ステップＳ９４）。

ステップＳ９４の処理が実行されると、格納部１１に格納されているリクエスト予約情報（リクエスト予約の拒否指示に含まれるリクエスト予約ＩＤを含むリクエスト予約情報）は、当該格納部１１から削除される（ステップＳ９５）。
ステップＳ９５の処理が実行された場合、ステップＳ９６及びＳ９７の処理と、ステップＳ９８及びＳ９９の処理とが並列に実行される。

なお、ステップＳ９６及びＳ９７の処理は、図１０に示すステップＳ３６及びＳ３７の処理に相当する。これにより、店舗端末３０に表示されている店舗管理画面は、リクエスト予約がキャンセル（拒否）されたことが反映された店舗管理画面に更新される。
一方、ログイン処理部１２は、図１５に示すステップＳ７２において特定されているＷｅｂサイトＡとは別のＷｅｂサイト（ここでは、ＷｅｂサイトＢ）のログイン情報を格納部１１から取得し、当該ログイン情報を使用してＷｅｂサイトＢにログインする（ステップＳ９８）。
ログイン処理部１２は、ステップＳ７４において取得されたリクエスト予約情報（つまり、ステップＳ９５において削除されたリクエスト予約情報）に基づいて、ステップＳ９８においてログインしたＷｅｂサイトＢにおいて保持されている空席情報（在庫情報）を更新する（ステップＳ９９）。なお、このステップＳ９９の処理は、新規予約がキャンセルされている代わりにリクエスト予約がキャンセルされている点以外は図１０に示すステップＳ３９の処理と同様であるため、その詳しい説明を省略する。

本実施形態においては、上記したようにＷｅｂサイトでリクエスト予約が受け付けられた場合であっても、対象店舗への予約を適切に管理することが可能である。

ところで、Ｗｅｂサイトにおいては、当該Ｗｅｂサイトにおいて予約を受け付けることが可能な時間帯（以下、サイト受付時間と表記）が設定されている。しかしながら、このサイト受付時間は、日毎に設定（個別設定）することができないのが一般的である。

また、予約管理装置１０側においても、上述した店舗端末３０に表示される店舗管理画面を介してＷｅｂ予約の受付時間（以下、Ｗｅｂ受付時間）が設定される。

更に、店舗端末３０に表示される店舗管理画面を介してＷｅｂ受付時間の一部の時間帯についてはＷｅｂ予約を受け付けないこと（以下、ブロックと表記）を設定することも可能であるものとする。

したがって、上記したように予約等が行われる以外であっても、サイト受付時間、Ｗｅｂ受付時間及びブロックの設定状況によっては各Ｗｅｂサイトの空席情報を調整する必要がある。

以下、図１９のフローチャートを参照して、空席情報を調整する際の予約管理装置１０の処理手順について説明する。

ここで、上記したＷｅｂ受付時間は、例えば予約管理装置１０とＷｅｂサーバ装置（他例えばＷｅｂサーバ装置２０ａ及び２０ｂ）との連携が設定される際に設定される。この場合、ログイン処理部１２は、Ｗｅｂ受付時間が設定されたＷｅｂサイトを特定する（ステップＳ１０１）。以下の説明においては、ステップＳ１０１において特定されたＷｅｂサイトを対象Ｗｅｂサイトと称する。

次に、ログイン処理部１２は、対象Ｗｅｂサイトにおいて設定されているサイト受付時間（以下、対象Ｗｅｂサイトのサイト受付時間と表記）を取得する（ステップＳ１０２）。対象Ｗｅｂサイトのサイト受付時間は、例えば格納部１１に格納されている対象Ｗｅｂサイトのログイン情報を使用して当該対象Ｗｅｂサイトにログインすることによって、当該対象Ｗｅｂサイトから取得される。なお、ログイン処理部１２によって取得された対象Ｗｅｂサイト受付時間は、例えば予約管理装置１０内で管理されてもよい。

ログイン処理部１２は、予約管理装置１０において設定されたＷｅｂ受付時間とステップＳ１０２において取得された対象Ｗｅｂサイトのサイト受付時間とが一致しているか否かを判定する（ステップＳ１０３）。換言すれば、ステップＳ１０３においては、例えばＷｅｂ受付時間内に対象Ｗｅｂサイトのサイト受付時間と対応しない時間帯が存在しないか否かが判定される。

Ｗｅｂ受付時間と対象Ｗｅｂサイトのサイト受付時間とが一致しないと判定された場合（ステップＳ１０３のＮＯ）、ログイン処理部１２は、上記したように対象Ｗｅｂサイトにログインし、当該対象Ｗｅｂサイトの空席情報を調整する（ステップＳ１０４）。なお、ステップＳ１０４における空席情報の調整の具体例については後述する。

一方、Ｗｅｂ受付時間と対象Ｗｅｂサイトのサイト受付時間とが一致すると判定された場合（ステップＳ１０３のＹＥＳ）、ログイン処理部１２は、当該対象Ｗｅｂサイトのサイト受付時間（及びＷｅｂ受付時間）とブロックが設定されている時間（Ｗｅｂ予約を受け付けない時間）とが重複するか否かを判定する（ステップＳ１０５）。

対象Ｗｅｂサイトのサイト受付時間とブロックが設定されている時間とが重複すると判定された場合（ステップＳ１０５のＹＥＳ）、ステップＳ１０４の処理が実行される。

一方、対象Ｗｅｂサイトのサイト受付時間とブロックが設定されている時間とが重複しないと判定された場合（ステップＳ１０５のＮＯ）、対象Ｗｅｂサイトのサイト受付時間、Ｗｅｂ受付時間及びブロックとの関係では空席情報の調整は必要ないため、ステップＳ１０４の処理は実行されない。

上記した図１９に示す処理によれば、予約管理装置１０とＷｅｂサーバ装置との連携が設定される場合において、例えばＷｅｂ受付時間の設定（編集）が行われ、当該設定時間とＷｅｂサイトのサイト受付時間とで一致しない時間帯が生じたとき、または当該Ｗｅｂ受付時間とブロックが設定されている時間とが重複する時間帯が生じたときに空席情報の調整が必要であると判定される。なお、ここではＷｅｂ受付時間の設定が行われた場合に図１９の処理が実行されるものとして説明したが、例えば店舗端末３０においてブロックの設定が行われた場合に図１９に示す処理が実行されても構わない。

ここで、図２０を参照して、上記した図１９に示す処理において空席情報を調整する必要があるケース及び空席情報を調整する必要がないケースについて具体的に説明する。

図２０に示す各ケースは、サイト受付時間、Ｗｅｂ受付時間、ブロックが設定されている時間（ブロック設定時間）及び予約の状況が時間帯毎に示されている。なお、図２０の「予約」は、当該予約における利用開始時間及び予め設定されている利用期間を考慮した時間帯（つまり、店舗を利用すると想定される時間帯）を示している。

例えば図２０に示すケース１においては、サイト受付時間は１９時から２１時までの時間帯であり、Ｗｅｂ受付時間も同様に１９時から２１時までの時間帯である。この場合、サイト受付時間及びＷｅｂ受付時間は一致しており、１９時から２１時までの時間帯においては予約の受付が可能であるため、空席情報の調整は不要である。

一方、ケース２においては、サイト受付時間は１９時から２１時までの時間帯であり、Ｗｅｂ受付時間は１９時から２０時半までの時間帯である。この場合、２０時３０分から２１時までの時間帯においては、サイト受付時間とＷｅｂ受付時間が重複しておらず、予約を受け付けることができない。このため、２０時３０分から２１時までの時間帯については予約を受け付けないようにＷｅｂサイトの空席情報が調整される。

次に、ケース３においては、サイト受付時間及びＷｅｂ受付時間はケース１と同様であり、ブロック設定時間は１８時から１９時までの時間帯である。この場合、サイト受付時間及びＷｅｂ受付時間は一致しており、かつ、ブロック設定時間は当該サイト受付時間及びＷｅｂ受付時間と重複していないため、空席情報の調整は不要である。

一方、ケース４においては、サイト受付時間及びＷｅｂ受付時間はケース１と同様であり、ブロック設定時間は２０時半から２１時半までの時間帯である。この場合、サイト受付時間及びＷｅｂ受付時間は一致しているが、２０時３０分から２１時までの時間帯においては、ブロック設定時間とサイト受付時間及びＷｅｂ受付時間とが重複しており、予約を受け付けることができない。このため、２０時３０分から２１時までの時間帯については予約を受け付けないようにＷｅｂサイトの空席情報が調整される。

なお、ケース５については、予約によって店舗が利用されると想定される時間帯についてはサイト受付時間及びＷｅｂ受付時間が一致する時間帯であっても他の予約を受け付けることができないことが示されている。

上記した図１９に示す処理によれば、例えば図２０に示すケース２及びケース４のような場合に自動的に空席情報を調整することができる。

上記したように本実施形態においては、Ｗｅｂサーバ装置２０ａ及び２０ｂ（第１及び第２のサーバ装置）の各々によって管理されているＷｅｂサイトＡ及びＢ（第１及び第２のＷｅｂサイト）の各々で受け付けられた予約を示す予約情報（第１の予約情報）を収集し、当該収集された予約情報を含む店舗管理画面を生成し、当該生成された店舗管理画面が店舗端末３０に表示される。なお、予約情報は、ＷｅｂサイトＡ及びＢの各々にログインすることによって収集される。

本実施形態においては、このような構成により、複数のＷｅｂサイトで受け付けられた予約の管理を容易にすることが可能となる。

また、本実施形態においては、ＷｅｂサイトＡにおいて対象店舗への予約が受け付けられた場合にＷｅｂサーバ装置２０ａから送信されるメールを受信し、当該受信されたメールに基づいてＷｅｂサイトＡにおいて受け付けられた予約を示す予約情報（第２の予約情報）を取得し、当該取得された予約情報を反映した店舗管理画面を生成する。このような構成によれば、例えばＷｅｂサイトＡで新規予約が受け付けられた場合に、当該新規予約が反映された店舗管理画面を店舗端末３０に表示することが可能となる。

更に、本実施形態においては、上記したようにＷｅｂサイトＡで新規予約が受け付けられた場合に、ＷｅｂサイトＢにログインし、当該ＷｅｂサイトＢの空席情報を更新する。これにより、ＷｅｂサイトＡで受け付けられた新規予約と重複する予約がＷｅｂサイトＢで受け付けられることを回避することが可能となる。

また、本実施形態においては、ＷｅｂサイトＡにおいて対象店舗への予約の内容が変更された場合にＷｅｂサーバ装置２０ａから送信されるメールを受信し、当該受信されたメールに基づいてＷｅｂサイトＡにおいて変更された予約の内容を示す予約変更情報を取得し、当該取得された予約変更情報を反映した店舗管理画面を生成する。このような構成によれば、例えばＷｅｂサイトＡにおいて予約が変更された場合に、当該予約の変更が反映された店舗管理画面を店舗端末３０に表示することが可能となる。

更に、本実施形態においては、上記したようにＷｅｂサイトＡにおいて予約が変更された場合に、ＷｅｂサイトＢにログインし、当該ＷｅｂサイトＢの空席情報を更新する。これにより、ＷｅｂサイトＡにおいて変更された予約の内容に応じてＷｅｂサイトＢの空席情報を自動的に更新することが可能となる。

また、本実施形態においては、ＷｅｂサイトＡにおいて対象店舗への予約がキャンセルされた場合にＷｅｂサーバ装置２０ａから送信されるメールを受信し、当該受信されたメールに基づいてＷｅｂサイトＡにおいてキャンセルされた予約を示す予約キャンセル情報を取得し、当該取得された予約キャンセル情報を反映した店舗管理画面を生成する。このような構成によれば、例えばＷｅｂサイトＡにおいて予約がキャンセルされた場合に、当該予約のキャンセルが反映された店舗管理画面を店舗端末３０に表示することが可能となる。

更に、本実施形態においては、上記したようにＷｅｂサイトＡにおいて予約がキャンセルされた場合に、ＷｅｂサイトＢにログインし、当該ＷｅｂサイトＢの空席情報を更新する。これにより、ＷｅｂサイトＡにおける予約のキャンセルに応じてＷｅｂサイトＢの空席情報を自動的に更新することが可能となる。

また、本実施形態においては、店舗端末３０を利用する利用者（例えば、店舗の従業員等）の当該店舗端末３０に対する操作に応じて、対象店舗への予約を示す予約情報（第２の予約情報）を取得し、当該予約情報に基づいてＷｅｂサイトＡ及びＢの空席情報（第１及び第２の空席情報）をそれぞれ更新する。このような構成によれば、例えば対象店舗において電話等により新規予約を受け付けた場合であっても、当該新規予約と重複する予約がＷｅｂサイトＡ及びＢで受け付けられることを回避することが可能となる。

なお、本実施形態においては、説明の便宜上、Ｗｅｂサーバ装置（Ｗｅｂサイト）が２つである場合について説明したが、当該Ｗｅｂサーバ装置（Ｗｅｂサイト）は３以上であっても構わない。

また、本実施形態においては、説明の便宜上、１つの店舗端末３０についてのみ説明したが、予約管理装置１０が複数の店舗端末と通信可能に接続される場合には、上記した店舗端末３０と同様の処理が各店舗端末に対して実行されればよい。

なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。

１０…予約管理装置、１０ａ…コンピュータ、１０ｂ…記憶装置、１１…格納部、１２…ログイン処理部、１３…店舗管理画面生成部、１４…表示処理部、１５…メール解析部、２０ａ，２０ｂ…Ｗｅｂサーバ装置、３０…店舗端末。

Claims (13)

1. 店舗への予約を受け付けるための異なる第１及び第２のＷｅｂサイトの各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置において、
   前記第１のＷｅｂサイトにおいて設定されている第１のサイト受付時間を取得する第１の取得手段と、
   前記取得された第１のサイト受付時間と前記予約管理装置において設定されているＷｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第１のサーバ装置内で管理されている、前記第１のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新する第１の更新手段と、
   前記第２のＷｅｂサイトにおいて設定されている第２のサイト受付時間を取得する第２の取得手段と、
   前記取得された第２のサイト受付時間と前記Ｗｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第２のサーバ装置内で管理されている、前記第２のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新する第２の更新手段と、
   前記第１及び第２のサーバ装置にアクセスし、前記第１及び第２のサーバ装置内で管理されている空席情報に基づいて前記第１及び第２のＷｅｂサイトの各々で受け付けられた予約を示す第１の予約情報を収集する収集手段と、
   前記収集された第１の予約情報を含む店舗管理画面を生成する生成手段と、
   前記生成された店舗管理画面を前記店舗端末に表示する表示処理手段と
   を具備する予約管理装置。
2. 前記第１及び第２のＷｅｂサイトの各々にログインするための第１及び第２のログイン情報を格納する格納手段を更に具備し、
   前記収集手段は、前記店舗管理画面を生成する場合に、前記格納手段に格納されている第１及び第２のログイン情報の各々を順次使用して前記第１及び第２のＷｅｂサイトの各々にログインすることによって前記第１の予約情報を収集する
   請求項１記載の予約管理装置。
3. 前記第２のＷｅｂサイトにおいて前記店舗への予約が受け付けられた場合に前記第１のサーバ装置から送信されるメールを受信する受信手段と、
   前記受信されたメールに基づいて、前記第１のサーバ装置によって管理されている第１のＷｅｂサイトにログインし、当該第１のＷｅｂサイトにおいて受け付けられた予約を示す第２の予約情報を取得する第３の取得手段と
   を更に具備し、
   前記生成手段は、前記取得された第２の予約情報を反映した店舗管理画面を生成する
   請求項２記載の予約管理装置。
4. 前記取得された第２の予約情報に基づいて、前記第２のサーバ装置によって管理されている第２のＷｅｂサイトにログインし、前記第２のサーバ装置内で管理されている空席情報を更新する第３の更新手段を更に具備する請求項３記載の予約管理装置。
5. 前記第１のＷｅｂサイトにおいて前記店舗への予約の内容が変更された場合に前記第１のサーバ装置から送信されるメールを受信する受信手段と、
   前記受信されたメールに基づいて、前記第１のサーバ装置によって管理されている第１のＷｅｂサイトにログインし、当該第１のＷｅｂサイトにおいて変更された予約の内容を示す予約変更情報を取得する第３の取得手段と
   を更に具備し、
   前記生成手段は、前記取得された予約変更情報を反映した店舗管理画面を生成する
   請求項２記載の予約管理装置。
6. 前記取得された予約変更情報に基づいて、前記第２のサーバ装置によって管理されている第２のＷｅｂサイトにログインし、前記第２のサーバ装置内で管理されている空席情報を更新する第３の更新手段を更に具備する請求項５記載の予約管理装置。
7. 前記第１のＷｅｂサイトにおいて受け付けられた前記店舗への予約がキャンセルされた場合に前記第１のサーバ装置から送信されるメールを受信する受信手段と、
   前記受信されたメールに基づいて、前記第１のサーバ装置によって管理されている第１のＷｅｂサイトにログインし、当該第１のＷｅｂサイトにおいてキャンセルされた予約を示す予約キャンセル情報を取得する第３の取得手段と
   を更に具備し、
   前記生成手段は、前記取得された予約キャンセル情報を反映した店舗管理画面を生成する
   請求項２記載の予約管理装置。
8. 前記取得された予約キャンセル情報に基づいて、前記第２のサーバ装置によって管理されている第２のＷｅｂサイトにログインし、前記第２のサーバ装置内で管理されている空席情報を更新する第３の更新手段を更に具備する請求項７記載の予約管理装置。
9. 前記店舗端末を利用する利用者の当該店舗端末に対する操作に応じて、前記店舗への予約を示す第２の予約情報を取得する第３の取得手段と、
   前記第２の予約情報が取得された場合、前記第１のサーバ装置によって管理されている第１のＷｅｂサイトにログインし、前記第１のサーバ装置内で管理されている空席情報を更新する第３の更新手段と、
   前記第２の予約情報が取得された場合、前記第２のサーバ装置によって管理されている第２のＷｅｂサイトにログインし、前記第２のサーバ装置内で管理されている空席情報を更新する第４の更新手段と
   を更に具備する請求項２記載の予約管理装置。
10. 店舗への予約を受け付けるための異なる第１及び第２のＷｅｂサイトの各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置において、
    前記第１のＷｅｂサイトにおいて前記店舗への予約が受け付けられた場合に前記第１のサーバ装置から送信される第１のメールを受信する第１の受信手段と、
    前記受信された第１のメールの解析結果から前記第１のＷｅｂサイトで受け付けられた予約を示す第１の予約情報を収集する第１の収集手段と、
    前記第２のＷｅｂサイトにおいて前記店舗への予約が受け付けられた場合に前記第２のサーバ装置から送信される第２のメールを受信する第２の受信手段と、
    前記受信された第２のメールの解析結果から前記第２のＷｅｂサイトで受け付けられた予約を示す第２の予約情報を収集する第２の収集手段と、
    前記収集された第１及び第２の予約情報を含む店舗管理画面を生成する生成手段と、
    前記生成された店舗管理画面を前記店舗端末に表示する表示処理手段と
    を具備する予約管理装置。
11. 店舗への予約を受け付けるための異なる第１及び第２のＷｅｂサイトの各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置において、
    前記第１及び第２のＷｅｂサイトの各々にログインするための第１及び第２のログイン情報を格納する格納手段と、
    前記格納手段に格納されている第１及び第２のログイン情報の各々を順次使用して前記第１及び第２のＷｅｂサイトの各々にログインすることによって、当該第１及び第２のＷｅｂサイトの各々で受け付けられた予約を示す第１の予約情報を収集する収集手段と、
    前記収集された第１の予約情報を含む店舗管理画面を生成する生成手段と、
    前記生成された店舗管理画面を前記店舗端末に表示する表示処理手段と、
    前記第１のＷｅｂサイトにおいて前記店舗への予約が受け付けられた場合に前記第１のサーバ装置から送信されるメールを受信する受信手段と、
    前記受信されたメールに基づいて、前記第１のサーバ装置によって管理されている第１のＷｅｂサイトにログインし、当該第１のＷｅｂサイトにおいて受け付けられた予約を示す第２の予約情報を取得する取得手段と、
    前記取得された第２の予約情報に基づいて、前記第２のＷｅｂサイトにログインし、前記第２のサーバ装置内で管理されている当該第２のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新する更新手段と
    を具備し、
    前記生成手段は、前記第２の予約情報が取得された場合、当該第２の予約情報を反映した店舗管理画面を生成し、
    前記更新手段は、前記第２の予約情報によって示される予約が受け付けられた席が前記第２のＷｅｂサイトにおいて管理されている場合に前記空席情報を更新する
    予約管理装置。
12. 店舗への予約を受け付けるための異なる第１及び第２のＷｅｂサイトの各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置が実行する予約管理方法であって、
    前記第１のＷｅｂサイトにおいて設定されている第１のサイト受付時間を取得するステップと、
    前記取得された第１のサイト受付時間と前記予約管理装置において設定されているＷｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第１のサーバ装置内で管理されている、前記第１のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新するステップと、
    前記第２のＷｅｂサイトにおいて設定されている第２のサイト受付時間を取得するステップと、
    前記取得された第２のサイト受付時間と前記Ｗｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第２のサーバ装置内で管理されている、前記第２のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新するステップと、
    前記第１及び第２のサーバ装置にアクセスし、前記第１及び第２のサーバ装置内で管理されている空席情報に基づいて前記第１及び第２のＷｅｂサイトの各々で受け付けられた予約を示す予約情報を収集するステップと、
    前記収集された予約情報を含む店舗管理画面を生成するステップと、
    前記生成された店舗管理画面を前記店舗端末に表示するステップと
    を具備する予約管理方法。
13. 店舗への予約を受け付けるための異なる第１及び第２のＷｅｂサイトの各々を管理する第１及び第２のサーバ装置と当該店舗に設けられる店舗端末と通信可能に接続される予約管理装置のコンピュータによって実行されるプログラムであって、
    前記コンピュータに、
    前記第１のＷｅｂサイトにおいて設定されている第１のサイト受付時間を取得するステップと、
    前記取得された第１のサイト受付時間と前記予約管理装置において設定されているＷｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第１のサーバ装置内で管理されている、前記第１のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新するステップと、
    前記第２のＷｅｂサイトにおいて設定されている第２のサイト受付時間を取得するステップと、
    前記取得された第２のサイト受付時間と前記Ｗｅｂ受付時間とが一致していない場合、当該一致していない時間帯においては予約を受け付けないように、前記第２のサーバ装置内で管理されている、前記第２のＷｅｂサイトにおいて予約可能としている空席を示す空席情報を更新するステップと、
    前記第１及び第２のサーバ装置にアクセスし、前記第１及び第２のサーバ装置内で管理されている空席情報に基づいて前記第１及び第２のＷｅｂサイトの各々で受け付けられた予約を示す予約情報を収集するステップと、
    前記収集された予約情報を含む店舗管理画面を生成するステップと、
    前記生成された店舗管理画面を前記店舗端末に表示するステップと
    を実行させるためのプログラム。

Images