JP6425709B2 - 復元中に予備拡張辞書を利用するデータ復元 - Google Patents

Description

本発明の実施形態は、圧縮及び復元に関し、より詳細には、復元性能を向上させるために圧縮辞書の予備拡張及び自己復元データ要素を用いることに関する。

現代のソフトウェアアプリケーションは、ディスク上に若しくはメモリ内に格納されるデータ、又はネットワークを介して伝送されるデータのサイズを小さくするために、圧縮を広範に利用している。圧縮技術は、損失なしの場合も損失ありの場合もある。損失あり技術は、元のソースデータに対してある程度のデータを失うことが許容できる場合に用いることができる。例えば、低解像度システム（例えば、携帯電話のディスプレイ）によって提示される写真は、より高解像度のソース写真（例えば、高解像度の家族写真）によって提供される詳細の全てを必ずしも必要としない。携帯電話は、本質的に、より高解像度の家族写真の実体を表示するが、より低解像度の画像を使用することにより利用可能な低減された処理要件及びストレージ要件を伴う。

データを圧縮するための損失なし技術は、データの損失が有害な場合（例えば、銀行口座の桁の損失、社会保障番号の損失、又は緊急応答システムなどの基幹システム用のデータの損失）に用いることができる。圧縮及び復元技術の使用は、一般に、圧縮処理側及び復元処理側の両方において、ＣＰＵ処理リソースと、ディスクスペース又はデータ伝送リソースとのトレード・オフとなる。換言すれば、高い圧縮効率は、典型的にはより多くの処理リソース及びより少ないストレージ・スペースを必要とし、一方、低い圧縮効率は、典型的にはより少ない処理リソース及びより多くのストレージ又は伝送リソースを必要とする。効率を高めるための伝統的な手法は、圧縮アルゴリズムに焦点を合わせてきた。

本発明の目的は、復元性能を向上させるための、圧縮データを復元する方法、システム及びコンピュータ・プログラム製品を提供することである。

本発明の１つの実施形態によれば、コンピュータによって実行される、圧縮データを復元するための方法が提供される。第１の復元辞書が解析される。第１の復元辞書は、アドレス指定スキームに基づいて第１の復元辞書内に非連続方式で分散された未圧縮データ部分を各々が有する複数の連鎖を含み、ここで各連鎖の前記未圧縮データ部分は、圧縮データの対応する未圧縮バージョンを形成する。第１の復元辞書内の連鎖の各々の未圧縮データ部分を組み合わせて圧縮データの未圧縮バージョンを形成することにより、第２の復元辞書が生成され、圧縮データを復元するための命令が第２の復元辞書内に挿入される。圧縮データを第２の復元辞書に適用することによって、圧縮データが復元される。本発明の実施形態は、圧縮データを上述の方法と実質的に同じ方式で復元するためのシステム及びコンピュータ・プログラム製品をさらに含む。

一般に、種々の図面において同様の数字は、同様の構成要素を示すために使用される。

本発明の実施形態で使用するための例示的なコンピューティング環境の線図である。 本発明の実施形態による圧縮スキームの初期復元辞書から第２の復元辞書を生成する方式を示す手順フローチャートである。 本発明の実施形態による第２の復元辞書を利用して圧縮データを復元する方式を示す手順フローチャートである。

多くのデータ圧縮技術がその対応する復元方式と共に存在するが、本明細書で説明する技術は、Ｚｉｖ−Ｌｅｍｐｅｌアルゴリズムのような記号又はトークン置換型損失なし圧縮技術において特に有用となる。Ｚｉｖ−Ｌｅｍｐｅｌアルゴリズムは、一連の記号を単一コードで置き換えることによって効率を達成するが、付加的なコード化を伴う。例えば、文字「Ａ」を数字１で置き換えることができ、「Ｂ」を数字２で、以下同様に英語のアルファベットの２６文字を置き換えることができるが、それでもなおこれは、１対１記号置換である。

しかしながら、いずれの所与の言語においても、一連の記号は共通である。例えば、単語「ｔｈｅ」は、３つの記号又は単一のトークンを含み、英語において広範に用いられる。この場合、単語「ｔｈｅ」全体を、単一ビット（又は文字として格納される場合には単一バイト）しか必要としない数字「１」のような単一記号で表すことができ、これにより、３記号の単語が３対１（３：１）の置換効率で単一記号に削減される。高い効率を得るために、ビット単位コードを用いることができる（例えば、トークンをコード化するための最小数のビット）。この例においては、数字「１」がトークン「ｔｈｅ」の置換コードとなる。さらに、文法構造が関与する場合、単語「ｔｈｅ」は、記号「ｔｈｅ」が完全にその内部に含まれる（例えばａｎ「ｔｈｅ」ｍ）「ａｎｔｈｅｍ」のような別の単語の一部でないときには常に、少なくとも２つのスペースで囲まれていることを識別することができる。従って、英語において見いだされる単語「ｔｈｅ」は、通常、２つのスペースで囲まれた「ｔｈｅ」の形態（すなわち、単語「ｔｈｅ」）であり、合計で５つの記号になるが、それでもなお数字「１」のような単一コードで置き換えることができるので、これによりこのトークン内の５つの記号が、５：１の置換効率で単一コードに削減される。語句がソース文書内で繰り返される場合、さらなる効率を達成することができる。

元のトークンとその対応する置換コードとが辞書内に格納される。この点に関して、単純な置換を用いる圧縮の単純化された考え方は、復元中にコード「１」を「見つけ（ｌｏｏｋ ｕｐ）」、トークン「ｔｈｅ」で置換することである。しかしながら、実際の動作においては、入力データストリームは、通常、連続的に処理され（例えば、大容量の辞典を圧縮することを考える）、新たなトークンに遭遇するたびにこれが付加される。従って、圧縮辞書は単なる単純な語彙集ではなく、最終的に元データを損失なしに回復するための、未圧縮データからの入力トークンの複雑なコード化、及び辞書内でのトークンのアドレス指定である。このような複雑さは、Ｚｉｖ−Ｌｅｍｐｅｌ圧縮に対する復元技術に関してこの後で提示される例を通じて明らかになるであろう。

