JP2008525880A - 個人データの制御装置及び方法 - Google Patents

Abstract

個人データに対するポリシーの設定において、主エンドユーザから発せられ、個人データの選択された部分に対するプライバシポリシーを規定する命令が、アプリケーション部（２２０）を介してサービスブローカ（２５０）のプライバシ設定ノード（２５８）へ通信される。この命令は、そのデータについて可能性のあるデータプロバイダ（２４０）を規定している。ポリシーは、データベース（２５４）において、その主エンドユーザに対する個人プライバシツリーであって、個人データが関連するプライバシポリシーとともに階層的に配置された個人プライバシツリーに保存される。個人データに対する要求を受信すると、プライバシ設定ノードは、そのデータに対して規定されたプライバシポリシーが存在するか否かを、主ユーザのプライバシツリーをチェックすることによって判定する。要求されたデータに対するポリシーがある場合、プライバシ設定ノードは可能性のあるデータプロバイダの中から１つを選択し、アプリケーション部へ応答を返して、要求された個人データをこのプロバイダにおいてアクセスできるようにする。

Description

本発明は概して通信システムにおけるセキュリティに関し、特には、インターネットやそれに似たネットワーク上の、エンドユーザの制御に従った個人データの取り扱いに関する。

モバイルインターネット用のサービス開発が近年爆発的に増大しており、ゲーム、カレンダー、チャットグループ、ニュース、電子商取引といったように、多数のサービス及びアプリケーションが提供されるに至っている。特に、パーソナライズドサービス、即ち、個人データに依存するサービス（例えば、要求者に対し、現在いる場所の天気の提供、通勤の行き帰りの時刻表の提供、電子商取引した商品の自宅への配達、クレジットカードへの課金等）に対する高い需要が存在する。

パーソナライズドサービスの提供を可能にするためには、何らかの形で、個人に関する情報（地位(position)、人口統計情報(demographics)、生体情報(biometrics)等）の提供を受けなければならず、これがプライバシ対策を重大なものにしている。プライバシポリシーはパーソナライズドサービスを行う上でますます重要になっており、それがあることにより、モバイルインターネットをフル活用することができる。

従来の通信システムは通常、ユーザが興味のある新しいサービス毎に、ポリシーの確認(review)及び承諾を要求するものであった。個々のポリシーは異なっており、個人データの必要性や公開に関して起こりうる様々な事象に関連している。しかし、特にコンシューマセグメントについては、モバイルインターネットのみならずインターネットで提供されるサービスやアプリケーションは、非常に速いペースで生まれては消えてゆくであろう。このようは、アプリケーションの頻繁な入れ替わりは、パーソナルプライバシの問題に影響を与える。なぜなら、ユーザに、興味を持つ新しいサービスごとに企業のポリシーを確認し、承諾することを課すのは非現実的だからである。一般的なポリシーでも、ユーザが１つのポリシーの全てを読んで理解するには少なくとも１０分かかり、エンドユーザにとって障害になっていることは明白である。

従って、パーソナライズドサービスを受けるために、必要以上に複雑化せずに個人情報を保護する、ユーザフレンドリな方法のシステムに対する高い要求が存在する。このような機能を可能にするネットワークは、本出願人による国際特許出願［１］において概説されており、個人データをその利用と切り離して公開させることを提案している（以下、「クラシックロックボックス」と呼ぶ）。そこでは、特定の一部のデータを利用する新しいサービスができる度に再設定する必要なく、人口統計情報や物理的な位置といった個人情報を保護（又は公開）可能なように設計された一般的なアーキテクチャが提供されている。個人情報を公開又は保護する条件は、エンドユーザの制御下にある。上述の汎用ネットワークのウェブサービスへの適用は、本出願人による国際特許出願［２］に開示されている。

クラシックロックボックスは、例えばインターネット上で個人データを取り扱うための汎用的な機構及びネットワークを提供するが、依然として解決すべき事項は存在する。膨大な個人情報が関与し、多数の関係者がそのデータを用いて様々なことを行いたいと思うであろう。それは、システムを複雑化し、それらのデータに対するアクセス権をどうやって適切に保存及び構築するかという問題を生じさせる。また、ユーザフレンドリな方法で、個人データを設定及び分配できるような解決策もまた必要とされている。

［１］国際特許出願公開第WO03/32222A1号 ［２］国際特許出願公開第WO2004/072855A1号

本発明の目的は、インターネットのようなオープンネットワークにおいて、特にサービスブローカシステムに関して、改善された個人情報の取り扱いを提供することにある。また、別の目的は、エンドユーザのセキュリティに妥協することなく、効率的な方法で個人データを保存するための機構を提供することにある。さらに別の目的は、個人データに関する要求の取り扱いをユーザフレンドリに行うことである。

これら目的は、添付した特許請求の範囲に従って達成される。
本発明は、個人データのユーザフレンドリかつ効率的な取り扱いを提供する有利な機能を提供を備えているクラシックロックボックスによって概要が説明されるような通信システムに関する。本発明が提案する、エンドユーザの制御に従った個人データ取り扱い手順は、個々のプライベートポリシーと共に個人データ要素を含むプライバシツリーにおける特定のデータ構成に基づく。汎用プライバシツリーと複数の個人プライバシツリーがあり、プライバシツリーは、個人データとプライバシポリシーが、例えば特定のルックアップテーブル及びポインタを用いたインタラクションを通じて都合良くアクセスできるように、階層的に構成される。本発明の特定の実施形態によれば、システムパフォーマンス及びエンドユーザ体験をさらに向上させるため、主及び副エンドユーザ並びにデーモンノードの新しい概念が導入される。デーモンノードは、プライバシツリーの（場合により）異なる階層及び／又は異なるサブツリーから複数のデータを要求する、要求集合体(aggregated requests)を可能にする。好ましい実施形態において、汎用及び個人プライバシツリー、主及び副エンドユーザ並びにデーモンノードの機能が相まって、膨大な個人プライバシデータの便利な取り扱いを可能にする手順を形成する。

本発明の別の側面によれば、エンドユーザの制御に従った個人データ取り扱いのための手段を有する通信ノード及び通信システムが提供される。

本発明、並びに本発明の他の目的及び利点は、以下の説明を添付図面と共に参照することによって最もよく理解できるであろう。

本発明は、”クラシックロックボックス”［１］と同様の方法により、個人データの公開をその利用と切り離したアーキテクチャを示すシステムに関する。そのため、まずクラシックロックボックスの簡単な説明を行い、その後で本発明の特徴について詳細に説明する。

クラシックロックボックスの実装を、図１に示す。図１は、本発明を利用可能な、個人データのエンドユーザ制御のための従来の通信システムの模式的な概要を示す図である。図示されるシステム１００は、アクセス手段１２４を有する要求アプリケーション１２２、アクセス手段１４２を有する情報提供アプリケーション１４６、中央サーバ１５２及び付随データベース（ＤＢ）１５４を備える中央サーバ手段１５０、及び、情報保持データベース１４８を含んでいる。アクセス手段１２４，１４２の各々は、それぞれのデータベース１２６，１４４を有している。アクセス手段は中央サーバ手段と通信するように構成され、情報ルーティング及び、データベース１５４に保存される個人保護プロファイルを用いた個人プロファイル保護／保護解除を受け持つ。

