JP2020101967A - 食材管理システム、食材保管庫、および食材購入推奨方法 - Google Patents

Abstract

【課題】食材を管理し必要に応じて食材の購入を勧める食材管理システムにおいて、食材の購入をユーザにより有利なかたちで推奨する。【解決手段】食材管理システムは、食材保管庫に在庫している食材の在庫情報を取得する在庫情報取得手段と、食材を販売する販売店から販売情報を取得する販売情報取得手段と、前記在庫情報と前記販売情報に基づいて、ユーザに購入を勧める推奨食材を決定する推奨食材決定手段と、前記推奨食材の購入を勧める通知を、前記食材保管庫に関連付けられた端末に送信する送信手段と、を備える。例えば、レシピ提示の際に特売されている食材を利用するレシピを優先的に提案して当該不足食材の購入を推奨してもよい。また、常備品の在庫が少なくなったときに購入を推奨する際に、常備品が特売されているか否かに応じて推奨通知を行うための在庫量の判定閾値を変えてもよい。【選択図】図１２

Description

本発明は、食材管理システムに関する。

近年、冷凍冷蔵庫（以下、単に冷蔵庫とも称する）に種々の機能を持たせて利便性を向上させることが提案されている。

例えば、特許文献１は、冷蔵庫に食品を入れる際に、冷蔵庫との音声対話により食品名と使用期限とを入力可能とし、食品の使用期限が近づくと冷蔵庫から音声により知らせることを提案する。

特許文献２は、在庫食材を使い切るように所定期間（例えば１週間）の献立を決定し、追加購入が必要な食材が分かる形式で食材リストを提示する。また、この画面に、食材を購入するための購入画面へ移動するためのボタン（ＧＵＩ）を設けて、購入を容易にすることも提案されている。

特許文献３は、冷蔵庫を閉じる際に食材に付加したＩＣタグを読み取ることで、在庫食品の種類とともにその使用期限も把握して管理することを提案する。また、テレビから受信したレシピと在庫食材とに応じて、このレシピにしたがって調理する際に必要となる食材を発注可能とすることも提案する。

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

しかしながら、上記従来技術は、食品の販売店との連携を考慮していない。食品販売店は食品の特売を行うことがあり、食品の特売を考慮して食品の購入を勧めることはユーザにとってメリットがある。

本発明は、食材の在庫を管理し必要に応じて食材の購入を勧める食材管理システムにおいて、食材の購入をユーザにより有利なかたちで推奨することを目的とする。

本発明の一態様は、
食材保管庫に在庫している食材の在庫情報を取得する在庫情報取得手段と、
食材を販売する販売店から販売情報を取得する販売情報取得手段と、
前記在庫情報と前記販売情報に基づいて、ユーザに購入を勧める推奨食材を決定する推奨食材決定手段と、
前記推奨食材の購入を勧める通知を、前記食材保管庫に関連付けられた端末に送信する送信手段と、
を備える、食材管理システムである。

本態様において、販売情報には特売されている食材に関する情報が含まれ、推奨食材決
定手段は、特売されている食材を優先的に推奨する食材として決定してもよい。また、販売情報に、食材またはその包装もしくは容器に食材に関する情報を格納した記憶媒体が設けられた（取り付けられた）食材であるか否かの情報が含まれ、推奨食材決定手段は、当該記憶手段が設けられた食材を優先的にユーザに推奨する食材として決定してもよい。ここで、「優先的に」というのは、他の条件が同条件であれば、特売されている食材あるいは記憶手段が設けられた食材を推奨食材として決定するという意味であり、他の条件次第ではこれらの条件を満たさない食材が推奨食材として決定されてもよい。

本態様は、在庫情報に基づいて提案するレシピを決定するレシピ決定手段をさらに備えてもよい。この場合、推奨食材決定手段は、レシピ決定手段によって決定されたレシピに必要な食材の中のうち前記食材保管庫に在庫されていない食材を、推奨食材として決定してもよい。また、レシピ決定手段は、追加購入が必要な食材が少ないレシピほど高く評価し、食材の追加購入が必要な場合には、追加購入が必要な食材が特売されている食材であれば、そうでない場合よりも高く評価し、評価の高い所定数個のレシピを提案するレシピとして決定してもよい。このようにすることで、在庫食材だけで作れないレシピを提案する際に、特売されている食材を用いたレシピが提案されるので、ユーザにとってメリットがある。特売されている食材を用いたレシピを優先的に提案することは、特売されている食材の購入を優先的に推奨することと同義とみなせる。

また、本態様において、推奨食材決定手段は、前記食材保管庫に常備すべき常備食材の在庫量が第１閾値以下であれば、当該常備食材を推奨食材として決定してもよい。この場合、推奨食材決定手段は、常備食材が特売されている食材である場合には、第２閾値（第２閾値は第１閾値よりも大きい）以下であれば、当該常備食材を推奨食材として決定することが望ましい。常備品が特売されている場合には早めに購入を推奨することで、特売の機会に在庫補充をすることが可能となる。特売品であれば在庫が第１閾値よりも多くても購入を推奨することは、特売品の購入を優先的に推奨することと同義とみなせる。

本態様は、食材の在庫情報に基づき、所定の頻度以上で使用および補充があり、かつ、在庫量が平均して所定量以上である食材を、常備食材として決定する常備食材決定手段をさらに備えてもよい。この構成によれば、ユーザが特段の入力をしなくても、食品保管庫に常備すべき食材を把握できる。

本態様において、販売店は実店舗であり、推奨食材の購入を勧める通知の前記ユーザ端末への送信は、ユーザ端末が前記実店舗内または前記実店舗から所定の距離以内に位置するときに行われてもよい。このようにすれば、ユーザが実店舗の近くにいるときに通知がされるので、通知を受けてすぐに購入を行うことができる。

本態様において、販売店はオンラインショップである場合は、食材の購入を推奨する通知には、前記オンラインショップにおける前記推奨食材の購入ページへのリンクが含まれてもよい。この構成によれば、ユーザは通知を受けて後に、食材の購入ページにジャンプして食材の購入が簡単にできる。

