JP7167520B2 - メニュー生成システム及びメニュー生成方法 - Google Patents

Description

本開示は、飲食店メニューをリアルタイムに生成するのに用いられるシステム及び方法に関する。このシステム及び方法は、深刻な食餌疾患を持つ人、及び／又は、飲食店等の施設の無駄の削減において特に有用であるが、これらに限定されない。

深刻な食餌疾患（ナッツアレルギー又は糖尿病等）を持つ人は、不慣れな提供源（飲食店等）が提供する食品又は飲料を飲食するときに、大変な注意を払う必要がある。従来は、特定の食品又は飲料項目が原材料として何を含むのか、また、疾患者がどの原材料を避けるべきなのかの判断は、疾患者自身の知識や、食品提供源のスタッフの助けに頼るほかなかった。

米国特許第７５４９５９２号 米国特許第７６４１１２０号 米国特許第７７６２１８８号 米国特許第８３０４０７６号

しかしながら、本発明者らの知見によれば、従来の方法は、個人が専門的な知識を必要とするのみならず、非常に時間が掛かる。その上、食品提供源が提供可能な全ての項目から、安全に飲食できる食品及び飲料項目を選別するのは、誤りが生じ易い。

このような問題は、理解不可能な言語を使用する国を疾患者が旅行するとき、益々深刻になり得る。

従って、深刻な食餌疾患を持つ人は、不慣れな提供源から提供される食品又は飲料を飲食する際には非常に用心深くなったり、加えて／あるいは、拒絶反応を発症する深刻なリスクに直面したりすることがあるのが現状である。

加えて、飲食店又は施設が、顧客の食餌的／医療的ニーズに適した飲食物を提供したい場合、提供可能な多数の異なるメニューを用意したり、あるいは、メニューに多数の指標を載せたりする必要があった。このため、ユーザにとって複雑で解り難い場合もあった。

以上のような事情に鑑み、本開示の目的は、上記に示す問題を解決することにある。

本開示の第１の形態によれば、飲食店のメニューをリアルタイムに生成するメニュー生成システムが提供される。メニュー生成システムは、管理装置と、出力装置とを有する。管理装置は、複数の候補メニュー項目を記憶するよう構成されたメニュー項目属性記憶モジュールと、各前記複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む、各前記複数の候補メニュー項目のメニュー項目属性を記憶するよう構成されたメニュー項目属性記憶モジュールと、ユーザ要求情報又は飲食店ステータス情報の少なくとも何れか一方を含む明細情報を受信するよう構成された明細入力モジュールと、前記受信した明細情報を前記複数の候補メニュー項目及び対応する属性に適用することにより、複数の実メニュー項目及び対応する説明を決定するよう構成されたメニュー項目情報処理モジュールと、前記決定された実メニュー項目及び対応する説明に基づき、メニューを生成するよう構成されたメニュー生成モジュールとを有する。出力装置は、前記管理装置と通信可能に接続され、前記生成されたメニューを出力するよう構成される。従って、一形態によれば、ユーザ要求情報及び／又は飲食店ステータス情報を考慮して、リアルタイムに更新したメニューを生成し出力するメニュー生成システムが提供される。

本開示の第２の形態によれば、飲食店のメニューをリアルタイムに生成するメニュー生成方法が提供される。メニュー生成方法は、管理装置により、複数の候補メニュー項目を記憶し、前記管理装置により、各前記複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む、各前記複数の候補メニュー項目のメニュー項目属性を記憶し、前記管理装置により、ユーザ要求情報又は飲食店ステータス情報の少なくとも何れか一方を含む明細情報を受信し、前記管理装置により、前記受信した明細情報を前記複数の候補メニュー項目及び対応する属性に適用することにより、複数の実メニュー項目及び対応する説明を決定し、前記管理装置により、前記決定された実メニュー項目及び対応する説明に基づき、メニューを生成し、出力装置により、前記生成されたメニューを出力する。従って、一形態によれば、ユーザ要求情報及び／又は飲食店ステータス情報を考慮して、リアルタイムに更新したメニューを生成し出力するメニュー生成方法が提供される。

本開示、具体的には、図面の簡単な説明、発明を実施するための形態及び特許請求の範囲を参照することにより、本開示の他の実施形態がより明確になる。

本開示によれば、ユーザ要求情報及び／又は飲食店ステータス情報を考慮して、リアルタイムに更新したメニューを生成し出力することができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

リアルタイムなメニュー生成システムを示す。 管理装置を示す。 出力装置を示す。 管理装置の一例を示す。 ユーザ入力端末を示す。 ユーザ要求入力インターフェースを示す。 食餌要求の適用前後のメニューを示す。 翻訳前後のメニューを示す。 管理装置の別の一例を示す。 経営者側端末を示す。 時間的状況を適用したメニューを示す。 メニュー項目提供可能状況の提示を適用したメニューを示す。 飲食店メニューをリアルタイムに生成する方法を示す。 コンピュータ環境を示す。

図面を参照して本開示の実施形態を説明する。図面中、同様の構成要素は同様の参照符号を付す。

本開示は、リアルタイムにメニューを生成可能なシステムを提供する。本開示において、「リアルタイム」は、例えば、システムが「オンデマンド」でメニューを生成し出力したり、特定の最新の情報又は要求に基づいてメニューを生成し出力したりするのが可能であることを意味する。従って、このシステムは、例えば、あるメニューをリクエストする特定のユーザの要求や、飲食店の最新のステータスを考慮して、例えば、個人専用の、的確な及び／又は最新のメニューを提供する。本開示において、「ユーザ」は、例えば、システムを使用し得るなら誰でもよく、顧客、ウェイター、管理者、調理スタッフ又は旅行会社スタッフなどでよい。

本開示は主に「飲食店（レストラン）メニュー」について説明する。しかしながら、本開示の実施形態はより広範囲に適用可能である。例えば、本開示の実施形態は、他の食品又は飲料供給者（カフェ、バー、パブ、クラブ、スポーツ競技場等）のメニューや、食品又は飲料を提供する他の現場のメニューに、適用可能である。さらに、本開示の実施形態は、特定の現場で提供可能な項目（エンターテインメントのオプション（選択肢）や、個人専用のサービス等）のリスト（メニュー以外）に、適用可能である。

