JP2013020626A - 提案に基づくレストラン予約 - Google Patents

Abstract

【課題】
レストランは、来店する顧客の数、または、これらの販売促進に応答して彼らが来店する時間をコントロールするには限界がある。
【解決手段】
提案に基づくレストラン予約システムはプロセッサとメモリからなる。プロセッサは、日付又は日付の範囲、時間の範囲、位置、料理、人数などの属性の集合を含む予約に対するリクエストを受信し、日付、時間及び人数に対する実際のテーブルの利用可能性に基づいて利用可能な予約の集合を決定し、日付、時間及び人数に基づいて１つ以上の提案を決定し、利用可能な予約の集合と１つ以上の提案との間で重複する部分集合を決定するように構成される。メモリは、プロセッサに連結され、プロセッサに命令を提供するように構成される。
【選択図】図１

Description

レストラン予約に関する。

レストランは、典型的に、顧客の望みを改善して、ごひいきにしてもらうために販売促進を行う。例えば、ハッピーアワー（サービスタイム）の販売促進、または、無料の料理のクーポンなどである。

しかしながら、レストランは、来店する顧客の数、または、これらの販売促進に応答して彼らが来店する時間をコントロールするには限界がある。

本発明は、プロセス、装置、システム、物の構成、コンピュータで読込可能な記録媒体に組み入れられたコンピュータプログラム製品、及び／又は、プロセッサに連結されたメモリー上に格納され、かつ／または、プロセッサ、例えば、メモリーによって提供される命令を実行するように構成されたプロセッサなどを含む非常に多くの方法によって実施することができる。本明細書では、これらの実施形態、又は本発明が採用し得るその他の形態は、手法（テクニック）と称され得る。一般に、開示された方法のステップの順序は、本発明の技術的範囲において変更することができる。特に明記しない限り、タスクを実行するように構成されたプロセッサ又はメモリーなどの構成要素は、所定の時間でタスクを実行するように一時的に構成された一般的なコンポーネント、又は、タスクを実行するために製造された独自のコンポーネントとして実装される。本明細書では、用語“プロセッサ”は、コンピュータプログラム命令などのようなデータを処理するように構成された、１つ以上の装置、回路、及び／又は、プロセッシングコアのことである。

本発明の１つ以上の実施形態の詳細な説明は、本発明の原理を説明した添付の図面と共に、以下に与えられる。本発明は、そのような実施形態に関して述べられるが、本発明は実施形態に限定されるものではない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、多数の代替物、改良物、及び、同等物を包含する。多数の具体的な詳細は、本発明を十分に理解するために、以下に記載される。これらの詳細は、実施例のために与えており、本発明は、これらの具体的な詳細のいくらか又は全てによらずに、特許請求の範囲に従って定められるものである。明確にする目的で、本発明に関連する技術分野において周知の技術事項は、本発明を無駄に不明りょうにし得るので、詳細な説明はしないことにする。

提案に基づくレストラン予約のためのシステムが開示される。本システムは、プロセッサとメモリーを含む。プロセッサは、日付あるいは日付範囲、時間範囲、場所、料理、及び、人数（パーティーサイズ）など、一連の属性を含む予約のためのリクエストを受信し、前記日付、前記時間、及び、前記人数に対して、実際のテーブルの利用可能性（利用可能テーブル）に基づいて、利用可能な予約の集合を決定し、前記日時、前記時間、及び、前記人数に基づいて、１つ以上の提案を決定し、前記利用可能な予約の集合と前記１つ以上の提案との間で、重複する部分集合を決定するように、構成される。メモリーは、プロセッサに連結され、プロセッサに命令を提供するように構成される。

提案に基づくレストラン予約のためのシステムは、プロセッサとメモリーを含む。プロセッサは、利用可能性ルールを用いて、複数の利用可能なテーブルを生成し、適切な利用可能テーブルの集合を決定するために、前記複数の利用可能なテーブルをフィルターにかけ、適切な提案の集合を決定するために、複数の提案をフィルターにかけ、前記適切な利用可能テーブルの集合と前記適切な提案の集合との間で、重複する部分集合を決定し、トリガーイベントが発生した場合には、前記重複する部分集合から利用者に提案を与えるように、構成される。メモリーは、プロセッサに連結され、プロセッサに命令を提供するように構成される。

本発明の様々な実施形態は、本願明細書及び図面に開示される。

図１は、提案に基づくレストラン予約のためのシステムの１つの実施形態を示すブロック図である。 図２は、サービスプロバイダシステムの１つの実施形態を示すブロック図である。 図３Ａは、提案に基づくレストラン予約に対する処理の流れを示すフローチャートである。 図３Ｂは、提案に基づくレストラン予約の処理の流れの１つの実施形態を示すフローチャートである。 図４は、ユーザーインターフェース表示の１つの実施形態を示す図である。 図５は、ユーザーインターフェース表示の１つの実施形態を示す図である。