また、推奨食材を購入可能なオンラインショップが複数存在する場合には、前記通知には、オンラインショップごとの販売価格および最短配送日時が含まれてもよい。このように、販売価格と最短配送日時が含まれることで、どの販売店で購入するのがよいかをユーザが判断する手助けとなる。

また、本態様において、販売店は実店舗であり、かつ、推奨食材を購入可能な販売店が複数ある場合、ユーザの現在位置および前記食材保管庫の位置の少なくともいずれかに基づいて、１つまたは複数の販売店を選択する販売店選択手段をさらに備え、前記通知には
、前記販売店選択手段によって選択された販売店の情報が含まれてもよい。例えば、ユーザあるいは食材保管庫に近い販売店を選択したり、ユーザの位置から食材保管庫までの経路上にある販売店を選択したりすることが考えられる。このような立地にある販売店は、ユーザが立ち寄りやすい店舗であるため、ユーザにとって便利である。

本発明の別の一態様は、
食材に関する情報を読み取る読取モジュールを備える食品保管庫であって、
前記読取モジュールは、底面部と、前記底面部に対して垂直に設けられた複数の仕切部材と、前記複数の仕切部材のいずれかに設けられたＲＦリーダーとを含み、
前記ＲＦリーダーは、前記仕切部材の間に収納された食材の包装または容器に取り付けられたＲＦタグから、当該食材に関する情報を読み取る、
ことを特徴とする食材保管庫である。

本発明のさらに別の一態様は、
コンピュータによって実行される食材購入推奨方法であって、
食材保管庫に在庫している食材の在庫情報を取得する在庫情報取得ステップと、
食材を販売する販売店から販売情報を取得する販売情報取得ステップと、
前記在庫情報と前記販売情報に基づいて、ユーザに購入を勧める推奨食材を決定する推奨食材決定ステップと、
前記推奨食材の購入を勧める通知を、前記販売店に関する情報とともに前記食材保管庫のユーザに関連付けられた端末に送信する送信ステップと、
を含む、食材購入推奨方法である。

また、本発明は、この方法をコンピュータに実行させるためのコンピュータプログラム、あるいはこのコンピュータプログラムを非一時的に記憶したコンピュータ可読記憶媒体として捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。

本発明によれば、食材を管理し必要に応じて食材の購入を勧める食材管理システムにおいて、食材の購入をユーザにより有利なかたちで推奨することができる。

第１実施形態にかかるシステムの全体概要を示す図。 第１実施形態にかかる冷凍冷蔵庫の機能ブロックを示す図。 冷凍冷蔵庫の庫内に設置される読取モジュールの外観を示す図。 在庫情報記憶部に記憶されるデータの一例を示す図。 販売情報記憶部に記憶されるデータの一例を示す図。 在庫リスト表示画面の一例を示す図。 第１実施形態にかかるレシピ決定処理の流れを示すフローチャート。 レシピ評価の基準の一例を示す図。 レシピ詳細画面および商品詳細画面の一例を示す図。 第２実施形態にかかる冷凍冷蔵庫の機能ブロックを示す図。 第２実施形態における常備品決定処理を説明する図。 第２実施形態における追加購入推奨処理の流れを示すフローチャート。

＜実施形態１＞
［システム構成］
本発明の第1実施形態は、冷凍冷蔵庫（食品保管庫）１００に在庫している在庫食材を
管理し、在庫食材を考慮してレシピを提案するとともに、必要となる食材の購入を容易化する食材管理システムである。

図１は、本実施形態にかかるシステムの全体概要を示す図である。本システムは、冷凍冷蔵庫１００、ユーザ端末２００、ショッピングサーバ３００を含む。冷凍冷蔵庫１００は、食材を保管するとともに、在庫食材の管理や在庫食材に基づくレシピ提案などを行う機能を有する。ユーザ端末２００は、冷凍冷蔵庫１００と通信可能であり、冷凍冷蔵庫１００内にある食材の情報を取得したり、冷凍冷蔵庫１００にレシピの提案を求めたりする機能を有する。ユーザ端末２００は、また、ショッピングサーバ３００と通信可能であり、ショッピングサーバ３００から販売商品に関する情報を取得したり、商品の購入をしたりする機能を有する。ショッピングサーバ３００は、食品を含む商品の販売を行うオンラインショッピングサイトを提供し、ユーザ（ユーザ端末２００）からの購入指示に応じて、商品の受注・発送を行う機能を有する。

ユーザ端末２００は、スマートフォン、タブレット型ＰＣ、ラップトップ型ＰＣ、デスクトップ型ＰＣなどの任意の情報処理装置（コンピュータ）であり、冷凍冷蔵庫１００およびショッピングサーバ３００と通信可能である。冷凍冷蔵庫１００との通信は、無線ＬＡＮやＢｌｕｅｔｏｏｔｈ（登録商標）が一般的であるが、その他の通信方式であっても構わない。ユーザ端末２００は、インターネットなどの公衆網を介して冷凍冷蔵庫１００と通信することで、在宅していない場合でも冷凍冷蔵庫１００の状態を把握可能である。

ユーザ端末２００はあらかじめ冷凍冷蔵庫１００との関連付けがなされる。例えば、これら２つの装置同士が機器ＩＤに基づいて直接的に関連付けられてもよいし、これら２つの装置が共通のユーザＩＤに関連付けられることで間接的に関連付けられてもよい。なお、ユーザＩＤに基づく関連付けを行う場合には、これら２つの装置を結びつけるための外部サーバを用いるとよい。

また、ショッピングサーバ３００は、１台または複数台の情報処理装置（コンピュータ）から構成され、オンラインショッピングに関する機能を提供する。

ユーザ端末２００およびショッピングサーバ３００は従来技術を適用可能であるため詳細な説明は省略し、以下では、主に冷凍冷蔵庫１００について詳細に説明する。

［冷凍冷蔵庫］
図２は、冷凍冷蔵庫１００の機能ブロックを示す図である。冷凍冷蔵庫１００は、読取モジュール１０１、庫内カメラ１０４、販売情報取得部１０５、在庫食材情報取得部１１０、在庫情報記憶部１１１、販売情報記憶部１１２、在庫表示出力部１１３、レシピ検索要求受信部１１４、レシピ検索部１１５、レシピ出力部１１６を備える。これらの機能部のうち、読取モジュール１０１と庫内カメラ１０４以外の機能部は、冷凍冷蔵庫１００に設けられた１つまたは複数のプロセッサがプログラムを実行することによって実現される。

