JP2011113374A - 献立決定支援装置、献立決定支援システム、献立決定支援方法、献立決定支援プログラム、記憶媒体 - Google Patents

Abstract

【課題】地域毎の食材または特産品を用いる献立を提案することができる、また、地域毎の旬の時期の違いを反映した献立を提案することができる献立決定支援技術を提供する。
【解決手段】献立を決定することを支援する装置であって、地域を特定する地域特定部と、日付を特定する日付特定部と、料理とその料理に用いられる食材の情報を格納する記憶部と、記憶部が格納している情報を用いて献立を提案する献立提案部と、を備え、記憶部は、前記食材の情報として、地域および時期毎の旬の食材またはその地域の特産品の少なくともいずれかを特定する情報を格納しており、献立提案部は、地域特定部が特定した地域および日付特定部が特定した日付に対応する食材を用いた献立の情報を前記記憶部から検索し、提案献立として出力する。
【選択図】図１

Description

本発明は、料理の献立を決定することを支援する技術に関するものである。

従来、料理の献立を提案する技術として、下記特許文献１〜３がある。
下記特許文献１では、カレンダーに基づいて予め旬の素材を登録しておき、ユーザの操作日に対応した食材を検索条件に加えることが記載されている。

下記特許文献２では、食材ごとに旬に関する情報を備え、暦情報を有する計時手段により算出された暦と対応する旬の食材を優先的に選別することが記載されている。

下記特許文献３では、現在の季節を特定するためのタイマを用いることが記載されている。

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

上記特許文献１〜３に記載の技術では、例えば地域の特産品など、各地域でよく使われる食材が考慮されていないため、地域によっては入手困難な食材が献立として提案される場合がある。また、地域に合った季節感ある献立の提案が難しい。

本発明は、上記のような課題を解決するためになされたものであり、地域に合った献立を提案することのできる献立決定支援技術を提供することを目的とする。

本発明に係る献立決定支援装置は、地域と時期毎の食材または地域特産品を特定する情報を保持しており、その地域と時期毎の食材または特産品を用いる献立を提案する。

本発明に係る献立決定支援装置によれば、地域毎の食材または特産品を用いる献立を提案することができる。また、地域毎の旬の時期の違いを反映した献立を提案することができる。

実施の形態１に係る献立決定支援装置１００の機能ブロック図である。 レシピデータベース１３１が保持するレシピデータの構成とデータ例を示す図である。 地域食材データベース１３２が保持している地域食材テーブル１３２１の構成とデータ例を示す図である。 献立決定支援装置１００が献立を提案する過程を示す処理フローである。 図４のステップＳ４０９の詳細手順を示す処理フローである。 実施の形態２において、制御部１４０がレシピデータベース１３１の「出来上がりイメージ」欄の画像データを用いて献立を提案する基準を説明する図である。 制御部１４０がレシピデータベース１３１の「出来上がりイメージ」欄の画像データを用いて献立を１品のみ提案する基準を説明する図である。 料理の出来上がりイメージのうちＲＧＢ値を算出する際に用いる色または座標を指定したレシピデータの例を示す図である。 ユーザデータベース１３３が格納する選択履歴情報１３３１の構成とデータ例を示す図である。 出力部１６０の画面表示イメージを示す図である。 実施の形態４において地域食材データベース１３２が保持する食材種類情報１３２２の構成とデータ例を示す図である。 ユーザが同じ食材を連続して希望した場合の献立提案例を示す図である。 レシピデータに含まれる各項目を表示するか否かを定義するデータを示す図である。 旬の時期が同じ、または旬の時期が近い単位で地域をグループ分けした例を示す図である。 図１４と同じ内容のデータを日本地図上に示した図である。 プルダウンメニューから宮城県を選択した例を示す図である。 郵便番号から地域情報を取得する場合の入力および表示例である。 電話番号から地域情報を取得する場合の入力および表示例である。 似た気候の地域をグループ分けした例を示す図である。 図１９に示した地域のグループ分けを日本地図上に示した図である。 日時設定画面の１例を示す図である。 カレンダー上で日付を指定する画面例である。 月日入力欄に月日を数値入力する画面例である。 プルダウンメニューで月日を選択する画面例である。 実施の形態１２に係る献立決定支援装置１００の構成図である。

＜実施の形態１＞
本明細書中においては、献立全体を構成する料理一品一品を「料理」、一つ又は複数の料理を組み合わせた献立全体を「献立」、「献立」と「料理」のどちらを指す場合もありうる場合は「献立料理」と記載することとする。つまり、献立とは、一品以上の料理を含み、ユーザから入力された条件にしたがって提案するものであり、主食のみの献立もありうるし、主食と副菜などからなる献立もありうる。

図１は、本発明の実施の形態１に係る献立決定支援装置１００の機能ブロック図である。献立決定支援装置１００は、地域特定部１１０、日付特定部１２０、記憶部１３０、制御部１４０、入力部１５０、出力部１６０を備える。

地域特定部１１０は、献立決定支援装置１００の現在位置を、地域単位で特定する。ここでいう地域とは、旬の食材や特産品がそれぞれに異なる程度の大きさの範囲を指し、後述の地域食材データベース１３２における地域と同程度の範囲であることが好ましい。地域を特定する手法には、任意の公知技術を用いることができる。例えばＧＰＳを用いて現在位置を特定する、などの手法が考えられる。

日付特定部１２０は、現在日時を特定する。例えばタイマなどを用いて日付特定部１２０を構成することができる。

記憶部１３０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置で構成され、レシピデータベース１３１、地域食材データベース１３２、ユーザデータベース１３３を格納している。

制御部１４０は、献立決定支援装置１００の現在位置（地域）と日付、および記憶部１３０が格納している各データベースを用いて、提案する献立を決定し、出力部１６０より出力する。献立を決定する過程については後述する。

入力部１５０は、献立を提案するよう献立決定支援装置１００に指示するためにユーザが使用する操作指示部である。提案に際しての条件設定を入力することもできる。入力部１５０は、例えばキーボード、キーパッド、タッチパッド、マウス、トラックボールなどの形態で実現することができる。また、操作メニューを表示するための画面表示部などを適宜備える。

出力部１６０は、制御部１４０が決定した提案する献立を出力する。出力形式は、例えば液晶ディスプレイなどを用いた画面表示によるものでもよいし、提案する献立の内容を記述したデータとして出力するものでもよい。画面表示デバイスについては、入力部１５０と共通化してもよい。

レシピデータベース１３１は、料理毎に料理名、材料、味、食感、色などの基本データを保持するデータベースである。詳細は後述の図２で説明する。

地域食材データベース１３２は、地域および月毎の旬の食材、特産品のリストを保持する。詳細は後述の図３で説明する。なお、地域固有の食材のリスト以外に、一般的な食材のリストを保持してもよい。以下では一般食材のリストについての説明は省略する。

ユーザデータベース１３３は、レシピデータベース１３１または地域食材データベース１３２をユーザ毎にカスタマイズするためのデータを格納するデータベースである。

