JPWO2016151679A1 - 情報処理装置、情報処理方法、プログラム - Google Patents

Abstract

ある時期に売れそうな商品としての要素を持ちながら、現状、当該時期に売上が増加していない商品を抽出する。このために商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する。そして売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する。抽出した推奨商品について、対応する比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する。

Description

本発明は情報処理装置、情報処理方法、プログラムに関し、特に販売増加が見込まれる商品の抽出についての技術分野に関する。

特開平１１−３１６７７６号公報

電子商取引システムが運営する仮想商店街において各種の店舗が出店し、一般ユーザがオンライン取引により商品購入を行うことが一般化している。
取引される各種の商品の中には、特定の時期に売上が伸びるような季節性のあるものが存在する。このため店舗側にとっては、各種の商品について売れる時期を判定し、時期に合わせたマーケティング戦略を立てることが重要とされる。
上記特許文献１には、時期毎にまとめられた項目と数値の表から全体としての時間的な変化の度合いを直感的に把握し得るマクロトレンド計算手法が開示されている。例えばこの手法等を用いることで商品の購買履歴から、その商品が売れた時期を分析することもできる。

ところで季節性のある商品として、ある時期に販売が伸びることが確認された商品のなかには、実績として確認されている売れた時期以外の時期にもニーズが存在する場合がある。しかしながら、各商品についての「実績の無い時期におけるニーズ」を把握することは困難である。
そこで本発明では、実際に売れている時期以外の特定の時期に売れそうな時期があると推定できる商品を容易に判定できるようにすることを目的とする。

本発明に係る情報処理装置は、商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定部と、前記売上増加時期特定部が特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出部と、前記推奨商品抽出部が抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定部と、を備えたものである。
売上増加時期を複数有する商品を比較商品としたときに、売上増加時期の一部が比較商品と一致している商品は、比較商品との売上要因の類似性を有すると推定できる。そのため比較商品の売上増加時期であって、かつ推奨商品の売上増加時期とはなっていない時期は、推奨商品の売上増加が期待できる時期と推定できる。このように、商品の売上増加時期の比較により、簡易に、或る商品についての、現在売れている時期以外の特定の時期での販売促進可能性を推定できる。

上記した情報処理装置においては、前記推奨商品抽出部は、前記比較商品に対して、売上増加時期の一部が一致する商品であって、かつ、前記比較商品との関連性判定により関連性があると判定した商品を、前記推奨商品とすることが考えられる。
即ち比較商品と売上増加時期が一部一致するだけでなく、関連性条件も付加して推奨商品を抽出することで、推奨時期設定部が設定する推奨時期の信頼性を高める。

上記した情報処理装置においては、前記推奨時期設定部は、前記推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期のうちで、当該推奨商品について設定された非推奨時期を除いた時期を、当該推奨商品の推奨時期と設定することが考えられる。
即ち商品について推奨する時期として相応しくない時期を非推奨時期として設定しておく。そして非推奨時期については、推奨時期とは設定しないようにする。

上記した情報処理装置においては、送信対象店舗に選択した店舗の端末装置に対して、前記推奨商品抽出部が抽出した推奨商品と、その推奨商品について前記推奨時期設定部が設定した推奨時期の情報を含む、販売提案情報の送信制御を行う販売提案情報提供部を備えることが考えられる。
即ち推奨商品を、推奨時期に売れそうな商品と推定されるものとして店舗に通知することで販売準備の機会を提供する。

上記した情報処理装置においては、前記販売提案情報提供部は、或る推奨商品の前記販売提案情報について、その推奨商品の取扱い店舗又は取扱い可能性を有する店舗を前記送信対象店舗として選択することが考えられる。
即ち、推奨商品に関する販売提案情報を、その推奨商品に無関係な店舗、つまり取り扱うことがない店舗に提供しないようにすることで、店舗側に無駄と認識される通知を避ける。逆に送信対象店舗は、その推奨商品に関係がある店舗となることで、販売提案情報が有効な情報となる。

上記した情報処理装置においては、前記販売提案情報提供部は、或る推奨商品の前記販売提案情報について、その推奨商品が対応する前記比較商品の取扱い店舗又は取扱い可能性を有する店舗を前記送信対象店舗として選択することが考えられる。
推奨商品と、対応する比較商品が関連性を有する商品であれば、比較商品を扱う店舗にも、推奨商品に関する販売提案情報は有効な情報となる。

上記した情報処理装置においては、前記販売提案情報提供部は、前記販売提案情報で通知する推奨時期の開始日から所定日時前の時点で、前記販売提案情報を前記送信対象店舗に対して送信する制御を行うことが考えられる。
即ち店舗側で売上増加時期に合わせて商品販売準備を整えることができるように適切なタイミングで販売提案情報を送信する。

上記した情報処理装置においては、前記推奨商品抽出部が抽出した推奨商品についての商品紹介情報が、その推奨商品について前記推奨時期設定部が設定した推奨時期において、ユーザ端末に提示されるように制御する商品紹介制御部を備えることが考えられる。
推奨商品は、比較商品との売上増加時期の比較に基づいて、これまで特に顕著な売上がなかった時期（推奨時期）に売れる可能性があると推定された商品である。そこで、売れる可能性の或る推奨時期において、その商品がユーザ端末で紹介されるようにする。

上記した情報処理装置においては、前記商品紹介制御部は、或る推奨商品の推奨時期に、その推奨商品が対応する前記比較商品を対象とする特定のユーザアクションが行われたユーザ端末において、当該推奨商品についての商品紹介情報が提示されるように制御することが考えられる。
或る比較商品を対象として商品ウェブページ閲覧等の特定のユーザアクションを行ったユーザは、或る目的でその比較商品の購入を考えているユーザであると推定できる。すると、比較商品に対応する推奨商品にも興味を持つユーザとも推定できる。そこで商品紹介情報として、ユーザの目的に沿う商品と推定される推奨商品を推奨時期に提示する。

上記した情報処理装置においては、前記商品紹介制御部は、ユーザ端末を使用するユーザの購入履歴に含まれる商品が前記比較商品とされた推奨商品についての商品紹介情報が、当該推奨商品の推奨時期に、前記ユーザ端末において提示されるように制御することが考えられる。
或る比較商品を購入したユーザは、比較商品に対応する推奨商品にも興味を持つユーザとも推定できる。そこで商品紹介情報として、ユーザの目的に沿う商品と推定される推奨商品を、推奨時期に提示する。

本発明に係る情報処理方法は、情報処理装置が実行する情報処理方法として、商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定ステップと、前記売上増加時期特定ステップで特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出ステップと、前記推奨商品抽出ステップで抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定ステップと、を備える。
この情報処理方法により、或る商品についての、現在売れている時期以外の特定の時期での販売促進可能性を推定できる。
本発明に係るプログラムは、上記の各情報処理方法としての各ステップの処理を情報処理装置に実行させるプログラムである。

本発明によれば、ある時期に顕著に売れているという実績の或る商品であって、他の時期でも売れる可能性が或る商品及びその時期を容易に判定できるという効果がある。

本発明の実施の形態の電子商取引システムのブロック図である。 実施の形態で用いられるコンピュータ装置のブロック図である。 実施の形態の電子商取引サーバの機能構成及びデータベースの説明図である。 季節性のある商品の説明図である。 実施の形態の時期管理データベースと購買履歴データベースの説明図である。 実施の形態の売上増加時期特定処理のフローチャートである。 商品の売上増加時期の説明図である。 実施の形態の推奨商品及び時期判定処理の第１例のフローチャートである。 実施の形態の推奨時期設定処理のフローチャートである。 実施の形態の推奨商品及び時期判定処理の第２例のフローチャートである。 実施の形態の販売提案情報送信処理のフローチャートである。 実施の形態の販売提案の提示態様の説明図である。 実施の形態の商品紹介制御処理のフローチャートである。 実施の形態の紹介商品の提示態様の説明図である。 実施の形態の紹介商品の提示態様の説明図である。 実施の形態の商品紹介制御処理の第２例のフローチャートである。 実施の形態の商品紹介制御処理の第３例のフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．電子商取引システム構成＞
＜２．ＥＣサーバの機能構成及びデータベース＞
＜３．推奨商品及び推奨時期の設定＞
＜４．店舗への販売提案＞
＜５．ユーザへの商品紹介＞
＜６．まとめ及び変形例＞
＜７．プログラム及び記憶媒体＞

なお実施の形態では、本発明請求項にいう情報処理装置の例として、電子商取引システムを提供する電子商取引サーバ（ＥＣサーバ）を挙げる。電子商取引サーバは１又は複数の情報処理装置によって実現されるものであり、従って本発明請求項にいう情報処理装置は、１つの情報処理装置或いは複数の情報処理装置が連携して実現される。
また実施の形態で用いる主な語句については、以下の意味となる。
・ユーザ：電子商取引システムを利用して商品の閲覧、購入等を行うユーザ
・商品：電子商取引システム上で商取引の対象とされている商品である。物理的な品物としての商品だけでなく各種サービスとしての商品も含む
・店舗：電子商取引システムに出店された店舗
・ユーザアクション：ユーザ端末を用いてユーザが行う行動の総称であり、例えばリンク画像のクリック操作、検索ワード入力、検索実行操作、お気に入り登録操作、購入操作、ログイン操作などが例となる。

