特表 2016-512934 ネットワークにおけるネットワーク・ノード機能の位置確認および配置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2016-512934(P2016-512934A)

(43)【公表日】2016年5月9日

(54)【発明の名称】ネットワークにおけるネットワーク・ノード機能の位置確認および配置

(51)【国際特許分類】

   H04W 92/00 20090101AFI20160404BHJP

【ＦＩ】

   H04W92/00

【審査請求】有

【予備審査請求】未請求

【全頁数】28

(21)【出願番号】特願2016-503622(P2016-503622)

(86)(22)【出願日】2014年3月17日

(85)【翻訳文提出日】2015年11月10日

(86)【国際出願番号】EP2014055234

(87)【国際公開番号】WO2014146996

(87)【国際公開日】20140925

(31)【優先権主張番号】13159723.9

(32)【優先日】2013年3月18日

(33)【優先権主張国】EP

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US

(71)【出願人】

【識別番号】504292093

【氏名又は名称】コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ

(71)【出願人】

【識別番号】508351406

【氏名又は名称】ネダーランゼ・オルガニサティ・フォーア・トゥーゲパスト−ナトゥールヴェテンシャッペリーク・オンデルゾエク・ティーエヌオー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】ストリジカーズ，ルドルフ

(72)【発明者】

【氏名】ミューレンホフ，ピーテル・ヤン

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA21

5K067DD17

5K067DD24

5K067EE02

5K067EE10

5K067EE16

(57)【要約】

本発明は、第１ネットワーク・ノードにおいてネットワーク・ノード機能を使用する代わりに、第２ネットワーク・ノードにおいてこのネットワーク・ノード機能の配置および使用を可能にする。ネットワーク・ノード機能は、例えば、サーバ機能またはルータ機能である。第２ネットワーク・ノードは、通例、クライアント・デバイスまたは運営会社の内部あるいはその近くに配置される。運営会社は、クライアント−サーバ通信の最適化、およびネットワークにおけるクライアント−サーバ通信上の負荷の最適化を可能にするために、クライアント・デバイスにサービスする。第１ネットワーク・ノードに送信されたクライアント要求は、第２ネットワーク・ノードにリダイレクトすることができる。
【選択図】図１

【特許請求の範囲】

【請求項1】

第１ネットワーク・ノード（１）に通信可能に接続されたクライアント・デバイス（３）に提供されるネットワーク・ノード機能を第２ネットワーク・ノード（２）上で有効にする方法であって、
前記ネットワーク・ノード機能を要求するために、要求データ（１０１）を前記第１ネットワーク・ノード（１）における前記クライアント・デバイス（３）から受信するステップ（１１）であって、前記要求データ（１０１）が、クライアント識別データと前記第１ネットワーク・ノード（１）における前記ネットワーク・ノード機能の指示とを含む、ステップと、
前記第１ネットワーク・ノード（１）において、前記クライアント識別データに基づいてリソース・プロバイダ・エンティティ（４）を決定するステップ（１２）と、
前記第１ネットワーク・ノード（１）から前記リソース・プロバイダ・エンティティ（４）に、リソース割り当て要求（１０２）を送信するステップ（１３）であって、前記リソース割り当て要求（１０２）が、前記クライアント識別データと前記ネットワーク・ノード機能の指示とを含む、ステップと、
前記リソース割り当て要求（１０２）に基づいて、前記リソース・プロバイダ・エンティティ（４）においてクライアント・コンテキスト・データを得るステップ（１４）と、
前記クライアント・コンテキスト・データに基づいて、前記リソース・プロバイダ・エンティティ（４）において前記第２ネットワーク・ノード（２）を決定するステップ（１５）と、
前記リソース・プロバイダ・エンティティ（４）から前記第２ネットワーク・ノード（２）に機能配置要求（１０３）を送信するステップ（１６）であって、前記機能配置要求（１０３）が前記ネットワーク・ノード機能の指示を含む、ステップと、
前記機能配置要求（１０３）に基づいて、前記第２ネットワーク・ノード（２）において前記ネットワーク・ノード機能を有効にするステップ（１７）と
を含む、方法。

【請求項2】

請求項１記載の方法であって、更に、
前記第１ネットワーク・ノード（１）の仲介によって、前記リソース・プロバイダ・エンティティ（４）から前記クライアント・デバイス（３）に応答データ（１０４）を送信するステップ（１８）と、
前記応答データ（１０４）に基づいて、前記クライアント・デバイス（３）から前記第２ネットワーク・ノード（２）に、前記ネットワーク・ノード機能を使用するための別の要求データ（１０５）をリダイレクトするステップ（１９）と
を含む、方法。

【請求項3】

請求項１または２記載の方法において、前記第２ネットワーク・ノード（２）において前記ネットワーク・ノード機能を有効にするステップ（１７）が、ネットワーク・ノード機能データを前記第２ネットワーク・ノード（２）にダウンロードするステップ（２０）を含み、前記ネットワーク・ノード機能データが、前記ネットワーク・ノード機能を定めるコンピュータ・プログラム・コードを含む、方法。

【請求項4】

請求項１〜３のいずれか１項記載の方法において、前記クライアント・デバイス（３）が、第１ゲートウェイ・エンティティ（５）の仲介によって、前記第１ネットワーク・ノード（１）に通信可能に接続され、前記応答データ（１０４）が、前記第２ネットワーク・ノード（２）に対する参照を含み、前記リダイレクトするステップ（１９）が、前記応答データ（１０４）に基づいて、前記第１ゲートウェイ・エンティティ（５）において実行される、方法。

【請求項5】

請求項４記載の方法において、前記第１ゲートウェイ・エンティティ（５）が、前記クライアント・デバイス（３）におけるゲートウェイ・エンティティ、前記クライアント・デバイス（３）に通信可能に接続されたルータ、前記クライアント・デバイス（３）にワイヤレスに接続された移動体ネットワークにおける基地局、前記クライアント・デバイス（３）に通信可能に接続された移動体ネットワークにおけるパケット・データ・ネットワーク・ゲートウェイ、または前記クライアント・デバイス（３）に通信可能に接続された住居用ゲートウェイの内の１つである、方法。

【請求項6】

請求項１〜３のいずれか１項記載の方法において、前記クライアント・デバイス（３）が、第１ゲートウェイ・エンティティ（５）の仲介によって、前記ネットワーク・ノード（１）に通信可能に接続され、更に、
前記リソース・プロバイダ・エンティティ（４）において、前記第２ネットワーク・ノード（２）において前記ネットワーク・ノード機能にアクセスするための仲介として前記クライアント・デバイス（３）によって使用されることになる、前記第１ゲートウェイ・エンティティ（５）とは異なる第２ゲートウェイ・エンティティ（６）を決定するステップ（２１）であって、前記サービス応答データ（１０６）が、前記第２ゲートウェイ・エンティティ（６）に対する参照を含む、ステップを含み、
前記リダイレクトするステップ（１９）が、前記応答データ（１０４）に基づいて、前記第２ゲートウェイ・エンティティ（６）の仲介により、前記クライアント・デバイス（３）から前記第２ネットワーク・ノード（２）までの接続を設定するステップを含む、方法。

【請求項7】

請求項６記載の方法において、前記第２ゲートウェイ・エンティティ（６）が、前記クライアント・デバイス（３）におけるゲートウェイ・エンティティ、前記クライアント・デバイス（３）に通信可能に接続されたルータ、前記クライアント・デバイス（３）にワイヤレスに通信可能に接続された移動体ネットワークにおける基地局、前記クライアント・デバイス（３）に通信可能に接続された移動体ネットワークにおけるパケット・データ・ネットワーク・ゲートウェイ、または前記クライアント・デバイス（３）に通信可能に接続された住居用ゲートウェイの内の１つである、方法。

【請求項8】

請求項１から７のいずれか１項記載の方法において、前記リソース・プロバイダ・エンティティ（４）を前記第１ネットワーク・ノード（１）において決定するステップ（１２）が、
前記クライアント識別データの少なくとも一部を参照データベース（７）に送信し（２３）、応答において前記参照データベース（７）から前記リソース・プロバイダ・エンティティに対する前記参照を受信する（２４）ことによって、前記クライアント識別データに基づいて、前記リソース・プロバイダ・エンティティ（４）に対する参照を解明するステップ（２２）を含む、方法。

【請求項9】

請求項８記載の方法において、前記クライアント識別データの前記少なくとも一部が、前記クライアント・デバイス（３）のＩＰアドレスを含み、前記参照データベース（７）が、フーイズ・データベース、ジオＩＰデータベース、またはＩＰアドレス範囲をリソース・プロバイダ・エンティティ（４）にリンクするデータベースの内の１つである、方法。

【請求項10】

請求項１から９のいずれか１項記載の方法において、前記リソース割り当て要求（１０２）が更に、１つ以上のリソース要件を含み、前記第２ネットワーク・ノードを前記リソース・プロバイダ・エンティティにおいて決定するステップ（１５）が更に、前記１つ以上のリソース要件に基づく、方法。

【請求項11】

請求項１から１０のいずれか１項記載の方法であって、更に、
前記リソース・プロバイダ・エンティティ（４）において、第３ネットワーク・ノード（８）を、前記クライアント・コンテキスト・データ、および前記クライアント・デバイス（３）の地理的移動に基づく前記第３ネットワーク・ノード（８）における前記ネットワーク・ノード機能の将来の使用予測に基づいて、決定するステップ（２５）と、
前記リソース・プロバイダ・エンティティ（４）から前記第３ネットワーク・ノード（８）に別の機能配置要求（１０６）を送信するステップ（２６）であって、前記別の機能配置要求（１０６）が、前記ネットワーク・ノード機能の指示を含む、ステップと、
前記別の機能配置要求（１０６）に基づいて、前記第３ネットワーク・ノード（８）において前記ネットワーク・ノード機能を有効にするステップと
を含む、方法。

【請求項12】