説明を簡単にするために、本明細書で説明する技術を、Ｚｉｖ−Ｌｅｍｐｅｌ圧縮スキームのような広範に用いられる基本アルゴリズムに関して説明する。本明細書で説明する技術の多くは、他の圧縮及び復元技術（例えば、文脈木重み付け法又はバイト対コード化）に変換することができる。学界によっては、Ｚｉｖ−Ｌｅｍｐｅｌは、Ｌｅｍｐｅｌ−Ｚｉｖ（ＬＺ）とも呼ばれる。本明細書において用いる場合、Ｚｉｖ−Ｌｅｍｐｅｌ、Ｌｅｍｐｅｌ−Ｚｉｖ、及びＬＺは全て、Ｚｉｖ−Ｌｅｍｐｅｌアルゴリズム、又はその変形及び等価物を指すものとする。

その発端から、Ｚｉｖ−Ｌｅｍｐｅｌは、特定の用途に合わせてアルゴリズムを改良して（例えば、Ｈｕｆｆｍａｎコード化技術を追加することにより）、ＬＺアルゴリズムのファミリーを形成することにより進歩してきた。例えば、ＬＺ７７及びＬＺ７８アルゴリズムは、異なる用途に用いられている。ＬＺ７７は、．ＺＩＰファイル圧縮及びＳｔａｃｋｅｒディスク圧縮アルゴリズムと共に用いる場合に効率を有する。別の変形において、ＬＺ７８は、Ｖ．４２モデム標準を用いたネットワーク上のデータ伝送と共に用いる場合、又は画像交換フォーマット（ＧＩＦ）圧縮を用いる画像圧縮と共に用いる場合に効率を有する。このようにして、Ｚｉｖ−Ｌｅｍｐｅｌアルゴリズムは時と共に進化してきた。

伝統的な圧縮技術は、一般に復元効率よりもむしろ圧縮効率をより指向したものである。本発明の実施形態は、復元効率を高める。本発明の実施形態で使用するための例示的な環境を図１に示す。具体的には、この環境は、１つ又は複数のサーバ・システム１０と、１つ又は複数のクライアント又はエンドユーザ・システム１４とを含む。サーバ・システム１０及びクライアント・システム１４は、互いに遠隔にあってネットワーク１２上で通信するものとすることができる。ネットワークは、任意の数の任意の適切な通信媒体（例えば、広域ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、インターネット、イントラネットなど）によって実装することができる。代替的に、サーバ・システム１０とクライアント・システム１４は、互いにローカルにあって、任意の適切なローカル通信媒体（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、配線、無線リンク、イントラネットなど）を介して通信するものとすることができる。

サーバ・システム１０及びクライアント・システム１４は、ディスプレイ又はモニタ（図示せず）、ベース（例えば、少なくとも１つのプロセッサ１５、１つ若しくは複数のメモリ３５及び／又は内部若しくは外部ネットワークインタフェース若しくは通信装置２５（例えば、モデム、ネットワークカードなど））、随意の入力装置（例えば、キーボード、マウス又はその他の入力装置）、並びに任意の市販ソフトウェア及びカスタム・ソフトウェア（例えば、サーバ／通信ソフトウェア、文字列復元記録モジュール、命令コード化モジュール、ブラウザ／インタフェース・ソフトウェアなど）を装備することが好ましい、任意の従来の又はその他のコンピュータ・システムによって実装することができる。

クライアント・システム１４は、ユーザが、サーバ・システム１０へ圧縮データセット（例えば、ファイル、文書、ピクチャなど）を圧縮すること、又はサーバ・システム１０から圧縮データセットを取り出すことを可能にする。サーバ・システムは、後述するように、既に圧縮された（例えばＺｉｖ−Ｌｅｍｐｅｌアルゴリズムにより）圧縮データ（例えば、ファイル、文書、ピクチャなど）を復元するための復元モジュール１６と、ひとたび圧縮データセットが取り出されたとき（例えば、データ処理システム又はユーザにより）の自己復元のための命令を埋め込むための命令コード化モジュール２０とを含む。

データベース・システム１８は、種々の形態の圧縮ベースの情報（例えば、圧縮データ及びデータベース、並びに復元辞書など）を格納することができる。データベース・システムは、任意の従来の又はその他のデータベース又はストレージ・ユニットによって実装することができ、サーバ・システム１０及びクライアント・システム１４に対してローカル又は遠隔にあるものとすることができ、任意の適切な通信媒体（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、配線、無線リンク、イントラネットなど）を介して通信することができる。

本発明の実施形態の簡単な要約を目的として、伝統的な方法で圧縮されたデータセットが、本明細書で説明する技術によって予備拡張される。本明細書で説明する例において、圧縮データは、固定長、その元の長さ、又は復元効率を補助するその他の何らかの都合の良い長さに復元される。Ｚｉｖ−Ｌｅｍｐｅｌ圧縮に関して、復元は、辞書の拡張によって達成され、この辞書は、圧縮中に定義される本質的に「翻訳」辞書であり、これは、より小さい参照コードをその元の対応トークンに変換する（例えば、上述のようにコード数字「１」が「ｔｈｅ」に変換される）。拡張された対応トークンを指定された順序で連結して元のソースデータが形成され、これにより、圧縮されていた元データが生成される。

あるいは、１つ又は複数のクライアント・システム１４は、独立型ユニットとして動作している場合には復元を行うことができる。独立型動作モードにおいて、クライアント・システムは、データ（例えば、圧縮データ及びデータベース、並びに復元辞書など）を格納するか又はデータへのアクセスを有し、復元モジュール１６と、格納及び復元のための命令を挿入するための命令コード化モジュール２０とを含む。本質的に、ＬＺ辞書を部分的に拡張して第２の辞書を得る。復元中の第２の復元辞書の使用により、最終的に元のデータセットの回復がもたらされる。

クライアント・システム１４のグラフィカル・ユーザ・インタフェース（例えば、ＧＵＩなど）又はその他のインタフェース（例えば、コマンドラインプロンプト、メニュースクリーンなど）は、所望のデータ及び解析に関係する対応ユーザからの情報を要請し、解析結果（例えば、圧縮効率、予備拡張効率、最終復元中のＣＰＵ使用量など）を含むレポートを提供することができる。

モジュール１６及び２０は、後述する本発明の実施形態の種々の機能を行うための１つ又は複数のモジュール又はユニットを含むことができる。種々のモジュール（例えば、復元モジュール１６、命令コード化モジュール２０など）は、任意の数のソフトウェア及び／又はハードウェア・モジュール又はユニットの任意の組合せによって実装することができ、プロセッサ１５による実行のためにサーバ及び／又はクライアント・システムのメモリ３５内に常駐することができる。この点に関して、後述のように、復元モジュール１６は、復元を行い、命令コード化モジュール２０は、結果の復元データを生成する自己復元のための命令を第２の辞書に挿入する。

