【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般的にはデータ格納及び伝送システムに関し、詳細には、データ格納及び伝送の能力を改善する、データ圧縮システム及び方法に関する。

【０００２】

【従来の技術】データ格納システムとデータ伝送システムとの間のデータ圧縮の重要でない違いによって、データ格納システムのみが、特に、このようなシステムに格納されたデータファイルに言及される。 しかし、全てのデータ格納システムは、データ伝送システム及び他のアプリケーションをカバーするように、容易に拡張され得る。 ファイルはバイト又はキャラクタの連続するストリームであると考えられ、そこではバイトは幾つかの固定された数のビットから成り、圧縮システムはこの入力バイトのストリームを、「圧縮された」バイトの出力ストリームに変換し、これから伸張ユニットによって、オリジナルファイルの内容が再構築され得る。

【０００３】コンピュータデータファイルが典型的に膨大な量の冗長性を含むということは、定着している。 これらのファイルがディスク又はテープ記憶媒体上でより小さいスペースを占めるように、又は１２００ボーのモデムラインのような伝送チャネルに於いてより短い時間で移送され得るように、これらのファイルを「圧縮」するために多くの技術が長年用いられてきた。 例えば、パーソナルコンピュータに使用される幾つかの広く用いられている市販のプログラムがある（例えば、Systems En
hancement Associates, Inc., Wayne, NJ, 1985のＡＲ
Ｃソフトウェア）。 このプログラムはファイル上で圧縮及び伸張の機能を果たす。 減少量はファイルの内容に大きく依存して変化するが、このようなプログラムにとって、与えられたファイルの大きさを２：１の比（又はそれ以上）に減少させることは一般的ではない。

【０００４】データ圧縮のための従来技術における多くのアプローチがなされている。 これらのアプローチの幾つかは、ファイル又はファイル内のデータの一定のタイプについて、暗黙の前提を作り出している。 例えば、スキャナを用いて生成されたページのビットイメージは、
殆どが空白の画素であり、この傾向は、このようなファイルの大きさを大きく減少させる圧縮アルゴリズムによって利用される。 同様に、ワードプロセッシングファイルは、関係する言語（即ち、英語）に最もよく現れるキャラクタ（又はワード）の知識を用いて容易に圧縮される、多くのアスキーキャラクタを含んでいる。 他の圧縮方法はファイルのタイプから独立しており、そのデータに「適応」するようにされている。 一般に、特定のタイプ用の圧縮技術は、その技術が最適化されるファイル上では、一般用のアルゴリズムよりも高い圧縮性能を供給する。 しかし、もしファイルモデルが正しくないと、それらは非常に低い圧縮性能を有する傾向にある。 例えば、英語のテキストに最適化された圧縮方法は、フランス語のテキストを含むファイル上では、不完全にしか機能しないかも知れない。

【０００５】典型的には、格納システムはどんなタイプのデータがその中に格納されているかを知らない。 従って、特定のデータ用の圧縮技術は避けられ、又はそれらは可能な技術の集合の一つとして用いられるのみである。 例えば、ＡＲＣは多くの方法を用い、そして各ファイルに最適のそれを選択する。 しかし、このアプローチは単一の圧縮方法を用いるのに比べて、非常なコンピュータのオーバーヘッドを必要とする。

【０００６】圧縮方法の他の重要な見地は、ファイルが処理される速度である。 もし圧縮（又は伸張）の速度が非常に遅く、システムの性能を著しく低下させる場合には、たとえそれが競合する方法よりも高い圧縮比を達成し得ても、その圧縮方法は受け入れられない。 例えば、
ストリームテープシステムでは、もしテープ駆動に必要な速度でデータを供給するのに十分速くファイルが圧縮されなければ、テープは流れの速度を落し、圧縮による性能及び／又は容量利得は無駄になる。

【０００７】最も一般的な圧縮技術の一つは、ランレングスコード化として知られている。 このアプローチは、
ゼロ又はスペースキャラクタのような同じバイト（キャラクタ）が繰り返されたストリングを、ファイルがしばしば有しているという事実を利用している。 このようなストリングは「エスケープ」キャラクタを用いてコード化され、繰り返し数、繰り返されるキャラクタが続く。
ランの形式で現れなかった他の全てのキャラクタは、それらを「普通テキスト」として出力ストリームに置くことによってコード化される。 エスケープキャラクタは滅多に使用しないバイトとなるように選ばれ、入力ストリームにおけるその出現は、キャラクタとしてのエスケープキャラクタそれ自身を有する長さ１のランとしてコード化される。 ランレングスコード化はあるタイプのファイル上ではよく機能するが、もしファイルが繰り返しのキャラクタを有していなければ（又はファイルにエスケープキャラクタがしばしば出現すれば）、低い圧縮比率しか有し得ない。 従って、一般に、エスケープキャラクタの選択は、データ上で最も使用の少ないバイトを捜すという余分な経路を必要とし、このようなシステムの効率を低下させる。

【０００８】最も洗練されたアプローチは、ハフマンコードとして知られている（Huffman,David A., "A Metho
d for the Construction of Minimum Redundancy Code
s",Proceedings of the IRE, pp. 1098-1110, Septembe
r 1952を参照せよ）。 この方法では、あるバイトはファイル内で他のバイトよりしばしば多く現れると仮定される。 例えば英語のテキストでは、文字「ｔ」又は「Ｔ」
は文字「Ｑ」より多く存在する。 各バイトはビットストリングに割り当てられ、その長さは、逆にファイル内におけるそのバイトの相対的な頻度に関係する。 これらのビットストリングは、もし１ビットがある時に処理されると、唯一の結果しか生じないようにデコードされるように選択される。 ハフマンはファイルに対する相対的頻度の統計に基づく、ビットストリングの最適割当てのためのアルゴリズムを導いている。

【０００９】ハフマンアルゴリズムは、達成される圧縮が漸近的にファイルの「エントロピー」に近づくことを保証し、それは以下のように正確に定義される。

【００１０】 Ｈ＝ＳＵＭ−［ｐ（ｉ）ｌｏｇ ₂ （ｐ（ｉ））］ ここで、 ｐ（ｉ）＝ファイル内のキャラクタｉの確率 ＝（ｉの出現数）／（ファイル内のキャラクタの総数） Ｈの単位はビットであり、それはファイル内のキャラクタを表現するのに（平均して）どれだけのビットが必要であるかを測定する。 例えば、もしエントロピーが８ビットバイトを用いて４．０ビットであれば、ハフマン圧縮システムはファイル上で２：１の圧縮をなし得る。 エントロピーが高いほど、データはより「乱雑」（従って、あまり圧縮できない）である。

【００１１】ハフマンのコード化は多くのタイプのファイル上で非常によく機能する。 しかし、ビットストリングのバイトへの割当ては、多くの実際的な困難を伴う。
例えば、予め設定されたコード化スキームが用いられる場合（例えば、英語における文字の出現の頻度に基づいて）、もしその予め設定されたスキームが、ファイル内の実際に存在するものとかなり異なる頻度統計であると仮定すると、ハフマンのコード化はファイルを大きく拡張するかもしれない。 これに加えて、ファイルの内容に基づくコード化スキームの演算は、ハフマンアルゴリズムを頻度統計に適応するのと同様に、データ上での２つのパスを必要とするのみならず（従って、システムの効率を低下させる）、コード化テーブルがデータに沿って格納されるということが必要とされ、これは圧縮率の上での否定的な衝撃を有する。 更に、バイトの相対的頻度は、ファイル内で動的に容易に変えられ得る。 そのため、どの点でも特定のコード化割当てはうまく機能しない。

【００１２】ハフマンアプローチの多くの変形があり（例えば、Jones, Douglas W., "Application of Splay
Trees to Data Compression", Communications of the
ACM,pp. 996-1007, Vol. 31, No. 8, August 1988）、
通常、それらは処理された入力バイトの最新の履歴に基づいた、動的コード割当てを含んでいる。 このようなスキームは上で議論した問題点を回避する。 他のアプローチは同時に２バイトワード（バイグラム（bi-gram））
を見ることを含み、ハフマンのコード化をそのワード上で行う。

【００１３】近年のハフマンのコード化の変形は、MacC
riskenの米国特許第4,730,348号（及びその中で参照されている他の特許）に現れている。 MacCriskenの米国特許では、ハフマンコードは先のバイトのコンテキストにおけるバイトに割り当てられる。 言い換えれば、複数のコード化テーブルが用いられ、各テーブルは先のバイトに従って選択される。 このアプローチは、例えば、英語では文字「ｕ」は頻繁には現れないが、「ｑ」の後には殆ど常に現れるという観察に基づいている。 従って、
「ｕ」に割り当てられるコードは、先の文字が「ｑ」
（又は「Ｑ」）であるかどうかに依存して異なるであろう。 多数のテーブルと動的コード割当てとを用いる同様のスキームについては、Jones, Douglas W., "Applicat
ion of SplayTrees to Data Compression"を参照されたい。

【００１４】上述のハフマンタイプのアプローチは、コンピュータによって強化される傾向にあり、例外的に高い圧縮比率を達成するものではない。 この観察に対する一つの説明は、８ビットバイトに基づく純粋なハフマンコードは最も良い場合には８：１の圧縮比率を達成し得ること、そしてそれはファイルが同じバイトの繰り返し（即ち、エントロピー＝０）から成る最善の状況でのみ達成され得ることである。 同じ状況では、単純なランレングスコード化スキームは５０：１以上の圧縮率を達成し得る。 平均の性能は最善及び最悪の場合の数の同じ組み合わせであろう。 そして、最善の場合の限度は、その平均をも制限する。 ハフマンのコード化の公知の限度は、確率が厳密に２の累乗でなければ、理論的な限度の１ビットの範囲内となることは保証されるが、エントロピーを達成し得ないことである。 これは、全てのハフマンコードが長さにおける正確なビット数であるという事実のためである。 一方、全ての場合においてエントロピーを達成するためには、断片的なビット長が必要である。 言い換えると、ハフマンのアルゴリズムはまるめの問題を有している。 一般に、高い確率でトークンがある場合に問題は悪化する。 なぜなら、「エラー」のビットの断片が、割り当てられたコードのサイズの大きなパーセンテージを占めるからである。

【００１５】数学的コード化は、まるめの問題を実際に克服することのできる公知の技術である。 しかしながら、数学的コード化に必要なテーブルは、ハフマンのテーブルのように圧縮可能ではなく、またテーブルサイズの問題を克服するために数学的アルゴリズムを動的に行うことは、可能ではあるが、計算上非常に集中的である。 最終的な結果として、数学的コード化を用いて実際に達成される利得は、理論的見地から望まれるほど大きくはない。

【００１６】圧縮のための全体的に異なるアプローチが、Lempel及びZivによって開発され（Ziv, J.及びLemp
el, A., "Compression of Individual Sequences via V
ariable-Rate Coding", IEEE Transactions on Informa
tion Theory, Vol. IT-24, pp. 530-536, September 19
78を参照せよ）、Welchによって改良されている（Welc
h, Terry A., "A Technique for High-Performance Dat
a Compression", IEEE Computer, pp. 8-19, June 1984
を参照せよ）。 可変長のコードを固定された大きさのバイトに割り当てる代わりに、Lempel-Zivアルゴリズム（「ＬＺ」）は、固定長のコードを可変の大きさのストリングに割り当てる。 ファイルからの入力バイトが処理されるにつれて、ストリングのテーブルが作成され、各バイト又はバイトのストリングは、テーブル内のストリングのインデックスのみを出力することにより、圧縮される。 典型的にはこのインデックスは１１〜１４ビットの範囲であり、１２ビットが一般的である。 なぜならこれは単純な手法に向いているからである。 テーブルは先にコード化されたバイトのみを用いて作成されるので、
圧縮及び伸張のシステムの両方は、テーブル情報を移送するのに必要な余分なオーバーヘッド無しに、同じテーブルを維持することができる。 ハッシングアルゴリズムがマッチするストリングを効率的に捜すのに用いられる。 ファイルの初めでは、テーブルはアルファベットの各キャラクタに対して一つのストリングが初期化される。 従って、たとえそのストリングが長さ１のみを有していても、全てのバイトは少なくとも一つのストリングに見いだされるということを確実にする。