請求項１から１１のいずれか１項記載の方法において、前記第１ネットワーク・ノード（１）から前記リソース・プロバイダ・エンティティ（４）に前記リソース割り当て要求（１０２）を送信するステップ（１３）が、前記クライアント・デバイス（３）とは異なるネットワーク・デバイス（９）によってトリガーされる、方法。

【請求項13】

請求項１から１２のいずれか１項記載の方法において、前記第２ネットワーク・ノード（２）がクラウド・サービスである、方法。

【請求項14】

請求項１から１３のいずれか１項記載の方法であって、更に、前記リソース・プロバイダ・エンティティ（４）において、前記第２ネットワーク・ノード（２）における前記ネットワーク・ノード機能の使用に課金するステップ（１０７）を含む、方法。

【請求項15】

第１ネットワーク・ノード（１）に通信可能に接続されたクライアント・デバイス（３）によってアクセス可能なネットワーク・ノード機能を第２ネットワーク・ノード（２）上で有効にするリソース・プロバイダ・エンティティ（４）であって、
前記第１ネットワーク・ノード（１）からリソース割り当て要求（１０２）を受信し、前記リソース割り当て要求（１０２）が、クライアント識別データと前記第１ネットワーク・ノード（１）における前記ネットワーク・ノード機能の指示とを含み、
前記リソース割り当て要求（１０２）に基づいて、クライアント・コンテキスト・データを得て、
前記クライアント・コンテキスト・データに基づいて前記第２ネットワーク・ノード（２）を決定し、
機能配置要求（１０３）に基づいて、前記第２ネットワーク・ノード（２）において前記ネットワーク・ノード機能を有効にするために、前記第２ネットワーク・ノード（２）に前記機能配置要求（１０３）を送信し、前記機能配置要求（１０３）が、前記ネットワーク・ノード機能の指示を含む、
ように構成される、リソース・プロバイダ・エンティティ（４）。

【請求項16】

請求項１５記載のリソース・プロバイダ・エンティティ（４）において、前記リソース割り当て要求（１０２）が更に、１つ以上のリソース要件を含み、当該リソース・プロバイダ・エンティティ（４）が更に、前記１つ以上のリソース要件に基づいて、前記第２ネットワーク・ノード（２）を決定するように構成される、リソース・プロバイダ・エンティティ（４）。

【請求項17】

請求項１５または１６記載のリソース・プロバイダ・エンティティ（４）であって、更に、
前記クライアント・コンテキスト・データと、前記クライアント・デバイス（３）の地理的移動に基づく前記第３ネットワーク・ノード（８）における前記ネットワーク・ノード機能の将来の使用予測とに基づいて、第３ネットワーク・ノード（８）を決定し、
前記第３ネットワーク・ノード（８）に別の機能配置要求（１０６）を送信して、前記別の配置要求（１０６）に基づいて前記第３サーバ（８）において前記ネットワーク・ノード機能を有効にするように構成され、前記別の機能配置要求（１０６）が、前記ネットワーク・ノード機能の指示を含む、リソース・プロバイダ・エンティティ（４）。

【請求項18】

請求項１５〜１７のいずれか１項記載のリソース・プロバイダ・エンティティ（４）であって、更に、前記第２ネットワーク・ノード（２）における前記ネットワーク・ノード機能の使用に課金するように構成される、リソース・プロバイダ・エンティティ（４）。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークにおけるネットワーク・ノード機能の位置確認(localization)および配置(placement)に関する。更に特定すれば、本発明は、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にする方法、および第２ネットワーク・ノード上においてネットワーク・ノード機能を有効にするリソース・プロバイダ・エンティティ(resource provider entity)に関する。

【従来技術】

【0002】

ネットワーク・オーバーヘッドが、クライアント−サーバ・アプリケーションの二点間性能に影響を及ぼす可能性があることは知られている。ネットワーク・オーバーヘッドの影響は、ネットワークの数、ネットワーク・エレメントの数、および／またはクライアントとサーバとの間の地理的距離が増大すると、大きくなる恐れがある。例えば、クライアントとサーバとの間の距離によって生ずるネットワーク遅延は、１つのユーザ要求が複数のコールをデータベース、アプリケーション・サーバ、および／またはクライアントに要求するとき、クライアントの体験品質を著しく低下させる可能性がある。

【0003】

クライアント−サーバ通信におけるネットワーク関連性能劣化は、明示的にネットワーク・トラフィックを管理することによって減らすことができる。これまで、ネットワーク運営会社は、例えば、経路を特定のエンド・ポイントに割り当てる（例えば、ＭＰＬＳ、ＶＰＮ、または光ファイバ回路を使用して）ことができ、またはアプリケーションにサービス品質要件を表現させる（例えば、DiffServまたはIntServを使用する）ことができ、サービス品質要件は、アプリケーション・トラフィックの優先順位を決めるために使用することができる。更に近年では、ソフトウェア定義ネットワークが、例えば、隘路を回避するためにデータ流を経路変更することによって、集中制御プレーンを使用して、データ流に対する一層粒度の細かい制御を、ネットワーク運営業者に可能にする。

【0004】

既知のネットワーク管理の解決手段は隘路を回避するまたはトラフィックに優先順位を付けることができるが、これらはエンド・ポイント、即ち、クライアントおよびサーバの位置を変更することができない。その結果、ネットワークにおける潜在的な規模決定問題(dimensioning problem)を解決することができず、ネットワーク・リソースの削減（例えば、ホップの数を最小限に抑える、ネットワーク・リソースの帯域幅または明示的制御を最適化する）を達成することができない。これの影響は、多くの要求側クライアント−サーバ・アプリケーションが、低容量のネットワーク・エレメントの使用を要求すると、サービスを拒否するまたはその速度を制限する以外に、認められたネットワークの品質を改善するためのネットワーク管理解決手段がないことである。

【0005】

クラウド・サービスの使用を可能にするネットワークの制御、運営、および維持を専門とするネットワーク・サービス・プロバイダが知られている。このようなネットワーク・サービス・プロバイダは、通例、クラウド・サービス・プロバイダに、そのクラウド・サービスにどのようにアクセスするか制御する能力を提供しない。

【0006】

更に、クラウド・サービス・プロバイダは、通例、ネットワーク・サービス・プロバイダが、ネットワーク・サービス配信を考慮に入れるクラウド・サービス配信を最適化することを許可しない。このため、ネットワーク・サービス・プロバイダおよびクラウド・サービス・プロバイダの双方が、最適なリソース使用でエンド・ユーザに最適なサービスを提供するように、ネットワークおよびその他の基本的計算リソースを構成することができないという状況に至る。

【0007】

移動体通信に対する３ＧＰＰ規格における近年の開発は、長期発展（ＬＴＥ）ネットワークおよびデバイスに関する。ＬＴＥは、４Ｇ（即ち、第４世代）移動体通信規格としても知られており、移動体電話機およびデータ端末用高速データのワイヤレス通信のための規格である。これは、ＧＳＭ（登録商標）／ＥＤＧＥ（２Ｇまたは２．５Ｇとしても知られる）およびＵＭＴＳ／ＨＳＰＡ（３Ｇとしても知られる）ネットワーク技術の後継であり、中核となるネットワーク改善と共に異なる無線インターフェースを使用して、容量を増大し速度を高める。

【0008】

最適なリソース使用で最適なサービスをエンド・ユーザに提供できないという以上で識別した問題は、ＬＴＥネットワークにも該当する可能性がある。ＬＴＥネットワークの設計は、ネットワーク・リソースと組み合わせた計算またはストレージ・リソースの管理および調整(coordination)を含まない。

【0009】

クライアント・デバイスは、通例、アクセス・ポイント・ネーム（ＡＰＮ）に接続を要求することによって、インターネット・ゲートウェイに接続し(attach)、アクセス・ポイント・ネーム（ＡＰＮ）は、アドレシングおよびインターネット・ゲートウェイ機能というような、実際のＩＰサービスを提供する公衆データ・ネットワーク（ＰＤＮ）ゲートウェイへのトンネルに繋がる。あるいは、ネットワーク・サービス・プロバイダのネットワークにおける（ホーム）ルータまたはＨ（ｅ）ノードＢ（即ち、ＬＴＥ基地局）が、インターネット・ゲートウェイとして機能することができる。ネットワーク・サービス・プロバイダのネットワークにおける位置に依存して、インターネット・ゲートウェイ上のトラフィックは、インターネットに導出される前に、バックホール（即ち、基地局または（ホーム）ルータをコア・ネットワークに接続するネットワーク）を通じてそのコア・ネットワークに導出される。

【0010】

既知の３ＧＰＰの提案では、Ｈ（ｅ）ノードＢは、ローカル・エリア・ネットワークを通じてローカル・デバイスにデータ・トラフィックをリダイレクトする、または他のインターネット・サービス・プロバイダのネットワークを通じてトラフィックをリダイレクトするように構成することができる。このような提案の一例は、"Local IP Access and Selected IP Traffic Offload (LIPA SIPTO)"（ローカルＩＰアクセスおよび選択ＩＰトラフィック・オフロード（ＬＩＰＡ ＳＩＰＴＯ）と題する３ＧＰＰ仕様 TR 23.829 Release 10において見ることができる。ＬＩＰＡ ＳＩＰＴＯの目標は、利用可能な固定ブロードバンド・ネットワークを通じてトラフィックをリダイレクトすることによってバックホールまたはコア・ネットワークにおける輻輳を回避すること、そしてホーム・プリンタまたはメディア・センタのような、ローカル・デバイスとのＩＰ通信をサポートすることである。クライアント・デバイスは、Ｈ（ｅ）ノードＢ、（ホーム）ルータ、またはＰＤＮ−ゲートウェイをインターネット・ゲートウェイとして介してアクセス・ネットワークに接続される。インターネット・ゲートウェイは、パケットのフィルタリング、およびネットワーク・アドレス変換によるトラフィックのリダイレクトをサポートする。

【0011】

