JP2014532233A - モビリティおよびマルチホーミングコンテンツ検索アプリケーションのためのシステムおよび方法 - Google Patents

Abstract

ＴＣＰ／ＩＰスタック層またはセッション層内のクライアントアプリケーションの下のコントローラ機能が、セッションベースのアプリケーション層機能（例えば、コンテンツ検索）に関連する状態およびステータス情報を監視すると共に、この情報を使用して、１つまたは複数のセッションを第１のクライアントインターフェースから第２のクライアントインターフェース（例えば、３Ｇ、４Ｇ、ＬＴＥ、８０２．１１ｘ、ＷｉＭＡＸ）へと、また別のアプリケーション機能供給エンティティ（例えば別のコンテンツサーバ、キャッシュサーバ、サービスプロバイダ）へとマイグレーションさせる。

Description

本発明は、一般にマルチホームホストまたはモバイルホストに関し、より詳細には、それだけには限らないが、通信ネットワーク間のホスト移行のようなものとしてコンテンツ検索のシームレスセッションマイグレーションを実現することに関する。

モバイルホストまたはマルチホームホストでは、コンテンツ検索セッションを実行しながら（例えばクライアントが遠隔のサーバからデータを検索しながら）、ホストの第３層のネットワークアクセスポイント（すなわちＩＰアドレス）を変更しなければならないことがある。このようなインターフェース変更は、「新」インターフェースの方が「旧」インターフェースよりもリンク品質が高い、または遭遇する輻輳が少ないために望ましいことがある。このインターフェースはまた、ユーザが１つのネットワークのカバレージエリアから別のネットワークのカバレージエリアへ移動するときにも変更しなければならない。

クライアントの新インターフェースに対しては、別のサーバの方が、ホストの旧インターフェースへデータを送出していたサーバよりもデータを送出するのにより適していることがある。これは、新サーバが、クライアントの新インターフェースにより近接しているためでありうる。また、インターフェースの１つに接続しているネットワークが１つのアプリケーション層プロキシを保持するが、他のインターフェースをサポートするネットワークはこのようなプロキシを保持しない、または異なるプロキシを保持するという可能性もある。このようなプロキシ情報は、モバイル／マルチホームホストにおいて事前設定することができるのに対し、コンテンツ検索のために使用されるリモートアドレスは、インターフェースを変更するときに変更しなければならない。

少なくともこれらの理由のために、コンテンツ検索のためにクライアントによって使用されるインターフェースと一緒に、コンテンツを送出するサーバを変更する機能を実現することが望ましい。

コンテンツ検索アプリケーションでは一般に、ＴＣＰ、ＳＣＴＰまたはＭＰＴＣＰなどのストリーム型トランスポートプロトコルを使用し、これらにより、クライアントがコンテンツサーバに接続されると共に、信頼性が高く順序正しいコンテンツの送出が確保される。ＴＣＰが下位トランスポートプロトコルとして使用される場合、トランスポート接続は、後継クライアントサーバセッションを中断しなければ別のインターフェースへマイグレーションさせることができない。ＳＣＴＰが使用される場合、クライアントは、トラフィックフローを旧インターフェースから新インターフェースにマイグレーションさせることができる。しかし、旧サーバ上のＳＣＴＰ制御ブロックが、新サーバと共有されていない接続関連情報を保持しているので、サーバを同時に変更することは不可能である。同じ問題が、接続にＭＰＴＣＰが使用される場合にも起こる。さらに、ＳＣＴＰおよびＭＰＴＣＰは一般に、インターネット上でサポートされていない。

したがって、第３層でセッションエンドポイントマイグレーションの機能に対応し、トランスポート層およびアプリケーション層には透過的ないくつかのモビリティ／マルチホーミングプロトコルがある。例としては、Ｍｏｂｉｌｅ ＩＰプロトコルファミリ、ＳＨＩＭ６およびＬＴＥがある。これらの解決策の中には、ホームエージェントまたは専用ゲートウェイ（ＭＩＰｖ４、ＭＩＰｖ６、ＤＳＭＩＰ、ＰＭＩＰ、ＬＴＥ）などの追加のネットワークノードが必要になるものもある。残念ながら、これらの解決策のどれによっても、データ検索が進行している間にコンテンツサーバを変更することができない。

コンテンツ中心ネットワークと呼ばれる提案があり（例えば、Ｊａｃｏｂｓｏｎ他、「Ｎｅｔｗｏｒｋｉｎｇ Ｎａｍｅｄ Ｃｏｎｔｅｎｔ」、ＣｏＮＥＸＴ’０９、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｆｉｆｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｅｍｅｒｇｉｎｇ Ｎｅｔｗｏｒｋｉｎｇ Ｅｘｐｅｒｉｍｅｎｔｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｉｅｓ）、これによると、コンテンツ検索セッション中のモビリティ／マルチホーミングおよびコンテンツソースマイグレーションが可能になる。しかし、これらの提案は、現在のＩＰ層プロトコルおよびトランスポート層プロトコルに対応していない。同じ理由のために、これらの提案はさらに、既存のネットワークインフラストラクチャまたはインターネットにも対応していない。

付着点変更およびサーバ変更がクライアントアプリケーション自体の中に構築されるアプリケーション層解決策が存在する。このようなアプリケーションでは、データ転送を中途で停止し、対応するトランスポート接続を終了させ、新トランスポート接続を再確立し、同じサーバまたは新サーバに残りのデータを要求することができる。これらの解決策は、特定のアプリケーション層プロトコルならびにコンテンツのデータタイプに適合させることができるが、すべてのクライアントアプリケーションによって別個に実施する必要がある。これは非常に厄介であり、また本質的に、既存アプリケーションすなわちレガシーアプリケーションをサポートしない。

いくつかのコンテンツ検索技術が、コンテンツ検索でクライアントによって使用されるコンテンツおよび／またはインターフェースを送出するサーバを変更するために存在するとはいえ、残念ながら、これらの技術のどれも、既存および進化中のトランスポートプロトコルへの対応を維持しながら既存のクライアントアプリケーションをサポートすることはできない。

Ｊａｃｏｂｓｏｎ他、「Ｎｅｔｗｏｒｋｉｎｇ Ｎａｍｅｄ Ｃｏｎｔｅｎｔ」、ＣｏＮＥＸＴ’０９、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｆｉｆｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｅｍｅｒｇｉｎｇ Ｎｅｔｗｏｒｋｉｎｇ Ｅｘｐｅｒｉｍｅｎｔｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｉｅｓ

