JP5454262B2 - プライバシー保護装置、プライバシー保護方法、プライバシー保護プログラム、及びライフログ管理システム - Google Patents

Description

本発明は、個人情報の提供におけるプライバシー保護技術に関する。

近年、ＧＰＳ等の各種センサーを内蔵した携帯電話の普及により、ユーザの位置情報や購買履歴等の日々の行動履歴（ライフログ）をリアルタイムにサーバ側で収集することが可能となってきている。また、これらのサーバ側で収集した情報を利用することで、ユーザの位置や嗜好に基づいてお勧め情報をユーザに配信するレコメンドサービス等が実現されつつある。

一方、サーバ側で収集したこれらライフログ情報をサービサに提供する上で、提供した情報から個人が特定されないようにプライバシーを保護することが求められている。これに対して、サービサから個人情報取得要求（位置情報等の要求）を受けた際に、その属性値を持っているユーザが少なくともＫ人以上いる場合（Ｋ−匿名性を満たす場合）のみ所望の情報を提供することで、人数が少ないことによるプライバシーリスクを解決する手法が提案されている（例えば、特許文献１参照）。

特開２００５−２３４８６６号公報

しかしながら、上記した手法は、サービサ側がライフログ管理サーバに対して、検索要求を行ったとき、Ｋ−匿名性を満たしている場合に所望の情報を受け取る方法であるため、サービサが位置情報のように動的に変化する情報を基にタイムリーな推薦を行おうとする場合は、一定間隔で検索を行う等の処理が必要である。検索の間隔を広げるとタイムリーな推薦が行えず、一方で、検索の間隔を狭めると処理負荷が増大するという問題がある。

これに対して、検索の条件を事前にサーバに登録しておき、動的に変化する情報が登録した条件に一致した場合にのみ、サーバからサービサにライフログを通知する(Ｓｕｂｓｃｒｉｂｅ／Ｎｏｔｉｆｙモデル)方法が考えられる。本モデルでは、上記Ｋ−匿名性の保障を行う場合、Ｋ人以上いることの判断をいつ行うかによって下記の問題が発生する。

まず、通知条件を登録する際に判定する場合(Ｓｕｂｓｃｒｉｂｅ時)、位置情報等の頻繁に変化する属性を条件設定（例：現在位置が品川駅の場合等）する場合は、たまたまそのときにその条件を満たしている人数が少なかった場合に登録自体ができなくなる。

また、通知条件が一致して、実際にサービサにライフログを通知する場合（Ｎｏｔｉｆｙ時）、Ｓｕｂｓｃｒｉｂｅ時に条件を満たすユーザ数がＫ人未満で、かつ、指定した条件の属性がほとんど頻繁に変化しない属性の場合（例：性別や住所等）は、半永久的にＮｏｔｉｆｙがサービサに通知されなくなるため、サービサ側は、無意味な条件を設定していることが分からない。

そこで、本発明では、Ｓｕｂｓｃｒｉｂｅ／ＮｏｔｉｆｙモデルにおけるＫ−匿名性保護を実現することを目的とする。

上記の目的を達成するために、以下に開示するプライバシー保護装置は、ユーザの情報を収集してライフログとして蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログをサービサに通知するライフログ管理システムにおけるプライバシー保護装置であって、ユーザのライフログが蓄積されるのに応じて、当該ライフログを構成する各属性の更新頻度を算出して記録する属性更新頻度管理部と、サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、前記属性更新頻度管理部が記録する更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する静的属性抽出部と、前記静的属性抽出部が抽出した静的属性について、通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が前記限界人数を超えているときに、通知依頼の登録をサービサから受け付ける通知依頼受付部とを備える。

上記の構成によれば、Ｓｕｂｓｃｒｉｂｅ／ＮｏｔｉｆｙモデルにおけるＫ−匿名性保護を実現することができる。

