JP2022091215A - 食材注文装置、食材注文方法、及びプログラム - Google Patents

Abstract

【課題】献立に含まれる各料理に必要な食材を注文できる食材注文装置を提供する。【解決手段】食材注文装置１は、調理予定の献立を識別する献立識別子と、その献立の数量とを受け付ける受付部１１と、献立識別子と、その献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける複数の献立情報と、料理識別子と、その料理識別子の料理を作るために用いられる食材を識別する食材識別子及び食材の使用量とを対応付ける複数のレシピ情報とが記憶される記憶部１２と、献立情報及びレシピ情報を用いて、受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する取得部１３と、取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する注文情報生成部１４と、注文情報を出力する出力部１５とを備える。【選択図】図１Ａ

Description

本発明は、献立に応じて調理に必要な食材を注文することができる食材注文装置等に関する。

従来、食材を注文する際には、食材や数量を手作業で指定して注文を行っていた。そのため、注文の処理に煩雑な作業が要求されることになるという問題があった。また、注文に間違いが生じた場合には、食材が不足して予定の料理を作れなくなったり、食材が余ることによって食品ロスが発生したりすることがあった。

このような食材の注文の煩雑さを解消するために、料理ごとに必要な食材の一覧をデータベース化し、そのデータベースを用いて選択した料理に必要な食材を注文できるシステムが開発されている（特許文献１参照）。

特開２００３－１８７１１５号公報

しかしながら、上記特許文献１のシステムでは、料理ごとの注文を行うことができるだけである。そのため、例えば、１つの献立（例えば、さば味噌煮定食など）に複数の料理が含まれる場合には、その料理ごとに注文を行う必要があり、そのための処理が煩雑になるという問題があった。

本発明は、上記課題を解決するためになされたものであり、献立単位で、調理に必要な食材を注文することができる食材注文装置等を提供することを目的とする。

上記目的を達成するため、本発明の一態様による食材注文装置は、調理予定の献立を識別する献立識別子と、献立の数量とを受け付ける受付部と、献立識別子と、献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、料理識別子の料理を作るために用いられる食材を識別する食材識別子及び食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部と、献立情報及びレシピ情報を用いて、受付部によって受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する取得部と、取得部によって取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する注文情報生成部と、注文情報を出力する出力部と、を備えたものである。
このような構成により、献立を識別する献立識別子、及び献立の数量を受け付けることによって、その数量の献立を作るために必要な食材を注文することができるようになる。したがって、食材ごとや料理ごとに注文を行う必要がなくなり、利便性が向上されることになる。

また、本発明の一態様による食材注文装置では、記憶部では、注文対象の選択に関するポリシーを示すポリシー情報も記憶されており、注文情報生成部は、取得部によって取得された食材識別子に対応する複数の注文対象が存在する場合に、ポリシー情報に応じて注文対象を選択してもよい。
このような構成により、注文対象に複数の選択肢がある場合に、ポリシーに応じた選択が行われるようになる。その結果、例えば、最も安い注文対象を選択する、国産の注文対象を選択するなどのポリシーに応じた注文対象の注文を自動的に実現することができるようになる。

また、本発明の一態様による食材注文装置では、記憶部では、食材の食材識別子と、食材の在庫量とを対応付ける在庫情報も複数記憶されており、注文情報生成部は、取得部によって取得された食材識別子に対応する在庫量及び食材の必要量に基づいて注文情報を生成してもよい。
このような構成により、在庫を考慮した食材の注文を行うことができ、不必要な食材の注文を回避することができ、食品ロスを低減することができる。

また、本発明の一態様による食材注文装置では、注文情報生成部は、取得部によって取得された食材識別子に対応する在庫量を、食材の必要量と注文情報によって注文した食材の注文量とを用いて更新してもよい。
このような構成により、注文に応じて理論的な在庫量を管理することができる。

また、本発明の一態様による食材注文装置では、食材の在庫量を示す在庫情報を受け付けて記憶部に蓄積する在庫受付部をさらに備えてもよい。
このような構成により、例えば、ＩＣタグ等を用いて取得された実際の在庫量を管理することができるようになる。

また、本発明の一態様による食材注文装置では、記憶部では、食材識別子と、食材識別子で識別される食材の注文量とを対応付ける注文量情報も記憶されており、注文情報生成部は、注文量情報によって注文量に対応付けられている食材識別子が取得部によって取得された際には、食材識別子に対応付けられている注文量となるように注文情報を生成してもよい。
このような構成により、例えば、食材注文装置による食材の注文とは別ルートで購入している食材については、注文量を０にすることができる。また、例えば、大量に保管することができる特定の食材については、保管場所に応じた注文量の単位で注文することができるようになり、頻繁な注文を回避することができるようになる。

また、本発明の一態様による食材注文装置では、注文情報には、注文に関する年月日及び注文対象ごとの金額が含まれており、注文情報生成部は、生成した注文情報を記憶部に蓄積し、記憶部で記憶されている注文情報に含まれる注文に関する年月日及び注文対象ごとの金額を用いて、単位期間に注文された注文対象の合計金額を算出する算出部をさらに備え、出力部は、算出部によって算出された合計金額をも出力してもよい。
このような構成により、例えば、単位期間ごとの食材コストを自動的に取得することができるようになる。

また、本発明の一態様による食材注文方法は、受付部、献立識別子と、献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、料理識別子の料理を作るために用いられる食材を識別する食材識別子及び食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部、取得部、注文情報生成部、及び出力部を用いて処理される食材注文方法であって、受付部が、調理予定の献立を識別する献立識別子と、献立の数量とを受け付けるステップと、取得部が、献立情報及びレシピ情報を用いて、受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得するステップと、注文情報生成部が、取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成するステップと、出力部が、注文情報を出力するステップと、を備えたものである。

本発明の一態様による食材注文装置等によれば、指定された数量の献立を作るために必要な食材を自動的に注文することができ、利便性が向上されることになる。

