(57)【要約】【課題】    従来技術は、冷蔵庫側で自動的に消費期限を取得して管理するため、利用者が自ら食品の消費期限を管理する必要がなくなる。しかしながら、この技術は、あくまでも個人の情報管理に過ぎず、例えば食料品販売店がこの情報を利用して消費者の需要を把握することを可能にするような技術は提案されていなかった。【解決手段】本発明に係る需要予測方法は、冷蔵庫内在庫の消費期限情報を受信する受信ステップと、前記受信ステップにおいて受信した消費期限情報に基づき、各冷蔵庫内在庫の消費期限情報を格納している在庫テーブルを更新する更新ステップと、前記更新ステップにおいて更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測ステップと、前記需要予測ステップにおいて算出された需要予測値を、販売店に通知する通知ステップと、を含むことを特徴とする。【選択図】  図１ 
2005056236.tif 000002
【特許請求の範囲】
【請求項１】
冷蔵庫の在庫情報から需要予測を行うサーバによる需要予測方法であって、
冷蔵庫内在庫の消費期限情報を受信する受信ステップと、
前記受信ステップにおいて受信した消費期限情報に基づき、各冷蔵庫内在庫の消費期限情報を格納している在庫テーブルを更新する更新ステップと、
前記更新ステップにおいて更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測ステップと、
前記需要予測ステップにおいて算出された需要予測値を、販売店に通知する通知ステップと、
を含むことを特徴とする需要予測方法。
【請求項２】
前記需要予測ステップは、冷蔵庫の所在地単位に需要予測を行うことを特徴とする請求項１記載の需要予測方法。
【請求項３】
各商品の在庫情報を格納している在庫テーブルと、
冷蔵庫の在庫情報を受信する受信手段と、
前記受信手段において受信した在庫情報に基づき、前記在庫テーブルを更新する更新手段と、
前記更新手段において更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測手段と、
前記需要予測手段において算出された需要予測値を、販売店に通知する通知手段と、
を備えることを特徴とする需要予測装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、家庭や小規模な商店などに設置されている冷蔵庫の在庫情報を把握し、その在庫情報から商品の需要予測を行う需要予測方法に関するものである。
【背景技術】
【０００２】
従来、冷蔵庫の中にある食品の消費期限は、利用者が自ら目で見て管理をしていた。この作業を自動化する仕組みとして、冷蔵庫への入庫の際に、食品に貼付してあるバーコードを読み取って冷蔵庫自身が各食品の消費期限を管理し、消費期限が切れそうな食品があったら警告をするという技術がある（特許文献１）。
【特許文献１】特開平５−２８８４５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述した従来技術は、冷蔵庫側で自動的に消費期限を取得して管理するため、利用者が自ら食品の消費期限を管理する必要がなくなる。しかしながら、この技術は、あくまでも個人の情報管理に過ぎず、例えば食料品販売店がこの情報を利用して消費者の需要を把握することを可能にするような技術は提案されていなかった。
【課題を解決するための手段】
【０００４】
本発明に係る需要予測方法は、冷蔵庫内在庫の消費期限情報を受信する受信ステップと、前記受信ステップにおいて受信した消費期限情報に基づき、各冷蔵庫内在庫の消費期限情報を格納している在庫テーブルを更新する更新ステップと、前記更新ステップにおいて更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測ステップと、前記需要予測ステップにおいて算出された需要予測値を、販売店に通知する通知ステップと、を含むことを特徴とする。
【０００５】
このように構成することにより、今まで各家庭内だけの利用に留まっていた冷蔵庫内の在庫情報を情報センターで一括管理するようにし、これらの情報を集計して分析するようにしたため、有益な需要情報を食料品販売店等に配信することが可能になる。
【０００６】
また、本発明に係る需要予測方法は、冷蔵庫の所在地単位に需要予測を行うように構成することにより、より詳細な需要予測が可能となる。
【０００７】
また、本発明に係る需要予測方法は、各販売店の商圏情報を格納する店舗テーブルを参照し、各販売店の商圏に限定した需要予測値を通知するように構成することにより、店舗の商圏に限定した需要予測情報を配信することが可能となる。
【０００８】
また、本発明に係る需要予測方法は、各商品の買い替え閾値を格納する閾値テーブルを参照し、前記在庫テーブルに格納された商品の消費期限から前記買い替え閾値を減算した日付を需要発生ポイントとして、各商品の需要予測値を算出するように構成することにより、消費期限が到来する前の需要発生ポイントに基づいた需要予測情報を配信することが可能となる。
【発明の効果】
【０００９】
このように本発明は、各家庭の冷蔵庫内在庫情報を情報センタで収集して分析することで、食料品販売店の販売計画に有益な需要予測情報を配信することを可能とする。
【発明を実施するための最良の形態】
【００１０】
本発明の実施の形態に係るシステム概要について図1を用いて説明する。まず、本実施の形態における前提として、各家庭１２０の冷蔵庫１２１には特開平５−２８８４５６号公報で開示されている物品管理機能付冷蔵庫の如く、冷蔵庫内に格納されている食料品の商品名や消費期限等を管理する仕組みが備わっているものとする。尚、当該公報では、食料品の格納時等に食品についているバーコード上の情報を取り込む構成となっているが、本発明は情報センターにおける需要予測方法に係るものであるため、各家庭１２０の冷蔵庫１２１の情報取得方法には限定されない。また、この冷蔵庫１２１はインターネットなどのネットワーク１４０に接続されており、このネットワーク１４０を介して情報センタサーバ１００と通信可能な状態となっている。
【００１１】
次に、本発明の需要予測方法を実施する情報センタサーバ１００について説明する。情報センタサーバ１００は、ネットワーク１４０を介して各家庭の冷蔵庫１２１と接続されて、受信した在庫情報に基づいて需要予測を行い、同じくネットワーク１４０を介して接続されている各販売店１３０のサーバ１３１にその需要予測情報を配信する。この需要予測方法は、情報センタサーバ１００で動作するプログラム群の処理方法であって、当該プログラム群には、各家庭の冷蔵庫１２１から在庫情報を受信する受信プログラム１０１、受信プログラム１０１で受信した情報に基づいて情報センタサーバ１００で管理する在庫情報を更新する在庫更新プログラム１０２、当該在庫情報に基づいて需要を予測する需要予測プログラム１０３、需要予測プログラム１０３で予測した需要予測情報を各販売店のサーバ１３１に配信する送信プログラム１０４、とが含まれる。これらのプログラムは、情報センタサーバ１００の図示せぬ外部記憶装置に格納されており、各プログラム実行時に内部記憶装置に読み出される。
【００１２】
また更に、情報センタサーバ１００の外部記憶装置には、各家庭の冷蔵庫１２１の所在地情報を格納する所在地テーブル１１０、各家庭の冷蔵庫１２１内の在庫情報を格納する在庫テーブル１１１、各販売店の情報を格納する店舗テーブル１１２、各食料品のアラーム発信時期情報を格納する閾値テーブル１１３、需要予測結果を格納する需要予測テーブル１１４、とが含まれ、必要に応じて、受信プログラム１０１、在庫更新プログラム１０２、需要予測プログラム１０３、送信プログラム１０４、から参照又は更新される。
【００１３】
また、需要予測情報の配信先である販売店１３０には、情報を受信するサーバ１３１が設置されており、このサーバ１３１は、ネットワーク１４０を介して情報センタサーバ１００と通信可能な状態となっている。
【００１４】
次に、本発明の一実施の形態に係る処理概要について、図２を用いて説明する。まず、情報センタサーバ１００の受信プログラム１０１が、各家庭の冷蔵庫１２１から在庫情報を受信する（Ｓ２０１）。受信する情報は、冷蔵庫のＩＰアドレス、商品名、消費期限、といった情報である。尚、この場合の受信方法は、各家庭の冷蔵庫１２１が定期的に送信してきても良いし、情報センタサーバ１００が各家庭の冷蔵庫１２１に対して定期的に情報を問い合わせる方法でも構わない。後者の場合、情報センタサーバ１００では、図３の所在地テーブル３０１のような所在地情報が格納されており、登録済みの冷蔵庫１２１のＩＰアドレスとそのＩＰアドレスに該当する家庭の所在地が対応付けて記録されているので、この所在地テーブル３０１に登録されているＩＰアドレスに向けて在庫情報の問い合わせを行うこととなる。尚、この所在地テーブル３０１は、需要予測プログラム１０３でその情報を用いるため、前者の場合であっても必要となる。
【００１５】
次に、受信プログラム１０１で受信した在庫情報に基づいて、在庫更新プログラム１０２により、在庫テーブル１１１の更新を行う在庫更新処理（Ｓ２０２）が実行される。そして、在庫更新処理で最新状態となった在庫テーブル１１１の在庫情報に基づき、需要予測プログラム１０３により、需要予測処理が実行される（Ｓ２０３）。そして最終的に、送信プログラム１０４により、需要予測処理の結果に基づき、各販売店のサーバ１３１に需要予測情報が配信される送信処理（Ｓ２０４）が実行される。
【００１６】
以上、図２の処理フローの如く各処理を実行することで、各販売店に有益な需要予測情報が自動的に配信可能となる。
【００１７】
次に、図２で説明した、在庫更新処理（Ｓ２０２）、需要予測処理（Ｓ２０３）、送信処理（Ｓ２０４）につき、それぞれ図面を用いて詳細に説明する。
【００１８】
まず、在庫更新処理（Ｓ２０２）について、図４のフローを用いて詳細に説明する。在庫更新プログラム１０２は、Ｓ２０１で在庫情報を受信が完了すると、受信した在庫情報に基づき、該当する冷蔵庫の在庫情報を最新状態にする。具体的には、まず、在庫テーブル１１１の該当するＩＰアドレスのレコードを削除する（Ｓ４０１）。この在庫テーブル１１１を、図５の在庫テーブル５０１に例示する。在庫テーブル５０１は、冷蔵庫のＩＰアドレスであるＩＰアドレス、在庫されている商品名、消費期限を表す鮮度保証、とから構成されている。ＩＰアドレスは各冷蔵庫で一意となるが、冷蔵庫に在庫されている食料品は複数存在するため、ＩＰアドレスは複数レコードで重複する。場合によっては、同一の冷蔵庫に同一商品が複数存在することも考えられるため、商品名も複数レコードで重複する場合がある。そのため、Ｓ４０１では、該当する冷蔵庫のＩＰアドレスに合致するレコードを全て削除し、新たに受信した在庫情報に置き換えるという処理を行う（Ｓ４０２）。
【００１９】
その後、別の冷蔵庫から受信した在庫情報があるか否かを判定し（Ｓ４０３）、あった場合はＳ４０１の処理に戻り、なかった場合はこの在庫更新処理（Ｓ２０２）を終了する。
【００２０】
次に、需要予測処理（Ｓ２０３）について、図６のフローを用いて詳細に説明する。まず、需要予測プログラム１０３は、在庫テーブル５０１を読み込む（Ｓ６０１）。在庫テーブル５０１は、前述のとおり、各冷蔵庫に在庫されている食料品の商品名と鮮度保証の日付を格納している。このレコードを１レコードずつ読み込み、各食料品が買い替え時（需要発生ポイント）か否かを判定する（Ｓ６０２）。この判定は、在庫テーブルの鮮度保証日と処理日付を比較して、処理時点で鮮度保証日を過ぎていないか否かを判定することもできるが、本実施の形態においては、より正確に計算するため、商品ごとの買い替え閾値を用いた需要発生ポイントを利用することとする。
【００２１】
例えば、ソースやケチャップのように、常に家庭に常備しておく必要があるような食料品については、消費期限が過ぎてから購入するのではなく、消費期限がある程度近づいてくると、とりあえず購入しておく場合が多い。そのため、商品ごとに消費期限何日前に購入するかという閾値を設定して、その値を閾値テーブル１１３に格納しておく。この閾値テーブル１１３を、図７の閾値テーブル７０１に例示する。閾値テーブル７０１は、商品名と前述の閾値を対応付けて格納している。ここで、閾値を０日とすることで、前述の商品ごとの買い替え閾値を用いない商品についても処理することが可能となる。
【００２２】
Ｓ６０２の判定の結果、処理日付が閾値を考慮した需要発生ポイントを越えていた場合はＳ６０４に進み、越えていない場合はＳ６０５に進む（Ｓ６０３）。
【００２３】
例えば、在庫テーブル５０１の１レコード目の場合、ＩＰアドレス１２３の冷蔵庫の○○ソースの鮮度保証日が２００３年１０月９日であることがわかる。そして、処理日付が２００３年７月１日だと仮定する。この前提において、まず、Ｓ６０２では、商品名である○○ソースをキーとして閾値テーブル７０１を検索する。そして、抽出された情報から、○○ソースの買い替え閾値が３０日であることがわかる。そこで、前述の鮮度保証日２００３年１０月９日から買い替え閾値３０日を減算し、買い替えポイント、つまり需要発生ポイント２００３年９月９日を取得する。そこで、この需要発生ポイント２００３年９月９日と処理日付２００３年７月１日を比較し、処理日付現在ではまだ需要発生ポイントを越えていないと判断される。この場合は、Ｓ６０３の判定はＮとなり、Ｓ６０５に進む。
【００２４】
また、例えば、在庫テーブル５０１の４レコード目の場合、ＩＰアドレス７８９の冷蔵庫の××ケチャップの鮮度保証日が２００３年７月３１日であることがわかる。そして、処理日付が２００３年７月１日だと仮定する。この前提において、まず、Ｓ６０２では、商品名である××ケチャップをキーとして閾値テーブル７０１を検索する。そして、抽出された情報から、××ソースの買い替え閾値が６０日であることがわかる。そこで、前述の鮮度保証日２００３年７月３１日から買い替え閾値６０日を減算し、買い替えポイント、つまり需要発生ポイント２００３年６月１日を取得する。そこで、この需要発生ポイント２００３年６月１日と処理日付２００３年７月１日を比較し、処理日付現在で既に需要発生ポイントを超えていると判断される。この場合は、Ｓ６０３の判定はＹとなり、Ｓ６０４に進む。
【００２５】
上述のように、需要発生ポイントを超えていると判断した場合、その商品については買い替え需要があると判定され、需要予測テーブル１１４に書き出す（Ｓ６０４）。この需要予測テーブル１１４を、図８の需要予測テーブル８０１に例示する。需要予測テーブル８０１は、商品ごとの需要予測値を所在地ごとに格納するテーブルであり、商品名、所在地名、需要値である数量、とから構成されている。例えば在庫テーブル５０１の４レコード目の場合であれば、この需要予測テーブルに書き込まれることになる。その場合、まずＩＰアドレス７８９をキーに所在地テーブル３０１を検索する。そして、抽出された情報から、需要が発生している所在地が川崎市中原区井田三舞町であることがわかる。そこで、商品名××ケチャップ、所在地名川崎市中原区井田三舞町をキーに需要予測テーブル８０１を検索し、合致したレコードの数量に１を加算する。この検索において、合致するレコードが見つからなかった場合は、新規にレコードを発生させることになる。このようにして、所在地ごとの商品の需要予測値が蓄積されていく。
【００２６】
Ｓ６０４において需要予測テーブル８０１への書き込みが完了すると、Ｓ６０３の判定でＮとなった場合と同様、Ｓ６０５に進み、在庫テーブル５０１の全てのレコードについて処理が完了したか否かを判定する。まだ全てのレコードについての処理が完了していなかった場合はＳ６０１の処理に戻り、全てのレコードについての処理が完了した場合にはこの需要予測処理（Ｓ２０３）を終了する。
【００２７】
次に、送信処理（Ｓ２０４）について、図９のフローを用いて詳細に説明する。まず、送信プログラム１０４は、店舗テーブル１１２を読み込む（Ｓ９０１）。店舗テーブル１１２は、本情報センタの需要予測情報配信サービスを契約している販売店の情報を格納している。この店舗テーブル１１２を、図１０の店舗テーブル１００１に例示する。店舗テーブル１００１は、店舗名、メールアドレス、商圏、とから構成されている。尚、商圏については、この例では住所が格納されているものとする。
【００２８】
Ｓ９０１で店舗テーブルを読み込むと、次に、読み込んだレコードの商圏をキーに、需要予測テーブル８０１を検索する（Ｓ９０２）。この処理により、処理対象の店舗の商圏に合致する需要予測情報を抽出することができる。具体的には、店舗テーブル１００１の１レコード目の場合であれば、○○スーパーの商圏が、川崎市中原区下小田中、川崎市中原区井田三舞町、川崎市中原区上小田中、であることがわかり、これらの地名をキーに需要予測テーブル８０１を検索する。その結果、川崎市中原区下小田中において○○ソースが５２個、川崎市中原区井田三舞町において××ケチャップが１０５個、という需要予測情報が存在することがわかる。
【００２９】
そこで、この情報に基づき、需要予測値を配信するための電子メールを編集する（Ｓ９０３）。この配信メールを、図１１の通知メール１１０１に例示する。メールの本文については、需要予測テーブル８０１の抽出結果に基づいて作成し、宛先（○○スーパー様）については、店舗テーブル１００１に基づいて作成する。
【００３０】
このように編集した電子メールを、店舗テーブル１００１のメールアドレスに格納されている電子メールアドレスに対して配信する（Ｓ９０４）。その後、店舗テーブル１００１の全てのレコードについて処理が完了したか否かを判定する（Ｓ９０５）。まだ全てのレコードについての処理が完了していなかった場合はＳ９０１の処理に戻り、全てのレコードについての処理が完了した場合にはこの送信処理（Ｓ２０４）を終了する。
【００３１】
尚、上述の実施の形態においては、各販売店の商圏を、住所を用いて行っているが、別の方法として、緯度経度を用いた商圏の捉え方も可能である。この場合は、所在地テーブル１１０及び店舗テーブル１１２に緯度経度を格納しておき、店舗の緯度及び軽度の数値から所定の範囲を商圏とし、その範囲内にある所在地に設置されている冷蔵庫を集計対象とすることとなる。
【００３２】
このような一連の処理を行うことにより、販売店のサーバ１３１に需要予測情報が配信され、販売店１３０は販売計画を立てるために有益な需要予測情報を得ることができる。
【００３３】
（付記１）
冷蔵庫の在庫情報から需要予測を行うサーバによる需要予測方法であって、
冷蔵庫内在庫の消費期限情報を受信する受信ステップと、
前記受信ステップにおいて受信した消費期限情報に基づき、各冷蔵庫内在庫の消費期限情報を格納している在庫テーブルを更新する更新ステップと、
前記更新ステップにおいて更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測ステップと、
前記需要予測ステップにおいて算出された需要予測値を、販売店に通知する通知ステップと、
を含むことを特徴とする需要予測方法。
【００３４】
（付記２）
前記需要予測ステップは、冷蔵庫の所在地単位に需要予測を行うことを特徴とする請求項１記載の需要予測方法。
【００３５】
（付記３）
前記通知ステップは、各販売店の商圏情報を格納する店舗テーブルを参照し、各販売店の商圏に限定した需要予測値を通知することを特徴とする請求項２記載の需要予測方法。
【００３６】
（付記４）
前記需要予測ステップは、各商品の買い替え閾値を格納する閾値テーブルを参照し、前記在庫テーブルに格納された商品の消費期限から前記買い替え閾値を減算した日付を需要発生ポイントとして、各商品の需要予測値を算出することを特徴とする請求項１記載の需要予測方法。
【００３７】
（付記５）
各商品の在庫情報を格納している在庫テーブルと、
冷蔵庫の在庫情報を受信する受信手段と、
前記受信手段において受信した在庫情報に基づき、前記在庫テーブルを更新する更新手段と、
前記更新手段において更新された在庫テーブルの情報に基づき、各商品の需要予測値を算出する需要予測手段と、
前記需要予測手段において算出された需要予測値を、販売店に通知する通知手段と、
を備えることを特徴とする需要予測装置。
【図面の簡単な説明】
【００３８】
【図１】実施の形態のシステム構成図である。
【図２】実施の形態の処理フローである。
【図３】所在地テーブルの一例を示す図である。
【図４】在庫更新処理の流れを示すフローチャートである。
【図５】在庫テーブルの一例を示す図である。
【図６】需要予測処理の流れを示すフローチャートである。
【図７】閾値テーブルの一例を示す図である。
【図８】需要予測テーブルの一例を示す図である。
【図９】送信処理の流れを示すフローチャートである。
【図１０】店舗テーブルの一例を示す図である。
【図１１】通知メールの一例を示す図である。
【符号の説明】
【００３９】
１００  情報センタサーバ
１０１  受信プログラム
１０２  在庫更新プログラム
１０３  需要予測プログラム
１０４  送信プログラム
１１０  所在地テーブル
１１１  在庫テーブル
１１２  店舗テーブル
１１３  閾値テーブル
１１４  需要予測テーブル
１２０  家庭
１２１  冷蔵庫
１３０  販売店
１３１  サーバ
【図１】
2005056236.tif 000003
【図２】
2005056236.tif 000004
【図３】
2005056236.tif 000005
【図４】
2005056236.tif 000006
【図５】
2005056236.tif 000007
【図６】
2005056236.tif 000008
【図７】
2005056236.tif 000009
【図８】
2005056236.tif 000010
【図９】
2005056236.tif 000011
【図１０】
2005056236.tif 000012
【図１１】
2005056236.tif 000013