JP2008234041A - コンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバ - Google Patents

Abstract

【課題】 コンテキスト共有時においてプライバシーポリシーの設定、制御が容易なコンテキスト共有システムを提供する。
【解決手段】 ＲＤＦのトリプルに従って、コンテキスト情報を、ノードＩＤ、プロパティ及び値で構成すると共に、ノード情報も、ＩＤ、クラス及び値で構成する。プライバシーポリシーを、ノード条件、対象ユーザ、アクセス権で構成する。クライアントは、上記ポリシーのノード条件と、作成したコンテキスト情報やノード情報がマッチすると、ポリシーの対象ユーザ及びアクセス権をアクセス情報にコピーし、作成した情報と共に送信する。サーバは、送信されてきた情報を保存する。また、任意のユーザのコンテキストがあるユーザから要求された場合、要求元ユーザが、要求先ユーザの要求されたコンテキストに係るアクセス権で許可されていると、そのコンテキスト情報を返信する。
【選択図】 図１

Description

本発明はコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバに関し、例えば、個人のプロファイル、キーワード、行動履歴、現在の状況等からなるコンテキストを共有する際のプライバシーポリシーを制御する方法に適用し得るものである。

従来、コンテキストを共有する際のプライバシーポリシーを制御する方法として、特許文献１の段落「０００９」に開示されている方法がある。この方法は、サーバコンピュータに送信すべきではない、特定のキーワード、名詞句、及び連絡先を、プライバシープリファレンス（サーバに送信することができる情報を定義したもの）において識別することができるようにしたものである。

また、特許文献２の段落「０００９」及び「００１０」に開示されている方法もある。この方法は、ユーザに対応して予め設定されたプライバシー要件を満たす情報要素を選択し、この選択された情報要素をもとにプレゼンス情報を生成する方法であり、また、ユーザが使用する情報通信端末の状態に関する検出要素を取り込む際には、ユーザに対応して予め設定されたプライパシー要件に対応する検出要素のみを選択的に取り込み、これをもとにプレゼンス情報を生成する方法である。
特開２００６−９２５４０ 特開２００５−２０２７８９

しかしながら、上記特許文献１の方法では、行動履歴の場所情報として、スケジュールに記載した場所は社内公開し、メールに記載した場所はメールの受信者にのみ公開し、終業時間外の情報は非公開とするといった複雑なプライバシーポリシーを、特定のキーワードあるいは名詞句で識別できるようにすることは、そのための設定に手間がかかるという課題を有する。

また、上記特許文献２の方法では、プライバシー要件をどのように記述するのか、また、それを満足する情報要素及びプレゼンス情報をどのように抽出するかの具体例が記載されておらず、すなわち、複雑なプライバシーポリシーを記述する具体的な方法が開示されていない。

そのため、コンテキストを共有する際のプライバシーポリシーを設定したり制御したりすることが容易な、プライバシーポリシーの記述が明確であるコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバが望まれている。

第１の本発明は、ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおいて、（１）上記各クラアントが、（１−１）（１−１−１）ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、（１−１−２）上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、（１−１−３）ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報とを保持する第１のコンテキスト保持手段と、（１−２）対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有する、プライバシーポリシー情報を管理するプライバシーポリシー管理手段と、（１−３）コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信する第１のコンテキスト管理手段とを備え、（２）上記サーバは、（２−１）上記クライアントから送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を、ユーザごとに保持する第２のコンテキスト保持手段と、（２−２）送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記第２のコンテキスト保持手段に保持させると共に、任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信する第２のコンテキスト管理手段とを備えることを特徴とする。

第２の本発明は、ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおいて、（１）上記各クラアントは、コンテキストの送信を管理する第１のコンテキスト管理手段、コンテキストの情報を保持する第１のコンテキスト保持手段、プライバシーポリシーの情報を管理するプライバシーポリシー管理手段を有し、（１−１）上記コンテキスト保持手段は、コンテキスト情報、ノード情報、及び、アクセス情報を保持し、（１−１−１）上記コンテキスト情報は、ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有し、（１−１−２）上記ノード情報は、上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有し、（１−１−３）上記アクセス情報は、ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有し、（１−２）上記プライバシーポリシー情報は、対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有し、（１−３）上記第１のコンテキスト管理手段は、コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信し、（２）上記サーバは、第２のコンテキスト管理手段、及び、第２のコンテキスト保持手段を有し、（２−１）上記第２のコンテキスト保持手段は、上記クライアントから送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を、ユーザごとに保持し、（２−２）上記第２のコンテキスト管理手段は、送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記第２のコンテキスト保持手段に保持させると共に、任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信することを特徴とする。

第３の本発明は、ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおける上記クライアントにおいて、（１）（１−１）ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、（１−２）上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、（１−３）ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報とを保持するコンテキスト保持手段と、（２）対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有する、プライバシーポリシー情報を管理するプライバシーポリシー管理手段と、（３）コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信するコンテキスト管理手段とを備えることを特徴とする。

第４の本発明は、ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおける上記サーバにおいて、（１）上記クラアントから送信されてきた、（１−１）ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、（１−２）上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、（１−３）ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報とを保持するコンテキスト保持手段と、（２）送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記コンテキスト保持手段に保持させると共に、任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信するコンテキスト管理手段とを備えることを特徴とする。

本発明によれば、コンテキストを共有する際のプライバシーポリシーを設定したり制御したりすることが容易な、プライバシーポリシーの記述が明確であるコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバを提供することができる。

（Ａ）第１の実施形態
以下、本発明によるコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバの第１の実施形態を、図面を参照しながら説明する。

（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るコンテキスト共有システムの構成を示すブロック図である。図１において、複数のクライアント１（１Ａ、１Ｂ、１Ｃ、…）とサーバ２とがネットワークを介して接続されている。

各クライアント１は、サーバ２にコンテキストを送信して管理すると共に、サーバ２に所望のコンテキストを要求して取り出すものである。各クライアント１は、例えば、コンテキスト共有システム用のプログラムがインストールされた、通信機能を有するパソコンや携帯電話などの情報処理装置が該当するが、コンテキストの共有機能から見た場合、機能的には、図１のクライアント１Ａに示すような詳細構成を有する。

各クライアント１は、ユーザＩＤ１０を保持していると共に、コンテキストの送信を管理するコンテキスト管理手段１１、コンテキストの情報を保持するコンテキスト保持手段１２、プライバシーポリシーを管理するプライバシーポリシー管理手段１３、セキュリティポリシーを管理するセキュリティポリシー管理手段１４、センサ及びアプリケーションの情報からコンテキストを推定するコンテキスト推定手段１５、０又は１以上のセンサ１６（１６Ａ、１６Ｂ、１６Ｃ、…）、及び、０又は１以上のコンピュータアプリケーション１７（１７Ａ、１７Ｂ、１７Ｃ、…）を有している。

コンテキスト管理手段１１には、コンテキスト保持手段１２、プライバシーポリシー管理手段１３、セキュリティポリシー管理手段１４、コンテキスト推定手段１５、及び、各センサ１６、及び、各コンピュータアプリケーション１７が接続されている。

なお、図１では、各クライアント１における、サーバ２側からコンテキストを取り出すための構成を省略している。

コンテキスト管理手段１１は、図２に示すようなクラス定義情報１１１を保持しており、センサ１６から入力されたデータや情報、起動されているアプリケーション１７から与えられたデータや情報に対し、クラス定義情報１１１を適用し、コンテキスト保持手段１２が保持するコンテキストを形成、管理するものである。

クラス定義情報１１１は、１以上のクラス定義１１１Ａ、１１１Ｂ、１１１Ｃ、…から構成されている。各クラス定義は、クラス名１１１１、０又は１以上のプロパティ定義１１１２、０又は１以上のメソッド定義１１１３から構成されている。クラス名１１１１、プロパティ定義１１１２及びメソッド定義１１１３の一組でなる各クラス定義は、後述するコンテキスト情報やノード情報が、ＲＤＦ（Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）のトリプルを構成し得るように定義すると共に、複数のＲＤＦのトリプルから、ＲＤＦのグラフを容易に構成し得るように定義しておく。

この実施形態の場合、「ＲＤＦのトリプル」の記述は、Ｗ３Ｃ勧告による記述方法に従った記述されたものに限定されず、ＲＤＦのトリプルやＲＤＦのグラフと同様な表記を実現できる記述方法であれば良い（例えば、ＵＲＬ参照方式の表記でなくても良い）。