本発明の実施の形態による食材注文装置の構成を示すブロック図 同実施の形態による食材注文装置の構成の他の一例を示すブロック図 同実施の形態による食材注文装置の構成の他の一例を示すブロック図 同実施の形態による食材注文装置の動作を示すフローチャート 同実施の形態における献立情報の一例を示す図 同実施の形態におけるレシピ情報の一例を示す図 同実施の形態における食材情報の一例を示す図 同実施の形態における食材情報の他の一例を示す図 同実施の形態における取得された食材識別子、食材の必要量の一例を示す図 同実施の形態における注文情報の一例を示す図 同実施の形態における在庫情報の一例を示す図 同実施の形態における注文量情報の一例を示す図 同実施の形態におけるコンピュータシステムの外観一例を示す模式図 同実施の形態におけるコンピュータシステムの構成の一例を示す図

以下、本発明による食材注文装置、及び食材注文方法について、実施の形態を用いて説明する。なお、以下の実施の形態において、同じ符号を付した構成要素及びステップは同一または相当するものであり、再度の説明を省略することがある。本実施の形態による食材注文装置、及び食材注文方法は、指定された数量の献立の調理に必要な食材を自動的に注文することができるものである。

図１Ａは、本実施の形態による食材注文装置１の構成を示すブロック図である。本実施の形態による食材注文装置１は、受付部１１と、記憶部１２と、取得部１３と、注文情報生成部１４と、出力部１５とを備える。なお、本実施の形態では、食材注文装置１がスタンドアロンの装置である場合について主に説明し、それ以外の場合については後述する。スタンドアロンの食材注文装置１は、例えば、パーソナルコンピュータやタブレット端末、スマートフォンなどによって実現されてもよい。

受付部１１は、調理予定の献立を識別する献立識別子と、その献立の数量とを受け付ける。受付部１１は、例えば、献立に応じた調理を行うユーザによって指定された献立識別子及び数量を受け付けてもよい。献立とは、１以上の料理を含む料理のグループである。通常、献立は２以上の料理を含んでいる。料理は、通常、一品料理である。例えば、さば味噌煮定食である献立は、さば味噌煮、ライス、味噌汁、レンコンのキンピラ等の各料理を含んでいてもよい。献立識別子は、例えば、献立の名称であってもよく、献立を識別するための数字や記号等であってもよい。本実施の形態では、献立識別子が献立の名称である場合について主に説明する。他の識別子についても同様である。献立の数量は、調理予定の献立の個数である。例えば、献立の数量「Ｎ」が受け付けられた場合には、Ｎ人前の献立の調理に必要な食材が、食材注文装置１によって注文されることになる。なお、Ｎは１以上の整数である。献立識別子と数量とは、両者の対応付けが分かるように受け付けられることが好適である。例えば、献立識別子と数量との組が受け付けられてもよい。献立識別子の受け付けは、例えば、後述する献立情報によって料理識別子に対応付けられている献立識別子の一覧から、特定の献立識別子の選択を受け付けることによって行われてもよい。また、受付部１１は、受け付けた献立識別子の献立の調理を行う年月日を受け付けてもよい。

受付部１１は、例えば、入力デバイス（例えば、キーボードやマウス、タッチパネルなど）から入力された情報を受け付けてもよく、有線または無線の通信回線を介して送信された情報を受信してもよく、所定の記録媒体（例えば、磁気ディスクや半導体メモリなど）から読み出された情報を受け付けてもよい。なお、受付部１１は、受け付けを行うためのデバイス（例えば、モデムやネットワークカードなど）を含んでもよく、または含まなくてもよい。また、受付部１１は、ハードウェアによって実現されてもよく、または所定のデバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

記憶部１２では、複数の献立情報と、複数のレシピ情報とが記憶される。献立情報は、献立識別子と、その献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける情報である。献立情報によって、ある献立にどのような料理が含まれるのかが示されることになる。レシピ情報は、料理識別子と、その料理識別子の料理を作るために用いられる食材を識別する食材識別子及び食材の使用量とを対応付ける情報である。レシピ情報によって、ある料理を作るために使用される食材と、その食材の使用量とが示されることになる。レシピ情報によって料理識別子と対応付けられる食材識別子及び食材の使用量の組の個数は、例えば、１個であってもよく、または２個以上であってもよい。使用量は、例えば、重量や容量、個数などによって示されてもよい。なお、記憶部１２には、上記以外の情報も記憶されてもよい。例えば、注文情報の生成時に参照される、後述する食材情報や、注文を行う主体を識別する注文者識別子等が記憶部１２で記憶されていてもよい。

ここで、「Ａ１情報とＡ２情報とを対応付ける情報」とは、その情報を用いて、Ａ１情報とＡ２情報の一方から、他方を特定することができることを意味している。したがって、その情報は、Ａ１情報とＡ２情報とを組として含んでいてもよく、Ａ１情報とＡ２情報とをリンク付ける情報であってもよい。

記憶部１２に情報が記憶される過程は問わない。例えば、記録媒体を介して情報が記憶部１２で記憶されるようになってもよく、通信回線等を介して送信された情報が記憶部１２で記憶されるようになってもよく、または、入力デバイスを介して入力された情報が記憶部１２で記憶されるようになってもよい。献立情報やレシピ情報は、ユーザによって記憶部１２に蓄積されてもよい。このようにして、ユーザは、自分用の献立情報やレシピ情報を食材注文装置１に登録することができる。記憶部１２は、不揮発性の記録媒体によって実現されることが好適であるが、揮発性の記録媒体によって実現されてもよい。記録媒体は、例えば、半導体メモリや磁気ディスクなどであってもよい。