本発明における「献立提案部」は、制御部１４０、出力部１６０が相当する。

地域特定部１１０、日付特定部１２０、制御部１４０は、これらの機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やマイコンなどの演算装置とその動作を規定するソフトウェアプログラムを用いて構成することもできる。後者のソフトウェアプログラムは、本発明における「献立決定支援プログラム」に相当する。

図２は、レシピデータベース１３１が保持するレシピデータの構成とデータ例を示す図である。レシピデータは、個々の料理の詳細情報を保持するデータである。以下、レシピデータが有する各情報欄について説明する。

（図２：「料理名」欄）
「料理名」欄は、当該レシピデータが記述している料理の料理名を保持する。料理名そのものに、献立を提案する際に用いることのできる情報が含まれている場合もある。制御部１４０は、例えば現在の季節が冬であれば、料理名に「冷」などの寒さを連想させる文字を含むものを、提案する献立の対象から除外することができる。どのようなキーワードを含む料理を除外するかをユーザデータベース１３３に格納し、ユーザ毎にカスタマイズすることもできる。

（図２：「料理材料」欄）
「料理材料」欄は、当該レシピデータが記述している料理を作るために用いられる食材リストを保持する。特に、地域の旬の食材や特産品を使用する献立を提案するときに、本欄が保持するデータを有効に活用することができる。

（図２：「種類」「ジャンル」欄）
「種類」「ジャンル」欄は、当該レシピデータが記述している料理の大まかな分類を表すデータを保持する。制御部１４０は、１品目として例えば「ご飯もの」が決定された場合、２品目以降は「ご飯もの」以外の料理を提案するようにする。同様に、１品目として例えば「和食」が決定された場合、２品目以降もなるべく「和食」料理を提案するようにすることができる。

（図２：「味」欄）
「味」欄は、当該レシピデータが記述している料理の大まかな味の種類を表すデータを保持する。制御部１４０は、例えば子供向けの献立を提案するよう指示されたときは、本欄が「甘」になっている料理を優先的に提案することができる。

（図２：「食感」欄）
「食感」欄は、当該レシピデータが記述している料理の食感を表すデータを保持する。制御部１４０は、例えば１品目として提案した料理の食感と異なる食感を有する料理を２品目以降に提案することにより、献立に多様性を持たせることができる。また、例えばお年寄り向けの献立を提案するよう指示されたときは、本欄が「硬い」になっている料理をなるべく除外するようにすることができる。

（図２：「色」欄）
「色」欄は、当該レシピデータが記述している料理の色を表すデータを保持する。制御部１４０は、複数の料理を提案する場合、本欄の値を用いて、彩りのよい組み合わせを提案することができる。本欄の値は、料理全体の色を表すものとしてもよいし、食材毎に色を保持してもよい。

（図２：「定番」欄）
「定番」欄は、当該レシピデータが記述している料理が定番料理であるか否かを表すデータを保持する。

（図２：「手間／所要時間」欄）
「手間／所要時間」欄は、当該レシピデータが記述している料理を作るために要する時間を表すデータを保持する。本欄の値は、提案された料理のなかからユーザが料理を選択する際の目安になる。例えばユーザが急いでいるときは、本欄の値が小さい料理が選択される場合が多いと考えられる。

（図２：「調理器具」欄）
「調理器具」欄は、当該レシピデータが記述している料理を作るときにユーザが使用する調理器具のリストを保持する。制御部１４０は、例えば暑い日には、コンロやフライパンなど暑さを感じやすい調理器具を使用する料理を提案しないようにするなど、料理を提案する際に本欄の値を参考情報として用いることができる。また、オーブンや炊飯器など調理を開始してしまえばその後は出来上がりまで何もしなくてよい調理器具を使用する料理を、フライパンなどのように常に付き添っていなければならない調理器具を使用する料理とセットにして提案する、といったこともできる。

（図２：「調理方法」欄）
「調理方法」欄は、当該レシピデータが記述している料理の調理方法を表すデータを保持する。制御部１４０は、献立の多様性の観点から、１品目に提案した料理の調理方法と２品目以降に提案する料理の調理方法を変えることが望ましい。

（図２：「出来上がり料理温度」欄）
「出来上がり料理温度」欄は、当該レシピデータが記述している料理を美味しく飲食できる温度を表すデータを保持する。人が、温かく、または、冷たく、美味しいと感じる温度は、一般的に体温との差が２５度以上であることや、保温機能のある弁当箱の保温温度が５０度前後〜６０度前後であるものが多いことから、例えば「温かい料理＝５５度以上」、「冷たい料理＝１２度以下」とする。常温については日本工業規格で定められている５度〜３５度を参考に、「常温料理＝１５〜３５度」とする。制御部１４０は、現在の季節が冬であれば、本欄の値が小さい料理を、提案する献立の対象から除外することができる。保持するデータは、例えば同じ汁物でも、味噌汁は６５度前後、甘みの強い汁粉などは多少低めの５０度程度のほうが美味しく感じられるという、温度の違いを考慮することが望ましい。

（図２：「出来上がりイメージ」欄）
「出来上がりイメージ」欄は、当該レシピデータが記述している料理が完成した時のイメージを示す画像データを保持する。制御部１４０は、「色」欄に代えて、または「色」欄と併せて本欄から料理の色合いを抽出し、彩りのよい料理の組み合わせを提案することができる。

（図２：「調理手順」欄）
「調理手順」欄は、当該レシピデータが記述している料理の詳細な調理手順を記述したデータを保持する。本欄は、ユーザが当該料理を実際に作ることができるか否かを判断するためなどの参考情報として用いることができる。また、料理を作る際に本欄を出力部１６０で画面表示させて参考にすることもできる。

図３は、地域食材データベース１３２が保持している地域食材テーブル１３２１の構成とデータ例を示す図である。地域食材テーブル１３２１は、各月の旬の食材および地域特産品の情報を、地域毎に保持している。制御部１４０は、地域食材テーブル１３２１を参照することにより、地域および月毎の旬の食材および地域特産品を把握できる。

制御部１４０は、必ずしも当月の旬の食材または特産品を選択する必要はなく、例えば当月の前後２ヶ月以内であれば旬の食材または特産品の範囲に含むものとして取り扱ってもよい。旬の食材または特産品をどの期間範囲内で選択するかについてのデータを例えばユーザデータベース１３３に格納しておき、カスタマイズできるようにしてもよい。

図４は、献立決定支援装置１００が献立を提案する過程を示す処理フローである。以下図４の各ステップについて説明する。

（図４：ステップＳ４０１）
地域特定部１１０と日付特定部１２０は、それぞれ献立決定支援装置１００が設置されている地域と現在日付を取得し、制御部１４０に出力する。

（図４：ステップＳ４０２）
制御部１４０は、地域特定部１１０と日付特定部１２０より取得した地域と日付を用いて地域食材データベース１３２を検索し、該当する地域の旬の食材と特産品のリスト（地域食材リスト）を取得する。