例えば、クラス名１１１１が「位置情報コンテキスト」である１つのクラス定義として、そのプロパティ定義１１１２として、日時クラスであるプロパティ「日時」で定義する。クラス名１１１１が「位置情報コンテキスト」である他の１つのクラス定義として、そのプロパティ定義１１１２として、住所クラスであるプロパティ「位置」で定義する。クラス名１１１１が「位置情報コンテキスト」であるさらに他の１つのクラス定義として、そのプロパティ定義１１１２として、移動状況クラスであるプロパティ「移動状況」を定義する。

また例えば、クラス名１１１１が「日時」である１つのクラス定義として、メソッド定義１１１３として、日付クラスを取得するメソッド「日付（）」を定義する。また、クラス名１１１１が「日時」である他の１つのクラス定義として、メソッド定義１１１３として、時間クラスを取得するメソッド「時間（）」を定義する。さらに、クラス名１１１１が「日時」であるさらに他の１つのクラス定義として、メソッド定義１１１３として、曜日クラスを取得するメソッド「曜日（）」を定義する。

次に、コンテキスト保持手段１２が保持する情報の一般的な構成を、図３〜図６を用いて説明する。なお、具体的な構成例については、後述する動作の項で言及する。

コンテキスト保持手段１２は、図３に示すように、大きくは、コンテキスト情報１２１、ノード情報１２２、及び、アクセス情報１２３を保持する。

コンテキスト情報１２１は、０又は１以上のレコード１２１Ａ、１２１Ｂ、１２１Ｃ、…から構成されており、コンテキストを記述している。各レコードは、図４に示すように、ノードＩＤ１２１１、及び、１以上のプロパティ１２１２及び値１２１３の組、処理フラグ１２１４から構成される。ノードＩＤ１２１１、プロパティ１２１２及び値１２１３が、ＲＤＦのトリプルとなっており、ノードＩＤ１２１１が同一のＲＤＦのトリプルは、同一のレコードに記述されている。プロパティ１２１２の値１２１３としては、他のノードＩＤが記述されることもあり得る。処理フラグ１２１４は、ＲＤＦのトリプル単位に記述されるものであり、クライアント１からサーバ２へ、このＲＤＦのトリプルに関する情報をアップデートしたか否かが記述されるものである。

ノード情報１２２は、０又は１以上のレコード１２２Ａ、１２２Ｂ、１２２Ｃ、…から構成されており、コンテキスト情報１２１のＲＤＦのトリプルを規定するノードの情報が記述されている。各レコードは、図５に示すように、コンテキスト情報１２１のノードＩＤ１２１１あるいは値１２１３に対応するＩＤ１２２１、クラス１２２２、及び、値１２２３から構成されている。ここでも、ＩＤ１２２１、クラス１２２２、及び、値１２２３が、ＲＤＦのトリプルとなっている。

アクセス情報１２３は、０又は１以上のレコード１２３Ａ、１２３Ｂ、１２３Ｃ、…から構成されており、アクセス権を拒否したり許可したりする条件や、コンテキスト情報の記名（公開）有無などを記述するものである。各レコードは、図６に示すように、ＩＤ１２３１、対象ユーザ１２３２、アクセス権１２３３、匿名フラグ１２３４から構成される。ＩＤ１２３１には、ノードＩＤが記述され。対象ユーザ１２３２は、「全て」、「社外」、「社内」などの対象となるユーザを特定するフィールドである。アクセス権１２３３には、拒否又は許可が記述される。匿名フラグ１２３４は、ユーザＩＤの記名（公開）有無などが記述される。

プライバシーポリシー管理手段１３は、アクセス情報１２３を形成する基となるプライバシーポリシー情報１３１を保持するものであり、セキュリティポリシー管理手段１４は、アクセス情報１２３を形成する基となるセキュリティポリシー情報１４１を保持するものである。プライバシーポリシー情報１３１は、ユーザについての個人的の情報又は小グループの情報の保護のためのポリシー情報であり、セキュリティポリシー情報１４１は、全ユーザ又は多数のユーザ（例えば、全社的又は部門単位）について共通的に適用する情報保護のためのポリシー情報である。

プライバシーポリシー情報１３１は、１以上のレコード１３１Ａ、１３１Ｂ、１３１Ｃ、…から構成されている。各レコードは、図７に示すように、対象となるクラスあるいはキーワードを記述したノード条件１３１１、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ１３１２、読み出しを許可する、あるいは、許可しないを記述したアクセス権１３１３、匿名で公開するか記名で公開するかを記述した匿名フラグ１３１４から構成されている。

セキュリティポリシー情報１４１も、１以上のレコード１４１Ａ、１４１Ｂ、１４１Ｃ、…から構成されている。各レコードは、図８に示すように、対象となるクラスあるいはキーワードを記述したノード条件１４１１、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ１４１２、読み出しを許可する、あるいは、許可しないを記述したアクセス権１４１３、匿名で公開するか記名で公開するかを記述した匿名フラグ１４１４から構成されている。

センサ１６は、ＧＰＳセンサあるいは無線通信を利用した位置情報センサ、温度センサ、音響センサ、光度センサ、加速度センサなどである。センサ１６は、ユーザについてのコンテキストの取得に関係するものであれば、そのセンサの種類は問われないものである。当該クライアント１がパソコンなどの情報処理装置で構成されている場合、センサ１６は、情報処理装置に内蔵のものであっても良く、情報処理装置が有するＵＳＢ端子などに接続可能なものであっても良い。

アプリケーション１７は、メールソフト、電話ソフト、チャットソフト、文書作成ソフト、インターネットブラウザ、スケジューラなどのアプリケーションプログラムである。アプリケーション１７は、ユーザについてのコンテキストの取得に関係するものであれば、その種類は問われないものである。

コンテキスト推定手段１５は、センサ１６やアプリケーション１７からの情報から、コンテキストを推定するものである。推定方法については動作の項で明らかにする。

サーバ２は、コンテキストを受信し、要求に応じてコンテキストを送信するものである。サーバ２は、例えば、コンテキスト共有システム用のプログラムがインストールされた、通信機能を有するパソコンなどの情報処理装置が該当するが、コンテキストの共有機能から見た場合、機能的には、図１に示すような詳細構成を有する。

すなわち、サーバ２は、コンテキスト管理手段２１、各ユーザのコンテキストの情報を保持するコンテキスト保持手段２２、セキュリティポリシーを管理するセキュリティポリシー管理手段２４を有している。コンテキスト管理手段２１には、コンテキスト保持手段２２及びセキュリティポリシー管理手段２４が接続されている。

コンテキスト保持手段２２は、各ユーザについてのコンテキストに係る情報を共有して保持しているものである。コンテキスト保持手段２２は、図９に示すように、１以上のユーザＩＤ２２０、及び、各ユーザＩＤ２２０に対応したコンテキスト情報２２１、ノード情報２２２、アクセス情報２２３を保持するものである。

コンテキスト情報２２１は、図示は省略するが、クライアント１におけるコンテキスト情報１２１と同様の構成であり、０又は１以上のレコード２２１Ａ、２２１Ｂ、２２１Ｃ、…から構成され、各レコードは、ノードＩＤ２２１１、及び、１以上のプロパティ２２１２及び値２２１３の組から構成されている（図４参照）。

ノード情報２２２は、図示は省略するが、クライアント１におけるノード情報１２２と同様の構成であり、０又は１以上のレコード２２２Ａ、２２２Ｂ、２２２Ｃ、…から構成され、各レコードは、ＩＤ２２２１、クラス２２２２、値２２２３から構成されている（図５参照）。

アクセス情報２２３は、図示は省略するが、クライアント１におけるアクセス情報１２
と同様の構成であり、０又は１以上のレコード２２３Ａ、２２３Ｂ、２２３Ｃ、…から構成され、各レコードは、ＩＤ２２３１、対象ユーザ２２３２、アクセス権２２３３、匿名フラグ２２３４から構成されている（図６参照）。

セキュリティポリシー管理手段２４は、セキュリティポリシー情報２４１を保持しているものである。セキュリティポリシー情報２４１は、図示は省略するが、クライアント１におけるセキュリティポリシー情報１４１と同様の構成であり、１以上のレコード２４１Ａ、２４１Ｂ、２４１Ｃ、…から構成され、各レコードは、ノード条件２４１１、対象ユーザ２４１２、アクセス権２４１３、匿名フラグ２４１４から構成されている（図８参照）。

（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るコンテキスト共有システムの動作を、図面を参照しながら説明する。

まず最初に、サーバ２とクライアント１間でのセキュリティポリシーの統一動作について説明する。

