JP7003822B2 - 情報処理装置、情報処理システム、及びプライバシ保護プログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム、及びプライバシ保護プログラムに関する。

従来、ユーザが保持する端末からユーザのリアルタイムな位置情報を取得し、取得した位置情報に基づいて、位置に関連する情報を端末に提供するサービスが知られている。このようなサービスを利用するユーザは、詳細な位置情報をサービス提供者に教えたくない場合もあるため、端末からサービス提供者に送信する位置情報をユーザの存在位置を抽象化した位置情報とすることがある。例えば、端末からサービス提供者に送信する位置情報としては、ユーザが存在している市区町村の名称とすることができる。

特開２００９－２９６４５２号公報

しかしながら、個々の時点において抽象化した位置情報を送信したとしても、複数の時点の抽象化した位置情報を組み合わせて解析すると、ユーザが存在する又は存在した範囲（存在範囲）として、知られたくない程度に狭い範囲が特定できてしまう場合がある。このような場合には、ユーザのプライバシが侵害されるおそれがある。

このようなプライバシの侵害を回避するための方法としては、ユーザの存在位置をより広い領域で抽象化することが考えられる。この場合、端末からサービス提供者に送信する位置情報は、例えば都道府県の名称などとすることができる。しかしながら、この場合には、サービス提供者から提供される情報が都道府県全体の情報となり、情報量が膨大になるおそれがある。

また、プライバシの侵害を回避するための方法としては、抽象化した位置情報を送信するタイミングを遅らせることも考えられるが、このようにすると、ユーザの位置に関連する情報をリアルタイムに提供することができない。

１つの側面では、本発明は、外部装置から位置に関連する情報を取得する際のプライバシ保護を実現することが可能な情報処理装置、情報処理システム及びプライバシ保護プログラムを提供することを目的とする。

一つの態様では、情報処理装置は、位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定する特定部と、前記特定部が特定した前記存在可能な範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断する判断部と、前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信する送信部と、前記外部装置から前記第３の領域に関連する情報を受信する受信部と、を備える。

外部装置から位置に関連する情報を取得する際のプライバシ保護を実現することができる。

一実施形態に係る情報処理システムの構成を概略的に示す図である。 図２（ａ）は、ユーザ端末のハードウェア構成を示す図であり、図２（ｂ）は、サービス提供装置及び個人データ管理サーバのハードウェア構成を示す図である。 ユーザ端末、個人データ管理サーバ、サービス提供装置の機能ブロック図である。 プライバシ保護条件を示す図である。 図５（ａ）は、リクエスト済み領域情報ログの一例を示す図であり、図５（ｂ）は、存在可能範囲の代表点を説明するための図である。 個人データ管理サーバの一連の処理を示すフローチャートである。 図５のステップＳ１６の詳細処理を示すフローチャートである。 図６のステップＳ１８の詳細処理を示すフローチャートである。 図９（ａ）、図９（ｂ）は、リクエスト済み領域情報ログの変遷を示す図である。 図１０（ａ）、図１０（ｂ）は、図６～図８の処理を説明するための図（その１）である。 図１１（ａ）、図１１（ｂ）は、図６～図８の処理を説明するための図（その２）である。 図６～図８の処理を説明するための図（その３）である。 図１３（ａ）、図１３（ｂ）は、図６～図８の処理を説明するための図（その４）である。 図１４（ａ）、図１４（ｂ）は、図６～図８の処理を説明するための図（その５）である。 図１５（ａ）、図１５（ｂ）は、図６～図８の処理を説明するための図（その６）である。 図１６（ａ）、図１６（ｂ）は、図６～図８の処理を説明するための図（その７）である。 図１７（ａ）、図１７（ｂ）は、図６～図８の処理を説明するための図（その８）である。 図１８（ａ）、図１８（ｂ）は、図６～図８の処理を説明するための図（その９）である。 変形例を示す図（その１）である。 変形例を示す図（その２）である。 変形例を示す図（その３）である。

以下、情報処理システムの一実施形態について、図１～図１８（ｂ）に基づいて詳細に説明する。図１には、一実施形態に係る情報処理システム１００の構成が概略的に示されている。

図１に示すように、情報処理システム１００は、端末としてのユーザ端末７０と、外部装置としてのサービス提供装置１０と、情報処理装置としての個人データ管理サーバ２０と、を備える。ユーザ端末７０と、サービス提供装置１０と、個人データ管理サーバ２０は、インターネットなどのネットワーク８０に接続されている。

ユーザ端末７０は、スマートフォンやタブレット型端末などのユーザが携帯可能な端末である。図２（ａ）には、ユーザ端末７０のハードウェア構成が示されている。図２（ａ）に示すように、ユーザ端末７０は、ＣＰＵ（Central Processing Unit）１９０、ＲＯＭ（Read Only Memory）１９２、ＲＡＭ（Random Access Memory）１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、位置検出装置１８９、及び可搬型記憶媒体用ドライブ１９９等を備えている。表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、タッチパネルや物理ボタン、キーボード等を含む。位置検出装置１８９は、ＧＰＳ（Global Positioning System）センサ等を含む。これらユーザ端末７０の構成各部は、バス１９８に接続されている。ユーザ端末７０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図３に示す、位置情報送信部７２、及びサービス情報受信部７４としての機能が実現されている。なお、図３のユーザ端末７０の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。

位置情報送信部７２は、サービス提供装置１０に対して現在の位置に関連する情報の提供をリクエストする場合に、位置検出装置１８９で取得された現在位置の情報を、個人データ管理サーバ２０に送信する。

サービス情報受信部７４は、サービス提供装置１０から個人データ管理サーバ２０に送信されてくる情報の全部又は一部を個人データ管理サーバ２０から受信する。サービス情報受信部７４が受信した情報は、ユーザ端末７０の現在位置に関連する情報であり、表示部１９３に表示されるなどして、ユーザに提供される。

図１に戻り、個人データ管理サーバ２０は、ユーザ端末７０からユーザ端末７０の現在位置の情報とともに、現在位置に関連する情報のリクエストを受信する。そして、個人データ管理サーバ２０は、ユーザ端末７０の現在位置の情報を抽象化し、抽象化した現在位置の情報とともにリクエストをサービス提供装置１０に送信する。この場合、個人データ管理サーバ２０は、ユーザ端末７０を利用するユーザのプライバシが侵害されないように、抽象化した現在位置の情報にダミーの情報を付加して、サービス提供装置１０に送信する場合がある。

また、個人データ管理サーバ２０は、リクエストに対応する情報がサービス提供装置１０から送信されてきた場合に、受信した情報の全部又は一部をユーザ端末７０に送信する。なお、個人データ管理サーバ２０のハードウェア構成や機能の詳細については後述する。