エンドユーザ１１０からコンタクトされると、データ読み出し又は個人プロファイルへの新しいデータの設定のために、要求アプリケーション１２２は通常、ネットワークのどこかにある個人プロファイルデータの要求をアクセス手段１２４へ送信する。アクセス手段１２４は、要求を転送すべき中央サーバ手段１５０のアドレスを見つけ出すため、自身のデータベース１２６を呼び出す。要求はセキュアＨＴＴＰ（ＨＴＴＰＳ）を通じて中央サーバ１５２へ転送され、中央サーバ１５２はデータベース１５４の中の個人保護プロファイルから、適切なポリシーを読み出す。拒否又は許可の標示がアクセス手段１２４に戻され、許可の場合、アクセス手段１２４はインターネット１３０を通じたアクセス手段１４２との通信にＨＴＴＰＳを用いる。アクセス手段１４２は提供アプリケーション１４６にコンタクトし、提供アプリケーション１４６は情報保持データベース１４８からデータを読み出す。情報はアクセス手段１４２、インターネット１３０及びアクセス手段１２４と通じて提供アプリケーションへ返送される。

クラシックロックボックスシステム１００の基本機能は、個人情報へのアクセス権が中央部（中央サーバ手段１５０）におけるエンドユーザ１１０によって管理され、一方で、個人データ、即ちそのような情報は、別の情報源１４８上の通信システムを通じて配信されることである。このようにしてエンドユーザは、異なるプロバイダから異なる情報要求者への個人情報へのアクセスに対するロック／アンロックを行うことができる中央機関を提供される。

さらに、クラシックロックボックスを用いて、要求側の身元を提供側には隠すことができる（あるいはその逆方向についても）。個人情報と様々な場所との間のコネクションは、必ずユーザが制御する中央サーバ手段１５０を通る。個人プロファイルデータをユーザＩＤとともに様々な場所（又は関係のない同一の場所）に拡散させることで、高度のエンドユーザプライバシが得られる。

ウエブサービスに関するクラシックロックボックスのさらなる発展及び利用について、［２］に示されている。［２］には、本発明を利用可能な、個人データのエンドユーザによる管理のための従来の別の通信システムが記載されている。

ロックボックスの概念に関する更なる詳細については、［１］及び［２］を参照されたい。

本発明はクラシックロックボックスによってその概要が説明されるような通信システムに関するものであるが、その概念をさらに進歩させたものである。背景技術において述べたように、一般に、膨大な個人情報が関与し、多数の関係者がそのデータを用いて様々なことを行いたいと欲する場合、それらはシステムを複雑化させる。そのため、クラシックロックボックスには、個人データのユーザフレンドリかつ効率的な取り扱いを提供するための有利な機能が備えられてきた。

基本的に、プライバシポリシーデータの保存及び取り扱いが面倒であるという問題は、例えば特定のルックアップテーブルとポインタを用いたインタラクションを通じて、都合良くアクセスすることを可能にする、プライバシツリーにおけるプロパティを有するデータ構成に基づく機構により、本発明に従って解決される。汎用プライバシツリー及び複数の個人プライバシツリーが存在し、さらに、システムが、システムパフォーマンス及びエンドユーザ体験をさらに向上させるための主及び副エンドユーザ並びにデーモンノードの新しい概念にも依存することが好ましい。好ましい実施形態において、これらの機能は共に動作し、以下に説明するような方法で互いを補完する。汎用並びに個人プライバシツリー、主及び副ユーザ並びにデーモンノードの機能についての例示及び詳細な説明を行う前に、本発明に係る典型的な通信システムの主要な機能要素について、図２を参照して説明する。

図２は、本発明の例示的な実施形態に係る、個人データのエンドユーザ制御のための通信システムの模式的な図である。アプリケーション部２２０、データ提供部２４０及びサービスブローカ２５０を有する通信システム２００が図示されている。アプリケーション部２２０と通信している複数のエンドユーザは、図中、セルラ電話機２１０−１、パーソナルコンピュータ（ＰＣ）２１０−２及びラップトップコンピュータ２１０−３によって表されている。セルラ電話機２１０−１は通常、アプリケーション部とのコンタクトに、無線アプリケーションプロトコル（ＷＡＰ）ゲートウェイのような中間装置を用いる。アプリケーション部２２０は、アプリケーションノード２２２及びアクセス手段２２４とを有する。アクセス手段２２４は、データベース（ＤＢ）のような情報保持手段２４８に格納される個人データ（例えば生体情報や位置データ）を取得（又は設定）するために、データ提供部２４０のアクセス手段２４２と通信可能である。

アプリケーション部２２０及びデータ提供部２４０はいずれも、サービスブローカ２５０との通信手段を有する。サービスブローカ２５０は、少なくとも１つの付随データベース２５４を備えるプライバシ設定ノード（ＰＳＮ）２５８を有している。データベース２５４は、プライバシツリー内に階層的に構成されたプライバシポリシーを格納している。ＰＳＮ２５８は、プライバシツリー内のポリシーに関する、ユーザからの指示の実行において、重要な役割を演じる。ＰＳＮ２５８は、データベース２５４内のプライバシツリーにおけるプライバシポリシーを設定するための手段及び、要求者２２０にプライバシポリシーを手渡す手段を備える、サービスブローカ２５０内の管理機能と見なすことができる。データ設定及び要求処理のいずれも、それらの動作が許可されるか否かに関するＰＳＮ２５８によるチェックを伴い、それにより、サービスブローカ２５０が発行し、そのサービスブローカに限定される特定のＩＤが利用できる。ＰＳＮの機能の詳細は、以下の”データ設定の例示手順”及び”要求処理の例示手順”の欄において行う。

図２に示す例示的な実施形態において、サービスブローカ２５０はさらに、以下の”共通サインオンの実装”において説明する（オプション）機能を提供する、共通サインオン（ＣＳＯ）サーバ２５６を含んでいる。

本発明に係る通信システムは、通常、多数のアプリケーション部及び多数のデータ提供部を備えていることに留意されたい。そして、個人データは様々なデータプロバイダのデータベースで、システム中に分布されている。

プライバシツリー
本発明は、プライバシポリシー及び関連データを、プライバシツリーを用いてプライバシ設定ノード内に（あるいはプライバシ設定ノードと関連付けて）保存することを提案する。プライバシツリーは、データ要素を表す複数のノードを含み、このノードに対して、個人の設定(personal preferences)がプライバシポリシー内に設定されうる。個人データ要素を有するノードは、把握及び管理が可能なユーザフレンドリなツリー構成が実現できるよう、階層的に配置される。

好ましくは、システムレベルで定義される汎用プライバシツリーが存在し、それを用いてユーザ特有の個人プライバシツリーが生成される。図３は、本発明の例示的な実施形態に従ってプライバシポリシーを構成するために用いられる汎用プライバシツリー３５１を示す図である。汎用ツリー３５１は、様々なプロバイダが、コネクションを生成することなしに個々のエンドユーザへ何を提供するのかを示している。このツリーはシステム全体に対するものであり、要求側のアプリケーションが入手可能な情報を表している。各ノード３５３は、サービスブローカのオペレータが契約を結んでいる（ただし、個人レベルでの適用は不要である）パートナーの情報３５５（例えば、靴データ要素に対しては、””靴店Ｚ”，”ビッグシューズ”，”チープシューズ”という名前の会社）を、含むか、指すかしている。ノード３５３はまた、例えば、関連するポリシーファイル／テンプレート及び価格情報（例えば、１つ又は複数のプロバイダへの要求のコスト／収益）を含んでも良い。

