JPH01314430A - 可変ビット長コード語のビット長通信方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔発明の分野〕 本発明は、デジタルデータ圧縮システムに関するもので
あり、とりわけ、適応的で、可逆の、すなわち、損失の
ないデジタルデータ圧縮システムに関するものである。

〔関連出順に対するクロスリファレンス〕これは、譲渡
光が共通で、同時に提出された、名指しされた発明者の
３つの米国特許出頭の１つである。他の出願は、“有限
長の探索窓によるテキスト置換データ圧縮（Ｔｅｘｔｕ
ａｌ　５ｕｂｓｔｉｔｕｔｉｏｎＤａｔａ　Ｃｏｍｐｒ
ｅｓｓｉｏｎ　ｗｉｔｈ　Ｆｉｎｉｔｅ　Ｌｅｎｇｔｈ
　ＳｅａｒｃｈＷｉｎｄｏｗｓ　（Ｄ／８７００６））
”と、“テキスト置換データ圧縮システムのための探索
木データ構造コード化（Ｓｅａｒｃｈ　Ｔｒｅｅ　Ｄａ
ｔａ　５ｔｒｕｃｔｕｒｅ　Ｂｎｃｏｄｉｎｇ　ｆｏｒ
Ｔｅｘｔｕａｌ　５ｕｂｓｔ＋ｔｕｔｉｏｎ　Ｄａｔａ
　Ｃｏｍｐｒｅｓｓ＋ｏｎ　Ｓｙｓｔｅｍｓ〈Ｄ／８８
０６８））″　に関するものである。これらの異なる出
願によって取り扱われる発明は、さまざまな方法で組み
合わせることができるので、共通の詳細説明を用いてい
る。

〔発明の背景〕

デジタルデータ圧縮は、例えばファイルに関する記憶要
件を緩和し、帯域幅を制限された通信チャネルで、デー
タを転送することができる率を増し、強化された機密保
護を提供するため、そのコード化前に、データの内部冗
長度を低下させるのに用いることができるので、デジタ
ルデータ圧縮は、重要なツールである。

専用データ圧縮システムと汎用データ圧縮システムがあ
る。専用システムは、それらが最適化されているソース
データの圧縮に用いられる場合には、たいてい満足のい
くようになっている。しかし、汎用ンステムは、通例的
には、ソースデータに適応するように設計されているた
め、通常、それらは、未知または種々のソースデータタ
イプを圧縮するのにより適している。これら汎用システ
ムは、小ファイルのため、及び、内部的に一致性のない
統計的特性を備えたソースデータのために大幅な圧縮を
加えることが必要とされる可能性のある、ソースデータ
の組成構造の基本的変更に敏速に適応できるだけでなく
、安定した統計的特性を備えた大ファイルのために近最
適圧縮を加えることもできるのが、理想である。設計者
は、これらの競合する設計目的を解決するため、さまざ
まなアプローチを行ったが、彼らの努力結果は、十分に
満足のいくものではなかった。

ンヤノ：／　（Ｓｈａｎｎｏｎ）　　の通信理論（１９
４８年のベルシステムテクニカルジャーナル（Ｔｈｅ　
Ｂｅ１ｌ　ＳｙｓｔｅｍＴｅｃｈｎｉｃａｌ　Ｊｏｕｒ
ｎａｌ）　　第２７巻第３号の３７９〜４２３頁、及び
１９４８年の第４号の６２３〜６５６　頁における、シ
ー・イー・ンヤノン（Ｃ，Ｅ、５ｈａｎｎｏｎ）著゛数
理通信理論（Ａ　ｌｌａｔｈｅｍａｔ＋ｃａｌ　Ｔｈｅ
ｏｒｙ　ｏｆ　Ｃｏｍｍｕｎ＋ｃａｔ＋ｏｎ）”は、所
定のソース記号の理想的コード化では、その記号の発生
確率Ｐの−Ｌｏｇ　２に等しいスペースを用いることを
示している。コード化が、このメモリーのないモデルに
適合する場合、記号を表すのに必要な平均スペースは、
ソース記号のエントロピーである： 【＝０ ここで：Ｘは、独特なｎ個の記号を含むソース記号から
ランダムに選択した記号であり；Ｃ，は、可能性のある
全てのソース記号をカバーする。

ただし、実際問題として、式（１）のゼロ次エントロピ
ーモデルは、従来の多くのソースの冗長の有効部分を捕
捉することができない。例えば、英語のテキストは、一
般に１次エントロピーにおいてかなりのドロップを示す
： ここで＝ｘｙは、ランダムに選択した１対のソース文字
である。

他に、統計的確率における捕捉メカニズムにあらかじめ
調整を施す必要のない、高次の首尾一貫したテキスト及
び同様のソースデータを捕捉するための、いわゆる“テ
キスト置換”データ圧縮処理が提案されている。ジェイ
・ジブ（Ｊ、２ｉｖ）　　及びエイ・レンペル（Ａ、　
Ｌｅｍｐｅｌｊは、あらかじめコード化された記号のス
）　ＩＪソング再発生は、こうした再発生直後の記号（
すなわち、再発生ス）　ＩＪソング接尾文字）を、（１
）前に発生したス）　ＩＪソング一方の端（例えば、前
端）を指示し、（２）再発生ストリングの長さを識別す
るコピーコード語から始めることによって表すことがで
きるという考えに基づいた、テキスト置換処理用の演算
モデルを提案した。彼らは、こうしたコピー譜が、再発
生する記号ス）　ＩＪソング十分かつ完全に規定するも
のと認識し、従って、彼らは、再発生する記号ストリン
グの記号とコード語を“置換″して、その圧縮表現を与
えることを構忠した。１９７７年のＩ　ＥＥＥ情報理論
に関する会報（ＩＥＥεＴｒａｎｓａｃｔｉｏｎｓ　ｏ
ｎＩｎｆｏｒ＋ｙｆｉｔｉｏｎ　Ｔｈｅｏｒｙ）　、Ｉ
Ｔ−２３第３号、３３７〜３４３頁におけるジェイ・ジ
ブ（Ｊ、２ｉｖ）他による“順次データ圧縮のための汎
用アルゴリズム（Ａ　ｌｎｌｖｅｒｓａｌＡｌｇｏｒｉ
ｔｈｍ　ｆｏｒ　５ｅｑｕｅｎｔｉａｌ　Ｄａｔａ　Ｃ
ｏｍｐｒｅｓｓ＋ｏｎ）”参照のこと。

あいにく、もとのジブーレンペル（Ｚｉｖ−Ｌｅｍｐｅ
ｌ）アルゴリズムに基づ（圧縮システムは、許容できな
いほど遅い傾向があり、とりわけ高圧縮をなし遂げられ
なかった。速度を改善するため、彼ら、及び該分野の他
の研究者は、各種代替案を開発した。これらの代替案の
い（つかは、人工的に厳格なパージング（ｐａｒｓｉｎ
ｇ）　　メカニズムを採用して、コピーコード語の発生
を簡単にし、圧縮の実施に必要なデータ構造のサイズを
制限した。例えばジェイ・ジブ（Ｊ、Ｚｉｖ）他による
前述の文献；　１９７８年のＩ　ＥＥＥ情報理論に関す
る会報（＋ＥＥＥＴｒａｎｓａｃｔｉｏｎｓ　ｏｎ　［
ｎｆｏｒｍａｔ＋ｏｎ　Ｔｈｅｏｒｙ）　　、ＩＴ−２
４第４号、４０５〜４１２頁におけるジエイ・ジブ（Ｊ
、Ｚｉｖ）による“個々のシーケンスに関するコード化
定理（Ｃｏｄｉｎｇ　Ｔｈｅｏｒｅｍｓ　ｆｏｒ　Ｉｎ
ｄｉｖｉｄｕａｌ　５ｅｑｕｅｎｃｅｓ）”；１９７８
年のＩ　ＥＥＥ情報理論に関する会報（ＩＥＥＥＴｒａ
ｎｓａｃｔｉｏｎｓ　　ｏｎ　　Ｉｎｆｏｒｍａｔｉｏ
ｎ　　Ｔｈｅｏｒｙ）　　、ＩＴ−２４第５号、５３０
〜５３６頁におけるジェイ・ジブ（Ｊ、Ｚｉｖ）他によ
る“可変速コード化による個々の／−ケンスの圧縮（Ｃ
ｏｍｐｒｅｓｓｉｏｎ　ｏｆ　Ｉｎｄｉｖｉｄｕａｌ　
５ｅｑｕｅｎｃｅｓＶｉａ　Ｖａｒｉａｂｌｅ−Ｒａｔ
ｅ　Ｃｏｄｉｎｇ）”；及び１９８４年８月７日、“デ
ータ信号を圧縮し、圧縮データを復元するための装置及
び方法（Ａｐｐａｒａｔｕｓ　ａｎｄ　Ｍｅｔｈｏｄ　
ｆｏｒＣｏｍｐｒｅｓｓｉｎｇ　　Ｄａｔａ　　Ｓｉｇ
ｎａｌ　　ａｎｄ　　Ｒｅｓ、ｔｏｒｉｎｇ　　ｔｈｅ
Ｃｏｍｐｒｅｓｓｅｄ　Ｄａｔａ）”　に対し発行され
たダブリュ・エル・イーストマン（Ｗ、Ｌ、Ｅａｓｔｍ
ａｎ）他の米国特許明細書第４．４６４．６５０　号参
照のこと。しかしながら、これら修正されたジブーレン
ベル（Ｚｉｖ−Ｌｅｍｐｅｌ）　スタイルのデータ圧縮
システムは、それらが適応する速度及びそれらが行う圧
縮の両方または一方で判断するそれらの性能が、−船釣
には、期待はずれのため、十分な満足が得られなかった
。

データ圧縮にテキスト置換を利用するため提案された、
幾分異なるアプローチは、個々の記号及び記号ストリン
グに関する適応リストまたは辞書の構築に基づくもので
ある。例えば、１９８４年のＩＢＭ研究報告ＩＦ　（１
Ｂ！Ｊ　Ｒｅ５ｅａｒｃｈ　Ｒｅｐｏｒｔ）ＲＣ１０６
３０、＃４７７９８におけるブイ・ニス・ミラー（Ｖ、
　Ｓ、ｌＡ１１ｌｅｒ）池による“ジブ及びレンペルに
よるテーマニ関スる変形例（Ｖａｒｉａｔｉｏｎｓ　ｏ
ｎ　ａ　Ｔｈｅｍｅ　ｂｙ　Ｚｉｖ　ａｎｄＬｅｍｐｅ
ｌ）”、１９８５年のＮＡＴＯ，ＡＳ　ＩシリーズＦ（
ＮＡＴＯ，＾ＳＩ　５ｅｒｉｅｓ　Ｆ＞第１２巻、１３
１−１４１頁における、語に関する組合せアルゴリズム （Ｃｏｍｂｉｎａｔｉｏｎａｌ　Ａｌｇｏｒｉｔｈｍｓ
　ｏｎ　Ｗｏｒｄｓ）；１９ｇ４年のＩＥＥＥコンピュ
ータ（ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ）　　、第１７巻、
第６号の８〜１９頁における、ティー・エイ・ウェルチ
（Ｔ、　Ａ、Ｗｅｌｃｈ）　　による“高性能データ圧
縮のための技術（Ａ　Ｔｅｃｈｎｉｑｕｅ　ｆｏｒ　Ｈ
ｉｇｈ　Ｐｅｒｆｏｒｍａｎｃｅ　ＤａｔａＣｏｍｐｒ
ｅｓｓ　１ｏｎ）”；及び、１９８４年のＡＣＭの通信
（Ｃｏｎ＋ｎ＋ｕｎｉｃａｔｉｏｎ　ｏｆ　ｔｈｅ　Ａ
ＣＭ）、第２９巻、第４号の３２０〜３３０頁における
、ジェイ・エル・ボンクレイ（Ｊ、Ｌ、　Ｂｏｎｋｌｅ
ｙ）　　による“局所的に適応するデータ圧縮室（Ａ　
Ｌｏｃａｌｌｙ　Ａｄａｐｔｉｖｅ　Ｄａｔａ　Ｃｏｍ
ｐｒｅｓｓｉｏｎＳｃｈｅｍｅ）”参照のこと。しかし
、これらのシステムは、適応が緩慢で、得られる圧縮は
劣っている。

先行技術の欠点を考慮すると、安定した統計的特性を有
する大規模なソースデータ及び規模がより小さいソース
データや可変の統計的特性を有するソースデータに対し
信頼できる、有効な圧縮を施すための、実用的な、汎用
で、適応的な、可逆の（すなわち損失のない）　データ
圧縮システムに対する必要が、まだ存在することは明ら
かである。

テキスト置換技術は、該タスクによく適合するものであ
るが、その潜在能力を十分に実現するには、実際に、こ
うしたデータ圧縮を実施するだめの改良された方法及び
手段が必要になる。

〔発明の要約〕

本発明によれば、圧縮データをコード化するための可変
長のコード語を発生させるのに、開始、ステップ、停止
の単項コード化が用いられる。

〔望ましい具体例の詳細な説明〕

本発明は、いくつかの図示具体例に関連して、以下で少
し詳しく説明が施されているが、それらの具体例に本発
明を制限する意図のないことは理解すべきである。それ
どころか、その目的は、付属の特許請求の範囲によって
定義の本発明の精神及び範囲内にある全ての修正、代替
案、及び、相当物を包含することにある。

Ａ、概要 ここで図面を、とりわけこの時点では第１図を参照する
と、順次デジタル方式でコード、化されるソースデータ
を圧縮する圧縮器６２と、そのデータを順次復元する伸
長器６３を備えたデータ圧縮システム６１が示されてい
る。本発明の各種具体例が説明されており、それ以外に
ついても連想させられるが、それらのそれぞれが、可逆
の、すなわち、損失のないデータ圧縮システムを提供し
、従って、伸長すなわち復元されるデータは、もとのソ
ースデータとほぼ同一である。さらに、本発明の全ての
具体例は適応的であり、従って、ソースデータは、例え
ば、英数字テキスト、走査像または合成像、大または機
械が読み取れるコンピュータコード、こうしたソースタ
イプ及び／又はその他のソースタイプによるさまざまな
組合せのいずれかによって構成することができる。

まず、圧縮器６２及び伸長器６３は、適切な構成のハー
ドウェアにより、すなわち、適性にプログラムされた汎
用デジタルコンピュータを用いることにより実現可能で
あることを理解すべきである。

さらに、圧縮器６２及び伸長器６３は、例えば、圧縮ソ
ースデータをファイルサーバ（不図示）にロードしたり
、復元ソースデータをファイルサーバから検索するため
、それらを局所化することが所望の場合には、同じ場所
に配置することができる。