＜１．電子商取引システム構成＞
図１に複数の店舗が出店する仮想的な商店街を実現するＥＣ（electronic commerce：電子商取引）システムとして機能するネットワークシステムの構成例を示している。図１における電子商取引サーバ（以下「ＥＣサーバ」という）２が本発明請求項の情報処理装置の実施の形態に相当する。

図１に示すように、本実施の形態に係るＥＣシステムは、ＥＣサーバ２、複数の店舗端末４、複数のユーザ端末５がネットワーク１により相互に通信可能に接続されている。またＥＣサーバ２は電子商取引データベース６にアクセス可能とされている。
なお、以下では「データベース」を「ＤＢ」と表記する。

ネットワーク１の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク１の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。

ＥＣサーバ２は、例えば仮想商店街のポータルとして機能する仮想商店街サーバである。ＥＣサーバ２は、店舗端末４やユーザ端末５から受信した処理要求に基づく処理を実行する。例えばユーザへの商品やサービスの検索ページの提供、各店舗に対する店舗ページの提供、ユーザの検索に応じた商品やサービスの検索、検索結果一覧表示、各ページでの広告やユーザへのお勧め商品等の表示、商品購入に関する処理、店舗管理、ユーザ管理などを行う。

店舗端末４は、仮想商店街に出店する店舗側で使用される情報処理装置として示している。店舗端末４は仮想商店街で販売する商品の情報等を、ＥＣサーバ２を介して電子商取引ＤＢ６に登録することなどに用いられる。例えば、ＥＣサーバ２から提供される専用画面が店舗端末４の表示部に表示される。店舗の担当者はこの専用画面を介して商品の情報等を電子商取引ＤＢ６に登録する。

ユーザ端末５は、仮想商店街を利用して商品やサービスの購入を行うユーザによって操作される情報処理装置として示している。ユーザ端末５は例えばパーソナルコンピュータ、携帯電話機、又は携帯情報端末等の情報処理装置により実現される。

本実施形態の場合、例えば、ＥＣサーバ２ではＨＴＴＰ（Hypertext Transfer Protocol）デーモンが起動される。また店舗端末４又はユーザ端末５ではブラウザが起動され、店舗端末４又はユーザ端末５からは、ブラウザを介して処理要求（ＨＴＴＰリクエスト）がＥＣサーバ２に送信される。ＥＣサーバ２からは、上記の処理要求に対応する処理結果（ＨＴＴＰレスポンス）が店舗端末４又はユーザ端末５に送信される。例えば、ウェブページ記述言語で記述されたページデータが店舗端末４又はユーザ端末５に送信される。そして、このページデータに基づいて、処理結果に基づくウェブページ（画面）が店舗端末４又はユーザ端末５の表示部に表示される。
ＥＣサーバ２はこのような動作によりユーザ端末５に仮想商店街としてのウェブページを提供し、またユーザ端末５からの要求に応じた商品検索、商品提示、広告提示、決済処理等を行う。またＥＣサーバ２は店舗端末４に対しても同様の動作で、商品登録ページの提供や、店舗端末４からの要求に応じた商品登録などを行う。

ＥＣサーバ２がこれらの処理を行うために電子商取引ＤＢ６に必要な情報が格納される。図では本実施の形態の後述の処理に関連するＤＢとして、ユーザＤＢ６ａ、店舗ＤＢ６ｂ、商品ＤＢ６ｃ、広告ＤＢ６ｄ、購買履歴ＤＢ６ｅ、時期管理ＤＢ６ｆを例示している。もちろんこれ以外にも仮想商店街のポータルとして機能するために必要なＤＢが各種存在する。

ユーザＤＢ６ａには、仮想商店街を利用するユーザに関するデータが登録される。例えば登録されたユーザ毎に、ユーザ識別情報であるユーザＩＤ（identification）、ログインのパスワード、住所、氏名、性別や年齢等の属性情報、決済情報、電子メールアドレスなどが登録される。また各ユーザの購入履歴として、仮想商店街で行われた取引の履歴に関するデータが登録される。例えばユーザＩＤ毎に、購入商品の商品ＩＤ及び商品に関する情報、購入店舗、購入日時、購入価格等が登録される。さらに各ユーザの閲覧履歴、お気に入り登録情報なども記憶される。

店舗ＤＢ６ｂには、仮想商店街に出店している店舗に関するデータが登録される。例えば各店舗について、店舗識別情報としての店舗ＩＤ、名称、住所、電話番号、及び店舗に関するウェブページ（店舗ページ）へのリンク情報（ＵＲＬ（Uniform Resource Locator））などが登録される。
商品ＤＢ６ｃには、仮想商店街で取り扱っている商品に関するデータが登録される。例えば商品テーブル６ｂには、各商品（サービスも含む）について、商品識別情報としての商品ＩＤ、当該商品を販売する店舗の店舗ＩＤ、商品のカテゴリー、名称、価格、在庫、商品に関するウェブページ（商品ページ）へのリンク情報（ＵＲＬ）などが登録される。
なお商品ＩＤとしては、品物の型番等に対応した１つの製品を識別するＩＤや、各店舗の商品を識別するＩＤ（つまり同じ商品であっても各店舗で異なるＩＤ）が用いられる場合があるが、本実施の形態でいう商品ＩＤは前者の例を想定して説明する。但し後者の例であっても実施の形態と同様の処理は可能である。

広告ＤＢ６ｄには、店舗によって登録された広告情報が登録されている。各広告情報としては、商品や店舗の写真やロゴなどの広告画像、広告文としてのテキスト情報、広告を選択するためのキーワード、ＵＲＬリンク、実績情報、広告単価情報などが紐づけられている。実績情報とは、表示回数（インプレッション）、クリック回数、ＣＴＲ（Click Through Rate）、アクセス数、コンバージョン数、ＣＶＲ（Conversion Rate）、商品売上値などである。
ＥＣサーバ２は、広告ＤＢ６ｅから選択した広告画像やテキストを各種ウェブページ上で表示させることができる。

購買履歴ＤＢ６ｅ、時期管理ＤＢ６ｆについては後述する。
本実施の形態では、ＥＣサーバ２はこのような電子商取引ＤＢ６にアクセスして各種処理に必要な情報を取得する。
なお電子商取引ＤＢ６は、ＥＣサーバ２とは別のサーバコンピュータ内に構築されていてもよいし、ＥＣサーバ２内に構築されていてもよい。
また図示及び説明の便宜上、電子商取引ＤＢ６として示したが、ユーザＤＢ６ａ、店舗ＤＢ６ｂ、商品ＤＢ６ｃ、広告ＤＢ６ｄ、購買履歴ＤＢ６ｅ、時期管理ＤＢ６ｆの各ＤＢは、ＥＣサーバ２がアクセス可能とされていればどのような形態で実現されていてもよい。例えばＥＣサーバ２と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ６ａとして記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢと取引用のユーザＤＢなど）により記憶管理されてもよい。実施の形態で説明する上記各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢの形態で例示したものに過ぎない。

続いて図１に示したＥＣサーバ２、店舗端末４、ユーザ端末５を構成する情報処理装置のハードウエア構成を図２に示す。ＥＣサーバ２、店舗端末４、ユーザ端末５として示した各装置は、情報処理および情報通信が可能な図２に示すようなコンピュータ装置として実現できる。

図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイやスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワーク１を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しをしたりすることが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、ＥＣサーバ２、店舗端末４、ユーザ端末５としての必要な情報処理や通信が実行される。
なお、ＥＣサーバ２、店舗端末４、ユーザ端末５を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。

＜２．ＥＣサーバの機能構成及びデータベース＞
図３に１又は複数の情報処理装置で構成されるＥＣサーバ２としての機能構成を示す。
ＥＣサーバ２としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウエアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。

ＥＣサーバ２は、通信部２１、ウェブサーバ２２、管理部２３、検索部２４、売上増加時期特定部２５、推奨商品抽出部２６、推奨時期設定部２７、販売提案情報提供部２８、商品紹介制御部２９を有する。

通信部２１は、ネットワーク１を介してのユーザ端末５や店舗端末４、或いは他の情報処理装置との各種通信を行う。例えば通信部２１は、ユーザ端末５や店舗端末４においてブラウザ上で提示されるウェブページを構成するＨＴＭＬデータの送信や、ユーザ端末５や店舗端末４において行われたウェブ画面上での入力情報の受信等を行う。また通信部２１は、ユーザ端末５や店舗端末４に対する電子メール送信等を行う機能も含む。

ウェブサーバ２２は、仮想商店街を構成する各種ウェブページの生成（ＨＴＭＬデータ生成）を行う。例えばポータル画面、検索画面、検索結果画面、商品画面、店舗画面等の各種ページデータの生成を行う。このためにユーザＤＢ６ａ、店舗ＤＢ６ｂ、商品ＤＢ６ｃ、広告ＤＢ６ｄからの必要な情報の取得も行う。
管理部２３は、ユーザ登録、店舗登録、商品登録、ユーザ端末５や店舗端末４からのログイン処理、広告登録、決済処理等、電子商取引システムで必要な処理を行う。またこれらの処理に応じて、ユーザＤＢ６ａ、店舗ＤＢ６ｂ、商品ＤＢ６ｃ、広告ＤＢ６ｄ、購買履歴ＤＢ６ｅの情報の登録・更新等の管理も行う。
検索部２４は、商品ＤＢ６ｃを用いた商品検索や、店舗ＤＢ６ｂを用いた商品検索、広告ＤＢ６ｅを用いた広告検索等を行い、ウェブページに提示させる商品、店舗、広告等の情報を取得する。これらの情報は例えばウェブサーバ２２に受け渡され、ウェブページの生成に用いられる。

