JP2021043597A - サーバ装置、プログラム及び在庫管理システム - Google Patents

Abstract

【課題】食品の在庫管理に係る利便性を向上させることが可能なサーバ装置、プログラム及び在庫管理システムを提供する。【解決手段】ユーザを識別するユーザ識別子に関連付けて、食品の在庫数を食品種別毎に管理する管理手段と、前記食品種別毎の在庫数に基づいて、使用する食品の食品種別及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する第１選定手段と、前記第１選定手段が選定したレシピ情報を、前記ユーザ識別子に対応するユーザ端末に提供する提供手段と、前記ユーザ端末から調理対象の前記レシピ情報が指示されると、当該レシピ情報に規定された食品種別の数量に基づき、前記管理手段が管理する当該食品種別の在庫数を減算する減算手段と、を備える。【選択図】図１０

Description

本発明の実施形態は、サーバ装置、プログラム及び在庫管理システムに関する。

従来、家庭内で使用する食品（食材）を管理するための技術が提案されている。例えば、インテリジェント冷蔵庫と呼ばれる装置では、冷蔵庫内をスキャンし、食品に付されたＲＦＩＤタグ（ＩＣタグともいう）から情報を読み取ることで、冷蔵庫内に収納された食品の在庫情報を取得することが可能となっている。

しかしながら、従来の技術では、消費した食品の残量の管理については利便性に欠けるものとなっている。具体的には、上述の従来技術では、ＲＦＩＤタグを読み取ることで冷蔵庫内にどのような食品が存在するかを知ることができるが、その食品の残量を管理することはできない。例えば、購入時の内容量が６個の食品（例えば６個パックの卵）を２個分使用したような場合、上述の従来技術では残りの残量（在庫数）を管理することはできない。

本発明が解決しようとする課題は、食品の在庫管理に係る利便性を向上させることが可能なサーバ装置、プログラム及び在庫管理システムを提供することである。

実施の形態のサーバ装置は、管理手段と、第１選定手段と、提供手段と、減算手段とを備える。管理手段は、ユーザを識別するユーザ識別子に関連付けて、食品の在庫数を食品種別毎に管理する。第１選定手段は、前記食品種別毎の在庫数に基づいて、使用する食品の食品種別及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する。提供手段は、前記第１選定手段が選定したレシピ情報を、前記ユーザ識別子に対応するユーザ端末に提供する。減算手段は、前記ユーザ端末から調理対象の前記レシピ情報が指示されると、当該レシピ情報に規定された食品種別の数量に基づき、前記管理手段が管理する当該食品種別の在庫数を減算する。

図１は、実施形態に係る在庫管理システムの構成の一例を示す図である。 図２は、実施形態に係るユーザ端末のハードウェア構成の一例を示すブロック図である。 図３は、実施形態に係る在庫管理サーバのハードウェア構成の一例を示す図である。 図４は、実施形態に係る在庫管理ＤＢのデータ構成の一例を示す図である。 図５は、実施形態に係るユーザ管理ＤＢのデータ構成の一例を示す図である。 図６は、実施形態に係るレシピ管理ＤＢのデータ構成の一例を示す図である。 図７は、実施形態に係るバイヤー管理ＤＢのデータ構成の一例を示す図である。 図８は、実施形態に係るバイヤーサーバのハードウェア構成の一例を示す図である。 図９は、実施形態に係る販売情報マスタのデータ構成の一例を示す図である。 図１０は、実施形態に係る在庫管理システムの機能構成の一例を示す図である。 図１１は、実施形態に係るユーザ端末の表示部に表示される画面の一例を示す図である。 図１２は、実施形態に係るユーザ端末の表示部に表示される画面の他の例を示す図である。 図１３は、実施形態のユーザ端末と在庫管理サーバとで行われる食品登録処理の一例を示すフローチャートである。 図１４は、実施形態のユーザ端末と在庫管理サーバとで行われる食品消費処理の一例を示すフローチャートである。 図１５は、実施形態のユーザ端末と在庫管理サーバとで行われる情報提供処理の一例を示すフローチャートである。 図１６は、実施形態の在庫管理サーバが実行するポイント付与処理の一例を示すフローチャートである。

図１は、実施形態に係る在庫管理システムの構成の一例を示す図である。図１に示すように、在庫管理システム１は、ユーザ端末１０と、在庫管理サーバ２０と、バイヤーサーバ３０とを有する。ユーザ端末１０、在庫管理サーバ２０、及びバイヤーサーバ３０は、インターネットや各種公衆網等のネットワークＮ１を介して通信可能に接続される。なお、ネットワークＮ１に接続されるユーザ端末１０及びバイヤーサーバ３０の台数は、図１の例に限定されないものとする。

ユーザ端末１０は、本システムのユーザが使用する端末装置である。ユーザ端末１０は、タブレット型コンピュータ、スマートフォン等の通信機能を備えた通信端末である。本実施形態において、ユーザ端末１０は、主にユーザ宅で使用される。例えば、ユーザ端末１０は、冷蔵庫ＲＦに着脱自在に構成されてもよい。

在庫管理サーバ２０は、本システムのユーザ宅（冷蔵庫ＲＦ）に存在する食品（食材）の在庫管理を行うサーバ装置である。具体的には、在庫管理サーバ２０は、ユーザ端末１０から送信される各種情報に基づいて、ユーザ宅に存在する食品の数量（在庫数）を管理する。また、在庫管理サーバ２０は、食品の在庫状況等に基づいて、調理候補となるレシピ情報を選定し、当該レシピ情報をユーザ端末１０に提供する。そして、在庫管理サーバ２０は、レシピ情報に基づいて調理が行われたことを検知すると、そのレシピ情報に規定された食品の数量を該当する食品の在庫数から減算する。

また、在庫管理サーバ２０は、選定したレシピ情報や当該レシピ情報で規定された食品等に基づいて、購入候補となる食品を選定する。そして、在庫管理サーバ２０は、選定した食品に関する情報とともに、当該食品を販売するバイヤーに関する情報をユーザ端末１０に提供する。なお、在庫管理サーバ２０は、本システムを運営する企業等に設けられるとするが、これに限らず、ネットワーク接続された複数のサーバ装置が協働することで実現されるクラウドであってもよい。

バイヤーサーバ３０は、例えば商品（食品）を販売する各バイヤー（店舗）の店舗サーバ等である。バイヤーサーバ３０は、自己の店舗で販売する食品の価格等を含んだ販売情報を在庫管理サーバ２０に提供する。

次に、上述した各装置のハードウェア構成について説明する。

まず、ユーザ端末１０について説明する。図２は、ユーザ端末１０のハードウェア構成の一例を示すブロック図である。図２に示すように、ユーザ端末１０は、各種演算やユーザ端末１０の各部を統括的に制御する制御部１１を備える。

制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びＲＴＣ（Real Time Clock）等によって構成されるコンピュータである。ＲＯＭは、各種プログラムやデータを記憶する。ＲＡＭは、各種プログラムを一時的に記憶するとともに、各種データを書き換え自在に記憶する。ＲＴＣは、現在の日時を計時する。

また、制御部１１は、バス等を介して、表示部１２、操作部１３、読取部１４、通信部１５及び記憶部１６等に接続される。

表示部１２は、例えば、液晶ディスプレイ等の表示デバイスである。表示部１２は、制御部１１の制御の下、各種の情報（画面）を表示する。操作部１３は、ユーザが操作入力を行うための各種の操作キーを有する。なお、表示部１２は、タッチパネルを備えてもよい。この場合、タッチパネルは、操作部１３として機能する。

