(57)【要約】【課題】サービスを提供する店舗が、みずからの店舗の利用者層に合致する顧客だけをねらってサービス申込みの誘引をし、予約のキャンセル率を低減させ、閑散時間帯の稼働率を向上させ、さらに顧客のニーズを的確に把握できる、飲食店予約システムを提供する。【解決手段】サービスの予約枠を、あらかじめ在庫として登録し、かつ自動更新する、予約在庫管理手段と、登録利用者のプロフィール情報等を記録したデータベースと、当該プロフィール情報を飲食サービス情報とつきあわせて、店舗の客層に合致する登録利用者だけに申込みの誘引をする手段と、登録利用者が申込みのキャンセル等のできる期間を制限する手段と、飲食サービスを受けた登録利用者からアンケートを回収する手段と、実際に飲食サービスを受けた利用者の数にもとづいて、システムの利用料を課金する手段とを備えた飲食店予約システム。【選択図】図１
2012042996.tif 000002
【特許請求の範囲】
【請求項１】
飲食店が提供するサービス情報と、当該サービスを受けようとする利用者のプロフィール等を含む登録情報とを記憶するデータベースを有し、または利用するサーバコンピュータが、
当該サービスの予約枠の集まりからなる予約在庫を、あらかじめ予約の誘引をする前に登録し、かつ自動更新する、予約在庫管理手段と、
前記データベースに記憶されたサービス情報および登録情報を照合し、当該飲食店の客層に合致する利用者を選択して予約の誘引をする、メッセージ送受信手段と、
前記データベースに当該利用者の予約情報を記録し、当該予約の人数変更またはキャンセル等の更新を受理する期間に制約を設ける、予約情報管理手段と、
前記更新後の利用者数にもとづいて、システムの利用料を飲食店に課金する、利用料課金手段とを有することを特徴とする、飲食店予約システム。
【請求項２】
前記サービス情報において、前記予約の誘引後に、サービスの提供をうける人数を増減させる手段を有する、請求項１に記載の飲食店予約システム。
【請求項３】
前記予約情報管理手段において、前記利用者にアンケートを送信し、回答メッセージを受信すると、当該利用者へ優待ポイントを発行する手段を有する、請求項１または２に記載の飲食店予約システム。
【請求項４】
飲食店が提供するサービス情報と、当該サービスを受けようとする利用者のプロフィール等を含む登録情報とを記憶するデータベースを有し、または利用するコンピュータにおいて、
当該サービスの予約枠の集まりからなる予約在庫を、あらかじめ予約の誘引をする前に登録し、かつ自動更新する、予約在庫管理ステップと、
前記データベースに記憶されたサービス情報および登録情報を照合し、当該飲食店の客層に合致する利用者を選択して予約の誘引をする、メッセージ送受信ステップと、
前記データベースに当該利用者の予約情報を記録し、当該予約の人数変更またはキャンセル等の更新を受理する期間に制約を設ける、予約情報管理ステップと、
前記更新後の利用者数にもとづいて、システムの利用料を飲食店に課金する、利用料課金ステップとを実行する、飲食店予約プログラム。
【請求項５】
前記サービス情報において、前記予約の誘引後に、サービスの提供をうける人数を増減させるステップを実行できる、請求項４に記載の飲食店予約プログラム。
【請求項６】
前記予約情報管理ステップにおいて、前記利用者にアンケートを送信し、回答メッセージを受信すると、当該利用者へ優待ポイントを発行するステップを実行することを特徴とする、請求項４または５に記載の飲食店予約プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、飲食サービスを提供する店舗のための、予約管理システムであって、とくに新規顧客を開拓するための、予約の誘引を可能とする機能を備えたことを特長とする。
【背景技術】
【０００２】
従来から、飲食店にかぎらず、予約処理をシステム化した発明は、いくつか存在する。それらの特徴は区々であるが、サービスの供用スケジュールを最適化する機能は、おおむね、どのシステムでも共通に備えている。
【０００３】
たとえば特許文献１に記載されたシステムは、宿泊施設のように、同種類の多数の予約対象物をあつかう場合、予約の受理と同時に特定の予約対象物を割り当てるのでなく、単位時間ブロックごとの予約受理件数が、受容可能な上限数未満であるかぎり、予約を受理して、予約対象物の稼働率を向上させる。
【０００４】
また、特許文献２に記載されたシステムでは、飲食店やカラオケ施設のように、空き状況をリアルタイムで提供することを求められる場合、サービス提供者は、施設の空き情報を随時に更新してデータベースへ記録し、サービス利用者は、このデータベースを随時に参照して的確な予約行動をとることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２７９８０２号公報
【特許文献２】特開２００９−６４１４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記の先行技術はすべて、サービスのアベイラビリティ向上を通じて、効率的に顧客を獲得し、さらにリピーター確保を目的にしているといってよいが、サービスへの予約を誘引するには、必ずしも、これだけで充分とはいえない。
【０００７】
多数の顧客を誘引するには、ディスカウントが、もっとも直接的な手段である。しかしながら、場合によっては、相当程度の損失をこうむることを覚悟しなくてはならない。そのうえ、来客がリピーターとなってくれるとはかぎらず、ビジネスチャンスの拡大が、あまり期待できない。また、顧客のニーズを分析できないという欠点がある。
【０００８】
本発明は、こうした実情にかんがみてなされたものであり、上記の欠点を克服した、効果的な予約の誘引ができ、かつサービスのアベイラビリティが向上するシステムを提供しようとするものである。
【課題を解決するための手段】
【０００９】
上記の課題を解決するための本願発明は、サーバ、システム端末 (パーソナルコンピュータ、携帯専用端末、携帯電話機のいずれか)、および利用者端末から構成され、飲食店サービスを提供する側 (以下、「飲食サービス提供者」という) と、飲食店サービスを利用する側 (以下、「飲食サービス利用者」という) とを仲介する、情報交換システムを提供する。システム端末は、飲食サービス提供者が、常備する装置であって、もっぱら飲食サービス提供者とサーバとの間の情報交換をおこなう。利用者端末は、飲食サービス利用者が保有する、携帯電話機、パーソナルコンピュータなどの無線または有線の通信装置であって、インターネット機能を装備していなくてはならない。
【００１０】
サーバは、ソフトウェアモジュール群、およびデータベースから構成される。ソフトウェアモジュール群は、本願発明にかかるサーバの動作を定義する。データベースは、飲食サービス提供者から収集した飲食サービス情報や、飲食サービス利用者から得られたプロフィール情報、および予約情報を蓄積する。
【００１１】
ソフトウェアモジュール群は、会員情報処理部、飲食サービス情報処理部、予約カレンダー処理部、飲食サービス変更処理部 (予約在庫設定ルーチン、飲食サービス内容変更ルーチン、予約人数変更ルーチン)、および利用料金算定処理部から構成され、サーバ内におけるデータ処理、ならびに上記のシステム端末および利用者端末とのデータ送受信をつかさどる。
【００１２】
会員情報処理部は、本願発明にかかる飲食店予約システムを利用して、飲食サービス告知情報を得ようとする飲食サービス利用者の、利用者端末から会員登録の申込みを受理して、会員情報をデータベースに蓄積する。会員情報には、当該飲食サービス利用者のプロフィール情報、すなわち、ライフサイクル、行動エリア、好みの料理や食材、外食予算などのデータが含まれる。
【００１３】
また、会員情報処理部は、飲食サービス提供者による飲食サービスの提供を実際に受けた会員に対し、利用者端末へ、アンケートを送信する。当該アンケートへの回答が得られたとき、その回答をした会員へ、優待ポイントの発行をおこなう。このため、会員は、アンケートへの積極的な回答を動機づけられるため、飲食サービス提供者は、みずから提供するサービスへの、フィードバックを効果的に収集できる。優待ポイントは、ポイント数を金銭に換算することができ、アンケートへの回答ごとに、所定のポイント数が会員へ与えられるものとする。優待ポイント数は、会員情報の一部として、データベースに記録される。
【００１４】
飲食サービス情報処理部は、飲食サービス提供者からの、飲食サービス告知情報をデータベースに蓄積し、飲食サービス利用者の利用者端末へ、週ごとにオンデマンド形式で配信する。ただし、配信先は、飲食サービス告知情報と、上記のプロフィール情報とがマッチする会員だけである。このため、飲食サービス提供者は、みずからの店舗の客層に合致し、かつ指定する時間帯に来店が可能な会員だけに、ピンポイント形式で情報発信できるので、予約の得られる蓋然性は高く、閑散時間帯の空席を埋めることができ、さらにリピーター獲得も期待できる。
【００１５】
予約カレンダー処理部は、飲食サービス告知情報にもとづいて予約枠を生成する。予約枠は、飲食サービスを提供する店舗における、サービスの日時、サービスの内容、ならびに受け入れ可能な組数および人数などから構成されるデータである。予約枠の生成は、週単位でおこなわれるが、最初の週から起算して４週先の分までが、あらかじめ自動的に複製される。この４週分の予約枠の集まりを、予約在庫といい、４週間の期間を、在庫ウィンドウという。在庫ウィンドウは、週単位で未来方向へシフトし、在庫ウィンドウにおける予約在庫の内容は、週単位のラウンドロビン形式で自動的に更新される。たとえば、２０１０年９月の第１週に予約枠を生成した場合、第１週の予約枠は、第２週ないし第４週にも適用される。第１週が経過して在庫ウィンドウのシフトが生じ、在庫ウィンドウが第２週ないし第５週となった場合、第１週の予約枠が、第５週の予約枠として複製される。第２週が経過して在庫ウィンドウのシフトが生じ、在庫ウィンドウが第３週ないし１０月第１週となった場合、第２週の予約枠が、１０月第１週の予約枠として複製される。したがって、飲食サービス提供者は、いちど予約枠の基礎データを入力すれば、これを再入力する手間から解放される。一方、飲食サービス情報処理部は、予約在庫に含まれる、前半２週分の予約枠を、飲食サービス告知情報とともに飲食サービス利用者へ配信する。飲食サービス利用者は、この前半２週分の予約枠にもとづいて予約をする。後半２週分の予約枠は、飲食サービス提供者による保守のために、リザーブされる。予約カレンダー処理部は、飲食サービス利用者の利用者端末から、予約枠にもとづく予約を受理し、時系列にまとめて予約カレンダーを生成し、データベースに記録する。予約カレンダー処理部は、利用者端末からの予約変更も受けつける。なお、在庫ウィンドウは、４週間でなくてはならないわけではなく、飲食店予約システムの運用条件に応じて、短縮または伸張してよい。
【００１６】
また、予約カレンダー処理部は、飲食サービス提供者が提供する、飲食サービスのそれぞれについて、予約カレンダーをシステム端末に表示する。飲食サービス提供者は、予約カレンダーに示された予約状況にもとづいて、仕入れや作業の段取りを的確におこなえる。
【００１７】
飲食サービス変更処理部は、予約の誘引メッセージの配信後に、予約枠、すなわち飲食サービス提供者が提供する、飲食サービスの受け入れ枠を拡大または縮小する手段を提供する (予約在庫設定ルーチン)。これは、曜日や時間帯に応じて、臨機応変な集客を可能にするためである。
【００１８】
また、飲食サービス変更処理部は、データベースに蓄積された飲食サービス告知情報の変更手段を提供する (飲食サービス内容変更ルーチン)。サービスの日程、受け入れ可能な人数、メニューとその価格、休業日などを再設定することができ、サービスの開始や停止も制御できる。価格は、日程、受け入れ可能な人数、およびメニューに必要な食材などに応じて、最適な値に設定できる。
【００１９】
さらに、飲食サービス変更処理部は、利用者からの、予約のキャンセルまたは予約人数変更を受理する。ただし、利用者は、キャンセル不能期間に、利用者端末からキャンセル等をすることができない。これは、飲食サービス提供者が、不測の損害をこうむらないようにするためである。キャンセル不能期間のデフォルト設定は、飲食サービスの提供前日以降とする。飲食サービス提供者は、キャンセル不能期間を短縮し、飲食サービスの提供当日以降とすることも可能であるから、キャンセル不能期間は、０日ないし２日のあいだで設定できる。飲食サービス変更処理部は、キャンセル不能期間の到来まで、利用者端末からキャンセル等のデータを受理し、データベースに、キャンセルフラグを設定する。キャンセル不能期間における、キャンセル等のデータは、利用者端末から受理しない (予約人数変更ルーチン)。ただし、キャンセル等の意思表示をする事前連絡が、飲食サービス利用者からあった場合、飲食サービス提供者は、飲食サービス提供の当日にかぎり、システム端末から、データベースに、キャンセルフラグの設定をすることができる。事前連絡をした飲食サービス利用者は、当該キャンセルフラグの設定をうけることにより、キャンセル不能期間であっても、予約のキャンセル等をすることができる。なお、飲食店予約システムの管理者は、キャンセルフラグの設定の有無にかかわらず、キャンセル等の操作をおこなえる。
【００２０】
利用料金算定処理部は、飲食サービス利用者の人数に、所定の飲食店予約システム利用料金を乗じて得た金額を、飲食サービス提供者へ課金する。予約の誘引は、当該店舗の客層と合致する者だけになされており、しかも上記のとおりキャンセル等に制約が設けられているため、予約をした飲食サービス利用者が実際に店舗を訪れる蓋然性は、きわめて高くなる。よって、飲食サービス提供者は、その収益に見合った、飲食店予約システム利用料を納めればすむので、過大な費用を負担することがない。このため、飲食サービス提供者を、広く募ることが可能となる。なお、課金のしかたは任意でかまわない。飲食店予約システムで出力した帳票を郵送してもよいし、課金情報を記した電子メールを飲食店予約システムが自動配信してもよい。飲食サービス提供者がアカウントコードをブラウザから入力すると、飲食店予約システムが課金情報を表示出力するようにしてもよい。
【発明の効果】
【００２１】
本発明は、飲食サービス提供者が、魅力的な飲食サービスを、インターネット経由でサーバから顧客へ提供できるシステムを提供する。飲食サービス利用者は、このシステムを提供するサイトに登録するだけで、種々の飲食サービス情報をサーバから配信してもらうことができる。
【００２２】
予約の誘引をするために、サーバは、登録時に飲食サービス利用者が入力したプロフィールを、飲食サービス提供者が提供する飲食サービスの内容と照合し、飲食サービス提供者の客層に合致する者だけを選択して、飲食サービス情報を配信する。よって、飲食サービス情報を配信された飲食サービス利用者が実際に店舗を訪れる蓋然性が高まり、しかも新規顧客の獲得が期待できる。
【００２３】
サーバは、予約を誘引しやすいような飲食サービスだけを登録する。たとえば、通常ならば、きわめて高価格な飲食サービスを５割ないし８割引で提供するものなどである。飲食サービス提供の時間帯は、限定しなくてはならないが、飲食サービス提供者が自由に設定してよい。したがって、飲食サービス提供者は、店舗の閑散時間帯などを利用して、新規顧客の獲得キャンペーンをすることが可能となる。
【００２４】
上記のように、飲食サービス利用者が、実際に店舗を訪れる蓋然性は高い。また、飲食サービス利用者は、飲食サービス提供者が設定するキャンセル不能期間に、キャンセル等をすることができない。したがって、飲食サービス提供者は、不測の損害をまぬがれ、たとえ大幅なディスカウントをしていても、確実にコストを回収できる。また、飲食サービス提供者は、実際に店舗を訪れた飲食サービス利用者の数にもとづいて、システム利用料を課金されるので、新規顧客獲得のための費用を、必要最小限に抑制できる。
【図面の簡単な説明】
【００２５】
【図１】本発明の、一実施形態にかかる、飲食店予約システムの構成図である。
【図２】システム端末に表示される、画面の遷移図である。
【図３】飲食店予約システムの動作を示す、全体的な流れ図である。
【図４】飲食サービス告知情報の保守動作を示す、流れ図である。
【図５】飲食サービスの予約人数の変更へ対応する動作を示す、流れ図である。
【発明を実施するための形態】
【００２６】
以下、添付図面を参照しながら、本発明の飲食店予約システムを実施するための最良の形態を詳細に説明する。図１〜図５は、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表わし、基本的な構成及び動作は同様であるものとする。
【００２７】
＜構成＞
本実施形態の飲食店予約システムは、サーバ１０ (図１)、飲食サービス提供者のシステム端末１１ (同図)、および飲食サービス利用者の利用者端末１２ (同図) から構成される。サーバ１０とシステム端末１１との間、及びサーバ１０と利用者端末１２との間は、無線または有線による通信によって情報交換をする。
【００２８】
サーバ１０は、ソフトウェアモジュール群 (１０２ないし１０６)、およびデータベース１０１から構成される。ソフトウェアモジュール群は、会員情報処理部１０２、飲食サービス情報処理部１０３、予約カレンダー処理部１０４、飲食サービス変更処理部１０５ (予約在庫設定ルーチン、飲食サービス内容変更ルーチン、予約人数変更ルーチンを含む)、および利用料金算定処理部１０６から構成される。データベース１０１は、会員情報、ならびに飲食サービス提供者の飲食サービス告知情報および予約枠を蓄積する。飲食サービス告知情報は、飲食サービス提供者が飲食サービス利用者へ提供する、飲食サービスの内容を詳しく説明するものであり、予約枠は、いつ、どこで、だれが、どんな飲食サービスを提供するのか、さらに、その飲食サービスに受入れが可能な人数は何人までかを指定するものであって、これらは、飲食サービス提供者からの情報にもとづき、サーバ１０がデータベースへ登録する。登録された飲食サービス告知情報および予約枠は、システム端末１１を用いて、飲食サービス提供者が変更することもできる。サーバ１０は、飲食サービス告知情報および予約枠を、利用者端末１２へ、オンデマンドで配信する。
【００２９】
システム端末１１は、各飲食サービス提供者に配備されるもので、表示部１１１、操作部１１２、通信機能部１１３から構成される。その他の構成は、任意でよい。ただし、システム端末１１を携帯専用端末とするのであれば、入力操作をマルチタッチスクリーン方式でおこなえる、いわゆるスマートフォンであることが望ましい。
【００３０】
利用者端末１２は、飲食サービス利用者が保有する、携帯電話などの携帯用無線通信端末、またはパーソナルコンピュータなどの有線通信端末であって、表示部１２１、操作部１２２、通信機能部１２３から構成される。インターネット通信機能をもつかぎり、任意の機器でさしつかえない。利用者端末１２には、飲食サービス提供者が、あらかじめサーバ１０へ登録した、飲食サービス情報が表示される。飲食サービス利用者は、この飲食サービス告知情報から、好みのサービスを選択し、予約操作をおこなう。入力された予約情報は、サーバ１０へ送信され、蓄積されて、各飲食サービス提供者は、システム端末１１を使用して、予約状況や顧客情報を確認できる。
【００３１】
会員情報処理部１０２は、飲食サービス利用者の利用者端末１２から会員登録の申込みを受理して、会員情報をデータベース１０１に蓄積する。会員情報には、当該飲食サービス利用者のプロフィール情報、すなわち、ライフサイクル、行動エリア、好みの料理や食材、外食予算などが含まれる。また、会員情報処理部１０２は、飲食サービスを利用した飲食サービス利用者の利用者端末１２へ、アンケートを含むメッセージを送信する。アンケートでは、当該店舗のリピーターになりたいかどうかを、必ず答えてもらうものとする。アンケートに回答が得られた場合、その回答をした飲食サービス利用者へは、優待ポイントを発行する。飲食サービス利用者へ与えられた優待ポイントの数は、会員情報の一部としてデータベースに記録される。一方、飲食店予約システムの利用規約に反して、キャンセル不能期間にキャンセル等を通知したり、当日に来店しない飲食サービス利用者に対しては、優待ポイントの抹消などの、ペナルティを課すことができる。飲食サービス提供者は、利用規約にもとづき、キャンセル料の支払いを求める。
【００３２】
飲食サービス情報処理部１０３は、飲食サービス提供者からのデータにもとづいて、飲食サービス利用者へ提供される飲食サービス告知情報を、サーバ１０に蓄積する。飲食サービス告知情報は、飲食サービス提供者が提供する、飲食サービスの広告であって、サービス提供の日時を限定するかわりに、大幅なディスカウントを提示する。休業日はいつかなどの情報も、飲食サービス告知情報に含まれる。予約カレンダー処理部１０４は、飲食サービス提供者からのデータにもとづいて、予約枠を生成し、サーバ１０に蓄積する。予約枠は、メニューおよびその価格、何日の何時から何時までに何人を何組まで受け入れるかなどの情報を含む。飲食サービス情報処理部１０３は、サーバ１０が蓄積した飲食サービス告知情報および予約枠を、利用者端末１２へ、オンデマンド形式で配信する。
【００３３】
予約カレンダー処理部１０４は、飲食サービス利用者の利用者端末１２から、予約枠にもとづく予約を受けつけ、さらに利用者端末１２の求めに応じ、予約の変更を受けつける。さらに、予約カレンダー処理部１０４は、受理した予約を飲食サービス提供者ごとの時系列にまとめ、予約カレンダーを生成して、データベース１０１に記録する。さらに、この予約カレンダーにもとづいて、当日および翌日以降の予約状況を、飲食サービス提供者の提供するサービスごとに、システム端末１１へ表示する。飲食サービス提供者は、この予約状況を参照しながら、当該飲食サービスのための仕入れや、作業の段取りを的確におこなえる。
【００３４】
飲食サービス変更処理部１０５ (予約在庫設定ルーチン) は、提供を開始している飲食サービスの日付けおよび時間ごとに、受け入れが可能な組数および人数の上積みおよび削減を可能とする。
【００３５】
飲食サービス変更処理部１０５ (飲食サービス内容変更ルーチン) は、飲食サービス提供者が提供しようとするサービスの内容を再定義する。サービスの日程、受け入れ可能な人数、メニューとその価格、休業日などを定め、サービスの開始や停止も制御する。
【００３６】
飲食サービス変更処理部１０５ (予約人数変更ルーチン) は、サービス提供前に予約人数の変更があった場合の処理をおこなう。この飲食店予約システムでは、キャンセル不能期間における利用者端末１２からのキャンセルや予約人数変更を認めない。しかし、飲食サービス提供者のシステム端末１１は、飲食サービス提供の当日に、サーバ１０へ、キャンセルフラグの設定を指示できる。このキャンセルフラグが設定された予約は、利用者端末１２から、キャンセル等をしたのと同様にあつかわれる。ただし、キャンセル不能期間にキャンセルフラグが設定されると、飲食サービス利用者にペナルティが課される。このため、飲食サービス利用者は、キャンセル不能期間前にキャンセル等を事前連絡するように動機づけられるので、飲食サービス提供者は、安心してサービス提供の準備ができる。
【００３７】
利用料金算定処理部１０６は、飲食サービス提供者が提供する飲食サービスを現実に受けた、飲食サービス利用者の人数を確定する。上記のとおり、飲食サービス利用者は、キャンセル等に制約が課されるので、飲食サービス提供当日の予約人数が、実際に来店する蓋然性はきわめて高い。また予約人数に変動があっても、事前連絡が担保されるため、飲食サービス提供者の損害を極小化することができる。こうして確定した、飲食サービス利用者の人数に、所定の飲食店予約システム利用料金を乗じて得た金額を、飲食店予約システムを利用する飲食サービス提供者へ課金する。
【００３８】
つぎに、飲食店予約システムの動作をステップごとに示す：
＜動作Ｓ１０＞：飲食店予約システムの全体的な動作
Ｓ１０１：＜会員登録情報の収集＞
利用者端末１２から、会員登録の申込みを受信すると、サーバ１０は、会員情報処理部１０２を呼び出して、申込みをした利用者の情報を、データベースに記録する。
【００３９】
Ｓ１０２：＜飲食サービス告知情報の蓄積と配信＞
サーバ１０は、飲食サービス提供者からの申込みにもとづき、飲食サービス告知情報および予約枠を蓄積する。蓄積したこれらの情報は、飲食サービス情報処理部１０３を呼び出して、利用者端末１２へ、オンデマンドで配信する。配信先は、会員情報処理部１０２が、飲食サービス利用者のプロフィール情報と、飲食サービス告知情報とを照合して決定する。たとえば、飲食サービス利用者のプロフィール情報に、和食を好む５０代の女性と記録されていれば、おもに和食のサービス告知情報が配信され、若年層をターゲットとするエスニック料理のサービス告知情報が配信されることはない。また、東京都港区の青山周辺を主たる行動エリアとする利用者に対し、東京都武蔵野市の吉祥寺周辺で提供されるサービスの告知情報が配信されることもない。さらに、飲食サービス利用者のプロフィール情報に、平日の午後２時から午後４時に来店が不可能と記録している一般的なサラリーマンなどへ、この時間帯のサービス告知情報が配信されることはない。
【００４０】
Ｓ１０３：＜飲食サービスの申込みの受理＞
利用者端末１２は、サーバ１０から飲食サービス告知情報および予約枠を取得して、飲食サービスの選択をし、予約枠に示された枠内の人数を指定して、予約情報を入力し、サーバ１０へ送信する。予約カレンダー処理部１０４は、送信された予約情報を、データベース１０１に記録する。
【００４１】
Ｓ１０４：＜飲食サービス申込みデータの更新の受理＞
利用者端末１２は、必要に応じて、変更した予約情報を、サーバ１０へ送信する。ただし、利用者端末１２は、キャンセル不能期間には予約人数の変更ができない。飲食サービス提供の当日に、予約人数を変更できるのは、飲食サービス提供者だけであって、動作Ｓ３０にもとづき、システム端末１１を用いておこなう。
【００４２】
Ｓ１０５：＜飲食サービス告知情報や申し込みデータの保守＞
システム端末１１は、動作Ｓ２０にもとづき、飲食サービス告知情報への応答によって発生した予約情報から、予約した飲食サービス利用者の人数を確認し、必要があれば、あわせて飲食サービス告知情報および予約枠の内容へ変更を加える。飲食サービス利用者からの連絡による人数の変更やキャンセルがあれば、動作Ｓ３０にもとづいて処理をする。
【００４３】
Ｓ１０６：＜アンケート処理＞
サーバ１０は、会員情報処理部１０２を呼び出して、飲食サービス利用者の利用者端末１２へ、アンケートを含むメッセージを送信する。アンケートに回答が得られると、その回答をした飲食サービス利用者へ、優待ポイントを発行する。発行された優待ポイントの数は、当該飲食サービス利用者の会員情報における、優待ポイント数属性へ加算される。
【００４４】
Ｓ１０７：＜飲食店予約システム利用料の課金＞
サーバ１０は、利用料金算定処理部１０６を呼び出して、利用者端末１２およびシステム端末１１からの情報にもとづき、実際に飲食サービスの提供を受けた飲食サービス利用者の、最終的な人数を割り出す。この最終的な人数に応じて、サーバ１０は、飲食サービス提供者へ、本願発明にかかる、飲食店予約システムの利用料を課金する。
【００４５】
＜動作Ｓ２０＞：システム端末からの、飲食サービス告知情報の保守動作
Ｓ２０１：＜当日予約の確認＞
システム端末１１が、サーバ１０との通信経路を確立すると、予約カレンダー処理部１０４が呼び出され、トップ画面２０ (図２) が、システム端末１１上に表示される。メニュー欄２０１は、トップ画面２０上から選択できる機能の一覧を表示する。当日予約欄２０２は、当日の予約状況を示す。行ごとに予約エントリ、すなわち来客の名前、人数、来店時刻が記され、割引など特典の対象となる予約には、その旨も示される。システム端末１１の利用者が、翌日以降の予約を確認するには、当日予約欄２０２に設けられた、予約カレンダーへのリンクを用いて、予約カレンダー画面３０ (図２) へ移行する。
【００４６】
Ｓ２０２：＜当日以降の予約確認＞
予約カレンダー画面３０は、システム端末１１上に表示され、当日以降の予約状況の一覧を表示する。メニュー欄３０１は、予約カレンダー画面３０上から選択できる機能の一覧を表示する。予約カレンダー欄３０２は、当日以降の各日付けにおける、予約状況の一覧表を提示する。各日付けにおける予約エントリが、行単位で簡潔に示される。予約カレンダー画面３０は、予約エントリをスクロール方式で表示できる。システム端末１１の利用者が、サービスの受け入れ枠を変更するには、予約カレンダー欄３０２上のリンクを用いて、予約在庫設定ルーチンを呼び出し、予約在庫設定画面４０ (図２) へ移行する。
【００４７】
Ｓ２０３：＜サービス受け入れ枠の変更＞
予約在庫設定画面４０は、システム端末１１上に表示され、予約在庫の保守をする。サービスを提供する日付けおよび時間ごとに、受け入れ可能な組数および人数を変更できる。日付けおよび時間ごとの予約状況欄４０１は、当日の来客の名前、人数、来店時刻を列挙する。日付けおよび時間ごとの、残り予約受入枠欄４０２は、予約の受入ができる人数に上積みまたは削減をしたい場合に使用する。システム端末１１の利用者が、開始時刻で識別されるサービスに対して、受入の上積みまたは削減をしたい人数を、セレクトボックスから選択し、変更ボタンを押すと、変更が受理され、サービス確認画面５０ (図２) へ移行する。
【００４８】
Ｓ２０４：＜サービス内容の確認＞
サービス確認画面５０は、システム端末１１上に表示され、サービスの内容を確認したり、サービスの内容へ変更を加える。トップ画面２０のメニュー欄２０１に設けられたリンクを用いても、サービス確認画面５０へと移行できる。メニュー欄５０１は、サービス確認画面５０上から選択できる機能の一覧を表示する。メッセージ５０２は、サービス提供の状況を記す。システム端末１１の利用者が、変更ボタン５０３を押すと、飲食サービス内容変更ルーチンが呼び出され、飲食サービス内容変更画面６０ (図２) へ移行する。
【００４９】
Ｓ２０５：＜サービス内容の変更＞
飲食サービス内容変更画面６０は、システム端末１１上に表示され、サービス内容へ加える変更を選択する。メニュー欄６０１は、飲食サービス内容変更画面６０から選択できる機能の一覧を表示する。システム端末１１の利用者は、基本設定ボタン６０２を押して、サービスの日程、受け入れ可能な組数および人数、ならびにサービスの開始や停止を変更する。また、システム端末１１の利用者は、サービス内容ボタン６０３を押して、提供メニューや価格などを変更する。すでに予約を受けつけた飲食サービスの内容を変更した場合、予約カレンダー画面３０の予約カレンダー欄３０２には、飲食サービス提供者の注意を喚起するマークが、予約エントリごとに付される。休日設定ボタン６０４を押せば、休日追加欄が表示され、すでに設定されている休業日、および新たに休業日として設定する日をセレクトボックス群によって選択できる。すでに予約を受けつけた日を、新たに休業日として設定しなおすことも可能であるが、その新たな休業日へ、予約を追加することはできない。
【００５０】
＜動作Ｓ３０＞：飲食サービスの予約人数変更へ対応する動作
Ｓ３０１：＜予約の選択＞
飲食サービス利用者が、飲食サービス提供の当日にキャンセルを申し出たり、または飲食サービス提供の当日に来店しないなど、当日の予約人数に変更が加わった場合、システム端末１１の利用者は、トップ画面２０の当日予約欄２０２から該当の予約を選択し、予約人数変更ルーチンを呼び出す。
【００５１】
Ｓ３０２：＜予約人数の変更＞
トランザクション表示画面７０ (図２) が表示される。予約人数の変更が可能な時間帯であれば、予約人数変更欄７０１がアクティブ状態で表示される。予約人数変更欄７０１では、変更後の予約人数を選択するための、セレクトボックスが提示される。また、飲食サービス利用者から飲食サービス提供者へ、キャンセル不能期間前に事前連絡があったか否かを選択し、キャンセルフラグを設定するための、セレクトボックスも提示される。システム端末１１の利用者は、これらのデータを入力する。
【００５２】
Ｓ３０３：＜申請＞
申請ボタン７０２が表示される。システム端末１１の利用者が、申請ボタン７０２を押すと、入力データは、サーバ１０へ送信される。サービス提供の予定時刻が経過するとともに、予約人数が確定する。キャンセルフラグの設定があり、かつ予約人数に減少がある場合、その減少は、確定値に反映される。この確定値は、実際に飲食サービスの提供を受けた飲食サービス利用者の数であるとみなされる。
【００５３】
以上、本発明の飲食店予約システムについて実施形態を示し、具体的に説明したが、本発明はこれらに限定されるものではない。当業者であれば、本発明の要旨を逸脱しない範囲内において、上記の各実施形態における、サーバ、データベース、ユーザインターフェースの構成および機能に様々な変更や改良を加えることが可能である。なお、システム端末 (システム端末１１) を、専用機器とする必要はない。たとえば、汎用のパーソナルコンピュータに導入したアプリケーションプログラムがサーバと通信する形式を採用してもよいし、汎用のパーソナルコンピュータからブラウザを経由して、サーブレットを利用する形式を採用してもかまわない。
【産業上の利用可能性】
【００５４】
本発明の飲食店予約システムは、図１に示すように、サーバ (コンピュータ)、アプリケーションソフトウェアモジュール、データベース、ネットワークシステム等によって実現されるものであり、また、図に明示的には示されていないが、コンピュータのＣＰＵ、メモリ、補助記憶装置、ディスプレイ、入出力デバイス等を含むハードウェア資源を統括するＯＳを用いて具体的に実現されるものであるから、自然法則を利用した技術的思想に該当するものであり、レストラン、食堂、ケータリング、ホテル等の産業において利用することができるものである。
【符号の説明】
【００５５】
１０    サーバ
１０１  データベース
１０２  会員情報処理部
１０３  飲食サービス情報処理部
１０４  予約カレンダー処理部
１０５  飲食サービス変更処理部
１０６  利用料金算定処理部
１１    システム端末
１１１  表示部
１１２  操作部
１１３  通信機能部
１２    利用者端末
１２１  表示部
１２２  操作部
１２３  通信機能部
２０    トップ画面
２０１  メニュー欄
２０２  当日予約欄
３０    予約カレンダー画面
３０１  メニュー欄
３０２  予約カレンダー欄
４０    予約在庫設定画面
４０１  予約状況欄
４０２  残り予約受入枠欄
５０    サービス確認画面
５０１  メニュー欄
５０２  メッセージ
５０３  変更ボタン
６０    飲食サービス内容変更画面
６０１  メニュー欄
６０２  基本設定ボタン
６０３  サービス内容ボタン
６０４  休日設定ボタン
７０    トランザクション表示画面
７０１  予約人数変更欄
７０２  申請ボタン
Ｓ１０    飲食店予約システムの全体的な動作
Ｓ１０１  会員登録情報の収集
Ｓ１０２  飲食サービス告知情報の蓄積と配信
Ｓ１０３  飲食サービスの申込みの受理
Ｓ１０４  飲食サービス申込みデータの更新の受理
Ｓ１０５  飲食サービス告知情報や申し込みデータの保守
Ｓ１０６  アンケート処理
Ｓ１０７  飲食店予約システム利用料の課金
Ｓ２０    システム端末からの、飲食サービス告知情報の保守動作
Ｓ２０１  当日予約の確認
Ｓ２０２  当日以降の予約確認
Ｓ２０３  サービス受け入れ枠の変更
Ｓ２０４  サービス内容の確認
Ｓ２０５  サービス内容の変更
Ｓ３０    飲食サービスの予約人数変更へ対応する動作
Ｓ３０１  予約の選択
Ｓ３０２  予約人数の変更
Ｓ３０３  申請
【図１】
2012042996.tif 000003
【図２】
2012042996.tif 000004
【図３】
2012042996.tif 000005
【図４】
2012042996.tif 000006
【図５】
2012042996.tif 000007