（図４：ステップＳ４０３）
制御部１４０は、ステップＳ４０２で取得した地域食材を使用する料理をレシピデータベース１３１から検索し、得られた料理を献立として提案する。このとき、ユーザデータベース１３３が保持しているユーザ毎のカスタマイズ情報を加味してもよい。以下のステップＳ４０７、Ｓ４１０でも同様である。提案する献立の内容は、出力部１６０を介してユーザに提示される。

（図４：ステップＳ４０４）
制御部１４０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１５０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０５へ進む。

（図４：ステップＳ４０５）
制御部１４０は、ステップＳ４０２で取得した地域食材に代えて、またはこれに追加して、地域食材データベース１３２または規定の食材リストより他の食材のリストを取得して入力部１５０に画面表示させ、ユーザに提案する。

（図４：ステップＳ４０６）
制御部１４０は、提案する食材のいずれかを選択するよう促すメッセージを入力部１５０に画面表示させる。ユーザはいずれかの食材を選択するか、もしくはいずれの食材も希望に合致しない旨を指示する。ユーザがいずれかの食材を選択した場合はステップＳ４０７へ進み、いずれも選択しなかった場合はステップＳ４０９へ進む。

（図４：ステップＳ４０７）
制御部１４０は、ステップＳ４０６でユーザが選択した食材を使用する料理をレシピデータベース１３１から検索し、得られた料理を献立として提案する。提案する献立の内容は、出力部１６０を介してユーザに提示される。

（図４：ステップＳ４０８）
制御部１４０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１５０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０９へ進む。

（図４：ステップＳ４０９）
制御部１４０は、献立を提案するための条件を入力するようユーザに促すメッセージを入力部１５０に画面表示させる。ユーザは、後述の図５で説明する手順にしたがって条件を入力し、制御部１４０はその条件指定を受け付ける。

（図４：ステップＳ４１０）
制御部１４０は、ステップＳ４１０で指定された条件を用いてレシピデータベース１３１と地域食材データベース１３２を検索し、得られた料理を献立として提案する。条件を満たす料理が見つからなかった場合は、「お勧めできる料理がありませんので条件を見直してください。」のようなメッセージを表示し、ステップＳ４０９に戻るようにしてもよい。また、条件を満たす料理がなくても、「条件にあう提案メニューがありませんでしたので、○○からのお勧めを探しました」等のメッセージを表示した後、代替案の料理候補を提案するようにしてもよい。

（図４：ステップＳ４１１）
制御部１４０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１５０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０９へ戻る。

（図４：ステップＳ４１２）
制御部１４０は、選択された料理の詳細レシピを出力部１６０に画面表示させる。制御部１４０は、その料理を確定してよいか否かを問い合わせるメッセージを入力部１５０に画面表示させる。ユーザはその料理を確定するか否かを指示する。確定しない場合は、ステップＳ４０９やＳ４１０などに戻るようにしてもよい。

図５は、図４のステップＳ４０９の詳細手順を示す処理フローである。以下、図５の各ステップについて説明する。

（図５：ステップＳ５０１）
制御部１４０は、入力部１５０に例えば「なにを使いたいですか？」などのメッセージを表示させる。ユーザは例えば、冷蔵庫にある食材や、帰宅途中に買う予定の食材など、使いたい食材を指定する。本ステップでは、複数の食材を選択できるようにしておくことが望ましい。

（図５：ステップＳ５０２）
制御部１４０は、入力部１５０に例えば「誰が食べますか？」などのメッセージを表示させる。ユーザは、料理を食べる人物の種別、例えば、小さい子供、中高生〜大人、お年寄り、などの人物種別を指定する。本ステップでは、複数の人物種別を指定できるようにしてもよい。

（図５：ステップＳ５０３）
制御部１４０は、入力部１５０に例えば「料理の種類は？」などのメッセージを表示させる。ユーザは例えば、献立の提案を受けたいご飯もの、めん類、おかず、汁物等や、主食、主菜、副菜、汁物等の料理種別を指定する。本ステップでは、複数の料理種別を指定できるようにしてもよい。

（図５：ステップＳ５０４）
制御部１４０は、入力部１５０に例えば「食べたいジャンルは？」などのメッセージを表示させる。ユーザは例えば、和食、洋食、中華、その他、おまかせ、などの料理ジャンルを指定する。本ステップでは、複数の料理ジャンルを指定できるようにしてもよい。

以上、献立決定支援装置１００が献立を提案する過程を説明した。なお、ユーザは図５の各条件を入力せずそれぞれ個別にスキップすることもできる。スキップされた条件については、制御部１４０は特に希望条件はないものとして取り扱う。例えば、食べたいジャンルがスキップされた場合は、和食でも洋食でも中華でも何でも提案可能と判断する。

以上のように、本実施の形態１に係る献立決定支援装置１００は、月毎の旬の食材および特産品を地域毎に保持する地域食材データベース１３２を備える。制御部１４０はこれを用いて、地域と日付に合わせた献立をレシピデータベース１３１から検索してユーザに提案することができる。

＜実施の形態２＞
実施の形態１では、レシピデータベース１３１と地域食材データベース１３２を用いて地域と日付に合わせた献立を提案する手法を説明した。本発明の実施の形態２では、料理の出来上がりイメージを用いて提案献立をより絞り込む手法を説明する。本実施の形態２に係る献立提案装置１００の構成は実施の形態１と概ね同様であるため、以下では差異点を中心に説明する。

図６は、本実施の形態２において、制御部１４０がレシピデータベース１３１の「出来上がりイメージ」欄の画像データを用いて献立を提案する基準を説明する図である。以下制御部１４０が実行する処理について説明する。なおここでは、ユーザが１品目の料理として「カレーライス」を選択済みであり、２品目として「サラダ」を提案するよう要求した場合を想定する。レシピデータベース１３１には、２種類のサラダ「サラダ１」「サラダ２」のレシピデータが格納されているものとする。

（ステップ１：ＲＧＢ値を抽出する）
制御部１４０は、図４のステップＳ４０３、Ｓ４０７、Ｓ４１０において、レシピデータベース１３１より料理の一覧を取得した後、「カレーライス」「サラダ１」「サラダ２」の「出来上がりイメージ」欄の画像データを取得する。制御部データ１４０は、取得した画像データのうち代表的な色のＲＧＢ値を取得する。代表的な色として、例えば画像データのうち最も多く使用されている色を用いることができる。例えば、図６のカレーライスの料理イメージ中で最も多く使用する色を（ｒ_０，ｇ_０，ｂ_０）、サラダ１の料理イメージ中で最も多く使用する色を（ｒ_１，ｇ_１，ｂ_１）、サラダ２の料理イメージ中で最も多く使用する色を（ｒ_２，ｇ_２，ｂ_２）、とすることができる。

（ステップ２：料理間のＲＧＢベクトル距離を算出する）
制御部１４０は、「カレーライス」のＲＧＢ値を基準として、「カレーライス」と「サラダ１」「サラダ２」のＲＧＢ値のベクトル距離を算出する。ここでいうＲＧＢ値のベクトル距離とは、ＲＧＢ値を座標値とする点を３次元座標上に配置したときに得られる各点間の距離のことである。