クラウド・コンピューティングでは、クライアント・デバイスは、クラウド・サービス・プロバイダにおいてクラウド・サービスを使用する。クラウド・サービスとは、クラウド・コンピューティング技術を使用する任意の接続デバイスを使用して、任意のアクセス・ネットワークを通じて、任意の時点においてオンデマンドで配信および消費されるサービスである。クラウド・サービス・ユーザ（ＣＳＵ）とは、通例、クライアント・デバイスを使用して、配信されるクラウド・サービスを消費する人または組織である。ＣＳＵは、クラウド・サービス・プロバイダ（ＣＳＰ）によって提供されるクラウド・サービスを、このクラウド・サービスの実際のユーザ、即ち、エンド・ユーザに配信する中間ユーザを含むことができる。エンド・ユーザは、人、機械、またはアプリケーションとすることができる。クラウド・コンピューティングとは、サービス・ユーザが、構成可能な計算リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、およびサービス）の共有プールに対するオンデマンド・ネットワーク・アクセスを有することを可能にするモデルであり、通例、最小限の管理の手間またはサービス・プロバイダの仲介で、プロビジョニングおよび放出することができる。クラウド・コンピューティングは、クラウド・サービスを可能にする。電気通信の観点から、ユーザは物理的なリソースを購入しているのではなく、クラウド・コンピューティング環境によって有効にされるクラウド・サービスを購入していると考えられる。サービスとしてのクラウド・インフラストラクチャ（ＩａａＳ）は、クラウド・サービスの一カテゴリであり、クラウド・サービス・プロバイダによってクラウド・サービス・ユーザに提供される能力は、仮想処理、ストレージ、クラウド内ネットワーク接続サービス（例えば、ＶＬＡＮ、ファイアウォール、負荷バランサ、およびアプリケーション加速）、およびクラウド・サービス・ユーザが任意のアプリケーションを展開し実行することができるクラウド・インフラストラクチャのその他の基礎的コンピューティング・リソースを提供することである。クラウド間コンピューティングは、クラウド・リソースのオンデマンドによる割り当てを可能とし、クラウド・リソースには、コンピューティング、ストレージ、およびネットワーク、ならびにクラウド・システムの相互作用による作業負荷の移転を含む。ＣＳＰの観点からは、クラウド間コンピューティングは、クラウド間ピア形成(inter-cloud peering)、クラウド間サービス・ブローカ、およびクラウド間連合を含む、異なる様態で実現することができる。これらの様態は、ＣＳＰが他のＣＳＰと相互作用するときに果たすことができる、別個の可能な役割に対応する。クラウド間ピア形成は、２つのＣＳＰ間における直接相互接続を提供する。クラウド間サービス・ブローカ（ＩＳＢ）は、ＣＳＰを相互接続することによって達成される、２つ（以上）のＣＳＰ間における間接的相互接続を提供し、相互接続されたＣＳＰ間における相互作用サービス機能を提供することに加えて、相互接続されたＣＳＰの内１つ（以上）のために、仲介サービス機能(brokering service function)も提供する。また、ＩＳＢは、仲介サービスを受ける相互接続されたエンティティの内１つ（以上）がクラウド・サービス・ユーザ（ＣＳＵ）である場合にも該当する(cover)。仲介サービス機能は、一般に、以下の３つのカテゴリ、即ち、サービス仲介、サービス集計、およびサービス裁定(arbitrage)を含むが、これらに限定されるのではない。クラウド間連合とは、相互に信頼されたクラウドが、そのリソースを統合することによって、論理的に一緒に集まる、クラウド間コンピューティングを実現する１つの様態である。クラウド間連合は、ＣＳＰが需要の変動に応答して、リソースを他のＣＳＰに動的に外部委託することを可能にする。

【0012】

移動体クラウドとは、移動体アプリケーション（即ち、移動体デバイス用アプリケーション）が構築されるモデルであり、クラウド・コンピューティング技術を使用して、強化されホストされる。クライアント・デバイスは、デバイス上のゲートウェイとして機能することができ、クラウド内において格納および処理された情報に、ユーザがアクセスすることを可能にする。移動体クラウド・アプリケーションは、処理または格納タスクを、クラウド内に位置するサーバに送り、結果を受信および表示し、クラウド・リソースを使用して、データを格納し、通常ではクライアント・デバイスによって実行される機能を実行することができる（例えば、移動体デバイス上における最適な表示のためにウェブ・ページを前処理する、トランスコーディング、アプリケーション・データを格納する）。移動体クラウド・アプリケーションは、クライアント・デバイス上でダウンロードすることができ、またはウェブ・ブラウザによって直接アクセスし（例えば、ＨＴＭＬ５およびJava（登録商標）scriptを使用して）、クライアント・デバイスの機能、およびカメラ、ＧＰＳ、またはマイクロフォンのようなセンサを利用してサービスを配信することができる。

【0013】

移動体クラウド・アプリケーション・プロバイダは、通例、クラウド・サーバとクライアント・デバイスとの間においてネットワークを制御することはできないが、クライアント・デバイスとクラウド・サーバとの間の通信は、ブロードバンド接続を必要とする。更に、ストリーミング・メディアまたはゲーミング・アプリケーションが、ある一定のレイテンシおよびジッタ制限以内のネットワーク接続を要求する場合がある。新たなそして一層過酷なアプリケーションをサポートするためのネットワーク高速化の要望が増えつつあるため、ネットワーク・サービス・プロバイダは、通例、この需要に応えるためにネットワーク容量を増大させる。トラフィックの優先順位というような他の選択肢は、高度なネットワーク管理を必要とし、ネットワーク・サービス・プロバイダの境界内でサービス品質を向上させるに過ぎない。しかし、ネットワーク・サービス・プロバイダの境界外部における輻輳、遅延、エラー、および障害は、相変わらずアプリケーション性能に悪影響を及ぼすおそれがある。

【0014】

クラウド間コンピューティングは、エンド・ユーザがサービスを作成し、多数のクラウド・サービス・プロバイダ（ＣＳＰ）を通じてサービスを移転することを可能にする。 この能力は、エンド・ユーザが３つの機能、即ち、負荷均衡化、クラウド・バースティング(cloud bursting)、およびフェールオーバーを実現することを可能にする。負荷均衡化の設定では、多数のクラウド・サーバ・プロバイダを通じてサーバがコピーされる。プロキシ・サーバは、クライアント要求をこれらのサーバに分散する。クラウド・バースティングは、ローカル・リソースがワークフローを処理するには不十分であるとき、サーバがその作業負荷を多数のクラウド・サービス・プロバイダにわたって分散することを可能にする。負荷均衡化は、クライアント要求を分散するために使用することができるが、サーバが、クライアント要求を処理するために、この作業負荷の一部を処理してもよい。また、エンド・ユーザは、サーバを多数のリソース・プロバイダにわたって分散することができるとき、フェールオーバー・メカニズムを実現することもできる。

【0015】

クラウド間サービス・ブローカは、クラウド・サービス・プロバイダ間において仲介、集計、および裁定する能力を追加する。アプリケーション要件（例えば、位置、価格設定、リソース）に依存して、クラウド間サービス・ブローカは、クラウド・リソース購入者（例えば、エンド・ユーザ、クラウド・サービス・プロバイダ、または再販業者）をクラウド・リソース販売業者（例えば、クラウド・サービス・プロバイダまたは再販業者）に照会する機能を提供する。その目標は、サーバを実行するため、そして個々のクラウド・サービス・プロバイダをクラウド・サービスのための１つのエントリ・ポイントに抽象化するために、提供されるリソースと要求されるリソースとの間で可能な限り最良の一致を得ることである。クラウド間サービス・ブローカは、エンド・ユーザに、クラウド間における負荷均衡化、クラウド・バースティング、およびフェールオーバーを実現する能力を提供することを要求される。

【0016】

クラウド・サービス・ブローカは、サーバ要件（例えば、価格、ＣＰＵ、メモリ、位置）をクラウド位置に照会するために使用することができる。クラウド・サービス・ブローカは、クライアントとサーバとの間におけるネットワークの観念(notion)を有さず、クライアント・デバイスのネットワーク・コンテキスト特定の詳細をモデル化することもない。したがって、クラウド・サービス・ブローカは、ネットワーク・サービス・プロバイダのネットワーク（１つまたは複数）を横断することによって誘発されるオーバーヘッドを著しく低減することはなく、クライアント−サーバ通信に悪影響を及ぼす（例えば、ネットワーク・レイテンシ、伝搬遅延、ネットワーク・デバイスにおけるバッファリング／キューイング、エラー、障害）。

【0017】

ＬＩＰＡ ＳＩＰＴＯに対する現在の３ＧＰＰ提案は、クライアント−サーバ通信を最適化するための解決手段を全く提供しない。何故なら、ネットワークのオーバーヘッドを最小限に抑えるまたは回避するメカニズムを提供しないからである。その結果、例えば、クラウド間サービス・ブローカを使用してインターネットにおけるクラウド位置にサーバを割り当てても、クライアントに大きな恩恵をもたらすことにはならず、ネットワーク・サービス・プロバイダにおけるトラフィックの低減にも繋がらない。

【発明の概要】

【発明が解決しようとする課題】

【0018】

クライアント・デバイスに関係付けて、ネットワークの望ましい動作パラメータを達成できるように、サーバ機能を配置することができる解決手段が求められている。

【課題を解決するための手段】

【0019】

本発明の目的は、クライアント・デバイスに関係付けて、ネットワークの望ましい動作パラメータを達成できるように、サーバ機能を配置することができる解決手段を提供することである。

【0020】