実際圧縮器６２及び伸長器６３の単一場所でのソフトウ
ェアの実現は、同じコンピュータを利用し、攬令に基づ
いて圧縮器及び伸長器のプログラムを実施することで可
能になる。代替案として、例えば、制限された帯域幅の
通信媒体（不図示）を介してデータの送信をし、受信を
するため、それらの機能を分散することが所望の場合に
は、圧縮器６２及び伸長器６３は、異なる場所に配置す
ることができる。ファイル及びストリームの圧縮器及び
伸長器について論考されるが、それらの主たる相違点は
、それらの人力データのフロー制御と、それらのバイト
のアライメントを復元するための、パッドコード語で圧
縮データに対し行うパッディング（ｐａｄｄｉｎｇ）　
　に関連する。データは、“クライアント（ｃｌｉｅｎ
ｔ）　”　　（圧縮器の“クライアント”はデータソー
スであり、伸長器の“クライアント”はデータシンクで
ある）によって、ストリーム圧縮器に“押し°（ｐｕｓ
ｈｅｄ）”込まれたり、ストリーム伸長器から“引き（
ｐｕｌｌｅｄ）”出されたりするが、一方で、データは
、内部制御によってファイル圧縮器及び伸長器に“押し
”込まれる。パッドコード語による圧縮データのパフデ
ィングについて、さしあたっての言及をおこなうが、該
主題は、一般に、本発明の範囲を超えるものであり、当
該技術における熟練者の作業知識内のものである。

本発明を実施するため、圧縮器６２は、最近圧縮された
、連携するソース記号の全てに関する完全な、現在の記
録を、その発生順に従ってアセンブルし、保全する。こ
の記録は、適合するメモリーに保持され、最も新しく圧
縮された記号の位置ｌと、Ｗを探索窓の記号長とした場
合の、前に圧縮された記号の位置ｉ　−ｗとの間のソー
スデータストリームにおいて、以前に圧縮されている記
号の全てにわたる先入れ／先出しく“ＦＩＦＯ”　）　
　“探索窓”を提供する。動作時、探索窓に挿入される
前に、ソース記号がテストを受け、記号位置ｉ＋１にお
けるテスト記号に、それに後続する１つ以上の記号を追
加することによって形成される伸長記号ストリングのい
ずれかに対する整合を探索窓が含んでいるか否かの判定
をし、もし含んでいれば、該整合のうち最長のものの記
号長を求める。整合が見つからなければ、すなわち、現
存する最長の整合が、所定の“最小有意味コピー長”の
基準を満たすには短すぎる場合には、圧縮器６２が、一
般形態“リテラルｘｌ″を有する固定長または可変長の
リテラルコード語の後の圧縮データストリームにテスト
記号を挿入する。次に、伸長器６３は、このコード語が
、それに対し、次の“ｘｌ”記号を直接その出力に送る
ように命令するものと解釈する。

一方、探索窓が、こうした伸長テスト記号のストリング
にとって十分な長さの整合を含んでいる場合、圧縮器６
２は、（１）現存する最長の整合を終了する記号（すな
わち、該整合の長さをそれ以上延長できない記号）を見
つけるか、または、（２）許容できる整合の最大長を見
つけたと判定するまで、さらに非圧縮データス）　ＩＪ
−ムの記号毎に調べを進めていく。こうした事象のいず
れかに応答し、圧縮器６２は、整合された記号のス）Ｉ
Ｊシンク代わりに、固定長または可変長のコピーコード
語の一般的な形“ＸＣ＋−Ｖをコピー”を圧縮データス
トリームに挿入する。このコード語は、ｙ≦Ｗの場合、
前に復元されているソース記号“ｙ″を飛び越して戻り
、それから、漸次より最近のものになる連続した記号”
Ｘｃ”をその出力にコピーし、飛越し人口位置の記号か
らそのコピー処理を始めるように伸長器６３に命令する
。

Ｂ、基本的な具体例 明らかなことではあるが、達成される圧縮は、コピー語
、及び、リテラル語に必要なスペースによって決まる。

第２図は、それぞれ、固定長の８ビツト及び１６ビツト
のリテラルコード語及びコピーコード語を用いた、テキ
ストの普通の一節に関する単一パスの圧縮を示している
。これらのコード語の長さは、本発明の基本的特徴では
ないが、これらの特定のコード語は、本発明の実施にと
って十分であり、バイトが各文字テキストと各コンピュ
ータソースコードの両方または一方につき、通常の８ビ
ツトで構成されるソースデータとのアライメントがとれ
るという利点を有することを理解すべきである。

しばらくコード語のレイアウトに焦点を合わせると、８
ビツトのリテラルコード語の最初の４つのビット位置は
、通常“００００”のような、リテラルコード語の一義
的識別を行うだめの確保された導入ピットシーケンスを
納めるリテラルフラグすなわち識別フィールドしＦに割
り当てられることが分かる。その場合、こうしたコード
Ｊ５の他の、すなわち、最後の４つのビットは、リテラ
ル長ｘｌを〔１・・・１６）の範囲でコード化するリテ
ラル長フィードＬＬに常駐し、これによって、１６まで
のリテラル記号をこうしたコード語に付加することが可
能になる（すなわち“最大許容リテラル長”）。

一方、コピーコード語は、コピー長と、変位すなわち位
置決め値の両方を含んでいる。この場合、各コピーコー
ド語の最初の４つのビット位置は、コピー長Ｘｃを〔２
・・・１６〕の範囲でコード化するコピー長フィールド
ＣＬに割り当てられ、一方、その残りの、すなわち、最
後の１２のビア）位置は、変位ｙを〔１・・・・４０９
６　）の範囲でコード化するコピー変位フィールドＣＤ
を提供する。従って、１６までの記号は、単一のコピー
コード語で表すことができ、これにより、“最大許容可
能コピー長“が定義される（これは、コードが適性に１
つずつシフトされるいくつかの例の１つであり、これに
より、２進値ｌを有するコードは、コピー長２を表し、
２進値２を有するコードは、コピー長３を表し・・・）
。さらに、整合記号ストリングの起点は、４０９６の最
も新しく処理された記号の位置の１つである場合に限っ
て、一義的識別が可能になるため、探索窓の有効長が決
まる。

第２図に示す例を単純化するため、圧縮器６２の探索窓
が、当初空であり、英数字文字、句読点、及び、サンプ
ルテキストの中間のスペースの全て（すなわち、その“
ソース記号″の全て）を記１徴するのに十分な長さを備
えるものと仮定した。本発明の具体例の１つに従ってソ
ースデータを圧縮し、伸長するだめの単純化コンピュー
タプログラムが、付録Ａに記載されているが（より簡単
な手順の一部については、機能本位に説明されているだ
けである）、これは、参考までに本書に組み入れたもの
である。

明らかに、本発明の付録Ａの具体例は、圧縮器６２の動
作に下記の論理規則を課す：（１）圧縮器６２がアイド
ル状態の場合、及び、それに続ぐ１つ以上の記号によっ
て拡張される所定のテスト記号（すなわち、拡張テスト
記号ストリング）に関する探索窓内にある最長の整合が
、記号２つの長さ未満の場合には、“リテラル”が開始
される；（２）いったん開始されると、少なくとも３つ
の記号にまたがる整合が見つからない限り、その最大許
容可能長に達するまでに、リテラルが割込まれることは
ない；（３）（ｉ）　　こうした割込みの場合、または
、（１１）圧縮器６２がアイドル状態であったり、少な
くとも２つの記号にまたがる整合が見つかる場合には“
コピー”が開始される；（４）（ｉ）　　リテラルが割
り込まれるか、または（ｉｉ　）最大許容可能長のリテ
ラルが得られる場合には、必ず、リテラルコード語及び
それに付加されるリテラルソース記号が、圧縮データス
トリームに挿入される；（５）整合のとられた人力また
はテスト記号ストリングが、（ｉ）　得られる最長の整
合の長さをそれ以上延長しない記号によって終了するか
、または、　（ｉｉ　）最大許容可能コピー長にまたが
る場合には、必ず、コピーコード語が圧縮データストリ
ームに挿入される。付録に見られるコメントは、前述の
規則とコードを…互に関係させる手助けとなる。さらに
、付録Ａの序文は、圧縮プログラムの実行速度を上昇さ
せ、その実行に必要な記憶量を減少させるために利用可
能な、いくつかの技術に関するものである。

圧縮器６２の探索窓が当初空であるという単純化の仮定
を考慮すると、以上の要約された圧縮規則によって、圧
縮器６２は、第２図に示すサンプルテキストの最初のい
くつかの記号をリテラルコード語に付加することになる
のは明らかである。実際、この場合には、圧縮規則は、
記号１−２６のリテラルコード化を必要とし、従って、
この最初の記号ストリングには、最大許容可能リテラル
長を有するどの１つのリテラルコード語が伸長器６３に
有効に伝えることができるよりも多くのリテラルが含ま
れることになる。こうした状況は、時々、とりわけ始動
時、及び、圧縮器６２があるタイプのソースデータから
別のタイプのソースデータに移行中に発生しやすくなり
、従って、圧縮器６２は、最大許容可能リテラル長のリ
テラル記号ストリングをアセンブルする場合には、必ず
、再循環するということを理解するのが重要である。こ
の再循環の結果、圧縮器６２は、さらに長いリテラル記
号のストリングを２つ以上の許容可能な長さのサブスト
リング組区分し、該サブス）　ＩＪソング別個のリテラ
ルコード語に付加して、それらを伸長器６３に送る。例
えば、第２図に示すテキストの記号１−１６が、長さの
値が１６の第１のリテラルコード語に付加され、次に、
記号１７−２６が、長さの値が１０の第２のリテラルコ
ード語に付加される。明らかなことだが、これらのより
長いリテラルの便益の１つは、それらが、圧縮データス
トリームに挿入されるリテラルコード語の数を有効に減
少させ、同時に、圧縮器は、新しいソースデータタイプ
に適応するということにある。

第２図のテキストの記号２７は、記号位置１＋１にある
時、記号２７７２９が前に発生した記号１−３に整合す
るため、記号３つ分の長さの整合が見つかる。従って、
さらに進行中の“リテラル”が割り込まれ、“コピー″
が開始する。サンプルテキストの簡単な再検討により、
先行する記号２つ分の長さの整合がいくつか明らかにな
るが、これは、この特定の例において、たまたま生じた
“コピー”の最初の例である。従って、それら先行する
整合のそれぞれは、記号２つ分の長さしかなく、リテラ
ルが発生している間に生じたものであるため、付録Ａの
圧縮規則に従って、それらは無視されたと理解すべきで
ある。

記号２７−２８に関して見つけた整合に応答して、“コ
ピー”を開始すると、圧縮器６２は、さらに記号３８に
おけるような、整合を終了するソース記号（すなわち、
それ以上最も長い整合の長さを延長できない記号）を見
つけるまで、または、最大許容可能コピー長の整合を見
つけるまで、後続のソース記号について、次々と整合記
号のストリングを拡張する。これらの事象のいずれかが
生じると、圧縮器６２は、整合のとれた記号ストリング
の代わりに、コピーコード語を圧縮データストリームに
送り込む。コピーコード語は、該記号ストリングの長さ
を表示し、その前に発生した先行記号の位置を示すポイ
ンタを提供するが、これによって、伸長器６３は、前述
の“飛び越して戻り″、“繰り上げてコピーする”処理
により、コード語で表された記号を回復することが可能
になる。

第３図を参照すると、圧縮器６２の付録Ａの具体例は、
（２）探索窓記号位置１〜ｉ−ｗにおいて、最も新しく
圧縮された記号によって先行される、（１）記号位置ｉ
＋ｌにまで至り、それを含む記号位置において、ソース
記号のまさに圧縮されるようとしている部分からの記号
を記憶する先入れ／先出しくＦＩＦＯ）人力バッファ７
１から構成される。ソフトウ二アの実現において、バッ
ファ７１は、好都合なことには、四分円に分割される円
形バッファであるため、圧縮すべきソース記号がつきる
まで（例えば、現在のソースファイルの最後に達するま
で）　、バッチトランザクション（ｂａｔｃｈｔｒａｎ
ＳａＣｔ　１ｎｎ）を用いて、ソース記号を規則的にバ
ッファに対し四分円毎に再ロードすることができる。そ
れによって、圧縮器６２に対するソース記号のタイムリ
ーなフローを維持するのに必要な■１０トランザクショ
ンの数が減少する。こうした実現時には、圧縮器６２に
よって行われる圧縮をその入力バッファ７１の再ローデ
イングから有効に切り離すのに十分な大きさになるよう
に、四分円が選択される。

探索及び更新論理部７２は、発生順に従って、バッファ
７１の記号位置１〜１−Ｗ（すなわち、探索窓）内にお
ける記号を互いに連係させ、順次記号がソフトされて、
探索窓に入り、それを通り、そこから出て（る時、それ
らの記号ストリングのうち最も新しく発生したストリン
グを追跡する、探索木編成によるデータ構造７３をアセ
ンブルし、これを保全する。探索木データ構造７３によ
って得られる連係のカットオフの深さは、都合よく、最
大許容可能コピー長に等しくなるように選択され、これ
により、それを記憶するのに必要な記憶量、及び、それ
を保全するのに必要な処理時間が制限されることになる
。探索木７３のサイズをさらに縮小するために利用可能
な他のいくつかの技術、及び、それを更新するのに必要
な時間については、さらに詳しく後述される。

動作時、探索及び更新論理部７２は、探索木７３を用い
て、記号位置ｉ　＋　１に生じるテスト記号に関するバ
ッファ７１の記号位置ｉ　−ｉ　−ｗ内におけるどこか
に整合があるか否かを判定する。整合が見つかれば、論
理部７２は、記号位置１＋２における記号をテストスト
リングに付加するこ止によって、それを拡張し、次に、
この拡張された入力記号ストリングに対する探索窓内に
、やはり整合があるか否かを判定する。これは、反復処
理であり、これによって、探索及び更新論理部７２は、
現在の最長の整合の長さを延長することができない記号
（すなわち整合を終了する記号）に出くわすまで、また
は、最大許容可能コピー長の整合の存在が識別されるま
で、非圧縮記号について、次々と、テスト記号ストリン
グを拡張することによって、それを漸次捕捉していく。

これらの事象のいずれかが発生すると、探索及び更新論
理部７２は、上に要約したコード化規則に従って動作し
、１つまたは複数のテストされる記号が、コピーエンコ
ーダ７５によってコピーコード語としてコード化される
べきか、または、リテラルエンコーダ７６によってリテ
ラルコード語に付加されるべきか判定するディスクリミ
ネータに対し、報告を行う。そのため、探索及び更新論
理部７２によって与えられる報告は、見つかった最長の
整合の長さと、先行して発生した整合のとられた記号の
探索窓の位置とを識別する（整合の長さが、コピーに必
要とされる最小整合長未満であれば、この位置情報は報
告する必要がない）。この場合、整合記号ストリングの
先行記号すなわち最初の記号の場所が、記号位置１＋１
からの変位としてコピーエンコーダ７５に報告されるが
、その場所は、別の方法で明確に識別できるのは明らか
である。

探索及び更新論理部７２からの報告に応答して、コピー
コード語が、コピーエンコーダ７５によって出力バッフ
ァ７７に挿入され、これによって、ディスクリミネータ
７４は、こうしたコード、４によってコード化するのに
十分な長さの整合が識別されたものと結論を下すことに
なる。コピーコード語が、整合のとられた記号ストリン
グの記号に取って代わるので、整合のとられた記号スト
リングの全ての記号は、ディスクリミネータ７４が探索
及び更新論理部７２からのそれ以上の報告に応答する前
に、バッファ７１の探索窓の四分円すなわちセクター内
ヘンフトされる。そのため、各コピーの長さに対応する
カウントが、カウンタ制御式ゲート７８の文字スキップ
カウンタにロードされ、コピーによって表された記号が
人力バッファ７１の探索窓のセクターにロードされてい
る間、コード化論理部７４−７６が一時的に、それ以上
コード語を発生できなくなる。整合のとられた記号スト
リングの順次記号のそれぞれが、探索窓にロードされ、
その結果、整合のとられたストリングに続く記号からコ
ード化が再開されることになる。

