"データを圧縮するための方法であって、記憶手段に格納されているデータ内のシーケンスと一致する、ルックアップテーブル内のインデックスを検索するステップであって、前記ルックアップテーブルは、インデックスに対応する1つまたは複数の、前記記憶手段内の位置を有する、ステップと、前記検索されたシーケンスに対応する位置が、LRULastRecentlyUsedテーブルにおいて参照されていない時間が最も長い複数の位置の1つと一致するかどうかを判別するステップであって、前記LRUテーブル中の各位置は、対応するシーケンスの位置を符号化するためのLRU表現を有し、かつ、以前ストリーミング配信されたデータ内のシーケンスが参照されていない時間が最も長い複数の位置の1つを示す参照となる、ステップと、前記検索されたシーケンスの位置が前記LRUテーブルに含まれる場合は、前記LRUテーブルを参照し、対応するLRU表現を使用して前記検索されたシーケンスの位置を符号化し、かつ、第1のハフマン符号を使用して前記検索されたシーケンスの長さを符号化するステップであって、前記データは、前記検索されたシーケンスの位置および長さを符号化することにより圧縮される、ステップと、または、前記検索されたシーケンスの位置が前記LRUテーブルに含まれない場合は、前記LRU表現を使用せずに、前記検索されたシーケンスの位置を符号化し、かつ、第1のハフマン符号を使用して前記検索されたシーケンスの長さを符号化するステップであって、前記データは、前記検索されたシーケンスの位置および長さを符号化することにより圧縮される、ステップとを備えることを特徴とする方法。前記符号化された1つまたは複数の位置を含む圧縮データをストリーミング配信するステップをさらに備えることを特徴とする請求項1に記載の方法。前記インデックスを検索するステップは、前記検索されたインデックスの各位置を含むハッシュチェーンを参照することを特徴とする請求項1に記載の方法。前記シーケンスおよび前記インデックスは、それぞれ、少なくとも2バイトからなることを特徴とする請求項1に記載の方法。前記圧縮データは、1つまたは複数のパケットとして形成されており、前記パケットは、圧縮が各パケットごとに行われるようネットワーク経由送信のために圧縮されることを特徴とする請求項1に記載の方法。前記検索されたシーケンスの位置は、ハフマン符号化と、算術符号化と、プレフィクス符号化と、マルコフ符号化とからなるグループから選択された符号化技術を使用して符号化されることを特徴とする請求項1に記載の方法。前記インデックスを検索するステップでは、しきい値を使用して実行することを特徴とする請求項1に記載の方法。請求項1に記載の方法をコンピュータに実行させるためのコンピュータ実行可能命令を備えるプログラムを記録したコンピュータ読み取り可能な媒体。データを前記記憶手段に追加するステップと、追加されたデータを前記ルックアップテーブルに含めるために前記記憶手段を参照するルックアップテーブルを更新するステップとをさらに備えることを特徴とする請求項1に記載の方法。データを圧縮するためのサーバであって、記憶手段に格納されているデータ内のシーケンスと一致する、ルックアップテーブル内のインデックスを検索し、前記ルックアップテーブルは、対応するインデックスの1つまたは複数の、前記記憶手段内の位置を有する位置を有しており、前記検索されたシーケンスの位置が、LRULastRecentlyUsedテーブルにおける最も長い間参照されていない複数の位置の1つと一致するかどうかを判別し、前記LRUテーブル中の各位置は、対応するシーケンスの位置を符号化するためのLRU表現を有し、かつ、以前ストリーミング配信されたデータ内のシーケンスの最も長い間参照されていない複数の位置の1つを示す参照となり、前記検索されたシーケンスの位置が前記LRUテーブルに含まれる場合は、前記LRUテーブルを参照し、対応するLRU表現を使用して前記検索されたシーケンスの位置を符号化し、かつ、第1のハフマン符号を使用して前記検索されたシーケンスの長さを符号化する処理であって、前記データは、前記検索されたシーケンスの位置および長さを符号化することにより圧縮される、処理と、または、前記検索されたシーケンスの位置が前記LRUテーブルに含まれない場合は、前記LRU表現を使用せずに、前記検索されたシーケンスの位置を符号化し、かつ、第1のハフマン符号を使用して前記検索されたシーケンスの長さを符号化する処理であって、前記データは、前記検索されたシーケンスの位置および長さを符号化することにより圧縮される、処理とを実行するように構成されていることを特徴とするサーバ。前記サーバはさらに、前記符号化された1つまたは複数の位置を含む圧縮データをストリーミング配信するように構成されていることを特徴とする請求項10に記載のサーバ。前記サーバは、インデックスを検索する場合に、前記検索されたインデックスの各位置を含むハッシュチェーンを参照することを特徴とする請求項10に記載のサーバ。前記シーケンスおよび前記インデックスは、それぞれ、少なくとも2バイトからなることを特徴とする請求項10に記載のサーバ。前記圧縮データは、1つまたは複数のパケットとして形成されており、前記パケットは、圧縮が各パケットごとに行われるようネットワーク経由送信のために圧縮されることを特徴とする請求項10に記載のサーバ。前記検索されたシーケンスの位置は、ハフマン符号化と、算術符号化と、プレフィクス符号化と、マルコフ符号化とからなるグループから選択された符号化技術を使用して符号化されることを特徴とする請求項10に記載のサーバ。ネットワークと、サーバであって、複数のバイトを有する第1のヒストリバッファと、複数のエントリを含むルックアップテーブルであって、前記エントリのそれぞれは複数のインデックスのうちの特定の1つを使用して発見可能であり、前記エントリのそれぞれは対応する前記インデックスが前記ヒストリバッファ内に置かれているかを示す参照であり、もし置かれていれば、前記ヒストリバッファ内の前記対応する前記インデックスの1つまたは複数の位置を示す参照である、ルックアップテーブルと、前記ヒストリバッファ内のマッチングシーケンスの長さ分の符号を含む第1のハフマンテーブルと、マッチングシーケンスの位置およびリテラルバイトを含む第2のハフマンテーブルと、圧縮モジュールであって、リモートアクセスの要求に応じてストリーミング配信されるデータ内のカレントポインタが指す初期シーケンスと一致する前記ルックアップテーブル内の前記インデックスの1つを見つけ、前記マッチングインデックスの前記対応する前記エントリが1つまたは複数の前記位置を参照している場合、前記マッチングインデックスを持つ前記位置のそれぞれのシーケンスと前記カレントポインタが指す前記データ内のシーケンスとを比較し、前記比較からマッチングシーケンスを導き、前記第1のヒストリバッファ内の前記マッチングシーケンスの前記位置および長さを含む表現を含むようにデータを構成し、前記第1のハフマンテーブルを使用してマッチングシーケンスの位置を符号化し、LRULastRecentlyUsedテーブルを使用してマッチングシーケンスの位置を符号化し、前記LRUテーブルは、最近のマッチングシーケンスの参照された複数の位置をリスト化しており、前記マッチングシーケンスの位置が前記LRUテーブルに存在しない場合は、前記マッチングシーケンスの位置が前記第2のハフマンテーブルを使用して符号化されて、前記マッチングシーケンスの前記長さだけ前記カレントポインタを進め、前記マッチングインデックスの前記対応するエントリが前記位置をどれも参照しない場合、前記初期シーケンスを含むようにデータを構成し、前記第2のハフマンテーブルを使用して前記初期シーケンスのリテラルバイトを符号化して、前記初期シーケンスの長さだけ前記カレントポインタを進め、前記カレントポインタが前記追加データを通じて進めたときに、前記ネットワーク経由で、パケット化済みの構成されたデータをストリーミング配信するようにサーバを実行させる圧縮モジュールと、を備えるサーバと、前記サーバと通信するために、前記ネットワークに通信接続され、第2のプロセッサおよび第2のメモリを備え、第2のヒストリバッファ、マッチングシーケンスの位置およびリテラルバイトを復号化するための符号を含む第3のハフマンテーブル、マッチングシーケンスの長さ分を復号化するための符号を含む第4のハフマンテーブル、LRUテーブル、および、ストリーミング配信データを伸張可能にする伸張モジュールを備えるクライアントと、を備え、前記クライアントは、前記構成されたデータを受信するように構成されており、符号化された表現が前記構成されたデータに存在している場合、前記伸張モジュールに従ってクライアントは、前記LRUテーブル、前記第3のハフマンテーブルおよび前記第4のハフマンテーブルを使用して、前記表現により示される復号後の位置および復号後の長さに基づいて前記第2のヒストリバッファ内のマッチングシーケンスを見つけることにより、前記表現を復号するように構成されていることを特徴とするシステム。したがって、データ圧縮に対する継続的な必要性がある。データ圧縮について説明する。一実施例では、クライアントからのリモートアクセスの要求に応じて送信されたデータや、ターミナルサービス環境でのデータなどをクライアントにストリーミング配信するために、データを圧縮する圧縮モジュールがサーバにより実行される。圧縮モジュールは、クライアントにすでにストリーミング配信されているデータを含むヒストリバッファを使用する。圧縮モジュールは、実行されると、ストリーミング配信されるデータ内のシーケンスとヒストリバッファ内の1つまたは複数のシーケンスとを比較して、マッチングシーケンスを見つける。ヒストリバッファ内のシーケンスの位置を特定するために、複数のインデックスのうちの1つでそれぞれ発見可能な複数のエントリを有するルックアップテーブルを使用する。これらのエントリのそれぞれは、対応するインデックスがヒストリバッファ内に置かれているかどうかを示す参照であり、もし置かれていれば、さらに、ヒストリバッファ内の対応するインデックスの1つまたは複数の位置を示す参照となる。したがって、圧縮モジュールは、ストリーミング配信されるデータ内の初期シーケンスをルックアップテーブルのインデックスとして使用し、ヒストリバッファ内のマッチングインデックスを見つけることができる。その後、データ内のマッチングシーケンスは、ヒストリバッファ内のマッチングシーケンスの位置および長さを記述する表現で置き換えられ、これによりクライアントにストリーミング配信する圧縮データを形成することができる。他の実施例では、方法は、サーバにより提供されるターミナルサービスからデータをクライアントにネットワーク経由で通信するためにリソースが使用可能かどうかを示すフィードバックを受け取ること、およびそのフィードバックに応じて、データを圧縮するために使用される圧縮ルーチンの1つまたは複数のパラメータをチューニングすることを含む。さらに他の実施例では、方法は、サーバを通じて利用可能なアプリケーションまたはファイルへのリモートアクセスの要求をクライアントからサーバで受け取ることを含む。ネットワーク経由で、その要求に応じてデータを伝達するためにリソースが使用可能であるかどうかが判別される。データを圧縮するために使用される圧縮ルーチンの1つまたは複数のパラメータは、上記判別されたリソースの使用可能性に基づいてチューニングされる。なお、説明の中の例において、同じ参照番号は、類似の構造およびコンポーネントを参照するために使用する。概要データ圧縮について説明する。一実施例では、圧縮モジュールは、サーバからクライアントへストリーミング発信するデータを圧縮するためサーバにより実行される。圧縮モジュールは、クライアントにすでにストリーミング配信されているデータを含むヒストリバッファを使用する。圧縮モジュールは、実行時に、ストリーミング配信されるデータ内のシーケンスとヒストリバッファ内の1つまたは複数のシーケンスとを比較して、マッチングシーケンスを見つける。ヒストリバッファ内のシーケンスの位置を特定するために、複数のエントリを有するルックアップテーブルが使用される。これらのエントリはそれぞれ、複数のインデックスのうちの特定の1つを使用して発見可能である。各エントリは、対応するインデックスがヒストリバッファ内に置かれているかどうかを示す参照であり、もし置かれていれば、さらに、ヒストリバッファ内の対応するインデックスの1つまたは複数の位置を示す参照となる。したがって、圧縮モジュールは、ストリーミング配信されるデータ内の初期シーケンスをルックアップテーブルのインデックスとして使用し、エントリを1つ見つけることができる。このようにして、圧縮モジュールは、ヒストリバッファ内の各シーケンスをストリーミング配信されるデータ内のシーケンス毎に別々に比較することなく、初期シーケンスを有するヒストリバッファ内でそれぞれの位置をすばやく特定することができる。マッチングインデックスの対応するエントリが複数の位置を参照している場合、圧縮モジュールは、マッチングインデックスがある各位置のシーケンスを初期シーケンスを含むデータ内のシーケンスと比較することによりマッチングシーケンスを導出することができる。その後、データ内のマッチングシーケンスは、ヒストリバッファ内のマッチングシーケンスの位置および長さを記述する表現で表すことができる。その後、その表現を含む圧縮データを形成することができる。続いて、圧縮データはクライアントにストリーミング配信される。クライアントは、サーバからクライアントにすでにストリーミング配信されているデータも含んでいるヒストリバッファを使用することにより圧縮データを伸張する。クライアントは、伸張モジュールの実行を通じて、データを再構成するためにその表現により示される長さおよび位置を使用してクライアントのヒストリバッファ内のマッチングシーケンスを見つける。このようにして、データを失うことなくデータの圧縮および伸張を行うことができるような可逆データ圧縮技術が実現される。例えば、ビデオデータは、このデータ圧縮技術を使用することで、データの一部を失わずに、したがってビデオデータの解像度を維持して、圧縮および圧縮解除を行うことができる。例示的環境図1は、データがネットワーク106経由でサーバ102からクライアント104へストリーミング配信される環境100を示す一実施例の図である。クライアント104は、さまざまな方法で構成することができる。例えば、クライアント104は、図示されているようなデスクトップコンピュータ、および、移動局、娯楽機器、セットトップボックス、携帯電話などのネットワーク106経由で通信することが可能な装置として構成することができる。クライアント104は、さらに、クライアント104を操作する人および/またはエンティティentityに関係していてもよい。つまり、クライアント104は、ユーザおよび/またはマシンを含む論理クライアントを記述しているとすることができる。1つのクライアント104が図示されているが、複数のクライアントをネットワーク106に通信可能に接続することができる。ネットワーク106は、インターネットとして図示されているが、さらに、イントラネット、有線または無線電話網などのさまざまな他のネットワークを含むこともできる。サーバ102は、ネットワーク106経由でデータをクライアント104にストリーミング配信するように構成されている。サーバ102は、クライアント104によるレンダリングのために、さまざまなストリーミングデータを供給する。一実施例では、サーバ102は、クライアント104にストリーミング配信されるコンサートのWeb放送を提供することができる。クライアント104によりレンダリングされると、ユーザはそのWeb放送を視聴できる。他の実施例では、クライアント104は、このクライアント104により出力するために、サーバ102からストリーミング配信される楽曲を含むデータを受信することができる。さらなる実施例では、サーバ102は、さらに、リモートアプリケーション実行用のターミナルサービスterminalservicesを提供することもできる。例えば、サーバ102は、複数のアプリケーション1081、...、108n、...、108Nを含むことができるが、ただし、nは2からNまでの任意のアプリケーションとすることができる。アプリケーション1081~108Nはそれぞれ、サーバ102上で実行される。サーバ102は、ネットワーク106経由で、アプリケーション1081~108Nを実行することを通じて供給される画面情報をクライアント104にストリーミング配信する。例えば、画面情報は、オペレーティングシステムにより与えられるデスクトップの表示、およびワードプロセッサの実行に関係する情報を表示するウィンドウ、ならびにオペレーティングシステムおよび/またはワードプロセッサにより与えられるオーディオ情報も含むことができる。サーバ102からストリーミング配信される画面情報は、ユーザが見られるようにクライアント104によりレンダリングされる。ユーザは、クライアント104と対話し、マウス108および/またはキーボード110などのクライアント104の入力デバイスを使用して入力することができる。入力は、キーボード110を使用することにより供給される、ワードプロセッサ用のテキスト入力などのレンダリングされた画面情報に対応することができる。それらの入力は、ネットワーク106経由でクライアント104からサーバ102へ通信される。入力は、サーバ102により受信されると、複数のアプリケーション1081~108Nを実行するときに使用することができる。例えば、ワードプロセッサは、ドキュメントに含めるためにテキスト入力を受け、画面情報をクライアント104にストリーミング配信して、このテキストを含むドキュメントを示すことができる。サーバ102上でのアプリケーション1081~108Nの実行と、画面情報のクライアント104へのストリーミング配信を通じて、クライアント104は、クライアント104自体では他の方法だと利用できない機能を利用することができる。例えば、クライアント104は、例えば、限られた処理および/またはメモリリソースを有するシンクライアントとして構成することができる。しかし、サーバ102は、例えば、クライアント104よりも処理および/またはメモリリソースの量をより多くもたせることにより、機能を豊富にすることができる。したがって、サーバ102は、クライアント104では実行できない、および/またはクライアント104で実行すると低速となるアプリケーションを実行することができる。サーバ102は、画面情報をクライアント104に送信することによりアプリケーション1081~108Nの1つまたは複数の実行結果をクライアント104に送り、ネットワーク106経由でクライアントから入力を受け取る。このようにして、処理リソース、メモリリソース、および複数のアプリケーション1081~108Nなど、サーバ102が備える機能を、他の方法だとこの機能を利用できないクライアント104に提供することができる。ネットワーク経由でサーバ102とクライアント104間の通信を提供するために、サーバ102とクライアント104は、それぞれ、リモートデスクトッププロトコルRDP112、114を実装することができる。RDP112、114は、すでに説明したようにアプリケーション1081~108Nに対しネットワーク接続を介したリモート表示および入力機能を提供するように設計されている。例えば、RDPを使用することにより、サーバ102からクライアント104にデバイス通信devicecommunicationおよびプレゼンテーションデータを搬送する個別の仮想チャネルとともに、クライアント104からサーバ102に通信される暗号化された入力を可能にする。RDP112、114は、さらに、圧縮および伸張モジュール116、118をサーバ102およびクライアント104のそれぞれに含めることにより帯域幅を削減することもできる。圧縮モジュール116はRDP112の実装を通じてサーバ102により実行され、ネットワーク106経由でストリーミング配信する前にデータを圧縮することができる。同様に、伸張モジュール118はRDP114の実装を通じてクライアント104により実行されることにより、ネットワーク106経由でサーバ102からストリーミング配信された圧縮データを伸張することができる。圧縮および伸張モジュール116、118は、実行時にそれぞれ、ネットワーク1006経由でストリーミング配信されるデータの圧縮および伸張を行う。すでに述べたように、ストリーミングデータの圧縮および伸張では、一度にデータセット全体の圧縮および伸張を行うのとは対照的に、つまりブロック圧縮とは対照的に、独自の複雑な状況をもたらす場合がある。例えば、データはリアルタイムでストリーミング配信することができるため、データのストリーミング配信に遅延が生じるとデータの有用性を低下させる場合がある。圧縮および伸張モジュール116、118では、ストリーミングデータの独自の複雑な状況に対処し、それにより、図3から5に関してさらに詳しく説明されているように、ネットワーク106経由で圧縮データのストリーミング配信を提供する。ターミナルサービスTSを使用することにより、クライアント104は、サーバ102にインストールされているアプリケーション1081~108Nのうちの1つまたは複数にアクセスし、サーバ102上のアプリケーションを実行し、クライアント104上にそのアプリケーションのユーザインターフェイスUIを表示することができる。アプリケーション1081~108Nはサーバ102上で実行されるため、TSにより、クライアント104は、クライアント104がクライアント104自体でリソースをローカルで実行するのに適したハードウェアおよびソフトウェアを有しているかどうかに関係なく、企業インフラのリソースを活用することができる。クライアント104は、複数のアプリケーション1081~108Nがサーバ102により実行されるターミナルサービス環境で説明しているが、クライアント104は、複数のアプリケーション1201、...、120m、...、120Mのうちの1つまたは複数を実行することもできる。例えば、アプリケーション1201~120Mのうちの1つは、ユーザが見るために表示するデータをレンダリングし、マウス108および/またはキーボード110などのユーザからの入力を受け取るためにRDP114とともに利用されるインターフェイスを備えることができる。さらに、圧縮および伸張モジュール116、118は、それぞれのRDP112、114の一部として図示されているが、圧縮および伸張モジュール116、118は、それぞれストリーミングデータの圧縮および伸張のため実行されるスタンドアロンのソフトウェアコンポーネントとして構成することができる。さらに、以下の説明の一部では、ターミナルサービス環境における圧縮の使用について説明しているが、本明細書で説明している圧縮および伸張技術は、他のさまざまな環境でも利用することができる。例えば、この圧縮技術を使用することにより、リモートアクセス環境で使用されるデータを圧縮することができる。リモートアクセスとは、遠く離れた場所からコンピュータまたはネットワークにアクセスできることを表す。例えば、企業の遠隔地にある事務所では、企業のネットワークにアクセスすることを所望し、リモートアクセスを利用して、電話回線網、インターネットなどを経由し、そこに収容されているファイルおよびアプリケーションにアクセスする場合がある。サーバ102は、ネットワークにリモートでアクセスすることを求めているクライアントを処理するためにセットアップされている関連ソフトウェアを有するリモートアクセスサーバとして構成することができる。一実施例では、リモートアクセスサーバは、セキュリティ用のファイヤウォールサーバおよびリモートアクセス要求をネットワークの他の部分に転送するルータを含む。リモートアクセスサーバは、さらに、仮想プライベートネットワークVPNの一部として使用することもできる。図2は、図1のサーバ102およびクライアント104をさらに詳しく示している一実施例200の図である。サーバ102は、プロセッサ202およびメモリ204を備える。RDP112およびその個別の圧縮モジュール116は、プロセッサ202上で実行されているように例示され、メモリ204に格納可能である。同様に、クライアント104は、プロセッサ206およびメモリ208を備える。RDP114およびその個別の伸張モジュール118は、プロセッサ206上で実行されているように例示され、メモリ208に格納可能である。サーバ102からクライアント104にストリーミング配信されるべきデータは、ビデオカメラ、マイクなどの入力デバイス210から受け取った、アプリケーション1081~108Nのうちの1つまたは複数の実行など、さまざまなソースから供給することができる。圧縮モジュール116は、サーバ102のプロセス202上で実行され、クライアント104にストリーミング配信するデータを圧縮する。そのデータは、サーバ102からクライアント104へパケットでストリーミング配信することができる。例えば、圧縮モジュール116は、所与の長さの未圧縮のシーケンスを有するデータを受け取り、そのシーケンスを、より小さな現在圧縮されている長さに圧縮すること、例えばバイト数、ビット数などを減らすことを試みることができる。圧縮モジュール116は、シーケンスを、置き換えられるシーケンスに比べて格納時に使用されるメモリリソースが少なくて済む、例えばバイト数の少ない表現で置き換えることにより、パケット毎にデータを圧縮することができる。圧縮モジュール116がシーケンスを圧縮できる場合、圧縮データがRDP接続の終点、つまりクライアント104のRDP114に送信される。伸張モジュール118はクライアント104により実行され、圧縮データを伸張してデータを再構成する。圧縮モジュール116がデータを圧縮できない場合、データは、非圧縮形式で、つまりリテラルシーケンスでクライアント104にストリーミング配信することができる。圧縮モジュール116は、その後、サーバ102により実行され、後続のシーケンスの圧縮を試みることができる。データを圧縮するために使用される基本オペレーションは、以前にストリーミング配信されたシーケンスとともに圧縮されるデータ内のシーケンスのパターンマッチングを伴う。これを達成するために、圧縮モジュール116は、クライアント104にすでにストリーミング配信されているデータを収容しているヒストリバッファ212を維持する。圧縮モジュール116は、実行時に、ストリーミング配信されるデータ内のシーケンスとすでにクライアント104にストリーミング配信されているデータに含まれる1つまたは複数のシーケンスとを照合する。その後、ヒストリバッファ内のシーケンスと一致するストリーミング配信されるデータ内のシーケンスは、ヒストリバッファ212内のマッチングシーケンスを参照する1つまたは複数の表現を使用して表現することができる。これらの表現は、より小さい、つまり、圧縮する実際のシーケンス、すなわちマッチングシーケンスを格納するために使用されるメモリリソースよりも、使用するメモリリソースをより少なくすることができる。このことは、ストリーミング配信されるデータに含まれるデータの量を有効に低減する。ヒストリバッファ212を使用したパターンマッチングの基本例を例示するために、ヒストリバッファ212は、以下のシーケンスを含むと仮定する。12745639451491圧縮モジュール116は、サーバ102のプロセッサ202上で実行され、以下のシーケンスを受け取る。45974563945146圧縮モジュール116は、実行時に、圧縮されるデータ内のシーケンスと一致するヒストリバッファ内で最長のシーケンス、つまりマッチングシーケンスmatchingsequenceを見つける。この場合、ヒストリバッファ内に現れるマッチングシーケンスは、以下では太字で示されている。マッチングシーケンスは、長さ10バイトで、ヒストリバッファ212の先頭から3バイトのところで始まる左から開始し、0からカウントする。したがって、圧縮モジュール116は、実行時に、ストリーミング配信されるデータを以下のように表現することにより、圧縮データを作成することができる。459バッファの先頭から3バイトのところで始まる長さ10バイトの一致6サーバ102では、ヒストリバッファ内のマッチングシーケンスを参照することにより、クライアント104にすでにストリーミング配信されているシーケンスを再送する必要はない。それ故に、圧縮モジュール116は、ストリーミング配信されるデータ内の繰り返しパターンを見つけて、この繰り返しパターン、つまりマッチングシーケンスを、ネットワーク106経由で送信されたときに使用するメモリリソースおよび帯域幅がより少ない表現で置き換えることにより、ストリーミング配信されるデータを圧縮する。圧縮データを伸張するために、クライアント104は、伸張モジュール118およびヒストリバッファ214を備える。クライアント104のヒストリバッファ214は、サーバ102のヒストリバッファ212のように、すでにストリーミング配信されているデータを格納する。したがって、伸張モジュール118は、クライアント104により実行されると、ヒストリバッファ214を使用することによりクライアント104にストリーミング配信されている圧縮データを伸張することができる。前の実施例の続きとして、クライアント104が以下のように示されている圧縮データを受け取ると仮定する。459バッファの先頭から3バイトのところで始まる長さ10バイトの一致6伸張モジュール118は、圧縮データに含まれる表現に基づき、実行時に、ヒストリバッファ214から圧縮されたシーケンスを取り出すことができ、これは、以下のように太字で示される。こうして、伸張モジュール118は、ヒストリバッファ214を使用して圧縮された文字列を伸張することができる。サーバ102は、ヒストリバッファ212内でマッチングシーケンスを見つけるためのルックアップテーブル216を備えることもできる。例えば、ルックアップテーブル216は、複数のインデックスのうちの対応する1つによりそれぞれ発見可能な複数のエントリを含むことができる。それぞれのエントリは、対応するインデックスを有するヒストリバッファ212内の各位置を記述する。したがって、圧縮モジュール116は、サーバ102により実行されると、ルックアップテーブル216を使用することによりヒストリバッファ212内の特定のシーケンスをすばやく特定することができる。ルックアップテーブル216およびヒストリバッファ212についてのさらなる検討は、図3~4の関連で見出すことができる。サーバ102は、ハフマン符号化、算術符号化、プレフィクス符号化Prefixencoding、およびマルコフ符号化などの符号化技術を使用して、ストリーミング配信用にデータをさらに圧縮することもできる。例えば、ストリーミング配信されるデータは、ヒストリバッファ内のシーケンスと一致しないシーケンスを含むことができる。これらのシーケンスは、リテラルシーケンスliteralsequencesと呼ばれる。ハフマン符号化を使用して、データ内のリテラルシーケンスの一部または全部を圧縮すると、データをさらに圧縮することができる。例えば、ハフマン符号化は、さらに圧縮するそれぞれのリテラルシーケンスの出現度数を関連付ける出現度数テーブルから始めることができる。出現度数ケーブルは、データ自体および/または代表データから生成することができる。例えば、すでにストリーミング配信されているパケットを処理することでリテラルシーケンスの出現度数を求め、その後それを利用して、それぞれの後続のパケットを処理することができる。例えば、可変長文字列を、一意的なプレフィクスprefixなどのその特定のリテラルシーケンスを一意に表すそれぞれのリテラルシーケンスに割り当てることができる。その後、その可変長文字列をツリー状に配列して、各リテラルシーケンスおよび表現をそれぞれ符号化および復号化する。リテラルシーケンスを符号化するために、符号化されるリテラルシーケンスをツリー内に配置する。リテラルシーケンスを含む葉を特定するために使用されるツリーの枝を利用して、リテラルシーケンスを符号化する、つまり、リテラルシーケンスの表現を与える。例えば、ハフマン符号化に使用されるツリーの各枝には出力アルファベットの記号、例えば、ビット0と1がマークされ、符号化は、ツリーのルートから符号化されるリテラルシーケンスまでの経路上の枝マーキングの列挙となる。各表現の復号化は、リテラルシーケンスを含むツリーの葉に到達するまで、可変長文字列内のそれぞれの連続する値に基づいて、ツリーをその原点から枝を通り下ってツリーの葉へと縦走traversingすることによって行われる。リテラルシーケンスのハフマン符号化について説明してきたが、ハフマン符号化を使用することによりさらにさまざまなデータを圧縮することができる。例えば、ハフマンテーブル218では、リテラル222シーケンスおよびバックポインタ224の両方を符号化することができる。リテラルシーケンスは、すでに説明しているように、ヒストリバッファ212内に見つからないシーケンスを含む。したがって、ハフマンテーブル218を使用することで、リテラル222シーケンスを圧縮することができる。ハフマンテーブル218を利用してバックポインタ224も圧縮できる。バックポインタ224は、ヒストリバッファ212内の特定のシーケンスの位置を記述する。例えば、すでに説明しているように、ヒストリバッファ212内のシーケンスと一致するデータ内のシーケンス、つまりマッチングシーケンスは、バッファの先頭からYバイトのところで始まる長さXバイトの一致として記述することができる。バックポインタ224は、ヒストリバッファ212内のマッチングシーケンスの位置、つまりYバイトを記述する。ハフマンテーブル220を使用することにより、マッチングシーケンスの長さ分226、つまりXバイト分を圧縮することができる。サーバ102からクライアント104にストリーミング配信された圧縮データを伸張するために、それぞれサーバ102のハフマンテーブル218、220に対応するハフマンテーブル228、230を使用して、クライアント104により、伸張モジュール116が実行される。例えば、ハフマンテーブル228は、リテラル232シーケンスおよびバックポインタ234を伸張するために使用でき、一方、ハフマンテーブル230は、マッチングシーケンスの長さ226を伸張するために使用することができる。ハフマンテーブルのさらなる検討は、図7の関連で見出すことができる。サーバ102およびクライアント104は、さらに、それぞれLRUlastrecentlyused:最も長い間参照されていないテーブル236、238を含むこともできる。LRUテーブル236、238はそれぞれ、バックポインタが最も長い間参照されていないバックポインタのうちの1つであったかどうかに基づきバックポインタをさらに符号化するために使用することができる。例えば、LRUテーブル236は、それぞれ、最後の4つのバックポインタ毎に、LRU表現を与えるために使用することができる。LRU表現は、LRUテーブル236内で特定のバックポインタを特定するためのインデックスとして使用される。この方法で、繰り返されるバックポインタは、さらに圧縮することができる。LRUテーブルのさらなる検討は、図7の関連で見出すことができる。サーバ102からクライアント104にストリーミング配信されるデータの圧縮について説明しているが、クライアント104は、データを圧縮してサーバ102にストリーミング配信で送り返すこともできる。さらに、以下では、サーバ102からクライアント104にストリーミング配信されるパケットに関してデータの圧縮について説明しているが、データのさまざまな集合を使用して、サブパケットバイトシーケンスsub‐packetbytesequences、複数パケットなどのデータを圧縮することができる。さらに、以下では、バイトシーケンスについて説明しているが、ビットなど、データ内の他のシーケンスについても考慮されている。手順の実施例図3は、ストリーミング配信するデータを圧縮用に構成する例示的手順300を示す流れ図である。ブロック302で、データがヒストリバッファ212に追加される。例えば、ヒストリバッファ212は、ネットワーク106経由で図2のサーバ102からクライアント104にストリーミング配信された、かつ/またはストリーミング配信する準備ができている複数のパケット3041、3042を含むことができる。他の実施例では、パケット3041、3042は、圧縮モジュール116の実行によりすでに処理されているデータに対応することができる。サーバ102は、ストリーミング配信されるパケット3043を受信する。圧縮モジュール116は、サーバ102により実行されると、パケット3043をヒストリバッファ212に追加し、これによりヒストリバッファは、ストリーミング配信されたパケット3041、3042およびストリーミング配信されるパケット3043を含む。ブロック306で、圧縮モジュール116は、サーバ102により実行されると、ルックアップテーブル216を更新して、追加データ、つまりパケット3043を参照する。ルックアップテーブル216は、kを1からKまでの任意のインデックスとし、複数のインデックス308kを含むように構成される。インデックス308kはそれぞれ、ルックアップテーブル216内の複数のエントリのうちのそれぞれ1つを発見するために使用される。各エントリは、複数のインデックス308kのうちの対応する1つがヒストリバッファ212内に置かれているかどうかを示す参照であり、もし置かれていれば、ヒストリバッファ212内の対応するインデックス308kの1つまたは複数の位置を示す参照となる。例えば、複数のエントリのうちの1つで、インデックス308kのうちの対応する1つを持つヒストリバッファ212内の複数の位置を参照することができる。複数の位置はそれぞれ、複数のハッシュチェーン310kのうちの対応する1つの使用を通じて説明されているように、図示されている。例えば、インデックス308kは、シーケンス45を持つものとして図示されている。ルックアップテーブル216内のインデックス308kの対応するエントリ、つまり、ハッシュチェーン310kは、ヒストリバッファ212内のインデックス308k45の各位置を記述する。例えば、パケット3041は、図3では、以下のシーケンスを持つものとして図示されている。01234567パケット3042は、図3では、以下のシーケンスを持つものとして図示されている。89453130図2のクライアント104にストリーミング配信されるパケット3043は、図3では、以下のシーケンスを持つものとして図示されている。45670824パケット3041~3043は、以下のシーケンスが観察されるようにヒストリバッファ内に順次配列される。012345678945313045670824ハッシュチェーン310kは、ヒストリバッファ212内のインデックス308k45のそれぞれの位置を記述する。各位置は、さまざまな方法で記述することができる。例えば、これらの位置は、ヒストリバッファ212の先頭から数え、番号0から始めたときのシーケンスの第1のバイトの位置として記述することができる。ハッシュチェーン310kは、ハッシュチェーン310k内の16からパケット3043の先頭まで図3において点線で示すように、ヒストリバッファ212内のシーケンスの先頭から16バイトのところにあるインデックス308k45の第1の位置を記述する。同様に、ハッシュチェーン310kは、ハッシュチェーン310k内の10からパケット3042の第3バイトまで図3において点線で図示されている、ヒストリバッファ212内のシーケンスの先頭から10バイトのところにあるインデックス308k45の第2の位置を記述する。さらに、ハッシュチェーン310kは、ヒストリバッファ212内の4バイトのところにあるインデックス308k45の第3および最終の位置を含む。したがって、ルックアップテーブル216は、ヒストリバッファ212内のインデックス308kの各位置、例えば、4、10、16を記述するハッシュチェーン310kを参照する対応するエントリを持つインデックス308k、例えば45を含む。ルックアップテーブル216を更新することにより、圧縮モジュール116は、実行時に、図4に関して後でさらに詳しく説明するように、より効率的な方法でストリーミング配信されるデータを圧縮することができる。各インデックス308kは、図3では、複数のハッシュチェーン310kのうちの対応する1つを持つものとして図示されているが、インデックス308kが対応するハッシュチェーンを持たない場合もある。例えば、場合によっては、ヒストリバッファ212がインデックスを含まないこともある。したがって、そのインデックスに対応するルックアップテーブル216内のエントリは、ハッシュチェーンを含み得ない。言い換えると、そのインデックスに対するハッシュチェーンは値0を持つ、つまり対応するインデックスを含む場所はヒストリバッファ212内にはないということである。さらに、複数のハッシュチェーン310kはそれぞれルックアップテーブル216内に含まれるように図示されているが、ハッシュチェーン310kの1つまたは複数をさまざまな方法で提供することができる。例えば、ルックアップテーブル216内の各エントリは、ルックアップテーブル216とは別の配列として構成される対応するハッシュチェーンへのポインタを含むことができる。図4は、ストリーミング配信されるパケット3043への参照を含むように構成されている図3のルックアップテーブル216を使用してパケット3043を圧縮する例示的手順400を示す流れ図である。ブロック402で、圧縮モジュール116は、実行時に、カレントポインタ404を、図3のブロック302のヒストリバッファ212に追加されたデータ、つまりパケット3043のところで開始する。ブロック406で、圧縮モジュール116は、サーバ102により実行され、カレントポインタ404が指す初期シーケンスと一致するルックアップテーブル216内のインデックスを見つける。例えば、圧縮モジュール116は、カレントポインタ404のところの2バイト、例えば45からなる初期シーケンスを使用して、その初期シーケンスと一致する複数のインデックス308kのうちの1つを見つけることができる。この例では、ルックアップテーブル216のインデックス308k45は、ヒストリバッファ212内のカレントポインタ404が指す初期シーケンス45と一致する。インデックス308kは、ヒストリバッファ212内のインデックス45308kの各位置を記述するハッシュチェーン310kを参照する対応するエントリをルックアップテーブル216内に持つ。したがって、その対応するエントリは、ヒストリバッファ212内の初期シーケンスの各位置を記述する。マッチングインデックス308kの対応するエントリが複数の位置を参照する場合、マッチングインデックス308k45を有するヒストリバッファ212内の各位置のシーケンスが、カレントポインタ404が指す初期シーケンスを有するデータ内のシーケンスと比較される。例えば、カレントポインタ404、つまりヒストリバッファ212内の位置16のところの初期シーケンス45、およびヒストリバッファ212内の位置10にあるシーケンスは、長さ2である、つまり、各位置のバイトシーケンス内の先頭2バイトのみで一方を他方と照合する。すでに述べたように、この実施例のハッシュチェーン310k内の位置は、ヒストリバッファ212の先頭から番号0を先頭番号として数えることで記述される。カレントポインタ404が指す初期シーケンスおよびヒストリバッファ212内の位置4のシーケンスは長さ4である。つまり、位置4にあるバイトシーケンス内の4バイトは、位置4のところのシーケンス内の4バイトに一致する。このようにして、マッチングシーケンス4567は、計算で求められた長さから導かれる。最適なマッチングシーケンスを見つけるために、図7に関してさらに詳しく説明されているように、最大長が計算で求められ、かつ/またはしきい値に達するまで、ハッシュチェーン310k内の各位置を、圧縮されるデータのシーケンス、つまり、パケット3043と比較することができる。比較を最適化するため、次のバイトはシーケンス、例えば、初期シーケンスまたはヒストリバッファ212内のインデックスの後に続く1バイトを最初に比較することができるが、それは、最初の2バイトが一致すること照合から知られているからである。シーケンス内の次のバイトに基づく比較のさらなる検討が、図8の関連で見出すことができる。ブロック408で、マッチングシーケンスは、圧縮データを形成するために使用される表現で表される。例えば、パケット3043内のマッチングシーケンス4567は、ヒストリバッファ212内のマッチングシーケンスの長さおよびマッチングシーケンスの位置を記述する表現で表すことができる。この表現は、タプルtuple、つまり指定された順序を持つ集まりとして形式化でき、{バックポインタ,長さ}という形式となる。バックポインタは、マッチングシーケンスの相対的位置をヒストリバッファ212内のオフセットとして記述することができる。例えば、バックポインタは、ヒストリバッファ212内におけるマッチングシーケンスの絶対的位置とカレントポインタ404の絶対的位置との間のオフセットとして相対的位置を記述することができる。この例では、マッチングシーケンスの絶対的位置は、ヒストリバッファ212内の位置4であり、カレントポインタ404の絶対的位置は、16である。したがって、マッチングシーケンスの相対的位置は、カレントポインタ404から12バイトのところである。長さは、マッチングシーケンスの長さを記述し、例えば4である。したがって、パケット3043を、マッチングシーケンス4567を表現{12,4}で表すことにより圧縮し、圧縮データ、例えば、パケット410を形成することができる。他の実施例では、マッチングシーケンスの位置は、ヒストリバッファのマッチングシーケンスの絶対的位置、例えば、位置4から得られる。こうして、ルックアップテーブル216からは、ヒストリバッファ212内の各インデックス308kの各位置が得られる。したがって、圧縮モジュール116が実行されると、初期シーケンスのそれぞれの位置を、マッチングシーケンスを見つけるためにヒストリバッファ212内で個々のビットまたはバイトを尋ね歩くことをせずに、ヒストリバッファ212内で見つけることができる。そのため、圧縮モジュール116は、ストリーミング配信されるデータを効率よく圧縮することができる。図5は、伸張モジュール128の実行を通じてクライアント104により図4の圧縮されたパケットを伸張する例示的な手順500を示す流れ図である。ブロック502で、クライアント104は、図4のサーバからクライアント104にストリーミング配信された、圧縮されたデータ、例えばパケット410を受け取る。ブロック504で、伸張モジュール128は、実行時に、クライアント104のヒストリバッファ214内のマッチングシーケンスを検出する。クライアント104のヒストリバッファ214は、サーバ102のヒストリバッファ212のように、サーバ102からクライアント104へストリーミング配信されているデータを含めることができる。そのため、圧縮データ、例えばパケット410が形成される前に、クライアント104のヒストリバッファ214は、サーバ102のヒストリバッファ212と一致する。したがって、伸張モジュール118は、実行時に、サーバのヒストリバッファ212内のマッチングシーケンスの長さおよび位置を記述する表現からクライアント104のヒストリバッファ214内のマッチングシーケンスを見つけることができる。前の実施例の続きとして、マッチングシーケンス4567が、位置12で見つかるが、それは、すでに説明したように相対的位置である。ブロック506で、伸張モジュール118は、実行時に、この表現をマッチングシーケンスで置き換えて、データを再構成する。例えば、表現{12,4}は、マッチングバイトシーケンス4567で置き換えられ、図4のブロック408で圧縮されたパケット3043のシーケンスと一致するシーケンス45670824を含むパケット508を形成する。例えば、圧縮データは、マッチングシーケンスの代わりに表現を含む新しいデータセットを形成することによりストリーミング配信されるデータから形成することができる。そのため、この実施例で示されるように、クライアント104は、ルックアップテーブル216を使用せずに圧縮データを伸張することができる。したがって、ストリーミング配信される圧縮データは、クライアント104がサーバ102に比べて削減されたハードウェアおよび/またはソフトウェアリソースを有する場合でも、クライアント104により伸張することができる。図3~4に関連してそれぞれ説明した例示的な手順300、400では、ルックアップテーブル216は、複数のインデックス308kのそれぞれが2バイトを含むように構成されている。したがって、ルックアップテーブル216に、ホストバッファ212内のすべての2バイトシーケンスを記述している65,536個の対応するエントリを入れることができる。これにより、ルックアップテーブル216で直接、初期シーケンスを使用することができる。つまり、初期シーケンスは、対応するエントリを発見するためにルックアップテーブル216とともに使用するように変換されないということである。2バイトを持つインデックス308kについて説明しているが、3バイトシーケンス、4バイトシーケンスなどのさまざまな長さのインデックスを使用することができる。図6は、ストリーミング配信されるデータを含めるためヒストリバッファ212でスライディングウィンドウが使用される一実施例600の図である。図3に関連して説明している実施例では、パケット3043がヒストリバッファ212に追加されている。その後、パケット3043を参照するために、ルックアップテーブル216が更新される。しかし、ヒストリバッファ212は、記憶容量が限れている場合がある。したがって、スライディングウィンドウを使用して、ヒストリバッファ212に新規追加データを含める。例えば、ヒストリバッファ212は、図3のブロック302でパケット3043を追加した結果としてシーケンス602を含めることができる。この実施例のヒストリバッファ212は、最大で24バイト格納することができる。したがって、8バイトあるシーケンス604を追加するために、圧縮モジュール116を実行してヒストリバッファ212の先頭から8バイトあるシーケンス606を取り除き、残りのシーケンスをヒストリバッファ212の先頭に移動させる。その後、新しいシーケンス604がヒストリバッファ212の末尾に追加される。シーケンスの移動と追加により、ヒストリバッファ212には、新規追加シーケンス604を含む24バイトあるシーケンス608を有することとなる。ルックアップテーブル216を更新してシーケンス608を反映させるために、ルックアップテーブル216内のハッシュチェーン310k内の各位置において、ヒストリバッファ212内でバイトのそれぞれがシフトされたバイト数に対応する数を減じることができる。例えば、この実施例では、バイトのそれぞれが8バイト分シフトされ、新しいシーケンス604用に空きが作られている。したがって、複数のハッシュチェーン3101~310Kによって記述されるそれぞれの位置は、その位置から8が減じられ、ヒストリバッファ212内の対応するインデックス308kの新しい位置を反映する。ヒストリバッファ212内にもはや含まれていないハッシュチェーン310kのそれぞれから位置を削除するために、0未満の値を持つ任意の位置をハッシュチェーン310kから削除する。図7は、ストリーミングデータの圧縮をさらに最適化する一実施例における手順700を示す流れ図である。図3~4に関して説明した前の手順300、400では、ルックアップテーブル216は、ヒストリバッファ212内の初期シーケンスを効率よく特定するため対応するインデックス308kのヒストリバッファ212内の各位置を記述するように構成されている。ヒストリバッファ212内でマッチングシーケンスを見つけることをさらに最適化して、データ圧縮の効率をさらに高めることができる。例えば、ブロック702では、マッチングシーケンスは、ルックアップテーブルを使用し、またしきい値を使用して見つけられる。さまざまなしきい値が使用できる。例えば、マッチングシーケンスを見つけるための比較は、実行される比較の回数を制限するためヒストリバッファ内の所定の数の位置で実行するようにできる。ストリーミング配信されるデータと比較されるヒストリバッファ内の位置の数を制限することにより、位置のサイズ例えば、バイト数を制限することができる。例えば、すでに説明したように、ヒストリバッファ212内のマッチングシーケンスの位置は、マッチングシーケンスの先頭または末尾とカレントポインタの先頭または末尾との間の相対的位置として記述することができ、これはバックポインタにより記述することができる。したがって、実行される比較の回数を制限することにより、マッチングシーケンスは、カレントポインタのより近くに配置される可能性が高くなる。したがって、この近さゆえに、位置はより小さな値をもつことができ、例えば、使用するバイトをより少なくできる。他の実施例では、所定のしきい値を超える値を持つ位置を考慮しないような、またこの位置に対する値のサイズを制限する役目をすることができるようなしきい値を採用することができる。そのため、探索する位置の数、それぞれの位置を記述する値のサイズ、それぞれの配置されているシーケンスの長さを記述する値のサイズなど、さまざまなしきい値を使用することができる。決定ブロック704で、マッチングシーケンスの位置を記述するバックポインタが最も長い間参照されていないLRUテーブルに含まれているかどうかに関して判別する。LRUテーブルを使用して、最も長い間参照されていないバックポインタを格納することができる。マッチングシーケンスのバックポインタがLRUテーブルに含まれている場合、LRUテーブル内のバックポインタに対応するLRU表現は、マッチングシーケンスのバックポインタを符号化するために使用される。例えば、LRUテーブルは、4つの最も長い間参照されていないバックポインタがLRUテーブルに格納されるように深さ4depthoffourを持つことができる。LRU内のバックポインタはそれぞれ、LRUテーブルへマッピングする対応するLRU表現を有する。したがって、バックポインタがLRUテーブルに含まれている場合、その後ブロック706で、バックポインタをLRUテーブルからのLRU表現を用いて符号化することができる。このようにして、圧縮モジュールは、ストリーミングデータ内に見つけられる追加パターンを処理して、さらにデータを圧縮することができる。例えば、サーバからクライアントにストリーミング配信されるグラフィックデータは、ヒストリバッファ内の類似のオフセットで繰り返されるマッチングシーケンスを含むことができる。したがって、マッチングシーケンスは、マッチングシーケンスの長さおよび位置を含み、その位置はさらにLRU表現を使用することにより圧縮される、表現を使用して圧縮することができる。バックポインタがLRUテーブルに含まれていない場合、次いでブロック708で、バックポインタを図2のハフマンテーブル228を使用して符号化することができる。ハフマン符号化は、さらに圧縮するそれぞれのバックポインタの出現度数を関連付ける出現度数テーブルから始めることができる。それぞれのバックポインタに、そのバックポインタを一意に表す可変長文字列が割り当てられる。例えば、それぞれの可変長文字列に一意的なプレフィクスprefixをもつことができる。その後、それらの文字列をツリー状に配列して、各バックポインタおよび表現をそれぞれ符号化および復号化することができる。バックポインタを符号化するために、バックポインタはツリー内に配置される。バックポインタを含む葉を特定するために使用されるツリーの枝を利用して、バイトシーケンスを符号化する、つまり、バックポインタの表現を与える。例えば、ハフマン符号化に使用されるツリーの各枝には出力アルファベットの記号、例えば、ビット0と1がマークされ、符号化は、ツリーのルートから符号化されるバックポインタまでの経路上の枝マーキングの列挙となる。各表現の復号化は、バックポインタを含むツリーの葉に到達するまで、文字列内のそれぞれの連続する値に基づき、ツリーをその原点から下へ枝を通りツリーの葉へとたどることによって実行される。ブロック710で、マッチングシーケンスの長さも、ハフマンテーブルを使用して符号化される。例えば、図2のハフマンテーブル230を使用して、ヒストリバッファ内のマッチングシーケンスの長さを符号化し、さらにデータを圧縮することができる。長さは、バックポインタについて説明されているとおりに符号化することができる。ブロック712で、マッチングシーケンスは、ヒストリバッファ内のマッチングシーケンスの位置およびマッチングシーケンスの長さを記述するバックポインタを含むタプルとして構成された表現により表される。ブロック714で、コスト関数を使用することにより、マッチングシーケンスに比べて、その表現がより効率的かどうか、例えば、使用されるメモリリソースが格納時により少なく、かつ/または使用される帯域幅がストリーミング配信時により小さいかを判別する。例えば、場合によっては、マッチングシーケンスに使用されるバイト数は、ヒストリバッファ内のマッチングシーケンスの位置および長さを記述する表現よりも少ない。したがって、コスト関数を使用して、表現またはマッチングシーケンス、つまり、データ内のリテラルシーケンスがより効率的かどうかを判別することができる。さまざまなコスト関数が使用できる。例えば、コスト関数は、バックポインタのサイズとマッチングシーケンスの長さのとの積を使用することができる。決定ブロック716で、その表現がより効率的である場合、次いでブロック718で、マッチングシーケンスをその表現で表すことにより圧縮データが形成される。ブロック720で、カレントポインタが更新され、次の初期シーケンスが処理される。例えば、カレントポインタは、マッチングシーケンスの長さずつ増分され、データ内の次のシーケンスについてこの手順を繰り返すことができる。ストリーミング配信するデータを通じてカレントポインタが増分されると、圧縮データは、クライアントにストリーミング配信される。決定ブロック716で、表現があまり効率的でない場合、ブロック722で、マッチングシーケンスはすでに説明したようにハフマンテーブルを使用して表される。ブロック720で、カレントポインタは、マッチングシーケンス内のバイト数ずつ増分され、次のシーケンスについてこの手順が続いて行われる。すでに説明しているように、ハフマンテーブルにより、ストリーミング配信されるデータをさらに圧縮することができる。バックポインタ、長さ、およびリテラルシーケンスをそれぞれ符号化するための3つのハフマンテーブルを説明してきた。他の実施例では、ハフマンテーブルを組み合わせることができる。例えば、図2に示されるように、ハフマンテーブル228を使用して、リテラル232バイトシーケンスおよびバックポインタ234を符号化することができる。圧縮ストリーム内のバックポインタとリテラルシーケンスとを区別するために、バックポインタおよびリテラルシーケンスに、それぞれの一意的なプレフィクスを与えることができ、例えば、それぞれのバックポインタがビット0から始まり、それぞれのリテラルシーケンスがビット1から始まるようにすることができる。他の実施例では、統一インデックスコードunifiedindexcodeを使用して、バックポインタおよびリテラルシーケンスがそれぞれ異なる文字を有するように、リテラルシーケンスとバックポインタの両方を単一のアルファベットに組み合わせることにより、リテラルシーケンスとバックポインタの両方を符号化することができる。すでに説明してあるハフマンテーブルなどの符号化テーブルは、さまざまな方法で提供することができる。例えば、一実施例では、ストリーミング配信されるデータのパケット毎に符号化テーブルを計算する必要がないように、符号化テーブルを圧縮モジュールおよび伸張モジュールが使用するためにあらかじめ構成しておく。これを使用することにより、暗号化プロセスの速度を高めることができる。他の実施例では、符号化テーブルは、所定の間隔で動的に計算される。例えば、符号化テーブルは、所定の数のパケットを受信し符号化テーブルを更新する毎に再計算されるようにしてもよい。図8は、データ圧縮をさらに最適化するためにシーケンスの比較が最適化される一実施例800の図である。前述同様に、サーバ102は、ヒストリバッファ212およびルックアップテーブル216を備える。サーバ102は、圧縮モジュール116を実行して、パケット3043を圧縮する。ヒストリバッファ212の先頭から最初の2バイトが同じである最も右側のシーケンスの先頭までのオフセットを、i1=HASH[HASH_SUMs]と表すことができる。示されている実施例では、sは45に等しく、ヒストリバッファ212の先頭から数えゼロから始める場合、i1=10である。ヒストリバッファ212の先頭から次に最も右側のシーケンスまでの次のオフセットは、i2=NEXT[i1]と表すことができる。図8に示されている実施例では、ハッシュチェーン802k内でi2=NEXT[10]=4である。同様に、ヒストリバッファ212の先頭からの続く各オフセットは、i3=NEXT[i2]などハッシュチェーン802k内で表すことができる。示されている実施例では、45を含むヒストリバッファ212内にはほかにシーケンスがないためi3=0である。圧縮モジュール116は、実行時に、ヒストリバッファ212内の位置16にある45から始まるパケット3043を圧縮する手順を開始することができる。圧縮モジュール116は、まず、ハッシュチェーン802kの位置i1=HASH[HASH_SUM’4’,’5’]=10から初期シーケンス45を含むシーケンスをヒストリバッファ212内で特定することができる。この位置は記憶され、NEXT[16]は10に設定され、HASH[HASH_SUM’4’,’5’]は16に設定される。シーケンスは、最初にそれぞれのシーケンス内で次に続くバイトを比較することによって、現在位置16および位置i110で、一方を他方と比較される。この場合、パケット3043内の第3バイトとパケット3042内の第5バイトとを比較して、一致を見つける。示されている実施例では、HISTORY[103]=’3’およびHISTORY[163]=’6’であるため、次に続くバイトつまり、それぞれのシーケンス内の3番目のバイトは異なる。したがって、期待されるマッチングシーケンスの長さは2のままであり、期待されるマッチングシーケンスの位置は10のままである。その後、圧縮モジュール116は、ルックアップテーブル216から位置i2=NEXT[i1]=4にある、ヒストリバッファ212内の次のシーケンスを特定することができる。i2はゼロに等しくないため、少なくとも2つのバイトの一致がある。それぞれのバイト45に続く次のバイトが前のように比較され、結果的に4バイトの一致が得られる。したがって、期待されるマッチングシーケンスの長さは4に設定され、期待されるマッチングシーケンスの位置は4に設定される。その後、圧縮モジュール116は、ハッシュチェーン802kから位置i3=NEXT[i2]=0にある、ヒストリバッファ212内の他のシーケンスを特定することができる。i3はゼロに等しいため、それはハッシュチェーン802kの末尾であり、他の位置は比較されない。一実施例では、圧縮モジュール116は、ハッシュチェーン802kの末尾を特にはチェックしないことに留意されたい。その代わりに、位置i0図8に示す例では16、NEXT[0]にあるシーケンスはi0に等しく設定される。したがって、ハッシュチェーン802kの末尾iN=NEXT[i{N-1}]=0に到達したときに、チェックされ、圧縮モジュール116はi{N1}=NEXT[iN]=i0に進む。期待されるマッチングシーケンスの長さの後の続く次のバイトを比較することにより、比較速度を改善することができる。例えば、前の実施例では、HISTORY[i0MatchLength]はHISTORY[i0MatchLength]と比較された。ヒストリバッファ212内に比較すべき他のシーケンスがない場合、それぞれの位置にあるシーケンス全体の比較が実行される。つまり、ヒストリバッファ212内のそれぞれの位置にあるそれぞれのシーケンス内で、各バイトについて一方が他方と比較される。シーケンス全体の比較が成功すると、マッチングシーケンスが導かれる。このようにして、ヒストリバッファ212内のシーケンスの比較において、かなりのスピードアップを得ることができる。図9は、システムから受け取ったフィードバックに応じて圧縮が動的にチューニングされる一実施例におけるシステム900の図である。ネットワーク上のサーバ102とクライアント104間の通信は、さまざまなファクタにより変化する場合がある。例えば、クライアント104では、ソフトウェアおよび/またはハードウェアリソースの制限があり、クライアント104でのデータの伸張は、サーバ102での圧縮よりも時間が長くかかる場合がある。他の実施例では、サーバ102は、データを複数のクライアントに供給するので、クライアントは、サーバ102がそれらのクライアントのそれぞれのためにデータを圧縮できる速度よりも、高速にデータを伸張することができる。すでに説明した圧縮パラメータの1つまたは複数をチューニングすることにより、サーバ102とクライアント104のハードウェアおよび/またはソフトウェアリソースならびにそれらを通信可能に接続するネットワーク106のリソースを考慮に入れ、サーバ102とクライアント104間の通信を最適化することができる。例えば、サーバ102がクライアント104に圧縮データを送信するのを待機している場合、サーバ102は、追加圧縮計算を実行して、さらにデータを圧縮することができる。RDP112の圧縮モジュール116のパラメータをチューニングするために、フィードバックを求める。さまざまなファクタをフィードバックとして使用し、一般的なネットワーク特性などの圧縮パラメータをチューニングすることができる。例えば、圧縮モジュール116が、低速なリンクであるためネットワークの逆圧backpressureが生じていることを示すネットワークレイヤからの情報を使用して、さらにデータを圧縮するにはさらに時間がかかることを示すことができる。したがって、逆圧がある場合、最終的な出力サイズの削減のためデータの圧縮にさらに時間をかけるように、圧縮モジュール116を動的にチューニングすることができる。他の実施例では、RDP112は、ヒストリバッファ9041、...、904h、...、904Hの固定プール902を利用することができる。データを送信しなければならない上位レイヤは、プール902にバッファ例えば、バッファ904hを要求すること割り当てること、バッファ904hにデータを埋め込むことデータを圧縮することを含む、その後圧縮されたデータをクライアント104に送信することで動作する。バッファ904hは、バッファのコンテンツが送信されている場合のみ、プール902に戻される、つまり解放される。この技術により、RDP112、より具体的には圧縮モジュール116は、バッファを解放してバッファプールに戻すのに要する時間の長さに基づいて、ネットワーク接続が低速であるか、または高速であるか例えば、帯域幅の大きさ、クライアントが低速であるか、または高速であるか例えば、クライアントがデータを伸張するのに要する時間などに関するフィードバック、つまり逆圧情報backpressureinformationを取得することができる。さらに他の実施例では、プール902のバッファ9041~904Hのどれもが使用できない場合、圧縮にさらに時間をかけるようにさまざまな圧縮しきい値をチューニングすることにより、圧縮モジュール116をいっそう働くように適合させることができる。いったんネットワーク状態が改善されたら、圧縮モジュール116をチューニングして、データの送出がさらに速くなるように圧縮動作回数を減らすこともできる。例えば、ネットワーク106に使用可能な帯域幅がかなりある場合、データ通信にかかる時間を短縮する必要がないため、実行される圧縮動作の回数を減らすことができる。このように、変動するネットワーク状態に基づき実行時に圧縮パラメータが変更されるように動的な技術を採用することができる。他の実施例では、ネットワーク速度の初期測定を利用してパラメータをチューニングし、その後、これらのパラメータをセッション全体で使用する。すでに述べたように、圧縮モジュール116のチューニングに使用されるファクタについては、サーバ102のハードウェアおよび/またはソフトウェアリソースも考慮に入れることできる。例えば、サーバ102上の負荷を考慮に入れることができ例えば、どれくらいのアクティブセッションがサーバ102により提供されているか、図2のプロセッサ202上の負荷など、圧縮の強さを動的にチューニングし、圧縮でCPUをあまり使わないことにより補償することができる。チューニングできる圧縮パラメータの一例として、検索ウィンドウのサイズがある。例えば、検索ウィンドウのサイズを64Kから512Kまででチューニングすることができる。ウィンドウのサイズを大きくすると、相対的圧縮度が高くなるが、実行が遅くなることがある。したがって、ネットワークが低速であるとみなされる場合には、大きなウィンドウに切り換えると都合がよい。圧縮モジュール116をチューニングするために使用されるファクタの他の例では、一致を探すためにトラバースされるハッシュチェーン内のリンクの数をチューニングすることができる。例えば、長いチェーンリンクを辿ると、より長い一致が見つかる確率が高まるが、照合を実行するのに追加のハードウェアおよび/またはソフトウェアリソースのコストがかかる場合がある。圧縮モジュール116をチューニングするために使用されるファクタのさらなる例は、検索を終了するために見つかった最長一致を指定するしきい値である。すでに説明しているように、しきい値を使用することにより、一致を見つけるために実行される検索の回数を制限することができる。このしきい値が大きいほど、より長い一致が見つかる確率が高まり、したがってデータの圧縮がさらに行われる。しかし、この検索を実行する場合、さらに多くの処理リソースが使用される場合もある。さまざまなファクタおよびパラメータについて説明してきたが、他のさまざまなファクタおよびパラメータも、本明細書で説明したように使用することができる。本発明を、構造的特徴および/または方法論的動作に固有の専門用語で説明してきたが、添付の特許請求の範囲で規定する本発明は、説明した特定の機能または動作に必ずしも限定されるものではないことを理解されたい。むしろ、特定の機能および動作は、請求する本発明の例示的な実施形態として開示している。"