カレーライスの画像のＲＧＢ値が（ｒ_０，ｇ_０，ｂ_０）、サラダ１の画像のＲＧＢ値が（ｒ_１，ｇ_１，ｂ_１）、サラダ２の画像のＲＧＢ値が（ｒ_２，ｇ_２，ｂ_２）である場合、それぞれのベクトル距離は下記（式１）（式２）で算出することができる。

（ステップ３：ベクトル距離が最も離れている料理を提案する）
制御部１４０は、カレーライスのＲＧＢ値からのベクトル距離が長いほうのサラダを優先して提案する。優先して提案するとは、例えば優先する料理を先に提案する、優先する料理のみを提案する、などのように、ユーザに対する訴求度がより高い方法で提示することをいう。以下でも同様である。制御部１４０は、上記手法により、カレーライスの色彩と組み合わせると献立全体としての彩りがよくなるサラダを提案することができる。

図７は、制御部１４０がレシピデータベース１３１の「出来上がりイメージ」欄の画像データを用いて献立を１品のみ提案する基準を説明する図である。献立を１品のみ提案する場合には、図６で説明した場合とは異なり基準となる料理が存在しないため、１つの料理の画像データ内で色のＲＧＢベクトル値を算出することになる。具体的には、１つの料理の画像データ内で複数の点を設定し、各点間のＲＧＢベクトル距離を算出する。

図７に示す例では、制御部１４０は画像データ内の４つの点を任意に選択し、各点のＲＧＢ値を取得する。点１のＲＧＢ値が（ｒ_１，ｇ_１，ｂ_１）、点２のＲＧＢ値が（ｒ_２，ｇ_２，ｂ_２）、点３のＲＧＢ値が（ｒ_３，ｇ_３，ｂ_３）、点４のＲＧＢ値が（ｒ_４，ｇ_４，ｂ_４）であるとする。これらの点１〜４間のベクトル距離の合計は、（点１−点２間）＋（点１−点３間）＋（点１−点４間）＋（点２−点３間）＋（点２−点４間）＋（点３−点４間）であり、下記（式３）で表すことができる。

上記（式３）で１／６を乗算しているのは、値を正規化するためである。上記（式３）で算出できる値が大きいほど、色のバリエーションに富む料理であるといえる。制御部１４０は、提案する献立の候補が複数存在するとき、この値が大きいものを優先することにより、彩りのよい献立を提案することができる。

また、図６で示した例において、各料理のＲＧＢベクトル距離を複数点について比較したい場合には、制御部１４０は、各点の全ての組み合わせについてＲＧＢベクトル距離を求め、その平均を求める。これにより、図６〜図７と同様の処理を行うことができる。例えば、カレーライスの画像のＲＧＢ値が（ｒ_０１，ｇ_０１，ｂ_０１）と（ｒ_０２，ｇ_０２，ｂ_０２）で、サラダ１の画像のＲＧＢ値が（ｒ_１１，ｇ_１１，ｂ_１１）と（ｒ_１２，ｇ_１２，ｂ_１２）で、サラダ２の画像のＲＧＢ値が（ｒ_２１，ｇ_２１，ｂ_２１）と（ｒ_２２，ｇ_２２，ｂ_２２）であるとすると、カレーライスとこれらのサラダとの距離は以下の式で求められる。

制御部１４０は、カレーライスのＲＧＢ値からのベクトル距離が長いほうのサラダを提案する。上記（式４）（式５）で１／４を乗算しているのは、値を正規化するためである。一般的には、料理ＡのＲＧＢ値がｍ個で表わされ、料理ＢのＲＧＢ値がｎ個で表わされる場合は、各ＲＧＢ値の距離の和をｍ×ｎで割ればよいということになる。

図８は、料理の出来上がりイメージのうちＲＧＢ値を算出する際に用いる色または座標を指定したレシピデータの例を示す図である。料理の画像データのＲＧＢ値を抽出する際には、皿などの食器や背景などの部分を除外して料理の部分のみから抽出することが望ましい。そこで図８では、レシピデータ内に「サンプル色」欄を設けた。同欄には、料理の代表的な色のサンプル値、または出来上がりイメージの画像内で代表的な色を有する部分の座標値を保持する。制御部１４０は、本欄が保持する色または座標を用いて、料理の代表色を定めることができる。

制御部１４０は、例えば食器形状の周縁部分を検出して除外すべき部分を自動判別するようにしてもよいが、「サンプル色」欄を設ける手法の方が簡便で処理負荷も少ない点で便宜である。

以上のように、本実施の形態２によれば、レシピデータベース１３１は料理の色彩についての情報を「出来上がりイメージ」欄の画像データまたは「サンプル色」欄に保持しており、制御部１４０は、その色彩情報を用いて色のバリエーションが多くなる献立を提案する。これにより、視覚的イメージのよい献立提案を行うことができる。また色彩バリエーションが豊かな献立は、食材の種類が豊富で栄養面なども優れているものと想定され、視覚的観点のみならず健康的観点からも好ましい。

また、本実施の形態２によれば、制御部１４０は料理のＲＧＢ値のベクトル距離が離れているほど色彩バリエーションが豊富であるものと取り扱う。これにより、料理の色彩の豊富さを、演算処理の上で取り扱い易い定量的な手法で算出することができ、処理負荷などの観点から好都合である。

＜実施の形態３＞
本発明の実施の形態３では、ユーザの好みを献立提案に反映する構成と動作例を説明する。本実施の形態３に係る献立決定支援装置１００の構成は実施の形態１〜２と概ね同様であるため、以下では差異点を中心に説明する。

図９は、ユーザデータベース１３３が格納する選択履歴情報１３３１の構成とデータ例を示す図である。制御部１４０は、図４で説明した処理フローにおいてユーザより献立または食材の選択を受け付けると、その選択内容を選択履歴情報１３３１に格納する。これにより、ユーザが過去に選択した料理名、材料名、料理の種類やジャンルなどの履歴がユーザデータベース１３３に蓄積されることになる。

制御部１４０は、食材や献立を提案するとき、ユーザが過去に選択した回数が多いものを優先して提案する。具体的には、例えば図４のステップＳ４０３、Ｓ４０５、Ｓ４０７、Ｓ４１０などにおいて食材や献立を提案する際に、過去に選択された回数の多いものを先に提案するようにする。これにより、提案する食材や献立にユーザの嗜好を反映させることができる。

＜実施の形態４＞
本発明の実施の形態４では、食材が偏らないように工夫して献立を提案する構成と動作例を説明する。本実施の形態４に係る献立決定支援装置１００の構成は実施の形態１〜３と概ね同様であるため、以下では差異点を中心に説明する。

図１０は、出力部１６０の画面表示イメージを示す図である。ここでは出力部１６０が画面表示デバイスを備え、画面表示によってユーザに献立を提案することを想定する。制御部１４０は、複数の料理を組み合わせた献立を提案するとき、献立内の各料理が使用する食材の偏りについて配慮する。以下に具体例を挙げる。