従来技術の様々な欠陥が諸実施形態によって対処される。これらの実施形態では、マルチホームホストまたはモバイルホストによる実質的に連続したコンテンツ検索により、コンテンツ検索中にそのインターフェースだけでなく、クライアントセッションによって使用されるコンテンツサーバも変更することが、クライアントでのコンテンツ検索セッションを中断しなくても可能になる。

様々な実施形態では、ＴＣＰ／ＩＰスタック層またはセッション層内のクライアントアプリケーションの下のコントローラ機能が実施される。このコントローラ機能は、アプリケーション層プロトコルによって使用される様々なコマンドを監視して、アプリケーション層機能が、別のクライアントインターフェース（例えば、３Ｇ、４Ｇ、ＬＴＥ、８０２．１１ｘ、ＷｉＭＡＸ）に、およびまたは別のアプリケーション機能供給エンティティ（例えば別のコンテンツサーバ、キャッシュサーバ、サービスプロバイダ）にマイグレーションできるように、アプリケーション層機能（例えば、コンテンツ検索）に関連する状態およびステータス情報を維持する。

一実施形態では、ホストにおいてコンテンツ検索アプリケーションと関連付けられたコンテンツ検索セッションを第１のインターフェースを介して第１のサーバから、第２のインターフェースを介して第２のサーバへマイグレーションさせるための装置は、第２のインターフェースを使用して第２のサーバへのトランスポート接続を確立し、検索されるべきコンテンツと関連付けられた識別子と、コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の表示とを含むコンテンツ要求メッセージを、第２のインターフェースを介して第２のサーバに向けて送信し、第２のインターフェースを介して受け取られたコンテンツ担持データストリームを解析して、コンテンツ検索アプリケーションによって受け取られるさらなるコンテンツ部分を識別し、およびコンテンツ検索アプリケーションに向けて、識別された、コンテンツ検索アプリケーションが受け取らなかったコンテンツ部分を転送するように、構成されたプロセッサを備える。

別の実施形態では、ホストにおいてコンテンツ検索アプリケーションと関連付けられたコンテンツ検索セッションを第１のインターフェースを介して第１のサーバから、第２のインターフェースを介して第２のサーバへマイグレーションさせるための方法は、第２のインターフェースを使用して第２のサーバへのトランスポート接続を確立するステップと、検索されるべきコンテンツと関連付けられた識別子を含み、およびコンテンツ検索アプリケーションによって受け取られるコンテンツ部分の表示を含むコンテンツ要求メッセージを、第２のインターフェースを介して第２のサーバへ送信するステップと、第２のインターフェースを介して受け取られたコンテンツ担持データストリームを解析して、コンテンツ検索アプリケーションによって受け取られるさらなるコンテンツ部分を識別するステップと、コンテンツ検索アプリケーションに向けて、識別された、コンテンツ検索アプリケーションが受け取らなかったコンテンツ部分を転送するステップとを含む。

様々な実施形態では、ＴＣＰ／ＩＰスタック層またはセッション層内のクライアントアプリケーションの下のコントローラ機能が、セッションベースのアプリケーション層機能（例えば、コンテンツ検索）に関連する状態およびステータス情報を監視すると共に、この情報を使用して、１つまたは複数のセッションを第１のクライアントインターフェースから第２のクライアントインターフェース（例えば、３Ｇ、４Ｇ、ＬＴＥ、８０２．１１ｘ、ＷｉＭＡＸ）へと、また別のアプリケーション機能供給エンティティ（例えば別のコンテンツサーバ、キャッシュサーバ、サービスプロバイダ）へとマイグレーションさせる。

本明細書の教示は、以下の詳細な説明を添付の図面と併せて考察することにより容易に理解することができよう。

一実施形態によるホストデバイスを含む通信システムの高レベルブロック図である。 図１の通信システムに使用するのに適したホストデバイスの高レベルブロック図である。 図１の通信システムに使用するのに適したホストデバイスの高レベルブロック図である。 一実施形態による方法を示すプロトコル図である。 一実施形態による方法を示す流れ図である。 一実施形態による方法を示す流れ図である。 本明細書に記載の機能を実行するのに適したコンピュータの高レベルブロック図である。

理解しやすいように、可能な場合には、各図に共通の同じ要素を示すのに同一の参照番号が使用されている。

マルチホームホストまたはモバイルホストが、コンテンツを供給するサーバを、クライアントによって使用されるインターフェースと一緒に、コンテンツ検索アプリケーションには透過的な方法で変更できるようにする一般化機能が本明細書で図示され説明されるが、様々な他の関連および／または非関連の機能もまた開示されうることに留意されたい。

様々な実施形態では、既存および進化中のトランスポートプロトコルへの対応を維持しながら、マルチホームホストまたはモバイルホスト内の既存のクライアントアプリケーションをサポートして、コンテンツを供給するサーバを、コンテンツ検索のためにクライアントによって使用されるインターフェースと一緒に変更する。

様々な実施形態が、ネットワークにあるサーバのコンテンツの検索のためのアプリケーションを使用するモバイルホストおよび／またはマルチホームホストに適用可能である。このようなコンテンツ検索セッションの例には、ウェブブラウジングセッション中、ウェブベースのビデオストリーミングセッション中、ＨＴＴＰベースのファイル転送セッション中、および他の非ステートフルコンテンツ検索セッション中などに実行される、ウェブサーバからのダウンロードが含まれる。諸実施形態では、進行しているクライアントアプリケーションへのデータ送出を保ちながら、すなわちアプリケーションを中断または再起動することなく、ホストがネットワークインターフェースならびにコンテンツ送出サーバを透過的に変更することが可能である。

諸実施形態では、オフセット機能をサポートするクライアントアプリケーションによって使用される安全な冪等メソッド呼出しを行う。このオフセット機能は、コンテンツの開始に対して、例えば、特定のオフセットを用いてコンテンツ送出を開始するようにリモートサーバに命令する。

一実施形態では、コンテンツ検索はＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）に基づいており、クライアントは、コンテンツ検索セッションを呼び出すのにＧＥＴメソッドを使用する。ＨＴＴＰプロトコルは、このようなオフセット機能をサポートする。ＨＴＴＰにはＲＡＮＧＥコマンドを使用することができ、このコマンドは、すでに受け取られているコンテンツのオクテット量と一緒に、ＨＴＴＰ要求ヘッダの中に挿入されなければならない。

