JP2019091115A - 情報処理装置 - Google Patents

Abstract

【課題】おすすめ料理の動的な提案により顧客満足度を向上させること。【解決手段】ユーザの入店からの経過時間に基づいて統計的に１以上のおすすめ料理候補を選択し、選択されたおすすめ料理候補の中からユーザ入店後に注文された料理と前記おすすめ料理候補との相関に基づいて１以上のおすすめ料理を動的に決定し、決定したおすすめ料理をユーザに提示するための表示情報を生成する制御部を具備する情報処理装置。【選択図】図８

Description

本技術は、情報処理装置に関し、特に、飲食店の来店客に情報を提示するための技術に関する。

レストランや居酒屋などの飲食店では、おすすめ品を来店客に提示する場合、おすすめ品の情報が記載されたポスターを店舗内に掲示するなどの方法が従来行われている。しかしながら、ポスター掲示による方法ではおすすめ料理の変更に柔軟に対応できなかった。

特許文献１には、販促メニューの製作時間とコストの低減を目的として、ディスプレイ端末に注文履歴や顧客属性に基づいて作成した販促メニューを表示する技術が開示されている。

特許文献２には、客に対して効率よく注文を促すことを目的として、飲食注文端末毎の商品推奨のタイミングを、飲食注文端末毎の飲食経過時間を計時し、計時した飲食経過時間に基づいて判定する技術が開示されている。

特許文献３には、店員の携帯するハンディオーダ端末にテーブル毎の客単価を表示することで、店員による注文取りを促すことが記載されている。また、同一客単価帯のテーブルが複数ある場合には、テーブル毎の滞在時間を提示することで、どのテーブルに優先的に注文を取りに行けばよいのかを示すことも記載されている。

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

おすすめ料理の提案は店員の裁量に任されていることが多いが、店員がユーザとのコミュニケーションに時間を割けない状況があると、適切な提案ができない。これに対して、ポスレジ・システムを利用しておすすめ料理を提案する場合、提案が単調になるという問題点がある。ユーザの食べたいものや飲みたいものは、飲食店への入店後、時々刻々と変化する。

これらの事情に鑑み、本発明は、おすすめ料理の動的な提案により顧客満足度を向上させることを目的とする。

上記目的を達成する本発明に係る一態様は、制御部を具備する情報処理装置である。
上記制御部は、ユーザの入店からの経過時間に基づいて統計的に１以上のおすすめ料理候補を選択する。
上記制御部は、選択されたおすすめ料理候補の中からユーザ入店後に注文された料理と上記おすすめ料理候補との相関に基づいて１以上のおすすめ料理を動的に決定する。
上記制御部は、決定したおすすめ料理をユーザに提示するための表示情報を生成する制御部を具備する。

上記ユーザは、料理が提供される飲食店の来店客を含む。なお、ユーザは２人以上の複数であってもよく、グループとして捉える場合はユーザグループと呼ぶ。
上記料理には飲食店が提供可能な飲食物を含み、したがって、アルコール飲料やソフトドリンク類も含む。
上記情報処理装置は、飲食店の内部に設置されたコンピュータとして実施されてもよいし、外部に設置されたサーバとして実施されてもよく、その実施の態様に特別の限定はない。上記情報処理装置が飲食店のテーブルの上や傍に設置された注文受付機能を備えたセルフオーダー端末や、デジタルサイネージであるような態様も一例として挙げられる。
上記表示情報は、例えばスマートフォンに表示される画面や、デジタルサイネージの画面でもよい。表示情報を実際に表示する表示装置について限定はしない。表示情報は例えばマークアップランゲージによりコーディングされた情報でもよいし、その他の方法により生成された情報であってもよい。

上記情報処理装置によれば、ユーザの入店後の注文に応じて動的に変化するおすすめ料理が、入店からの経過時間に基づいて判断される適切なタイミングで提案されるため、おすすめ料理の動的な提案が実現し、顧客満足度を向上させることができる。

上記情報処理装置において、上記制御部は、上記経過時間に基づいて食事の終了が予想される時間が近づいてきたタイミングで、注文品の累計が所定の金額に、到達したか否かを判定し、到達していない場合にもう一品追加の提案をしてもよい。

上記構成における所定の金額は、例えば、ユーザグループの人数と、想定される一人当たりの客単価とを乗算した金額でもよい。

上記構成によれば、ユーザ又はユーザグループが享受したサービスが、飲食店の提供可能なサービスの標準的な水準に未だ達していないような場合に、もう一品追加の料理の提案をすることができるので、顧客満足度を向上させることができる。

上記情報処理装置において、上記制御部は、上記相関を料理に紐付けされるメタデータに基づいて決定してもよい。

上記メタデータは、限定するものではないが、例えば、カロリーや食材、調理法などのデータが含まれる。例えば、食材と調理法が共通する２つの料理が両方とも注文される例が統計的に少ないことが、あらかじめわかっている場合、２つの料理には負の相関がある。制御部は、メタデータに基づいて、このような負の相関があると決定（判断）する。逆に、一方の料理が注文された場合、他方の料理も注文されやすいような料理のペアには、正の相関があると決定（判断）する。制御部は、「ユーザ入店後に注文された料理」に対して「おすすめ料理候補」が負の相関を持つ場合にはおすすめ料理にすることに対して消極的になるような情報処理をしてもよい。また、逆の場合にはおすすめ料理にすることに対して積極的になるような情報処理をしてもよい。