【００１７】Lempel-Zivアルゴリズムは、それ自身をデータに適合させ、ファイルの内容に根拠を置く予め設定されたテーブルを必要としないので、魅力がある。 更に、ストリングを極端に長くし得るので、最適の場合の圧縮比率は非常に高く、実際のＬＺ出力は、ほとんどのタイプのファイルでハフマンスキームに匹敵する。 また、それは装置にとっても非常に単純であり、この単純さが高い効率に現れている。

【００１８】しかし、幾つかの障害もまた、ＬＺ圧縮法に存在する。 ＬＺストリング探索は「どん欲な」アルゴリズムである。 例えば、次のストリングを考える。

【００１９】ＡＢＣＤＥＦＢＣＤＥＦ ここで、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆは異なったバイトである。 ＬＺストリング探索は、ＡＢ、ＢＣ、ＣＤ、ＤＥ、
ＥＦ、ＢＣＤ、ＤＥＦのストリングをストリングテーブルに付け加え、このアルゴリズムを用いて出力され得る長さ２又はそれ以上のストリングは、上で示した時点ではＢＣ及びＤＥのみであることに注意しなければならない。 実際にはストリングＢＣＤＥＦは既に入力に現れている。 従って、第２のＢＣＤＥＦストリングは最初のＢ
ＣＤＥＦに戻って参照されるのが理想であるが、実際にはこれは行われない。

【００２０】ＬＺアプローチにとって重大な欠点は、圧縮されたデータを保持するためのストリングテーブルが、長いファイルを満たしてしまう傾向にあることである。 しかし、テーブルの大きさは増大されることができ、このアプローチはストリングを表すのにより多くのビットを必要とし、従って、効率が低下するであろう。
この欠点を扱うための一つのアプローチは、テーブルがいっぱいになったときにそのテーブルの全部又は一部を捨てることであろう。 アルゴリズムの構造のために、最新に見いだされたストリングが最初に捨てられる。 なぜなら、それらは先のストリングに戻って参照するからである。 しかし、ローカルデータに動的に適合しているのは、最新のストリングであり、それらを捨てるのもまた効率的ではない。 基本的にはＬＺストリングは無限の長さのメモリを有しているので、ファイル内のデータのタイプの変更は、もしストリングテーブルがいっぱいであれば、非常なコード化の効率の悪さを引き起こし得る。

【００２１】同時に１より多くの方法を用いる圧縮システムを設計することも可能である。 このシステムは、ファイル内でその方法が最も効率的になるように動的に後ろ及び前にスイッチングする。 装置の観点からは、このようなスキームは非常に高価であるかも知れないが（即ち、遅く及び／又は高価である）、結果として得られる圧縮比率を非常に高くすることができる。

【００２２】動的に前後にスイッチするこのような一つの方法は、MacCriskenの特許に開示されている。 上述のように、バイグラムハフマン法は主要な圧縮技術として使用されている。 典型的には、圧縮及び伸張システムは予め定義された（即ち、統計的に）コードテーブルのセットを用いてスタートする。 おそらく、英語、フランス語及びパスカルソースコードのためのこのようなテーブルのセットがある。 圧縮ユニット（送信機）は、使用されるテーブルの短い記述を最初に移送又は格納する。 伸張ユニット（受信機）はこのコードを分析し、適切なテーブルを選択する。 圧縮の間に、もし現在のテーブルが十分に機能しないことが決定されると、送信機は特別の（「エスケープ」）ハフマンコードを移送する。 このコードは、他の特定の予め定義されたテーブルを選択するか、又は伸張された先のデータに基づいて新たなテーブルを計算するかどうかを受信機に伝える。 送信機及び受信機の両方は、同じアルゴリズムを用いてテーブルを計算するので、テーブル全体を送る必要はないけれども計算を行うのに幾らかの時間がかかる。 ひとたび新たなテーブルが計算されると、以前と同様に圧縮が行われる。
かなりのコンピュータのオーバーヘッドが存在するけれども、この技術が更に動的ハフマンスキームに用いられ得ないという理由は無いことに注意されなければならない。

【００２３】ハフマンのコード化に加えて、MacCrisken
は第２のストリングに基づく圧縮方法を用いている。 送信機及び受信機の両方が、最新の移送された入力バイトの履歴バッファを保持する。 それぞれの新たな入力バイト（Ａ）に対してバイグラムハフマンコードが生成されるが、ハッシングスキームを用いて履歴内の次の３つの入力バイト（ＡＢＣ）によって表現されるストリングを見つける試みもまた行われる。 ハッシュが３バイトストリング上で行われ、ハッシュリスト内の古い入力の廃棄を可能とするために、２重にリンクされたハッシュリストが維持される。 もしストリングが見つかると、ストリングが続くことを示すために特別のハフマンエスケープコードが生成され、履歴バッファ内のストリングの長さとオフセットが送られる。 オフセットは１０ビットにコードされ、長さは３〜１８バイトの長さを表現する４ビットにコードされる。 しかし、このようなストリングが送られる前に、圧縮ユニットはストリング内の全てのバイトに対するハフマンコードを発生し、そのハフマンコードの大きさをストリングビットの大きさと比較する。
典型的にはハフマンストリングエスケープコードは４ビットであり、ストリングを表すのに１９ビットを要する。 ２つの量の小さい方が送られる。

【００２４】MacCriskenストリング法は、Lempel-Ziv法のストリングテーブルは決していっぱいにならないという問題点を避けているということに注意しなければならない。 なぜなら、古い入力はハッシュリストから除くことによって廃棄されるからである。 従って、最新の（１
キロバイト以内）のストリングのみがテーブルを占める。 また、原理的には全てのマッチするストリングが見いだされるので、それは「どん欲」ではない。 実際には、ストリング探索の長さの制限が課されている。 これに加えて、MacCrisken法は２つの圧縮アルゴリズムを同時に効率的に行い、従って、コンピュータのオーバーヘッドが非常に高くなるので、コンピュータで行うには非効率的である。

【００２５】データの最新処理されたバイトの「スライディングウインドウ」を維持し、マッするバイトのストリングに対するウインドウを走査するLempel-Ziv技術のうちのMacCrisken法の変形を用いるアルゴリズムが他にもいくつかある。 ストリングが見いだされると、マッチするストリングの長さ及びウインドウ内のそのオフセットが出力される。 他の場合では、「生の」バイトが出力される。 圧縮エンジンのコード化部分は、ストリングと生のバイトとの間の差異を示すタグを送り、ストリング及び生のバイト自体は多くの方法でコード化され得る。

【００２６】明らかに、データのタイプが異なると、ストリングの長さ及びオフセットの分布も異なるので、単一の固定されたコード化が全ての可能なファイルに対して最適とはなり得ない。 従って、見いだされたストリングに基づいてコード化を決定するための様々な技術が開発されている。 例えば、ハフマンコード化は、ストリングの長さ及びオフセットをコード化するために用いられることができる。 実際には、全ての長さ及びオフセットが個々のハフマンコードを与えられるわけではない。 その代わりに、長さ及びオフセットの範囲が、単一のハフマンコードによって表されることができる。 範囲内の値を区別するために特別なビットがハフマンコードの後ろに続いている。 これらの範囲、つまりビン（bin）は、
データにおいて典型的に観察される分布を近似するように選択される。

【００２７】そのようなアプローチの利点の一つは、選択されるビンの制約内で、コード化が、圧縮されたイメージのサイズを最小化するように処理されるているデータに対して最適化され得ることである。 そのようなアプローチの１つの欠点は、コード化フォーマットを記述するタイプのテーブルがデータと共に送られなければならず、従って、可変コード化によって得られる余分な圧縮をある程度打ち消すことになる。 実際に、十分大きなデータブロックに対して、このオーバーヘッドは、コード化における利得によって補償されるよりも大きい。 他の欠点は、このタイプのアプローチは本質的に、ハードウエアであってもソフトウエアであっても、固定コード化スキームよりも実行が困難であることである。 ここでも、補償率における利得が、複雑さの増大よりも重要となることがよくある。 データの各バイトが処理される毎にコード化を動的に修正してテーブルの必要性を除去することはできるが、そのようなスキームは、さらに非常に複雑であるので、典型的には、圧縮率の対応する劇的利得を伴わずに圧縮及び伸張のスループットを劇的に低速化させる。 ３番目の欠点は、多くの場合に重要ではないが、このタイプのアルゴリズムが本質的に２経路アプローチであるので、いずれかのコード化トークンが出力され得る前にストリング探索エンジンによって全てのデータが処理されることが必要であることである。

【００２８】ストリングをコード化することに加えて、
生バイトもまたコード化され得る。 スライディングウインドウ法を用いて、各アイテム出力はストリング又は生バイトのいずれかであるので、生バイト及びストリングが共にコード化され得る。 例えば、単一ハフマンコードが、生バイト又はある長さのストリングのいずれかを表すことができる。 コード化に生バイトを含ませることは、用いられる特定のコード化を特定するテーブルのサイズをさらに大きくする傾向があるが、このテーブルサイズの増大は、得られる圧縮の利得によって典型的には克服される。

【００２９】PKZIP version 2.0及びLHA version 2.13
は共通に、このタイプの圧縮方法を用いるＭＳ−ＤＯＳ
コンピュータに対して利用可能な圧縮ユーティリティである。 これらのプログラムによって用いられるストリング探索技術は異なるが、得られる圧縮フォーマットは、
スタイルが極めて似ている。 意外ではないが、非常に似た圧縮率が得られる。 各プログラムは、スライディングウインドウ及び最小のストリングの長さである３を用いており、圧縮データの一部として格納される２つのハフマンテーブルを発生させる。 第１（及び大きい方）のハフマンテーブルは生バイト及びストリング長さをコード化する。 例えば、PKZIPは、各種サイズの２９レングスビンの合計を用いて、ハフマンコード０〜２５５に生バイトを割当て、ハフマンコード２５７〜２８５に３〜２
５８のストリング長を割当てる。

【００３０】第２のハフマンテーブルは、PKZIP及びLHA
によって用いられて、ストリング長が特定されると、ストリングオフセットを表す。 言い換えると、（生バイトとは反対に）ストリング長に対応するハフマンコードの後ろに、ストリングオフセットを特定するために異なるハフマンコードが用いられる。 PKZIPは、１から３２７
６８の範囲の３０個のオフセットビンに対するハフマンコードを有しているが、LHAは、１から８１９１の範囲の１３個のオフセットビンを有している。 これらのアルゴリズムは、サイズが８Ｋバイト又はそれ以上のデータのブロックを圧縮する際に最も効果的であるので、ブロックサイズの一部であるテーブルオーバーヘッドは最小となる。

【００３１】これらの製品において、ハフマンのアルゴリズムによって発生されるコードの長さを与えるだけで、ハフマンコードの独特のセットを発生させて割り当てることができるという公知の事実によって、ハフマンテーブルは、それ自体が圧縮形態で格納されている。 従って、ハフマンコードの長さのみが格納される必要があるので、テーブルはコード自体よりもかなり小さくなる（さらに圧縮可能である）。 実際、ハフマン長はハフマンコード化を用いて圧縮されるので、ハフマン長を引き出すために用いられる初期の（未圧縮の）ハフマンテーブルが実際にあり、それはその後、データの圧縮及び伸張において用いられるハフマンコードを発生させるために用いられる。

