JP6944531B2 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Description

本発明は情報処理装置、情報処理方法、プログラム、記憶媒体に関し、特にユーザに情報を送信する技術に関する。

ネットワーク上におけるユーザの行動に基づいてユーザに有益と思われる情報を提供する技術が知られている。例えば、ユーザの閲覧履歴に応じて該ユーザの興味を惹起させるような商品ページを提示することや、各種の広告からユーザの購買履歴に応じた広告を選択して提示することなどが行われている。
そして、これらの技術を応用して、インターネット上における情報提示だけでなく実際の店舗（実店舗）においても、ユーザの行動に基づいて有益と思われる情報の提示を行う技術が開示されている。
例えば、特許文献１においては、ユーザのプロファイル情報と購買履歴情報に基づいて実店舗における商品購入を提案する情報を提供する技術が開示されている。

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

しかし、特許文献１に開示された技術は、ユーザが来店した店舗に関するレコメンド情報を送信するものの、それが適切なタイミングで行われているとは限らない。

本発明は、このような事情を鑑みてなされたものであり、来店した店舗でユーザが目的を果たせなかったと推定できる場合に有益な情報を提供することを目的とする。

本発明に係る情報処理装置は、ユーザが店舗から退店したことを検出する検出部と、前記店舗の情報に基づくレコメンド情報を退店が検出されたユーザに送信するレコメンド部と、を備えている。
これにより、レコメンド情報の送付対象となるユーザを退店したことを検出したユーザに絞り込んだ上でレコメンド情報の送信が行われる。

上述した情報処理装置の前記検出部は、前記店舗でユーザの支払いの有無を検出してもよい。
ユーザが購買行動を行ったか否かに応じてレコメンド情報の要否や選別が行われる。

上述した情報処理装置の前記レコメンド部は、退店が検出された店舗における支払いが検出されなかった場合に前記レコメンド情報として退店が検出された店舗に関する情報を送信してもよい。
ユーザが来店した店舗はユーザの興味関心に合致する店舗である可能性が高い。そのような店舗についてのレコメンド情報がユーザに送信される。

上述した情報処理装置の前記レコメンド部は、退店が検出された店舗における支払いが検出されなかった場合に前記レコメンド情報として退店が検出された店舗とは異なる代替店舗に関する情報を送信してもよい。
来店したにも関わらず購買行動が検出されなかった店舗は、ユーザが目的が果たせなかった可能性が高い。そのような店舗の代替となる店舗がユーザに提示される。

上述した情報処理装置の前記レコメンド部は、前記代替店舗が利用不可である場合には該代替店舗に関する前記レコメンド情報の送信を行わなくてもよい。
利用不可である店舗をレコメンドすることは、通知を受け取ったユーザにとって不利益となりかねない。

上述した情報処理装置の前記レコメンド部は、複数の代替店舗が抽出された場合には、支払いを行ったユーザが多く検出された店舗を前記レコメンド情報として送信してもよい。
多くの購買行動が検出された店舗は、多くのユーザにとって適切な店舗である可能性が高い。そのような店舗が代替店舗として購買行動が検出されなかったユーザに対してレコメンドされる。

上述した情報処理装置の前記レコメンド部は、ユーザが支払いを行った時間情報を用いて前記レコメンド情報の送信を行ってもよい。
即ち、ユーザが店舗へ来店したことを検出した時間と、他のユーザによる代替店舗での購買行動を検出した時間を考慮してレコメンド情報としての代替店舗が送信される。

上述した情報処理装置の前記レコメンド部は、送信対象とされたユーザの位置に関する気象情報を用いて前記レコメンド情報の送信を行ってもよい。
例えば、レコメンド情報として送信する代替店舗が混雑しており待ち時間が発生する可能性がある場合に、待ち時間を適切な状態で過ごすことができるかどうかなどを加味して代替店舗の選択及び提示を行うことができる。

上述した情報処理装置の前記検出部は、ユーザが所定エリア内に位置することを検出した状態から検出されない状態へと変化することによって退店したことを検出してもよい。
これにより、来店を検出する手法を用いて退店の検出が行われる。
上述した情報処理装置の前記検出部は、近距離無線通信を用いて店舗から退店したことを検出してもよい。
これにより、店舗からの退店を検出するために例えばＧＰＳ機能などをユーザが携帯する情報端末上で起動しておく必要がない。

本発明に係る情報処理方法は、店舗におけるユーザの支払いの有無を検出する検出ステップと、ユーザが店舗から退店したことを検出するステップと、退店が検出された店舗における前記支払いが検出されなかった場合に当該退店が検出されたユーザのユーザ端末に当該退店が検出された店舗に関する情報をレコメンド情報として送信するレコメンドステップと、を情報処理装置が実行するものである。
この情報処理方法により、来店した店舗でユーザが目的を果たせなかったと推定できる場合に有益な情報を提供することができる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。本発明に係る記憶媒体は、上記プログラムを記憶したものである。これらにより上述の情報処理装置の処理を実現する。

本発明によれば、来店した店舗でユーザが目的を果たせなかったと推定できる場合に有益な情報を提供することができる。

本発明の実施の形態のレコメンドサーバを含むネットワークの説明図である。 実施の形態のレコメンドサーバの機能構成の説明図である。 履歴ＤＢの一例を示す図である。 実施の形態で利用できるコンピュータ装置のブロック図である。 第１の実施の形態に関するフローチャートである。 第１の実施の形態のレコメンド情報抽出処理のフローチャートである。 第１の実施の形態のレコメンド情報選択処理のフローチャートである。 第２の実施の形態に関するフローチャートである。 第２の実施の形態のレコメンド情報抽出処理のフローチャートである。 第２の実施の形態のレコメンド情報選択処理のフローチャートである。 レコメンド情報抽出処理の別例のフローチャートである。 レコメンド情報選択処理の別例のフローチャートである。 レコメンド情報抽出処理の別例２のフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．システム構成＞
＜２．各処理例＞
＜２−１．第１の実施の形態＞
＜２−２．第２の実施の形態＞
＜２−３．レコメンド情報抽出処理の別例＞
＜２−４．レコメンド情報選択処理の別例＞
＜２−５．レコメンド情報抽出処理の別例２＞
＜３．変形例＞
＜４．まとめ＞
＜５．プログラム及び記憶媒体＞

＜１．システム構成＞

図１に実施の形態のレコメンドサーバ１を含むネットワークシステムの構成例を示す。
本実施の形態に係るネットワークシステムは、ユーザ（会員）にレコメンド情報を提供するためのレコメンドサーバ１と、ユーザが所持するユーザ端末２が通信ネットワーク３により接続されている。レコメンドサーバ１がユーザに提供するレコメンド情報は、店舗２００に関する情報である。具体的には、店舗２００が扱う商品の情報や店舗２００そのものの情報などである。

図１には、店舗２００の一例である店舗２００Ａを示している。店舗２００Ａには、クレジットカード端末４や電子マネー端末５やポイントカード端末６が設置されており、各端末は通信ネットワーク３に接続されている。
また、クレジットカード端末４、電子マネー端末５、ポイントカード端末６のそれぞれに応じてクレジットカードシステム７、電子マネーシステム８、ポイントカードシステム９が通信ネットワーク３に接続されている。

クレジットカード端末４は、ユーザが商品購入の際に利用するクレジットカードの有効性を確認するための端末である。クレジットカード端末４で読み込まれたクレジットカードの情報は、通信ネットワーク３を介してクレジットカードシステム７へと送信される。クレジットカードシステム７では、クレジットカードの有効性が確認され、その結果がクレジットカード端末４へと送信される。
クレジットカードシステム７では、それ以外にもクレジットカードの利用者情報の管理や店舗への商品代金の支払いやユーザに対する利用料金の請求などの各種処理を行う。