売上増加時期特定部２５は、購買履歴ＤＢ６ｅに記憶された、商品毎の購買日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する。つまり季節性の商品におけるよく売れる時期を特定する。
図４Ａは、「バーベキュー用品」と「虫除けスプレー」という２つの商品の月毎の売上数を例示している。例えば仮想商店街全体でのこれらの商品の売上数であるとする。図４Ｂは、図４Ａをグラフ化したものである。実線は虫除けスプレー、破線はバーベキュー用品を示す。
この例の場合、バーベキュー用品は、５月と８月に、他の月に比べて売上が顕著に増加している。一方、虫除けスプレーは８月に、他の月に比べて売上が顕著に増加している。
この場合のバーベキュー用品に関しては、５月、８月が売上増加時期となり、虫除けスプレーに関しては、８月が売上増加時期となる。売上増加時期特定部２５は、このように各商品について、各月の売上数に基づいて売上増加時期を特定する。

なお売上増加時期は、商品の売上数が顕著に増加する時期である。ここでいう「時期」とは各種の期間が想定されるが、本実施の形態では説明の簡略化のため、１月から１２月の月単位の例で説明する。
もちろん実施の形態の処理において、売上増加時期としての「時期」とは月単位に限られない。例えば週単位、日単位、時間単位でもよく、またその期間としては、任意設定した期間、シーズン（春期間、夏期間、秋期間、冬期間）、夏休み時期（７月及び８月）、正月期間（１月１日〜１月５日）、盆期間（例えば８月５日〜８月１５日）、クリスマス期間（例えば１２月１５日〜１２月２５日）、特に一般的理由が不明な期間（例えば６月５日〜６月７日）なども想定される。いずれにしても、或る商品が、或る期間に売上が顕著に増加している場合、それがその商品の売上増加時期となる。

図３の推奨商品抽出部２６は、売上増加時期特定部２５が特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する処理を行う。
例えば図４Ａの例の場合、バーベキュー用品は売上増加時期が５月と８月の２つある。従って、バーベキュー用品を比較商品に設定する。そして、バーベキュー用品の売上増加時期と他の各商品の売上増加時期とを比較し、一部が一致する商品を推奨商品とする。例えば虫除けスプレーは５月がバーベキュー用品と一致するため、推奨商品とする。
図４Ｃには商品Ｍ１０，Ｍ２０の月毎の売上数を示しているが、この場合、商品Ｍ１０は３月、６月が売上増加時期となっており、商品Ｍ２０は６月、９月が売上増加時期となっている。いずれも売上増加時期が複数あるため、比較商品とされうる。
商品Ｍ１０が比較商品と選択された場合、売上増加時期として６月が一致しているため、商品Ｍ２０が推奨商品となる。また商品Ｍ２０が比較商品と選択された場合、売上増加時期として６月が一致しているため、商品Ｍ１０が推奨商品となる。
なお、推奨商品抽出部２６が推奨商品とするのは、売上増加時期が比較商品と一部一致している商品である。全部一致の商品は推奨商品とはしない。例えば図４Ａのバーベキュー用品が比較用品として選択されている場合に、或る商品の売上増加時期が５月と８月であった場合、その商品は推奨商品とはしない。

図３の推奨時期設定部２７は、推奨商品抽出部２６が抽出した推奨商品について、対応する比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する処理を行う。
対応する比較商品とは、その推奨商品が推奨される理由となった、売上増加時期の一部が一致する比較商品である。例えば図４Ａの「虫除けスプレー」が推奨商品とされた場合、対応する比較商品は「バーベキュー用品」である。そして比較商品（バーベキュー用品）の売上増加時期（５月、８月）であって当該推奨商品（虫除けスプレー）の売上増加時期（８月）とはなっていない時期を、当該推奨商品（虫除けスプレー）の推奨時期とするため、推奨時期は５月となる。

推奨時期は、その推奨商品の売上が顕著に伸びてはいない時期であるが、その時期も売れることが期待される時期である。つまり、比較商品と売上増加時期の一部が一致している商品については、比較商品が売れている時期であれば売れるであろうと推定するという考え方で推奨時期を設定する。
実際に、同時期に売れる商品同士には売れる理由となる何らかの関連性を有することが多い。本実施の形態では、その点に着目することで、或る商品について売れていない時期のうちで売れそうな時期を判定し、推奨時期とする。例えば虫除けスプレーは野外バーベキューではよく用いられる商品であり、実際には５月ころにも必要になることは多いが、人々の意識で、５月の時点（あまり虫を気にしていない時期）ではバーベキューの準備の際に虫除けスプレーに思い至らない場合が多い。つまり虫除けスプレーは、現状、５月に売上が伸びてはいないが、バーベキュー用品とともに５月にも売れる要因を備えた商品といえる。

図３の販売提案情報提供部２８は、送信対象店舗に選択した店舗端末４に対して、推奨商品抽出部２６が抽出した推奨商品と、その推奨商品について推奨時期設定部２７が設定した推奨時期の情報を含む、販売提案情報の送信制御を行う。
つまり販売提案情報提供部２８は、ある特定の時期に売れそうな商品を店舗に提案する処理を行う。

商品紹介制御部２９は、推奨商品抽出部２６が抽出した推奨商品についての商品紹介情報が、その推奨商品について推奨時期設定部２７が設定した推奨時期において、ユーザ端末５に提示されるように制御する。
つまり商品紹介制御部２９は、特定の時期に売れそうな商品を、その特定の時期においてユーザに紹介する処理を行う。特に推奨商品は、それまで当該特定の時期（推奨時期）に売れていたものではないため、商品紹介制御部２９の処理は、その時期にユーザにとって適切な商品を新たに紹介するという意味を持つ処理ともなり得る。

これらの機能を備えたＥＣサーバ２が推奨商品の抽出や推奨時期の設定、店舗端末４への提案、ユーザ端末５における紹介などを行うために用いる購買履歴ＤＢ６ｅ、時期管理ＤＢ６ｆについて説明する。

図５に時期管理ＤＢ６ｆと購買履歴ＤＢ６ｅの一例を示している。
時期管理ＤＢ６ｆは、各種商品が商品ＩＤ（Ｍ１，Ｍ２・・・）により登録されるとともに、各商品について、売上増加時期、推奨フラグ、推奨時期、非推奨時期、比較商品を登録するＤＢである。
この時期管理ＤＢ６ｆにエントリされる商品は、売上増加時期を有する商品である。つまり売上増加時期特定部２５によって、或る時期が売上増加時期とされた商品が、時期管理ＤＢ６ｆに登録される。
なお、エントリされる商品の商品ＩＤ（Ｍ１，Ｍ２・・・等）は、商品ＤＢ６ｃと共通の商品ＩＤにより登録されることで、商品ＤＢ６ｃの内容を参照する場合に都合がよい。

時期管理ＤＢ６ｆにおける各商品についての売上増加時期としては、その商品について売上増加時期特定部２５が特定した時期が登録される。なお図の数値は月を表す。
推奨フラグは、推奨商品抽出部２６の処理により推奨商品とされたことを示すフラグである。ここでは“１”が推奨商品、“０”が推奨商品とはされていないことを示すものとしている。
推奨時期は、その商品（推奨商品）について推奨時期設定部２７が設定した推奨時期（例えば月）が登録される。
非推奨時期は、各商品について、推奨時期とすることは相応しくない時期（例えば月）が予め登録されている。例えば商品Ｍ３が冬期商品である場合、７月、８月、９月は非推奨時期として登録されるなどである。
比較商品としては、その商品が推奨商品とされた際の比較商品を示す情報（例えば商品ＩＤ）が登録される。ここでは最低限、時期管理ＤＢ６ｆに登録されている比較商品を示すことができればよいため、時期管理ＤＢ６ｆ内のアドレス（或いはアドレスオフセット）などで比較商品を指す情報としてもよい。

なお、図では売上増加時期、推奨時期、非推奨時期を、それぞれ月単位の情報としたが、上述のように月単位に限らず、或る期間が示されれば良い。
また以上の時期管理ＤＢ６ｆは、例えば商品ＤＢ６ｃの一部として構成してもよい。つまり商品ＤＢにおいて、売上増加時期が存在する一部の商品について、売上増加時期、推奨フラグ、推奨時期、非推奨時期、比較商品が登録される形態でもよい。

購買履歴ＤＢ６ｅは、各商品について、仮想商店街において各種のユーザから購買された日時を登録したＤＢである。例えば図示のように、１つの商品を示す商品ＩＤ毎に、その商品が購買された日時情報が登録されている。
なお購買履歴ＤＢ６ｅは、例えば購買履歴ログ情報のような形式で、商品ＩＤと購買日時が時間軸に沿って並べられるものでもよい。いずれにしても、購買履歴ＤＢ６ｅは、各商品について、購買が発生した日時が検出できるものであれば良い。

