WO2013132778A1

WO2013132778A1 - 情報処理システム、情報処理方法、情報処理装置およびその制御方法と制御プログラム

Info

Publication number: WO2013132778A1
Application number: PCT/JP2013/001087
Authority: WO
Inventors: 土井　伸一; 板谷　聡子; 琢小西; 理恵田仲
Original assignee: 日本電気株式会社
Priority date: 2012-03-08
Filing date: 2013-02-26
Publication date: 2013-09-12
Also published as: JP2015121828A

Abstract

［課題］商品購入に関わるユーザの交通移動量を積極的に削減することにより、交通渋滞を緩和すること。［解決手段］ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得部と、ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、ユーザの商品購入要求に関する情報を、ネットワークを介して通知する商品購入情報通知部と、店舗への商品の入荷情報を、ネットワークを介して受信して、商品の店舗における購入案内を、ネットワークを介してユーザの通信端末に対して報知する商品購入案内部と、を備えることを特徴とする。

Description

情報処理システム、情報処理方法、情報処理装置およびその制御方法と制御プログラム

　本発明は、情報処理システム、情報処理方法、情報処理装置およびその制御方法と制御プログラムに関し、特に、交通渋滞を考慮した商品配置のための情報処理システム、情報処理方法、情報処理装置およびその制御方法と制御プログラムに関する。

　特許文献１には、小売店舗の商品発注量に基づいて交通渋滞を予測する技術が開示されている。また、特許文献２には、渋滞ルート上の店舗よりも迂回ルート上の店舗において割り増しポイントを付与するようにして、ユーザを迂回ルートに誘導する技術が開示されている。

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

　特許文献１及び２に記載の技術は、交通渋滞の発生を前提として、その交通渋滞をいかに緩和するかという対処療法的な技術である。したがって、特許文献１及び２では、交通渋滞の根本原因の１つでもあるユーザの交通移動量そのものを削減することはできない。

　本発明の目的は、上述の課題を解決する情報処理装置を提供することにある。

　本発明に係る情報処理装置は、ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得手段と、前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知する商品購入情報通知手段と、前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する商品購入案内手段と、を備えることを特徴とする。

　本発明に係る情報処理の制御方法は、ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得し、前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知し、前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する、ことを特徴とする。

　本発明に係る情報処理プログラムは、コンピュータを、ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得手段と、前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知する商品購入情報通知手段と、前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する商品購入案内手段と、して動作させることを特徴とする。

　本発明によれば、商品購入に関わるユーザの交通移動量を積極的に削減することにより、交通渋滞を緩和することができる。

図１は、本発明の第１実施形態に係る情報処理装置の構成を示すブロック図である。図２は、本発明の第２実施形態に係る情報処理システムの概略動作を説明する図である。図３は、本発明の第２実施形態に係る情報処理システムの構成を示すブロック図である。図４は、本発明の第２実施形態に係る情報処理システムの動作手順を示すシーケンス図である。図５は、本発明の第２実施形態に係る情報処理装置の機能構成を示すブロック図である。図６は、本発明の第２実施形態に係るユーザ端末の機能構成を示すブロック図である。図７は、本発明の第２実施形態に係る店舗端末の機能構成を示すブロック図である。図８は、本発明の第２実施形態に係るユーザ情報ＤＢの構成を示す図である。図９は、本発明の第２実施形態に係る店舗情報ＤＢの構成を示す図である。図１０は、本発明の第２実施形態に係る商品情報ＤＢの構成を示す図である。図１１は、本発明の第２実施形態に係る流通／在庫管理ＤＢの構成を示す図である。図１２は、本発明の第２実施形態に係る情報処理装置のハードウェア構成を示すブロック図である。図１３は、本発明の第２実施形態に係る商品購入要求テーブルの構成を示す図である。図１４は、本発明の第２実施形態に係る商品ニーズテーブルの構成を示す図である。図１５は、本発明の第２実施形態に係る情報処理装置の動作手順を示すフローチャートである。図１６は、本発明の第２実施形態に係る商品ニーズ値算出処理の動作手順を示すフローチャートである。図１７は、本発明の第２実施形態に係る商品配置最適化処理の動作手順を示すフローチャートである。図１８は、本発明の第２実施形態に係るユーザ端末のハードウェア構成を示すブロック図である。図１９は、本発明の第２実施形態に係るユーザ端末の処理手順を示すフローチャートである。図２０は、本発明の第２実施形態に係る店舗端末のハードウェア構成を示すブロック図である。図２１は、本発明の第２実施形態に係る店舗端末の処理手順を示すフローチャートである。図２２は、本発明の第３実施形態に係る情報処理システムの動作手順を示すシーケンス図である。図２３は、本発明の第３実施形態に係る情報処理装置の機能構成を示すブロック図である。図２４は、本発明の第３実施形態に係る店舗選択テーブルの構成を示す図である。図２５は、本発明の第３実施形態に係る情報処理装置の動作手順を示すフローチャートである。図２６は、本発明の第３実施形態に係る商品配置最適化処理の動作手順を示すフローチャートである。図２７は、本発明の第４実施形態に係る情報処理システムの動作手順を示すシーケンス図である。図２８は、本発明の第４実施形態に係る情報処理装置の機能構成を示すブロック図である。図２９は、本発明の第４実施形態に係るリクエスト学習ＤＢの構成を示す図である。図３０は、本発明の第４実施形態に係る商品ニーズテーブルの構成を示す図である。図３１は、本発明の第４実施形態に係る情報処理装置の動作手順を示すフローチャートである。図３２は、本発明の第４実施形態に係るユーザ商品購入要求予測処理の動作手順を示すフローチャートである。図３３は、本発明の第５実施形態に係る情報処理システムの動作手順を示すシーケンス図である。図３４は、本発明の第５実施形態に係る情報処理装置の機能構成を示すブロック図である。図３５は、本発明の第５実施形態に係るリクエスト学習ＤＢの構成を示す図である。図３６は、本発明の第５実施形態に係る商品ニーズテーブルの構成を示す図である。図３７は、本発明の第５実施形態に係る情報処理装置の動作手順を示すフローチャートである。図３８は、本発明の第５実施形態に係る商品配置最適化処理の動作手順を示すフローチャートである。図３９は、本発明の第６実施形態に係る情報処理システムにおけるユーザ端末への商品購入案内例を示す図である。図４０は、本発明の第６実施形態に係る情報処理システムにおける店舗端末への商品入荷リクエスト例を示す図である。図４１は、本発明の第７実施形態に係る情報処理システムにおけるユーザおよび店舗へのポイント付与例を示す図である。

　以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。

　［第１実施形態］
　本発明の第１実施形態としての情報処理装置１００について、図１を用いて説明する。情報処理装置１００は、交通渋滞を考慮した商品配置を制御する装置である。

　図１に示すように、情報処理装置１００は、商品購入要求取得部１１１と、商品購入情報通知部１１２と、商品購入案内部１１３と、を含む。商品購入要求取得部１１１は、ユーザの所在地１１１ａとユーザの商品購入要求に関する情報１１１ｂとを取得する。商品購入情報通知部１１２は、ユーザの所在地１１１ａとの距離が第１閾値Ｄｈより短い（１１２ａ）店舗１２０、１３０の通信端末に対して、ユーザの商品購入要求に関する情報１１２ｂを、ネットワーク１４０を介して通知する。商品購入案内部１１３は、店舗１２０、１３０への商品の入荷情報１１３ａを、ネットワーク１４０を介して受信する。そして、商品購入案内部１１３は、商品の店舗１２０、１３０における購入案内１１３ｂを、ネットワーク１４０を介してユーザの通信端末に対して報知する。

　本実施形態によれば、商品購入に関わるユーザの交通移動量を積極的に削減することにより、交通渋滞を緩和することができる。

　［第２実施形態］
　次に、本発明の第２実施形態に係る情報処理システムについて説明する。本実施形態に係る情報処理システムは、ユーザがユーザ端末を介して入力した商品購入要求を収集する。各店舗では、各店舗からの距離が閾値より近いユーザの商品購入要求に合った商品が用意される。情報処理システムは、当該ユーザに各店舗での商品購入案内をする。

　本実施形態によれば、各ユーザは購入を要求した商品をより近い店舗で購入できるので、ユーザの交通移動量が削減されて、交通渋滞を緩和することができる。

　《情報処理システム》
　以下、図２乃至図４に従って、本実施形態のサーバ装置である情報処理装置を含む情報処理システムについて説明する。

　（概略動作の説明）
　図２は、本実施形態に係る情報処理システム２００の概略動作を説明する図である。

　図２の上段では、左図が、ユーザＡのユーザ端末２１０における、商品購入要求をするための画面である。右図が、ユーザＡのユーザ端末２２０における、商品入荷案内の画面である。また、図２の下段では、左図が、店舗Ａの店舗端末２４０における、商品入荷リクエストの画面である。右図が、店舗Ａの店舗端末２４０における、商品入荷報告の画面である。

　以下、本情報処理システム２００の概略動作を説明する。

　まず、上段左図において、ユーザは、ユーザ端末２１０の画面２１１に表示された商品購入要求ウインドウ２１２に、購入要求商品、数、希望日時の欄２１３に商品購入要求の入力を行なう。そして、ユーザがリクエスト２１４を押すと、商品購入要求の内容は商品購入要求メッセージとして情報処理装置２３０に送信される。

　情報処理装置２３０は、ユーザ端末からのユーザの商品購入要求を収集する。情報処理装置２３０は、商品配置決定部２３１により、各ユーザの所在地に近い店舗への購入要求を満足させるように商品の配置を決定する。そして、情報処理装置２３０は、各店舗の端末に商品の入荷をリクエストする。

　下段左図は、店舗Ａの店舗端末２４０の表示画面２４１に表示された入荷リクエストウインドウ２４２である。なお、店舗端末２４０は、入荷リクエストウインドウ２４２に、ユーザの商品購入要求の情報（商品、要求数、ユーザ所在地など）を表示してもよい。店舗Ａのオペレータは、入荷リクエストウインドウ２４２を見て、店舗Ａの在庫などを考慮して配送センター２５０に商品の入荷を依頼する。配送センター２５０においては、オペレータが、全体の商品在庫や配送スケジュール、配送車両スケジュールなどを考慮して、店舗Ａからの入荷依頼に対応する。

　下段右図は、配送センター２５０から商品入荷があった場合の、店舗Ａの店舗端末２４０から情報処理装置２３０への入荷報告が表示された、表示画面２４３上の入荷報告ウインドウ２４４である。

　情報処理装置２３０は、他の店舗からの入荷報告に加えて、店舗Ａからの入荷報告を受信する。そして、情報処理装置２３０は、ユーザＡの所在地からの距離が閾値内の店舗における商品入荷スケジュールを整理する。そして、情報処理装置２３０は、上段右図のように、ユーザＡのユーザ端末２２０の表示画面２２１に表示された入荷スケジュールウインドウ２２２により報知する。入荷スケジュールウインドウ２２２には、ユーザＡが購入要求した商品の内、プリンタ用紙とタオルとが既に店舗Ａに用意され、電気ポットは、離れていない店舗Ｂに、明日入荷することが報知されている。