（在庫食材の読取機能）
読取モジュール１０１は、庫内の食材１０に付されたＲＦタグ１１から食材の情報を読み取るためのモジュールである。図３に、読取モジュール１０１の外観を示す。読取モジュール１０１は、底面部２０と、底面部２０に対して略垂直に設けられた複数の仕切部材２１と、端部の仕切部材２１に設けられたＲＦリーダー１０２と、底面部２０に設けられた重量センサ１０３を有する。読取モジュール１０１によって読み取られた情報は、在庫食材情報取得部１１０に送られる。

読取モジュール１０１は、冷凍冷蔵庫１００に予め備え付けられたものであってもよいし、冷凍冷蔵庫１００に後から設置されてもよい。読取モジュール１０１を後から設置する場合、読取モジュール１０１はバッテリ駆動としてもよいし、冷凍冷蔵庫１００から電源をとってもよい。また、読取モジュール１０１が読み取った情報は、有線通信または無線通信を介して直接に冷凍冷蔵庫１００に送信されてもよいし、無線通信により外部サーバを経由して冷凍冷蔵庫１００に送信されてもよい。後付け可能な読取モジュール１０１を用いることで、ＲＦリーダー１０２などを有していない冷凍冷蔵庫１００であっても、食材１０の情報を読み取ることが可能となる。

読取モジュール１０１において、端部以外の仕切部材２１は移動可能に構成されて、仕切部材２１間の間隔を調整可能であってもよい。仕切部材２１の移動は、スライド移動であってもよいし、取付位置を変えることによる移動であってもよい。また、図３の例では、端部が開放された構成であるが、端部も囲って四方を囲うボックス形状としてもよい。

食材１０（またはその包装や容器）に食材に関する情報を記憶したＲＦタグ１１が付されている場合には、食材１０を読取モジュール１０１の仕切部材２１の間に配置することで、ＲＦリーダー１０２が食材に関する情報を読み取ることができる。ＲＦタグ１１には、食材１０の種類や消費期限が含まれる。また、ＲＦタグ１１に格納される食材に関する情報は、食材１０の総重量（包装等を含む）、内容量、１個あたりの重量等が含まれてもよく、その場合、これらの情報を元に重量センサ１０３の検出値から食材１０の残量を把握できる。食材に関する情報は、その他にも、カロリー、栄養成分、製造者、生産地などの情報を含んでもよい。

また、このような読取モジュール１０１の仕切区画に食材１０を立てて整列させることで、食材１０が積層されることを防止でき、冷凍冷蔵庫１００を開けたときにユーザは目視で在庫食材を一覧できる。このような構成は、冷凍食品に対して好適に適用可能である。冷凍食品は、凍っているため形状が安定しており、かつ、多くの種類の商品において形状がほぼ同一であるためである。冷凍食品の包装の表面部にＲＦタグ１１を設けておけば、読取モジュール１０１に縦置きした状態でＲＦリーダー１０２がＲＦタグ１１の情報を読み取ることができる。

ただし、ＲＦタグによる読取は冷凍食品に限らず、任意の食材に対して適用可能である。例えば、読取モジュール１０１を冷蔵庫や野菜室等に設置してもよいし、庫内に食材を出し入れするときにＲＦタグを読み取れるようにＲＦリーダーを冷蔵庫の枠部分に設けてもよい。後者の場合は、食材の重量を読み取ることはできないが、少なくとも在庫している食材の種類を把握可能である。

庫内カメラ１０４は、庫内に設置され、在庫している食材を撮影するためのカメラである。庫内の食材を撮影できるように、庫内カメラ１０４は、庫内の複数箇所に設けられることが好ましい。庫内カメラ１０４によって撮影された画像は、在庫食材情報取得部１１０に送られ、在庫食材の種類や残量などが画像解析処理によって取得される。画像解析は、公知の技術によって実現可能である。なお、在庫食材情報取得部１１０すなわち冷凍冷蔵庫１００が有するプロセッサ自体が画像解析処理を行ってもよいし、在庫食材情報取得部１１０が外部のサーバに画像データを送信して外部サーバにおける解析結果を取得するようにしてもよい。

また、食材に関する情報をＲＦタグに格納する代わりに、ＱＲコード（登録商標）に格納し、当該ＱＲコードを食材（またはその包装や容器）に取り付けてもよい。ＱＲコードは庫内カメラ１０４によって読み取り可能である。あるいは庫内カメラ１０４が、食材の容器や包装に付加されているバーコードを読み取って在庫食材を認識するようにしてもよ
い。

在庫食材を検知する方法は、読取モジュール１０１や庫内カメラ１０４を使用した態様に限られない。例えば、ユーザ端末２００と在庫食材情報取得部１１０が通信を行って、ユーザ端末２００から在庫食材に関する情報が入力されてもよい。ユーザによる入力は、例えば、テキスト入力や音声入力であり、食品の種類や消費期限などをユーザが直接入力してもよい。その他にも、食材に関する情報を容器等にユーザが手書きし、この手書きの文字をユーザ端末２００で読み取って文字認識をすることで食材に関する情報を取得してもよい。また、ユーザ端末２００が食材を撮影しその画像を解析処理して食材に関する情報を取得してもよいし、ユーザ端末２００がＲＦタグやＱＲコードやバーコードを読み取って食材に関する情報を取得してもよい。このようにしてユーザ端末２００によって取得された食材に関する情報は、ユーザ端末２００から在庫食材情報取得部１１０に送信される。なお、ユーザ端末２００が撮影した画像や音声などが在庫食材情報取得部１１０に送信されて、解析処理等は在庫食材情報取得部１１０が行うようにしてもよい。

その他の検知方法として次のような方法も可能である。例えば、ＱＲコードやＲＦタグ等が付加された容器に食材を入れて保存する場合やＱＲコード等が付加されたクリップ等で袋とじして保存する場合には、ユーザ端末２００がＱＲコード等に格納されている識別子（ＩＤ）を取得し、また、容器に保存されている食品をユーザから受け取る。そして、これらの情報をユーザ端末２００から在庫食材情報取得部１１０に送信し、在庫食材情報取得部１１０がこれらの情報を関連付けて記憶する。このように、一度ＱＲコードの識別子と食材を関連付けた後は、庫内カメラ１０４等により取得したＱＲコード等の識別子から容器に保存されている食品を把握できる。

