(57)【要約】【課題】  ユーザの希望などに応じて他の特定のユーザに対して各種依頼を適切なタイミングで出すことができるようにする。【解決手段】  本発明に係る位置情報処理方法は、ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出するステップと、ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、第１のユーザの位置情報（例えば第１のユーザの現在位置又は第１のユーザの予定位置）が、抽出された第２のユーザに係る、上記位置に関わる通知条件を満たしているか判断する判断ステップと、第１のユーザの位置情報が上記位置に関わる通知条件を満たしていると判断された場合には、第２のユーザに対して第１のユーザの情報を含む通知を行う通知ステップとを含む。【選択図】  図１
2005215725.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出するステップと、
ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、前記第１のユーザの位置情報が、抽出された前記第２のユーザに係る、前記位置に関わる通知条件を満たしているか判断する判断ステップと、
前記第１のユーザの位置情報が前記位置に関わる通知条件を満たしていると判断された場合には、前記第２のユーザに対して前記第１のユーザの情報を含む通知を行う通知ステップと、
を含み、コンピュータにより実行される位置情報処理方法。
【請求項２】
前記位置に関わる通知条件が、前記第２のユーザにより設定された位置に関わる条件と前記第２のユーザの購買履歴に基づき自動的に抽出された位置に関わる条件との少なくともいずれかを含む請求項１記載の位置情報処理方法。
【請求項３】
前記位置に関わる通知条件が、店舗識別情報と商品情報とのうち少なくともいずれかを含む請求項１又は２記載の位置情報処理方法。
【請求項４】
前記判断ステップが、
店舗の位置情報及び販売商品情報を含む店舗情報を格納する店舗情報格納部を参照して、前記第１のユーザの位置情報に基づき該当する店舗情報を抽出するステップと、
抽出された前記店舗情報が、前記通知条件格納部に格納された、前記第２のユーザに係る前記位置に関わる通知条件に含まれる前記店舗識別情報と前記商品情報との少なくともいずれかに合致するか判断する第２判断ステップと、
を含む、請求項３のいずれか１つ記載の位置情報処理方法。
【請求項５】
ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出する手段と、
ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、前記第１のユーザの位置情報が、抽出された前記第２のユーザに係る、前記位置に関わる通知条件を満たしているか判断する判断手段と、
前記第１のユーザの位置情報が前記位置に関わる通知条件を満たしていると判断された場合には、前記第２のユーザに対して前記第１のユーザの情報を含む通知を行う通知手段と、
を有する位置情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、位置情報処理技術に関する。
【背景技術】
【０００２】
近年ＧＰＳ（Global Positioning System）機能付携帯電話機や個人用の携帯ＧＰＳ端末の登場により、自分がどこにいるかということを比較的容易に把握できるようになった。また、ＧＰＳなどの技術を用いて特定の人間や物体の現在位置を知ることもできるようになっている。
【０００３】
また例えば特開２００１−１７５７１８号公報には以下のような技術が開示されている。すなわち、複数の利用者が、利用者自身の属性と、他者の属性に対する条件とを含む紹介に必要な情報をサーバに登録し、利用者端末を携帯し、利用者端末が利用者端末の位置情報を無線通信網を介してサーバに送信し、サーバが、利用者が登録した情報と、利用者端末から受信した位置情報と、過去の紹介処理の実行の有無の判断履歴とに基づいて、利用者同士の組の紹介処理の実行の有無を判断し、紹介処理の実行の対象となる組の利用者の利用者端末に対して、無線通信網を介して紹介に必要な情報を通知する。これにより、利用者に、プロファイルがマッチし、自分の近傍に存在する他者、又はその条件に過去の条件検索の結果履歴を加えた条件を満たした他者を紹介することができる。
【０００４】
さらに例えば特開２００２−５８０５４号公報には以下のような技術が開示されている。すなわち、通信事業者Ｙのネットワーク内に設定される携帯通信端末の位置情報を利用して、現にユーザが存在するセルＣ１と同一のエリア内に、ユーザが登録した第三者の電話番号の携帯通信端末Ｐ、Ｑ、Ｒに関する存否を判定して、ユーザに返答するものである。これにより、特定の者がユーザの近隣にいることを容易に、直ちに知ることができる。
【０００５】
さらに例えば特開平９−２６４９４３号公報には以下のような技術が開示されている。すなわち、歩行者、走行中の車、列車等の移動体からの現在位置情報等は、基地局アンテナから電話局を経て、管理センタに移動体の個別識別シリアルナンバ（電話番号）を基に整理（記憶）され、第三者（例えば電話加入者あるいはパソコン端末）からは加入電話線路と電話局を経て、シリアルナンバ（電話番号）を基に自由に移動体の現在位置その他の情報をアクセスできる。これにより、移動体からの位置情報等をどこからでもいつでも自由にアクセスできるようになる。
【０００６】
さらに例えば特開平１１−６４００７号公報には以下のような技術が開示されている。すなわち、衛星からの信号を受信するＧＰＳアンテナ装置とＧＰＳ受信解析装置及び表示装置とからなるＧＰＳ装置であって、携帯電話機やペイジャーやＰＨＳ（Personal Handy phone System）により通信回線からの遠隔操作が可能なＧＰＳアンテナ装置と、受信信号の転送送信装置とを搭載し、離れた場所にあるコントロールセンターに於いてＧＰＳアンテナで受信した信号を、受信解析装置で解析した信号により現在位置を表示する表示装置を設置したものである。これにより、装置を携帯する者の現在位置を第三者が探索し、または本人が連絡できる装置であって、携帯電話にＧＰＳアンテナ装置を装着し、コントロールセンターで受信信号を解析して表示装置に表示することができる。
【特許文献１】特開２００１−１７５７１８号公報
【特許文献２】特開２００２−５８０５４号公報
【特許文献３】特開平９−２６４９４３号公報
【特許文献４】特開平１１−６４００７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
このように従来技術は、自分の近隣にいる特定の者を知ることができるというものであったり、特定の者の位置情報を知ることができるというものである。しかしながら、通常のユーザは、特定の者の位置情報を常に監視していられるわけではない。また、特定の者の行動予定を常に把握しているわけではない。また、例えば、今あそこの店又は店の近所にいればあれを買ってきてほしいとか、明日あそこの店又は店の近所に行くのならばあれを買ってきてほしいといった要求を満たすような技術は何ら開示されていない。
【０００８】
従って本発明の目的は、ユーザの希望などに応じて他の特定のユーザに対して各種依頼を適切なタイミングで出すことができるようにするための位置情報処理方法を提供することである。
【課題を解決するための手段】
【０００９】
本発明に係る位置情報処理方法は、ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出するステップと、ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、第１のユーザの位置情報（例えば第１のユーザの現在位置又は第１のユーザの予定位置）が、抽出された第２のユーザに係る、上記位置に関わる通知条件を満たしているか判断する判断ステップと、第１のユーザの位置情報が上記位置に関わる通知条件を満たしていると判断された場合には、第２のユーザに対して第１のユーザの情報を含む通知を行う通知ステップとを含む。
【００１０】
このように第２のユーザに対応付けられている第１のユーザの位置情報が、例えば第２のユーザの希望する位置に関わる通知条件（例えば特定の店舗の付近、特定の商品を販売している店舗の付近、特定の商品ジャンルに属する商品を販売している店舗の付近）を満たす場合には、例えば通知条件を満たしたとき又は近い将来通知条件を満たす予定であることが判明したときに第２のユーザに通知がなされる。すなわち、第２のユーザは、必要であれば適切なタイミングで第１のユーザに対して何らかの依頼を行うことができる。
【００１１】
また、本発明において、第２のユーザから第１のユーザに対する特定の商品の購入依頼を受信した場合、第１のユーザに対して特定の商品の購入依頼を送信するステップをさらに含むようにしてもよい。このように第２のユーザから第１のユーザへの依頼の転送自体も本仕組みにおいて取り扱うようにしても良いし、依頼自体については直接第２のユーザから第１のユーザに行うようにしても良い。
【００１２】
さらに、上で述べた位置に関わる通知条件が、第２のユーザにより設定された位置に関わる条件と第２のユーザの購買履歴に基づき自動的に抽出された位置に関わる条件との少なくともいずれかを含むようにしてもよい。すなわち、単に第２のユーザの希望に基づく条件だけではなく、第２のユーザが自分では気付かないような特徴を購買履歴により自動抽出して条件設定する場合もある。
【００１３】
また、上で述べた位置に関わる通知条件が、店舗識別情報と商品情報とのうち少なくともいずれかを含むようにしてもよい。
【００１４】
さらに、上で述べた判断ステップが、店舗の位置情報及び販売商品情報を含む店舗情報を格納する店舗情報格納部を参照して、第１のユーザの位置情報に基づき該当する店舗情報を抽出するステップと、抽出された店舗情報が、通知条件格納部に格納された、第２のユーザに係る上記位置に関わる通知条件に含まれる店舗識別情報と商品情報との少なくともいずれかに合致するか判断する第２判断ステップとを含むようにしてもよい。
【００１５】
このように、店舗について直接条件設定がなされる場合もあれば、商品について条件設定がなされて当該商品から店舗が特定されるような場合もある。さらに特定の商品だけではなく商品ジャンルなどの商品群について条件設定がなされる場合もある。
【００１６】
なお、上記方法は、コンピュータとプログラムの組み合わせにて実施される場合もあり、その場合に当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。
【発明の効果】
【００１７】
本発明によれば、ユーザの希望などに応じて他の特定のユーザに対して各種依頼を適切なタイミングで出すことができるようになる。
【発明を実施するための最良の形態】
【００１８】
図１に本発明の一実施の形態に係るシステム概要図を示す。例えば公衆回線網やインターネットなどであるネットワーク１には、複数の無線基地局５ａ及び５ｂ、例えばパーソナルコンピュータである１又は複数のユーザ端末Ｃ、被検索者（現在位置を探索されて例えば買い物を依頼される人物）により保持され且つ移動しながら例えば所定時間間隔で位置情報を送信する移動端末Ａ、移動端末Ａを保持する被検索者を登録したユーザが保持する移動端末Ｂ、本実施の形態における主たる処理を実施するセンタ・サーバ３、センタ・サーバ３の管理者が操作する例えばパーソナルコンピュータである１又は複数の管理者端末７が接続されている。
【００１９】
移動端末Ａ及び移動端末Ｂは、ＧＰＳ機能と、メーラ機能と、ウェブ（Ｗｅｂ）ブラウザ機能とを有する例えば携帯電話機である。但し、ＰＤＡ（Personal Digital Asistant）などの端末装置であってもよい。無線基地局５ａ及び５ｂについては、従来と同じであってこれ以上説明しない。ユーザ端末Ｃ及び管理者端末７は、メーラ機能と、Ｗｅｂブラウザ機能を有している。
【００２０】
センタ・サーバ３は、Ｗｅｂサーバ機能及びメーラ機能を有しており、さらにデータメンテナンス部３１、ユーザインタフェース部３２、購入履歴解析部３３、被検索者探索処理部３４及び照合処理部３５を有している。これらの機能の詳細については後に説明する。また、センタ・サーバ３は、商品データベース（ＤＢ）３６と、リストＤＢ３７と、店舗ＤＢ４０と、地図ＤＢ３９と、ユーザＤＢ３８とを管理している。これらのデータベースに格納されているデータについては以下で説明する。
【００２１】
まず地図ＤＢ３９の説明を行うが、その前に本実施の形態における地図データの取り扱いについて概観する。本実施の形態では、原則として地図を２００ｍ×２００ｍｍの正方形メッシュに分割する。図２に当該メッシュが所定数集まって構成されるエリアの一例を示す。図２の例では、５個×７個＝３５個のメッシュによりエリアが構成されている。図２には、エリアの境界線及びメッシュの境界線には、緯度・経度の値が示されており、例えばエリアの上限界値は北緯３６．０５．１５．１９９９４、下限界値は北緯３６．０５．１５．１９４９４となっている。またエリアの左限界値は東経１３６．５７．５１．６４６０９、エリアの右限界値は東経１３６．５７．５１．６３９０９となっている。各メッシュの頂点は、図２に示すように境界線の交点の緯度・経度の値により特定される。
【００２２】
なお、本実施の形態の趣旨からして電車や高速道路で移動している場合には、即座に買い物を行うことはできないため、電車の線路上や高速道路上の区画はエリアには含まれないようにする。図２の例ではハッチングが付された部分については電車の線路となっているため、エリアには含まれない。
【００２３】
エリアを所定数まとめると区域が構成される。本実施の形態では、例えば市区町村などの一定の範囲のエリアをまとめることにより区域が構成されるものとする。このように階層化された地図において各メッシュは、メッシュに付された番号（又はＩＤ）と、エリアに付された番号（又はＩＤ）と、区域に付された番号（又はＩＤ）との組み合わせにて特定するものとする。例えば、横０１−０９８−１３といったように表す。
【００２４】
なお、２００ｍｍ×２００ｍｍ程度の大きさを有するメッシュを用いると、大規模な商業施設などは、図３に示すように、いくつものメッシュにまたがることがある。すなわち、通常のメッシュＢ，Ｃ，Ｄ及びＥのうちメッシュＢ，Ｃ及びＤ上に、商業施設Ｆが配置されている。このような場合には、商業施設Ｆを一つのメッシュとして識別するものとする。従ってメッシュＢ，Ｃ及びＤ上の点であっても、メッシュＦと重なる場合にはメッシュＦを優先して特定するものとする。なお、メッシュＦと他のメッシュとの角度は必ずしも９０°とは限らないので、例えば特定の点がメッシュＦに含まれるか否かは以下の方法にて判断する。すなわち、対象の四角形を２つの三角形に分割し、その三角形の領域内に判断対象の点が入っているかどうかで判断する。その三角形内の領域に含まれているかどうかについては、対象の点の位置を三角形の二辺のベクトルによる一次結合で表すことにより判定する。
【００２５】
なお、図３に示したような特殊な場合にメッシュＦに特定の点が含まれるかの判断方法について説明したので、通常の場合に特定の点がいずれのメッシュに含まれるか判断する方法を図４を用いて簡単に説明しておく。図４の例では、図２において示したメッシュＡを示している。メッシュＡの頂点をａ、ｂ、ｃ及びｄとする。そして、特定の点をｘとする。センタ・サーバ３（被検索者探索処理部３４）では、この正方形の範囲は、上で述べたように東経及び北緯で示され、ａ乃至ｂ間は北緯３６．０５．１５．１９５９４から３６．０５．１５．１９４９４であり、ｂ乃至ｃ間は東経１３６．５７．５１．６４５０９から１３６．５７．５１．６４４０９である。従って特定の点ｘが例えば（３６．０５．１５．１９５８２，１３６．５７．５１．６４４７５）である場合には、北緯及び東経が、上で述べた正方形の範囲に入っているため、特定の点ｘはメッシュＡに含まれると判断される。メッシュを特定する際には、このようにエリア内の全てのメッシュを順次検索して、東経及び北緯のいずれもが包含される範囲を有するメッシュを特定する。
【００２６】
このような前提の下、地図ＤＢ３９には以下に示すようなデータが格納されている。なお、このようなデータの登録については例えば管理者端末７とセンタ・サーバ３のデータメンテナンス部３１とのデータのやり取りにて実施される。
【００２７】
図５に地図ＤＢ３９に格納される区域情報テーブルの一例を示す。図５の例では、各区域について、区域名と、区域の上限界値（緯度）と、区域の下限界値（緯度）と、区域の左限界値（経度）と、区域の右限界値（経度）とが登録されるようになっている。このように区域の辺を特定することにより各区域の範囲を特定することができる。また、図６に、各区域について設けられるエリア情報テーブルの一例を示す。図６の例では、各エリアについて、エリア名と、エリアの上限界値（緯度）と、エリアの下限界値（緯度）と、エリアの左限界値（経度）と、エリアの右限界値（経度）とが登録されるようになっている。このようにエリアの辺を特定することにより各エリアの範囲を特定することができる。
【００２８】
また、図７に地図ＤＢ３９に格納される区域データテーブルの一例を示す。図７の区域データテーブルは各メッシュのデータと区域及びエリアを結びつけるものであり、図７の例では、各メッシュについて、区域名と、エリア名と、メッシュ名と、メッシュの上限界値（緯度）と、メッシュの下限界値（緯度）と、メッシュの左限界値（経度）と、メッシュの右限界値（経度）とが登録されるようになっている。これにより各メッシュの範囲を特定することができ、さらにエリア及び区域との階層関係を特定できる。例えば「横０１−０００１−０４」というメッシュＩＤにより、区域「横０１」、エリア「０００１」、メッシュ「０４」が特定される。なお、商業施設のメッシュについては、４頂点の緯度・経度のデータを登録しておく。
【００２９】
また、地図ＤＢ３９には図８に示すような住所データテーブルも格納される。図８の住所データテーブルは住所からメッシュＩＤを特定するために使用され、図８の例では、都道府県名の列と、市区町村名の列と、町名の列と、丁目の列と、番地等の列と、メッシュＩＤの列とが設けられている。例えば店舗の住所やユーザの自宅住所からメッシュＩＤを本テーブルにて簡単に特定できる。
【００３０】
さらに、地図ＤＢ３９には図９に示すような駅データテーブルも格納される。図９の駅データテーブルは駅名などから当該駅のメッシュＩＤを特定するために使用され、図９の例では、最寄駅ＩＤの列と、路線名／会社（鉄道会社）の列と、駅名の列と、メッシュＩＤの列とが設けられている。これにより、例えばユーザの最寄駅が指定された場合に、当該最寄駅のメッシュＩＤを簡単に特定することができる。
【００３１】
次に商品ＤＢ３６に格納されるデータの一例について説明する。図１０に商品データテーブルの一例を示す。図１０の商品データテーブルは特定の商品のデータを取得するために用いられ、図１０の例では、商品区分を表すジャンルのＩＤ（ジャンルＩＤ）の列と、商品ＩＤの列と、商品名の列と、製造メーカの列と、小売希望価格の列と、独占販売フラグ（Ｙ／Ｎ）の列とが設けられている。独占販売フラグが「Ｙ」の商品は、１つの店舗又は１つのチェーンの店舗でしか販売していない商品を表し、「Ｎ］の商品は特に販売している店舗が限定されていない商品を示す。
【００３２】
また、図１１に商品ＤＢ３６に格納されるジャンルテーブルの一例を示す。図１１のジャンルテーブルはジャンル名とジャンルＩＤを対応付けるものであり、図１１の例では、ジャンルＩＤの列とジャンルの列とが設けられている。
【００３３】
本実施の形態では、被検索者が主に移動中に急にユーザが依頼する商品を購入することになるため、（１）服飾品、アクセサリー、腕時計などデザイン性が高く、商品選択が個人の主観に大きく依存するような商品類、（２）パソコン本体、冷蔵庫などの家電類や机、タンスなどの家具類といった高額や大型の商品、（３）通常繰り返し購入することや他人に頼んで購入することがないような商品類については、商品ＤＢ３６にデータは登録されない。
【００３４】
次に店舗ＤＢ４０に格納されるデータの一例について説明する。図１２に店舗データテーブルの一例を示す。図１２の店舗データテーブルは特定のメッシュに存在する店舗を特定するためや店舗の取扱商品及び商品のジャンルを特定するため等に用いられ、図１２の例では、メッシュＩＤの列と、店舗ＩＤの列と、営業時間フラグの列と、店舗名の列と、店舗住所の列と、取扱商品ＩＤの列と、取扱ジャンルＩＤの列と、備考の列とが設けられている。営業時間フラグについては、被検索者が付近にいる時に店舗が開店していなければ購入依頼を行う意味がないので営業中であるかを確認するために設定されるものであり、予め定められたルールに従って設定される。例えばＡ０９−１８については、無休で営業時間が９時から１８時であることを示している。また、Ｄ１０−１７は、水曜定休で営業時間が１０時から１７時であることを示している。取扱商品ＩＤ及び取扱ジャンルＩＤには、当該店舗において取り扱っている商品について、商品データテーブルに登録されている商品ＩＤ及びジャンルＩＤが登録される。備考は臨時の休業日などの情報、閉店情報などが登録される。
【００３５】
商品ＤＢ３６に登録されない商品について上で述べたが、上記のような商品のみを取り扱う店舗については店舗ＤＢ４０に登録されない。
【００３６】
次にユーザＤＢ３８に格納されるデータの一例について説明する。センタ・サーバ３により提供されるサービスを利用する際には、ユーザは、例えばユーザ端末Ｃ又は移動端末Ｂを用いて事前に登録を行う必要がある。例えば、ユーザは、ユーザ端末Ｃ又は移動体端末Ｂを操作して、センタ・サーバ３のユーザ登録ページにアクセスさせると、センタ・サーバ３のユーザインタフェース部３２は、ユーザ登録ページのデータをユーザ端末Ｃ又は移動体端末Ｂ（以下、ユーザ端末Ｃを用いる例を示す。）に送信する。ユーザ端末Ｃは、ユーザ登録ページ・データを受信し、例えば図１３に示すような画面を表示装置に表示する。
【００３７】
図１３の例では、氏名入力欄と、ふりがな入力欄と、自宅の住所入力欄と、最寄駅名入力欄と、鉄道会社名入力欄と、電話番号入力欄と、転送先メールアドレス入力欄と、本サービスの対価を徴収するための口座番号入力欄及び銀行名入力欄と、同じく対価徴収のためのクレジットカード番号入力欄と、本サービスについての契約条項を表示するための契約条項表示ボタンと、契約条項に同意することを確認するためのチェックボックスと、ユーザ登録を実行させるための登録ボタンと、登録の中止を行うための中止ボタンとが設けられている。ユーザは、この画面に従って必要なデータを入力し、契約条項に同意する場合には、チェックボックスにチェックを付して、登録ボタンをクリックする。
【００３８】
そうすると、ユーザ端末Ｃは、入力データなどをセンタ・サーバ３のユーザインタフェース部３２に送信する。センタ・サーバ３のユーザインタフェース部３２は、ユーザ端末Ｃからユーザ登録のためのデータを受信し、例えばユーザに対する確認のステップを経てユーザＤＢ３８に受信データを登録する。図１４にユーザＤＢ３８に格納されるユーザ登録テーブルの一例を示す。図１４のユーザ登録テーブルの例では、ユーザＩＤの列と、パスワードの列と、氏名の列と、ふりがなの列と、住所の列と、電話番号の列と、メールアドレスの列と、支払口座情報又はクレジットカード情報の列と、最寄駅ＩＤの列と、駅メッシュＩＤの列と、住所メッシュＩＤの列とが設けられる。ユーザＩＤとパスワードについては登録時にユーザインタフェース部３２により自動発行される。ユーザＩＤとパスワードについてはユーザに通知される。また、ユーザインタフェース部３２は、地図ＤＢ３９に格納されたデータ(図９）を用いて、ユーザの最寄駅について最寄駅ＩＤ及び駅メッシュＩＤを取得して登録する。さらに、地図ＤＢ３９（図８）を参照してユーザの自宅住所から住所メッシュＩＤを特定して登録する。
【００３９】
次に、本サービスの提供を受けるためには被検索者の登録が必須となる。従って、ユーザはユーザ端末Ｃを操作して被検索者登録／更新／削除ページにアクセスさせる。ユーザ端末Ｃからのアクセスに応じて、センタ・サーバ３のユーザインタフェース部３２は、被検索者登録／更新／削除ページのデータをユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から被検索者登録／更新／削除ページのデータを受信し、例えば図１５に示すような画面を表示装置に表示する。
【００４０】
図１５の例では、被検索者登録／更新／削除ページは、登録部１５０と更新／削除部１５１とを含む。そして、登録部１５０には、被検索者氏名の入力欄と、当該被検索者のメールアドレスの入力欄と、登録メール送信ボタンとを含む。新規に被検索者を登録する際には、氏名及びメールアドレスを入力し、登録メール送信ボタンをクリックする。なお、登録メール送信ボタンをクリックしただけでは被検索者として登録されない。これは被検索者の位置情報という個人情報が用いられるため被検索者の同意が必要なためである。従って、登録メール送信ボタンがクリックされると、当該被検索者氏名及びメールアドレスの情報がユーザ端末Ｃからセンタ・サーバ３のユーザインタフェース部３２に送信される。ユーザインタフェース部３２は、一旦上記データを登録依頼ユーザのユーザＩＤに対応付けてユーザＤＢ３８に仮登録し、当該被検索者に対して同意を求めるメールを送信する。当該メールに応じて被検索者から同意を得ることができれば、上記の仮登録を本登録に変更する。なお、被検索者からは「ふりがな」などの情報を追加で取得し、被検索者ＩＤ及びパスワードといったデータを発行する。被検索者ＩＤ及びパスワードは、被検索者に通知され、例えば被検索者が自己の登録を変更したり削除したりする場合に用いられる。
【００４１】
なお、更新／削除部１５１には、当該ユーザに対応して既登録の被検索者のデータを含むテーブルと、更新ボタンと、削除ボタンとが含まれる。ユーザは、変更したいデータ（氏名／メールアドレス）をクリックし、さらに更新ボタンをクリックする。ユーザが更新ボタンをクリックすると、選択されたボタンのＩＤ等がユーザ端末Ｃからセンタ・サーバ３に送信される。センタ・サーバ３のユーザインタフェース部３２は、選択されたボタンＩＤから変更項目の入力欄を含むページ・データを生成し、ユーザ端末Ｃに送信する。ユーザ端末Ｃは、当該ページ・データを受信し、表示装置に表示する。ユーザは、変更項目の入力欄に変更内容（氏名／メールアドレス）を入力し、更新メール送信ボタンをクリックする。ユーザ端末Ｃは、センタ・サーバ３に変更項目の内容データを送信する。センタ・サーバ３は、変更項目の内容データを受信し、ユーザＤＢ３８において被検索者ＩＤに対応して仮登録する。本実施の形態では、被検索者の同意を得ずには更新登録ができないようになっているため、更新確認メールを被検索者宛に送信する。被検索者から同意を得られれば、仮登録を本登録に変更する。
【００４２】
削除を行う場合には被検索者に同意を得る必要はないので、ユーザが図１５の画面において被検索者又はメールアドレスのいずれか及び削除ボタンをクリックした場合には、選択されたボタンのＩＤ等がユーザ端末Ｃからセンタ・サーバ３に送信される。センタ・サーバ３のユーザインタフェース部３２は、選択されたボタンのＩＤ等を受信し、被検索者ＩＤを特定し、ユーザＤＢ３８において登録ユーザと被検索者ＩＤとの対応付けを解除する。
【００４３】
上で述べた処理において用いられるユーザＤＢ３８に格納される、被検索者に関連するデータの一例を図１６及び図１７を用いて説明する。図１６に被検索者データテーブルの一例に示す。図１６の例では、被検索者ＩＤの列と、パスワードの列と、氏名の列と、ふりがなの列と、メールアドレスの列とが設けられている。これにより各被検索者について必要なデータを得ることができる。また、図１７には登録ユーザと被検索者とを対応付けるための対応テーブルの一例を示す。図１７の例では、ユーザＩＤの列と、被検索者として登録された被検索者のＩＤの列とが設けられている。このように、一人のユーザにつき複数の被検索者を登録することができる。なお本テーブルにおいては被検索者ＩＤから登録ユーザを抽出することもできる。なお、同じ人物を複数のユーザが被検索者として登録することも可能である。なお、図示しないが、ユーザＤＢ３８には、被検索者が現在位置するエリアＩＤを管理する被検索者位置テーブルも格納されている。
【００４４】
またユーザは、どのような場合にセンタ・サーバ３から通知を受けることを希望するかについて手動で登録を行うことができる。ユーザはユーザ端末Ｃを操作してセンタ・サーバ３の店舗又は商品登録ページにアクセスさせる。ここではまず店舗登録ページにアクセスして店舗を登録する場合の処理について説明する。ユーザ端末Ｃからのアクセスに応じて、センタ・サーバ３のユーザインタフェース部３２は、店舗登録ページのデータをユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から店舗登録ページのデータを受信し、例えば図１８のような画面を表示装置に表示する。
【００４５】
図１８の例では、店舗登録ページは、店舗検索部１８０と登録店舗修正削除部１８１とが含まれる。店舗検索部１８０には、店舗名入力欄と、店舗住所入力欄と、商品ジャンル選択欄と、店舗検索ボタンとが設けられている。ユーザは、新規に店舗を登録する場合には、入力欄にデータを入力し、商品ジャンルを選択する。但し検索であるからいずれかのデータが選択又は入力されていれば良い。店舗検索ボタンのクリックに応じて、ユーザ端末Ｃは選択入力データをセンタ・サーバ３に送信する。センタ・サーバ３のユーザインタフェース部３２は、ユーザ端末Ｃから検索条件である選択入力データを受信し、当該選択入力データに従って店舗ＤＢ４０（図１２）を検索する。ユーザインタフェース部３２は、検索結果を含む店舗リストページ・データを生成し、ユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から店舗リストページ・データを受信し、表示装置に表示する。この店舗リストページには、検索条件に合致する店舗のデータが含まれる。なお、店舗だけではなく、当該店舗が取り扱う商品及びその商品のジャンルについてのデータも選択可能な態様で提示される。ユーザは、店舗のみ、ジャンルのみ、商品のみ、店舗と商品とジャンルとの組み合わせ、店舗とジャンルの組み合わせと、商品とジャンルの組み合わせとを選択できる。選択した後に登録ボタンをクリックするとユーザ端末Ｃは、選択データをセンタ・サーバ３に送信する。センタ・サーバ３のユーザインタフェース部３２は、ユーザ端末Ｃから選択データを受信し、リストＤＢ３７に登録する。なお、店舗などには、メモなどを対応付けて登録することも可能である。
【００４６】
また、登録店舗修正削除部１８１には、店舗名と登録ジャンルと店舗所在地とメモ等を含む登録項目テーブルと、情報修正ボタンと、情報削除ボタンとが設けられている。既にリストＤＢ３７に登録されているデータ（店舗についての登録データ）が存在する場合には、この登録項目テーブルが生成される。店舗とジャンルとが対応して登録されている場合には、登録ジャンルについてのデータが表示される。なお、登録項目テーブルの修正又は削除可能な項目はボタンになっており、選択可能である。店舗名については、当該店舗を削除するために選択可能となっており、登録ジャンルについては、当該ジャンルを削除又は変更するために選択可能となっており、メモ等についても削除又は変更するために選択可能となっている。情報修正を行う場合には、修正を行うべき項目をクリックした後に情報修正ボタンをクリックする。ユーザ端末Ｃは、ユーザからの入力を受け付け、選択ボタンのＩＤ等及び情報修正を示すコードをセンタ・サーバ３に送信する。センタ・サーバ３は、選択ボタンのＩＤ等及び情報修正を示すコードを受信し、当該選択ボタンのＩＤ等に対応する修正入力欄を含む情報修正ページ・データを生成し、ユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から情報修正ページ・データを受信し、表示装置に表示する。ユーザは、選択した項目について修正後のデータを入力し、登録ボタンをクリックする。ユーザ端末Ｃは、ユーザにより入力された修正データをセンタ・サーバ３に送信する。センタ・サーバ３は、ユーザ端末Ｃから修正データを受信し、当該修正データに従ってリストＤＢ３７のデータを更新する。
【００４７】
一方、情報削除を行う場合には、ユーザは、削除すべき項目をクリックした後に情報削除ボタンをクリックする。ユーザ端末Ｃは、ユーザからの入力を受け付け、選択ボタンのＩＤ等及び情報削除を示すコードをセンタ・サーバ３に送信する。センタ・サーバ３は、選択ボタンのＩＤ等及び情報削除を表すコードを受信し、受信データに従ってリストＤＢ３７に格納されたデータを削除する。
【００４８】
次に商品登録ページにアクセスして商品を登録する場合の処理について説明する。ユーザ端末Ｃからのアクセスに応じて、センタ・サーバ３のユーザインタフェース部３２は、商品登録ページのデータをユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から商品登録ページのデータを受信し、例えば図１９のような画面を表示装置に表示する。
【００４９】
図１９の例では、商品登録ページは、商品検索部１９０と登録商品修正削除部１９１とを含む。商品検索部１９０には、商品名入力欄と、商品ジャンル選択欄と、店舗名入力欄と、商品検索ボタンとが設けられている。ユーザは、新規に商品を登録する場合には、入力欄にデータを入力し、商品ジャンルを選択する。但し検索であるからいずれかのデータが選択又は入力されていれば良い。商品検索ボタンのクリックに応じて、ユーザ端末Ｃは選択入力データをセンタ・サーバ３に送信する。センタ・サーバ３のユーザインタフェース部３２は、ユーザ端末Ｃから検索条件である選択入力データを受信し、当該選択入力データに従って商品ＤＢ３６（図１０）を検索する。ユーザインタフェース部３２は、検索結果を含む商品リストページ・データを生成し、ユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から商品リストページ・データを受信し、表示装置に表示する。この商品リストページには、検索条件に合致する商品のデータが含まれる。なお、商品だけではなく、当該商品を販売している店舗（例えば独占販売の場合のみに限定しても良い）及び当該商品のジャンルについてのデータも選択可能な態様で提示される。ユーザは、店舗のみ、ジャンルのみ、商品のみ、店舗と商品とジャンルとの組み合わせ、店舗とジャンルの組み合わせと、商品とジャンルの組み合わせとを選択できる。選択した後に登録ボタンをクリックするとユーザ端末Ｃは、選択データをセンタ・サーバ３に送信する。センタ・サーバ３のユーザインタフェース部３２は、ユーザ端末Ｃから選択データを受信し、リストＤＢ３７に登録する。なお、商品には、メモなどを対応付けて登録することも可能である。
【００５０】
また、登録商品修正削除部１９１には、商品名と登録ジャンルと販売店舗名とメモ等を含む登録項目テーブルと、情報修正ボタンと、情報削除ボタンとが設けられている。既にリストＤＢ３７に登録されているデータ（商品についての登録データ）が存在する場合には、この登録項目テーブルが生成される。また、登録商品に店舗が対応付けられて登録されている場合には、販売店舗名の列にデータが表示される。なお、登録項目テーブルの修正又は削除可能な項目はボタンになっており、選択可能である。商品名については、当該商品を削除するために選択可能となっており、登録ジャンルについては、当該商品と併せてジャンルを削除するために選択可能となっており、販売店舗名についても販売店の対応付けを変更又は削除するために選択可能となっており、メモ等についても削除又は変更するために選択可能となっている。情報修正を行う場合には、修正を行うべき項目をクリックした後に情報修正ボタンをクリックする。ユーザ端末Ｃは、ユーザからの入力を受け付け、選択ボタンのＩＤ等及び情報修正を示すコードをセンタ・サーバ３に送信する。センタ・サーバ３は、選択ボタンのＩＤ等及び情報修正を示すコードを受信し、当該選択ボタンのＩＤ等に対応する修正入力欄を含む情報修正ページ・データを生成し、ユーザ端末Ｃに送信する。ユーザ端末Ｃは、センタ・サーバ３から情報修正ページ・データを受信し、表示装置に表示する。ユーザは、選択した項目についての修正後のデータを入力し、登録ボタンをクリックする。ユーザ端末Ｃは、ユーザにより入力された修正データをセンタ・サーバ３に送信する。センタ・サーバ３は、ユーザ端末Ｃから修正データを受信し、当該修正データに従ってリストＤＢ３７のデータを更新する。
【００５１】
一方、情報削除を行う場合には、ユーザは、削除すべき項目をクリックした後に情報削除ボタンをクリックする。ユーザ端末Ｃは、ユーザからの入力を受け付け、選択ボタンのＩＤ等及び情報削除を示すコードをセンタ・サーバ３に送信する。センタ・サーバ３は、選択ボタンのＩＤ等及び情報削除を表すコードを受信し、受信データに従ってリストＤＢ３７に格納されたデータを削除する。なお、上で述べた独占販売商品については、店舗と商品との関係を削除できないため、変更・削除については独占販売については確認処理を行った上で削除・修正などを実施する。
【００５２】
以上のような処理により例えば図２０に示すようなデータがリストＤＢ３７に登録される。図２０の例では、登録ユーザのユーザＩＤの列と、店舗ＩＤの列と、ジャンルＩＤの列と、商品ＩＤの列とが設けられている。図２０の例にも示しているように、ユーザが店舗のみを指定した場合には店舗ＩＤのみ、ジャンルのみを指定した場合にはジャンルＩＤのみ、商品のみを指定した場合にはジャンルＩＤ及び商品ＩＤ（独占販売の場合には店舗も登録される場合がある）が登録される。また図示していないが、店舗ＩＤとジャンルＩＤの組み合わせについて登録される場合もある。このリストＤＢ３７に登録されるデータが、登録ユーザに対する通知条件となる。
【００５３】
次に図２１を用いて本実施の形態の処理フローの概要を説明する。まず、初期情報登録を実施する（ステップＳ１）。初期情報登録は、上でも述べたように、商品ＤＢ３６、店舗ＤＢ４０及び地図ＤＢ３９にデータを登録するものであり、例えば管理者端末７とセンタ・サーバ３のデータメンテナンス部３１とのデータのやりとりで実施される。次に、ユーザ情報登録を実施する（ステップＳ３）。ユーザ情報登録処理は、上で述べたようにユーザＤＢ３８及びリストＤＢ３７にデータを登録するものであり、例えば移動端末Ａ、移動端末Ｂ及びユーザ端末Ｃとセンタ・サーバ３のユーザインタフェース部３２とのやりとりで実施される。次に、購入履歴解析部３３は、購入履歴解析処理を実施する（ステップＳ５）。ユーザ情報登録処理（ステップＳ３）においては自ら店舗や商品の情報を登録したが、ここではユーザ自らが自覚していない又は失念してしまっているそのユーザに有用な情報を自動的に抽出して登録する。これについては後に詳述する。そして、被検索者探索処理部３４及び照合処理部３５は、探索・照合・通知処理を実施する（ステップＳ７）。被検索者の位置を特定し、通知条件と照合し、登録ユーザへ通知するなどの処理を実施する。なお、この処理についても後に詳述する。
【００５４】
まず購入履歴解析処理（図２１：ステップＳ５）について説明する。上でも述べたがユーザ自ら注目すべき店舗、商品又はジャンルを登録しても良いが、ユーザ自身登録を失念してしまっている項目又はユーザは意識していない項目も存在する。例えば、クレジットカードや電子マネーなど購入履歴が記録されるような手段にて決済を行った場合、その購入履歴データが取得できれば、登録すべき商品等を自動的に抽出してリストＤＢ３７に登録することができる。なお、ユーザ情報登録処理をスキップして、本処理のみを実行する場合もある。
【００５５】
本実施の形態では、センタ・サーバ３の外部システムから購入履歴データ（少なくとも購入日、購入店舗及び購入品のデータを含む）を取得して、（１）行動範囲内の店舗で販売している商品については、購入間隔が１ヶ月以上６ヶ月以内の数ヶ月に一度購入する程度の商品、（２）行動範囲外の店舗で販売している商品については、１年間に３乃至６回程度購入している商品を抽出するものである。なおこの条件における数値は一例であって、他の数値を用いるようにしても良い。なお、本実施の形態では、「行動範囲」とは、（１）自宅と最寄駅を結ぶ直線上のメッシュ及び当該メッシュの上下又は左右１メッシュ以内、（２）１ヶ月に５回以上購入している店舗のメッシュとする。なお、行動範囲の定義についても、本実施の形態とは異なる定義を採用するようにしても良い。
【００５６】
次に購入履歴解析処理について図２２乃至図２６を用いて説明する。購入履歴解析部３３は、購入履歴データをソートする仮表作成処理を実施する（ステップＳ１１）。この仮表作成処理は、（１）外部システムから取得した購入履歴データにおいて、最後の日付から過去一年分のデータを解析対象とし、さらに購入品が上で述べた本実施の形態における取扱除外商品であるレコードを除外したレコード群を抽出し、（２）購入履歴データに含まれる「購入日」をベースに各レコードを古い順にソートした結果を含むテーブルを生成するものである。外部システムから取得した購入履歴データは、図示しない購入履歴データ格納部に格納して用いるものとする。
【００５７】
次に、購入履歴解析部３３は、行動範囲分析処理を実施する（ステップＳ１３）。この処理は上で述べたような基準に基づきメッシュを抽出する処理であって、詳細については後に述べる。そして、行動範囲として抽出されたメッシュに含まれる店舗を店舗ＤＢ４０（図１２）から抽出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１５）。そして、ステップＳ１１で生成した仮表から未処理レコードを１つ抽出し（ステップＳ１７）、ステップＳ１５で読み出された店舗のデータを参照して、購入品が行動範囲内の店舗で販売されているか判断する（ステップＳ１９）。もし、販売されていると判断された場合には、ステップＳ１１で生成された仮表を参照して購入間隔が１ヶ月以上６ヶ月以下であるか判断する（ステップＳ２１）。もし、この基準を満たさないと判断された場合にはステップＳ２９に移行する。一方、この基準を満たすと判断された場合には、当該購入品のＩＤを商品ＤＢ３６（図１０）を検索して特定し（ステップＳ２５）、当該購入品のＩＤ等をリストＤＢ３７に登録する（ステップＳ２７）。なお、商品ＩＤだけではなく、ジャンルＩＤも登録する。場合によっては店舗ＩＤをも登録するようにしても良い。そしてステップＳ２９に移行する。一方、ステップＳ１９で、購入品が行動範囲内の店舗で販売されていないと判断された場合、当該購入品が最初の購入から１年以内に３乃至６回購入されているか、ステップＳ１１で生成された仮表を参照して判断する（ステップＳ２３）。この基準を満たしている場合にはステップＳ２５に移行し、この基準を満たしていない場合にはステップＳ２９に移行する。
【００５８】
ステップＳ２９では、仮表において全ての未処理レコードを処理したか判断する（ステップＳ２９）。もし未処理レコードが存在している場合にはステップＳ１７に戻る。一方、未処理レコードが存在しない場合には元の処理に戻る。
【００５９】
このようにして上で述べたような基準を満たす商品等を自動抽出してリストＤＢ３７に登録することができる。
【００６０】
次に、行動範囲分析処理について図２３乃至図２６を用いて説明する。購入履歴解析部３３は、ユーザの自宅及び最寄駅のメッシュＩＤをユーザＤＢ３８から取得し、例えばメインメモリなどの記憶装置に格納する（図２３：ステップＳ３１）。そして取得したメッシュＩＤで地図ＤＢ３９（図７）を検索して、当該メッシュの限界値を取得し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３３）。そして限界値に基づき最寄駅から自宅への方向を特定する（ステップＳ３５）。
【００６１】
例えば、自宅メッシュの上限界値と最寄駅メッシュの上限界値とを比較し、同じであれば最寄駅から自宅への方向は水平と仮に特定する。そして、例えば自宅メッシュの右限界値と最寄駅メッシュの右限界値とを比較し、自宅メッシュの右限界値の方が小さければ単に「右」、自宅メッシュの右限界値の方が大きければ単に「左」と特定される。
【００６２】
一方、自宅メッシュの上限界値と最寄駅メッシュの上限界値とを比較して、自宅メッシュの上限界値の方が値が大きければ最寄駅から自宅への方向は仮に「上」と判断され、自宅メッシュの上限界値の方が小さければ最寄駅から自宅への方向は仮に「下」と判断される。さらに、例えば自宅メッシュの右上限値と最寄駅メッシュの右上限値とを比較して、同じであれば最寄駅から自宅への方向は単に「上」又は「下」と、上限界値についての比較の際の判断結果で確定される。
【００６３】
また、自宅メッシュの上限界値と最寄駅メッシュの上限界値との差が存在する場合、自宅メッシュの右限界値と最寄駅メッシュの右限界値とを比較して、さらに右限界値についての差と上限界値についての差を比較する。もし、（１）自宅メッシュの右限界値の方が小さく且つ右限界値についての差の方が大きい場合には、垂直又は水平方向「右」及び斜め方向「右斜め」及び「上」又は「下」（上限界値についての比較結果に従う）を特定し、（２）自宅メッシュの右限界値の方が大きく且つ右限界値についての差の方が大きい場合には、垂直又は水平方向「左」及び斜め方向「左斜め」及び「上」又は「下」（上限界値についての比較結果に従う）を特定し、（３）自宅メッシュの右限界値の方が小さく且つ上限界値についての差の方が大きい場合には、垂直又は水平方向「上」又は「下」（上限界値についての比較結果に従う）並びに斜め方向「右斜め」及び「上」又は「下」（上限界値についての比較結果に従う）を特定し、（４）自宅メッシュの右限界値の方が大きく且つ上限界値についての差の方が大きい場合には、垂直又は水平方向「上」又は「下」（上限界値についての比較結果に従う）並びに斜め方向「左斜め」及び「上」又は「下」（上限界値についての比較結果に従う）を特定する。
【００６４】
そして、購入履歴解析部３３は、ステップＳ３５の処理結果に基づき、自宅と最寄駅が垂直又は水平直線で結べるか判断する（ステップＳ３７）。ステップＳ３５で最寄駅から自宅への方向が「右」のみ又は「左」のみ若しくは「上」のみ又は「下」のみと判断されたを確認する。もし、斜め方向が特定されている場合については、端子Ａを介して図２５において説明する。ステップＳ３７において自宅と最寄駅が垂直又は水平直線で結べると判断された場合の一例を図２４を用いて説明する。図２４の例では、自宅と駅（最寄駅）のメッシュが水平に配置された例である。
【００６５】
次に、購入履歴解析部３３は、ステップＳ３５で特定された方向とは逆方向の１メッシュを行動範囲テーブルに登録する（ステップＳ３９）。図２４の例では、ステップＳ３５において方向は「左」と特定されるので、「右」方向に１メッシュ分進んだメッシュａを行動範囲テーブルに登録する。また、最寄駅メッシュを特定する（ステップＳ４１）。図２４の例では、メッシュｂ１が最寄駅メッシュであるから、これを特定する。そして、特定されたメッシュ、及び水平方向（「右」又は「左」）の場合には上下のメッシュ、垂直方向（「上」又は「下」）の場合には左右のメッシュを、行動範囲テーブルに登録する（ステップＳ４３）。また特定されたメッシュが自宅メッシュであるか判断する（ステップＳ４５）。まだ自宅メッシュに到達していないと判断される場合には、ステップＳ３５で特定された方向に１メッシュ分進み、当該メッシュを特定する（ステップＳ４７）。図２４の例では、メッシュｂ２を特定する。そしてステップＳ４３に戻る。このステップＳ４３乃至Ｓ４７を繰り返すと、メッシュｂ２及びｃ２、メッシュｂ３及びｃ３、メッシュｂ４及びｃ４が、行動範囲テーブルに登録される。メッシュｂ４及びｃ４が行動範囲テーブルに登録されると、ステップＳ４５で自宅メッシュに到達したと判断される。
【００６６】
自宅メッシュに到達したと判断した場合には、ステップＳ３５において特定された方向に１メッシュ分進み、当該メッシュを行動範囲テーブルに登録する（ステップＳ４９）。図２４の例ではメッシュｅを行動範囲テーブルに登録する。このように図２４においてハッチングが付されたメッシュ群が行動範囲として特定される。
【００６７】
さらに、購入履歴解析部３３は、ステップＳ１１で生成した仮表を参照して、１ヶ月に５回以上購入している店舗を特定し、当該店舗のメッシュを行動範囲テーブルに登録する（ステップＳ５１）。そして元の処理に戻る。
【００６８】
次に図２５及び図２６を用いて端子Ａから移行した先の処理について説明する。なお、図２５の処理を実施する場合というのは、例えば図２６に示すように自宅メッシュと最寄駅メッシュが水平（「右」又は「左」）又は垂直（「下」又は「上」）の直線で結ぶことができないような場合である。購入履歴解析部３３は、自宅メッシュから最寄駅メッシュに、ステップＳ３５において特定された斜め方向に従ってメッシュ線を配置する（ステップＳ５３）。図２６の例では、ステップＳ３５において特定される方向は垂直又は水平方向は「左」であり、斜め方向は「左斜め」及び「上」ということになる。すなわち、最寄駅から見て自宅の位置は左斜め上ということになる。一方、基準を自宅にすると、最寄駅の位置は右斜め下ということになる。本ステップでは、「左斜め」及び「上」から、「右斜め」及び「下」という方向を特定し、右斜め下４５°方向にメッシュ線を配置する。図２６の例では、斜線が付加されたメッシュがメッシュ線上のメッシュとなる。
【００６９】
そして、購入履歴解析部３３は、ステップＳ３５において特定された垂直又は水平方向とは逆方向の１メッシュを行動範囲テーブルに登録する（ステップＳ５５）。図２６の例では、ステップＳ３５において垂直又は水平方向「左」が特定されているので、「右」方向に１メッシュ進んだメッシュＢを行動範囲テーブルに登録する。
【００７０】
また、最寄駅メッシュを特定する（ステップＳ５７）。そして、特定されたメッシュ及びその上下（垂直又は水平方向が「右」又は「左」の場合）又は左右（垂直又は水平方向が「上」又は「下」の場合）のメッシュを行動範囲テーブルに登録する（ステップＳ５９）。図２６の例ではメッシュＣ１及びＤ１が行動範囲テーブルに登録される。そして、メッシュ線上のメッシュに到達したか判断する（ステップＳ６１）。もし到達していないと判断された場合には、ステップＳ３５で特定された垂直又は水平方向に１メッシュ進み、当該メッシュを特定する（ステップＳ６３）。そしてステップＳ５９に戻る。一方、メッシュ線上に到達するとステップＳ６５に移行する。ステップＳ５９乃至ステップＳ６３を繰り返すことにより、メッシュＣ２及びＤ２、メッシュＣ３及びＤ３が特定される。そしてメッシュＣ３がメッシュ線上のメッシュとなり、ステップＳ６５に移行する。
【００７１】
次に購入履歴解析部３３は、メッシュ線上の自宅メッシュの方向の次のメッシュを特定する（ステップＳ６５）。図２６の例ではメッシュＦ１を特定する。そして、特定されたメッシュ及びその上下（垂直又は水平方向が「右」又は「左」の場合）又は左右（垂直又は水平方向が「上」又は「下」の場合）を行動範囲テーブルに登録する（ステップＳ６７）。図２６の例では、メッシュＦ１及びＧ１が登録される。そして、自宅メッシュに到達したか判断する（ステップＳ６９）。自宅メッシュに到達していない場合には、メッシュ線上を自宅メッシュ方向に１メッシュ進み、当該メッシュを特定する（ステップＳ７１）。図２６の例ではメッシュＦ２が特定される。そしてステップＳ６７に戻る。ステップＳ６７乃至Ｓ７１を繰り返すことにより、図２６の例ではメッシュＦ２及びＧ２が特定される。
【００７２】
そして自宅メッシュに到達すると、ステップＳ３５で特定された垂直又は水平方向に１メッシュ分進み、当該メッシュを行動範囲テーブルに登録する（ステップＳ７３）。図２６の例では、垂直又は水平方向は「左」であったので、「左」のメッシュＩが行動範囲テーブルに登録される。そして端子Ｂを介して図２３のステップＳ５１に移行する。
【００７３】
このようにすることにより上で述べた行動範囲が特定され、さらに行動範囲内のメッシュに含まれる店舗を抽出することができるようになる。
【００７４】
次に、被検索者探索処理部３４及び照合処理部３５により実行される探索・照合・通知処理について説明する。これまでの処理にて準備が完了しており、被検索者が移動端末Ａに対して位置情報をセンタ・サーバ３に送信する設定を行うと、図２７に示すような処理を実施する。すなわち、移動端末Ａは、例えば定期的（例えば数分おきに）に位置情報をセンタ・サーバ３に送信する（ステップＳ８１）。位置情報は、被検索者ＩＤと、現在位置の緯度・経度のデータとを含む。センタ・サーバ３の被検索者探索処理部３４は、移動端末Ａから位置情報を受信すると、例えばメインメモリなどの記憶装置に格納する（ステップＳ８３）。なお、被検索者の位置情報はプライバシ保護のため被検索者探索処理でしか用いられないようにする。そして、被検索者探索処理を実施する（ステップＳ８５）。この被検索者探索処理については、図２８及び図２９を用いて詳細に説明する。
【００７５】
被検索者探索処理部３４は、被検索者端末から受信した位置情報から被検索者を特定する（図２８：ステップＳ１１１）。位置情報に含まれる被検索者ＩＤを特定する。そして、前回のエリアＩＤが登録されているか判断する（ステップＳ１１５）。例えばユーザＤＢ３８に被検索者位置テーブルを設け、被検索者ＩＤ及びエリアＩＤを登録しておく。なお、所定期間被検索者の移動端末Ａから位置情報を受信しない場合には、当該被検索者のレコードは被検索者位置テーブルから削除される。もし当該被検索者位置テーブルを参照して当該被検索者についてエリアＩＤが登録されていると判断された場合には、地図ＤＢ３９（図６）を参照して、前回のエリアＩＤ及び受信した位置情報からエリアを特定する（ステップＳ１１７）。前回のエリアＩＤを保持している場合には、当該エリアから動いたかどうかを判断することによってメッシュＩＤの特定を高速化するものである。すなわち、各エリアには上下左右の限界値が登録されており、被検索者の移動端末Ａから受信した緯度・経度がその値を超えている場合には、当該エリア外に移動したことを特定できる。上限界値を超えた場合には、上のエリアに移動したものと推定し、右限界値を超えた場合には右側のエリアを移動したものと推定し、その他の方向についても同様である。場合によってはエリアだけではなく区域の限界値とも比較して限界値を超えているようであれば、別の区域についてエリアを特定する。
【００７６】
図２９に一例を示す。例えば前回のエリアＩＤがＡを示しており、当該エリアＡの上限界値が３６．０５．１５．１９９９４、下限界値が３６．０５．１５．１９４９４、左限界値が１３６．５７．５１．６４６０９、右限界値が１３６．５７．５１．６３９０９であるものとする。この時被検索者の位置が、（３６．０５．１５．１９５９４，１３６．５７．５１．６４４０９）である場合には、両方の値がエリアＡの限界値内に収まっているのでエリアＡからは移動していないと判定される。一方、（３６．０５．１５．２０１９４，１３６．５７．５１．６４４０９）である場合には、上限界値を超えているのでエリアＢに移動したものと推定する。さらに、（３６．０５．１５．１９５９４，１３６．５７．５１．６３７０９）である場合には、右限界値を超えているのでエリアＥに移動したものと推定する。さらに、（３６．０５．１５．２０１９４，１３６．５７．５１．６３６０９）である場合には、上限界値及び右限界値ともに超えているのでエリアＦに移動したものと推定する。
【００７７】
一方、ステップＳ１１５において前回のエリアＩＤが登録されていないと判断された場合には、受信した位置情報及び地図ＤＢ３９（図５）に格納された区域の限界値の情報を基に区域を特定する（ステップＳ１１９）。そして、受信した位置情報及び地図ＤＢ３９（図６）に格納され且つステップＳ１１９で特定されたエリアの限界値の情報を基に、エリア（エリアＩＤ）を特定する（ステップＳ１２１）。そしてステップＳ１２１又はステップＳ１１１７で特定されたエリアＩＤを、例えばユーザＤＢ３８の被検索者位置テーブルに登録する（ステップＳ１２３）。
【００７８】
このような処理を実施してエリアを特定する。なお、被検索者位置テーブルにメッシュＩＤを登録しておくような方法も可能であるが、メッシュでは範囲が狭すぎるため何らかの理由でメッシュの移動記録が漏洩した場合に問題となるため、プライバシに配慮してエリアを用いている。
【００７９】
エリアが特定されると、当該エリア内のメッシュの限界値を地図ＤＢ３９（図７）から読み出し、各メッシュの限界値と受信した経度・緯度の情報からエリア内のメッシュを特定する（ステップＳ１２５）。すなわち、メッシュＩＤを取得し、例えばメインメモリなどの記憶装置に格納する。なお、上でも述べたが商業施設が正方形メッシュとは別に規定されている場合もある。従って、現在位置が商業施設上でないか判断する（ステップＳ１２７）。商業施設についても長方形メッシュとして４頂点の緯度・経度のデータがエリア毎に地図ＤＢ３９に登録されているので、商業施設が当該エリア中に存在している場合にはそのデータを参照して、現在位置が商業施設上であるか判断する。もし、商業施設上であると判断された場合には、ステップＳ１２５で特定されたメッシュＩＤではなく、商業施設のメッシュＩＤを特定する（ステップＳ１２９）。そして元の処理に戻る。一方、商業施設上ではないと判断された場合には、何もせず元の処理に戻る。
【００８０】
以上のような処理を実施することにより、次の処理に用いる被検索者のエリアＩＤを特定でき、さらに本来必要なメッシュＩＤを特定することができる。ここで、被検索者の位置情報そのものについては破棄する。
【００８１】
図２７の説明に戻って、次に照合処理部３５は、照合処理を実施する（ステップＳ８７）。この照合処理については図３０乃至図３６を用いて説明する。まず、照合処理部３５は、被検索者探索処理において特定された被検索者ＩＤ及びメッシュＩＤを取得する（図３０：ステップＳ１３１）。そして、取得された被検索者ＩＤの被検索者を自己の被検索者としているユーザのユーザＩＤを、ユーザＤＢ３８（図１７）から読み出し、ユーザＩＤ表を生成し、メインメモリ等の記憶装置に格納する（ステップＳ１３３）。そして、ユーザＩＤ表の全てのユーザについて処理したか判断する（ステップＳ１３５）。もし全てのユーザについて処理が完了した場合には元の処理に戻る。
【００８２】
一方、未処理のユーザがユーザＩＤ表に残っている場合には、ユーザＩＤ表から１のユーザを抽出し（ステップＳ１３７）、当該ユーザについて仮表生成処理を実施する（ステップＳ１３９）。この仮表生成処理については、図３１を用いて説明する。照合処理部３５は、リストＤＢ３７（図２０）から該当ユーザの情報を例えばメインメモリ等の記憶装置に読み出す（ステップＳ１５５）。そして、全てのレコードを処理したか判断する（ステップＳ１５７）。全てのレコードの処理が完了した場合には元の処理に戻る。一方、未処理レコードが存在する場合には、未処理の１レコードを特定する（ステップＳ１５９）。そして、当該レコードが店舗ＩＤのみで構成されるものであるか判断する（ステップＳ１６１）。もし、当該レコードが店舗ＩＤのみで構成されるものである場合には、店舗仮表に当該レコードの店舗ＩＤを登録する（ステップＳ１６３）。そして端子Ｅを介してステップＳ１５７に戻る。一方、当該レコードが店舗ＩＤのみで構成されるわけではない場合には、当該レコードがジャンルＩＤのみで構成されるものであるか判断する（ステップＳ１６５）。もし、当該レコードがジャンルＩＤのみで構成されるものである場合には、ジャンル仮表に当該レコードのジャンルＩＤを登録する（ステップＳ１６７）。そして端子Ｅを介してステップＳ１５７に戻る。一方、当該レコードがジャンルＩＤのみで構成されるものではない場合、商品仮表に商品ＩＤを登録し（ステップＳ１６９）、さらに商品ＩＤに対応して登録されているジャンルＩＤをジャンル仮表に登録する（ステップＳ１７１）。そして、端子Ｅを介してステップＳ１５７に戻る。
【００８３】
このようにして、店舗仮表、ジャンル仮表及び商品仮表が生成される。すなわち、ユーザへの通知条件となる店舗のリスト、ジャンルのリスト、商品のリストが生成されることになる。
【００８４】
図３０の説明に戻って、照合処理部３５は、メッシュＩＤで特定されるメッシュ内において営業時間中の全ての店舗の店舗情報を、店舗ＤＢ４０（図１２）から、メインメモリなどの記憶装置に読み出す（ステップＳ１４１）。営業時間中でなければ買い物はできないので、本実施の形態では営業時間フラグに従って予め処理対象から除去するものである。そして、ステップＳ１４１において読み出された店舗情報の全ての店舗情報について処理したか判断する（ステップＳ１４３）。もし全ての店舗情報について処理したと判断された場合にはステップＳ１３５に戻る。一方、未処理の店舗情報が存在する場合には、未処理の１店舗分の情報を特定し（ステップＳ１４５）、当該店舗で販売する商品の商品ＩＤがステップＳ１３９で生成された商品仮表中のいずれかの商品と一致するか判断する（ステップＳ１４７）。もし、当該店舗で販売する商品の商品ＩＤがステップＳ１３９で生成された商品仮表中のいずれかの商品と一致した場合には、商品メールを生成し（ステップＳ１４９）、商品メールを送信する（ステップＳ１５１）。そして端子Ｄを介してステップＳ１４３に戻る。ここで、ユーザＤＢ３８（図１４）から処理対象のユーザＩＤを用いてユーザ名及びメールアドレスを抽出し、ユーザＤＢ３８（図１６）から被検索者ＩＤを用いて被検索者名及びメールアドレスを抽出し、一致すると判断された商品ＩＤを用いて商品ＤＢ３６（図１０）から商品名を抽出し、店舗ＤＢ４０（図１２）から処理対象の店舗ＩＤを用いて店舗名を抽出して、例えばメインメモリなどの記憶装置に格納しておく。そして、読み出したデータを用いて商品メールを生成する。商品メールの具体例については後に述べる。
【００８５】
一方、当該店舗で販売する商品の商品ＩＤがステップＳ１３９で生成された商品仮表中のいずれの商品ＩＤとも一致しない場合には、端子Ｃを介して図３２の処理に移行する。次に、照合処理部３５は、処理対象店舗の店舗ＩＤがステップＳ１３９で生成された店舗仮表中のいずれかの店舗と一致するか判断する（図３２：ステップＳ１７５）。もし、処理対象の店舗の店舗ＩＤが店舗仮表中のいずれかの店舗ＩＤと一致したと判断された場合には、店舗メールを生成し（ステップＳ１７７）、当該店舗メールを送信する（ステップＳ１７９）、そして端子Ｄを介してステップＳ１４３に戻る。ここでは、ユーザＤＢ３８（図１４）から処理対象のユーザＩＤを用いてユーザ名及びメールアドレスを抽出し、ユーザＤＢ３８（図１６）から被検索者ＩＤを用いて被検索者名及びメールアドレスを抽出し、処理対象店舗の店舗ＩＤを用いて店舗ＤＢ４０（図１２）から店舗名を抽出して、例えばメインメモリなどの記憶装置に格納しておく。そして、読み出したデータを用いて店舗メールを生成する。
【００８６】
一方、処理対象店舗の店舗ＩＤがステップＳ１３９で生成された店舗仮表中のいずれの店舗ＩＤとも一致しない場合には、処理対象店舗に対応して登録されているジャンルＩＤがステップＳ１３９で生成されたジャンル仮表中のいずれかのジャンルＩＤと一致するか判断する（ステップＳ１８１）。もし、処理対象店舗に対応して登録されているジャンルＩＤがジャンル仮表中のいずれかのジャンルＩＤと一致すると判断された場合には、ジャンル・メールを生成し（ステップＳ１８３）、当該ジャンル・メールを送信する（ステップＳ１８５）、そして端子Ｄを介してステップＳ１４３に戻る。ここで、ユーザＤＢ３８（図１４）から処理対象のユーザＩＤを用いてユーザ名及びメールアドレスを抽出し、ユーザＤＢ３８（図１６）から被検索者ＩＤを用いて被検索者名及びメールアドレスを抽出し、ジャンルＩＤを用いて商品ＤＢ３６（図１１）からジャンル名を抽出し、処理対象店舗の店舗ＩＤを用いて店舗ＤＢ４０（図１２）から店舗名を抽出して、例えばメインメモリなどの記憶装置に格納する。そして、読み出したデータを用いてジャンル・メールを生成する。
【００８７】
このような処理を実施することにより被検索者が現在存在する位置のメッシュに含まれる店舗について、店舗、商品、ジャンルのいずれかが、ユーザに対応して設定されている通知条件たる店舗仮表、商品仮表、ジャンル仮表のいずれかの項目と一致するか判断する。もし、一致する事項が存在する場合には、商品メール、店舗メール、ジャンル・メールをユーザに送信する。なお、一致する項目がない場合にはメールは生成されず、送信されない。そして、次の被検索者の位置情報の処理に移行する。ここではいずれかのメールが生成され、送信されるものとする。
【００８８】
図２７の説明に戻って、ステップＳ８７でメールが生成され且つ送信される。そうすると、ユーザが保持する移動体端末Ｂは、センタ・サーバ３からのメールを受信し、表示装置に表示する（ステップＳ８９）。例えば図３３のような商品メールが表示装置に表示される。図３３の例では、○○という被検索者の位置情報に基づき△△△△という店舗が特定され、さらに「■■■■■」という商品が特定される場合を示す。すなわち、商品メールには、被検索者の情報と、商品の情報と、店舗の情報が含まれる。図３３の商品メールの例では、メッセージ入力欄と「送信する」ボタンと「送信しない」ボタンとが設けられている。ユーザは、○○という被検索者に当該商品の購入を依頼する場合には、例えばメッセージ入力欄にメッセージを入力し「送信する」ボタンをクリックする。商品の購入を依頼しない場合には「送信しない」ボタンをクリックする場合と何もしない場合とがある。
【００８９】
ここではメッセージを入力し「送信する」ボタンがクリックされたものとする。そうすると、移動端末Ｂは、指示に応じてセンタ・サーバ３に購入依頼データを送信する（ステップＳ９１）。購入依頼データには、メッセージと、被検索者ＩＤ、店舗ＩＤ、商品ＩＤ等か又はこれらのデータと対応付けられた商品メールＩＤとが含まれる。例えばセンタ・サーバ３の照合処理部３５は、移動端末Ｂから購入依頼データを受信すると（ステップＳ９３）、ステップＳ８７で特定され且つメインメモリなどの記憶装置に格納されているデータ等を用いて、被検索者宛の購入依頼メールを送信する（ステップＳ９５）。商品メールＩＤでそれらのデータが特定されるようにする場合もある。
【００９０】
そして、移動端末Ａは、センタ・サーバ３からの購入依頼メールを受信し、表示装置に表示する（ステップＳ９６）。例えば図３４のような購入依頼メールが表示される。図３４の購入依頼メールの例では、依頼者（◎◎）、店舗（△△△△）、商品（■■■■■）の情報が含まれており、さらに依頼者からのメッセージ表示欄と、依頼に対して承諾することを表明するための「購入する」ボタンと、依頼を拒否することを表明するための「購入しない」ボタンとが設けられている。被検索者は、メールの内容を確認して、依頼を承諾する場合には「購入する」ボタンをクリックし、依頼を拒否する場合には「購入しない」ボタンをクリックする。
【００９１】
移動端末Ａは、被検索者による承諾／拒否応答を受け付け、センタ・サーバ３に送信する（ステップＳ９７）。センタ・サーバ３の照合処理部３５は、移動端末Ａから被検索者による承諾／拒否応答を受信し、一旦メインメモリなどの記憶装置に格納する（ステップＳ９９）。そして、当該承諾／拒否応答メールを生成し、依頼者宛に承諾／拒否応答メールを送信する（ステップＳ１０１）。移動端末Ｂは、センタ・サーバ３からの承諾／拒否応答メールを受信し、表示装置に表示する（ステップＳ１０３）。
【００９２】
このように被検索者の現在位置に応じて、対応するユーザのために設定されている商品、店舗、商品ジャンルの通知条件を満たしているか判断して、満たしている場合にはユーザに対し購入依頼を行うか確認する通知が行われる。また、購入依頼を行う場合には、センタ・サーバ３が仲介する。
【００９３】
なお、図３３の商品メールの代わりに図３５に示すようなジャンル・メールが送信される場合もある。図３５の例では、「目薬（中高年向け）」が特定されたジャンルを表しており、被検索者（○○）、店舗（△△△△）の情報が含まれている。さらに、図３５の例では、購入依頼品入力欄と、メッセージ入力欄と、「送信する」ボタンと、「送信しない」ボタンとが設けられている。ユーザは、購入依頼商品名を入力し「送信する」ボタンをクリックするか、又は「送信しない」ボタンをクリックする。「送信する」ボタンがクリックされると、例えば被検索者ＩＤ、ジャンルＩＤ、店舗ＩＤ、購入依頼商品名、及びメッセージのデータが購入依頼データとしてセンタ・サーバ３に送信する。なお、ジャンル・メールＩＤによりステップＳ８７で特定され且つメインメモリに格納されるデータを識別できるようにしておき、当該ジャンル・メールがセンタ・サーバ３に送信されてくるようにしても良い。
【００９４】
また、図３５に示したようなジャンル・メールに対応してユーザが購入依頼を行った場合には、図３４の購入依頼メールの代わりに図３６に示すような購入依頼メールが被検索者宛に送信される。図３６の例では、依頼者（◎◎）、店舗（△△△△）、購入依頼商品（■■■■■）のデータが含まれている。また、メッセージ表示欄と、「購入する」ボタンと、「購入しない」ボタンとが設けられている。なお、ジャンルが一致して図３５のようなジャンル・メールが送信されたので、依頼者が指定した購入依頼商品が必ずしも店舗で販売されているかは不明であるため、その旨のメッセージも含まれている。被検索者は、依頼を承諾する場合には「購入する」ボタンをクリックし、依頼を拒否する場合には「購入しない」ボタンをクリックする。
【００９５】
店舗メールについては図示を省略するが、基本的にはジャンル・メールにおいてジャンルのデータが含まれないようなメールが生成され、送信される。店舗メールに応じて被検索者宛に送信される購入依頼メールについても図示しないが、図３６と同じような内容となる。
【００９６】
なお、上で述べたセンタ・サーバ３、ユーザ端末Ｃ、管理者端末７は、コンピュータであって、コンピュータは図３７に示すような構成を有する。すなわち、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及び上で述べた処理を実施するアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００９７】
また、移動端末Ａ及びＢについても、ドライブ装置２５１３やＨＤＤ２５０５については保持しない場合もあるが、代わりにフラッシュメモリなどの半導体記憶装置を保持している。
【００９８】
以上本発明の一実施の形態を説明したが、本発明は上で述べた実施の形態に限定されるものではない。例えば、図３８に別の実施の態様を示す。この図３８は図２７に代わって実施される処理フローである。図３８では、被検索者は、移動端末Ａを操作して、現在位置ではなく、例えば明日又は来週など将来の予定位置情報をセンタ・サーバ３に送信する（ステップＳ１９１）。例えば、出張の予定や旅行の予定などに従って、例えば出張先や旅行先の駅名、ビル名その他の位置情報を含む。また時間のデータについては、日にちだけの場合もあれば時刻のデータを含む場合もある。なお、わざわざ予定位置情報のみを送信するのではなく、例えばスケジュールを管理するサービスへのスケジュール登録のためのデータを用いるようにしても良い。その場合、受信データはスケジュール・データ格納部に格納される。
【００９９】
センタ・サーバ３の被検索者探索処理部３４は、移動端末Ａから予定位置情報を受信し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１９３）。次に、例えば地図ＤＢ３９等を参照して予定位置情報に対応するメッシュＩＤを特定する（ステップＳ１９５）。そして、照合処理部３５は、照合処理を実施する（ステップＳ１９７）。なお、図３０乃至図３２に示した照合処理を実施するが、例えばステップＳ１４１における営業時間の確認などは、予定時刻が特定できれば実施する。以下、ステップＳ１９９乃至ステップＳ２１５は、図２７のステップＳ８９乃至ステップＳ１０３とほぼ同じである。
【０１００】
また、他の変形も可能である。例えばセンタ・サーバ３については１台のコンピュータにて上記の機能を実現するようにしても良いし、複数台のコンピュータにより実現させるようにしても良い。さらに、図１に示した機能ブロックは必ずしもプログラム・モジュールに対応するものではない。また、データベース構成についても図１に限定するものではなく、より多くのデータベース又はより少ないデータベースを使用するようにしても良い。
【０１０１】
メールを使用する例を述べたが、メールではなく、音声メッセージを利用するようにしても良いし、インスタントメッセージ等を使用しても良い。また、センタ・サーバ３を介さずに直接ユーザと被検索者が、購入依頼以降のやり取りを行っても良い。
【０１０２】
また、上の処理フローでは同じ内容のメールが数分おきに生成され送信される場合もあるので、前回送信した通知メールを保存しておき、同じ内容の場合には送信しないなどとの処置を施す場合もある。
【０１０３】
（付記１）
ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出するステップと、
ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、前記第１のユーザの位置情報が、抽出された前記第２のユーザに係る、前記位置に関わる通知条件を満たしているか判断する判断ステップと、
前記第１のユーザの位置情報が前記位置に関わる通知条件を満たしていると判断された場合には、前記第２のユーザに対して前記第１のユーザの情報を含む通知を行う通知ステップと、
を含み、コンピュータにより実行される位置情報処理方法。
【０１０４】
（付記２）
前記第２のユーザから前記第１のユーザに対する特定の商品の購入依頼を受信した場合、前記第１のユーザに対して前記特定の商品の購入依頼を送信するステップ
をさらに含む、付記１記載の位置情報処理方法。
【０１０５】
（付記３）
前記第１のユーザの位置情報が、前記第１のユーザの現在位置の情報と前記第１のユーザの予定位置の情報とのいずれかであることを特徴とする付記１又は２記載の位置情報処理方法。
【０１０６】
（付記４）
前記位置に関わる通知条件が、前記第２のユーザにより設定された位置に関わる条件と前記第２のユーザの購買履歴に基づき自動的に抽出された位置に関わる条件との少なくともいずれかを含む付記１乃至３のいずれか１つ記載の位置情報処理方法。
【０１０７】
（付記５）
前記位置に関わる通知条件が、店舗識別情報と商品情報とのうち少なくともいずれかを含む付記１乃至４のいずれか１つ記載の位置情報処理方法。
【０１０８】
（付記６）
前記判断ステップが、
店舗の位置情報及び販売商品情報を含む店舗情報を格納する店舗情報格納部を参照して、前記第１のユーザの位置情報に基づき該当する店舗情報を抽出するステップと、
抽出された前記店舗情報が、前記通知条件格納部に格納された、前記第２のユーザに係る前記位置に関わる通知条件に含まれる前記店舗識別情報と前記商品情報との少なくともいずれかに合致するか判断する第２判断ステップと、
を含む、付記５記載の位置情報処理方法。
【０１０９】
（付記７）
前記商品情報が、商品ジャンルの情報を含み、
前記第２判断ステップにおいて、前記店舗において販売される商品のジャンルと前記商品情報に含まれる商品ジャンルの情報とを比較する
ことを特徴とする付記６記載の位置情報処理方法。
【０１１０】
（付記８）
購買日及び購買店舗の情報を含む購買履歴のデータを格納する購買履歴データ格納部を参照して、ユーザの行動範囲として特定された地理的範囲に含まれる購買店舗についての第１の条件と、前記ユーザの行動範囲として特定された地理的範囲に含まれない購買店舗についての第２の条件との少なくともいずれかを満たす店舗の情報を前記位置に関わる条件として特定するステップ
をさらに含む付記４記載の位置情報処理方法。
【０１１１】
（付記９）
前記判断ステップが、
前記第２判断ステップにおいて合致すると判断された場合、合致すると判断された店舗識別情報、又は合致すると判断された商品情報及び当該商品を販売する店舗識別情報とを特定する特定ステップをさらに含み、
前記通知ステップにおいて、前記特定ステップにおいて特定された情報をさらに通知する
ことを特徴とする付記６記載の位置情報処理方法。
【０１１２】
（付記１０）
付記１乃至９のいずれか１つ記載の位置情報処理方法をコンピュータに実行させるためのプログラム。
【０１１３】
（付記１１）
ユーザ間の対応関係を格納したユーザ情報格納部を参照して、移動する第１のユーザに対応付けられている第２のユーザを抽出する手段と、
ユーザの現在位置とは無関係の位置に関わる通知条件を格納した通知条件格納部を参照して、前記第１のユーザの位置情報が、抽出された前記第２のユーザに係る、前記位置に関わる通知条件を満たしているか判断する判断手段と、
前記第１のユーザの位置情報が前記位置に関わる通知条件を満たしていると判断された場合には、前記第２のユーザに対して前記第１のユーザの情報を含む通知を行う通知手段と、
を有する位置情報処理装置。
【図面の簡単な説明】
【０１１４】
【図１】本発明の一実施の形態に係るシステム概要図である。
【図２】エリアの一例を示す図である。
【図３】メッシュにおける商業施設の取扱いを説明するための模式図である。
【図４】メッシュに含まれるか否かを判定するための処理を説明するための模式図である。
【図５】区域情報テーブルの一例を示す図である。
【図６】エリア情報テーブルの一例を示す図である。
【図７】区域データテーブルの一例を示す図である。
【図８】住所データテーブルの一例を示す図である。
【図９】駅データテーブルの一例を示す図である。
【図１０】商品データテーブルの一例を示す図である。
【図１１】ジャンルテーブルの一例を示す図である。
【図１２】店舗データテーブルの一例を示す図である。
【図１３】ユーザ登録画面の一例を示す図である。
【図１４】ユーザ登録テーブルの一例を示す図である。
【図１５】被検索者登録／更新／削除画面の一例を示す図である。
【図１６】被検索者データテーブルの一例を示す図である。
【図１７】対応テーブルの一例を示す図である。
【図１８】お気に入り店舗登録画面の一例を示す図である。
【図１９】お気に入り商品登録画面の一例を示す図である。
【図２０】リストＤＢに登録されるデータの一例を示す図である。
【図２１】本発明の一実施の形態に係る処理フローを示す図である。
【図２２】購入履歴解析処理の処理フローを示す図である。
【図２３】行動範囲分析処理の処理フローの一部を示す図である。
【図２４】行動範囲分析処理の処理フローを説明するための模式図である。
【図２５】行動範囲分析処理の処理フローの一部を示す図である。
【図２６】行動範囲分析処理の処理フローを説明するための模式図である。
【図２７】探索・照合・通知処理の処理フローを示す図である。
【図２８】被検索者探索処理の処理フローを示す図である。
【図２９】区域の例を示す図である。
【図３０】照合処理の処理フローの一部を示す図である。
【図３１】仮表生成処理の処理フローを示す図である。
【図３２】照合処理の処理フローの一部を示す図である。
【図３３】商品メールの一例を示す図である。
【図３４】購入依頼メールの一例を示す図である。
【図３５】ジャンル・メールの一例を示す図である。
【図３６】購入依頼メールの一例を示す図である。
【図３７】コンピュータの機能ブロックの一例を示す図である。
【図３８】探索・照合・通知処理の処理フローの第２例を示す図である。
【符号の説明】
【０１１５】
１  ネットワーク    ３  センタ・サーバ
５ａ，５ｂ  無線基地局
７  管理者端末
Ａ，Ｂ  移動端末
Ｃ  ユーザ端末
３１  データメンテナンス部
３２  ユーザインタフェース部
３３  購入履歴解析部
３４  被検索者探索処理部
３５  照合処理部
３６  商品ＤＢ    ３７  リストＤＢ    ３８  ユーザＤＢ
３９  地図ＤＢ    ４０  店舗ＤＢ
【図１】
2005215725.tif 000003
【図２】
2005215725.tif 000004
【図３】
2005215725.tif 000005
【図４】
2005215725.tif 000006
【図５】
2005215725.tif 000007
【図６】
2005215725.tif 000008
【図７】
2005215725.tif 000009
【図８】
2005215725.tif 000010
【図９】
2005215725.tif 000011
【図１０】
2005215725.tif 000012
【図１１】
2005215725.tif 000013
【図１２】
2005215725.tif 000014
【図１３】
2005215725.tif 000015
【図１４】
2005215725.tif 000016
【図１５】
2005215725.tif 000017
【図１６】
2005215725.tif 000018
【図１７】
2005215725.tif 000019
【図１８】
2005215725.tif 000020
【図１９】
2005215725.tif 000021
【図２０】
2005215725.tif 000022
【図２１】
2005215725.tif 000023
【図２２】
2005215725.tif 000024
【図２３】
2005215725.tif 000025
【図２４】
2005215725.tif 000026
【図２５】
2005215725.tif 000027
【図２６】
2005215725.tif 000028
【図２７】
2005215725.tif 000029
【図２８】
2005215725.tif 000030
【図２９】
2005215725.tif 000031
【図３０】
2005215725.tif 000032
【図３１】
2005215725.tif 000033
【図３２】
2005215725.tif 000034
【図３３】
2005215725.tif 000035
【図３４】
2005215725.tif 000036
【図３５】
2005215725.tif 000037
【図３６】
2005215725.tif 000038
【図３７】
2005215725.tif 000039
【図３８】
2005215725.tif 000040