取得部１３は、記憶部１２で記憶されている献立情報及びレシピ情報を用いて、受付部１１によって受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する。献立識別子及び数量に応じた献立とは、その数量分の、献立識別子で識別される献立のことである。より具体的には、取得部１３は、受付部１１によって受け付けられた献立識別子に、献立情報によって対応付けられている１以上の料理識別子を特定することによって、献立に含まれる料理を特定することができる。また、取得部１３は、特定した各料理識別子に、レシピ情報によって対応付けられている食材識別子及び使用量を特定し、特定した使用量に、受付部１１によって受け付けられた数量を乗算し、食材識別子ごとに乗算結果の合計を算出することによって、食材識別子と食材の必要量との組を取得することができる。ここで、その乗算結果の合計値が、食材の必要量となる。また、合計値の算出が行われなかった食材識別子については、使用量に数量を乗算した結果が、食材の必要量となる。なお、取得部１３は、特定した食材識別子と使用量とについて、先に食材識別子ごとの使用量の合計を算出してから、その合計値に、受付部１１によって受け付けられた数量を乗算することによって食材の必要量を取得してもよい。このようにして、受付部１１で受け付けられた献立識別子の献立を、受付部１１で受け付けられた数量分だけ調理するために必要となる食材の食材識別子と食材の必要量との組が、献立の調理に必要な食材の種類分だけ取得されることになる。

注文情報生成部１４は、取得部１３によって取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する。食材の必要量と一致する量の注文を行うことができるのが理想的であるが、通常、注文することができる単位である注文単位は食材ごとに決まっている。例えば、牛乳は通常、１２３（ｍｌ）のような単位で注文することはできず、５００（ｍｌ）や１０００（ｍｌ）などの注文単位で注文することになる。したがって、注文情報生成部１４は、取得された食材識別子及び食材の必要量の複数の組に応じて、注文単位での注文となるように注文情報を生成する。通常、注文情報生成部１４は、取得部１３によって取得された食材識別子ごとに、必要量以上の注文量となるように、注文情報を生成する。注文情報生成部１４は、例えば、食材識別子と、その食材識別子の食材である注文対象を識別する識別子（以下、この識別子を「商品識別子」と呼ぶこともある。）と、その注文対象の注文単位と、その注文対象の金額とを対応付ける食材情報を用いて注文情報を生成してもよい。その食材情報は、例えば、記憶部１２で記憶されていてもよく、または、食材注文装置１の外部の装置（例えば、食材情報のデータベースを管理しているサーバ等の装置）で記憶されていてもよい。後者の場合には、注文情報生成部１４は、例えば、取得部１３によって取得された食材識別子を外部の装置に出力することによって、その食材識別子に対応する商品識別子や金額、注文単位等を受け取ってもよい。食材識別子の出力や、注文単位等の受け取りは、例えば、通信回線を介した送受信によって行われてもよい。本実施の形態では、食材識別子と、その食材識別子の食材である注文対象を識別する商品識別子と、その注文対象の注文単位と、その注文単位に応じた金額とを対応付ける複数の食材情報が記憶部１２で記憶されている場合について主に説明する。その食材情報は、通常、食材の販売者から提供される情報である。

注文情報生成部１４は、例えば、ある食材である注文対象の注文量を、その食材の必要量以上となり、注文単位の整数倍の量となるように決定し、その注文対象の商品識別子と、決定した注文量とを注文情報に追加する処理を、取得部１３によって取得された食材識別子で識別される食材ごとに繰り返すことによって、注文情報を生成してもよい。注文情報は、例えば、取得部１３によって取得された食材識別子の食材である注文対象の商品識別子と、その注文対象の注文量との組を複数含むと共に、注文に関する年月日（例えば、注文の年月日、注文に応じた納品の年月日、注文に応じた支払いの年月日等であってもよい。）、注文対象ごとの金額などを含んでいてもよい。また、注文情報は、注文者を識別する注文者識別子を含んでいてもよい。なお、注文量は、注文対象の個数によって示されてもよく、重量や容量によって示されてもよい。

出力部１５は、注文情報生成部１４によって生成された注文情報を出力する。この出力は、例えば、所定の機器への通信回線を介した送信でもよく、プリンタによる印刷でもよく、記録媒体への蓄積でもよく、他の構成要素への引き渡しでもよい。なお、注文情報の出力によって注文を行うという観点からは、この出力は、例えば、メーカーや卸、小売店、ウェブショップ等に注文情報を送信することであってもよい。また、紙による注文が行われる場合には、この出力は印刷であってもよい。出力部１５は、出力を行うデバイス（例えば、通信デバイスやプリンタなど）を含んでもよく、または含まなくてもよい。また、出力部１５は、ハードウェアによって実現されてもよく、または、それらのデバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

次に、食材注文装置１の動作、すなわち食材注文方法について図２のフローチャートを用いて説明する。
（ステップＳ１０１）受付部１１は、献立識別子及び献立の数量を受け付けたかどうか判断する。そして、献立識別子等を受け付けた場合にはステップＳ１０２に進み、そうでない場合には、献立識別子等を受け付けるまで、ステップＳ１０１の処理を繰り返す。

（ステップＳ１０２）取得部１３は、記憶部１２で記憶されている献立情報、及びレシピ情報を用いて、ステップＳ１０１で受け付けられた献立識別子及び数量に応じた献立を作るために必要な各食材の食材識別子及び食材の必要量をそれぞれ取得する。

（ステップＳ１０３）生成部１４は、ステップＳ１０２で取得された食材識別子及び食材の必要量の複数の組に基づいて注文情報を生成する。この注文情報の生成において、生成部１４は、例えば、記憶部１２で記憶されている食材情報によって示される、食材ごとの注文単位を用いてもよい。

（ステップＳ１０４）出力部１５は、ステップＳ１０３で生成された注文情報を出力する。そして、ステップＳ１０１に戻る。
なお、図２のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、本実施の形態による食材注文装置１の動作について、具体例を用いて説明する。この具体例では、図３Ａで示される献立情報、図３Ｂで示されるレシピ情報、図４Ａで示される食材情報が記憶部１２で記憶されているものとする。