在庫食材情報取得部１１０は、上述のようにして取得した在庫食材に関する情報を、在庫情報記憶部１１１に格納する。図４は、在庫情報記憶部１１１に記憶されるデータの一例であり、食材の種類、登録日、期限、残量などが含まれる。ここでは、在庫情報記憶部１１１に最新の情報のみが格納されるように記載しているが、過去の情報を保持するようにしてもよい。例えば、保管を始めた日時、一部を使用した場合の使用量と日時、全て使い切って在庫がなくなった日時などを蓄積してもよい。このようにすれば、過去においてどのように食材を利用したかの履歴が把握可能である。

在庫食材に関する情報を取得するために、種々の方法があることを説明したが、これら全ての方法を採用する必要はなく、少なくともいずれか１つの方法で情報を取得すればよい。

（販売情報の取得機能）
販売情報取得部１０５は、ショッピングサーバ３００と通信して、ショッピングサーバ３００で販売している商品に関する情報を取得する。販売情報取得部１０５が取得した販売情報は、販売情報記憶部１１２に格納される。図５は、販売情報記憶部１１２に記憶されるデータの一例である。図に示すように、販売情報は、例えば、食材ＩＤ、食材種類、分量、販売価格、割引の有無、最短配達日時、ＲＦタグ１１の有無などの情報が含まれる。この他にも、製造メーカや製造者・生産地などの情報が販売情報に含まれてもよい。ここでは、販売情報に割引の有無が含まれる例を説明したが、現在の販売価格が割引価格であることが分かればよく、例えば、販売情報に通常販売価格と現在の販売価格とが含まれてもよい。

なお、最短配達日時が分かるために、ユーザの住所（配達先住所）が分かっている必要があるが、これはユーザが予め登録しているものとする。

また、図１では、ショッピングサーバ３００は１つのみが描かれているが、本システムは複数のショッピングサーバ３００を含んでもよく、その場合、販売情報取得部１０５はこれら複数のショッピングサーバ３００から販売情報を取得して、どのショッピングサーバ３００の販売情報であるか分かる態様で販売情報記憶部１１２に記憶する。

（在庫一覧表示機能）
在庫表示出力部１１３は、ユーザ端末２００からの要求に応じて、冷凍冷蔵庫１００に現在在庫している在庫食品の一覧を作成して、ユーザ端末２００に送信する。在庫表示出力部１１３は、在庫情報記憶部１１１を参照して、在庫している食材の種類・残量・期限を取得して、図６に示すような在庫リスト表示を行うためのデータを生成しユーザ端末２００へ送信する。なお、図６の在庫リストには、冷凍冷蔵庫１００に含まれる全ての食材がリストされるのが基本であるが、ユーザからの指示により特定の条件を満たす食材のみを表示するようにしてもよい。条件として、例えば、野菜類のみ、肉類のみ、期限が近いもののみなどが考えられるが、その他の条件であってもよい。

在庫リストには、チェックボックス６１と、レシピ検索ボタン６２、購入ボタン６３が含まれてもよい。チェックボックス６１は、各食材に設けられ、個別にオンオフを設定可能である。レシピ検索ボタン６２は、チェックボックス６１にチェックが入っている食材を利用するレシピを検索するためのボタンである。レシピ検索については後ほど詳細に説明する。購入ボタン６３は、チェックボックス６１にチェックが入っている食材を購入するためのボタンである。購入ボタン６３が押されると、ショッピングサーバ３００の商品購入ページにジャンプしてもよいし、選択された全ての商品を購入するための意思確認ページにジャンプしてもよいし、選択された商品の発注要求をショッピングサーバ３００に送信してもよい。ショッピングサーバ３００で商品を購入するために、在庫リストには商品を購入ページ等へジャンプするためのリンクが含まれる。

また、ショッピングサーバ３００が複数ある場合には、いずれかが予め選択されている場合にはそのショッピングサーバ３００を利用すればよいし、そうではない場合はいずれのショッピングサーバ３００を利用するかをユーザに選択させてもよい。

（レシピ検索機能）
レシピ検索要求受信部１１４は、ユーザからレシピ検索指示と、レシピ検索に関する条件とを受信する。レシピ検索の条件として、利用する食材、利用しない食材、料理の種類（和・洋・中、煮物・揚げ物・炒め物・ごはんもの・汁もの、など）等が例示できる。その他の条件として、ダイエットや食事療法に伴う摂取カロリーの上限や、アレルギー等による摂取禁止食材などの制限を用いてもよい。レシピ検索要求受信部１１４は、レシピ検索用の画面をユーザ端末２００に提示して、ユーザからの入力を受け取ってもよいし、上述した在庫リスト（図６）から入力を受け取ってもよい。なお、レシピ検索条件は必ずしもユーザからその都度入力される必要はなく、あらかじめ指定されたユーザの嗜好や制限を反映するようにしてもよいし、最近に作った料理と重複しないことを条件としてもよい。

レシピ検索部１１５は、レシピ検索要求受信部１１４が取得した検索条件に合致するレシピを検索してユーザに提示する。以下、図７のフローチャートを参照して、レシピ検索部１１５によるレシピ決定処理を説明する。

ステップＳ１１において、レシピ検索部１１５は、レシピ検索要求受信部１１４を介して、レシピ検索に関するユーザの要望（条件）を取得する。ユーザの要望には、上述したように、利用する食材や料理の種類などが含まれる。

ステップＳ１２において、レシピ検索部１１５は、在庫情報記憶部１１１を参照して、冷凍冷蔵庫１００に在庫している食材の情報を取得する。また、ステップＳ１３において、レシピ検索部１１５は、販売情報記憶部１１２を参照して、ショッピングサーバ３００で販売している食材に関する販売情報を取得する。