上記構成によれば、おすすめ料理をユーザの入店後の注文に応じて動的に変化させる具体的方法を提供することができる。

上記情報処理装置において、上記制御部は、提示したおすすめ料理をユーザが選択した場合に提案に乗ったと判断し、おすすめ料理の提案の処理を積極的に実行してもよい。

おすすめ料理の提示を見て当該料理を注文したユーザは、おすすめ情報に対する感度が高いものと考えられる。このようなユーザに対しては、飲食サービス提供側からの情報提供を積極的に行うことが顧客満足度の向上につながる。ここで「積極的に実行する」には、提案頻度を上げる、おすすめ情報の表示強度を上げる（目立つようにする）、などの態様が含まれる。

上記構成によれば、おすすめ情報への感度の高いユーザに対しては情報提供が積極的になされるので、さらに顧客満足度を向上させることができる。

上記情報処理装置において、上記制御部は、上記入店時刻からの経過時間及び／又は滞在時間帯をパラメータにした統計的情報に基づくおすすめ料理候補の選択を行ってもよい。

例えばフレンチレストランを例に取るとアラカルトで注文を受ける場合、前菜として注文される料理、デセールとして注文される料理がある、入店時間からの経過時間と注文ニーズとの間に相関が認められる場合がある。上記統計的情報は、例えば、上記情報処理装置が設置される飲食店において過去に注文された料理の履歴データベースとすることができる。この履歴データベースは、「入店からの経過時間」と「滞在時間帯」をパラメータに有することが好ましく、例えば、入店後例えば１０分経過した時点の注文頻度を料理ごとに有するといったようなデータ構造にしてもよい。

上記構成によれば、おすすめ料理候補の選択を行う情報処理を具体的に提供することができる。

上記情報処理装置において、上記制御部は、ユーザから注文を受けた時刻を少なくとも一時的に記憶し、記憶した複数の時刻の間隔に係る注文間隔に応じて、おすすめ料理の決定頻度を変更してもよい。

上記決定頻度の変更においては、料理の注文間隔が狭いユーザに対して頻繁におすすめ料理を提示するようにしてもよい。逆に、注文間隔が広いユーザに対しては頻繁なおすすめ料理の提示を抑制してもよい。あるいは、注文間隔が広いユーザに対しては、入店からの経過時間が所定の時間が経つ前であっても、上記所定の時間の後におすすめ料理候補として選択される料理の中からおすすめ料理候補が選択されるようにしてもよい。この場合、所定の時間としては、例えばデザートや食後の口直しをおすすめ料理として提示することを開始する時間とすることができる。

上記構成によれば、注文間隔によりユーザの空腹度合いを推し量ることができ、これに応じた頻度の変更を行うことで適切なおすすめ料理の提案が可能になる。

上記情報処理装置において、上記制御部は、提案することが決定したおすすめ料理に係る第１の料理を第１のタイミングで提案すると、上記第１の料理の提供が上記第１の料理とは異なる注文済みの第２の料理の提供と同時になる場合、上記第１の料理を第１のタイミングよりも遅い第２のタイミングで提案してもよい。

上記構成によれば、第１の料理と第２の料理の提供が同時にならないようにすることにより、適切なタイミングでのおすすめ料理の提案が可能になる。

上記情報処理装置において、上記制御部は、入店からの経過時間に基づいて第１の時間帯に選択されるおすすめ料理候補に該当する料理が、上記第１の時間帯よりも前に注文された場合、上記経過時間が上記第１の時間帯よりも前の第２の時間帯に入っているか否かに関わらず、上記第２の時間帯に選択されるおすすめ料理候補からおすすめ料理を決定してもよい。

上記第１の時間帯は、限定するものではないが、例えば、食事の最後のほうの時間帯にしてもよい。この場合、居酒屋で「〆の料理」と呼ばれる料理やデザートなどが注文されがちな時間帯にすることができる。上記第１の時間帯は、例えば、飲食店に来店した過去のユーザの平均的な滞在時間から導き出されたものでもよく、例えば、平均滞在時間が１２０分の場合入店後９０分から１２０分までの時間帯を第１の時間帯としてもよい。
上記第２の時間帯は、上記第１の時間帯よりも時間的に先に位置する時間帯である。上記第１の時間帯よりも前の時間帯の全部又は一部としてもよい。例えば、入店後３０分から９０分までの時間帯を第２の時間帯としてもよい。