図３Ａで示される献立情報は、献立識別子と、その献立識別子で識別される献立に含まれる料理の料理識別子とを有する情報である。例えば、献立識別子「さば味噌煮定食」と、料理識別子「ライス」「味噌汁」「さば味噌煮」「レンコンのキンピラ」等との組である献立情報によって、献立識別子「さば味噌煮定食」で識別される献立（以下、献立「さば味噌煮定食」と呼ぶこともある。他の識別子についても同様である。）に、料理「ライス」「味噌汁」「さば味噌煮」「レンコンのキンピラ」等が含まれることが示される。

図３Ｂで示されるレシピ情報は、料理識別子と、食材識別子及び食材の使用量とを有する情報である。例えば、料理識別子「さば味噌煮」に必要な食材及び使用量は、食材「さば切り身」が「１（個）」、食材「酒」が「１５（ｍｌ）」、食材「みりん」が「１５（ｍｌ）」等であることが示される。なお、図３Ｂのレシピ情報には、食材として「水」を含めていないが、水も食材に含めてもよい。この場合には、例えば、後述する注文量情報を用いることなどによって、水は注文されないようにしてもよく、または、水の使用量に応じてミネラルウォータなどが注文されてもよい。

図４Ａで示される食材情報は、食材識別子と、その食材識別子で識別される食材である注文対象を識別する商品識別子と、その注文対象の注文単位と、その注文対象の注文単位に応じた金額とを有する情報である。例えば、食材「米」である注文対象の商品は「ＡＡＡ米」であり、その注文単位は「３０（ｋｇ）」であり、３０（ｋｇ）の商品「ＡＡＡ米」の値段が「８５００（円）」であることが示される。この具体例では、１個の食材識別子に１個の商品識別子が対応付けられているものとする。すなわち、ある食材を購入する際に、商品を選択することはできないものとする。なお、１個の食材識別子に２個以上の商品識別子が対応付けられている場合、すなわち商品を選択することができる場合については、図４Ｂを用いて後述する。

なお、この具体例では、食材識別子と、商品識別子とが異なる場合について説明するが、そうでなくてもよい。食材識別子が商品識別子であってもよい。この場合には、レシピ情報によって、料理に使用する食材が、具体的な商品によって示されることになる。例えば、食材識別子を商品識別子とすることによって、フランチャイズ等の各店において献立に用いる食材を同じ商品にすることができ、すべての店について使用する食材を統一することができ、調理された献立の品質を一定に保つことができるようになる。

この具体例において、まず、食材注文装置１が、図３Ａの献立情報に含まれる献立識別子の一覧を作成し、ユーザに提示したとする。そして、ユーザが、その献立識別子の一覧において、献立識別子「さば味噌煮定食」を選択し、数量「１２」を入力したとする。すると、献立識別子「さば味噌煮定食」及び数量「１２」が受付部１１によって受け付けられ、取得部１３に渡される（ステップＳ１０１）。

献立識別子「さば味噌煮定食」及び数量「１２」を受け取ると、取得部１３は、献立識別子「さば味噌煮定食」を検索キーとして図３Ａの献立情報を検索し、ヒットした献立識別子「さば味噌煮定食」に対応付けられている料理識別子「ライス」「味噌汁」等をすべて特定する。また、取得部１３は、特定した料理識別子「ライス」を検索キーとして図３Ｂのレシピ情報を検索し、ヒットした料理識別子「ライス」に対応付けられている食材識別子「米」及び食材の使用量「７５（ｇ）」の組を取得する。取得部１３は、そのような処理を、特定した各料理識別子について行う。料理識別子「味噌汁」「さば味噌煮」のように、食材識別子と使用量との２以上の組が対応している場合には、取得部１３は、その２以上の組を取得する。このようにして、食材識別子と食材の使用量との複数の組が取得されることになる。

その後、取得部１３は、取得した各組に含まれる使用量に、受け取った数量「１２」を乗算すると共に、同じ食材識別子を含む複数の組を取得した場合には、その食材識別子に対応する乗算結果を合計し、その食材識別子に対応する必要量を、その合計値とする。このようにして、受け付けられた献立識別子及び数量に応じた献立の調理に必要な食材を識別する食材識別子及びその食材の必要量の組が、図５で示されるように食材ごとに取得される（ステップＳ１０２）。図５によって、１２人前の献立「さば味噌煮定食」を作るために、食材「米」の必要量が「９００（ｇ）」であり、食材「味噌」の必要量が「４３２（ｇ）」であることなどが示されている。取得部１３は、図５で示される取得結果を、注文情報生成部１４に渡す。

図５で示される取得結果を受け取ると、注文情報生成部１４は、各食材について、図４Ａの食材情報を用いて、必要量以上の注文単位に応じた注文量となるように、注文情報を生成する。具体的には、注文情報生成部１４は、図５で示される１番目の食材識別子「米」を検索キーとして図４Ａの食材情報を検索し、ヒットした食材情報に含まれる商品識別子「ＡＡＡ米」、注文単位「３０（ｋｇ）」、金額「８５００（円）」を取得する。そして、その注文単位は、食材「米」の必要量「９００（ｇ）」を超えているため、注文情報に、商品識別子「ＡＡＡ米」、注文量「１」、金額「８５００（円）」を追加する。なお、この具体例では、注文量は、商品の注文数であるとする。注文情報生成部１４は、２番目以降の食材識別子「味噌」「顆粒だし」等についても、同様に商品識別子等を取得して注文情報に追加する。また、食材識別子「さば切り身」については、注文単位が「１（個）」であり、必要量が「１２（個）」であるため、注文量は「１２」となる。このように、商品の注文数である注文量「Ｍ」は、注文単位×Ｍが必要量以上となる最も小さいＭに設定される。なお、Ｍは１以上の整数である。また、注文情報生成部１４は、記憶部１２においてあらかじめ記憶されている注文者識別子「Ｕ００１」と、図示しないカレンダー部から取得した年月日「２０２０／１１／１３」とを注文情報に追加する。その結果、図６で示される注文情報が生成されることになる（ステップＳ１０３）。図６の注文情報によって、例えば、商品「ＡＡＡ米」を１個注文し、その金額が「８５００（円）」であることなどが示されている。注文情報生成部１４は、生成した注文情報を出力部１５に渡す。

