(57)【要約】柔軟なアクセス制御機能を備えた顧客プロファイル・アクセスプロトコルを提供する。このプロトコルは、ユーザプロファイルのデータへの安全でプライバシー保護可能なアクセスが容易に実現できるようにする。ユーザプロファイルのデータには、他のユーザ、サービスプロバイダ、及びシステム管理者のようなクライアントがアクセスできる。ユーザプロファイルデータは、サービスプロバイダ及びシステム管理者による使用が可能である。ユーザプロファイルデータは、ユーザに提供されるサービスをカスタマイズするためにサービスプロバイダが使用できる。プロファイルへのアクセスを制御する許可を、ユーザによる管理の元で設定できる。ユーザは、ユーザプロファイル内の異なる階層の情報に関して異なる許可を指定できる。例えば、第１組の許可はユーザプロファイル全体に関連付ける一方、第２組の許可はユーザプロファイル内の特定フィールドに関連付けることができる。許可が１つのグループ又は代数集合演算子により指定される複数グループの組合せに関連付けられるように、クライアントをグループ分けできる。
2004530195.tif 000002
【特許請求の範囲】
【請求項１】
電子装置における方法であって、
ユーザに関する情報を保持したユーザプロファイルを提供する段階と、
前記ユーザプロファイルに関する第１組の許可を設定する段階であって、前記第１組の許可が、前記ユーザプロファイルに誰がアクセスできるかを指定する、設定する段階と、
前記ユーザプロファイルの選択した下位区分に関する第２組の許可を設定する段階であって、前記第２組の許可が、前記下位区分に誰がアクセスできるかを指定する、設定する段階とを含み、
関係者が前記選択した下位区分にアクセスするには、この関係者が、前記ユーザプロファイルへのアクセス権を持っていることが前記第１組の許可によって指定されていなければならず、前記選択した下位区分にアクセス権を備えていることが前記第２組の許可によって指定されていなければならない、方法。
【請求項２】
前記下位区分がフィールドである、請求項１に記載の方法。
【請求項３】
前記第１組の許可が、前記ユーザプロファイルへアクセスできる者に、前記ユーザプロファイルにどんな種類のアクセスが許可されるかを指定する、請求項１に記載の方法。
【請求項４】
少なくとも１つの関係者には前記ユーザプロファイルへの読み出しアクセスが許可され、これが、この関係者は前記ユーザプロファイル内の情報を読み出してよいことを表す、請求項３に記載の方法。
【請求項５】
少なくとも１つの関係者には前記ユーザプロファイルへの書き込みアクセスが許可され、これが、この関係者は前記ユーザプロファイル内に情報を書き込んでよいことを表す、請求項４に記載の方法。
【請求項６】
少なくとも１つの関係者には前記ユーザプロファイルへの可用性アクセスが許可され、これが、この関係者は前記ユーザプロファイルが利用可能かどうかを確認できることを表す、請求項４に記載の方法。
【請求項７】
少なくとも１つの関係者には前記ユーザプロファイルへの削除アクセスが許可され、これが、この関係者は前記ユーザプロファイル内の情報を削除してよいことを表す、請求項４に記載の方法。
【請求項８】
前記第２組の許可が、誰が前記ユーザプロファイルにアクセスできるかを指定する、請求項１に記載の方法。
【請求項９】
前記第１組の許可及び前記第２組の許可の一方が、それぞれ前記ユーザプロファイル及び前記下位区分にアクセスできる関係者のリストを含む、請求項１に記載の方法。
【請求項１０】
複数の当事者からなる定義済みグループが提供され、前記第１組の許可及び前記第２組の許可の少なくとも一方が、前記グループの１つがアクセス権を持っていることを指定する、請求項１に記載の方法。
【請求項１１】
前記ユーザが、前記第１組の許可及び前記第２組の許可の少なくとも一方を指定する、請求項１に記載の方法。
【請求項１２】
前記第１組の許可及び前記第２組の許可の少なくとも一方が、デフォルトにより設定される、請求項１に記載の方法。
【請求項１３】
前記ユーザプロファイル内の付加的な下位区分に関する第３組の許可を設定する段階を更に含み、前記第３組の許可が、誰が前記付加的な下位区分にアクセスできるかを指定する、請求項１に記載の方法。
【請求項１４】
前記ユーザプロファイルの前記下位区分が階層的に編成されており、前記下位区分が前記付加的な下位区分を含む、請求項１２に記載の方法。
【請求項１５】
定義済みグループが提供され、前記第１組の許可及び前記第２組の許可の少なくとも一方が、誰がアクセス権を持っているかをアクセス集合として指定し、前記アクセス集合が、前記グループの少なくとも２つに関して実行された集合代数演算から得られたものである、請求項１に記載の方法。
【請求項１６】
ネットワークを介してアクセス可能な、ユーザに関する情報を保持したユーザプロファイルを提供する段階と、
前記ユーザにサービスを提供するサービスプロバイダのグループを指定する段階であって、各グループが一組のサービスプロバイダを含んだ、指定する段階と、
選択したユーザプロファイル内の許可された情報へのアクセス許可を前記グループの選択した１つのグループに与えて、前記選択したグループ内のサービスプロバイダが、前記許可された情報にアクセスできるようにする段階とを含む、方法。
【請求項１７】
前記選択したグループ内の全てのサービスプロバイダが、共通した種類のサービスを提供する、請求項１６に記載の方法。
【請求項１８】
少なくとも１つのグループが、このグループの部分集合を構成する他のグループを含み、前記グループが論理的に関連したサービスプロバイダを含む、請求項１６に記載の方法。
【請求項１９】
前記ユーザプロファイルには集中リポジトリを介してアクセス可能であり、前記ユーザプロファイル内の前記許可された情報には、このアクセス可能な情報を前記ユーザから直接的に要請しなかったサービスプロバイダがアクセスできる、請求項１６に記載の方法。
【請求項２０】
電子装置における方法であって、
様々なフィールドを備えたユーザプロファイルを提供する段階であって、前記フィールドの少なくとも１つが関連付けられた許可を備えた、提供する段階と、
少なくとも１つの選択したフィールドへのアクセスを阻止するように、又、前記ユーザプロファイル中の少なくとも１つの所定のフィールドへのアクセスを許可するように、前記許可を所定のサービスプロバイダに関して設定して、前記ユーザの身元を伏せることにより、前記所定のサービスプロバイダと前記ユーザとの間の匿名トランザクションをサポートする段階とを含む、方法。
【請求項２１】
前記ユーザプロファイルが、前記ユーザの名前を保持する名前フィールドを含み、前記選択したフィールドが前記名前フィールドである、請求項２０に記載の方法。
【請求項２２】
前記ユーザプロファイルが、前記ユーザの住所を保持する住所フィールドを含み、前記選択したフィールドが前記住所フィールドである、請求項２０に記載の方法。
【請求項２３】
前記許可が、前記フィールドの中の複数フィールドへの前記所定のサービスプロバイダによるアクセスを阻止するように設定されている、請求項２０に記載の方法。
【請求項２４】
前記ユーザプロファイルが、支払い機構に関する情報を保持する支払いフィールドを含み、前記選択したフィールドが前記支払いフィールドである、請求項２０に記載の方法。
【請求項２５】
前記ユーザプロファイルが、クレジットカード番号を保持するクレジットカードフィールドを含み、前記選択したフィールドが前記クレジットカードフィールドである、請求項２０に記載の方法。
【請求項２６】
電子装置における方法であって、
ユーザに関する情報をフィールドに保持したユーザプロファイルを提供する段階と、
（ｉ）  前記ユーザプロファイル内のフィールドと、
（ｉ）  前記ユーザプロファイル内の前記フィールドに関するアクセス許可と、
（ｉｉｉ）  前記ユーザプロファイル内の前記フィールドの選択したものへのアクセス許可を備えたグループのメンバと、
（ｉｖ）  グループに関するアクセス情報を指定するグループアクセス許可と、
（ｖ）  前記アクセス許可に関する許可を指定する許可アクセス許可と、
（ｖｉ）  前記ユーザプロファイルに関するスキーマ定義と、
からなる項目の取得及び設定を可能にするプロトコルを提供する段階とを含む、方法。
【発明の詳細な説明】
【関連出願】
【０００１】
本願は、２００１年３月１４日付けで出願された「ユーザプロファイル管理のためのアクセス制御プロトコル」と題する米国特許出願第０９／８０８，９１１号の優先権を主張する。この特許出願の発明者は本願と同一であり、この特許出願は引用してここに援用する。
【技術分野】
【０００２】
本発明は、一般に情報処理に関わり、より詳しくはユーザプロファイル管理のためのアクセス制御プロトコルに関する。
【発明の背景】
【０００３】
インターネットサービスプロバイダ及び無線サービスプロバイダは、一般に、ユーザに関する情報をユーザプロファイルに維持することで、ユーザへのサービスの個人化に努める。各サービスプロバイダは、購入履歴、選好、代金請求情報などのような各ユーザに関するデータを別々に格納している。サービスプロバイダは、ユーザに関するデータを収集し、そのデータを特定のデータ形式で格納する役目を担う。
【０００４】
残念ながら、ユーザへのサービスをカスタマイズするこの従来のアプローチには幾つかの欠点がある。第一に、同一労力の繰り返しが多くなる。別々のサービスプロバイダが、名前、住所、及び電話番号などのユーザに関する同一情報を維持することがある。これは内在的な非能率性であり、ユーザは、同一情報を多数のサービスプロバイダに提出することを求められる場合もあり、ユーザにとっても面倒な問題である。更に、各サービスプロバイダは、ユーザ選好の一部（すなわち、それぞれのサービスプロバイダが収集したデータのみ）しか把握していない。こうしたわけで、各ベンダーは、ユーザに提供されるサービスの一部のみしか個人化できないことがある。三番目の問題として、典型的にはユーザは、サービスプロバイダが格納するデータを管理することができない。実際のところ、殆どのユーザは、収集されたデータにアクセスすることもできない。こうしたデータは、非良心的なサービスプロバイダにより悪用されることもある。四番目の問題としては、情報が全てのサービスプロバイダに自動的に伝搬されるのでなく、正確な情報は、典型的には一部の選択したサービスプロバイダにしか与えられないので、あるユーザに関して収集されたデータは不正確であるか、或いは期限切れである場合がある。
【発明の開示】
【０００５】
発明の概要
本発明は、ユーザプロファイルの基礎構造を提供することによって、ユーザに関するデータを入手し且つ維持する従来のアプローチの制約に対処する。この基礎構造によれば、ユーザプロファイルは中央リポジトリを介して格納され、アクセスされる。ユーザプロファイルは、多数のサービスプロバイダがアクセスできる情報を含むことができる。ユーザ１人に付き１つのユーザプロファイルしか存在しないので、変更は一個所で行うだけでユーザプロファイルが最新状態に維持される。ユーザプロファイルは、ユーザによって修正できる。ユーザは、自分のユーザプロファイルを完全に制御することができ、又、ユーザプロファイルに導入する情報を特定できる。更に、ユーザは、どのクライアントが自分のユーザプロファイル内の情報にアクセスする許可を得るかを指定する許可を制御することもできる。これら許可は、各クライアントに与えられるアクセスの種類を指定してもよい。許可はユーザプロファイル全体に関して指定されるだけでなく、ユーザプロファイル内の個別フィールドに関して指定してもよい。
【０００６】
この基礎構造は、クライアントによるユーザプロファイルの作成、管理、及びアクセスを容易にするプロトコルを含む。クライアントには、サービスプロバイダ、システム管理者、及びユーザが含まれる。アカウント情報は、それぞれの種類のクライアントに関して維持してもよい。
【０００７】
本発明の第１の局面によれば、この方法は、電子装置において実施される。この方法によれば、ユーザに関する情報を保持するユーザプロファイルが提供される。一組の許可がユーザプロファイルに関して設定される。この一組の許可は、誰がユーザプロファイルにアクセスできるかを指定し、更に、どの種類のアクセスが許可されるかも指定する。
【０００８】
本発明の別の局面によれば、ユーザに関する情報を保持したユーザプロファイルが提供される。これらユーザプロファイルにはネットワークを介してアクセスできる。サービスプロバイダのグループが定義できる。各グループは、一組のサービスプロバイダを含む。アクセス許可が、これらグループ内の選択した何れか１つを介して与えられ、この選択したグループ内のサービスプロバイダによる情報へのアクセスを容易にする。
【０００９】
本発明の更に別の局面によれば、様々なフィールドを備えたユーザプロファイルが電子装置内に設けられ、これらフィールドの少なくとも幾つかは、関連付けられた許可を備えている。これら許可は、少なくとも１つの選択したフィールドへのアクセスを阻止し、ユーザプロファイル中の少なくとも１つの所定フィールドへのアクセスを許可するように、所定のサービスプロバイダに関して設定され、この所定のサービスプロバイダとユーザとの間の匿名トランザクション（すなわち、ユーザの身元が明かされないトランザクション）をサポートする。
発明の詳細な説明
【００１０】
本発明の例示的実施形態は、柔軟なアクセス制御能力を備えたユーザプロファイル・アクセスプロトコルを提供する。このプロトコルは、ユーザプロファイルスキーマ定義、ユーザプロファイルフィールド、ユーザプロファイルアクセス許可（各フィールドごとに）、許可がどの関係者に与えられるかを定義するグループ、グループアクセス許可、及び許可アクセス許可（すなわち、「メタ許可」）を取得し、設定する演算を含む。
【００１１】
ユーザプロファイルには、管理者、ユーザ、及びサービスプロバイダなどのクライアントがアクセスできる。ユーザプロファイルは、インターネットサービスプロバイダ及び無線サービスプロバイダと組み合わせて使用するのに特に適するように構成されている。このプロトコルは、ユーザ選好及びその他の種類のユーザ情報を生成し、修正し、且つアクセスする手法を提供する。サービスプロバイダは、このユーザプロファイル情報にアクセスして、顧客に提供するサービスをカスタマイズできる。
【００１２】
このプロトコルは、選好マネージャと１つのクライアントとの間の対話を指定する。要求と、このプロトコルの応答とを移送するための通信機構は存在しているものと想定される。クライアントは、コンピュータネットワーク（インターネットのような）又は通信ネットワーク（無線ネットワークのような）のようなネットワークを介して選好マネージャと通信できる。一般に、このプロトコルは、選好マネージャとクライアントとの間に通信路を必要とする。
【００１３】
ＰＭＴプロトコルは、ユーザプロファイル内の各データ単位へのアクセスを、そのデータに関連付けられた許可を検査することで制御する。許可は、ユーザプロファイル全体に関連付けられていてもよいし、プロファイル内の１つのフィールドに関連付けられていてもよい。従って、許可の細分性は、最小項目をフィールドとして様々に変更できる。許可は、グループ単位で指定してもよい。事実、許可は、グループに適用される集合代数を用いて指定できる。例えば、あるユーザプロファイルには、２つのグループの合併集合により識別される複数クライアントがアクセスできるようにしてもよい。１つのグループは、クライアントの一覧（すなわち、各クライアントが関連付けられたアカウント識別を持つアカウント識別の一覧）として、或いは他のグループに関して定義してよい。こうしたグループを用いることで、同一カテゴリのサービスプロバイダのグループ内でのデータ共有、及び他の種類のデータ共有が可能となる。更に、これらグループは、ユーザプロファイルへのアクセスを許可されたクライアントの動的修正を容易に可能にする。例えば、ユーザが、ピザ販売業者のあるグループに、ユーザの電話番号へのアクセスを許可した場合は、このピザ販売業者グループは動的に修正されるので、ユーザがユーザプロファイルを更新して、そのグループに加わったか或いはそこから削除されたピザ販売業者を含めたり、除去したりする必要はない。これら許可を指定することが、そうした変更を自動的に行うことになる。
【００１４】
ユーザプロファイルは、サービスプロバイダ固有フィールド（すなわち、クライアント指定スキーマ）を含んでよい。例えば、ピザ販売業者が、ユーザが好むピザを指定するフィールドを持っていてもよい。更に、ユーザプロファイルは、ユーザ名、住所、及び電話番号などのより一般的な情報を含んでもよい。
【００１５】
このプロトコルでは、各通信の意味を規定する。例えば、あるユーザに関する情報を取得する場合、この要求にどのように応答するかは、許可がこの状況で何を意味するかに依存する。このプロトコルは、各ユーザに関して格納されている情報の詳細に加え、許可の取得及び取り出しを記述する。このプロトコルは、更に、グループ及びアカウントの定義も記述する。このプロトコルは、簡潔性を維持しながら、強力な基礎構造を提供することを目指す。
【００１６】
図１は、本発明の例示的な実施形態で使用する構成要素を示す。ＰＭＴサーバ１０は、データベース１４に格納されているユーザプロファイルに関わるトランザクションを容易にするために設けられている。ＰＭＴサーバ１０は、コンピュータシステム又は他の知的電子装置上で実行するサーバプロセスであると考えられる。ＰＭＴプロトコル１２は、ＰＭＴサーバ１０にサポートされており、このＰＭＴプロトコルに従ってトランザクションが実行される。クライアントもＰＭＴプロトコルをサポートしている（例えば、クライアントは適切なＰＭＴ要求を作成できる）ものと考える。ＰＭＴサーバ１０は、データベース１４内のデータへのアクセスを求めるクライアントのアカウントのレジストリを維持するアカウントマネージャ１６を実行できる。上述のように、各アカウントは、サービスプロバイダ又はシステム管理者などのクライアントユーザを表す。ＰＭＴサーバ１０は、ユーザがユーザプロファイル内のデータに関して明示的な許可を指定しなかった場合に割り当てられる、幾つかのデフォルト許可１８も保持している。データベース１４は、ユーザプロファイル、クライアント（サービスプロバイダなど）からなるグループに関する情報、及び許可情報を保持している。
【００１７】
サービスプロバイダ（ＳＰ）２０は、ＰＭＴプロトコル１２を用いてＰＭＴサーバ１０に通信することで、データベース１４内のデータにアクセスできる。データ共有機構２２は、リポジトリと、幾つかの種類の個人データを格納する別のシステム（例えば、サービスプロバイダが維持するシステムなど）との間の情報交換を容易にする。匿名セッションイネーブラ機構２４は、後に詳述するように、ＰＭＴプロトコルとの通信セッションが匿名で行われるのを可能にする。安全トランザクションマネージャ２６は、サービスプロバイダとＰＭＴプロトコル１０との間の通信が安全に行われるのを保証するために設けられている。
【００１８】
ユーザインターフェースロジック２８を設けて、ユーザがＰＭＴサーバ１０と通信できるようにしてもよい。ユーザが、ユーザプロファイル許可を修正するのに加え、ユ―ザプロファイル及び関連付けられた許可を表示できるのが好ましいことがある。例えば、ＰＭＴサーバ１０は、検証され且つ認証されたユーザが、ユーザプロファイル及び関連付けられた許可を検討し、修正できるようにするウェブページを提供できる。ユーザインターフェースロジック２８は、ユーザとＰＭＴサーバ１０との間の対話を容易にする。上述のように、ユーザは、ウェブ装置３２を介してＰＭＴサーバ１０にアクセスし、このサーバと通信できる。ウェブ装置３２は、ウェブユーザインターフェース３４を介してインターネットを通じて、或いは他のコンピュータネットワークを通じて通信する。ウェブ装置の例には、パーソナルコンピュータ、インターネット機器、ネットワークコンピュータ、及びウェブブラウザに依存する他の種類の装置が含まれるが、それらには限定されない。ユーザは、携帯電話、個人情報機器（ＰＤＡ）、及びインテリジェントページャなどの無線装置３０を用いて無線ユーザインターフェース３６を介して通信できる。無線装置３０は、無線アプリケーションプロトコル（ＷＡＰ）を用いてＰＭＴサーバ１０と通信するＷＡＰ装置３０でよい。
【００１９】
図２は、例示的な実施形態が実施される環境の一例を示す。ＰＭＴサーバ１０は、ネットワーク５０（例えば、インターネット、コンピュータネットワーク、又は通信ネットワーク）と接続している。様々なサービスプロバイダ５２及び５４が、ネットワーク５０を介して接続されたリソースを備えている。ユーザプロファイルがデータベース１４に格納されているユーザ５６は、ネットワーク５０にアクセスできる。管理者５８には、サーバ１０への直接アクセス権があってもよい（すなわち、直接ケーブル接続されていてもよい）。サーバ１０は、ユーザプロファイル内のデータを維持する役割を担う選好マネージャ１７を含む。更に、サーバ１０は、ユーザ及びクライアントを認証するための認証機構を備えていてもよい。更に一般的には、ＰＭＴプロトコル２８へのその他のサポートもサーバ１０に格納して、このサーバ上で実行してもよい。このサーバは、実行を補助する複数のサーブレット１５を備えていてもよい。データベース１４は、ユーザプロファイル、アカウント情報、及びグループ分けに関わる情報を含む。
【００２０】
当業者であれば、単一のデータベースでなく、多数のデータベースを用いてもよく、このデータベースの多数の複製を設けてもよいことは理解するすはずである。更に、多数のＰＭＴサーバを設けて、可用性を高めたり、負荷の最適配分を行ったり、トランザクションの待ち時間を減少させたりできる。
【００２１】
上述のように、クライアントは多くの形態を取ることができる。図３は、クライアント１６が、サービスプロバイダ６２でよいことを示している。サービスプロバイダは、無線ネットワーク又はコンピュータネットワークなどのネットワークを介してサービスを提供する。サービスプロバイダは、顧客がインターネットを介してアクセスするインターネットサービスプロバイダ（ＩＳＰ）でもよい。クライアントは、ユーザ６４又は管理者６６でもよい。
【００２２】
ユーザプロファイル内の情報は、階層的に格納してもよい。当業者であれば、データはレコード形式で格納する必要はなく、他のデータ種類でもよいことは理解するはずである。例えば、場合によっては、全てのデータをオブジェクト中にカプセル化してもよい。こうしたオブジェクトは階層編成してもよい。これらデータは階層的である必要はなく、非階層的でもよい。
【００２３】
図４は、ユーザプロファイル６８の一部の一例を示す。ユーザプロファイル６８内に格納されたデータは、ユーザ名７２、住所７４、及び電話番号７６を含む。任意のストア（「ストアＸ」）に関する情報をユーザプロファイル６８に格納してもよい。ユーザのピザの好み８５も、ユーザプロファイル６８に格納してよい。同様に、カフェラッテ９０に関するコーヒーの好みも、カフェモカ８８に関するコーヒーの好みと共に含めてもよい。他のデータ９１もユーザプロファイル６８に格納してよい。
【００２４】
ユーザに関する許可を指定できるが、その際の細分性は可変である。許可はユーザプロファイル全体に関連付けられていてもよく、或いはユーザプロファイル内の１つのフィールドに関連付けられていてもよい。異なるデータ構造が使用される場合は、細分性を変更して、使用される特定のデータ構造に合わせることができる。図５は、こうした許可の一例を示す。ユーザプロファイル６８は、名前フィールド７２、住所フィールド７４、及び電話番号フィールド７６を含む。許可をユーザプロファイル６８に関して格納し、更に、許可を電話番号フィールド７６に関しても格納する。ユーザプロファイル６８に関する許可１０２は、ユーザプロファイル１００に関連付けられたユーザの一意の識別子を指定するユーザ識別１０４を含む。又、許可１０２は、ユーザプロファイルにアクセスできるクライアント又はグループそれぞれのアカウント識別及びアクセス権１０６も指定する。最後に、許可１２２は電話番号フィールド７６に関して格納されている。フィールド識別１２４は、電話番号フィールド７６を一意に識別する。この電話番号フィールドにアクセスできる人の一覧１２６が提供されている。
【００２５】
許可は、クライアントに与えられるアクセスの種類も指定する。これらの許可には、クライアントによる関連付けられたデータ単位に対する読み出し及び書き込みを可能とする書き込みアクセスと、クライアントによる関連付けられたデータ単位に対する読み出しは許可するが、書き込みは許可しない読み出しアクセスとが含まれる。これら許可には削除アクセスも含まれる。削除アクセスでは、クライアントは、関連付けられたデータ単位内のデータを削除できる。可用性アクセスでは、クライアントは、このデータが利用可能かどうかを確認できる。更に、許可には、クライアントによる許可値の書き込みを可能とする許可書き込みアクセスが含まれる。
【００２６】
このプロトコルは、クライアントからなるグループの定義の記述を容易にする。グループは、サービスプロバイダをグループ分けするのにとりわけ適している。グループ分けすることで、サービスプロバイダは情報を共有し、許可を個別クライアントでなくグループに関連付けることが可能になる。
【００２７】
図６に示したように、グループは階層的に編成してもよい。図６は、サービスプロバイダグループの階層１５０を示す。食品グループ１５２は、食品産業に分類されるサービスプロバイダを包含する。食品グループ１５２は、ピザ販売業者の下位グループ１５４及びファーストフード販売業者の下位グループ１５６を含むことができる。ピザ販売業者グループ１５４は、ピザキングというサービスプロバイダ１５８とピザシャックというサービスプロバイダ１６０を含むことができる。同様に、ファーストフードグループ１５６は、バーガーマイスターというサービスプロバイダ１６２及びジョニーズバーガー１６４を含むことができる。
【００２８】
上述のように、アカウント情報は各クライアントに関して維持し、各クライアントは固有のアカウント識別により識別される。アカウントに関して、代金請求情報や他の関連情報などの付加的情報を維持してもよい。
【００２９】
グループはアカウントの収集体か、或いは他のグループの集合代数式である。具体的には、これら代数式は、合併、及び共通部分、及び集合差の集合代数演算子を用いる。集合代数式により定義されるグループは、動的に評価される。グループに変化があると、式の得られる値も動的に変化する。
【００３０】
このプロトコルは、応答／要求プロトコルである。言い換えると、要求が提示されて、応答が返される。要求では幾つかの異なるパラメータが用いられる。これらのパラメータには、クライアントを識別する文字数字の列を与えるアカウント識別が含まれる。別のパラメータとしては、グループを一意に識別するグループ識別がある。同様に、フィールドを識別するフィールド識別がある。識別の種類には、読み出し、書き込み、可用性、及び削除が含まれる。付加的な許可には、許可読み出し及び許可書き込みがある。
【００３１】
このプロトコルは、セッションを開始する前にはログインが必要であることを指定する。ＰＭＴサーバ１０とのセッション開始を求めるクライアントには、アカウント識別及びパスワードの提出を要求するようにしてもよい。
【００３２】
このプロトコルは、データベース１４に格納されているデータに関連付けることができる幾つかの演算を指定する。これらの演算には次のものが含まれる。
getNodeData
setNodeData
deleteProfileNode
getPermission
setPermission
問い合わせ
【００３３】
getNodeData演算は、求められている情報ユーザプロファイルを識別する渡されるパラメータである。この情報は、ユーザ識別及びフィールド識別を含むことができる。対照的に、フィールドを求める場合は、ユーザ識別及びフィールド識別を全て指定しなければならない。要求クライアントが適切な許可を得ていれば、ｇｅｔ要求により所望のデータがクライアントに返される。そうでなければ、クライアントは、要求が拒否されたことを示す適切なメッセージを受け取ることになる。
【００３４】
setNodeData演算子は、クライアントがユーザプロファイル内で値を設定できるようにする。入力パラメータには、ユーザ識別、フィールド識別、及び設定する値が含まれる。
【００３５】
deleteProfileNode演算は、クライアントがフィールド又はユーザプロファイルを削除できるようにする。入力パラメータは、このフィールド又はユーザプロファイルを指定する。クライアントは、適切な削除アクセス許可を持っていなければならない。
【００３６】
getPermission演算は、クライアントがフィールド又はユーザプロファイルに関連付けられた許可を入手できるようにする。フィールド又はユーザプロファイルは、入力パラメータにより指定される。
【００３７】
setPermission演算子は、クライアントがフィールド又はユーザ識別に関する許可を設定できるようにする。このコマンドを使って、１つのグループ全体に設定許可を設定できる。
【００３８】
問い合わせ演算は、問い合わせ基準に一致するユーザ識別の一覧を返す。
【００３９】
このプロトコルは、グループを管理する要求で提出できる演算も指定する。これらの演算には次のものが含まれる。
getMembers
newGroup
defineGroup
deleteGroup
getGroupPermission
setGroupPermission
【００４０】
getMembers演算子は、クライアントが、グループ識別入力パラメータにより識別されるグループ内のメンバの一覧を入手できるようにする。
【００４１】
newGroup演算子は、クライアントが新たなグループを定義できるようにする。入力パラメータは、テキスト形式の記述に加えグループ名も含む。クライアントには、グループ識別及び／又は新たな空のグループが定義されたという確認が返される。
【００４２】
defineGroup演算子は、newGroup演算子を用いて作成されたグループのメンバを定義する。入力パラメータは、グループ識別及びそのグループを適切に定義するのに必要な任意の代数集合演算子を含む。
【００４３】
deleteGroup演算子は、データベース１４から任意のグループを削除する。入力パラメータは、このグループのグループ識別を指定する。
【００４４】
getGroupPermission演算子は、特定グループの許可を入手する。
【００４５】
setGroupPermission演算子により、特定グループに関する許可が設定できる。
【００４６】
又、このプロトコルは、ユーザプロファイル内のデータベーススキーマ管理用の演算子も含む。上述のように、サービスプロバイダ及び他のクライアントは、ユーザプロファイル内に格納されているデータのスキーマを定義できる。これらの演算には次のものが含まれる。
addField
deleteField
setSchemaPermission
【００４７】
addField演算子により、新たなフィールドがスキーマに追加できる。入力パラメータは、追加する新たなフィールドを識別する。
【００４８】
deleteField演算子は、フィールド識別により識別されたフィールドを削除する。
【００４９】
アプリケーションプログラム・インタフェースを定義して、クライアントがＰＭＴプロトコルにより指定される演算を呼び出しできるようにしてもよい。
【００５０】
例示的な実施形態の１つの利点は、ユーザがユーザプロファイルを制御できることである。ユーザは、ユーザインターフェースロジック２８を用いてＰＭＴサーバ１０にアクセスできる。図７は、ユーザプロファイルを生成するために実行される諸ステップを示したフローチャートである。ユーザに関する情報を入手する（図７のステップ１７０を参照）。ユーザは、ユーザプロファイルに組み込まれる情報を入力せよという指示メッセージを、ユーザインターフェースロジック２８を介して受けることができる。或いは、ユ―ザプロファイルを作成するため、データ共有機構２２が情報を入手してもよく、或いはこの情報は他のソースから入手してもよい。次に、この情報は、関連付けられた許可と共にユーザプロファイルに格納される（図７のステップ１３２を参照）。ユーザが、許可を明示的に設定できるようにしてもよいし、或いは、デフォルト許可１８を適用してもよい。
【００５１】
例示的な実施形態は、許可を適切に設定することで、匿名トランザクションの実行を容易にする。図８は、こうした匿名トランザクションを容易に実行するための諸ステップを示したフローチャートである。まず、少なくとも１つのデータ単位は、アクセスを阻止するために設定した許可を含むことができる（図８のステップ１８０）。このデータ単位は、例えば、フィールドである。多数のこうした単位は、選択したクライアントにこうした単位へのアクセスを拒否することで遮断できる。ユーザプロファイル内の少なくとも１つのデータ単位は、許可によって、少なくとも１つのクライアントがこのフィールドへのアクセスを許可されるように構成される（図８のステップ１８２）。次に、このトランザクションを実行できる。このトランザクションは、例えば、ユーザ名又は他の識別情報へのアクセスを阻止することにより匿名で実行できる。例えば、ユーザのクレジットカード番号又はアドレス又は電話番号へのアクセスを阻止できる。同様に、場合によっては、クレジットカード又は銀行口座番号のような支払い機構のみへのアクセスを許可してもよい。
【００５２】
潜在的用途の一つとしては、医療記録の分野がある。名前が容易に特定できない患者識別によって、患者を識別可能としてよい。ユーザプロファイル内の患者の身元が明かされるようなフィールドへのアクセスは阻止される。次に、診療記録は、患者識別を刻印してネットワークを介して安全に送信できる。
【００５３】
本発明を例示的な実施形態を参照して説明してきたが、当業者であれば、形式及び細部は、添付の特許請求の範囲に画定した本発明の意図した範囲から逸脱することなく様々に変更できることは理解するはずである。
【図面の簡単な説明】
【００５４】
本発明の例示的な実施形態は、次の図面に関連して下記に説明する。
【図１】本発明の例示的な実施形態で使用する幾つかの構成要素を示す。
【図２】例示的な実施形態を実施するための代表的な環境を示す。
【図３】ＰＭＴプロトコルに参加可能な、様々な種類のクライアントを示す。
【図４】ユ―ザプロファイルに格納されたデータの一例を示す。
【図５】例示的な実施例において、許可を設定する際の様々な細分性を示す。
【図６】サービスプロバイダ階層の一例を示す。
【図７】ユーザプロファイルを生成するために実行される諸ステップを示したフローチャートである。
【図８】匿名トランザクションをサポートするために実行される諸ステップの一例を示したフローチャートである。
【図１】
2004530195.tif 000003
【図２】
2004530195.tif 000004
【図３】
2004530195.tif 000005
【図４】
2004530195.tif 000006
【図５】
2004530195.tif 000007
【図６】
2004530195.tif 000008
【図７】
2004530195.tif 000009
【図８】
2004530195.tif 000010
【国際公開パンフレット】
2004530195.tif 000011
2004530195.tif 000012
2004530195.tif 000013
2004530195.tif 000014
2004530195.tif 000015
2004530195.tif 000016
2004530195.tif 000017
2004530195.tif 000018
2004530195.tif 000019
2004530195.tif 000020
2004530195.tif 000021
2004530195.tif 000022
2004530195.tif 000023
2004530195.tif 000024
2004530195.tif 000025
2004530195.tif 000026
2004530195.tif 000027
2004530195.tif 000028
2004530195.tif 000029
2004530195.tif 000030
2004530195.tif 000031
2004530195.tif 000032
【国際公開パンフレット（コレクトバージョン）】
2004530195.tif 000033
【国際調査報告】
2004530195.tif 000034