電子マネー端末５は、電子マネーを商品購入に用いるための端末であり、電子マネーがチャージされたカードから情報を読み取り決済を行う。電子マネー端末５で読み取られた情報は電子マネーシステム８へ送信される。電子マネーシステム８は、電子マネーの利用に応じてチャージ額の減算処理を行い、店舗への支払い処理を行う。
電子マネーシステム８は、他にも、利用者及び電子マネーカードに関する情報の管理や、電子マネーのチャージに基づくチャージ額の加算処理などを行う。

ポイントカード端末６は、商品の購入などによるポイントの付与や商品購入及び特典の享受などによるポイントの使用などに利用されるポイントカードを読み取るための端末である。ポイントカード端末６で読み取ったポイントカードの情報は、通信ネットワーク３を介してポイントカードシステム９に送信される。ポイントカードシステム９は、ポイントの利用に応じたポイント数の減算処理を行い、利用したポイント数に応じた金額を店舗へ支払う処理を行う。
ポイントカードシステム９は、他にも、ポイントカードの利用者情報の管理や、ポイント数の管理や、ポイントカードを利用可能な店舗情報の管理などを行う。

店舗２００Ａには、近距離無線発信器が設置されている。近距離無線通信発信器の一例として、以下の説明においてはビーコン発信器１０を用いる。
ビーコン発信器１０は、近くに位置する情報処理端末等を把握するために設置されているものであり、例えば内部に搭載された電池によって一定間隔（数百ｍｓ間隔など）で情報送信を行う。ビーコン発信器１０の電波到達距離は例えば数ｍ〜数十ｍとされている。従って、少なくとも店舗２００Ａにユーザが来店したことを検出可能とされている。
なお、店舗２００Ａの敷地が広い場合には、電波到達距離の長いビーコン発信器１０を設置してもよいし、或いは複数のビーコン発信器１０，１０，・・・を設置してもよい。

なお、図１では、店舗２００Ａにクレジットカード端末４、電子マネー端末５、ポイントカード端末６がそれぞれ一つずつ設置されている状態を示しているが、これは一例であり、複数のクレジットカード端末４，４，・・・や複数の電子マネー端末５，５，・・・や複数のポイントカード端末６，６，・・・が設置されていてもよい。また、全ての種類の端末が設置されている必要はなく、例えばクレジットカード端末４が設置されていなくてもよいし、電子マネー端末５が設置されていなくてもよいし、ポイントカード端末６が設置されていなくてもよい。

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

ユーザ端末２は、ビーコン発信器１０から発信された情報（ビーコン信号）を受信可能とされている。また、ユーザ端末２にはソフトウェアがインストールされており、ビーコン発信器１０から受信したビーコン信号を通信ネットワーク３を介してレコメンドサーバ１へ送信する機能を有している。
ユーザ端末２は、携帯可能な比較的小型の情報処理端末とされており、例えば、通信機能を備えた小型のＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどが想定される。
ユーザ端末２は、レコメンドサーバ１からのレコメンド情報を受信する。

レコメンドサーバ１は、ユーザ端末２から位置情報を受信し、必要に応じてレコメンド情報を該ユーザ端末２に送信するＰＣなどの情報処理端末である。
そのために、レコメンドサーバ１は、検出部１ａと蓄積部１ｂとレコメンド部１ｃと類似判定部１ｄを備えている（図２参照）。

検出部１ａは、ユーザが店舗２００Ａなどの店舗に近接（来店）したことを検出する。店舗へ近接した状態の検出は、例えば、ユーザ端末２が受信したビーコン信号（或いはビーコン信号を受信したこと）をレコメンドサーバ１へ送信することによって行われる。
なお、近接状態の検出を連続的に行うことにより、店舗への来店及び退店を検出することができる。例えば、店舗２００Ａへの近接状態を検出していない状態から検出した状態へと変化したことによってユーザが店舗２００Ａに来店したことを検出する。また、店舗２００Ａへの近接状態を検出した状態から検出していない状態へと変化したことによってユーザが店舗２００Ａから退店したことを検出する。即ち、ユーザが所定エリア内に位置する状態から所定エリア内に位置しない状態を検出することにより、退店検出を行う。

店舗２００Ａへの来店及び退店については、ビーコン発信器１０を用いなくてもよい。例えば、ユーザが携帯するユーザ端末２がＧＰＳ（Global Positioning System）による位置情報を定期的にレコメンドサーバ１へ送信することによって実現可能である。検出部１ａは、受信した位置情報と店舗２００Ａの位置情報を比較することにより店舗２００Ａとユーザの位置関係を把握し、ユーザが店舗２００Ａに来店しているか否かを判定することができる。また、位置情報の変化を捉えることにより、ユーザが店舗２００Ａ来店したことや退店したことを把握することができる。

検出部１ａは、ユーザが店舗２００Ａで商品の購入などの行動（購買行動）を行ったことを検出する。購買行動の検出は、クレジットカードシステム７や電子マネーシステム８やポイントカードシステム９から購買情報を取得することによって行う。
なお、ユーザ自身が情報を入力することにより購買行動の検出を行ってもよい。例えば、ユーザが行った商品レビューの投稿などを取得することによって購買行動の検出を行ってもよい。

また、店舗２００Ａに複数のビーコン発信器１０，１０，・・・を設置し、ユーザ端末２が各ビーコン発信基１０，１０，・・・から受信するビーコン信号の信号強度を検知することにより店舗２００Ａ内のユーザ端末２の位置を検出してもよい。この場合には、ユーザ端末２がキャッシュレジスター付近に位置した形跡があれば購買行動があったと推定してもよい。この方法であれば、購買行動の検出にクレジットカードシステム７や電子マネーシステム８やポイントカードシステム９から情報を取得しなくてもよいため、簡易な処理によって実現可能である。そして、キャッシュレジスター付近へ移動せずに退店したユーザに対しては、確実に購買行動を行っていないユーザとして、後述するレコメンド情報を送信することが可能である。即ち、簡易なシステム構成及び処理手順で購買行動を行っていないユーザに有益な情報を提供することができる。

蓄積部１ｂは、ユーザの行動履歴情報を蓄積する処理を行う。具体的には、ユーザが店舗２００Ａに来店したことを検出して来店履歴情報を記憶する。また、ユーザが店舗２００Ａから退店したことを検出して退店履歴情報を記憶する。そして、ユーザが購買行動を行ったことを検出して購買行動履歴情報を記憶する。
それぞれの履歴情報には行動を検出した時間情報を紐付けて管理する。

レコメンド部１ｃは、ユーザ端末２に対してレコメンド情報を送信する。レコメンド情報の送信に際しては、大きく分けてレコメンド情報の抽出処理、レコメンド情報の選択処理、送信処理などを実行する。
レコメンド情報の抽出処理では、検出部１ａによってユーザが店舗２００Ａに来店したことや店舗２００Ａから退店したことが検出されたことに応じてレコメンド情報の抽出処理を行う。即ちユーザに送信すべきレコメンド情報の抽出を行う。
レコメンド情報の選択処理は、抽出処理で抽出されたレコメンド情報から実際に送信する情報を選択する処理である。
送信処理では、対象のユーザ端末２に選択されたレコメンド情報を送信する処理を行う。
各処理についての具体的な処理については後述する。

類似判定部１ｄは、ユーザ間の類似度の判定や似ているか否かの判定を行う。類似度或いは似ているか否かの判定は、例えば、ユーザごとのユーザ情報に基づいて行うか、或いは、ユーザの来店履歴のある店舗情報や購買行動履歴のある店舗情報に基づいて判定を行う。

レコメンドサーバ１は、上記した各種処理を実行するためにデータベースにアクセス可能とされている。なお、以下「データベース」については「ＤＢ（Database）」と表記する。図１及び図２ではレコメンドサーバ１がアクセス可能なＤＢとしてユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２を例示している。

ユーザＤＢ５０は、レコメンドサーバ１が提供するレコメンド情報を受け取るユーザに関する情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、年収、住所、メールアドレス、趣味などの個人的な情報が紐付けられて記憶される。
更に、本実施の形態においては、ユーザの現在地情報が記憶されていてもよい。現在地情報は、ユーザ端末２のＧＰＳ情報をユーザ端末２から受信してもよいし、店舗２００に設置されたビーコン発信基１０から受信したビーコン信号の情報をユーザ端末２から受信してもよい。