図１は、一実施形態に係るリアルタイムメニュー生成システム１００を示す。図１は、リアルタイムメニュー生成システム１００の構成要素を模式的に示す。図１に示すように、リアルタイムメニュー生成システム１００は、管理装置１２０及び出力装置１８０を有する。リアルタイムメニュー生成システム１００は、１以上のユーザ入力端末１４０又は経営者側端末１６０をさらに有してもよい。

本開示の実施形態において、管理装置１２０、経営者側端末１６０、ユーザ入力端末１４０及び出力装置１８０を、個別の装置として図示する。しかしながら、別の実施形態では、管理装置１２０、経営者側端末１６０、ユーザ入力端末１４０及び出力装置１８０の何れかが、一体的に構成されてもよい。例えば、一実施形態では、管理装置１２０及び出力装置１８０が一体的な単一の装置として構成され、経営者側端末１６０及びユーザ入力端末１４０が一体的な単一の端末として構成されてもよい。一実施形態では、管理装置１２０、経営者側端末１６０、ユーザ入力端末１４０及び出力装置１８０の全てが、が一体的な単一の装置として構成されてもよい。

リアルタイムメニュー生成システム１００の構成要素は、上述した管理装置１２０、経営者側端末１６０、ユーザ入力端末１４０及び出力装置１８０が全てではない。リアルタイムメニュー生成システム１００は、他の構成要素をさらに有してもよい。あるいは、リアルタイムメニュー生成システム１００自体が、より大きな装置の一部であってもよい。

出力装置１８０は、管理装置１２０と通信可能に接続される。リアルタイムメニュー生成システム１００が経営者側端末１６０及びユーザ入力端末１４０を有する場合は、経営者側端末１６０及びユーザ入力端末１４０も、管理装置１２０と通信可能に接続される。

通信接続方式は、各装置及び／又は各端末間で情報を転送可能であれば、如何なる適切な通信接続も使用可能である。特定の実装時の要求に応じて、有線接続（Ethernet、USB又はFirewire（登録商標）等）、無線接続（Bluetooth（登録商標）、Wi-Fi（登録商標）、セルラーネットワーク又は赤外線等）又はコンピュータ読み取り可能な記憶媒体（CD、DVD、Blu-Ray（登録商標）、メモリーカード又はUSBフラッシュドライブ等）を使用したマニュアル転送等の通信接続を使用すればよい。

リアルタイムメニュー生成システム１００の各構成要素について、以下により詳細に説明する。

図２は、図１に示した管理装置１２０を示す。図２は、管理装置１２０の構成要素を模式的に例示する。図２に示すように、管理装置１２０は、メニュー項目属性記憶モジュール１２２、メニュー項目属性記憶モジュール１２４、明細入力モジュール１２６、メニュー項目情報処理モジュール１２８及びメニュー生成モジュール１３０を有する。一実施形態では、管理装置１２０は、メニュー項目属性記憶モジュール１２２、メニュー項目属性記憶モジュール１２４、明細入力モジュール１２６、メニュー項目情報処理モジュール１２８及びメニュー生成モジュール１３０のうち、１以上の構成要素を必ずしも有さなくてもよい。

メニュー項目属性記憶モジュール１２２は、複数の候補メニュー項目を記憶するよう構成されたモジュールである。候補メニュー項目のリストは、食品項目及び飲料項目の両方を含んでよい。飲食店が原則提供可能な全ての項目を提示してもよい。

メニュー項目属性記憶モジュール１２４は、各複数の候補メニュー項目の対応する属性を記憶するよう構成されたモジュールである。この属性は、各複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む。一実施形態では、メニュー項目属性記憶モジュール１２４は、メニュー項目属性記憶モジュール１２２が記憶する、各複数の候補メニュー項目に使用されている全ての原材料を記憶してもよい。実装時の要求に応じて、メニュー項目属性記憶モジュール１２４は、主原材料のみを記憶してもよい。しかしながら、一実施形態では、メニュー項目属性記憶モジュール１２４は、使用量の少ない原材料（調味料又は添加物等）をさらに記憶してもよい。

一実施形態では、メニュー生成システム１００は、一般的なメニュー項目のデータベースを有したり、一般的なメニュー項目のデータベースにアクセスしたりする。メニュー項目属性記憶モジュール１２４が記憶する１以上のメニュー項目の属性は、一般的なメニュー項目のデータベースから、自動的に読み込まれる。これにより、一般的なメニュー項目の属性を、個別に入力する必要が無くなる。

一実施形態では、メニュー項目属性記憶モジュール１２４は、候補メニュー項目のさらに詳細な属性（調理温度、原材料産地、宗教的認証、エシカル認証及び／又は１以上の調理法等）を記憶してもよい。

以下により詳細に説明するように、メニュー項目属性記憶モジュール１２４が属性情報を記憶することにより、管理装置１２０は、候補メニュー項目の属性に基づいて、候補メニュー項目を処理することができる。従って、管理装置１２０は、候補メニュー項目の属性を考慮して、出力メニューに含むべき実メニュー項目（以下、実メニュー項目）を決定することができる。一実施形態では、実メニュー項目は、メニュー項目のシンプルなキーワード及び／又は付随的な情報（メニュー項目の属性又は詳細な説明等）を含んでもよい。

明細入力モジュール１２６は、明細情報を受信するよう構成される。明細情報は、管理装置１２０が実メニュー項目及び対応する説明を決定するのに用いる要求を定義するのに用いられる。

明細入力モジュール１２６は、明細入力モジュール１２６に直接入力された明細情報を受信してもよい。あるいは、明細入力モジュール１２６と通信可能に接続されたデータソース又は明細入力モジュール１２６に含まれるデータソースが、明細情報にアクセスしてもよい。どのように明細情報を受信可能とするかの具体例を、以下に例を挙げて説明する。

明細情報は、ユーザ要求情報又は飲食店ステータス情報の少なくとも何れか一方を含む。