一方、リテラルの長さがまだ分かっていなくても、探索
及び更新論理部７２が、コピーとしてコード化されるの
に十分な長さの整合を見つけることができない場合には
、ディスクリミネータ７４によってリテラルが開始され
る。いったんリテラルが開始すると、探索及び更新論理
部７２は、非圧縮記号が記号位置１＋１にシフトされる
際、リテラルに対する割込みを保証するのに十分な長さ
の拡張テスト記号ストリングに関する整合を見つけるま
で（たとえば、少なくとも記号３つ分の長さ）、又はテ
ストされた記号の数が、最大許容可能リテラル長さに達
するまで、非圧縮記号について順次その拡張をテストす
る。該事象のいずれかが生じると、必ずリテラルエンコ
ーダ７６がリテラルの長さを識別するリテラルコード語
を出力バッファ７７に挿入し、次にリテラルの累積した
記号を順次バッファ７７にコピーして、これによりそれ
らをリテラルコード語に付加する。コピーに十分な長さ
の整合が見つかれば、即座に又は例示の具体例における
ように、コピーに関する整合がその極限の長さまで拡張
されて、コピーエンコーダ７５がコピーコード語を送り
出す準備が整うと、リテラルコード梧及びその付加され
るリテラル記号が出力バッファ７７にロード可能となる
。

第４図に示すように、圧縮されたソースデータを復元す
るため、伸長器６３は、適当な速度で又は要求に従って
圧縮データをデコーダ８２に供給する人力バッファ８１
から構成される。デコーダ８２は、リテラル論理部８３
とコピー論理部８４のためのリテラルコード語とコピー
コード語を、それぞれ交互に解読する。リテラルコード
語がデコーダ８２によって解読される時、リテラル論理
部８３は、解読されるリテラルの長さＸｔ　に応答して
、次のＸ、記号４直接ＦＩＦＯ出力バツフア８５に順次
ロードする。

一方、コピーコード語が解読される時には、コピー論理
部８４が変位ｙと長さＸｃ　に応答して、予め復元され
た記号のストリングを出力バッファ８５に順次コピーし
バッファ８５における予め復元されたｙ番目の記号から
始めて、そこから漸次新しく伸長されるｘＣの記号スト
リングまでコピーを拡張する。

Ｃ９更に、探索木に関して 好都合なことに、探索木７３は、そのキーの“デジット
”に従って、任意の時間において、人力バッファ７１の
探索窓での記号位置ｌ〜ｉ　−ｗ内にあるソース記号に
よって規定されるその“葉”に分岐する。たとえば、第
５図に示す冗長性の高い英語テキストに焦点を合わせる
と、人力バッファ７１の探索窓での記号位置の範囲内に
ある、テキストの任意の部分の個々の文字に従って分岐
する探索木７３は、圧縮ソース記号を探索窓に送り込み
、それを通し、そこから出すＦＩＦＯシフトの埋め合わ
せのため、動作時にポインタが更新される場合には再発
生記号及び記号ストリングの先に発生した位置を明らか
にするのに必要なポインタを提供するのによく適合する
。記号は、前述のようにリテラルコード語とコピーコー
ド語のいずれに関連するか判定された直後に、記号位置
ｌを介して窓にシフトインされ、一方、古い記号は、そ
れによって占められたスペースがより新しく圧縮された
記号及び記号ス）　ポインタを記憶するのに必要になる
と、記号位１１−Ｗを介して窓からシフトアウトされる
。ソース記号と固定長の探索窓との相対移動は、探索窓
に対する記号の物理的シフトとして最も視覚化しやすい
が、それはソフトウェアの場合、ソフトウェアの制御下
でソース記号に対してシフトされるポインタを用いるこ
とによって実現可能であることを理解すべきである。

第６Ａ図〜第６Ｅ図を参照すると、）　！Ｊ−（Ｔｒｅ
ｅ）の木データ構造が（１９７５年のアジソン・ウニズ
リ−社（＾ｄｄ＋５ｏｎ−Ｗｅｓｌｅｙ）、コンピュー
タプログラミングの技術（Ｔｈｅ＾已ｏｆ　Ｃｏｍｐｕ
ｔｅｒ　Ｐｒｏｇｒａｍｍ＋ｎｇ）　　第３巻、第２版
の４８１頁におけるデイ−・イー・クヌース（Ｄ、　Ｅ
、　Ｋｎｕｔｈ）　　による二分頚と探索（Ｓｏｒｔｉ
ｎｇａｎｄ　Ｓｅａｒｃｈｉｎｇ）参照のこと）探索木
７３の基本的な機能要件を満たすことが明らかになる。

周知のように、記号ストリングは、木の根からストリン
グの各順次毎に更にレベル１つ分ずつ下降することによ
って、トリー（Ｔｒｉｅ）の木に挿入される。従って、
木の１番目のレベルは、任意の記号ス）　ポインタにお
ける」番目の記号に従って分岐し、その結果、木は、本
質的に、探索窓内にふける全ての記号及び記号ス）　＋
Ｊソング位！を示すのに必要なポインタの全てを含むこ
とになる。ただし、記号ストリングをトリー（Ｔｒｉｅ
）の木に挿入するには、かなりの量の処理時間が必要に
なる（最悪の場合、ｎ個の記号からなるファイルに関す
る挿入時間は、０　（ｄ−ｎ）　　になるが、ここでｄ
は最大許容可能コピー長である）。更に、こうしたデー
タ構造のサイズは、Ｏ（ｄ−ｗ）にまで増大するが、こ
こでＷは探索窓のサイズであり、従って、単純な）　！
Ｊ　−（Ｔｒｉｅ）の木のデータ構造は、本発明のほと
んどの実際の用途には大きすぎる。

第７Ａ図〜第７Ｅ図を参照すると、パトリシア（ＰＡＴ
ＨＩＣＩＡ）の木（１９６８年の米国計算機学会の定期
刊行物（Ｊｏｕｒｎａｌ　ｏｆ　ｔｈｅ　Ａｓ５ｏｃｉ
ａｔｉｏｎ　ｆｏｒ　Ｃｏｍｐｕｔｉｎｇ！Ｊａｃｈｉ
ｎｅｒｙ）の第１５巻第４号５１３〜５３４頁に右ける
デイ−・アール・モリソン（口、ＲＭｏｒｒｉｓｏｎ）
による“パトリシア：英数字でコード化された情報を検
索するための実用アルゴリズム（ＰＡＴＨＩＣＩＡ−Ｐ
ｒａｃｔ＋ｃａｌ　Ａｌｇｏｒｉｔｈｍ　ｔｏ　Ｒｅｔ
ｒｉｅｖｅ　Ｉｎｆｏｒ＋＋＋ａｔｉｏｎＣｏｄｅｄ　
ｉｎ　ＡＩｐｈａｎｕｍｅｒ＋ｃ）”参照のこと）は、
トリー（Ｔｒｉｅ）の木に対する比較的コンパクトな代
替案である。周知のように、バトリシア（ＰＡＴＲＩＣ
ＩＡ）の木の内部ノードは、それが牽引を作成中のファ
イルに対するポインタを含んでおり、従って、こうした
木データ構造は、探索径路の技毎に単一の“デジット”
又は記号を含みさえすればよく、このためト！Ｊ−（Ｔ
ｒｉｅ）の木（すなわち、子孫が、１つしかないもの）
の余分な内部ノードが排除される。

たとえば、探索木７３（第３図）がバ）　ＩＪシア（Ｐ
ＡＴＲＩＣＩＡ）の木であれば、第７Ｂ図〜第７Ｅ図に
弧で挿入して表示された記号は、木の分岐に影響しない
ので、明らかにデータ構造へ含める必要はない。ただし
、それらが納まっている弧に関するノードの位置ポイン
タとレベルポインタの対により、識別される探索窓記号
位置内における記号を走査することによって回復するこ
とができ、従って、それらは該弧で有効に表示される。

古典的なパトリシア（ＰＡＴＨＩＣＩＡ）の木は、各探
索の終了時に、ファイルのアクセス及び比較を１回行う
だけでよい。しかし、パトリシア（ＰＡＴＨＩＣＩＡ）
スタイルの探索木７３が本発明の実施に用いられる場合
、一般に、木への記号ストリングの挿入時に横断される
弧で表示された記号を走査するのが望ましく、これによ
って、木を下降していく間に、該弧が導くノード内の位
置ポインタが更新可能になる。普通、探索木７３に挿入
される“デジット”は、バイト（たとえば、８ビツトの
文字）であり、２５６はどの大きさの分岐要素を提供す
ることができる。しかしながら、通例、ノードはそれほ
ど多くの子孫を有しておらず、従って、その探索径路の
分岐を規定するため、木７３の７−ド内に確保しなけれ
ばぼらないスペース量は、その弧のハツシング（ｈａｓ
ｔ＋＋ｎｇ）　　によって、減少させることができる。

比較的カットオフの深さが浅い探索木を用いるにもかか
わらず、十分な圧縮を行うことができる場合、パトリン
ア（ＰＡＴＲＩＣＩＡ）の木は、探索木７３にとって受
入れることのできる選択である。前に指摘したように、
こうした木は、適度にコンパクトなデータ構造によって
規定されるが、それはトリー（７ｒｉｅ）の木とほぼ同
じ挿入処理（すなわち、根に戻ってそれから木を降下し
ていく）　に依存している。従って、より長い記号スト
リングをパトリシア（ＰＡＴＨＩＣＩＡ）の木に挿入す
るのに必要とされる時間は、最大許容可能コピー長が比
較的短い（やはり、最悪の場合には、ｎ個の記号からな
るファイルに関する挿入時間は、０（ｄ−ｎ）となるが
、ここで木の必要とされる深さｄは最大許容可能コピー
長に等しい）具体例に対して該タイプの木を実際に適用
するのを制限する傾向がある。

幸いなことに、第８図に示す少し修正を施された接尾木
は、０（ｎ）　　時間内に、探索木７３（第３図）に記
号ストリングを挿入できることが必要な、又は望ましい
具体例に対して利用することが可能である。１９７６年
の米国計算機学会定期刊行物（Ｊｏｕｒｎａｌｏｆ　ｔ
ｈｅ　Ａｓ５ｏｃｉａｔｉｏｎ　ｆｏｒ　Ｃｏｍｐｕｔ
ｉｎｇ　Ｍａｃｈｉｎｅｒｙ）の第２８巻第１号２６２
〜２７２頁における“スペース節約型接尾木アルゴリズ
ム（＾Ｓｐａｃｅ−Ｅｃｏｎｏｍ　ｉｃａ　ｌ５ｕｆｆ
＋ｘ　Ｔｒｅｅ　Ａ１ｇｏｒｉｔｈｍ’）　　にイー・
エム・マフフレイト（ε、Ｒ１１ＭｃＣｒｅｉｇｈｔ）
　　によって説明されているように、接尾木の内部ノー
ドは、第８図にダッシュラインで示すように、それらの
接尾部に関するノードにそれらを連係させるポインタを
含んでいる。更に詳述すれば、第９図に示す一般化した
接尾木を参照すると、ストリングａＸのような接尾部を
拡張した記号ストリングに関する内部ノードは、Ｘのよ
うなその接尾部の拡張を表したノードに対するポインタ
を含んでいることが分かる。従って、探索窓にふける位
置ｐから開始する接尾部を拡張した記号ストリングが、
接尾スタイルの探常水７３のレベルｌに挿入されたばか
りの場合、接尾部を拡張した記号ス）　ＩＪソング表す
ノード（たとえば、位置ｐから開始するストリング）か
らその接尾部の拡張に関するノード（たとえば、位置ｐ
＋１から開始するス）　ＩＪソングに至る近接接尾部ポ
インタが常に存在するので、位置ｐ＋１から開始するス
トリングは、その根に戻ることな（、探索木に挿入可能
になる。

第９図について更にもう少し詳しく考察してみると、ａ
ＸＹからなるストリングに関する前の反復時に、整合が
見つけられた状況を表していることが分かるが、ここで
、ａは単一の記号であり、Ｘ及びＹは１つ以上の記号か
らなるストリングであり、ｂはＹに続く最初の整合のと
られていない記号である。時々生じるそれ以外の複雑化
の要因について説明するため、αは、ス）　ＩＪソング
ＸＹｂに関する探索径路とストリングａ　ＸＹＺに関す
る探索径路との間の弁別を行うため、木に、付加された
ばかりの新しい内部ノードであり、この場合、Ｚはｂか
ら始まらないものと仮定した。該仮定を考慮すると、ノ
ードαに関する接尾部連係の計算を行う必要がまだある
ということが理解できるであろう。

マツクレイ）　（！ＪｃＣｒｅｉｇｈｔ）　　の上記教
示に従って、まずノードα（まだ接尾部の連係が行われ
ていない）から木を登り（すなわちその根に向かって）
、次に高位のノードβに達することによって、次のスト
リングＸＹｂを木に挿入し、その結果、ストリングａＸ
ＹからＹを除去することが可能になる。

ノードβは、必然的にストリングａＸを表すことになり
、従って、その接尾部ポインタが規定によりストリング
ａＸの接尾部Ｘを表すノードＴに続くことになる。Ｘを
表すノードを見つけると、ここで木を降下して、まずス
）　ＩＪソングを“再走査”し、次に、更に木を降下し
て“走査”を行い、サブストリングｘＹで開始する記号
ストリングについて、現存する最長の整合を見つけるこ
とにより、ここで接尾部を拡張した記号ストリングＸＹ
ｂを挿入することが可能となる。その接尾部を拡張した
ＸＹｂに関して整合が存在する場合、“再走査゛はサブ
ストリングＸＹに対応する１ノードδで終了することに
なる。一方、接尾部を拡張した記号ストリングＸＹｂに
対する整合がなければ、Ｙで始まるストＩＪングを表す
弧を開いて、それを引き継ぐ弧によって表されるＹを伴
う新しいノードδを挿入することによって、ノードδが
生成されることになる。どちらの場合にも、ノードδは
記号すに分岐し、前の記号ストリングａＸＹに関する接
尾部ＸＹを表す。従って、それに対するポインタがノー
ドαの接尾部の連係フィールドに人力され、これによっ
て、最も新しく生成されたものを除くことになる可能性
はあるが、接尾部水内にある全ての内部ノードが接尾部
で連係する不変量が復元する。

幸いにも、上述の処理時に、“再走査”される弧で表さ
れた記号ストリング（たとえば、ストリングＹ）は、木
に挿入されるストリングの対応する記号と対照する必要
はないというのは、この２組の記号の一致は、前の反復
時に確証されているためである（すなわち、記号ス）　
ＩＪソングＸＹの接尾部ＸＹが木に挿入されていた時）
。その最も新しい接尾部の拡張だけしか、探索木の内容
と対照する必要がないので、この先行知識によって、は
ぼ線形時間で接尾スタイルの木７３に記号ス）　ＩＪソ
ング挿入することが可能になる。