店舗ＤＢ５１は、店舗２００などの実店舗の情報が記憶される。例えば、それぞれの店舗を一意に識別可能な店舗ＩＤに対して、店舗名、ＧＰＳ情報や住所情報などの位置情報、取扱商品の商品ＩＤ、或いは取扱商品群を特定可能な商品ジャンル情報（販売ジャンル情報）、電話番号やメールアドレスなどの連絡先情報などが紐付けられて記憶される。

履歴ＤＢ５２は、ユーザの来店履歴情報や退店履歴情報や購買行動履歴情報が記憶される。これらの情報は、ユーザが来店した際や退店した際や購買行動を行った際に逐次記憶される。具体的には、図３に示すように、時系列に沿って各レコードが記憶される。各レコードは、例えば、レコードを一意に特定可能な履歴ＩＤに対して日時情報、ユーザＩＤ、行動種別、対象店舗の情報が紐付けられた構成とされている。行動種別は、当該レコードがユーザの来店に係るものであるのか、退店に係るものであるのか、或いは購買行動に係るものであるのかを示すものである。
なお、この構成はあくまで一例であり、これ以外の情報が含まれていてもよいし、一部の情報を含んでいなくてもよい。

なお、図３は、履歴ＤＢ５２に記憶される各レコードから、二人のユーザ（Ｕ０９９２１とＵ００７６４）についての各種行動履歴の一部を抜粋したものである。即ち、ユーザＡ（Ｕ０９９２１）が店舗２００Ａに来店した後何も買わずに退店し、続けて店舗２００Ｂに来店した後何らかの商品を購入して退店した履歴と、ユーザＢ（Ｕ００７６４）が店舗２００Ａに来店した後何も買わずに退店したことを示す部分が抜粋されている。

以上の各ＤＢ（ユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２）は、レコメンドサーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えばレコメンドサーバ１と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部または全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ一つのＤＢとして構成される必要もない。例えば履歴ＤＢ５２として記憶される情報が、複数のＤＢ（例えば来店及び退店に関する履歴情報を記憶するＤＢと、購買行動に関する履歴情報を記憶するＤＢなど）により記憶管理されてもよい。以上の各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。

図１に示したレコメンドサーバ１やユーザ端末２やクレジットカードシステム７や電子マネーシステム８やポイントカードシステム９などの各システムを構成する端末などの情報処理装置のハードウェア構成を図４に示す。レコメンドサーバ１やユーザ端末２やクレジットカードシステム７や電子マネーシステム８やポイントカードシステム９などの各システムを構成する端末は、情報処理および情報通信が可能な図４に示すようなコンピュータ装置によって実現される。

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

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

レコメンドサーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部または一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また各機能は複数の情報処理装置に分散されていてもよい。更に機能の一つが、複数の情報処理装置によって実現されてもよい。

＜２．各処理例＞

レコメンドサーバ１が実行する処理について、添付図を参照しながら説明する。

＜２−１．第１の実施の形態＞
第１の実施の形態では、ユーザが店舗２００に来店したことを契機としてレコメンド情報を送信する例について図５を参照して説明する。本例では、ユーザがある店舗を訪れた場合に、他のユーザが取った行動に基づいて代替となる店舗を抽出し、該店舗をレコメンド情報として提供する。
レコメンドサーバ１はステップＳ１０１で、行動情報を受信したか否かを判定する。行動情報とは、ユーザが所定の店舗２００に来店した情報や店舗２００から退店した情報や店舗２００で行った購買行動に関する情報である。このような行動情報を受信するまで、レコメンドサーバ１はステップＳ１０１で待機する。

行動情報を受信したレコメンドサーバ１は、続くステップＳ１０２で行動情報を履歴ＤＢ５２に記憶する処理を行う。これにより履歴ＤＢ５２に一つのレコードが記憶される。

レコメンドサーバ１は、ステップＳ１０３で、記憶した行動情報の行動種別が来店に関するものであるか否かを判定する。来店に関するもの以外、即ち退店に関するものや購買行動に関するものである場合、レコメンドサーバ１はステップＳ１０１の待機状態へと遷移する。
一方、記憶した行動情報が来店に関するものであった場合、レコメンドサーバ１はステップＳ１０４の処理に進む。なお、以下の各実施の形態や各例では、ユーザＢが店舗２００Ａに来店した履歴情報が記憶された場合について述べる。即ち、図３に示す履歴ＤＢ５２に履歴ＩＤ＝１７０５２９５８９１５とされたレコードが記憶されたことに応じて続くステップＳ１０４及びステップＳ１０５の処理が実行される場合について述べる。

ステップＳ１０４では、ユーザＢに提示すべきレコメンド情報を抽出する処理を実行する。続いて、レコメンドサーバ１は、ステップＳ１０５において、抽出したレコメンド情報から一部の情報を選択する選択処理を実行する。
レコメンド情報の抽出処理及び選択処理の一例について、図６及び図７を参照して説明する。

図６に示すレコメンド情報抽出処理では、レコメンドサーバ１は第１店舗へ来店し購買行動を行わずに退店したユーザをステップＳ２０１で抽出する。ここで抽出するユーザは、ユーザＢを含んでいてもよいが、基本的にはユーザＢ以外の他のユーザである。第１店舗とは、レコメンド情報の送信対象とされるユーザＢが来店した店舗であり、即ち店舗２００Ａである。店舗２００Ａに来店したユーザＢに対して、次に提示すべき代替店舗の情報をレコメンド情報として送信するためである。
具体的には、図３の履歴ＤＢ５２に示すように、店舗２００Ａに来店して購買行動を行わずに退店したユーザＡを含む１または複数のユーザ（以降「第１抽出ユーザ」と記載）が抽出される。

続いて、レコメンドサーバ１はステップＳ２０２で、第２店舗へ来店したユーザを更に抽出（選別）する。具体的には、ステップＳ２０１で抽出された第１抽出ユーザから、第２店舗へ来店したユーザを更に絞り込む処理を行う。ステップＳ２０２で更に絞り込まれたユーザを「第２抽出ユーザ」と記載する。
第２店舗とは、第１店舗（即ち店舗２００Ａ）とは異なる他店舗であり、店舗２００Ｂであってもよいし店舗２００Ｃであってもよい。
なお、第１店舗としての店舗２００Ａの退店時間から３０分などの所定時間以内に第２店舗を訪れたユーザに絞り込んでもよい。これは、第１店舗の退店から例えば２４時間後に第２店舗を訪れたユーザを抽出したとしても、第１店舗の代わりに第２店舗を訪れたと判定することが難しいためである。即ち、第１店舗の退店から第２店舗の来店までの経過時間が長いほど、第１店舗の代替店舗として第２店舗を訪れた可能性が低くなるためである。
従って、第１店舗の退店から３０分や１時間、或いは２時間などの所定時間以内に第２店舗を来店したユーザに絞り込むことによって、ユーザＢに適切なレコメンド情報を送信できる可能性を高めることができる。もちろん、第１店舗と第２店舗の位置情報を用いて所定時間を可変としてもよい。即ち、第１店舗と第２店舗が近い距離に位置している場合は、所定時間を短くし、第１店舗と第２店舗が遠い距離に位置している場合は所定時間を長くしてもよい。これにより、店舗ごとの位置情報を考慮して適切な代替店舗をユーザＢに提示できる可能性を更に高めることができる。