サービス提供装置１０は、個人データ管理サーバ２０からリクエストを受信し、受信したリクエストに基づいて、ユーザ端末７０に提供する情報を抽出して、個人データ管理サーバ２０に送信する。図２（ｂ）には、サービス提供装置１０のハードウェア構成が示されている。図２（ｂ）に示すように、サービス提供装置１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ）９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらサービス提供装置１０の構成各部は、バス９８に接続されている。サービス提供装置１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図３に示す、リクエスト受信部１２、処理部１４、サービス情報送信部１６としての機能が実現されている。なお、図３のサービス提供装置１０の各部の機能は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。

リクエスト受信部１２は、個人データ管理サーバ２０から送信されてくるリクエスト（ユーザ端末７０の抽象化した現在位置の情報やダミーの情報を含む）を受信する。リクエスト受信部１２は、受信したリクエストを処理部１４に受け渡す。

処理部１４は、リクエストを受け取ると、受け取ったリクエストに基づいて、ユーザ端末７０に提供する情報を抽出し、サービス情報送信部１６に受け渡す。

サービス情報送信部１６は、処理部１４から受け取った情報を個人データ管理サーバ２０に送信する。

（個人データ管理サーバ２０のハードウェア構成及び機能について）
個人データ管理サーバ２０は、サービス提供装置１０と同様、図２（ｂ）に示すようなハードウェア構成を有する。具体的には、個人データ管理サーバ２０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ＨＤＤ）９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。個人データ管理サーバ２０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（プライバシ保護プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（プライバシ保護プログラムを含む）をＣＰＵ９０が実行することにより、図３の各部の機能が実現されている。なお、図３の個人データ管理サーバ２０の各部の機能は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。

個人データ管理サーバ２０は、ＣＰＵ９０がプログラムを実行することにより、図３に示す、位置情報取得部２２、抽象化部２４、特定部及び判断部としてのプライバシ侵害判定部２６、ダミー領域生成部２８、領域統合部３０、リクエスト送信部３２、受信部としてのサービス情報受信部３４、選択部としてのサービス情報選択部３６、として機能する。

位置情報取得部２２は、ユーザ端末７０の位置情報送信部７２から送信されてくるユーザ端末７０の現在位置の情報を取得し、抽象化部２４に受け渡す。

抽象化部２４は、プライバシ保護条件４０に基づいて、受け取ったユーザ端末７０の位置情報を抽象化する。ここで、プライバシ保護条件４０は、一例として、図４に示すようなデータであるものとする。図４のプライバシ保護条件４０においては、ユーザごと（ユーザＩＤごと）に、抽象化用プライバシ保護条件と、侵害判定用プライバシ保護条件と、が定義されている。なお、プライバシ保護条件４０は、各ユーザが予め設定しておく条件であるものとする。

例えば、図４の例では、ユーザＩＤ＝Ａの場合、抽象化部２４は、受け取ったユーザ端末７０の現在位置の情報を、現在位置を含む市区町村名に変換することで、抽象化する。また、ユーザＩＤ＝Ｂの場合、抽象化部２４は、受け取ったユーザ端末７０の位置情報を、該位置情報を含む都道府県名に変換することで、抽象化する。また、ユーザＩＤ＝Ｃの場合、抽象化部２４は、受け取ったユーザ端末７０の位置情報を、該位置情報を含む街区名に変換することで、抽象化する。なお、抽象化した現在位置の情報は、ユーザが存在する領域を示す情報であるため、抽象化した現在位置を以下においては「存在領域」と呼ぶものとする。なお、侵害判定用プライバシ保護条件は、プライバシ侵害判定部２６において用いられるものであるので、詳細については後述する。

プライバシ侵害判定部２６は、ユーザ端末７０の存在領域の情報をサービス提供装置１０に送信した場合に、プライバシが侵害されるか否かを判定する。ここで、個々の時点において抽象化した現在位置の情報（存在領域の情報）を送信したとしても、複数の時点の存在領域を組み合わせて解析すると、ユーザが存在する又は存在した範囲（存在可能範囲）として、知られたくない程度に狭い範囲が特定できてしまう場合がある。この場合における「知られたくない程度」が図４のプライバシ保護条件４０の「侵害判定用プライバシ保護条件」である。すなわち、侵害判定用プライバシ保護条件は、予め定められている、第三者に知られたくない存在可能範囲の条件である。例えば、図４のユーザＩＤ＝Ａの場合、複数の時点の存在領域情報を組み合わせて解析した場合に特定される存在可能範囲が、存在領域の７０％以上でなければプライバシが侵害されると判定される。また、ユーザＩＤ＝Ｂの場合、複数の時点の存在領域情報を組み合わせて解析した場合に特定される存在可能範囲が、面積３０ｋｍ²以上でなければプライバシが侵害されると判定される。なお、プライバシ侵害判定部２６の具体的な処理については、後述する。

ダミー領域生成部２８は、プライバシ侵害判定部２６によりユーザのプライバシが侵害されると判定された場合に、ユーザ端末７０の存在領域の情報と一緒にサービス提供装置１０に送信するダミーの情報を生成する。ダミーの情報は、存在領域の近傍の別の領域（ダミー領域）の情報である。例えば、存在領域がＡ区である場合には、Ａ区の近傍に存在する区がダミー領域となる。

領域統合部３０は、抽象化部２４が変換した存在領域の情報と、ダミー領域生成部２８が生成したダミー領域の情報とを統合して、リクエスト送信部３２に受け渡す。なお、プライバシ侵害判定部２６においてプライバシが侵害されないと判定された場合には、ユーザ端末７０の存在領域の情報が、抽象化部２４からリクエスト送信部３２に直接受け渡される。

リクエスト送信部３２は、ユーザ端末７０からのリクエストを、領域統合部３０又は抽象化部２４から受け取った領域の情報とともに、サービス提供装置１０のリクエスト受信部１２に対して送信する。なお、リクエスト送信部３２は、リクエストの内容をリクエスト済み領域情報ログ４２に格納する。リクエスト済み領域情報ログ４２は、一例として、図５（ａ）に示すようなデータ構造を有する。図５（ａ）のリクエスト済み領域情報ログ４２は、ユーザ端末７０ごと（ユーザＩＤごと）に用意されているものとする。