ステップＳ１４において、レシピ検索部１１５は、検索条件に合致するレシピを検索する。取得するレシピには、必要材料や調理手順に関する情報が含まれる。レシピ検索自体は公知技術であるためここでの詳細な説明は省略する。なお、レシピ検索部１１５がレシピ情報を全て保持するようにしてレシピ検索部１１５（冷凍冷蔵庫１００内のプロセッサ）でレシピ検索処理の全てを行ってもよいし、外部のサーバに対してレシピ検索要求を送信してこのサーバから検索結果のレシピを受信してもよい。なお、後述するようにレシピのスコアリングを行うので、ステップＳ１４で取得するレシピに検索条件のいずれかを満たさないレシピが含まれてもよい。

ステップＳ１５において、レシピ検索部１１５は、ステップＳ１４で検索されたレシピをスコアリング（評価）する。なお、ここでは、ステップＳ１４のレシピ検索において検索のスコア付けがされていることを前提とし、ステップＳ１５でそのスコアの調整を行うことを想定する。ただし、ステップＳ１４で得られたレシピを全て同一の評価とみなしてステップＳ１５でスコアの調整を行ってもよい。

評価の基準として次のようなものが考えられる。まず、第一に、在庫食材のみで作れるレシピを高評価とし、追加購入が必要な食材（以下、不足食材ともいう）がある場合にはそうではない場合よりも低評価とする。また、不足食材がある場合、その食材が特売されている食材であれば、そうでないときよりも高評価とする。例えば、図８に示すように、不足食材がなければ評価値をゼロとし、不足食材がある場合、それが特売されている食材であれば１つあたり−１ポイントとし、特売されていない食材であれば１つあたり−２ポイントとすることが考えられる。

なお、ここでは追加食材が１つ増えるたびに評価を線形的に下げていくようにしているが、必ずしもそのようにする必要はなく、２つ目以降の追加食材についてのマイナス評価はより少なくしてもよい。特にオンラインショッピングでは、１つ買う手間も２つ以上買う手間もそれほど変わらないためである。

また、不足食材について上記以外の観点から評価を行ってもよい。例えば、不足食材のうちの最短配送日時が最も遅い食材の最短配送日を考慮して評価してもよい。すなわち、不足食材の全てを早く入手できるレシピほど高評価にすることも考えられる。また、不足食材を購入するために利用する販売店が少ないほど高評価にすることが考えられる。また、不足食材を購入するために必要な総金額が少ないほど高評価にすることが考えられる。

また、不足食材にＲＦタグ１１が取り付けられて販売されている食材であれば、そうでない場合よりも高評価にすることが考えられる。このような評価を行うことで、食品メーカが販売品にＲＦタグを取り付けるインセンティブが生じ、食品へのＲＦタグの取付の普及が見込める。

なお、取得したレシピがユーザからの検索条件を満たさない場合には、ステップＳ１５のスコアリングの際に、マイナス評価してもよい。

ここでは様々な評価基準を例示したが、これらのうちの複数の基準を組み合わせて評価してもよい。この場合、異なる評価基準に基づくスコアを単純平均または加重平均して最終的なスコアを得ることが考えられる。

ステップＳ１６において、レシピ検索部１１５は、ユーザにレシピを提示するための出力画面のデータをユーザ端末２００に送信する。レシピ提示画面では、検索されたレシピのうち、スコア（評価）が高い方から所定数個のレシピがスコアにしたがった順序でリスト表示される。そして、提示されたレシピのいずれかを選択することでレシピの詳細を見ることができる。

図９Ａは、ユーザがいずれかのレシピを選択したときに表示されるレシピの詳細画面である。図に示すように、レシピ詳細画面には、メニュー名や必要な食材９１とその分量９２、必要な食材の保有有無（在庫有無）９３が表示される。レシピ詳細画面には、つくりかたの手順も表示される。また、一括購入ボタン９５は、不足食材を一括で購入するためのボタンであり、例えば、このボタンを押すとショッピングサーバ３００において、不足食材が全て買い物カゴに入れられた状態の決済画面にジャンプするようにしてもよい。

必要な食材９１を選択すると、選択された食材を購入するためのショッピングサーバ３００上での商品詳細ページが表示される。具体的には、各食材にショッピングサーバ３００の商品詳細ページのリンクが関連付けられており、何れかの食材が選択されると関連付けられたリンクのページが表示される。図９Ｂは、商品詳細ページの例を示す。この例では、選択された食材が商品として３つ存在することを想定する。商品一覧９８に複数の商品のそれぞれについて、販売店舗名、商品名、価格、最短配送日などの情報が表示される。このように、複数の商品のそれぞれについて、販売価格や最短配送日がユーザに容易に把握可能な形式で表示されることはユーザの利便性を向上する。また、ユーザは表示されている複数の商品の一つを選択可能であり、選択されている商品（この例では、下線が引かれた商品が選択されていることを示す）に関する情報が、画像表示欄９６および詳細説明欄９７に表示される。なお、レシピ詳細画面で選択された食材が商品として複数存在する場合に、複数の商品をどのような順序で表示するかは、種々の方式が考えられる。例えば、価格（単価）が安い順に表示したり、最短配送日が早いものから順に表示したり、特売品を優先的に表示したり、食品にＲＦタグが付加されているものを優先的に表示したりすることが考えられる。

ユーザは、数量を指定して「買い物カゴに入れる」ボタン９９を押すことで、現在選択されている商品を買い物カゴに投入できる。買い物カゴに投入した後の決済処理は、通常のオンラインショップにおける処理と同様であるためここでは説明を省略する。なお、本実施形態では、複数の販売店（オンラインショップ）の商品が商品一覧に表示されているが、いずれか一つの販売店のみの商品を表示するようにしてもよい。

［本実施形態の有利な効果］
本実施形態は読取モジュール１０１を利用して食材を整列した状態で冷凍冷蔵庫１００内に保管できるため、冷凍冷蔵庫１００に在庫している食材をユーザが目視で簡単に把握できる。

また、冷凍冷蔵庫１００内に在庫している食材に関する情報（種類、残量、期限など）を冷凍冷蔵庫１００が把握しているため、ユーザはユーザ端末２００を介して在庫食材を把握できる。ユーザ端末２００と冷凍冷蔵庫１００がインターネットなどの公衆網を介して接続される形態では、ユーザは自宅以外の場所でもいつでも在庫食材に関する情報を参照できる。