（例１：ユーザが指定した食材（以下、「指定食材」という）の場合）
指定食材を使用した料理だけを提案する。指定食材が複数の場合は、指定食材を使用する料理を同程度ずつ提案してもよい（人参料理2品、大根料理2品など）。また、指定食材が非常に多い場合は、指定食材を全て使用する料理から優先し、少なくとも１つ以上の指定食材を使用した料理を提案するようにする。

（例２：ユーザが指定していない食材（以下、「指定外食材」という）の場合）
提案数が少ない場合は、指定外食材が重複しないように料理を提案するが、多い場合は、指定外食材を使用する料理を、各２０％程度までに抑えて提案するようにしてもよい。

肉類や魚など、料理の味等の特性を決めるのに重要な鍵となる食材（以下、「主要食材」という）についても、基本的には上記例１、例２と同様に考えてよいが、１品目が決まり、2品目以降を提案するときは、できるだけ主要食材が重複しないように料理を選定することが好ましい。同じ主要食材を持つ料理を一度に食べるのを好まないユーザが多いと考えられるからである。

主要食材を含む食材名を料理名と併せて画面表示すれば、ユーザが料理名と食材名を参考にしながら最終選択をすることができるので便宜である。図１０の例では、料理１と料理２は主要食材Ａ、料理３と料理５は主要食材Ｂ、料理４は主要食材Ｃを用いることが分かる。

いずれの食材が主要食材であるかについては、例えばレシピデータの「料理材料」欄が保持する各食材のうち主要食材であるものに、その食材が主要食材である旨の属性を付与しておくことにより把握できる。図２に示した例では、食材「むき栗」に「メイン」属性がついているので、制御部１４０は「むき栗」が主要食材であることが分かる。

その他、レシピデータの「料理名」欄の値から主要食材を判断することもできる。例えば料理名に「鶏肉の○○」、「○○豆腐」などのように食材名が含まれていれば、その食材が主要食材であると判断することもできる。食材名が複数含まれていればそれぞれを主要食材とする。

「肉の○○」「魚の○○」などのように大まかな食材名のみが料理名に含まれる場合には、具体的な食材を料理名のみから特定することができない。この場合は、全食材の中から肉や魚に属するものを適宜選び、当該料理における主要食材として取り扱うこともできる。

図１１は、本実施の形態４において地域食材データベース１３２が保持する食材種類情報１３２２の構成とデータ例を示す図である。食材種類情報１３２２は、食材がどの種類に属するかを記述した情報である。

食材種類情報１３２２は、各食材の「材料」、「種類」、「旬」、「主要食材可否」についての情報を保持する。図１１に示す例では、食材「秋刀魚」は種類「魚」に属することが記載されている。

項目「旬」は、当該食材がよくとれおいしい時期を示す。この項目は、制御部１４０が季節にあった料理を提案するときの判断材料とすることができる。

項目「主要食材可否」は、その食材が主要食材になり得る（○）か、そうでない（×）かを示すものである。

図１２は、ユーザが同じ食材を連続して希望した場合の献立提案例を示す図である。ここでは２日間連続した例を示した。短期間に同じ献立を提案するとユーザにとって新鮮味に欠けるため、このような場合は同じ食材を使用する異なる献立を提案することが望ましい。

図１２では、１日目は主要食材Ａ〜Ｃを使用する料理１〜５を提案し、２日目は同じ主要食材Ａ〜Ｃを使用する料理１１〜１５を提案する例を示した。具体的には、1日目に料理１を選択したので、2日目は、料理１の優先度を下げて提案することを表している。
これにより、ユーザが短期間の間に同じ食材を希望した場合でも、ユーザを飽きさせない献立提案を行うことができる。

図１２のような献立提案を行うためには、例えばユーザデータベース１３３に直近１週間程度の献立履歴を格納しておき、次回提案時には献立履歴に含まれる料理を提案しないかまたは優先度を下げて提案する、といった手法が考えられる。

以上のように、本実施の形態４によれば、制御部１４０は、複数の料理を含む献立を提案する際に、同一の食材が献立内に含まれる割合について、指定食材の場合は、提案する全ての献立に含まれてよいので１００％とし、指定外食材の場合は２０％程度に抑える。ただし、指定外食材については、提案する献立の数が少なくなるほど、同一の食材が献立内に含まれる割合を少なくすることが望ましい。これにより、ユーザは常に新鮮な献立提案を受けることができる。食材のバリエーションが豊富になることにより、栄養面も良好になると考えられるので、健康の観点からも好ましい。

また、本実施の形態４において、制御部１４０は、同一の食材を使用する献立を短期間内に提案するときは、同じ料理をなるべく提案しないように、例えば直近（例：１週間程度）に提案した料理の優先度を下げるなどして献立を提案する。これにより、同一の食材を使用する場合でも新鮮味のある献立を提案することができる。

さらに、図１０または図１２の献立提案画面において、急いでいるユーザの便宜のため、調理時間の短い料理の横に「時短」などのマークを画面表示し、ユーザが調理時間の短い献立を選び易くするようにしてもよい。

なお、図１０および図１２の献立提案画面において、表示される「メニュー」は「献立料理」を示す。

＜実施の形態５＞
実施の形態４では、食材がなるべく重ならないように献立を提案することを説明した。同様の観点から、制御部１４０は、調理方法がなるべく重複しないように献立料理を提案することもできる。同じ調理方法を用いる料理は味も似ているかもしくは同種の味になる可能性があり、献立のバリエーションの観点から好ましくないからである。

ただし提案数が多い場合は、例えば、おかずは一般的に「煮る」調理方法を用いる料理が多いため、他の調理方法より多く提案するなど、料理の種類により重複の程度を変えるようにしてもよい。

本実施の形態５に係る献立決定支援装置１００の構成は、実施の形態４と同様である。

＜実施の形態６＞
以上の実施の形態１〜５において、図５の処理フローでユーザが入力するその他の条件として、例えば「ＮＧ食材」、「ＮＧ調理法」なども考えられる。

「ＮＧ食材」とは、ユーザが好まない食材があれば登録しておいてもらうものである。ＮＧ食材がある場合、制御部１４０は、当該ユーザへ献立を提案するときは、ＮＧ食材が含まれるものを必ず除外するようにする。

「ＮＧ調理法」とは、ユーザが好まない調理法があれば登録しておいてもらうものである。ＮＧ調理法がある場合、制御部１４０は、当該ユーザへ献立を提案するときは、ＮＧ調理法を用いる料理を必ず除外するようにする。

これらの条件については、あらかじめユーザデータベース１３３に同様の情報を格納しておき、制御部１４０がこれを読み出して献立提案時に用いるようにしてもよい。同様に、ユーザが積極的に使いたい食材または献立料理をユーザデータベース１３３に格納しておき、制御部１４０がこれを読み出して献立提案時に用いるようにしてもよい。

