JP4335812B2 - 異種のネットワークにおける遠隔サービスの呼び出し - Google Patents

Description

本発明は、概して、コア・ネットワークによって提供されるサービス及びサービス・ネットワーク上に存在するアプリケーション間の相互作用及び互換性に関する。より詳細には本発明は、コア・ネットワークとサービス・ネットワークとの間、並びにいくつかのコア・ネットワーク間のオープン・スタンダード・インタフェースに関する。

今日、通信市場における大型選手（big player）は、ユーザに通信ネットワーク及びインターネットへのアクセスを提供するために機能する、複数の国間に分散されたある種のタイプのアクセス及びコア・ネットワーク技術を有している。上記で述べたようなタイプの代表的技術は、ＧＰＲＳ、ＥＤＧＥ、ＣＤＭＡ、ＴＤＭＡ、Ｄ−ＡＭＰＳ、ＰＤＣ、ＣＤＭＡ−２０００、ＷＣＤＭＡ等のようなもの、並びに様々な異種の環境が生じる様々なシナリオで得られるそれらの組み合わせである。このため、そのような異種の環境によってもたらされる複雑さとは別に、これらのネットワークをいくつかの地方会社に行政的に分割することは、環境により多くの異質性を付加し、統一されたサービス及び、異なるコア・ネットワーク又は異なるネットワーク・ドメインを通じて移動するユーザへのサービス・アプリケーション・アクセスの規定をより複雑にする。

伝統的な通信の前提外でネットワークを運営する新たな競争相手が現れつつある。これら新たな競争相手は、特にデータ伝送に関連する全ての問題については、現在は通信市場の一部であるが、ローミング、従来のＰＬＭＮネットワークよりもより広帯域のアクセス、及びユーザへの他の付加価値サービスの追加を可能にする。その上、これらの会社も、小さなＷＬＡＮの地方オペレータ、衛星オペレータ、ケーブルオペレータなどのいくつかのタイプのネットワークを運営するかもしれない。

通信ネットワークについてのそのような市場のシナリオでは、古い及び新しいネットワーク運営者は彼ら自身の顧客のベースを持っており、そのためアプリケーション及びサービスを開発するための労力は、技術の大きな多様性及び行政的環境により以前よりも複雑である。この複雑さに直面して、通信ネットワークは現在、サービス・レイヤ、コントロール・レイヤ、及び接続性レイヤを含むものと理解されている。サービス・レイヤは概して、高レベルのアプリケーション、より詳細にはエンドユーザ・アプリケーションの開発及び運営のためのネットワーク環境と理解されている。接続性レイヤは、エンドツーエンドの接続を確立するのに要求される、必要なインフラストラクチャ、又はネットワーク・リソースを提供する。コントロール・レイヤは、接続性レイヤ内のこれらのネットワーク・リソースを制御するために、要求されたインフラストラクチャ又はネットワーク制御エンティティを提供する一方、エンドユーザのサービス・アプリケーションを実行するために必要なネットワーク・サポートと共に、サービス・レイヤを提供する。サービス・アプリケーション・レイヤが独立したネットワークであるサービス・ネットワークとして実現される一方、コントロール及び接続性レイヤはアクセス・ネットワークと相互に作用するコア・ネットワーク内に残存するような、ネットワーク・アーキテクチャを提案することによって、個人用のサービスを迅速かつ容易に開発するために、次のステップが導入された。

異種の環境におけるサービス・レイヤ及びコントロール・レイヤ間の相互作用及び互換性は、ネットワークの境界及び端末間に渡る個人的サービスの携帯性を可能とするための、真の仮想ホーム環境（Virtual Home Environment：ＶＨＥ）をユーザに提供するために、解決する必要がある。ＶＨＥの概念は、どんなネットワーク及びどんな端末でも、どこにユーザが位置していても、すなわち、そのようなユーザが現在契約しているアクセス及びコア・ネットワーク、並びに彼らが現在移動している場所から独立して、ユーザに同じ個人化された機能、ユーザ・インタフェースのカスタム化及びサービスを一貫して提供することである。これに関連して、遠隔サービスの呼び出し及びサービス・ネットワークのローミングが、ユーザが真の仮想ホーム環境を持つことを可能とするためのキーファクターのように思われる。

サービス・ネットワーク・レイヤとコア・ネットワーク・レイヤとの間のオープン・サービス・アクセス（ＯＳＡ）インタフェースを標準化するために最近なされた努力の１つの代表的実例は、Ｐａｒｌａｙ／ＯＳＡ仕様であり、これはいくつかのアプリケーション・プログラミング・インタフェース（ＡＰＩ）に基づいている。これらのＡＰＩは、コア・ネットワークによって提供されるサービスに開発者がアクセスするのを、簡単な方法で可能とする。

初期のアプリケーション・プログラミング・インタフェース（ＡＰＩ）のセットは、いわゆるＰａｒｌａｙグループ内で定義され、それらの標準化は第３世代パートナーシップ・プロジェクト（３ＧＰＰ）及び欧州電気通信標準化機構（ＥＴＳＩ）標準化団体の下で継続されている。この状況において、上記のＡＰＩに沿ったサービスネットワークの概念は、Ｐａｒｌａｙグループ内では“Ｐａｒｌａｙ”と呼ばれるが、３ＧＰＰ及びＥＴＳＩではそれらを通常“オープン・サービス・アクセス”（ＯＳＡ）と呼ぶ。簡潔にするために、図１に示されるコア及びサービスネットワーク間のインタフェース・レイヤを参照するのに、ＯＳＡ／ＰＡＲＬＡＹという用語を本願明細書全体を通して使用する。現在、ＯＳＡ／ＰＡＲＬＡＹ ＡＰＩの特定及び標準化についての密接な協働作業が、Ｐａｒｌａｙ、３ＧＰＰ、及びＥＴＳＩの間で行われており、その作業の大部分は共同で行われている。

このように、ＯＳＡ／ＰＡＲＬＡＹは、ユーザ及び開発者がオペレータのコア・ホーム・ネットワークによって提供されるサービスを用いる、アプリケーションへのアクセス及びアプリケーションの提供を可能とする。その目的は、上記のＡＰＩネットワークから独立しており、そのためアプリケーションに影響を与えずにコア・ネットワーク技術の進化を可能とすること、並びにアプリケーションが異なるタイプのコア・ネットワークで動作するのを可能とすることである。

従って、図２Ａに示されるように、ＯＳＡ／ＰＡＲＬＡＹに基づいた従来のアーキテクチャは、形式的にはサービス・ネットワークに含まれ、アプリケーション・サーバ（ＡＳ）上で開発されるクライアント・アプリケーション、ＯＳＡ／ＰＡＲＬＡＹインタフェースのインタフェース・クラスを表し、サービス・イネーブラ（Service Enabler）とも呼ばれるサービス能力サーバ（ＳＣＳ：Service Capability Server）内で実現されるいくつかのサービス能力機能（ＳＣＦ：Service Capability Features）、サービス能力機能への制御されたアクセス（Ｓ−３０）のようなフレームワーク能力をアプリケーションに提供（Ｓ−１０）する、ＯＳＡ／ＰＡＲＬＡＹフレームワーク（ＦＷ）、コア・ネットワーク要素（ＣＮ）を含んでいる。詳細には、アプリケーション・サーバ（ＡＳ）上で実行されるアプリケーションは、サービス能力サーバ（ＳＣＳ）によって提供されるサービス能力機能を使用し（Ｓ−２０）、そのためＳＣＳはＡＰＩのサーバ側を実現し、ＡＳはクライアント側を実現する。ＳＣＳは、ホーム・ロケーション・レジスタ（ＨＬＲ）、移動交換局（ＭＳＣ）、呼状態制御機能（ＣＳＣＦ）等のようなコア・ネットワーク要素と相互作用（Ｓ−４０）してもよい。

クライアント・アプリケーションは、サービス能力機能に関して標準化されたアプリケーション・インタフェースを介してＯＳＡ／ＰＡＲＬＡＹ機能にアクセスする。これはサービス能力機能がアクセス可能であり、ＯＳＡ／ＰＡＲＬＡＹ ＡＰＩインタフェースにおける呼び出しを介してクライアント・アプリケーションによって見えることを意味する。

上記のＯＳＡ／ＰＡＲＬＡＹ機能は、識別のために概して３つの異なるタイプ：
−アクセス制御、セキュリティ、ＯＳＡ／ＰＡＲＬＡＹ機能の信用及び管理に必要な、共通に使用されるユーティリティを提供する、フレームワーク機能；
−基礎となるネットワーク能力の機能をアプリケーションが利用できるようにする、ネットワーク機能；及び
−アプリケーションが、ユーザの状態、位置、あるいは対応するユーザ・プロファイルのデータなどの特定ユーザのデータにアクセスできるようにする、ユーザ・データ関連機能にグループ化される。

特に、フレームワークは、ＯＳＡ／ＰＡＲＬＡＹアプリケーションにホーム・ネットワークにおけるサービス能力、より具体的には、認証及び承認を含むセキュリティ管理、サービスの登録及び発見機能、並びに完全性管理を利用できるようにする基本的能力を提供する。

上記で述べたＯＳＡ／ＰＡＲＬＡＹ ＡＰＩインタフェースにおける動作に関して、３つのタイプのインタフェース・クラス：
−例えば、ホーム・ネットワークのサービス能力をアプリケーションが利用できるようにする、認証などの基本的メカニズムをアプリケーションに提供する、サービス・ネットワーク内のアプリケーションとフレームワークとの間のインタフェース・クラス（Ｓ−１０）；
−アプリケーションとサービス能力機能（ＳＣＦ）との間のインタフェース・クラス（Ｓ−１０）、該サービス能力機能は、そのようなインタフェース・クラス（Ｓ−２０）が一旦フレームワークから得られると、アプリケーションに利用可能な個々のサービスである；及び
−マルチベンダ環境をサポートするメカニズムを提供する、フレームワークとサービス能力機能との間のインタフェース・クラス（Ｓ−３０）、が識別されている。