本発明の実施形態１に係るライフログ管理システムと当該システムにおけるプライバシー保護装置の構成の一例を示すブロック図 本発明の実施形態１におけるＳｕｂｓｃｒｉｂｅ時の処理の一例を示すフロー図 ライフログの一例を示す図 通知依頼登録ＤＢの一例を示す図 属性更新頻度ＤＢの一例を示す図 Ｓｕｂｓｃｒｉｂｅ要求の一例を示す図 本発明の実施形態１におけるユーザのライフログ更新時の処理の一例を示すフロー図 サービサに通知される通知情報の一例を示す図 本発明の実施形態１におけるＵｎｓｕｂｓｃｒｉｂｅ時の処理の一例を示すフロー図 本発明の実施形態２に係るライフログ管理システムと当該システムにおけるプライバシー保護装置の構成の一例を示すブロック図 本発明の実施形態２におけるＳｕｂｓｃｒｉｂｅ時の処理の一例を示すフロー図 通知依頼登録履歴ＤＢの一例を示す図 本発明の実施形態２におけるユーザのライフログ更新時の処理の一例を示すフロー図 本発明の実施形態２におけるＵｎｓｕｂｓｃｒｉｂｅ時の処理の一例を示すフロー図

本発明の実施形態について、図面を用いて詳細に説明する。
[実施形態１]
図１は、本発明の実施形態１に係るライフログ管理システム１の構成を示すブロック図である。ライフログ管理システム１には、本発明のプライバシー保護装置２が搭載されている。本システムは、ユーザの情報を収集してライフログとしてユーザライフログＤＢ３００に蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログをユーザライフログＤＢ３００から抽出してサービサに通知する。ユーザライフログＤＢ３００に記録されるライフログは、ユーザの行動履歴や性質、特徴等を表すデータであり、少なくとも１つの属性の情報を含む。ライフログは、例えば、図３に示すように、ユーザＩＤ、更新時刻、性別、住所、趣味、現在地を含むデータである。

図１において、ライフログ管理システム１は、通知依頼受付部１１０、属性更新頻度管理部１２０、静的属性抽出部１３０、プライバシー保護装置、匿名性判定部１４０、通知依頼登録ＤＢ１５０、情報登録部１６０、通知条件判定部１７０、通知保留データ管理部１８０、通知部１９０、ユーザライフログＤＢ３００を備える。このうち、本実施例では、プライバシー保護装置２は、通知依頼受付部１１０、属性更新頻度管理部１２０、及び静的属性抽出部１３０を備えるものとする。

なお、ライフログ管理システム１およびプライバシー保護装置２の構成は、図１に示す例に限られない。例えば、プライバシー保護装置２が、匿名性判定部１４０等、その他の機能を含む構成であってもよい。接続された２台のコンピュータに、プライバシー保護装置２と、ライフログ管理システム１のその他の機能がそれぞれ設けられる構成であってもよい。また、プライバシー保護装置２とライフログ管理システム１の機能は、複数のコンピュータに分散して構成されてもよい。

通知依頼受付部１１０は、通知依頼登録（以下、Ｓｕｂｓｃｒｉｂｅと称する）をサービサから受け付ける。例えば、通知依頼受付部１１０は、ユーザのライフログがサービサに通知されるときに、ユーザのライフログの各属性が満たすべき通知条件、通知先、及びサービサのサービス有効期間を含むＳｕｂｓｃｒｉｂｅをサービサから受け付けることができる。なお、通知依頼受付部１１０は、後述する匿名性判定部１４０が、静的属性について、通知条件を満たすユーザ数が限界人数を超えると判定したとき、通知依頼登録ＤＢ１５０にＳｕｂｓｃｒｉｂｅの登録を行う。Ｓｕｂｓｃｒｉｂｅの登録は、例えば、図４に示すように、通知依頼登録ＤＢ１５０に、ＳｕｂＩＤ、登録時刻、通知条件、及び通知先ＵＲＬを含むデータが登録されることによって行われる。

属性更新頻度管理部１２０は、ユーザのライフログの更新に基づいて、当該ライフログを構成する各属性の更新頻度を算出して記録する。例えば、属性更新頻度管理部１２０は、属性更新頻度ＤＢ（図示せず）に、図５に示すように、属性と更新頻度（例えば、１日あたりの更新人数）とを関連付けて記録する。

静的属性抽出部１３０は、サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、属性更新頻度管理部１２０が管理する更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する。

例えば、静的属性抽出部１３０は、予め定められた限界人数をサービサのサービス有効期間で割って算出された値を変更頻度の閾値とする。属性更新頻度管理部１２０が管理する更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出することができる。

匿名性判定部１４０は、静的属性抽出部１３０が抽出した静的属性について、登録を受け付けた通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が限界人数を超えていることを判定する。これによって、通知条件に従ってサービサへ通知されるべき情報が、匿名性を満足する可能性があるか否か判定することができる。