いくつかの実施形態では、予約の検索に対する応答を定めるための方法は、テーブルの利用可能性と提案の有効性を定めることを含む。テーブルの利用可能性は、利用可能性ルールを用いて利用可能なものを生成し、その後、該利用可能なものをフィルターにかけて適切な利用可能テーブルを求めることで定められる。提案の有効性は、提案ルールを用いて全ての提案を生成し、そして、該提案をフィルターにかけて適切な提案を求めるによって決定される。適切な利用可能なテーブル、及び、適切な提案は、両集合（適切な利用可能テーブル及び適切な提案）に存在するレストラン／テーブルを見るために検索される。いくつかの実施形態では、検索を行なった後、両集合に存在する、前記レストラン／テーブルは特定され、前記レストラン／テーブルは、顧客に結果を提示する前に、経営管理／収益最適化ルールを生成する場合がある。

いくつかの実施形態では、本システムは、特別な提案型などの検索結果を利用者に提供する。例えば、「サンフランシスコ（ＳＦ）における５０％オフの全ての商取引」が、本システムにおいて検索され、利用者に提供される。

いくつかの実施形態では、レストランは、特定の時間で当該レストランにおいて利用可能なテーブルに限定した提案を作成することができる。それによって、レストランは、販売促進のための提案を受信した顧客の数及び来店率（到着率）をコントロールすることができ、レストランをあふれさせることなく、それらのテーブルを埋めるための販売促進を目的にすることができる。いくつかの実施形態では、本システムは、利用可能なテーブルの全ての有効な組合せを計算する。本システムは、テーブルは予約されると、動的に組合せを削除する。いくつかの実施形態では、本システムは、利用可能なテーブルのルール集合に基づいて提案を自動的に生成する。例えば、レストランは、本日から２日間で、かつ、月曜日から木曜日の午後５時から午後６時半の間で、利用可能なテーブルに対して、請求書の最初の２０ドルを５０％オフにすることを提案する。いくつかの実施形態では、本システムは、テーブル稼動率に基づいて動的に更新される提案を作成する。別の実施形態では、提案（例えば、割引率のパーセンテージ又は値段の割引）は、顧客の来店率、利用可能なテーブル、レストランの定員、収益最適化、顧客維持（顧客囲い込み）、人数、日付、１日のうちの何時、一週間のうちの何曜日、特別なイベント、映画の日、休日、予約率、一日当たりの提案の総数、時間帯（シフト）当たりの全提案、一日当たりの受け入れられた全提案、ある期間における提案の上限数、その他の適切な考量を考慮して、作成される。いくつかの実施形態では、提案は、希望時間が利用可能である場合に、該希望時間に対してなされる。

別の実施形態において、レストランのテーブルの利用可能性は、１）割り振りモデル、すなわち、割り当て（レストランが、時間帯又は来店率に対して、利用可能であるテーブル、食器一式（人数分の食事）又はパーティーの数を指定する）、２）スロットモデル（レストランが、利用可能な人数及び正確な時間を指定する）、３）在庫目録（レストランが、利用可能な特定のテーブル及び時間を指定する）に基づいており、本システムは、特定の人数及び時間、又は、テーブル或いは予約の空き時間を同定するその他の適切な事項を指定する。

いくつかの実施形態では、予約と提案は、単に組み合わせて提供され、予約が完了していないか、キャンセルされた場合に戻される。いくつかの実施形態では、提案は、ペーパーレスで（例えば、ネットワークを介した提案、携帯電話上での提案、ウェブサービスにアクセスするコンピュータ上での提案として）、作成される。いくつかの実施形態では、提案は、予約を捜し求める顧客とサービスとして予約を提供する顧客へのサービスとの間でなされる個別の取引として作成される。提案と有効性は、利用者とサービスとの間の個別の取引のために調整され、該取引は受け入れられるかもしれないが、もし受け入れられなければ取り消される。

別の実施形態において、提案は、収益、食器一式、パーティー、様々な粒度（例えば、日、週、月、年、先週の同じ日、昨年の同じ週など）を伴った、現在の動向データ及び／又は履歴データから算出されたものの全て、提案を作成するために適切なその他の基準のいずれかに基づいている。

いくつかの実施形態では、提案を作成するための本システムは、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、サードパーティーのシステムを用いてアクセスされるか、サードパーティーのシステムと一体化される。例えば、本システムは、割引サービス（例えば、電子メールを介して割引券を配布するサービス、例えば、グルーポン（Groupon^TM）、ウェブを介して割引券を提供するサービス、例えば、リビングソーシャル（LivingSocial）など）と共に利用される。ただし、提案は、レストランで利用可能なテーブルと直接つながっている。

