JP2014048875A - メニュー出力装置、メニュー出力方法、およびプログラム - Google Patents

Abstract

【課題】従来、飲食物注文のためのメニューの使用性が低かった
【解決手段】注文情報を受け付ける注文情報受付部と、ユーザが現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文情報の集合である注文履歴情報が格納される注文履歴格納部と、飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部と、メニュー項目を配置したメニューであって、格納された注文履歴情報と、格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、メニューを出力する出力部とを備えたメニュー出力装置により、飲食物の注文の際に、注文を行うためのメニューの使用性を向上できる。
【選択図】図１

Description

本発明は、飲食物の注文の際に使用するメニュー画面を出力するメニュー出力装置等に関するものである。

従来の注文メニューを出力する装置等として、一覧表とメニュー品目欄とを含むメニュー割付画面を液晶ディスプレイに表示するものが知られていた（例えば、特許文献１参照）。
（例えば、特許文献１参照）。

特開２０１０−２４４４１８号公報（第１頁、第１図等）

しかしながら、従来の技術においては、飲食物の注文の際に、注文を行うためのメニューの使用性が低い、という課題があった。さらに具体的には、例えば、従来の技術においては、現在の来店中に注文した飲食物の履歴等に応じて、メニュー項目の内容が変わらない。そのため、ユーザの現在の状況に応じた、使用性の高いメニュー画面を提供できなかった。

本第一の発明のメニュー出力装置は、ユーザが注文した飲食物を示す情報であって、飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付部と、ユーザが注文した飲食物の履歴を示す情報であって、注文情報受付部が受け付けた注文情報の集合である注文履歴情報が格納される注文履歴格納部と、注文情報受付部が受け付けた注文情報を注文履歴格納部に蓄積する注文履歴蓄積部と、飲食物識別情報と対応付けられた情報であって、飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部と、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報と、飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、メニュー取得部が取得したメニューを出力する出力部とを備えたメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて動的に、かつ適切にメニュー画面を変更できる。

また、本第二の発明のメニュー出力装置は、第一の発明に対して、飲食物属性情報を有するルールであり、飲食に関するルールである１以上の飲食ルールを格納し得るルール格納部をさらに具備し、メニュー取得部は、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報を１以上の飲食ルールに適用し、注文履歴情報と飲食物属性情報とに応じた態様のメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて、かつルールに従って、適切にメニュー画面を変更できる。

また、本第三の発明のメニュー出力装置は、第一または第二の発明に対して、ユーザの属性を示す情報であるユーザ属性情報を受け付けるユーザ属性情報受付部をさらに備え、メニュー取得部は、さらに、ユーザ属性情報受付部が受け付けたユーザ属性情報に応じた態様のメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況とお客様の属性とに応じて、適切にメニュー画面を変更できる。

また、本第四の発明のメニュー出力装置は、第一から第三いずれかの発明に対して、飲食物に関する在庫状況を示す情報である在庫情報が、飲食物の飲食物識別情報と対応付けて格納されている在庫格納部をさらに備え、メニュー取得部は、さらに、在庫情報に応じた態様のメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況と在庫状況とに応じて、適切にメニュー画面を変更できる。

また、本第五の発明のメニュー出力装置は、第一から第四いずれかの発明に対して、注文履歴格納部には、さらに、ユーザが過去に注文した飲食物の履歴を示す情報であって、過去に注文情報受付部が受け付けた注文情報の集合である過去注文履歴情報が格納されており、過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する嗜好情報取得部をさらに備え、メニュー取得部は、さらに、嗜好情報に応じた態様のメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況とお客様の嗜好とに応じて、適切にメニュー画面を変更できる。

また、本第六の発明のメニュー出力装置は、第一から第五いずれかの発明に対して、メニュー取得部は、メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて、適切にメニュー項目の順序を変更したメニュー画面を提示できる。

また、本第七の発明のメニュー出力装置は、第一から第五いずれかの発明に対して、メニュー取得部は、メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて、適切にメニュー項目を選択不可にしたメニュー画面を提示できる。

また、本第八の発明のメニュー出力装置は、第一から第五いずれかの発明に対して、メニュー取得部は、メニュー項目の一部の値を変更したメニューを取得するメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて、適切にメニュー項目の内容を変更したメニュー画面を提示できる。

また、本第九の発明のメニュー出力装置は、第一から第八いずれかの発明に対して、メニュー取得部は、注文情報受付部が注文情報を受け付ける毎に、注文履歴情報と飲食物属性情報とに応じた態様のメニューを取得し、出力部は、メニュー取得部が取得したメニューを出力するメニュー出力装置

かかる構成により、飲食物を注文する度に、注文状況に応じた適切なメニューが出力される。

また、本第十の発明のメニュー出力装置は、第一から第九いずれかの発明に対して、１以上のメニュー項目のうちの、少なくとも一部のメニュー項目は、出力されるメニュー項目の内容を示すメニュー項目内容と、当該メニュー項目内容が選択される条件を示す選択条件とを有する２以上のメニュー項目部品を有し、メニュー取得部は、注文履歴情報と前記飲食物属性情報とを選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成する請求項１から請求項７いずれか一項に記載のメニュー出力装置である。

かかる構成により、飲食物の注文状況に応じて、適切にメニューを変更しやすいメニューのデータ構造を提供できる。

本発明によるメニュー出力装置によれば、飲食物の注文のためのメニューの使用性を向上できる。

実施の形態１におけるメニュー出力システムの概念図を示す図 同メニュー出力システムのブロック図 同メニュー出力装置１の動作について説明するフローチャート 同メニュー構成処理について動作について説明するフローチャート 同ルールを適用したメニュー構成処理について、図５のフローチャートの動作について説明するフローチャート 同ルールを適用しないメニュー構成処理について、図６のフローチャートの動作について説明するフローチャート 同ランクを用いたメニュー構成処理について、図７のフローチャートの動作について説明するフローチャート 同選択的メニュー項目処理について、図８のフローチャートの動作について説明するフローチャート 同嗜好情報取得処理について、図９のフローチャートの動作について説明するフローチャート 同メニュー項目管理表を示す図 同注文履歴管理表を示す図 同飲食物属性情報管理表を示す図 同在庫管理表を示す図 同ルール管理表を示す図 同メニュー画面の例を示す図 同メニュー画面の例を示す図 同コンピュータシステムの概観図 同コンピュータシステムのブロック図

以下、メニュー出力装置等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動作を行うので、再度の説明を省略する場合がある。

（実施の形態１）
本実施の形態において、注文した飲食物の履歴情報を蓄積し、当該注文履歴と飲食物に関する情報と飲食物の属性を示す飲食物属性とを用いて注文のためのメニューを動的に変更するメニュー出力システムについて説明する。

また、本実施の形態において、飲食に関するルールである１以上の飲食ルールを用いて、動的にメニューを変更するメニュー出力システムについて説明する。

また、本実施の形態において、来店人数、ご一緒されているお客様の関係（例えば、家族、恋人、同姓友人等）、お客様のアレルギー情報等のお客様の属性に応じて注文メニューを動的に変更するメニュー出力システムについて説明する。

また、本実施の形態において、食材または飲食物の在庫情報を用いて、メニューを動的に変更するメニュー出力システムについて説明する。

また、本実施の形態において、注文履歴から個人の嗜好を分析し、嗜好の情報を用いてメニューを動的に変更するメニュー出力システムについて説明する。

また、本実施の形態において、メニューの変更の態様として、メニュー項目の順序を変更したり、メニュー項目を削除またはグレーアウトしたり、メニュー項目の一部の表示の変更（金額、量などの変更）を行ったりする場合について説明する。

なお、飲食物とは、例えば、飲食物や、飲料等である。複数の飲食物や飲料等の組合せ構成されるもの（例えば、飲食物のセットやコース等）も、ここでは一の飲食物と考えても良い。

また、飲食店とは、例えば、レストランや、喫茶店、居酒屋等の、飲食物を提供する店舗等である。

図１は、本実施の形態におけるメニュー出力システムの概念図である。メニュー出力システムは、メニュー出力装置１、および１以上のメニュー出力端末２を備える。メニュー出力装置１は、例えば、いわゆるサーバ装置である。また、メニュー出力端末２は、例えば、お客様が保有する端末装置である。メニュー出力端末２は、例えば、いわゆるスマートフォン等の携帯端末、携帯用のパソコン、店舗の席に設置されている注文用の端末等、情報の入出力が行える端末であれば何でも良い。さらに、メニュー出力装置１、および１以上のメニュー出力端末２は、通常、無線、または有線のネットワークで相互に通信可能である。

図２は、本実施の形態におけるメニュー出力システムのブロック図である。メニュー出力装置１は、注文情報受付部１０１、注文履歴格納部１０２、注文履歴蓄積部１０３、飲食物属性情報格納部１０４、メニュー項目格納部１０５、ユーザ属性情報受付部１０６、在庫格納部１０７、嗜好情報取得部１０８、ルール格納部１０９、メニュー取得部１１０、出力部１１１を備える。

メニュー出力端末２は、メニュー受信部２１、メニュー出力部２２、注文受付部２３、注文送信部２４を備える。

注文情報受付部１０１は、注文情報を受け付ける。注文情報とは、ユーザが飲食店に対して注文した飲食物を示す情報である。注文情報は、飲食物の識別情報である飲食物識別情報を有する。飲食物識別情報は、飲食物名や、飲食物に割り当てられた数字や文字列で構成されるコード等である。一の注文情報は、一の飲食物識別情報を有しているものであることが好ましいが、複数の飲食物識別情報を有していても良い。ここでのユーザは、個人であっても複数の人で構成されるグループであっても良い。注文情報は、注文した飲食物の数量を示す情報を更に有していても良い。また、注文情報は、ユーザを識別するユーザ識別情報や注文した日時を示す時刻情報を有しても良い。ユーザ識別情報は、例えば、ユーザ名や、ユーザに割り当てられたコード、ユーザの電話番号、ユーザのクレジットカード番号、ユーザの会員番号等である。また、注文情報は、注文を受け付ける店舗の識別情報である店舗識別情報を有していても良い。店舗識別情報は、例えば、店舗名や、店舗に割り当てられたコード、店舗の電話番号等である。また、店舗を経営する法人や個人等の識別情報等であっても良い。また、注文情報は、ユーザが飲食物を注文した順番を示す情報を有していても良い。順番を示す情報は、注文を受け付けた順番が判断可能な情報であれば良く、例えば、注文順番を示す連番等の数値や、注文を受け付けた時刻を含む情報である。また、ここでの時刻を含む情報は、日付の情報だけでも良く、日付の情報を含んでいても良い。順番を示す情報に関しては、以下においても同様である。なお、注文情報がユーザ識別情報を有しない場合、注文情報受付部１０１は、ユーザ識別情報と注文情報とを受け付けることは好適である。
なお、注文情報受付部１０１は、店外に設置されているメニュー出力端末２からの注文を受け付けても良い。かかる場合のメニュー出力端末２は、例えば、ユーザが保有している、いわゆるスマートフォンやパソコン等である。