本発明の一態様によれば、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にする方法が提案される。ネットワーク・ノード機能は、第１ネットワーク・ノードに通信可能に接続されたクライアント・デバイスに提供することができる。この方法は、ネットワーク・ノード機能を要求するために、要求データを第１ネットワーク・ノードにおけるクライアント・デバイスから受信するステップを含むことができる。要求データは、クライアント識別データと、第１ネットワーク・ノードにおけるネットワーク・ノード機能の指示とを含むことができる。この方法は、更に、第１ネットワーク・ノードにおいて、クライアント識別データに基づいて、リソース・プロバイダ・エンティティを決定するステップも含むことができる。この方法は、更に、第１ネットワーク・ノードからリソース・プロバイダ・エンティティに、リソース割り当て要求を送信するステップも含むことができる。リソース割り当て要求は、クライアント識別データと、ネットワーク・ノード機能の指示とを含むことができる。この方法は、更に、リソース割り当て要求に基づいて、リソース・プロバイダ・エンティティにおいてクライアント・コンテキスト・データを得るステップを含むことができる。この方法は、更に、クライアント・コンテキスト・データに基づいて、リソース・プロバイダ・エンティティにおいて第２ネットワーク・ノードを決定するステップを含むことができる。この方法は、更に、リソース・プロバイダ・エンティティから第２ネットワーク・ノードに機能配置要求を送信するステップを含むことができる。この機能配置要求は、ネットワーク・ノード機能の指示を含むことができる。この方法は、更に、機能配置要求に基づいて、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にするステップを含むことができる。

【0021】

本発明の態様によれば、第２ネットワーク・ノード上においてネットワーク・ノード機能を有効にするリソース・プロバイダ・エンティティが提案される。ネットワーク・ノード機能は、第１ネットワーク・ノードに通信可能に接続されたクライアント・デバイスによってアクセス可能であることができる。このリソース・プロバイダ・エンティティは、第１ネットワーク・ノードからリソース割り当て要求を受信するように構成することができる。リソース割り当て要求は、クライアント識別データと、第１ネットワーク・ノードにおけるネットワーク・ノード機能の指示とを含むことができる。リソース・プロバイダ・エンティティは、リソース割り当て要求に基づいて、クライアント・コンテキスト・データを得るように構成することができる。リソース・プロバイダ・エンティティは、クライアント・コンテキスト・データに基づいて第２ネットワーク・ノードを決定するように構成することができる。リソース・プロバイダ・エンティティは、機能配置要求に基づいて、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にするために、第２ネットワーク・ノードに機能配置要求を送信するように構成することができる。機能配置要求は、ネットワーク・ノード機能の指示を含むことができる。

【0022】

このように、本発明は、ネットワーク・ノード機能を第１ネットワーク・ノードにおいて使用する代わりに、第２ネットワーク・ノードにおけるネットワーク・ノード機能の配置および使用を可能にする。第２ネットワーク・ノードの配置は、クライアント・デバイスまたはこのクライアント・デバイスにサービスする運営会社のネットワークと第２ネットワーク・ノードとの間における通信が、クライアント・デバイスによって要求されるサービスの体験品質、および恐らくは、クライアント−サーバ通信に関係するネットワーク負荷に関して、第１ネットワーク・ノードよりも最適になるように行われる。第１ネットワーク・ノードに送信されるクライアント要求は、第２ネットワーク・ノードにリダイレクトされてもよい。

【0023】

クライアント・デバイスは、任意のエンド・ユーザ・デバイス、または第１ネットワーク・ノードおよび第２ネットワーク・ノード以外のネットワーク・ノードであってもよい。

【0024】

ネットワーク・ノードの例には、サーバ、ルータ、およびスイッチがある。ネットワーク・ノード機能の例には、アプリケーションまたはネットワーク・サービス（の一部）がある。アプリケーション・サービスは、例えば、ウェブ・サーバ、ＨＴＴＰプロキシ、データベース、ウェブ・サービス（例えば、ＲＥＳＴ、ＳＯＡＰ）、データ・ストア、またはコンテンツ・キャッシュ（例えば、ＣＤＮサービス）である。ネットワーク・サービスの例には、インターネット・ゲートウェイ、ＤＨＣＰサーバ、ファイアウォール、ネットワーク・エレメント機能（例えば、ＨＳＳ、ＭＭＥ、ＰＤＮ−ＧＷ）、ネットワーク制御／シグナリング機能（例えば、ＩＭＳ制御機能、パケット転送、経路計算）、およびプロトコル実施（ＯＳＰＦ、ＢＧＰ、ＩＰｖ４、ＩＰｖ６）がある。

【0025】

クライアント・コンテキスト・データは、例えば、リソース割り当て要求からクライアント識別データを得ることによって、リソース割り当て要求から直接得られればよい。クライアント・コンテキスト・データは、クライアント・コンテキスト・データにおける情報の派生物であってもよい。リソース割り当て要求からの情報は、他のデータによって充実させてもよく、この充実させたデータが、得られるコンテキスト・データとなる。リソース割り当て要求からの情報が、その情報に関係するデータを発見するために使用されてもよく、次いで、関係するデータが、得られるコンテキスト・データとなる。

【0026】

ネットワーク・ノードにおけるネットワーク・ノード機能の配置は、通例、ネットワーク・ノードにおけるハードウェア・リソースの割り当て、および割り当てられたハードウェア・リソース上におけるネットワーク・ノード機能の読み込みを含み、これによって、ネットワーク・ノード機能を実行し使用することを可能にする。ネットワーク・ノード機能が既に第２ネットワーク・ノード上にあることが可能であり、この場合、このネットワーク・ノード機能をアクティブにすることによって、ネットワーク・ノード機能が有効にされてもよい。

【0027】

ネットワーク・ノードが、リソースを仮想化する設備、例えば、ハイパーバイザを提供してもよい。リソースのプールにアクセスを与えるクラウド・ネットワークまたはクラウド・サービス・プロバイダにおいて、多数のネットワーク・ノードが編成されてもよい。次いで、ネットワーク・ノード機能は、仮想機械の一部として実現されてもよく（または、仮想化リソース、例えば、仮想化スイッチ、ルータにアクセスするために提供される他の抽象化）、または多数のネットワーク・ノード機能が１つの仮想機械に組み合わせられてもよい。

【0028】

インターネット・ゲートウェイは、例えば、（ホーム）ルータ、ＰＤＮ−ＧＷ、またはＨ（ｅ）ノードＢである。

【0029】

クラウド・サービス・プロバイダは、例えば、クライアント、サーバ、および／またはネットワーク要件（例えば、クライアント・デバイスの地理的位置、クラウド・プロバイダの位置に対するネットワーク・コストおよび性能、および／または方針）に基づいて選択されてもよい。

【0030】

エンティティとは、ネットワーク・ノード、または通信プロトコルを使用して他のエンティティとの通信が可能なネットワーク・ノード上で実行するソフトウェア・モジュールである。リソース・プロバイダ・エンティティとは、リソース割り当て要求を処理し、クライアント・コンテキスト・データを得るために、クライアント識別データのような、リソース割り当て要求と共に提供されるクライアント・デバイスについての情報を使用するように構成されたエンティティである。次いで、クライアント・コンテキスト・データは、ネットワーク・ノード機能をクライアント・デバイスに提供するためにどのネットワーク・ノードを使用するとよいか決定するために、リソース・プロバイダ・エンティティによって使用される。このように選択されたネットワーク・ノードが、第２ネットワーク・ノードになる。リソース・プロバイダ・エンティティは、ハードウェア・リソースを第２ネットワーク・ノードに割り当てさせ、ネットワーク・ノード機能を読み込むために、第２ネットワーク・ノードに機能配置要求を送信し、その後、ネットワーク・ノード機能が有効にされ、使用の準備ができる。ネットワーク・ノード機能が既に第２ネットワーク・ノードに読み込まれていることも可能であり、この場合、リソースの割り当て、およびネットワーク・ノード機能の読み込みを飛ばすことができ、代わりに、ネットワーク・ノード機能をアクティブにすればよい。

【0031】

実施形態では、この方法は、更に、第１ネットワーク・ノードの仲介によって、リソース・プロバイダ・エンティティからクライアント・デバイスに応答データを送信するステップも含むことができる。更に、この方法は、応答データに基づいて、クライアント・デバイスから第２ネットワーク・ノードに、ネットワーク・ノード機能を使用するために別の要求データをリディレクトするステップも含むことができる。

【0032】

ネットワーク・ノード機能を使用するためのクライアント・デバイスからの要求データを、第２ネットワーク・ノードにリダイレクトすることを可能にするために、リソース・プロバイダ・エンティティは、応答データをクライアント・デバイスに、第１ネットワーク・ノードの仲介によって送信すればよい。応答データは、例えば、第２ネットワーク・ノードに対する参照を含む。応答データは、要求データを第２ネットワーク・ノードにリダイレクトするために、クライアント・デバイスによって、または例えば、クライアント・デバイスと第１ネットワーク・ノードとの間にあるゲートウェイによって使用されてもよい。その結果、ネットワーク・ノード機能は、これより、第１ネットワーク・ノードの代わりに、第２ネットワーク／ノードにおいて使用することができる。

【0033】

実施形態では、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にするステップは、ネットワーク・ノード機能データを第２ネットワーク・ノードにダウンロードするステップを含み、ネットワーク・ノード機能データは、ネットワーク・ノード機能を定めるコンピュータ・プログラム・コードを含む。

【0034】

これによって、第２ネットワーク・ノードがネットワーク・ノード機能データを、例えば、ネットワーク・ノード機能のデータ・イメージの形態でダウンロードすることが可能となり、この場合、ネットワーク・ノード機能は、例えば、第２ネットワーク・ノードにおいて利用可能でない。ネットワーク・ノード機能データは、任意のデータ・ソースからダウンロードされてもよい。

【0035】

実施形態では、 クライアント・デバイスは、第１ゲートウェイ・エンティティの仲介によって、第１ネットワーク・ノードに通信可能に接続することができ、応答データは、第２ネットワーク・ノードに対する参照を含み、リダイレクトするステップは、応答データに基づいて、第１ゲートウェイ・エンティティにおいて実行される。

【0036】

これによって、クライアント・デバイスを再構成する必要なく、別の要求データのリダイレクトを第１ゲートウェイ・エンティティによって扱うことが可能になる。ここで、リダイレクトはクライアント・デバイスに対して透過的である。

【0037】