それでもなお、また図３Ａに示すように、いくつかのクライアント・アプリケーション（ＡＳ−１）と、フレームワーク（ＦＷ−１）と、いくつかのサービス能力（ＳＣＳ−１）と、第１のコア・ネットワーク（ＣＮ−１）とを備える、ユーザのホーム・ネットワークにおいて、いくつかのクライアント・アプリケーション（ＡＳ−２）と、フレームワーク（ＦＷ−２）と、サービス能力（ＳＣＳ−２）と、第２のコア・ネットワーク（ＡＣ−２）とを備える、訪問先ネットワーク内のサービス能力（ＳＣＳ−２）を利用するアプリケーション（ＡＳ−１，ＳＣＳ−１）の実行（Ｓ−４５）をＯＳＡ／ＰＡＲＬＡＹインタフェースを介して制御する方法であって、前記ホーム・ネットワーク及び前記訪問先ネットワークが異なるドメイン・オペレータに属しており、訪問先ネットワークの前記サービス能力（ＳＣＳ−２）がホーム・ネットワークに登録されていない、方法は存在しない。

上記で述べたＯＳＡ／ＰＡＲＬＡＹモデルは、異なる管理用及びビジネス用のドメインが現れるような方法で、異なるプレイヤー間に可変的に分散されてもよい。いくつかの代表的モデルは図２Ｂ及び２Ｃに示されており、ここでは特に、エンタープライズ・オペレータは、ネットワーク・ドメイン・オペレータに向かうアプリケーションに代わって動作する別のドメインとして表わされている。

特定のオペレータは、図２Ｂに示されているように、コア・ネットワーク並びに内部で開発されたエンドユーザ・サービス及びアプリケーションを受け持つ組織があり、別の独立した組織が、パートナーを介したエンドユーザ・サービスの提供、並びに前記パートナーへのサービス能力の提供を受け持つような方法で組織化される。上記のような異なる組織化は、それら自身のポリシーを独立して施行（enforce）し、それら自身のサービス情報を集める必要がある、幾分異なる通信ドメイン（コア・ネットワーク・ドメイン、エンドユーザ・サービス・ドメイン、パートナー）を含意する。このため、これら異なる通信ドメインは、各ドメイン自身によって提供されるサービス能力に加え、それ以外のドメインからサービス能力を提供するというそれぞれの利点が得られ、これは近年“連合（Federation）”としていくつかのフォーラムで知られている。換言すれば、異なる会社や事務所の様々な組織であっても、第２のドメイン、すなわちドナー・ドメインが第１のドメイン、すなわちレシーバ・ドメインに対してサービス能力を提供できるという、柔軟な解決策を持つという付加的利点が得られ、該レシーバ・ドメインは次に前記サービスをそれ自身のパートナー、すなわちそれら自身のサービス・プロバイダに提供できるであろう。その上、ある種のビジネス指向シナリオの下では、小売のネットワーク・サービスを受け持つエンタープライズ・オペレータの役割が存在する。図２Ｃに示したような、そのようなエンタープライズ・オペレータの役割は、前記エンタープライズ・オペレータ（ＥＯ）とアプリケーション・プロバイダ（ＡＰ）との間のサービス・ドメインにおいて、サービス合意（Service Agreement）が設定される（Ａ−１１）のを可能とする。エンタープライズ・オペレータはまた、サービス合意（Ａ−１０）、すなわちその特定のサービス・イネーブラ（ＳＣＳ）を提供するネットワーク・ドメイン・オペレータ（ＮＤＯ）とのサービス契約によっても制限される。

それにもかかわらず、ネットワーク・ドメイン・オペレータにとって、該ネットワーク・ドメイン・オペレータと合意しているアプリケーション・プロバイダに別のドメインのサービス・イネーブラを提供する手段は何もない。図３Ｂに示されるように、ＯＳＡ／ＰＡＲＬＡＹに注目したアーキテクチャ及びインタフェース・モデルは、自身のサービス能力（ＳＣＳ−２）を第１のドメイン（ＮＤＯ−１）に提供すると共にその逆も行う第２のドメイン（ＮＤＯ−２）を提供せず、これらドメイン（ＮＤＯ−１；ＮＤＯ−２）のいずれも、対応するアプリケーション・サービス・レベル合意（Ａ−１０，Ａ−１１）、すなわちランタイム・サービスの実行の間に施行されるであろうポリシーを提供する、自身のパートナー（ＡＰ−１，ＥＯ−１；ＡＰ−２，ＥＯ−２）を有することもない。

これに関して、本発明の目的は、訪問先ネットワークのような別のドメイン内のネットワークからのネットワーク・サービスを利用するアプリケーションの実行を、ＯＳＡ／ＰＡＲＬＡＹインタフェースを介して、ユーザのホーム・ネットワーク内で可能とする手段及び方法を提供することであり、ここで前記ユーザのホーム・ネットワーク及び前記訪問先ネットワークは異なるドメイン・オペレータに属しており、前記ネットワーク・サービスはユーザのホーム・ネットワークに登録されていない。

本発明の別の目的は、各ドメイン自身によって提供されるサービス能力に加え、ドメインが別のドメインからのサービス能力の提供を可能とすることである。

上記の目的は、本発明によれば、とりわけ、クライアント・サービス・アプリケーションに標準化されたインタフェースを介してサービス能力機能を提供するための通信システム及び方法を設けることによって達成される。特に、該通信システム及び方法は、いくつかの異なるネットワーク・ドメインの下で、ＯＳＡ／ＰＡＲＬＡＹ ＡＰＩによって提供されるような標準化されたインタフェースが、サービス・ネットワークとコア・ネットワークとの間に存在するシナリオで適用可能である。

このため該通信システムは、クライアント・サービス・アプリケーションが実行されるいくつかのアプリケーション・サーバと、いくつかの第１のサービス・イネーブラ、すなわち第１の（レシーバ）ネットワーク・ドメインにおいて第１のサービス能力機能が明確にされる第１のサービス能力サーバと、制御されたアクセスを前記第１のサービス能力機能に提供する第１のフレームワークと、サービス・ネットワークのエンティティと相互作用するいくつかのコア・ネットワーク要素とを備えている。

概して言うと、フレームワークは、ＯＳＡ／ＰＡＲＬＡＹ標準に関して上記で述べたフレームワーク機能、並びに後述する本発明によって提供される新たなフレームワーク機能を実行するように意図された、機能的フレームワーク・エンティティと見なされ得る。一方、本発明の目的について、サービス・イネーブラは、特定のネットワーク・ドメイン内でサービス能力機能（ＳＣＦ）が明確にされるサービス能力サーバ（ＳＣＳ）と見なされ得る。単純化のために、本明細書を通じて、常に互いに関連付けられることなしに、特定の文脈に応じて、サービス能力機能、あるいはサービス・イネーブラ、あるいはサービス能力サーバと呼ばれる。

このため、本発明によれば、この通信システム内の前記第１のフレームワークは、少なくとも１つの第２のフレームワークと通信するように構成され、後者は、第２の（ドナー）ネットワーク・ドメインのいくつかの第２のサービス・イネーブラ内で明確にされる第２のサービス能力機能にアクセスすることを目的とする。

簡潔にするために、本明細書では自身のサービス・イネーブラ、あるいは前記サービス・イネーブラで明確にされるサービス能力機能を、別のドメインに提供するネットワーク・ドメインをドナー・ドメインと呼ぶことが多い。これに関連して、本明細書ではドナー・ドメインによって提供されたサービス・イネーブラを使用可能にされたネットワーク・ドメインを、レシーバ・ドメインと呼ぶことが多い。

この通信システムにおけるフレームワークは、フレームワークとフレームワークとの通信を可能にする所与のプロトコル手段である。そのようなプロトコル手段は、第２のネットワーク・ドメイン内の第２のフレームワークの存在を、第１のネットワーク・ドメイン内の第１のフレームワークに対して公表（advertise）する手段を含んでおり、それによってサービス能力機能が共有され得る。そのプロトコル手段は、第２のネットワーク・ドメイン内の第２のフレームワークから、第１のネットワーク・ドメイン内の第１のフレームワークに対して、前記第２のネットワーク・ドメインのサービス・イネーブラから、前記第１のネットワーク・ドメインのクライアント・アプリケーションに提供され得る、サービス能力機能を公表する手段も含んでいる。

その上、他のドメイン内の他のフレームワークを公表する手段は、別のフレームワーク内にそれ自身によって各フレームワークを登録する手段を含んでいる。この自己登録とは別に、あるいは代替的に、第２のネットワーク・ドメイン内の第２のフレームワークの存在を、第１のネットワーク・ドメイン内の第１のフレームワークに対して公表する手段は、前記第１のドメインのオペレータが、第１のフレームワーク内に第２のフレームワークを登録する手段、並びに前記第２のドメインのオペレータが、第２のフレームワーク内に第１のフレームワークを登録するための手段を含んでいる。

更に、第２のネットワーク・ドメインのサービス・イネーブラから提供され得るサービス能力機能を公表する手段は、前記第２のネットワーク・ドメイン内の第２のフレームワークから、第１のネットワーク・ドメイン内の第１のフレームワークに対して、サービス識別子、サービス・タイプ、サービス可用性、サービス特性及びサービス・インタフェースを含む要素のグループから、少なくとも１つのサービス情報の要素についてのサービス情報を通知する手段を含んでいる。その上、第２のネットワーク・ドメイン内の利用可能なサービス能力機能の存在を公表する手段は、第１のネットワーク・ドメイン内の第１のフレームワークから、第２のネットワーク・ドメイン内の第２のフレームワークに対して、サービス情報のそのような要素の通知の基準を生成する手段を含んでいる。

該通信システムは更に、第１のネットワーク・ドメイン内の第１のフレームワークと、第２のネットワーク・ドメイン内の第２のフレームワークとの間で、セキュリティ管理メカニズムを実行する手段を含んでいる。前記セキュリティ管理メカニズムを実行する手段は、第１及び第２のドメイン間のサービス合意を記録する手段を含んでいる。これらのサービス合意は、第１のドメインがそのレシーバ・クライアント・アプリケーションにサービス能力を利用させる状態を明確にし、第２のドメインがサービス能力を第１のドメインに供給できる決まりを明確にする。これらのサービス合意は、このように前記第１及び第１のドメイン間に適用されるポリシーが考慮されても良い。サービス合意を記録する上記の手段に加えて、あるいは代替的に、サービス・アサーション及び署名を渡す手段も、第１のフレームワークと第２のフレームワークとの間でセキュリティ管理メカニズムを実行する手段内に含まれていても良い。