汎用プライバシツリーとは異なり、個人プライバシツリーは個々のエンドユーザが定義する規則に従って”切りつめ”(pruned)られている。図４は、本発明の例示的な実施形態に従ってプライバシポリシーを保存及びアクセスするために用いられる個人プライバシツリー４５１を示す図である。この特定の個人について許可されたプロバイダを含む、特定の設定に関する情報４５５は、個々のノード４５３に保存される。この例において、（図３の汎用プライバシツリーと比較して）”存在しない”(missing)ノードは、対応するサービスをこの個人が許可していないことを意味する。図４のエンドユーザは、靴要素に対するプロバイダとして”靴店Ｚ”を選択している、即ち、このエンドユーザは、少なくとも彼に関する個人データの読み出しを許可された人物の少なくともサブセットに対して、会社”靴店Ｚ”が靴に関する個人データを提供することを許可している。

個々のエンドユーザの個人プライバシツリー４５１は、汎用プライバシツリー３５１からコピーを作成することにより、有利に生成することができる。このステップが実行される場合、ノード４５３の各々は、ノードに対してプライバシポリシーが適切に設定されるまで、”データ公開禁止”に設定されることが好ましい。

（汎用及び個人）プライバシツリーの階層化は、いくつかの利点を暗示する。それは、データをユーザフレンドリな方法でデータを整理し、多数のデータ形式にまたがった簡単な概観を可能にする。膨大な量のデータを、都合の良い方法で取り扱うことが可能である。複数のプライバシポリシーをサービスブローカシステム内に分布させることも可能であり、そのために、プライバシツリーのノードが、実際のプライバシデータの代わりに、個々のプライバシポリシーへのポインタを含む。さらに、階層的な配置は、例えば、下位レベルのノードが同一プロバイダからのデータを含む場合において、１レベルに対する許可がその下位レベルについても影響を与えるような解決策も可能にする。

主及び副ユーザ
本発明の個人データ取り扱いは、本発明の特定の実施形態に従ってエンドユーザの様々なタイプを区別することによって、さらに拡張することができる。このような解決策は、サービスブローカ内にプライバシポリシーを有するユーザに対しては第１のユーザタイプ（本明細書では主ユーザと呼ぶ）、１人又は何人かの主ユーザについての個人情報を単に要求するであろうユーザに対しては第２のユーザタイプ（本明細書では副ユーザと呼ぶ）を割り当てる。主ユーザは、主又は副エンドユーザからの個人情報要求に関連するユーザである。従って、主ユーザは要求（”被問い合わせ”(asked about)）に関与することができ、その一方で副ユーザは、彼が要求することを許可している１人又は何人かの主ユーザに関する情報の問い合わせ(ask about)ができるが、定義されたプライバシポリシーを持たないので、被要求はされ得ない。典型的な副エンドユーザは、主エンドユーザの家族、友人又は同僚であってよい。

副エンドユーザに関し、ＰＳＮは、主エンドユーザから（アプリケーション部を介して）ＰＳＮに通信される命令に従って、少なくとも１人の副エンドユーザを主エンドユーザに割り当てることが好ましい。これは通常、プライバシポリシー設定手順に関して実行される。特定の主ユーザについての副ユーザとして割り当てられたユーザが、その主ユーザに関する全ての個人データへのアクセスを自動的に許可されるような場合もあるだろう。しかし一般には、その主ユーザは、特定の副ユーザにどのデータ要素へのアクセスを許可するかを指定する必要があるだろう。図４においては、例えば、ＩＤ10000528を有する副ユーザに対して、靴データ要素へのアクセスのみが許可されている。

サービスブローカは、好ましくは、含まれる主及び副ユーザに対して固有の識別子を発行し、これらのユーザタイプを識別する。以下に示すように、個人データ要求の、提案するサービスブローカシステム及びプライバシツリー構造を用いた取り扱い手順は、主及び副ユーザＩＤによって、非常に効率化される。例えば、個々のユーザ関係の定義とともにルックアップテーブルを用い、初期段階において、要求が許可ユーザからの来たものかチェックすることが可能である。

従って、ある主ユーザに関する個人情報に対する要求は、その主ユーザ自身から又は、副ユーザとして定義された他のユーザから発せられうる。なお、ある主ユーザが他の１人以上の主ユーザに関する問い合わせを行う場合も珍しくなく、この場合、問い合わせする主ユーザは、他の主ユーザに対する”副ユーザ”として振る舞う。換言すれば、主ユーザはいずれも副ユーザになりうる。

デーモンノード
個人データを取り扱うための、提案する機構のユーザフレンドリーさや性能は、本発明の特定の実施形態により、１つ又は複数の所謂”デーモンノード”をプライバシツリーに導入することにより、さらに拡張することができる。デーモンノードは、個人データ要素に関する少なくとも２つの他のノードを指すノードであり、それによって集合要求(aggregated requests)が可能になる。デーモンノードは固有サービス識別子と関連付けられる。つまり、関係する要求アプリケーションからすると、他のサービス／ノードと同じように見える。

図５は、本発明の例示的な実施形態に係る、デーモンノード５５７を有する個人プライバシツリー５５１を示す図である。図５のツリー５５１は、汎用プライバシツリーのサブセットであっても、個人プライバシツリーであってもよい。図示されるデーモンノード５５７は、米国の靴サイズについてのノードと、シャツノードを指している。このノードは、他のノードとして取り扱われ、ある人（主ユーザ）のシャツサイズ及び米国の靴サイズの両方を問い合わせるための集合要求を可能にする。シャツ及び靴のサイズデータは、同一のデータプロバイダから提供されなくても良い。デーモンノードを用いることで、要求側のアクセス手段は、実際には個々のデータ要素に対する複数の要求が存在するにもかかわらず、要求者が１つの要求を行うだけですむようにすることができる。図５に示すように、デーモンノード５５７の１つの有利な機能は、プライバシツリー５５１内の異なるレベルに配置された複数のデータノード５５３を指すことができる点である。デーモンノードはまた、プライバシツリーの異なるサブツリーに属する同一又は異なるレベルのノードを指すことももちろん可能である。

このように、デーモンノードを用いた解決策は、エンドユーザからの１つの要求を通じた複数の個人データエンティティの読み取りを可能にする。そして、アプリケーション部からサービスブローカへ通信される要求は、個々の個人データ要素を有するプライバシツリー内の複数のノードを指すデーモンノードのサービス識別子と、集合要求とを備える。しかし、主エンドユーザが、デーモンノードを用いた複数のデータ要素の同時設定を許可されるような実施形態もあり得る。つまり、デーモンノードはデータのまとめ書き(aggregated writing)にも用いることができ、それによって複数のプライバシポリシーが複数の個人データ要素に対して同時に定義される。

複数の情報に対する集合要求を許可することにより、デーモンノードを用いた解決策はプライバシツリーの複数の個人データ要素（ノード）にアクセスする手順を高速化する。これにより、通常は同一サービスに用いられる複数のデータ要素や、同一プロバイダを有する複数のデータ要素といった、適切な複数データ要素からなるグループを複数形成することが可能になり、それらは、複数のデーモンノードによってまとめて取り扱うことが可能である。デーモンノードの他の利点は、新しいサービスを非常に素速く立ち上げることが可能なことである。これは、デーモンノードが、新しいサービスが既存のサービスを利用可能にするからである 例えば、あるアプリケーションに位置を提供するサービスを、位置及び出身地(home city)を含むように簡単に拡張することができる。