実施形態では、 第１ゲートウェイ・エンティティは、クライアント・デバイスにおけるゲートウェイ・エンティティ、クライアント・デバイスに通信可能に接続されたルータ、クライアント・デバイスにワイヤレスに接続された移動体ネットワークにおける基地局、クライアント・デバイスに通信可能に接続された移動体ネットワークにおけるパケット・データ・ネットワーク・ゲートウェイ、またはクライアント・デバイスに通信可能に接続された住居用ゲートウェイの内の１つであることが可能である。

【0038】

これによって、第１ゲートウェイ機能を、ネットワークにおける異なるエンティティにおいて実装することが可能になる。ゲートウェイ・エンティティは、ソフトウェアで、例えば、クライアント・デバイスにおける通信モジュールとして実装されてもよい。

【0039】

実施形態では、 クライアント・デバイスは、第１ゲートウェイ・エンティティの仲介によって、第１ネットワーク・ノードに通信可能に接続される。この方法は、更に、リソース・プロバイダ・エンティティにおいて、第２ネットワーク・ノードにおいてネットワーク・ノード機能にアクセスするための仲介としてクライアント・デバイスによって使用される、第１ゲートウェイ・エンティティとは異なる第２ゲートウェイ・エンティティを決定するステップを含むことができる。サービス応答データは、第２ゲートウェイ・エンティティに対する参照を含むことができる。リディレクトするステップは、応答データに基づいて、第２ゲートウェイ・エンティティの仲介により、クライアント・デバイスから第２ネットワーク・ノードまでの接続を設定するステップを含むことができる。

【0040】

このように、第２ゲートウェイ・エンティティに接続するように、クライアント・デバイスに命令することができる。これによって、別の要求データのリダイレクトを、第２ゲートウェイ・エンティティによって処理することが可能になる。

【0041】

一実施形態では、 第２ゲートウェイ・エンティティは、クライアント・デバイスにおけるゲートウェイ・エンティティ、クライアント・デバイスに通信可能に接続されたルータ、クライアント・デバイスにワイヤレスに接続された移動体ネットワークにおける基地局、クライアント・デバイスに通信可能に接続された移動体ネットワークにおけるパケット・データ・ネットワーク・ゲートウェイ、またはクライアント・デバイスに通信可能に接続された住居用ゲートウェイの内の１つである。

【0042】

これによって、第２ゲートウェイ機能を、ネットワークにおける異なるエンティティにおいて実装することが可能になる。ゲートウェイ・エンティティは、ソフトウェアで、例えば、クライアント・デバイスにおける通信モジュールとして実装されてもよい。

【0043】

実施形態では、リソース・プロバイダ・エンティティを第１ネットワーク・ノードにおいて決定するステップは、クライアント識別データの少なくとも一部を参照データベースに送信し、応答において参照データベースからリソース・プロバイダ・エンティティに対する参照を受信することによって、クライアント識別データに基づいて、リソース・プロバイダ・エンティティに対する参照を解明するステップを含むことができる。

【0044】

これによって、多数のリソース・プロバイダ・エンティティがある場合に、該当するリソース・プロバイダ・エンティティを発見することが可能になる。

【0045】

実施形態では、クライアント識別データの少なくとも一部は、クライアント・デバイスのＩＰアドレスを含み、参照データベースが、フーイズ・データベース、ジオＩＰデータベース、またはＩＰアドレス範囲をリソース・プロバイダ・エンティティにリンクするデータベースの内１つである。

【0046】

これによって、種々の参照データベースを使用して、リソース・プロバイダ・エンティティを解明することが可能になる。

【0047】

一実施形態では、リソース割り当て要求は、更に、１つ以上のリソース要件を含むことができる。第２ネットワーク・ノードをリソース・プロバイダ・エンティティにおいて決定するステップは、更に、１つ以上のリソース要件に基づくことができる。

【0048】

実施形態では、リソース割り当て要求は、更に、１つ以上のリソース要件を含むことができる。リソース・プロバイダ・エンティティは、更に、１つ以上のリソース要件に基づいて、第２ネットワーク・ノードを決定するように構成することができる。

【0049】

これによって、リソース・プロバイダ・エンティティを選択するときに、最大価格、最小帯域幅、最大レイテンシ、または最大ジッタというような、種々のリソース要件を考慮に入れることが可能になる。

【0050】

実施形態において、この方法は、更に、リソース・プロバイダ・エンティティにおいて第３ネットワーク・ノードを、クライアント・コンテキスト・データ、およびクライアント・デバイスの地理的移動に基づく第３ネットワーク・ノードにおけるネットワーク・ノード機能の将来の使用予測に基づいて、決定するステップを含むことができる。この方法は、更に、リソース・プロバイダ・エンティティから第３ネットワーク・ノードに別の機能配置要求を送信するステップを含むことができる。別の機能配置要求は、ネットワーク・ノード機能の指示を含むことができる。この方法は、更に、別の機能配置要求に基づいて、第３ネットワーク・ノードにおいてネットワーク・ノード機能を有効にするステップを含むことができる。

【0051】

実施形態では、第３ネットワーク・ノードを、クライアント・コンテキスト・データ、およびクライアント・デバイスの地理的移動に基づく第３ネットワーク・ノードにおけるネットワーク・ノード機能の将来の使用予測に基づいて、決定するように構成することができる。更に、リソース・プロバイダ・エンティティは、第３ネットワーク・ノードに別の機能配置要求を送信し、この別の機能配置要求に基づいて第３サーバにおいてネットワーク・ノード機能を有効にするように構成することができる。別の機能配置要求は、ネットワーク・ノード機能の指示を含むことができる。

【0052】

このように、リソース・プロバイダ・エンティティは、クライアント・コンテキスト・データと、例えば、クライアント・デバイスの地理的移動に基づく第３ネットワーク・ノードにおけるネットワーク・ノードの将来の使用予測とに基づいて、第３ネットワーク・ノードを決定し、第３ネットワーク・ノードにおいてこのネットワーク・ノード機能を予め割り当て、予め読み込むことができる。

【0053】

実施形態では、第１ネットワーク・ノードからリソース・プロバイダ・エンティティにリソース割り当て要求を送信する動作は、クライアント・デバイスとは異なるネットワーク・デバイスによってトリガーすることができる。

【0054】

一実施形態では、第２ネットワーク・ノードはクラウド・サービスとすることができる。

【0055】

実施形態では、この方法は、更に、リソース・プロバイダ・エンティティにおいて、ネットワーク・ノード機能の使用に課金するステップを含むことができる。

【0056】

実施形態では、リソース・プロバイダ・エンティティは、更に、ネットワーク・ノード機能の使用に課金するように構成することができる。

【0057】

これによって、例えば、第２ネットワーク・ノードにおけるネットワーク・ノード機能の使用の課金が可能になる。

【0058】

以後、本発明の実施形態について更に詳しく説明する。しかしながら、これらの実施形態は、本発明に対する保護範囲を限定するように解釈してはならないことは、認められてしかるべきである。

【図面の簡単な説明】

【0059】

本発明の態様について、図面に示す実施形態例を参照しながら、更に詳細に説明する。

【図1】図１は、第２ネットワーク・ノードにおいてネットワーク・ノード機能を有効にするネットワーク・アーキテクチャの実施形態例である。

【図2】図２は、第２ネットワーク・ノードから第３ネットワーク・ノードへのネットワーク・ノード機能の事前割当を適用するネットワーク・アーキテクチャの実施形態例である。

【図3】図３は、本発明の実施形態例の時間シーケンス図である。

【図4】図４は、本発明の実施形態例の時間シーケンス図である。

【図5】図５は、本発明の実施形態例の時間シーケンス図である。

【図6】図６は、本発明の実施形態例の時間シーケンス図である。

【図7】図７は、本発明の実施形態例の時間シーケンス図である。

【図8】図８は、本発明の実施形態例の時間シーケンス図である。

【発明を実施するための形態】

【0060】

ネットワーク・ノード機能を第１ネットワーク・ノードにおいて使用する代わりに、第２ネットワーク・ノードにおけるそのネットワーク・ノード機能の配置および使用を可能にする解決手段を提供する。第２ネットワーク・ノードは、通例、クライアント・デバイスまたはクライアント・デバイスにサービスする運営業者のネットワークに関して、望ましい動作パラメータ（例えば、レイテンシ、帯域幅、ホップ、親和性、データ処理容量、ストレージ）に対して選択される。第１ネットワーク・ノードに送信されたクライアント要求は、第２ネットワーク・ノードにリダイレクトすることができる。

【0061】

クライアント・デバイスは、ＰＣ、ノートブック、タブレットまたはスマートフォン、あるいは第１ネットワーク・ノードおよび第２ネットワーク・ノード以外のネットワーク・ノードのような、任意のエンド・ユーザ・デバイスでよい。

【0062】

ネットワーク・ノードの例には、サーバおよびルータがある。ネットワーク・ノード機能の例には、サーバ機能およびルータ機能がある。サーバ機能は、例えば、アプリケーション・サービスを提供するウェブ・サーバ、ＨＴＴＰプロキシ、またはＤＨＣＰサーバである。ルータ機能の例には、経路計算（ルーティング・プロトコルの一部）、パケット・フィルタ、ファイアウォール、およびパケット転送がある。

【0063】

ネットワーク・ノードにおけるネットワーク・ノード機能の配置は、通例、ネットワーク・ノードにおけるハードウェア・リソースの割り当て、および割り当てられたハードウェア・リソース上へのネットワーク・ノード機能の読み込み(loading)を含み、これによってネットワーク・ノード機能を実行し使用することが可能になる。ネットワーク・ノード機能が既に第２ネットワーク・ノードに存在することも可能であり、その場合、このネットワーク・ノード機能をアクティブにすればよい。

【0064】

第２ネットワーク・ノードは、クラウド・ネットワークまたはクラウド・サービス・プロバイダにおいて編成された仮想機械をホストするための設備(facilities)、例えば、ハイパーバイザ(hypervisor)を提供することができる。次いで、ネットワーク・ノード機能は、仮想機械の一部として実現されてもよく、または多数のネットワーク・ノード機能が１つの仮想機械に組み合わせられてもよい。