本開示の一実施形態によれば、明細入力モジュール１２６は、ユーザ要求入力モジュール１２６Ａ及び／又は飲食店ステータスモジュール１２６Ｂを有してもよい。本開示の一実施形態によれば、管理装置１２０Ａは、ユーザ要求入力モジュール１２６Ａを有する。図４乃至図８を参照して、管理装置１２０Ａを後で説明する。本開示の一実施形態によれば、管理装置１２０Ｂは、飲食店ステータスモジュール１２６Ｂを有する。図９乃至図１２を参照して、管理装置１２０Ｂを後で説明する。

本開示は、これらの実施形態を個別に説明する。しかし、当然ながら、明細入力モジュールは、ユーザ要求入力モジュール１２６Ａ及び飲食店ステータスモジュール１２６Ｂの両方を有してもよい。即ち、これらの実施形態を組み合わせてもよい。

これらの実施形態に係るユーザ要求情報及び飲食店ステータス情報の具体例を以下に説明する。

メニュー項目情報処理モジュール１２８は、受信した明細情報を複数の候補メニュー項目及び対応する属性に適用することにより、出力メニューに含むべき複数の実メニュー項目及び対応する説明を決定する。どのように明細情報を適用するかの具体例を、以下に説明する。「適用」は、明細情報に基づき候補メニュー項目を選択又はフィルタリングすること、明細情報に基づき論理演算を実行して候補メニュー項目を決定すること、情報やデータをさらに取得して特定の目的の要求に応じて明細情報を補うこと、又は、明細情報に基づき選択された異なる形式にデータを変換すること、のうち１以上を含めばよい。

メニュー生成モジュール１３０は、メニュー項目情報処理モジュール１２８により決定された実メニュー項目及び対応する説明に基づき、メニューを生成するよう構成される。見方によっては、メニュー生成モジュール１３０は、決定された実メニュー項目を描画したり書式を整えたりして、人間が読み取り可能な形式に変換するといえる。

図３は、出力装置１８０の一例を示す。図３は、出力装置１８０の構成要素を模式的に例示する。図３に示すように、出力装置１８０は、プリンタ１８２及び通信モジュール１８４を有する。一実施形態では、出力装置１８０は、プリンタ１８２及び通信モジュール１８４のうち、１以上の構成要素を必ずしも有さなくてもよい。出力装置１８０は、例えば、代わりにディスプレイを有してもよい。

出力装置１８０は、メニュー生成モジュール１３０により生成されたメニューを出力するよう構成される。

一実施形態では、出力装置１８０は、プリンタ１８２を有する。プリンタ１８２は、オンデマンドのメニューを、必要時に、リアルタイムで印刷する。印刷したメニューは、ユーザが見慣れている点と、リアルタイムなメニューを読み取るハードウェアが別途必要ではない点において、便利である。加えて、必要なときのみメニューを印刷することができるので、メニューが必ず最新のものであることが保証される。また、予め印刷することによる無駄（例えば、複数の言語でメニューを予め印刷してストックしておくことで生じる無駄）を防ぐことができる。

さらに、特定のユーザ又は特定のユーザのグループのためにメニューを印刷する際に、様々な変更（文字サイズ、色又は書式の調整）ができるので、ユーザ要求情報（医療的な要求又は個人的な嗜好等）を考慮したメニューを作成することができる。例えば、記載内容を改変し、文字サイズを大きくし、フォントの色を変更してコントラストを高めれば、弱視のユーザにとっての可読性が向上する。

一実施形態では、プリンタ１８２は、メニューを再使用可能紙に出力するよう構成された再使用可能紙用のプリンタである。一実施形態では、再使用可能紙システムとして消色可能／再使用可能紙（Xerox（登録商標）製）を使用可能であり、その詳細は例えば、上記特許文献１乃至４に開示される。

再使用可能紙を使用することで、同じ用紙を繰り返し使うことができ、紙の消耗を減らすとともに資源の消費を減らすことができる。再使用可能紙を使用することは、ユーザ毎に又はリアルタイムにメニューを提供するのに益々実用的である。

一実施形態では、出力装置１８０は、通信モジュール１８４を有する。通信モジュール１８４は、メニューをリモート装置に出力可能に構成される。リモート装置は、ユーザのモバイルデバイス（携帯電話又はタブレット等）や、現場（レストラン等）にある専用のスクリーンでよい。

通信モジュール１８４は、メニューをリモート装置に出力するよう構成されてもよい。出力時には、特定の実装時の要求に応じて、有線接続（Ethernet、USB又はFirewire（登録商標）等）、無線接続（Bluetooth（登録商標）、Wi-Fi（登録商標）、セルラーネットワーク又は赤外線等）又はコンピュータ読み取り可能な記憶媒体（CD、DVD、Blu-Ray（登録商標）、メモリーカード又はUSBフラッシュドライブ等）を使用したマニュアル転送等の通信接続を使用すればよい。一実施形態では、電子メール、ファイル転送、又は専用のアプリ（アプリケーション）に直接接続することにより、メニューをリモート装置に出力してもよい。

ユーザがモバイルデバイスを使い慣れているなら、ユーザのモバイルデバイスにメニューを提供すれば、ユーザにとって便利であると考えられる。現場（レストラン等）にある専用のスクリーンにメニューを提供すれば、複数のユーザが最新のリアルタイムなメニューを見ることが出来て便利であると考えられる。メニューをリモート装置に電子的に提供すれば、メニューを物理的に作成する必要性が減り、紙の消耗を減らすことができる。

上述のように、図４乃至図８は、本開示の一実施形態を示す。図４は、管理装置１２０Ａを模式的に示す。管理装置１２０Ａにおいて、明細入力モジュール１２６は、ユーザ要求入力モジュール１２６Ａを有する。ユーザ要求入力モジュール１２６Ａは、ユーザ要求情報を受信するよう構成される。図４においては、明細入力モジュール１２６を単にユーザ要求入力モジュール１２６Ａとしてのみ示す。管理装置１２０Ａの他の構成要素は、特に断りの無い限り、図２を参照して説明した対応する構成要素と実質的に同様である。

