JP2021018633A - システム - Google Patents

Abstract

【課題】 ユーザが商品の在庫リストを確認し、ある商品の在庫が少なければユーザはその商品を追加で購入する必要があると判断できる。しかしながら、ユーザが在庫リストを確認することを忘れていれば、商品の追加の購入が必要であるとユーザは気付くことができなかった。【解決手段】 ユーザは、携帯端末１００を用いて商品の識別情報を読み取る。サーバ２００は、携帯端末１００の読み取り状況に基づいて商品の需要を予測し、予測の結果に従って商品の購入をユーザに促す。【選択図】 図６

Description

本発明は、商品の購入をユーザに促すシステムに関する。

特許文献１には、携帯端末を使って冷蔵庫に保存されている食材の在庫を管理し、更に消費期限日が近い食材を使った献立をユーザに提案するシステムが開示されている。

また、食材等の商品の在庫を示す在庫リストを用いることで、ユーザは商品の在庫を把握することができる。ユーザが在庫リストを確認した結果、ある商品の在庫が少なければ、ユーザはその商品を追加で購入する必要があると判断できる。

特開２００８−０８４１０２号公報

しかしながら従来のシステムの場合、商品の追加の購入が必要であるとユーザが気付くには、ユーザ自身が在庫リストを確認する必要があった。言い換えれば、ユーザが在庫リストを確認することを忘れていれば、商品の追加の購入が必要であるとユーザは気付くことができなかった。

そこで本発明では、商品の追加の購入が必要であることをユーザに気付かせることができる仕組みを提供することを目的とする。

上述した課題を解決するために、本発明が提供するシステムは、商品の識別情報を読み取る読み取り手段と、読み取った識別情報に基づいて、商品に関する処理を実行する処理手段と、読み取り手段による読み取り状況に基づいて商品の需要を予測し、予測の結果に従って商品の購入をユーザに促す通知手段とを備えることを特徴とする。また、本発明が提供するシステムは、商品の識別情報を読み取る読み取り手段と、読み取った識別情報に基づいて、商品に関する処理を実行する処理手段と、商品を保存する保存庫から得られた商品の重量を示す重量情報に基づいて、商品の購入をユーザに通知手段とを備えることを特徴とする。

本発明によれば、商品の追加の購入が必要であることをユーザに気付かせることができる。

携帯端末１００の構成を示す図である。 サーバ２００の構成を示す図である。 携帯端末１００が実行する処理を示すフローチャートである。 サーバ２００が実行する処理を示すフローチャートである。 食材データベース５００を示す図である。 サーバ２００が実行する処理を示すフローチャートである。 通知イベントデータベース７００を示す図である。 サーバ２００が実行する処理を示すフローチャートである。 携帯端末１００が実行する処理を示すフローチャートである。 冷蔵庫１０００の構成を示す図である。 重量管理データベース１１００を示す図である。 冷蔵庫１０００が実行する処理を示すフローチャートである。 サーバ２００が実行する処理を示すフローチャートである。

以下、本発明の実施形態について、図面を用いて説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
（実施形態１）
本実施形態のシステムは、ユーザが所有する携帯端末１００と、インターネット等のネットワーク上のサーバ２００とで構成される。ユーザは、携帯端末１００のカメラを用いて、食材に付加されているバーコードやＱＲコード（登録商標）のようなコードを読み取る。サーバ２００は、携帯端末１００による読み取り状況に基づいて食材の需要を予測し、予測の結果に従って商品の購入をユーザに促す。以下、本実施形態について詳しく説明する。