　なお、ユーザ端末２２０は、ユーザ端末２１０と同じであっても異なってもよい。本例では、スマートフォンで商品購入要求が入力され、タブレットで商品購入案内が出力される例が示されているが、これに限定されない。ユーザ端末は、デスクトップ型ＰＣやノート型ＰＣ、携帯電話、デジタルカメラ、あるいはカーナビゲーションなどであってよい。

　（システム構成）
　図３は、本実施形態に係る情報処理システム２００の構成を示すブロック図である。

　情報処理システム２００は、１つの情報処理装置２３０と、３つの店舗と、１つの配送センター２５０とを備える。情報処理装置２３０は、商品配置決定部２３１を有する。３つの店舗は、それぞれの店舗が他の店舗と離れていない店舗のグループである店舗Ａ２４０－１、店舗Ｂ２４０－２、店舗Ｃ２４０－３とからなる。また、図３の人形の図形はユーザの所在地を表わしている。ハッチングのある人形の図形は、商品購入要求を情報処理装置２３０に送信したユーザの所在地を表わしている。

　図３は、情報処理装置２３０がユーザからの商品購入要求を収集した状態を示している。情報処理装置２３０は、収集したユーザからの商品購入要求を、店舗Ａ２４０－１から所定範囲３１０内のユーザ、店舗Ｂ２４０－２から所定範囲３２０内のユーザ、店舗Ｃ２４０－３から所定範囲３３０内のユーザに分類する。そして、情報処理装置２３０の商品配置決定部２３１は、各店舗から所定範囲内のユーザの商品購入要求をまとめて、対応する各店舗に商品入荷リクエスト３１１、３２１、３３１を通知する。各店舗は、配送センター２５０に、各商品の入荷依頼３１２、３２２、３３２を送信する。

　配送センター２５０からの配送トラックによる配送３１３、３２３、３３３によって、商品が各店舗に届けられると、入荷済み情報が、各店舗あるいは配送センターから、情報処理装置２３０に通知される。情報処理装置２３０は、各店舗における商品の入荷を確認して、商品購入要求をしたユーザに対して入荷情報３１４、３２４、３３４を報知する。

　入荷情報３１４、３２４、３３４の報知を受けたユーザは、図中の破線の矢印で示すように、近い店舗で商品を購入する。このように、各ユーザが、より近い店舗で所望の商品を購入するように、情報処理装置２３０が案内して誘導できるので、ユーザの交通移動量が削減されて、交通渋滞が緩和される。

　（動作手順）
　図４は、本実施形態に係る情報処理システム２００の動作手順を表すシーケンス図である。なお、図４においては、ユーザおよび店舗の本情報処理システムへの会員登録手順は、簡略化のため省略されている。

　まず、ステップＳ４０１において、各範囲３１０、３２０、３３０のユーザ端末のいずれかから、商品購入要求が情報処理装置２３０に送信される。そして、情報処理装置２３０は、ユーザ情報ＤＢを参照して、商品購入要求に付加されるユーザＩＤから、ユーザの所在地を認識する。

　情報処理装置２３０は、ステップＳ４０３において、ユーザ端末から収集された商品購入要求を、ユーザの所在地に基づいて各店舗Ａ、店舗Ｂ、店舗Ｃに振り分ける。そして、情報処理装置２３０は、各店舗Ａ、店舗Ｂ、店舗Ｃへの商品配置を決定する。なお、この商品配置の決定は、単にユーザの商品購入要求のみに基づいて行われる必要はない。例えば、ユーザの商品購入要求がバラバラであることにより頻繁に少量の商品が店舗Ａ～Ｃに配送される場合、配送が交通渋滞や温暖化ガスに悪影響を与える。これを避けるためには、適切な頻度で配送が行われるように、ユーザの商品購入要求を各店舗にまとめる必要がある。一方、ユーザの商品購入要求を商品単位でまとめることにより、特定の商品の配置が特定の店舗に偏ると、各店舗の商売に対する介入が強くなり過ぎる。情報処理装置２３０は、これらを考慮して、各店舗への適切な商品配置を決定する。なお、商品の最適配置については、その一例を図１６に従って詳細に後述する。その他、下記の非特許文献１のプログラム決定のアルゴリズム等も使用可能である。

　（非特許文献１）http://www.ai-gakkai.or.jp/jsai/conf/2008/program/pdf/100001.pdf
　次に、情報処理装置２３０は、ステップＳ４０５において、各店舗Ａ～Ｃに対して、配置が決定された商品を入荷するように依頼する。ステップＳ４０７において、その入荷リクエストの通知が情報処理装置２３０から各店舗に送信される。入荷リクエストの通知を受信した店舗が、その入荷リクエストを受諾すれば、ステップＳ４０９において、その店舗は配送センター２５０に対して商品の配送をリクエストする。

　配送センター２５０は、ステップＳ４１１において、配送リクエストへの対応を含む配送スケジュールを決定する。その際、配送センター２５０は、受信した配送リクエストが可能か否か、あるいは、配送回数／距離が増加しないか、などを考慮する。そして、配送センター２５０は、決定した配送スケジュールに従って商品を配送する。配送スケジュールの最適化は、送路問題（VRP － Vehicle Routing Problem）としても知られている。配送問題の解法として、例えば、非特許文献２の『分割配送路問題－ラグランジュ緩和を利用した解法について―』などがある。

　（非特許文献２）http://www.orsj.or.jp/~archive/pdf/e_mag/Vol.39_3_372.pdf
　配送センター２５０から商品の配送を受領した各店舗は、ステップＳ４１３において、商品と数とを含む入荷報告を行なう。情報処理装置２３０は、入荷報告を受信する。情報処理装置２３０は、受信した入荷報告に含まれる入荷商品が、ユーザが商品購入要求した商品であれば、ステップＳ４１５において、商品購入要求をしたユーザに対して入荷情報を報知する。

　なお、上述のように、必ずしも、１回のユーザの商品購入要求に対して１回の商品配置の決定が行われるわけではない場合、情報処理装置２３０は、ユーザに対して、一番近い店舗の入荷情報だけを報知するのではなく、近辺の複数の店舗の情報を入荷スケジュールに従って報知するのが望ましい。また、在庫管理や配送管理の影響により商品入荷数と商品購入要求数も必ずしも一致しない。したがって、情報処理装置２３０は、商品購入要求したユーザだけに入荷情報を報知するのではなく、商品購入要求をしなかった他のユーザにも限定的に入荷情報を報知してもよい。

　《情報処理装置の機能構成》
　図５は、本実施形態に係る情報処理装置２３０の機能構成を示すブロック図である。

　情報処理装置２３０は、ネットワークを介してユーザ端末や店舗端末や配送センターと通信する通信制御部５０１を有する。ユーザ商品購入要求取得部５０２は、通信制御部５０１がユーザ端末から受信したメッセージから、ユーザの商品購入要求を取得する。そして、ユーザ商品購入要求記憶部５０３は、ユーザの商品購入要求をユーザ情報ＤＢ５０４に蓄積する（図８参照）。また、店舗商品入荷情報取得部５０５は、通信制御部５０１が店舗端末から受信したメッセージから、店舗の商品入荷情報を取得する。そして、店舗商品記憶部５０６は、店舗の商品入荷情報を店舗情報ＤＢ５０７に蓄積する（図９参照）。また、ユーザ情報ＤＢ５０４および店舗情報ＤＢ５０７に蓄積されている情報に含まれる商品の詳細な情報は、商品情報ＤＢ５０８に格納されている（図１０参照）。

　店舗商品ニーズ値算出部５１０は、ユーザ情報ＤＢ５０４が蓄積するユーザの所在地およびユーザからの商品購入要求と、店舗情報ＤＢ５０７が蓄積する店舗の所在地とを取得する。そして、店舗商品ニーズ値算出部５１０は、地図情報ＤＢ５０９を参照して算出した、ユーザの所在地と店舗の所在地との間の距離が、第１閾値Ｄｈより近いユーザの商品購入要求から、各店舗における各商品のニーズ値を算出する。店舗商品入荷リクエスト送信部５１１は、店舗商品ニーズ値算出部５１０からの各店舗における各商品のニーズ値が第２閾値Ｎｈを超える商品の入荷リクエストを、対応する各店舗に送信する。

　ユーザ商品購入案内生成部５１２は、ユーザ情報ＤＢ５０４が蓄積するユーザの所在地およびユーザからの商品購入要求と、店舗情報ＤＢ５０７が蓄積した商品入荷情報とを取得する。ユーザ商品購入案内生成部５１２は、地図情報ＤＢ５０９を参照して、各ユーザの所在地と各店舗の所在地とから、各ユーザと各店舗との距離を算出する。そして、ユーザ商品購入案内生成部５１２は、ユーザごとに、ユーザと各店舗との距離を考慮した、各店舗における各商品の購入案内を生成する。ユーザ商品購入案内送信部５１３は、ユーザ商品購入案内生成部５１２が生成した各ユーザへの購入案内を、各ユーザに送信する。かかる購入案内は、ユーザの交通移動量や交通渋滞を考慮して、ユーザごとに適切に誘導する案内であるのが望ましい。しかし、通信のトラフィックを考慮すると、ユーザ商品購入案内生成部５１２は、複数のユーザを所在地や購入要求した商品によりグループ化して、購入案内を同報通信してもよい。

　《ユーザ端末の機能構成》
　図６は、本実施形態に係るユーザ端末２１０、２２０の機能構成を示すブロック図である。なお、ユーザ端末２１０、２２０には種々の機種が使用されてよい。図６には、本実施形態において必須の共通機能のみが示される。

　操作部６０１は、ユーザによるユーザ端末２１０、２２０への操作を受け付ける。ユーザ商品購入要求送信部６０２は、操作部６０１に入力された操作の中で、ユーザの商品購入要求を、通信制御部６０３を介して、情報処理装置２３０に送信する。

　ユーザ商品購入案内受信部６０４は、通信制御部６０３を介して、情報処理装置２３０からユーザへの商品購入案内を受信する。出力部６０５は、表示部６０６と音声入出力部６０７とを有する。表示部６０６はユーザへの商品購入案内を表示する。また、音声入出力部６０７はユーザへの商品購入案内を音声出力してもよい。

　《店舗端末の機能構成》
　図７は、本実施形態に係る店舗端末２４０の機能構成を示すブロック図である。なお、店舗端末２４０には種々の機種が使用されてよい。図７には、本実施形態において必須の共通機能のみが示される。

　操作部７０１は、オペレータによる店舗端末２４０への操作を受け付ける。商品入荷依頼送信部７０２は、操作部７０１に入力された操作の中で、店舗からの商品入荷依頼を、通信制御部７０４を介して、配送センター２５０に送信する。商品入荷通知送信部７０３は、操作部７０１に入力された操作の中で、店舗からの商品入荷通知を、通信制御部７０４を介して、情報処理装置２３０に送信する。

　商品入荷リクエスト受信部７０５は、通信制御部７０４を介して、情報処理装置２３０から店舗への商品入荷リクエストを受信する。出力部７０６は、表示部７０７と音声入出力部７０８とを有する。表示部７０７は店舗への商品入荷リクエストを表示する。また、音声入出力部７０８は店舗への商品入荷リクエストを音声出力してもよい。

　（ユーザ情報ＤＢ）
　図８は、本実施形態に係るユーザ情報ＤＢ５０４の構成を示す図である。ユーザ情報ＤＢ５０４は、本情報処理システムに加入する会員ユーザの情報を蓄積する。なお、ユーザ情報ＤＢ５０４の構成は、図８に限定されない。