【００３２】典型的には、これらのアプローチは固定コード化技術よりも１０〜１５％小さいサイズまでデータを圧縮することができる。 データ圧縮に関する文献及び研究の多くが、コード化技術よりもストリング探索方法に注目しているが、コード化が行われる方法に厳密に傾注することによって、大きな利得が（複雑さを犠牲にして）達成され得ることが経験的に明らかである。 しかしながら、複雑さの局面を無視しても、固定コード化は、
テーブルが送られ得ない多くのアプリケーションに対してはやはり重要である。 例えば、多くの伝送システムにおいて、データの小さなパケット（多くの場合、１００
バイトよりも小さい）が圧縮されなくてはならない。 テーブルオーバーヘッドはこの場合重要である。 同様に、
いくつかのアプリケーションにおいて、データは、テーブルが発生され得るように、受け取られる全ブロックを待つことなく、データが受け取られるとすぐに圧縮され移送されなくてはならない。

【００３３】可変コード化スキームを用いる圧縮比率における利得の主要な部分は、可変コード化自体から得られるものであり、生バイト及びストリングの分布に適合する。 しかしながら、利得の他の重要な成分は、可変コード化によって提供されるより大きなウインドウサイズ（例えば、８Ｋバイト以上）に帰することができる。 より大きなウインドウによって、より多くのストリングが見いだされることが可能となる。 なぜなら、より大きな履歴がストリング探索のために利用可能となるからである。 固定コード化スキームでは、残念なことに、オフセットのコード化サイズの増大は、より多くのストリングが見いだされるという事実を打ち消す傾向がある。 一方、可変コード化スキームでは、余分のストリングがオフセットコード化の適合性によって全体の圧縮比率を増大させる。

【００３４】

【発明が解決しようとする課題】実施する観点から、より大きなウインドウサイズに伴う一つの問題は、全体の圧縮及び伸張エンジンが単一の集積回路上に配置されるべきである場合には特に、必要なハードウエアのコストが非常に高いことである。 同様に、ソフトウエアの実現には通常、ウインドウサイズに比例するメモリサイズが必要であり、これが多くの場合に許容され得ない。 あらゆる場合において、通常は、圧縮アルゴリズムの互換性のあるソフトウエア及びハードウエアのバージョンを有することが望ましい。 アルゴリズムによって達成され得る圧縮比率と共に、ハードウエア及びソフトウエアの両方のコスト及び速度が考慮されなくてはならない。

【００３５】

【課題を解決するための手段】本発明のデータ圧縮方法は、入力バイトのウインドウ内のマッチングストリングに対する探索であって、生のバイトまたは一定の長さおよび該ウインドウへ戻る一定のオフセットを有するマッチングストリングのいずれかを表現するトークンからなるストリームを生成する探索を実行するステップと、該トークンを予め定義されているビンに割り当てるステップであって、該ビンのいくつかは、所定の長さおよび一定のオフセット範囲内にあるマッチングストリングを有するステップと、各ビンに割り当てられたトークンの発生頻度に基づいて、可変長コードを各ビンに割り当てるステップと、生成された各トークンに対し、各トークンが割り当てられた該ビンの該可変長コードを、出力データストリームに出力するステップと、各可変長コードが出力された後、必要であれば、該ビン内の該トークンを正確に特定するために、余分なビットを出力するステップとを包含する。

【００３６】前記方法は、前記可変長コードを割り当てる前に、入力データストリームの全てのマッチングストリング探索を完了するステップと、該入力ストリーム全体から各ビンにおけるトークン発生数をカウントするステップと、該発生カウントに基づいて前記可変長コードを割り当てるステップと、各ビンに割り当てられた該可変長コードを示すコーディングテーブルを生成するステップと、いかなる符合化されたトークンを出力する前に、該コーディングテーブルを前記出力データストリームに出力するステップとをさらに包含することもできる。

【００３７】前記可変長コードを割り当てるステップが、前記発生カウントに基づいてハフマンのアルゴリズムを用いて該可変長コードを割り当てるステップをさらに包含することもできる。

【００３８】前記コーディングテーブルを生成するステップが、前記可変長コードの長さのみを有するコーディングテーブルを生成するステップをさらに包含することもできる。

【００３９】前記方法は、ランレングス圧縮体系を用いて前記コーディングテーブルを圧縮するステップをさらに包含することもできる。

【００４０】前記方法は、ハフマンコーディングを用いて、前記コーディングテーブルを圧縮するステップと、
該コーディングテーブル中の可変長に割り当てられたハフマンコードを特定するために使用される予備テーブルを生成するステップとをさらに包含することもできる。

【００４１】前記方法は、圧縮された出力データの末端部を示す特別なビンを割り当てるステップと、全ての他のトークンが出力された後に、該圧縮された出力データビンの該末端部のコードを出力するステップとをさらに包含することもできる。

【００４２】前記方法は、前記ビンを以下に示すように割り当てるステップ

【００４３】

【表９】

【００４４】をさらに包含することもできる。

【００４５】前記方法は、ビン２５６から３１８のコードの後にストリングオフセットを特定する一定数の余分なビットを以下に示すように続けるステップ

【００４６】

【表１０】

【００４７】をさらに包含することもできる。

【００４８】前記方法は、ビン３１９から３３４のコードの後にストリングオフセットを特定する一定数の余分なビットを以下に示すように続けるステップ

【００４９】

【表１１】

【００５０】をさらに包含することもできる。

【００５１】前記方法は、ビン３３４のコードおよびオフセットビットの後にストリング長を特定する余分なビットを以下に示すように続けるステップ

【００５２】

【表１２】

【００５３】をさらに包含することもできる。

【００５４】他の局面によれば、本発明の圧縮された入力データストリームを伸張するデータ伸張方法は、全てのバイト出力の履歴アレイを維持するステップと、入力データストリームが消耗するまで、または該圧縮された入力データストリームの末端部を示すコードが見つかるまで、以下のステップを繰り返すステップと、該圧縮された入力データストリームからビンコードを抜き出すステップと、該ビンコードに関連したトークンを正確に決定するために必要とされる余分なビットを抜き出すステップと、該トークンが生のバイトに相当する時、該生のバイトを出力するステップと、該トークンがマッチングストリングに相当する時、該ストリングのオフセットを用いて該履歴アレイにインデックスバックすることにより該ストリングの全てのバイトを出力するステップとを包含する。

【００５５】前記方法は、前記圧縮された入力データストリームの開始部からコーディングテーブルを抜き出すステップと、該コーディングテーブルからカテゴリーに対する可変長コードを抜き出すステップとをさらに包含することもできる。

【００５６】他の局面によれば、本発明のデータ圧縮装置は、入力バイトのウインドウ内のマッチングストリングに対する探索であって、生のバイトまたは一定の長さおよび該ウインドウへ戻る一定のオフセットを有するマッチングストリングのいずれかを表現するトークンからなるストリームを生成する探索を実行する手段と、該トークンを予め定義されているビンに割り当てる手段であって、該ビンのいくつかは、所定の長さおよび一定のオフセット範囲内にあるマッチングストリングを有する手段と、各ビンに割り当てられたトークンの発生頻度に基づいて、可変長コードを各ビンに割り当てる手段と、生成された各トークンに対し、各トークンが割り当てられた該ビンの該可変長コードを、出力データストリームに出力する手段と、各可変長コードが出力された後、必要であれば、該ビン内の該トークンを正確に特定するために、余分なビットを出力する手段とを備えている。

【００５７】前記装置は、前記可変長コードを割り当てる前に、入力データストリームの全てのマッチングストリング探索を完了する手段と、該入力ストリーム全体から各ビンにおけるトークン発生数をカウントする手段と、該発生カウントに基づいて前記可変長コードを割り当てる手段と、各ビンに割り当てられた該可変長コードを示すコーディングテーブルを生成する手段と、いかなる符合化されたトークンを出力する前に、該コーディングテーブルを前記出力データストリームに出力する手段とをさらに備えることもできる。

【００５８】前記可変長コードを割り当てる手段が、前記発生カウントに基づいてハフマンのアルゴリズムを用いて該可変長コードを割り当てる手段をさらに備えることもできる。

【００５９】前記コーディングテーブルを生成する手段が、前記可変長コードの長さのみを有するコーディングテーブルを生成する手段をさらに備えることもできる。

【００６０】前記装置は、ランレングス圧縮体系を用いて前記コーディングテーブルを圧縮する手段をさらに備えることもできる。

【００６１】前記装置は、ハフマンコーディングを用いて、前記コーディングテーブルを圧縮する手段と、該コーディングテーブル中の可変長に割り当てられたハフマンコードを特定するために使用される予備テーブルを生成する手段とをさらに備えることもできる。

【００６２】前記装置は、圧縮された出力データの末端部を示す特別なビンを割り当てる手段と、全ての他のトークンが出力された後に、該圧縮された出力データビンの該末端部のコードを出力する手段をさらに備えることもできる。

【００６３】前記装置は、前記ビンを以下に示すように割り当てる手段

【００６４】

【表１３】

【００６５】をさらに備えることもできる。

【００６６】前記装置は、ビン２５６から３１８のコードの後にストリングオフセットを特定する一定数の余分なビットを以下に示すように続ける手段

【００６７】

【表１４】

【００６８】をさらに備えることもできる。

【００６９】前記装置は、ビン３１９から３３４のコードの後にストリングオフセットを特定する一定数の余分なビットを以下に示すように続ける手段

【００７０】

【表１５】

【００７１】をさらに備えることもできる。

【００７２】前記装置は、ビン３３４のコードおよびオフセットビットの後にストリング長を特定する余分なビットを以下のように続ける手段

【００７３】

【表１６】

【００７４】をさらに備えることもできる。

【００７５】他の局面によれば、本発明の圧縮された入力データストリームを伸張するデータ伸張装置は、全てのバイト出力の履歴アレイを維持する手段と、該圧縮された入力データストリームからビンコードを抜き出す手段と、該ビンコードに関連したトークンを正確に決定するために必要とされる余分なビットを抜き出す手段と、
生のバイトを出力する手段と、マッチングストリングの全てのバイトを、該ストリングのオフセットを用いて該履歴アレイにインデックスバックすることにより出力する手段とを備えている。

【００７６】前記装置は、前記圧縮された入力データストリームの開始部からコーディングテーブルを抜き出す手段と、該コーディングテーブルから該カテゴリーに対する可変長コードを抜き出す手段とをさらに備えることもできる。

【００７７】

【作用】本発明は、磁気ディスク又はテープ記憶装置のようなデジタル記憶装置の容量を増大させる、圧縮／伸張システムである。 圧縮方法は完全に適合性があり、予め初期化されたコード化テーブルを必要とせずに、コンピュータファイルのようなバイトに適応したキャラクタストリームを最適化する。 それは従来技術に見られる多くの困難を克服し、上述で議論した先行する技術の何れよりも、より少ないメモリ要件で、より速くより高い圧縮率を達成する。

【００７８】圧縮は、まず、以前のマッチするストリング又はバイトに対して、入力データストリーム全体に探索を行うことによって達成される。 ストリング探索は、
以前に処理されたバイトの履歴アレイを維持することによって達成される。 マッチするストリングが見いだされると、マッチするストリングの長さ及び履歴アレイ内でのマッチするストリングのオフセット（相対的位置）を示す出力トークンが発生される。 現在調べられているバイトを含むマッチするストリングが見いだされない場合には、「生の」バイトであることを示す出力トークンが発生される。

【００７９】圧縮プロセスは、マッチするストリング及びストリング探索によって発生される生のバイトを表すトークンのハフマンに基づくコード化を用いることによって完結する。 単一のハフマンコード化ツリーが、生のバイト及び多くの最も共通するストリング長／オフセットの対に対して用いられる。 ハフマンテーブル自体は、
データの圧縮イメージの一部として圧縮形態で格納される。

【００８０】本発明の好ましい実施例は、圧縮ユニットから出力されるコード化データストリームを伸張するための方法も包含している。 伸張するための方法は、以下のステップを包含している。 第１に、コード化されたハフマン長テーブルが受け取られてデコードされる。 各ハフマンビンに対するコードの長さが分かると、ハフマンコードが各トークンビンに割り当てられる。 トークンビンに対してハフマンコードが与えられると、ハフマンツリーがトークンをデコードするために構築され、それが圧縮入力データストリームから引き出される。 ハフマンビンが生のバイトに対応する場合には、伸張ユニットが生のバイトを出力する。 ハフマンビンがストリングに対応する場合には、ストリングオフセット及び長さを特定するために必要な全ての余分なビットが、入力データストリームから引き出される。 その後、ストリングが、同時に１バイト出力される。 好ましい実施例において、たいていのスライディングウインドウ伸張スキームと同様に、これは、最新のバイト出力の履歴アレイを維持し、
オフセットによって履歴アレイにインデックスし直すことによって行われ、１バイトが引き出される。 生バイト又はストリングバイトのいずれか全てのバイト出力が履歴アレイに加えられる。