＜３．推奨商品及び推奨時期の設定＞
以下、ＥＣサーバ２が実行する推奨商品の抽出及び推奨時期の設定処理を説明する。これは推奨商品を抽出し、また推奨時期を設定して、上記の推奨商品ＤＢ６ｇへ登録する処理である。大きく分けて、売上増加時期特定部２５の機能による各商品についての売上増加時期特定処理と、推奨商品抽出部２６及び推奨時期設定部２７の機能による推奨商品抽出／推奨時期設定の処理が、ＥＣサーバ２で行われる。

まず図６，図７により各商品の売上増加時期特定処理について説明する。
ＥＣサーバ２は、図６に示す売上増加時期特定処理を行う。これは、各商品の売上増加時期を調査し、売上増加時期が存在する商品について、例えば商品ＩＤと売上増加時期を時期管理ＤＢ６ｆに登録する処理となる。
各種の商品のうちには、特定の時期に売上が伸びるものがある。今、時期を月単位とする例で説明すると、例えば図７に示すように、各種の商品は、その性質によって月ごとに売上が変動する（又は変動しない）。
図７において商品ｍ１、ｍ３は、１２月、１月、２月が売上増加時期となる。
商品ｍ２は、７月、８月、９月が売上増加時期となる。
商品ｍ４は、特に売上増加時期はなく、年間でまんべんなく売上がある商品である。

図６の処理は、電子商店街で販売される各商品について、このような売上増加時期を特定するか又は売上増加時期が存在しないことを判定する処理となる。なお、もちろんこの処理は、電子商店街で取り扱われる全ての商品を対象としてもよいし、一部の商品を対象としてもよい。一部の商品とは、例えば選択した１又は複数のジャンルの商品、選択した１又は複数の価格帯の商品、年間売上数が所定数以上の商品などである。
ＥＣサーバ２は、電子商店街で取り扱われる全商品又は一部の商品について、商品毎にそれぞれ図６の処理を行う。

まずステップＳ１０１でＥＣサーバ２は、売上増加時期の特定を行う商品として処理対象とする１つの商品ＩＤを特定する。
ステップＳ１０２でＥＣサーバ２は、その特定した商品についての購買履歴の情報を購買履歴ＤＢ６ｅから取得する。つまり特定の商品ＩＤについての購買があった日時情報を取得する。
ステップＳ１０３でＥＣサーバ２は、当該処理対象の商品についての時期毎の売上数（販売された個数）を計算する。例えば各月の購買数を算出する。なお、例えば各商品について、時期毎の売上数が管理されているＤＢが存在するのであれば、そのＤＢから時期毎の売上数の情報を取得するのみでよい。

ステップＳ１０４でＥＣサーバ２は、当該商品について、売上数の時期的変動を判定する。即ち特定の時期が売上増加時期となっているか、或いは売上増加時期が存在しないかを判定する。
例えば各月毎の売上数について、標準偏差や分散の値を求め、その値が所定値以上であれば、つまり時期による売上数の変動が認められる値であれば、時期的変動がある商品とし、標準偏差や分散の値が所定値未満であれば、時期的変動がない商品と判定することが考えられる。
時期的変動がない商品の場合は、ステップＳ１０５から、その商品についての図６の処理を終える。例えば図７の商品ｍ４のような場合である。つまり時期的変動がない商品は時期管理ＤＢ６ｆには登録しない。

時期的変動がある商品であると判定した場合（例えば図７の商品ｍ１、ｍ２、ｍ３等の場合）は、ＥＣサーバ２はステップＳ１０５からＳ１０６に進み、売上増加時期の判定基準を設定する。判定基準とは、各時期の売上数を比較する値であり、各時期が売上増加時期であるか否かを判断する閾値である。
例えば月単位での売上数の平均値に或る加算値を加えた値を判定基準とする。図７には、各商品ｍ１、ｍ２、ｍ３について設定した判定基準ｒｆ１，ｒｆ２，ｒｆ３の例を示している。例えば判定基準ｒｆ１は、商品ｍ１の月ごとの売上数の平均値に、加算値を加算した値とする。
平均値に加算値を加えるのは、顕著に売上が増加している時期を判定するためである。

ステップＳ１０７でＥＣサーバ２は、その商品について売上増加時期を特定する。今、図７の商品ｍ１を処理対象としているとすると、ＥＣサーバ２は各時期（月）の売上数と判定基準ｒｆ１を比較して、売上数が判定基準ｒｆ１を越える時期を売上増加時期と特定する。
そしてステップＳ１０８でその商品の売上増加時期の情報を保存する。
即ち、その商品の商品ＩＤを新たなエントリとして時期管理ＤＢ６ｆに登録するとともに売上増加時期の情報を登録する。

以上の図６の処理を、処理対象とした全ての商品について完了することで、各商品の売上増加時期の特定ができたものとなる。
この時点で、時期管理ＤＢ６ｆには売上増加時期を有する商品が登録されていることになる。
なおステップＳ１０６で判定基準を商品毎に設定しているのは、平均的な売上数は商品毎に異なることを考慮して、それぞれの商品に適した判定基準で売上増加時期の特定ができるようにするためである。その意味で、加算値も商品毎に設定するとよい。例えば平均値の２０％を加算値とするなどである。

続いて図８により推奨商品及び時期判定処理の第１例を説明する。
ＥＣサーバ２は、時期管理ＤＢ６ｆに登録された商品について、図８に示す処理により、推奨商品を抽出し、それらの推奨時期を設定する。
図８の処理は、例えば先の図６の処理で時期管理ＤＢ６ｆに登録された商品のうちで、複数の売上増加時期を有する商品をそれぞれ順次、比較商品に選択して行う。

ＥＣサーバ２はステップＳ２０１で、時期管理ＤＢ６ｆに登録された商品のうちで、複数の売上増加時期を有する商品を選択し、比較商品とするとともに、その売上増加時期の情報を取得する。例えば図５の商品Ｍ１を比較商品とし、その売上増加時期の情報「５月、８月」を取得する。
そしてステップＳ２０２でＥＣサーバ２は、変数Ｎに商品数、変数ｎ＝１とセットする。変数Ｎに代入する商品数とは、時期管理ＤＢ６ｆに登録された商品の数である。

そしてＥＣサーバ２は、時期管理ＤＢ６ｆに登録された各商品について、ステップＳ２０３以降の処理を行う。
即ちＥＣサーバ２はまずステップＳ２０３で、時期管理ＤＢ６ｆに登録されているうちの第（ｎ）の商品を選択する。もし第（ｎ）の商品が、ステップＳ２０１で選択した比較商品である場合は、ステップＳ２０４からＳ２０９に進む。
ＥＣサーバ２は、ステップＳ２０９では、変数ｎが変数Ｎ（全商品数）に達したか否かを判定する。全商品についてステップＳ２０３以降の処理が終了していれば処理を終える。終了していなければ、ステップＳ２１０で変数ｎをインクリメントしてステップＳ２０３に戻る。つまり次の商品の処理に進む。

第（ｎ）の商品が比較商品以外の場合、ＥＣサーバ２はステップＳ２０５に進み、その第（ｎ）の商品についての売上増加時期の情報を時期管理ＤＢ６ｆから取得する。
そしてステップＳ２０６でＥＣサーバ２は、比較商品と、第（ｎ）の商品の売上増加時期を比較し、一部が一致しているか否かを判定する。
一致する時期がない場合、或いは全てが一致している場合は、ステップＳ２０９→Ｓ２１０→Ｓ２０３と進み、次の商品の処理に進む。

比較商品と第（ｎ）の商品の売上増加時期が一部一致していた場合、ＥＣサーバ２はステップＳ２０６からＳ２０７に進み、その第（ｎ）の商品を推奨商品に設定する。具体的には、その商品について推奨フラグを“１”とし、また対応する比較商品の情報を登録する。比較商品は、ステップＳ２０１で選択した商品（売上増加時期の一部一致を確認した商品）である。

続いてＥＣサーバ２はステップＳ２０８で、当該推奨商品の推奨時期を設定する。ステップＳ２０８の処理例を図９Ａに示す。
推奨時期は、対応する比較商品の売上増加時期であって、かつ当該推奨商品（第（ｎ）の商品）の売上増加時期とはなっていない時期である。そこでＥＣサーバ２は図９ＡのステップＳ２５０で、比較商品の売上増加時期のうちで、推奨商品の売上増加時期に含まれていない時期を、非一致時期として判定する。
そしてステップＳ２５１でＥＣサーバ２は、ステップＳ２５０で判定した非一致時期を、そのまま推奨時期とし、その推奨時期の情報を第（ｎ）の商品について登録する。
例えば比較商品が図５における商品Ｍ１、第（ｎ）の商品が商品Ｍ２の例でいうと、５月が推奨時期に該当する。そこで商品Ｍ２の推奨時期の情報として、図示のように５月と登録する。

ＥＣサーバ２は、図８のステップＳ２０９でｎ≧Ｎ、つまり全商品についてステップＳ２０３以降の処理が終了したと確認された時点で図８の処理を終える。
この時点で、或る１つの商品を比較商品として、売上増加時期の一部が共通する推奨商品と推奨時期が登録されたことになる。
続いて、例えば他の商品を比較商品とした状態で、同様に図８の処理を行う。このような処理により、時期管理ＤＢ６ｆにおいて、推奨商品と推奨時期が管理される状態となる。