図１は携帯端末１００の構成を示す図である。携帯端末１００は、例えばスマートフォンやタブレット端末であり、情報機器の一例である。制御部１０１は携帯端末１００の動作を制御する。制御部１０１はプロセッサを少なくとも有し、このプロセッサが後述するメモリ１０２に記憶されている制御プログラムを読みだして実行することで、制御部１０１が携帯端末１００の動作を制御する。メモリ１０２は制御プログラム等の各種データを記憶する不揮発性の記憶媒体であり、例えばフラッシュメモリである。表示部１０３はタッチパネルであり、画像や動画等の情報を表示し、また、タッチ操作によってユーザから指示を受け付ける。通信部１０４は、携帯端末１００が外部装置と通信するためのインタフェースである。通信部１０４は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ等の無線ＬＡＮ規格に基づく無線通信、第４世代移動通信システム（通称４Ｇ）や第５世代移動通信システム（通称５Ｇ）に基づく無線通信を実行する。カメラ１０５は、撮影機能と、バーコードやＱＲコードのようなコードを読み取る読み取り機能とを有する。

図２はサーバ２００の構成を示す図である。制御部２０１はサーバ２００の動作を制御する。制御部２０１はプロセッサを少なくとも有し、このプロセッサが後述するメモリ２０２に記憶されている制御プログラムを読みだして実行することで、制御部２０１がサーバ２００の動作を制御する。メモリ２０２は制御プログラムや後述する食材データベース５００等の各種データを記憶する不揮発性の記憶媒体であり、例えばＨＤＤ（ハードディスクドライブ）である。通信部２０３は、サーバ２００が外部装置と通信するためのインタフェースである。通信部２０３は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ等の無線ＬＡＮ規格に基づく無線通信や、イーサネット（登録商標）に基づく有線ＬＡＮ通信を実行する。

次に図３のフローチャートを用いて、携帯端末１００が実行する処理を説明する。図３のフローチャートに示す各ステップは、携帯端末１００の制御部１０１によって実現される処理であり、制御部１０１のプロセッサがメモリ１０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ３０１において、携帯端末１００は、カメラ１０５によってコードを読み取ったか否かを判定する。本実施形態では、バーコードやＱＲコードのようなコードが食材に付加されている。このコードには、後述する食材ＩＤのような識別情報が含まれていて、携帯端末１００は、カメラ１０５を用いてコードを読み取り、そして読み取ったコードを解析することで識別情報を取得する。なお、コードが食材に付加されているとは、コードが印刷されたシールが食材自体に貼り付けられている態様や、食材を包装する袋にコードが印刷される態様を示すものである。ステップ３０１においてコードを読み取ったと携帯端末１００が判定すると、処理はステップ３０２に進む。一方、コードを読み取っていない場合は、携帯端末１００はコードを読み取るまで待機する。

次にステップ３０２において、携帯端末１００は、読み取ったコードに基づいて食材を特定できたか否かを判定する。本実施形態では、携帯端末１００は、コードから取得した食材ＩＤをサーバ２００に送信し、サーバ２００からの応答を受信することで食材を特定する。サーバ２００が実行する処理については後ほど説明する。食材を特定できたと携帯端末１００が判定すると、処理はステップ３０３に進む。一方、食材を特定できないと携帯端末１００が判定すると、処理はステップ３０５に進む。食材を特定できない場合は、サーバ２００からの応答が所定時間（例えば１分）なかった場合や、サーバ２００からの応答が「対応レコードなし」であった場合である。

次にステップ３０３について説明する。ステップ３０３において、携帯端末１００は、特定した食材を携帯端末１００が管理する在庫リストに登録する。在庫リストとは、複数の食材それぞれについて、食材名、食材の種類、保存を開始した日時、保存期限日、残量等の情報を記憶するリストである。サーバ２００から携帯端末１００が受信する応答には、食材名、食材の種類、保存期限、保存場所が含まれていて、これらの情報を使って在庫リストへの登録が実行される。在庫リストの「保存を開始した日時」は、食材を在庫リストに登録した日時が自動的に登録される。また、在庫リストの「保存期限日」は、食材を在庫リストに登録した日時から、サーバ２００からの応答に含まれている「保存期限」が経過した日時が自動的に算出されて登録される。なお、サーバ２００からの応答に含まれている「保存期限」をそのまま「保存期限日」の算出に使っても良いし、サーバ２００からの応答に含まれている「保存期限」よりも短い期間、例えば３分の２の期間を「保存期限日」の算出に使っても良い。ユーザは、この在庫リストを確認することで、どのような食材が自宅にあるのかを確認でき、また、保存期限日が近い食材を容易に把握することもできる。

