アイデンティティサービスに対するアクセス権を提供する方法及び装置
ユーザのアイデンティティサービスに対するアクセス権を提供する方法、装置及びコンピュータプログラム。ディスカバリサービスＤＳサーバ（１００）は、ユーザが利用可能であるアイデンティティサービス（ＩＤＳＲＶ‐Ａ、ＩＤＳＲＶ‐Ｂ）の参照情報（ＲＯ１Ａ、ＲＯｎＢ）をユーザの集合に対して格納する。それら参照情報は、前記アイデンティティサービスを提供するサービスプロバイダＳＰ（１２０、１３０）と接続するのに使用可能である。特定のユーザに対してまだ登録されていない特定のアイデンティティサービスの場合、ＤＳサーバは、そのサービスを提供できるＳＰ（１４０）を選択し、前記アイデンティティサービスの登録に対応する新しいリソースオファリング（ＲＯ２Ｘ）を格納する。適切なＳＰを選択するために、ＤＳサーバは、特定のＳＰにより提供されるアイデンティティサービスに関する情報及びＳＰがサポートするアイデンティティサービスを使用してＳＰから動的に更新される内容に関する情報を含むサービス機能記憶領域（１０３‐２、３０１）をチェックできる。ＤＳサーバはユーザと接続し、ＳＰ基本設定とサービスデータの収集との少なくともいずれかを実行することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アイデンティティ連携フレームワークにおいてサービスを提供することに関し、特に、ユーザのアイデンティティサービスに対するアクセス権を提供する方法及びそれに関連する装置に関する。
【背景技術】
【０００２】
インターネットを介して提供される第１の種類のサービスは、通常、１対１（消費者対企業、ユーザ対プロバイダ）の関係に限定される。この種類のサービスの主な例において、サービスプロバイダ（以下、ＳＰと呼ぶ）は、１つ以上のサービスを複数のユーザに提供できる。これらのサービスのうちのあるものは、（例えば）共通に提供され、例えば、任意のユーザが利用可能な情報サービスか、あるいは、ユーザ毎にカスタマイズや許可を受ける必要のない情報サービスかの少なくともいずれかにすぎない。他のサービスは、供給されるユーザに応じてカスタマイズでき、例えば、ユーザの識別及び許可が事前に行なわれる。このことは、例えば、サービス又はその内容が供給される特定の各ユーザに応じて、若しくはそのユーザの基本設定に応じて適応される場合、或いは、ＳＰに対するサービスアカウントを有するユーザ（例えば、ＳＰのサービスに加入しているユーザ）に対してのみサービスが与えられる場合の、少なくともいずれかの場合に必要となる。
【０００３】
サービスの提供がユーザの識別を必要とする特別な場合、ＳＰはユーザ認証を実行する機構を実現し、通常、各ＳＰにおいてユーザの証明書(credential)（例えば、ユーザの識別子及びパスワード）を格納及び管理する。しかし、この簡単化された方法において、種々のＳＰに対して種々のサービスアカウントを有するユーザの場合、ユーザはそれらＳＰにより提供される異なるサービスにアクセスするための証明書を覚えておく必要があるため、ユーザ側で不便が生じる。ユーザは、全てのＳＰにおいて同一の証明書を利用することによりその欠点をなくそうとするだろうが、不可能である場合がある（例えば、ＳＰがユーザ識別子を強制的に与える場合、あるいは、同一ＳＰにおいて、選択された同一のユーザ識別子が既に他のユーザに割り当てられている場合）。しかし、いずれの場合においても、ユーザは、ＳＰにアクセスする度に証明書を提供する必要がある。
【０００４】
近年、アイデンティティ連携フレームワークが、主にその問題を解決するために開発された。簡単に説明すると、アイデンティティ連携フレームワークは、機能エンティティの集合（後述するＳＰ及びその他）と、複数のＳＰがユーザの連携アイデンティティ情報をそれらＳＰ間で共有することを可能にする機構の集合とを含む。この説明において、ユーザの「アイデンティティ」（「ネットワーク・アイデンティティ」としても知られる）とは、前記ユーザが種々のＳＰにわたり有する各サービスアカウント中に、前記ユーザに対して保持される属性の集合を示す。
【０００５】
「リバティ・アライアンス・プロジェクト（Liberty Alliance Project）」ＬＡＰ（http://www.projectliberty.org/）は、アイデンティティ連携フレームワークの標準化に係る標準化フォーラムである。従って、本出願において、ＬＡＰのいくつかの特定の用語である機能手順及び機能エンティティは、例として、周知の標準化されたアイデンティティ連携フレームワークの機能動作を示すために使用される。当業者は、それらの用語をアイデンティティ連携を提供する同様のフレームワークの同義語である機能手順及び機能エンティティと容易に関連付けられるだろう。
【０００６】
アイデンティティ連携フレームワークの第１の目標は、所謂ＳＳＯ（「シングルサインオン」、また「シンプリファイド・サインオン」としても知られる）を提供することであった。ＳＳＯにより、ユーザは、異なるサービス及びアプリケーションに安全にアクセスできる。それら異なるサービス及びアプリケーションは、異なるネットワーク又は管理ドメインに分散している可能性のある複数のＳＰを介して、毎回認証されることなくアクセスされる。ＳＳＯの背景にある現在の原理は、ユーザが特定のセッションに対して１度認証すると、そのようなレベルの認証を受け付けるユーザが加入している全てのサービスに対するアクセス権が与えられることを提示する。この原理により、ユーザは、ユーザが要求する特定の異なる各サービスに対する認証を明示的に行なわずに、それら異なるサービスにアクセスできる。ＳＳＯは、１度ユーザを認証し、その後、一般に「アイデンティティ・プロバイダ」ＩＤＰとして知られるサーバエンティティの仲介によって、結果として得られた認証を他のＳＰへの入口に対して有効にすることにより実現される。
【０００７】
アイデンティティ連携フレームワークの別の目標は、ユーザの連携アイデンティティに基づいて新しい種類のサービスを提供することである。簡単に説明すると、それら新しい種類のサービスは、複数のＳＰにわたるユーザの連携アイデンティティのリソースの消費を考慮する。用語「リソース」は、包括的な用語であり、より静的な性質を有するデータ属性（ユーザの名前、従業員番号、特定のサービス又はネットワークにおけるユーザ識別子等）、及び、より動的な性質を有するデータ属性（例えば、カレンダデータ、現在の地理的な位置等の前記ユーザに対するサービスに依存するデータ属性）等のユーザの連携アイデンティティのデータ属性を示してもよい。または、ユーザの連携アイデンティティの代わりの役割を果たすサービス（例えば、ショートメッセージの送信、電子メールの送信等、ユーザのアイデンティティに対してある動作を実行するサービス）を示してもよい。この場合、特定のＳＰは特定のサービスをユーザに提供できるが、ユーザは、そのサービスを完了するために、前記ユーザの連携アイデンティティのリソースの消費（例えば、ユーザのクレジットカード番号の使用、ユーザのウェブを使用したカレンダのデータのチェック、又は、そのカレンダに対するデータの設定、個人情報の使用等）を必要とするだろう（例えば、オプションの機能又は必須の機能として）。ここで、前記リソースは、格納され且つ別のＳＰにおいて主に処理される。前記「消費」は、前記リソースの検索と更新との少なくともいずれかだけでなく、アイデンティティを生かした動作の実行（例えば、ＳＰにおけるユーザのアイデンティティの属性はユーザの移動電話番号を含み、そのＳＰからその電話番号へショートメッセージを送信する動作）も含む。従って、新しい種類のサービスは、それらサービスの達成／カスタマイズ等のためにユーザに対してローカルに保持するデータを単に使用する以上のことを行なえるＳＰから前記ユーザに提供される。
【０００８】
この新しい種類のサービスの提供は、一般に、サーバエンティティの介入により達成される。サーバエンティティは、第１のＳＰが所望のリソースを保持する第２のＳＰにアクセスするのを可能にする「ディスカバリサービス(Discovery Service)」ＤＳとして一般に知られるサービスを提供する。本出願において、用語「ディスカバリサービスサーバ」（又はＤＳサーバ）は、任意の他の種類のサービスを提供する、又は、提供しないサーバマシンにサーバエンティティが常駐するか否かに関わらず、ディスカバリサービスＤＳを提供するサービスエンティティを示すために使用される。
【０００９】
アイデンティティ連携フレームワークにおいて一般に使用される専門用語において、上述の第２のＳＰはＷＳＰ（ウェブサービス・プロバイダ）として動作し、上述の第１のＳＰはＷＳＣ（ウェブサービス・コンシューマ）として動作するだろう。アイデンティティに関する情報の検索又は更新のために、あるいは前記アイデンティティのためのある動作を実行するために、ＷＳＣがＷＳＰにアクセスし且つリソースに従って動作することを可能にするサービスは、「アイデンティティサービス」として知られる。この専門用語の説明において、ＤＳサーバは、複数のＷＳＣがユーザの登録アイデンティティサービスを動的に発見することを可能にする「ディスカバリサービス」ＤＳを提供するように、対応するＷＳＰにアクセスするのに使用可能な情報をそれらＷＳＣに提供する。
【００１０】
ＤＳサーバは、ユーザのアイデンティティサービスに関する情報を格納するレジスタとして動作するとともに、要求があったときに前記情報を提供する機能エンティティである。特定のユーザの各登録アイデンティティサービスに対するＤＳサーバを格納する情報は、一般に「リソースオファリング」ＲＯとして知られる。その情報の内容は、ユーザの特定のアイデンティティサービス・インスタンスを一意に識別するのに使用できる。例えば、ユーザの約束及びタスクを格納するユーザの「カレンダ」サービスに対するアクセス権を提供するために、ＤＳサーバはＲＯを格納する。ＲＯは、種々のサービスを区別するためのサービスの種類の識別子（Service Type）、前記ユーザと関連のある前記サービスの種類のサービスインスタンスを一意に識別する識別子（例えば、他のユーザの「カレンダ」と区別するために）（Resource ID）、及び、前記ユーザに対する前記サービスを提供するＳＰを識別する識別子（Provider ID）を特に含む。それら全ての識別子は、統一資源識別子ＵＲＩ（Uniform Resource Identifiers）の形式であってもよい。しかし、特定のユーザの特定のアイデンティティサービスを識別し、且つ、アクセスするために、対応するＳＰと接続するのに使用可能な参照情報を提供する形式であれば、他の表現形式（例えば、単一のＵＲＩ）でもよい。
【００１１】
ディスカバリサービスＤＳを提供するために、最新のＤＳサーバは、以下の２種類の要求を受信し、それに返答するように構成される。第１の種類の要求は、「リソースオファリング」ＲＯの変更（新しいＲＯの挿入、又は、格納されたＲＯの除去）を要求し、以下において「ディスカバリサービス更新」ＤＳ更新と呼ばれる。第２の種類の要求は、格納されたＲＯの取得を要求し、対応するＲＯを含む「ディスカバリサービス応答」ＤＳ応答でＤＳサーバにより返答される。この第２の種類の要求は、以下において「ディスカバリサービスクエリ」ＤＳクエリと呼ばれる。
【００１２】
「ディスカバリサービス」ＤＳは、ＤＳ自体の特性により、「リソース」の特別な集合（すなわち、リソースオファリング、ＲＯ）の消費を（発見するという形態で）提供するアイデンティティサービスである。アイデンティティウェブサービスフレームワークにおけるディスカバリサービスを説明する仕様書は、「Liberty ID-WSF Discovery Service Specification」version 1.1（https://www.projectliberty.org/specs/liberty-idwsf-disco-svc-v1.1.pdfにおいて入手可能である）としてＬＡＰにより公開されている。
【００１３】
図１及び図２を参照して、この種類の新しいサービスの簡単な例を提供し、アイデンティティ連携フレームワークにおけるエンティティ間の機能関係に関して簡単に説明する。
【００１４】
図１において、複数のＳＰ（１１０、１２０、１３０、１４０）、ＩＤＰ（９０）、ＤＳサーバ（１００）及びユーザ端末（１５０‐１）と対話するユーザ（１５０‐２）が概略的に示される。尚、ＬＡＰの特定の専門用語において、包括的な用語「主体者」は、連携アイデンティティを取得できるエンティティを示すために使用される。用語「主体者」の範囲には、人間ユーザ、人間ユーザのグループ、企業、正当なエンティティ又は機能を供給するエンティティが含まれる。それら全ての種類の「主体者」は、実際にはアイデンティティ連携の「ユーザ」であり（又はユーザとなり）、用語「ユーザ」（１５０）は、本出願の以下において、ユーザの種類に関係なく、アイデンティティ連携のユーザを示すために使用される。図１のＳＰ（１１０、１２０、１３０、１４０）は、１つ以上のサービスプロバイダ機関のドメインに属することができる１つ以上のサーバエンティティの各々を表す。ここで、各サーバエンティティは、コンピュータを使用するマシン等の同一のサーバマシン内に共に配置されてもよく、あるいは種々のマシンにわたり分散されてもよい。同様に、ＩＤＰ又はＤＳサーバに対して開示される対応する機能性は、２つ以上のマシンにわたり分散されるか（例えば、各マシンが全体の機能性のサブ機能を実行する）、あるいは同一マシン内に共に配置される。しかし、簡単のために、示されるサーバエンティティ（９０、１００、１１０、１２０、１３０、１４０）の各々は、各々が対応する開示された機能性を実現する単一マシンを表すものと仮定される。しかし、実用上の実現例において、ＩＤＰの機能及びディスカバリサービスの機能は、同一のサーバマシン内に共に配置されて使用される。
【００１５】
簡単のために、１つのＤＳサーバが図１に表される。しかし、２つ以上のＤＳサーバが、アイデンティティ連携フレームワークを提供する通信システム内に存在してもよい。ここで、例えば各ＤＳサーバは、ディスカバリサービスを前記連携のユーザの集合に供給するために割り当てられる。
【００１６】
ユーザ（１５０）は、２つ以上のＳＰ（１１０、１２０、１３０）と通信し、上述のように、ＳＳＯ機能を使用してユーザ認証が行なわれる種々のサービスに対するアクセス権を獲得できる。また、ＳＰ及びＩＤＰは、ユーザを認証するため及び特に認証アサーションを配信するために通信できる（１０）。例えば、ユーザ（１５０）は、ＳＰ１１０との第１の通信を確立し、そのＳＰにおいて認証される。ＩＤＰ（９０）はこの認証に関与し、ユーザが例えばＳＰ１２０との別の通信を確立する時、ＩＤＰはＳＰ１２０に認証アサーションを提供する。ユーザが証明書を再び提供する必要なく、ＳＰ１２０は、そのＳＰにおける対応するサービスに対するアクセス権を付与する。
【００１７】
ＩＤＰは、ユーザのＳＳＯ認証処理中にＩＤＰとＳＰとの間で交換されるデータの一部として、ＤＳサーバ（１００）と接続するのに使用可能な参照情報をユーザ（１１０、１２０、１３０）が接続する任意のＳＰに更に提供し、それにより前記ＤＳサーバから前記ユーザのＲＯを（必要に応じて）取得できる。ＤＳと接続するのに使用可能な前記参照情報は、上述のようにＤＳサーバにより提供されるアイデンティティサービス（すなわち「ディスカバリサービス」ＤＳ）にアクセスするために使用されるため、「リソースオファリング」であると考えられる（以下、ＲＯ‐ＤＳと呼ぶ）。更なる通信（１２）は、ユーザ（１５０）のアイデンティティサービスにアクセスするためにＳＰ間で確立される。
【００１８】
図２に示す信号フローを使用して、ユーザの特定のアイデンティティサービスに対するＲＯをどのようにＤＳサーバに格納するか、及び、そのＲＯにどのようにして更にアクセスするかを説明する。第１のステップ（フロー２０１）において、ユーザ（１５０）は、特定のＳＰ（１３０）にアクセスし、そのＳＰにより供給される特定のサービスに加入することを決定する。例えば、ＳＰ１３０（例えば、取引銀行）は、ウェブを介して安全な支払いサービスを提供する。あるいは、例えばＳＰ１３０は、パーソナルコンピュータ又は移動電話からウェブブラウザアプリケーションを介してユーザによりチェックされ且つ他のサービスを（又は他のサービスの結果）提供するためにチェックされる（又は更新される）カレンダサービスを提供する。特定のサービスへの加入を要求するためのユーザのＳＰへのアクセスは、ユーザに周知の登録ＵＲＬ（ユニフォームリソースロケータ）又はウェブページ上でＳＰにより指示される登録ＵＲＬにＨＴＴＰメッセージ（通常、ＨＴＴＰ「Get」）を送信することにより開始してもよい。図示される次のステップ（フロー２０２）において、ＳＰ１３０は、前記ＳＰ１３０における前記ユーザの前記アイデンティティサービスにアクセスするための対応するＲＯを含むＤＳサーバ１００に、「ディスカバリサービス更新」ＤＳ更新を送信する。前記ＲＯを使用することにより、別のＳＰ（１１０）は、例えば、前記ユーザにより入手される商品に対する支払いアサーションを取得でき、あるいはユーザのカレンダデータをチェック又は更新できる。
【００１９】
受信したＤＳ更新の結果、ＤＳサーバは受信ＲＯを格納する（２０３）。図１に概略的に示すように、ＤＳサーバはデータ記憶領域（１０３‐１）を有し、ディスカバリサービスを供給するユーザ（ＵＳＲ‐１，ＵＳＲ‐２，．．．，ＵＳＲ‐ｎ）毎に、又は、前記ユーザの各々に対して登録されたアイデンティティサービス毎に、複数のＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）を格納する。
【００２０】
その後、ユーザ１５０はＳＰ１１０にアクセスする（フロー２０４）。ＳＰ１１０は、例えば、ウェブを介して支払いを受け付けるフライト予約サービスを供給し、追加機能として、ユーザのカレンダのチェック及び更新（例えば、飛行時間を「利用不可能」としてマークするユーザの利用可能性の確認、チケットを入手するためのタスクの設定等）との少なくともいずれかを更に提供する。ユーザ（１５０）がＩＤＰ（９０）の介入により先に認証されていると仮定すると（信号フローは図２には示さない）、ＳＰ１１０は、ＤＳと接続するのに使用可能な参照情報（上述のように、ＲＯ、ＲＯ‐ＤＳ）をＩＤＰから取得する。例えば、ユーザのカレンダをチェック又は更新するために、あるいは予約したフライトに対する支払いアサーションを取得するために、ＳＰ１１０は、「ディスカバリサービスクエリ」ＤＳクエリをＤＳサーバ（１００）に送信する（フロー２０５）。ＤＳクエリ（２０５）は、ＤＳサーバにアクセスするために取得されたＲＯ（ＲＯ‐ＤＳ）のリソース識別子（Resource ID）を含む。このリソース識別子により、ＤＳサーバは、関連する特定のユーザ（１５０）を識別できる。また、ＤＳクエリ（２０５）は、要求したアイデンティティサービスの識別子（例えば、「カレンダ」サービスを識別するために設定されたService Type識別子）を更に含むことができる。
【００２１】
受信したＤＳクエリが特定のアイデンティティサービスの識別子（Service Type）を含む場合、ＤＳサーバ（１００）は、前記サービス及び前記ユーザに対して登録されたＲＯが存在するかをチェックする。ＤＳクエリがアイデンティティサービスの種類の識別子なしで受信される場合、ＤＳサーバは、参照されたユーザに対して格納された全てのＲＯを含む「ディスカバリサービス応答」ＤＳ応答（フロー２０６）を返す。例えば（図１の記憶領域１０３‐１の内容を参照して）、ＤＳサーバは、ＵＳＲ‐１の場合はＲＯ１Ａ及びＲＯ１Ｂ、又はＵＳＲ‐２の場合はＲＯ２Ａを含むＤＳ応答を返す。あるいは、受信したＤＳクエリが特定のアイデンティティサービスの識別子を含む場合、ＤＳサーバは、指示されたアイデンティティサービス（例えば、ＲＯ１Ｂ）に対応するＲＯのみを返す。ＤＳ応答（フロー２０６）を取得すると、ＳＰ１１０は、アイデンティティサービスにより考慮されるリソースを提供するＳＰ（１３０）と通信することにより（フロー２０７、２０８）、取得したＲＯのデータを使用してアイデンティティサービスを呼び出せる（それにより、例えば、ユーザカレンダにアクセスし又はそれを更新したり、支払いアサーション、ユーザプロファイルデータ等を取得する）。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
しかし、ＤＳクエリにおいて指示されるアイデンティティサービスが前記ユーザの未登録アイデンティティサービスである場合（すなわち、そのアイデンティティサービスに対するＲＯがＤＳサーバ１００に格納されていない場合）、あるいはＤＳサーバにおいて前記ユーザに対して登録されたアイデンティティサービスが全く存在しない場合、後続するＤＳ応答（２０６）は空で送信される。ＳＰ１１０がユーザ１５０に提供する予定であるサービスの特性によっては、その事象は、前記サービスが最終的に拒否される原因となる可能性があり、あるいは、最小限の影響として、提供された最終的なサービスの品質の低下の原因となる可能性がある。例えば、これは、アイデンティティサービスが登録されていた場合にそのアイデンティティサービスを介して自動的に取得されたであろう必要なデータの一部を、ＳＰ１１０に対してユーザが手動で提示することを要求する。
【００２３】
ユーザは、そのアイデンティティサービスを提供できるＳＰと接続することにより上述の問題を克服し、この時点まで未登録であるアイデンティティサービスをユーザ自身に対して登録できる。しかし、ユーザは、前記アイデンティティサービスを提供できるＳＰを最終的に見つけ出すまでに、いくつかのＳＰと接続しなければならない可能性がある。ＳＰを見つけると、ユーザはそのサービスに加入できる。従って、上述のフロー２０１及び２０２が実行され、前記ユーザに対して前記アイデンティティサービスをＤＳサーバに登録する。その後、例えば、ユーザが放置されたサービスに対するアクセス権をまだ獲得したい場合、ユーザは再び処理を開始し、前記アイデンティティサービスを発見できなかったＳＰ（１１０）と再び接続できる。
【００２４】
しかし、その方法により、ユーザが後で必要とする可能性のあるユーザの未登録アイデンティティサービスとして残っている他のアイデンティティサービスに対して、上述の状況と同一の状況が繰り返されることを防止することはできない。更に、新しいサービスは、ＳＰにより迅速に開発及び実現され、それは、新しいアイデンティティサービスの提供及び要求を最終的に含む。しかし、アイデンティティサービスの登録に対する最新の機構（フロー２０１及び２０２を参照して説明した）は、前記新しいサービスの迅速な展開を妨げる。これは、ユーザの所望のアイデンティティサービスをＤＳサーバに登録する（２０２）前記ＳＰを実現するように、ユーザが継続して適切なＳＰを見つけ、かつ、それらＳＰに接続する（２０１）必要があるからである。
【課題を解決するための手段】
【００２５】
本発明は、ユーザの未登録アイデンティティサービスに対する登録処理をディスカバリサービスサーバからトリガすることにより上記問題を解決する。これは、請求項１記載の方法、請求項１６記載のディスカバリサービスサーバ、又は、請求項３３記載のコンピュータプログラムにより達成される。本発明の実施形態については、添付の請求の範囲で説明する。
【００２６】
ユーザのアイデンティティサービスを登録し、前記登録したアイデンティティサービスに対するアクセス権を提供するために、ディスカバリサービスを提供する周知の機能に加え、本発明による方法、ディスカバリサービスサーバ及びコンピュータプログラムは、それぞれ、ユーザに対してまだ登録されていないアイデンティティサービスを提供するサービスプロバイダをディスカバリサービスサーバから選択するステップ、手段、及び、コンピュータ可読プログラムコードと、前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するためにリソースオファリングを前記ディスカバリサービスサーバに格納するステップ、手段、及び、コンピュータ可読プログラムコードとを含む。
【００２７】
ユーザの未登録アイデンティティサービスを登録する登録処理をディスカバリサービスサーバからトリガすることにより、前記ユーザは、利益を得るアイデンティティサービスの正確な知識を有する必要もなく前記アイデンティティサービスを提供するサービスプロバイダを自身で見つける必要性もない。ディスカバリサービスサーバが特定のユーザに対して登録されたアイデンティティサービスを認識しているため、ディスカバリサービスサーバは、前記ユーザに対してまだ登録されていないアイデンティティサービスの登録を開始し、それにより、前記サービスが最初に要求される前、又は、要求された時に前記アイデンティティサービスへのアクセスが可能になる。更に、ディスカバリサービスサーバにおけるユーザの登録アイデンティティサービスに関する知識により、サービスプロバイダに関するユーザの基本設定と、サービスプロバイダのサービス機能との少なくともいずれかに基づいてサービスプロバイダを選択することが可能になる。その基本設定とサービス機能との少なくともいずれかは、ディスカバリサービスサーバにおいて、先に登録されたアイデンティティサービスのリソースオファリングの内容から取得される。
【００２８】
本発明は、サービスプロバイダの選択と、ユーザの未登録アイデンティティサービスを登録するための対応するリソースオファリングの作成とを行なうディスカバリサービスサーバにおいて、有利に実現される種々の実施形態を提供する。しかし、最低限の実現例において、ディスカバリサービスサーバは、適切な候補サービスプロバイダを直接選択し、関連データを使用して対応するリソースオファリングを形成する。
【００２９】
一実施形態によると、ディスカバリサービスサーバは、サービス機能記憶領域をチェックし、前記アイデンティティサービスを提供できるサービスプロバイダを選択できる。サービス機能記憶領域は、特に、１つ以上のアイデンティティサービスの識別子と１つ以上のサービスプロバイダの識別子とを関連付けて有することができる。それにより、特定のサービスプロバイダにより提供されるアイデンティティサービスと、特定のアイデンティティサービスを提供できるサービスプロバイダとの少なくともいずれかをチェックできる。従って、特定のアイデンティティを提供するサービスプロバイダを選択することが可能になる。
【００３０】
別の実現例において、サービス機能記憶領域は、外部データベース等の外部エンティティに格納される。この場合、ディスカバリサービスサーバは、サービスプロバイダを選択するために、記憶領域をクエリして、サービスプロバイダ／アイデンティティサービスの関係に関する情報を取得する。あるいはそれに加えて、サービス機能記憶領域はディスカバリサービスサーバ内に格納され、それにより、内部チェック処理が可能になり、外部エンティティにクエリを送信することを回避する。
【００３１】
サービス機能記憶領域は、ディスカバリサービスサーバに格納されるか、或いは、外部エンティティに格納されるかに関わらず、サービスプロバイダがそれぞれ提供できるアイデンティティサービスに関する情報を含むサービスプロバイダから受信される機能登録を使用して動的に更新されるのが好ましい。しかし、サービス機能記憶領域は、情報を要求及び更新するために複数の周知のサービスプロバイダをクエリすることにより周期的に更新されてもよい。単純なアクセスポリシーは、機能登録を送信することを許可されたサービスプロバイダ、又は、同一の目的でディスカバリサービスサーバからクエリされることを許可されたサービスプロバイダを判定するために確立される。それにより、ユーザに対するアイデンティティサービスを提供するアイデンティティサービスプロバイダをディスカバリサービスサーバにおいて選択する時、要求に応じて、いくつかの信用サービスプロバイダのみを選択可能な候補とすることができる。
【００３２】
本発明は、異なる状況において、特定のアイデンティティサービスが１つ以上のユーザの未登録アイデンティティサービスであるかを評価するための種々の実施形態、又は特定のユーザがまだ登録されていないアイデンティティサービスを１つ以上有するかを評価するための種々の実施形態を提供する。それらの実施形態において、提供されるアイデンティティサービスは、ユーザの登録アイデンティティサービスに対してディスカバリサービスサーバに格納されたリソースオファリングの内容と比較してチェックされる。
【００３３】
一実施形態において、上記チェックは、対応するアイデンティティサービスにアクセスするために、ユーザの１つ以上のリソースオファリングを要求するディスカバリサービスクエリを前記ディスカバリサービスサーバにおいて受信した際に実行される。別の実施形態において、ディスカバリサービスサーバは、サービスプロバイダから機能登録を受信した際に前記チェックを行なうことができる。更に別の実施形態において、１つ以上のユーザに対する未登録アイデンティティサービスを見つけるためのチェックは、上記サービス機能記憶領域の周期的なチェックの際に実行される。更に別の実施形態において、ユーザの未登録アイデンティティサービスを判定するためのチェックは、前記ユーザからの通信をディスカバリサービスサーバにおいて受信した際に行なわれる。
【００３４】
別の実施形態によると、ディスカバリサービスサーバは、特定のユーザに対する未登録アイデンティティサービスを検出した際に、前記ユーザとの通信の確立を要求する。
【００３５】
更に別の実施形態によると、ユーザはディスカバリサービスサーバと通信できる。それにより、ディスカバリサービスサーバは、ユーザからサービスプロバイダ基本設定を収集することと、選択したサービスプロバイダからアイデンティティサービスを提供するのに使用可能なサービス関連データを収集することの少なくともいずれかが可能になる。前記通信は、上述のように、ディスカバリサービスサーバから先に行なわれた通信要求の結果であってもよく、あるいはユーザから受信した自発通信であってもよい。前記ユーザに対して未登録の特定のアイデンティティサービスの場合、ディスカバリサービスサーバは、ユーザにより指示されたサービスプロバイダ基本設定に従って前記アイデンティティサービスを提供するサービスプロバイダを選択でき、該当する場合は、そのサービスプロバイダに受信したサービス関連データの一部又は全てを転送できる。従って、当該サービスに対して、選択されたサービスプロバイダはそれらデータをユーザから後で収集する必要はない。
【００３６】
本発明の別の実施形態は、ディスカバリサービスサーバにおいて未登録アイデンティティサービスに対するリソースオファリングを提供するために、選択されたサービスプロバイダの介入が必要とされる状況に関する。特に、これは、ディスカバリサービスサーバが対応するリソースオファリングを形成するのに必要とされる全て又は任意のデータを有さず、それらデータの一部又は全てが生成され且つ選択されたサービスプロバイダから後で受信される場合でもよい。あるいは、選択されたサービスプロバイダがサービス関連データをユーザから収集すること又はサービス提供に対するユーザの同意を要求することと、アクセスポリシーを確立することとの少なくともいずれかを必要とする場合でもよい。これらの場合において、ディスカバリサービスサーバは、ユーザに対するアイデンティティサービスの提供の要求を選択されたサービスプロバイダに送信する。ここで、前記提供の要求は、オプションとして、前記ユーザに対する前記サービスの提供を、ユーザ独自のものにすることと、ユーザに適応させることとの少なくともいずれかのために、サービス関連データを更に含む。サービス関連データは、ディスカバリサービスサーバにより収集されてもよい。前記提供の要求の結果、選択されたサービスプロバイダは、対応するアイデンティティサービスをディスカバリサービスサーバに登録するためのリソースオファリングを含むディスカバリサービス更新を前記ディスカバリサービスサーバに送信できる。
【００３７】
一実施形態によると、ディスカバリサービスサーバは、選択されたサービスプロバイダに提供の要求を直接送信する。ユーザがディスカバリサービスサーバと通信状態にある時に適用可能である別の実施形態によると、ディスカバリサービスサーバは、選択されたサービスプロバイダに対する前記通信のリダイレクションの内部に埋め込まれた提供の要求を送信する。更に別の実施形態によると、ディスカバリサービスサーバがユーザのまだ登録されていないアイデンティティサービスにアクセスするために、前記ユーザのリソースオファリングを要求するディスカバリサービスクエリを受信した時、提供の要求は、前記ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答内で搬送される。
【発明を実施するための最良の形態】
【００３８】
次に、本発明のいくつかの好適な実施形態について、図３〜図９を参照して詳細に説明する。
【００３９】
図３は、相互接続ネットワーク（３００）を介して相互接続される複数のＳＰ（１１０、１２０、１３０、１４０）及びＤＳサーバ（１００）を示し、その結果、複数のサブネットワークを形成できる。相互接続ネットワークにより、ユーザ（１５０）は、１つ以上のＳＰ、並びにＤＳサーバ（１００）又はＩＤＰ（図３には示さない）と通信できる。図３に示すエンティティ間の通信（そのうちのいくつかは、図５のフローチャート及び図９の信号フローに表される）は、ウェブサービスを提供するために今日利用される周知のプロトコル（「ハイパーテキスト転送プロトコル」ＨＴＴＰ等）を使用することにより達成され、情報、要求及び応答を通信ネットワークを介して交換する時にエンベロープ及びデータ符号化として使用される別のプロトコル（「シンプル・オブジェクト・アクセス・プロトコル」ＳＯＡＰ等）を組み込むことができる。
【００４０】
ＤＳサーバ（１００）の一般的な内部構造を図３に示す。通信システムにより又は通信システムを介して提供されるサービスを供給する装置又はそれらサービス間を仲介する装置が、特定の構成の詳細に関わらず、１つ以上の機能モジュールで構成されることは周知である。各機能モジュールは、前記装置により実現される全体の機能の特定のサブ機能を実行するように構成され、最終的には前記装置における他の機能モジュールと協働するように構成される。特に、現代の通信システムにおけるサーバエンティティは、一般に、ソフトウェア及びハードウェアを含むコンピュータを使用する装置である。ここで、１つの前記装置における特定の機能モジュールは、ソフトウェア、ハードウェア又はそれらの組合せの一部を含むことができる。前記一部は、特定の（サブ）機能を実行し、更に継続する場合は、他の機能モジュールを実現するソフトウェア部分とハードウェア部分との少なくともいずれかと協働するように設計される。通信システムに対するサーバ装置の機能が規定されると、前記装置を実現するために機能モジュールを構成することは、当業者にとっての日常業務に該当する。従って、ＤＳサーバ（１００）の一般的な内部構造について、その構成に関する具体的な詳細には触れずに、基本的な機能モジュールを参照して説明する。
【００４１】
図３に示すＤＳサーバ（１００）の簡略化された内部構造は、処理モジュール（１０１）、通信モジュール（１０２）、データ記憶モジュール（１０３）及び１つ以上の内部通信バス（１０４）を含む。内部通信バス（１０４）は、それらモジュール間のデータ通信及び協働を可能にする。処理モジュール（１０１）は、例えば、負荷分割モード又はアクティブバックアップモードで動作する１つ以上のプロセッサ（１０１０）を含むことができる。処理モジュール（１０１）は、従来技術から周知であり、後述する機能性により拡張されるディスカバリサービスを提供するために、サービスロジックを実行して、ＤＳサーバ（１００）と他のエンティティ（１１０、１２０、１３０、１４０、１５０、３０１）との間で交換される信号を処理するとともに、ＤＳサーバにおける他の機能モジュール（１０２、１０３）を制御する。
【００４２】
外部通信は、１つ以上の通信装置（１０２１、１０２２）を含むことができる通信モジュール（１０２）を介して実行される。例えば、各々が特定の種類の通信（例えば、ＳＰのみとの通信、特定の種類の通信プロトコルに対してのみの通信等）を行なう１つ以上の通信装置（１０２１、１０２２）が存在する。また、１つ以上の通信装置（１０２１、１０２２）は、任意の種類の通信において使用されるのに適切であり、この場合の通信装置の数は、ＤＳサーバに対して推定される全体の外部信号と比較し、外部信号を処理する個々の容量によって異なる。
【００４３】
１つ以上のデータ記憶装置（１０３０）を含むことができるデータ記憶モジュール（１０３）は、動作するのに必要なデータを格納するためにＤＳサーバにおいて使用される。データ記憶装置（例えば、メモリチップ、磁気ディスク、光ディスク等）は、最新技術において周知であり、それにより、ＤＳサーバ（１００）のデータ記憶モジュール（１０３）は、同一の又は異なる種類の１つ以上の記憶装置を（例えば、要求されるデータアクセス速度、格納された特定のデータに対する所望の信頼性等の基準に基づいて）使用することが可能になる。２つのデータ記憶領域（１０３‐１、１０３‐２）は、図３において強調される。尚、それら２つの記憶領域は論理的に独立しているため、それら記憶領域が必ずしもそれぞれ個別の記憶装置に含まれる必要はない。例えば、データ記憶モジュール（１０３）のアドレス指定可能な総記憶領域は、周知のアドレシング技術を使用してデータ記憶の詳細を隠蔽することを可能にする２つ以上の記憶装置（１０３０）のアドレス指定可能な個別の記憶領域を含むことができる。ここで、異なる記憶領域（例えば、１０３‐１、１０３‐２）は、アドレス指定可能な異なる領域を割り当てることにより、規定されるとともに区別される。
【００４４】
第１のデータ記憶領域（１０３‐１）は、複数のリソースオファリングＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）を格納する。上述のように、ＲＯは、ユーザについて既に登録されているアイデンティティサービス毎にＤＳサーバに格納され、前記ユーザの前記アイデンティティサービスを提供するＳＰにアクセスして前記アイデンティティサービスを要求するのに使用できる。例えば、「ＲＯ２Ａ」で示されるＲＯは、アイデンティティサービス「Ａ」に対するユーザ「ＵＳＲ‐２」のＲＯを例示する。例示の目的で使用される表記以外に、ＲＯ「ＲＯ２Ａ」は、アイデンティティサービスの種類（「Ａ」）を他のアイデンティティサービスと区別するためのサービスの種類の識別子（上記ＬＡＰ ＤＳ仕様書においてService Typeと呼ばれる）と、前記ユーザに対するアイデンティティサービス「Ａ」を提供するＳＰを識別する識別子（上記ＬＡＰ ＤＳ仕様書においてProvider IDと呼ばれる）と、前記ＳＰにおける前記ユーザに対応するアイデンティティサービスのサービスインスタンスを区別するためのサービスインスタンス識別子（上記ＬＡＰ ＤＳ仕様書においてResource IDと呼ばれる）とを含んでもよい。
【００４５】
第２のデータ記憶領域（１０３‐２）は、本発明に従って提供され、複数のＳＰから提供されるアイデンティティサービスに関するサービス機能情報を格納する。この第２の記憶領域（１０３‐２）は、１つ以上のアイデンティティサービスの識別子（ＩＤＳＲＶ‐Ａ，ＩＤＳＲＶ‐Ｂ，．．．，ＩＤＳＲＶ‐Ｘ）とそれらアイデンティティサービスを提供する１つ以上のＳＰの識別子（ＳＰ‐１２０，ＳＰ‐１３０，．．．，ＳＰ‐１４０）とを関連付けて含むことができる。あるいは、サービス機能記憶領域は、上述の内容と本質的には同一の内容を有して外部データベース（３０１）上に保持されてもよい。サービス機能情報を内部又は外部に記憶するいずれの場合においても、アイデンティティサービスの識別子を使用するサービス機能記憶領域（１０３‐２、３０１）に対するチェックにより、前記サービスを提供できる１つ以上のＳＰに関する情報が提供され、ＳＰの識別子を使用するチェックにより、前記ＳＰが提供する１つ以上のアイデンティティサービスの識別子が提供される。
【００４６】
従って、サービス機能記憶領域（１０３‐２、３０１）をチェックすることにより、特定のＳＰにより提供されるアイデンティティサービスに関する情報又は特定のアイデンティティサービスを提供できるＳＰに関する情報が提供されることが可能である。
【００４７】
ＳＰが提供できるアイデンティティサービスに対して影響を与えるＳＰにおける変更が起こる可能性がある。最も一般的な例は、特定のＳＰが、以前は提供していなかった新しいアイデンティティサービスを提供するために、新しいサービスロジックが提供されることである。しかし、例えば、ＳＰが特定の日付から特定のアイデンティティサービスの提供を停止する場合、あるいは新しいＳＰがアイデンティティ連携フレームワークにおける残りのエンティティと協働するように設定されるとともに、１つ以上のアイデンティティサービスを提供できる場合もある。従って、サービス機能記憶領域（１０３‐２、３０１）は、ＳＰとＳＰが提供できるアイデンティティサービスとの関係に関する変更を動的に報告及び更新を行なう中心的な場所となる。前記動的な更新を実行する代わりに、ＳＰは、ＤＳサーバ（機能記憶領域１３０‐２が使用される場合）又は外部データベース（３０１）に「機能登録」メッセージを送信する。「機能登録」メッセージは、例えば、ＳＰが関連付けるＳＰの識別子と、１つ以上のアイデンティティサービスの識別子と、指示されたアイデンティティサービスに対しては提供又は停止するかを示すコードとを含むことができる。尚、簡単のために、１つのＤＳサーバのみが例において示される。しかし、２つ以上のサーバエンティティがアイデンティティ連携フレームワークにおいて存在してもよい（例えば、各サーバエンティティは、前記連携のユーザの集合にディスカバリサービスＤＳを提供する）。これらの例において、提供するアイデンティティサービスに関する変更が行なわれるＳＰは、２つ以上のＤＳサーバに機能更新を送信してもよい。
【００４８】
機能登録メッセージは、後で使用するためにサービス機能記憶領域（１０３‐２、３０１）にも格納される更なるデータ（図３において詳細は示さない）を含んでもよい。例えば、提供され得る所与のアイデンティティサービスについて、ＳＰは、データをリスト表示する形式や、サービスの提供に必要なデータ（例えば、言語基本設定、個人の住所、好適なメールアドレス等のサービス関連データ）の収集を、サービスを受けるユーザからＤＳサーバに委託するか否かを指示してもよい。機能登録メッセージは、アイデンティティサービスを登録するためのエントリポイントを含んでもよい。このとき、そのエントリポイントは、例えばユニフォーム・リソース・ロケータＵＲＬでもよく、そのＵＲＬは、ユーザ（１５０）がＳＰ（１３０）のサービスへの加入をローカルで要求した際（図２のフロー２０１で示される）に使用したＵＲＬと同一でも異なってもよい。更に、機能登録メッセージは、ＳＰから指示された登録基本設定を含むことができ、それは、アイデンティティサービスの登録を完了するために、例えば、前記ＳＰがＤＳサーバとの直接通信又は他の通信方法を受け入れる（又は、より好ましいと考える）かを指示してもよい。また、メッセージは、１つのユーザ又はユーザの集合に対してＲＯを形成するのに必要なデータの一部又は全てを含んでもよい。
【００４９】
あるいは、ＤＳサーバ（１００）は、周知の複数のＳＰを周期的にクエリして、機能登録メッセージに対して上記指示されたデータと同一の種類のデータをそれらＳＰから要求し、その後、サービス機能記憶領域（１０３‐２）の内容を更新する。
【００５０】
必ずしもＳＰとの通信（上記機能登録又は機能クエリ）を要求する必要がないＤＳサーバ（１００）においてサービス機能記憶領域（１０３‐２）を形成する簡単な実施形態は、ＤＳサーバに既に格納される複数のＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）に既に格納されるアイデンティティサービス及びＳＰに関するデータの収集を含んでもよい。すなわち、対応するアイデンティティサービスの識別子（例えば、Service Type）と共に各ＲＯに格納されるＳＰの識別子（例えば、Provider ID）を収集することは、ＤＳサーバ上に保持されるサービス機能記憶領域（１０３‐２）を形成することであると考えられ、あるいは、高い探索性能が要求される場合は、前記ＤＳサーバに論理的に分離されたデータベース（１０３‐２）を構築するのに使用される。従って、この簡単な実施形態において、ＤＳサーバに保持されるサービス機能記憶領域（１０３‐２）は、ＳＰから受信されるＤＳ更新メッセージで更新される（例えば、図２のフロー２０２で示される）。例えば、機能記憶領域１０３‐２は、ＤＳ更新２０２で指示されるアイデンティティサービスを提供する際にＳＰ１３０が現れなかった場合に更新される。
【００５１】
図４〜図７に示されるフローチャートは、本発明によるＤＳサーバ（１００）の動作方法（４０）を示すために使用される。この時、図４の簡略化されたフローチャートは基本的なステップ（４１、４２、４３）を示し、それらステップは図５、図６及び図７において更に詳細に示される。
【００５２】
ステップ４１において、ユーザの未登録アイデンティティサービスを判定するために、提供されるアイデンティティサービスはユーザ毎のＲＯの内容と比較してチェックされ、アイデンティティサービスはＤＳサーバに格納される。ステップ４２において、ＳＰが、未登録アイデンティティサービスを提供するために選択される。ここで、この包括的なステップは、上述のように、サービス機能記憶領域（１０３‐２、３０１）のチェック（４２‐Ｑ、４２‐Ｒ）を含んでもよい。最後に、ステップ４３において、この時点までにユーザに対して未登録のアイデンティティサービスは、そのサービスに対して対応するＲＯを格納することにより、ＤＳサーバ（１００）に登録される。これにより、前記ＤＳサーバから前記アイデンティティサービスへのアクセスが可能になる。
【００５３】
図５は、ユーザの未登録アイデンティティサービスの存在に関する初期評価をＤＳサーバ（１００）によって行ない、且つ必要に応じてサービスにアクセスできるように、サービスの登録を可能にする更なる動作を行なういくつかのステップを示す。図５のステップ４１１及び４１３を参照して説明されるように、この初期評価は、機能登録（ＣＡＰ‐ＵＰＤ）がＳＰから受信された時又はサービス機能記憶領域（１０３‐２、３０１）の周期的なチェックの際に行なわれる。別の方法も可能であり、それら別の方法において、いくつかのユーザのＲＯに対するチェックは、例えば、各ユーザ又はユーザのグループに関連付けられる特定のサービスの種類のパラメータ、あるいはアイデンティティサービス毎に関連付けられる同様のパラメータに依存して、その時点で実行されてもよく、又は、後で実行するように遅延されてもよく、あるいは実行されなくてもよい。例えば、特定のユーザは、ＤＳサーバにおいて登録処理のトリガが初期段階で（例えば、アイデンティティサービスがＤＳクエリで明示的に要求される前に）実行されるか、或いは後で実行されるかを提示する本発明によるアイデンティティサービスのアクセス権を自動的に提供するために、サービスの種類に関連付けられてもよい。同様に、ＤＳサーバへの登録のトリガは先の段階で実行されるのが好ましいか否かを提示する特定のアイデンティティサービスと関連するパラメータ（これは、機能登録の追加データとして受信され、サービス機能記憶領域に格納される）が存在してもよい。
【００５４】
従って、サービス機能更新の受信（４１１）後又はサービス機能記憶領域の周期的なチェック（４１３）後に実行される未登録アイデンティティサービスを判定するための評価は、１つ以上のアイデンティティサービス及び１つ以上のユーザに対して実行される。しかし、その評価は、いくつかの他のサービス又はユーザに対しては、後で（例えば、ＤＳクエリを受信した際、又はＤＳサーバにおいてユーザ通信を受信した際に）実行されてもよい。
【００５５】
ステップ４１１において、機能登録メッセージ（ＣＡＰ‐ＵＰＤ）は、ＤＳサーバ（１００）においてＳＰから受信される。次に、ステップ４１２において、サービス機能記憶領域（１０３‐２）の内容は、受信メッセージの内容で更新される。別の実現例は、ステップ４１４への遷移により示されるように、この時点で未登録のアイデンティティサービスに対するチェックを行なうことを含む。例えば、機能登録メッセージがＳＰ１４０から受信され、新しいアイデンティティサービス（例えば、ＩＤＳＲＶ‐Ｘ）を提供できることを報告すると仮定する。ステップ４１４は、そのアイデンティティサービスが１つ以上のユーザに対して既に登録されているか否かを判定するために、ＤＳにおいて前記１つ以上のユーザのＲＯをチェックすることを含む。これは、そのアイデンティティサービスのサービスの種類の識別子がＲＯに含まれるかを１つ以上のＲＯにおいてチェックすることにより達成されてもよい。同様に、機能登録メッセージ（４１１、ＣＡＰ‐ＵＰＤ）は、ＳＰ１３０から受信され、例えば、それまでにＳＰ１３０が提供していたアイデンティティサービス（例えば、ＩＤＳＲＶ‐Ａ）の停止を報告してもよい。この場合、ステップ４１４のチェックにより、影響を受けるＲＯ（例えば、ＲＯ２Ａ）が与えられ、それにより、ユーザに対して先に登録されているアイデンティティサービス（例えば、ＵＳＲ‐２に対するＩＤＳＲＶ‐Ａ）をこの時から未登録とすることができる。
【００５６】
あるいは又はそれに加えて（上述のように、特定の処理動作が行なわれるいくつかのユーザ又はアイデンティティサービスが存在する場合）、未登録アイデンティティサービスを判定するためのチェックは、ステップ４１３により示されるように、サービス機能記憶領域（１０３‐２、３０１）の周期的なチェックが実行されるまで遅延される。ユーザの未登録アイデンティティサービスを判定する目的で行なわれるサービス機能記憶領域の周期的なチェックは、トラフィック及びサービス需要が低いと考えられる特定の時間に後続の提供処理を実行させることができるため有利である。ステップ４１３の後続するチェックを実行する周期は、例えば、毎日特定の時間にチェックを実行するようにセットアップされてもよく、あるいは、例えば、ＤＳサーバで測定された最近の信号トラフィックに依存して動的にセットアップされてもよい。いずれの場合においても、サービス機能記憶領域（１０３‐２、３０１）の周期的なチェックにより、特定のＳＰが新しいサービスを提供することを報告する時期、又は、ＳＰが古いサービスの提供を停止することを報告する時期に依存しないＤＳサーバに未登録アイデンティティサービスを登録するための登録処理の非同期トリガが可能になる。更に、前記周期的なチェックにより、複数のユーザの未登録アイデンティティサービスに対するバッチ処理を容易にしてもよい。
【００５７】
あるユーザに対して登録されていないアイデンティティサービスを評価するためのチェックは、サブフロー「Ａ」、「Ｂ」及び「Ｃ」で示されるように更に遅延されてもよい。例えば、ＤＳサーバ（１００）は、ＤＳクエリの受信を待つか（ステップ４１８により示される）、あるいは当該ユーザからの通信を待つ（ステップ４１７により示される）ことができる。そのＤＳクエリ、又は、通信は、未登録アイデンティティサービスの登録を開始することに対するユーザの同意をＤＳサーバから取得するために使用されるか、あるいは前記登録を実行するのに使用されるユーザデータ及び基本設定を収集するために使用される。
【００５８】
ステップ４１４のチェックが実行され、アイデンティティサービス（例えば、ＩＤＳＲＶ‐Ｘ）が特定のユーザ（例えば、ＵＳＲ‐２）の未登録アイデンティティサービスとしてステップ４１５において見つけられると仮定すると、上記処理の代わりとなる次に説明する種々の処理が存在する。
【００５９】
ステップ４１６において、当該ユーザに対する通信を確立するための要求を送信させる処理が選択される。例えば、未登録アイデンティティサービスの登録を開始することに対するユーザの同意をＤＳサーバから取得するために、或いは、前記登録に対してユーザデータ基本設定、同意等を収集するために、サービス登録を開始する前にユーザと対話する目的で要求が送信される。前記要求は、異なるベアラを介して送信されてもよく、ＤＳサーバは、前記要求に対処するために、ユーザについて認識する識別子を使用でき、又は別のサーバエンティティから（例えば、ＩＤＰから）識別子を取得できる。例えば、要求は、ユーザの移動電話番号に送信されるショートメッセージ（ＳＭＳ）で搬送されるか、あるいはユーザのメールＵＲＬに送信される電子メールで搬送される。要求は、ＤＳサーバのサービスポイントにマップするＵＲＬを含んでもよく、あるいは（例えば、ユーザがＤＳサーバへのアクセス方法を知っている場合）ユーザがまだ加入していない新しいアイデンティティサービスが利用可能であることをユーザに警告するテキストを搬送してもよい。
【００６０】
あるいは、先に示したように、ＤＳサーバは、ＤＳクエリの受信を待つことができ（ステップ４１８）、あるいは当該ユーザからの通信を待つことができる（ステップ４１７）。ここで、ユーザからの前記通信は、ＤＳサーバから送信される先の通信要求の結果として受信されてもよく（ステップ４１６）、あるいはＤＳサーバにおいてユーザから受信される自発通信でもよい。後者の例は、例えば、ユーザがユーザの登録アイデンティティサービスに関連するアクセスポリシーをセットアップするためにＤＳサーバと通信する（例えば、ＤＳサーバが提供するウェブページを介して）際に起こる可能性がある。
【００６１】
図５のステップ４２及び４３（図４の簡略化されたフローにおいて示されるステップ４２及び４３に対応する）は、簡単な実施形態に従って、ステップ４１４及び４１５において検出される未登録アイデンティティサービスを提供するＳＰを選択すること及びユーザに対して登録するためにＤＳサーバ（１００）において対応するＲＯを提供することをそれぞれ表す。本実施形態は、ユーザの介入及び選択されたＳＰとの通信を要求しない。また、本実施形態は、前記ＳＰにより前記ユーザに対して提供される際に前記アイデンティティサービスに対するＲＯを直接形成するために、ＤＳサーバがユーザ及びＳＰデータに対するアクセス権を有してもよいという状況に適する。例えば、前記データの一部は、機能登録メッセージにおいてＳＰから受信され、他のデータは、同一のＳＰにおける同一のユーザに対する別のアイデンティティサービスの登録に関連付けられて再利用されてもよい。この場合（しかし、それに限定されない）、ステップ４２において、当該ユーザが既に周知である（例えば、ユーザがＳＰに対するサービスアカウントを既に有するか、あるいはＳＰが前記ユーザに対して別のアイデンティティサービスを既に供給している）ＳＰが選択されるのが好ましい。
【００６２】
更に別の処理方法（図５には示さない）は、ステップ４１４及び４１５の判定後に選択されてもよい。その方法は、ＤＳサーバと選択されたＳＰとの間の通信を含むが、ユーザの介入を要求せず、またＤＳサーバが未登録アイデンティティサービスに対応するＲＯを要求するＤＳクエリの受信を待つ必要がない。この方法を達成する処理ステップについては、図６に示すステップを参照して後述する。
【００６３】
図６に示されるフローは、ユーザからの通信が受信された時にＤＳサーバ（１００）により実行されるいくつかの処理ステップを示す。先のサブフロー「Ａ」及び「Ｂ」により示されるように、ユーザからの通信は、ＤＳサーバ（４１６）からユーザに先に送信される要求の結果であってもよく、あるいはＤＳサーバにおいてユーザから受信される自発通信であってもよい。
【００６４】
ステップ４２０において、ユーザの通信（例えばＨＴＴＰ「Get」メッセージ）は、ＤＳサーバ（１００）において受信される。次に、ステップ４２１において、ユーザの登録アイデンティティサービスに対するユーザのために格納されたＲＯについてのチェックは、ユーザに提供され、かつ、まだ登録されていない１つ以上のアイデンティティサービスに対して実行される。未登録アイデンティティサービスがそのユーザに対して発見された場合（ステップ４２２）、ステップ４２３において、ＳＰが選択されてもよい。上述のように、サービス機能記憶領域（１０３‐２、３０１）のチェックは、未登録アイデンティティサービスの判定及び後続のＳＰの選択の際に評価するために使用されてもよい。
【００６５】
単純な実現例は、ＤＳサーバ（１００）における後続する対応するＲＯの提供及び格納（ステップ４３）で構成される。これは、図５のステップ４２及び４３を参照して上述したように達成される。
【００６６】
ＳＰを選択するためのステップ４２３において実行されるサービス機能記憶領域（１０３‐２、３０１）に対するチェックの結果、２つ以上のＳＰが当該アイデンティティサービスを提供するために発見されてもよい。この場合の適切な解決策は、ユーザが既にサービスアカウントを有する１つのＳＰを選択することを含んでもよい。例えば、ステップ４２３において発見されたＳＰのうちの１つと一致するＳＰを見つけるために、ＤＳサーバにおいて、検索がユーザのために格納された他のＲＯに対して実行される。２つ以上のＳＰがその条件を満たし、実現例のオプションとして、ＤＳサーバはそれらＳＰのうち任意のＳＰを直接選択できる。ステップ４２３において、当該アイデンティティサービスを供給するのに適切なＳＰとして見つけられたＳＰがユーザからのある特定のサービス専用関連データ（例えば、言語基本設定、個人の住所、クレジットアカウント番号等）の収集をＤＳによって行なうことを提示した（例えば、そのサービスに対する機能登録の際）ことが発見される。更に、未登録アイデンティティサービスの登録をトリガする前に明確なユーザの同意を取得することが要求される場合がある。
【００６７】
従って、そのような場合（選択可能なＳＰが複数存在する場合、ユーザの同意が必要とされる場合、サービスデータ収集が指示される場合）、複数のＳＰの中から１つのＳＰを選択するようにユーザに指示し、それらサービス関連データの一部又は全てを入力するようにユーザに指示することが望ましい。ステップ４２４において、通信はその目的でユーザに送信され、ステップ４２５において、ユーザからの通信はその結果として受信され、それは、サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）とサービス関連データ（ＳＲＶ‐ＤＡＴ）との少なくともいずれかを含むことができる。また、ユーザに送信される通信要求（４１６、４２４）において（又は、前記ユーザに対して確立された通信において）、ＤＳサーバは、前記プロバイダ基本設定（ＳＰ‐ＰＲＥＦ）とサービス関連データ（ＳＲＶ‐ＤＡＴ）との少なくともいずれかを入力するように前記ユーザに指示してもよい。サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）は、異なる形式であってもよく、ユーザの同意であると仮定されてもよい（しかし、その目的に対する特定のアサーションは、ユーザ通信４２５においても使用できる）。例えば、ユーザが複数のＳＰのＵＲＩを含むリストを受信した場合、サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）は、それらＳＰのうち１つのＳＰのＵＲＩを含むことができる。また、ユーザは好適なドメイン（例えば、「xzy.com」）を指示することができ、それにより、ＤＳサーバはそのドメインに属する適切なＳＰを選択する。更に、ユーザは、選択可能なＳＰのうち「任意」のＳＰが選択されてもよいことを指示でき、この場合、ＤＳサーバは任意の更なる基準（例えば、完全ランダム、より負荷の少ないＳＰ等）に従って１つのＳＰを自由に選択できる。次に、ステップ４２６において、ユーザが提示した基本設定に従ってＳＰが選択される。
【００６８】
上述のように、選択されたＳＰが当該ユーザを知っているのが好ましい場合がある。アイデンティティ連携フレームワークにおいて、一般にその知識は、ユーザが前記ＳＰに対して連携サービスアカウントを有することを示し、その結果、それらフレームワークにおいて周知の機構に従って、ユーザに対するユーザ識別子が前記ＳＰと中央供給エンティティ（例えば、既に説明したように、同一のサーバマシン内に共に配置されて使用するＩＤＰサービスを提供するサーバエンティティ又はディスカバリサービスＤＳを提供するサーバエンティティ）との間で共有されることを示す。プライバシーの理由から、一般に「ユーザ別名」として知られる前記ユーザ識別子は、異なるＳＰ間では同一ユーザに対しても異なる。
【００６９】
ステップ４２７は、選択されたＳＰにおいてユーザが周知であるか否か（又は、換言すると、例えばユーザがＳＰを介してアイデンティティを連携したために、ＳＰがユーザを知っているか否か）を考慮するＳＰ選択処理の一部を集約する。ユーザが選択されたＳＰにより既に知られている場合、前記ＳＰと共有される前記ユーザのユーザ別名は、前記ＳＰとの更なる通信の際に前記ユーザを参照するために選択される。あるいは、ユーザは、選択されたＳＰにおいて連携される必要があり、これは、例えば、図６の後続するステップを参照して説明される別の方法のうち１つを使用して達成されてもよい。
【００７０】
ユーザが選択されたＳＰに対して周知であるか否かに関わらず、未登録アイデンティティサービスの登録を完了し、次にＤＳサーバにおいて対応するＲＯを提供するための２つの基本的なモードが存在する。それらモードは、選択されたＳＰとの通信がＲＯを提供するために必要とされる時、又は、要求される時に常に存在する。
【００７１】
ステップ４２８Ａは、選択されたＳＰにユーザをリダイレクトすることを示す第１のモードを表す。これは、例えば、当該アイデンティティサービスを提供するウェブサービスプロバイダ（ＷＳＰ）として動作するように選択されたＳＰ（例えば、１４０）に対して、ユーザ（１５０）とＤＳサーバ（１００）との間に確立された通信をリダイレクトするＨＴＴＰ「redirect」により達成されてもよい。ステップ４２８Ｂは、ＤＳサーバ（１００）と選択されたＳＰ（例えば、１４０）との間の直接通信の確立（例えば、サーバエンティティ間の通信に対する所謂「バックチャネル」に対して、ＳＯＡＰ等の周知のプロトコル・バインディングを使用する）を示す第２のモードを表す。
【００７２】
ステップ４２８Ａ及び４２８Ｂの通信は、実際には、それら通信を受信するＳＰからアイデンティティサービスを提供するための要求であり、特に、未登録アイデンティティサービスの登録が要求されることを提示する特定のコードと、当該アイデンティティサービスの識別子と、ＤＳサーバにおいて当該ユーザを識別するのに使用可能な識別子（例えば、そのユーザに対するＲＯ‐ＤＳ）とを含んでもよい。それら通信は、ユーザから収集されたサービス関連データ（ＳＲＶ-ＤＡＴ）を更に含んでもよく、選択されたＳＰから機能登録メッセージで受信された（４１１）サービスエントリポイントの識別子を使用すること又は含むことにより対処される。ステップ４２８Ｂに対して使用された用語「直接通信」は、間にいくつかのルーティングエンティティを含んでもよいＤＳサーバと選択されたＳＰとの間に確立された通信を含み、ステップ４２８Ａのようにリダイレクション要求に埋め込んで提供の要求を送信するような「間接的」な方法とは対照的であることを理解するべきである。
【００７３】
ユーザが選択されたＳＰにおいて周知である場合、そのＳＰにおけるユーザの共有される（連携される）ユーザ別名は、ステップ４２８Ａ又は４２８Ｂにおいて送信される要求に含まれてもよい。ユーザが選択されたＳＰにおいて周知でない場合、ＤＳサーバは、ユーザに対してダミーの識別子（あるいは、「デフォルト」として合意された他の指標又はデフォルトとして認識される指標）を含んでもよい。ダミーの識別子は、受信機ＳＰにおいて、前記ＳＰから前記ユーザのアイデンティティを連携する必要があると解釈される。例えば、ユーザが選択されたＳＰに対してリダイレクトされる場合（４２８Ａ）、ＤＳサーバは、ユーザに対してダミーの識別子を含んでもよい（又は識別子を含まなくてもよい）。従って、選択されたＳＰがユーザを識別できないため、ＳＰは、ユーザが既にサービスアカウントをそのＳＰに対して有するかを調査するために又はそのＳＰにおいて新しいアカウントを作成するためにユーザと対話してもよい。その後、ＳＰは、ユーザ連携を要求し（例えば、認証要求メッセージをＩＤＰに対して送信する）、ＩＤＰは、特にユーザ別名及びそのユーザに対するＤＳサーバと通信するための情報（すなわち、更なるＤＳクエリ、又は、ＤＳ更新のためのユーザに対するＲＯ‐ＤＳ）を返す。あるいは、ＤＳサーバは、ユーザに対して事前に割当てられた別名を作成し、且つ、選択されたＳＰと関連付けてＩＤＰ（９０）に格納するために、必要なステップを行なってもよい（図６においては詳細に示さないが、ステップ４２７において実行されると考えられる）。ここで、前記別名は、対応するＲＯ‐ＤＳと共に提供の要求において送信されてもよい（４２８Ａ、４２８Ｂ）。いずれの場合においても（ユーザが選択されたＳＰにおいて周知であるか又は周知でない場合）、選択されたＳＰはユーザと対話する必要がある（例えば、サービスを最終的に提供するために必要とされる更なるデータを収集するため）。従って、当該ユーザと選択されたＳＰとの間の更なる対話が必要とされる（予測される）場合には、ステップ４２８Ａのリダイレクトする方法が選択されるのが好ましい。
【００７４】
ステップ４２８Ａ又は４２８Ｂにおける選択されたＳＰに送信される未登録アイデンティティサービスの提供の要求の結果、ステップ４２９において、ＤＳ更新（又は他の同等のメッセージ）は前記ＳＰから受信され、ＤＳ更新は前記ＳＰにより形成されたＲＯ（ＲＯ２Ｘ）を含む。これを達成するために、ＳＰにおける処理手段は、ユーザがＳＰと接続する（図２のフロー２０１）時の方法と同様の方法でＤＳサーバから行なわれるアイデンティティサービスの提供の要求に応答するように変更されてもよく、それにより、同様の要求を行なう（２０２、４２９）。あるいは、ＲＯ又はＲＯを形成するのに使用可能なデータを搬送できる限り、特定のメッセージが、一般に使用されるＤＳ更新の代わりに使用されてもよい。その後、ステップ４３０において、受信されたＲＯはＤＳサーバにより格納される。それにより、これまでに未登録のアイデンティティサービスを登録し、ＲＯを使用して更なるＤＳクエリに対して応答することが可能になる。そのＤＳクエリは、前記ユーザの前記アイデンティティサービスに対するアクセス権を要求するために、最終的に前記ＤＳサーバにおいて受信されてもよい。
【００７５】
尚、上記ステップ４２３、４２７及び４２８Ｂに対応する実行フローは、未登録アイデンティティサービスが先の段階（図５のステップ４１４及び４１５）で検出された場合にＲＯを提供するための別の実行方法を構成する。これは、ユーザの介入を必要としない。従って、例えば、機能登録後（ステップ４１１）又はサービス機能記憶領域の周期的なチェック後（ステップ４１３）に、ユーザの未登録アイデンティティサービスがユーザの介入なく先の段階で検出された場合、ＤＳサーバは、適切なＳＰを選択し、前記アイデンティティサービスの提供の要求を前記ＳＰに直接送信できる（ステップ４２８Ｂ）。これは、ＳＰからの後続するＤＳ更新において受信される対応するＲＯ（ＲＯ２Ｘ）（ステップ４２９）を格納する（ステップ４３０）ことで終了する。
【００７６】
図７に示されるフローチャートは、ＤＳクエリがＳＰから受信された時（ステップ４２１０）にＤＳサーバ（１００）により実行される処理ステップを示す。ウェブサービスコンシューマ（ＷＳＣ）として動作する前記ＳＰは、ユーザのアイデンティティサービスに対するアクセス権を要求し、前記アイデンティティサービスは、前記ユーザに対してまだ登録されていない。上述のように、それら処理ステップは、本発明のＤＳサーバが何らかの理由によりユーザの未登録アイデンティティサービスの登録を遅延させた場合（例えば、ＤＳクエリを待つという条件がユーザ又はサービスに対して設定されている場合、更新されたサービス機能記憶領域の周期的なチェックが行なわれる前にＤＳクエリが受信される場合、未登録アイデンティティサービスのバッチ処理がいくつかのユーザに対して待ち状態である場合等）に実行される。
【００７７】
ステップ４２１１及び４２１２は、最新技術によるＤＳにおける現在の処理を表してもよい。これは、背景の節で提示したように、受信されたＤＳクエリにおいて指示されるアイデンティティサービスが、関連するユーザに対して格納された任意のＲＯに対応するかを判定するためのチェックを示す。要求されたアイデンティティサービスが前記ユーザに対するＤＳサーバに登録されていない場合に本発明に従って処理するための３つの別の方法を図７に示す。
【００７８】
第１の方法（ステップ４２１３Ａ）において、リダイレクション要求は、ＤＳクエリを送信したＳＰに送信され、ユーザをＤＳサーバにリダイレクトするように要求する。リダイレクション要求は、ＤＳ応答内に埋め込まれて送信されてもよく、あるいはリダイレクトすることを要求する別の種類のメッセージで送信されてもよい。リダイレクション要求は、ＤＳサーバのサービスポイントにマップするＵＲＬを含むことができる（ステップ４１６の通信の場合と同様）。第２の方法（ステップ４２１３Ｂ及び４２１４Ｂ）において、ＤＳサーバは、ステップ４１６を参照して先に説明したように、当該ユーザに対する通信を確立するための要求を送信してもよい。この第２の方法において、ＤＳサーバは、ＲＯを含まないＤＳ応答を送信してもよく（ステップ４２１３Ｂ）、あるいは要求されたアイデンティティサービスの対応するＲＯが利用可能になるまでＤＳ応答を待ち状態にしてもよい。第３の方法は、対応するＲＯの提供及び格納のためにユーザの介入も選択されたＳＰとの通信も必要としない簡単な実施形態に対応する。簡単な本実施形態の処理ステップは、サブフロー「Ｅ」への遷移により示され、図６の適切なＳＰの選択を行なうステップ４２３、並びに生成されたＲＯの提供及び格納を行なうステップ４３に継続する。これは、サブフロー「Ｄ」により示されるように図７のステップ４２１６Ｂに戻り、生成されたＲＯ（ＲＯ２Ｘ）を含むＤＳ応答は、ＤＳクエリを送信したＳＰに送信される。
【００７９】
個別には示さないが、第４の方法がステップ４２１２の後に選択される。これは、ユーザとの通信の確立を必要とせず、図６を参照して上述したステップ４２３、４２７、４２８Ｂ、４２９及び４３０の実行を含む。この方法の実行は、遷移「Ｇ」を介して図７に示す処理フローに継続する。
【００８０】
上述の最初の２つの方法（それぞれステップ４２１３Ａ、及びステップ４２１４Ｂ（ステップ４２１３Ｂに先行する又は先行しない））の場合、実行フローはユーザ通信の受信に継続する（図６のフロー「Ａ」への遷移により示される）。これは、図６に示す処理フローを参照して上述したように処理される。遷移「Ｇ」及び「Ｆ」により指示されるように、実行フローは図７に戻る。ここで、提供の要求が選択されたＳＰに直接送信された場合（図６のステップ４２８Ｂ）、実行フローは直接継続し（フロー「Ｇ」）、あるいは提供の要求がリダイレクションで送信された場合（図６のステップ４２８Ａ）、実行フローは、ステップ４２１５において、選択されたＳＰから受信されるリダイレクションの受信を待つ（フロー「Ｆ」）。選択されたＳＰから受信されるリダイレクションは、ＳＰが生成したＲＯ（ＲＯ２Ｘ）を含んでもよく、これは、受信された提供の要求の結果として前記ＳＰが送信したＤＳ更新の送信（ステップ４２９）を不必要にするオプションとなる。また、ステップ４２１５において受信されるリダイレクション及びステップ４２９において受信されるＤＳ更新（又は同等のメッセージ）は、アイデンティティサービスが示すリソースに対して、供給されるユーザがアクセス、管理等を行なうことを容易にするためのデータを含んでもよく、それらデータは後続する通信（例えばカレンダのチェックを容易にする又は個人データを変更するなど、当該リソースのアクセス又は管理に対処するのに使用可能なＵＲＬ等）を介してユーザに配信されてもよい。
【００８１】
ステップ４２１５の後又は遷移サブフロー「Ｇ」の後、２つの処理方法が選択される。第１の方法は、ステップ４２１６Ｂにより示されるように、選択されたＳＰから受信されたＲＯを含むＤＳ応答の送信を含む。また、実行はステップ４２１６Ａに継続してもよく、ステップ４２１６Ａにおいて、ユーザはＤＳクエリを送信したＳＰにリダイレクトされる。後続するステップ４２１７Ａ及び４２１８Ａにより示されるように、ＷＳＣとして動作するＳＰ（すなわち、アイデンティティサービスの呼出しを介して前記ユーザのアイデンティティのリソースの消費を必要とするサービスをユーザに供給するＳＰ）からの後続するＤＳクエリは、対応するＲＯ（ＲＯ２Ｘ）を使用して正常に返答されてもよい。
【００８２】
図５〜図７を参照して上述したいくつかの処理ステップに対応する信号フローを図８及び図９に示す。それら信号フローは、ＤＳサーバからユーザの未登録アイデンティティサービスに対するアクセス権を提供する例を示すために使用される。ここで、前記提供は、ＤＳクエリの受信の際に実行される。
【００８３】
図８のフロー４１１において、機能登録は、ＤＳサーバ１００においてＳＰ１４０から受信される。例えば、ＳＰ１４０は、ＩＤＳＲＶ‐Ｘ等のアイデンティティサービスを今後提供できることを報告する。ＤＳサーバは、ＳＰ１４０がそのアイデンティティサービスを供給できる（図３に示す）ことを提示するために、サービス機能記憶領域（１０３‐２）を更新する（４１２）。図５〜図７を参照して上述したように、ＤＳサーバは、機能登録において受信された更新により、いくつかのユーザに対して未登録である（又は未登録となった）アイデンティティサービスの提供を開始できる。しかし、上述のように、図８及び図９で示される例において、ＤＳサーバ１００が、ユーザに対応する未登録アイデンティティサービスのＲＯの不足を示すＤＳクエリの受信を待つ場合の例が示される。
【００８４】
その後フロー２０４において、ユーザ１５０は、ＳＰ１１０にアクセスし、特定のサービスを要求する。簡単にするため、ユーザ１５０と、アクセスされたＳＰ１１０と、認証アサーションをＳＰ１１０に提供するＩＤＰ９０との間で一般に実行される認証フローは、図８及び図９には示さない。ＳＰ１１０においてユーザ１５０によりアクセスされるサービスは、例えば、ユーザのカレンダの更新を含む追加サービスを提供するフライト予約サービスであってもよい。これは、ＳＰが他のＳＰ、すなわちリソースに対してＷＳＰとして動作するＳＰにより提供される前記ユーザのリソース（この場合、カレンダデータ）に対するアクセス権をアイデンティティサービスを介して取得する必要があるため、ＳＰは前記追加サービスを提供するためにＷＳＣとなる必要があることを示す。従って、ＳＰ１１０は、ユーザに対して格納されたＲＯに対処するためのリソース識別子及び要求されたアイデンティティサービスの種類の識別子を含むＤＳサーバにＤＳクエリを送信する（フロー４２１０）。この例を示す目的で、「ＩＤＳＲＶ‐Ｘ」が「カレンダ」サービスを識別するために設定されたサービスの種類の識別子であると仮定される。受信されたＤＳクエリはＤＳサーバにおいて処理され（Ｃ）、例えば、ＤＳサーバ記憶領域１０３-１に格納されたサービス（ＩＤＳＲＶ‐Ｘ）及びユーザ（１５０）に対するＲＯが存在しないことが分かる。上述のように、ＤＳサーバは、ユーザに対してアイデンティティサービスＩＤＳＲＶ‐Ｘを登録するために対応するＲＯを提供することを続行する前に、ユーザ１５０と対話してもよい（Ａ）。
【００８５】
図８は、ＤＳサーバ１００が選択されたＳＰ１４０に対して提供の要求を送信する（フロー４２８Ｂ）上述の可能な方法を示している。その結果、ＤＳ更新（フロー４２９）は、そのユーザ及び指示されたサービス（例えば、ＲＯ０２Ｘ）に対するＲＯを搬送するＳＰ１４０から受信され、それは、ユーザに対するＤＳサーバによりＲＯ記憶領域（１０３‐１）に格納される（４３０）。次にＤＳサーバは、最近登録されたＲＯ（ＲＯ０２Ｘ）を含む受信されたＤＳクエリ（フロー４２１０）に対するＤＳ応答を送信する（フロー４２１６Ｂ）。その後、ＷＳＣとして動作するＳＰ１１０は、受信したＲＯ（ＲＯ０２Ｘ）のデータを使用して、ＳＰ１４０にアクセスする（フロー２０７）。ＳＰ１４０は、要求されたアイデンティティサービスを供給するＷＳＰとして動作する。ＳＰ１１０がＳＰ１４０に対して要求する動作の種類に応じて（本質的にはサービスに対して規定された動作におけるサービスの特質に応じて）、ＷＳＣ（ＳＰ１１０）とＷＳＰ（ＳＰ１４０）との対話は、図８に示す１往復以上の通信を含んでもよい。例えば、フロー２０８は、単純な動作（例えば、カレンダデータの読出し又は更新）に対する応答を表してもよいが、より複雑な動作に対しては、より多くの信号フローが存在するだろう。
【００８６】
図９のフロー４１１、２０４及び４２１０は、図８を参照して説明されたように実行され且つ処理される。しかし、図９は、ＳＰ１４０に提供の要求を送信するための別の方法及びユーザと接続するための方法を示す。
【００８７】
フロー４２１３Ａにおいて、リダイレクションがＳＰ１１０に送信される。リダイレクションは、前記ＳＰが有するユーザ１５０との通信をＤＳサーバ１００に対してリダイレクトすることを要求し、ＤＳサーバと接続するために使用可能な参照情報（例えば、ＤＳサーバのサービスポイントにマップするＵＲＬ）を含んでもよい（例えば、ユーザにとってＤＳサーバが不明であると考えられる場合）。ユーザは、その後リダイレクトされ、ＤＳサーバとの通信を開始する（フロー４２０）。ＤＳサーバは、例えばユーザ基本設定を収集してＳＰを選択するために又は提供されるサービスに対するサービス関連データを収集するために、ユーザ１５０と対話してもよい（Ａ）。ユーザ１５０との通信は、選択されたＳＰ１４０にリダイレクトされる（フロー４２８Ａ）。ユーザ１５０とＳＰ１４０との間の後続する通信は、特に、他のいくつかの実施形態に従ってＤＳサーバにより収集される先に参照されたデータと同一の種類のデータを収集するため、又は前記データの収集を完了するために使用されてもよい（例えば、ＤＳサーバが必要な全てのデータをユーザから収集しなかった場合）。
【００８８】
その後、ＤＳ更新（フロー４２９）は、ユーザ及び指示されたサービス（例えば、ＲＯ０２Ｘ）に対するＲＯを搬送するＳＰ１４０から受信され、図８の先の例のフローと同様に、ユーザに対するＤＳサーバによりＲＯ記憶領域（１０３‐１）に格納される（４３０）。ＳＰ１４０は、ユーザ１５０との通信をＤＳサーバ１００にリダイレクトする（フロー４２１５）。上述のように、このリダイレクションは、生成されたＲＯ（ＲＯ０２Ｘ）を搬送してもよく、それによりＤＳ更新の送信（４２９）を不必要にする。ＤＳサーバにおけるユーザとの通信は、クエリしているＳＰ１１０に対してリダイレクトされる（フロー４２１６Ａ）。ここで、前記リダイレクションは、アイデンティティサービスが提供されたことを示す指標、又は、要求されたアイデンティティサービスにアクセスするのに使用可能な対応するＲＯ（ＲＯ２Ｘ）を含んでもよい。あるいは、それら連鎖リダイレクションは、ＳＰ１１０にアドレス指定された戻り情報を含むことにより低減される。それにより、ＳＰ１４０は、ユーザを直接ＳＰ１１０に対してリダイレクトすることが可能になる（これは、ＤＳ更新の送信４２９を必要にするだろう）。
【００８９】
図９に示される後続するフローは、ＲＯがＳＰ１１０に送信されていないことを考慮する。フロー４２１７Ａにおいて、ＤＳクエリが受信され、新しく登録されたＲＯ（ＲＯ０２Ｘ）を要求する。これに対して、フロー４２１８Ａにおいて、ＤＳサーバ１００からＤＳ応答で返答される。後続するフロー２０７及び２０８は、図８を参照して説明したように実行される。
【００９０】
図７又は図８には示さないが、例えばユーザが要求したサービスが完全に達成されたことを確認するために、要求したアイデンティティサービスにＳＰ１１０からアクセスした結果、ＳＰ１１０とユーザ１５０との間で更なる対話が行なわれる。上述の例に続き、ＳＰ１００は、ユーザ１５０のカレンダが更新されたことをユーザ１５０に更に指示してもよい。
【００９１】
最新技術の通信システムにおけるサーバエンティティは、一般に、コンピュータを使用するマシンにおいて実現される。従って、コンピュータ可読プログラムコードを含むコンピュータプログラムは、通信システムのコンピュータを使用するサーバエンティティにロードされ、それにより、前記サーバエンティティの各々は、それぞれの特定の機能性に従った所定の方法に応じて動作する。当業者は、コンピュータを使用するＤＳサーバにロードされることを意図されたコンピュータプログラムについて、作成と変更との少なくともいずれかを行う際、本発明の範囲から逸脱せずに、コンピュータプログラムの作成と変更との少なくともいずれかを行うのにそれら技術を容易に適用できる。それらコンピュータプログラムは、コンピュータを使用するＤＳサーバにおいて実行される際、ＤＳサーバを上述の任意の実施形態に従って動作させる。
【００９２】
例示としての限定しない方法で、いくつかの好適な実施形態に関して本発明を説明した。当業者には、種々の変形例が容易に理解される。そのため、本発明は、請求の範囲を考慮して解釈され限定される。
【図面の簡単な説明】
【００９３】
【図１】最新技術によるアイデンティティ連携フレームワークにおける協働するいくつかのエンティティを示す概略図である。
【図２】ディスカバリサービスサーバにおいてアイデンティティサービスをサービスプロバイダから登録し、前記アイデンティティサービスにアクセスする最新技術による簡略化された信号フローを示す図である。
【図３】図１に示される図と同様の図であり、本発明によるいくつかの機能モジュール及びディスカバリサービスサーバのデータ内容を概略的に示す図である。
【図４】本発明による方法を示す簡略化されたフローチャートである。
【図５】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図６】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図７】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図８】図５〜図７のフローチャートに示される実施形態のうちいくつかの実施形態に対応する簡略化された信号フローを示す図である。
【図９】図５〜図７のフローチャートに示される実施形態のうちいくつかの実施形態に対応する簡略化された信号フローを示す図である。
【技術分野】
【０００１】
本発明は、アイデンティティ連携フレームワークにおいてサービスを提供することに関し、特に、ユーザのアイデンティティサービスに対するアクセス権を提供する方法及びそれに関連する装置に関する。
【背景技術】
【０００２】
インターネットを介して提供される第１の種類のサービスは、通常、１対１（消費者対企業、ユーザ対プロバイダ）の関係に限定される。この種類のサービスの主な例において、サービスプロバイダ（以下、ＳＰと呼ぶ）は、１つ以上のサービスを複数のユーザに提供できる。これらのサービスのうちのあるものは、（例えば）共通に提供され、例えば、任意のユーザが利用可能な情報サービスか、あるいは、ユーザ毎にカスタマイズや許可を受ける必要のない情報サービスかの少なくともいずれかにすぎない。他のサービスは、供給されるユーザに応じてカスタマイズでき、例えば、ユーザの識別及び許可が事前に行なわれる。このことは、例えば、サービス又はその内容が供給される特定の各ユーザに応じて、若しくはそのユーザの基本設定に応じて適応される場合、或いは、ＳＰに対するサービスアカウントを有するユーザ（例えば、ＳＰのサービスに加入しているユーザ）に対してのみサービスが与えられる場合の、少なくともいずれかの場合に必要となる。
【０００３】
サービスの提供がユーザの識別を必要とする特別な場合、ＳＰはユーザ認証を実行する機構を実現し、通常、各ＳＰにおいてユーザの証明書(credential)（例えば、ユーザの識別子及びパスワード）を格納及び管理する。しかし、この簡単化された方法において、種々のＳＰに対して種々のサービスアカウントを有するユーザの場合、ユーザはそれらＳＰにより提供される異なるサービスにアクセスするための証明書を覚えておく必要があるため、ユーザ側で不便が生じる。ユーザは、全てのＳＰにおいて同一の証明書を利用することによりその欠点をなくそうとするだろうが、不可能である場合がある（例えば、ＳＰがユーザ識別子を強制的に与える場合、あるいは、同一ＳＰにおいて、選択された同一のユーザ識別子が既に他のユーザに割り当てられている場合）。しかし、いずれの場合においても、ユーザは、ＳＰにアクセスする度に証明書を提供する必要がある。
【０００４】
近年、アイデンティティ連携フレームワークが、主にその問題を解決するために開発された。簡単に説明すると、アイデンティティ連携フレームワークは、機能エンティティの集合（後述するＳＰ及びその他）と、複数のＳＰがユーザの連携アイデンティティ情報をそれらＳＰ間で共有することを可能にする機構の集合とを含む。この説明において、ユーザの「アイデンティティ」（「ネットワーク・アイデンティティ」としても知られる）とは、前記ユーザが種々のＳＰにわたり有する各サービスアカウント中に、前記ユーザに対して保持される属性の集合を示す。
【０００５】
「リバティ・アライアンス・プロジェクト（Liberty Alliance Project）」ＬＡＰ（http://www.projectliberty.org/）は、アイデンティティ連携フレームワークの標準化に係る標準化フォーラムである。従って、本出願において、ＬＡＰのいくつかの特定の用語である機能手順及び機能エンティティは、例として、周知の標準化されたアイデンティティ連携フレームワークの機能動作を示すために使用される。当業者は、それらの用語をアイデンティティ連携を提供する同様のフレームワークの同義語である機能手順及び機能エンティティと容易に関連付けられるだろう。
【０００６】
アイデンティティ連携フレームワークの第１の目標は、所謂ＳＳＯ（「シングルサインオン」、また「シンプリファイド・サインオン」としても知られる）を提供することであった。ＳＳＯにより、ユーザは、異なるサービス及びアプリケーションに安全にアクセスできる。それら異なるサービス及びアプリケーションは、異なるネットワーク又は管理ドメインに分散している可能性のある複数のＳＰを介して、毎回認証されることなくアクセスされる。ＳＳＯの背景にある現在の原理は、ユーザが特定のセッションに対して１度認証すると、そのようなレベルの認証を受け付けるユーザが加入している全てのサービスに対するアクセス権が与えられることを提示する。この原理により、ユーザは、ユーザが要求する特定の異なる各サービスに対する認証を明示的に行なわずに、それら異なるサービスにアクセスできる。ＳＳＯは、１度ユーザを認証し、その後、一般に「アイデンティティ・プロバイダ」ＩＤＰとして知られるサーバエンティティの仲介によって、結果として得られた認証を他のＳＰへの入口に対して有効にすることにより実現される。
【０００７】
アイデンティティ連携フレームワークの別の目標は、ユーザの連携アイデンティティに基づいて新しい種類のサービスを提供することである。簡単に説明すると、それら新しい種類のサービスは、複数のＳＰにわたるユーザの連携アイデンティティのリソースの消費を考慮する。用語「リソース」は、包括的な用語であり、より静的な性質を有するデータ属性（ユーザの名前、従業員番号、特定のサービス又はネットワークにおけるユーザ識別子等）、及び、より動的な性質を有するデータ属性（例えば、カレンダデータ、現在の地理的な位置等の前記ユーザに対するサービスに依存するデータ属性）等のユーザの連携アイデンティティのデータ属性を示してもよい。または、ユーザの連携アイデンティティの代わりの役割を果たすサービス（例えば、ショートメッセージの送信、電子メールの送信等、ユーザのアイデンティティに対してある動作を実行するサービス）を示してもよい。この場合、特定のＳＰは特定のサービスをユーザに提供できるが、ユーザは、そのサービスを完了するために、前記ユーザの連携アイデンティティのリソースの消費（例えば、ユーザのクレジットカード番号の使用、ユーザのウェブを使用したカレンダのデータのチェック、又は、そのカレンダに対するデータの設定、個人情報の使用等）を必要とするだろう（例えば、オプションの機能又は必須の機能として）。ここで、前記リソースは、格納され且つ別のＳＰにおいて主に処理される。前記「消費」は、前記リソースの検索と更新との少なくともいずれかだけでなく、アイデンティティを生かした動作の実行（例えば、ＳＰにおけるユーザのアイデンティティの属性はユーザの移動電話番号を含み、そのＳＰからその電話番号へショートメッセージを送信する動作）も含む。従って、新しい種類のサービスは、それらサービスの達成／カスタマイズ等のためにユーザに対してローカルに保持するデータを単に使用する以上のことを行なえるＳＰから前記ユーザに提供される。
【０００８】
この新しい種類のサービスの提供は、一般に、サーバエンティティの介入により達成される。サーバエンティティは、第１のＳＰが所望のリソースを保持する第２のＳＰにアクセスするのを可能にする「ディスカバリサービス(Discovery Service)」ＤＳとして一般に知られるサービスを提供する。本出願において、用語「ディスカバリサービスサーバ」（又はＤＳサーバ）は、任意の他の種類のサービスを提供する、又は、提供しないサーバマシンにサーバエンティティが常駐するか否かに関わらず、ディスカバリサービスＤＳを提供するサービスエンティティを示すために使用される。
【０００９】
アイデンティティ連携フレームワークにおいて一般に使用される専門用語において、上述の第２のＳＰはＷＳＰ（ウェブサービス・プロバイダ）として動作し、上述の第１のＳＰはＷＳＣ（ウェブサービス・コンシューマ）として動作するだろう。アイデンティティに関する情報の検索又は更新のために、あるいは前記アイデンティティのためのある動作を実行するために、ＷＳＣがＷＳＰにアクセスし且つリソースに従って動作することを可能にするサービスは、「アイデンティティサービス」として知られる。この専門用語の説明において、ＤＳサーバは、複数のＷＳＣがユーザの登録アイデンティティサービスを動的に発見することを可能にする「ディスカバリサービス」ＤＳを提供するように、対応するＷＳＰにアクセスするのに使用可能な情報をそれらＷＳＣに提供する。
【００１０】
ＤＳサーバは、ユーザのアイデンティティサービスに関する情報を格納するレジスタとして動作するとともに、要求があったときに前記情報を提供する機能エンティティである。特定のユーザの各登録アイデンティティサービスに対するＤＳサーバを格納する情報は、一般に「リソースオファリング」ＲＯとして知られる。その情報の内容は、ユーザの特定のアイデンティティサービス・インスタンスを一意に識別するのに使用できる。例えば、ユーザの約束及びタスクを格納するユーザの「カレンダ」サービスに対するアクセス権を提供するために、ＤＳサーバはＲＯを格納する。ＲＯは、種々のサービスを区別するためのサービスの種類の識別子（Service Type）、前記ユーザと関連のある前記サービスの種類のサービスインスタンスを一意に識別する識別子（例えば、他のユーザの「カレンダ」と区別するために）（Resource ID）、及び、前記ユーザに対する前記サービスを提供するＳＰを識別する識別子（Provider ID）を特に含む。それら全ての識別子は、統一資源識別子ＵＲＩ（Uniform Resource Identifiers）の形式であってもよい。しかし、特定のユーザの特定のアイデンティティサービスを識別し、且つ、アクセスするために、対応するＳＰと接続するのに使用可能な参照情報を提供する形式であれば、他の表現形式（例えば、単一のＵＲＩ）でもよい。
【００１１】
ディスカバリサービスＤＳを提供するために、最新のＤＳサーバは、以下の２種類の要求を受信し、それに返答するように構成される。第１の種類の要求は、「リソースオファリング」ＲＯの変更（新しいＲＯの挿入、又は、格納されたＲＯの除去）を要求し、以下において「ディスカバリサービス更新」ＤＳ更新と呼ばれる。第２の種類の要求は、格納されたＲＯの取得を要求し、対応するＲＯを含む「ディスカバリサービス応答」ＤＳ応答でＤＳサーバにより返答される。この第２の種類の要求は、以下において「ディスカバリサービスクエリ」ＤＳクエリと呼ばれる。
【００１２】
「ディスカバリサービス」ＤＳは、ＤＳ自体の特性により、「リソース」の特別な集合（すなわち、リソースオファリング、ＲＯ）の消費を（発見するという形態で）提供するアイデンティティサービスである。アイデンティティウェブサービスフレームワークにおけるディスカバリサービスを説明する仕様書は、「Liberty ID-WSF Discovery Service Specification」version 1.1（https://www.projectliberty.org/specs/liberty-idwsf-disco-svc-v1.1.pdfにおいて入手可能である）としてＬＡＰにより公開されている。
【００１３】
図１及び図２を参照して、この種類の新しいサービスの簡単な例を提供し、アイデンティティ連携フレームワークにおけるエンティティ間の機能関係に関して簡単に説明する。
【００１４】
図１において、複数のＳＰ（１１０、１２０、１３０、１４０）、ＩＤＰ（９０）、ＤＳサーバ（１００）及びユーザ端末（１５０‐１）と対話するユーザ（１５０‐２）が概略的に示される。尚、ＬＡＰの特定の専門用語において、包括的な用語「主体者」は、連携アイデンティティを取得できるエンティティを示すために使用される。用語「主体者」の範囲には、人間ユーザ、人間ユーザのグループ、企業、正当なエンティティ又は機能を供給するエンティティが含まれる。それら全ての種類の「主体者」は、実際にはアイデンティティ連携の「ユーザ」であり（又はユーザとなり）、用語「ユーザ」（１５０）は、本出願の以下において、ユーザの種類に関係なく、アイデンティティ連携のユーザを示すために使用される。図１のＳＰ（１１０、１２０、１３０、１４０）は、１つ以上のサービスプロバイダ機関のドメインに属することができる１つ以上のサーバエンティティの各々を表す。ここで、各サーバエンティティは、コンピュータを使用するマシン等の同一のサーバマシン内に共に配置されてもよく、あるいは種々のマシンにわたり分散されてもよい。同様に、ＩＤＰ又はＤＳサーバに対して開示される対応する機能性は、２つ以上のマシンにわたり分散されるか（例えば、各マシンが全体の機能性のサブ機能を実行する）、あるいは同一マシン内に共に配置される。しかし、簡単のために、示されるサーバエンティティ（９０、１００、１１０、１２０、１３０、１４０）の各々は、各々が対応する開示された機能性を実現する単一マシンを表すものと仮定される。しかし、実用上の実現例において、ＩＤＰの機能及びディスカバリサービスの機能は、同一のサーバマシン内に共に配置されて使用される。
【００１５】
簡単のために、１つのＤＳサーバが図１に表される。しかし、２つ以上のＤＳサーバが、アイデンティティ連携フレームワークを提供する通信システム内に存在してもよい。ここで、例えば各ＤＳサーバは、ディスカバリサービスを前記連携のユーザの集合に供給するために割り当てられる。
【００１６】
ユーザ（１５０）は、２つ以上のＳＰ（１１０、１２０、１３０）と通信し、上述のように、ＳＳＯ機能を使用してユーザ認証が行なわれる種々のサービスに対するアクセス権を獲得できる。また、ＳＰ及びＩＤＰは、ユーザを認証するため及び特に認証アサーションを配信するために通信できる（１０）。例えば、ユーザ（１５０）は、ＳＰ１１０との第１の通信を確立し、そのＳＰにおいて認証される。ＩＤＰ（９０）はこの認証に関与し、ユーザが例えばＳＰ１２０との別の通信を確立する時、ＩＤＰはＳＰ１２０に認証アサーションを提供する。ユーザが証明書を再び提供する必要なく、ＳＰ１２０は、そのＳＰにおける対応するサービスに対するアクセス権を付与する。
【００１７】
ＩＤＰは、ユーザのＳＳＯ認証処理中にＩＤＰとＳＰとの間で交換されるデータの一部として、ＤＳサーバ（１００）と接続するのに使用可能な参照情報をユーザ（１１０、１２０、１３０）が接続する任意のＳＰに更に提供し、それにより前記ＤＳサーバから前記ユーザのＲＯを（必要に応じて）取得できる。ＤＳと接続するのに使用可能な前記参照情報は、上述のようにＤＳサーバにより提供されるアイデンティティサービス（すなわち「ディスカバリサービス」ＤＳ）にアクセスするために使用されるため、「リソースオファリング」であると考えられる（以下、ＲＯ‐ＤＳと呼ぶ）。更なる通信（１２）は、ユーザ（１５０）のアイデンティティサービスにアクセスするためにＳＰ間で確立される。
【００１８】
図２に示す信号フローを使用して、ユーザの特定のアイデンティティサービスに対するＲＯをどのようにＤＳサーバに格納するか、及び、そのＲＯにどのようにして更にアクセスするかを説明する。第１のステップ（フロー２０１）において、ユーザ（１５０）は、特定のＳＰ（１３０）にアクセスし、そのＳＰにより供給される特定のサービスに加入することを決定する。例えば、ＳＰ１３０（例えば、取引銀行）は、ウェブを介して安全な支払いサービスを提供する。あるいは、例えばＳＰ１３０は、パーソナルコンピュータ又は移動電話からウェブブラウザアプリケーションを介してユーザによりチェックされ且つ他のサービスを（又は他のサービスの結果）提供するためにチェックされる（又は更新される）カレンダサービスを提供する。特定のサービスへの加入を要求するためのユーザのＳＰへのアクセスは、ユーザに周知の登録ＵＲＬ（ユニフォームリソースロケータ）又はウェブページ上でＳＰにより指示される登録ＵＲＬにＨＴＴＰメッセージ（通常、ＨＴＴＰ「Get」）を送信することにより開始してもよい。図示される次のステップ（フロー２０２）において、ＳＰ１３０は、前記ＳＰ１３０における前記ユーザの前記アイデンティティサービスにアクセスするための対応するＲＯを含むＤＳサーバ１００に、「ディスカバリサービス更新」ＤＳ更新を送信する。前記ＲＯを使用することにより、別のＳＰ（１１０）は、例えば、前記ユーザにより入手される商品に対する支払いアサーションを取得でき、あるいはユーザのカレンダデータをチェック又は更新できる。
【００１９】
受信したＤＳ更新の結果、ＤＳサーバは受信ＲＯを格納する（２０３）。図１に概略的に示すように、ＤＳサーバはデータ記憶領域（１０３‐１）を有し、ディスカバリサービスを供給するユーザ（ＵＳＲ‐１，ＵＳＲ‐２，．．．，ＵＳＲ‐ｎ）毎に、又は、前記ユーザの各々に対して登録されたアイデンティティサービス毎に、複数のＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）を格納する。
【００２０】
その後、ユーザ１５０はＳＰ１１０にアクセスする（フロー２０４）。ＳＰ１１０は、例えば、ウェブを介して支払いを受け付けるフライト予約サービスを供給し、追加機能として、ユーザのカレンダのチェック及び更新（例えば、飛行時間を「利用不可能」としてマークするユーザの利用可能性の確認、チケットを入手するためのタスクの設定等）との少なくともいずれかを更に提供する。ユーザ（１５０）がＩＤＰ（９０）の介入により先に認証されていると仮定すると（信号フローは図２には示さない）、ＳＰ１１０は、ＤＳと接続するのに使用可能な参照情報（上述のように、ＲＯ、ＲＯ‐ＤＳ）をＩＤＰから取得する。例えば、ユーザのカレンダをチェック又は更新するために、あるいは予約したフライトに対する支払いアサーションを取得するために、ＳＰ１１０は、「ディスカバリサービスクエリ」ＤＳクエリをＤＳサーバ（１００）に送信する（フロー２０５）。ＤＳクエリ（２０５）は、ＤＳサーバにアクセスするために取得されたＲＯ（ＲＯ‐ＤＳ）のリソース識別子（Resource ID）を含む。このリソース識別子により、ＤＳサーバは、関連する特定のユーザ（１５０）を識別できる。また、ＤＳクエリ（２０５）は、要求したアイデンティティサービスの識別子（例えば、「カレンダ」サービスを識別するために設定されたService Type識別子）を更に含むことができる。
【００２１】
受信したＤＳクエリが特定のアイデンティティサービスの識別子（Service Type）を含む場合、ＤＳサーバ（１００）は、前記サービス及び前記ユーザに対して登録されたＲＯが存在するかをチェックする。ＤＳクエリがアイデンティティサービスの種類の識別子なしで受信される場合、ＤＳサーバは、参照されたユーザに対して格納された全てのＲＯを含む「ディスカバリサービス応答」ＤＳ応答（フロー２０６）を返す。例えば（図１の記憶領域１０３‐１の内容を参照して）、ＤＳサーバは、ＵＳＲ‐１の場合はＲＯ１Ａ及びＲＯ１Ｂ、又はＵＳＲ‐２の場合はＲＯ２Ａを含むＤＳ応答を返す。あるいは、受信したＤＳクエリが特定のアイデンティティサービスの識別子を含む場合、ＤＳサーバは、指示されたアイデンティティサービス（例えば、ＲＯ１Ｂ）に対応するＲＯのみを返す。ＤＳ応答（フロー２０６）を取得すると、ＳＰ１１０は、アイデンティティサービスにより考慮されるリソースを提供するＳＰ（１３０）と通信することにより（フロー２０７、２０８）、取得したＲＯのデータを使用してアイデンティティサービスを呼び出せる（それにより、例えば、ユーザカレンダにアクセスし又はそれを更新したり、支払いアサーション、ユーザプロファイルデータ等を取得する）。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
しかし、ＤＳクエリにおいて指示されるアイデンティティサービスが前記ユーザの未登録アイデンティティサービスである場合（すなわち、そのアイデンティティサービスに対するＲＯがＤＳサーバ１００に格納されていない場合）、あるいはＤＳサーバにおいて前記ユーザに対して登録されたアイデンティティサービスが全く存在しない場合、後続するＤＳ応答（２０６）は空で送信される。ＳＰ１１０がユーザ１５０に提供する予定であるサービスの特性によっては、その事象は、前記サービスが最終的に拒否される原因となる可能性があり、あるいは、最小限の影響として、提供された最終的なサービスの品質の低下の原因となる可能性がある。例えば、これは、アイデンティティサービスが登録されていた場合にそのアイデンティティサービスを介して自動的に取得されたであろう必要なデータの一部を、ＳＰ１１０に対してユーザが手動で提示することを要求する。
【００２３】
ユーザは、そのアイデンティティサービスを提供できるＳＰと接続することにより上述の問題を克服し、この時点まで未登録であるアイデンティティサービスをユーザ自身に対して登録できる。しかし、ユーザは、前記アイデンティティサービスを提供できるＳＰを最終的に見つけ出すまでに、いくつかのＳＰと接続しなければならない可能性がある。ＳＰを見つけると、ユーザはそのサービスに加入できる。従って、上述のフロー２０１及び２０２が実行され、前記ユーザに対して前記アイデンティティサービスをＤＳサーバに登録する。その後、例えば、ユーザが放置されたサービスに対するアクセス権をまだ獲得したい場合、ユーザは再び処理を開始し、前記アイデンティティサービスを発見できなかったＳＰ（１１０）と再び接続できる。
【００２４】
しかし、その方法により、ユーザが後で必要とする可能性のあるユーザの未登録アイデンティティサービスとして残っている他のアイデンティティサービスに対して、上述の状況と同一の状況が繰り返されることを防止することはできない。更に、新しいサービスは、ＳＰにより迅速に開発及び実現され、それは、新しいアイデンティティサービスの提供及び要求を最終的に含む。しかし、アイデンティティサービスの登録に対する最新の機構（フロー２０１及び２０２を参照して説明した）は、前記新しいサービスの迅速な展開を妨げる。これは、ユーザの所望のアイデンティティサービスをＤＳサーバに登録する（２０２）前記ＳＰを実現するように、ユーザが継続して適切なＳＰを見つけ、かつ、それらＳＰに接続する（２０１）必要があるからである。
【課題を解決するための手段】
【００２５】
本発明は、ユーザの未登録アイデンティティサービスに対する登録処理をディスカバリサービスサーバからトリガすることにより上記問題を解決する。これは、請求項１記載の方法、請求項１６記載のディスカバリサービスサーバ、又は、請求項３３記載のコンピュータプログラムにより達成される。本発明の実施形態については、添付の請求の範囲で説明する。
【００２６】
ユーザのアイデンティティサービスを登録し、前記登録したアイデンティティサービスに対するアクセス権を提供するために、ディスカバリサービスを提供する周知の機能に加え、本発明による方法、ディスカバリサービスサーバ及びコンピュータプログラムは、それぞれ、ユーザに対してまだ登録されていないアイデンティティサービスを提供するサービスプロバイダをディスカバリサービスサーバから選択するステップ、手段、及び、コンピュータ可読プログラムコードと、前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するためにリソースオファリングを前記ディスカバリサービスサーバに格納するステップ、手段、及び、コンピュータ可読プログラムコードとを含む。
【００２７】
ユーザの未登録アイデンティティサービスを登録する登録処理をディスカバリサービスサーバからトリガすることにより、前記ユーザは、利益を得るアイデンティティサービスの正確な知識を有する必要もなく前記アイデンティティサービスを提供するサービスプロバイダを自身で見つける必要性もない。ディスカバリサービスサーバが特定のユーザに対して登録されたアイデンティティサービスを認識しているため、ディスカバリサービスサーバは、前記ユーザに対してまだ登録されていないアイデンティティサービスの登録を開始し、それにより、前記サービスが最初に要求される前、又は、要求された時に前記アイデンティティサービスへのアクセスが可能になる。更に、ディスカバリサービスサーバにおけるユーザの登録アイデンティティサービスに関する知識により、サービスプロバイダに関するユーザの基本設定と、サービスプロバイダのサービス機能との少なくともいずれかに基づいてサービスプロバイダを選択することが可能になる。その基本設定とサービス機能との少なくともいずれかは、ディスカバリサービスサーバにおいて、先に登録されたアイデンティティサービスのリソースオファリングの内容から取得される。
【００２８】
本発明は、サービスプロバイダの選択と、ユーザの未登録アイデンティティサービスを登録するための対応するリソースオファリングの作成とを行なうディスカバリサービスサーバにおいて、有利に実現される種々の実施形態を提供する。しかし、最低限の実現例において、ディスカバリサービスサーバは、適切な候補サービスプロバイダを直接選択し、関連データを使用して対応するリソースオファリングを形成する。
【００２９】
一実施形態によると、ディスカバリサービスサーバは、サービス機能記憶領域をチェックし、前記アイデンティティサービスを提供できるサービスプロバイダを選択できる。サービス機能記憶領域は、特に、１つ以上のアイデンティティサービスの識別子と１つ以上のサービスプロバイダの識別子とを関連付けて有することができる。それにより、特定のサービスプロバイダにより提供されるアイデンティティサービスと、特定のアイデンティティサービスを提供できるサービスプロバイダとの少なくともいずれかをチェックできる。従って、特定のアイデンティティを提供するサービスプロバイダを選択することが可能になる。
【００３０】
別の実現例において、サービス機能記憶領域は、外部データベース等の外部エンティティに格納される。この場合、ディスカバリサービスサーバは、サービスプロバイダを選択するために、記憶領域をクエリして、サービスプロバイダ／アイデンティティサービスの関係に関する情報を取得する。あるいはそれに加えて、サービス機能記憶領域はディスカバリサービスサーバ内に格納され、それにより、内部チェック処理が可能になり、外部エンティティにクエリを送信することを回避する。
【００３１】
サービス機能記憶領域は、ディスカバリサービスサーバに格納されるか、或いは、外部エンティティに格納されるかに関わらず、サービスプロバイダがそれぞれ提供できるアイデンティティサービスに関する情報を含むサービスプロバイダから受信される機能登録を使用して動的に更新されるのが好ましい。しかし、サービス機能記憶領域は、情報を要求及び更新するために複数の周知のサービスプロバイダをクエリすることにより周期的に更新されてもよい。単純なアクセスポリシーは、機能登録を送信することを許可されたサービスプロバイダ、又は、同一の目的でディスカバリサービスサーバからクエリされることを許可されたサービスプロバイダを判定するために確立される。それにより、ユーザに対するアイデンティティサービスを提供するアイデンティティサービスプロバイダをディスカバリサービスサーバにおいて選択する時、要求に応じて、いくつかの信用サービスプロバイダのみを選択可能な候補とすることができる。
【００３２】
本発明は、異なる状況において、特定のアイデンティティサービスが１つ以上のユーザの未登録アイデンティティサービスであるかを評価するための種々の実施形態、又は特定のユーザがまだ登録されていないアイデンティティサービスを１つ以上有するかを評価するための種々の実施形態を提供する。それらの実施形態において、提供されるアイデンティティサービスは、ユーザの登録アイデンティティサービスに対してディスカバリサービスサーバに格納されたリソースオファリングの内容と比較してチェックされる。
【００３３】
一実施形態において、上記チェックは、対応するアイデンティティサービスにアクセスするために、ユーザの１つ以上のリソースオファリングを要求するディスカバリサービスクエリを前記ディスカバリサービスサーバにおいて受信した際に実行される。別の実施形態において、ディスカバリサービスサーバは、サービスプロバイダから機能登録を受信した際に前記チェックを行なうことができる。更に別の実施形態において、１つ以上のユーザに対する未登録アイデンティティサービスを見つけるためのチェックは、上記サービス機能記憶領域の周期的なチェックの際に実行される。更に別の実施形態において、ユーザの未登録アイデンティティサービスを判定するためのチェックは、前記ユーザからの通信をディスカバリサービスサーバにおいて受信した際に行なわれる。
【００３４】
別の実施形態によると、ディスカバリサービスサーバは、特定のユーザに対する未登録アイデンティティサービスを検出した際に、前記ユーザとの通信の確立を要求する。
【００３５】
更に別の実施形態によると、ユーザはディスカバリサービスサーバと通信できる。それにより、ディスカバリサービスサーバは、ユーザからサービスプロバイダ基本設定を収集することと、選択したサービスプロバイダからアイデンティティサービスを提供するのに使用可能なサービス関連データを収集することの少なくともいずれかが可能になる。前記通信は、上述のように、ディスカバリサービスサーバから先に行なわれた通信要求の結果であってもよく、あるいはユーザから受信した自発通信であってもよい。前記ユーザに対して未登録の特定のアイデンティティサービスの場合、ディスカバリサービスサーバは、ユーザにより指示されたサービスプロバイダ基本設定に従って前記アイデンティティサービスを提供するサービスプロバイダを選択でき、該当する場合は、そのサービスプロバイダに受信したサービス関連データの一部又は全てを転送できる。従って、当該サービスに対して、選択されたサービスプロバイダはそれらデータをユーザから後で収集する必要はない。
【００３６】
本発明の別の実施形態は、ディスカバリサービスサーバにおいて未登録アイデンティティサービスに対するリソースオファリングを提供するために、選択されたサービスプロバイダの介入が必要とされる状況に関する。特に、これは、ディスカバリサービスサーバが対応するリソースオファリングを形成するのに必要とされる全て又は任意のデータを有さず、それらデータの一部又は全てが生成され且つ選択されたサービスプロバイダから後で受信される場合でもよい。あるいは、選択されたサービスプロバイダがサービス関連データをユーザから収集すること又はサービス提供に対するユーザの同意を要求することと、アクセスポリシーを確立することとの少なくともいずれかを必要とする場合でもよい。これらの場合において、ディスカバリサービスサーバは、ユーザに対するアイデンティティサービスの提供の要求を選択されたサービスプロバイダに送信する。ここで、前記提供の要求は、オプションとして、前記ユーザに対する前記サービスの提供を、ユーザ独自のものにすることと、ユーザに適応させることとの少なくともいずれかのために、サービス関連データを更に含む。サービス関連データは、ディスカバリサービスサーバにより収集されてもよい。前記提供の要求の結果、選択されたサービスプロバイダは、対応するアイデンティティサービスをディスカバリサービスサーバに登録するためのリソースオファリングを含むディスカバリサービス更新を前記ディスカバリサービスサーバに送信できる。
【００３７】
一実施形態によると、ディスカバリサービスサーバは、選択されたサービスプロバイダに提供の要求を直接送信する。ユーザがディスカバリサービスサーバと通信状態にある時に適用可能である別の実施形態によると、ディスカバリサービスサーバは、選択されたサービスプロバイダに対する前記通信のリダイレクションの内部に埋め込まれた提供の要求を送信する。更に別の実施形態によると、ディスカバリサービスサーバがユーザのまだ登録されていないアイデンティティサービスにアクセスするために、前記ユーザのリソースオファリングを要求するディスカバリサービスクエリを受信した時、提供の要求は、前記ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答内で搬送される。
【発明を実施するための最良の形態】
【００３８】
次に、本発明のいくつかの好適な実施形態について、図３〜図９を参照して詳細に説明する。
【００３９】
図３は、相互接続ネットワーク（３００）を介して相互接続される複数のＳＰ（１１０、１２０、１３０、１４０）及びＤＳサーバ（１００）を示し、その結果、複数のサブネットワークを形成できる。相互接続ネットワークにより、ユーザ（１５０）は、１つ以上のＳＰ、並びにＤＳサーバ（１００）又はＩＤＰ（図３には示さない）と通信できる。図３に示すエンティティ間の通信（そのうちのいくつかは、図５のフローチャート及び図９の信号フローに表される）は、ウェブサービスを提供するために今日利用される周知のプロトコル（「ハイパーテキスト転送プロトコル」ＨＴＴＰ等）を使用することにより達成され、情報、要求及び応答を通信ネットワークを介して交換する時にエンベロープ及びデータ符号化として使用される別のプロトコル（「シンプル・オブジェクト・アクセス・プロトコル」ＳＯＡＰ等）を組み込むことができる。
【００４０】
ＤＳサーバ（１００）の一般的な内部構造を図３に示す。通信システムにより又は通信システムを介して提供されるサービスを供給する装置又はそれらサービス間を仲介する装置が、特定の構成の詳細に関わらず、１つ以上の機能モジュールで構成されることは周知である。各機能モジュールは、前記装置により実現される全体の機能の特定のサブ機能を実行するように構成され、最終的には前記装置における他の機能モジュールと協働するように構成される。特に、現代の通信システムにおけるサーバエンティティは、一般に、ソフトウェア及びハードウェアを含むコンピュータを使用する装置である。ここで、１つの前記装置における特定の機能モジュールは、ソフトウェア、ハードウェア又はそれらの組合せの一部を含むことができる。前記一部は、特定の（サブ）機能を実行し、更に継続する場合は、他の機能モジュールを実現するソフトウェア部分とハードウェア部分との少なくともいずれかと協働するように設計される。通信システムに対するサーバ装置の機能が規定されると、前記装置を実現するために機能モジュールを構成することは、当業者にとっての日常業務に該当する。従って、ＤＳサーバ（１００）の一般的な内部構造について、その構成に関する具体的な詳細には触れずに、基本的な機能モジュールを参照して説明する。
【００４１】
図３に示すＤＳサーバ（１００）の簡略化された内部構造は、処理モジュール（１０１）、通信モジュール（１０２）、データ記憶モジュール（１０３）及び１つ以上の内部通信バス（１０４）を含む。内部通信バス（１０４）は、それらモジュール間のデータ通信及び協働を可能にする。処理モジュール（１０１）は、例えば、負荷分割モード又はアクティブバックアップモードで動作する１つ以上のプロセッサ（１０１０）を含むことができる。処理モジュール（１０１）は、従来技術から周知であり、後述する機能性により拡張されるディスカバリサービスを提供するために、サービスロジックを実行して、ＤＳサーバ（１００）と他のエンティティ（１１０、１２０、１３０、１４０、１５０、３０１）との間で交換される信号を処理するとともに、ＤＳサーバにおける他の機能モジュール（１０２、１０３）を制御する。
【００４２】
外部通信は、１つ以上の通信装置（１０２１、１０２２）を含むことができる通信モジュール（１０２）を介して実行される。例えば、各々が特定の種類の通信（例えば、ＳＰのみとの通信、特定の種類の通信プロトコルに対してのみの通信等）を行なう１つ以上の通信装置（１０２１、１０２２）が存在する。また、１つ以上の通信装置（１０２１、１０２２）は、任意の種類の通信において使用されるのに適切であり、この場合の通信装置の数は、ＤＳサーバに対して推定される全体の外部信号と比較し、外部信号を処理する個々の容量によって異なる。
【００４３】
１つ以上のデータ記憶装置（１０３０）を含むことができるデータ記憶モジュール（１０３）は、動作するのに必要なデータを格納するためにＤＳサーバにおいて使用される。データ記憶装置（例えば、メモリチップ、磁気ディスク、光ディスク等）は、最新技術において周知であり、それにより、ＤＳサーバ（１００）のデータ記憶モジュール（１０３）は、同一の又は異なる種類の１つ以上の記憶装置を（例えば、要求されるデータアクセス速度、格納された特定のデータに対する所望の信頼性等の基準に基づいて）使用することが可能になる。２つのデータ記憶領域（１０３‐１、１０３‐２）は、図３において強調される。尚、それら２つの記憶領域は論理的に独立しているため、それら記憶領域が必ずしもそれぞれ個別の記憶装置に含まれる必要はない。例えば、データ記憶モジュール（１０３）のアドレス指定可能な総記憶領域は、周知のアドレシング技術を使用してデータ記憶の詳細を隠蔽することを可能にする２つ以上の記憶装置（１０３０）のアドレス指定可能な個別の記憶領域を含むことができる。ここで、異なる記憶領域（例えば、１０３‐１、１０３‐２）は、アドレス指定可能な異なる領域を割り当てることにより、規定されるとともに区別される。
【００４４】
第１のデータ記憶領域（１０３‐１）は、複数のリソースオファリングＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）を格納する。上述のように、ＲＯは、ユーザについて既に登録されているアイデンティティサービス毎にＤＳサーバに格納され、前記ユーザの前記アイデンティティサービスを提供するＳＰにアクセスして前記アイデンティティサービスを要求するのに使用できる。例えば、「ＲＯ２Ａ」で示されるＲＯは、アイデンティティサービス「Ａ」に対するユーザ「ＵＳＲ‐２」のＲＯを例示する。例示の目的で使用される表記以外に、ＲＯ「ＲＯ２Ａ」は、アイデンティティサービスの種類（「Ａ」）を他のアイデンティティサービスと区別するためのサービスの種類の識別子（上記ＬＡＰ ＤＳ仕様書においてService Typeと呼ばれる）と、前記ユーザに対するアイデンティティサービス「Ａ」を提供するＳＰを識別する識別子（上記ＬＡＰ ＤＳ仕様書においてProvider IDと呼ばれる）と、前記ＳＰにおける前記ユーザに対応するアイデンティティサービスのサービスインスタンスを区別するためのサービスインスタンス識別子（上記ＬＡＰ ＤＳ仕様書においてResource IDと呼ばれる）とを含んでもよい。
【００４５】
第２のデータ記憶領域（１０３‐２）は、本発明に従って提供され、複数のＳＰから提供されるアイデンティティサービスに関するサービス機能情報を格納する。この第２の記憶領域（１０３‐２）は、１つ以上のアイデンティティサービスの識別子（ＩＤＳＲＶ‐Ａ，ＩＤＳＲＶ‐Ｂ，．．．，ＩＤＳＲＶ‐Ｘ）とそれらアイデンティティサービスを提供する１つ以上のＳＰの識別子（ＳＰ‐１２０，ＳＰ‐１３０，．．．，ＳＰ‐１４０）とを関連付けて含むことができる。あるいは、サービス機能記憶領域は、上述の内容と本質的には同一の内容を有して外部データベース（３０１）上に保持されてもよい。サービス機能情報を内部又は外部に記憶するいずれの場合においても、アイデンティティサービスの識別子を使用するサービス機能記憶領域（１０３‐２、３０１）に対するチェックにより、前記サービスを提供できる１つ以上のＳＰに関する情報が提供され、ＳＰの識別子を使用するチェックにより、前記ＳＰが提供する１つ以上のアイデンティティサービスの識別子が提供される。
【００４６】
従って、サービス機能記憶領域（１０３‐２、３０１）をチェックすることにより、特定のＳＰにより提供されるアイデンティティサービスに関する情報又は特定のアイデンティティサービスを提供できるＳＰに関する情報が提供されることが可能である。
【００４７】
ＳＰが提供できるアイデンティティサービスに対して影響を与えるＳＰにおける変更が起こる可能性がある。最も一般的な例は、特定のＳＰが、以前は提供していなかった新しいアイデンティティサービスを提供するために、新しいサービスロジックが提供されることである。しかし、例えば、ＳＰが特定の日付から特定のアイデンティティサービスの提供を停止する場合、あるいは新しいＳＰがアイデンティティ連携フレームワークにおける残りのエンティティと協働するように設定されるとともに、１つ以上のアイデンティティサービスを提供できる場合もある。従って、サービス機能記憶領域（１０３‐２、３０１）は、ＳＰとＳＰが提供できるアイデンティティサービスとの関係に関する変更を動的に報告及び更新を行なう中心的な場所となる。前記動的な更新を実行する代わりに、ＳＰは、ＤＳサーバ（機能記憶領域１３０‐２が使用される場合）又は外部データベース（３０１）に「機能登録」メッセージを送信する。「機能登録」メッセージは、例えば、ＳＰが関連付けるＳＰの識別子と、１つ以上のアイデンティティサービスの識別子と、指示されたアイデンティティサービスに対しては提供又は停止するかを示すコードとを含むことができる。尚、簡単のために、１つのＤＳサーバのみが例において示される。しかし、２つ以上のサーバエンティティがアイデンティティ連携フレームワークにおいて存在してもよい（例えば、各サーバエンティティは、前記連携のユーザの集合にディスカバリサービスＤＳを提供する）。これらの例において、提供するアイデンティティサービスに関する変更が行なわれるＳＰは、２つ以上のＤＳサーバに機能更新を送信してもよい。
【００４８】
機能登録メッセージは、後で使用するためにサービス機能記憶領域（１０３‐２、３０１）にも格納される更なるデータ（図３において詳細は示さない）を含んでもよい。例えば、提供され得る所与のアイデンティティサービスについて、ＳＰは、データをリスト表示する形式や、サービスの提供に必要なデータ（例えば、言語基本設定、個人の住所、好適なメールアドレス等のサービス関連データ）の収集を、サービスを受けるユーザからＤＳサーバに委託するか否かを指示してもよい。機能登録メッセージは、アイデンティティサービスを登録するためのエントリポイントを含んでもよい。このとき、そのエントリポイントは、例えばユニフォーム・リソース・ロケータＵＲＬでもよく、そのＵＲＬは、ユーザ（１５０）がＳＰ（１３０）のサービスへの加入をローカルで要求した際（図２のフロー２０１で示される）に使用したＵＲＬと同一でも異なってもよい。更に、機能登録メッセージは、ＳＰから指示された登録基本設定を含むことができ、それは、アイデンティティサービスの登録を完了するために、例えば、前記ＳＰがＤＳサーバとの直接通信又は他の通信方法を受け入れる（又は、より好ましいと考える）かを指示してもよい。また、メッセージは、１つのユーザ又はユーザの集合に対してＲＯを形成するのに必要なデータの一部又は全てを含んでもよい。
【００４９】
あるいは、ＤＳサーバ（１００）は、周知の複数のＳＰを周期的にクエリして、機能登録メッセージに対して上記指示されたデータと同一の種類のデータをそれらＳＰから要求し、その後、サービス機能記憶領域（１０３‐２）の内容を更新する。
【００５０】
必ずしもＳＰとの通信（上記機能登録又は機能クエリ）を要求する必要がないＤＳサーバ（１００）においてサービス機能記憶領域（１０３‐２）を形成する簡単な実施形態は、ＤＳサーバに既に格納される複数のＲＯ（ＲＯ１Ａ、ＲＯ１Ｂ、ＲＯ２Ａ、ＲＯｎＢ）に既に格納されるアイデンティティサービス及びＳＰに関するデータの収集を含んでもよい。すなわち、対応するアイデンティティサービスの識別子（例えば、Service Type）と共に各ＲＯに格納されるＳＰの識別子（例えば、Provider ID）を収集することは、ＤＳサーバ上に保持されるサービス機能記憶領域（１０３‐２）を形成することであると考えられ、あるいは、高い探索性能が要求される場合は、前記ＤＳサーバに論理的に分離されたデータベース（１０３‐２）を構築するのに使用される。従って、この簡単な実施形態において、ＤＳサーバに保持されるサービス機能記憶領域（１０３‐２）は、ＳＰから受信されるＤＳ更新メッセージで更新される（例えば、図２のフロー２０２で示される）。例えば、機能記憶領域１０３‐２は、ＤＳ更新２０２で指示されるアイデンティティサービスを提供する際にＳＰ１３０が現れなかった場合に更新される。
【００５１】
図４〜図７に示されるフローチャートは、本発明によるＤＳサーバ（１００）の動作方法（４０）を示すために使用される。この時、図４の簡略化されたフローチャートは基本的なステップ（４１、４２、４３）を示し、それらステップは図５、図６及び図７において更に詳細に示される。
【００５２】
ステップ４１において、ユーザの未登録アイデンティティサービスを判定するために、提供されるアイデンティティサービスはユーザ毎のＲＯの内容と比較してチェックされ、アイデンティティサービスはＤＳサーバに格納される。ステップ４２において、ＳＰが、未登録アイデンティティサービスを提供するために選択される。ここで、この包括的なステップは、上述のように、サービス機能記憶領域（１０３‐２、３０１）のチェック（４２‐Ｑ、４２‐Ｒ）を含んでもよい。最後に、ステップ４３において、この時点までにユーザに対して未登録のアイデンティティサービスは、そのサービスに対して対応するＲＯを格納することにより、ＤＳサーバ（１００）に登録される。これにより、前記ＤＳサーバから前記アイデンティティサービスへのアクセスが可能になる。
【００５３】
図５は、ユーザの未登録アイデンティティサービスの存在に関する初期評価をＤＳサーバ（１００）によって行ない、且つ必要に応じてサービスにアクセスできるように、サービスの登録を可能にする更なる動作を行なういくつかのステップを示す。図５のステップ４１１及び４１３を参照して説明されるように、この初期評価は、機能登録（ＣＡＰ‐ＵＰＤ）がＳＰから受信された時又はサービス機能記憶領域（１０３‐２、３０１）の周期的なチェックの際に行なわれる。別の方法も可能であり、それら別の方法において、いくつかのユーザのＲＯに対するチェックは、例えば、各ユーザ又はユーザのグループに関連付けられる特定のサービスの種類のパラメータ、あるいはアイデンティティサービス毎に関連付けられる同様のパラメータに依存して、その時点で実行されてもよく、又は、後で実行するように遅延されてもよく、あるいは実行されなくてもよい。例えば、特定のユーザは、ＤＳサーバにおいて登録処理のトリガが初期段階で（例えば、アイデンティティサービスがＤＳクエリで明示的に要求される前に）実行されるか、或いは後で実行されるかを提示する本発明によるアイデンティティサービスのアクセス権を自動的に提供するために、サービスの種類に関連付けられてもよい。同様に、ＤＳサーバへの登録のトリガは先の段階で実行されるのが好ましいか否かを提示する特定のアイデンティティサービスと関連するパラメータ（これは、機能登録の追加データとして受信され、サービス機能記憶領域に格納される）が存在してもよい。
【００５４】
従って、サービス機能更新の受信（４１１）後又はサービス機能記憶領域の周期的なチェック（４１３）後に実行される未登録アイデンティティサービスを判定するための評価は、１つ以上のアイデンティティサービス及び１つ以上のユーザに対して実行される。しかし、その評価は、いくつかの他のサービス又はユーザに対しては、後で（例えば、ＤＳクエリを受信した際、又はＤＳサーバにおいてユーザ通信を受信した際に）実行されてもよい。
【００５５】
ステップ４１１において、機能登録メッセージ（ＣＡＰ‐ＵＰＤ）は、ＤＳサーバ（１００）においてＳＰから受信される。次に、ステップ４１２において、サービス機能記憶領域（１０３‐２）の内容は、受信メッセージの内容で更新される。別の実現例は、ステップ４１４への遷移により示されるように、この時点で未登録のアイデンティティサービスに対するチェックを行なうことを含む。例えば、機能登録メッセージがＳＰ１４０から受信され、新しいアイデンティティサービス（例えば、ＩＤＳＲＶ‐Ｘ）を提供できることを報告すると仮定する。ステップ４１４は、そのアイデンティティサービスが１つ以上のユーザに対して既に登録されているか否かを判定するために、ＤＳにおいて前記１つ以上のユーザのＲＯをチェックすることを含む。これは、そのアイデンティティサービスのサービスの種類の識別子がＲＯに含まれるかを１つ以上のＲＯにおいてチェックすることにより達成されてもよい。同様に、機能登録メッセージ（４１１、ＣＡＰ‐ＵＰＤ）は、ＳＰ１３０から受信され、例えば、それまでにＳＰ１３０が提供していたアイデンティティサービス（例えば、ＩＤＳＲＶ‐Ａ）の停止を報告してもよい。この場合、ステップ４１４のチェックにより、影響を受けるＲＯ（例えば、ＲＯ２Ａ）が与えられ、それにより、ユーザに対して先に登録されているアイデンティティサービス（例えば、ＵＳＲ‐２に対するＩＤＳＲＶ‐Ａ）をこの時から未登録とすることができる。
【００５６】
あるいは又はそれに加えて（上述のように、特定の処理動作が行なわれるいくつかのユーザ又はアイデンティティサービスが存在する場合）、未登録アイデンティティサービスを判定するためのチェックは、ステップ４１３により示されるように、サービス機能記憶領域（１０３‐２、３０１）の周期的なチェックが実行されるまで遅延される。ユーザの未登録アイデンティティサービスを判定する目的で行なわれるサービス機能記憶領域の周期的なチェックは、トラフィック及びサービス需要が低いと考えられる特定の時間に後続の提供処理を実行させることができるため有利である。ステップ４１３の後続するチェックを実行する周期は、例えば、毎日特定の時間にチェックを実行するようにセットアップされてもよく、あるいは、例えば、ＤＳサーバで測定された最近の信号トラフィックに依存して動的にセットアップされてもよい。いずれの場合においても、サービス機能記憶領域（１０３‐２、３０１）の周期的なチェックにより、特定のＳＰが新しいサービスを提供することを報告する時期、又は、ＳＰが古いサービスの提供を停止することを報告する時期に依存しないＤＳサーバに未登録アイデンティティサービスを登録するための登録処理の非同期トリガが可能になる。更に、前記周期的なチェックにより、複数のユーザの未登録アイデンティティサービスに対するバッチ処理を容易にしてもよい。
【００５７】
あるユーザに対して登録されていないアイデンティティサービスを評価するためのチェックは、サブフロー「Ａ」、「Ｂ」及び「Ｃ」で示されるように更に遅延されてもよい。例えば、ＤＳサーバ（１００）は、ＤＳクエリの受信を待つか（ステップ４１８により示される）、あるいは当該ユーザからの通信を待つ（ステップ４１７により示される）ことができる。そのＤＳクエリ、又は、通信は、未登録アイデンティティサービスの登録を開始することに対するユーザの同意をＤＳサーバから取得するために使用されるか、あるいは前記登録を実行するのに使用されるユーザデータ及び基本設定を収集するために使用される。
【００５８】
ステップ４１４のチェックが実行され、アイデンティティサービス（例えば、ＩＤＳＲＶ‐Ｘ）が特定のユーザ（例えば、ＵＳＲ‐２）の未登録アイデンティティサービスとしてステップ４１５において見つけられると仮定すると、上記処理の代わりとなる次に説明する種々の処理が存在する。
【００５９】
ステップ４１６において、当該ユーザに対する通信を確立するための要求を送信させる処理が選択される。例えば、未登録アイデンティティサービスの登録を開始することに対するユーザの同意をＤＳサーバから取得するために、或いは、前記登録に対してユーザデータ基本設定、同意等を収集するために、サービス登録を開始する前にユーザと対話する目的で要求が送信される。前記要求は、異なるベアラを介して送信されてもよく、ＤＳサーバは、前記要求に対処するために、ユーザについて認識する識別子を使用でき、又は別のサーバエンティティから（例えば、ＩＤＰから）識別子を取得できる。例えば、要求は、ユーザの移動電話番号に送信されるショートメッセージ（ＳＭＳ）で搬送されるか、あるいはユーザのメールＵＲＬに送信される電子メールで搬送される。要求は、ＤＳサーバのサービスポイントにマップするＵＲＬを含んでもよく、あるいは（例えば、ユーザがＤＳサーバへのアクセス方法を知っている場合）ユーザがまだ加入していない新しいアイデンティティサービスが利用可能であることをユーザに警告するテキストを搬送してもよい。
【００６０】
あるいは、先に示したように、ＤＳサーバは、ＤＳクエリの受信を待つことができ（ステップ４１８）、あるいは当該ユーザからの通信を待つことができる（ステップ４１７）。ここで、ユーザからの前記通信は、ＤＳサーバから送信される先の通信要求の結果として受信されてもよく（ステップ４１６）、あるいはＤＳサーバにおいてユーザから受信される自発通信でもよい。後者の例は、例えば、ユーザがユーザの登録アイデンティティサービスに関連するアクセスポリシーをセットアップするためにＤＳサーバと通信する（例えば、ＤＳサーバが提供するウェブページを介して）際に起こる可能性がある。
【００６１】
図５のステップ４２及び４３（図４の簡略化されたフローにおいて示されるステップ４２及び４３に対応する）は、簡単な実施形態に従って、ステップ４１４及び４１５において検出される未登録アイデンティティサービスを提供するＳＰを選択すること及びユーザに対して登録するためにＤＳサーバ（１００）において対応するＲＯを提供することをそれぞれ表す。本実施形態は、ユーザの介入及び選択されたＳＰとの通信を要求しない。また、本実施形態は、前記ＳＰにより前記ユーザに対して提供される際に前記アイデンティティサービスに対するＲＯを直接形成するために、ＤＳサーバがユーザ及びＳＰデータに対するアクセス権を有してもよいという状況に適する。例えば、前記データの一部は、機能登録メッセージにおいてＳＰから受信され、他のデータは、同一のＳＰにおける同一のユーザに対する別のアイデンティティサービスの登録に関連付けられて再利用されてもよい。この場合（しかし、それに限定されない）、ステップ４２において、当該ユーザが既に周知である（例えば、ユーザがＳＰに対するサービスアカウントを既に有するか、あるいはＳＰが前記ユーザに対して別のアイデンティティサービスを既に供給している）ＳＰが選択されるのが好ましい。
【００６２】
更に別の処理方法（図５には示さない）は、ステップ４１４及び４１５の判定後に選択されてもよい。その方法は、ＤＳサーバと選択されたＳＰとの間の通信を含むが、ユーザの介入を要求せず、またＤＳサーバが未登録アイデンティティサービスに対応するＲＯを要求するＤＳクエリの受信を待つ必要がない。この方法を達成する処理ステップについては、図６に示すステップを参照して後述する。
【００６３】
図６に示されるフローは、ユーザからの通信が受信された時にＤＳサーバ（１００）により実行されるいくつかの処理ステップを示す。先のサブフロー「Ａ」及び「Ｂ」により示されるように、ユーザからの通信は、ＤＳサーバ（４１６）からユーザに先に送信される要求の結果であってもよく、あるいはＤＳサーバにおいてユーザから受信される自発通信であってもよい。
【００６４】
ステップ４２０において、ユーザの通信（例えばＨＴＴＰ「Get」メッセージ）は、ＤＳサーバ（１００）において受信される。次に、ステップ４２１において、ユーザの登録アイデンティティサービスに対するユーザのために格納されたＲＯについてのチェックは、ユーザに提供され、かつ、まだ登録されていない１つ以上のアイデンティティサービスに対して実行される。未登録アイデンティティサービスがそのユーザに対して発見された場合（ステップ４２２）、ステップ４２３において、ＳＰが選択されてもよい。上述のように、サービス機能記憶領域（１０３‐２、３０１）のチェックは、未登録アイデンティティサービスの判定及び後続のＳＰの選択の際に評価するために使用されてもよい。
【００６５】
単純な実現例は、ＤＳサーバ（１００）における後続する対応するＲＯの提供及び格納（ステップ４３）で構成される。これは、図５のステップ４２及び４３を参照して上述したように達成される。
【００６６】
ＳＰを選択するためのステップ４２３において実行されるサービス機能記憶領域（１０３‐２、３０１）に対するチェックの結果、２つ以上のＳＰが当該アイデンティティサービスを提供するために発見されてもよい。この場合の適切な解決策は、ユーザが既にサービスアカウントを有する１つのＳＰを選択することを含んでもよい。例えば、ステップ４２３において発見されたＳＰのうちの１つと一致するＳＰを見つけるために、ＤＳサーバにおいて、検索がユーザのために格納された他のＲＯに対して実行される。２つ以上のＳＰがその条件を満たし、実現例のオプションとして、ＤＳサーバはそれらＳＰのうち任意のＳＰを直接選択できる。ステップ４２３において、当該アイデンティティサービスを供給するのに適切なＳＰとして見つけられたＳＰがユーザからのある特定のサービス専用関連データ（例えば、言語基本設定、個人の住所、クレジットアカウント番号等）の収集をＤＳによって行なうことを提示した（例えば、そのサービスに対する機能登録の際）ことが発見される。更に、未登録アイデンティティサービスの登録をトリガする前に明確なユーザの同意を取得することが要求される場合がある。
【００６７】
従って、そのような場合（選択可能なＳＰが複数存在する場合、ユーザの同意が必要とされる場合、サービスデータ収集が指示される場合）、複数のＳＰの中から１つのＳＰを選択するようにユーザに指示し、それらサービス関連データの一部又は全てを入力するようにユーザに指示することが望ましい。ステップ４２４において、通信はその目的でユーザに送信され、ステップ４２５において、ユーザからの通信はその結果として受信され、それは、サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）とサービス関連データ（ＳＲＶ‐ＤＡＴ）との少なくともいずれかを含むことができる。また、ユーザに送信される通信要求（４１６、４２４）において（又は、前記ユーザに対して確立された通信において）、ＤＳサーバは、前記プロバイダ基本設定（ＳＰ‐ＰＲＥＦ）とサービス関連データ（ＳＲＶ‐ＤＡＴ）との少なくともいずれかを入力するように前記ユーザに指示してもよい。サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）は、異なる形式であってもよく、ユーザの同意であると仮定されてもよい（しかし、その目的に対する特定のアサーションは、ユーザ通信４２５においても使用できる）。例えば、ユーザが複数のＳＰのＵＲＩを含むリストを受信した場合、サービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）は、それらＳＰのうち１つのＳＰのＵＲＩを含むことができる。また、ユーザは好適なドメイン（例えば、「xzy.com」）を指示することができ、それにより、ＤＳサーバはそのドメインに属する適切なＳＰを選択する。更に、ユーザは、選択可能なＳＰのうち「任意」のＳＰが選択されてもよいことを指示でき、この場合、ＤＳサーバは任意の更なる基準（例えば、完全ランダム、より負荷の少ないＳＰ等）に従って１つのＳＰを自由に選択できる。次に、ステップ４２６において、ユーザが提示した基本設定に従ってＳＰが選択される。
【００６８】
上述のように、選択されたＳＰが当該ユーザを知っているのが好ましい場合がある。アイデンティティ連携フレームワークにおいて、一般にその知識は、ユーザが前記ＳＰに対して連携サービスアカウントを有することを示し、その結果、それらフレームワークにおいて周知の機構に従って、ユーザに対するユーザ識別子が前記ＳＰと中央供給エンティティ（例えば、既に説明したように、同一のサーバマシン内に共に配置されて使用するＩＤＰサービスを提供するサーバエンティティ又はディスカバリサービスＤＳを提供するサーバエンティティ）との間で共有されることを示す。プライバシーの理由から、一般に「ユーザ別名」として知られる前記ユーザ識別子は、異なるＳＰ間では同一ユーザに対しても異なる。
【００６９】
ステップ４２７は、選択されたＳＰにおいてユーザが周知であるか否か（又は、換言すると、例えばユーザがＳＰを介してアイデンティティを連携したために、ＳＰがユーザを知っているか否か）を考慮するＳＰ選択処理の一部を集約する。ユーザが選択されたＳＰにより既に知られている場合、前記ＳＰと共有される前記ユーザのユーザ別名は、前記ＳＰとの更なる通信の際に前記ユーザを参照するために選択される。あるいは、ユーザは、選択されたＳＰにおいて連携される必要があり、これは、例えば、図６の後続するステップを参照して説明される別の方法のうち１つを使用して達成されてもよい。
【００７０】
ユーザが選択されたＳＰに対して周知であるか否かに関わらず、未登録アイデンティティサービスの登録を完了し、次にＤＳサーバにおいて対応するＲＯを提供するための２つの基本的なモードが存在する。それらモードは、選択されたＳＰとの通信がＲＯを提供するために必要とされる時、又は、要求される時に常に存在する。
【００７１】
ステップ４２８Ａは、選択されたＳＰにユーザをリダイレクトすることを示す第１のモードを表す。これは、例えば、当該アイデンティティサービスを提供するウェブサービスプロバイダ（ＷＳＰ）として動作するように選択されたＳＰ（例えば、１４０）に対して、ユーザ（１５０）とＤＳサーバ（１００）との間に確立された通信をリダイレクトするＨＴＴＰ「redirect」により達成されてもよい。ステップ４２８Ｂは、ＤＳサーバ（１００）と選択されたＳＰ（例えば、１４０）との間の直接通信の確立（例えば、サーバエンティティ間の通信に対する所謂「バックチャネル」に対して、ＳＯＡＰ等の周知のプロトコル・バインディングを使用する）を示す第２のモードを表す。
【００７２】
ステップ４２８Ａ及び４２８Ｂの通信は、実際には、それら通信を受信するＳＰからアイデンティティサービスを提供するための要求であり、特に、未登録アイデンティティサービスの登録が要求されることを提示する特定のコードと、当該アイデンティティサービスの識別子と、ＤＳサーバにおいて当該ユーザを識別するのに使用可能な識別子（例えば、そのユーザに対するＲＯ‐ＤＳ）とを含んでもよい。それら通信は、ユーザから収集されたサービス関連データ（ＳＲＶ-ＤＡＴ）を更に含んでもよく、選択されたＳＰから機能登録メッセージで受信された（４１１）サービスエントリポイントの識別子を使用すること又は含むことにより対処される。ステップ４２８Ｂに対して使用された用語「直接通信」は、間にいくつかのルーティングエンティティを含んでもよいＤＳサーバと選択されたＳＰとの間に確立された通信を含み、ステップ４２８Ａのようにリダイレクション要求に埋め込んで提供の要求を送信するような「間接的」な方法とは対照的であることを理解するべきである。
【００７３】
ユーザが選択されたＳＰにおいて周知である場合、そのＳＰにおけるユーザの共有される（連携される）ユーザ別名は、ステップ４２８Ａ又は４２８Ｂにおいて送信される要求に含まれてもよい。ユーザが選択されたＳＰにおいて周知でない場合、ＤＳサーバは、ユーザに対してダミーの識別子（あるいは、「デフォルト」として合意された他の指標又はデフォルトとして認識される指標）を含んでもよい。ダミーの識別子は、受信機ＳＰにおいて、前記ＳＰから前記ユーザのアイデンティティを連携する必要があると解釈される。例えば、ユーザが選択されたＳＰに対してリダイレクトされる場合（４２８Ａ）、ＤＳサーバは、ユーザに対してダミーの識別子を含んでもよい（又は識別子を含まなくてもよい）。従って、選択されたＳＰがユーザを識別できないため、ＳＰは、ユーザが既にサービスアカウントをそのＳＰに対して有するかを調査するために又はそのＳＰにおいて新しいアカウントを作成するためにユーザと対話してもよい。その後、ＳＰは、ユーザ連携を要求し（例えば、認証要求メッセージをＩＤＰに対して送信する）、ＩＤＰは、特にユーザ別名及びそのユーザに対するＤＳサーバと通信するための情報（すなわち、更なるＤＳクエリ、又は、ＤＳ更新のためのユーザに対するＲＯ‐ＤＳ）を返す。あるいは、ＤＳサーバは、ユーザに対して事前に割当てられた別名を作成し、且つ、選択されたＳＰと関連付けてＩＤＰ（９０）に格納するために、必要なステップを行なってもよい（図６においては詳細に示さないが、ステップ４２７において実行されると考えられる）。ここで、前記別名は、対応するＲＯ‐ＤＳと共に提供の要求において送信されてもよい（４２８Ａ、４２８Ｂ）。いずれの場合においても（ユーザが選択されたＳＰにおいて周知であるか又は周知でない場合）、選択されたＳＰはユーザと対話する必要がある（例えば、サービスを最終的に提供するために必要とされる更なるデータを収集するため）。従って、当該ユーザと選択されたＳＰとの間の更なる対話が必要とされる（予測される）場合には、ステップ４２８Ａのリダイレクトする方法が選択されるのが好ましい。
【００７４】
ステップ４２８Ａ又は４２８Ｂにおける選択されたＳＰに送信される未登録アイデンティティサービスの提供の要求の結果、ステップ４２９において、ＤＳ更新（又は他の同等のメッセージ）は前記ＳＰから受信され、ＤＳ更新は前記ＳＰにより形成されたＲＯ（ＲＯ２Ｘ）を含む。これを達成するために、ＳＰにおける処理手段は、ユーザがＳＰと接続する（図２のフロー２０１）時の方法と同様の方法でＤＳサーバから行なわれるアイデンティティサービスの提供の要求に応答するように変更されてもよく、それにより、同様の要求を行なう（２０２、４２９）。あるいは、ＲＯ又はＲＯを形成するのに使用可能なデータを搬送できる限り、特定のメッセージが、一般に使用されるＤＳ更新の代わりに使用されてもよい。その後、ステップ４３０において、受信されたＲＯはＤＳサーバにより格納される。それにより、これまでに未登録のアイデンティティサービスを登録し、ＲＯを使用して更なるＤＳクエリに対して応答することが可能になる。そのＤＳクエリは、前記ユーザの前記アイデンティティサービスに対するアクセス権を要求するために、最終的に前記ＤＳサーバにおいて受信されてもよい。
【００７５】
尚、上記ステップ４２３、４２７及び４２８Ｂに対応する実行フローは、未登録アイデンティティサービスが先の段階（図５のステップ４１４及び４１５）で検出された場合にＲＯを提供するための別の実行方法を構成する。これは、ユーザの介入を必要としない。従って、例えば、機能登録後（ステップ４１１）又はサービス機能記憶領域の周期的なチェック後（ステップ４１３）に、ユーザの未登録アイデンティティサービスがユーザの介入なく先の段階で検出された場合、ＤＳサーバは、適切なＳＰを選択し、前記アイデンティティサービスの提供の要求を前記ＳＰに直接送信できる（ステップ４２８Ｂ）。これは、ＳＰからの後続するＤＳ更新において受信される対応するＲＯ（ＲＯ２Ｘ）（ステップ４２９）を格納する（ステップ４３０）ことで終了する。
【００７６】
図７に示されるフローチャートは、ＤＳクエリがＳＰから受信された時（ステップ４２１０）にＤＳサーバ（１００）により実行される処理ステップを示す。ウェブサービスコンシューマ（ＷＳＣ）として動作する前記ＳＰは、ユーザのアイデンティティサービスに対するアクセス権を要求し、前記アイデンティティサービスは、前記ユーザに対してまだ登録されていない。上述のように、それら処理ステップは、本発明のＤＳサーバが何らかの理由によりユーザの未登録アイデンティティサービスの登録を遅延させた場合（例えば、ＤＳクエリを待つという条件がユーザ又はサービスに対して設定されている場合、更新されたサービス機能記憶領域の周期的なチェックが行なわれる前にＤＳクエリが受信される場合、未登録アイデンティティサービスのバッチ処理がいくつかのユーザに対して待ち状態である場合等）に実行される。
【００７７】
ステップ４２１１及び４２１２は、最新技術によるＤＳにおける現在の処理を表してもよい。これは、背景の節で提示したように、受信されたＤＳクエリにおいて指示されるアイデンティティサービスが、関連するユーザに対して格納された任意のＲＯに対応するかを判定するためのチェックを示す。要求されたアイデンティティサービスが前記ユーザに対するＤＳサーバに登録されていない場合に本発明に従って処理するための３つの別の方法を図７に示す。
【００７８】
第１の方法（ステップ４２１３Ａ）において、リダイレクション要求は、ＤＳクエリを送信したＳＰに送信され、ユーザをＤＳサーバにリダイレクトするように要求する。リダイレクション要求は、ＤＳ応答内に埋め込まれて送信されてもよく、あるいはリダイレクトすることを要求する別の種類のメッセージで送信されてもよい。リダイレクション要求は、ＤＳサーバのサービスポイントにマップするＵＲＬを含むことができる（ステップ４１６の通信の場合と同様）。第２の方法（ステップ４２１３Ｂ及び４２１４Ｂ）において、ＤＳサーバは、ステップ４１６を参照して先に説明したように、当該ユーザに対する通信を確立するための要求を送信してもよい。この第２の方法において、ＤＳサーバは、ＲＯを含まないＤＳ応答を送信してもよく（ステップ４２１３Ｂ）、あるいは要求されたアイデンティティサービスの対応するＲＯが利用可能になるまでＤＳ応答を待ち状態にしてもよい。第３の方法は、対応するＲＯの提供及び格納のためにユーザの介入も選択されたＳＰとの通信も必要としない簡単な実施形態に対応する。簡単な本実施形態の処理ステップは、サブフロー「Ｅ」への遷移により示され、図６の適切なＳＰの選択を行なうステップ４２３、並びに生成されたＲＯの提供及び格納を行なうステップ４３に継続する。これは、サブフロー「Ｄ」により示されるように図７のステップ４２１６Ｂに戻り、生成されたＲＯ（ＲＯ２Ｘ）を含むＤＳ応答は、ＤＳクエリを送信したＳＰに送信される。
【００７９】
個別には示さないが、第４の方法がステップ４２１２の後に選択される。これは、ユーザとの通信の確立を必要とせず、図６を参照して上述したステップ４２３、４２７、４２８Ｂ、４２９及び４３０の実行を含む。この方法の実行は、遷移「Ｇ」を介して図７に示す処理フローに継続する。
【００８０】
上述の最初の２つの方法（それぞれステップ４２１３Ａ、及びステップ４２１４Ｂ（ステップ４２１３Ｂに先行する又は先行しない））の場合、実行フローはユーザ通信の受信に継続する（図６のフロー「Ａ」への遷移により示される）。これは、図６に示す処理フローを参照して上述したように処理される。遷移「Ｇ」及び「Ｆ」により指示されるように、実行フローは図７に戻る。ここで、提供の要求が選択されたＳＰに直接送信された場合（図６のステップ４２８Ｂ）、実行フローは直接継続し（フロー「Ｇ」）、あるいは提供の要求がリダイレクションで送信された場合（図６のステップ４２８Ａ）、実行フローは、ステップ４２１５において、選択されたＳＰから受信されるリダイレクションの受信を待つ（フロー「Ｆ」）。選択されたＳＰから受信されるリダイレクションは、ＳＰが生成したＲＯ（ＲＯ２Ｘ）を含んでもよく、これは、受信された提供の要求の結果として前記ＳＰが送信したＤＳ更新の送信（ステップ４２９）を不必要にするオプションとなる。また、ステップ４２１５において受信されるリダイレクション及びステップ４２９において受信されるＤＳ更新（又は同等のメッセージ）は、アイデンティティサービスが示すリソースに対して、供給されるユーザがアクセス、管理等を行なうことを容易にするためのデータを含んでもよく、それらデータは後続する通信（例えばカレンダのチェックを容易にする又は個人データを変更するなど、当該リソースのアクセス又は管理に対処するのに使用可能なＵＲＬ等）を介してユーザに配信されてもよい。
【００８１】
ステップ４２１５の後又は遷移サブフロー「Ｇ」の後、２つの処理方法が選択される。第１の方法は、ステップ４２１６Ｂにより示されるように、選択されたＳＰから受信されたＲＯを含むＤＳ応答の送信を含む。また、実行はステップ４２１６Ａに継続してもよく、ステップ４２１６Ａにおいて、ユーザはＤＳクエリを送信したＳＰにリダイレクトされる。後続するステップ４２１７Ａ及び４２１８Ａにより示されるように、ＷＳＣとして動作するＳＰ（すなわち、アイデンティティサービスの呼出しを介して前記ユーザのアイデンティティのリソースの消費を必要とするサービスをユーザに供給するＳＰ）からの後続するＤＳクエリは、対応するＲＯ（ＲＯ２Ｘ）を使用して正常に返答されてもよい。
【００８２】
図５〜図７を参照して上述したいくつかの処理ステップに対応する信号フローを図８及び図９に示す。それら信号フローは、ＤＳサーバからユーザの未登録アイデンティティサービスに対するアクセス権を提供する例を示すために使用される。ここで、前記提供は、ＤＳクエリの受信の際に実行される。
【００８３】
図８のフロー４１１において、機能登録は、ＤＳサーバ１００においてＳＰ１４０から受信される。例えば、ＳＰ１４０は、ＩＤＳＲＶ‐Ｘ等のアイデンティティサービスを今後提供できることを報告する。ＤＳサーバは、ＳＰ１４０がそのアイデンティティサービスを供給できる（図３に示す）ことを提示するために、サービス機能記憶領域（１０３‐２）を更新する（４１２）。図５〜図７を参照して上述したように、ＤＳサーバは、機能登録において受信された更新により、いくつかのユーザに対して未登録である（又は未登録となった）アイデンティティサービスの提供を開始できる。しかし、上述のように、図８及び図９で示される例において、ＤＳサーバ１００が、ユーザに対応する未登録アイデンティティサービスのＲＯの不足を示すＤＳクエリの受信を待つ場合の例が示される。
【００８４】
その後フロー２０４において、ユーザ１５０は、ＳＰ１１０にアクセスし、特定のサービスを要求する。簡単にするため、ユーザ１５０と、アクセスされたＳＰ１１０と、認証アサーションをＳＰ１１０に提供するＩＤＰ９０との間で一般に実行される認証フローは、図８及び図９には示さない。ＳＰ１１０においてユーザ１５０によりアクセスされるサービスは、例えば、ユーザのカレンダの更新を含む追加サービスを提供するフライト予約サービスであってもよい。これは、ＳＰが他のＳＰ、すなわちリソースに対してＷＳＰとして動作するＳＰにより提供される前記ユーザのリソース（この場合、カレンダデータ）に対するアクセス権をアイデンティティサービスを介して取得する必要があるため、ＳＰは前記追加サービスを提供するためにＷＳＣとなる必要があることを示す。従って、ＳＰ１１０は、ユーザに対して格納されたＲＯに対処するためのリソース識別子及び要求されたアイデンティティサービスの種類の識別子を含むＤＳサーバにＤＳクエリを送信する（フロー４２１０）。この例を示す目的で、「ＩＤＳＲＶ‐Ｘ」が「カレンダ」サービスを識別するために設定されたサービスの種類の識別子であると仮定される。受信されたＤＳクエリはＤＳサーバにおいて処理され（Ｃ）、例えば、ＤＳサーバ記憶領域１０３-１に格納されたサービス（ＩＤＳＲＶ‐Ｘ）及びユーザ（１５０）に対するＲＯが存在しないことが分かる。上述のように、ＤＳサーバは、ユーザに対してアイデンティティサービスＩＤＳＲＶ‐Ｘを登録するために対応するＲＯを提供することを続行する前に、ユーザ１５０と対話してもよい（Ａ）。
【００８５】
図８は、ＤＳサーバ１００が選択されたＳＰ１４０に対して提供の要求を送信する（フロー４２８Ｂ）上述の可能な方法を示している。その結果、ＤＳ更新（フロー４２９）は、そのユーザ及び指示されたサービス（例えば、ＲＯ０２Ｘ）に対するＲＯを搬送するＳＰ１４０から受信され、それは、ユーザに対するＤＳサーバによりＲＯ記憶領域（１０３‐１）に格納される（４３０）。次にＤＳサーバは、最近登録されたＲＯ（ＲＯ０２Ｘ）を含む受信されたＤＳクエリ（フロー４２１０）に対するＤＳ応答を送信する（フロー４２１６Ｂ）。その後、ＷＳＣとして動作するＳＰ１１０は、受信したＲＯ（ＲＯ０２Ｘ）のデータを使用して、ＳＰ１４０にアクセスする（フロー２０７）。ＳＰ１４０は、要求されたアイデンティティサービスを供給するＷＳＰとして動作する。ＳＰ１１０がＳＰ１４０に対して要求する動作の種類に応じて（本質的にはサービスに対して規定された動作におけるサービスの特質に応じて）、ＷＳＣ（ＳＰ１１０）とＷＳＰ（ＳＰ１４０）との対話は、図８に示す１往復以上の通信を含んでもよい。例えば、フロー２０８は、単純な動作（例えば、カレンダデータの読出し又は更新）に対する応答を表してもよいが、より複雑な動作に対しては、より多くの信号フローが存在するだろう。
【００８６】
図９のフロー４１１、２０４及び４２１０は、図８を参照して説明されたように実行され且つ処理される。しかし、図９は、ＳＰ１４０に提供の要求を送信するための別の方法及びユーザと接続するための方法を示す。
【００８７】
フロー４２１３Ａにおいて、リダイレクションがＳＰ１１０に送信される。リダイレクションは、前記ＳＰが有するユーザ１５０との通信をＤＳサーバ１００に対してリダイレクトすることを要求し、ＤＳサーバと接続するために使用可能な参照情報（例えば、ＤＳサーバのサービスポイントにマップするＵＲＬ）を含んでもよい（例えば、ユーザにとってＤＳサーバが不明であると考えられる場合）。ユーザは、その後リダイレクトされ、ＤＳサーバとの通信を開始する（フロー４２０）。ＤＳサーバは、例えばユーザ基本設定を収集してＳＰを選択するために又は提供されるサービスに対するサービス関連データを収集するために、ユーザ１５０と対話してもよい（Ａ）。ユーザ１５０との通信は、選択されたＳＰ１４０にリダイレクトされる（フロー４２８Ａ）。ユーザ１５０とＳＰ１４０との間の後続する通信は、特に、他のいくつかの実施形態に従ってＤＳサーバにより収集される先に参照されたデータと同一の種類のデータを収集するため、又は前記データの収集を完了するために使用されてもよい（例えば、ＤＳサーバが必要な全てのデータをユーザから収集しなかった場合）。
【００８８】
その後、ＤＳ更新（フロー４２９）は、ユーザ及び指示されたサービス（例えば、ＲＯ０２Ｘ）に対するＲＯを搬送するＳＰ１４０から受信され、図８の先の例のフローと同様に、ユーザに対するＤＳサーバによりＲＯ記憶領域（１０３‐１）に格納される（４３０）。ＳＰ１４０は、ユーザ１５０との通信をＤＳサーバ１００にリダイレクトする（フロー４２１５）。上述のように、このリダイレクションは、生成されたＲＯ（ＲＯ０２Ｘ）を搬送してもよく、それによりＤＳ更新の送信（４２９）を不必要にする。ＤＳサーバにおけるユーザとの通信は、クエリしているＳＰ１１０に対してリダイレクトされる（フロー４２１６Ａ）。ここで、前記リダイレクションは、アイデンティティサービスが提供されたことを示す指標、又は、要求されたアイデンティティサービスにアクセスするのに使用可能な対応するＲＯ（ＲＯ２Ｘ）を含んでもよい。あるいは、それら連鎖リダイレクションは、ＳＰ１１０にアドレス指定された戻り情報を含むことにより低減される。それにより、ＳＰ１４０は、ユーザを直接ＳＰ１１０に対してリダイレクトすることが可能になる（これは、ＤＳ更新の送信４２９を必要にするだろう）。
【００８９】
図９に示される後続するフローは、ＲＯがＳＰ１１０に送信されていないことを考慮する。フロー４２１７Ａにおいて、ＤＳクエリが受信され、新しく登録されたＲＯ（ＲＯ０２Ｘ）を要求する。これに対して、フロー４２１８Ａにおいて、ＤＳサーバ１００からＤＳ応答で返答される。後続するフロー２０７及び２０８は、図８を参照して説明したように実行される。
【００９０】
図７又は図８には示さないが、例えばユーザが要求したサービスが完全に達成されたことを確認するために、要求したアイデンティティサービスにＳＰ１１０からアクセスした結果、ＳＰ１１０とユーザ１５０との間で更なる対話が行なわれる。上述の例に続き、ＳＰ１００は、ユーザ１５０のカレンダが更新されたことをユーザ１５０に更に指示してもよい。
【００９１】
最新技術の通信システムにおけるサーバエンティティは、一般に、コンピュータを使用するマシンにおいて実現される。従って、コンピュータ可読プログラムコードを含むコンピュータプログラムは、通信システムのコンピュータを使用するサーバエンティティにロードされ、それにより、前記サーバエンティティの各々は、それぞれの特定の機能性に従った所定の方法に応じて動作する。当業者は、コンピュータを使用するＤＳサーバにロードされることを意図されたコンピュータプログラムについて、作成と変更との少なくともいずれかを行う際、本発明の範囲から逸脱せずに、コンピュータプログラムの作成と変更との少なくともいずれかを行うのにそれら技術を容易に適用できる。それらコンピュータプログラムは、コンピュータを使用するＤＳサーバにおいて実行される際、ＤＳサーバを上述の任意の実施形態に従って動作させる。
【００９２】
例示としての限定しない方法で、いくつかの好適な実施形態に関して本発明を説明した。当業者には、種々の変形例が容易に理解される。そのため、本発明は、請求の範囲を考慮して解釈され限定される。
【図面の簡単な説明】
【００９３】
【図１】最新技術によるアイデンティティ連携フレームワークにおける協働するいくつかのエンティティを示す概略図である。
【図２】ディスカバリサービスサーバにおいてアイデンティティサービスをサービスプロバイダから登録し、前記アイデンティティサービスにアクセスする最新技術による簡略化された信号フローを示す図である。
【図３】図１に示される図と同様の図であり、本発明によるいくつかの機能モジュール及びディスカバリサービスサーバのデータ内容を概略的に示す図である。
【図４】本発明による方法を示す簡略化されたフローチャートである。
【図５】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図６】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図７】図４の簡略化されたフローチャートに示されるステップの実施形態を示す詳細なフローチャートである。
【図８】図５〜図７のフローチャートに示される実施形態のうちいくつかの実施形態に対応する簡略化された信号フローを示す図である。
【図９】図５〜図７のフローチャートに示される実施形態のうちいくつかの実施形態に対応する簡略化された信号フローを示す図である。
【特許請求の範囲】
【請求項１】
ディスカバリサーバ（１００）からユーザのアイデンティティサービスに対するアクセス権を提供する方法であって、
ａ）前記ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を前記ディスカバリサービスサーバに格納するステップ（２０３）であって、前記アイデンティティサービスはサービスプロバイダ（１３０）により提供され、前記リソースオファリングは前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有する、ステップと、
ｂ）前記ユーザのリソースオファリングを取得するために、前記ディスカバリサービスサーバにおいてディスカバリサービスクエリを受信するステップ（２０５）と、
ｃ）前記ユーザの登録アイデンティティサービスのリソースオファリングを含むディスカバリサービス応答で前記クエリに返答するステップ（２０６）と、
を備え、
ユーザの未登録アイデンティティサービスに対するアクセス権を前記ディスカバリサービスサーバから提供するために、
ｄ）前記ユーザの前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を前記ディスカバリサービスサーバから選択するステップ（４２）と、
ｅ）前記選択されたサービスプロバイダにより提供されたときに前記ユーザの前記アイデンティティサービスを登録するために、リソースオファリング（ＲＯ２Ｘ）を前記ディスカバリサービスサーバに格納するステップ（４３）と、
を更に備えることを特徴とする方法。
【請求項２】
前記ステップ「ｄ」は、
ｄ．１）前記アイデンティティサービスを提供できるサービスプロバイダを選択するために、サービス機能記憶領域（１０３‐２、３０１）をチェックするステップ（４２‐Ｑ、４２‐Ｒ）
を備え、
前記サービス機能記憶領域は、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）と、前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）の少なくとも１つの識別子と、
を有する請求項１記載の方法。
【請求項３】
前記ステップ「ｄ．１」のチェックは周期的に繰り返される（４１３）請求項２記載の方法。
【請求項４】
ｄ．０）前記ディスカバリサービスサーバに前記サーバ機能記憶領域（１０３‐２）を格納する先行するステップを更に備え、
前記ステップ「ｄ．１」は、前記ディスカバリサービスサーバに格納された内部サービス機能記憶領域をチェックするステップを備える
請求項２又は３記載の方法。
【請求項５】
ｆ）前記ディスカバリサービスサーバにおいて、サービスプロバイダから提供されるアイデンティティサービスの識別子を有する機能登録を前記サービスプロバイダから受信するステップ（４１１）と、
ｇ）前記ディスカバリサービスサーバに格納される前記サーバ機能記憶領域（１０３‐２）を前記機能登録の内容で更新するステップ（４１２）と、
を更に備える請求項４記載の方法。
【請求項６】
前記ステップ「ｄ．１」は、
ｄ．１．１）アイデンティティサービスの識別子を有するサービス機能クエリを外部サービス機能記憶領域（３０１）に送信するステップ（４２‐Ｑ）と、
ｄ．１．２）前記アイデンティティサービスを提供できるサービスプロバイダの識別子を有する前記クエリに対する応答を受信するステップ（４２‐Ｒ）と、
を備える請求項２又は３記載の方法。
【請求項７】
ｈ）前記ディスカバリサービスサーバにおいて、第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）をユーザの前記登録アイデンティティサービスに対して登録された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定する先行するステップ（４１４、４２１、４２１１）
を更に備える請求項１から６のいずれか１項に記載の方法。
【請求項８】
前記ステップ「ｈ」は、
‐請求項１のステップ「ｂ」に記載されるように、前記ディスカバリサービスサーバにおけるディスカバリサービスクエリを受信すること（２０５、４２１０）と、
‐請求項５のステップ「ｆ」に記載されるように、前記ディスカバリサービスサーバにおけるサービスプロバイダから機能登録を受信すること（４１１）と、
‐請求項３に記載されるように、サービス機能記憶領域を周期的にチェックすること（４１３）と、
‐前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信すること（４２０）と、
から選択される少なくとも１つのステップの後に実行される
請求項７記載の方法。
【請求項９】
ｉ）前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスである場合、前記ユーザとの通信の確立の要求を前記ディスカバリサービスサーバから送信するステップ（４１６、４２１４Ｂ、４２１３Ａ）と、
ｊ．０）前記確立の要求に対する応答として、前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信するステップ（４２０）と、
を更に備える請求項７記載の方法。
【請求項１０】
ｊ．１）前記ディスカバリサービスサーバにおいて、通信において前記ユーザにより指示されるサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの前記通信を受信するステップ（４２５）を更に備え、
前記ステップ「ｄ」は、
ｄ．２）前記サービスプロバイダ基本設定に従って、前記アイデンティティサービスを提供できる複数のサービスプロバイダから１つのサービスプロバイダを選択するステップ（４２６）を備える
請求項１から９のいずれか１項に記載の方法。
【請求項１１】
ｊ．２）前記ディスカバリサービスサーバにおいて、通信において前記ユーザにより指示されるサービス関連データ（ＳＲＶ-ＤＡＴ）を有する前記ユーザからの前記通信を受信するステップ（４２５）を更に備え、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
前記ステップ「ｄ」は、
ｄ．３）前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求を前記ディスカバリサービスサーバから前記選択されたサービスプロバイダに送信するステップ（４２８Ａ、４２８Ｂ）と、
ｄ．４）前記要求の結果、前記ディスカバリサービスサーバにおいて、前記ユーザの前記アイデンティティサービスを前記ディスカバリサービスサーバに登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新を前記選択されたサービスプロバイダから受信するステップ（４２９）と、
を更に備え、
前記ステップ「ｅ」は、前記受信したリソースオファリングを前記ディスカバリサービスサーバに格納するステップ（４３０）を備える
請求項１から１１のいずれか１項に記載の方法。
【請求項１３】
ステップ「ｄ．３」で送信された前記提供の要求は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能なサービス関連データを有する
請求項１２記載の方法。
【請求項１４】
前記サービス関連データは、前記ステップ「ｊ．２」で受信した前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を有する請求項１３記載の方法。
【請求項１５】
前記ステップ「ｄ．３」は、
ｄ．３．１）前記ディスカバリサービスサーバにおいて受信された受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答に含まれる前記提供の要求を送信するステップ（４２８Ａ）と、
ｄ．３．２）前記ディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求に含まれる前記提供の要求を送信するステップ（４２８Ａ）と、
ｄ．３．３）前記ディスカバリサービスサーバから前記選択されたサービスプロバイダに前記提供の要求を直接送信するステップ（４２８Ｂ）とから選択される１つのステップと、
を備える請求項１２から１４のいずれか１項に記載の方法。
【請求項１６】
ユーザのアイデンティティサービスに対するアクセス権を提供するディスカバリサービスサーバ（１００）であって、
‐ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を格納する第１のデータ記憶領域（１０３‐１）を有するデータ記憶モジュール（１０３）であり、前記アイデンティティサービスは、サービスプロバイダ（１３０）により提供され、前記リソースオファリングは、前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有するデータ記憶モジュール（１０３）と、
‐他の通信エンティティ（１１０、１２０、１３０、１４０、１５０、３０１）と通信するために信号を交換する通信モジュール（１０２）と、
‐前記信号を処理し且つ前記データ記憶モジュールのデータの格納及び検索を制御する処理モジュール（１０１）とを具備し、
前記信号は、
‐ユーザのリソースオファリングを取得するためにディスカバリサービスクエリを受信すること（２０５）と、
‐前記ユーザの登録アイデンティティサービスのリソースオファリングが含まれるディスカバリサービス応答を送信すること（２０６）と
を少なくとも有し、
前記処理モジュールは、前記第１のデータ記憶領域の内容をチェックし且つ前記通信モジュールに前記ディスカバリ応答を送信するように指示するために、ディスカバリクエリの受信に応答可能であるディスカバリサービスサーバであって、
ユーザの未登録アイデンティティサービスに対するアクセス権を提供するために、前記処理モジュールは、
‐前記ユーザの前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を選択し、
‐前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するために、リソースオファリング（ＲＯ２Ｘ）を前記第１のデータ記憶領域に格納するように構成されることを特徴とするディスカバリサービスサーバ。
【請求項１７】
前記サービスプロバイダを選択するために、前記処理モジュールは、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）及び前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービスの少なくとも１つの識別子（ＩＤＳＲＶ‐Ｘ）を有するサービス機能記憶領域（１０３‐２、３０１）をチェックする（４２‐Ｑ、４２‐Ｒ）ように構成される
請求項１６記載のディスカバリサービスサーバ。
【請求項１８】
前記処理モジュールは、前記チェックを周期的に繰り返す（４１３）ように構成される請求項１７記載のディスカバリサービスサーバ。
【請求項１９】
前記データ記憶モジュール（１０３）は、
前記サーバ機能記憶領域を格納する第２のデータ記憶領域（１０３‐２）を更に具備し、
前記処理モジュールは、前記サービスプロバイダを選択するために前記ディスカバリサービスサーバの前記第２のデータ記憶領域をチェックするように構成される
請求項１７又は１８記載のディスカバリサービスサーバ。
【請求項２０】
前記通信モジュールは、
サービスプロバイダから提供されるアイデンティティサービスの識別子を有する機能登録を前記サービスプロバイダから受信する（４１１）ように構成され、
前記処理モジュールは、前記第２のデータ記憶領域（１０３‐２）の内容を前記機能登録の内容で更新する（４１２）ために、前記機能登録の受信に応答可能である
請求項１９記載のディスカバリサービスサーバ。
【請求項２１】
前記処理モジュールは、アイデンティティサービスの識別子を有するサービス機能クエリを外部サービス機能記憶領域（３０１）に送信する（４２‐Ｑ）ことを前記通信モジュールに指示するように構成され、
前記通信モジュールは、前記アイデンティティサービスを提供できるサービスプロバイダの識別子を有する前記クエリに対する応答を受信する（４２‐Ｒ）ように構成され、
前記処理モジュールは、前記応答の内容に応じてサービスプロバイダを選択するために、前記応答の受信に応答可能である
請求項１７又は１８記載のディスカバリサービスサーバ。
【請求項２２】
前記処理モジュールは、
第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）を前記第１のデータ記憶領域のユーザの前記登録アイデンティティサービスに対して格納された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし（４１４、４２１、４２１１）、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定するように構成される
請求項１６から２１のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２３】
前記処理モジュールは、
‐請求項１６に記載されるように、前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリを受信する（２０５、４２１０）際、又は
‐請求項２０に記載されるように、サービスプロバイダから機能登録を受信する（４１１）際、又は
‐請求項１８に記載されるように、サービス機能記憶領域を周期的にチェックする（４１３）際、又は
‐前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信する（４２０）際に、前記第１のアイデンティティサービス及び前記ユーザに対する前記チェックを実行するように応答可能である
請求項２２記載のディスカバリサービスサーバ。
【請求項２４】
前記処理モジュールは、ユーザとの通信の確立の要求を送信することを前記通信モジュールに指示する（４１６、４２１４Ｂ、４２１３Ａ）ために、前記ユーザの未登録アイデンティティサービスの検出に応答可能である
請求項２２記載のディスカバリサービスサーバ。
【請求項２５】
前記通信モジュールは、前記ユーザにより指示されたサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの通信を受信する（４２５）ように構成され、
前記処理モジュールは、前記サービスプロバイダ基本設定に従ってサービスプロバイダを選択するために、前記通信に応答可能である
請求項１６から２４のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２６】
前記通信モジュールは、前記ユーザにより指示されたサービス関連データ（ＳＲＶ‐ＤＡＴ）を有する前記ユーザからの通信を受信する（４２５）ように構成され、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項１６から２５のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２７】
ユーザの未登録アイデンティティサービスに対するアクセス権を提供するために、前記処理モジュールは、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求（４２８Ａ、４２８Ｂ）を前記選択されたサービスプロバイダに送信することを前記通信モジュールに指示するように更に構成される
請求項１６から２６のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２８】
前記提供の要求（４２８Ａ、４２８Ｂ）は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能であるサービス関連データを備える
請求項２７記載のディスカバリサービスサーバ。
【請求項２９】
前記サービス関連データは、前記ユーザからの通信で受信される前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を備える
請求項２８記載のディスカバリサービスサーバ。
【請求項３０】
前記提供の要求は、
‐前記ディスカバリサービスサーバにおいて受信される受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答（４２８Ａ）に含まれるか、又は
‐前記ディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求（４２８Ａ）に含まれるか、又は
‐前記ディスカバリサービスサーバから前記サービスプロバイダに対する直接通信（４２８Ａ）に含まれる
請求項２７から２９のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３１】
前記通信モジュールは、前記提供の要求（４２８Ａ、４２８Ｂ）の結果、前記ディスカバリサービスサーバに前記ユーザの前記アイデンティティサービスを登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新（４２９）を前記選択されたサービスプロバイダから受信するように構成され、
前記処理モジュールは、前記受信したリソースオファリングを前記第１のデータ記憶領域（１０３‐１）に格納する（４３０）ために、前記ディスカバリサービス更新の受信に応答可能である
請求項２７から３０のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３２】
前記データ記憶モジュール（１０３）は少なくとも１つのデータ記憶領域（１０３０）を具備し、
前記通信モジュール（１０２）は、信号を交換する少なくとも１つの通信装置（１０２１）を具備し、
前記処理モジュール（１０１）は、通信装置により受信される前記信号を処理し且つ送信される前記信号の送信を通信装置に指示する少なくとも１つのプロセッサ（１０１０）を具備する
請求項１６から３１のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３３】
コンピュータを使用するディスカバリサービスサーバ（１００）からユーザのアイデンティティサービスに対するアクセス権を提供するコンピュータプログラムであって、
‐前記コンピュータを使用するディスカバリサービスサーバによって前記ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を格納する（２０３）ためのコンピュータ可読プログラムコードであり、前記アイデンティティサービスは、サービスプロバイダ（１３０）により提供され、前記リソースオファリングは、前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有するコンピュータ可読プログラムコードと、
‐前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリ（２０５）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記コンピュータを使用するディスカバリサービスサーバによって前記ユーザの登録アイデンティティサービスのリソースオファリングが含まれるディスカバリサービス応答（２０６）で前記クエリに返答するためのコンピュータ可読プログラムコードと、
を備えるコンピュータプログラムであって、
ユーザの未登録アイデンティティサービスに対するアクセス権を前記ディスカバリサービスサーバから提供するために、
‐前記ユーザに対して前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を前記コンピュータを使用するディスカバリサービスサーバによって選択する（４２）ためのコンピュータ可読プログラムコードと、
‐前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するためにリソースオファリング（ＲＯ２Ｘ）を前記コンピュータを使用するディスカバリサービスサーバによって格納する（４３）ためのコンピュータ可読プログラムコードと、
を更に備えることを特徴とするコンピュータプログラム。
【請求項３４】
前記アイデンティティサービスを提供できるサービスプロバイダを選択するためにサービス機能記憶領域（１０３‐２、３０１）を前記コンピュータを使用するディスカバリサービスサーバによってチェックする（４２‐Ｑ、４２‐Ｒ）ためのコンピュータ可読プログラムコードを更に備え、
前記サービス機能記憶領域は、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）及び前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービスの少なくとも１つの識別子（ＩＤＳＲＶ‐Ｘ）を備える
請求項３３記載のコンピュータプログラム。
【請求項３５】
前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを周期的に繰り返す（４１３）ためのコンピュータ可読プログラムコードを更に備える
請求項３４記載のコンピュータプログラム。
【請求項３６】
前記コンピュータを使用するディスカバリサービスサーバによって前記ディスカバリサービスサーバに前記サービス機能記憶領域（１０３‐２）を格納するためのコンピュータ可読プログラムコードと、
前記コンピュータを使用するディスカバリサービスサーバによって前記内部サービス機能記憶領域をチェックし、前記サービスプロバイダを選択するためのコンピュータ可読プログラムコードと、
を更に備える請求項３４又は３５記載のコンピュータプログラム。
【請求項３７】
サービスプロバイダからの機能登録（４１１）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記コンピュータを使用するディスカバリサービスサーバによって前記内部サービス機能記憶領域（１０３‐２）の内容を前記機能登録の内容で更新する（４１２）ためのコンピュータ可読プログラムコードを更に備え、
前記機能登録は、前記サービスプロバイダから提供されるアイデンティティサービスの識別子を備える
請求項３６記載のコンピュータプログラム。
【請求項３８】
前記コンピュータを使用するディスカバリサービスサーバによってアイデンティティサービスの識別子を有するサービス機能クエリ（４２‐Ｑ）を外部サービス機能記憶領域（３０１）に送信して、応答の内容に従ってサービスプロバイダを選択するようにアイデンティティサービスを提供できる前記サービスプロバイダの識別子を有する前記クエリに対する前記応答（４２‐Ｒ）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備える
請求項３４又は３５記載のコンピュータプログラム。
【請求項３９】
前記コンピュータを使用するディスカバリサービスサーバによって第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）をユーザの登録アイデンティティサービスに対して格納された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし（４１４、４２１、４２１１）、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定するためのコンピュータ可読プログラムコードを更に備える
請求項３３から３８のいずれか１項に記載のコンピュータプログラム。
【請求項４０】
前記チェックを行なうための前記コンピュータ可読プログラムコードは、
‐請求項３３に記載されるように、前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリ（２０５、４２１０）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐請求項３７に記載されるように、サービスプロバイダからの機能登録（４１１）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐請求項３５に記載されるように、サービス機能記憶領域の周期的なチェック（４１３）の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐前記ディスカバリサービスサーバにおける前記ユーザからの通信（４２０）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードとから選択される少なくとも１つのコンピュータ可読プログラムコードと、
を備える請求項３９記載のコンピュータプログラム。
【請求項４１】
前記ユーザとの通信の確立の要求（４１６、４２１４Ｂ、４２１３Ａ）を前記コンピュータを使用するディスカバリサービスサーバによって送信するためのコンピュータ可読プログラムコードを更に備える
請求項３９記載のコンピュータプログラム。
【請求項４２】
前記ユーザにより指示されるサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの通信の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記サービスプロバイダ基本設定に従ってサービスプロバイダを選択するためのコンピュータ可読プログラムコードを更に備える
請求項３３から４１のいずれか１項に記載のコンピュータプログラム。
【請求項４３】
前記ユーザにより指示されるサービス関連データ（ＳＲＶ‐ＤＡＴ）を有する前記ユーザからの通信（４２５）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備え、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項３３から４２のいずれか１項に記載のコンピュータプログラム。
【請求項４４】
前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求（４２８Ａ、４２８Ｂ）を前記コンピュータを使用するディスカバリサービスサーバによって前記選択されたサービスプロバイダに送信するためのコンピュータ可読プログラムを更に備える
請求項３３から４３のいずれか１項に記載のコンピュータプログラム。
【請求項４５】
前記提供の要求（４２８Ａ、４２８Ｂ）は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能なサービス関連データを有する
請求項４４記載のコンピュータプログラム。
【請求項４６】
前記サービス関連データは、前記ユーザからの通信において受信される前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を有する
請求項４５記載のコンピュータプログラム。
【請求項４７】
前記提供の要求は、
‐前記コンピュータを使用するディスカバリサービスサーバにおいて受信される受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答（４２８Ａ）に含まれるか、又は
‐前記コンピュータを使用するディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求（４２８Ａ）に含まれるか、又は
‐前記コンピュータを使用するディスカバリサービスサーバから前記サービスプロバイダに対する直接通信（４２８Ｂ）に含まれる
請求項４４から４６のいずれか１項に記載のコンピュータプログラム。
【請求項４８】
前記提供の要求（４２８Ａ、４２８Ｂ）の結果、前記ユーザの前記アイデンティティサービスを登録するために前記受信リソースオファリングを格納するように（４３０）、前記ユーザの前記アイデンティティサービスを前記ディスカバリサービスサーバに登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新（４２９）の前記選択されたサービスプロバイダからの受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備える
請求項４４から４７のいずれか１項に記載のコンピュータプログラム。
【請求項１】
ディスカバリサーバ（１００）からユーザのアイデンティティサービスに対するアクセス権を提供する方法であって、
ａ）前記ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を前記ディスカバリサービスサーバに格納するステップ（２０３）であって、前記アイデンティティサービスはサービスプロバイダ（１３０）により提供され、前記リソースオファリングは前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有する、ステップと、
ｂ）前記ユーザのリソースオファリングを取得するために、前記ディスカバリサービスサーバにおいてディスカバリサービスクエリを受信するステップ（２０５）と、
ｃ）前記ユーザの登録アイデンティティサービスのリソースオファリングを含むディスカバリサービス応答で前記クエリに返答するステップ（２０６）と、
を備え、
ユーザの未登録アイデンティティサービスに対するアクセス権を前記ディスカバリサービスサーバから提供するために、
ｄ）前記ユーザの前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を前記ディスカバリサービスサーバから選択するステップ（４２）と、
ｅ）前記選択されたサービスプロバイダにより提供されたときに前記ユーザの前記アイデンティティサービスを登録するために、リソースオファリング（ＲＯ２Ｘ）を前記ディスカバリサービスサーバに格納するステップ（４３）と、
を更に備えることを特徴とする方法。
【請求項２】
前記ステップ「ｄ」は、
ｄ．１）前記アイデンティティサービスを提供できるサービスプロバイダを選択するために、サービス機能記憶領域（１０３‐２、３０１）をチェックするステップ（４２‐Ｑ、４２‐Ｒ）
を備え、
前記サービス機能記憶領域は、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）と、前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）の少なくとも１つの識別子と、
を有する請求項１記載の方法。
【請求項３】
前記ステップ「ｄ．１」のチェックは周期的に繰り返される（４１３）請求項２記載の方法。
【請求項４】
ｄ．０）前記ディスカバリサービスサーバに前記サーバ機能記憶領域（１０３‐２）を格納する先行するステップを更に備え、
前記ステップ「ｄ．１」は、前記ディスカバリサービスサーバに格納された内部サービス機能記憶領域をチェックするステップを備える
請求項２又は３記載の方法。
【請求項５】
ｆ）前記ディスカバリサービスサーバにおいて、サービスプロバイダから提供されるアイデンティティサービスの識別子を有する機能登録を前記サービスプロバイダから受信するステップ（４１１）と、
ｇ）前記ディスカバリサービスサーバに格納される前記サーバ機能記憶領域（１０３‐２）を前記機能登録の内容で更新するステップ（４１２）と、
を更に備える請求項４記載の方法。
【請求項６】
前記ステップ「ｄ．１」は、
ｄ．１．１）アイデンティティサービスの識別子を有するサービス機能クエリを外部サービス機能記憶領域（３０１）に送信するステップ（４２‐Ｑ）と、
ｄ．１．２）前記アイデンティティサービスを提供できるサービスプロバイダの識別子を有する前記クエリに対する応答を受信するステップ（４２‐Ｒ）と、
を備える請求項２又は３記載の方法。
【請求項７】
ｈ）前記ディスカバリサービスサーバにおいて、第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）をユーザの前記登録アイデンティティサービスに対して登録された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定する先行するステップ（４１４、４２１、４２１１）
を更に備える請求項１から６のいずれか１項に記載の方法。
【請求項８】
前記ステップ「ｈ」は、
‐請求項１のステップ「ｂ」に記載されるように、前記ディスカバリサービスサーバにおけるディスカバリサービスクエリを受信すること（２０５、４２１０）と、
‐請求項５のステップ「ｆ」に記載されるように、前記ディスカバリサービスサーバにおけるサービスプロバイダから機能登録を受信すること（４１１）と、
‐請求項３に記載されるように、サービス機能記憶領域を周期的にチェックすること（４１３）と、
‐前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信すること（４２０）と、
から選択される少なくとも１つのステップの後に実行される
請求項７記載の方法。
【請求項９】
ｉ）前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスである場合、前記ユーザとの通信の確立の要求を前記ディスカバリサービスサーバから送信するステップ（４１６、４２１４Ｂ、４２１３Ａ）と、
ｊ．０）前記確立の要求に対する応答として、前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信するステップ（４２０）と、
を更に備える請求項７記載の方法。
【請求項１０】
ｊ．１）前記ディスカバリサービスサーバにおいて、通信において前記ユーザにより指示されるサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの前記通信を受信するステップ（４２５）を更に備え、
前記ステップ「ｄ」は、
ｄ．２）前記サービスプロバイダ基本設定に従って、前記アイデンティティサービスを提供できる複数のサービスプロバイダから１つのサービスプロバイダを選択するステップ（４２６）を備える
請求項１から９のいずれか１項に記載の方法。
【請求項１１】
ｊ．２）前記ディスカバリサービスサーバにおいて、通信において前記ユーザにより指示されるサービス関連データ（ＳＲＶ-ＤＡＴ）を有する前記ユーザからの前記通信を受信するステップ（４２５）を更に備え、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
前記ステップ「ｄ」は、
ｄ．３）前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求を前記ディスカバリサービスサーバから前記選択されたサービスプロバイダに送信するステップ（４２８Ａ、４２８Ｂ）と、
ｄ．４）前記要求の結果、前記ディスカバリサービスサーバにおいて、前記ユーザの前記アイデンティティサービスを前記ディスカバリサービスサーバに登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新を前記選択されたサービスプロバイダから受信するステップ（４２９）と、
を更に備え、
前記ステップ「ｅ」は、前記受信したリソースオファリングを前記ディスカバリサービスサーバに格納するステップ（４３０）を備える
請求項１から１１のいずれか１項に記載の方法。
【請求項１３】
ステップ「ｄ．３」で送信された前記提供の要求は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能なサービス関連データを有する
請求項１２記載の方法。
【請求項１４】
前記サービス関連データは、前記ステップ「ｊ．２」で受信した前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を有する請求項１３記載の方法。
【請求項１５】
前記ステップ「ｄ．３」は、
ｄ．３．１）前記ディスカバリサービスサーバにおいて受信された受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答に含まれる前記提供の要求を送信するステップ（４２８Ａ）と、
ｄ．３．２）前記ディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求に含まれる前記提供の要求を送信するステップ（４２８Ａ）と、
ｄ．３．３）前記ディスカバリサービスサーバから前記選択されたサービスプロバイダに前記提供の要求を直接送信するステップ（４２８Ｂ）とから選択される１つのステップと、
を備える請求項１２から１４のいずれか１項に記載の方法。
【請求項１６】
ユーザのアイデンティティサービスに対するアクセス権を提供するディスカバリサービスサーバ（１００）であって、
‐ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を格納する第１のデータ記憶領域（１０３‐１）を有するデータ記憶モジュール（１０３）であり、前記アイデンティティサービスは、サービスプロバイダ（１３０）により提供され、前記リソースオファリングは、前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有するデータ記憶モジュール（１０３）と、
‐他の通信エンティティ（１１０、１２０、１３０、１４０、１５０、３０１）と通信するために信号を交換する通信モジュール（１０２）と、
‐前記信号を処理し且つ前記データ記憶モジュールのデータの格納及び検索を制御する処理モジュール（１０１）とを具備し、
前記信号は、
‐ユーザのリソースオファリングを取得するためにディスカバリサービスクエリを受信すること（２０５）と、
‐前記ユーザの登録アイデンティティサービスのリソースオファリングが含まれるディスカバリサービス応答を送信すること（２０６）と
を少なくとも有し、
前記処理モジュールは、前記第１のデータ記憶領域の内容をチェックし且つ前記通信モジュールに前記ディスカバリ応答を送信するように指示するために、ディスカバリクエリの受信に応答可能であるディスカバリサービスサーバであって、
ユーザの未登録アイデンティティサービスに対するアクセス権を提供するために、前記処理モジュールは、
‐前記ユーザの前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を選択し、
‐前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するために、リソースオファリング（ＲＯ２Ｘ）を前記第１のデータ記憶領域に格納するように構成されることを特徴とするディスカバリサービスサーバ。
【請求項１７】
前記サービスプロバイダを選択するために、前記処理モジュールは、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）及び前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービスの少なくとも１つの識別子（ＩＤＳＲＶ‐Ｘ）を有するサービス機能記憶領域（１０３‐２、３０１）をチェックする（４２‐Ｑ、４２‐Ｒ）ように構成される
請求項１６記載のディスカバリサービスサーバ。
【請求項１８】
前記処理モジュールは、前記チェックを周期的に繰り返す（４１３）ように構成される請求項１７記載のディスカバリサービスサーバ。
【請求項１９】
前記データ記憶モジュール（１０３）は、
前記サーバ機能記憶領域を格納する第２のデータ記憶領域（１０３‐２）を更に具備し、
前記処理モジュールは、前記サービスプロバイダを選択するために前記ディスカバリサービスサーバの前記第２のデータ記憶領域をチェックするように構成される
請求項１７又は１８記載のディスカバリサービスサーバ。
【請求項２０】
前記通信モジュールは、
サービスプロバイダから提供されるアイデンティティサービスの識別子を有する機能登録を前記サービスプロバイダから受信する（４１１）ように構成され、
前記処理モジュールは、前記第２のデータ記憶領域（１０３‐２）の内容を前記機能登録の内容で更新する（４１２）ために、前記機能登録の受信に応答可能である
請求項１９記載のディスカバリサービスサーバ。
【請求項２１】
前記処理モジュールは、アイデンティティサービスの識別子を有するサービス機能クエリを外部サービス機能記憶領域（３０１）に送信する（４２‐Ｑ）ことを前記通信モジュールに指示するように構成され、
前記通信モジュールは、前記アイデンティティサービスを提供できるサービスプロバイダの識別子を有する前記クエリに対する応答を受信する（４２‐Ｒ）ように構成され、
前記処理モジュールは、前記応答の内容に応じてサービスプロバイダを選択するために、前記応答の受信に応答可能である
請求項１７又は１８記載のディスカバリサービスサーバ。
【請求項２２】
前記処理モジュールは、
第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）を前記第１のデータ記憶領域のユーザの前記登録アイデンティティサービスに対して格納された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし（４１４、４２１、４２１１）、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定するように構成される
請求項１６から２１のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２３】
前記処理モジュールは、
‐請求項１６に記載されるように、前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリを受信する（２０５、４２１０）際、又は
‐請求項２０に記載されるように、サービスプロバイダから機能登録を受信する（４１１）際、又は
‐請求項１８に記載されるように、サービス機能記憶領域を周期的にチェックする（４１３）際、又は
‐前記ディスカバリサービスサーバにおいて前記ユーザから通信を受信する（４２０）際に、前記第１のアイデンティティサービス及び前記ユーザに対する前記チェックを実行するように応答可能である
請求項２２記載のディスカバリサービスサーバ。
【請求項２４】
前記処理モジュールは、ユーザとの通信の確立の要求を送信することを前記通信モジュールに指示する（４１６、４２１４Ｂ、４２１３Ａ）ために、前記ユーザの未登録アイデンティティサービスの検出に応答可能である
請求項２２記載のディスカバリサービスサーバ。
【請求項２５】
前記通信モジュールは、前記ユーザにより指示されたサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの通信を受信する（４２５）ように構成され、
前記処理モジュールは、前記サービスプロバイダ基本設定に従ってサービスプロバイダを選択するために、前記通信に応答可能である
請求項１６から２４のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２６】
前記通信モジュールは、前記ユーザにより指示されたサービス関連データ（ＳＲＶ‐ＤＡＴ）を有する前記ユーザからの通信を受信する（４２５）ように構成され、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項１６から２５のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２７】
ユーザの未登録アイデンティティサービスに対するアクセス権を提供するために、前記処理モジュールは、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求（４２８Ａ、４２８Ｂ）を前記選択されたサービスプロバイダに送信することを前記通信モジュールに指示するように更に構成される
請求項１６から２６のいずれか１項に記載のディスカバリサービスサーバ。
【請求項２８】
前記提供の要求（４２８Ａ、４２８Ｂ）は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能であるサービス関連データを備える
請求項２７記載のディスカバリサービスサーバ。
【請求項２９】
前記サービス関連データは、前記ユーザからの通信で受信される前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を備える
請求項２８記載のディスカバリサービスサーバ。
【請求項３０】
前記提供の要求は、
‐前記ディスカバリサービスサーバにおいて受信される受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答（４２８Ａ）に含まれるか、又は
‐前記ディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求（４２８Ａ）に含まれるか、又は
‐前記ディスカバリサービスサーバから前記サービスプロバイダに対する直接通信（４２８Ａ）に含まれる
請求項２７から２９のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３１】
前記通信モジュールは、前記提供の要求（４２８Ａ、４２８Ｂ）の結果、前記ディスカバリサービスサーバに前記ユーザの前記アイデンティティサービスを登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新（４２９）を前記選択されたサービスプロバイダから受信するように構成され、
前記処理モジュールは、前記受信したリソースオファリングを前記第１のデータ記憶領域（１０３‐１）に格納する（４３０）ために、前記ディスカバリサービス更新の受信に応答可能である
請求項２７から３０のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３２】
前記データ記憶モジュール（１０３）は少なくとも１つのデータ記憶領域（１０３０）を具備し、
前記通信モジュール（１０２）は、信号を交換する少なくとも１つの通信装置（１０２１）を具備し、
前記処理モジュール（１０１）は、通信装置により受信される前記信号を処理し且つ送信される前記信号の送信を通信装置に指示する少なくとも１つのプロセッサ（１０１０）を具備する
請求項１６から３１のいずれか１項に記載のディスカバリサービスサーバ。
【請求項３３】
コンピュータを使用するディスカバリサービスサーバ（１００）からユーザのアイデンティティサービスに対するアクセス権を提供するコンピュータプログラムであって、
‐前記コンピュータを使用するディスカバリサービスサーバによって前記ユーザの登録アイデンティティサービスに対するリソースオファリング（ＲＯ２Ａ）を格納する（２０３）ためのコンピュータ可読プログラムコードであり、前記アイデンティティサービスは、サービスプロバイダ（１３０）により提供され、前記リソースオファリングは、前記アイデンティティサービスにアクセスするために前記サービスプロバイダと接続するのに使用可能な参照情報を有するコンピュータ可読プログラムコードと、
‐前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリ（２０５）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記コンピュータを使用するディスカバリサービスサーバによって前記ユーザの登録アイデンティティサービスのリソースオファリングが含まれるディスカバリサービス応答（２０６）で前記クエリに返答するためのコンピュータ可読プログラムコードと、
を備えるコンピュータプログラムであって、
ユーザの未登録アイデンティティサービスに対するアクセス権を前記ディスカバリサービスサーバから提供するために、
‐前記ユーザに対して前記未登録アイデンティティサービスを提供するサービスプロバイダ（１４０）を前記コンピュータを使用するディスカバリサービスサーバによって選択する（４２）ためのコンピュータ可読プログラムコードと、
‐前記選択されたサービスプロバイダにより提供された時に前記ユーザの前記アイデンティティサービスを登録するためにリソースオファリング（ＲＯ２Ｘ）を前記コンピュータを使用するディスカバリサービスサーバによって格納する（４３）ためのコンピュータ可読プログラムコードと、
を更に備えることを特徴とするコンピュータプログラム。
【請求項３４】
前記アイデンティティサービスを提供できるサービスプロバイダを選択するためにサービス機能記憶領域（１０３‐２、３０１）を前記コンピュータを使用するディスカバリサービスサーバによってチェックする（４２‐Ｑ、４２‐Ｒ）ためのコンピュータ可読プログラムコードを更に備え、
前記サービス機能記憶領域は、サービスプロバイダの少なくとも１つの識別子（ＳＰ‐１４０）及び前記サービスプロバイダから提供される少なくとも１つのアイデンティティサービスの少なくとも１つの識別子（ＩＤＳＲＶ‐Ｘ）を備える
請求項３３記載のコンピュータプログラム。
【請求項３５】
前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを周期的に繰り返す（４１３）ためのコンピュータ可読プログラムコードを更に備える
請求項３４記載のコンピュータプログラム。
【請求項３６】
前記コンピュータを使用するディスカバリサービスサーバによって前記ディスカバリサービスサーバに前記サービス機能記憶領域（１０３‐２）を格納するためのコンピュータ可読プログラムコードと、
前記コンピュータを使用するディスカバリサービスサーバによって前記内部サービス機能記憶領域をチェックし、前記サービスプロバイダを選択するためのコンピュータ可読プログラムコードと、
を更に備える請求項３４又は３５記載のコンピュータプログラム。
【請求項３７】
サービスプロバイダからの機能登録（４１１）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記コンピュータを使用するディスカバリサービスサーバによって前記内部サービス機能記憶領域（１０３‐２）の内容を前記機能登録の内容で更新する（４１２）ためのコンピュータ可読プログラムコードを更に備え、
前記機能登録は、前記サービスプロバイダから提供されるアイデンティティサービスの識別子を備える
請求項３６記載のコンピュータプログラム。
【請求項３８】
前記コンピュータを使用するディスカバリサービスサーバによってアイデンティティサービスの識別子を有するサービス機能クエリ（４２‐Ｑ）を外部サービス機能記憶領域（３０１）に送信して、応答の内容に従ってサービスプロバイダを選択するようにアイデンティティサービスを提供できる前記サービスプロバイダの識別子を有する前記クエリに対する前記応答（４２‐Ｒ）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備える
請求項３４又は３５記載のコンピュータプログラム。
【請求項３９】
前記コンピュータを使用するディスカバリサービスサーバによって第１のアイデンティティサービス（ＩＤＳＲＶ‐Ｘ）をユーザの登録アイデンティティサービスに対して格納された前記リソースオファリング（ＲＯ２Ａ）と比較してチェックし（４１４、４２１、４２１１）、前記第１のアイデンティティサービスが前記ユーザの未登録アイデンティティサービスであるかを判定するためのコンピュータ可読プログラムコードを更に備える
請求項３３から３８のいずれか１項に記載のコンピュータプログラム。
【請求項４０】
前記チェックを行なうための前記コンピュータ可読プログラムコードは、
‐請求項３３に記載されるように、前記ユーザのリソースオファリングを取得することを要求するディスカバリサービスクエリ（２０５、４２１０）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐請求項３７に記載されるように、サービスプロバイダからの機能登録（４１１）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐請求項３５に記載されるように、サービス機能記憶領域の周期的なチェック（４１３）の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードと、
‐前記ディスカバリサービスサーバにおける前記ユーザからの通信（４２０）の受信の処理の際に、前記コンピュータを使用するディスカバリサービスサーバによって前記チェックを実行するためのコンピュータ可読プログラムコードとから選択される少なくとも１つのコンピュータ可読プログラムコードと、
を備える請求項３９記載のコンピュータプログラム。
【請求項４１】
前記ユーザとの通信の確立の要求（４１６、４２１４Ｂ、４２１３Ａ）を前記コンピュータを使用するディスカバリサービスサーバによって送信するためのコンピュータ可読プログラムコードを更に備える
請求項３９記載のコンピュータプログラム。
【請求項４２】
前記ユーザにより指示されるサービスプロバイダ基本設定（ＳＰ‐ＰＲＥＦ）を有する前記ユーザからの通信の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理し、前記サービスプロバイダ基本設定に従ってサービスプロバイダを選択するためのコンピュータ可読プログラムコードを更に備える
請求項３３から４１のいずれか１項に記載のコンピュータプログラム。
【請求項４３】
前記ユーザにより指示されるサービス関連データ（ＳＲＶ‐ＤＡＴ）を有する前記ユーザからの通信（４２５）の受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備え、
前記サービス関連データは、選択されたサービスプロバイダからの前記アイデンティティサービスの提供に使用可能である
請求項３３から４２のいずれか１項に記載のコンピュータプログラム。
【請求項４４】
前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供の要求（４２８Ａ、４２８Ｂ）を前記コンピュータを使用するディスカバリサービスサーバによって前記選択されたサービスプロバイダに送信するためのコンピュータ可読プログラムを更に備える
請求項３３から４３のいずれか１項に記載のコンピュータプログラム。
【請求項４５】
前記提供の要求（４２８Ａ、４２８Ｂ）は、前記選択されたサービスプロバイダからの前記ユーザに対する前記アイデンティティサービスの提供に使用可能なサービス関連データを有する
請求項４４記載のコンピュータプログラム。
【請求項４６】
前記サービス関連データは、前記ユーザからの通信において受信される前記サービス関連データ（ＳＲＶ‐ＤＡＴ）の少なくとも一部を有する
請求項４５記載のコンピュータプログラム。
【請求項４７】
前記提供の要求は、
‐前記コンピュータを使用するディスカバリサービスサーバにおいて受信される受信ディスカバリサービス要求に対する返答として送信されるディスカバリサービス応答（４２８Ａ）に含まれるか、又は
‐前記コンピュータを使用するディスカバリサービスサーバと前記ユーザとの間に確立された通信を前記選択されたサービスプロバイダにリダイレクトするリダイレクション要求（４２８Ａ）に含まれるか、又は
‐前記コンピュータを使用するディスカバリサービスサーバから前記サービスプロバイダに対する直接通信（４２８Ｂ）に含まれる
請求項４４から４６のいずれか１項に記載のコンピュータプログラム。
【請求項４８】
前記提供の要求（４２８Ａ、４２８Ｂ）の結果、前記ユーザの前記アイデンティティサービスを登録するために前記受信リソースオファリングを格納するように（４３０）、前記ユーザの前記アイデンティティサービスを前記ディスカバリサービスサーバに登録するためのリソースオファリング（ＲＯ２Ｘ）を有するディスカバリサービス更新（４２９）の前記選択されたサービスプロバイダからの受信を前記コンピュータを使用するディスカバリサービスサーバによって処理するためのコンピュータ可読プログラムコードを更に備える
請求項４４から４７のいずれか１項に記載のコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２００７−５３７５３６（Ｐ２００７−５３７５３６Ａ）
【公表日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願番号】特願２００７−５１３０９５（Ｐ２００７−５１３０９５）
【出願日】平成１６年５月１１日（２００４．５．１１）
【国際出願番号】ＰＣＴ／ＳＥ２００４／０００７２０
【国際公開番号】ＷＯ２００５／１０９８２２
【国際公開日】平成１７年１１月１７日（２００５．１１．１７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願日】平成１６年５月１１日（２００４．５．１１）
【国際出願番号】ＰＣＴ／ＳＥ２００４／０００７２０
【国際公開番号】ＷＯ２００５／１０９８２２
【国際公開日】平成１７年１１月１７日（２００５．１１．１７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]