ここで、受け付けとは、タッチパネル、キーボード、マウスなどの入力デバイスから入力された情報の受け付け、有線もしくは無線の通信回線を介して送信された情報の受信、光ディスクや磁気ディスク、半導体メモリなどの記録媒体から読み出された情報の受け付けなどを含む概念である。

また、注文情報の入力手段は、タッチパネルやマウスやメニュー画面によるもの等、何でも良い。注文情報受付部１０１は、タッチパネル等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。

注文履歴格納部１０２は、注文履歴情報が格納される。注文履歴情報とは、ユーザが現在来店中の飲食店において、現在の来店中に注文した飲食物の履歴を示す情報であることは好適である。また、注文履歴情報は、現在の来店中に注文情報受付部１０１が受け付けた注文情報の集合であることは好適である。また、注文履歴情報を構成する各注文情報は、注文情報受付部１０１が注文情報を受け付けた順番を示す情報と対応付けられて格納されていても良い。また、注文履歴情報は、通常、ユーザ識別情報と対応付けて格納されている。なお、注文履歴情報は、店外に設置されているメニュー出力端末２から送信された情報でも良い。また、注文履歴情報は、後述する過去注文履歴情報を含むと考えても良い。

注文履歴格納部１０２には、過去注文履歴情報が格納されても良い。過去注文履歴情報は、過去に注文された飲食物の履歴を示す情報である。また、過去注文履歴情報は、ユーザが現在来店中の飲食店において、過去の来店時に注文した飲食物の履歴を示す情報である。過去注文履歴情報は、ユーザの過去の来店時に、注文情報受付部１０１が受け付けた注文情報の集合であることは好適である。過去注文履歴情報は、この過去注文履歴情報が有する飲食物識別情報が示す飲食物の注文を受け付けたタイミングが異なる点を除けば、上述した注文履歴情報と同様の情報であってもよい。注文履歴格納部１０２において、注文履歴情報と過去注文履歴情報とはどのように区別されるかは問わない。例えば、注文履歴格納部１０２に格納されているユーザが注文した飲食物の履歴を示す情報のうちの、現在の来店時よりも前の日時と対応付けられた履歴を示す情報を過去注文履歴情報とし、現在の来店時以降の日時と対応付けられた履歴を示す情報を注文履歴情報としても良い。また、注文履歴情報と過去注文履歴情報とは、異なるフォルダ等に格納されていてもよい。この場合、例えば、ユーザによる来店が終了した時点（例えば、ユーザが注文した飲食物の精算を完了した時点）以降に、注文履歴蓄積部１０３や図示しない処理部等が、注文履歴格納部１０２に格納された注文履歴情報を、過去注文履歴情報が格納されているフォルダに移動させるようにしても良い。また、注文履歴情報と過去注文履歴情報とに、異なる識別情報（例えば、注文履歴情報であるか過去注文履歴情報であるかを示すフラグ等の情報）を対応付けて注文履歴格納部に蓄積するようにしても良い。

なお、注文履歴格納部１０２は、例えば、物理的には分離されている複数の記憶媒体等から構成されていても良く、注文履歴情報と、過去注文履歴情報とが、複数の記憶媒体のうちの異なる記憶媒体にそれぞれ格納されていても良い。

注文履歴格納部１０２は、不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。なお、かかることは以下の格納部についても同様である。また、注文履歴格納部１０２に、情報が記憶される過程は問わない。かかることも、他の格納部も同様である。

注文履歴蓄積部１０３は、注文情報受付部１０１が受け付けた注文情報を前記注文履歴格納部１０２に蓄積する。注文履歴蓄積部１０３は、例えば、注文情報受付部１０１が受け付けた注文情報を、上述したような受け付けた順番を示す情報と対応付けて注文履歴格納部１０２に蓄積してもよい。順番を示す情報が時刻である場合、メニュー出力装置１が有する図示しない時計等から現在の時刻を取得するようにすればよい。また、注文履歴蓄積部１０３は、注文情報の入力を行ったユーザのユーザ識別情報や、注文を受け付けた飲食店の飲食店識別情報と対応付けて注文情報を蓄積するようにしても良い。ユーザ識別情報は、例えば、注文を行うユーザがメニュー出力装置１にログイン等を行う際に入力したユーザ識別情報を用いる。また、飲食店識別情報は、例えば、予め図示しない記憶媒体等に蓄積されている飲食店識別情報を読み出す。ユーザが現在の来店中に受け付けた注文情報は、例えば、注文履歴情報として注文履歴格納部１０２に蓄積（例えば、追記）される。また、例えば、ユーザが来店を終えた後には、蓄積された注文履歴情報が過去注文履歴情報となる。

注文履歴蓄積部１０３は、通常、ＭＰＵやメモリ等から実現され得る。注文履歴蓄積部１０３の処理手順は、通常、ソフトウェアで実現され、当該ソフトウェアはＲＯＭ等の記録媒体に記録されている。但し、ハードウェア（専用回路）で実現しても良い。

飲食物属性情報格納部１０４は、１以上の飲食物属性情報が格納される。飲食物属性情報とは、飲食物識別情報と対応付けられた情報であって、飲食物識別情報が示す飲食物の属性を示す情報である。飲食物属性情報は、例えば、飲食物の種類（オードブル、メイン、デザート等）、飲食物の材料の種類（野菜、肉類、スープ等）、カロリーの値、調理方法、分野、重量等である。

メニュー項目格納部１０５は、１以上のメニュー項目が格納される。メニュー項目は、飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である。メニュー項目は、例えば、「＜飲食物識別情報＞唐揚げ，＜価格＞３００円，＜飲食物属性情報＞＜カロリー＞５００ＫＣａｌ，＜ジャンル＞揚げ物，＜材料＞鶏肉，・・・＜／飲食物属性情報＞」である。

また、メニュー項目は、注文履歴情報、嗜好情報、ユーザ属性情報のうちの１以上の情報に基づいて、その内容が変更されても良い。かかる場合、メニュー項目は、例えば、内容を変更するための条件である内容変更条件、変更する内容に関する情報である変更内容情報を有する。メニュー項目は、例えば、「＜飲食物識別情報＞唐揚げ，＜価格＞３００円，＜内容変更条件＞注文履歴情報に２以上の「＜飲食物識別情報＞唐揚げ」が存在，＜変更内容情報＞価格＝１００＋（２００−５０×Ｎ），＜飲食物属性情報＞＜カロリー＞５００ＫＣａｌ，＜ジャンル＞揚げ物，＜材料＞鶏肉，・・・＜／飲食物属性情報＞」である。かかるメニュー項目のうちの「＜内容変更条件＞注文履歴情報に２以上の「＜飲食物識別情報＞唐揚げ」が存在」は、唐揚げを２以上注文していることを示す。また、「＜変更内容情報＞価格＝１００＋（２００−５０×Ｎ）」は、「価格＝１００＋（２００−５０×Ｎ）」（Ｎは注文回数）により、価格が算出されることを示す。なお、＜変更内容情報＞は数式であるが、値など、他の表現形式でも良いことは言うまでもない。

また、メニュー項目は、メニュー項目内容と内容選択条件とを有する２以上のメニュー項目部品であっても良い。メニュー項目内容とは、出力されるメニュー項目の内容を示す情報である。また、選択条件は、メニュー項目内容が選択される条件を示す情報である。メニュー項目を構成する２つのメニュー項目部品は、例えば、「＜メニュー項目内容＞＜飲食物識別情報＞唐揚げ，＜価格＞３００円＜／メニュー項目内容＞，＜選択条件＞総額２０００円未満」「＜メニュー項目内容＞＜飲食物識別情報＞唐揚げ，＜価格＞２５０円＜／メニュー項目内容＞，＜選択条件＞総額２０００円以上」である。かかるメニュー項目は、総額２０００円未満の間は、唐揚げの価格が３００円のメニュー項目が選択され、総額２０００円以上の場合は唐揚げの価格が２５０円のメニュー項目が選択されることを示す。なお、２以上のメニュー項目部品を有するメニュー項目を、適宜、選択的メニュー項目という。また、総額とは、ユーザが注文した飲食物の価格の合計である。

ユーザ属性情報受付部１０６は、ユーザの属性を示す情報であるユーザ属性情報を受け付ける。ユーザ属性情報とは、例えば、来店人数、一緒に来店された複数のユーザ（お客様）の関係（例えば、家族、恋人、同姓友人など）、ユーザのアレルギーに関する情報であるアレルギー情報（そばアレルギー等）などである。また、ユーザ属性情報受付部１０６は、通常、受け付けたユーザ属性情報を、ユーザ識別情報と対応付けて、図示しない記録媒体に一時蓄積する。なお、ユーザ属性情報受付部１０６は、メニュー出力端末２から、ユーザ属性情報を受信しても良い。また、ユーザ属性情報は、ユーザ識別情報を含んでも良いし、ユーザ識別情報と対応付いていても良い。ユーザ属性情報がユーザ識別情報と対応付いている場合、ユーザ属性情報受付部１０６は、ユーザ識別情報とユーザ属性情報とを受け付ける。

また、ユーザ属性情報を受け付ける手段は何でも良い。ユーザ属性情報受付部１０６は、例えば、無線または有線の通信手段により、ユーザ属性情報を受け付ける。

在庫格納部１０７は、飲食物に関する在庫状況を示す情報である在庫情報が、飲食物の飲食物識別情報と対応付けて格納されている。なお、在庫格納部１０７の在庫情報は、飲食物の消費に従って、図示しない手段により更新される。在庫情報の更新は、通常、人手により行われるが、在庫情報の自動チェック機能（図示しない手段による）を有し、自動的に行われても良い。