以降の説明では、在庫リストを携帯端末１００が記憶するものとして説明するが、在庫リストはサーバ２００が記憶しても良い。この場合、所定のタイミング（例えば在庫リストを表示するための操作が携帯端末１００に入力されたタイミング）で、携帯端末１００がサーバ２００から最新の在庫リストを取得するようにすれば良い。

次にステップ３０４において、携帯端末１００は、特定した食材の保存場所をユーザに通知する。携帯端末１００は、サーバ２００から受信した応答に含まれている保存場所の情報に基づいて、この保存場所に食材を保存するようにユーザに通知する。後ほど詳しく説明するが、特定した食材が大根であれば、大根を冷蔵庫の冷蔵室に保存することをユーザに促す通知画面を携帯端末１００が表示する。なお、通知画面の表示に限らず、他の方法、例えば音声メッセージを使って携帯端末１００が食材の保存場所をユーザに通知しても良い。また、通信機能を備えるスマートスピーカーに対して携帯端末１００が指示することで、このスマートスピーカーが食材の保存場所を音声メッセージで通知しても良い。また、通信機能を備える冷蔵庫に対して携帯端末１００が指示することで、この冷蔵庫が食材の保存場所をユーザに通知する通知画面を表示しても良いし、また、この冷蔵庫が食材の保存場所を音声メッセージで通知しても良い。ステップ３０４の処理によって、ユーザは食材を適切な保存場所で保存できる。

次にステップ３０５について説明する。ステップ３０５において、携帯端末１００は、在庫リストに登録するために必要な情報をユーザに入力させる。具体的には、携帯端末１００は、食材名、食材の種類、保存期限日をユーザに入力させるための入力画面を表示する。なお、保存を開始した日時については、自動的に設定した状態でこの入力画面を表示すれば良い。次にステップ３０６において、携帯端末１００は、ユーザが入力した情報を在庫リストに登録する。

次に図４のフローチャートを用いて、サーバ２００が実行する処理を説明する。図４のフローチャートに示す各ステップは、サーバ２００の制御部２０１によって実現される処理であり、制御部２０１のプロセッサがメモリ２０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ４０１において、サーバ２００は、食材ＩＤを受信したか否かを判定する。食材ＩＤを受信したとサーバ２００が判定すると、処理はステップ４０２に進む。本実施形態では、サーバ２００は携帯端末１００から食材ＩＤを受信する。一方、食材ＩＤを受信していない場合、サーバ２００は食材ＩＤを受信するまで待機する。

次にステップ４０２において、サーバ２００は、図５に示す食材データベース５００の中に、受信した食材ＩＤに対応するレコードがあるか否かを判定する。食材データベース５００は、サーバ２００のメモリ２０２に記憶されている情報であり、複数の食材それぞれについて、食材名、食材の種類、保存期限、保存場所を記憶するデータベースである。例えば食材ＩＤが００３のレコードに注目すると、食材名が大根、食材の種類が野菜、保存期限が３日、保存場所が冷蔵室と定義されている。受信した食材ＩＤに対応するレコードがあるとサーバ２００が判定すると、処理はステップ４０３に進む。一方、受信した食材ＩＤに対応するレコードがないとサーバ２００が判定すると、処理はステップ４０４に進む。

次にステップ４０３について説明する。ステップ４０３において、サーバ２００は、食材ＩＤに対応するレコードの情報を携帯端末１００に応答する。食材ＩＤに対応するレコードの情報は、具体的には食材名、食材の種類、保存期限、保存場所である。これらの情報に基づいて、図３のステップ３０３とステップ３０４で説明した処理が携帯端末１００において実行される。例えば、ステップ４０３で携帯端末１００に送信された情報が、食材ＩＤが００３のレコードの情報である場合、携帯端末１００において大根の情報が在庫リストに登録され、また、大根の保存場所が冷蔵庫の冷蔵室であることがユーザに通知される。また、ステップ４０３で携帯端末１００に送信された情報が、食材ＩＤが００５のレコードの情報である場合、携帯端末１００においてじゃがいもの情報が在庫リストに登録され、また、じゃがいもの保存場所が冷暗所であることがユーザに通知される。図４のステップ４０３、及び、図３のステップ３０４によって、ユーザは食材に適した保存場所を把握し、食材を適切な保存方法で保存できる。なお、図５の冷蔵室、冷凍室、野菜室、パーシャル室は、それぞれ冷蔵庫の貯蔵室に対応し、保存場所の候補として冷蔵庫の貯蔵室が含まれていることがわかる。また、図５の冷暗所は冷蔵庫の庫外を示し、常温と呼ばれることもある。

