(57)【要約】本発明は、ネットワーク通信に関する。複数の第２のプロトコルをカプセル化する第１のプロトコルを使用して、ネットワークを通じて通信を行う。第１のプロトコルの使用によって、セッションの持続性およびクライアントとホストサービスとの間の信頼できる接続が提供される。本発明の本局面の一実施態様では、第２の接続が、第２のプロトコルのうちの１つを使用して、第１のプロトコルサービスとホストサービスとの間に確立される。第１のプロトコルサービスとホストサービスとの間の通信は、第２のプロトコルのうちの１つを介して行われる。第１のプロトコルはＴＣＰ／ＩＰを通じて通信を行うことができ、第２のプロトコルは、例えば、ＨＴＴＰ、ＲＤＰ、ＩＣＡ、ＦＴＰ、Ｏｓｃａｒ、またはＴｅｌｎｅｔを通じて通信を行うことができる。
2007509521.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク通信の方法であって、
第１のプロトコルを使用してクライアントと第１のプロトコルサービスとの間の第１の接続を確立するステップと、
前記第１のプロトコルにカプセル化された複数の第２のプロトコルを介して前記クライアントと前記第１のプロトコルサービスとの間で通信するステップとを含み、
前記第２のプロトコルのうちの少なくとも１つが複数の仮想チャネルを含む、方法。
【請求項２】
前記第２のプロトコルのうちの１つを使用して前記第１のプロトコルサービスとホストサービスとの間の第２の接続を確立するステップと、
前記第２のプロトコルのうちの１つを介して前記第１のプロトコルサービスと前記ホストサービスとの間で通信するステップとをさらに含む、請求項１に記載の方法。
【請求項３】
前記複数の第２のプロトコルを使用して前記第１のプロトコルサービスと複数のホストサービスとの間の複数の第２の接続を確立するステップであって、前記複数の第２の接続のそれぞれは前記第１のプロトコルサービスと異なるホストサービスとの間に確立され、前記複数の第２の接続のそれぞれは前記複数の第２のプロトコルのうちの１つを使用して確立されるステップと、
前記複数の第２のプロトコルのうちの１つを介した前記複数の第２の接続のそれぞれを通じて前記第１のプロトコルサービスと前記複数のホストサービスとの間で通信するステップとをさらに含む、請求項１に記載の方法。
【請求項４】
前記クライアントと前記第１のプロトコルサービスとの間の前記第１の接続を確立するステップが、中間ノードを介して前記第１の接続を確立するステップを含む、請求項１に記載の方法。
【請求項５】
前記第１のプロトコルが、ＴＣＰ／ＩＰを通じて通信される、請求項１に記載の方法。
【請求項６】
各仮想チャネルが、リモートアクセス機能を可能にする複数のプロトコルパケットを含む、請求項１に記載の方法。
【請求項７】
前記第１のプロトコルのレベルで通信を圧縮するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記第１のプロトコルのレベルで通信を暗号化するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記第１の接続がセキュアであり、
前記第１のプロトコルサービスと第１のホストサービスとの間の第２の接続を確立するステップと、
前記第１の接続および前記第２の接続を介して前記クライアントと前記第１のホストサービスとの間で通信するステップと、
前記第２の接続を中断するステップと、
前記第１の接続を中断せずに前記第１のプロトコルサービスと第２のホストサービスとの間の第３の接続を確立するステップと、
前記第１の接続および前記第３の接続を介して前記クライアントと前記第２のホストサービスとの間で通信するステップとをさらに含む、請求項１に記載の方法。
【請求項１０】
前記第２のプロトコルのうちの１つが、ＨＴＴＰ、ＲＤＰ、１ＣＡ、ＦＴＰ、Ｏｓｃａｒ、およびＴｅｌｎｅｔからなる一連のプロトコルから選択される、請求項１に記載の方法。
【請求項１１】
クライアントにホストサービスへの信頼できる接続を提供する方法であって、
複数の第２のプロトコルをカプセル化する第１のプロトコルを使用して前記クライアントと第１のプロトコルサービスとの間の第１の接続を確立するステップと、
前記複数の第２のプロトコルのうちの１つを使用して前記第１のプロトコルサービスと前記ホストサービスとの間の第２の接続を確立するステップと、
前記クライアントおよび前記第１のプロトコルサービスのうちの少なくとも１つで前記第１の接続を介して直近に送信されたデータパケットのキューを維持するステップとを含み、
前記第１の接続が失敗したときには、
前記第２の接続を維持するステップと、
前記第１の接続を介して直近に送信されたデータパケットのキューの維持を継続するステップと、
前記第１のプロトコルを使用して前記クライアントと前記第１のプロトコルサービスとの間の第３の接続を確立するステップとを含む、方法。
【請求項１２】
前記第３の接続を介して、キューに入れたデータパケットのうちの少なくとも１つを送信するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
ネットワーク通信のためのシステムであって、
クライアントとの第１の接続を受け入れ、第１のプロトコルにカプセル化された複数の第２のプロトコルを介してクライアントと通信するように構成された第１のプロトコルサービスを含み、
前記第２のプロトコルのうちの少なくとも１つが複数の仮想チャネルを含む、システム。
【請求項１４】
前記第１のプロトコルサービスが、ホストサービスとの第２の接続を確立し、前記第２のプロトコルのうちの1つを介して前記ホストサービスと通信するようにさらに構成された、請求項１３に記載のシステム。
【請求項１５】
前記第１のプロトコルサービスが、前記複数の第２のプロトコルを使用して複数のホストサービスとの複数の第２の接続を確立するようにさらに構成され、前記複数の第２の接続のそれぞれは異なるホストサービスと確立され、前記第２の接続のそれぞれが前記複数の第２のプロトコルのうちの１つを使用して確立され、前記第１のプロトコルサービスが、前記複数の第２のプロトコルのうちの１つを介した前記複数の第２の接続のそれぞれを通じて前記複数のホストサービスと通信するようにさらに構成された、請求項１３に記載のシステム。
【請求項１６】
前記クライアントとの前記第１の接続が、中間ノードを経由される、請求項１３に記載の方法。
【請求項１７】
前記第１のプロトコルが、ＴＣＰ／ＩＰを通じて通信される、請求項１３に記載のシステム。
【請求項１８】
各仮想チャネルが、リモートアクセス機能を可能にする複数のプロトコルパケットを含む、請求項１３に記載のシステム。
【請求項１９】
前記第１のプロトコルサービスが、前記第１のプロトコルのレベルで通信を圧縮するようにさらに構成された、請求項１３に記載のシステム。
【請求項２０】
前記第１のプロトコルサービスが、前記第１のプロトコルのレベルで通信を暗号化するようにさらに構成された、請求項１３に記載のシステム。
【請求項２１】
前記第１の接続がセキュアであり、前記第１のプロトコルサービスが、第１のホストサービスとの第２の接続を確立し、前記第２の接続を中断し、前記第１の接続を中断せずに第２のホストサービスとの第３の接続を確立するようにさらに構成された、請求項１３に記載のシステム。
【請求項２２】
前記第２のプロトコルのうちの１つが、ＨＴＴＰ、ＲＤＰ、１ＣＡ、ＦＴＰ、Ｏｓｃａｒ、およびＴｅｌｎｅｔからなる一連のプロトコルから選択される、請求項１３に記載のシステム。
【請求項２３】
クライアントにホストサービスへの信頼できる接続を提供するシステムであって、
前記クライアントとの第１の接続を受け入れ、前記ホストサービスとの第２の接続を確立し、前記第１の接続が失敗したときには、前記第２の接続を維持し、前記クライアントからの第３の接続を受け入れるように構成された第１のプロトコルサービスと、
前記第１のプロトコルサービスとの第２の接続を受け入れ、前記第１の接続が失敗したときには、第２の接続を維持するように構成された前記ホストサービスとを含み、
前記第１の接続および第３の接続は、複数の第２のプロトコルをカプセル化する第１のプロトコルを使用してそれぞれ確立され、前記クライアントおよび前記第１のプロトコルサービスのうちの少なくとも１つは、前記第１の接続の前でも失敗時でも、前記第１の接続を介して直近に送信されたデータパケットのキューを維持するようにさらに構成された、システム。
【請求項２４】
前記クライアントが、前記第３の接続を介して、キューに入れたデータパケットのうちの少なくとも１つを送信するようにさらに構成された、請求項２３に記載のシステム。
【請求項２５】
前記第１のプロトコルサービスが、前記第３の接続を介して、キューに入れたデータパケットのうちの少なくとも１つを送信するようにさらに構成された、請求項２３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にネットワーク通信に関する。より具体的には、本発明は、他のプロトコルをカプセル化することによってセッションの持続性および信頼性を提供する通信プロトコルに関する。
【背景技術】
【０００２】
２台のコンピュータ間の通信、例えば、クライアントとサーバとの間のネットワークを通じた通信は、様々な周知の通信プロトコルを使用して行うことができる。しかし、ネットワーク接続は切断されることが多い。例えば、クライアントとサーバとの間の無線接続が不安定であることが多い。その他、ネットワーク接続が断続的となる場合がある。例えば、エレベータやトンネルに入ると接続が失われ、そのエレベータやトンネルから出ないかぎり接続を回復できない場合がある。
【０００３】
現在の多様なプロトコルを使用するネットワーク接続を通じた通信の場合、ネットワーク接続が中断するとデータパケットが失われる。例えば、現在の多様なプロトコルが標準的なＴＣＰネットワーク接続を通じて通信を行う場合、データバッファは概して接続が中断したときに消去される。このように、ネットワーク接続が回復すると、例えば、ネットワーク化されたアプリケーションは、中断する前の状態から再開することができない。概して、エラーメッセージが表示され、ユーザーに不便さに対するフラストレーションを与えることになる。
【０００４】
さらに、現在の多様なプロトコルによるネットワークを通じた通信では、トランスポート接続の頻繁な切断および回復を必要とすることが多い。例えば、ＨＴＴＰを単独または代表的なプロキシプロトコルとともに使用して、標準的なＴＣＰ接続を通じてウェブサイトを閲覧するには、各リソースに対する新しいＨＴＴＰ接続に加えて、以前のＴＣＰ／プロキシプロトコル接続を閉じて、各リソースに対する新しいＴＣＰ／プロキシプロトコル接続を開く必要がある。
【０００５】
さらに、ネットワーク接続に失敗した場合、通信が再開できるようにする前に概して再起動およびサーバへの完全な再ログオンを行わなければならない。例えば、ログオン認証の再適用が必要である。多くの場合これは緩慢なプロセスであり、ユーザーの非効率性をももたらす。
【０００６】
したがって、ネットワーク通信のための改善したシステムおよび方法が必要である。
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明は、クライアントにホストサービスへの信頼できる接続を提供するシステムおよび方法に関する。クライアントとホストサービスとの間の通信に使用する第２のプロトコルのカプセル化が可能な第１の通信プロトコルは、ネットワーク中断時のデータの維持を確実にする。より具体的には、クライアントとホストサービスとの間で通信されるデータがバッファリングされる。例えば、携帯電話のクライアントなどのクライアントは、同じネットワーク内の異なるアクセスポイント間を移動し、一時的なネットワークの中断中にバッファリングされたデータが維持される。同様に、別の例では、クライアントがネットワーク間を（例えば、有線ネットワークから無線ネットワークに）移動する場合、ホストサービスへの一時的な接続の中断中にバッファリングされたデータが維持される。バッファリングされたデータの維持に加えて、クライアントがネットワークのアクセスポイント間、またはネットワーク自身の間を移動する場合、例えば、ネットワーク接続が、サーバ側のコンポーネントの不具合（例えば、サーバ側のプロキシの不具合）、システム内のタイムアウト、または他の理由によって中断した場合でも、バッファリングされたデータを維持することができる。したがって、セッションの持続性が達成され、信頼性が確保される。
【０００８】
本発明の第１の通信プロトコルを使用することによって、第１のプロトコルが通信を行うトランスポート接続、または第１のプロトコル接続自身をも同様に繰り返し開くことおよび／または閉じることを必要とせずに、その中にトンネルさせた第２のプロトコル接続を繰り返し開くことおよび／または閉じることも可能になる。このように、システムの効率が改善される。
【０００９】
さらに、本発明は、ネットワーク接続の中断に続くクライアントのホストサービスへの再接続のシステムおよび方法に関する。より具体的には、前記クライアントのホストサービスへの再接続のシステムおよび方法は、再接続チケットを使用し、ユーザーのログオン認証の再適用を必要としない。このように、クライアントをホストサービスに再接続するために必要な時間が削減される。
【００１０】
一局面では、本発明は、一般にネットワーク通信の方法に関する。前記方法は、第１のプロトコルを使用してクライアントと第１のプロトコルサービスとの間の第１の接続を確立するステップと、前記第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して前記クライアントと前記第１のプロトコルサービスとの間で通信するステップとを含む。さらに、前記第２のプロトコルのうちの少なくとも１つが複数の仮想チャネルを含む。
【００１１】
本発明の本局面の一実施態様では、第２の接続が、第２のプロトコルのうちの１つを使用して、第１のプロトコルサービスとホストサービスとの間に確立される。前記第１のプロトコルサービスと前記ホストサービスとの間の通信は、前記第２のプロトコルのうちの１つを介して行われる。別の実施態様では、複数の第２の接続が、複数の第２のプロトコルを使用して、前記第１のプロトコルサービスと複数のホストサービスとの間に確立される。具体的には、前記複数の第２の接続のそれぞれが、前記第１のプロトコルサービスと異なるホストサービスとの間に確立され、前記複数の第２の接続のそれぞれは、前記複数の第２のプロトコルのうちの１つを使用して確立される。前記第１のプロトコルサービスと前記複数のホストサービスとの間の通信は、前記複数の第２のプロトコルのうちの１つを介した前記複数の第２の接続のそれぞれを通じて行われる。さらに別の実施態様では、前記クライアントと前記第１のプロトコルサービスとの間の第１の接続が、中間ノードを介して確立される。
【００１２】
前記第１のプロトコルはＴＣＰ／ＩＰを通じて通信を行うことができ、前記第２のプロトコルは、例えば、ＨＴＴＰ、ＲＤＰ、ＩＣＡ、ＦＴＰ、Ｏｓｃａｒ、またはＴｅｌｎｅｔを通じて通信を行うことができる。加えて、各仮想チャネルは、リモートアクセス機能を可能にする複数のプロトコルパケットを含むことができる。
【００１３】
一実施態様では、通信が第１のプロトコルのレベルで圧縮される。別の実施態様では、通信が第１のプロトコルのレベルで暗号化される。さらに別の実施態様では、第１の接続がセキュアであり、第１のプロトコルサービスと第１のホストサービスとの間の第２の接続を確立し、クライアントおよび前記第１のホストサービスが前記第１の接続および前記第２の接続を介して通信を行い、前記第２の接続を中断し、前記第１の接続を中断せずに前記第１のプロトコルサービスと第２のホストサービスとの間の第３の接続を確立し、前記第１の接続および前記第３の接続を介して前記クライアントおよび前記第２のホストサービスが通信を行う。
【００１４】
別の局面では、本発明は、クライアントにホストサービスへの信頼できる接続を提供する方法に関する。前記方法は、第１のプロトコルを使用して前記クライアントと第１のプロトコルサービスとの間の第１の接続を確立するステップと、第２のプロトコルを使用して前記第１のプロトコルサービスと前記ホストサービスとの間の第２の接続を確立するステップとを含む。前記第１のプロトコルは、複数の第２のプロトコルをカプセル化する。前記方法は、前記クライアントおよび前記第１のプロトコルサービスのうちの少なくとも１つでの前記第１の接続を介して直近に送信されたデータパケットのキューの維持とをさらに含む。前記第１の接続が失敗したときには、前記第２の接続を維持し、前記第１の接続を介して直近に送信されたデータパケットのキューの維持を継続し、前記第１のプロトコルを使用して前記クライアントと前記第１のプロトコルサービスとの間の第３の接続を確立する。
【００１５】
本発明の本局面の一実施態様では、第３の接続を介してキューに入れたデータパケットのうちの少なくとも１つを送信する。
【００１６】
別の局面では、本発明は、クライアントをホストサービスに再接続する方法を提供する。前記方法は、前記クライアントと中間ノードとの間の第１の接続を提供するステップと、前記中間ノードと第１のプロトコルサービスとの間の第２の接続を提供するステップと、前記第１のプロトコルサービスと前記ホストサービスとの間の第３の接続を提供するステップとを含む。中断は、前記第１の接続および前記第２の接続のうちの少なくとも１つにおいて検出される。前記クライアントと前記中間ノードとの間の前記第１の接続を再確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第３の接続を維持する。第１のチケットおよび第２のチケットも中間ノードで受信する。前記第１のチケットを検証する。前記第１のチケットの検証後、前記中間ノードと前記第１のプロトコルサービスとの間の前記第２の接続を再確立する。前記第２のチケットを検証し、前記第２のチケットの検証後、再確立された前記第２の接続を、維持された前記第３の接続にリンクする。
【００１７】
本発明の本局面の一実施態様では、前記方法は、第１の接続および第２の接続のうちの少なくとも１つにおいて中断が検出された後、前記第１の接続および前記第２の接続のうちの残りの接続を中断するステップを含む。
【００１８】
別の実施態様では、第１のチケットは、中間ノードからチケットオーソリティへ送信され、前記チケットオーソリティを使用して前記第１のチケットを検証する。前記第１のチケットの検証後には、第１のプロトコルに対するアドレスが前記中間ノードで受信される。さらに、前記第１のチケットは、その検証後に削除することができる。前記第１のチケットの削除後は、代替の第１のチケットを生成することができる。
【００１９】
さらに別の実施態様では、第２のチケットが中間ノードから第１のプロトコルサービスに送信され、前記第２のチケットは前記第１のプロトコルサービスを使用して検証される。前記第２のチケットは、その検証後に削除することができる。前記第２のチケットの削除後は、代替の第２のチケットを生成することができる。
【００２０】
さらに別の実施態様では、中間ノードは、第１のチケットの要求をチケットオーソリティに送信することができる。例えば乱数となりうる前記第１のチケットは、前記チケットオーソリティで生成することができる。前記チケットオーソリティは、ハンドルを生成し、前記チケットオーソリティで、前記第１のチケットのコピーと、前記ハンドルのコピーと、前記第１のプロトコルサービスに対するアドレスとを保存することもできる。前記第１のチケットおよび前記ハンドルは、前記チケットオーソリティから前記中間ノードへ送信することができ、次いで前記第１のチケットをクライアントに送信することができる。前記ハンドルは、前記チケットオーソリティに保存された前記第１のチケットのコピーの削除にも使用することができる。
【００２１】
更なる実施態様では、例えば乱数となりうる第２のチケットは、第１のプロトコルサービスで生成することができる。第２のチケットおよびセッション番号のコピーも、前記第１のプロトコルサービスに保存することができる。前記第２のチケットは、前記第１のプロトコルサービスからクライアントへ送信することができる。加えて、第１のチケットおよび第２のチケットのうちの少なくとも１つを所定の時間の経過後に自動的に削除することができる。
【００２２】
別の局面では、本発明は、クライアントをホストサービスに再接続する方法を提供する。前記方法は、前記クライアントと第１の中間ノードとの間の第１の接続を提供するステップと、前記第１の中間ノードと第１のプロトコルサービスとの間の第２の接続を提供するステップと、前記第１のプロトコルサービスと前記ホストサービスとの間の第３の接続を提供するステップとを含む。中断は、前記第１の接続および前記第２の接続のうちの少なくとも１つにおいて検出される。前記第１の中間ノードとは異なる前記クライアントと第２の中間ノードとの間の第４の接続を確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第３の接続を維持する。第１のチケットおよび第２のチケットも前記第２の中間ノードで受信する。前記第１のチケットを検証する。前記第１のチケットの検証後、前記第２の中間ノードと前記第１のプロトコルサービスとの間の第５の接続を確立する。前記第２のチケットを検証し、前記第２のチケットの検証後、確立された前記第５の接続を、維持された前記第３の接続にリンクする。
【００２３】
別の局面では、本発明は、クライアントをホストサービスに再接続する方法を提供する。前記方法は、前記クライアントと第１のプロトコルサービスとの間の第１の接続を提供するステップと、前記第１のプロトコルサービスと前記ホストサービスとの間の第２の接続を提供するステップとを含む。中断は、前記第１の接続において検出される。前記クライアントと前記第１のプロトコルサービスとの間の前記第１の接続を再確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第２の接続を維持する。チケットは、前記第１のプロトコルサービスでも受信される。前記チケットは検証される。前記チケットの検証後、再確立された前記第１の接続を、維持された前記第２の接続にリンクする。
【００２４】
本発明の本局面の一実施態様では、その検証後にチケットを削除する。さらに、前記チケットの削除後に代替のチケットを生成することができる。別の実施態様では、乱数となりうるチケットは、第１のプロトコルサービスで生成することができる。前記チケットおよびセッション番号のコピーは、前記第１のプロトコルサービスに保存することができる。前記チケットは、前記第１のプロトコルサービスからクライアントへ送信することもできる。加えて、前記チケットは、所定の時間の経過後に自動的に削除することができる。
【００２５】
別の局面では、本発明は、一般にネットワーク通信のシステムに関する。前記システムは、クライアントとの第１の接続を受け入れ、第１のプロトコルにカプセル化された複数の第２のプロトコルを介してクライアントと通信を行うように構成された第１のプロトコルサービスを含む。さらに、前記第２のプロトコルのうちの少なくとも１つが複数の仮想チャネルを含む。
【００２６】
本発明の本局面の一実施態様では、第１のプロトコルサービスが、ホストサービスとの第２の接続を確立し、第２のプロトコルを介して前記ホストサービスと通信を行うようにさらに構成される。別の実施態様では、第１のプロトコルサービスが、複数の第２のプロトコルを使用して複数のホストサービスとの複数の第２の接続を確立するようにさらに構成される。具体的には、前記複数の第２の接続のそれぞれが異なるホストサービスによって確立され、前記第２の接続のそれぞれが前記複数の第２のプロトコルのうちの１つを使用して確立される。このような実施態様では、前記第１のプロトコルサービスが、前記複数の第２のプロトコルのうちの１つを介した前記複数の第２の接続のそれぞれを通じて前記複数のホストサービスと通信を行うようにさらに構成される。さらに別の実施態様では、クライアントとの第１の接続は、中間ノードを経由される。
【００２７】
第１のプロトコルはＴＣＰ／ＩＰを通じて通信を行うことができ、第２のプロトコルは、例えば、ＨＴＴＰ、ＲＤＰ、ＩＣＡ、ＦＴＰ、Ｏｓｃａｒ、またはＴｅｌｎｅｔを通じて通信を行うことができる。加えて、各仮想チャネルは、リモートアクセス機能を可能にする複数のプロトコルパケットを含むことができる。
【００２８】
一実施態様では、第１のプロトコルサービスは、第１のプロトコルのレベルで通信を圧縮するように構成される。別の実施態様では、第１のプロトコルサービスは、第１のプロトコルのレベルで通信を暗号化するように構成される。さらに別の実施態様では、第１の接続がセキュアであり、第１のプロトコルサービスが、第１のホストサービスとの第２の接続を確立し、前記第２の接続を中断し、前記第１の接続を中断せずに第２のホストサービスとの第３の接続を確立するように構成される。
【００２９】
別の局面では、本発明は、クライアントにホストサービスへの信頼できる接続を提供するシステムに関する。前記システムは、第１のプロトコルサービスと前記ホストサービスとを含む。前記第１のプロトコルサービスは、前記クライアントとの第１の接続を受け入れ、前記ホストサービスとの第２の接続を確立するように構成され、前記第１の接続が失敗したときには、前記第２の接続を維持し、クライアントからの第３の接続を受け入れる。前記ホストサービスは、前記第１のプロトコルサービスとの第２の接続を受け入れるように構成され、前記第１の接続が失敗したときには、第２の接続を維持する。前記第１の接続および前記第３の接続は、複数の第２の接続をカプセル化できる第１のプロトコルを使用してそれぞれ確立される。さらに、前記クライアントおよび前記第１のプロトコルサービスのうちの少なくとも１つは、前記第１の接続の前でも失敗時でも、前記第１の接続を介して直近に送信されたデータパケットのキューを維持するようにさらに構成される。
【００３０】
本発明の本局面の一実施態様では、クライアントは、第３の接続を介してキューに入れたデータパケットのうちの少なくとも１つを送信するようにさらに構成される。あるいは、第１のプロトコルサービスを、前記第３の接続を介してキューに入れたデータパケットのうちの少なくとも１つを送信するように構成することができる。
【００３１】
別の局面では、本発明は、クライアントをホストサービスに再接続するシステムを提供する。前記システムは、前記クライアントと、中間ノードと、第１のプロトコルサービスとを含む。前記クライアントは、前記中間ノードによる第１の接続を維持するように構成される。その部分に関して、前記中間ノードは、前記クライアントによる前記第１の接続、および前記第１のプロトコルサービスによる第２の接続を維持するように構成される。前記第１のプロトコルサービスは、前記中間ノードによる前記第２の接続、および、前記ホストサービスによる第３の接続を維持するように構成される。このシステムによれば、中断は、前記第１の接続および前記第２の接続のうちの少なくとも１つにおいて検出され、前記クライアントと前記中間ノードとの間の前記第１の接続を再確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第３の接続を維持し、第１のチケットおよび第２のチケットが前記クライアントから前記中間ノードへ送信され、前記第１のチケットを検証し、前記第１のチケットの検証後、前記中間ノードと前記第１のプロトコルサービスとの間の第２の接続を再確立し、前記第２のチケットを検証し、前記第２のチケットの検証後、再確立された前記第２の接続を、維持された前記第３の接続にリンクする。
【００３２】
本発明の本局面の一実施態様では、第１の接続および第２の接続のうちの少なくとも１つにおいて中断が検出された後に、前記第１の接続および前記第２の接続のうちの残りの接続を中断する。
【００３３】
別の実施態様では、第１のチケットは、チケットオーソリティを使用して検証される。
前記チケットオーソリティは、例えば、中間ノードから前記第１のチケットを受信して、前記第１のチケットを検証するように構成される。一実施態様では、中間ノードは、第１のチケットの検証後に、第１のプロトコルサービスに対するアドレスを受信するようにさらに構成される。前記チケットオーソリティは、その検証後に前記第１のチケットを削除するように構成することができる。さらに、前記チケットオーソリティは、前記第１のチケットの削除後に代替の第１のチケットを生成するように構成することができる。
【００３４】
別の実施態様では、第２のチケットは、第１のプロトコルサービスを使用して検証される。前記第１のプロトコルサービスは、例えば、中間ノードから前記第２のチケットを受信して前記第２のチケットを検証するように構成される。前記第１のプロトコルサービスは、その検証後に前記第２のチケットを削除するように構成することができる。さらに、前記第１のプロトコルサービスは、前記第２のチケットの削除後に代替の第２のチケットを生成するように構成することができる。
【００３５】
さらに別の実施態様では、中間ノードは、第１のチケットに対する要求を前記チケットオーソリティに送信するように構成される。前記チケットオーソリティは、例えば乱数となりうる前記第１のチケットを発生するように構成することができる。前記チケットオーソリティは、ハンドルを生成し、前記第１のチケットのコピーと、前記ハンドルのコピーと、前記第１のプロトコルサービスに対するアドレスとを保存するように構成することもできる。前記チケットオーソリティは、前記第１のチケットおよび前記ハンドルを前記チケットオーソリティから前記中間ノードへ送信し、次いで前記第１のチケットを前記クライアントに送信できるように構成することができる。前記中間ノードは、前記チケットオーソリティに保存した前記第１のチケットのコピーを削除するために前記ハンドルを使用するように構成することもできる。
【００３６】
更なる実施態様では、第１のプロトコルサービスは、例えば乱数となりうる第２のチケットを生成するように構成することができる。前記第１のプロトコルサービスは、前記第２のチケットおよびセッション番号のコピーを保存するように構成することもできる。別の実施態様では、第１のプロトコルサービスは、第２のチケットをクライアントに送信するように構成される。加えて、第１のチケットおよび第２のチケットのうちの少なくとも１つは、所定の時間の経過後に自動的に削除するように構成することができる。
【００３７】
別の局面では、本発明は、クライアントをホストサービスに再接続するシステムを提供する。前記システムは、前記クライアントと、第１の中間ノードと、第１のプロトコルサービスと、前記第１の中間ノードとは異なる第２の中間ノードとを含む。前記クライアントは、前記第１の中間ノードによる第１の接続を維持するように構成される。その部分に関して、前記第１の中間ノードは、前記クライアントによる前記第１の接続、および前記第１のプロトコルサービスによる第２の接続を維持するように構成される。前記第１のプロトコルサービスは、前記第１の中間ノードによる前記第２の接続、および、前記ホストサービスによる第３の接続を維持するように構成される。このシステムによれば、中断は、前記第１の接続および前記第２の接続のうちの少なくとも１つにおいて検出され、前記クライアントと第２の中間ノードとの間の第４の接続を再確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第３の接続を維持し、第１のチケットおよび第２のチケットは、前記クライアントから前記第２の中間ノードへ送信され、前記第１のチケットを検証し、前記第１のチケットの検証後、前記第２の中間ノードと前記第１のプロトコルサービスとの間の第５の接続を確立し、前記第２のチケットを検証し、前記第２のチケットの検証後、確立された前記第５の接続を、維持された前記第３の接続にリンクする。
【００３８】
別の局面では、本発明は、クライアントをホストサービスに再接続するシステムを提供する。前記システムは、前記クライアントと、第１のプロトコルサービスとを含む。前記クライアントは、前記第１のプロトコルサービスによる第１の接続を維持するように構成される。その部分に関して、前記第１のプロトコルサービスは、前記クライアントによる前記第１の接続、および前記ホストサービスによる第２の接続を維持するように構成される。このシステムによれば、中断は、前記第１の接続において検出され、前記クライアントと前記第１のプロトコルサービスとの間の前記第１の接続を再確立しながら、前記第１のプロトコルサービスと前記ホストサービスとの間の前記第２の接続を維持し、チケットが、前記クライアントから前記第１のプロトコルサービスへ送信され、前記チケットを検証し、前記チケットの検証後、再確立された前記第１の接続を、維持された前記第２の接続にリンクする。
【００３９】
本発明の本局面の一実施態様では、第１のプロトコルサービスは、チケットの検証後に前記チケットを削除するようにさらに構成される。さらに、前記第１のプロトコルサービスは、前記チケットの削除後に代替のチケットを生成するようにさらに構成することができる。別の実施態様では、第１のプロトコルサービスは、例えば乱数となりうるチケットを生成するように構成される。前記第１のプロトコルサービスは、前記チケットおよびセッション番号のコピーを保存するように構成することができる。前記第１のプロトコルサービスは、前記クライアントに前記チケットを送信するように構成することもできる。加えて、前記チケットは、所定の時間の経過後に自動的に削除するように構成することができる。
【発明を実施するための最良の形態】
【００４０】
以下、本発明の特定の実施態様について説明する。しかし、本発明は、これらの実施態様に限定されるものではなく、本願明細書に明白に開示した内容への追加および変更が本発明の範囲に明白に含まれることを意図していることに留意されたい。さらに、本願明細書に開示される種々の実施態様の特徴は排他的でなく、本願明細書に組み合わせまたは置き換えが明示されていなくても、本発明の精神と範囲から逸脱することなくそのような組み合わせおよび置き換えが存在しうると理解されたい。
【００４１】
図１Ａを参照すると、一般に本発明は、ネットワーク通信に関し、特にクライアントにホストサービスへの信頼できる接続の提供に有用となりうる。概観すると、ネットワーク通信のシステム１００は、ネットワーク１０４を通じて第１のプロトコルサービス１１２（例えば、第２のコンピュータ）と通信を行うリモートクライアント１０８（例えば、第１のコンピュータ）を含む。システム１００は、ネットワーク１０４’を通じて第１のプロトコルサービス１１２と通信を行い、ネットワーク１０４を通じて第１のプロトコルサービス１１２を介してクライアント１０８と通信を行う、複数のホストサービス１１６ａ乃至１１６ｎ（例えば、第３のコンピュータ）も含む。あるいは、本発明の別の実施態様では、図１Ｂを参照すると、第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、独立したコンピュータとして使用されるのではなく、むしろ図１Ａのように、例えばホストノード１１８ａのような同じコンピュータに組み込まれる。システム１００は、１つ、２つ、または多数のホストノード１１８ａ乃至１１８ｎを含むことができる。
【００４２】
一実施態様では、図１Ａに示すように、ネットワーク１０４および１０４’は独立したネットワークである。図１Ｂに示すように、ネットワーク１０４および１０４’は同じネットワーク１０４とすることができる。一実施態様では、ネットワーク１０４および／またはネットワーク１０４’は、例えば、会社のイントラネットのようなローカルエリアネットワーク（ＬＡＮ）または、例えば、インターネットまたはワールドワイドウェブのようなワイドエリアネットワーク（ＷＡＮ）である。リモートクライアント１０８、第１のプロトコルサービス１１２、ホストサービス１１６、および／またはホストノード１１８は、これらに限定されないが、標準電話回線、ＬＡＮまたはＷＡＮのリンク（例えば、８０２．１１、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（例えば、ＩＳＤＮ，Ｆｒａｍｅ  Ｒｅｌａｙ、ＡＴＭ）、無線接続、あるいはこれらのいずれかまたはすべてを組み合わせたものなど、様々な接続を介してネットワーク１０４および／またはネットワーク１０４’に接続することができる。
【００４３】
さらに、クライアント１０８は、ワークステーション、デスクトップコンピュータ、ラップトップ、ハンドヘルドコンピュータ、携帯電話、または通信が可能で、本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する他の形態のコンピュータまたはテレコミュニケーション装置とすることができる。クライアント１０８は、例えば、視覚的表示装置（例えば、コンピュータ用モニタ）、データ入力装置（例えば、キーボード）、持続的および／または揮発性記憶装置（例えば、コンピュータメモリ）、プロセッサ、およびマウスを備えることができる。
【００４４】
同様に、図１Ａを参照すると、第１のプロトコルサービス１１２およびホストサービス１１６のそれぞれは、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有するいずれかのコンピュータ上に提供することができる。あるいは、第１のプロトコルサービス１１２およびホストサービス１１６の機能を、図１Ｂに示すように、例えばホストノード１１８のような同じコンピュータに組み込む場合は、第１のプロトコルサービス１１２および／またはホストサービス１１６を、汎用コンピュータおよび／または、例えば、ＡＳＩＣまたはＦＰＧＡのような特殊用途向けハードウェア装置上で実行されるソフトウェアプログラムとして使用することができ、ホストノード１１８は、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有するいずれかのコンピュータとすることができる。
【００４５】
一実施態様では、ホストサービス１１６のそれぞれは、クライアント１０８に対して遠隔で利用可能な１つ以上のアプリケーションプログラムをホストする。１つまたは複数のホストサービス１１６が同じアプリケーションプログラムをホストすることができる。このようなアプリケーションの例には、ＭＩＣＲＯＳＯＦＴ  ＷＯＲＤなどのワード処理プログラム、およびＭＩＣＲＯＳＯＦＴ  ＥＸＣＥＬなどの表計算プログラムなどが挙げられ、そのどちらもＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）から入手可能である。一部／すべてのホストサービス１１６がホスト可能な他のアプリケーションプログラムの例には、財務報告プログラム、顧客登録プログラム、技術的なサポート情報を提供するプログラム、顧客データベースアプリケーション、およびアプリケーションの設定マネージャが挙げられる。さらに、一実施態様では、ホストサービス１１６は、ストリーミングオーディオおよび／またはストリーミングビデオをクライアント１０８に提供するオーディオ／ビデオストリーミングサーバである。別の実施態様では、ホストサービス１１６は、一部／すべてのファイルタイプをクライアント１０８に提供するファイルサーバを備える。
【００４６】
引き続き図１Ａおよび図１Ｂを参照すると、クライアント１０８は、第１のプロトコルを使用してネットワーク１０４を通じてクライアント１０８と第１のプロトコルサービス１１２との間の接続１２０を確立するように構成される。第１のプロトコルサービス１１２は、その役割として、接続１２０を受け入れるように構成される。したがって、クライアント１０８および第１のプロトコルサービス１１２は、第１のプロトコルを使用して互いに通信を行うことができる。
【００４７】
一部の実施態様では、図１Ａおよび図１Ｂに示すように、クライアントエージェント１２８は、クライアント１０８内に含まれる。クライアントエージェント１２８は、例えば、ソフトウェアプログラムおよび／または、例えば、ＡＳＩＣまたはＦＰＧＡなどのようなハードウェア装置として使用することができる。クライアントエージェント１２８は、あらゆるタイプのプロトコルを使用することができ、それには、例えば、ＨＴＴＰクライアントエージェント、ＦＴＰクライアントエージェント、Ｏｓｃａｒクライアントエージェント、Ｔｅｌｎｅｔクライアントエージェント、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ  Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）製のＩｎｄｅｐｅｎｄｅｎｔ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）クライアントエージェント、またはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲｅｍｏｔｅ  Ｄｅｓｋｔｏｐ  Ｐｒｏｃｅｄｕｒｅ  （ＲＤＰ）クライアントエージェントが挙げられる。一部の実施態様では、クライアントエージェント１２８は、それ自体が第１のプロトコルを使用して通信を行うように構成される。一部の実施態様では（図示せず）、クライアント１０８は、複数のクライアントエージェント１２８ａ乃至１２８ｎを含み、それぞれがホストサービス１１６ａ乃至１１６ｎとそれぞれ通信を行う。
【００４８】
別の実施態様では、スタンドアロンのクライアントエージェントは、第１のプロトコルを使用してクライアント１０８が通信できるように構成される。スタンドアロンのクライアントエージェントはクライアント１０８内に組み込まれるか、またはスタンドアロンのクライアントエージェントをクライアント１０８から独立させることができる。スタンドアロンのクライアントエージェントは、例えば、ローカルホストのプロキシである。一般に、スタンドアロンのクライアントエージェントは、クライアントエージェント１２８に関する本願明細書に開示された機能のいずれかを実行することができる。
【００４９】
さらに下記のように、第１のプロトコルサービス１１２は、一実施態様では、それ自体が第１のプロトコルを使用して通信を行うように構成される。
【００５０】
第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａ乃至１１６ｎとの間の接続１２４ａ乃至１２４ｎを確立するようにそれぞれ構成される。例えば、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａ、および第１のプロトコルサービス１１２と別のホストサービス１１６ｂとの間の接続１２４ｂを確立することができる。一実施態様では、第１のプロトコルサービス１０８は、このような接続１２４ａ乃至１２４ｎを別々に確立する（すなわち、第１のプロトコルサービス１１２は、一度に１つの接続を確立する）。別の実施態様では、第１のプロトコルサービス１１２は、このような接続１２４ａ乃至１２４ｎのうちの２つ以上を同時に確立する。
【００５１】
さらに別の実施態様では、第１のプロトコルサービス１１２は、接続１２０を中断せずに２つ以上の接続１２４をクライアント１０８に提供するように構成される。例えば、第１のプロトコルサービス１１２は、クライアント１０８のユーザーがホストサービスに１１６ａに存在する第１のアプリケーションプログラムの実行を要求した場合、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立するように構成することができる。ユーザーが第１のアプリケーションプログラムの実行を終了し、例えばホストサービス１１６ｂに存在する第２のアプリケーションプログラムの実行を開始する場合、一実施態様では、第１のプロトコルサービス１１２は、接続１２４ａを中断して、第１のプロトコルサービス１１２とクライアント１０８との間の接続１２０を中断させずに第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立するように構成される。
【００５２】
第１のプロトコルサービス１１２およびホストサービス１１６ａ乃至１１６ｎは、限定されないが、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ  Ｌａｕｄｅｒａｌｅ、Ｆｌｏｒｉｄａ）製のＩＣＡプレゼンテーションプロトコルおよび／またはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）製のＲＤＰプレゼンテーションプロトコルを含む、様々な第２のプロトコルのうちのいずれか１つを使用して、接続１２４ａ乃至１２４ｎを通じて通信を行うことができる。例えば、第１のプロトコルサービス１１２およびホストサービス１１６ａは、ＩＣＡプレゼンテーションプロトコルを使用して接続１２４ａを通じて通信を行いながら、第１のプロトコルサービス１１２およびホストサービス１１６ｂは、ＲＤＰプレゼンテーションプロトコルを使用して接続１２４ｂを通じて通信を行うことができる。
【００５３】
一実施態様では、第１のプロトコルサービス１１２とホストサービス１１６との間の通信を行うために使用する、例えばＩＣＡプレゼンテーションプロトコルのような第２のプロトコルは、複数の仮想チャネルを含む。仮想チャネルは、データを交換するためのコマンドを発行するためにアプリケーション層コードが使用するセッション指向の送信接続である。例えば、複数の仮想チャネルのそれぞれは、リモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。一実施態様では、複数の仮想チャネルのうちの１つが、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるために、第１のプロトコルサービス１１２を介して、グラフィックスクリーンコマンドをホストサービス１１６からクライアント１０８に送信するためのプロトコルパケットを含む。別の実施態様では、複数の仮想チャネルのうちの１つが、クライアント１０８で文書を印刷させるために、第１のプロトコルサービス１１２を介して、プリンタコマンドをホストサービス１１６からクライアント１０８に送信するためのプロトコルパケットを含む。
【００５４】
一実施態様では、第１のプロトコルは、トンネリングプロトコルである。第１のプロトコルサービス１１２は、それぞれがホストサービス１１６と第１のプロトコルサービス１１２との間の通信に使用する、複数の第２のプロトコルを第１のプロトコル内にカプセル化する。このように、ホストサービス１１６および第１のプロトコルサービス１１２は、複数の第２のプロトコルを介してクライアント１０８と通信を行う。一実施態様では、第１のプロトコルは、例えば、ＴＣＰ／ＩＰ接続を通じて複数の第２のプロトコルのトンネリングが可能な、アプリケーションレベルのトランスポートプロトコルである。
【００５５】
図２を参照すると、概念的には、接続１２０を介したクライアント１０８と第１のプロトコルサービス１１２との間の通信は、、第１のプロトコル２０４内にカプセル化された複数の第２のプロトコル２００ａ乃至２００ｎ（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および／またはＲＤＰ）の形をとる。これは、第１のプロトコル２０４の中の第２のプロトコル２００ａ乃至２００ｎの位置によって示される。セキュアな通信が要求されない場合は、図２に示すように、第１のプロトコル２０４は、ＴＣＰ接続２０８を通じて通信を行うことができる。
【００５６】
図３を参照すると、セキュアな通信を使用する場合、第１のプロトコル２０４は、例えば、セキュアソケットレイヤー（ＳＳＬ）２１６プロトコルを使用して保護されるＴＣＰ接続２１２などのような暗号化された接続を通じて通信を行う。ＳＳＬは、Ｎｅｔｓｃａｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ社（Ｍｏｕｎｔａｉｎ  Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）が開発し、Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＳＬ）プロトコルとしてインターネット技術特別調査委員会（ＩＥＴＦ）が広め、ＩＥＴＦ  ＲＦＣ−２２４６に記載された、現在の標準である。
【００５７】
従って、複数の第２のプロトコル２００ａ乃至２００ｎは、接続１２０を通じてセキュリティ有り（図３）またはセキュリティなし（図２）で第１のプロトコル２０４内で通信を行う。
【００５８】
一実施態様では、第１のプロトコル２０４は、その中にトンネリングした、例えば、ＨＴＴＰ接続２００などのような第２のプロトコル接続２００が、第１のプロトコル２０４がそれを通じて通信を行うトランスポート接続（例えば、ＴＣＰ接続２０８および／または２１２）、ＳＳＬプロトコル接続２１６、または第１のプロトコル接続２０４自身をも同様に繰り返して開くおよび／または閉じることを必要とせずに、繰り返して開くおよび／または閉じるようにする。
【００５９】
図４を参照すると、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００は、接続１２０を介して通信を行うために、複数の第２のプロトコル２００（例えば、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡおよび／またはＲＤＰ）を第１のプロトコル２０４内にカプセル化する。任意に、下記のように、第１のプロトコルサービス１１２およびクライアント１０８のクライアントエージェント１２８が使用するプロセス例３００はまた、接続１２０を介した通信の前に、第１のプロトコルのレベルで通信を圧縮および／または暗号化する。第１のプロトコルサービス１１２の観点から、第２のプロトコルパケット３０４は、接続１２４を介して第１のプロトコルサービス１１２で受信する。例えば、２の第２のプロトコルパケット３０４ａおよび３０４ｂは、第１のプロトコルサービス１１２によって受信される。１つ、２つ、または多数の第２のプロトコルパケット３０４を受信することができる。一実施態様では、第２のプロトコルパケット３０４は、ホストサービス１１６によって接続１２４を通じて第１のプロトコルサービス１１２に送信される。第２のプロトコルパケット３０４は、ヘッダー３０８およびデータペイロード３１２を含む。
【００６０】
第２のプロトコルパケット３０４の受信の後に、第１のプロトコルサービス１１２は、１つ以上の第２のプロトコルパケット３０４を第１のプロトコルパケット３１６内にカプセル化する。一実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルパケットヘッダ３２０を生成し、例えば、２つの第２のプロトコルパケット３０４ａおよび３０４ｂなどのような、１つ以上の第２のプロトコルパケット３０４を第１のプロトコルパケットのデータペイロード３２４内にカプセル化する。別の実施態様では、１つの第２のプロトコルパケット３０４ａだけが、各第１のプロトコルパケット３１６内にカプセル化される。
【００６１】
一実施態様では、第１のプロトコルパケット３１６は、次いで接続１２０、例えば図２を参照して説明される接続２０８を通じて、クライアント１０８のクライアントエージェント１２８に送信される。あるいは、別の実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケット３１６の送信の前に、第１のプロトコル２０４のレベルでの通信を暗号化するようにさらに構成される。このような一実施態様では、第１のプロトコルパケット３１６は、例えば、図３を参照して説明されるＳＳＬプロトコルを使用して暗号化される。その結果、ヘッダー３３２と、データペイロード３３６としての暗号化された第１のプロトコルパケット３１６’を含むセキュアなパケット３２８が生成される。セキュアなパケット３２８は、次いで接続１２０、例えば図３を参照して説明されるセキュアなＴＣＰ接続２１２を通じて、クライアント１０８のクライアントエージェント１２８に送信される。
【００６２】
別の実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケット３１６の送信の前に、第１のプロトコル２０４のレベルで通信を暗号化するようにさらに構成される。一実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルパケット３１６を暗号化する前に、標準的な圧縮技術を使用して第１のプロトコルパケット３１６を圧縮する。このように、システム１００の効率が改善される。
【００６３】
図１Ａおよび図１Ｂを再び参照すると、本発明のシステム１００は、一実施態様では、例えばホストサービス１１６ａのようなホストサービス１１６への信頼できる接続を有するリモートクライアント１０８を提供する。例えば、クライアント１０８がクライアント１０８と第１のプロトコルサービス１１２との間の接続１２０を確立し、第１のプロトコルサービス１１２が第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを確立する場合は、次いでクライアントエージェント１２８または第１のプロトコルサービス１１２のいずれか、またはその両方が、接続１２０を介して直近に送信された第１のプロトコルデータパケットのキューを維持するように構成される。例えば、キューに入れたデータパケットは、接続１２０の前でも失敗時でもクライアントエージェント１２８および／または第１のプロトコルサービス１１２によって維持されることができる。さらに、接続１２０の失敗時には、第１のプロトコルサービス１１２、および同様にホストサービス１１６ａは、接続１２４ａを維持するように構成される。
【００６４】
接続１２０の失敗を受けて、クライアント１０８は、いずれのデータも失わずに第１のプロトコルサービス１１２による新しい接続１２０を確立する。より具体的には、接続１２０の失敗時に接続１２４ａが維持されるので、新しく確立された接続１２０は、維持された接続１２４ａにリンクされることができる。さらに、直近に送信された第１のプロトコルデータパケットがキューに入っているので、クライアント１０８によってそれらを第１のプロトコルサービス１１２に再び送信することができ、および／または第１のプロトコルサービス１１２によって新しく確立された接続１２０を通じてクライアント１０８に再び送信することができる。このように、ホストサービス１１６ａとクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失われずに持続的に進められる。
【００６５】
一実施態様では、クライアント１０８のクライアントエージェント１２８および／または第１のプロトコルサービス１１２は、それらが接続１２０を通じて送信するデータパケットに番号を付ける。例えば、クライアントエージェント１２８および第１のプロトコルサービス１１２それぞれに、他のものがそのデータパケットにどのように番号を付けたかに関係なく、それ自身の送信データパケットに別々に番号を付ける。さらに、データパケットの番号付けは、データパケットの番号を付け直さずに絶対的なものとすることができる。すなわち、クライアントエージェント１２８および／または第１のプロトコルサービス１１２により送信された最初のデータパケットには、番号１を付けることができ、接続１２０を通じてクライアントエージェント１２８および／または第１のプロトコルサービス１１２により送信された各データパケットには、その後にそれぞれ連続した番号が付けられる。
【００６６】
このような一実施態様では、接続１２０の中断および再確立を受けて、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、一方にそれが要求する次のデータパケットを通知する。例えば、クライアントエージェント１２８が、接続１２０の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１２０の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に現在データパケット番号１１を要求していることを通知する。同様に、第１のプロトコルサービス１１２は、このように機能することもできる。あるいは、別のこのような実施態様では、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、一方に受信した最後のパケットデータを通知する。例えば、クライアントエージェント１２８が、接続１２０の中断の前に番号１乃至１０のデータパケットを受信した場合、接続１２０の再確立時に、クライアントエージェント１２８は第１のプロトコルサービス１１２に最後に受信したデータパケット番号１０を通知する。第１のプロトコルサービス１１２も同様に機能することができる。さらに別の実施態様では、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、接続１２０の再確立時に、一方に受信した最後のデータパケットおよび要求する次のデータパケットの両方を通知する。
【００６７】
このような実施態様では、接続１２０の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、他のものが受信していないバッファリングされたデータパケットを再送信することができ、第１のプロトコルサービス１１２を介して、ホストサービス１１６とクライアント１０８との間の通信セッションをいずれのデータも失わずに進めることができる。さらに、接続１２０の再確立時に、クライアントエージェント１２８および／または第１のプロトコルサービス１１２は、現在一方が受信したことがわかっているバッファリングされたデータパケットをそれぞれのバッファから消去することができる。
【００６８】
図５は、クライアント１０８を上述のようにホストサービス１１６に再接続することが可能な、システム４００の別の実施態様を示す。すべて上述したネットワーク１０４および１０４’、クライアント１０８、第１のプロトコルサービス１１２、およびホストサービス１１６に加えて、システム４００は、中間ノード１３２と、チケットオーソリティ１３６とをさらに含む。一実施態様では、中間ノード１３２は、ネットワーク１０４の構成により、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき、例えばファイアウォールおよび／またはルータのようなセキュリティゲートウェイである。図示するように、チケットオーソリティ１３６は、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、スタンドアロンのネットワークコンポーネントとすることができる。
【００６９】
図５の実施態様に示すように、中間ノード１３２は、クライアント１０８によって開始される接続１２０ａを受け入れ、第１のプロトコルサービス１１２による第２の接続１２０ｂを確立するように構成される。合わせて、接続１２０ａおよび第２の接続１２０ｂは、上述のように接続１２０を構成し、それらを通じて第１のプロトコルを使用してクライアント１０８および第１のプロトコルサービス１１２が通信を行う。
【００７０】
図に示すように、中間ノード１３２はまた、チケットオーソリティ１３６と通信を行うように構成される。一実施態様では、チケットオーソリティ１３６は、中間ノード１３２からの第１の再接続チケットに対する要求を受信し、その後に第１の再構成チケットを生成するように構成される。第１の再接続チケットは、例えば、大きな乱数を含むことができる。
【００７１】
別の実施態様では、チケットオーソリティ１３６は、ハンドルを生成するように構成される。ハンドルは、例えば、第１の再接続チケットと関連する（例えば、マップする）乱数とすることができる。一実施態様では、ハンドルは、第１の再接続チケットを形成している乱数よりも小さな乱数である。例えば、ハンドルは、３２ビット乱数としてよい。チケットオーソリティ１３６は、第１の再接続チケットおよびハンドルを中間ノード１３２に送信しながら、第１の再接続チケットのコピーおよびハンドルのコピーを維持する。第１の再接続チケットのコピーは、後にチケットオーソリティ１３６が使用することができ、クライアント１０８の再接続プロセス中に、後にチケットオーソリティ１３６にそのコピーを示す際に、元々はクライアント１０８に送信された第１の再接続チケットを検証する。一実施態様では、チケットオーソリティ１３６は、第１のプロトコルサービス１１２に対するアドレスも維持するが、そのアドレスは、後述するように、第１の接続チケットに関連し、第１の再接続チケットの検証時に、中間ノード１３２に送信される。
【００７２】
一実施態様では、中間ノード１３２は、チケットオーソリティ１３６がそこに送信されたハンドルを使用して、チケットオーソリティ１３６で維持された第１の接続チケットを削除するようにさらに構成される。別の実施態様では、下記のように、チケットオーソリティ１３６は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第１の再接続チケットを削除し、その後代替の第１の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第１の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。
【００７３】
別の実施態様では、第１のプロトコルサービス１１２は、第１の再接続チケットなどの場合、例えば、大きな乱数を含むことができる第２の再接続チケットを生成するように構成される。第１のプロトコルサービス１１２は、第２の接続チケットをクライアント１０８に送信しながら、第２の再接続チケットのコピーおよびセッション番号を維持するようにも構成することができる。第２の再接続チケットのコピーは、後に第１のプロトコルサービス１１２が使用することができ、クライアント１０８の再接続プロセス中に、後に第１のプロトコルサービス１１２にそのコピーを示す際に、元々はクライアント１０８に送信された第２の再接続チケットを検証する。一実施態様では、第１のプロトコルサービス１１２は、中間ノード１３２を介して第２の再接続チケットをクライアント１０８に送信する。別の実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットをクライアント１０８に直接送信する。さらに、下記にさらに詳しく説明するように、第１のプロトコルサービス１１２は、クライアント１０８のホストサービス１１６への再接続プロセス中に、第２の再接続チケットを削除し、その後代替の第２の再接続チケットを生成するようにさらに構成される。加えて、別の実施態様では、第２の再接続チケットは、所定の時間の経過後に自動的に削除するように構成される。
【００７４】
一実施態様では、中間ノード１３２は、第１および第２の再接続チケットに対する中間物としての機能を果たす。中間ノード１３２は、例えば、チケットオーソリティ１３６が生成する第１の再接続チケット、および第１のプロトコルサービス１１２が生成する第２の再接続チケットを受信する。中間ノード１３２は、次いで第１の再接続チケットおよび第２の再接続チケットをクライアント１０８に送信することができる。さらに、クライアント１０８のホストサービス１１６への再接続プロセス中、中間ノード１３２は、クライアント１０８から第１の再接続チケットおよび第２の再接続チケットを受け入れることができ、その後第１の再接続チケットをチケットオーソリティ１３６に送信することができ、該当する場合は、第２の再接続チケットを第１のプロトコルサービス１１２に送信することができる。
【００７５】
クライアント１０８のホストサービス１１６への再接続プロセス、および第１および第２の再接続チケットの使用について、図７乃至１０とともに下記に開示される方法を参照してさらに説明する。
【００７６】
図６Ａを参照すると、ネットワーク通信のためのシステム５００の別の実施態様は、上述のように、ネットワーク１０４および１０４’と、クライアント１０８と、第１のプロトコルサービス１１２と、ホストサービス１１６と、中間ノード１３２と、チケットオーソリティ１３６とを含み、さらに、一実施態様においてクライアント１０８をホストサービス１１６に最初に接続するためにどちらも使用される、第１の計算コード１４０および第２の計算ノード１４４を示す。さらに、図６Ａの実施態様では、クライアント１０８は、例えば、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、ＷＡ）製のＩＮＴＥＲＮＥＴ  ＥＸＰＬＯＲＥＲなどのような、ワールドワイドウェブに接続するためのウェブブラウザ１４８をさらに含む。
【００７７】
一実施態様では（図示せず）、システム５００は、２つ以上の中間ノード１３２および／または２つ以上の第１のプロトコルサービス１１２を含む。クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード１３２および／または第１のプロトコルサービス１１２は、例えばロードバランシング式に基づいてそれぞれ選択することができる。
【００７８】
第１の計算ノード１４０および第２の計算ノード１４４のそれぞれは、通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、いずれのコンピュータとすることができる。例えば、一実施態様では、第１の計算ノード１４０は、１つ以上のウェブサイトを提供するウェブサーバである。別の実施態様では、第２の計算ノード１４４は、ＸＭＬサービスを提供する。
【００７９】
一実施態様では、クライアント１０８およびネットワーク１０４は、外部ネットワーク１５２を形成するが、破線で示される第１のファイアウォール１５６によってシステム５００の他の部分から切り離される。中間ノード１３２および第１の計算ノード１４０は、「非武装地帯」１６０（すなわち、会社のプライベートネットワークとパブリックネットワークとの間に配置されるネットワーク領域）内に置くことができ、同様に破線で示される第１のファイアウォール１５６および第２のファイアウォール１６４によってシステム５００の他の部分から切り離される。次いで、図に示すように、ネットワーク１０４’、第１のプロトコルサービス１１２、ホストサービス１１６ａ乃至１１６ｎ、チケットオーソリティ１３６、および、第２の計算ノード１４４は、内部ネットワーク１６８を形成するが、第２のファイアウォール１６４によってシステム１００の他の部分から切り離される。
【００８０】
あるいは、別の実施態様では、図６Ｂを参照して、システム５００は、非武装地帯１６０内でネットワーク１０４と中間ノード１３２との間に配置される第３の計算ノード１４６をさらに含む。第３の計算ノード１４６は、ネットワーク化された通信が可能で本願明細書に開示した動作を行うには十分なプロセッサ能力とメモリ容量を有する、いずれのコンピュータとすることができる。下記のように、第３の計算ノード１４６は、一部の実施態様では、クライアント１０８のホストサービス１１６への最初の接続プロセス中、および／またはクライアント１０８のホストサービス１１６への再接続プロセス中に使用する。より具体的には、下記のように、システム５００が２つ以上の中間ノード１３２を含む際には、第３の計算ノード１４６は、例えばロードバランシング式に基づいて、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の通信が通過すべき中間ノード１３２を選択することができる。
【００８１】
さらに、図６Ｃを参照すると、図６Ｂの中間ノード１３２は、別の実施態様では、２つ以上のレベル「ａ」乃至「ｎ」の中間ノード１３２に置換することができる。図示するように、各レベル「ａ」乃至「ｎ」は、２つ以上の中間ノード１３２ａ乃至１３２ｎを含むことができる。下記のように、クライアント１０８のクライアントエージェント１２８は、例えばロードバランシング式に基づいて、中間ノード１３２のいずれの組合せを介して送ることができる。例えば、図示するように、クライアントエージェント１２８は、接続１２２を介して中間ノード１３２を介して送ることができる。当業者にとって容易に明らかなように、他の構成のシステム５００も可能である。
【００８２】
再び図６Ａを参照すると、一実施態様では、ウェブブラウザ１４８は、ネットワーク１０４を通じて第１の計算ノード１４０と通信を行うが、これ自身が第２の計算ノード１４４およびチケットオーソリティ１３６と接続する。より具体的には、第１の計算ノード１４０は、第２の計算ノード１４４およびチケットオーソリティ１３６のアドレスによって構成される。一実施態様では、下記にさらに説明するように、第１の計算ノード１４０は、クライアント１０８のウェブブラウザ１４８と、第２の計算ノード１４４と、チケットオーソリティ１３６との間の情報を中継し、それによってそれらの直接的な通信を防ぐように構成される。このような直接的な通信を防ぐことによって、第１の計算ノード１４０は、システム５００に更なるレベルのセキュリティを付加する。第１の計算ノード１４０は、中間ノード１３２のアドレス、または代わりに、２つ以上の中間ノード１３２のアドレスによって構成することもできる。
【００８３】
第２の計算ノード１４４は、その役割として、ホストサービス１１６上で実行するどのアプリケーションプログラムをクライアント１０８のユーザーが利用できるのかを判断するように構成される。すなわち、第２の計算ノード１４４は、ユーザーがアクセスを許可されたのはどのアプリケーションプログラムなのかを判断する。一実施態様では、ユーザーが自身の所望のアプリケーションプログラムを選択した後、さらに下記のように、第２の計算ノード１４４は、ロードバランシングのためにユーザーの所望のアプリケーションを実行するために、どのホストサービス１１６を使用するのかを判断するように構成される。第２の計算ノード１４４は、そのホストサービス１１６のアドレスを第１の計算ノード１４０に返す。第２の計算ノード１４４は、ロードバランシング式を使用して複数の第１のプロトコルサービス１１２の中からも選択される、第１のプロトコルサービス１１２のアドレスも第１の計算ノード１４０に返す。次に、第１の計算ノード１４０は、選択した第１のプロトコルサービス１１２および選択したホストサービス１１６のアドレスをチケットオーソリティ１３６に送信する。
【００８４】
チケットオーソリティ１３６は、その役割として、接続チケットを生成する。一実施態様では、チケットオーソリティ１３６は、クライアント１０８への送信に対する最初の接続チケットを第１の計算コード１４０に送信する。別の実施態様では、チケットオーソリティは、第１の再接続チケットを中間ノード１３２に送信する。
【００８５】
クライアント１０８をホストサービス１１６へ最初に接続するプロセス、およびチケットオーソリティ１３６と、第１の計算ノード１４０と、第２の計算ノード１４４と、その結果の第３の計算ノード１４６との役割を下記に説明する。
【００８６】
図７を参照して、図６Ａ乃至図６Ｃの例示的実施態様を使用したネットワーク通信のための方法６００の一実施態様を示す。ステップ６０４で、クライアント１０８は、例えば下記に示す方法７００を用いて、クライアント１０８を複数のホストサービス１１６に接続する。クライアント１０８の複数のホストサービス１１６への接続後、クライアント１０８およびホストサービス１１６は、第１のプロトコルサービス１１２を介して、およびステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して通信を行う。一実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケットの送信前に、通信を第１のプロトコル２０４のレベルで暗号化し、それによって通信を保護する。別の実施態様では、第１のプロトコルサービス１１２は、いずれの第１のプロトコルパケットの送信前に、通信を第１のプロトコル２０４のレベルで圧縮し、それによって通信効率を改善する。
【００８７】
ステップ６１２で、クライアントエージェント１２８は、クライアントエージェント１２８と第１のプロトコルサービス１１２との間の接続１２０が失敗したかどうかを判断する。例えば、クライアントエージェント１２８と中間ノード１３２との間の接続１２０ａが失敗した、中間ノード１３２と第１のプロトコルサービス１１２との間の接続１２０ｂが失敗した、あるいは接続１２０ａおよび１２０ｂの両方が失敗したという可能性がある。クライアントエージェント１２８が、接続１２０は失敗しなかったと判断した場合は、方法６００はステップ６２０へ進む。一方で、クライアントエージェント１２８が、接続１２０は失敗したと判断した場合は、ステップ６１６で、クライアント１０８にホストサービス１１６への信頼できる接続を提供し、ホストサービス１１６に再接続する。
【００８８】
ステップ６２０では、クライアント１０８がプロトコルサービス１１２との接続１２０を、そして結果的にホストサービス１１６との接続１２４ａ乃至１２４ｎを完全に完了することを望んでいるかどうかを判断する。望んでいない場合には、ステップ６０８で、第１のプロトコル内にカプセル化された複数の第２のプロトコルを介して、クライアント１０８と第１のプロトコルサービス１１２との間の通信を継続する。望んでいる場合は、次いでステップ６２４で、すべての接続１２０ａ、１２０ｂ、および１２４ａ乃至１２４ｎを中断し、すべての再接続チケットを削除する。一実施態様では、中間ノード１３２は、チケットオーソリティ１３６から受信したハンドルを使用して、チケットオーソリティ１３６に保存された第１の再接続チケットのコピーを削除する。別の実施態様では、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２に保存された第２の再接続チケットのコピーを削除する。
【００８９】
更なる実施態様では、何らかの理由で第２のプロトコル接続１２４が失敗した場合、関連する第１のプロトコルサービス１１２で保存された第２の再接続チケットのコピーを第１のプロトコルサービス１１２によって削除する。さらに別の実施態様では、第１の再接続チケットおよび／または第２の再接続チケットは、ステップ６１２でのように、接続１２０における失敗に続いて、および／またはステップ６２０でのように、接続１２０の完全な終了に続いて、所定の時間の経過後に自動的に削除される。
【００９０】
図８Ａ乃至８Ｃを参照して、図６Ａ乃至図６Ｃの例示的実施態様を使用してクライアント１０８のホストサービス１１６への最初の接続（例えば、図７のステップ６０４で）のための方法７００の一実施態様を示す。
【００９１】
ステップ７０４で、クライアント１０８は、ブラウザ１４８を使用して、例えばＨＴＴＰリクエストなどのような、リクエストを第１の計算ノード１４０に送信する。第１の計算ノード１４０は、認証情報（例えば、ユーザー名およびパスワード）を要求する、例えばＨＴＭＬフォームなどのようなウェブページを返す。クライアント１０８のユーザーは、自分の認証を入力して完了したフォームを第１の計算ノード１４０に送信する。
【００９２】
ステップ７０８で、第１の計算ノード１４０は、次いでクライアント１０８のユーザーに実行可能なアプリケーションを通知する。一実施態様では、第１の計算ノード１４０は、ユーザーの認証をログインページから取り出し、第２の計算ノード１４４に対しユーザーが利用可能なアプリケーションを列挙するよう求める要求とともに、その認証を第２の計算ノード１４４に送信する。ユーザーの認証に基づいて、第２の計算ノード１４４は、ユーザーが利用可能な特定のアプリケーションのリストを第１の計算ノード１４０に返し、次いでそのリストは、例えばウェブページの形態で、クライアント１０８のユーザーに転送される。
【００９３】
ステップ７１２で、ユーザーは、所望のアプリケーションと、そのアプリケーションを第１の計算ノード１４０に送信する要求を選択する。例えば、一実施態様では、ユーザーは、第１の計算ノード１４０がユーザーに示すウェブページにリストされた所望のアプリケーションと、そのアプリケーションを第１の計算ノード１４０に転送するＨＴＴＰ要求をクリックする。その要求は、第１の計算ノード１４０によって処理され、第２の計算ノード１４４に転送される。
【００９４】
ステップ７１６で、第２の計算ノード１４４は、要求したアプリケーションを実行するホストサービス１１６を判断する。第２の計算ノード１４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。一実施態様では、第２の計算ノード１４４は、接続１２４を介してホストサービス１１６と通信を行うために使用する複数の第１のプロトコルサービス１１２の中から第１のプロトコルサービス１１２も判断する。また、第２の計算ノード１４４は、例えば、ロードバランシング式に基づいてその決定を行うことができる。第２の計算ノード１４４は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを第１の計算ノード１４０に返す。
【００９５】
ステップ７２０で、クライアント１０８には、次いで最初の接続チケットと、中間ノード１３２（下記のように、その実際のアドレスか、またはその仮想アドレスである）のためのアドレスが提供される。一実施態様では、第１の計算ノード１４０は、最初の接続チケットの要求とともに、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスをチケットオーソリティ１３６に提供する。チケットオーソリティ１３６は、選択したホストサービス１１６および選択した第１のプロトコルサービス１１２のアドレスを保存し、最初の接続チケットを生成し、この最初の接続チケットを第１の計算ノード１４０に送信しながら、自身のためのコピーを保存する。
【００９６】
一実施態様において中間ノード１３２の実際のアドレスによって構成される第１の計算ノード１４０は、次いで中間ノード１３２の実際のアドレスおよび最初の接続チケットをクライアント１０８のブラウザ１４８に送信する。第１の計算ノード１４０は、例えば、中間ノード１３２の実際のアドレスおよび最初の接続チケットを含むファイルをまず作成し、次いでそのファイルをクライアント１０８のブラウザ１４８に送信することができる。あるいは、別の実施態様では、第１の計算ノード１４０は、２つ以上の中間ノード１３２の実際のアドレスによって構成される。このような実施態様では、第１の計算ノード１４０は、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード１３２を判断する。第１の計算ノード１４０は、次いでその選択した中間ノード１３２の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１４８に送信する。一実施態様では、第１の計算ノード１４０は、ロードバランシング式を使用して中間ノード１３２を選択する。次いでクライアント１０８のクライアントエージェント１２８が起動され、中間ノード１３２のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と中間ノード１３２との間の第１のプロトコル接続１２０ａを確立する。
【００９７】
あるいは、別の実施態様では、第１の計算ノード１４０は、中間ノード１３２の仮想アドレスとしての機能を果たす第３の計算ノード１４６の実際のアドレスによって構成される。このような実施態様では、ステップ７２０で、第１の計算ノード１４０は、第３の計算ノード１４６の実際のアドレスおよび最初の接続チケットを、例えば、上述のファイルを使用して、クライアント１０８のブラウザ１４８に送信する。次いでクライアント１０８のクライアントエージェント１２８が起動され、第３の計算ノード１４６の実際のアドレスを使用して、ステップ７２４で、クライアント１０８のクライアントエージェント１２８と第３の計算ノード１４６との間の第１のプロトコル接続を確立する。第３の計算ノード１４６は、次いで、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード１３２を判断する。一実施態様では、第３の計算ノード１４６は、ロードバランシング式を使用して中間ノード１３２を選択する。中間ノード１３２を選択すると、第３の計算ノード１４６は、中間ノード１３２に対する第１のプロトコル接続を確立する。その結果、第３の計算ノード１４６を介して、第１のプロトコル接続１２０ａが、クライアント１０８のクライアントエージェント１２８と中間ノード１３２との間に存在する。したがって、第３の計算ノード１４６の実際のアドレスは、中間ノード１３２の実際のアドレスにマップされる。その結果、クライアント１０８のクライアントエージェント１２８に対して、第３の計算ノード１４６の実際のアドレスが中間ノード１３２の仮想アドレスとしての機能を果たす。
【００９８】
一実施態様では、複数のレベルの中間ノード１３２が存在する際には、上述のように、第１の計算ノード１４０または第３の計算ノード１４６中間ノード１３２はそれぞれ、クライアントエージェント１２８がレベル「ａ」で接続する中間ノード１３２だけを選択する。このような実施態様では、各々のレベル「ａ」乃至「ｎ−１」で、クライアントエージェント１２８がレベルで送られる中間ノード１３２は、その後、例えばロードバランシング式に基づいて、次のレベルで接続する中間ノード１３２を判断する。あるいは、他の実施態様では、第１の計算ノード１４０または第３の計算ノード１４６はそれぞれ、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、クライアントエージェント１２８が送られる中間ノード１３２を選択する。
【００９９】
クライアント１０８のクライアントエージェント１２８と中間ノード１３２との間の第１のプロトコル接続１２０ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法７００において中間ノード１３２と称する）を確立すると、次いでクライアントエージェント１２８は、最初の接続チケットを中間ノード１３２に送信する。
【０１００】
次いで、ステップ７２８で、最初の接続チケットが有効かどうかを判断する。一実施態様では、中間ノード１３２は、検証のために最初の接続チケットをチケットオーソリティ１３６に送信する。一実施態様では、チケットオーソリティ１３６は、ステップ７２０で保存した最初の接続チケットのコピーと比較することによって、最初の接続チケットの有効性を判断する。チケットオーソリティ１３６が最初の接続チケットを有効であると判断した場合、ステップ７３２で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスおよび選択したホストサービス１１６のアドレスを中間ノード１３２に送信する。第１のプロトコルサービス１１２は、最初の接続チケットおよびそのコピーを削除することもできる。一方で、チケットオーソリティ１３６が最初の接続チケットを無効であると判断した場合、ステップ７３０で、クライアント１０８は、第１のプロトコルサービス１１２への接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１０１】
ステップ７３２に続いて、中間ノード１３２は、選択した第１のプロトコルサービス１１２のアドレスを使用して、ステップ７３６で、中間ノード１３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１２０ｂを確立する。したがってここでは、中間ノード１３２を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に、第１のプロトコル接続１２０が存在する。中間ノード１３２は、選択したホストサービス１１６のアドレスを第１のプロトコルサービス１１２に渡すこともできる。
【０１０２】
一実施態様では、ステップ７４０で、第１のプロトコルサービス１１２は、選択したホストサービス１１６のアドレスを使用して、第１のプロトコルサービス１１２と選択したホストサービス１１６との間の第２のプロトコル接続１２４を確立する。例えば、選択したホストサービス１１６は実際にホストサービス１１６ａであり、第２のプロトコル接続１２４ａが第１のプロトコルサービス１１２とホストサービス１１６ａとの間に確立される。
【０１０３】
一実施態様では、ステップ７４０に続いてステップ７４４で、ユーザーは実行する第２のアプリケーションを選択し、ステップ７４８で、第２の計算ノード１４４は第２のアプリケーションが実行されるホストサービス１１６を判断する。例えば、ロードバランシング式を計算することによって、第２の計算ノード１４４は、第２のアプリケーションプログラムを実行するためにホストサービス１１６ｂを選択することが可能である。第２の計算ノード１４４は、次いで選択したホストサービス１１６ｂのアドレスを第１のプロトコルサービス１１２に送信する。一実施態様では、第２の計算ノード１４４は、第１のプロトコルサービス１１２をによる直接的な通信状態にあり、そこにアドレスを直接送信する。別の実施態様では、選択したホストサービス１１６ｂのアドレスは、第１のプロトコルサービス１１２に間接的に送信される。例えば、第１の計算ノード１４０、チケットオーソリティ１３６、中間ノード１３２、および第１のプロトコルサービス１１２のいずれの組合せを介して第１のプロトコルサービス１１２にアドレスを送信することができる。選択したホストサービス１１６ｂのアドレスを受信すると、第１のプロトコルサービス１１２は、ステップ７５２で、第１のプロトコルサービス１１２と選択したホストサービス１１６ｂとの間の第２のプロトコル接続１２４ｂを確立する。
【０１０４】
接続１２４ａおよび１２４ｂを通じて通信を行うために使用できる第２のプロトコルには、限定されないが、ＨＴＴＰ、ＦＴＰ、Ｏｓｃａｒ、Ｔｅｌｎｅｔ、ＩＣＡ、および、ＲＤＰを含む。さらに、一実施態様では、上述のように、少なくとも１つの第２のプロトコルは、複数の仮想チャネルを含むが、それぞれリモートクライアント１０８での機能を可能にする複数のプロトコルパケットを含むことができる。例えば、一実施態様では、一方のホストサービス１１６ａはウェブサーバであり、ＨＴＴＰプロトコルを使用して接続１２４ａを通じて第１のプロトコルサービス１１２と通信を行い、他方のホストサービス１１６ｂはアプリケーションサーバであり、ＩＣＡプロトコルを使用して接続１２４ｂを通じて第１のプロトコルサービス１１２と通信を行う。ホストサービス１１６ｂは、クライアント１０８にグラフィカルユーザーインターフェイスを表示させるグラフィックスクリーンコマンドをクライアント１０８に送信するためのプロトコルパケット、およびクライアント１０８で文書を印刷させるプリンタコマンドをクライアント１０８に送信するためのプロトコルパケットの両方を生成する。
【０１０５】
ステップ７４４、７４８、および７５２は、複数回繰り返すことができる。このように、複数のアプリケーションプログラムを複数のホストサービス１１６ａ乃至１１６ｎ上で実行することができ、その出力は、複数の第２のプロトコルを使用して接続１２４ａ乃至１２４ｎを通じて第１のプロトコルサービス１１２へ通信を行うことができる。ステップ７５６では、第１のプロトコルサービス１１２は、上述のように、第１のプロトコル内に複数の第２のプロトコルをカプセル化することができる。このように、クライアント１０８は、複数のホストサービス１１６に接続され、同時にそれらと通信を行う。
【０１０６】
別の実施態様では、ステップ７４４、７４８、および７５２を行う前に、例えば、ホストサービス１１６ｂなどのようなホストサービス１１６上で新しいアプリケーションプログラムを実行するために、クライアント１０８のユーザーは、例えば、ホストサービス１１６ａ上で実行しているアプリケーションプログラムなどのような、別のアプリケーションプログラムの実行を終了する。そのような場合、第１のプロトコルサービス１１２は、第１のプロトコルサービス１１２とホストサービス１１６ａとの間の接続１２４ａを中断させる。次いで第１のプロトコルサービス１１２は、ステップ７４４、７４８、および７５２を実行して、クライアント１０８と第１のプロトコルサービス１１２との間の接続１２０を中断せずに、第１のプロトコルサービス１１２とホストサービス１１６ｂとの間の接続１２４ｂを確立する。
【０１０７】
一実施態様では、第１の再接続チケットは、ステップ７６０で生成される。例えば、中間ノード１３２は、チケットオーソリティ１３６から第１の再接続チケットを要求する。その要求を受信すると、チケットオーソリティ１３６は、例えば大きな乱数である第１の再接続チケットを生成し、例えばより小さな乱数であるハンドルも生成することができる。次いでチケットオーソリティ１３６は、ステップ７６４で、第１の再接続チケットおよびハンドルを中間ノード１３２に送信し、一方で、第１の再接続チケットのコピーおよびハンドルのコピーを保存することができる。チケットオーソリティ１３６は、ステップ７２０で第１の計算ノード１４０によってそこに送信された第１のプロトコルサービス１１２のアドレスの維持を継続する。次いで中間ノード１３２は、ステップ７６８で、第１の再接続チケットをクライアント１０８に送信する。
【０１０８】
ステップ７７２では、次いで第２の再接続チケットを生成する。一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうる第２の再接続チケットを生成する。次いで第１のプロトコルサービス１１２は、ステップ７７６で、中間ノード１３２を介して第２の再接続チケットをクライアント１０８に送信する。この際、第１のプロトコルサービス１１２は、接続１２０の中断に続いて再接続されるセッションを識別するために、第２の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。一実施態様では、例えば、第１のプロトコルサービス１１２は、特定のセッション番号に対して、そのセッション番号に関連する第２のプロトコル接続１２４ａ乃至１２４ｎをリストしたテーブルを維持する。したがって、第１のプロトコルサービス１１２での第１のプロトコル接続１２０の再確立および第２の再接続チケットの検証に続けて、下記のように、第１のプロトコルサービス１１２は、クライアント１０８への通信のために、再確立された第１のプロトコル接続１２０内にカプセル化された第２のプロトコル接続１２４を識別することができる。
【０１０９】
あるいは、別の実施態様では、再度図１Ａを参照すると、本発明のシステム１００は中間ノード１３２、チケットオーソリティ１３６、第３の計算ノード１４６のいずれも含まない。このような実施態様では、ステップ７６０乃至７７６では、第１および第２の再接続チケットの両方を生成および送信するのではなく、システム１００および方法７００は、単一の再接続チケットだけを提供する。このような一実施態様では、第１のプロトコルサービス１１２は、例えば大きな乱数となりうる単一の再接続チケットを生成する。第１のプロトコルサービス１１２は、次いで単一の再接続チケットを接続１２０を通じてクライアント１０８に直接送信する。この際、第１のプロトコルサービス１１２は、接続１２０の中断に続いて再接続されるセッションを識別するために、単一の再接続チケットのコピーおよびそれらに関連するセッション番号を保存する。
【０１１０】
以下、図９を参照して、図６Ａ乃至６Ｃの例示的実施態様を使用した、（例えば、図７のステップ６１６で）クライアント１０８に１つ以上のホストサービス１１６への信頼できる接続を提供し、クライアント１０８をホストサービス１１６へ再接続する方法８００の一実施態様を示す。特に、ステップ８０４で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間の第２のプロトコル接続１２４を維持する。さらに、ステップ８０８で、例えば、図７のステップ６１６で中断していると判断された接続１２０を介して、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間の直近に送信されたデータパケットのキューを維持する。一実施態様では、データパケットは、接続１２０の前でも失敗時でもキューに入れられ維持される。キューに入れたデータパケットは、例えば、クライアントエージェント１２８によってバッファ内に維持することができる。あるいは、第１のプロトコルサービス１１２は、キューに入れたデータパケットをバッファ内に維持することができる。さらに別の実施態様では、クライアントエージェント１２８および第１のプロトコルサービス１１２のどちらも、キューに入れたデータパケットをバッファ内に維持する。
【０１１１】
ステップ８１２で、新しい第１のプロトコル接続１２０が、クライアント１０８のクライアントエージェント１２８と第１のプロトコルサービス１１２との間に確立され、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされ、それによって、クライアント１０８をホストサービス１１６に再接続する。クライアント１０８の再接続後、ステップ８０８で維持されたキューに入れたデータパケットは、ステップ８１６で、新しく確立された第１のプロトコル接続１２０を介して送信することができる。このように、ホストサービス１１６とクライアント１０８との間の通信セッションは、第１のプロトコルサービス１１２を介して、いずれのデータも失わずに持続的に進められる。
【０１１２】
以下、図１０Ａおよび１０Ｂを参照して、図６Ａ乃至６Ｃの例示的実施態様を使用した、（例えば、図９のステップ８１２で）クライアント１０８を１つ以上のホストサービス１１６へ再接続する方法９００の一実施態様を示す。
【０１１３】
ステップ９０４で、クライアント１０８と第１のプロトコルサービス１１２との間のうちの残りの接続を中断する。例えば、接続１２０ａは失敗したが、接続１２０ｂは失敗していない場合、接続１２０ｂを中断する。あるいは、接続１２０ｂは失敗したが、接続１２０ａは失敗していない場合、接続１２０ａを中断する。
【０１１４】
一実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した中間ノード１３２の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と中間ノード１３２との間の第１のプロトコル接続１２０ａを再確立する。あるいは、別の実施態様では、例えば、図８のステップ７２０で、クライアント１０８に提供した第３の計算ノード１４６の実際のアドレスを使用して、ステップ９０８で、クライアント１０８のクライアントエージェント１２８は、次いでクライアントエージェント１２８と第３の計算ノード１４６との間の第１のプロトコル接続を再確立する。第３の計算ノード１４６は、クライアント１０８と第１のプロトコルサービス１１２との間のメッセージが通過すべき中間ノード１３２を判断する。一実施態様では、第３の計算ノード１４６は、ロードバランシング式を使用して中間ノード１３２を選択する。クライアント１０８のいつ以上のホストサービス１１６への再接続において、第３の計算ノード１４６によって選択された中間ノード１３２は、例えば、図８のステップ７２０で、クライアント１０８を１つ以上のホストサービス１１６に最初に接続するために、その選択とは異なることができる。中間ノード１３２を選択すると、第３の計算ノード１４６は、中間ノード１３２への第１のプロトコル接続を再確立する。したがって、第１のプロトコル接続１２０ａは、第３の計算ノード１４６を介して、クライアント１０８のクライアントエージェント１２８と中間ノード１３２との間で再確立される。
【０１１５】
一実施態様では、複数のレベルの中間ノード１３２が存在する場合、クライアントエージェント１２８がレベル「ａ」乃至「ｎ−１」で送られる中間ノード１３２は、例えばロードバランシング式に基づいて、次のレベルで接続される中間ノード１３２を判断する。あるいは、別の実施態様では、第３の計算ノード１４６は、複数またはすべてのレベル「ａ」乃至「ｎ」に対して、クライアントエージェント１２８が送られる中間ノード１３２を判断する。
【０１１６】
クライアント１０８のクライアントエージェント１２８と中間ノード１３２との間の第１のプロトコル接続１２０ａ、例えば、レベル「ｎ」の中間ノード１３２（以下、方法９００において中間ノード１３２と称する）を確立すると、次いでクライアントエージェント１２８は、ステップ９１２で、第１の再接続チケットおよび第２の再接続チケットを中間ノード１３２に送信する。
【０１１７】
次いで、ステップ９１６で、第１の再接続チケットが有効かどうかを判断する。一実施態様では、第１の再接続チケットの有効性は、チケットオーソリティ１３６を使用することによって判断される。例えば、中間ノード１３２は、第１の再接続チケットをチケットオーソリティ１３６に送信する。一実施態様では、チケットオーソリティ１３６は、第１の再接続チケットの有効性を、以前に保存した第１の再接続チケットのコピーと比較することによって判断する。チケットオーソリティ１３６が第１の再接続チケットを有効であると判断した場合、ステップ９２０で、チケットオーソリティ１３６は、第１のプロトコルサービス１１２のアドレスを中間ノード１３２に送信する。あるいは、チケットオーソリティ１３６が第１の再接続チケットを無効であると判断した場合、ステップ９２４で、クライアント１０８は、第１のプロトコルサービス１１２への再接続を拒否し、結果的に、ホストサービス１１６に接続する。
【０１１８】
ステップ９２８で、第１の再接続チケットは、例えばチケットオーソリティ１３６によって削除され、代替の第１の再接続チケットが、例えばチケットオーソリティ１３６により生成される。さらに、代替のハンドルが、例えばチケットオーソリティ１３６により生成されることができる。一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットおよび代替のハンドルを中間ノード１３２に送信する。さらに、一部のこのような実施態様では、チケットオーソリティ１３６は、代替の第１の再接続チケットのコピーを保存する。一部の実施態様では、チケットオーソリティ１３６は、クライアント１０８が第１の再接続チケットの削除に進む前に代替の第１の再接続を受信したことを認識するまで待つ。
【０１１９】
第１の再接続チケットの検証後、中間ノード１３２は、第１のプロトコルサービス１１２のアドレスを使用して、ステップ９３２で、中間ノード１３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１２０ｂを再確立する。中間ノード１３２と第１のプロトコルサービス１１２との間の第１のプロトコル接続１２０ｂを再確立すると、次いでステップ９３６で、第２の再接続チケットが有効かどうかを判断する。一実施態様では、第２の再接続チケットの有効性は、第１のプロトコルサービス１１２を使用することによって判断する。例えば、中間ノード１３２は、第２の再接続チケットを第１のプロトコルサービス１１２に送信する。一実施態様では、第１のプロトコルサービス１１２は、第２の再接続チケットの有効性を、以前に保存した第２の再接続チケットのコピーと比較することによって判断する。第１のプロトコルサービス１１２が第２の再接続チケットを有効であると判断した場合、第１の中間ノード１３２と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１２０ｂは、ステップ９４０で、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされる。あるいは、第１のプロトコルサービス１１２が第２の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１２０ｂは、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、ステップ９４４で、１つ以上のホストサービス１１６への再接続を拒否する。
【０１２０】
ステップ９４８で、第２の再接続チケットは、例えば第１のプロトコルサービス１１２によって削除され、代替の第２の再接続チケットが、クライアント１０８への送信のために、例えば第１のプロトコルサービス１１２により生成される。このような実施態様では、第１のプロトコルサービス１１２は、代替の第２の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が第２の再接続チケットの削除に進む前に代替の第２の再接続を受信したことを認識するまで待つ。
【０１２１】
ステップ９５２で、代替の第１の再接続チケットおよび代替の第２の再接続チケットは、クライアントに送信される。例えば、チケットオーソリティ１３６は、中間ノード１３２を介して、代替の第１の再接続チケットをクライアント１０８に送信することができる。さらに、一実施態様では、第１のプロトコルサービス１１２は、中間ノード１３２を介して、代替の第２の再接続チケットをクライアント１０８に送信する
あるいは、他の実施態様では、上述のように、本発明のシステム１００および方法は、単一の再接続チケットだけを提供する。このように、第１および第２の再接続チケットを使用するのではなく、本発明の方法９００は、上述の単一の再接続チケットだけを使用する。このような一実施態様では、クライアント１０８のクライアントエージェント１２８には、第１のプロトコルサービス１１２のアドレスも提供される。ホストサービス１１６に再接続するために、クライアントエージェント１２８は、単一の再接続チケットを第１のプロトコルサービス１１２に直接送信する。第１のプロトコルサービス１１２は、次いで単一の再接続チケットが有効であるかどうかを判断する。一実施態様では、第１のプロトコルサービス１１２は、単一の再接続チケットの有効性を、以前に保存した単一の再接続チケットのコピーと比較することによって判断する。第１のプロトコルサービス１１２が単一の再接続チケットを有効であると判断した場合、クライアント１０８と第１のプロトコルサービス１１２との間で再確立された第１のプロトコル接続１２０は、第１のプロトコルサービス１１２と１つ以上のホストサービス１１６のそれぞれとの間で維持された第２のプロトコル接続１２４にリンクされる。あるいは、第１のプロトコルサービス１１２が第２の再接続チケットを無効であると判断した場合、再確立された第１のプロトコル接続１２０は、１つ以上の維持された第２のプロトコル接続１２４にはリンクされず、クライアント１０８は、１つ以上のホストサービス１１６への再接続を拒否する。
【０１２２】
単一の再接続チケットの検証後、単一の再接続チケットは、例えば第１のプロトコルサービス１１２によって削除され、代替の単一の再接続チケットが、クライアント１０８への送信のために、例えば第１のプロトコルサービス１１２により生成される。代替の単一の再接続チケットのクライアント１０８への送信では、第１のプロトコルサービス１１２は、代替の単一の再接続チケットのコピーを保存する。一部の実施態様では、第１のプロトコルサービス１１２は、クライアント１０８が単一の再接続チケットの削除に進む前に代替の単一の再接続を受信したことを認識するまで待つ。
【０１２３】
さらに別の実施態様では、第１および第２の再接続チケットと同様に、単一の再接続チケットは、ステップ６１２でのように、接続１２０における失敗に続いて、および／またはステップ６２０でのように、接続１２０の完全な終了に続いて、所定の時間の経過後に自動的に削除されるように構成される。
【０１２４】
当業者であれば、本発明の趣旨および範囲から逸脱することのない、本願明細書に開示された発明の変形、改良、および他の実施態様を見出すであろう。本発明は、上記の例示的説明のみによって定義されるものではない。
【図面の簡単な説明】
【０１２５】
上述の本発明の他の目的、局面、特徴、および利点は、添付図面とともに以下の説明を参照することによって、より明らかになり、よりよく理解されるであろう。
【図１Ａ】本発明の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図１Ｂ】本発明の別の実施態様による、クライアントにホストサービスへの信頼できる接続を提供するシステムのブロック図である。
【図２】本発明の実施態様によるネットワークを通じて行われる通信を示す。
【図３】本発明の他の実施態様によるネットワークを通じて行われる通信を示す。
【図４】本発明の実施態様によるネットワークを通じた通信のために第１のプロトコル内に複数の第２のプロトコルをカプセル化するプロセスを示す。
【図５】本発明の実施態様によるクライアントのホストサービスへの再接続のためのコンポーネントをさらに含む図１の例示的システムのブロック図である。
【図６Ａ】本発明の実施態様によるクライアントのホストサービスへの最初の接続のためのコンポーネントをさらに含む図５の例示的システムのブロック図である。
【図６Ｂ】本発明の実施態様によるクライアントのホストサービスへの最初の接続、およびクライアントのホストサービスへの再接続のためのコンポーネントをさらに含む図６Ａの例示的システムのブロック図である。
【図６Ｃ】図６Ｂのシステムの別の実施態様のブロック図である。
【図７】本発明の実施態様によるネットワーク通信方法の流れ図である。
【図８Ａ】本発明の実施態様によるクライアントの複数のホストサービスへの接続方法の流れ図である。
【図８Ｂ】本発明の実施態様によるクライアントの複数のホストサービスへの接続方法の流れ図である。
【図８Ｃ】本発明の実施態様によるクライアントの複数のホストサービスへの接続方法の流れ図である。
【図９】本発明の実施態様によるクライアントにホストサービスへの信頼できる接続を提供する方法、およびクライアントのホストサービスへの再接続方法の流れ図である。
【図１０Ａ】本発明の実施態様によるクライアントのホストサービスへの再接続方法の流れ図である。
【図１０Ｂ】本発明の実施態様によるクライアントのホストサービスへの再接続方法の流れ図である。
【図１Ａ】
2007509521.tif 000003
【図１Ｂ】
2007509521.tif 000004
【図２】
2007509521.tif 000005
【図３】
2007509521.tif 000006
【図４】
2007509521.tif 000007
【図５】
2007509521.tif 000008
【図６Ａ】
2007509521.tif 000009
【図６Ｂ】
2007509521.tif 000010
【図６Ｃ】
2007509521.tif 000011
【図７】
2007509521.tif 000012
【図８Ａ】
2007509521.tif 000013
【図８Ｂ】
2007509521.tif 000014
【図８Ｃ】
2007509521.tif 000015
【図９】
2007509521.tif 000016
【図１０Ａ】
2007509521.tif 000017
【図１０Ｂ】
2007509521.tif 000018
【国際調査報告】
2007509521.tif 000019
2007509521.tif 000020
2007509521.tif 000021