クライアント１は、起動時には、図１０のシーケンス図に示すように、サーバ２にアクセスしてセキュリティポリシー情報２４１を取り込み（Ｓ１、Ｓ２）、当該クライアント１のセキュリティポリシー情報１４１と、取り込んだサーバ２のセキュリティポリシー情報２４１とが同一か否かを判定し（Ｓ３）、同一でない場合は、サーバ２のセキュリティポリシー情報２４１をコピーしてクライアント１のセキュリティポリシー情報１４１とする（Ｓ４）。なお、取り込みのためのセキュリティポリシー情報２４１のダウンロードと、両セキュリティポリシー情報１４１及び２４１の比較処理とを並行的に実行するものであっても良い。

また、サーバ２は、シーケンス図やフローチャートの図示は省略するが、サーバ２のセキュリティポリシー情報２４１が変更された場合には、各クライアント１Ａ、１Ｂ、１Ｃ、…にアクセスし、サーバ２のセキュリティポリシー情報２４１をコピーして与え、各クライアント１Ａ、１Ｂ、１Ｃ、…において、セキュリティポリシー情報１４１として格納させるようにする。

以上のような動作によって、コンテキスト共有システムにおけるセキュリティポリシーの統一を図ることができる。

次に、クライアント１におけるコンテキスト情報１２１の生成方法について、図１１を用いて説明する。なお、以下では、センサ１６が、ＧＰＳセンサあるいは無線通信を利用した位置情報センサであるとし、アプリケーション１７がメールソフトであるとして説明する。

センサ１６は、定期的に（例えば、１分おきに）現在位置データを取得し、取得した日時データと共にコンテキスト管理手段１１に送る（Ｓ５１）。例えば、「データ＝位置情報；日時＝２００６／１０／２２ １２：３４；緯度＝３５／３８／２６．１８５；経度＝１３９／４４／４９．４７」を送る。

コンテキスト管理手段１１は、センサ１６から送られたデータをコンテキスト推定手段１５に送り（Ｓ５２）、コンテキスト推定手段１５は、送られたデータに応じてコンテキストを推定し（Ｓ５３）、コンテキスト情報としてコンテキスト管理手段１１に返す（Ｓ５４）。

一方、アプリケーション１７は、メール送信時及びメール閲覧時に、あるいは、定期的に（例えば、１５分おきに）、送信メールあるいは既読メールの種別と、メール全体をコンテキスト管理手段１１に送る（Ｓ６１）。

このときにも、コンテキスト管理手段１１は、アプリケーション１７から送られたデータをコンテキスト推定手段１５に送り（Ｓ５２）、コンテキスト推定手段１５は、送られたデータに応じてコンテキストを推定し（Ｓ５３）、コンテキスト情報としてコンテキスト管理手段１１に返す（Ｓ５４）。

以下、コンテキスト推定手段１５の推定方法を説明する。

コンテキスト推定手段１５は、送られてきた位置情報データから位置情報コンテキストを推定する場合、まず、現在位置データが座標データの場合には、送られてきた位置情報データをキーとして、住所やランドマーク（例えば、東京駅、慶応義塾大学日吉キャンパス、東名高速道路海老名ＳＡなど）の情報を検索し、住所、及び、存在するならばランドマークを求める。コンテキスト推定手段１５は、送られてきた位置情報データが逆に住所又はランドマークの情報の場合は、それらをキーとして座標データを求める。

コンテキスト推定手段１５は、上述した推定時のデータ変換を、予め用意しておいた内部情報に基づいて行っても良く、また、汎用のＷｅｂサービスを利用して行っても良い。このような汎用のＷｅｂサービスとして、例えば、個人サイトのＧｅｏｃｏｄｉｎｇ（ｈｔｔｐ：／／ｗｗｗ．ｇｅｏｃｏｄｉｎｇ．ｊｐ／）や、ｋｎｅｃｈｔのＧｅｏｃｏｄｉｎｇ ＡＰＩ（ｈｔｔｐ：／／ａｐｉ．ｋｎｅｃｈｔ．ｊｐ／ｇｅｏｃｏｄｉｎｇ／）等を適用できる。

上述した位置データ「データ＝位置情報；日時＝２００６／１０／２２ １２：３４；緯度＝３５／３８／２６．１８５；経度＝１３９／４４／４９．４７」の例の場合、住所が「東京都港区芝浦４−１０−１６」、ランドマークが「沖電気工業（株）」になる。

次に、コンテキスト推定手段１５は、現在位置データの時系列（過去の現在位置データを例えば所定時間だけバッファリングしておく）から、移動状況（止まっているか、歩いているか、電車や車に乗っているか）を判定する。このような判定の方法としては、例えば、特開２００３−０７６８１８号公報に記載の方法を適用できる。例えば、現在位置データと直前の位置データとが同じであれば、速度が０であり、移動状況は「静止」になる。

その後、コンテキスト推定手段１５は、位置情報コンテキストとして、日時データ、その日時における位置の住所及びランドマーク、移動状況を、コンテキスト管理手段１１に返信する。上記の例では、データとして、「コンテキスト：位置情報；日時：２００６／１０／２２ １２：３４；住所＝東京都港区芝浦４−１０−１６；ランドマーク＝沖電気工業（株）；移動状況＝静止」を返信する。

一方、コンテキスト推定手段１５は、メールの種別とメール全体が送られてきたときには、以下のような推定動作を行う。以下では、例えば、「データ＝メール；種別＝受信；送信日時＝２００６／１０／２２ １２：３４；送信者＝田中一郎；送信アドレス＝ｉｃｈｉｒｏ．ｔａｎａｋａ＠ａｂｃ．ｃｏｍ；受信者＝山田太郎；受信アドレス＝ｔａｒｏ．ｙａｍａｄａ＠ｘｙｚ．ｃｏｍ；タイトル＝１１／１打合せについて；メール本文＝田中＠ＡＢＣ杜です。１１／１の打合せは、佐藤も参加し、ＣＴＩの…」が送られたとする。

コンテキスト推定手段１５は、コンテキスト管理手段１１を介して送られたメールのデータから、メール履歴コンテキストを推定する（Ｓ５３）。

まず、メールアドレスから社内、社外などの属性を求める。上記の例では、送信アドレスの＠以下の［ａｂｃ］などから送信者の属性が「社外」であると推定する。次に、メール本文から、固有表現抽出技術及びキーワード抽出技術を用いて、キーワードとしての固有表現（人名、組織名、地名、製品名、イベント名、住所、電話番号、メールアドレスなど）、及び、その他のキーワードを抽出する。また、メールタイトルからも、キーワードとしての固有表現、及び、その他のキーワードを抽出する。

固有表現の抽出方法としては、例えば、特開２００４−０４６７７５号公報に記載の方法を適用できる。上記の例では、メール本文から、日付として「１１／１」、人名として「田中」及び「佐藤」、組織名として「ＡＢＣ杜」が抽出され、メールタイトルから、日時として「１１／１」が抽出される。キーワードの抽出方法としては、例えば、特開２００２２３５０６１号公報に記載の方法を適用できる。上記の例では、メール本文から、「打合せ」、「ＣＴＩ」が抽出され、メールタイトルから、「打合せ」が抽出される。

その後、コンテキスト推定手段１５は、メール履歴コンテキストとして、メール種別、送信日時、受信日時、メール送信者、受信者、タイトル、キーワード（固有表現及びその他のキーワード）のデータ等を含む「コンテキスト＝メール履歴；種別＝受信；日時＝２００６／１０／２２ １２：３４；送信者＝田中一郎；送信者属性＝社外：受信者＝山田太郎；タイトル＝１１／１打合せについて；キーワード＝１１／１（日付）、田中（人名）、佐藤（人名）、ＡＢＣ社（組織名）、打合せ（未設定）、ＣＴＩ（未設定）」をコンテキスト管理手段１１に返信する。

コンテキスト管理手段１１は、返信されたコンテキストを、コンテキスト情報１２１に対応する形式に変換して、コンテキスト保持手段１２により保存する（Ｓ５４）。以下、かかるステップＳ５４の動作を詳述する。

コンテキスト管理手段１１は、まず、コンテキスト保持手段１２によって、コンテキスト情報１２１及びノード情報１２２を取得する。