【0065】

インターネット・ゲートウェイは、例えば、（ホーム）ルータ、ＰＤＮ−ＧＷ、またはＨ（ｅ）ノードＢである。

【0066】

クラウド・サービス・プロバイダは、例えば、クライアント、サーバ、および／またはネットワーク要件（例えば、クライアント・デバイスの地理的位置、クラウド・プロバイダの位置に対するネットワーク・コストおよび性能、および／またはポリシー）に基づいて、選択されるとよい。

【0067】

以下の例では、ネットワーク・ノードはサーバに関係し、ネットワーク・ノード機能はサーバ機能に関係する。以上の例は、ルータおよびルータ機能のような、他のタイプのネットワーク・ノードおよびネットワーク・ノード機能にも同様に適用することができる。以下の例では、ネットワーク・ノードがクラウド位置になっており、サーバがクラウド位置において実行する仮想機械（ＶＭ）になっているが、本発明はクラウド・コンピューティングに限定されないことは理解されよう。ネットワーク・ノードは、任意の種類のサーバであってもよく、ネットワーク・ノード機能は、任意の種類のサーバ機能であってもよい。

【0068】

図１は、ネットワーク・アーキテクチャの実施形態例を示す。クライアント・デバイス３とサーバ１との間にある矢印によって示されるように、クライアント・デバイス３は、通信可能に第１サーバ１に接続される。クライアント・デバイス３は、基地局３１を介して、移動体ネットワーク３０のエッジにおいて第１インターネット・ゲートウェイ５に接続される移動体デバイスであってもよい。サーバ１は、クラウド・ネットワーク３４における多数のクラウド・サーバ３５の内の１つであればよい。

【0069】

クライアント３は、要求をサーバ１に送ることができる。サーバ１は、例えば、ＵＲＬのような間接的な参照を使用することによって、任意の既知の方法でアドレスされればよい。ＵＲＬは、ドメイン・ネーム・サービス（ＤＮＳ）を使用して、またはサーバのネットワーク・アドレスを直接使用することによって、ＩＰアドレスのようなネットワーク・アドレスに変換される。クライアント要求は、サーバ１に達する前に、ネットワーク・サービス・プロバイダのインターネット・ゲートウェイ５を通過してもよい。サーバ１がクライアント要求を受信すると、サーバ機能の一部または全部を他の位置における第２サーバに委託することによって、（例えば、履歴データ、要求のタイプを使用して、あるいは能動的または受動的なネットワーク測定値を適用することによって）要求されたサービスを最適化できるか否か判断することができる。サーバ１は、ＶＭ（例えば、サーバ１のコピーまたは特定の機能）を作成するために、クラウド・サービス・プロバイダの位置確認を行うリソース要求を、リソース・プロバイダ・エンティティ４に送ることができる。これは、例えば、ＶＭ２において高い帯域幅および低いレイテンシのネットワーク接続を必要とするサーバ機能を配置することによって、クライアント３の性能およびエンド・ユーザ体験を最適化する。

【0070】

クライアントは、サーバ１への有線接続を有するデバイスであればよい。更に、クライアント・デバイスは、ルータまたはホーム・ルータ３３の仲介によってブロードバンド・ネットワーク３２に接続される。ルータまたはホーム・ルータ３３を介して、サーバ１への接続を行うことができる。

【0071】

図２に示す実施形態例を参照すると、第１サーバ１はリソース・プロバイダ・サービス４に、第３サーバ８上にリソースを予め割り当てるように、またはネットワークがあるイベントをトリガーしたときに（例えば、ハンドオーバーまたは輻輳の場合に）自動的にサーバ機能を割り当てるように要求することができる。図２の例では、クライアント・デバイス３が、基地局３１および第１インターネット・ゲートウェイ５の仲介により、第２サーバ２に通信可能に接続される。この例では、クライアント・デバイス３は、左側のクライアント・デバイス３（即ち、第１地理的位置にあるクライアント・デバイス３）と右側のクライアント・デバイス３（即ち、第２地理的位置にあるクライアント・デバイス３）との間にあるブロック矢印によって示されるように、他の基地局３１のカバレッジ・エリアに移動する。これは、ハンドオーバー・イベントをトリガーすることができ、リソース・プロバイダ４に向かう矢印によって表されるように、ハンドオーバー・イベントはソース・プロバイダ４において受諾される。リソース・プロバイダ４は、第２サーバ２に、サーバ機能を割り当てる、例えば、リソース・プロバイダ４から第２サーバ２への矢印によって表されるように、その状態およびデータを、クライアント・デバイス３のために、第３サーバ８に転送することを知らせることができる。この状態およびデータの転送は、第２サーバ２および第３サーバ８間にあるブロック矢印によって示される。

【0072】

ハンドオーバー・ネットワーク・イベントは、ホーム・サブスクライバ・サーバ（ＨＳＳ）のような、ネットワーク・イベントを待ち受ける(listen to)移動体ネットワークにおけるノードによって検出することができる。ＨＳＳは、再割り当てを自動的に開始し、ネットワーク・ノード２，８におけるサーバ機能が、クライアント・デバイス３からの明示的なリソース要求がなくても、エンド・ユーザにとって最適な位置に連続的に配置されることを確保することができる。

【0073】

クライアント・デバイス３が、ＧＰＲＳ、ＵＭＴＳ、またはＬＴＥ移動体デバイスのような移動体通信デバイスである場合、クライアント・デバイス３は、通例、ＰＤＮ−ＧＷまたはインターネット・ゲートウェイ５，６の仲介によってデータ接続を有するように構成される。次いで、データ・トラフィックはクライアント・デバイス３からインターネット・ゲートウェイ５，６に抜ける(tunneled)。任意に、サーバ２，８はインターネット・ゲートウェイ５，６に配置される。３ＧＰＰ規格は、クライアント・デバイス３にＩＰ接続を提供するインターネット・ゲートウェイ５，６が、地理的にクライアント・デバイス３の近くで、インターネット・ゲートウェイ５，６のＩＰアドレスを解明するための既知のＤＮＳ方法を使用して、選択されることを推奨する。したがって、インターネット・ゲートウェイ５，６は地理的にクライアント・デバイス３の近くに配置されると仮定することができる。

【0074】

図３〜図８は、本発明の実施形態例の時間シーケンス図を示す。エレメント間におけるデータの転送は、矢印によって表される。角括弧間の参照は、転送されるデータの内容を示す。黒点は、エレメントにおいて実行されるアクションを表す。図５〜図８において示されるような破線の垂直線は、１つ以上のステップが、簡略化のために、示されないことを表す。

【0075】

図３において、例えば、移動体ネットワークにおけるクラウド位置における第２サーバ２上にサーバ機能を有効にする例が示される。クライアント・デバイス３において実行するプログラムが、セッションを開始することができ、要求データ１０１を第１サーバ１に送る。例えば、ＨＴＴＰ、ＦＴＰ、ＳＳＨ、ＳＭＴＰ、ＳＩＰ、または任意の他のプロトコルを使用するクライアント・サービス要求方法に依存して、クライアント識別データを含む要求データ１０１は、サーバ１においてクライアント・デバイス３から受信される（１１）。サーバ１は、通例、クライアント・デバイス３のユーザからは透過的である。サーバ１は、ＩＰｖ４アドレス、ＩＰｖ６アドレス、ホーム・ネーム、またはクライアント識別データからの任意の他の識別を使用して、クライアント３を担当するリソース・プロバイダ・エンティティ４のサービス・アクセス・ポイント（例えば、URLの形態）を決定する（１２）。

【0076】

リソース・プロバイダ・エンティティ４のサービス・アクセス・ポイントの決定（１２）は、図７に示すような、参照データベース７を使用してリソース・プロバイダ・エンティティ４への参照を解明する（２２）ことに基づいてもよい。参照データベース７は、例えば、フーイズ・データベース(Whois database)、ジオＩＰデータベース(geolP database)、またはＩＰアドレス範囲をリソース・プロバイダ・エンティティ４にリンクするデータベースである。サーバ１は、フーイズ・データベースに対してフーイズ要求２３を実行し、クライアント・デバイス３のＩＰアドレス空間に関連付けられたリソース・プロバイダ４のインターフェースへの参照を構築するために応答２４を受信する。クライアント・デバイス３のＩＰアドレスを地理的に最も近いリソース・プロバイダ位置と組ませる(match)ために、代わりにまたは加えて、リソース・プロバイダ４はジオＩＰデータベースを使用して解明されてもよい。この場合、ジオＩＰデータベースは、通例、ＩＰアドレス、およびリソース・プロバイダのサービス・アクセス・ポイントの地理的位置を含む。サーバ１は、参照要求２３に応答して、ＩＰアドレスのリソース・プロバイダへのマッピングのリストを受信することができる（２４）。

【0077】

要求データ１０１は、通例、サーバ１において要求されている機能の指示を、例えば、サービス要求の形態で含む。追加のユーザまたはデバイス特定プロパティが、要求データ１０１に含まれてもよく、サーバ１はこのプロパティを、リソース・プロバイダ・エンティティ４の決定１２において使用する、および／またはリソース割り当て要求１０２を生成するために使用することができる。このようなプロパティの例は、クライアント・デバイスのＧＰＳ位置、証明書、およびサービス・レベル同意情報である。クライアント３およびサーバ１は、加えてまたは代わりに、サーバにプロパティを供給するためにプロトコルを使用することもできる。このようなプロトコルの例は、クライアント・デバイス３の地理的位置を受信するためにサーバ１がクライアント３のＧＰＳデバイスへのアクセスを要求することである。他の例は、サーバが明示的に加入者識別情報を要求することである。

【0078】