一実施形態では、ユーザ要求情報は、１以上のユーザ食餌要求を含む。ユーザ食餌要求は、アレルギー、食品過敏症、医療的な特別食、妊婦食、幼児食、離乳食、宗教食、エシカル食、減量食及びライフスタイルに合った食餌のうち１以上を考慮することができる。メニュー項目情報処理モジュール１２８は、これらの食餌要求を、候補メニュー項目及び候補メニュー項目に対応する属性に適用する。この場合、「適用」は、候補メニュー項目の原材料及びユーザ食餌要求に基づき、候補メニュー項目を選択することを含む。

一例として、食餌要求の取り扱いについて以下に説明する。

・ユーザ食餌要求がピーナッツアレルギーを含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、原材料としてピーナッツ又はピーナッツ製品を含むことを示す属性をもつ候補メニュー項目を、除外すればよい。

・ユーザ食餌要求が糖尿病を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、砂糖又は加工炭水化物を多量に含むことを示す属性をもつ候補メニュー項目を、除外すればよい。

・ユーザ食餌要求が妊婦食を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、アルコールや、低温調理された肉や魚を含むことを示す属性をもつ候補メニュー項目を、除外すればよい。

・ユーザ食餌要求が宗教食を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、非ハラル（イスラム教）又は非コーシャー（ユダヤ教）に由来する原材料や、非ハラル又は非コーシャーで加工された原材料を含むことを示す属性をもつ候補メニュー項目を、除外すればよい。

・ユーザ食餌要求が減量食又は一食の最大カロリーを含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、候補メニュー項目の属性に基づき高カロリーと算出された候補メニュー項目を、除外すればよい。

このようにして、メニュー生成システム１００は、特定のユーザの特定の食餌要求に合わせて専用のメニューを生成することができる。これにより、ユーザは、時間を掛けず安全に、自分専用のメニューから好きな項目を選択できる。選択する際、専門的な知識は必要ない。さらに、自分のユーザ食餌要求に適合しない項目を誤って選択して健康を害することは望ましくないが、そのリスクも無い。このメニュー生成システムは、特に旅行時に有用である。旅行時には、言葉の壁がある場合があるため、ユーザ要求に適合しない食品を誤って選択するリスクがあるが、このリスクを減らすことができる。

上の列挙は単に一例である。特定の実装時の要求に応じて、他のユーザ食餌要求や、それを取り扱う方法が多く考えられる。

ユーザ食餌要求に代えて、あるいは、ユーザ食餌要求に加えて、ユーザ要求情報は、１以上のユーザ言語を含む。ユーザ言語は、ユーザが使用する言語や、ユーザが理解可能な言語を含むことができる。メニュー項目情報処理モジュール１２８は、これらの言語要求を、候補メニュー項目及び候補メニュー項目に対応する属性に適用する。この場合、「適用」は、１以上のユーザ言語の少なくとも１つで記載された対応する説明を取得することを含む。

特定の実装時の要求に応じて、この「取得」は多数の形式を採用してもよい。一実施形態では、オンデマンドの機械翻訳や、公知の翻訳のデータベースの検索により、対応する説明を取得することができる。あるいは、翻訳が入手できなければ、メニュー項目の写真を供給することで、対応する説明を取得することができる。メニュー項目情報処理モジュール１２８自体が、対応する説明を取得してもよい。あるいは、メニュー項目情報処理モジュール１２８と通信可能に接続された別のコンピュータ装置（専用のモジュール又はウェブサービス等）が、対応する説明を取得してもよい。

このようにして、メニュー生成システムは、ユーザの使用する言語でメニューをオンデマンドで生成し、出力することができる。これにより、ユーザが確実にメニューを理解することができる。健康を害するおそれのあるメニューのオプションを誤って選択することは望ましくないが、それを避けることができる。

一実施形態では、リアルタイムメニュー生成システム１００は、ユーザ入力端末１４０を有する。ユーザ要求入力モジュール１２６Ａは、ユーザ入力端末１４０を介してユーザ要求情報を受信するよう構成される。

図５は、ユーザ入力端末１４０を模式的に示す。図５に示すように、ユーザ入力端末１４０は、光学撮像装置１４２、近距離無線受信機１４４及びマニュアル入力装置１４６等の受信装置を有する。一実施形態では、ユーザ入力端末１４０は、光学撮像装置１４２、近距離無線受信機１４４及びマニュアル入力装置１４６のうち、１以上の構成要素を必ずしも有さなくてもよい。ユーザ入力端末１４０を用いて、ユーザは、自分のユーザ要求情報をリアルタイムメニュー生成システム１００に容易に入力することができる。

ユーザ入力端末１４０が光学撮像装置１４２を含む場合、ユーザ入力端末１４０は、ユーザが提示する視覚的コードを読み取ることによりユーザ要求情報を受信すればよい。一実施形態では、視覚的コードは、物理的なカードに印刷されていてもよいし、ユーザのモバイルデバイスに表示されてもよい。一実施形態では、視覚的コードは、ユーザ要求情報を直接的に含んでもよい。あるいは、視覚的コードは、シリアルナンバーでもよい。あるいは、視覚的コードは、ユーザ入力端末１４０が外部のデータソース（メニュー生成システム１００のデータベース、ウェブサービス等）からユーザ要求情報を受信できるようなリンクでもよい。特定の実装時の要求に応じて、視覚的コードは、QRコード（登録商標）や、他の１次元コードや２次元コード等、適切な形式とすればよい。

このようにして、光学撮像装置１４２を用いることで、ユーザは、時間を掛けず的確に、自分のユーザ要求情報をメニュー生成システム１００に入力できる。加えて、非常に詳細なユーザ要求情報を、この方法で受信することができる。一実施形態によれば、このようなコードは、ユーザ要求情報にアクセスして読み出すためのアクセス情報（例えば、URL）を含むことができる。さらに、コード自体がユーザ要求情報を含む場合は、メニュー生成システム１００は、ユーザ要求情報を直接取得することができ、ユーザ要求情報をリモートで取得する必要が無い。