上記構成によれば、第１の時間帯におすすめ料理候補として選択されるような料理が、第１の時間帯よりも前の時間において注文されたような場合に、第１の時間帯よりも前の時間帯（第２の時間帯）におすすめ料理候補として選択されるような料理を、第２の時間帯でなくてもおすすめ料理として決定し、提案する情報処理が行われることによって、飲食店が本来、大きな満足を与えることができるはずの料理を享受する機会を逃さないように、ユーザに提案することができる。その結果として、顧客満足度を向上させることができる。
例えば、「〆の料理」やデザートなどをユーザが比較的早期に注文した場合、ユーザは本来その店舗で楽しむことができる目玉料理を食べ逃してしまう可能性があったが、上記情報処理装置によれば、そのような可能性を低減させることができ、顧客満足度の向上につながる。

上記情報処理装置において、上記制御部は、入店してからユーザが注文した酒類の履歴と、注文した料理との相関とに基づいて、提案する酒類を決定してもよい。

飲食店は特定の銘柄の日本酒に合う料理を開発したり、特定の料理に合うワインを特別に選定したりする場合があり、酒類に関しては特定の料理との結びつきが強い場合がある。

上記情報処理装置によれば、そのような酒類に関する飲食店の強いこだわりを、おすすめ料理に反映することができる。

上記情報処理装置において、上記制御部は、調理時間が所定の第１の時間を越える料理をおすすめ料理候補とする場合、入店からの経過時間に調理時間及び／又はサーブまでの時間を加えた時間が、所定の第２の時間を越えない場合にのみ、上記調理時間が上記第１の時間を越える料理をおすすめ料理候補としてもよい。

上記構成によれば、上記調理時間が上記第１の時間を越える料理については、おすすめ料理候補とするにあたって入店からの経過時間が遅くなりすぎないように考慮がなされ、これにより、顧客満足度を向上させることができる。

上記情報処理装置において、上記制御部は、上記調理時間が上記第１の時間を越える料理が注文されると、上記調理時間が上記第１の時間を越える料理がユーザに提供されるまでの時間内に提供可能な料理を、優先的におすすめ料理候補としてもよい。

上記構成によれば、上記調理時間が上記第１の時間を越える料理が注文された場合においては、ユーザを待たせている比較的長い時間の間に、提供可能な料理をユーザに提案することによって、顧客満足度を向上させることができる。

上記情報処理装置は、さらに、おすすめ料理の提案を店員の操作する可搬型端末に出力する出力部を有してもよい。
上記情報処理装置によれば、店員の可搬型端末に表示情報を出力することができる。

以上に説明したように、本発明によれば、おすすめ料理の動的な提案が実現し、顧客満足度が向上する。

本発明に係る一実施形態のシステム構成を示す図である。 上記実施形態に係る店舗端末のハードウェア構成例を示す図である。 上記実施形態に係る記憶部が記憶する各種データの構成例を示す図である。 上記実施形態に係る料理情報データベースの構成を説明するための模式図である。 上記実施形態に係る売上情報データベースの構成を説明するための模式図である。 上記実施形態に係る売上情報データベースに基づく情報を説明するための図である。 上記実施形態に係る注文情報データベースの構成を説明するための模式図である。 上記実施形態に係る料理情報提供システムの動作を説明するための図である。 上記実施形態に係る店舗端末の情報処理を説明するための図である。 上記実施形態における注文済み料理とおすすめ料理候補との相関に基づく決定処理を説明するための模式図である。 上記実施形態におけるおすすめ料理情報を提供するタイミングについて説明するための図である。 上記実施形態に係る店舗端末の情報処理を説明するための図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［システムの構成］
図１は、本実施形態に係る料理情報提供システム１の構成を示した図である。同図に示すように、本実施形態に係る料理情報提供システム１は、飲食店の店舗内で完結したシステムであり、店舗端末１００とユーザ端末２００と従業員端末３００を含む。なお、図１のシステム構成例は一例に過ぎず、店舗内で完結したシステムにしない実施も可能である。また、従業員端末３００は必ずしも必要ではない。

本実施形態に係る制御部が構成される店舗端末１００は、汎用のコンピュータを利用した端末として構成することができる。店舗端末１００は、おすすめ料理情報をユーザ端末２００に送信する。なお、ネットワークの態様はどのようなものでもよいが、例えば、無線ローカルエリアネットワークによるものが利用できる。

ユーザ端末２００も、汎用のコンピュータを利用した端末として構成することができるが、例えば、スマートデバイスやタブレット型端末などのデバイスを利用してもよい。図１中には、店舗内のテーブル席に据え置きされる注文受付（セルフオーダー）機能も備えた卓上端末２００ａが示されている。また、ユーザが個人的に持っているスマートフォンをユーザ端末２００として利用してもよい。図１中には、ユーザが有するスマートフォン２００ｂが示されている。ユーザ端末２００は表示装置と通信装置を備え、ユーザにおすすめ料理情報を表示装置に表示する。

本実施形態において、店舗端末１００に注文情報を送信するデバイスとしては、ユーザ端末２００のほかに、従業員端末３００がある。従業員端末３００は、ユーザ（来店客）から注文を聞き取った従業員（ホール係）が操作入力した料理の注文に係る情報を店舗端末１００に送信する。このように、注文情報の入力は、ユーザ端末２００以外の装置からも可能である。

なお、従業員がユーザ端末２００を操作してもよい。また、以下では、単に「ユーザ」と表記した場合、複数のユーザからなるグループを指すこともあることとする。