図１は、一実施形態によるホストデバイスを含む通信システムの高レベルブロック図を示す。詳細には、図１は、マルチホームホストまたはモバイルホスト１１０が複数のネットワーク１２０と通信して、ネットワーク１２０を介してそれぞれのコンテンツ供給源１４０のコンテンツを検索することができるシステム１００を示す。

本明細書で論じられる様々な実施形態によれば、ホスト１１０は、第１のネットワークと関連付けられたサーバのコンテンツを検索するセッションから、第２のネットワークと関連付けられたサーバのコンテンツを検索するセッションへと、コンテンツ送出を再起動することなく、またはそれ以外にホストコンテンツ検索アプリケーションを中断することなく、移行することができる。

ホスト１１０は、例えば、第１のネットワーク１２０−１とインターフェースするための第１のインターフェース１１２−１、第２のネットワーク１２０−２とインターフェースするための第２のインターフェース１１２−２、コントローラ１１４、クライアント１１６、およびインターフェースマネージャ１１８を備える。

クライアント１１６は、コンテンツ検索アプリケーション（ＣＲＡ）を含むとして示されており、このアプリケーションを使用して、コンテンツサーバなどのリモートエンティティとのセッションを確立するのに必要なすべての対話および信号伝達を行い、コンテンツサーバからの所望のコンテンツの送出を要求し、送出されたコンテンツを受け取り、受け取られたコンテンツを、ホスト１１０と関連付けられた表示回路（図示せず）および／または記憶デバイス（図示せず）に向けて伝える。

コントローラ１１４は、クライアント１１６とインターフェース１１２の間に必然的に位置する。様々な実施形態では、コントローラ１１４は、制御信号の一部または全部、および／またはクライアント１１６とインターフェース１１２の間で伝えられるデータトラフィックの一部または全部を監視する。コントローラ１１４は、インターフェースマネージャ１１８に応答して、クライアント１１６によるインターフェース１１２の使用を適応させる。一般に、コントローラ１１４の動作はクライアント１１６には見えない。様々な実施形態では、インターフェースマネージャ１１８は、コントローラ１１４により制御信号および／またはデータトラフィックが、第１のインターフェース１１２−１だけを介して、第２のインターフェース１１２−２だけを介して、または第１および第２のインターフェース１１２の何らかの組合せだけを介して流れるようにする。

インターフェースマネージャ１１８は、クライアント１１６とインターフェース１１２の間の制御信号および／またはデータトラフィックをサポートするために、複数のインターフェース１１２のどれを使用するかをコントローラ１１４に選択させる。インターフェースマネージャ１１８は、インターフェース制御（ＩＣ）信号経路を介してコントローラ１１４と通信するとして示されている。

いくつかの実施形態では、使用可能なインターフェース１１２のうちのどれが、クライアント１１６での使用のためにコントローラ１１４によって選択されるべきかをインターフェースマネージャが表わす点で、ＩＣ信号経路は単方向性である。

いくつかの実施形態では、インターフェースマネージャ１１８とコントローラ１１４が互いに通信して、クライアント要求、インターフェース要求、インターフェース１１２の状態、通信ネットワーク１２０の状態などを理解するのに有用な情報を送信するという点で、ＩＣ信号経路は双方向性である。同様に、インターフェースマネージャ１１８は、条件付きトリガ状態を伝達することができ、この状態が生じたとコントローラ１１４によって検知された場合には、コントローラ１１４が新インターフェース１１２を選択することになり、または他の何らかの機能を実行することになる。

様々な実施形態では、ある特定のインターフェース１１２の選択と関連付けられた条件が、コントローラ１１４を介してインターフェースマネージャ１１８に伝達される。様々な実施形態では、このような条件は、ネットワーク管理システム（ＮＭＳ）、サービスプロバイダ、あるいは１つまたは複数のインターフェース１１２を介してホストと動作可能に接続された他の何らかのエンティティから与えられる。例えば、ネットワーク１２０のそれぞれに関連する輻輳情報は、それぞれのインターフェース１１２を介してコントローラ１１４および／またはインターフェースマネージャ１１８に伝達することができる。

他の条件には、ネットワークプロバイダに関連した選好、特定のモバイルネットワークプロバイダに関連した「フリー」ホットスポットを識別するホットスポット識別情報などが含まれる。例えば、３Ｇと８０２．１１の両方にそれぞれのインターフェース１１２によってアクセスできるホスト１１０の場合では、いくつかのホットスポットをサービスレベル契約、プロバイダ間契約などに応じて、無料または低いコストで使用することができる。

したがって、様々な実施形態では、インターフェースマネージャ１１８によってコントローラ１１４に伝えられる制御信号は、第１のインターフェースを介して受け取られた輻輳レベルインジケータ、第２のインターフェースを介して受け取られた輻輳レベルインジケータ、選好サービスプロバイダが第２のインターフェースと関連付けられていることの確定、選好サーバが第２のインターフェースと関連付けられていることの確定、低減コストが第２のインターフェースと関連付けられていることの確定、性能向上が第２のインターフェースと関連付けられていることの確定、選好ネットワークが第２のインターフェースと関連付けられていることの確定、などのうちの１つ以上と関連付けることができる。

様々な実施形態では、コンテンツ検索アプリケーションＣＲＡによって開始および／または管理されるコンテンツ検索セッションのコンテキスト内のコンテンツを検索するなどのために、インターフェース選択条件をコントローラ１１４とインターフェースマネージャ１１８の一方または両方で使用して、複数のインターフェース１１２のどれをクライアント１１６で使用するかに関しての決定を行うことができる。

本明細書には２つのインターフェース１１２が図示されているが、３つ以上のインターフェース１１２もまた、様々な実施形態のコンテキスト内で利用できることを理解されたい。インターフェース１１２のそれぞれにより、対応するネットワーク１２０との通信が可能になる。

それぞれのネットワーク１２０は、ホスト１１０とコンテンツソース１４０の間の通信を可能にするのに十分な１つまたは複数のアクセスネットワーク、コアネットワークなどを含む。それぞれのネットワーク１２０は、それぞれのドメイン名サーバ（ＤＮＳ）１３０と関連付けられているとして図示されているが、追加ドメイン名サーバをどのネットワーク１２０のコンテキスト内でも使用することができる。

それぞれのコンテンツソース１４０は、それぞれのネットワーク１２０と通信するためのインターフェース１４２と、クライアント１１６とのセッションを確立し、クライアント１１６と対話し、およびクライアント１１６にコンテンツを供給するように一般になされたコンテンツサーバ１４４とを含むとして図示されている。コンテンツサーバ１４０は、セッションベースのコンテンツ送出およびまたはストリーミングができる、任意のタイプのコンテンツサーバまたはコンテンツ送出システムを含むことができる。

