(57)【要約】通信回路網の実効帯域幅を大きくするシステムと方法が「スーパー」トランスポート及び従来のＴＣＰ／ＩＰ通信ネットワークの上にキャッシング構造、例えば、インターネット、を上乗せすることによって与えられ、それは通信回路網において情報の伝送速度を大きくする。「スーパー」トランスポート及びキャッシング構造は、通信回路網において通信リンクによって分離された少なくとも二つのモジュールに追加されたソフトウェア又はハードウェア又は両方を含む。最終結果は、通信回路網のユーザが情報にアクセス又は情報を減少するためのかれらの時間を著しく減らし、通信がネットワーク、特に大きなネットワーク（例えばインターネット）が企業及び個人の両方によって商取引を遂行する効率的な手段になることである。
2004535713.tif 000002
【特許請求の範囲】
【請求項１】
データを第１のコンピュータシステムによってコミュニケーションネットワークを経て第２のコンピュータシステムへ転送するために圧縮する方法であり、データのセクションを前記第１のコンピュータシステムによって選択するステップ、  複数の圧縮アルゴリズムの各圧縮アルゴリズムのためのコスト値を前記第１のコンピュータの装置動作条件を用いて決定するステップ、最小コスト値に基づいて一つの圧縮アルゴリズムを前記複数から選択するステップ、前記データのセクションを前記選択された圧縮アルゴリズムを用いて圧縮するステップ、及び前記データの圧縮セクションを前記第２のコンピュータシステムに送るステップを備えるデータ圧縮方法。
【請求項２】
前記コスト値は、前記セクションを圧縮する時間に前記圧縮セクションを転送する時間を加えた和を前記第２のコンピュータに送るステップを含む請求項１の方法。
【請求項３】
前記第１のコンピュータのシステム動作条件が前記第１のコンピュータシステムの利用可能な処理サイクルを含む請求項１の方法。
【請求項４】
データを第１のコンピュータシステムによってコミュニケーションネットワークを経て第２のコンピュータシステムへ転送するために圧縮する方法であり、一つのデータのセクションを選択するステップ、前記データのセクションのデータ・フォーマットを決定するステップ、前記データのセクションを複数の圧縮アルゴリズムから前記データ・フォーマットに基づいて自動的に選択される一つの圧縮アルゴリズムを用いて圧縮するステップ、及び前記圧縮セクションを前記第２のコンピュータに送るステップを含むデータ圧縮方法。
【請求項５】
前記データ・フォーマットが画像、２進数、テキスト、フラッシュ、グラフィックス、ビデオ、オーディオ及び文書処理フォーマットからなる群からの選択を含む請求項４の方法。
【請求項６】
前記データのセクションを効率的なファイル書式で記憶するステップを更に含む請求項４の方法。
【請求項７】
データを第１のコンピュータシステムによって第２のコンピュータシステムへ通信リンクを経て転送するために圧縮する方法であり、データの一つのセクションを前記第１のコンピュータシステムによって選択するステップ、前記通信リンク上のデータ通信量が、伝送容量未満であるとき、前記セクションを圧縮する時間及び前記セクションのためのリンク待ち時間に基づいて関数の結果を算出するステップ、前記結果に従い、前記セクションを圧縮するステップ、及び前記圧縮セクションを前記第２のコンピュータに送るステップを含むデータ圧縮方法。
【請求項８】
前記関数が前記圧縮する時間引く前記リンク待ち時間及び前記結果が負の値を有するとき、前記セクションを圧縮するステップを含む請求項７の方法。
【請求項９】
第１のコンピュータシステムが通信リンクによって第２のコンピュータシステムへ接続されており、前記第１のコンピュータシステムによって共通の宛先を有する複数のパケットを纏め直す方法であって、各々がアプリケーション・データを含む前記複数のパケットを受けるステップ、前記複数のパケットから前記アプリケーション・データを含む情報を抽出するステップ、前記情報を含む新規なパケットを作るステップ、及び前記新規なパケットを前記第２のコンピュータシステムに送るステップを備える複数のパケットを纏め直す方法。
【請求項１０】
前記複数のパケットがＴＣＰ／ＩＰパケットを含む請求項９の方法。
【請求項１１】
前記新規なパケットが前記通信リンクの最大伝送ユニット（ＭＴＵ）を有する請求項９の方法。
【請求項１２】
各パケットのアプリケーション・データがアプリケーション・データユニットを含み、前記情報が、各パケットのアプリケーション・データユニットを含み、前記方法がパケット・アプリケーション・データへいくつかのＴＣＰ及びＩＰヘッダ情報を前記パケットから追加するステップを更に含む請求項９の方法。
【請求項１３】
前記情報は、ウェブサーバへの複数の関連したユーザＨＴＴＰ要求を含む請求項９の方法。
【請求項１４】
前記情報がシングル・ユーザＨＴＴＰ要求に応じて複数の関連したウェブサーバＨＴＴＰ応答を含む請求項９の方法。
【請求項１５】
第１のコンピュータシステムと第２のコンピュータシステムの間にＴＣＰ／ＩＰプロトコルを用いて半永久トランスポート制御プロトコル（ＴＣＰ）接続を設ける方法であり、前記第１のコンピュータシステムと前記第２のコンピュータシステムの間にＴＣＰ接続を確立するステップ，アプリケーション情報を前記第１のコンピュータシステムによって複数のソース・アドレスから受けるステップ、前記第２のアプリケーション情報を前記第１のコンピュータシステムによって前記ＴＣＰ接続を通じて送るステップ、及び前記ＴＣＰ接続を切るステップを含む半永久トランスポート制御プロトコル（ＴＣＰ）接続を設ける方法。
【請求項１６】
前記ＴＣＰ接続を切る前記ステップが予め定められた時間間隔の後で起こる請求項１５の方法。
【請求項１７】
前記ソース・アドレスは、ユーザ・アドレスまたはウェブ・サーバー・アドレスまたは両方を含む請求項１５の方法。
【請求項１８】
前記ソース・アドレスがＩＰアドレスを含む請求項１５の方法。
【請求項１９】
第１のコンピュータシステムを用いて複数の第２のコンピュータシステムから共通の宛先を有する複数の重複データ要求を簡素化する方法であり、前記複数の重複のデータ要求を前記第１のコンピュータシステムによって受けるステップ、
前記複数の第２のコンピュータシステムの返信先を記録するステップ、前記複数の重複のデータ要求からの共通のデータを含み、前記第１のコンピュータシステムをソース・アドレスとする統合データ要求を作るステップ、及び前記統合データ要求を送るステップを含む複数の重複データ要求を簡素化する方法。
【請求項２０】
前記統合データ要求を前記共通の宛先で前記統合データ要求に応答するデータを生成するホスト・システムによって受けるステップ、前記生成されたデータを前記第１のコンピュータシステムに送るステップ、前記返信先を用いて、前記生成されたデータをコピーするステップ、及び前記コピーを前記複数の第２のコンピュータシステムに送るステップを更に含む請求項１９の方法。
【請求項２１】
公衆通信網によって接合された複数のコンピュータによって複数の仮想私設ネットワークを設ける方法であって、
前記複数の仮想私設ネットワークの第１の仮想私設ネットワークを前記複数のコンピュータの第１のコンピュータと前記複数のコンピュータの第２のコンピュータの間に前記第１のコンピュータのアドレス及び前記第２のコンピュータのアドレスを含む集中許可テーブルを用いて確立するステップ、及び前記複数の仮想私設ネットワークの第２の仮想私設ネットワークを前記第１のコンピュータと前記複数のコンピュータの第３のコンピュータの間に前記第３のコンピュータのアドレスをさらに含む集中許可テーブルを用いて確立するステップを含む複数の仮想私設ネットワークを与える方法。
【請求項２２】
前記集中許可テーブルは前記第１のコンピュータが前記第２のコンピュータ及び前記第３のコンピュータと通信する許可を有することを示す請求項２１の方法。
【請求項２３】
第１のコンピュータシステムが通信リンクによって第２のコンピュータシステムへ接続されており、前記第１のコンピュータシステムによって共通の宛先を有する複数のパケットを纏め直す方法であって、各々がアプリケーション・データを含む前記複数のパケットを受けるステップ、前記複数のパケットから前記アプリケーション・データを含む情報を抽出するステップ、前記情報を含む通信リンク上のデータ通信量に基づいて決定される多数の新規なパケットを作るステップ、及び  前記多数の新規なパケットを前記第２のコンピュータシステムに送るステップを備える複数のパケットを纏め直す方法。
【請求項２４】
標準化通信プロトコルを有する通信ネットワークの情報の流れを大きくするシステムであって、第１のアプリケーション情報及び第１の制御情報を有するパケットと前記標準化通信プロトコルを用いて送る第１のモジュール、前記パケットを受けて、前記標準化通信プロトコルを用いて第２のアプリケーション情報及び第２の制御情報を有するスーパー・パケットを送る第２のモジュール、前記標準化通信プロトコルを用いて前記スーパー・パケットを受ける第３のモジュールを備え、前記第２のアプリケーション情報は、前記第１のアプリケーション情報及びいくつかの前記第１の制御情報から構成されている通信ネットワークの情報の流れを大きくするシステム。
【請求項２５】
前記標準化通信プロトコルがＴＣＰ／ＩＰである請求項２４のシステム。
【請求項２６】
リクエスタ・コンピュータシステムが遠隔データ記憶装置から中間コンピュータシステムを経て情報を検索するための時間を短縮する方法であって、前記データ記憶装置からデータを検索するために要求を前記中間コンピュータシステムによって受けるステップ、第１のデータ項目を前記中間コンピュータシステムによって前記データ記憶装置から検索するステップ、及び前記第１のデータ項目を前記データ記憶装置から第２のデータ項目を検索しながら、前記中間コンピュータシステムが並行して前記リクエスタ・コンピュータシステムに送るステップを含む情報を検索するための時間を短縮する方法。
【請求項２７】
前記データ記憶装置が、ウェブサーバの一部である請求項２６のシステム。
【請求項２８】
通信ネットワークの複数のスーパー・モジュールの二つのスーパー・モジュールの間のネットワーク・セグメントの性能を大きくするシステムであって、複数のＩＰパケットを受けて、前記複数のＩＰパケットから組み入れられたアプリケーション・データを含む変更データ・パケットを送る前記複数のスーパー・モジュールの中の第１のスーパー・モジュール、及び前記変更データ・パケットを受ける前記複数のスーパー・モジュールの中の第２のスーパー・モジュールを備え、前記第２のスーパー・モジュールは、前記変更データ・パケットを処理する追加アプリケーション層を有するＴＣＰ／ＩＰ通信プロトコル・スタックを含む二つのスーパー・モジュールの間のネットワーク・セグメントの性能を大きくするシステム。
【請求項２９】
前記第２のスーパー・モジュールが層システムの一部であり、前記段になったシステムは、前記第２のスーパー・モジュールに接続された前記複数のスーパー・モジュールの複数のより小さいレベルのスーパー・モジュールを含む請求項２８のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にいえば通信分野に関し、そして、特にコンピュータ・ネットワーク上の情報の効率的な伝達に関するに関する。
【発明の背景】
【０００２】
インターネットは、政府及び大学の間で調査ネットワークから企業及び個人の両方による個人的及び商業的取引を行う手段まで過去の数十年にわたってその使用範囲において著しく増大した。インターネットは当初の設計が体系化されていなかったので、故障の場合には通信が終わりになる確率が高かった。情報を転送する方法は、郵便を通して手紙を送ることと同様の概念に基づいている。メッセージは、多数のＴＣＰ／ＩＰパケット（すなわち手紙）に分割されて、受取人に送られる。手紙の様に、各パケットは受取人の所に着くために異なる経路をとることができる。多経路アプローチを介する多数の小パケットは、ユーザが、例えば、多くのウェブサイトに比較的安価にアクセスできるようにするが、それは、ユーザとウェブサイトの間のポイント・ツー・ポイント接続よりかなり遅い。
【０００３】
図１は、従来技術のインターネットへのユーザ接続を示しているブロック図である。一般に、ユーザ１１０がインターネット・サービス・プロバイダー（ＩＳＰ）によって従来のやり方で操作されるポイント・オブ・プレゼンス（ＰｏＰ）１１２を経てインターネットに接続する。ＰｏＰは、ＩＳＰのバックボーン・ネットワーク１１４（例えばＩＳＰ１）に接続されている。多数のＩＳＰバックボーン・ネットワーク（例えばＩＳＰ１及びＩＳＰ２）は、ネットワーク・アクセス・ポイント（例えばＮＡＰ１７０）によってつなぎ合わされてインターネット「クラウド（雲）」１６０を形成する。
【０００４】
より詳しくいえば、パソコン（ＰＣ）１２０における単一ユーザには、例えば直接の加入者回線（ＤＳＬ）モデム１２２、ＴＶケーブル・モデム１２４、標準ダイヤルアップ・モデム１２６又は固定ワイヤレスＰＣ又は携帯電話上のワイヤレス・トランシーバ１２８などのＰｏＰ１１２に接続するいくつかの選択がある。用語パソコン又はＰＣは、プロセッサ及びメモリを有するどんな装置をも記載するために本願明細書において用いられて、従来のデスクトップＰＣに限られない。ＰｏＰ１１２には、各タイプのモデム（又はトランシーバ）が、データをユーザ１１０から受信／へ送信するための対応するアクセス装置があるだろう。ＤＳＬモデム１２２の場合、ＰｏＰ１１２は、そのアクセス装置としてデジタル加入者回線アクセス・マルチプレクサ（ＤＳＬＡＭ）を有する。テーブル・モデム１２４の場合、ＰｏＰ１１２は、そのアクセス装置としてケーブル・モデム成端装置（ＣＴＭＳ）ヘッドエンドを有する。ＤＳＬ及びケーブル・モデム接続は数百キロビット／秒（Ｋｂｐｓ）を可能にし、データがダイヤルアップ遠隔アクセスサーバ（ＲＡＳ）１３４によってＰｏＰ１１２で受けられる標準ダイヤルアップ・モデム１２６よりかなり速い。ワイヤレス・トランシーバ１２８は、携帯情報端末（ＰＤＡ）又は携帯電話の一部であってもよく、ＰｏＰ１１２においてワイヤレ・トランシーバ１３６（例えば基地局）に接続される。
【０００５】
企業ユーザ（又はホームオフィスをもつ人）がローカルエリア・ネットワーク（ＬＡＮ）（例えばイーサネット・リンクによってＬＡＮサーバ１４４に接続されたＰＣ１４０及び１４２）を備えことができる。企業ユーザは、ＰｏＰ１１２にＴ１（１．５４４Ｍｂｐｓ）、部分Ｔ１接続又は高速接続を持つことができる。例えば、ＬＡＮサーバ１４４からのデータは、ルーター（図示せず）を経てデジタル接続装置、例えば、チャネル・サービス・ユニット／データ・サービス・ユニット（ＣＳＵ／ＤＳＵ）１４６に送られ、デジタル接続装置は、次に、デジタルデータをＴ１（又は部分Ｔ１）ラインを経てＰｏＰ１１２にあるＣＳＵ／ＤＳＵに送る。
【０００６】
ＰｏＰ１１２は、ＤＳＬＡＭ１３０、ＣＴＭＳヘッドエンド１３２、ＲＡＳ  １３４、ワイヤレス・トランシーバ１３６又はＣＳＵ／ＤＳＵ１５０が接続されるＩＳＰサーバ１５２を含む。ＩＳＰサーバ１５２は、ユーザ・サービス（例えば電子メール、ユースネット（Ｕｓｅｎｅｔ）又はドメイン・ネーム・サービス（ＤＮＳ）を与える。あるいは、ＤＳＬＡＭ１３０、ＣＴＭＳヘッドエンド  １３２、ＲＡＳ１３４、ワイヤレス・トランシーバ１３６又はＣＳＵ／ＤＳＵ  １５０は、ＩＳＰサーバ１５２をバイパスして、直接ルーター１５４（点線）に接続される。サーバ１５２は、ＰｏＰ１１２を例えば、ルーター１６２、１６４、１６６及び１６８を有するＩＳＰ１のバックボーンに接続するルーター１５４に接続されている。ＩＳＰ１のバックボーンは、例えば、ＮＡＰ１７０を経て、例えばルーター1７２、１７４及び１７６を有するもう一つのＩＳＰのバックボーン（ＩＳＰ２）に接続されている。ＩＳＰ２は、競争しているユーザにサービス（例えば電子メール及びユーザ・ウェブ・ホスティング）を提供するＩＳＰ２サーバ１８０を有する。インターネット「クラウド」１６０に接続されているのは、ウェブサーバ１８２及び１８４であって、それらがユーザ１１０にオンライン・コンテンツを与える。
【０００７】
インターネットは、企業及び個人の両方のための商取引を行うための基本的機能性を与えるが、例えば、ウェブサーバと企業又は個人ユーザの間の情報の転送におけるかなりの時間遅れは、重要な問題である。例えば、ＰＣ１２０のユーザが、ウェブサーバ１８２にあるウェブサイトから情報を望む。データがウェブサーバ１８２からユーザＰＣ１２０まで戻るために多くの「ホップ」がある。また、情報がパケットの形で「郵送で」戻されるので、パケットは、普通異なる経路を経て戻る。これらの異なる経路は、他のユーザパケットと共有され、いくつかの経路は遅いことがある。それゆえに、ウェブサーバ１８２とユーザ１２０の間の全てのリンクに充分な容量があったとしても、かなりの時間遅れがある。しかし、隘路（すなわち、そこでは通信量が容量を上回る）もあるので、なお一層の遅延がある。
【０００８】
二つの主要隘路は、最後及び最後から２番目のマイル（通信回線）である。ラストマイルは、ＰｏＰ１１２からユーザ１１０に至るものである。これは、ユーザ１２０が５６Ｋｂｐｓの最大速度でダイヤルアップ・モデムを用いているとき、容易に明白である。約５１２ＫｂｐｓのＤＳＬモデムでさえ、グラフィックスをダウンロードすることは、不愉快なほど遅くなることがある。最後から２番目のマイルは、ＩＳＰ間にある。ＰｏＰ１１２をもつＩＳＰは、それのバックボーン１１４を経て領域内／全国的／全地球的受信可能範囲を得るためにより高レベルのＩＳＰ（図示せず）に接続することができる。より高水準ＩＳＰへのバンド幅の増加がローカルＩＳＰの経費を大きくするので、例えばＰｏＰ１１２を有するローカルＩＳＰは、代わりにユーザ１１０に利用できる帯域の量を減らしてもよい。効果は、ウェブサーバ１８２とＰＣ１２０の間のリンク容量より多くの通信量があるということであり、したがってかなりの遅延問題がある。今日の速いペースの世界において、この問題は、商用伝達手段としてインターネットを使用することを非常に妨げている。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、通信回線網（例えばインターネット）を通じて情報の転送をする効率個々に又は纏めて、情報のためのユーザの待ち時間が非常に短縮されるように改善することを求めるニーズがある。
【００１０】
本発明は、「スーパー」輸送及び通信回路網における情報の伝送速度を大きくする従来のＴＣＰ／ＩＰ通信回路網（例えばインターネット）を超えるキャッシング構造を上乗せすることによって通信回路網の有効帯域幅を大きくするシステムと方法を与える。
【課題を解決するための手段】
【００１１】
「スーパー」トランスポート及びキャッシング構造は、通信回路網内の通信リンクによって分離された少なくとも二つのモジュールに追加されたソフトウェア又はハードウェア又は両方を含む。任意の二つの「スーパー」モジュールの間で、情報の速くて能率的な転送を可能にする通信リンクが確立され、そこでは情報の転送が転送されている未処理ビットの数と同じでなく、必要なデータ・ビットだけを含んで、例えば、オーバヘッド制御ビット又は冗長なデータ・ビットを除外する。通信リンクには固定容量があるので、情報ビットを大きくして非情報ビットを減少させることが非情報ビットを有するリンクの容量の割当量を減らす。それゆえ、まず非情報ビットの一部が転送されるまで、情報ビットの一部が待つ必要がない。したがって、情報の転送遅延は、非常に減少する。
【００１２】
「スーパー」トランスポート及びキャッシング構造の最終結果、したがって、情報伝達の増速は、通信回路網のユーザが情報へのアクセス及び／又は情報の検索のためのかれらの時間を減らされ、通信回路網（特に大きなネットワーク、例えばインターネット）は企業と個人の両方による商取引を行う効率的な手段になる
【００１３】
本発明の一実施例が第２のコンピュータへ通信回路網を経て転送するためにデータを第１のコンピュータシステムによって圧縮する方法を提供する。最初に、データのセクションが第１のコンピュータシステムによって選択される。次に、第１のコンピュータのシステムオペレーティング動作条件を用いている複数の圧縮アルゴリズムの各圧縮アルゴリズムに対するコスト値が決定される。圧縮アルゴリズムは、最小コスト値に基づいて複数から選ばれる。データのセクションは、選択された圧縮アルゴリズムを用いて圧縮されて第２のコンピュータシステムに送られる。
【００１４】
本発明のもう一つの実施例は、第２のコンピュータへ通信回路網を経て転送するためにデータを第１のコンピュータシステムによって圧縮する方法を提供する。
前記方法は、第１のコンピュータシステムによってデータのセクションを選択するステップ、前記セクションのデータ・フォーマットを決定するステップ、複数の圧縮アルゴリズムからデータ・フォーマットに基づいて自動的に選択される圧縮アルゴリズムを用いている前記セクションを圧縮するステップ、及び圧縮されたセクションを第２のコンピュータに送るステップを含む。
【００１５】
本発明のなおもう一つの実施例は、第２のコンピュータへコミュニケーションリンクを経て転送するためにデータを第１のコンピュータシステムによって圧縮する方法を提供する。前記方法は、データのセクションを第１のコンピュータシステムによって選択するステップ、通信リンク上のデータ通信量が伝送容量未満であるとき、前記セクションを圧縮するための時間及び前記セクションのためのリンク待ち時間に基づいて関数の結果を算出するステップ、前記結果に従って、セクションを圧縮するステップ、及び前記圧縮されたセクションを第２のコンピュータに送るステップを含む。
【００１６】
本発明の一実施態様は、第１のコンピュータシステムによって、共通の宛先を有する複数のパケットを纏め直すための方法を提供し、第１のコンピュータシステムは、通信リンクによって第２のコンピュータシステムへ接続されている。前記方法は、各々がアプリケーションデータを含む複数のパケットを受けるステップ、アプリケーションデータを含んでいる情報を複数のパケットから抽出するステップ、前記情報を含んでいる新規なパケットをつくるステップ及び前記新規なパケットを第２のコンピュータシステムに送るステップを含む。
【００１７】
本発明のもう一つの実施態様は、半永続的なトランスポート・コントロール。プロトコル（ＴＣＰ）を第１のコンピュータシステムと第２のコンピュータシステムの間にＴＣＰ／ＩＰプロトコルを用いて与える方法を提供する。前記方法は、第１のコンピュータシステムと第２のコンピュータシステムの間にＴＣＰ接続を確立するステップ、アプリケーション情報を第１のコンピュータシステムによって複数のソース・アドレスから受けるステップ、第２のアプリケーション情報を第１のコンピュータシステムによってＴＣＰ接続を通じて送るステップ、及びＴＣＰ接続を切るステップを含む。
【００１８】
本発明のもう一つの実施態様は、共通の宛先を有する複数の重複データ要求を複数の第２のコンピュータシステムから取り除くために第１のコンピュータシステムを用いる方法を提供する。前記方法は、複数の重複データ要求を第１のコンピュータシステムによって受けるステップ、前記複数の第２のコンピュータシステムの返信アドレスを記録するステップ、ソース・アドレスとして第１のコンピュータシステムを有する前記複数の重複データ要求から共通のデータを含んでいる串刺しデータ要求をつくるステップ、及び串刺しデータ要求を送るステップ含む。
【００１９】
本発明のもう一つの実施態様が、公衆通信回路網によって接ぎ合わされた複数のコンピュータによって複数の仮想プライベート・ネットワーク（ＶｉｒｔｕａｌＰｒｉｖａｔｅ  Ｎｅｔｗｏｒｋｓ）を設けるための方法を備える。
前記方法は、複数のコンピュータの中の第１のコンピュータと複数のコンピュータの中の第２のコンピュータの間に複数の仮想プライベート・ネットワークの中の第１の仮想プライベート・ネットワークを第１のコンピュータのアドレス及び第２のコンピュータのアドレスを有する集中パーミッション・テーブルを用いて確立するステップ及び第１のコンピュータと複数のコンピュータの第３のコンピュータの間に第３のコンピュータのアドレスを更に有する集中パーミッション・テーブルを用いて複数の仮想プライベート・ネットワークの中の第２の仮想プライベート・ネットワークを確立するステップ含む。
【００２０】
本発明のさらにもう一つの実施態様は、第１のコンピュータシステムによって共通の宛先を有する複数のパケットを纏め直すための方法を含み、前記第１のコンピュータシステムは、通信リンクによって第２のコンピュータシステムへ接続されている。前記方法は、各々がアプリケーション・データを含む複数のパケットを受けるステップ、複数のパケットからアプリケーション・データを含んでいる情報を抽出するステップ、情報を含んでいる数が通信リンク上のデータ通信量に基づいて決定される多数の新規なパケットをつくるステップ及び第２のコンピュータシステムに前記多数の新規なパケットを送るステップ含む。
【００２１】
本発明のもう一つの実施態様は、標準化通信プロトコルを有する通信ンネットワークの情報の流量を大きくするための装置含む。前記装置は、第１のアプリケーション情報と第１の制御情報を有するパケットを標準化通信プロトコルを用いて送る第１のモジュールと、パケットを受けてスーパー・パケットを標準化通信プロトコルを用いて送る第２のモジュール及び標準化された通信プロトコルを用いているスーパー・パケットを受けるための第３のモジュールを備え、前記スーパー・パケットは、第２のアプリケーション情報と第２の制御情報を有し、前記第２のアプリケーション情報は、第１のアプリケーション情報と若干の第１の制御情報を含む。
【００２２】
本発明の更なる実施態様が、リクエスター・コンピュータシステムが遠隔データ記憶装置から情報を中間コンピュータシステムを介して検索するための時間を減らすための方法で、前記方法は、データ記憶装置からデータを検索するために中間コンピュータシステムによって要求を受けるステップ、中間コンピュータシステムによって第１のデータ項目をデータ記憶装置から検索するステップ、及び、中間コンピュータシステムが第２のデータ項目をデータ記憶から検索しながら、並行してリクエスタ・コンピュータシステムに第１のデータ項目を送るステップを含む。
【００２３】
本発明の一実施態様が、通信回路網内の複数のスーパー・モジュールの二つのスーパー・モジュールの間のネットワーク・セグメントの性能を大きくするための装置を備えている。前記装置は、複数のＩＰパケットを受けて、変更データ・パケットを送った複数のスーパー・モジュールの中の第１のスーパー・モジュール及び変更データ・パケットを受ける複数のスーパー・モジュールの中の第２のスーパー・モジュールを備え、前記データ・パケットは、前記複数ＩＰパケットから結合されたアプリケーション・データを含み、第２のスーパー・モジュールは、変更データ・パケットを処理するための追加のアプリケーション層を有するＴＣＰ／ＩＰ通信プロトコル・スタックを有する。
【００２４】
本発明のこれら及びその他の実施態様、特徴、態様及び利点は、以下の説明、添付の請求の範囲及び添付図面に関してより十分によく理解されるようになる。
【発明を実施するための最良の形態】
【００２５】
以下の説明において、多数の具体的な詳細が本発明の特定の実施態様のより完全な説明を与えるために記載される。しかし、本発明が以下の全ての具体的な詳細なしで実施できることは、当業者にとって明らかである。他のいくつかの場合において、周知の機構は、本発明を不明瞭にしないために詳述しなかった。
【００２６】
個人及び企業が有効な商用伝達手段としてインターネットを用いるためには、ユーザが情報を要求して受け取るための時間は、今日生じている典型的な時間に比べて著しく減らされなければならない。本発明は、インターネット基盤の諸部分に重ねられることができる「スーパー」装置及びネットワークの情報の流れを大きくするための技術の両方を提供し、それらは、別々に又は組合せて、例えば、ウェブサイト又は他のユーザからの情報に対するユーザの待ち時間を著しく減らす。
【００２７】
図２は、図１の簡略化されているが、拡張されたブロック図であって本発明を説明するのを助けるために用いられる。適用できる場合、図１の同じ符号は図２においても用いられている。モデム２１０は、図１のＤＳＬモデム１２２、ケーブルモデム１２４、ダイヤルアップ・モデム１２６及びワイヤレス・トランシーバ１２８を備えている。同様に、アクセス装置２２０には、図１の対応するＤＳＬＡＭ１３０、ＣＭＴＳヘッドエンド１３２、ＲＡＳ１３４及びワイヤレス・トランシーバ１３６がある。デジタル接続装置２１２と２２２には、ＣＳＵ／ＤＳＵ装置１４６と１５０があり、追加でサテライト、ＩＳＤＮ又はＡＴＭ接続装置がある。図２は、ＬＡＮがデジタル接続装置２１２の他にＰｏＰ１１２に接続するためのもう一つのオプションを例示するために、ＬＡＮサーバ１４４とモデム２１０の間に追加の接続を有する。図２に示されるコンピュータとネットワーク装置の大部分は、標準化されたＴＣＰ／ＩＰを用いて通信する。
【００２８】
図３は、ＴＣＰ／ＩＰプロトコル・スタック及び各層のための関連のデータ・ユニットを示す。ＴＣＰ／ＩＰプロトコル・スタック３１０は、アプリケーション層３１２、トランスポート層３１４、インターネット層３１６及びネットワーク・アクセス層３１８を含む。アプリケーション層はアプリケーション又はユーザー・データ３２０（データの１ブロック又はユニット）を受ける。そして、我々はそれをアプリケーション・データ・ユニットと言う。例えば、ウェブページのためのユーザ要求は、一つのアプリケーション・データ・ユニットであろう。多数のアプリケーション・レベル・プロトコルがＴＣＰ／ＩＰにあり、電子メールのために用いられる簡易メール転送プロトコル（ＳＭＴＰ）とポスト・オフィス・プロトコル（ＰＯＰ）、ワールド・ワイド・ウェブ（ＷＷＷ）のために用いられるハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）及びファイル・トランスファー・プロトコル（ＦＴＰ）を含む。
【００２９】
トランスポート層３１４は、トランスミッション・コントロール・プロトコル（ＴＣＰ）及びユーザー・ダイアグラム・プロトコル（ＵＤＰ）を含む。ＴＣＰは、ソース及び宛先の間に信頼性の高い仮想回路を与える接続オリエンテッド・プロトコルである。ＴＣＰは、それを用いてバイトの流れを、ＩＰパッケージ送出サービスが信頼できない場合であっても、それらが重複又はデータ損失なしで送られた順序で配信するアプリケーションに保証を与える。トランスポート層はデータ３２０にＴＣＰヘッダ３２２を経て制御情報を追加し、これはＴＣＰデータ・ユニットといわれる。ＵＤＰはパケット配信を保証しないので、ＵＤＰを用いるアプリケーションは配信を確認するそれら独自の手段を備えなければならない。
【００３０】
インターネット層３１６は、ＴＣＰ／ＩＰの相互ネットワーキングを強調するために名づけられている。これは、インターネット・プロトコル（ＩＰ）パケットを送受信する無接続層である。ＩＰパケットがＩＰパケットの元のソース・アドレス及び最後の宛先アドレスを有するが、パケットがその最後の宛先に達する場合、特定の分岐点にあるＩＰ層は全く何もわからないで次の分岐点にＩＰパケットを送る。ＩＰパケットには、ＴＣＰデータ・ユニット（ＴＣＰヘッダ３２２及びデータ３２０）に追加されたＩＰヘッダ３２４がある。
【００３１】
ネットワーク・アクセス層３１８は、ＩＰパケットの物理的転送を取扱う最下層である。ネットワーク・アクセス層３１８は、それ自身の標準を定めるのではなく、既存のデータ・リンク標準及び物理層標準をグループに一纏めにしている。この層は、ネットワーク・ハードウェアとデバイス・ドライバとを定める。ヘッダ３２６及びトレーラ（図示せず）が通信ラインを通じてＩＰパケットの物理的転送を可能にするためにＩＰパケットに追加されている。
【００３２】
図２のＴＣＰ／ＩＰプロトコルの使用の例が、ウェブ・ページをウェブ・サーバ１８２から要求しているＰＣ１４０のユーザである。彼のブラウザを介するユーザは、アプリケーション層３１２にあるウェブ・ページ（すなわちアプリケーション・データ・ユニット３２０（図３））に対するユーザ要求をつくる。ＴＣＰ／ＩＰスタック３１０は、各ＴＣＰデータ・ユニットが添付されたＴＣＰヘッダ３２２を有するアプリケーション・データユニット３２０の一部を有する一つ以上のＴＣＰデータ・ユニットをつくる。ＰＣ１４０にあるトランスポート層３１４は、ＴＣＰを有するピア・ツー・ピア接続（すなわちバーチャル回路）をウェブサーバ１８２にあるトランスポート層３１４で設定する。各ＴＣＰデータ・ユニットは、一つ以上のＩＰパケットに分けられる。ＩＰパケットは、ＬＡＮサーバー１４４へ送られ、次いでＰｏＰサーバ１５２に送られ、そこでそれらは、それからＰｏＰルーター1５４を経てインターネット１５４へ送り出される。ＩＰパケットは、インターネット１６０上の多経路を通って進んでウェブサーバ１８２に到達する。ウェブサーバ１８２にあるトランスポート層３１４は、次にＩＰパケットからＴＣＰデータユニットを再組立てし、ＴＣＰデータ・ユニットをアプリケーション層３１２に通してユーザ要求を再組立てする。ウェブ・ページを得るユーザ要求は、それから実行される。ユーザへウェブ・ページを送るために、同じＴＣＰ仮想回路は、ウェブ・サーバ１８２及びＰＣ  １４０のトランスポート層の間に用いられることができる。ウェブ・ページはそれからＴＣＰデータ・ユニットにバラバラにされる。そして、それは順番にＩＰパケットにバラバラにされて、ＰＣ１４０に、インターネット１６０、ＰｏＰルーター1５４、ＰｏＰサーバー１５２、ＬＡＮサーバー１４４を経て送られる。
【００３３】
従来の相互作用の上記例においてユーザとウェブ・サーバーの間に起こるいくつかの問題がある。第１に、イーサネット・フレームにおける最大伝送ユニット（ＭＴＵ）（すなわちデータの最大量）は、１５００バイトである。しかし、ＴＣＰ／ＩＰ内のデータ３２０のための最大値は、約６４，０００バイトである。例えば、１６Ｍｂｐｓのトークンリングが約１８，０００バイトのＭＴＵを有し、モデムを用いるダイヤルアップ接続が約５７６バイトのＭＴＵを有する。これはＬＡＮサーバー１４４を去るＭＴＵが１５００バイトより大きい場合であっても、ＰＣ１４０とウェブサーバ１８２の間のバーチャル回路がユーザとウェブサーバーの間にＭＴＵの中の最小のものを有するＭＴＵでパケットを一般に用いることを意味する、すなわち、送出送還される多くの小さなＩＰパケットがある。第２に、一つの要求及び一つの応答だけでなく、ブラウザ要求の全シリーズとユーザがウェブ・サイトを用いているとき起こるウェブ・サーバー応答がある。例えば、グラフィックを有するウェブ・ページに対するユーザ要求がブラウザによってグラフィックに対するいくつかの要求が後に続く多数の要求（ハイパーテキスト・マークアップ言語（ＨＴＭＬ）に対して１要求）に分割される。第３に、圧縮がファイルのサイズをかなり減らすことができるという事実にも拘わらず、テキストとグラフィックスは通常非圧縮フォーマットで送られる。したがって、これら及びその他の問題は、従来のＴＣＰ／ＩＰネットワークにウェブ・サーバーからユーザまでデータを移すときにかなりの遅れを生じさせる。
【００３４】
図４は、ブラウザと本発明の実施態様のウェブサーバーの間に通信経路のブロック図である。ブラウザ５１２を用いているユーザがウェブ・サーバー１８２からウェブ・ページ５１４を要請するとき、ブラウザ５１２とウェブ・サーバー１８２の間の従来の交換は上述した。本発明の実施態様は、ブラウザ５１２とウェブ・サーバー１８２の間でデータを交換する代わりの超高速経路を与える複数のスーパー・モジュール（スーパー・ユーザー５４０、スーパー・アプライアンス５３２、スーパー・セントラル・オフィス（ＣＯ）サーバー５３４、スーパーＣＯコンセントレータ  ５３６及びスーパー・ホスト５３８を含む）をつくる。ウェブ・ページ５１４を求めるユーザ要求は、ＰＣ１４０で実行するブラウザ５１２によってやはりＰＣ１４０で作動しているスーパー・ユーザー・ソフトウェア５３０に送られる。スーパー・ユーザー５３０は、次にＬＡＮサーバー１４４で作動している（又はそれ自体のサーバーで実行している別の実施例にある）スーパー・アプライアンス・ソフトウェア５３２にユーザ要求を送る。スーパー・アプライアンス５３２はその次にスーパーＣＯサーバー５３４にユーザ要求を送り、それはその要求をスーパーＣＯコンセントレータ５３６に送る。スーパーＣＯサーバー５３４とスーパーＣＯコンセントレータ５３６は、独立型サーバーであってもよいし、又はそれがＰｏＰサーバー１５２で作動しているソフトウェアであってもよい。スーパーＣＯコンセントレータ５３６は、インターネット１６０を経てユーザ要求をそれ自身のサーバーを持つことがあるスーパー・ホスト５３８（又は別の実施例においてはスーパー・ホスト５３８がウェブ・サーバー１８２で作動しているソフトウェアである）に送る。ユーザ要求はスーパー・ホスト５４８からウェブ・サーバー１８２へ進み、それはウェブ・ページ１５４をウェブ・サーバー１８２（ウェブ・サーバー１８２は、サーバーのウェブ・ファーム及び多ウェブ・サイトを含むことがある）で作動しているウェブ・サイトから検索し、ウェブ・ページ５１４は、次にブラウザ５１２へスーパー・ホスト５３８，スーパーＣＯコンセントレータ５３６、スーパーＣＯサーバー５３４  スーパー・アプライアンス５３２、及びスーパー・ユーザー５３０を経て逆に進む。
【００３５】
他の実施態様において、一つ以上のスーパー・モジュールが例えば、スーパー・アプライアンス５３２が欠けていることがある。欠損スーパー・アプライアンス５３２の場合、スーパーＣＯサーバー５３４は、情報をＬＡＮサーバー１４４を介してスーパー・ユーザー５３０と交換する。もう一つの例は、スーパー・ホスト５４８がなかった場合、ウェブ・サーバー１８２は、情報をスーパーＣＯコンセントレータ５３６と交換することである。したがって、スーパー・モジュールが欠損している場合、対応する正常モジュール（例えばＰＣ１４０、ＬＡＮサーバー１４４、ＰｏＰサーバー１５０、ＰｏＰルーター1５４及びウェブ・サーバー１８２）が代わりに用いられる。全て又はいくつかのスーパー・モジュールを用いることができ、少なくとも二つの異なるスーパー・モジュールの間に少なくとも一つの通信リンクがある限り、リンク全体の情報流れは非常に改善される。さらに、より多くのスーパー・モジュールをネットワークを通じてスーパー層のデータの塊を拡張するために展開できる。
【００３６】
上述のユーザー−ツー−サーバー・アプリケーションに加えて、インターネット又はネットワーク構造内のスーパー・モジュールをそれらのネットワーク・セグメントを通じて性能を大きくするために用いることができる。そのような実施態様において、ネットワーク構造内の多数のスーパー・モジュールの間で転送された全てのデータが最適化される。例えば、ネットワークの異なる部分のスーパーＣＯサーバー・モジュールの間の通信が高価な又は帯域幅を限定されたリンク（例えば大陸横断回線又は衛星通信）の効率を改善するために特に魅力的である。この実施態様はまた、スーパー・モジュールを備える任意の二つのネットワーク点の間の通信の性能を改良し、コストを減らす。どのスーパー・モジュールの相互運用性もまた、積重ね式アプローチに論理的又は物理的な領域に対する通信を最適化可能にする。例えば、いくつかの構内スーパーＣＯサーバーは、段々に積み上げて領域スーパー・モジュールにすることができ、それは次に積み重ねて全国的スーパー・モジュールになる。この積重ね式アプローチは、スーパー・モジュール（アプリケーション又は元のソースに関係なく）の間の、全てのネットワーク通信量のためのネットワーク全体にわたって、スーパー・アプリケーション層のデータの塊を拡張する（すなわち、任意の数のスーパー・モジュール・ソース又はい任意の数の正常モジュール・ソースからのデータの組合せがありうる）。
【００３７】
図５は一つの従来のＴＣＰ／ＩＰ及び本発明の実施態様の二つの変更ＴＣＰ／ＩＰのプロトコル・スタックである。アプリケーション層３１２、トランスポート層３１４、インターネット層３１６及びネットワーク・アクセス層３１８は、図３のＴＣＰ／ＩＰプロトコル・スタック３１０にあるのと同じ層で、ノーマル・モジュール４６０（例えばＰＣ１４０）に対するものである。アプリケーション層４２０と４４０、「スーパー」アプリケーション層４２２と４４２、トランスポート層４２４と４４４、インターネット層４２６と４４６及びネットワーク・アクセス層４２８と４４８は、本実施態様の変更ＴＣＰ／ＩＰプロトコル・スタックであり、スーパー・モジュール４６２と４６４（例えばスーパー・アプライアンス  ５３２及びスーパー・ユーザー５３０）に対するものである。ノーマル・モジュール４６０は、通信リンク４１８を経てスーパー・モジュール４６２に接続され、スーパー・モジュール４６２は通信リンク４５０を経てスーパー・モジュール４６４に接続されている。
【００３８】
一つ以上のノーマル・モジュール４６０からＩＰパケットを受けると、スーパー・モジュール４６２は、全てのアプリケーション層データ及びＩＰパケットのＩＰとＴＣＰのヘッダーからスーパー・アプリケーション層４２２へ適用できるデータを抽出する。標準モジュールからの及びアプリケーション層４２０からのアプリケーション層データは、任意のプロトコル（例えばＨＴＴＰ１．０、ＨＴＴＰ１．１、ＦＴＰ、ＰＯＰ、ＳＭＴＰ、その他）のものであってよい。スーパー・アプリケーション層はアプリケーション・データ及び適当なＴＣＰ層とＩＰ層のデータを一つの大きなアプリケーション層データユニットに纏める。スーパー・モジュール４６２と４６４の間には、正常ＴＣＰ／ＩＰ運搬機構を用いる。これは、スーパー・モジュール４６２とスーパー・モジュール４６４の間に一つ以上の中間標準ノードがあるとき、ノーマル・モジュール４６０におけると同様のＴＣＰ／ＩＰスタックが一つの大きなアプリケーション層データユニットを転送するため用いられることを意味する。例えば、スーパー・モジュール４６４がアプリケーション・パケットを通常モジュールに送らなければならないとき、一つの大きなアプリケーション層データユニットは、スーパー・アプリケーション層４４２によってばらされ、ＴＣＰ／ＩＰパケットが構成しなおされて通常ノードに送られる。したがって、各々がオーバーヘッド・アドレス情報を有するデータの事実上多くの半充填パッケージを一つの大きなパッケージに組み替えることができる。長距離（例えば海外）通信の場合、コンテナ輸送によるコスト削減と類似している。
【００３９】
図６は、本発明の実施態様の図２の従来の装置に挿入されたスーパー・モジュールのブロック図である。装置が同じ又は類似している図２におけるのと同じ符号を図６において用いている。スーパー・ユーザー５４０が、モデム２１０を通してＰｏＰサーバー１５２へアクセス装置２２０を介して接続されている。スーパー・ユーザー５３０、スーパー・ユーザー５４２及びスーパー・アプライアンス５３２を有するローカルエリア・ネットワークは、モデム２１０又はデジタル接続装置２１２に接続されている。デジタル接続装置２１２は、ＰｏＰサーバー１５２へデジタル接続装置２２２によって接続されている。スーパー・アプライアンス５３２は、ＬＡＮサーバー１４４で実行するソフトウェアを含む。サーバー１５２はスイッチ４２０を経てルーター1５４に接続され、そのスイッチはスーパーＣＯサーバー５３４とスーパーＣＯコンセントレータ５３６にパケット通信量を迂回させる。ルーター1５４は、インターネット・クラウド１６０へ接続されている。インターネット１６０から、通信量はウェブ・サーバー１８２に接続されたスーパー・ホスト５３８に又はウェブ・サーバー１８４に接続されたスーパー・ホスト５５０にまたＩＳＰサーバー１８０に接続されたスーパー・ホスト５５２へ行くことができる。
【スーパー・システム構成要素】
【００４０】
図６のスーパー装置の構成要素（スーパー・ユーザー５４０、スーパー・アプライアンス５３２、スーパーＣＯサーバー５３４、スーパーＣＯコンセントレータ５３６及びスーパー・ホスト５３８を含む）の各々の一実施例を以下に説明する。
【００４１】
スーパー・ユーザー５３０は、ユーザのＰＣ（例えばＰＣ１４０）にあるソフトウェアを含む。データを求める全てのブラウザ要求がスーパー・ユーザー５３０から供給されるので、ブラウザ（例えばマイクロソフトのインタネット・エクスプローラ）がスーパー・ユーザー５３０に代わって設定される。さらに、ブラウザを経た全てのユーザ要求は、スーパー・ユーザー５３０に送られる。それゆえ、ブラウザは、スーパー・ユーザーによってネットワークの残りから隔離される。、スーパー・ユーザーは、ユーザがユーザのＰＣでローカル・キャッシュにおいて要求した全てのデータを取り入れるので、ユーザが再びデータを要求するとき、それをローカル・キャッシュ（利用できるならば）から局所的に検索する。
取り入れられるデータが予め定められたファイル・サイズを超える場合、スーパー・ユーザーは、ローカル・キャッシュ内の全てのデータを分析し、が取り入れるそれからと削除を上回る場合、最も使われそうでないデータを削除する。例えば、従来の最近用いられたことが最も少ないアルゴリズムを古いデータを捨てるために用いることができる。スーパー・ユーザー５４０のソフトウェア機能の一部は、以下の通りである。
【００４２】
１．キャッシング：ブラウザがローカル・キャッシュにあるデータを要求し、データがキャッシュ寿命要件に合えば、そのデータはローカル・キャッシュから供給される。さもなければ、データは最も近いスーパー・モジュール・キャッシュ（例えばスーパー・アプライアンス５３２又はスーパーＣＯサーバー５３４）スーパーＣＯコンセントレータ５３６又はスーパー・ホスト５３８）から検索され、そこでは更新されたデータは、利用できるか又は任意のスーパー・キャッシュから利用できなければ、ウェブ・サーバーから利用できる。各データ・エレメントはキャッシュ寿命を有する、すなわち、それがリフレッシュされることが必要になる前に、どれだけの期間それをキャッシュから用いることができるかである。
【００４３】
２．キャッシュ・リフレッシュ：スーパー・ユーザーＰＣが働いていない（インターネットからデータを能動的に検索していない）とき、スーパー・ユーザーは、ローカル・キャッシュを点検して、それのキャッシュ寿命に達しているデータを自動的にリフレッシュする。人工知能（ＡＩ）又は他の技術を用いるスーパー・ユーザーは、それがユーザが要求しそうであると決定したものに基づいてリフレッシュすることの優先順位を決める。例えば、スーパー・ユーザーは、ユーザがウェブ・ページにアクセス頻度の回数を保存できる。カウントが多ければユーザが将来そのウェブ・ページをもっと多く要求しそうなことを示すだろうし、スーパー・ユーザーは自動的にそのページをリフレッシュするであろう。
【００４４】
３．プリフェッチング：ＡＩ又は他の技術を用いることによって、スーパー・ユーザーは、アイドル・タイムの間、ユーザによって必要とされる確率の高いウェブ・ページをプリフェッチする（すなわち、ユーザがまだ求めなかったウェブ・ページを検索する）。例えば、ユーザがカタログ・サイト上のいくつかのページを調べている場合、ユーザが同じカテゴリーのサイト上の他のページを調べる確率が高い。スーパー・ユーザーはこれらのページをプリフェッチするだろう。プリフェッチングは、ユーザがローカル・キャッシュからデータを得るという確率を大きくする。
【００４５】
４．クーリエ・パケット（後述する）は纏められて、纏められたデータはスーパー・アプライアンス又はスーパーＣＯサーバーに送られる前にスーパー・ユーザーによって圧縮される。クーリエ・パケットはばらされると、ばらされたデータはブラウザに送られる前にスーパー・ユーザーによって解凍される。
【００４６】
スーパー・アプライアンス５３２は、ＬＡＮサーバー１４４で実行するソフトウェアを含む。スーパー・アプライアンス５３２によって実行されたいくつかの機能は、ファイア・ウォール・セキュリティ、大域的キャッシング、チーム化、スマートなホスティング及び電子メール管理を含む。スーパー・アプライアンスソフトウェアによって実行される更なる機能は、以下を含む。
【００４７】
１．スーパー・アプライアンスがスーパーＣＯサーバーに添付される場合、それらの間に送られる全てのデータは圧縮されて、クーリエ・パケットに纏められ、さもなければ、標準インターネット要求が用いられ、応答がスーパー・ユーザーに送られる前に、応答はクーリエ・パケットに纏められる。
【００４８】
２．スーパー・アプライアンスはまた、ユーザによって頻繁に用いられるウェブサイトを自動的に複製して保持する。
【００４９】
３．スーパー・アプライアンスがスーパーＣＯサーバーに添付される場合、それは、スーパーＣＯサーバーから変化を知らせられるときだけ、ウェブ・サイトのそれのコピーを更新する。スーパー・アプライアンスがスーパー・  ＣＯ  サーバーに添付されない場合、それは、アイドル・タイムの間及び／又は周期的に予め定められた間隔の間にウェブサイトの更新の有無を検査する。
【００５０】
４．スーパー・ユーザーがスーパー・アプライアンスに添付される場合、全てのデータ応答はスーパー・ユーザーに圧縮フォーマットで送られる。正規ユーザがスーパー・アプライアンスに添付される場合、データ応答はスーパー・アプライアンスにおいて解凍されてユーザに送られる。スーパー・ユーザーがウェブ・サイトを維持している場合、ウェブ・ページがスーパー・アプライアンスで更新されるときはいつでも、スーパー・ユーザーが変更を要求するように、通知がスーパー・ユーザーに送られる。
【００５１】
５．スーパー・ユーザーはまた、スーパー・アプライアンスにユーザのＰＣモニタ密度に関する情報を知らせて、ローカルエリア・ネットワークを通じて送られるグラフィックスに調整を行うことができるようにする。グラフィックスを表示することができないモニタに、高密度のグラフィックスを送ることは、ネットワーク・リソースの浪費である。スーパー・アプライアンスのソフトウェアは、データを送る前にグラフィックス密度を調整する。
【００５２】
６．二つ以上のスーパー・ユーザーが同じデータを要求する場合、スーパー・アプライアンスは要求を爆縮させて、次のスーパー・モジュール（例えばスーパーＣＯサーバー）に、一つだけの要求を送る。もう一つのスーパー・モジュールがスーパー・アプライアンスとウェブ・サイトの間にない場合、要求はなお爆縮されて、標準のＴＣＰ／ＩＰ要求が作られる。爆縮された要求に対する応答が受けられるとき、データはスーパー・アプライアンスによって爆増されて、データは適当なスーパー・ユーザーに送られる。
【００５３】
スーパー・アプライアンスに保持されるウェブサイトが多ければ多いほど、ウェブ・ページのためのアクセス速度は、ローカルエリア・ネットワーク速度に大きく近づく。スーパー・ユーザーに保存されたウェブ・ページが多ければ多いほど、ウェブ・アクセス速度は、ハードディスク・アクセス速度に大きく接近する。スーパー・アプライアンス及びスーパー・ユーザーでコピー及び保存できるウェブ・ページが多ければ多いほど、ラストマイルは、応答時間の間の隘路になり方が少なくなる。
【００５４】
スーパーＣＯサーバー５３４は、インターネット・バックボーン１１４とユーザ１１０の間の橋である。スーパーＣＯサーバー５３４の一つの目的は、ユーザとインターネットの間の通信量を最小化することである。スーパーＣＯサーバーは、これをスーパー・ユーザー又は通常ユーザによってスーパーＣＯサーバーを介してアクセスされたウェブサイトをコピーすることによって達成する。スーパーＣＯサーバー上に処理されるウェブ・サイトが多ければ多いほど、ネットワークは、ネットワーク全体に渡るデータの移動を減らすことによってより多く最適化される。スーパーＣＯサーバーに処理されるウェブ・サイトがスーパーＣＯコンセントレータ５３６に記憶されたウェブサイトから来る場合、ウェブ・ページが変わったスーパーＣＯコンセントレータ５３６によって通知されるときはいつでも、スーパーＣＯサーバー５３４は更新されたウェブ・ページを要求する。スーパーＣＯコンセントレータ５３６からのウェブ・ページは、圧縮されて纏め直されたフォーマットで記憶される。スーパーＣＯサーバー上にホストされるウェブサイトがスーパーＣＯコンセントレータに記憶されない場合、スーパーＣＯサーバーはホスティング・ウェブ・サーバーにあるウェブサイトの変化を予め定められた間隔で調べる。スーパーＣＯサーバーは、スーパー・アプライアンス５３２キャッシュごとに処理されるウェブサイトのログを保存する。あるスーパー・アプライアンス・キャッシュ上に存在するウェブサイトに変化が起こるとき、そのスーパー・アプライアンスに対して変化が起こったということ及びそのスーパー・アプライアンスが変更されたウェブ・ページの更新コピーを要求すべきであるこを知らせる通知が送られる。データが非スーパーＣＯコンセントレータ・サイトから受けられるとき、それは圧縮され、纏められてスーパーＣＯサーバーに記憶される。スーパーＣＯサーバーは、それの要求からそれのユーザによってアクセスされているウェブサイトを決定し、スーパーＣＯサーバー５３４キャッシュでコピーして保持すべきウェブ・サイトがどれかを決める。スーパーＣＯサーバーは、また、用いられていないサイトを削除するだろう。ウェブサイトが記憶され保存されていない場合、ウェブ・ページは、それが再び要求される場合、それを大域的キャッシュから供給できるように、独立した大域的キャッシュに保存される。正しいバランスが大域的キャッシュとウェブ・ホスティングの間に保持される必要がある。大域的キャッシュとスーパーＣＯサーバーは、一つのキャッシュとして実現して別々に管理すること又は二つの独立したキャッシュとして実現することができる。あるウェブ・ページがスーパー・アプライアンスから要求される場合、ウェブ・ページは超圧縮して纏め直されたフォーマットで送られ、さもなければ、ウェブ・ページは解凍されて要求しているユーザに送られる。それがネイティブ形式でユーザに送られるように、ユーザに最も近いスーパー・モジュールはどの纏め直されたフォーマットをもばらしてデータを解凍する。ユーザに最も近いスーパー・モジュールは、また、非圧縮でばらばらのフォーマットで情報を取り入れる。用いられる最適化は、可変データ（通常テキスト）に加えられる圧縮の量とウェブ・ページ上の可変データの量に関係する。インターネット上で用いられるリッチ・データ・フォーマットが多ければ多いほど、より多くの最適化が達成される。フラッシュ・ソフトウェア、ファイル、ジャバ・プログラム、ジャバ・スクリプトその他は、全てスーパーＣＯサーバーに記憶される。
【００５５】
スーパーＣＯサーバーキャッシュによって満たされないスーパー・アプライアンスからのデータ要求が要求されるＵＲＬ（ウェブサイト）を手入れする責任のあるスーパーＣＯコンセントレータ５３６に送られる。その要求は、最適化計画って纏められ圧縮されて爆縮される。一つの実施例において、データ爆縮の第１のレベルは、スーパーＣＯサーバーで起こる。別の実施例においては、爆縮はスーパー・アプライアンスによってなされる。領域的に用いるように向けられている重複使用特性を要求のあり次第爆縮し、応答のあり次第爆増することができるように、スーパーＣＯサーバーはＩＳＰ地理学によって編成される。スーパーＣＯサーバーのキャッシュのデータによって応答されることができない全ての要求と爆縮された要求は、スーパーＣＯコンセントレータに通される。
【００５６】
スーパーＣＯコンセントレータ５３６は、ウェブ・サイト（ＵＲＬのもの）によって編成される。これは、ユーザが必要とするウェブサイト・データがＣＯコンセントレータのキャッシュにある確率を大きくする。また、要求を爆縮させることができ、ネットワーク通信量を減らすことができる確率を大きくする。各スーパーＣＯコンセントレータは、キャッシングとスーパー・ホスト（例えば５３８）及びその他の非スーパー・ホスト・ウェブサイトとインタフェースで接続する役割を果たす。非スーパー・ホスト・ウェブサイトの場合、スーパーＣＯコンセントレータ５３６は、遭遇する第１のスーパー・モジュールであり、最初の纏め直し、最初の圧縮、最後の爆縮、最初の爆増、全てのグラフィックスの最適化圧縮フォーマットへの変換（ＰＮＧ又は有標圧縮アルゴリズム）及びスーパー・キャッシングの最初のレベルが発生する。これはまた、全てのチェックとリフレッシュが他のスーパー・モジュールのために起こる場合である。ウェブサイトからのデータがリフレッシュされて更新されるとき、スーパーＣＯサーバーは、全てのキャッシュを更新してリフレッシュすることができるように通知される。
【００５７】
ウェブ・サーバーは、インターネットに付属する一つ以上のウェブ・サイトを処理する。スーパー・ホスト（すなわちスーパー・ホスト５３８）は、スーパー  ＣＯコンセントレータ（例えば５３６）からなされた要求に答える。要求がウェブ・サーバーで処理される任意のウェブ・サイトのダウンロードのために作られるたびに、スーパー・ホスト５３８は、ウェブ・ページをウェブ・サーバーから検索して、要求元スーパーＣＯコンセントレータにその要求を送る前に、コンテンツを圧縮して纏める。これは、ウェブ輸送の効率を有効な圧縮率によるとともに全ての要求されたウェブ・ページ・データに対して単一データブロックを送ることによってよくなる。情報の各部分は、分析されて、データの特定の形式のために最もよく機能を果たす技術を用いて圧縮される。各スーパーＣＯコンセントレータ要求が受けられると、スーパー・ホストはスーパーＣＯコンセントレータのＩＰアドレスを記録する。スーパー・ホストは、ウェブ・サーバーに含まれるウェブ・サイトを点検して歴史的にウェブ・サイトからデータを要求したいすべてのスーパーＣＯコンセントレータにすべての変更ウェブ・ページの通知を送る。
これは、ウェブ・サイトのバージョンをリフレッシュすることを必要とし、スーパーＣＯコンセントレータがスーパーＣＯコンセントレータのキャッシュ内のウェブ・ページのそれのバージョンから直接にウェブ・ページに対するユーザ要求サービスをすることができるようにすることによってウェブ通信量を最小化するときをスーパーＣＯコンセントレータが分かるようにする。ウェブ・ページのスーパーＣＯコンセントレータのバージョンがリフレッシュされるために必要とする唯一の時は、それが変化した時である。これは、ウェブ・ホスティング・サイトからＩＳＰサイトへの最小化された通信量を可能にする。各ウェブサイトでデータにアクセスする多くのＩＳＰサイトがある。これは、ウェブサイトをインターネットの外側縁へ動かして、圧縮し纏めてインターネットの内部機構にすることにおけるステップである。ウェブサイトをインターネットの外側縁に動かす挑戦は、データが最新のものであることを確めることであり、スーパー・モジュール・キャッシュを連結することはこれを保証する。
【圧縮と効率的ファイルフォーマット】
【００５８】
データ圧縮が通信に特に有用であるのは、それによって装置が少ないビットで同じ量の情報を送ることが可能になるからである。種々のデータ圧縮技術があるが、ほんの少しだけしか標準化されていない。さらに、ファイル圧縮フォーマット（例えばＡＲＣ、ＧＺＩＰ及びＺＩＰ）がある。
【００５９】
本発明の一態様は、できるだけデータのソースに近くデータを圧縮して、その圧縮データを解凍することが必要である点へネットワークに沿って通す。圧縮データはソースと宛先の間の各スーパー・モジュールに圧縮フォーマットの形で蓄積される。必ずしも同じ圧縮、フォーマット化ではないが。これによって圧縮がネットワークの負荷ダイナミックスとともに変化できる。従来のブラウザ技術は解凍されたデータを必要とするので、ウェブサイトにあるデータは圧縮されて、ブラウザに手渡される直前に解凍されるべきである。圧縮のためのかなりのニーズは、帯域幅の限界がある場合それのためのラストマイルである。それゆえ、圧縮がスーパーＣＯサーバ  ５３４とスーパー・アプライアンス５３２又はスーパー・ユーザー５４０の間で起こることが重要である。
【００６０】
図７は本発明の一実施態様のブラウザとウェブ・サーバーの間の圧縮データ・トンネルを示す。ブラウザ５１２は非圧縮データ６１０を用い、ウェブ・サーバー１８２は非圧縮データ６１４を用いる。非圧縮データ６１０はスーパー・ユーザー５３０によって圧縮され、圧縮データ６１２はスーパー・アプライアンス５３２を介してスーパーＣＯサーバー５３４‐スーパーＣＯコンセントレータ５３６‐スーパー・ホスト５３８に送られ、スーパー・ホスト５３８がデータを解凍してウェブサーバー１８２によって用いられる非圧縮データ６１４にする。同様に、ウェブサーバー１８２からのウェブ・ページ・データは、スーパー・ホスト  ５３８によって圧縮されて、圧縮データ６１２としてスーパー・ユーザー５３０に送られ、そこでデータがブラウザ５１２用の非圧縮データ６１０に解凍される。
したがって、データは、ウェブサーバー１８２からブラウザ５１２への転送及びその逆の間できるだけ長い間圧縮フォーマットの形で保たれる。
【００６１】
本発明のもう一つの実施態様は、異なるデータ・フォーマットのための異なる圧縮アルゴリズムを用い、そこではデータ・フォーマットが一つのデータのための特定レイアウトになっている。一般に、データ・フォーマットが画像又は音声パターン又は両方を記載するビットマップｌと０の文字列）、バイナリ（実行可能なコンピュータ・プログラム、）テキスト形式（普通各バイト値が文字にマップされている）、及び数字データ・フォーマット（表計算ソフト及びその他のデータベース・プログラムによって用いられる）を含む。データ・フォーマットは、ベクトル・グラフィック・アニメーションのためのフラッシュ、マルチメディアのアプリケーションのための音声情報とモーションビデオ情報、及びレイアウト制御文字を埋め込んだワープロ文書を更に含むことがある。データ・フォーマットに基づいて圧縮アルゴリズムを選択することによって、全てのデータ・フォーマットに対して一般的なアルゴリズムを用いるよりよい結果（例えばより小さく圧縮したファイル・サイズ）を達成できる。例えば、グラフィックス又はバイナリ・ファイルに用いるよりずっと積極的な圧縮技術をテキスト・データに用いることができる。
【００６２】
図８は、本発明の実施態様の送られたデータのデータ・フォーマットに基づく圧縮アルゴリズムを示す。ステップ７１０において、送られるべきデータのセクション（例えばアプリケーション・データユニット、ファイル、ファイルの一部）がセンダー・スーパー・モジュールによって送られるように選択された。そのセクション内のデータのデータ・フォーマットは、センダー・スーパー・モジュール（ステップ７１２）によって決定される。ステップ７１４において、そのセクション内のデータは、それが単一フォーマットか又は混合フォーマット（例えばマイクロソフト（商標）アウトルック電子メール・メッセージにあるテキストと添付グラフィックスは混合フォーマットであろう）のものであるかどうかを決定するために調べられる。データ・フォーマットが混合であれば、ステップ７１６で、例えば、そのセクションはサブセクションに分解され、（例えばマイクロソフト（商標）アウトルック電子メール・メッセージはテキスト・セクションとグラフィックス・セクションに分解される）、プロセスはステップ７１２で各サブ−セクションで繰り返される。セクションのデータが単一のフォーマットのものであれば、ステップ７１８で、データ・フォーマットに基づく圧縮アルゴリズムが選択される。例えばテキスト・セクションに対しては、例えば、ＧＺＩＰを用いることができ、グラフィックス・セクションに対しては、例えば、ウェーブレット（さざなみ）圧縮を用いることができる。データが圧縮されていることを保証するための初期設定値圧縮アルゴリズムがある。ステップ７２０で、前記セクションのデータは、選択された圧縮アルゴリズムを用いて圧縮され、各データセクションは圧縮が行われた特定の時に特に用いられたアルゴリズムでタグを付けられる。テップ７２２で、圧縮セクションは、解凍アルゴリズムを有する受信者スーパー・モジュールに送られる。
【００６３】
圧縮による伝送待ち時間を減らすこととプロセッサがデータのセクションを圧縮するためにかかる時間の間に兼ね合いがある。目的は、データに対するユーザ待ち時間を最少にすることである。それゆえ、時々、データのセクションを圧縮して送り、それから解凍したデータのセクションを送るためにより多くの時間をとることがあり、従って、データのセクションは、圧縮されてはならない。異なる圧縮量と圧縮時間を有する異なる圧縮アルゴリズムを選択するときに、利用できる処理サイクル又は利用できる一時的な記憶スペースのような装置動作条件もまた考慮される必要がある。各スーパー・モジュールは、ネットワークについての作動情報に基づいて圧縮アルゴリズムを選択する。この作動情報は、クーリエ・パケットのデータとともにスーパー・モジュール間に通される。例えば、スーパー・モジュールが使用中の場合、すなわち、わずかな利用可能な処理サイクルだけしかなければ、より計算機的に集中的でない圧縮が用いられるべきである、すなわち、事実上、圧縮時間は大きくなる。これによって圧縮がネットワークのロード動特性とともに変化できる。
【００６４】
図９は、本発明のもう一つの実施態様のデータが圧縮されるべきか否かを決めるフローチャートである。ステップ８１０で、通信リンクを通じて第２のスーパー・モジュールに第１のスーパー・モジュールによって送られるべきデータのセクションが選択される。ステップ８１２で、第１のスーパー・モジュールは、通信リンクがフル、すなわちリンク容量一杯になっているかどうかを決める。ステップ８１４でリンクが容量一杯であれば、そのセクションが汎用アルゴリズム（例えばランレングス又はハフマン（Ｈｕｆｆｍａｎ）符号化）を用いて又は図７のフローチャートを用いて圧縮される（ステップ８２０）。リンクが容量一杯でなければ、ステップ８１６で、データ・セクションを圧縮する時間は、圧縮が起こるためにリンク待ち時間（すなわちデータのセクションを第１のスーパー・モジュールから第２のスーパー・モジュールまで転送するのにかかる時間）より大きくてはならない（ステップ８２０）。データを圧縮するためにかかる時間がデータを転送するための時間より長ければ、圧縮が行われない（ステップ８１８）。ステップ８２２で、データは、ステップ８２０からの圧縮形式又はステップ８１８からの非圧縮形式のどちらかで送られる。
【００６５】
図１０は、本発明のさらにもう一つの実施態様のもう一つの圧縮プロセスのためのフローチャートを示す。ステップ８４０で、送られるべきデータのセクションが選択される。ステップ８４２で、一群の圧縮アルゴリズム内の各圧縮アルゴリズムごとにデータのセクションを圧縮するためのコスト（システム動作条件を考慮に入れて）が決められる。そのグループの一つの圧縮アルゴリズムが最少のコストで選択される（ステップ８４６）。例えば、一つのコスト計算式は、データのセクションを圧縮する時間とデータの圧縮セクションに対するリンク待ち時間の和である。ここで、圧縮する時間は、圧縮時に利用可能な処理サイクルの平均数の関数である（システム動作条件の一例）。コスト（すなわち和）が各圧縮アルゴリズムごとにこのコスト計算式を用いて計算され、最少の和を有する圧縮アルゴリズムが選択される。ステップ８４８で、セクション内のデータは、選択された圧縮アルゴリズムを用いて圧縮され、ステップ８５０で、圧縮セクションが送られる。
【００６６】
何をどのように圧縮すべきか（すなわち最高の圧縮アルゴリズム）を調べるほかに、データがどこにあるかも重要である。一つの実施例において、グラフィカルでバイナリのウェブ・ページ・データ、ジャバ・スクリプト、フラッシュ・プログラミング、及び一般に変化しないものと圧縮可能性の少ないその他のデータは、スーパー・ユーザー又はスーパー・アプライアンス・サイトに保存される。ウェブ・ページに含まれる可変データ（すなわち通常はテキスト・データ、これは通常は変化するが、非常に圧縮しやすい）は、ラストマイルのインターネット側にあるウェブサーバー又は何らかの中間スーパー・モジュールから更新することができる。
【００６７】
圧縮のほかに、効果的なフォーマット（すなわちより小さいファイル・サイズを与えるフォーマット）に蓄積されたデータを有することは、圧縮と同様な効果を有する。本発明の一つの実施態様において、非効率的なデータ・フォーマットに遭遇する第１のスーパー・モジュールは、それを効果的なフォーマットに変換する。これは、システムの残り全体にわたって変換データの伝送とキャッシングを改良する。一例は、全てのグラフィック・データのビットマップ及びＧＩＦフォーマットからＪＰＥＧフォーマットへの変換である。これは、ビットマップに対しては１０：１の改善で、ＧＩＦに対しては５：１の改善を与える。ウェブ・ページ・グラフィックスの約９０％がＧＩＦフォーマットで記憶されるので、ＪＰＥＧへの変換は、ウェブ・ページ・グラフィックスのための情報伝達と保存を非常に改良する。
【リパッキング（纏め直し）】
【００６８】
典型的ウェブ・ページは、今日、ハイパーテキスト・マークアップ・ランゲージ（ＨＴＭＬ）文書、及び多くの埋め込み画像を含む。ブラウザのための従来の挙動は、ベースＨＴＭＬドキュメントを取り込むことであり、そして次に、ベースＨＴＭＬドキュメントの受信後、ブラウザは、多くの埋め込みオブジェクト（これは普通同じウェブサーバーにある）の２回目の取り込みをする。各埋め込みオブジェクト（すなわちアプリケーション・データユニット）は、ＴＣＰデータユニットに入れられ、各ＴＣＰデータユニットは、一つ以上のＩＰパケットに分けられる。例えば、一つの大きなＴＣＰ／ＩＰパケットではなく多くの埋め込みオブジェクトのための多くのＴＣＰ／ＩＰパケットを送ることは、ネットワークが制御データを送る際に必要であるより多くの時間を費やすことを意味し、換言すれば、コントロール・データ／時間に対するアプリケーション・データ／時間の比率は、大き過ぎる。多くの埋め込みオブジェクトを一つの大きなアプリケーション・データユニットに結合して、次に、一つ（又は少なくとも最小限の数）の大きなＴＣＰデータユニットをつくることがより効率的である。一つの大きなＴＣＰデータユニットの場合、このセンダー・スーパー・モジュールと次のレシーバー・スーパー・モジュールの間のリンクのための最大伝送ユニット（ＭＴＵ）は、ＩＰパケットのために用いられる。センダー・スーパー・モジュールは、送られるＩＰパケットの数を各ＩＰパケットを実際的であるのと同程度ＭＴＵに近づけようとすることによって最小にしようとする。スーパー・モジュール・センダーとスーパー・モジュール・レシーバーの間の各リンクについては、ＭＴＵはそのリンクのために決定され、ＩＰパケットのサイズは変ることがある。ユーザとウェブサーバーの間の通信リンクの全てのＭＴＵの中の最小公分母ＭＴＵが通常用いられている従来の技術とは異なり、本実施例においては、各リンクのＭＴＵが用いられる。
【００６９】
本発明の一実施例において、アプリケーション・データユニット（例えばユーザ要求とウェブサーバー応答）は、必要に応じて各スーパー・モジュール（例えばスーパー・ユーザー、スーパー・アプライアンス、スーパーＣＯサーバー、スーパーＣＯコンセントレータ及びスーパー・ホスト）においてより大きな（又は多数のより小さい）変更アプリケーション・データユニットに纏め直される（又はばらされる）。例えば、二つのＩＰパケットを一つのＩＰパケットに結合しよう。これは、「クーリエ」パケットの１例である。第１のＩＰパケットは、第１のＩＰヘッダ、第１のＴＣＰヘッダ及び第１のアプリケーション・データユニットを有する。第２のＩＰパケットは、第２のＩＰヘッダ、第２のＴＣＰヘッダ及び第２のアプリケーション・データユニットを有する。第１のアプリケーション・データユニット及び第１の疑似ヘッダを有する第１の変更アプリケーション・データユニットは、第１のＩＰヘッダ及び第１のＴＣＰヘッダ（例えばソース・アドレス、ソースと宛先ポート及び第１のＩＰパケットを再構成するに必要なその他の制御情報）から作られる。第２のアプリケーション・データユニット及び第２の疑似ヘッダを有する第２の変更アプリケーション・データユニットは、第２のＩＰヘッダ及び第２のＴＣＰヘッダ（例えばソース・アドレス、ソースと宛先ポート及び第２のＩＰパケットを再構成するに必要なその他の制御情報）から作られる。第２の変更アプリケーション・データユニットに連結された第１の変更アプリケーション・データユニットを有する複合アプリケーション・データユニットが作られる。新しいＴＣＰヘッダ及びＩＰヘッダは複合アプリケーション・データユニットに追加され、クーリエ・パケットが形成される。したがって、必要な制御情報が複合アプリケーション・データユニットに埋め込まれ、ＴＣＰ／ＩＰプロトコルはスーパー・モジュール・センダーとスーパー・モジュール・レシーバの間で複合アプリケーション・データユニットを動かすために用いられる。レシーバがスーパー・モジュールでないとき、複合アプリケーション・データユニットはばらされ、第１のＩＰパケットと第２のＩＰパケットは、改造されてスーパー・モジュール・センダーによって正規レシーバに送られる。
【００７０】
図１１は、本発明の実施態様のスーパー・ユーザーにある複数のアプリケーション・データユニットを纏め直すためのフローチャートである。ステップ９１０で、スーパー・ユーザーが同じ宛先を有する複数のアプリケーション・データユニットを一つのアプリケーション・データユニットに結合する。例えば、ウェブサーバーに対する多数のユーザ要求は、結合される。ステップ９１２で、一つのＴＣＰデータユニット（又は最小数のＴＣＰデータユニット）が一つのアプリケーション・データユニットから形成される。ステップ９１４で、一つのＩＰパケット（又は最小数のＩＰパケット）すなわち、クーリエ・パケット、が作られ、そこでは、各ＩＰパケットは、リンクのためのバイトのＭＴＵ数にできるだけ近くなるように、又はフォワーディング・タイマーＴが期限切れになって終うまで満たされる。ステップ９１６で、クーリエ・パケットは、宛先経路にある次のスーパー・モジュール（例えばスーパー・アプライアンス又はスーパーＣＯサーバー）に送られる。
【００７１】
図１２は、本発明のもう一つの実施態様のスーパー・  モジュールにある複数の受信ＩＰパケットを纏め直すためのフローチャートである。ステップ９２０で、スーパー・モジュールは、同じ宛先を有する複数のＩＰパケットを受ける。ステップ９２２で、アプリケーション情報は、複数のＩＰパケットから抽出される。ステップ９２４で、抽出されたアプリケーションは、纏め直されたパケット（すなわちクーリエ・パケット）を形成するために用いられる。ステップ９２６で纏め直されたパケット共通の宛先への経路にある次のスーパー・モジュールへ行く途中で送られる。
【００７２】
図１３は、図１２のステップ９２２と９２４をさらに詳細に説明する。ステップ９３２で、アプリケーション・データユニットは、ＩＰパケットから抽出される。アプリケーション・データユニットごとに、関連があるＴＣＰヘッダとＩＰヘッダ制御情報を調べる。そして、適用できる制御情報（例えばソース、ソースと宛先ポート及びデータ長）は、変更アプリケーション・データユニット（ステップ９３４）を形成するために対応するアプリケーション・データユニットに追加される。ステップ９３６で、変更アプリケーション・データユニットは、一つのＴＣＰデータユニット（又はＴＣＰデータユニットの最小限の数）を形成すために集計される。ステップ９３８で、新しい纏め直されたＩＰパケットは、センダーとレシーバのスーパー・モジュール間のリンクのＭＭを用いてＴＣＰデータユニットから形成される。
【００７３】
ステップ９３６で一つの大きなＴＣＰデータユニット又は多数の小さいＴＣＰデータユニットを形成するかどうかについての決定は、センダー・スーパー・モジュールを出てゆくリンク上の通信量ロードに従って動的に決められる。例えば、リンクが容量限度に近い場合、多数の小さいＴＣＰデータユニット、従って、小さいＩＰパケットを送る方が、待機しなければならないだろう一つ（又は若干）の大きなＩＰパケットを送るより効率的である。
【００７４】
図１４は、本発明の一態様のスーパー・ユーザーからスーパー・ホストへのクーリエ・パケットの例を示す。スーパー・ユーザー５３０は、ユーザ要求１０２０と１０２２（すなわちアプリケーション・データユニットＤ１とＤ２）を図１１のフローチャートに従ってクーリエ・パケット１０２４に組み入れる。スーパー・ユーザー１０１０は、ＩＰパケット１０２６にあるそれのユーザ要求Ｄ３を有し、スーパー・ユーザー１０１２は、ＩＰパケット１０２８にあるユーザ要求Ｄ５を有する。これらの単一スーパー・ユーザーの要求の両方ともがクーリエ・パケットに纏め直されて、適当なスーパー・アプライアンスに送られる。第１のスーパー・アプライアンス５３２で、クーリエ・パケット１０２４とＩＰパケット１０２６が図１２のフローチャートに従って受けられて纏め直され、より大きなアプライアンス・クーリエ・パケット１０３０を形成する。アプライアンス・クーリエ・パケット１０３０は、例えば、ＩＰパケット１０２４のＴＣＰとＩＰヘッダＨ１からの制御情報を含めるために変更されたアプリケーション・データユニットＤ１（Ｄ１Ａ）を有する。第２のスーパー・アプライアンス１０１４は、クーリエ・パケット１０２８−１を受けて、それ（１０２８−２）を変更しないで、それをスーパーＣＯサーバー５３４に転送する。スーパーＣＯサーバー５３４は、アプライアンス・クーリエ・パケット１０３０をスーパー・アプライアンス５３２から、そしてクーリエ・パケット１０２８−２をスーパー・アプライアンス１０１４から受ける。クーリエ・パケット１０３０と１０２８−２は、図１２のフローチャートに従って纏め直されてＣＯクーリエ・パケット１０３４になり、ＣＯクーリエ・パケット１０３４はスーパーＣＯコンセントレータ５３６に送られる。スーパーＣＯサーバー１０３６は、やはりスーパーＣＯコンセントレータ５３６に送られるＣＯクーリエ・パケット１０３８を有する。スーパーＣＯ  コンセントレータ５３６は、ＣＯクーリエ・パケット１０３４と１０３８をＣＯコンセントレータ・クーリエ・パケット１０４０に纏め直して、それをスーパー・  ホスト５３８に送る。スーパー・ホストは、ユーザ要求Ｄ１、Ｄ２、Ｄ３、Ｄ４、Ｄ５、Ｄ６及びＤ７（例えばＨＴＴＰ又はＦＴＰ要求）を得るためにＣＯコンセントレータ・クーリエ・パケット１０４０をばらして、それらの要求をウェブサーバーに送る。図１１，１２及び１３に従う纏め直しはまた、スーパー・ホスト５３８のウェブサーバーからスーパーＣＯコンセントレータ５３６、スーパーＣＯサーバー５３４及びスーパー・アプラアイアンス５３２を経てスーパー・ユーザー５３０へ戻るデータ応答に対して生ずる。
【００７５】
両方の方向において、各スーパー・  モジュールがクーリエ・パケットを受けるとき、それらは調べられて、ばらされ、そして、データはそのスーパー・  モジュールのキャッシュを更新するために用いられる。
クーリエ・パケットがバンドルされてそして、バンドルからはずしたとき、データ要求の爆縮そして、データ応答の爆発が実行される。
【データ要求とデータ転送の並行進行】
【００７６】
ウェブページを要求するユーザの例において、ブラウザのための従来の挙動は、ベースＨＴＭＬドキュメントを取り込んで、次にベースＨＴＭＬドキュメントを用いることであり、ブラウザは、一般に一つ以上のウェブサーバーにある多くの埋め込みオブジェクトの次の取り込みを行う。埋め込みオブジェクトは、一つの大きなＴＣＰデータユニットに入れて、ブラウザに戻すことができるだろう。改良がウェブ・サーバーに両方のベースＨＴＭＬドキュメントと埋め込みオブジェクトの両方を得させ、両方を一つの大きなＴＣＰデータユニットに戻すであろう。
これは、ウェブサーバーがベースＨＴＭＬドキュメント及び埋め込みオブジェクトを連続的に取り出して、両方をブラウザに送ることを意味する。本発明の更なる実施態様は、この連続プロセス（すなわち、検索及び送信）にまずベースＨＴＭＬドキュメントを得て、そのベース文書をブラウザに送ることによって並列にする。ベースＨＴＭＬドキュメントが移動中である間、ウェブサーバーは埋め込みオブジェクトを検索する。次に、埋め込みオブジェクトは、送られる。それゆえ、ベースＨＴＭＬドキュメントを送る時間は、連続プロセスにわたって守られる。ユーザは、この並列プロセスを用いてより短時間に全部のウェブ・ページを得る。
【００７７】
図１５は、データ検索と伝送を並列に行う本発明の一つの態様の一例を例示する。図１５は、従来のモジュール１１１０及びスーパー・モジュール１１１２の二つのモジュールを示す。水平軸１１１４は、時間間隔１１２０（時間０とｔ１の間）、１１２２（時間ｔｌとｔ２の間）、１１２４（時間ｔ２とｔ３の間），１１２６（時間ｔ３とｔ４の間）、及び  １１２８（時間ｔ４とｔ５の間）を表す。時間間隔１１２０で、両モジュール１１１０及び１１１２は、データ（１１３０及び１１４０）を読み出すための要求を受ける。時間間隔１１２２で、両方のモジュール１１１０及び１１１２は、第１のデータ項目（１１３２及び１１４２）を読み出す。時間間隔１１２４で、モジュール１１１０及び１１１２は、それらの動作が別れ、モジュール１１１０は第２のデータ項目１１３４を読み出し、続いて時間間隔１１２６で第１のデータ項目１１３６を送り、そして時間間隔１１２８で第２のデータ項目１１３８（すなわち連続プロセス）を送る。一方、スーパー・モジュール１１１２は、時間間隔１１２４で、第１のデータ項目が送られている（１１４６）間と並行して第２のデータ項目１１４４を読み出す。時間間隔１１２６で、スーパー・モジュールは、第２のデータ項目１１４８を送る。したがって、スーパー・モジュールは、時間間隔１１２８の時間を節約する。図１５がデータの検索と送信のパイプライン輸送の開始を例示しているように、このパイプラインが一杯のとき、もっと多くの時間が節約される。
【爆縮／爆増】
【００７８】
有限数のウェブサイトからデータを要求している多くのユーザがあるので、データの要求が多数のユーザのために繰り返されるという確率は増加し、ウェブサーバーに対して１に近づく。これらの重複要求は、不必要なネットワーク通信量であって、結合されるべきである。本発明の実施態様は、各スーパー・モジュールで、これらの重複要求を爆縮（すなわち重複要求を一つの要求に削減する）し、応答を爆増させる（すなわち一つの応答をいくつかの複製にコピーする）。
【００７９】
図１６は、スーパー・ホストにスーパー・ユーザーからのデータ要求を爆縮させることの一例を示す。証券会社を考えよう。新規発行株が上がるとき、４人のブローカーが同時に、株価速報を求めると、３人のブローカー（すなわちスーパー・ユーザー１２１０、１２１２、及び１２１４）が彼らの要求（すなわち１２４０、１２４２及び１２４４）をスーパー・アプライアン１２１６に送り、スーパー・アプライアンス１２１６は、要求スーパー・ユーザー１２１０、１２１２及び１２１４のＩＰアドレスを記憶して、一つの要求、Ｒｅｑ４（１２４６）だけをスーパーＣＯサーバー１２２０に送る。スーパーＣＯサーバー１２２０は、単一要求１２４６を受け、他のスーパー・アプライアンス５３２から何らかの他の重複要求又はスーパー・アプライアンスを用いない他の単一スーパー・ユーザーがあるかどうかを検査する。この例では、４人目のブローカー（スーパー・ユーザー１２１８）は、スーパーＣＯサーバー１２２０に重複要求１２４８を送った。スーパーＣＯサーバー１２２０は、それからスーパー・アプライアンス１２１６及びスーパー・ユーザー１２１８の全ての重複要求のためのＩＰアドレスを記憶し、重複要求を単一の要求（すなわち１２５０）へ爆縮し、要求１２５０をスーパーＣＯコンセントレータ１２２４に送る。スーパーＣＯコンセントレータ  １２２４は、次に他のスーパーＣＯサーバーからの他の重複要求（すなわちＩＳＰサーバー１２２２からの要求１２５２）の検査をし、全ての重複リクエスタのためのＩＰアドレスを記憶し、一つの要求１２５４をスーパー・ホスト１２３０へ送る。スーパー・ホスト１２３０は、また、適用できるならば、他のスーパー・  ＣＯコンセントレータからの重複要求を調べて爆縮する。この例では、他のスーパーＣＯコンセントレータが全くないので、スーパー・ホスト１２３０は、要求１２５４を受ける。
【００８０】
爆増プロセスが図１６に示されていないが、それは、順序は逆だが爆縮プロセスにならい、スーパー・ホスト１２３０から始まる。スーパー・ホスト１２３０は、ウェブサーバー（図示せず）からの応答データ（例えばウェブ・ページ）を読み取り、それを要求した各スーパーＣＯコンセントレータごとに、それを爆増させる（又はそれを繰り返す）。スーパーＣＯコンセントレータ１２２４は、応答データを受けて、それを要求した全てのスーパーＣＯサーバー（すなわちスーパーＣＯサーバー１２２０及び１２２２）のためにそれを爆増させる。スーパーＣＯサーバー（例えば１２２０）は、応答データを受けて、スーパー・アプライアンス１２１６及びスーパー・ユーザー１２１８のためにそれを爆増させる。スーパー・アプライアンス１２１６は、応答データを受けて、データを要求したスーパー・ユーザー１２１０、１２１２及び１２１４のためにそれを爆増させる。
【００８１】
図１７は、本発明の実施態様の同じ宛先への重複データ要求を爆縮させるプロセスのフローチャートである。ステップ１１１０で同じ宛先に対する重複子データ要求が親スーパー・モジュールによって受けられる。ステップ１１１２で、子リクエスタの戻りアドレスは、リストに記録され、親装置に保存される。ステップ１１１４で、重複子データ要求からの共通データは、抽出される、（すなわち、全てのデータ（制御情報を含まない）は、同じなので、一つの子データ要求にあるデータだけが調べられる。ステップ１１１６で、共通データと親戻りアドレスを有する一つの親要求が作られる。そして、ステップ１１１８で、親データ要求は、共通の宛先への経路上の次のスーパー・モジュールに送られる。
【００８２】
図１８は、本発明の実施態様の爆縮要求への応答を爆増させるプロセスを示す。
ステップ１１２０で、宛先は、応答データを親リクエスタ（すなわち爆縮データ要求を送った最後のスーパー・モジュール）に送る。ステップ１１２２で、親スーパー・モジュールは、子リクエスタ・アドレスを有するリストを検索する。ステップ１１２４そして、応答でデータは繰り返されるそして、コピーがリスト上の各子供に送られる（ステップ１１２６）。
【００８３】
データの爆縮及び爆増は、オーディオ及び／又はビデオ（特に放送のために）を流すために特に有用である。一つ以上のユーザが同じＴＶ、ビデオ、ラジオ又は音楽を要求するとき、要求は爆縮され、伝送は爆増される。特にリアルタイム放送のために確保された帯域幅の量は、重要である。多くの人々がインターネット・ラジオ局を聞いている場合、要求は、彼らがウェブ・ホスティング・サーバーに近づくとき激縮され、ユーザの方へ逆行するとき爆増される。インターネット・ラジオ局が同期された同一のデータを放送しているので、爆縮はスーパー・ホスト（全ての要求は、スーパー・ホストで一つの要求に爆縮する）において約１００％であり、爆増は約１００％（全てのユーザがウェブサーバーからスーパー・  ホストへの一つの流れによって取り扱われる）であろう。
【纏め直し及び激縮／爆増】
【００８４】
パケット纏め直し方法は、情報の流れを非常に大きくするために爆縮／爆増方法と協力して働く。ウェブ・サーバー１８２からウェブ・ページコンテンツを要求するスーパー・ユーザー５３０のプロセスの一実施例は、以下の通りである
【００８５】
１．スーパー・ユーザー５３０は、それが満たすことができない全てのそれのデータ要求をそれのローカル・キャッシュから単一のクーリエ・パケットに纏めて、それをスーパー・アプライアンス５３２に送る。
【００８６】
２．スーパー・アプライアンス５３２は、全ての並列の要求を他のスーパー・ユーザーから同じ宛先（すなわち他のユーザからのクーリエ・パケット）へもって行き、それらを一つのより大きなアプライアンス・クーリエ・パケットに纏め直す。どの重複ユーザ要求も爆縮される。一つのアプライアンス・クーリエ・パケットは、スーパーＣＯサーバー５３４に送られる。
【００８７】
３．スーパーＣＯサーバー５３２は、同じ宛先を有する全てのアプライアンス・クーリエ・パケットを多数のスーパー・アプライアンス（及び直接接続される任意のスーパー・ユーザー）から持っていって、より大きなＣＯクーリエ・パケットをスーパーＣＯコンセントレータ５３６に送る。再び重複ユーザ要求は、爆縮される。
【００８８】
４．スーパーＣＯコンセントレータ５３６は、並列のＣＯクーリエ・パケットを纏め直し、どの重複の要求をも爆縮させて、より大きなＣＯコンセントレータ・クーリエ・パケットを適当なスーパー・ホスト５３８に送る。
【００８９】
５．スーパー・ホスト５３８は、ＣＯコンセントレータ・クーリエ・パケット受けて復元する。スーパー・ホストは、要求を標準ウェブサーバー処理のための標準ＨＴＴＰ要求に変換する。
【００９０】
ウェブサーバー１８２は、次に、ＨＴＴＰ要求を処理してスーパー・ホスト５３８に送られるＨＴＴＰ応答を発生する。応答処理は、以下を含む。
【００９１】
６．スーパー・ホスト５３８はウェブサーバー１８２からデータ応答を受け戻し、スーパー・ホスト５３８は、それのキャッシュを更新し、応答を戻りＣＯコンセントレータ・クーリエ・パケットに一纏めにして、それを要求元スーパー・  ＣＯコンセントレータ５３６に送る。
【００９２】
７．スーパーＣＯコンセントレータ５３６は、戻りＣＯコンセントレータ・クーリエ・パケットを受けてスーパーＣＯコンセントレータ５３６キャッシュを更新するためにそれを復元する。スーパーＣＯコンセントレータ５３６は、データをを爆増させ、戻りＣＯクーリエ・パケットにデータを纏め直してそれらを適当な要求元スーパーＣＯサーバー（例えば５３４）に送る。
【００９３】
８．スーパーＣＯサーバー５３４は、戻りＣＯクーリエ・パケットを受けてそれをばらし、スーパー・アプライアンスのためのデータを爆増させ、スーパー・  ＣＯ  サーバーのキャッシュを更新し、データを戻りアプライアンス・クーリエ・パケットに纏め直して戻りアプライアンス・クーリエ・パケットを適当な要求元スーパー・アプライアンス（例えば５３２）へ送る。
【００９４】
９．スーパー・アプライアンス５３２は戻りアプライアンス・クーリエ・パケットを展開し、スーパー・アプライアンス５３２を更新し、キャッシュはデータをを爆増させ、データを戻りユーザ・クーリエ・パケットに纏め直してパケットを適当な要求元スーパー・ユーザー（例えば５３０）に送る。
【００９５】
１０．スーパー・ユーザー５３０は、戻りユーザ・クーリエ・パケットを受けてそれを展開し、それのキャッシュを更新し、そのデータを標準ＨＴＴＰプロトコルを用いているブラウザ５１２に通す。
【００９６】
纏め直しが一つ以上の効果的なブロックにウェブ・ページ・データを記憶することによってキャッシングの効率を変える。これは、ディスクアクセスをディスク・シークの数を減らすことによって著しく減らす。
【半永久的ＴＣＰ／ＩＰ接続】
【００９７】
あらゆるブラウザ要求及びウェブ・ページ応答のためのＨＴＴＰ１．０の下で、新規なＴＣＰ／ＩＰバーチャル回路が確立されている。これは、ユーザがウェブ・サイトを見ているとき、多くの要求／応答対があるので、かなりの遅延を生じ、各バーチャル回路は、バーチャル回路を定めるために３ウェイ・ハンドシェイクを、そしてバーチャル回路を切るために２又は３ウェイ・ハンドシェイクを必要とする。ＨＴＴＰ１．１は、ウェブ・サーバーとＨＴＴＰ１．１対応ブラウザの間に持続的な接続を確立することによって遅延を減少させる。従って、多数の要求が一つのＴＣＰデータユニットで送られることができ、多数の応答が一つの応答ＴＣＰデータユニットで受けられることができる。しかし、ＨＴＴＰ１．１に関するまだいくつかの問題がある。第１に、ブラウザが個々のウェブ・ページの中の第２のウェブ・サーバーからデータを受ける場合、第１のウェブ・サーバーに対する持続接続が失われるか又はもう一つの持続接続が確立されなければならないかのどちらかである。第２に、同じウェブサイトに対する多数のユーザが同じ持続接続を用いることができない。第３には、ＨＴＴＰ持続接続は、ウェブ・コンテンツだけのためのもので、他のアプリケーション層プロトコル（例えばＦＴＰ）は、取り扱われない。そして第４には、持続接続は、全経路のためのもので、ウェブサーバーとブラウザの間の経路の諸部分のためのものではない。
【００９８】
本発明の実施態様が任意の二つのスーパー・モジュール、例えばスーパー・アプライアンス又はスーパー・ユーザーとスーパーＣＯサーバー）の間に半永続的なＴＣＰ仮想回線（ラストマイル）をつくり、それは、予め定められた時間間隔「Ｔ」の間又はスーパー・モジュールうちの一つが閉じられるまで続く。半永久的なＴＣＰ仮想回線は、普通の３ウェイＴＣＰ／ＩＰシェイクハンドによって確立され、普通の２又は３ウェイＴＣＰ／ＩＰシェイクハンドによって切られる。データ転送期間の間に、全ての形式（例えばＨＴＴＰ、ＦＴＰ又はＳＭＮＰ）及び異なる最終ソースから共通の最終宛先（例えばウェブサーバーに対する多数のユーザ又はユーザに対する多数のウェブサーバー）へのアプリケーション・データをこの仮想回線を通じて転送できる。
【００９９】
データの形式又はデータのソースに制限がない理由は、クーリエ・パケットを使用しているからである。センダー・スーパー・モジュールで受けられた（又はつくられた）クーリエ・パケットには大きなアプリケーション・データユニットにある同じ宛先への全ての要求又は応答アプリケーション・データユニットの寄せ集めがあり、そこでは各要求又は応答アプリケーション・データユニットが関連したコントロール・データ（例えばソース・アドレス、ソースと宛先ＴＣＰポート、その他）を有する疑似ヘッダを備えている。必要に応じてレシーバー・スーパー・モジュール、（例えば、最終ユーザはスーパー・ユーザーでない）では、疑似ヘッダを含んでいる大きなアプリケーション・データユニットは、独立したＴＣＰデータユニットとＩＰパケットにばらされて共通の宛先に送り届けられる。要するに、アプリケーション層はプロトコルとソースの下側の３層との違いを隠してしまって、データ転送期間は非常に大きいアプリケーション・データユニットの転送である。
【０１００】
図１９は、トランスポート層でセンダーとレシーバの間の従来のＴＣＰ／ＩＰ接続、データ転送及び切断を示す。センダー１３１２とレシーバ１３１４の間の仮想回線を確立するために、ＴＣＰ同期データユニット（ＳＹＮＣ  １３１６）がセンダー１３１２からレシーバ１３１４へ送られる。レシーバ１３１４は、肯定応答ＳＹＮＣ  ＡＣＫ１３１８を返す。センダー１３１２は、３ウェイ接続シェイクハンドを完了するために、サイズＮ１＋Ｎ２のアプリケーション・データユニット用の第１のＴＣＰデータユニットとしてのＮ１バイトのデータ１３２０とＳＹＮＣ  ＡＣＫ１３１８の肯定応答ＡＣＫの両方を送る。レシーバ１３１４は、肯定応答ＡＣＫ  Ｎ１・１３２２を返す。次に、センダー１３１２は、Ｎ２バイトのデータ１３２４を送って、データの転送が完了していることを示す第２のＴＰＣデータユニットの中の最終フラグ（ＦＩＮ）を設定する。レシーバ１３１４は、データ転送を承認し、仮想回線接続を閉じるために肯定応答ＡＣＫ  ＦＩＮ１３２６を返す。センダー１３１２がＭｌ＋Ｍ２バイトのもう一つのアプリケーション・データユニットを送りたいとき、新規な仮想回線が１３３４においてＳＹＮＣ１３３０、ＳＹＮＣ  ＡＣＫ１３３２及びＡＣＫによってセットアップされなければならない。センダー１３１２は、Ｍ１バイトのデータを有する第１のＴＣＰデータユニット１３３４を送り、レシーバ１３１４は肯定応答１３３６を返す。センダー１３１２は、Ｍ２バイトのデータとＦＩＮビットセットを有する第２のＴＣＰデータユニット１３３８を送る。レシーバ１３１４は、ＡＣＫ  ＦＩＮを有する最終ビット１３４０を承認してと仮想回線接続を閉じる。
【０１０１】
図２０は、本発明の実施態様のＴＣＰ／ＩＰ接続、データ転送及び半永久接続のための切断を示す。センダー１３５２は、ＳＹＮＣ１３５６をレシーバ１３５４へ送ることによって最初の仮想回線接続をセットアップする。レシーバ１３５４は、ＳＹＮＣ  ＡＣＫ１３５８によって承認し、それは、センダー１３５２によってＡＣＫ１３６０で更に承認される。これは、持続仮想ＴＣＰ／ＩＰ接続をセットアップするために最初の３ウェイ・シェイクハンドを完了する。予め定められた時間間隔「Ｔ」１３６２の後、設定されたＦＩＮビットを有するＴＣＰデータユニット１３６４が仮想回線接続の閉成を要求するセンダー１３５２によって送られる。レシーバ１３５４は、ＡＣＫ  ＦＩＮ１３６６によって応答し、仮想回線を閉じる。予め定められた時間Ｔ１３６２において、Ｎ１、Ｎ２、Ｍ１及びＭ２バイトを有するＴＣＰデータユニットは、転送される。センダー１３５２からＮ１バイトのデータ１３７０がレシーバ１３５４へ転送され、レシーバ１３５４はＡＣＫ  Ｎ１・１３７２で応答する。次のＮ２バイト１３７４は、ＡＣＫ  Ｎ２・１３７６で応答するレシーバ１３５４へ転送される。
その次に、Ｍ１バイトのデータ１３７８は、ＡＣＫ  Ｍ１・１３８０で応答するレシーバ１３５４へ転送される。そして、最後に、Ｍ２バイトのデータ１３８２はレシーバ１３５４へ転送され、それはＡＣＫ  Ｍ２・１３８４によって応答する。したがって時間間隔Ｔ  の間、四つのＴＣＰデータユニットに分解されたＮ１＋Ｎ２＋Ｍ１＋Ｍ２バイトの一つの大きなアプリケーション・データユニットがセンダー１３５２からレシーバ１３５４へ転送され終わった。もっと多くのアプリケーション・データが転送される必要がある場合、新規なアプリケーション・データユニットは、Ｎ１＋Ｎ２＋Ｍ１＋Ｍ２バイトの大きなアプリケーション・データユニットに添付されて、半永久接続を通じて送られる。
【ＶＰＮ】
【０１０２】
仮想プライベート・ネットワーク（ＶＰＮ）は、例えばインターネットのような公衆ネットワーク資源を用いる例えば企業内イントラネットのような私設ネットワークである。ＶＰＮの二つの典型的形式は、サイト・ツー・サイト・アクセス及び遠隔アクセスである。各形式はＶＰＮゲートウェーを利用し、それは信頼できる私設ネットワークと信頼できない公衆ネットワークの間のゲートキーパー（一般に専門ハードウェア）である。ゲートキーパーは、信頼できる私設ネットワークにアクセスする者の「ゲスト」リストを有する。パケットがリストに載っていない場合、アクセスがない。
【０１０３】
図２１は、従来のサイト・ツー・サイトＶＰＮ１４４０及び従来の遠隔ＶＰＮ  １４４６の例を示す。サイト・ツー・サイトＶＰＮ１４４０の場合は、ＰＣ１４１２、ＰＣ１４１４及びＬＡＮサーバー１４１６を有する第１のイントラネットがＶＰＮゲートウェー１４２０によってインターネット１５３０へデジタル接続装置１５２６及びＰｏＰ１５１４を介して接続される。インターネット１５３０から、ＶＰＮ１４４０は、ＰＣ１４３４、ＰＣ１４３６及びＬＡＮサーバー１４３２を有する第２のイントラネットに、そして、ＰｏＰ１５４０、モデム１５４２及びＶＰＮゲートウェー１４３０を経て接続される。従って、第１のイントラネットと第２のイントラネットは、インターネットを経てつなぎ合わされ、複合イントラネットを形成するる。遠隔ＶＰＮ１４４６の場合は、遠隔ＰＣにいるユーザがモデム１５３４を経てＰｏＰ１５３２にダイヤルインして、インターネット１５３０、ＰｏＰ１５４０、モデム１５４２及びＶＰＮゲートウェー１４３０を経てＬＡＮサーバー１４３２にアクセスする。ＰＣは、ＶＰＮクライアント・ソフトウェアを有し、動的ＤＮＳ／ＵＲＬサービスによって供給される固定ＩＰアドレス又は動的ＩＰアドレスを持っていてもよく、それはＰＣによって用いられるＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）を与える。動的ＤＮＳ／ＵＲＬサービスがＶＰＮゲートウェー１４３０にＰＣのＩＰアドレスを知らせるので、ＰＣがＬＡＮサーバー１４３２にアクセスする。
【０１０４】
図２２に図示されている従来のＶＰＮには、いくつかの限界がある。第１に、特殊なゲートウェー・ハードウェアが一般に必要である。そして、第２には、ユーザーが多数のＶＰＮへアクセスできない。本発明の実施態様がこれらの問題を克服する。どのスーパー・モジュールサイトのグループ化も一つ以上のＶＰＮを形成することができる。どのスーパー・モジュールがどの他のスーパー・モジュールにアクセスできるか、すなわち、誰が誰にアクセスすることができるか、の許可テーブルを有する中央サイト１５３８（図１６）がある。
【０１０５】
図２２は、本発明の実施態様の二つの仮想私設ネットワーク（ＶＰＮ）の例を示す。スーパー・ユーザー１５１０がＶＰＮ１５５２及びＶＰＮ１５５０に属している。スーパー・ユーザー１５１０は、遠隔ＶＰＮ１５５０を経てスーパー・アプライアンス１５２４に遠隔接続されており、ここでスーパー・アプライアンス１５２４は、ＬＡＮサーバー１４１６で実行するソフトウェア・ゲートウェーである。スーパー・アプライアンス１５２４及びスーパー・アプライアンス１５４４が立ち上がると、それらは中央サイト１５３８にある許可テーブルにそれらのＩＰアドレスを送る。スーパー・ユーザー１５１０は、モデム１５１２を経てＰｏＰ１５１４にダイヤルインし、ＰｏＰは、ＩＰアドレスをスーパー・ユーザーに割り当てる。次に、中央サイトはスーパー・ユーザー１５１０によってログインされ、スーパー・ユーザー１５１０はそのＩＰアドレスを中央サイトに報告する。スーパー・ユーザー１５１０がスーパー・アプライアンス１５２４を経てＰＣ１４１２にアクセスしたいとき、許可テーブルを確かめる。スーパー・ユーザー１５１０にはアクセス権があるので、スーパー・ユーザー１５１０ＩＰアドレスとスーパー・アプライアンス１５２４ＩＰアドレスの間のトンネル（すなわち，ＶＰＮ１５５０）が確立される。スーパー・ユーザー１５１０は、また、中央サイト１５３８にある許可テーブルによって指示されるようにスーパー・ユーザー１５３６とスーパー・アプライアンス１５４４にアクセスするので、ＶＰＮ  １５５２が確立される。したがって、一つのスーパー・ユーザーが多数のＶＰＮ及び他のスーパー・ユーザーにアクセスできる。
【０１０６】
別の実施例において、スーパー・ユーザー１５３６はまた、遠隔ユーザであってもよく、ＶＰＮ１５５２がつくられるとき、ログオンされてはいけない。スーパー・ユーザー１５３６がログインするとき、それはＩＰアドレスを割り当てられて、許可テーブルに従って３ウェーＶＰＮ（スーパー・ユーザー１５３６、スーパー・ユーザー  １５１０及びスーパー・アプライアンス１５４４を含む）が確立される。
【０１０７】
スーパー・トランスポート・システムに関して上述した最適化は、スーパー・アプライアンス・モジュールがＶＰＮの両方の側面上に設置される限り、本発明の実施態様のどのＶＰＮにわたっても適用できる。例えば、二つのスーパー・モジュールは、ＶＰＮを用いて接続でき、例えば、全てのデータ転送は、それらがファイル、イーメール又はウェブ・ページであるかどうかに拘わらず、例えば圧縮技術、クーリエ・パケット、持続ＴＣＰ／ＩＰ、爆縮／爆増及び／又は上述の効果的なファイル形式を用いる。
【産業上の利用可能性】
【０１０８】
結論
本発明の特定の実施態様を説明したが、種々の改造、変更、代替構造及び等価物はまた、本発明の範囲内に含まれる。記載した発明は、ある特定のデータ処理環境内の動作に制限されないで、複数のデータ処理環境内で自由に作動できる。さらに、本発明を特定のシリーズの取引及びステップを用いて説明したが、本発明の範囲が記載されたシリーズの取引及びステップに限られないことは当業者にとって明らかなはずである。
【０１０９】
更に、本発明をハードウェア及びソフトウェアの特定の組合せを用いて説明したが、ハードウェア及びソフトウェアの他の組合せもまた、本発明の範囲内であると認められるべきである。本発明は、ハードウェアだけで又はソフトウェアだけで又はそれらの組合せを用いて実現されてもよい。
【０１１０】
明細書及び図面は、したがって、制限的な意味ではなく例示的意味で考えられるべきである。しかし、追加、控除、削除及び他の改変と変更が各請求項で説明した本発明のより広い精神と範囲から逸脱することなくなされうることは、明白である。
【図面の簡単な説明】
【０１１１】
【図１】従来技術のインターネットへのユーザ接続を示すブロック図である。
【図２】図１の単純化されているが拡大されたブロック図であって、本発明を説明するのを助けるために用いられる。
【図３】ＴＣＰ／ＩＰプロトコル・スタック及び各層に対する関連データ・ユニットを示す。
【図４】ブラウザと本発明の実施態様のウェブ・サーバーの間の通信経路のブロック図である。
【図５】従来のＴＣＰ／ＩＰの例及び本発明の実施態様の二つの変更ＴＣＰ／ＩＰプロトコル・スタックである。
【図６】本発明の実施態様の図２の従来のシステムに挿入されたスーパー・モジュールのブロック図である。
【図７】本発明の実施態様のブラウザとウェブサーバーの間の圧縮データ・トンネルを示す。
【図８】本発明の実施態様の送られたデータのデータ・フォーマットに基づいた圧縮アルゴリズムを示す。
【図９】本発明のもう一つの実施態様のデータを圧縮すべきか否かを決定するフローチャートである。
【図１０】本発明のさらにもう一つの実施態様のもう一つの圧縮プロセスのためのフローチャートを示す。
【図１１】本発明の実施態様のスーパー・ユーザーにおいて複数のアプリケーション・データユニットを纏め直すためのフローチャートである。
【図１２】本発明のもう一つの実施態様のスーパー・モジュールで、複数の受信されたＩＰパケットを纏め直すためのフローチャートである。
【図１３】図１２のさらに詳細なステップである。
【図１４】本発明の一態様のスーパー・ユーザーからスーパー・ホストへのクーリエ・パケットの例を示す。
【図１５】本発明の一態様のデータの検索と転送を並列に実行する例を例示する。
【図１６】スーパー・ユーザーからスーパー・ホストへのデータ要求を爆縮させる一例を示す。
【図１７】本発明の実施態様の同じ宛先への重複データ要求を爆縮させるプロセスのフローチャートである。
【図１８】本発明の実施態様の爆縮した要求に対する応答を爆増させるプロセスを示す。
【図１９】トランスポート層における従来のＴＣＰ／ＩＰ接続、データ転送及びセンダーとレシーバの間の切断を示す。
【図２０】本発明の実施態様のＴＣＰ／ＩＰ接続、データ転送及び半永久接続のための切断を示す。
【図２１】従来のサイト‐ツー‐サイトＶＰＮ１４４０及び従来の遠隔ＶＰＮ  １４４６の例を示す。
【図２２】本発明の実施態様の二つの仮想私設ネットワーク（ＶＰＮ）の例を示す。
【図１】
2004535713.tif 000003
【図２】
2004535713.tif 000004
【図３】
2004535713.tif 000005
【図４】
2004535713.tif 000006
【図５】
2004535713.tif 000007
【図６】
2004535713.tif 000008
【図７】
2004535713.tif 000009
【図８】
2004535713.tif 000010
【図９】
2004535713.tif 000011
【図１０】
2004535713.tif 000012
【図１１】
2004535713.tif 000013
【図１２】
2004535713.tif 000014
【図１３】
2004535713.tif 000015
【図１４】
2004535713.tif 000016
【図１５】
2004535713.tif 000017
【図１６】
2004535713.tif 000018
【図１７】
2004535713.tif 000019
【図１８】
2004535713.tif 000020
【図１９】
2004535713.tif 000021
【図２０】
2004535713.tif 000022
【図２１】
2004535713.tif 000023
【図２２】
2004535713.tif 000024
【国際公開パンフレット】
2004535713.tif 000025
2004535713.tif 000026
2004535713.tif 000027
2004535713.tif 000028
2004535713.tif 000029
2004535713.tif 000030
2004535713.tif 000031
2004535713.tif 000032
2004535713.tif 000033
2004535713.tif 000034
2004535713.tif 000035
2004535713.tif 000036
2004535713.tif 000037
2004535713.tif 000038
2004535713.tif 000039
2004535713.tif 000040
2004535713.tif 000041
2004535713.tif 000042
2004535713.tif 000043
2004535713.tif 000044
2004535713.tif 000045
2004535713.tif 000046
2004535713.tif 000047
2004535713.tif 000048
2004535713.tif 000049
2004535713.tif 000050
2004535713.tif 000051
2004535713.tif 000052
2004535713.tif 000053
2004535713.tif 000054
2004535713.tif 000055
2004535713.tif 000056
2004535713.tif 000057
2004535713.tif 000058
2004535713.tif 000059
2004535713.tif 000060
2004535713.tif 000061
2004535713.tif 000062
2004535713.tif 000063
2004535713.tif 000064
2004535713.tif 000065
2004535713.tif 000066
2004535713.tif 000067
2004535713.tif 000068
2004535713.tif 000069
2004535713.tif 000070
2004535713.tif 000071
2004535713.tif 000072
2004535713.tif 000073
2004535713.tif 000074
2004535713.tif 000075
2004535713.tif 000076
2004535713.tif 000077
2004535713.tif 000078
2004535713.tif 000079
2004535713.tif 000080
2004535713.tif 000081
2004535713.tif 000082
2004535713.tif 000083
2004535713.tif 000084
2004535713.tif 000085
2004535713.tif 000086
2004535713.tif 000087
【国際公開パンフレット（コレクトバージョン）】
2004535713.tif 000088
2004535713.tif 000089
【国際調査報告】
2004535713.tif 000090