［店舗端末のハードウェア構成］
図２は、店舗端末１００のハードウェア構成を示した図である。同図に示すように、店舗端末１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながら各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic Electro-Luminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、その他の入力装置である。なお、表示部１６と操作受付部１７を液晶タッチパネルにより一つにまとめてもよい。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。

通信部１９は、例えばＮＩＣ（Network Interface Card）や無線ＬＡＮ等の無線通信用の各種モジュールである。通信部１９により本端末の他端末とのデータの送受信が可能になる。
なお、ユーザ端末２００のハードウェア構成も、上述の店舗端末１００と同様の構成としてもよい。

なお、上述のハードウェア構成を採用することで、複数のユーザ及び／又はユーザ端末からの注文情報を一元的に店舗端末１００に集めることができ、効率的な情報処理が可能になる。

［記憶部のデータ内容］
記憶部１８が記憶する各種データのうち、以下で説明する本実施形態の構成及び動作に関係するものについて説明する。

図３は、記憶部１８が記憶する各種データの構成例を示す図である。図３に示すように、記憶部１８は、料理情報データベース１８１と売上情報データベース１８２と注文情報データベース１８３を有している。各データベースは相互に関連付けがなされており、全体として一つのリレーショナルデータベースとして構築されている。なお、これは説明のための便宜的な一例であり、他の実施形態においては、リレーショナルデータベースとしなくてもよい。また、データベースと呼べるような規模のものではなく、単純な記憶テーブルのようなものでもよい。

料理情報データベース１８１は、図１の店舗で提供可能な各料理の情報が記憶されたデータベースである。ここで言う料理にはアルコールドリンクを含む。売上情報データベース１８２は、図１の店舗の過去の売上に関連する情報が記憶されたデータベースである。注文情報データベース１８３は、図１の店舗に来店中のユーザ（来店客）のした注文をユーザごとに記憶するデータベースである。

図４を参照して料理情報データベース１８１の記憶内容やデータ構造について説明する。図４は、料理情報データベース１８１の構成を説明するための模式図である。料理情報データベース１８１は、図４の模式図に示すように、店舗が提供可能な「料理」を中心に構成されていて、「料理」の名称や、分類、食材、相性のいい料理、相性のいいアルコールドリンク、相性の悪い料理、等々がメタデータとして「料理」に紐付けされて格納されている。以下では、このようなメタデータを「タグ」と呼び、紐付けのことを「タグ付け」と呼ぶことがある。

図４中に示す「分類」は、例えば、「アントレ／メインディッシュ／デザート」のような分け方に基づく分類でもよいし、「野菜料理／肉料理／海鮮料理」のような分類でもよい。一つの料理に異なる分け方に基づく複数の分類が紐付けられてもよい。なお、各料理に紐付けされるメタデータとしては、図示のもののほかに、例えば、カロリー量や、相性のいい料理の分類（例えば、「海鮮料理との相性がよい」といった情報が紐付く）などがあってもよい。

次に、図５を参照して、売上情報データベース１８２の記憶内容やデータ構造について説明する。売上情報データベース１８２は、図５に示すような相関テーブルを持つ。図５（ａ）に示されるテーブルは、ある料理の注文された数量とその時間帯の関係を記録するテーブルである。売上情報データベース１８２は、このような時間帯と注文数の相関テーブルを料理ごとに有する。

図５（ｂ）に示されるテーブルは、ある料理が注文された時間（ただし、この時間は入店してからの経過時間）と注文数の関係を記録するテーブルである。売上情報データベース１８２は、このような注文された時間と注文数の相関テーブルを料理ごとに有する。なお、図５（ａ），（ｂ）に例示したテーブルは、ユーザごとのデータであってもよい。

売上情報データベース１８２には図５（ｂ）に例示したようなデータが格納されているため、売上情報データベース１８２からは、入店からの経過時間に応じた注文頻度に係る情報が料理ごとに得られる。図６に、入店からの経過時間に応じた注文頻度に係る情報を模式的に示す。

図６に示すように、売上情報データベース１８２に基づくと、それぞれの料理が「入店からの経過時間が短く、比較的早期に注文されがちである」、あるいは、「おおむね多くのユーザが食事を終わりにする時間に注文されがちである」といった、各料理の注文傾向が把握される。店舗端末１００のＣＰＵ１１は、売上情報データベース１８２に記録されている売上と時間に関する各種相関に基づいて、料理ごとの注文傾向を判断する。なお、図６には、２つの料理についての情報だけが示されているが、売上情報データベース１８２からは店舗が提供可能な料理すべての当該頻度情報が抽出できる。

次に、図７を参照して、注文情報データベース１８３の記憶内容やデータ構造について説明する。注文情報データベース１８３は、図７に示すようなテーブルを有し、ユーザごとに入店からの経過時間と注文料理を記録している。注文情報データベース１８３は、ＲＡＭ１３上に構築されてもよい。