一実施形態では、ホストは、第１のインターフェース１１２−１を介して無線モバイルネットワークと通信するように、また第２のインターフェース１１２−２によって無線「ホットスポット」と通信するように構成されたスマートフォンまたは他のモバイルデバイスを含む。詳細には、この実施形態では、第１のインターフェース１１２−１は、第１の通信ネットワーク１２０−１（例えば、３Ｇ、４Ｇ、ＬＴＥまたは他の無線モバイル／アクセスネットワーク）と通信するのに必要なハードウェアおよびソフトウェアの構成要素を含むように構成することができ、一方、第２のインターフェース１１２−２は、第２の通信ネットワーク１２０−２（例えば、８０２．１１ｘ、ＷｉＭＡＸ、無線ギガビットもしくは他の類似のものなどの無線「ホットスポット」タイプのネットワーク、または固定無線ネットワーク）と通信するのに必要なハードウェアおよびソフトウェアの構成要素を含むように構成することができる。

分かりやすいように省略されているが、ホスト１１０、ネットワーク１２０、ドメイン名サーバ１３０およびコンテンツソース１４０と関連付けられた様々な機能には一般に、ホスト１１０のコンテキスト内のハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実施されるコンピュータベースの機能が含まれることを理解されたい。すなわち、ホスト１１０は、１つまたは複数のプロセッサ、メモリ要素、入出力回路などの、図１では分かりやすさを向上させるために省略されている一般的な計算機要素を含む。このような要素を用意する計算機デバイスの一実施形態について、以下で図６に関してより詳細に説明する。

本明細書で論じられる様々な実施形態では、モバイル／マルチホームホストが、コンテンツ検索中にそのインターフェースだけでなく、クライアントセッションによって使用されるコンテンツサーバも変更することが、クライアントでのコンテンツ検索セッションを中断せずに可能になる。

様々な実施形態では、コントローラ１１４は、クライアントをサポートするソフトウェアの下のソフトウェア層内で実施されるソフトウェア機能を備える。詳細には、コントローラ機能は、ＴＣＰ／ＩＰスタック内またはセッション層上のクライアントアプリケーションの下に存在する。コントローラ機能は、そのそれぞれの層を通るトラフィックの少なくとも一部を監視しており、アプリケーション層プロトコルによって使用されるコマンドの少なくとも一部を認識または理解することができる。

一般的にいえば、コントローラ１１４は４つの主要なタスクを実行する：（１）クライアント１１６とインターフェース１１２の間のトラフィックを監視して、要求されたコンテンツの識別表示と、クライアントが受け取った要求コンテンツの量とを導出する、（２）要求コンテンツを含む新たに選択されたインターフェースについてサーバを識別する、（３）識別されたサーバへの転送接続を開始する、および（４）クライアントがまだ受け取っていないコンテンツの部分をクライアントに転送する。

詳細には、クライアントホストのインターフェースが変更される場合、コントローラは、新インターフェースでこのコンテンツのために使用されるべき最も適切なサーバを決定する。旧インターフェースを介してコンテンツを提供するサーバは「旧」サーバと表示され、一方、新インターフェースを介してコンテンツを供給するために選択されたサーバは「新」サーバと表示される。新サーバと旧サーバは、コンテンツプロバイダ機器の構成に応じて互いに同じものでありうることに留意されたい。

コントローラ機能により、新サーバへのトランスポート接続を開始し、例えば、元のコンテンツ検索要求のコピーを新サーバへ送る。

コントローラ機能によりまた、例えば、アプリケーション層プロトコルから与えられたコマンドが新サーバへ送られ、このコマンドは新サーバに対し、前のインターフェースを介してすでに受け取られたデータの量に基づく指定のオフセットに応じてコンテンツ送出を開始するように指示する。

次に、コントローラは、新サーバから送出されたデータをクライアントアプリケーションに転送し、旧サーバへの接続を終了させる。

これらのステップは一般に、クライアントアプリケーションには透過的であり、それによって、第１のネットワークインターフェースから第２のネットワークインターフェースへの検索コンテンツストリームのシームレス移行が容易になる。

オフセットについては、（１）受け取られたコンテンツの量を十分に特徴付ける、（２）アプリケーション層プロトコルに準拠し、したがってサーバによって理解される、および（３）受け取られたコンテンツストリーム（１つまたは複数）を監視することによって導出することができる、といういずれの表現が用いられてもよい。

オフセットは、受け取られたコンテンツのオクテットの量を表わす数値を含むことができる。オフセットは、受け取られたデータオブジェクトに対する識別子のリストを含むことができ、このデータオブジェクトは、標準化フォーマット（例えば、ＸＭＬ、ｈｔｍｌなど）を介して提供される。オフセットは、受け取られたビデオストリームまたはその一部分と関連付けられた時間間隔、フレームカウント、プログラムクロック基準（ＰＣＲ）など、他のメトリックを参照することもできる。

図２、図３は、図１の通信システムに使用するのに適したホストデバイスの高レベルブロック図を示す。具体的には、図２、図３は、図１に関して上述したホスト１１０と同様に動作するホスト１１０を示す。

図２に関して、コントローラ１１４の機能が、クライアント１１６によって呼び出される、またはアクセスされる関数のライブラリ内で実施されるように、セッション層実施態様がライブラリ関数を使用して提供される。さらに、カーネル空間が、第１のインターフェース１１２−１と関連付けられた第１のＴＣＰ／ＩＰスタック１１３−１と、コントローラ１１４によって呼び出されるまたはアクセスされる第２のＴＣＰ／ＩＰスタック１１３−２とを含む。

有利なことに、この実施態様は、ライブラリ関数をアップグレードしてコントローラ１１４およびインターフェースマネージャ１１８の機能を含むことによって、既存のマルチホームホストまたはモバイルホスト上の既存のアプリケーションをアップグレードして、本明細書に記載の様々な実施形態の機能をサポートすることができる機構を提供する。残念ながら、カーネル空間関数に直接アクセスすることによってライブラリ関数をバイパスするこれらのアプリケーションでは、様々な実施形態と関連付けられたコントローラ機能の一部を実施することが可能ではないことがある。