読取部１４は、追加対象の食品から当該食品に関する情報（以下、食品情報）を読み取る読取装置である。ここで、追加対象の食品は、例えば、ユーザが新たに購入した食品、他のユーザから譲り受けた食品等、読取部１４による読み取りが未実施の食品である。

読取部１４は、例えば、カメラ等の撮像装置や、ＲＦＩＤ（Radio Frequency IDentifier）タグを読み取り可能なリーダライタ装置等で実現することができる。読取部１４を撮像装置とする場合、読取部１４は、食品に付されたバーコードや２次元コード等のコードシンボルから、その食品に関する食品情報を読み取る。また、読取部１４を撮像装置とする場合、読取部１４は、食品の外観を撮像し、その撮像画像に含まれた文字列を食品情報として読み取ってもよい。また、読取部１４を撮像装置とする場合、読取１４は、一般物体認識等の技術を用いることで、食品の外観を撮像した撮像画像から食品の種別等を認識し、認識した食品に関する食品情報を取得するようにしてもよい。この場合、食品情報の取得元は特に問わず、食品の購入先となったバイヤーのサーバ装置でもよい。また、読取部１４をリーダライタ装置とする場合、読取部１４は、食品に付されたＲＦＩＤタグから、その食品に関する食品情報を読み取る。なお、食品情報については後述する。

通信部１５は、ネットワークＮ１に接続することが可能な通信インタフェースである。例えば、通信部１５は、ユーザ宅に設けられたルータ等の通信機器を介して、有線又は無線によりネットワークＮ１に接続される。通信部１５は、制御部１１の制御の下、ネットワークＮ１に接続された在庫管理サーバ２０等の外部装置と通信を行う。

記憶部１６は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の補助記憶装置である。記憶部１６は、制御部１１（ＣＰＵ）が実行する各種プログラムを記憶する。また、記憶部１６は、自己のユーザ端末１０を操作（所持）するユーザのユーザＩＤを記憶する。ここで、ユーザＩＤは、各ユーザを識別するためのユーザ識別子である。例えば、ユーザＩＤは、本システムを利用するユーザ毎に発行された固有の会員番号であってもよいし、メールアドレス等の固有情報であってもよい。なお、本実施形態では、ユーザ宅毎に１つのユーザＩＤが割り振られているものとする。

次に、在庫管理サーバ２０について説明する。図３は、在庫管理サーバ２０のハードウェア構成の一例を示す図である。図３に示すように、在庫管理サーバ２０は、各種演算や在庫管理サーバ２０の各部を統括的に制御する制御部２１を備える。

制御部２１は、ＣＰＵ、ＲＯＭ、ＲＡＭ及びＲＴＣ等によって構成されるコンピュータである。ＲＯＭは、各種プログラムやデータを記憶する。ＲＡＭは、各種プログラムを一時的に記憶するとともに、各種データを書き換え自在に記憶する。ＲＴＣは、現在の日時を計時する。

また、制御部２１は、バス等を介して、通信部２２及び記憶部２３等に接続されている。通信部２２は、ネットワークＮ１に接続することが可能な通信インタフェースである。通信部２２は、制御部２１の制御の下、ネットワークＮ１に接続されたユーザ端末１０やバイヤーサーバ３０等の外部装置と通信を行う。

記憶部２３は、例えばＨＤＤやＳＳＤ等の補助記憶装置である。記憶部２３は、制御部２１（ＣＰＵ）が実行する各種プログラムを記憶する。また、記憶部２３は、在庫管理システム１の運用に係る、在庫管理ＤＢ（データベース）２３１、ユーザ管理ＤＢ２３２、レシピ管理ＤＢ２３３、バイヤー管理ＤＢ２３４等を記憶する。

在庫管理ＤＢ２３１は、後述する在庫管理部２０１とともに管理手段の一例として機能する。在庫管理ＤＢ２３１は、各ユーザのユーザ宅に存在する食品の在庫状況を管理するためのデータベースである。在庫管理ＤＢ２３１は、例えば図４に示すデータ構成を有する。

図４は、在庫管理ＤＢ２３１のデータ構成の一例を示す図である。図４に示すように、在庫管理ＤＢ２３１は、各ユーザを識別するユーザＩＤ毎に、食品情報及び在庫数等の項目を関連付けて記憶する。

食品情報は、ユーザ端末１０の読取部１４によって食品から読み取られる情報である。食品情報は、例えば、食品ＩＤ、食品名、数量、賞味期限（消費期限）、バイヤーＩＤ等の項目を有する。ここで、食品ＩＤは、各食品の種別を識別するための食品識別子である。例えば、食品ＩＤは、ＪＡＮ（Japanese Article Number）コード等を用いることができる。食品名は、食品の名称を表す情報であり、数量は、その食品の重量や内容量を示す情報である。賞味期限（消費期限）は、食品の賞味期限や消費期限を示す日時情報である。バイヤーＩＤは、その食品を販売したバイヤー（店舗）を識別するためのバイヤー識別子である。なお、食品情報が有する項目は、図４の例に限らないものとする。例えば、食品情報は、生産者や生産地を示す項目を含んでもよい。

食品情報は、例えば食品ＩＤの単位で管理される。具体的には、同一の食品ＩＤを有する食品情報が複数読み取られた場合には、食品ＩＤ等の共通する項目（食品名）に関連付けて、数量、賞味期限（消費期限）及びバイヤーＩＤ等のその食品に固有の情報が登録される。また、在庫数は、食品ＩＤ毎に関連付けられる情報であり、その食品ＩＤに対応する食品の残量（個数又は重量）に対応する。

ユーザ管理ＤＢ２３２は、各ユーザに関する情報を管理するためのデータベースである。ユーザ管理ＤＢ２３２は、例えば図５に示すデータ構成を有する。

図５は、ユーザ管理ＤＢ２３２のデータ構成の一例を示す図である。図５に示すように、ユーザ管理ＤＢ２３２は、各ユーザのユーザＩＤ毎に、ユーザ情報、購入特性、自作レシピ、累積ポイント等の項目を関連付けて記憶する。

ユーザ情報は、各ユーザが予め設定した自己に関する情報であり、例えば、住所、家族構成、嗜好品情報、アレルギー情報、食費上限、調理時間等の項目を有する。ここで、住所は、ユーザ宅の所在地を示す情報である。家族構成は、ユーザの家族構成を示す情報であり、例えば４人（家族）等の情報が設定される。嗜好品情報は、ユーザの嗜好品を示す情報であり、例えば、レシピ名や食品名等の情報が設定される。アレルギー情報は、食品アレルギーの有無を示す情報であり、アレルギーが有る場合には原因となる食品（アレルゲン）の食品名や食品ＩＤ等が設定される。食費上限には、１食あたりの食費の上限値が設定される。調理時間には、１食分の料理に要する調理時間の目安となる時間数が設定される。

なお、ユーザ情報に設定される内容は、上記の例に限らないものとする。例えば、ユーザ情報には、ユーザの氏名、誕生日等の特別日に関する情報が設定されてもよい。また、ユーザ情報には、１週間や１月等の単位期間あたりの外食率等が設定されてもよい。また、ユーザ情報には、在庫管理サーバ２０から提供される食品（商品）に関する情報のうち、情報提供を所望する分野（特売商品、新商品等）が設定されてもよい。