本発明の実施形態により復元モジュール１６及び命令コード化モジュール２０が（例えば、サーバ・システム１０及び／又はクライアント・システム１４を介して）予備拡張及び復元を行う方法を、図２及び図３に示す。図２は、予備拡張の例示的なプロセスを示し、一方、図３は、復元プロセスを示す。

具体的には、図２を参照すると、ステップ２００においてＺｉｖ−Ｌｅｍｐｅｌ圧縮が行われ、圧縮データセット及び関連付けられた復元辞書が生成される。得られた圧縮データセットは、コードのアレイ（元データを置換する）と、関連付けられた復元辞書とを含むことができ、この復元辞書は、コードのアレイに対してマッピングするか又は組合せトークン及び辞書アレイを提供する。復元辞書は、元データ由来のデータセグメントの圧縮トークンの拡張及び復元バージョンを収容し、ここで、後述のように、トークンの復元バージョンがアドレス指定スキームによって連鎖されて復元データセグメントを形成する。圧縮２００は、伝統的なＺｉｖ−Ｌｅｍｐｅｌ技術及び／又は本明細書で説明する技術によってさらなる効率をもたらす修正された技術を用いて行うことができる。圧縮データセットの復元は、ステップ２１０において開始され（例えば復元モジュール１６によって行われる）、第２の修正された復元辞書を生成する。元の復元辞書及び第２の修正復元辞書の両方を、端末装置の能力、又はシステム規則若しくは要件に従って、復元のために格納することができる。

データセットの圧縮中に圧縮されるデータセグメントの各トークンに対して、ステップ２２０においてトークンを処理して復元データが生成される。一例のＺｉｖ−Ｌｅｍｐｅｌ復元を後で詳細に提示する。後述の例において、圧縮されたエントリは、１２ビットでコード化され（例えば、３つの４ビット１６進法ニブルとして）、これを用いて対応する８バイト（６４ビット）拡張が圧縮トークンに対して誘導され、ここで拡張データセグメント（複数のトークンを有する）は、２９バイト又は文字を含み、これは文字列と呼ばれることもある（例えば、２９文字拡張文字列）。この例において復元のために用いられるメモリ位置は、メモリアドレス０１４９＿６４３９３０１４ｘにて開始し、ここで「ｘ」は１６進法（基数１６）表示を示し、この場合、各桁は４ビット（例えば、０−Ｆｘ）であり、メモリ位置はバイト（８ビット）の量に関して表される。例として、復元辞書は、アドレス００００００４８＿Ｂ６Ｃ８８０００ｘにてメモリ内にロードされる。例示的な圧縮データの一部を以下に示し、ここで開始アドレスは左側にあり、４つの後続のメモリ位置の内容（例えば、各々が３２ビット又は４バイトを含む）が各アドレスの右側にある。

アドレス０１４９＿６４３９３０１４ｘで始まる最初の６バイトはヘッダであり、この場合、値は０４００２００１ＣＢ０１ｘであり、上記で点線の下線が付されている。ヘッダの後の次の１２ビットである４１ＥＸは、第１のトークンに対する１２ビットコード（実線下線）であり、本質的に復元辞書へのポインタである。８バイト拡張を用いると、復元辞書へのメモリ・オフセットに８が掛けられる（すなわち、４１Ｅｘ×８、又は２０Ｆ０ｘ）。この値を復元辞書開始位置である４８＿Ｂ６Ｃ８８０００ｘ（先導するゼロは省略される）に加算して、２０Ｆ０ｘ＋４８Ｂ６０Ｃ８０００ｘ＝４８Ｂ６０ＣＡ０Ｆ０ｘを得る。この位置での例示的な復元辞書データを以下に示し、ここで開始アドレスは左側にあり、４つのメモリストアが各アドレスの右側にある。

８バイト・トークン拡張がこのアドレスに存在し、下線が付されている（後の２つのメモリ位置内のデータは、この例には関係しない）。トークン拡張は、１６進数「Ａ」で開始し、１２ビット拡張アドレス４１９ｘが続き、５バイト（４０ビット）の未圧縮データ００３０００３０００ｘが続く。従って、この例のトークンは、未圧縮データを収容するのみならず、メタデータ（すなわち、４ビット命令「Ａ」及び拡張アドレス）も収容する。今までのところ、拡張データセグメント内の未圧縮データは、トークンの値又は００３０００３０００ｘである。規約により、トークン拡張の最初の４ビットがゼロではなく値Ａであるので、データセグメント拡張は不完全であるとみなされ、４１９ｘアドレスの１２ビット拡張を用いてデータセグメントの拡張が続けられる。復元辞書への次のメモリ・オフセットは、４１９ｘ×８、又は２０Ｃ８ｘである。この値を復元辞書開始位置である４８＿Ｂ６Ｃ８８０００ｘに加算して、２０Ｃ８ｘ＋４８Ｂ６０Ｃ８０００ｘ＝４８Ｂ６０ＣＡ０Ｃ８ｘを得る。そのメモリ位置における復元辞書データは、例えば、

とすることができる。

データセグメント内の次のトークンに対する８バイト・トークン拡張がこのアドレスに存在する。トークン拡張は、１６進数「Ａ」で開始し、１２ビット拡張アドレス４１４ｓが続き、このトークンに対する５バイトの未圧縮データ３４００３１００３０ｘが続く。このデータは、拡張データセグメント内の未圧縮データと連結される。今までのところ、拡張データセグメント内の未圧縮データは、３４００３１００３０００３０００３０００ｘである。このトークン拡張の最初の４ビットがゼロではないので、拡張は継続し、４１４ｘアドレスの１２ビット拡張を用いて、上述の方式で新たなアドレス４８Ｂ６０ＣＡ０Ａ０ｘが生成される。そのメモリ位置における復元辞書データは、例えば、

とすることができる。

次のトークンに対する８バイト・トークン拡張がこのアドレスに存在する。トークン拡張は、１６進数「Ａ」で開始し、１２ビット拡張アドレス４１４ｘが続き、５バイトの未圧縮データ０５００００６０００ｘが続く。このデータは、拡張データセグメント内の未圧縮データと連結される。今までのところ、拡張データセグメント内の未圧縮データは、０５００００６０００３４００３１００３０００３０００３０００ｘである。プロセスは、後続の８バイト・トークン拡張の最初の４ビットがゼロになるまで、後続のトークに対して継続する。例として、第４回目から第６回目までの拡張の繰返しは、以下のトークンを与える。