図３に関して、コントローラ１１４およびインターフェースマネージャ１１８をカーネル空間に含め、さらにコントローラ１１４をＴＣＰ／ＩＰスタック１１３と一体化することによって、１つのトランスポート層実施態様が提供される。有利なことに、この実施態様は、既存のマルチホームホストまたはモバイルホスト上の既存のアプリケーションが、ライブラリ関数と関連付けられたライブラリ、アプリケーションプログラミングインターフェース（ＡＰＩ）などを使用しないアプリケーションであったとしても、ライブラリ関数などのユーザ空間関数ほどに簡単にカーネル空間関数をアプリケーションによってバイパスできないので、本明細書に記載の様々な実施形態に応じてなお動作することができる機構を提供する。

図４は、一実施形態による方法を示すプロトコル図を示す。詳細には、図４は方法４００を示し、ステップ４０１、４０１から連続して４１１（を任意選択で超える）までと示された複数のステップのそれぞれで、情報が、上記で図１に関して説明された様々な機能要素間で搬送されるものとして示されて、それによって様々な実施形態が例示されている。

ステップ４０１で、クライアント１１６は、ドメイン名サーバ（ＤＮＳ）要求を、第１のインターフェース１１２−１（ここではＩＦ１とも示される）を介して、第１のネットワーク１２０−１と関連付けられたＤＮＳ １３０−１まで送出して、そこから第１のコンテンツサーバ１４０−１のＩＰアドレスを検索する。このステップ中、コントローラ１１４はＤＮＳ要求をインターセプトし、ＤＮＳ要求と関連付けられた汎用リソース識別子（ＵＲＩ）をキャッシュする。このプロセスは、ＨＴＴＰ環境のコンテキスト内では必要のないことが当業者には理解されよう。

ステップ４０２で、ＤＮＳサーバ１３０−１は、ＤＮＳ応答をクライアント１１６に送り返す。このステップ中、コントローラ１１４は、ＤＮＳサーバ１３０−１からの応答をインターセプトし、返されたＩＰアドレスを要求のＵＲＩと一緒にキャッシュする。このプロセスは、ＨＴＴＰ環境のコンテキスト内では必要のないことが当業者には理解されよう。

ステップ４０３で、クライアント１１６は、トランスポートセッションを、第１のコンテンツサーバ１４０−１のＩＰアドレスを使用して、第１のインターフェース１１２−１を介して開始し、コンテンツ検索要求を送出する。コントローラ１１４は、セットアップ要求をインターセプトし、接続のリモートＩＰアドレスに基づいてコンテンツのＵＲＩを識別し（ＨＴＴＰでは不要）、クライアントから送出されたコンテンツ要求メッセージをキャッシュし、このトランスポート接続の監視を開始する。

ステップ４０４で、第１のコンテンツサーバ１４０−１は、クライアント１１６に、応答ヘッダと、場合によりコンテンツデータの最初の部分とを含む応答パケットを送出する。コントローラは、このパケットをインターセプトし、クライアントに転送されるコンテンツデータの追跡を応答可能に開始する。

ステップ４０５で、第１のコンテンツサーバ１４０−１はクライアントに、パケットのストリームを要求コンテンツデータの追加部分も含めて送り続ける。コントローラは、これらのパケットをインターセプトし、クライアントに転送されるコンテンツ部分の追跡を継続する。

ステップ４０６で、インターフェースマネージャ１１８は、トリガをコントローラ１１４（例えばＩＣ信号経路）に送出する。トリガは、コントローラが第１のインターフェース１１２−１から第２のフェーズ１１２−２へ切り替えるべきことを示す。このトリガに応答して、コントローラ１１４は、キャッシュされたＤＮＳ要求のコピー（または、最初のコンテンツ要求と関連付けられた他のＵＲＩのインジケータ）を第２のネットワーク１２０−２へ、第２のインターフェース１１２−２を介して送出する。別法として、コントローラ１１６は、それがクライアントの以前のコンテンツ要求メッセージから検索したＵＲＩを含む、コントローラ自体のＤＮＳ要求を生成する。他の修正形態もまた、本発明者によって企図されている。

ステップ４０７で、第２のＤＮＳサーバ１３０−２は、ステップ４０６で受け取られたＤＮＳ要求に、所望のコンテンツを供給できる第２のネットワーク１２０−２内のサーバに１組のＩＰアドレスを与えることによって応答する。コントローラ１１４は、一実施形態では、この組からの、図４に第２のコンテンツサーバ１４０−２を指すとして示されているＩＰアドレスを選択する。

ステップ４０８で、コントローラ１１４は、第１のインターフェース１１２−１と第１のコンテンツサーバ１４０−１の間のトランスポート接続を、例えばＴＣＰ ＲＳＴによって終了させる。さらに、コントローラ１１４は、最初のトランスポート接続によってクライアントが受け取ったコンテンツの総量を決定する。

ステップ４０９で、コントローラ１１４は、第２のコンテンツサーバ１４０−２と関連付けられたＩＰアドレスを使用して、第２のインターフェース１１２−２を介した新しいトランスポート接続を確立する。加えて、コントローラ１１４は、この新しいトランスポート接続を介して、コンテンツ検索要求のコピーを、第１のインターフェース１１２−１を介して旧のトランスポート接続によってすでに検索されたコンテンツの量を明らかにするオフセットと共に、コンテンツ検索要求の中へ送出する。

ステップ４１０で、第２のコンテンツサーバ１４０−２はコントローラ１１４に、応答ヘッダと、場合により、オフセットから始まるコンテンツデータの最初の部分とを含む応答パケットを送出する。コントローラ１１４は、この応答ヘッダを除去し、受け取られたオフセット後データ部分があればクライアント１１６へ転送する。コントローラ１１４はまた、クライアントに転送されるコンテンツデータの追跡を継続する。クライアントは、コントローラ１１４の動作、特にコントローラ１１４によって行われたコンテンツ要求に気づいていないので、対応する応答ヘッダは、この時点でクライアントによって期待されていなく、したがってコントローラ１１４によってはぎ取られることに留意されたい。

ステップ４１１で、第２のコンテンツサーバ１４０−２は、要求されたコンテンツデータの追加部分を含むパケットのストリームをクライアント１１６へ送り続ける。コントローラ１１４は、これらのパケットをインターセプトし、クライアントへ転送されるコンテンツ部分の追跡を継続する。

図５は、一実施形態による方法を示す流れ図である。図５に関してここで論じられる方法では一般に、ＨＴＴＰがアプリケーション層プロトコルとして使用されること、およびＨＴＴＰ ＧＥＴメソッドがコンテンツを要求するために使用されることが企図されている。どこか別のところで論じるように、様々な他のプロトコルを、様々な他のソフトウェア層上のプロトコルと共に、実施することができる。

