(57)【特許請求の範囲】
【請求項１】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、連続的で分離されていないデータ・ストリームの圧縮を、ネットワーク・サーバによるデータの検索時からデータの送信時までの待ち時間の減少をさせるようにして、コンピュータで実行する方法であって、
前記データ・ストリームを調べ、前記データ・ストリームが圧縮可能であるかどうかを判定するステップと、
前記データ・ストリームが圧縮可能であれば、直ちに前記データ・ストリームをネットワーク・サーバの圧縮装置から発生される圧縮ストリームに乗せ、もって、前記ネットワーク・サーバによってデータの完全なブロックが検索され終わったか否かに無関係にただちに前記データ・ストリームに対して圧縮を実行して圧縮データ・ストリームを生成するステップと、
前記圧縮データ・ストリームの生成につれて前記圧縮データ・ストリームを連続的に送信するステップと
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記データ・ストリームが圧縮可能であるかどうかを判定する前記ステップは、前記データ・ストリームを調べ、前記データ・ストリームのヘッダが所定のヘッダタイプに一致するか否かを判定するステップを含む、ことを特徴とする方法。
【請求項３】
請求項１に記載の方法において、前記データ・ストリームが圧縮可能であるかどうかを判定する前記ステップは、前記データ・ストリームを調べ、前記データ・ストリームのファイル拡張子が所定のヘッダタイプに一致するか否かを判定するステップを含む、ことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、圧縮データ・ストリームを生成する前記ステップは、前記データ・ストリーム中のデータ・バイトのカウントを実行するステップを含む、ことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、圧縮データ・ストリームを生成する前記ステップは、前記データ・ストリーム中のデータ・バイトの印刷を実行するステップを含む、ことを特徴とする方法。
【請求項６】
請求項１に記載の方法において、前記データ・ストリームは、ＨＴＭＬデータ・ストリームである、ことを特徴とする方法。
【請求項７】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、ＨＴＭＬデータ・ストリームの圧縮を、ネットワーク・サーバによるデータの検索時からデータの送信時までの待ち時間の減少をさせるようにして、コンピュータで実行する方法であって、
前記ＨＴＭＬデータ・ストリーム中のコンテント・タイプ・ヘッダを読み取るステップを備え、
前記ＨＴＭＬデータ・ストリームの圧縮を実行する圧縮アルゴリズムを、ネットワーク・サーバの前記圧縮装置によって呼び出すステップを備え、その圧縮アルゴリズムは、前記ネットワーク・サーバによって、データの終わり標識の受信を待つこと無しに従ってデータの完全なブロックが検索され終わったか否かとは無関係に、前記ネットワーク・サーバによるデータの検索につれて、前記ＨＴＭＬデータ・ストリームの圧縮を実行するものであり、
圧縮後ただちに前記圧縮ＨＴＭＬデータ・ストリームを送信させるステップを備え、
前記データの完全なブロックの終わりまで送信を継続するステップを備える
ことを特徴とする方法。
【請求項８】
請求項７に記載の方法において、さらに、圧縮の前に前記ＨＴＭＬデータ・ストリーム中のデータ・バイトのカウントを実行するステップを含むことを特徴とする方法。
【請求項９】
請求項７に記載の方法において、さらに、圧縮の前に前記ＨＴＭＬデータ・ストリーム中の前記データ・バイトの印刷を実行するステップを含むことを特徴とする方法。
【請求項１０】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、機械読取り可能な記録媒体であって、データ・ストリームの圧縮を実行させる、命令のシーケンスを含むプログラムが記憶されており、当該命令のシーケンスがコンピュータ・システムによって実行されたときに、前記コンピュータ・システムに、
前記データ・ストリームを調べ、前記データ・ストリームが圧縮可能であるかどうかの判定をさせ、
前記データ・ストリームが圧縮可能であれば、直ちに前記データ・ストリームをネットワーク・サーバの圧縮装置から発生される圧縮ストリームに乗せ、もって、前記ネットワーク・サーバによってデータの完全なブロックが検索され終わったか否かに無関係にただちに前記データ・ストリームに対する圧縮を実行して圧縮データ・ストリームを生成させ、
前記圧縮データ・ストリームの生成につれて前記圧縮データ・ストリームを連続的に送信させること
を実行するプログラムを記憶した記録媒体。
【請求項１１】
請求項１０に記載の記録媒体において、前記した圧縮可能であるかどうかの判定は、前記データ・ストリームを調べ、前記データ・ストリームのヘッダが所定のヘッダタイプに一致するか否かを判定することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１２】
請求項１０に記載の記録媒体において、前記した圧縮可能であるかどうかの判定は、前記データ・ストリームを調べ、前記データ・ストリームのファイル拡張子が所定のヘッダタイプに一致するか否かを判定することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１３】
請求項１０に記載の記録媒体において、前記データ・ストリームに対する圧縮は、前記データ・ストリーム中のデータ・バイトのカウントを実行することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１４】
請求項１０に記載の記録媒体において、前記データ・ストリームに対する圧縮は、前記データ・ストリーム中のデータ・バイトの印刷を実行することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１５】
請求項１０に記載の記録媒体において、前記データ・ストリームは、ＨＴＭＬデータ・ストリームである、ことを特徴とする記録媒体。
【請求項１６】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、機械読取り可能な記録媒体であって、ＨＴＭＬデータ・ストリームの圧縮を実行させる、命令のシーケンスを含むプログラムが記憶されており、当該命令のシーケンスがコンピュータ・システムによって実行されたときに、前記コンピュータ・システムに、
前記ＨＴＭＬデータ・ストリーム中のコンテント・タイプ・ヘッダを読み取り、
前記ＨＴＭＬデータ・ストリームの圧縮を実行する圧縮アルゴリズムにして、前記ネットワーク・サーバによって、データの終わり標識の受信を待つこと無しに従ってデータの完全なブロックが検索され終わったか否かとは無関係に、前記ネットワーク・サーバによるデータの検索につれて、前記ＨＴＭＬデータ・ストリームの圧縮を実行する圧縮アルゴリズムを、ネットワーク・サーバの前記圧縮装置によって呼び出し、
圧縮後ただちに前記圧縮ＨＴＭＬデータ・ストリームを送信させ、
前記データの完全なブロックの終わりまで送信を継続すること
を実行する、プログラムを記憶した記録媒体。
【請求項１７】
請求項１６に記載の記録媒体において、さらに、前記ＨＴＭＬデータ・ストリーム中のデータ・バイトのカウントを、圧縮の前に実行することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１８】
請求項１６に記載の記録媒体において、さらに、前記ＨＴＭＬデータ・ストリーム中のデータ・バイトの印刷を、圧縮の前に実行することを含む、ことを特徴とするプログラムを記憶した記録媒体。
【請求項１９】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、連続的で分離されていないデータ・ストリームを、ネットワーク・サーバによるデータの検索時からデータの送信時までの待ち時間の減少をさせるようにして圧縮する装置であって、
前記データ・ストリームを調べ、前記データ・ストリームが圧縮可能であるかどうかを判定する手段と、
前記データ・ストリームが圧縮可能であると前記判定する手段により判定されると、直ちに前記データ・ストリームをネットワーク・サーバの圧縮装置から発生される圧縮ストリームに乗せ、前記ネットワーク・サーバによってデータの完全なブロックが検索され終わったか否かに無関係にただちに前記データ・ストリームに対して圧縮を実行して圧縮データ・ストリームを生成する手段と、
前記圧縮データ・ストリームの生成につれて前記圧縮データ・ストリームを連続的に送信する手段と
を含むことを特徴とする装置。
【請求項２０】
請求項１９に記載の装置において、前記データ・ストリームが圧縮可能であるかどうかを判定する前記手段は、前記データ・ストリームを調べ、前記データ・ストリームのヘッダが所定のヘッダタイプに一致するか否かを判定する手段を含む、ことを特徴とする装置。
【請求項２１】
請求項１９に記載の装置において、前記データ・ストリームが圧縮可能であるかどうかを判定する前記手段は、前記データ・ストリームを調べ、前記データ・ストリームのファイル拡張子が所定のヘッダタイプに一致するか否かを判定する手段を含む、ことを特徴とする装置。
【請求項２２】
請求項１９に記載の装置において、圧縮データ・ストリームを生成する前記手段は、前記データ・ストリーム中のデータ・バイトのカウントを実行する手段を含む、ことを特徴とする装置。
【請求項２３】
請求項１９に記載の装置において、圧縮データ・ストリームを生成する前記手段は、前記データ・ストリーム中のデータ・バイトの印刷を実行する手段を含む、ことを特徴とする装置。
【請求項２４】
請求項１９に記載の装置において、前記データ・ストリームは、ＨＴＭＬデータ・ストリームである、ことを特徴とする装置。
【請求項２５】
相互接続された複数のネットワーク・サーバおよびクライアント・システムを備え、ネットワーク・サーバの幾つかが圧縮装置を含み、クライアント・システムの幾つかが圧縮解除装置を含んでいて、ネットワークに構成されたコンピュータ・システムにおいて、ＨＴＭＬデータ・ストリームを圧縮する装置であって、
前記ＨＴＭＬデータ・ストリーム中のコンテント・タイプ・ヘッダを読み取る手段を備え、
前記ＨＴＭＬデータ・ストリームの圧縮を実行する圧縮アルゴリズムを、ネットワーク・サーバの前記圧縮装置によって呼び出す手段を備え、その圧縮アルゴリズムは、前記ネットワーク・サーバによって、データの終わり標識の受信を待つこと無しに従ってデータの完全なブロックが検索され終わったか否かとは無関係に、前記ネットワーク・サーバによるデータの検索につれて、前記ＨＴＭＬデータ・ストリームの圧縮を実行するものであり、
圧縮後ただちに前記圧縮ＨＴＭＬデータ・ストリームを送信させる手段を備え、
前記データの完全なブロックの終わりまで送信を継続する手段を備える
ことを特徴とする装置。
【請求項２６】
請求項２５に記載の装置において、さらに、圧縮の前に、前記ＨＴＭＬデータ・ストリーム中のデータ・バイトのカウントを実行する手段を含む、ことを特徴とする装置。
【請求項２７】
請求項２５に記載の装置において、さらに、圧縮の前に、前記ＨＴＭＬデータ・ストリーム中のデータ・バイトの印刷を実行する手段を含む、ことを特徴とする装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネット技術の分野に関する。詳細には、本発明は、連続的で分離されていないデータ・ストリームを圧縮する方法および装置に関する。
【０００２】
【従来の技術】
近年、パーソナル・コンピュータの使用度が大幅に増大している。この増加と共に、インターネット、特にＷＷＷ（「ウェブ」）の使用度が急激に増大している。ウェブは、ユーザが対話文書またはウェブ・ページを介してインターネット上の情報にアクセスできるようにするインターネット上のすべてのコンピュータを表す。ウェブは従来、主として科学的情報の情報源であったが、現在では、商業、娯楽、旅行、教育を含めてほぼあらゆる主題に関する情報の貴重な情報源である。自明であるが、これらの領域のそれぞれに必要な情報のタイプは大幅に異なる。たとえば、ユーザは、娯楽の分野では、ウェブ上でマルチメディア・プレゼンテーションへのアクセスを試み、それに対して旅行の分野では、特定の観光地の風景のダウンロードを試みる。
【０００３】
マルチメディア・ファイルおよびグラフィックス・ファイルがウェブ・マシン上の大量の記憶空間を占有するので、テキスト文書を含めウェブ上の大部分の文書は圧縮される。一般に、データ圧縮は、データを、最初のデータよりも小さな符号に変換することからなる。図１および図２は、従来技術の圧縮機構を示す。この圧縮機構は、ＪＰＥＧ圧縮アルゴリズムなど「ブロック・ベースの」圧縮パラダイムに基づくものである。具体的には、図１に示したように、データ・ブロック１００は、ブロック・ヘッダ１０２と、データ１０４と、ブロックの終わり１０６とを備える。ブロック・ベースの圧縮機構がデータ・ブロック１００を圧縮するには、データ１０４の長さの知識が必要である。ブロック・ベースの圧縮機構は、データ１０４の長さに関する情報をブロック・ヘッダ１０２から受信し、次いで、データ・ブロック１００が完全に受信されたことを示すブロックの終わり１０６が受信されるまで待つ。受信された時点で、データ・ブロック１００が圧縮され送信される。
【０００４】
図２は、ブロック・ベースの圧縮機構をさらに詳しく示す。図のように、ブロック１、２、３、４はタイムラインに沿って圧縮され送信される。タイムラインが、ブロックが受信され、圧縮され、送信される時間を示すと仮定すると、時間ｔ０でブロック１の検索が開始される。ブロック１の検索は時間ｔ１まで継続し、その時点でブロックの終わりインディケータが受信される。ブロックが完全に受信されたことが分かると、時間ｔ１でブロック１が圧縮され送信される。時間ｔ０と時間ｔ１の間にデータの送信は行われない。このパターンはブロック２、３、４でも繰り返され、すなわち時間ｔ２、ｔ３、ｔ４でデータ・ブロックの圧縮および送信が行われるが、これらの時間の間の、データ・ブロックの受信中にはデータの送信は行われない。
【０００５】
このブロック・ベースの圧縮機構では、ブロックが送信される前に、ブロックが受信され圧縮されるある量の待ち時間が生じる。前述のように、時間ｔ０と時間ｔ１の間、時間ｔ１と時間ｔ２の間、時間ｔ２と時間ｔ３の間、時間ｔ３と時間ｔ４の間にはデータ・ブロックは送信されない。したがって、ある量のデータを要求するクライアント・マシンは、データ・ブロック１、２、３、４を受信する際に待ち時間を経験することがある。この待ち時間のために、不安定な画像、ビデオ、テキストが生じ、ユーザは応答が遅延している印象を受ける。
【０００６】
【発明が解決しようとする課題】
したがって、圧縮および送信の前にデータ長を知らなくとも、連続的で分離されていないデータ・ストリームを圧縮できる方法および装置を有することが望ましい。
【０００７】
【課題を解決するための手段】
本発明は、連続的で分離されていないデータ・ストリームを圧縮する方法および装置を開示する。本発明の一態様によれば、データ・ストリームが調べられ、圧縮可能であるかどうかが判定される。圧縮可能である場合、そのデータ・ストリームは圧縮ストリームに乗せられ、ただちに圧縮が実行され、圧縮データ・ストリームが生成される。圧縮データ・ストリームは、生成されると連続的に送信される。本発明の他の態様によれば、データ・ストリームはＨＴＭＬ（ハイパー・テキスト・マークで言語）データ・ストリームである。
【０００８】
本発明の他の目的、特徴、利点は、添付の図面および詳細な説明から明らかになろう。
【０００９】
本発明を添付の図面において制限ではなく一例として図示する。図面では、同じ参照符号は同様な要素を参照する。
【００１０】
【発明の実施の形態】
本実施形態は、連続的で分離されていないデータ・ストリームを圧縮する方法および装置に関する。「ストリーム圧縮」は本実施形態では、連続的で分離されていないデータ・ストリームを圧縮する非ブロック・ベースの圧縮を含む。下記の詳細な説明では、本発明を完全に理解させるために多数の特定の詳細について述べる。しかし、当業者には、これらの特定の詳細を使用しなくても本発明を実施できることが明らかであろう。他の例では、本発明を不必要に曖昧にしないように、周知の構造、インタフェース、プロセスは詳しく示さなかった。
【００１１】
図３は、本発明が動作できる典型的なコンピュータ・システム２００を示す。当業者には、他の代替コンピュータ・システム・アーキテクチャも使用できることが明らかであろう。
【００１２】
一般に、図３に示したようなコンピュータ・システムは、情報を伝達するバス２０１と、情報を処理するためにバス２０１に結合されたプロセッサ２０２と、プロセッサ２０２用に情報および命令を記憶し、バス２０１に結合されたメイン・メモリ２０３と、プロセッサ２０２用に静的情報および命令を記憶し、バス２０１に結合された読取り専用メモリ２０４と、コンピュータ・ユーザに対して情報を表示するためにバス２０１に結合された表示装置２０５と、選択された情報およびコマンドをプロセッサ２０２に伝達するためにバス２０１に結合された入力装置２０６と、情報および命令を記憶するためにバス２０１に結合された、磁気ディスクや関連するディスク・ドライブなどの大容量記憶装置２０７とを備える。ディジタル情報を含むデータ記憶媒体２０８は大容量記憶装置２０７と共に動作するように構成され、それによって、プロセッサ２０２はバス２０１を介してデータ記憶媒体２０８上のディジタル情報にアクセスすることができる。
【００１３】
プロセッサ２０２は、様々な汎用プロセッサや、ＩｎｔｅｌTM  Ｃｏｒｐｏｒａｔｉｏｎによって製造されているＰｅｎｔｉｕｍTMマイクロプロセッサなどのマイクロプロセッサのうちの任意のプロセッサ２０２でよい。しかし、当業者には、特定のコンピュータ・システムで他の様々なプロセッサを使用することもできることが明らかになろう。表示装置２０５は、液晶装置でも、あるいは陰極管（ＣＲＴ）でも、あるいはその他の適切な表示装置でもよい。大容量記憶装置２０７は、ハード・ディスク、フロッピー・ディスク、ＣＤ−ＲＯＭ、磁気テープ、あるいはその他の磁気データ記憶媒体または光学データ記憶媒体上に記憶されている情報を読み書きするための、従来型のハード・ディスク・ドライブ、フロッピー・ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、あるいはその他の磁気データ記憶装置または光学データ記憶装置でよい。データ記憶媒体２０８は、ハード・ディスク、フロッピー・ディスク、ＣＤ−ＲＯＭ、磁気テープ、あるいはその他の磁気データ記憶媒体または光学データ記憶媒体でよい。
【００１４】
一般に、プロセッサ２０２は、大容量記憶装置２０７を使用してデータ記憶媒体２０８から処理命令およびデータを検索し、この情報を実行できるようにランダム・アクセス・メモリ２０３にダウンロードする。プロセッサ２０２は次いで、ランダム・アクセス・メモリ２０３または読取り専用メモリ２０４から得た命令ストリームを実行する。入力装置２０６で入力された、選択されたコマンドおよび情報を使用して、プロセッサ２０２によって実行される命令の流れが方向付けられる。等価入力装置２０６は、従来型のマウスやトラックボール装置などのポインティング装置でよい。次いで、この実行処理の結果が表示装置２０５上に表示される。
【００１５】
コンピュータ・システム２００は、コンピュータ・システム２００をネットワークに接続するネットワーク装置２１０を含む。コンピュータ・システム２００をネットワークに接続するネットワーク装置２１０には、イーサネット装置と、電話ジャックと、衛星リンクが含まれる。当業者には、他のネットワーク装置も使用できることが明らかであろう。
【００１６】
本発明の好ましい実施形態は、ＷｅｂＴＶTM  Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．（Ｐａｌｏ  Ａｌｔｏ）によって製造されているＷｅｂＴＶTMと呼ばれているシステム上で実施される。ＷｅｂＴＶTMシステムは、標準テレビジョン・セットを表示装置として使用してウェブをブラウズし、標準電話、総合サービス・ディジタル通信網（ＩＳＤＮ）、または同様な通信回線を使用して、インターネットなど従来型のネットワークに接続される。ＷｅｂＴＶTMクライアント・システムのユーザは、１つまたは複数のリモートＷｅｂＴＶTMサーバから与えられるＷｅｂＴＶTMネットワーク・サービスを利用することができる。ＷｅｂＴＶTMネットワーク・サービスを、ＷｅｂＴＶTMクライアント・システム上で実行されるソフトウェアと共に使用して、ウェブをブラウズし、電子メールを送信し、インターネットを他の様々な方法で利用することができる。ＷｅｂＴＶTMネットワークは、ウェブ内で実施され１つまたは複数のウェブ・サーバによってサポートされるＨＴＴＰベースの１組のプロトコルを使用する。
【００１７】
図４は、一実施形態によるＷｅｂＴＶTMネットワークの基本構成を示す。いくつかのＷｅｂＴＶTMクライアント２８０が、直接ダイヤル二方向データ接続２７５、たとえば、電話（ＰＯＴＳ、すなわち「従来型の電話サービス」）や、ＩＳＤＮ（総合サービス・ディジタル通信網）や、その他の同様なタイプの接続を介してモデム・プール２７０に接続される。モデム・プール２７０は通常、従来当技術分野で知られているようなルータを通じ、インターネットなど従来型のネットワーク・インフラストラクチャ２６５を介していくつかのリモート・サーバ２５０に結合される。
【００１８】
ＷｅｂＴＶTMシステムは、具体的にはＷｅｂＴＶTMクライアント２８０をサポートするＷｅｂＴＶTMサーバ２６０も含む。ＷｅｂＴＶTMサーバ２６０は、ＷｅｂＴＶTMクライアント２８０がウェブおよびその他のＷｅｂＴＶTMサービスにアクセスできるようにするプロキシとして働く。具体的には、ＷｅｂＴＶTMサーバ２６０は、「キャッシング・プロキシ」として機能する。ＷｅｂＴＶTMサーバ２６０上のプロキシ・キャッシュは、ＷｅｂＴＶTMクライアント２８０とＷｅｂＴＶTMサーバ２６０のどちらかが頻繁に使用するウェブ文書、画像、その他の情報を一時的に記憶するために使用される。
【００１９】
ＷｅｂＴＶTMサーバ２６０の一部として文書トランスコーダも設けられる。文書トランスコーダは、リモート・サーバ２５０から検索されたウェブ文書の符号を自動的に改訂するために使用されるソフトウェアを含む。トランスコーディングは、（１）ストリーミング、（２）バッファ、（３）遅延の各モードのうちの１つで実行される。プロキシ・トランスコーディング機構の詳細は、１９９６年６月３日に出願された出願番号第０８／６５６９２４号の「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｐｒｏｖｉｄｉｎｇ  Ｐｒｏｘｙｉｎｇ  ａｎｄ  Ｔｒａｎｓｃｏｄｉｎｇ  ｏｆ  Ｄｏｃｕｍｅｎｔｓ  ｉｎ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｎｅｔｗｏｒｋ」と題する関連米国特許出願に記載されている。現在市販されているプロキシ・サーバは、関連出願に記載されたトランスコーディング機能を含むように修正することができる。
【００２０】
ＷｅｂＴＶTMクライアント２８０はそれぞれ、直接、モデム・プール２７０と同様なＷｅｂＴＶTMモデム・プール２７５を介し、あるいは従来型のモデム・プール２７０およびインターネット２６５を通じて、ＷｅｂＴＶTMサーバ２６０に接続される。モデム・プール２７０が、インターネットおよび私設ネットワークへのアクセスを可能にする現在世界全体に存在するモデム・プールなど従来型のモデム・プールであることに留意されたい。ＷｅｂＴＶTMクライアントを含むＷｅｂＴＶTMシステムの詳細は、出願番号が第０８／６６００８８号であり１９９６年６月３日に出願された「Ｗｅｂ  Ｂｒｏｗｓｅｒ  Ａｌｌｏｗｉｎｇ  Ｎａｖｉｇａｔｉｏｎ  Ｂｅｔｗｅｅｎ  Ｈｙｐｅｒｔｅｘｔ  Ｏｂｊｅｃｔｓ  Ｕｓｉｎｇ  Ｒｅｍｏｔｅ  Ｃｏｎｔｒｏｌ」と題する関連米国特許出願に記載されている。
【００２１】
本発明の一実施形態は、コンピュータ・システム２００やＷｅｂＴＶTMサーバ２６０などのコンピュータ・システム上で従来どおりに実行することのできるソフトウェア・モジュールとして実施される。好ましい実施形態のアプリケーション・ソフトウェアは、周知の技法を使用して、データ記憶媒体２０８上に記憶され、それに続いてコンピュータ・システム２００またはＷｅｂＴＶTMサーバ２６０にロードされ実行される。この実施形態のソフトウェアは、開始された後、後述のように動作する。
【００２２】
図５は、本発明の一実施形態の概要を示す。具体的には、サーバ３００においてクライアントから要求３０２が受信される。サーバ３００は、要求されたデータ３０４を圧縮装置３０６へ送信する。圧縮装置３０６は、サーバ３００上に存在することも、あるいは独立のシステム上に存在することもできる。圧縮装置３０６は、要求されたデータ３０４を圧縮ストリーム３０８に乗せ（attach）、圧縮ストリームは次いで、受信側で圧縮解除装置３１０によって受信される。圧縮解除装置３１０は、クライアント３１４の一部でも、あるいは独立のシステムでもよい。圧縮解除装置３１０は、圧縮された要求データ３０４を受信し、このデータを圧縮解除ストリーム３１２に乗せる。圧縮解除された表示データ３１６は次いで、クライアント３１４によって表示される。
【００２３】
図６ないし図８は、本発明の一実施形態を詳しく示す。具体的には、この実施形態によれば、ブロック・パラダイムではなくストリーム圧縮パラダイムまたは「オンザフライ」圧縮パラダイムが使用される。「オンザフライ」は、本明細書では、本発明によるストリーム圧縮プロセスが、所定量のデータを待たずに圧縮を行うことを含む。その代わり、本発明によるストリーム圧縮は、データ・ストリームを圧縮ストリームに乗せ、プロセスがデータを圧縮可能と判定するとただちにデータの圧縮および送信を開始する。ストリーム圧縮プロセスは、要求されたすべてのデータが送信されるまで、圧縮ストリームに乗せられたデータを連続的に圧縮し送信する。本発明の一実施形態は、適応ハフマン符号化の修正バージョンを使用して、ストリーム圧縮を実行する。適応ハフマン符号化は当業者には良く知られている。ＬＺＰアルゴリズムなど他の符号化アルゴリズムを使用することもできる。
【００２４】
図６に示したように、データ・ストリーム４００は、ヘッダ４０２と、データ４０４と、データの終わり標識４０６とを含む。ウェブでは、ヘッダ４０２はコンテント・タイプ・ヘッダである。コンテント・タイプ・ヘッダは、ウェブ・クライアント・マシンとウェブ・サーバとの間の通信に関するＨＴＴＰ通信プロトコルの一部として定義されている。他のタイプのヘッダは他の通信プロトコルに使用される。ヘッダは一般に、ヘッダの後に続くデータのタイプおよび特性に関する情報を与える。
【００２５】
データ・パケット４００は圧縮の前に調べられ、ヘッダ４０２は、データ４０４が圧縮可能であるかどうかを判定するために使用される。本発明の一実施形態によれば、データ４０４は、コンテント・タイプ・ヘッダ「テキスト／ＨＴＭＬ」で示されるようにＨＴＭＬデータである。データ４０４が圧縮可能であることを示すコンテント・ヘッダを含むデータ・パケット４００を圧縮装置が検出すると、データ４０４はただちに、圧縮データを送信する圧縮ストリームに乗せられる。圧縮の前にデータ・パケット４００上で他の所定の機能を実行できることに留意されたい。このような所定の機能には、データ・ストリーム中のバイトをカウントすることと、データ・ストリーム中のバイトを印刷することが含まれる。
【００２６】
本発明の他の実施形態によれば、データ・ストリームはヘッダ４０２を含まない。この実施形態では、検索されたデータのファイル拡張子を調べて、そのファイルにどんなタイプのデータが存在するかを判定することができる。たとえば、ファイルがコンテント・タイプ・ヘッダ「テキスト／ＨＴＭＬ」のないＨＴＭＬファイルである場合でも、ファイル拡張子を調べることによってファイル内のデータのタイプを判定することができる。この例では、ファイル拡張子が .ＨＴＭＬである場合、ファイル内のデータのタイプは、ＨＴＭＬデータであると判定され、ファイル内のデータは圧縮可能としてマーク付けされる。他のファイル拡張子にはたとえば、Ｍｉｃｒｏｓｏｆｔディジタル・ビデオ・ファイルの .ＡＶＩが含まれる。ファイルの内容が判定された後、前述のように、圧縮データを送信する圧縮ストリームにデータ４０４が乗せられる。
【００２７】
本発明のこの実施形態は、圧縮すべきデータの長さを知らず、かつ所定量のデータを受信するのを待たずに、圧縮ストリームにデータを乗せる。圧縮、乗せ、送信の各ステップは、要求されたすべてのデータが圧縮され送信されるまで連続的に行われる。前述のように、ブロック・ベースの圧縮パラダイムでは、圧縮装置は、データを圧縮し始める前に、ブロック標識の終わりを受信するまで待機する。
【００２８】
図７および図８は、この実施形態を詳しく示す。図７は、圧縮ストリーム４１０に乗せられたデータ・ストリーム４０８を示す。データ・ストリーム４０８は、暗号化ストリーム４１２など他のタイプの適切なストリームに乗せることもできる。この機能ストリームの「層化」によって、すべてのデータが受信されるのを待たずに、各機能をほぼ同時に実行することができる。ＷｅｂＴＶTMサーバは、他の修正なしにこの種のストリーム圧縮を実行することができる。同じ機能を与えるように他の標準ウェブ・サーバを修正することができる。
【００２９】
図７に示したように、圧縮と送信は、時間ｔ１、ｔ２、ｔ３、ｔ４だけではなく連続的に行われる。時間ｔ０で、圧縮装置がデータを圧縮可能と判定した直後にデータの圧縮および送信が開始される。データは、引き続き時間ｔ０と時間ｔ１の間、時間ｔ１と時間ｔ２の間、時間ｔ２と時間ｔ３の間、時間ｔ３と時間ｔ４の間に圧縮され、送信される。このように、本発明は、圧縮機構が圧縮の前に特定の長さのデータを待つ必要があり、したがって、データ送信において固有の待ち時間を生じさせるというブロック・ベースの圧縮パラダイムに固有の欠点を解消する。
【００３０】
図８は、圧縮データの受信側を示す。圧縮された暗号化データ・ストリーム４１４が受信され、非暗号化ストリーム４１６および圧縮解除ストリーム４１８に乗せられる。図のように、データは連続的に受信され、非暗号化ストリーム４１６および圧縮解除ストリーム４１８に乗せられる。したがって、データは、時間ｔ１１、ｔ１２、ｔ１３、ｔ１４でのみ受信され非暗号化され圧縮解除されるのではなく、すべてのこれらの時間の間にも受信され非暗号化され圧縮解除される。ＷｅｂＴＶTMクライアントは、他の修正なしにこの種のストリーム圧縮解除を実行することができる。同じ機能を与えるように他の標準ウェブ・ブラウザを修正することができる。別法として、同じ機能を与えるように標準ウェブ・ブラウザを機能拡張するために追加ソフトウェア構成要素または「プラグイン」を設けることができる。
【００３１】
図９は、ＷｅｂＴＶTMシステムで実施される本発明の一実施形態を示す。ＷｅｂＴＶTMクライアント２８０が要求を出す。要求が処理され、リモート・サーバ２５０からデータが返される。リモート・サーバ２５０からのデータはインターネット２６５を介してＷｅｂＴＶTMサーバ２６０へ送信される。ＷｅｂＴＶTMサーバ２６０はデータをディスク６００に書き込み、それと同時にデータをＷｅｂＴＶTMクライアント２８０へ送信する。送信の前に、データのコンテント・タイプ・ヘッダが調べられる。データは、圧縮可能と判定された場合、データは圧縮ストリームに乗せられる。データがコンテント・タイプ・ヘッダを含まない場合、ファイル拡張子が調べられ、ファイル内のデータのタイプが判定される。本発明のこの実施形態によれば、データは、コンテント・タイプ・ヘッダまたはデータのファイル拡張子がＨＴＭＬデータを示す場合に圧縮可能と判定される。次いで、圧縮ストリームが書込みストリームに乗せられ、データがＷｅｂＴＶTMクライアント２８０へ送信される。
【００３２】
図１０は、本発明の一実施形態を示すフローチャートである。クライアント要求に基づいて、ステップ６０２でデータ・ストリームがリモート・データ源から受信され、あるいはローカル・ディスクから検索される。ステップ６０４で、データのヘッダまたはファイル拡張子が調べられ、データ・タイプが判定される。このデータ・タイプが所定のタイプに合致する場合、ステップ６０６でデータが圧縮可能と判定される。ステップ６０８で、データ・ストリームが、圧縮ストリーム、または暗号化ストリームなど他のタイプのストリームに乗せられる。次いでステップ６１０で、圧縮ストリームおよびその他のストリームが書込みストリームに乗せられる。ステップ６１２で、書込みストリームが、乗せられたストリームと共に送信され、ステップ６１４で、書込みストリームがクライアントによって受信される。
【００３３】
したがって、ストリーム圧縮方法および装置を開示した。本明細書で説明した特定の構成および方法は、本発明の原則を例示するものに過ぎない。当業者には、本発明の範囲から逸脱せずに形態および細部に多数の修正を加えることができよう。本発明は、特定の好ましい実施形態に関して示されているが、そのように制限されるものとみなすべきものではない。本発明は、添付の特許請求の範囲の範囲によってのみ制限される。
【図面の簡単な説明】
【図１】  従来技術の圧縮方法で使用されるデータ・ブロックを示す図である。
【図２】  従来技術の圧縮機構が複数のデータ・ブロックをどのように圧縮し送信するかを示す図である。
【図３】  本発明が動作する典型的なコンピュータ・システムの図である。
【図４】  本発明が動作する代替コンピュータ・システム（ＷｅｂＴＶTMシステム）の図である。
【図５】  現在請求中の発明の一実施形態の概要を示す図である。
【図６】  本発明の一実施形態によるデータ・ストリームを示す図である。
【図７】  タイムラインに従ったデータ・パケットの圧縮および送信を示す図である。
【図８】  タイムラインに基づく圧縮暗号化データ・パケットの受信を示す図である。
【図９】  ＷｅｂＴＶTMシステムで実施される本発明の一実施形態を示す図である。
【図１０】  本発明の一実施形態を示すフローチャートである。
【符号の説明】
２００  コンピュータ・システム
２０１  バス
２０２  プロセッサ
２０３  メイン・メモリ
２０４  読取り専用メモリ
２０５  表示装置
２０６  入力装置
２０７  大容量記憶装置
２０８  データ記憶媒体
２１０  ネットワーク装置
【図１】
0004165668.tif 000002
【図２】
0004165668.tif 000003
【図３】
0004165668.tif 000004
【図４】
0004165668.tif 000005
【図５】
0004165668.tif 000006
【図６】
0004165668.tif 000007
【図７】
0004165668.tif 000008
【図８】
0004165668.tif 000009
【図９】
0004165668.tif 000010
【図１０】
0004165668.tif 000011