なお、第１店舗の退店から第２店舗の来店の間に他の店舗の来店や退店を行っていてもよい。具体的には、ユーザＡが店舗２００Ａを退店した後、店舗２００Ｃに来店したがそこでも購買行動を行わずに退店し、次に訪れた店舗２００Ｂで購買行動を行った場合、ユーザＢに提示する代替店舗は店舗２００Ａの次に訪れた店舗２００Ｃではなく購買行動を行った店舗２００Ｂである可能性が高い。また、店舗２００Ａの隣に店舗２００Ｂが位置しており、販売している商品も類似している場合には、レコメンド情報を送信しなければ店舗２００Ａを退店したユーザＢは次に店舗２００Ｂに来店する可能性が高い。
このような場合であっても、本構成によれば、購買行動を行うまでに訪れた店舗の情報ではなく、購買行動を行った店舗の情報がレコメンド情報としてユーザＢに送信されるため、ユーザＢは無駄な来店を省くことができ、時間を有効利用することができる。

第２抽出ユーザを抽出した後、レコメンドサーバ１はステップＳ２０３において、１または複数の第２店舗を抽出する。第２抽出ユーザが１または複数であるため、ここで抽出される第２店舗も１または複数となる。抽出された第２店舗を「抽出店舗」と記載する。なお、例えば３人の第２抽出ユーザに対して、第２店舗が重複することもあるため、必ずしも抽出店舗が３店になるとは限らない。

店舗を抽出したレコメンドサーバ１は、図６に示すレコメンド情報抽出処理を終了し、続いて図７に示すレコメンド情報選択処理（図５のステップＳ１０５）を実行する。
レコメンド情報選択処理において、レコメンドサーバ１はステップＳ３０１で、商品ジャンルによる選択を行う。１または複数の抽出店舗から、第１店舗としての店舗２００Ａと販売ジャンル情報が少なくとも一部重複している店舗のみを選択する。
販売ジャンル情報が第１店舗と重複していない店舗は、第１店舗の代替店舗となる可能性は低いからである。

続いて、レコメンドサーバ１はステップＳ３０２で、時間情報を用いた選択を行う。具体的に、店舗２００Ａが飲食店である場合を例に挙げて説明する。
例えば、ユーザＣが店舗２００Ａで何も購買（飲食）せずに退店し、直後に店舗２００Ｃに来店して購買行動（飲食行動）を行っていたとする。ユーザＣが店舗２００Ｃで購買行動を行ったのは１２時ごろとし、これは時間的に昼食と考えられる。
一方、ユーザＢが店舗２００Ａに来店したのは、図３に示すように午前１９時であり、時間的に昼食である可能性は低い。従って、ユーザＣの行動履歴に基づいて店舗２００Ｃを代替店舗としてユーザＢに提示することは適切でない可能性がある。
ステップＳ３０２では、このように、代替店舗候補として選択されている店舗から時間情報を用いて更に絞り込む処理を行う。従って、店舗２００Ｃは代替店舗候補から外れることとなる。

次に、レコメンドサーバ１はステップＳ３０３で店舗の利用可否による選択を行う。各店舗２００，２００，・・・には利用不可となることがある。例えば定休日である店舗や営業時間外の店舗や閉店してしまった店舗などである。また、混雑状況により利用が困難な店舗も利用不可店舗として除外してもよい。このような店舗２００をユーザに代替店舗として提示することは好ましくないため、ステップＳ３０３の選択処理によって除外する。
定休日や営業時間などの情報は、例えば店舗ＤＢ５１に記憶されている。

なお、ステップＳ３０１乃至ステップＳ３０３の各選択処理は、何れか一つのみを行ってもよいし、全ての処理を行ってもよい。また、ユーザＢに対して代替店舗の提示を１店とするならば、代替店舗が１店となった時点でその後の選択処理を行わなくてもよい。他にも、ユーザＢに対して提示する代替店舗が０店であること、即ちレコメンド情報が無いことを許容するのであれば、全ての選択処理を行い、代替店舗が０店となった時点で以降
の処理を行わずに終了してもよい。

続いて、レコメンドサーバ１はステップＳ３０４で、更なる選択処理を行うか否かを判定する。具体的には、ユーザＢに提示する予定のレコメンド情報よりも多い情報が代替店舗として残っているかどうかを判定する。
更なる選択処理を行わない場合には、ステップＳ３０５の処理を行わずに図７に示すレコメンド情報選択処理を終える。一方、更なる選択処理を行う場合には、ステップＳ３０５の処理へと進む。

ステップＳ３０５では、レコメンドサーバ１はステップＳ３０１乃至ステップＳ３０３の各選択処理の結果残っている代替店舗候補を更に絞り込む処理を行う。具体的には、購買行動が多い順に所定数の店舗を選択する。所定数とは、ユーザＢに提示するレコメンド情報としての代替店舗情報の件数である。ユーザに１件の代替店舗を提示する場合には、購買行動が多い順に１件の代替店舗を選択し、３件の代替店舗を提示する場合には、購買行動が多い順に３件の代替店舗を選択する。
なお、購買行動が多い店舗とは、第１店舗（店舗２００Ａ）の代わりに来店したユーザが多い店舗である。
また、ステップＳ３０５では、購買行動が多い店舗を選択する代わりに他の情報に基づいて選択してもよい。例えば、ユーザＢの現在値から近い店舗順であってもよいし、ユーザＢの来店履歴がない店舗を選択してもよい。

図５の説明に戻る。ステップＳ１０４のレコメンド情報抽出処理、及びステップＳ１０５のレコメンド情報選択処理を行ったレコメンドサーバ１は、ステップＳ１０６で送信タイミングが到来したか否かを判定する処理を実行する。送信タイミングが到来していない場合は、ステップＳ１０６の処理を継続的に実行する。即ち、送信タイミングが到来するまでステップＳ１０６で待機する。
送信タイミングは、ユーザにレコメンド情報を送信することが適当と考えられるときである。例えば、ユーザＢが店舗２００Ａを退店したことを検出した後である。また、本実施の形態では、ユーザの来店検出、退店検出、購買行動検出を行っているが、来店検出しか行っていない場合であっても、退店したと考えられる時間を送信タイミングとしてもよい。例えば、ユーザＢが来店した店舗２００Ａの平均的な滞在時間が１時間である場合には、ユーザＢの来店検出から１時間後を送信タイミングとしてもよい。
このような処理を行えば、ユーザの来店検出を行うだけでもユーザに適切なタイミングでレコメンド情報を送信することが可能となる。これにより、レコメンドサーバ１の処理負担の軽減や履歴ＤＢ５２の記憶領域の消費削減を果たしつつレコメンド情報の送信が可能となる。

ステップＳ１０６で送信タイミングが到来したと判定したレコメンドサーバ１は、ステップＳ１０７で送信処理を行う。この送信処理で、レコメンド情報としての代替店舗情報が送信対象とされたユーザＢに対して送信される。

なお、ステップＳ１０５のレコメンド情報選択処理において各種選択を行った結果レコメンド情報としての代替店舗が無くなった場合には、ステップＳ１０６及びステップＳ１０７の処理を行わずに図５に示す一連の処理を終了する。また、ステップＳ１０４のレコメンド情報抽出処理においてレコメンドすべき情報が抽出されない場合も同様に、ステップＳ１０６及びステップＳ１０７の処理を実行せずに終了する。
また、図７のステップＳ３０３において各店舗の混雑状況を取得した場合には、ステップＳ１０７の送信処理においてレコメンド情報を送信する際に混雑状況を合わせて送信してもよい。これにより、ユーザは混雑状況を考慮した上で代替店舗を利用するか否かを判断することができる。即ち、ユーザにとって有益な情報を提供することができる。

＜２−２．第２の実施の形態＞
第２の実施の形態では、ユーザが店舗２００から退店したことを契機としてレコメンド情報を送信する。具体的に、図８を参照して説明する。
なお、ユーザＢが第１店舗としての店舗２００Ａを来店した後に購買行動を行わずに退店した場合について説明する。
レコメンドサーバ１は、行動情報の受信有無をステップＳ１２１で判定し、受信した行動情報をステップＳ１２２で履歴ＤＢ５２に記憶する。ステップＳ１２１及びステップＳ１２２の処理は、図５のステップＳ１０１及びステップＳ１０２の処理と同様の処理であるため、詳述を省く。