この例において、第６回目の繰返しにより、８バイトトークン拡張の最初の４ビットがゼロになり（下線）、それにより、このデータセグメントに対する拡張が完了したことが示される。次の桁はアドレスではないが４の値（下線）であり、これは４バイトのデータが残っていることを示す。この例において、４バイトは００１２００１８ｘ（下線）である。このデータセグメントに対する最終的な連結された又は拡張された値は、以下の例を用いて表される。
４１Ｅｘ＝００１２００１８３Ｅ００４０００４２００２Ｃ００３Ｃ００００５０００６０００３４００３１００３０００３０００３０００ｘ

データセグメントに対する拡張は、第２の修正復元辞書内に格納され、初期トークン拡張内のメモリ位置に基づいて取り出すことができる。上記の例に関して、第１回目の繰返しに由来する元のメモリ位置である４１Ｅｘを、第２の修正復元辞書内の拡張データセグメントに対するデータエントリ点として用いることができる。換言すれば、第２の修正復元辞書は、基本的に、拡張データセグメントを取り出すためのルックアップ・テーブルとして動作する。プロセスは、ステップ２３０において復元辞書内の全てのデータセグメント（及びトークン）が拡張されて第２の修正復元辞書内に格納されるまで続く。

上記のデータセグメントは、既知の長さ２９バイトを有する。圧縮効率を達成するために、復元を行うときに各データセグメント又はトークンを１回より多く用いることができる。データセグメントを復元するために、第２の復元辞書内の拡張データセグメントを上述の方式と同じ方式で連結することができる。

復元されたデータセグメントを提供するために、ステップ２３５において、１つ又は複数の命令を生成し、第２の修正復元辞書内に格納することができる（例えば、命令コード化モジュール２０によって行われる）。一例において、ステップ２３５において、ムーブ（又はコピー）命令を生成して格納することができる。ムーブ命令は、データを１つのメモリ位置から別の位置へ移動させる。例えば、復元辞書内の復元データセグメントは、復元データセグメントを一緒に共通ストレージ領域内へ移動することによって連結される。

例示的なムーブ命令を、以下、アセンブリ又はアセンブラ言語（例えば、３６０アセンブリ又はｘ８６アセンブリ）に関して説明する。アセンブリ言語は、下層のプロセッサ・アーキテクチャに結びつけることができ、偽英語様コード（ｐｓｅｕｄｏ−Ｅｎｇｌｉｓｈ ｌｉｋｅ ｃｏｄｅ）を用いてプロセッサ命令を表す。実行速度のために、多くのコンピュータ・コンパイラ及び処理サブルーチンは、アセンブリ言語で記述されている。従って、以下のコード例によって説明される論理を、処理プラットフォームに適合させることができる。一例において、アセンブリ言語命令ムーブ・キャラクタ（ＭＶＣ）は、ステップ２３５において、第２の修正復元辞書内の各復元データセグメントの位置に隣接した位置（メモリ内又はディスク上）に配置され又は格納される。コンピューティング環境に応じて、その他の命令コードを用いてデータをコピー又は移動することができる（例えば、ＭＶＩ、ＭＨＨＶＩ、ＭＯＶなど）。例示的なＭＶＣ命令を以下に示す。

第１の例のＭＶＣ命令は、データ（例えば、文字）をソース・ストレージ位置からターゲット・ストレージ位置へ移動させる。ソース及びターゲット・メモリ位置は、コンピュータ・プログラム内で定義することができる。第２の例のＭＶＣ命令は、４０データ要素（例えば、文字）をソース・ストレージ位置からターゲット・ストレージ位置へ移動させる。ＭＶＣ命令は、上限２５６データ要素（例えば、文字）までの移動を規定しており、これにより、データセグメントを連結して最終的に復元データセットを生成することが可能になる。この例において、ＴＡＲＧＥＴは、上述の共通ストレージ位置とすることができ、ＳＯＵＲＣＥは、第２の修正復元辞書内の復元データセグメント（例えば、復元モジュール１６によって生成される）とすることができる。

この例では、ステップ２３５において、第２の修正復元辞書内の復元データセグメントに隣接して配置された各ＭＶＣ命令のメモリ位置又は相対メモリ位置もまた、分離した命令ジャンプ・テーブル内に格納される。上記の例の２９バイト又は文字のデータセグメントを、対応するＭＶＣ命令（ＭＶＣ ＴＡＲＧＥＴ（２９），ＳＯＵＲＣＥ）によって移動させることができる。命令ジャンプ・テーブルは、圧縮データの第１回目の繰返しの復元を考慮したものである。

さらに明確にするために、第１のトークンを繰返し処理して、第１の拡張データセグメントを生成する。第１の拡張データセグメント（例えば、２９バイト文字列）及びＭＶＣ命令（又はその表現）は、第２の修正復元辞書内に格納される。第１のトークン及びゼロのメモリ・オフセット（すなわち、第１のエントリに対してゼロ）は、ジャンプ・テーブル内に格納される。メモリ・オフセットを、第２の修正復元辞書に格納されるような文字列の長さ及びＭＶＣ命令に適応させるために、現在のオフセットへ前進させる。次の（又は第２の）トークンを繰返し処理して、第２の拡張文字列を生成する。第２のトークン及び現在のメモリ・オフセットが、次のエントリとしてジャンプ・テーブル内に格納される。メモリ・オフセットを、第２の文字列の長さ及びＭＶＣ命令に適応するように前進させ、プロセスは、トークン処理が完了するまで続く。

従って、ジャンプ・テーブルは、トークンのリストと、対応する第２の修正復元辞書へのポインタ又はメモリアドレス・オフセットとを有し、ここでポインタは、本来的に拡張文字列長（すなわち、オフセットの前進による）を説明するものである。それゆえ、ＭＶＣ命令に対するソースアドレスは、ジャンプ・テーブルによって入手可能であり、一方、ターゲットアドレスは、ＭＶＣ命令に対する指定ターゲットアドレスを提供する制御ソフトウェアにより提供される。ジャンプ・テーブル内のエントリを処理することで、一連の拡張文字列の効率的な連結が可能になる。第２の修正復元辞書を復元するための例示的なアセンブリ言語のサンプルを以下に示し、図３に関連して説明する。コード・サンプルは、上述のように生成されたジャンプ・テーブルを含む。

全てのデータセグメント又は所与の数のデータセグメントが既に拡張されたか否かをステップ２４０で判定する。全てのデータセグメントが拡張されていない場合、プロセスはステップ２２０において繰り返される。そうでない場合には、プロセスは２４５において継続し、図３に進む。この時点で、圧縮データセット内のデータセグメントの予備拡張が完了する。データセットの復元は、後の時点で、元のソースデータが取り出されるときに行うことができる。