より詳細には、この通信システムはまた、第１のネットワーク・ドメイン内の第１のフレームワークと第２のネットワーク・ドメイン内の第２のフレームワークとの間で、第２のネットワーク・ドメインのサービス・イネーブラで利用可能なサービス能力機能を発見する手段を含んでいる。これは、前記第１のドメイン内のクライアント・アプリケーションによって要求されるのに応じて、特定の能力を取り決める手段を含んでいる。これら特定の能力が一旦うまく取り決められると、通信システムは、第２のフレームワークから第１のフレームワークに対して、第１のネットワーク・ドメイン内のクライアント・アプリケーションが第２のネットワーク・ドメインの対応するサービスを利用可能とするための、第２のネットワーク・ドメインのサービス・イネーブラで生成されたサービス・インスタンスに対する参照（reference）を返送する手段を含んでいる。

更にまた、通信システムは、第１の（レシーバ）ドメインと第２の（ドナー）ドメインとの間に挿入された、サービス・イネーブラ・プロキシを備えており、該サービス・イネーブラ・プロキシは、第１のドメイン内のアプリケーションから第２のドメインのサービス・イネーブラに対するサービス要求のため、並びに反対方向の通信におけるプロキシとして働くことを意図されている。該サービス・イネーブラ・プロキシは、好ましくは第１の（レシーバ）ドメイン内に設けられ、第２の（ドナー）ドメインの対応するサービス能力機能の参照を格納するために、前記第１のドメイン専用のサービス能力機能をいくつか備えていても良い。従って、通信システムは、第２の（ドナー）ドメイン内のフレームワーク（ドナー・フレームワーク）から受信した情報に基づいて、第１の（レシーバ）ドメイン内にサービス・イネーブラ・プロキシを自動的に生成する手段を更に含んでいても良く、前記情報は、サービス識別子、サービス・タイプ、サービス可用性、サービス特性及びサービス・インタフェースを含む要素のグループから選択された、少なくとも１つのサービス情報の要素を含んでいる。代替的に、該通信システムは、第２の（ドナー）ドメインからの、例えば、ソースコードやランタイムコードなどのダウンロードしたコードによって、サービス・イネーブラ・プロキシを生成する手段を更に備えていても良い。通信手段は、第１の（レシーバ）ドメイン内の第１のフレームワーク内に、第２の（ドナー）ドメインの特定のサービス・イネーブラを登録することによって、サービス・イネーブラ・プロキシを生成する代替的手段を備えていても良く、前記特定のサービス・イネーブラは、第２の（ドナー）ドメインに対してサービス・イネーブラ・プロキシとして働く。

ここに提示した通信システムは、上記で述べた本発明の目的を達成し、特に、第１の（レシーバ）ネットワーク・ドメインは、ユーザのホーム・コア・ネットワークを含むことができ、一方第２の（ドナー）ネットワーク・ドメインは、ユーザがローミングする訪問先コア・ネットワークを含むことができる。

本発明によって、クライアント・サービス・アプリケーションに、標準化されたインタフェース（ＯＳＡ／ＰＡＲＬＡＹ）を介してサービス能力機能へのアクセスを提供する方法も提供され、該方法は、
−第１の（レシーバ）ネットワーク・ドメイン内の第１のサービス能力機能を第１のフレームワークに登録し、第２の（ドナー）ネットワーク・ドメイン内の第２のサービス能力機能を第２のフレームワークに登録するステップと、
−対応する各フレームワークを通じた各ネットワーク・ドメイン内の、ユーザ、ネットワーク、要求中のアプリケーション、及びそれらの組み合わせを含むグループから選択された、いくつかのプレイヤーの認証及び承認のための、セキュリティ管理メカニズムを実行するステップと、
−前記第１の（レシーバ）ネットワーク・ドメイン内の要求中のアプリケーションによって利用可能な、第１のサービス能力機能を発見するステップと、を備えている。

本発明によれば、該方法はまた、
−第１の（レシーバ）ネットワーク・ドメインにおいて、第２の（ドナー）ネットワーク・ドメインにある第２のサービス能力機能が要求中のアプリケーションについて利用可能であるか判定するステップと、
−第１の（レシーバ）ネットワーク・ドメイン内の第１のフレームワークから、前記第２の（ドナー）ネットワーク・ドメイン内の第２のフレームワークを通じて、認証及び承認のためのセキュリティ管理メカニズムを実行するステップと、
−前記第２の（ドナー）ネットワーク・ドメイン内で、前記要求中のアプリケーションについて、利用可能な第２のサービス能力機能（ＳＣＦ−２）を発見するステップと、を含んでいる。

該方法は、第２のネットワーク・ドメインで第２のサービス能力機能が利用可能であるのを判定するために、第１の（レシーバ）ネットワーク・ドメイン内の第１のフレームワークに、第２の（ドナー）ネットワーク・ドメイン内で利用可能な第２のサービス能力機能へのアクセスを要求するステップを更に備えている。この判定は、第１の（レシーバ）ネットワーク・ドメイン内で選択された第１のサービス能力機能から、そのような情報を受信する付加的ステップを含んでいても良い。

その上、この方法における、第２の（ドナー）ネットワーク・ドメイン内で利用可能な第２のサービス能力機能を発見するステップはまた、第１の（レシーバ）ネットワーク・ドメインの第１のフレームワークと、第２の（ドナー）ネットワーク・ドメインの第２のフレームワークとから、能力を取り決めるステップを更に含んでいても良い。より詳細には、能力を取り決めるステップは、第２の（ドナー）ネットワーク・ドメインのサービス・イネーブラで、選択された第２のサービス能力機能のインスタンスを生成するステップと、第２のフレームワークから第１のフレームワークへそのようなインスタンスへの参照を返送するステップと、を含んでいる。

該方法が、第２の（ドナー）ネットワーク・ドメインの第２のフレームワークを、第１の（レシーバ）ネットワーク・ドメインの第１のフレームワークと共に登録するステップも含むときに、都合の良い動作が達成される。この登録には、第２のフレームワーク自身を第１のフレームワーク内に登録する第１のステップと、第１のフレームワーク自身を第２のフレームワーク内に登録する第２のステップとを含んでいる。この自己登録とは別に、あるいは代替的に、該方法はまた、第２の（ドナー）ネットワーク・ドメインのオペレータが、第２のフレームワーク内に第１の（レシーバ）ネットワーク・ドメインの第１のフレームワークを登録する第１のステップと、第１の（レシーバ）ネットワーク・ドメインのオペレータが、第１のフレームワーク内に第２の（ドナー）ネットワーク・ドメインの第２のフレームワークを登録する第２のステップとを含んでいる。自己登録又はオペレータによって開始された登録を使用することとは独立して、該方法は更に、前記第１及び第２のフレームワークに、互いによって制御されるサービス能力機能へのそれぞれのアクセスを可能とする少なくとも１つのインタフェースを発行（publish）するステップを備えている。

いずれかの特定のドメインにあるサービス・イネーブラは、新たなあるいはその時々で修正されたサービス能力機能で改善されても良い。前記サービス能力機能が登録された全てのドメインを通じて、対応するサービス情報を改善する必要が実際にある。従って、該方法は更に、そのようなサービス能力機能にアクセスするのに必要な、インタフェースの明確な指示があっても無くても、第１及び第２のネットワーク・ドメインそれぞれにおいて利用可能なサービス能力機能について、第１及び第２のフレームワーク間で情報を交換するステップを含んでいる。より詳細には、第１のネットワーク・ドメイン内の専用のサービス能力機能が、第２のネットワーク・ドメイン内で第２のサービス能力機能が利用可能であることを判定するのを受け持つとき、該方法は、第１のネットワーク・ドメイン内の少なくとも１つの第１のサービス能力機能に、第２のネットワーク・ドメイン内で利用可能な少なくとも１つの第２のサービス能力機能を示すステップと、おそらくは第１のネットワーク・ドメイン内のそのような専用のサービス能力機能内の対応する情報を格納するステップとを含んでいる。

この方法に、ネットワーク・ドメインのネットワーク・オペレータと、要求中のアプリケーションのサービス・プロバイダとの間のサービス・レベル合意を記録するステップを含むことによって、付加的利点が得られる。これに合わせて、該方法はまた、対応する第１及び第２のフレームワークを通じた、第１及び第２のネットワーク・ドメイン間のサービス・レベル合意を記録するステップを含んでいる。

これにより、前記サービス・レベル合意は、該方法が以下のステップを更に備えてもよいことによって、第２の（ドナー）ドメイン及び第１の）レシーバ）ドメインの間に拡張されるが、該ステップは、
−ドナー・フレームワークについて連合サービス・プロファイルを生成し割り当てるステップと、
−ドナー・フレームワークについて連合サービス合意にサインするステップと、
−ドナー・サービスを発見することが出来るクライアント・アプリケーション用のドナー・サービスについて必要な情報を、レシーバ・フレームワークにインストールする（登録する）ステップと、
−連合サービス合意の境界内で、ドナー・フレームワークからレシーバ・アプリケーション・サービス合意を要求するステップと、である。

実行者に連合フレームワークの設定におけるサービスを使用する権利を与える、アサーションを分配し渡すステップを含むことによって、より利点のあるセキュリティ管理メカニズムが達成され得る。従って、該方法は更に、
−レシーバ・フレームワークによるアサーションを他のエンティティのいずれかに渡すステップと、
−アサーションの分配及び／又は渡すことについての合意にサインするステップと、
−アサーションを要求するステップと、
−ドナー・サービスイネーブラが、ドナー・フレームワークについて受信したアサーションの有効性をチェックするステップと、を備えている。

該方法がまた、第２の（ドナー）ドメインのサービス・イネーブラで、選択された第２のサービス能力機能のインスタンスと通信するプロキシとして働くように構成された、サービス・イネーブラ・プロキシを第１の（レシーバ）ドメイン内で生成するステップを備えるときに、付加的利点が得られる。そのようなサービス・イネーブラ・プロキシの付加的利点は、この場合には第１の（レシーバ）ドメイン内で、ローカル・ポリシーを施行することである。

この方法では、第１の（レシーバ）ネットワーク・ドメインの第１のフレームワーク内で、サービス・イネーブラ・プロキシを自動的に生成するステップは、サービス・タイプ、サービス特性及びサービス・インタフェースを含む要素のグループから選択されたサービス情報の少なくとも１つの要素について、第２の（ドナー）ネットワーク・ドメインから、第１の（レシーバ）ネットワーク・ドメインでのサービス情報を取得するステップを含んでいても良い。