　ユーザ情報ＤＢ５０４は、ユーザＩＤ８０１に対応付けて、住所８０２と地図上の座標８０３とを記憶する。さらに、ユーザ情報ＤＢ５０４は、ユーザからの購入要求商品８０４、商品の要求数８０５、要求受信した要求日８０６、商品購入の希望日８０７を記憶する。

　なお、商品購入の希望日８０７は、商品によって異なってよい。また、購入要求商品のデータが蓄積される期間は、情報処理装置２３０における商品配置の調整タイミングとの関連で決められる。例えば、毎週末が調整タイミングであるなら、一週間分の商品購入要求が蓄積される。十日に一回、調整タイミングがあるなら、十日分の商品購入要求が蓄積される。かかる調整タイミングは、商品毎に好適なタイミングであるのが望ましい。

　（店舗情報ＤＢ）
　図９は、本実施形態に係る店舗情報ＤＢ５０７の構成を示す図である。店舗情報ＤＢ５０７は、本情報処理システムに加入する会員店舗の情報を蓄積する。なお、店舗情報ＤＢ５０７の構成は、図９に限定されない。

　店舗情報ＤＢ５０７は、店舗ＩＤ９０１に対応付けて、住所９０２と地図上の座標９０３とを記憶する。さらに、店舗情報ＤＢ５０７は、配送センター２５０への入荷要求商品９０４、入荷数９０５、商品の入荷済みを表わす入荷有無フラグ９０６、入荷予定日９０７を記憶する。ここで、入荷予定日９０７は、入荷要求商品がまだ入荷してないが（入荷有無フラグ９０６は"無"）、入荷予定がある場合の予定日である。

　（商品情報ＤＢ）
　図１０は、本実施形態に係る商品情報ＤＢ５０８の構成を示す図である。なお、商品情報ＤＢ５０８の構成は、図１０に限定されない。

　商品情報ＤＢ５０８は、商品ＩＤ１００１に対応付けて、商品のサイズ／重量１００２、商品の在庫があり配送可能な配送センターＩＤ１００３、標準配送間隔１００４、標準配送数１００５を記憶する。ここで、サイズ／重量１００２は、配送時のトラック占有率などと共に温暖化ガス排出量に関連する情報である。また、配送センターＩＤ１００３、標準配送間隔１００４、標準配送数１００５なども、店舗からの入荷依頼への対処において、別途に配送トラックを準備することによる交通渋滞への影響や、温暖化ガス排出量に関連する情報である。

　（流通／在庫管理ＤＢ）
　図１１は、本実施形態に係る流通／在庫管理ＤＢ１１００の構成を示す図である。なお、流通／在庫管理ＤＢ１１００の構成は、図１１に限定されない。

　本実施形態においては、ユーザによる商品購入要求に基づく、店舗での商品入荷やユーザへの商品購入案内のみが説明される。しかし、実際の商品流通や在庫の管理は、ユーザによる商品購入要求のみでなく、月や季節、年などの中長期スパン、あるいは催しものや人気などの短期スパンの、製造・流通・在庫・販売の統計手法によって行われる。本実施形態の交通渋滞緩和のための商品配置は、これら既存の商品流通や在庫管理技術と組み合わせることで、さらに好適な商品配置を達成できる。そして、本実施形態の交通渋滞緩和のための商品配置は、交通渋滞緩和や温暖化ガス排出量削減を促進できる。ここでは、そのための流通／在庫管理ＤＢ１１００の構成の一例が示される。しかし、本発明の各実施形態の説明では、流通／在庫管理についての説明は省略される。

　流通／在庫管理ＤＢ１１００は、本実施形態の例では、配送センターや店舗などの商品の在庫場所１１０１に対応付けて、在庫する商品ＩＤ１１０２を記憶する。なお、在庫場所１１０１は、製造工場や列車・飛行機・船の集荷場などを含んでもよい。そして、流通／在庫管理ＤＢ１１００は、各商品ＩＤ１１０２に対応付けて、入荷や出荷（販売）の前の在庫数１１０３、入荷数１１０４、出荷（販売）数１１０５、入荷や出荷（販売）後の在庫数１１０６を記憶する。なお、入荷や出荷（販売）後の在庫数１１０６は、次の処理のため、入荷や出荷（販売）の前の在庫数１１０３にコピーされる。

　《情報処理装置のハードウェア構成》
　図１２は、本実施形態に係る情報処理装置２３０のハードウェア構成を示すブロック図である。

　図１２で、ＣＰＵ１２１０は演算制御用のプロセッサである。ＣＰＵ１２１０は、プログラムを実行することで、図５の情報処理装置２３０の各機能構成部として動作する。ＲＯＭ１２２０は、初期データおよびプログラムなどの固定データおよびプログラムを記憶する。また、通信制御部５０１は、本実施形態においては、ネットワークを介してユーザ端末２１０、２２０や店舗端末２４０と通信する。なお、ＣＰＵ１２１０は１つに限定されない。ＣＰＵ１２１０は、複数のＣＰＵであっても、あるいは画像処理用のＧＰＵ(Graphics Processing Unit)を含んでもよい。

　ＲＡＭ１２４０は、ＣＰＵ１２１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ１２４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。ユーザＩＤ／認証情報１２４１は、通信相手のユーザ端末を操作するユーザの識別子とその認証情報である。商品購入要求テーブル１２４２は、ユーザ端末から受信した商品購入要求が商品単位でまとめられたテーブルである（図１３参照）。商品購入案内情報１２４３は、各ユーザ端末に送信される商品購入案内を表わす情報である。店舗ＩＤ１２４４は、通信相手である店舗端末を有する店舗の識別子である。商品ニーズテーブル１２４５は、店舗ごとに各商品のニーズがまとめられたテーブルである（図１４参照）。商品入荷リクエスト情報１２４６は、各店舗に送信される商品入荷リクエストを表わす情報である。商品入荷情報１２４７は、各店舗から通知された商品入荷を表す情報である。流通／在庫管理情報１２４８は、流通および在庫管理に使用される情報である。送受信データ１２４９は、ユーザ端末および店舗端末と通信制御部５０１を介して送受信されるデータである。

　ストレージ１２５０には、データベース、各種のパラメータ、本実施形態の実現に必要な以下のデータおよびプログラムが記憶されている。ユーザ情報ＤＢ５０４は、図８に示されるデータベースである。店舗情報ＤＢ５０７は、図９に示されるデータベースである。商品情報ＤＢ５０８は、図１０に示されるデータベースである。地図情報ＤＢ５０９は、ユーザの所在地や店舗の所在地から距離などを算出するために参照するデータベースである。流通／在庫管理ＤＢ１１００は、図１１に示されるデータベースである。

　ストレージ１２５０には、以下のプログラムが格納される。情報処理制御プログラム１２５１は、本情報処理装置２３０の全体を制御するプログラムである。商品購入要求収集モジュール１２５２は、情報処理制御プログラム１２５１において、ユーザ端末からのユーザの商品購入要求を収集してユーザ情報ＤＢ５０４に蓄積するモジュールである。商品ニーズ値算出モジュール１２５３は、情報処理制御プログラム１２５１において、収集されたユーザの商品購入要求から各店舗の各商品の商品ニーズ値を算出するモジュールである（図１６参照）。商品入荷制御モジュール１２５４は、情報処理制御プログラム１２５１において、各店舗に商品入荷を依頼し、また商品入荷を受信するモジュールである。商品購入案内モジュール１２５５は、ユーザ端末に対して、近い店舗における要求商品の購入を案内するモジュールである（図１７参照）。

　なお、図１２には、本実施形態に必須なデータやプログラムのみが示されている。図１２には、本実施形態に関連しないデータやプログラムは図示されていない。

　（商品購入要求テーブル）
　図１３は、本実施形態に係る商品購入要求テーブル１２４２の構成を示す図である。

　商品購入要求テーブル１２４２は、ユーザから商品購入要求のあった商品ＩＤ１３０１に対応付けて、商品購入したユーザＩＤ１３０２を記憶する。そして、商品購入要求テーブル１２４２は、各ユーザＩＤ１３０２に対応付けて、ユーザ所在地の地図上の座標１３０３、商品の要求数１３０４、購入の希望日１３０５、を記憶する。なお、商品購入の希望日８０７は、商品によって異なってよい。

　（商品ニーズテーブル）
　図１４は、本実施形態に係る商品ニーズテーブル１２４５の構成を示す図である。

　商品ニーズテーブル１２４５は、店舗ＩＤ１４０１に対応付けて、購入要求のある商品ＩＤ１４０２を記憶する。そして、商品ニーズテーブル１２４５は、各商品ＩＤ１４０２に対応付けて、後述のユーザ所在地と店舗との距離や優先度を基に算出された各商品のニーズ値１４０３、ニーズ値の閾値の比較結果である商品の配置要否フラグ１４０４、入荷有無フラグ１４０５を記憶する。

　《情報処理装置の動作手順》
　図１５は、本実施形態に係る情報処理装置２３０の動作手順を示すフローチャートである。図１２のＣＰＵ１２１０は、ＲＡＭ１２４０を使用しながらプログラムを実行することにより、図５の各機能構成部として、このフローチャートの動作を行う。

　まず、ステップＳ１５１１において、ユーザ商品購入要求取得部５０２は、ユーザの商品購入要求をユーザ端末から受信した否かを判定する。また、ステップＳ１５２１において、店舗商品ニーズ値算出部５１０は、店舗における商品配置を調整するタイミングであるか否かを判定する。なお、商品配置の調整タイミングを、例えば、日毎、週毎、月毎など、自由に設定することが可能である。また、商品ごとに異なるタイミングを設定することも可能である。また、ステップＳ１５３１においては、店舗商品入荷情報取得部５０５は、商品の入荷済み通知を店舗から受信したか否かを判定する。

　ユーザ商品購入要求取得部５０２は、商品購入要求をユーザ端末から受信した場合はステップＳ１５１３に進んで、ユーザ情報ＤＢ５０４に商品とユーザを対応づけて記憶する。

　店舗商品ニーズ値算出部５１０は、商品配置を調整するタイミングであればステップＳ１５２３に進んで、各店舗の各商品について商品ニーズ値を算出する処理を行なう（図１６参照）。次に、ステップＳ１５２５において、店舗商品入荷リクエスト送信部５１１は、算出したニーズ値を使用して各店舗への商品配置最適化処理を実行する（図１７参照）。そして、店舗商品入荷リクエスト送信部５１１は、各店舗に商品配置調整の入荷リクエストを行なう。なお、配送センターから各店舗への配送車両が交通渋滞の一因であるために配送スケジュールを考慮し、また、配送センターや各店舗の在庫も考慮する場合に、ステップＳ１５２５の商品配置最適化処理は実行される。したがって、店舗への商品配置の決定を商品ニーズ値のみに委ねる場合には、ステップＳ１５２５の商品配置最適化処理は無くてもよい。

　また、店舗商品入荷情報取得部５０５が商品の入荷済み通知を店舗から受信した場合はステップＳ１５３３に進んで、ユーザ商品購入案内送信部５１３は、各店舗の範囲にあるユーザ端末に商品入荷情報を通知して、商品購入案内をする。なお、ユーザ商品購入案内送信部５１３は、複数の店舗の商品入荷情報をスケジュールと共に報知してもよい。