注文情報を受け取ると、出力部１５は、あらかじめ決められた送信先に、受け取った注文情報を送信する（ステップＳ１０４）。このようにして、指定された数量の献立を調理するために必要な食材に関する注文が自動的に行われることになる。なお、この具体例では、注文情報の送信処理までが自動的に行われる場合について説明したが、例えば、注文情報の生成、及び送信に応じて、各注文対象がショッピングサイトのカートに入れられ、ユーザが「注文」ボタンを選択することに応じて、その注文が確定されてもよい。

なお、献立識別子等を受け付ける際に、献立の調理を行う年月日も一緒に受け付けている場合には、注文情報に、献立の調理を行う年月日、または、献立の調理を行う年月日に応じて取得した商品（食材）の納品日（通常、この納品日は、調理を行う年月日よりも以前の日に設定される。）が含められてもよい。

以上のように、本実施の形態による食材注文装置１によれば、受け付けられた数量の献立を調理するのに必要な食材を自動的に注文することができ、食材ごとに、また料理ごとに注文を行う場合よりも、注文作業が軽減されることになり、注文者の利便性が向上する。また、その注文時に、食材の必要量を取得し、その必要量以上となるように注文単位での注文を行うことによって、献立の調理に必要な食材の必要量と、食材を購入できる単位とが異なる場合であっても、その違いを考慮した注文を行うことができる。この食材注文装置１を用いることによって、例えば、飲食店、弁当の製造工場、給食業者、入所者に食事を提供する高齢者施設等における食材の注文業務を著しく簡単にすることができる。また、食材注文装置１を各家庭で用いた場合にも、食材の購入を容易に行うことができるというメリットがある。また、このような食材注文装置１による注文が行われることによって、注文を受ける側の処理も軽減することができる。現在、食材の注文はＦＡＸを用いて行われることが多く、その場合には、注文を受ける側において注文内容を手作業でシステムに入力する必要があり大きな負担となっている。一方、食材注文装置１による注文に応じて注文情報を受信することによって、注文を受ける側において自動的に注文がまとまることになり、負担が大幅に軽減されることになる。

以下、本実施の形態による食材注文装置１の変形例について説明する。
［ポリシーに応じた注文対象の選択］
食材識別子に対応する複数の注文対象が存在する場合には、あらかじめ設定されたポリシーに応じてその選択が行われてもよい。この場合には、記憶部１２において、注文対象の選択に関するポリシーを示すポリシー情報も記憶されていてもよい。ポリシー情報によって、例えば、金額の最も低い注文対象を選択すること、単位量当たりの金額が最も低い注文対象を選択すること、無農薬の注文対象を選択すること、有機栽培の注文対象を選択すること、国産の注文対象を選択することなどのポリシーが示されてもよい。そして、注文情報生成部１４は、取得部１３によって取得された食材識別子に対応する複数の注文対象が存在する場合には、ポリシー情報に応じて注文対象を選択してもよい。なお、ポリシー情報に応じた注文対象の選択が行われる場合には、例えば、食材情報に、そのポリシー情報に応じた選択を行うための情報、例えば、各商品が国産かどうかを示す情報や、有機栽培かどうかを示す情報が含まれていてもよい。

例えば、図４Ｂで示されるように、食材識別子「米」を含む２個の食材情報が存在する場合であって、記憶部１２で記憶されているポリシー情報によって金額の最も低い注文対象を選択することが示されている場合には、注文情報生成部１４は、商品「ＡＡＡ米」を選択してもよい。一方、記憶部１２で記憶されているポリシー情報によって有機栽培の注文対象を選択することが示されている場合には、注文情報生成部１４は、商品「ＢＢＢ米（有機栽培）」を選択してもよい。なお、図４Ｂでは、商品識別子に、ポリシー情報に応じた選択を行うための情報が含まれていることになる。

なお、複数のユーザが食材注文装置１を利用する場合には、記憶部１２において、ユーザ識別子（例えば、注文者識別子など）に対応付けてポリシー情報が記憶されており、献立識別子等を入力したユーザを識別するユーザ識別子に対応するポリシー情報を用いて、注文対象の選択が行われてもよい。また、記憶部１２でポリシー情報が記憶されておらず、取得部１３によって取得された食材識別子に対応する複数の注文対象が存在する場合には、ユーザが注文対象を選択できてもよい。

［在庫を考慮した注文情報の生成］
通常、食材の必要量と注文量とは異なるため、上記具体例で説明したような注文を繰り返すと、注文量と必要量との差分が在庫となり、その在庫が増えていくことになる。したがって、在庫を考慮して注文情報を生成するようにしてもよい。この場合には、記憶部１２において、複数の在庫情報も記憶されていてもよい。在庫情報は、食材の食材識別子と、その食材の在庫量とを対応付ける情報である。そして、注文情報生成部１４は、取得部１３によって取得された食材識別子に対応する在庫量及び食材の必要量に基づいて注文情報を生成してもよい。なお、取得部１３によって取得された食材識別子に対応する食材の必要量とは、その食材識別子と一緒に取得された食材の必要量、すなわち、その食材識別子で識別される食材の必要量のことである。この場合には、ある食材の必要量が在庫量を超えているときに、その食材について、「必要量－在庫量」以上の注文単位での注文が行われ、その食材の必要量が在庫量以下であるときに、その食材についての注文は行われないことになる。