【００８１】

【実施例】図１（ａ）及び図１（ｂ）において、本発明による圧縮ユニット４及び伸張ユニット６のブロック図が示される。 ユニット４及び６の両方は、ハードウエアモジュールであっても、ソフトウエアモジュールであってもよい。 しかし、好ましい実施例においては、圧縮ユニット４及び伸張ユニット６は１個の集積回路に組み入れられる（図１０）。 この集積回路は、マイクロプロセッサ５によって制御されるデータ記憶システム又はデータ伝送システムの一部として用いられる。 図１（ａ）において、入力データストリーム８は、ホスト１０と称されるデータ送信装置から圧縮ユニット４に入力される。
コード化され、圧縮されたデータストリーム１２は装置１４と称されるデータ受信装置へ伝送される。

【００８２】同様に、図１（ｂ）に於いて、伸張ユニット６は、装置１４（ここではデータ送信装置）から圧縮されたデータストリーム１８を受け取り、元の圧縮されていないデータストリーム２０を再構成し、そのデータストリームをホスト１０（ここではデータ受信装置）へ出力する。 好ましい実施例において、伸張及び圧縮は同時には行われない。 しかし、他の実施例に於いては伸張及び圧縮は同時に行われ得る。

【００８３】図２では、本発明によって動作するように構成された圧縮ユニット４のブロック図が示されている。 入力データ２２は、圧縮されるべき入力データストリームである。 入力データ２２は、ＭＥＭＳＩＺＥバイトのウインドウサイズを用いて、ブロック２４に示されるように、スライディングウインドウストリング探索アルゴリズムを用いて処理される。 多くの異なるストリング探索アルゴリズムがブロック２４において用いられ得る。 スライディングウインドウアルゴリズムの出力は一連のトークン２６である。

【００８４】トークン２６のそれぞれは、生バイト又は与えられた長さ及びオフセットを有するマッチするストリングである。 すでに処理された以前のＭＥＭＳＩＺＥ
バイトにおいてマッチするストリングが見いだされない場合に、生バイトトークンが生成される。 ストリングトークンは、見いだされたストリングマッチの長さ及びスライディングウインドウからのそのオフセットを示す。
長さ及びオフセットは、伸張ユニット６が元のデータを再構成し得るには十分である。

【００８５】出力トークンは、ハフマンコードがトークンビンのそれぞれに割り当てられるまで中間バッファ２
８に一時的に格納される。 この割当ては、入力データ２
２の全てがマッチするストリングを捜すために探索され、全てのトークンが生成されるまで起こらない。 トークンが生成されて格納されると、それらは、異なるビン又はカテゴリに割り当てられる。 ビンは、生バイト、各種ストリング長さ／オフセット対及び幾つかの個々のストリング長から成る。

【００８６】トークンはまた、入力データ２２から生成される全てのトークンに対して１ビン当たりのトークンの数をカウントするビンカウンタ３０へ入力される。 各ビンに対するカウントは、初期的にはゼロに設定され、
ビンに対応するトークンが生成される毎に１ずつインクリメントされる。 他の実施例において、ビンカウントは、中間バッファにおけるトークンを再処理することによってスライディングウインドウ探索が完了した後にのみ計算されて、カウントを累積する。 他の実施例において、中間トークンは、バイト配列された固定コード化を用いて（ビット配列フォーマットではなく）格納される。 バイト配列された固定コード化には、より大きな格納空間が必要ではあるが、より効率的に処理され得る。

【００８７】全ての入力データがスライディングウインドウ探索２４によって処理され、全ての出力トークンが一時的に格納されてビンカウントが計算されると、ハフマンのアルゴリズムが用いられて、ハフマンコード３２
が各種ビンに割り当てられる。 ハフマンコード３２は、
ビンカウンタ３０によって維持されるビンカウントから生成される。 各ビンに対するハフマンの確率は、ビンカウントに比例するので、一般に、大きなカウントを有するビンほど短いコードを割り当てられ、小さなカウントを有するビンほど長いコードを割り当てられる。

【００８８】単一のハフマンツリーを用いることによって、データと共に格納されるテーブルのサイズが小さくなる。 より重要なことに、ストリング長さ／オフセット対を単一ハフマンコードに組み合わせることは、所定の長さ及びオフセットのビンからのストリングが、例えばオフセットとは独立した所定の長さのストリングよりもかなり確率が低くなることを意味している。 従って、ハフマンコード化に付随するまるめの問題が最小化され、
高圧縮比率が小さなウインドウサイズでも達成され得る。 小さなウインドウサイズは、ハードウエア及びソフトウエア実現において、より許容可能なコストとなる。

【００８９】好ましい実施例において、ハフマンのアルゴリズムは、各ハフマンコードの長さを生成させるためにのみ用いられており、ビットコードそのものを生成させるためには用いられていない。 各ビンに対してハフマンコードの長さを与えると、実際のコードは、以下に説明されるように、図１５において示されるアルゴリズムを用いて一意的に生成される。 ハフマンコードの長さのみが圧縮データと共に格納され、伸縮ユニット６は図１
５の同様のアルゴリズムを用いてコードを割り当てる。
従って、圧縮及び伸縮の一致が保証される。

【００９０】中間バッファ２８からのトークン及びハフマンコード３２がいずれもハフマンエンコーダ３４へ入力される。 ハフマンエンコーダ３４は、圧縮された出力データ３６の第１の部分として、各ビン対するハフマンコードレングスを出力する。 そのレングスは、ハフマンビン０から始まり、最後のハフマンビンまで出力される。 好ましい実施例では１〜１５ビットの範囲であるコードレングス自体は、空間を節約するために圧縮フォーマットで出力される。 レングスフィールドにおいてゼロであるということは、所定のビンが起こらないことを意味している。 好ましい実施例において、単一のランレングス圧縮フォーマットは、４ビットによって表される各レングスを用いて、このレングステーブルをコード化するために用いられる。 他の実施例において、そのレングス自身も、可変ハフマンコードを用いてコード化されることができ、ハフマン長のためのコード化を特定するためにデータの始めにさらに他のテーブルが置かれている。 このテーブルは、圧縮されずに含まれている。 なぜなら、繰り返される連続レングス（つまり、ラン）がハフマンコードとしてどのように含まれているか（或いは含まれているかどうか）に応じて、３２個よりも少ないコードが典型的には含まれるからである。

【００９１】割り当てられ出力されたハフマンコードと共に、その後、ハフマンエンコーダは、中間バッファ２
８内のトークンを処理して、各トークンに対するハフマンコードを圧縮された出力データストリーム３６へ出力する。 たいていのストリングトークンは、ハフマンコードの後に添付される余分なビットを必要とする。 先ず、
ストリングオフセットを特定するために必要な余分のビットが出力される。 好ましい実施例において、長さ６以上のストリング（ハフマンビン３１９〜３３４）の後ろには、図１３に示されるように、ストリングオフセットコード化が後続している。 レングス３、４及び５（ハフマンビン２５６〜３１８）のストリングに対するコードの後ろには、図１４に示されるように、特定された余分のオフセットビットの数が後続している。 次に、ストリング長を十分に特定するために必要な余分のビットが出力される。 好ましい実施例において、図１４に示されるように、ハフマンビン３３４のみが余分なレングスビットを必要としている。 他の実施例において、中間バッファに出力トークンを格納する代わりに、元の入力データが、スライディングウインドウ探索アルゴリズムによって再び処理され、最初のスライディングウインドウ探索後に生成されるハフマンコードに基づいて、トークンストリームが、２回目の生成されるようにコード化される。

【００９２】圧縮ユニット４の出力はビットストリームである。 好ましい実施例において、ビットは、１６ビットワードで出力され、第１のビットがワードの最上位ビットであり、連続ビットがワードの最下位ビットまで満たしている。 ワードが満たされると、最下位バイトが最初に出力され、再びワードの最上位ビットから始まる最初のワードが蓄積される。 全てのトークンがコード化されて出力されると、特別のハフマンコード（好ましい実施例においては３３５）が圧縮データの終了を示すために出力され、パッドビットが出力ワードの残りを埋めるために出力される。 最終コードは伸張ユニット６を停止するために用いられる。 他の実施例においては、ビットが８ビットバイトで出力されることも可能であり、或いは、ビットが最下位ビットを先頭として蓄積されることもでき、或いは、ワードが最上位バイトを先頭として出力されることもできる。

【００９３】図３は、スライディングウインドウ探索ブロック２４によるトークン生成の一例を含む単純な結果のテーブルを示している。 テーブルは、２つの列に分けられており、第１列５０は、入力データストリームを示しており、第２列５２は、トークン及び生データの出力ストリームを示している。 トークンを生成させるために必要な最小マッチストリング長は好ましい実施例においては３である。 なぜなら、それが、経験的に最良の結果を与えるようであるからである。

【００９４】第２列５２は、行６０〜７０によって参照される。 第１の入力バイトはキャラクタ「Ａ」であり、
これは以前には現れなかったもので、生のバイト「Ａ」
に対応する出力トークンを有している（行６０）。 次の入力バイトはキャラクタ「Ｂ」であり、これは同様に以前には現れなかったもので（スライディングウインドウ履歴は「Ａ」のみを有している）、従って、生のバイト「Ｂ」に対応する出力トークンを有している（行６
２）。 次の入力バイトはキャラクタ「Ａ」である。 好ましい実施例において、３又はそれ以上を有するストリングのみがマッチするストリングとしてコード化されるので、キャラクタ「Ａ」は、生のバイト「Ａ」として出力される（行６４）。 しかしながら、次の「Ａ」キャラクタが起こると、全ての「Ａ」キャラクタが処理された後に、オフセット１でレングス５を有するマッチするストリングが見いだされる。 従って、対応するトークン（行６６）が生成される。 次の入力バイトは「Ｃ」であり、
これは以前には現れなかったもので、従って、生のバイト「Ｃ」に対応する出力トークンを有している（行６
８）。 次の３つのバイト「ＡＢＡ」は、入力データストリームの先頭のストリングにマッチしている。 従って、
オフセット９でのレングス３のストリングのマッチを示すマッチするストリングのためのトークンが出力される（行７０）。

【００９５】全てのデータ構造（例えば、履歴アレイ１
０２、ハッシュテーブル１００、及びオフセットアレイ１０４（図４））は、ＲＡＭ１６内に維持され、ＲＡＭ
１６は１つ又は多数のＲＡＭユニットを有していることができる。 好ましい実施例において行われる好ましいデータ構造のより詳細な説明は、それらを構築し維持する圧縮ユニット４の説明の間に、以下に説明される。

【００９６】以下に論じられる全ての数値パラメータの値（例えば、ＭＥＭＳＩＺＥ、１６ビットＨＰＴＲサイズ等）が、本発明の圧縮伸張技術の背後にある基本概念に影響を与えることなく修正され得ることを、当業者は認識するであろう。

【００９７】上記実施例において、バイトがマッチしなかった場合には、スライディングウインドウ探索２４
が、入力バイトストリームの履歴アレイを遡って現在の入力バイトまでマッチし、現在の入力バイトを含むストリングを探索する。 そのような新たなストリングが見いだされた場合には、マッチの長さがインクリメントされ、新たなマッチストリングの位置が定められて記憶される。 このように、このストリングマッチが「拡張」されている。 そのような新たなストリングが見いだされない場合には、或いは、非常に多くの以前の入力バイトエントリーが探索されなくてはならない場合には、現在のマッチするストリングが最大のストリングであると見なされ、そのコード化トークンが出力される。 コード化されたトークンは、その長さ及び入力バイトストリームを格納する履歴内の相対位置を含んでいる。 オフセットは、バッファ内のストリングの開始位置からマッチしたバイトまでのバイト数として算出される。 このバイト数は、好ましい実施例においては１からメモリサイズ（Ｍ
ＥＭＳＩＺＥ−１）の範囲である。