次にステップ４０４において、サーバ２００は、需要予測処理を実行する。この需要予測処理については、図６のフローチャートを用いて後ほど説明する。

次にステップ４０５について説明する。ステップ４０５において、サーバ２００は、「対応レコードなし」を携帯端末１００に応答する。この応答を受信した携帯端末１００は、図３のステップ３０５、ステップ３０６で説明した処理を実行する。

次に、携帯端末１００が管理する在庫リストの活用方法について説明する。携帯端末１００において献立検索を行う際に、保存期限日が近い食材を使う献立のみを検索しても良いし、保存期限日が近い食材を使う献立を他の献立よりも上位になるように検索結果を表示しても良い。また、保存期限日に近づいたタイミングで、その食材を使用するように携帯端末１００がユーザに促しても良い。

次に図６のフローチャートを用いて、サーバ２００が実行する需要予測処理について説明する。図６のフローチャートに示す各ステップは、サーバ２００の制御部２０１によって実現される処理であり、制御部２０１のプロセッサがメモリ２０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ６０１において、サーバ２００は、ステップ４０１で受信した食材ＩＤが示す食材について、コードの読み取り日時を記憶する。本実施形態では、ステップ４０１で食材ＩＤを受信した日時をコードの読み取り日時とする。サーバ２００は、複数の食材それぞれについて、コードの読み取り日時を記憶する。

次にステップ６０２について、サーバ２００は、記憶している読み取り日時に基づいてその食材の需要を予測できたか否かを判定する。本実施形態では、サーバ２００は、ユーザがある食材を購入する頻度に規則性があるか否かを判定し、その規則性に従って需要を予測する。

本実施形態では、例えばある食材の直近４回の購入のうち３回の購入頻度が同じであれば、その食材の購入頻度に規則性があるとサーバ２００が判定する。より具体的に説明すると、例えば食材ＩＤが００７の牛肉について、直近４回の読み取り日時が前回のコードの読み取りから４日後、４日後、３日後、４日後だったとする。これは、直近４回の購入が前回の購入日から４日後、４日後、３日後、４日後であるとも言える。このケースでは、サーバ２００は牛肉の購入頻度が４日毎であり、次の牛肉の需要（言い換えれば次の牛肉の購入）が４日後であると予測できる。このようにステップ６０２において食材の需要を予測できるとサーバ２００が判定すると、処理はステップ６０３に進む。一方、食材の需要を予測できないとサーバ２００が判定すると、サーバ２００は需要予測処理を終了する。

次にステップ６０３について説明する。ステップ６０３において、サーバ２００は、需要の予測結果に従って通知イベントを登録する。例えば上述した牛肉のケースでは、次の牛肉の需要が４日後であるとサーバ２００が予測している。このケースでは、サーバ２００は、４日後の朝（例えば午前７時）に牛肉の購入をユーザに促すように、図７の通知イベントデータベース７００に通知イベントを登録する。図７の通知イベントデータベース７００は、サーバ２００のメモリ２０２に記憶されている情報であり、ユーザに通知すべきイベントを記憶している。イベントＩＤが００３のレコードが、４日後の朝に牛肉の購入をユーザに促すように登録された通知イベントである。なお、通知イベントデータベース７００の通知日と通知時間は、ユーザが変更することができる。