図１は、提案に基づくレストラン予約のためのシステムの１つの実施形態を説明するブロック図である。示された例では、利用者１００がネットワーク１０４を介して、ウェブサーバー１０６と通信する。利用者１００は、利用可能なレストラン予約を要求する。ウェブサーバー１０６は、利用可能なレストラン予約（例えば、検索結果、批評、利用可能な時間、メニュー、座席表、テーブルレイアウト、特別なサービスなど）及び／又は、利用可能な提案（例えば、人数、時間、日付、レストランのタイプなどに基づく）に関する情報を提供する。ウェブサーバー１０６は、直接又はネットワーク１０４を介して、プロバイダシステム１０２と通信する。ウェブサーバー１０６は、サービスプロバイダシステム１０２（例えば、レストラン）を用いて、予約可能情報、予約確定情報、提案可能情報、提案確定情報、メニュー情報、座席表及び／又はテーブルレイアウト情報などと通信する。ウェブサーバー１０６はデータベース１０８と通信する。データベース１０８は、サービスプロバイダ情報（例えば、予約、メニュー、テーブル配置、顧客プロフィールなど）を格納する。別の実施形態では、プロセッサに接続されたネットワークであって、インターネットを介して公的にアクセス可能なウェブサイトへのネットワークは、次の１つ以上の機能：予約及び／又は提案の利用可能なものを送信する機能、ウェブサイトから要求を送信する機能、返された予約及び／又は提案受け入れ情報を送信する機能、或いは、その他の適切な機能を提供する。別の実施形態では、ウェブサーバー１０６又はサービスプロバイダシステム１０２に使われるグラフィカルユーザーインターフェースは、次の１つ以上の機能のためにプロセッサにつながれる：予約リクエストを送信すること及び返送すること、提案を送信すること及び返送すること、予約有効性を提供すること、予約確定情報を提供すること、提案ルールを受信すること、自動的に提案を生成すること、及び／又は、その他の適切な機能である。

いくつかの実施形態では、提案の特定、構成又は変更の機能、関連する範囲及びトリガー条件は、別のシステムを介して、又は、サービスプロバイダシステム１０２に相当するものによって行なわれる。別の実施形態では、提案の設定及びルールの入力は、企業間電子商取引（Ｂ２Ｂ）アプリケーションを用いて、又は、ウェブサーバー或いはその他の適切な方法で行なわれる。

図２は、サービスプロバイダシステムの１つの実施形態を示すブロック図である。いくつかの実施形態では、図２のサービスプロバイダシステム２００は、図１のサービスプロバイダシステム１０２の１つのシステムを実施するために用いられる。示された例において、サービスプロバイダシステム２００は、タッチスクリーン２０２、ウェブサーバーインターフェース２０６、データベース２０８及び在庫マネージャ２１０を含む。タッチスクリーン２０２は、サービスプロバイダシステム２００との橋渡しをするために用いられる。例えば、レストランの経営者は、ナビゲート、コマンド及びパラーメータの入力を行なうためにタッチスクリーン２０２を用いて、サービスプロバイダシステム２００に接続し、又は、その他、サービスプロバイダシステムとの適切なインタラクションによって、サービスプロバイダシステム２００に接続する。ウェブサーバーインターフェース２０６は、サービスプロバイダシステム２００とウェブサーバーに接続して機能する。ウェブサーバーインターフェース２０６は、予約情報、確定情報、配置情報、メニュー情報、又はその他の適切な情報と通信するために用いられる。データベース２０８は、サービスプロバイダ情報を格納する。サービスプロバイダ情報は、予約情報、確定情報、メニュー情報、配置情報などを含む。

在庫マネージャ２１０は、配置ビューア２１２、配置イニシャライザ２１４、組合せ＆置換エンジン２０６、クエリハンドラー２１８、及び、ルールエンジン２２０を含む。在庫マネージャ２１０は、レストラン予約の可能な組合せ及び／又は可能な置換のうち利用可能なものを提案することによって、レストランの在庫のより効率的な使用を可能とする。その後、新しい予約の受領をもって、可能な組合せ及び／又は可能な置換のリストは更新され、新しい予約によって削除される組合せ及び／又は置換が取り除かれる。例えば、新しい予約が組合せ及び／又は置換に競合（すなわち、同じテーブルを同じ期間内に使用すること、又は、この人数の予約に使われる過去の平均時間或いはディナーまでの平均時間などに基づいた同様の期間内に使用すること）するので、組合せ及び置換が可能ではない。配置ビューア２１２は、サービスプロバイダの従業員がレストランの配置を見ることができるようにする。配置情報は、レストランでのテーブル配置（例えば、テーブルの位置、組合せの可能性、座席の数など）を含む。配置イニシャライザ２１４は、レストランでの配置を初期化するために用いられる。組合せ＆置換エンジン２１６は、レストランの配置と現在の予約が与えられると、レストランに対して利用可能な予約の可能な組合せ及び／又は置換を決定する。クエリハンドラー２１８は、テーブルの利用可能性に関する問合わせ（クエリ）を処理するために用いられる。例えば、クエリは、所定のレストランのための利用可能な時間及び利用可能なテーブル配置の全て可能な置換及び組合せを含む利用可能な予約について作成される。ルールエンジン２２０は、ルールに基づいて、予約／テーブル／時間帯を選択するのに用いられる。ルールエンジン２２０は、テーブル／時間帯に対する予約を自動的に選択することができる。提案エンジン２２２は、日付、時間、テーブルサイズが与えられると、指定された所望の提案リストによって設定された具体的な提案に基づいて、或いは、要因（ファクタ）（例えば、顧客の来店率、予約された割合、日付、曜日、レストラン定員、収益の最適化、顧客保持率、資源の最適化、時間、時間帯、月中の１日、休日、ローカルイベント、予約の日数など）によって決まるルール集合に基づいて提案を定める自動化された提案生成エンジンによって、レストランのために利用可能な提案を定めるために用いられる。