【００９８】ハッシング技術は、好ましい実施例においては、効率的なストリング探索を行うために用いられる。 入力バイトストリームに対するストリング探索操作を行うために多くの実現方法があることを当業者は認識するであろう。 特に、マッチするストリングを見いだすために用いられ得る多くのハッシング技術及び探索方法がある。 各種のハッシング技術についての完全な背景に関しては、KnuthのSorting and Searching, The Art of
Computer Programming (Vol. 3) pp. 506-549 (1973)
を参照されたい。 この文献は参考として本明細書に援用されている。 以下は、好ましい実施例によって用いられる特定のハッシング構造の詳細な説明である。 説明されるデータ構造及びアプローチが選択された理由は、それらが、ストリング探索機能のために必要なＲＡＭサイクルの数を最小とし、システムのスループットを最大とするからである。

【００９９】図４を参照して、ハッシュ構造の好ましい実施例が説明される。 すでに処理された（圧縮された、
又は生データとして圧縮されなかった）入力データの最後のＭＥＭＳＩＺＥ（好ましくは２０４８）のキャラクタを包含する履歴アレイ１０２がＲＡＭ１６に格納されている（図１（ａ））。 新たな入力データがスライディングウインドウ探索２４によって受け取られると、本発明は、先ず、新たな入力データ中の少なくとも２バイトの「ストリング」が履歴アレイ１０２中のストリングとマッチするかどうかをチェックする。 マッチすれば、少なくとも３バイト長のマッチするストリングを見いだすように探索が拡張される。 少なくとも３バイト長のマッチするストリングが見いだされると、マッチするストリングを表すトークンが出力される。 少なくとも３バイト長のマッチするストリングが見いだされない場合には、
現在処理されているバイトを表す生データトークンが出力される。

【０１００】ハッシュテーブル１００は、履歴アレイ１
０２中の特定のストリングを素早く見いだすために用いられる。 ハッシュテーブル１００は、履歴アレイ１０２
への履歴アレイポインタを含む一連のエントリで構成されている。 オフセットアレイ１０４と称されている他のデータ構造はハッシュリンクテーブルである。 オフセットアレイ１０４中の各リンクリストの第１の要素は、特定のハッシュ値に対応する履歴アレイ中の前のエントリを指し示している。 リンクリスト中の最後の要素（この要素は無効なポインタであってもよい）はこのハッシュ値に関連付けられた最も古いエントリを指し示している。 スライディングウインドウ探索２４は、各入力バイトが処理された後にインクリメントされる１６ビットの履歴ポインタＨＰＴＲ１０８を維持している。 ＨＰＴＲ
１０８は０に初期化される。 好ましい実施例において、
圧縮操作は、６４Ｋサイズよりも大きなブロックに関しては行われない。 従って、ＨＰＴＲ１０８は、６４Ｋバイトがスライディングウインドウ探索２４によって処理された後に、０へ戻るように「ラップ」する必要はない。 ＨＰＴＲ１０８がラップしないので、ＨＰＴＲ１０
８の「ラッピング」によって無効となったハッシュテーブルからの古いエントリを取り除く必要がない。 オフセットアレイ１０４は実際には単純リンクリストから構成された２次ハッシュである。 ある特定のオフセットがＭ
ＥＭＳＩＺＥ−ＭＡＸＳＴＲ（ここでＭＡＸＳＴＲは探索されている最大のストリングである）よりも大きいか、又はリストの最近のエントリからの全てのリンクの合計がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きい場合には、特定のハッシュビン（値）中に有効なエントリはもはや存在しない。 このようにして、ＭＥＭＳＩＺＥ−
ＭＡＸＳＴＲよりも古いエントリは履歴アレイ１０２の終わりから効果的に「離れ落ちる（fall off）」。 本発明のこの点により、オフセットアレイ１０４中の単純リンクリストの使用を可能にする。 単純リンクリストの維持は、二重リンクリストに比べて半分以下のメモリアクセスによって行うことができる。

【０１０１】図５〜図７及び図８を参照して、本発明のスライディングウインドウ探索の詳細な流れ図が論じられる。 流れ図（図５〜図７及び図８）の特定のデータ経路を示すハード的に配線された版を図９に示す。

【０１０２】より詳細には、図５〜図７において、スライディングウインドウ探索ルーチンがブロック１０９でスタートする。 次に、ブロック１１０では、初期化ルーチン（図８）が呼び出され、図４に示すハッシュ構造が初期化される。 この操作は、新たなウインドウ探索操作のそれぞれの開始時に行われる。

【０１０３】図８において、ブロック１１２では、ハッシュポインタ１０８（ＨＰＴＲ）が０に設定される。 ブロック１１４（図８）では、現在コード化されているビットストリングの現在の長さを追跡するためのマッチ長変数（「ＭＡＴＣＨＬＥＮ」）が０に設定される。 次に、ブロック１２０の間に、ハッシュテーブル１００が値ＨＰＴＲ−ＭＥＭＳＩＺＥで埋められる。 このステップにより、ハッシュテーブル１００の以前の有効な全ての値が効果的に空にされる。

【０１０４】図５〜図７を再び参照すると、初期化ルーチン（図８）の終了後、入力されるデータストリームからのバイトを受け入れるためにスライディングウインドウ探索が始まり得る。 ブロック１２８の間に、操作を初期化するために、履歴アレイ１０２の最初の２つのバイトが入力データで埋められる。 この２バイトは、レジスタＩＮＲＥＧ０及びＩＮＲＥＧ１に保持される。 新たな１バイトが処理される度に、第１バイト及び次の入力バイトのハッシュ（「Ｈ」）が計算される。 好ましい実施例において、ＩＮＲＥＧ０を左に４ビットシフトたものとＩＮＲＥＧ１との排他的論理和を求めることによってハッシュが計算される。 上述のように、Knuth（以前に参照した）によって論じられるいずれのハッシュ関数も適用可能である。 新たな１個の入力バイトが処理される度に、ＩＮＲＥＧ１の内容がＩＮＲＥＧ０へ移され、Ｉ
ＮＲＥＧ１には新たなバイト値がロードされる。

【０１０５】ブロック１２８で処理される各バイトに対して、ハッシュ値Ｈ（「Ｈ」）が計算され、新たなハッシュ値に対応するハッシュリスト内の古いエントリが読み出されてＮＥＸＴと称される変数に格納される。 また、ブロック１２８では、現在のハッシュ値に対応するハッシュテーブル中の古いエントリがＨＰＴＲの現在の値で置換される。 ブロック１４０では、ＨＰＴＲ−ＮＥ
ＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうかが判定される。 変数ＭＡＸＳＴＲは、履歴アレイ１０２
中で見いだされるバイトのマッチするストリングが現在処理されているバイトによって上書きされないことを保証する、探索されている最大ストリングサイズの値である。 ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きいか又は等しい値にであると判定されると、処理はブロック１４
２へ進み、変数ＮＥＸＴはＨＰＴＲ−ＭＥＭＳＩＺＥに等しく設定される。 言い換えると、履歴の最後のＭＥＭ
ＳＩＺＥバイト中にマッチするストリングがなかったため、ハッシュビンが空にされる。

【０１０６】ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きいか又は等しい値となるかどうかの判定に拘らず、処理はブロック１４４へ進む。 ブロック１４４では、値ＨＰ
ＴＲ−ＮＥＸＴが対応するオフセットアレイ１０４のエントリであるＯＦＦＳＥＴ（ＨＰＴＲ）に書き込まれる。 同様に、ブロック１４４では、ＩＮＲＥＧ１の値が履歴アレイ１０２のエントリであるＨＩＳＴＯＲＹ（Ｈ
ＰＴＲ）に置かれる。 上記ブロック１２８、１４０、１
４２及び１４４で行われるステップにより、現在処理されているバイトに必要なデータ構造の保守は完了し、この時点で、履歴アレイ１０２の内容のストリング探索が開始され得る。 スライディングウインドウ探索がストリングマッチを現在処理しているかどうかに拘らず、処理される全ての入力バイトに対して上記ハウスキーピング機能が行われることに注意されたい。 他の実施例において、ハウスキーピング機能の幾つかは、圧縮比率でのわずかなコストでの操作のスループットを増大させるために、処理される入力バイトの幾つかに対してのみ行われる。

【０１０７】ブロック１４６では、マッチ長変数ＭＡＴ
ＣＨＬＥＮが０に等しいかどうかが判定される。 ブロック１１４の初期化ルーチン（図８）ではＭＡＴＣＨＬＥ
Ｎ変数が０に設定されたことを想起されたい。 ＭＡＴＣ
ＨＬＥＮは、現在のストリングマッチ長を包含しており、操作の開始時には０である。 ここで、圧縮操作の開始時での処理を行っており、ＭＡＴＣＨＬＥＮが０である場合には、内部ハッシュカウンタＨＡＳＨＣＮＴが０
に設定される。 ＨＡＳＨＣＮＴは、いずれかの特定のストリング探索の反復を制限するために用いられる。 次に、ブロック１５０では、ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥ
ＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうかが判定される。 得られる値がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも小さいと判定されると、処理はブロック１５２へ進む。
ブロック１５２の間に、変数ＩＮＲＥＧ１が履歴アレイのＨＩＳＴＯＲＹ（ＮＥＸＴ）の値に等しいかどうかが判定される。 このステップの目的は、履歴アレイ中の先行するエントリに対して、ＩＮＲＥＧ０及びＩＮＲＥＧ
１における２バイトにマッチする２バイトストリングを探索することである。 ＩＮＲＥＧ１における値のみがＨ
ＩＳＴＯＲＹ（ＮＥＸＴ）の値と比較される。 なぜなら、ハッシュ機能が、ＩＮＲＥＧ０に対して１対１の写影が行われるように選択されるので、ハッシュリスト中の各ストリングからの１バイトのみがＩＮＲＥＧ１と比較される必要があるからである。 このステップは、本実施例の性能を高める。 なぜなら、２バイト比較に代えて１バイトの比較を行うだけでよいからである。 ブロック１５０においてＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きい又は等しいと判定された場合には、処理はブロック１５８へ進む。 ブロック１５８では、ＩＮＲＥＧ０バイトを示す生のデータバイトトークンが出力され、処理がブロック１２５へ進む。 ブロック１２５では、次の入力バイトが得られ、処理全体が再び開始される。

【０１０８】ブロック１５２においてマッチしていると判定された場合には、処理はブロック１６０へ進み、変数ＭＡＴＣＨＰＴＲが変数ＮＥＸＴの値に等しく設定される。 加えて、変数ＭＡＴＣＨＬＥＮが２バイトマッチを示すように２に設定され、長さ２よりも大きなマッチするストリングが結局ない場合には、ＩＮＲＥＧ０の内容が変数ＯＬＤＲＡＷに格納される。 処理は、ブロック１２５へ進み、そこで、次の入力バイトが得られる。 しかしながら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）での値がマッチしない場合には、処理はブロック１５４へ進み、ＨＡ
ＳＨＣＮＴの値がインクリメントされ、変数ＮＥＸＴがＮＥＸＴ−ＯＦＦＳＥＴ（ＮＥＸＴ）に等しく設定される。 このステップにより、オフセットアレイ１０４によってリンクされている次のエントリが効果的に指し示される。 処理はブロック１５６へ進み、ＨＡＳＨＣＮＴが所定の最大カウント値ＭＡＸＨＣＮＴ（典型的には８）
に達しているかどうかが判定される。 ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きい又は等しい場合には、処理はブロック１５８へ進み、ＩＮＲＥＧ０に対する出力生バイトトークンが出力され、処理はブロック１２５へ進む。 しかしながら、ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きくなく又は等しくもない場合には、ＨＡＳＨＣ
ＮＴがＭＡＸＨＣＮＴ（つまり、好ましい実施例では８）に達するまで、又はハッシュリスト中にそれ以上有効なエントリが存在しなくなるまで（ブロック１５０で判定される）、又はマッチするストリングが見いだされるまで（ブロック１５２）、ブロック１５０、１５２、
１５４及び１５６の処理を継続する。