上述の通り、デーモンノードの各々は、個別のサービスＩＤに関連付けられており、要求アプリケーションには”通常の”サービスのように見える。しかし、デーモンノード内の個人データに対する要求結果は、複数のプライバシポリシーファイル（又は検証結果。以下を参照のこと）を含んだ応答メッセージとなるであろう。そのため、アプリケーション部のアクセス手段は、要求を、提供側への（”実際の”データ要素ノードごとの）複数の要求に分離する必要がある。さらに、例えば要求検証が要求側で実行される場合、アプリケーション部はデーモンノードが指すノードの全てに対して１つの検証を実行する。アプリケーション部のアクセス手段は、様々な提供部からの応答をアプリケーションノードへ返送するための１つの応答に集約しなければならない上、様々な検証イベントの結果を判定しなければならない。

デーモンノードに関する特定の問題は、複数の要求のあるサブセットが成功裏に検証され、他のサブセットの検証が失敗した場合に、どのように処理するかである。許可された個人データが、要求された複数のデータ要素のサブセットを構成するだけだとしても、アプリケーションノードへ返送するべきであろうか？本発明の特定の実施形態において、この問題は、アプリケーションノードに、必要に応じて、即ち、そのサービスがデータセットの全体を必要とするのか、サブセットでも意味があるのかに応じて、アプリケーション側のアクセス手段へ通知させるようにすることで解決される。この情報は、大元の要求に含められてもよいし、アクセス手段からのその後の招待(invitation)時に与えられても良い。例えば、靴の宅配を提供するサービスに対して、靴のサイズと自宅住所のうち靴のサイズだけが得られても全く役に立たないだろうが、（価値はおそらく下がるであろうが）一部のデータ項目によって実施可能なサービスを提供する他のアプリケーションも存在するであろう。

データ設定手順の例
プライバシ設定ノードが、エンドユーザが自身のプライバシポリシーを定義するための都合の良い方法をどのようにしてサポートするのかを例証するために、例示的な手順を以下に説明する。サービスブローカにおけるプライバシポリシーの設定は、完全にユーザの自発性に任せて行われても良いし、ポリシーが設定されていない個人データを要求するサービスをユーザが要求したことによって行われても良い。後者の場合、システムからユーザへ、ポリシーを定義したいかどうかを問い合わせる質問が送信される。

理論的には、定義すべきデータの量が膨大になりうるため、ＰＳＮは以下のエンドユーザインタラクションを通じてこの定義を遂行することが好ましい。

Ａ）（主）エンドユーザがポリシーを定義しようとするデータ要素（例えば、自宅住所、位置又は靴のサイズ）を選択する。このステップは、例えば、生体情報→靴のサイズ→米国の靴サイズ、のように、例えば図３に示す様なプライバシツリー構造における階層を下るステップを含んでよい。論理的に整理され、かつ簡単な概観を提供するため、階層はエンドユーザが探している特定のデータ要素を素速く探すことを容易にする。１つ又はいくつかのデーモンノード及び／又は、あるレベルへの許可がその下位レベルにも作用することを暗示する機能（コンテンツ又はプロバイダの観点から意味がある場合）を通じて、データ設定をさらに楽にすることができる。

Ｂ）次に、エンドユーザが、選択したデータ要素に対して許可する／可能性のあるプロバイダを定義する。そして、この情報がアプリケーション部を介してＰＳＮへ提供される。ＰＳＮは、そのエンドユーザが１つ又はいくつかのプロバイダを選択可能なサービスブローカと契約を結んでいるデータプロバイダのリストを提供することも可能である。このようにして、特定のデータ要素を、可能性のある１つ又は複数のデータプロバイダと関連付けすることができる。ユーザは、例えば地理的な位置についてはオペレータからだけ提供されるようにし、自宅住所はいくつかのプロバイダのどれかから提供されるように許可することができる。

Ｃ）サービスブローカとエンドユーザとのさらなるインタラクションと通じ、エンドユーザは選択したプロバイダの各々について必要な信用証明物、例えばディジタルＩＤ及びパスワードを入力する。サービスブローカはこれらの信用証明物を、選択されたプロバイダに対し、サービスブローカが代理を主張する人物を正当に代理していることを証明するために必要とし、それによりプロバイダは、自身がその人物に関する個人データを公開する権限を与えられていることを認証することができる。

Ｄ）好ましい実施形態において、上述の手順が完了したら、おそらくはパスワードと関連付けされて、副ユーザが定義される。上述したように、副ユーザは主ユーザに関する個人データの読み出しを許される。これは、例えば家族がお互いに関する所定の要求を行うことを可能にするであろう。副ユーザは、異なるデータ要素に対して個別に（従って、おそらくは異なって）定義されても良いし、あるいは、「オン／オフ」オプションを通じて、即ち、特定の主ユーザに対して副ユーザとして割り当てられた全ての人が、その人物についての全ての個人データへのアクセスを許可されてもよい。

Ｅ）ＰＳＮは、主ユーザによって設定された１つ又は複数のポリシーを、その特定のユーザの個人プライバシツリーにおける適切な位置に保存する。これがそのユーザが最初に行ったデータ設定であった場合、まず、個人プライバシツリーが、好ましくはそのサービスブローカの汎用プライバシツリーのコピー（又はそれに関連した何か）を作ることによって生成される。プライバシポリシーはそれらの各々のデータ要素とともに保存されても良いし、別個に保存され、各々のデータ要素と例えばポインタを通じてリンクされても良い。

要求取り扱いの手順例
図２及び複数の例示的なルックアップテーブルを参照して、入来する個人データ要求に応じたプライバシ設定ノードの機能を例証するための例示的な手順を説明する。シーケンスの主要な流れは、図２において矢印Ｉ〜ＶＩＩで示されている。

ある特定のサービスを欲する（ユーザ装置２１０を用いる）エンドユーザが、アプリケーション部２２０のアプリケーションノード２２２にアクセスする（Ｉ）。好ましくは共通サインオン（ＣＳＯ）サーバ２５６へのリダイレクトが存在し、それにより、ユーザはサービスブローカ２５０にログインする（ＩＩ） ＣＳＯ機構及びサービスブローカ２５０／ＰＳＮ２５８との間の相互動作は、以下の”共通サインオンの実装”欄においてさらに説明する。