いくつかの実施形態では、予約（例えば、レストランにおける具体的なテーブル）の選択は、自動選択ができるルールに基づく。別の実施形態において、予約を選択するためのルールは、テーブルの利用可能性（例えば、テーブルの稼働率を最大化する選択の適合度）を最大化すること、待ち時間を最小化すること、給仕スタッフへの負荷を分散すること、特定の指示（例えば、最初に窓際から最終的にそのレストランの後部など、その他適切なルール）において、テーブルを利用することを含む。別の実施形態において、予約の選択は、１つ以上の次の事項：
（例えば、収益の最大化は、より多く待ち時間／より長い待ち時間を生じ得る）収益を最大化すること、（例えば、顧客満足度の最大化は、レストランを十分に利用しないかもしれない）顧客満足度を最大化すること、（例えば、テーブルの稼働率の予測に用いられる）過去の入れ替わり時間、（例えば、支配人から）受け取った入れ替わり時間、（例えば、顧客の到着又は顧客の流れの予測のために用いられる）過去のレストラン予約情報、（例えば、顧客の要求及びレストランにおけるテーブルに対する潜在的な顧客の流れの予測に用いられる）過去の顧客検索情報（ただし、「過去」は、ルールが前の日や、前の週、月又は年の同じ日、或いは、連休などのその他の意味のある過去の同時期に基づいていることを意味し得る。）、レストランにおける顧客の最大来店率（例えば、最大来店率は、個々の来店率、パーティーでの来店率、より大きなパーティーでの来店率など、及び、１５分間隔の時間セグメント又は全体の入れ替え期間に基づいている。）、又は、予約の選択を支援するためのその他の適切な情報の少なくとも一部に基づいて決定される。

図３Ａは、レストラン予約に基づく提案のための処理の流れを示すフローチャートである。示された実施例では、３００において、要求（リクエスト）が、日付、時間及び人数を含む予約のために受信される。３０２において、利用可能な予約の集合は、レストランで利用可能な実際のテーブルに基づいて決定される。実際のテーブルで利用可能なものは、レストランの利用可能なテーブルに対する組合せ及び置換を計算することで求められる。例えば、レストランは、常連を席に案内できるテーブルを持つ。テーブルは、組合され得るか又は再配置され得る。テーブルを組み合わせたり、再配置したり、又は、分けたりするこの機能は、複数の可能な構成及び複数の可能で有効な予約が存在することを意味する。これらは、利用可能とすることができ、いくつかの予約が埋まってしまったという万一の場合に、新しい利用可能性が求められる。別の実施形態では、実際のテーブルの利用可能性（利用可能なテーブル）は、リアルタイムに決められる。ただし、利用可能性の決定には、日付予約情報、利用情報、配置情報、又は、その他適切な情報の少なくとも一部に基づいた、組合せ及び／又は置換の計算を用いる。別の実施形態では、実際の利用可能テーブルは、１つ以上の次の事項：日々の食器一式（食事）の最大数、座席の食器一式（食事）の数、食事客の付近のレストラン、食事客のレストラン利用履歴、来店率の限界、利用者の振る舞い、利用者の地理的な位置、利用者の支出履歴、来店履歴、１ページに費やす時間、ページ視聴履歴、食事履歴、好みの料理、食事場所、又はその他の適切な評価、に基づいている。３０４では、提案は、日付、時間及び人数に基づいて定められる。いくつかの実施形態では、１以上の提案は、リアルタイムに決められる。例えば、提案は次の事項の少なくとも一部に基づいて定められる：提案の開始日、提案の終了日、提案日（例えば、木曜日、月から水曜日など）、提案時間（例えば、午前１１時から午後３時、午後４時３０分から午後６時までなど）、日々の食器一式（人数分の食事）の最大数、座席の食器一式の数、提案数の上限、提案の数、提案の量（例えば、ドル割引、パーセント割引、パーセントによる食事の割引、パーセントによる飲み物の割引、１つ買うと１つ無料、無料の品物、無料の持込み料（コケージ）、コースメニューの料理、など）、来店率の限界（例えば、１時間毎の限られた数、１５分毎の限られた数など）などである。別の実施例では、１０％オフの提案は、２０１１年１月１０日から２０１１年１月２０日の間、火曜日から木曜日で、午後３時から午後４時の間に設定されるが、それぞれ１５分おきの期間で、２つ以上の提案は用いられない。別の実施形態では、１以上の提案は、最小人数及び／又は最大人数の少なくとも一部に基づいている。３０６では、重複する部分集合は、利用可能な予約の集合と提案の集合との間で定まる。当該重複する部分集合は、日付と人数に対して関連する提案をそれぞれ用いた１つ以上の予約を含む。重複する部分集合は、時間およびその時間に前後する時間に対して、関連する提案をそれぞれ用いた１つ以上の予約を含む。３０８では、重複する部分集合が提供される。

いくつかの実施形態では、提案はユーザーの振る舞いが引き金となる。例えば、引き金となる出来事（トリガーイベント）は、ページ上で費やした時間、ページ視聴履歴、食事履歴、好みの料理、食事場所、食事客の位置、食事客の付近のレストラン、提案の有効性、食事客のレストラン利用の履歴、などに基づいて生じる。いくつかの実施形態では、提案は利用者の地理的位置に基づいてもたらされる。いくつかの実施形態では、提案は収益又は資源の最適化に基づいてもたらされる。例えば、スタッフの利用効率の最大化又はレストランのエリアの利用効率の最大化である。いくつかの実施形態では、提案は食事客の過ごした時間の履歴によって、又は、特定のレストランにおける来店履歴によってもたらされる（例えば、以前は頻繁に来ていたが、最近きていない食事客に提案を生成する）。