ステップ５１０およびボックス５１１を参照すると、コントローラは、それがサポートするアプリケーション層プロトコルに関係する出力メソッド呼出しを監視する。ＴＣＰまたはＭＰＴＣＰを使用するトランスポート層上のコントローラの実施態様では、コントローラは、クライアントによって開始されたＳＹＮ／ＡＣＫハンドシェイクの後に、第１の出力データパケットを解析する。ＳＣＴＰでは、ＩＮＩＴハンドシェイク後の第１の出力データパケットが解析されなければならない。セッション層実施態様では、ＣＯＮＮＥＣＴ（）コール後の第１のデータパケットが解析されなければならない。

ステップ５１５およびボックス５１６を参照すると、コントローラは、出力メソッド呼出しに対応するＵＲＩまたはＵＲＬを識別する。このＵＲＩまたはＵＲＬは、コンテンツ検索に使用されるサーバのＩＰアドレスと一緒にキャッシュされる。一実施形態では、これは、ホストによって開始されるＤＮＳ要求／応答ハンドシェイクを監視するコントローラによって、またＤＮＳ要求のＵＲＩ／ＵＲＬをＤＮＳ応答に含まれるＩＰアドレスと一緒にキャッシュすることによって達成される。これらのキャッシュされたデータ、および出力メソッド呼出しの宛先アドレスに基づいて、メソッド呼出しの対応するＵＲＩ／ＵＲＬを見つけることができる。アプリケーション層プロトコルとして使用されるＨＴＴＰの場合では、ＵＲＩ／ＵＲＬは、ＧＥＴコールに含まれるＨＴＴＰヘッダから導出することができる。インターフェース用に構成されるＨＴＴＰプロキシの場合では、プロキシはコンテンツサーバを代理することができる。

ステップ５２０およびボックス５２１を参照すると、コントローラは、モビリティ／マルチホーミングサポートがアプリケーションクライアントに必要とされない、または何らかの理由で許容されない場合に、コントローラは、任意選択で監視を中止することができる。詳細には、コンテンツ検索セッションが上記のステップによって識別されたとき、コントローラはさらに、このアプリケーション層セッションがモビリティ／マルチホーミングのサポートを要求するかどうかを判断することができる。この判断には、ホストによってサポートされるインターフェースの数およびタイプなどの外部基準、ならびに他の基準を含むことができる。後続のコントローラ機能のコンテキスト内で、コンテンツ検索セッションがこのようなモビリティ／マルチホーミングサポートを要求することが想定される。

ステップ５２５およびボックス５２６を参照すると、コントローラは、セッション接続識別子またはトランスポート接続識別子をキャッシュする。これらの識別子は、クライアントアプリケーション用に定められ、およびコントローラによって開始された今後の接続部に到着するコンテンツデータ部分を送出するために、コントローラによって使用される。セッション層に存在するコントローラ機能の場合、このような識別子は、アプリケーションによって使用されるソケット記述子およびプロセスｉｄから構成されうる。トランスポート層に存在するコントローラ機能の場合には、このような識別子は、カーネル内の対応するプロトコル制御ブロックに対するポインタでありうる。

ステップ５３０およびボックス５３１を参照すると、コントローラは、クライアントアプリケーションからコンテンツ検索サーバに送られたメソッド呼出しコールに含まれる情報をキャッシュする。ＨＴＴＰがアプリケーション層プロトコルである場合、この情報は、ＨＴＴＰ ＧＥＴコールのＨＴＴＰ要求ヘッダを表わす。

ステップ５３５およびボックス５３６を参照すると、コントローラは、クライアントのメソッド呼出しに応答してコンテンツサーバから送られたすべてのデータを監視および解析する。コントローラは、受け取られたコンテンツの量を決定する。このプロセスでは、コントローラは、アプリケーション層プロトコルによって与えられたＨＴＴＰ応答ヘッダなどのシグナリング情報を無視しなければならないことがある。

一実施形態では、コンテンツは、オクテットまたはビットの単位で指定される。別の実施形態では、コンテンツは、オブジェクト識別子のリストによって表わされる。別の実施形態では、コンテンツは、ビデオストリームおよび／またはオーディオストリームなどに対して受け取られたいくつかの軸ユニットまたは軸フレームに関して指定される。別の実施形態では、コンテンツは、受け取られたビデオストリームの小部分を再生するのに要する時間間隔（コードタイムスタンプ（ＤＴＳ）、プレゼンテーションタイムスタンプ（ＰＴＳ）、プログラムクロック基準（ＰＣＲ）などを使用して計算される）に関して指定される。

ステップ５４０を参照すると、コントローラは、コンテンツ検索に使用されるインターフェースが変更されるべきことを示すインターフェースマネージャからの制御信号を待つ。制御信号が受け取られる時間までコントローラは、第１のインターフェース１１２−１を介して第１のコンテンツサーバ１４０−１から受け取られたコンテンツ部分の監視および解析を継続する。

ステップ５４５およびボックス５４６を参照すると、追加のインターフェース変更制御信号を受け取った後、コントローラは、新インターフェースでのコンテンツ送出のために適切なサーバを識別する。この目的のためにコントローラは、クライアントアプリケーションによって最初のメソッド呼出しにマッピングされたＵＲＩを含む新インターフェースでのＤＮＳ要求を開始することができる。ＤＮＳ応答が旧コンテンツサーバのＩＰアドレスを含まない場合には、新コンテンツサーバを使用することが賢明でありうる。ＨＴＴＰがアプリケーション層プロトコルとして使用され、ＨＴＴＰプロキシが旧インターフェースで使用されていたならば、新インターフェース用に新コンテンツサーバを使用することが賢明でありうる。新インターフェースがＨＴＴＰプロキシと共に構成される場合、ＨＴＴＰプロキシ自体は、コンテンツサーバの機能をクライアントに持っていくことができる。以下では、旧インターフェースおよび新インターフェースそれぞれに対して「旧サーバ」および「新サーバ」と呼ぶ。旧サーバと新サーバは、同じであることも、異なることも、および／またはプロキシサーバを指すこともある。