第２の修正復元辞書を復元のために利用する方法を、図３に関連して説明する。復元プロセスは、２５０において図２から継続することができ、又は元のソースデータが要求されたときに行うことができる（例えば、復元モジュール１６により）。復元は、ステップ２５５において開始する。ステップ２６０において、データセグメントの初期トークンが圧縮データから得られる。トークンは、第２の修正復元辞書へのポインタを含むことができる（例えば、上述の４１Ｅｘ）。ステップ２７０において、対応する拡張の命令が実行される。図２に関連して上述したジャンプ・テーブルの例を続けると、対応する又は第１のＭＶＣ命令が、ジャンプ・テーブル内で位置探索され、実行される。アセンブリコードセグメントを以下にリストとして示し、これはジャンプ・テーブルと例示的な修正復元辞書とを有する。

以下のコードは、予備拡張データベーステーブルの列又はレコード内のデータに対して全ての１２ビットコード化エントリを処理する。このコード・サンプルは、３１ビットアドレス指定を使用するが、４８ビット、６４ビット、又は本明細書で提示するような３１ビットアドレス指定コードと同様の論理を用いるその他の任意の適切な既存の又は将来的なコード化スキームを使用することができる。コード・サンプルの上部分は、予備拡張データセグメントを連結する例示的なコードを含む。下部分は、ジャンプ・テーブル及び予備拡張辞書エントリを含む辞書エントリ又は「ＤＩＣＴＥＮＴＳ」で始まる。ＤＩＣＴＥＮＴＳコード及びデータは、以前に予備拡張されて第２の修正復元辞書内に格納された（例えば、図２に関連して説明したように行われる動作の結果として）拡張辞書の結果とすることができる。ＤＩＣＴＥＮＴＳラベル付きコード（例えば、ＥＮＴラベル）、及びアセンブリ言語コード（例えばＭＯＶラベル）を有する辞書エントリは、上部コードセグメントの実行又はインスタンス化に先立ってメモリ内にロードされる。拡張コード及び辞書エントリは、メモリの異なる領域内に常駐することができ、これを以下にリストとして示す。
＊Ｒ０は、処理するための１２ビット辞書エントリのカウントを収容する
＊Ｒ１は、次の圧縮列バイト（ソース）を指示する
＊Ｒ３は、ターゲット（拡張）データを指示する
＊Ｒ９は、生成された辞書情報（「ＤＩＣＴＥＮＴＳ」）を指示する

上記ＤＩＣＴＥＮＴＳコード及びデータは、０００ｘからＦＦＦｘ（すなわちＥＮＴ０００−ＥＮＴＦＦＦ）まで列挙されるエントリ「ＥＮＴ」ラベルを伴うジャンプ・テーブルである。０００ｘからＦＦＦｘまでのＥＮＴ列挙値は、１２ビット拡張によって提供される全ての可能な値（順列）を表す。ラベルは、アセンブリ言語コードにおいて、プログラマ（及びアセンブリ言語コンパイラ）がそのラベルに関連付けられるコードの１つ又は複数の行を定義することを可能にする擬英語構文として用いられる。各ＥＮＴラベルは、対応するムーブ「ＭＯＶ」ラベルを有する。ジャンプ・テーブル内のＥＮＴエントリが処理されるときに、対応するＭＯＶコードが実行される。例えば、ラベルＥＮＴＦＦＥは、ラベルＭＯＶＦＦＥを指示する。そしてまたＭＯＶＦＦＥは、１０２バイトの予備拡張（未圧縮）データを第１の１２ビット拡張からレジスタＲ３によって指示されるターゲットアドレス（このターゲットアドレスは、呼出しソフトウェアによって提供することができる）へ移動する命令（例えば、これはＭＶＣ命令を含む）を有する。ＭＶＣ命令の次は、ロードアドレス「ＬＡ」命令であり、これは、Ｒ３レジスタ内のターゲットアドレスを１０２だけインクリメントする又は前進させる。次のエントリＥＮＴＦＦＦは、ＭＯＶＦＦＦを指示し、これは、１０３バイトのデータを第２の１２ビット拡張から、既に１０２だけインクリメントされたＲ３によって指示されるターゲットアドレスへ移動する命令を有する。各予備拡張データセグメントの長さは、異なる修正拡張辞書間で変化し得る。

ＭＯＶラベルに関連付けられたアセンブリ言語命令の実行後、プログラムは次の命令のためにジャンプ・テーブルへ戻る。ＭＶＣ命令の代わりに、第２の修正復元辞書へのポインタがジャンプ・テーブル内に格納される。第２の修正復元辞書は、ＭＶＣ命令を収容し、ＭＶＣ命令の終了後、プログラムは、次のポインタのためにジャンプ・テーブルへ戻る。全てのデータセグメントが既に処理されたか否かをステップ２７５で判定する。一例において、ジャンプ・テーブル内の最後のエントリは、主呼出し（復元）プログラムへ戻る戻り命令を収容する。否であれば、プロセスは、ステップ２６０へ戻る。そうでなければ、プロセスは、ステップ２８０において終了する。

命令の生成及び格納（例えば、ステップ２３５において命令コード化モジュール２０により）並びにこれらの命令の取得及び実行（例えば、ステップ２７０において復元モジュール１６により）の幾つかの変形例をここで説明する。第１の例において、ＭＶＣ命令をジャンプ・テーブル内に格納する代わりに、ＭＶＣ命令及び任意の所与の復元文字列の長さが、第２の修正復元辞書内の各復元データセグメントの隣に格納される（例えば、ステップ２３５において命令コード化モジュール２０により）。次いで、各復元文字列を予備バイトでパディングして、固定長の復元データセグメントを得る。パディング・バイトは、拡張文字列の一部ではないが、指定された固定長を得るために用いられるものであり、何らかの特定の情報で埋める必要はない。従って、第２の修正復元辞書内の各エントリは、ＭＶＣ命令、拡張データセグメント、及びパディング（例えば、２５６バイトの固定長を達成するための）を含むことができる。

この第１の変形例は、固定長アドレス指定を用いることができるので、ジャンプ論理を簡略化することができるという利点を有する。例えば、復元中に、復元のために用いられる１２ビット値を用いて、この１２ビット値に、パディングされたエントリのサイズを掛けることにより、復元辞書へ直接に索引付けすることができる。ひとたびこの復元辞書内の位置へ分岐されると、データセグメント長が得られ、復元データセグメントが連結のために移動される（例えば、ステップ２７０において復元モジュール１６により）。