また、レシピ検索の結果を表示する際に、不足食材を簡単に購入できる仕組みを導入しているためユーザの利便性が向上する。また、レシピを検索する際に、ユーザの希望や在庫食材だけでなく販売店における特売情報を考慮しているため、よりユーザにとって望ま
しいレシピの提案が可能となる。また、商品の購入を推奨する際に、ＲＦタグが付された商品を優先的に推奨することで、食品メーカ等が食品にＲＦタグを付加するインセンティブとなる。

＜実施形態２＞
本実施形態は、冷凍冷蔵庫１００に保管される常備品の在庫量が所定量以下になったら購入を推奨する食材管理システムである。本実施形態の基本的な構成は実施形態１と同様であるため、主に実施形態１と異なる部分について説明を行う。

本実施形態におけるシステムも実施形態１（図１）と同様に、冷凍冷蔵庫１００、ユーザ端末２００、ショッピングサーバ３００から構成される。図１０に本実施形態にかかる冷凍冷蔵庫１００の機能構成を示す。

本実施形態においても在庫食材を取得するための機能（すなわち、読取モジュール１０１、庫内カメラ１０４、在庫食材情報取得部１１０、在庫情報記憶部１１１）、および販売情報を取得するための機能（すなわち販売情報取得部１０５、販売情報記憶部１１２）は第１実施形態と同様であるため説明は省略する。

本実施形態では、冷凍冷蔵庫１００は、常備食材決定部１２０、常備食材情報記憶部１２１、通知部１２２の機能を有する。常備食材決定部１２０は、在庫情報やユーザからの入力に基づいて常備すべき食材の種類と、その常備食材を補充すべき残量の閾値を決定する。通知部１２２は、常備食材の残量が閾値以下となった場合に、常備食材の購入を推奨する通知を行う。以下、より詳細に説明する。

（常備食材決定処理）
図１１Ａは、常備食材決定部１２０が行う、在庫情報に基づく常備食材の決定処理である。なお、本実施形態においては、在庫情報記憶部１１１において、最新の在庫情報だけでなく、過去の在庫情報の履歴も含まれていることを前提とする。また、この処理においては、同一食材の異なる商品はひとまとめにして判断してもよいし、商品ごとに個別に判断をしてもよい。

ステップＳ２１において、常備食材決定部１２０は、在庫情報記憶部１１１から在庫情報の履歴を取得する。在庫情報の履歴から、冷凍冷蔵庫１００に在庫している（していた）食材の残量の時間的な変化を把握可能である。

ステップＳ２２において、常備食材決定部１２０は、ほぼ常に在庫があり、かつ、所定の頻度以上で追加購入されている食材を抽出する。ほぼ常に在庫があるというのは、対象期間中の在庫なしの期間の割合が所定割合以下の食材といえる。所定の頻度以上で追加されている食材は、所定の頻度以上で食材の使用と補充がされている食材といえる。これら２つの条件は、在庫食材が常備食材として満たすべき条件といえる。後者の条件は、使用されずに放置されている食材を除外するための条件である。なお、在庫に関する判定閾値（所定の割合）と追加購入頻度の判定閾値（所定の頻度）は、全ての食材について同一の値であってもよいし、食材に応じて異なる値としてもよい。

ステップＳ２３において、常備食材決定部１２０は、ステップＳ２２の条件を満たす食材が追加購入されたときの在庫量に基づいて、補充を推奨するための残量の閾値を決定する。例えば、食材が追加購入されたときの在庫量の平均値や中間値や最頻値を、閾値として採用することが考えられる。

ここで、図１１Ｂを参照してステップＳ２２，Ｓ２３の処理を説明する。図１１Ｂは、
ある食材の在庫量の時間変化を示すグラフ１１０１を示す。この例では、食材が常に在庫しており、また、時期１１０２，１１０３において追加購入されているため、ステップＳ２２の条件を満たすと判断される。そして、追加購入がされた時期１１０２，１１０３における在庫量に応じて、ステップＳ２３において在庫量１１０４が、補充を推奨するための在庫量の閾値として決定される。

ステップＳ２４において、ユーザに対して、常備食材として判断された食材の種類と追加購入のための閾値を提示して、この条件で常備食材として追加購入の監視対象とするか否かを問い合わせる。この問い合わせは、ユーザが、常備食材として管理するか否かを選択したり、判定閾値を変更したりすることができるように構成される。なお、この時点でユーザに問い合わせを行わずに、常備食材の在庫量が閾値を下回りユーザに追加購入を推奨する際に、上記の問い合わせをするようにしてもよい。

ステップＳ２５において、常備食材決定部１２０は、決定された常備食材の種類と追加購入のための閾値を関連付けて常備食材情報記憶部１２１に格納する。

なお、ここでは常備食材決定部１２０が在庫量の履歴に基づいて常備食材の種類と閾値を決定しているが、ユーザがこれらの情報を手動で入力しても構わない。

（常備品補充推奨処理）
次に、図１２Ａを参照して、通知部１２２が行う常備品の追加購入推奨処理について説明する。この処理は、例えば、定期的に行われてもよいし、ユーザによって指定されたときに行われてもよいし、所定の条件が満たされたときに行われてもよい。所定の条件の例は、ユーザがショッピングサーバ３００にアクセスしたという条件である。

ステップＳ３１において、通知部１２２は、常備食材情報記憶部１２１に記憶されている常備食材に関して、現在の在庫情報を在庫情報記憶部１１１から取得する。

ステップＳ３２において、通知部１２２が、常備食材の現在の在庫量が、常備食材情報記憶部１２１に記憶されている判定閾値（閾値ＴＨと称する）以下であるか判定する。在庫量が閾値ＴＨ以下であれば（Ｓ３２−ＹＥＳ）、ステップＳ３５に進み、当該常備食材の追加購入を推奨する通知を行う。そうでなければ（Ｓ３２−ＮＯ）、ステップＳ３３に進む。

ステップＳ３３では、通知部１２２は、販売情報記憶部１１２を参照して、処理対象の常備食材が特売されているか否かを判断する。特売されていない場合（Ｓ３３−ＮＯ）には、何もせずに処理を終了する。一方、処理対象の常備食材が特売されている場合（Ｓ３３−ＹＥＳ）には、ステップＳ３４に進む。