購入特性は、各ユーザが予め設定した食品の購入に係る特性を示す情報であり、例えば、運搬方法、曜日、天候影響等の項目を有する。ここで、運搬方法には、店舗で購入した食品をユーザ宅に運搬する方法（例えば、自動車、自転車、徒歩、キャリーバック等）が設定される。曜日には、購入頻度の高い曜日が設定される。天候影響には、天候による影響度合いが設定される。例えば、天候影響には、晴れの日は遠方の店舗で購入するが、雨の日は近くの店舗で購入する等が設定される。

自作レシピには、ユーザが作成した料理のレシピ情報又は当該レシピ情報を識別するレシピＩＤが登録される。なお、レシピ情報については後述する。累積ポイントには、ユーザＩＤのユーザに付与されたポイントの累積値が記録される。かかるポイントは、在庫管理システム１のユーザに付与されるサービスポイントであり、例えば、景品との交換に使用したり、店舗での値引きサービス等に利用したりすることができる。

レシピ管理ＤＢ２３３は、レシピ情報を管理するためのデータベースである。レシピ管理ＤＢ２３３は、例えば図６に示すデータ構成を有する。

図６は、レシピ管理ＤＢ２３３のデータ構成の一例を示す図である。図６に示すように、レシピ管理ＤＢ２３３は、レシピＩＤ毎に、レシピ名、調理方法、材料、食費、及び調理時間等の項目を関連付けて記憶する。レシピＩＤは、各レシピ（料理）を識別するための識別子である。レシピ名は、レシピの名称を表す情報である。調理方法は、レシピの調理方法（手順）を示す情報である。

材料には、にレシピに必要な食品に関する情報が規定されている。例えば、材料は、調理に使用する食品の食品ＩＤ、食品名、必要量等の項目を有する。ここで、必要量には、使用する食品の数量が設定される。なお、必要量には、予め定められた単位人数（例えば、１人や２人など）分の調理に必要な食品の数量が設定される。

また、食費には、単位人数分の調理に要する目安となる金額が設定される。調理時間には、単位人数分の調理に要する目安となる時間が設定される。

バイヤー管理ＤＢ２３４は、各バイヤーに関するバイヤー情報を管理するためのデータベースである。バイヤー管理ＤＢ２３４は、例えば図７に示すデータ構成を有する。

図７は、バイヤー管理ＤＢ２３４のデータ構成の一例を示す図である。図７に示すように、バイヤー管理ＤＢ２３４は、バイヤーＩＤ毎に、バイヤー名、住所等の項目を関連付けて記憶する。バイヤーＩＤは、各店舗（バイヤー）を識別するための識別子である。バイヤー名は、店舗の名称を示す情報である。住所は、店舗の所在地を示す情報である。

次に、バイヤーサーバ３０について説明する。図８は、バイヤーサーバ３０のハードウェア構成の一例を示す図である。図８に示すように、バイヤーサーバ３０は、各種演算やバイヤーサーバ３０の各部を統括的に制御する制御部３１を備える。

制御部３１は、ＣＰＵ、ＲＯＭ、ＲＡＭ及びＲＴＣ等によって構成されるコンピュータである。ＲＯＭは、各種プログラムやデータを記憶する。ＲＡＭは、各種プログラムを一時的に記憶するとともに、各種データを書き換え自在に記憶する。ＲＴＣは、現在の日時を計時する。

また、制御部３１は、バス等を介して、通信部３２及び記憶部３３等に接続されている。通信部３２は、ネットワークＮ１に接続することが可能な通信インタフェースである。通信部３２は、制御部３１の制御の下、ネットワークＮ１に接続された在庫管理サーバ２０等の外部装置と通信を行う。

記憶部３３は、例えばＨＤＤやＳＳＤ等の補助記憶装置である。記憶部３３は、制御部３１（ＣＰＵ）が実行する各種プログラムを記憶する。また、記憶部３３は、自装置が置かれた店舗（以下、自店舗ともいう）を識別するバイヤーＩＤを記憶する。また、記憶部３３は、販売情報マスタ３３１等を記憶する。

販売情報マスタ３３１は、自店舗で販売する各商品（食品）に関する販売情報を管理するためのデータベースである。販売情報マスタ３３１は、例えば図９に示すデータ構成を有する。

図９は、販売情報マスタ３３１のデータ構成の一例を示す図である。図９に示すように、販売情報マスタ３３１は、食品ＩＤ毎に、食品名、価格、数量、アレルゲン情報等の項目を関連付けて記憶する。ここで、食品ＩＤ及び食品名は、自店舗で販売する食品の食品ＩＤ、食品名に対応する。価格及び数量は、自店舗で販売する食品の価格、その食品の重量や内容量である。また、アレルゲン情報は、食品に含まれるアレルギー原因物質、食品の生産工程で混入の可能性があるアレルギー原因物質（食品名、食品ＩＤ等）を示す情報である。

次に、上述した各装置の機能構成について説明する。図１０は、在庫管理システム１の機能構成の一例を示す図である。

まず、ユーザ端末１０の機能構成について説明する。図１０に示すように、ユーザ端末１０は、食品情報取得部１０１と、食品情報送信部１０２と、調理レシピ指示部１０３と、インタフェース部１０４とを機能部として備える。かかる機能部は、制御部１１のＣＰＵが、記憶部１６のプログラムを実行することで実行されるソフトウェア構成であってもよいし、専用回路により実現されるハードウェア構成であってもよい。

食品情報取得部１０１は、読取部１４と協働することで、読取部１４が食品から読み取った食品情報を取得する。食品情報送信部１０２は、送信手段の一例である。食品情報送信部１０２は、食品情報取得部１０１が取得した食品情報を、自装置に記憶されたユーザＩＤとともに在庫管理サーバ２０に送信する。

例えば、ユーザ端末１０を操作するユーザは、追加対象の食品を冷蔵庫ＲＦに格納する際に、当該商品の商品情報を読取部１４に読み取らせる。かかる操作に応じて、食品情報取得部１０１は、読取部１４が読み取った食品情報を取得する。食品情報送信部１０２は、食品情報取得部１０１が取得した食品情報をユーザＩＤとともに在庫管理サーバ２０に送信する。在庫管理サーバ２０では、後述する在庫管理部２０１の機能により、読取部１４で読み取られた食品の数量を該当する食品の在庫数に追加する。これにより、冷蔵庫ＲＦに収納した食品の在庫状況が在庫管理サーバ２０で管理されることになる。

調理レシピ指示部１０３は、ユーザが調理したレシピ（レシピ情報）のレシピＩＤを在庫管理サーバ２０に指示する。具体的には、調理レシピ指示部１０３は、後述するインタフェース部１０４を介して、ユーザからレシピの決定又はレシピの調理完了を指示する操作（以下、レシピ決定操作ともいう）を受け付ける。調理レシピ指示部１０３は、レシピ決定操作を受け付けると、そのレシピのレシピＩＤを、何人分の分量を調理したのかを示す人数及びユーザＩＤとともに、在庫管理サーバ２０に送信する。

ここで、調理対象のレシピは、在庫管理サーバ２０から提供（提案）されたレシピであってもよいし、ユーザ管理ＤＢ２３２に登録された、ユーザ自身が作成したレシピであってもよい。また、ネットワークＮ１に接続された第３機関が提供するレシピであってもよい。なお、第３機関が提供するレシピが使用された場合、調理レシピ指示部１０３は、レシピＩＤの代わりに、そのレシピのレシピ情報を在庫管理サーバ２０に送信してもよい。

