以下、メニュー出力装置等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動作を行うので、再度の説明を省略する場合がある。
(実施の形態1)
本実施の形態において、注文した飲食物の履歴情報を蓄積し、当該注文履歴と飲食物に関する情報と飲食物の属性を示す飲食物属性とを用いて注文のためのメニューを動的に変更するメニュー出力システムについて説明する。
また、本実施の形態において、飲食に関するルールである1以上の飲食ルールを用いて、動的にメニューを変更するメニュー出力システムについて説明する。
また、本実施の形態において、来店人数、ご一緒されているお客様の関係(例えば、家族、恋人、同姓友人等)、お客様のアレルギー情報等のお客様の属性に応じて注文メニューを動的に変更するメニュー出力システムについて説明する。
また、本実施の形態において、食材または飲食物の在庫情報を用いて、メニューを動的に変更するメニュー出力システムについて説明する。
また、本実施の形態において、注文履歴から個人の嗜好を分析し、嗜好の情報を用いてメニューを動的に変更するメニュー出力システムについて説明する。
また、本実施の形態において、メニューの変更の態様として、メニュー項目の順序を変更したり、メニュー項目を削除またはグレーアウトしたり、メニュー項目の一部の表示の変更(金額、量などの変更)を行ったりする場合について説明する。
なお、飲食物とは、例えば、飲食物や、飲料等である。複数の飲食物や飲料等の組合せ構成されるもの(例えば、飲食物のセットやコース等)も、ここでは一の飲食物と考えても良い。
また、飲食店とは、例えば、レストランや、喫茶店、居酒屋等の、飲食物を提供する店舗等である。
図1は、本実施の形態におけるメニュー出力システムの概念図である。メニュー出力システムは、メニュー出力装置1、および1以上のメニュー出力端末2を備える。メニュー出力装置1は、例えば、いわゆるサーバ装置である。また、メニュー出力端末2は、例えば、お客様が保有する端末装置である。メニュー出力端末2は、例えば、いわゆるスマートフォン等の携帯端末、携帯用のパソコン、店舗の席に設置されている注文用の端末等、情報の入出力が行える端末であれば何でも良い。さらに、メニュー出力装置1、および1以上のメニュー出力端末2は、通常、無線、または有線のネットワークで相互に通信可能である。
図2は、本実施の形態におけるメニュー出力システムのブロック図である。メニュー出力装置1は、注文情報受付部101、注文履歴格納部102、注文履歴蓄積部103、飲食物属性情報格納部104、メニュー項目格納部105、ユーザ属性情報受付部106、在庫格納部107、嗜好情報取得部108、ルール格納部109、メニュー取得部110、出力部111を備える。
メニュー出力端末2は、メニュー受信部21、メニュー出力部22、注文受付部23、注文送信部24を備える。
注文情報受付部101は、注文情報を受け付ける。注文情報とは、ユーザが飲食店に対して注文した飲食物を示す情報である。注文情報は、飲食物の識別情報である飲食物識別情報を有する。飲食物識別情報は、飲食物名や、飲食物に割り当てられた数字や文字列で構成されるコード等である。一の注文情報は、一の飲食物識別情報を有しているものであることが好ましいが、複数の飲食物識別情報を有していても良い。ここでのユーザは、個人であっても複数の人で構成されるグループであっても良い。注文情報は、注文した飲食物の数量を示す情報を更に有していても良い。また、注文情報は、ユーザを識別するユーザ識別情報や注文した日時を示す時刻情報を有しても良い。ユーザ識別情報は、例えば、ユーザ名や、ユーザに割り当てられたコード、ユーザの電話番号、ユーザのクレジットカード番号、ユーザの会員番号等である。また、注文情報は、注文を受け付ける店舗の識別情報である店舗識別情報を有していても良い。店舗識別情報は、例えば、店舗名や、店舗に割り当てられたコード、店舗の電話番号等である。また、店舗を経営する法人や個人等の識別情報等であっても良い。また、注文情報は、ユーザが飲食物を注文した順番を示す情報を有していても良い。順番を示す情報は、注文を受け付けた順番が判断可能な情報であれば良く、例えば、注文順番を示す連番等の数値や、注文を受け付けた時刻を含む情報である。また、ここでの時刻を含む情報は、日付の情報だけでも良く、日付の情報を含んでいても良い。順番を示す情報に関しては、以下においても同様である。なお、注文情報がユーザ識別情報を有しない場合、注文情報受付部101は、ユーザ識別情報と注文情報とを受け付けることは好適である。
なお、注文情報受付部101は、店外に設置されているメニュー出力端末2からの注文を受け付けても良い。かかる場合のメニュー出力端末2は、例えば、ユーザが保有している、いわゆるスマートフォンやパソコン等である。
ここで、受け付けとは、タッチパネル、キーボード、マウスなどの入力デバイスから入力された情報の受け付け、有線もしくは無線の通信回線を介して送信された情報の受信、光ディスクや磁気ディスク、半導体メモリなどの記録媒体から読み出された情報の受け付けなどを含む概念である。
また、注文情報の入力手段は、タッチパネルやマウスやメニュー画面によるもの等、何でも良い。注文情報受付部101は、タッチパネル等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。
注文履歴格納部102は、注文履歴情報が格納される。注文履歴情報とは、ユーザが現在来店中の飲食店において、現在の来店中に注文した飲食物の履歴を示す情報であることは好適である。また、注文履歴情報は、現在の来店中に注文情報受付部101が受け付けた注文情報の集合であることは好適である。また、注文履歴情報を構成する各注文情報は、注文情報受付部101が注文情報を受け付けた順番を示す情報と対応付けられて格納されていても良い。また、注文履歴情報は、通常、ユーザ識別情報と対応付けて格納されている。なお、注文履歴情報は、店外に設置されているメニュー出力端末2から送信された情報でも良い。また、注文履歴情報は、後述する過去注文履歴情報を含むと考えても良い。
注文履歴格納部102には、過去注文履歴情報が格納されても良い。過去注文履歴情報は、過去に注文された飲食物の履歴を示す情報である。また、過去注文履歴情報は、ユーザが現在来店中の飲食店において、過去の来店時に注文した飲食物の履歴を示す情報である。過去注文履歴情報は、ユーザの過去の来店時に、注文情報受付部101が受け付けた注文情報の集合であることは好適である。過去注文履歴情報は、この過去注文履歴情報が有する飲食物識別情報が示す飲食物の注文を受け付けたタイミングが異なる点を除けば、上述した注文履歴情報と同様の情報であってもよい。注文履歴格納部102において、注文履歴情報と過去注文履歴情報とはどのように区別されるかは問わない。例えば、注文履歴格納部102に格納されているユーザが注文した飲食物の履歴を示す情報のうちの、現在の来店時よりも前の日時と対応付けられた履歴を示す情報を過去注文履歴情報とし、現在の来店時以降の日時と対応付けられた履歴を示す情報を注文履歴情報としても良い。また、注文履歴情報と過去注文履歴情報とは、異なるフォルダ等に格納されていてもよい。この場合、例えば、ユーザによる来店が終了した時点(例えば、ユーザが注文した飲食物の精算を完了した時点)以降に、注文履歴蓄積部103や図示しない処理部等が、注文履歴格納部102に格納された注文履歴情報を、過去注文履歴情報が格納されているフォルダに移動させるようにしても良い。また、注文履歴情報と過去注文履歴情報とに、異なる識別情報(例えば、注文履歴情報であるか過去注文履歴情報であるかを示すフラグ等の情報)を対応付けて注文履歴格納部に蓄積するようにしても良い。
なお、注文履歴格納部102は、例えば、物理的には分離されている複数の記憶媒体等から構成されていても良く、注文履歴情報と、過去注文履歴情報とが、複数の記憶媒体のうちの異なる記憶媒体にそれぞれ格納されていても良い。
注文履歴格納部102は、不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。なお、かかることは以下の格納部についても同様である。また、注文履歴格納部102に、情報が記憶される過程は問わない。かかることも、他の格納部も同様である。
注文履歴蓄積部103は、注文情報受付部101が受け付けた注文情報を前記注文履歴格納部102に蓄積する。注文履歴蓄積部103は、例えば、注文情報受付部101が受け付けた注文情報を、上述したような受け付けた順番を示す情報と対応付けて注文履歴格納部102に蓄積してもよい。順番を示す情報が時刻である場合、メニュー出力装置1が有する図示しない時計等から現在の時刻を取得するようにすればよい。また、注文履歴蓄積部103は、注文情報の入力を行ったユーザのユーザ識別情報や、注文を受け付けた飲食店の飲食店識別情報と対応付けて注文情報を蓄積するようにしても良い。ユーザ識別情報は、例えば、注文を行うユーザがメニュー出力装置1にログイン等を行う際に入力したユーザ識別情報を用いる。また、飲食店識別情報は、例えば、予め図示しない記憶媒体等に蓄積されている飲食店識別情報を読み出す。ユーザが現在の来店中に受け付けた注文情報は、例えば、注文履歴情報として注文履歴格納部102に蓄積(例えば、追記)される。また、例えば、ユーザが来店を終えた後には、蓄積された注文履歴情報が過去注文履歴情報となる。
注文履歴蓄積部103は、通常、MPUやメモリ等から実現され得る。注文履歴蓄積部103の処理手順は、通常、ソフトウェアで実現され、当該ソフトウェアはROM等の記録媒体に記録されている。但し、ハードウェア(専用回路)で実現しても良い。
飲食物属性情報格納部104は、1以上の飲食物属性情報が格納される。飲食物属性情報とは、飲食物識別情報と対応付けられた情報であって、飲食物識別情報が示す飲食物の属性を示す情報である。飲食物属性情報は、例えば、飲食物の種類(オードブル、メイン、デザート等)、飲食物の材料の種類(野菜、肉類、スープ等)、カロリーの値、調理方法、分野、重量等である。
メニュー項目格納部105は、1以上のメニュー項目が格納される。メニュー項目は、飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である。メニュー項目は、例えば、「<飲食物識別情報>唐揚げ,<価格>300円,<飲食物属性情報><カロリー>500KCal,<ジャンル>揚げ物,<材料>鶏肉,・・・</飲食物属性情報>」である。
また、メニュー項目は、注文履歴情報、嗜好情報、ユーザ属性情報のうちの1以上の情報に基づいて、その内容が変更されても良い。かかる場合、メニュー項目は、例えば、内容を変更するための条件である内容変更条件、変更する内容に関する情報である変更内容情報を有する。メニュー項目は、例えば、「<飲食物識別情報>唐揚げ,<価格>300円,<内容変更条件>注文履歴情報に2以上の「<飲食物識別情報>唐揚げ」が存在,<変更内容情報>価格=100+(200−50×N),<飲食物属性情報><カロリー>500KCal,<ジャンル>揚げ物,<材料>鶏肉,・・・</飲食物属性情報>」である。かかるメニュー項目のうちの「<内容変更条件>注文履歴情報に2以上の「<飲食物識別情報>唐揚げ」が存在」は、唐揚げを2以上注文していることを示す。また、「<変更内容情報>価格=100+(200−50×N)」は、「価格=100+(200−50×N)」(Nは注文回数)により、価格が算出されることを示す。なお、<変更内容情報>は数式であるが、値など、他の表現形式でも良いことは言うまでもない。
また、メニュー項目は、メニュー項目内容と内容選択条件とを有する2以上のメニュー項目部品であっても良い。メニュー項目内容とは、出力されるメニュー項目の内容を示す情報である。また、選択条件は、メニュー項目内容が選択される条件を示す情報である。メニュー項目を構成する2つのメニュー項目部品は、例えば、「<メニュー項目内容><飲食物識別情報>唐揚げ,<価格>300円</メニュー項目内容>,<選択条件>総額2000円未満」「<メニュー項目内容><飲食物識別情報>唐揚げ,<価格>250円</メニュー項目内容>,<選択条件>総額2000円以上」である。かかるメニュー項目は、総額2000円未満の間は、唐揚げの価格が300円のメニュー項目が選択され、総額2000円以上の場合は唐揚げの価格が250円のメニュー項目が選択されることを示す。なお、2以上のメニュー項目部品を有するメニュー項目を、適宜、選択的メニュー項目という。また、総額とは、ユーザが注文した飲食物の価格の合計である。
ユーザ属性情報受付部106は、ユーザの属性を示す情報であるユーザ属性情報を受け付ける。ユーザ属性情報とは、例えば、来店人数、一緒に来店された複数のユーザ(お客様)の関係(例えば、家族、恋人、同姓友人など)、ユーザのアレルギーに関する情報であるアレルギー情報(そばアレルギー等)などである。また、ユーザ属性情報受付部106は、通常、受け付けたユーザ属性情報を、ユーザ識別情報と対応付けて、図示しない記録媒体に一時蓄積する。なお、ユーザ属性情報受付部106は、メニュー出力端末2から、ユーザ属性情報を受信しても良い。また、ユーザ属性情報は、ユーザ識別情報を含んでも良いし、ユーザ識別情報と対応付いていても良い。ユーザ属性情報がユーザ識別情報と対応付いている場合、ユーザ属性情報受付部106は、ユーザ識別情報とユーザ属性情報とを受け付ける。
また、ユーザ属性情報を受け付ける手段は何でも良い。ユーザ属性情報受付部106は、例えば、無線または有線の通信手段により、ユーザ属性情報を受け付ける。
在庫格納部107は、飲食物に関する在庫状況を示す情報である在庫情報が、飲食物の飲食物識別情報と対応付けて格納されている。なお、在庫格納部107の在庫情報は、飲食物の消費に従って、図示しない手段により更新される。在庫情報の更新は、通常、人手により行われるが、在庫情報の自動チェック機能(図示しない手段による)を有し、自動的に行われても良い。
嗜好情報取得部108は、過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する。嗜好情報とは、例えば、飲食物属性情報、飲食物属性情報を選択するパターンを示す情報である。嗜好情報取得部108は、例えば、ある店舗に訪問の度に注文されている飲食物のジャンル(「種類」と言っても良い。)、またはある店舗に訪問の度に注文されている飲食物の飲食物識別情報を取得する。かかる場合、嗜好情報はジャンル、または飲食物識別情報である。そして、嗜好情報取得部108は、嗜好情報とユーザ識別情報を対応付けて保持することは好適である。
ルール格納部109は、1以上の飲食ルールを格納し得る。飲食ルールとは、飲食物属性情報を有するルールであり、飲食に関するルールである。飲食ルールは、食べる順序に関するルール(順序ルールという)、食べた飲食物の総量に関するルール(総量ルールという)、特定の飲食物属性情報に対応する飲食物の総量に関するルール(特定総量ルールという)などである。順序ルールは、例えば、「<順序><ジャンル>オードブル,<ジャンル>魚類,<ジャンル>肉類,<ジャンル>デザート,<ジャンル>ドリンク</順序>」など、飲食の順序を示すルールである。本ルールは、「オードブル、魚類、肉類、デザート、ドリンク」の順に、飲食することを示す。また、総量ルールは、例えば、「<カロリー>1000KCal以下」、「<重量>1kg以下」などである。「<カロリー>1000KCal以下」は、一回の来店において、飲食する総カロリーが1000KCal以下であることを示す。また、「<重量>1kg以下」は、来店以降に飲食した飲食物の総重量が1kg以下であることを示す。また、特定総量ルールは、例えば、「<総量 ジャンル=ビール>3杯以下」などである。「<総量 ジャンル=ビール>3杯以下」は、ビールは3杯以下に押さえること(4杯以上のビールは飲まないこと)を示す。なお、飲食ルールの記載方法やデータ構造は問わない。
また、1以上の飲食ルールは、ユーザ毎に管理されていることは好適である。つまり、飲食ルールとユーザ識別情報とは、対応付けて格納されていることは好適である。かかる場合、ユーザ毎に適用される飲食ルールが異なることになる。
また、ルール格納部109は、ユーザ識別情報と対応付けられている飲食ルールと、ユーザ識別情報と対応付けられていない飲食ルールの両方を含んでも良い。ユーザ毎に適用される飲食ルールが異なる場合、ダイエットを実施中のユーザは、総カロリーが500KCal以下になることをルールとして保持しており、他のユーザは総カロリーについての制約が存在しない、等の処理が可能となる。また、ユーザによって、飲食する順序を変えた順序ルールが存在する場合、ユーザの嗜好に応じた飲食物の提供が可能となる。また、ユーザ識別情報と対応付けられていない飲食ルールは、飲食店の都合(例えば、希少価値の高い飲食物は、一人1個まで等)を、すべてのユーザに課すために有効である。
メニュー取得部110は、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報と、飲食物属性情報格納部104に格納された飲食物属性情報とに応じた態様のメニューを取得する。つまり、メニュー取得部110は、通常、注文がなされる毎に、異なるメニューを取得する。なお、本明細書において、メニューとは、注文する画面を構成するための情報と指す場合、注文するメニュー画面を指す場合等がある。
また、さらに具体的には、メニュー取得部110は、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報を1以上の飲食ルールに適用し、注文履歴情報と飲食物属性情報とに応じた態様のメニューを取得する。例えば、飲食ルールが、順序ルール「<順序><ジャンル>オードブル,<ジャンル>魚類,<ジャンル>肉類,<ジャンル>デザート,<ジャンル>ドリンク</順序>」である場合、メニュー取得部110は、第一にオードブルのメニューを構成し、第二に魚類のメニューを構成し、第三に肉類のメニューを構成し、第四にデザートのメニューを構成し、最後にドリンクのメニューを構成する。また、例えば、飲食ルールが、特定総量ルール「<総量 ジャンル=ビール>3杯以下」である場合、3杯のビールが注文された後は、メニュー取得部110は、ビールのメニュー項目を用いずに、ビールのメニュー項目が存在しないメニューを構成する。
メニュー取得部110は、さらに、ユーザ属性情報受付部106が受け付けたユーザ属性情報に応じた態様のメニューを取得する。ユーザ属性情報が「そばアレルギー」である場合、メニュー取得部110は、食材識別情報として「そば」を有するメニュー項目、および飲食物識別情報「そば」のメニュー項目を取得せず、かかるメニュー項目が存在しないメニューを構成する。
また、メニュー取得部110は、在庫格納部107の在庫情報に応じた態様のメニューを取得する。
メニュー取得部110は、嗜好情報取得部108が取得した嗜好情報に応じた態様のメニューを取得する。嗜好情報が「ビールが大好き」であることを示す情報である場合、例えば、メニュー取得部110は、「ビール」のメニュー項目を選択しやすい位置に配置したり、「ビール」の表示を目立つ表示にしたり、中ジョッキの代わりに大ジョッキのビールのメニュー項目にしたりする。
メニュー取得部110は、メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得しても良い。デフォルトの配置に関する情報は、メニュー項目格納部105が保持していても良いし、メニュー取得部110が保持していても良い。
メニュー取得部110は、メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得しても良い。
メニュー取得部110は、メニュー項目の一部の値を変更したメニューを取得しても良い。
メニュー項目が選択的メニュー項目である場合、メニュー取得部110は、注文履歴情報と飲食物属性情報とを選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成する。
なお、メニュー取得部110が取得したメニュー項目から出力するメニューを構成する技術は公知技術であるので、詳細な説明を省略する。メニュー取得部110は、例えば、メニュー項目を配置するためのテンプレートの情報を保持しており、かかるテンプレートの情報に、メニュー項目を代入して、メニューを構成する。
出力部111は、メニュー取得部110が取得したメニューを出力する。取得したメニューとは、構成したメニューと同意義である。ここで、出力とは、通常、メニュー出力端末2への送信であるが、ディスプレイへの表示、プロジェクターを用いた投影、プリンタでの印字、音出力、記録媒体への蓄積、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。
出力部111は、通常、無線または有線の通信手段により実現され得る。
メニュー出力端末2を構成するメニュー受信部21は、メニュー出力装置1からメニューを受信する。メニュー受信部21は、通常、無線または有線の通信手段で実現されるが、放送を受信する手段で実現されても良い。
メニュー出力部22は、メニュー受信部21が受信したメニューを出力する。ここで、出力とは、通常、ディスプレイへの表示であるが、プロジェクターを用いた投影、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。
メニュー出力部22は、ディスプレイ等の出力デバイスを含むと考えても含まないと考えても良い。メニュー出力部22は、出力デバイスのドライバーソフトまたは、出力デバイスのドライバーソフトと出力デバイス等で実現され得る。
注文受付部23は、ユーザからの注文情報を受付ける。注文情報の受け付けは、通常、メニュー項目の指示により実現される。注文情報(メニュー項目の指示)の入力手段は、タッチパネルへのタッチ、マウス、またはメニュー画面によるもの等、何でも良い。注文受付部23は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。
注文送信部24は、注文受付部23が受け付けた注文情報をメニュー出力装置1に送信する。注文送信部24は、通常、無線または有線の通信手段で実現されるが、放送手段で実現されても良い。
次に、メニュー出力システムの動作について説明する。まず、メニュー出力装置1の動作について、図3のフローチャートを用いて説明する。
(ステップS301)注文情報受付部101は、メニュー出力端末2から注文情報を受け付けたか否かを判断する。なお、ここでの受け付けは、受信である。注文情報を受信すればステップS302に行き、注文情報を受信しなければステップS305に行く。なお、注文情報受付部101は、通常、ユーザ識別情報も共に受信する。
(ステップS302)注文履歴蓄積部103は、ステップS301で受信した注文情報を、ユーザ識別情報と対応付けて、注文履歴格納部102に蓄積する。
(ステップS303)メニュー取得部110は、ユーザ識別情報により識別されるユーザ向けのメニューを構成する。かかる処理をメニュー構成処理という。メニュー構成処理について、図4のフローチャートを用いて説明する。
(ステップS304)出力部111は、ステップS303で構成されたメニューを、メニュー出力端末2に送信する。なお、このメニュー出力端末2は、注文情報を送信してきたメニュー出力端末2である。
(ステップS305)ユーザ属性情報受付部106は、ユーザ属性情報を受信したか否かを判断する。ユーザ属性情報を受信すればステップS306に行き、ユーザ属性情報を受信しなければステップS307に行く。なお、本ステップで、ユーザ属性情報受付部106は、ユーザ識別情報もユーザ属性情報とともに受信することが好適である。
(ステップS306)ユーザ属性情報受付部106は、受け付けたユーザ属性情報を、ユーザ識別情報と対応付けて、図示しない記録媒体に一時蓄積する。なお、図示しない記録媒体は、例えば、ユーザ属性情報受付部106が保持している。
(ステップS307)嗜好情報取得部108は、嗜好情報を取得するタイミングであるか否かを判断する。嗜好情報を取得するタイミングであればステップS308に行き、嗜好情報を取得するタイミングでなければステップS309に行く。なお、嗜好情報を取得するタイミングは、例えば、メニュー出力装置1が、ユーザ識別情報で識別されるユーザが来店したことを示す情報を受信した場合である。また、嗜好情報を取得するタイミングは、例えば、ステップS301で、一のユーザ識別情報に対して、メニュー出力装置1が注文情報を、一の日に初めて受信した場合等である。また、嗜好情報を取得するタイミングは、例えば、図示しない手段が、ユーザの決済が完了した旨の情報を受信した場合である。
(ステップS308)嗜好情報取得部108は、嗜好情報取得処理を行う。嗜好情報取得処理について、図9のフローチャートを用いて説明する。
(ステップS309)図示しない受付手段が、在庫情報を変更する指示を受け付けたか否かを判断する。在庫情報を変更する指示を受け付ければステップS310に行き、在庫情報を変更する指示を受け付けなければステップS311に行く。なお、在庫情報を変更する指示は、変更内容を有する。変更内容は、変更する対象、および変更のための情報を有する。在庫情報を変更する指示は、例えば、「変更 <対象>鶏肉 <変更データ>0」である。「変更 <対象>鶏肉 <変更データ>0」は、食材「鶏肉」の在庫がなくなったことを示す。また、在庫情報を変更する指示は、例えば、「変更 <対象>から揚げ <変更データ>0」である。本指示は、飲食物識別情報「から揚げ」の在庫がなくなったことを示す。また、図示しない受付手段は、注文情報受付部101から、当該注文情報受付部101が受け付けた注文情報を用いて在庫情報を変更する指示を受け付けることは好適である。注文情報受付部101が、「注文 <対象>から揚げ <数量>2」を受け付けた場合、図示しない受付手段は、注文情報受付部101から、「変更 <対象>から揚げ <内容>$在庫−2」を受け付ける。ここで「$在庫」は、現在の「<対象>から揚げ」の在庫数を示す変数である。
(ステップS310)図示しない修正手段が、ステップS309において受け付けた在庫情報を変更する指示が有する変更内容に従って、在庫格納部107の在庫情報を変更する。
(ステップS311)図示しない受付手段は、メニューの出力指示を、メニュー出力端末2から受信したか否かを判断する。メニューの出力指示を受信すればステップS303に行き、受信しなければステップS301に戻る。
なお、図3のフローチャートにおいて、ステップS311でYesの場合、ステップS303に行ったが、メニュー取得部110がデフォルトの1以上のメニュー項目をメニュー項目格納部105から読み出し、メニューを構成しても良い。そして、出力部111が当該メニューをメニュー出力端末2に送信しても良い。
また、図3のフローチャートにおいて、注文情報を受信するごとに、動的にメニューを構成した。しかし、他のタイミングでメニューを構成しても良い。他のタイミングとは、例えば、定期的(10分に1回など)、ユーザからの指示があった際などである。
さらに、図3のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。
次に、ステップS303のメニュー構成処理について、図4のフローチャートを用いて説明する。
(ステップS401)メニュー取得部110は、メニューを出力する先のユーザを識別するユーザ識別情報を取得する。なお、このユーザ識別情報は、例えば、ステップS301で受信されたユーザ識別情報である。
(ステップS402)メニュー取得部110は、ステップS401で取得したユーザ識別情報に対応する注文履歴情報を、注文履歴格納部102から読み出す。
(ステップS403)メニュー取得部110は、ステップS401で取得したユーザ識別情報に対応するユーザ属性情報が存在するか否かを判断する。ユーザ属性情報が存在すればステップS404に行き、ユーザ属性情報が存在しなければステップS405に行く。
(ステップS404)メニュー取得部110は、ステップS401で取得したユーザ識別情報に対応するユーザ属性情報を取得する。なお、このユーザ属性情報の取得処理は、ユーザ属性情報受付部106が行っても良い。
(ステップS405)メニュー取得部110は、在庫格納部107の在庫情報を取得する。
(ステップS406)メニュー取得部110は、ステップS401で取得したユーザ識別情報に対応する嗜好情報が存在するか否かを判断する。嗜好情報が存在すればステップS407に行き、嗜好情報が存在しなければステップS408に行く。
(ステップS407)メニュー取得部110は、ユーザ識別情報に対応する嗜好情報を取得する。
(ステップS408)ルール格納部109に飲食ルールが存在するか否かを判断する。飲食ルールが存在すればステップS409に行き、飲食ルールが存在しなければステップS410に行く。
(ステップS409)メニュー取得部110は、飲食ルールを適用したメニュー構成処理を行う。かかる処理について、図5のフローチャートを用いて説明する。上位処理にリターンする。
(ステップS410)メニュー取得部110は、飲食ルールを適用しないメニュー構成処理を行う。かかる処理について、図6のフローチャートを用いて説明する。上位処理にリターンする。
なお、図4のフローチャートにおいて、注文履歴情報、ユーザ属性情報、在庫情報、嗜好情報、飲食ルールを用いてメニューを構成した。しかし、これらのすべての情報を用いずに、注文履歴情報等のうち、1以上の情報を用いて、動的にメニューを構成しても良い。
次に、ステップS409の飲食ルールを適用したメニュー構成処理について、図5のフローチャートを用いて説明する。上位処理にリターンする。
(ステップS501)メニュー取得部110は、ルール格納部109に順序ルールが存在するか否かを判断する。順序ルールが存在すればステップS502に行き、順序ルールが存在しなければステップS504に行く。
(ステップS502)メニュー取得部110は、順序ルールに従って、飲食物識別情報または種類識別情報にランクを付与する。ここでは、メニュー取得部110は、次に選択される可能性が高い飲食物識別情報または種類識別情報に高い値のランクを付与する。また、メニュー取得部110は、既に選択された飲食物識別情報または種類識別情報や、順序ルールに従えば、選択されるのがかなり先になる飲食物識別情報または種類識別情報に低い値(例えば、選択されないような値)のランクを付与する。なお、ランクとは、メニュー項目の出現態様に差異を設けるための指標であり、ここでは、ランクの値が大きいメニュー項目ほど、目立つ態様または選択されやすい態様で、メニュー項目が表示される、とする。
(ステップS503)メニュー取得部110は、各メニュー項目が有する飲食物識別情報のランクまたは種類識別情報のランクを、各メニュー項目のランクとして付与する。
(ステップS504)メニュー取得部110は、ルール格納部109に総量ルールが存在するか否かを判断する。総量ルールが存在すればステップS505に行き、総量ルールが存在しなければステップS513に行く。
(ステップS505)メニュー取得部110は、ユーザ識別情報に対応する注文履歴情報であり、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文履歴情報を、注文履歴格納部102から読み出す。そして、メニュー取得部110は、読み出した注文履歴情報から、対象となる総量(例えば、カロリーの総量)である摂取総量を取得する。なお、メニュー取得部110は、例えば、注文履歴情報に含まれる各注文情報の属性値である対象の値を取得し、加算する。
(ステップS506)メニュー取得部110は、カウンタiに1を代入する。
(ステップS507)メニュー取得部110は、i番目のメニュー項目が存在するか否かを判断する。i番目のメニュー項目が存在すればステップS508に行き、存在しなければステップS519に行く。
(ステップS508)メニュー取得部110は、i番目のメニュー項目に対応する対象となる値であり、飲食物を摂取した場合の量(例えば、カロリー)を、飲食物属性情報格納部104から取得する。
(ステップS509)メニュー取得部110は、ステップS505で取得した摂取総量と、ステップS508で取得した摂取した場合の量とを加算し、総量ルールに含まれる制限の量の範囲内であるか否か(総量ルールに合致するか否か)を判断する。総量ルールに合致する場合はステップS510に行き、合致しない場合はステップS511に行く。
(ステップS510)メニュー取得部110は、i番目のメニュー項目に、総量ルールに合致する場合に対応するランクを付加する。なお、例えば、メニュー取得部110は、i番目のメニュー項目が選択されやすくなるように、ランクを閾値分だけ増加させる(例えば、「+5」する)。
(ステップS511)メニュー取得部110は、i番目のメニュー項目に、総量ルールに合致しない場合に対応するランクを付加する。なお、例えば、メニュー取得部110は、i番目のメニュー項目が、絶対に選択されやすくなるように、ランクを閾値分だけ減少させる(例えば、「−∞」する)。なお、ここで、メニュー取得部110は、i番目のメニュー項目を削除しても良い。
(ステップS512)メニュー取得部110は、カウンタiを1、インクリメントする。ステップS507に戻る。
(ステップS513)メニュー取得部110は、ルール格納部109に特定総量ルールが存在するか否かを判断する。特定総量ルールが存在すればステップS514に行き、特定総量ルールが存在しなければステップS523に行く。
(ステップS514)メニュー取得部110は、注文履歴格納部102に存在する注文履歴情報であり、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文履歴情報であり、特定総量ルールに含まれる特定の飲食物の注文履歴情報を読み出す。そして、メニュー取得部110は、当該読み出した注文履歴情報から、対象となる総量(例えば、注文数)である摂取総量を取得する。なお、メニュー取得部110は、例えば、注文履歴情報に含まれる各注文情報の属性値である対象の値を取得し、加算する。
(ステップS515)メニュー取得部110は、特定の飲食物を飲食物識別情報または種類識別情報として有するメニュー項目を、メニュー項目格納部105から取得する。
(ステップS516)メニュー取得部110は、カウンタiに1を代入する。
(ステップS517)メニュー取得部110は、i番目のメニュー項目が存在するか否かを判断する。i番目のメニュー項目が存在すればステップS518に行き、存在しなければステップS523に行く。
(ステップS518)メニュー取得部110は、i番目のメニュー項目に対応する飲食物の摂取量(対象となる特定の量であり、例えば、注文数)を取得する。
(ステップS519)メニュー取得部110は、ステップS514で取得した特定の飲食物の摂取総量と、ステップS518で取得した量とを加算し、特定総量ルールに含まれる制限の量の範囲内であるか否か(特定総量ルールに合致するか否か)を判断する。特定総量ルールに合致する場合はステップS520に行き、合致しない場合はステップS521に行く。
(ステップS520)メニュー取得部110は、i番目のメニュー項目に、特定総量ルールに合致する場合に対応するランクを付加する。なお、例えば、メニュー取得部110は、i番目のメニュー項目が選択されやすくなるように、ランクを閾値分だけ増加させる(例えば、「+10」する)。
(ステップS521)メニュー取得部110は、i番目のメニュー項目に、特定総量ルールに合致しない場合に対応するランクを付加する。なお、例えば、メニュー取得部110は、i番目のメニュー項目が、絶対に選択されやすくなるように、ランクを閾値分だけ減少させる(例えば、「−∞」する)。なお、ここで、メニュー取得部110は、i番目のメニュー項目を削除しても良い。
(ステップS522)メニュー取得部110は、カウンタiを1、インクリメントする。ステップS517に戻る。
(ステップS523)メニュー取得部110は、飲食ルールを適用しないメニュー構成処理を行う。飲食ルールを適用しないメニュー構成処理について、図6のフローチャートを用いて説明する。上位処理にリターンする。
なお、図5のフローチャートにおいて、順序ルール、総量ルール、および特定総量ルールが、最大それぞれ1個存在する場合について説明した。しかし、ルール格納部109は、2以上の各種類のルールを格納していても良い。順序ルールが2以上存在する場合、ステップS502からステップS503が順序ルールの数だけループする。また、総量ルールが2以上存在する場合、ステップS505からステップS512が総量ルールの数だけループする。さらに、特定総量ルールが2以上存在する場合、ステップS514からステップS522が特定総量ルールの数だけループする。
また、図5のフローチャートにおいて、飲食ルールを用いて、メニュー項目にランクを付与したが、かかる処理方法は一例であることは言うまでもない。図5のフローチャートにおいて、飲食ルールに合致しないメニュー項目を、非表示としたり、グレーアウトしたりしても良いし、直ぐに選択されにくい位置に配置する等しても良い。
次に、ステップS410の飲食ルールを適用しないメニュー構成処理について、図6のフローチャートを用いて説明する。
(ステップS601)メニュー取得部110は、カウンタiに1を代入する。
(ステップS602)メニュー取得部110は、i番目のメニュー項目が存在するか否かを判断する。i番目のメニュー項目が存在すればステップS603に行き、存在しなければステップS611に行く。
(ステップS603)メニュー取得部110は、i番目のメニュー項目がユーザ属性情報を満たすか否かを判断する。ユーザ属性情報を満たす場合はステップS604に行き、ユーザ属性情報を満たさない場合はステップS605に行く。
(ステップS604)メニュー取得部110は、ユーザ属性情報を満たす場合に対応するように、i番目のメニュー項目のランクを変更する。例えば、i番目のメニュー項目が選択され易くなるように、メニュー取得部110は、ランクを閾値分だけ増加させる(例えば、「+5」する)。
(ステップS605)メニュー取得部110は、i番目のメニュー項目に、ユーザ属性情報を満たさない場合に対応するランクを付加する。なお、例えば、メニュー取得部110は、i番目のメニュー項目が、選択されにくくなる、または絶対に選択されやすくなるように、ランクを閾値分だけ減少させる(例えば、「−∞」する)。なお、ここで、メニュー取得部110は、i番目のメニュー項目を削除しても良い。
(ステップS606)メニュー取得部110は、i番目のメニュー項目が、本ユーザの嗜好情報に対応するか(合致するか)否かを判断する。嗜好情報に対応する場合はステップS607に行き、嗜好情報に対応しない場合はステップS608に行く。
(ステップS607)メニュー取得部110は、嗜好情報に対応する場合に合致するように、i番目のメニュー項目のランクを変更する。例えば、i番目のメニュー項目が選択され易くなるように、メニュー取得部110は、ランクを閾値分だけ増加させる(例えば、「+8」する)。なお、嗜好情報に対応しない場合、メニュー取得部110は、ランクを閾値分だけ減少させる、メニュー項目を削除する等の処理を行っても良い。
(ステップS608)メニュー取得部110は、在庫情報を用いて、i番目のメニュー項目に対応する飲食物が提供可能であるか否かを判断する。提供可能である場合はステップS610に行き、提供可能でない場合はステップS609に行く。なお、メニュー取得部110は、i番目のメニュー項目の飲食物識別子、または食材の情報を取得する。そして、メニュー取得部110は、当該飲食物識別子で識別される飲食物、または当該食材が、在庫情報を参照して、在庫が存在するか否かを判断する。そして、メニュー取得部110は、在庫が存在しない場合は、提供不可能である、と判断する。
(ステップS609)メニュー取得部110は、i番目のメニュー項目を削除する。なお、メニュー取得部110は、i番目のメニュー項目が選択されないように、ランクを変更しても良い。
(ステップS610)メニュー取得部110は、カウンタiを1、インクリメントする。ステップS602に戻る。
(ステップS611)メニュー取得部110は、ランクを用いたメニュー構成処理を行う。かかる処理について、図7のフローチャートを用いて説明する。
(ステップS612)メニュー取得部110は、選択的メニュー項目処理を行う。選択的メニュー項目処理について、図8のフローチャートを用いて説明する。上位処理にリターンする。
なお、図6のフローチャートにおいて、図5のフローチャートと同様に、メニュー項目にランクを付与したが、かかる処理方法は一例であることは言うまでもない。図6のフローチャートにおいて、直ぐに非表示としたり、直ぐにグレーアウトしたりしても良いし、直ぐに選択されにくい位置に配置する等しても良い。
次に、テップS611のランクを用いたメニュー構成処理について、図7のフローチャートを用いて説明する。
(ステップS701)メニュー取得部110は、メニューの変更が、メニュー項目の配置の変更であるか否かを判断する。メニュー項目の配置の変更である場合はステップS702に行き、メニュー項目の配置の変更でない場合はステップS703に行く。
(ステップS702)メニュー取得部110は、各メニュー項目に対応するランクを用いて、メニュー項目の集合をソートして、配置を変更する。つまり、かかる処理により、ランクが大きいメニュー項目が、選択されやすい位置(例えば、上部)に配置される。上位処理にリターンする。
(ステップS703)メニュー取得部110は、メニューの変更が、ランクの低いメニュー項目や選択されてはいけないメニュー項目を、非選択となるような変更であるか否かを判断する。非選択となるような変更である場合はステップS704に行き、非選択となるような変更でない場合はステップS705に行く。
(ステップS704)メニュー取得部110は、閾値以下のランクのメニュー項目を非選択の状態とする。なお、非選択の状態とする処理は、例えば、メニュー項目の削除、グレイアウトとする処理等である。上位処理にリターンする。
(ステップS705)メニュー取得部110は、メニューの変更が、メニュー項目の内容の変更であるか否かを判断する。内容の変更である場合はステップS706に行き、内容の変更でない場合は上位処理にリターンする。
(ステップS706)メニュー取得部110は、カウンタiに1を代入する。
(ステップS707)メニュー取得部110は、i番目のメニュー項目が存在するか否かを判断する。i番目のメニュー項目が存在すればステップS708に行き、存在しなければ上位処理にリターンする。
(ステップS708)メニュー取得部110は、i番目のメニュー項目が内容変更の候補であるメニュー項目か否かを判断する。内容変更の候補である場合はステップS709に行き、内容変更の候補でない場合はステップS712に行く。なお、メニュー取得部110は、メニュー項目の情報を参照し、内容変更の候補のフラグを検知して、内容変更の候補であるメニュー項目か否かを判断しても良いし、内容変更条件や変更内容情報を参照して、内容変更の候補であるメニュー項目か否かを判断しても良い。
(ステップS709)メニュー取得部110は、本ユーザ識別情報に対応する注文履歴情報のうち、内容変更条件に関連する情報を取得する。例えば、内容変更条件が、「ビールの注文数>=3」である場合、注文履歴情報が有する注文情報のうち、「<飲食物識別情報>ビール」を含む注文情報を取得する。
(ステップS710)メニュー取得部110は、ステップS709で取得した内容変更条件に関連する情報が、i番目のメニュー項目に対応する内容変更条件に合致するか否かを判断する。例えば、内容変更条件「ビールの注文数>=3」であり、ステップS709で取得した内容変更条件に関連する情報(ここでは、ビールの注文情報)が「ビールの注文数=3(注文情報が3つ存在)」を示す場合、メニュー取得部110は、内容変更条件に合致すると判断する。
(ステップS711)メニュー取得部110は、変更内容情報を取得する。そして、メニュー取得部110は、変更内容情報に従って、i番目のメニュー項目の内容を変更する。
(ステップS712)メニュー取得部110は、カウンタiを1、インクリメントする。ステップS707に戻る。
なお、図7のフローチャートにおいて、3つのメニューの変更方法について説明した。しかし、ランクに応じて、選択されやすさが変化するようなメニューの変更であれば、他の処理でも良い。また、3つのメニューの変更方法のうち、2以上の変更方法を組み合わせても良い。さらに、例えば、3つのメニューの変更方法のうち選択する変更方法をどれにするかについて、メニュー取得部110は、予め情報を保持している、とする。
次に、ステップS612の選択的メニュー項目処理について、図8のフローチャートを用いて説明する。
(ステップS801)メニュー取得部110は、メニュー項目格納部105または、メモリ上のメニュー項目(消去されていないメニュー項目)から、選択的メニュー項目を取得する。
(ステップS802)メニュー取得部110は、カウンタiに1を代入する。
(ステップS803)メニュー取得部110は、ステップS801で取得した選択的メニュー項目のうち、i番目の選択的メニュー項目が存在するか否かを判断する。i番目の選択的メニュー項目が存在すればステップS804に行き、i番目の選択的メニュー項目が存在しなければ上位処理にリターンする。
(ステップS804)メニュー取得部110は、i番目の選択的メニュー項目が有する選択条件に関連する情報を、注文履歴情報等から取得する。注文履歴情報等とは、注文履歴情報だけでも良いし、ユーザ属性情報、嗜好情報、在庫情報等を含んでも良い。
(ステップS805)メニュー取得部110は、カウンタjに1を代入する。
(ステップS806)メニュー取得部110は、i番目の選択的メニュー項目の中に、j番目のメニュー項目部品が存在するか否かを判断する。j番目のメニュー項目部品が存在すればステップS807に行き、j番目のメニュー項目部品が存在しなければステップS810に行く。
(ステップS807)メニュー取得部110は、j番目のメニュー項目部品に対応する選択条件を取得する。
(ステップS808)メニュー取得部110は、ステップS804で取得した情報が、ステップS807で取得した選択条件に合致するか否かを判断する。選択条件に合致する場合はステップS809に行き、選択条件に合致しない場合はステップS811に行く。
(ステップS809)メニュー取得部110は、j番目のメニュー項目部品を、i番目のメニュー項目の内容として取得する。
(ステップS810)メニュー取得部110は、カウンタiを1、インクリメントする。ステップS803に戻る。
(ステップS811)メニュー取得部110は、カウンタjを1、インクリメントする。ステップS806に戻る。
次に、ステップS308の嗜好情報取得処理について、図9のフローチャートを用いて説明する。
(ステップS901)嗜好情報取得部108は、ユーザ識別情報を取得する。
(ステップS902)嗜好情報取得部108は、ステップS901で取得したユーザ識別情報に対応する注文情報であって、現在来店中の飲食店に過去に来店した際に注文した内容に関する1以上の注文情報を、注文履歴格納部102から取得する。なお、ここでの1以上の注文情報も、注文履歴情報と言っても良い。
(ステップS903)嗜好情報取得部108は、カウンタiに1を代入する。
(ステップS904)嗜好情報取得部108は、i番目の飲食物識別情報が存在するか否かを判断する。なお、嗜好情報取得部108は、例えば、飲食物属性情報格納部104の情報を参照して、かかる判断を行う。
(ステップS905)嗜好情報取得部108は、i番目の飲食物識別情報で識別される飲食物の注文の頻度を示す頻度情報を、ステップS902で取得した注文履歴情報から取得する。なお、頻度情報は、例えば、来店した日のうち、どの程度の割合の日で、注文しているか否かを示す情報でも良いし、注文した日の総数でも良いし、注文した総回数(1日に2回以上、注文する場合もある)でも良い。また、嗜好情報取得部108は、注文の量に関する量情報も、ステップS902で取得した注文履歴情報から取得しても良い。なお、量情報は、例えば、注文した総重量、総杯数などである。
(ステップS906)嗜好情報取得部108は、頻度情報、または量情報、または頻度情報と量情報を用いて、i番目の飲食物識別情報で識別される飲食物の好きな度合いを示す嗜好レベルを取得する。なお、頻度情報、または量情報が大きい値を示すほど、通常、嗜好レベルが高くなる。
(ステップS907)嗜好情報取得部108は、i番目の飲食物識別情報と、ステップS906で取得した嗜好レベルとを対応付けて蓄積する。なお、嗜好情報取得部108は、図示しない記録媒体に飲食物識別情報と嗜好レベルとを対応付けて蓄積する。
(ステップS908)嗜好情報取得部108は、カウンタiを1、インクリメントする。ステップS904に戻る。
(ステップS909)嗜好情報取得部108は、カウンタiに1を代入する。
(ステップS910)嗜好情報取得部108は、i番目の種類識別情報が存在するか否かを判断する。なお、嗜好情報取得部108は、例えば、飲食物属性情報格納部104の情報を参照して、かかる判断を行う。なお、種類識別情報とは、飲食物の種類を識別する情報であり、ジャンル識別情報と言っても良い。飲食物の種類とは、どのような分類方法によってグループ化されたものでも良い。
(ステップS911)嗜好情報取得部108は、i番目の種類識別情報で識別される飲食物の注文の頻度を示す頻度情報を、ステップS902で取得した注文履歴情報から取得する。また、嗜好情報取得部108は、i番目の種類識別情報で識別される飲食物の注文の量に関する量情報も、ステップS902で取得した注文履歴情報から取得しても良い。
(ステップS912)嗜好情報取得部108は、頻度情報、または量情報、または頻度情報と量情報を用いて、i番目の種類識別情報で識別される種類の飲食物の好きな度合いを示す嗜好レベルを取得する。なお、頻度情報、または量情報が大きい値を示すほど、通常、嗜好レベルが高くなる。
(ステップS913)嗜好情報取得部108は、i番目の種類識別情報と、ステップS912で取得した嗜好レベルとを対応付けて蓄積する。なお、嗜好情報取得部108は、図示しない記録媒体に種類識別情報と嗜好レベルとを対応付けて蓄積する。
(ステップS914)嗜好情報取得部108は、カウンタiを1、インクリメントする。ステップS910に戻る。
次に、メニュー出力端末2の動作について説明する。メニュー出力端末2のメニュー受信部21は、メニュー出力装置1からメニューを受信する。そして、メニュー出力部22は、当該受信されたメニューをディスプレイ上に表示する。また、表示されているメニューを用いて、ユーザが注文を行うと、注文受付部23は注文情報を受け付ける。そして、
注文送信部24は、注文情報をメニュー出力装置1に送信する。なお、注文送信部24は、注文情報を、当該ユーザのユーザ識別情報と共に送信することは好適である。また、ユーザ識別情報は、例えば、メニュー出力端末2の図示しない記憶手段に記憶されている。
なお、メニュー出力端末2は公知技術により実現可能であるので、詳細な説明を省略する。
以下、本実施の形態におけるメニュー出力システムの具体的な動作について説明する。メニュー出力システムの概念図は図1である。
今、メニュー項目格納部105は、図10に示す多数のメニュー項目を格納している、とする。図10はメニュー項目管理表である。メニュー項目管理表は、「ID」「種類識別情報」「飲食物識別情報」「選択フラグ」「内容選択条件」「メニュー項目内容」の属性値を有するレコード(メニュー項目)を1以上格納している。属性「種類識別情報」は、飲食物の種類を示す情報である。種類とは、ジャンルやカテゴリーと言っても良い。「選択フラグ」は、メニュー項目が選択的メニュー項目であるか否かを示す。「選択フラグ」が「1」の場合は、メニュー項目は選択的メニュー項目である。また、「メニュー項目内容」として、「価格」「数量」を有する。また、メニュー項目は、飲食物の画像や動画等を有することは好適である。また、「ID」は、レコードを識別する情報である。また、また、図10における「ID=1」のレコードは選択的メニュー項目である。そして、「ID=1」のレコードの「内容選択条件」「メニュー項目内容」は、ユーザが使った総額が3000円以下である場合は、えだ豆の価格は300円のメニュー項目が選択されるが、総額が3000円を超えた後は、えだ豆の価格は250円のメニュー項目が選択されることを示す。また、「ID=28」のレコードの「内容選択条件」「メニュー項目内容」は、注文したから揚げが0の場合(初めて注文する場合)は、数量「80g」のメニュー項目が選択されるが、注文したから揚げが1以上の場合は、数量「160g」のメニュー項目が選択されることを示す。なお、選択的メニュー項目の選択候補のメニュー項目は、「ID=19」のレコードが示すように2より多くても良い。つまり、選択的メニュー項目により、注文状況に応じて、価格や数量等のメニューの内容が変更され得る。
また、注文履歴格納部102は、図11に示す注文履歴情報を格納している。図11は、注文履歴管理表である。注文履歴管理表は、多数の注文情報を有する。注文履歴管理表は、ここでは、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文情報、および過去注文履歴情報を有する。注文履歴管理表は、「ID」「ユーザ識別情報」「日時」「飲食物識別情報」「数量」「ユーザ属性情報」を有するレコード(注文情報)を多数格納している。「日時」は注文された日時であり、上述した時刻情報である。また、「数量」は注文された数量である。「ユーザ属性情報」は、ここでは一緒に来客した人数を示す。なお、図15において、一のユーザの注文情報だけが管理されているように見えるが、通常、多数のユーザの注文情報が管理されている。
また、飲食物属性情報格納部104は、図12に示す飲食物属性情報を格納している。図12は、飲食物属性情報管理表である。飲食物属性情報管理表は、「ID」「飲食物識別情報」「食材識別情報」「カロリー」「重量」「人数」を有するレコード(飲食物属性情報)を多数格納している。「食材識別情報」は飲食物を調理するのに必要な食材の情報であり、飲食物識別情報と同じ場合もある。「カロリー」は飲食物を摂取した時に取り込まれるカロリー数を示す。「重量」は飲食物の重量である。「人数」は摂取する際の適切な人数である。
また、在庫格納部107は、図13に示す在庫情報を格納している。図13は、在庫管理表である。在庫管理表は、「ID」「飲食物識別情報」「食材識別情報」「在庫数量」を有するレコード(在庫情報)を多数格納している。
さらに、ルール格納部109は、図14に示す飲食ルールを格納している。図14はルール管理表である。ルール管理表は、「ID」「ユーザ識別情報」「飲食ルール」を有するレコードを多数格納している。「飲食ルール」は「ルール種別」「ルール内容」を有する。「ルール種別」は、ルールの種類を示す。「ルール内容」はルールの内容を示す。
かかる状況において、ユーザ識別情報「0015」で識別されるユーザ(以下、本ユーザという。)が、ある飲食店に入った後、メニュー出力端末2を操作して、メニュー出力端末2は、メニュー出力装置1からメニューを受信し、図15に示すようなメニュー画面を出力した、とする。なお、動作の詳細は、例えば、以下である。つまり、メニュー出力装置1がメニュー出力指示をメニュー出力端末2から受信する。そして、メニュー取得部110が図10のメニュー項目管理表を読み込み、図15に示すメニューを構成する。次に、出力部111は当該メニューを送信する。そして、メニュー出力端末2のメニュー受信部21はメニューを受信し、メニュー出力部22は図15のメニューを出力する。
また、例えば、本店舗の店員または本ユーザが、ユーザ属性情報「一人」をユーザ識別情報「0015」と対にしてメニュー出力装置1に送信し、メニュー出力装置1のユーザ属性情報受付部106はユーザ属性情報「一人」とユーザ識別情報「0015」とを受信し、一時蓄積する。
次に、本ユーザは、図15の画面を用いて、「えだ豆」を注文した、とする。すると、メニュー出力端末2は、注文情報「<ユーザ識別情報>0015,<飲食物識別情報>えだ豆,<数量>1」を、メニュー出力装置1に送信する。
次に、メニュー出力装置1の注文情報受付部101は、注文情報「<ユーザ識別情報0015,<飲食物識別情報>えだ豆,<数量>1」を受信する。
次に、注文履歴蓄積部103は、受信した注文情報を、ユーザ識別情報「0015」と対応付けて、注文履歴格納部102に蓄積する。なお、ここで蓄積する注文情報は、「<飲食物識別情報>えだ豆,<数量>1」でも良い。また、注文履歴蓄積部103は、日時「2012/8/6 17:35」を図示しない時計から取得する。そして、注文履歴蓄積部103は、注文情報と日時とユーザ属性情報「一人」とを対応付けて蓄積する。
次に、メニュー取得部110は、以下のようにメニューを構成する。つまり、メニュー取得部110は、ユーザ識別情報「0015」を取得する。次に、メニュー取得部110は、ユーザ識別情報「0015」に対応する注文履歴情報を、注文履歴格納部102から読み出す。次に、メニュー取得部110は、ユーザ識別情報に対応するユーザ属性情報「0015」に対応するユーザ属性情報「一人」を取得する。また、メニュー取得部110は、図13の在庫情報を取得する。さらに、メニュー取得部110は、ユーザ識別情報「0015」に対応する嗜好情報「<飲食物識別情報>ビール<嗜好レベル>10,<飲食物識別情報>えだ豆<嗜好レベル>5,<飲食物識別情報>豆腐<嗜好レベル>2,・・・」を取得する。なお、この嗜好情報は、嗜好情報取得部108が、図9で説明した動作により、取得した情報である。
次に、メニュー取得部110は、ユーザ識別情報「0015」に対応する順序ルール「おつまみ→魚→肉→デザート」を、図14のルール管理表から取得する。そして、本順序ルールと、注文履歴格納部102に蓄積された注文情報「<飲食物識別情報>えだ豆,<数量>1」を用いて、「おつまみ」の注文の次は、「魚」であり、「おつまみ」の注文は完了した、と認識する。つまり、メニュー取得部110は、種類識別情報「おつまみ」のランクを「1」、種類識別情報「魚」のランクを「10」、種類識別情報「肉」のランクを「4」、種類識別情報「デザート」のランクを「2」とする。なお、ランクは「0」から「10」の整数であり、大きい値ほど選択されやすい位置の表示されるものとする。また、種類識別情報「ドリンク」のランクは「5」である、とする。
次に、メニュー取得部110は、ユーザ識別情報「0015」に対応する総量ルールと、特定総量ルールとを取得する。そいて、メニュー取得部110は、ユーザ識別情報「0015」に対応する総量ルール、特定総量ルールを満たすか否かを判断する。ここで、<飲食物識別情報>えだ豆のカロリー「50KCal」を図12の飲食物属性情報管理表から取得する。そして、メニュー取得部110は、総量ルールを満たさない、と判断する。また、メニュー取得部110は、本日の注文情報の中で、ビールの注文情報は存在しないので、特定総量ルール「ビール<=3杯」を満たさない、と判断する。
そして、次に、メニュー取得部110は、ユーザ属性情報「一人」を用いて、各メニュー項目のランクを変更する。例えば、メニュー取得部110は、「人数」に1を含まない飲食物情報(「人数=1」「人数=1〜2」は1を含むと判断される。)に対応するメニュー項目のランクを「−∞」に変更する。つまり、飲食物識別情報「おさしみセット」や「から揚げ」は「人数」に1を含まない飲食物情報であるので、これらのメニュー項目には「−∞」が付与される。なお、ここでは、デフォルトのメニュー項目のランクは「5」である、とする。また、「その他」のランクは「0」である、とする。
次に、メニュー取得部110は、在庫情報を用いて、提供不可な飲食物を決定し、当該飲食物に対応するメニュー項目を削除する。なお、この段階では、提供不可なメニュー項目は存在しない。
次に、メニュー取得部110は、ランクを用いて、メニュー項目の集合をソートする。つまり、メニュー取得部110は、ランクを用いて、種類識別情報「魚」、「ドリンク」、「肉」、「デザート」、「おつまみ」、「他」の順に、メニュー項目の集合を並び替える。
また、メニュー取得部110は、閾値以下のランクのメニュー項目を非選択(ここでは、例えば、削除)とする。ここでは、例えば、ランク「−∞」の「おさしみセット」や「から揚げ」が削除される。
次に、メニュー取得部110は、メニューの内容の変更を行うか否かを判断する。ここでは、メニューの内容の変更を行わない、と判断した、とする。
次に、メニュー取得部110は、選択的メニュー項目処理を行う。つまり、メニュー取得部110は、例えば、図10の「ID=19」のメニュー項目が選択的メニュー項目である、と判断する。そして、メニュー取得部110は、内容選択条件に関連する情報である価格を注文履歴情報から取得する。具体的には、メニュー取得部110は、本ユーザの本日の注文情報から価格「300円」のみを取得する。メニュー取得部110は、この価格「300円」から総額「300円」を得る。そして、メニュー取得部110は、総額「300円」は、選択的メニュー項目が有する「総額<=1500円」を満たす、と判断する。そして、メニュー取得部110は、メニュー項目内容「<価格>700円,<数量>60g,・・・」を取得する。
そして、メニュー取得部110は、図16のメニューを得る。図16において、選択されやすい位置に、種類識別情報「魚」の画面が配置されている。また、一人向けでは無い「おさしみセット」は削除されている。
次に、出力部111は、図16のメニューをメニュー出力端末2に送信する。
次に、メニュー出力端末2のメニュー受信部21は図16のメニューを受信し、メニュー出力部22は当該メニューを出力する。
次に、本ユーザは、ビールを次々に3杯注文した、とする。すると、特定総量ルール「ビール「3杯まで」」の制限ぎりぎりになったことを、メニュー取得部110は検知する。
次に、メニュー取得部110は、飲食物識別情報<ビール>に対応するメニュー項目が削除されたメニューを構成する。そして、出力部111は、当該メニューをメニュー出力端末2に送信する。
次に、メニュー出力端末2は、当該メニューを受信し、出力する。
なお、本ユーザが、例えば、フォアグラを注文した後、すべてのユーザに適用されるルール「フォアグラ「1個まで」」が、本ユーザにも適用され、フォアグラのメニュー項目は削除される。かかる処理は、上述した処理と同様である。
以上、本実施の形態によれば、飲食物の注文の際に、注文を行うためのメニューの使用性を向上できる。
また、本実施の形態によれば、飲食物の注文状況、飲食ルール、お客様の属性、在庫状況、お客様の嗜好等に応じて、適切にメニュー画面を変更できる。
また、本実施の形態によれば、注文をするごとにメニューの変更を行えることにより、常に、ユーザの状況に応じたメニューをユーザに提供できる。
なお、本実施の形態における処理は、ソフトウェアで実現しても良い。そして、このソフトウェアをソフトウェアダウンロード等により配布しても良い。また、このソフトウェアをCD−ROMなどの記録媒体に記録して流布しても良い。なお、このことは、本明細書における他の実施の形態においても該当する。なお、本実施の形態における情報処理装置を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、ユーザが現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す情報であって、現在の来店中に前記注文情報受付部が受け付けた前記注文情報の集合である注文履歴情報が格納される注文履歴格納部と、前記飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、前記飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である1以上のメニュー項目が格納されるメニュー項目格納部とにアクセス可能なコンピュータを、ユーザが飲食店に対して注文した飲食物を示す情報であって、当該飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付部と、前記注文情報受付部が受け付けた注文情報を前記注文履歴格納部に蓄積する注文履歴蓄積部と、前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報と、前記飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、前記メニュー取得部が取得したメニューを出力する出力部として機能させるためのプログラムである。
また、上記プログラムにおいて、前記コンピュータは、飲食物属性情報を有するルールであり、飲食に関するルールである1以上の飲食ルールを格納し得るルール格納部にさらにアクセス可能であり、前記メニュー取得部は、前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報を前記1以上の飲食ルールに適用し、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、コンピュータを、ユーザの属性を示す情報であるユーザ属性情報を受け付けるユーザ属性情報受付部としてさらに機能させ、前記メニュー取得部は、さらに、前記ユーザ属性情報受付部が受け付けたユーザ属性情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、飲食物に関する在庫状況を示す情報である在庫情報が、当該飲食物の飲食物識別情報と対応付けて格納されている在庫格納部にさらにアクセス可能なコンピュータを機能させるためのプログラムであって、前記メニュー取得部は、さらに、在庫情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記注文履歴格納部には、さらに、現在来店中の前記飲食店においてユーザが過去の来店時に注文した飲食物の履歴を示す情報であって、過去の来店時に前記注文情報受付部が受け付けた前記注文情報の集合である過去注文履歴情報が格納されており、前記過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する嗜好情報取得部として、コンピュータをさらに機能させるためのプログラムであって、前記メニュー取得部は、さらに、前記嗜好情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の一部の値を変更したメニューを取得するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記メニュー取得部は、前記注文情報受付部が注文情報を受け付ける毎に、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得し、前記出力部は、前記メニュー取得部が取得したメニューを出力するものとして、コンピュータを機能させるためのプログラムである。
また、上記プログラムにおいて、前記1以上のメニュー項目のうちの、少なくとも一部のメニュー項目は、出力されるメニュー項目の内容を示すメニュー項目内容と、当該メニュー項目内容が選択される条件を示す選択条件とを有する2以上のメニュー項目部品を有する選択的メニュー項目であり、前記メニュー取得部は、前記注文履歴情報と前記飲食物属性情報とを前記選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成するものとして、コンピュータを機能させるためのプログラムである。
また、図17は、本明細書で述べたプログラムを実行して、上述した種々の実施の形態のメニュー出力装置を実現するコンピュータの外観を示す。上述の実施の形態は、コンピュータハードウェア及びその上で実行されるコンピュータプログラムで実現され得る。図17は、このコンピュータシステム300の概観図であり、図18は、システム300のブロック図である。
図17において、コンピュータシステム300は、CD−ROMドライブを含むコンピュータ301と、キーボード302と、マウス303と、モニタ304とを含む。
図18において、コンピュータ301は、CD−ROMドライブ3012に加えて、MPU3013と、MPU3013、CD−ROMドライブ3012に接続されたバス3014と、ブートアッププログラム等のプログラムを記憶するためのROM3015と、MPU3013に接続され、アプリケーションプログラムの命令を一時的に記憶するとともに一時記憶空間を提供するためのRAM3016と、アプリケーションプログラム、システムプログラム、及びデータを記憶するためのハードディスク3017とを含む。ここでは、図示しないが、コンピュータ301は、さらに、LANへの接続を提供するネットワークカードを含んでも良い。
コンピュータシステム300に、上述した実施の形態のメニュー出力装置の機能を実行させるプログラムは、CD−ROM3101に記憶されて、CD−ROMドライブ3012に挿入され、さらにハードディスク3017に転送されても良い。これに代えて、プログラムは、図示しないネットワークを介してコンピュータ301に送信され、ハードディスク3017に記憶されても良い。プログラムは実行の際にRAM3016にロードされる。プログラムは、CD−ROM3101またはネットワークから直接、ロードされても良い。
プログラムは、コンピュータ301に、上述した実施の形態のメニュー出力装置の機能を実行させるオペレーティングシステム(OS)、またはサードパーティープログラム等は、必ずしも含まなくても良い。プログラムは、制御された態様で適切な機能(モジュール)を呼び出し、所望の結果が得られるようにする命令の部分のみを含んでいれば良い。コンピュータシステム300がどのように動作するかは周知であり、詳細な説明は省略する。
なお、上記プログラムにおいて、情報を送信する送信ステップや、情報を受信する受信ステップなどでは、ハードウェアによって行われる処理、例えば、送信ステップにおけるモデムやインターフェースカードなどで行われる処理(ハードウェアでしか行われない処理)は含まれない。
また、上記プログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、あるいは分散処理を行ってもよい。
また、上記各実施の形態において、一の装置に存在する2以上の通信手段は、物理的に一の媒体で実現されても良いことは言うまでもない。
また、上記各実施の形態において、各処理(各機能)は、単一の装置(システム)によって集中処理されることによって実現されてもよく、あるいは、複数の装置によって分散処理されることによって実現されてもよい。
本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。