ユーザ入力端末１４０が近距離無線受信機１４４を含む場合、ユーザ入力端末１４０は、ユーザの近距離無線装置からユーザ要求情報を読み取って受信すればよい。一実施形態では、近距離無線装置は、物理的なカードに含まれてもよいし、ユーザのモバイルデバイスでよい。一実施形態では、近距離無線装置は、ユーザ要求情報を直接供給してもよい。あるいは、近距離無線装置は、シリアルナンバーを供給してもよい。あるいは、近距離無線装置は、ユーザ入力端末１４０が外部のデータソース（メニュー生成システム１００のデータベース、ウェブサービス等）からユーザ要求情報を受信できるようなリンクを供給してもよい。特定の実装時の要求に応じて、近距離無線受信機１４４及び近距離無線装置は、適切な近距離無線通信技術（RFID、NFC、赤外線又はBluetooth（登録商標）等）を用いて通信すればよい。

このようにして、近距離無線受信機１４４を用いることにより、ユーザは、時間を掛けず的確に、自分のユーザ要求情報をメニュー生成システム１００に入力できる。加えて、非常に詳細なユーザ要求情報を、この方法で受信することができる。さらに、近距離無線装置がユーザ要求情報をメニュー生成システム１００に直接供給する場合は、メニュー生成システム１００は、ユーザ要求情報をリモートで取得する必要が無い。

ユーザ入力端末１４０がマニュアル入力装置１４６を有する場合、ユーザ入力端末１４０は、ユーザが直接入力したユーザ要求情報を受信できる。特定の実装時の要求に応じて、マニュアル入力装置１４６は、ユーザがユーザ要求情報をマニュアルで入力できる適当な装置（タッチスクリーン、キーボード、マウス又は音声認識装置）を含んでよい。

マニュアル入力装置１４６を使用することで、事前に特別な準備の必要も無く、特別なハードウェアやIDを持参する必要も無く、ユーザは、飲食店にいるときに自分のユーザ要求情報を入力することができる。

図６は、ユーザ要求入力インターフェース２００の一例を示す。ユーザ要求入力インターフェース２００は、マニュアル入力装置１４６を有するユーザ入力端末１４０において実現可能である。ユーザ要求入力インターフェース２００は、アレルギー／過敏症ドロップダウンリスト２１０、使用言語ドロップダウンリスト２２０、印刷ボタン２３０及びデバイスに送信ボタン２４０を有する。

アレルギー／過敏症ドロップダウンリスト２１０を用いて、ユーザは、自分が患う１以上のアレルギー又は過敏症を選択できる。使用言語ドロップダウンリスト２２０を用いて、ユーザは、自分が理解する１以上の言語を選択できる。

印刷ボタン２３０は、プリンタ１８２を有する出力装置１８０に印刷指示を出し、ユーザが選択したユーザ要求情報に基づきメニューを印刷させる。デバイスに送信ボタン２４０は、通信モジュール１８４を有する出力装置１８０に出力指示を出し、ユーザが選択したユーザ要求情報に基づきメニューをリモート装置（ユーザのモバイルデバイス等）に出力させる。

図６に示すユーザ要求入力インターフェース２００は、単に一例である。他の様々なインターフェースも実現可能である。例えば、ユーザ要求入力インターフェース２００は、ドロップダウンリスト２１０、２２０に加えて別のドロップダウンリストを有してもよいし、ドロップダウンリスト２１０、２２０に代えて別のドロップダウンリストを有してもよい。ユーザ要求入力インターフェース２００は、無線ボタン、アイコン、又は、自由に文字を入力可能なフィールドを有してもよい。このフィールドに、上述の特定のユーザ要求情報の組み合わせを入力することができる。

一実施形態では、ユーザ要求情報は、ユーザのメニュー選択又は飲食店来訪の履歴データに基づく情報を含んでもよい。この履歴データは、例えば、過去に来訪した飲食店で飲食した直近の食事のような範囲に限定してもよい。あるいは、履歴データは、このシステムを使用してユーザが過去に飲食した全ての食事及び来訪した全ての飲食店の実質的に完全な記録を構成してもよい。

このような情報は、例えば、メニューを生成するにあたりユーザにバランスの良い食事を勧めるのに使用することができる。例えば、ユーザがランチタイムに高カロリーな食事を飲食したとシステムが記録している場合、システムは、低カロリーの食事を高い比率で含むメニューに修正することができる。別の実施形態によれば、システムは、ユーザが特定のメニュー項目をいつも選択していると履歴データが実証している場合、その項目を目立つ位置に配置したメニューを生成することができる。これにより、ユーザは、このメニュー項目を、時間を掛けずに見つけることができる。

上述のユーザ要求情報は、１人のユーザのユーザ要求情報を意味する。一実施形態では、上述のユーザ要求情報入力手段の何れも、連続的に又は同時に、複数のユーザからユーザ要求情報を受信してもよい。

さらに、当然ながら、システムが複数のユーザからユーザ要求情報を受信する場合、一実施形態では、メニュー項目情報処理モジュール１２８は、複数のユーザからのユーザ要求情報を適用して複数の実メニュー項目及び対応する説明を決定し、これにより、全ての複数のユーザからのユーザ要求情報を満足するメニュー生成し出力するよう構成されてもよい。一例として、第１のユーザが大豆アレルギーであり、第２のユーザが卵アレルギーの場合、メニュー生成システム１００は、大豆又は卵を含む料理を含まないメニューを出力すればよい。

これにより、ユーザのグループが共通のメニュー項目を選択する場合、全てのユーザのユーザ要求情報を満足する１つのメニューを注文できる。従って、例えば、グループのメンバーの誰にも健康面で拒絶反応が発症しないような大皿料理を、グループで注文できる。

図７Ａ及び図７Ｂは、受信したユーザ要求情報に応じて、メニュー生成システム１００が変更したメニューのペアの一例を示す。図８Ａ及び図８Ｂは、受信したユーザ要求情報に応じて、メニュー生成システム１００が変更したメニューのペアの一例を示す。