次に図８のフローチャートを用いて、通知イベントデータベース７００に登録されている情報に従ってサーバ２００が食材の購入をユーザに促す処理について説明する。図８のフローチャートに示す各ステップは、サーバ２００の制御部２０１によって実現される処理であり、制御部２０１のプロセッサがメモリ２０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ８０１において、サーバ２００は、通知タイミングに達したか否かを判定する。サーバ２００は現在の日時を特定する。そして特定した現在の日時が通知イベントデータベース７００に登録されているいずれかの通知イベントの通知日、及び、通知時間に達した場合に、ステップ８０１において通知タイミングに達したとサーバ２００が判定し、処理はステップ８０２に進む。一方、通知タイミングに達していない場合、通知タイミングに達するまでサーバ２００は待機する。

次にステップ８０２について説明する。ステップ８０２において、サーバ２００は、通知タイミングに達した食材の購入を促す通知を携帯端末１００に送信する。例えば現在の日時が２０１９年７月２６日の午前７時であれば、食材ＩＤが００７の牛肉が通知タイミングに達したとサーバ２００が判定し、そして牛肉の購入を促す通知をサーバ２００が携帯端末１００に送信する。

次に図９のフローチャートを用いて、食材の購入を促す通知を受信した携帯端末１００が実行する処理について説明する。図９のフローチャートに示す各ステップは、携帯端末１００の制御部１０１によって実現される処理であり、制御部１０１のプロセッサがメモリ１０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ９０１において、携帯端末１００は、食材の購入を促す通知をサーバ２００から受信したか否かを判定する。食材の購入を促す通知をサーバ２００から受信したと携帯端末１００が判定すると、処理はステップ９０２に進む。一方、食材の購入を促す通知をサーバ２００から受信していない場合、当該通知を受信するまで携帯端末１００が待機する。

次にステップ９０２において、携帯端末１００は、サーバから２００から受信した通知に従って、食材の購入をユーザに促す。例えば牛肉の購入を促す通知をサーバ２００が携帯端末１００に送信していれば、携帯端末１００は牛肉の購入をユーザに促す通知画面を表示する。なお、通知画面の表示に限らず、他の方法、例えば音声メッセージを使って携帯端末１００が食材の購入をユーザに促しても良い。また、通信機能を備えるスマートスピーカーに対して携帯端末１００が指示することで、このスマートスピーカーが食材の購入をユーザに促しても良い。ユーザにしてみれば、食材の需要の予測結果に基づいて食材の購入を促されるため、食材の追加の購入が必要であることに気付くことができる。

なお、図３と図９のフローチャートで説明した携帯端末１００が実行する処理は、携帯端末１００にアプリケーションをインストールし、このアプリケーションによって実現されるようにしても良い。
（実施形態２）
次に、食材の重量を検知する重量センサを用いて、食材の追加の購入をユーザに促すシステムについて説明する。本実施形態のシステムは、ユーザが所有する携帯端末１００と、インターネット等のネットワーク上のサーバ２００と、冷蔵庫１０００とで構成される。携帯端末１００とサーバ２００は、実施形態１で説明した構成と同様であり、また実施形態１で説明した処理と同様の処理を実施するものとし、以下では実施形態１との差分を中心に説明する。

図１０は冷蔵庫１０００の構成を示す図である。冷蔵庫１０００は、冷蔵室、冷凍室、野菜室等の複数の貯蔵室を有し、図１０に図示しなない圧縮機、冷却器等で構成される冷凍サイクルによって各貯蔵室を目標温度に冷却する。冷蔵庫１０００は食材を保存する保存庫の一例である。

制御部１００１は冷蔵庫１０００の動作を制御する。制御部１００１はプロセッサを少なくとも有し、このプロセッサが後述するメモリ１００２に記憶されている制御プログラムを読みだして実行することで、制御部１００１が冷蔵庫１０００の動作を制御する。メモリ１００２は制御プログラム等の各種データを記憶する不揮発性の記憶媒体であり、例えばフラッシュメモリである。通信部１００３は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ等の無線ＬＡＮ規格に基づく無線通信を実行する。重量センサ１００４は、重量を検知するセンサである。後ほど詳しく説明するが、冷蔵庫１０００はドアポケットや棚に複数の重量センサが設けられている。