第２の変形例において、ＭＶＣ命令は、ジャンプ・テーブルの代わりに命令アレイ内に格納される。ひとたび各復元データセグメントが構築されると、ＭＶＣ命令は、命令アレイ内に挿入される（例えば、ステップ２３５において命令コード化モジュール２０により）。この技術が使用される場合、ＭＶＣ命令のみが命令アレイ内に格納され、主（呼出し）アプリケーションは、ＭＶＣアレイへと分岐する。命令アレイ内のＭＶＣとデータセグメントとを、第２の復元辞書内の別々のストレージ・セクション又はパーティション内に格納することができる。命令アレイとデータセグメントとが別々に格納されるので（すなわち、命令アレイはデータセグメントと混ざらない）、メモリ内にロードするときに、ＭＶＣ命令アレイをキャッシュメモリ（例えば、命令キャッシュ）内にロードすることができ、データセグメントを分離したメモリ（例えば、ＲＡＭ、データキャッシュなど）にロードすることができる。従って、命令アレイ技術は、キャッシュ構造（例えば、命令キャッシュ、データキャッシュなど）を利用することができる。復元中に、命令アレイ内のＭＶＣ命令が繰返し実行され、データセグメントを連結のために移動させる（例えば、ステップ２７０において復元モジュール１６により）。

第３の変形例において、継続論理がＭＶＣ命令と共に命令アレイ内に格納される（例えば、ステップ２３５において命令コード化モジュール２０により）。復元中に、アレイ内のＭＶＣ命令が連結のために実行され、継続命令がチェックされる（例えば、ステップ２７０において復元モジュール１６により）。さらなるＭＶＣ命令が残っていると継続論理が判断した場合、継続論理は、次のＭＶＣ命令を実行する。そうでない場合、復元は完了する。上記の例を通じて、復元を単一の呼出しで行うことができ、復元は自己実行され、それにより自己復元データセグメントが可能になる。換言すれば、このアルゴリズムは、全てのデータセグメントを、主呼出しアプリケーションに戻る前に結合する。

要約すれば、本発明の実施形態において、一連のムーブ命令が、全ての予備拡張データセグメントが連結されるまで繰返し実行され、これにより、圧縮（例えば、Ｚｉｖ−Ｌｅｍｐｅｌ圧縮）に用いられた元のデータセットがもたらされる。上記の例において、単に最初の２９バイトデータセグメントを得るために何回かの繰返しを行っていた。しかしながら、これらの繰返しは、本発明の実施形態によって、図３に関連して説明した復元（例えば、復元モジュール１６によって行われるような）中に実行する必要はない。伝統的なＬＺ復元と本発明の実施形態とを比較評価すると、経過時間及びＣＰＵ処理オーバーヘッドにおいてそれぞれ４３％及び８１％の削減が示された。

上で説明し図面に示した実施形態は、復元中ステップ２７０においての処理効率を高めるために予備拡張された自己復元する文字列を利用するデータ復元に関する実施形態を実装する多くの方法のうちのごく少数を表したに過ぎないことが認識されるであろう。

本発明の実施形態の環境は、任意の所望の様式で配置された、任意の数のコンピュータ又はその他の処理システム（例えば、クライアント又はエンドユーザ・システム１４、サーバ・システム１０など）及びデータベース又は他のリポジトリを含むことができ、本発明の実施形態は、任意の所望のタイプのコンピューティング環境（例えば、クラウド・コンピューティング、クライアント−サーバ、ネットワーク・コンピューティング、メインフレーム、独立型システムなど）に適用することができる。本発明の実施形態で使用されるコンピュータ又はその他の処理システムは、任意の数の任意のパーソナル型又はその他の型式のコンピュータ又は処理システム（例えば、デスクトップ、ラップトップ、ＰＤＡ、移動体装置など）によって実装することができ、任意の市販のオペレーティングシステム並びに市販のソフトウェア及びカスタム・ソフトウェア（例えば、ブラウザ・ソフトウェア、通信ソフトウェア、サーバ・ソフトウェア、文字列復元モジュール１６、命令コード化モジュール２０など）の任意の組合せを含むことができる。これらのシステムは、情報の入力及び／又は閲覧のために任意の型式のモニタ及び入力装置（例えば、キーボード、マウス、音声認識など）を含むことができる。

本発明の実施形態のソフトウェア（例えば、文字列復元モジュール１６、命令コード化モジュール２０など）は、任意の所望のコンピュータ言語で実装することができ、本明細書に含まれる機能的説明及び図面に示されたフローチャートに基づいてコンピュータ分野の当業者が開発することができるであろうことを理解されたい。さらに、本明細書における種々の機能を実行するソフトウェアへのいかなる言及も、一般に、ソフトウェア制御下でこれらの機能を実行するコンピュータ・システム又はプロセッサに言及するものとする。本発明の実施形態のコンピュータ・システムは、任意の型式のハードウェア及び／又はその他の処理回路によって代替的に実装することができる。

コンピュータ又はその他の処理システムの種々の機能は、任意の数のソフトウェア及び／又はハードウェア・モジュール又はユニット、処理又はコンピュータ・システム及び／又は回路間で、任意の方式で分散させることができ、ここでコンピュータ又は処理システムは、互いにローカルに又は遠隔に配置することができ、任意の適切な通信媒体（例えば、ＬＡＮ、ＷＡＮ、イントラネット、インターネット、配線、モデム接続、無線など）を介して通信することができる。例えば、本発明の実施形態の機能は、種々のエンドユーザ／クライアント及びサーバ・システム、及び／又は任意のその他の中間処理装置間で、任意の方式で分散させることができる。上で説明されフローチャートに示されたソフトウェア及び／又はアルゴリズムは、本明細書で説明される機能を達成する任意の方式で修正することができる。さらに、フローチャート又は説明内の機能は、所望の動作を達成する任意の順序で行うことができる。

本発明の実施形態のソフトウェア（例えば、文字列復元モジュール１６、命令コード化モジュール２０など）は、独立型システム又はネットワーク若しくはその他の通信媒体によって接続されるシステムと共に使用するための固定型又は携帯型プログラム製品機器又は装置の非一時的なコンピュータ可読媒体又は使用可能媒体（例えば、磁気又は光学媒体、光磁気媒体、フロッピーディスケット、ＣＤ−ＲＯＭ、ＤＶＤ、メモリ装置など）上で利用可能なものとすることができる。