例えば、匿名性判定部１４０は、静的属性抽出部１３０が抽出した静的属性について、サービサからのＳｕｂｓｃｒｉｂｅの通知条件を満たすユーザ数を抽出する。抽出されたユーザ数が限界人数を超えていると判定したときに、匿名性の満足の可能性があることを判定できる。

情報登録部１６０は、ユーザの通信機器からライフログの更新登録を受け付ける。ユーザの通信機器には、例えば、携帯電話、パソコン、ＰＤＡ等が用いられる。ユーザは、情報登録部１６０を介して、ライフログを新規に追加する。

通知条件判定部１７０は、ユーザのライフログが新規に追加された場合に、追加されたユーザのライフログが、登録を受け付けた通知依頼についての通知条件を満たすかどうかを判定し、通知条件を満たすと判定された場合、当該通知条件を満たす他のユーザを抽出し、抽出されたユーザ数が限界人数に達していない場合に、サービサへのライフログに関するデータの通知を保留して、保留したライフログを通知保留データ管理部１８０に登録する。

通知条件判定部１７０は、ユーザのライフログが新規に追加された場合に、追加されたユーザのライフログが、登録を受け付けた通知依頼についての通知条件を満たすかどうかを判定し、通知条件を満たすと判定された場合、当該通知条件を満たす他のユーザを抽出し、抽出されたユーザ数が限界人数に達している場合に、通知部１９０を介してライフログに関するデータをサービサに通知する。

なお、通知条件判定部１７０は、上記した２つの処理のうち、少なくとも一方の処理を行えばよい。

通知保留データ管理部１８０は、サービサへの通知が保留されたライフログに関するデータを格納する。保留されたライフログに関するデータは、通知条件判定部１７０によって通知条件を満たすユーザ数が限界人数に達したと判断されると、通知部１９０によってサービサへ通知される。

通知部１９０は、通知条件判定部１７０の処理に従って、サービサへのライフログに関するデータの通知（Ｎｏｔｉｆｙ）を行う。なお、本実施形態では、サービサへ通知する情報は、ライフログに限られない。ライフログの一部や、ライフログを加工したデータを通知することもできるし、その他のユーザに関連する情報をさらに通知することもできる。

以下、本発明の実施形態１におけるＳｕｂｓｃｒｉｂｅ時の処理について、図２のフロー図に従って説明する。なお、本実施形態１では、サービスの有効期間をサービサ側がＳｕｂｓｃｒｉｂｅ時に指定する構成で説明する。

まず、通知依頼受付部１１０は、Ｓｕｂｓｃｒｉｂｅを受け付ける。ここでは、通知依頼受付部１１０は、例えば、図６に示すように、サービサから、「通知条件：性別＝女性＆住所＝大久保＆位置＝三宮」とともに「通知先ＵＲＬ：ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ」とサービス有効期間「７日」を示すＳｕｂｓｃｒｉｂｅを受け付けたとする（ステップＳ２０１→Ｓ２０２）。

次に、静的属性抽出部１３０は、有効期間７日から１日あたりの変更頻度の閾値を算出する。例えば、静的属性抽出部１３０は、限界人数Kが１００人の場合（本実施形態では、限界人数を１００人とする）、１００／７＝３３人が変更頻度の閾値となる（ステップＳ２０３）。

静的属性抽出部１２０は、条件指定された属性の中（性別、住所、位置）で、上記閾値(３３人)以下の更新頻度の属性を更新頻度管理部１２０から抽出する。例えば、図５に示す例では、静的属性として性別、住所を抽出したとする（ステップＳ２０４）。

次に、匿名性判定部１４０は、静的属性の通知条件である、「性別＝女性＆住所＝大久保」を受け取る。匿名性判定部１４０は、ライフログを参照して、静的属性の通知条件を満たす他のユーザを検索し、ユーザの人数を取得する（ステップＳ２０５）。

次に、匿名性判定部１４０は、取得できた人数が限界人数１００人を超えているかどうかを判定する（ステップＳ２０６）。

ステップＳ２０６において、超えていると判定された場合、通知依頼受付部１１０は、Ｓｕｂｓｃｒｉｂｅ要求を受理して、ＳｕｂＩＤを生成し、通知依頼登録ＤＢ１５０にＳｕｂｓｃｒｉｂｅ情報と共にＳｕｂＩＤを登録する（ステップＳ２０７）。そして、通知依頼受付部１１０は、サービサにＳｕｂＩＤを返却する（ステップＳ２０８）。一方、ステップＳ２０５において、超えてないと判定された場合は、通知依頼受付部１１０は、サービサに登録エラーを返却する（ステップＳ２０６→Ｓ２０９）。