本発明の特徴の１つによれば、マツフレイト（ＭｃＣｒ
ｅｉｇｈｔ）によって説明された上記接尾スタイルの探
索木のデータ構造に対し、そのサイズに制限を加え、そ
の保全に必要な時間を短縮するため、いくつかの重要な
修正が加えられる。前に指摘したように、木の葉は、Ｆ
ＩＦＯに基づいて順次シフトされ、バッファ７１　（第
３図）の探索窓の記号位置１〜ＩＷに送り込まれて、こ
れを通ってそこから送り出され、これにより、固定長の
探索窓内にソースデータの最も新しく圧縮された部分を
保つための規則正しい手順が与えられる。更に、“息子
（ｓｏｎ）　　カウント”フィールドが、削除すべきノ
ードを識別するために木の内部ノードに含まれる。

明らかなことだが、内部ノードは、代替探索径路間にお
ける弁別に必要とされる場合に限り、木に付加される。

残っている“息子“が１つしかない“親（ｐａｒｅｎｔ
）ノード”は、探索径路の弁別を行えない。従って、任
意の７−ドの息子カウントフィールドの値が１にまで下
がると、かならずそのノードは削除され、その唯−残っ
ている、すなわち“孤児となった（ｏｒｐｈａｎｅｄ）
”息子は、次に高レベルの、すなわち“祖父（ｇｒａｎ
ｄρａｒｅｎｔ）　”ノードからの弧で表された記号又
はストリングと組合わされる。

更にもう１つ、既知接尾スタイルの探索木から逸脱して
いる点は、必ずしも更新を行うために木の根に戻ること
を必要とせずに、接尾部木の内部ノードにおける位置ポ
インタの更新が行えるようになっているとうことである
。更に詳述すると、本発明のより細目にわたる特徴の１
つに従って、接尾部木の内部メートにおけるポインタの
更新を行うため、“バーコレーテイング更新″を用い、
これによって木の接尾部の葉（すなわち、最近圧縮され
たソース記号）が探索窓を通ってンフトされる際、それ
らのポインタをその葉に対し維持することが可能になる
。そのため、木の各内部ノードは、前述の位置及びレベ
ルポインタ、接尾部ポインタ及び息子カウントフィール
ドに加え、単一の“更新″ビットを備えている。更に、
木に新しい記号ス）　ポインタが挿入される時には必ず
ストリングの最初の記号すなわち、先行記号の走査窓に
おける現在位置が、挿入されたばかりの記号ストリング
の新しい葉に関する親ノードまで上方へ移行し、これに
より、（１）最も新しく発生した所定の記号ストリング
の先行記号の現在位置が、その発生と探索窓内にまだ存
在する可能性のある同じ記号ストリングの以前の発生と
の区別を行うため、その葉の親ノードの位置フィールド
に書き込まれ、（２）新しい葉の親ノードに関する更新
ビットの状態が反転されることになる。親ノードの更新
ビットが、“偽″の状態から“真”の状態にスイッチさ
れると、それ以上位置の更新は波及しない。しかし、新
しい葉の親ノードの更新ビットが、“真”の状態から“
偽”の状態にスイッチされると、新しく挿入され、記号
ストリン、グの先行記号に関する探索窓での現在の位置
は、木の上方へ移り（その根に向かって戻る）、更新が
“偽”の更新ビットを有する高レベルのノードに達する
まで、記号ストリングに関する探索径路上の全てのノー
ドの位置フィールドを更新する。この更新処理は更新の
伝播がその更新ビットが“偽゛の状態にある時に、更新
を受ける第１のノード（最低レベルのノード）で終了す
るので、“バーコレーテイング更新”と呼ばれる。こう
した更新終了ノードの位置フィールドは、新しく挿入さ
れた記号ストリングの先行記号を指示するために更新さ
れ、該ノードの更新ビットが、“真”の状態にスイッチ
されて、これによってそれが受ける次の更新をその親ノ
ードに伝播するように、そのノードの条件付けが行われ
る。最後に新しく挿入される記号ス）ポインタの最後の
記号が探索窓に送り込まれ、これにより探索窓が満杯の
場合には、探索木７３（第３図）の最古の葉が削除され
ることになる（すなわち、探索窓から送り出される）。

前に指摘したように、接尾スタイルの探索木７３から葉
を削除すると、息子１人しか残されない親ノードの削除
がトリガーされるのが望ましい。そのため、こうした木
から削除される親ノードの位置は、やはり上述の処理に
従って、多かれ少なかれ、木の根に向かって上方へ移行
する（すなわち、削除されるノードの位置ポインタが、
必ず次に高レベルのノードの位置フィールドに書き込ま
れるが、高レベルのノードの更新ビットの状態に従って
、条件付きでしか、そこから上方へは伝播しない）。基
本的な区別は、削除されたノードからのバーコレーテイ
ング更新の際、こうした更新を受信する高レベルのノー
ドのそれぞれに対し、現存する位置ポインタが、提案さ
れた更新の位置ポインタと対照され、これによって、そ
の２つのポインタのうち最も新しい方が、（１）更新を
受けるノードに対する位置ポインタとして、及び（２）
更新がそこまで及ぶことを認められる場合には、次に高
いレベルのノードに対する提案された更新として選択可
能になる。

最悪の場合、新しく挿入された記号ス）　ＩＪングの接
尾部の葉、すなわち、最後の記号に関する親ノードから
木の根までの経路における全てのノードが、“真”の更
新ビットを有し、このため更新が木の根に至るまで全面
的に広まる可能性がある。

しかしながら、上述のパーコレーテイング更新処理は、
それを実施するのに必要とされる時間が、探索木７３０
葉の全てについて償却される場合には、記号又は文字毎
に一定の時間量で実施するのが可能であることが分かる
。更に一層重要なことだが、この処理は、探索木７３の
内部ノードの全てに妥当な位置ポインタを保全するのに
有効であり、これによりノードはそれらが表わしている
記号を含む探索窓の記号位置に対し、正確な参照符が付
与されることになるのが分かる。

探索木７３の更に別の実施についても思いつくことにな
る。たとえば、トリー（Ｔｒｉｅ）の木と、パトリシア
（ＰＡＴＨＩＣＩＡ）の木に関する前述の考察から明ら
かなように、接尾部水に備えたパーコレーテイング更新
は、各記号ストリングの挿入毎に、木の根に戻りさえす
れば、回避することができる。その場合、木の内部ノー
ドは更新ビットが不要であり、ノードが削除される時、
更新を行う必要がない。同様に、接尾部の連係は、該タ
スクを実施するのに必要な平均時間を大幅に短縮するが
、こうした探索木への記号ストリングの挿入時に、接尾
部ノードの位置を見つけるのに不可欠ではない。

それらがなければ、所定のストリングに対する接尾部の
葉から開始しそれから接尾部のノードに達するまで、親
ポインタに従って木の根に向かって戻ることが可能であ
る。明らかなことだが、所定の記号ストリングに関する
接尾部の葉は、探索窓における所定の記号位置ｐを起点
とする整合を備えることが分かっている、ストリングａ
ＸＹ（第８図）のようなストリング以後の最初に整合の
とられていない記号であるため、簡単に位置が求められ
る。更に、こうした記号ストリングに関する接尾部のノ
ードは、親ポインタを用いて、接尾部の葉から木の根に
向かって、上方へ挿入されるストリングの長さによって
決まる適当な数のレベルだけ移動させることによって、
識別することができ、これによって各記号ス）ＩＪソン
グ挿入毎に、木の根まで戻らなくても済むという利点が
保たれる（明らかなことかだ、ハツシュテーブルの検索
は、通常、接尾部の葉に向かってレベル毎に下降してい
く必要があるため、探索木を移動するコス。

トは均一ではない）。しかし、最大許容可能コピー長が
長い場合には、この接尾部ノードに基づく代替ストリン
グ挿入処理は、最悪の場合、望ましくないほど遅くなる
。同様に探索木７３の一部が深い場合には、全ての更新
が木の根にまで及ばねばならない時、極度に長い平均更
新時間が必要になる。従って、通常は接尾部連係及びパ
ーコレーテイング更新が望ましい。

Ｄ、拡張された具体例 ■、　統計的感応コード化 明らかなことだが、固定長のリテラルコード語及びコピ
ーコード語の有効利用には、ソースデータが分解される
ことになるリテラル及びコピーの平均長に対し、該コー
ド語の長さを慎重にバランスさせる必要がある。探索窓
のサイズが増すことは、見つけることができる整合する
記号ス）ＩＪソング平均長を増すことにつながるが、探
索窓内において個々の記号位置を指定するのに必要な位
置ポインタのサイズも増す。より新しい記号位置を表示
するポインタが、より利用されることになりやすいので
、これらのより大きなポインタは、それらが無差別に用
いられる場合、得られる圧縮をおさえることが可能であ
る。更に、リテラル及びコピーが短くなる方が、リテラ
ル及びコピーが長くなるより可能性が高い。従って、圧
縮を増すことが所望の場合には、統計的感応による可変
長のリテラルコード語及びコピーコード語を利用して、
本発明を実施するのが有効である。

こうした統計的感応による可変長時間のコード語を供給
するために、様々な技術を利用することができる。たと
えば、コード化論理部７４り第３図）に報告される、リ
テラル長及びコピー長と、変位のハフマン（ｌｕｆｆｍ
ａｎ）適応コード化又は演算コード化を利用することが
できる。しかしながら、こうしたコード化は、一般に遅
く、圧縮器１２　（第３図）の固定長の探索窓が、すで
にそれをソースデータに対し適合させているので、それ
は単に二次的な適応の利点しか生じない。更にもう１つ
のアプローチは、各種長さのコピー及び変位のコード化
だけでなく、各種長さのリテラルのコード化に対しても
、ビット長の異なる拡張された一群の独特のコード語を
予め割当てることである。その場合、短いリテラルと短
い近接コピーは、一般にそれらに比較的短いコード語を
割当てることによってコード化され、一方、より長いリ
テラル及びより長いコピーとより遠くに変位したコピー
の両方又は一方は、それらにより長いコード語を割当て
ることによってコード化され、これによって、用いろれ
るコード語の長さが平均的なソースデータが分解される
リテラル成分とコピー成分の頻度分布の所定のモデルに
合うよう調整される。長さが４ビツトから３０ビツト　
（それらのサイズ参照のこと）にわたる、代表的な一群
の互いに区別可能なコード！！（それらの導入インジケ
ータのピットン−ケンス参照のこと）については、それ
らが割当てられるコード化タスク（それらの名称と１６
にの長さの探索窓の様々な変位範囲内で、それらによっ
て扱われるストリング長を参照のこと）、及びそれらが
割当てられるリテラルとコピーにこれらのコード語によ
って独特なコード化を施すことができるようにするレイ
アウト　（コード語のレイアウト参照のこと）と共に、
以下に述べる。

（以下、余白） ただし、本発明のより重要な特徴の１つに従うと、統計
的感応による可変長のリテラルコード語及びコピーコー
ド語を生成するより簡単で有効な技術の１つによって、
リテラルの長さとコピーの長さ及び変位を表すく開始、
ステップ、停止〉の単項コードの線形数列を供給する。

第１０図に９１で示すような単項符号器が得られる。明
らかに、コード化規則又は方法は、単項符号器９Ｉの前
に配置されるコード化論理部９２によって強化されるが
、それ以外の点では、第１０図に示す圧縮器は、第３図
に示す圧縮器と十分に似ており、同様の部分の識別を行
うのに同様の参照番号を用いることが可能である。

定義の要素として、く開始、ステップ、停止〉の単項コ
ードは、リテラルの長さとコピーの長さ又は変位がデジ
タル方式で記録されており、値のフィールド自体が後続
するフィールドのビット長を指定する単項コードで構成
される。次に値のフィールドは、指定の“開始”数量上
のビットと、指定の“停止”数量下のビットを含むこと
を強要される。更に、値のフィールドのビット長は、指
定の“ステップ”パラメータの線形関数としてインクリ
メンタルに変化し、可変長コードの線形数列を定義する
。従って、こうしたコードのｎ番目のコードエ吾は、（
開始＋（ｎ−１）・ステップ）のサイズの値フィールド
が後続する単一の“０°　（すなわち、単項フィールド
長インジケータ）によって終了するｎ−１個の“１″か
ら構成される。整数が、これらの異なるサイズのコード
語に順次割付けられていく。たとえば、＜３．２．９＞
の単項コードの異なる長さの４つのコード語が、以下の
ように、整数カウント数を写像する。

コード語　　　　　　範囲 ＯＸＸＸ　　　　　　　　０−７ １０ＸＸＸＸ　　　　　　　　８−３９１１０ＸＸＸＸ
ＸＸＸ　　　　　　４Ｏ−１６７１１１ｘｘｘｘｘｎ＋
ｘｘ　　−１６８−６７９明らかに、値フィールドのビ
ット長が、所定の“停止”サイズに等しい場合には、単
項フィールド長インジケータに対する単一の“０″ター
ミネータは省略することができる。テーブルの探索手順
が単項コードをコード化するための実行可能な代替案で
あることを理解すべきであるが、参考まで；二、本書に
組込んだ付ｉｔＢには、単項コードを生成するための単
純化擬似コードによる計算手順が示されている。更に、
参考までに、付録Ｃも組込まれているが、それは、上に
概略を述べた論理規則に従ってソースデータを分解する
ことにより識別されるリテラルとコピーに対し、単項コ
ードを加えるテキスト置換データ圧縮システムに関する
セダー（Ｃｅｄａｒ）　　ソースコードのりスティング
であるためである。しかしながら、単項コード化は、圧
縮可能なコヒーレンシー（ｃｏｈｅｒｅｎｃｙ）　が存
在する長さ（及び／又は圧縮不能な非コヒーレンシーが
存在する長さ）を捕捉し、テキスト置換スタイルのデー
タ圧縮システムの場合には、冗長性を見出すことができ
る位置を捕捉するための、様々なタイプのラン長又はス
トリング長に依存するデータ圧縮に利用できることを理
解すべきである。更により一般的には、単項コード化は
、ラン長、コピー長、コピー変位、リテラル長等を含む
、数値の可変長コード化をもたらすデジタルデータ圧縮
システムに利用することが可能である。

明らかなことだが、さまざまな要素が上述のコード化規
則に従って、圧縮されるデータのリテラル長と、コピー
長及び変位をコード化するためのく開始、ステップ、停
止〉単項コードの選択に影響する可能性がある。たとえ
ば、第１１図に示す単純化有限状態機械（ＦＳＭ）によ
って表されているようにコピー長のコード化に＜２．１
．１０＞の単項コードを利用し、これによって、最大許
容可能コピー長を２０４４の記号に制限することができ
る。

コピー長がゼロの場合、リテラルの信号を出す。

その長さは、さらに＜０．１．５＞の単項コードを用い
てコード化され、その結果、最大許容可能リテラル長は
、６３の信号になる。一方、コピー長が非ゼロであれば
、＜１０．　２．１４＞の単項コードでコピーの変位を
コード化し、２１，５０４の記号位置からなる広い探索
窓内のどこかを起点とするコピーを指摘することができ
る。実際には、単項数列における無駄な状態を回避する
ため、最大コピー長及びリテラル長が選択されるのが普
通である。

時には、同様の技術がコピー変位の単項コード化におけ
る無駄な状態を回避するためにも利用される。

無駄な状態を回避するため、用いられる単項コードに対
し改良を施すことも可能である（不図示）。