例えば、ユーザ端末１０を操作するユーザは、操作部１３を介して所望のレシピを選択すると、冷蔵庫ＲＦに収納された食品を用いて調理を行う。なお、レシピを選択する際には、何人分の調理を行うのかを示す人数が、操作部１３を介して入力されるものとする。そして、ユーザは、調理が完了すると、操作部１３を介して調理完了を指示する。かかる操作に応じ、調理レシピ指示部１０３は、選択されたレシピのレシピＩＤ、人数及びユーザＩＤを在庫管理サーバ２０に送信する。これにより、在庫管理サーバ２０では、後述する在庫管理部２０１の機能により、調理により消費された各食品の数量が在庫数から削減されることになる。

インタフェース部１０４は、表示部１２及び操作部１３と協働することで、各種情報の表示（アウトプット）と、ユーザからの入力（インプット）を受け付ける。例えば、インタフェース部１０４は、在庫管理サーバ２０から提供される各種の情報に基づき、調理候補となるレシピに関する情報や、食品購入を支援するための情報を表示する画面を表示部１２に表示させる。

次に、在庫管理サーバ２０の機能構成について説明する。図１０に示すように、在庫管理サーバ２０は、在庫管理部２０１と、情報提供部２０２と、フィードバック処理部２０３と、ポイント付与部２０４とを機能部として備える。かかる機能部は、制御部２１のＣＰＵが、記憶部２３のプログラムを実行することで実行されるソフトウェア構成であってもよいし、専用回路により実現されるハードウェア構成であってもよい。

在庫管理部２０１は、管理手段、受信手段、加算手段及び減算手段の一例である。在庫管理部２０１は、各ユーザ端末１０から送信される情報に基づき、各ユーザ宅の食品の在庫状況を、在庫管理ＤＢ２３１を用いて管理する。具体的には、在庫管理部２０１は、ユーザ端末１０から食品情報とユーザＩＤとの組を受け付けると、そのユーザＩＤに関連付けて食品情報を在庫管理ＤＢ２３１に登録する。また、在庫管理部２０１は、登録した食品情報と同一の食品ＩＤに関連付けられた在庫数に、その食品情報に含まれた数量の値を加算する。

また、在庫管理部２０１は、ユーザ端末１０からレシピＩＤと人数とユーザＩＤとの組を受け付けると、レシピ管理ＤＢ２３３等を参照し、指示されたレシピＩＤの材料に設定された各食品の必要量から、指示された人数分の消費量を算出する。具体的には、在庫管理部２０１は、レシピＩＤの材料に示された食品の必要量に対し人数／単位人数を乗算することで、調理で使用されたその食品の消費量を算出する。そして、在庫管理部２０１は、指示されたユーザＩＤに係るエントリを参照し、レシピＩＤの材料に設定された各食品（食品ＩＤ）の在庫数から、当該食品について算出した消費量の値をそれぞれ減算する。

また、在庫管理部２０１は、第３機関が提供するレシピ情報がユーザ端末１０から送信された場合には、当該レシピ情報に含まれる食品名、必要量及び単位人数等の情報から、各食品の消費量を算出する。そして、在庫管理部２０１は、指示されたユーザＩＤに係るエントリを参照し、レシピＩＤの材料に設定された各食品（食品ＩＤ）の在庫数から、当該食品について算出した消費量の数量をそれぞれ減算する。

なお、在庫数がゼロとなった食品の食品情報については、該当する食品ＩＤのエントリ全体を在庫管理ＤＢ２３１から削除する形態としてもよいし、継続して利用する可能な食品ＩＤや在庫数（ゼロ）等の項目を保持したまま、残りの食品情報を在庫管理ＤＢ２３１から削除する形態としてもよい。

また、在庫数から消費量分の減算を行う場合には、その消費量に応じた数量を、該当する食品の食品情報から減算する形態としてもよい。例えば、在庫管理部２０１は、或る食品（食品ＩＤ）について算出した消費量分の数量を、当該食品ＩＤに関連付けて登録された何れかの食品情報の数量から減算してもよい。この場合、在庫管理部２０１は、賞味（消費）期限が最も早い食品情報から減算することが好ましい。さらには、数量がゼロになった食品情報を在庫管理ＤＢ２３１から削除してもよい。

情報提供部２０２は、提供手段の一例である。情報提供部２０２は、ユーザ端末１０に対し各種の情報を提供する。一例として、情報提供部２０２は、ユーザ端末１０からの要求に応じて、当該ユーザ端末１０に対応するユーザＩＤに関連付けて登録された在庫管理ＤＢ２３１の食品情報や在庫数等をユーザ端末１０に提供する。また、他の例として、情報提供部２０２は、ユーザ端末１０からの要求に応じて、当該ユーザ端末１０に対応するユーザＩＤに関連付けて登録されたユーザ管理ＤＢ２３２の自作レシピ（レシピ情報）等をユーザ端末１０に提供する。なお、情報提供部２０２は、自作レシピを提供する際に、当該自作レシピに含まれる材料と、対応するユーザの食品の在庫状況とを比較することで算出した、不足分の食品とその数量とをあわせて提供してもよい。

また、情報提供部２０２は、図１０に示すように、レシピ提案部２０２１及び購入支援部２０２２等を有する。レシピ提案部２０２１は、第１選定手段の一例であり、調理候補となるレシピの選定に係る処理を実行する。具体的には、情報提供部２０２は、記憶部２３に記憶された各種ＤＢの登録内容に基づいて、レシピ管理ＤＢ２３３等に登録されたレシピの中から、調理候補となるレシピを選定する。なお、レシピの選定方法は上記例に限らず、種々の方法を採用することが可能である。

例えば、レシピ提案部２０２１は、在庫管理ＤＢ２３１に登録された食品の在庫状況及びユーザ管理ＤＢ２３２に登録された家族構成に基づき、家族構成で示された人数分の料理を作成することが可能なレシピＩＤをレシピ管理ＤＢ２３３から選定する。この場合、レシピ提案部２０２１は、材料の全てを在庫分の食品で充足可能なレシピＩＤを選定してもよいし、材料の一部を在庫分の食品で充足可能なレシピＩＤを選定してもよい。

また、例えば、レシピ提案部２０２１は、ユーザ管理ＤＢ２３２に登録された嗜好品情報の内容に基づいて、当該嗜好品情報に設定されたレシピ名や食品名を使用するレシピＩＤをレシピ管理ＤＢ２３３から選定してもよい。また、例えば、レシピ提案部２０２１は、ユーザ管理ＤＢ２３２に登録されたユーザの食費上限や調理時間の条件に基づき、当該条件に該当するレシピＩＤをレシピ管理ＤＢ２３３から選定してもよい。なお、レシピ提案部２０２１は、ユーザ端末１０から送信されたレシピＩＤの履歴に基づき、同一料理のレシピＩＤや類似する料理のレシピＩＤが連続しないよう、選定するレシピＩＤを制限することが好ましい。

また、例えば、レシピ提案部２０２１は、在庫管理ＤＢ２３１に登録された各食品の賞味期限（消費期限）に基づき、期限切れの近い食品を使用するレシピＩＤを優先的に選定してもよい。また、例えば、レシピ提案部２０２１は、ユーザ管理ＤＢ２３２に登録されたアレルギー情報に基づき、当該アレルギー情報に設定された食品を使用しないレシピＩＤを優先的に選定してもよい。

購入支援部２０２２は、第２選定手段及び第３選定手段の一例である。購入支援部２０２２は、購入候補となる食品の選定と、選定した食品を購入することが可能なバイヤーの選定に係る処理を実行する。ここで、食品及びバイヤーの選定方法は特に問わず、種々の方法を採用することが可能である。