これにより、静的属性を用いて判断することにより、Ｓｕｂｓｃｒｉｂｅ時に、位置情報等の頻繁に変化する属性を条件設定する場合でも、登録自体ができなくなるということを回避できる。

以下、本発明の実施形態１におけるユーザのライフログ更新時の処理について、図７のフロー図に従って説明する。

まず、ユーザの携帯端末から属性更新（ユーザID=ＵｓｅｒＡ&現在地=三宮）の要求を受け付けたとする（ステップＳ７０１→Ｓ７０２）。

次に、情報登録部１６０は、該当ユーザ（ＵｓｅｒＡ）のライフログに現在時刻と現在地を登録する（ステップＳ７０３）。

情報登録部１６０は、属性更新頻度管理部１２０に属性更新通知(現在地属性が変更)を行う。属性更新頻度管理部１２０は、更新された属性の更新頻度を更新する（ステップＳ７０４）。

次に、情報登録部１６０は、通知条件判定部１７０に通知判定依頼を行う。通知条件判定部１５０は、通知依頼登録ＤＢ１５０からＳｕｂｓｃｒｉｂｅ情報として、Ｓｕｂｓｃｒｉｐｔｉｏｎリストを取得する（ステップＳ７０５）。Ｓｕｂｓｃｒｉｐｔｉｏｎリストは、例えば、図４に示すように、各Ｓｕｂｓｃｒｉｂｅをリスト化したものである。

次に、通知条件判定部１７０は、ＵｓｅｒＡのライフログと通知条件が一致しているＳｕｂｓｃｒｉｐｔｉｏｎ（ここでは、ＳｕｂＩＤ：００１−２２３、通知条件：「ユーザID=ＵｓｅｒＡ&現在地＝三宮」）を取り出したとする（ステップＳ７０６）。

次に、通知条件判定部１７０は、ライフログを参照して、通知条件に一致したＳｕｂｓｃｒｉｐｔｉｏｎの全属性の通知条件を満たす他のユーザを検索し、ユーザの人数を取得する（ステップＳ７０７）。

次に、通知条件判定部１７０は、ＳｕｂＩＤ００１−２２３の通知条件がK−匿名性を満足しているかどうかを判定するため、匿名性判定部１４０に依頼する。匿名性判定部１４０は、通知条件に一致したＳｕｂｓｃｒｉｐｔｉｏｎの全属性の通知条件を満たすユーザの人数が限界人数１００人を超えているか否かを判定することによって、Ｋ−匿名性を満足しているか否かを判定する（ステップＳ７０８）。

ステップＳ７０８において、K−匿名性を満足していない場合（限界人数１００人を超えていない場合）、匿名性判定部１４０は、ＳｕｂＩＤをキーにして、通知保留データ管理部１８０に通知情報を登録する（ステップＳ７０９）。

一方、ステップＳ７０８において、K−匿名性を満足している場合（限界人数１００人を超えている場合）、匿名性判定部１４０は、通知保留データ管理部１８０から保留中のＳｕｂＩＤ００１−２２３に関する通知情報を取り出し、通知部１９０に通知処理を依頼する（Ｎｏｔｉｆｙ）。

通知部１９０は、この通知処理の依頼に基づいて、該当するサービス（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）に対して、通知情報を送信する（ステップＳ７０８→Ｓ７１０）。例えば、図８に示すように、ＳｕｂＩＤ＝００１−２２３、ユーザＩＤ＝ＵｓｅｒＡ、通知条件：性別＝女性&住所＝大久保&位置＝三宮が通知情報としてサービサに提供される。

これにより、Ｓｕｂｓｃｒｉｂｅ時に、条件を満たすユーザ数がＫ人を超えているときに通知依頼を登録することにより、指定した条件の属性がほとんど頻繁に変化しない属性の場合でも、半永久的にＮｏｔｉｆｙがサービサに通知されなくなるということを回避できる。