推奨商品は、その推奨時期において、現状、さほど売上が伸びてはいないが、その推奨時期に売れる可能性が有ると推定された商品となる。
例えば、まだ一般に認知度が低い商品であったり、或いは知られている商品であっても例えば上述の５月における「虫除けスプレー」などのように、購入するユーザ側が、ある時期において購入に思い至らない商品などが想定される。

推奨商品及び時期判定処理の第２例を図１０で説明する。なお、図８と同一処理については同一符号を付し説明を省略する。
この第２例は、図８のステップＳ２０４，Ｓ２０５の間に、ステップＳ２２０，Ｓ２２１を加えた例である。
ＥＣサーバ２はステップＳ２２０では、比較商品と第（ｎ）の商品について関連性判定を行う。
そして関連性有りと判定した場合、ステップＳ２２１からＳ２０５に進み、売上増加時期の一部一致判定を行う。関連性無しと判定した場合は、ステップＳ２２１→Ｓ２０９→Ｓ２１０→Ｓ２０３と進んで次の商品の処理に移る。

即ちこの第２例は、推奨商品とする条件として、比較商品と売上増加時期が一部一致するだけでなく、関連性条件も付加するものである。
ステップＳ２２０での関連性判定としては、例えば次のような手法が考えられる。
・ユーザＤＢ６ａにおける履歴情報や、購買履歴ＤＢ６ｅの情報を参照して、同時に購入されたことがあるか（或いは所定回数以上、同時購入が行われているか）を確認し、同時購入の実績があれば関連性有りとする。
・商品ＤＢ６ｃ等でユーザレビューを参照し、第（ｎ）の商品や比較商品のレビューに他方の商品名が出現しているか（或いは出現が所定回数以上発見されたか）を確認し、出現実績があれば関連性有りとする。例えば「虫除けスプレー」のレビューに「バーベキューで使用します」等の文言があれば、関連性ありとする。
・第（ｎ）の商品と比較商品の商品ジャンルの一致又は近似により関連性を判断する。
・各商品についての商品関連性を示すＤＢを用意しておき、当該ＤＢを参照して関連性を判断する。
例えばこのような手法で関連性を判断し、比較商品との関連性が有ることを推奨商品の１つとすることで、全く無関係な商品との比較により、推奨商品とされることを回避する。

ところで図５の時期管理ＤＢ６ｆでは、非推奨時期の情報を登録する例を挙げたが、ここまで説明した処理例を用いる場合は、非推奨時期の情報は必ずしも登録しておく必要は無い。
そこで図９Ｂにより、非推奨時期の情報を用いる例を述べる。
図９Ｂは、図８又は図１０におけるステップＳ２０８の推奨時期設定処理の一例である。

ＥＣサーバ２は図９ＢのステップＳ２５０で、比較商品の売上増加時期のうちで、推奨商品の売上増加時期に含まれていない非一致時期を判定する。
次にステップＳ２５５でＥＣサーバ２は、第（ｎ）の商品の非推奨時期の情報を時期管理ＤＢ６ｆから取得する。
ステップＳ２５６でＥＣサーバ２は、ステップＳ２５０で判定した非一致時期と、ステップＳ２５５で取得した非推奨時期を比較し、非一致時期の全てが非推奨時期に該当するか否かを確認する。
そして非一致時期の全てが非推奨時期に該当するのでなければ、ＥＣサーバ２はステップＳ２５７に進み、非推奨時期に該当しない非一致時期を推奨時期とし、その推奨時期の情報を第（ｎ）の商品について登録する。
例えば比較商品が図５における商品Ｍ３で、第（ｎ）の商品が商品Ｍ４の例でいうと、商品Ｍ４について比較商品（Ｍ３）との非一致時期は、１月、１２月となる。ところが１２月は商品Ｍ４について非推奨時期に設定されている。そこで商品Ｍ４の推奨時期の情報としては、１２月を除き、図示のように１月のみ登録する。

ステップＳ２５６で、非一致時期の全てが非推奨時期に該当する場合、推奨時期とすべき時期は存在しないことになる。そこでＥＣサーバ２はステップＳ２５８に進み、その第（ｎ）の商品について、直前のステップＳ２０７で設定した推奨フラグをクリアする。推奨時期が存在しないものは推奨商品とはしないようにするためである。

このように非推奨時期は、推奨時期として登録されないようにする。例えば商品によっては、推奨時期としてあまり好適でない時期が存在するものもある。例えば海水浴関連の商品についての冬期などである。そのような時期を非推奨時期として登録しておくことで、適切ではない時期が推奨時期とされることがないようにできる。

＜４．店舗への販売提案＞
続いて推奨商品／推奨時期の情報の利用について説明する。まずここでは店舗への販売提案について述べる。推奨商品は推奨時期に売れそうな商品と推定されるものであるため、この情報を店舗に提供することで、店舗の販売促進機会を創出する。

ＥＣサーバ２は主に販売提案情報提供部２８の機能により、以下の図１１の販売提案情報送信処理を行う。
ＥＣサーバ２は図１１のステップＳ４０１で、本日の年月日を確認し、本日＋αで推奨時期となる推奨商品を時期管理ＤＢ６ｆから抽出する。ここで“α”とは、推奨商品の販売準備を考慮した日数であり、例えば店舗での販売企画、仕入れなどを考慮した日数であればよい。例えばα＝３０日、４５日、６０日などの固定値でもよいし、商品のジャンル、種別毎に設定した値などとしてもよい。
本日＋αで推奨時期となる推奨商品とは、例えば時期管理ＤＢ６ｆにおいて推奨フラグがオン（“１”）となっている商品であって、登録されている推奨時期からα日の前が本日となる商品である。例えばα＝６０日とした場合、本日が１０月２日であれば、推奨時期の先頭が１２月とされている推奨商品を抽出する。

続いてステップＳ４０２でＥＣサーバ２は、ステップＳ４０１で抽出した推奨商品の数を変数Ｚに代入する。そしてステップＳ４０３〜Ｓ４０９で、抽出した各推奨商品についての処理を行う。
ＥＣサーバ２はステップＳ４０３で変数Ｚ＝０であるか否かを確認する。変数Ｚ＝０とは、本日処理を行う推奨商品が存在しないか、或いはステップＳ４０１で抽出した各推奨商品についての処理を終えた場合である。

変数Ｚ＝０でなければ、ＥＣサーバ２はステップＳ４０４で、抽出した推奨商品の１つを処理対象として選択する。そして選択した推奨商品の商品ＩＤを取得する。
ステップＳ４０５でＥＣサーバ２は、選択した推奨商品の商品情報を、商品ＩＤを用いて例えば商品ＤＢ６ｃから取得する。例えば商品名、ジャンル情報、製品コード、製品画像等を取得する。

ステップＳ４０６でＥＣサーバ２は、当該処理対象の推奨商品についての情報を提供する提供先の店舗を選択する。例えば処理対象の推奨商品の情報を、その種の商品の取り扱いを行わない店舗に通知しても無駄である。
そこで、当該推奨商品を取り扱っている店舗、もしくは取り扱う可能性のある店舗を選択する。例えば店舗ＤＢ６ｂや商品ＤＢの情報を用いて、各店舗の取り扱い商品を確認し、当該推奨商品を既に扱っている店舗を検索する。また、現在は取り扱っていないが、当該推奨商品と同ジャンルの商品を扱っている店舗を取扱い可能性のある店舗として抽出してもよい。

ここで、当該推奨商品に対応する比較商品、即ち時期管理ＤＢ６ｆに、その推奨商品に対応して登録されている比較商品（推奨商品設定の際に売上増加時期の比較を行った商品）の取扱い店舗又は取扱い可能性を有する店舗を選択しても良い。
推奨商品は対応する比較商品との売上時期の相関性が想定されるものであるため、関連用品であり、同じ店舗で扱われる可能性が高いと推定されるためである。
また上述の図１０のように関連性条件が満たされた場合に推奨商品と設定される場合は特に、比較商品を扱う店舗では推奨商品を扱うことが推定されるためでもある。

ステップＳ４０７でＥＣサーバ２は、選択した推奨商品についての販売提案情報を生成する。例えば、当該対象の推奨商品についての時期管理ＤＢ６ｆに登録された情報や、商品ＤＢ６ｃから取得した情報を用いて、ステップＳ４０６で選択した１又は複数の店舗に送信する情報を生成する。例えば商品名、製品コード、推奨理由、推奨時期の情報を含む販売提案情報を生成する。

図１２に、ステップＳ４０７で生成する販売提案情報の例を示している。例えば商品名、製品コード、推奨理由、推奨時期、商品画像を含む例としている。
商品名、製品コードにより、商品を特定する。商品画像は必ずしも必要ではないが、店舗スタッフに推奨商品を伝える場合に有用である。
推奨理由としては、その推奨商品に対応する比較商品の情報を用いれば良い。例えば「虫除けスプレー」に関して「バーベキュー用品とともに売れる可能性がある」というような情報である。このような推奨理由を含むことで、店舗スタッフが、どうしてこの商品が販売提案されたかを理解しやすくできる。
推奨時期は、その推奨商品について時期管理ＤＢ６ｆに登録されている推奨時期の情報をそのまま用いる。