例えば、購入支援部２０２２は、レシピ提案部２０２１が選定したレシピＩＤの家族構成分の材料と、在庫管理ＤＢ２３１に登録された食品の在庫数とを比較し、調理に必要な材料（食品）を在庫分で充足することが可能か否かを判定する。そして、調理に必要な材料（食品）を在庫分で充足できない場合、購入支援部２０２２は、不足分の食品の食品ＩＤを購入候補として選定する。この場合、購入支援部２０２２は、各バイヤーサーバ３０の販売情報マスタ３３１を参照し、購入候補の食品ＩＤに関する販売情報が登録されているか否かを判定する。そして、購入支援部２０２２は、購入候補の食品ＩＤに関する販売情報が登録されたバイヤーサーバ３０のバイヤーを選定し、そのバイヤーサーバ３０から販売情報を取得する。

また、購入支援部２０２２は、上述の選定条件とともに、ユーザ管理ＤＢ２３２に登録されたユーザ情報や購入特性、バイヤー管理ＤＢ２３４に登録されたバイヤー情報等に基づいてバイヤーを選定してもよい。例えば、購入支援部２０２２は、ユーザ情報に設定された住所と、バイヤー情報に設定された各バイヤー（店舗）の住所とに基づいて、ユーザ宅から所定距離以内に存在するバイヤーを選定してもよい。また、例えば、購入支援部２０２２は、購入特性に設定された運搬方法に基づき、ユーザの住所から運搬方法に応じた距離の範囲内に存在するバイヤーを選定してもよい。また、例えば、購入支援部２０２２は、購入特性に設定された曜日や天候と、本日の曜日や天候とに応じて、選定するバイヤーを切り替えてもよい。この場合、購入支援部２０２２は、気象庁等の第３機関が提供する天候情報を用いてもよい。

また、購入支援部２０２２が購入候補として選定する食品は、レシピ提案部２０２１が選定したレシピＩＤに規定された食品に限らず、他の食品であってもよい。例えば、購入支援部２０２２は、在庫管理ＤＢ２３１に登録された各食品の在庫状況に基づいて、在庫数が閾値未満となった食品を購入候補に設定してもよい。また、例えば、購入支援部２０２２は、各ユーザが購入する食品の購入傾向に基づき、同時購入される傾向の高い食品を購入候補に選定してもよい。また、例えば、購入支援部２０２２は、定期的に購入（追加）される食品の購入サイクルに基づいて、購入候補の食品を選定してもよい。また、例えば、購入支援部２０２２は、各バイヤーサーバ３０から提供される情報等に基づき、特別に安い値段で販売されている特売商品や新商品の食品を購入候補に選定してもよい。この場合、購入支援部２０２２は、ユーザ情報に設定された、情報提供を所望する分野に応じた食品を選定することが好ましい。

なお、購入支援部２０２２は、ユーザ管理ＤＢ２３２のユーザ情報にアレルギー情報が設定されている場合、設定された食品を購入候補としないよう排他制御することが好ましい。具体的には、購入支援部２０２２は、アレルギー情報の設定内容が、購入候補として選定した食品、又は購入候補の食品の販売情報に含まれたアレルゲン情報の内容に該当するか否かを判定する。ここで、アレルギー情報の設定内容に該当した場合、購入支援部２０２２は、選定した購入候補を破棄し、代替の食品等の他の食品を購入候補に選定する。

情報提供部２０２は、上述したレシピ提案部２０２１及び購入支援部２０２２の処理結果に基づき、調理候補のレシピのレシピ情報や、購入候補の食品の販売情報、当該食品を販売するバイヤーに関する情報等を含んだ提案情報をユーザ端末１０に提供する。ユーザ端末１０では、在庫管理サーバ２０から提供された提案情報を受信すると、インタフェース部１０４の機能により、提案情報の内容を表す画面が表示部１２に表示される。

図１１は、ユーザ端末１０の表示部１２に表示される画面の一例を示す図である。ここで画面Ｇ１は、提案情報に基づく画面の一例であり、第１表示領域Ｇ１１と、第２表示領域Ｇ１２とを有する。

ここで、第１表示領域Ｇ１１は、現在日時、天候、気温等の情報を表示するための領域である。第１表示領域Ｇ１１に表示される情報は、ＲＴＣや気象庁等の外部サーバからユーザ端末１０によって取得される。

第２表示領域Ｇ１２は、在庫管理サーバ２０から提供された提供情報の内容を表示するための領域である。図１１では、レシピ提案部２０２１が選定したレシピ「料理ＡＡＡ」に関する情報を第２表示領域Ｇ１２に表示した例を示している。具体的には、ユーザ情報の家族構成に設定された２人前分の材料（食品）の分量が、在庫管理ＤＢ２３１に登録された食品（食品Ａ、食品Ｂ）と、不足分の食品（食品Ｃ）とに分けて表示されている。

また、図１１では、購入支援部２０２２が取得した食品Ｃの販売情報に基づく内容を第２表示領域Ｇ１２に表示した例を示している。具体的には、ユーザ情報や購入特性等に基づき選定されたバイヤー名「ＸＸスーパー」と、そのバイヤーのバイヤーサーバ３０から取得された販売情報に基づく内容（特売情報）とが表示されている。この場合、インタフェース部１０４は、「特売情報」が選択されたことを条件に、食品Ｃの価格等の詳細な販売情報を表示させてもよい。

また、第２表示領域Ｇ１２には、レシピ参照を指示するボタンＢ１１が表示される。インタフェース部１０４は、ボタンＢ１１の操作を受け付けると、「料理ＡＡＡ」の調理方法等の詳細なレシピ情報を表示させる。

また、画面Ｇ１には、調理対象のレシピの決定を指示するボタンＢ１２と、在庫食材の表示を指示するボタンＢ１３と、自作レシピの表示を指示するボタンＢ１４とが表示される。

インタフェース部１０４は、ボタンＢ１２の操作を受け付けると、第２表示領域Ｇ１２に表示されたレシピのレシピＩＤを調理対象に設定する。なお、インタフェース部１０４は、ボタンＢ１２の操作を、調理完了の指示操作として受け付ける構成としてもよい。

また、インタフェース部１０４は、ボタンＢ１３の操作を受け付けると、在庫管理サーバ２０の情報提供部２０２と協働することで、在庫管理ＤＢ２３１に登録された食品の在庫状況を表示部１２に表示させる。具体的には、インタフェース部１０４はボタンＢ１３の操作を受け付けると、自装置のユーザＩＤとともに、在庫状況を要求する情報を在庫管理サーバ２０に送信する。在庫管理サーバ２０の情報提供部２０２は、ユーザ端末１０から在庫状況が要求されると、そのユーザＩＤに関連付けて在庫管理ＤＢ２３１に記憶された各食品の食品情報及び在庫数を読み出し、要求元のユーザ端末１０に提供する。そして、インタフェース部１０４は、取得した各食品の食品情報及び在庫数に基づき在庫状況を表す画面を表示させる。

また、インタフェース部１０４は、ボタンＢ１４の操作を受け付けると、在庫管理サーバ２０の情報提供部２０２と協働することで、ユーザ管理ＤＢ２３２に登録された自作レシピを表示部１２に表示させる。具体的には、インタフェース部１０４は、ボタンＢ１４の操作を受け付けると、自装置のユーザＩＤとともに、自作レシピを要求する情報を在庫管理サーバ２０に送信する。在庫管理サーバ２０の情報提供部２０２は、ユーザ端末１０から自作レシピが要求されると、そのユーザＩＤに関連付けてユーザ管理ＤＢ２３２に記憶された各自作レシピ（レシピ情報）を読み出し、要求元のユーザ端末１０に提供する。そして、インタフェース部１０４は、取得したレシピ情報に基づき、自作レシピを選択可能な画面を表示させる。