上記の他、ユーザが定番料理を好むか否かの情報をユーザデータベース１３３に格納しておいてもよい。ユーザの定番料理に対する嗜好として、自分が作り慣れている定番料理を好んで選択する場合と、定番以外の料理を選択して自分のレパートリーを増やそうとする場合とがある。ユーザデータベース１３３に各ユーザの定番料理に関する嗜好を格納しておけば、制御部１４０はこれを読み出してユーザの嗜好に応じて提案する献立の傾向を調整することができる。

＜実施の形態７＞
制御部１４０が献立を１品のみ提案する際に考慮する条件として、例えば、以下のようなものが考えられる。条件の優先順に列挙する。
（条件１）旬の食材（カレンダー、ＧＰＳ機能から検知または任意入力）
（条件２）季節に合わない料理名のものを除外する
（条件３）希望の食材（任意入力）
（条件４）対象人物（任意入力）
（条件５）料理の種類（任意入力）
（条件６）料理ジャンル（任意入力）
（条件７）写真の彩りのよい献立
（条件８）ＮＧ食材
（条件９）定番料理の利用
制御部１４０が複数の料理を組み合わせた献立を提案する際、１品目の候補を提案する優先順の例を以下に示す。
（条件１）料理の種類（任意入力）
（条件２）旬の食材（カレンダー、ＧＰＳ機能から検知）
（条件３）季節に合わない献立名のものを除外する
（条件４）希望の食材（任意入力）
（条件５）ＮＧ食材
（条件６）ジャンル（任意入力）
（条件７）食べる対象（任意入力）
（条件８）写真の彩りのよい献立
（条件９）定番献立の利用
制御部１４０は、２品目以降の料理は例えば以下の優先順で提案する。
（条件１０）料理の種類
（条件１１）旬の食材
（条件１２）季節に合わない献立名のものを除外する
（条件１３）希望の食材
（条件１４）ＮＧ食材
（条件１５）最初の料理で決まった食材を除外
（条件１６）最初の料理で決まった食感を除外
（条件１７）最初の料理で決まった調理方法を除外
（条件１８）最初の料理との色の距離が大きくなる献立を選択

このように、優先順序を考慮した組み合わせで条件を設定すると、ユーザの嗜好にあった栄養価の高い献立を提案することが可能になる。なお、献立候補の提案画面に表示する候補数は、いくつであってもよく、条件を満たす順にあらかじめ決められた数を表示するようにしてもよい。献立候補の提案画面において、「お勧めは○○件です」のようなメッセージを表示し、献立候補の総数を示すようにしてもよい。出力部１６０上の表示方法（形態やサイズなど）により、ユーザが見やすい件数に違いが出てくることが考えられるからである。

＜実施の形態８＞
図１３は、レシピデータに含まれる各項目を表示するか否かを定義するデータ示す図である。レシピデータの各項目は、出力部１６０で提案結果を表示するか否かをユーザの好みによりカスタマイズできるようにしておくことが望ましい。例えば、人によって「辛いか」、「所要時間はどのくらいか」などを表示画面に表示していた方が便利と感じる人もいるからである。

制御部１４０は、出力部１６０にレシピデータの内容を画面表示するよう指示する際、図１３に示すデータを読み込み、表示項目を調節する。図１３のデータは、例えばユーザ毎のカスタマイズ情報として、ユーザデータベース１３３などに格納しておくとよい。

＜実施の形態９＞
以上の実施の形態１〜８において、入力部１５０は、特定の機能を操作するための専用の操作キーを備えてもよい。操作キーは例えば以下のようなものを含む。

（操作キー例その１：「検索」キー）
「検索」キーは、ユーザが献立の提案をするよう献立決定支援装置１００に指示するときに操作するキーである。ユーザが条件を入力した後に「検索」キーを操作すると、それらの条件が制御部１４０に出力される。

（操作キー例その２：「戻り」キー）
「戻り」キーは、現在の表示画面から前回の表示画面に戻る操作を行うキーである。

（操作キー例その３：「最初へ」キー）
「最初へ」キーは、現在の食材や献立の選択・提案をすべてキャンセルし、初期画面に戻る操作を行うキーである。初期画面に戻る前に「すべての条件入力がクリアされますがよろしいですか？」のような注意を促す表示を行うようにしてもよい。以下のような動作例が考えられる。

（操作キー例その３：「最初へ」キー：動作例その１）
献立決定支援装置１００の電源を入れると、ステップＳ４０１〜Ｓ４０３を実行する。以降いずれかの画面で「最初へ」キーを押すと、初期画面が表示される。初期画面には、メッセージ「何を提案しましょうか？それとも条件入力しますか？」と表示され、ユーザが“献立提案”を選択すると図４のステップＳ４０１を開始し、“食材提案”を選択するとステップＳ４０５を開始する。また、“条件入力”を選択した場合は、ステップＳ４０９を開始する。

（操作キー例その３：「最初へ」キー：動作例その２）
献立決定支援装置１００の電源を入れた直後に献立の提案をするのではなく、「何を提案しましょうか？それとも条件入力しますか？」というメッセージを表示するようにする。以降は動作例その１と同じ動作とする。

（操作キー例その４：「詳細」キー）
「詳細」キーは、料理の詳細を表示する操作を行うキーである。献立候補の提案画面において、ユーザが詳しい内容を見たい料理を選択して操作すると、レシピカードの内容が表示される。

（操作キー例その５：「キープ」キー）
「キープ」キーは、提案されている献立候補の中で好みの料理にマークする操作を行うキーである。他の料理も見た上で、キープマークのついている料理だけを表示させ、その中から最終的に選択する献立を決定することができる。

（操作キー例その６：「また今度」キー）
「また今度」キーは、提案された献立候補の中で好みだったが、例えば、食材が入手できずに作れない、時間が掛かりすぎるので今日は作れない、などの料理にマークする操作を行うキーである。このようなマークが付いた料理は、次回以降の献立提案の際に、他の条件に合えば、優先的に表示順を上位にもってくるようにしてもよい。「また今度」キーによりマークされた料理は、「お気に入り料理」としユーザデータベース１３３に格納される。たとえば、献立候補として、「お気に入り料理」だけを表示させるようしてもよい。

（操作キー例その７：「これに決めた」キー）
「これに決めた」キーは、現在提案されている献立候補の中から最終的に選択した献立を決定する操作を行うキーである。

（操作キー例その８：「やめる」キー）
「やめる」キーは、現在提案されている献立候補の中に気に入ったものがない場合、提案を受けるのを止める操作を行うキーである。

（操作キー例その９：「料理の追加」キー）
「料理の追加」キーは、最初に入力した料理数の条件に対して、「もう一品」追加する操作を行うキーである。

（操作キー例その１０：「食材の追加」キー）
「食材の追加」キーは、現在提案されている献立候補の中に、気に入ったものがない場合に、他の食材を追加する操作を行なうキーである。また、気に入った献立はあったが、さらに他の食材を追加したい場合の操作を行う場合にも用いることができる。

＜実施の形態１０＞
本発明の実施の形態１０では、地域の特定について説明する。献立決定支援装置１００の構成は、実施の形態１〜９と同様である。

図１４は、旬の時期が同じ、または旬の時期が近い単位で地域をグループ分けした例を示す図である。制御部１４０は、図１４の表を入力部１５０に画面表示させ、ユーザは自分が住んでいる地域を同表の中から選択する。地域特定部１１０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