なお、通知依頼削除（Ｕｎｓｕｂｓｃｒｉｂｅ）時は、図９のフロー図に示すように、通知依頼受付部１１０は、Ｕｎｓｕｂｓｃｒｉｂｅ依頼を受付け（ステップＳ９０１→Ｓ９０２）、該当するＳｕｂＩＤに対応するＳｕｂｓｃｒｉｂｅ情報を通知依頼登録ＤＢから削除する（ステップＳ９０３）。
[実施形態２]
本実施形態２では、サービスの有効期間をサービサが指定するのではなく、サービサの通知依頼登録履歴から自動的に算出する例を示している。本実施形態２では、サービサがＵｎｓｕｂｓｃｒｉｂｅする際に、通知依頼登録ＤＢ１５０から、必要な情報を取得し、Ｓｕｂｓｃｒｉｂｅの期間を算出して、通知依頼登録履歴ＤＢ２１０に記録しておき、次回、同じサービサからＳｕｂｓｃｒｉｂｅを受け付けた場合に、過去のＳｕｂｓｃｒｉｂｅの平均継続時間を算出することで、サービサの有効期間を求めている。なお、本実施例では、サービサの一意性を、通知ＵＲＬによって行っているが、明示的にサービスを識別するＩＤをサービサＩＤとして利用してもよい。

図１０は、本発明の実施形態２に係るライフログ管理システム１の構成を示すブロック図である。プライバシー保護装置２は、実施形態１の構成に、更に、サービス有効期間判定部２００、及び通知依頼登録履歴ＤＢ２１０を備える。なお、実施形態１と同一構成については、同一の符号を付す。

サービサの過去の通知依頼の登録履歴を保持する通知依頼履歴データベース（通知依頼登録履歴ＤＢ２１０）と、新規に通知依頼を登録するサービサについて、通知依頼履歴データベースから対応するサービサの過去の通知依頼の登録履歴を抽出し、当該通知依頼の登録履歴の平均継続時間を算出することによって、当該サービサのサービスの有効期間を算出するサービス有効期間判定部２００を更に備える。

通知依頼登録履歴ＤＢ２１０では、例えば、図１２に示すように、サービスＩＤ、ＳｕｂＩＤ、通知条件、サービスの開始日時、サービスの終了日時、及びサービスの期間を含むデータとして登録される。

サービス有効期間判定部２００は、例えば、サービスＩＤをキーにして、通知依頼登録履歴ＤＢ２１０から該当するＳｕｂｓｃｒｉｐｔｉｏｎを取得し、取得できたＳｕｂｓｃｒｉｐｔｉｏｎの数とそれらのサービスの期間から平均継続時間を算出して、サービス有効期間とし、算出したサービス有効期間を有効期間管理テーブル（図示せず）に記録することができる。

例えば、サービスＩＤ（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）の通知依頼登録履歴を参照すると、ＳｕｂＩＤ００１−３３のサービスの期間が９日、ＳｕｂＩＤ００１−３４のサービスの期間が４日、ＳｕｂＩＤ００１−３５のサービスの期間が８日であることから、（９＋４＋８）／３＝７と算出され、サービスＩＤ（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）のサービス有効期間は、７日となる。また、サービスＩＤ（ｈｔｔｐ：／／ｔａｒｏ．ｃｏｍ／Ｂ）の通知依頼登録履歴を参照すると、ＳｕｂＩＤ００２−１１のサービスの期間が１８１日、ＳｕｂＩＤ００２−５５のサービスの期間が１８２日、ＳｕｂＩＤ００２−２２のサービスの期間が１７９日であることから、（１８１＋１８２＋１７９）／３≒１８０と算出され、サービスＩＤ（ｈｔｔｐ：／／ｔａｒｏ．ｃｏｍ／Ｂ）のサービス有効期間は、１８０日となる。

以下、本発明の実施形態２におけるＳｕｂｓｃｒｉｂｅ時の処理について、図１１のフロー図に従って説明する。

まず、通知依頼受付部１１０は、Ｓｕｂｓｃｒｉｂｅを受け付ける。ここでは、通知依頼受付部１１０は、例えば、実施形態１と同様、サービサから、「通知条件：性別＝女性＆住所＝大久保＆位置＝三宮」とともに「通知先ＵＲＬ：ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ」を示すＳｕｂｓｃｒｉｂｅを受け付けたとする（ステップＳ１１０１→Ｓ１１０２）。

次に、サービス有効期間判定部２００は、通知先ＵＲＬであるサービスＩＤをキーにして、通知依頼登録履歴ＤＢ２１０から該当するＳｕｂｓｃｒｉｐｔｉｏｎを取得し、取得できたＳｕｂｓｃｒｉｐｔｉｏｎの数とそれらのサービスの期間から平均継続時間を算出して、サービス有効期間とする（ステップＳ１１０３）。ここでは、通知先ＵＲＬ（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）の通知依頼登録履歴を参照して、ＳｕｂＩＤ００１−３３（サービスの期間が９日）、ＳｕｂＩＤ００１−３４（サービスの期間が４日）、ＳｕｂＩＤ００１−３５（サービスの期間が８日）から、（９＋４＋８）／３＝７と算出され、通知先ＵＲＬ（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）のサービス有効期間を７日とする。