代替的に該方法では、第１の（レシーバ）ネットワーク・ドメイン内でサービス・イネーブラ・プロキシを生成するステップが、第２の（ドナー）ドメインからソースコード又はランタイムコードをダウンロードするステップを含んでいても良い。ダウンロードしたコードは、例えば、第１の（レシーバ）ドメインに、ローカル・ポリシーを含むソースコードを付加することを可能とすることによって、あるいは第２の（ドナー）ドメインからダウンロードしたランタイムコードに、ローカル・ポリシー・サーバに格納されたポリシーへの参照を持たせることによって、ローカル・ポリシーの施行規則を含んでいても良い。後者の場合には、第１の（レシーバ）ドメインは、ダウンロードしたコードがローカル・ポリシー・サーバを調べることが出来るのを確認するだけでよい。

加えて、第２の（ドナー）ドメインのサービス・イネーブラを、第１の（レシーバ）ドメインのフレームワークに登録し、両方のドメインがポリシーを設定でき、これらのポリシーがサービス・イネーブラによって施行されるのを可能とするようにしてもよい。該方法は、第１の（レシーバ）フレームワークによって各クライアント・アプリケーションについてサービス・イネーブラ・プロキシが生成されること、あるいは第１の（レシーバ）フレームワークによって要求されたときに、各クライアント・アプリケーションについてインスタンスを発生させる、１つのメイン・サービス・イネーブラ・プロキシが第１の（レシーバ）ドメイン内に存在することを可能とする。

以下の説明を添付図面と共に読むことによって、本発明の特徴、目的及び利点が明らかになるであろう。

本発明の第１の態様によれば、拡張され改善されたＯＳＡ／ＰＡＲＬＡＹインタフェースを介して、異種の訪問先ネットワークからのネットワーク・サービスを利用する、ユーザのホーム・ネットワーク内のサービス・アプリケーションの実行をサポートするためのシステム及び方法の現時点で好適な実施形態がいくつか提供され、ここで前記ユーザのホーム・ネットワーク及び前記異種の訪問先ネットワークは異なるドメイン・オペレータに属しており、前記ネットワーク・サービスはユーザのホーム・ネットワーク内に明確には登録されていない。

概略的に言えば、そして本発明の第２の態様によれば、第２のネットワーク・ドメイン、すなわちドナー・ドメインが、それ自身のサービス能力を第１のドメイン、すなわちレシーバ・ドメインに提供するのを可能とし、次にレシーバ・ドメインがこれらのサービス能力をそれら自身のパートナーやサービス・プロバイダに提供することができる、前記システム及び方法の現時点で好適な実施形態もいくつか提供される。

本発明によればその上、上記２つの態様で共有される特定の実施形態が提供され、該実施形態は、合意の記録と異なるネットワーク及びドメイン間でのセキュリティ・アサーションの交換、並びに実行時にそれらを施行することを可能とする。

本発明の別の態様による、複合ネットワーク・ドメイン環境において、サービス及びコア・ネットワーク間で相互作用するために、新たなフレームワークとフレームワークとのインタフェースを加えることによって、仮想グローバル・フレームワークがどのように構成され得るのかを説明するために、特定のアーキテクチャの概要が、図４に示されている。そのような新たなフレームワークとフレームワークとのインタフェース（Ｓ−６０）は、クライアント・アプリケーション（Ａｐｐｌ．１；Ａｐｐｌ．２；Ａｐｐｌ．３；Ａｐｐｌ．Ｍ）に、対応するコア・ネットワーク（ＣＮ−１；ＣＮ−２；ＣＮ−３；ＣＮ−Ｎ）と相互作用するサービス能力サーバ（ＳＣＳ−１；ＳＣＳ−２；ＳＣＳ−３；ＳＣＳ−Ｎ）内に設けられた、特定のサービス能力機能（ＳＣＦ）へのアクセスを有することを可能にする。

仮想グローバル・フレームワーク（ＶＧＦ）はこのように、いくつかのローカル・フレームワーク（ＦＷ−１；ＦＷ−２；ＦＷ−３；ＦＷ−Ｎ）と、フレームワークとフレームワークとのインタフェース（Ｓ−６０）を含んで構成され、各ローカル・フレームワークは、特定のネットワーク・ドメインのサービス能力サーバ（ＳＣＳ−１；ＳＣＳ−２；ＳＣＳ−３；ＳＣＳ−Ｎ）内のサービス能力機能（ＳＣＦ）へのアクセスを制御するために、そのようなネットワーク・ドメインで局所的に働いている。

このＶＧＦ、及び本発明による比較的新しいフレームワークとフレームワークとのインタフェース（Ｓ−６０）は、概して、遠隔サービスの呼び出し、より詳細には、ＯＳＡ／ＰＡＲＬＡＹの範疇において、異なるネットワーク・ドメイン間でのサービスの共有及びネットワーク・ローミング・サービスの提供を可能にする。例えば、図５Ａは概して前記遠隔サービス呼び出しをサポートするアーキテクチャを示しているが、詳細には加入者が訪問先の公衆陸上移動通信網（ＰＬＭＮ）内にローミングしたときの、コア・ネットワーク・サービスの提供に適用される。また、例えば、図５Ｂはネットワーク・ドメイン・オペレータ（ＥＯ−１）が、どのようにアプリケーション・プロバイダに、サインされたサービス合意（Ａ−１１）と共に、サービス・イネーブラ内のサービス能力機能（ＳＣＦ）、すなわち、前記新たなフレームワークとフレームワークとのインタフェース（Ｓ−６０）のおかげで、別のネットワーク・ドメイン・オペレータのサービス能力サーバ（ＳＣＳ−２）を提供できるのかを示している。

本発明の別の態様によれば、フレームワークとフレームワークとのインタフェース（Ｓ−６０）は、オンライン及びオフラインの２つの主要な動作モデルを提供する。オンライン・モデルは、好適には、クライアント・アプリケーションのために働いている第１のドメイン内の第１のフレームワークが、サービスが呼び出される第２のドメイン内の第２のフレームワークへの、アクセス及び有効なアクセスを準備する手順について実行される。オンライン・モデルで好適に実行される代表的実施形態は、例えば、図７Ｅ及び７Ｆ、図９Ｄ及び９Ｅ、及び図１０に示されたものであろう。一方、オフライン・モデルは、フレームワークの交換と、特定のサービス合意の下でのそれら対応するサービスについての情報、及びある種の通信で必要とされる対応するインタフェース・プロトコルの更新とに使用される。オフライン・モデルが好適に実行される代表的な実施形態は、例えば、図６、図７Ａから７Ｃ、及び図９Ａから９Ｂに示されたものであろう。

単純化のために、オンライン・モデルの動作の好適でかなり単純化した実施形態を、図５Ａに関連して良好に説明する。このため、第１のクライアント・アプリケーション（Ａｐｐｌ−１）は、そのローカル・フレームワーク（ＦＷ−１）に特定のサービスを要求する（Ｓ−１０）。ローカル・フレームワーク（ＦＷ−１）は、そのサービスがそれ自身のドメインのサービス・イネーブラ、すなわち、それ自身のドメインのサービス能力サーバ（ＳＣＳ−１）の関与だけで、十分かつ有効に実行され得るのかをチェックし（Ｓ−３０）、クライアント・アプリケーションに適切に通知される（Ｓ−１０；Ｓ−２０）。そのような要求されたサービスの呼び出しに、別のネットワーク・ドメイン（ＳＣＳ−２）が関与する必要があれば、クライアント・アプリケーション（Ａｐｐｌ−１）はローカル・フレームワーク（ＦＷ−１）に、対応する遠隔ドメイン内のそのようなサービスにアクセスするよう要求する（Ｓ−１０）。そして、ローカル・フレームワーク（ＦＷ−１）は、ローカルな要求中のクライアント・アプリケーション（Ａｐｐｌ−１）による遠隔サービス（ＳＣＳ−２）の利用を可能とするために、遠隔フレームワーク（ＦＷ−２）とのセキュリティ管理メカニズムを開始する（Ｓ−６０）。ローカル（ＦＷ−１）及び遠隔（ＦＷ−２）両方のフレームワークは、必要なサービス能力を取り決め（Ｓ−６０）、遠隔サービス能力機能（ＳＣＦ）の最も適切な関与を選択する（Ｓ−６０）。特定のサービスがサービス・イネーブラ（ＳＣＳ−２）で実体化されたら、遠隔フレームワーク（ＦＷ−２）はローカル・フレームワーク（ＦＷ−１）とそのサービスのインスタンスの識別情報を通信し、その情報はそのローカル・フレームワーク（ＦＷ−１）によって要求中のクライアント・アプリケーション（Ａｐｐｌ−１）に提供される。そして要求中のクライアント・アプリケーション（Ａｐｐｌ−１）は、そのサービスについて遠隔ＳＣＦとの接続が最終的に可能となる。

一方、オフライン・モデルの動作を単純化した別の実施形態は、それぞれの登録を含むそれぞれのサービスについて、フレームワーク間で情報の交換及び更新を示す、図６に関連して良好に説明される。

まず最初に、異なるフレームワーク間での登録段階は、図６に示すように、基本的及び単純化した２つのステップによって概略的に示される。登録の第１のステップは、新たなフレームワーク、すなわち、アプリケーションを所有するオペレータのフレームワーク、すなわち、ローカル又はレシーバ・フレームワークによってアクセスされ得る、遠隔又はドナー・フレームワークの存在を公表する。サービス告知の第２のステップは、図７Ａ及び９Ａに示される代替的好適な実施形態により詳細に示されており、利用可能なサービスと、ローカル又はレシーバ・フレームワークに遠隔又はドナー・フレームワーク内の前記サービスへのアクセスを可能とするインタフェースとを発表する。

新たな遠隔又はドナー・フレームワークの参照、並びに遠隔フレームワーク毎に基づいた利用可能なサービスは、好適には、フレームワークの登録が、実際にはそれぞれのドメイン・オペレータからトリガされる代替的実施形態に関する、図７Ａ及び７Ｃに示されているように、ローカル又はレシーバ・フレームワークに格納される。