いくつかの実施形態では、提案は事前に指定した条件及び／又は事前に指定したルールに基づいて作成される。例えば、提案は、食事客が予約を入れるときに、レストランから１マイル以内に位置する食事客に対してのみ利用可能である；提案は、それが９０％利用されるまで、レストランの「セクション１」に対して生成される；ビップ（ＶＩＰ）のみに対して、３０％オフの提案が生成される；などである。別の実施形態では、事前に指定した条件及び／又は事前に指定したルールは、１つ以上の次の事項：
提案を探すことに対してインセンティブやトリガーを与えるために、食事客は、レストランの顧客（例えば、顧客システムの利用者）によって、或いはレストランの使用者（例えば、レストランのオーナー）によって設定されている条件を満たすこと、食事客がレストランのｘフィート又はｙマイル以内にいること、食事客がリピータであること、食事客が興味のあるレストランとして明らかにフラグを立てていること、食事客がｘ日間以上レストランに食事にきていないこと、食事客がｘ日間以上予約サービスを利用していないこと、又はその他の適切な条件及び／又はルールを含む。いくつかの実施形態では、事前に指定した条件及び／又は事前に指定したルールは、レストラン経営者によって、設定の期間中に決定される。本システムは、前記ルール及び／又は前記事前に指定した条件に基づいて、リアルタイムに提案を生成したり、修正したり、修了したりする。

いくつかの実施形態では、提案は等級による方法、又は時間に対して段階的に或いは線形的に変化する。例えば、割引のパーセンテージは、レストランのアプローチとして有効な在庫に対する日数によって、１０％から２０％、３０％へと変化する。例えば、３日前には１０ドルオフの割引が提案され、２日前には２０ドルオフの割引が提案され、１日前には３０ドルオフの割引が提案され、逆もまた同様である。

いくつかの実施形態では、自動化されたシステムは、ルール集合の少なくとも一部に基づいて提案を作成するために開発される。例えば、テーブル稼働率が全体の３０％未満である在庫水準に対して、テーブル稼働率が全体の７０％になるまで提案を作成する。提案は、予約できる日に近づくと徐々に増加する。いくつかの実施形態では、自動化された提案の開始は、レストランの混雑の割合の少なくとも一部に基づいている。いくつかの実施形態では、ルール集合は、一連の段階状の異なる提案：５％、１０％、１５％及び２０％の値下げを示す。いくつかの実施形態では、ルール集合は、一連の異なるタイプの提案：飲み物の割引、メイン料理の割引、無料の料理などを示す。いくつかの実施形態では、自動化された提案は、お勧めの席（例えば、中庭、眺めなど）の少なくとも一部に基づいている。

図３Ｂは、提案に基づくレストラン予約の処理の流れの１つの実施形態を示すフローチャートである。示された実施例において、３５０では、レストランにおける全ての利用可能なテーブルが利用可能性ルールを用いて生成される。例えば、１）利用可能なスロット―日付、時間及びサイズ（人数）は、レストランによって予め設定され、実際のテーブルに直接関連しない。２）利用可能な割り当て／割り振り―レストランは、ある食事客の最大数又は時間帯で販売できる予約を指定する（それらも実際のテーブルに直接関連しない）。例えば、午後５時から午後１０時までディナーコースの時間帯において３０人分の料理を販売する。３）利用可能な在庫は、レストランは、全てのテーブルや、１名から５名のテーブルなどの各テーブルの人数の範囲がそれぞれ２から６名を着席させることができることを含む、当該レストランの間取図を示す。また、レストランは組み合わせることができるテーブルを定義し、任意で注文の好み（例えば、窓際にある１０名から１２名のテーブルで着席での食事など）を指定する。本システムは、これらのルールに基づいて、全ての可能な日付、時間及び人数を自動的に生成して示す。そして、予約が作成されたときに、利用可能性を自動的に更新する。別の実施形態では、利用可能性ルールは、１つ以上の次のルール：
正確な利用可能テーブル、おおよその利用可能テーブル、又は、推定の利用可能テーブルを示す、レストランからの情報の少なくとも一部に基づいて、利用可能性を決定するルール、あるレストランにおけるテーブルの可能な配置と再配置が与えられると、テーブルの全ての可能な組合せ及び置換に従って、利用可能性を決定するルール、テーブルの割り当て、食器一式、又は、時間帯或いは来店率に対して利用できるパーティーに従って、利用可能性を決定するルール、利用可能な人数や正確な時間を示すスロットモデルに従って、利用可能性を決定するルール、レストランによって、利用できる正確なテーブルと時間が指定された在庫目録に従って、決定するルール、又は、その他の適切なルールを含む。