ここで、図１２は、ユーザ端末１０の表示部１２に表示される画面の他の例を示す図である。ここで画面Ｇ２は、図１１に示したボタンＢ１４の操作に応じて表示される自作レシピの選択画面の一例である。

図１２に示すように、画面Ｇ２は、第１表示領域Ｇ２１と第２表示領域Ｇ２２とを有する。ここで、第１表示領域Ｇ２１は、上述した第１表示領域Ｇ１１と同様の表示領域いである。また、第２表示領域Ｇ２２は、自作レシピの選択画面に対応する。

図１２では、自作レシピとして予め登録された「料理ＢＢＢ」と「料理ＣＣＣ」とのレシピを第２表示領域Ｇ２２に表示した例を示している。ここで、各レシピには、調理対象のレシピの決定を指示するボタンＢ２１（Ｂ２１ａ、Ｂ２１ｂ）が対応付けて表示される。

インタフェース部１０４は、何れか一つのボタンＢ２１の操作を受け付けると、上述したボタンＢ１２と同様に、操作対象のボタンＢ２１に対応するレシピのレシピＩＤを調理対象に設定する。なお、図１２では、「料理ＣＣＣ」が調理対象に選択された例を示しており、不足分の材料（食品Ｄ）の数量を示す情報を第３表示領域Ｇ２３に表示した例を示している。

このように、在庫管理システム１では、在庫管理サーバ２０から提供される提供情報に基づき、調理候補となるレシピをユーザ端末１０の表示部１２に表示させる。これにより、ユーザは、冷蔵庫ＲＦ内に収納された食品の在庫状況を意識しなくとも、在庫状況に基づき選定されたレシピを調理対象とすることができる。したがって、在庫管理システム１では、食品の在庫管理に係る利便性を向上させるとともに、レシピ決定に係るユーザの利便性を向上させることができる。

図１０に戻り、更に在庫管理サーバ２０は、フィードバック処理部２０３と、ポイント付与部２０４とを備える。フィードバック処理部２０３は、ユーザ端末１０との遣り取りで得られた各種の分析結果をバイヤーサーバ３０に提供するための機能部である。

例えば、フィードバック処理部２０３は、所定期間中に各ユーザのユーザ端末１０から送信された食品情報に基づいて、当該期間中に購入された食品の傾向を、当該ユーザの住ユーザ宅が存在する地域毎に分析する。そして、フィードバック処理部２０３は、バイヤー管理ＤＢ２３４に基づいて、地域毎に分析した食品の購入傾向を、当該地域に対応する店舗のバイヤーサーバ３０に提供する。これにより、バイヤーサーバ３０では、自己の店舗が存在する地域での食品の購入傾向を得ることができるため、販促活動等に利用することができる。

なお、フィードバック処理部２０３が提供する情報は上記例に限定されないものとする。例えば、フィードバック処理部２０３は、各ユーザのユーザ情報や購入特性の傾向を地域毎に分析し、その分析結果を当該地域に対応するバイヤーサーバ３０に提供してもよい。

また、フィードバック処理部２０３は、在庫管理ＤＢ２３１やユーザ管理ＤＢ２３２に収納された各ユーザに関する情報をバイヤーサーバ３０に提供してもよい。この場合、例えば、各ユーザのユーザ情報に情報提供の可否を示す項目を設け、フィードバック処理部２０３は、情報提供「可」が設定されたユーザのみを、情報提供の対象とすることが好ましい。

ポイント付与部２０４は、ユーザに対しポイント付与を行う機能部である。具体的には、ポイント付与部２０４は、該当するユーザのユーザＩＤに関連付けられたユーザ管理ＤＢ２３２の累積ポイントに対し、付与ポイントの値を加算することで、ポイントの付与を行う。

なお、ポイント付与の条件やポイントの付与率は、特に問わず、任意に設定することが可能である。例えば、ユーザの行動が所定の条件を満たした場合に、当該ユーザにポイントを付与するように設定してもよい。一例として、ポイント付与部２０４は、情報提供部２０２が提案情報で提供（提案）した購入候補の食品が、当該販売情報で指示したバイヤーの店舗で購入されたことを条件に、その食品の価格に応じたポイント数を付与してもよい。この場合、ポイント付与部２０４は、ユーザ端末１０に提供した提案情報に含まれる購入候補の食品の食品ＩＤ及びバイヤーＩＤの組と、その提案情報の提供後、ユーザ端末１０から送信される食品情報の食品ＩＤ及びバイヤーＩＤの組とを比較する。そして、ポイント付与部２０４は、食品ＩＤ及びバイヤーＩＤの組が一致したことを条件に、提案情報に基づき食品が購入されたと判断し、ユーザ端末１０のユーザにポイントの付与を行う。

このように、在庫管理サーバ２０では、ユーザの購買行動に応じて当該ユーザにポイントを付与することができる。したがって、在庫管理システム１は、食品購入に係るユーザの動機付けを高めることができるとともに、在庫管理システム１に参加したバイヤーの販促活動を支援することができる。

なお、ポイント付与の条件は上記例に限らないものとする。例えば、ポイント付与部２０４は、在庫管理ＤＢ２３１やユーザ管理ＤＢ２３２に格納されたユーザに関する情報を、フィードバック処理部２０３の機能によりバイヤーサーバ３０に提供する代償として、ユーザにポイントを付与する構成としてもよい。

次に、バイヤーサーバ３０の機能構成について説明する。図１０に示すように、バイヤーサーバ３０は、販売情報提供部３０１と、情報受付部３０２とを機能部として備える。かかる機能部は、制御部３１のＣＰＵが、記憶部３３のプログラムを実行することで実行されるソフトウェア構成であってもよいし、専用回路により実現されるハードウェア構成であってもよい。

販売情報提供部３０１は、在庫管理サーバ２０に対し、記憶部３３に記憶されたバイヤーＩＤ及び販売情報マスタ３３１を参照可能に提供する。なお、販売情報提供部３０１は、在庫管理サーバ２０から指定された食品ＩＤの販売情報を販売情報マスタ３３１から読み出し、在庫管理サーバ２０に提供してもよい。

情報受付部３０２は、在庫管理サーバ２０から提供されたフィードバック情報等を受け付ける。例えば、情報受付部３０２は、在庫管理サーバ２０から提供されたフィードバック情報を記憶部３３等に記憶したりする。

以下、上述した在庫管理システム１の動作例について説明する。

まず、図１３を参照して、ユーザ端末１０と在庫管理サーバ２０とで行われる食品登録処理の手順について説明する。図１３は、ユーザ端末１０と在庫管理サーバ２０とで行われる食品登録処理の一例を示すフローチャートである。

ユーザ端末１０の食品情報取得部１０１は、操作部１３等を介して食品の読み取りが指示されると、読取部１４を動作させる。この状態で、読み取り対象の食品が読取部１４に近付けられると、食品情報取得部１０１は、読取部１４が食品から読み取った食品情報を取得する（ステップＳ１１）。次いで、食品情報送信部１０２は、食品情報取得部１０１が取得した食品情報を、ユーザＩＤとともに在庫管理サーバ２０に送信する（ステップＳ１２）。