送られてきたコンテキストが、上述した位置情報コンテキストの例では、ノード情報１２２に、図１２（Ｂ）に示すように、以下のような５つのレコード１２２Ａ〜１２２Ｅを作成する。レコード１２２Ａは、ＩＤ１２２１が重複しない固有のＩＤ（例えば、「ＣＰ０００１」を有し）、クラス１２２２が「位置情報コンテキスト」、値１２２３が「なし（空白）」である。レコード１２２Ｂは、ＩＤ１２２１が重複しない固有のＩＤ（例えば、「Ｄ０００１」）、クラス１２２２が「日時」、値１２２３が送信された日時情報（「２００６／１０／２２ １２：３４」）である。レコード１２２Ｃは、ＩＤ１２２１が重複しない固有のＩＤ（例えば、「Ｐ０００１」）、クラス１２２２が「住所」、値１２２３が送信された住所（「東京都港区芝浦４−１０−１６」）である。レコード１２２Ｄは、ＩＤ１２２１が重複しない固有のＩＤ（例えば、「Ｐ０００２」）、クラス１２２２が「ランドマーク」、値１２２３が送信されたランドマーク（「沖電気工業（株）」）である。レコード１２２Ｅは、ＩＤ１２２１が重複しない固有のＩＤ（例えば、「Ｃ０００１」）、クラス１２２２が「移動状況」、値１２２３が送信された移動状況（例えば、「静止」）である。

但し、ノード情報１２２のレコードを作成する際、クラス１２２２が同じ、かつ、値１２２３が同じレコードが存在する場合は、新しいレコードを作成しない。

また、図１２（Ａ）に示すようなコンテキスト情報１２１のレコード１２１Ａを作成する。コンテキスト情報１２１の新たなレコード１２１ＡにおけるノードＩＤ１２１１として、ノード情報１２２における先頭レコード１２２ＡのＩＤ１２２１と同じ値、すなわち「ＣＰ０００１」を挿入する。また、コンテキスト情報１２１のプロパティ１２１２と値１２１３の組として、ノード情報１２２における２番目のレコード１２２Ｂに対応した「日時」及び「Ｄ０００１」、ノード情報１２２における３番目のレコード１２２Ｃに対応した「位置」及び「Ｐ０００１」、ノード情報１２２における４番目のレコード１２２Ｄに対応した「位置」及び「Ｐ０００２」、ノード情報１２２における５番目のレコード１２２Ｅに対応した「移動状況」及び「ＣＯ００１」を設け、処理フラグ１２１４を「未処理」とする。

上記において、クラス「住所」や「ランドマーク」のプロパティを「位置」にすることなどは、図２に示すクラス定義情報によって定義されている。

図１２に示すコンテキスト情報１２１及びノード情報１２２の構成を、ノード及びアークを用いたグラフで描くと、図１３に示すようなる。すなわち、「ノード、アーク、ノード」をＲＤＦのトリプルとしたＲＤＦのグラフとなっている。

図１４は、上述したメール履歴コンテキストの例に対して、取得されたコンテキスト情報１２１及びノード情報１２２を示している。なお、図１４は、コンテキスト情報１２１及びノード情報１２２共に、一部のレコードについて示している。

メール履歴コンテキストの例では、ノード情報１２２に、ＩＤ１２２１が「ＣＭ０００１」、クラス１２２２が「メール履歴コンテキスト」、値１２２３がなしであるレコード１２２Ｆ、及び、ＩＤ１２２１が「ＭＴ０００１」、クラス１２２２が「メール送受信種別」、値１２２３が「受信」であるレコード１２２Ｇを作成し、また、ノード情報１２２に、ＩＤ１２２１が「Ｄ０００２」、クラス１２２２が「日時」、値１２２３が「１０／２２ １２：３４」であるレコード１２２Ｈを作成し、以下、同様に、送信者、送信アドレス、受信者、受信アドレス、タイトル、キーワードについてのノード情報１２２のレコードを作成する。その際、キーワードについては、それぞれのキーワードについて、ノード情報１２２に、ＩＤ１２２１が「Ｋ０００１」、クラス１２２２が「人」、値１２２３が「田中」であるレコード１２２Ｉ、ＩＤ１２２１が「Ｋ０００２」、クラス１２２２が「人」、値１２２３が「佐藤」であるレコード１２２Ｊ、…を作成する。その後、コンテキスト情報１２１に、ノードＩＤ１２１１が「ＣＭ０００１」、プロパティ１２１２と値１２１３の組が「種別」、「ＭＴ０００１」、「送受信日時」、「Ｄ０００２」、「キーワード」、「Ｋ０００１」、「キーワード」、「Ｋ０００２」…（以下、略）、処理フラグ１２１４が「未処理」であるレコード１２１Ｂを作成する。

コンテキスト情報１２１及びノード情報１２２を作成（取得）する処理が終了すると、コンテキスト保持手段１２は、コンテキスト情報１２１及びノード情報１２２を、例えば、ファイルとしてデータベースに保存する。

次に、プライバシー及びセキュリティを考慮したコンテキストの送信処理の説明に先立ち、セキュリティポリシーとプライバシーポリシーの設定について順に説明する。

セキュリティポリシーとして、「個人情報は社内であっても一切流通させない」、「従業員の位置情報は社内で共有し、社外へは社内（本社、支社を含む）の位置情報のみ公開する」、「メール履歴は、送受信の区別、受信あるいは送信日時、タイトル、キーワードだけを社内公開する」を設定する場合を、図１５に示す設定例を参照しながら説明する。サーバ２におけるセキュリティポリシー情報２４１は、ユーザ（管理者）が所定の記述方法に従って記述するものである。

なお、サーバ２におけるセキュリティポリシー情報２４１は、上述したように、図８に示すクライアント１におけるセキュリティポリシー情報１４１と同様の構成であり、各レコードが、ノード条件２４１１、対象ユーザ２４１２、アクセス権２４１３、匿名フラグ２４１４から構成されている。

ユーザ（管理者）は、まず、サーバ２のセキュリティポリシー情報２４１に、ノード条件２４１１が「Ｘ；Ｘ．クラス＝＝人」、対象ユーザ２４１２が「すべて」、アクセス権２４１３が「拒否」、匿名フラグ２４１４が「未設定」であるレコード２４１Ａを作成する。これは、「個人情報は社内であっても一切流通させない」を意味している。

次に、ノード条件２４１１が「Ｘ；Ｘ．クラス＝＝位置情報コンテキスト」、対象ユーザ２４１２が「社内」、アクセス権２４１３が「許可」、匿名フラグ２４１４が「記名」であるレコード２４１Ｂと、ノード条件２４１１が「Ｘ；Ｘ．クラス＝＝位置情報コンテキスト ＡＮＤ （Ｘ，位置，＠社内ランドマーク）」、対象ユーザ２４１２が「社外」、アクセス権２４１３が「許可」、匿名フラグ２４１４が「記名」であるレコード２４１Ｃと、ノード条件２４１１が「Ｘ；Ｘ．クラス＝＝位置情報コンテキスト」、対象ユーザ２４１２が「社外」、アクセス権２４１３が「拒否」、匿名フラグ２４１４が「未設定」であるレコード２４１Ｄとを作成する。これらのレコード２４１Ｂ〜２４１Ｄは、「従業員の位置情報は社内で共有し、社外へは社内（本社、支社を含む）の位置情報のみ公開する」を意味している。

さらに、ノード条件２４１１が「Ｘ，Ｙ，Ｚ，Ｕ，Ｖ；Ｘ．クラス＝＝メール履歴コンテキスト ＡＮＤ （Ｘ，種別，Ｙ） ＡＮＤ （Ｘ，日時，Ｚ） ＡＮＤ （Ｘ，タイトル，Ｕ） ＡＮＤ （Ｘ，キーワード，Ｖ）」、対象ユーザ２４１２が「社内」、アクセス権２４１３が「許可」、匿名フラグ２４１４が「記名」であるレコード２４１Ｅと、ノード条件２４１１が「Ｙ；Ｘ．クラス＝＝メール履歴コンテキスト ＡＮＤ （Ｘ，＊，Ｙ）」、対象ユーザ２４１２が「社内」、アクセス権２４１３が「拒否」、匿名フラグ２４１４が「未設定」であるレコード２４１Ｆとを作成する。これらレコード２４１Ｅ及び２４１Ｆは、「メール履歴は、送受信の区別、受信あるいは送信日時、タイトル、キーワードだけを社内公開し、それ以外は非公開」を意味している。