しかしながら、専用であってもそうでなくても、特定のサービス能力機能（ＳＣＦ）がこの端部で使用されるときに、付加的利点が得られるであろう。図１０に示した代表的な使用例を更に説明する、本発明の別の実施形態によれば、遠隔フレームワーク毎に基づいた利用可能なサービス、又はその参照は、好適にはローカル又はレシーバ・フレームワークのアクセス制御の下にある、サービス・イネーブラ（ＳＣＳ）内にある特定のサービス能力機能（ＳＣＦ−１）内に格納される。

より詳細には、より詳細な実施形態の代替例が図８Ａから８Ｄに示されており、ここでこのＳＣＳは、レシーバ・ドメインとドナー・ドメインとの間に挿入されたプロキシ・サービス・イネーブラ（プロキシＳＣＳ）として実際に動作しており、レシーバ・ドメイン内のアプリケーション（Ａｐｐｌ−１；Application）からドナー・ドメインに対するサービス要求、並びにその反対方向の通信について、プロキシとして動作することを意図されている。この別の実施形態は、フレームワークをより標準的な方法で動作させるようにし、図１０に示されるように、ドナー・ドメインの適切なサービス能力サーバ（ＳＣＦ−２）を選択するレシーバ・ドメイン内で、特定のサービス・イネーブラ（ＳＣＳ）でのサービス能力機能（ＳＣＦ−１）、おそらくはＳＣＳプロキシと常に連絡を取っており、特定のサービスについてクライアント・アプリケーションを処理する。

利用可能なサービスの有無又はそれらの参照とは独立して、遠隔フレームワーク毎に基づいた情報は、ローカル・フレームワーク内、前記ローカルフレームワークの制御の下にある特定のサービス能力機能（ＳＣＦ）内、又はドナー及びレシーバ・ドメインの間に挿入されたプロキシ・サービス・イネーブラ内に格納されており、フレームワーク（ローカル；遠隔；ドナー）がサービスを追加又は変更したとき、図６、７Ａ及び９Ａに示されるように、前記フレームワークはそのサービスの更新を関連するフレームワーク（遠隔；ローカル；レシーバ）に送信する。

上記実施形態のいくつかについて、異なる使用例を以下で説明する。それでもなお、特に関連する使用例は位置決定サービスであり、本発明のいくつかの実施形態では、該サービスは上記で述べた代表的問題を解決するのに適している。このため、図１０はローミング環境における位置決定サービスのこの使用例を示しており、ここでクライアント・アプリケーション（Ａｐｐｌ−１）は、適切なサービス合意が存在する第１のドメインの参照内のローカル・フレームワーク（ＦＷ−１）と、認証のために必要なセキュリティ管理メカニズムを実行する。そして、クライアント・アプリケーション（Ａｐｐｌ−１）は、利用可能なサービス能力機能へのインタフェースについて、ローカル・フレームワーク（ＦＷ−１）に対して発見処理を要求する。ローカル・フレームワーク（ＦＷ−１）は、この第１のドメインのサービス能力サーバ（ＳＣＳ）内のサービス能力機能のセット（ＳＣＦ−１）と交渉を開始し、要求されたサービスを処理するのに適切なＳＣＦ＿ＩＤを選択し、特定のサービスをアプリケーションが要求するのに使用するそのＳＣＦ＿ＩＤの参照、すなわち、アプリケーション（Ａｐｐｌ−１）が必要とする特定の能力に対応した位置決めＳＣＦを、得られた発見インタフェースとして返送する。

上記のセキュリティ管理メカニズムの間、ローカル・フレームワーク（ＦＷ−１）は、アプリケーション（Ａｐｐｌ−１）がＳＣＦの使用を許可されているか、及びどのポリシー基準の下にあるのかをチェックする。これはいわゆるドメイン・ネットワーク・オペレータ及びサービス・プロバイダの間のサービス合意（ＳＬＡ）内で記録されても良い。アプリケーションがＳＣＦに使用を許可されている場合、ローカル・フレームワーク（ＦＷ−１）は、クライアント・アプリケーション（Ａｐｐｌ−１）の要求を満たすと思われる、全てのサービス能力機能である、全てのＳＣＦ＿ＩＤの識別情報を返送する。次に、アプリケーションはＳＣＦ＿ＩＤの１つを選択し、ＳＣＳはこのアプリケーションによって使用され状態をチェックすることも出来るＳＣＦインスタンスを生成する。このＳＣＦインスタンスの参照がフレームワーク（ＦＷ−１）に返送され、フレームワークはその参照をアプリケーション（Ａｐｐｌ−１）に返送する。この時点からアプリケーションはこのＳＣＦを使用することが出来る。

アプリケーション（Ａｐｐｌ−１）は、発見インタフェース（ＳＣＦ−１）によって得られたＳＣＦインスタンスに、移動端末“Ｚ”（ＭＴ Ｚ）の位置測定を依頼する。前記ＳＣＦインスタンス（ＳＣＦ−１）は、ＭＴ ＺがネットワークＲに位置していることを検出する。換言すると、第１のドメインは第２のネットワーク・ドメイン、すなわちネットワークＲでのサービス能力機能が、要求中のアプリケーションに利用可能であるかを判定する。この応答はアプリケーション（Ａｐｐｌ−１）に返送される。アプリケーションは、ローカル・フレームワーク（ＦＷ−１）に、前記遠隔ネットワーク・ドメインでの遠隔サービス能力機能へのアクセスを要求する。より詳細には、上記で予期され以下で詳細に説明するＳＣＳプロキシの代替的実施形態を使用することによって、クライアント・アプリケーションが特定のサービスを処理すべく、ドナー・ドメインの適切なサービス能力機能（ＳＣＦ−２）を選択するために、レシーバ・ドメイン内のサービス能力機能（ＳＣＦ−１）が連絡を受けても良い。

この段階で、ローカル・フレームワーク（ＦＷ−１）は、適切なサービス合意が存在する参照される第２のドメイン内の遠隔フレームワーク（ＦＷ−２）との、対応するセキュリティ管理メカニズムを開始する。サービス合意が前提とする適切なセキュリティ管理メカニズムの正しい結果に応じて、ローカル・フレームワーク（ＦＷ−１）から遠隔フレームワーク（ＦＷ−２）に対して、後者（ＦＷ−２）が第２のネットワーク・ドメイン内で要求中のアプリケーション（Ａｐｌ−１）によって使用される、利用可能なサービス能力機能（ＳＣＦ−２）を発見するための、遠隔処理が開始され得る。そのようなセキュリティ管理メカニズムは、図７Ｄ及び７Ｅに示されるサービス・レベル合意の区分に関して、あるいは図９Ｃに示されるアサーション有効基準に関して、実行され得る。

従って、ローカル・フレームワーク（ＦＷ−１）は、遠隔フレームワーク（ＦＷ−２）に、位置測定サービスについて、第２のドメインでのサービス能力サーバ又はサービス・イネーブラ（ＳＣＳ−２）内に位置するかもしれない、サービス能力機能（ＳＣＦ−２）を要求する。ローカル・フレームワーク（ＦＷ−１）は、アプリケーション（Ａｐｐｌ−１）によって要求された利用可能な訪問先のサービス能力機能の１つを選択し、遠隔フレームワーク（ＦＷ−２）を通じて特定の能力を交渉するが、これはローカル・フレームワークがアプリケーションの要求を知っており、遠隔フレームワークが登録されたそのような能力を有するものの１つであるからである。そして訪問先のサービス能力サーバ（ＳＣＳ−２）は、第１のドメイン内のクライアント・アプリケーション（Ａｐｐｌ−１）によって使用される予定の訪問先サービスのインスタンスを生成する。このインスタンスの参照が、遠隔フレームワーク（ＦＷ−２）からローカル・フレームワーク（ＦＷ−１）に返送され、ローカル・フレームワークはそれをアプリケーション（Ａｐｐｌ−１）に返送する。この時点からクライアント・アプリケーション（Ａｐｐｌ−１）は、訪問先のサービス能力機能（ＳＣＦ−２）を使用することが出来、ローカル及び遠隔フレームワークの間でこの処理が管理される。

本発明のこの態様による主な利点は、クライアント・アプリケーションがサービスを所望するときには常に、クライアント・アプリケーションだけが自身のローカル・フレームワークと連絡を取るが、フレームワークが後続する処理と他の連合した（Federated）ＯＳＡ／ＰＡＲＬＡＹ環境との関係とを管理することである。このためクライアント・アプリケーションは１つのフレームワーク内にだけ登録され、連合した全てのドメイン内に登録される必要はない。

相補的に、上記本発明の第２の態様によればいくつかの実施形態が提供され、本発明の他の目的も達成される。これに関連して、３つの詳細な実施形態は、第２のネットワーク・ドメイン、すなわちドナー・ドメインが、それ自身のサービス能力を第１のネットワークドメイン、すなわちレシーバ・ドメインに対して提供するのを目的としており、次に該レシーバ・ドメインは、全てのドメインにそのポリシーをインストールし施行するのを可能とする間に、これらのサービス能力をそれ自身のパートナーやサービス・プロバイダに提供することが出来る。３つの詳細な実施形態のそれぞれは、考えられる特定の利点に応じた他の特定の態様についての特定の実施形態を提供する。

第１の詳細な実施形態は図７Ａから７Ｆに示されており、既存のサービス合意モデルに拡張を提供し、これによりレシーバ・ドメインに、ドナー及び該レシーバ・ドメインの間のサービス合意を‘区分化あるいは細分化’することを可能とする。複数の区分がレシーバ・ドメイン及びそのアプリケーション・プロバイダ間のサービス合意を構成する。この第１の詳細な実施形態について更に説明するが、以下ではサービス合意区分化の実施形態と呼ぶ。第２の詳細な実施形態は図８Ａから８Ｄに示されており、レシーバ・ドメインがいわゆるプロキシ・イネーブラ（プロキシＳＣＳ）を、好適にはドナー・ドメインのサービス・イネーブラ毎に有する、モデルを提供する。この第２の詳細な実施形態についても更に説明するが、以下ではプロキシの実施形態と呼ぶ。図９Ａから９Ｅの第３の詳細な実施形態は、現在のサービス合意モデルをアサーションに基づいたモデルに置き換えることによって、付加的利点を提供する。この第３の詳細な実施形態についても更に説明するが、以下ではサービス・アサーションの実施形態と呼ぶ。