レコメンドサーバ１は、ステップＳ１２３において、先の処理で記憶した行動履歴の行動種別が退店に関するものであるか否かを判定する。行動種別が退店に関するもの以外となる行動履歴を受信した場合、レコメンドサーバ１は再びステップＳ１２１の処理を実行する。
一方、行動種別が退店に関する行動履歴を受信した場合、レコメンドサーバ１はステップＳ１２４でレコメンド情報抽出処理を行い、ステップＳ１２５でレコメンド情報選択処理を実行する。

図９及び図１０を参照して、ステップＳ１２４のレコメンド情報抽出処理とステップＳ１２５のレコメンド情報選択処理を説明する。
本実施の形態では、ユーザの退店を契機としてレコメンド情報を送信するため、退店した店舗とは異なる他店舗の情報を送信する以外にも退店したばかりの店舗に関する情報を送信することが考えられる。
ここでは、退店したばかりの店舗に関する情報をレコメンド情報として送信する例を説明する。

レコメンドサーバ１は、レコメンド情報抽出処理として、図９のステップＳ２２１の処理を実行する。ステップＳ２２１では、ユーザＢが退店した店舗２００Ａに関するレコメンド情報の抽出を行う。
店舗２００Ａに関する情報としては、例えば、店舗２００Ａで人気の商品情報や売れ行きが急上昇している商品、或いはユーザＢの興味のある商品などである。

続いて、レコメンドサーバ１は図１０のステップＳ３２１以降の各処理を行うことにより、抽出された情報からレコメンド情報を選択する。
先ず、ステップＳ３２１では、ユーザの興味や嗜好情報に基づいた選択を行う。ユーザの興味や嗜好の情報は、例えばユーザＤＢ５０に記憶されている。これらの情報は、ユーザに直接入力された情報であってもよいし、ユーザの購買行動履歴から抽出した推定情報であってもよいし、ユーザが来店した店舗情報から抽出した推定情報であってもよい。

次に、レコメンドサーバ１はステップＳ３２２で、ユーザの移動経路に基づいて選択する処理を実行する。例えば、店舗２００Ａに複数のビーコン発信器１０，１０，・・・が設置されている場合に、店舗２００ＡにおけるユーザＢの移動経路が把握できる。このような情報を用いて、ユーザが立ち寄ったコーナー及び立ち寄っていないコーナーなどを把握し、立ち寄っていないコーナーで販売されている商品に関する商品情報を選択することが考えられる。ステップＳ３２１及びステップＳ３２２の双方の選択処理を実行することにより、ユーザＢが気がつかなかった虞のある興味のある商品がレコメンド情報として選択される。具体的には、店舗２００Ａが書店であり、ユーザＢの好きな作家の作品が通常の場所から特設コーナーなどに一時的に移転されていた場合には、ユーザＢが気がつかずに店舗２００Ａを退店した可能性がある。このようなケースを店舗２００Ａ内におけるユーザＢの移動経路を把握することにより推定し、適切なレコメンド情報を選択する。
なお、店舗内における商品の位置については、例えば店舗ＤＢ５１に記憶されていてもよい。また、各商品が置かれている位置を把握せずに、各ユーザの移動経路及び嗜好情報から各コーナーにどのような属性のユーザが訪れやすいかを蓄積した情報を利用してもよい。

レコメンドサーバ１はステップＳ３２３で選択処理の要否を判定し、続くステップＳ３２４で更なる選択処理を行う。ステップＳ３２３及びステップＳ３２４の処理は、前述したステップＳ３０４及びステップＳ３０５の処理と同様であるため、詳述を省く。
図８の説明に戻る。レコメンド情報の抽出及び選択を行ったレコメンドサーバ１は、ステップＳ１２６で送信処理を実行する。

＜２−３．レコメンド情報抽出処理の別例＞
図８のステップＳ１２４のレコメンド情報抽出処理の別例について、図１１を参照して説明する。
レコメンド情報抽出処理の別例では、第１店舗へ来店したが購買行動を行わずに退店し、且つ、第２店舗へ来店して購買行動を行ったユーザを単に抽出するのではなく、それらのユーザの中からレコメンド情報の送信対象のユーザと類似しているユーザを抽出する例について説明する。
先ず、レコメンドサーバ１はステップＳ２４１において、類似ユーザの抽出を行う。類似ユーザとは、例えば、来店履歴のある店舗が類似しているユーザや、購買行動のある店舗が類似しているユーザや、家族構成が類似しているユーザや、住所情報が類似しているユーザ（住所が近いユーザ）などである。

続いて、レコメンドサーバ１はステップＳ２４２及びステップＳ２４３において、それらの類似ユーザの中から第１抽出ユーザや第２抽出ユーザを抽出する処理を行う。ステップＳ２４２の処理は前述の図６のステップＳ２０１と同様の処理であり、ステップＳ２４３の処理は前述の図６のステップＳ２０２と同様の処理であるため、詳述は省略する。

最後に、レコメンドサーバ１はステップＳ２４４において、１または複数の第２店舗を抽出する。この処理は、図６のステップＳ２０３の処理と同様の処理である。
なお、この処理は、図８のステップＳ１２４の処理の一例として説明したが、図５のステップＳ１０４のレコメンド情報抽出処理の一例として実行してもよい。即ち、ユーザＢが店舗２００Ａに来店したことに応じて行うレコメンド情報抽出処理として、図１１の処理を行ってもよい。

＜２−４．レコメンド情報選択処理の別例＞
図８のステップＳ１２５のレコメンド情報選択処理の別例について、図１２を参照して説明する。
レコメンド情報選択処理の別例では、天候情報を加味してレコメンド情報の選択を行う。
本例では、ユーザＢが店舗２００Ａを退店したことを契機として図８のステップＳ１２４などのレコメンド情報抽出処理が実行され、その後に図１２に示す一連の処理が実行される。

天候情報を用いたレコメンド情報選択処理では、レコメンドサーバ１はステップＳ３４１において、第１店舗としての店舗２００Ａの住所情報を店舗ＤＢ５１から取得する。
続いて、レコメンドサーバ１はステップＳ３４２において、店舗２００Ａの現在の天候情報を取得する。天候情報は、通信ネットワーク３を介して天気情報を配信しているウェブサイト等から取得する。また、天候情報とは、例えば、気温情報、晴れや雨などの天気情報、風速情報などである。

レコメンドサーバ１はステップＳ３４３において、既に抽出されている１または複数の店舗から天候情報に応じた店舗選択を行う。例えば、天気情報が雨であれば、ユーザＢの現在地、即ち店舗２００Ａから屋外を通らずに地下通路や屋根のあるアーケード街のみを移動して到着可能な店舗を優先的に選択する。また、同一建物内にある店舗を優先的に選択してもよい。このとき、店舗の混雑状況を更に考慮してもよい。例えば、店舗が混雑しており待たされることが分かっている場合には、屋根のある待機スペースがある店舗を選択してもよい。

外気温が低く店舗が混雑していることが分かった場合には、室内で待機可能な店舗を選択してもよい。他にも、花粉情報や紫外線情報に基づいて店舗を選択してもよい。そして、これらの情報を用いるか否かはユーザＢのユーザ情報に基づくことが望ましい。例えば、花粉症を患っているユーザであるか否かにより、花粉症情報を用いた選択処理を行うか否かを決定する。

外気温が低く店舗が混雑しているが、風が無い場合には、陽光の下で待機可能な店舗を選択してもよい。
なお、気温が穏やかで晴天や曇りなどの場合には、天候情報に応じた選択を行わなくてもよい。その場合には、例えば、図７や図１０などのレコメンド情報選択処理を代わりに実行してもよい。なお、図１０のステップＳ３２１の興味・嗜好情報に基づく選択は、先述した例では商品情報を選択したが、ここでは店舗情報を選択する処理となる。ステップＳ３２２の移動経路に基づく選択処理では、ユーザが立ち寄っていないコーナーの情報を見逃したと推定して選択する例を説明したが、ここではユーザが立ち寄ったコーナーの情報を取得し、立ち寄ったコーナーからユーザの探している商品情報を推定し、当該推定した情報に基づいて店舗選択を行う。