図１５は、図１４と同じ内容のデータを日本地図上に示した図である。制御部１４０は、図１５を入力部１５０に画面表示させ、地図上でユーザにいずれかの地域を選択させるようにしてもよい。この他、地図上から都道府県単位で選択できるようにしてもよい。地域特定部１１０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

図１６〜図１８は、ユーザが地域を指定するその他の手法を示す図である。制御部１４０は、各図が示す入力画面を入力部１５０に画面表示させ、ユーザにいずれかの地域を選択させる。地域特定部１１０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。以下、各図について説明する。

図１６は、プルダウンメニューから宮城県を選択した例を示す図である。

図１７は、郵便番号から地域情報を取得する場合の入力および表示例である。郵便番号を３桁以上入力することで、地域を検索することが可能になる。ここでは郵便番号「９８０」と入力した例を示す。この時点で、地域が「宮城県仙台市内」であることが分かる。郵便番号と地域の対応関係については、あらかじめ対応関係データを地域特定部１１０が保持しておくなどして把握すればよい。

図１８は、電話番号から地域情報を取得する場合の入力および表示例である。電話番号として市外局番を２桁以上入力することで、地域を検索することが可能になる。ここでは市外局番「０２」と入力した例を示した。市外局番「０２」から始まる地域は、「宮城県」、「山形県」、「福島県」、「新潟県」、「長野県」、「群馬県」、「栃木県」、「茨城県」の８つである。入力桁数が少ない場合、この例のように複数の地域が対象となることがあるため、それら複数の地域の中から、献立を提案してほしい地域を選択できるようにしてもよい。

図１９は、似た気候の地域をグループ分けした例を示す図である。これは、地域の分け方を都道府県単位にこだわらず、より柔軟に分けたものである。制御部１４０は、図１９のようにグループ分けした表を入力部１５０に画面表示させ、ユーザに選択させる。地域特定部１１０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

地域の分け方と、地域食材データベース１３２が格納している食材リストの地域区分とが一致していると処理の上で都合がよいが、必ずしも一致していなくともよい。

図２０は、図１９に示した地域のグループ分けを日本地図上に示した図である。制御部１４０は、図１９の表に代えて図２０の地図を入力部１５０に画面表示させ、地図上でユーザに地域を選択させるようにしてもよい。

以上、本実施の形態１０では、地域の特定について説明した。

＜実施の形態１１＞
本発明の実施の形態１１では、日付の特定について説明する。献立決定支援装置１００の構成は、実施の形態１〜１０と同様である。

図２１は、日時設定画面の１例を示す図である。制御部１４０は、入力部１５０に図２１のような日時設定画面を表示させ、ユーザに現在日時を入力させる。ここでは「２００９年１０月１５日１５時３０分」を入力した例を示した。日付特定部１２０はその入力を受け取ると、内部時刻をその日時に設定する。時刻は１２時間制および２４時間制のどちらでも設定可能にしておくことが望ましい。現在、社会一般ではどちらも使われているからである。

日付特定部１２０は、現在日時を設定した後は、内部のタイマなどにより自動的に日時を進め、以後はいつでも現在日付を特定することができる。制御部１４０は、その日付に対応する旬の地域食材や特産品を用いる献立を提案する。

図２２〜図２４は、日付を自動的に特定することに代えて、献立を提案してもらいたい日付をユーザが指定する際に用いる画面例を示す。制御部１４０は、入力部１５０に各図が示すいずれかの画面を表示させる。ユーザはその画面上で日付を入力する。日付特定部１２０は、その入力に基づき献立を提案すべき日付を特定する。以下、各図について説明する。

図２２は、カレンダー上で日付を指定する画面例である。

図２３は、月日入力欄に月日を数値入力する画面例である。

図２４は、プルダウンメニューで月日を選択する画面例である。

以上、本実施の形態１１では、日付の特定について説明した。

＜実施の形態１２＞
図２５は、本発明の実施の形態１２に係る献立決定支援装置１００の構成図である。本実施の形態１２における献立決定支援装置１００は、実施の形態１〜１１と同様の構成を有するが、各機能部が物理的に複数の装置に分割して構成されている点が異なるため、ここでは献立決定支援システムという。以下、各装置について説明する。

端末装置２００（クライアント端末）は、地域特定部１１０、日付特定部１２０、入力部１５０、出力部１６０を備える。端末装置２００は、ユーザが手にとって所望の献立を探すためのものであり、携帯型の装置として構成されていることが望ましい。

サーバ３００は、記憶部１３０、制御部１４０を備える。サーバ３００は、端末装置２００から献立を提案するようリクエストを受け、上述の実施の形態で説明した献立提案動作を実行して端末装置２００に提案内容を提示する。サーバ３００は、端末装置２００が送信するリクエストや検索条件の指定を受け付ける検索条件入力部（図示せず）を備える。サーバ３００は、異なるユーザが使用する複数の端末装置２００からのリクエストに応じられるような構成としてもよい。

表示装置４００は、第２出力部４１０を備える。第２出力部４１０は、好適には、端末装置２００が備える出力部１６０よりも大きな画面表示部を有する。ユーザは端末装置２００の出力部１６０で献立を見ることもできるし、例えば調理を開始するときはより大画面の第２出力部４１０でレシピデータを見ながら調理をする、といった使い分けをすることもできる。

端末装置２００、サーバ３００、表示装置４００は、ネットワーク５００によって接続されており、互いにデータを送受信することができる。好適には、ネットワーク５００は無線ネットワークであり、各装置が無線通信によって相互に通信できることが好ましい。

各装置を無線接続すれば、端末装置２００を携帯端末装置（電子手帳、携帯電話、携帯ゲーム機、電子手帳なども含まれる）によって構成することができる。これによりユーザは、場所を選ばずに献立を検討することができ、また、献立を決めた後に、買い物の際に持参することができる。

＜実施の形態１３＞
以上の実施の形態１〜１２で説明した献立決定支援装置１００（以下、「献立決定支援システム」を含む）は、他の電子機器に組み込んでその電子機器に献立提案機能を付加するように構成してもよい。例えば以下のような電子機器に組み込む例が考えられる。

（組み込み例その１：電子レンジ）
電子レンジに献立決定支援装置１００を組み込み、ユーザが電子レンジを用いた料理を作り易くすることができる。この場合、調理器具として電子レンジを用いる料理を優先的に提案するようにしてもよい。

（組み込み例その２：冷蔵庫）
冷蔵庫に献立決定支援装置１００を組み込む場合、冷蔵庫のもつ庫内の在庫管理機能と献立決定支援装置１００が連動し、在庫する食材およびその食材を用いる料理を優先的に提案するようにしてもよい。

（組み込み例その３：携帯電話、電子手帳）
携帯電話または電子手帳に献立決定支援装置１００を組み込む場合、献立を決めた後、買い物する食材がある場合の買い物メモを記憶・表示できる機能を搭載してもよい。