図７Ａは、ユーザ要求情報を適用する前のメニュー３００Ａを例示する。メニュー３００Ａは、メニュー項目の４つのカテゴリ（肉料理３１０、魚料理３２０、野菜料理３３０及び飲み物３４０）を図示する。各カテゴリに含まれる実メニュー項目は図示しない。メニュー３００Ａは、例えば、明細情報（ユーザ要求情報又は飲食店ステータス情報等）が無い場合の初期設定のメニューである。

図７Ｂは、ユーザ要求情報を適用した後のメニュー３００Ｂを図示する。例えば、メニュー生成システム１００が、ユーザが魚アレルギーであることを示す食餌要求を受信した場合、メニュー項目情報処理モジュール１２８は、出力するメニュー３００Ｂに魚料理を含まないよう決定する。従って、メニュー項目情報処理モジュール１２８は、魚料理３２０のカテゴリを除外する。一実施形態によれば、メニュー項目情報処理モジュール１２８は、魚料理３２０の代わりに、許容されるカテゴリ（本例では、デザート３５０）を提示してもよい。

図８Ａは、ユーザ要求情報を適用する前のメニュー４００Ａを例示する。メニュー４００Ａは、メニュー項目の４つのカテゴリ（肉料理４１０Ａ、魚料理４２０Ａ、野菜料理４３０Ａ及び飲み物４４０Ａ）を図示する。各カテゴリに含まれる実メニュー項目は図示しない。

図８Ｂは、ユーザ要求情報を適用した後のメニュー４００Ｂを図示する。例えば、メニュー生成システム１００が、英語が望ましいとの指示を受信した場合、メニュー項目情報処理モジュール１２８は、英語で記載されたメニュー項目の対応する説明であるMeat Dishes４１０Ｂ、Fish Dishes４２０Ｂ、Vegetable Dishes４３０Ｂ及びDrinks４４０Ｂを取得する。

上述のように、図９乃至図１２は、本開示の別の一実施形態を示す。図９は、管理装置１２０Ｂを模式的に示す。管理装置１２０Ｂにおいて、明細入力モジュール１２６は、飲食店ステータスモジュール１２６Ｂを有する。飲食店ステータスモジュール１２６Ｂは、飲食店ステータス情報を受信するよう構成される。図９においては、明細入力モジュール１２６を単に飲食店ステータスモジュール１２６Ｂとしてのみ示す。管理装置１２０Ｂの他の構成要素は、特に断りの無い限り、図２又は図４を参照して説明した対応する構成要素と実質的に同様である。

一実施形態では、飲食店ステータス情報は、原材料在庫情報を含む。原材料在庫情報は、例えば、最新の原材料在庫レベル又は最新の原材料価格のうち１以上を考慮することができる。メニュー項目情報処理モジュール１２８は、原材料在庫情報を、候補メニュー項目及び候補メニュー項目に対応する属性に適用する。この場合、「適用」は、候補メニュー項目の原材料及び原材料在庫情報に基づき、候補メニュー項目を選択することを含む。

飲食店ステータス情報は、原材料在庫情報に代えて、あるいは、原材料在庫情報に加えて、ユーザのメニュー選択の履歴データを含む。このような履歴データは、カテゴリのグループ（時間又は曜日等）に分類されてもよい。メニュー項目情報処理モジュール１２８は、ユーザのメニュー選択の履歴データを、候補メニュー項目及び候補メニュー項目に対応する属性に適用する。この場合、「適用」は、履歴データに含まれるメニュー項目の履歴の人気度に基づき、候補メニュー項目を選択することを含む。

一例として、飲食店ステータス情報の取り扱い例について以下に説明する。

・飲食店ステータス情報が、一部の原材料の在庫が少ないことや、別の原材料が在庫切れであることを示す情報を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、特定の在庫レベル未満の原材料を含む候補メニュー項目を、除外すればよい。メニュー項目情報処理モジュール１２８は、フィルタリングに加えて、あるいは、フィルタリングに代えて、選択されたメニュー項目に対応する、メニュー項目の原材料の最新の在庫レベルを示す説明情報を提示してもよい。このようにして、メニュー生成システム１００は、メニュー項目の最新の提供可能状況を的確に反映して提示するメニューを、生成することができる。

・飲食店ステータス情報が、一部の最新の原材料価格が高価であることを示す情報を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、高価格な原材料を含むメニュー項目を除外し、低価格な原材料を含む類似のメニュー項目を代替的に含むようにすればよい。あるいは、メニュー項目情報処理モジュール１２８は、メニュー項目を並べ替えてもよい。例えば、高価格な原材料を含む項目をメニューの目立たない位置（メニューページより下や、メニューの後ろの方等）に配置する。このようにして、メニュー生成システム１００は、飲食店に掛かる原材料価格を抑えることができる。

・飲食店ステータス情報が、例えば、他の曜日より木曜日に特定のメニュー項目の人気度が高いことを示す情報を含む場合、メニュー項目情報処理モジュール１２８は、候補メニュー項目を以下の様にフィルタリングすればよい。例えば、木曜日に、この特定のメニュー項目が、出力されるメニューの目立つ位置に現れるようにすればよい。このように、メニュー生成システム１００は、履歴の上で木曜日により人気度の高いメニュー項目をより目立つ位置に配置することで、ユーザがこのメニュー項目を見つけやすくなる。従って、ユーザがメニューを探すのに掛ける時間を短縮することができる。

上の列挙は単に一例である。特定の実装時の要求に応じて、他の飲食店ステータス情報や、それを取り扱う方法が多く考えられる。

一実施形態では、飲食店ステータスモジュール１２６Ｂは、データベース又は在庫管理システムから、飲食店ステータス情報を受信してもよい。特定の実装時の要求に応じて、データベース又は在庫管理システムは、例えば、管理装置１２０Ｂの一部として実現されてもよいし、メニュー生成システム１００に含まれる管理装置１２０Ｂ以外の要素の一部として実現されてもよいし、メニュー生成システム１００と通信可能に接続された外部装置として実現されてもよい。

一実施形態では、リアルタイムメニュー生成システム１００は、経営者側端末１６０を有する。図１０は、経営者側端末１６０を模式的に示す。経営者側端末１６０は、管理装置と通信可能に接続される。経営者側端末１６０は、メニュー項目属性記憶モジュール１２２、メニュー項目属性記憶モジュール１２４及び飲食店ステータスモジュール１２６Ｂのうち１以上を入力するよう構成される。