嗜好情報取得部１０８は、過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する。嗜好情報とは、例えば、飲食物属性情報、飲食物属性情報を選択するパターンを示す情報である。嗜好情報取得部１０８は、例えば、ある店舗に訪問の度に注文されている飲食物のジャンル（「種類」と言っても良い。）、またはある店舗に訪問の度に注文されている飲食物の飲食物識別情報を取得する。かかる場合、嗜好情報はジャンル、または飲食物識別情報である。そして、嗜好情報取得部１０８は、嗜好情報とユーザ識別情報を対応付けて保持することは好適である。

ルール格納部１０９は、１以上の飲食ルールを格納し得る。飲食ルールとは、飲食物属性情報を有するルールであり、飲食に関するルールである。飲食ルールは、食べる順序に関するルール（順序ルールという）、食べた飲食物の総量に関するルール（総量ルールという）、特定の飲食物属性情報に対応する飲食物の総量に関するルール（特定総量ルールという）などである。順序ルールは、例えば、「＜順序＞＜ジャンル＞オードブル，＜ジャンル＞魚類，＜ジャンル＞肉類，＜ジャンル＞デザート，＜ジャンル＞ドリンク＜／順序＞」など、飲食の順序を示すルールである。本ルールは、「オードブル、魚類、肉類、デザート、ドリンク」の順に、飲食することを示す。また、総量ルールは、例えば、「＜カロリー＞１０００ＫＣａｌ以下」、「＜重量＞１ｋｇ以下」などである。「＜カロリー＞１０００ＫＣａｌ以下」は、一回の来店において、飲食する総カロリーが１０００ＫＣａｌ以下であることを示す。また、「＜重量＞１ｋｇ以下」は、来店以降に飲食した飲食物の総重量が１ｋｇ以下であることを示す。また、特定総量ルールは、例えば、「＜総量 ジャンル＝ビール＞３杯以下」などである。「＜総量 ジャンル＝ビール＞３杯以下」は、ビールは３杯以下に押さえること（４杯以上のビールは飲まないこと）を示す。なお、飲食ルールの記載方法やデータ構造は問わない。

また、１以上の飲食ルールは、ユーザ毎に管理されていることは好適である。つまり、飲食ルールとユーザ識別情報とは、対応付けて格納されていることは好適である。かかる場合、ユーザ毎に適用される飲食ルールが異なることになる。

また、ルール格納部１０９は、ユーザ識別情報と対応付けられている飲食ルールと、ユーザ識別情報と対応付けられていない飲食ルールの両方を含んでも良い。ユーザ毎に適用される飲食ルールが異なる場合、ダイエットを実施中のユーザは、総カロリーが５００ＫＣａｌ以下になることをルールとして保持しており、他のユーザは総カロリーについての制約が存在しない、等の処理が可能となる。また、ユーザによって、飲食する順序を変えた順序ルールが存在する場合、ユーザの嗜好に応じた飲食物の提供が可能となる。また、ユーザ識別情報と対応付けられていない飲食ルールは、飲食店の都合（例えば、希少価値の高い飲食物は、一人1個まで等）を、すべてのユーザに課すために有効である。

メニュー取得部１１０は、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報と、飲食物属性情報格納部１０４に格納された飲食物属性情報とに応じた態様のメニューを取得する。つまり、メニュー取得部１１０は、通常、注文がなされる毎に、異なるメニューを取得する。なお、本明細書において、メニューとは、注文する画面を構成するための情報と指す場合、注文するメニュー画面を指す場合等がある。

また、さらに具体的には、メニュー取得部１１０は、メニュー項目を配置したメニューであって、注文履歴格納部に格納された注文履歴情報を１以上の飲食ルールに適用し、注文履歴情報と飲食物属性情報とに応じた態様のメニューを取得する。例えば、飲食ルールが、順序ルール「＜順序＞＜ジャンル＞オードブル，＜ジャンル＞魚類，＜ジャンル＞肉類，＜ジャンル＞デザート，＜ジャンル＞ドリンク＜／順序＞」である場合、メニュー取得部１１０は、第一にオードブルのメニューを構成し、第二に魚類のメニューを構成し、第三に肉類のメニューを構成し、第四にデザートのメニューを構成し、最後にドリンクのメニューを構成する。また、例えば、飲食ルールが、特定総量ルール「＜総量 ジャンル＝ビール＞３杯以下」である場合、３杯のビールが注文された後は、メニュー取得部１１０は、ビールのメニュー項目を用いずに、ビールのメニュー項目が存在しないメニューを構成する。

メニュー取得部１１０は、さらに、ユーザ属性情報受付部１０６が受け付けたユーザ属性情報に応じた態様のメニューを取得する。ユーザ属性情報が「そばアレルギー」である場合、メニュー取得部１１０は、食材識別情報として「そば」を有するメニュー項目、および飲食物識別情報「そば」のメニュー項目を取得せず、かかるメニュー項目が存在しないメニューを構成する。

また、メニュー取得部１１０は、在庫格納部１０７の在庫情報に応じた態様のメニューを取得する。

メニュー取得部１１０は、嗜好情報取得部１０８が取得した嗜好情報に応じた態様のメニューを取得する。嗜好情報が「ビールが大好き」であることを示す情報である場合、例えば、メニュー取得部１１０は、「ビール」のメニュー項目を選択しやすい位置に配置したり、「ビール」の表示を目立つ表示にしたり、中ジョッキの代わりに大ジョッキのビールのメニュー項目にしたりする。

メニュー取得部１１０は、メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得しても良い。デフォルトの配置に関する情報は、メニュー項目格納部１０５が保持していても良いし、メニュー取得部１１０が保持していても良い。

メニュー取得部１１０は、メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得しても良い。

メニュー取得部１１０は、メニュー項目の一部の値を変更したメニューを取得しても良い。

メニュー項目が選択的メニュー項目である場合、メニュー取得部１１０は、注文履歴情報と飲食物属性情報とを選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成する。

なお、メニュー取得部１１０が取得したメニュー項目から出力するメニューを構成する技術は公知技術であるので、詳細な説明を省略する。メニュー取得部１１０は、例えば、メニュー項目を配置するためのテンプレートの情報を保持しており、かかるテンプレートの情報に、メニュー項目を代入して、メニューを構成する。

出力部１１１は、メニュー取得部１１０が取得したメニューを出力する。取得したメニューとは、構成したメニューと同意義である。ここで、出力とは、通常、メニュー出力端末２への送信であるが、ディスプレイへの表示、プロジェクターを用いた投影、プリンタでの印字、音出力、記録媒体への蓄積、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。

出力部１１１は、通常、無線または有線の通信手段により実現され得る。

メニュー出力端末２を構成するメニュー受信部２１は、メニュー出力装置１からメニューを受信する。メニュー受信部２１は、通常、無線または有線の通信手段で実現されるが、放送を受信する手段で実現されても良い。

メニュー出力部２２は、メニュー受信部２１が受信したメニューを出力する。ここで、出力とは、通常、ディスプレイへの表示であるが、プロジェクターを用いた投影、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。
メニュー出力部２２は、ディスプレイ等の出力デバイスを含むと考えても含まないと考えても良い。メニュー出力部２２は、出力デバイスのドライバーソフトまたは、出力デバイスのドライバーソフトと出力デバイス等で実現され得る。

注文受付部２３は、ユーザからの注文情報を受付ける。注文情報の受け付けは、通常、メニュー項目の指示により実現される。注文情報（メニュー項目の指示）の入力手段は、タッチパネルへのタッチ、マウス、またはメニュー画面によるもの等、何でも良い。注文受付部２３は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。

注文送信部２４は、注文受付部２３が受け付けた注文情報をメニュー出力装置１に送信する。注文送信部２４は、通常、無線または有線の通信手段で実現されるが、放送手段で実現されても良い。

次に、メニュー出力システムの動作について説明する。まず、メニュー出力装置１の動作について、図３のフローチャートを用いて説明する。

（ステップＳ３０１）注文情報受付部１０１は、メニュー出力端末２から注文情報を受け付けたか否かを判断する。なお、ここでの受け付けは、受信である。注文情報を受信すればステップＳ３０２に行き、注文情報を受信しなければステップＳ３０５に行く。なお、注文情報受付部１０１は、通常、ユーザ識別情報も共に受信する。

（ステップＳ３０２）注文履歴蓄積部１０３は、ステップＳ３０１で受信した注文情報を、ユーザ識別情報と対応付けて、注文履歴格納部１０２に蓄積する。

（ステップＳ３０３）メニュー取得部１１０は、ユーザ識別情報により識別されるユーザ向けのメニューを構成する。かかる処理をメニュー構成処理という。メニュー構成処理について、図４のフローチャートを用いて説明する。

（ステップＳ３０４）出力部１１１は、ステップＳ３０３で構成されたメニューを、メニュー出力端末２に送信する。なお、このメニュー出力端末２は、注文情報を送信してきたメニュー出力端末２である。

（ステップＳ３０５）ユーザ属性情報受付部１０６は、ユーザ属性情報を受信したか否かを判断する。ユーザ属性情報を受信すればステップＳ３０６に行き、ユーザ属性情報を受信しなければステップＳ３０７に行く。なお、本ステップで、ユーザ属性情報受付部１０６は、ユーザ識別情報もユーザ属性情報とともに受信することが好適である。

（ステップＳ３０６）ユーザ属性情報受付部１０６は、受け付けたユーザ属性情報を、ユーザ識別情報と対応付けて、図示しない記録媒体に一時蓄積する。なお、図示しない記録媒体は、例えば、ユーザ属性情報受付部１０６が保持している。

（ステップＳ３０７）嗜好情報取得部１０８は、嗜好情報を取得するタイミングであるか否かを判断する。嗜好情報を取得するタイミングであればステップＳ３０８に行き、嗜好情報を取得するタイミングでなければステップＳ３０９に行く。なお、嗜好情報を取得するタイミングは、例えば、メニュー出力装置１が、ユーザ識別情報で識別されるユーザが来店したことを示す情報を受信した場合である。また、嗜好情報を取得するタイミングは、例えば、ステップＳ３０１で、一のユーザ識別情報に対して、メニュー出力装置１が注文情報を、一の日に初めて受信した場合等である。また、嗜好情報を取得するタイミングは、例えば、図示しない手段が、ユーザの決済が完了した旨の情報を受信した場合である。

（ステップＳ３０８）嗜好情報取得部１０８は、嗜好情報取得処理を行う。嗜好情報取得処理について、図９のフローチャートを用いて説明する。