セキュリティポリシー情報２４１の表記において、「Ｘ；」は、Ｘがポリシーを設定する対象のノードであることを意味し、「Ｘ．クラス＝＝」は、あるノードのクラスが記述された値と等しいことを意味し、図１５には存在しないが、「Ｘ＝＝」は、あるノードの値が記述された値と等しいことを意味する。また、例えば、「（Ｘ，位置，値）」は対象であるノードから、クラスが「位置」であるプロパティで接続されたノードがある値であることを意味し、「＊」はすべてとマッチすることを意味する。「＠社内ランドマーク」は、社内のランドマークの集合、すなわち、「自席」、「第１会議室」、「第２会議室」、「支店１」、「支店２」及び「社内」である。各レコードは、先頭側ほど優先度が高いものとする。

各クライアント１のセキュリティポリシー情報１４１は、上述したセキュリティポリシーの統一方法により、サーバ２のセキュリティポリシー２４１と同じ内容になる。

次に、クライアント１に、プライバシーポリシーとして、「位置情報は、平日９時から１７時３０分は社内公開するが、それ以外は社内を含め非公開」を設定する場合を、図１６に示す設定例を参照しながら説明する。クライアント１のプライバシーポリシーは、クライアント１のユーザが所定の記述方法に従って記述するものである。

上述したように、クライアント１におけるプライバシーポリシー情報１３１は、各レコードが、ノード条件１３１１、対象ユーザ１３１２、アクセス権１３１３、匿名フラグ１３１４から構成されている。

クライアント１のユーザは、クライアント１のプライバシーポリシー情報１３１に、ノード条件１３１１が「Ｘ，Ｙ，Ｚ，Ｕ；Ｘ．クラス＝＝位置情報コンテキスト ＡＮＤ （Ｘ，日時，Ｙ） ＡＮＤ （Ｙ，曜日，Ｚ） ＡＮＤ Ｚ＝＝＠平日 ＡＮＤ （Ｙ，時間，Ｕ） ＡＮＤ Ｕ＞＝時間（９時） ＡＮＤ Ｕ＜＝時間（１７時３０分）」、対象ユーザ１３１２が「社内」、アクセス権１３１３が「許可」、匿名フラグ１３１４が「記名」であるレコード１３１Ａ、及び、ノード条件１３１１が「Ｘ； Ｘ．クラス＝＝位置情報コンテキスト」、対象ユーザ１３１２が「すべて」、アクセス権１３１３が「拒杏」、匿名フラ１３１４が「未設定」であるレコード１３１Ｂを作成する。

ここで、「（Ｙ，曜日，Ｚ）」は、ノード（Ｙ）から「曜日」プロパティで接続された値のノード（Ｚ）を意味するが、「日時」クラスは「曜日」クラスを返すメソッド「曜日（）」がクラス定義情報１１１に定義されており、「曜日」プロパティが存在しない場合は、このメソッドで「明日」クラスのノードを取得するものとする。また、「時間（９時）」は、９時に対応するノード（時間クラス）を返すコンストラクタで、クラス定義情報１１１に定義されているものとする。

以上のように設定されたセキュリティポリシー及びプライバシーポリシーが考慮（参照）されて、コンテキストの送信処理が実行される。

次に、コンテキストの公開処理について、図１７を参照しながら説明する。コンテキストの公開処理では、コンテキスト管理手段１１は、定期的に（例えば、１５分おきに）、コンテキスト情報１２１に対して、セキュリティポリシー、プライバシーポリシーの順にマッチングを行い、コンテキスト情報の公開範囲を決定する。

コンテキスト管理手段１１は、まず、コンテキスト情報１２１のレコードを順に参照し、そのレコードの処理フラグ１２１４が「未処理」の場合に、ノード情報１２２の情報を参照し、処理フラグ１２１４を「処理済」に変更する（Ｓ１０１）。図１２（Ａ）の例では、レコード１２１Ａを参照し、処理フラグ１２１４が「未処理」であるため、ノードＩＤ１２１１、すなわち「ＣＰ０００１」、並びに、プロパティ１２１２と値１２１３の組、すなわち、「日時」及び「Ｄ０００１」、「住所」及び「Ｐ０００１」、「ランドマーク」及び「Ｐ０００２」、「移動状況」及び「Ｃ０００１」を参照し、ノード情報１２２の該当するＩＤ１２２１のレコード、すなわち、ＩＤ１２２１が「ＣＰ０００１」、クラス１２２２が「位置情報コンテキスト」、値が「ＣＰ０００１」であるノード情報１２２のレコード１２２Ａ、ＩＤ１２２１が「Ｄ０００１」、クラス１２２が「日時」、値が日時情報であるノード情報１２２のレコード１２２Ｂを参照する。

次に、参照したコンテキスト情報１２１のレコード、ノード情報１２２のレコードについて、セキュリティポリシー情報１４１の各レコード１４１Ａ、１４１Ｂ、１４１Ｃ、…のノード条件１４１１とのマッチングを順に行い、マッチする場合は、アクセス情報１２３にレコードを作成する（Ｓ１０２）。

図１８（Ａ）は、上述の例の場合に、アクセス情報１２３に、作成されたレコードの例を示す説明図である。

上述の例では、コンテキスト情報１２１のレコード１２１Ａが、セキュリティポリシー情報１４１のレコード１４１Ｂのノード条件１４１１「Ｘ．クラス＝＝位置情報コンテキスト」とマッチするため、ＩＤ１２３１がマッチしたコンテキスト情報１２１のレコードのＩＤ１２２１「ＣＰ０００１」が設定され、対象ユーザ１２３２、アクセス権１２３３、匿名フラグ１２３４がそれぞれマッチしたセキュリティポリシー情報１４１のレコードの対象ユーザ１４１２「社内」、アクセス権１４１３「許可」、匿名フラグ１４１４「記名」が設定されたレコード１２３Ａをアクセス情報１２３に作成する。但し、アクセス情報１２３にレコードを作成する際、ＩＤ１２３１及び対象ユーザ１２３２が同じレコードが既に存在する場合には、新しいレコードを作成しない。

同様に、ノード情報１２２のレコード１２２Ａが、セキュリティポリシー情報１４１のレコード１４１Ｄのノード条件１４１１「Ｘ．クラス＝＝位置情報コンテキスト」とマッチするため、ＩＤ１２３１が「ＣＰ０００１」、対象ユーザ１２３２が「社外」、アクセス権１２３３が「拒否」、匿名フラグ１２３４が「未設定」であるレコード１２３Ｂをアクセス情報１２３に作成する。

同様に、プライバシーポリシーとマッチングを行う（Ｓ１０３）。上述の例では、１０月２２日が日曜日の場合、ノード情報１２２のレコード１２２Ａは、プライバシーポリシー情報１３１のレコード１３１Ｂのノード条件１３１１「Ｘ．クラス＝＝位置情報コンテキスト」とマッチするので、ＩＤ１２３１が「ＣＰ０００１」、対象ユーザ１２３２が「すべて」、アクセス権１２３３が「拒否」、匿名フラグ１２３４が「未設定」であるレコード１２３Ｃをアクセス情報１２３に作成する。

次に、コンテキスト管理手段１１は、アクセス情報１２３の各レコードについて、ＩＤ１２３１が同一のレコードについて、論理積を求め、求めたものに元のレコードを置換する（Ｓ１０４）。図１８（Ｂ）は、図１８（Ａ）を置換したものである。

そのために、まず、各レコードのアクセス権１２３３が「拒否」の場合、対象ユーザ１２３２を補集合に変更し、アクセス権１２３３を「許可」に設定する。上述の例では、レコード１２３Ｂの対象ユーザ１２３２が「ＮＯＴ社外」、アクセス権１２３３が「許可」に、レコード１２３Ｃの対象ユーザ１２３２が「なし」、アクセス権１２３３が「許可」に変更される。論理積を求めると、対象ユーザ１２３２が「社内 ＡＮＤ ＮＯＴ社外 ＡＮＤ なし」、すなわち「なし」となり、アクセス情報１２３のレコードは、ＩＤ１２３１が「ＣＰ０００１」、対象ユーザ１２３２が「なし」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「未設定」となる。これは、１０月２２日の１２時３４分に東京都港区芝浦４−１０−１６に居た（静止して）ことを示す位置情報のコンテキストは、その日が日曜日なので、プライバシーポリシーによって公開されないことを意味している。

メール履歴コンテキストの例については、セキュリティポリシーとのマッチングを行うと、送受信の区別、送信あるいは受信日時、タイトル、キーワードに対応するノードついては、セキュリティポリシー情報１４１のレコード１４１Ｅ、１４１Ｆ、１４１Ｇ、１４１Ｈにそれぞれマッチし、送信者、送信アドレス、受信者、受信アドレス、対応するノードついては、セキュリティポリシー情報１４１のレコード１４１Ｉにマッチする。