【０１０９】最終的に、処理はブロック１２５へ進み、
この時点で、スライディングウイントウ探索は、次の入力データバイトを処理する準備ができている。 ブロック１２５では、ＨＰＴＲがインクリメントされる。 ＭＡＴ
ＣＨＬＥＮがブロック１４６で０よりも大きいと判定されるまで、ブロック１２８、１４０、１４２、１４４、
１４６、１４８、１５０、１５２、１５４、１５６、１
５８、１６０及び１２５の処理が継続される。 ブロック１４６では、ＭＡＴＣＨＬＥＮが０に等しくない場合には、処理がブロック１６２へ進むことに注意されたい。
ブロック１６２では、変数ＭＡＴＣＨＰＴＲが１だけインクリメントされる。 このように、新たな値ＩＮＲＥＧ
１は、履歴アレイ１０２中のＭＡＴＣＨＰＴＲにおいて見いだされるＭＡＴＣＨＬＥＮ＋１の長さのストリームにおける次のバイトと比較される。 ブロック１６４では、バイトがマッチしているかどうかの判定がなされる。 バイトがマッチする場合には、ブロック１８０でＭ
ＡＴＣＨＬＥＮがインクリメントされてストリングが拡張され、処理はブロック１２５へ進む。 しかしながら、
バイトがマッチしない場合には、処理はブロック１６６
へ進み、変数ＮＥＸＴがＭＡＴＣＨＰＴＲ−ＭＡＴＣＨ
ＬＥＮ＋１に等しく設定される。 処理は、ブロック１６
８へ進み、変数ＮＥＸＴがＮＥＸＴ−ＯＦＦＳＥＴ（Ｎ
ＥＸＴ）に等しく設定される。 加えて、ブロック１６８
では、変数ＨＡＳＨＣＮＴがインクリメントされる。 ステップ１６６及び１６８は、ハッシュリストの残りの連続するストリングエントリにおいた、マッチがとれる元のストリングを探索するスライディングウインドウ探索を効果的に引き起こす。 ブロック１７０では、ＨＰＴＲ
−ＮＥＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうかが判定される。 ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きいと判定された場合には、有効なエントリはそれ以上存在せず、処理はブロック１２４へ進む。 ブロック１２４では、ＭＡＴＣＨＬＥＮが２よりも大きいかどうかが判定される。 大きくないと判定されると、処理はブロック１２６へ進み、変数ＯＬＤＲＡＷにおける生データバイトを表す出力トークンが出力される。 その後、
ＮＥＸＴはＩＮＲＥＧ１及びＩＮＲＥＧ０の最新のハッシュ値に対応して、ハッシュリストで置換される。 その後、ＭＴＡＣＨＬＥＮが０にリセットされ、処理はブロック１４８から再開される。

【０１１０】ブロック１２４でＭＡＴＣＨＬＥＮが２よりも大きいと判定された場合には、処理はブロック１８
２へ進み、スライディングウインドウ探索２４が、マッチするストリングの長さ（ＭＡＴＣＨＬＥＮ）及び履歴アレイ１０２内でのそのオフセット（ＯＦＦＳＥＴ＝Ｈ
ＰＴＲ−ＭＡＴＣＨＰＴＲ）を表すトークンを出力する。 処理はブロック１８４へ進み、ＭＡＴＣＨＬＥＮが０に設定され、処理は、新たなバイトに対してブロック１２５を開始する。

【０１１１】しかしながら、ブロック１７０においてＭ
ＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも小さいと判定された場合には、処理はブロック１７２へ進み、ＭＡＴＣＨＬ
ＥＮ＞＝ＭＡＸＳＴＲであるかどうかが判定される。 Ｍ
ＡＴＣＨＬＥＮ＞＝ＭＡＸＳＴＲである場合には、探索は限界に達し、処理はブロック１２４へ続く。 しかしながら、ＭＡＴＣＨＬＥＮがＭＡＸＳＴＲよりも大きくなく、等しくもないと判定される場合には、処理はブロック１７４へ進む。

【０１１２】ブロック１７４では、位置ＨＩＳＴＯＲＹ
（ＮＥＸＴ）におけるＭＡＴＣＨＬＥＮ＋１の現在のストリングが内部マッチバッファの内容に等しいかどうかが判定される。 内部マッチバッファは、現在のマッチしているストリングのＭＡＴＣＨＬＥＮ個の全てのバイトを包含している。 このバッファによって、このストリングをマッチさせる最初の試みが失敗しても、新たなストリングの探索が高速化される。 マッチが行われる度にマッチをとろうとするバイトを得るためにＲＡＭにアクセスする必要はなく、マッチをとろうとするバイトがチップ内で即座に利用可能であるので効率的である。 言い換えると、マッチバッファは、処理を効率的に向上するためのルックアサイド（ｌｏｏｋ ａｓｉｄｅ）バッファとして機能する。 マッチバッファの長さは有限である（好ましい実施例においてＭＡＸＳＴＲ＝８バイト）。

【０１１３】ＨＩＳＴＯＲＹ（ＮＥＸＴ）におけるＭＡ
ＴＣＨＬＥＮ＋１のストリングがマッチバッファの内容に等しい場合には、処理はブロック１７８へ進み、変数ＭＡＴＣＨＰＴＲがＮＥＸＴ＋ＭＡＴＣＨＬＥＮに等しく設定される。 処理はブロック１８０へ進み、そこで、
ＭＡＴＣＨＬＥＮがインクリメントされ、処理はブロク１２５へ進む。 ブロック１２５では、入力データストリームにおける次の新たなバイトが処理される。 しかしながら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）におけるストリングがマッチバッファに等しくない場合には、処理がブロック１７６へ進み、変数ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴ
よりも大きい又は等しいかどうかに関する判定がなされる。 ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きい又は等しい場合には、処理はブロック１８２及び１８４へ進み、履歴アレイにおけるマッチの長さ及びオフセットを含むマッチストリングトークンが出力され、変数ＭＡＴ
ＣＨＬＥＮが０に設定される。 処理は、ブロック１２５
へ進み、次の新たな入力データバイトが処理される。 しかしながら、ブロック１７６においてＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きくなく又は等しくもない場合には、処理は、ＭＡＴＣＨＬＥＮ＋１の長さのマッチが見いだされるまで、又はＨＡＳＨＣＮＴがＭＡＸＨＣＮ
Ｔに達するまで、又は有効なハッシュエントリがそれ以上存在しなくなるまで（ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥＭ
ＳＩＺＥ−ＭＡＸＳＴＲ）、ブロック１６８、１７０、
１７２、１７４及び１７６の処理を継続する。

【０１１４】好ましい実施例において、上記操作は、Ｒ
ＡＭ１６（図１（ａ））が全てのクロックサイクルでも使用中であることを保証するために、パイプライン化される。 なぜなら、ＲＡＭサイクルカウントが性能を制限する要因であるからである。

【０１１５】典型的には、記憶システムにおいて、データは、一定サイズのセクタ又はブロックへ分割されなくてはならず、所定段階で圧縮が切り捨てられ、次に、残りの入力ストリームに関する新たな処理が再スタートする。 圧縮ユニット４はその後、後述される特別な「圧縮データの終わり」トークンを出力する。

【０１１６】本発明がなされる過程において、圧縮方法の広範なソフトウエアシミュレーションが行われた。 Ｍ
ＡＸＨＣＮＴ、ＨＡＳＨＳＩＺＥ、マッチバッファサイズ及びＭＥＭＳＩＺＥを含む全てのパラメータの値が変化させられて、スループット及び圧縮比に対するそれらのパラメータの影響が調べられた。 好ましい実施例の特定の形式及びパラメータの組は、これらの性能上の論点に対して受け入れ可能なトレードオフが得られるように選択された。 しかし、多くの類似のパラメータの組及びコード化は実質的に同様の性能に帰着する。

【０１１７】図９に、好適な実施態様におけるスライディングウインドウ探索２４（図２）および出力トークンの生成を含む回路図２２８を示す。 回路２２８の要素はデジタル論理によって実現される。 回路２２８は、圧縮コントローラ兼シーケンスユニット２３０によって制御される。 圧縮コントローラ兼シーケンスユニット２３０
は、回路２２８の要素のそれぞれに一連の制御ライン（図示せず）によってリンクされている。 好適な実施態様では、毎秒数メガヘルツで作動する内部クロック（図示せず）は、作動中の各クロックサイクルにおいて１個以上の要素に働きかけるコントローラ兼シーケンスユニット２３０の活性化レベルを定める。 実際の作動およびそれらのシーケンスは、すでに論じた図５〜図７および図８に示されている。

【０１１８】回路２２８におけるデータフローのより詳細な説明を行う。 入力バイトストリームの圧縮されていないバイトは、圧縮ユニット４に入力され、ライン２４
４を介して入力ＦＩＦＯ２３２に与えられる。 入力ＦＩ
ＦＯ２３２に格納されたバイトは、２個の拡張ＦＩＦＯ
レジスタＩＮＲＥＧ１（２３３）およびＩＮＲＥＧ０
（２３５）に転送される。 より詳細には、ＦＩＦＯ２３
２からのデータはライン２４６を介してＩＮＲＥＧ１レジスタ２３３に与えられる。 ＩＮＲＥＧ１レジスタ２３
３に格納されたデータは、次にライン２４８および２５
０を介してＩＮＲＥＧ０レジスタ２３５に転送される。
ＩＮＲＥＧ１およびＩＮＲＥＧ０レジスタの目的はハッシュ関数２３７への入力を発生することにあることを想起されたい。 ハッシュ関数２３７の出力はライン２５５
を介してマルチプレクサ２５６へ伝送される。

【０１１９】ＩＮＲＥＧ１レジスタ２３３において、マッチングストリングが見い出せない場合には、それはライン２４８、２５４、および２５８を介して出力管理部２６０へ送られる。 出力管理部２６０の目的は、生のデータバイトおよびマッチングストリングの出力トークンを生成することにある。 出力管理部２６０の出力は、ライン２６２を介してビットバイト変換器２６４へ伝送される。 次にこのデータはライン２６８を介して出力ＦＩ
ＦＯ２３４に入力される。 出力トークンは、出力ＦＩＦ
Ｏ２３４からライン２７０を介して中間バッファ（図２
の２８）へ出力される。

【０１２０】ＩＮＲＥＧ１レジスタ２３３の内容はまた、ライン２４８、２５４、および２７２を介して内部マッチバッファ２７４へ送られる。 内部マッチバッファ２７４の目的は、マッチングプロセスの能力を効果的に向上させるための「ルックアサイド（lookaside）」バッファとして機能することにある。 マッチバッファ２７
４の内容はバイト比較レジスタ２７６の内容と比較される。 マッチバッファの内容は、ライン２７８上に多重化されてバイト比較レジスタ２７６へ送られる。 バイト比較レジスタ２７６の内容は外部のＲＡＭ２３８内に格納されている履歴アレイ１０２（図４）から得られる。 履歴アレイのエントリの内容は、ライン２８０を介してラッチ２８２に入力され、次に、ライン２８４および２８
６を介してバイト比較レジスタ２７６へ送られる。 ブロック２７６によって実行されるバイト比較の結果は、ライン２８８を介して圧縮コントローラ兼シーケンスユニット２３０に伝達される。 圧縮コントローラ兼シーケンスユニット２３０は比較結果を評価し、制御ライン（図示せず）を介して回路２２８の様々な要素に適切な制御信号を送り出す。