エンドユーザから発せられた要求は、アプリケーション部２２０内のアプリケーションノード２２２から、アプリケーション部２２０のアクセス手段２２４を介し、ＰＳＮ２５８を有するサービスブローカ２５０へ通信される（ＩＩＩ，ＩＶ）。この要求は、要求される個人データが関連する主ユーザの識別子、例えばＭＳ−ＩＳＤＮ，クレジットカード番号又は類似の識別手段を含むほか、要求されるサービスの識別子、例えば正規ノード又はデーモンノードに対するサービスシーケンス番号を含む。ＰＳＮ２５８は、システムの仕様に従い、例えばＰＫＩ及び／又はＩＰアドレスデータを用いて、要求を検証し、その要求が正当なクライアント（アクセス手段）から来たものであることを裏付ける。この手順のために、例えば表１のようなルックアップテーブルを用いることができる。表１はサービスブローカに接続されるパートナー及び、それらパートナーと通信するために用いられる”帯域外(out-of-band)”データをリストする。（最初の列は、サービスブローカにおける個々のパートナーのＩＤを含んでいる。）そのような帯域外データの例としては、ＰＫＩデータ、ＩＰアドレス、プライバシポリシーを行使する場所の指定（例えば、”デフォルト”としてシステム全体(system-wide)に基づく指定や、アプリケーション側及び／又は提供側に特有な指定がなされる）、（提供側のパートナーに対する）応答時間、セッションをオープンにしておく期間、等がある。帯域外データの量は、所望のシステム機能性によって決定される。表１に示すように、本発明に係る、パートナーに関連する帯域外データテーブルは、要求側（図２におけるアプリケーション部）又は提供側のパートナーとで同じであることが好ましい。

好ましい実施形態において、パートナーに関する要求検証は、ＩＰアドレスのチェックから開始する。表１のアドレスに対応しないＩＰアドレスから要求が来ている場合、その要求は直ちに拒否されうる。正しいＩＰアドレスについては、ディジタル署名（公開鍵）及び／又はプロバイダの身元の２次チェックを行うための、次のステップをオプションで有しても良い。まずＩＰアドレスを独立してチェックすることは、高いシステムパフォーマンスに寄与する。

少なくとも理論的には、全ての当事者が信用できる状況があり得、そのような場合にはこの種の初期検証は不要である。

要求がＣＳＯにリダイレクトされた場合、アプリケーションノードから受信されるセッションＩＤを、ＣＳＯログイン手順において開始される正しいセッションとの接続に使用することができる。ＣＳＯを経由しない要求に対しては、そのようなセッションが存在しない代わり、内部サービスブローカＩＤを供給する必要がある。そのような場合、ＰＳＮ（又はサービスブローカの他の機能部）が、表２を用い、入来主ユーザＩＤ（例えば、ＭＳ−ＩＳＤＮ又はクレジットカード番号）を、内部の、サービスブローカシステム用の固有ユーザＩＤへマッピングする。

表２の情報は、ディジタルＩＤをあるドメインから別のドメインへマッピングするために用いられる。ドメインは例えばＭＳ＿ＩＳＤＮドメインのようなオペレータドメインであっても良いし、顧客のＩＤ（航空会社、店舗、保険会社、銀行、等）を有する企業ドメインであってもよい。表に示すように、ディジタルＩＤは、パートナーが要求側（アプリケーション部）又は提供側のどちらに属するかには依存しないことが好ましい。パートナーが、主ユーザ自身が個人データを要求しているか、他人（副ユーザ）が要求しているのかに応じ、ユーザ／顧客に対して異なるディジタルＩＤを希望する場合、例えば、そのパートナーを２つの異なるパートナーＩＤキーを用いて２度登録することによって対応することができる。

簡単さのため、表２は１人の主エンドユーザのディジタルＩＤのみを示している。このエンドユーザは、パートナーの各々との関係においては、自身の電話番号又は他の顧客ＩＤを通じて識別されるが、サービスブローカユーザＩＤは１つしか持たない。

サービスブローカは要求者用のＩＤを持つ必要があり、要求者が主ユーザの場合には、以前のステップにおいて既に与えられている。しかし、要求者が副エンドユーザの場合には、要求者のＩＤ（副ＩＤ、例えばＭＳ−ＩＳＤＮ）もまた内部サービスブローカＩＤに（本例においては表３を用いて）マッピングされる。

表３はサービスブローカが正しく機能するために必要な基本的な個人データ及び、特定のユーザに関するデータの要求を許可されているかのデータの経過を追ったものである。本例において、”サービスブローカｐｗ”欄のパスワードには、２つの機能がある。主ユーザが自身のプライバシ設定にアクセスする及び／又は個人データを読み出すために用いることができる。また、主ユーザに関する個人データを読み出すために、可能性のある副ユーザによってもオプションで用いられ得る。

ユーザタイプ欄は、サービスブローカにプライバシポリシーを有し、要求（問い合わせ及び被問い合わせ）に関与するであろう主ユーザ（Ｐ）と、主ユーザに関する問い合わせを行うかもしれないが、プライバシポリシーが定義されておらず、自身に関するデータ要求が許されていない副ユーザ（Ｓ）とを区別するためのものである。

好ましい実施形態において、ＰＳＮは要求について、この段階で既にマイナーチェックを実行する。要求が副ユーザとしてのみ規定されているユーザに関するものかどうかは、表３から知ることができる。そのような要求は直ちに打ち切ることができ、ＤＴＤ（文書型定義）、即ちプライバシポリシーをコンパイルする必要が無く、要求はアプリケーションノードへ戻ることができる（以下の段落と比較されたい）。このチェックイベントを、以下に図６に関連して説明するような方法で、さらに拡張することができる。

適切なユーザＩＤを供給した後、ＰＳＮは主ユーザの個人プライバシツリーの場所及び、要求されたデータに関連するノードの（汎用）プライバシツリー内の位置を、適切なルックアップテーブルから読み出す。本例において、表４は、個人プライバシツリーを見つけるために用いられる。事前に表２から取得されたサービスブローカユーザＩＤに対し、表４は個人プライバシツリーの位置を指す。

プライバシツリー内のパスは、要求と共に入来するサービスＩＤが入力される表５を用いて見つけることができる。要求者からのあるサービスＩＤに対し、この表は、関連するプライバシポリシーが汎用プライバシツリー及び個人プライバシツリーのどこで見つかるかを記述する。名前空間スキーマを用いてツリーをどうやって降りたら良いかを知らせるという観点からすると、ポインタは”相対的”であることが好ましい。ポインタは、本例におけるサービス００５−００８のように、実際の（”単独の”）ノードを指してもよいし、サービス００９のようにデーモンノードを指しても良い。

表４及び表５からのポインタは、個人プライバシツリーの収集及びプライバシツリー内の正しいデータ要素／ノードを特定するには十分である。以上のような動作を行った後、ＰＳＮは、要求エンドユーザ及び要求されたデータ要素に関し、要求を以下のようにチェックすることが好ましい。

表６は、サービスブローカＩＤが互いにどのように関連しているかを追ったものである。主ユーザ以外の人からの要求に対して、ＰＳＮは、表６を用いて、その要求がエンドユーザ間の関係に関して許可されるかどうかを調べることができる。具体的には、表６は、個々の主ユーザＩＤと、その主ユーザによって、その主ユーザに関する個人データの問い合わせが許されている副ユーザの１つ以上のＩＤとの関係を規定している。パスワードが必要な場合には、表３から読み出される。ユーザによる直感的なグループ分けを容易にするため、例示的な表６は、グループに対するある種のニックネーム、例えば”家族”又は”同僚”の使用を許している。これにより、プライバシポリシーを、副ＩＤのグループ全体にまとめて設定することが可能になる。

表６を用いて、ＰＳＮは要求エンドユーザが、その要求に関連する主ユーザに対して有効な副ユーザであるのかチェックすることができる。もしそうであれば、手順を継続する。一方、要求エンドユーザが有効な副ユーザでなければ、手順は打ち切られる。ある実施形態においては、このチェックは、個人プライバシツリーの読み出しより前に、例えば、上述した、表３を用いたマイナーチェックに関して実行されうる。