（ステップＳ３０９）図示しない受付手段が、在庫情報を変更する指示を受け付けたか否かを判断する。在庫情報を変更する指示を受け付ければステップＳ３１０に行き、在庫情報を変更する指示を受け付けなければステップＳ３１１に行く。なお、在庫情報を変更する指示は、変更内容を有する。変更内容は、変更する対象、および変更のための情報を有する。在庫情報を変更する指示は、例えば、「変更 ＜対象＞鶏肉 ＜変更データ＞０」である。「変更 ＜対象＞鶏肉 ＜変更データ＞０」は、食材「鶏肉」の在庫がなくなったことを示す。また、在庫情報を変更する指示は、例えば、「変更 ＜対象＞から揚げ ＜変更データ＞０」である。本指示は、飲食物識別情報「から揚げ」の在庫がなくなったことを示す。また、図示しない受付手段は、注文情報受付部１０１から、当該注文情報受付部１０１が受け付けた注文情報を用いて在庫情報を変更する指示を受け付けることは好適である。注文情報受付部１０１が、「注文 ＜対象＞から揚げ ＜数量＞２」を受け付けた場合、図示しない受付手段は、注文情報受付部１０１から、「変更 ＜対象＞から揚げ ＜内容＞＄在庫−２」を受け付ける。ここで「＄在庫」は、現在の「＜対象＞から揚げ」の在庫数を示す変数である。

（ステップＳ３１０）図示しない修正手段が、ステップＳ３０９において受け付けた在庫情報を変更する指示が有する変更内容に従って、在庫格納部１０７の在庫情報を変更する。

（ステップＳ３１１）図示しない受付手段は、メニューの出力指示を、メニュー出力端末２から受信したか否かを判断する。メニューの出力指示を受信すればステップＳ３０３に行き、受信しなければステップＳ３０１に戻る。

なお、図３のフローチャートにおいて、ステップＳ３１１でＹｅｓの場合、ステップＳ３０３に行ったが、メニュー取得部１１０がデフォルトの１以上のメニュー項目をメニュー項目格納部１０５から読み出し、メニューを構成しても良い。そして、出力部１１１が当該メニューをメニュー出力端末２に送信しても良い。

また、図３のフローチャートにおいて、注文情報を受信するごとに、動的にメニューを構成した。しかし、他のタイミングでメニューを構成しても良い。他のタイミングとは、例えば、定期的（１０分に１回など）、ユーザからの指示があった際などである。

さらに、図３のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、ステップＳ３０３のメニュー構成処理について、図４のフローチャートを用いて説明する。

（ステップＳ４０１）メニュー取得部１１０は、メニューを出力する先のユーザを識別するユーザ識別情報を取得する。なお、このユーザ識別情報は、例えば、ステップＳ３０１で受信されたユーザ識別情報である。

（ステップＳ４０２）メニュー取得部１１０は、ステップＳ４０１で取得したユーザ識別情報に対応する注文履歴情報を、注文履歴格納部１０２から読み出す。

（ステップＳ４０３）メニュー取得部１１０は、ステップＳ４０１で取得したユーザ識別情報に対応するユーザ属性情報が存在するか否かを判断する。ユーザ属性情報が存在すればステップＳ４０４に行き、ユーザ属性情報が存在しなければステップＳ４０５に行く。

（ステップＳ４０４）メニュー取得部１１０は、ステップＳ４０１で取得したユーザ識別情報に対応するユーザ属性情報を取得する。なお、このユーザ属性情報の取得処理は、ユーザ属性情報受付部１０６が行っても良い。

（ステップＳ４０５）メニュー取得部１１０は、在庫格納部１０７の在庫情報を取得する。

（ステップＳ４０６）メニュー取得部１１０は、ステップＳ４０１で取得したユーザ識別情報に対応する嗜好情報が存在するか否かを判断する。嗜好情報が存在すればステップＳ４０７に行き、嗜好情報が存在しなければステップＳ４０８に行く。

（ステップＳ４０７）メニュー取得部１１０は、ユーザ識別情報に対応する嗜好情報を取得する。

（ステップＳ４０８）ルール格納部１０９に飲食ルールが存在するか否かを判断する。飲食ルールが存在すればステップＳ４０９に行き、飲食ルールが存在しなければステップＳ４１０に行く。

（ステップＳ４０９）メニュー取得部１１０は、飲食ルールを適用したメニュー構成処理を行う。かかる処理について、図５のフローチャートを用いて説明する。上位処理にリターンする。

（ステップＳ４１０）メニュー取得部１１０は、飲食ルールを適用しないメニュー構成処理を行う。かかる処理について、図６のフローチャートを用いて説明する。上位処理にリターンする。

なお、図４のフローチャートにおいて、注文履歴情報、ユーザ属性情報、在庫情報、嗜好情報、飲食ルールを用いてメニューを構成した。しかし、これらのすべての情報を用いずに、注文履歴情報等のうち、１以上の情報を用いて、動的にメニューを構成しても良い。

次に、ステップＳ４０９の飲食ルールを適用したメニュー構成処理について、図５のフローチャートを用いて説明する。上位処理にリターンする。

（ステップＳ５０１）メニュー取得部１１０は、ルール格納部１０９に順序ルールが存在するか否かを判断する。順序ルールが存在すればステップＳ５０２に行き、順序ルールが存在しなければステップＳ５０４に行く。

（ステップＳ５０２）メニュー取得部１１０は、順序ルールに従って、飲食物識別情報または種類識別情報にランクを付与する。ここでは、メニュー取得部１１０は、次に選択される可能性が高い飲食物識別情報または種類識別情報に高い値のランクを付与する。また、メニュー取得部１１０は、既に選択された飲食物識別情報または種類識別情報や、順序ルールに従えば、選択されるのがかなり先になる飲食物識別情報または種類識別情報に低い値（例えば、選択されないような値）のランクを付与する。なお、ランクとは、メニュー項目の出現態様に差異を設けるための指標であり、ここでは、ランクの値が大きいメニュー項目ほど、目立つ態様または選択されやすい態様で、メニュー項目が表示される、とする。

（ステップＳ５０３）メニュー取得部１１０は、各メニュー項目が有する飲食物識別情報のランクまたは種類識別情報のランクを、各メニュー項目のランクとして付与する。

（ステップＳ５０４）メニュー取得部１１０は、ルール格納部１０９に総量ルールが存在するか否かを判断する。総量ルールが存在すればステップＳ５０５に行き、総量ルールが存在しなければステップＳ５１３に行く。

（ステップＳ５０５）メニュー取得部１１０は、ユーザ識別情報に対応する注文履歴情報であり、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文履歴情報を、注文履歴格納部１０２から読み出す。そして、メニュー取得部１１０は、読み出した注文履歴情報から、対象となる総量（例えば、カロリーの総量）である摂取総量を取得する。なお、メニュー取得部１１０は、例えば、注文履歴情報に含まれる各注文情報の属性値である対象の値を取得し、加算する。

（ステップＳ５０６）メニュー取得部１１０は、カウンタｉに１を代入する。

（ステップＳ５０７）メニュー取得部１１０は、ｉ番目のメニュー項目が存在するか否かを判断する。ｉ番目のメニュー項目が存在すればステップＳ５０８に行き、存在しなければステップＳ５１９に行く。

（ステップＳ５０８）メニュー取得部１１０は、ｉ番目のメニュー項目に対応する対象となる値であり、飲食物を摂取した場合の量（例えば、カロリー）を、飲食物属性情報格納部１０４から取得する。

（ステップＳ５０９）メニュー取得部１１０は、ステップＳ５０５で取得した摂取総量と、ステップＳ５０８で取得した摂取した場合の量とを加算し、総量ルールに含まれる制限の量の範囲内であるか否か（総量ルールに合致するか否か）を判断する。総量ルールに合致する場合はステップＳ５１０に行き、合致しない場合はステップＳ５１１に行く。

（ステップＳ５１０）メニュー取得部１１０は、ｉ番目のメニュー項目に、総量ルールに合致する場合に対応するランクを付加する。なお、例えば、メニュー取得部１１０は、ｉ番目のメニュー項目が選択されやすくなるように、ランクを閾値分だけ増加させる（例えば、「＋５」する）。

（ステップＳ５１１）メニュー取得部１１０は、ｉ番目のメニュー項目に、総量ルールに合致しない場合に対応するランクを付加する。なお、例えば、メニュー取得部１１０は、ｉ番目のメニュー項目が、絶対に選択されやすくなるように、ランクを閾値分だけ減少させる（例えば、「−∞」する）。なお、ここで、メニュー取得部１１０は、ｉ番目のメニュー項目を削除しても良い。

（ステップＳ５１２）メニュー取得部１１０は、カウンタｉを１、インクリメントする。ステップＳ５０７に戻る。

（ステップＳ５１３）メニュー取得部１１０は、ルール格納部１０９に特定総量ルールが存在するか否かを判断する。特定総量ルールが存在すればステップＳ５１４に行き、特定総量ルールが存在しなければステップＳ５２３に行く。

（ステップＳ５１４）メニュー取得部１１０は、注文履歴格納部１０２に存在する注文履歴情報であり、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文履歴情報であり、特定総量ルールに含まれる特定の飲食物の注文履歴情報を読み出す。そして、メニュー取得部１１０は、当該読み出した注文履歴情報から、対象となる総量（例えば、注文数）である摂取総量を取得する。なお、メニュー取得部１１０は、例えば、注文履歴情報に含まれる各注文情報の属性値である対象の値を取得し、加算する。

（ステップＳ５１５）メニュー取得部１１０は、特定の飲食物を飲食物識別情報または種類識別情報として有するメニュー項目を、メニュー項目格納部１０５から取得する。

（ステップＳ５１６）メニュー取得部１１０は、カウンタｉに１を代入する。

（ステップＳ５１７）メニュー取得部１１０は、ｉ番目のメニュー項目が存在するか否かを判断する。ｉ番目のメニュー項目が存在すればステップＳ５１８に行き、存在しなければステップＳ５２３に行く。

（ステップＳ５１８）メニュー取得部１１０は、ｉ番目のメニュー項目に対応する飲食物の摂取量（対象となる特定の量であり、例えば、注文数）を取得する。

（ステップＳ５１９）メニュー取得部１１０は、ステップＳ５１４で取得した特定の飲食物の摂取総量と、ステップＳ５１８で取得した量とを加算し、特定総量ルールに含まれる制限の量の範囲内であるか否か（特定総量ルールに合致するか否か）を判断する。特定総量ルールに合致する場合はステップＳ５２０に行き、合致しない場合はステップＳ５２１に行く。