【０１２１】ＩＮＲＥＧ０レジスタ２３５の内容はまた、ライン２５１および２９０を介してマルチプレクサ２９２へ送られ得る。 マルチプレクサ２９２は調停を行い、ＩＮＲＥＧ０の内容をライン２９４を介してラッチ２９６へ送る。 ラッチ２９６の内容は、ライン２９８を介してＲＡＭ２３８内のデータ構造の履歴アレイ１０２
（図４）へ出力される。

【０１２２】ライン２８０を介してＲＡＭ２３８から入力されるデータはまた、ラッチ２８２並びにライン２８
４、３００、および３０２を介してレジスタ３０４へ送られる。 このパス上のデータは、ＮＥＸＴと称される変数に格納された古いハッシュポインタを含んでいる。 レジスタ３０４の内容は、ライン３０５、３０６、および３０７を介してマルチプレクサ２５６へ出力される。 レジスタ３０４の出力はまた、ライン３０５および３０８
を介してオフセットレジスタ３１０に与えられる。 オフセットレジスタ３１０の機能について簡単に説明する。
レジスタ３０４の内容はまた、ライン３０４、３０５、
３０６、および３１２を介してＭＡＴＣＨＰＴＲのための変数内容を含むレジスタ３１４へ送られる。 レジスタ３１４の出力（ＭＡＴＣＨＰＴＲ）は、ライン３１６を介してマルチプレクサ２５６へ送られる。 レジスタ３１
８の目的は、ポインタＨＰＴＲをインクリメントすることである。 レジスタ３１８の出力は、ライン３２０および３２２を介してマルチプレクサ２５６へ送られる。 他に、レジスタ３１８の出力はまた、ライン３２０および３２４を介してオフセットレジスタ３１０へ送られる。
オフセット関数の目的は、履歴アレイ中の適切なオフセットを計算すること、またはライン３２４および３０８
を介してレジスタ３１８および３０４から入力されるデータからＨＰＴＲ−ＮＥＸＴを計算することにある。

【０１２３】修正スイッチ３２８はライン３３０を介してオフセットレジスタ３１０に与えられ、これによってオフセット関数はライン３２４を介して入力される現在のＨＰＴＲのみを出力するようになる。 修正スイッチ３
２８が、オフセット関数が定められるように設定された場合には、オフセット関数３１０の出力は、マルチプレクサ２９２または出力管理部２６０のいずれかに送られる。 その出力が出力管理部２６０へ送られる場合には、
それはライン３３２および３３６を介して送られる。 オフセットは出力管理部２６０においてコード化ストリングにコード化される。 他方、その出力はライン３３２および３３４を介してマルチプレクサ２９２へ送られ、次にライン２９４を介してラッチ２９６へ、そしてライン２９８を介してＲＡＭ２３８へ出力される。 しかし、修正スイッチ３２８がオフセットレジスタ３１０の出力が現在のＨＰＴＲであるように設定された場合には、その出力は、ライン２９４上の出力を調停するマルチプレクサ２９２へライン３３２および３３４を介して送られる。

【０１２４】出力管理部２６０へのコード化のための長さ入力は、回路図２２８の最下部に示されているレジスタ３３８によって維持されている。 レジスタ３３８の出力はライン３４０を介して出力管理部２６０に与えられる。 マルチプレクサ２５６の目的は、ＲＡＭ２３８内の適切なデータ構造を選択するために、ライン３１６、３
２２、３０７および２５５上のアドレスの内のいずれを出力するかを調停することにある。

【０１２５】図１０を参照して、入力および出力ＦＩＦ
Ｏの使用について説明する。 入力ＦＩＦＯ２３２（図９）および出力ＦＩＦＯ２３４（図９）を、圧縮ユニット４の入力および出力側に示す。 入力および出力ＦＩＦ
Ｏは好ましくは、圧縮ユニット４および伸張ユニット６
と同じチップ内にある。

【０１２６】図１１に、本発明の圧縮されたデータ出力フォーマットを４００として示す。 圧縮されたデータ出力フォーマット４００は、圧縮されたハフマン長テーブル４０２およびコード化されたハフマントークン４０４
から構成される。 コード化されたハフマントークン４０
４は、生のデータバイトまたはハフマン長テーブルに従ったマッチングストリングを表現している。 図１１にも示す各コード化されたハフマントークン４０４はハフマンビンコード４０６を有している。 ハフマンビンコード４０６が１より多い可能なオフセットを有するマッチングストリングを示すなら、コード化されたハフマントークン４０４はまた、特定のハフマンビンコード４０６に対するストリングの正確なオフセットを示す余分なオフセットビット４０８を有する。 同様に、ハフマンビンコード４０６が１より多い可能な長さを有するマッチングストリングを示すなら、コード化されたハフマントークン４０４はまた、特定のハフマンビンコード４０６に対するストリングの正確な長さを示す余分な長さビット４
１０を有する。

【０１２７】ほとんどのデータにおいて、ストリングの大部分が長さ３、４、または５であることが経験によって判明している。 このため、好適な実施態様では、これらのストリング長は複数のハフマンビンに分割され、これによりオフセット分布に対するハフマンコードのより良いマッチングが可能となっている。 ハフマンビン内のこれらのストリングの長さおよびオフセットを組み合わせなければ、ストリングのハフマン丸め誤差はより有意なものとなる。 例えば、これらの長さのストリングに対するトークン確率によれば（オフセットを無視して）、
大抵が２〜５ビットの長さを有するハフマンコードを導いている。 長さおよびオフセットを基にしてこれらのビンを分割すると、これらのビンのハフマン長は典型的には６〜１０ビットの範囲である。 このビン分割によって得られる余分なコーディング効率により、ほんの２Ｋバイトのウインドウサイズでもってしても良好な圧縮比率が得られる。 また、より大きいウインドウを用いると、
組み合わせたビンを用いない場合よりも組み合わせた長さ／オフセット対を用いる方がわずかに高い圧縮比率が得られた。

【０１２８】図１２は、本発明に従ったトークンビンの配列の一例を示す表である。 列４５０はハフマンビンの数を示し、列４５２は各ビンによって表現されているものの記述を示し、また列４５４は、存在するならば、各ビンによって表現されているオフセットの範囲内での正確なオフセットを特定する必要がある余分なオフセットビットの数を示している。 例えば行４６２はハフマンビン０から２５５がコード０から２５５を有する生のバイトを表現することを示している。 生のバイトコードはＡ
ＳＣＩＩまたは他の類似のコード体系から決定され得る。 生のバイトはマッチングストリングではないので、
ハフマンビン０から２５５は余分なオフセットビットを必要としない。 別の実施例では、行４６４はハフマンビン２５６から２５８が１のオフセットを有している長さ３、４、および５のマッチングストリングそれぞれを表現していることを示している。 １つのオフセット値のみがハフマンビン２５６から２５８のそれぞれによって示されるので、これらのビンは余分なオフセットビットを必要としない。 さらなる実施例では、行４６６はハフマンビン２９５から２９７が１２８から１９１の範囲のオフセット値を有する、長さ３、４、および５のマッチングストリングそれぞれを表現していることを示している。 １２８から１９１の範囲にある６４個のオフセット値の何れが所定の出力トークンによって表現されるかを特定するために、６つの余分なオフセットビットが必要とされる。

【０１２９】さらに別の実施例では、行４６８がハフマンビン３１９から３３３が長さ６から２０のマッチングストリングそれぞれを表現することを示している。 ６以上の長さを有するマッチングストリングに対するオフセットを特定するために必要とされる余分なオフセットビットを図１３に示し、以下に説明する。 さらに別の実施例では、行４７０はハフマンビン３３４が長さ２１以上のストリングを表現することを示している。 このビンは１つの特定の長さより長いストリングを表現しているため、余分な長さビットはこのビンを含有するトークンによって表現される特定の長さを特定する必要がある。 このビン中のマッチングストリングの長さを特定する必要がある余分な長さビットを図１４に示し、以下に説明する。 長さが６以上のマッチングストリングのオフセットを特定する必要がある余分なオフセットビットを図１３
に示し、以下に説明する。 最後の実施例では、行４７２
はハフマンビン３３５が圧縮されたデータマーカーの末端部を表現することを示している。 明らかに余分なオフセットビットは必要とされない。

【０１３０】当業者であれば、基本圧縮技術を変えることなく、本明細書に記載の全てのパラメータ（例えば、
ＭＥＭＳＩＺＥ、特定のビン配列等）の値を改変し得ることを認識するだろう。

【０１３１】好適な実施態様では、長さが６以上の全てのストリングは図１３に示す固定オフセットコード化を用いている。 別の実施態様では、長さが６以上のストリングもまた、好適な実施態様において長さ３、４、および５のストリングに用いられたものと同様の、組み合わせたストリング長およびオフセット範囲を持つビンを有し得る。 しかし、ほとんどのストリングが長さ５以下であるため、追加のハフマンテーブルエントリを格納するために必要とされる余分なスペースは、より長いストリング上におけるより良いコーディングによる利得と匹敵するものであり、そのような実施態様においては、圧縮比率において極めて適度な利得が得られたことが、経験により判明した。 同様に、別の実施態様において２バイトである最小のストリング長を用いると、ほとんどまたは全く圧縮比率利得が経験的に観察されなかったが、これは生のバイト上のハフマンがストリングコード化と同様に長さが２のストリングを典型的にコード化するためであろう。

【０１３２】図１３の５０２に示すように、１から３２
の範囲のオフセットが２つのビット「００」およびそれに続く５ビットからなる余分なオフセットビットにより表現されている。 ５０４に示すように、３３から１６０
の範囲のオフセットが２つのビット「０１」およびそれに続く７ビットからなる余分なオフセットビットで表現されている。 ５０６に示すように、１６１から６７２の範囲のオフセットが２つのビット「１０」およびそれに続く９ビットからなる余分なオフセットビットで表現されている。 ５０８に示すように、６７３から２０４７の範囲のオフセットが２つのビット「１１」およびそれに続く１１ビットからなる余分なオフセットビットで表現されている。

【０１３３】図１４に、長さが２１以上であるストリングの長さを表現するために用いた余分な長さビットの配列の一例を表にして示す。 ５２０の列は可能なストリング長を示しており、５２２の列は所定の長さを特定するために用いられる対応する余分な長さビットを示している。

【０１３４】図１５に、ハフマン長からハフマンコードを割り当てるアルゴリズムをＣプログラム言語で記載する。 ５４０において、一例であるサブルーチンを通過した変数を定義する。 変数「lengths」は各コードの長さの配列である。 変数「codes」は、サブルーチンによって生成される割り当てられたハフマンコードの配列であり、それぞれ３２ビットを限度とする。 変数「size」は「lengths」配列中のエントリ数を表現する整数である。 ５４２において、サブルーチンの頻度カウントが初期化される。 ５４４において、各長さの頻度がカウントされる。 ５４６において、ベースコードが割り当てられる。 ５４８において実際のハフマンコードがビンに割り当てられる。

【０１３５】図１６において、本発明に従ってハフマン長さテーブルをコード化するために用いられるランレングス符合化の使用法を示す。 長さテーブル５７０は種々のセグメント５７２を含有する。 セグメント５７２は、
ゼロカウント５７４、非ゼロカウント５７６および非ゼロ長さ５８０を有している。 ゼロカウント５７４および非ゼロカウント５７６はそれぞれカウント５７８を有している。 カウント５７８はゼロまたは非ゼロカウントを表現する。 カウント５７８は図１６に示すようにコード化される。 「００００」のカウントは全テーブルの末端部を表現する。 カウント「０００１」から「１１１０」
はカウント１から１４をそれぞれ表現する。 カウント１
５から２７０は「１１１１」およびそれに続く８ビットからなるカウントによって表現される。 非ゼロ長さ５８
０は図１６に示すようにコード化される。 「００００」
の非ゼロ長さは全テーブルの末端部を示す。 「０００
１」から「１１１１」の非ゼロ長さは１から１５の非ゼロ長さをそれぞれ表現する。