しかし、通常は、特定の要求されたデータ要素に関して、要求ユーザをより具体的にチェックする必要があるだろう。個人プライバシツリーはＰＳＮ２５８及び、プライバシツリーを保持するデータベース２５４との相互動作を通じて読み出される（図２、Ｖ）。そして、ＰＳＮは、表５の参照による出力を用いて、個人プライバシツリー内の正しいノードを見出す。その後、要求ユーザが、この特定のデータ要素に関して問い合わせることを許可されていることが裏付けられる。そして、ＰＳＮは、この特定のデータ要素に対して、プライバシポリシーが規定されているかどうかをチェックする。もし規定されていなければ、手順を停止し、アクセス手段及びアプリケーションへ通知する。

一方、要求されたデータのタイプが許可されるであろう場合、即ち、プライバシポリシーを有する場合、入来した要求を引き受ける適切なプロバイダ２４０が、ＰＳＮ２５８によって決定される。このプロバイダは、そのサービスブローカシステムと契約を結んでいるプロバイダの汎用プライバシツリー内のリストから選択されることが好ましい。（汎用プライバシツリー内のプロバイダのリストアップをサポートする契約を確立するための、データ提供部及びサービスブローカ間の相互動作は、図２には示していない。）要求されたデータ要素に対して複数の可能性のあるプロバイダが規定されている場合、ＰＳＮは、例えば、エンドユーザの好み、オペレータ設定及びユーザビヘイビアの少なくとも１つの要因に基づく、システム全体のビジネスロジックを用いてプロバイダを選択することが好ましい。

プロバイダが選択されると、選択された提供部２４０でアプリケーション部／要求側２２０がデータにアクセスできるよう、アプリケーション部／要求側２２０へ送信されることになるデータが、適切なルックアップテーブルから抽出される。提供側における、選択されたパートナーに対する帯域外データが表１から抽出される。直接あるいは１つ以上の中間デバイスを介して提供部へアクセスすることを可能にする、プロバイダのＩＰアドレスあるいは何らかの対応情報が、アクセス手段２２４に供給されることが最低限必要である。提供側において用いられるユーザの信用証明物は、表２を用いて見出される。本例において、要求が関連する主ユーザの内部サービスブローカＩＤは、選択されたデータプロバイダの識別子と共に表に入力され、それにより、ユーザＩＤ及び、必要に応じて、提供側で有効なパスワードを見出すことができる。

選択されたプロバイダに関して収集された帯域外データ及びユーザの信用証明物は、好ましくは上述したように主ユーザのプライバシツリーから読み出されたプライバシポリシーをも含んだメッセージにより、アプリケーション部に戻される（ＩＶ）。好ましくは、要求は、アプリケーション部又は提供部において検証される。これは、要求された個人データを要求者へ配布しうるかどうかを調べるため、要求の内容が、プライバシポリシーの内容と比較されることを意味する。要求が成功したならば、アプリケーション部は要求された個人データを、通知された提供部から読み出す（ＶＩ，ＶＩＩ）。

好適な実施形態において、返送メッセージはＰＳＮが読み出した、予め定義されたテンプレートを用いて生成される。例えば、以下の方法でＳＯＡＰ応答メッセージに統合された、ユーザ定義のポリシーファイルを有するＤＴＤテンプレートである。選択された提供ユニットの識別子は、入来要求からのサービスＩＤとともに、ＤＴＤ及びＳＯＡＰ応答用のテンプレートを見つけるために用いられる。その後、プロバイダに対する帯域外データ、提供側におけるユーザＩＤ及びＤＴＤテンプレート（プライバシポリシーテンプレート）を含んだメッセージ内容が、ＳＯＡＰテンプレートに統合され、ＳＯＡＰ応答を形成する。サービスブローカからアプリケーション部、そして（アプリケーション部における検証が禁止しなければ）提供部へ送信されるメッセージは、［２］に記述されるカプセル化形式とすると有利である。

デーモンノードを指す要求の場合、デーモンノードは付随する固有のサービスＩＤを有し、従って通常は、ＳＯＡＰ応答用テンプレートのような、付随する応答テンプレートを有する。応答は通常、デーモンノードを通じてアクセスされるノードの１つに対して１つＤＴＤを含んでいる。ＤＴＤの代わりに、デーモンノードを用いた集合要求用のみならず、単独の要求についても、ＸＭＬスキーマを用いることができる。プライバシポリシーファイル及び応答メッセージのそのような実施形態及び他の実装もまた、本発明の範囲に含まれる。

もちろん、本発明に従って送信されるメッセージには、暗号化及びデジタル署名を適用すべきである。これには例えば［１］及び［２］に示されるような、従来の暗号化手段を用いることができる。

上述した例において、最終的な要求の検証が、アプリケーション部又は提供部若しくはその両方で行われる。好ましさは低下するが、可能性のある代替方法として、サービスブローカにおいて行いうる検証を実施してもよいことが理解されよう。そのような場合、別の方法でアプリケーション部へ検証結果が通知されるのであれば、プライバシポリシーをアプリケーション部へ戻さなくてもよい。

本発明は、例えば、サービスブローカへ通信される要求がウェブサービス、サービスブローカにおいて発行される情報及びサービスブローカに付随して格納される記述に対する要求であるような場合にまさしく適用可能である。そのようなウェブサービスの実装についての更なる詳細については、［２］を参照されたい。

共通サインオンの実装
上述したように、本発明のサービスブローカシステムを通じたサービスを要求したり、個人データへアクセスしたりしようとするユーザは、好ましくは（図２の矢印ＩＩに従って）共通サインオン（ＣＳＯ）サーバへリダイレクトされ、ＣＳＯサーバによってユーザはサービスブローカにログインする。ＣＳＯ機構を用いることにより、新しいアプリケーションがコンタクトされるごとにユーザ認証が実行される。そのサービスブローカに限定されたディジタルユーザＩＤが発行される。

好ましい実施形態において、ＣＳＯサーバはＰＳＮと通信するためにサービスブローカに配置され、それによってＣＳＯサーバは、予期される要求を初期段階でＰＳＮに警告することでき、システムパフォーマンスが向上する。エンドユーザがＣＳＯ経由でログインする場合、ＰＳＮはエンドユーザの個人プライバシツリーを読み出し、そのエンドユーザに対するセッションを生成するものとする。好ましくは、（一時的な）セッションＩＤが生成され、ＣＳＯから返される。そして、アプリケーション部のアクセス手段からサービス要求を受信するまで、ＰＳＮサーバは通常は待機状態となる。

ＣＳＯ経由で開始された要求手順について、ＰＳＮは、個人データの要求を受信すると、セッションが存在するか確認するであろう。ＣＳＯ手順が使用されることになっており、かつセッションがない場合、処理は中断される。

そのようなＣＳＯ機能についての更なる詳細については、［２］を参照されたい。