続いて、レコメンドサーバ１はステップＳ３４４で更なる選択処理の要否を判定し、ステップＳ３４５で購買行動が多い順に店舗を選択する処理を行う。これらの処理は、図７のステップＳ３０４及びステップＳ３０５の処理と同様であるため、詳述を省く。
本例で説明した天候情報に基づく選択処理を行うために、店舗ＤＢ５１に天候情報に関する情報が記憶されていてもよい。例えば、店舗ごとに待機場所が雨天の場合に適切か否かなどの情報が記憶されている。また、履歴ＤＢ５２に天候情報に関する情報が記憶されていてもよい。例えば、来店に係るレコードに当時の天候が記憶されていてもよい。他店舗と比較して雨天の際の来店履歴情報が少なく晴天の際の来店履歴情報が多い場合には、雨天時のレコメンド情報として提示する店舗としては不適切である可能性が高いため、レコメンド情報選択処理で選択しないことなどが考えられる。

＜２−５．レコメンド情報抽出処理の別例２＞
レコメンド情報抽出処理では、上述したように、例えば、ユーザＢが店舗２００Ａへ来店したことや店舗２００Ａから退店したことを契機にユーザＢ以外の行動履歴に基づいて店舗２００Ａ以外の店舗についてのレコメンド情報をユーザＢに提示する。このとき、例えばユーザＡが店舗２００Ａの後に店舗２００Ｂに来店して購買行動を行った場合、店舗２００ＢがユーザＢに対して提示する代替店舗の候補となる。

レコメンド情報抽出処理の別例２では、ユーザＡが店舗２００Ｂをどのようにして選択して来店したかを考慮する。具体的には、ユーザＡが検索操作に基づいて店舗２００Ｂを選択したか否かを考慮する。
ユーザＡが店舗２００Ａを来店し、購買行動を行わずに退店した後に検索操作を行って店舗２００Ｂに関する情報を得ていた場合、店舗２００Ａ以外の代替店舗を見つけるための検索操作を行った可能性が高いと考えられる。そのようにして情報が得られた店舗２００Ｂは、ユーザＡにとって店舗２００Ａの代替店舗である可能性が高い。即ち、ユーザＢにとっても店舗２００Ｂは店舗２００Ａの代替店舗である可能性が高い。具体的に図１３を参照して説明する。

レコメンドサーバ１はステップＳ２６１で、第１店舗としての店舗２００Ａへ来店し購買行動を行わずに退店したユーザを抽出する。
続いて、レコメンドサーバ１はステップＳ２６２で、検索操作の結果として得られた第２店舗へ来店したユーザを絞り込む。検索操作の有無については、ユーザ端末２からレコメンドサーバ１へ送信されて、ＤＢに記憶される。例えば、履歴ＤＢ５２に記憶された各レコードのうち、来店に関するレコードについては、検索操作を伴ったものであるか否かが記憶される。

レコメンドサーバ１はステップＳ２６３で、第２店舗の抽出を行う。これにより、ユーザが第１店舗を訪れた後に検索操作を行って来店した第２店舗の情報が抽出される。
なお、その後にレコメンドサーバ１が実行するレコメンド情報選択処理については、図７に示す処理であってもよいし、図１０に示す処理であってもよいし、図１２に示す処理であってもよい。このとき、図１０に示すステップＳ３２１やステップＳ３２２の処理は、レコメンド情報選択処理の別例で説明したような処理内容となる。

＜３．変形例＞

上記した図７や図１０や図１２に示すレコメンド情報選択処理では、その前に実行したレコメンド情報抽出処理によって抽出された各店舗の情報や商品に関する情報から所定数の情報をランダムに選択してもよい。これにより、レコメンド情報が偏ることを防止することができるため、多用なレコメンド情報を提供することができる。

ユーザの購買行動を把握するためにＰＯＳ（Point Of Sale）システムと連携してもよい。これにより、確実に購買行動の把握を行うことができる。
また、購買行動は、商品の取り寄せの依頼や購入予約や発送依頼などを含んでもよい。即ち、店舗２００で代金を支払い購入商品を受け取る行動に限らず、商品を店舗で受け取るが代金の支払いは後日となる場合や、商品を後日発送してもらうが代金は先に支払う場合なども含む。

上述した各例は、履歴ＤＢ５２にユーザＩＤ情報が記憶されるように、レコメンドサーバ１が提供するレコメンド情報提供サービスにログインしている状態で各種の処理が行われる例を示しているが、ログインを必ずしも要するわけではない。例えば、店舗２００への来店行動や退店行動や購買行動を把握した段階でレコメンドサーバ１がユーザに数時間や１日間有効な仮ＩＤを発行してもよい。
レコメンドサーバ１が提供するレコメンド情報は、退店したばかりの店舗２００に関するレコメンド情報や、退店した店舗２００の代替店舗のレコメンド情報を送信するものである。従って、店舗２００Ａを退店したユーザＡが１週間後に店舗２００Ｂにて購買行動を行ったからといって、店舗２００Ｂを店舗２００Ａの代替店舗として推定することは不適切である可能性が高い。即ち、店舗２００Ａ及び店舗２００Ｂに対して１週間に亘って行われた各行動が同一人物によるものであるのかどうかを把握することは必須ではない。
従って、数時間などのある程度短い時間の間において行われた来店行動や退店行動や購買行動が同一人物によるものであることを把握できればよいため、短期間有効な仮ＩＤによって各ユーザの行動を把握することでも十分効果を得ることが可能である。

上記した各処理の組合せはあくまで一態様である。従って、それぞれの処理をいかように組み合わせたとしても各種の効果を得ることができる。例えば、レコメンド情報選択処理として、図７のステップＳ３０１、Ｓ３０２、Ｓ３０３の各選択処理の後に図１０のステップＳ３２１、Ｓ３２２の各選択処理を実行してもよい。また、異なる例のレコメンド情報抽出処理とレコメンド情報選択処理を組み合わせてもよい。

なお、上記の各例ではレコメンド情報として実際の店舗情報を送信する例を説明したが、ネットワーク上に展開される仮想ショッピングモールや仮想店舗を代替店舗として提示してもよい。仮想ショッピングモールや仮想店舗への来店は、ネットワーク上に展開されている店舗のウェブページの閲覧を開始したことをもって来店として扱うことができる。また、当該ウェブページの閲覧を停止したことをもって退店として扱うことができる。そして、退店に応じてユーザに提示される代替店舗は、仮想ショッピングモールに属する別の仮想店舗であってもよいし、ネットワーク上ではない実際の店舗であってもよい。
具体的には、ユーザＡが実際の店舗２００Ａに来店したが購買行動を取らずに、続けて店舗２００Ｂに来店して購買行動を行った場合に、レコメンドサーバ１はその一連の履歴情報を蓄積する。続いて、Ａさんに類似した類似ユーザであるユーザＢが仮想ショッピングモールに出店されている店舗２００Ａの仮想店舗２００Ａ’に来店（ウェブページの閲覧開始）し、その後退店（ウェブページの閲覧終了）した場合に、Ｂさんに対して店舗２００Ｂについてのレコメンド情報を送信する。このとき、Ｂさんに送信するレコメンド情報としては、実際の店舗２００Ｂに関する情報であってもよいし、店舗２００Ｂの仮想店舗２００Ｂ’に関する情報であってもよい。勿論、店舗２００Ｂ、店舗２００Ｂ’双方の情報を送信してもよい。

＜４．まとめ＞