たとえば、ソースデータをリテラルとコピーに分解する
ための前述の規則は、最大許容可能リテラル長未満のリ
テラルがその直後に決して、長さが２のもう１つのリテ
ラルもコピーも続かないことを保証する。従って、こう
した非最大長のリテラルがコード化される時には、必ず
、こうしたリテラルに続かねばならないコピーのコード
化のため、（２，１，１０＞のコードは、２つだけシフ
トダウンし、その結果、ゼロのコード値は、３のコピー
長を表し、■のコード値は、４のコピー長を表し・・・
といった形になるようにすることができる。

開始時における値に属するもう１つの改良は、探索窓が
充填されていく際に、段階的にコピー変位のコード化を
取入れることである。たとえば、こうした段階的利用は
コピー変位に対しく１０−ｘ。

２、ｌ４−Ｘ）の単項コードを用いることによって実現
することができるが、この場合、Ｘは当初、ｌＯに等し
くなるようにセットされており、次に変位ポインタが以
前に圧縮された記号を含んでいる全ての窓での位置を識
別できることを必要とされる時、その必要に従って、ゼ
ロまでデクリメントされる。

コピー変位のコード化における無駄な状態を回避するた
めに利用できる更にもう１つの技術は、そのフィールド
が表わさねばならない様々な変位値のそれぞれを、一義
的に識別するため一群をなす“疎（ｓｐａｒｓｅ）“コ
ード語を提供するのに丁度の大きさになるまで、その単
項数列における最大のフィールドを収縮させることであ
る。従って、最大の、すなわち“停止（ｓｔｏｐ）″サ
イズのフィールドの＜１０−　ｘ、　　２．１４−　ｘ
　）の単項コードでコード化される値が合計Ｖ個ある場
合、そのフィールドに関する“疎コード化”により、Ｖ
個の値のうち小さい方は、ＬＩＯｇ２ｖＪのビットでコ
ード化され、その大きい方は、ｒｌｏｇ２ｖ１のビット
でコード化される。明らかなことだが、こうした疎コー
ド化は、Ｖ個の値のそれぞれをコード化するために、１
４−　Ｘのビットを用いる必要をなくし、この結果、最
大変位値を備えたコピーコード語のビットサイズを縮小
することになる。

この疎コード化技術をさらに説明するため、６つの値の
うち１つに関するコード化について考える。その値をコ
ード化するのに３ビツトのフィールドが用いられる場合
には、可能性のある８つの状態のうち２つが、無駄な２
状態になる。しかし下記のように、値０と１は２ビツト
でコード化し、値Ｃ２，，５）は３ビツトでコード化す
ると、無駄な状態がなくなる。

値　　　　　　コード １旧 ３　　　　　１旧 典型的な疎コード化手順及び解読手順について以下に示
す。

εｎｃｏｄｅ：　ＰＲＯＣ［ｖａｌｕｅ、ｎＦｒｅｅＶ
ａｌｕｅｓ、ｎＢｉｔｓ：ＣＡＲＤＩＮＡＬ］＝　（Ｉ
Ｆ　　ｖａｌｕｅ＜ｎＦｒｅｅＶａｌｕｅｓ　　ＴＨＥ
Ｎ　　０ｕｔｐｕｔ［Ｖａｌｕｅ、ｎＢｉｔｓ−１］ε
ＬＳＥ　０ｕｔｐｕｔ［ｖａｌｕｅｓｎＦｒｅｅＶａｌ
ｕｅｓ、ｎＢｉｔｓコ；）； Ｄｅｃｏｄｅ：　ＰＲＤＣ［ｎＦｒｅｅＶａｌｕｅｓ、
ｎＢｉｔｓ：ＣＡＲＤＩＮＡＬ］ＲＥＴＵＲＮＳ［Ｖａ
ｌｕｅ：ＣＡＲＤＩＮＡＬ］＝　（ ＩＦ　ｎＦｒｅｅＶａｌｕｅｓ＝ＯＴ）ＩＥＮ　ｖａｌ
ｕｅｓＩｎｐｕｔ［ｎＢ＋ｔｓｌεＬＳＥ　（ ｖａｌｕｅｓ−１ｎｐｕｔ［ｎＢｉｔｓ−１］　；ＩＦ
　ｖａｌｕｅ＞＝ｎＦｒｅｅＶａｌｕｅｓ　ＴＨＥＮ　
ｖａｌｕｅ＋ｖａｌｕｅ＋ｖａｌｕｅ−ｎＦｒｅｅＶａ
ｌｕｅｓ＋Ｉｎｐｕｔ［１］　；）； ２、高速の圧縮器 前述の圧縮器は、伸長器６３（第５図）　のような記憶
容量を制限した伸長器によって、比較的迅速に伸長でき
るように、圧縮データを書式作成する。

従って、それらは最終ユーザに配布し、彼等によって伸
長されるように、フロッピーデスクへの圧縮形態でソフ
トウェアの大量放出を行うことが所望される場合のよう
に、圧縮速度が設計を単純化したり、伸長器の性能を最
適化することほど重要でない用途には、とりわけよく適
合する。さらに、前述の圧縮器は、普通の適度に簡単な
ハードウェアの実現にむいている。たとえば、ＶＳＬ　
Ｉによるハードウェアの具体例では、探索木は、排除さ
れ、最長の整合を求めるように探索窓内の多数の文字に
対し同時に作用する幾つかのコンパレータに置き換えら
れる。都合のよいことに、探索窓に含まれている記号は
、半導体のメモリーチップに記憶されるので、最長の適
合を求める際、外部メモリーを参照する必要がない。部
分的には外部メモリーを参照する必要がないため、この
種の圧縮器は極めて高速度で働き、広範な種々のデータ
に対し優れた圧縮を行うことができる。さらに、それら
は単一のチップに納まるため、汎用計算機能を用いずに
、“独立（ｓｔａｎｄ　ａ、Ｉｏｎｅ）　　”データ圧
縮機能が望まれる用途には適している。

しかしながら、ファイルが圧縮した形で得られねばなら
ない場合のように、より高速のソフトウェア圧縮器が望
ましい別の状況もある。このため、本発明の更にもう１
つの特徴に従って、本発明の上述の固定長のコード語と
単項コード化された可変長のコード語の具体例による圧
縮速度は、先行コピーの最初の記号によって、又は、前
にリテラルとして圧縮データストリームに挿入された記
号によって画定される境界上からコピーが開始するよう
に制限することによって大幅に増大させることが可能で
ある。前述の圧縮器におけるように、探索窓内の各記号
毎に、１つの葉を探索木７３（第３図）　に備えている
のではなく、本発明のこれらのより高速の具体例は、各
コピーコード語及び各リテラルコード語毎に、１つの葉
しか探索木７３に備えていない。これは、該木７３を探
索し、更新するのに必要な計算を減少させ、これによっ
て、平均的データの圧縮速度を大幅に増すことになる。

前のコピーの第２の、すなわち、後続の記号を起点とす
る整合は無視されるので、従って“得られる最長の整合
″°は、探索窓内のどの場所においても最長の整合かも
しれないし、そうでないかもしれない。従って、このア
プローチによって上昇する圧縮速度は、システムがソー
スデータの変化に順応する速度を低下させるという犠牲
を払って得られることになるのは明らかである。さらに
、明らかになる理由によって、これらの、より高速の圧
縮器のための相補形（ｃｏｍｐｌｅｍｅｎｔａｒｙ）　
伸長器は、幾分遅くなり、より多くの記憶を必要とする
。

全てのコピーが先行コピー又はリテラルを起点とするよ
うに制限する利点の１つは、再発生する記号ストリング
の前の前の発生位置を明らかにする位置ポインタは、放
出された以前のｙ番目のコード語又はリテラル文字の始
めを識別できさえすればよいため、圧縮することができ
るということである。たとえば、“圧縮変位”は、次の
ように実現することができる：まず、圧縮器の人力バッ
ファにポインタを記憶するために、窓のサイズに等しい
長さの記憶素子のアレイが設けられる。このアレイの各
素子は、圧縮器から送り出されるコピーコード語又はリ
テラル文字の異なる１つを示し、従って、探索木７３に
おける葉とこのアレイにおける素子との間には、１対１
の対応が存在しており、木の各内部ノードは、その派生
する葉の１つに対応したアレイの素子を識別する。次に
整合のとられた記号ストリング（すなわち、コピーが取
って代わろうとしている記号ストリング）の葉に対応し
たアレイ素子と、最長の整合が見出された葉、すなわち
、内部弧に対応したアレイ素子の間におけるアレイ素子
の数によって、コピー変位が測定される。すなわち、前
の具体例と同じように、コピー変位は、“固定長の窓”
において測定されるが、再発生する記号ス）　ＩＪソン
グ以前の発生に関する先行記号の文字バッファにおける
位置は、“探索窓”の記号位置に直接アドレス指定する
ことによってではなく、このポインタのアレイを“間接
的に”詳しく検討することによって求められる。従って
、参照ポインタアレイのサイズは固定されているが、探
索窓の長さは最近圧縮されたデータの組成に従って伸長
したり、収縮したりする可能性がある。コピー長は、や
はり記号で測定されるので、コピー長の測定及びコード
化についての先行する説明は、これらの修正具体例にも
当てはまる。参考までに、本書に組み込んだ付録りは、
圧縮変位と単項コード化の組合せによる上述の圧縮規則
に基づく圧縮システムに関する、セダー（［ｅｄａｒ）
のソースコードのりスティングである。

各反復時に、根から始めて、該高速圧縮器の探・　常水
７３（第３図）に記号ストリングが挿入される。

ス）　ＩＪソング、現存のコード語／リテラル文字の境
界に挿入されるだけであるため、それらは、線型時間に
挿入することができる。接尾部ポインタ及び伝播更新は
不必要であり、従って、該具体例に関する探索木７３（
第３図）は、比較的シンプルなパトリシア（ＰＡＴＨＩ
ＣＩＡ　）の木（第７Ａ図〜第７ε図参照のこと）が望
ましい。しかし、該具体例の場合、パトリシア（ＰＡＴ
ＨＩＣＩＡ）スタイルの探索木７３の深さｌにおける全
ての記号について、永久ノードのアレイを生成するのが
有効である点には、注意すべきである。長さｌのコピー
は決して送り出されることがないので、探索窓が、たと
えこれらの永久ノードのそれぞれに対応した記号を常に
含んでいることができなくても、それを行うことは可能
である。探索木７３に対しこうしたノードの永久アレイ
が設けられる場合、記号ストリングは、挿入されている
ストリングの最初の記号に基づく永久ノードのアレイに
指標付けを行うことによって、木に挿入することが可能
になる。その後、挿入処理は普通ハツシュテーブルの探
索と弧比較に依存して、パトリシア（ＰＡＴＨＩＣＩＡ
）スタイルの探索木の利用に関して概略を既述したよう
に、さらに深く木を降下していく。探索木に記号ストリ
ングが挿入される間、探索木に挿入される記号ストリン
グに関する探索経路の全てのノードを通過するので、挿
入処理時に探索木を降下していく間に、それらのノード
によって表される記号に関する更新された探索窓の記号
位置をノードの位置フィールドに書き込むことができる
。

前のコピーコード語を開始する記号で、または、前のリ
テラルに含まれた記号で始めるようにコピーを開眼する
ことによって、これらの修正された圧縮器がソースデー
タの局所コヒーレンスを捕捉する能力が低下するが、そ
れは比較的控えめなピットサイズの圧縮ポインタを利用
して、比較的遠くまで戻って前に圧縮したソースデータ
に達することを可能にし、その結果より大きい探索窓を
用いて、より長い整合を行うことが実現可能になる。

これは、テキストのような自然語の構造を有するソース
データにとって好都合である。しかし、前述の制限は、
例えばソースデータが走査像を表わす場合に通常存在す
るような、極めて局所化されたコヒーレンスを大量に備
えたソースデータの圧縮には望ましくない場合もあるこ
とが分かる。

３、　追加変形例 全ての先行するコピー／リテラルの境界に比べて、より
頻繁に探索木７３（第３図）を更新するため、これらの
案に対するいくつかの変更を用いることができる。例え
ば、探索木７３に対し、長さが２の各コピーコード語に
よって表される記号の間に葉を加えることと、長さが３
のコピーコード語によって表される全ての記号ス２＋ン
グの最後の記号に後続して、探索木に葉を挿入すること
の両方または一方を行うことができる。実際のところ、
前述の圧縮器によって表される極値の中間にふいて゛、
探索木に葉を挿入するという変更（そのうちの１つにお
いては、全ての記号について、探索木に葉が人力され、
そのもう１つにおいては、各コピーコード毎に１度、各
リテラル文字毎に１度、葉が人力される）は、どれも、
この方法の一般的な枠内で実現可能である。これらのよ
り高速の圧縮システムの能力を増すためのこれらの技術
及びその他の技術を用いて、ソースデータの局所コヒー
レンスを捕捉することによって、ある程度圧縮度を増す
ことが可能になるが、その圧縮及び伸長の速度は低下す
る。さらに、ある時点で木が凍結されて更新されず、従
ってその後は探索木の静的データ構造に基づいて、コピ
ー及びリテラルとしてそれ以上のソース記号がコード化
されるが、木はコード化されたばかりのストリングにつ
いては更新されないという変更もある。その場合、圧縮
度はソースデータの非定常統計値のために低下するが、
必要の際には木のサイクリングを再開することができる
。このアプローチは最高速が必要とされる用途に用いら
れる可能性があるが、圧縮量をＭ９すことになりがちで
ある。

更に、有効な記号によって、窓が準備すなわち初期設定
され、ソースデータの最初の部分の圧縮が改善可能にな
る、前述の２つの方法に対する変更もある。これはソー
スデータが準備データと似ている場合には圧縮を改善す
る可能性があるが、ソースデータが準備データと似てい
ない場合には、少し複雑になり、圧縮を悪化させること
になる。

ス）　ＩＪソング探索木に加えられ、あるいは探索木か
ら除去される場合に関する変更以外に、ソフトウェアの
具体例に用いられるデータ構造に関する変更もある。付
録Ｃにおいて、我々は、連鎖した円形のハツシュテーブ
ルに弧が挿入される接尾部の木を用いた。明らかなこと
だが、ハードウェアの具体例において木は不要であり、
窓自体だけが圧縮方法の中心をなす。また、明ろかでは
あるが、ソフトウェアの具体例において、接尾部の木を
実現するために、他の多くの種類のハツシュテーブル、
リスト又はそれ以外のデータ構造を用いることが可能で
ある。更に、明らかなことだが、我々は、その実施が有
効でないと信じているが、接尾部の木をより単純なパト
リンア（ＰＡＴＲＩＣＩＡ）の木に置き換えることもで
きるし、あるいは、それを２進木、分類済みリスト又は
他のデータ構造に置き換えることも可能である。こうし
た変更は、付録Ｃについても可能である。こうした変更
の全ては、プログラミング技術における熟練者の能力の
範囲内にある。

更に明らかなことだが、付録Ａ、Ｃ及びＤの実現には８
ビツトの記号又は文字が用いられるが、他の記号サイズ
を利用して、同等の圧縮器を実現することが可能である
。

更に、理解できるはずだが、付録Ａ、Ｃ及びＤは、それ
らのコピーコード語が窓内で見つけられる最長の整合に
必ず当てはまるという意味において“貢欲”であるが、
それが最長の整合よりも短いコード語で表すことが可能
であれば、最長の整合よりも短い整合が時々コード化さ
れる変更を実現することは、該技術の熟練者の能力の範
囲内である。こうした変更は“賞欲な”もう片方の方法
に比べて遅くなる可能性があるが、概して少し高めの圧
縮度を達成することができる（最悪の場合でも、かなり
高い圧縮度を達成する可能性がある）。