図５（ａ）に示すように、リクエスト済み領域情報ログ４２には、「日時」、「存在領域情報」、「ダミー領域情報」、「存在可能範囲」の各情報が格納される。「日時」の欄には、ユーザ端末７０からリクエストを受信した日時の情報が格納される。「存在領域情報」の欄には、ユーザ端末７０の現在位置を抽象化した存在領域の情報（例えばユーザ端末７０が存在する市区町村名）が格納される。「ダミー領域情報」の欄には、サービス提供装置１０に送信したダミー領域の情報（例えばユーザ端末７０が存在する市区町村の近傍の市区町村名）が格納される。「存在可能範囲」の欄には、サービス提供装置１０が特定することができるユーザ端末７０の存在可能範囲の情報が格納される。具体的には、「存在可能範囲」には、存在可能範囲を規定するための複数の代表点の緯度、経度の情報が格納される。図５（ａ）の例では、存在可能範囲は東京都の中野区全体であるため、代表点は、図５（ｂ）に示すような中野区と他の区との境界に位置する白丸で示す複数の点（例えば境界線の向きが所定角度以上変化する点）である。なお、図５（ｂ）において示す代表点は一例であり、実際の代表点の個数や位置は図５（ｂ）とは異なっている。

サービス情報受信部３４は、サービス提供装置１０のサービス情報送信部１６から情報を受信すると、受信した情報をサービス情報選択部３６に受け渡す。

サービス情報選択部３６は、サービス情報受信部３４が受信した情報のうち、ユーザ端末７０の存在領域に関連する情報を選択（抽出）し、ユーザ端末７０のサービス情報受信部７４に送信する。なお、サービス情報選択部３６は、情報選択（抽出）の際に、リクエスト済み領域情報ログ４２の存在領域情報の欄を参照する。

（個人データ管理サーバ２０の処理について）
次に、個人データ管理サーバ２０の処理について、図６～図８のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。なお、説明の前提として、図４のユーザＩＤ＝Ａのユーザがユーザ端末７０を利用しているものとする。また、リクエスト済み領域情報ログ４２には、ユーザＩＤ＝Ａのユーザ端末７０のログデータが一切存在していないものとする。

図６は、個人データ管理サーバ２０の全体処理を示すフローチャートである。図６の処理では、まず、ステップＳ１０において、位置情報取得部２２が、リクエストが発生するまで待機する。ユーザ端末７０の位置情報送信部７２から現在の位置情報とリクエストが送信されてくると、ステップＳ１２に移行し、位置情報送信部７２は、現在の位置情報とリクエストを受信して、抽象化部２４に送信する。

次いで、ステップＳ１４では、抽象化部２４が、現在の位置情報を抽象化して存在領域情報を生成する。この場合、抽象化部２４は、図４のプライバシ保護条件４０からユーザＩＤ＝Ａのユーザの抽象化用プライバシ保護条件「市区町村」を得て、ユーザ端末７０の現在の位置情報を抽象化する。例えば、ユーザ端末７０が中野区内に存在している場合には、存在領域は「中野区」となる。

次いで、ステップＳ１６では、プライバシ侵害判定部２６が、プライバシ侵害判定処理を実行する。このステップＳ１６では、図７のフローチャートに沿った処理が実行される。なお、図７の処理では、今回のリクエストがｎ番目のリクエストとなる。

図７の処理では、ステップＳ３０において、プライバシ侵害判定部２６は、（ｎ－１）番目のリクエストに関する情報がリクエスト済み領域情報ログ４２に格納されているか否かを判断する。なお、上述したように、リクエスト済み領域情報ログ４２には、ユーザＩＤ＝Ａのログが存在していないため、ステップＳ３０の判断は否定される。ステップＳ３０の判断が否定された場合には、プライバシ侵害判定部２６は、ステップＳ３２において「プライバシ侵害無し」と判定し、図７の全処理を終了して、図６のステップＳ１７に移行する。

図６のステップＳ１７に移行すると、プライバシ侵害判定部２６は、プライバシ侵害有りと判定されたか否かを判断する。このステップＳ１７の判断が否定された場合には、ステップＳ２２に移行する。

ステップＳ２２に移行すると、リクエスト送信部３２が、リクエストをサービス提供装置１０（リクエスト受信部１２）に送信する。このとき、リクエスト送信部３２は、存在領域（中野区）の情報をリクエストとともに送信する。

次いで、ステップＳ２４では、リクエスト送信部３２が、リクエスト済み領域情報ログ４２を更新する。本例の場合、図５（ａ）のように、存在領域情報の欄に「中野区」が格納されるが、ダミー領域情報の欄は空欄となる。また、存在可能範囲の欄には、図５（ｂ）に示す中野区の境界の代表点（白丸で示す点）の緯度、経度の情報が格納される。

次いで、ステップＳ２６に移行すると、サービス情報受信部３４が、サービス提供装置１０から送信されてくるサービス情報（ここでは、存在領域（中野区）に関連する情報）を受信する。

次いで、ステップＳ２８では、サービス情報選択部３６が、リクエスト済み領域情報ログ４２を参照して、受信したサービス情報の中から、ユーザ端末７０に提供すべき情報を選択して、ユーザ端末７０（サービス情報受信部７４）に送信する。なお、ユーザ端末７０の存在領域が中野区であり、サービス情報受信部３４が、サービス情報として存在領域（中野区）に関連する情報のみを受信した場合には、サービス情報選択部３６は、受信したすべての情報をユーザ端末７０に送信する。その後は、ステップＳ１０に戻る。

次に、リクエスト済み領域情報ログ４２に図９（ａ）に示すようなログが格納されている状況において、２０１７年１０月２５日の１４：００：００にユーザ端末７０からリクエストが発生する場合について説明する。この１４：００：００におけるユーザ端末７０の現在位置は世田谷区内であるものとする。なお、図９（ａ）のログデータの「存在可能範囲」の欄には、渋谷区全体の領域を規定する代表点の緯度・軽度の情報が格納されているものとする。

ユーザ端末７０からリクエストが発生すると、図６のステップＳ１０の判断が肯定され、ステップＳ１２に移行する。ステップＳ１２に移行すると、位置情報送信部７２は、現在の位置情報とリクエストを受信して、抽象化部２４に送信する。次いで、ステップＳ１４では、抽象化部２４が、現在の位置情報を抽象化して存在領域の情報を生成する。この場合、存在領域は「世田谷区」となる。

次いで、ステップＳ１６では、図７のプライバシ侵害判定処理が実行される。図７の処理では、まず、ステップＳ３０において、プライバシ侵害判定部２６が、リクエスト済み領域情報ログ４２に（ｎ－１）番目のリクエストがあるか否かを判断する。ここでは、図９（ａ）に示すように、リクエスト済み領域情報ログ４２に直前に得られたリクエスト（（ｎ－１）番目のリクエスト）の情報が格納されているので、ステップＳ３０の判断は肯定され、ステップＳ３４に移行する。

ステップＳ３４に移行すると、プライバシ侵害判定部２６は、（ｎ－１）番目のリクエストとｎ番目のリクエストのインターバル時間を算出する。本例では、インターバル時間が３０分と算出される。