　（商品ニーズ値算出処理）
　図１６は、本実施形態に係る商品ニーズ値算出処理Ｓ１５２３の動作手順を示すフローチャートである。

　まず、店舗商品ニーズ値算出部５１０は、ステップＳ１６０１において、配置調整を行なう商品を選別する。店舗商品ニーズ値算出部５１０は、例えば、以下のように、商品を選別する。店舗商品ニーズ値算出部５１０は、基本的に、ユーザが、今すぐではないが近いうちに必要であると考えている商品（または情報でも可）を選別する。具体的には、店舗商品ニーズ値算出部５１０は、ユーザが毎日の買い物で買うような生鮮食品ではなく、ユーザが週末などにまとめて買えば十分であるもの（日用品、文房具、ゲーム、調味料類、家電類、洋服類など）を選別することが考えられる。しかし、これに限定される訳ではない。

　ステップＳ１６０３において、店舗商品ニーズ値算出部５１０は、地域内から１つの注目する店舗を選択する。次に、ステップＳ１６０５において、店舗商品ニーズ値算出部５１０は、選別された商品から１つの注目する商品を選択する。そして、ステップＳ１６０７において、店舗商品ニーズ値算出部５１０は、選択した店舗に行けるユーザの購入要求から、選択した商品の購入要求を選別して収集する。なお、ここで、店舗商品ニーズ値算出部５１０は、単純にユーザの所在地と選択した店舗の所在地間の距離が閾値以内（例えば、１ｋｍ以内など）であることを、選択した店舗に行けるユーザの条件としてもよい。また、選択した店舗に行けるユーザの条件は、ユーザの所在地と店舗の所在地の間の距離や必要時間、行くための交通機関の利用状態、店舗まで行くには車が必要か／自転車か／徒歩か、あるいは、ユーザの年齢や健康状態などに対する条件を含んでもよい。ユーザの所在地と店舗の所在地の間の必要時間に対する条件として、例えば、所要時間が車で１０分以内であること、あるいは所要時間自転車で１０分以内であることなどが考えられる。あるいは、さらに詳細に駐車場や駐輪場からの徒歩時間、公共交通を使う場合の車や自転車、徒歩を考慮した所要時間が条件であってもよい。あるいは、店舗商品ニーズ値算出部５１０は、これら条件を組み合わせて判断してもよい。もしくは、店舗商品ニーズ値算出部５１０は、距離や時間、条件では区切らず、あるエリア内の全ユーザを、そのエリア内の店舗のいずれかに割り振るようにする。ユーザを割り振る方法として、各ユーザを、最も近い店舗に割り振る方法もある。各ユーザを最も近い店舗に割り振った結果、一店舗にユーザが集中するのであれば、多少遠くても違う店舗に割り振る方法もある。これらの方法によって、全てのユーザが商品購入要求に対して少なくとも１店舗への購入案内を受けるようにするのが望ましい。

　ステップＳ１６０９において、店舗商品ニーズ値算出部５１０は、ステップＳ１６０７で収集した各ユーザの商品購入要求を、ユーザの所在地と店舗の所在地間の距離と、商品購入の優先度とに基づいて、１つの店舗の１つの商品について商品のニーズ値を算出する。

　店舗商品ニーズ値算出部５１０は、商品のニーズ値算出を、例えば、以下の式に従って行なう。すなわち、店舗商品ニーズ値算出部５１０は、選択した店舗に行けるユーザ全員によるニーズ値を加算した値を、１つの店舗の１つの商品について商品のニーズ値とする。