ステップ５５０およびボックス５５１を参照すると、コントローラは、旧サーバへの旧トランスポート接続を終了させる。ホストが一度に１つのインターフェースしかサポートできない場合には、このステップは、新インターフェースでのコンテンツ送出のために適切なサーバを特定するステップの前に実行される。コントローラがトランスポート層で実施され、ＴＣＰがトランスポートプロトコルとして使用される場合には、コントローラは、ＲＳＴコマンドを送出してその接続を終了させることができる。この目的のために、コントローラは、トランスポート接続識別子を知る必要がある。コントローラがセッション層で実施される場合には、コントローラは、ＣＬＯＳＥ（ ）コールによって接続を閉じることができる。この目的のために、コントローラは、ソケット記述子と、最終的にプロセス識別子とを知る必要がある。

ステップ５５５を参照すると、コントローラは、新サーバによって新インターフェースを介して新トランスポート接続を確立する。コントローラ機能がトランスポート層に存在する実施形態では、同じプロトコル制御ブロックを有利に使用することができる。しかし、これは、新インターフェースを介する新サーバとの接続設定シグナリングハンドシェイクを経なければならない。これにより、新コンテンツサーバから送出されるさらなるコンテンツデータを同じクライアントアプリケーションに転送できることが保証される。コントローラがセッション層に存在する実施形態では、新コンテンツサーバから受け取られたコンテンツデータ部分は、同じアプリケーション層処理で同じソケット記述子へ転送される。

ステップ５６０およびボックス５６１を参照すると、コントローラは、キャッシュされたメソッド呼出しを新トランスポート接続で新サーバへ送る。コントローラは、すでに受け取られた量のコンテンツデータの送出をコンテンツサーバが省略できるようにするオフセットを含む命令を挿入する。この命令は、アプリケーション層プロトコルに特有のものである。ＨＴＴＰではＲＡＮＧＥコマンドを使用することができ、このＲＡＮＧＥコマンドは、すでに受け取られた量のコンテンツのオクテットと一緒にＨＴＴＰ要求ヘッダの中に挿入されなければならない。

ステップ５６５を参照すると、コントローラは、新接続で受け取られたすべてのコンテンツをクライアントアプリケーションへ転送する。この目的のために、コントローラは、それがこのコンテンツ検索セッションのためにキャッシュしたセッション接続識別子またはトランスポート接続識別子を使用する。新接続で、通過コンテンツデータ部分のカウントは、さらなる接続マイグレーションイベントが実行されうるように継続する。様々な実施形態では、ステップ５６５での動作は、ステップ５３５およびボックス５３６に関して上で論じた動作と類似している。

図６は、本明細書に記載の機能を実行するのに適したコンピュータの高レベルブロック図を示す。

図６に示されるように、コンピュータ６００は、プロセッサ要素６０２（例えば、中央処理ユニット（ＣＰＵ）および／または他の適切なプロセッサ（１つまたは複数））と、メモリ６０４（例えば、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など）と、協働モジュール／プロセス６０５と、様々な入力／出力デバイス６０６（例えば、ユーザ入力デバイス（キーボード、キーパッド、マウスなど）、ユーザ出力デバイス（ディスプレイ、スピーカなど）、入力ポート、出力ポート、受信器、送信器、および記憶デバイス（例えば、テープドライブ、フロッピー（登録商標）ドライブ、ハードディスクドライブ、コンパクトディスクドライブなど））とを含む。

本明細書で図示および説明した機能は、ソフトウェアおよび／またはハードウェアの形で、例えば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または他の任意のハードウェア等価物を使用して実施できることを理解されたい。一実施形態では、協働プロセス６０５は、メモリ６０４にロードし、プロセッサ６０２によって実行して、本明細書で論じた機能を実施することができる。すなわち、協働プロセス６０５は（関連データ構造体を含み）、例えばＲＡＭメモリ、磁気もしくは光ドライブ、または磁気もしくは光ディスケットなどのコンピュータ可読記憶媒体に記憶することができる。

図６に示されたコンピュータ６００は、本明細書に記載の機能要素、および／または本明細書に記載の機能要素の一部分を実施するのに適した一般的アーキテクチャおよび機能性を提供することを理解されたい。例えば、コンピュータ６００は、ホスト１１０、コンテンツサーバ１４０、ドメイン名サーバ１３０、および／またはこれらの一部分などのうちの１つ以上を実施するのに適した一般的アーキテクチャおよび機能性を提供する。

ソフトウェア方法として本明細書で論じられたステップのいくつかは、例えば、プロセッサと協働して様々な方法ステップを実行する回路としてハードウェアの中で実施できることが企図されている。本明細書で論じられた機能／要素の一部分は、コンピュータプログラム製品として実施することができ、コンピュータ命令がコンピュータで処理されると、本明細書に記載の方法および／または技法が呼び出される、またはそれとは別の方法で提供されるようにコンピュータの動作が適応する。本発明の方法を呼び出すための命令は、固定または取外し可能な媒体内に記憶し、同報通信のデータストリームまたは他の信号伝搬媒体によって送信し、および／または命令に従って動作する計算機デバイス中のメモリ内に記憶することができる。

様々な実施形態で重要な利益が得られる。具体的には、様々な実施形態に基づくシステム、装置および方法は、いわゆるスマートフォンの機能セットの中に直接組み込むことができる。このような組込みは、電話製造者（例えば、アップル、モトローラ、ＨＴＣ、サムスン、Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ、ＬＧ、ノキアなど）またはオペレーティングシステムベンダー（例えば、アップル、グーグル、マイクロソフトなど）から提供される、固有のハードウェア／ソフトウェア機能セットまたは移動電話プラットフォームの中で行われてよい。様々な実施形態に応じた組込み機能により、本明細書に記載の様々な機能を実行するための効率的な機構が実現され、様々なハードウェアおよびソフトウェアのベンダに製品差別化が提供される。

本明細書で論じた様々な実施形態は、移動電話またはモバイルＯＳベンダによって容易に適合化されるが、その理由は、（１）マルチホーミングがスマートフォンでのユビキタス機能になっている、（２）ネットワークが別々のサービスプロバイダによって運営される、多くの異種ネットワークシナリオ（３Ｇ／４Ｇに重なるＷｉ−Ｆｉ）がある、（３）専用のネットワーク側機器が必要とされない、および（４）サーバでのアップグレードが必要とされない、からである。したがって、本発明は、いかなるサードパーティの投資にも依存することなく電話またはモバイルＯＳに価値を付加する。

有利なことに、様々な実施形態により、例えばＨＴＴＰベースのコンテンツ検索アプリケーションのために、ネットワークおよびアクセスプロバイダ全体にわたる移動性またはインターフェースマイグレーションが可能になる。これらのアプリケーションは、モバイルインターネットトラフィックの大部分を占める。