そして図１１のステップＳ４０８でＥＣサーバ２は、送信対象として選択した店舗へ、販売提案情報を送信する処理を行う。送信は、例えば電子メール形式でもよいし、店舗端末４への何らかのメッセージ送信機能が存在すれば、その機能を用いてもよい。
ＥＣサーバ２は、以上で１つの推奨商品についての販売提案情報の送信処理を終えたことに応じて、ステップＳ４０９で変数ＺをデクリメントしてステップＳ４０３に戻る。
ステップＳ４０３で変数Ｚ＝０となっていれば、図１１の処理を終える。変数Ｚ＝０でなければ、ステップＳ４０１で抽出した他の推奨商品についてのステップＳ４０４〜Ｓ４０９の処理を同様に行う。

以上の処理により、ＥＣサーバ２が特定の時期に売れる可能性が高いと推定した推奨商品の情報が、適切な時期に、適切な店舗に対して送信される。

＜５．ユーザへの商品紹介＞
次にユーザに対する推奨商品の紹介について第１例〜第３例を説明する。
ＥＣサーバ２が時期管理ＤＢ６ｆにおいて推奨フラグを立てた推奨商品は、或る対応する比較商品との相関性に基づいて推奨時期に売れそうな商品と推定されたものである。そこで推奨商品の情報を適切にユーザに提示すれば、ある理由で商品を探しているユーザにとって購入に適した商品を紹介できることになる。

第１例を図１３に示す。ＥＣサーバ２は主に商品紹介制御部２９の機能により、以下の図１３の商品紹介制御処理を行う。
ＥＣサーバ２は図１３のステップＳ５０１で、特定のユーザアクションを監視している。
ユーザアクションとは、ユーザ端末を用いてユーザが行う各種の行動であるが、例えばその中で、商品検索操作、購入手続操作（購入手続へ移行する操作や、その過程の操作）などを特定のユーザアクションとする。
或るユーザ端末５において、特定のユーザアクションが行われたことを検知したら、ＥＣサーバ２はステップＳ５０２に進み、そのユーザアクションの対象となっている商品を特定する。例えば商品検索操作の場合、検索ワードに基づいて検索される商品を対象商品として特定する。購入手続操作の場合、購入対象の商品を対象商品とする。

ステップＳ５０３でＥＣサーバ２は、時期管理ＤＢ６ｆにおいて推奨商品として登録されている商品の情報を参照し、ステップＳ５０２で特定した対象商品が比較商品として登録されている推奨商品が存在するか否かを確認する。そして存在した場合、その推奨商品を抽出する。
ステップＳ５０４でＥＣサーバ２は、ステップＳ５０３で抽出した推奨商品の数を変数Ｗに代入する。この時点で変数Ｗ＝０、つまり推奨商品が抽出されなかった場合は、今回検知した特定のユーザアクションに対応しては特に商品紹介は行わずに処理を終える。

１以上の推奨商品が抽出され変数Ｗ＝０とされていなければ、ＥＣサーバ２はステップＳ５０６に進み、抽出した推奨商品の１つを処理対象として選択する。そして選択した推奨商品の商品ＩＤを取得する。
ステップＳ５０７でＥＣサーバ２は、処理対象の推奨商品について時期管理ＤＢ６ｆに登録されている推奨時期を確認し、現在が、その推奨時期にあたるか否かを確認する。
現在がその推奨商品の推奨時期内であれば、ＥＣサーバ２はステップＳ５０８に進み、選択した推奨商品の商品情報を、商品ＩＤを用いて例えば商品ＤＢ６ｃや広告ＤＢ６ｄから取得する。例えば商品名、ジャンル情報、製品コード、製品画像、価格情報、その商品の広告情報等を取得する。

そしてステップＳ５０９でＥＣサーバ２は、対象の推奨商品についての商品情報、広告情報等の全部又は一部を用いて商品紹介情報を生成し、ステップＳ５１０でユーザ端末５において提示する情報として処理する。例えば商品紹介情報が所定のページデータに組み込まれた状態でユーザ端末５において表示されるようにページデータ生成やユーザ端末５への送信を行う。

具体的にはこの場合、特定のユーザアクションに対応する態様で商品紹介情報の生成及び出力を行う。
例えば検索操作の場合、ユーザ端末５で図１４のような表示が行われるようにする。
図１４は検索結果画面５１を例示している。この検索結果画面５１には、ＥＣサーバ２が検索部２４の機能により検索した商品の一覧を提示する。
ここではユーザがバーベキュー用品を検索した場合の検索結果画面５１の例として、検索結果領域５３にはバーベキュー用品としての各種の商品が提示されている状態を示している。この検索結果画面５１において紹介領域５２を設定し、ここに対象の推奨商品の情報が提示されるようにする。

この場合の処理は次のようになる。
ユーザ端末５においてバーベキュー用品についての検索操作が行われたことを、ＥＣサーバ２はステップＳ５０１で特定のユーザアクションとして検知する。ＥＣサーバ２はステップＳ５０２でバーベキュー用品を対象商品として特定する。そしてステップＳ５０３で時期管理ＤＢ６ｆを参照し、バーベキュー用品が比較商品として登録されている推奨商品として「虫除けスプレー」を抽出する。ＥＣサーバ２は、ステップＳ５０６で「虫除けスプレー」を処理対象とする。そして現在が「虫除けスプレー」の推奨時期として登録された５月であったため、ステップＳ５０８に進んだとする。ＥＣサーバ２は、ステップＳ５０８で「虫除けスプレー」の商品情報、広告情報、共通要素情報等のうちの必要な情報を取得し、ステップＳ５０９で商品紹介情報を生成する。例えば「虫除けスプレー」の広告情報と共通要素情報を用いて、「虫除けスプレー」を紹介する情報を生成する。この商品紹介情報は、バーベキュー用品の検索結果情報ともにウェブサーバ２２の機能によりページデータに合成された後、ユーザ端末５に送信され、図１４のように表示される。

また購入関連操作としてユーザアクションを検出した場合の提示例を図１５Ａ、図１５Ｂに示している。
図１５Ａはユーザが、「バーベキュー用品」を買い物かごに入れ、購入手続を開始しようとする場合の例である。この場合、買い物かごの商品を提示するカート商品領域５５とともに紹介領域５６を設定し、ここに対象の推奨商品の情報が提示されるようにする。
この場合の処理は次のようになる。ユーザ端末５において「バーベキュー用品」が買い物かごに入れられて購入手続に移行したことを、ＥＣサーバ２はステップＳ５０１で特定のユーザアクションとして検知する。そしてこの場合、上記同様に「バーベキュー用品」を対象商品とし、ステップＳ５０３で「バーベキュー用品」が比較商品とされた推奨商品として「虫除けスプレー」を抽出する。そしてステップＳ５０８、Ｓ５０９でＥＣサーバ２は、「虫除けスプレー」の商品紹介情報を生成する。この商品紹介情報は、ウェブサーバ２２の機能により購入手続のページデータに合成された後、ユーザ端末５に送信され、図１５Ａのような表示が実行される。

図１５Ｂはユーザが、「バーベキュー用品」の購入手続を完了した場合の例である。例えば購入完了を示す通知領域５７とともに紹介領域５８を設定し、ここに対象の推奨商品の情報が提示されるようにする。
この場合の処理としては、ユーザ端末５において「バーベキュー用品」の購入手続が完了に達したことを、ＥＣサーバ２はステップＳ５０１で特定のユーザアクションとして検知する。そしてステップＳ５０２以降で同様の処理が行われ、「虫除けスプレー」の商品紹介情報が生成され、商品紹介情報がウェブサーバ２２の機能により購入完了のページデータに合成された後、ユーザ端末５に送信され、図１５Ｂのような表示が実行される。

図１３のステップＳ５１０までの処理で、１つの推奨商品について以上の例のようにユーザ端末５において商品紹介が行われる。
ＥＣサーバ２はステップＳ５１１で変数ＷをデクリメントしてステップＳ５０５に戻る。
ステップＳ５０５で変数Ｗ＝０となっていれば、図１３の処理を終える。変数Ｗ＝０でなければ、ステップＳ５０３で抽出した他の推奨商品についてのステップＳ５０６〜Ｓ５１１の処理を同様に行う。
なお、複数の推奨商品について商品紹介情報が生成された場合、最終的なユーザ端末への送信は、各推奨商品の商品紹介情報が生成された後において行われるようにするとよい。例えば複数の推奨商品の商品紹介情報をそれぞれページデータとして合成した後に、ユーザ端末への送信が行われるとよい。

ところで或る推奨商品についてのステップＳ５０７の判断で、もし現在が、その推奨商品の推奨時期でなければ、ステップＳ５１１に進んで変数ＷをデクリメントしステップＳ５０５に戻る。つまりその推奨商品についての商品紹介情報は生成せず、ユーザへの商品紹介は行わないようにしている。

なお、図１２のように商品紹介を行う場合のトリガとなる特定のユーザアクションとしては、検索操作や購入関連操作は一例である。
例えば或る商品（比較商品）についてのお気に入り登録操作を特定のユーザアクションとしてもよい。その場合、お気に入り登録後の画面、例えばお気に入り登録一覧画面で、推奨商品の紹介が行われれば良い。或いはお気に入り登録後に、各種ページ上での広告と同様の態様で推奨商品の紹介が行われるようにしてもよい。
また。或る商品（比較商品）についての検索結果画面のクリックや、広告のクリックなどを特定のユーザアクションとし、これらの場合に遷移するページ、例えば商品詳細ページや店舗ページなどにおいて、推奨商品の紹介情報が提示されてもよい。
もちろん他のユーザアクションも考えられる。いずれの場合も図１３と同様の処理が行われれば良い。
いずれにしても、比較商品を対象とする特定のユーザアクションは、そのユーザが比較商品に興味を持った場合に行うものであるため、その後の画面、例えば検索結果ページ、購入手続ページ、商品詳細ページ、お気に入り登録ページなどで推奨商品を提示することでユーザに的確な商品紹介ができる。