（ステップＳ５２０）メニュー取得部１１０は、ｉ番目のメニュー項目に、特定総量ルールに合致する場合に対応するランクを付加する。なお、例えば、メニュー取得部１１０は、ｉ番目のメニュー項目が選択されやすくなるように、ランクを閾値分だけ増加させる（例えば、「＋１０」する）。

（ステップＳ５２１）メニュー取得部１１０は、ｉ番目のメニュー項目に、特定総量ルールに合致しない場合に対応するランクを付加する。なお、例えば、メニュー取得部１１０は、ｉ番目のメニュー項目が、絶対に選択されやすくなるように、ランクを閾値分だけ減少させる（例えば、「−∞」する）。なお、ここで、メニュー取得部１１０は、ｉ番目のメニュー項目を削除しても良い。

（ステップＳ５２２）メニュー取得部１１０は、カウンタｉを１、インクリメントする。ステップＳ５１７に戻る。

（ステップＳ５２３）メニュー取得部１１０は、飲食ルールを適用しないメニュー構成処理を行う。飲食ルールを適用しないメニュー構成処理について、図６のフローチャートを用いて説明する。上位処理にリターンする。

なお、図５のフローチャートにおいて、順序ルール、総量ルール、および特定総量ルールが、最大それぞれ１個存在する場合について説明した。しかし、ルール格納部１０９は、２以上の各種類のルールを格納していても良い。順序ルールが２以上存在する場合、ステップＳ５０２からステップＳ５０３が順序ルールの数だけループする。また、総量ルールが２以上存在する場合、ステップＳ５０５からステップＳ５１２が総量ルールの数だけループする。さらに、特定総量ルールが２以上存在する場合、ステップＳ５１４からステップＳ５２２が特定総量ルールの数だけループする。

また、図５のフローチャートにおいて、飲食ルールを用いて、メニュー項目にランクを付与したが、かかる処理方法は一例であることは言うまでもない。図５のフローチャートにおいて、飲食ルールに合致しないメニュー項目を、非表示としたり、グレーアウトしたりしても良いし、直ぐに選択されにくい位置に配置する等しても良い。

次に、ステップＳ４１０の飲食ルールを適用しないメニュー構成処理について、図６のフローチャートを用いて説明する。

（ステップＳ６０１）メニュー取得部１１０は、カウンタｉに１を代入する。

（ステップＳ６０２）メニュー取得部１１０は、ｉ番目のメニュー項目が存在するか否かを判断する。ｉ番目のメニュー項目が存在すればステップＳ６０３に行き、存在しなければステップＳ６１１に行く。

（ステップＳ６０３）メニュー取得部１１０は、ｉ番目のメニュー項目がユーザ属性情報を満たすか否かを判断する。ユーザ属性情報を満たす場合はステップＳ６０４に行き、ユーザ属性情報を満たさない場合はステップＳ６０５に行く。

（ステップＳ６０４）メニュー取得部１１０は、ユーザ属性情報を満たす場合に対応するように、ｉ番目のメニュー項目のランクを変更する。例えば、ｉ番目のメニュー項目が選択され易くなるように、メニュー取得部１１０は、ランクを閾値分だけ増加させる（例えば、「＋５」する）。

（ステップＳ６０５）メニュー取得部１１０は、ｉ番目のメニュー項目に、ユーザ属性情報を満たさない場合に対応するランクを付加する。なお、例えば、メニュー取得部１１０は、ｉ番目のメニュー項目が、選択されにくくなる、または絶対に選択されやすくなるように、ランクを閾値分だけ減少させる（例えば、「−∞」する）。なお、ここで、メニュー取得部１１０は、ｉ番目のメニュー項目を削除しても良い。

（ステップＳ６０６）メニュー取得部１１０は、ｉ番目のメニュー項目が、本ユーザの嗜好情報に対応するか（合致するか）否かを判断する。嗜好情報に対応する場合はステップＳ６０７に行き、嗜好情報に対応しない場合はステップＳ６０８に行く。

（ステップＳ６０７）メニュー取得部１１０は、嗜好情報に対応する場合に合致するように、ｉ番目のメニュー項目のランクを変更する。例えば、ｉ番目のメニュー項目が選択され易くなるように、メニュー取得部１１０は、ランクを閾値分だけ増加させる（例えば、「＋８」する）。なお、嗜好情報に対応しない場合、メニュー取得部１１０は、ランクを閾値分だけ減少させる、メニュー項目を削除する等の処理を行っても良い。

（ステップＳ６０８）メニュー取得部１１０は、在庫情報を用いて、ｉ番目のメニュー項目に対応する飲食物が提供可能であるか否かを判断する。提供可能である場合はステップＳ６１０に行き、提供可能でない場合はステップＳ６０９に行く。なお、メニュー取得部１１０は、ｉ番目のメニュー項目の飲食物識別子、または食材の情報を取得する。そして、メニュー取得部１１０は、当該飲食物識別子で識別される飲食物、または当該食材が、在庫情報を参照して、在庫が存在するか否かを判断する。そして、メニュー取得部１１０は、在庫が存在しない場合は、提供不可能である、と判断する。

（ステップＳ６０９）メニュー取得部１１０は、ｉ番目のメニュー項目を削除する。なお、メニュー取得部１１０は、ｉ番目のメニュー項目が選択されないように、ランクを変更しても良い。

（ステップＳ６１０）メニュー取得部１１０は、カウンタｉを１、インクリメントする。ステップＳ６０２に戻る。

（ステップＳ６１１）メニュー取得部１１０は、ランクを用いたメニュー構成処理を行う。かかる処理について、図７のフローチャートを用いて説明する。

（ステップＳ６１２）メニュー取得部１１０は、選択的メニュー項目処理を行う。選択的メニュー項目処理について、図８のフローチャートを用いて説明する。上位処理にリターンする。

なお、図６のフローチャートにおいて、図５のフローチャートと同様に、メニュー項目にランクを付与したが、かかる処理方法は一例であることは言うまでもない。図６のフローチャートにおいて、直ぐに非表示としたり、直ぐにグレーアウトしたりしても良いし、直ぐに選択されにくい位置に配置する等しても良い。

次に、テップＳ６１１のランクを用いたメニュー構成処理について、図７のフローチャートを用いて説明する。

（ステップＳ７０１）メニュー取得部１１０は、メニューの変更が、メニュー項目の配置の変更であるか否かを判断する。メニュー項目の配置の変更である場合はステップＳ７０２に行き、メニュー項目の配置の変更でない場合はステップＳ７０３に行く。

（ステップＳ７０２）メニュー取得部１１０は、各メニュー項目に対応するランクを用いて、メニュー項目の集合をソートして、配置を変更する。つまり、かかる処理により、ランクが大きいメニュー項目が、選択されやすい位置（例えば、上部）に配置される。上位処理にリターンする。

（ステップＳ７０３）メニュー取得部１１０は、メニューの変更が、ランクの低いメニュー項目や選択されてはいけないメニュー項目を、非選択となるような変更であるか否かを判断する。非選択となるような変更である場合はステップＳ７０４に行き、非選択となるような変更でない場合はステップＳ７０５に行く。

（ステップＳ７０４）メニュー取得部１１０は、閾値以下のランクのメニュー項目を非選択の状態とする。なお、非選択の状態とする処理は、例えば、メニュー項目の削除、グレイアウトとする処理等である。上位処理にリターンする。

（ステップＳ７０５）メニュー取得部１１０は、メニューの変更が、メニュー項目の内容の変更であるか否かを判断する。内容の変更である場合はステップＳ７０６に行き、内容の変更でない場合は上位処理にリターンする。

（ステップＳ７０６）メニュー取得部１１０は、カウンタｉに１を代入する。

（ステップＳ７０７）メニュー取得部１１０は、ｉ番目のメニュー項目が存在するか否かを判断する。ｉ番目のメニュー項目が存在すればステップＳ７０８に行き、存在しなければ上位処理にリターンする。

（ステップＳ７０８）メニュー取得部１１０は、ｉ番目のメニュー項目が内容変更の候補であるメニュー項目か否かを判断する。内容変更の候補である場合はステップＳ７０９に行き、内容変更の候補でない場合はステップＳ７１２に行く。なお、メニュー取得部１１０は、メニュー項目の情報を参照し、内容変更の候補のフラグを検知して、内容変更の候補であるメニュー項目か否かを判断しても良いし、内容変更条件や変更内容情報を参照して、内容変更の候補であるメニュー項目か否かを判断しても良い。

（ステップＳ７０９）メニュー取得部１１０は、本ユーザ識別情報に対応する注文履歴情報のうち、内容変更条件に関連する情報を取得する。例えば、内容変更条件が、「ビールの注文数＞＝３」である場合、注文履歴情報が有する注文情報のうち、「＜飲食物識別情報＞ビール」を含む注文情報を取得する。

（ステップＳ７１０）メニュー取得部１１０は、ステップＳ７０９で取得した内容変更条件に関連する情報が、ｉ番目のメニュー項目に対応する内容変更条件に合致するか否かを判断する。例えば、内容変更条件「ビールの注文数＞＝３」であり、ステップＳ７０９で取得した内容変更条件に関連する情報（ここでは、ビールの注文情報）が「ビールの注文数＝３（注文情報が３つ存在）」を示す場合、メニュー取得部１１０は、内容変更条件に合致すると判断する。

（ステップＳ７１１）メニュー取得部１１０は、変更内容情報を取得する。そして、メニュー取得部１１０は、変更内容情報に従って、ｉ番目のメニュー項目の内容を変更する。

（ステップＳ７１２）メニュー取得部１１０は、カウンタｉを１、インクリメントする。ステップＳ７０７に戻る。

なお、図７のフローチャートにおいて、３つのメニューの変更方法について説明した。しかし、ランクに応じて、選択されやすさが変化するようなメニューの変更であれば、他の処理でも良い。また、３つのメニューの変更方法のうち、２以上の変更方法を組み合わせても良い。さらに、例えば、３つのメニューの変更方法のうち選択する変更方法をどれにするかについて、メニュー取得部１１０は、予め情報を保持している、とする。

次に、ステップＳ６１２の選択的メニュー項目処理について、図８のフローチャートを用いて説明する。

（ステップＳ８０１）メニュー取得部１１０は、メニュー項目格納部１０５または、メモリ上のメニュー項目（消去されていないメニュー項目）から、選択的メニュー項目を取得する。

（ステップＳ８０２）メニュー取得部１１０は、カウンタｉに１を代入する。