３５２では、テーブルの利用可能性は、適切な利用可能テーブルを決定するためにフィルターにかけられる。例えば、利用可能なレストランテーブルのデータベースは、利用可能性基準（例えば、エリア、料理のタイプ、時間の範囲、日付の範囲、人数など）を満足するテーブルのために検索される。例えば、テーブルの利用可能性は、資源を最適化するため、又は、収益を最適化するためにフィルターにかけられる。いくつかの実施形態では、レストランは、セクション１が一時的に閉まっているので、セクション２の利用を最適化する。

３５４では、全ての提案は、提案ルールを用いて生成される。例えば、レストランが定員の７０％に満たない場合に、日曜日から木曜日にかけて飲み物２杯で１杯分とする提案を生成し、レストランの定員が９０％に達した場合に、これらの提案の生成を停止する。レストランが、４時間の大きなパーティー向けの部屋を完売しているような別の実施例では、厨房／給仕スタッフ資源を最大限に活用するために、提案ルールは、８時間のシフトのうち残った４時間のために、全請求額の３０％オフの提案を生成する。別の実施形態では、提案ルールは、１つ以上の次のルール：
日付、時間及び人数の少なくとも一部に基づいて提案の有効性を決定するルール、提案がもはや望まれないものになると、当該提案は利用可能なものではないので、提案に対して定員を超えて申し込まれないように、リアルタイムで提案の有効性を決定するルール、キャンペーンの制限（例えば、キャンペーン期間が及ぶ定められた上限、一度キャンペーンを使うと、その提案はもやは利用可能ではない）、１日の制限（例えば、１日当たりの定められた上限）、スロット（時間枠）に基づく制限（例えば、特定の時間）の少なくとも一部に基づいて、提案の有効性を決定するルール、提案が利用可能でないとき（例えば、ピーク時間、休日、シアタータイムなど）に、特典除外日或いは時間、又は、特典除外ルールの少なくとも一部に基づいて、有効性を決定するルール、ペース（例えば、しきい値を超えないように、提案の消費率を抑制するコントロール）の少なくとも一部に基づいて、有効性を決定するルール、又はその他の適切な提案ルールを含む。

３５６では、適切な提案を決定するために、提案がフィルターにかけられる。例えば、提案は、検索評価を満たす提案（例えば、提案が所望の時間範囲、日付範囲、料理タイプ、位置、近所、割引範囲、割引タイプ、人数などの範囲内ある）を識別するためにフィルターにかけられる。例えば、提案の数は、資源の最適化目標（例えば、部屋の使用状況、給仕スタッフの利用状況、キッチンの使用状況、在庫食材の使用状況など）を満たすために決定される。

３５８では、重複する部分集合は、適切な利用可能テーブルと適切な提案との間で決められる。３６０では、イールドマネジメント又は収益最適化ルールが適用される。例えば、提案は、レストラン事業を改善するように設計されたルールを適用することによって作成される。レストランが４時間の大きいパーティー向けの部屋を完売している例では、ルールによって、厨房／給仕スタッフの資源の利用を最大化するために、８時間のシフトにおける残り４時間のために、全請求額の３０％オフの提案を生成できる。別の実施例では、（予約と支出の履歴に基づいて）気前よくお金を使う人として知られている、レストランのビップ（ＶＩＰ）にのみ、持込み料無料の提案を生成する。レストランが大量の牛肉を仕入れてしまったような別の例では、牛肉料理全品に対して３０％割引を提案する。いくつかの実施形態では、レストランのビジネス尺度（例えば、現状の食器一式（人数分の食事）、予約及び日、週、月で発生した収益 対 人数分の食事、予約に設定されたしきい値又は偏差値、 収益 対 過去のトレンド）に基づいて、提案が動的に有効又は無効にされる。いくつかの実施形態では、これらの尺度の１つの短期投資利益は、次の事項：（ａ）提案を有効にすること、（ｂ）提案された提案数の増加、（ｃ）提案された割引の変更、（ｄ）提案価格の調整を引き起こす。いくつかの実施形態では、最適化ルールは、提案エンジンへフィードバックする。

いくつかの実施形態では、提案はルール集合に基づいて除去される（例えば、提案開始の日からｘ日以内に提案が売れなければ、その提案を自動的に削除する）。

図４は、ユーザーインターフェース表示の１つの実施形態を示す図である。示された実施例において、４００では、利用者は、場所、料理の種類又は特定のレストラン、日付、時間及び人数についてのフィールドに入力できる。その後、利用者は、テーブルを三択するように指示することができる。４０４では、タブ表示がｘ％オフの食事を示す。いくつかの実施形態では、指示項目が選択された後に、タブ表示が読み込まれる。タブ表示は、１０ドルで予約できる高級シティーレストランでの２０％から３０％オフの食事を表示する。割引は目立たないようにお会計に適用され得る。例えば、ロシアンヒルに位置し、イタリアンスタイルのレストランであるレストランテ イタリアーノは、５５レビューと４つ星の格付けを有し、３０％オフの割引を受けることができる。同様に、２５ドル割引や２０％割引が、マハラジャ、バートズステーキハウス、カラマリといったレストランに対して受けられる。割引又はプロモーションは、ボタン４０２を押すことによって選択できる。