図１０に示すように、経営者側端末１６０は、光学撮像装置１６２、近距離無線受信機１６４及びマニュアル入力装置１６６等の受信装置を有する。一実施形態では、経営者側端末１６０は、光学撮像装置１６２、近距離無線受信機１６４及びマニュアル入力装置１６６のうち、１以上の構成要素を必ずしも有さなくてもよい。経営者側端末１６０を用いて、例えば飲食店経営者は、候補メニュー項目の情報、候補メニュー項目の属性及び飲食店ステータス情報を入力することができる。入力方法については、図５を参照して説明した、ユーザがユーザ要求情報をユーザ入力端末１４０に入力する方法と実質的に同様である。

このようにして、経営者側端末１６０を用いることで、飲食店経営者は、時間を掛けず効率的に情報を入力できる。この効果は、ユーザ入力端末１４０を用いた入力で達成される効果と実質的に同様である。一例として、経営者側端末は、新たに配達された在庫に含まれる（付された）視覚的コード又は近距離無線装置を読み取ることにより、情報を受信するよう構成されてもよい。これにより、候補メニュー項目の情報、候補メニュー項目の属性及び飲食店ステータス情報を、時間を掛けず容易に入力することができる。

図１１Ａ、図１１Ｂ及び図１２は、受信した飲食店ステータス情報に応じて、メニュー生成システム１００が変更したメニューの一例を示す。

図１１Ａ及び１１Ｂは、ユーザのメニュー選択の履歴データに応じて、メニュー生成システム１００が出力したメニューの一例を示す。図１１Ａは、ランチタイムメニューを示す。図１１Ａは、ランチタイムの履歴の人気度が高いメニュー項目の４つのカテゴリ（サンドウィッチ５１０、サラダ５２０、パスタ５３０及びソフトドリンク５４０）を図示する。同図では各カテゴリに含まれる実メニュー項目は図示しない。

図１１Ｂは、ディナータイムメニューを示す。図１１Ｂは、ディナータイムの履歴の人気度が高いメニュー項目の４つのカテゴリ（メインコース５５０、大皿料理５６０、デザート５７０及びアルコール５８０）を図示する。同図では各カテゴリに含まれる実メニュー項目は図示しない。

このようにして、メニュー生成システム１００は、メニューを生成する時刻に選択される傾向の高いメニュー項目のみを表示したり、目立つように表示したりすることができる。これにより、メニューに含める情報をより的確に選択することができる。これにより、ユーザは、時間を掛けずに、現在の時刻に人気度の高い料理を見つけることができる。加えて、メニューを出力する時刻に人気度の低い不要なメニュー項目を、メニューに含めることが無いので、メニューを短くすることができる。これにより、現在の時刻には不要である項目を含めた、冗長で不要なメニューを印刷することによる資源の消耗を減らすことができる。

図１２は、メニュー６００の一例を示す。メニュー項目情報処理モジュール１２８が原材料在庫情報を適用した後に、メニュー６００は、メニュー項目の最新の提供可能状況を示すことができる。メニュー６００は、６つのメニュー項目と、メニュー項目に対応提供可能状況レベルとを図示する。具体的には、メニュー６００は、マグロ料理６６０は在庫切れであり、ビーフ料理６２０は在庫が少なく、ポーク料理６１０、チキン料理６３０、マス料理６４０及びサーモン料理６５０は通常の在庫であることを示す。このように、メニュー生成システム１００は、現在提供不可能な料理や、近い将来提供不可能となり得る料理を、ユーザに直接的に提示するメニューを生成してもよい。

図１２は、異なるシェーディング（色の明暗）で塗った丸印の指標で在庫レベルを示している。しかしながら、代わりに、適当であればどのような指標でも使用できる。例えば、適用時の要求に応じて、「交通信号」カラーシステムや、数値指標を使用すればよい。また、一実施形態では、在庫切れ又は注文できないメニュー項目を全て、メニューから除いてもよい。

上記の説明は、メニュー生成システム１００の観点から主に記載した。当然ながら、本開示の実施形態は、メニュー生成システム１００の上記の動作に対応する方法も含む。

図１３は、メニュー生成方法７００の一例を示し、以下のステップを有する。まず、ステップＳ７１０で、管理装置により、複数の候補メニュー項目を記憶する。メニュー生成方法７００は、次にステップＳ７２０に進む。ステップＳ７２０で、管理装置により、各複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む、各複数の候補メニュー項目のメニュー項目属性を記憶する。メニュー生成方法７００、次にステップＳ７３０に進む。ステップＳ７３０で、管理装置により、ユーザ要求情報又は飲食店ステータス情報の少なくとも何れか一方を含む明細情報を受信する。メニュー生成方法７００は、次にステップＳ７４０に進む。ステップＳ７４０で、管理装置により、受信した明細情報を複数の候補メニュー項目及び対応する属性に適用することにより、複数の実メニュー項目及び対応する説明を決定する。メニュー生成方法７００は、次にステップＳ７５０に進む。ステップＳ７５０で、管理装置により、決定された実メニュー項目及び対応する説明に基づき、メニューを生成する。最後に、メニュー生成方法７００は、次にステップＳ７６０に進む。ステップＳ７６０で、出力装置により、生成されたメニューを出力する。

図１４は、コンピュータハードウェアインプリメンテーション（実装）１０００の一例を模式的に示す。コンピュータハードウェアインプリメンテーション１０００は、管理装置１２０／１２０Ａ／１２０Ｂ、経営者側端末１６０、ユーザ入力端末１４０及び出力装置１８０の個々の実装として適切であるとともに、何れかの組み合わせの実装としても適切である。