次に、静的属性抽出部１３０は、算出されたサービス有効期間７日から１日あたりの変更頻度の閾値を算出する（ステップＳ１１０４）。ここでは、静的属性抽出部１３０は、限界人数Kが１００人の場合（実施形態１と同様、限界人数を１００人とする）、１００／７＝３３人が変更頻度の閾値とする。静的属性抽出部１２０は、条件指定された属性の中（性別、住所、位置）で、上記閾値(３３人)以下の更新頻度の属性を更新頻度管理部１２０から抽出し、静的属性として性別、住所を抽出したとする（ステップＳ１１０５）。

次に、匿名性判定部１４０は、静的属性の通知条件である、「性別＝女性＆住所＝大久保」を受け取る。匿名性判定部１４０は、ライフログを参照して、静的属性の通知条件を満たす他のユーザを検索し、ユーザの人数を取得する（ステップＳ１１０６）。

次に、匿名性判定部１４０は、取得できた人数が限界人数１００人を超えているかどうかを判定する（ステップＳ１１０７）。

ステップＳ１１０７において、越えていると判定された場合、通知依頼受付部１１０は、Ｓｕｂｓｃｒｉｂｅ要求を受理して、ＳｕｂＩＤを生成し、通知依頼登録ＤＢ１５０にＳｕｂｓｃｒｉｂｅ情報と共にＳｕｂＩＤを登録する（ステップＳ１１０８）。そして、通知依頼受付部１１０は、サービサにＳｕｂＩＤを返却する（ステップＳ１１０９）。一方、ステップＳ１１０７において、超えてないと判定された場合は、通知依頼受付部１１０は、サービサに登録エラーを返却する（ステップＳ１１０７→Ｓ１１１０）。

以下、本発明の実施形態２におけるユーザのライフログ更新時の処理について、図１３のフロー図に従って説明する。

まず、ユーザの携帯端末の情報登録部１６０が属性更新（ユーザID=ＵｓｅｒＡ&現在地=三宮）の要求を受け付けたとする（ステップＳ１３０１→Ｓ１３０２）。

次に、情報登録部１６０は、該当ユーザ（ＵｓｅｒＡ）のライフログに現在時刻と現在地を登録する（ステップＳ１３０３）。

情報登録部１６０は、属性更新頻度管理部１２０に属性更新通知(現在地属性が変更)を行う。属性更新頻度管理部１２０は、更新された属性の更新頻度を更新する（ステップＳ１３０４）。

次に、情報登録部１６０は、通知条件判定部１７０に通知判定依頼を行う。通知条件判定部１５０は、通知依頼登録DBからＳｕｂｓｃｒｉｂｅ情報として、Ｓｕｂｓｃｒｉｐｔｉｏｎリストを取得する（ステップＳ１３０５）。

次に、通知条件判定部１７０は、ＵｓｅｒＡのライフログと通知条件が一致しているＳｕｂｓｃｒｉｐｔｉｏｎ（ここでは、ＳｕｂＩＤ：００１−２２３、通知条件：「ユーザID=ＵｓｅｒＡ&現在地＝三宮」）を取り出す（ステップＳ１３０６）。

次に、通知条件判定部１７０は、ライフログを参照して、通知条件に一致したＳｕｂｓｃｒｉｐｔｉｏｎの全属性の通知条件を満たす他のユーザを検索し、ユーザの人数を取得する（ステップＳ１３０７）。

次に、通知条件判定部１７０は、ＳｕｂＩＤ００１−２２３の通知条件がK-匿名性を満足しているかどうかを判定するため、匿名性判定部１４０に依頼する。匿名性判定部１４０は、通知条件に一致したＳｕｂｓｃｒｉｐｔｉｏｎの全属性の通知条件を満たすユーザの人数が限界人数１００人を超えているか否かを判定することによって、Ｋ−匿名性を満足しているか否かを判定する（ステップＳ１３０８）。

ステップＳ１３０８において、K−匿名性を満足していない場合（限界人数１００人を超えていない場合）、匿名性判定部１４０は、ＳｕｂＩＤをキーにして、通知保留データ管理部１８０に通知情報を登録する（ステップＳ１３０９）。