なお、在庫情報は、例えば、理論的に管理されてもよく、または、実際に測定された値が用いられてもよい。理論的に管理する場合には、注文情報生成部１４は、取得部１３によって取得された食材識別子に対応する在庫量を、食材の必要量と注文情報によって注文した食材の注文量とを用いて更新してもよい。例えば、ある食材について注文を行う場合には、その食材の注文量から必要量を減算した値が、その食材の在庫量に加算されることになる。また、例えば、ある食材について注文を行わない場合、すなわち、必要量が在庫量以下であった場合には、その食材の在庫量から必要量が減算されることになる。このようにして、在庫情報における各食材の在庫量が、注文情報生成部１４によって更新されてもよい。例えば、上記具体例において、注文情報の生成前には各食材の在庫量が０であった場合には、在庫情報における注文後の各食材の在庫量は、図７で示されるように、注文量から必要量を減算した値となる。例えば、食材「米」については、注文量が３０（ｋｇ）であり、必要量が９００（ｇ）であるため、在庫量は「２９１００（ｇ）」となる。この後に、献立識別子「さば味噌煮定食」、数量「１０」が受け付けられたとすると、食材「米」「味噌」などについては注文を行わなくてもよいことになる。その際には、在庫量から、それぞれ必要量が減算されることになる。また、受付部１１で受け付けられた献立の数量と、実際に調理した献立の数量が異なることもありうる。この場合には、その差に応じて在庫量を増減させてもよい。

一方、実際に測定された値に応じた在庫情報が記憶部１２で記憶される場合には、図１Ｂで示されるように、食材注文装置１は、食材の在庫量を示す在庫情報を受け付けて記憶部１２に蓄積する在庫受付部１６をさらに備えてもよい。在庫受付部１６によって受け付けられる在庫情報は、例えば、手作業で生成された情報であってもよく、食材に付与されたＩＣタグを読み取るリーダや重量計などを用いて自動的に取得された情報であってもよい。在庫受付部１６は、受け付けた在庫情報を記憶部１２に蓄積する際に、上書きで蓄積してもよく、または、最新の在庫情報を特定可能なように蓄積してもよい。後者の場合には、注文情報生成部１４は、記憶部１２で記憶されている最新の在庫情報を用いて注文情報の生成を行ってもよい。在庫情報は、例えば、定期的に受け付けられて記憶部１２に蓄積されてもよく、または、在庫に変動があった際に受け付けられて記憶部１２に蓄積されてもよい。このように、食材の在庫量を示す在庫情報が受け付けられて蓄積される場合には、在庫情報がより正確な情報となる。また、例えば、食材注文装置１を用いた注文とは別ルートでの注文が行われる場合にも、適切に在庫情報を管理することができるようになる。

在庫受付部１６は、例えば、入力デバイスから入力された情報を受け付けてもよく、有線または無線の通信回線を介して送信された情報を受信してもよく、所定の記録媒体から読み出された情報を受け付けてもよい。なお、在庫受付部１６は、受け付けを行うためのデバイスを含んでもよく、または含まなくてもよい。また、在庫受付部１６は、ハードウェアによって実現されてもよく、または所定のデバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

また、在庫情報に、賞味期限や消費期限を含めてもよい。この場合には、在庫情報において、賞味期限や消費期限ごとに、食材の在庫量が示されてもよい。そして、注文情報生成部１４は、献立の調理を行う年月日において期限の切れていない食品の在庫量のみを用いて、上記した在庫量を考慮した注文情報の生成を行ってもよい。この場合には、受付部１１において、献立の調理を行う年月日も受け付けられることが好適である。また、在庫情報に、在庫の保管場所（例えば、Ａ冷蔵庫、Ｂ冷蔵庫、Ｃ食品庫等）を含めてもよい。この場合には、在庫情報において、在庫の保管場所ごとに、食材の在庫量が示されてもよい。例えば、一つの食材が２以上の保管場所で保管されている場合には、在庫情報において、その食材の在庫量が保管場所ごとに管理されていてもよい。

［あらかじめ決められた注文量での注文］
所定の食材については、あらかじめ注文量が決められていてもよい。例えば、米や味噌などのように、大量に使用することが想定されており、それに応じた保管スペースが確保されている食材については、その保管スペースに応じた単位で購入することによって、食材が納入された後の保管スペースへの保管作業が頻繁に繰り返されないようにすることができる。また、例えば、食材注文装置１を用いた注文とは別ルートでの注文を行う食材については、注文量を「０」にしてもよい。

この場合には、記憶部１２において、単数または複数の注文量情報が記憶されていてもよい。注文量情報は、食材識別子と、その食材識別子で識別される食材の注文量とを対応付ける情報である。図８は、注文量情報の一例を示す図である。図８において、１番目の注文量情報では、食材識別子「米」の注文量が「０」であることが示されている。例えば、上記のように、米を別ルートで購入する場合には、このような設定が行われることが好適である。また、図８の２番目の注文量情報では、食材識別子「味噌」の注文量が「１００（ｋｇ）」であることが示されている。例えば、味噌については、１００（ｋｇ）に応じた保管スペースが確保されている場合には、このような設定が行われることが好適である。

注文情報生成部１４は、注文量情報によって注文量に対応付けられている食材識別子が取得部１３によって取得された際には、その食材識別子に対応付けられている注文量となるように注文情報を生成する。０ではないある注文量となるように注文情報を生成するとは、例えば、注文量情報によって指定されている注文量と厳密に同じ注文量となるように注文情報を生成することであってもよく、注文量情報によって指定されている注文量に近い注文量となるように注文情報を生成することであってもよい。例えば、図８で示される注文量情報が記憶部１２で記憶されている場合には、食材識別子「米」に対応する注文を行うときに、注文情報生成部１４は、注文量を「０」にする。すなわち、注文情報に食材識別子「米」に関する注文を含めないようにする。また、例えば、食材識別子「味噌」に対応する注文を行うときに、注文情報生成部１４は、注文量を「１００（ｋｇ）」となるようにする。なお、例えば、味噌の注文単位が３０（ｋｇ）である場合などのように、注文量情報で指定されている注文量と一致する注文を行うことができない場合には、注文情報生成部１４は、注文量情報で指定されている注文量以下で最大の注文量となるように注文を行ってもよい。上記の味噌の例では、９０（ｋｇ）の注文を行ってもよい。