一方、在庫管理サーバ２０では、食品情報及びユーザＩＤの組が受信されると（ステップＳ２１）、在庫管理部２０１は、受信した食品情報を同時に受信したユーザＩＤに関連付けて在庫管理ＤＢ２３１に登録する（ステップＳ２２）。そして、在庫管理部２０１は、ステップＳ２２で登録した食品情報に含まれる数量を、当該食品情報に含まれる食品ＩＤの在庫数に加算する（ステップＳ２３）。

上述の処理により、在庫管理サーバ２０では、読取部１４で読み取られた食品の食品情報が在庫管理ＤＢ２３１に登録されるとともに、その食品の数量が在庫数に加算される。例えばバイヤーで購入した食品を冷蔵庫ＲＦに収納する際に、食品毎に食品情報の読み取りを行うことで、冷蔵庫ＲＦに収納された各食品の食品情報が在庫管理ＤＢ２３１に登録されることになる。

次に、図１４を参照して、ユーザ端末１０と在庫管理サーバ２０とで行われる食品消費処理の手順について説明する。図１４は、ユーザ端末１０と在庫管理サーバ２０とで行われる食品消費処理の一例を示すフローチャートである。なお、本処理の前提として、調理対象のレシピを決定するための画面（例えば、図１１）が表示部１２に表示されているものとする。

ユーザ端末１０の調理レシピ指示部１０３は、操作部１３等を介してレシピ決定操作を受け付けると（ステップＳ３１）、対応するレシピのレシピＩＤを、人数及びユーザＩＤとともに在庫管理サーバ２０に送信する（ステップＳ３２）。

一方、在庫管理サーバ２０では、レシピＩＤ、人数及びユーザＩＤの組が受信されると（ステップＳ４１）、在庫管理部２０１は、レシピ管理ＤＢ２３３を参照し、レシピＩＤに関連付けられた各材料（食品）の人数分の数量（消費量）を算出する（ステップＳ４２）。次いで、在庫管理部２０１は、算出した各食品の数量を、ユーザＩＤに関連付けて在庫管理ＤＢ２３１に記憶された該当する食品の在庫数から減算する（ステップＳ４３）。

上述の処理により、在庫管理サーバ２０では、レシピ情報に基づき調理された各食品の消費量が、在庫管理ＤＢ２３１の在庫数から削減される。これにより、ユーザ端末１０のユーザは、調理したレシピを指示するだけで、その調理に使用された各食品の消費量を在庫管理ＤＢ２３１が管理する該当する食品の在庫数から減らすことができる。

次に、図１５を参照して、ユーザ端末１０と在庫管理サーバ２０とで行われる情報提供処理の手順について説明する。図１５は、ユーザ端末１０と在庫管理サーバ２０とで行われる情報提供処理の一例を示すフローチャートである。

まず、在庫管理サーバ２０のレシピ提案部２０２１は、在庫管理ＤＢ２３１及びユーザ管理ＤＢ２３２に記憶された各ユーザの情報に基づき、調理候補となるレシピをレシピ管理ＤＢ２３３からユーザ毎に選定する（ステップＳ５１）。ここで、レシピ提案部２０２１がステップＳ５１を実行するタイミングは特に問わず、例えば、予め定められた時刻に実行するように設定してもよい。

続いて、購入支援部２０２２は、ステップＳ５１で選定されたレシピの各材料（食品）及びその数量と、在庫管理ＤＢ２３１に記憶された該当する食品の在庫数とに基づいて、不足分の食品をユーザ毎に特定（選定）する（ステップＳ５２）。

続いて、購入支援部２０２２は、ユーザ管理ＤＢ２３２に記憶された各ユーザのユーザ情報及び購入特性に基づいて、バイヤー管理ＤＢ２３４に記憶されたバイヤーの中から、販売情報の取得先となるバイヤーをユーザ毎に選定する（ステップＳ５３）。次いで、購入支援部２０２２は、選定したバイヤーのバイヤーサーバ３０から、ステップＳ５２で特定した食品の販売情報を取得する（ステップＳ５４）。

続いて、情報提供部２０２は、レシピ提案部２０２１及び購入支援部２０２２の処理結果に基づき、調理候補のレシピのレシピ情報や購入候補の食品の販売情報等を含んだ提案情報を、各ユーザのユーザ端末１０に送信する（ステップＳ５５）。

一方、ユーザ端末１０では、提案情報が受信されると（ステップＳ６１）、インタフェース部１０４は、その提案情報に基づく画面を表示部１２に表示させる（ステップＳ６２）。

上述の処理により、ユーザ端末１０では、レシピ提案部２０２１が選定したレシピ情報や、購入支援部２０２２が選定した食品の販売情報が表示部１２に表示されることになる。これにより、ユーザ端末１０のユーザは、表示部１２に表示されたレシピ情報に基づき、調理対象とするレシピを容易に選択することができる。また、ユーザ端末１０のユーザは、表示部１２に表示された販売情報に基づき、不足分の商品を購入可能なバイヤーやその商品の価格等を確認することができる。

次に、図１６を参照して、在庫管理サーバ２０が実行するポイント付与処理の手順について説明する。図１６は、在庫管理サーバ２０が実行するポイント付与処理の一例を示すフローチャートである。なお、本処理は、図１３で説明した在庫管理サーバ２０のバックグラウンドで実行される処理である。

まず、在庫管理サーバ２０では、ユーザ端末１０から送信された食品情報とユーザＩＤとの組を受信する（ステップＳ７１）。ポイント付与部２０４は、ユーザ端末１０から送信された食品情報が、提案情報に基づき購入された食品か否かを判定する（ステップＳ７２）。具体的には、ポイント付与部２０４は、情報提供部２０２が当該ユーザＩＤのユーザ端末１０に提供した提案情報の食品ＩＤ及びバイヤーＩＤが、ユーザ端末１０から送信された食品情報に含まれる場合、提案情報に基づき購入された食品と判定する。

ここで、提案情報に基づき購入された食品と判定した場合（ステップＳ７２；Ｙｅｓ）、ポイント付与部２０４は、その食品の購入金額に応じたポイントを、該当するユーザのユーザＩＤに付与する（ステップＳ７３）。また、提案情報に基づき購入された食品でない場合には、ポイント付与部２０４は、ポイントを付与することなく処理を終了する。

上述の処理により、在庫管理サーバ２０では、提案情報に基づいて行ったユーザの購買行動に応じてポイントを付与することができる。したがって、在庫管理サーバ２０は、ユーザ端末１０のユーザに対し、食品購入に係る動機付けを高めることができる。また、在庫管理サーバ２０は、在庫管理システム１に参加したバイヤーの販促活動を支援することができる。

以上のように、在庫管理サーバ２０は、ユーザを識別するユーザＩＤに関連付けて、ユーザ宅（冷蔵庫ＲＦ）に存在する食品の在庫数を食品ＩＤ毎に管理する。また、在庫管理サーバ２０は、食品ＩＤ毎の在庫数に基づいて、使用する食品の食品ＩＤ及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する。また、在庫管理サーバ２０は、選定したレシピ情報を、ユーザＩＤに対応するユーザ端末１０に提供し、当該ユーザ端末１０から調理対象のレシピ情報が指示されると、当該レシピ情報に規定された食品ＩＤの数量に基づき、在庫管理ＤＢ２３１に記憶された当該食品ＩＤの在庫数を減算する。

これにより、在庫管理システム１（在庫管理サーバ２０）は、調理によって消費された食品の数量（分量）を、当該食品の在庫数から減算することができるため、残りの在庫数（内容量）を管理することができる。例えば、購入時の内容量が６個の食品（例えば６個パックの卵）を２個分使用したような場合、本実施形態の在庫管理システム１では、残りの内容量４個を在庫数として管理することができるため、食品の在庫管理に係る利便性を向上させることができる。