更に、前述の２つの圧縮器は、コピーコード語とリテラ
ルコード語との選択を行い、コピーのためにどの時点で
リテラルコード語を終了すべきかを決めるための特定の
方法を用いている。明らかなことだが、他の多（の方法
が可能であり、これらのいずれかを実現することは、当
該技術における熟練者の能力の範囲内にある。

最後に、付録Ｃの具体例では、単項コードく開始、ステ
ップ、停止〉を用いて、コピー長及び変位を別個にコー
ド化するが、コピー長の単項コード化又はそれ以外のコ
ード化がすてにコ、−ド化されているコピー変位によっ
て決まる変更又はコピー変位の単項コード化又はそれ以
外のコード化がすでにコード化されているコピー長によ
って決まる変更を利用することも可能である。実際には
、コピー長とコピー変位の両方のコード化を決めるのに
単一の接頭部コードを用いることを含め、更に他の変更
も思い浮かぶことになる（上述の固定長のコード化参照
）。これらの変更の全てが、プログラミング技術におけ
る熟練者の能力の範囲内にあり、特定の選択は実現の容
易さと代表的なソースデータのサンプルの統計的特性に
よって決まることになる。

４６圧縮比の改良 全ての必要なコピーを行えるようにするのに、各記号ス
トリングの１つの例しか必要としない場合でも、圧縮デ
ータは探索窓のアドレス可能なスパン内に同一の記号ス
トリングの複数コード化例を含んでいる可能性があるた
め、上述の圧縮器による圧縮データのコード化が最善で
ある。しかし、探索木データ構造は再発生記号ス）　Ｉ
Ｊソングそれろと共通の探索経路を共用するため、スペ
ースをむだにしない。

従って、圧縮比を改良するため、パ）　ＩＪシア（ＰＡ
ＴＨＩＣＩＡ）の木（第７Ａ図〜第７Ｅ図）構造のよう
な探索木のデータ構造に直接基づいたコピーコード語を
利用してコード化を実施することが可能である。例えば
、こうした木の任意の葉で終了する整合を表すコピーコ
ード語（ＬｅａｆＣｏｐＹ）　　と、木の内部弧で終了
する整合を表すコピーコード語（ＭｏｄｅＣｏｐｙ）　
　との区別を行うため、単一ビットの接頭部（“０”ま
たは“１“）を用いることができる。

圧縮器と伸長器においては同一の探索木が構築されるが
、伸長器はそれが圧縮器から受信するコード語を用いて
、圧縮器が構築した木を複製する。

各ＬｅａｆＣｏｐｙ　：Ｉ−ド譜及び各ＮｏｄｅＣｏｐ
ｙ　Ｄ−ド梧は明らかに、それが表す記号ストリングを
指定するための２つの情報要素二ノードまたは葉と弧の
変位（パ）　ＩＪシア（ＰＡＴＲＩＣ’１Ａ））　　の
木の弧は２つ以上の記号を表す可能性があるため、変位
が必要とされる）を含んでいる。探索窓のスパン内に２
回以上現れるストリングは、単一ノードの弧として現れ
、従って、それらはそれらのコード化において冗長性の
ない〜０ｄｅＣＯｐｙとして圧縮されることを理解すべ
きである。

さらに詳述すると、ＭｏｄｅＣｏｐｙが要求される場合
、その識別接頭部には〔０・・・最大ノード番号〕の範
囲内における次の自由ノードを示すノード番号が続くが
、この場合、最大ノード番号は圧縮システムの初期設定
以後に用いられた最大の７一ド番号である。従って、弧
の変位は入力弧に関する記号数に基づいてコード化され
る。よくあることだが、人力弧に対し単一の記号しかな
ければ、その変位は長さのフィールドを抑制することに
よって推論的にコード化することができる。しかし、人
力弧が複数の記号を表す場合、整合が生じた弧に沿った
位置を示す値を記録するため、ノード番号に長さのフィ
ールドが付加される。普通、記録される値は、ちょうど
新しいノードに生じる整合については０、その親ノード
から下方へ記号１つ分変位したところで生じる整合につ
いてはｌ、親ノードから下方へ記号２つ分変位したとこ
ろで生じる整合については２・・・になる。都合のよい
ことに、ＮｏｄｅＣｏｐｙの弧変位をコード化するため
疎コードが用いられるので、このためこれらのコード語
の長さフィールドは通常わずか１または２ビツトで構成
される。

一方、ＬｅａｆＣｏｐｙが要求される場合には、その識
別接頭部の後に、整合が終了した（リテラルを意味する
ゼロの弧変位によって）親ノードから葉の弧を下降した
距離を指定するため、＜１．１．ＩＨの単項コード化長
さフィールド（こうした単項数列は、４０９４の記号の
長さまでの弧長さをコード化することができる）が続く
。非ゼロの弧変位値（すなわち、リテラルを意味しない
値）を有するＬｅａｆＣｏｐｙに関する長さフィールド
の後に、整合する記号ストＩソングの先行記号に関する
探索窓での記号位置が、できれば上述の数列＜ｔｏ−Ｌ
２，１４−×〉のような別の適合する単項数列を漸次段
階的に組み込むことによってコード化される。

都合のよいことには、リテラルはその導入ビットシーケ
ンスすなわち“フラグとして０の弧変位を有するＬｅａ
ｆＣｏｐｙを用いることによって、一義的に識別される
。それらの導入フラグのビットには、＜０．１．５＞　
のコードのようなさらにもう１つのく開始、ステップ、
停止〉の単項数列を用いて、リテラルの長さがコード化
されている長さのフィールドが後続する。コード化規則
は、最大許容可能長未満のリテラルの直後に別のリテラ
ルが続くのを禁じており、従ってこうしたリテラルの直
後にコード化されるＬｅａｆＣｏｐｙの弧変位に関する
単項コードは１つだけシフトダウンされ、１の弧変位が
従って０としてコード化され、２の変位が１としてコー
ド化され・・・といった形をとるようにすることができ
る。

ＮｏｄｅＣｏｐＹに対するノード番号は、最低使用頻度
（ＬＲＵ）選択アルゴリズムに従って取り扱い、より使
用頻度の高いノードを識別するのに必要なビット数を減
らすコード化を用いるのが望ましい場合であっても、値
〔０・・・最大ノード番号〕に関する疎コード化を用い
てコード化される。明らかなことだが、こうしたノード
の取り扱い及びコード化案は、設計者の裁量によって実
施することができる。

前に指摘したように、データを復元するためこの具体例
の場合の伸長器は、ソースデータの対応する部分の圧縮
／伸長時に、圧縮器の探索木の探索経路と同一の探索経
路を含む探索木を再構築し保全しなければならない。た
だし圧縮器とは異なり、伸長器に加えられるコード語は
各コピーの長さを判定し、即座に木に加えられるべき新
しいノードの親の位置をつきとめることができるように
する。従って、最長の適合が２つ以上の記号にまたがる
と、あるコピーが必ず選択されるように制限されている
場合、コード化方法が記号ス）　ＩＪソング木に挿入す
るのにバッジコテ−プルは必要とされない。コード化方
法に関するこの制限により、伸長器は、それが解読した
特定のＮｏｄｅＣｏｐｙコード語またはＬｅａｆＣｏｐ
ｙコード語によって示されるノードまたは弧から各折し
い葉をたらすことによって、木を再構築することができ
る。さらに解読されるのがリテラルの場合には、伸長器
はリテラル記号に関する永久深さ、すなわちレベルｌの
ノードから葉をたらすことができる（想起されるように
、永久深さｌのノードは都合のよいことに各ソース記号
毎に与えられている）。

Ｅ１代表的な機能的流れ図 前述の説明を補足するため、代表的な機能的流れ図の説
明を以下に行う。これらの図は単純化されてふり、いく
つかの具体例に特定されるものであるが、それらは本発
明をその様々な形態で実施することに関心のある人に対
して、−船釣な枠組みを提供する。可逆の、すなわち、
損失のない圧縮システムの場合、伸長器は必然的に圧縮
器を補足することになり、従って、圧縮器の機能的性能
特性は、伸長器の性能要件をかなり決定する。上述の圧
縮器には、再発生する記号ストリングの前に発生した位
置を明らかにするため、探索窓内の全ての記号に対する
直接アドレス指定を可能にするものもあるし、一方では
、探索窓内におけるいくつかの記号（すなわち、先行す
るコード語を開始する記号、又はリテラルとして前に放
出された記号）に対して、ポインタのアレイを利用しで
あるいは木構造のコード化によって、間接アドレス指定
を行うことにより、前に発生したこうした位置を明らか
にするものもある。ソースデータの圧縮及び伸長に関す
る木構造のコード化及び解読は、探索窓の内容に対する
直接又は間接アドレス指定よりも少し複雑であり、従っ
て、木構造のコード化及び解読は、下記流れ図に特徴が
示されている。

■、　整合記号ストリングの位置決定及び拡張第１２図
を参照すると、ストリーム圧縮器の全てが、それらの探
索木７３（第３図）　を保全し、再発生する記号ストリ
ングの以前の発生を識別するために、はぼ同じプロセス
を利用している。想起されるように、ファイル圧縮器は
、ソース記号をそれらに“押し付けられる”のではなく
、ファイルからソース記号を“引き出す”が、さもなけ
れば、それらは記号ストリングをそれらの探索木に挿入
し、それらのストリーム圧縮器の片一方とほぼ同じやり
方で、それら探索木を保全する。本発明の“ストリーム
”の実現は、標準的な“ストリーム“Ｉ１０インターフ
ェイス仕様を満たすように設計されているので、データ
暗号化及び解読ルーチン、及びデータ通信プロトコルの
ような他のストリーム手順によって簡単に層化すること
ができる。

このため、参考までに組み込まれている付録Ｅは、前述
のＩ１０仕様（本発明の範囲外である）に則してス）　
ＩＪ−ムの圧縮及び伸長機能゛を付与するのに必要な手
順を示している。オペレーティングシステムによって、
圧縮ソフトウェアのパッケージがロードされると、それ
らは、圧縮方法登録簿（不図示）によってそれ自体を登
録し、その方法によって与えられる手順にクライアント
（すなわち、圧縮システムのサービスを必要とする送信
データ端末装置及び受信データ端末装置）がアクセス可
能になる。圧縮を実施するため、クライアントはまず、
−ＣｒｅａｔｅＥｎｃｏｄｉｎｇＳｔｒｅａｍ−手順に
よって、圧縮器が必要とするデータ構造を初期設定する
が、コード化ストリーム生成に対するアーギユメントは
、ソースデータを表すコード語が送られる出カス）　Ｉ
Ｊ−ム手順で・ある。その後、クライアントは、”Ｃ３
ＵｎｓａｆｅＰｕｔＢｌｏｃｋ”手順を用イテ、圧縮の
ための文字ブロックを提示したり、あるいは“Ｃ３Ｐｕ
ｔＣｈａｒ”手順を用いて、単一の文字を提示する。一
連のソース記号を圧縮する途中で、圧縮器がその出力バ
ッファにコード語を累積するが、それは、その内部デー
タ構造で表された別の記号を有しており、該データ構造
に対するコード語はまだ生成されていない。従って、い
つでもクライアントがまだコード語で表されていない全
ての記号のコード化を強要し、これらのコード語の全て
が出力ストリームに送られるように強要することを望む
場合、それは“Ｃ３ＰＩｕｓｈ”手順を呼び出す。

Ｃ５ｔ！ｎ５ａｆｅＰｕｔ旧ｏｃｋ、　Ｃ３ＰｕｔＣｈ
ａｒ　及びＣ３Ｆｌｕｓｈは、任意の順序で繰返し呼び
出すことができる。最後に、クライアントが圧縮器の使
用を終えて、最後のＣ３ＦＩｕｓｈを出すと、Ｃ３Ｃｌ
ｏｓｅ”手順を呼び出すことによって、圧縮器が用いて
いた記憶領域を解放することができる。

同峰に、伸長器は、そのためのアーギュメントがコード
語を入手すべき人力ストリームである”ＣｒｅａｔｅＤ
ｅｃｏｄｉｎｇＳむｒｅａｍ”手順を有している。それ
は、また非圧縮すなわち解読ソース記号のブロックを得
るために呼び出すことができる “ＥＳＬＩｎｓａｆｅＧｅｔＢ！ｏｃｋ”手順と、単一
の非圧縮ソース記号を得るため呼び出すことができる“
ＥＳＧｅｔＣｈａｒ”手順を有している。更に、伸長器
はそれが用いた記憶領域を解放する“ＥＳＣＩｏｓｅ”
手順を有している。

このストリーム圧縮システムが、ファイルを圧縮するた
めに用いられる場合、Ｃ５ＦＩｕｓｈ　はファイルの終
了時に１度だけ用いられる。Ｃ５ＦＩｕｓｈ　は通常、
以下に述べるように、ＰａｄＣｏｐｙコード語又はＰａ
ｄＬ　ｉ　ｔｅｒａ　ｌコード語のいずれかを生成する
。これらのコード語はストリーム圧縮器とファイル圧縮
器の間における主たる相違点である。これらのコード語
には、極めて低い確率が割当てられるためストリーム圧
縮器によって用いられるコード化は相当するファイル圧
縮器によって用いられものとほぼ同一であり、得られる
圧縮器もほぼ同一である。明らかなことだが、ストリー
ム圧縮器の主たろ利点は、前述のように、ファイル圧縮
に加えて他の用途にも利用できるということにある。

ここで、第１２図に図示されている、圧縮器のＣ３Ｕｎ
ｓａｆｅＰｕｔＢｌｏｃｋ手順を参照すると、探索木は
当初、永久深さｌのノード、空の窓及び空の人力文字バ
ッファから構成されており、現在の整合の深さは０であ
る。圧縮のためＣ５ＬＩｎｓａｆｅＰｕｔＢｌｏｃｋ又
はＣ３ＰｕｔＣｈａｒ　によって文字が提供されるに従
って木は成長し、その３つの資源の１つがつきるまで窓
が満たされる。これらの資源は、サイズパラメータｍａ
ｘｃｏｐｙＤｉｓｐ　（木における葉すなわち窓の位置
の数）　　、１ＴｌａｘＮｏｄｅｓ　（水内で許容され
る最大ノード数）、及び、ｏ３ｕｆＳｉｚｅ　（人力文
字バッファの最大サイズ）によって規定される。　ｍａ
ｘＮｏｄｅｓとｏＢｕｆｓｉｚｅの値は、普通、ノード
と文字バッファのどちらを使い果たす前に大部分のソー
スデータがｍａｘｃｏｐｙＤｉｓｐ　の葉を使い果たす
ように選択される。

その場合、圧縮器は各コピーコード語又はリテラル文字
に関し、１つの葉は自由になり、１つの葉は割当てられ
るという“定常状態“の動作条件に結局たどりつくとに
なる。テキスト及び他の何らかの種類のデータに関し、
大きいソースデータで得られる圧縮度は、ｍａＸｃＯｐ
ｙＤｉｓｐが増大するにつれて増すことになる。付録Ｅ
における具体例は、ｍａｘｃｏｐｙＤ＋５ｐ＝１６．３
８４の位置の窓サイズを用いているが、この実施は約１
０００〜６３０００の間のｍａｘｃｏｐｙＤ　ｉｓｐの
値について十分機能を果たせるということが分かる。