図６は、本発明の例示的な実施形態に係る、エンドユーザの制御に従った個人データ取り扱いのための手順を要約したフローチャートである。手順は、ブローカにおいて個人データに対するポリシーを設定することから始まる。最初のステップＳ１で、主エンドユーザから発せられ、選択された個人データ要素に対するプライバシポリシーを規定する命令が、アプリケーション部を介してサービスブローカのプライバシ設定ノードへ通信される。この命令は、選択された個人データ要素に対して少なくとも１つの可能性のあるデータ提供部を規定する。プライバシポリシーは、その主エンドユーザに対する個人プライバシツリーであって、個人データ要素が関連するプライバシポリシーとともに階層的に配置された個人プライバシツリーに保存される（ステップＳ２）。

上述の通り、ブローカにおけるプライバシポリシーの設定は、ユーザからの全くの自発的行為によって実行されても良いし、ユーザが自身に関する個人データに関連するサービス要求を行った際、サービスブローカへリダイレクトされた後に実行されても良い。

アプリケーションノードが特定のサービスを要求した際に開始されるプル／プッシュ手順の概要が、ステップＳ３ーＳ７に示されている。ステップＳ３において、少なくとも１つの個人データ要素に関連する要求が、アプリケーション部からサービスブローカに通信される。この要求は、要求された個人データ要素が関連する主エンドユーザの識別子及びサービス識別子を含んでいる。（有効な）要求が主エンドユーザ又は、その主エンドユーザによって規定された副エンドユーザから発せられる。

プライバシ設定ノードは、要求された個人データ要素のそれぞれに対して、主エンドユーザが規定したプライバシポリシーが存在するか否かを、主エンドユーザの個人プライバシツリーをチェックすることによって判定する。ステップＳ４は、要求された個人データ要素のいずれかに対して、プライバシポリシーが規定されているかどうかを問い合わせている。もしそうであれば、プライバシ設定ノードは、ステップＳ５において、個人データ要素の各々に対し、可能性のあるデータ提供部の中から１つのデータ提供部を選択する。最後のステップＳ６において、プライバシ設定ノードは、アプリケーション部に応答メッセージを返送し、選択されたデータ提供ユニットにおける、要求された個人データ要素へのアクセスを提供する。一方、要求された個人データ要素に対するプライバシポリシーが無ければ、手順は別のパスに移り、好ましくは要求拒否の通知をアプリケーション部に戻すステップＳ７（オプション）を経て終了する。要求者が主ユーザの場合、この通知は、ユーザに、ポリシーを規定したいかどうかを問い合わせることによって達成されても良く、その結果、上述したデータ設定手順及びステップＳ１へのリダイレクトが起こりうる。

本発明を具体的かつ例示的な実施形態に関して説明してきたが、本発明が開示された機能の等価物のみならず、本技術分野における当業者にとって自明な変更物や派生物をも含むことを強調しておくべきであろう。すなわち、本発明の範囲は、特許請求の範囲によってのみ限定される。

本発明を利用可能な、個人データのエンドユーザ制御のための従来の通信システムの模式的な概要を示す図である。 本発明の例示的な実施形態に係る、個人データのエンドユーザ制御のための通信システムの模式的な概要を示す図である。 本発明の例示的な実施形態に従ってプライバシポリシーを構成するために用いられる汎用プライバシツリーを示す図である。 本発明の例示的な実施形態に従ってプライバシポリシーを保存及びアクセスするために用いられる個人プライバシツリーを示す図である。 本発明の例示的な実施形態に係る、デーモンノードを有する個人プライバシツリーを示す図である。 本発明の例示的な実施形態に係る、エンドユーザの制御に従った個人データ取り扱いのための方法のフローチャートである。

Claims (26)

1. サービスブローカ（２５０）と通信するように構成されるアプリケーション部（２００）と、複数のデータ提供部（２４０）とを含む通信システム（２００）において、エンドユーザの制御に従って個人データの取り扱いを行うための方法であって、
   前記サービスブローカのプライバシ設定ノード（２５８）において、選択された個人データ要素に対するプライバシポリシーを規定する、主エンドユーザから発せられた命令であって、少なくとも１つの可能性のあるデータ提供部を前記選択された個人データ要素と関連付ける命令を含む命令を受信し、
   前記プライバシポリシーを、前記プライバシ設定ノードに関連づけられた、前記主エンドユーザに対する個人プライバシツリー（４５１）であって、個人データ要素と対応するプライバシポリシーとについての、階層的に配置されたノードを有する個人プライバシツリーに保存し、
   前記アプリケーション部から前記サービスブローカへ、少なくとも１つのデータ要素に関する要求であって、前記要求される個人データ要素が関連する前記主エンドユーザの識別子及び、サービス識別子とを含む要求を通信し、
   前記プライバシ設定ノードにおいて、前記要求される個人データ要素の各々について、前記主エンドユーザが規定したプライバシポリシーが存在するか否かを、前記主エンドユーザの前記個人プライバシツリーをチェックすることによって判定し、
   前記要求される個人データ要素の少なくともサブセットに対してプライバシポリシーが存在する場合には、
   前記プライバシ設定ノードにおいて、前記規定されたプライバシポリシーを有する前記要求される個人データ要素について、前記可能性のあるデータ提供部の中からデータ提供部を選択し、
   前記プライバシ設定ノードから前記アプリケーション部へ応答メッセージを返送し、前記選択されたデータ提供部における、前記規定されたプライバシポリシーを有する前記要求される個人データ要素へのアクセスを提供する、ことを特徴とする方法。
2. 前記個人プライバシツリー（４５１）が、階層的に配置されたノード（３５３）を有する汎用プライバシツリー（３５１）の少なくとも一部に基づいており、その少なくともサブセットが、プライバシポリシーが規定されうる個人データ要素の各々を指し示すことを特徴とする請求項１記載の方法。
3. 前記サービスブローカ（２５０）に通信される前記要求が、前記プライバシツリー（５５１）内の個々の個人データ要素を有する複数のノード（５５３）を指し示すデーモンノード（５５７）のサービス識別子を含む集合要求であることを特徴とする請求項１又は請求項２記載の方法。
4. 前記デーモンノード（５５７）が、前記プライバシツリー（５５１）の異なるサブツリーもしくは異なるレベルに配置された複数のノード（５５３）を指し示すことを特徴とする請求項３記載の方法。
5. 前記主エンドユーザの個人プライバシツリー（４５１）及び前記前記階層ツリー構造における前記プライバシポリシーに対する前記ノード（４５３）へのポインタの各々を用い、前記プライバシポリシーを収集するステップを含むことを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
6. 前記プライバシポリシーを収集するステップが、少なくとも１つの予め定められたルックアップテーブルを使用して、前記サービスブローカ（２５０）において有効な前記主エンドユーザの識別子に基づいて前記個人プライバシツリー（４５１）への前記ポインタを取得するとともに、前記サービス識別子に基づいて前記プライバシポリシーに対する前記ノード（４５３）への前記ポインタを取得することを特徴とする請求項５記載の方法。
7. 前記主エンドユーザからのさらなる命令に従って、少なくとも１人の副エンドユーザを割り当てるステップをさらに有し、前記副エンドユーザが、前記主エンドユーザに関する前記個人データ要素の少なくともサブセットへのアクセスを許可されることを特徴とする請求項１乃至請求項６のいずれか１項に記載の方法。
8. 前記プライバシ設定ノード（２５８）において、前記アプリケーション部（２２０）からの前記要求の発生元をチェックするステップと、
   前記要求が、前記要求される個人データ要素の前記主エンドユーザ、もしくは前記要求される個人データ要素について、前記主エンドユーザによって割り当てられた副エンドユーザから発生したものでない限り、前記要求を拒否するステップとをさらに有することを特徴とする請求項７記載の方法。