図１１は、サーバ２００のメモリ２０２に記憶されている重量管理データベース１１００を示す図である。この重量管理データベース１１００は、冷蔵庫１０００の重量センサ１００４の検知結果に基づいて、冷蔵庫１０００に収納されている食材の収納状態をサーバ２００が管理するためのものである。

本実施形態の冷蔵庫１０００は、ドアポケットにセンサＩＤ００１〜００３で示す３つの重量センサが設けられていて、また、冷蔵庫１０００の棚に、センサＩＤ００４〜００７で示す４つの重量センサそれぞれに対応する４つのエリアが設けられている。なお、重量センサの数、及び、重量センサに対応するエリアの数は単なる例示であり、本実施形態で説明する数に限定されない。図１１の重量管理データベース１１００の場合、センサＩＤ００３の重量センサに対応するドアポケットには、重量１００ｇのりんごジュースが置かれていることがわかる。また、重量管理データベース１１００には、過去の重量推移も記憶されている。

なお、重量センサが存在するエリアにどの種類の食材が置かれているかをサーバ２００が特定する方法は、２つ想定される。１つ目の方法は、ユーザが携帯端末１００を用いて冷蔵庫１０００への食材の収納方法を手動で設定する方法である。この方法の場合、ユーザは「ドアポケット３にりんごジュースを保存している」という情報を携帯端末１００に入力し、携帯端末１００がサーバ２００にユーザが入力した情報を通知する。

２つ目の方法は、ユーザが携帯端末１００を用いて食材に付加されているコードを読み取ることと、重量センサの検知結果とに基づいてサーバ２００が食材の収納状態を自動的に特定する方法である。例えばユーザが、携帯端末１００を用いてりんごジュースに付加されているコードを読み取り、そして冷蔵庫１０００のドアポケット３にりんごジュースを置いたとする。このとき、携帯端末１００がコードから読み取った食材ＩＤをサーバ２００に通知する。更に、センサＩＤが００３の重量センサが検知する重量に変更があったことを冷蔵庫１０００がサーバ２００に通知することで、サーバ２００はドアポケット３にりんごジュースが置かれたと判定できる。

次に図１２のフローチャートを用いて、冷蔵庫１０００が実行する処理を説明する。図１２のフローチャートに示す各ステップは、冷蔵庫１０００の制御部１００１によって実現される処理であり、制御部１００１のプロセッサがメモリ１００２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ１２０１において、冷蔵庫１０００は、重量センサ１００４の検知結果に変化があったか否かを判定する。重量センサ１００４の検知結果に変化があると冷蔵庫１０００が判定すると、処理はステップ１２０２に進む。一方、重量センサ１００４の検知結果に変化がなければ、冷蔵庫１０００は待機する。

次にステップ１２０２において、冷蔵庫１０００は、重量情報をサーバ２００に送信する。重量情報とは、検知結果に変化があった重量センサのセンサＩＤと、その重量センサが検知している重量とを示す情報である。

次に図１３のフローチャートを用いて、サーバ２００が実行する処理を説明する。図１３のフローチャートに示す各ステップは、サーバ２００の制御部２０１によって実現される処理であり、制御部２０１のプロセッサがメモリ２０２に記憶されている制御プログラムを読みだして実行することによって実現される。

まずステップ１３０１において、サーバ２００は、重量情報を冷蔵庫１０００から受信したか否を判定する。重量情報をサーバ２００が冷蔵庫１０００から受信すると、処理はステップ１３０２に進む。一方、重量情報をサーバ２００が受信していなければ、サーバ２００は待機する。

次にステップ１３０２において、サーバ２００は、冷蔵庫１０００から受信した重量情報に従って重量管理データベース１１００を更新する。

次にステップ１３０３において、サーバ２００は、重量管理データベース１１００が管理している情報に基づいて食材の使用状況を推定し、食材の追加の購入をユーザに促す必要があるか否かを判定する。食材の追加の購入をユーザに促す必要があるとサーバ２００が判定すると、処理はステップ１３０４に進む。一方、食材の追加の購入をユーザに促す必要がないとサーバ２００が判定すると、サーバ２００は図１３のフローチャートに示す処理を終了する。

