【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は一般に、ディジタルデータの圧縮および圧縮解除に関し、特に、辞書を使用して圧縮データを記憶する無損失圧縮および圧縮解除方法と装置の実施、およびネットワークパケット通信への圧縮／圧縮解除技術の適用に関する。

【０００２】

【従来の技術】多くの種類の圧縮機構は、２進シーケンス、即ち「コードワード」を使用して多数キャラクタのストリング（以下、多数キャラクタストリングと称す）
を符号化する。 このコードワードは、それ以外の場合には、個々のキャラクタの符号化に使用されることはない。 ストリングは、１つの「アルファベット」、即ち単一キャラクタのストリング（以下、単一キャラクタストリングと称す）から構成されている。 このアルファベットは、圧縮装置が処理を行う最小の一意の情報片を表現するものである。 従って、キャラクタの表現に８ビットを用いるアルゴリズムは、そのアルファベット中に256
の一意のキャラクタを有することになる。 圧縮は、符号化機構において表現された多数キャラクタストリングがデータストリームの所与のファイル中で発生する場合に有効なものである。 人の言語間の翻訳に使用される二カ国語の辞書との類比により、未圧縮コードと既圧縮コードとの間のマッピングを行う装置は、一般に「辞書」と呼ばれている。

【０００３】一般に、辞書ベースの圧縮機構の有用性は、多数キャラクタストリングに関する辞書項目が使用される頻度によって決まる。 或る一定の辞書が１つのファイル形式について最適化された場合にその辞書が別の形式のファイルについても最適化されるという可能性はまずない。 例えば、新聞のテキストファイルに見られるような多数のキャラクタ組み合わせを含む辞書は、データベースファイル、スプレッドシートファイル、ビットマップグラフィックファイル、コンピュータ支援設計ファイル等を効率よく圧縮する可能性のまずないものである。

【０００４】所与の入力データを圧縮するために使用される辞書がその入力データの圧縮中に生成される適応型圧縮機構は既知のものである。 未圧縮の入力データ中に含まれ得るあらゆる単一キャラクタを表すコードワードが辞書に入力される。 ファイル中で多数キャラクタストリングに遭遇した際に、別の項目が辞書に追加される。
その別の辞書項目は、それ以降に発生する多数キャラクタストリングの符号化に利用される。 例えば、現在の（以下、カレントと称す）入力パターンの突き合わせは、辞書中に現在存在するフレーズに対してのみ試行される。 突き合わせが失敗する毎に、新たなフレーズが辞書に追加される。 この新たなフレーズは、突き合わせが行われたフレーズを１つの記号（例えば、その突き合わせを「中断させる」入力記号）で拡張することにより形成される。 辞書が発達するにつれて、ファイル中で最も頻繁に発生する多数キャラクタストリングに遭遇する程度まで、圧縮が行われる。

【０００５】圧縮解除時には、辞書が同様にして構成される。 従って、既圧縮ファイル中で或るキャラクタストリングについてのコードワードに遭遇した場合、辞書は、対応するキャラクタストリングを再構成するために必要な情報を含んでいる。 辞書を使用して圧縮および圧縮解除情報を記憶する、広範に利用されている圧縮アルゴリズムとして、ＬＺ１と呼ばれているLempelの第１の方法、および、ＬＺ２と呼ばれているZivの第２の方法が挙げられる。 Lempel-Ziv（ＬＺ）アルゴリズムは、
「On the Complexity of Finite Sequence」(IEEE Tran
sactions on Information Theory, IT-22:75-81, Jan.
1976)、および「A Universal Algorithm forSequential
Data Compression」(IEEE Transactions on Informati
on Theory,IT-23:337-343, May 1977)、および「Compre
ssion of Individual Sequences via Variable Rate Co
ding」(IEEE Transactions on Information Theory, IT
-24:530-536)において、Lempel、Ziv両氏により最初に発表されたものである。 辞書の使用については、Eastma
n等の米国特許第4,464,650号明細書にも開示されており、更に、そのアルゴリズムの様々な改良策が、Welch
の米国特許第4,558,302号明細書、およびMiller等の米国特許第4,814,746号明細書に開示されている。