圧縮器の初期設定時及びＣ３Ｆｌｕｓｈ　の後、最長の
整合の深さは０である。しかしＣ３ＵｎｓａｆｅＰｕｔ
Ｂｌｏｃｋ又はＣ５ＰｕｔＣｈａｒの実施後、最長の整
合の深さは常に１以上である。１０１におけるように、
圧縮のため次の文字が送られると、圧縮器はまず、この
文字を含めるため、現在の最長の整合を拡張しようとし
、拡張された記号のストリングは、１０２．１０３゜１
０４、１１１．１１３．１１０　及び１１２　に示すよ
うに木に挿入される。拡張記号ストリングの挿入時にた
どる探索径路は、木における現在の整合位置によって決
まる。すなわち、（１）現在の整合が葉の皿上にあれば
、拡張ス）　ＩＪソング探索径路は１０２．１１１．１
１３及び１１２　として規定され、（２）現在の整合が
ちょうどノード位置であれば、探索径路は１０２．１０
３．１１０及び１１２　として決定され、あるいは（３
）現在の整合が木の内部皿上にあれば探索径路は１０２
．１０３．１０４及び１１２　　として識別される。

１０４　のような探索木の内部皿上で、または１１１の
よ、うな木の葉の皿上でそれ以上整合の拡張ができなく
なると、ノードが自由リストから取り出されて、１０５
　のような整合の終了したポイントで木に分割される。

次に１０６　におけるように、新しい葉がこの新しいノ
ードからたらされる。或いは、整合が１１０のような既
存の７−ドを越えて拡張できない場合には、新しい葉は
１０６のような既存のノードからたらされる。整合は１
１３　のような葉の弧における最大許容可能コピー長、
すなわち深さに達するとやはり必ず終了する。ただしこ
うした状況下では、新しいストリングと、整合すること
になった以前に生じたストリングとの間には、時間的な
差異と、結果的に生じる探索窓に対するそれらの位置の
違いを除くと、実質的な相違はない。

従って１１４　におけるように、ストリングに関する切
取られた葉は除去され、１０６　におけるように新しい
葉がその位置につく。ノードが自由リストから取出され
る場合、自由リストが全てのノードが使用されているこ
とを表す、空ではないか確かめる。これが生じると、“
ｍａｘＮｏｄｅｓ”パラメータによって決まる最大ノー
ド割当てに達していなければ、新しいノードが生成され
て自由リストに加えられる。

最後に、１０７　におけるように、水位置が更新されて
新しい葉に対する親ノードから始まり、永久深さｌのノ
ードに達するまで、木を登っていく。

この具体例の場合、全てのノードが根まで更新されるが
、既述のようなバーコレーテイング更新の利用が可能で
あることは理解できよう。また具体例には、木の降下時
に、ノード位置を更新できるものもある。

この時点で木の更新が済み、新しい記号ストリングを正
確に表すことになる。次のステップは木で表されたばか
りのストリングをコード化し、次の整合を求める準備を
行うことに関するものである。窓が満杯の場合には、１
０８　におけるように、木から最古の葉が除去され、そ
の記憶域は次に生成されることになる葉のために再利用
可能になる（圧縮器がその窓をまだ満たしていなければ
、あるいは１１４　のように切り取り深さに達したため
に、その葉がすでに除去されている場合には、あるいは
１１７　におけるように、それがすでに除去されてバッ
ファ内にスペースができている場合には、あるいは１２
１　におけるように、木に割当てられた数のノードを使
い果たしたために、それがすでに除去されている場合に
は、このステップは不要である）。次に、１１５　にお
けるように、コード化が実施されるが、これについては
以下で第１３図において更に詳しく説明される。

コード化の後、圧縮器は、１１６　におけるように出力
バッファをチエツクし、バッファが最大許容可能コピー
長のコピー（次のコード語にとって最悪の場合）　を記
憶するのに十分な自由スペースを備えているか確かめる
。もしなければ、１１７　におけるように、木から最古
の葉が除去され、コピーに加えて追加記憶量にとって十
分な記憶スペース“ｏＢｕｆＲｅｓｅｒｖｅ”（付録Ｅ
参照のこと）がバッファ内で自由になる。各葉は、バッ
ファ内の１つ以上の記号を表しているので、葉を自由に
するとバッファスペースも自由にな５゜出力バッファを
チエツクした後、圧縮器は１２２　におけるように、ノ
ード自由リストが空（ｍａｘＮｏｄｅｓノードが、現在
水内で使用中であることを意味している）か否かを確か
める。そうであれば、それはバッチ除去処理”ＴｏＦｒ
ｅｅｌｅａｖｅｓ”　（パラメータ値１００　を有する
）　によって、木から最古の葉を除去する。菓を頻繁に
削除すると、残された息子が１人しかない親ノードを生
じることになり、従って、次に上述のノード削除処理す
なわち、再生処理が用いられると該親ノードを再生し、
自由リストにそれを加えることが可能になるが、このス
テップは、ノード自由リストが１つ以上の自由ノードを
含むようになるまで反復されることに注意すべきである
。明らかなことだが、ｍａｘｃｏｐｙＤｉｓｐの葉にと
って最悪の場合の要件以上の数のノードを割当てること
によって、少しシンプルになるように圧縮器に変更を加
えることで、第１２図のステップ１２１　及び１２２　
をなくすことができる。実際のところ、この代替案は、
付ＱＥにおけるコメントとして記述され、付録Ｃ及びＤ
の具体例で用いられている。しかし、この代替案のアプ
ローチの欠点は、圧縮器の記憶要件におけるものである
。

最後に最長の整合を拡張しなかった圧縮器に対し提出さ
れたばかりの文字が、１２３　におけるように新しい整
合の最初の文字になる。この文字に関して水位置は永久
深さ１のノードになるようにセットされ、圧縮器は更に
、もう１つの文字を受は入れるループを実施する。

明らかに、第１２図は付録Ｅの圧縮器と付録りの圧縮２
階のいずれかを表しているが、これらの２つの圧縮器は
、後述するコード化機能１１５　に隠されたコード化の
細部において異なっている。更に、付録りの圧縮器は“
ｍａｘｃｏｐｙＤ　ｉｓｐ”の葉の最悪の場合の要件に
とって十分な数のノードを設けることによって、ノード
取扱いステップ１２１　及び１２２　が排除される、上
述のよりシンプルな変更を利用している。

２、　木構造エンコーダ 第１２図におけるステップ１０５　は、圧縮器のコード
化セクションを表しており、第１３図には、付録Ｅの木
構造によるエンコーダがより詳しく図示されている。コ
ード化セクションのジョブは、ＮｏｄｅＣｏｐｙ、　Ｌ
ｅａｆＣｏｐｙ、　Ｌｉｔｅｒａｌ、　ＰａｄＬｉｔｅ
ｒａｌ　及びＰａｄＣｏｐｙコード梧によって、ソース
データをコンパクトに表すことである。用いられる種類
のコードは、都合のよいことに、接頭部コードであり、
これはどのコード語も他のコードの接頭部にならないこ
とを意味し、従って、伸長器はコード語のストリームを
明確に解読することができる。

付録Ｃの具体例の場合、文字がすでにコピーコード語に
よって表されているか否かに関係なく、各文字毎にコー
ド化セクションが入力され、従って、第３図のステップ
７８のように、文字スキップカウントが用いられる。こ
れは、別のコード語を生成する時間になるまで、コピー
コード語ですでに表されている文字をカウントダウンす
るのに用いられる。しかし、付録り及びＥにおける具体
例に関するエンコーダは、すでにコード化された文字ｊ
＝ついては２度と入力されないので、それらはこのスキ
ップカウントを必要としない。

エンコーダは、まず次の文字がリテラルで表されるよう
になる時、及びそれがコピーで表されるようになる時を
決める。最長の整合が、長さ１である場合、その文字は
リテラルで表さねばならないが、最長の整合が長さ２以
上であれば、この方法は、リテラルとコピーのいずれで
それを表すか選択することができる。付録Ｃ及びＤの具
体例はこの方法の決定を純粋に最長の整合の長さに基づ
いて行うものではないが、この理由は、長さ１のリテラ
ルのコード化が４ビフト（及び文字）を必要とし、一方
長さ２又は３のリテラルが６ピツト（及び文字）を必要
とすることにある。すなわち、リテラルを開始する“コ
スト”は４ビツトであるが、長さｌから長さ２への拡張
はコストが２ビツトしかかからず、長さ２から長さ３へ
の拡張はコストが０ビツトである。これらのコストが異
なるため、都合のよいことに、エンコーダはなかなかリ
テラルを開始しようしないが、−旦それを始めると、コ
ピーのためになかなかそれを終了しようとしない。すな
わち、好都合なことには、方法の決定には“ヒステリシ
ス”が存在する。これらを考慮すると、長さ２のコピー
がリテラルにとって望ましいが、−旦すチラルが開始さ
れると長さ３の（すなわち、最大リテラル長に達する）
コピーしかそれを停止することができないという上述の
シンプルな方法になる。わずかに複雑さが増すという犠
牲を払って、少し高めの圧縮度が得られる他の方法を考
えることも可能である。

ただし、付録Ｅの木構造のエンコーダの場合別の考慮が
働くことになる。すなわち、伸長器は圧縮器のものと同
様のハツシュテーブルまたは他のデータ４Ｒ造に頼らず
に、解読するコード語から木を再生成できるのが望まし
い。このため最長の整合が長さ２以上の場合には、必ず
コピーを選択し、最長の整合が長さ２未満の場合に限っ
てリテラルを開始または拡張するように、その方法に制
限を加えることが望ましい。この制■の結果、伸長器は
必ずリテラル文字に関する葉をそのリテラル文字に対応
する永久深さｌのノードからたらすことができるように
なる。この方法の制限の結果、伸長器はより複雑な方法
に従った場合に比べて圧縮度が少し低くなるのが普通で
あるが、よりシンプルで、より速く動作し、より少ない
記憶域ですむことになる。

第１３図を参照すると明らかだが、コード化は用いられ
る圧縮アルゴリズムによって決まる。しかし、望ましい
圧縮アルゴリズムの全てに共通した特性に従い、１２７
　におけるように、まずリテラルがコード化中か否かを
判定する。リテラルがコード化中の場合、１２８　にお
けるように、上述の挿入処理における各反復の間、コー
ド化されるコピーが出てくるまで、または１２９　にお
けるように最大許容可能長のリテラルがアセンブルされ
るまで、リテラルの長さが拡張される。リテラルがその
最大許容可能長に達すると、１３１　におけるように、
リテラルコード語は累算されたリテラル記号の直前にあ
る出力バッファにロードされる。同様にコード化すべき
コピーがあると、１３４　におけるように、累算したリ
テラル長カウントをチエツクしてリテラルが累算中かど
うか確かめる。そうであれば、１３５　におけるように
、リテラルコード語と累算したリテラル記号がコピーコ
ード語の前の出力バッファにロードされる（想起される
ように、リテラルコード語とそれに付属のリテラルソー
ス記号は、コピーの存在が確認された後及びコピーに関
するコード語がロードされる前には、いつでも圧縮器の
出力バッファにロードすることができる）。

リテラルが出力されると、必ず１３４　における累算さ
れたリテラル記号のカウントが０にリセットされるため
、別のリテラルの累算が可能になる。

この場合、１３８　において判定されるように、コピー
が葉の皿上で終了するか否かに従って、ＬｅａｆＣｏｐ
ｙ１３６　またはＮ０ｄｅＣＯｐＹ１３７　を用いてコ
ピーがコード化される。１３９　におけるように、各リ
テラルの後出カバソファがチエツクされコピーがそれに
ロードされるが、１４０　に右けるように、それが略満
坏の場合にはダンプされる。木構造のコード化のさまざ
まな細部については、付録Ｅのコメントに記述されてい
る。コード化に関する追加説明については、以下の伸長
器の説明において行うものとする。

３、エンコーダのバイトアライメント 第１４図を参照すると、フラッシュ指令が出される時、
任意の部分リテラルと圧縮器内に残っているコピーの両
方または一方に関するコード語を出力するため、フラッ
シュ処理が用いられる。ファイル圧縮器の場合、こうし
た指令はファイルの終了時に限って出されるが、その時
点においては圧縮器が通常のコピーコード語またはリテ
ラルコード語を出力する用意が整っていなくても、ビッ
トの進行ストリングを終了し、それらが間違ってコード
語と解釈されないようにする必要のある場合には、通常
圧縮器からファイルの最後のわずかな記号もいっきょに
送り出す必要がある。ストリーム圧縮器の場合、フラッ
シュ処理は圧ｖａ器に関するソースデータが一時的に使
い果たされている間に、受信器に対し追加圧縮データを
いくつか提供するのに用いることもできる。どちらかの
タイプの圧縮器においても、フラッシュは圧縮データは
バイトまたは語アライメントを復元する（付録Ｅの具体
例は、１６ビツトの境界に対するアライメントを復元す
る）。

フラッシュが開始すると圧縮器の通常の動作は一時的に
中断され、その探索木７３（第３図）が次の記号または
文字を挿入する準備の整えられる深さが１４１　におけ
るようにチエツクされる。木がすでに根までセットされ
ている場合、フラッシュは１４２　において打ち切られ
、圧縮器はすぐに通常の動作に復元される。さもなけれ
ば、１４３　におけるように累算されたリテラルカウン
トがチエツクされ、１４４　におけるように７ラブシ二
によって中断されたリテラルの累算記号を伴ってリテラ
ルコード語が出力される。累算されたリテラルの出力後
最古の葉がまだ削除されていなければ、１４４　におけ
るように、それが木から除去される。しかし、パッドコ
ード語によってコード化される記号は明確な探索経路を
規定していないので、木はそれらに対し更新されない。

次に１４５　におけるように、フラッシュが開始する時
木が深さ１のノードにある場合には、まだ圧縮器の探索
木内にある１つのソース記号を伴うパッドリテラルコー
ド語を用いて、あるいは水内にまだ２つ以上のソース記
号がある場合には、中断されたコピーの探索窓での記号
位置及び長さを識別するパフトコピーコード語を用いて
フラッシュがコード化される。圧縮器の出力バッファに
パッドリテラルコード語またはパッドコピーコード１５
がロードされ、それに追加ビットを加えて、この特定の
例におけるように次の１６ビツトの境界のような都合の
よい境界で、バッファの出力のアライメントがとられる
。最後に、１４６におけるようにバッファがダンプされ
、さらに１４７　におけるように、探索木７３（第３図
）はその根にリセットされて圧縮器がそれ以上の文字を
受信するのに備える。

４、木構造の伸長器 本発明の付録Ｅの具体例によれば、クライアントはコー
ド語を取り出すことになる人力ストリーム（あるいはデ
ータ源）をアーギユメントとして備える“Ｃｒｅａｔｅ
ＤｅｃｏｄｉｎｇＳｔｒｅａｍ”手順を呼び出すことに
よって、伸長器の初期設定を行う。初期設定後、クライ
アントは文字ブロックを読み取る１ε５ＬＩｎｓａｆｅ
Ｇｅｔ８１ｏｃｋ’と、単一の文字を読み取る“ＥＳＧ
ｅｔＣｈａｒ”に対し、繰り返し手順呼出しを行い、ク
ライアントの指示に従って入力ストリームからコード語
を順次解読することにより、非圧縮または伸長記号が抽
出されるようにする。”ＥＳｅｎｄ口ｆ”は、伸長スト
リームがそれ以上記号を送り出すことができないかチエ
ツクするのに用いることができる。“ε５Ｇｅｔｃｈａ
ｒ“の実施は、単に記号カウント１を備える”ＥＳＬＩ
ｎｓａｆｅＧｅｔ８１ｏｃｋ”を呼び出すだけであるた
め、ここでの説明は’［１ＳＬＩｎｓａｆｅＧｅｔＢＩ
ｏｃｋ“に制限するが、“ＢＳＧｅｔＣｈａｒ”手順に
対しても同様の説明があてはまることは理解できよう。

