(57)【特許請求の範囲】
【請求項１】
入力データストリームを圧縮する方法であって、
入力データストリームを複数のデータブロックへと分割するステップと、
複数のフィンガプリントを計算するステップとを有し、前記複数のフィンガプリントの各フィンガプリントは、前記複数のデータブロックの異なる１つのデータブロックに対応するものであり、前記方法はさらに、
入力データストリームを前記複数のフィンガプリントと比較するステップと、特定のフィンガプリントと入力データストリームの間に合致が生じたときには入力データストリーム内のその合致を符号化するステップと、
符号化した入力データストリームを圧縮データストリームへと圧縮するステップとを有することを特徴とする方法。
【請求項２】
前記入力データストリームは一連の文字からなることを特徴とする請求項１に記載の方法。
【請求項３】
前記入力データストリームを比較するステップの動作は、一連の文字の個々の文字の関数として入力データストリームを順に検索し、その個々の文字のそれぞれの関数として中間フィンガプリントを計算することを特徴とする請求項２に記載の方法。
【請求項４】
前記複数のフィンガプリントと共に前記複数のデータブロックをデータ構造に記憶するステップを更に有することを特徴とする請求項２に記載の方法。
【請求項５】
前記入力データストリームを比較するステップの動作は、
特定のフィンガプリントに合致する一連の文字から最も長い合致シーケンスを識別するステップをさらに有することを特徴とする請求項３に記載の方法。
【請求項６】
前記入力データストリームを比較するステップの動作は、中間フィンガプリントを特定のフィンガプリントと比較することを特徴とする請求項３に記載の方法。
【請求項７】
前記合致を符号化するステップは、最も長い合致シーケンスの入力データストリームにおける開始位置と最も長い合致シーケンスの長さを符号化することを特徴とする請求項５に記載の方法。
【請求項８】
複数の文字を含む入力データストリームを圧縮コードストリームへと処理する方法であって、
入力データストリームを複数のブロックに分割するステップを有し、各ブロックは複数の文字のうち特定の数の文字を含み、前記方法はさらに、
複数のフィンガプリントを計算するステップを有し、前記複数のフィンガプリントの各フィンガプリントは、前記複数のデータブロックの異なる１つのデータブロックに対応するものであり、前記方法はさらに、
特定のフィンガープリントと特定のブロックのいずれかの部分との間に合致が生じたかを判断するために、複数のブロックを複数のフィンガプリントと比較するステップと、
前記合致のそれぞれに対し、入力データストリームにて識別子を符号化するステップとを有し、前記識別子は、少なくとも特定のブロックの合致部分の入力データストリームにおける開始位置と合致部分の長さとを含み、前記方法はさらに、
符号化された入力データストリームを圧縮コードストリームへと圧縮するステップとを有することを特徴とする方法。
【請求項９】
符号化された入力データストリームの圧縮がLempel-Zivコーディング技術に従って行われることを特徴とする請求項１又は８に記載の方法。
【請求項１０】
前記比較するステップの動作が、
ウインドウサイズを選択するステップと、
ウインドウサイズの関数として複数のブロックを検索するステップとを有することを特徴とする請求項８に記載の方法。
【請求項１１】
前記ウインドウサイズは特定の数の文字であることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記複数のブロックを比較するステップの動作は、
ブロックに含まれる特定の数の文字それぞれにおけるブロックに対する中間フィンガプリントを計算するステップと、
中間フィンガプリントを特定のフィンガプリントと比較するステップとを有することを特徴とする請求項１１に記載の方法。
【請求項１３】
前記複数のブロックの各ブロックはブロックサイズが等しいことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記ブロックサイズは１０〜１０００文字の範囲であることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記複数のブロックの検索が、ブロックに含まれる特定の数の文字を順に行われることを特徴とする請求項１２に記載の方法。
【請求項１６】
前記複数のフィンガプリントと共に前記複数のデータブロックをデータ構造に記憶するステップをさらに有し、前記データ構造は、各フィンガプリントをその異なる１つの対応するブロックと共に記憶することを特徴とする請求項８に記載の方法。
【請求項１７】
前記開始位置は入力データストリームにおける文字の位置であり、合致した部分の長さは文字の数であることを特徴とする請求項１６記載の方法。
【請求項１８】
データ圧縮装置であって、
入力データストリームを受信し複数のブロックへと分割する受信器を有し、各ブロックは入力データストリームからの複数の文字の特定の数の文字を含んでおり、さらに、
複数のフィンガプリントを計算するエンコーダを有し、各フィンガプリントは前記複数のブロックの異なる１つのブロックに対応するものであり、前記エンコーダは、複数のブロックを複数のフィンガプリントと比較し、特定のフィンガプリントと特定のブロックのいずれかの部分の間で合致が生じたかを判断し、そして前記合致のそれぞれに対し、入力データストリームにおける識別子を符号化するものであり、前記装置はさらに、
符号化された入力データストリームを圧縮コードストリームへと圧縮するコンプレッサを有することを特徴とするデータ圧縮装置。
【請求項１９】
デジタルデータストリームを圧縮データ形式で記憶するデータ記憶システムであって、
デジタルデートストリームを複数のデータブロックへと分割する手段を有し、各ブロックは複数の文字を有するものであり、前記システムはさらに、
複数のフィンガプリントを計算する手段を有し、各フィンガプリントは、前記複数のデータブロックの異なる１つのデータブロックに対応するものであり、前記システムはさらに、
複数のブロックを検索する手段と、
ブロックの複数の文字の各文字における各ブロックに対する中間フィンガプリントを計算する手段と、
中間フィンガプリントを複数のフィンガプリントの特定のフィンガプリントと比較する手段と、
特定のフィンガプリントと中間フィンガプリントの間で合致が生じたときには前記合致をデジタルデータストレームにおいて符号化する手段と、
符号化されたデジタルデータストリームを圧縮データ形式に圧縮する手段とを有することを特徴とするデータ記録システム。
【請求項２０】
圧縮デジタル信号を処理する装置であって、前記圧縮デジタル信号は、入力デジタルデータストリームを複数のデータブロックへと分割し、それぞれが複数のデータブロックの異なる１つのデータブロックに対応する複数のフィンガプリントを計算し、入力デジタルデータストリームを複数のフィンガプリントと比較し、特定のフィンガプリントと入力デジタルデータストリームの間で合致が生じたときには入力デジタルデータストリームにおいて前記合致を符号化し、符号化された入力デジタルデータストリームを圧縮デジタル信号に圧縮し、そして前記圧縮デジタル信号を通信チャネルへ供給することにより生成されたものであり、前記装置は、
通信チャネルから圧縮デジタル信号を受信する受信器と、
受信した圧縮デジタル信号を脱圧縮し、その脱圧縮したデジタル信号から入力デジタルデータストリームを回復するデコンプレッサとを有することを特徴とする圧縮デジタル信号を処理する装置。
【請求項２１】
入力データストリームを圧縮コードストリームへと処理するステップを有し、前記入力データストリームは複数の文字を含み、さらに、
入力データストリームを複数のブロックへと分割するステップとを有し、各ブロックは複数の文字の特定の数の文字を含み、さらに、
複数のフィンガプリントを計算するステップを有し、各フィンガプリントは、前記複数のブロックの異なる１つのブロックに対応し、さらに、
複数のブロックを複数のフィンガプリントと比較するステップと、
特定のフィンガプリントと特定のブロックのいずれかの部分の間に合致が生じるかどうかを判断するステップと、
前記合致のそれぞれに対し、入力データストリームにおけるその合致の識別子を符号化するステップとを有し、前記識別子は、特定のブロックの合致した部分の入力データストリームにおける開始位置と合致した部分の長さとを含み、そして、
符号化された入力データストリームを圧縮コードストリームへと圧縮するステップとを有する方法をコンピュータに実行させるプログラムを記録した、コンピュータが読み取り可能な媒体。
【請求項２２】
それぞれが複数の文字からなる複数のブロックへと入力データストリームを分割するステップと、
それぞれが前記複数のブロックの異なる１つのブロックに対応する複数のフィンガプリントを計算するステップと、
ブロックの複数の文字の各文字の関数として入力ストリームを検索するステップと、
ブロックの各文字におけるブロックに対する中間フィンガプリントを計算するステップと、
中間フィンガプリントを複数のフィンガプリントと比較するステップと、
複数のフィンガプリントの特定のフィンガプリントと中間フィンガプリントの間で合致が生じたかを判断するステップと、
前記合致のぞれぞれ対し、ブロックの合致した部分の入力データストリームの開始位置と合致した部分の長さとを含む、入力データストリーム内の識別子を符号化するステップと、
符号化された入力データストリームを圧縮コードストリームへと圧縮して記録信号を得るステップとを有する処理に従って生成された前記記録信号を記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ記憶および通信システムに関し、特に、それらシステムの容量および利用を改善することに関する。
【０００２】
【従来の技術】
従来のデータ圧縮技術およびシステムはデジタルデータストリームを圧縮コードストリームへと符号化し、圧縮コードストリームを対応する元のデータストリームへとデコードして戻す。ここでコードストリームを「圧縮」としているが、それは、コードストリームが通常、元のデータストリームに含まれる符号の数よりも少ない数のコードであるからである。このような小さいコードは元のデータよりも少ない量のメモリーに記憶することができる。
【０００３】
また、圧縮コードストリームは、圧縮されていない元のデータよりも短い時間で通信システム（例えば、有線、無線、光ファイバ通信システム）にて送信することができる。今日の通信ネットワークにおいて、コンテンツ交換の量が相当に増大しており、データ送信および記憶容量の必要性が今までかつてないほど増えている。このように、データ圧縮は現代の送信プロトコルおよび通信ネットワークにおいて重要な役割を担っている。
【０００４】
データ圧縮に有用な２つのクラスの圧縮技術は、周知のように、いわゆる特殊用途圧縮と汎用圧縮である。特殊用途圧縮技術は特殊な種類のデータを圧縮するために設計され、実装するのに比較的低コストであることが多い。例えば、周知な特殊用途圧縮技術として、ランレングス符号化、ゼロサプレッション符号化、ヌル圧縮符号化、パターン置き換えの技術がある。
【０００５】
これら技術により、一般に、比較的小さな圧縮比となる。なぜなら、一般的な特性および冗長性を有するデータを通常圧縮するからである。圧縮比とは、元のデータの長さに対しての圧縮コードの長さの測定値である。しかし、特殊用途圧縮技術はより一般的性質のデータ（共通な性質を多く有さないようなデータ等）を圧縮するのにあまり有効でないことが多い。
【０００６】
対照的に、汎用圧縮技術は一種類のデータを特別に圧縮するのに設計されてはおらず、実際の圧縮プロセスの際に異なる種類のデータに適合することが多い。最も有名で有用な汎用圧縮技術は、Ｌｅｍｐｅｌ−Ｚｉｖコーディングとして知られる。Ｊ．ＺｉｖとＡ．Ｌｅｍｐｅｌによって開発された一連のアルゴリズムから派生している。これについて、文献、Ｚｉｖ  ｅｔ  ａｌ．，”Ａ  Ｕｎｉｖｅｒｓａｌ  Ａｌｇｏｒｉｔｈｍｓ  ｆｏｒ  Ｓｅｑｕｅｎｔｉａｌ  Ｄａｔａ  Ｃｏｍｐｒｅｓｓｉｏｎ”，  ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｈｅｏｒｙ，  ＩＴ−２３（３）：３３７−３４３，  Ｍａｙ  １９７７（ＬＺ１アルゴリズムを記載している）、Ｚｉｖ  ｅｔ  ａｌ．，”Ｃｏｍｐｒｅｓｓｉｏｎ  ｏｆ  Ｉｎｄｉｖｉｄｕａｌ  Ｓｅｑｕｅｎｃｅｓ  Ｖｉａ  Ｖａｒｉａｂｌｅ−Ｒａｔｅ  Ｃｏｄｉｎｇ”，  ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ，ＩＴ−２４（５）：５３０−５３６，  Ｓｅｐｔｅｍｂｅｒ  １９７８（ＬＺ２アルゴリズムを記載している）に記載されている。これらＬＺ１、ＬＺ２データ圧縮方式は周知であり詳細には説明しない。
【０００７】
ＬＺ１（ＬＺ７７とも呼ばれる）データ圧縮プロセスは繰り返された文字シーケンス（本明細書において、文字（ｃｈａｒａｃｔｅｒ）とはビット群をいい言語としての文字を意味するのではない）は、そのシーケンス（マッチングシーケンス）の前の出現を参照することによって置き換えることができるという原理に基づいている。この参照（例えば、ポインタ）は通常、前の出現の位置（例えば、繰り返しシーケンスの開始からのオフセットバイト）、および繰り返す文字の数（マッチドレングス）を示す情報を含む。この参照は通常、伝統的なＬＺ１コーディングに従うと「＜Ｏｆｆｓｅｔ，  ｌｅｎｇｔｈ＞」として表されている。
【０００８】
対照的に、ＬＺ２（ＬＺ７８としても知られる）圧縮は、圧縮の際に作られるルックアップテーブルないし辞書を適応的に成長させることに基づいて、入力データ文字のストリームを符号化値へとパースする（ｐａｒｓｅ）。すなわち、ＬＺ２は、ＬＺ１コーディングのようにバイト境界や長さにおいて一致性を見つけたりはせず、辞書のワードがソースストリング（文字列）と一致すれば、新しいワードが辞書に加えられる。この辞書はその一致したワードとその後のソースストリングバイトからなる。ＬＺ２コーディングに従うと、一致は辞書内のワードへのポインタないしインデックスとして符号化される。
【０００９】
上述のように、ＬＺ１およびＬＺ２アルゴリズムが用いる基本的な原理から派生した圧縮方式は多い。例えば、Ｔｅｒｒｙ  Ａ．ＷｅｌｃｈはＬＺ２コーディングを改善して周知のＬｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ（ＬＺＷ）圧縮プロセスを作った。これについて、文献、Ｔ．Ａ．Ｗｅｌｃｈ，”Ａ  Ｔｅｃｈｎｉｑｕｅ  ｆｏｒ  Ｈｉｇｈ  ｐｅｒｆｏｒｍａｎｃｅ  Ｄａｔａ  Ｃｏｍｐｒｅｓｓｉｏｎ”，ＩＥＥＥ  Ｃｏｍｐｕｔｅｒ，ｐｐ．８−１９，Ｊｕｎｅ  １９８４および米国特許第４５５８３０２明細書（１９８５年１２月１０日発行）を参照するとよい。
【００１０】
これらＬＺ２およびＬＺＷの両方の圧縮技術は入力文字のストリングを固定長コードへとマッピングするいわゆるストリングテーブルを生成し利用する。具体的には、これら圧縮技術は文字ストリームを順に検索しテーブル（辞書）に前に記憶した最長のストリングとマッチ（合致）する遭遇したシンボルのシーケンスに基づいてコードを生成することにより、データ文字のストリームを圧縮されたコードストリームへと圧縮する。各マッチがなされコードシンボルが生成されるに従い、このプロセスは辞書に新しいストリングエントリーをも記憶する。これは、データストリームにおけるマッチしたシーケンスに加えて、データストリームにおいて遭遇する次の文字シンボルからなる。
【００１１】
上述のように、Ｌｅｍｐｅｌ−Ｚｉｖコーディングの要点は、元のデータストリーム（例えば、送信されるドキュメント）において繰り返されるストリングやサブストリングを見つけることである。圧縮されるドキュメントにおける繰り返されたフレーズは元のデータストリームにおいて前に出現した場所へのポインタによって置き換えられる。従って、この方法で圧縮されるデータ（例えば、テキスト）をデコードすることには、ポインタが指すすでにデコードしたテキストでポインタを置き換えることを必要とする。
【００１２】
周知のように、Ｌｅｍｐｅｌ−Ｚｉｖコーディングを用いる際に設計上主に考慮することとして、ポインタがどれくらい戻るか制限を設定し、その制限をどのようにするか決めることがある。別の設計上に考慮することとして所望の制限内のどのサブストリングがポインタのターゲットとするかということがある。すなわち、前のテキストへのポインタのリーチの制限がなくなったり、いわゆるグローイングウィンドウ（ｇｒｏｗｉｎｇ  ｗｉｎｄｏｗ）、あるいは前の「Ｎ」文字の固定サイズのウィンドウに制限される。ここで、Ｎは通常、数千文字（例えば、３キロバイト）の範囲である。
【００１３】
このコーディングに従うと、ストリングの繰り返しは、両方のストリングがウィンドウに出現した場合にのみ発見され圧縮される。このようなＬｅｍｐｅｌ−Ｚｉｖコーディングの設計時には、速さ、メモリー条件、圧縮比の間で妥協して決められる。ウィンドウをスライドすることには少なくとも１つの欠点がある。ウィンドウをスライドさせる方式は、入力テキストにおいて遠くに出現するストリング（例えば、１００００文字分）を見つけることはできない。
【００１４】
【発明が解決しようとする課題】
上述のようなＬＺ１、ＬＺ２、ＬＺＷ圧縮方式のような従来の圧縮方式は有効なデータ圧縮を提供しているが、記憶装置の条件や伝送時間を減らすために更に大きく圧縮する方式が望まれている。
【００１５】
【課題を解決するための手段】
本発明は、比較的低い圧縮比を実現する方法および装置を提供する。これは、圧縮プロセス（例えば、いずれかのＬｅｍｐｅｌ−Ｚｉｖ圧縮方式）を適用する前に入力データの初期評価として入力データストリームのより長い履歴およびより長いコモンストリングを用いることを我々が認識したことに基づいている。すなわち、通常の圧縮プロセスが所望の圧縮を行うために比較的短い（最も最近の数キロバイト）入力データの履歴を用いるが、より長いコモンストリングシーケンスを用いることとより長い履歴を用いることとが組み合わさって、圧縮効率を増加できることを我々は認識した。これは特に、繰り返す長いストリングを多く有する長い入力ストリームを圧縮する際に有効である。
【００１６】
本発明に従うと、摘出した長コモンストリングに対してストリングマッチングを適用することになり入力データをプリプロセス（前処理）する。好ましい実施例に従うと、入力データは、個々のブロックが均等なサイズ（線文字長）を有するように一連のブロックへと分割される。また、好ましい実施例に従うと、各ブロックに対していわゆるフィンガプリント（指紋）が計算され記憶される。フィンガプリントは、大きいテキストストリングの比較的小さいシグネチャーである。例えば、千文字のストリングが３２ビット長のフィンガプリントへとマッピングされる。従って、同一のストリングは常に同じフィンガプリントを有する。また、等しくないストリングはほとんど常に等しくないフィンガプリントを有する（特定の確率ファクタ内で）。
【００１７】
本発明に従うと、入力データストリームが検索（traverse）され、入力ストリームの特定の文字セットから計算した（文字毎ベースで）中間フィンガプリントと、前に計算し記憶したフィンガプリントとの間で比較がなされる。好ましい実施例に従うと、入力ストリームは、均等なブロックサイズを有するスライドウィンドウの関数として検索され、中間フィンガプリントは現在の文字ウィンドウから計算され、前に記憶したフィンガプリントと比較される。
【００１８】
好ましい実施例に従い、フィンガプリントの間にマッチを検出すると、入力ストリームは、検出したマッチの関数として決められた識別子とともに符号化される。符号化された識別子は、元の入力ストリームにおけるマッチングストリングの開始位置およびストリング長を含む。その後に、好ましい実施例に従うと、前処理され符号化された入力ストリームに対し更にＬｅｍｐｅｌ−Ｚｉｖ圧縮を用いて圧縮がなされる。
【００１９】
本発明に従うと、全体の記憶容量の条件を余り大きくせずに、長いコモンストリングを識別し、入力データの大きな履歴を調べることができる。本発明に従って、様々な圧縮方法によって大きな圧縮比を実現することができる。すなわち、本発明の原理はいずれの特定の圧縮方式には依存せず、広い範囲の圧縮方式において本発明の様々な原理を用いる利点を発揮することができる。
【００２０】
ストリングマッチングメカニズムとしてフィンガプリントを用いることは新しくはない。テキスト処理システムにおけるストリングマッチングに対してフィンガプリントは用いられている。具体的には、テキストファイルにおいて長いコモンストリングを検索する際に用いられている。例えば、文献、Ｒ．Ｍ．Ｋａｒｐ  ａｎｄ  Ｍ．Ｏ．Ｒａｂｉｎ，”Ｅｆｆｉｃｉｅｎｔ  Ｒａｎｄｏｍｉｚｅｄ  Ｐａｔｔｅｒｎ−Ｍａｔｃｈｉｎｇ  Ａｌｇｏｒｉｔｈｍｓ”，ＩＢＭＪ．Ｒｅｓ．Ｄｅｖｅｌｏｐ．，Ｖｏｌ．３１，Ｎｏ．２，ｐｐ．２４９−２６０，  Ｍａｒｃｈ  １９８７は、ストリング検索の際にフィンガプリントを用いることを記載している。しかし、我々はフィンガプリントを優雅な圧縮ツールとして導入できることを認識した。これにより、全体の記憶容量条件を余り大きくせずに、繰り返す長いストリングを多数有する。大きい入力データストリームに対してデータ圧縮を改善することができる。
【００２１】
【発明の実施の形態】
圧縮プロセス（例えば、Ｌｅｍｐｅｌ−Ｚｉｖ圧縮方式のいずれか）を適用する前に入力データの初期評価として入力データストリームのより長い履歴およびより長いコモンストリングを用いることの認識に基づいて、本発明は比較的圧縮比を実現する方法および装置を提供する。通常の圧縮プロセスが所望の圧縮をするために入力データの比較的短い履歴（最も最近のバイト群）を用いるが我々はより長いコモンストリングシーケンスと共により長い履歴を用いることにより、特に、繰り返す長いストリングを多数有するより長い入力ストリーム（例えば、大規模データベース）を圧縮する際に、圧縮効率を増加することができることを認識した。
【００２２】
本発明は、これら方法を実践する方法および装置の形態で実現することができる。また本発明は、ＦＤ（ｆｌｏｐｐｙ  ｄｉｓｋｅｔｔｅ）、ＣＤ−ＲＯＭ、ハードディスクドライブ、機械が読み取り可能な記憶媒体のような実体的な媒体に実装されるプログラムコードの形態にて実現することもできる。この場合、プログラムコードが機械（例えば、コンピュータ）へとロードされ機械によって実行されると、その機械が本発明を実行する装置となる。また、本発明はプログラムコードの形態にて実装することができ、例えば、機械へとロードされおよび／または機械によって実行され、あるいは電線、ケーブリング、光ファイバ、電磁放射のような何らかの伝送媒体にて送信されるようなプログラムコードの形態にて実装される。プログラムコード汎用プロセッサに実装された場合に、プログラムコードセグメントがプロセッサと組合わさって、特定のロジック回路と類似するように動作するユニークなデバイスを与える。
【００２３】
図１は、本発明に従ってデータを圧縮したり脱圧縮したりするためのシステム１００のブロック図である。システム１００は、ほんの少しだけ名前を揚げるのに伝送媒体（例えば、有線、無線、光ファイバ等）上に情報を送信するのに用いられる。また、システム１００は、例えば、コンピュータのディスクドライブのような磁気媒体、ＣＤ−ＲＯＭのような光学的に読み取り可能な媒体、インターネット上の媒体へと情報を記録し、またはそれらから情報を読み取るのにも有用である。
【００２４】
従って、本発明に従って圧縮されたデータを磁気ディスクドライブのような磁気媒体、ＣＤ−ＲＯＭのような光記録可能な媒体上に記録することができる。図１において、入力データストリーム１０５（例えば、テスト）が入力データエンコーダ１１０に供給される。下で詳細に述べるように、本発明に従う入力データエンコーダ１１０は、抽出する長いコモンストリングに対してストリングマッチング技術を適用することにより本発明に従って入力データストリームをプリプロセスおよび符号化する。この符号化プロセスに関連する本発明の多くの原理は下で図２に示した例を特に参照してより広く説明する。
【００２５】
図１に戻ると、本発明に従って作られた符号化入力データストリーム１１５はコンプレッサ１２０に渡される。好ましい実施例に従うコンプレッサ１２０は、符号化入力データストリーム１１５を圧縮データ１２５に圧縮するのにＬｅｍｐｅｌ−Ｚｉｖ圧縮を、具体的には、ＬＺ７７コーディングを適用する。ここで、上述のように本発明に従って符号化入力データストリーム１１５を圧縮するのにいずれのＬｅｍｐｅｌ−Ｚｉｖタイプの圧縮をも有効に用いて本発明の原理の利点を実現することができることに留意されたい。
【００２６】
次に圧縮データ１２５はチャネルエンコーダ１３０により符号化されチャネル符号化された情報１３５を作る。チャネル符号化により圧縮された情報に対し情報を加え、エラー検出やデータ読み取りプロセスにおける訂正を可能にする。伝統的なチャネル符号化技術としては、各シンボルが１もしくは複数のデータビットで表されるシンボルのシーケンスを符号化する周知のＲｅｅｄ−Ｓｏｌｏｍｏｎ符号化がある。次にこれらシンボルは変調エンコーダ１４０により変調符号化され、変調されたデータストリーム１４５を作る。これは、伝送チャネルを通って送信されるかあるいは媒体１５０上に記録されるチャネルシーケンスを定める。
【００２７】
ノイズや干渉は多くの場合、データストリームの伝送や記録時にチャネル／媒体１５０にて投入される。従って、変調デコーダ１５５、チャネルデコーダ１６０はノイズとともに変調データストリーム１４５を受信し、周知な方法で、チャネルエンコーダ１３０、変調エンコーダ１４０の符号化プロセスをそれぞれ逆にたどる。チャネルデコーダ１６０からのデータストリームはコンプレッサ１２０が生成する圧縮データ１２５に対応する。図７、１１に関連して詳細に説明するように本発明に従って、このデータストリームはデコンプレッサ１６５により脱圧縮され、データデコーダ１７０によりデコードされ、出力データストリーム１７５を作る。
【００２８】
本発明の多くの原理は、圧縮による相当な削減や伝送効率を実現することに関連している。図２は、本発明に従ってデータを圧縮する動作を示す流れ図であり、図１のシステムにて有用である。入力データストリーム（例えば、テキストファイル）が受信される（２１０）。特定の圧縮ブロックサイズ「ｂ」が選択される（２２０）。このｂは特定の文字の数である。好ましい実施例に従って、ｂは２０〜１０００文字の範囲で選択される。入力データストリームはサイズｂのブロック群に分割される（２３０）。その後に、本発明に従って、ブロック群の各ブロックに対しフィンガプリントが計算され格納される（２４０）。
【００２９】
好ましい実施例に従って、文献、Ｋａｒｐ  ｅｔ  ａｌ．，  ｓｕｐｒａ．  に記載された技術に従ってフィンガプリントが計算される。カープらはストリング検索を支援するのにフィンガプリントを元々用いた。すなわち、長さｎのストリングが長さｍのサーチパターンを含むかどうかである。カープらはサーチパターンのｍの文字をポリノミアルモジュロ（多項式法処理）した大きな素数として解釈した。従って、得られるフィンガプリントは、例えば、３２ビットワードとして格納することができる。カープの技術は入力ストリングを走査し、長さｍのｎ−ｍ＋１のサブストリングのそれぞれに対し同じフィンガプリントを計算する。もしこれらフィンガプリントがマッチしなければ、そのサブストリングはパターンにマッチしないという結論を出す。もしそれらフィンガプリントがマッチすれば、そのサブストリングは実際にはパターンにマッチするかどうかの更なるチェックを行う。
【００３０】
カープらの技術は以下のようなフィンガプリントの幾つかの有用な特性を証明した。すなわち、
（１）フィンガプリントを迅速に計算することができること。すなわち、フィンガプリントをＯ（ｍ）の時間で初期化することができ、Ｏ（１）の時間である位置をスライドすることにより更新することができること。
（２）フィンガプリントは偽のマッチを得ること。すなわち、等しくないストリングは等しくないフィンガプリントを持つことが非常に確かであること。（２つの等しくないストリングが同じ３２ビットフィンガプリントを有する確率は約２−３２である。）
（３）大きな素数をランダムで選ぶことができ、テキストストリング検索においてランダム化したアルゴリスムを得ることができること。
【００３１】
我々は、繰り返しストリングを有する非常に大きな入力データストリームに対し増強したデータ圧縮を行うようなエレガントな圧縮ツールを導入することによってフィンガプリントを用いることを認識した。本発明に従うと、全体の記憶容量の必要条件の余り増加させないで長いコモンストリングを識別して入力データの大きな履歴を調べることができる。すなわち、本発明に従って、異なるストリングの間の相関を認識するデータ圧縮構成を用いる。具体的には、特定のテキストストリングの第２出現を繰り返しとして認識し、この第２出現を符号化した第１ストリングへの参照によって置き換える。従って、本発明に従うと、多くの圧縮方法に対し大きな圧縮比を実現することができる。
【００３２】
特定の圧縮方式におけるストリング繰り返しの認識は知られている。例えば、文献、Ｊ．  Ｇ．  Ｃｌｅａｒｙ  ｅｔ  ａｌ．，  ”Ｕｎｂｏｕｎｄｅｄ  ｌｅｎｇｔｈ  ｃｏｎｔｅｘｔｓ  ｆｏｒ  ＰＰＭ”，  Ｃｏｍｐｕｔｅｒ  Ｊｏｕｒｎａｌ  ４０，２／３，  ｐｐ．  ６７−７５，  １９９７、  Ｃ．  Ｇ．  Ｎｅｖｉｌｌｅ−Ｍａｎｎｉｎｇ  ｅｔ  ａｌ．，  ”Ａ  ｓｐａｃｅ−ｅｃｏｎｏｍｉｃａｌ  ｓｕｆｆｉｘ  ｔｒｅｅ  ｃｏｎｓｔｒｕｃｔｉｏｎ  ａｌｇｏｒｉｔｈｍ”，  Ｊｏｕｒｎａｌ  ｏｆ  Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ  Ｒｅｓｅａｒｃｈ，  ｐｐ．  ６７−８２，  Ｓｅｐｔｅｍｂｅｒ  １９９７にはストリング繰り返しを認識している特定の圧縮方式を記載している。しかし、本発明とは対照的にこれらの従来の方式は大きな量のメモリーを必要とする。すなわち、フィンガプリントを用いない方法において、ｎ文字のファイルを処理をするのに約ｎのワードを主メモリーに必要とする。下で議論するように、記憶条件の必要条件を激的に増加せずに本発明に従うと大きな圧縮比を実現することができる。
【００３３】
図２において、好ましい実施例に従うと、各ブロックに対し計算したフィンガプリントを格納する（２４０）。入力ストリームの各ブロック境界にてフィンガプリントが記録される。また、プライマリデータ構造がｂバイトの重なり合わないブロックのそれぞれのフィンガプリントを記憶する。すなわち、好ましい実施例に従うと、各バイト１．．．ｂ、ｂ＋１．．．２ｂ、２ｂ＋１．．．３ｂ等々のようにフィンガプリントが記憶される。
【００３４】
好ましい実施例に従うと、約ｎ／ｂのフィンガプリントが記憶される。このｎは上述のストリングの長さである。本発明に従うと、元の入力ストリームの少ない割合のみが記憶され、従って、記憶装置の必要条件を低く押さえることができる。また、好ましい実施例に従うと、入力データストリームにおけるそのシーケンスの位置を表す正数と共にお互いをハッシュテーブル（周知なデータ構造）にてフィンガプリントを記憶し表現する。
【００３５】
図３は、図２の動作によって計算されたフィンガプリントを記憶するデータ構造３００を示す。データ構造３００は入力ストリームの各ブロックを記憶する。例えば、ブロック１〜ｍはブロック３０５〜３２５として示した。それに加え、各ブロックに対し、計算したフィンガプリントを記憶する。例えば、図３においてＦＰ１〜ＦＰｍをフィンガプリント３３０〜３５０として示した。更に、下で述べるように、入力データストリーム（データ構成３００）を検索するのにスライディングウィンドウ３５５を用い、上述のマッチを検出するのに現在の文字のウィンドウを記憶されたフィンガプリントと比較する。
【００３６】
より詳細には、図２において、入力データストリームを検索し、入力文字と記憶されたフィンガプリントの間に比較を行い（２５０）、マッチを検出する（２６０）。すなわち、入力データストリームを検索するのにスライディングウィンドウ（例えば、スライディングウィンドウ３５５）を用い、現在の文字のウィンドウに対していわゆる「中間(interim)」フィンガプリントを計算する。これは図においては現在の文字のウィンドウで文字毎のベースで行われている。
【００３７】
これら現在の文字のウィンドウにわたって計算される中間フィンガプリントはマッチを検出するために格納フィンガプリントと比較される。具体的には、入力テキストを走査するに従って、コモンフィンガプリントを見つけるためにハッシュテーブルが用いられ、コモンストリングの位置を判断する。もしマッチが出現すれば、シーケンス「＜ｓｔａｒｔ，  ｌｅｎｇｔｈ＞」を用いてそのマッチを符号化する（２７０）。ここで、ｓｔａｒｔは初期位置であり、ｌｅｎｇｔｈはコモンシーケンスのサイズである。
【００３８】
例えば、以下の入力データストリームを考えてみる。
Ｔｈｅ  Ｃｏｎｓｔｉｔｕｔｉｏｎ  ｏｆ  ｔｈｅ  Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ，  ＰＲＥＡＭＢＬＥ  Ｗｅ，  ｔｈｅ  ｐｅｏｐｌｅ  ｏｆ  ｔｈｅ  Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ，  ｉｎ  ｏｒｄｅｒ  ｔｏ  ｆｏｒｍ  ａ  ｍｏｒｅ  ｐｅｒｆｅｃｔ  ｕｎｉｏｎ．．．
上述のような本発明の原理を適用すると、以下の符号化データストリームの結果を得ることができる。
Ｔｈｅ  Ｃｏｎｓｔｉｔｕｔｉｏｎ  ｏｆ  ｔｈｅ  Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ，  ＰＲＥＡＭＢＬＥ  Ｗｅ，  ｔｈｅ  ｐｅｏｐｌｅ  ＜１６，２１＞，  ｉｎ  ｏｒｄｅｒ  ｔｏ  ｆｏｒｍ  ａ  ｍｏｒｅ  ｐｅｒｆｅｃｔ  ｕｎｉｏｎ．．．
この符号化データストリームから、繰り返しストリングは”ｔｈｅ  ｐｅｏｐｌｅ  ｏｆ  ｔｈｅ  Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ”は上述のように本発明の”＜ｓｔａｒｔ，  ｌｅｎｇｔｈ＞”シーケンスフォーマットを用いる識別子で符号化されていることがわかる。
【００３９】
好ましい実施例に従うと、マッチするフィンガプリントを有するブロックがいわゆる偽マッチではないことを確実にするため、可能な限りであるが長さがｂ−１文字よりも長くない範囲で、（入力データストリームにわたって）逆方向および順方向でマッチの拡張を行う。もし幾つかのブロックが現フィンガプリントとマッチすれば、そのようなブロックの中での最大のマッチが本発明に従って符号化される。
【００４０】
フィンガプリントに対しての入力文字（中間フィンガプリント）の比較は入力ストリームの終わりに到達するまで継続する（２８０）。その後に、符号化データストリーム（本発明に従って符号化された元の入力データストリーム）が周知の圧縮アルゴリズムのいずれか（例えば、Ｌｅｍｐｅｌ−Ｚｉｖ圧縮）を圧縮される（２９０）。
【００４１】
以下の準コードは、上述のような本発明の原理に従うフィンガプリントの比較および符号化を記したものである。変数ｆｐは、フィンガプリントを表し、関数ｃｈｅｃｋｆｏｒｍａｔｃｈはハッシュテーブルにおけるフィンガプリントをルックアップし、マッチを見つければそのマッチを符号化する。
0003634711.tif 000002
【００４２】
上の準コードは、本発明を実装するプロセッサにおける実行をするために、多くのプログラム（例えば、Ｃ言語プログラム）にて開発するのに用いることができる。例えば、図９〜１０は、本発明に従ってデータ圧縮するＣ言語ソースプログラム９００を示す。ソースプログラム９００は、このソースコードプログラム９００全体で用いる特定のデータ型、変数、データ構造を規定するプログラム命令を含むプログラムソースコード部分９１０を含む。
【００４３】
プログラムソースコード部分９２０は、上述のように本発明に従ってストリングマッチング動作を実装するプログラム命令を含む。プログラムソースコード部分９３０は、上述のように本発明に従って計算されたフィンガプリントを格納するのに用いるハッシュテーブルデータ構造を定め構築するのを支援するプログラム命令である。プログラムソースコード部分９４０、９５０（図１０）は、上述のように本発明に従って符号化データファイルを作るために圧縮を完成させるプログラム命令を含む。
【００４４】
Ｃ言語ソースプログラム９００は、生来的に例示的であり本発明を理解するのを支援するために表現してある。本発明を具現化する他のプログラムを本発明の範囲から外れずに開発することは当業者であればできるであろう。
【００４５】
上述の本発明の多くの原理を更に説明するため、図４は、一連の短い非圧縮入力データストリーム４００を、本発明に従って符号化された対応する一連の符号化出力データストリーム４１０と共に示してある。図４を調べることにより、入力データストリーム４２０〜４５０はそれぞれ、符号化出力４６０〜４９０それぞれに示すようにマッチングストリングの符号化された表現によって処理されている。
【００４６】
また、図５、６には本発明を更に説明するために、大きな入力データファイル、具体的には、アメリカ合衆国の憲法に対する本発明の原理の適用を示している。図５は、憲法の選択部分からなる入力データファイル５００を示している。本発明に従う憲法のテキストの圧縮は、同じ長いストリングが頻繁に現れることを考えると特に本発明の利点を発揮できる。例えば、入力データファイル５００のテキスト部分５１０、５２０、５３０は幾つかの長い繰り返すストリングを含む。
【００４７】
従って、上述の本発明の多くの原理を適用すると、図６に示した符号化データファイル６００を得る。６００は符号化部分６１０、６２０、６３０を有し、これらそれぞれは入力データファイル５００のテキスト部分５１０、５２０、５３０に対応する。符号化部分６１０、６２０、６３０はそれぞれ、エンコーディング（例えば、エンコーディング６３５−６９０）を含む。これらは、本発明に従って導かれ、ブロックサイズ＝２０を用い、更に圧縮比を増しデータ伝送レートをより効率的にするために更に圧縮させることができる。
【００４８】
例えば、エンコーディング６３５は、文字位置３９１に始まる４７文字のマッチングシーケンス（すなわち、マッチングストリング）が検出され符号化されたことを示す。同様に、例えば、エンコーディング６７５は、文字位置２４３９に始まる１０３文字のマッチングシーケンスが検出され符号化されたことを示す。
【００４９】
圧縮プロセスを適用する前に入力データの初期評価（プリプロセス）においてフィンガプリントを用いることを認識することにより、入力データストリームの長い履歴および長いコモンストリングを用いることに基づいて比較的低い圧縮比を実現することができる。重要なことに、本発明は記憶装置の必要条件を余り増加させず、いずれの特定の圧縮技術にも依存しない。すなわち、本発明は、相当な圧縮比を実現する多様な周知の圧縮アルゴリズムを用い、記憶装置の必要条件や転送時間を減らすことができる。
【００５０】
圧縮テスト結果を記す前に、本発明を用いて得られる符号化データファイルの脱圧縮を議論する。図７は、本発明の更なる原理に従ってデータを脱圧縮する動作７００の流れ図である。本発明による符号化データファイル（例えば、符号化データファイル６００）から、この態様では文字毎のベースで個々の文字「ｃ」を取り出す（７１０）。
【００５１】
特定の文字ｃがシンボル「＜」とマッチするかどうかの判断を行う（７２０）。マッチしなければ、脱圧縮プロセスに従って出力ファイルへと文字ｃが書き込まれ（７３０）、符号化データファイルから次の文字が取り出される。マッチすれば、符号化データファイルから次の文字が取り出される（７４０）。再び、特定の文字ｃがシンボル「＜」とマッチするかどうかの判断をする（７５０）。マッチすれば、出力ファイルにシンボル「＜」が書き込まれ（７６０）、次の文字が取り出される。マッチしなければ、上で詳細に示した「＜ｓｔａｒｔ，  ｌｅｎｇｔｈ＞」エンコーディングが符号化ファイルから読み取られる（７７０）。
【００５２】
この態様に従うと、＜ｓｔａｒｔ，  ｌｅｎｇｔｈ＞情報を用いて、「ｓｔａｒｔ」位置から始まり「ｌｅｎｇｔｈ」情報と等しい長さを有する符号化ファイルから出力ファイルへとストリングがコピーされる（７８０）。すなわち、本発明に従って前に符号化されたマッチングストリングがそれ全体で脱圧縮され出力ファイルへと書き込まれる。文字が残っていれば（７９０）、脱圧縮プロセスは継続する。残っていなければ、脱圧縮プロセスは完了し出力ファイルを完成させる。
【００５３】
本発明の脱圧縮プロセスは、コンピュータ、プロセッサ、ＤＳＰ等で実行させることができる。図１１は、図７に示した本発明に従うデータを脱圧縮する動作を実装するＣ言語ソースコードプログラム１１００を示す。ソースコードプログラム部分１１００は符号化データファイルおよびそこに含まれる個々の文字を操作する配列を定める。部分１１２０は文字を処理するプログラムの主要部分を実行し、符号化ファイルを脱圧縮して出力ファイルを作る。
【００５４】
Ｃ言語ソースコードプログラム１１００は生来的に例示的であり、本発明の理解を深めるために記した。本発明の原理を実装する他のプログラムを本発明の範囲を外れずに当業者は容易に作ることができるであろう。
【００５５】
本発明の多くの原理および利点を説明するため、非常に大きなファイルに関連して本発明を適用し、そのファイルの圧縮の多くの結果を比較した。サンプルとしては、周知のＣＤ−ＲＯＭで”Ｐｒｏｊｅｃｔ  Ｇｕｔｅｎｂｅｒｇ  Ｃｏｍｐａｃｔ  Ｄｉｓｃ”，  Ｗａｌｎｕｔ  Ｃｒｅｅｋ  ＣＤＲＯＭ，  Ｗａｌｎｕｔ  Ｃｒｅｅｋ，  ＣＡ  に含まれる全てのテキストファイルを連結させて用いた。このＣＤ−ＲＯＭには１９９４の文書が含まれている。この試験のため、我々は周知のＵＮＩＸの「ｃａｔ」コマンドを用いて全てのテキストファイルを連結した。具体的なＵＮＩＸコマンド文字列は、「ｃａｔ  ＊／＊．ｔｘｔ  ＞  ｇｕｔ９４ａｌｌ．ｔｘｔ」であった。このように連結することにより、６６１２２ＭＢｙｔｅｓの入力ファイルを得て、これに本発明の原理を適用した。
【００５６】
図８は、連結した当該テキストファイルを圧縮した結果の比較８００を示す。ファイルサイズはＭＢｙｔｅで示してあり、圧縮による元ファイルと割合をパーセントで示した。ブロックサイズｂ（８１０）を変化させた効果を比較した。「ｃｏｍ  ｂ」の見出しを有する列８２０は、本発明を適用した効果を示してあり、入力テキストファイルのサイズの変化を示してある。「ｃｏｍ  ％」の見出しを有する列８３０は、ブロックサイズを変化させて調べた圧縮パーセンテージを示す。
【００５７】
「ｃｏｍ  ｂ｜ｇｚｉｐ」の見出しを有する列８４０および「ｃｏｍ｜ｇｚｉｐ  ％」の見出しを有する列８５０は、本発明の原理と組み合わせて周知の「ｇｚｉｐ」圧縮アルゴリズム（周知のＧＮＵによるＬＺ７７の実装であるｇｚｉｐ）を適用した結果を示す。「ｃｏｍ｜ｇｚｉｐ  ％」（８５０）は、列８２０のサイズに対する列８４０の割合を示す。例えば、線のブロックサイズを用い本発明と組み合わせてｇｚｉｐを適用すると、元のファイルパーセントを１９．７％の割合で減らすことができた。図よりブロックサイズｂが減ると、最適でない点（効率的な圧縮にはブロックサイズが小さすぎる）に到達するまで圧縮の度合いは増えている。また、「ｔｏｔａｌ  ％」の見出しを有する列８６０は、元のファイルと比較した列８４０の割合を示してあり、ｂの最適な選択は、ｃｏｍがｇｚｉｐのファイルサイズの減少量を超えて２２．５％のファイルサイズの減少量となっているところの３１ＭＢｙｔｅである。
【００５８】
本明細書における説明は単に本発明の原理の例を示したのみである。当業者は、本発明の範囲を外れずに多くの構成を変えずに本明細書が開示することに基づいて多くの構成を考えることができるであろう。特許請求範囲の記載において特定の機能を実行する手段として表現したいずれの要素も、その機能を実行するいずれの機能をも表すように意図してある。例えば、（ａ）その機能を実行する回路要素の組み合わせ、あるいは（ｂ）その機能を実行するためソフトウェアを実行する適切な回路と組合わさるいずれの形態におけるソフトウェア（従って、ファームウェア、オブジェクトコード、マイクロコード等をも含む。）を含む。
【図面の簡単な説明】
【図１】本発明に従ってデータを圧縮し展開するシステム。
【図２】本発明に従ってデータを圧縮する動作の流れ図。これは図１のシステムにて有用である。
【図３】図２の動作に従って計算された入力データストリームやフィンガプリントを記憶するデータ構造の例。
【図４】本発明に従って符号化された一連の符号化データストリームとともに一連の非圧縮データストリームを示す。
【図５】入力データファイルの選択部分。
【図６】本発明の原理に従って図５の入力データファイルから符号化された符号化データファイルの選択部分。
【図７】本発明に従い展開する動作の流れ図。
【図８】本発明に従ってテキストファイルを圧縮した圧縮結果。
【図９】図２に示すように本発明に従ってデータを圧縮するＣ言語ソースコードプログラム。
【図１０】図９と同様。
【図１１】図７に示すように本発明に従ってデータを展開するＣ言語プログラム。
【符号の説明】
１０５  入力データストリーム
１１０  入力データエンコーダ
１１５  符号化入力データストリーム
１２０  コンプレッサ
１２５  圧縮データ
１３０  チャネルエンコーダ
１３５  チャネル符号化された情報
１４０  変調エンコーダ
１４５  変調データストリーム
１５０  媒体
１５５  変調デコーダ
１６０  チャネルデコーダ
１６５  デコンプレッサ
１７０  データデコーダ
１７５  出力データストリーム
２１０  入力データストリームを受信
２２０  圧縮ブロックサイズ「ｂ」を選択
２３０  入力データストリームをサイズ「ｂ」ブロック群に分割
２４０  各ブロックに対しフィンガプリントを計算し格納する
２５０  入力データストリームを横断し、キャラクタベースでフィンガプリントを計算し格納されたフィンガプリントと比較
２６０  マッチするか？
２７０  マッチを符号化
２８０  入力データストリームの終わりか？
２９０  符号化された入力データストリームに圧縮を適用
３９１、２４３９  文字位置
４１０  符号化出力データストリーム
４００、４２０〜４５０  入力データストリーム
４６０〜４９０  符号化出力
５００  入力データファイル
５１０、５２０、５３０  テキスト部分
６００  符号化データファイル
６１０、６２０、６３０  符号化部分
６３５  エンコーディング
７１０  符号化データファイルから文字「ｃ」を取り出す
７３０  出力ファイルに文字「ｃ」を書き込む
７４０  次の文字に進む。
「ｃ＝次の文字」
７６０  出力ファイルに「＜」を書き込む
７７０  符号化データファイルから＜ｓｔａｒｔ，ｌｅｎｇｔｈ＞エンコーディングを読み取る
７８０  ｓｔａｒｔ位置からｌｅｎｇｔｈの長さのストリングを出力ファイルにコピーする
７９０  まだ「ｃ」はあるか？
９００  ソースプログラム
９１０、９２０、９３０、９４０、９５０  プログラムソースコード部分
１１００  ソースコードプログラム部分
１１２０  部分
【図１】
0003634711.tif 000003
【図２】
0003634711.tif 000004
【図３】
0003634711.tif 000005
【図４】
0003634711.tif 000006
【図５】
0003634711.tif 000007
【図６】
0003634711.tif 000008
【図７】
0003634711.tif 000009
【図８】
0003634711.tif 000010
【図９】
0003634711.tif 000011
【図１０】
0003634711.tif 000012
【図１１】
0003634711.tif 000013