ステップ１３０３について具体的に説明する。本実施形態では、例えばある食材の直近４回の重量変化の平均値をサーバ２００が算出し、その食材の残量が算出した平均値以下であればその食材の追加の購入をユーザに促す必要があるとサーバ２００が判定する。図１１でセンサＩＤが００３の重量センサに注目すると、直近４回の重量変化の平均値は１００ｇであり、重量センサが検知している食材の残量は１００ｇである。このケースでは食材の残量が算出した平均値以下であるため、その食材の追加の購入をユーザに促す必要があるとサーバ２００が判定する。なお、図１１からも明らかなように、過去の重量推移は減少だけではなく、増加する場合もある。これは、在庫がなくなったためユーザが新しい食材を購入したケースや、古くなった食材を廃棄してユーザが新しい食材を購入したケースが該当する。ユーザの使用量に注目するために、ステップ１３０３で食材の直近Ｎ回（Ｎは自然数）の重量変化の平均値をサーバ２００が算出する際には、重量が減少しているケースの値のみを用いることが望ましい。

次にステップ１３０４について説明する。ステップ１３０４において、サーバ２００は、食材の購入を促す通知を携帯端末１００に送信する。例えば上述したケースでは、センサＩＤが００３の重量センサに対応する食材、即ちりんごジュースの購入を促す通知をサーバ２００が携帯端末１００に送信する。この通知を受けた携帯端末１００は、図９で説明した処理を実行する。ユーザにしてみれば、次にその食材を使用する際には残量が少なく足りない可能性がある食材について購入を促されるため、その食材を適切なタイミングで追加購入することができる。
（変形例）
サーバ２００追加の購入をユーザに促す対象は食材に限定されない。食材に限らず、食器洗い機や洗濯機に用いる洗剤のような消耗品を含む様々な商品にも上述した実施形態を適用できる。

また、サーバ２００が商品の購入をユーザに促す際に、その商品ではなくその商品に類似する類似商品の購入をユーザに促しても良いし、また、その商品と類似商品の両方の購入をユーザに促しても良い。類似商品とは、例えば商品があるメーカーの冷凍食品であれば、そのメーカーの新発売の冷凍食品が該当する。

また、上述した実施形態では商品の追加の購入をサーバ２００がユーザに促しているが、購入をユーザに促すのではなく、サーバ２００が店舗にその商品の購入を自動発注しても良い。また、自動発注の場合は配送の時間を考慮し、上述した実施形態よりも早いタイミング（例えば１日前）に発注することが望ましい。

１００ 携帯端末
１０５ カメラ
２００ サーバ
５００ 食材データベース
７００ 通知イベントデータベース
１０００ 冷蔵庫
１１００ 重量管理データベース

Claims (5)

1. 商品の識別情報を読み取る読み取り手段と、
   読み取った前記識別情報に基づいて、前記商品に関する処理を実行する処理手段と、
   前記読み取り手段による読み取り状況に基づいて前記商品の需要を予測し、予測の結果に従って前記商品の購入をユーザに促す通知手段とを備えることを特徴とするシステム。
2. 商品の識別情報を読み取る読み取り手段と、
   読み取った前記識別情報に基づいて、前記商品に関する処理を実行する処理手段と、
   前記商品を保存する保存庫から得られた前記商品の重量を示す重量情報に基づいて、前記商品の購入をユーザに通知手段とを備えることを特徴とするシステム。
3. 前記通知手段は、前記商品の購入ではなく前記商品に類似する類似商品の購入、又は、前記商品と前記類似商品の両方の購入をユーザに促すことを特徴とする請求項１又は２に記載のシステム。
4. 前記処理手段は、前記商品に適した保存場所をユーザに通知することを特徴とする請求項１又は２に記載のシステム。
5. 前記処理手段は、前記商品を在庫リストに追加することを特徴とする請求項１から３のいずれか１項に記載のシステム。

Images