(57)【要約】【課題】  ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することを可能にする。【解決手段】  ユーザの活動内容を示す状況情報を複数の個人用状況情報管理サーバ１００、…に分散して管理する分散状況情報管理システム１において、分散状況情報管理サーバ１００、…は、ユーザの状況情報を管理する状況情報管理部１０１、…と、１以上のユーザが属するグループ毎に状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御部１０３、…と、ユーザが所属するグループの他のユーザの状況情報を個人用状況情報管理サーバ１００、…から収集する分散状況情報統合制御部１０４、…とを有し、分散状況情報統合制御部１０４、…は、収集した状況情報のユーザへの開示範囲をグループポリシに記述された開示条件に基づいて決定する。【選択図】          図１
2006085395.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの活動内容を示す状況情報を複数のサーバに分散して管理する分散状況情報管理システムであって、
前記サーバは、ユーザの状況情報を管理する状況情報管理部と、１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御部と、前記ユーザが所属するグループの他のユーザの状況情報を前記複数のサーバから収集する分散状況情報統合制御部とを有し、
前記分散状況情報統合制御部は、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに記述された前記開示条件に基づいて決定することを特徴とする分散状況情報管理システム。
【請求項２】
ユーザの活動内容を検出するセンサと、
前記センサで検出された情報から前記ユーザの状況情報を取得する状況情報取得サーバとを有し、
前記状況情報取得サーバは取得した状況情報を前記ユーザの管理下にあるサーバへ送信することを特徴とする請求項１記載の分散状況情報管理システム。
【請求項３】
ユーザが使用するクライアントと、
前記クライアントへ所定のアプリケーションを提供するアプリケーションサーバとを有し、
前記アプリケーションサーバは前記クライアントから前記ユーザが所属するグループの他のユーザに関する状況情報が問い合わせられると、前記分散状況情報統合制御部へ問い合わせを行い、
前記分散状況情報統合制御部は、前記問い合わせに基づいて前記ユーザの所属するグループの他のユーザの状況情報を前記複数のサーバから収集することを特徴とする請求項１記載の分散状況情報管理システム。
【請求項４】
ユーザの活動内容を示す状況情報を管理する分散状況情報管理サーバであって、
ユーザの状況情報を管理する状況情報管理部と、
１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御部と、
前記ユーザが所属するグループの他のユーザの状況情報を複数のサーバから収集する分散状況情報統合制御部とを有し、
前記分散状況情報統合制御部は、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに記述された前記開示条件に基づいて決定することを特徴とする分散状況情報管理サーバ。
【請求項５】
前記グループポリシには、前記ユーザの活動状況に応じて前記状況情報の詳細、概要、統計または虚偽の何れかを開示するような開示条件が記述されていることを特徴とする請求項４記載の分散状況情報管理サーバ。
【請求項６】
前記分散状況情報統合制御部は、自サーバに対するアクセス権を持つユーザの認証を行うための公開鍵を管理し、該鍵に基づいて前記他のサーバの認証を行った後、前記他サーバから要求されるユーザの状況情報の取得要求に応答することを特徴とする請求項４記載の分散状況情報管理サーバ。
【請求項７】
ユーザの活動内容を示す状況情報を複数のサーバに分散して管理する分散状況情報管理方法であって、
ユーザが所属するグループの他のユーザの状況情報の問い合わせを受け付ける第１ステップと、
前記他のユーザの状況情報を前記複数のサーバから収集する第２ステップと、
１以上のユーザが属するグループ毎に前記状況情報の開示条件を設定するためのグループポリシに基づいて前記第２ステップで収集した前記状況情報の開示範囲を決定する第３ステップとを有することを特徴とする分散状況情報管理方法。
【請求項８】
ユーザの活動内容を示す状況情報を他のサーバと共に分散して管理するコンピュータを機能させるためのプログラムであって、
ユーザの状況情報を管理する状況情報管理処理と、
１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御処理と、
前記グループに所属する他のユーザの状況情報を前記他のサーバから収集する分散状況情報統合制御処理とを前記コンピュータに実行させ、
前記分散状況情報統合制御処理は、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに基づいて決定することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散状況情報管理システム、分散状況情報管理サーバ、分散状況情報管理方法、およびそのプログラムに関し、特にセンサによって取得可能なユーザの状況情報に基づいたアプリケーションを構築するための分散処理技術に関する。
【背景技術】
【０００２】
現在、ＲＦＩＤや赤外線や無線を応用した位置検出技術や、カメラ画像の認識技術や、音声認識技術などの多様なセンサ技術が存在する。これらセンサ技術を用いることで、ユーザの位置情報やユーザの挙動や対話の内容など、ユーザの動態を示す様々な状況情報を収集することが可能となる。また、我々はこのように収集された状況情報を利用することで、ユーザのリアルなワークの分析システムや、ユーザが明示的に指示せずともユーザの状況変化に応じたサービスを提供するような高度なアプリケーションを構築できるようになる。
【０００３】
上記のように、ユーザの状況情報の利用は、アプリケーションの高度化という面では有益であるが、その一方で、ユーザの状況情報の無分別な収集・利用は、ユーザのプライバシーの侵害につながる。とりわけ、センサ情報を統括するインフラストラクチャが集中的にユーザの状況情報を管理するようなシステム・アーキテクチャでアプリケーションを構築する場合には、ユーザは自分の状況情報を一切コントロールできないまま一方的に利用される環境に置かれることになるため、プライバシーの問題は非常に深刻になる。
【０００４】
ユーザのプライバシーを守るためには、ユーザ各自が自身の状況情報を管理し開示範囲を制御できるようなネットワークサービスに状況情報を分散配置させるシステム・アーキテクチャが有効である。
【０００５】
例えば以下に示す特許文献１には、移動体の位置情報を分散的に管理するための移動体位置認識分散管理システムが開示されている。また、以下に示す特許文献２には、ユーザの状況情報の開示範囲を制御する分散型のユーザエージェントを備えたインフラストラクチャが開示されている。さらに、以下に示す特許文献３および特許文献４には、分散した複数の機器が強調してユーザの状況情報を判断し、当該ユーザの機器に対するアクセス権を自動設定するための情報公開型アクセス制御方法または合議型アクセス制御方法が開示されている。
【特許文献１】特開平５−１８９６６８号公報
【特許文献２】特開平７−２００４４７号公報
【特許文献３】特開２００２−３０４３７７号公報
【特許文献４】特開２００３−２４２１２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、このようなシステム・アーキテクチャに基づいて複数のユーザ間でコラボレーションを行うようなアプリケーションを構築する場合に、ユーザ同士がどのようなグループを構成するかが運用前には分からないため、分散配置しているユーザの状況情報を運用時に組み合わせることが困難であるという課題が存在する。また、グループの構成が出来たとしても、グループの活動状況に応じて状況情報の開示範囲を動的に制御しなければならない場面があるが、そのような場合に、分散しているユーザの状況情報に対してグループで一貫した開示範囲制御を行うこともまた困難であるという課題が存在する。
【０００７】
例えば特許文献１が開示するところの技術は、その目的が位置情報管理サービスの負荷分散であるため、位置情報の開示範囲制御を行うことを考慮しておらず、これを実現できていないという問題が存在する。また、特許文献２が開示するところの技術は、ユーザエージェントの機能がユーザ個人単位の開示範囲制御にとどまるため、グループ単位での制御を行うことができず、外部の集中型の調停メカニズム(エスクローサービス)を必要とし、グループ単位での開示範囲制御を分散的に実行することができないという問題が存在する。さらに、特許文献３および特許文献４が開示するところの技術は、複数のユーザからなるグループに対してアクセス権を設定するものではないという問題が存在する。
【０００８】
そこで本発明は、上記の問題に鑑みてなされたものであり、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能な分散状況情報管理システム、分散状況情報管理サーバ、分散状況情報管理方法、およびそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
かかる目的を達成するために、請求項１記載の本発明は、ユーザの活動内容を示す状況情報を複数のサーバに分散して管理する分散状況情報管理システムであって、前記サーバが、ユーザの状況情報を管理する状況情報管理部と、１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御部と、前記ユーザが所属するグループの他のユーザの状況情報を前記複数のサーバから収集する分散状況情報統合制御部とを有し、前記分散状況情報統合制御部が、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに記述された前記開示条件に基づいて決定するように構成される。複数のサーバに分散された状況情報を収集し、これの開示範囲をグループポリシに基づいて決定するように構成することで、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。また、グループポリシに基づくことで、グループの活動状況に応じて動的に開示範囲を制御するように構成することも可能となる。さらに、サーバ間でユーザの状況情報を交換可能に構成しているため、分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャを実現することが可能となる。これにより、複数のユーザ間でコラボレーションを行うようなアプリケーションを実現することが可能となる。さらにまた、例えば状況情報を管理するサーバをユーザの管理下にあるサーバとすることで、ユーザのプライバシーを守るためにユーザ各自が自身の状況情報を管理することが可能となる。
【００１０】
また、請求項１記載の発明は、例えば請求項２記載のように、ユーザの活動内容を検出するセンサと、前記センサで検出された情報から前記ユーザの状況情報を取得する状況情報取得サーバとを有し、前記状況情報取得サーバは取得した状況情報を前記ユーザの管理下にあるサーバへ送信するように構成されても良い。ユーザの状況情報を適宜取得するセンサおよびサーバを設けることで、状況情報の鮮度を保つことができる。
【００１１】
また、請求項１記載の発明は、例えば請求項３記載のように、ユーザが使用するクライアントと、前記クライアントへ所定のアプリケーションを提供するアプリケーションサーバとを有し、前記アプリケーションサーバが前記クライアントから前記ユーザが所属するグループの他のユーザに関する状況情報が問い合わせられると、前記分散状況情報統合制御部へ問い合わせを行い、前記分散状況情報統合制御部が前記問い合わせに基づいて前記ユーザの所属するグループの他のユーザの状況情報を前記複数のサーバから収集するように構成されても良い。分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャが実現可能となったことにより、クライアントへアプリケーションを提供するアプリケーションサーバを設けることで、複数のユーザ間でコラボレーションを行うことが可能となる。
【００１２】
また、請求項４記載の発明は、ユーザの活動内容を示す状況情報を管理する分散状況情報管理サーバであって、ユーザの状況情報を管理する状況情報管理部と、１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御部と、前記ユーザが所属するグループの他のユーザの状況情報を複数のサーバから収集する分散状況情報統合制御部とを有し、前記分散状況情報統合制御部が、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに記述された前記開示条件に基づいて決定するように構成される。複数のサーバに分散された状況情報を収集し、これの開示範囲をグループポリシに基づいて決定するように構成することで、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。また、グループポリシに基づくことで、グループの活動状況に応じて動的に開示範囲を制御するように構成することも可能となる。さらに、サーバ間でユーザの状況情報を交換可能に構成しているため、分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャを実現することが可能となる。これにより、複数のユーザ間でコラボレーションを行うようなアプリケーションを実現することが可能となる。さらにまた、例えば状況情報を管理するサーバをユーザの管理下にあるサーバとすることで、ユーザのプライバシーを守るためにユーザ各自が自身の状況情報を管理することが可能となる。
【００１３】
また、請求項４記載の発明は、例えば請求項５記載のように、前記グループポリシに、前記ユーザの活動状況に応じて前記状況情報の詳細、概要、統計または虚偽の何れかを開示するような開示条件が記述されていてもよい。活動状況に応じて詳細、概要、統計または虚偽の状況情報を開示するように構成することで、状況に応じて柔軟にユーザのプライバシーを守ることが可能となる。
【００１４】
また、請求項４記載の発明は、例えば請求項６記載のように、前記分散状況情報統合制御部が、自サーバに対するアクセス権を持つユーザの認証を行うための公開鍵を管理し、該公開鍵に基づいて前記他のサーバの認証を行った後、前記他サーバから要求されるユーザの状況情報の取得要求に応答するように構成されても良い。分散状況情報統合制御部が公開鍵を管理するように構成することで、ユーザ認証を組み込んだシステム設計が可能となり、より安全な運用を実現することができる。
【００１５】
また、請求項７記載の発明は、ユーザの活動内容を示す状況情報を複数のサーバに分散して管理する分散状況情報管理方法であって、ユーザが所属するグループの他のユーザの状況情報の問い合わせを受け付ける第１ステップと、前記他のユーザの状況情報を前記複数のサーバから収集する第２ステップと、１以上のユーザが属するグループ毎に前記状況情報の開示条件を設定するためのグループポリシに基づいて前記第２ステップで収集した前記状況情報の開示範囲を決定する第３ステップとを有して構成される。複数のサーバに分散された状況情報を収集し、これの開示範囲をグループポリシに基づいて決定するように構成することで、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。また、グループポリシに基づくことで、グループの活動状況に応じて動的に開示範囲を制御するように構成することも可能となる。さらに、サーバ間でユーザの状況情報を交換可能に構成しているため、分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャを実現することが可能となる。これにより、複数のユーザ間でコラボレーションを行うようなアプリケーションを実現することが可能となる。
【００１６】
また、請求項８記載の発明は、ユーザの活動内容を示す状況情報を他のサーバと共に分散して管理するコンピュータを機能させるためのプログラムであって、ユーザの状況情報を管理する状況情報管理処理と、１以上のユーザが属するグループ毎に前記状況情報の開示条件が記述されたグループポリシを管理するグループポリシ制御処理と、前記グループに所属する他のユーザの状況情報を前記他のサーバから収集する分散状況情報統合制御処理とを前記コンピュータに実行させ、前記分散状況情報統合制御処理が、収集した前記状況情報の前記ユーザへの開示範囲を前記グループポリシに基づいて決定するように構成される。複数のサーバに分散された状況情報を収集し、これの開示範囲をグループポリシに基づいて決定するように構成することで、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。また、グループポリシに基づくことで、グループの活動状況に応じて動的に開示範囲を制御するように構成することも可能となる。さらに、サーバ間でユーザの状況情報を交換可能に構成しているため、分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャを実現することが可能となる。これにより、複数のユーザ間でコラボレーションを行うようなアプリケーションを実現することが可能となる。
【発明の効果】
【００１７】
本発明によれば、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能な分散状況情報管理システム、分散状況情報管理サーバ、分散状況情報管理方法、およびそのプログラムを実現することができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明を実施するための最良の形態を図面と共に詳細に説明する。
【実施例１】
【００１９】
まず、本発明による実施例１について詳細に説明する。本実施例は、ユーザ各自が自身の状況情報を管理可能にするための分散型のシステム・アーキテクチャである。これを実現するために、本実施例では、ユーザの状況情報や個人情報を各ユーザの管理下のサーバに分散配置し、アプリケーションに対してその情報を開示するという構成をとる。この構成は本質的にユーザ各自が自身の状況情報を完全に制御下に置ける構成である。
【００２０】
また、本実施例では、各ユーザの持つ状況情報の開示範囲の制御をグループ単位で一貫して分散して行う機構も設ける。そのための機構として、本発明では、グループ単位での状況情報の開示制御を行うグループポリシ制御部と、分散した複数のユーザの状況情報を左記グループポリシ制御部に従って収集する分散状況情報統合制御部とを導入する。これらの機構はユーザの管理下のサーバにそれぞれ分散配置され、必要なタイミングで協調して動作する。
【００２１】
以上のように、ユーザの状況情報や個人情報を各ユーザの管理下のサーバに分散配置し、アプリケーションに対してその情報を開示するという構成に、各ユーザの持つ状況情報の開示範囲の制御をグループ単位で一貫して分散して行う機構を組み合わせることで、本実施例では、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。また、グループの活動状況に応じた動的な開示範囲制御をも可能にする。これらの特徴により、本発明を利用して、ユーザのプライバシーを守るためにユーザ各自が自身の状況情報を管理可能にしつつ、複数のユーザ間でコラボレーションを行うようなアプリケーションを構築することが可能となる。
【００２２】
次に、本実施例を図面と共に詳細に説明する。図１は本実施例による分散状況情報管理システム１の構成を示すシステム図である。図１に示すように、分散状況情報管理システム１は、状況情報取得サーバ１０とアプリケーションサーバ２０と個人用状況情報管理サーバ１００、２００とクライアント１１０とを有して構成される。また、これらはＬＡＮ（Local Area Network）やインターネットなど、所定のネットワークを介して相互に接続されている。
【００２３】
アプリケーションサーバ２０は、以下で取得したユーザの状況情報を利用するためのアプリケーションを提供する情報処理装置である。また、クライアント１１０は、このアプリケーションサーバ２０をユーザが利用するための情報処理装置である。なお、アプリケーションサーバ２０およびクライアント１１０は１台以上である。
【００２４】
状況情報取得サーバ１０は、ユーザへユニークに割り当てられた識別情報（以下、ＩＤという）を読み取るためのセンサ群１１と接続され、これで読み取られた情報が随時入力される。ここで、ＩＤとしては、例えば指紋や虹彩や声紋や顔のパターンや手のひらの静脈パターンやＤＮＡ情報など、人が生まれながらにして持つ（但し、後天的な情報も含む）固有の情報（これを自然情報という）を適用することができるが、この他にも、例えば人為的に付した固有の情報を適用することができる。したがって、センサ群１１には、タグ１２からＩＤを読み取るための接触型又は非接触型読取装置や、指紋センサや、虹彩センサや、声紋センサや、顔のパターンを識別するためのセンサや、手のひらの静脈パターンを識別するためのセンサや、ＤＮＡ情報を読み取るためのセンサなどを適用することができる。本実施例では、ＲＦ−ＩＤなどのようなタグ１２を用いて人為的にユーザへＩＤを付与し、これから非接触にＩＤを読み取る場合を例に挙げる。
【００２５】
また、センサ群１１には、ユーザの位置情報や、ユーザを含む周囲の画像やユーザが発している音声など、様々な情報を検出するためのセンサとして赤外線センサやカメラやマイクなどが適用される。
【００２６】
これらセンサ群１１で検出された情報（以下、センサ情報という）は状況情報取得サーバ１０に入力される。状況情報取得サーバ１０は、センサ情報を解析することで、ユーザを特定し、また、ユーザの位置情報や活動内容推定情報など、様々な情報（以下、状況情報という）を取得する。例えばユーザの識別は、タグ１２から読み出されたＩＤを用いることで容易に特定することができる。ユーザの位置情報は、赤外線センサの位置とユーザの検出位置とからで容易に取得することができるし、また、カメラの撮影方向が判っていれば、カメラから取得した画像を認識処理することで容易に取得することができる。活動内容推定情報は、ユーザを撮影した画像を認識処理し、ユーザの動作や服装を特定したり、ユーザが発している声を認識処理し、その内容を特定することで取得することができる。ただし、本発明による状況情報は上記のものに限らず、ユーザの活動内容、例えばある時刻の存在位置や使用している電子機器や作業内容や一緒にいる他のユーザなどを示す情報であれば、その目的に応じて如何なる情報も適用することができる。
【００２７】
状況情報取得サーバ１０で取得された状況情報は個人用状況情報管理サーバ１００、２００、…の何れかに送られ、それぞれのユーザ毎に分散して記憶される。すなわち、ユーザの状況情報や個人情報は、個人用状況情報管理サーバ１００、２００、…の何れかであって、当該ユーザの管理下にある個人用状況情報管理サーバに分散配置される。これにより、ユーザ各自が自身の状況情報を管理し、開示範囲を制限したり、開示を拒否したりするように設定することが可能となる。
【００２８】
以上で説明した各分散コンポーネント（状況情報取得サーバ１０、アプリケーションサーバ２０、個人用状況情報管理サーバ１００、２００、…、クライアント１１０で実行された機能）は、リモートオブジェクトを用いて連携動作する。この概念図を図２に示す。なお、各分散コンポーネントは所定のプログラムを実行することで実現される。また、リモートオブジェクトとは、別のコンピュータからそのメソッドを呼び出すためのオブジェクトである。このタイプのオブジェクトは、例えばＪａｖａ（登録商標）プラットフォームの分散オブジェクトモデルであれば、リモートオブジェクトのメソッドを宣言するＪａｖａ（登録商標）インタフェースである、１つまたは複数の「リモートインタフェース」により記述することができる。
【００２９】
次に、図１に戻り、個人用状況情報管理サーバ１００、２００、…の詳細について説明する。個人用状況情報管理サーバ１００、２００、…は、状況情報管理部１０１、２０１、…と個人情報管理部１０２、２０２、…とグループポリシ制御部１０３、２０３、…と分散状況情報統合制御部１０４、２０４、…とをそれぞれ有する。ここで、本実施例のポイントは、ユーザ毎の状況情報が各ユーザの管理下にある個人用状況情報管理サーバ１００、２００、…の何れかに分散配置されつつ、それらがグループ単位の開示制御の下で統合利用可能になる点にある。上記の構成におけるグループポリシ制御部１０３、２０３、…と、分散状況情報統合制御部１０４、２０４、…とは、これを可能にするための構成要素である。
【００３０】
状況情報管理部１０１、２０１、…は、上記のように状況情報取得サーバ１０から入力された状況情報をユーザ毎に管理する。この状況情報は以下に示す活動履歴管理テーブルおよび最新状態管理テーブルにおいて管理される。図３に活動履歴管理テーブルの一例を示す。また、図４に最新状態管理テーブルの一例を示す。
【００３１】
活動履歴管理テーブルはユーザ毎の状況情報の履歴を管理するためのテーブルであり、図３に示すように、状況情報が状況情報取得サーバ１０において取得された『時刻』と、その際ユーザが居た場所や活動内容を示す『動作』と、その際ユーザが個人で活動していたか、何れかのグループ単位で活動していたかを示す『活動グループ』とを保持している。すなわち、本実施例によるユーザ毎の状況情報は『時刻』と『動作』と『活動グループ』とを含んでなる。なお、『活動グループ』はそのユーザがどのグループで活動しているかの判定結果を格納しているが、これは、センサ側ないしはアプリケーション側で推定するか、またはユーザの明示的な指定により得られる情報である。
【００３２】
最新状態管理テーブルはユーザ毎の最新の状況情報を管理するためのテーブルであり、図４に示すように、状況情報を構成する要素情報を示す『状態名』と、これの値である『状態値』とを保持している。すなわち、状況情報取得サーバ１０から入力された状況情報は一時最新状態管理テーブルに格納され、その後、一定時間経過した後、または、次の最新の状況情報が入力された際、活動履歴管理テーブルへ移される。
【００３３】
個人情報管理部１０２、２０２、…は、ユーザの個人情報を管理する。この個人情報は以下に示す個人属性管理テーブルにおいて管理される。図５に個人属性管理テーブルの一例を示す。
【００３４】
個人属性管理テーブルはユーザのプロファイルなど、長期間変化しないユーザ情報を管理するためのテーブルであり、図５に示すように、ユーザＩＤや役職や所属や関心キーワードなどの属性が『属性名』と『属性値』とで保持されている。なお、ユーザＩＤはユーザ毎に付与された識別情報であり、例えばタグ１２によりユーザが携帯することができる。また、関心キーワードとはユーザが従事する業務などから抽出されたキーワードであり、ユーザが関心を持つ事項を特定するための情報である。このような個人情報管理テーブルで保持される情報は、システム設計時または運用時に管理者またはユーザ自身が入力することで得られる。
【００３５】
グループポリシ制御部１０３、２０３、…は、グループを管理する。これは、例えば図６に示すようなグループポリシ管理テーブルにおいて管理される。
【００３６】
グループポリシ管理テーブルはグループに属するユーザや当該グループに与えられたポリシを管理するためのテーブルであり、図６に示すように、グループに与えられた識別子（『グループＩＤ』）と、名称である『グループ名』と、グループに属するユーザをリスト化した『メンバ・ユーザＩＤリスト』と、グループに与えられたポリシである『グループポリシ』とを保持している。なお、『グループポリシ』は他の記憶手段等で記憶されたグループポリシへのリンクという形で管理される。グループポリシの詳細については後述において説明する。
【００３７】
分散状況情報統合制御部１０４、２０４、…は、他の個人用状況情報管理サーバと連携し、分散して管理されている状況情報を統合するための構成である。これを実現するために、分散状況情報統合制御部１０４、２０４、…は、他の個人用状況情報管理サーバへアクセスし、必要な情報を取得するための情報を保持する個人状況情報管理サービス管理テーブルを有する。個人状況情報管理サービス管理テーブルの一例を図７に示す。
【００３８】
図７に示すように、個人状況情報管理サービス管理テーブルは、他の個人用状況情報管理サーバを管理するユーザの『ユーザＩＤ』と、当該個人用状況情報管理サーバと通信する際に使用するリモートオブジェクトを取得するための『サービスＩＤ』と、他の個人用状況情報管理サーバを管理し自サーバに対してアクセス権を持つユーザとして、当該他の個人用状況情報管理サーバを認証し、自サーバに対するアクセスの許認可を判断するために使用する、当該ユーザの『公開鍵』とを保持している。なお、『公開鍵』は暗号化キーである。また、サービスＩＤは、これに限らず、例えばＩＰ（Internet Protocol）アドレス（ＩＰｖ６を含む）やＰｔｏＰネットワークにおける個のＩＤなど、グローバルにユニークな値であれば如何なるもので代用することができる。
【００３９】
次に、グループポリシについて詳細に説明する。グループポリシ制御部１０３、２０３、…は、上述の図６に示すグループポリシ管理テーブルを管理すると共に、グループポリシを評価することで状況情報の開示制御を行う。グループポリシは、ユーザの状況情報をグループ単位で開示制御するルールを記述したものである。ユーザはグループメンバ間で合意したルールをグループポリシに記述する。グループポリシは各グループポリシ制御部１０３、２０３、…に分散して存在するが、グループポリシ制御部１０３、２０３、…は互いに他のグループポリシ制御部１０３、２０３、…と連携し、同一のグループに対するグループポリシが同一になるように自動的に同期をとる。
【００４０】
図８はグループポリシの例である。‘target-group-id:’行はユーザの状況情報の開示先のグループのＩＤを記述している。‘release-method:’行以下には、条件と開示方法のルールとを記述している。このルールは条件文と実行文との組から構成され、‘release-method:’部に記述した順序に従って条件文が評価され、成立した条件に対応する開示処理が実行される。条件が一つ成立した時点でその‘release-method:’部の評価は終了する。
【００４１】
例えば、‘target-group-id:590’に対しては、条件文として‘get_active_group_id_set().contains(590)’が記述されている。この条件文により、『現在活動しているグループのグループＩＤ集合を取得し、その中に自身のグループＩＤである‘590’が含まれている、すなわち、自身のグループが活動状況にある』ということが成立するか否かが判定される。この条件文が成立する場合、‘release_detail()’の記述に従って、『詳細な活動状況を開示する』処理が実行される。また、上記条件が成立しない場合、いつでも成立する‘default:’が成立し、‘release_summary("location-role","location-interests")’の記述に従って、『位置と役割の概要と、位置と興味の概要を開示する』処理が実行される。つまり、グループＩＤ＝５９０のグループは、活動中は互いのグループメンバの状況情報の詳細を開示してもよいが、活動していないときは概要しか開示しないことを、グループメンバ間で了解し、ポリシとして設定している。また、これとは別に、例えば‘target-group-id:624’に対して記述されているように、概要の代わりに統計値を開示してもよい。
【００４２】
但し、状況によっては、必ずしも実際の状況情報を開示する必要は無い。例えば、グループＩＤ＝５９０に対してグループＩＤ＝８１１が競合状態にあるときは、グループＩＤ＝５９０の活動中は、グループＩＤ＝８１１に対しては、‘release_fake_summary("location-member")’という記述に従って、『位置とメンバの概要の偽情報を開示する』というように、虚偽の情報を開示するように構成することもできる。
【００４３】
ここで、アプリケーションサーバ２０からの要求に応じて個人用状況情報管理サーバ１００、２００、…がレスポンスした状況情報の例を以下に図９から図１１に示す。なお、図９から図１１はパイソン言語を用いて記述した例である。図９は詳細な状況情報をレスポンスした際の内容を示す図である。この例では、状況情報管理部１０１、２０１、…の管理するデータが全て開示されている。図１０は状況情報の概要をレスポンスした際の内容を示す図である。この例では、グループメンバの居る位置及びグループメンバの個人情報に設定されている役割毎にカウントした人数と、グループメンバの居る位置及びグループメンバの個人情報に設定されている関心キーワードの集合とが概要として開示されている。図１１は状況情報の統計をレスポンスした際の内容を示す図である。この例では、問い合わせ時点での状況情報ではなく、一定の期間での統計値が開示されている。
【００４４】
次に、本実施例による分散状況情報統合制御部１０４、２０４、…の動作について説明する。なお、以下の説明では分散状況情報統合制御部１０４に着目する。
【００４５】
分散状況情報統合制御部１０４は他の分散状況情報統合制御部２０４、…やアプリケーションサーバ２０と協調的に動作し、分散しているユーザの状況情報を収集する。また、分散状況情報統合制御部１０４は収集した状況情報をグループポリシ制御部１０３の制御する開示範囲のもとで開示する。開示例は図９から図１１に示した通りである。
【００４６】
また、上記した各分散コンポーネントは、例えば図１２に示すように、名前サービスを利用して適切な名前空間に写像することで、グループ単位でひとまとめに取り扱うことが容易になる。ここで名前サービスとは、ネットワーク上に分散するオブジェクトリファレンスを一箇所に登録して管理するためのサービスである。サーバアプリケーションでは、このオブジェクト（コンポーネント）に分かりやすい名前をつけて名前サービスに登録する。クライアントは登録された名前をもとにオブジェクトリファレンスを検索することが可能となる。図１２では、‘User-Profile Manager’が個人情報管理部１０２、２０２、…を表し、‘User-status Manager’が状況情報管理部１０１、２０１、…を示し、‘Policy Manager’がグループポリシ制御部１０３、２０３、…を示す。本実施例では、分散状況情報統合制御部は、このような名前空間を経由して各分散コンポーネントへの到達性を管理するものとするが、もちろん、処理の都度、図７で管理されているサービスＩＤをもとに問い合わせを行ったり、ネットワーク全体に問い合わせをブロードキャストしたり等の他の方法を用いることも可能である。
【００４７】
次に、本実施例の動作を図面と共に説明する。まず、クライアント１１０がアプリケーションサーバ２０を利用するためには、そのユーザと関わりのある個人用状況情報管理サーバ１００、２００、…によってクライアント１１０が認証されねばならない。クライアント１１０が各個人用状況情報管理サーバ１００、２００、…に認証させる際の手順を図１３に示す。なお、認証手順は一般的に用いられているチャレンジ−レスポンス方式を使用している。
【００４８】
図１３に示すように、クライアント１１０は、まずアプリケーションサーバ２０へ認証要求を送信する（Ｃ１→Ａ１）。アプリケーションサーバ２０は認証要求を受信すると、全ての個人用状況情報管理サーバ１００、２００、３００、…へ認証要求を送信する（Ａ２→Ｓ１１，Ａ３→Ｓ２１，Ａ３→Ｓ３１）。認証要求を受信した個人用状況情報管理サーバ１００、２００、３００、…は、クライアント１１０に対してチャレンジコードを送信する（Ｓ１２→Ｃ２，Ｓ２２→Ｃ４，Ｓ３２→Ｃ６）。これに対し、クライアント１１０は受信したチャレンジコードを予めユーザへ付与された非公開鍵で暗号化することでレスポンスコードを生成し、これを送信元の個人用状況情報管理サーバ１００、２００、３００、…へ送信する（Ｃ３→Ｓ１３，Ｃ５→Ｓ２３，Ｃ７→Ｓ３３）。レスポンスコードを受信した個人用状況情報管理サーバ１００、２００、３００、…は、これを予めユーザへ付与しておいた公開鍵で復号化して矛盾があるか否かを確認し、矛盾が無い場合、認証ＯＫを示す認証応答をアプリケーションサーバ２０へ送信する（Ｓ１４→Ａ５，Ｓ２４→Ａ６，Ｓ３４→Ａ７）。このように全ての個人用状況情報管理サーバ１００、２００、３００、…から認証応答を受信すると、アプリケーションサーバ２０はクライアント１１０へ認証応答を送信する（Ａ８→Ｃ８）。これにより、クライアント１１０の認証が完了する。なお、この認証方式はエンティティ認証方式におけるチャレンジ／レスポンス方式を採用した場合の例である。本発明では、この認証方式に限らず、他の認証方式を採用しても良い。
【００４９】
以上のように認証が完了すると、ユーザは、例えば自分が属するグループの状況情報を問い合わせることができる。この際の手順を図１４に示す。
【００５０】
図１４に示すように、クライアント１１０は、まずアプリケーションサーバ２０へグループの状況情報を問い合わせる（Ｃ１１→Ａ１１）。ここでは問い合わせるグループのグループＩＤを‘６２４’とする。問い合わせを受けると、アプリケーションサーバ２０は個人用状況情報管理サーバへ問い合わせを行う（Ａ１２→Ｓ１１１）。ここで、個人用状況情報管理サーバ１００、２００、３００、…は協調して動作しているため、アプリケーションサーバ２０は何れか１つの個人用状況情報管理サーバに対して問い合わせを行えば良い。本説明では個人用状況情報管理サーバ１００へ問い合わせを行った場合を例に挙げる。
【００５１】
個人用状況情報管理サーバ１００は、まず、問い合わせ元のクライアント１１０に対して認証を行うために、チャレンジコードを送信する（Ｓ１１２→Ｃ１２）。これに対し、クライアント１１０は、上述したチャレンジ／レスポンス方式に従って、チャレンジコードを暗号化してレスポンスコードを生成し、これを個人用状況情報管理サーバ１００へ送信する（Ｃ１３→Ｓ１１５）。個人用状況情報管理サーバ１００は、受信したレスポンスコードを復号化し、認証が確認されると、自己を含む全ての個人用状況情報管理サーバ１００、２００、３００、…に対して状況情報照会を実行する（Ｓ１１４→Ｓ１１５、Ｓ１１８→Ｓ２１１、Ｓ１２０→Ｓ３１１）。この際、個人用状況情報管理サーバ１００は、分散状況情報統合制御部１０４において保持してある個人状況情報管理サービス管理テーブルに格納された他のユーザのユーザＩＤとサービスＩＤと公開鍵とを用いて、他のユーザの状況情報照会を実行する。これに対し、照会された個人用状況情報管理サーバ１００、２００、３００、…は、受信した他のユーザのユーザＩＤとサービスＩＤと公開鍵とに基づいて、自己が管理する活動履歴管理テーブルと最新状態管理テーブルと個人属性管理テーブルとを参照することで他のユーザの状況情報を取得し、これを個人用状況情報管理サーバ１００へ送信する（Ｓ１１６→Ｓ１１７、Ｓ２１２→Ｓ１１９、Ｓ３１２→Ｓ１２１）。このように状況情報を収集すると、個人用状況情報管理サーバ１００は、グループポリシ管理テーブルで管理されたグループポリシに従って、他のユーザの状況情報の詳細、概要、統計（図９から図１１を参照）または虚偽をアプリケーションサーバ２０へ送信する（Ｓ１２２→Ａ１３）。アプリケーションサーバ２０は受信した他のユーザの状況情報をクライアント１１０へ送信し（Ａ１４→Ｃ１４）、これをクライアント１１０において開示させる。
【００５２】
ここで、個人用状況情報管理サーバ１００が受信した他のユーザの状況情報からクライアント１１０へ開示する状況情報（詳細、概要、統計または虚偽）を抽出する際の動作を図１５を用いて詳細に説明する。
【００５３】
図１５に示すように、個人用状況情報管理サーバ１００は結果集合Ｒを空集合に初期化する（ステップＳ１０１）。次に個人用状況情報管理サーバ１００は、問い合わせ先となったグループＩＤ（図１３のＡ１１→Ｓ１１１参照：６２４）に対応するグループポリシ（６２４）をグループポリシ管理テーブル（図７参照）から取得し（ステップＳ１０２）、これをＧＰに代入する（ステップＳ１０３）。
【００５４】
次に個人用状況情報管理サーバ１００は、問い合わせ元のユーザＩＤを取得する（ステップＳ１０４）。これは認証時にクライアント１１０から取得したユーザＩＤを用いることもできる。このようにユーザＩＤを取得すると、個人用状況情報管理サーバ１００は、取得したユーザＩＤが所属するグループのグループＩＤの集合Ｓをグループポリシ管理テーブル（図７参照）から求める（ステップＳ１０５）。
【００５５】
次に個人用状況情報管理サーバ１００は、集合Ｓに含まれる全ての要素に対して以下の処理による調べを実行したか否かを判定し（ステップＳ１０６）、実行済みである場合（ステップＳ１０６のＹｅｓ）、処理を終了する。一方、実行済みでない場合、個人用状況情報管理サーバ１００は集合Ｓから未だ調べていない要素であるグループＩＤを１つ選択し、これをＧＩＤに代入する（ステップＳ１０７）。次に個人用状況情報管理サーバ１００は、ＧＩＤに含まれるグループＩＤに対応するグループへ開示可能な状況情報をＧＰに代入されたグループポリシに基づいて評価し、得られた状況情報の集合を結果集合Ｒに代入する（ステップＳ１０８）。これにより、問い合わせ元のユーザの所属グループと問い合わせ時点での状況に応じた範囲とに基づいて、他のユーザの状況情報をポリシに応じて開示することが可能となる。
【００５６】
以上のように構成および動作することで、本実施例によれば、ユーザ管理下の個人用状況情報管理サーバに自身の状況情報を蓄積するため、ユーザのプライバシーを守るためにユーザ各自が自身の状況情報を管理することが可能となる。また、個人用状況情報管理サーバ間でユーザの状況情報を交換可能に構成しているため、分散された状況情報を統合的に利用可能にする分散型のシステム・アーキテクチャを実現することが可能となる。これにより、複数のユーザ間でコラボレーションを行うようなアプリケーションを実現することが可能となる。さらに、複数のサーバに分散された状況情報を収集し、これの開示範囲をグループポリシに基づいて決定するように構成することで、ユーザの状況情報の開示範囲制御をグループ単位で一貫して分散的に実行することが可能となる。さらにまた、グループポリシに基づくことで、グループの活動状況に応じた動的な開示範囲制御が可能となる。
【００５７】
なお、上記実施例１は本発明を実施するための例にすぎず、本発明はこれらに限定されるものではなく、これらの実施例を種々変形することは本発明の範囲内であり、更に本発明の範囲内において、他の様々な実施例が可能であることは上記記載から自明である。
【図面の簡単な説明】
【００５８】
【図１】本発明の実施例１による分散状況情報管理システムの構成を示すシステム図である。
【図２】図１に示す各分散コンポーネント（状況情報取得サーバ１０、アプリケーションサーバ２０、個人用状況情報管理サーバ１００、２００、…、クライアント１１０で実行された機能）がリモートオブジェクトを用いて連携動作する際の構成を示す概念図である。
【図３】本発明の実施例１による活動履歴管理テーブルの一例を示す図である。
【図４】本発明の実施例１による最新状態管理テーブルの一例を示す図である。
【図５】本発明の実施例１による個人属性管理テーブルの一例を示す図である。
【図６】本発明の実施例１によるグループポリシ管理テーブルの一例を示す図である。
【図７】本発明の実施例１による個人状況情報管理サービス管理テーブルの一例を示す図である。
【図８】本発明の実施例１によるグループポリシの一例を示す図である。
【図９】本発明の実施例１において要求に応じてレスポンスされた状況情報（詳細）の例を示す図である。
【図１０】本発明の実施例１において要求に応じてレスポンスされた状況情報（概要）の例を示す図である。
【図１１】本発明の実施例１において要求に応じてレスポンスされた状況情報（統計）の例を示す図である。
【図１２】名前サービスを利用することで図１に示す分散コンポーネントを適切な名前空間に写像した際の概念図である。
【図１３】本発明の実施例１においてクライアント１１０が各個人用状況情報管理サーバ１００、２００、…に認証させる際の手順を示すシーケンスである。
【図１４】本発明の実施例１においてクライアント１１０からグループの状況情報を問い合わせる際の手順を示すシーケンスである。
【図１５】本発明の実施例１において個人用状況情報管理サーバ１００が受信した他のユーザの状況情報からクライアント１１０へ開示する状況情報（詳細、概要または統計）を抽出する際の動作を示すフローチャートである。
【符号の説明】
【００５９】
１  分散状況情報管理システム          １０  状況情報取得サーバ１０
１１  センサ群                        １２  タグ
２０  アプリケーションサーバ          １１０  クライアント
１００、２００、３００、…  個人用状況情報管理サーバ
１０１、２０１、…  状況情報管理部
１０２、２０２、…  個人情報管理部
１０３、２０３、…  グループポリシ制御部
１０４、２０４、…  分散状況情報統合制御部
【図１】
2006085395.tif 000003
【図２】
2006085395.tif 000004
【図３】
2006085395.tif 000005
【図４】
2006085395.tif 000006
【図５】
2006085395.tif 000007
【図６】
2006085395.tif 000008
【図７】
2006085395.tif 000009
【図８】
2006085395.tif 000010
【図９】
2006085395.tif 000011
【図１０】
2006085395.tif 000012
【図１１】
2006085395.tif 000013
【図１２】
2006085395.tif 000014
【図１３】
2006085395.tif 000015
【図１４】
2006085395.tif 000016
【図１５】
2006085395.tif 000017