次いで、ステップＳ３６では、プライバシ侵害判定部２６が、（ｎ－１）番目のリクエストにおける存在可能範囲の境界からインターバル時間内で移動できる範囲（移動可能範囲）を求める。この場合、（ｎ－１）番目のリクエストの存在可能範囲が渋谷区全域であるため、渋谷区の境界からインターバル時間（３０分）以内に移動可能な範囲として、図１０（ａ）において破線で示す範囲を特定する。なお、移動可能範囲は、境界上の各点からインターバル時間に基づく所定距離だけ離れた点を繋いだ範囲などとすることができる。

次いで、ステップＳ３８では、プライバシ侵害判定部２６が、ｎ番目リクエストの存在領域の面積に対する、求めた移動可能範囲に含まれるｎ番目リクエストの存在領域の面積の割合を求める。具体的には、プライバシ侵害判定部２６は、世田谷区の面積に対する、求めた移動可能範囲（破線内領域）と重複する世田谷区内の面積（図１０（ｂ）において黒塗りされた部分の面積）の割合を求める。

次いで、ステップＳ４０では、プライバシ侵害判定部２６が、ｎ番目リクエストのプライバシ保護条件をクリアしているか否かを判断する。この場合、プライバシ侵害判定部２６は、図４のユーザＩＤ＝Ａの侵害判定用プライバシ保護条件（割合が７０％以上）をクリアしているか否かを判断する。図１０（ｂ）の例では、黒塗り部分が世田谷区に対して占める割合が世田谷区の７０％以上となっていないため、ステップＳ４０の判断は否定され、ステップＳ４４に移行する。ステップＳ４４では、プライバシ侵害判定部２６が、ｎ番目のリクエストにおいてプライバシ侵害が有ると判定する。一方、ステップＳ４０の判断が肯定された場合には、ステップＳ４２に移行し、プライバシ侵害判定部２６は、ｎ番目のリクエストにおいてプライバシ侵害が無いと判定する。ステップＳ４２又はＳ４４の後は、ステップＳ４６に移行する。

ステップＳ４６に移行すると、プライバシ侵害判定部２６は、ｎ番目のリクエストでの存在可能範囲の境界からインターバル時間内での移動可能範囲を求める。この場合、図１１（ａ）において太実線で示すような移動可能範囲が特定されたとする。

次いで、ステップＳ４８では、プライバシ侵害判定部２６が、（ｎ－１）番目リクエストの存在領域の面積に対する、求めた移動可能範囲に含まれる（ｎ－１）番目リクエストの存在領域の面積の割合を求める。具体的には、プライバシ侵害判定部２６は、渋谷区の面積に対する、求めた移動可能範囲（太実線内領域）と重複する渋谷区内の面積（図１１（ｂ）において黒塗りされた部分の面積）との割合を求める。この場合、図１１（ｂ）に示すように、移動可能範囲の中に渋谷区の全てが含まれているため、割合は１００％となる。

次いで、ステップＳ５０では、プライバシ侵害判定部２６が、ｎ番目リクエストのプライバシ保護条件をクリアしているか否かを判断する。この場合、プライバシ侵害判定部２６は、図４のユーザＩＤ＝Ａの侵害判定用プライバシ保護条件（割合が７０％以上）をクリアしているか否かを判断する。図１１（ｂ）の例では、ステップＳ４８で求めた割合が７０％以上となっているため、ステップＳ５０の判断は肯定され、ステップＳ５２に移行する。

ステップＳ５２に移行すると、プライバシ侵害判定部２６は、ｎ番目のリクエストにおいてプライバシ侵害が無いと判定する。一方、ステップ５０の判断が否定され、ステップＳ５４に移行した場合には、プライバシ侵害判定部２６は、ｎ番目のリクエストにおいてプライバシ侵害が有ると判定する。ステップＳ５２又はＳ５４の後は、図７の全処理を終了し、図６のステップＳ１７に移行する。なお、図７の処理においては、ステップＳ３６～Ｓ４４の処理と、ステップＳ４６～Ｓ５４の処理の順番を入れ替えてもよいし、同時並行的に実行することとしてもよい。

図６のステップＳ１７に移行すると、プライバシ侵害判定部２６は、プライバシ侵害有りと判定されたか否かを判断する。ここでは、図７の処理においてステップＳ４４及び／又はステップＳ５４を経ていた場合に、ステップＳ１７の判断が肯定される。ステップＳ１７の判断が肯定されると、ステップＳ１８に移行する。

ステップＳ１８に移行すると、ダミー領域生成部２８が、ダミー領域情報生成処理を実行する。具体的には、ダミー領域生成部２８は、図８のフローチャートに沿った処理を実行する。

図８の処理では、まず、ステップＳ６０において、ダミー領域生成部２８が、（ｎ－１）番目リクエスト時の移動可能範囲（図１２において破線で囲まれた領域）とｎ番目リクエストの移動可能範囲（図１２において実線で囲まれた領域）が重複する領域に少なくとも一部が含まれている領域（区）を追加候補領域として抽出する。この場合、図１２に示すように、重複する領域に少なくとも一部が含まれる「杉並区」、「中野区」、「目黒区」、「品川区」、「港区」、「新宿区」が追加候補領域として抽出される。

次いで、ステップＳ６２では、ダミー領域生成部２８が、全ての追加候補領域を１つずつｎ番目のリクエストの存在領域に追加した場合の、（ｎ－１）番目のリクエスト時及びｎ番目リクエスト時の存在可能範囲の増加面積を求める。

例えば、追加候補領域である「杉並区」をｎ番目のリクエストの存在領域に追加するとする。この場合、図１３（ａ）に示すように、ｎ番目のリクエストの存在領域が世田谷区と杉並区になることで、太実線で示すｎ番目リクエスト時の移動可能範囲が図１２よりも広がる。そして、ｎ番目リクエスト時の存在可能範囲は、杉並区内において黒塗りで示す範囲の面積だけ増加する。一方、（ｎ－１）番目のリクエスト時の存在可能範囲の増加面積は０である。

また、例えば、追加候補領域である「目黒区」をｎ番目のリクエストの存在領域に追加するとする。この場合、図１３（ｂ）に示すように、ｎ番目のリクエストの存在領域が世田谷区と目黒区になることで、太実線で示すｎ番目リクエスト時の移動可能範囲が図１２よりも広がる。そして、ｎ番目リクエスト時の存在可能範囲は、目黒区内において黒塗りで示す範囲の面積だけ増加する。一方、（ｎ－１）番目のリクエスト時の存在可能範囲の増加面積は０である。

その他の追加候補領域についても、同様の処理にして、増加面積の計算を行う。なお、ここでは、一例として、「杉並区」、「目黒区」、「品川区」…の順に増加面積が多かったものとする。