＜実施の形態１４＞
以上の実施の形態１〜１３で説明した献立決定支援装置１００の機能は、ＣＰＵなどの演算装置が実行するプログラムとして実装することができる。例えば、地域特定部１１０、日付特定部１２０、制御部１４０の機能を本発明に係る献立決定支援プログラムとして実装し、演算装置に実行させることにより、献立決定支援装置１００の機能を実現することができる。

また、前記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能を献立決定支援装置１００にすでに記録されているＯＳ（Ｏｐｅｒａｉｎｇ Ｓｙｓｔｅｍ）などのプログラムとの組み合わせで実現してもよい。

上記プログラムをコンピュータ読み取り可能な記憶媒体に記録して、この記憶媒体に記録されたプログラムをＣＰＵに読み込ませ、実行することにより、献立決定支援装置１００の各機能部の処理を実現してもよい。

上記プログラムを格納した「記憶媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ＤＶＤ、ブルーレイディスク等のコンピュータ読み取り可能な可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置などのことをいう。さらには、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。

１００：献立決定支援装置、１１０：地域特定部、１２０：日付特定部、１３０：記憶部、１３１：レシピデータベース、１３２：地域食材データベース、１３２１：地域食材テーブル、１３２２：食材種類情報、１３３：ユーザデータベース、１３３１：選択履歴情報、１４０：制御部、１５０：入力部、１６０：出力部、２００：端末装置、３００：サーバ、４００：表示装置、４１０：第２出力部、５００：ネットワーク。

Claims (16)

1. 献立を決定することを支援する装置であって、
   地域を特定する地域特定部と、
   日付を特定する日付特定部と、
   料理とその料理に用いられる食材の情報を格納する記憶部と、
   前記記憶部が格納している情報を用いて献立を提案する献立提案部と、
   を備え、
   前記記憶部は、
   前記食材の情報として、地域および時期毎の旬の食材またはその地域の特産品の少なくともいずれかを特定する情報を格納しており、
   前記献立提案部は、
   前記地域特定部が特定した地域および前記日付特定部が特定した日付に対応する食材を用いた献立の情報を前記記憶部から検索し、提案献立として出力する
   ことを特徴とする献立決定支援装置。
2. 前記記憶部は、前記料理の情報として、当該料理の色彩の情報を格納しており、
   前記献立提案部は、より多くの色彩が生じる料理を優先して提案する
   ことを特徴とする請求項１記載の献立決定支援装置。
3. 前記記憶部は、前記料理の色彩の情報として、当該料理の画像データを格納しており、
   前記献立提案部は、
   前記画像データの１以上の点のＲＧＢ値を取得し、
   そのＲＧＢ値を座標値とする点を３次元座標に配置して得られる各点間の距離がより離れている画像データほどより多くの色彩が生じるものとして取り扱う
   ことを特徴とする請求項２記載の献立決定支援装置。
4. 前記献立提案部が提案した料理または食材のうちいずれを選択するかの指定を受け取る入力部を備え、
   前記記憶部は、前記入力部が受け取った選択の履歴を蓄積し、
   前記献立提案部は、前記記憶部に格納されている履歴が多い料理または食材を優先して提案する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載の献立決定支援装置。
5. 前記献立提案部は、複数の料理を含む献立を提案する際に、同じ食材を用いる料理の割合を所定閾値以下とする
   ことを特徴とする請求項１から請求項４のいずれか１項に記載の献立決定支援装置。
6. 前記記憶部は、
   前記料理の情報として、その料理に用いられる主要食材の情報を格納しており、
   前記献立提案部は、
   複数の料理を含む献立を提案する際に、同じ主要食材を用いる料理の割合を所定閾値以下とする
   ことを特徴とする請求項５記載の献立決定支援装置。
7. 前記記憶部は、前記料理の情報として、当該料理の調理方法の情報を格納しており、
   前記献立提案部は、複数の料理を含む献立を提案する際に、同じ調理方法を用いる料理の割合が所定閾値以下となるように献立を提案する
   ことを特徴とする請求項１から請求項６のいずれか１項に記載の献立決定支援装置。
8. 前記記憶部は、
   前記献立提案部が料理の情報を前記記憶部から検索する際の条件として、ユーザが使いたい食材またはユーザが使いたくない食材の少なくともいずれか一方の情報を格納しており、
   前記献立提案部は、
   前記記憶部が格納している前記条件に基づき、ユーザが使いたい食材を用いる料理を優先して提案し、またはユーザが使いたくない食材を用いる料理を提案しないようにする
   ことを特徴とする請求項１から請求項７のいずれか１項に記載の献立決定支援装置。
9. 前記記憶部は、
   前記料理の情報として、当該料理が定番料理であるか否かの情報を格納するとともに、前記献立提案部が料理の情報を前記記憶部から検索する際の条件として、ユーザが定番料理を所望するか否かの情報を格納しており、
   前記献立提案部は、
   ユーザが定番料理を所望する旨の情報を前記記憶部が格納している場合は、定番料理を優先して提案する
   ことを特徴とする請求項１から請求項８のいずれか１項に記載の献立決定支援装置。
10. 前記地域特定部、前記日付特定部、前記記憶部、前記献立提案部のうち少なくともいずれかは、通信回線を介して当該献立決定支援装置に接続されている
    ことを特徴とする請求項１から請求項９のいずれか１項に記載の献立決定支援装置。
11. 前記献立提案部が料理の情報を前記記憶部から検索する際の条件指定を受け取る検索条件入力部を備えた
    ことを特徴とする請求項１から請求項１０のいずれか１項に記載の献立決定支援装置。
12. 請求項１１記載の献立決定支援装置と、
    前記献立決定支援装置に対して献立を提案するよう要求するクライアント端末と、
    を有し、
    前記検索条件入力部は、
    通信回線を介して前記クライアント端末に接続されており、
    前記クライアント端末は、
    前記通信回線を介して前記献立決定支援装置に前記要求を送信しその応答を受信する
    ことを特徴とする献立決定支援システム。
13. 前記献立提案部が出力する提案献立を画面表示する表示装置を有する
    ことを特徴とする請求項１２記載の献立決定支援システム。
14. 料理とその料理に用いられる食材の情報を格納するデータベースを用いて献立を決定することを支援する方法であって、
    地域を特定する地域特定ステップと、
    日付を特定する日付特定ステップと、
    前記データベースが格納している情報を用いて提案献立として出力する献立提案ステップと、
    を有し、
    前記データベースは、前記食材の情報として、
    地域および時期毎の旬の食材またはその地域の特産品の少なくともいずれかを特定する情報を格納しており、
    前記献立提案ステップでは、
    前記地域特定ステップで特定した地域および前記日付特定ステップで特定した日付に対応する食材を用いた献立の情報を前記データベースから検索し、提案献立として出力する
    ことを特徴とする献立決定支援方法。
15. 請求項１４記載の献立決定支援方法をコンピュータに実行させることを特徴とする献立決定支援プログラム。
16. 請求項１５記載の献立決定支援プログラムを格納したことを特徴とする記憶媒体。

Images