　各ユーザのニーズ値＝｛商品の優先度/店舗までの距離｝×α(ユーザ）
　商品のニーズ値＝Σ｛商品の優先度/店舗までの距離｝×α(ユーザ）
　ここで、Σは、選択した店舗に行けるユーザ全員のニーズ値を加算することを表す。そして、αは、距離と優先度との間で重みを調整するための、ユーザ毎の補正値である。なお、本実施形態においては、交通渋滞の緩和を目標としているので、全体としては、ユーザに不満を与えない範囲で優先度よりも距離に重みをおくように調整が加えられてもよい。

　次に、ステップＳ１６１１において、店舗商品入荷リクエスト送信部５１１は、算出されたニーズ値が第２閾値Ｎｈを超えるか否かを判定する。算出されたニーズ値が第２閾値Ｎｈを超える場合、ステップＳ１６１３において、店舗商品入荷リクエスト送信部５１１は、そのニーズ値を持つ商品を配置調整する商品に決定する。

　ステップＳ１６１５において、選択された１つの店舗について、ステップＳ１６０１で選別された全商品に対するニーズ値算出と配置調整決定とが完了するまで、ステップＳ１６０５からＳ１６１５の処理が繰り返されるように、処理が分岐する。また、ステップＳ１６１７において、全店舗の、ステップＳ１６０１で選別された全商品についてニーズ値算出と配置調整決定とが完了するまで、ステップＳ１６０３からＳ１６１７の処理が繰り返されるように、処理が分岐する。

　なお、ステップＳ１６１１とＳ１６１３の処理は、全店舗あるいは全商品についてのニーズ値算出の後に実行されてもよい。

　例えば、ステップＳ１６０９において得られた、店舗Ａと店舗Ｂにおけるニーズ値の算出の結果が、店舗Ａ（調味料類10、日用雑貨7、文房具5、衣料品4）、店舗Ｂ（調味料類8、日用雑貨11、文房具6、衣料品2）である例について説明する。第２閾値Ｎｈが"９"である場合、店舗Ａには"調味料類"の配送が行われ、店舗Ｂには"日用雑貨"の配送が行なわれる。また、第２閾値Ｎｈが"６"である場合、月曜日には、店舗Ａに"調味料類"、店舗Ｂに"日用雑貨"が配送され、火曜日には、店舗Ａに"日用雑貨"、店舗Ｂに"調味料類"が配送されるように、配置スケジュールが決定されてもよい。なお、第２閾値Ｎｈは、商品の配分過程で変化するのが望ましい。なぜなら、本例のような配置制御をすると、次第にニーズ値の低い商品が配送センターに残っていき、店舗に配置されない商品が発生してしまうからである。したがって、その場合には、第２閾値Ｎｈを下げる必要が出てくる。例えば、ニーズ値の最大値に比例するように第２閾値Ｎｈを設定するのも、１つの解決方法である。

　（商品配置最適化処理）
　図１７は、本実施形態に係る商品配置最適化処理Ｓ１５２５の動作手順を示すフローチャートである。

　まず、ステップＳ１７０１において、店舗商品入荷リクエスト送信部５１１は、商品ニーズ値算出処理Ｓ１５２３において決定された、各店舗の各商品の配置調整の結果を取得する。次に、ステップＳ１７０３において、店舗商品入荷リクエスト送信部５１１は、各店舗および各商品の優先度を設定する。かかる"優先度"は、ニーズ値算出時のユーザの有する優先度とは異なり、各店舗が交通渋滞に関係する度合いや、本システムの交通渋滞緩和への貢献度なども考慮された優先度である。

　ステップＳ１７０５において、店舗商品入荷リクエスト送信部５１１は、配送センターや各店舗の在庫情報を、流通／在庫管理ＤＢ１１００から取得する。かかる在庫情報は、配送可能な商品や各店舗の在庫がユーザの要求をどこまで補えるかなどを考慮するために使用される。また、ステップＳ１７０７において、店舗商品入荷リクエスト送信部５１１は、配送センターの流通／在庫管理に基づく配送スケジュールを取得する。この配送スケジュールは、個々のユーザの商品購入要求とは別に、統計的な流通／在庫管理から計画されたものである。ここでは、配送トラックの交通渋滞への影響も考慮するために考慮される。

　そして、ステップＳ１７０９において、店舗商品入荷リクエスト送信部５１１は、上記各取得情報および設定情報に基づいて、各店舗への各商品の適切な入荷期待値を決定する。かかる多条件による本実施形態の商品配置の最適化は、ユーザへのサービスを維持しながら、ユーザの交通移動量と配送のためのトラック移動量とを削減して、交通渋滞緩和を実現する。

　《ユーザ端末のハードウェア構成》
　図１８は、本実施形態に係るユーザ端末２１０、２２０のハードウェア構成を示すブロック図である。

　図１８で、ＣＰＵ１８１０は演算制御用のプロセッサである。ＣＰＵ１８１０は、プログラムを実行することで図６のユーザ端末２１０、２２０の各機能構成部として動作する。ＲＯＭ１８２０は、初期データなどの固定データおよびプログラムを記憶する。また、通信制御部６０３は、本実施形態においては、ネットワークを介して情報処理装置２３０と通信する。なお、ＣＰＵ１８１０は１つに限定されない。ＣＰＵ１８１０は複数のＣＰＵであってもよい。ＣＰＵ１８１０は画像処理用のＧＰＵを含んでもよい。

　ＲＡＭ１８４０は、ＣＰＵ１８１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ１８４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。ユーザＩＤ／認証情報１８４１は、ユーザ端末を操作中のユーザの識別子とその認証情報である。ユーザ端末ＩＤ１８４２は、当該ユーザ端末の識別子である。商品購入要求情報１８４３は、情報処理装置２３０に送信される、ユーザが入力した商品購入要求の情報である。商品購入案内情報１８４４は、情報処理装置２３０から受信した商品購入案内の情報である。入出力データ１８４５は、入出力インタフェース１８６０を介して入出力される入出力データを表す。送受信データ１８４６は、通信制御部６０３を介して送受信される送受信データを表す。

　ストレージ１８５０には、データベースと、各種のパラメータと、本実施形態の実現に必要な以下のデータとプログラムが記憶されている。商品購入要求履歴１８５１は、自ユーザ端末が情報処理装置２３０に送信した商品購入要求が蓄積された履歴である。商品購入案内履歴１８５２は、自ユーザ端末が情報処理装置２３０から受信した商品購入案内が蓄積された履歴である。これらは、ユーザあるいはシステムによる確認のため使用される。ストレージ１８５０には、以下のプログラムが格納される。ユーザ端末制御プログラム１８５３は、本ユーザ端末２１０、２２０の全体を制御する制御プログラムである。商品購入要求モジュール１８５４は、ユーザ端末制御プログラム１８５３において、ユーザによる商品購入要求の入力と商品購入要求の情報処理装置２３０への送信とを制御するモジュールである。商品購入案内モジュール１８５５は、ユーザ端末制御プログラム１８５３において、情報処理装置２３０からの商品購入案内の受信と商品購入案内の自ユーザ端末からユーザへの報知を制御するモジュールである。

　入出力インタフェース１８６０は、入出力機器との入出力データをインタフェースする。入出力インタフェース１８６０には、表示部６０６、キーボード、タッチパネル、ポインティンデバイスなどの操作部６０１が接続される。また、入出力インタフェース１８６０には、スピーカやマイクなどの音声入出力部６０７が接続される。さらに、入出力インタフェース１８６０には、ＧＰＳ(Global Positioning System)位置生成部１８６１やカメラ１８６２などが接続される。

　なお、図１８には、本実施形態に必須なデータやプログラムのみが示されている。図１８には、本実施形態に関連しないデータやプログラムは図示されていない。

　《ユーザ端末の処理手順》
　図１９は、本実施形態に係るユーザ端末２１０、２２０の処理手順を示すフローチャートである。図１８のＣＰＵ１８１０は、ＲＡＭ１８４０を使用しながらプログラムを実行することにより、図６の各機能構成部として、このフローチャートの動作を行う。

　まず、ステップＳ１９１１において、ユーザ商品購入要求送信部６０２は、ユーザによる商品購入要求があるか否かを判定する。また、ステップＳ１９２１において、ユーザ商品購入案内受信部６０４は、情報処理装置２３０からの商品購入案内の受信があるか否かを判定する。

　ユーザによる商品購入要求があれば、ステップＳ１９１３に進んで、ユーザ商品購入要求送信部６０２は、ユーザがユーザ端末の表示画面や操作部６０１などを使用して入力した、商品名、購入数、購入希望日などを取得する（図２参照）。続いて、ステップＳ１９１５において、ユーザ商品購入要求送信部６０２は、取得した商品名、購入数、購入希望日などを情報処理装置２３０に送信する。

　また、情報処理装置２３０からの商品購入案内の受信があれば、ステップＳ１９２３に進んで、ユーザ商品購入案内受信部６０４は、商品名、その商品が購入可能な店舗、入荷スケジュールである入荷日などを取得する。なお、ユーザ商品購入案内受信部６０４は、複数の店舗の入荷スケジュールを受信してもよい。続いて、ステップＳ１９２５において、出力部６０５は、取得した商品名、店舗、入荷日などを表示あるいは音声により報知する。

　《店舗端末のハードウェア構成》
　図２０は、本実施形態に係る店舗端末２４０のハードウェア構成を示すブロック図である。

　図２０で、ＣＰＵ２０１０は演算制御用のプロセッサである。ＣＰＵ２０１０は、プログラムを実行することで、図７の店舗端末２４０の各機能構成部として動作する。ＲＯＭ２０２０は、初期データなどの固定データおよびプログラムを記憶する。また、通信制御部７０４は、本実施形態においては、ネットワークを介して情報処理装置２３０あるいは配送センター２５０と通信する。なお、ＣＰＵ２０１０は１つに限定されない。ＣＰＵ２０１０は複数のＣＰＵであってもよい。ＣＰＵ２０１０は画像処理用のＧＰＵを含んでもよい。

　ＲＡＭ２０４０は、ＣＰＵ２０１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ２０４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。オペレータＩＤ／認証情報２０４１は、店舗端末を操作中のオペレータの識別子とその認証情報である。店舗端末ＩＤ２０４２は、当該店舗端末の識別子である。商品入荷リクエスト情報２０４３は、情報処理装置２３０から受信した商品入荷リクエストの情報である。商品入荷済情報２０４４は、オペレータが入力した、情報処理装置２３０に送信される、商品入荷済みを確認するための情報である。入出力データ２０４５は、入出力インタフェース２０６０を介して入出力される入出力データを表す。送受信データ２０４６は、通信制御部７０４を介して送受信される送受信データを表す。

　ストレージ２０５０には、データベースと、各種のパラメータと、本実施形態の実現に必要な以下のデータとプログラムが記憶されている。在庫管理ＤＢ２０５１は、自店舗の商品の在庫管理を行なうためのデータベースである。売上管理ＤＢ２０５２は、自店舗の商品の売上げ管理を行なうためのデータベースである。ストレージ２０５０には、以下のプログラムが格納される。店舗端末制御プログラム２０５３は、本店舗端末２４０の全体を制御する制御プログラムである。商品入荷リクエストモジュール２０５４は、店舗端末制御プログラム２０５３において、情報処理装置２３０からの商品入荷リクエストの受信と店舗端末からオペレータへの報知を制御するモジュールである。商品入荷通知モジュール２０５５は、店舗端末制御プログラム２０５３において、オペレレータによる商品入荷済みの入力と、商品入荷情報の情報処理装置２３０への送信とを制御するモジュールである。

　入出力インタフェース２０６０は、入出力機器との入出力データをインタフェースする。入出力インタフェース２０６０には、表示部７０７、キーボード、タッチパネル、ポインティンデバイスなどの操作部７０１が接続される。また、入出力インタフェース２０６０には、スピーカやマイクなどの音声入出力部７０８が接続される。入出力インタフェース２０６０には、さらに、図示しない、ＧＰＳ位置生成部やカメラなどが接続されてもよい。

　なお、図２０には、本実施形態に必須なデータやプログラムのみが示されている。図２０には、本実施形態に関連しないデータやプログラムは図示されていない。

　《店舗端末の処理手順》
　図２１は、本実施形態に係る店舗端末２４０の処理手順を示すフローチャートである。図２０のＣＰＵ２０１０は、ＲＡＭ２０４０を使用しながらプログラムを実行することにより、図７の各機能構成部として、このフローチャートの動作を行う。

　まず、ステップＳ２１１１において、商品入荷リクエスト受信部７０５は、情報処理装置２３０からの商品入荷リクエストの受信があるか否かを判定する。また、ステップＳ１９２１において、商品入荷通知送信部７０３は、オペレータによる情報処理装置２３０への商品入荷通知があるか否かを判定する。

　情報処理装置２３０からの商品入荷リクエストの受信があれば、ステップＳ２１１３に進んで、商品入荷リクエスト受信部７０５は、情報処理装置２３０から受信した商品入荷リクエストの情報を取得する（図２参照）。そして、ステップＳ２１１５において、出力部７０６は、取得した商品入荷リクエスト情報を表示あるいは音声によりオペレータに報知する。

　また、オペレータによる商品入荷通知があれば、ステップＳ２１２３に進んで、商品入荷通知送信部７０３は、オペレータが店舗端末の表示画面や操作部７０１などを使用して入力した、商品入荷情報を取得する。続いて、ステップＳ２１２５において、商品入荷通知送信部７０３は、商品入荷に基づいて在庫管理ＤＢ２０５１および売上管理ＤＢ２０５２を更新する。そして、ステップＳ２１２７において、商品入荷通知送信部７０３は、商品入荷情報を情報処理装置２３０に送信する。

　［第３実施形態］
　次に、本発明の第３実施形態に係る情報処理システムについて説明する。本実施形態に係る情報処理システムは、上記第２実施形態と比べると、ユーザが購入要求する商品を用意する店舗を周回させてユーザの移動を分散する点で異なる。その他の構成および動作は、第２実施形態と同様である。そのため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

　本実施形態によれば、各ユーザは購入を要求した商品をより近い店舗で購入できるためにユーザの交通移動量が削減されると共に、ユーザの移動日が分散されることにより、さらに交通渋滞を緩和することができる。

　《情報処理システムの動作手順》
　図２２は、本実施形態に係る情報処理システム２２００の動作手順を示すシーケンス図である。なお、図２２において、店舗Ｂが選択され、商品が店舗Ｂに入荷するように誘導する例を説明する。図２２において、第２実施形態の図４と同様のステップには同じステップ番号を付して、説明を省略する。

　ステップＳ２２０３において、情報処理装置２２３０は、各ユーザからの商品購入要求を収集する。そして、情報処理装置２２３０は、第２実施形態と同様に商品のニーズ値を算出して、商品配置の最適化処理を行なう。しかし、情報処理装置２２３０は、ステップＳ２２０３において、その処理中あるいは処理後に、店舗選択テーブル２３１４（図２４）を参照して、ある範囲内にある店舗グループ間で商品入荷を周回させる。すなわち、情報処理装置２２３０は、ユーザの商品購入要求を単純に最短距離の店舗に分散するのではなく、商品が入荷しユーザへの商品案内が行われる店舗を、交通渋滞緩和を図れるように店舗グループ間で計画的に周回させる。第２実施形態のように、ユーザの商品購入要求を単純に最短距離の店舗に分散させるだけでは、店舗による商品販売数の偏りなどにより新たに交通渋滞が発生する可能性がある。情報処理装置２２３０は、上述の処理によって、店舗による商品販売数の偏りなどにより新たに交通渋滞が発生する可能性を回避する。

　次に、情報処理装置２２３０は、ステップＳ２２０５において、選択された店舗への商品配置依頼を行なう。本例では店舗Ｂが選択された店舗である。なお、情報処理装置２２３０は、商品毎に店舗を選択してもよい。情報処理装置２２３０は、例えば店舗Ａから店舗Ｃまでのいずれかの店舗が最短距離の店舗であるユーザから要求があった全商品に対して、店舗Ｂを選択してもよい。また、情報処理装置２２３０は、ユーザから要求があった、店舗Ａ乃至店舗Ｃにおいて共通の商品を選択してもよい。情報処理装置２２３０は、逆に、ユーザから要求があった、各店舗において共通の商品を、各店舗に分散させてもよい。

　ステップＳ２２０７において商品入荷リクエストを受信した店舗Ｂの店舗端末２４０は、ステップＳ２２０９において、商品の配送リクエストを配送センター２５０に送信する。なお、上述のように、入荷リクエストや配送リクエストは、ステップＳ２２０３の商品配置決定処理の結果に従って行われるので、入荷リクエストや配送リクエストには、店舗Ｂが通常は在庫していない商品が含まれ得る。

　店舗Ｂの店舗端末２４０が配送リクエストを送信した商品が、配送センター２５０から、配送スケジュールも考慮して、店舗Ｂに入荷すると、ステップＳ２２１３において、店舗Ｂの店舗端末２４０は、情報処理装置２２３０に入荷報告を行なう。なお、ステップＳ４１５における情報処理装置２２３０からユーザ端末への商品案内情報の送信は、店舗Ｂの範囲３２０内のユーザに対してだけでなく、店舗Ａおよび店舗Ｃの範囲内のユーザに対しても行われる。なお、この場合、商品案内情報の送信の対象者は、商品購入要求したユーザ全員でなくてよい。情報処理装置２２３０は、別の距離の閾値を設けて、商品案内情報が送信されるユーザを選択してもよい。あるいは、情報処理装置２２３０は、商品購入要求をした順に所定数の、商品案内情報が送信されるユーザを選択してもよい。選択は、ユーザへのサービスを維持して、交通渋滞緩和を促進するように行なわれればよい。

　《情報処理装置の機能構成》
　図２３は、本実施形態に係る情報処理装置２２３０の機能構成を示すブロック図である。なお、図２３において、第２実施形態の図５と同様の機能構成部には同じ参照番号を付して、説明を省略する。

　店舗選択テーブル２３１４は、ユーザが購入要求をした、日用品、文房具、ゲーム、調味料類、家電類、洋服類などの商品毎に、グループ分けされた地域内の店舗の、グループ内の周回の順序を記憶する（図２４参照）。店舗商品入荷リクエスト送信部２３１１は、第２実施形態と比較すると、商品入荷リクエストを送信する店舗の選択において、店舗選択テーブル２３１４を参照する点で異なる。

　（店舗選択テーブル）
　図２４は、本実施形態に係る店舗選択テーブル２３１４の構成を示す図である。店舗選択テーブル２３１４の構成は、図２４に限定されない。

　店舗選択テーブル２３１４は、商品ＩＤ２４０１に対応付けて、店舗の周回順である店舗周回グループ２４０２を記憶する。例えば、図２４においては、第１の商品は、巡回の順序が店舗Ａ→店舗Ｂ→店舗Ｃであるグループと、巡回の順序が店舗Ｄ→店舗Ｆ→店舗Ｅ→店舗Ｇであるグループとを含む、店舗周回グループ２４０２に対応付けられている。また、第２の商品は、巡回の順序が店舗Ａ→店舗Ｇ→店舗Ｄであるグループと、巡回の順序が店舗Ｂ→店舗Ｅ→店舗Ｆであるグループとを含む、店舗周回グループ２４０２に対応付けられている。上述のように、商品ごとに店舗グループを生成しても、全商品について店舗グループを生成してもよい。

　《情報処理装置の動作手順》
　図２５は、本実施形態に係る情報処理装置２２３０の動作手順を示すフローチャートである。図１２のＣＰＵ１２１０がＲＡＭ１２４０を使用しながらプログラムを実行することで、図２３の各機能構成部として、このフローチャートの動作を行う。なお、第２実施形態の図１５と同様のステップには同じステップ番号を付して、説明を省略する。

　第２実施形態の図１５との相違は、ステップＳ２５２５における、商品配置最適化処理である（図２６参照）。ステップＳ２５２５において、店舗商品入荷リクエスト送信部２３１１は、店舗選択テーブル２３１４も考慮して、商品配置の最適化が行なわれる。他のステップは、第２実施形態の図１５と同様である。

　（商品配置最適化処理）
　図２６は、本実施形態に係る商品配置最適化処理２５２５の動作手順を示すフローチャートである。なお、図２６において、第２実施形態の図１７と同様のステップには同じステップ番号を付して、説明を省略する。

　図２６においては、ステップＳ２６０３において、店舗商品入荷リクエスト送信部２３１１は、店舗選択テーブル２３１４から店舗周回情報を取得する。そして、ステップＳ２６０９において、店舗商品入荷リクエスト送信部２３１１は、第２実施形態と同様に、各店舗および各商品の配置調整情報、各店舗および各商品の優先度、配送センターおよび店舗の在庫情報、配送センターの配送スケジュールを決定する。加えて、店舗商品入荷リクエスト送信部２３１１は、店舗周回情報を考慮して、各店舗および各商品の入荷期待値を決定する。

　なお、商品が配置される店舗の選択への店舗周回情報の寄与度は、ユーザの密集程度により異なってもよい。例えば、狭い範囲にユーザが密集している高層マンションや団地などでは、店舗周回の対象の商品を少量の商品に限定することが、交通渋滞緩和のために有利である。一方、郊外の住宅地などの、ユーザが比較的密集していない地域では、店舗周回の対象の商品を少量の商品に限定せずユーザへの商品購入案内を制御することにより、購入日時を分散させることも考えられる。

　［第４実施形態］
　次に、本発明の第４実施形態に係る情報処理システムについて説明する。本実施形態に係る情報処理システムは、上記第２および第３実施形態と比べると、以下の点で異なる。本実施形態の情報処理システムは、ユーザの商品購入要求や商品購入の履歴に基づいてユーザの商品購入要求を予測する。本実施形態の情報処理システムは、その商品購入要求の予測を基に商品を各店舗に用意させる。そして、本実施形態の情報処理システムは、当該ユーザに各店舗での商品購入案内を送信する。その他の構成および動作は、第２実施形態あるいは第３実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

　本実施形態によれば、あらかじめ予測されたユーザの商品購入要求による店舗での商品の用意がより長い時間軸でスケジュールされる。よって、ユーザの交通移動量の削減あるいはユーザの移動日の分散がより適切になる。従って、さらに交通渋滞を緩和することができる。

　なお、本実施形態の情報処理システムは、本実施形態の商品購入要求の予測と、第２実施形態のユーザの実際の商品購入要求とを組み合わせて、各店舗の商品用意とユーザへの商品購入案内とを行なうことができる。この場合に、予測された要求と実際の要求とに重み付けを行なうか、あるいはそれらが時間的に近い要求である場合はそれらが同じ要求であるとみなして一方を削除するなどの組み合わせ操作を行なうのが望ましい。

　《情報処理システムの動作手順》
　図２７は、本実施形態に係る情報処理システム２７００の動作手順を示すシーケンス図である。なお、図２７においては、ユーザ端末と店舗の端末は、それぞれ、１つのユーザ端末と１つの店舗の端末として図示される。しかし、図４のように、複数の範囲のそれぞれに、ユーザ端末と店舗の端末があるものとする。また、店舗から配送センター２５０への配送依頼と商品配送については省略されている。

　まず、情報処理装置２７３０のリクエスト学習ＤＢ２８１７（図２９参照）へのデータ蓄積の手順を説明する。情報処理装置２７３０は、ステップＳ２７０１においてユーザ端末からの商品購入要求を受信すると、その商品購入要求をリクエスト学習ＤＢ２８１７に転送する。そして、ステップＳ２７０３において、情報処理装置２７３０は、リクエスト学習ＤＢ２８１７に商品購入要求データを蓄積する。また、情報処理装置２７３０は、ステップＳ２７０５において店舗端末からの商品販売結果を受信すると、その商品販売結果をリクエスト学習ＤＢ２８１７に転送する。そして、ステップＳ２７０７において、情報処理装置２７３０は、リクエスト学習ＤＢ２８１７に商品販売データを蓄積する。かかる商品購入要求データと商品販売データとの蓄積は、継続して行われる。

　情報処理装置２７３０は、商品配置調整のタイミングになった場合、ステップＳ２７１１において、リクエスト学習ＤＢ２８１７から商品購入要求履歴と商品販売データである商品購入履歴とを読み出す。そして、情報処理装置２７３０は、ステップＳ２７１３において、今までのユーザの購入要求履歴と商品購入履歴とを参照して、各ユーザについて各商品の購入要求を予測する。予測された商品購入要求は、ユーザの疑似商品購入要求として、以下の商品配置処理に使われる。なお、実際には、ステップＳ２７１５のように、ユーザの商品購入要求も並行して行なわれる。その場合には、ステップＳ２７１７において、情報処理装置２７３０は、リクエスト学習ＤＢ２８１７に商品購入要求データを蓄積する。

　情報処理装置２７３０は、ステップＳ２７１９において、予測された商品購入要求のスケジュールである購入予測スケジュールから、各店舗の入荷リクエストを生成する。情報処理装置２７３０は、この入荷リクエストの生成において、実際の商品購入要求を追加して使用してもよい。あるいは、情報処理装置２７３０は、予測された商品購入要求に重なる、ユーザからの商品購入要求があれば、一方のみを使用する処理を行なってもよい。そして、情報処理装置２７３０は、ステップＳ２７２１において、店舗の店舗端末に対して入荷リクエストを送信する。

　ステップＳ２７２３において、店舗における入荷処理が行なわれると、ステップＳ２７２５において、店舗の端末は、入荷情報を情報処理装置２７３０に通知する。情報処理装置２７３０は、入荷情報を受けて、商品案内情報を対応するユーザ端末に送信する。商品案内情報を受信したユーザ端末は、ステップＳ２７３１において、商品案内情報を報知する。

　ユーザが商品案内情報のあった商品を購入すると、ステップＳ２７３３において、店舗端末から情報処理装置２７３０に商品販売結果が通知される。商品販売結果は、リクエスト学習ＤＢ２８１７に転送される。ステップＳ２７３５において、商品販売結果を表す商品販売データは、リクエスト学習ＤＢ２８１７に蓄積される。

　《情報処理装置の機能構成》
　図２８は、本実施形態に係る情報処理装置２７３０の機能構成を示すブロック図である。なお、図２８において、第２実施形態の図５と同様の機能構成部には同じ参照番号を付して、説明は省略する。

　店舗商品販売結果取得部２８１５は、通信制御部５０１を介して店舗端末から受信した商品販売結果を取得する。そして、商品販売結果記憶部２８１６は、取得した商品販売結果のデータをリクエスト学習ＤＢ２８１７に記憶する。リクエスト学習ＤＢ２８１７は、ユーザ端末から受信した商品購入要求も蓄積する。

　商品購入要求予測部２８１８は、リクエスト学習ＤＢ２８１７に蓄積されたデータからユーザの商品購入要求を予測する。店舗商品ニーズ値算出部２８１０は、第２実施形態と異なり、商品購入要求予測部２８１８が予測した疑似商品購入要求も使って、各店舗の各商品のニーズ値を算出する。

　（リクエスト学習ＤＢ）
　図２９は、本実施形態に係るリクエスト学習ＤＢ２８１７の構成を示す図である。リクエスト学習ＤＢ２８１７の構成は、図２９に限定されない。

　リクエスト学習ＤＢ２８１７は、ユーザＩＤ２９０１に対応付けて、商品ＩＤ２９０２を記憶する。そして、リクエスト学習ＤＢ２８１７は、各商品ＩＤ２９０２に対応付けて、ユーザが商品購入要求を送信した購入要求日２９０３および購入要求臼２９０４を記憶する。また、リクエスト学習ＤＢ２８１７は、各商品ＩＤ２９０２に対応付けて、商品購入案内をユーザ端末に送信した購入案内日２９０５および案内店舗２９０６を記憶する。リクエスト学習ＤＢ２８１７は、さらに、各商品ＩＤ２９０２に対応付けて、ユーザによる購入日２９０７と、購入数２９０８と、購入店舗２９０９とを記憶する。

　商品購入要求予測部２８１８は、これらのリクエスト学習ＤＢ２８１７のデータから、ユーザの商品購入要求の傾向（頻度や個数など）、購入案内に対する反応の傾向（購入までの遅延や店舗の選択など）、購入の傾向（購入頻度や個数、店舗など）を分析して、商品購入要求を予測する。

　（商品ニーズテーブル）
　図３０は、本実施形態に係る商品ニーズテーブル３０４５の構成を示す図である。なお、商品ニーズテーブル３０４５を図示すると複雑になる。図３０は、商品ニーズテーブル３０４５の模式図である。

　図３０の疑似商品購入要求は、リクエスト学習ＤＢ２８１７のデータから各ユーザについて予測された商品購入要求である。ここで、横線は、ユーザが商品購入要求を行うことが予測される予測期間を表す。また、数字は購入要求の予測量（数）である。これらは、リクエスト学習ＤＢ２８１７のデータから推測される平均頻度や平均個数と、それらの標準偏差値などから予測された値である。したがって、周期と個数が、実際とは異なって理想化されている。しかし、これらは図３０の例に限定される必要はない。

　上記疑似商品購入要求から決定された図３０の商品入荷リクエストは、個々のユーザの疑似商品購入要求に一対一に対応しない。疑似商品購入要求から期待されるユーザが購入する商品数は、実際の商品購入要求から期待されるユーザが購入する商品数と違って、実際にユーザが購入する商品数に対して余裕を含むと考えられる。したがって、商品入荷リクエストは、店舗Ａと店舗Ｂとに対して異なる周期で、予測量（数）をカバーできるように分散してスケジュールされる。ここにおいても、本実施形態では、店舗商品入荷リクエスト送信部５１１は、交通渋滞緩和のために、配送回数をむやみに増加させることなく、かつ、ユーザが各店舗に集中しないような商品入荷リクエストを決定する。

　《情報処理装置の動作手順》
　図３１は、本実施形態に係る情報処理装置２７３０の動作手順を示すフローチャートである。このフローチャートは、図１２のＣＰＵ１２１０がＲＡＭ１２４０を使用しながらプログラムを実行することで、図２８の各機能構成部として、このフローチャートの動作を行う。なお、第２実施形態の図１５と同様のステップには同じステップ番号を付して、説明を省略する。

　図３１と第２実施形態の図１５との相違は、商品の配置調整タイミングを決定する処理において、ステップＳ３１２１の、リクエスト学習ＤＢ２８１７のデータからユーザの商品購入要求を予測する処理を有することである。そして、そのリクエスト学習ＤＢ２８１７へのデータ蓄積のために、ユーザ商品購入要求取得部５０２がユーザの商品購入要求を受信した場合、ステップＳ３１１５において、ユーザ商品購入要求記憶部５０３は、ユーザの商品購入要求をリクエスト学習ＤＢ２８１７に蓄積する。また、店舗商品入荷情報取得部５０５が店舗の商品入荷情報を受信した場合、ステップＳ３１３５において、店舗商品記憶部５０６は、店舗の商品入荷情報をリクエスト学習ＤＢ２８１７に蓄積する。さらに、店舗商品販売結果取得部２８１５が、ステップＳ３１４１において商品販売情報の店舗からの受信を判別し、商品販売情報を受信した場合、ステップＳ３１４３において、商品販売結果記憶部２８１６は、商品販売情報をリクエスト学習ＤＢ２８１７に蓄積する。他のステップは、第２実施形態の図１５と同様である。

　（ユーザ商品購入要求予測処理）
　図３２は、本実施形態に係るユーザ商品購入要求予測処理Ｓ３１２１の動作手順を示すフローチャートである。

　まず、ステップＳ３０２１において、ユーザ商品購入要求予測部２８１８は、リクエスト学習ＤＢ２８１７から、１人のユーザの商品購入要求の履歴および商品購入の履歴を読み出す。そして、ステップＳ３２０３において、ユーザ商品購入要求予測部２８１８は、その１人のユーザが購入する、１つの商品の購入タイミング、期間、数を予測する（図３０参照）。ステップＳ３２０５においては、ユーザ商品購入要求予測部２８１８は、その１人のユーザが購入する、全商品の購入予測が終了するまで、購入予測の処理を繰り返す。また、ステップＳ３２０７においては、ユーザ商品購入要求予測部２８１８は、地域の全ユーザの履歴の全商品の購入予測が終了するまで、ユーザの上述の履歴の読み出しとそのユーザに対する購入予測の処理を繰り返す。

　最後に、ユーザ商品購入要求予測部２８１８は、複数のユーザに対して予測した、商品購入タイミング、期間、数を、交通渋滞緩和の観点から調整する（図３０参照）。

　［第５実施形態］
　次に、本発明の第５実施形態に係る情報処理システムについ説明する。本実施形態に係る情報処理システムは、上記第４実施形態と比べると、本情報処理装置に登録されて本情報処理装置がサービスを提供する会員ユーザの商品購入履歴のみでなく、非登録の非会員ユーザの商品購入履歴も考慮して各店舗の商品用意を行なう点で異なる。その他の構成および動作は、第４実施形態と同様である。そのため、第４実施形態と同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

　本実施形態によれば、非会員ユーザの商品購入によって会員ユーザが商品を購入できない事故を減らし、サービスへの信頼性を高めることができる。

　《情報処理システムの動作手順》
　図３３は、本実施形態に係る情報処理システム３３００の動作手順を示すシーケンス図である。なお、図３３において、第４実施形態の図２７と同様のステップには同じステップ番号を付して、説明を省略する。

　ステップＳ３３０５においては、店舗の端末は、店舗から情報処理装置３３３０へ送信する商品購入結果として、会員ユーザの商品購入結果のみでなく非会員ユーザの商品購入結果も通知する。そして、ステップＳ３３０７においては、情報処理装置３３３０は、非会員の商品販売データもリクエスト学習ＤＢ３４１７に蓄積する。

　また、ステップＳ３３１１において、情報処理装置３３３０は、非会員の商品購入履歴をリクエスト学習ＤＢ３４１７から読み出す。そして、ステップＳ３３１３において、情報処理装置３３３０は、非会員ユーザの各商品の購入予測を行なう。

　ステップＳ３３１９においては、情報処理装置３３３０は、会員ユーザの購入予測スケジュールと、非会員ユーザの購入予測とから、各店舗に対する入荷リクエストを生成する。具体的には、非会員ユーザも商品を購入するので、情報処理装置３３３０は、非会員ユーザが購入する商品の予測値を上乗せした商品の入荷リクエストを送信することで、会員ユーザが店舗で商品を購入できない場合を回避するよう制御する。

　《情報処理装置の機能構成》
　図３４は、本実施形態に係る情報処理装置３３３０の機能構成を示すブロック図である。なお、図３４において、第４実施形態の図２８と同様の機能構成部には同じ参照番号を付して、説明を省略する。

　リクエスト学習ＤＢ３４１７は、第４実施形態のリクエスト学習ＤＢ２８１７にさらに非会員商品購入データ３４１７ａを追加したデータベースである。非会員購入予測部３４１０は、リクエスト学習ＤＢ３４１７の非会員商品購入データ３４１７ａを参照して、非会員ユーザの商品購入予測を行なう。そして、店舗商品入荷リクエスト送信部３４１１は、非会員購入予測部３４１０からの非会員ユーザの商品購入予測も参照して、各店舗に対して商品入荷リクエストを送信する。

　（リクエスト学習ＤＢ）
　図３５は、本実施形態に係るリクエスト学習ＤＢ３４１７の構成を示す図である。なお、図３５において、第４実施形態の図２９と同じ部分は、図中で、会員商品購入に関するリクエスト学習ＤＢ２８１７で示された部分である。

　追加部分である、非会員商品購入データ３４１７ａは、商品ＩＤ３５０１に対応付けて、店舗ＩＤ３５０２を記憶する。そして、非会員商品購入データ３４１７ａは、各店舗ＩＤ３５０２に対応付けて、非会員の商品の購入日３５０３と購入数３５０４とを記憶する。

　（商品ニーズテーブル）
　図３６は、本発明の第５実施形態に係る商品ニーズテーブル３６４５の構成を示す図である。なお、商品ニーズテーブル３６４５は、図示すると複雑である。図３６は、商品ニーズテーブル３６４５の模式図である。

　図３６の疑似商品購入要求は、会員商品購入に関するリクエスト学習ＤＢ２８１７のデータから各ユーザについて予測された商品購入要求である。図３６の疑似商品購入要求は、図３０の疑似商品購入要求と同じである。

　図３６の非会員購入予測は、店舗Ａおよび店舗Ｂにおける非会員の商品購入結果の履歴から予測される購入予測である。

　図３６の商品入荷リクエストは、上記疑似商品購入要求および非会員購入予測から決定される。図３６の商品入荷リクエストの商品の数は、第４実施形態のように決定された図３０の商品入荷リクエストの商品の数に、さらに非会員購入予測の商品の数が付加された数である。この場合にも、図３０の例と同様に、非会員購入予測から期待される、非会員ユーザが購入する商品数は、実際に非会員ユーザが購入する商品数に対して余裕を含むと考えられる。したがって、商品入荷リクエストは、図３０の商品入荷リクエストのように、店舗Ａと店舗Ｂとで異なる周期で、予測量（数）をカバーできるように分散してスケジュールされる。また、図３６の商品入荷リクエストの商品の数は、図３０の商品入荷リクエストの商品の数に非会員購入予測の商品の数が追加された数である。ここにおいても、本実施形態では、店舗商品入荷リクエスト送信部３４１１は、交通渋滞緩和のために、配送回数をむやみに増加させることなく、かつ、ユーザが各店舗に集中しないように、商品入荷リクエストを決定する。

　《情報処理装置の動作手順》
　図３７は、本実施形態に係る情報処理装置３３３０の動作手順を示すフローチャートである。なお、図３７において、図３１と同様のステップには同じステップ番号を付して、説明は省略する。

　ステップＳ３７２３においては、非会員商品購入予測部３４１０は、非会員商品購入を予測する。そして、ステップＳ３７２５の商品配置最適化処理において、店舗商品入荷リクエスト送信部３４１１は、第２実施形態のステップＳ１５２５の処理に加えて、非会員商品購入の予測も考慮して商品配置の最適化を行なう（図３８参照）。

　（商品配置最適化処理）
　図３８は、本実施形態に係る商品配置最適化処理Ｓ３７２５の動作手順を示すフローチャートである。なお、図３８において、第２実施形態の図１７と同様のステップには同じステップ番号を付して、説明は省略する。

　ステップＳ３８０１において、店舗商品入荷リクエスト送信部３４１１は、ステップＳ３７２３で予測された非会員商品購入予測を取得する。そして、ステップＳ３８０９において、店舗商品入荷リクエスト送信部３４１１は、非会員商品購入予測も考慮して、各店舗における各商品の入荷数を決定する。

　［第６実施形態］
　次に、本発明の第６実施形態に係る情報処理システムについて説明する。本実施形態に係る情報処理システムでは、上記第２乃至第５実施形態と比べると、ユーザ端末への商品購入案内や店舗端末への商品入荷リクエストが異なる。その他の構成および動作は、第２乃至第５実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

　本実施形態によれば、ユーザの商品購入に伴うユーザの移動や店舗への商品入荷に伴う商品配送を分散すべく誘導することにより、さらに交通渋滞を緩和することができる。

　なお、本実施形態に記載した種々の商品購入案内や商品入荷リクエストはこれに限定されない。商品購入案内や商品入荷リクエストとして、記載されている例の組合せや他の例が可能である。

　《ユーザ端末への商品購入案内》
　図３９は、本実施形態に係る情報処理システム３９００におけるユーザ端末への商品購入案内の例を示す図である。なお、図３９には、４つのユーザ端末への商品購入案内の例を示すが、これに限定されない。本実施形態の商品購入案内の例には、他の実施形態の商品購入案内より交通渋滞が緩和されるようにユーザの商品購入を誘導するための種々の工夫が含まれる。

　図３９の左上図の、ユーザ端末２２０の表示画面３９２１は、地域内の全店の全スケジュール３９２２を通知する画面である。ユーザは、かかる画面により、交通渋滞が緩和されるような店舗と購入日を選択することが可能となる。

　図３９の右上図の、ユーザ端末２２０の表示画面３９３１は、近所の１店舗のみの予定３９３２を通知する画面である。ユーザは、かかる画面により、交通渋滞が緩和されるように購入日を選択することが可能となる。また、図示されないが、近所の１店舗の全予定に加えて、ユーザが購入要求した商品を最も早い日程で売る別の店舗の予定などを案内することも考えられる。

　図３９の左下図の、ユーザ端末２２０の表示画面３９４１は、"電気ポットをご希望であれば、今日は隣町のＡ店で、今週金曜日には近所のＢ点で購入可能です。"というリコメンド３９４２を示す。また、表示画面３９４１は、"プリンタ用紙は、今日なら駅前のＤ店に１箱入荷、今週水曜日には、近所のＣ店に５箱入荷します。"というリコメンド３９４３を示す。なお、リコメンドはこれに限定されない。

　図３９の右下図の、ユーザ端末２２０の表示画面３９５１は、リコメンド３９４２と、"今日隣町のＡ店に行く場合は、次の経路をお勧めします。経路途中で次のサービスが受けられます。"というリコメンド３９５２を示す。図３９の右下の図は、商品配置の決定や商品購入案内の生成の際に、さらに、本実施形態の情報処理装置が、ユーザが通るのに最もよい経路を計算する場合の表示画面の例である。図３９の右下の図の例では、ユーザが通るのに最もよい経路が合わせて提示される。商品購入案内生成部５１２は、ユーザに提示した経路を通ってもらうために、次のような情報やサービスの案内を付加してもよい。そのような案内は、例えば、"おすすめルートを通ると、途中のＣチェックポイントでお店のクーポンが手に入ります。"、"セールの耳より情報が手に入ります。"、"節約のコツ情報が手に入ります／商品の限定特典の引換クーポンが手に入ります。"などである。このように、本実施形態に係る情報処理装置は、商品の分散に加えて、場所に紐づけられた有用な情報の配送によって、ユーザの誘導を図ることにより、交通渋滞緩和を促進してもよい。

　《店舗端末への商品入荷リクエスト》
　図４０は、本実施形態に係る情報処理システム３９００における店舗端末への商品入荷リクエストの例を示す図である。なお、図４０には、２つの店舗端末への商品入荷リクエストの例が示される。商品入荷リクエストは、これらの例に限定されない。本実施形態の商品入荷リクエストには、他の実施形態の商品入荷リクエストより交通渋滞の緩和につながるように店舗の商品入荷を誘導するための、種々の工夫が含まれる。

　図４０の左図の、店舗端末２４０の表示画面４０４１は、ユーザからの商品購入要求の商品数を表すユーザ要求と、店舗の在庫数の予測値である在庫予測と、オペレータが入荷を依頼するために入力した商品の個数である入荷数とを含むリクエスト画面４０４２を含む。リクエスト画面４０４２は情報処理装置から送信される。店舗のオペレータは、かかる画面によって入荷の依頼を行うことにより、交通渋滞が緩和されるような、配送センターへの商品の入荷のリクエストを行うことが可能である。

　図４０の右図の、店舗端末２４０の表示画面４０４３は、前述のユーザ要求および店舗の在庫予測に加えて、配送センターの在庫数の予定であるセンター在庫予定と、オペレータが入荷を依頼するために入力した商品の個数である入荷数とを含むリクエスト画面４０４４を含む。リクエストするように、リクエスト画面４０４４は情報処理装置から送信される。店舗のオペレータは、かかる画面によって入荷の依頼を行うことにより、交通渋滞が緩和されるように、配送センターへの配送センターの在庫も考慮した商品の入荷のリクエストを行うことが可能である。

　［第７実施形態］
　次に、本発明の第７実施形態に係る情報処理システムについて説明する。本実施形態に係る情報処理システムは、上記第２乃至第６実施形態と比べると、ユーザの商品購入に関する行動や商店の商品販売に関する行動に対して、本情報処理システムによる交通渋滞の緩和への貢献に応じたポイントを付与する点で異なる。その他の構成および動作は、第２乃至第６実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

　本実施形態によれば、ユーザの商品購入に関する行動や商店の商品販売に関する行動を交通渋滞の緩和に資するよう誘導することにより、さらに交通渋滞を緩和することができる。

　なお、本実施形態のポイントの付与の例はその一例である。本実施形態の情報処理システムは、交通渋滞緩和に資するよう誘導する、他のポイントを付与してもよい。

　《ユーザおよび店舗へのポイント付与》
　図４１は、本実施形態に係る情報処理システム４１００におけるユーザおよび店舗へのポイントの付与の例を示す図である。

　図４１の上段４１１０は、ユーザの商品購入に関する行動を、交通渋滞を緩和するように誘導するために付与されるポイントの例を表す。情報処理装置には、ユーザ行動４１１１に対応付けて、増加されるポイント数４１１２が記憶されている。例えば、ユーザ端末が商品購入要求を情報処理装置に送信した場合のポイント付与は、"＋５ポイント"である。また、ユーザが商品購入案内を受けた店舗で購入した場合のポイント付与は、"＋１０ポイント"である。また、ユーザが最も近い店舗で購入した場合のポイント付与は、"＋１５ポイント"である。このようなポイント付加により、ユーザの商品購入要求の入力行動と、商品購入案内に従った購入行動を促進することができる。

　図４１の中段４１２０は、情報処理装置であらかじめ設定した場所に立ち寄った場合や場所を通過した場合に、ポイントやサービス品を提供することにより、ユーザを誘導するために付与されるポイントの例を表す。図４１の中段４１２０の例では、店舗における購入に対して、ユーザの誘導のためのポイントは付与されない。例えば、立ち寄り場所や通過場所として、経由することにより交通渋滞が緩和される、ユーザのルート上の場所が設定される。情報処理装置は、ユーザの立ち寄り／通過場所４１２１に対応付けて、付与されるポイント数や提供されるサービス品４１２２を記憶する。例えば、ユーザがスーパーＡに立ち寄れば、それだけでポイント１０がプラスされる。また、ユーザが国道Ｂの交差点ｂを通過すれば、ポイント５がプラスされる。あるいは、ユーザが国道Ｃの交差点ｃを通過すれば、クーポン券が提供される。なお、情報処理装置は、設定場所への立ち寄りや通過の判定を、ユーザ端末がＧＰＳ情報に基づいてＳＮＳの"チェックイン"機能などを使って情報処理装置に報告することで行なう。情報処理装置は、受信した報告からユーザ端末にポイントやサービスを提供する。

　図４１の下段４１３０は、商品入荷や商品販売に関する店舗の行動を、交通渋滞を緩和するように誘導するために付与されるポイントの例である。情報処理装置は、店舗行動４１３１に対応付けて、増加されるポイント数４１３２を記憶する。例えば、店舗端末から商品入荷リクエストに応じて入荷依頼が出された場合のポイント付与は、"＋１０ポイント"である。また、店舗で近隣のユーザが商品購入した場合のポイント付与は、"＋５ポイント"である。また、商品入荷リクエストに応じて入荷した商品を、商品購入案内を受けた近隣のユーザが購入した場合のポイント付与は、"＋１５ポイント"である。このようなポイント付加により、店舗が商品入荷リクエストに応じて商品の入荷を行う行動と、店舗独自の、ユーザに商品の購入を案内する行動を促進できる。

　［他の実施形態］
　以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴をどのように組み合わせたシステムまたは装置も、本発明の範疇に含まれる。

　また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する制御プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされる制御プログラム、あるいはその制御プログラムを格納した媒体、その制御プログラムをダウンロードさせるＷＷＷ(World Wide Web)サーバも、本発明の範疇に含まれる。

　この出願は２０１２年３月８日に出願された日本出願特願２０１２－０５１９２７を基礎とする優先権を主張し、その全てをここに取り込む。

Claims

　ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得手段と、
　前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知する商品購入情報通知手段と、
　前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する商品購入案内手段と、
　を備えることを特徴とする情報処理装置。
　前記商品購入情報通知手段は、前記ユーザの所在地との距離が前記第１閾値より短い店舗を異なる日時に選択する店舗選択手段を有し、
　前記商品購入案内手段は、選択された店舗における前記異なる日時の購入案内を報知することを特徴とする請求項１に記載の情報処理装置。
　前記商品が複数の場合に、前記商品購入要求取得手段と、前記商品購入情報通知手段と、前記商品購入案内手段とが、各商品についてそれぞれ処理を行なうことを特徴とする請求項１または２に記載の情報処理装置。
　前記商品購入要求取得手段は、前記ユーザからの商品購入要求メッセージを収集して、商品購入要求をユーザの所在地に対応付けて記憶し、
　前記商品購入情報通知手段は、記憶された前記商品購入要求とユーザの所在地とに基づいて、各店舗との距離を算出して前記距離が前記第１閾値より短い店舗の通信端末に対して前記ユーザの商品購入要求に関する情報を通知することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
　前記商品購入要求取得手段は、前記ユーザの商品購入履歴を蓄積して、前記ユーザの商品購入要求を予測し、
　前記商品購入情報通知手段は、予測された前記商品購入要求とユーザの所在地とに基づいて、各店舗との距離を算出して前記距離が前記第１閾値より短い店舗の通信端末に対して前記ユーザの予測された商品購入要求に関する情報を通知することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
　前記商品購入要求取得手段は、非登録のユーザの商品購入履歴を蓄積して、前記非登録のユーザの商品購入要求を予測し、
　前記商品購入情報通知手段は、予測された前記非登録のユーザの商品購入要求に基づいて、さらに、前記距離が前記第１閾値より短い店舗の通信端末に対して前記非登録のユーザの予測された商品購入要求に関する情報を通知することを特徴とする請求項４または５に記載の情報処理装置。
　前記商品購入情報通知手段は、各店舗について、前記商品購入要求のあるユーザの所在地と前記店舗との距離と、前記ユーザの商品購入の優先度とに基づいて、各商品のニーズ値を算出し、算出された前記ニーズ値が第２閾値を超える場合に、当該商品の購入に関する情報を前記店舗の通信端末に通知することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
　前記商品購入情報通知手段は、前記商品購入要求をもつユーザの数と、前記商品購入要求される要求数と、前記店舗において在庫する在庫数とに基づいて、前記商品と前記商品の入荷数とを、前記ユーザの商品購入要求に関する情報として、前記店舗に通知することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
　前記商品購入情報通知手段は、さらに前記店舗への商品の配送スケジュールを考慮して、前記商品と前記商品の入荷数とを、前記ユーザの商品購入要求に関する情報として、前記店舗に通知することを特徴とする請求項８に記載の情報処理装置。
　商品購入要求の前記ネットワークを介したユーザからの入力、特定の店舗における商品購入案内の報知に応じたユーザの商品購入、および、ユーザの商品購入要求に関する情報の通知に応じた店舗における入荷商品の販売、に対してポイントを付与するポイント付与手段をさらに備えることを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
　ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得し、
　前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知し、
　前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する
　ことを特徴とする情報処理装置の制御方法。
　コンピュータを、
　ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得手段と、
　前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末に対して、前記ユーザの商品購入要求に関する情報を、ネットワークを介して通知する商品購入情報通知手段と、
　前記店舗への前記商品の入荷情報を、前記ネットワークを介して受信して、前記商品の前記店舗における購入案内を、前記ネットワークを介して前記ユーザの通信端末に対して報知する商品購入案内手段と、
　して動作させることを特徴とする制御プログラム。
　ユーザの通信端末と店舗の通信端末と前記店舗における商品配置を管理する情報処理装置とがネットワークにより接続された情報処理システムであって、
　ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得する商品購入要求取得手段と、
　前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末から、前記ユーザの商品購入要求に関する情報を通知する商品購入情報通知手段と、
　前記店舗への前記商品の入荷情報に応じて、前記商品の前記店舗における購入案内を前記ユーザの通信端末から報知する商品購入案内手段と、
　を備えることを特徴とする情報処理システム。
　ユーザの通信端末と店舗の通信端末と前記店舗における商品配置を管理する情報処理装置とがネットワークにより接続された情報処理システムの情報処理方法であって、
　ユーザの所在地と該ユーザの商品購入要求に関する情報とを取得し、
　前記ユーザの所在地との距離が第１閾値より短い店舗の通信端末から、前記ユーザの商品購入要求に関する情報を通知し、
　前記店舗への前記商品の入荷情報に応じて、前記商品の前記店舗における購入案内を前記ユーザの通信端末から報知する
　ことを特徴とする情報処理方法。