次いで、ステップＳ６４では、ダミー領域生成部２８が、ｎ番目のリクエストの存在領域に対して、増加面積が多い順に追加候補領域を１つ追加する。まず、ダミー領域生成部２８は、ｎ番目のリクエストの存在領域（世田谷区）に杉並区を追加する。この場合、ｎ番目リクエストにおける存在可能範囲は、図１３（ａ）において黒塗りで示す部分となる。

次いで、ステップＳ６６では、ダミー領域生成部２８が、プライバシ保護条件をクリアしているか否かを判断する。ここでは、ダミー領域生成部２８は、図１３（ａ）において黒塗りで示す部分の面積が、ｎ番目リクエスト時の存在領域（世田谷区）の面積の７０％以上であるか否かを判断する。このステップＳ６６の判断が否定された場合には、ステップＳ６４に戻る。

次いで、ステップＳ６４では、次に増加面積が多かった目黒区をｎ番目のリクエストの存在領域（ここでは世田谷区と杉並区）に追加する。この場合、ｎ番目リクエストにおける存在可能範囲は、図１４（ａ）において黒塗りで示す部分となる。次いで、ステップＳ６６では、ダミー領域生成部２８は、図１４（ａ）において黒塗りで示す部分の面積が、ｎ番目リクエスト時の存在領域（世田谷区）の７０％以上であるか否かを判断する。このステップＳ６６の判断が否定された場合には、再度ステップＳ６４に戻る。

そして、ステップＳ６４に戻ると、次に増加面積が多かった品川区をｎ番目のリクエストの存在領域（ここでは世田谷区と杉並区と目黒区）に追加する。この場合、ｎ番目リクエストにおける存在可能範囲は、図１４（ｂ）において黒塗りで示す部分となる。次いで、ステップＳ６６では、ダミー領域生成部２８は、図１４（ｂ）において黒塗りで示す部分の面積が、ｎ番目リクエスト時の存在領域（世田谷区）の面積の７０％以上であるか否かを判断する。ここでの判断が肯定されると、図８の全処理が終了し、図６のステップＳ２０に移行する。なお、ステップＳ６４において追加された追加候補領域（杉並区、目黒区、品川区）がダミー領域であり、ダミー領域の情報は、ダミー領域生成部２８から領域統合部３０に送信される。

図６のステップＳ２０に移行すると、領域統合部３０は、存在領域（世田谷区）の情報と、ダミー領域（杉並区、目黒区、品川区）の情報とを統合し、リクエスト送信部３２に送信する。

次いで、ステップＳ２２では、リクエスト送信部３２が、リクエストをサービス提供装置１０（リクエスト受信部１２）に送信する。このとき、リクエスト送信部３２は、存在領域（世田谷区）の情報とダミー領域（杉並区、目黒区、品川区）の情報とをリクエストとともに送信する。

次いで、ステップＳ２４では、リクエスト送信部３２が、リクエスト済み領域情報ログ４２を更新する。本例の場合、図９（ｂ）のように、存在領域情報の欄に「世田谷区」が格納され、ダミー領域情報の欄に「杉並区、目黒区、品川区」が格納される。そして、存在可能範囲の欄には、図１４（ｂ）に示す黒塗り部分の複数の代表点の緯度、経度の情報が格納されるようになっている。

次いで、ステップＳ２６に移行すると、サービス情報受信部３４は、サービス提供装置１０から送信されてくるサービス情報（ここでは、存在領域（世田谷区）に関連する情報と、ダミー領域（杉並区、目黒区、品川区）に関連する情報）を受信する。

次いで、ステップＳ２８では、サービス情報選択部３６が、リクエスト済み領域情報ログ４２を参照して、受信したサービス情報の中から、ユーザ端末７０に提供すべき情報を選択して、ユーザ端末７０（サービス情報受信部７４）に送信する。なお、サービス情報受信部３４は、サービス情報として存在領域（世田谷区）に関連する情報と、ダミー領域情報（杉並区、目黒区、品川区）に関連する情報を受信している。一方、ユーザ端末７０の現在の存在領域は世田谷区であるため、受信した情報の中から存在領域（世田谷区）に関連する情報のみを選択（抽出）して、ユーザ端末７０に送信する。その後は、ステップＳ１０に戻る。

上述した図１０（ａ）～図１４（ｂ）の例は、ｎ番目のリクエストにおいてプライバシ侵害があるが、（ｎ－１）番目のリクエストにおいてプライバシ侵害が無い場合の例である。以下においては、別の例として、（ｎ－１）番目のリクエストにおいてプライバシ侵害があるが、ｎ番目のリクエストにおいてプライバシ侵害が無い場合の例について説明する。

図１５（ａ）には、（ｎ－１）番目のリクエスト時の存在領域が世田谷区であり、ｎ番目のリクエスト時の存在領域が渋谷区である場合を示している。この場合、図１５（ｂ）において太実線で示す範囲が、ｎ番目リクエスト時の移動可能範囲であり、破線で示す範囲が、（ｎ－１）番目リクエスト時の移動可能範囲である。

本例では、（ｎ－１）番目リクエストの存在領域の面積（世田谷区の面積）に対する、ｎ番目リクエスト時の移動可能範囲に含まれる（ｎ－１）番目リクエストの存在領域の面積（図１５（ｂ）の黒塗り部分の面積）の割合が７０％以上でない。したがって、（ｎ－１）番目のリクエストにおいてプライバシ侵害がある。一方、ｎ番目リクエストの存在領域の面積（渋谷区の面積）に対する、（ｎ－１）番目リクエスト時の移動可能範囲に含まれるｎ番目リクエストの存在領域の面積（渋谷区全体の面積）の割合は、１００％である。したがって、ｎ番目のリクエストにおいてプライバシ侵害はない。

この場合、図８のステップＳ６４では、図１６（ａ）に示すように、ダミー領域生成部２８が、ｎ番目のリクエスト時の存在領域（渋谷区）に杉並区を追加する。これによりｎ番目のリクエスト時の移動可能範囲（太実線で囲まれた範囲）の大きさが図１５（ｂ）よりも大きくなるため、（ｎ－１）番目のリクエスト時の存在可能範囲が黒塗りで示すように大きくなる。ただし、この段階では、（ｎ－１）番目のリクエスト時の存在可能範囲（黒塗りの範囲）の面積が世田谷区全体の面積の７０％を超えていないため、ステップＳ６６の判断は否定され、ステップＳ６４に戻る。