上記の各例で説明したように、レコメンドサーバ１は、ユーザが携帯する情報端末（ユーザ端末２）が店舗２００に近接したことを検出する近接検出部（検出部１ａ）と、ユーザが店舗２００において購買行動を行ったことを検出する購買行動検出部（検出部１ａ）と、ユーザの店舗２００への来店と購買行動に関する履歴情報を蓄積する蓄積部１ｂと、一人のユーザの履歴情報から第１店舗の来店履歴情報の検出と第１店舗の購買行動履歴情報の非検出と第１店舗に関する履歴情報の後に蓄積された第２店舗の来店履歴情報及び購買行動履歴情報の検出が行われた場合に、第１店舗への近接が検出されたユーザの情報端末に対して第２店舗に関するレコメンド情報を送信するレコメンド部１ｃと、を備えている。
これにより、実際の店舗に関する他のユーザの来店履歴情報及び購買行動履歴情報に基づいてユーザが来店した店舗の代替となる店舗の情報がユーザに提供される。
従って、例えば飲食店であれば、第１店舗で食事をすることができなかったユーザに対して、第１店舗の代わりに他ユーザが食事を行った第２店舗が存在する場合に該第２店舗が代替店舗としてレコメンドされる。
勿論、第１店舗や第２店舗は飲食店に限定されず、文房具などの商品を扱う店舗であってもよい。例えば、第１店舗で購入したい文具がなかった場合に、代替店舗となり得る第２店舗としての文具店がレコメンドされる。
また、第１店舗への近接が検出されたユーザに対してレコメンドする第２店舗は、該ユーザの位置からあまり遠い場所に位置するものは不適切となる可能性が高い。本構成によれば、実際に第１店舗へ来店した他ユーザがその後訪れて購買行動を取った店舗が代替店舗としてユーザにレコメンドされるため、第１店舗付近にいる該ユーザに対して適切なレコメンドとなる可能性を高めることができる。
更に、不要な情報の送受信が抑制されることにより、レコメンドサーバ１の処理負担軽減及びユーザが所持するユーザ端末２の処理負担軽減が図られる。また、適切な情報が提供されることにより、改めて検索するなどのユーザの負担を軽減すると共に、検索の際のユーザ端末２の処理負担の発生を抑制する。

レコメンド情報抽出処理の別例（図１１）で説明したように、ユーザ間の類似を判定する類似判定部１ｄを備え、レコメンド部１ｃは、送信対象とされたユーザと類似すると判定された類似ユーザの履歴情報に基づいて送信を行ってもよい。
これにより、第１店舗への近接が検出されたユーザとレコメンド情報の抽出元となったユーザの類似度合いが判定される。
従って、レコメンド情報の送信対象（送信先）とされたユーザにとって適切な代替店舗が第２店舗としてレコメンドされる可能性を高めることができる。

検出部１ａの説明で記載したように、近接検出部（検出部１ａ）は、近距離無線通信（例えばビーコン信号を用いた通信）を用いて店舗２００に近接したことを検出してもよい。
これにより、店舗２００への近接を検出するために例えばＧＰＳ機能などをユーザが携帯するユーザ端末２上で起動しておく必要がない。
近距離無線通信は比較的低消費電力で通信可能なものが多い。特に、ＧＰＳ機能を常に起動しておくよりも低消費電力である。従って、ユーザが携帯するユーザ端末２のバッテリ消費を押さえることができるため、ユーザの利便性の向上を図ることができる。

第２の実施の形態などで説明したように、レコメンド部１ｃは、送信対象とされたユーザが第１店舗を退店したことを検出した後にレコメンド情報の送信を行ってもよい。
これにより、ユーザが第１店舗に来店しただけではレコメンド情報として代替店舗が提示されない。
具体的には、ユーザが第１店舗へ来店したが購買行動をせずに退店した場合について、代替店舗となる第２店舗がレコメンド情報として提供される。これにより、第１店舗で購買行動を行う予定のユーザであって代替店舗のレコメンドが不要なユーザに対してレコメンド情報を送信してしまうことを防止することができる。

検出部１ａの説明で記載したように、購買行動の検出は、電子マネーの利用、クレジットカードの利用またはポイントカードの利用に基づいて行ってもよい。
電子マネーやクレジットカードやポイントカードの利用では電子データを扱うことが多く、これによって購買行動の検出を行いやすくすることができる。
従って、ＧＰＳや近距離無線通信を用いて行う来店検出や退店検出などと共に、購買行動検出を確実に行うことができるため、無用なレコメンド情報の送信などを防止することができる。

第１の実施の形態で説明したように、レコメンド部１ｃは、第２店舗が利用不可である場合には該第２店舗に関するレコメンド情報の送信を行わなくてもよい。
利用不可である店舗をレコメンドすることは、通知を受け取ったユーザにとって不利益となりかねない。
従って、そのような第２店舗のレコメンドを行わないことで、ユーザの利便性の向上を図ることができる。

第１の実施の形態（図７）で説明したように、レコメンド部１ｃは、複数の第２店舗が複数のユーザの履歴情報から抽出された場合において、抽出された第２店舗のうち該複数のユーザの購買行動履歴情報が多い店舗をレコメンド情報として送信してもよい。
第１店舗で購買行動が検出されなかったユーザが最も多く訪れ且つ購買行動を行った次の店舗が第２店舗としてユーザにレコメンドされる。
従って、ユーザの目的に適合した店舗が第２店舗としてレコメンドされ、ユーザにとって有益な情報を提供することができる可能性を高めることができる。

第１の実施の形態（図７）で説明したように、蓄積部１ｂは、ユーザが行動を起こした時間情報を紐付けた履歴情報を蓄積し、レコメンド部１ｃは、時間情報を用いてレコメンド情報の送信を行ってもよい。
即ち、ユーザが第１店舗へ来店したことを検出した時間と、他のユーザが第１店舗の次に来店した第２店舗で購買行動を起こした時間を考慮してレコメンド情報が送信される。
例えば、ランチの時間に提示すべき代替店舗としての第２店舗とディナーの時間に提示すべき代替店舗としての第２店舗は異なることが考えられる。本構成によれば、時間情報を考慮して第２店舗が抽出されてレコメンド情報として送信されるため、適切なレコメンドがなされる可能性をより高めることができる。

レコメンド情報選択処理の別例（図１２）で説明したように、レコメンド部１ｃは、送信対象とされたユーザの位置に関する気象情報を用いてレコメンド情報の送信を行ってもよい。
例えば、レコメンド情報として送信する第２店舗が混雑しており待ち時間が発生する可能性がある場合に、待ち時間を適切な状態で過ごすことができるかどうかなどを加味して第２店舗の選択を行うことができる。
従って、具体的には、雨の日や気温の低い日に外で待機しなくてはならない店舗を第２店舗の候補から除外することができ、ユーザにとって満足度の高い情報を提供することができる。他にも、雨の日に雨風にさらされずに移動できる移動経路が確保できる店舗を優先的に第２店舗の候補として抽出することなども可能となる。

第２の実施の形態で説明したように、ユーザが店舗２００から退店したことを検出する検出部１ａと、店舗２００の情報に基づくレコメンド情報を退店が検出されたユーザに送信するレコメンド部１ｃと、を備えている。
これにより、レコメンド情報の送付対象となるユーザを退店したことを検出したユーザに絞り込んだ上でレコメンド情報の送信が行われる。
従って、来店しただけでレコメンド情報の送信が行われる場合と比較して、無駄な情報送信を抑制することができ、ユーザの利便性及び満足度の向上を図ることができる。
また、不要な情報の送受信が抑制されることにより、サーバの処理負担軽減及びユーザが所持する情報端末の処理負担軽減が図られる。

検出部１ａの説明で記載したように、検出部１ａは、店舗２００でユーザが購買行動を行ったことを検出してもよい。
ユーザが購買行動を行ったか否かに応じてレコメンド情報の要否や選別が行われる。
従って、ユーザにとって有益な情報がレコメンド情報として送信される可能性を高めることができる。

検出部１ａの説明で記載したように、検出部１ａは、ユーザが所定エリア内に位置することを検出した状態から検出されない状態へと変化することによって退店したことを検出してもよい。
これにより、来店を検出する手法を用いて退店の検出が行われる。
即ち、退店検出のための専用の装置を店舗に設置することなどが不要となり、コスト削減に寄与することができる。