図５はユーザーインターフェース表示の１つの実施形態を示す図である。示された例において、５００では、利用者は、日付、時間及び人数に関するフィールドに入力できる。例えば、利用者は、２０１１年６月２５日の午後９時３０分に２名のテーブルを見つけるためにリクエストをする。そこで、さらに利用者はテーブルを見つけるために指示できる。５０２では、ディスプレイは９時３０分前後の時間帯で３０％オフを提案する４つのレストランを示す。カラマリ レストランは８時、９時１５分、９時３０分で、利用可能な３０％オフの提案を有する。ファーロール レストランは８時３０分と１０時３０分で、利用可能な３０％オフの提案を有する。プイポックは、８時４５分、９時３０分、９時４５分で、利用可能な３０％オフの提案を有する。ビーンズ ステーキハウスは、８時３０分、９時、９時１５分で、利用可能な３０％オフの提案を有する。

先の実施形態は、理解を明確にするために、ある程度詳細に記載されているが、本発明は上述の詳細な説明に限定されるものではない。本発明を実施する多くの代替的な方法が存在する。開示された実施形態は説明のためのものであり、限定的なものではない。

Claims (40)

1. 提案に基づくレストラン予約システムにおいて、
   日付と時間と人数に対して、実際のテーブルの利用可能性に基づいて、利用可能な予約の集合を決定し、
   前記実際のテーブルの利用可能性は、レストランのテーブルの利用可能性に対する組合せ及び置換を計算することで定められ、
   前記日付と前記時間と前記人数に基づいて１つ以上の提案を決定し、
   前記利用可能な予約の集合と前記１つ以上の提案との間で重複する部分集合を決定するように構成されたプロセッサと、
   前記プロセッサに連結され、前記プロセッサに命令を提供するように構成されたメモリと
   を含む、提案に基づくレストラン予約システム。
2. 前記日付と前記時間と前記人数を含む予約のためのリクエストを受信すること
   をさらに含むことを特徴とする請求項１に記載のシステム。
3. 前記重複する部分集合を提供すること
   をさらに含むことを特徴とする請求項１に記載のシステム。
4. 前記組合せ及び置換は、可能なテーブルの組合せ又は分離、或いは、レストランに対して可能なその他の配置
   を含むことを特徴とする請求項１に記載のシステム。
5. 前記実際のテーブルの利用可能性は、リアルタイムに決定されること
   を特徴とする請求項１に記載のシステム。
6. 前記利用可能性の決定には、日付予約情報、利用情報、構成情報の少なくとも一部に基づく組合せ及び／又は置換の計算を用いること
   を特徴とする請求項５に記載のシステム。
7. 前記１つ以上の提案は、リアルタイムに決定されること
   を特徴とする請求項１に記載のシステム。
8. 前記１つ以上の提案は、提案の開始日、提案の終了日、提案日、提案時間の少なくとも一部に基づくこと
   を特徴とする請求項１に記載のシステム。
9. 前記１つ以上の提案は、日々の食器一式の最大数、座席の食器一式の数、提案数の上限、提案の数、提案の量、食事客の位置、食事客の付近のレストラン、提案の有効性、食事客のレストラン利用の履歴、来店率の限界の少なくとも一部に基づくことを特徴とする請求項１に記載のシステム。
10. 前記実際のテーブルの利用可能性は、日々の食器一式の最大数、座席の食器一式の数、提案数の上限、食事客の位置、食事客の付近のレストラン、食事客のレストラン利用の履歴、来店率の限界
    のうち１つ以上のものに基づくこと
    を特徴とする請求項１に記載のシステム。
11. 前記１つ以上の提案は、最小人数と最大人数の少なくともいずれか一方に基づくこと
    を特徴とする請求項１に記載のシステム。
12. 前記重複する部分集合は、前記日付と前記人数に対する関連した提案をそれぞれ伴った１つ以上の予約を含むこと
    を特徴とする請求項１に記載のシステム。
13. 前記重複する部分集合は、前記時間の前後の時間帯に対する関連した提案をそれぞれ伴った１つ以上の予約を含むこと
    を特徴とする請求項１に記載のシステム。
14. 前記１つ以上の提案は、等級による方法、段階的な方法、又は線形的な方法のうち１つ以上の方法で変化すること
    を特徴とする請求項１に記載のシステム。
15. 前記１つ以上の提案は、ルール集合の少なくとも一部に基づいて、自動的に作成されること
    を特徴とする請求項１に記載のシステム。
16. 自動化された提案の開始又は終了は、トリガーイベント又は事前に指定された条件の少なくとも一方に基づくこと
    を特徴とする請求項１５に記載のシステム。
17. 前記トリガーイベントは、利用者の振る舞い、利用者の地理的な位置、利用者の支出履歴、来店履歴、１ページに費やす時間、ページ視聴履歴、食事履歴、好みの料理及び食事場所のうち１つ以上のものに基づいて引き起こされること
    を特徴とする請求項１６に記載のシステム。
18. 前記実際のテーブルの利用可能性は、利用者の振る舞い、利用者の地理的な位置、利用者の支出履歴、来店履歴、１ページに費やす時間、ページ視聴履歴、食事履歴、好みの料理及び食事場所のうち１つ以上のものに基づくこと
    を特徴とする請求項１６に記載のシステム。
19. 自動化された提案の開始又は終了は、少なくともレストランの混雑の割合に基づくこと
    を特徴とする請求項１５に記載のシステム。