本実施形態に係るコンピュータハードウェアインプリメンテーション１０００は、１以上のコミュニケーションバス１１００を介して全て接続された、プロセッサ１００２、記憶装置１００４、表示装置１００６、入力装置１００８及び通信装置１０１０を有する。プロセッサ１００２は、プログラム又は他の種の指示に従って、演算処理を実行する。記憶装置１００４は、例えば、RAM等の揮発性メモリ及び／又はハードディスク等の不揮発性メモリを有する。記憶装置１００４は、プログラム情報及び／又はプログラムデータを記憶する。表示装置１００６は、例えば、ディスプレイであり、表示画像を提供する。入力装置１００８は、例えば、入力用のキーボード又はタッチパネルである。通信装置１０１０は、プロセッサ１００２の処理結果及び記憶装置１００４に記憶される情報を他のコンピュータと送受信可能に動作する。

一実施形態では、コンピュータハードウェアインプリメンテーション１０００は、プロセッサ１００２、記憶装置１００４、表示装置１００６、入力装置１００８及び通信装置１０１０のうち、１以上の構成要素を必ずしも有さなくてもよい。一実施形態では、コンピュータハードウェアインプリメンテーション１０００は、入力装置１００８及び表示装置１００６に代えて、あるいは、入力装置１００８及び表示装置１００６に加えて、上に詳述した構成要素である追加的な入力装置及び出力装置を有してもよい。

リアルタイムなメニュー生成システム及び方法を上に説明した。リアルタイムなメニュー生成システム及び方法は、ユーザ要求情報及び／又は飲食店ステータス情報を考慮して、リアルタイムに、更新したメニューを生成し出力することができる。

本技術の各実施形態及び各変形例について上に説明したが、本技術は上述の実施形態にのみ限定されるものではなく、本技術の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

１００…メニュー生成システム
１２０、１２０Ａ、１２０Ｂ…管理装置
１２２…メニュー項目記憶モジュール
１２４…メニュー項目属性記憶モジュール
１２６…明細入力モジュール
１２６Ａ…ユーザ要求入力モジュール
１２６Ｂ…飲食店ステータスモジュール
１２８…メニュー項目情報処理モジュール
１３０…メニュー生成モジュール
１４０…ユーザ入力端末
１６０…経営者側端末
１８０…出力装置

Claims (7)

1. 飲食店のメニューをリアルタイムに生成するメニュー生成システムであって、
   複数の候補メニュー項目を記憶するよう構成されたメニュー項目記憶モジュールと、
   各前記複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む、各前記複数の候補メニュー項目のメニュー項目属性を記憶するよう構成されたメニュー項目属性記憶モジュールと、
   ユーザ入力端末を介して前記メニューに関するユーザの要求を示すユーザ要求情報を受信するよう構成されたユーザ要求入力モジュールと、
   前記受信したユーザ要求情報を前記複数の候補メニュー項目及び対応する属性に適用することにより、複数の実メニュー項目及び対応する説明を決定するよう構成されたメニュー項目情報処理モジュールと、
   前記決定された実メニュー項目及び対応する説明に基づき、メニューを生成するよう構成されたメニュー生成モジュールと
   を有する管理装置と、
   前記管理装置と通信可能に接続され、前記生成されたメニューを出力するよう構成された出力装置と、
   前記管理装置と通信可能に接続された前記ユーザ入力端末と
   を具備し、
   前記ユーザ入力端末は、光学撮像装置または近距離無線受信機を有し、ユーザのモバイルデバイスに表示された前記ユーザ要求情報を含む視覚的コードを前記光学撮像装置によって読み取るか、または、前記モバイルデバイスに記憶された前記ユーザ要求情報を前記近距離無線受信機によって受信することで、前記ユーザ要求情報を受信する
   メニュー生成システム。
2. 請求項１に記載のメニュー生成システムであって、
   前記出力装置は、紙に前記メニューを出力するよう構成されたプリンタを含む
   メニュー生成システム。
3. 請求項２に記載のメニュー生成システムであって、
   前記プリンタは、前記メニューを再使用可能紙に出力するよう構成された再使用可能紙用のプリンタである
   メニュー生成システム。
4. 請求項１乃至３の何れか一項に記載のメニュー生成システムであって、
   前記ユーザ要求情報は、１以上のユーザ食餌要求を含み、
   前記メニュー項目情報処理モジュールは、前記受信したユーザ要求情報を前記適用する際、候補メニュー項目の原材料及び前記ユーザ食餌要求に基づき、候補メニュー項目を選択する
   メニュー生成システム。
5. 請求項１乃至４の何れか一項に記載のメニュー生成システムであって、
   前記ユーザ要求情報は、１以上のユーザ言語を含み、
   前記メニュー項目情報処理モジュールは、前記受信したユーザ要求情報を前記適用する際、前記１以上のユーザ言語の少なくとも１つで記載された前記対応する説明を取得する
   メニュー生成システム。
6. 請求項１、４、５の何れか一項に記載のメニュー生成システムであって、
   前記ユーザ要求入力モジュールは、複数のユーザから前記ユーザ要求情報を受信するよう構成される
   メニュー生成システム。
7. 飲食店のメニューをリアルタイムに生成するメニュー生成方法であって、
   管理装置により、複数の候補メニュー項目を記憶し、
   前記管理装置により、各前記複数の候補メニュー項目に使用されている少なくとも１以上の原材料を含む、各前記複数の候補メニュー項目のメニュー項目属性を記憶し、
   前記管理装置により、当該管理装置と通信可能に接続されたユーザ入力端末を介して前記メニューに関するユーザの要求を示すユーザ要求情報を受信し、
   前記管理装置により、前記受信したユーザ要求情報を前記複数の候補メニュー項目及び対応する属性に適用することにより、複数の実メニュー項目及び対応する説明を決定し、
   前記管理装置により、前記決定された実メニュー項目及び対応する説明に基づき、メニューを生成し、
   出力装置により、前記生成されたメニューを出力し、
   前記ユーザ入力端末は、光学撮像装置または近距離無線受信機を有し、ユーザのモバイルデバイスに表示された前記ユーザ要求情報を含む視覚的コードを前記光学撮像装置によって読み取るか、または、前記モバイルデバイスに記憶された前記ユーザ要求情報を前記近距離無線受信機によって受信することで、前記ユーザ要求情報を受信する
   メニュー生成方法。

Images