サーバは、リソース割り当て要求１０２を生成する。リソース割り当て要求１０２は、サーバ機能が読み込まれる第２サーバ２をリソース・プロバイダ４が決定することに関連するデータを含む。リソース割り当て要求１０２は、通例、クライアントＩＰアドレスまたは任意の他のクライアント識別データ、および要求されたサーバ機能の指示を含む。任意に、リソース割り当て要求１０２は、クライアント特定プロパティを含む。要求されたサーバ機能の指示と共に、サーバ機能を実行するためのリソース要件、および／またはサーバ機能を読み込み実行するためにサーバ機能データを参照するＵＲＬを供給することもできる。サーバ１は、リソース割り当て要求１０２をリソース・プロバイダ・エンティティ４に送信する（１３）。

【0079】

リソース割り当て要求１０２において提供された情報を使用して、リソース・プロバイダ・エンティティ４はクライアント・コンテキスト・データを得る（１４）。ここでは、リソース・プロバイダ・エンティティ４は、クライアントＩＰアドレスを使用して、クライアント・デバイス３のホーム・ネットワークに問い合わせて、例えば、加入者の識別情報を求めることができる。入手可能であれば、リソース・プロバイダ４は、リソース割り当て要求１０２における追加のパラメータを使用して、ネットワークにおけるクライアント・デバイスのコンテキスト、例えば、ＰＧＳ座標、またはクライアント３によって供給される送信元アドレス・フィールド(X-Forwarded-For field)における送信元ＩＰアドレスを判定してもよい。ネットワーク・サービス・プロバイダは、通例、それらのＩＰ空間からのＩＰアドレスを、現在それを使用している加入者識別情報と照合することができる。一旦加入者識別情報がわかったなら、ネットワーク・サービス・プロバイダはネットワークにおけるクライアント・デバイスのコンテキストを構築することができる（例えば、地理的位置、インターネット・ゲートウェイ、ネットワーク・サービス、方針、および許可）。クライアント・デバイス３も、サーバ１も、リソース・プロバイダ４も、ネットワークのトポロジ知識を必要としない。クライアント・デバイス３が、例えば、ネットワーク・サービス・プロバイダのネットワークのネットワーク・アドレス変換デバイスの後ろにあり、公開ＩＰアドレスのみが与えられる場合、ネットワーク・サービス・プロバイダは、例えば、５−タプル（ソースＩＰ、宛先ＩＰ、ソース・ポート、宛先ポート、プロトコルＩＤ）から加入者識別情報を判定することができると想定する。これは、ＮＡＴが、通例、接続を提供するために、公開アドレスおよびポートと秘密アドレスおよびポートとの間のマッピングを維持するからである。

【0080】

このようにして得られたクライアント・コンテキスト・データは、リソース・プロバイダ・エンティティ４によって、サーバ機能が読み込まれる第２サーバ２を決定する（１５）ために使用される。例えば、リソース要求、リソース割り当て要求１０２からのクライアント特定プロパティ、ならびにクラウド位置およびそれらのプロパティの予め格納されたリストから、リソース・プロバイダ４はクラウド位置２を選択する。

【0081】

第２サーバ２またはクラウド位置２は、直接インターネット・ゲートウェイ６に接続されても(attach)、ローカル・エリア・ネットワークを通じて接続されても、あるいはワイド・エリア・ネットワークまたはインターネットのような他のネットワーク３２を通じて接続されてもよい。インターネット・ゲートウェイ６に接続される場合、クラウド位置２のインターフェースは、例えば、クラウド位置に関連付けられたインターネット・ゲートウェイＤＮＳネームおよびＩＰアドレスのリストを維持することによって、インターネット・ゲートウェイ６の識別子から構築されるとよい。ローカル・エリア・ネットワークまたは他のネットワーク３２を通じて接続される場合、クラウド位置２は、地理的距離、帯域幅、およびインターネット・ゲートウェイに対するサービス品質というような、他のパラメータに対する選択でもよい(be selection on)。

【0082】

リソース・プロバイダ・エンティティ４は、デフォルトのルール・セットを使用して、またはリソース割り当て要求１０２において与えられるルール・セットおよびネットワーク・サービス・プロバイダによって維持されるクラウド位置プロパティのリストに基づいて、最良の相応しい(matching)クラウド位置２を決定し、任意に関連するインターネット・ゲートウェイ６も決定する（１５）ことができる。クライアント特定リソース要件というような追加のパラメータが与えられない単純な場合では、リソース・プロバイダ４は、クライアント・デバイス３の現在のインターネット・ゲートウェイ５に直接関連付けられたクラウド位置２を選択する（例えば、ＨＳＳから引き出される）。デフォルト・クラウド位置の選択は、クラウド位置２のクライアント・デバイス３またはそのインターネット・ゲートウェイ５，６までの地理的距離、レイテンシ、ジッタ、およびその他のプロパティ（例えば、加入者に関連付けられたセキュリティ・レベル、または地理的境界）を含むことができ、インターネットまたはネットワーク・サービス・プロバイダのネットワークにおける異なるインターネット・ゲートウェイ６またはクラウド位置２の選択に繋げることができる。プロパティの中でもとりわけ、クラウド位置に関連付けられたプロパティのリストは、価格設定、即ち、特定の位置においてサーバ機能を使用するコスト、および位置に関連付けられた能動的または受動的な測定値（例えば、指定されたＩＰ宛先に対する帯域幅、レイテンシ、またはジッタ）を含むとよい。

【0083】

以下の表は、クラウド位置に関連付けられたプロパティのリストの例である。この例におけるクラウド位置は、ＵＲＬとして与えられる。クラウド位置においてサービスをホストするコストは、「価格」という列において与えられる。クラウド位置が接続されるＰＤＮ−ＧＷの地理的位置は、経度／緯度地理的座標で与えられる。ＰＤＮ−ＧＷにアドレシングするために使用されることが可能な、ＰＤＮ−ＧＷの識別情報も与えられる。最後の３つの列は、クラウド位置に関連付けられた帯域幅、レイテンシ、およびジッタ情報を与える。

【0084】

【表1】

【0085】

リソース割り当て要求１０２が、例えば、価格が１を超えてはならないというルールを含む場合、上に示すプロパティ表における最初の行が選択されると、クラウド位置http://cloudlocation1.netの選択という結果となる。

【0086】

クラウド位置２の決定１５の結果、通例、クラウド位置２（例えば、ＲＥＳＴを使用する）および任意にインターネット・ゲートウェイ５，６のインターフェースへの参照（例えば、ＵＲＩまたはＵＲＬ）が得られる。

【0087】

クラウド位置を発見する最適化が可能である。例えば、加入者識別情報が、予め定められた数のクラウド位置と関連付けられてもよく、またはインターネット・ゲートウェイがデフォルトのクラウド位置に割り当てられてもよい。加入者識別情報は、位置統計または方針に基づいて（例えば、ユーザが事務所にいる、またはユーザが自宅にいる）、１組のデフォルト・クラウド位置と関連付けられてもよい。

【0088】

その結果、クラウド選択は、ＨＳＳにおける参照に簡略化されることが可能になる。

【0089】

リソース・プロバイダ・エンティティ４は、第２サーバ２が発見されたことを承認するために、応答データ１０４を第１サーバ１に送ることができる。得られたクラウド位置が、クライアントが現在使用しているインターネット・ゲートウェイ５以外に、インターネット・ゲートウェイ６を通じて到達可能である場合、リソース・プロバイダ・エンティティ４は、応答データ１０４内にある情報（例えば、接続すべき新たなＡＰＮ）をサーバ１に追加することができ、一方、サーバ１は応答データ１０４をクライアント・デバイス３に送信することができる（例えば、ＨＴＴＰ応答ヘッダ内に埋め込まれる）。クライアント・デバイスは、応答データ１０４内にある追加情報を使用して、ネットワークに、他のインターネット・ゲートウェイ６へのアクセスを要求することができる。例えば、ＨＴＴＰ応答が、（新たな）ターゲットＰＤＮ−ＧＷ６を識別するＡＰＮを含むとき、クライアント３は、電気通信ネットワークにおける既存のメカニズムを使用して、接続要求(attach request)をネットワークに送ることができる。

【0090】

一旦クラウド位置、および任意に、クラウド位置２が接続されるインターネット・ゲートウェイが決定されたなら、リソース・プロバイダ・エンティティ４は機能配置要求１０３を、選択されたクラウド位置２（または他の第２サーバ２）に、リソース割り当て要求１０２からのパラメータと共に送ることができる（１６）。

【0091】

クラウド位置２は、機能配置要求１０３に基づいて、サーバ機能を、例えば、仮想機械上に読み込む（１７）。例えば、サーバ機能のデータ・イメージの形態であるサーバ機能データ（または更に一般的には、ネットワーク・ノード機能データ）は、読み込みの前に、任意のデータ・ソースからダウンロードされればよい。例えば、サーバ機能データがクラウド位置２にない場合、クラウド位置２は、図４に示すように、例えば、リソース割り当て要求１０２における任意のＵＲＬによって参照されるサーバ機能データをダウンロードすることができる（２０）。図４の例では、サーバ機能データは第２サーバからダウンロードされるが、任意の他のソースからダウンロードされてもよい。サーバ機能データは、例えば、仮想システムのディスク・イメージ、他のリソース、および記述を収容するオープン仮想化フォーマット(open virtualization format)でフォーマットされたファイルである。ＯＶＦパッケージは、機能配置要求１０３からの指定されたリソース要件（例えば、メモリ量、ディスク・サイズ、およびＣＰＵの数）によって、クラウド位置２におけるハイパーバイザ（例えば、ＫＶＭ、ＶＭware）上で仮想機械を実行するために使用することができる。リソース割り当て要求１０２におけるＵＲＬによるデータ参照は、集中レポジトリにおいてキャッシュされるまたは利用可能に保持されても、あるいはネットワーク・サービス・プロバイダのネットワークにわたって分散されてもよい。例えば、ローミングまたはハンドオーバーの場合、データを多数の位置にわたって分散すると、２つの位置間で転送しなければならないデータ量を減らすことができる（例えば、ＶＭ状態を、ローカルに入手可能なコピーと同期させるだけでよい）。

【0092】