9. 前記応答メッセージが、前記選択されたデータ提供部（２４０）において有効なユーザ識別子及び、前記選択されたデータ提供部のＩＰアドレスを含むことを特徴とする請求項１乃至請求項８のいずれか１項に記載の方法。
10. 前記応答メッセージがさらに、前記要求される個人データ要素に対する前記プライバシポリシーを含むことを特徴とする請求項９記載の方法。
11. 前記アプリケーション部（２２０）又は前記選択されたデータ提供部（２４０）において、前記要求と、前記要求される個人データ要素に対する前記プライバシポリシーとを比較することによって、前記要求を検証するステップをさらに有することを特徴とする請求項１０記載の方法。
12. 前記選択されたデータ提供部（２４０）において有効な前記ユーザ識別子及び、前記選択されたデータ提供部の前記ＩＰアドレスを、前記サービスブローカにおいて有効な前記主エンドユーザの識別子及び前記選択されたデータ提供部の識別子を入力として、少なくとも１つのルックアップテーブルから収集するステップをさらに有することを特徴とする請求項９乃至請求項１１のいずれか１項に記載の方法。
13. 共通サインオン（ＣＳＯ）サーバ（２５６）において、前記アプリケーション部（２２０）で受信された全ての要求に対し、エンドユーザ認証イベントを実行するステップをさらに有し、前記ＣＳＯサーバは前記サービスブローカ内に配置され、前記プライバシ設定ノードと通信するように構成されていることを特徴とする請求項１乃至請求項１２のいずれか１項に記載の方法。
14. エンドユーザの制御に従って個人データを取り扱うための手段を有する通信ノード（２５８）であって、前記通信ノードは、通信システム（２００）内のサービスブローカ（２５０）に配置されるとともに、前記通信システムは、前記サービスブローカと通信されるように構成されるアプリケーション部（２２０）と、複数のデータ提供部（２４０）とをさらに備えており、前記通信ノードが、
    選択された個人データ要素に対するプライバシポリシーを規定する、主エンドユーザから発せられた命令であって、少なくとも１つの可能性のあるデータ提供部を前記選択された個人データ要素と関連付ける命令を含む命令を受信する手段と、
    前記プライバシポリシーを、前記主エンドユーザに対する個人プライバシツリー（４５１）であって、個人データ要素と、関連するプライバシポリシーとについての、階層的に配置されたノード（４５３）を有する個人プライバシツリーに保存する手段と、
    前記アプリケーション部から前記サービスブローカへ通信される、少なくとも１つのデータ要素に関する要求であって、前記要求される個人データ要素が関連する前記主エンドユーザの識別子及び、サービス識別子とを含む要求を受信する手段と、
    前記要求される個人データ要素の各々について、前記主エンドユーザが規定したプライバシポリシーが存在するか否かを、前記主エンドユーザの前記個人プライバシツリーをチェックすることによって判定する手段と、
    前記要求される個人データ要素の少なくともサブセットに対してプライバシポリシーが存在する場合、前記規定されたプライバシポリシーを有する前記要求される個人データ要素について、前記可能性のあるデータ提供部の中からデータ提供部を選択する手段と、
    前記アプリケーション部へ応答メッセージを返送し、前記選択されたデータ提供部における、前記規定されたプライバシポリシーを有する前記要求される個人データ要素へのアクセスを提供する手段とを有することを特徴とする通信ノード。
15. 前記個人プライバシツリー（４５１）が、階層的に配置されたノード（３５３）を有する汎用プライバシツリー（３５１）の少なくとも一部に基づいており、その少なくともサブセットが、プライバシポリシーが規定されうる個人データ要素の各々を指し示すことを特徴とする請求項１４記載の通信ノード。
16. 前記個人又は汎用プライバシツリー（５５１）が、前記プライバシツリー内の複数のノード（５５３）を指し示す少なくとも１つのデーモンノード（５５７）を有し、それによって１つの集合要求を通じて複数の個人データ要素に到達可能であることを特徴とする請求項１４又は請求項１５記載の通信ノード。
17. 前記デーモンノード（５５７）が、前記プライバシツリー（５５１）の異なるサブツリーもしくは異なるレベルに配置された複数のノード（５５３）を指し示すことを特徴とする請求項１６記載の通信ノード。
18. 前記主エンドユーザの個人プライバシツリー（４５１）及び前記前記階層ツリー構造における前記プライバシポリシーに対する前記ノード（４５３）へのポインタの各々を用い、前記プライバシポリシーを収集する手段をさらに含むことを特徴とする請求項１４乃至請求項１７のいずれか１項に記載の通信ノード。
19. 前記プライバシポリシーを収集する手段が、少なくとも１つの予め定められたルックアップテーブルを使用して、前記サービスブローカにおいて有効な前記主エンドユーザの識別子に基づいて前記個人プライバシツリー（４５１）への前記ポインタを取得するとともに、前記サービス識別子に基づいて前記プライバシポリシーに対する前記ノード（４５３）への前記ポインタを取得することを特徴とする請求項１８記載の通信ノード。
20. 前記主エンドユーザからのさらなる命令に従って、少なくとも１人の副エンドユーザを割り当てる手段をさらに有し、前記副エンドユーザが、前記主エンドユーザに関する前記個人データ要素の少なくともサブセットへのアクセスを許可されることを特徴とする請求項１４乃至請求項１９のいずれか１項に記載の通信ノード。
21. 前記アプリケーション部（２２０）からの前記要求の発生元をチェックする手段と、
    前記要求が、前記要求される個人データ要素の前記主エンドユーザ、もしくは前記要求される個人データ要素について、前記主エンドユーザによって割り当てられた副エンドユーザから発生したものでない限り、前記要求を拒否する手段とをさらに有することを特徴とする請求項２０記載の通信ノード。
22. 前記応答メッセージが、前記選択されたデータ提供部（２４０）において有効なユーザ識別子及び、前記選択されたデータ提供部のＩＰアドレスを含むことを特徴とする請求項１４乃至請求項２１のいずれか１項に記載の通信ノード。
23. 前記応答メッセージがさらに、前記要求される個人データ要素に対する前記プライバシポリシーを含むことを特徴とする請求項２２記載の通信ノード。
24. 前記選択されたデータ提供部（２４０）において有効な前記ユーザ識別子及び、前記選択されたデータ提供部の前記ＩＰアドレスを、前記サービスブローカ（２５０）において有効な前記主エンドユーザの識別子及び前記選択されたデータ提供部の識別子を入力として、少なくとも１つのルックアップテーブルから収集する手段をさらに有することを特徴とする請求項２２又は請求項２３に記載の通信ノード。
25. 前記アプリケーション部（２２０）で受信された全ての要求に対してエンドユーザ認証イベントが存在するように、前記サービスブローカ（２５０）内の共通サインオン（ＣＳＯ）サーバ（２５６）と通信するように構成された認証手段をさらに有することを特徴とする請求項１４乃至請求項２４のいずれか１項に記載の通信ノード。
26. エンドユーザの制御に従った個人データ取り扱いを行うための手段を有する通信システム（２５０，２００）であって、請求項１４乃至請求項２５のいずれか１項に記載の通信ノード（２５８）を有することを特徴とする通信システム。

Images