【０１３６】テーブルの符合化の一例を５８２に示す。
実施例において示す全ての数量は４ビットニブルである。 一例である長さテーブル５８４はコード化される以下の長さを含有する：０、０、０、０、８、９、１、
０、５、４、０、０、０。 テーブルの最初のセグメントは４、３、８、９、１、であり、それは４つのゼロ、３
つの非ゼロ、および３つの非ゼロ長さ８、９、１を表現している。 テーブルの第２のセグメントは１、２、５、
４、であり、それは１つのゼロ、２つの非ゼロ、および２つの非ゼロ長さ５、４を表現している。 テーブルの最後のセグメントは３、０であり、それは３つのゼロおよびテーブルの末端部を表現している。

【０１３７】図１７〜図２２を参照して、小さな入力ストリームに対する圧縮ユニット４の簡潔化されてはいるが完全な出力例の段階を、好適な実施態様におけるコード化方法を用いて、説明する。 この場合、入力ストリームのサイズは図に示すにはあまりに小さいため、出力データストリームは実際には入力データストリームより大きい。 しかし、この例は、どのように圧縮符合化ステップが実行されるかを正確に説明するのに役立つ。

【０１３８】図１７に、一例として、ＡＳＣＩＩテキストのフレーズ"this is a small small example"を示している。 列６００に、スライディングウインドウ探索によって生成されたトークンを挙げている。 列６０２に、
各トークンに対応するハフマンビンを図１２に示すハフマンビン配列に従って表記する。

【０１３９】図１８において、列６１０にハフマンビンを数値順に表記する。 列６１２に列６１０の各ビンに対するビンカウントを表記する。 列６１４に列６１０の各ビンに対するハフマン長を表記する。 列６１６に、列６
１０の各ビンに対して割り当てられたハフマンコードを表記する。

【０１４０】図１９に、圧縮されたハフマンテーブルを示すが、全ての数値は１６進法ニブルで表している。 圧縮されたテーブルのセグメントを列６２０に表記する。
各テーブルセグメントに対応する記述を列６２２に載せる。

【０１４１】図２０に、コード化されたトークンのビットストリームを列６３０に示す。 対応するコード化されていないトークンを列６３２に表記する。

【０１４２】図２１に、テーブルおよびコード化されたトークンからなる出力バイトストリーム６４０を示す。
図２２に、出力ワードにプットバック（put back）された出力バイトストリーム６４０からなる、出力ワードストリーム６４２を示す。

【０１４３】図２３に、本発明に従ってコード化された伸張データの伸張操作を表わすフローブロック図を示す。 伸張操作は圧縮操作より簡潔であるが、それは主としてストリング探索が必要でないこと、およびデータが中間バッファなしに１回のパスで処理され得るためである。

【０１４４】伸張操作はブロック７００において開始し、伸張ユニット６が圧縮された入力ストリームからハフマン長テーブルを読み込む。 これらの長さは圧縮されたフォーマット内に格納されているため、それらは圧縮ユニット４に用いられる方法に従って圧縮された入力ビットストリームから伸張される。 好適な実施態様においては、図１６のランレングス符合化が用いられるが、他の多くの技術もまた使用可能である。 公知の各ハフマンビンに対するコードの長さを用いて、処理はブロック７
０２に進み、図１５に示すアルゴリズムを用いて、ハフマンコードが各ビンに割り当てられる。 トークンビンに対するハフマンコードの場合、処理はブロック７０４に進み、トークンをデコードするためにハフマンツリーが構築される。 好適な実施態様では、ハフマンツリーは図２４の７５０に示すように、記憶装置中のデータ構造によって表現される。 ツリーを７５６に図示する。 対応するハフマンコードを７５８に列挙する。 データ構造７
５０の各メモリセルの内容は２つのフィールド、タグビットフィールド７５２および子／ビンフィールド７５４
からなる。 メモリセル中のタグビットはセルがツリーの葉を含有しているか、または子があるかを知らせる。 タグビットが子があることを示すと、セルの残りのビットが左側の子のメモリアドレスＮを与え、右側の子がアドレスＮ＋１に現れる。 タグビットがこれがハフマンツリーの葉であることを示すなら、メモリセルの残りのビットは葉に関連したハフマンビン数を含有している。 好適な実施態様では、メモリ幅は、１つのタグビットおよび１０のアドレスビットからなる少なくとも１１のビットである。 好適な実施態様では、３３６＊２メモリセルのみが実際に完全なツリーを含むことを要求され、これが１０ビットのアドレスを必要としている。

【０１４５】圧縮された入力データストリームからトークンを抜き出し、それらをデコードするために、一度に１ビットずつが読みだされる。 開始メモリアドレスがＭ
＝０に設定される。 ビットがゼロなら、左ノード（アドレスＭ）の内容が検査される。 ビットが１なら、右ノード（アドレスＭ＋１）の内容が検査される。 問題のノードが葉でないなら、ＭはＮ（そのメモリセルの残りのビット）に等しくなるように設定され、ツリートラバーサルが、この方法で葉ノードが見つかるまで継続される。

【０１４６】ハフマンビンが生のバイトに相当するなら、伸張ユニット６は生のバイトを出力する。 ハフマンビンがストリングに相当するなら、ストリングオフセットおよび長さを特定する必要がある余分なビットが入力データストリームから抜き出される。 次にストリングが、一度に１バイトずつ出力される。 好適な実施態様では、ほとんどのスライディングウインドウ伸張体系でそうであるように、これは最後のＭＥＭＳＩＺＥバイト出力の履歴アレイを維持し、バイトを引き出すオフセットにより履歴アレイ中へインデックスバック（indexing b
ack）することにより行われる。 出力された全てのバイト、生のバイトまたはストリングバイトのいずれかが、
履歴アレイに加えられる。 ハフマンビンが圧縮されたデータマークの末端部に対応するなら、伸張ユニット６は停止する。 そうでなければ、各ストリングまたは生のバイトを処理した後、トークンを抜き出す処理は、入力ストリームが消耗するまで、または圧縮されたデータマークの末端部が見つかるまで継続される。

【０１４７】別の実施態様では、ハフマンテーブルがマルチビットルックアップテーブルとして構築され、さらに速い操作を可能とする。 ビットの定数（Ｋ）が入力ストリームから抜き出され、２ ^kエントリを有するテーブル中でルックアップするために用いられる。 テーブルサイズは典型的には５１２または１０２４エントリであり、Ｋ＝９または１０に相当する。 各テーブルエントリはコード長（Ｌ）を含有しており、実際に必要とされるビット数を知らせる。 このコード長がＫ以下であれば、
抜き出されたビットはハフマンビンを独特の方法で同定するに充分なものであり、またテーブルエントリの残りはハフマンビン数を特定する。 この場合、入力データストリームから抜き出されたＫ−Ｌビットは実際には必要でないため、それらはハフマンビン処理を進める前に入力ストリームに効果的に「プットバック」された。 ＫがＬよりも大きければ、テーブルエントリの残りは、好適な実施態様において上述したように、一度に１ビットずつ、トラバースされるハフマンサブツリーの残りのメモリ位置（Ｎ）を特定する。 一般にテーブルの葉エントリは２ ^(KL)回反復される。 この技術は、ほとんどのハフマンビンが、ハフマンコード長の１ビット当り１メモリサイクルではなく、１回のメモリサイクルにより抜き出されることを可能にし、伸張プロセスの実質的なスピードアップを導いている。

【０１４８】図２３において、一度ハフマンツリーが構築されると、処理はブロック７０６に進み、圧縮された入力データストリームから次のハフマンコードが抜き出され、そのコードで表現されたビンを決定するハフマンコードに対するデータ構造へと続く。 次に、ブロック７
０８において、ハフマンビンが生のバイトであるかが決定される。 生のバイトであれば、処理はブロック７１０
に進み、生のバイトが伸張データストリームに出力される。 次に処理はブロック７０６に戻る。

【０１４９】ブロック７０８において、ハフマンビンが生のバイトでないと決定されると、処理はブロック７１
２に進み、ハフマンビンが「圧縮されたデータの末端部」マーカであるか否かが決定される。 是であれば、処理は終了し伸張は完了する。 否であれば、処理はブロック７１４に進み、特定のハフマンビンにとって必要であれば余分なストリングオフセットビットが抜き出される。 次に処理はブロック７１６に進み、特定のハフマンビンにとって必要であれば余分なストリング長ビットが抜き出される。

【０１５０】次に処理はブロック７１８に進み、マッチングストリングの次のバイトが、所定のオフセットおよび長さで伸張ユニット６により維持された履歴アレイから出力される。 次に処理はブロック７２０に進み、出力されるマッチングストリング内に他にバイトがあるかが決定される。 あるならば、処理はブロック７１８に戻り、次のバイトが出力される。 マッチングストリング内に他にバイトがなければ、処理はブロック７０６に戻り、次のハフマンコードが抜き出される。

【０１５１】本発明を例を挙げて、好適な実施態様により説明してきたが、本発明はそれらに限定されるものではない。

【０１５２】

【発明の効果】本発明によれば、完全に適合性があり、
予め初期化されたコード化テーブルを必要とせず、コンピュータファイルのようにバイトに適応したキャラクタストリームを最適化するデータ圧縮が達成される。

【図面の簡単な説明】

【図１】（ａ）は、本発明による、未圧縮データを受け取り圧縮データを出力する圧縮ユニットを示すブロック図、（ｂ）は、本発明による、圧縮データを受け取り伸張データを出力する伸張ユニットを示すブロック図である。

【図２】本発明によって動作するように構成された圧縮ユニットのブロック図である。

【図３】本発明による出力トークンの生成の例を示す図である。

【図４】入力データストリームに関してマッチするストリングの探索を行うための、本発明の好ましい実施例によって実行されるデータ構造を示す図である。

【図５】入力データストリームから出力トークンを生成させるためのスライディングウインドウ探索を示す流れブロック図である。

【図６】入力データストリームから出力トークンを生成させるためのスライディングウインドウ探索を示す流れブロック図である。

【図７】入力データストリームから出力トークンを生成させるためのスライディングウインドウ探索を示す流れブロック図である。

【図８】図４に示されるデータ構造のハッシュテーブルを初期化するためのスライディングウインドウ探索（図５〜図７）の間に参照される初期化ルーチンの流れブロック図である。

【図９】本発明のスライディングウインドウ探索及び出力トークン生成をハード的配線で示した概略ブロック図である。

【図１０】入力及び出力ＲＡＭＦＩＦＯを示すブロック図である。

【図１１】本発明において用いられる圧縮フォーマットを示す図である。

【図１２】本発明による、トークンビンの割当ての一例を示す表である。

【図１３】図１２の例のハフマンビン割当てによる６及びそれ以上のストリングの長さに対する余分なオフセットビットのコード化の一例を示す図である。

【図１４】図１２の例のハフマンビン割当てによって単一ハフマンビンに割り当てられる２１及びそれ以上のストリングの長さに対する余分なレングスビットのコード化の一例を示す図である。

【図１５】ハフマンレングスからハフマンコードを割り当てるためのアルゴリズムを示す図である。

【図１６】本発明によるハフマンレングスをコード化するために用いられるランレングスコード化の使用を示す図である。

【図１７】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図１８】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図１９】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図２０】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図２１】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図２２】本発明による圧縮コード化の簡単化された例のステージを示す図である。

【図２３】本発明によるコード化データを伸張するための伸張動作を示す流れブロック図である。

【図２４】本発明によるコード化データを伸張するための伸張ハフマンツリーデータ構造を示す図である。

【符号の説明】

２３０ 圧縮コントローラ兼シーケンスユニット ２６０ 出力管理部 ２７４ 内部マッチバッファ ３３８ レジスタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダグラス エル． ホワイティング アメリカ合衆国 カリフォルニア 92009, カールズバッド，フェボ コート 3312 (72)発明者 グレン エイ． ジョージ アメリカ合衆国 カリフォルニア 91106, パサデナ，ピー． オー． ボックス 60545 (72)発明者 グレン イー． アイビー アメリカ合衆国 カリフォルニア 91106, パサデナ，サウス ミシガン ナンバー 202 146