通信ネットワークは、任意の数の任意の型式の通信ネットワーク（例えば、ＬＡＮ、ＷＡＮ、インターネット、イントラネット、ＶＰＮなど）によって実装することができる。本発明の実施形態のコンピュータ又はその他の処理システムは、任意の従来の又はその他のプロトコルを介してネットワーク上で通信する任意の従来の又はその他の通信装置を含むことができる。コンピュータ又はその他の処理システムは、ネットワークへのアクセスのための任意の型式の接続（例えば、有線、無線など）を利用することができる。ローカル通信媒体は、任意の適切な通信媒体（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、配線、無線リンク、イントラネットなど）によって実装することができる。

システムは、情報（例えば、拡張辞書、圧縮データなど）を格納するために、任意の数の任意の従来の又はその他のデータベース、データストア又はストレージ構造（例えば、ファイル、データベース、データ構造、データ又その他のリポジトリなど）を使用することができる。データベース・システムは、情報（例えば、拡張辞書、圧縮データなど）を格納するために、任意の数の任意の従来の又はその他のデータベース、データストア又はストレージ構造（例えば、ファイル、データベース、データ構造、データ又その他のリポジトリなど）によって実装することができる。データベース・システムは、サーバ及び／又はクライアント・システム内に含まれるか又はこれに結合されるものとすることができる。データベース・システム及び／又はストレージ構造は、コンピュータ又はその他の処理システムの遠隔又はローカルにあるものとすることができ、任意の所望のデータ（例えば、拡張辞書、圧縮データなど）を格納することができる。

本発明の実施形態は、情報（例えば、予備拡張命令、データ検索、レポートなど）を取得する又は提供するために、任意の数の任意の型式のユーザ・インタフェース（例えば、グラフィカル・ユーザ・インタフェース（ＧＵＩ）、コマンドライン、プロンプトなど）を使用することができ、ここでインタフェースは、任意の様式で配置された任意の情報を含むことができる。インタフェースは、任意の適切な入力装置（例えば、マウス、キーボードなど）を介して情報を入力／表示し、及び所望の動作を開始するために、任意の位置に配置された任意の数の任意の型式の入力又は作動機構（例えば、ボタン、アイコン、フィールド、ボックス、リンクなど）を含むことができる。インタフェース・スクリーンは、スクリーン間で任意の様式でナビゲートするために、任意の適切なアクチュエータ（例えば、リンク、タブなど）を含むことができる。

レポートは、任意の様式で配置された任意の情報を含むことができ、所望の情報（例えば、圧縮効率、予備拡張効率、完全復元中のＣＰＵ使用量など）をユーザに提供するために規則又はその他の基準に基づいて構成可能なものとすることができる。

本発明の実施形態は、上述の特定のタスク又はアルゴリズムに限定されないが、圧縮データの予備拡張のために利用することができる。データは、Ｚｉｖ−Ｌｅｍｐｅｌに基づく技術を含むがこれに限定されない、任意の損失なし圧縮技術によって圧縮することができる。

任意の数及び型式の復元（又は拡張）辞書を使用し格納することができる。拡張辞書は、復元中の処理効率を向上させるために、基礎をなすデータを完全に又は部分的に復元した任意の型式の予備拡張を含むことができる。

予備拡張辞書内に格納される命令は、拡張中のデータの連結を可能にする任意の形態のものとすることができる（例えば、ムーブ、コピー、ＭＶＣ命令など）。連結命令を予備拡張文字列長と共に用いて、正しい文字列長を得ることができる。予備拡張文字列は、任意の所望の長さを得るためにパディングを含むことができる。連結命令、文字列長などは、復元辞書内に格納することもでき、又は分離したジャンプ・テーブル若しくは命令テーブルとして格納することもできる。連結命令は、継続論理、又は命令の継続実行を可能にする若しくは任意の所望のコード分岐又はジャンプを可能にするその他の命令を含むことができ、また、所望の処理特性（例えば、辞書拡張時間、ＣＰＵ利用率など）を得るための単一の関数呼出し又は複数の呼出しを伴うデータ拡張を考慮に入れたものとすることができる。

圧縮データエントリは、任意の所望の長さ（例えば、８ビット、１２ビットなど）のものとすることができ、圧縮され及び予備拡張されたデータを拡張するために任意の形態のアドレス指定を含むことができる。拡張トークンは、任意の所望の長さ（例えば、８バイト、１６バイトなど）のものとすることができ、任意の所望のメタデータ（例えば、継続命令、停止命令、拡張アドレスなど）を含むことができる。拡張データセットは、復元プロセスを補助する任意の所望の命令（例えば、ムーブ、コピー、継続命令など）を含むことができる。任意の形態のキャッシュ構造を使用し又は活用して、予備拡張、拡張、命令ストレージを容易にすることができる（例えば、ジャンプ・テーブル、命令キャッシュ、一時的ストレージ、命令オペランドなど）。

本明細書で用いられる用語は、特定の実施形態を説明するためのものにすぎず、本発明を限定することを意図したものではない。本明細書で用いられる場合、単数形「１つの（a）」、「１つの（an）」及び「その（the）」は、文脈が明らかにそうでないことを示さない限り、複数形も同様に含むことを意図したものである。「含む（comprise）」、「含んでいる（comprising）」、「含む（includes)」、「含んでいる（including）」、「有する（has、have）」、「有している（having）」、「伴う（with）」及び同様の用語は、本明細書で用いられる場合、記述された特徴、整数、ステップ、動作、要素、及び／又はコンポーネントの存在を指定するが、１つ又は複数のその他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの群の存在又は付加を排除するものではないことがさらに理解されるであろう。

以下の特許請求の範囲における全ての「手段又はステップと機能との組み合わせ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作、及び均等物は、その機能を、明確に特許請求された他の請求要素との組み合わせで実行するためのあらゆる構造、材料、又は動作を含むことが意図されている。本発明の説明は、例証及び説明を目的として提示されたものであり、網羅的であること又は本発明を開示された形態に限定することを意図したものではない。本発明の範囲及び趣旨から逸脱しない多くの修正及び変形が当業者には明らかとなるであろう。実施形態は、本発明の原理及び実際の用途を最も良く説明するために、そして、当業者が、企図した特定の用途に適した種々の修正を伴う種々の実施形態に関して本発明を理解できるように、選択及び説明したものである。