第２サーバ２またはクラウド位置２は、サーバ機能を実行するサーバにクライアント・デバイス３によって到達可能なＩＰアドレスまたは任意の他のアドレスを、ネットワークにおけるＤＨＣＰまたは他のメカニズムを介して割り当てることができる。第２サーバのＩＰアドレスは、ファイアウォールの後ろに位置してもよい。その場合、第２サーバ２は、通例、第１サーバ１との通信を開始する。例えば、サーバ機能を提供するために仮想機械が使用される場合、クラウド位置２は、ストリングまたはストリングを参照するＵＲＬを、ＶＭに関する情報（例えば、ＩＰアドレス、ユーザ名、パスワード、証明書、暗号ハッシュ、リソースを監視するためのＵＲＬ、ＶＭを制御するためのＲＥＳＴインターフェース）と共に戻すことができる。

【0093】

割り当ての結果、リソース・プロバイダ・エンティティ４は、特定のクラウド位置におけるというような、第２サーバ２におけるサーバ機能の使用に対して課金および／または請求書作成を開始することができる。請求書作成は、第２サーバ２においてサーバ機能の使用を開始したサーバ１の所有者に対してでもよく、クライアント・デバイス３の所有者に対してでもよく、またはサーバ１の所有者とクライアント・デバイス３の所有者との間で分配されてもよい。ここでは、第２サーバ２におけるサーバ機能を、第１サーバ１またはクライアント・デバイス３の所有者およびその加入者識別情報と関連付けるＩＰアドレスのリストが維持されるとよい（例えば、リソース・プロバイダ４またはＨＳＳの一部において）。

【0094】

一旦サーバ機能が第２サーバ２において有効にされ、そのプロパティ（例えば、ＩＰアドレス）が知られると、リソース・プロバイダ４は第２サーバ２に関連付けられたクライアント・デバイス３またはインターネット・ゲートウェイ５，６（例えば、ホーム・ルータ、住居用ゲートウェイ、ＰＤＮゲートウェイ、Ｈ（ｅ）ノードＢ）にプロビジョニングすることができる。インターネット・ゲートウェイ５，６のプロビジョニングは、パケット・フィルタリング、ネットワーク・アドレス変換を必要とすることがあり、更に、名称解明（name resolving)またはリダイレクトのためのアプリケーション・レイヤ・ゲートウェイ・サービスを必要とする可能性もある。リソース・プロバイダ４は、第２サーバ２についての情報を使用して、ホーム・ネーム、パケット・フィルタリング・ルール、ネットワーク・アドレス変換マッピング、およびクライアント要求１０５の第２サーバ２へのリダイレクト１９が得られるアプリケーション・レイヤ・ゲートウェイ・ルールから、リダイレクトされるＩＰアドレスを解明することができる（例えば、第２サーバのホーム・ネームがリソース要求において与えられた場合）。

【0095】

更に、クライアント要求１０５は、クライアント・デバイス３またはインターネット・ゲートウェイ５，６によって第２サーバ２にリダイレクトされてもよい。ここでは、インターネット・ゲートウェイ５，６またはクライアント・デバイス３は、応答データ１０４を使用して構成される。

【0096】

一旦サーバ機能が第２サーバ２において実行し、クライアント要求１０５が第２サーバ２にリダイレクトされたなら、第２サーバにおけるサーバ機能は、明示的にまたはトリガーによって停止されてもよい。サーバ機能の停止は、第１サーバ１によって（例えば、ＶＭがそれ自体をシャットダウンすることを可能にする終了タイマを使用して）、リソース・プロバイダ４によって（例えば、予め定められた最大資金予算に達したとき）、または明示的なクライアント３の要求によって（例えば、削除クエリーをリソース・プロバイダ４に送ることによって）トリガーされてもよい。例えば、クラウド位置２におけるＶＭが停止要求を受けたとき、リソース・プロバイダ４に通知し、リソース・プロバイダ４は、関連付けられたインターネット・ゲートウェイ５，６またはクライアント３におけるあらゆる構成されたリダイレクトというような、ＶＭに関連付けられたあらゆる状態を一掃する。

【0097】

図５は、第１インターネット・ゲートウェイ５が、クライアント・デバイス３と第１サーバ１との間、クライアント・デバイス３と第２サーバ２またはクラウド位置２との間、そしてクライアント・デバイス３とリソース・プロバイダ・エンティティ４との間におけるメッセージ・フローに、第１インターネット・ゲートウェイ５がどのように関与し得るかの例を示す。メッセージ・フロー１１、１８、１９は、図３に示したものと同様であるが、ここでは、図示のように、第１インターネット・ゲートウェイ５を介して進む。

【0098】

図６は、第１インターネット・ゲートウェイ５および第２インターネット・ゲートウェイ６が、クライアント・デバイス３と第１サーバ１との間、クライアント・デバイス３と第２サーバ２またはクラウド位置２との間、そしてクライアント・デバイス３とリソース・プロバイダ・エンティティ４との間におけるメッセージ・フローにどのように関与し得るかの例を示す。メッセージ・フロー１１、１８、１９は、図３に示したものと同様であるが、ここでは、図示のように、第１インターネット・ゲートウェイ５および第２インターネット・ゲートウェイを介して進む。

【0099】

第１サーバ１はリソース・プロバイダ４を知っているので、高度な動作が可能である。第１サーバ１は、例えば、図８の例に示すように、１つのサーバではなく、多数のサーバ２、８においてサーバ機能が利用可能になることを要求することができる（例えば、予想される軌道(trajectory)に基づいて）。図３の例と同様に、図８では、リソース・プロバイダ・エンティティ４は、クライアント・コンテキスト・データに基づいて、第２サーバ２を決定する（１５）。更に、リソース・プロバイダ・エンティティ４は、クライアント・コンテキスト・データ、および第３サーバ８におけるサーバ機能の将来の使用予測に基づいて、例えば、クライアント・デバイス３の地理的移動に基づいて、第３サーバ８を決定する（２５）。機能配置要求１０３の他に、別の機能配置要求１０６が、サーバ機能を第３サーバ８において有効にするために、第３サーバ８に送信されてもよい。多数のサーバ２、８におけるサーバ機能の有効化は、例えば、サーバ割り当てを高速化するために使用することができる。

【0100】

ローミングの場合、クライアント・デバイス３のＩＰアドレスをクライアント・デバイス３のホーム・ネットワークと関連付けてもよい。何故なら、クライアント・デバイス３は、訪問先ネットワークにおけるローカル・インターネット・ゲートウェイにアクセスできないか、または他のネットワークに移動する前にホーム・ネットワークに接続されたからである。結果的に、第２サーバ２の位置は、ホーム・ネットワークにおけるインターネット・ゲートウェイ５に地理的に近くなるが、クライアント・デバイス３から地理的に遠ざかってもよい。訪問先ネットワークがローカル・インターネット・ゲートウェイ６へのアクセスを与えるとき、ＨＳＳはこの変化の情報によって更新されてもよく、加入者識別情報のＨＳＳ更新を待ち受けるＩＭＳアプリケーションが、リソース・プロバイダ４に、サーバ機能を訪問先ネットワークにおける第２サーバ２またはクラウド位置２に読み込ませるまたは移動させることもできる。

【0101】

リソース・プロバイダ・エンティティ４は、サーバがそのように要求した場合、ハンドオーバーまたはネットワーク輻輳の指示というような、任意のネットワーク・イベントによってトリガーされる新たな位置に、第２サーバ２におけるサーバ機能を動的に移動させることができる。例えば、ハンドオーバーの場合、加入者識別情報に関連付けられたＨＳＳイベントを待ち受けるＩＭＳアプリケーションを作ることができる。ハンドオーバー時に、ＩＭＳアプリケーションは、新たなリソース要求を新たな位置と共に、リソース・プロバイダ４に送ることができる。一旦サーバ機能が第２サーバ２において有効にされたなら、リソース・プロバイダ４はサーバ機能を第１サーバ１から削除する、または古い位置へのハンドオーバーが要求された場合にはそれを有効のまま保持することができる。リソース・プロバイダは、第２サーバ２から第１サーバ１へのリダイレクトを行うことを選択してもよい。これによって、サーバ機能は第１サーバにおいて利用可能のまま残ることが可能になるが、第２サーバ２においては、サーバ機能はもはや利用可能ではない。ホームおよび訪問先ネットワークの双方が、状態およびデータ転送を高速化するために、サーバのキャッシングおよび分散を共有することも可能である（例えば、コンテンツ分散ネットワーク）。

【0102】

本発明は繰り返し多数のドメインに適用されてもよい。例えば、リソース・プロバイダ４がＶＭのためにクラウド位置２を要求したとき、それは次に(on its turn)そのドメインにおけるリソース・プロバイダに、与えられた要件に最も適したクラウド位置およびインターネット・ゲートウェイを選択することを要求することができる。

【0103】

第２サーバ２は、リソース割り当て要求１０２を送ることができる。リソース・プロバイダ・エンティティ４は、次いで、サーバ関連のリストから引き出された加入者識別情報（恐らくは、その関連付けられた許可および方針を使用する）の代わりに、他のサーバにおけるサーバ機能の有効化を開始することができる。

【0104】

本発明の一実施形態は、コンピュータ・システムによる使用のためのプログラム製品として実現することもできる。プログラム製品のプログラム（１つまたは複数）は、実施形態の機能（本明細書において説明した方法を含む）を定め、種々の非一時的コンピュータ読み取り可能記憶媒体に収容することができる。例示のコンピュータ読み取り可能記憶媒体には、（ｉ）情報が永続的に格納される非書き込み可能記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内部のリード・オンリー・メモリ・デバイス、ＲＯＭチップ、または任意のタイプのソリッド・ステート不揮発性半導体メモリ）、および（ｉｉ）変化可能な情報が格納される書き込み可能記憶媒体（例えば、ディスケット・ドライブ内におけるフラッシュ・メモリ、フロッピ・ディスク、またはハード・ディスク・ドライブ、または任意のタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）が含まれるが、これらに限定されるのではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】