サービス合意区分化の実施形態の下では、ドナー・ドメイン内のＯＳＡ／ＰＡＲＬＡＹフレームワーク（以下では、ドナー・フレームワーク）は、サービス・イネーブラ（ＳＣＳ−２）を、例えば図２Ａ及び２Ｃに示したような既存のメカニズムを用いて、前記ドナー・ドメイン内のその通知を受けたアプリケーションに公表することが出来る。本発明の詳細な実施形態によれば、図６に関して上記で既に述べ、ここで図７Ａに関して詳述するが、そのようなアプリケーションだけでなく、レシーバ・ドメイン内のＯＳＡ／ＰＡＲＬＡＹフレームワーク（以下、レシーバ・フレームワーク）にも、ドナー・ドメイン内の前記サービス・イネーブラ（ＳＣＳ−２）が通知される。このため、レシーバ・ドメインが、ドナー・ドメインからレシーバ・ドメインのパートナー（アプリケーション）に、サービス・イネーブラ（ＳＣＳ−２）を提供するとき、これら２つのドメインは連合（Fedaration）を形成すると言われる。同様に、レシーバ・フレームワークが、ドナー・フレームワークによって公表されたサービス・イネーブラ（ＳＣＳ−２）を提供するとき、２つのフレームワークは連合設定で動作していると言われる。

このサービス合意区分化の実施形態の下での連合設定におけるドナー・フレームワークは、このため、
−図６に関して上記で説明したようなオフライン動作モードで、あるいは図７Ｂに示したようなオペレータが関連する手順で、レシーバ・フレームワークを登録した後の、図７Ａに示されたような、前記ドナー・フレームワーク内に登録されたレシーバ・フレームワークへの、新たに登録されたサービス・イネーブラの公表、
−図７Ｄに示されているように、レシーバ・フレームワークが、レシーバ・フレームワークとそのパートナーが特定のサービス・イネーブラを使用できるという条件での、ドナー及びレシーバ・フレームワークの間の契約と見なされ得る、連合サービス合意にサインできるようにする、メカニズムの提供、及び
−図７Ｅに含まれているように、レシーバ・フレームワークが、連合サービス合意によって設定される制限内でのレシーバ・フレームワーク・パートナーのアプリケーションの１つについて、ドナー・フレームワークからレシーバ・アプリケーション・サービス合意を要求できるようにする、メカニズムの提供、を受け持つ。

レシーバ・アプリケーション・サービス合意の項目は、レシーバ・フレームワークによって構成されるが、ドナー・フレームワークは、要求されたレシーバ・アプリケーション・サービス合意が、連合サービス合意の項目によって設定される制限内であることを保証する。レシーバ・アプリケーション・サービス合意は、特定のアプリケーションに与えられた連合サービス合意の区分と見なせ得る。レシーバ・アプリケーション・サービス合意がレシーバ・フレームワークに配布されたとき、図７Ｅに表され、更に図１０に示された使用例を参照して上記で既に述べたように、新たなサービス・インスタンスが生成され、レシーバ・フレームワークに参照が渡される。

一方、このサービス合意区分化の実施形態の下での連合設定におけるレシーバ・フレームワークは、ドナー・ドメインのサービス・イネーブラの登録を受け持つが、図７Ｃに示されているように、該サービス・イネーブラは、ドナー・フレームワークによって公表され、ドナー・サービスとも呼ばれ、自身のアプリケーションについてそれらを利用可能とする。従って、公表されたサービス・イネーブラの特性についてのリストは、ドナー・フレームワークから検索される。

サービス合意区分化の詳細な実施形態としてのこれらいくつかの実施形態に加え、図７Ｂで示されたように、レシーバのドメイン内の他のサービスのいずれかについては、ドナー・サービスについての専用のサービス・プロファイルが生成されてもよい。これに関連して、そのようなサービス・プロファイルは、図１０に示した使用例に関して上記で述べたように、レシーバ・ドメイン内の専用のサービス能力機能の形態を取り入れても、あるいはその中に格納されても良い。

更に、レシーバ・アプリケーションがそのようなドナー・サービスを選択し、レシーバ・ドメイン内の適用可能なセキュリティ管理メカニズム内で、レシーバ・フレームワークとのサービス合意にサインしたとき、前記レシーバ・フレームワークは、ドナー及びレシーバ・フレームワーク間の対応するセキュリティ管理メカニズムの一部として、ドナー・フレームワークに、レシーバ・サービス合意を要求する。レシーバ・フレームワークはこの要求の中で、前記レシーバ・アプリケーションに割り当てられたサービス・プロファイル内で定義された、項目及び／又は制限を提供する。そして、ドナー・フレームワークは、図７Ｅに示されたシーケンス図及び図１０に示した使用例でも検討したように、レシーバ・アプリケーション・サービス合意を契約するのに、これらの項目及び／又は制限を利用する。

その上、図７Ｆは、ドナー・ドメインがレシーバ・ドメインに自身のドナー・サービスを提供するのを終了させる、現在好適な実施形態を示している。どの図にも書いていないが、同様な手順がレシーバ・ドメインからもトリガされてもよい。

プロキシの実施形態の下では、ドナー・ドメイン内のサービス・イネーブラ（ＳＣＳ−２）にアクセスするために、レシーバ・ドメイン及びドナー・ドナー・ドメインの間に挿入された、いわゆるプロキシ・サービス・イネーブラ（プロキシＳＣＳ）が設けられる。より詳細には、実際の第１サービス・イネーブラ（プロキシＳＣＳ）が、レシーバ・ドメイン内のアプリケーションからドナー・ドメイン内の第２のサービス・イネーブラ（ＳＣＳ−２）への要求について、及び前記第２のサービス・イネーブラからアプリケーションへの他の方向においても同様に、レシーバ・ドメイン内でプロキシとして動作するように設けられている。ドナー・ドメイン内のそのような第２のサービス・イネーブラからの観点からは、第１のサービス・イネーブラ（プロキシＳＣＳ）は、アプリケーションと見なされる。

その上、図８Ａ及び８Ｂに示されるように、プロキシ設定においてプロキシ・サービス・イネーブラ（プロキシＳＣＳ）は、レシーバ・ドメインのアプリケーションからの要求に対するプロキシとして動作するため、及び前記アプリケーションをドナー・ドメイン内の実際のサービス・イネーブラ（ＳＣＳ−２）へ中継するために、ドナー・ドメイン内の実際のサービス・イネーブラ（ＳＣＳ−２）との通信を受け持つ。その上、プロキシ・サービス・イネーブラ（プロキシＳＣＳ）は、ポリシー又はアプリケーション・プロバイダ及びレシーバ・ドメイン間の合意の施行を受け持つ。

プロキシ設定においてドナー・フレームワークは、新たに登録されたサービスを登録されたレシーバ・フレームワークに公表するのを受け持つ。これに関連して、図６及び図７Ａに示されたような、ドナー及びレシーバ・フレームワーク間の相互登録のためのサービス合意区分化の実施形態の下で既に説明した先に述べた方法を、このプロキシの実施形態にも適用してもよい。その上、代替的実施形態で更に説明するように、ドナー・フレームワークが、サービス・イネーブラのコードをレシーバ・ドメインにオプションで提供して、対応するサービス・イネーブラがインスタンス化され得、前記レシーバ・ドメイン内のローカル・ポリシーを施行するようにオプションで調整されてもよい。

一方、プロキシ設定においてレシーバ・フレームワークは、プロキシ・サービス・イネーブラ（プロキシＳＣＳ）の登録と、それらをレシーバ・ドメイン内の自身のクライアント・アプリケーションに利用可能にすることとを受け持つ。従って、このプロキシの実施形態によってプロキシ・サービス・イネーブラを生成するのに、いくつかの代替例が提案される。

プロキシを生成する第１の代替的実施形態では、プロキシ・サービス・イネーブラは、第２の（ドナー）ドメインのサービス・イネーブラにある選択された第２のサービス能力機能のインスタンスと通信する、第１の（レシーバ）ドメイン内に生成される。このようなサービス・イネーブラ・プロキシの主な利点は、ローカル・ポリシーを、この場合は第１の（レシーバ）ドメイン内で施行することである。プロキシ・サービス・イネーブラは、サービス識別子、サービス・タイプ、サービス可用性、サービス特性及びサービス・インタフェースを含む要素のグループから選択された少なくとも１つの要素について、第２の（ドナー）ドメインから受信した情報に基づいて、第１の（レシーバ）ドメイン内で自動的に生成されても良い。

プロキシを生成する第２の代替的実施形態では、プロキシ・サービス・イネーブラは、第２の（ドナー）ドメインからソース・コードやランタイム・コードをダウンロードすることによって、第１の（レシーバ）ドメイン内で生成される。このコードは、ローカル・ポリシー施行規則を含むように調整されたものであっても良い。例えば、第１の（レシーバ）ドメインがローカル・ポリシーを含むコードを追加可能としたり、あるいは第２の（ドナー）ドメインからダウンロードしたランタイム・コードに、ローカル・ポリシー・サーバ内に格納されたポリシーへの参照を持たせるようにしてもよい。後者の場合には、第１の（レシーバ）ドメインは、ダウンロードされたコードがローカル・ポリシー・サーバが参照可能に構成されていることを確認するだけでよい。

プロキシを生成する第３の代替的実施形態では、プロキシ・サービス・イネーブラは、第２の（ドナー）ドメイン内のサービス・イネーブラ（ＳＣＳ）を選択することによって第１の（レシーバ）ドメイン内で生成されるが、これはこのサービス・イネーブラ（ＳＣＳ）を、プロキシ・サービス・イネーブラとして働くように第１の（レシーバ）ドメインのフレームワークに登録すること、及びサービス・イネーブラ（ＳＣＳ）が両方のドメインのポリシーを設定しこれらのポリシーを施行させるのを可能とすることによって行われる。プロキシ・サービス・イネーブラは、第２の（ドナー）ドメイン内の実際のサービス・イネーブラ（ＳＣＳ）のサービス・タイプ及び特性値に基づいて構成されても良い。これに関連して、プロキシ・サービス・イネーブラの構成は、いわゆる連合調停者として図８Ａに表されているような、専用の構成要素が受け持ってもよい。より詳細には、前記プロキシ・サービス・イネーブラの導入は、レシーバ・フレームワークが受け持っても良い。また更に、図８Ｄに示されるプロキシ・サービス・イネーブラの役割を満たすために、ドナー・ドメイン内の特定のサービス・イネーブラがレシーバ・フレームワークに登録されても良く、このためレシーバ・ドメイン内に登録される。