ＣＰＵ１１は、注文情報データベース１８３を参照して、ユーザが注文した料理とその注文がなされた時間（入店からの経過時間）を取得することができる。注文情報データベース１８３は、ユーザが入店した時刻もユーザごとに記憶する。したがって、ＣＰＵ１１は、ユーザが注文した料理とその注文がなされた時刻も取得することができる。

［システムの動作］
次に、上記料理情報提供システム１における料理情報提供の流れについて説明する。図８は、料理情報提供システム１で実行される情報処理の一例に係るシーケンス図である。図示のように、店舗端末１００は、ユーザが来店すると入店時刻を注文情報データベース１８３に記録する（ＳＴ１０）。なお、ユーザ来店は、従業員が従業員端末３００に来店を記録する操作を行うことにより店舗端末１００にユーザ来店を通知するような仕組みによって、店舗端末１００に把握される用に構成してもよい。

店舗端末１００は、所定のタイミングで表示情報を生成し、また、生成した表示情報をユーザ端末２００に送信（出力）する（ＳＴ１１，ＳＴ１２，ＳＴ１３）。他方で、ユーザ端末２００は、店舗端末１００から送信（出力）されてきた表示情報を、自端末の表示部で表示する（ＳＴ２１，ＳＴ２４，ＳＴ２５）。また、ユーザ所望のタイミングで、ユーザ端末２００は注文情報を店舗端末１００に対して送信（出力）する（ＳＴ２２，ＳＴ２３）。

なお、言うまでもないことであるが、図８に示したシーケンスは、一例であり、ユーザが注文をするタイミングにより注文情報の出力（ＳＴ２２，ＳＴ２３）が図８とは異なるタイミングで行われてもよい。ユーザ（来店客）の入店から退店までのあいだ、図８に示すような、表示情報の生成出力とその表示（例えば、ＳＴ１１とＳＴ２１のペア）と、ユーザ端末２００からの注文情報の出力（例えば、ＳＴ２２，ＳＴ２３）が繰り返される。

料理情報提供システム１における料理情報提供に係る情報処理は、ユーザが退店したときに終了する。例えば、従業員端末３００やユーザ端末２００などから、「お客様のお帰り」を通知されると、店舗端末１００はその時刻を注文情報データベース１８３に記録して処理を終了する。

図９に、店舗端末１００による表示情報の生成出力処理（ＳＴ１１，ＳＴ１２，ＳＴ１３）の詳細な処理の流れが示されている。店舗端末１００のＣＰＵ１１は、まず、ＳＴ１０で注文情報データベース１８３に記録されたユーザの入店時刻からの経過時間に基づいて、料理情報データベース１８１に記憶されている料理群の中から、おすすめ料理候補を１以上、統計的な方法により選択する（ＳＴ３１）。

ＣＰＵ１１が実行する統計的な方法は、例えば、売上情報データベース１８２から、入店からの経過時間をパラメータにして、その時間に注文される頻度が高い料理を抽出してもよい。売上情報データベース１８２は、図６に模式的に示したような情報を料理ごとに出力することができる。ＣＰＵ１１は、売上情報データベース１８２を入店からの経過時間をパラメータにして検索することにより、１以上のおすすめ料理候補を抽出する。なお、この検索の際には、例えば、頻度情報に利益率などで重み付けをしておすすめ料理候補を抽出してもよい。これにより、利益率の高い料理を積極的におすすめすることができる。

また、このＳＴ３１のおすすめ料理候補の選択の際に、ＣＰＵ１１は、ユーザの入店からの経過時間に加えて、あるいはこれに代えて、ユーザの滞在時間帯をパラメータにしてもよい。飲食店では時間帯によって、よく注文される料理が異なる場合があるため、これにより、おすすめする料理もそれに合わせて変化させることができる。

続いて、店舗端末１００のＣＰＵ１１は、選択されたおすすめ料理候補の中から、ユーザ端末２００に表示させる表示情報に含ませるおすすめ料理を動的に決定する（ＳＴ３２）。この動的な決定処理は、ユーザ入店後に注文された料理と、候補に挙げられているおすすめ料理候補との相関に基づいて、ＣＰＵ１１により判断される。

図１０は、上記注文済み料理とおすすめ料理候補との相関に基づく決定処理を説明するための模式図である。図１０中、左部分に示すように、ユーザからの注文（料理ａ１，２，・・・）は時系列に沿って、店舗端末１００に入力される。ここで入力される注文に係る料理には、図４に示したようなメタデータが紐付けされている。一方で、図１０中、右部分に示すように、おすすめ料理として挙げられている料理のそれぞれにも、図４に示したようなメタデータが紐付けされている。

ＣＰＵ１１は、図１０中、右部分に示されているおすすめ料理候補の一つ一つを、左部分に示されている過去に注文された料理と、それぞれに紐付けられたメタデータ同士の相関関係を検討することによって、重み付けする。メタデータ同士の相関関係の一例としては、図１０中に示したように、ある食材に係るメタデータと、おすすめ料理候補に紐付けられた食材に係る１つ以上のメタデータとの相関がある。