ステップＳ３４では、通知部１２２が、常備食材の現在の在庫量が、閾値ＴＨに所定の値αを足した量以下であるか判定する。この値α（＞０）は食材に応じて適宜決定すればよく、システム側で予め設定してもよいし、ユーザからの入力に基づいて決定してもよい。また、在庫情報の履歴に基づいて１回の利用あたりの利用量を求めて、１回または数回分の利用量を、値αとして決定してもよい。在庫量が閾値ＴＨ＋αより多ければ（Ｓ３４−ＮＯ）、何もせずに処理を終了する。一方、在庫量が閾値ＴＨ＋α以下であれば（Ｓ３４−ＹＥＳ）、ステップＳ３５に進み、当該常備食材の追加購入を推奨する通知を行う。

ステップＳ３２からＳ３４における判定方法を、図１２Ｂを参照して説明する。図１２Ｂに示すように、常備食材の在庫量が閾値ＴＨ以下であれば、当該常備食材が特売されているか否かにかかわらずに、追加購入を推奨する。常備食材の在庫量が閾値ＴＨより多く
閾値ＴＨ＋α以下であれば、常備食材が特売されている場合に限って追加購入を推奨する。常備食材の在庫量が閾値ＴＨ＋αよりも多い場合には、常備食材が特売されているか否かにかかわらずに、追加購入の推奨をしない。

ステップＳ３５において、通知部１２２は、ユーザ端末２００に対して、常備食材の追加購入を推奨する通知を行う。常備食材に対応する商品が複数存在する場合には、例えば、次のような基準で優先度をつけて購入を推奨すればよい。まず、販売価格（単価）に基づいて優先度を決定することが考えられる。常備食材が特売されていることが原因で追加購入を推奨する場合（Ｓ３４でＹＥＳと判定された場合）は、特売されている商品を優先的に推奨するとよい。その他にも、最短配送日時や商品にＲＦタグが付加されているか否かなどを考慮して推奨商品の優先度を決定してもよい。

通知部１２２からユーザ端末２００に送られる追加購入推奨通知には、ショッピングサーバ３００において推奨食材を購入するためのページにジャンプするためのリンク情報が含まれる。これにより、ユーザは購入推奨通知を受けて簡単に購入が行える。購入推奨通知には、実施形態１で説明した商品の詳細情報画面（図９Ｂ）と同様の情報を含む画面が含まれることが望ましい。この際、複数の販売店での購入が可能である場合には、販売店ごとの価格や配達日時が比較可能な形で表示されることも望ましい。なお、ユーザに購入の確認を求めてから購入を行う代わりに、ユーザの確認を取らずに購入（発注）手続を行うようにしてもよい。このように自動的に購入を行う場合には、購入手続を行った旨の通知をユーザに対して行い、また事後的な購入のキャンセルを受付可能とするとよい。

［本実施形態の有利な効果］
本実施形態によれば、冷凍冷蔵庫１００に常備すべき食材の在庫量が閾値よりも少なくなったときに追加購入を推奨することができるので、常備食材の在庫切れを防止できる。また、常備食材が特売されているときには、推奨通知を行う閾値を上げることで、特売価格での購入が可能となる。

また、本実施形態では、食材の在庫情報の履歴から常備食材を自動的に判断しているため、ユーザが常備食材を入力する手間を省くこともできる。

＜変形例＞
上記の実施形態においては、食材の販売店がオンラインショップであったが、販売店は実店舗であってもよい。この場合、ショッピングサーバ３００の代わりに、商品情報提供を提供するためのサーバが利用される。また、実施形態１のレシピ情報の提供を行う際や、実施形態２の常備品の追加購入の推奨を行う際には、商品販売ページへジャンプするため機能は実装せず、商品の詳細情報を提示のみを行う。

また、購入を推奨する食材を販売する実店舗が複数存在する場合に、ユーザの現在位置（すなわちユーザ端末２００の現在位置）や冷凍冷蔵庫１００の位置（典型的には自宅の位置）を考慮して、いずれか１つまたは複数の販売店での商品情報を提供するようにしてもよい。例えば、ユーザの現在位置に最も近い販売店や、冷凍冷蔵庫１００の位置に最も近い販売店を選択することが考えられる。あるいは、ユーザの現在位置から冷凍冷蔵庫１００までの経路上に存在する販売店を選択することが考えられる。

さらに、実施形態２の常備品補充推奨処理を、ユーザ（ユーザ端末２００）が販売店に入店したとき、あるいは販売店から所定距離以内に接近したときに実行するようにしてもよい。どの販売店に入店または接近したときに常備品補充推奨処理を実行するかは、ユーザがあらかじめ設定可能としてもよい。なお、常備品補充推奨処理の全ての販売店に入店または接近したときに行う必要はなく、通知の要否までの判定を予め行っておいて、ユー
ザが販売店に入店または接近したときに通知を行うようにしてもよい。

上記の実施形態では、冷凍冷蔵庫１００内のプロセッサ（コンピュータ）が在庫食材の把握やレシピ提案などの機能を実行している。しかしながら、これらの機能は、冷凍冷蔵庫１００以外に設けられたコンピュータによって実行されてもよい。このコンピュータは、冷凍冷蔵庫１００の読取モジュール１０１や庫内カメラ１０４、およびユーザ端末２００と通信可能であれば、上述した機能を実現することができる。

また、上記では冷凍冷蔵庫に本発明を適用する例を取り上げたが、冷凍機能と冷蔵機能のいずれか一方のみを有する食品保管庫に本発明を適用してもよいし、冷凍機能も冷蔵機能も有さない食品保管庫に本発明を適用してもよい。

１００：冷凍冷蔵庫 ２００：ユーザ端末 ３００：ショッピングサーバ
１０１：読取モジュール １０２：ＲＦリーダー １０３：重量センサ
１０４：庫内カメラ １０５：販売情報取得部 １０６：在庫食材情報取得部
１１１：在庫情報記憶部 １１２：販売情報記憶部 １１３：在庫表示出力部
１１４：レシピ検索要求受信部 １１５：レシピ検索部 １１６：レシピ出力部