そして、ステップＳ６４では、図１６（ｂ）に示すように、ダミー領域生成部２８が、ｎ番目のリクエスト時の存在領域（ここでは、渋谷区と杉並区）に目黒区を追加する。これによりｎ番目のリクエスト時の移動可能範囲（太実線で囲まれた範囲）の大きさが図１６（ａ）よりも大きくなるため、（ｎ－１）番目のリクエスト時の存在可能範囲が黒塗りで示すように大きくなる。この場合、（ｎ－１）番目のリクエスト時の存在可能範囲（黒塗りの範囲）の面積が世田谷区全体の面積の７０％を超えていれば、ステップＳ６６の判断は肯定され、図６のステップＳ２０に移行する。

ステップＳ２０に移行すると、領域統合部３０は、存在領域（渋谷区）の情報と、ダミー領域（杉並区、目黒区）の情報とを統合し、リクエスト送信部３２に送信する。その後は、ステップＳ２２～Ｓ２８の処理を前述したのと同様に実行する。

なお、上記処理により、（ｎ－１）番目のリクエスト時の存在可能範囲は変化するため、リクエスト済み領域情報ログ４２の（ｎ－１）番目のリクエストの存在可能範囲の情報は更新される。

次に、（ｎ－１）番目のリクエスト及びｎ番目のリクエストの両方においてプライバシ侵害がある場合の例について説明する。

図１７（ａ）には、（ｎ－１）番目のリクエスト時の存在領域が渋谷区であり、ｎ番目のリクエスト時の存在領域が豊島区である場合を示している。この場合、図１７（ａ）において太実線で示す範囲が、ｎ番目リクエスト時の移動可能範囲であり、破線で示す範囲が、（ｎ－１）番目リクエスト時の移動可能範囲である。

図１７（ａ）においては、（ｎ－１）番目リクエスト時の存在可能範囲（渋谷区内の存在可能範囲）及びｎ番目リクエスト時の存在可能範囲（豊島区内の存在可能範囲）にハッチングが付されている。図１７（ａ）からわかるように、（ｎ－１）番目リクエスト時の存在可能範囲は、渋谷区全体の面積の７０％以上ではなく、ｎ番目リクエスト時の存在可能範囲は、豊島区全体の面積の７０％以上ではない。

この場合、ダミー領域生成部２８が、図１７（ｂ）に示すようにｎ番目リクエスト時の存在領域（豊島区）に新宿区を追加すると、ｎ番目リクエスト時の移動可能範囲が図１７（ａ）よりも広がる。このとき、ｎ番目のリクエスト時の存在可能範囲は、図１８（ａ）に示す黒塗りの領域となり、当該存在可能範囲は、豊島区全体の面積の７０％以上となる。また、（ｎ－１）番目のリクエスト時の存在可能範囲は、図１８（ｂ）に示す黒塗りの領域となり、当該存在可能範囲は、渋谷区全体の面積の７０％以上となる。したがって、本例では、ダミー領域生成部２８は、新宿区をダミー領域とすることで、プライバシが侵害されるのを防止することができる。

なお、上記処理により、（ｎ－１）番目のリクエスト時の存在可能範囲は変化するため、リクエスト済み領域情報ログ４２の（ｎ－１）番目のリクエストの存在可能範囲の情報は更新される。

なお、図６の処理を繰り返す場合、個人データ管理サーバ２０では、（ｎ＋１）番目のリクエストがあると、ｎ番目のリクエストを送信する際に求めた存在可能範囲をｎ番目のリクエスト時の存在領域として扱って、上記と同様の処理を実行するものとする。

これまでの説明からわかるように、本実施形態では、ダミー領域生成部２８、領域統合部３０、及びリクエスト送信部３２により、プライバシ保護条件を満たしていない場合に、ｎ番目のリクエスト時の存在領域と、該存在領域以外のダミー領域とを、リクエストとともにサービス提供装置１０に送信する送信部としての機能が実現されている。

以上、詳細に説明したように、本実施形態によると、プライバシ侵害判定部２６は、ユーザ端末７０の位置検出装置１８９が第１の時刻（ｎ番目のリクエスト時）に検出した位置を含む存在領域（第１の領域）の情報と、第１の時刻よりも前の第２の時刻（（ｎ－１）番目のリクエスト時）に検出した位置を含む存在領域（第２の領域）の情報と、の組み合わせからｎ番目のリクエスト時におけるユーザ端末７０の存在可能範囲及び（ｎ－１）番目のリクエスト時におけるユーザ端末７０の存在可能範囲を特定し（Ｓ３８、Ｓ４８）、各存在可能範囲が、プライバシ保護条件（予め定められている第三者に知られてもよい存在可能範囲の条件）を満たしているか否かを判断する。そして、ダミー領域生成部２８は、プライバシ保護条件を満たしていない場合に、ｎ番目のリクエスト時の存在領域以外の領域をダミー領域とし、リクエスト送信部３２は、領域統合部３０が統合した存在領域とダミー領域（第３の領域）を、リクエストとともにサービス提供装置１０に送信する。また、サービス情報受信部３４は、サービス提供装置１０から存在領域とダミー領域に関連する情報を受信する。これにより、本実施形態では、ｎ番目のリクエスト時の存在領域と（ｎ－１）番目のリクエスト時の存在領域とを組み合わせて解析するとプライバシが侵害されてしまうような場合に、存在領域とダミー領域とを送信することで、存在領域に関連する情報を取得する際のプライバシ侵害を抑制することができる。また、本実施形態では、例えば、プライバシの侵害を回避するために位置情報を更に広い範囲で抽象化する場合と比べ、サービス提供装置１０から受信する情報量の増加を抑制することができる。また、本実施形態では、ユーザ端末７０の存在領域の情報をサービス提供装置１０にリアルタイムに送信することができるため、ユーザ端末７０では、存在領域に関連する情報をリアルタイムに取得することが可能である。

また、本実施形態では、ダミー領域生成部２８は、ｎ番目のリクエストを送信する前に、ｎ番目のリクエスト時の存在領域とダミー領域とを送信することで、プライバシ保護条件がクリアできることを確認している（Ｓ６６）。これにより、確実にプライバシ侵害を防止することができる。

また、本実施形態では、プライバシ保護条件をクリアできるまで、ダミー領域を１つずつ追加することとしている（Ｓ６４、Ｓ６６）。これにより、送信するダミー領域を必要最小限とすることができる。また、送信するダミー領域を必要最小限とすることで、サービス提供装置１０から受信するダミー領域に関連する情報の量を低減することができる。

また、本実施形態では、サービス情報選択部３６は、サービス提供装置１０から受信した情報から存在領域に関連する情報を選択して、ユーザ端末７０に送信することとしている。これにより、ユーザ端末７０では、サービス提供装置１０が提供する情報の質を低下させることなく、ユーザのプライバシを保護することができる。