20. 自動化された提案の開始又は終了は、少なくとも収益の最適化に基づくこと
    を特徴とする請求項１５に記載のシステム。
21. 自動化された提案の開始又は終了は、少なくとも資源の最適化に基づくこと
    を特徴とする請求項１５に記載のシステム。
22. 提案に基づくレストラン予約方法において、
    日付と時間と人数に対して、実際のテーブルの利用可能性に基づいて、利用可能な予約の集合を決定するステップであって、前記実際のテーブルの利用可能性は、レストランのテーブルの利用可能性に対する組合せ及び置換を計算することで定められる、ステップと、
    前記日付と前記時間と前記人数に基づいて１つ以上の提案を決定するステップと、
    前記利用可能な予約の集合と前記１つ以上の提案との間で重複する部分集合を決定するステップと
    を含む、提案に基づくレストラン予約方法。
23. 提案に基づくレストラン予約のためのコンピュータプログラム製品であって、コンピュータ読み取り可能記録媒体に組み入れられる、コンピュータプログラム製品において、
    日付と時間と人数に対して、実際のテーブルの利用可能性に基づいて、利用可能な予約の集合を決定し、
    前記実際のテーブルの利用可能性は、レストランのテーブルの利用可能性に対する組合せ及び置換を計算することで定められ、
    前記日付と前記時間と前記人数に基づいて１つ以上の提案を決定し、
    前記利用可能な予約の集合と前記１つ以上の提案との間で重複する部分集合を決定するためのコンピュータ命令を
    含む提案に基づくレストラン予約のためのコンピュータプログラム製品。
24. 提案に基づくレストラン予約システムにおいて、
    利用可能性ルールを用いて、複数の利用可能テーブルを生成し、
    前記複数の利用可能なテーブルをフィルターにかけ、適切な利用可能テーブルの集合を決定し、
    提案ルールを用いて、複数の提案を生成し、
    前記複数の提案をフィルターにかけ、適切な提案の集合を決定し、
    前記適切な利用可能テーブルの集合と前記適切な提案との間で重複する部分集合を決定し、
    トリガーイベントが発生した場合には、前記重複する部分集合から利用者に提案を提供するように構成されたプロセッサと、
    前記プロセッサに連結され、前記プロセッサに命令を提供するように構成されたメモリと
    を含む、提案に基づくレストラン予約システム。
25. 前記複数の利用可能テーブルは、複数のレストランにおいて、テーブルの利用可能性の全ての可能な置換及び組合せを検索することを含むこと
    を特徴とする請求項２４に記載のシステム。
26. 前記複数の利用可能テーブルを生成することは、複数のレストランの割り当て又は割り振りを検索することを含むこと
    を特徴とする請求項２４に記載のシステム。
27. 前記複数の利用可能テーブルを生成することは、複数のレストランにおける時間帯にそれぞれ関連するテーブルの利用可能性を検索することを含むこと
    を特徴とする請求項２４に記載のシステム。
28. 前記トリガーイベントは、収益最適化の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
29. 前記トリガーイベントは、資源最適化の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
30. 前記トリガーイベントは、利用者の振る舞いの少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
31. 前記トリガーイベントは、利用者の地理的な位置の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
32. 前記トリガーイベントは、利用者の支出履歴の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
33. 前記トリガーイベントは、来店履歴の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
34. 前記トリガーイベントは、１ページに費やす時間の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
35. 前記トリガーイベントは、ページ視聴履歴の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
36. 前記トリガーイベントは、食事履歴の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
37. 前記トリガーイベントは、好みの料理の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
38. 前記トリガーイベントは、食事場所の少なくとも一部に基づいて引き起こされること
    を特徴とする請求項２４に記載のシステム。
39. 提案に基づくレストラン予約方法において、
    利用可能性ルールを用いて、複数の利用可能テーブルを生成するステップと、
    前記複数の利用可能なテーブルをフィルターにかけ、適切な利用可能テーブルの集合を決定するステップと、
    提案ルールを用いて、複数の提案を生成するステップと、
    前記複数の提案をフィルターにかけ、適切な提案の集合を決定するステップと、
    前記適切な利用可能テーブルの集合と前記適切な提案との間で重複する部分集合を決定するステップと、
    トリガーイベントが発生した場合には、前記重複する部分集合から利用者に提案を提供するステップと
    を含む、提案に基づくレストラン予約方法。
40. 提案に基づくレストラン予約のためのコンピュータプログラム製品であって、コンピュータ読み取り可能記録媒体に組み入れられる、コンピュータプログラム製品において、
    利用可能性ルールを用いて、複数の利用可能テーブルを生成し、
    前記複数の利用可能なテーブルをフィルターにかけ、適切な利用可能テーブルの集合を決定し、
    提案ルールを用いて、複数の提案を生成し、
    前記複数の提案をフィルターにかけ、適切な提案の集合を決定し、
    前記適切な利用可能テーブルの集合と前記適切な提案との間で重複する部分集合を決定し、
    トリガーイベントが発生した場合には、前記重複する部分集合から利用者に提案を提供するためのコンピュータ命令を
    含む提案に基づくレストラン予約のためのコンピュータプログラム製品。

Images