Claims (19)

1. 食材保管庫に在庫している食材の在庫情報を取得する在庫情報取得手段と、
   食材を販売する販売店から販売情報を取得する販売情報取得手段と、
   前記在庫情報と前記販売情報に基づいて、ユーザに購入を勧める推奨食材を決定する推奨食材決定手段と、
   前記推奨食材の購入を勧める通知を、前記食材保管庫に関連付けられた端末に送信する送信手段と、
   を備える、食材管理システム。
2. 前記販売情報には、特売されている食材に関する情報が含まれ、
   前記推奨食材決定手段は、特売されている食材を優先的に推奨する食材として決定する、
   請求項１に記載の食材管理システム。
3. 前記食材保管庫は、前記食材またはその包装もしくは容器に設けられた記憶媒体から前記食材に関する情報を読み取る読取モジュールを備えており、
   前記在庫情報取得手段は、前記読取モジュールから前記食材保管庫に在庫している食材の在庫情報を取得する、
   ことを特徴とする請求項１または２に記載の食材管理システム。
4. 前記食材保管庫の前記読取モジュールは、重量センサを備えており、
   前記在庫情報取得手段は、前記読取モジュールから得られる重量センサの検出値から、前記食材の残量を前記在庫情報として、取得する、
   ことを特徴とする請求項３に記載の食材管理システム。
5. 前記記憶媒体は、ＲＦタグであり、
   前記読取モジュールは、底面部と、前記底面部に対して垂直に設けられた複数の仕切部材と、前記複数の仕切部材のいずれかに設けられたＲＦリーダーとを備える、
   ことを特徴とする請求項３または４に記載の食材管理システム。
6. 前記販売情報には、食材またはその包装もしくは容器に食材に関する情報を格納した記憶媒体が設けられた食材であるか否かの情報が含まれ、
   前記推奨食材決定手段は、食材に関する情報を格納した記憶媒体が食材またはその包装もしくは容器に設けられた食材を優先的にユーザに推奨する食材として決定する、
   請求項１から５のいずれか１項に記載の食材管理システム。
7. 前記在庫情報に基づいて提案するレシピを決定するレシピ決定手段をさらに備え、
   前記推奨食材決定手段は、前記レシピ決定手段によって決定されたレシピに必要な食材の中のうち前記食材保管庫に在庫されていない食材を、推奨食材として決定する、
   ことを特徴とする請求項１から６のいずれか１項に記載の食材管理システム。
8. 前記販売情報には、特売されている食材に関する情報が含まれ、
   前記レシピ決定手段は、
   追加購入が必要な食材が少ないレシピほど高く評価し、
   食材の追加購入が必要な場合には、追加購入が必要な食材が特売されている食材であれば、そうでない場合よりも高く評価し、
   評価の高い所定数個のレシピを、提案するレシピとして決定する、
   ことを特徴とする請求項７に記載の食材管理システム。
9. 前記推奨食材決定手段は、前記食材保管庫に常備すべき常備食材の在庫量が第１閾値以下であれば、当該常備食材を推奨食材として決定する、
   請求項１から６のいずれか１項に記載の食材管理システム。
10. 前記販売情報には、特売されている食材に関する情報が含まれ、
    前記推奨食材決定手段は、前記常備食材が特売されている食材である場合には、第２閾値以下であれば、当該常備食材を推奨食材として決定し、
    前記第２閾値は前記第１閾値よりも大きい、
    請求項９に記載の食材管理システム。
11. 食材の在庫情報に基づき、所定の頻度以上で使用および補充があり、かつ、在庫量が平均して所定量以上である食材を、常備食材として決定する常備食材決定手段をさらに備える、
    請求項９または１０に記載の食材管理システム。
12. 前記販売店は実店舗であり、前記推奨食材の購入を勧める通知の前記端末への送信は、前記端末が前記実店舗内または前記実店舗から所定の距離以内に位置するときに行われる、
    請求項９から１１のいずれか１項に記載の食材管理システム。
13. 前記販売店はオンラインショップであり、
    前記通知には、前記オンラインショップにおける前記推奨食材の購入ページへのリンクが含まれる、
    ことを特徴とする請求項１から１２のいずれか１項に記載の食材管理システム。
14. 前記推奨食材を購入可能なオンラインショップが複数存在する場合には、前記通知には、オンラインショップごとの販売価格および最短配送日時が含まれる、
    ことを特徴とする請求項１３に記載の食材管理システム。
15. 前記販売店は実店舗であり、
    前記推奨食材を購入可能な販売店が複数ある場合、ユーザの現在位置および前記食材保管庫の位置の少なくともいずれかに基づいて、１つまたは複数の販売店を選択する販売店選択手段をさらに備え、
    前記通知には、前記販売店選択手段によって選択された販売店の情報が含まれる、
    ことを特徴とする請求項１から１２のいずれか１項に記載の食材管理システム。
16. 食材に関する情報を読み取る読取モジュールを備える食品保管庫であって、
    前記読取モジュールは、底面部と、前記底面部に対して垂直に設けられた複数の仕切部材と、前記複数の仕切部材のいずれかに設けられたＲＦリーダーとを含み、
    前記ＲＦリーダーは、前記仕切部材の間に収納された食材の包装または容器に取り付けられたＲＦタグから、当該食材に関する情報を読み取る、
    ことを特徴とする食材保管庫。
17. 前記読取モジュールは、前記複数の仕切部材によって区切られた区画に設けられた重量センサをさらに含む、
    ことを特徴とする請求項１６に記載の食材保管庫。
18. コンピュータによって実行される食材購入推奨方法であって、
    食材保管庫に在庫している食材の在庫情報を取得する在庫情報取得ステップと、
    食材を販売する販売店から販売情報を取得する販売情報取得ステップと、
    前記在庫情報と前記販売情報に基づいて、ユーザに購入を勧める推奨食材を決定する推奨食材決定ステップと、
    前記推奨食材の購入を勧める通知を、前記販売店に関する情報とともに前記食材保管庫のユーザに関連付けられた端末に送信する送信ステップと、
    を含む、食材購入推奨方法。
19. 請求項１８に記載の方法の各ステップをコンピュータに実行させるためのプログラム。

Images