論理積の処理後には、アクセス情報１２３に、ＩＤ１２３１が「ＣＭ０００１」、対象ユーザ１２３２が「社内」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「記名」であるレコードと、ＩＤ１２３１が送受信の区別、送信あるいは受信日時、タイトル、キーワードに対応するノードのＩＤ、対象ユーザ１２３２が「社内」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「記名」であるそれぞれのレコードと、ＩＤ１２３１が送信者、送信アドレス、受信者、受信アドレス、本文のノードに対応するＩＤ、対象ユーザ１２３２が「なし」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「未設定」であるレコードとの３個のレコードが作成される。

その後、コンテキスト管理手段１１は、アクセス情報１２３を基に、非公開以外のコンテキスト情報をユーザＩＤ１０と共にサーバ２に送る（Ｓ１０５）。

上述の例では、アクセス情報１２３のＩＤ１２３１が「ＣＰ０００１」であるレコードは、対象ユーザ１２３２が「なし」のためにコンテキスト情報は送らず、ＩＤ１２３１が「ＣＭ０００１」であるレコードは、対象ユーザ１２３２が「社内」のため、当該レコード、及び、コンテキスト情報１２１の関連するレコード１２１Ｂ、ノード情報１２２の関連するレコードをユーザＩＤ１０（例えば、「Ｕ０００１」）と共にサーバ２に送る。但し、ノード情報１２２、アクセス情報１２３の関連するレコードのＩＤ１２２１、１２３１が、アクセス情報１２３のレコードで対象ユーザ１２３２が「なし」のレコードである場合には、そのノード情報１２２、アクセス情報１２３のレコードは送らない。

次に、サーバ２における処理を、図１９のフローチャートを用いて説明する、
サーバ２は、クライアント１から、ユーザＩＤ、コンテキスト情報のレコード、ノード情報のレコード、及び、アクセス情報のレコードを受け取ると、コンテキスト管理手段２１は、コンテキスト保持手段２２により、受け取ったユーザＩＤに対応するコンテキスト情報２２１、ノード情報２２２、アクセス情報２２３にそれぞれ格納する（Ｓ２０１）。

上述の例では、ユーザＩＤ「Ｕ０００１」に対応するコンテキスト情報２２１として、ノードＩＤ２２１１が「ＣＭ０００１」、プロパティ２２１２と値２２１３の組が、「送受信日時」及び「Ｄ０００２」、「キーワード」及び「Ｋ０００１」、「キーワード」及び「Ｋ０００２」、「キーワード」及び「Ｋ０００３」、「キーワード」及び「Ｋ０００４」であるレコード、並びに、関連するノード情報２２２、及び、アクセス情報２２３として、ＩＤ２２３１が「ＣＭ０００１」、ユーザ情報２２３２が「社内」、アクセス権２２３３が「許可」、匿名フラグ２２３４が「記名」であるレコードが格納される。

ユーザがサーバ２にアクセスし、コンテキストを要求すると、アクセス権に応じて、コンテキストを返す（Ｓ２０２）。

クライアント１Ｂから、社内のユーザ（ＩＤ＝Ｕ０００２）が、ユーザＩＤ「Ｕ０００１」の現在（１０月２２日１２時４５分）の位置情報コンテキストを要求すると、クライアント１Ｂは、「要求ユーザＩＤ：Ｕ０００２；要求コンテキスト＝位置情報コンテキスト；ユーザＩＤ＝Ｕ０００１」をサーバ２に送る。

サーバ２は、「Ｕ０００１」について、一定時間（例えば、クライアント１がサーバ２にコンテキスト情報を送信する時間間隔である１５分）内のコンテキスト情報が見つからないため、「ユーザＩＤ＝Ｕ０００１；クラス＝位置情報コンテキスト；結果＝なし」を返す。

また、社内のユーザ（ＩＤ＝Ｕ０００２）が、ユーザＩＤ「Ｕ０００１」のメール履歴コンテキストを要求した場合は、一定時間内のコンテキストとして、コンテキスト情報２２１にＩＤ２２３１が「ＣＭ０００１」であるレコードがあり、対応するアクセス情報２２３の対象ユーザ２２３２が「社内」、アクセス権２２３３が「許可」、匿名フラグ２２３４が「記名」であるので、コンテキスト情報として「ユーザＩＤ＝Ｕ０００１；クラス＝メール履歴コンテキスト；種別＝受信；日時：２００６／１０／２２ １２：３４；タイトル＝１１／１打合せについて；キーワード＝１１／１（日付）、ＡＢＣ社（組織名）、打合せ（未設定）、ＣＴＩ（未設定）」を返す。

別の例として、日時が１０月２３日（月曜日）であり、その他が同じ内容である位置情報コンテキスト（１０月２３日の１２時３４分に東京都港区芝浦４−１０−１６に居た（静止して）；ＩＤ１２１１を「ＣＰ０００２」とする）の場合は、クライアント１でコンテキスト情報とプライバシーポリシーのマッチングにおいて、ノード情報１２２のレコードは、セキュリティポリシー情報１３１のレコード１３１Ａのノード条件１３１１「Ｘ．クラス＝＝位置情報コンテキスト ＡＮＤ （Ｘ，日時，Ｙ） ＡＮＤ （Ｙ，曜日，Ｚ） ＡＮＤ Ｚ＝＝＠平日 ＡＮＤ （Ｙ，時間，Ｕ） ＡＮＤ Ｕ＞＝時間（９時） ＡＮＤ Ｕ＜＝時間（１７時３０分）」とマッチし、アクセス情報１２３に、ＩＤ１２３１が「ＣＰ０００２」、対象ユーザ１２３２が「社内」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「記名」であるレコード１２３Ｄを作成し、論理積は、対象ユーザ１２３２が「社内 ＡＮＤ ＮＯＴ 社外 ＡＮＤ 社内」、すなわち「社内」となり、アクセス情報１２３のレコードは、ＩＤ１２３１が「ＣＰ０００２」、対象ユーザ１２３２が「社内」、アクセス権１２３３が「許可」、匿名フラグ１２３４が「記名」となる。

このコンテキストがサーバ２に格納されている場合、クライアント１Ｂから、社内のユーザ（ＩＤ＝Ｕ０００２）が、ユーザＩＤ「Ｕ０００１」の現在（１０月２３日１２時４５分）の位置情報コンテキストを要求すると、一定時間内のコンテキストとして、コンテキスト情報２２１にＩＤ２２１１が「ＣＰ０００２」であるレコードがあり、対応するアクセス情報２２３の対象ユーザ２２３２が「社内」、アクセス権２２３３が「許可」、匿名フラグ２２３４が「記名」であるので、コンテキスト情報として「ユーザＩＤ＝Ｕ０００１；クラス＝位置情報コンテキスト；日時＝２００６／１０／２３ １２：３４；住所＝東京都港区芝浦４−１０−１６；ランドマーク＝沖電気工業（株）；移動状況＝静止」を返す。

（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、コンテキスト情報１２１を、ノードＩＤ１２１１、プロパティ１２１２、値１２１３から構成し、ノード情報１２２を、ＩＤ１２２１、クラス１２２２、値１２２３から構成し、セキュリティポリシー情報１４１を、ノード条件１４１１、対象ユーザ１４１２、アクセス権１４１３から構成し、プライバシーポリシー情報１３１も、ノード条件１３１１、対象ユーザ１３１２、アクセス権１３１３から構成するようにしたので、公開あるいは非公開するコンテキストのクラスを指定したり、値を指定したり、あるノードの条件を指定したりすることが可能となる、という効果が得られる。

これにより、例えば、「個人情報は社内であっても一切流通させない」、「従業員の位置情報は社内で共有し、社外へは社内（本社、支社を含む）の位置情報のみ公開する」、「メール履歴は、送受信の区別、受信あるいは送信日時、タイトル、キーワードだけを社内公開する」、「位置情報は、平日の９時から１７時３０分は社内公開するが、それ以外は社内を含め非公開」といった複雑なセキュリティポリシー、プライバシーポリシーの設定が可能になる、という効果が得られる。

また、クラスとして、「人」、「氏名」、「住所」、「電話番号」などを用意し、コンテキスト推定手段１５に、クラスに応じたキーワードを抽出する固有表現の抽出技術を用いることにより、テキスト部分から抽出したキーワードをコンテキストとした場合に、コンテキストを公開する際、一般のキーワードは公開しても個人情報だけを非公開にすることが可能になり、セキュリティやプライバシーを守りつつ、最大限のコンテキストを公開できるという効果が得られる。