例えば、食材がよく似ているという相関関係が得られる場合、ＣＰＵ１１は、おすすめ料理候補に係る料理ｂ１の重み付けを下げる、というような処理を行う。これにより、似たような料理が連続しておすすめ料理として提示されることを抑制できる。例えば、前菜として鮮魚のカルパッチョを注文したユーザは、その後に刺身の盛り合わせをおすすめされても感度が鈍い、というような例があるが、本例の処理によれば、そのようなおすすめがなされるのを抑制することができる。

上記注文済み料理とおすすめ料理候補との相関に基づく決定処理の一例としては、例えば、ＣＰＵ１１は、おすすめ料理候補に挙げられている料理のそれぞれに、注文済みの料理のそれぞれとの、メタデータ同士の相関関係を検討し、重み付けを与える。その上で、重み付けにしたがって、おすすめを決定する。乱数を使ってランダムに決定してもよい。その際に重み付けを考慮してランダムに決定してもよい。なお、ＣＰＵ１１は、おすすめ料理を複数決定してもよい。

ＣＰＵ１１は、おすすめ料理を決定すると、次に、表示情報を生成する（ＳＴ３３）。表示情報は、例えば、マークアップランゲージが使用されたページとして構成されてもよい。次に、ＣＰＵ１１は、生成した表示情報をユーザ端末２００に出力（送信）する（ＳＴ３４）。ユーザ端末２００の表示装置は、受信した表示情報を画面に映し出す。

以上が料理情報提供システム１の動作の流れである。
上記情報処理装置によれば、ユーザの入店後の注文に応じて動的に変化するおすすめ料理が、入店からの経過時間に基づいて判断される適切なタイミングで提案されるため、おすすめ料理の動的な提案が実現し、顧客満足度を向上させることができる。
上記情報処理装置によれば、おすすめ料理をユーザの入店後の注文に応じて動的に変化させる具体的方法を提供することができる。

［おすすめ料理の提案のタイミング１］
次に、おすすめ料理情報を提供するタイミングについて説明する。おすすめ料理情報を提供するタイミングは、言い換えれば、Ｓ１１，ＳＴ１２，ＳＴ１３の表示情報の生成出力がなされる所定のタイミングになる。図１１は、おすすめ料理情報を提供するタイミングについて説明するための図である。

図１１において、縦軸は時間軸を表し、矢印は、おすすめ料理情報が提供されるタイミングを示すものとする。本実施形態におけるおすすめ料理情報を提供するタイミングは、一例として図１１（ａ）に示すように、１０分おきなどのように等間隔でおすすめ料理情報が提供されるように構成してもよい。

あるいは、売上情報データベース１８２に記憶されている図５（ｂ）のようなデータに基づいて、前菜の注文が少なくなるタイミングなどを割り出し、そのタイミングにおすすめ料理情報が提供されるように構成してもよい（不図示）。あるいは、入店後、５分経過時、２０分経過時、５０分経過時、などのように、あらかじめ決められた所定のタイミングで、おすすめ料理情報が提供されるように構成してもよいし、ユーザからの注文が所定時間ない場合におすすめ料理情報が提供されるように構成してもよい（不図示）。

さらに、図１１（ｂ）に示すように、本料理情報提供システム１により提供されたおすすめ料理情報に対して、ユーザが好意的なレスポンスを返す、例えば、そのおすすめ料理を注文する、といったアクションがあった場合、店舗端末１００のＣＰＵ１１は、その後のおすすめ料理情報の提供を積極的に行うようにしてもよい。具体的には、図１１（ｂ）に示すように、所定の間隔で提供していたおすすめ料理情報を、より短いスパンで提供するようにする。あるいは、頻繁におすすめ料理情報を更新してもよい。

所定の間隔を置いておすすめ料理情報を提供するのではなく、あらかじめ決められた所定のタイミングで、おすすめ料理情報が提供されるように構成されている場合、そのあらかじめ決められた所定のタイミングを早めのタイミングにシフトさせるようにしてもよい。この場合、例えば、通常なら入店後２０分経過時にメインディッシュのおすすめ料理情報を提供するところ、入店後１５分経過時にそれを提供するようにする。

おすすめ料理情報の提供をより頻繁に行うようにタイミング変更するトリガーとしては、上述のように、ユーザがおすすめ料理情報に対して好意的なレスポンスを返したことのほかに、ユーザの注文間隔の頻度でもよい。この場合、ＣＰＵ１１が、ユーザの注文間隔を、注文間隔データベース１８３を参照することにより把握しておき、注文間隔の広狭に応じて、おすすめ料理情報の提供の頻度を変更する。

この場合例えば、ＣＰＵ１１は、料理の注文間隔が狭いユーザに対して頻繁におすすめ料理を提示するようにしてもよい。逆に、注文間隔が広いユーザに対しては頻繁なおすすめ料理の提示を抑制してもよい。あるいは、注文間隔が広いユーザに対しては、入店からの経過時間が所定の時間が経つ前であっても、前記所定の時間の後におすすめ料理候補として選択される料理の中からおすすめ料理候補が選択されるようにしてもよい。この場合、所定の時間としては、例えばデザートや食後の口直しをおすすめ料理として提示することを開始する時間とすることができる。