第１５Ａ図及び第１５Ｂ図を参照すると、伸長器は圧縮
器を補足して忠実にもとのソースデータを回復すること
が分かる。そのため上に指摘したように、伸長器のデー
タ構造は圧縮器のデータ構造とちょうど同じように初期
設定される。さらにコード語が解読される時には、必ず
伸長器の木と探索窓は圧縮処理の対応するステップにふ
ける圧縮器の木と同一になる。明らかに、コード語を解
読するために伸長器がとるステップはコード化によって
完全に書き取られる。

付録Ｅの伸長器は、その人力ストリームからビットを得
るための人力サブルーチンを備えている。

１５６．１５９　及び１６０　におけるように、別のコ
ード語またはリテラル文字のためにさらにビットが必要
とされる場合には、ビットを得るためにこのサブルーチ
ンが必ず呼び出される。入力ストリームが完全に使い果
たされると、′εｎｄＯｆｓｔｒｅａｍ’　エラーフラ
グが掲げられ、その結果“ε５ＵｎｓａｆｅＧｅｔＢｌ
ｏｃｋ″手順がそのクライアントに戻されて、文字カウ
ントは要求されるカウント未満になる。その結果、クラ
イアントは伸長を終了する。

伸長器は、もしあれば伸長されている現在のコピーのバ
ッファ位置と残りの長さ、あるいは、もしあれば伸長さ
れている現在のリテラルの残りの長さである状態変数を
有している。１５１　におけるように、別の文字が要求
されると、′ε５ＵｎｓａｆｅＧｅｔＢｌｏｃｋ′″は
まずこれらの変数をチエツクし、他のコードを解読しな
くても次の記号を送り出すことができるか確かめる。　
ＭｏｄｅＣｏｐｙ　、非ゼロの弧変位を有するＬｅａｆ
Ｃｏｐｙ　、またはＰａｄＣｏｐｙ　コード語が伸長さ
れる処理中であれば、伸長器は１５２．１５３及び１５
４で示すステップを利用して、次の文字を別の場所から
文字バッファへ複写することによりそれを送り出す。一
方、リテラルコード語（すなわち、ゼロ弧変位を有する
ＬｅａｆＣｏｐｙ　）が伸長される処理中であれば、伸
長器は１５２．１５５．１５６．１５７及び１５８で示
すステップを利用して次のリテラル文字を伸長する。

明らかに、木は全てのリテラル文字毎に、及び全てのコ
ピーコード語毎に更新される。ステップ１０Ｂ’、１１
６°、１１７°、１２２°　及び１２１°は、圧縮器に
関連して前に述べたのと全く同様に、葉、ノード、及び
バッファを規定することに関連したものである。

同様に、ステップ１０８’、１１６°、１１７’　、１
２２’　　及び１２１゛は、１５７　におけるように圧
縮器によって行われたのと全く同様に、葉が伸長器の木
の永久深さｌのノードに取りつけられるようにする。従
って圧縮器を説明するのに用いられたものに対応する準
備基準数値が、伸長処理の同様のステップの識別に用い
られている。

現在のコピーまたはリテラルが使い果たされると、１５
９　におけるように次のコード語を解読するのが適正で
ある。コード語がＮｏｄｅＣｏｐｙまたはＬｅａｆＣｏ
ｐｙてあれば、これは木に新しい葉を加えることになる
。更に、葉は伸長器の木に対し各リテラルの最初の文字
毎に加えられることになる。こうした可能性のあるコー
ド語にそなえるため、再びステップ１０８’、１１６°
、１１７’、１２２’　　及び１２１°が用いられて、
葉に必要な資源が得られるか確認がされ、またコード化
時に圧縮器が有していたのと同じ構成を伸長器が解読時
に備えるか確認がされる。

コード化は“接頭部コードとして知られる１群のコード
を用いるが、これはどのコード語も他のコード語の接頭
部にならないということを意味するため、１５９　にお
けるように、デコーダはあるコード語と別のコード語を
簡単に区別することができる。従って、任意のビットシ
ーケンスの可能性のある解釈は１つだけしかないことに
なる。詳述すると、付録Ｅによって用いられるコード化
において、コード語の最初のビットが　１ｅａｆＣｏｐ
ｙ。

Ｌ＋ｔｅｒａｌ、ｐａｄＣｏｐｙ　及びＰａｄＬｉｔｅ
ｒａｌ　Ｄ−ド語からＮｏｄｅＣｏｐｙコード語を区別
する。このビット信号がＮｏｄｅＣｏｐｙを知らせると
、使用中の最大ノード数が既述の“疎コード化”技術を
用いてノード番号として読み取られ、解読されることに
なるビット数を求める。次に、このノード数は木に参照
符をつけ、その特定のノードに対する人力弧の長さを求
めるために利用される。さらに、指定のノードに対する
人力弧が記号１つの長さを越えると、その記号長はやは
り弧長の１疎コ一ド表現に基づいて、弧変位として解読
されるビット数を決める。

ノード番号の解読は、伸長器が最大ノード数について圧
縮器と同じ値を用いることと、圧縮器とちょうど同じよ
うにノードに番号をつけて用いられる木を有する必要の
あることに注意すべきである。

１５９　におけるように、デコーダによって処理される
最初のビットが解読中のコード語がＮｏｄｅＣｏｐｙで
ないことを示す場合には、必ずそのコードの最大、すな
わち停止サイズのフィールド（すなわち１１個の２進数
ｌの“インジケータ”　（すなわち１１１１１１１１１
１　）から成る単項コード語）が単項コードから“エス
ケープ″して、パッドコピーコード語またはパッドリテ
ラルコード語を出力するよう予約されるということを除
き、＜　１．１．１２＞の単項コードが解読される。＜
１．１．１２＞の単項コードの解読値がリテラルを表す
０の場合、デコーダは次にリテラル長として＜０．１．
５＞の単項コードを解読し、リテラルに付加されるリテ
ラルソース記号の数を求める。

＜１．１．１２＞の単項コードの解読値が〔ｌ・・・４
０９４　］の範囲内であれば、それは葉の弧の親ノード
から葉の弧を下降する弧変位として解釈される。従って
、圧縮画変位は、エンコーダに関して上に述べたように
、この場合＜１０−Ｘ、　　２．１４−Ｘ＞の単項コー
ドと、その最大すなわち“停止”フィールドの“疎コー
ド化”に基づいて解読される。

弧変位がｐａｄｃｏｐｙ　またはＰａｄいｔｅｒａｔを
意味する場合、ＰａｄＣＯｌ］Ｖ長フィールドは＜１．
１．１２＞の単項コードを用いて解読される。このフィ
ールドの解読値が０の場合、それはコード語が単一のリ
テラル文字の後続するパッドリテラルであることを意味
している。でなければ、ＰａｄＣｏｐｙ長が解読された
後、最長の整合の最初の、すなわち先行する記号の探索
窓での位置に対する相対変位が（１０−Ｘ。

２．１４−Ｘ＞の単項コードを用いて解読され、最大す
なわち“停止”フィールドに関する疎フィールドが改善
される。これらの細部の全てが、前述の圧縮器によって
実行されるコード化動作に一致する。

１５９　におけるように、デコーダがＬｅａｆＣｏｐｙ
またはパフトコピーを解読すると、それは現在の窓位置
と、最長の整合が見つけられた窓位置の間における圧縮
位置の数（すなわち、コピーコード語またはリテラル文
字の数）である圧縮変位を送り出す。圧縮変位は、窓サ
イズを法とした現在の窓位置から圧縮変位を引くことに
よって、圧縮窓位置、すなわち相当する葉の数に翻訳さ
れる。デコーダがＮｏｄｅＣｏｐｙを解読すると、指定
ノードに関する圧縮窓位置は木内のノードから得られる
。これらの場合の全てにおいて、圧縮窓位置は、圧縮窓
位置に関する°’ｃＷｉｎｄｏｗ”アレイ項目を読み取
ることによって文字バッファ位置に翻訳される（付録Ｅ
参照のこと）。これらの翻訳は、第１５Ｂ図に１６２　
及び１７０　で概略が示されている。

ＰａｄＬｉｔｅｒａｌまたはＰａｄＣｏｐｙ　コード語
の解読に応答して、伸長器の木に葉が加えられることは
ない。

木に葉が加えられない理由は、圧縮器システムのこの特
定の具体例に特有のものであり、付録Ｅの“Ｃ５Ｆｌｕ
ｓｈ手順”に先行する長いコメントに説明されている。

しかしながら、それらはこれ以上の解説を正当化するほ
ど十分に本発明の趣旨に関連したものではない。実際の
ところ、ブセグラミング技術における熟練者には、パッ
ド機能を実施するのにさまざまな方法があることが分か
るであろう。

それにもかかわらず、この機能は重要であり、従って伸
長器はボックス１６０　におけるように、ＰａｄＬｉｔ
ｅｒａｌ　　コード語から文字バッファへ単一の記号を
移し、次に人力ストリームからアライメントのとれる次
の１６ビツト位置までビットをスキップすることによっ
て、１６１　におけるように、１６ビツト語の境界にお
いて人力ストリームのアライメントをとるということに
留意すること。同様にＰａｄＣｏ＋）ｙに応答して、伸
長器は、１６２　におけるようにＰａｄＣｏｐｙ圧縮変
位を文字バッファ位置に翻訳しく上述のように）　、Ｐ
ａｄＣｏｐｙ長を保管する。それは次に、１５３及び１
５４　におけるように、ｐａｄｃｏｐｙ　によって表さ
れる記号をバッファに複写することによって、このプロ
セスを完了する前に、ちょうどＰａｄＬ　ｉ　ｔｅｒａ
　ｌの場合のように１６ビツトの境界においてアライメ
ントをとる。

デコーダが、１５９　におけるようにＬｅａｆＣｏｐｙ
を解読すると、それは次に、上述のように圧縮変位を葉
の数すなわち窓位置に翻訳する。次に、それは親ポイン
タに従って、木内の指示された葉からその葉の親ノード
に進む（明らかなことだが、このノードの深さプラス弧
変位は、複写されることになる文字数である）。１１３
　におけるように、計算されたコピー長が最大許容可能
コピー長に等しいと判定されると、再発生記号ス）　Ｉ
Ｊソング関する切り取られた葉が、１１４°におけるよ
うに木から除去されて、１０６゛におけるように新しい
葉に置き換えられる。やはり、これらの働きは、圧縮器
内における相当する働きにちょうど対応している。通常
はそうであるように、最大許容可能コピー長に達しなか
った場合には、１６４　におけるように、葉及びノード
が木に加えられる。ステップ１６５．１６６、及び１６
７　は、最大許容可能数のノードｍａｘＮｏｄｅｓ”が
使用されるまで、使用されるノード数を漸増させること
に関連′している（それらは、圧縮器におけるステップ
１０５　の機能に関して少し詳しい説明を提供する）。

ｍａＸＮＯｄｅｓノードが用いられていない限り、ノー
ド自由リストが空でないことを確認するこれらノード自
由リストのチエツク後、ちょうど１０７　における圧縮
器の場合のように、木の位置は１０７°におけるように
更新され、窓位置は、上述のように“ｃＷｉｎｄｏｗ”
　アレイを読み取ることによって、１７０　におけるよ
うに文字バッファ位置に翻訳される。最後に、Ｌｅａｆ
Ｃｏｐｙの最初の文字が１５３及び１５４　におけるよ
うに複写される。

デコーダがＮｏｄｅＣｏｐｙを解読すると、指示された
ノードの深さ及び窓位置が、１６９　におけるように木
から得られる。１６８　においてテストされたように弧
変位がゼロであれば、最長の整合はちょうどノードで終
了したことになる。この場合新しい葉は、１０６°にお
けるように指示されたノードからたれ下がる。さもなけ
れば、自由リストから新しいノードが取り出され、↑旨
示されたノードの親から指示された弧変位をしたところ
で木に挿入されて、１６４　におけるように新しいノー
ドから新しい葉がたれる。その他の働きは、１６５．１
６６．１６７．１０７°、１７０．１５３　及び１５４
　に示したように葉のコピーの場合と同じである。

文字が送り出された後、伸長器は循環してステップ１５
１　　に戻り続行する。

Ｊ結論〕 以上を考慮すると、本発明のく開始、ステップ、停止〉
の単項コード化は、本書に開示のさまざまなテキストｉ
換データ圧縮処理に関するコピー及びリテラルのような
、圧縮データをコード化するための一群の可変長コード
語を提供するということが理解できる。ただし、テキス
）Ｒ換データ圧縮は、この〈開始、ステップ、停止〉の
単項コード化を有効に利用できる、あるタイプのデータ
圧縮のほんの一例にしかすぎない。

【図面の簡単な説明】

第１図はデータ圧縮システムの簡易ブロック図、第２図
は本発明の基本的具体例に従ったサンプルテキストのス
トリングに関するコード化を示す図、第３図は第２図に
示すコード化を実施するように構成されたデータ圧縮器
のさらに詳細なブロック図、第４図は第３図に示す圧縮
器によって圧縮されたデータを復元する伸長器のブロッ
ク図である。 第５図はサンプル記号のス）　ＩＪソング関する記号毎
のパージングを示し、第６Ａ図〜第６Ｅ図はトリー（Ｔ
ｒｉｅ）の探索木編成が施されたデータ構造の構成を図
表で示し、第７Ａ図〜第７ε図はバトリシア（ＰＡＴＨ
ＩＣＩＡ）の木編成が施されたデータ構造の構成を図表
で示し、第８図は第７Ｅ図に示すデータ構造の接尾木編
成を図表で示している。第９図は接尾木の一般化表現、
第１Ｏ図は単項符号器を備える圧縮器の略ブロック図、
第１１図は第１０図に示す単項符号器の動作を示す有限
状態図、第１２図は圧縮変位を利用する、すなわち、木
構造エンコーダを備えたテキスト置換圧縮器に関する簡
易フロー図、第１３図は第１２図に示す圧縮器の木構造
エンコーダに関する簡易フロー図、第１４図は第１２図
に示す圧縮器の圧縮出力のアライメントをとる語に関す
るフラッシュ及びパッドサブルーチンの簡易フロー図で
ある。第１５Ａ図〜第１５８図は組み合わせると第１２
図〜第１４図に示す圧縮器に対する伸長器の簡易フロー
図を形成する。 ６１：データ圧縮システム ６２：圧縮器　　　　　６３：伸長器 特許［ｆｆ人セロックスコーポレーション代　　理　　
人　　　　　　小　　堀　　　益ＦＩＧ、５Ａ ＦＩＧ、７８ ＦＩＧ、７Ｃ ＦＩＧ、　１１

Claims (1)

【特許請求の範囲】
1. １、圧縮データをコード化するための一群の可変長コー
   ドを提供する、開始、ステップ、停止の単項コード化。