なお、上記実施形態では、存在可能範囲がプライバシ保護条件を満たしているか否かを判断する場合に、存在可能範囲の面積に基づいて判断する場合について説明したが、これに限られるものではない。例えば、存在可能範囲に含まれる道路の長さに基づいて、プライバシ保護条件を満たしているか否かを判断することとしてもよい。この場合、プライバシ侵害判定部２６は、存在領域に含まれる全道路の長さに対する、存在可能範囲に含まれる道路の長さが所定割合以上である場合や、存在可能範囲に含まれる道路の長さが所定以上である場合に、プライバシ保護条件を満たしていると判断することができる。また、例えば、存在可能範囲に含まれる地名の数に基づいて、プライバシ保護条件を満たしているか否かを判断することとしてもよい。この場合、プライバシ侵害判定部２６は、存在領域に含まれる全地名の数に対する、存在可能範囲に含まれる地名の数が所定割合以上である場合や、存在可能範囲に含まれる地名の数が所定以上である場合に、プライバシ保護条件を満たしていると判断することができる。また、例えば、存在可能範囲に含まれるランドマークの数に基づいて、プライバシ保護条件を満たしているか否かを判断することとしてもよい。この場合、プライバシ侵害判定部２６は、存在領域に含まれる全ランドマークの数に対する、存在可能範囲に含まれるランドマークの数が所定割合以上である場合や、存在可能範囲に含まれるランドマークの数が所定以上である場合に、プライバシ保護条件を満たしていると判断することができる。

なお、上記実施形態では、ユーザの移動方法を特定又は限定することができる場合には、特定又は限定された移動方法を考慮して、移動可能範囲（図９（ａ）の破線で囲まれた範囲、図１０（ａ）の太実線で囲まれた範囲など）を求めることとしてもよい。例えば、ユーザが車で移動していることが分かっている場合には、時速５０ｋｍで移動するという条件で移動可能範囲を求めるようにしてもよい。また、ユーザが徒歩で移動していることが分かっている場合には時速４ｋｍ、ユーザが電車で移動していることが分かっている場合には時速１１０ｋｍで移動するという条件で移動可能範囲を求めることとしてもよい。なお、ユーザの移動方法を特定できない場合には、選択可能な移動方法のうち最も速い速度で移動していると仮定して、移動可能範囲を求めることとしてもよい。

また、上記実施形態では、移動方法に応じて、ユーザが移動可能な範囲を制限してもよい。例えば、ユーザが車で移動していることが分かっている場合には、移動可能範囲を車道が繋がっている範囲に限定してもよい。また、ユーザが徒歩で移動していることが分かっている場合には、徒歩で立ち入り可能な範囲に限定してもよい。なお、ユーザの移動方法は、例えばユーザ端末７０が有する加速度センサで検出される振動に基づいて特定してもよいし、ユーザがユーザ端末７０に対して移動方法の情報を入力するようにしてもよい。

なお、上記実施形態の個人データ管理サーバ２０では、図１９に示すように、サービス情報選択部３６がユーザ端末７０に送信しなかった情報（すなわち、ダミー領域の情報）を記憶する記憶部としての情報記憶部５２を有していてもよい。この場合、位置情報取得部２２は、ユーザ端末７０の現在位置を受信したときに、受信した現在位置に関連する情報が情報記憶部５２に記憶されているか否かを確認する。そして、現在位置に関連する情報が情報記憶部５２に記憶されていた場合には、位置情報取得部２２からサービス情報選択部３６にその旨を通知する。サービス情報選択部３６は、この通知を受けた場合には、情報記憶部５２から現在位置に関連する情報を読み出し、ユーザ端末７０に送信する。このようにすることで、個人データ管理サーバ２０とサービス提供装置１０との間の通信回数を減らすことが可能となる。なお、情報は時々刻々と変化するため、データベースにおいては、情報を記憶した日時を管理しておき、データベースに記憶してから所定時間が経過したときに情報を破棄するようにすることが好ましい。なお、図１９の例において、ダミー領域を選定する場合（図８のＳ６４、Ｓ６６）には、ユーザ端末７０の移動方向（又は今後移動するであろう方向）を考慮することとしてもよい。この場合、ユーザ端末７０の移動方向に基づいて、移動方向に沿って存在する領域（例えば市区町村）を優先的にダミー領域として設定することとしてもよい。これにより、今後利用される可能性の高い情報を情報記憶部５２に記憶しておく（プリキャッシュしておく）ことができるようになる。

なお、上記実施形態では、図３に示すように、個人データ管理サーバ２０がサービス情報選択部３６を有する場合について説明したが、これに限られるものではない。例えば、図２０に示すように、個人データ管理サーバ２０のサービス情報選択部３６を省略し、サービス情報選択部３６と同様の機能のサービス情報選択部３６’をユーザ端末７０’に持たせてもよい。

