(57)【要約】本発明は、概して、ピアツーピア通信およびリモートアクセス接続性を提供するためのリモートアクセスアーキテクチャに関する。一実施態様では、本発明のリモートアクセスアーキテクチャは、ゲートウェイのような第３のコンピューティングデバイスを介して、ピアコンピューティングデバイス間の直接接続を確立するための方法を提供する。加えて、本発明は、ピアツーピア通信を最適化するために、たとえば、以下の技術を提供する。１）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットの受信の疑似確認応答。２）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットのペイロードシフティング。
2008507928.tif 000002
【特許請求の範囲】
【請求項１】
第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するための方法であって、前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であり、前記方法は、
（ａ）前記第１のコンピューティングデバイスによって、第３のコンピューティングデバイスとの第１のトンネリングセッションを確立し、前記第２のコンピューティングデバイスによって、前記第３のコンピューティングデバイスとの第２のトンネリングセッションを確立するステップと、
（ｂ）前記第１のコンピューティングデバイスによって、前記第３のコンピューティングデバイスを介して、前記第２のコンピューティングデバイスへの通信セッションを開始するステップと、
（ｃ）サーバーによって、前記通信セッションを確立するために信号を受信するステップと、
（ｄ）前記サーバーによって、前記第１のコンピューティングデバイスに、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを含む、第１のネットワークアドレスを通信するステップと、
（ｅ）前記第１のコンピューティングデバイスによって、前記第１のネットワークアドレスを使用して前記第２のコンピューティングデバイスとの接続を開始するために、リクエストを通信するステップと、
（ｆ）前記第３のコンピューティングデバイスによって、前記リクエストをインターセプトして、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供するステップであって、前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを含む、ステップと、
（ｇ）前記第３のコンピューティングデバイスによって、前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスからの接続を可能にするために、前記第２のコンピューティングデバイスにリクエストを通信するステップと、を含む方法。
【請求項２】
前記第１のトンネリングセッションまたは前記第２のトンネリングセッションのうちの１つの少なくとも一部は、セキュアソケットレイヤーまたは仮想プライベートネットワークのうちの１つを含む、請求項１に記載の方法。
【請求項３】
前記第３のコンピューティングデバイスは、リモートアクセスゲートウェイを含む、請求項１に記載の方法。
【請求項４】
前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する、請求項１に記載の方法。
【請求項５】
前記第３のコンピューティングデバイスによって、前記第１のトンネリングセッションを介して、前記第１のコンピューティングデバイスに帯域外の信号を通信することにより、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供するステップを含む、請求項１に記載の方法。
【請求項６】
前記第２のコンピューティングデバイスによって、前記第２のネットワークアドレスを使用して前記第２のコンピューティングデバイスへ通信するために、前記第１のコンピューティングデバイスにファイアウォール内のフォワードホールを提供するステップを含む、請求項１に記載の方法。
【請求項７】
前記第３のコンピューティングデバイスによって、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスに鍵を通信するステップを含む、請求項１に記載の方法。
【請求項８】
前記第１のコンピューティングデバイスによって、前記第２のコンピューティングデバイスに前記鍵を通信するステップを含む、請求項７に記載の方法。
【請求項９】
前記第１のコンピューティングデバイスによって、前記第２のコンピューティングデバイスにデータを送信する前に、前記第２のコンピューティングデバイスから受信した前記鍵が、前記第１のコンピューティングデバイスの鍵に一致することを確認するステップを含む、請求項８に記載の方法。
【請求項１０】
前記第２のコンピューティングデバイスによって、前記第１のコンピューティングデバイスに前記鍵を通信するステップを含む、請求項７に記載の方法。
【請求項１１】
前記第２のコンピューティングデバイスによって、前記第２のコンピューティングデバイスにデータを送信する前に、前記第１のコンピューティングデバイスから受信した前記鍵が、前記第２のコンピューティングデバイスの鍵に一致することを確認するステップを含む、請求項１０に記載の方法。
【請求項１２】
第１の通信デバイスを前記第１のコンピューティングデバイスに関連付け、第２の通信デバイスを前記第２のコンピューティングデバイスに関連付けるステップを含む、請求項１に記載の方法。
【請求項１３】
前記第１の通信デバイスまたは前記第２の通信デバイスのうちの１つは、ソフトウェアコンポーネントまたはハードウェアコンポーネントのうちの１つを備える、請求項１２に記載の方法。
【請求項１４】
前記接続を介して、前記第１の通信デバイスと前記第２の通信デバイスとの間の通信セッションを確立するステップを含む、請求項１２に記載の方法。
【請求項１５】
前記第１のコンピューティングデバイスにトラバースせずに、前記通信セッションを通じて、前記第１の通信デバイスと前記第２の通信デバイスとの間を通信するステップを含む、請求項１５に記載の方法。
【請求項１６】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の前記接続を介して、リモートディスプレイプロトコルを通信するステップを含む、請求項１に記載の方法。
【請求項１７】
リモートデスクトッププロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルのうちの１つを含む、請求項１６に記載の方法。
【請求項１８】
前記接続を介して、前記第１のコンピューティングデバイスのスクリーンビューを前記第２のコンピューティングデバイスと共有するステップを含む、請求項１に記載の方法。
【請求項１９】
ゲートウェイにおいて、第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するための方法であって、前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であり、前記方法は、
（ａ）第１のネットワーク上の前記第１のコンピューティングデバイスとの第１のトンネリングセッションを確立するステップと、
（ｂ）前記第２のネットワーク上の前記第２のコンピューティングデバイスとの第２のトンネリングセッションを確立するステップと、
（ｃ）前記第２のコンピューティングデバイスとの通信セッションを開始するために、前記第１のコンピューティングデバイスによってリクエストを受信するステップと、
（ｄ）前記第１のコンピューティングデバイスに、前記第２のコンピューティングデバイスと交信するための第１のネットワークアドレスを提供するステップであって、前記第１のネットワークアドレスは、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを含むステップと、
（ｅ）前記第１のネットワークアドレスを使用して、前記第２のコンピューティングデバイスとの接続を開始するために、前記第１のコンピューティングデバイスによってリクエストを受信するステップと、
（ｆ）前記接続を開始するために前記リクエストをインターセプトし、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供するステップであって、前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを含むステップと、
（ｇ）前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスから前記第２のコンピューティングデバイスへの接続を可能にするために、前記第２のコンピューティングデバイスにリクエストを通信するステップと、を含む方法。
【請求項２０】
前記第１のトンネリングセッションまたは前記第２のトンネリングセッションのうちの１つの少なくとも一部は、セキュアソケットレイヤーまたは仮想プライベートネットワークのうちの１つを含む、請求項１９に記載の方法。
【請求項２１】
前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する、請求項１９に記載の方法。
【請求項２２】
前記第１のトンネリングセッションを介して、前記第１のコンピューティングデバイスに帯域外の信号を通信することにより、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供するステップを含む、請求項１９に記載の方法。
【請求項２３】
前記第１のコンピューティングデバイスに鍵を通信するステップを含む、請求項１９に記載の方法。
【請求項２４】
前記第２のコンピューティングデバイスに鍵を通信するステップを含む、請求項１９に記載の方法。
【請求項２５】
第３のコンピューティングデバイスを介して、第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するためのシステムであって、前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であり、前記システムは、
前記第１のネットワーク上の第１のコンピューティングデバイスと、
前記第２のネットワーク上の第２のコンピューティングデバイスと、
前記第１のコンピューティングデバイスとの第１のトンネリングセッションおよび、前記第２のコンピューティングデバイスとの第２のトンネリングセッションを確立する第３のコンピューティングデバイスと、
前記第３のコンピューティングデバイスを介してアクセス可能なサーバーと、を備え、
前記サーバーは、前記第３のコンピューティングデバイスを介して、前記第１のコンピューティングデバイスに、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを含む、第１のネットワークアドレスを通信し、
前記第１のコンピューティングデバイスは、前記第１のネットワークアドレスを使用して前記第２のコンピューティングデバイスとの接続を開始するために、前記第３のコンピューティングデバイスを介して、第１のリクエストを通信し、
前記第３のコンピューティングデバイスは、前記第１のリクエストをインターセプトし、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供し、前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを含み、
前記第３のコンピューティングデバイスは、前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスからの接続を可能にするために、前記第２のコンピューティングデバイスに第２のリクエストを通信する、システム。
【請求項２６】
前記第１のトンネリングセッションまたは前記第２のトンネリングセッションのうちの１つの少なくとも一部は、セキュアソケットレイヤーまたは仮想プライベートネットワークのうちの１つを含む、請求項２５に記載のシステム。
【請求項２７】
前記第３のコンピューティングデバイスは、リモートアクセスゲートウェイを含む、請求項２５に記載のシステム。
【請求項２８】
前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する、請求項２５に記載のシステム。
【請求項２９】
前記第３のコンピューティングデバイスは、前記第１のトンネリングセッションを介して、帯域外の信号を通信することによって、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供する、請求項２５に記載のシステム。
【請求項３０】
前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスを使用して、前記第２のコンピューティングデバイスへ通信するために、前記第１のコンピューティングデバイスにファイアウォール内のフォワードホールを提供する、請求項２５に記載のシステム。
【請求項３１】
前記第３のコンピューティングデバイスは、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスに鍵を通信する、請求項２５に記載のシステム。
【請求項３２】
前記第１のコンピューティングデバイスは、前記第２のコンピューティングデバイスに前記鍵を通信する、請求項３１に記載のシステム。
【請求項３３】
前記第１のコンピューティングデバイスは、前記第２のコンピューティングデバイスにデータを送信する前に、前記第２のコンピューティングデバイスから受信した前記鍵が、前記第１のコンピューティングデバイスの鍵に一致することを確認する、請求項３２に記載のシステム。
【請求項３４】
前記第２のコンピューティングデバイスは、前記第１のコンピューティングデバイスに前記鍵を通信する、請求項３１に記載のシステム。
【請求項３５】
前記第２のコンピューティングデバイスは、前記第２のコンピューティングデバイスにデータを送信する前に、前記第１のコンピューティングデバイスから受信した前記鍵が、前記第２のコンピューティングデバイスの鍵に一致することを確認する、請求項３４に記載のシステム。
【請求項３６】
前記第１のコンピューティングデバイスに関連付けられた第１の通信デバイスと、前記第２のコンピューティングデバイスに関連付けられた第２の通信デバイスと、を備える、請求項２５に記載のシステム。
【請求項３７】
前記第１の通信デバイスまたは前記第２の通信デバイスのうちの１つは、ソフトウェアコンポーネントまたはハードウェアコンポーネントのうちの１つを備える、請求項３６に記載のシステム。
【請求項３８】
前記第１の通信デバイスは、前記接続を介して、前記第２の通信デバイスとの通信セッションを確立する、請求項３７に記載のシステム。
【請求項３９】
前記第１の通信デバイスは、前記第３のコンピューティングデバイスをトラバースせずに、前記通信セッションを通じて、前記第２の通信デバイスと通信する、請求項３８に記載のシステム。
【請求項４０】
前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスは、前記接続を介して、リモートディスプレイプロトコルを通信する、請求項２５に記載のシステム。
【請求項４１】
リモートデスクトッププロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルのうちの１つを含む、請求項２５に記載のシステム。
【請求項４２】
前記第１のコンピューティングデバイスは、前記接続を介して、スクリーンビューを前記第２のコンピューティングデバイスと共有する、請求項２５に記載のシステム。
【請求項４３】
第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するためのゲートウェイであって、前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であり、前記ゲートウェイは、
第１のネットワーク上の前記第１のコンピューティングデバイスとの第１のトンネリングセッションを確立するための手段と、
前記第２のネットワーク上の前記第２のコンピューティングデバイスとの第２のトンネリングセッションを確立するための手段と、
前記第２のコンピューティングデバイスとの通信セッションを開始するために、前記第１のコンピューティングデバイスによってリクエストを受信するための手段と、
前記第１のコンピューティングデバイスに、前記第２のコンピューティングデバイスと交信するための第１のネットワークアドレスを提供するための手段であって、前記第１のネットワークアドレスは、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを含む手段と、
前記第１のネットワークアドレスを使用して、前記第２のコンピューティングデバイスとの接続を開始するために、前記第１のコンピューティングデバイスによってリクエストを受信するための手段と、
前記接続を開始するために前記リクエストをインターセプトし、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供するための手段であって、前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを含む手段と、
前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスから前記第２のコンピューティングデバイスへの前記接続を可能にするために、前記第２のコンピューティングデバイスにリクエストを通信するための手段と、を備えるゲートウェイ。
【請求項４４】
前記第１のトンネリングセッションまたは前記第２のトンネリングセッションのうちの１つの少なくとも一部は、セキュアソケットレイヤーまたは仮想プライベートネットワークのうちの１つを含む、請求項４３に記載のシステム。
【請求項４５】
前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する、請求項４３に記載のシステム。
【請求項４６】
前記第１のトンネリングセッションを介して、前記第１のコンピューティングデバイスに帯域外の信号を通信することにより、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供するための手段を備える、請求項４３に記載のシステム。
【請求項４７】
前記第１のコンピューティングデバイスに鍵を通信するための手段を備える、請求項４３に記載のシステム。
【請求項４８】
前記第２のコンピューティングデバイスに鍵を通信するための手段を備える、請求項４３に記載のシステム。
【請求項４９】
不可逆プロトコルを介した送信のために構成されたパケットを可逆プロトコルを介して通信するための方法であって、
（ａ）可逆プロトコルを介して、第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間の接続を確立するステップと、
（ｂ）前記第１のコンピューティングデバイスによって、不可逆プロトコルに従って構成される１つ以上のパケットを有するペイロードを含む可逆プロトコルパケットを検出するステップと、
（ｃ）前記第１のコンピューティングデバイスによって、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つに、前記可逆プロトコルパケットの受信の擬似確認応答を通信するステップと、
（ｄ）前記第１のコンピューティングデバイスによって、前記第２のコンピューティングデバイスに、前記可逆プロトコルパケットを通信するステップと、を含む方法。
【請求項５０】
前記第１のコンピューティングデバイスによって、鍵を使用して前記１つ以上のパケットを暗号化するステップを含む、請求項４９に記載の方法。
【請求項５１】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の帯域外のトランスポートセキュリティレイヤーセッションを介して、前記第１のコンピューティングデバイスに、暗号鍵を提供するステップを含む、請求項５０に記載の方法。
【請求項５２】
パケット単位で前記１つ以上のパケットを暗号化するステップを含む、請求項４９に記載の方法。
【請求項５３】
ステップ（ｄ）の前に、ステップ（ｃ）を行うステップをさらに含む、請求項４９に記載の方法。
【請求項５４】
前記第２のコンピューティングデバイスは、ゲートウェイである、請求項４９に記載の方法。
【請求項５５】
前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つによる、前記可逆プロトコルパケットの受信の擬似確認応答の受信に応えて、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つのネットワークスタックが、前記可逆プロトコルの可逆特性の提供に関連するオペレーションを実行しないようにするステップを含む、請求項４９に記載の方法。
【請求項５６】
前記可逆プロトコルは、トランスポート制御プロトコルを含む、請求項４９に記載の方法。
【請求項５７】
前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つの前記ネットワークスタックが、前記可逆プロトコルとともに、再送信、順序付け、フロー制御アルゴリズム、Ｎａｐｌｅのアルゴリズム、およびスライディングウィンドウアルゴリズムのうちの１つ以上を実行しないようにするステップを含む、請求項５６に記載の方法。
【請求項５８】
前記不可逆プロトコルは、ユーザーデータグラムプロトコルを含む、請求項４９に記載の方法。
【請求項５９】
前記第１のコンピューティングデバイスによって、セキュアソケットレイヤーまたはトランスポートセキュリティレイヤートンネルのうちの１つを介して、前記第２のコンピューティングデバイスに、前記可逆プロトコルを通信するステップを含む、請求項４９に記載の方法。
【請求項６０】
前記１つ以上のパケットは、リアルタイムプロトコルを含む、請求項４９に記載の方法。
【請求項６１】
前記第１のコンピューティングデバイスによって、前記１つ以上のパケットを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータのうちの１つを通信するステップを含む、請求項４９に記載の方法。
【請求項６２】
不可逆プロトコルを介した送信のために構成されたパケットを可逆プロトコルを介して通信するためのシステムであって、
可逆プロトコルを介して、第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間の接続を確立するための手段と、
前記第１のコンピューティングデバイスによって、不可逆プロトコルに従って構成される１つ以上のパケットを有するペイロードを含む可逆プロトコルパケットを検出するための手段と、
前記第１のコンピューティングデバイスによって、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つに、前記可逆プロトコルパケットの受信の擬似確認応答を通信するための手段と、
前記第１のコンピューティングデバイスによって、前記第２のコンピューティングデバイスに、前記可逆プロトコルパケットを通信するための手段と、を備えるシステム。
【請求項６３】
前記第１のコンピューティングデバイスによって、鍵を使用して前記１つ以上のパケットを暗号化するための手段を備える、請求項６２に記載のシステム。
【請求項６４】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の帯域外のトランスポートセキュリティレイヤーセッションを介して、前記第１のコンピューティングデバイスに、暗号鍵を提供するための手段を備える、請求項６３に記載のシステム。
【請求項６５】
パケット単位で前記１つ以上のプロトコルパケットを暗号化するための手段を備える、請求項６３に記載のシステム。
【請求項６６】
前記可逆プロトコルパケットを通信する前に、前記可逆プロトコルパケットの受信の疑似確認応答を通信するための手段をさらに備える、請求項６２に記載のシステム。
【請求項６７】
前記第２のコンピューティングデバイスは、ゲートウェイである、請求項６２に記載のシステム。
【請求項６８】
前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つによって、前記可逆プロトコルパケットの受信の疑似確認応答の受信に応えて、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つのネットワークスタックが、前記可逆プロトコルの可逆特性の提供に関連するオペレーションを実行しないようにするための手段を備える、請求項６２に記載のシステム。
【請求項６９】
前記可逆プロトコルは、トランスポート制御プロトコルを含む、請求項６２に記載のシステム。
【請求項７０】
前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つの前記ネットワークスタックが、前記可逆プロトコルとともに、再送信、順序付け、およびフロー制御アルゴリズムのうちの１つ以上を実行しないようにするための手段を備える、請求項６９に記載のシステム。
【請求項７１】
前記不可逆プロトコルは、ユーザーデータグラムプロトコルを含む、請求項６２に記載のシステム。
【請求項７２】
前記第１のコンピューティングデバイスによって、セキュアソケットレイヤーまたはトランスポートセキュリティレイヤートンネルのうちの１つを介して、前記第２のコンピューティングデバイスに、前記可逆プロトコルを通信するための手段を備える、請求項６２に記載のシステム。
【請求項７３】
前記１つ以上のパケットは、リアルタイムプロトコルを含む、請求項６２に記載のシステム。
【請求項７４】
前記第１のコンピューティングデバイスによって、前記１つ以上のパケットを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータのうちの１つを通信するための手段を備える、請求項６２に記載のシステム。
【請求項７５】
ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するための方法であって、
第１のデバイスにおいて、信頼できないトランスポートプロトコルを使用して送信される第１のパケットを受信するステップと、
前記受信した第１のパケットの第１のペイロードを含む第１のＴＣＰパケットと、前記第１のデバイスと第２のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーと、を作成するステップと、
前記第１のデバイスによって、前記第２のデバイスに前記第１のＴＣＰパケットを送信するステップと、
前記第１のデバイスにおいて、信頼できないトランスポートプロトコルを使用して送信される第２のパケットを受信するステップと、
前記受信した第２のパケットの第２のペイロードを含む第２のＴＣＰパケットと、前記第１のＴＣＰヘッダー情報と、を作成するステップと、
前記第１のデバイスによって、前記第２のデバイスから前記第１のペイロードの受信の確認応答を受信する前に、前記第２のデバイスに前記第２のＴＣＰパケットを送信するステップと、を含む方法。
【請求項７６】
前記信頼できないトランスポートプロトコルに関連付けられたポート番号でＴＣＰ接続を確立するステップを含む、請求項７５に記載の方法。
【請求項７７】
前記第１のデバイスによって、前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットが、信頼できないトランスポートプロトコルを含むことを動的に判断するステップを含む、請求項７５に記載の方法。
【請求項７８】
前記信頼できないトランスポートプロトコルは、ＵＤＰである、請求項７５に記載の方法。
【請求項７９】
パケット取得機構を使用して、前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットをインターセプトすることによって、前記第１のデバイス上の前記前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットを受信するステップをさらに含む、請求項７５に記載の方法。
【請求項８０】
前記第１のデバイスによって、ＶＰＮゲートウェイデバイスとの前記ＴＣＰ接続を確立するステップを含む、請求項７５に記載の方法。
【請求項８１】
前記ＴＣＰ接続を介して、前記第１のデバイスと前記第２のデバイスとの間にピアツーピア通信を確立するステップを含む、請求項７５に記載の方法。
【請求項８２】
前記第１のデバイスによって、前記第１および第２のＴＣＰパケットを暗号化し、前記第２のデバイスによって、前記暗号化された第１および第２のＴＣＰパケットを解読するステップを含む、請求項７５に記載の方法。
【請求項８３】
ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するための方法であって、
第２のデバイスにおいて、第１のデバイス上に作成され、前記第２のデバイス上で受信する第１のＴＣＰパケットをインターセプトするステップであって、前記第１のＴＣＰパケットは、信頼できないプロトコルおよび前記第１のデバイスと前記第３のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーを使用したアプリケーションによって生成される第１のパケットの第１のペイロードを含み、前記インターセプトは、前記第１のＴＣＰパケットが前記第２のデバイス上のＴＣＰスタックに提供される前に生じる、ステップと、
前記情報のＴＣＰヘッダーに応答して、前記第１のペイロードが、信頼できないトランスポートプロトコルを使用したアプリケーションによって生成されたパケットであることを識別するステップと、
前記第１のＴＣＰパケットから前記情報のＴＣＰヘッダーを取り除くステップと、
前記信頼できないデータプロトコルを使用して、アプリケーションに前記第１のペイロードを転送するステップと、を含む方法。
【請求項８４】
前記信頼できないプロトコルは、ＵＤＰである、請求項８３に記載の方法。
【請求項８５】
前記識別するステップは、前記ＴＣＰヘッダー情報が、前記信頼できないトランスポートプロトコルに関連付けられたポート番号を含むことを識別するステップを含む、請求項８３に記載の方法。
【請求項８６】
前記第２のデバイスによって、パケット取得ドライバを使用して、前記第１のＴＣＰパケットをインターセプトするステップをさらに含む、請求項８３に記載の方法。
【請求項８７】
前記第１のデバイスは、クライアントデバイスであり、前記第２のデバイスはＶＰＮゲートウェイである、請求項８３に記載の方法。
【請求項８８】
前記アプリケーションに前記第１のペイロードを転送する前に、第２のデバイス上でネットワークアドレス変換（ＮＡＴ）を行うステップをさらに含む、請求項８７に記載の方法。
【請求項８９】
ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するためのシステムであって、
第１のデバイスであって、
第１および第２のパケットを生成するアプリケーションであって、前記第１および第２のパケットは、信頼できないトランスポートプロトコルを使用して送信される、アプリケーションと、
フィルタプロセスであって、前記アプリケーションから前記第１および第２のパケットをインターセプトして、トンネルプロセスに前記インターセプトされたパケットを転送する、フィルタプロセスと、
トンネルプロセスであって、前記第１のデバイスと第２のデバイスとの間のＴＣＰ接続を開くことをリクエストし、前記ＴＣＰ接続を開くための前記リクエストは、前記ＴＣＰ接続が、信頼できないトランスポートプロトコルで送信されることを意図したパケットを送信することを前記第１および第２のデバイスに示し、前記トンネルプロセスは、前記第２のデバイスに、第１および第２のＴＣＰパケット内のペイロードとして前記第１および第２のパケットを転送し、前記トンネルプロセスは、前記第１のＴＣＰパケットを送信した後かつ前記第１のＴＣＰパケットに対する確認応答を受信する前に、前記第２のＴＣＰパケットを送信する、トンネルプロセスと、
を備える第１のデバイスと、
第１のデバイスと通信する第２のデバイスであって、
前記第１のデバイスによってリクエストされた前記ＴＣＰ接続を開く第２のトンネルプロセスであって、前記ＴＣＰ接続のソースアドレスを識別して第２のフィルタプロセスに転送する、第２のトンネルプロセスと、
前記第２のフィルタプロセスであって、ヘッダー内の前記ＴＣＰ接続のソースアドレスとともに、前記第２のデバイスにおいて受信した前記アプリケーションからのパケットをインターセプトし、前記第２のフィルタプロセスは、前記受信したパケットから前記ＴＣＰヘッダーを取り除いて、前記第２のデバイス上のＴＣＰ／ＩＰスタックを迂回して、目的とする宛先に前記取り除いたパケットを転送する、第２のフィルタプロセスと、
を備える第２のデバイスと、
を備えるシステム。
【請求項９０】
前記第１のデバイス上の前記フィルタプロセスは、パケット取得ドライバを備える、請求項８９に記載のシステム。
【請求項９１】
前記第２のデバイス上の前記第２のフィルタプロセスは、パケット取得ドライバを備える、請求項８９に記載のシステム。
【請求項９２】
前記第１のデバイスは、クライアントデバイスであり、前記第２のデバイスはＶＰＮゲートウェイデバイスである、請求項８９に記載のシステム。
【請求項９３】
前記取り除かれたパケットが送信される、第３のデバイスをさらに備える、請求項８９に記載のシステム。
【請求項９４】
前記第２のデバイスは、第３のデバイスに前記取り除いたパケットを送信する前に、ネットワークアドレス変換を行うために使用するネットワークアドレス変換（ＮＡＴ）テーブルをさらに備える、請求項９３に記載のシステム。
【請求項９５】
前記信頼できないデータプロトコルは、ＵＤＰである、請求項８９に記載のシステム。
【請求項９６】
ネットワークのフラグメンテーションを低減するために、安全なネットワーク通信の最大送信単位を調整するための方法であって、
（ａ）第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間にセッションを確立するステップであって、前記第１のコンピューティングデバイスは、第１のネットワークスタックを有する、ステップと、
（ｂ）前記第１のコンピューティングデバイスによって、暗号化されたペイロードを有するネットワークパケットを検出するステップと、
（ｃ）前記第１のコンピューティングデバイスによって、少なくとも、前記ペイロードの暗号化された部分に関連するサイズだけ、前記最大送信単位サイズを減じるために、前記第１のネットワークスタックの最大送信単位パラメータの設定を決定するステップと、
（ｄ）前記決定された設定に、前記第１のネットワークスタックの前記最大送信単位を変更するステップと、を含む方法。
【請求項９７】
セキュアソケットレイヤーまたはトランスポートレイヤーセキュリティトンネルのうちの１つを介して、前記第２のコンピューティングデバイスに前記ネットワークパケットを通信するステップを含む、請求項９６に記載の方法。
【請求項９８】
前記ペイロードは、リアルタイムプロトコルを含む、請求項９６に記載の方法。
【請求項９９】
前記第１のネットワークスタックのネットワークドライバインターフェース規約のレベル機構を介して、前記最大送信単位のパラメータを変更するステップをさらに含む、請求項９６に記載の方法。
【請求項１００】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションごとに、前記最大送信単位の設定を動的に決定するステップをさらに含む、請求項９６に記載の方法。
【請求項１０１】
ゲートウェイを介して、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションを確立するステップを含む、請求項９６に記載の方法。
【請求項１０２】
前記第１のコンピューティングデバイスによって、前記ネットワークパケットの前記ペイロードを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータのうちの１つを通信するステップを含む、請求項９６に記載の方法。
【請求項１０３】
前記ネットワークパケットを通信する前に、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つに、前記ネットワークパケットの受信の疑似確認応答を通信するステップを含む、請求項９６に記載の方法。
【請求項１０４】
前記第１のコンピューティングデバイスのエージェントを介して、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の前記セッションを確立するステップをさらに含む、請求項９６に記載の方法。
【請求項１０５】
前記エージェントによって、前記決定された設定に対する前記最大送信単位を変更するために、ＩＯＣＴＬアプリケーションプログラミングインタフェースを介して、前記第１のネットワークスタックに通信するステップを含む、請求項１０４に記載の方法。
【請求項１０６】
ネットワークのフラグメンテーションを低減するために、安全なネットワーク通信の最大送信単位を調整するためのシステムであって、
第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間にセッションを確立するための手段であて、前記第１のコンピューティングデバイスは、第１のネットワークスタックを有する、手段と、
前記第１のコンピューティングデバイスによって、暗号化されたペイロードを有するネットワークパケットを検出するための手段と、
前記第１のコンピューティングデバイスによって、少なくとも、前記ペイロードの暗号化された部分に関連するサイズだけ、前記最大送信単位サイズを減じるために、前記第１のネットワークスタックの最大送信単位パラメータの設定を決定するための手段と、
前記決定された設定に、前記第１のネットワークスタックの前記最大送信単位を変更するための手段と、を備えるシステム。
【請求項１０７】
セキュアソケットレイヤーまたはトランスポートレイヤーセキュリティトンネルのうちの１つを介して、前記第２のコンピューティングデバイスに前記ネットワークパケットを通信するための手段を備える、請求項１０６に記載のシステム。
【請求項１０８】
前記ペイロードは、リアルタイムプロトコルを含む、請求項１０６に記載のシステム。
【請求項１０９】
前記ペイロードは、リアルタイムの音声、オーディオ、またはデータのうちの１つの表現を含む、請求項１０６に記載のシステム。
【請求項１１０】
前記第１のネットワークスタックのネットワークドライバインターフェース規約のレベル機構を介して、前記第１のコンピューティングデバイスの前記最大送信単位パラメータを変更するための手段をさらに備える、請求項１０６に記載のシステム。
【請求項１１１】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションごとに、前記最大送信単位の設定を動的に決定するための手段をさらに備える、請求項１０６に記載のシステム。
【請求項１１２】
ゲートウェイを介して、前記前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションを確立するための手段を備える、請求項１０６に記載のシステム。
【請求項１１３】
前記第１のコンピューティングデバイスによって、前記ネットワークパケットの前記ペイロードを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータのうちの１つを通信するための手段を備える、請求項１０６に記載のシステム。
【請求項１１４】
前記ネットワークパケットを通信する前に、前記第１のコンピューティングデバイスまたは前記第２のコンピューティングデバイスのうちの１つに、前記ネットワークパケットの受信の疑似確認応答を通信するための手段を備える、請求項１０６に記載のシステム。
【請求項１１５】
前記ネットワークパケットは、可逆プロトコルパケットを含む、請求項１０６に記載のシステム。
【請求項１１６】
前記可逆プロトコルパケットは、トランスポート制御プロトコルを含む、請求項１１５に記載のシステム。
【請求項１１７】
前記ペイロードは、不可逆プロトコルパケットを含む、請求項１０６に記載のシステム。
【請求項１１８】
前記不可逆プロトコルパケットは、ユーザーデータグラムプロトコルを含む、請求項１１７に記載のシステム。
【請求項１１９】
前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションを確立するための、前記第１のコンピューティングデバイスのエージェントを含む、請求項１０６に記載のシステム。
【請求項１２０】
前記エージェントは、前記決定された設定に対する前記最大送信単位を変更するために、ＩＯＣＴＬアプリケーションプログラミングインタフェースを介して、前記第１のネットワークスタックに通信する、請求項１１９に記載のシステム。
【請求項１２１】
クライアントが、前記クライアントのアプリケーションに関連付けられた前記クライアントのネットワーク通信に優先順位をつけるための方法であって、
（ａ）前記クライアントによって、前記クライアントの１つ以上のアプリケーションに関連付けられた１つ以上のネットワークパケットをインターセプトするステップと、
（ｂ）前記クライアントによって、キューに前記１つ以上のネットワークパケットを格納するステップと、
（ｃ）前記クライアントによって、前記キューに入れた１つ以上のネットワークパケットが、前記クライアントの第１のアプリケーションに関連付けられていることを判断するステップと、
（ｄ）前記クライアントによって、前記クライアントの第２のアプリケーションに関連付けられた前記キュー内の少なくとも１つのネットワークパケットの前に、前記判断された１つ以上のネットワークパケットを配置するために、前記判断された１つ以上のネットワークパケットの優先順位を示すステップと、
（ｅ）前記クライアントのネットワークスタックを介して、前記優先順位付けされた１つ以上のネットワークパケットを通信に提供するステップと、を含む方法。
【請求項１２２】
前記判断するステップは、前記クライアントによって、前記第１のアプリケーションの前記キューに入れた１つ以上のネットワークパケットが、リアルタイムデータを含むことを判断するステップをさらに含む、請求項１２１に記載の方法。
【請求項１２３】
前記リアルタイムデータは、リアルタイムプロトコル、ユーザーデータグラムプロトコル、および音声またはオーディオのうちの１つの表現、のうちの１つを含む、請求項１２２に記載の方法。
【請求項１２４】
前記クライアントによって、少なくとも１つの前記第２のアプリケーションのネットワークパケットが、前記第１のアプリケーションの前記１つ以上のネットワークパケットの前に、前記ネットワークスタックを介して通信されないようにするステップを含む、請求項１２１に記載の方法。
【請求項１２５】
前記クライアントによって、前記キュー内に前記第２のアプリケーションに関連付けられたネットワークパケットを保持して、前記保持されたネットワークパケットの前に順位付けされた、前記第１のアプリケーションに関連付けられた前記１つ以上のネットワークパケットの通信に応じて、前記保持されたネットワークパケットを解放するステップを含む、請求項１２１に記載の方法。
【請求項１２６】
前記クライアントによって、前記クライアント上の前記１つ以上のアプリケーションに、前記１つ以上のネットワークパケットを透過的にインターセプトするステップを含む、請求項１２１に記載の方法。
【請求項１２７】
フォアグラウンドで前記第１のアプリケーションを実行し、バックグラウンドで前記第２のアプリケーションを実行するステップを含む、請求項１２１に記載の方法。
【請求項１２８】
前記第１のアプリケーションの優先順位を、前記第２のアプリケーションに関連付けられた優先順位よりも高く関連付けるステップを含む、請求項１２１に記載の方法。
【請求項１２９】
ユーザーによって、前記第１のアプリケーションまたは前記第２のアプリケーションのうちの１つの優先順位を特定するステップを含む、請求項１２８に記載の方法。
【請求項１３０】
前記クライアントによって、コンピューティングデバイスから前記１つ以上のネットワークパケットを受信するステップを含む、請求項１２１に記載の方法。
【請求項１３１】
前記１つ以上のアプリケーションによって、コンピューティングデバイスに、前記クライアントから通信するための前記１つ以上のネットワークパケットを提供する、請求項１２１に記載の方法。
【請求項１３２】
クライアントであって、前記クライアントのアプリケーションに関連付けられた前記クライアントのネットワーク通信に優先順位を付け、
前記クライアントの１つ以上のアプリケーションに関連付けられた前記クライアントの１つ以上のネットワークパケットをインターセプトするための機構、および
キューに前記１つ以上のネットワークパケットを格納して、前記クライアントのネットワークスタックを介して、前記１つ以上のネットワークパケットを通信するためのネットワークドライバと、
前記１つ以上のネットワークパケットが、前記クライアントの第１のアプリケーションに関連付けられていることを判断し、前記クライアントの第２のアプリケーションに関連付けられた前記キュー内の少なくとも１つのネットワークパケットの前に、前記判断された１つ以上のネットワークパケットを配置するために、前記１つ以上のネットワークパケットの優先順位を前記ネットワークドライバに示すためのエージェントと、を備えるクライアント。
【請求項１３３】
前記エージェントは、前記第１のアプリケーションの前記１つ以上のネットワークパケットが、リアルタイムデータを含むことを判断する、請求項１３２に記載のクライアント。
【請求項１３４】
前記リアルタイムデータは、リアルタイムプロトコル、ユーザーデータグラムプロトコル、および音声またはオーディオのうちの１つの表現、のうちの１つを含む、請求項１３２に記載のクライアント。
【請求項１３５】
前記エージェントまたは前記ネットワークドライバのうちの１つは、少なくとも１つの前記第２のアプリケーションのネットワークパケットが、前記第１のアプリケーションの前記１つ以上のネットワークパケットの前に、前記ネットワークスタックを介して通信されないようにする、請求項１３２に記載のクライアント。
【請求項１３６】
前記ネットワークドライバは、前記キュー内に前記第２のアプリケーションに関連付けられたネットワークパケットを保持して、前記保持されたネットワークパケットの前に順位付けされた、前記第１のアプリケーションに関連付けられた前記１つ以上のネットワークパケットの通信に応じて、前記保持されたネットワークパケットを解放する、請求項１３２に記載のクライアント。
【請求項１３７】
前記機構は、前記クライアント上の前記１つ以上のアプリケーションに対して、前記１つ以上のネットワークパケットを透過的にインターセプトする、請求項１３２に記載のクライアント。
【請求項１３８】
前記第１のアプリケーションは、前記フォアグランドで実行し、前記第２のアプリケーションは、前記バックグラウンドで実行する、請求項１３２に記載のクライアント。
【請求項１３９】
前記第１のアプリケーションは、前記第２のアプリケーションよりも高い優先順位を有する、請求項１３２に記載のクライアント。
【請求項１４０】
ユーザーが、前記優先順位を特定するための構成機構を備える、請求項１３２に記載のクライアント。
【請求項１４１】
前記クライアントは、コンピューティングデバイスから前記１つ以上のネットワークパケットを受信する、請求項１３２に記載のクライアント。
【請求項１４２】
前記１つ以上のアプリケーションは、コンピューティングデバイスに、前記クライアントから通信するための前記１つ以上のネットワークパケットを提供する、請求項１３２に記載のクライアント。
【請求項１４３】
前記ネットワークドライバは、ネットワークドライバインターフェース仕様（ＮＤＩＳ）ドライバを備える、請求項１３２に記載のクライアント。
【請求項１４４】
前記ネットワークドライバは、前記クライアントのオペレーティングシステムのカーネルモードで動作する、請求項１３２に記載のクライアント。
【請求項１４５】
前記エージェントは、前記クライアントのオペレーティングシステムのユーザーモードで動作する、請求項１３２に記載のクライアント。
【請求項１４６】
前記エージェントまたは前記ネットワークドライバのうちの１つは、前記クライアントの１つ以上のネットワークパケットをインターセプトするための機構を備える、請求項１３２に記載のクライアント。
【請求項１４７】
第１のプロトコルを介して確立されたセッションを、ネットワークの混乱から保護するための方法であって、
（ａ）クライアントのエージェントを介して、前記クライアントとデバイスとの間のネットワーク接続を通じて第１のプロトコルを介したセッションを確立するステップであって、前記ネットワーク接続は、ネットワークスタックに関連付けられ、前記ネットワークスタックの第１の部分は、前記第１のプロトコルのレイヤーの下位に前記ネットワークスタックの１つ以上のレイヤーを備え、前記ネットワークスタックの第２の部分は、前記第１のプロトコルのためのレイヤーおよび前記第１のプロトコルの上位に前記ネットワークスタックの１つ以上のレイヤーを備える、ステップと、
（ｂ）前記ネットワークスタックの前記第１の部分の廃止を生じさせる、前記ネットワーク接続内の混乱を検出するステップと、
（ｃ）前記エージェントによって、前記混乱中に、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持するステップと、
（ｄ）前記セッションおよび前記ネットワークスタックの前記第２の部分を保持しながら、前記ネットワークスタックの前記第２の部分および前記ネットワーク接続を再確立するステップと、を含む方法。
【請求項１４８】
（ｅ）前記ネットワークスタックの前記保持された第２の部分および前記ネットワークスタックの前記再確立された第１の部分との前記セッションを継続するステップを含む、請求項１４７に記載の方法。
【請求項１４９】
（ｅ）前記ネットワークスタックの前記第２部分によって、混乱中に受信したあらゆるネットワークパケットをドロップするステップを含む、請求項１４７に記載の方法。
【請求項１５０】
前記デバイスは、リモートアクセスゲートウェイまたはコンピューティングデバイスのうちの１つを備える、請求項１４７に記載の方法。
【請求項１５１】
セキュアソケットレイヤー（ＳＳＬ）プロトコル、トランスポートレイヤーセキュリティ（ＴＬＳ）プロトコル、およびトンネリングプロトコルのうちの１つの前記第１のプロトコルを介して、前記セッションを確立するステップをさらに含む、請求項１４７に記載の方法。
【請求項１５２】
前記エージェントによって、前記クライアントおよび前記デバイスとの間の前記セッションを介して、リアルタイムデータを通信するステップを含む、請求項１４７に記載の方法。
【請求項１５３】
前記リアルタイムデータは、リアルタイムプロトコルを含む、請求項１５２に記載の方法。
【請求項１５４】
前記リアルタイムデータは、音声またはオーディオのうちの１つの表現を含む、請求項１５２に記載の方法。
【請求項１５５】
前記エージェントを、前記クライアントのオペレーティングシステムのユーザーモードで動作させるステップを含む、請求項１４７に記載の方法。
【請求項１５６】
前記ネットワークの前記第１の部分は、トランスポート制御プロトコルまたはインターネットプロトコルのうちの１つを備える、請求項１４７に記載の方法。
【請求項１５７】
前記ネットワークスタックの前記第２の部分は、インターネットプロトコル、ユーザーデータグラムプロトコル、またはボイスオーバーインターネットプロトコルのうちの１つを備える、請求項１４７に記載の方法。
【請求項１５８】
リモートディスプレイプロトコルを介して、前記デバイスと通信する前記クライアントを備える、請求項１４７に記載の方法。
【請求項１５９】
前記リモートディスプレイプロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルのうちの１つを備える、請求項１５８に記載の方法。
【請求項１６０】
前記ネットワーク接続を介して通信する前記クライアントのアプリケーションに、ステップ（ｂ）、（ｃ）、および（ｄ）のうちの１つを透過的に実行するステップを含む、請求項１４７に記載の方法。
【請求項１６１】
前記エージェントによって、前記クライアントのアプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトするステップを含む、請求項１４７に記載の方法。
【請求項１６２】
前記スタックの前記第２の部分に関連付けられたネットワークドライバによって、前記クライアント上の前記アプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトするステップを含む、請求項１４７に記載の方法。
【請求項１６３】
第１のプロトコルを介して確立されたセッションを、ネットワークの混乱から保護するためのシステムであって、
第１のプロトコルを介して、ネットワーク接続を通じて、前記クライアントとデバイスとの間のセッションを確立するクライアントのエージェントと、
第１の部分および第２の部分を有するネットワークスタックであって、前記ネットワークスタックの前記第１の部分は、前記第１のプロトコルのレイヤーの下位に前記ネットワークスタックの１つ以上のレイヤーを備え、前記ネットワークスタックの第２の部分は、前記第１のプロトコルのためのレイヤーおよび前記第１のプロトコルの上位に前記ネットワークスタックの１つ以上のレイヤーを備える、ネットワークスタックと、
前記ネットワークスタックの前記第２の部分の廃止を生じさせる、前記ネットワーク接続内の混乱を検出するための検出器と、を備え、
前記検出器による前記廃止の検出に応じて、前記エージェントは、前記混乱中に、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持し、
前記エージェントが、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持しながら、前記クライアントは、前記ネットワークスタックの前記第１の部分および前記ネットワーク接続を再確立する、システム。
【請求項１６４】
前記エージェントは、前記ネットワークスタックの前記保持された第２の部分および前記ネットワークスタックの前記再確立された第１の部分との前記セッションを継続する、請求項１６３に記載のシステム。
【請求項１６５】
前記ネットワークの前記第１の部分または前記第２の部分は、混乱中に受信したあらゆるネットワークパケットをドロップする、請求項１６３に記載のシステム。
【請求項１６６】
前記デバイスは、リモートアクセスゲートウェイまたはコンピューティングデバイスのうちの１つを備える、請求項１６３に記載のシステム。
【請求項１６７】
前記第１のプロトコルは、セキュアソケットレイヤー（ＳＳＬ）プロトコル、トランスポートレイヤーセキュリティ（ＴＬＳ）プロトコル、およびトンネリングプロトコルのうちの１つを備える、請求項１６３に記載のシステム。
【請求項１６８】
前記エージェントは、前記クライアントおよび前記デバイスとの間の前記セッションを介して、リアルタイムデータを通信する、請求項１６３に記載のシステム。
【請求項１６９】
前記リアルタイムデータは、リアルタイムプロトコルのうちの１つを含む、請求項１６８に記載のシステム。
【請求項１７０】
前記リアルタイムデータは、音声またはオーディオのうちの１つの表現を含む、請求項１６８に記載のシステム。
【請求項１７１】
前記エージェントは、前記クライアントのオペレーティングシステムのユーザーモードで動作する、請求項１６３に記載のシステム。
【請求項１７２】
前記ネットワークスタックの前記第１の部分は、トランスポート制御プロトコルまたはインターネットプロトコルのうちの１つを備える、請求項１６３に記載のシステム。
【請求項１７３】
前記ネットワークスタックの前記第２の部分は、インターネットプロトコル、ユーザーデータグラムプロトコル、またはボイスオーバーインターネットプロトコルのうちの１つを備える、請求項１６３に記載のシステム。
【請求項１７４】
前記第１のプロトコルは、リモートディスプレイプロトコルを含む、請求項１６３に記載のシステム。
【請求項１７５】
前記リモートディスプレイプロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルのうちの１つを備える、請求項１７４に記載のシステム。
【請求項１７６】
前記エージェントは、アプリケーションに対して、前記クライアントの前記アプリケーションの１つ以上のネットワークパケットを透過的にインターセプトする、請求項１６３に記載のシステム。
【請求項１７７】
前記ネットワークスタックの前記第２の部分に関連付けられたネットワークドライバを備え、前記ネットワークドライバは、アプリケーションに対して、前記クライアントの前記アプリケーションの１つ以上のネットワークパケットをインターセプトし、前記セッションを介して通信するために、前記エージェントに前記１つ以上のパケットを提供する、請求項１６３に記載のシステム。
【請求項１７８】
前記ネットワークドライバは、ネットワークドライバインターフェース仕様（ＮＤＩＳ）ドライバを備える、請求項１７７に記載のシステム。
【請求項１７９】
前記ネットワークドライバは、前記クライアントのオペレーティングシステムのカーネルモードで動作する、請求項１７７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本出願は、米国仮特許出願番号第６０／５９０，８３７号（発明の名称「Ａｄ  Ｈｏｃ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｎｅｔｗｏｒｋｓ  Ａｎｄ  Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ」）（２００４年７月２３日出願）、および米国仮特許出願番号第６０／６０１，４３１号（発明の名称「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ａｓｓｕｒｉｎｇ  Ｒｅｄｕｎｄａｎｃｙ  Ｉｎ  Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  Ｓｏｌｕｔｉｏｎ」）（２００４年８月１３日）、および米国仮特許出願番号第６０／６０７，４２０号（発明の名称「Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ  Ｂｒｉｄｇｉｎｇ」）（２００４年９月３日）、および米国仮特許出願番号第６０／６０８，８１４号（発明の名称「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ａｓｓｕｒｉｎｇ  Ｒｅｄｕｎｄａｎｃｙ  Ｉｎ  Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  Ｓｏｌｕｔｉｏｎ」）（２００４年９月１０日出願）（これらすべてが参考として本明細書に援用される）に対する優先権を主張する。
【０００２】
（技術分野）
本発明は、概してネットワーク上のノード間のネットワーク通信の最適化に関する。
【背景技術】
【０００３】
（背景情報）
仮想プライベートネットワーク（ＶＰＮ）は、トンネリングおよびセキュリティ機構を使用してプライバシーを守るために、インターネットのようなパブリック通信インフラを使用するプライベートデータネットワークである。このように、ＶＰＮは、パブリックネットワークをトラバースする企業データに、データ暗号化およびセキュリティを提供する。パブリックネットワークを介した企業データへの安全なアクセスへの取り組みに加えて、ＶＰＮはまた、２つの切断されたネットワーク、またはルーティング不可能なネットワークからネットワークトラフィックをルーティングすることも目的としている。例えば、１０．０．０．０−１０．２５５．２５５．２５５の範囲にあるプライベートインターネットのプロトコルアドレスを有する第１のプライベートネットワークは、ＶＰＮを介して、１９２．１６８．０．０−１９２．１６８．２５５．２５５の範囲にあるプライベートインターネットのプロトコルアドレスを有する第２のプライベートネットワークと通信することが可能である。ＶＰＮによって、第１のプライベートネットワーク上のリモートマシンは、リモートマシンからネットワークトラフィックをトンネリングして、第２のプライベートネットワーク上にそのネットワークトラフィックを出現させることによって、第２のプライベートネットワーク上の内部マシンと通信することが可能になる。これは、リモートコンピュータが、リモートネットワーク上にある企業サーバーで処理を行っている、クライアントサーバプロトコルに対して十分に機能することが可能である。
【０００４】
しかし、従来のＶＰＮは、ピアツーピアプロトコルでのように、２つのリモートコンピュータが、ＶＰＮゲートウェイを介して互いに直接通信するためにトンネリングする場合には十分に機能することができない。ＶＰＮは、２つのリモートコンピュータが、ＶＰＮゲートウェイを介して、全てのピアツーピア通信をトンネリングする、互いに素なプライベートネットワークのアドレス空間を平坦化することによって、このピアツーピアコンピューティングを達成している。その結果、ピアのうちの１つからのネットワークトラフィックは、ＶＰＮゲートウェイを通って流れ、ピアコンピュータへインターネット上を逆に流れるように、インターネット上のトンネルを切り替える。ピアコンピュータは、ピアコンピュータ間に、より短い直接経路を有する場合があるが、ピアコンピュータ間のネットワークトラフィックは、より長く移動し、最適なルートイベントではない場合がある。リモートコンピュータが、より長いデータ経路ルーティングの欠点を負うことなく、ＶＰＮによって提供されるセキュリティから恩恵を受けられるようにすることは有用となりうる。
【０００５】
２つのコンピュータ間のネットワークを通じた直通通信によって、他の非効率性が存在する。例えば、ネットワーク接続は、ブレークダウンの影響を受けやすい。例えば、クライアントとサーバーとの間の無線接続は、信頼できないことが多い。他の場合では、ネットワーク接続は、断続的である。ある人がエレベータまたはトンネルに入った場合に接続が失われ、その接続は、エレベータまたはトンネルから出たときにしか復旧しない場合がある。別の例では、無線ネットワークトポロジでのように、モバイルコンピューティングデバイスがネットワークのアクセスポイント間を移動する場合に、接続が途絶することがある。
【０００６】
クライアントとサーバーコンピュータとの間に確立された通信セッションが異常終了した場合、クライアントは、一般に、新しい通信セッションを開始することによって、その接続を再確立しなければならない。新しい通信セッションを開始するために、ユーザーは、サーバーコンピュータが新しい通信セッションに対してそのユーザーを許可できるように、一般に、そのサーバーコンピュータに、ログインとパスワードを組み合わせたような、認証証明書を再送信しなければならない。複数の通信セッションにわたってユーザーが認証証明書を繰り返し再送信することは、潜在的な攻撃者にそのユーザーの認証証明書を公開することになるので、認証証明書のセキュリティレベルが低下する。加えて、これは、ユーザーのフラストレーションおよび非効率性をももたらす、しばしば時間のかかるプロセスである。さらに、新しい通信セッションの確立においては、ネットワークは、クライアントが、インターネットプロトコルアドレスのような新しいネットワーク識別子を取得することを必要とする場合がある。クライアント上のアプリケーションまたはプログラムは、クライアントのネットワーク識別子の変更によって、再起動を必要とする場合がある。したがって、ネットワークの混乱からコンピューティングデバイスを保護することが望ましい。
【０００７】
ピアコンピューティングデバイス間の直通通信に関連する別の非効率性は、通信に使用するプロトコルが、求められるほど効率的または安全ではない場合があることである。一例として、ネットワーク通信には、ボイスオーバーＩＰ（ＶｏＩＰ）通信のようなリアルタイムデータ通信が挙げられる。リアルタイムデータ通信は、通話の際の待ち時間を減じるために、ユーザーデータグラムプロトコルのような信頼できないプロトコルを介して通信する場合がある。しかし、ＶｏＩＰ通信は、ＶｏＩＰ通信に信頼できるプロトコルを提供する、ＴＣＰ／ＩＰネットワークまたは安全なＳＳＬゲートウェイをトラバースすることが可能である。これは、信頼できないプロトコルを減じることを目的とした、通話の際の待ち時間を増加させる場合がある。不可逆プロトコルを使用した通信を対象とした可逆プロトコルを介して、データを送信するための技術が必要である。
【０００８】
直通通話における別の非効率性は、暗号化の使用によって生じる。安全なネットワーク通信を提供するために、ＳＳＬのような暗号化を使用することが可能である。通信は安全であるが、ネットワークトラフィックの暗号化は、ネットワークパケットのサイズを増加させ、単一のパケットに対するパケットペイロードが大きくなりすぎる場合がある。これは、パケットのフラグメンテーションをもたらすことになり、通信処理のためにより多くのオーバーヘッドを生じさせる。暗号化オーバーヘッド補うために、パケットの最大サイズを調整するための技術は有用となりうる。
【０００９】
ユーザーのアクティビティおよびクライアントのアプリケーションによって通信が生成されるときに、クライアントが、一般にネットワーク通信を送信する、および通信を受信したときに、受信ネットワーク通信を処理する、という事実から、別の非効率性が生じる。例えば、ある場合では、アプリケーションが実行中で、ユーザーによって現在能動的に使用されているが、バックグラウンドで実行中のアプリケーションに対して生成または受信したネットワークパケットが、フォアグラウンドで実行中のアプリケーションに対して生成または受信したネットワークパケットの前に処理される場合がある。別の例では、クライアントは、リモートコンピューティングデバイスに通話を提供するために、ＶｏＩＰアプリケーションを実行させる場合がある。クライアント上の１つ以上の別のアプリケーションは、ＶｏＩＰのリアルタイムデータ通信に関係なく実行させることが可能である。これらのアプリケーションのためのネットワークパケットは、ＶｏＩＰ通話のリアルタイムのネットワークパケットより前に処理する場合があるので、待ち時間が増加し、音声通信の質を低下させる。アプリケーション認識で、クライアント固有のパケットトラフィックの優先順位付けを提供することが望ましい。
【発明の開示】
【課題を解決するための手段】
【００１０】
(発明の要旨)
本発明は、概してピアツーピア通信およびリモートアクセス接続性を提供するためのリモートアクセスアーキテクチャに関する。一実施態様では、本発明のリモートアクセスアーキテクチャは、ゲートウェイのような第３のコンピューティングデバイスを介して、ピアコンピューティングデバイス間の直接接続を確立するための方法を提供する。加えて、本発明は、ボイスオーバーＩＰ（ＶｏＩＰ）シグナリングのようなリアルタイム通信、およびメディア、ビデオ、およびウェブコラボレーション、スクリーンまたはデスクトップシェアリング、およびインスタントメッセージングのような他のリアルタイムデータアプリケーションを含む、ピアツーピア通信を最適化するための様々な技術を提供する。本発明は、以下のピアツーピア最適化技術を提供する。１）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットの受信の疑似確認応答。２）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットのペイロードシフティング。３）最大送信単位（ＭＴＵ）のパラメータを調整することによって、パケットフラグメンテーションを削減し、暗号化によるオーバーヘッドを補う。４）クライアント側ネットワーク通信のアプリケーション認識の優先順位付け。５）モバイルコンピューティングに対してなどの、信頼性が高く、永続的なネットワーク接続およびアクセスのためのネットワークの混乱の防止。
【００１１】
一側面では、本発明は、第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するための方法に関する。前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であってよい。前記方法は、前記第１のコンピューティングデバイスによって、第３のコンピューティングデバイスとの第１のトンネリングセッションを確立し、前記第２のコンピューティングデバイスによって、前記第３のコンピューティングデバイスとの第２のトンネリングセッションを確立するステップを含む。第３のコンピューティングデバイスは、ＳＳＬ  ＶＰＮゲートウェイのようなゲートウェイであってよい。前記第１のコンピューティングデバイスは、シグナリングプロトコルを介するなどの、前記第３のコンピューティングデバイスを介して、前記第２のコンピューティングデバイスへの通信セッションを開始する。サーバーは、前記開始された通信セッションを確立するために信号を受信し、前記サーバーは、前記第１のコンピューティングデバイスに、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを含む、第１のネットワークアドレスを通信する。前記第１のコンピューティングデバイスは、前記第１のネットワークアドレスを使用して前記第２のコンピューティングデバイスとの接続を開始するために、リクエストを通信する。前記方法は、前記第３のコンピューティングデバイスによって、前記リクエストをインターセプトして、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供するステップをさらに含む。前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを識別する。前記第３のコンピューティングデバイスは、ファイアウォールをトラバースするスイマーセッションを介するなどの、前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスからの接続を可能にするために、前記第２のコンピューティングデバイスにリクエストを通信する。
【００１２】
本発明の一実施態様では、前記第１のトンネリングセッションまたは前記第２のトンネリングセッションは、セキュアソケットレイヤーまたは仮想プライベートネットワークを使用して確立される。前記第３のコンピューティングデバイスは、リモートアクセスゲートウェイであってよい。別の実施態様では、前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する。
【００１３】
別の実施態様では、本発明の方法は、前記第３のコンピューティングデバイスによって、前記第１のトンネリングセッションを介して、前記第１のコンピューティングデバイスに帯域外の信号を通信することにより、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供するステップを含む。更なる一実施態様では、本発明の方法は、前記第２のコンピューティングデバイスによって、前記第２のネットワークアドレスを使用して前記第２のコンピューティングデバイスへ通信するために、前記第１のコンピューティングデバイスにファイアウォール内のフォワードホールを提供するステップを含む。
【００１４】
本発明の更なる一実施態様では、前記第３のコンピューティングデバイスは、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスに鍵を通信する。前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスは、鍵を交換することが可能である。加えて、前記第１および第２のコンピューティングデバイスは、他のコンピューティングデバイスにデータを送信する前に、前記他のコンピューティングデバイスから受信した鍵が一致することを確認することが可能である。
【００１５】
本発明のいくつかの実施態様では、前記方法は、第１の通信デバイスを前記第１のコンピューティングデバイスに関連付け、また第２の通信デバイスを前記第２のコンピューティングデバイスに関連付ける。前記第１の通信デバイスまたは前記第２の通信デバイスは、ハードまたはソフトＶｏＩＰ電話のような、ソフトウェアコンポーネントまたはハードウェアコンポーネントを備えることが可能である。一実施態様では、本発明の方法は、前記第１および第２のコンピューティングデバイス間の前記接続を介して、前記第１の通信デバイスと前記第２の通信デバイスとの間の通信セッションを確立する。前記第１の通信デバイスおよび前記第２の通信デバイスは、前記第３のコンピューティングデバイスをトラバースせずに、前記通信セッションを通じて通信することが可能である。
【００１６】
本発明の別の実施様態では、前記方法は、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の前記接続を介して、リモートディスプレイプロトコルを通信する。前記リモートデスクトッププロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルを含むことが可能である。更なる一実施態様では、前記方法は、前記接続を介して、前記第１のコンピューティングデバイスのスクリーンビューまたはスクリーンデータを前記第２のコンピューティングデバイスと共有する。
【００１７】
一側面では、本発明は、ゲートウェイにおいて、第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するための方法を提供する。前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であってよい。前記方法は、第１のネットワーク上の前記第１のコンピューティングデバイスとの第１のトンネリングセッションを確立するステップと、前記第２のネットワーク上の前記第２のコンピューティングデバイスとの第２のトンネリングセッションを確立するステップと、を含む。前記ゲートウェイは、前記第２のコンピューティングデバイスとの通信セッションを開始するために、前記第１のコンピューティングデバイスによってリクエストを受信する。前記第１のコンピューティングデバイスは、前記第２のコンピューティングデバイスと交信するための第１のネットワークアドレスを提供する。前記第１のネットワークアドレスは、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを識別する。前記ゲートウェイは、前記第１のネットワークアドレスを使用して、前記第２のコンピューティングデバイスとの接続を開始するために、前記第１のコンピューティングデバイスによってリクエストを受信し、前記接続を開始するために前記リクエストをインターセプトし、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供する。
前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを識別する。前記ゲートウェイは、ファイアウォールをトラバースするスイマーセッションを介するなどの、前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスから前記第２のコンピューティングデバイスへの接続を可能にするために、前記第２のコンピューティングデバイスにリクエストを通信する。
【００１８】
一実施態様では、前記ゲートウェイを介した前記第１のトンネリングセッションまたは前記第２のトンネリングセッションは、セキュアソケットレイヤーまたは仮想プライベートネットワークを含む。別の実施態様では、前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する。更なる一実施態様では、本発明の方法は、前記第１のトンネリングセッションを介して、前記第１のコンピューティングデバイスに帯域外の信号を通信することにより、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供する。加えて、前記ゲートウェイは、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスに鍵を通信することが可能である。
【００１９】
別の側面では、本発明は、第３のコンピューティングデバイスを介して、第１のネットワーク上の第１のコンピューティングデバイスと第２のネットワーク上の第２のコンピューティングデバイスとの間にピアツーピア通信セッションを確立するためのシステムに関する。前記第１のネットワークは前記第２のネットワークから切断され、前記第２のネットワークへのルーティングが不可能であってよい。前記システムは、前記第１のネットワーク上の第１のコンピューティングデバイスと、前記第２のネットワーク上の第２のコンピューティングデバイスと、を備える。第３のコンピューティングデバイスは、前記第１のコンピューティングデバイスとの第１のトンネリングセッションおよび、前記第２のコンピューティングデバイスとの第２のトンネリングセッションを確立する。前記システムはまた、前記第３のコンピューティングデバイスを介してアクセス可能なサーバーも備える。オペレーションに際し、前記サーバーは、前記第３のコンピューティングデバイスを介して、前記第１のコンピューティングデバイスに、前記第２のトンネリングセッションに関連付けられた前記第２のコンピューティングデバイスのネットワークアドレスを識別する、第１のネットワークアドレスを通信する。前記第１のコンピューティングデバイスは、前記第１のネットワークアドレスを使用して前記第２のコンピューティングデバイスとの接続を開始するために、前記第３のコンピューティングデバイスを介して、第１のリクエストを通信する。前記第３のコンピューティングデバイスは、前記第１のリクエストをインターセプトし、前記第１のコンピューティングデバイスに前記第２のコンピューティングデバイスの第２のネットワークアドレスを提供する。前記第２のネットワークアドレスは、前記第２のコンピューティングデバイスに関連付けられたパブリックネットワークアドレスを識別する。前記第３のコンピューティングデバイスは、前記第２のネットワークアドレスを使用して、前記第１のコンピューティングデバイスからの接続を可能にするために、前記第２のコンピューティングデバイスに第２のリクエストを通信する。
【００２０】
本システムの一実施態様では、前記第１のトンネリングセッションまたは前記第２のトンネリングセッションは、セキュアソケットレイヤーまたは仮想プライベートネットワークを含む。さらに、前記第３のコンピューティングデバイスは、ＳＳＬ  ＶＰＮゲートウェイのようなリモートアクセスゲートウェイであってよい。前記システムの別の実施態様では、前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスに関連付けられたファイアウォールの背後に位置する。
【００２１】
本発明の更なる一実施態様では、前記第３のコンピューティングデバイスは、帯域外のＴＬＳセッションを介するなどの、前記第１のトンネリングセッションを介して、帯域外の信号を通信することによって、前記第１のコンピューティングデバイスに前記第２のネットワークアドレスを提供する。一実施態様では、前記第２のコンピューティングデバイスは、前記第２のネットワークアドレスを使用して、前記第２のコンピューティングデバイスへ通信するために、前記第１のコンピューティングデバイスにファイアウォール内のフォワードホールを提供する。
【００２２】
本発明のシステムの更なる一実施態様では、前記第３のコンピューティングデバイスは、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスに鍵を通信する。前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスは、鍵を交換することが可能である。加えて、前記第１および第２のコンピューティングデバイスは、データを送信する前に、前記他のコンピューティングデバイスから受信した前記鍵を照合することが可能である。
【００２３】
本発明のいくつかの実施態様では、前記システムは、前記第１のコンピューティングデバイスに関連付けられた第１の通信デバイスと、前記第２のコンピューティングデバイスに関連付けられた第２の通信デバイスと、を備える。前記第１の通信デバイスまたは前記第２の通信デバイスは、ハードまたはソフトＶｏＩＰ電話のような、ソフトウェアコンポーネントまたはハードウェアコンポーネントを備えることが可能である。一実施態様では、本発明のシステムは、前記第１および第２のコンピューティングデバイス間の接続を介して、前記第１の通信デバイスと前記第２の通信デバイスとの間の通信セッションを確立するステップを含む。前記第１の通信デバイスおよび前記第２の通信デバイスは、前記第３のコンピューティングデバイスをトラバースせずに、前記通信セッションを通じて、通信することが可能である。
【００２４】
本発明の別の実施様態では、前記第１のコンピューティングデバイスおよび前記第２のコンピューティングデバイスは、前記接続を介して、リモートディスプレイプロトコルを通信する。前記リモートデスクトッププロトコルは、独立コンピューティングアーキテクチャプロトコルまたはリモートデスクトッププロトコルを含むことが可能である。更なる一実施態様では、前記第１のコンピューティングデバイスは、前記接続を介して、スクリーンビューまたはスクリーンデータを前記第２のコンピューティングデバイスと共有することが可能である。
【００２５】
別の側面では、本発明は、不可逆プロトコルを介して送信されるように構成されたパケットを、可逆プロトコルを介して通信するための方法に関する。前記方法は、システムのような１つ以上の電子デバイスにおいて行うこと、およびあらゆる好適な手段および機構によって行うことが可能である。前記方法は、可逆プロトコルを介して、第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間の接続を確立するステップを含む。いくつかの実施態様では、前記第２のコンピューティングデバイスは、ＳＳＬ  ＶＰＮゲートウェイのようなゲートウェイであってよい。前記第１のコンピューティングデバイスは、前記第１のコンピューティングデバイスによって、不可逆プロトコルに従って構成される１つ以上のパケットを有するペイロードを含む可逆プロトコルパケットを検出する。前記第１のコンピューティングデバイスは、前記第１のコンピューティングデバイスおよび／または前記第２のコンピューティングデバイスに、前記可逆プロトコルパケットの受信の擬似確認応答を通信する。前記可逆プロトコルパケットの受信の疑似確認応答は、前記可逆プロトコルの信頼性アルゴリズムおよび機構を用いないようにする。前記第１のコンピューティングデバイスは、前記第２のコンピューティングデバイスに、前記可逆プロトコルパケットを通信する。いくつかの実施態様では、前記可逆プロトコルパケットの受信の疑似確認応答は、前記可逆プロトコルパケットを通信する前に通信される。
【００２６】
一実施態様では、本発明の方法は、前記第１のコンピューティングデバイスによって、鍵を使用して前記１つ以上のパケットを暗号化するステップを含む。いくつかの実施態様では、暗号鍵は、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間の帯域外のトランスポートセキュリティレイヤーセッションを介して、前記第１のコンピューティングデバイスに提供することが可能である。更なる一実施態様では、前記方法は、パケット単位で前記１つ以上のパケットを暗号化する。
【００２７】
本発明の方法の別の実施態様では、前記第１のコンピューティングデバイスおよび／または前記第２のコンピューティングによる、前記可逆プロトコルパケットの受信の擬似確認応答の受信に応えて、前記第１のコンピューティングデバイスおよび／または前記第２のコンピューティングは、前記可逆プロトコルの可逆特性の提供に関連するオペレーションを実行しないようにする。一実施態様では、前記可逆プロトコルは、トランスポート制御プロトコルである。
【００２８】
更なる一実施態様では、本発明の方法は、前記第１のコンピューティングデバイスおよび／または前記前記第２のコンピューティングデバイスが、前記可逆プロトコルとともに、１）再送信、２）順序付け、３）フロー制御アルゴリズム、４）Ｎａｐｌｅのアルゴリズム、および５）スライディングウィンドウアルゴリズムのうちの１つ以上を実行しないようにする。
【００２９】
一実施態様では、前記不可逆プロトコルは、ユーザーデータグラムプロトコルを含む。別の実施態様では、前記方法は、前記第１のコンピューティングデバイスによって、セキュアソケットレイヤーまたはトランスポートセキュリティレイヤートンネルを介して、前記第２のコンピューティングデバイスに、前記可逆プロトコルを通信するステップを含む。
【００３０】
別の実施態様では、前記ペイロードの１つ以上のパケットは、リアルタイムプロトコルを含む。更なる一実施態様では、前記方法は、前記第１のコンピューティングデバイスによって、前記１つ以上のパケットを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータのうちの１つを通信するステップを含む。
【００３１】
一側面では、本発明は、ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するための方法に関する。前記方法は、第１のデバイスにおいて、信頼できないトランスポートプロトコルを使用して送信される第１のパケットを受信するステップと、前記受信した第１のパケットの第１のペイロードを含む第１のＴＣＰパケットと、前記第１のデバイスと第２のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーと、を作成するステップと、を含む。前記第１のデバイスは、前記第２のデバイスに前記第１のＴＣＰパケットを送信する。前記方法は、前記第１のデバイスにおいて、信頼できないトランスポートプロトコルを使用して送信される第２のパケットを受信するステップと、前記受信した第２のパケットの第２のペイロードを含む第２のＴＣＰパケットと、前記第１のＴＣＰヘッダー情報と、を作成するステップと、をさらに含む。前記第１のデバイスによって、前記第２のデバイスから前記第１のペイロードの受信の確認応答を受信する前に、前記第１のデバイスは、前記第２のデバイスに前記第２のＴＣＰパケットを送信する。
【００３２】
一実施態様では、本発明の方法は、前記信頼できないトランスポートプロトコルに関連付けられたポート番号でＴＣＰ接続を確立するステップを含む。別の実施態様では、前記方法は、前記第１のデバイスによって、前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットが、信頼できないトランスポートプロトコルを含むことを動的に判断するステップを含む。いくつかの実施態様では、前記信頼できないトランスポートプロトコルは、ＵＤＰである。
【００３３】
更なる一実施態様では、前記方法は、パケット取得機構を使用して、前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットをインターセプトすることによって、前記第１のデバイス上の前記前記第１のＴＣＰパケットおよび前記第２のＴＣＰパケットを受信するステップを含む。いくつかの実施態様では、前記方法は、前記第１のデバイスによって、ＶＰＮゲートウェイデバイスとの前記ＴＣＰ接続を確立する。他の実施態様では、前記方法は、前記ＴＣＰ接続を介して、前記第１のデバイスと前記第２のデバイスとの間にピアツーピア通信を確立するステップを含む。本発明の別の実施様態では、前記方法は、前記第１のデバイスによって、前記第１および第２のＴＣＰパケットを暗号化し、前記第２のデバイスによって、前記暗号化された第１および第２のＴＣＰパケットを解読するステップを含む。
【００３４】
別の側面では、本発明は、ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するための方法に関する。前記方法は、第２のデバイスにおいて、第１のデバイス上に作成され、前記第２のデバイス上で受信する第１のＴＣＰパケットをインターセプトするステップを含む。前記第１のＴＣＰパケットは、信頼できないプロトコルおよび前記第１のデバイスと前記第３のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーを使用したアプリケーションによって生成される第１のパケットの第１のペイロードを含む。前記方法の前記インターセプトするステップは、前記第１のＴＣＰパケットが前記第２のデバイス上のＴＣＰスタックに提供される前に生じる。前記方法は、前記情報のＴＣＰヘッダーに応答して、前記第１のペイロードが、信頼できないトランスポートプロトコルを使用したアプリケーションによって生成されたパケットであることを識別するステップと、前記第１のＴＣＰパケットから前記情報のＴＣＰヘッダーを取り除くステップと、前記信頼できないデータプロトコルを使用して、アプリケーションに前記第１のペイロードを転送するステップと、を含む。
【００３５】
一実施態様では、前記信頼できないプロトコルは、ＵＤＰである。別の実施態様では、前記識別するステップは、前記識別するステップは、前記ＴＣＰヘッダー情報が、前記信頼できないトランスポートプロトコルに関連付けられたポート番号を含むことを識別するステップを含む。いくつかの実施態様では、前記方法は、前記第２のデバイスによって、パケット取得ドライバを使用して、前記第１のＴＣＰパケットをインターセプトするステップを含む。
【００３６】
いくつかの実施態様では、前記第１のデバイスは、クライアントデバイスであり、前記第２のデバイスはＶＰＮゲートウェイである。加えて、本発明の方法は、前記アプリケーションに前記第１のペイロードを転送する前に、第２のデバイス上でネットワークアドレス変換（ＮＡＴ）を行うステップを含む。
【００３７】
更なる側面では、本発明は、ＴＣＰ接続を通じて、信頼できないトランスポートプロトコルを使用して、アプリケーションからパケットを送信するためのシステムに関する。前記システムは、第１のデバイスと、第２のデバイスと、を含む。前記第１のデバイスは、第１および第２のパケットを生成するアプリケーションを有する。前記第１および第２のパケットは、信頼できないトランスポートプロトコルを使用して送信される。第１のデバイスはまた、フィルタプロセスとトンネリングプロセスと、を有する。前記フィルタプロセスは、前記アプリケーションから前記第１および第２のパケットをインターセプトして、前記トンネルプロセスに前記インターセプトされたパケットを転送する。前記トンネルプロセスは、前記第１のデバイスと第２のデバイスとの間のＴＣＰ接続を開くことをリクエストする。前記ＴＣＰ接続を開くための前記リクエストは、前記ＴＣＰ接続が、信頼できないトランスポートプロトコルで送信されることを意図したパケットを送信することを前記第１および第２のデバイスに示す。前記トンネルプロセスは、前記第２のデバイスに、第１および第２のＴＣＰパケット内のペイロードとして前記第１および第２のパケットを転送する。前記トンネルプロセスは、前記第１のＴＣＰパケットを送信した後かつ前記第１のＴＣＰパケットに対する確認応答を受信する前に、前記第２のＴＣＰパケットを送信する。
【００３８】
本発明のシステムの前記第２のデバイスは、前記第１のデバイスと通信する。前記第２のデバイスは、第２のフィルタプロセスと、トンネリングプロセスと、を有する。前記第２のトンネルプロセスは、前記第１のデバイスによってリクエストされた前記ＴＣＰ接続を開き、前記ＴＣＰ接続のソースアドレスを識別して前記第２のフィルタプロセスに転送する。前記第２のフィルタプロセスは、ヘッダー内の前記ＴＣＰ接続のソースアドレスとともに、前記第２のデバイスにおいて受信した前記アプリケーションからパケットをインターセプトする。前記第２のフィルタプロセスは、前記受信したパケットから前記ＴＣＰヘッダーを取り除いて、前記第２のデバイス上のＴＣＰ／ＩＰスタックを迂回して、目的とする宛先に前記取り除いたパケットを転送する。
【００３９】
本発明のシステムの一実施態様では、前記第１のデバイス上の前記フィルタプロセスおよび／または前記第２のデバイス上の前記第２のフィルタプロセスは、パケット取得ドライバである。いくつかの実施態様では、前記第１のデバイスは、クライアントデバイスであり、前記第２のデバイスは、ＶＰＮゲートウェイデバイスである。一実施態様では、前記信頼できないデータプロトコルは、ＵＤＰである。
【００４０】
別の実施態様では、前記システムはまた、前記取り除かれたパケットが送信される、第３のデバイスも備える。加えて、前記第２のデバイスは、前記第３のデバイスに前記取り除いたパケットを送信する前に、ネットワークアドレス変換を行うために使用するネットワークアドレス変換（ＮＡＴ）テーブルをさらに備えることが可能である。
【００４１】
更なる一側面では、本発明は、ネットワークのフラグメンテーションを低減するために、安全なネットワーク通信の最大送信単位を調整するための方法に関する。前記方法は、システムのような１つ以上の電子デバイスにおいて、およびあらゆる好適な手段および機構によって行うことが可能である。前記方法は、第１のコンピューティングデバイスと第２のコンピューティングデバイスとの間にセッションを確立するステップを含む。前記セッションは、前記第１のコンピューティングデバイスのエージェントによって確立することが可能である。前記第１のコンピューティングデバイスは、第１のネットワークスタックを有する。前記方法は、前記第１のコンピューティングデバイスによって、暗号化されたペイロードを有するネットワークパケットを検出し、前記第１のコンピューティングデバイスによって、少なくとも、前記ペイロードの暗号化された部分に関連するサイズだけ、前記最大送信単位サイズを減じるために、前記第１のネットワークスタックの最大送信単位パラメータの設定を決定する。前記方法は、前記決定された設定に、前記第１のネットワークスタックの前記最大送信単位（ＭＴＵ）を変更する。このように、報告されたＭＴＵパラメータは、暗号化を補うために減じられる。
【００４２】
一実施態様では、本発明の方法は、セキュアソケットレイヤーまたはトランスポートレイヤーセキュリティトンネルを介して、前記第２のコンピューティングデバイスに前記ネットワークパケットを通信する。前記第２のコンピューティングデバイスは、ＳＳＬ  ＶＰＮゲートウェイのようなゲートウェイであってよい。別の実施態様では、前記ペイロードは、リアルタイムプロトコルを含む。
【００４３】
加えて、一実施態様では、前記方法は、前記第１のネットワークスタックのネットワークドライバインターフェース規約（ＮＤＩＳ）のレベル機構を介して、前記最大送信単位のパラメータを変更することが可能である。別の実施態様では、前記方法は、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションごとに、前記最大送信単位の設定を動的に決定する。一実施態様では、前記第１のコンピューティングデバイスの前記エージェントは、前記決定された設定に対する前記最大送信単位を変更するために、ＩＯＣＴＬアプリケーションプログラミングインタフェースを介して、前記第１のネットワークスタックに通信する。
【００４４】
いくつかの実施態様では、本発明の方法は、ゲートウェイを介して、前記第１のコンピューティングデバイスと前記第２のコンピューティングデバイスとの間のセッションを確立する。他の実施態様では、前記方法は、前記第１のコンピューティングデバイスによって、前記ネットワークパケットの前記ペイロードを介して、前記第２のコンピューティングデバイスに、リアルタイムの音声、オーディオ、またはデータを通信する。さらに別の実施態様では、前記方法は、前記ネットワークパケットを通信する前に、前記第１のコンピューティングデバイスおよび／または前記第２のコンピューティングデバイスに、前記ネットワークパケットの受信の疑似確認応答を通信する。一実施態様では、前記ネットワークパケットは、トランスポート制御プロトコルのような可逆プロトコルパケットを含む。別の実施態様では、前記ペイロードは、ユーザーデータグラムプロトコルのような不可逆プロトコルパケットを含む。
【００４５】
更なる側面では、本発明は、クライアントが、クライアントのアプリケーションに関連付けられた前記クライアントのネットワーク通信に優先順位をつけるための方法に関する。前記方法は、前記クライアントによって、前記クライアントの１つ以上のアプリケーションに関連付けられた１つ以上のネットワークパケットをインターセプトするステップと、キューに前記１つ以上のネットワークパケットを格納するステップと、を含む。前記クライアントは、前記キューに入れた１つ以上のネットワークパケットが、前記クライアントの第１のアプリケーションに関連付けられていることを判断する。前記クライアントは、前記クライアントの第２のアプリケーションに関連付けられた前記キュー内の少なくとも１つのネットワークパケットの前に、前記判断された１つ以上のネットワークパケットを配置するために、前記判断された１つ以上のネットワークパケットの優先順位を示す。前記クライアントは、前記クライアントのネットワークスタックを介して、前記優先順位付けされた１つ以上のネットワークパケットを通信に提供する。
【００４６】
一実施態様では、本発明の方法は、前記クライアントによって、前記第１のアプリケーションの前記キューに入れた１つ以上のネットワークパケットが、リアルタイムデータを含むことを判断するステップを含む。前記リアルタイムデータは、１）リアルタイムプロトコル、２）ユーザーデータグラムプロトコル、および３）音声またはオーディオの表現、のうちの１つを含むことが可能である。
【００４７】
別の実施態様では、前記方法は、前記クライアントによって、少なくとも１つの前記第２のアプリケーションのネットワークパケットが、前記第１のアプリケーションの前記１つ以上のネットワークパケットの前に、前記ネットワークスタックを介して通信されないようにするステップを含む。更なる一実施態様では、前記方法は、前記クライアントによって、前記キュー内に前記第２のアプリケーションに関連付けられたネットワークパケットを保持して、前記保持されたネットワークパケットの前に順位付けされた、前記第１のアプリケーションに関連付けられた前記１つ以上のネットワークパケットの通信に応じて、前記保持されたネットワークパケットを解放するステップを含む。
【００４８】
本発明のさらに別の実施態様では、前記方法は、前記クライアントによって、前記クライアント上の前記１つ以上のアプリケーションに対して、前記１つ以上のネットワークパケットを透過的にインターセプトするステップを含む。いくつかの実施態様では、前記第１のアプリケーションはフォアグランドで動作し、前記第２のアプリケーションはバックグラウンドで実行する。
【００４９】
本発明の一実施態様では、前記方法は、前記第１のアプリケーションの優先順位を、前記第２のアプリケーションに関連付けられた優先順位よりも高く関連付けるステップを含む。別の実施態様では、ユーザーは、前記第１のアプリケーションまたは前記第２のアプリケーションの優先順位を特定することが可能である。更なる一実施態様では、前記クライアントは、コンピューティングデバイスから前記１つ以上のネットワークパケットを受信する。また、前記１つ以上のアプリケーションは、コンピューティングデバイスに、前記クライアントから通信するための前記１つ以上のネットワークパケットを提供する。
【００５０】
別の側面では、本発明は、前記クライアントのアプリケーションに関連付けられた前記クライアントのネットワーク通信に優先順位を付けるためのクライアントに関する。前記クライアントは、前記クライアントの１つ以上のアプリケーションに関連付けられた前記クライアントの１つ以上のネットワークパケットをインターセプトするための機構を備える。前記クライアントはまた、キューに前記１つ以上のネットワークパケットを格納して、前記クライアントのネットワークスタックを介して、前記１つ以上のネットワークパケットを通信するためのネットワークドライバも備える。前記クライアントは、前記１つ以上のネットワークパケットが、前記クライアントの第１のアプリケーションに関連付けられていることを判断し、前記クライアントの第２のアプリケーションに関連付けられた前記キュー内の少なくとも１つのネットワークパケットの前に、前記判断された１つ以上のネットワークパケットを配置するために、前記１つ以上のネットワークパケットの優先順位を前記ネットワークドライバに示すためのエージェントをさらに備える。
【００５１】
一実施態様では、前記第１のアプリケーションの前記１つ以上のネットワークパケットが、リアルタイムデータを含むことを判断する。前記リアルタイムデータは、１）リアルタイムプロトコル、２）ユーザーデータグラムプロトコル、および３）音声またはオーディオの表現、のうちの１つを含む。
【００５２】
更なる一実施態様では、本発明のエージェントまたはネットワークドライバは、少なくとも１つの前記第２のアプリケーションのネットワークパケットが、前記第１のアプリケーションの前記１つ以上のネットワークパケットの前に、前記ネットワークスタックを介して通信されないようにする。一実施態様では、前記ネットワークドライバは、前記キュー内に前記第２のアプリケーションに関連付けられたネットワークパケットを保持して、前記保持されたネットワークパケットの前に順位付けされた、前記第１のアプリケーションに関連付けられた前記１つ以上のネットワークパケットの通信に応じて、前記保持されたネットワークパケットを解放する。
【００５３】
他の一実施例において、本発明は、 前記機構を介して、前記クライアント上の前記１つ以上のアプリケーションに対して、前記１つ以上のネットワークパケットを透過的にインターセプトする。いくつかの実施態様では、前記第１のアプリケーションは、前記フォアグランドで実行し、前記第２のアプリケーションは、前記バックグラウンドで実行する。また、前記第１のアプリケーションは、前記第２のアプリケーションよりも高い優先順位を有することが可能である。さらに、前記クライアントは、ユーザーが、前記優先順位を特定するための構成機構を備えることが可能である。いくつかの実施態様では、前記クライアントは、コンピューティングデバイスから前記１つ以上のネットワークパケットを受信する。他の実施態様では、前記１つ以上のアプリケーションは、コンピューティングデバイスに、前記クライアントから通信するための前記１つ以上のネットワークパケットを提供する。
【００５４】
更なる一実施態様では、前記ネットワークドライバは、ネットワークドライバインターフェース仕様（ＮＤＩＳ）ドライバを備える。また、前記ネットワークドライバは、前記クライアントのオペレーティングシステムのカーネルモードで動作することが可能である。ある場合では、前記エージェントは、前記クライアントのオペレーティングシステムのユーザーモードで動作する。さらに、前記エージェントまたは前記ネットワークドライバは、前記クライアントの１つ以上のネットワークパケットをインターセプトするための機構を備える。
【００５５】
さらに別の側面では、本発明は、第１のプロトコルを介して確立されたセッションを、ネットワークの混乱から保護するための方法に関する。前記方法は、クライアントのエージェントを介して、前記クライアントとデバイスとの間のネットワーク接続を通じて第１のプロトコルを介したセッションを確立するステップを含む。前記ネットワーク接続は、ネットワークスタックに関連付けられる。前記ネットワークスタックの第１の部分は、前記第１のプロトコルのレイヤーの下位に前記ネットワークスタックの１つ以上のレイヤーを備え、前記ネットワークスタックの第２の部分は、前記第１のプロトコルのためのレイヤーおよび前記第１のプロトコルの上位に前記ネットワークスタックの１つ以上のレイヤーを備える。前記方法は、前記ネットワークスタックの前記第２の部分の廃止を生じさせる、前記ネットワーク接続内の混乱を検出するステップと、前記エージェントによって、前記混乱中に、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持するステップと、を含む。前記方法は、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持しながら、前記ネットワークスタックの前記第１の部分および前記ネットワーク接続を再確立するステップをさらに含む。
【００５６】
一実施態様では、前記方法は、前記ネットワークスタックの前記保持された第２の部分および前記ネットワークスタックの前記再確立された第１の部分との前記セッションを継続するステップを含む。いくつかの実施態様では、前記方法はまた、前記ネットワークスタックの前記第１の部分および／または前記第２部分によって、混乱中に受信したあらゆるネットワークパケットをドロップするステップを含む。
【００５７】
別の実施態様では、前記デバイスは、リモートアクセスゲートウェイまたは別のコンピューティングデバイスを備える。場合によっては、前記方法は、１）セキュアソケットレイヤー（ＳＳＬ）プロトコル、２）トランスポートレイヤーセキュリティ（ＴＬＳ）プロトコル、および３）トンネリングプロトコルのうちの１つの前記第１のプロトコルを介して、前記セッションを確立するステップを含む。加えて、本発明の方法は、前記エージェントによって、前記クライアントおよび前記デバイスとの間の前記セッションを介して、リアルタイムデータを通信するステップを含むことが可能である。前記リアルタイムデータは、リアルタイムプロトコルを含むか、または前記リアルタイムデータは、音声またはオーディオを表すことが可能である。
【００５８】
いくつかの実施態様では、前記エージェントは、前記クライアントのオペレーティングシステムのユーザーモードで動作する。一実施態様では、前記ネットワークの前記第１の部分は、トランスポート制御プロトコルまたはインターネットプロトコルのうちの１つを含む。別の実施態様では、前記ネットワークスタックの前記第２の部分は、１）インターネットプロトコル、２）ユーザーデータグラムプロトコル、または３）ボイスオーバーＩＰのうちの１つを備える。加えて、前記クライアントは、リモートディスプレイプロトコルを介して、前記デバイスと通信する前記クライアントを備える。
前記リモートディスプレイプロトコルは、独立コンピューティングアーキテクチャ（ＩＣＡ）プロトコルまたはリモートデスクトッププロトコル（ＲＤＰ）であってよい。
【００５９】
別の実施態様では、本発明の方法は、前記ネットワーク接続を介して通信する前記クライアントのアプリケーションに透過的に実行する。一実施態様では、前記方法は、前記エージェントによって、前記クライアントのアプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトするステップを含む。一実施態様では、前記方法は、前記スタックの前記第１の部分に関連付けられたネットワークドライバによって、前記クライアント上の前記アプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトするステップを含む。
【００６０】
更なる側面では、本発明は、第１のプロトコルを介して確立されたセッションを、ネットワークの混乱から保護するためのシステムに関する。前記システムは、第１のプロトコルを介して、ネットワーク接続を通じて、前記クライアントとデバイスとの間のセッションを確立するクライアントのエージェントを有する。前記システムは、前記クライアントの前記ネットワークスタックのような、第１の部分および第２の部分を有するネットワークスタックを備える。前記ネットワークスタックの第２の部分は、前記第１のプロトコルのためのレイヤーおよび前記第１のプロトコルの上位に前記ネットワークスタックの１つ以上のレイヤーを備え、前記ネットワークスタックの第１の部分は、前記第１のプロトコルのレイヤーの下位に前記ネットワークスタックの１つ以上のレイヤーを備える。前記システムは、前記ネットワークスタックの前記第１の部分の廃止を生じさせる、前記ネットワーク接続内の混乱を検出するための検出器を備える。前記システムのオペレーションに際し、また前記検出器による前記廃止の検出に応じて、前記エージェントは、前記混乱中に、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持する。前記エージェントが、前記セッションおよび前記ネットワークスタックの前記第２の部分を保持しながら、前記クライアントは、前記ネットワークスタックの前記第１の部分および前記ネットワーク接続を再確立する。
【００６１】
本発明のシステムの一実施態様では、前記エージェントは、前記ネットワークスタックの前記保持された第２の部分および前記ネットワークスタックの前記再確立された第１の部分との前記セッションを継続する。いくつかの実施態様では、前記ネットワークの前記第１の部分および／または前記第２の部分は、混乱中に受信したあらゆるネットワークパケットをドロップする。
【００６２】
一実施態様では、前記システムの前記デバイスは、リモートアクセスゲートウェイまたは別のコンピューティングデバイスを備える。前記第１のプロトコルは、１）セキュアソケットレイヤー（ＳＳＬ）プロトコル、２）トランスポートレイヤーセキュリティ（ＴＬＳ）プロトコル、および３）トンネリングプロトコルのうちの１つを備えることが可能である。別の実施態様では、本発明のエージェントは、前記クライアントおよび前記デバイスとの間の前記セッションを介して、リアルタイムデータを通信する。前記リアルタイムデータは、リアルタイムプロトコルまたは、音声またはオーディオの表現を含むことが可能である。
【００６３】
前記システムのいくつかの実施態様では、前記エージェントは、前記クライアントのオペレーティングシステムのユーザーモードで動作する。前記システムの一実施態様では、前記ネットワークの前記第１の部分は、トランスポート制御プロトコルおよび／またはインターネットプロトコルを備える。別の実施態様では、前記ネットワークスタックの前記第２の部分は、１）インターネットプロトコル、２）ユーザーデータグラムプロトコル、または３）ボイスオーバーＩＰのうちの１つを備える。加えて、前記クライアントは、リモートディスプレイプロトコルを介してデバイスと通信することが可能であり、独立コンピューティングアーキテクチャ（ＩＣＡ）プロトコルまたはリモートデスクトッププロトコル（ＲＤＰ）であってよい。
【００６４】
別の実施態様では、本発明のシステムは、前記ネットワークスタックの前記第２の部分を保持し、前記ネットワーク接続を介して通信する前記クライアントのアプリケーションに、前記ネットワークスタックの前記第１の部分を透過的に再確立する。一実施態様では、前記エージェントは、前記クライアントのアプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトする。一実施態様では、前記システムはまた、前記スタックの前記第２の部分に関連付けられたネットワークドライバによって、前記クライアント上の前記アプリケーションに対して、前記アプリケーションに関連付けられた１つ以上のネットワークパケットを透過的にインターセプトするステップを含む。
【００６５】
本発明の様々な実施態様の詳細を、以下の添付図面および説明に記載する。
【発明を実施するための最良の形態】
【００６６】
（説明）
上述の本発明の他の目的、側面、特徴、および利点は、添付図面とともに以下の説明を参照することによって、より明らかになり、より適切に理解されるであろう。
【００６７】
以下、本発明の実施態様について説明する。しかし、本発明は、これらの実施態様に限定されなるものではなく、むしろその趣旨は本願明細書に明白に開示した内容への追加および変更が本発明の範囲に明白に含まれるということに留意されたい。さらに、本願明細書に開示される種々の実施態様の特徴は排他的でなく、本願明細書に組み合わせまたは置き換えが表されていなくても、本発明の精神と範囲から逸脱することなく、当該の組み合わせおよび置き換えが存在しうると理解されたい。
【００６８】
本発明の例示的実施態様は、概してピアツーピア通信およびリモートアクセス接続性を提供するためのリモートアクセスアーキテクチャに関する。一例示的実施態様では、本発明のリモートアクセスアーキテクチャは、ゲートウェイのような第３のコンピューティングデバイスを介して、ピアコンピューティングデバイス間の直接接続を確立するための方法を提供する。本発明はまた、ゲートウェイによって、またはゲートウェイなしで確立されたピアツーピア通信を最適化するための様々な方法も提供する。ピアツーピア通信には、ボイスオーバーＩＰ（ＶｏＩＰ）シグナリングのようなリアルタイム通信、およびメディア、ビデオ、およびウェブコラボレーション、スクリーンまたはデスクトップシェアリング、およびインスタントメッセージングのような他のリアルタイムデータアプリケーションが挙げられる。ゲートウェイを介したピアツーピア接続の確立に加えて、本発明はまた、ピアツーピア通信を最適化するために以下の技術を提供する。１）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットの受信の疑似確認応答。２）不可逆プロトコルを介した送信のために構築されるパケットの可逆プロトコルを介した通信を可能にする、ネットワークパケットのペイロードシフティング。３）最大送信単位（ＭＴＵ）のパラメータを調整することによって、パケットフラグメンテーションを削減し、暗号化によるオーバーヘッドを補う。４）クライアント側ネットワーク通信のアプリケーション認識の優先順位付け。５）モバイルクライアントに対してなどの、信頼性が高く、永続的なネットワーク接続およびアクセスのためのネットワークの混乱の防止。これらの技術は、いくつかの実施態様では、２つのクライアント間のピアツーピア通信において、または他の実施態様では、クライアントとのゲートウェイとの間の通信、または本発明の一例示的実施態様のＳＳＬ  ＶＰＮゲートウェイを介するなどの、別のコンピューティングデバイスへのゲートウェイを介した１つのコンピューティングデバイス間の通信において、実施することが可能である。
【００６９】
本発明の例示的実施態様では、ピアツーピア経路最適化技術は、クライアントがゲートウェイを介してアクセスしようとするリソースへのより最適な経路を決定する。クライアントおよびサーバーまたはピアコンピュータのようなクライアントがアクセスするリソースは、ゲートウェイを介するよりも直接的な経路を有することが可能である。例えば、クライアントおよびサーバーは、ゲートウェイからは離して、互いに近くに配置することが可能であるので、ゲートウェイを介するよりも互いに近くなる。さらに、ゲートウェイを利用することによって、クライアントとサーバーとの間のエンドツーエンドのネットワーク通信において、少なくとも１つの追加ホップが生じる。インターネットプロトコル（ＩＰ）ネットワークアドレスを割り当てた、クライアントおよびサーバーの仮想プライベートネットワークを使用したゲートウェイを介して通信するクライアントおよびサーバーの代わりに、本発明のゲートウェイおよびリモートアクセスアーキテクチャは、ゲートウェイを使用せずに、ピアツーピア様式の直接経路を介した、互いの通信を容易にする。しかし、場合によっては、クライアントおよびサーバーは、クライアントおよび／またはサーバーのいずれかが、ネットワークアドレス変換（ＮＡＴ）ファイアウォールのような、ファイアウォールの背後にある場合があるので、互いの間の直接経路を持たない場合がある。本発明のピアツーピア経路最適化技術およびリモートアクセスアーキテクチャはまた、クライアントおよびサーバーが、ファイアウォールのトラバースを介して直接通信するための技術も提供する。このように、本発明のピアツーピア経路最適化技術は、ゲートウェイを介するよりも、ピアコンピュータ間のより短くより最適な経路を提供する。
【００７０】
本発明の例示的実施態様では、本発明の実施態様の疑似確認応答技術によって、不可逆プロトコルを介して送信されるように構成したパケットを、可逆プロトコルを介して通信することが可能となる。例えば、リアルタイムプロトコル（ＲＴＰ）は、ボイスオーバーＩＰ（ＶｏＩＰ）通信に、ユーザーデータグラムプロトコル（ＵＤＰ）を通じて実行することができる。いくつかのリアルタイムの音声アプリケーションでは、ネットワークパケットを順に獲得したり、ネットワークパケットの配信を保証したりするのではなく、ネットワークパケットを遅れずに受信者に獲得させることがより重要になりうるので、ＵＤＰのような不可逆または信頼できないプロトコルを、音声通信に使用することが可能である。しかし、セキュアソケットレイヤー（ＳＳＬ）またはトランスポートレイヤーセキュリティ（ＴＬＳ）のような、安全な通信および／またはトンネリングプロトコルを使用した仮想プライベートネットワークおよびリモートアクセスソリューションによって、ＵＤＰのような不可逆プロトコルを介して送信するように構成したリアルタイムアプリケーションのデータは、トランスポート制御プロトコル（ＴＣＰ）のような可逆または信頼できるプロトコルを介して通信することが可能である。
本発明の技術によって、ＵＤＰを通じたＲＴＰのような不可逆プロトコルは、ＴＣＰのような可逆プロトコルを介して通信することが可能となり、一方で、可逆プロトコルの可逆特性のうちの１つ以上が通信に適用されないようにする。本発明の例示的実施態様では、本技術は、可逆プロトコルが、プロトコルの信頼性を提供するアルゴリズムを実行しないようにするために、対応するネットワークスタックに、可逆プロトコルのネットワークパケットの受信の疑似確認応答を通信する。この技術を使用することによって、例えば、通信を安全にするために、および不可逆プロトコルのネットワークパケットを受信者に確実に獲得させるのではなく、受信者に遅れずに獲得させるために、ＴＣＰ、ＳＳＬを介するか、またはゲートウェイのトンネリングプロトコルを介するなどして、可逆プロトコルを通じて不可逆プロトコルを通信することができる。一実施態様では、この技術は、ピア間のＳＳＬまたはＴＬＳを通じて、またはゲートウェイを介して、ＶｏＩＰのようなリアルタイムデータ通信を安全に通信するために使用することができる。
【００７１】
本発明の例示的実施態様はまた、不可逆プロトコルを介して送信されるように構成されたパケットを、可逆プロトコルを介して通信できるようにする、ペイロードシフティングの別の技術を提供する。第１のコンピューティングデバイスは、信頼できないトランスポートプロトコルを使用して送信される第１のパケットを受信して、受信した第１のパケットの第１のペイロードを含む第１のＴＣＰパケットを作成する。第１のＴＣＰパケットは、第１と第２のコンピューティングデバイスとの間に確立されたＴＣＰ接続に関連する情報を有する、ＴＣＰヘッダーとともに作成される。第１のＴＣＰパケットは、第２のコンピューティングデバイスに送信される。信頼できないトランスポートプロトコルを使用して送信される第２のパケットは、第１のコンピューティングデバイスによって受信され、次に、受信した第２のパケットのペイロードを含むが、第１のＴＣＰパケットのＴＣＰヘッダー情報を有する、第２のＴＣＰパケットを作成する。第２のＴＣＰパケットは、第２のデバイスから第１のＴＣＰパケットの受信の確認応答を受信する前に、第２のコンピューティングデバイスに送信される。このように、ペイロードシフティング技術は、受信の確認応答を受信するまで、ＴＣＰヘッダーの下で複数の信頼できないトランスポートプロトコルのペイロードを通信する。
【００７２】
本発明の例示的実施態様では、最大送信単位の調整技術により、ペイロードの暗号化によるネットワークパケットのサイズの影響を考慮するために、クライアントのネットワークスタックの最大送信単位（ＭＴＵ）のパラメータの報告サイズが減じられる。ネットワークパケットのペイロードの暗号化によって、クライアントに、またはクライアントによって通信されるネットワークパケットのサイズが増加し、ネットワークパケットが断片化される場合がある。例えば、サーバーは、クライアントへのＳＳＬゲートウェイを介してクライアントにネットワークパケットを通信することが可能である。サーバーは、クライアントのネットワークスタックが処理できるＭＴＵのサイズを満たさなければならない、ネットワークパケットを送信するが、ゲートウェイによって提供される暗号化は、ネットワークパケットがクライアントに到達する前に、ネットワークパケットのサイズを増加させる。これによって、暗号化によって増加したパケットサイズが、クライアントのＭＴＵのサイズに対して大きくなりすぎるので、ゲートウェイを介してサーバーからクライアントに通信されるネットワークパケットが断片化される。本発明の技術は、暗号化のオーバーヘッドを補うことを考慮するために、クライアントの報告されたＭＴＵのサイズを調整して、より小さなサイズを報告する。本技術では、ネットワークのフラグメンテーションを減じるか、あるいは最適でないフラグメンテーションを回避する。
【００７３】
本発明の例示的実施態様では、優先順位付け技術は、ネットワーク通信のクライアント側およびアプリケーション認識の優先順位付けを提供する。すなわち、本発明のリモートアクセスクライアントは、クライアント上のネットワーク通信の優先順位付けを管理および制御する。優先順位付けは、クライアント上のアプリケーションの優先順位に基づく。リモートアクセスクライアントは、クライアント上で実行しているアプリケーションに関連付けられたネットワーク通信を透過的にインターセプトし、そのネットワーク通信がアプリケーションに関連付けられていることを検出し、そのアプリケーションの優先順位に基づいて、ネットワーク通信の優先順位を決定する。例えば、クライアント上のアプリケーションは、ピアクライアントに、またはゲートウェイを介して、ＶｏＩＰのようなリアルタイムデータ通信を通信している場合がある。リモートアクセスクライアントは、ネットワークパケットをインターセプトし、例えば、そのネットワークパケットがリアルタイムデータを含むこと、またはそれがＶｏＩＰアプリケーションからのものであること、を検出することが可能である。リモートアクセスクライアントは、ネットワークパケットを、非リアルタイムデータ通信の前に、または他のアプリケーションからのネットワーク通信の前に通信することが可能であるように、このネットワークパケットの優先順位を示すことが可能である。このように、本発明の優先順位付け技術は、クライアント上で実行されているアプリケーションに基づいて、クライアントの性能、動作特性、およびユーザーエクスペリエンスを改善または向上させることが可能である。
【００７４】
本発明の例示的実施態様では、ネットワークの混乱から保護する技術は、ピアツーピア通信セッションまたはゲートウェイへの接続のような、永続的かつ信頼できるネットワークへのクライアントの接続を提供する。例えば、ソフトウェアベースのＩＰ電話を有するラップトップのようなモバイルクライアントは、ＶｏＩＰ通信のためのネットワークに接続することが可能である。モバイルクライアントが同じネットワーク内の異なるアクセスポイント間を移動するとき、またはクライアントが（例えば、有線ネットワークから無線ネットワークに）ネットワークを切り替えるとき、ネットワーク内に一時的な混乱が生じる場合がある。これは、クライアントへのネットワークサービスを混乱させ、ＶｏＩＰ通話をドロップする場合がある。加えて、モバイルクライアントはアクセスポイント間の移動するので、モバイルクライアントは、新しい動的ホスト構成プロトコル（ＤＨＣＰ）リースなどから、異なるＩＰネットワークアドレスを取得する場合がある。また、これによって、ネットワーク接続およびＶｏＩＰ電話通信に混乱が生じる場合がる。本発明の技術は、ネットワーク内の混乱を検出し、ネットワークの混乱からネットワークスタックの一部を保護する。ネットワークスタックの他の部分を再確立してネットワークに再接続しながら、ネットワークスタックの保護された部分が保持される。ネットワークが利用可能になった時点で、本発明は、クライアントのネットワーク通信を継続する。いくつかの実施態様では、ネットワーク通信は、ネットワークの混乱中にキューに入れられて、ネットワークが利用可能になった時点で送信される。リアルタイムデータ通信のためなどの他の実施態様では、ＶｏＩＰ通話のようなリアルタイムの通信における待ち時間を生じさせる可能性のある、ネットワークパケットの待ち行列を回避するために、混乱中にネットワークパケットがドロップされる。
【００７５】
本発明の例示的実施態様は、概して、トランスポート制御プロトコル（ＴＣＰ）またはユーザーデータグラムプロトコル（ＵＤＰ）のようなインターネットプロトコル（ＩＰ）ベースのプロトコルに関して記述される場合があるが、本発明の技術は、逐次パケット交換（ＳＰＸ）プロトコルを使用したあらゆるＩｎｔｅｒｎｅｔｗｏｒｋ  Ｐａｃｋｅｔ  Ｅｘｃｈａｎｇｅ（ＩＰＸ）プロトコルベースのネットワークのような、他のネットワークプロトコルを有する他のタイプのネットワーク環境において使用することが可能である。また、ＵＤＰのような不可逆または信頼できないプロトコル、およびＴＣＰのような可逆または信頼できるプロトコルを、本発明の一実施態様を示すために使用する場合があるが、当業者に公知のあらゆる可逆／信頼できるプロトコル、および不可逆／信頼できないプロトコルを、本願明細書に記述される本発明のオペレーションの実施において使用することが可能である。さらに、本発明のいくつかの例示的実施態様を、ＶｏＩＰのようなリアルタイムデータ通信に関して下記に記述するが、本発明の技術は、当業者が認識および理解されるであろう、非リアルタイムデータ通信に適用することが可能である。
【００７６】
加えて、本発明の例示的実施態様は、時にピアツーピア通信に関して記述する場合がある。一側面では、ピアツーピアモデルは、他のコンピュータにそのリソースへのアクセスを提供することによってサーバーとしての役割を果たすことができ、また他のコンピュータから共有リソースにアクセスすることによってクライアントとしての役割を果たすことができるタイプのネットワークを備える。別の側面では、ピアツーピアモデルは、クライアントおよびサーバーという概念を含まない場合があるが、クライアントおよびサーバーは、クライアントツークライアント、サーバーツーサーバー、またはクライアント／サーバー対ゲートウェイのようなコンピューティングデバイスと同様に、ピアツーピア通信を提供することが可能である。更なる側面では、ピアツーピア通信は、コンピュータ間で、第三者ネットワークまたはゲートウェイのようなデバイスの補助を受けずに、互いに情報を交換することができるプロセスを有する。ピアツーピア通信は、概してコンピュータ間の直接通信として記述される場合があるが、例えばネットワークハブのような、送信および／または通信を容易にするために、コンピューティングデバイス間に他のネットワーク要素が存在する場合がある。
【００７７】
さらに、本発明の例示的実施態様では、ピアツーピア、ポイントツーポイント、クライアントツーサーバー、その他を記述している場合があるが、当業者は、本発明が、あらゆるネットワーク技術を介して、あらゆる方法によってコンピューティングデバイス間で実施することが可能であり、ピアツーピア、クライアント／サーバー、その他のあらゆる記述は、本発明を制限しようとするものではないことを認識および理解されよう。
【００７８】
一側面では、本発明は、ゲートウェイを介してネットワークへ通信するためのリモートアクセスクライアント、または別のリモートアクセスクライアントまたは別のコンピューティングデバイスへのピアツーピアを有する、リモートアクセスアーキテクチャに関する。本発明のリモートアクセスアーキテクチャは、ゲートウェイの背後のプライベートネットワークと、パブリックネットワークのような外部ネットワーク上のクライアントとの間で送信される、ネットワークトラフィックを安全に通信するためのシステムおよび方法を提供する。本発明のリモートアクセスアーキテクチャでは、ゲートウェイにネットワークアドレス変換（ＮＡＴ）機能を提供することによって、プライベートネットワークからクライアントを分離できるようにする。ネットワークアドレス変換（ＮＡＴ）を使用するＶＰＮゲートウェイは、プライベートネットワークをクライアントによる直接的なレイヤー２アクセスから保護するために、クライアントのＩＰアドレスのなりすましを提供する。
【００７９】
図１Ａを参照する。環境１８０は、本発明の一例示的実施態様にリモートアクセスアーキテクチャを展開するためのシステムを示す。概略的に、環境１８０は、１つ以上のネットワーク接続３４１ａ−３４１ｎを介して、ネットワーク１０４に接続される複数のコンピューティングデバイス１０２ａ−１０２ｃ（ここでは、クライアント１０５ａ−１０５ｃとも称する）を備える。１つ以上のクライアント１０５ａ−１０５ｎは、ゲートウェイ３５０を介して、サーバー１０２ａ、サーバーファーム１０２ｅ、またはピアコンピューティングデバイス１０２ｄに接続することが可能である。
【００８０】
各クライアント１０５ａ−１０５ｎは、図１Ｃを参照して詳述するリモートアクセスクライアント１２０ａ−１２０ｃと、１つ以上のアプリケーション３３８ａ−３３８ｎと、を備える。クライアント１０５ａ−１０５ｎのそれぞれは、あらゆるタイプおよび／または形態の好適なトンネリングまたはゲートウェイプロトコルを使用して、トンネリングまたはゲートウェイ接続３４１ａ−３４１ｎを介して、ネットワーク１０４を通じてゲートウェイ３４０に通信する。いくつかの実施態様では、ゲートウェイ接続３４１ａ−３４１ｎは、カプセル化および暗号化などを介して安全に通信するために使用することが可能であり、あるいは、リアルタイム、可逆、または不可逆プロトコルのようなあらゆるプロトコルを使用することが可能である。他の実施態様では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｎのうちの１つ以上と、コンピューティングデバイス１０２ｄ−１０２ｎのうちのいずれかとの間の仮想プライベートネットワーク接続を提供する。
【００８１】
クライアント１０５は、ネットワーク１０４のようなネットワークにアクセスする１つ以上のアプリケーション３３８を実行することができる、あらゆるタイプおよび／または形態のコンピューティングデバイス１０２とすることができる。アプリケーション３３８は、あらゆるタイプおよび／または形態のウェブブラウザ、ウェブベースのクライアント、クライアント−サーバーアプリケーション、シンクライアントコンピューティングクライアント、ＡｃｔｉｖｅＸコントロール、またはＪａｖａ（登録商標）アプレットのような、あらゆるタイプおよび／または形態のアプリケーションとするか、またはクライアント１０５上で実行できるか、またはネットワーク１０４を介して通信することができる、あらゆるタイプおよび／または形態の実行可能な命令とすることができる。アプリケーション３３８は、あらゆるタイプのプロトコルを使用することができ、例えば、ＨＴＴＰクライアント、ＦＴＰクライアント、Ｏｓｃａｒクライアント、またはＴｅｌｎｅｔクライアントとすることができる。いくつかの実施態様では、アプリケーション３３８は、リモートディスプレイまたはプレゼンテーションレベルのプロトコルを使用する。一実施態様では、アプリケーション３３８は、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ  Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ）が開発した、ＩＣＡクライアントである。他の実施態様では、アプリケーション３３８は、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）が開発した、リモートデスクトッププロトコル（ＲＤＰ）クライアントを含む。他の実施態様では、アプリケーション３３８は、ソフトＩＰ電話のような、ＶｏＩＰ通信に関連するあらゆるタイプのソフトウェアを含む。更なる実施態様では、アプリケーション３３８は、ストリーミングビデオおよび／またはオーディオのためのアプリケーションのような、リアルタイムデータ通信に関連するあらゆるアプリケーションを含む。
【００８２】
クライアント１０５ａ−１０５ｎは、同じネットワーク１０４上に存在するか、またはプライベートネットワークのような独立したネットワーク上に存在することが可能な、コンピューティングデバイス１０２ｄ−１０２ｎを介して提供されるリソースのうちのいずれかであってよい。いくつかの実施態様では、コンピューティングデバイス１０２ａ−１０２ｎは、クライアント１０５ａ−１０５ｎのネットワーク１０４から切断され、ルーティングが不可能であるネットワーク上に存在させることが可能である。一実施態様では、クライアント１０５ａ−１０５ｎのうちのいずれかは、リモートアクセスクライアント１０２ｎおよびアプリケーション３３８ｄを有するピアコンピューティングデバイス１０２ｄと通信することが可能である。例えば、アプリケーション３３８ｄは、クライアント／サーバーの一部、またはクライアント１０５ａ−１０５ｎ上のアプリケーション３３８ａ−３３８ｃのうちのいずれかにタイプする分散アプリケーションであってよい。いくつかの実施態様では、リモートアクセスクライアント１２０ａ−１２０ｎのうちのいずれかは、ゲートウェイ３４０を介してリモートアクセスクライアント１２０ｎと通信することが可能である。
【００８３】
別の実施態様では、クライアント１０５ａのうちのいずれかは、ゲートウェイ３４０を介して、アプリケーション３３８ｅを実行するサーバー１０２ｅに通信することが可能であり、例えば、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）が製作するＭｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅのような電子メールサービス、ウェブまたはインターネットサーバー、またはデスクトップシェアリングサーバー、あるいはコラボレーションサーバーを提供する、アプリケーションサーバーであってよい。いくつかの実施態様では、アプリケーション３３８ｅのうちのいずれかは、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ  Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ、Ｆｔ．）が提供するＧｏｔｏＭｅｅｔｉｎｇ．ｃｏｍ、ＷｅｂＥｘ社（Ｓａｎｔａ  Ｃｌａｒａ、Ｃａｌｉｆｏｒｎｉａ）が提供するＷｅｂＥｘ．ｃｏｍ、またはＭｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）が提供するＬｉｖｅＭｅｅｔｉｎｇ．ｃｏｍのような、あらゆるタイプのホストサービスを含むことが可能である。
【００８４】
別の実施態様では、クライアント１０５ａのうちのいずれかは、ゲートウェイ３４０を介して、サーバーファーム１０２ｎ、または単一のエンティティとして管理される１つ以上のサーバーの論理グループである、サーバーネットワークに通信することが可能である。サーバーファーム１０２ｎは、シンクライアントコンピューティングまたはリモートディスプレイのプレゼンテーションアプリケーションを提供するアプリケーション３３８ｆのような、１つ以上のアプリケーション３３８Ｎを実行することが可能である。一実施態様では、サーバー１０２ｅまたはサーバーファーム１０２ｎは、アプリケーション３３８ｅ−３３８ｎ、ＭｅｔａＦｒａｍｅまたはＣｉｔｒｉｘ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＳｅｒｖｅｒＴＭのような、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社のＣｉｔｒｉｘ  Ａｃｃｅｓｓ  ＳｕｉｔｅＴＭのいずれかの部分、および／またはＭｉｃｒｏｓｏｆｔ社のＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  Ｔｅｒｍｉｎａｌ  Ｓｅｒｖｉｃｅｓのうちのいずれかを実行する。
【００８５】
引き続き図１Ａを参照する。ゲートウェイ３４０は、他のネットワークに、１つのネットワーク上の１つ以上のコンピューティングデバイスを接続するために使用することが可能なリモートアクセスサーバーのような、あらゆるタイプおよび／または形態のゲートウェイを含むことが可能である。別の側面では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｃにプライベートネットワークへのアクセスを提供するように、仮想プライベートネットワーク接続を提供するために使用することが可能である。更なる一側面では、ゲートウェイ３４０は、２つの異種のプロトコル、またはｄｉｓｊｏｉｎｔまたは切断されたネットワークまたはシステムを変換する、ハードウェアまたはソフトウェア設定とすることが可能である。ゲートウェイ３４０は、特殊なハードウェアまたはネットワークデバイスを備えるか、またはゲートウェイとしての機能を果たすように構成されたコンピューティングデバイスとすることが可能である。
このように、ゲートウェイ３４０は、ソフトウェア、ハードウェア、またはソフトウェアおよびハードウェアを組み合わせたものを含むことができる。一実施態様では、クライアント１０５およびゲートウェイ３４０は、ＳＳＬまたはＴＬＳ、あるいはＣｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社（Ｆｏｒｔ  Ｌａｕｄｅｒｄａｌｅ、Ｆｌｏｒｉｄａ、Ｆｔ．）が製作するＣｉｔｒｉｘ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌのような、あらゆるタイプおよび／または形態のゲートウェイまたはトンネリングプロトコル３４１ａ−３４１ｎを介して通信する。
【００８６】
いくつかの実施態様では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｃから受信した暗号化パケットを解読することが可能であり、クライアント１０５ａ−１０５ｎに通信されるパケットを暗号化することが可能である。ゲートウェイ３４０は、ネットワーク１０４のようなプライベートネットワークを保護するために使用することが可能である。いくつかの実施態様では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｃを、プライベートＩＰアドレスまたはプライベートネットワークのＩＰアドレスと関連付ける。これらの実施態様のうちの１つでは、ゲートウェイ３４０がクライアント１０５ａ−１０５ｃからパケットを受信したときに、ゲートウェイ３４０は、そのパケットのＩＰアドレスをプライベートネットワークのクライアント１０５ａ−１０５ｃに関連付けられたＩＰアドレスに変換する。いくつかの実施態様では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｃとのネットワークトラフィックに、アクセス制御ポリシーを適用することが可能である。例えば、アクセス制御ポリシーは、パケットを送付先にルーティングする前に、クライアントから受信したパケットに適用することが可能である。
【００８７】
ゲートウェイ３４０の一実施態様では、フレームがＳＳＬトンネルを介してゲートウェイ３４０に入ると、パケットおよびそのペイロードを、コールバックを介して、ＳＳＬ暗号解読に機能を提供する、ユーザーモードで実行するハンドラに送る。別の実施態様では、オープンＳＳＬを使用することが可能である。他の実施態様では、ハードウェアアクセラレータを使用する。更なる一実施態様では、ゲートウェイ３４０は、リモートアクセスを提供するための１つ以上のブレードを備える。パケットが解読されると、そのパケットは、ヘッダーをアセンブルしてリモートアクセスブレードに伝える、ＨＴＴＰネットワークスタックに注入される。リモートアクセスブレードでは、パケットは、パケット内に含まれるデータのタイプによって分類される。一実施態様では、パケットは、ログインおよび登録をリクエストするＨＴＴＰヘッダーを含む。別の実施態様では、パケットは、ＴＣＰ／ＵＤＰ／ＲＡＷ／ＯＴＨＥＲ接続の確立を求める。さらに別の実施態様では、パケットは、接続固有のデータを含む。さらに別の実施態様では、パケットは、他のユーザーとのコラボレーションのような特殊機能のリクエストを含み、ユーザーディレクトリおよび存在を取り込むか、または会議やウェブキャストのような電話機能をリクエストする。リモートアクセスモジュールは、対応するサブハンドラに適切にパケットを送る。例えば、クライアント１０５は、ゲートウェイ３４０の背後のプライベートネットワーク上の特定の機械に接続を設定するようにリクエストすることが可能である。リモートアクセスモジュールは、アクセス制御モジュールを参照することが可能であり、肯定応答が返された場合は、リモートアクセスモジュールは、リクエストを許可することが可能である。いくつかの実施態様では、リモートアクセスモジュール１２０は、対応するクライアント１０５ａ−１０５ｃへのＳＳＬトンネル３４１ａ−３４１ｎに、入力フレームを関連づけるためにＮＡＴ／ＰＡＴを用いたフレーム転送モジュールを使用して、プライベートネットワークに順次フレームを注入することによって、そのリクエストを許可することが可能である。
【００８８】
図１Ａに示されるように、ネットワーク１０４は、あらゆるタイプのネットワークとすることができる。ネットワーク１０４は、企業イントラネットのようなローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、またはインターネットやワールドワイドウェブのようなワイドエリアネットワーク（ＷＡＮ）とすることができる。ネットワーク１０４のトポロジは、バス、スター、またはリングネットワークトポロジであってよい。ネットワーク１０４およびネットワークトポロジは、本願明細書に記述される本発明のオペレーションに対応できる、ネットワークまたはネットワークトポロジのいずれかであってよい。クライアント１０８およびゲートウェイ３４０は、様々な接続を介して１つ以上のネットワーク１０４に接続することができる。該接続には、標準電話線、ＬＡＮまたはＷＡＮリンク（例、Ｔ１、Ｔ３、５６  ｋｂ、Ｘ．２５、ＳＮＡ、ＤＥＣＮＥＴ）、ブロードバンド接続（例、ＩＳＤＮ、Ｆｒａｍｅ  Ｒｅｌａｙ、ＡＴＭ、Ｇｉｇａｂｉｔ  イーサネット（登録商標）、イーサネット（登録商標）オーバーＳＯＮＥＴ）、および無線通信、またはそれらを組み合わせたものが挙げられる。接続は、様々な通信プロトコル（例、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、イーサネット（登録商標）、ＡＲＣＮＥＴ、ファイバ分散データインターフェース（ＦＤＤＩ）、ＲＳ２３２、ＩＥＥＥ  ８０２．１１、ＩＥＥＥ  ８０２．１１ａ、ＩＥＥＥ  ８０２．１１ｂ、ＩＥＥＥ  ８０２．１１ｇ、および、直接的な非同期接続）を使用して確立することができる。
【００８９】
本発明の一実施態様では、図１Ａに示されるゲートウェイ３４０は、コンピューティングデバイス１０２ａ−１０２ｎ間の直接的なピアツーピア接続を容易にするために使用される。例えば、クライアント１０５ａは、ピアコンピューティングデバイス１０２ｄにアクセスするために、ゲートウェイ３４０とのトンネリングセッションを確立することが可能である。ゲートウェイ３４０は、クライアント１０５ａが、ゲートウェイ３４０をトラバースせずにコンピューティングデバイス１０２ｄに直接接続できるようにするために、クライアント１０５ａのリモートアクセスクライアント１２０ａおよびコンピューティングデバイス１０２ｄのリモートアクセスクライアント１２０ｎによってネゴシエートする。クライアント１０５ａとコンピューティングデバイス１０２ｄとの間のネットワーク接続が確立されると、クライアント１０５ａは、コンピューティングデバイス１０２ｄとピアツーピア様式で通信することができる。本発明のゲートウェイ３４０は、環境１８０内に示されるコンピューティングデバイス１０２ａ−１０２ｎのいずれかの間の直接的なピアツーピア接続を容易にすることができる。一実施態様では、ゲートウェイ３４０は、例えば、クライアント１０５ａとクライアント１０５ｂとの間、またはクライアント１０５ｂとクライアント１０５ｃとの間などの、クライアント１０５ａ−１０５ｎのうちのいずれかの間のピアツーピア接続を容易にすることができる。別の実施態様では、ゲートウェイ３４０は、例えば、コンピューティングデバイス１０２ｄと１０２ｅまたはサーバーファーム１０２ｎとの間などの、コンピューティングデバイス１０２ｄ−１０２ｎ間のピアツーピア接続を容易にする。他の実施態様では、ゲートウェイ３４０は、クライアント１０５ａ−１０５ｎのうちの１つと、コンピューティングデバイス１０２ｄ−１０２ｎのうちの１つとの間のピアツーピア接続を容易にする。ゲートウェイ３４０を介してピアツーピア接続を容易にする技術は、図２Ａおよび２Ｂを参照して以下に詳述する。
【００９０】
図１Ｂを参照する。本発明のリモートアクセスクライアント１２０は、ゲートウェイ３０４のないピアツーピア接続の例示的実施態様において使用することが可能である。例えば、ゲートウェイ３４０は、図１に示されるコンピューティングデバイス１０２ａ−１０２ｎのうちののいずれかの間のピアツーピア接続を容易にすることが可能であり、その後、コンピューティングデバイス１０２ａ−１０２ｎは、ピアツーピア様式で互いに直接通信する。他の実施態様では、任意のコンピューティングデバイス１０２ａは、接続を容易にするゲートウェイ３４０を用いずに、ネットワーク１０４を介して、別のコンピューティングデバイス１０２ｂまたは１０２ｃに直接通信することが可能である。
【００９１】
図１Ｂの概略では、リモートアクセスクライアント１２０ａは、１つ以上のアプリケーション３３８ａを実行するクライアント１０２ａ上に展開することが可能である。コンピューティングデバイス１０２ａは、ネットワーク１０４を通じて、コンピューティングデバイス１０２ｂおよび／またはコンピューティングデバイス１０２ｃに接続することが可能である。コンピューティングデバイス１０２ｂはまた、リモートアクセスクライアント１２０ｂも備えるピアまたはクライアントコンピューティングデバイスであってよい。いくつかの実施態様では、リモートアクセスクライアント１２０ａおよび１２０ｂは、ネットワーク１０４を介して互いに通信することが可能であり、アプリケーション３３８ａが、ウェブベースまたはクライアント／サーバーアプリケーションのようなアプリケーション３３８ｂに通信するように、互いに連携して機能することが可能である。他の実施態様では、リモートアクセスクライアント１２０ａは、リモートアクセスクライアント１２０を実行しないサーバーであってよいコンピューティングデバイス１２０ｃと通信することが可能である。
【００９２】
図１Ｃは、クライアント１０５からネットワーク１０４にネットワークパケットをルーティングするためのリモートアクセスクライアントを有するシステムを示す、ブロック図を示す。概略的に、システムは、アプリケーションまたはユーザースペースとも称される、ユーザーモード３３２を含むオペレーティングシステムを有するコンピューティングデバイス１０２（本願明細書では、クライアント１０５と称する）と、カーネルまたはシステムレベルスペースとも称される、カーネルモード３３４と、を含む。クライアント１０５は、一実施態様では、ユーザーモード３３２で動作することが可能な、エージェント３２６を実行する。クライアント１０５はまた、一実施態様では、カーネルモードまたはカーネル空間３３４で実行することが可能な、フィルタ３２２も実行する。一実施態様では、フィルタ３２２およびエージェント３２６は、ネットワークを介してパケットをルーティングするための、または本願明細書に記述される本発明のオペレーションに従ってリモートアクセス接続を提供するための、リモートアクセスクライアント１２０を形成する。リモートアクセスクライアント１２０、またはエージェント３２６またはフィルタ３２２のようなその任意の部分は、ユーザーモード３３２またはカーネルモード３３４で実行することが可能である。
【００９３】
クライアント１０５はまた、当業者が認識および理解するであろう、ネットワークスタック３１０も有することが可能であり、開放型システム間相互接続（ＯＳＩ）の通信モデルのネットワークレイヤーのような、１つ以上のネットワークレイヤーを備えることが可能である。ネットワークスタック３１０は、当業者が認識および理解するであろう、イーサネット（登録商標）を通じたＴＣＰ／ＩＰプロトコルまたはＩＥＥＥ  ８０２．１１のような無線プロトコルなどの１つ以上のプロトコルを備えることが可能である。さらに、ネットワークスタック３１０は、ＴＣＰドライバまたはネットワークレイヤードライバのような、１つ以上のレイヤーに対応する１つ以上のネットワークドライバを含むことが可能である。ネットワークドライバは、コンピューティングデバイス１０２のオペレーティングシステムの一部として、またはネットワークインターフェースカードあるいはコンピューティングデバイス１０２の他のネットワークアクセスコンポーネントの一部として、含むことが可能である。加えて、ネットワークスタック３１０のネットワークドライバのうちのいずれかは、本願明細書に記述される本発明の技術のうちのいずれかに対応する、ネットワークスタック３１０のカスタムまたは改良部分を提供するようにカスタマイズ、改良、または構成することが可能である。加えて、ネットワークスタック３１０のいくつかの部分はカーネルモード３３４で動作することが可能であり、一方で他の部分は、ネットワークスタック３１０のアプリケーションレイヤーのような、ユーザーモード３３２で実行することが可能である。
【００９４】
フィルタ３２２は、パケット取得機構３６５を備えることが可能であり、フィルタ３２２および／またはパケット取得機構３６５は、クライアント１０５のネットワークスタック３１０の任意のレイヤーまたはその一部分で動作するネットワークドライバのような、ネットワークドライバを含むことが可能である。フィルタ３２２および／またはパケット取得機構３６５は、ネットワークドライバインターフェース規約（ＮＤＩＳ）に適合するドライバ、すなわちＮＤＩＳドライバを備えることが可能である。別の実施態様では、フィルタ３２２および／またはパケット取得機構３６５は、ミニフィルタまたはミニポートドライバを備えることが可能である。パケット取得機構３６５はまた、いくつかの実施態様では、カーネルモード３３４で動作することが可能である。パケット取得機構３６５は、フィルタ３２２の一部として示されているが、パケット取得機構３６５は、フィルタ３２２から分離していてもよい。加えて、フィルタ３２２およびパケット取得機構３６５は、クライアント１０５のネットワークスタックの異なるレイヤーまたはその一部で動作することが可能である。
【００９５】
フィルタ３２２は、パケットをフィルタリングするためのフィルタテーブルを使用することが可能である。フィルタリングテーブルは、パケット取得機構３６５によってインターセプトされるパケットのようなパケットに対して、どのアクションを行うべきかを決定するために使用される。フィルタ３２２は、フィルタリングテーブルに基づいて行うアクションを決定するために、ルーティング情報のようなパケットのコンテンツを調査することができる。いくつかの実施態様では、フィルタ３２２は、それらのコンテンツに基づいて、ネットワークパケットをドロップまたは承認することが可能である。他の実施態様では、フィルタ３２２は、パケットコンテンツおよび／またはフィルタリングテーブルに基づいて、エージェント３２６にネットワークパケットをルーティングすることが可能である。フィルタテーブルはまた、不要なパケットが破棄されることを確認するために使用することも可能である。フィルタ３２２は、特定の宛先アドレスへのパケットを破棄することによって、特定のプロトコルへのアクセスを拒否するために、またはリモートコンピュータからの無許可のアクセスを回避するために使用することが可能である。
【００９６】
いくつかの実施態様では、フィルタリングテーブルは、プライベートネットワークに関する情報を含む。他の実施態様では、クライアントコンピューティングデバイス１０２上のフィルタ３２２は、フィルタリングテーブルを受信する。これらの実施態様のうちの１つでは、フィルタ３２２は、アプリケーション３３８から、またはコンピューティングデバイス１０２上のエージェント３２６から、フィルタリングテーブルを受信する。これらの実施態様のうちの別のものでは、フィルタ３２２は、エージェント３２６から構成設定を受信して、その構成設定をフィルタリングテーブルに格納する。
【００９７】
パケット取得機構３６５は、アプリケーション３３８に関連付けられたネットワークパケットのような、クライアント１０５のネットワークトラフィックのうちのいずれかをインターセプトすることが可能である。いくつかの実施態様では、パケット取得機構３６５は、アプリケーション３３８、エージェント３２６、ゲートウェイ３４０、またはパケット取得機構３６５が動作するレイヤーの上位または下位で動作する他のドライバまたはレイヤーのような、クライアント１０５のネットワークスタック３１０のいずれかの部分に、ネットワークトラフィックを透過的にインターセプトする。このように、本発明は、本願明細書に記述される技術のうちのいずれかとともに使用すること、およびそれらに対応することができ、アプリケーションおよびそのアプリケーションによって使用されるプロトコルに使用することができる。一実施態様では、パケット取得機構３６５は、ネットワーク１０４および／またはゲートウェイ３４０を介して通信される任意のネットワークトラフックのような、送信パケットトラフィックをインターセプトする。パケット取得機構３６５は、エージェント３２５またはエージェント３２６のフレームモニター機構３６０にパケットを転送することが可能である。いくつかの実施態様では、フィルタ３２２は、非同期のＩ／Ｏ制御メッセージを介してエージェント３２６と通信する。これらの実施態様のうちの１つでは、パケット取得機構３６５は、非同期のＩ／Ｏ制御メッセージを介して、ゲートウェイ３４０の背後のプライベートネットワークに宛てたパケットを転送することが可能である。他の実施態様では、フィルタ３２２は、ＵＤＰパケットを介してユーザースペース３３４で動作するエージェント３２６と通信する。一実施態様では、フィルタ３２２は、非同期のＩ／Ｏ制御メッセージを介して、エージェント３２６ドライバから構成設定を受信する。構成設定は、フィルタ処理するネットワーク、プロトコル、またはパケットのタイプに関する情報を含むことが可能である。一実施態様では、フィルタ３２２は、フィルタリングテーブルに構成設定を格納する。別の実施態様では、フィルタ３２２は、構成設定を含むフィルタリングテーブルを受信する。
【００９８】
一実施態様では、フィルタ３２２は、検査のためにクライアント１０５の全ての送信パケットをインターセプトする。例えば、いくつかの実施態様では、フィルタは、クライアント１０５による送信のために、ユーザーモード３３２実行するアプリケーション３３８によって生成されたパケットをインターセプトする。パケットがフィルタリングテーブル内にリストされた条件を満たした場合、フィルタ３２２は、パケットの元の宛先ではなく、エージェント３２６にパケットを送信することが可能である。フィルタ３２２は、エージェント３２６にパケットを転送するために、非同期のＩ／Ｏ制御メッセージを使用することが可能である。フィルタ３２２は、ルーティングテーブルに従って、またはこれに応答して、エージェント３２６にパケットを送信することが可能である。
【００９９】
いくつかの実施態様では、エージェント３２６およびフィルタ３２２は、ＩＯＣＴＬライブラリおよびオペレーティングシステムのＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ファミリによって提供されるファンクションコールのような、ＩＯＣＴＬのアプリケーションプログラミングインタフェース（ＡＰＩ）を介して通信する。他の実施態様では、エージェント３２６とフィルタ３２２との間のＩＯＣＴＬベースのインターフェースは、クライアント１０５上で実行するオペレーティングシステムの任意の部分によって提供することが可能である。Ｉ／Ｏ制御メッセージおよびＩＯＣＴＬインターフェースに関して述べられているが、エージェント３２６およびフィルタ３２２は、あらゆる好適な機構および／または手段を介して通信することが可能である。
【０１００】
クライアント１０５のカーネル３３４は、ＮＤＩＳインターフェースを備えることが可能である。いくつかの実施態様では、ＮＤＩＳインターフェースは、複数の中間フィルタを備える。一実施態様では、パケットは、ＮＤＩＳインターフェースを通り、複数の中間フィルタによって調査することが可能である。フィルタ３２２は、ＮＤＩＳドライバとして提供することが可能であるが、フィルタ３２２はまた、カーネル３３４で実行するプロセス、または他のセットまたはタイプの実行可能な命令であってもよい。
【０１０１】
本発明のエージェント３２６は、クライアント１０５上のアプリケーションスペース３３２またはユーザーモードで実行することが可能である。他の実施態様では、エージェント３２６は、カーネルモード３３４で動作する。いくつかの実施態様では、エージェント３２６は、フィルタ３２２からパケットを受信するための機能を提供する。他の実施態様では、エージェント３２６は、受信したパケットにポリシーを提供するための機能を提供する。さらに別の実施態様では、エージェント３２６は、ゲートウェイ３４０へのＳＳＬトンネルを管理するための機能を提供する。さらに他の実施態様では、エージェント３２６は、ゲートウェイ３４０へのパケットを暗号化して送信するための機能を提供する。エージェント３２６は、フレームモニター機構３６０を備えることが可能である。フレームモニター３６０は、受信したパケットにポリシーを適用するためのポリシーおよびロジックを含むことが可能である。エージェント３２６は、フレームモニター３６０が行うポリシーベースの決定に応答するゲートウェイ３４０に、パケットを送信することが可能である。
【０１０２】
いくつかの実施態様では、フレームモニター３６０は、パケットの送信時に、クライアント１０５の状態またはエンドポイントを判断するために、ポリシーを適用することが可能である。他の実施態様では、フレームモニター３６０は、パケットを生成したアプリケーション３３８を識別することが可能である。これらの実施態様にいくつかでは、識別されたアプリケーション３３８に応答するゲートウェイ３４０にパケットを送信するために、ポリシーベースの決定を行うことが可能である。別の実施態様では、フレームモニター３６０は、識別されたアプリケーションが実際にパケットを生成したことを確認するために、パケットにチェックサムを行うことが可能である。
【０１０３】
他の実施態様では、パケット取得機構３６５は、フィルタ３２２の代わりに、またはこれに加えてエージェント３２６内に含めることが可能である。このように、エージェント３２６は、ネットワークトラフィックをインターセプトすることが可能である。パケット取得機構３６５は、アプリケーション３３８に関連付けられたネットワークトラフィックのような、クライアント１０５の受信および／または送信パケットを、インターセプト、フック、または取得するために、任意のフッキングのアプリケーションプログラミングインタフェース（ＡＰＩ）を使用することが可能である。
【０１０４】
一実施態様では、ＴＣＰ接続は、図１Ｂのコンピューティングデバイス１０２ｃ、または図１Ａのゲートウェイ３４０のような、ターゲットコンピューティングデバイスにＩＰパケットを送信するために、クライアント１０５上で実行するアプリケーション３３８によって開始される。リモートアクセスクライアント１２０は、アプリケーション３３８によって生成されるＩＰパケットをインターセプトまたは取得することが可能である。リモートアクセスクライアント１２０は、アプリケーション３３８にＴＣＰ確認応答パケットを送信して、アプリケーション３３８によって開始されたＴＣＰ接続を終了させることが可能である。次いで、リモートアクセスクライアント１２０は、第２のコンピューティングデバイス１０２ｃまたはゲートウェイ３４０への第２のＴＣＰ接続を作成して、この第２のＴＣＰ接続を介して、取得したＩＰパケットを送信する。いくつかの実施態様では、リモートアクセスクライアント１２０は、取得したＩＰパケットをバッファに格納することが可能である。これらの実施態様では、リモートアクセスクライアント１２０は、第２のコンピューティングデバイス１０２ｃへの第２のＴＣＰ接続を介して、バッファリングしたＩＰパケットを送信することが可能である。取得したＩＰパケットをバッファに格納することによって、ネットワーク接続の混乱時のパケットの保護が可能になる。
【０１０５】
一実施態様では、取得したＩＰパケットを受信すると、ゲートウェイ３４０は、図１Ａにあるような、ゲートウェイ３４０とターゲットコンピューティングデバイスとの間の第３のＴＣＰ接続を作成することが可能である。ゲートウェイ３４０は、ポートマップドネットワークアドレス変換（ＮＡＴ）テーブルを保持することが可能であり、これによって、ゲートウェイ３４０は、ターゲットコンピューティングデバイス１０２ｄから、クライアント１０５上でＩＰパケットを生成したアプリケーション３３８によって監視されるポートに、応答パケットを送信することが可能となる。クライアント１０５は、ゲートウェイ３４００のパブリックネットワークアドレスとだけ通信するので、クライアント１０５は、ターゲットコンピューティングデバイス１０２ｄのネットワークアドレスに気付かず、ターゲットコンピューティングデバイス１０２ｄが存在するネットワークに対するセキュリティを向上させる。同様に、ゲートウェイ３４０がターゲットコンピューティングデバイス１０２ｄへのＴＣＰ接続を生じさせるので、ターゲットコンピューティングデバイス１０２ｄは、クライアント１０５のアドレス情報を受信せず、クライアント１０５およびそれが存在するネットワークが保護される。加えて、ゲートウェイ３４０がＩＰパケットを受信するので、ゲートウェイ３４０は、ＩＰパケットをターゲットコンピューティングデバイス１０２ｄへ送信するべきかどうかに関して、ポリシーまたはセキュリティチェックに応答する判断を行うことが可能であり、ターゲットコンピューティングデバイス１０２ｄが存在するネットワークに対する保護がさらに強化される。
【０１０６】
一実施態様では、本発明は、ゲートウェイ３４０の背後のプライベートの保護されたネットワークから、外部ネットワーク１０４上のクライアント１０５に送信されるパケットを保護するための方法を提供する。本発明は、ゲートウェイ３４０にネットワークアドレス変換（ＮＡＴ）機能を提供することによって、プライベートネットワークからクライアント１０５を分離できるようにする。ＮＡＴを使用するＶＰＮゲートウェイは、クライアント１０５による直接的なレイヤー２アクセスからプライベートネットワークを保護するために、クライアント１０５のＩＰアドレスのなりすましを提供する。
【０１０７】
一側面では、エージェント３２６、フレームモニター３６０、フィルタ３２２、およびパケット取得機構３６５のようなリモートアクセスクライアント１２０の任意の部分、またはそれらの任意の部分は、ソフトウェア、ＡＳＩＣまたはＦＰＧＡのようなハードウェア、またはソフトウェアおよび／またはハードウェアを組み合わせたものを備えることが可能である。いくつかの実施態様では、リモートアクセスクライアント１２０の複数の部分を、クライアント１０５上の１つ以上のブレードを介して提供することが可能である。
【０１０８】
リモートアクセスクライアント１２０は、エージェント３２６およびフィルタ３２２のような複数のコンポーネントで示されているが、当業者は、本願明細書に記述されたリモートアクセスクライアント１２０のオペレーションおよび機能は、単一の機構または単一のコンポーネントにおいて実行することが可能であることを認識および理解されよう。例えば、いくつかの実施態様では、リモートアクセスクライアント１２０のオペレーションおよび機能は、アプリケーション３３８内に含むことが可能である。一実施態様では、例えば、リモートアクセスクライアント１２０の機能およびオペレーションは、単にエージェント３２６として提供される場合があり、別の実施態様では、単にフィルタ３２２のようなネットワークドライバとして提供される場合がある。
【０１０９】
いくつかの実施態様では、リモートアクセスクライアント１２０、またはエージェント３２６、フレームモニター３６０、フィルタ３２２、およびパケット取得機構３６５のような、その任意の部分は、アプリケーション、モジュール、サービス、コンピュータプログラム、ソフトウェアコンポーネント、ウェブサービス、ウェブコンポーネント、ライブラリ、機能、プロセス、タスク、スレッド、または本願明細書に記述されるような本発明の機能を実行するように構成されて、これを実行でき、ユーザーモード３３２および／またはカーネルモード３３４の任意の部分またはその組み合わせにおいて動作することが可能な、あらゆるタイプおよび／または形態の実行可能な命令を含むことが可能である。
【０１１０】
図１Ａ乃至１Ｃに示されるように本発明のリモートアクセスクライアント１２０を展開し、通信するための種々の方法で使用することが可能であり、またゲートウェイ３４０を介して、またはピアコンピューティングデバイス間を直接介するなどして、他のコンピューティングデバイスへのネットワークを通じて、リモートアクセスを提供することが可能である。これらの種々の環境では、リモートアクセスクライアント１２０は、以下に詳述するような、本発明の１つ以上の最適化技術を実施するために使用することが可能である。例えば、リモートアクセスクライアント１２０は、ＶｏＩＰ、デスクトップシェアリング、または図１Ａ乃至１Ｃの例示的環境のいずれかにおけるウェブ会議のような、リアルタイムデータ通信を最適化するために使用することが可能である。
【０１１１】
図１Ａ乃至１Ｃの例示的実施態様では、クライアント１０５のうちのいずれか、サーバー、またはゲートウェイ３４０のような、コンピューティングデバイス１０２ａ−１０２ｎは、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社（Ｐａｌｏ  Ａｌｔｏ、Ｃａｌｉｆｏｒｎｉａ）またはＤｅｌｌ社（Ｒｏｕｎｄ  Ｒｏｃｋ、ＴＸ）が製造するその種のパーソナルコンピュータまたはコンピュータサーバーのような、あらゆるタイプおよび／または形態のコンピューティングデバイスとして提供することが可能である。図１Ｄおよび１Ｅは、本発明の実施態様を実施するのに有用なコンピューティングデバイス１０２のブロック図を示す。図１Ｄおよび１Ｅに示されるように、各コンピューティングデバイス１０２は、中央演算処理装置１０２と、メインメモリユニット１０４と、を含む。図１Ｄに示されるように、標準的なコンピューティングデバイス１０２は、視覚的表示装置１２４、キーボード１２６、および／またはマウスのようなポインティングデバイス１２７を備えることが可能である。各コンピューティングデバイス１０２はまた、１つ以上の入出力デバイス１３０ａおよび１３０ｂ（概して、参照番号１３０で示される）、および中央演算処理装置１０２と通信するキャッシュメモリ１４０のような、更なる任意の要素を含むことも可能である。
【０１１２】
中央演算処理装置１０２は、プロセス命令がメインメモリユニット１０４から取り込まれる命令に応答して処理を行う任意のロジック回路である。多くの実施態様では、中央演算処理装置は、次のようなマイクロプロセッサユニットによって提供される：８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）  Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標）  ＩＩ、Ｃｅｌｅｒｏｎ、Ｘｅｏｎプロセッサ（これらは全て、Ｉｎｔｅｌ社（Ｍｏｕｎｔａｉｎ  Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ）によって製造される）；６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、―ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、ＭＰＣ７４５７プロセッサ（これらは全て、Ｍｏｔｏｒｏｌａ社（Ｓｃｈａｕｍｂｕｒｇ、Ｉｌｌｉｎｏｉｓ）によって製造される）；Ｃｒｕｓｏｅ  ＴＭ５８００、Ｃｒｕｓｏｅ  ＴＭ５６００、Ｃｒｕｓｏｅ  ＴＭ５５００、Ｃｒｕｓｏｅ  ＴＭ５４００、Ｅｆｆｉｃｅｏｎ  ＴＭ８６００、Ｅｆｆｉｃｅｏｎ  ＴＭ８３００、またはＥｆｆｉｃｅｏｎ  ＴＭ８６２０プロセッサ（Ｔｒａｎｓｍｅｔａ社（Ｓａｎｔａ  Ｃｌａｒａ、Ｃａｌｉｆｏｒｎｉａ）によって製造される）；ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ６４ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ＩＩＩ、ＰＯＷＥＲ３−ＩＩ、ＲＳ６４ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５、またはＰＯＷＥＲ６プロセッサ（これらは全て、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ社（Ｗｈｉｔｅ  Ｐｌａｉｎｓ、Ｎｅｗ  Ｙｏｒｋ）によって製造される）；または、ＡＭＤ  Ｏｐｔｅｒｏｎ、ＡＭＤ  Ａｔｈｌｏｎ６４ＦＸ、ＡＭＤ  Ａｔｈｌｏｎ、またはＡＭＤ  Ｄｕｒｏｎプロセッサ（Ａｄｖａｎｃｅｄ  Ｍｉｃｒｏ  Ｄｅｖｉｃｅｓ社（Ｓｕｎｎｙｖａｌｅ、Ｃａｌｉｆｏｒｎｉａ）によって製造される）。コンピューティングデバイス１０２は、上述のプロセッサのうちのいずれか、または本願明細書に記述される動作が可能な他のプロセッサに基づくことが可能である。
【０１１３】
メインメモリユニット１０４は、データを格納することができ、あらゆる格納場所にマイクロプロセッサ１００が直接アクセスできるようにする、１つ以上の次のようなメモリチップとすることが可能である：スタティックＲＡＭ（ＳＲＡＭ）、バーストＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ  ＳＲＡＭ（ＢＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、高速ページモードＤＲＡＭ（ＦＰＭ  ＤＲＡＭ）、キャッシュ内蔵型高速ＤＲＡＭ（ＥＤＲＡＭ）、拡張データ出力ＲＡＭ（ＥＤＯ  ＲＡＭ）、拡張データ出力ＤＲＡＭ（ＥＤＯ  ＤＲＡＭ）、バースト拡張データ出力ＤＲＡＭ（ＢＥＤＯ  ＤＲＡＭ）、キャッシュ内蔵型高速ＤＲＡＭ（ＥＤＲＡＭ）、同期型ＤＲＡＭ（ＳＤＲＡＭ）、ＪＥＤＥＣ  ＳＲＡＭ、ＰＣ１００  ＳＤＲＡＭ、ダブルデータレートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃＬｉｎｃ  ＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトラムバス  ＤＲＡＭ（ＤＲＤＲＡＭ）、または強誘電性ＲＡＭ（ＦＲＡＭ）。メインメモリ１０４は、上述のメモリチップのうちのいずれか、または本願明細書に記述される動作が可能な他の利用可能なメモリチップに基づくことが可能である。図１Ｅに示される実施態様では、プロセッサ１００は、システムバス１５０（以下に詳述する）を介してメインメモリ１０４と通信する。図１Ｅは、プロセッサがメモリポート１０３を介してメインメモリ１０４と直接通信する、コンピューティングデバイス１０２の一実施態様を示す。例えば、図１Ｅでは、メインメモリ１０４は、ＤＲＤＲＡＭであってよい。
【０１１４】
図１Ｄおよび１Ｅは、メインプロセッサ１００が第２のバス（バックサイドバスと称することもある）を介してキャッシュメモリ１４０と直接通信する、実施態様を示す。他の実施態様では、メインプロセッサ１００は、システムバス１５０を使用してキャッシュメモリ１４０と通信する。キャッシュメモリ１４０は、一般にメインメモリ１０４よりも応答時間が速く、一般にＳＲＡＭ、ＢＳＲＡＭ、またはＥＤＲＡＭによって提供される。
【０１１５】
図１Ｄに示される実施態様では、プロセッサ１００は、ローカルシステムバス１５０を介して種々の入出力デバイス１３０と通信する。種々のバスは、入出力デバイス１３０のうちのいずれかに中央演算処理装置１０２を接続するために使用することが可能であり、ＶＥＳＡ  ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕＢｕｓが挙げられる。入出力デバイスがビデオディスプレイ１２４である実施態様に関して、プロセッサ１００は、アドバンストグラフィックポート（ＡＧＰ）を使用して、ディスプレイ１２４と通信することが可能である。図１Ｅは、メインプロセッサ１００が、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ、ＲａｐｉｄＩ／Ｏ、またはＩｎｆｉｎｉＢａｎｄを介して、入出力デバイス１３０ｂと直接通信する、コンピュータ１０２の一実施態様を示す。図１Ｅはまた、プロセッサ１００が、入出力デバイス１３０ｂと直接通信しながら、ローカルインタコネクトバスを使用して入出力デバイス１３０ａと通信するような、ローカルバスおよび直接通信を混合した、一実施態様も示す。
【０１１６】
コンピューティングデバイス１０２は、３．５インチ、５．２５インチディスクのようなフロッピディスク、またはＺＩＰディスクを受けるためのフロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々なフォーマットのテープドライブ、ＵＳＢデバイス、ハードドライブ、または本発明に関するリモートアクセスクライアントソフトウェア１２０のようなソフトウェアおよびプログラムをインストールするのに好適な他のデバイスのような、あらゆる好適なインストールデバイス１１６に対応することが可能である。
【０１１７】
コンピューティングデバイス１０２は、オペレーティングシステムおよび他の関連するソフトウェアを格納するために、また本発明のリモートアクセスクライアント１２０に関連するあらゆるプログラムのような、アプリケーションソフトウェアプログラムを格納するために、１つ以上のハードディスクドライブまたは独立した複数のディスクからなる冗長配列のような、ストレージデバイス１２８をさらに備えることが可能である。状況に応じて、インストールデバイス１１８のうちのいずれかを、ストレージデバイス１２８として使用することも可能である。加えて、オペレーティングシステムおよびプロキシソフトウェア１２０は、例えば、ｋｎｏｐｐｉｘ．ｎｅｔからのＧＮＵ／Ｌｉｎｕｘディストリビューションとして利用可能な、ＧＮＵ／Ｌｉｎｕｘ用の起動可能なＣＤであるＫＮＯＰＰＩＸ（登録商標）のような起動可能なＣＤなどの、起動可能なメディアから実行することができる。
【０１１８】
さらに、コンピューティングデバイス１０２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、または、これに限定されないが、標準電話線、ＬＡＮまたはＷＡＮリンク（例、８０２．１１、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンド接続（例、ＩＳＤＮ、Ｆｒａｍｅ  Ｒｅｌａｙ、ＡＴＭ）、無線通信、または上述の全てまたはいずれかを組み合わせたものを含む、様々な接続を介したインターネットにインターフェースするためのネットワークインターフェース１１８を備えることが可能である。ネットワークインターフェース１１８は、内蔵ネットワークアダプタ、ネットワークインターフェースカード、ＰＣＭＣＩＡネットワークカード、カードバスネットワークアダプタ、無線ネットワークアダプタ、ＵＳＢネットワークアダプタ、モデム、または本願明細書に記述された通信およびオペレーションが可能なあらゆるタイプのネットワークに、コンピューティングデバイス１０２をインターフェースするのに好適な他のデバイスを備えることが可能である。
【０１１９】
様々な入出力デバイス１３０ａ−１３０ｎを、コンピューティングデバイス１０２内に存在させることが可能である。入力装置には、キーボード、マウス、トラックパッド、トラックボール、マイクロホン、および描画タブレットが挙げられる。出力装置には、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザープリンタ、および昇華型プリンタが挙げられる。入出力デバイスは、図１Ｄに示されるように入出力コントローラ１２３によって制御することが可能である。入出力コントローラは、キーボード１２６、およびポインティングデバイス１２７（例、マウス、光ペン）のような、１つ以上の入出力デバイスを制御することが可能である。さらにまた、入出力デバイスはまた、コンピューティングデバイス１０２にストレージ１２８および／またはインストールメディア１１８を提供することも可能である。さらに別の実施態様では、コンピューティングデバイス１０２は、Ｔｗｉｎｔｅｃｈ  Ｉｎｄｕｓｔｒｙ社（Ｌｏｓ  Ａｌａｍｏｓ、Ｃａｌｉｆｏｒｎｉａ）によって製造される一連のデバイスであるＵＳＢフラッシュドライブのような、携帯型のＵＳＢストレージデバイスを受けるために、ＵＳＢ接続を提供することが可能である。
【０１２０】
更なる実施態様では、入出力デバイス１３０は、ＵＳＢバス、Ａｐｐｌｅ  Ｄｅｓｋｔｏｐ  Ｂｕｓ、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ  ８００バス、イーサネット（登録商標）バス、ＡｐｐｌｅＴａｌｋバス、Ｇｉｇａｂｉｔイーサネット（登録商標）バス、非同期転送モードバス、ＨＩＰＰＩバス、スーパーＨＩＰＰＩバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、またはシリアルアタッチドＳＣＳＩバスのような、システムバス１５０と外部通信バスとの間のブリッジ１７０とすることが可能である。
【０１２１】
図１Ｄおよび１Ｅに示される種類のコンピューティングデバイス１０２は、一般にオペレーティングシステムの制御下で動作し、タスクのスケジューリングおよびシステムリソースへのアクセスを制御する。コンピューティングデバイス１０２は、マイクロソフト（登録商標）ウィンドウズ（登録商標）オペレーティングシステムのバージョンのうちのいずれか、異なるリリースのＵｎｉｘ（登録商標）およびＬｉｎｕｘオペレーティングシステム、Ｍａｃｈｉｎｔｏｓｈコンピュータ用のＭａｃＯＳ（登録商標）のバージョンのうちのいずれか、あらゆる内蔵オペレーティングシステム、あらゆるリアルタイムオペレーティングシステム、あらゆるオープンソースオペレーティングシステム、あらゆる専用のオペレーティングシステム、モバイルコンピューティングデバイス用のオペレーティングシステム、または本願明細書に記述されたコンピューティングデバイス上で実行してオペレーションを行うことができる他のオペレーティングシステムのような、あらゆるオペレーティングシステムを実行することができる。標準的なオペレーティングシステムには、次のものが挙げられる：ＷＩＮＤＯＷＳ（登録商標）３．ｘ、ＷＩＮＤＯＷＳ（登録商標）９５、ＷＩＮＤＯＷＳ（登録商標）９８、ＷＩＮＤＯＷＳ（登録商標）２０００、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ３．５１、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ４．０、ＷＩＮＤＯＷＳ（登録商標）  ＣＥ、およびＷＩＮＤＯＷＳ（登録商標）  ＸＰ（これらは全て、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）によって製造される）；ＭａｃＯＳ（Ａｐｐｌｅ  Ｃｏｍｐｕｔｅｒ社（Ｃｕｐｅｒｔｉｎｏ、Ｃａｌｉｆｏｒｎｉａ）によって製造される）；ＯＳ／２（Ｉｎｔｅｒｎａｔｉｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ社（Ａｒｍｏｎｋ、Ｎｅｗ  Ｙｏｒｋ）によって製造される）；および、特にＬｉｎｕｘ（Ｃａｌｄｅｒａ社（Ｓａｌｔ  Ｌａｋｅ  Ｃｉｔｙ、Ｕｔａｈ）によって配信される自由に利用できるオペレーティングシステム、Ｊａｖａ（登録商標）、またはＵｎｉｘ（登録商標）。
【０１２２】
他の実施態様では、コンピューティングデバイス１０２は、デバイスと一貫性のある異なるプロセッサ、オペレーティングシステム、および入力装置を備えることが可能である。例えば、一実施態様では、コンピュータ１０２は、Ｐａｌｍ社によって製造されるＺｉｒｅ７１携帯情報端末である。本実施態様では、Ｚｉｒｅ７１は、ＰａｌｍＯＳオペレーティングシステムの制御下で動作し、５ウェイナビゲータデバイスとともに、スタイラス入力装置を備える。
【０１２３】
さらに、コンピューティングデバイス１０２は、あらゆるワークステーション、デスクトップコンピュータ、ラップトップまたはノートブックコンピュータ、サーバー、ハンドヘルドコンピュータ、携帯電話、他のコンピュータ、または通信することができ、本願明細書のオペレーションを行うに十分なプロセッサ能力およびメモリ容量を有する他の形態のコンピューティングまたは通信デバイスとすることができる。
【０１２４】
一側面では、本発明は、図１Ａ乃至１Ｃの例示的環境のうちのいずれかに示されるような、コンピューティングデバイス間の通信を最適化するための種々の技術の提供に関する。本発明は、スタンドアロンまたは任意の組み合わせにおいて、実施することが可能な以下の技術を提供する：１）ピアツーピア経路最適化、２）不可逆プロトコルを介した通信のために構成されたパケットの可逆プロトコルを介した通信、３）暗号化を補うために最大送信単位（ＭＴＵ）を調整することによるネットワークのフラグメンテーションの低減、４）クライアント側のアプリケーション認識ネットワーク通信の優先順位付け、および５）デバイスのネットワークの混乱からの保護。ピアツーピア経路最適化技術は、図２Ａおよび図２Ｂを参照して以下に説明する。不可逆プロトコルを介した通信のために構成されたパケットの可逆プロトコルを介した通信のための技術は、図３Ａおよび３Ｂを参照して説明する。ＭＴＵ調整技術は、図４を参照して説明する。クライアント側のアプリケーション認識ネットワーク通信の優先順位付けは、図５Ａおよび５Ｂを参照して説明する。ネットワークの混乱からの保護は、図６Ａおよび６Ｂを参照して説明する。
【０１２５】
一側面では、本発明は、図１Ａに示されるゲートウェイ３４０のような、ゲートウェイを介して第２のコンピューティングデバイスにアクセスする第１のコンピューティングデバイスの間のピアツーピア経路最適化技術の提供に関する。ピアツーピアルーティング技術は、ゲートウェイを介して通信セッションを確立する、または確立しようとする、コンピューティングデバイス間のより最適かつ直接的な通信を提供する。本発明の実施例の例示的方法２６０は、図２Ａの例示的環境２００を考慮して以下に説明する。概略的に、環境２００は、１０．１０．１０．ＸＸＸの範囲のＩＰアドレスを有するネットワークのような、プライベートネットワークへのリモートアクセス接続を提供する、ゲートウェイ３４０を備える。プライベートネットワークに関連したゲートウェイ３４０は、プライベートネットワーク上の通信のためのＩＰアドレス１０．１０．１０．２を割り当てておくことが可能である。このプライベートネットワークは、サーバー１０２ｃを備えることが可能である。また、プライベートネットワークは、あらゆるタイプおよび／または形態のＶｏＩＰ電話のような通信デバイス２１０ｃを備える。通信デバイス２１０ｃには、プライベートネットワークにＩＰアドレス１０．１０．１０．１００が割り当てられる。
【０１２６】
一実施態様では、サーバー１０２は、シグナリングサーバーを備え、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間などの、コンピュータデバイス間の通信セッションを確立するための、あらゆるタイプおよび／または形態のシグナリングサービスを提供することが可能である。一実施態様では、サーバー１０２ｃは、セッション開始プロトコル（ＳＩＰ）に対応する。ＳＩＰは、ビデオ、音声、チャット、ゲーム、および仮想現実のようなマルチメディア要素を伴う、双方向のユーザーセッションを開始するためのインターネット技術特別調査委員会（ＩＥＴＦ）の標準プロトコルである。一実施態様では、ＳＩＰは、開放型システム間相互接続（ＯＳＩ）の通信モデルのアプリケーションレイヤーにおいて機能する。いくつかの実施態様では、第１のコンピューティングデバイス１０２ａは、シグナリング経路２２０を介して、シグナリングサーバー１０２ｃに対して、ＳＩＰプロトコルを介するなどの、シグナリングを介してセッションを開始する。一実施態様では、ゲートウェイ３４０とともにシグナリングサーバー１０２ｃは、電話２１０ａと２１０ｂとの間のＶｏＩＰ通信セッションのためのような、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間のメディア経路２２５を確立するために使用される。
【０１２７】
環境２００の第１のコンピューティングデバイス１０２ａは、接続３４１ａを通じてネットワーク１０４を介してゲートウェイ３４０にアクセスし、ファイアウォール２０５ａをトラバースする、プライベートまたはパブリックのネットワークの一部であってよい。ファイアウォール２０５ａは、パブリックネットワークへのアクセスおよびトラバースを提供し、ＩＰアドレス２４．２４．２４．１００を割り当てている。第１のコンピューティングデバイス１０２ａは、ＶｏＩＰ通信デバイスまたは他のリアルタイムデータ通信デバイスのような、通信デバイス２１０ａと通信するか、これにインターフェースされるか、または接続することが可能である。第２のコンピューティングデバイス１０２ｂは、プライベートネットワークの一部とすることが可能であり、ＩＰアドレス１９２．１６８．２０．２０を割り当てている。加えて、第２のコンピューティングデバイス１０２ｂは、ソフトウェアベースのＶｏＩＰ通信デバイスまたはプログラムのような、ソフトウェアベースの通信デバイス２１０ｂを備えることが可能である。第２のコンピューティングデバイス１０２ｂは、接続３４１ｂを通じてネットワーク１０４を介して、パブリックネットワークのＩＰアドレス２１６．２１６．１０．１０を有するファイアウォール２０５ｂをトラバースして、ゲートウェイ３４０にアクセスすることが可能である。ファイアウォール２０５ａおよび２０５ｂは、ＮＡＴファイアウォールのような、当業者に公知のあらゆるタイプおよび／または形態のファイアウォールであってよい。
【０１２８】
図２Ａの第１のコンピューティングデバイス１０２ａおよび第２のコンピューティングデバイス１０２ｂは、本発明のリモートアクセスクライアント１２０を備え、これを使用して環境２００内にアドホックのピアツーピア仮想ネットワーク接続を提供する。ゲートウェイ３４０への、ＳＳＬ  ＶＰＮ接続のような、トンネルおよび仮想プライベート接続の保持に加えて、本発明のリモートアクセスクライアント１２０はまた、到達を試みているピアへの、ＳＳＬ  ＶＰＮ接続のような、直接的なアドホック接続を確立するために、ロジック、機能、およびオペレーションも有する。図２Ａを考慮して、図２Ｂの例示的方法２６０は、本発明の一例示的実施態様において、ピアツーピアの安全な通信セッションが、メディア経路２２５に対してどのように確立されるのかを説明するために使用する。方法２６０で示すように、本発明のピアツーピアルーティング技術は、より良好な音声品質を提供し、他のリアルタイムデータ通信とともにＶｏＩＰ通信に関連する待ち時間を減じる。
【０１２９】
例示的方法２６０の概略では、ステップ２６２で、コンピューティングデバイス１０２ａおよび１０２ｂは、ゲートウェイ３４０とのトンネリングセッションを確立する。ステップ２６４で、第１のコンピューティングデバイス１０２ａは、シグナリングサーバー１０２ｂへのシグナリング経路２２０を介してシグナリングプロトコルを使用して、ゲートウェイ３４０を介して第２のコンピューティングデバイス１０２ｂへのセッションを開始する。セッションは、第１のコンピューティングデバイス１０２ａと通信する通信デバイス１０２ａによって開始することが可能である。ステップ２６６で、シグナリングサーバー１０２ｃは通信セッションを設定し、ステップ２６８で、第２のコンピューティングデバイス１０２ｂの第１のネットワーク識別子を有する第１のコンピューティングデバイス１０２ａを提供する。第１のネットワーク識別子は、ゲートウェイ３４０によってトンネル３４１ｂを経て確立されたＩＰアドレスに基づいた、第２のコンピューティングデバイス１０２ｂの、ホスト名またはＩＰアドレスのような、ネットワークアドレスを含む。ステップ２７０で、第１のコンピューティングデバイス１０２ａは、接続または通信セッションを確立するために、第１のネットワーク識別子を使用して、第２のコンピューティングデバイス１０２ｂへ通信する。
【０１３０】
更なる概略では、ステップ２７２で、ゲートウェイ３４０は、第１のコンピューティングデバイス１０２ａによって通信をインターセプトし、第１のコンピューティングデバイス１０２ａに第２のコンピューティングデバイス１０２ｂの第２のネットワーク識別子を提供する。第２のネットワーク識別子は、第２のコンピューティングデバイス１０２ｂの最後の公知のパブリックＩＰアドレスのような、第１のコンピューティングデバイス１０２ａが直接または公的にアクセス可能な、第２のコンピューティングデバイス１０２ｂのＩＰアドレスまたはホスト名を含む。ステップ２７４で、一実施態様では、ゲートウェイ３４０は、第２のコンピューティングデバイス１０２ｂが、ファイアウォール２０５ｂを介して第２のコンピューティングデバイス１０２ｂへ接続するように、第１のコンピューティングデバイス１０２ａのスイマーセッションを確立することをリクエストするために、第２のコンピューティングデバイス１０２ｂへ通信する。いくつかの実施態様では、ゲートウェイ３４０は、ステップ２７６で、第１のコンピューティングデバイス１０２ａおよび第２のコンピューティングデバイス１０２ｂの暗号鍵をネゴシエートまたは提供することが可能である。ステップ２７８で、第１のコンピューティングデバイス１０２ａは、第２のコンピューティングデバイス１０２ｂへの直接接続、通信セッション、またはメディア経路２２５を確立する。他の実施態様では、ステップ２８０で、第１のコンピューティングデバイス１０２ａおよび／または第２のコンピューティングデバイス１０２ｂは、通信を許可する前に、他のコンピューティングデバイスが受信した暗号鍵を照合する。
【０１３１】
例示的ステップ２６２のいくつかの実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂは、あらゆるタイプおよび／または形態のトンネリングまたはゲートウェイプロトコルのような、あらゆる好適な手段および／または機構によって、ゲートウェイ３４０との接続を確立することが可能である。いくつかの実施態様では、ゲートウェイ３４０への接続３４１ａおよび３４１ｂは、仮想プライベートネットワーク接続を形成することが可能であり、他の実施態様では、ＳＳＬまたはＴＬＳを使用して、図２に示される１０．１０．１０．ＸＸＸの範囲のＩＰアドレスで識別されるプライベートネットワークのような、プライベートネットワークへの安全な通信を提供する。一実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂは、パブリックネットワークを介してファイアウォール２０５ａおよび２０５ｂをトラバースすることによってゲートウェイ３４０へ接続するが、別の実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂは、プライベートネットワークを介してゲートウェイ３４０に接続することが可能であり、ファイアウォール２０５ａおよび２０５ｂをトラバースしなくてよい。当業者は、コンピューティングデバイス１０２ａおよび１０２ｂは、ゲートウェイ３４０に接続して通信することが可能な、様々な方法を認識および理解されよう。
【０１３２】
例示的ステップ２６４で、一実施態様では、ハードＩＰ電話のような通信デバイス２１０ａは、ソフトＩＰ電話のような通信デバイス２１０ｂに、通話のような通信セッションを開始する。いくつかの実施態様では、通信デバイス２１０ａは、通信デバイス２１０ｂの内線を指示することによって通話を開始する。通信デバイス２１０ａが通信セッション開始するとき、通信セッションまたはメディアセッションを確立するためのこの開始、指示、またはリクエストを、ＳＩＰプロトコル、専用のシグナリングプロトコル、またはシグナリングに好適な他のタイプのプロトコルを介して、シグナリングサーバー１０２ａに送信する。信号は、シグナリング経路２２０を介して、ゲートウェイ２３０へのトンネリングセッション３４１を介して通信され、ゲートウェイ３４０の背後のプライベートネットワークのイントラネット経路を介してシグナリングサーバー１０２ｃに到達する。
【０１３３】
方法２６０の例示的実施態様は、ＶｏＩＰまたは通信シグナリングおよびセッションを考慮して説明しているが、当業者は、本発明を、あらゆるタイプおよび／または形態の通信セッション、リアルタイムまたはビデオ、音声、チャット、ゲーム、および仮想現実のようなマルチメディア要素を伴う双方向のユーザーセッションのような、他のセッションを開始するために使用することが可能であることを認識および理解されよう。このように、通信デバイス２１０ａおよび２１０ｂ、シグナリング／信号経路２２０、およびシグナリングサーバー１２０ａは、通信セッションのタイプおよび／または形態に対応するデバイス、シグナリング、プロトコル、および通信のタイプおよび／または形態を相応かつ適切に含むことが可能である。
【０１３４】
例示的ステップ２６６のいくつかの実施態様では、シグナリングサーバー１０２ｃは、あらゆるタイプおよび／または形態の通信セッションを設定することが可能であり、一実施態様では、シグナリングサーバー１０２ｃは、通信デバイス２１０ａによって開始されるＶｏＩＰ通話のような、通信セッション設定する。通信または他のメディアセッションを設定するとき、シグナリングサーバー１０２ｃは、ステップ２７０で、開始通信デバイス２１０ａおよび／または第１のコンピューティングデバイス１０２ａに命令、リクエスト、または通信を行って、特定のネットワークアドレスを介してピア通信デバイス２１０ｂへの交信、シグナリング、接続、または通信を行う。いくつかの実施態様では、開始通信デバイス２１０ａに対するシグナリングサーバー１０２ｃによって提供されるネットワークアドレスは、ゲートウェイ３４０の背後のプライベートネットワーク上のコンピューティングデバイス１０２ｂのネットワークアドレス（すなわち１０．１０．１０．ＸＸＸ）を含む。一実施態様では、ピア通信デバイス２１０ｂのネットワークアドレスは、企業プライベートネットワークアドレスを含むことが可能である。
【０１３５】
この点で、そのＶＰＮプライベートＩＰアドレスを介してピア通信デバイス２１０ｂと交信する代わりに、例示的方法２６０では、リモートアクセスクライアント１２０を介して、通信デバイス２１０ａおよび／または第１のコンピューティングデバイス１０２ａが、ピアまたはターゲット通信デバイス２１０ｂ、または第２のコンピューティングデバイス１０２ｂと直接交信しやすくする。本発明の技術は、いずれかのＶｏＩＰプロトコルに固有のものではなく、コンピューティングデバイス間のあらゆるピアツーピア接続のような、他のプロトコルに適用することが可能である。本発明の技術は、クライアントが接続しようとしているリソースのＩＰアドレスを通じて判断を行う。
【０１３６】
ステップ２７０で、通信デバイス２１０ａが、ステップ２６８でシグナリングサーバー１２０ｃによって提供された、ソフトＩＰ電話のＶＰＮプライベートＩＰアドレスのような、第１のネットワークアドレスによって、通信デバイス２１０ｂへのデータ接続を開始するとき、ゲートウェイ３４０は、通信デバイス２１０および／または第１のコンピューティングデバイス１０２ｂに、通信デバイス２１０ｂと交信するための第２のネットワークアドレスを提供するために通信をインターセプトする。一実施態様では、ゲートウェイ３４０が介在して、ハードＩＰ電話２１０ａのトラフィックを容易にする第１のコンピューティングデバイスに、確立した同じＶＰＮトンネル３４１ａを通じて帯域外の信号を送信する。当業者は、ゲートウェイ３４０は、コンピューティングデバイス１０２ｂおよび／または通信デバイス２１０ｂと交信するためのネットワークアドレスが、任意の適切な手段および／または機構によって直接与えられた、通信デバイス２１０および／またはコンピューティングデバイス１０２ａへ通信することが可能であることを認識および理解されよう。例えば、ゲートウェイ３４０は、第２のトンネリングセッションを介して、第１のコンピューティングデバイス１０２ａに第２のネットワークアドレスを通信することが可能である。
【０１３７】
いくつかの実施態様では、ゲートウェイは、ソフトＩＰ電話２１０ｂを実行している第２のコンピューティングデバイス１０２ｂが、ゲートウェイ３４０と交信するために使用した、最後の公知のパブリックＩＰアドレスを第１のコンピューティングデバイス１０２ａに示す。他の実施態様では、このパブリックＩＰは、第２のコンピューティングデバイスの実際のＩＰアドレスではなく、第２のコンピューティングデバイス１０２ｂが背後にあるファイアウォール２０５ｂのＩＰアドレスとすることが可能である。コンピューティングデバイス２１０ａがファイアウォール２０５ｂのパブリックＩＰアドレスと直接交信する場合は、ファイアウォール２０５ｂによってパケットを拒否することが可能である。これらの実施態様では、ゲートウェイ３４０は、コンピューティングデバイス１０２ｂに、当業者に公知である、第１のコンピューティングデバイス１０２ａに対するスイマーセッションを確立するように命令する。フォワードホールは、第１のコンピューティングデバイス１０２ａがそれを介してトラバースまたは戻ることができる、ファイアウォール２０５ｂにパンチされる。他の実施態様では、第１のコンピューティングデバイス１０２ａが、ファイアウォール２０５ｂをトラバースして、第２のコンピューティングデバイス１０２ｂに接続して通信できるようにするために、あらゆる適切な手段および／または機構を使用することが可能である。
【０１３８】
例示的方法２６０は、ファイアウォール２０５ａの背後に第２のコンピューティングデバイス１０２ｎを有する、図２Ａの環境２００に関して説明しているが、当業者は、例示的方法２６０は、第２のコンピューティングデバイス１０２ｂがファイアウォール２０５ａをトラバースせずに直接アクセスできる環境において使用できることを認識および理解されよう。このように、例示的方法２６０は、第１のコンピューティングデバイス１０２ａが、第２のコンピューティングデバイス１０２ｂに接続するためのスイマーセッションまたは他の機構を提供するように、ステップ２７４で命令する必要がない。
【０１３９】
いくつかの実施態様では、ゲートウェイ３４０は、ステップ２７６で、安全な通信のためのコンピューティングデバイス１０２ａと１０３ｂとの間の暗号鍵をネゴシエートすることが可能である。コンピューティングデバイス１０２ａおよび１０２ｂは、安全で暗号化した通信のために、および／または他のコンピューティングデバイスを認証または許可するために、この鍵を使用することが可能である。他の実施態様では、悪意のあるコンピューティングデバイスがこのオープンホールを利用していないことを確認するために、ゲートウェイ３４０は、ステップ２７６で、２つのコンピューティングデバイス１０２ａと１０２ｂとの間の秘密鍵をネゴシエートし、それぞれのリモートアクセスクライアントは、データ通信を許可する前に、それらの鍵が一致することを確認する。例えば、スイマーセッションを確立する実施態様では、この鍵は、オープンホールに入ってくるパケットが、スイマーセッションが意図したコンピューティングデバイスからのものであることを確認する。
【０１４０】
他の実施態様では、ゲートウェイ３４０は、ステップ２７６を行わずに、コンピューティングデバイス１０２ａと１０２ｂとの間のピアツーピア通信セッションの安全な機構を提供する。例えば、コンピューティングデバイス１０２ａおよび１０２ｂは、同じ企業プライベートネットワーク内に存在させることが可能であり、したがって信頼することが可能である。更なる実施態様では、秘密鍵をネゴシエートするゲートウェイ３４０の代わりに、コンピューティングデバイス１０２ａおよび１０２ｂは、ピアツーピア通信のために、他のコンピューティングデバイスを認証および／または許可するための任意の適切な手段および／または機構を使用する。いくつかの実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂは、経路３４１を介して、またはステップ２８０で、ステップ２７８で確立されたメディア経路２２５を介するなどの、ゲートウェイのトンネリングセッションを介して認証および／または許可することが可能である。例えば、各コンピューティングデバイス１０２ａおよび１０２ｂのリモートアクセスクライアント１２０は、あらゆるデータの接続２２５を通じた通信が許可される前に、確立されたメディア経路２２５を通じて、鍵を照合するために確認することができる。
【０１４１】
ステップ２７８で、ゲートウェイ３４０をトラバースせずに、コンピューティングデバイス１０２ａと１０２ｂとの間に、あらゆるタイプおよび／または形態の通信のための直接メディア経路２２４を確立する。いくつかの実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂのそれぞれのＶＰＮの割り当てられたＩＰアドレスを使用しない代わりに、パブリックＩＰアドレスまたはそれらが存在するネットワークによって割り当てられたＩＰアドレスを使用する。本発明の技術を使用することで、コンピューティングデバイス１０２ａおよび１０２ｂのそれぞれのリモートアクセスクライアント１２０は、一時的なピアツーピアＳＳＬゲートウェイとしての機能を果たし、ゲートウェイ３４０を介して通信せずに、互いのＳＳＬセッションを直接解読する。経路２２５を介した直接ピアツーピア通信セッションは、ゲートウェイ３４０を介した追加ホップを無効にする。これによって、ゲートウェイ３４０を介してより長い経路を使用することによる待ち時間が減じられ、図２Ａに示されるＶｏＩＰ通信のような、リアルタイムデータ通信の品質、性能、およびエクスペリエンスを向上させることになる。
【０１４２】
いくつかの実施態様では、ゲートウェイ３４０は、コンピューティングデバイス１０２が、ピアツーピア通信セッションを確立しようとしたり、ゲートウェイ３４０を介してリソースにアクセスしようとしたりするたびに、例示的方法２６０の技術を自動的に実行するように構成することが可能である。他の実施態様では、ゲートウェイ３４０は、ソースＩＰアドレス、宛先ＩＰアドレス、またはそれらを組み合わせたものに対する特定のＩＰアドレスの範囲に対してだけ、例示的方法２６０の技術を自動的に実行するように構成することが可能である。更なる実施態様では、ゲートウェイ３４０は、アプリケーションおよび／またはゲートウェイ３４０を介してアクセスされるリソースのタイプに基づいて、この技術を実行することが可能である。例えば、一実施態様では、ゲートウェイ３４０は、あらゆるタイプのデスクトップまたはゲートウェイ３４０を介してスクリーンデータを共有するスクリーン共有アプリケーションに対して、この技術を自動的に実行することが可能である。他の実施態様では、ゲートウェイ３４０は、あらゆるタイプおよび／または形態のビジネスルール、アクセス制御ポリシー、または他の構成、アルゴリズム、および統計に基づいて、この技術の実行を決定することが可能である。例えば、ゲートウェイ３４０は、ピアコンピューティングデバイス間のｐｉｎｇベースのタイミング統計に基づいて、この技術を実行することが可能である。ピアコンピューティングデバイスが、ゲートウェイ３４０よりも互いに近接している場合、ゲートウェイは、ピアツーピアルーティング技術を実行する。当業者は、本発明のゲートウェイが、本発明のピアツーピアルーティング技術を実行するように適応させるか、または構成することが可能である様々な方法を認識および理解されよう。
【０１４３】
一側面では、本発明は、不可逆プロトコルを介して構成された可逆プロトコルを介した通信を可能にすることに関する。図３Ｂに示される一技術では、本発明は、例えばＴＣＰまたはＳＳＬ／ＴＣＰ接続を介したＵＤＰを通じてＲＴＰを通信するような、可逆または信頼できるプロトコルを介して不可逆または信頼できないプロトコルを通信するときに、疑似確認応答技術を使用する。図３Ｃに示される別の技術では、本発明は、不可逆プロトコルを介して送信するように構成された可逆プロトコルを介して通信するためにペイロードシフティングを使用する。当業者は、いくつかの実施態様では、本発明のこれらの技術が、ＵＤＰレベルでのトランスポートレイヤーセキュリティ（ＴＬＳ）の達成を助力することを、下記の説明を考慮して認識および理解するであろう。
【０１４４】
疑似確認応答技術を実施するための本発明の実施態様の例示的方法３６０を、図３Ａの例示的環境３００を考慮して、またさらに図１Ａ乃至１Ｅを考慮して以下に説明する。概略的に、環境３００は、コンピューティングデバイス１０２ｂのピアクライアント１０５ｂと通信するか、または代わりにネットワーク１０４を介してゲートウェイ３４０と通信する、コンピューティングデバイス１０２ａのクライアント１０５ａを備える。いくつかの実施態様では、クライアント１０５ａがＩＰルーター３０５ａおよび３０５ｂをトラバースするか、またはネットワーク１０４がＩＰルーター３０５ａおよび３０５ｂを有することが可能である。しかし、他の実施態様では、コンピューティングデバイス１０２ａおよび１０２ｂ、およびゲートウェイ３４０を、同じネットワーク１０４上に存在させることが可能である。加えて、通信デバイス２１０ａをクライアント１０５ａに関連付けることが可能であり、第２の通信デバイス２１０ｂをピアクライアント１０５ｂまたはゲートウェイ３４０に関連付けることが可能である。
【０１４５】
クライアント１０５ａは第１のネットワークスタック３１０ａを含むことが可能であり、クライアント１０５またはゲートウェイ３４０は、第２のネットワークスタック３１０ｂを備えることが可能である。ネットワークスタック３２０１ａおよび３１０ｂは、開放型システム間相互接続（ＯＳＩ）の通信モデルのあらゆるネットワークレイヤーのような、１つ以上のネットワークレイヤーを備えることが可能である。例えば、図３Ａに示されるように、ネットワークスタック３１０ａおよび３１０ｂは、当業者が公知のＴＣＰ／ＩＰベースのネットワーク１０４に好適なフレームレイヤーの上位に、ＴＣＰ／ＩＰ３４３ａおよび３４３ｂの通信レイヤーの通信を含む。ＴＣＰレイヤー３４３ａおよび３４３ｂは、信頼できるかまたは可逆プロトコルの例示的実施態様を含む。例えば、当業者が公知のＴＣＰ３４３ａおよび３４３ｂでは、ネットワークスタック３１０ａおよび３１０ｂ、またはＴＣＰドライバのような任意のドライバまたはその機構は、アルゴリズムおよびオペレーションを行うことが可能であり、またプロトコルの１つ以上の可逆または信頼できる特性を提供するために、ロジックまたは機能を備えることが可能である。例えば、ＴＣＰ３４３ａおよび３４３ｂに対応するために、ネットワークスタック３１０ａおよび３１０ｂは、パケットの順序付け、パケットの再送信、パケットの受信の確認応答、フロー制御アルゴリズム、スライディングウィンドウアルゴリズム、および／またはＮａｐｌｅのアルゴリズム、および、当業者がＴＣＰ３４３ａおよび３４３ｂまたは他の可逆プロトコルを考慮して認識および理解するであろう、他の信頼性に関連するオペレーションおよびアルゴリズムを行うことが可能である。
【０１４６】
加えて、ネットワークスタック３１０ａおよび３１０ｂは、ＳＳＬまたはＳＳＬ  ＶＰＮ通信をサポートするための、ＳＳＬレイヤー３４１ａおよび３４１ｂを備えることが可能である。例えば、ＳＳＬレイヤー３４１ａおよび３４１ｂは、リモートアクセスクライアント１２０間、またはリモートアクセスクライアント１２０とゲートウェイ３４０との間のゲートウェイまたはトンネリングセッションに使用することが可能である。図３Ａに示されるように、ネットワークスタック３１０ａおよび３１０ｂはまた、ＴＣＰのような可逆プロトコル３４３ａおよび３４３ｂを通じて通信される、ＵＤＰのような不可逆プロトコル３４２ａおよび３４２ｂに、レイヤーを提供することも可能である。いくつかの実施態様では、不可逆または信頼できないプロトコル３４２ａおよび３４２ｂは、ＵＤＰを通じたリアルタイムプロトコル（ＲＴＰ）を含むことが可能であり、音声またはオーディオの表現のような任意のタイプおよび／または形態のリアルタイムデータを有するペイロードを含むことが可能である。他の実施態様では、不可逆プロトコル３４２ａおよび３４２ｂは、図２Ａおよび２Ｂを参照して上述した例示的方法２６０を介して確立したセッションのような、確立されたＶｏＩＰセッションにおけるクライアント１０５ａとの通信を通じて、ＶｏＩＰを担送することが可能である。可逆プロトコルなどを介して信頼できる様式でパケットを獲得するよりも、ピアクライアント１０５ｂのような受信者がパケットを遅れずに獲得することのほうが重要であるので、音声のようなリアルタイムアプリケーションに、ＵＤＰ３４２ａおよび３４２ｂのような可逆プロトコルを選択することが可能である。
【０１４７】
ネットワークスタック３１０ａおよび３１０ｂはまた、本発明のリモートアクセスクライアント１２０のシム３２２ａおよび３２２ｂを含む。シム３２２ａおよび３２２ｂは、リモートアクセスクライアント１２０の任意の部分を含むことが可能であり、いくつかの実施態様では、ネットワークドライバ、ネットワークドライバインターフェース、または本願明細書に記述される本発明の疑似確認応答技術を提供するための他のネットワークレイヤー関連の機構を備えることが可能である。シム３２２ａおよび３２２ｂは、ソフトウェア、ハードウェア、またはソフトウェアおよびハードウェアを組み合わせたものを含むことが可能である。一実施態様では、シム３２２ａおよび３２２ｂは、ネットワークパケットがＴＣＰレイヤー３４３ａに到達する前に、ネットワークスタックのＩＰレイヤーで動作することが可能である。他の実施態様では、シム３２２ａおよび３２２ｂは、ＴＣＰレイヤー３４３ａおよび３４３ｂで動作することが可能である。当業者は、シム３２２ａおよび３２２ｂが、可逆プロトコルのレイヤーに含まれるか、またはこれに隣接する、ネットワークスタック３１０ａおよび３１０ｂにおける可逆プロトコルのオペレーションのレイヤーに関連するあらゆる様式で動作することが可能であることを認識および理解されよう。
【０１４８】
図３Ｂの方法で示されるような本発明の疑似確認応答技術によって、ＵＤＰ３４２ａおよび３４３ｂのような不可逆プロトコルは、ＴＣＰ３４３ａおよび３４３ｂのような可逆プロトコルを介して通信することが可能となる。ＴＣＰパケットの受信の疑似確認応答を発行するシム３２２ａおよび３２２ｂによって、本発明の技術は、ＴＣＰ３４３ａおよび３４３ｂの例における、パケットの順位付け、パケットの再送信、フロー制御アルゴリズム、スライディングウィンドウアルゴリズム、および／またはＮａｐｌｅのアルゴリズムのうちのいずれかのように、可逆プロトコルの信頼性の機構、オペレーション、およびアルゴリズムを回避するか、または無効にする。このように、不可逆プロトコル３４２ａおよび３４２ｂは、可逆プロトコル３４３ａおよび３４３ｂを通じて通信することができるが、リアルタイムデータ通信などにおいて必要となる場合がある不可逆または信頼できない特性を保持することができる。また、この技術によって、不可逆プロトコルを安全に通信すること、またはトンネリングプロトコルを介してトラバースすること、あるいは不可逆プロトコル通信に可逆プロトコルの可逆特性を適用せずに、単にＴＣＰ／ＩＰを介して通信できるようになる。
【０１４９】
例示的方法３６０の概略では、ステップ３６５で、コンピューティングデバイス１０２ａおよび１０２ｂまたはゲートウェイ３４０は、可逆プロトコルパケットが通信されることによって、ＴＣＰ接続のような可逆プロトコルベースの接続を確立する。ステップ３７０で、本発明のリモートアクセスクライアント１２０は、可逆プロトコルパケットのペイロードが、ＲＴＰまたはＵＤＰのような不可逆プロトコルを含むか、またはリアルタイムデータを含むことを検出することが可能である。一実施態様では、ステップ３７５で、例示的方法３６０は、ステップ３６７の帯域外のＴＬＳまたはＳＳＬセッションを介して提供される鍵のような、鍵によってペイロードを暗号化することが可能である。ステップ３８０で、可逆プロトコルパケットの受信の疑似確認応答は、シム３２２ａおよび３２２ｂなどによって、ネットワークスタック３１０ａおよび３１０ｂに通信するか、または提供することが可能である。可逆プロトコルパケットの受信の疑似確認応答の受信に応えて、ステップ３８５で、それぞれのネットワークスタック３１０ａおよび３１０ｂは、可逆プロトコルの信頼できるまたは可逆特性を提供するアルゴリズムおよびオペレーションのうちの１つ以上または全てを実行しない。ステップ３９０で、不可逆プロトコルペイロードを有する可逆プロトコルパケットは、ネットワークスタック３１０ａと３１０ｂとの間で通信される。
【０１５０】
例示的方法３６０のステップ３６５で、可逆プロトコル接続は、あらゆるタイプおよび／または形態の可逆プロトコルを使用して、あらゆる適切な手段および／または機構を介して確立することが可能である。一実施態様では、クライアント１０５ａのネットワークスタック３１０ａは、ネットワークスタック３１０ｂを有するピアクライアント１０５ａへの、ＴＣＰのような可逆プロトコル接続を確立する。別の実施態様では、クライアント１０５ａのネットワークスタック３１０ａは、ネットワークスタック３１０ｂを有するゲートウェイ３４０への可逆プロトコル接続を確立する。加えて、ステップ３６５の可逆プロトコル接続は、ＳＳＬのような保護された様式で、または仮想プライベート接続として確立することが可能である。ネットワークスタック３１０ａおよび３１０ｂは、同じネットワークレイヤーを有するように示されているが、当業者は、ネットワークスタックが、異なるバージョンの、または異なるオペレーティングシステムおよび／またはドライバに関連付けられた、対応するレイヤーを有することが可能であること、また各ネットワークスタック３１０ａおよび３１０ｂが、より多くのレイヤー、より少ないレイヤー、または異なるレイヤーを有することが可能であることを認識および理解されよう。
【０１５１】
例示的ステップ３６０で、一実施態様では、リモートアクセスクライアント１２０は、パケット取得機構３６５などを介して、ネットワークパケットをインターセプトし、任意の好適な手段および／または機構によってネットワークパケットを調査して、ネットワークパケットのペイロードに使用されるプロトコルのタイプを判断するか、またはネットワークパケットのペイロードのコンテンツのタイプを判断する。いくつかの実施態様では、リモートアクセスクライアント１２０のシム３２２ａおよび３２２ｂは、ネットワークパケットをインターセプトして調査するために使用することが可能である。一実施態様では、リモートアクセスクライアント１２０は、ネットワークパケットをインターセプトして、そのネットワークパケットが、任意の可逆プロトコルまたはＴＣＰのような特定の可逆プロトコルを含んでいるかどうかを判断することが可能である。ネットワークパケットが可逆プロトコルである場合、リモートアクセスクライアント１２０は、ペイロードを確認してプロトコルのタイプおよび／またはデータのタイプを判断する。
【０１５２】
一実施態様では、リモートアクセスクライアント１２０は、ペイロードを表す不可逆プロトコルのヘッダーの任意の部分のような、ネットワークパケットのペイロードの好適なフィールドによって、そのペイロードがプロトコルのコンテンツを有することを判断することが可能である。別の実施態様では、リモートアクセスクライアント１２０は、ペイロードが不可逆プロトコルを含むか、またはリアルタイムデータを含むかどうかを、ペイロードの任意のデータによって判断することが可能である。一実施態様では、リモートアクセスクライアント１２０は、ＴＣＰパケットがＲＴＰまたはＵＤＰのペイロードを含んでいることを判断し、ペイロードの暗号化を適用する。リモートアクセスクライアント１２０は、任意の好適な様式で提供された鍵を有するあらゆるタイプおよび／または形態の暗号化を使用して、ネットワークパケットのペイロードを暗号化することが可能である。いくつかの実施態様では、図３Ａに示されるように、鍵または暗号文は、クライアント１０５ａおよび１０５ｂまたはクライアント１０５ａとゲートウェイとの間の帯域外のＴＬＳセッションを介してネゴシエートされるが、対照的に他の実施態様では、セッションが最初にネゴシエートされて、同じソケットである、従来のＴＬＳセッションがデータ通信に使用される。いくつかの実施態様では、ステップ３７５の暗号化は、パケット単位で行われる。別の実施態様では、暗号化は、複数のパケットに一度に行われる。
【０１５３】
本発明の例示的方法３６０のステップ３８０で、それぞれ送受信するコンピューティングデバイス１０２ａおよび１０２ｂ、またはゲートウェイ３４０を備えるネットワークスタック３１０ａおよび３１０ｂに、ネットワークパケットの受信の疑似確認応答（例、可逆プロトコルパケット）を発行、通信、または提供する。シム３２２ａおよび３２２ｂ、リモートアクセスクライアント１２０の任意の部分、またはネットワークスタック３１０ａおよび３１０ｂの任意の部分は、ネットワークパケットの受信の疑似確認応答を発行することが可能である。一側面では、ネットワークパケットの受信の疑似確認応答は、ネットワークパケットの実際の受信を承認しないように通信されるものではなく、ネットワークスタック３１０ａおよび３１０ｂに関連付けられた可逆プロトコルの可逆および信頼できる機構を回避するためのものである、という意味において擬似的である。このように、ネットワークパケットの受信の疑似確認応答は、実際のネットワークパケットの受信の確認応答と同じ形態および／またはタイプである。
【０１５４】
いくつかの実施態様では、受信の疑似確認応答は、単一または複数のネットワークパケットを通信する前に、ネットワークスタック３１０ａおよび３１０ｂに発行される。他の実施態様では、受信の疑似確認応答は、ネットワークパケットを通信した後だが一度に発行されるか、または受信ネットワークスタック３１０ａおよび３１０ｂの可逆プロトコル機構が送信されたネットワークパケットに適用されないようにするなどの方法で発行される。一実施態様では、ネットワークパケットの受信の疑似確認応答は、各ネットワークパケットに発行され、別の実施態様では、通信セッションまたは可逆プロトコル接続ごとに一度発行することが可能である。さらに、当業者は、受信の疑似確認応答は、異なるオペレーティングシステムに対して、ネットワークスタック３１０ａおよび３１０ｂ内の異なる場所において行うことが可能であることを認識および理解されよう。例えば、一実施態様では、受信の確認応答は、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのＭｉｃｒｏｓｏｆｔ  Ｆａｍｉｌｙのネットワークドライバインターフェース規約（ＮＤＩＳ）のドライバレベルで発行することが可能である。
【０１５５】
例示的方法３６０のステップ３８５で、ステップ３８０においてネットワークパケットの受信の疑似確認応答を受信しているネットワークスタック３１０ａおよび３１０ｂは、当該の受信に応えて、可逆プロトコルの１つ以上の可逆特性を提供する任意の１つ以上のアルゴリズムおよびオペレーションを、実行しないか、実行を止めるか、または実行しないようにすることが可能である。例えば、可逆プロトコルとしてのＴＣＰの実施態様内に、ネットワークスタック３１０ａおよび３１０ｂは、ネットワークパケットに関する次のいずれか１つ以上、またはＴＣＰ接続を実行しないことが可能である：パケットの順序付け、パケットの再送信、フロー制御アルゴリズム、スライディングウィンドウアルゴリズム、および／またはＮａｐｌｅのアルゴリズム。いくつかの実施態様では、受信の疑似確認応答は、ネットワークスタック３１０ａおよび３１０ｂの可逆レイヤーが信頼性のアルゴリズムを用いないようにするために、パケット単位で受信しなければならない。このように、送信ネットワークスタック３１０ａおよび３１０ｂは、どのパケットに本発明の疑似確認応答技術を適用するかを、パケット単位で決定することができる。可逆プロトコルの信頼性アルゴリズムを適用しなければならない不可逆プロトコルを含む、いくつかの可逆プロトコルのネットワークパケットが存在する場合がある。他の実施態様では、ネットワークパケットの受信の疑似確認応答は、可逆プロトコルセッションまたは接続中に受信されるあらゆる後続のパケットに対して信頼性のアルゴリズムを用いないように、可逆プロトコル接続に対して一度受信することが可能である。
【０１５６】
ステップ３９０で、例示的方法３６０は、ネットワークスタック３１０ａおよび３１０ｂを介して、可逆プロトコルペイロードを有する可逆プロトコルパケットを通信する。一実施態様では、可逆プロトコルパケットはステップ３８５の後に通信され、他の実施態様では、ステップ３８５の前に通信される。したがって、可逆プロトコルパケットはネットワーク内で失われるが、不可逆プロトコルのパケット要求するときに、そのパケットの再要求は行われない。
【０１５７】
方法３６０の例示的実施態様は、ＴＣＰのようなネットワークパケットの受信の疑似確認応答を使用して説明しているが、可逆プロトコルのあらゆる信頼性または可逆アルゴリズムを用いないようにするために、ネットワークスタック３１０ａおよび３１０ｂに、あらゆるタイプおよび／または形態の命令、リクエスト、または命令を通信することが可能である。いくつかの実施態様では、ネットワークスタック３１０ａおよび３１０ｂの可逆プロトコルレイヤーは、パケット単位、セッション、または接続単位のいずれかで信頼性のアルゴリズムを使用しないようにするために、設定、フラグ、または命令を有するように適応させるか、または構成することが可能である。例えば、可逆プロトコルは、可逆プロトコルパケットのヘッダーなどに、パケットに対して信頼性を破棄または無効にすべきかどうかを示すフィールドを有することが可能である。
【０１５８】
以下、図３Ｃを参照する。可逆プロトコルを介して、不可逆プロトコルに基づいて構成されたパケットを送信するために行うステップの別の実施態様を、例示的方法３４５によって示し、ペイロードシフティング技術とも称する。例示的方法３４５の概略では、ステップ３４８で、信頼できないトランスポートプロトコルを使用して送信される第１のパケットは、クライアント１０５のような第１のデバイスで受信する。ステップ３５０で、第１のデバイス１０５は、受信した第１のパケットの第１のペイロード、および第１のデバイス１０５と第２のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーを含む第１のＴＣＰパケットを作成する。第１のデバイス１０５は、ステップ３５２で、第２のデバイスに第１のＴＣＰパケットを送信する。ステップ３５４で、第１のデバイス１０５は、信頼できないトランスポートプロトコルを使用して送信された第２のパケットを受信し、ステップ３５６で、受信した第２のパケット、および第１のＴＣＰヘッダー情報の第２のペイロードを含む第２のＴＣＰパケットを作成する。ステップ３５８で、第１のデバイスは、第２のデバイスから第１のペイロードの受信の確認応答を受信する前に、第２のデバイスに第２のＴＣＰパケットを送信する。
【０１５９】
引き続き図３Ｃを参照して詳述する。ステップ３４８で、信頼できないトランスポートプロトコルを使用して送信される第１のパケットは、第１のデバイス１０５で受信する。いくつかの実施態様では、ＵＤＰの不可逆プロトコルを使用してパケットを送信することを目的とする。更なる実施態様では、パケットは、ＵＤＰを通じたＲＤＰを含む。他の実施態様では、第１のパケットは、ユーザーモード３３２で実行するアプリケーションプログラム３３８で生成する。いくつかの実施態様では、パケットは、カーネルモード３３４で実行するアプリケーション３３８で生成する。他の実施態様では、第１のパケットは、再送信のために第１のデバイス１０５で受信する。さらに別の実施態様では、第１のパケットは、それがネットワークスタック３１０ａおよび３１０ｂに到達する前に、フィルタプロセス３２２によってインターセプトされる。フィルタプロセス３２２は、ユーザーモード３３２、またはカーネルモード３３４で実行することが可能である。いくつかの実施態様では、フィルタ３２２は、ミニドライバである。他の実施態様では、フィルタ３２２は、ＮＤＩＳドライバである。他の実施態様では、フィルタ３２２プロセスは、第１のパケットをインターセプトするためにフックするアプリケーションを使用する。更なる実施態様では、フックするアプリケーションは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して実行される。一実施態様では、ネットワークパケットのフックは、ネットワークスタック３１０ａ−３１０ｎのネットワークレイヤーで生じる。
【０１６０】
ステップ３５０で、第１のデバイス１０５は、受信した第１のパケットの第１のペイロード、および第１のデバイス１０５と第２のデバイスとの間に確立されたＴＣＰ接続に関連する情報の第１のＴＣＰヘッダーを含む第１のＴＣＰパケットを作成する。例えば、ＴＣＰ接続は、一実施態様では、クライアント１０５とピアコンピューティングデバイス１０２ｂとの間に確立することが可能であり、別の実施態様では、クライアント１０５とゲートウェイ３４０との間に確立することが可能である。いくつかの実施態様では、第１のデバイス１０５は、ＴＣＰパケットが、特定のＴＣＰポートを開くことによって、不可逆プロトコルを介して送信されるように構成されたパケットのペイロードを含むことを示す。他の実施態様では、第１のデバイス１０５は、ＴＣＰパケットが、ＴＣＰヘッダーにフラグを設定することによって、不可逆プロトコルを介して送信されるように構成されたパケットのペイロードを含むことを示す。ＴＣＰヘッダーは、送信元ノードに関する情報、宛先ノードに関する情報、または特にＴＣＰパケットを識別するシーケンス番号を含むことが可能である。
【０１６１】
ステップ３５２で、第１のデバイス１０５は、第２のデバイスに第１のＴＣＰパケットを送信する。いくつかの実施態様では、第２のデバイスは、ゲートウェイ３４０であってよい。他の実施態様では、第２のデバイスは、「ピア」コンピューティングデバイス１０２ｂである。第１のＴＣＰパケットは、例えばＳＳＬまたはＴＬＳを使用して、第２のデバイスに送信する前に暗号化することが可能である。
【０１６２】
ステップ３５４で、第１のデバイス１０５は、ＵＤＰのような信頼できないトランスポートプロトコルを使用して送信される、第２のパケットを受信する。第２のパケットは、第１のパケットを生成した同じアプリケーション３３８から受信することが可能である。ステップ３５６で、第１のデバイス１０５は、上述のように、受信した第２のパケットおよび第１のＴＣＰヘッダーの第２のペイロードを含む第２のＴＣＰパケットを作成する。ステップ３５８で、第１のデバイス１０５は、次いで、第２のデバイスから第１のペイロードの受信の確認応答を受信する前に、第２のデバイスに第２のＴＣＰパケットを送信する。いくつかの実施態様では、確認応答を第２のデバイスから受信するときに、第１のデバイス１０５は、パケットを送信する前にＴＣＰヘッダー情報を更新する。他の実施態様では、第１のデバイス１０５は、更新されたＴＣＰヘッダー情報を有し、第２のペイロードを有する第３のＴＣＰパケットを作成する。第１のデバイスは、次いで第３のＴＣＰパケットを送信する。
【０１６３】
ＴＣＰパケットを受信すると、第２のデバイスは、必要に応じてそれを解読し、パイロードが、不可逆プロトコルを使用して送信されるように構成された１つ以上のパケットであることを判断する。第２のデバイスは、パケットを受信したポートに基づくか、またはＴＣＰヘッダー情報内のフラグによって、これを判断することができる。判断すると、第２のデバイスは、ペイロードからＴＣＰヘッダーを取り除いて、ペイロードを配信する。
【０１６４】
別の側面では、本発明は、暗号化したネットワークパケットに対するパケットフラグメンテーションを減じることによって、ネットワーク通信を最適化するための、報告された最大送信単位（ＭＴＵ）パラメータの調整に関する。この技術は、図３Ａの例示的環境３００のネットワークスタック３１０ａおよび３１０ｂの一方または両方に適用することが可能である。上述の例示的方法３６０に基づいて処理される任意のネットワークパケットのような、ネットワークパケットのペイロードを暗号化することで、ペイロードのサイズを増加させる場合がある。すなわち、ネットワークパケットのサイズは、暗号化したペイロードに対する暗号化していない元のペイロードのサイズの変化を補うために増加させる場合がある。
【０１６５】
引き続き図３Ａを参照する。ネットワークスタック３１０ａおよび３１０ｂは、イーサネット（登録商標）ベースのネットワークのようなネットワークにおいて、１つのタイプの物理的メディアを通じて送信することができる、最大のユニットのサイズを示すために、最大送信単位４０２ａおよび４０２ｂ（ＭＴＵ）のパラメータを含むことが可能である。ＴＣＰ／ＩＰの実施態様では、ＭＴＵ４０２ａおよび４０２ｂは、データグラムをより小さなユニットに分解または断片化する必要のあるインターフェースを用いずに、インターネットプロトコル（ＩＰ）レイヤーのインターフェースによって送信することができる、最大のデータグラムまたはパケットを示す。ＭＴＵパラメータ４０２ａおよび４０２ｂは、ネットワークインターフェースカードのような通信インターフェースに関連付けることが可能である。イーサネット（登録商標）のデフォルトのＭＴＵサイズは１，５００バイトであり、ＩＥＥＥ  ８０２．３では１，４９２バイトである。当業者は、デフォルトのＭＴＵサイズが、トークンリング、ＦＤＤＩ、Ｘ．２５などのようなネットワーク技術に基づくものであることを認識および理解されよう。
【０１６６】
図４を参照する。フロー図は、本発明のＭＴＵ調整方法４００の例示的実施態様を示す。概略的に、ステップ４０５で、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間のような、コンピューティングデバイス間のセッションを確立する。ステップ４１０で、第１のコンピューティングデバイス１０２ａのようなコンピューティングデバイス１０２のうちの１つは、暗号化したペイロードを有するネットワークパケットを検出する。ステップ４１５で、コンピューティングデバイス１０２ａおよび１０２ｂは、ペイロードの暗号化した部分のサイズを補うために、ネットワークスタック３１０ａおよび３１０ｂのＭＴＵ４０２ａおよび４０２ｂのパラメータの設定を決定する。ステップ４２０で、ＭＴＵ４０２ａおよび４０２ｂのパラメータは、暗号化した部分を補うために減じられる。ＭＴＵ４０２ａおよび４０２ｂがリクエストまたは報告される場合、ＭＴＵ４０２ａおよび４０２ｂは、イーサネット（登録商標）に対する１，５００のような、物理レイヤーに関連するＭＴＵのサイズよりも小さいサイズを示す。
【０１６７】
この技術を使用することで、ネットワーク１０４上のあらゆるデバイスは、ネットワークスタック３１０ａおよび３１０ｂに従って暗号化することができ、断片化できない、減じられたＭＴＵのサイズに基づいて、ネットワークスタック３１０ａおよび３１０ｂに、ネットワークパケットを通信することが可能である。ネットワークパケットを暗号化する場合、イーサネット（登録商標）のような、物理的なネットワークレイヤーの媒体の実際のＭＴＵのサイズに合わせなければならない。例えば、ＭＴＵ４０２ａおよび４０２ｂのパラメータは、イーサネット（登録商標）に対する１，５００のデフォルトのＭＴＵのサイズに設定すること、および暗号化オーバーヘッドを補うために、例えば１００バイトの決定されたバイト数を減じた例示的方法４００に従って設定することが可能である。ネットワークパケットは、サーバーリソースから、報告されたＭＴＵ４０２ａおよび４０２ｂのサイズ１，４００と等しいサイズを有するクライアントに送信することが可能である。ネットワークパケットは、ゲートウェイ３４０をトラバースして、ＳＳＬトンネルを介して暗号化することが可能であり、今度はネットワークパケットのサイズが１，４７５に増加する。このサイズは、イーサネット（登録商標）の物理的なメディアのＭＴＵのサイズに合っているので、ネットワークパケットは断片化されない。
【０１６８】
例示的方法４００のステップ４０５で、クライアント１０５ｂまたは図２Ａのゲートウェイ３４０のような、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間のあらゆるタイプおよび／または形態の通信セッションを確立することが可能である。いくつかの実施態様では、セッションは、第１のコンピューティングデバイス上のリモートアクセスクライアント１２０を使用して確立する。一実施態様では、リモートアクセスクライアント１２０は、ＳＳＬ  ＶＰＮセッションのようなゲートウェイ３４０によるセッションを確立するか、またはピアコンピューティングデバイス１０２ｂ上の別のリモートアクセスクライアント１２０へのセッションを確立することが可能である。
【０１６９】
ステップ４１０のいくつかの実施態様では、リモートアクセスクライアント１２０は、暗号化したペイロードを有するネットワークパケットを検出する。一実施態様では、パケット取得機構３６５は、ネットワークパケットをインターセプトし、エージェント３２６は、パケットが暗号化されたかどうかを判断する。しかし、フィルタ３２２またはフレームモニター３６０のような、リモートアクセスクライアント１２０の他の部分は、パケットが暗号化されたかどうかを判断することが可能である。一実施態様では、ネットワークパケットのペイロード全体が暗号化されるが、他の実施態様では、ペイロードの一部が暗号化される。本発明は、パケットが暗号化されているかどうかを判断するための、あらゆるタイプおよび／または形態の手段または機構を使用することが可能である。例えば、場合によっては、リモートアクセスクライアント１２０は、ペイロードが暗号化されていることを示すネットワークパケットのフラグまたはフィールドを確認することが可能である。他の実施態様では、リモートアクセスクライアント１２０は、ペイロードがランダムなデータまたは暗号化によるノイズを含んでいるので、ペイロードの一部が不明瞭であるかどうかを確認することが可能である。加えて、暗号化したペイロードは、レイヤー２、３、６、または７の暗号化のような、ネットワークスタック３１０ａおよび３１０ｂの任意のレイヤーに関連して暗号化することが可能である。
【０１７０】
ステップ４１５のいくつかの実施態様では、本発明の例示的方法４００は、パケット単位で報告されたＭＴＵ４０２ａおよび４０２ｂのサイズに対する調整を判断するか、または他の実施態様では、接続またはセッション単位で、それに応じてステップ４２０でＭＴＵ４０２ａおよび４０２ｂを調整する。一実施態様では、ＭＴＵ４０２ａおよび４０２ｂは、ネットワークパケットに対する暗号化オーバーヘッドの量だけ減じられる。場合によっては、例示的方法４００は、セッションまたは接続全体に対してＭＴＵ４０２ａおよび４０２ｂのサイズを一度決定し、セッション全体に対する暗号化オーバーヘッドを補う値だけ、ＭＴＵ４０２ａおよび４０２ｂのサイズを減じる。例えば、ネットワークパケットは、様々な暗号化オーバーヘッドを有する場合があるが、この調整は最大の暗号化オーバーヘッドを補う。更なる実施態様では、ＭＴＵ４０２ａおよび４０２ｂは、ネットワークパケットのエンドツーエンドのネットワークトラバースにおいて生じる場合のある、ゲートウェイ３４０による暗号化のような、ネットワークパケットがネットワークスタック３１０ａおよび３１０ｂを残した場合に生じうる暗号化を考慮するように調整することが可能である。
【０１７１】
加えて、ＭＴＵ４０２ａおよび４０２ｂのサイズは、暗号化オーバーヘッドに加えて、他のネットワーク性能因子に対して調整することが可能である。いくつかの実施態様では、ＭＴＵ４０２ａおよび４０２ｂのサイズは、暗号化オーバーヘッドによって減じられているが、ネットワーク通信に関連する他のオーバーヘッドおよび因子を補うようにさらに減じることが可能であり、また、他の場合では増加する。例えば、ＭＴＵ４０２ａおよび４０２ｂのサイズは、暗号化に関連していない因子に対して予め調整することが可能であり、本発明の技術を使用した後に、ＭＴＵ４０２ａおよび４０２ｂのサイズは、暗号化オーバーヘッドを考慮するように減じられる。当業者は、本発明の技術に従った暗号化オーバーヘッドの調整のほかに、またはこれに加えて、ＭＴＵの調整に対する他の因子および考慮すべきものが存在しうることを認識および理解するであろう。
【０１７２】
図５Ａおよび５Ｂを参照する。本発明は、更なる側面では、クライアント側のアプリケーション認識ネットワーク通信の優先順位付け技術に関する。本発明のリモートアクセスクライアント１２０は、アプリケーションのタイプおよび／または優先順位に基づいた、アプリケーションネットワーク通信の高機能かつクライアント中心の優先順位付けをクライアントに提供する。図５Ａのシステム５００に示されるように、コンピューティングデバイス１０２のリモートアクセスクライアント１０５は、ネットワーク１０４に接続される。クライアント１０５は、リモートアクセスクライアント１２０のエージェント３２６およびフィルタ３２２を介してネットワーク１０４にアクセスする、１つ以上のアプリケーション３３８ａ−３３８ｎを実行することが可能である。いくつかの実施態様では、アプリケーション３３８ａ−３３８ｎは、ＶｏＩＰのような１つ以上のリアルタイムデータ通信を提供する。他の実施態様では、１つ以上のアプリケーション３３８ａ−３３８は、コラボレーション、オンラインミーティング、および／またはデスクトップシェアリング関連のサービスまたは機能を提供することが可能である。
【０１７３】
図５Ａに示されるように、パケット取得機構３６５、３６５’は、クライアント１０５のアプリケーション３３８ａ−３３８ｎのうちのいずれかのネットワークトラフィックをインターセプトするために、リモートアクセスクライアント１２０のフィルタ３２２またはエージェント３２６に含めることが可能である。リモートアクセスクライアント１２０は、クライアント１０５のネットワーク通信をキューに入れて優先順位付けするための、あらゆるキュー５４０ａ−５４０ｎを含むことが可能である。一実施態様では、キュー５４０ａ−５４０ｎは、フィルタ３２２のＮＤＩＳドライバのようなネットワークドライバに含めることが可能であり、他の実施態様では、エージェント３２６とともに含めるか、またはエージェント３２６によるアクセスが可能である。キュー５４０ａ−５４０ｎは、パケット取得機構３６５によってインターセプトされたネットワークパケットのような、ネットワークパケットを格納および／または配列するためのあらゆるタイプおよび／または形態の好適な手段および／または機構を備えることが可能である。いくつかの実施態様では、キュー５４０ａ−５４０ｎは、クライアント１０５のアプリケーション３３８ａ−３３８ｎに関連するネットワークパケットに関連付けるか、または割り当てることが可能である。他の実施態様では、キュー５４０ａ−５４０ｎは、高、中、低のような優先順位のレベルによるか、または優先順位１・・・１０のように数値によって編成することが可能である。当業者は、キュー５４０ａ−５４０ｎの数は、３、５、または１０の優先順位レベルのような、あらゆる優先順位付けの細分性に基づくことが可能であることを認識および理解するであろう。加えて、キュー５４０ａ−５４０ｎのうちのいくつかは、ネットワークパケットが優先順位ベースのキュー５４０ａ−５４０ｎに分類され、および／または取り出される前に、ネットワークパケットを受信および／または送信するために使用することが可能である。
【０１７４】
リモートアクセスクライアント１２０はまた、ゲートウェイ３４０を介してネットワーク１０４上にルーティングするような、クライアントのネットワークパケットをエージェント３２６を介してどのようにリーティングするのかを判断するための、ルーティングテーブル５３８を有するか、これにアクセスするか、またはこれを使用することも可能である。一実施態様では、エージェント３２６は、図１Ａに例示されるように、ゲートウェイ３４０へのＳＳＬ  ＶＰＮ接続を確立および保持する。一実施態様では、ルーティングテーブル５３８は、ソースと宛先通信ポイントとの間の通信経路または接続を識別するために、ソースコンピューティングデバイスおよび宛先コンピューティングデバイスに関する情報を含む。ルーティングテーブル５３８は、ネットワーク１０４上の通信経路を識別するために、ソースＩＰアドレスおよびソースポート、および宛先ＩＰアドレスおよび宛先ポイントを含むことが可能である。例えば、ソースＩＰアドレスおよびソースポートは、クライアント１０５のＩＰアドレスおよびクライアント１０５上のアプリケーション３３８ａ−３３８ｎがネットワーク１０５上を通信するポートを表すことが可能である。宛先ＩＰアドレスは、アプリケーション３３８ａ−３３８ｎが、ピアデバイスによって使用される宛先ポートを介して通信する、ピアコンピューティングデバイスのＩＰアドレスを表すことが可能である。
【０１７５】
加えて、リモートアクセスクライアント１２０は、アプリケーション上で実行するアプリケーション３３８ａ−３３８ｎに関連するネットワーク通信のクライアント側の優先順位付けを指定するための、１つ以上のポリシー５２０を有することが可能である。これらのポリシー５２０は、あらゆる適切な手段および／または機構によって指定することが可能である。いくつかの実施態様では、ポリシー５２０は、アプリケーション３３８ａ−３３８ｎの名前および／またはアプリケーション３３８ａ−３３８ｎのタイプによって指定することが可能である。他の実施態様では、ポリシー５２０は、アプリケーション３３８ａ−３３８ｎによって使用される１つ以上のプロトコルのタイプ、および／またはネットワークパケットのペイロードのサイズに従って指定することが可能である。別の実施態様では、ポリシー５２０は、アプリケーションの実行がクライアント１０５のフォアグランドなのか、バックグラウンドなのかに基づいて、優先順位付けを定義する。さらに別の実施態様では、ポリシー５２０は、ホスト名またはＩＰアドレス、および／または宛先ポート番号のような宛先ネットワークアドレスに基づいて、優先順位を示すことが可能である。加えて、ポリシー５２０は、複数のアプリケーション３３８ａ−３３８ｎおよび／またはいずれかのポイントにおいてクライアント上で実行することが可能な複数のプロトコルを補うために、階層的に指定することが可能である。さらに、ポリシー５２０は、１つのアプリケーション３３８ａが実行している場合に、第２のアプリケーション３３８ｂが上位または下位の優先順位を有することが可能である、などの条件付きで指定することが可能である。当業者は、クライアント側のアプリケーション優先順位を定義するための多数の方法を認識および理解されよう。
【０１７６】
ポリシー５２０は、エージェント３２６でアクセス可能とすること、エージェント３２６に構成すること、またはエージェント３２６でロードすることが可能である。例えば、ポリシー５２０は、ゲートウェイ３４０によって提供するか、またはそれを介してダウンロードすることが可能である。ポリシー５２０は、ポリシーを指定するためのあらゆるタイプおよびフォーマットのシンタックスおよび／または言語を含むことが可能であり、電子的に１つ以上のネットワークパケットまたはＸＭＬファイルのようなファイルを介するなどの、あらゆるタイプおよび／または形態のメディアを介して提供することが可能である。ポリシー５２０は、あらゆる適切な手段および／または機構によってユーザーが設定できるようにすることが可能である。例えば、エージェント３２６は、ユーザーインターフェース、グラフィック、またはデザインのような構成機構、およびポリシー５２０を構成または指定するように構成した構成機構を提供することが可能である。
【０１７７】
図５Ａのシステム５００および図１Ａ乃至１Ｃを考慮して、図５Ｂの方法５５０に示される本発明の優先順位付け技術を以下に説明する。概略的に、例示的方法５５０のステップ５５５で、クライアント１０５は、クライアント１０５上のアプリケーション３３８ａ−３３８ｎに関連付けられた１つ以上のネットワークパケットをインターセプトし、ステップ５６０で、ネットワークパケットはキュー５４０ａ−５４０ｎに格納される。ステップ５６５で、インターセプトされた、およびキューに入れたネットワークパケットの優先順位は、アプリケーション３３８ａ−３３８ｎのタイプおよび／または優先順位に基づいて決定される。ステップ５７０で、決定された優先順位がネットワークパケットに示され、ステップ５７５で、ネットワークパケットは、この決定された優先順位に従って通信される。このように、アプリケーション３３８ａ−３３８ｎによってクライアント１０５上に生成される送信ネットワークパケットは、アプリケーション３３８ａ−３３８ｎのタイプおよび／または優先順位に基づいて、送信前にクライアント１０５によって優先順位が付けられる。例えば、アプリケーション３３８ａは、ゲートウェイ３４０へのＳＳＬ接続のＴＣＰ／ＩＰセッションを介してＵＤＰを通じたＲＴＰのような、ＶｏＩＰ通信のリアルタイムデータを生成することが可能である。クライアント１０５は、本発明の技術を使用して、非リアルタイムデータ通信アプリケーションのような、他のアプリケーションの上位にアプリケーション３３８ａのリアルタイムデータ通信の優先順位を付けることが可能である。この技術は、ネットワークトラフィックの優先順位付けがスイッチおよびルーターのような媒介ネットワークデバイス内に生じる、サービスの質（ＱｏＳ）ネットワークを補うことが可能である。
【０１７８】
例示的方法５００のステップ５５５で、クライアント１０５は、アプリケーション３３８ａ−３３８ｎ、ゲートウェイ３４０、ピアコンピューティングデバイス、およびネットワークスタックのネットワークレイヤーのうちのいずれかに対して、１つ以上のアプリケーション３３８ａ−３３８ｎのネットワークパケットを透過的にインターセプトすることが可能である。このように、本発明の技術は、あらゆるタイプのクライアント１０５上のアプリケーション３３８ａ−３３８ｎに対応する。いくつかの実施態様では、ネットワークパケットは、エージェント３２６またはフィルタ３２２を介して、パケット取得機構３６０によって、インターセプトされる。アプリケーション３３８ａ−３３８ｎのあらゆる受信および／または送信ネットワークパケットは、本発明のリモートアクセスクライアント１２０によってインターセプトすることが可能である。
【０１７９】
ステップ５６０で、ステップ５５５でインターセプトされたネットワークパケットは、キュー５４０ａ−５４０ｎに格納することが可能である。一実施態様では、ネットワークパケットは、ステップ５６５および５７０でネットワークパケットに優先順位を付ける前に、一時的なキュー５４０ａ−５４０ｎに格納される。他の実施態様では、ネットワークパケットは、ステップ５６５および／またはステップ５７０でネットワークパケットに優先順位を付けた後に、アプリケーション３３８ａ−３３８ｎに関連付けられた、決定された優先順位付きキュー５４０ａ−５４０ｎまたはキュー５４０ａ−５４０ｎに格納される。
【０１８０】
ステップ５６５で、本発明のリモートアクセスクライアント１２０は、優先順位を判断して任意の優先順位ベースのポリシー５２０を適用するために、ネットワークパケットとアプリケーション３３８ａ−３３８ｎとの関連付けを判断する。クライアント１０５は、エージェント３２６を介するなどして、あらゆる適切な手段および／または機構によって、ネットワークトラフィックをアプリケーション３３８ａ−３３８ｎに関連付けることができる。いくつかの実施態様では、エージェント３２６は、ヘッダー、フィールド、またはネットワークパケットのペイロード内のデータのタイプおよびコンテンツのような、ネットワークパケットのコンテンツのうちのいずれかによって、ネットワークパケットをアプリケーション３３８ａ−３３８ｎから生成されたものとして識別する。他の実施態様では、ネットワークパケットは、ソース、宛先ＩＰアドレス、ＩＰアドレスを有するポート番号、およびネットワークパケットのポート番号のような、ルーティングテーブル５３８からの情報と照合することによって、アプリケーション３３８ａ−３３８ｎに関連付けられる。いくつかの実施態様では、エージェント３２６は、識別したアプリケーションが実際にパケットを生成したことを確認するために、フレームモニター３６０を介するなどして、そのパケットにチェックサムを行うことが可能である。
【０１８１】
加えて、リモートアクセスクライアント１２０は、ネットワークパケットに関連付けられたアプリケーション３３８ａ−３３８ｎが、ネットワークパケットの実行がクライアント１０５のフォアグランドなのか、バックグラウンドなのかを判断することが可能である。さらに、リモートアクセスクライアント１２０は、クライアント１０５のオペレーティングシステムによってアプリケーション３３８ａ−３３８ｎに割り当てられた、プロセスタスクの優先順位のような、あらゆる優先順位を判断することが可能である。他の実施態様では、リモートアクセスクライアント１２０は、サイズ、メモリ使用量、総実行時間、および／または使用頻度のような、アプリケーション３３８ａ−３３８ｎの他の特性または統計を判断することが可能である。当業者は、クライアント側のアプリケーション認識ネットワーク通信の優先順位付けを提供するために、本発明の技術がアプリケーションの様々な特性を使用することが可能であることを認識および理解するであろう。
【０１８２】
ステップ５７０で、本発明のリモートアクセスクライアント１２０は、ステップ５６５でパケットに関連付けられたアプリケーション３３８ａ−３３８ｎに基づいて、インターセプトしてキューに入れたネットワークパケットの優先順位を示す。一実施態様では、エージェント３２６は、ポリシー５２０によって指定または示される優先順位付けのルールに従って、アプリケーション３３８ａ−３３８ｎのネットワークパケットに優先順位を適用するために、ポリシー５２０を使用する。いくつかの実施態様では、エージェント３２６は、アプリケーション３３８ａ−３３８ｎのネットワークパケットの優先順位を示すために、実行がフォアグランドなのか、バックグラウンドなのか、のようなアプリケーション３３８ａ−３３８ｎの特性を使用することが可能である。他の実施態様では、エージェント３２６は、アプリケーション３３８ａ−３３８ｎのネットワークパケットの優先順位を示すために、ポリシー５２０とアプリケーション３３８ａ−３３８ｎの特性とを組み合わせたものを使用することが可能である。
【０１８３】
いくつかの実施態様では、エージェント３２６は、ネットワークパケットキュー５４０ａ−５４０ｎの管理のために、フィルタ３２２に優先順位を示して、示された優先順位を適用する。エージェント３２６は、ＩＯＣＴＬインターフェースのようなアプリケーションプログラミングインタフェース（ＡＰＩ）、または当業者が公知の他のタイプおよび／または形態のインターフェースを介するなどして、あらゆる適切な手段および／または機構によって、フィルタ３２２にネットワークパケットの優先順位を通信することが可能である。一実施態様では、フィルタ３２２は、名前によってアプリケーション３３８ａ−３３８ｎを認識しないが、ルーティングテーブル５３８を介して、アプリケーション３３８ａ−３３８ｎのネットワークパケットへの優先順位を関連付けることができる。ネットワークパケットに対応するアプリケーション３３８ａ−３３８ｎは、ＩＰアドレスおよびポート番号のような、ソースと宛先識別子とを組み合わせたものによって識別することができる。このように、いくつかの実施態様では、エージェント３２６は、アプリケーション名の代わりにルーティング情報によって、フィルタ３２２に優先順位を示す。他の実施態様では、エージェント３２６は、フィルタ３２２に、ルーティングテーブル５３８内のルーティング情報に対する、アプリケーション名またはプロセスＩＤなどによる、アプリケーション３３８ａ−３３８ｎ間のマッピングを提供する。
【０１８４】
アプリケーション３３８ａ−３３８ｎの示された優先順位に基づいて、いくつかの実施態様では、フィルタ３２２は、優先順位に対応して、ネットワークパケットをキュー５４０ａ−５４０ｎ内に配置、配列、またはコーディネートすることが可能である。一実施態様では、フィルタ３２２は、ネットワークパケットを、一時的なキュー５４０ａ−５４０ｎ、メモリ、または他のストレージから、アプリケーション３３８ａ−３３８ｎに関連付けられたキュー５４０ａ−５４０ｎ、優先順位に関連付けられたキュー５４０ａ−５４０ｎ、またはアプリケーションと優先順位の両方に関連付けられたキュー５４０ａ−５４０ｎに移動させることが可能である。例えば、一実施態様では、全ての高優先順位のネットワークトラフィックを、高優先順位付きキュー５４０ａに配列して、他のアプリケーション３３８ａ−３３８ｎの前のリアルタイムデータアプリケーション３３８ａ−３３８ｎのような、アプリケーション３３８ａ−３３８ｎの優先順位の順序に基づいた順番で構成することが可能である。いくつかの実施態様では、ネットワークパケットは、ネットワークパケットがＦＩＦＯ様式などでパケット取得機構３６５によってインターセプトされた時間に基づいて、優先順位付きキュー５４０ａ−５４０ｎの順番で配列することが可能である。更なる一実施態様では、１つのキュー５４０ａ−５４０ｎは、優先順位付けのためにフィルタ３２２が使用することが可能である。各ネットワークパケットは、全てのアプリケーション３３８ａ−３３８ｎおよびインターセプトされたネットワークパケットにわたるパケットの優先順位付けによってパケットを提供するために、全ての他のインターセプトされたネットワークパケットのそれぞれの優先順位の順序で配置および配列することが可能である。当業者は、ネットワークパケットを、高、中、低または他の細分性などによって、種々の優先順位付きキュー５４０ａ−５４０ｎに配列すること、および本願明細書に記述される本発明のオペレーションの実施におけるあらゆる好適な様式でキューに配置または配列することが可能であることを認識および理解されよう。
【０１８５】
一実施態様では、アプリケーション３３８ａ−３３８ｎの全てのネットワークパケットは、アプリケーション５４０ａ−５４０ｎに関連付けられたキュー５４０ａ−５４０ｎ内に配置される。例えば、第１の宛先ＩＰアドレスに通信するアプリケーションのインターセプトされたネットワークパケット、および第１の宛先ポートは、第１のキュー５４０ａに配置することが可能である。別の実施態様では、電子メールまたは音声アプリケーションのような、あるタイプのアプリケーション３３８ａ−３３８ｎの全てのネットワークパケット、またはＲＴＰまたはＵＤＰのような、アプリケーション３３８ａ−３３８ｎが使用するあるタイプのプロトコルの全てのネットワークパケットは、１つ以上のアプリケーションのネットワークパケットに優先順位をつけるために、キュー５４０ａ−５４０ｎ内に配置することが可能である。例えば、オンラインのコラボレーション関連のアプリケーション３３８ａ−３３８ｎは、コラボレーション関連のアプリケーションの第１のキュー５４０ａに配置して優先順位をつけることが可能である。第２のキュー５４０ｂは、電子メール関連のアプリケーション３３８ａ−３３８ｎに使用することが可能である。別の例では、キュー５４０ａは、リアルタイムデータを通信するか、またはＲＴＰおよび／またはＵＤＰプロトコルを使用して通信するアプリケーション３３８ａ−３３８ｎに使用することが可能である。更なる例では、キュー５４０ａは、ＩＣＡまたはＲＤＰのようなリモートディスプレイプロトコルを使用して通信するアプリケーション３８ａ−３３８ｎに使用することが可能である。
【０１８６】
特定のアプリケーション３３８ａ−３３８ｎ、アプリケーション３３８ａ−３３８ｎのタイプまたはカテゴリ、またはプロトコルによって構成されるアプリケーション関連のキュー５４０ａ−５４０ｎのそれぞれにおいて、ネットワークパケットを、フォアグラウンドのアプリケーション、ネットワークパケットのサイズ、ネットワークパケットがインターセプトされた時間などの、それらを生成するアプリケーション３３８ａ−３３８ｎの特性によって、さらに順位付けすることが可能である。いくつかの実施態様では、ポリシー５２０が、存在しないか、またはネットワークパケットに適用していないので、またはポリシー５２０が、優先順位付けのためにネットワークパケットを無視するか、または処理しないことが示されているので、１つ以上のキュー５４０ａ−５４０ｎを、インターセプトされたが優先順位が付けられていないネットワークパケットに使用することが可能である。当業者は、アプリケーション３３８ａ−３３８ｎ、アプリケーション３３８ａ−３３８ｎのタイプ、またはアプリケーション３３８ａ−３３８ｎが使用するプロトコルに関連付けられたキュー５４０ａ−５４０ｎにおける優先順位ベースの様式で、ネットワークパケットを配置および配列することが可能な様々な方法があること、および優先順位は、クライアント１０５に指定されたポリシー５２０に基づくことが可能であることを認識および理解するであろう。
【０１８７】
例示的方法５５０のステップ５７５で、ネットワークパケットは、ネットワークパケットの決定された優先順位に基づいて、キュー５４０ａ−５４０ｎから通信される。いくつかの実施態様では、最も高い優先順位付きキュー５４０ａ−５４０ｎのネットワークパケットが最初に通信され、次いで次に高い優先順位付きキュー５４０ａ−５４０ｎのネットワークパケットが２番目に通信される、などのように、ネットワークパケットは、優先順位付きキュー５４０ａ−５４０ｂに構成される。他の実施態様では、キュー５４０ａ−５４０ｎがアプリケーション３３８ａ−３３８ｎによって構成されるので、ステップ５７５で、本発明は、アプリケーション３３８ａ−３３８ｎのそれぞれの優先順位に基づいて、キュー５４０ａ−５４０ｎからネットワークパケットを通信する。キュー５４０ａ−５４０ｎの組織および管理に関わらず、当業者は、本発明のリモートアクセスクライアントは、決定された優先順位による、またはこれに従った様式のキューであり、またクライアントのポリシー５２０に基づくか、またはこれから導出することが可能な様式のキューからネットワークパケットを通信することを認識および理解するであろう。
【０１８８】
いくつかの実施態様では、本発明のリモートアクセスクライアント１２０は、どのネットワークパケットをどのキューから通信するかの判断において、他のネットワーク因子を考慮する。例えば、リモートアクセスクライアント１２０は、アプリケーション３３８ａ−３３８ｎに関連するＴＣＰ接続に対するゼロのウィンドウサイズを受信するなどの、ネットワークの混雑の示度を受信することが可能である。別の例では、リモートアクセスクライアント１２０は、特定の宛先への再送信の多さを認識することが可能である。このように、いくつかの実施態様では、リモートアクセスクライアント１２０は、ネットワークパケットがキュー５４０ａ−５４０ｎにおいて他のネットワークパケットよりも高い優先順位を有することが可能であっても、混雑のような他のネットワークの因子に関連するネットワークパケットの通信を抑制するか、または通信させないことが可能である。したがって、クライアント１０５は、クライアント１０５のあらゆるポリシー５２０に基づいてこれに従い、さらにネットワーク上で生じるネットワークの統計および他の因子を考慮して、アプリケーション３３８ａ−３３８ｎ上のクライアント１０５のネットワーク通信の優先順位付けを制御および管理する。
【０１８９】
図６Ａおよび６Ｂを参照する。更なる側面では、本発明は、永続的かつ信頼性の高い接続性のためのネットワークの混乱から保護する技術の提供に関する。図６Ａは、図３Ａを参照して上述したように環境３００を示す。環境３００は、ネットワークスタック３１０ａおよび３１０ｂを示し、図１Ａ乃至１Ｃ、２Ａ、または５Ａに示されるコンピューティングデバイス１０２およびゲートウェイ３４０のうちのいずれかのような、コンピューティングデバイス１０２ａおよび１０２ｂ、またはゲートウェイ３４０のネットワークスタックを表すことが可能である。当業者は、ネットワークスタック３１０ａおよび３１０ｂのそれぞれが、フレームネットワークレイヤーの上位のＴＣＰ／ＩＰネットワークレイヤーのような、１つ以上のネットワークレイヤーを備えることが可能であることを認識および理解するであろう。図６Ａの環境３００には、ネットワークスタック３１０ａおよび３１０ｂが特定の一組のネットワークレイヤーとともに示されるが、当業者は、ネットワークスタック３１０ａおよび３１０ｂが、あらゆる好適な組み合わせにおいて、あらゆるタイプおよび形態のネットワークレイヤーを有することが可能であり、ネットワークスタック３１０ａおよび３１０ｂのそれぞれが、他のネットワークスタックに関して異なる形態の各レイヤーを有することが可能であることを認識および理解するであろう。
【０１９０】
ネットワークスタック３１０ａおよび３１０ｂは、ネットワークスタックの第１の部分６０５ａおよび６０５ｂと、ネットワークスタックの第２の部分６１０ａおよび６１０ｂと、を有するとみなすことが可能である。図６Ａのネットワークスタック３１０ａおよび３１０ｂの例に示されるように、ネットワークスタックの第１の部分６０５ａおよび６０５ｂは、ＴＣＰネットワークレイヤーより下位のネットワークレイヤーを備える。第２の部分６１０ａおよび６１０ｂは、ＳＳＬプロトコルレイヤーを通じたＵＤＰなどのような、ＴＣＰネットワークレイヤーの上位にそれらのネットワークレイヤーを備えることが可能である。第１の部分６０５ａおよび６０５ｂと第２の部分６１０ａおよび６１０ｂは、ＴＣＰレイヤーで分けて、セグメント化して、または分割して示されているが、当業者は、第１の部分および第２の部分を、本発明のネットワークの混乱から保護する技術を実施する上位または下位の分割レイヤーに形成することが可能であることを認識および理解するであろう。
【０１９１】
図６Ａに示されるネットワークスタック３１０ａおよび３１０ｂは、図５Ａに示されるクライアントのような、クライアント１０５上のアプリケーション３３８ａ−３３８ｎを表すことが可能であり、第２のコンピューティングデバイス１０２ｂ、またはこの代わりにゲートウェイ３４０に、ピアツーピアのＳＳＬ  ＶＰＮ接続を確立する。クライアント１０５は、ノートブック、携帯情報端末（ＰＤＡ）、スマートフォン、またはあらゆるタイプのモバイルコンピューティングまたは通信デバイスのような、モバイルクライアントであってよい。クライアント１０５は、ピアデバイス１０２ｂまたはゲートウェイ３４０に対して確立されたＳＳＬセッションを介してＵＤＰを通じた、ＵＤＰプロトコルまたはＲＴＰを介して、ＶｏＩＰ通信のようなリアルタイムデータを通信することが可能である。一実施態様では、リモートアクセスクライアント１２０のエージェント３２６は、ゲートウェイ３４０またはピアコンピューティングデバイス１０２ｂへのＳＳＬまたはＳＳＬ  ＶＰＮセッションを確立および保持する。エージェント３２６は、ユーザーモード３３２で実行することが可能であり、アプリケーションレイヤーのプロトコルとともに、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂに関連する、あらゆるネットワークレイヤーおよびプロトコル処理をすることが可能である。ＴＣＰ／ＩＰベースのネットワーク１０４のように、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂのＳＳＬセッションを通じたＵＤＰを、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを形成するＴＣＰ／ＩＰスタックを通じて通信することが可能である。図１Ａまたは図５Ａに示されるように、本発明のリモートアクセスクライアント１２０を考慮して、フィルタ３２２は、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂにおいてカーネルモード３３２で動作するネットワークドライバであってよい。
【０１９２】
本発明は、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂに対するあらゆるタイプおよび／または形態のネットワークの混乱のような、ネットワークレベルの接続の中断中のネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂを保持するために、図６Ｂの例示的方法６５０で示されるような、ネットワークの混乱から保護する技術を使用する。本発明のネットワークの混乱から保護する技術は、クライアント１０５のアプリケーション３３８ａ−３３８ｎ、クライアント１０５のユーザー、第１の部分６０５ａおよび６０５ｂの上位のいずれか１つ以上のネットワークレイヤー、およびゲートウェイ３４０またはピアコンピューティングデバイス１０２ｂおよびそれぞれのネットワークスタック３１０ａおよび３１０ｂのいずれかの部分に対して、透過的に実行することが可能である。一実施態様では、クライアントのユーザーに、ネットワークが途絶したこと、またはセッションが中断したことを通知せずに、ネットワークの混乱から保護される。
【０１９３】
例示的方法６５０の概略では、ステップ６６５で、クライアント１０５は、ピアコンピューティングデバイスまたはゲートウェイのような、クライアントと別のデバイスとの間のネットワーク接続を通じて、少なくとも第１のプロトコルを介してセッションを確立する。このように、ネットワークスタック３１０ａおよび３１０ｂは、クライアント１０５上に確立されるか、または使用される。ネットワークスタック３１０ａおよび３１０ｂは、第１の部分６０５ａおよび６０５ｂおよび第２の部分６１０ａおよび６１０ｂを有する。ステップ６６０で、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを廃止させるたり、または使用を途絶させたり、使用を継続させなくする、ネットワーク接続の混乱を検出する。ステップ６６５で、本発明は、第２の部分６１０ａおよび６１０ｂのネットワークレイヤーに関連付けられた、１つまたは複数のセッションの混乱または保持中に、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂを保持する。
【０１９４】
混乱中に、ステップ６７０で、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂに関連するいずれかのネットワークパケットをキューに入れることが可能である。ステップ６７５で、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを再確立するか、またはネットワークの混乱から受信する。ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを再確立しながら、本発明は、第２の部分６１０ａおよび６１０ｂ、およびそのセッションを保持し、ステップ６８０で、第２の部分６１０ａおよび６１０ｂをネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂとリンクするか、または再び関連付けることによって、セッションを継続できるようにする。ネットワーク接続および／またはセッションは、ステップ６８０で、自動的に再認証することが可能である。ステップ６８５で、例示的方法は、任意のキューに入れたネットワークパケットを通信して、ネットワークの混乱が生じなかったかのようにセッションを透過的に継続することが可能である。
【０１９５】
例示的ステップ６５５の一実施態様では、第１のコンピューティングデバイス１０２ａは、あらゆる好適な手段および／または機構によって、およびあらゆるタイプおよび／または形態の接続ベースのプロトコルを使用することによって、ピアコンピューティングデバイス１０２ｂまたはゲートウェイ３４０のような、第２のデバイスとのネットワーク接続を確立することが可能である。例えば、ＴＣＰ／ＩＰネットワーク上のＴＣＰ接続を介して、またはＩＰＸ／ＳＰＸネットワーク上のＳＰＸ接続によって、ネットワーク接続を確立することが可能である。いくつかの実施態様では、ネットワーク接続は、図５Ａに示されるいずれかのアプリケーションのような、アプリケーション３３８ａ−３３８ｎのうちのいずれかによって開始することが可能である。例えば、Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ社のＩＣＡクライアント、またはＭｉｃｒｏｓｏｆｔ社のリモートディスプレイクライアントのようなリモートディスプレイクライアントは、ネットワーク接続を開始または確立することが可能である。他の実施態様では、エージェント３２６、フィルタ３２２、またはリモートアクセスクライアント１２０の他の部分を介して、例示的ステップ６６５のネットワーク接続を開始および／または確立することが可能である。一実施態様では、ネットワーク接続を確立することで、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを形成する。他の実施態様では、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂ、またはその一部分は、クライアント１０５の開始時に、ネットワーク１０４への接続を介して確立される。
【０１９６】
いくつかの実施態様では、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂは、ＩＣＡまたはＲＤＰのリモートディスプレイプロトコルのような、ネットワーク接続を通じたあらゆるタイプおよび／または形態のプロトコルを介して、ＳＳＬセッションのような１つ以上のセッションを確立することによって形成される。セッションは、任意のアプリケーション３３８ａ−３３８ｎか、またはクライアントのリモートアクセスクライアント１２０を介して確立することが可能である。一実施態様では、セッションは、ピアコンピューティングデバイス１０２ｂまたはゲートウェイ３４０によって、トンネリングまたはゲートウェイセッションに対応することができる。別の実施態様では、セッションは、例えばシグナリングプロトコル（ＳＩＰ）を介して確立されるメディアセッションのような、あらゆるタイプの対話型セッションであってよい。例えば、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂは、図２Ｂの例示的方法２６０によって確立されたもののような、ＶｏＩＰ通信セッションを含むことが可能である。加えて、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂに関連付けた複数のセッションが存在してよい。例えば、ＳＳＬまたはＳＳＬ  ＶＰＮセッションは、１つのセッションを形成することが可能であり、一方で、ＵＤＰを通じたＲＴＰを介したメディアセッションなどが、第２のセッションを形成することが可能である。加えて、ネットワークスタック３１０ａおよび３１０ｂの任意のアプリケーションレイヤーでは、クライアント１０５上の１つ以上のアプリケーション３３８ａ−３３８ｎは、ピアコンピューティングデバイス１０２ｂによってアプリケーションレベルのセッションを確立することが可能である。一実施態様では、リモートアクセスクライアント１２０のエージェント３２６は、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂ、および１つ以上の関連するセッションの確立および保持に関与する。
【０１９７】
本発明の例示的方法６５０のステップ６６０で、ネットワーク接続の混乱を検出する。一実施態様では、ネットワークの混乱は、ネットワークとネットワークのセグメントとの間を移動するクライアント１０５によって生じる場合があり、いくつかの実施態様では、クライアント１０５に、新しいネットワークＩＰアドレスおよび／またはホスト名を取得させる。いくつかの実施態様では、この混乱は、例えばＴＣＰまたはＳＰＸ接続の切断を生じさせるような、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを途絶させる。一側面では、この混乱によって、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂ、またはその任意の一部分が廃止されるか、または再確立、再接続、再設定、または再構成が必要になる。例えば、いくつかの実施態様では、ネットワークスタックのＩＰレイヤーは、ＴＣＰレイヤーを再確立している間、そのままの状態を保持することが可能である。一実施態様では、任意のＴＣＰ関連のドライバは、再起動を必要とする場合がある。他の実施態様では、ネットワーク接続が途絶して、新しいＴＣＰ接続を確立するしかない場合であっても、ＴＣＰ／ＩＰレイヤーはそのままの状態である。他の実施態様では、ＴＣＰ／ＩＰレイヤーはそのままの状態であるが、クライアント１０５のＩＰアドレスを変更するような、新しいネットワークまたはネットワークセグメントに対して、ＴＣＰ／ＩＰレイヤー自体を再構成する必要がある。当業者は、ネットワーク接続が途絶されて、ネットワークスタックの第１の部分に影響または作用を及ぼしうる、様々な状況があることを認識および理解するであろう。
【０１９８】
いくつかの実施態様では、エージェント３２６またはリモートアクセスクライアント１２０の他の部分は、あらゆる適切な手段および／または機構によってネットワークの混乱を検出することが可能である。一実施態様では、エージェント３２６は、エラーメッセージを受信することによって、またはネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂに対するＡＰＩコールの呼び出し時または実行時の失敗によって、ネットワークの混乱を判断することが可能である。例えば、第２の部分６１０ａおよび６１０ｂに対するエージェント３２６によって保持されるＳＳＬセッションは、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂのＴＣＰ接続に依存または従属する。エージェント３２６がＳＳＬセッションを介して処理を行うとき、エージェント３２６は、ＴＣＰ接続の問題を示すエラーまたは失敗のメッセージを受信することが可能である。他の実施態様では、エージェント３２６は、ネットワークの混乱を示すイベントまたはメッセージを、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂの任意のネットワークレイヤーから受信することが可能である。当業者は、ネットワークの混乱を検出することが可能な様々な方法を認識および理解するであろう。
【０１９９】
例示的ステップ６６５で、いくつかの実施態様では、ネットワークの混乱を検出すると、エージェント３２６または本発明のリモートアクセスクライアント１２０の他の部分は、混乱中に、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂを保持する。例えば、エージェント３２６によって保持されたＳＳＬベースのセッションは、潜在的なＴＣＰ接続に依存するが、エージェント３２６は、ＴＣＰ接続に対する混乱中に、ＳＳＬセッションを開けたままか、またはアクティブのままにする。ネットワークスタックの第２の部分６１０ａおよび６１０ｂの１つ以上のレイヤーに関連付けられた複数のセッションが存在しうるので、エージェント３２６は、いくつかの実施態様では、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂが途絶していても、その複数のセッションのうちの１つ以上または全てを開けたままか、またはアクティブのままにする。
【０２００】
例示的方法６５０のステップ６７０で、本発明のリモートアクセスクライアント１２０は、いくつかの実施態様では、ネットワークの混乱中に、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂに関連するプロトコルのうちの、いずれかの１つ以上のネットワークパケットをキューに入れる。リモートアクセスクライアント１２０は、図５Ａに示されるキュー５４０ａ−５４０ｎのうちのいずれかのような、あらゆるタイプおよび／または形態の待ち行列機構を使用することが可能である。他の実施態様では、リモートアクセスクライアント１２０は、混乱中に、音声通信のためのＵＤＰを通じたＲＴＰのような、不可逆プロトコルに関連するあらゆるパケットのような、ネットワークパケットを破棄することが可能である。場合によっては、音声通信などにおける待ち時間および品質の問題を軽減するために、ＵＤＰパケットのようなパケットを破棄することが望ましい場合がある。更なる実施態様では、リモートアクセスクライアント１２０は、いくつかのネットワークパケットをキューに入れて、他のネットワークパケットを破棄することが可能である。更なる一実施態様では、リモートアクセスクライアント１２０は、いくつかのネットワークパケットをキューに入れて、所定の時間の経過後にネットワークパケットのいくつか、または全てを破棄することが可能である。リモートアクセスクライアント１２０は、どのネットワークパケットをキューに入れる、および／または破棄するのかを判断するために、ポリシー５２０を使用することが可能である。例えば、第２のアプリケーション３３８ｎのネットワークパケットを破棄しながら、第１のアプリケーション３３８ａのネットワークパケットをキューに入れることが可能である。他の実施態様では、リモートアクセスクライアント１２０は、混乱中にネットワークパケットをキューに入れる、および／または破棄するかどうかを判断するために、当業者に公知のあらゆるネットワーク統計またはあらゆるネットワークトラフィックの検査技術（例、ステートフル検査）を使用することが可能である。
【０２０１】
例示的方法６５０のステップ６７５で、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂが再確立され、一方で、任意の所望のセッションまたはネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂのセッションの保持に加えて、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂが保持される。ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂは、あらゆる適切な手段および／または機構によって再確立することが可能である。例えば、クライアント１０５は、移動しているモバイルクライアント１０５に対する新しいネットワークへのロギングなどによって、ネットワーク１０４へのＴＣＰ／ＩＰ接続を再確立することが可能である。他の実施態様では、リモートアクセスクライアント１２０は、エージェント３２６またはフィルタ３２２を介するなどして、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを再確立する。例えば、エージェント３２６は、新しいＴＣＰ接続を開始および確立することが可能である。第１の部分６０５ａおよび６０５ｂを再確立すると、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂは、ネットワークスタック３１０ａおよび３１０ｂを再確立するために、第１の部分６０５ａおよび６０５ｂとリンクされるか、再び関連付けられるか、または第１の部分６０５ａおよび６０５ｂの使用を開始するか、または使用を継続する。いくつかの実施態様では、エージェント３２６は、第１の部分６０５ａおよび６０５ｂが再確立されたことを、任意のネットワークレイヤーのイベントによって通知されるか、または他の実施態様では、第１の部分６０５ａおよび６０５ｂが再確立されたことを判断するために、所定の頻度でポーリングを行うことが可能である。例えば、エージェント３２６は、ＴＣＰ接続がアクティブであるか、または再接続することができるのかを確認することが可能である。
【０２０２】
いくつかの実施態様では、ステップ６８０で、エージェント３２６のようなリモートアクセスクライアント１２０は、ネットワークスタック６１０ａおよび６１０ｂの第１の部分６０５ａおよび６０５ｂに対するＴＣＰ接続のようなネットワーク接続のために、クライアント１０５またはクライアント１０５のユーザーを自動的に再認証することが可能である。例えば、リモートアクセスクライアント１２０は、クライアント１０５のユーザーのあらゆるネットワーク関連の信用証明書を使用して、ネットワーク１０４に対して、クライアント１０５を自動的に再認証することが可能である。加えて、リモートアクセスクライアント１２０は、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂに関連付けられた任意のセッションのために、クライアント１０５またはクライアント１０５のユーザーを自動的に再認証することが可能である。例えば、エージェント３２６と、ゲートウェイ３４０またはピアコンピューティングデバイス１０２ｃとの間のＳＳＬセッションを、再認証することが可能である。
【０２０３】
別の例では、アプリケーション３３８ａは、ホストサービス、ウェブサーバー、またはアクセスのために認証証明書を使用するアプリケーションサーバーにアクセスしていることが可能である。エージェント３２６は、認証証明書に関連するアプリケーションを使用して、対応するサービスまたはサーバーに対して、アプリケーション３３８ａを自動的に再認証することが可能である。いくつかの実施態様では、リモートアクセスクライアント１２０は、ネットワークアクセスおよび／またはＴＣＰ接続、ＳＳＬまたはＳＳＬ  ＶＰＮセッション、および／またはメディアインタラクティブのユーザーセッション（例、ＶｏＩＰ通話セッション）のようなあらゆるアプリケーションレベルのセッションなどに対して、複数のレベルでクライアントおよび／またはクライアント１０５のユーザーを再認証することが可能である。さらに、リモートアクセスクライアント１２０は、ステップ６８５の前、ステップ６８５の間（例えば、キューに入れたネットワークパケットの通信後だが他の通信を継続する前）、またはステップ８６５の後（サーバーまたはゲートウェイ３４０のようなピアコンピューティングデバイスからの認証のリクエストに応えて）、いつでも再認証することが可能である。
【０２０４】
例示的方法６５０のステップ６８５で、本発明のリモートアクセスクライアント１２０は、ネットワークスタックの第２の部分６１０ａおよび６１０ｂの１つまたは複数のセッションの使用を継続する。ステップ６７０で、任意のネットワークパケットがキューに入れられたか、またはキューに入れたままの場合、リモートアクセスクライアント１２０は、キューに入れたネットワークパケットを通信して、クライアント１０５の１つ以上のアプリケーション３３８ａ―３３８ｎによって生成されるか、またはこれに送信されるネットワークパケットのような、クライアント１０５のあらゆるネットワークパケットの通信を継続する。このように、本発明のネットワークの混乱から保護する技術は、ノマディックなモバイルコンピューティングのソリューションにシームレスかつ透明なソリューションを提供し、概して信頼性が高く、永続的なネットワーク接続およびアクセスを提供する。
【０２０５】
ＶｏＩＰ通信の例では、本発明の例示的方法６５０は、ネットワークの混乱による通話のドロップ回数を減少させて、ＶｏＩＰの使用およびエクスペリエンスを改善する。本発明のリモートアクセスクライアント１２０は、セッションおよびネットワークへの接続を自動的に保持するので、ＶｏＩＰのユーザーは、ネットワークのアベイラビリティにおいて、一時的なネットワークの混乱による通話の再接続が不要になる。加えて、本発明のリモートアクセスクライアント１２０は、ネットワークの混乱の後にセキュリティを提供するために、接続およびセッションを自動的に再認証する。さらに、本発明のネットワークを保護する技術は、１）ネットワークの混乱中にトランザクション、コマンド、またはオペレーションを自動的に継続すること、２）ネットワークの混乱中にセッションに関連するコンテキストおよびキャッシュを保持すること、３）ネットワークの変更によるクライアントのネットワークアドレスの変更を自動的に処理すること、に対して有用である。
【０２０６】
信頼性が高く、永続的な接続を提供することによって、本発明はまた、図１Ｃのクライアント１０５ａおよび１０５ｂのような、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間で使用される機能の一部として、トランザクション、コマンド、またはオペレーションの中断も回避する。例えば、Ｗｉｎｄｏｗｓ（登録商標）  Ｅｘｐｌｏｒｅｒを使用したファイルのコピーオペレーションは、ネットワーク接続に混乱が生じた後に動作を継続するようにデザインされていない。クライアント１０５上のユーザーは、クライアント１０５からサーバー１０２ｃにファイルをコピーするために、Ｗｉｎｄｏｗｓ（登録商標）  Ｅｘｐｌｏｒｅｒのファイルコピー機能を使用することが可能である。１つまたは複数のファイルサイズにより、本オペレーションは、完了に比較的時間がかかる場合がある。サーバーへのファイルコピーのオペレーション中に、クライアント１０５とサーバーとの間のネットワーク接続に中断があれば、ファイルコピーは失敗することになる。ネットワーク接続が再確立されると、ユーザーは、クライアント１０５からサーバーにファイルをコピーするために、Ｗｉｎｄｏｗｓ（登録商標）  Ｅｘｐｌｏｒｅｒから別のファイルコピー機能を起動しなければならなくなる。本発明下では、ユーザーは、別のファイルコピーオペレーションを起動する必要はない。ネットワーク接続は、図６Ｂに示されるように、本発明のネットワークの混乱から保護する技術によって再確立される。このように、Ｗｉｎｄｏｗｓ（登録商標）  Ｅｘｐｌｏｒｅｒのファイルコピーには、ネットワーク接続における中断が知らされないので、失敗することはない。オペレーションを失敗せずに継続できるように、リモートアクセスクライアント１２０は、あらゆる接続を再確立してキューに入れたあらゆるデータを送信する。リモートアクセスクライアント１２０は、ネットワーク接続の中断によってサーバーに転送されなかった、ファイルコピーオペレーションに関連するデータのキューを保持する。ネットワーク接続が再確立されると、リモートアクセスクライアント１２０は、キューに入れたデータを送信することができ、次いで適当な時期にファイルコピーオペレーションに関連するデータの転送を継続する。
【０２０７】
本発明の本側面は、ファイルコピーオペレーション例に関して説明しているが、当業者は、ネットワーク接続の混乱によって失敗せずに、さらにはクライアント１０５またはクライアント１０５のユーザーが、混乱の存在または混乱の通知があることを認識することなく、第１のコンピューティングデバイス１０２ａと第２のコンピューティングデバイス１０２ｂとの間で行われる、あらゆるオペレーション、処理、コマンド、ファンクションコールなどを保持および継続できることを認識および理解するであろう。加えて、アプリケーション３３８、ゲートウェイ３４０、第２のコンピューティングデバイス１０２ｃ、およびネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂのいずれかの部分に対して、トランザクションまたはオペレーションを透過的に保持および継続することができる。
【０２０８】
ピアコンピューティングデバイス１０２ｂまたはゲートウェイ３４０への信頼性が高く、永続的な接続を有するクライアント１０５を提供することによって、本発明は、ネットワーク接続の中断中にユーザーセッションを保持することによって、サーバー上のホストサービスのような、ピア上のアプリケーション３３８によって新しいユーザーセッションが開かれるプロセスを回避する。ピアコンピューティングデバイス間の各ユーザーセッションに対して、各コンピューティングデバイスは、セッション固有のコンテキストおよびキャッシュ、およびユーザーセッションのそのインスタンスに関連する他のアプリケーション固有の機構を保持することが可能である。確立された新しいユーザーセッションのそれぞれに対して、新しいユーザーセッションを反映するために、これらのセッション固有のコンテキストおよびキャッシュを再ポピュレートまたは再確立する必要がある。例えば、クライアント１０５上のユーザーは、ウェブサーバーまたはウェブアプリケーションを有するサーバー１０２ｃによって、ｈｔｔｐセッションを有することが可能である。サーバー１０２ｃは、クライアント１０５によるｈｔｔｐセッションのこのインスタンスの提供に固有のコンテキストを保持することが可能である。コンテキストは、サーバーのメモリ内か、サーバーのファイル内か、またはサーバー１０２の機能の提供に関連する他のコンポーネント内に格納することが可能である。また、クライアント１０５は、ウェブサーバーへの発行済みのリクエストのトラックを保持するための機構のような、ｈｔｔｐセッションのインスタンスに固有のローカルなコンテキストを有することが可能である。このコンテキストは、クライアント１０５のメモリ内か、クライアント１０５のファイル内か、またはクライアント１０５とインターフェースされた他のソフトウェアコンポーネント内に格納することが可能である。
クライアント１０５とサーバー１０２ｃとの間の接続が永続的でない場合は、サーバー１０２ｃおよびクライアント１０５上に、新しいユーザーセッションを、新しいセッション固有のコンテキストとともに確立する必要がある。本発明は、新しいセッション、およびそのセッションによる新しい特定のセッションコンテキストを再確立する必要がないように、セッションを保持する。
【０２０９】
本発明は、ネットワークレベルの接続の中断中に、クライアントのユーザーにセッションが中断されたことを通知せずにユーザーセッションを保持する。本発明の本則面のオペレーションでは、クライアント１０５は、ピアコンピューティングデバイスへの接続を確立する。この接続を介して、クライアント１０５とサーバーとの間のセッションが確立される。リモートアクセスクライアント１２０は、認証証明書、および確立したセッションに対するクライアント１０５およびホストサーバー１０２ｃのコンテキストのような、セッションに関連するあらゆる情報を格納および保持することができる。ネットワーク接続の混乱を検出したとき、リモートアクセスクライアント１２０は、ネットワークスタックの第２の部分６１０ａおよび６１０ｂを保持しながら、ネットワークスタック３１０ａおよび３１０ｂの第１の部分６０５ａおよび６０５ｂを再確立することができる。ネットワーク接続の混乱によって、クライアント１０５とサーバー１０２ｃとの間のセッションが使用する潜在的なＴＣＰ／ＩＰ接続に中断が生じる場合がある。しかし、ネットワークスタック３１０ａおよび３１０ｂの第２の部分６１０ａおよび６１０ｂが保持されるので、セッションが中断したことをクライアント１０５のユーザーに通知せずに、ネットワーク接続を再確立した後に、そのセッションを再確立および／または継続することができる。したがって、ネットワーク接続の混乱によって生じるセッションの中断は、本発明のネットワークの混乱から保護する技術を使用して、効果的にユーザーに知られないようになる。
【０２１０】
さらに、信頼性の高い、永続的な接続を提供することによって、本発明はまた、クライアント１０５が、セッションまたはクライアント１０５上のアプリケーション３３８を再起動せずに、異なるネットワークトポロジを介してトラバースできるようにする。例えば、クライアント１０５は、無線ネットワーク接続を有するノートブックコンピュータであってよい。クライアント１０５が、第１の無線ネットワークから第２の無線ネットワークに移動するとき、クライアントのネットワーク接続は、第２の無線ネットワークとのネットワーク接続を確立するときに、第１の無線ネットワークから一時的に途絶させることが可能である。第２の無線ネットワークは、クライアント１０５に、ホスト名またはインターネットプロトコルアドレスのような、新しいネットワーク識別子を割り当てることが可能である。この新しいネットワーク識別子は、第１の無線ネットワークがクライアント１０５に割り当てたネットワーク識別子とは異なるものであってよい。別の例では、クライアント１０５は、イーサネット（登録商標）ケーブルを介して、ネットワーク上のポートに物理的に接続することが可能である。物理的接続は、切断して、別の場所に移動したクライアント１０５がネットワーク上の異なるポートに接続することが可能である。これによって、ネットワーク接続の混乱が生じたり、場合により割り当てられたネットワーク識別子の変更が生じたりする場合がある。本発明を用いなければ、ネットワークトポロジの変更、ネットワーク接続の混乱、および／または割り当てられたネットワーク識別子の変更によって、ピアコンピューティングデバイス間のあらゆるセッションを再起動しなければならない場合がある。本願明細書に記述される方法およびシステムによって、本発明のリモートアクセスクライアント１２０は、クライアントに対するネットワーク接続を保持して、ネットワークトポロジおよびネットワーク識別子の変更の処理を含む、クライアント１０５のネットワーク接続を自動的に再確立する。クライアント１０５およびクライアント１０５上のあらゆるアプリケーションまたはセッションは、あたかもネットワーク接続の混乱またはネットワーク識別子の変更がなかったかのように、動作を継続することができる。さらに、クライアント１０５上のユーザーは、中断または変更が生じたことを認識しなくてよく、クライアント１０５は、当該の中断の通知を受信しなくてよい。
【０２１１】
更なる一側面では、図２Ｂ、３Ｂ、３Ｃ、４、５Ｂ、および６Ｂの例示的方法のような、本発明の技術のうちのいずれかを互いに１つ以上組み合わせて実施することができる。一実施態様では、ピアツーピアルーティング技術を、疑似確認応答および／またはＭＴＵ調整技術とともに実施することが可能である。これは、ＴＣＰの任意の信頼性機構による待ち時間を回避し、暗号化のオーバーヘッドによるフラグメンテーションを減じながら、より最適かつ直接的な経路を介してピアに接続するために、および安全なＳＳＬ／ＴＣＰ／ＩＰ接続を通じてＵＤＰを介してリアルタイムデータを通信するために、ＶｏＩＰのようなリアルタイムデータを通信するクライアントを提供する。加えて、この実施態様は、さらにクライアント側のアプリケーション認識の優先順位付け技術および／またはネットワークの混乱から保護する技術と組み合わせることが可能である。このように、安全なリアルタイムデータ通信は、ＶｏＩＰのようなリアルタイムエクスペリエンスの品質を向上させるために、クライアントの他のアプリケーションよりも高い優先順位でクライアントから送信することができる。ネットワークの混乱から保護する技術によって、ノートブックのソフト電話のようなＶｏＩＰ電話は、ネットワークのアクセスポイント間を移動して、自動的にセッションを継続することができるようになる。
【０２１２】
本発明の技術は、例えばＳＳＬ  ＶＰＮゲートウェイを通じたＶｏＩＰ通信でのような、ネットワーク通信の最適化に対して相互補完的である。このように、１）ピアツーピアルーティング技術、２）疑似確認応答技術、３）ペイロードシフティング技術、４）ＭＴＵ調整技術、５）クライアント側のアプリケーション認識技術、および５）本発明のネットワークの混乱から保護する技術、のそれぞれは、次の本発明の技術および最適化のうちの１つ以上とともに実施することが可能である：１）ピアツーピアルーティング技術、２）疑似確認応答技術、３）ペイロードシフティング技術、４）ＭＴＵ調整技術、５）クライアント側のアプリケーション認識技術、および／または５）ネットワークの混乱から保護する技術。
【０２１３】
本発明の更なる例示的な一例では、ＧｏＴｏＭｅｅｔｉｎｇ．ｃｏｍ、ＷｅｂＥｘ．ｃｏｍ、またはＬｉｖｅＭｅｅｔｉｎｇ．ｃｏｍのホストされたサービスのような、オンラインミーティングは、本発明の技術を１つ以上組み合わせて使用することが可能である。ホストサービスは、ミーティングプレゼンタの第１のコンピューティングデバイスと、ミーティング出席者の第２のコンピューティングデバイスとの間のピアツーピア通信を容易にするために、ゲートウェイ３４０、および例示的方法２６０の技術を使用することが可能である。ミーティングプレゼンタおよび出席者のコンピューティングデバイスは、ホストサービス、リモートアクセスクライアント１２０、またはそのいずれかの部分を介してダウンロードすることが可能である。ミーティングプレゼンタおよびミーティング出席者がピアツーピア接続を確立すると、ピアコンピューティングデバイスは、それらの通信を最適化するために、ＭＴＵ調整技術、クライアント側のアプリケーション認識技術、またはネットワークの混乱から保護する技術のような、本発明の最適化技術のうちのいずれかを使用することが可能である。ピアツーピアルーティングとともに、本発明の最適化技術は、オンラインミーティング、コラボレーション、またはデスクトップシェアリングの性能、効率、およびユーザーエクスペリエンスを向上させる。
【０２１４】
更なる側面および図２Ａを考慮して、例えば、本発明のリモートアクセスクライアント１２０は、ハートウェアまたはソフトウェアベースのＶｏＩＰ電話のような通信デバイス２１０ａおよび２１０ｂに、動的ホスト構成プロトコル（ＤＨＣＰ）のＩＰアドレス、または公的に可視的なＩＰアドレスを配信することができる。本発明のゲートウェイ３４０は、図２Ａに示されるクライアント１０５ｂのような、クライアントのパブリックＩＰアドレスの発見を容易にする。このように、本発明の技術によって、プロトコルは、機能を継続するために、プロトコルを通じてそれらのＩＰアドレスを通信できるようになる。
【０２１５】
多くの変更および改良は、本発明の精神と範囲から逸脱することなく、当業者によって行うことが可能である。したがって、図示した実施態様は、例示目的のためだけに示されたものであり、本発明を制限するものと捉えるべきではなく、以下の請求項によって定義されるものである、と明白に理解されたい。これらの請求項は、上述の図に示して説明したものと他の点において同じではなくても、字義通りに記述されたもの、また非現実的に異なる同等の要素を含むものとして読み取られるべきである。
【図面の簡単な説明】
【０２１６】
【図１Ａ】ネットワーク環境において、ゲートウェイを介して本発明のオペレーションを実施するための一実施態様を示すブロック図である。
【図１Ｂ】ピアツーピアネットワーク環境において、本発明のオペレーションを実施するための別の実施態様を示すブロック図である。
【図１Ｃ】ネットワーク通信のための本発明のリモートアクセスクライアントの一実施態様を示すブロック図である。
【図１Ｄ】および
【図１Ｅ】本発明の一実施態様の実施に有用な、コンピューティングデバイスの実施態様を示すブロック図である。
【図２Ａ】ピアツーピア通信経路を確立するために本発明の技術の一実施態様を実施するためのピアツーピアネットワーク環境の一実施態様を示すブロック図である。
【図２Ｂ】本発明のピアツーピア経路最適化技術を最適化するために行われるステップの一実施態様を示すフロー図である。
【図３Ａ】図１Ａ乃至１Ｃに示される例示的な環境のコンピューティングデバイスのうちのいずれかのネットワークスタックの一実施態様を示すブロック図である。
【図３Ｂ】不可逆プロトコルを介した送信のために構成した可逆プロトコルを介して通信するために、ネットワークパケットの受信の擬似確認応答を使用するために行われるステップの一実施態様を示すフロー図である。
【図３Ｃ】不可逆プロトコルを介した送信のために構成した可逆プロトコルを介して通信するために行われるステップの一実施態様を示すフロー図である。
【図４】最大送信単位パラメータを調整するために行われるステップの一実施態様を示すフロー図である。
【図５Ａ】クライアント側のアプリケーション認識の優先順位付け技術を提供するための、クライアントの環境を示すブロック図である。
【図５Ｂ】クライアント側のアプリケーション認識の優先順位付けを提供するために行われるステップの一実施態様を示すフロー図である。
【図６Ａ】デバイスをネットワークの混乱から保護するための装置の環境を示すブロック図である。
【図６Ｂ】デバイスをネットワークの混乱から保護するために行われるステップの一実施態様を示すフロー図である。
【図１Ａ】
2008507928.tif 000003
【図１Ｂ】
2008507928.tif 000004
【図１Ｃ】
2008507928.tif 000005
【図１Ｄ】
2008507928.tif 000006
【図１Ｅ】
2008507928.tif 000007
【図２Ａ】
2008507928.tif 000008
【図２Ｂ】
2008507928.tif 000009
【図３Ａ】
2008507928.tif 000010
【図３Ｂ】
2008507928.tif 000011
【図３Ｃ】
2008507928.tif 000012
【図４】
2008507928.tif 000013
【図５Ａ】
2008507928.tif 000014
【図５Ｂ】
2008507928.tif 000015
【図６Ａ】
2008507928.tif 000016
【図６Ｂ】
2008507928.tif 000017
【国際調査報告】
2008507928.tif 000018
2008507928.tif 000019
2008507928.tif 000020
2008507928.tif 000021
2008507928.tif 000022