これによれば、ＣＰＵ１１は注文間隔に基づいてユーザの空腹度合いを推し量ることができ、これに応じた頻度の変更を行うことで適切なおすすめ料理の提案が可能になる。

その他のおすすめ料理情報を提供するタイミングとしては、入店からの経過時間に基づくと、食事の終了が予想される時間が近づいたタイミングで、ＣＰＵ１１が、注文情報データベース１８３を参照することにより注文された品が所定の金額等に到達したか否かを判定し、到達していないと判定される場合に、さらにおすすめ料理情報を提供するよう構成してもよい。例えば、「２時間呑み放題」のような居酒屋で、１時間３０分経過した時点で上記情報処理を行う。

このような構成によれば、ユーザ又はユーザグループが享受したサービスが、飲食店の提供可能なサービスの標準的な水準に未だ達していないような場合に、もう一品追加の料理の提案をすることができるので、顧客満足度を向上させることができる。

さらに別の情報処理として、ＣＰＵ１１は、デザートやいわゆる「〆の料理」が、通常それらが注文される時間帯（「第１の時間帯」とする）よりも前に注文された場合、かならずしも入店からの経過時間に基づいておすすめ料理の提案をしなくてもよい。この場合、入店からの経過時間が第１の時間帯よりも前の所定の時間帯（「第２の時間帯」とする）に入っていなくても、その第２の時間帯に選択されるようなおすすめ料理候補から、おすすめ料理を決定する。

これにより、第１の時間帯におすすめ料理候補として選択されるような料理が、第１の時間帯よりも前の時間において注文されたような場合に、第１の時間帯よりも前の時間帯（第２の時間帯）におすすめ料理候補として選択されるような料理を、第２の時間帯でなくてもおすすめ料理として決定し、提案される。

そうすると、飲食店が本来、大きな満足を与えることができるはずの料理を享受する機会を逃さないように、ユーザに提案することができる。その結果として、顧客満足度を向上させることができる。例えば、「〆の料理」やデザートなどをユーザが比較的早期に注文した場合、ユーザは本来その店舗で楽しむことができる目玉料理を食べ逃してしまう可能性があった。上述のようなおすすめ料理の提案タイミングの制御によれば、そのような可能性を低減させることができ、顧客満足度の向上につながる。

［おすすめ料理の提案のタイミング２］
おすすめ料理情報の提供を行うタイミングに関する情報処理については、さらに、以下に述べるように、図９のＳＴ３４（表示情報の出力）の処理を行うタイミングを調整することにより、料理の提供のタイミング（サーブタイミング）が重ならないようにしてもよい。

図１２は、本情報処理の手順の一例を示すフローチャートである。図９と同じく店舗端末１００のＣＰＵ１１が実行する情報処理となる。ＳＴ４１、ＳＴ４２，ＳＴ４３，ＳＴ４５は図９に示したステップと同じ処理である。図１２に示すように、ＣＰＵ１１は、ＳＴ４５（表示情報の出力）の処理を行う直前に、表示情報の出力を遅らせるか否かを判断する（ＳＴ４４）。この表示出力ディレイは、ＳＴ４５を行うと、その時点でそのおすすめ料理（「第１の料理」とする）の注文をユーザから受けた場合、別の注文済みの料理（「第２の料理」とする）の提供と同時になる場合に、実行される（ＳＴ４４，Ｙｅｓ）。

図１２に示したような処理を行うことにより、第１の料理と第２の料理の提供が同時にならないようになる。したがって、適切なタイミングでのおすすめ料理の提案が可能になる。

［時間のかかる料理のおすすめ］
さらに、別の情報処理として、時間のかかる料理を安易におすすめ料理としない処理をしてもよい。調理時間は、図４で示したようなメタデータにより料理ごとに設定されている。このような場合、ＣＰＵ１１は、図９のＳＴ３１の選択をする際、ユーザの入店からの経過時間に、メタデータにより特定される調理時間及び／又はサーブまでの時間を加えた時間が、所定の閾値を越えないような料理のみをおすすめ料理候補にする。あるいは逆に、ユーザの入店からの経過時間に、メタデータにより特定される調理時間及び／又はサーブまでの時間を加えた時間が、所定の閾値を越える料理は、おすすめ料理候補から除外する。

上記情報処理によれば、時間のかかるような料理をおすすめするにあたって、入店からの経過時間が遅くなりすぎないような配慮がなされる。これにより、顧客満足度を向上させることができる。

さらに、上述の処理をした上で、調理時間が上記所定の閾値を越える料理が注文されると、ＣＰＵ１１は、図９のＳＴ３１の選択をする際、注文された料理がユーザに提供されるまでの時間内に提供可能な料理を、優先的におすすめ料理候補としてもよい。

優先的におすすめ料理候補とする処理の具体的な方法としては、例えば、ＣＰＵ１１が、料理情報データベース１８１に記憶されている料理群の中から、統計的な方法により１以上のおすすめ料理候補を選択する（図９のＳＴ３１）際に、選択に用いる料理ごとの重み付けを変更する。これにより、時間のかかる料理がユーザに提供されるまでの時間内に提供可能な料理が、通常ならば例えば４０％の確率でおすすめ料理候補に選択されるところ、８０％の確率で選択されるように変更できる。