次に商品紹介制御としての第２例を図１６で説明する。
図１６は、図１３のステップＳ５０７とＳ５０８の間にステップＳ５２０の処理を加えた例である。
ステップＳ５２０でＥＣサーバ２は、ユーザアクションの対象となった商品と同じ店舗で処理対象としている推奨商品が扱われているか否かを確認する処理を行う。
例えば図１５Ａ、図１５Ｂの例のトリガとした購入関連操作が行われた場合に、その購入店舗で、推奨商品が販売されているか否かを店舗ＤＢ６ｂ等の情報から確認する。そして取り扱われている場合のみ、ステップＳ５０８〜Ｓ５１０の処理を行う。
これにより、購入手続のページや、店舗ページ或いは商品詳細ページにおいて推奨商品の商品紹介情報を提示させるのは、その推奨商品が、その対象の店舗で取り扱われている場合のみとなる。従って商品紹介情報を、当該店舗での販売促進に適した情報とすることができる。

商品紹介制御としての第３例を図１７で説明する。図１７においてステップＳ５０４以降は図１３と同様である。ステップＳ５３０，Ｓ５３１が図１３と異なる。
この例は、ユーザの購入履歴に応じて、推奨時期に推奨商品の紹介情報が提示されるようにする例である。

ＥＣサーバ２は、ステップＳ５３０でログインしたユーザの情報をユーザＤＢ６ａから取得する。そしてステップＳ５３１でＥＣサーバ２は、そのユーザの購入履歴を確認し、購入した商品が比較商品とされている推奨商品を抽出する。
即ちＥＣサーバ２は、時期管理ＤＢ６ｆにおいて推奨商品として登録されている商品についての比較商品の情報とユーザの購入履歴を比較して、そのユーザが購入したことのある商品が比較商品とされている推奨商品を抽出する。
そしてステップＳ５０４でＥＣサーバ２は、ステップＳ５０３で抽出した推奨商品の数を変数Ｗに代入する。この時点で変数Ｗ＝０、つまり推奨商品が抽出されなかった場合は特に商品紹介は行わずに処理を終える。変数Ｗ＝０でなければ、抽出した推奨商品についてステップＳ５０６以降の処理を行う。

つまりこの図１７の例では、或る推奨商品の比較商品を購入したことのあるユーザに対して、その推奨商品を推奨時期に紹介する処理が行われることになる。

ここまで商品紹介制御の例として第１例から第３例を説明したが、これら以外にも商品紹介制御例は考えられる。
例えば、ユーザアクションに関わらず、また特定のユーザを対象とせずに、推奨商品の紹介情報が提示されるようにすることも考えられる。例えば現在が推奨時期となる推奨商品を選択し、任意の時点でユーザ端末５に送信する例である。
或いはまた、現在が推奨時期となっている推奨商品の広告を表示させるという処理も考えられる。

＜６．まとめ及び変形例＞
以上、実施の形態について説明してきたが、本実施の形態によれば、以下のような効果が得られる。
実施の形態のＥＣサーバ２（情報処理装置）は、商品毎の購買された日時が記憶された購買履歴ＤＢ６ｅの情報を用いて各商品の売上増加時期を特定する売上増加時期特定部２５を有する。またＥＣサーバ２は、売上増加時期特定部２５が特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出部２６を有する。またＥＣサーバ２は、推奨商品抽出部２６が抽出した推奨商品について、対応する比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定部２７を有する。
売上増加時期を複数有する商品を比較商品としたときに、売上増加時期の一部が比較商品と一致している商品は、比較商品との売上要因の類似性を有すると推定できる。そのため比較商品の売上増加時期であって、かつ推奨商品の売上増加時期とはなっていない時期は、推奨商品の売上増加が期待できる時期と推定できる。
従って実施の形態のＥＣサーバ２によれば、或る時期に顕著に売れているという実績のある商品であって、他の時期でも売れる可能性が或る商品及びその時期を容易に判定できるという効果がある。そしてこの情報を利用することで、推奨商品及び推奨時期を用いた効率的な情報の提供や市場運営が可能となる。

特に、実際に売れそうな理由がありながら特定の時期に売れていない商品を抽出するのは、従来は、各商品の種別、性質、機能、価格等の属性や、時期的適合性、さらには売上げ実績データなどを照合して、非常に困難な分析が必要となると考えられてきた。これに対して実施の形態の手法によれば、特定時期に売れる商品同士の相関性に着眼して推奨商品及び推奨時期を抽出するため、非常に簡易な処理で、特定時期に売れそうな商品を抽出できる。
またこのように商品について売れそうな時期を簡易に推定することは、いわゆる強調フィルタリング等の手法では困難である。協調フィルタリングでは、例えば属性が共通するユーザ間での商品購入履歴の関連性を用いて、対象のユーザが興味を持つと推定される商品を判定するものであるが、売れそうな時期を簡易に判定することはできない。本実施の形態は、これを推奨商品の推奨時期として設定し、推奨商品の情報を適切なタイミングで用いることができるようにしている。

またＥＣサーバ２（推奨商品抽出部２６）は、図１０の例で示したように、比較商品に対して、売上増加時期の一部が一致する商品であって、かつ、比較商品との関連性判定により関連性があると判定した商品（Ｓ２２０，Ｓ２２１）を、推奨商品とする。
即ち比較商品と売上増加時期が一部一致するだけでなく、関連性条件も付加して推奨商品を抽出する。このようにすると、比較商品とのある程度の相関性があるものが推奨商品とされることになるため、設定する推奨時期の信頼性を高めることができる。

またＥＣサーバ２（推奨時期設定部２７）は、図９Ｂの例として示したように、推奨商品について、対応する比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期のうちで、当該推奨商品について設定された非推奨時期を除いた時期（Ｓ２５６，Ｓ２５７）を、当該推奨商品の推奨時期と設定する。
図５の時期管理ＤＢ６ｆにおける非推奨時期のように、予め商品について推奨する時期としては相応しくない時期を非推奨時期として設定しておく。すると、この非推奨時期の情報を参照して、不適切な推奨時期を設定することがないようにできる。例えば海水浴用品について１月、２月を推奨時期としてしまうことがない。これによってあまり適切とはいえない時期に販売提案や商品紹介を行うことを回避できる。
但し、推奨時期は、あくまで店舗への販売提案やユーザへの商品紹介の基準になるものであって、商品の販売時期ではない。このため推奨時期は非推奨時期を避けて設定するものとしなくても大きな問題は生じないが、非推奨時期を避けて設定することで販売提案や商品紹介の時期的な適切さを向上できるものである。

なお例えば図９Ａのように推奨時期の設定に非推奨時期を考慮しない場合でも、非推奨時期を用いて適切なタイミングで販売提案やユーザへの商品紹介を行うこともできる。例えば図１１のステップＳ４０１でいう推奨時期を、推奨時期と登録されている時期のうちで非推奨時期を除いた時期とすればよい。
また例えば図１３のステップＳ５０７でいう推奨時期を、推奨時期と登録されている時期のうちで非推奨時期を除いた時期とすればよい。
このようにすれば、非推奨時期に合わせた販売提案やユーザへの商品紹介が行われないようにすることができる。

またＥＣサーバ２（販売提案情報提供部２８）は、送信対象店舗に選択した店舗端末４に対して、推奨商品とその推奨時期の情報を含む販売提案情報の送信制御を行うようにしている（図１１）。
これにより推奨商品を、推奨時期に売れそうな商品として店舗に通知することで販売準備の機会を提供する。また店舗が販売機会を逃さないことで、電子商取引を活性化することができる。

またＥＣサーバ２（販売提案情報提供部２８）は、或る推奨商品の販売提案情報について、その推奨商品の取扱い店舗又は取扱い可能性を有する店舗を送信対象店舗として選択している（Ｓ４０６）
これにより、推奨商品に関する販売提案情報を、その推奨商品に無関係な店舗、つまり取り扱うことがない店舗に提供しないようにして、店舗側に無駄と認識される通知を避ける。逆に送信対象店舗は、その推奨商品に関係がある店舗となることで、販売提案情報が有効な情報となる。

またＥＣサーバ２（販売提案情報提供部２８）は、或る推奨商品の販売提案情報について、その推奨商品が対応する比較商品の取扱い店舗又は取扱い可能性を有する店舗を送信対象店舗として選択している（Ｓ４０６）。
推奨商品に対応する比較商品は、推奨商品との相関性がある商品であるため、比較商品を扱う店舗では、推奨商品を扱うことも想定される。従って、比較商品を扱う店舗にも、推奨商品に関する販売提案情報は有効な情報となる。

またＥＣサーバ２（販売提案情報提供部２８）は、販売提案情報で通知する推奨時期の開始日から所定日時（α）前の時点で、販売提案情報を送信対象店舗に対して送信する制御を行うようにしている（Ｓ４０１）。
これにより、店舗側で売上増加時期に合わせて商品販売準備を整えることができる適切なタイミングで販売提案情報を送信できる。