プロキシの実施形態の下での更なる対処の形態として、図８Ｃは、プロキシの実施形態の下でサービス合意がどのように終了されるのかについて、代表的実施形態を示している。

第３の詳細な実施形態である、上述のサービス・アサーションの実施形態は、先の２つの実施形態に対して付加的利点をもたらすものと思われている。このサービス・アサーションの実施形態は、ドナー及びレシーバ・ドメイン間のサービス・アサーションの交換及び実行に基づいている。

このサービス・アサーションの実施形態の下では、ドナー・ドメイン（ドナー・フレームワーク）内のＯＳＡ／ＰＡＲＬＡＹフレームワークは、サービス（ドナー・サービス）を、前記ドナー・ドメイン内でその通知を受けたアプリケーションに公表することが出来、また図９Ａに従って、図６及び７Ａに示したような、サービス合意区分化の実施形態に関して上記で予期されるのと同様な方法で、これらのドナー・サービスを、レシーバ・ドメイン内のＯＳＡ／ＰＡＲＬＡＹフレームワークにも公表することが出来る。

従って、図９Ｃは、レシーバ・フレームワークが、ドナー・フレームワークによるサービス・アサーションの配布をどのように要求し得るかを示している。その処理自体は図７Ｄに示したものに匹敵するが、サービス合意モデルのアサーションに基づいたモデルでの置き換えにより近い。概略的に言えば、アサーションは承認及び／又は認証のステートメントであり、いくつかの属性を含むことが出来る。より詳細には、アサーションはセキュリティ管理メカニズムに含まれると見なされても良い。

このため、図９Ｃによれば、ドナー・フレームワークは、該ドナー及びレシーバ・フレームワークの間でセキュリティ管理メカニズムを実行するときに、サービス・アサーションをレシーバ・フレームワークに渡す。同様な方法で、図９Ｄは、レシーバ・フレームワーク及びクライアント・アプリケーションの間でセキュリティ管理メカニズムが実行されるときに、対応するサービス・アサーションが、レシーバ・フレームワークからレシーバ・ドメイン内のクライアント・アプリケーションなどの他の要求しているエンティティのいずれかにどのように渡されるのかを示している。

概念的には、サービス・アサーションは、アプリケーション及び特定のサービスの間の合意を記載している。アサーションは、あるエンティティからサービスに送信され得、その後そのアサーションを送信したエンティティについてそのサービスが利用可能となる。そのようなアサーションの‘送信’は、この状況ではアサーションの‘実行’と見なすことが出来る。アサーションが発行されたときは、どのアプリケーション又はエンティティがそのアサーションを実行することになるのかはまだわからない。

レシーバ・フレームワークはその取得可能な能力をアサーションに表すことによって公表することが出来、そのアサーションをレシーバ・ドメインの内側又は外側のアプリケーションに渡すことが出来る。そしてこのアプリケーションは、そのアサーションの実行、又はそのアサーションを別のアプリケーションに渡すのいずれかを行うことが出来る。この方法で、合意に従ってサービスを使用することを示す、承認権を有する合意が、非常に柔軟な方法で交換され得る。

付加的に、例えばアプリケーションのような、アサーションを渡すエンティティが、アサーションに認証、承認又は属性データを付加しても良い。この方法で、そのアプリケーションはアサーションをカスタム化できる。アサーションを交換する各ドメインは、付加的データを渡すこと及び該付加的データにアサーションに関連付けることができる。例えば、記載した能力を自身の能力で拡張あるいは制限することができ、このためある種の階層化アサーションとなる。

このサービス・アサーションの実施形態の下で、連合設定におけるドナー・フレームワークはこのように、以下の事項を受け持つ：
−図９Ｂが示すような、あるいは図６に示された上記のオフライン動作モードでの、ドナー・サービスの利用について、合意及び権利を表すサービス・アサーションの生成、
−図９Ａが示すような、新たに登録されたサービス、あるいはかなり新しいサービス・イネーブラ（ＳＣＳ−２）の公表；
−図９Ｃに含まれるような、サービス・アサーションをレシーバ・フレームワークに渡すメカニズムの提供。該メカニズムは、必要であれば、アサーションが交換されたこと及び拒否しないことが証明され得る、ステートメントの両方のパーティによる署名を含んでいても良く、アサーション又はその一部は暗号化されているのが好ましい；
−登録されたレシーバ・フレームワーク、あるいはドナー・ドメイン内にあるローカル・アプリケーションに渡されたアサーションの追跡；及び
−実行されたアサーションの有効性チェックのための要求の処理。このような要求は通常ドナー・サービスによって、あるいはより詳細には、図９Ｅに示されるようにサービス・イネーブラ（ＳＣＳ−２）内に位置するのが好ましいサービス・マネージャ・エンティティによって送信され、ドナー・フレームワークはそのアサーションが以前に実行されているかどうかをチェックする。

本発明によってサポートされる一般的な原理によれば、アサーションが実行され得るのは一度だけである。ドナー・フレームワークは、サービス・イネーブラ（ＳＣＳ−２）内に位置するのが好ましいサービス・マネージャ・エンティティに、アサーションがまだ有効であるのか否かを知らせる。それにもかかわらず、当業者のだれもが分かるように、サービス・イネーブラは、フレームワークに関与せずにアサーションの有効性をチェックするために、それ自身のメカニズムを有してもよい。

一方、このサービス・アサーションの実施形態の下で、連合設定におけるレシーバ・フレームワークは、以下の事項を受け持つ：
−図９Ｃに示されるような、サービス・アサーションのドナー・フレームワークへの受け渡しの要求。ここでそのようなアサーションを取得するためのメカニズムは、既に上記で述べたように、必要であれば、アサーションが交換されたこと及び拒否しないことが証明され得る、ステートメントの両方のパーティによる署名を含んでいても良く、アサーション又はその一部は暗号化されているのが好ましい；
−レシーバ・ドメイン内、及びおそらくは該レシーバ・ドメインの外部にあるアプリケーションへの、新たに取得した能力の公表；
−承認、認証及び‘階層化’アサーションを生成するための属性データを含む、要素のグループの少なくとも１つの要素についてのアサーション・データの付加；
−レシーバ・フレームワークがレシーバ・ドメインの代理として働き、レシーバ・ドメインが、イネーブラ、又はドナー・ドメインの能力をシールドするために、他のパートナー・ドメインに対する中間レイヤとして働くように意図されているときに通常は起こる、ドナー・サービスへのアサーションの提供、すなわちアサーションの‘実行’；及び
−図９Ｄに示されるような、アプリケーションからの要求に応じた、レシーバ・ドメイン内のそのアプリケーションへのサービス・アサーションのハンドオーバ。このメカニズムは、既に上記で述べたように、必要であれば、アサーションが交換されたこと及び拒否しないことが証明され得る、ステートメントの両方のパーティによる署名を含んでいても良く、アサーション又はその一部は暗号化されているのが好ましい。

これに関連して、レシーバ・フレームワークがサービス・アサーションを渡したとき、そのアサーションを自身が実行することはもはや許されないが、レシーバ・ドメイン内で該アサーションを受信したアプリケーションだけが、そのアサーションを実行すること、あるいは他のアプリケーションにそれを渡すことができる。

結局のところ、ドナー・ドメイン内のサービス・イネーブラ（ＳＣＳ）は以下の事項を受け持つ：
−ドナー・フレームワークに自身を登録すること；
−アサーションがドナー・フレームワークによってサインされたかどうか、及びオプションでアサーションが変更されたか否かを有効にする；
−最初のアサーションの受信に応じて、ドナー・フレームワークに、該アサーションが前記ドナー・フレームワークによって渡されたか、及びそのアサーションがまだ友好化どうかを有効にするために要求すること；及び
−ドナー・フレームワーク又はサービス・イネーブラ自身によるアサーションの承認に応じて、アサーション内に記載された合意の特性に従って実行者がサービスにアクセスするのを許可すること。

以上本発明を、図示したあるいは非限定的な方法でいくつかの実施形態に関して説明した。上記の教示に照らして、本発明の多くの変更や変形が可能であるのは明らかである。本発明の範囲は、本明細書及び図面に関連して特許請求の範囲によって決定され、これら特許請求の範囲内にある実施形態のあらゆる変更は、本発明の範囲に含まれるべきである。