検出部１ａの説明で記載したように、検出部１ａは、近距離無線通信を用いて店舗２００から退店したことを検出してもよい。
これにより、店舗２００からの退店を検出するために例えばＧＰＳ機能などをユーザが携帯するユーザ端末２上で起動しておく必要がない。
近距離無線通信は比較的低消費電力で通信可能なものが多い。特に、ＧＰＳ機能を常に起動しておくよりも低消費電力である。従って、ユーザが携帯するユーザ端末２のバッテリ消費を押さえることができるため、ユーザの利便性の向上を図ることができる。

第２の実施の形態（図９や図１０）で説明したように、レコメンド部１ｃは、退店が検出された店舗２００における購買行動が検出されなかった場合にレコメンド情報として退店が検出された店舗２００に関する情報を送信してもよい。
ユーザが来店した店舗はユーザの興味関心に合致する店舗である可能性が高い。そのような店舗についてのレコメンド情報がユーザに送信される。
例えば、ユーザが書店に来店し購買行動を行わずに退店した場合に、ユーザが立ち寄っていないコーナーに関する有益な情報をレコメンド情報として送信することが考えられる。この場合には、ユーザにとって既知の情報がレコメンド情報として送信される可能性は低くなり、有益な情報が提供される可能性を高めることができる。

第１の実施形態などで説明したように、レコメンド部１ｃは、退店が検出された店舗２００における購買行動が検出されなかった場合にレコメンド情報として退店が検出された店舗２００とは異なる代替店舗に関する情報を送信してもよい。
来店したにも関わらず購買行動が検出されなかった店舗２００は、ユーザが目的が果たせなかった可能性が高い。そのような店舗２００の代替店舗がユーザに提示される。
ユーザが訪れた店舗２００に基づいて代替店舗がレコメンドされることにより、ユーザが次に訪れるべき店舗を検索する手間が省けるため、利便性の高い情報を提供することができる。

第１の実施の形態で説明したように、レコメンド部１ｃは、代替店舗が利用不可である場合には該代替店舗に関するレコメンド情報の送信を行わなくてもよい。
利用不可である店舗２００をレコメンドすることは、通知を受け取ったユーザにとって不利益となりかねない。
従って、そのような代替店舗のレコメンドを行わないことで、ユーザの利便性の向上を図ることができる。

第１の実施の形態（図７）で説明したように、レコメンド部１ｃは、複数の代替店舗が抽出された場合には、購買行動が多く検出された店舗２００をレコメンド情報として送信してもよい。
多くの購買行動が検出された店舗２００は、多くのユーザにとって適切な店舗である可能性が高い。そのような店舗２００が代替店舗として購買行動が検出されなかったユーザに対してレコメンドされる。
従って、ユーザの目的に適合した店舗が代替店舗としてレコメンドされ、ユーザにとって有益な情報を提供することができる可能性を高めることができる。

第１の実施の形態（図７）で説明したように、レコメンド部１ｃは、ユーザが行動を起こした時間情報を用いてレコメンド情報の送信を行ってもよい。
即ち、ユーザが店舗２００へ来店したことを検出した時間と、他のユーザによる代替店舗での購買行動を検出した時間を考慮してレコメンド情報としての代替店舗が送信される。
例えば、ランチの時間に提示すべき代替店舗とディナーの時間に提示すべき代替店舗は異なることが考えられる。本構成によれば、時間情報を考慮して代替店舗が抽出されてレコメンド情報として送信されるため、適切なレコメンドがなされる可能性をより高めることができる。

レコメンド情報選択処理の別例（図１２）で説明したように、レコメンド部１ｃは、送信対象とされたユーザの位置に関する気象情報を用いてレコメンド情報の送信を行ってもよい。
例えば、レコメンド情報として送信する代替店舗が混雑しており待ち時間が発生する可能性がある場合に、待ち時間を適切な状態で過ごすことができるかどうかなどを加味して代替店舗の選択及び提示を行うことができる。
従って、具体的には、雨の日や気温の低い日に外で待機しなくてはならない店舗を代替店舗の候補から除外することができ、ユーザにとって満足度の高い情報を提供することができる。他にも、雨の日に雨風にさらされずに移動できる移動経路が確保できる店舗を優先的に代替店舗の候補として抽出することなども可能となる。

＜５．プログラム及び記憶媒体＞

実施の形態のプログラムは、レコメンドサーバ１の演算処理装置（ＣＰＵ等）に各種の処理を実行させるプログラムである。

実施の形態のプログラムは、ユーザが店舗から退店したことを検出する検出機能を演算処理装置に実行させる。
また、店舗の情報に基づくレコメンド情報を退店が検出されたユーザに送信するレコメンド機能を演算処理装置に実行させる。
即ちこのプログラムは、情報処理装置の演算処理装置に対して図５乃至図１３に示す各処理を実行させるプログラムである。

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

１ レコメンドサーバ、１ａ 検出部、１ｂ 蓄積部、１ｃ レコメンド部、１ｄ 類似判定部、２ ユーザ端末、３ 通信ネットワーク、４ クレジットカード端末、５ 電子マネー端末、６ ポイントカード端末、７ クレジットカードシステム、８ 電子マネーシステム、９ ポイントカードシステム、１０ ビーコン発信器、５０ ユーザＤＢ、５１ 店舗ＤＢ、５２ 履歴ＤＢ、２００，２００Ａ，２００Ｂ，２００Ｃ 店舗

Claims (9)

1. 店舗におけるユーザの支払いの有無及び店舗からの退店を検出する検出部と、
   退店が検出された店舗における前記支払いが検出されなかった場合に当該退店が検出されたユーザのユーザ端末に当該退店が検出された店舗とは異なる代替店舗に関する情報をレコメンド情報として送信するレコメンド部と、を備え、
   前記代替店舗は前記退店が検出された店舗と同種の商品またはサービスを提供する店舗とされた
   情報処理装置。
2. 前記レコメンド部は、前記代替店舗が利用不可である場合には該代替店舗に関する前記レコメンド情報の送信を行わない
   請求項１に記載の情報処理装置。
3. 前記レコメンド部は、複数の代替店舗が抽出された場合には、前記支払いを行ったユーザが多く検出された店舗を前記レコメンド情報として送信する
   請求項１に記載の情報処理装置。
4. 前記レコメンド部は、ユーザが支払いを行った時間情報を用いて前記レコメンド情報の送信を行う
   請求項１に記載の情報処理装置。
5. 前記レコメンド部は、送信対象とされたユーザの位置に関する気象情報を用いて前記レコメンド情報の送信を行う
   請求項１に記載の情報処理装置。
6. 前記検出部は、ユーザが所定エリア内に位置することを検出した状態から検出されない状態へと変化することによって退店したことを検出する
   請求項１に記載の情報処理装置。
7. 前記検出部は、近距離無線通信を用いて店舗から退店したことを検出する
   請求項１に記載の情報処理装置。
8. 店舗におけるユーザの支払いの有無を検出するステップと、
   ユーザが店舗から退店したことを検出するステップと、
   退店が検出された店舗における前記支払いが検出されなかった場合に当該退店が検出されたユーザのユーザ端末に当該退店が検出された店舗とは異なる代替店舗に関する情報をレコメンド情報として送信するレコメンドステップと、を備え、
   前記代替店舗は前記退店が検出された店舗と同種の商品またはサービスを提供する店舗とされた
   情報処理装置が実行する情報処理方法。
9. 店舗におけるユーザの支払いの有無を検出する機能と、
   ユーザが店舗から退店したことを検出する機能と、
   退店が検出された店舗における前記支払いが検出されなかった場合に当該退店が検出されたユーザのユーザ端末に当該退店が検出された店舗とは異なる代替店舗に関する情報をレコメンド情報として送信するレコメンド機能と、を備え、
   前記代替店舗は前記退店が検出された店舗と同種の商品またはサービスを提供する店舗とされた
   コンピュータに実行させるプログラム。

Images