（ステップＳ８０３）メニュー取得部１１０は、ステップＳ８０１で取得した選択的メニュー項目のうち、ｉ番目の選択的メニュー項目が存在するか否かを判断する。ｉ番目の選択的メニュー項目が存在すればステップＳ８０４に行き、ｉ番目の選択的メニュー項目が存在しなければ上位処理にリターンする。

（ステップＳ８０４）メニュー取得部１１０は、ｉ番目の選択的メニュー項目が有する選択条件に関連する情報を、注文履歴情報等から取得する。注文履歴情報等とは、注文履歴情報だけでも良いし、ユーザ属性情報、嗜好情報、在庫情報等を含んでも良い。

（ステップＳ８０５）メニュー取得部１１０は、カウンタｊに１を代入する。

（ステップＳ８０６）メニュー取得部１１０は、ｉ番目の選択的メニュー項目の中に、ｊ番目のメニュー項目部品が存在するか否かを判断する。ｊ番目のメニュー項目部品が存在すればステップＳ８０７に行き、ｊ番目のメニュー項目部品が存在しなければステップＳ８１０に行く。

（ステップＳ８０７）メニュー取得部１１０は、ｊ番目のメニュー項目部品に対応する選択条件を取得する。

（ステップＳ８０８）メニュー取得部１１０は、ステップＳ８０４で取得した情報が、ステップＳ８０７で取得した選択条件に合致するか否かを判断する。選択条件に合致する場合はステップＳ８０９に行き、選択条件に合致しない場合はステップＳ８１１に行く。

（ステップＳ８０９）メニュー取得部１１０は、ｊ番目のメニュー項目部品を、ｉ番目のメニュー項目の内容として取得する。

（ステップＳ８１０）メニュー取得部１１０は、カウンタｉを１、インクリメントする。ステップＳ８０３に戻る。

（ステップＳ８１１）メニュー取得部１１０は、カウンタｊを１、インクリメントする。ステップＳ８０６に戻る。

次に、ステップＳ３０８の嗜好情報取得処理について、図９のフローチャートを用いて説明する。

（ステップＳ９０１）嗜好情報取得部１０８は、ユーザ識別情報を取得する。

（ステップＳ９０２）嗜好情報取得部１０８は、ステップＳ９０１で取得したユーザ識別情報に対応する注文情報であって、現在来店中の飲食店に過去に来店した際に注文した内容に関する１以上の注文情報を、注文履歴格納部１０２から取得する。なお、ここでの１以上の注文情報も、注文履歴情報と言っても良い。

（ステップＳ９０３）嗜好情報取得部１０８は、カウンタｉに１を代入する。

（ステップＳ９０４）嗜好情報取得部１０８は、ｉ番目の飲食物識別情報が存在するか否かを判断する。なお、嗜好情報取得部１０８は、例えば、飲食物属性情報格納部１０４の情報を参照して、かかる判断を行う。

（ステップＳ９０５）嗜好情報取得部１０８は、ｉ番目の飲食物識別情報で識別される飲食物の注文の頻度を示す頻度情報を、ステップＳ９０２で取得した注文履歴情報から取得する。なお、頻度情報は、例えば、来店した日のうち、どの程度の割合の日で、注文しているか否かを示す情報でも良いし、注文した日の総数でも良いし、注文した総回数（１日に２回以上、注文する場合もある）でも良い。また、嗜好情報取得部１０８は、注文の量に関する量情報も、ステップＳ９０２で取得した注文履歴情報から取得しても良い。なお、量情報は、例えば、注文した総重量、総杯数などである。

（ステップＳ９０６）嗜好情報取得部１０８は、頻度情報、または量情報、または頻度情報と量情報を用いて、ｉ番目の飲食物識別情報で識別される飲食物の好きな度合いを示す嗜好レベルを取得する。なお、頻度情報、または量情報が大きい値を示すほど、通常、嗜好レベルが高くなる。

（ステップＳ９０７）嗜好情報取得部１０８は、ｉ番目の飲食物識別情報と、ステップＳ９０６で取得した嗜好レベルとを対応付けて蓄積する。なお、嗜好情報取得部１０８は、図示しない記録媒体に飲食物識別情報と嗜好レベルとを対応付けて蓄積する。

（ステップＳ９０８）嗜好情報取得部１０８は、カウンタｉを１、インクリメントする。ステップＳ９０４に戻る。

（ステップＳ９０９）嗜好情報取得部１０８は、カウンタｉに１を代入する。

（ステップＳ９１０）嗜好情報取得部１０８は、ｉ番目の種類識別情報が存在するか否かを判断する。なお、嗜好情報取得部１０８は、例えば、飲食物属性情報格納部１０４の情報を参照して、かかる判断を行う。なお、種類識別情報とは、飲食物の種類を識別する情報であり、ジャンル識別情報と言っても良い。飲食物の種類とは、どのような分類方法によってグループ化されたものでも良い。

（ステップＳ９１１）嗜好情報取得部１０８は、ｉ番目の種類識別情報で識別される飲食物の注文の頻度を示す頻度情報を、ステップＳ９０２で取得した注文履歴情報から取得する。また、嗜好情報取得部１０８は、ｉ番目の種類識別情報で識別される飲食物の注文の量に関する量情報も、ステップＳ９０２で取得した注文履歴情報から取得しても良い。

（ステップＳ９１２）嗜好情報取得部１０８は、頻度情報、または量情報、または頻度情報と量情報を用いて、ｉ番目の種類識別情報で識別される種類の飲食物の好きな度合いを示す嗜好レベルを取得する。なお、頻度情報、または量情報が大きい値を示すほど、通常、嗜好レベルが高くなる。

（ステップＳ９１３）嗜好情報取得部１０８は、ｉ番目の種類識別情報と、ステップＳ９１２で取得した嗜好レベルとを対応付けて蓄積する。なお、嗜好情報取得部１０８は、図示しない記録媒体に種類識別情報と嗜好レベルとを対応付けて蓄積する。

（ステップＳ９１４）嗜好情報取得部１０８は、カウンタｉを１、インクリメントする。ステップＳ９１０に戻る。

次に、メニュー出力端末２の動作について説明する。メニュー出力端末２のメニュー受信部２１は、メニュー出力装置１からメニューを受信する。そして、メニュー出力部２２は、当該受信されたメニューをディスプレイ上に表示する。また、表示されているメニューを用いて、ユーザが注文を行うと、注文受付部２３は注文情報を受け付ける。そして、
注文送信部２４は、注文情報をメニュー出力装置１に送信する。なお、注文送信部２４は、注文情報を、当該ユーザのユーザ識別情報と共に送信することは好適である。また、ユーザ識別情報は、例えば、メニュー出力端末２の図示しない記憶手段に記憶されている。

なお、メニュー出力端末２は公知技術により実現可能であるので、詳細な説明を省略する。

以下、本実施の形態におけるメニュー出力システムの具体的な動作について説明する。メニュー出力システムの概念図は図１である。

今、メニュー項目格納部１０５は、図１０に示す多数のメニュー項目を格納している、とする。図１０はメニュー項目管理表である。メニュー項目管理表は、「ＩＤ」「種類識別情報」「飲食物識別情報」「選択フラグ」「内容選択条件」「メニュー項目内容」の属性値を有するレコード（メニュー項目）を１以上格納している。属性「種類識別情報」は、飲食物の種類を示す情報である。種類とは、ジャンルやカテゴリーと言っても良い。「選択フラグ」は、メニュー項目が選択的メニュー項目であるか否かを示す。「選択フラグ」が「１」の場合は、メニュー項目は選択的メニュー項目である。また、「メニュー項目内容」として、「価格」「数量」を有する。また、メニュー項目は、飲食物の画像や動画等を有することは好適である。また、「ＩＤ」は、レコードを識別する情報である。また、また、図１０における「ＩＤ＝１」のレコードは選択的メニュー項目である。そして、「ＩＤ＝１」のレコードの「内容選択条件」「メニュー項目内容」は、ユーザが使った総額が３０００円以下である場合は、えだ豆の価格は３００円のメニュー項目が選択されるが、総額が３０００円を超えた後は、えだ豆の価格は２５０円のメニュー項目が選択されることを示す。また、「ＩＤ＝２８」のレコードの「内容選択条件」「メニュー項目内容」は、注文したから揚げが０の場合（初めて注文する場合）は、数量「８０ｇ」のメニュー項目が選択されるが、注文したから揚げが１以上の場合は、数量「１６０ｇ」のメニュー項目が選択されることを示す。なお、選択的メニュー項目の選択候補のメニュー項目は、「ＩＤ＝１９」のレコードが示すように２より多くても良い。つまり、選択的メニュー項目により、注文状況に応じて、価格や数量等のメニューの内容が変更され得る。

また、注文履歴格納部１０２は、図１１に示す注文履歴情報を格納している。図１１は、注文履歴管理表である。注文履歴管理表は、多数の注文情報を有する。注文履歴管理表は、ここでは、現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す注文情報、および過去注文履歴情報を有する。注文履歴管理表は、「ＩＤ」「ユーザ識別情報」「日時」「飲食物識別情報」「数量」「ユーザ属性情報」を有するレコード（注文情報）を多数格納している。「日時」は注文された日時であり、上述した時刻情報である。また、「数量」は注文された数量である。「ユーザ属性情報」は、ここでは一緒に来客した人数を示す。なお、図１５において、一のユーザの注文情報だけが管理されているように見えるが、通常、多数のユーザの注文情報が管理されている。

また、飲食物属性情報格納部１０４は、図１２に示す飲食物属性情報を格納している。図１２は、飲食物属性情報管理表である。飲食物属性情報管理表は、「ＩＤ」「飲食物識別情報」「食材識別情報」「カロリー」「重量」「人数」を有するレコード（飲食物属性情報）を多数格納している。「食材識別情報」は飲食物を調理するのに必要な食材の情報であり、飲食物識別情報と同じ場合もある。「カロリー」は飲食物を摂取した時に取り込まれるカロリー数を示す。「重量」は飲食物の重量である。「人数」は摂取する際の適切な人数である。

また、在庫格納部１０７は、図１３に示す在庫情報を格納している。図１３は、在庫管理表である。在庫管理表は、「ＩＤ」「飲食物識別情報」「食材識別情報」「在庫数量」を有するレコード（在庫情報）を多数格納している。