本発明が適用される技術分野の基本的概要である、サービス・ネットワークとコア・ネットワークとの間の標準的インタフェースを示す図である。 ホーム公衆陸上移動通信網と相互作用するＯＳＡ／ＰＡＲＬＡＹのアーキテクチャを単純化した図である。 ある組織がコア・ネットワーク・ドメインを受け持ち、別の組織がパートナーを介したエンドユーザ・サービスの提供を受け持つ、ＯＳＡ／ＰＡＲＬＡＹの別の図である。 アプリケーション・プロバイダの代わりに、ネットワーク・オペレータ・ドメインにおいてサービス合意を生成するのを意図したドメイン自身を表す、エンタープライズ・オペレータの役割を示す図である。 ドメイン間のサービス合意の条件の下で、第１のドメインが第２のドメインのサービス能力を自身のクライアント・アプリケーションに提供できないという、現在の技術によるシナリオを示す図である。 両方のドメイン間のサービス合意の条件の下で、第１のドメインが第２のドメインのサービス・イネーブラを自身のアプリケーション・プロバイダに提供できないという、現在の技術によるシナリオを示す図である。 複合ネットワーク・ドメイン環境において、仮想グローバル・フレームワークが、サービス及びコア・ネットワーク間で相互作用するために、新たなフレームワークとフレームワークとのインタフェースを加えることによって構成され得る、コンパクトにしたアーキテクチャを示す図である。 より詳細には、複合ネットワーク・ドメイン環境において、仮想グローバル・フレームワークが、サービス及びコア・ネットワーク間で相互作用するために、新たなフレームワークとフレームワークとのインタフェースを加えることによって、一般的及びサービスのローミングで、遠隔サービス実行をサポートするいくつかのネットワーク・ドメインを有する分散アーキテクチャを示す図である。 フレームワークとフレームワークとのインタフェースのおかげで、第１のネットワーク・ドメイン・オペレータが、第１のアプリケーション・プロバイダに、別のネットワーク・ドメイン・オペレータのサービス・イネーブラ内のサービス能力機能を提供できる、いくつかのネットワーク・ドメインを有する分散アーキテクチャを示す図である。 フレームワーク、即ちドナー及びレシーバ・フレームワークの登録と、ドナー・ドメインからレシーバ・ドメインに利用可能なサービスの公表との基本的かつ単純化したステップを示す図である。 サービス合意の区分化に基づく詳細な実施形態に従ういくつかのシーケンスのうち、サービス・レベル合意がどのようにレシーバ・フレームワークに公表されるのかを示すシーケンスの図である。 連合サービス・プロファイルがどのように生成されるのかを示すシーケンスの図である。 連合ＳＣＦがどのようにレシーバ・フレームワークにインストールされ得るのかを示すシーケンスの図である。 連合サービス・レベル合意がどのようにサインされるのかを示すシーケンスの図である。 アプリケーション・サービス・レベル合意がどのようにサインされ得るのかを示すシーケンスの図である。 連合サービス・レベル合意がどのように終了され得るのかを示すシーケンスの図である。 プロキシ・イネーブラ・モデルに基づく詳細な実施形態に従い、サービス・アクセスを提供するいくつかのシーケンスのうち、プロキシがどのようにインストールされるのかを示すシーケンスの図である。 アプリケーション・サービス・レベル合意がどのようにサインされ、レシーバ・ドメインのローカル・ポリシーを施行する間に、プロキシＳＣＳが実際のＳＣＳへ要求を中継するのかを示すシーケンスの図である。 サービス・レベル合意がどのように終了されるのかを示すシーケンスの図である。 ＳＣＳがどのようにプロキシの代替として登録され得るのかを示すシーケンスの図である。 サービス・アサーションの交換に基づく詳細な説明に従ういくつかのシーケンスのうち、サービス・タイプがどのようにレシーバ・フレームワークに公表され得るのかを示すシーケンスの図である。 アサーション・プロファイル及びアサーションがどのように生成され得るのかを示すシーケンスの図である。 ドナー・フレームワークがどのようにレシーバ・フレームワークにアサーションを与え得るのかを示すシーケンスの図である。 レシーバ・フレームワークがどのようにアプリケーションにアサーションを渡し得るのかを示すシーケンスの図である。 レシーバ・アプリケーションがどのようにアサーションを実践し得るのかを示すシーケンスの図である。 本発明によるいくつかの好適な実施形態を含む、ローミング環境における位置決めサービスに関連した使用例を示す図である。

Claims (20)

1. クライアント・サービス・アプリケーション（Ａｐｐｌ−１）に、ＯＳＡ／ＰＡＲＬＡＹインタフェースを介してサービス能力機能を提供するように構成された通信システムであって、該システムは、
   クライアント・サービス・アプリケーションが実行される１以上のアプリケーション・サーバ（ＡＳ−１）と、
   第１のネットワーク・ドメイン（ＮＤＯ−１）内で第１のサービス能力機能が明確にされる１以上の第１のサービス・イネーブラ（ＳＣＳ−１）と、
   制御されたアクセスを前記第１のサービス能力機能に提供する第１のレシーバ・フレームワーク（ＦＷ−１）と、
   ユーザが加入するホーム・コア・ネットワークおよび／またはユーザがローミングする訪問先コア・ネットワークから選択された１以上のコア・ネットワーク（ＣＮ−１、ＣＮ−２）の要素と
   を備えており、
   前記レシーバ・フレームワーク（ＦＷ−１）が、該レシーバ・フレームワークの通信手段を用いて、少なくとも１つのドナー・フレームワーク（ＦＷ−２）に備えられた対応する通信手段と通信し、前記第２のネットワーク・ドメインに備えられた１以上の第２のサービス・イネーブラ（ＳＣＳ−２）内で特定された第２のサービス能力機能へアクセスするように構成されていることを特徴とする通信システム。
2. 前記レシーバ・フレームワークの前記通信手段及び前記ドナー・フレームワークの前記対応する通信手段が、フレームワークとフレームワークとの通信を可能とするプロトコル手段を含むことを特徴とする請求項１に記載の通信システム。
3. 前記プロトコル手段は、前記第２のネットワーク・ドメイン内の前記ドナー・フレームワークの存在を、前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークに対して公表する手段を含んでおり、それによってサービス能力機能が共有され得ることを特徴とする請求項２に記載の通信システム。
4. 前記プロトコル手段は、前記第２のネットワーク・ドメイン内のドナー・フレームワークから、前記第１のネットワーク・ドメイン内のレシーバ・フレームワークに対して、前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラから、前記第１のネットワーク・ドメインの前記クライアント・サービス・アプリケーションに提供され得る、サービス能力機能を公表する手段を含むことを特徴とする請求項３に記載の通信システム。
5. 前記ドナー・フレームワークの存在を前記レシーバ・フレームワークに対して公表する手段が、前記ドナー・フレームワーク自身を前記レシーバ・フレームワーク内に登録する手段を含むことを特徴とする請求項３に記載の通信システム。
6. 前記第２のネットワーク・ドメイン内の前記ドナー・フレームワークの存在を、前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークに対して公表する手段が、前記第１のネットワーク・ドメインのオペレータが、前記ドナー・フレームワークを前記レシーバ・フレームワーク内に登録するための手段を含むことを特徴とする請求項３に記載の通信システム。
7. 前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラから提供され得るサービス能力機能を公表する手段が、前記第２のネットワーク・ドメイン内の前記ドナー・フレームワーク）から、前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークに対して、サービス識別子、サービス・タイプ、サービス可用性、サービス特性及びサービス・インタフェースを含む要素のグループから、少なくとも１つのサービス情報の要素を通知する手段を含むことを特徴とする請求項４に記載の通信システム。
8. 前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラで利用可能なサービス能力機能の存在を公表する手段が、前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークから、第２のネットワーク・ドメイン内の前記ドナー・フレームワークに対して、サービス情報のそのような要素の通知の基準を生成する手段を含むことを特徴とする請求項７に記載の通信システム。
9. 前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークと、前記第２のネットワーク・ドメイン内の前記ドナー・フレームワークとの間で、前記第１のネットワーク・ドメインと前記第２のネットワーク・ドメインとの間のサービス合意、認証と承認、サービスの登録と発見機能およびインテグリティ管理の中から選択して実施する、セキュリティ管理メカニズムを実行する手段を含むことを特徴とする請求項１から８のいずれか１項に記載の通信システム。
10. 前記レシーバ・フレームワーク及び前記ドナー・フレームワークの間で、前記セキュリティ管理メカニズムを実行する手段は、前記第１及び前記第２のネットワーク・ドメイン間の前記サービス合意を記録する手段を含み、該サービス合意は、前記第１及び第２のネットワーク・ドメイン間に適用されるポリシーを表すことを特徴とする請求項９に記載の通信システム。
11. 前記レシーバ・フレームワーク及び前記ドナー・フレームワークの間で、前記セキュリティ管理メカニズムを実行する手段は、サービス・アサーション及び署名を渡す手段を含むことを特徴とする請求項９に記載の通信システム。
12. 前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークと前記第２のネットワーク・ドメイン内の前記ドナー・フレームワークとの間で、前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラで利用可能なサービス能力機能を発見する手段を更に含むことを特徴とする請求項１から１１のいずれか１項に記載の通信システム。
13. 前記レシーバ・フレームワークと前記ドナー・フレームワークとの間で、利用可能なサービス能力機能を発見する手段は、前記第１のネットワーク・ドメイン内の前記クライアント・サービス・アプリケーションによって要求されるのに応じて、特定の能力を取り決める手段を含むことを特徴とする請求項１２に記載の通信システム。
14. 前記レシーバ・フレームワークにおける前記通信手段と前記ドナー・フレームワークにおける前記対応する通信手段の各々は更に、前記第２のネットワーク・ドメイン内の対応するサービスをクライアント・サービス・アプリケーションが利用できるように、前記第２ネットワーク・ドメイン内の前記ドナー・フレームワークから前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワークに対して、前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラで生成されたサービス・インスタンスに対する参照を返送する手段を含むことを特徴とする請求項１３に記載の通信システム。
15. 前記第１のネットワーク・ドメインと前記第２のネットワーク・ドメインとの間に挿入され、前記第１のネットワーク・ドメイン内の前記クライアント・サービス・アプリケーションから前記第２のネットワーク・ドメインの前記第２のサービス・イネーブラに対するサービス要求のため、並びに反対方向の通信におけるプロキシとして働くことを意図されている、サービス・イネーブラ・プロキシを更に含むことを特徴とする請求項１から１４のいずれか１項に記載の通信システム。
16. 前記サービス・イネーブラ・プロキシは、前記第１のネットワーク・ドメイン内に設けられ、前記第２のネットワーク・ドメインの対応するサービス能力機能の参照を格納するために、前記第１のネットワーク・ドメイン専用のサービス能力機能を１以上備えていることを特徴とする請求項１５に記載の通信システム。
17. 前記第２のネットワーク・ドメイン内の前記ドナー・フレームワークから受信した、サービス識別子、サービス・タイプ、サービス可用性、サービス特性及びサービス・インタフェースを含む要素のグループから選択された、少なくとも１つのサービス情報の要素を含む情報に基づいて、前記第１のネットワーク・ドメイン内に前記サービス・イネーブラ・プロキシを自動的に生成する手段を更に備えることを特徴とする請求項１５に記載の通信システム。
18. 前記第２のネットワーク・ドメインからの、前記第１のネットワーク・ドメイン内に前記サービス・イネーブラ・プロキシを生成するよう意図された、ソースコードやランタイムコードをダウンロードする手段を更に備えることを特徴とする請求項１５に記載の通信システム。
19. 前記第１のネットワーク・ドメイン内の前記レシーバ・フレームワーク内に、前記第２のネットワーク・ドメインに対して前記サービス・イネーブラ・プロキシとして働く、前記第２のネットワークドメインの特定のサービス・イネーブラが登録されていることを特徴とする請求項１５に記載の通信システム。
20. 前記第１のネットワーク・ドメインは、前記ユーザの加入する前記ホーム・コア・ネットワーク（ＣＮ−１）を含み、前記第２のネットワーク・ドメインは、前記ユーザがローミングする前記訪問先コア・ネットワーク（ＣＮ−２）を含むことを特徴とする請求項１から１９のいずれか１項に記載の通信システム。

Images