本発明の種々の実施形態の説明を例証のために提示したが、これらは網羅的であること又は開示された実施形態に限定することを意図したものではない。当業者には、説明した実施形態の範囲及び趣旨から逸脱しない多くの修正及び変形が明白となるであろう。本明細書で用いた用語は、実施形態の原理、実際的用途、又は市場で見いだされる技術に対する技術的改良点を最も良く説明するように、又は、当業者が本明細書で開示した実施形態を理解することができるように、選択されたものである。

当業者であれば理解するように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又はソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形を取ることができ、本明細書においてはこれらの全てを一般に「回路」、「モジュール」又は「システム」と呼ぶことができる。さらに、本発明の態様は、コンピュータ可読プログラム・コードが組み入れられた１つ又は複数のコンピュータ可読媒体内として具体化されたコンピュータ・プログラム製品の形を取ることができる。

１つ又は複数のコンピュータ可読媒体の任意の組合せを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読ストレージ媒体とすることができる。コンピュータ可読ストレージ媒体は、例えば、電子、磁気、光学、電磁気、赤外線若しくは半導体のシステム、装置、若しくはデバイス、又は上記のもののいずれかの適切な組合せとすることができる。コンピュータ可読ストレージ媒体のより具体的な例（非網羅的なリスト）として、以下のもの：即ち、１つ又は複数の配線を有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又は上記のもののいずれかの適切な組合せが挙げられる。本明細書の文脈においては、コンピュータ可読ストレージ媒体は、命令実行システム、装置若しくはデバイスによって、又はこれらと関連して用いるためのプログラムを収容又は格納することができる任意の有形媒体とすることができる。

コンピュータ可読信号媒体は、例えばベースバンド内に又は搬送波の一部として、具体化されたコンピュータ可読プログラム・コードをその中に有する、伝搬されるデータ信号を含むことができる。このような伝搬信号は、これらに限定されるものではないが、電磁気、光又はそれらのいずれかの適切な組合せを含む、種々の形態のいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ、命令実行システム、装置若しくはデバイスによって、又はこれらと関連して用いるためのプログラムを伝達し、伝搬し、又は搬送することができる任意のコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に具体化されたプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦ等、又は上記のもののいずれかの適切な組合せを含む、任意の適切な媒体を用いて伝送することができる。

本発明の態様の操作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、ＳｍａｌｌＴａｌｋ、Ｃ＋＋等のようなオブジェクト指向型プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語のような従来の手続き型プログラミング言語を含む、１つ又は複数のプログラミング言語のいずれかの組合せで記述することができる。プログラム・コードは、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。一番最後のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続が為される場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。

本発明の態様は、以下、本発明の実施形態による方法、システム及び／又はコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組合せは、コンピュータ・プログラム命令によって実装することができることが理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロック内で指定された機能／動作を実装するための手段を作り出すようにすることができる。

これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装する命令を含む製品を製造するようにすることもできる。

コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生成し、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにすることもできる。

図面内のフローチャート及びブロック図は、本発明の種々の実施形態による、システム、方法、及びコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に記された機能は、図中に記された順序とは異なる順序で生じることがあることにも留意されたい。例えば、連続して示された２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、及びブロック図及び／又はフローチャート図中のブロックの組合せは、指定された機能又は動作を実行する専用ハードウェア・ベースのシステム、又は専用のハードウェアとコンピュータ命令との組合せによって実装することができることにも留意されたい。

１０：サーバ・システム
１４：クライアント・システム

Claims (10)

1. コンピュータによって実行される、圧縮データを復元するための方法であって、
   第１の復元辞書を解析するステップであって、前記第１の復元辞書は、アドレス指定スキームに基づいて前記第１の復元辞書内に非連続方式で分散された未圧縮データ部分を各々が有する複数の連鎖を含み、ここで各連鎖の前記未圧縮データ部分は、圧縮データの対応する未圧縮バージョンを形成する、第１の復元辞書を解析するステップと、
   前記第１の復元辞書内の前記連鎖の各々の前記未圧縮データ部分を組み合わせて圧縮データの未圧縮バージョンを形成するステップにより第２の復元辞書を生成し、圧縮データを復元するための命令を前記第２の復元辞書内に挿入するステップと、
   圧縮データを前記第２の復元辞書に適用することにより、前記圧縮データを復元するステップと、
   を含む、コンピュータによって実行される方法。
2. 前記圧縮データが、Ｚｉｖ Ｌｅｍｐｅｌ圧縮スキームに従って圧縮されている、請求項１に記載のコンピュータによって実行される方法。
3. 前記第２の復元辞書内の前記命令が、前記圧縮データの単一のトークンを一回の移動で
   復元する命令を含む、請求項１に記載のコンピュータによって実行される方法。
4. 前記第２の復元辞書内の前記命令が、前記圧縮データの全てのトークンを一回の呼出しで復元する命令を含む、請求項１に記載のコンピュータによって実行される方法。
5. 前記第２の復元辞書内の前記命令が、コンピュータ・アーキテクチャから独立したものである、請求項１に記載のコンピュータによって実行される方法。
6. 前記命令と未圧縮バージョンとが一緒に前記第２の復元辞書内に存在し、キャッシュ構造を利用する、請求項１に記載のコンピュータによって実行される方法。
7. 前記第２の復元辞書内の前記命令が、前記圧縮データの未圧縮バージョンを連結するムーブ命令、前記圧縮データの未圧縮バージョンに関連付けられた長さ、及び継続命令のうちの１つ又は複数を含む、請求項１に記載のコンピュータによって実行される方法。
8. 第１の復元辞書を解析し、前記第１の復元辞書は、アドレス指定スキームに基づいて前記第１の復元辞書内に非連続方式で分散された未圧縮データ部分を各々が有する複数の連鎖を含み、ここで各連鎖の前記未圧縮データ部分は、圧縮データの対応する未圧縮バージョンを形成し、
   前記第１の復元辞書内の前記連鎖の各々の前記未圧縮データ部分を組み合わせて圧縮データの未圧縮バージョンを形成することにより前記第２の復元辞書を生成し、圧縮データを復元するための命令を前記第２の復元辞書内に命令を挿入し、
   圧縮データを前記第２の復元辞書に適用することにより、前記圧縮データを復元する、
   ように構成された少なくとも１つのプロセッサを含むコンピュータ・システムを含む、
   システム。
9. 請求項１〜７の何れか１項に記載の方法の各ステップを、コンピュータに実行させる、コンピュータ・プログラム。
10. 請求項９記載の前記コンピュータ・プログラムをコンピュータ可読ストレージ媒体に記録した、コンピュータ可読ストレージ媒体。
    

Images