（Ｂ）第２の実施形態
次に、本発明によるコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバの第２の実施形態を、図面を参照しながら説明する。

第２の実施形態に係るコンテキスト共有システムも、その構成は、第１の実施形態とほぼ同様であるが、図２０に示すように、アプリケーション１７とコンテキスト推定手段１５が接続され、アプリケーション１７からコンテキスト推定手段１５を呼び出せる点が第１の実施形態と異なっている。また、第２の実施形態は、アプリケーション１７が、コンテキスト管理手段１１を介して、サーバ２にコンテキストを要求して受け取ることができるものとする。

第２の実施形態の場合、サーバ２は、条件を付加したコンテキストの要求を受け付け、条件にマッチしたコンテキストを返す機能を有するものとする。

クライアント１のアプリケーション１７が、第１の実施形態の場合と同様に、メールソフトであるとして、特徴的な動作の一例を説明する。なお、図２１は、この特徴的な動作例を示すシーケンス図である。

メールソフト（アプリケーション１７）は、メールを送信する際、まず、コンテキスト推定手段１５を呼び出して、そのメールのコンテキスト（メール履歴コンテキスト）を得る。

例えば、宛先が課長（鈴木次郎）、タイトルが「ＡＢＣ社打合せ」、本文が「ＡＢＣ社から連絡があり……」とすると、アプリケーション１７はメールデータをコンテキスト推定手段１５に送り、コンテキスト推定手段１５は、組織名として「ＡＢＣ社」を抽出し、コンテキストとして、「コンテキスト＝メール履歴；種別＝未送信；日時＝２００６／１０／２２ １５：００；送信者＝山田太郎；受信者＝鈴木二郎；受信者属性＝社内；タイトル＝ＡＢＣ社打合せ；キーワード＝ＡＢＣ社（組織）；…」をアプリケーション１７に返す（Ｓ３０１）。

その後、アプリケーション１７は、サーバ２を呼び出し、送信するメールのメール履歴コンテキストに応じたコンテキストを得る（Ｓ３０２）。

まず、アプリケーション１７は、例えば、送信するメールのメール履歴コンテキストのキーワード「ＡＢＣ杜」、コンテキストの公開範囲として受信者属性「社内」を条件として要求データに加え、「要求ユーザＩＤ＝Ｕ０００１；要求コンテキスト＝＊；ユーザＩＤ＝Ｕ０００１；キーワード＝ＡＢＣ社；公開範囲＝社内」をサーバ２に送る。ここで、要求ユーザＩＤとユーザＩＤが共に「Ｕ０００１」であるのは、自分自身のコンテキストを要求していることを意味し、「要求コンテキスト＝＊」は、すべてのコンテキストを要求していることを意味している。

サーバ２は、ユーザ「Ｕ０００１」に関するコンテキストから、キーワード「ＡＢＣ社」を含むものを検索し、「ユーザＩＤ＝Ｕ０００１；クラス＝メール履歴コンテキスト；種別＝受信；日時＝２００６／１０／２２ １２：３４；タイトル＝１１／１ 打合せについて；キーワード＝１１／１（日付）、ＡＢＣ社（組織名）、打合せ（未設定）、ＣＴＩ（未設定）、…」を返す。仮に、このときの条件として、他のキーワード「ＸＹＺ社」が要求された場合には、キーワードにマッチするコンテキストが見つからず、サーバ２は、「ユーザＩＤ＝Ｕ０００１；クラス＝メール履歴コンテキスト；結果＝なし」を返す。

アプリケーション１７は、得られたコンテキスト情報を、送信するメールに付与して送信する（Ｓ３０３）。

第２の実施形態によれば、サーバ２に、条件を付加したコンテキストの要求を受け付け、条件にマッチしたコンテキストを返す機能を有するようにしたので、その機能を利用したサービスが可能となる。

例えば、送信するメールに関する自分自身のコンテキストを得て、送信メールに付与することにより、相手に自分のコンテキストを伝え、コミュニケーションを効率化させることができる。

（Ｃ）第３の実施形態
次に、本発明によるコンテキスト共有システム、コンテキスト共有方法、クライアント及びサーバの第３の実施形態を、図面を参照しながら説明する。

第３の実施形態に係るコンテキスト共有システムも、その構成は、第２の実施形態とほぼ同様である。第３の実施形態の場合、サーバ２は、ユーザＩＤを指定しないコンテキストの要求を受け付け、条件にマッチした複数ユーザのコンテキストを返す機能を有する点が、既述した実施形態と異なっている。

クライアント１のアプリケーション１７が、プレゼンテーションソフトであるとして、第３の実施形態での特徴的な動作例を説明する。なお、図２２は、この特徴的な動作例を示すシーケンス図である。

ユーザが資料を作成する際、プレゼンテーションソフト（アプリケーション１７）は、サーバ２を呼び出し、ユーザが指定したキーワードに関する匿名コンテキストを得る。

まず、アプリケーション１７は、例えば、キーワード「ＣＴＩ」を条件として要求データに加え、「要求ユーザＩＤ＝Ｕ０００１；要求コンテキスト＝＊；匿名フラグ＝ＯＮ；（Ｘ；Ｘ．クラス＝人 ＡＮＤ Ｘ，スケジュール，Ｙ） ＡＮＤ （Ｙ，日時，１０／２５ １０：００） ＡＮＤ （Ｙ，タイトル，ＡＢＣ社事前打合せ））；キーワード＝ＣＴＩ」をサーバ２に送る（Ｓ４０１）。ここで、「匿名フラグ＝ＯＮ」は匿名コンテキストを意味し、「（Ｘ；Ｘ．クラス＝人…）」は、会議参加予定者のコンテキストを要求していることを意味している。

サーバ２は、キーワード「ＣＴＩ」を含むコンテキストを検索し、マッチするコンテキストがある場合には、仮のユーザＩＤを付与し、例えば、「クラス＝メール履歴コンテキスト；匿名ユーザＩＤ＝ＵＴＭＰ０００１；種別＝受信；日時＝２００６／１０／２２ １２：３４；タイトル；１１／１打合せについて；キーワード＝１１／１（日付）、ＡＢＣ社（組織名）、打合せ（未設定）、ＣＴＩ（未設定）、…；クラス＝ファイル履歴コンテキスト；匿名ユーザＩＤ＝ＵＴＭＰ０００２；種別＝書類；…；キーワード＝ＣＴＩ（未設定）」を返す（Ｓ４０２）。

アプリケーション１７は、「ＶｏＩＰ」についても、匿名のコンテキストを得る（Ｓ４０３、Ｓ４０４）。

アプリケーション１７は、得られたコンテキスト情報から、匿名ユーザＩＤ別のコンテキストを集計することにより、「ＣＴＩ」について２件、「ＶｏＩＰ」について１件のコンテキストがあることを表示する（Ｓ４０５）。

第３の実施形態によれば、サーバ２に、ユーザＩＤを指定しないコンテキストの要求を受け付け、条件にマッチした複数ユーザのコンテキストを返す機能を有するようにしたので、その機能を利用したサービスが可能となる。

例えば、資料作成中に、会議参加予定者のコンテキストを得て、キーワードごとの集計をすることにより、事前に会議参加者のキーワードに対する認知度を推定することが可能になり、コミュニケーションを効率化することができる。

（Ｄ）他の実施形態
上記各実施形態では、クライアント１のコンテキスト管理手段１１がコンテキスト情報をサーバ２に送信するものを示したが、これに代え、又は、これに加え、コンテキスト管理手段１１がコンテキスト情報をサーバ２に送信することなく、クライアント１内のアプリケーション１７の要求に応じて、公開可能なコンテキストを返すような動作モードを設けるようにしても良い。例えば、クライアント１が携帯電話の場合には、ユーザが常時クライアント１を持ち運ぶので、かかる機能は有効である。

また、上記各実施形態では、サーバに送信するコンテキストを自動的に推定して得るものを示したが、これに加え、ユーザの入力情報に応じてコンテキスト情報を得るようにしても良い。

さらに、上記各実施形態では、コンテキスト情報などの取得が定期的に実行されるものを示したが、コンテキスト情報の間欠的な取得が不定期的であっても良いことは勿論である。