またＥＣサーバ２（商品紹介制御部２９）は、推奨商品についての商品紹介情報が、その推奨商品についての推奨時期において、ユーザ端末５に提示されるように制御している（図１３、図１６、図１７のＳ５０７）
推奨商品は、比較商品との売上増加時期の比較に基づいて、これまで特に顕著な売上がなかった時期（推奨時期）に売れる可能性があると推定された商品である。そこで、売れる可能性の或る推奨時期において、その商品がユーザ端末で紹介されるようにすることが好適な紹介タイミングとなる。また他の時期にむやみに紹介を行いすぎて、ユーザに煩わしく感じさせることも防止できる。

またＥＣサーバ２（商品紹介制御部２９）は、或る推奨商品の推奨時期に、その推奨商品が対応する比較商品を対象とする特定のユーザアクションが行われたユーザ端末５において、当該推奨商品についての商品紹介情報が提示されるように制御している（図１３）。
或る比較商品を対象として商品ウェブページ閲覧等の特定のユーザアクションを行ったユーザは、或る目的でその比較商品の購入を考えているユーザであると推定できる。すると、比較商品に対応する推奨商品にも興味を持つユーザとも推定できる。そこで商品紹介情報として、ユーザの目的に沿う商品と推定される推奨商品を推奨時期に提示することで、ユーザに的確な商品紹介ができる。

またＥＣサーバ２（商品紹介制御部２９）は、ユーザ端末５を使用するユーザの購入履歴に含まれる商品が比較商品とされた推奨商品について、その商品紹介情報が、当該推奨商品の推奨時期に、ユーザ端末５において提示されるように制御する場合もある（図１７）。
或る比較商品を購入したユーザは、比較商品に対応する推奨商品にも興味を持つユーザと推定できる。そこで商品紹介情報として、ユーザの目的に沿う商品と推定される推奨商品を、推奨時期に提示することでユーザに的確な商品紹介ができる。

本発明は上述の実施の形態に限らず、多様な変形例が考えられる。
推奨商品の抽出には、図８における売上増加時期の条件、或いは図１０における売上増加時期の条件と関連性判定という条件に加えて、各種の条件設定を行ってもよい。
例えば推奨商品として価格上限や価格下限を設定し、あまり高価な商品や安価過ぎる商品は推奨商品とは設定しないということも考えられる。
また、推奨商品の条件として、仮想商店街全体での在庫数が所定数以上、取扱い店舗数が所定数以上などとしての条件を設定してもよい
また、比較商品と同価格帯の商品であるという条件を設定してもよい。

またユーザ端末５への商品紹介として、例えば推奨時期が共通する複数の推奨商品を時期管理ＤＢ６ｆから抽出して、推奨時期に、それらの商品の一覧表示を行うようにすることも考えられる。

また例えばウェブページ上で複数個（ｎ個）の商品紹介情報を提示可能な場合に、ｍ個（ｍ＞ｎ）の推奨商品が紹介する対象となった場合において、ユーザに提示する推奨商品の選択手法は各種考えられる。例えばランダムに１つ又は所定数を紹介する商品として選択したり、ユーザの履歴や属性に応じて紹介する推奨商品を選択することも考えられる。或いは在庫数、販売実績などにより選択しても良い。

＜７．プログラム及び記憶媒体＞
以上、本発明の情報処理装置の実施の形態としてのＥＣサーバ２を説明してきたが、実施の形態のプログラムは、ＥＣサーバ２における少なくとも売上増加時期特定部２５、推奨商品抽出部２６、推奨時期設定部２７の処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

実施の形態のプログラムは、商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定手順（Ｓ１０１〜Ｓ１０８）と、前記売上増加時期特定手順で特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出手順（Ｓ２０１〜Ｓ２０７）と、前記推奨商品抽出手順で抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定手順（Ｓ２０８）とを情報処理装置に実行させる。
即ちこのプログラムは、情報処理装置に図６、図８（又は図１０）及び図９で説明した処理を実行させるプログラムである。またさらに図１１、図１３（又は図１６、図１７）の処理を実行させるプログラムとしてもよい、

このようなプログラムにより上述したＥＣサーバ２としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

１ ネットワーク、２ ＥＣサーバ、４ 店舗端末、５ ユーザ端末、６ 電子商取引ＤＢ、６ａ ユーザＤＢ、６ｂ 店舗ＤＢ、６ｃ 商品ＤＢ、６ｄ 広告ＤＢ、６ｅ 購買履歴ＤＢ、６ｆ 時期管理ＤＢ、２１ 通信部、２２ ウェブサーバ、２３ 管理部、２４ 検索部、２５ 売上増加時期特定部、２６ 推奨商品抽出部、２７ 推奨時期設定部、２８ 販売提案情報生成部、２９ 商品紹介制御部

特に、実際に売れそうな理由がありながら特定の時期に売れていない商品を抽出するのは、従来は、各商品の種別、性質、機能、価格等の属性や、時期的適合性、さらには売上げ実績データなどを照合して、非常に困難な分析が必要となると考えられてきた。これに対して実施の形態の手法によれば、特定時期に売れる商品同士の相関性に着眼して推奨商品及び推奨時期を抽出するため、非常に簡易な処理で、特定時期に売れそうな商品を抽出できる。
またこのように商品について売れそうな時期を簡易に推定することは、いわゆる協調フィルタリング等の手法では困難である。協調フィルタリングでは、例えば属性が共通するユーザ間での商品購入履歴の関連性を用いて、対象のユーザが興味を持つと推定される商品を判定するものであるが、売れそうな時期を簡易に判定することはできない。本実施の形態は、これを推奨商品の推奨時期として設定し、推奨商品の情報を適切なタイミングで用いることができるようにしている。

Claims (12)

1. 商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定部と、
   前記売上増加時期特定部が特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出部と、
   前記推奨商品抽出部が抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定部と、を備えた
   情報処理装置。
2. 前記推奨商品抽出部は、前記比較商品に対して、売上増加時期の一部が一致する商品であって、かつ、前記比較商品との関連性判定により関連性があると判定した商品を、前記推奨商品とする
   請求項１に記載の情報処理装置。
3. 前記推奨時期設定部は、前記推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期のうちで、当該推奨商品について設定された非推奨時期を除いた時期を、当該推奨商品の推奨時期と設定する
   請求項１又は請求項２に記載の情報処理装置。
4. 送信対象店舗に選択した店舗の端末装置に対して、前記推奨商品抽出部が抽出した推奨商品と、その推奨商品について前記推奨時期設定部が設定した推奨時期の情報を含む、販売提案情報の送信制御を行う販売提案情報提供部を備えた
   請求項１に記載の情報処理装置。
5. 前記販売提案情報提供部は、或る推奨商品の前記販売提案情報について、その推奨商品の取扱い店舗又は取扱い可能性を有する店舗を前記送信対象店舗として選択する
   請求項４に記載の情報処理装置。
6. 前記販売提案情報提供部は、或る推奨商品の前記販売提案情報について、その推奨商品が対応する前記比較商品の取扱い店舗又は取扱い可能性を有する店舗を前記送信対象店舗として選択する
   請求項４又は請求項５に記載の情報処理装置。
7. 前記販売提案情報提供部は、前記販売提案情報で通知する推奨時期の開始日から所定日時前の時点で、前記販売提案情報を前記送信対象店舗に対して送信する制御を行う
   請求項４乃至請求項６のいずれかに記載の情報処理装置。
8. 前記推奨商品抽出部が抽出した推奨商品についての商品紹介情報が、その推奨商品について前記推奨時期設定部が設定した推奨時期において、ユーザ端末に提示されるように制御する商品紹介制御部を備えた
   請求項１乃至請求項７のいずれかに記載の情報処理装置。
9. 前記商品紹介制御部は、或る推奨商品の推奨時期に、その推奨商品が対応する前記比較商品を対象とする特定のユーザアクションが行われたユーザ端末において、当該推奨商品についての商品紹介情報が提示されるように制御する
   請求項８に記載の情報処理装置。
10. 前記商品紹介制御部は、ユーザ端末を使用するユーザの購入履歴に含まれる商品が前記比較商品とされた推奨商品についての商品紹介情報が、当該推奨商品の推奨時期に、前記ユーザ端末において提示されるように制御する
    請求項８又は請求項９に記載の情報処理装置。
11. 情報処理装置が実行する情報処理方法として、
    商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定ステップと、
    前記売上増加時期特定ステップで特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出ステップと、
    前記推奨商品抽出ステップで抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定ステップと、を備えた
    情報処理方法。
12. 商品毎の購買された日時が記憶された購買履歴情報を用いて各商品の売上増加時期を特定する売上増加時期特定手順と、
    前記売上増加時期特定手順で特定した売上増加時期を複数有する商品を比較商品とし、該比較商品に対して、売上増加時期の一部が一致する商品を推奨商品として抽出する推奨商品抽出手順と、
    前記推奨商品抽出手順で抽出した推奨商品について、対応する前記比較商品の売上増加時期であって、かつ当該推奨商品の売上増加時期とはなっていない時期を、当該推奨商品の推奨時期と設定する推奨時期設定手順と、
    を情報処理装置に実行させるプログラム。

Images