様々な実施形態では、レガシーアプリケーションなどがこれらの機能に影響を及ぼすことができるように、これらの機能がアプリケーションに透過的な仕方で得られる。様々な実施形態ではまた、モビリティアンカーなどの専用のネットワーク側機器が不必要になるように、これらの機能がアクセスプロバイダに透過的な方法で得られる。

さらに、リモートコンテンツサーバは、アプリケーション層プロトコルがコンテンツ要求メッセージの中にオフセット記述を含まない限り、いかなるプロトコルアップグレードも必要としない。この条件は、ＨＴＴＰおよび類似のプロトコルに適合する。

さらに、コンテンツサーバはまた、モビリティ／インターフェースマイグレーション中に変更することができ、これにより、選択されたネットワークごとに最適なサーバを使用することが可能になる。この機能によりまた、一部のネットワーク、例えば、企業ネットワーク内に存在するプロキシの存在下での動作が可能になる。それゆえに、様々な実施形態において、企業ネットワークとモバイルネットワークオペレータのネットワークとの間のセッションマイグレーションのためのサポートが提供される。

本発明の教示を組み込んだ様々な実施形態が本明細書で詳細に図示され説明されたが、当業者なら、これらの教示をやはり組み込んだ他の多くの多様な実施形態を容易に考案することができる。

Claims (10)

1. ホストにおいてコンテンツ検索アプリケーションと関連付けられたコンテンツ検索セッションを第１のインターフェースを介して第１のサーバから、第２のインターフェースを介して第２のサーバへマイグレーションさせるための方法であって、
   第２のインターフェースを使用して第２のサーバとのトランスポート接続を確立するステップと、
   検索されるべきコンテンツと関連付けられた識別子を含み、および前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の表示を含むコンテンツ要求メッセージを、第２のインターフェースを介して第２のサーバに向けて送信するステップと、
   前記第２のインターフェースを介して受け取られたコンテンツ担持データストリームを解析して、前記コンテンツ検索アプリケーションによって受け取られるさらなるコンテンツ部分を識別するステップと、
   前記コンテンツ検索アプリケーションに向けて、識別された、前記コンテンツ検索アプリケーションが受け取らなかったコンテンツ部分を転送するステップと
   を含む、方法。
2. 前記第１のインターフェースを介して受け取られるコンテンツの送出を抑制するステップをさらに含む、請求項１に記載の方法。
3. コンテンツ検索アプリケーションから送られたコンテンツ要求メッセージをキャッシュするステップをさらに含み、第２のインターフェースを介して第２のサーバに向けて送信される前記コンテンツ要求メッセージ内の前記コンテンツ識別子が、キャッシュされたコンテンツ要求メッセージから導出される、請求項１に記載の方法。
4. コンテンツ検索アプリケーションに送出されるコンテンツ部分の表現をキャッシュするステップをさらに含み、前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の前記表示が、キャッシュされたコンテンツ部分表現から導出される、請求項３に記載の方法。
5. 前記第２のサーバとの前記トランスポート接続が、前記第１のインターフェースを介して受け取られる輻輳レベルインジケータのうちの１つ以上と関連付けられた制御信号と、前記第２のインターフェースを介して受け取られる輻輳レベルインジケータと、選好されたサービスプロバイダが前記第２のインターフェースと関連付けられているという判断と、選好されたサーバが前記第２のインターフェースと関連付けられているという判断と、低減されたコストが前記第２のインターフェースと関連付けられているという判断と、性能向上が前記第２のインターフェースと関連付けられているという判断と、選好されたネットワークが前記第２のインターフェースと関連付けられているという判断とに応じて確立される、請求項１に記載の方法。
6. 前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の前記表示がオクテットカウントに基づき、
   前記コンテンツ要求メッセージがＨＴＴＰ ｇｅｔメッセージを含み、
   前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の前記表示が、前記ｇｅｔメッセージのＲＡＮＧＥエントリとして含まれるオクテットカウントに基づく、請求項１に記載の方法。
7. ＤＮＳ位置サービスが、前記第２のサーバを識別するために使用され、前記方法がさらに、前記第２のサーバと関連付けられたホスト汎用リソース識別子（ＵＲＩ）または汎用リソースロケータ（ＵＲＬ）を含むＤＮＳ要求を前記ＤＮＳ位置サービスへ送信するステップを含む、請求項１に記載の方法。
8. ＴＣＰがトランスポート機構として使用され、第１のサーバによるさらなるデータ送出が、前記第１のインターフェースを介してＴＣＰ ＲＳＴメッセージを送信することによって抑制される、請求項１に記載の方法。
9. ホストにおいてコンテンツ検索アプリケーションと関連付けられたコンテンツ検索セッションを第１のインターフェースを介して第１のサーバから、第２のインターフェースを介して第２のサーバへマイグレーションさせるための装置であって、
   第２のインターフェースを使用して第２のサーバへのトランスポート接続を確立し、
   検索されるべきコンテンツと関連付けられた識別子と、前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の表示とを含む前記コンテンツ要求メッセージを、第２のインターフェースを介して第２のサーバに向けて送信し、
   前記第２のインターフェースを介して受け取られたコンテンツ担持データストリームを解析して、前記コンテンツ検索アプリケーションによって受け取られるさらなるコンテンツ部分を識別し、および
   前記コンテンツ検索アプリケーションに向けて、識別された、前記コンテンツ検索アプリケーションが受け取らなかったコンテンツ部分を転送するように
   構成されたプロセッサを備える、装置。
10. ホストにおいてコンテンツ検索アプリケーションと関連付けられたコンテンツ検索セッションを第１のインターフェースを介して第１のサーバから、第２のインターフェースを介して第２のサーバへマイグレーションさせるための方法であって、
    第２のインターフェースを使用して第２のサーバへのトランスポート接続を確立するステップと、
    検索されるべきコンテンツと関連付けられた識別子を含み、および前記コンテンツ検索アプリケーションによって受け取られるコンテンツ部分の表示を含むコンテンツ要求メッセージを、第２のインターフェースを介して第２のサーバに向けて送信するステップと、
    前記第２のインターフェースを介して受け取られたコンテンツ担持データストリームを解析して、前記コンテンツ検索アプリケーションによって受け取られるさらなるコンテンツ部分を識別するステップと、
    前記コンテンツ検索アプリケーションに向けて、識別された、前記コンテンツ検索アプリケーションが受け取らなかったコンテンツ部分を転送するステップと
    を含む方法を、プロセッサによって実行されたときに実施するソフトウェア命令を含む、コンピュータ可読媒体。

Images