(57)【要約】サービス融合ファブリック（１０３）が、複数の独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワーク（１０４）と、融合されたアプリケーション層（１００）との間に動作可能に配置される。そしてこのサービス融合ファブリックを用いて（２０２）、サービス要求を受け取り、サービス要求を処理し、対応する応答を提供し、およびその応答を公表してサービス要求を容易にする。サービス要求を処理することには、サービス要求と、サービス要求に対応するユーザ・セッション状態と、サービス要求に対応するユーザの選択とをサポートする資源に対してサービス要求を処理することが含まれる。応答を提供することには、処理されたサービス要求とサービス要求に対する融合された応答とのうちの少なくとも１つを含む応答を提供することが含まれる。
2009515429.tif 000002
【特許請求の範囲】
【請求項１】
独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む複数のネットワークと、
複数サービス・エンド・ユーザと
ともに用いる方法であって、
独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む前記複数のネットワークと、融合されたアプリケーション層との間のサービス融合ファブリックを提供すること、
サービス融合ファブリックを用いて、
サービス要求を受け取ること、
前記サービス要求をサポートする資源と、
前記サービス要求に対応するユーザ・セッション状態と、
前記サービス要求に対応するユーザの選択と
に関してサービス要求を処理すること、
処理されたサービス要求とサービス要求に対する融合された応答とのうちの少なくとも１つを含む応答を提供すること、
前記応答を公表して前記サービス要求のサポートを容易にすること、
を備える方法。
【請求項２】
サービス要求を受け取ることに、サービス融合ファブリックの外部のサービス・エンド・ユーザからサービス要求を受け取ることを含む、請求項１に記載の方法。
【請求項３】
サービス要求を受け取ることは、前記サービス融合ファブリックの外部のアプリケーションからサービス要求を受け取ることを含む、請求項１に記載の方法。
【請求項４】
サービス要求を受け取ることは、前記サービス融合ファブリックの一部を含むサービス管理要素からサービス要求を受け取ることを含む、請求項１に記載の方法。
【請求項５】
前記サービス要求をサポートする資源に対して前記サービス要求を処理することは、データベースにアクセスすることを含む、請求項１に記載の方法。
【請求項６】
データベースにアクセスすることは、データベースにアクセスして、
前記サービス要求をサポートする少なくとも潜在的に利用可能な資源についての情報と、
前記サービス要求をサポートする少なくとも潜在的に利用可能な資源の現在の利用可能性についての情報と、
前記サービス要求のサポートに関連する少なくとも潜在的に利用可能な資源に対応する既存の許可についての情報と、
のうちの少なくとも１つについての情報を得ること、を備える請求項５に記載の方法。
【請求項７】
前記サービス要求を、前記サービス要求に対応するユーザ・セッション状態に対して処理することは、サービス要求に関係するエンド・ユーザに対する実質的に現在のセッション状態についての情報を用いることを備える、請求項１に記載の方法。
【請求項８】
前記サービス要求に関係するエンド・ユーザに対する実質的に現在のセッション状態についての前記情報は、
特定のエンド・ユーザが現在アクティブなセッションを有しているかどうかについての情報と、
特定のエンド・ユーザの代わりに現在アクティブであるアプリケーションについての情報と
のうちの少なくとも１つを備える、請求項７に記載の方法。
【請求項９】
前記サービス要求に対応するユーザ選択に関する前記サービス要求を処理することは、
所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての予め設定されたルールと、
所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての動的に設定されたルールと、
のうちの少なくとも１つについての情報を用いることを備える、請求項１に記載の方法。
【請求項１０】
前記ユーザ選択は、少なくとも部分的には、
前記サービス要求を開始したエンティティと、
前記サービス要求を容易にするために使用される資源と、
前記サービス要求に関与するエンティティと、
前記サービス要求の受益者と、
前記サービス要求を容易にするために用いられるアプリケーションと、
のうちの少なくとも１つによって行なわれる、請求項９に記載の方法。
【請求項１１】
前記サービス要求を処理することは、前記サービス要求の少なくとも一部を、資源プロセッサ、セッション状態プロセッサ、および選択プロセッサのそれぞれにルーティングすることを含む、請求項１に記載の方法。
【請求項１２】
前記サービス融合ファブリックを用いて応答を提供することは、資源、ユーザ・セッション状態、およびユーザ選択についての情報をサービス管理ネットワーク要素に提供することを含む、請求項１に記載の方法。
【請求項１３】
前記情報をサービス管理ネットワーク要素に提供することはさらに、情報を処理して、前記サービス要求を処理する複数の潜在的な方法の中からサービス要求を処理する特定の方法を選択することを備える、請求項１２に記載の方法。
【請求項１４】
前記処理されたサービス要求を公表してサービス要求のサポートを容易にすることには、
前記処理されたサービス要求についてのイネーブリング情報を、
サービス要求の要求者と、
少なくとも１つの資源所有者と、
サービス融合ファブリック内の別のサービス管理ネットワーク要素と、
のうちの少なくとも１つに提供することを備える、請求項１に記載の方法。
【請求項１５】
サービス融合ファブリックにおいて用いられる装置であって、サービス融合ファブリックは、独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む複数のネットワークと、融合されたアプリケーション層との間に配置され、前記装置は、
サービス要求受信部と、
前記サービス要求受信部に動作可能な状態で結合されるサービス要求ルータと、
前記サービス要求ルータに動作可能な状態で結合され、前記サービス要求のサポートに対応する資源利用可能性を評価するように構成および配置される、資源評価部と、
サービス要求ルータに動作可能な状態で結合され、サービス要求のサポートに対応するユーザ・セッション状態を評価するように構成および配置されるユーザ・セッション状態評価部と、
サービス要求ルータに動作可能な状態で結合され、サービス要求のサポートに対応するユーザ選択を評価するように構成および配置されるユーザ選択評価部と、
資源評価部、ユーザ・セッション状態評価部、およびユーザ選択評価部に動作可能な状態で結合され、処理されたサービス要求応答を公表してサービス要求受信部が受け取るサービス要求のサポートを容易にするように構成および配置されるサービス要求公表部と、を備える装置。
【請求項１６】
前記サービス要求受信部は、サービス・エンド・ユーザと、アプリケーションと、サービス融合ファブリックの一部を含むサービス管理ネットワーク・エンティティとのいずれかからサービス要求を受け取るように構成および配置される、請求項１５に記載の装置。
【請求項１７】
資源利用可能性についての情報を資源評価部から受け取り、ユーザ・セッション状態についての情報をユーザ・セッション状態評価部から受け取り、およびユーザ選択についての情報をユーザ選択評価部から受け取るとともに、情報を用いてサービス要求を処理することによって、公表可能な処理されたサービス要求応答をサービス要求公表部に提供するサービス管理ネットワーク要素をさらに備える、請求項１５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、サービス融合ファブリック（ｓｅｒｖｉｃｅ  ｃｏｎｖｅｒｇｅｎｃｅ  ｆａｂｒｉｃ）に関し、より詳細には、サービス要求に対してファブリックを用いることに関する。
【背景技術】
【０００２】
いろいろな種類のネットワークが当該技術分野において知られている。これらに含まれているのは、説明用の例として挙げれば、アクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークである（当業者であれば認めるように、どんな所与のネットワークも、これらのネットワーク形式のうちの１つまたは複数として機能し、所与のネットワークにたとえばアクセス・ネットワークおよび制御ネットワークの両方が含まれる場合もある）。場合によっては、統合の限られた様相を、このようなネットワークの２つ以上に適用する場合がある。しかしより一般的には、このようなネットワークは多かれ少なかれ、互いに独立に動作する。（本明細書で用いる場合、「独立した」は次のものを指す。すなわち、技術的独立性（２つのネットワークが動作的に互いと互換しないような場合）、アクセス独立性（２つのネットワークが、たとえば容易にするための接続が両者の間にないために、互いにアクセスすることができないような場合）、および／または動作上の独立性（２つのネットワークが、両者間の透過的なやり取りが全体的にまたは部分的に排除されるように、別個に管理されるような場合）である）。
【０００３】
結果として、技術の典型的な現代ユーザが、日常生活において、膨大な数の異なるサービスおよび／またはエンド・ユーザ・デバイスに囲まれていることが分かる。これらのサービスおよびデバイスは、多くの場合に、互いにまったく独立に動作するものである。当然のことながら、エンド・ユーザ・デバイスが、エンド・ユーザに対してまったく別個のサービスを行なう場合、このような区別による問題は、従来技術の点からは現時点ではほとんど存在しない。たとえば、無線電話によって双方向の音声電話サービスが実現している一方で、テレビジョンによってテレビ放送の受信が実現していることに注目した場合、現時点での問題はほとんど存在しない。すなわち、このようなネットワーク間に統合が無いことは、従来技術の観点では問題とする必要がない。
【０００４】
このように問題が無いことは重大である。このことが特に明白となるのは、場合によっては既存のネットワーク統合の中に、このような統合が示す潜在性をもっと積極的に活用することを伴わないものもあることを考えたときである。たとえば、現在のところケーブル・サービス・プロバイダは、電話サービスおよびテレビ受信サービスの両方を、統合型ネットワークを介して実現していることが多い。しかしたいていは、多くの場合に、この統合が関係しているのは、転送のモードの方であり、その統合型ネットワークを介して与えられるサービスの統合の方ではない。
【０００５】
このような状態が存在する主な原因は、別の問題にある。すなわち、現時点で従来技術を代表するアプリケーションが莫大な数および形式だけ存在するからである。アプリケーションには、種々のサービスおよびアクションが所与のエンド・ユーザ（または他のネットワーク要素またはノード）の代わりに最終的に行なわれる伝達手段が含まれている。言い換えれば、ネットワークによって、アプリケーション・ベースのサービスが所与のエンド・ユーザまで届く導管が実現されている。たとえば電話アプリケーションは、電話サービスが所与のエンド・ユーザに所与のネットワークを介して届くことを可能にするものである。
【０００６】
所与のアプリケーションを所与のネットワーク内でまたはネットワークを使ってうまく動作させるには通常、相当なそのネットワーク特有の知識とその他の知識（ｖｅｒｔｉｃａｌ  ａｗａｒｅｎｅｓｓ）が必要である。当然のことながら、この状況は、ほとんどのネットワークがどちらにしても互いに独立しているという単純な事実を反映したものである。そのため、所与のアプリケーションの範囲を複数のネットワークに渡って広げようとする意図は、どれも大きく失敗に終わっている。所与のアプリケーションが複数のネットワーク上で動作する場合はある。しかしこのような場合も通常は、アプリケーション設計者またはネットワーク設計者によって、このような操作性に適応しようとする多大な努力が払われたことを反映したものである。このように高度にカスタマイズされた解決方法は、所与の場合には有用であるが、可能性をほとんど啓発されてこなかった。
【０００７】
このような問題に対処するために提案された解決方法の１つとして、一方で複数の独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークと、他方では融合されたアプリケーション層との間に介在するサービス融合ファブリックが挙げられる。（たとえば、以前に出願された「サービス融合ファブリックを容易にする方法（ＭＥＴＨＯＤ  ＴＯ  ＦＡＣＩＬＩＴＡＴＥ  Ａ  ＳＥＲＶＩＣＥ  ＣＮＶＥＧＥＮＣＥ  ＦＡＢＲＩＣ）」と題された、２００４年１１月２２日出願された仮出願６０／６３０，１０６号明細書を参照のこと。なおこの文献の全内容は、本明細書においてこの参照により組み込まれている）。適切に構成され実施されれば、このようなサービス融合ファブリックは、複数のアクセス・ネットワークおよび制御ネットワークに対するアプリケーション・サーバとして効果的に機能するとともに、複数のサービス・ネットワークに対する制御サーバまたはアプリケーション・ゲートウェイとして効果的に機能する。異なる側面で見ると、レガシー・ネットワークとともに動作する能力を保つために、サービス融合ファブリックは好ましくは、サービス・ネットワークとのやり取りを、アクセス・ネットワークまたは制御ネットワークの挙動のそれと整合する方法で行ない、一方でアクセス・ネットワークまたは制御ネットワークとのやり取りを、サービス・ネットワークの挙動のそれと整合する方法で行なう。このようなサービス融合ファブリックは通常、次のうちの少なくとも１つについての情報にアクセスすることができる。すなわち、エンド・ユーザ情報、サービス情報、ネットワーク情報、デバイス情報、資源情報、アプリケーション情報、および／またはエッジ・ゲートウェイ情報である。
【０００８】
このような情報アクセスによって、サービス融合ファブリックが、複数のネットワークにおける少なくとも１つのエンティティについてのコンテキスト情報を取得すること、およびこれらのネットワークの少なくとも１つに対応付けられる少なくとも第１のエンティティに対応する他の情報（特にトリガリング情報を含む）を取得することが、可能になり容易になる。そして後者の情報は、サービス融合ファブリック内においてコンテキスト情報に対して処理されて、処理された情報が形成される。そして処理された情報は、複数のネットワークのうちの１つまたは複数に対応付けられる少なくとも１つのエンティティに分配される。
【０００９】
このような構成によって、サービス融合ファブリックの利用を可能にし、サービスの統合をもたらす。この統合は、サービス融合ファブリックによって、少なくとも部分的に、融合されたアプリケーション層の所与のアプリケーションに対して自動的で透過な方法で行なわれるので、所与のアプリケーションは、複数の候補ネットワークの中からの動的に選択と利用とによって容易に実行することができる。この結果、ネットワーク資源に対する活用の度合いが、以前は利用できなかった程度まで可能になる。所与のアプリケーションが、本来は独立している複数のネットワークを介して所与のサービスを配信できるようになるにつれて、エンド・ユーザの体験はより透過的で直観的になる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
このように構成されていれば、所与のエンド・ユーザは、複数のアクセス・ネットワークにまたがる複数の動作及び／又は通信セッションや、異なるエンド・ポイントおよびネットワークに接続されたポイントを使用する複数の動作及び／又はセッションや、異なるアプリケーション・サーバを伴い、異なる管理ドメインの下で動作する複数の動作及び／又は通信セッションに関与している（ここで「管理ドメイン」は、ネットワーク接続されたコンピュータのグループであって、各コンピュータは何らかの方法で（たとえば１つまたは複数の共通の通信アドレスを用いて）提携され、通常は特定の所有者または管理者の援助の下で操作されるような、コンピュータのグループであると理解される）。しかし同時に、種々のサポーティング・アクセス・ネットワーク、アプリケーション・サーバ、および／またはエンド・ポイントは、本質的に互いに独立に機能してもよい。この結果、独立した管理ドメインに渡って本来は適応されているエンド・ユーザの融合サービスの追跡、調整、および／または管理が失敗する可能性がある。
【発明を実施するための最良の形態】
【００１１】
前記の必要性は、以下の詳細な説明に記載されるサービス融合ファブリックの使用についての方法および装置を提供することによって、特に図面とともに検討したときに、少なくとも部分的に対処される。
【００１２】
当業者であれば理解するように、図の要素は、簡潔および明瞭を目的として例示されており、必ずしも一定の比率で描かれてはいない。たとえば、図の要素のいくつかの寸法および／または相対的な位置付けは、本発明の種々の実施形態の理解の向上を助けるために、他の要素に対して誇張されている場合がある。また商業的に実現可能な実施形態において有用かまたは必要である一般的だが良く理解されている要素は、示していないことが多い。これは、本発明のこれらの種々の実施形態の見え方をなるべく邪魔しないようにするためである。さらに次のことが理解される。すなわち、あるアクションおよび／またはステップを、特定の順番で現れるように記載するかまたは示している場合があるが、当業者であれば分かるように、手順に対するこのような特定性は実際には必要ではない。また当然のことながら、本明細書で用いる用語および表現の意味は、このような用語および表現に、対応する個々の照会および検討の範囲に対して与えられる普通の意味である。ただし、特定の意味が本明細書で述べられている場合を除く。
【００１３】
一般的に言って、これらの種々の実施形態によって、複数のネットワーク（独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む）と、融合されたアプリケーション層との間のサービス融合ファブリックが提供される。そして、このサービス融合ファブリックを用いて以下のことを行なう。すなわち、サービス要求（すなわち、１つまたは複数の特定のまたは暗示のサービスたとえば接続性関連のサービス、アプリケーションまたはアプリケーション・サポート・サービスなどの提供を求める特定のまたは暗示の要求）を受け取り、サービス要求を処理し、対応する応答を提供し、その応答を公表してサービス要求を容易にする。異なるドメインを有するマルチ・ネットワーク、マルチ・アプリケーション、マルチ・デバイス・システムでは、受け取ったサービス要求は、全体としてシステムの点から見ると不完全で／記述が不適切な場合がある。たとえばサービス要求は、特定のアプリケーション・サービス・ネットワークに特有の場合があり、その形成中にそのネットワークのみを考慮している場合がある。サービス要求を処理することは、サービス要求と、サービス要求に対応するユーザ・セッション状態と、サービス要求に対応するユーザ選択とをサポートする資源に対してサービス要求を処理することを含む。応答を提供することは、処理されたサービス要求とサービス要求に対する融合された応答とのうちの少なくとも１つを含む応答を提供することを含む。融合された応答は、少なくとも部分的には、複数のアクセス・ネットワーク、サービス・ネットワーク、デバイスおよび／またはアプリケーションに渡って行なわれる処理を包含する要求に対する応答であって、より全体的に認識される応答を形成するものである。同様に、処理されたサービス要求は、少なくとも部分的には、複数のアクセス・ネットワーク、サービス・ネットワーク、デバイスおよび／またはアプリケーションに渡って行なわれる処理を包含する要求であって、要素ネットワークおよび／またはデバイスに対する、より適切な要求を形成するものである。
【００１４】
１つのアプローチによれば、サービス融合ファブリックは、サービス要求受信部、サービス要求ルータ、および複数のサービス要求処理サブ要素から構成される要素を備える。例としては、サービス要求のサポートに対応する資源利用可能性を評価するための資源評価部、サービス要求のサポートに対応するユーザ・セッション状態を評価するためのユーザ・セッション状態評価部、サービス要求のサポートに対応するユーザ選択を評価するためのユーザ選択評価部が挙げられる。１つのアプローチによれば、サービス管理ネットワーク要素は、資源利用可能性、ユーザ・セッション状態、およびユーザ選択について得られる情報を受け取って、サービス要求を処理し、結果として得られる公表可能な処理されたサービス要求を提供する。サービス要求公表部は、このような公表可能な処理されたサービス要求を受け取って公表することによって、サービス要求のサポートを容易にする。
【００１５】
１つのアプローチによれば、この処理されたサービス要求は、修正されたサービス要求である。このサービス要求を、サーバまたはネットワーク要素へ送って、そこで要求を実現しても良い。また処理されたサービス要求は、要求エンティティに対する応答の形式を取ることで、それを適切なサーバへ送ってサービス実現のために用いても良い。さらに必要に応じて、複数の処理された出力サービスが、要求から生じる。この状況の例は、アプリケーション挙動が別個のアプリケーション・サーバ上に分割されるときである（たとえば、１つのアプリケーション・サーバが所有する単一のビデオ／オーディオ・セッション（おそらくは、サード・パーティ・プロバイダが所有するローカル・エリア・ネットワーク接続されたボイス・オーバー・インターネット・プロトコル／ビデオ・コールであって、住宅用インターネット・プロトコル・ゲートウェイを通して単一のレンダリング・デバイスへ移植されるもの）が、２つの別個のアプリケーションに分割するようにユーザによって要求されても良い。この場合、１つは、住宅電話を用いてオーディオ部分をサポートするためのものであって、住宅電話の公衆交換電話網ラインがローカルな公衆交換電話網キャリアによってサービスされるものであり、同時に、元のセッションのビデオ部分が、ケーブル・オペレータによってサービスされる住宅テレビに流される）。実際には、必要に応じて、サービス要求処理サブ要素は、サーバに対する処理された要求を公表して使用する資源を確定すること、および要求者に対する応答（要求者をその資源へ導く）を公表することを判決定しても良い。
【００１６】
このような構成（たとえば、単一のコール・サーバまたはゲートウェイに基づくアーキテクチャとは異なる）は、複数の異なるコール・サーバおよび／またはアプリケーション・サーバに勝る。この結果、複数の形式のコール・サーバを効果的に連続的に接続することができるため、エンド・ユーザと融合されたアプリケーションとの両方の観点から融合が実現される。結果として、全体として同期されたサービス挙動の実現が、全体の容量、待ち時間、および／または実施コストに対して必要以上に妥協することがほとんどかまたはまったく予想されずに行なわれる。
【００１７】
これらの利益および他の利益が、以下の詳細な説明を十分に評価および検討することによって、より明瞭になる。次に図面、特に図１を参照して、当業者であれば理解するように、任意の数のアプリケーション（たとえば、１番目のアプリケーション１０１〜Ｎ番目のアプリケーション１０２）が、融合されたアプリケーション層１００を構成している。これらのアプリケーションは、サービス融合ファブリック１０３に、適切な対応するアプリケーション・プログラミング・インターフェース（図示せず）を介して接続されて機能する。同様に、サービス融合ファブリック１０３には通常、複数のネットワーク・インターフェース（図示せず）が含まれている。このようなネットワーク・インターフェースのそれぞれは通常、１つ（または、それほど一般的ではないが、複数）の対応するネットワーク（たとえば、１番目のネットワーク１０５〜Ｍ番目のネットワーク１０６のうちのいずれか）と、共用できるやり取りを行なう。１番目のネットワーク１０５〜Ｍ番目のネットワーク１０６は、一般に好まれる独立したアクセス・ネットワーク、制御ネットワーク、および／またはサービス・ネットワーク１０４を構成する（各ネットワーク・プロバイダ・ドメインにおける資源とやり取りするために、サービス融合ファブリック１０３は、たとえば特定アクセス・ネットワーク向けプロトコルたとえばセッション開始プロトコルまたはＯＳＡ／パーレイを基にする。たとえば、インターネット・プロトコル・マルチメディア・サブシステム（ＩＭＳ）用法の場合には、サービス融合ファブリック１０３は、インターネット・プロトコル・マルチメディア・サブシステム・サービス・コントロール（ＩＳＣ）インターフェース（セッション開始プロトコルに基づく）を基にすることができる）。
【００１８】
当該技術分野において理解されるように、サービス融合ファブリック１０３自体は、次のようなエンジンを有する層を備える。すなわち、エンジンとして、サービス融合ファブリック１０３が情報を得ることを可能にし、その情報を用いて、エンド・ユーザに送られているコンテントの処理を行ない、および／または他の場合には、このようなコンテントを、種々のネットワーク（所与の場合にこのようなサービスに対して利用可能であり得る）を介して送ることを実施および選択するエンジンである。一般的に言って、このようなサービス融合ファブリック１０３は、複数のサービス融合処理機能および複数のサービス融合サポート機能（図示せず）を備える。
【００１９】
より詳細には、サービス融合ファブリック自体は、以下の機能要素の一部または全部からなる。
融合調整機能：この機能は好ましくは、以下のうちの少なくとも１つを融合したものを提供する。すなわちユーザＩＤ、デバイス、アクセスおよびサービス所有権、セッション制御、および資源能力である。融合調整機能には、論理エンティティとして、他の特徴に加えて、コンテキスト情報および他の情報を処理してサービス統合を行なうものが含まれる。入力を、サービス・プロバイダおよびオペレータ・データベース、手入力されたプロファイル情報から、ならびに／または対応するネットワーク、エッジから、ならびに／またはエンド・ユーザ・サポート機能から得る。そしてこの情報は、種々のアプリケーションによって、アプリケーション・プログラミング・インターフェースを介してかまたは他のネットワーク・エンティティからのメッセージを介して、アクセスされる。このアクセスは、プロトコルたとえばセッション開始プロトコル、ハイパー・テキスト転送プロトコル、拡張可能マークアップ言語、または現在のところ存在し得るかもしくは後に開発され得る他のメカニズムを用いて行なわれる。アプリケーションからの要求に基づいて、融合調整機能は、資源割り当ておよび／または割り当て解除、セッション開始、変更、および／または終了などの機能も行なう。これには、コア・ネットワーク、アクセス・ネットワーク、エッジ・ネットワーク、もしくはエンド・ユーザ・デバイスにおけるサポート機能とのやり取り、または適切な特定レガシー技術向けプロトコル（または複数のプロトコル）を介してのレガシー・インターフェースとのやり取りが伴っても良い。これらの機能は、融合調整機能デバイスまたはプラットフォームによって直接行なっても良いし、リダイレクト機能によって間接的に行なっても良い。また融合調整機能は、ネットワーク・サポート機能、エッジ・サポート機能、またはクライアント・サポート機能のうちの１つまたは複数による要求に応答してアクションを行なっても良い。
【００２０】
ネットワーク・サポート機能：この機能は、セッション制御ネットワークに接続して、あるいはエッジ・インフラストラクチャ・デバイスおよび／またはクライアント・デバイスに接続して機能する。また融合調整機能にも接続して機能する。そしてセッション、アクセス、および権利情報を調整機能に提供する。この情報の一部は、エッジ・デバイスにもエンド・ユーザ・デバイスにも利用可能でなくても良い。またネットワーク・サポート機能は、融合調整機能によるコマンドに応答してアクションを行なっても良い。
【００２１】
エッジ・サポート機能：この機能は、アクセス・ネットワークおよびクライアント・デバイスに接続して機能する。この機能は、エンド・ユーザの管理制御下のデバイス内にあっても良い。また融合調整機能にも接続して機能する。またセッション情報、資源情報、それ自身についてのＩＤ情報、それを調整機能まで延ばすデバイスについてのＩＤ情報を提供する。またエッジ・サポート機能は、融合調整機能によるコマンドに応答してアクションを行なっても良い。
【００２２】
クライアント・サポート機能：この機能は、アプリケーションとクライアント・デバイス内に存在する資源とに接続して機能する。これらの資源には、ネットワーク・アクセス、制御資源、フォーマット変更もしくはコンテント・トランスコーディング、メディア資源たとえばヒューマン・インターフェース（入力もしくは出力）能力、または他の資源が、含まれる。クライアント・サポート機能は、それ自身についてのこの情報を融合調整機能に提供する。またクライアント・サポート機能は、融合調整機能によるコマンドに応答してアクションを行なっても良い。
【００２３】
当業者であれば注意し理解するように、アプリケーションおよびアプリケーション・サーバは、融合調整機能から情報を受け取り、また情報を、融合調整機能へ、アプリケーション・プログラミング・インターフェースまたは標準化されたプロトコルを介して提供することもできる。このように、当業者であれば了解して理解するように、個々のアプリケーションを他のものと融合することが、サービス融合ファブリックを通して可能となる。
【００２４】
このように構成され実施されれば、サービス融合ファブリック１０３は、融合されたアプリケーション層１００におけるアプリケーションからコンテントを受け取り、および／または能力を最終的なエンド・ユーザ１０７情報消費者へ配信することができる。このアクションは、アプリケーション・サービスの初期配信時におよび／またはこのような配信中に、行なわれる。サービス融合ファブリック１０３は、アプリケーション能力を所与のエンド・ユーザ１０７へ配信することを、現在の状況に最も良く適合する方法で、またその他の場合には、その特定のエンド・ユーザ１０７または設定に最も関連するコンテキストを考慮することによって、行われる。
【００２５】
１つのアプローチによれば、融合調整機能およびサポート機能の複数の様相が、サービス融合ファブリックの機能を提供するために存在する。必要に応じて、融合調整機能をサポート機能と同じ場所に配置することで、両方のファブリック要素の機能を行なう１つのデバイスを実現する。
【００２６】
したがってサービス融合ファブリック１０３は、複数のアクセス・ネットワーク上で透過的に動作するサービスをアプリケーション開発者が作成することを可能にする融合されたサービス機能を提供するものと考えられる。これを可能にするために、この機能性は、融合されたアプリケーションに共通の特徴をサポートすることが好ましい。これには、ユーザのＩＤ、状態、およびプロファイル；デバイスのＩＤ、状態、およびプロファイル；セッション状態；および場所（これらは少しの例である）を、複数のネットワークに渡って追跡することが含まれる。少なくとも、ユーザおよびそのセッション、資源、ならびにアクセスについて収集された情報は、融合されたサービス開発者が使用できる単純なアプリケーション・プログラミング・インターフェースを用いて公開されることが好ましい。このより豊富な融合機能によって、相反する資源要求を分析すること、プロファイルおよび状態情報に基づいてサービスに優先順位をつけること、調整の負担の一部からアプリケーションを解放することが支援され、またレガシー・アプリケーションが他のアクセス・ネットワークおよびデバイスへ移動される。
【００２７】
特に、このようなサービス融合ファブリックは、以下のことを促進しおよび／または容易にするように見える。−（仮想の）融合されたネットワークの一部を形成するすべてのネットワークにおける呼び出し制御機能およびサービス資源とやり取りすること。−複数のアプリケーションに共通のＩＤ、セッション、状態、および選択をユーザごとに管理すること。−アプリケーション開発者がサービス論理を実施するためのオープン・インターフェースを提供すること。−各ネットワークにおけるエンド・ユーザ・デバイスおよび他のエンティティと、ネットワークの固有プロトコルを用いて通信すること。
【００２８】
これらの機能を組み合わせた結果、ネットワークおよびデバイスに渡ってシームレスでユーザ中心のサービス移動を達成するためのフレームワークが実現される。これには、たとえば、融合されたサービスが少なくとも部分的に複数のコア・ネットワークの協調動作および相互動作に基づくようにすることを含み、また可能に、少なくとも一部のコア・ネットワークは、互いに異なるドメイン内にある。このようなサービス融合ファブリック１０３によって、ＩＤ、セッション、サービス、ならびにネットワークおよびデバイス資源をアプリケーションと調整する手段が、効果的に提供される。用語「ファブリック」によって暗示されるように、このような統合サービス・サポートは、複数のイネーブリング・プラットフォーム上で集中および／または分配することができる。
【００２９】
次に図２を参照して、以上のようなサービス融合ファブリックを、一方で複数の独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークと、他方では融合されたアプリケーション層との間に提供すること２０１を想定する。そして開示したプロセス２００が、そのサービス融合ファブリックを用いること２０２を行なって、一連の関連タスクを容易にするとともに実施する。この一連のステップは一般的に、サービス要求を受け取ったときに始まる。このサービス要求には、以下の要求が含まれている。たとえば、新しいサービスを開始する要求、新しい資源を既存のサービスに加える要求、既存のサービスに対応する状態を変える要求、所与のサービスを１つのネットワークから別のネットワークへ移動させる（または１つのエンド・ユーザ・デバイスから別のエンド・ユーザ・デバイスへ移動させる）要求など。
【００３０】
このサービス要求は、サービス融合フィールド自体の外部にあるサービス・エンド・ユーザから受け取る。しかし別のアプローチによれば、このサービス要求は、サービス融合ファブリックの外部のアプリケーションまたはネットワーク要素から受け取る。またさらに別のアプローチによれば、このサービス要求を、サービス融合ファブリック自体の内部から受け取る（たとえば、このサービス要求を、サービス融合ファブリックの一部を含むサービス管理要素によって供給される。これについては以下で詳細に説明する）。
【００３１】
そしてこのプロセス２００によって、受け取ったサービス要求の処理を、サービス要求と、ユーザ要求に対応するユーザ・セッション状態と、サービス要求に対応するユーザ選択とをサポートする資源に対して行なうことが実現される。当業者であれば理解するように、ユーザ要求または別のエンティティによる要求に対応するユーザ・セッション状態は、この状態が対応するもの以外のサービスのセッションに関係していても良い。たとえばユーザ・セッション状態は、ユーザが「オフ・フック」であって電話呼び出しにおける別の点に接続されている場合に関する。サービス要求は、何らかの他のサービスに関していても良い。たとえば、ユーザに対する場所ガイドされた「プッシュ」広告である。サービス要求は、電話呼び出しセッションに当然に結合されるわけではない。しかし「ユーザは電話呼び出し中でビジーである」というユーザ・セッション状態は対象範囲である。したがってこの意味および例において、ユーザ・セッション状態はユーザ要求に対応しているとみなされる。１つのアプローチによれば、この処理には、サービス要求の少なくとも一部を、資源プロセッサ、セッション状態プロセッサ、および選択プロセッサのそれぞれに送ることを含め（これらのプロセッサは、統合されたプラットフォームを共有しても、離散的なエンティティを備えていてもる）。
【００３２】
サービス要求の処理を、サービス要求をサポートする資源に対して行なうことには、データベースにアクセスすること、たとえば以下の情報の少なくとも１つについての情報を含むデータベースにアクセスすることが含まれる。すなわち、サービス要求をサポートする少なくとも潜在的に利用可能な資源についての情報、サービス要求をサポートする少なくとも潜在的に利用可能な資源の現在の利用可能性についての情報、および／またはサービス要求のサポートに関連し得る少なくとも潜在的に利用可能な資源に対応する既存の許可についての情報である。当業者であれば認めて理解するように、本明細書で用いる場合、「資源」は任意のベアラ・メカニズム（たとえばベアラ・チャネルもしくは他のサポート機能性、割り当て可能な拡散コード、時間スロット、サービス・レベルの品質、これらはほんの少しの例である）または他のサポート機能性（たとえば特定のコーディング・プラットフォームもしくはアプローチ、暗号化など）に関する。また「資源」は、当業者によって、所与のサービスを設定し、維持し、および／または終了させるのに有用かまたは必要であり得る任意のアプリケーション・レンダリング資産に関するものと理解される（所与のサービスには以下のものが含まれる（しかしこれらに限定されない）。サービス許可、ネットワーク許可、アクセス・ネットワーク能力（たとえばバンド幅またはサービスおよびそれらの特性（たとえばサービスの品質、サポートされるかまたは必要とされるプロトコル（たとえばＭＰＥＧ−４、ボイス・オーバー・インターネット・プロトコル、いわゆる加入電話サービス（ＰＯＴＳ）など）））、ユーザが利用できるアドレス可能なデバイスなど）。
【００３３】
サービス要求の処理を、サービス要求に対応するユーザ・セッション状態に対して行なうことには、サービス要求に関係するエンド・ユーザに対する実質的に現在のセッション状態についての情報を用いることを含めることができる。このような情報としてはたとえば、特定のエンド・ユーザが現在アクティブなセッションを有しているかどうかについての情報および／または特定のエンド・ユーザの代わりに現在アクティブであるアプリケーションについての情報が含まれる。このような情報を集めることは、たとえば、ユーザ・セッションの現在の状態を追跡するセッション・モニタを介して行なわれる。このような情報によって、以下についての見識が効果的に得られる。すなわち、所与のエンド・ユーザが現在ビジーであるかどうか、所与のアプリケーションが現在ビジーであるかどうか、または所与のエンド・ユーザが、特定のタイプのサービス（またはアプリケーション）のみを現在受け入れられるような状態にあるかどうかなどである。
【００３４】
サービス要求を、サービス要求に対応するユーザ選択に対して処理することには、以下のうちの少なくとも１つについての情報を用いることを含む。すなわち、所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての予め設定されたルールおよび／または所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての動的に設定されたルールである。（当業者であれば理解して認めるように、本明細書で用いる場合、「サービス受益者」は、次のうちどれを指しても良い。すなわち、エンド・ユーザ、アプリケーション、または本質的に任意のサービス要求ソースもしくは他のエンティティ（特定のサービス要求を行なうことから生じる利益の全部または一部を受け取るもの）である）。
【００３５】
より詳細には、このようなユーザ選択は、少なくとも部分的には、サービス要求を開始したエンティティ（たとえばプラットフォームまたは機能）、サービス要求を容易にするために使用され得る資源、サービス要求に関与し得るエンティティ、サービス要求の受益者、サービス要求を容易にするために用いられるアプリケーションなどのうちの、少なくとも１つによって行なわれる。これらの選択は、たとえば、どの特定のアクションが、どのトリガリング状況の下で、およびどのユーザ（またはアプリケーション、ネットワーク、もしくはデバイス）状態条件の下で起こるかなどについてのルールまたは優先度に、関係すること。一般的に言って、これらの選択によって、特定のサービスを所与のエンド・ユーザにどのように提供すべきかが規定される。
【００３６】
場合によっては、このような処理はフィルタリング・アクションとして効果的に機能する。すなわち、情報要求（または少なくともその一部）を前記の各観点から考慮することによって、要求されたサービスを容易にするためにどの資源が利用できるか、１つまたは複数の必要な要素または任意的な要素の動作の現在の状態が、１つまたは複数のサービス配信オプションと共存できるかどうかなどについての状況をまとめる。
【００３７】
このような作成された情報を考慮して、このプロセス２００は次に、サービス要求に対する応答を提供する。すなわち、１つのアプローチによれば、このサービス要求応答は、少なくとも部分的には、前記したように以前に作成された資源、ユーザ・セッション状態、および関連性のあるユーザ選択についての情報の関数として形成される。１つのアプローチによれば、サービス管理ネットワーク要素は、このサービス要求応答の一部または全部を形成する。このサービス管理ネットワーク要素を、１つまたは複数の特定のドメインに（たとえば所有権および／または動作管理を通して）具体的に対応付けても対応付けなくても良い。１つのアプローチによれば、このサービス管理ネットワーク要素は他の情報源にアクセスしても良い（たとえば、（これに限定されないが）サービス融合ファブリックの外部のドメイン要素。これには、別の異なるサービス融合ファブリックの一部を含むドメイン要素が含まれる）。
【００３８】
このサービス要求応答には、たとえば処理されたサービス要求、サービス要求に対する融合された応答、または他の応答（その動作状況ならば関連性があり得るもの）が含まれる。多くの場合、提供されたサービス要求応答には、サービス要求を処理する複数の潜在的な方法の中から選択されたサービス要求を処理する特定の方法が含まれている。
【００３９】
１つのアプローチによれば、サービス管理ネットワーク要素は、この選択処理の通知を、資源、ユーザ・セッション状態、および関連性のあるユーザ選択についての前記の情報を用いて行なう。しかし他の基準を用いても良い。たとえば、必要に応じて、サービス要求を処理する特定の方法を選択することは、部分的に、特定のレベルの実施を複数のドメインに渡って行なう取り組みに基づく（たとえば、実施条件を、複数の利用可能な候補ネットワークまたはデバイスに渡って最適化することを試みることによって）。実施条件には以下のような因子を含んでいても良い。すなわち、接続ビット・レート、待ち時間、ジッター、ユーザまたはサービス・プロバイダに対するコスト、ネットワーク・ローディング、パワー／バッテリ寿命、ユーザ選択、デバイス入力／出力特性、または他の条件（所与のアプリケーション設定において関連性のあり得るもの）である。
【００４０】
またこのプロセス２００は、選択された応答を公表することによって、サービス要求を容易にする。公表は通常、少なくとも部分的には望ましい。なぜならば、サービス管理ネットワーク要素自体には、サービス要求に対して選択された応答の詳細を実現する不可欠な必要な手段および／または権限が無いからである。このような公表を、たとえば、サービス融合ファブリックにおけるサービス要求の要求者、１つまたは複数の資源所有者、および／または別のサービス管理ネットワーク要素のうちの１つまたは複数宛に送って、ほんの少しの潜在的に関連性のある公表対象を示しても良い。
【００４１】
このように構成されていれば、サービス融合ファブリックは、複数のネットワークに渡るサービス要求に適応される。より詳細には、所与のサービス要求に対するサポートをサポートすること（または最適化さえすること）が、複数の管理ドメイン（たとえば、アクセス・ネットワーク、サービス・ネットワーク、エンド・ユーザ・プラットフォームなどに対応する）に及ぶ条件の組を用いて可能である。例示を目的として、サービス要求を、呼び出しに対応する第１のドメインを介して提出して、特定のエンド・ユーザへ配信することができる。このような教示に従えば、サービス融合ファブリックは、このエンド・ユーザが第２のドメインにおいてビジーであることを知ることができ、またその知見を、サービス要求を処理して適切なサービス要求応答を定式化するときに取り込むことができる。
【００４２】
当業者であれば理解するように、前記プロセスは、多種多様の利用可能でおよび／または容易に構成されたプラットフォームのいずれかを用いて容易に可能になる。このようなプラットフォームには、当該技術分野で知られている部分的にもしくは全体としてプログラマブルなプラットフォーム、またはいくつかのアプリケーションに対して望ましくあり得る専用のプラットフォームが含まれる。次に図３を参照して、このようなネットワーク要素に対する例示的なアプローチを示す。
【００４３】
すでに暗に記載したように、このネットワーク要素３００は、複数の独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークと、融合されたアプリケーション層との間に配置されるサービス融合ファブリックにおいて用いることが意図されている。この例示的な実施形態では、ネットワーク要素３００は、サービス要求受信部３０１を備えている。サービス要求受信部３０１は、以下のうちのいずれかからサービス要求を受け取るように構成および配置されている。すなわち、サービス・エンド・ユーザ、アプリケーション、およびサービス融合ファブリックの一部を含むサービス管理ネットワーク・エンティティである（これについてはすでに一般的に述べた）。
【００４４】
サービス要求受信部３０１は、サービス要求ルータ３０２に動作可能に結合している。後者は、サービス要求受信部３０１からサービス要求を受け取り、サービス要求（またはその関連性のある部分）を処理／フィルタリング用に送ることは前述した通りである（ここでは、資源評価部３０３、ユーザ・セッション状態評価部３０４、およびユーザ選択評価部３０５によって例示する）。資源評価部３０３は、サービス要求のサポートに対応する資源利用可能性を評価する働きをする。ユーザ・セッション状態評価部３０４は、サービス要求のサポートに対応するユーザ・セッション状態を評価する働きをする。ユーザ選択評価部３０５は、サービス要求のサポートに対応するユーザ選択を評価する働きをする。
【００４５】
１つの選択可能アプローチによれば、これらの評価部の出力は次に、サービス管理ネットワーク要素３０６に結合される。サービス管理ネットワーク要素３０６は、結果としての情報を用いてサービス要求を処理することによって、公表可能な処理されたサービス要求応答を提供するように構成および配置されている。別の選択可能なアプローチによれば、サービス管理ネットワーク要素３０６は、評価部のうちの１つまたは複数を自分自身に組み込んでいる。
【００４６】
この例示的な実施形態では、サービス要求公表部３０７が、公表可能なサービス要求応答を受け取って、その応答を公表する働きをすることによって、サービス要求受信部３０１が当初に受け取った対応するサービス要求をサポートすることが容易になっている。
【００４７】
当業者であれば認めて理解するように、このようなネットワーク要素３００は、図３に示す説明図によって提案される複数の物理的に別個の要素から構成されていても良い。しかしこの説明図を、論理ビューを含むものとして見ることもできる。この場合、これらの要素のうちの１つまたは複数を、共有プラットフォームを介して可能にするとともに実現することができる。また次のことも理解される。すなわち、このような共有プラットフォームには、当該技術分野で知られている全体的にまたは少なくとも部分的にプログラマブルなプラットフォームが含まれていても良い。
【００４８】
これらの教示によって、多くの明確な優位性が実現されている。たとえば、これらの教示によって、管理ドメイン間調整が、異なる独立した管理ドメイン間で密な結合を同時に起こすことを必要とせずに、実現される。またこれらの教示は、非常に拡張可能であるとともに、１つのネットワークまたはアプリケーションのアップグレードおよび更新には適応するが、他のものに対してはそうではない。一般的に、これらの教示によって、過度の先行投資およびインフラストラクチャを必要とすることなく、統合サービスに向けての比較的優美な移動経路が容易に実現される。
【００４９】
当業者であれば認めるように、幅広い変更、修正、および組み合わせを前述の実施形態に対して施すことが、本発明の趣旨および範囲から逸脱することなく可能であり、またこのような変更、修正、および組み合わせは本発明の考え方の範囲内であると考えるべきである。たとえば必要に応じて、前述のユーザ選択には、少なくとも部分的に動的な構成を含むことができる。１つのアプローチによれば、ユーザ・インターフェースによって、所与のユーザが、サービス要求を提出するときにある選択を表現できるようにすることができる。たとえば、許容し得る候補選択オプションのリストをユーザに示すことを、サービス要求をしたときに行なって、ユーザが自分の意図および希望により特定のオプションを選択できるようにすることができる。
【図面の簡単な説明】
【００５０】
【図１】本発明の種々の実施形態に基づいて構成された概略図を含む図である。
【図２】本発明の種々の実施形態に基づいて構成されたフロー図を含む図である。
【図３】本発明の種々の実施形態に基づいて構成されたブロック図を含む図である。
【図１】
2009515429.tif 000003
【図２】
2009515429.tif 000004
【図３】
2009515429.tif 000005
【手続補正書】
【提出日】平成20年5月23日(2008.5.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む複数のネットワークと、
複数サービス・エンド・ユーザと
ともに用いる方法であって、
独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む前記複数のネットワークと、融合されたアプリケーション層との間のサービス融合ファブリックを提供すること、
サービス融合ファブリックを用いて、
サービス要求を受け取ること、
前記サービス要求をサポートする資源と、
前記サービス要求に対応するユーザ・セッション状態と、
前記サービス要求に対応するユーザの選択と
に関してサービス要求を処理すること、
処理されたサービス要求とサービス要求に対する融合された応答とのうちの少なくとも１つを含む応答を提供すること、
前記応答を公表して前記サービス要求のサポートを容易にすること、
を備える方法。
【請求項２】
前記サービス要求をサポートする資源に対して前記サービス要求を処理することは、データベースにアクセスアクセスして、
前記サービス要求をサポートする少なくとも潜在的に利用可能な資源についての情報と、
前記サービス要求をサポートする少なくとも潜在的に利用可能な資源の現在の利用可能性についての情報と、
前記サービス要求のサポートに関連する少なくとも潜在的に利用可能な資源に対応する既存の許可についての情報と、
のうちの少なくとも１つについての情報を得ること、
を備える請求項１に記載の方法。
【請求項３】
前記サービス要求を、前記サービス要求に対応するユーザ・セッション状態に対して処理することは、サービス要求に関係するエンド・ユーザに対する実質的に現在のセッション状態についての情報を用いることを備える、請求項１に記載の方法。
【請求項４】
前記サービス要求に関係するエンド・ユーザに対する実質的に現在のセッション状態についての前記情報は、
特定のエンド・ユーザが現在アクティブなセッションを有しているかどうかについての情報と、
特定のエンド・ユーザの代わりに現在アクティブであるアプリケーションについての情報と
のうちの少なくとも１つが備えられる、請求項７に記載の方法。
【請求項５】
前記サービス要求に対応するユーザ選択に関する前記サービス要求を処理することは、
所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての予め設定されたルールと、
所与のサービス受益者の代わりにサービスをどのように容易にすべきかについての動的に設定されたルールと、
のうちの少なくとも１つについての情報を用いることを備える、請求項１に記載の方法。
【請求項６】
前記ユーザ選択は、少なくとも部分的には、
前記サービス要求を開始したエンティティと、
前記サービス要求を容易にするために使用される資源と、
前記サービス要求に関与するエンティティと、
前記サービス要求の受益者と、
前記サービス要求を容易にするために用いられるアプリケーションと、
のうちの少なくとも１つによって行なわれる、請求項９に記載の方法。
【請求項７】
前記サービス要求を処理することは、前記サービス要求の少なくとも一部を、資源プロセッサ、セッション状態プロセッサ、および選択プロセッサのそれぞれにルーティングすることを含む、請求項１に記載の方法。
【請求項８】
前記サービス融合ファブリックを用いて応答を提供することは、資源、ユーザ・セッション状態、およびユーザ選択についての情報をサービス管理ネットワーク要素に提供することを含む、請求項１に記載の方法。
【請求項９】
前記情報をサービス管理ネットワーク要素に提供することはさらに、情報を処理して、前記サービス要求を処理する複数の潜在的な方法の中からサービス要求を処理する特定の方法を選択することを備える、請求項１２に記載の方法。
【請求項１０】
前記処理されたサービス要求を公表してサービス要求のサポートを容易にすることには、
前記処理されたサービス要求についてのイネーブリング情報を、
サービス要求の要求者と、
少なくとも１つの資源所有者と、
サービス融合ファブリック内の別のサービス管理ネットワーク要素と、
のうちの少なくとも１つに提供することを備える、請求項１に記載の方法。
【請求項１１】
サービス融合ファブリックにおいて用いられる装置であって、サービス融合ファブリックは、独立したアクセス・ネットワーク、制御ネットワーク、およびサービス・ネットワークのうちのいずれかを含む複数のネットワークと、融合されたアプリケーション層との間に配置され、前記装置は、
サービス要求受信部と、
前記サービス要求受信部に動作可能な状態で結合されるサービス要求ルータと、
前記サービス要求ルータに動作可能な状態で結合され、前記サービス要求のサポートに対応する資源利用可能性を評価するように構成および配置される、資源評価部と、
サービス要求ルータに動作可能な状態で結合され、サービス要求のサポートに対応するユーザ・セッション状態を評価するように構成および配置されるユーザ・セッション状態評価部と、
サービス要求ルータに動作可能な状態で結合され、サービス要求のサポートに対応するユーザ選択を評価するように構成および配置されるユーザ選択評価部と、
資源評価部、ユーザ・セッション状態評価部、およびユーザ選択評価部に動作可能な状態で結合され、処理されたサービス要求応答を公表してサービス要求受信部が受け取るサービス要求のサポートを容易にするように構成および配置されるサービス要求公表部と、を備える装置。
【請求項１２】
前記サービス要求受信部は、サービス・エンド・ユーザと、アプリケーションと、サービス融合ファブリックの一部を含むサービス管理ネットワーク・エンティティとのいずれかからサービス要求を受け取るように構成および配置される、請求項１５に記載の装置。
【請求項１３】
資源利用可能性についての情報を資源評価部から受け取り、ユーザ・セッション状態についての情報をユーザ・セッション状態評価部から受け取り、およびユーザ選択についての情報をユーザ選択評価部から受け取るとともに、情報を用いてサービス要求を処理することによって、公表可能な処理されたサービス要求応答をサービス要求公表部に提供するサービス管理ネットワーク要素をさらに備える、請求項１５に記載の装置。
【国際調査報告】
2009515429.tif 000006