一方、ステップＳ１３０８において、K−匿名性を満足している場合（限界人数１００人を超えている場合）、匿名性判定部１４０は、通知保留データ管理部１８０から保留中のＳｕｂＩＤ００１−２２３に関する通知情報を取り出し、通知部１９０に通知処理を依頼する。

通知部１９０は、この通知処理の依頼に基づいて、該当するサービス（ｈｔｔｐ：／／ｈｏｇｅ．ｃｏｍ／Ａ）に対して、通知情報を送信する（ステップＳ１３０８→Ｓ１３１０）。例えば、図８に示すように、ＳｕｂＩＤ＝００１−２２３、ユーザＩＤ＝ＵｓｅｒＡ、通知条件：性別＝女性&住所＝大久保&位置＝三宮が通知情報としてサービサに提供される。

なお、通知依頼削除（Ｕｎｓｕｂｓｃｒｉｂｅ）時は、図１４のフロー図に示すように、通知依頼受付部１１０は、Ｕｎｓｕｂｓｃｒｉｂｅ依頼を受付け（ステップＳ１４０１→Ｓ１４０２）、該当するＳｕｂＩＤに対応するＳｕｂｓｃｒｉｂｅ情報を通知依頼登録ＤＢ１５０から取得する（ステップＳ１４０３）。そして、通知依頼受付部１１０は、取得したＳｕｂｓｃｒｉｂｅ情報の登録時刻と現在の登録削除時刻から登録期間を算出し、通知ＵＲＬをキーにして、通知依頼登録履歴ＤＢ２１０に、Ｓｕｂｓｃｒｉｂｅ情報を登録する（ステップＳ１４０４）。

以上説明したように、本実施形態によれば、Ｓｕｂｓｃｒｉｂｅ／ＮｏｔｉｆｙモデルにおけるＫ−匿名性保護を実現することができる。また、動的に変化するユーザ情報に対してユーザの匿名性を確保しつつ、サービサは、Ｓｕｂｓｃｒｉｂｅ／Ｎｏｔｉｆｙ機構を利用できるため、ポーリング操作が不要となり、サービサ側のリソース消費削減が可能となる。更に、サービサは、Ｓｕｂｓｃｒｉｂｅ登録時点で条件がＫ−匿名性を満足する可能性が少ないことを知ることができるため、条件指定をチューニングすることが可能となり、サービサから見た利便性が向上する。

なお、ライフログのデータを時系列で蓄積するのではなく、現在の最新情報だけをプレゼンスデータとして保持してもよい。例えば、ユーザ端末から属性更新通知を受け取った場合に、ライフログにデータを追加する代わりに、該当する項目を上書きすることで実現できる。これにより、ライフログのデータ量の肥大化を防ぐことが可能となる。

上記実施形態で説明した構成は、単に具体例を示すものであり、本発明の技術的範囲を制限するものではない。本発明の効果を奏する範囲において、任意の構成を採用することが可能である。上記実施形態では、システムに本発明を適用した例を説明したが、情報処理装置として実現されてもよい。

なお、本発明の実施形態は、上述した実施形態を実現するソフトウェアのプログラム（実施の形態では図に示すフロー図に対応したプログラム）が装置に供給され、その装置のコンピュータが、供給されたプログラムを読出して、実行することによっても達成せれる場合を含む。したがって、本実施形態で説明した機能処理をコンピュータで実現するために、コンピュータにインストールされるプログラム自体も本発明の一実施形態である。つまり、本発明の機能処理を実現させるためのプログラムも、実施形態の一側面に含まれる。また、本発明の機能処理を実現させるためのプログラムを記録した媒体も、実施形態の一側面に含まれる。

１ ライフログ管理システム
２ プライバシー保護装置
１１０ 通知依頼登録受付部
１２０ 属性更新頻度管理部
１３０ 静的属性抽出部
１４０ 匿名性判定部
１５０ 通知依頼登録ＤＢ
１６０ 情報登録部
１７０ 通知条件判定部
１８０ 通知保留データ管理部
１９０ 通知部
２００ サービス有効期間判定部
２１０ 通知依頼登録履歴ＤＢ
３００ ユーザライフログＤＢ

Claims (7)