さらにまた、上記各実施形態の説明においては、コンテキスト情報等の情報を、表形式的に図示して説明したが、その格納形式は表形式に限定されるものではなく、上述と同様な単位で区別できるのであれば他の格納形式であっても良い。なお、特許請求の範囲では便宜上「レコード」という用語を用いている。

第１の実施形態に係るコンテキスト共有システムの構成を示すブロック図である。 第１の実施形態のクライアントにおけるコンテキスト管理手段が管理するクラス定義情報の構成を示す説明図である。 第１の実施形態のクライアントにおけるコンテキスト保持手段が保持する情報の概略構成を示す説明図である。 第１の実施形態のクライアントにおけるコンテキスト情報の構成を示す説明図である。 第１の実施形態のクライアントにおけるノード情報の構成を示す説明図である。 第１の実施形態のクライアントにおけるアクセス情報の構成を示す説明図である。 第１の実施形態のクライアントにおけるプライバシーポリシー情報の構成を示す説明図である。 第１の実施形態のクライアントにおけるセキュリティポリシー情報の構成を示す説明図である。 第１の実施形態のサーバにおけるコンテキスト保持手段が保持する情報の概略構成を示す説明図である。 第１の実施形態のクライアントが起動時にセキュリティポリシー情報を確認する動作を示すシーケンス図である。 第１の実施形態のクライアントにおけるコンテキスト情報の生成方法を示すシーケンス図である。 第１の実施形態のクライアントにおけるコンテキスト情報及びノード情報の生成例（１）を示す説明図である。 図１２のコンテキスト情報をＲＤＦグラフで表現した説明図である。 第１の実施形態のクライアントにおけるコンテキスト情報及びノード情報の生成例（２）を示す説明図である。 第１の実施形態におけるセキュリティポリシーの設定例を示す説明図である。 第１の実施形態におけるプライバシーポリシーの設定例を示す説明図である。 第１の実施形態におけるコンテキストの公開処理を示すフローチャートである。 第１の実施形態のクライアントにおけるアクセス情報の生成例及び統合例（論理積例）を示す説明図である。 第１の実施形態に係るサーバの処理を示すフローチャートである。 第２の実施形態に係るコンテキスト共有システムの構成を示すブロック図である。 第２の実施形態のコンテキスト共有システムにおける特徴的な動作を示すシーケンス図である。 第３の実施形態のコンテキスト共有システムにおける特徴的な動作を示すシーケンス図である。

符号の説明

１（１Ａ、１Ｂ、１Ｃ、…）…クライアント、１０…ユーザＩＤ、１１…コンテキスト管理手段、１２…コンテキスト保持手段、１３…プライバシーポリシー管理手段、１４…セキュリティポリシー管理手段、１５…コンテキスト推定手段、１６…センサ、１７…アプリケーション、
２…サーバ、２１…コンテキス管理手段、２２…コンテキスト保持手段、２４…セキュリティポリシー管理手段。

Claims (8)

1. ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおいて、
   上記各クラアントが、
   ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、
   上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、
   ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報と
   を保持する第１のコンテキスト保持手段と、
   対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有する、プライバシーポリシー情報を管理するプライバシーポリシー管理手段と、
   コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信する第１のコンテキスト管理手段とを備え、
   上記サーバは、
   上記クライアントから送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を、ユーザごとに保持する第２のコンテキスト保持手段と、
   送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記第２のコンテキスト保持手段に保持させると共に、任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信する第２のコンテキスト管理手段とを備える
   ことを特徴としたコンテキスト共有システム。
2. 上記第２のコンテキスト管理手段は、任意のクライアントのユーザから、任意のユーザの、ある条件のコンテキストが要求された場合に、要求先のユーザのコンテキスト情報について指定された条件にマッチし、要求元ユーザにアクセス権が許可されているときに、要求されたコンテキスト情報を返信することを特徴とした請求項１に記載のコンテキスト共有システム。
3. 上記アクセス情報の各レコードはさらに匿名フラグを含むと共に、上記プライバシーポリシー情報の各レコードはさらに匿名フラグを含み、
   上記第２のコンテキスト管理手段は、任意のクライアントのユーザから、ユーザを指定せずに、ある条件のコンテキストが要求された場合に、すべてのコンテキスト情報に対して、指定された条件にマッチし、要求元ユーザのアクセス権が許可されている場合に、そのコンテキスト情報を返信することを特徴とした請求項１又は２に記載のコンテキスト共有システム。
4. ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有方法において、
   上記各クラアントは、コンテキストの送信を管理する第１のコンテキスト管理手段、コンテキストの情報を保持する第１のコンテキスト保持手段、プライバシーポリシーの情報を管理するプライバシーポリシー管理手段を有し、
   上記コンテキスト保持手段は、コンテキスト情報、ノード情報、及び、アクセス情報を保持し、
   上記コンテキスト情報は、ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有し、
   上記ノード情報は、上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有し、
   上記アクセス情報は、ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有し、
   上記プライバシーポリシー情報は、対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有し、
   上記第１のコンテキスト管理手段は、
   コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、
   作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信し、
   上記サーバは、第２のコンテキスト管理手段、及び、第２のコンテキスト保持手段を有し、
   上記第２のコンテキスト保持手段は、上記クライアントから送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を、ユーザごとに保持し、
   上記第２のコンテキスト管理手段は、
   送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記第２のコンテキスト保持手段に保持させると共に、
   任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信する
   ことを特徴としたコンテキスト共有方法。
5. 上記第２のコンテキスト管理手段は、任意のクライアントのユーザから、任意のユーザの、ある条件のコンテキストが要求された場合に、要求先のユーザのコンテキスト情報について指定された条件にマッチし、要求元ユーザにアクセス権が許可されているときに、要求されたコンテキスト情報を返信することを特徴とした請求項４に記載のコンテキスト共有方法。
6. 上記アクセス情報の各レコードはさらに匿名フラグを含むと共に、上記プライバシーポリシー情報の各レコードはさらに匿名フラグを含み、
   上記第２のコンテキスト管理手段は、任意のクライアントのユーザから、ユーザを指定せずに、ある条件のコンテキストが要求された場合に、すべてのコンテキスト情報に対して、指定された条件にマッチし、要求元ユーザのアクセス権が許可されている場合に、そのコンテキスト情報を返信することを特徴とした請求項４又は５に記載のコンテキスト共有方法。
7. ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおける上記クライアントにおいて、
   ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、
   上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、
   ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報と
   を保持するコンテキスト保持手段と、
   対象となるクラスあるいはキーワードを記述したノード条件、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、１以上のレコードを有する、プライバシーポリシー情報を管理するプライバシーポリシー管理手段と、
   コンテキストを収集して上記コンテキスト情報及び上記ノード情報を作成すると共に、作成したコンテキスト情報及びノード情報に対して、上記プライバシーポリシー情報とのマッチングを行い、プライバシーポリシー情報のノード条件と、コンテキスト情報あるいはノード情報がマッチする場合は、プライバシーポリシー情報の対象ユーザ及びアクセスを、上記アクセス情報にコピーした後、上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記サーバに送信し、かつ、ユーザの入力に応じて、コンテキストの要求をサーバに送信するコンテキスト管理手段とを備える
   ことを特徴としたクライアント。
8. ユーザ個人に係るコンテキストの情報を取得して間欠的にサーバに送信する１以上のクライアントと、任意のクライアントから要求された任意のユーザのコンテキストの情報を所定条件下で返信するサーバとを有するコンテキスト共有システムにおける上記サーバにおいて、
   上記クラアントから送信されてきた、
   ノードＩＤ、１組以上のプロパティ及び値の組情報、及び、処理フラグを含む、０又は１以上のレコードを有する、コンテキスト情報と、
   上記コンテキスト情報のノードＩＤあるいはプロパティの値に対応するＩＤ、クラス及び値を含む、０又は１以上のレコードを有する、ノード情報と、
   ＩＤ、読み出しを許可する、あるいは、許可しないユーザあるいはグループを記述した対象ユーザ、読み出しの許可、不許可を記述したアクセス権を含む、０又は１以上のレコードを有する、アクセス情報と
   を保持するコンテキスト保持手段と、
   送信されてきた上記コンテキスト情報、上記ノード情報及び上記アクセス情報を上記コンテキスト保持手段に保持させると共に、任意のクライアントのユーザから、任意のユーザのコンテキストが要求された場合に、要求元のユーザが、要求先のユーザの要求されたコンテキストに係るアクセス権で読み出しが許可されている場合に、そのコンテキスト情報を返信するコンテキスト管理手段とを備える
   ことを特徴としたサーバ。

Images