［食材コストの算出］
注文情報を用いて、所定の単位期間に注文された注文対象の合計金額、すなわち食材コストを算出してもよい。この場合には、食材注文装置１は、図１Ｃで示されるように、単位期間に注文された注文対象の合計金額を算出する算出部１７をさらに備えていてもよい。この場合には、注文情報に、注文に関する年月日及び注文対象ごとの金額が含まれているものとする。また、注文情報生成部１４は、生成した注文情報を記憶部１２に蓄積する。そして、算出部１７は、記憶部１２で記憶されている注文情報に含まれる注文に関する年月日及び注文対象ごとの金額を用いて、単位期間に注文された注文対象の合計金額を算出する。単位期間は、例えば、１か月、四半期、半年、１年等であってもよい。より具体的には、算出部１７は、２０１９年の１年間（１月から１２月まで）に注文された注文対象の合計金額を算出してもよく、２０２０年の１月（１日から３１日まで）に注文された注文対象の合計金額を算出してもよい。より詳細には、算出部１７は、合計金額を算出する単位期間に含まれる年月日の注文情報を特定し、その特定した注文情報に含まれる注文対象の各金額を合計することによって、その単位期間に注文された注文対象の合計金額を算出してもよい。また、出力部１５は、算出部１７によって算出された合計金額をも出力してもよい。なお、出力部１５が合計金額を出力する方法は、注文情報を出力する方法と同じであってもよく、または、異なっていてもよい。例えば、出力部１５は、注文情報を送信すると共に、合計金額を所定の記憶部に蓄積してもよい。

［サーバとしての食材注文装置］
本実施の形態では、食材注文装置１がスタンドアロンである場合について主に説明したが、食材注文装置１は、サーバ・クライアントシステムにおけるサーバ装置であってもよい。この場合には、受付部や出力部は、通信回線を介して入力を受け付けたり、情報を出力したりしてもよい。また、通常、サーバ装置である食材注文装置１は、複数のユーザから献立識別子等を受信することになる。したがって、献立情報やレシピ情報、在庫情報、注文量情報等は、記憶部１２において、ユーザ識別子に対応付けて記憶されており、あるユーザから献立識別子等を受け付けた場合には、食材注文装置１は、そのユーザのユーザ識別子に対応する情報を用いて注文情報を生成してもよい。

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

また、上記実施の形態において、各構成要素間で行われる情報の受け渡しは、例えば、その情報の受け渡しを行う２個の構成要素が物理的に異なるものである場合には、一方の構成要素による情報の出力と、他方の構成要素による情報の受け付けとによって行われてもよく、または、その情報の受け渡しを行う２個の構成要素が物理的に同じものである場合には、一方の構成要素に対応する処理のフェーズから、他方の構成要素に対応する処理のフェーズに移ることによって行われてもよい。

また、上記実施の形態において、各構成要素が実行する処理に関係する情報、例えば、各構成要素が受け付けたり、取得したり、選択したり、生成したり、送信したり、受信したりした情報や、各構成要素が処理で用いる閾値や数式、アドレス等の情報等は、上記説明で明記していなくても、図示しない記録媒体において、一時的に、または長期にわたって保持されていてもよい。また、その図示しない記録媒体への情報の蓄積を、各構成要素、または、図示しない蓄積部が行ってもよい。また、その図示しない記録媒体からの情報の読み出しを、各構成要素、または、図示しない読み出し部が行ってもよい。

また、上記実施の形態において、各構成要素等で用いられる情報、例えば、各構成要素が処理で用いる閾値やアドレス、各種の設定値等の情報がユーザによって変更されてもよい場合には、上記説明で明記していなくても、ユーザが適宜、それらの情報を変更できるようにしてもよく、または、そうでなくてもよい。それらの情報をユーザが変更可能な場合には、その変更は、例えば、ユーザからの変更指示を受け付ける図示しない受付部と、その変更指示に応じて情報を変更する図示しない変更部とによって実現されてもよい。その図示しない受付部による変更指示の受け付けは、例えば、入力デバイスからの受け付けでもよく、通信回線を介して送信された情報の受信でもよく、所定の記録媒体から読み出された情報の受け付けでもよい。

また、上記実施の形態において、食材注文装置１に含まれる２以上の構成要素が通信デバイスや入力デバイス等を有する場合に、２以上の構成要素が物理的に単一のデバイスを有してもよく、または、別々のデバイスを有してもよい。

また、上記実施の形態において、各構成要素は専用のハードウェアにより構成されてもよく、または、ソフトウェアにより実現可能な構成要素については、プログラムを実行することによって実現されてもよい。例えば、ハードディスクや半導体メモリ等の記録媒体に記録されたソフトウェア・プログラムをＣＰＵ等のプログラム実行部が読み出して実行することによって、各構成要素が実現され得る。その実行時に、プログラム実行部は、記憶部や記録媒体にアクセスしながらプログラムを実行してもよい。なお、上記実施の形態における食材注文装置１を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、献立識別子と、献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、料理識別子の料理を作るために用いられる食材を識別する食材識別子及び食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部にアクセス可能なコンピュータを、調理予定の献立を識別する献立識別子と、献立の数量とを受け付ける受付部、献立情報及びレシピ情報を用いて、受付部によって受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する取得部、取得部によって取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する注文情報生成部、注文情報を出力する出力部として機能させるためのプログラムである。

なお、上記プログラムにおいて、上記プログラムが実現する機能には、ハードウェアでしか実現できない機能は含まれない。例えば、情報を取得する取得部や、情報を受け付ける受付部、情報を出力する出力部などにおけるモデムやインターフェースカードなどのハードウェアでしか実現できない機能は、上記プログラムが実現する機能には少なくとも含まれない。

また、このプログラムは、サーバなどからダウンロードされることによって実行されてもよく、所定の記録媒体（例えば、ＣＤ－ＲＯＭなどの光ディスクや磁気ディスク、半導体メモリなど）に記録されたプログラムが読み出されることによって実行されてもよい。また、このプログラムは、プログラムプロダクトを構成するプログラムとして用いられてもよい。

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

