(58)【調査した分野】(Int.Cl.,DB名)
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得手段と、
前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出手段と、
前記対象の注文実績情報に基づいて、前記ユーザが所定の組み合わせの商品を所定の順序で注文したか否かに応じて、前記ユーザの退席可能性を判定する判定手段と、
前記対象の店舗に関し前記判定手段による判定結果に応じて更新される情報を提供する提供手段と、
を含むことを特徴とする情報提供システム。
前記記憶手段に、前記ユーザの前記対象の店舗における過去の注文実績情報が記憶される場合には、当該過去の注文実績情報に基づいて、前記所定の組み合わせの商品と、前記所定の順序を設定する設定手段をさらに含む
ことを特徴とする請求項1に記載の情報提供システム。
前記設定手段は、前記記憶手段に、前記ユーザの前記対象の店舗における過去の注文実績情報が記憶されない場合には、当該対象の店舗における過去の注文実績情報に基づいて、前記所定の組み合わせの商品と、前記所定の順序を設定する
ことを特徴とする請求項2に記載の情報提供システム。
前記設定手段は、前記記憶手段に、前記ユーザの前記対象の店舗における過去の注文実績情報が記憶されない場合には、前記ユーザと属性情報が対応する他のユーザの前記対象の店舗における過去の注文実績情報に基づいて、前記所定の組み合わせの商品と、前記所定の順序を設定する
ことを特徴とする請求項3に記載の情報提供システム。
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得手段と、
前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出手段と、
前記抽出手段により抽出された注文実績情報における同一商品の注文数量に基づいて、当該注文実績情報に係るユーザの数を推定する推定手段と、
前記推定したユーザの数に基づいて設定したユーザの退席可能性を判定するための判定条件が、前記対象の注文実績情報により満足されたかに応じて、前記ユーザの退席可能性を判定する判定手段と、
前記対象の店舗に関し前記判定手段による判定結果に応じて更新される情報を提供する提供手段と、
を含むことを特徴とする情報提供システム。
前記抽出手段は、前記記憶手段から、店舗識別情報及び座席識別情報が同一であって、注文時間の時間間隔が所定の時間間隔よりも短い注文実績情報を前記対象の注文実績情報として抽出する
ことを特徴とする請求項1乃至5のいずれかに記載の情報提供システム。
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得ステップと、
前記注文実績情報取得ステップで取得した注文実績情報を記憶手段に記憶するステップと、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出ステップと、
前記対象の注文実績情報に基づいて、前記ユーザが所定の組み合わせの商品を所定の順序で注文したか否かに応じて、前記ユーザの退席可能性を判定する判定ステップと、
前記対象の店舗に関し前記判定手段による判定結果に応じて更新される情報を提供する提供ステップと、
を含むことを特徴とする情報提供方法。
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得手段と、
前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出手段と、
前記対象の注文実績情報に基づいて、前記ユーザが所定の組み合わせの商品を所定の順序で注文したか否かに応じて、前記ユーザの退席可能性を判定する判定手段と、
前記対象の店舗に関し前記判定手段による判定結果に応じて更新される情報を提供する提供手段
としてコンピュータを機能させるためのプログラム。
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得ステップと、
前記注文実績情報取得ステップにより取得した注文実績情報を記憶手段に記憶するステップと、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出ステップと、
前記抽出ステップにより抽出された注文実績情報における同一商品の注文数量に基づいて、当該注文実績情報に係るユーザの数を推定する推定ステップと、
前記推定したユーザの数に基づいて設定したユーザの退席可能性を判定するための判定条件が、前記対象の注文実績情報により満足されたかに応じて、前記ユーザの退席可能性を判定する判定ステップと、
前記対象の店舗に関し前記判定ステップによる判定結果に応じて更新される情報を提供する提供ステップと、
を含むことを特徴とする情報提供方法。
店舗を識別する店舗識別情報と、当該店舗の座席を識別する座席識別情報に関連付けられた、ユーザが注文した商品を識別する商品識別情報と、当該注文に係る商品の数量と、を含む注文実績情報を取得する注文実績情報取得手段と、
前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、
前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報に基づいてグループ化して抽出する抽出手段と、
前記抽出手段により抽出された注文実績情報における同一商品の注文数量に基づいて、当該注文実績情報に係るユーザの数を推定する推定手段と、
前記推定したユーザの数に基づいて設定したユーザの退席可能性を判定するための判定条件が、前記対象の注文実績情報により満足されたかに応じて、前記ユーザの退席可能性を判定する判定手段と、
前記対象の店舗に関し前記判定手段による判定結果に応じて更新される情報を提供する提供手段
としてコンピュータを機能させるためのプログラム。
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、実際には個々の客ごとに飲食の量、同席する人数、飲食の目的等が異なり店舗の滞在時間は異なることが一般的であるから、上記の従来技術のように個々の客を一律に扱ってその注文内容を考慮に入れずに客席の空き予測をした場合にはその予測精度が低くなってしまっていた。
【0005】
本発明は上記課題に鑑みて為されたものであって、その目的は、店舗の客席の空き状況に関する情報を店舗内のユーザの注文実績に基づいて逐次更新して提供できる情報提供システム、情報提供方法、プログラム及び情報記録媒体を提供することにある。
【課題を解決するための手段】
【0006】
上記目的を達成するために、本発明に係る情報提供システムは、店舗を識別する店舗識別情報と、前記店舗に注文する商品を識別する商品識別情報と、当該注文に係る商品の数量と、当該注文に係るユーザを識別するユーザ識別情報と、当該注文に係る注文時間と、当該注文に係る座席識別情報とを含む注文実績情報を取得する注文実績情報取得手段と、前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報及び注文時間に基づいてグループ化して抽出する抽出手段と、前記記憶手段に、前記対象の注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む過去の注文実績情報が記憶される場合には、当該過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定する判定手段と、前記対象の店舗に関し前記判定手段による判定結果に基づく情報を提供する提供手段と、を含むことを特徴とする。
【0007】
また、本発明の一態様では、前記判定手段は、前記記憶手段に、前記対象の注文実績情報以外に当該注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む他の注文実績情報が記憶されない場合には、当該店舗識別情報及び当該ユーザ識別情報のユーザと属性情報が対応する他のユーザのユーザ識別情報を含む過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定することを特徴とする。
【0008】
また、本発明の一態様では、前記判定手段は、前記記憶手段に、前記対象の注文実績情報以外に当該注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む他の注文実績情報が記憶されない場合には、当該店舗識別情報を含む過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定することを特徴とする。
【0009】
また、本発明の一態様では、前記注文実績情報は、前記注文に係る決済金額を含み、前記判定手段は、前記対象の注文実績情報に係る決済金額の合計が所定の決済金額を超えている場合に、前記対象の注文実績情報に係るユーザが前記対象の店舗から退席する可能性が高いと判定することを特徴とする。
【0010】
また、本発明の一態様では、前記判定手段は、前記対象の注文実績情報に係る商品のカロリーの合計が所定のカロリーを超えている場合に、前記対象の注文実績情報に係るユーザが前記対象の店舗から退席する可能性が高いと判定することを特徴とする。
【0011】
また、本発明の一態様では、前記判定手段は、前記現在の注文実績情報に含まれる最初の時間からの経過時間が第1の経過時間を超えている場合に、前記対象の注文実績情報に係るユーザが前記対象の店舗から退席する可能性が高いと判定することを特徴とする。
【0012】
また、本発明の一態様では、前記判定手段は、前記対象の注文実績情報に含まれる最後の時間からの経過時間が第2の経過時間を超えている場合に、前記対象の注文実績情報に係るユーザが前記対象の店舗から退席する可能性が高いと判定することを特徴とする。
【0013】
また、本発明の一態様では、前記抽出手段は、前記記憶手段から、店舗識別情報及び座席識別情報が同一であって、注文時間の時間間隔が所定の時間間隔よりも短い注文実績情報を前記対象の注文実績情報として抽出することを特徴とする。
【0014】
また、本発明の一態様では、前記提供手段は、前記対象の注文実績情報に係るユーザの退席可能性に応じて決定した退席予測時間を提供することを特徴とする。
【0015】
また、本発明の一態様では、前記判定手段は、前記対象の注文実績情報によって、所定の組み合わせ及び順序により所定の商品群が注文された場合に、前記対象の注文実績情報に係るユーザが前記対象の店舗から退席する可能性が高いと判定することを特徴とする。
【0016】
また、本発明の一態様では、前記判定条件は、少なくとも注文に係る時間帯、季節、前記対象の注文実績情報に係るユーザの数、前記対象の注文実績情報に係るユーザの性別のいずれかに応じて可変であることを特徴とする。
【0017】
また、本発明の一態様では、前記情報提供システムは、前記抽出手段により抽出された注文実績情報に含まれる商品の数量に基づいて、当該注文実績情報に係るユーザの数を推定する推定手段をさらに含むことを特徴とする。
【0018】
また、本発明の一態様では、前記過去の注文実績情報は、前記対象の注文実績情報と、少なくとも注文に係る時間帯、季節、前記対象の注文実績情報に係るユーザの数、前記対象の注文実績情報に係るユーザの性別のいずれかが関連した注文実績情報であることを特徴とする。
【0019】
また、本発明に係る情報提供方法は、店舗を識別する店舗識別情報と、前記店舗に注文する商品を識別する商品識別情報と、当該注文に係る商品の数量と、当該注文に係るユーザを識別するユーザ識別情報と、当該注文に係る注文時間と、当該注文に係る座席識別情報とを含む注文実績情報を取得する注文実績情報取得ステップと、前記注文実績情報取得ステップで取得した注文実績情報を記憶手段に記憶するステップと、前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報及び注文時間に基づいてグループ化して抽出する抽出ステップと、前記記憶手段に、前記対象の注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む過去の注文実績情報が記憶される場合には、当該過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定する判定ステップと、前記対象の店舗に関し前記判定ステップよる判定結果に基づく情報を提供する提供ステップと、を含むことを特徴とする。
【0020】
また、本発明に係るプログラムは、店舗を識別する店舗識別情報と、前記店舗に注文する商品を識別する商品識別情報と、当該注文に係る商品の数量と、当該注文に係るユーザを識別するユーザ識別情報と、当該注文に係る注文時間と、当該注文に係る座席識別情報とを含む注文実績情報を取得する注文実績情報取得手段と、前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報及び注文時間に基づいてグループ化して抽出する抽出手段と、前記記憶手段に、前記対象の注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む過去の注文実績情報が記憶される場合には、当該過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定する判定手段と、前記対象の店舗に関し前記判定手段による判定結果に基づく情報を提供する提供手段としてコンピュータを機能させるためのプログラムである。
【0021】
また、本発明に係る情報記録媒体は、店舗を識別する店舗識別情報と、前記店舗に注文する商品を識別する商品識別情報と、当該注文に係る商品の数量と、当該注文に係るユーザを識別するユーザ識別情報と、当該注文に係る注文時間と、当該注文に係る座席識別情報とを含む注文実績情報を取得する注文実績情報取得手段と、前記注文実績情報取得手段により取得した注文実績情報を記憶手段に記憶する手段と、前記記憶手段から、対象の店舗に係る注文実績情報のうち現在の注文に係る対象の注文実績情報を、座席識別情報及び注文時間に基づいてグループ化して抽出する抽出手段と、前記記憶手段に、前記対象の注文実績情報に含まれる店舗識別情報及びユーザ識別情報を含む過去の注文実績情報が記憶される場合には、当該過去の注文実績情報に基づいて設定した判定条件と前記対象の注文実績情報との比較に基づいて、前記対象の注文実績情報に係るユーザの退席可能性を判定する判定手段と、前記対象の店舗に関し前記判定手段による判定結果に基づく情報を提供する提供手段としてコンピュータを機能させるためのプログラムを記録した情報記録媒体である。
【発明の効果】
【0022】
本発明の一態様によれば、店舗の客席の空き状況に関する情報を店舗内のユーザの注文実績に基づいて逐次更新して提供できる。
【発明を実施するための形態】
【0024】
以下、本発明に係る実施の形態(以下、実施形態)を、図面を参照しながら説明する。
【0025】
図1には、本実施形態に係る店舗情報処理システム100のシステム構成図を示した。
図1に示されるように、店舗情報処理システム100は、携帯端末200、受注サーバ300、決済サーバ400、店舗情報提供サーバ500、店舗端末600を含み、携帯端末200、受注サーバ300、決済サーバ400、店舗情報提供サーバ500、店舗端末600はそれぞれネットワーク700を介して相互に通信可能に接続される。
【0026】
携帯端末200は、無線通信機能及び電子マネー等による決済機能を有する情報処理端末である。例えば、携帯端末200はタッチパネルやボタン等の操作受け付け部を備え、ユーザから受け付けた操作に応じて処理を実行し、その処理結果をタッチパネルに表示する。例えば、ユーザは、携帯端末200により店舗情報提供サーバ500にアクセスして店舗の空き状況を確認し、受注サーバ300からダウンロードした店舗のメニュー情報から指定したメニューを注文し、注文したメニューの電子決済を決済サーバ400との間で実行する等の処理を行う。なお、本実施形態において対象とする店舗は、店内にテーブル及び座席を有する飲食店とし、店舗の空き状況に関する情報とは、店舗で飲食物の提供を受ける少なくとも一部のユーザが店舗から退席しそうな状態にあるか否かを判定した判定結果に基づき生成される情報である。
【0027】
受注サーバ300は、携帯端末200から注文情報を受け付けて、受け付けた注文情報を処理するサーバである。例えば、受注サーバ300は、携帯端末200から受け付けた注文情報についての電子決済を決済サーバ400に依頼し、決済サーバ400から当該電子決済の完了通知を受信した場合に、当該注文情報を店舗端末600に送信する。なお、店舗においては、店舗端末600が受注サーバ300から受信した注文情報に従って、店舗内のユーザに注文されたメニュー(商品)を提供する。
【0028】
決済サーバ400は、受注サーバ300が携帯端末200から受け付けた注文情報の電子決済を、当該注文情報を送信した携帯端末200に実行させて、その実行結果を取得し管理するサーバである。例えば、決済サーバ400は、携帯端末200により発注された注文情報について電子マネー決済を実行させ、電子マネー決済が正常に完了した場合に、受注サーバ300に当該注文情報についての決済完了通知を送信する。
【0029】
店舗情報提供サーバ500は、受注サーバ300から店舗内の各ユーザにより発注された注文情報の履歴に基づいて当該各ユーザが退席しそうな状態にあるか否かを判定し、その判定結果に基づいて当該店舗の空き状況に関する退席予測情報を提供する。
【0030】
[店舗情報処理システム100における注文処理のシーケンスの一例]
以下、
図2に示すシーケンス図を参照しながら、店舗情報処理システム100における注文処理の流れを説明する。以下説明するシーケンスの例では、ユーザは受注サーバ300にユーザID、メールアドレス、性別、生年月日等の属性情報を予め登録してあることとする。
【0031】
図2に示すように、ユーザは利用しようとする店舗内又は店舗外において、携帯端末200を用いて受注サーバ300にユーザIDとパスワードを入力してログインし(S1)、上記利用しようとする店舗を検索し(S2)、検索された店舗のメニュー情報をダウンロードする(S3)。なお、携帯端末200は、メニュー情報と共に当該メニュー情報に基づいて受注サーバ300に発注処理を行うためのアプリケーションをダウンロードすることとしてもよい。
【0032】
携帯端末200は、ダウンロードしたメニュー情報に基づいてメニュー画面を表示する(S4)。
図3には、携帯端末200に表示されるメニュー画面の一例を示した。
図3に示されるメニュー画面の例では、メニューごとにメニュー名、当該メニューの金額、当該メニューの注文に進むためのリンクが設けられる。
【0033】
ここで「注文に進む」のリンクが押下されると、例えば
図4に示すメニュー注文画面が表示される。
図4に示すメニュー注文画面には、注文数量、ユーザのテーブルを識別するテーブル識別情報(例えばテーブル番号)の入力欄、注文を実行する「注文実行」のリンク等が設けられる。
【0034】
ユーザは店舗内でテーブルに案内された後に、例えば
図4に示したメニュー注文画面に注文数量と、当該テーブルのテーブル識別情報を入力して「注文実行」のリンクを押下すると、携帯端末200はユーザから要求されたメニュー、注文数量、テーブル識別情報、店舗ID、ユーザIDを含む注文情報を受注サーバ300に送信する(S5)。
【0035】
受注サーバ300は、携帯端末200から受信した注文情報の受注が可能でない場合には(S6:N)、注文不可通知を携帯端末200に送信する(S7)。受注サーバ300は、携帯端末200から受信した注文情報の受注が可能な場合には(S6:Y)、当該注文情報に係る決済情報と当該決済情報のトークンを携帯端末200に送信するとともに(S8)、携帯端末200を決済サーバ400にリダイレクトさせる(S9)。なお、受注サーバ300は、受け付けた注文が可能か否かは、店舗端末600に問い合わせて判断することとしてもよいし、受注サーバ300に各店舗の受注可能なメニューの情報を順次更新して保持している場合には、当該受注可能なメニューの情報に基づいて判断することとしてもよい。
【0036】
なお、受注サーバ300が、注文情報を識別する注文ID、決済金額、注文情報に係るユーザのメールアドレスを含む決済依頼情報を決済サーバ400に送信することとしてもよく、この場合には、決済サーバ400は、受注サーバ300から受信した決済依頼情報に含まれるメールアドレスに対して、電子決済を実行するためのリンクを含む決済開始メールを送信することとしてよい。
【0037】
図5には、決済開始メールの一例を示した。
図5に示される例では、決済開始メールには、決済に係る注文内容(メニュー、注文数量、決済金額)と、「お支払いはこちら」のリンクが含まれる。「お支払いはこちら」のリンクが選択されると、例えば
図6に示される、電子マネー決済開始画面に進み、電子マネー決済開始画面の案内に従って電子マネー決済を実行する。
【0038】
携帯端末200では、決済サーバ400と通信して、決済情報に基づいて電子マネー決済を実行すると(S10)、決済サーバ400は、電子マネー決済の完了通知を受け付けて(S11)、例えば
図7に示す決済完了メールを携帯端末200に送信する。
【0039】
決済サーバ400は、電子マネー決済が完了した注文IDの情報を受注サーバ300に通知し(S12)、受注サーバ300は、決済の完了通知を受けた注文IDに係る注文情報を店舗端末600に送信する(S13)。店舗では、店舗端末600が受注サーバ300から受信した注文情報に従って、ユーザに注文されたメニューに係る飲食物が提供される。
【0040】
受注サーバ300は、処理が完了した注文情報に係る注文実績情報を店舗情報提供サーバ500に送信する(S14)。例えば、注文実績情報には、注文ID、ユーザID、ユーザ属性情報、店舗ID、メニューID、注文数量、決済金額、メニュー属性情報(例えばカロリー)、注文時間、テーブル識別情報等を含むこととしてよい。受注サーバ300は、注文情報について処理が完了するごとに、当該注文情報に係る注文実績情報を店舗情報提供サーバ500に送信してもよいし、予め定められたタイミング(例えば所定の時間間隔置き等)でそれまでに蓄積された未送信の注文実績情報を店舗情報提供サーバ500に送信してもよい。店舗情報提供サーバ500は、受注サーバ300から受信した注文実績情報を記憶する(S15)。上記の処理(S5〜S15)は、携帯端末200から注文を受けるごとに行われることとしてよい。
【0041】
なお、店舗情報処理システム100における注文処理のシーケンスは上述した例に限られない。例えば、上記のシーケンスにおいて、受注サーバ300は、携帯端末200から受信した注文情報の受注が可能な場合には(S6:Y)、トークンを発行するとともに、発行したトークンを決済サーバ400に送信して、決済サーバ400がトークンを含む決済情報を携帯端末200に送信するようにしてもよい。この場合には、携帯端末200で決済が実行された後に、携帯端末200がトークンを含む決済完了通知を受注サーバ300に送信し、受注サーバ200が当該決済完了通知に含まれるトークンと、発行したトークンとを照合して、決済が行われた注文情報を特定することとしてよい。また、携帯端末200で決済が実行された後に、携帯端末200がトークンを含む決済完了通知を決済サーバ400に送信し、受注サーバ200が決済サーバ400からトークンを受信して、発行したトークンとの照合を行うようにしても構わない。
【0042】
[店舗情報提供サーバ500による退席予測処理の一例]
次に、
図8に示したフローチャートを参照しながら、店舗情報提供サーバ500において記憶された注文実績情報を利用して行われる退席予測処理の流れを説明する。
【0043】
図8に示されるように、店舗情報提供サーバ500は、処理対象の店舗ID(Siとし、1≦i≦N、iの初期値は1で、Nは処理対象の全店舗数)を選択し(S21)、当該選択した店舗IDを含む注文実績情報の中から処理対象のユーザID(Ujとし、1≦j≦M、jの初期値は1で、Mは処理対象の全ユーザ数)を選択する(S22)。そして、店舗情報提供サーバ500は、記憶された注文実績情報から、上記選択された店舗ID(Si)とユーザID(Uj)を含み、所定の条件を満足する注文実績情報を抽出する(S23)。ここで所定の条件とは、例えば、注文時間が現在時から所定の時間間隔内にある注文実績情報であること等の条件としてよい。
【0044】
店舗情報提供サーバ500は、上記抽出した注文実績情報と、所定の判定条件とに基づいて、店舗(Si)からユーザ(Uj)が退席しそうな状態にあるか否かを判定し(S24)、その判定結果を店舗(Si)、ユーザ(Uj)に関連づけて記憶する(S25)。なお、所定の判定条件は、店舗(Si)、店舗(Si)の属性情報(店舗カテゴリ等)、ユーザ(Uj)、ユーザ(Uj)の属性情報(年齢、性別等)のいずれか又はこれらの組み合わせに関連付けられて記憶された判定条件の中から選択することとしてよい。
【0045】
次に、店舗情報提供サーバ500は、処理対象のユーザが残っている場合には(S26:Y)、Ujのjをインクリメントして次のユーザを選択して(S27)、S23に戻り、処理対象のユーザが残っていない場合には(S26:N)、処理対象の店舗が残っているか否かを判定する(S28)。ここで、処理対象の店舗が残っている場合には(S28:Y)、Siのiをインクリメントして次の店舗を選択するとともにUjのjを1に設定して(S29)、S23に戻り、処理対象の店舗が残っていない場合には(S28:N)、店舗情報提供サーバ500は、それまでに店舗、ユーザの組に関連づけて記憶された判定結果に基づいて、各店舗の退席予測情報を生成する(S30)。そして、店舗情報提供サーバ500は、生成した退席予測情報を携帯端末200等のクライアント装置に対して提供する(S31)。
【0046】
図9には、退席予測情報に基づき表示される店舗状況表示画面の一例を示した。
図9に示される例では、指定された検索条件に合致した各店舗について、退席しそうな状態にあると判定されたユーザの数(白丸の数に対応)と、退席しそうな状態にないと判定されたユーザの数(黒丸の数に対応)に応じた店舗状況が表示される。これにより、ユーザは各店舗においてどの程度のユーザが退席しそうかを把握できる。なお、
図9に示した店舗状況表示画面は一例であり、他の態様で空き状況を表示することとしてもよい。
【0047】
以上が、店舗情報処理システム100において行われる処理の一連の流れである。次に、上記説明したシーケンスを実現するために店舗情報処理システム100の各装置に備えられる機能の一例について説明する。
【0048】
[携帯端末200の機能]
図10には、携帯端末200の機能ブロック図を示した。
図10に示されるように、携帯端末200は、表示部202、入力部204、メニュー情報取得部206、注文情報送信部208、決済情報受信部210、及び電子決済部212を備える。
【0049】
携帯端末200に備えられる上記各部の機能は、CPU等の制御手段、メモリ等の記憶手段、外部デバイスとデータを送受信する通信インターフェース等の通信手段、タッチパネル等の表示手段及び入力手段、電子マネー決済のためのICチップ等のハードウェアを備えたコンピュータが、コンピュータ読み取り可能な情報記憶媒体に格納されたプログラムを読み込み実行することで実現されることとしてよい。なお、プログラムは光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体によって携帯端末200に供給されることとしてもよいし、インターネット等のデータ通信網を介して携帯端末200に供給されることとしてもよい。
【0050】
表示部202は、例えばタッチパネル等により実現され、グラフィックイメージに基づいて画面を表示する。表示部202には、例えば
図3,
図4,
図5,
図6,
図7,
図9等に示した画面が表示される。
【0051】
入力部204は、例えばタッチパネルやボタン等を介してユーザからの操作入力を受け付ける。
【0052】
メニュー情報取得部206は、例えば受注サーバ300にアクセスして、入力部204からの入力に基づいて指定された店舗のメニュー情報を取得する。また、メニュー情報取得部206は、メニュー情報とともに、当該メニュー情報に基づいて受注サーバ300に注文を実行するためのアプリケーションを取得しインストールすることとしてもよい。
【0053】
注文情報送信部208は、メニュー情報取得部206により取得されたメニュー情報の中から選択されたメニューに係る注文情報を生成して受注サーバ300に送信する。注文するメニューの選択は、メニュー情報に基づき表示部202に表示されたメニュー画面に従って行われることとしてよい。また、注文情報には、例えば、注文に係るユーザID、メニューID、注文数量、店舗ID、ユーザの座席を識別するテーブル識別情報を含むこととしてよい。
【0054】
決済情報受信部210は、注文情報送信部208により送信した注文情報に対する決済情報を決済サーバ400から受信する。決済情報は、電子決済を開始するための情報であり、例えば決済に係る注文情報と決済金額とを含むこととしてよい。本実施形態では、携帯端末200は電子決済を電子マネーにより行うこととするが、クレジットカード決済等の他の電子決済を行うこととしてもよい。また、決済情報受信部210は、決済情報を受信サーバ300から受信するようにしてもよい。なお、決済情報には、受注サーバ300により発行されたトークンを含むこととしてよい。
【0055】
電子決済部212は、決済情報受信部210により受信した決済情報に基づいて電子決済を実行する。なお、電子決済を電子マネーにより行う場合には、携帯端末200に保持される電子マネーの残高から決済情報に係る決済金額を減算することとし、残高が決済金額以上である場合には電子決済が正常に完了し、残高が決済金額未満である場合にはエラーとなる。そして、電子決済部212による電子決済の実行結果は決済サーバ400に通知される。
【0056】
[受注サーバ300の機能]
次に、受注サーバ300に備えられた機能について説明する。
図11には、受注サーバ300の機能ブロック図を示した。
図11に示されるように、受注サーバ300は、ユーザ情報記憶部302、メニュー情報記憶部304、メニュー情報提供部306、注文情報受信部308、決済依頼部310、決済完了通知受信部312、注文処理部314、及び注文実績情報提供部316を備える。
【0057】
受注サーバ300に備えられる上記各部の機能は、CPU等の制御手段、メモリ等の記憶手段、外部デバイスとデータを送受信する通信インターフェース等の通信手段等のハードウェアを備えたコンピュータが、コンピュータ読み取り可能な情報記憶媒体に格納されたプログラムを読み込み実行することで実現されることとしてよい。なお、プログラムは光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体によって受注サーバ300に供給されることとしてもよいし、インターネット等のデータ通信網を介して受注サーバ300に供給されることとしてもよい。
【0058】
ユーザ情報記憶部302は、ユーザのアカウント情報を記憶する。
図12には、ユーザ情報記憶部302に記憶されるユーザ情報テーブルの一例を示した。
図12に示したユーザ情報テーブルの例では、ユーザID、パスワード、ユーザのメールアドレス、ユーザの生年月日、ユーザの性別がそれぞれ関連づけて記憶される。もちろん、ユーザ情報テーブルに記憶される情報は上記の例に限定されない。
【0059】
メニュー情報記憶部304は、1又は複数のそれぞれの店舗で提供されるメニュー情報を記憶する。
図13には、メニュー情報記憶部304に記憶されるメニュー情報テーブルの一例を示した。
図13に示したメニュー情報テーブルでは、店舗を識別する店舗IDごとに、当該店舗で提供されるそれぞれのメニューの情報が記憶される。なお、メニューの情報は、メニューID、メニュー名、金額、イメージ(URL)、カロリー等を含むこととするが、これに限定されない。
【0060】
メニュー情報提供部306は、携帯端末200から要求された店舗IDについてメニュー情報記憶部304に記憶されるメニュー情報を当該携帯端末200に提供する。また、メニュー情報提供部306は、メニュー情報と共に、当該メニュー情報に基づいて注文するためのアプリケーションを携帯端末200に提供することとしてもよい。
【0061】
注文情報受信部308は、携帯端末200の注文情報送信部208から送信された注文情報を受信する。例えば、注文情報には、ユーザID、メニューID、注文数量、店舗ID、ユーザのテーブルを識別するテーブル識別情報を含むこととするが、これに限定されない。
【0062】
決済依頼部310は、注文情報受信部308により受信した注文情報についての決済を決済サーバ400に依頼する。例えば、決済依頼部310は、注文情報受信部308により受信した注文情報ごとに、当該注文情報を識別する注文IDを付与するとともに、当該注文情報に係る決済金額を算出する。決済金額の算出は、メニュー情報記憶部304に記憶されるメニューIDに関連づけられた金額に注文数量を掛け合わせたものの合計額を算出することで行うこととしてよい。そして、決済依頼部310は、例えば注文ID、注文情報、決済金額、決済を行うユーザのメールアドレスを含む決済依頼情報を決済サーバ400に送信する。なお、上記のメールアドレスには、注文情報に含まれるユーザIDに関連づけてユーザ情報記憶部302に記憶されるメールアドレスを用いることとしてよい。
【0063】
決済結果受信部は、決済依頼部310により決済サーバ400に依頼した決済の結果を、決済サーバ400から受信する。決済の結果は、例えば、注文IDと、決済の結果を示す真偽値を含むこととしてよい。なお、決済が正常に完了した場合には真(T)、決済が正常に完了しなかった場合には偽(F)とする。
【0064】
注文処理部314は、決済結果受信部により受信した決済結果が正常完了を示す注文情報について、当該注文情報に係る店舗IDに応じた店舗端末600に注文情報を送信する。店舗側では、店舗端末600で受信した注文情報に従ってユーザに当該注文情報に係るメニューが提供される。
【0065】
注文実績情報提供部316は、注文処理部314により処理した注文情報について注文実績情報を生成し、生成した注文実績情報を店舗情報提供サーバ500に提供する。注文実績情報には、例えば注文ID、ユーザID、ユーザ属性情報(年齢、性別等)、店舗ID、メニューID、注文数量、決済金額、メニュー属性情報(カロリー等)、注文時間、テーブル識別情報等を含むこととするが、これに限定されない。
【0066】
[決済サーバ400の機能]
次に、決済サーバ400に備えられた機能について説明する。
図14には、決済サーバ400の機能ブロック図を示した。
図14に示されるように、決済サーバ400は、決済依頼受付部402、決済情報送信部404、決済完了判定部406、及び決済結果通知部408を備える。
【0067】
決済サーバ400に備えられる上記各部の機能は、CPU等の制御手段、メモリ等の記憶手段、外部デバイスとデータを送受信する通信インターフェース等の通信手段等のハードウェアを備えたコンピュータが、コンピュータ読み取り可能な情報記憶媒体に格納されたプログラムを読み込み実行することで実現されることとしてよい。なお、プログラムは光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体によって決済サーバ400に供給されることとしてもよいし、インターネット等のデータ通信網を介して決済サーバ400に供給されることとしてもよい。
【0068】
決済依頼受付部402は、受注サーバ300から決済依頼を受け付ける。具体的には、決済依頼受付部402は、受注サーバ300の決済依頼部310により送信された決済依頼情報を受信する。なお、決済依頼情報には、例えば注文ID、注文情報、決済金額、メールアドレスを含むこととするが、これに限定されない。
【0069】
決済情報送信部404は、決済依頼受付部402で受け付けた決済依頼情報に基づいて生成した決済開始メールを、当該決済依頼情報に含まれるメールアドレスに宛てて送信する。決済開始メールには、例えば決済ID、注文情報に基づく注文内容、決済金額を含むこととするが、これに限定されない。なお、決済サーバ400においては、決済IDと対応する注文IDとを関連づけて記憶しておくこことしてよい。
【0070】
決済完了判定部406は、決済情報送信部404により送信した決済開始メールに基づいて携帯端末200により電子決済が正常に行われたか否かを判定する。例えば、決済完了判定部406は、携帯端末200から受信した決済ID、電子決済に用いた電子マネーID、及び決済の正否の情報に基づいて決済完了の正否を判定することとしてよい。
【0071】
決済結果通知部408は、決済完了判定部406による判定結果を受注サーバ300に通知する。具体的には、決済IDに関連づけて記憶された注文IDと、当該決済IDの決済結果(例えば正常に完了した場合には真、エラーが発生した場合には偽)を受注サーバ300に通知することとしてよい。
【0072】
[店舗情報提供サーバ500の機能]
次に、店舗情報提供サーバ500に備えられた機能について説明する。
図15には、店舗情報提供サーバ500の機能ブロック図を示した。
図15に示されるように、店舗情報提供サーバ500は、注文実績情報取得部502、注文実績情報記憶部504、判定対象抽出部506、判定条件記憶部508、判定条件設定部510、人数推定部512、判定条件取得部514、判定部516、退席予測情報生成部518、及び退席予測情報提供部520を備える。
【0073】
店舗情報提供サーバ500に備えられる上記各部の機能は、CPU等の制御手段、メモリ等の記憶手段、外部デバイスとデータを送受信する通信インターフェース等の通信手段等のハードウェアを備えたコンピュータが、コンピュータ読み取り可能な情報記憶媒体に格納されたプログラムを読み込み実行することで実現されることとしてよい。なお、プログラムは光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体によって店舗情報提供サーバ500に供給されることとしてもよいし、インターネット等のデータ通信網を介して店舗情報提供サーバ500に供給されることとしてもよい。
【0074】
注文実績情報取得部502は、受注サーバ300の注文実績情報提供部316から提供される注文実績情報を取得する。なお、注文実績情報取得部502は、定期的に受注サーバ300に注文実績情報の提供を要求するようにしてもよい。注文実績情報には、例えば注文ID、ユーザID、ユーザ属性情報(年齢、性別等)、店舗ID、メニューID、注文数量、決済金額、メニュー属性情報(カロリー等)、注文時間、テーブル識別情報等が含まれることとするが、これに限定されない。
【0075】
注文実績情報記憶部504は、注文実績情報取得部502により順次取得される注文実績情報を記憶する。
図16には、注文実績情報記憶部504に記憶される注文履歴テーブルの一例を示した。
図16に示す注文履歴テーブルの例では、注文ID、ユーザID、ユーザの年齢、ユーザの性別、店舗ID、メニューID、注文数量、決済金額、カロリー(当該注文に係る総カロリー)、注文時間、テーブル識別情報が格納されることとするが、これに限定されない。
【0076】
判定対象抽出部506は、注文実績情報記憶部504から対象の店舗IDとユーザIDとを含む注文実績情報であって、所定条件を満足する注文実績情報を1つのグループとして抽出する。ここで、対象の店舗IDとユーザIDは、注文実績情報記憶部504に記憶される店舗IDとユーザIDのいずれかとしてもよいし、注文実績情報取得部502により新たに取得された注文実績情報に係る店舗IDとユーザIDとしてもよい。また、上記の所定条件とは、例えば、注文実績情報の注文時間が現時点から第1の時間範囲内(例えば6時間以内等)にあること、又は、それに加えて、前後する少なくとも一方の注文に係る注文時間が第2の時間範囲内(例えば30分以内等)にあること等としてよい。これにより、対象ユーザの対象店舗における1回の飲食に係る注文実績情報を1つのグループとして抽出することができる。
【0077】
判定条件記憶部508は、少なくともユーザ、ユーザの属性情報、店舗、又は店舗の属性情報のいずれかに関連づけて記憶した判定条件であって、当該ユーザの注文実績に基づいて当該ユーザが当該店舗を退席しそうな状態にあるか否かを判定するための判定条件を記憶する。以下、判定条件につき具体例を挙げて説明する。
【0078】
図17A〜
図17Dには、判定条件記憶部508に記憶される判定条件の一例を示した。
【0079】
図17Aには、1グループの注文実績情報による注文金額の合計が閾値に達したか否かにより、ユーザが退席しそうか否かを判定する判定条件(タイプA)の一例を示した。
図17Aに示される判定条件テーブルの例では、判定条件を識別する判定条件ID、条件検索キー(ユーザID、ユーザ属性、店舗ID、店舗属性)、条件パラメータ(時間帯・季節、人数・性別)、判定条件が関連づけて記憶される。判定条件は、例えば、1グループの注文実績情報による注文金額の合計をS
a、閾値Th
a、αを加算又は減算パラメータ、wを重みとした場合に、S
a>w(Th
a+α)として表す。これは、S
a>w(Th
a+α)を満たす場合に、ユーザが退席しそうな状態にあると判定することを示す。なお、α及びwは条件パラメータに基づいて設定することとしてよく、例えば、αは時間帯や季節ごとに値を設定し、wは人数又は性別に応じて設定する(例えばw=ユーザを含む同席人数・性別因子(男性なら1、女性なら0.8)等)こととしてよい。また、条件検索キーは、ユーザID、ユーザ属性、店舗ID、店舗属性のうち、値が格納されているユーザID、ユーザ属性、店舗ID、店舗属性の組み合わせについての判定条件であることを示す。すなわち、判定条件A001は、ユーザID(U001)と店舗ID(S001)についての判定条件であり、判定条件A002は、ユーザID(001)とカテゴリが「居酒屋」の店舗についての判定条件である。
【0080】
図17Bには、1グループの注文実績情報による摂取カロリーの合計が閾値に達したか否かにより、ユーザが退席しそうか否かを判定する判定条件(タイプB)の一例を示した。
図17Bに示される判定条件テーブルの例では、判定条件を識別する判定条件ID、条件検索キー(ユーザID、ユーザ属性、店舗ID、店舗属性)、条件パラメータ(時間帯・季節、人数・性別)、判定条件を関連づけて記憶している。判定条件は、例えば、1グループの注文実績情報による摂取カロリーの合計をS
b、閾値Th
b、αを加算又は減算パラメータ、wを重みとした場合に、S
b>w(Th
b+α)として表す。これは、S
b>w(Th
b+α)を満たす場合に、ユーザが退席しそうな状態にあると判定することを示す。なお、α及びwは条件パラメータに基づいて設定することとしてよく、例えば、αには時間帯や季節ごとにおける基準からの変動量を設定し、wは人数に応じて設定する(例えばw=ユーザを含む同席人数・性別因子(男性なら1、女性なら0.8)等)こととしてよい。また、条件検索キーは、ユーザID、ユーザ属性、店舗ID、店舗属性のうち、値が格納されているユーザID、ユーザ属性、店舗ID、店舗属性の組み合わせについての判定条件であることを示す。すなわち、判定条件B001は、ユーザID(U001)と店舗ID(S001)についての判定条件であり、判定条件B002は、ユーザID(001)とカテゴリが「居酒屋」の店舗についての判定条件である。
【0081】
図17Cには、1グループの注文実績情報における注文時間の時間間隔に基づいて、ユーザが退席しそうか否かを判定する判定条件(タイプC)の一例を示した。
図17Cに示される判定条件テーブルの例では、判定条件を識別する判定条件ID、条件検索キー(ユーザID、ユーザ属性、店舗ID、店舗属性)、条件パラメータ(時間帯)、判定条件を関連づけて記憶している。判定条件は、例えば、一連の注文における初回の注文時間をT1、最後の注文時間をTL、現在時刻をTPとした場合に、TP−T1>Th
c1+α(時間帯補正)、又はTP−TL>Th
c2+β(時間帯補正)とする。前者の条件は、初回注文時からの経過時間が閾値(Th
c1)+αを超えた場合にユーザが退席しそうな状態にあると判定することを示し、後者の条件は、最後の注文時からの経過時間が閾値(Th
c2)+βを超えた場合にユーザが退席しそうな状態にあると判定することを示す。
【0082】
図17Dには、1グループの注文実績情報から検出される注文パターンに基づいて、ユーザが退席しそうか否かを判定する判定条件(タイプD)の一例を示した。例えば、注文パターンは、注文されたメニューの順序を考慮した組み合わせとしてよい。
図17Dに示される判定条件テーブルの例では、判定条件を識別する判定条件ID、条件検索キー(ユーザID、ユーザ属性、店舗ID、店舗属性)、条件パラメータ(人数:w)、判定条件を関連づけて記憶している。判定条件を、例えば、アルコール飲料(数量X×w以上)、皿料理(数量Y×w以上)、ご飯もの(数量w以上)により表した場合には、1グループの注文実績情報により、上記各メニューが上記順序で注文された場合に、ユーザが退席しそうな状態にあると判定することとする。
【0083】
判定条件設定部510は、判定条件記憶部508に記憶される判定条件の内容を設定する。例えば、判定条件設定部510は、ユーザからの入力に基づいて判定条件を設定することとしてもよいし、注文実績情報記憶部504に記憶される過去の注文実績に基づいて判定条件を設定することとしてもよい。例えば、判定条件設定部510は、判定対象抽出部506により1つのグループとして抽出された注文実績情報に係るユーザID(又は当該ユーザIDと同一又は類似のユーザ属性)及び店舗ID(又は当該店舗IDと同一又は類似の店舗属性)について注文実績情報記憶部504に記憶される注文実績情報に基づいて判定条件を設定することとしてもよい。
【0084】
以下、判定条件設定部510が、過去の注文実績に基づいて判定条件を設定する一例について説明する。例えば、判定条件設定部510は、注文実績情報記憶部504に記憶されるユーザIDと店舗IDの組ごとに判定対象抽出部506により抽出された各グループの注文実績情報に基づいて、平均の決済金額や最大の決済金額、平均の摂取カロリーや最大の摂取カロリー、初回注文時からの平均滞在時間や最大滞在時間、最終注文時からの平均滞在時間や最大滞在時間、さらには注文パターンを求め、当該求めた各値や注文パターンに基づいて判定条件を設定することとしてよい。また、判定条件設定部510は、同様にユーザID、ユーザ属性、店舗ID、店舗属性の中から判定条件を設定する対象の要素を選択し、当該選択した要素を含む注文実績情報を注文実績情報記憶部504から抽出し、当該抽出した注文実績情報に基づいて、上記選択した要素についての判定条件を設定することとしてよい。
【0085】
人数推定部512は、判定対象抽出部506により1つのグループとして抽出された注文実績情報に係るユーザと同席している人数(ユーザを含める)を推定する。例えば、人数推定部512は、判定対象抽出部506により抽出された注文実績情報に含まれるテーブル識別情報に紐付けられた座席数を同席人数としてもよいし、1回又は複数回における注文実績情報における同一メニュー(例えばドリンク)の注文数量を同席人数としてもよい。また、人数推定部512は、判定対象抽出部506により抽出された注文実績情報に係るユーザIDについて注文実績情報記憶部504に記憶される過去の注文実績情報について推定された人数(例えばその平均値)に基づいて同席人数を推定してもよい。
【0086】
判定条件取得部514は、判定対象抽出部506により1つのグループとして抽出された注文実績情報に基づいて、判定条件記憶部508から適用する判定条件(適用判定条件)を取得する。例えば、判定条件取得部514は、タイプA〜Dの判定条件の少なくとも1つについて、(優先順位1)1グループの注文実績情報に含まれるユーザIDと店舗IDとの組み合わせについて設定された判定条件、(優先順位2)上記ユーザIDと、上記店舗IDの店舗属性との組み合わせについて設定された判定条件、(優先順位3)上記ユーザIDのユーザ属性と、上記店舗IDとの組み合わせについて設定された判定条件、(優先順位4)上記ユーザIDのユーザ属性と、上記店舗IDの店舗属性との組み合わせについて設定された判定条件、(優先順位5)上記ユーザID又はそのユーザ属性について設定された判定条件、(優先順位6)上記店舗ID又はその店舗属性に設定された判定条件を判定条件記憶部508から検索し、その最上位の優先順位のものを適用判定条件として取得することとしてよい。また、タイプA〜Dにも優先順位を設定することとしてもよく、優先順位も上記の例に限られるものではない。また、判定条件取得部514は、判定対象抽出部506により抽出された各グループの注文実績情報について、適用判定条件をそれぞれ取得することとする。
【0087】
判定部516は、判定対象抽出部506により1つのグループとして抽出された注文実績情報が、判定条件取得部514により取得された適用判定条件を満足するか否かに基づいて、当該注文実績情報に係るユーザが、当該注文実績情報に係る店舗から退席しそうな状態にあるか否かを判定する。また、判定部516は、判定条件取得部514により取得された適用判定条件が複数ある場合には(例えばタイプA〜Dのそれぞれの判定条件が得られた場合等)、それら複数の適用判定条件のいずれかが満足された場合に、ユーザが店舗から退席しそうな状態にあると判定することとしてもよいし、それらの全てが満足された場合に、ユーザが店舗から退席しそうな状態にあると判定することとしてもよい。また、判定部516は、複数の適用判定条件のうちいくつ満足したかに応じて、退席可能性のレベルを判定することとしても構わない。そして、判定部516は、判定対象抽出部506により抽出された各グループの注文実績情報について、上記の判定を行うこととしてよい。
【0088】
なお、判定対象抽出部506により1つのグループとして抽出された注文実績情報には、そのグループを示すグループIDを関連付けて記憶することとしてよい。また、グループごとの注文実績情報を抽出処理は、判定対象抽出部506により判定対象として抽出された注文実績情報以外の過去の注文実績情報についても、判定対象の注文実績情報の抽出後又はその前に実行することとしてよい。例えば、注文実績情報記憶部504に、判定対象の注文実績情報以外に、判定対象の注文実績情報に含まれる店舗ID(対象店舗ID)及びユーザID(対象ユーザID)を含む注文実績情報が記憶される場合には、その注文実績情報をグループ化した各々(又はその少なくとも1グループ)を過去の注文実績情報として抽出することとしてよい。そして、注文実績情報記憶部504に、判定対象の注文実績情報以外に、対象店舗ID及び対象ユーザIDを含む注文実績情報が記憶されない場合には、対象ユーザIDのユーザと属性(例えば年齢や性別)が同一又は類似の類似ユーザIDと対象店舗IDを含む注文実績情報を検索し、検索された注文実績情報をグループ化した各々(又はその少なくとも1グループ)を過去の注文実績情報として抽出することとしてよい。さらに、対象店舗IDと類似ユーザIDを含む注文実績情報が検索されなかった場合には、対象店舗IDを含む注文実績情報をグループ化した各々(又はその少なくとも1グループ)を過去の注文実績情報として抽出することとしてよい。そして、判定条件設定部510は、上記抽出した過去の注文実績情報に基づいて、判定対象の注文実績情報を判定するための判定条件を設定することとしてよい。
【0089】
退席予測情報生成部518は、判定対象抽出部506により1つのグループとして抽出された注文実績情報ごとの判定部516による判定結果に基づいて、それぞれの店舗についての退席予測情報を生成する。以下、1つの店舗(対象店舗)について生成される退席予測情報の一例について説明する。
【0090】
退席予測情報生成部518は、対象店舗の店舗IDを含む注文実績情報のグループごとに判定部516による判定結果を集計する。すなわち、対象店舗について退席しそうと判定されたユーザ数と、退席しそうと判定されなかったユーザ数とをそれぞれ集計し、それらの数又は比に基づいて退席予測情報を生成する。例えば、退席予測情報は、店舗において退席しそうと判定されたユーザ数、退席しそうと判定されたユーザのいるテーブルの比率、退席しそうと判定されたユーザ数と退席しそうと判定されなかったユーザ数との比較結果等を表示するデータとして生成することとしてよい。また、退席予測情報には、退席しそうと判定されたユーザ数と、退席しそうと判定されなかったユーザ数の差や比に予測待ち時間を予め関連づけておいて、対象店舗について集計された退席しそうと判定されたユーザ数と、退席しそうと判定されなかったユーザ数との差や比に基づいて予測待ち時間を決定し、当該決定した予測待ち時間を退席予測情報に含めることとしてもよい。
【0091】
退席予測情報提供部520は、店舗ごとに生成された退席予測情報を提供する。例えば、退席予測情報提供部520は、クライアント装置から指定された店舗について、退席予測情報生成部518により生成された退席予測情報を提供することとしてもよいし、店舗の退席予測情報の提供ページに、各店舗の退席予測情報の一覧を掲載して提供することとしてもよい。
【0092】
以上説明した、本実施形態に係る店舗情報処理システム100によれば、店舗内のユーザから受け付けた注文情報を利用して各ユーザが店舗から退席しそうな状態にあるか否かを判定し、その判定結果に基づいて店舗内の客席の空き状況に関する情報を提供できる。ユーザはこうした情報を利用することで、店舗の混雑状況やおおよその待ち時間をリアルタイムで把握できる。また、ユーザが店舗から退席しそうな状態にあるか否かを判定するための判定条件を、過去の注文実績に基づいて設定することもできる。
【0093】
本発明は上記の実施形態に限定されるものではない。例えば、上記の実施形態では、携帯端末200は受注サーバ300から店舗のメニュー情報を取得することとしたが、店舗端末600、店舗情報提供サーバ500等から取得するようにしてもよい。
【0094】
また、上記の実施形態では、受注サーバ300、決済サーバ400、店舗情報提供サーバ500を分けて構成する例を示したが、これらのサーバの少なくとも一部を統合してもよいし、それぞれのサーバに備えられた機能を複数台のサーバにさらに分散して構成してもよい。
【0095】
また、上記の実施形態では、受注サーバ300にユーザの情報を記憶しておくこととしたが、決済サーバ400において電子マネーのIDに対応付けてユーザの情報(名前、年齢、性別等)を記憶し、決済時に用いられる電子マネーのIDに基づいてユーザの情報を特定することとしてもよい。
【0096】
また、上記の実施形態では、例としてタイプA〜Dの判定条件を示したが、判定条件はこれら複数のタイプの判定条件を組み合わせて構成することとしてもよいし、上記実施形態では例示されなかったタイプの判定条件をさらに加えることとしてもよい。