さらに、ルール格納部１０９は、図１４に示す飲食ルールを格納している。図１４はルール管理表である。ルール管理表は、「ＩＤ」「ユーザ識別情報」「飲食ルール」を有するレコードを多数格納している。「飲食ルール」は「ルール種別」「ルール内容」を有する。「ルール種別」は、ルールの種類を示す。「ルール内容」はルールの内容を示す。

かかる状況において、ユーザ識別情報「００１５」で識別されるユーザ（以下、本ユーザという。）が、ある飲食店に入った後、メニュー出力端末２を操作して、メニュー出力端末２は、メニュー出力装置１からメニューを受信し、図１５に示すようなメニュー画面を出力した、とする。なお、動作の詳細は、例えば、以下である。つまり、メニュー出力装置１がメニュー出力指示をメニュー出力端末２から受信する。そして、メニュー取得部１１０が図１０のメニュー項目管理表を読み込み、図１５に示すメニューを構成する。次に、出力部１１１は当該メニューを送信する。そして、メニュー出力端末２のメニュー受信部２１はメニューを受信し、メニュー出力部２２は図１５のメニューを出力する。

また、例えば、本店舗の店員または本ユーザが、ユーザ属性情報「一人」をユーザ識別情報「００１５」と対にしてメニュー出力装置１に送信し、メニュー出力装置１のユーザ属性情報受付部１０６はユーザ属性情報「一人」とユーザ識別情報「００１５」とを受信し、一時蓄積する。

次に、本ユーザは、図１５の画面を用いて、「えだ豆」を注文した、とする。すると、メニュー出力端末２は、注文情報「＜ユーザ識別情報＞００１５，＜飲食物識別情報＞えだ豆，＜数量＞１」を、メニュー出力装置１に送信する。

次に、メニュー出力装置１の注文情報受付部１０１は、注文情報「＜ユーザ識別情報００１５，＜飲食物識別情報＞えだ豆，＜数量＞１」を受信する。

次に、注文履歴蓄積部１０３は、受信した注文情報を、ユーザ識別情報「００１５」と対応付けて、注文履歴格納部１０２に蓄積する。なお、ここで蓄積する注文情報は、「＜飲食物識別情報＞えだ豆，＜数量＞１」でも良い。また、注文履歴蓄積部１０３は、日時「２０１２／８／６ １７：３５」を図示しない時計から取得する。そして、注文履歴蓄積部１０３は、注文情報と日時とユーザ属性情報「一人」とを対応付けて蓄積する。

次に、メニュー取得部１１０は、以下のようにメニューを構成する。つまり、メニュー取得部１１０は、ユーザ識別情報「００１５」を取得する。次に、メニュー取得部１１０は、ユーザ識別情報「００１５」に対応する注文履歴情報を、注文履歴格納部１０２から読み出す。次に、メニュー取得部１１０は、ユーザ識別情報に対応するユーザ属性情報「００１５」に対応するユーザ属性情報「一人」を取得する。また、メニュー取得部１１０は、図１３の在庫情報を取得する。さらに、メニュー取得部１１０は、ユーザ識別情報「００１５」に対応する嗜好情報「＜飲食物識別情報＞ビール＜嗜好レベル＞１０，＜飲食物識別情報＞えだ豆＜嗜好レベル＞５，＜飲食物識別情報＞豆腐＜嗜好レベル＞２，・・・」を取得する。なお、この嗜好情報は、嗜好情報取得部１０８が、図９で説明した動作により、取得した情報である。

次に、メニュー取得部１１０は、ユーザ識別情報「００１５」に対応する順序ルール「おつまみ→魚→肉→デザート」を、図１４のルール管理表から取得する。そして、本順序ルールと、注文履歴格納部１０２に蓄積された注文情報「＜飲食物識別情報＞えだ豆，＜数量＞１」を用いて、「おつまみ」の注文の次は、「魚」であり、「おつまみ」の注文は完了した、と認識する。つまり、メニュー取得部１１０は、種類識別情報「おつまみ」のランクを「１」、種類識別情報「魚」のランクを「１０」、種類識別情報「肉」のランクを「４」、種類識別情報「デザート」のランクを「２」とする。なお、ランクは「０」から「１０」の整数であり、大きい値ほど選択されやすい位置の表示されるものとする。また、種類識別情報「ドリンク」のランクは「５」である、とする。

次に、メニュー取得部１１０は、ユーザ識別情報「００１５」に対応する総量ルールと、特定総量ルールとを取得する。そいて、メニュー取得部１１０は、ユーザ識別情報「００１５」に対応する総量ルール、特定総量ルールを満たすか否かを判断する。ここで、＜飲食物識別情報＞えだ豆のカロリー「５０ＫＣａｌ」を図１２の飲食物属性情報管理表から取得する。そして、メニュー取得部１１０は、総量ルールを満たさない、と判断する。また、メニュー取得部１１０は、本日の注文情報の中で、ビールの注文情報は存在しないので、特定総量ルール「ビール＜＝３杯」を満たさない、と判断する。

そして、次に、メニュー取得部１１０は、ユーザ属性情報「一人」を用いて、各メニュー項目のランクを変更する。例えば、メニュー取得部１１０は、「人数」に１を含まない飲食物情報（「人数＝１」「人数＝1〜２」は１を含むと判断される。）に対応するメニュー項目のランクを「−∞」に変更する。つまり、飲食物識別情報「おさしみセット」や「から揚げ」は「人数」に１を含まない飲食物情報であるので、これらのメニュー項目には「−∞」が付与される。なお、ここでは、デフォルトのメニュー項目のランクは「５」である、とする。また、「その他」のランクは「０」である、とする。

次に、メニュー取得部１１０は、在庫情報を用いて、提供不可な飲食物を決定し、当該飲食物に対応するメニュー項目を削除する。なお、この段階では、提供不可なメニュー項目は存在しない。

次に、メニュー取得部１１０は、ランクを用いて、メニュー項目の集合をソートする。つまり、メニュー取得部１１０は、ランクを用いて、種類識別情報「魚」、「ドリンク」、「肉」、「デザート」、「おつまみ」、「他」の順に、メニュー項目の集合を並び替える。

また、メニュー取得部１１０は、閾値以下のランクのメニュー項目を非選択（ここでは、例えば、削除）とする。ここでは、例えば、ランク「−∞」の「おさしみセット」や「から揚げ」が削除される。

次に、メニュー取得部１１０は、メニューの内容の変更を行うか否かを判断する。ここでは、メニューの内容の変更を行わない、と判断した、とする。

次に、メニュー取得部１１０は、選択的メニュー項目処理を行う。つまり、メニュー取得部１１０は、例えば、図１０の「ＩＤ＝１９」のメニュー項目が選択的メニュー項目である、と判断する。そして、メニュー取得部１１０は、内容選択条件に関連する情報である価格を注文履歴情報から取得する。具体的には、メニュー取得部１１０は、本ユーザの本日の注文情報から価格「３００円」のみを取得する。メニュー取得部１１０は、この価格「３００円」から総額「３００円」を得る。そして、メニュー取得部１１０は、総額「３００円」は、選択的メニュー項目が有する「総額＜＝１５００円」を満たす、と判断する。そして、メニュー取得部１１０は、メニュー項目内容「＜価格＞７００円，＜数量＞６０ｇ，・・・」を取得する。

そして、メニュー取得部１１０は、図１６のメニューを得る。図１６において、選択されやすい位置に、種類識別情報「魚」の画面が配置されている。また、一人向けでは無い「おさしみセット」は削除されている。

次に、出力部１１１は、図１６のメニューをメニュー出力端末２に送信する。

次に、メニュー出力端末２のメニュー受信部２１は図１６のメニューを受信し、メニュー出力部２２は当該メニューを出力する。

次に、本ユーザは、ビールを次々に３杯注文した、とする。すると、特定総量ルール「ビール「３杯まで」」の制限ぎりぎりになったことを、メニュー取得部１１０は検知する。

次に、メニュー取得部１１０は、飲食物識別情報＜ビール＞に対応するメニュー項目が削除されたメニューを構成する。そして、出力部１１１は、当該メニューをメニュー出力端末２に送信する。

次に、メニュー出力端末２は、当該メニューを受信し、出力する。

なお、本ユーザが、例えば、フォアグラを注文した後、すべてのユーザに適用されるルール「フォアグラ「１個まで」」が、本ユーザにも適用され、フォアグラのメニュー項目は削除される。かかる処理は、上述した処理と同様である。

以上、本実施の形態によれば、飲食物の注文の際に、注文を行うためのメニューの使用性を向上できる。

また、本実施の形態によれば、飲食物の注文状況、飲食ルール、お客様の属性、在庫状況、お客様の嗜好等に応じて、適切にメニュー画面を変更できる。

また、本実施の形態によれば、注文をするごとにメニューの変更を行えることにより、常に、ユーザの状況に応じたメニューをユーザに提供できる。

なお、本実施の形態における処理は、ソフトウェアで実現しても良い。そして、このソフトウェアをソフトウェアダウンロード等により配布しても良い。また、このソフトウェアをＣＤ−ＲＯＭなどの記録媒体に記録して流布しても良い。なお、このことは、本明細書における他の実施の形態においても該当する。なお、本実施の形態における情報処理装置を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、ユーザが現在来店中の飲食店において現在の来店中に注文した飲食物の履歴を示す情報であって、現在の来店中に前記注文情報受付部が受け付けた前記注文情報の集合である注文履歴情報が格納される注文履歴格納部と、前記飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、前記飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部とにアクセス可能なコンピュータを、ユーザが飲食店に対して注文した飲食物を示す情報であって、当該飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付部と、前記注文情報受付部が受け付けた注文情報を前記注文履歴格納部に蓄積する注文履歴蓄積部と、前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報と、前記飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、前記メニュー取得部が取得したメニューを出力する出力部として機能させるためのプログラムである。

また、上記プログラムにおいて、前記コンピュータは、飲食物属性情報を有するルールであり、飲食に関するルールである１以上の飲食ルールを格納し得るルール格納部にさらにアクセス可能であり、前記メニュー取得部は、前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報を前記１以上の飲食ルールに適用し、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、コンピュータを、ユーザの属性を示す情報であるユーザ属性情報を受け付けるユーザ属性情報受付部としてさらに機能させ、前記メニュー取得部は、さらに、前記ユーザ属性情報受付部が受け付けたユーザ属性情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、飲食物に関する在庫状況を示す情報である在庫情報が、当該飲食物の飲食物識別情報と対応付けて格納されている在庫格納部にさらにアクセス可能なコンピュータを機能させるためのプログラムであって、前記メニュー取得部は、さらに、在庫情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記注文履歴格納部には、さらに、現在来店中の前記飲食店においてユーザが過去の来店時に注文した飲食物の履歴を示す情報であって、過去の来店時に前記注文情報受付部が受け付けた前記注文情報の集合である過去注文履歴情報が格納されており、前記過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する嗜好情報取得部として、コンピュータをさらに機能させるためのプログラムであって、前記メニュー取得部は、さらに、前記嗜好情報に応じた態様のメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記メニュー取得部は、前記メニュー項目の一部の値を変更したメニューを取得するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記メニュー取得部は、前記注文情報受付部が注文情報を受け付ける毎に、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得し、前記出力部は、前記メニュー取得部が取得したメニューを出力するものとして、コンピュータを機能させるためのプログラムである。