1. ユーザの情報を収集してライフログとして蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログに関するデータをサービサに通知するライフログ管理システムにおけるプライバシー保護装置であって、
   ユーザのライフログが蓄積されるのに応じて、当該ライフログを構成する各属性の更新頻度を算出して記録する属性更新頻度管理部と、
   サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、前記属性更新頻度管理部が記録する更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する静的属性抽出部と、
   前記静的属性抽出部が抽出した静的属性について、通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が前記限界人数を超えているときに、通知依頼の登録をサービサから受け付ける通知依頼受付部とを備える、プライバシー保護装置。
2. ユーザのライフログが新規に追加された場合に、追加されたユーザのライフログが、登録を受け付けた通知依頼についての通知条件を満たすかどうかを判定し、当該通知条件を満たす場合、当該通知条件を満たす他のユーザを抽出し、抽出されたユーザ数が前記限界人数に達していない場合に、サービサへの当該通知条件を満たすライフログに関するデータの通知を保留する通知判定部を更に備える、請求項１に記載のプライバシー保護装置。
3. ユーザのライフログが新規に追加された場合に、追加されたユーザのライフログが、登録を受け付けた通知依頼についての通知条件を満たすかどうかを判定し、当該通知条件を満たす場合、当該通知条件を満たす他のユーザを抽出し、抽出されたユーザ数が前記限界人数に達している場合に、当該通知条件を満たすライフログに関するデータをサービサに通知する通知判定部を更に備える、請求項１に記載のプライバシー保護装置。
4. サービサの過去の通知依頼の登録履歴を保持する通知依頼履歴データベースと、
   新規に通知依頼を登録するサービサについて、前記通知依頼履歴データベースから対応するサービサの過去の通知依頼の登録履歴を抽出し、当該通知依頼の登録の平均継続時間を算出することによって、当該サービサのサービスの有効期間を算出するサービス有効期間判定部を更に備える、請求項１〜３のいずれかに記載のプライバシー保護装置。
5. ユーザの情報を収集してライフログとして蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログに関するデータをサービサに通知するライフログ管理システムであって、
   ユーザのライフログが蓄積されるのに応じて、当該ライフログを構成する各属性の更新頻度を算出して記録する属性更新頻度管理部と、
   サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、前記属性更新頻度管理部が記録する更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する静的属性抽出部と、
   前記静的属性抽出部が抽出した静的属性について、通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が前記限界人数を超えているときに、通知依頼の登録をサービサから受け付ける通知依頼受付部と、
   ユーザのライフログが新規に追加された場合に、追加されたユーザのライフログが、登録を受け付けた通知依頼についての通知条件を満たすかどうかを判定し、当該通知条件を満たす場合、当該通知依頼についての通知条件を満たす他のユーザを抽出し、抽出されたユーザ数が前記限界人数に達している場合に、当該通知条件を満たすライフログに関するデータをサービサに通知する通知判定部とを備える、ライフログ管理システム。
6. ユーザの情報を収集してライフログとして蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログに関するデータをサービサに提供するライフログ管理システムにおけるプライバシー保護方法であって、
   ユーザのライフログが蓄積されるのに応じて、当該ライフログを構成する各属性の更新頻度を算出して記録する属性更新頻度管理ステップと、
   サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、前記属性更新頻度管理ステップで記録した更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する静的属性抽出ステップと、
   前記静的属性抽出ステップで抽出した静的属性について、通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が前記限界人数を超えていると判定したときに、通知依頼の登録をサービサから受け付ける通知依頼受付ステップとを備える、プライバシー保護方法。
7. ユーザの情報を収集してライフログとして蓄積し、通知依頼の登録をサービサから受け付け、登録を受け付けた通知依頼についての通知条件を満たすユーザのライフログに関するデータをサービサに提供するライフログ管理システムにおけるコンピュータが実行するプライバシー保護プログラムであって、
   前記コンピュータに、
   ユーザのライフログが蓄積されるのに応じて、当該ライフログを構成する各属性の更新頻度を算出して記録する属性更新頻度管理ステップと、
   サービサのサービス有効期間と予め定められた限界人数に基づいて、変更頻度の閾値を算出し、前記属性更新頻度管理ステップで記録した更新頻度が、算出された変更頻度の閾値以下である属性を静的属性として抽出する静的属性抽出ステップと、
   前記静的属性抽出ステップで抽出した静的属性について、通知依頼についての通知条件を満たすユーザ数を抽出し、抽出されたユーザ数が前記限界人数を超えていると判定したときに、通知依頼の登録をサービサから受け付ける通知依頼受付ステップとを実行させる、プライバシー保護プログラム。

Images