また、ユーザ端末１０のユーザは、冷蔵庫ＲＦに収納された食品の在庫状況を意識することなく、在庫状況に基づき選定されたレシピを調理対象とすることができるため、食品の在庫管理に係る利便性とともに、レシピ決定に係るユーザの利便性を向上させることができる。

また、在庫管理サーバ２０は、ユーザ端末１０から食品情報が送信されると、その食品情報に含まれた食品ＩＤの数量を、ユーザ端末１０に対応するユーザＩＤに関連付けて記憶された当該食品ＩＤの在庫数に加算する。これより、在庫管理システム１では、食品の追加登録を容易に行うことができるため、食品の在庫管理に係る利便性を向上させることができる。

また、在庫管理サーバ２０は、調理候補として選定したレシピ情報で使用する食品ＩＤに基づいて購入候補の食品ＩＤを選定し、選定した食品ＩＤの販売情報と当該食品ＩＤの食品を販売するバイヤーとに関する情報とをユーザ端末１０に提供する。これにより、在庫管理システム１では、購入候補の食品の販売価格やその購入先をユーザ端末１０に提供することができるため、ユーザに対し食品の購入支援を行うことができる。

また、在庫管理サーバ２０は、予め設定されたユーザの購入特性等に基づいて、複数のバイヤーの中から購入候補の食品を販売するバイヤーを選定し、選定したバイヤーに関する情報を、購入候補の食品の販売情報とともにユーザ端末１０に提供する。これにより、在庫管理システム１では、各ユーザの購入特性に応じた購入先をユーザ端末１０に提供することができるため、ユーザに対する食品の購入支援をより効率的に行うことができる。

なお、上述の実施形態では、ユーザ端末１０を冷蔵庫ＲＦと別体としたが、冷蔵庫ＲＦと一体的に構成されてもよい。この場合、ユーザ端末１０は、所謂インテリジェント冷蔵庫としてもよく、冷蔵庫ＲＦに収納された食品のＲＦＩＤタグから自動で食品情報を読み取る構成としてもよい。

また、上述の実施形態では、冷蔵庫ＲＦに収納された食品の在庫管理を行う形態を説明したが、食品を収納する場所はこれに限定されるものではない。例えば、食品を収納する場所は、食品収納庫やワインセラー等であってもよい。更には、ユーザ宅全体を、食品を収納する場所としてもよく、この場合ユーザ宅に存在する食品の在庫管理を行うことができる。

以上、本発明の実施形態を説明したが、上記実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。上記実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更、追加、組合せ等を行うことができる。また、上記実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

なお、上記実施形態の各装置で実行されるプログラムは、各装置が備える記憶媒体（ＲＯＭ又は記憶部）に予め組み込んで提供するが、これに限らないものとする。例えば、プログラムは、インストール可能な形式又は実行可能な形式のファイルで、コンピュータで読み取り可能な記録媒体に記録して提供してもよい。係る記憶媒体は、例えばＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等が挙げられる。更に、記憶媒体は、コンピュータ或いは組み込みシステムと独立した媒体に限らないものとする。例えば、記憶媒体は、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードすることで、記憶又は一時記憶した記憶媒体も含まれる。

また、上記各実施形態の各装置で実行されるプログラムは、インターネット等のネットワーク経由で提供又は配布する構成としてもよい。

１ 在庫管理システム
１０ ユーザ端末
２０ 在庫管理サーバ
３０ バイヤーサーバ
１０１ 食品情報取得部
１０２ 食品情報送信部
１０３ 調理レシピ指示部
２０１ 在庫管理部
２０２ 情報提供部
２０２１ レシピ提案部
２０２２ 購入支援部
２０３ フィードバック処理部
２０４ ポイント付与部
３０１ 販売情報提供部
３０２ 情報受付部

特開２０１１−２０３９３２号公報

Claims (6)

1. ユーザを識別するユーザ識別子に関連付けて、食品の在庫数を食品種別毎に管理する管理手段と、
   前記食品種別毎の在庫数に基づいて、使用する食品の食品種別及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する第１選定手段と、
   前記第１選定手段が選定したレシピ情報を、前記ユーザ識別子に対応するユーザ端末に提供する提供手段と、
   前記ユーザ端末から調理対象の前記レシピ情報が指示されると、当該レシピ情報に規定された食品種別の数量に基づき、前記管理手段が管理する当該食品種別の在庫数を減算する減算手段と、
   を備えるサーバ装置。
2. 食品の食品種別及び数量を含んだ食品情報を、前記ユーザ端末から受信する受信手段と、
   前記食品情報に含まれる前記食品種別の数量を、前記ユーザ端末に対応する前記ユーザ識別子に関連付けて管理された、当該食品種別の在庫数に加算する加算手段と、
   を更に備える請求項１に記載のサーバ装置。
3. 前記第１選定手段が選定した前記レシピ情報で使用する食品の食品種別に基づいて、購入候補の食品種別を選定する第２選定手段を更に備え、
   前記提供手段は、前記第２選定手段が選定した前記食品種別と、当該食品種別の食品を販売するバイヤーとに関する情報を、前記ユーザ端末に提供する請求項１又は２に記載のサーバ装置。
4. 前記ユーザ識別子に対応するユーザの食品購入に係る特性に基づいて、複数のバイヤーの中から、前記第２選定手段が選定した前記食品種別の食品を販売するバイヤーを選定する第３選定手段を更に備え、
   前記提供手段は、前記第２選定手段が選定した前記食品種別と、前記第３選定手段が選定した前記バイヤーとに関する情報を、前記ユーザ端末に提供する請求項３に記載のサーバ装置。
5. サーバ装置のコンピュータを、
   ユーザを識別するユーザ識別子に関連付けて、食品の在庫数を食品種別毎に管理する管理手段と、
   前記管理手段が管理する前記食品種別毎の在庫数に基づいて、使用する食品の食品種別及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する第１選定手段と、
   前記第１選定手段が選定したレシピ情報を、前記ユーザ識別子に対応するユーザ端末に提供する提供手段と、
   前記ユーザ端末から調理対象の前記レシピ情報が指示されると、当該レシピ情報に規定された食品種別の数量に基づき、前記管理手段が管理する当該食品種別の在庫数を減算する減算手段と、
   して機能させるためのプログラム。
6. ユーザ端末とサーバ装置とを有する在庫管理システムであって、
   前記ユーザ端末は、
   食品の食品種別及び数量を含む食品情報を前記サーバ装置に送信する送信手段を備え、
   前記サーバ装置は、
   ユーザを識別するユーザ識別子に関連付けて、食品の在庫数を食品種別毎に管理する管理手段と、
   前記ユーザ端末から前記食品情報を受信する受信手段と、
   前記受信手段が受信した前記食品情報に含まれる前記食品種別の数量を、前記ユーザ端末に対応する前記ユーザ識別子に関連付けて管理された、当該食品種別の在庫数に加算する加算手段と、
   前記管理手段が管理する前記食品種別毎の在庫数に基づいて、使用する食品の食品種別及び数量が規定された複数のレシピ情報の中から、調理候補のレシピ情報を選定する第１選定手段と、
   前記第１選定手段が選定したレシピ情報を前記ユーザ端末に提供する提供手段と、
   前記ユーザ端末から調理対象の前記レシピ情報が指示されると、当該レシピ情報に規定された食品種別の数量に基づき、前記管理手段が管理する当該食品種別の在庫数を減算する減算手段と、
   を備える在庫管理システム。

Images