また、上記プログラムにおいて、前記１以上のメニュー項目のうちの、少なくとも一部のメニュー項目は、出力されるメニュー項目の内容を示すメニュー項目内容と、当該メニュー項目内容が選択される条件を示す選択条件とを有する２以上のメニュー項目部品を有する選択的メニュー項目であり、前記メニュー取得部は、前記注文履歴情報と前記飲食物属性情報とを前記選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成するものとして、コンピュータを機能させるためのプログラムである。

また、図１７は、本明細書で述べたプログラムを実行して、上述した種々の実施の形態のメニュー出力装置を実現するコンピュータの外観を示す。上述の実施の形態は、コンピュータハードウェア及びその上で実行されるコンピュータプログラムで実現され得る。図１７は、このコンピュータシステム３００の概観図であり、図１８は、システム３００のブロック図である。

図１７において、コンピュータシステム３００は、ＣＤ−ＲＯＭドライブを含むコンピュータ３０１と、キーボード３０２と、マウス３０３と、モニタ３０４とを含む。

図１８において、コンピュータ３０１は、ＣＤ−ＲＯＭドライブ３０１２に加えて、ＭＰＵ３０１３と、ＭＰＵ３０１３、ＣＤ−ＲＯＭドライブ３０１２に接続されたバス３０１４と、ブートアッププログラム等のプログラムを記憶するためのＲＯＭ３０１５と、ＭＰＵ３０１３に接続され、アプリケーションプログラムの命令を一時的に記憶するとともに一時記憶空間を提供するためのＲＡＭ３０１６と、アプリケーションプログラム、システムプログラム、及びデータを記憶するためのハードディスク３０１７とを含む。ここでは、図示しないが、コンピュータ３０１は、さらに、ＬＡＮへの接続を提供するネットワークカードを含んでも良い。

コンピュータシステム３００に、上述した実施の形態のメニュー出力装置の機能を実行させるプログラムは、ＣＤ−ＲＯＭ３１０１に記憶されて、ＣＤ−ＲＯＭドライブ３０１２に挿入され、さらにハードディスク３０１７に転送されても良い。これに代えて、プログラムは、図示しないネットワークを介してコンピュータ３０１に送信され、ハードディスク３０１７に記憶されても良い。プログラムは実行の際にＲＡＭ３０１６にロードされる。プログラムは、ＣＤ−ＲＯＭ３１０１またはネットワークから直接、ロードされても良い。

プログラムは、コンピュータ３０１に、上述した実施の形態のメニュー出力装置の機能を実行させるオペレーティングシステム（ＯＳ）、またはサードパーティープログラム等は、必ずしも含まなくても良い。プログラムは、制御された態様で適切な機能（モジュール）を呼び出し、所望の結果が得られるようにする命令の部分のみを含んでいれば良い。コンピュータシステム３００がどのように動作するかは周知であり、詳細な説明は省略する。

なお、上記プログラムにおいて、情報を送信する送信ステップや、情報を受信する受信ステップなどでは、ハードウェアによって行われる処理、例えば、送信ステップにおけるモデムやインターフェースカードなどで行われる処理（ハードウェアでしか行われない処理）は含まれない。

また、上記プログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、あるいは分散処理を行ってもよい。

また、上記各実施の形態において、一の装置に存在する２以上の通信手段は、物理的に一の媒体で実現されても良いことは言うまでもない。

また、上記各実施の形態において、各処理（各機能）は、単一の装置（システム）によって集中処理されることによって実現されてもよく、あるいは、複数の装置によって分散処理されることによって実現されてもよい。

本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

以上のように、本発明にかかるメニュー出力装置は、飲食物の注文の際に、注文を行うためのメニューの使用性を向上できる、という効果を有し、飲食店で利用されるメニュー出力装置等として有用である。

１ メニュー出力装置
２ メニュー出力端末
２１ メニュー受信部
２２ メニュー出力部
２３ 注文受付部
２４ 注文送信部
１０１ 注文情報受付部
１０２ 注文履歴格納部
１０３ 注文履歴蓄積部
１０４ 飲食物属性情報格納部
１０５ メニュー項目格納部
１０６ ユーザ属性情報受付部
１０７ 在庫格納部
１０８ 嗜好情報取得部
１０９ ルール格納部
１１０ メニュー取得部
１１１ 出力部

Claims (12)

1. ユーザが注文した飲食物を示す情報であって、当該飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付部と、
   ユーザが注文した飲食物の履歴を示す情報であって、前記注文情報受付部が受け付けた前記注文情報の集合である注文履歴情報が格納される注文履歴格納部と、
   前記注文情報受付部が受け付けた注文情報を前記注文履歴格納部に蓄積する注文履歴蓄積部と、
   前記飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、
   前記飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部と、
   前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報と、前記飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、
   前記メニュー取得部が取得したメニューを出力する出力部とを備えたメニュー出力装置。
2. 飲食物属性情報を有するルールであり、飲食に関するルールである１以上の飲食ルールを格納し得るルール格納部をさらに具備し、
   前記メニュー取得部は、
   前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報を前記１以上の飲食ルールに適用し、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得する請求項１記載のメニュー出力装置。
3. ユーザの属性を示す情報であるユーザ属性情報を受け付けるユーザ属性情報受付部をさらに備え、
   前記メニュー取得部は、
   さらに、前記ユーザ属性情報受付部が受け付けたユーザ属性情報に応じた態様のメニューを取得する請求項１または請求項２記載のメニュー出力装置。
4. 飲食物に関する在庫状況を示す情報である在庫情報が、当該飲食物の飲食物識別情報と対応付けて格納されている在庫格納部をさらに備え、
   前記メニュー取得部は、
   さらに、在庫情報に応じた態様のメニューを取得する請求項１から請求項３いずれか一項に記載のメニュー出力装置。
5. 前記注文履歴格納部には、
   さらに、前記ユーザが過去に注文した飲食物の履歴を示す情報であって、過去に前記注文情報受付部が受け付けた前記注文情報の集合である過去注文履歴情報が格納されており、
   前記過去注文履歴情報からユーザの嗜好を示す情報である嗜好情報を取得する嗜好情報取得部をさらに備え、
   前記メニュー取得部は、
   さらに、前記嗜好情報に応じた態様のメニューを取得する請求項１から請求項４いずれか一項に記載のメニュー出力装置。
6. 前記メニュー取得部は、
   前記メニュー項目の配置を、デフォルトの配置に対して変更したメニューを取得する請求項１から請求項５いずれか一項に記載のメニュー出力装置。
7. 前記メニュー取得部は、
   前記メニュー項目の一部を削除、または選択を受け付けない状態としたメニューを取得する請求項１から請求項５いずれか一項に記載のメニュー出力装置。
8. 前記メニュー取得部は、
   前記メニュー項目の一部の値を変更したメニューを取得する請求項１から請求項５いずれか一項に記載のメニュー出力装置。
9. 前記メニュー取得部は、
   前記注文情報受付部が注文情報を受け付ける毎に、前記注文履歴情報と前記飲食物属性情報とに応じた態様のメニューを取得し、
   前記出力部は、
   前記メニュー取得部が取得したメニューを出力する請求項１から請求項８いずれか一項に記載のメニュー出力装置。
10. 前記１以上のメニュー項目のうちの、少なくとも一部のメニュー項目は、
    出力されるメニュー項目の内容を示すメニュー項目内容と、当該メニュー項目内容が選択される条件を示す選択条件とを有する２以上のメニュー項目部品を有する選択的メニュー項目であり、
    前記メニュー取得部は、
    前記注文履歴情報と前記飲食物属性情報とを前記選択条件に適用し、合致する選択条件に対応するメニュー項目内容を取得し、メニューを構成する請求項１から請求項９いずれか一項に記載のメニュー出力装置。
11. ユーザが注文した飲食物の履歴を示す情報であって、前記注文情報受付部が受け付けた前記注文情報の集合である注文履歴情報が格納される注文履歴格納部と、
    前記飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、
    前記飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部とを具備する記録媒体を用い、注文情報受付部、注文履歴蓄積部、メニュー取得部、および出力部により実現されるメニュー出力方法であって、
    前記注文情報受付部が、ユーザが注文した飲食物を示す情報であって、当該飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付ステップと、
    前記注文履歴蓄積部が、前記注文情報受付ステップで受け付けられた注文情報を前記注文履歴格納部に蓄積する注文情報蓄積ステップと、
    前記メニュー取得部が、前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報と、前記飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得ステップと、
    前記出力部が、前記メニュー取得ステップで取得されたメニューを出力する出力ステップとを具備するメニュー出力方法。
12. ユーザが注文した飲食物の履歴を示す情報であって、前記注文情報受付部が受け付けた前記注文情報の集合である注文履歴情報が格納される注文履歴格納部と、
    前記飲食物識別情報と対応付けられた情報であって、当該飲食物識別情報が示す飲食物の属性を示す情報である飲食物属性情報が格納される飲食物属性情報格納部と、
    前記飲食物識別情報が示す飲食物に関する情報であって、メニューに配置可能な情報である１以上のメニュー項目が格納されるメニュー項目格納部とにアクセス可能なコンピュータを、
    ユーザが注文した飲食物を示す情報であって、当該飲食物の識別情報である飲食物識別情報を有する情報である注文情報を受け付ける注文情報受付部と、
    前記注文情報受付部が受け付けた注文情報を前記注文履歴格納部に蓄積する注文履歴蓄積部と、
    前記メニュー項目を配置したメニューであって、前記注文履歴格納部に格納された注文履歴情報と、前記飲食物属性情報格納部に格納された飲食物属性情報とに応じた態様のメニューを取得するメニュー取得部と、
    前記メニュー取得部が取得したメニューを出力する出力部として機能させるためのプログラム。

Images