図９は、上記プログラムを実行して、上記実施の形態による食材注文装置１を実現するコンピュータの外観の一例を示す模式図である。上記実施の形態は、コンピュータハードウェア及びその上で実行されるコンピュータプログラムによって実現されうる。

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

図１０は、コンピュータシステム９００の内部構成を示す図である。図１０において、コンピュータ９０１は、ＣＤ－ＲＯＭドライブ９０５に加えて、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９１１と、ブートアッププログラム等のプログラムを記憶するためのＲＯＭ９１２と、ＭＰＵ９１１に接続され、アプリケーションプログラムの命令を一時的に記憶すると共に、一時記憶空間を提供するＲＡＭ９１３と、アプリケーションプログラム、システムプログラム、及びデータを記憶するハードディスク９１４と、ＭＰＵ９１１、ＲＯＭ９１２等を相互に接続するバス９１５とを備える。なお、コンピュータ９０１は、ＬＡＮやＷＡＮ等への接続を提供する図示しないネットワークカードを含んでいてもよい。

コンピュータシステム９００に、上記実施の形態による食材注文装置１の機能を実行させるプログラムは、ＣＤ－ＲＯＭ９２１に記憶されて、ＣＤ－ＲＯＭドライブ９０５に挿入され、ハードディスク９１４に転送されてもよい。これに代えて、そのプログラムは、図示しないネットワークを介してコンピュータ９０１に送信され、ハードディスク９１４に記憶されてもよい。プログラムは実行の際にＲＡＭ９１３にロードされる。なお、プログラムは、ＣＤ－ＲＯＭ９２１、またはネットワークから直接、ロードされてもよい。また、ＣＤ－ＲＯＭ９２１に代えて他の記録媒体（例えば、ＤＶＤ等）を介して、プログラムがコンピュータシステム９００に読み込まれてもよい。

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

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

以上より、本発明の一態様による食材注文装置等によれば、指定された数量の献立を調理するために必要な食材の注文を自動的に行うことができるという効果が得られ、食材を注文する装置等として有用である。

１ 食材注文装置
１１ 受付部
１２ 記憶部
１３ 取得部
１４ 注文情報生成部
１５ 出力部
１６ 在庫受付部
１７ 算出部

Claims (9)

1. 調理予定の献立を識別する献立識別子と、当該献立の数量とを受け付ける受付部と、
   献立識別子と、当該献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、当該料理識別子の料理を作るために用いられる食材を識別する食材識別子及び当該食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部と、
   前記献立情報及び前記レシピ情報を用いて、前記受付部によって受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する取得部と、
   前記取得部によって取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する注文情報生成部と、
   前記注文情報を出力する出力部と、を備えた食材注文装置。
2. 前記記憶部では、注文対象の選択に関するポリシーを示すポリシー情報も記憶されており、
   前記注文情報生成部は、前記取得部によって取得された食材識別子に対応する複数の注文対象が存在する場合に、前記ポリシー情報に応じて注文対象を選択する、請求項１記載の食材注文装置。
3. 前記記憶部では、食材の食材識別子と、当該食材の在庫量とを対応付ける在庫情報も複数記憶されており、
   前記注文情報生成部は、前記取得部によって取得された食材識別子に対応する在庫量及び食材の必要量に基づいて注文情報を生成する、請求項１または請求項２記載の食材注文装置。
4. 前記注文情報生成部は、前記取得部によって取得された食材識別子に対応する在庫量を、食材の必要量と前記注文情報によって注文した食材の注文量とを用いて更新する、請求項３記載の食材注文装置。
5. 食材の在庫量を示す在庫情報を受け付けて前記記憶部に蓄積する在庫受付部をさらに備えた、請求項３記載の食材注文装置。
6. 前記記憶部では、食材識別子と、当該食材識別子で識別される食材の注文量とを対応付ける注文量情報も記憶されており、
   前記注文情報生成部は、前記注文量情報によって注文量に対応付けられている食材識別子が前記取得部によって取得された際には、当該食材識別子に対応付けられている注文量となるように前記注文情報を生成する、請求項１から請求項５のいずれか記載の食材注文装置。
7. 前記注文情報には、注文に関する年月日及び注文対象ごとの金額が含まれており、
   前記注文情報生成部は、生成した注文情報を前記記憶部に蓄積し、
   前記記憶部で記憶されている注文情報に含まれる注文に関する年月日及び注文対象ごとの金額を用いて、単位期間に注文された注文対象の合計金額を算出する算出部をさらに備え、
   前記出力部は、前記算出部によって算出された合計金額をも出力する、請求項１から請求項６のいずれか記載の食材注文装置。
8. 受付部、献立を識別する献立識別子と、当該献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、当該料理識別子の料理を作るために用いられる食材を識別する食材識別子及び当該食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部、取得部、注文情報生成部、及び出力部を用いて処理される食材注文方法であって、
   前記受付部が、調理予定の献立を識別する献立識別子と、当該献立の数量とを受け付けるステップと、
   前記取得部が、前記献立情報及び前記レシピ情報を用いて、受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得するステップと、
   前記注文情報生成部が、取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成するステップと、
   前記出力部が、前記注文情報を出力するステップと、を備えた食材注文方法。
9. 献立を識別する献立識別子と、当該献立識別子の献立に含まれる料理を識別する料理識別子とを対応付ける献立情報が複数記憶されると共に、料理識別子と、当該料理識別子の料理を作るために用いられる食材を識別する食材識別子及び当該食材の使用量とを対応付けるレシピ情報が複数記憶される記憶部にアクセス可能なコンピュータを、
   調理予定の献立を識別する献立識別子と、当該献立の数量とを受け付ける受付部、
   前記献立情報及び前記レシピ情報を用いて、前記受付部によって受け付けられた献立識別子及び数量に応じた献立を作るために必要な食材の食材識別子及び食材の必要量を取得する取得部、
   前記取得部によって取得された食材識別子及び食材の必要量に基づいて、食材を所定の注文単位で注文するための注文情報を生成する注文情報生成部、
   前記注文情報を出力する出力部として機能させるためのプログラム。

Images