また、上記実施形態では、図１や図３に示すように、情報処理システム１００が個人データ管理サーバ２０を有する場合について説明したが、これに限られるものではない。すなわち、図２１に示すように、情報処理システム１００から個人データ管理サーバ２０を省略し、個人データ管理サーバ２０の機能を有するユーザ端末７０”を用いることとしてもよい。なお、ユーザ端末７０”の位置情報取得部２２は、図２（ａ）の位置検出装置１８９から位置情報を取得する。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定する特定部と、
前記特定部が特定した前記存在可能な範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断する判断部と、
前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信する送信部と、
前記外部装置から前記第３の領域に関連する情報を受信する受信部と、
を備える情報処理装置。
（付記２） 前記判断部は、前記特定部が特定した存在可能範囲の面積が前記条件を満たしているか否か、前記特定部が特定した存在可能範囲に含まれる道路の長さが前記条件を満たしているか否か、前記特定部が特定した存在可能範囲に含まれる地名の数が前記条件を満たしているか否か、及び前記特定部が特定した存在可能範囲に含まれる予め定められているランドマークの数が前記条件を満たしているか否か、の少なくとも１つの判断を行う、
ことを特徴とする付記１に記載の情報処理装置。
（付記３） 前記第３の領域の情報と、前記第２の領域の情報との組み合わせから特定される、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び／又は、前記第２の時刻において前記位置検出装置が存在可能な範囲は、前記条件を満たす、
ことを特徴とする付記１又は２に記載の情報処理装置。
（付記４） 前記送信部は、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲が前記条件を満たすまで、前記第１の領域以外の領域を１つずつ追加して前記第３の領域を決定する、
ことを特徴とする付記３に記載の情報処理装置。
（付記５） 前記第１の領域以外の領域を前記第３の領域に追加する順は、前記位置検出装置の移動方向に基づく順である、ことを特徴とする付記４に記載の情報処理装置。
（付記６） 前記特定部は、予め設定されている移動方法に基づいて、前記存在可能な範囲を特定する、ことを特徴とする付記１～５のいずれかに記載の情報処理装置。
（付記７） 前記受信部が受信した前記第３の領域に関連する情報から、前記第１の領域に関連する情報を選択する選択部を更に備える付記１～６のいずれかに記載の情報処理装置。
（付記８） 前記第３の領域に関連する情報のうち、前記第１の領域に関連する情報以外の情報を記憶する記憶部を更に備える付記７に記載の情報処理装置。
（付記９） 位置検出装置を有する端末と、
前記端末から、前記位置検出装置が検出した位置の情報を取得する情報処理装置と、を備え、
前記情報処理装置は、
前記位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定する特定部と、
前記特定部が特定した存在可能範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断する判断部と、
前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信する送信部と、
前記外部装置から前記第３の領域に関連する情報を受信する受信部と、
を有することを特徴とする情報処理システム。
（付記１０） 位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定し、
特定した前記存在可能な範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断し、
前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信し、
前記外部装置から前記第３の領域に関連する情報を受信する、
処理をコンピュータに実行させるためのプライバシ保護プログラム。
（付記１１） 前記判断する処理では、前記特定する処理で特定した存在可能範囲の面積が前記条件を満たしているか否か、前記特定する処理で特定した存在可能範囲に含まれる道路の長さが前記条件を満たしているか否か、前記特定する処理で特定した存在可能範囲に含まれる地名の数が前記条件を満たしているか否か、及び前記特定する処理で特定した存在可能範囲に含まれる予め定められているランドマークの数が前記条件を満たしているか否か、の少なくとも１つの判断を行う、
ことを特徴とする付記１０に記載のプライバシ保護プログラム。
（付記１２） 前記第３の領域の情報と、前記第２の領域の情報との組み合わせから特定される、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び／又は、前記第２の時刻において前記位置検出装置が存在可能な範囲は、前記条件を満たす、
ことを特徴とする付記１０又は１１に記載のプライバシ保護プログラム。
（付記１３） 前記送信する処理では、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲が前記条件を満たすまで、前記第１の領域以外の領域を１つずつ追加して前記第３の領域を決定する、
ことを特徴とする付記１２に記載のプライバシ保護プログラム。
（付記１４） 前記第１の領域以外の領域を前記第３の領域に追加する順は、前記位置検出装置の移動方向に基づく順である、ことを特徴とする付記１３に記載のプライバシ保護プログラム。
（付記１５） 前記特定する処理では、予め設定されている移動方法に基づいて、前記存在可能な範囲を特定する、ことを特徴とする付記１０～１４のいずれかに記載のプライバシ保護プログラム。
（付記１６） 前記受信する処理で受信した前記第３の領域に関連する情報から、前記第１の領域に関連する情報を選択する処理を、前記コンピュータが更に実行することを特徴とする付記１０～１５のいずれかに記載のプライバシ保護プログラム。
（付記１７） 前記第３の領域に関連する情報のうち、前記第１の領域に関連する情報以外の情報を記憶部に記憶する処理を前記コンピュータが更に実行することを特徴とする付記１６に記載のプライバシ保護プログラム。

１０ サービス提供装置（外部装置）
２０ 個人データ管理サーバ（情報処理装置）
２６ プライバシ侵害判定部（特定部、判断部）
２８ ダミー領域生成部（送信部の一部）
３０ 領域統合部（送信部の一部）
３２ リクエスト送信部（送信部の一部）
３４ サービス情報受信部（受信部）
３６ サービス情報選択部（選択部）
５２ 情報記憶部（記憶部）
７０ ユーザ端末（端末）
１００ 情報処理システム
１８９ 位置検出装置

Claims (10)

1. 位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定する特定部と、
   前記特定部が特定した前記存在可能な範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断する判断部と、
   前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信する送信部と、
   前記外部装置から前記第３の領域に関連する情報を受信する受信部と、
   を備える情報処理装置。
2. 前記判断部は、前記特定部が特定した存在可能範囲の面積が前記条件を満たしているか否か、前記特定部が特定した存在可能範囲に含まれる道路の長さが前記条件を満たしているか否か、前記特定部が特定した存在可能範囲に含まれる地名の数が前記条件を満たしているか否か、及び前記特定部が特定した存在可能範囲に含まれる予め定められているランドマークの数が前記条件を満たしているか否か、の少なくとも１つの判断を行う、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第３の領域の情報と、前記第２の領域の情報との組み合わせから特定される、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び／又は、前記第２の時刻において前記位置検出装置が存在可能な範囲は、前記条件を満たす、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記送信部は、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲が前記条件を満たすまで、前記第１の領域以外の領域を１つずつ追加して前記第３の領域を決定する、
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記第１の領域以外の領域を前記第３の領域に追加する順は、前記位置検出装置の移動方向に基づく順である、ことを特徴とする請求項４に記載の情報処理装置。
6. 前記特定部は、予め設定されている移動方法に基づいて、前記存在可能な範囲を特定する、ことを特徴とする請求項１～５のいずれか一項に記載の情報処理装置。
7. 前記受信部が受信した前記第３の領域に関連する情報から、前記第１の領域に関連する情報を選択する選択部を更に備える請求項１～６のいずれか一項に記載の情報処理装置。
8. 前記第３の領域に関連する情報のうち、前記第１の領域に関連する情報以外の情報を記憶する記憶部を更に備える請求項７に記載の情報処理装置。
9. 位置検出装置を有する端末と、
   前記端末から、前記位置検出装置が検出した位置の情報を取得する情報処理装置と、を備え、
   前記情報処理装置は、
   前記位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定する特定部と、
   前記特定部が特定した存在可能範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断する判断部と、
   前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信する送信部と、
   前記外部装置から前記第３の領域に関連する情報を受信する受信部と、
   を有することを特徴とする情報処理システム。
10. 位置検出装置が第１の時刻に検出した位置を含む第１の領域の情報と、前記位置検出装置が前記第１の時刻よりも前の第２の時刻に検出した位置を含み、前記第２の時刻に前記位置検出装置が存在する領域の情報として外部装置に対して既に送信している第２の領域の情報と、の組み合わせから、前記第１の時刻において前記位置検出装置が存在可能な範囲、及び、前記第２の時刻において前記位置検出装置が存在可能な範囲を特定し、
    特定した前記存在可能な範囲が、予め定められている第三者に知られてもよい存在可能範囲の条件を満たしているか否かを判断し、
    前記条件を満たしていない場合に、前記第１の領域の情報と前記第１の領域以外の領域とを含む第３の領域の情報を、前記第１の時刻に前記位置検出装置が存在する領域の情報として前記外部装置に対して送信し、
    前記外部装置から前記第３の領域に関連する情報を受信する、
    処理をコンピュータに実行させるためのプライバシ保護プログラム。

Images