【０００６】実際の装置での実施時には、圧縮／圧縮解除に利用可能な記憶装置の量は有限のものである。 従って、辞書中の項目の数は有限であり、項目の符号化に用いるコードワードの長さが制限される。 一般に、コードワードの長さは12〜16ビットの範囲にある。 入力データシーケンスが充分に長い場合、辞書は最終的に「一杯」
の状態になる。 この時点では幾つかの動作が可能である。 例えば、その現状のまま辞書を凍結させて残りの入力シーケンスに利用することができる。 第２のアプローチでは、辞書をリセットして、スクラッチにより新たな辞書が作成される。 第３のアプローチでは、圧縮率が低下するまで辞書が一定期間だけ凍結され、次いで辞書がリセットされる。 辞書をリセットする別の戦略については、1992年6月1日出願の米国特許出願第07/892,546号「Lempel-Ziv Compression Scheme with Enhanced Adap
tion」（本引用をもってその開示内容を本明細書に包含させたものとし、その詳細な説明は省略する）、および
Bunton,S.等の「Practical Dictionary Management for
Hardware Data Compression」(Communications of the
ACM, 35:95-104, Jan. 1992）に記載されている。

【０００７】ＬＺＷプロセスの場合、辞書は、圧縮辞書の構成に使用される単一キャラクタストリングについて初期設定されなければならない。 それらのキャラクタには、圧縮／圧縮解除装置中の一意のコードが割当てられる。 これは、エンコーダから送出される任意の別の出力コード（例えば、多数キャラクタストリングを表すコード）中のビット数が単一キャラクタストリングの数により制御されることを示唆している。 例えば、多数キャラクタストリングについての最短ビット長は、単一キャラクタストリングの数によって決定される。 多数キャラクタを表す後続コード中のビット数は、辞書中の項目の数が２の次のべき乗に達する毎に１ビットだけ長さが増す。 より多くのビットを使用して単一キャラクタのコードワードを表すと、それに比例して圧縮性能全体が低下する。

【０００８】上述のような単一入力キャラクタの初期設定は、入力データが大きなアルファベットサイズを有する場合、または、入力データ中に未知のアルファベットのサブセットしか発生しないことが予期される場合には、不十分なものとなる。 例えば、入力データのための「未加工の」アルファベットが16ビットの記号から構成されている場合は、初期の辞書サイズは、65,536の項目を有することになる。 従って、「未加工の」アルファベットからのキャラクタに加えて生成されるあらゆる出力コード（例えば多数キャラクタストリングを表すコード）の最小長は、少なくとも17ビットとなる。 また、入力データのブロック（即ち、圧縮されるべきデータ）
が、アルファベットサイズに比較して小さい場合には、
入力データからの単一キャラクタストリングの初期設定、記憶および符号化のそれぞれに起因して、時間、記憶空間および圧縮率が不必要に増大することになる。

【０００９】このような問題を克服するために、ＬＺアルゴリズムの幾つかの変形例では、空の初期辞書を採用している。 新たな入力キャラクタに遭遇すると、圧縮装置が特殊コードを出力し、次いで新キャラクタのコピーを出力する。 これにより、実際に使用されている入力アルファベットのサブセットを圧縮解除装置が追跡することが可能となり、符号化を通常通りに進めることが可能になる。 この戦略の主な問題は、新キャラクタを符号化するコストが高いことである。 大きいアルファベットにわたりファイルが短い場合には、この追加コストは許容できない程高くなり得る。 例えば、８ビットの記号および12ビットの出力コードを使用する場合には、新キャラクタが発生したことをデコーダに知らせるために20ビットが必要となる。 更に、ＬＺアルゴリズムにより出力される符号化キャラクタストリングに冗長性が存在する場合が多い。 例えば、同一の入力キャラクタからなるストリング（即ち「ラン」）は、予測可能で冗長な構造を有する一連の符号化ストリングを生成する。 この冗長性は、現時点では、標準的な圧縮アルゴリズムの圧縮率を更に高める効力を発揮するものではない。

【００１０】従って、データ圧縮率を高め、辞書ベースの圧縮／圧縮解除装置に必要な記憶装置の量を削減するために、異なる形式の入力データおよび異なるデータ構造に適応可能な、データ圧縮の初期設定プロセスが依然として必要とされている。

【００１１】

【発明が解決しようとする課題】従って、本発明の目的は、辞書ベースの装置におけるディジタルデータの圧縮および圧縮解除を改良することにある。

【００１２】本発明の別の目的は、符号化キャラクタストリングの表現に使用されるビット数を削減することにより、圧縮／圧縮解除機構のデータ圧縮率を高めることにある。

【００１３】本発明の別の目的は、辞書ベースの圧縮／
圧縮解除装置における辞書の初期設定での付加コストを削減することにある。

【００１４】本発明の更に別の目的は、小さいファイル中で発生したディジタルデータ、または、大きい単一キャラクタのアルファベットのサブセットにより表されるディジタルデータを、一層効率よく圧縮することにある。

【００１５】本発明の更に別の目的は、入力データのキャラクタのランを表す符号化キャラクタストリングを再圧縮して、圧縮／圧縮解除装置の圧縮率を更に高めることにある。

【００１６】

【課題を解決するための手段】本発明は、入力データの形式および構造の変化に適応可能な辞書ベースの初期設定機構である。 この初期設定機構は、辞書ベースの圧縮／圧縮解除装置で使用されるデータ項目の数を最小限にして単一キャラクタデータストリングを表現することにより、圧縮率を高めるものである。 データ項目数を削減することにより、圧縮データストリング中のコードワードのビット長が短縮される。 圧縮データストリング中のコードワードのビット長が短縮されることにより、圧縮率全体が高まる。

【００１７】本発明は、可変数の特殊コードを使用する。 特殊コードの総数は、一般的には入力データアレイ中の単一キャラクタを表すのに使用されるキャラクタコードの総数未満になるよう選択される。 各特殊コードは、新キャラクタに関する情報の一部を保持している。
次いで、新キャラクタを更に識別する付加的なビットが、別個の部分キャラクタ中に伝送される。 このプロセスにより、新たな記号を伝送する「コスト」（即ち、帯域幅と記憶空間）が削減される。 このプロセスは、非初期設定プロセス（例えば、空の初期辞書）から、アルファベット中の各々の一意のキャラクタが辞書中の項目に割り当てられる完全アルファベット初期設定まで、どのような場合にも適応可能である。

【００１８】特殊コードの数は、現在実行中の用途に適応可能なものである。 従って、この特殊コードの数は、
圧縮率を最大限にするように特定形式のデータに応じて予め定められる。 この方法により、辞書がアルファベットサイズよりも少ない項目を有することが可能となる。
従って、極めて小さな記憶装置しか必要としない小さい辞書で圧縮が可能となる。 これは、入力データブロックが短く、各ブロックを個々に圧縮する必要がある用途で特に有用である。 この初期設定機構はまた、辞書サイズを中庸に留めつつ、大きなアルファベットサイズ（例えば、16ビットの記号）を有するデータソースの圧縮を行うことを可能にするものである。

【００１９】本発明の更に別の態様では、ＬＺ方式（Ｌ
ＺＥ）で一種のランレングス符号化が実施される。 従来のＬＺ２データ圧縮では、ラン（即ち、入力データ中に同じキャラクタが繰り返し発生したものからなるストリング）は、一連のコードとして符号化される。 各々の連続するコードは、先行するコード上に構成され、その後に、そのランの残り即ち末尾についてのコードが続く。
次いで、圧縮解除装置が、それらの各コードを順次受信して復号する。 この装置は、単一コード（キャラクタのランの大部分を表すもの）と、先行コードおよび末尾コードとを伝送することにより、短縮化シーケンスを送る。

【００２０】前述のＬＺＥ方法が、単独で使用され、または、他の方法と組み合わせて使用されて、ネットワークパケットの伝送に特に有用な圧縮機構が形成される。
組み合わせ装置では、ＬＺＥ圧縮機構は、１つ以上の他のデータ圧縮方法と並行して入力データストリームに適用される。 前記の「他のデータ圧縮方法」としては、ハフマン可変長符号化機構、または非圧縮伝送機構等が挙げられる。 次いで、最良の圧縮率をもたらす方法による出力が使用されて、データ伝送および記憶が行われる。
広範囲に分布する長さを有するパケットを含む実際のネットワークパケットデータについて高圧縮率が達成される。 この高圧縮率は、短いパケットの割合が大きなデータであっても、パケット長の全範囲に亘って一貫して維持される。

【００２１】本発明の上述その他の目的、特徴および利点は、添付図面に関連して進める本発明の好適実施例についての以下の詳細な説明により一層容易に明確となろう。

【００２２】

【実施例】Lempel-Ziv圧縮／圧縮解除装置の基本構成および動作は公知のものであり、このため、図１および図２を参照して一般的な用語で説明するに留める。 図１の装置22は、ディジタルデータ通信（または記憶）チャネル28によって相互接続された圧縮副装置24と圧縮解除副装置26とを備えている。 実際には、この装置の双方の端末機は、圧縮副装置および圧縮解除副装置を備えており、そのハードウェアは一般には、データの圧縮／送信、または、データの受信／圧縮解除を行うよう互換的に動作することができるように設計される。

【００２３】それぞれの副装置は、従来の通信（または記憶）回路（図示せず）に加えて、基本的なLempel-Ziv
圧縮アルゴリズムを実施する圧縮エンジン30と、キャラクタストリングデータを符号化するデータ項目が記憶されている１つ以上の辞書を実施する記憶装置32と、後述の強化を行う支援回路とを備えている。 その支援回路は、図７および図９で更に詳細に説明する中間初期設定エンコーダ34および相手側部品となるデコーダ36と、図１２および図１５に示すエンコーダラン強化エンジン38
および相手側部品となるデコーダラン強化エンジン40とを備えている。

【００２４】図２は、ディジタルデータの無損失圧縮（即ち、元のデータがその圧縮画像から完全に回復されるもの）のためのLempel-Ziv（ＬＺ）アルゴリズムを示すものである。 ＬＺ法は、入力データストリーム中のカレントパターンを以前に発生したパターンと突き合わせる。 例えば、入力ストリーム46中のカレントパターン42
（ＡＢＣ）は、以前に伝送されたパターン44（ＡＢＣ）
と同じである。 圧縮副装置24（図１参照）は、その突き合わせが行われた入力記号（ＡＢＣ）を最大に一致する記述（即ち、コードワード）で置き換える。 次いで、圧縮解除副装置26（図１参照）が、一致するコードワードから、および、以前に圧縮解除されたデータセグメントから、元の記号を再構成する。 冗長データソースでは、
多数のキャラクタの一致を記述する記述、即ちコードワードは、突き合わせが行われたパターンより短くなる傾向があり、これにより、データ圧縮が達成される。

【００２５】ＬＺ２の主な特徴は、インクリメンタル構文解析にある。 入力データシーケンスは、複数フレーズへと構文解析され、それらのフレーズが辞書に収集される。 カレント入力パターンの最大突き合わせは、上述のように辞書中のフレーズに対してのみ試行される。 各々の突き合わせの後、突き合わせを「中断させる」入力記号を有する突き合わせが行われたフレーズを拡張することにより、新フレーズが形成される。 上記アルゴリズムおよびそのアルゴリズムの変形例は、漸近的に最適な（即ち、理論上可能な最良の圧縮率を限界内で達成する）ものである。 このアルゴリズムはまた、高度の適応性を有するものであり、入力データの統計的特性を「オンザフライ」で学習することができる。 ＬＺ２では、その「知識」が辞書中に記憶され、その辞書の各項目により、入力データシーケンスの構文解析が行われる。

【００２６】ＬＺ２の圧縮装置の実施態様は概略的に以下のように説明することができる。

【００２７】１． 入力アルファベット中に存在する全ての単一文字ワード（例えば256の１バイトストリング）
で辞書が初期設定され、次いで、各々の単一キャラクタワードに別個の索引コードワードが割り当てられる。

【００２８】２． 入力データストリームからの最初のキャラクタでカレントフレーズが初期設定される。

【００２９】３． 入力データストリームからのキャラクタが継続的に読み出され、一致するフレーズが辞書中に存在する限り、カレントフレーズが拡張される。 ４． カレントフレーズがＷａという形式のもの（「ａ」
は入力データストリームから読み出された最後のキャラクタ、Ｗは辞書中のフレーズ）であり、同時に、そのＷ
ａがフレーズ辞書中の項目と一致しない場合に、プロセスが停止される。

【００３０】５． Ｗについてのコードワードが出力される。

【００３１】６． Ｗａが辞書に追加され、次に利用可能なコードワードが割り当てられる。

【００３２】７． カレントフレーズが「ａ」にセットされて、プロセスがステップ３に戻る。

【００３３】この実施態様はＬＺＷとして公知のものである。

【００３４】図１の圧縮解除副装置26では、同様のフレーズ辞書が構成される。 この圧縮解除装置は、上記のステップ１の場合と同様に最初に初期設定され、次いでデータの圧縮解除中に新フレーズが辞書に追加される。 この圧縮解除装置は、キャラクタ「ａ」で始まるフレーズのコードが後に続いているフレーズＷのコードを受信した場合に、フレーズＷａを辞書に追加し、そのフレーズに次に利用可能なコードを割り当てる。 このように、この圧縮解除装置は、圧縮装置により構成された辞書を再構成することができ、従って、圧縮装置が圧縮データと共に辞書を送る必要はない。

【００３５】実際の実施例では、エンコーダ用に（および同様にデコーダ用に）利用可能な記憶装置の量は限られたものである。 従って、辞書中のフレーズ数も限られたものとなり、出力コードも限られた長さのものとなる。 一般的には、コード長の上限は、12ビットおよび16
ビットの間となる。 入力データシーケンスが充分に長い場合には、辞書は最終的には「一杯」になる。 その時点で、ＬＺＷ辞書は、「凍結」されるか、または「再初期設定」される。

【００３６】上記で概略を示したＬＺＷ圧縮手順のステップ１は、全ての単一キャラクタストリングを用いた辞書の初期設定を必要とする。 ｍが入力データストリングからの単一キャラクタのサイズをビットで表すものと仮定する（例えば、最も一般的な場合には、ｍ＝８、即ち１バイト）。 辞書中の初期フレーズには、コードＣo,Ｃ
o＋１,Ｃo＋２,…,Ｃo＋（２ ^m −１）（Ｃoは負でない初期数）が割り当てられる。 これは、エンコーダにより送出された最初のコード（即ち、多数キャラクタストリングを表す最初のコード）が少なくともｍ＋１ビット長を有していなければならないことを示唆している。 実践的な実施態様では、圧縮プロセスの開始時に長さｍ＋１の出力コードを使用し、その後に辞書中の項目数が次の２
のべき乗に達する毎に出力コードの長さを１ビットだけ増大させるのが普通である。 このため、出力コードの長さはｍ＋１とｂとの間で変動する（ここで、２ ^bは辞書の最大サイズ、ｂ≧ｍ＋１）。 簡略化のため、辞書の最大サイズが２のべき乗であるものと仮定する。 これは不可欠な要件ではないが、最も実践的な実施態様を示すものである。 明らかに、出力コードの長さは圧縮率に直接影響を及ぼす。 即ち、出力コードが短いほど圧縮率は良好となる。

【００３７】上記ステップ１の初期設定は、多くの用途で良好に機能するものであるが、アルファベットサイズが大きい場合には不十分なものとなる。 また、この初期設定プロセスは、入力アルファベットの未知のサブセットが、圧縮すべきデータ中に発生するものと予期される場合にも、不十分なものとなる。 例えば、入力データの「未加工の」アルファベットが16ビット記号から構成される用途では、初期の辞書サイズは65,536項目を有し、
出力コードの最小長さは17ビットとなる。 また、圧縮すべきデータブロックがアルファベットサイズと比較して小さい用途では、潜在する単一キャラクタストリングの各々を符号化する必要がない場合が多い。

【００３８】これら問題点を解決するために、ＬＺアルゴリズムのいくつかの変形例では、空の初期辞書を採用している。 新しい入力キャラクタに遭遇すると、圧縮装置は、その新キャラクタのコピーが後に続く特殊コードを出力する。 この方法の場合、圧縮解除装置が、実際に使用される入力アルファベットのサブセットを追跡し、
復号が通常どおりに進行する。 このプロセスの主な問題は、新キャラクタの符号化のコストが高いことである。
大きいアルファベットにわたる短いファイルの場合、この付加的なコストは許容できないほど高くなる。 例えば、図３では、どの新キャラクタが発生したかを圧縮解除エンジン30（図１参照）に示すのにキャラクタコード
46と特殊コード48との双方が必要である。 キャラクタの長さが８ビットであり、カレントコードの長さが12ビットであるものと仮定した場合、各々の新キャラクタを識別するために全部で20ビットを伝送しなければならないことになる。

【００３９】中間辞書初期設定 上述のビット長および記憶装置に関する問題を解消するために、２ ^kの異なる特殊コードＣo,Ｃo＋１,Ｃo＋２,
…,Ｃo＋（２ ^k −１）が使用される（ここで、０≦ｋ≦
ｍ）。 これは、別の制御コードのために数０,１,…,Ｃo
−１が使用されることを仮定したものである。 このようにして、特殊コードは、新キャラクタについてｋビットの情報を備え、新キャラクタを識別するためには正確にｍ−ｋの付加的なビットが必要である。 これを図４にｋ
＝５で示す。 特殊コード48についてのカレントコード長は12ビットであり、部分キャラクタコード49の長さは３
ビットである（即ち、ｍ−ｋ＝８−５＝３）。 従って、
新たな１つの単一キャラクタストリングを伝送するコストは、20ビットから15ビットに削減される。 ｋ＝０の場合、この方法は空の初期設定へと移行し、また、ｋ＝ｍ
の場合には、装置は完全アルファベット初期設定として動作する（即ち、アルファベット中の各キャラクタがコードワードにより表される）。

【００４０】ここで図５を参照する。 本発明による動作は、空の初期辞書で始まり、基本的に下記のように修正されたＬＺアルゴリズムに従って進行する。 この動作は、次に使用可能なコード（ＮＡＣ）を値Ｃo＋２ ^kに設定することにより、ブロック50で開始される。 次ステップのブロック52では、ヌルストリングがカレントフレーズＷとしてセットされる。 次いでブロック54で、次の入力キャラクタが「ａ」として入力される。 ブロック56のステップは、ストリングＷａが既に辞書中に記憶されているか否かを照会する。 ストリングＷａが既に辞書中に記憶されている場合には、ブロック58がＷをＷａに等しく設定してブロック54に戻る。 このプロセスは、辞書中で一致が発見される限り繰り返される。 これは、Lempel
-Ziv方式では一般的なことである。

【００４１】また、Ｗａが辞書中で発見されない場合には、ブロック60が、Ｗがヌルストリングであるか否かを照会する。 Ｗがヌルストリングでない場合には、圧縮が従来のＬＺＷのようにブロック62,66,68を経て進行する。 ブロック62は、Ｗについてのコードを出力し、ブロック66は、符号化ストリングＷａをデータ項目としてアドレス位置ＮＡＣで辞書中に記憶させる。 ブロック68
は、ＮＡＣを１だけインクリメントし、「ａ」が次のＷ
の値として働く。 次いで、プロセスはブロック54に戻る。

【００４２】判定ブロック60が、Ｗがヌルストリングであると判定した場合には、入力キャラクタ「ａ」が新キャラクタであるとみなされる。 次いで、圧縮装置は、プロセス「新キャラクタ」というブロック64に進む。 これはサブプロセスであり、図６を参照して後で詳述することとする。 このプロセス「新キャラクタ」から戻ると、
ブロック65で入力キャラクタ「ａ」がアドレス位置ＮＡ
Ｃで辞書中に入力される。 次いでブロック67でＮＡＣがインクリメントされて、プロセスがブロック52に戻る。

【００４３】ここで図６を参照する。 サブプロセス64
（図５参照）において、ブロック70で示す第１ステップは、ｍビットから成るキャラクタａを２つの部分、即ち、ｋビットから成るａ ₁と、ｍ−ｋビットから成るａ ₂
とに分割するステップである。 次いでブロック72がＣ ₁
を値Ｃo＋ａ ₁に設定する。 次いでブロック74がｂビットを用いてＣ ₁を出力し、ブロック76がｍ−ｋビットを用いてａ ₂を出力する。 ここで、ｂは、出力コードワードに現在使用しているビット数である。 次いでこのサブプロセスは、図５のブロック65に戻る。

【００４４】図７は、図６のサブプロセスをハードウェアで実施するための回路34（図１参照）を示すものである。 キャラクタａがｍビットレジスタ80へと入力され、
このレジスタ中に前記キャラクタが２つの部分、即ち、
ｋビットから成るａ ₁およびｍ−ｋビットから成るａ ₂で記憶される。 値Ｃoは、ｂビットレジスタ82中に記憶され、ａ ₁と共に加算器84に出力されて、ｂビット合計Ｃ ₁
＝Ｃ ₀ ＋ａ ₁が形成される。 この合計が、レジスタ86の最初のｂビット中に配されて、そのレジスタ86の下位ｍ−
ｋビット中のａ ₂と連結される。 その結果として生じたｂ＋ｍ−ｋビットのシーケンスが出力バッファ88へとシフトされて、圧縮されたストリーム中に挿入される（圧縮解除装置へ伝送される）。

【００４５】図８は、圧縮解除プロセス90を示すものである。 このプロセスは、ブロック91で開始して、ｂビットの特殊コードＣ ₁を読み出し、次いでブロック92でコードＣ ₁がＣo未満であるか否かを照会する。 コードＣ ₁
がＣo未満である場合には、ブロック93がコードＣ ₁をプロセス制御コードとして処理し、ブロック91に戻る。 また、コードＣ ₁がＣo未満でない場合には、このプロセスは先に進み、ブロック94でコードＣ ₁がＣo＋２ ^k未満であるか否かを照会する。 コードＣ ₁がＣo＋２ ^k未満でない場合には、ルーチンはブロック96に移行して、コードＣ ₁を通常のＬＺコードとして処理し、次いでブッロク9
1に戻る。 また、コードＣ ₁がＣo＋２ ^k未満である場合には、コードＣ ₁は新キャラクタについてのコードであると見なされて、ルーチンがブロック98に戻り、特殊コードＣ ₁とその関連する部分キャラクタコードａ ₂とが新キャラクタとして処理される（一対のＣ ₁ ,ａ ₂は、図７
の回路中の圧縮装置により出力されたものである）。

【００４６】図９は、図８のサブプロセス98をハードウェアで実施した回路36（図１参照）を示すものである。
特殊コードＣ ₁および部分キャラクタコードａ ₂が入力バッファ（図示せず）からレジスタ102,104へとそれぞれ受信される。 レジスタ100中の固定値Ｃoの中容が、減算器106中で、レジスタ102の中容から減算される。 そのｂ
ビットの結果がレジスタ108中に収容され、レジスタ108
の最上位ｂ−ｋビットが廃棄される。 レジスタ108中の最下位ｋビットが、レジスタ110のａ ₁フィールド中に記憶されて、レジスタ104からの部分キャラクタコードａ ₂
と連結される。 レジスタ110の中容は、ブロック112で単一キャラクタストリングとして辞書中に入力され、また出力バッファ114中にロードされる。

【００４７】特殊コードの数（または等価的にはパラメータｋ）は、手近な用途に合わせて調整可能なものである。 実験結果によれば、広範囲の入力ファイルに対し、
ｍ／２に近いｋの値で最良の圧縮が達成されることが示されている。 特に、ｍ＝８の場合はｋ＝５、ｍ＝16の場合はｋ＝７という値が最適であることが実験的に判明した。 多数キャラクタストリングについての初期コード長は、典型的なｍ＋１ビットではなく、ｋ＋１ビットだけである点に留意されたい。 従って、この方法により、アルファベットサイズよりも小さい辞書が可能となり、また入力キャラクタよりも短いコードワードが可能となる。

【００４８】このため、極めて小さい辞書を用いて圧縮を行うことが可能となり、この場合には、極めて少ない記憶装置しか必要なくなる。 この方法は、入力データブロックが短く、各ブロックが別個に圧縮される必要がある用途では、特に魅力的なものとなる。 別の側面によれば、この方法により、辞書のサイズを中庸に保ちつつ、
大きなアルファベットサイズ（例えば、16ビット記号）
を有するデータソースの圧縮が可能となる。

【００４９】ここで、ｍ＝８、ｋ＝５、Ｃo＝３であり、伝送すべき新キャラクタが２進表現01101010を有するものと仮定する。 このキャラクタの最初のｋビットは
01101であり、数13を表している。 このため、伝送される特殊コードはＣo＋13＝16である。 このコードは、カレントコード長を用いて伝送される。 更に、特殊コードが部分キャラクタコードａ ₂として伝送された後、ｍ−
ｋ＝３の残りのビット010が「そのまま」伝送される。
カレントコード長が12ビットであると仮定すると、結果として生じる２進出力は、特殊コードについては[00000
0010000]となり、キャラクタコードについては[010]となる。

【００５０】図１０は、種々のキャラクタコードおよび特殊コードのビット長での圧縮結果を示すものである。
全ての圧縮実験のための入力ファイルは、ASCIIデータファイル、２進法で実行できるＣプログラムソース、およびテキストファイルを含むコンピュータファイルを収集したものを（ＵＮＩＸのコマンドtarを用いて）連結することにより得たものである。 入力ファイルの全サイズは6,594,560バイトであった。 番号を付した列１〜５
に示すように５つの圧縮方法を試験した。 列１は、ｍ＝
８で完全アルファベット辞書初期設定法を用いた場合であり、従来のＬＺＷ実施例の結果である。 列２は、ｍ＝
８、ｋ＝０で空辞書初期設定法を用いた場合の結果である。 列３は、ｍ＝８、ｋ＝５で中間辞書初期設定法を用いた場合の結果である。 列４は、ｍ＝16、ｋ＝０で空辞書初期設定法を用いた場合の結果である。 列５は、ｍ＝
16、ｋ＝７で中間辞書初期設定法を用いた場合の結果である。

【００５１】各機構について、最も左の列に示すように最大出力コード長を６〜16ビットに変動させて幾つかの辞書サイズを試行した。 各機構での圧縮率（ＣＲ）は、
次の関係式を用いて算定される。

【００５２】ＣＲ＝（圧縮ファイルサイズ）／（元のファイルサイズ） 従って、ＣＲの値が小さいほど圧縮率が良好であることが示される。 図１０から分かるように、中間初期設定辞書を用いた機構は、辞書が極めて小さく（例えばｂ＜
ｍ）、完全初期設定が不可能な場合であっても、大幅な圧縮がなされる。 これは、記憶装置が不十分となる用途で極めて有用である。 中間初期設定はまた、ｂがｍよりも僅かに大きい場合に完全初期設定よりも性能が優れており、ｂの値が一層大きい場合には、それら２つの機構は互いに競合するものとなる。 ｋ＞０での中間初期設定は、ほとんど常に空初期設定よりも性能が優れたものとなる。

【００５３】16ビット入力記号を用いて、中庸サイズの辞書で良好な圧縮率を達成することが可能である。 16ビット機構の主な利点は、（各圧縮ステップで８ビットではなく16ビットを処理することにより）記憶装置の量をわずかに増やすだけで圧縮装置のスループットを２倍にすることができる点にある。 一般に、ＬＺＷ辞書中の項目は、以前の項目へのポインタ（またはそれに対応するコード）とキャラクタとから成っている。 従って、16ビット機構は、一般に、それと同数の辞書項目を有する８
ビット機構に比較して、１辞書項目につき更に別の１バイトを必要とすることになる。 更に、16ビットが未加工のキャラクタのサイズである場合（例えば或る種の医療用画像形成用途等）、そのキャラクタサイズが維持される際に最良の圧縮が達成される。

【００５４】上述の初期設定機構は、短いデータブロックが個々に（即ち、或るブロックとその次のブロックとで辞書情報を共用することなく）圧縮される用途で有利である。 このような用途の一例として、ローカルエリアネットワーク（ＬＡＮ）におけるデータパケットの圧縮が挙げられる。 典型的なＬＡＮで現在使用されているネットワークプロトコルでは、パケット長は60バイトから
2028バイト未満の範囲を有し、より短いパケットがトラフィック中で高い割合を示している。 上記値は近似的な数値である。 パケットの正確な長さは、パケットの「エンベロープ」をどの程度まで考慮に入れるかによって決まる。 それはまた、パケットが処理されるプロトコル層によって決まる。

【００５５】 ラン符号化の強化無損失データ圧縮の最も簡単な方法の１つに、ランレングス符号化（ＲＬＥ）がある。 ランは、入力中に同じキャラクタが繰り返し発生するストリング（例えば、ａ ₀ ,
ａ ₁ ,ａ ₃ ,…,a _n-1 ）である。 ここで、ｎはストリング中の同じキャラクタ「ａ」の反復発生回数である。 ストリングａ ₀ ,ａ ₁ ,ａ ₃ ..a _n-1は、同じキャラクタ「ａ」のｎ
個のコピーを表すものである。 ＲＬＥでは、そのようなランは、ランレングスｎが後に続くキャラクタを送ることにより符号化される。 ｎの値が大きい場合には、ランの圧縮率は０（log(n)/n）となる。 ＬＺ２機構もまた、
長いランを圧縮する優れた動作を行う。 ｎの値が大きいものと仮定すると、上記のランは、ＬＺ２機構では、一連のコードＡ ₀ ,Ａ ₁ ,Ａ ₁ ＋１,Ａ ₁ ＋２,Ａ ₁ ＋３,…,Ａ ₁ ＋
（ｋ−１）,Ａ ₂として符号化される。 ここで、Ａ ₀は、
辞書中のａの最長のストリングについてのコードである。 Ａ ₁は、カレントランが読み出される前に次に利用可能なコードである。 Ａ ₂は、後述するコードであり、
ｋは、負でない整数である。

【００５６】Ａ ₀で表されるａのストリングの長さがＬ ₀
である場合、Ａ ₁ ＋（ｉ−１）は、Ｌ ₀ ＋ｉのａからなるストリングを表している（１≦ｉ≦ｋ）。 Ａ ₂は、Ｌ ₁のａからなる残りの「尾部」を表しており（０≦Ｌ ₁ ≦
（Ｌ ₀ ＋ｋ））、その後に何らかの別のキャラクタが続く可能性がある（Ｌ ₁ ＝０の場合、符号化されたランの一部としてコードＡ ₂は必要ない）。 ランの長さは、ｎ
＝Ｌ ₀ ＋（Ｌ ₀ ＋１）＋（Ｌ ₀ ＋２）＋……＋（Ｌ ₀ ＋ｋ）
＋Ｌ ₁ ＝Ｌ ₀ (ｋ＋１）＋ｋ（ｋ＋１）／２＋Ｌ ₁となる。
従って、ｎの値が大きく、辞書が充分に大きい場合には、基本的なＬＺ２機構は、Ｏ（√（ｎ）Ｌｏｇ（ｎ）
／ｎ）という圧縮率を達成する。 従って、双方の機構とも漸近的にゼロ圧縮率を達成するものの、入力が制限されているため、長いランの圧縮にはＲＬＥの方が一層適している。

【００５７】長いランを符号化する場合のＬＺ２の効率は、以下の観察に基づいて改善することができる。 ＬＺ
２圧縮解除装置がシーケンスＡ ₁ ,Ａ ₁ ＋１,Ａ ₁ ＋２,Ａ ₁
＋３,……,Ａ ₁ ＋（ｋ−１）における各コードを読み出す場合、その読み出されたコードは、その特定の時点で、可能な最長のコードとなる（即ち、読み出されたコードは作成されたばかりのコードである）。 従って、エンコーダは、ｎ個の「ａ」のランについてシーケンスＡ
₀ ,Ａ ₁ ＋（ｋ−１）,Ａ ₂さえ送ればよい。 デコーダがコードＡ ₁ ＋（ｋ−１）を受信すると、そのデコーダは、
その値が現在の可能な最大コードＡ ₁を超えていることを検知し、１つのランが符号化されていることを「学習」し、および、値ｋおよび「ミッシングシーケンス」
Ａ ₁ ,Ａ ₁ ＋１,Ａ ₁ ＋２,…,Ａ ₁ ＋（ｋ−２）を容易に再構成することができる。 この場合、伝送されたビット数はＯ（log(k)）＝Ｏ（log(n)）であり、強化ＬＺ２の圧縮率は、ＲＬＥ機構の場合と同様に、Ｏ（log(n)/n）となる。

【００５８】図１１はランを強化させていない従来のＬ
Ｚエンコーダを示すブロック図である。 入力エンジン11
6は、入力データストリーム（図示せず）からキャラクタを読み出し、その入力キャラクタを圧縮エンジン118
（図１のブロック30を参照）に送る。 圧縮エンジン118
は、入力キャラクタを得て辞書を構成して保持する。 例えば、辞書は、一意の入力キャラクタストリングを表すデータ項目を備える。 圧縮エンジン118は、入力データストリームを圧縮し、その圧縮入力データをコードワードとして出力エンジン120に出力する。 次いで出力エンジン120は、後に行う圧縮解除のために圧縮データストリングを記憶するか、または、圧縮データストリングを帯域幅を縮小して通信チャネル28（図１参照）を介して伝送する。 圧縮データは、図１５で更に説明するように、通信チャネル28の反対側の端末でその圧縮解除が行われる。 圧縮エンジン118は、典型的には、次に利用可能なコード（ＮＡＣ）を識別するアドレスポインタ122
を保持する。 次の一意のキャラクタストリングがデータ項目として圧縮／圧縮解除辞書中に記憶される。 例えば、ＮＡＣは、次の一意の入力キャラクタストリングについてのコードワードとして使用される次のアドレス位置を表すものである。

【００５９】図１２は、図１に示す本発明によるエンコーダラン強化エンジンを詳細に示すブロックである。 入力エンジン124は、入力データストリームからキャラクタを読み出す。 圧縮エンジン126は、その入力キャラクタを読み出し、辞書を維持し、および、図１１を参照して前述したようにキャラクタコードを生成する。 符号化された入力データは、次いでエンコーダラン強化エンジン128に送られ、これにより第２レベルのデータ圧縮が提供される。 ラン強化エンジン128からの圧縮コードは、出力エンジン130に送られ、図１１の出力エンジン1
20と同様にして処理される。

【００６０】ラン強化エンジン128は、別個のアドレスポインタ134（ＲＵＮＣＯＤＥ）を収容しており、そのポインタ134が、圧縮エンジン126により使用されるＮＡ
Ｃアドレスポインタ132と連携して使用される。 キャラクタストリングが圧縮エンジン126により符号化された後、ラン強化エンジン128は、出力コードを遮断し、それがキャラクタのランの一部であるか否かを判定する。
その出力コードがランの一部であると判定された場合には、ラン強化エンジン128は、そのランからのキャラクタを含む幾つかのコードを出力エンジン130が出力するのを禁止する。 次いでラン強化エンジン128は、そのランから送信されなかったコードを識別する情報を含むランコードワードを生成する。 次いで、そのランコードワードが、そのランの終わりの検出時に出力される。

【００６１】図１３は、図１２に示すラン強化エンジン
128により実行されるプロセスを示す詳細なフローチャートである。 ブロック136でコード「Ｃ」が照会されて、そのコード値が辞書中で作成された最後のコード（即ち、ＮＡＣ−１）と等しいか否かが判定される。 コードＣがＮＡＣ−１と等しい場合には、ランは既に発生しており、判定ブロック136はブロック138へジャンプして、コード値「Ｃ」がアドレスポインタＲＵＮＣＯＤＥ
に書き込まれる。 ラン強化エンジンは次いで、出力エンジン130（図１２参照）をディセーブルにして、コードＣが出力されるのを防止する。 次いでプロセスは、圧縮エンジンにより生成される次のコードのために判定ブロック136にジャンプする。 後続のコードがラン中にあるキャラクタを表す（即ち、同じキャラクタを表す）限り、このプロセスは繰り返される。 例えば、ＲＵＮＣＯ
ＤＥは、最後のコードＣの値に絶えずリセットされ、出力エンジンは、コードワードを出力することが抑止される。 ブロック136に戻った際には、ＮＡＣの値が圧縮エンジンによりインクリメントされることに留意されたい。

【００６２】新たに遮断したコードがＮＡＣ−１と等しくない（即ち、圧縮／圧縮解除エンジンで作成された最後のコードと等しくない）場合には、ランが発生しなかったか、またはランが完了しているかの何れかである。
次いで判定ブロック136は、判定ブロック142にジャンプして、アドレスポインタＲＵＮＣＯＤＥの値がチェックされる。 ＲＵＮＣＯＤＥがヌル値である場合には、以前にランは生じておらず、判定ブロック142はブロック148
にジャンプする。 次いで、ブロック148は、コードＣを出力する。 このコードＣは、他のランでない符号化キャラクタストリングと同一のものである。 次いでプロセスは、圧縮エンジンによって作成される次のコードのために判定ブロック136に戻る。 また、ＲＵＮＣＯＤＥがヌルでない場合には、以前にランが生じており、判定ブロック142は、ブロック144で出力される次のコードとしてＲＵＮＣＯＤＥを出力する。 プロセスがブロック146にジャンプして、ＲＵＮＣＯＤＥがヌル値にリセットされ、次いでブロック148がランを中断させたコードＣ
（コードワード）の値を出力する。 次いで、ラン強化エンジンが判定ブロック136に戻り、次のコードワードが圧縮エンジンから遮断される。

【００６３】図１４は、従来の圧縮解除装置を示すブロック図である。 デコーダ入力エンジン150は、コードワードにより表された圧縮キャラクタストリングのシーケンスを受信し、そのコードワードを圧縮解除エンジン15
2に供給する。 その圧縮解除エンジン152は、コードワードを得て辞書を構成して保持し、符号化された出力キャラクタを生成する。 次に利用可能なアドレス（ＮＡＣ）
ポインタ156は、図５で説明したＮＡＣポインタと同様の態様で保持される。 デコーダ出力エンジン154は、圧縮解除エンジン152からの圧縮解除キャラクタの出力を制御する。

【００６４】図１５は、本発明によるランレングス強化デコーダを示すブロック図である。 デコーダ入力エンジン158は、図１５のデコーダ入力エンジン150と同じものである。 入力エンジン158からのコードワードは、圧縮解除エンジン162で更に圧縮解除が行われる前に、デコーダラン強化エンジン160で遮断される。 このラン強化エンジン160は、各コードワードをチェックして、そのコードワードがランコードワードを構成するものか否かを判定し、それに従って、修正されたコードストリームを生成する。 ランコードが存在しない場合には、コードワードが圧縮解除エンジン162に送られて、通常の圧縮解除が行われる。 デコーダ出力エンジン164は次いで、
圧縮解除エンジンからの符号化キャラクタの出力を制御する。 デコーダラン強化エンジン160は、図１２に示したものと同様にして圧縮解除エンジン162中のアドレスポインタ（ＮＡＣ）へのアクセスを有するアドレスポインタ（ＲＵＮＣＯＤＥ）168を含んでいる。

【００６５】図１６は、図１５のデコーダランレングス強化エンジン160の動作を示す詳細なフローチャートである。 ブロック170でコード「Ｃ」が照会されて、そのコード値が、次に利用可能なコードアドレスとして圧縮解除装置が予期している正規の値と異なるか否かが判定される。 例えば、圧縮解除エンジンは、典型的には、コードＣが、次に利用可能なコードＮＡＣより小さいものと予測する。 コードＣが正規の値である場合（即ち、コードＣ＜ＮＡＣ）には、ブロック172が「Ｃ」の値を処理のために圧縮解除エンジンに送る。 Ｃが正規の値と異なる場合（即ち、Ｃ≧ＮＡＣ）には、デコーダラン強化エンジンは、予測される最大コード値とコードＣの値との間の「ギャップを充填する」。

【００６６】より詳細に説明すると、ブロック174は、
値ＮＡＣをアドレスポインタＲＵＮＣＯＤＥに書き込み、ブロック176は、圧縮解除される次のコードワードとしてＲＵＮＣＯＤＥを圧縮解除エンジンに送る。 ＲＵ
ＮＣＯＤＥの値はブロック178でインクリメントされ、
判定ブロック180が、デコーダラン強化エンジンが出力コードと予測される次の利用可能なアドレスとの間の「ギャップを充填している」（即ち、ＲＵＮＣＯＤＥ＞
Ｃ）か否かを判定する。 デコーダラン強化エンジンがランの復号を完了している場合には、判定ブロック180
は、ランの圧縮解除が完了していることを示す。 ランコードワードとＮＡＣとの「ギャップを充填する」ために別のコードワードが必要である場合（即ち、ＲＵＮＣＯ
ＤＥ≦Ｃ）には、判定ブロック180がブロック176に戻って、アドレスポインタＲＵＮＣＯＤＥの値を圧縮解除エンジンに送る。 次いでＲＵＮＣＯＤＥがインクリメントされ、ランの中の全てのコードが圧縮解除エンジンに供給されるまで、このプロセスが繰り返される。

【００６７】図１７および図１８は、中間初期設定プロセスとランレングス強化プロセスとが共に作用する態様を示すものである。 生データストリーム182が、データ圧縮エンジン30（図１参照）へ送られて、図５に示した中間初期設定方法を用いて圧縮される。 入力データストリーム182中の各キャラクタ「ａ」には、データストリーム中の位置を識別し易いように添字を付してある。 従って、ａ ₀ ,ａ ₁ ,……,ａ ₁₁は同一のキャラクタ「ａ」の1
2回のコピーしたものを表している。 １組の初期動作条件190は、８ビットの単一キャラクタ長（ｍ＝８）と、3
2の特殊コード（ｋ＝５）と、12ビット固定長の出力コード（ｂ＝12）と、初期開始アドレス１（Ｃ ₀ ＝１）とから構成されている。 ２進表記での「ａ」のＡＳＣＩＩ
表現は[01100001]である。 次に利用可能なコード（ＮＡ
Ｃ）は、先ずＮＡＣ＝Ｃ ₀ ＋２ ^k ＝１＋32＝33と計算される。 記憶装置184は、圧縮／圧縮解除辞書中の特定のアドレス位置におけるデータストリーム182からのデータ項目を示している。

【００６８】中間初期設定圧縮プロセスは、最初の入力キャラクタａ ₀を読み出し、それと一致するキャラクタを記憶装置184中で探索する。 そのａ ₀がデータストリーム中の最初のキャラクタであると仮定した場合には、一致は発生しない。 次いでキャラクタａ ₀がアドレス位置ＮＡＣ（ADDR33）で「新キャラクタ」として記憶される。 ａ ₀の最初の５ビット（即ち、２進数[01100]＝12）
がＣ ₀と合計されて、圧縮データストリーム186中の最初のコードワード「13」として出力される。 次いでａ ₀の最後の３ビットについての部分コード（即ち、２進数[0
01]＝１）が次のコードワード１として出力される。 データストリーム186は、中間初期設定法を用いた圧縮プロセスの後のコードワードを示すものであり、データストリーム188は、図１３に示すラン強化プロセスの後のデータストリーム186を示すものである。

【００６９】ラン強化プロセスは、特殊キャラクタコード「13」および部分キャラクタコード「１」がＮＡＣ−
１と等しくなく、それ故、それらコードを圧縮データストリーム188に送ることを判定する。 次いでアドレスポインタＮＡＣがインクリメントされる（ＮＡＣ＝34）。
次の入力キャラクタａ ₁が読み出され、それと一致するデータ項目が記憶装置184中で探索される。 アドレス位置ADDR33に既にａ ₀が記憶されているので、突き合わせが行われると、次の入力キャラクタａ ₂がａ ₁と連結される。 ストリング「ａａ」（即ち、ａ ₁ ,ａ ₂ ）を求めて別の探索が行われる。 この探索は失敗する（即ち、一致は発生しない）。 Ｗはもはや「ヌル」ではない（即ち、Ｗ
＝コード(ａ ₁ )）ので、コードワード「33」が圧縮エンジン126によって出力される（図１２参照）。 ラン強化エンジン128（図１２参照）がコードワード「33」を遮断して、そのコードワードがＮＡＣ−１と等しい（即ち、ＮＡＣ−１＝34−１＝33）か否かを判定する。 コードワード「33」はＮＡＣ−１に等しく、従って、アドレスポインタＲＵＮＣＯＤＥが「33」に設定され、出力エンジン130（図１２参照）がディセーブルになって、コードワード33の出力が抑止される。 次いでストリング「ａ ₁ ,ａ ₂ 」がアドレス位置ＮＡＣ（ADDR34）に記憶され、アドレスポインタＮＡＣがインクリメントされる（ＮＡＣ＝35）。

【００７０】記憶装置184中の既に記憶されたデータ項目と一致しない次のキャラクタストリングは、ストリング[ａ ₃ ,ａ ₄ ,ａ ₅ ]である。 次いで辞書項目「ａａ」（即ち、ADDR34）が、典型的には圧縮エンジンにより出力される。 ラン強化エンジンは、出力コードがＮＡＣ−１
（即ち35−１）に等しいか否かを判定する。 従って、アドレスポインタＲＵＮＣＯＤＥの値が現在の出力コード値（即ちＲＵＮＣＯＤＥ＝34）と置き換えられる。 次いでラン強化エンジンが出力エンジンをディセーブルにして、コードワード「34」が圧縮エンジンから出力されるのが抑止される。 次いで圧縮エンジンがアドレス位置Ｎ
ＡＣ（ADDR35）にキャラクタストリング[ａ ₃ ,ａ ₄ ,ａ ₅ ]
を記憶し、ＮＡＣをインクリメントする（ＮＡＣ=3
6）。

【００７１】記憶装置184中のデータ項目と一致しない生データストリーム182からの次のキャラクタストリングは、キャラクタストリング[ａ ₆ ,ａ ₇ ,ａ ₈ ,ａ ₉ ]である。 次いで出力コードワード「35」が圧縮エンジンにより出力される。 出力コードワード「35」がＮＡＣ−１
（36−１）に等しいので、アドレスポインタＲＵＮＣＯ
ＤＥの値が値35に設定され、この出力コードワード「3
5」が圧縮データストリーム188中に出力されることが禁止される。 次いでキャラクタストリング[ａ ₆ ,ａ ₇ ,ａ ₈ ,
ａ ₉ ]がアドレス位置ＮＡＣ（ADDR36）に記憶され、アドレスポインタＮＡＣがインクリメントされる（ＮＡＣ=3
7）。 次いで圧縮エンジンが、シーケンス[ａ _{1 0} ,ａ ₁₁ ,
ｂ]が記憶装置184中のどの項目とも一致しなくなるまで、生データストリーム182からの更なるキャラクタを組み合わせる。 次いで、最後の一致データ項目ストリング（即ち、ADDR34における[ａ ₁ ,ａ ₂ ]）についてのコードワード「34」が圧縮エンジンにより出力される。 ラン強化エンジンは、コードワード「34」がＮＡＣ−１（3
6）（即ちランの終わり）に等しくないことを判定する。 ＲＵＮＣＯＤＥの値が「36」である（即ち、ヌルではない）ので、ＲＵＮＣＯＤＥ値およびコードワード「34」（即ち36,34）が、圧縮データストリーム188に出力される。 次いでＲＵＮＣＯＤＥが「ヌル」値にリセットされる。 ＮＡＣがインクリメントされる前に、キャラクタストリング[ａ ₁₀ ,ａ ₁₁ ,ｂ]が記憶位置ＮＡＣ（ADDR
37）中にコピーされる。 このプロセスは、生データストリーム182からの全てのキャラクタが圧縮されるまで続行される。

【００７２】データストリーム188は、図８に示すように、符号化キャラクタ「13」を先ず復号することにより圧縮解除される。 コードワード「13」は、Ｃo（即ち「１」）より大きく、Ｃo＋２ ^k （即ち「33」）より小さいので、このコードワードは、図９に示すように、新キャラクタとして処理される。 例えば、データストリーム
188からの次の３ビット（即ち、コードワード「１」）
は、特殊キャラクタコード「13」の復号化５ビット２進表現（即ち、13−Ｃo＝12＝[01100]）と連結される。 これにより、「ａ」のＡＳＣＩＩ表現（即ち[01100001]）
が生成される。 最初に、復号化キャラクタは、圧縮解除データストリーム190中でａ _oとして表される。 次いで、
復号化キャラクタ「ａ」が、圧縮解除辞書（図示せず）
のアドレス位置ADDR33にロードされる。

【００７３】圧縮データストリーム188からの次の符号化キャラクタ「36」は、Ｃo＋２ ^kよりも大きいものと判定され、その符号化キャラクタは、多数キャラクタ符号化キャラクタストリングと呼ばれている。 その符号化キャラクタは、デコーダラン強化エンジン160（図１６
参照）により遮断される。 コードワード「36」がＮＡＣ
(33)の現在値と比較される。 コード値「36」はコード値「33」よりも大きいので、ＮＡＣの値がアドレスポインタＲＵＮＣＯＤＥに書き込まれ、そのＲＵＮＣＯＤＥ
が、圧縮解除エンジンにより圧縮解除される次の符号化キャラクタとして使用される。 圧縮解除エンジンは、アドレス位置ADDR34に圧縮解除辞書を構成し、ＬＺ２圧縮解除機構にとって典型的な態様で、圧縮解除データストリーム190上のランからキャラクタを出力する。

【００７４】次いで、図１６のデコーダラン強化プロセスがＲＵＮＣＯＤＥをインクリメント(34)して、ＲＵＮ
ＣＯＤＥの値が符号化キャラクタ値「36」以下であるか否かをチェックする。 ＲＵＮＣＯＤＥの値は「36」未満なので、ＲＵＮＣＯＤＥの新たな値が次の符号化キャラクタとして圧縮解除エンジンに送られる。 このプロセスは、ＲＵＮＣＯＤＥがコードワード値「36」と等しくなるまで繰り返される。 次いで、次のコードワード「34」
が圧縮データストリーム188から読み出され、デコーダラン強化エンジンにより同様の態様で処理される。 このようにして、圧縮データストリーム中のコードワード（即ちコードワード33,34,35）のギャップがラン強化エンジンにより充填される。

【００７５】生データストリーム182は、図５に示すＬ
Ｚ２中間初期設定圧縮プロセスにより第１レベルまで圧縮され、そのデータは更に、図１３に示すラン強化プロセスにより第２レベルまで圧縮される。 データストリーム188から明らかなように、ラン強化エンジンから伝送されるコードワードの数は、データストリーム186により通常伝送されるコードワードの数よりも小さい。 従って、中間的初期設定プロセスにより提供される符号化キャラクタの短縮されたビット長によって圧縮率が最初に増大され、更にラン強化プロセスによって増大される。

【００７６】ラン符号化強化プロセスは、入力データ中の他の種類の冗長性について圧縮上の不利を伴うものではないことに留意されたい。 強化は、ＬＺ２機構により生成されるコードストリームに残るいくつかの残留冗長性を利用する。 即ち、任意の所与の時点で、ストリーム中で発生し得る「最大有効コード」が存在し、その最大コードよりも大きな値は「イリーガル」なものである。
ラン符号化の強化は、それらの「イリーガル」なコードを使用してランの符号化を行う。 可変長コードと共にラン符号化強化を実施する場合、シーケンスＡ ₁ ,Ａ ₁ ＋１,
Ａ ₁ ＋２,Ａ ₁ ＋３,……,Ａ ₁ ＋（ｋ−１）は、コード長の限界値にまで亘ることはできない。 例えば、Ａ ₁ ＋（ｋ
−１）の伝送に必要なビット数は、Ａ ₁の伝送に必要なビット数と同じでなければならない。 何故ならば、圧縮解除装置が予期するビット長がそのビット数であるからである。 これは（必要であれば）ランをサブランに分割することにより行われる。 このラン符号化強化は、幾つかの変形例が可能なものである。 そのような変形例には、「新コード」Ａ ₁ ＋１,Ａ ₁ ＋２,……,Ａ ₁ ＋（ｋ−
１）を辞書に入力しないものがある。 従って、ランの符号化方法を維持したまま、辞書のスペースが節減される。 どの変形例の性能が優れているかは、入力データ中のランレングスの分布によって決まる。

【００７７】 ハフマン符号化ネットワークプロトトコル（例えばＴＣＰ／ＩＰ）は、
転送中の実際のデータパケットを、ネットワークのトラフィック管理に必要な付加情報のエンベロープで包む。
実験結果の観察により、この付加情報は、ネットワークトラフィック中でヌルバイトが発生する相対的な頻度を大幅に高める傾向を有するものであることが示された。
この現象は、パケットのエンベロープ中の種々のフィールドの「ゼロ・パディング」に一部起因するものである。 非ゼロの値が発生する頻度はデータによって決まり、また長期間に亘って均一な分布から著しく離脱することはない。 このため、バイト値についての確率分布の大まかな近似は以下の通りとなる。

【００７８】 Ｐ(ｃ)＝ｐ （ｃ＝０） Ｐ(ｃ)＝（１−ｐ）／２５５ （ｃ≠０） ここで、Ｐ(ｃ)は値ｃを有する１バイトが発生する確率であり、０≦ｐ≦１である。 ネットワークトラフィックを監視することにより得られるｐの値は代表的には0.2
と0.3との間で変動する。 極めて短いパケットの場合、
または実際のパケットデータが圧縮不可能な場合（例えば、データがソースで既に圧縮されている場合）には、
ゼロ値の高い確率が、データ中に残っている冗長性であることが多い。 このような場合には、簡単なハフマン符号化機構の方がＬＺ機構よりも性能が優れていることがある。

【００７９】ハフマン符号化の基本原理は、可変長コードで固定長キャラクタを符号化する、ということであり、即ち、最も頻度の高いキャラクタにはより短いコードを使用し、最も頻度の低いキャラクタにはより長いコードを使用する。 ハフマン符号化機構は当業界で公知のものであるので、詳細には説明しないこととする。 ハフマンアルゴリズムを用いることにより、所与の確率分布について最適なコード割り当てを構成することが可能である。 その結果として生じるコード割り当ては、「接頭語が必要ない」という特性をも有している（即ち、別のコードの接頭語としてコードが生じることはない）。 これにより、符号化ストリームが一意の判読可能性および即時性を有するものとなる。

【００８０】ｐ＞1／256で、０〜255の値を有する８ビット入力バイトを仮定した、上記の簡単な確率分布の場合の、最適なハフマンコード割り当てを図１９に示す。
同図の中央列において、「ｚ」は１≦ｚ≦８の範囲の整数であり、そのｐの関数としての最適値は以下のようにして決定される。 この符号化機構の圧縮率は、次の方程式１で定義される。

【００８１】 Ｒ(ｚ,ｐ) ＝ ｐｚ／８ ＋ [(１−ｐ)／2040] × (２ ^9-z ＋2038) (1) １≦ｚ≦８の範囲の一定のｚについて、Ｒ(ｚ,ｐ)はｐ
の一次関数となる。 その傾きは非正数であり、ｚと共に単調に増加する。 また、値Ｒ(ｚ,０)は、ｚと共に単調に減少する。 図２０は、１≦ｚ≦４および０≦ｐ≦0.5
の場合のＲ(ｚ,ｐ)を示すグラフである。 従って、所与のｚについて値ｐ _zが存在し、ｚ'＞ｚおよびｐ＞ｐ _zの全てについて、Ｒ(ｚ,ｐ)≦Ｒ(ｚ',ｐ)となる。 ｐ _zが以下の一次方程式(2)の根であることが容易に確認されよう。

【００８２】 Ｒ(ｚ',ｐ) ＝ Ｒ(ｚ＋１,ｐ _z ) (2) 方程式(1)の式Ｒ(ｚ,ｐ)を方程式(2)に代入してｐ _zについて解くと、下記方程式が得られる。

【００８３】ｐ _z ＝ ２ ^8-Z ／ [(255×２ ^Z )＋256] 図２１は、０≦ｚ≦８についてｐ _zの値を示す表である。 完全性を期すためにｚ＝０での値ｐ _z ＝１も含めてある。 所与のｚの値（１≦ｚ≦８）は、ｐがｐ _z ≦ｐ≦
Ｐ _z-1の範囲にある場合に最適となる。 これらの間隔の幾つかを図２０に示す。 従って、64／319≦ｐ≦128／38
3（約0.2006≦ｐ≦0.3342）の場合にはｚ＝２が最適となる。 この範囲が典型的なＬＡＮトラフィックで経験上認められるｐの値を含んでいることに留意されたい。

【００８４】 ネットワークパケットのための圧縮機構前述の種々の圧縮方法が、図２２で組み合わされて、ネットワークパケットのカスタマイズされた圧縮のための効率的な機構が生成される。 図２２は、パケットアドレスフィールド（通常は２つの６バイトフィールド）を処理するためのブロック202を示している。 或る特定用途（例えばネットワークブリッジ）では、ほとんどのパケットが、小さなサブセットからのアドレス（即ちブリッジによりサービスされるステーションのアドレス）を備えている。 これらの頻繁に生じるアドレスは、テーブル中に記憶させることができ、また連続番号によりテーブル中に符号化することができる。 例えば、アドレステーブルが255バイト長である場合には、連続番号を１バイトで符号化することが可能であり、従って、アドレスフィールドについて６：１の圧縮率を達成することができる（テーブル中で発見されないアドレスをマークするために１つのコードは予約しておく）。 また別の用途では、アドレスフィールドは、パケットの残りと共に圧縮され、または未圧縮のまま送られる。

【００８５】ここで図２２を参照する。 入力パケット20
0は、アドレス処理ブロック202に送られる。 また、ブロック208は、強化ＬＺ２機構を表しており、中間初期辞書およびラン符号化強化（ＬＺＥ）を備えている。 ブロック204は、ｚ＝２の場合の上述の簡単なハフマン機構（ｚ−ＨＵＦ）を示している。 ハードウェアによる実施態様では、ＬＺＥおよびｚ−ＨＵＦが並行して実行される。 ブロック210は、カレントパケットについて最高性能を有する圧縮方法の出力を選択する。 次いでブロック
210は、圧縮パケット長を含む短いヘッダおよび選択された圧縮方法についての標識と共に、圧縮パケットを出力する。 また、その圧縮された出力の長さが、パケットの拡張を防止するために、ブロック200からの元のパケットの長さと比較される。 ＬＺＥおよびｚ−ＨＵＦのいずれもパケットの圧縮に成功しなかった場合は、元のコピーが、ヘッダ中の適当な指示と共にブロック206から出力される。

【００８６】一般に、パケットの大部分は、ブロック20
4のｚ−ＨＵＦまたはブロック206の「コピー」を用いた場合より、ブロック208のＬＺＥを用いた場合の方が良好な圧縮率を得ることになる。 しかし、パケットによっては（ほとんどの場合、短いパケット）、ｚ−ＨＵＦブロックおよび「コピー」ブロックの方が優れている。 代表的な圧縮結果を、異なる２つのパケットファイルについて図２３に示す。 同図の１行目は、最大16ビットの出力コードを有するＬＺＷによる実施態様（ＵＮＩＸ圧縮）を示している。 全パケットが１つのファイルとして圧縮される（即ち、パケットの境界が無視され、辞書が各パケット間で共用される）。 図２３の表の２行目は、
12ビットの出力コードを有するＵＮＩＸ圧縮の結果を示し、３行目は、上述のＬＺＥ圧縮による結果を示し、４
行目は、図２２に示すようにＬＺＥ圧縮機構とｚ−ＨＵ
Ｆ圧縮機構との双方を並行して用いた場合の圧縮結果を示している。 ３行目と４行目の結果は、各パケットを別個に圧縮することに相当するものである。

【００８７】図２３から分かるように、個々のパケットについての圧縮性能は、大きなパケットファイルを圧縮する場合に近似しており、また場合によってはそれよりも優れていることがある。 これは、パケット間の冗長性を利用することによって大きいパケットファイル中のデータソースの統計的特性に適応させる一層良好な機会が存在する場合であっても、真となる。 図２３の圧縮結果は、何日間も継続してソフトウェアを実行可能とした長期間の圧縮試験の結果と一致するものである。 ネットワークパケットが周期的にサンプリングされ、圧縮され、
圧縮解除されて、圧縮率の監視が行われた。

【００８８】図２４は、時間の関数として圧縮率を示すグラフである。 約200時間に亘って圧縮が測定された。
サンプリングされたデータセットは、1,420,998のパケットから成り、総サイズが198,754,151バイト、平均パケット長が140バイトであった。 このデータセットについての平均圧縮率は0.572であった。 図２５は、パケット長についてデータ分布（総バイト数の一部）を示すグラフである。 このデータセット中の50％を越えるバイトが、200バイト以下の長さのパケット中に含まれている。 図２６は、異なる範囲のパケット長について平均圧縮率を示すものである。 各パケット長毎に一貫した良好な圧縮率が維持されている。

【００８９】上述の装置は、「未加工の」アルファベットが大きい場合（例えば16ビット記号）にデータソース中の圧縮性能を改善するものである。 更に、この装置は、各ブロックが個々に圧縮されなければならない、短いブロックに区分されたデータソースについても、圧縮性能を改善するものである。 これらの強化により、ネットワークパケット用にカスタマイズされた圧縮機構が提供される。 従って、個々のネットワークパケットについての圧縮性能は、平均パケット長が極めて短い場合であっても、大きいパケットファイルで達成される性能に匹敵するものとなる。

【００９０】以上、本発明の原理を好適実施例に基づいて図示し説明してきたが、本発明は、そのような原理から逸脱することなく、その構成および細部を修正することが可能であることは明白である。 特許請求の範囲に記載の本発明の思想及び範囲に含まれる全ての修正例および変形例を本発明として請求する。

【００９１】以下に本発明の実施態様を列挙する。

【００９２】１． 辞書ベースの圧縮／圧縮解除装置において入力データを符号化する方法であって、この方法が、入力データからの一意の多数キャラクタストリングを辞書項目として前記圧縮／圧縮解除装置中に記憶させ、前記入力データからの多数キャラクタストリングを、そのキャラクタストリングと一致する辞書項目のアドレスに従ってコードワードへと符号化し、圧縮／圧縮解除辞書中に以前に記憶されていない、前記入力データからの単一キャラクタストリングを識別し、各々の単一キャラクタストリングを特殊コードと部分コードとに符号化し、その各々の特殊コードと部分コードとがその関連する単一キャラクタストリングの選択可能な部分を表しており、符号化された単一キャラクタストリングに対応するコードワードと、符号化された多数キャラクタストリングに対応するコードワードとの双方を有する圧縮データストリームを前記圧縮／圧縮解除装置から出力し、各々の特殊コードおよびその関連する部分コードが、単一キャラクタストリングを一意に識別し、および前記入力データ中に存在し得る一意の単一キャラクタストリングの総数のサブセットを表している、というステップを含むことを特徴とする、前記符号化方法。

【００９３】２． 特殊コード中に何ビットの単一キャラクタが含まれているかを決定する選択可能なパラメータｋに従って、圧縮データストリーム中の各々の単一キャラクタストリングについての特殊コードを符号化する、
というステップを含むことを特徴とする、前項１記載の符号化方法。

【００９４】３． 圧縮データストリームから単一キャラクタストリングを再構成するステップを含み、この再構成ステップが、圧縮データストリーム中の特殊コードを識別し、その特殊コードをその関連する単一キャラクタストリングの元の部分へと復号し、その特殊コードをその関連する部分コードと組み合わせる、というステップから成ることを特徴とする、前項２記載の符号化方法。

【００９５】４． 圧縮／圧縮解除装置により生成されるコード値の所定範囲内に存在するように特殊コードが符号化されることを特徴とする、前項１記載の符号化方法。

【００９６】５． 単一キャラクタストリングを符号化するステップが、単一キャラクタストリングからのビットのサブセットを特殊コードに割り当て、単一キャラクタからの残りのビットを部分コードに割り当てる、というステップから成り、単一キャラクタストリングを表すために特殊コード中のビットの数が圧縮／圧縮解除装置中で割り当てられたコードワードの数によって決定される、ということを特徴とする、前項１記載の符号化方法。

【００９７】６． 単一キャラクタストリングの特殊コードに割り当てられたビット数が、入力データの種類および構造に従って変更されることを特徴とする、前項５記載の符号化方法。

【００９８】７． 圧縮データストリーム中の連続するコードワードのランを検出するステップを含み、そのラン中の各コードワードが、同じキャラクタから構成された入力データストリングを表していることを特徴とする、
前項１記載の符号化方法。

【００９９】８． 圧縮データストリームからのコードワードのランを圧縮するステップを含むことを特徴とする、前項７記載の符号化方法。

【０１００】９． 圧縮／圧縮解除装置が圧縮データストリーム中のコードワードのランの一部を出力することを禁止するステップを含むことを特徴とする、前項７記載の符号化方法。

【０１０１】１０． 禁止されたコードワードに続いて送られる最初のコードワードの値により、禁止されたコードワードのシーケンスの再構成を可能にすることを特徴とする、前項９記載の符号化方法。

【０１０２】１１． 少なくとも１つの別の圧縮機構を用いて入力データを圧縮すると同時に、最良の圧縮率を提供する圧縮機構から圧縮データストリームを選択する、
というステップを含むことを特徴とする、前項７記載の符号化方法。

【０１０３】１２． 入力データのサイズが各々の圧縮データストリームよりも小さい場合に、未圧縮の入力データキャラクタを選択するステップを含むことを特徴とする、前項１１記載の符号化方法。

【０１０４】１３． 一意の単一キャラクタストリングの総数が、圧縮／圧縮解除装置中の辞書項目の総数よりも多いことを特徴とする、前項１記載の符号化方法。

【０１０５】１４． 一意の単一キャラクタストリングの数が２ ¹⁶であることを特徴とする、前項１記載の符号化方法。

【０１０６】１５． 辞書ベースの圧縮／圧縮解除装置において入力データを符号化する方法であって、この方法が、入力データからのキャラクタストリングを符号化し、一意の単一キャラクタストリングをデータ項目として圧縮／圧縮解除辞書中に記憶させ、符号化キャラクタストリングを表すコードワードから成る圧縮データストリームを圧縮／圧縮解除装置から出力し、入力データキャラクタのランを表す圧縮データストリーム中のコードワードのシーケンスを検出し、前記入力データキャラクタを表すランが、同じ値を有し、圧縮／圧縮解除装置により逐次に処理され、圧縮／圧縮解除装置が圧縮データストリーム中のコードワードのランの一部を出力するのを禁止することにより圧縮データストリームを圧縮し、
禁止されたコードワードに続いて送られる最初のコードワードの値により、禁止されたコードワードのシーケンスの再構成を可能にする、というステップを含むことを特徴とする、前記符号化方法。

【０１０７】１６． 圧縮／圧縮解除装置から出力された符号化値を、圧縮／圧縮解除辞書中に記憶されている最後のデータ項目の記憶位置と比較することによりランが検出されることを特徴とする、前項１５記載の符号化方法。

【０１０８】１７． 圧縮／圧縮解除装置から出力された符号化値が、辞書中に記憶されている最後のキャラクタストリングのアドレス値と等しくならなくなるまで、圧縮／圧縮解除装置が符号化キャラクタストリングを出力することを禁止するステップを含むことを特徴とする、
前項１６記載の符号化方法。

【０１０９】１８． 禁止されたコードワードに続いて送られる最初のコードワードを、圧縮／圧縮解除装置により圧縮解除データへと更に圧縮解除されたコードワードへと、圧縮解除するステップを含むことを特徴とする、
前項１５記載の符号化方法。

【０１１０】１９． 辞書ベースの圧縮／圧縮解除装置において入力データを符号化する回路であって、この回路が、前記入力データからの単一キャラクタストリングおよび多数キャラクタストリングをコードワードへと符号化し、そのコードワードを圧縮データストリームとして出力する、圧縮／圧縮解除エンジンと、前記入力データからの単一キャラクタストリングを第１コードフィールドと第２コードフィールドとに分割する手段と、前記圧縮データストリーム中の前記単一キャラクタストリングを識別するために前記第１コードフィールドを符号化する手段であって、前記第１コードフィールドが、圧縮／
圧縮解除エンジンのコード値の所定範囲内にあるように符号化される、前記符号化手段と、前記第１コードフィールドを復号してそれを前記第２コードフィールドと組み合わせることにより圧縮データストリームから単一キャラクタストリングを生成する手段であって、前記第１
および第２コードフィールドが、入力データ中で発生する可能性のある全ての単一キャラクタストリングのサブセットを表すことにより、符号化キャラクタストリングのビット長を短縮する、前記生成手段ととを備えることを特徴とする、前記符号化回路。

【０１１１】２０． 前記符号化手段が前記第１コードフィールドからの選択可能なビット数を所定値と合計することを特徴とする、前項１９記載の符号化回路。

【０１１２】２１． 前記生成手段が、前記第１コードフィールドから所定値を減算し、その減算結果からの選択可能な数のビットを前記第２コードフィールドと組み合わせることを特徴とする、前項１９記載の符号化回路。

【０１１３】２２． 前記圧縮／圧縮解除エンジンに接続され、その圧縮／圧縮解除エンジンが前記圧縮データストリーム中のコードワードの幾つかを出力することを禁止する、エンコーダラン強化エンジンを備えていることを特徴とする、前項１９記載の符号化回路。

【０１１４】２３． 前記圧縮／圧縮解除エンジンに接続され、禁止されたコードワードに続いて送られる最初のコードワードの値から、禁止されたコードワードのシーケンスを再構成する、デコーダラン強化エンジンを備えていることを特徴とする、前項２２記載の符号化回路。

【０１１５】

【発明の効果】本発明は上述のように構成したので、データ圧縮率を高め、辞書ベースの圧縮／圧縮解除装置に必要な記憶装置の量を削減するために、異なる形式の入力データおよび異なるデータ構造に適応可能な、データ圧縮の初期設定プロセスを提供することができる。

【図面の簡単な説明】

【図１】本発明による強化が実施された圧縮／圧縮解除装置の概要を示すブロック図である。

【図２】ＬＺ圧縮の基本原理を示す説明図である。

【図３】空の初期辞書を有する従来のＬＺ圧縮方式での新キャラクタの伝送を示す説明図である。

【図４】本発明による中間辞書初期設定を用いた強化Ｌ
Ｚ圧縮による新キャラクタの伝送を示すフローチャートである。

【図５】基本的なＬＺＥの中間初期設定プロセスを示すフローチャートである。

【図６】図５のサブプロセスである「新キャラクタ」の符号化を示すフローチャートである。

【図７】図１の圧縮副装置で図６の符号化サブプロセスを実行するための回路を示す機能ブロック図である。

【図８】図６のサブプロセスにより生成された符号化コードについての「新キャラクタ」符号化サブプロセスを示すフローチャートである。

【図９】図１の圧縮解除副装置で図８の符号化サブプロセスを実施するための回路を示す機能ブロック図である。

【図１０】本発明による異なる初期設定方式についての圧縮結果を示す表である。

【図１１】従来のデータ圧縮装置を示すブロック図である。

【図１２】強化Lempel-Zivランレングス符号化機構を図１に示す圧縮副装置で実施するための回路を示すブロック図である。

【図１３】本発明による強化Lempel-Zivランレングス符号化方法を実施するためのプロセスを示すフローチャートである。

【図１４】従来のデータ圧縮解除装置を示すブロック図である。

【図１５】本発明による図１の圧縮解除副装置で強化Le
mpel-Zivランレングス符号化を実施するための回路を示すブロック図である。

【図１６】本発明による強化Lempel-Zivランレングス符号化方法を示すフローチャートである。

【図１７】中間初期設定およびランレングス符号化を行うための方法の図形化して示す説明図である（１／
２）。

【図１８】中間初期設定およびランレングス符号化を行うための方法の図形化して示す説明図である（２／
２）。

【図１９】最適なハフマン符号化割り当てを示す表である。

【図２０】ハフマン符号化データの圧縮率を示すグラフである。

【図２１】異なるビット長についての確率分布を示す表である。

【図２２】本発明による並列「最良利益」圧縮装置を示すブロック図である。

【図２３】種々のネットワークパケットファイルについての圧縮結果を示す表である。

【図２４】実際のネットワークパケットデータに対して図２２の装置を用いた場合の圧縮率を時間の関数で示すグラフである。

【図２５】図２４のデータ分布をパケット長の関数として示すグラフである。

【図２６】図２４のデータ圧縮率をパケット長の関数として示すグラフである。

【符号の説明】

24 圧縮副装置 26 圧縮解除副装置 30 圧縮エンジン 32 記憶装置 34 中間初期設定エンコーダ 36 デコーダ 38 エンコーダラン強化エンジン 40 デコーダラン強化エンジン