上記情報処理によれば、時間のかかる料理が注文された場合においては、ユーザを待たせている比較的長い時間の間に、提供可能な料理をユーザに提案することによって、顧客満足度を向上させることができる。

［変形例］
上述の実施形態は種々の変形が可能である。例えば、上記実施形態においては、店舗端末１００が実行した情報処理による表示情報が、ユーザ端末２００に出力される例が記載されているが、従業員端末３００に出力されるように構成してもよい。この実施形態の利用例としては、ホール係などの従業員が自分の携帯する従業員端末３００を見て、来店客におすすめ料理を提案する。このようなハードウェア構成にすることで、来店客と従業員のコミュニケーションを促進することがきる。

また、上記実施形態の一変形例においては、おすすめメニュー情報を提案する際に、提案する根拠となったメタデータをユーザに表示してもよい。これにより、過去に注文された料理と、おすすめメニューとの相関を店員が説明することなくユーザに認識させることができ、より納得感のある注文を促すことができる。

以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。なお、実施形態に開示した構成はすべて組み合わせて実施することが可能である。

また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるネットワーク上のサーバも、本発明の範疇に含まれる。

１…料理情報提供システム
１１…ＣＰＵ
１８…記憶部
１９…通信部
１８１…料理情報データベース
１８２…売上情報データベース
１８３…注文情報データベース
１００…店舗端末
２００…ユーザ端末
３００…従業員端末

Claims (12)

1. ユーザの入店からの経過時間に基づいて統計的に１以上のおすすめ料理候補を選択し、
   選択されたおすすめ料理候補の中からユーザ入店後に注文された料理と前記おすすめ料理候補との相関に基づいて１以上のおすすめ料理を動的に決定し、
   決定したおすすめ料理をユーザに提示するための表示情報を生成する制御部を具備する
   情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記制御部は、前記経過時間に基づいて食事の終了が予想される時間が近づいてきたタイミングで、注文品の累計が所定の金額に、到達したか否かを判定し、到達していない場合にもう一品追加の提案をする
   情報処理装置。
3. 請求項１又は２に記載の情報処理装置であって、
   前記制御部は、前記相関を料理に紐付けされるメタデータに基づいて決定する
   情報処理装置。
4. 請求項１から３のいずれかに記載の情報処理装置であって、
   前記制御部は、提示したおすすめ料理をユーザが選択した場合に提案に乗ったと判断し、おすすめ料理の提案の処理を積極的に実行する
   情報処理装置。
5. 請求項１から４のいずれかに記載の情報処理装置であって、
   前記制御部は、前記入店時刻からの経過時間及び／又は滞在時間帯をパラメータにした統計的情報に基づくおすすめ料理候補の選択を行う
   情報処理装置。
6. 請求項１から５のいずれかに記載の情報処理装置であって、
   前記制御部は、ユーザから注文を受けた時刻を少なくとも一時的に記憶し、記憶した複数の時刻の間隔に係る注文間隔に応じて、おすすめ料理の決定頻度を変更する
   情報処理装置。
7. 請求項１から６のいずれかに記載の情報処理装置であって、
   前記制御部は、提案することが決定したおすすめ料理に係る第１の料理を第１のタイミングで提案すると、前記第１の料理の提供が前記第１の料理とは異なる注文済みの第２の料理の提供と同時になる場合、前記第１の料理を第１のタイミングよりも遅い第２のタイミングで提案する
   情報処理装置。
8. 請求項１から７のいずれかに記載の情報処理装置であって、
   前記制御部は、入店からの経過時間に基づいて第１の時間帯に選択されるおすすめ料理候補に該当する料理が、前記第１の時間帯よりも前に注文された場合、前記経過時間が前記第１の時間帯よりも前の第２の時間帯に入っているか否かに関わらず、前記第２の時間帯に選択されるおすすめ料理候補からおすすめ料理を決定する
   情報処理装置。
9. 請求項１から８のいずれかに記載の情報処理装置であって、
   前記制御部は、入店してからユーザが注文した酒類の履歴と、注文した料理との相関とに基づいて、提案する酒類を決定する
   情報処理装置。
10. 請求項１から９のいずれかに記載の情報処理装置であって、
    前記制御部は、調理時間が所定の第１の時間を越える料理をおすすめ料理候補とする場合、入店からの経過時間に調理時間及び／又はサーブまでの時間を加えた時間が、所定の第２の時間を越えない場合にのみ、前記調理時間が前記第１の時間を越える料理をおすすめ料理候補とする
    情報処理装置。
11. 請求項１０に記載の情報処理装置であって、
    前記制御部は、前記調理時間が前記第１の時間を越える料理が注文されると、前記調理時間が前記第１の時間を越える料理がユーザに提供されるまでの時間内に提供可能な料理を、優先的におすすめ料理候補とする
    情報処理装置。
12. 請求項１から１１に記載の情報処理装置であって、
    おすすめ料理の提案を店員の操作する可搬型端末に出力する出力部を有する
    情報処理装置。

Images