(57)【要約】【課題】部分符号データであっても階層構造を踏まえて容易に照合することができる画像処理装置を提供する。【解決手段】この画像処理装置は、階層符号データを構成する符号列単位でキャッシュに保存し、該キャッシュに保存された符号列を符号データの階層構造に基づいて並び替え、前記符号列を並び替えた符号列群を使用して別の符号データと照合（比較）する。【選択図】図８
2007043544.tif 000002
【特許請求の範囲】
【請求項１】
階層符号データを構成する符号列単位で保存するキャッシュを備え、該キャッシュに保存された符号列を符号データの階層構造に基づいて並び替える符号列並び替え手段と、前記符号列を並び替えた符号列群を使用して別の符号データと照合（比較）する符号データ照合手段を有することを特徴とする画像処理装置。
【請求項２】
請求項１に記載の画像処理装置において、前記キャッシュ上の符号列を使用して符号列の構造を推定するキャッシュ上の符号データ構造推定手段を有し、前記推定された階層構造に基づいて前記符号データの構造単位でキャッシュ上の符号列を並び替えることを特徴とする画像処理装置。
【請求項３】
請求項２に記載の画像処理装置において、照合する単位が階層レベル単位であることを特徴とする画像処理装置。
【請求項４】
請求項２または３に記載の画像処理装置において、前記照合は、前記符号データに含まれる符号列の長さ（パケット長）を使用することを特徴とする画像処理装置。
【請求項５】
請求項２または３に記載の画像処理装置において、前記照合は、階層符号データの階層数によって比較することを特徴とする画像処理装置。
【請求項６】
請求項２または３に記載の画像処理装置において、前記照合は、前記階層符号データの階層毎の階層レベル数によって比較することを特徴とする画像処理装置。
【請求項７】
請求項１乃至６のいずれかに記載の画像処理装置において、照合対象の符号データを構成する符号列の順番とキャッシュに保存されている符号列の順番とが同一であるように符号データを該キャッシュに保存する手段を有することを特徴とする画像処理装置。
【請求項８】
請求項７に記載の画像処理装置において、記憶装置を備え、該記憶装置と前記キャッシュには符号データがパケット単位（最小符号列単位）で保存され、照合対象の符号データと該キャッシュに保存された符号データが最小符号列単位で同じ保存位置（先頭アドレスから同じメモリロケーション位置）にあるかどうかを判定する判定手段を有し、前記判定手段を使用して符号データ間の照合をすることを特徴とする画像処理装置。
【請求項９】
請求項１乃至８のいずれかに記載の画像処理装置において、パケット単位（最小符号列単位）の照合対象の符号データとキャッシュにパケット単位で保存された符号データと同じ保存順位にある前記パケットが一致するかどうかを判定する判定手段を有し、前記判定手段を使用して符号データ間の照合をすることを特徴とする画像処理装置。
【請求項１０】
請求項９に記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データの同じ保存位置（先頭アドレスから同じメモリロケーション位置）の範囲を指定して該範囲にある符号データの照合をすることを特徴とする画像処理装置。
【請求項１１】
請求項１０に記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データの同じ保存順の範囲を指定して、該範囲にある符号データの照合をすることを特徴とする画像処理装置。
【請求項１２】
請求項１０に記載の画像処理装置において、キャッシュに保存された符号データの保存順を指定して該保存位置にある符号データの有無によって照合することを特徴とする画像処理装置。
【請求項１３】
請求項１乃至１２のいずれかに記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データは、同じ階層構成（プログレッション順）を持つことを特徴とする画像処理装置。
【請求項１４】
請求項１３に記載の画像処理装置において、キャッシュに保存された符号データの階層構造（プログレッション順）と照合対象の符号データの階層構造（プログレッション順）とを一致させることを特徴とする画像処理装置。
【請求項１５】
請求項１３または１４に記載の画像処理装置において、高頻度に使用する符号データのプログレッション順に基づいて照合する階層の選択をすることを特徴とする画像処理装置。
【請求項１６】
請求項１乃至１５のいずれかに記載の画像処理装置において、前記キャッシュの符号列から構成された符号データの階層構造が、照合対象である符号データの階層構造に基づいて変更することを特徴とする画像処理装置。
【請求項１７】
請求項１乃至１６のいずれかに記載の画像処理装置において、前記照合は、符号データの階層構造の特定の階層の符号列長の合計で比較することを特徴とする画像処理装置。
【請求項１８】
請求項１乃至１７のいずれかに記載の画像処理装置において、前記照合は、符号データの階層構造の上位階層から下位階層の符号列の符号長の合計で比較してなされ、不一致な符号列を特定することを特徴とする画像処理装置。
【請求項１９】
請求項１乃至１８のいずれかに記載の画像処理装置において、前記符号データがＪＰＥＧ２０００（ＩＳＯ／ＩＥＣ  １５４４４−１）規格に基づき符号化されたデータであることを特徴とする画像処理装置。
【請求項２０】
サーバの記憶装置に保存された符号データをクライアントが受信する符号データ転送機能を有するクライアントサーバシステムにおいて、前記クライアントは、前記受信した符号データをキャッシュに保存し再利用するキャッシュ機能を有し、請求項１乃至１９のいずれかに記載の符号データの照合を前記サーバの記憶装置上の符号データと前記キャッシュに保存された符号データ（複数符号列）との間でなされることを特徴とする画像処理システム。
【請求項２１】
サーバの記憶装置に保存された符号データをクライアントが受信する符号データ転送機能を有するクライアントサーバシステムにおいて、前記クライアントは、キャッシュに保存された符号列から推定された該符号列の符号データの構造データを前記サーバへ転送する手段を有し、前記サーバは、前記構造データを使用して、請求項１乃至１９のいずれかに記載の照合手段によって照合することを特徴とする画像処理システム。
【請求項２２】
請求項２０または２１に記載の画像処理システムにおいて、前記クライアントは、前記符号データがＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，  ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）規格に基づき、照合対象である符号データの一部である部分符号データを受信する部分符号データアクセス機能を有することを特徴とする画像処理システム。
【請求項２３】
階層符号データを構成する符号列単位でキャッシュに保存し、該キャッシュに保存された符号列を符号データの階層構造に基づいて並び替え、前記符号列を並び替えた符号列群を使用して別の符号データと照合（比較）することを特徴とする画像処理方法。
【請求項２４】
コンピュータに、請求項１乃至１９のいずれかに記載の画像処理装置の機能、または、請求項２０乃至２２のいずれかに記載の画像処理システムの機能を実現させるためのプログラム。
【請求項２５】
コンピュータが読み取り可能な記録媒体であって、請求項２４に記載のプログラムを記録したことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置、画像処理システム、画像処理方法、プログラムおよび記録媒体に関し、特に、キャッシュモデルを用いて部分画像符号化データをアクセス機能を具備する符号化処理装置を含み、ＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，  ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）の実装技術に係る。
【背景技術】
【０００２】
サーバにあるＪＰＥＧ２０００仕様に基づいて符号化された符号データをアクセスする方式としてＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）がある。その仕様には、既にクライアント側に受信された符号データは新たに転送することなく使用することで高速にアクセスできるような仕組みとして、クライアント上に符号データの一部を保存するキャッシュの機能を備えている。
【０００３】
ところで、符号データは部分符号データが断片的に転送されるため、クライアントのキャッシュに保存される符号データは、断片的な符号列である。そのため、ある画像データの全体画像を構成するものではないから、それが閲覧制限がかかった画像符号化データの一部であることで、許されるとしても、複数の断片化した符号列を集めると閲覧制限がかかった画像符号化データを構成する場合がある。
【０００４】
そのため、断片化された符号列を構成する符号データに閲覧制限がかかった画像符号化データであることを照合し特定する仕組みが必要である。しかしながら一般的には、断片化された符号列から判断することは困難であった。有価証券の偽造防止についても同様である。
【０００５】
また、ＪＰＩＰ等において、クライアント側のキャッシュ上の符号データ（符号列）とサーバ側の元符号データとの間の整合性（一致）識別を効率的に施すことが求められる。サーバ側のオリジナルの符号データの一部部分が編集されたような場合、古い部分符号データが最新のものであると間違えて使用したりする場合があるからである。そのような場合には、サーバ側で部分的な符号データの変更等があったときに、新しいデータと古いデータとの間で内容の整合性がとれなくなる。
【０００６】
ところで、符号データを保存するキャッシュに係る先願としては、特許文献１がある。特許文献１では本発明と全く異なるが、ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへ変換するＪＰＩＰに係る出願である。ＪＰＩＰの仕様には、符号データを保存するキャッシュについて規定している。
また、特許文献２は、キャッシュがタイル単位に符号データを管理し、共通の（定型）フォーマットを持つ画像データなど構造化文書画像データの場合では、タイル単位ではなく構造単位で画像データを参照することが多い。
また、特許文献３は、断片化された符号データから不足する符号データを算出し受信サーバクライアント間の構造化文書画像符号データの構造化要素単位でキャッシュデータの整合性を保持する機能をもち、構造化要素単位にまとめておくことで過不足判定を効率的に進めるものである。
【特許文献１】特開２００４−２７４７５８号公報
【特許文献２】特開２００５−１２６８６号公報
【特許文献３】特開２００４−２４２２７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ここで、照合の効率化を阻害している要因として、次のようなことが考えられる。
【０００８】
（１）一般にキャッシュ上のデータは断片的な符号データを構成する最小の符号列単位で保存されているため、符号列毎に順次比較することになり、符号列を複数個集め、まとまった単位で比較することができなかった。
整合性を保証する照合範囲は全ての範囲である必要はなく、特定され限定されていてかまわなく、かえって範囲が限定されることで効率的である。キャッシュデータの整合性を保証する範囲はアクセスに対応した単位であることが望ましい。
【０００９】
（２）符号データが階層構造をもつなど複雑である場合にあっては、キャッシュ上に保存されているデータ構成とサーバ側に保存されているデータのデータ構成とが必ずしも同じではないために、照合を効率的に行うことができないという問題があった。
一般にキャッシュ上のデータは断片的な全ての符号列が連続していない記憶領域に符号列単位で保存され構造化されていないが、元符号データは符号化の規定に基づいて符号列が並んでいる。階層符号データのように部分符号データに分割して復号再生できるような場合は、転送される符号データは必ずしも符号データを構成する全ての符号列を含まないからである。キャッシュデータが順不同で保存されるため、符号データが決められた順番ではメモリに保存されないためである。
【００１０】
（３）サーバ上に保存されているデータは、他のクライアントからの要求のために、符号データの階層関係（プログレッション順）が変更される場合がある。
ＪＰＥＧ２０００仕様の階層符号データの場合は、符号データの階層関係（プログレッション順）を自由に変更できることに特徴があるからである。そのこのことは、階層構造の一致判定を複雑にする。
照合する最小単位は、パケット単位である。一方、部分符号データをアクセスする単位は、パケットより大きな上位レベルの単位（たとえば、プレシンクト単位あるいはタイル単位で複数のパケットをまとめたもの）である。したがって複数個のパケットを効率的に整合性をチェックする仕組みが重要になる。
【００１１】
しかし、上述した特許文献では、複数媒体に保存されているデータ間の同一性の判定に係る対象が、階層符号データであり、同一性判定範囲が階層レベルのまとまった部分符号データであるような場合にあって、部分符号データの階層構造を求め、並べ替えて保存することはしていない。
【００１２】
また、高速に部分符号データを照合する以外に、階層データ構造を柔軟に変更し比較するデータのプログレッション構成に適応する工夫や、プログレッションの使用頻度に反映してバックグラウンド処理で階層データ構造を柔軟に変更する工夫についてもなされていない。
【００１３】
このため、第一の課題としては、キャッシュ上に保存された断片化された符号列で構成できる符号データにより再生される画像が閲覧制限のかかった画像を含んでいる、あるいは、偽造有価証券の画像を含んでいるという照合を効率的に行うことにある。
【００１４】
また、第二の課題としては、クライアント側のキャッシュ上の符号データ（符号列）とサーバ側の元符号データとの間での符号データ間（あるいは符号列間）での効率的な一致判定（照合）が必要である。
【００１５】
本発明は、上述の実情を考慮してなされたものであって、殊にＪＰＥＧ２０００のような階層符号化データを対象として、クライアントサーバシステムにおいて、クライアント側のキャッシュ上の符号データ（符号列）とサーバ側の元符号データとの間の照合を効率的かつ確実に実現することを目的とする。
また、ＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，  ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）において、高速アクセス（アップロードデータ読み出し）を可能とするＪＰＩＰキャッシュモデルアーキテクチャを提供することを目的とする。
【課題を解決するための手段】
【００１６】
上述の課題を解決するために、請求項１に記載の画像処理装置の発明は、階層符号データを構成する符号列単位で保存するキャッシュを備え、該キャッシュに保存された符号列を符号データの階層構造に基づいて並び替える符号列並び替え手段と、前記符号列を並び替えた符号列群を使用して別の符号データと照合（比較）する符号データ照合手段を有することを特徴とする。
【００１７】
請求項２に記載の発明は、請求項１記載の画像処理装置において、前記キャッシュ上の符号列を使用して符号列の構造を推定するキャッシュ上の符号データ構造推定手段を有し、前記推定された階層構造に基づいて前記符号データの構造単位でキャッシュ上の符号列を並び替えることを特徴とする。
請求項３に記載の発明は、請求項２記載の画像処理装置において、照合する単位が階層レベル単位であることを特徴とする。
【００１８】
請求項４に記載の発明は、請求項２または３記載の画像処理装置において、前記照合は、前記符号データに含まれる符号列の長さ（パケット長）を使用することを特徴とする。
請求項５に記載の発明は、請求項２または３に記載の画像処理装置において、前記照合は、階層符号データの階層数によって比較することを特徴とする。
請求項６に記載の発明は、請求項２または３記載の画像処理装置において、前記照合は、前記階層符号データの階層毎の階層レベル数によって比較することを特徴とする。
【００１９】
請求項７に記載の発明は、請求項１乃至６のいずれかに記載の画像処理装置において、照合対象の符号データを構成する符号列の順番とキャッシュに保存されている符号列の順番とが同一であるように符号データを該キャッシュに保存する手段を有することを特徴とする。
請求項８に記載の発明は、請求項７記載の画像処理装置において、記憶装置を備え、該記憶装置と前記キャッシュには符号データがパケット単位（最小符号列単位）で保存され、照合対象の符号データと該キャッシュに保存された符号データが最小符号列単位で同じ保存位置（先頭アドレスから同じメモリロケーション位置）にあるかどうかを判定する判定手段を有し、前記判定手段を使用して符号データ間の照合をすることを特徴とする。
【００２０】
請求項９に記載の発明は、請求項１乃至８のいずれかに記載の画像処理装置において、パケット単位（最小符号列単位）の照合対象の符号データとキャッシュにパケット単位で保存された符号データと同じ保存順位にある前記パケットが一致するかどうかを判定する判定手段を有し、前記判定手段を使用して符号データ間の照合をすることを特徴とする。
【００２１】
請求項１０に記載の発明は、請求項９記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データの同じ保存位置（先頭アドレスから同じメモリロケーション位置）の範囲を指定して該範囲にある符号データの照合をすることを特徴とする。
請求項１１に記載の発明は、請求項１０記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データの同じ保存順の範囲を指定して、該範囲にある符号データの照合をすることを特徴とする。
請求項１２に記載の発明は、請求項１０記載の画像処理装置において、キャッシュに保存された符号データの保存順を指定して該保存位置にある符号データの有無によって照合することを特徴とする。
【００２２】
請求項１３に記載の発明は、請求項１乃至１２のいずれかに記載の画像処理装置において、照合対象の符号データとキャッシュに保存された符号データは、同じ階層構成（プログレッション順）を持つことを特徴とする。
請求項１４に記載の発明は、請求項１３に記載の画像処理装置において、キャッシュに保存された符号データの階層構造（プログレッション順）と照合対象の符号データの階層構造（プログレッション順）とを一致させることを特徴とする。
【００２３】
請求項１５に記載の発明は、請求項１３または１４記載の画像処理装置において、高頻度に使用する符号データのプログレッション順に基づいて照合する階層の選択をすることを特徴とする。
【００２４】
請求項１６に記載の発明は、請求項１乃至１５のいずれかに記載の画像処理装置において、前記キャッシュの符号列から構成された符号データの階層構造が、照合対象である符号データの階層構造に基づいて変更することを特徴とする。
請求項１７に記載の発明は、請求項１乃至１６のいずれかに記載の画像処理装置において、前記照合は、符号データの階層構造の特定の階層の符号列長の合計で比較することを特徴とする。
請求項１８に記載の発明は、請求項１乃至１７のいずれかに記載の画像処理装置において、前記照合は、符号データの階層構造の上位階層から下位階層の符号列の符号長の合計で比較してなされ、不一致な符号列を特定することを特徴とする。
請求項１９に記載の発明は、請求項１乃至１８のいずれかに記載の画像処理装置において、前記符号データがＪＰＥＧ２０００（ＩＳＯ／ＩＥＣ  １５４４４−１）規格に基づき符号化されたデータであることを特徴とする。
【００２５】
請求項２０に記載の画像処理システムの発明は、サーバの記憶装置に保存された符号データをクライアントが受信する符号データ転送機能を有するクライアントサーバシステムにおいて、前記クライアントは、前記受信した符号データをキャッシュに保存し再利用するキャッシュ機能を有し、請求項１乃至１９記載のいずれかに記載の符号データの照合を前記サーバの記憶装置上の符号データと前記キャッシュに保存された符号データ（複数符号列）との間でなされることを特徴とする。
【００２６】
請求項２１に記載の発明は、サーバの記憶装置に保存された符号データをクライアントが受信する符号データ転送機能を有するクライアントサーバシステムにおいて、前記クライアントは、キャッシュに保存された符号列から推定された該符号列の符号データの構造データを前記サーバへ転送する手段を有し、前記サーバは、前記構造データを使用して、請求項１乃至１９のいずれかに記載の照合手段によって照合することを特徴とする。
【００２７】
請求項２２に記載の発明は、請求項２０または２１記載の画像処理システムにおいて、前記クライアントは、前記符号データがＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，  ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）規格に基づき、照合対象である符号データの一部である部分符号データを受信する部分符号データアクセス機能を有することを特徴とする。
【００２８】
請求項２３に記載の画像処理方法の発明は、階層符号データを構成する符号列単位でキャッシュに保存し、該キャッシュに保存された符号列を符号データの階層構造に基づいて並び替え、前記符号列を並び替えた符号列群を使用して別の符号データと照合（比較）することを特徴とする。
請求項２４に記載の発明は、コンピュータに、請求項１乃至１９のいずれかに記載の画像処理装置の機能、または、請求項２０乃至２２のいずれかに記載の画像処理システムの機能を実現させるためのプログラムである。
請求項２５に記載の発明は、コンピュータが読み取り可能な記録媒体であって、請求項２４に記載のプログラムを記録したことを特徴とする記録媒体である。
【発明の効果】
【００２９】
本発明によれば、クライアント側のキャッシュ上の符号データ（符号列）とサーバ側の元符号データとの間の照合を効率的に施すことができ、部分符号データであっても階層構造を踏まえて容易に照合することができる。
また、キャッシュ上の非連続的に保存された断片的な符号列であっても、符号データとの間で効率的かつ確実に照合することができ、判定するデータ（符号列）の範囲を限定し効率的に照合することができる。
【発明を実施するための最良の形態】
【００３０】
以下、図面を参照して本発明に係る好適な実施形態について詳細に説明する。
まず、ＪＰＥＧ２０００およびＪＰＩＰについて説明する。
【００３１】
（１）ＪＰＥＧ２０００による符号化：
ＪＰＥＧ２０００（ＩＳＯ／ＩＥＣ  １５４４４−１）規格の符号化は、おおよそ以下の手順でなされる。
インターレース画像のフレームデータを、Ｙ，Ｃｒ，Ｃｂの色成分毎のデータに変換し、各色成分の色データに対して、２次元離散ウェーブレット変換を施し、得られるウェーブレット係数に、ＪＰＥＧ２０００に規定のスカラ量子化処理を施し、スカラ量子化されたデータに対しＪＰＥＧ２０００に規定のエントロピー符号化処理（いわゆる係数モデリングによる算術符号化処理）を施した後、ＪＰＥＧ２０００で規定する符号列を生成する。
復号化処理はこの逆の手順である。
【００３２】
勿論、これらの処理は、ハードウェア回路により実現しても良い。処理の高速化が図られる。なお、ＪＰＥＧ２０００に準拠する符号化処理を全てハードウェア回路で実現する画像処理装置は、既に存在する。
【００３３】
図１は、ＪＰＥＧ２０００の基本となる階層符号化アルゴリズムを説明するための図である。色空間変換・逆変換部、２次元ウェーブレット変換・逆変換部、量子化・逆量子化部、エントロピー符号化・復号化部、タグ処理部で構成されている。
ＪＰＥＧアルゴリズムと比較して、最も大きく異なる点の一つは変換方法である。ＪＰＥＧでは離散コサイン変換（ＤＣＴ：Ｄｉｓｃｒｅｔｅ  Ｃｏｓｉｎｅ  Ｔｒａｎｓｆｏｒｍ）を、階層符号化圧縮伸長アルゴリズムでは離散ウェーブレット変換（ＤＷＴ：Ｄｉｓｃｒｅｔｅ  Ｗａｖｅｌｅｔ  Ｔｒａｎｓｆｏｒｍ）を、各々用いている。
ＤＷＴは、ＤＣＴに比べて、高圧縮領域における画質が良いという長所が、ＪＰＥＧの後継アルゴリズムであるＪＰＥＧ２０００で採用された大きな理由の一つとなっている。
【００３４】
また、他の大きな相違点は、後者では、最終段に符号形成を行うために、タグ処理部と呼ばれる機能ブロックが追加されていることである。この部分で、圧縮動作時には圧縮データがコードストリームとして生成され、伸長動作時には伸長に必要なコードストリームの解釈が行われる。そして、コードストリームによって、ＪＰＥＧ２０００は様々な便利な機能を実現できるようになった。
例えば、図２に示した様に、ブロック・ベースでのＤＷＴにおけるオクターブ分割に対応した任意の階層（デコンポジション・レベル）で、静止画像の圧縮伸長動作を自由に停止させることができるようになる。
【００３５】
なお、原画像の入出力部分には、色空間変換部が接続されることが多い。例えば、原色系のＲ（赤）／Ｇ（緑）／Ｂ（青）の各コンポーネントからなるＲＧＢ表色系や、補色系のＹ（黄）／Ｍ（マゼンタ）／Ｃ（シアン）の各コンポーネントからなるＹＭＣ表色系から、ＹＵＶあるいはＹＣｂＣｒ表色系への変換又は逆の変換を行う部分がこれに相当する。
【００３６】
以下、ＪＰＥＧ２０００アルゴリズムについて、少し詳しく説明する。
カラー画像は、一般に、図３に示すように、原画像の各コンポーネント（ここではＲＧＢ原色系）が、矩形をした領域（タイル）によって分割される。そして、個々のタイル、例えば、Ｒ００，Ｒ０１，…，Ｒ１５／Ｇ００，Ｇ０１，…，Ｇ１５／Ｂ００，Ｂ０１，…，Ｂ１５が、圧縮伸長プロセスを実行する際の基本単位となる。従って、圧縮伸長動作は、コンポーネント毎、そしてタイル毎に、独立に行われる。
【００３７】
符号化時には、各コンポーネントの各タイルのデータが、図１の色空間変換部に入力され、色空間変換を施されたのち、２次元ウェーブレット変換部で２次元ウェーブレット変換（順変換）が適用されて周波数帯に空間分割される。
【００３８】
図２には、デコンポジション・レベル数が３の場合の、各デコンポジション・レベルにおけるサブバンドを示している。即ち、原画像のタイル分割によって得られたタイル原画像（０ＬＬ）（デコンポジション・レベル０）に対して、２次元ウェーブレット変換を施し、デコンポジション・レベル１に示すサブバンド（１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨ）を分離する。そして引き続き、この階層における低周波成分１ＬＬに対して、２次元ウェーブレット変換を施し、デコンポジション・レベル２に示すサブバンド（２ＬＬ，２ＨＬ，２ＬＨ，２ＨＨ）を分離する。
【００３９】
順次同様に、低周波成分２ＬＬに対しても、２次元ウェーブレット変換を施し、デコンポジション・レベル３に示すサブバンド（３ＬＬ，３ＨＬ，３ＬＨ，３ＨＨ）を分離する。更に図２では、各デコンポジション・レベルにおいて符号化の対象となるサブバンドを、グレーで表してある。例えば、デコンポジション・レベル数を３とした時、グレーで示したサブバンド（３ＨＬ，３ＬＨ，３ＨＨ，２ＨＬ，２ＬＨ，２ＨＨ，１ＨＬ，１ＬＨ，１ＨＨ）が符号化対象となり、３ＬＬサブバンドは符号化されない。
【００４０】
次いで、指定した符号化の順番で符号化の対象となるビットが定められ、図１の量子化部で対象ビット周辺のビットからコンテキストが生成される。
量子化の処理が終わったウェーブレット係数は、個々のサブバンド毎に、「プレシンクト」と呼ばれる重複しない矩形に分割される。これは、インプリメンテーションでメモリを効率的に使うために導入されたものである。図４に示した様に、一つのプレシンクトは、空間的に一致した３つの矩形領域からなっている。更に、個々のプレシンクトは、重複しない矩形の「コードブロック」に分けられる。これは、エントロピー・コーディングを行う際の基本単位となる。
【００４１】
エントロピー符号化部（図１参照）では、コンテキストと対象ビットから確率推定によって、各コンポーネントのタイルに対する符号化を行う。こうして、原画像の全てのコンポーネントについて、タイル単位で符号化処理が行われる。
【００４２】
エントロピー符号化部で形成される符号データの最小単位は、パケットと呼ばれる。パケットは、プログレッシブ順にシーケンス化され、これが画像ヘッダセグメントのなかの１つで示される。パケットは、あるプログレッシブ順データで、それぞれ、領域、解像度、レイヤ、および色成分によって配列される。即ち、ＪＰＥＧ２０００規格では、画質（レイヤ（Ｌ））、解像度（Ｒ）、コンポーネント（Ｃ）、位置（プレシンクト（Ｐ））という４つの画像の要素の優先順位を変更することによって、以下に示す５通りのプログレッションが定義されている。
【００４３】
・ＬＲＣＰプログレッション：プレシンクト、コンポーネント、解像度レベル、レイヤの順序に復号されるため、レイヤのインデックスが進む毎に画像全面の画質が改善されることになり、画質のプログレッションが実現できる。レイヤプログレッションとも呼ばれる。
【００４４】
・ＲＬＣＰプログレッション：プレシンクト、コンポーネント、レイヤ、解像度レベルの順序に復号されるため、解像度のプログレッションが実現できる。
【００４５】
・ＲＰＣＬプログレッション：レイヤ、コンポーネント、プレシンクト、解像度レベルの順序に復号されるため、ＲＬＣＰ同様、解像度のプログレッションであるが、特定位置の優先度を高くすることができる。
【００４６】
・ＰＣＲＬプログレッション：レイヤ、解像度レベル、コンポーネント、プレシンクトの順序に復号されるため、特定部分の復号が優先されるようになり空間位置のプログレッションが実現できる。
【００４７】
・ＣＰＲＬプログレッション：レイヤ、解像度レベル、プレシンクト、コンポーネントの順序に復号されるため、例えばカラー画像のプログレッシブ復号の際に最初にグレーの画像を再現するようなコンポーネントのプログレッションが実現できる。
【００４８】
このようにＪＰＥＧ２０００規格では、画像は領域（タイルまたはプレシンクトといった画像構成要素）、解像度、階層（レイヤ）、色成分に分割され、それぞれが独立してパケットとして符号化される。これらのパケットはデコードすることなしに、コードストリームから識別され抽出され得るところに特徴がある。
【００４９】
最後に、タグ処理部（符号列形成部）は、エントロピー符号化部からの全符号化データを１本のコードストリームに結合するとともに、それにタグを付加する処理を行う。図５には、コードストリームの構造を簡単に示した。コードストリームの先頭と各タイルを構成する部分タイルの先頭にはヘッダと呼ばれるタグ情報が付加され、その後に、各タイルの符号化データが続く。そして、コードストリームの終端には、再びタグが置かれる。
【００５０】
一方、復号化時には、符号化時とは逆に、各コンポーネントの各タイルのコードストリームから画像データを生成する。図１を用いて簡単に説明する。この場合、タグ処理部は、外部より入力したコードストリームに付加されたタグ情報を解釈し、コードストリームを各コンポーネントの各タイルのコードストリームに分解し、その各コンポーネントの各タイルのコードストリーム毎に復号化処理が行われる。コードストリーム内のタグ情報に基づく順番で復号化の対象となるビットの位置が定められるとともに、逆量子化部で、その対象ビット位置の周辺ビット（既に復号化を終えている）の並びからコンテキストが生成される。
【００５１】
エントロピー復号化部で、このコンテキストとコードストリームから確率推定によって復号化を行い、対象ビットを生成し、それを対象ビットの位置に書き込む。このようにして復号化されたデータは各周波数帯域毎に空間分割されているため、これを２次元ウェーブレット逆変換部で２次元ウェーブレット逆変換を行うことにより、画像データの各コンポーネントの各タイルが復元される。復元されたデータは色空間逆変換部によって元の表色系のデータに変換される。
【００５２】
（２）ＪＰＩＰにおける符号データのやり取り：
サーバにあるＪＰＥＧ２０００符号から、必要な符号だけを受信するためのプロトコルとして国際規格ＪＰＩＰ（ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ  −  Ｐａｒｔ  ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ）（［“Ｉｎｆｏｒｎａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ−ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ”ＩＳＯ／ＩＥＣ  ＦＤＩＳ  １５４４４−９：２００４”］）がある。
【００５３】
このような、階層的な画像を部分的にアクセスするためのプロトコルは、古くは、画像の多重解像度表現であるＦｌａｓｈＰｉｘと、それにアクセスするためのプロトコルであるＩＩＰ（Ｉｎｔｅｒｎｅｔ  Ｉｍａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）に見ることができる。ＪＰＩＰに係る特許文献としては特許文献１がある。
【００５４】
ＪＰＩＰにおいては、クライアントからの要求（リクエスト）に応じて、サーバは完全な画像ファイル、タイルパートストリーム（ＪＰＴ−ストリーム）またはプレシンクトストリーム（ＪＰＰ−ストリーム）の形式をもつ符号データを戻す（応答する）。
ＪＰＴ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるタイルパートの組としてサブ画像の符号データを戻す方法である。
一方、ＪＰＰ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるプレシンクトの組としてサブ画像の符号データを戻す方法である。
【００５５】
ＪＰＴ−ストリームにより順次アクセスした符号データを再生する場合は、タイル分割されたタイル領域毎に順次完全に再生するのに対して、ＪＰＰ−ストリームにより順次アクセスした符号データを再生する場合は、タイル領域に跨った広い領域で、小さい領域（プレシンクト）単位に徐々に再生することができる。すなわち、ＪＰＴ−ストリームのアクセスによる再生では、一時に再生する範囲が画像全体の中であるタイル領域に限定されているのに対し、ＪＰＰ−ストリームのアクセスによる再生では、一時に再生する範囲はタイル領域に限定されず画像全体での再生が可能なのである。
【００５６】
このように、ＪＰＩＰのクライアントは、受信された符号データの部分を識別でき、それらの部分を復号し且つ画像を生成することができるように、タイルパートストリーム又は、プレシンクトストリームの形式で、ＪＰＥＧ２０００コードストリームのサブセットを戻す機能を提供する。
【００５７】
即ち、ＪＰＰ−ストリームは、ＪＰＥＧ２０００コードストリームへ変換され、ＪＰＥＧ２０００デコーダで復号することができる。この変換は、復号されるデータと共に、メインヘッダの全てとタイルヘッダの全てを受信すれば十分である。
【００５８】
ＪＰＰ−ストリームは、メッセージのシーケンスより構成される（図６参照）。各メッセージは、含まれるデータ−ビン情報の形式を示す（メインヘッダ、メタデータ、プレシンクト、又は、タイルヘッダ）。各メッセージは、データ−ビン内の開始位置とメッセージの長さも示す。各メッセージは、その形式、その形式内のインデックス、その形式とインデックスを有する「データ−ビン」へのメッセージのオフセット、及び、メッセージ長を識別するヘッダを有する。
【００５９】
メッセージは、典型的には、データ−ビン全てを含まず、データ−ビンの一部を含む。メッセージには、データ−ビンがどのタイル、コンポーネント、位置及び、解像度データビンに対してであるかを示す識別子を含む。本発明では、タイル、コンポーネント、位置及び、解像度を階層としており、データ−ビンに含まれる符号列（パケット）は、各階層のどのレベル（階層レベル）のデータであるかという情報が対応している。例えば、データ−ビンに含まれるある符号列がタイルＡでコンポーネントがＣｂで位置４で解像度１レベルであることが示されている。
【００６０】
プレシンクトデータ−ビンは、一連のパケットヘッダ（ＰＨ）とパケットデータ（ＰＤ）より構成される（図７参照）。パケットヘッダは、どのコードブロックがパケットのパケットデータ部分内のデータを有するかに関する情報、各符号ブロックに格納されたバイト数に関する情報、及び、各符号ブロックについての符号化パスの数を含む。ＪＰＩＰの標準仕様では、パケットヘッダには、どのコンポーネント、位置、解像度、タイル、あるいは、それが属するレイヤを識別する情報（階層レベル情報）は持っていない。
【００６１】
本発明の一実施例として、先に示したメッセージデータを解析して、パケット単位の階層レベル情報をパケットヘッダに記録してもかまわない。クライアント側でＪＰＰ−ストリーム受信後、これらの情報を記録することもできる。
【００６２】
同様に、ＪＰＩＰの標準仕様では、パケットヘッダの長さに関する明確な情報は持たない。パケットデータの長さは、パケット内の全てのコードブロックにデータの長さを加算することにより決定できる。
本発明の一実施例として、パケットヘッダにこれらのデータ長を計算した結果を保存する構成にすることができる。ＪＰＰ−ストリームに規定された構成によりパケットを抽出することができる。
【００６３】
ＪＰＩＰのプロトコルは、二つの異なるタイプの要求をもっている。サーバがキャッシュモデルを維持する必要がないという意味におけるステートレスリクエストとそれ以外のリクエストがある。
サーバのキャッシュモデルには、それまでにサーバに送信したことについての情報の記録がなされている。
また、クライアントのキャッシュには、サーバから受信した符号データが保存され、サーバは、キャッシュモデルを用いることによって、既に転送した符号データをクライントに転送することなく、再利用できる。典型的には、クライアントは、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番にデータをアペンドしキャッシュに保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。
【００６４】
（３）ＪＰＩＰにおけるクライアント、サーバ、及びネットワーク：
図８は、ＪＰＩＰにおけるキャッシュを持ったクライアントサーバモデル構成例であり、図９は、ＪＰＩＰにおけるクライアントサーバネットワークモデル構成例である。
【００６５】
図８は、クライアント及びサーバ間で符号データを通信するネットワーク環境の一実施例を示す。図８に示すように、サーバ１０２は、ある種のネットワークを介してクライアント１０１のような少なくとも１つのクライアントに接続されている。クライアント１０１は、しばしば、人間のユーザにより制御される「プログラム」であるが、しかし、完全に自動化されたシステムでも良い。クライアント１０１は、ある画像のサブセットに対する要求（リクエスト）１１０を発行し、要求１１０に示された方法で対応する符号データを含む応答１１３を受信する。ネットワークの帯域幅又はサーバ１０２の資源又は、ファイル要求の構造のために、クライアント１０１は要求された画像の部分符号データ以外のおおよその符号データを受信し得る。クライアント１０１は、典型的には、キャッシュを用いて、画像の異なる部分の出力に対する要求を発行し、前に受信された符号データに対する追加分の符号データを受信する。
【００６６】
ＪＰＩＰの基本的特徴の一つは、クライアントが既に受信した符号データを繰返すことを避ける能力である。この符号データの再送信を避ける２つの方法がある。
一つ目の方法（図９）としては、クライアント１０１が、サーバ１０２へ送信されクライアントで既に受信された符号データについての情報をもつことで、クライアント１０１は冗長なデータの配信をサーバ１０２に要求しないで済ませ、それにより、サーバ１０２は冗長な符号データを送信しないで済ます方法である。サーバ１０２が、「ステートレス」で動作する場合にあっては、それまでの相互動作を記憶することなく動作する。サーバが、それまでの相互動作を記憶する特別なキャッシュモデルを維持する必要がないことから、一般的には、ステートレスで動作しているということが多い。
【００６７】
二つ目の方法（図８）としては、クライアント１０１とサーバ１０２は、「セッション」を確立し、サーバ１０２は、クライアント１０１へ送られた符号データを記憶しておくキャッシュモデルをもっている。即ち、サーバのキャッシュモデルには、それまでにサーバ１０２に送信したことについての情報の記録がなされている。クライアント１０１のキャッシュには、サーバ１０２から受信した符号データが保存され、サーバ１０２は、キャッシュモデルを用いることによって、既に転送した符号データをクライアント１０１に転送することなく、再利用できる。典型的には、クライアント１０１は、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番にデータをアペンドしキャッシュに保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。
【００６８】
本発明は、主に、ステートレスな要求を処理する図８に係り、キャッシュ管理部１０８を有することで、キャッシュ１０３のキャッシュデータを管理する。
【００６９】
クライアント１０１は、それまでに要求した符号データの全てを受信する前にさえも、興味のある画像の部分に対応する符号データを変更し得る。あるサーバは、これらの変更を扱うために、前の要求に対する応答を割り込みすることができる。
【００７０】
図９は、典型的なネットワークを示す。図９を参照すると、ネットワークは、複数のクライアント（例えば、クライアント２２１，２２２，２４０）と複数のサーバを含む。単一のサーバは、数１００万の異なるクライアントへ同じ画像の異なる部分を扱い得る。単一のクライアントは、画像と他のデータ（例えば、ＨＴＭＬページ）を、幾つかのサーバから受信する。プロキシサーバは、オリジナルサーバと通信すること無しに幾つかの要求への素早い応答を可能とするために、ネットワーク内に存在しうる。有効な帯域幅と帯域幅のコストは、異なるクライアントと同じサーバの間で又は、異なるサーバの間で広く変わる。
【００７１】
最も一般的に使用されるネットワークは、インターネット又はワールドワイドウェブである。しかし、ＪＰＩＰは、ローカルエリアネットワーク（ＬＡＮ）又は、どのような一般的な相互接続システムにも適用できる。ＪＰＩＰは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の上で最も一般的に転送されるが、しかし、ＴＣＰ／ＩＰ及びＵＤＰを含む他の転送プロトコルと共に使用されると予想される。
【００７２】
以上のことから、ＪＰＩＰストリームの符号フォーマット（メッセージ）を分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数が分かる。また、プログレッション順序についても知ることができる。
【００７３】
図１０は、ＪＰＩＰを使用した場合の出力表示画面例を示す。図１０（Ａ）では、２つのタイルからなるデータが表示されており、例えば、それぞれのタイルをクリックすることによって画像データが表示され、図１０（Ｂ）のような画質の劣ったタイル４枚からなる画像となる。さらに、右下をクリックすることによって、そのタイルの部分画像（図１０（Ｃ））の解像度が変倍され、部分画質レベルが向上する。このように、部分画像データを参照する場合に使用される。部分画像データを参照する都度、表示クライアント側からサーバ側へ符号データを転送要求し再生する。
【００７４】
このようにＪＰＩＰにおいては、クライアント（出力側）では、全ての（階層）符号データではなく、部分符号データを必要としていることを前提としている。そのため、部分符号データからオリジナルの符号データの階層構造を知ることができないという問題があった。
【００７５】
（４）ＪＰＥＧ２０００のコードストリームのフォーマット：
ＪＰＥＧ２０００のコードストリームは、画像についての全てのエントロピー符号化されたデータと、その符号化されたデータを復号するために使用されるべき方法を記述するデータを含む。
コードストリームは、使用されるウェーブレット変換に関する情報、タイルのサイズ、プレシンクトのサイズ、解像度に関する情報、ファイル内のパケットの順序等を含む。コードストリームは、エントロピー符号化されたデータを画像サンプルに復号するのに必要な全てのパラメータを含まなければならない。コードストリームは、例えば、パケットの長さのような、符号化されたデータの部分への高速アクセスを提供する情報も含み得る。
【００７６】
ＪＰＥＧ２０００のコードストリームのフォーマットの概略構成を図１１（Ａ）に示す。ＪＰＥＧ２０００の「コードストリーム」には、いくつかのマーカセグメントをもっている。マーカセグメントとは、一つの２バイト長よりなるマーカとそれに付随するパラメータ群から構成されている。各マーカセグメントには機能、用途、データ長が表されている。コードストリームのフォーマットは符号データの始まりを示すＳＯＣ（Ｓｔａｒｔ  ｏｆ  Ｃｏｄｅｓｔｒｅａｍ）マーカで始まる。ＳＯＣマーカの後には、符号化のパラメータや量子化のパラメータ等を記述したメインヘッダが続き、その後に実際の符号データが続く。
【００７７】
メインヘッダの構成を図１１（Ｂ）に示す。メインヘッダはＣＯＤ，ＱＣＤの必須マーカセグメントと、ＣＯＣ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＭ，ＴＬＭ，ＰＬＭ，ＣＲＧ，ＣＯＭのオプションマーカセグメントで構成される。ここで、ＳＩＺマーカセグメントには、コンポーネント数とかタイルサイズなどの非圧縮時の画像の情報が記述され画像コンポーネントの幅と高さについての情報を含む。ＣＯＤとＣＯＣマーカセグメントは、圧縮されたデータはどの様に復号されるべきかを示すパラメータを含む。ＣＯＤマーカにはプログレッション順序、レイヤ数、プレシンクトサイズ、デコンポジション分割数が記述されている。ＱＣＤマーカは量子化に係る情報が記載されている。また、ＣＯＭマーカはコメント等の情報を付加したいときに利用するマーカで、メインヘッダ、タイルヘッダの双方で使用することが可能である。
【００７８】
メインヘッダの後に、一連の「タイルパート」がある。各タイルパートは、特定のタイルと部分を識別する「ＳＯＴ（Ｓｔａｒｔ  ｏｆ  Ｔｉｌｅ−ｐａｒｔ）」マーカセグメントで始まる。各タイルパートについて符号化されたデータには、「ＳＯＴ」マーカセグメントが先行する。「ＳＯＴ」マーカセグメントには、タイルパート数に係る情報を含んでいる。
【００７９】
実際の符号データ（図１２）は、ＳＯＴマーカで始まり、タイルヘッダ、ＳＯＤ（Ｓｔａｒｔ  ｏｆ  Ｄａｔａ）マーカ、タイルデータ（符号）で構成される。これら画像全体に相当する符号データの後に、符号の終了を示すＥＯＣ（Ｅｎｄ  ｏｆ  Ｃｏｄｅｓｔｒｅａｍ）マーカが付加される。メインヘッダはＣＯＤ，ＱＣＤの必須マーカセグメントとＣＯＣ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＭ，ＴＬＭ，ＰＬＭ，ＣＲＧ，ＣＯＭのオプションマーカセグメントで構成される。
【００８０】
タイルヘッダ構成を図１１（Ｃ）（Ｄ）に示す。同図は、タイルデータの先頭に付加されるマーカセグメント列であり、ＣＯＤ，ＣＯＣ，ＱＣＤ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＴ，ＰＬＴ，ＣＯＭのマーカセグメントが使用可能である。一方、図１１（Ｄ）は、タイル内が複数に分割されている場合における分割されたタイルパートの先頭に付加されるマーカセグメント列であり、ＰＯＣ，ＰＰＴ，ＰＬＴ，ＣＯＭのマーカセグメントが使用可能である。タイルヘッダでは必須マーカセグメントはなく、すべてオプションである。
タイルデータ（符号）は、連続したパケットで構成される。コードストリーム中のパケットの順番をプログレッション順序と呼んでいる。
【００８１】
以上のことから、ＪＰＥＧ２０００コードフォーマットを分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数がわかる。また、プログレッション順序についても知ることができる。
【００８２】
以上の事実を踏まえて、以下に示した問題解決の考え方に沿って、本発明の実施形態を詳細に説明する。
【００８３】
（Ａ）キャッシュデータの符号列を構造化（階層化）して、階層レベル単位でキャッシュデータの照合をする機能をもたせる。
（Ｂ）また、係る構造化データを辿ることで、効率的にある特定階層に含まれる符号列（パケット）に範囲を限定して照合を図る。
（Ｃ）クライアント（キャッシュ）の符号列を符号データの規定に基づく順番に並び替えてからサーバ上の符号データと照合する。
（Ｄ）本発明では、クライアント側のキャッシュ（一時保存）とサーバ側の符号データ間で互いに同様な順番で記録する構成とし、記憶装置上の同じ位置に配置されているデータ同士が互いに同じであるようにすることによって、（符号データが格納されている先頭アドレスからの（パケットが保存されている）順番が同じであるアドレスに同じデータが格納されていることから）、メモリへのデータの格納順位（連続性）を使用してデータを簡単に読み出し互いに比較することが可能となる。特に、複数のパケット（データの最小単位）の連続的なデータ間の整合性の比較ができることから、効率的に複数個の連続的なパケットデータをまとめて比較することが可能となる。
サーバ／クライアント（キャッシュ）間で同一の順番に並び替えて、パケット（最小符号データ単位）を格納して比較することで、ある範囲をまとめて参照効率を高くして比較できるようにする。
したがって、符号データのプログレッション順に応じて、キャッシュ上の符号データを照合することで、上記処理を効率的に実現する。
【００８４】
（５）サーバクライアント間でキャッシュデータと元画像符号化データ間の効率的な照合：
図１３は、本発明におけるキャッシュデータとの照合の概念図を示す。本発明の典型的な応用においては、クライアント上のキャッシュに断片的な符号列を併合することによって生成した符号データを復号再生したときに閲覧禁止の文章などが再生されることがないように照合する（認証する）機能を提供するところにある。
【００８５】
一般的に、キャッシュ上の符号列は断片的であるが、それらを体系化しまとめて符号化することで再生禁止の画像が再生し得る。そこで、本発明の典型的な構成においては、体系化したときの符号データを合成し、必要に応じて並べ替えて符号列レベルで禁止画像の符号データと照合するというものである。その場合にあって、効率的に照合すると共に、部分画像の符号データと照合する機能も提供する。クライアントが先に説明したＪＰＩＰのプロトコルを使用して断片的に（部分的に）転送された部分符号データをサーバから入手しクライアントキャッシュに保存されるような場合に応用できる。
【００８６】
図１４は、クライアントサーバネットワークモデルの構成例である。照合要求は、クライアント２０１でなされ、照合はサーバ２０３でなされる。典型的な応用においては、照合するときに管理テーブルを受信してなされる。
【００８７】
本発明の典型的なクライアントサーバ照合システムは、サーバの記憶装置に保存された符号データをクライアントが受信する機能を有するクライアントサーバシステムにおいて、クライアントにおいて前記クライアントのキャッシュに保存された符号列を分析して推定された該符号列の符号データの構造データをサーバへ転送し、サーバにおいて前記構造データを使用して照合する。本発明の照合は階層符号データの符号列の管理（構造）テーブルを用いてキャッシュ管理を実現している。
【００８８】
図１６は、クライアントサーバ照合システムの処理手順を示すフローチャートである。
クライアント１０１では、符号データを入力しキャッシュへ保存し、管理テーブルに構造データを作成し、このキャッシュデータ検査要求と共に管理テーブルをサーバへ転送する。
クライアント１０１では、サーバ１０２より検査結果を待って、検査結果をサーバから受信する。この検査結果がＯＫで復号中止でなければ、復号再生し、次の符号データの入力へ戻る。また、復号中止であれば、次の符号データの入力へ戻る。
【００８９】
サーバ１０２では、クライアント１０１からの検査要求待ち、クライアント１０１から送られた管理テーブルを照合処理して、照合結果をクライアントへ返し、次の検査要求を待つ。
【００９０】
また、クライアントサーバシステムは、クライアントがサーバの記憶装置に保存された符号データをサーバから受信し、前記受信した符号データをクライアントのキャッシュに保存し再利用するキャッシュ機能を有し、符号データの照合をサーバの記憶装置上の符号データとクライアント上のキャッシュに保存された符号データ（複数符号列）との間でなされる。
【００９１】
図１５は、照合の（クライアントサーバ）システム構成例である。特徴的なところは、クライアント１０１に照合要求部１１１を具備し、サーバ１０２には照合処理部１１２を具備していることである。キャッシュ上の符号列を管理するために、キャッシュ管理部１０８には、符号データ解析部１０１０、管理テーブル構造テーブル生成処理部１０１１、管理テーブル構造テーブル変更処理部１０１２、管理テーブル構造テーブル参照処理部１０１３、符号データ保存処理部１０１４、を備えている。符号データ解析部１０１０では、符号データを解析し、構造を推定するために必要な各符号列の情報（階層数と各階層ごとのその符号列の属するレベル）を抽出する。管理テーブル構造テーブル生成処理部１０１１では、各符号列の情報（部分符号データに含まれる符号列の階層レベル）を使用して管理テーブルと構造テーブルを生成する。このとき、符号列は、符号データ保存処理部１０１４で保存する。管理テーブルと構造テーブルを変更したり１０１１、あるいは、参照したり１０１２する機能も具備している。
【００９２】
図１７は、階層を選んで階層レベルでキャッシュデータの照合に係る基本処理のフローチャートである。
キャッシュデータの照合処理は、構造を照合して構造を同じにし、オリジナルの階層符号データとの整合処理を行う（Ｓ１）。
次に、照合単位を設定し、符号データの照合を行うことによって、階層単位毎に照合する（Ｓ２）。
最後に、符号データのアップデート更新処理を行う（Ｓ３）。
【００９３】
図１８は、照合処理部１０１５の構成例である。照合処理部１０１５は、符号データ間整合処理部１０１５０、階層単位毎の照合部１０１５１、符号データのアップロード更新制御部１０１５２により構成されている。符号データ間整合処理部１０１５０は、（Ａ）オリジナルの階層符号データとの整合処理を実施し、階層単位毎の照合部１０１５１は、（Ｂ）階層単位毎の照合を実施し、符号データのアップロード更新制御部１０１５２は（Ｃ）符号データのアップデート更新処理を実施する。
【００９４】
図１５は、キャッシュデータ（符号列構造）管理のためのデータ構造の基本構成図である。管理テーブルと構造テーブルと符号列保存部よりなる。本実施形態では、構造テーブルは、表形成であるが、後述する別の実施形態（図２０）では、ツリー構造をもっている。管理テーブルは、符号データ名（ファイル名）、階層数、各階層毎の階層レベル数（階層レベルの最大値）、構造データへのアドレス（ポインタ）により構成されている。階層数により階層レベル数の項目の数が変更される。
【００９５】
構造テーブルは、階層レベル数の各階層分の組み合わせの全ての項目を含む。符号列の属する各階層の階層レベルに該当する符号データへのポインタの部分に該符号列が保存されている。
【００９６】
図２０は、キャッシュ管理テーブル、構造テーブルの例である。構造データを表す形式が、ツリー構造であるところが特徴であり、このツリー構造は、前述した図１５のテーブル構造とは互換性がある。すなわち、テーブル構造は、ツリー構造へ変換することも、逆も任意に変更することができる。ツリー構造をもつ構造テーブルは、階層ノードにより構成されている。各階層ノードは、階層レベルＮｏと下位階層レベルへの全てのポインタと情報項目より構成されている。最下位の階層では、各階層ノードは階層レベルＮｏと符号列へのポインタ格納領域をもっている。下位階層レベルへの全てのポインタはもっていない。また、符号列がない場合は、該ポインタ格納領域はＮＵＬＬになっている。
【００９７】
ところで、図２０あるいは、図１５で示した構造データを使用することによって、ある階層レベルに属する符号列を参照することは容易である。符号列に対応してそれの属する階層レベルを知ることが容易であり、かつ、階層毎に階層レベルによって体系化された形式で保存されているからである。例えば、最上位階層の階層レベルが１である符号データは、符号データに対応した同階層の階層レベルが１である符号列を探せばよいが、図１５のテーブルタイプの構造データにおいては、連続的に並んでいるため参照は高速にできる。一方、図２０の構造データにおいては、階層ノードの該当する階層の階層レベル番号が１である階層ノードから下位階層ノードへのポインタをたどっていくことで該符号列を参照できる。
【００９８】
ツリー構造の構造データにおいては、各階層ノードは情報項目をもつが、図２０では、下位階層の符号列の符号列の符号長の合計値を記録している。符号列を保存するときに、その符号列の属する階層レベルにあたる階層ノードの同項目の値（符号長の値）をカウントアップすることによって生成する。
【００９９】
図２１は、図２２で示す構造化データを生成するキャッシュデータの構造化処理を示すフローチャートである。
キャッシュデータの生成処理は、符号データの構造把握するために次の処理を全ての符号列が終了まで繰り返す（Ｓ１１〜Ｓ１４）。
対象符号データの符号列を順次取り出し（Ｓ１１）、部分符号データに含まれる符号列の階層レベルを抽出し符号データの各階層の最高階層レベル番号を算出（断片的な符号列（パケット）群より構造を把握）し（Ｓ１３）、各階層の最高階層レベルを持つ全ての階層レベルの組み合わせパターンをもつ構造データテーブル作成する（Ｓ１４）。
【０１００】
次に、キャッシュデータの符号列保存処理するために次の処理を全ての符号列が終了まで繰り返す（Ｓ１５〜Ｓ１８）。
対象符号データの符号列を順次取り出し（Ｓ１５）、該符号列を保存し（Ｓ１７）、符号列の階層レベルを調べ、構造データテーブルの該階層レベルの符号列へのポインタに符号列のアドレスを書き込む（Ｓ１８）。
【０１０１】
図２３は、図２０で示す構造化データを生成するキャッシュデータの構造化処理を示すフローチャートである。
クライアントのキャッシュデータ構造生成処理は、部分符号データの受信を待ち、部分符号データを受信する（Ｓ２１）。
次に、符号データの構造把握では、部分符号データに含まれる符号列の階層レベルを抽出し（Ｓ２２）、キャッシュデータ管理テーブルへ符号列の最高階層レベル番号を書き込む（断片的な符号列（パケット）群より構造を把握）（Ｓ２３）。
次に、キャッシュの更新処理では、キャッシュデータ管理テーブル上の各階層のレベル数を読み込み（Ｓ２４）、前記レベル数をもつ階層ノードデータを作成する（Ｓ２５）。
【０１０２】
ここで、階層ノードデータは、次の項目からなっている。
（ｉ）階層レベルＮｏ、
（ｉｉ）下位階層の階層ノードデータへのポインタ、
（ｉｉｉ）下位階層データ有無フラグ、
（ｉｖ）下位階層の符号列の総符号長。
【０１０３】
そして、各階層ノードデータの（ｉ）階層レベルＮｏを記載し（Ｓ２６）、各階層ノードデータの（ｉｉ）下位階層の階層ノードデータへのポインタを記載する（Ｓ２７）。この時最下位階層ノードデータの（ｉｉ）下位階層の階層ノードデータへのポインタの初期値はＮＵＬＬとしておく。また、（ｉｉｉ）下位階層データ有無フラグは０とし、（ｉｖ）下位階層の符号列の総符号長は０とする。
【０１０４】
次に、保存対象とする符号列毎に順次以下の処理をして（Ｓ２８〜Ｓ３２）、ステップＳ２１へ戻る。
保存対象とする符号列を取り出して（Ｓ２８）、符号列を保存する（Ｓ３０）。
階層ノードデータを上位階層から下位階層へと辿りながら、その符号列の各階層レベルで（ｉ）階層レベルＮｏと一致する最下位の階層ノードデータを探し、該最下位の階層ノードデータの（ｉｉ）下位階層の階層ノードデータへのポインタ先を、符号列が保存されているアドレスとする（Ｓ３１）。この時、上位階層の階層ノードデータから（ｉｉ）下位階層の階層ノードデータへのポインタ先を辿っていった時の階層レベルＮｏが、その符号の階層レベルであるようになっている。
階層ノードデータを上位階層から下位階層へと辿りながら、該最下位の階層ノードデータの（ｉｉ）下位階層の階層ノードデータへのポインタを書き込む時に、辿られた階層ノードデータの（ｉｉｉ）下位階層データ有無フラグに１を加え、（ｉｖ）下位階層の符号列の総符号長に該符号列の符号長を加え、ステップＳ２８へ戻る（Ｓ３２）。
このようにして作成された構造データテーブルを更新し、符号データを書き込んで、次の部分符号データの受信を待つ。
【０１０５】
図２４は、別のデータ構造の基本構成図である。管理テーブルとしてファイル（符号データ）が、サブファイル（サブ符号データ）により構成されるような場合である。
全体の文書画像に絵柄などの画像データが組み込んであるような構造化文書画像の符号化などで、符号データもこのような階層構造を持たせる場合がある。このような場合にあっては、キャッシュを管理するためのデータ構造も、本実施形態のように、符号データの階層関係にしたがって管理テーブルも階層構造をもたせて実現する。それぞれのサブファイルが、それぞれ独立の構造テーブルをもたせることで、符号列間の関係（構造）が管理できる。構造化文書画像にも対応することができる。
【０１０６】
図２５は、階層を選んで階層レベルでキャッシュデータの照合に係るより具体的な処理を示すフローチャートである。
キャッシュデータの照合処理は、オリジナルの階層符号データとの整合処理をする。
このため、オリジナル階層符号データのプログレッション順を調べ、不一致ならば（Ｓ３６／不一致）、次の符号データをアップロードして終了する（Ｓ４８）。一致していれば（Ｓ３６／一致）、プログレッション順を同じになるように構造データテーブルを変換して構造を同じにする（Ｓ３７）。
【０１０７】
次に、階層単位毎に照合する（Ｓ３８〜Ｓ４４）。
照合の階層の決定（例、比較対象の階層符号データの最上位階層を照合の階層とする）して、照合単位を設定する（Ｓ３８）。
そして、符号データを照合する（Ｓ３９〜Ｓ４４）。
まず、照合の階層をレベル毎に（該レベルに含まれる符号データを）取り出し（Ｓ３９）、全レベルが終了したならば、該当の符号データをアップロードし（Ｓ４７）、キャッシュデータを更新して（Ｓ４６）、ステップＳ４１へ戻る。
【０１０８】
キャッシュの階層符号データの構造データテーブルのポインタ欄の値を順次抽出し（Ｓ４１）、該レベルの全符号データが終了したならばステップＳ３９へ戻る（Ｓ４２）。
一方、構造データテーブルのポインタ欄はＮＵＬＬでなければ（Ｓ４３／ＹＥＳ）、符号データ間を照合し、一致していれば（Ｓ４４／一致）、ステップＳ４１へ戻る。
また、不一致であれば（Ｓ４４／不一致）、照合単位に含まれる符号データを全てアップロードし（Ｓ４５）、キャッシュデータを更新して（Ｓ４６）、ステップＳ４１へ戻る。
また、構造データテーブルのポインタ欄はＮＵＬＬであれば（Ｓ４３／ＮＯ）、ステップＳ４７へ進んで符号データをアップロードして（Ｓ４７）、キャッシュデータを更新して（Ｓ４６）、ステップＳ４１へ戻る。
【０１０９】
本発明は、キャッシュに保存された符号列を符号データの階層構造に基づいて並び替える符号列並び替え、並び替えた符号列群を使用して別の符号データと照合（比較）する符号データ照合手段を提供する。即ち、非連続断片的な符号列を並び替えてから照合対象の符号データと照合する。
【０１１０】
また、構造の照合の前段階としてキャッシュ上の符号列により構成される符号データの構造を推定する。図１５を用いて説明したように、キャッシュ上の符号列を使用して符号列の構造を推定する。非連続断片的な符号列を並び替えるときに構造を推定する手段を具備することで符号列が、断片的であっても構造を踏まえた部分的な並び替えができ部分的な照合ができる。即ち、階層単位毎の照合にて階層レベル単位でまとめて照合する。
【０１１１】
図２６は、符号長による照合処理を示すフローチャートである。
クライアントのキャッシュデータの照合では、符号データの構造（プログレシブ順）を合わせる（Ｓ５１）。
次に、符号データ全体の符号長で比較し（Ｓ５２）、符号データの符号長が一致していれば（Ｓ５３）、キャッシュデータの照合処理を行う（Ｓ５４）。
不一致ならば、照合結果が不一致として処理を終了する（Ｓ５８）。
次に、部分符号データの照合を行う（Ｓ５５〜Ｓ５７）］
まず、照合対象の部分符号データを上位階層から下位階層へ順次符号長を比較し（Ｓ５５）、部分データ長が一致していれば（Ｓ５６／一致）、キャッシュデータの照合処理を行い（Ｓ５７）、全ての階層の符号長の比較が終了するまでステップＳ５５へ戻る。
部分データ長が一致していなければ（Ｓ５６／不一致）、照合結果が不一致として処理を終了する（Ｓ５８）。
【０１１２】
符号データに含まれる符号列の長さ（パケット長）を使用して照合することで、符号長（パケット長）という簡易な照合方法により効率的な照合ができる。
【０１１３】
部分符号データの照合の際に、図２０のツリー構造からなる構造データを使用して、上位階層から下位階層へ順次辿っていって符号長を段階的に比較することで効率的な照合ができる。また、上位階層の符号長を比較することで、効率的な照合をすることができる。このようにして、符号長による段階的な照合処理をしている。
【０１１４】
（６）照合単位の設定：
図１４を用いて説明したように、クライアントサーバシステムで照合する場合においては、サーバ側でクライアントキャッシュ上の符号列により構成される符号データを照合対象の符号データの階層構造に合わせて照合するが、照合対象が特定されてしまい少ない。ところが、別の応用においては、照合対象が多数存在するような場合がある。
【０１１５】
例えば、著作権をもつ書類データなどの不特定多数の画像符号化データと比較するような場合である。そのような場合にあっては、照合対象と比較する場合に階層構造を入れ替える負担も大きい。そこで、本発明では、照合対象の階層構造化の際の構造化傾向（プログレッション順の使用頻度）に合わせて、クライアントキャッシュ上の符号列の構成を予め最頻度のプログレッション順として符号データを形成する方法を提供している。
【０１１６】
図２７は、使用頻度を考慮したキャッシュデータの照合単位選択処理を示すフローチャートである。
クライアントの保存データ入替え単位選択処理は、データ照合要求を待ち（Ｓ６１）、照合要求受信がない場合（Ｓ６２／ない）、サーバ側から照合対象の使用傾向（プログレッション順の使用頻度）を受信し（Ｓ６３）、照合対象の使用傾向（プログレッション順の使用頻度）が最大であるプログレッション順を選択し（Ｓ６４）、プログレッション順に合わせた階層構造のキャッシュデータ生成処理を行って（Ｓ６５）、ステップＳ６１へ戻る。
【０１１７】
一方、照合要求受信があった場合（Ｓ６２／ある）、階層構造自体で照合を行う（Ｓ６７〜Ｓ６８）。
階層数と階層ごとに階層レベル数の照合を行い（Ｓ６６）、一致していない場合（Ｓ６７／ＹＥＳ）、結果を返して（Ｓ６８）、ステップＳ６１へ戻る。
一方、一致している場合（Ｓ６７／ＮＯ）、部分判別単位ごとに照合する（Ｓ６９〜Ｓ７１）。
まず、照合単位を選択し（Ｓ６９）、照合単位が区切り単位となるように階層データテーブルを再構成し（Ｓ７０）、照合処理を行って結果を返し（Ｓ７１）、ステップＳ６１へ戻る。
【０１１８】
サーバの照合対象の使用傾向記録処理では、符号データの使用を待ち（Ｓ７２）、符号データ使用があれば、符号データのプログレッション順に抽出し（Ｓ７３）、照合対象の使用傾向（プログレッション順の使用頻度）を記録して（Ｓ７４）、ステップＳ７２へ戻る。
【０１１９】
図２７の照合は、高頻度に使用する符号データのプログレッション順に基づいて照合する階層の選択をする。
また、図２７は、本発明の照合方法のひとつであるが、階層構造自体で照合する機能を有しており、符号データの階層構造の階層レベルで照合し、構造自体で比較する。より具体的には、階層符号データの階層数または階層符号データの階層毎の階層レベル数を比較することで早い段階で照合できる。階層数と階層レベル数で照合する。
【０１２０】
（７）階層を自動的に同じにして照合：
以下の説明は、階層構造自体の照合ではキャッシュに保存された符号データの階層構造（プログレッション順）を照合対象の符号データの階層構造（プログレッション順）とを一致させて照合する。
【０１２１】
図２８は、クライアントサーバモデルにおいてキャッシュデータの照合単位を選択して照合する処理を示すフローチャートである。
保存データ入替え単位選択処理は、データ照合要求待ち（Ｓ８１）、照合要求を受信する（Ｓ８２）。
次に、照合単位を選択し（Ｓ８３）、照合単位が区切り単位となるように階層データテーブルを再構成して（Ｓ８４）、データ照合単位を決定する。
次に、照合処理をして結果を返し（Ｓ８５）、ステップＳ８１へ戻る。
【０１２２】
図２９は、照合単位について説明するための図である。符号データの階層構造がテーブルタイプの構造テーブルで管理する場合を示す。構造テーブルの階層レベルの値によって要求された範囲の符号列を容易に特定することができる。
【０１２３】
図３０は、キャッシュ上の符号データの照合範囲の入れ替方法を説明するための概念図である。構造テーブルとしては、図１９で説明したテーブルタイプのものを示すが、図２０で示したツリータイプのものであっても同様である。互いに相互変換可能であるからである。構造テーブルの入れ替えとしては、階層レベルＮｏの記載された行の値によって列単位の順番を入れ替えることで実現する。即ち、最上位の階層の階層レベル順に列単位のデータを並び替え、続いて、次の階層の階層レベル順を上位階層のレベル順が損なわないように並び替え、続いて、同様な並び替えを下階層の階層レベルまで繰り返して処理する。
このようにして、キャッシュデータの照合単位を比較対象の符号データのプログレションにより変更される。
【０１２４】
図２２は、照合対象の使用傾向に基づく、照合の際の入替え単位の決定に係る概念図である。照合対象の符号データのプログレッション順（階層単位での並び順）に基づいて照合単位を決定する実現概念図を示す。この例では、階層は、解像度レベル、領域レベル、画質レベルで区分されており、プログレッション順の使用頻度によって最上位階層が解像度であった回数が２回、領域であったのが８回、画質であったのが３回であることから、大きい順番に符号データ入れ替え要求が多いものとして、構造データテーブルを構成し、最上位階層の単位で符号データを入れ替える。
【０１２５】
（８）キャッシュデータを並べ替えて照合：
図３１は、連続した物理領域への並べ替えに係る説明図である。
照合対象の符号データを構成する符号列の順番とキャッシュに保存されている符号列の順番とが同一であるように符号データをキャッシュに並び替えて保存して比較（照合）することを示す。
特に、厳密な符号データの一致を判定する場合に有効である。符号データの有無についても簡単に比較することができる。
【０１２６】
図３２は、キャッシュデータを並べ替え照合する処理を示すフローチャートである。
キャッシュデータの照合処理は、構造の照合を行い、構造をオリジナルの階層構造（プログレッション）と同じにすることによってオリジナルの階層符号データとの整合処理を行う（Ｓ９１）。
次に、照合する範囲の符号列をオリジナルの階層構造（プログレッション）で連続した物理領域にて並べ替え（Ｓ９２）、連続した物理領域に並べられた符号列群を互いに比較照合することによって、階層単位毎に照合する（Ｓ９３）。
最後に、符号データのアップデート更新処理を行って処理を終了する（Ｓ９４）。
【０１２７】
図３３は、メモリロケーションにおける照合に係る概念図である。記憶装置上に物理的な連続領域に符号データが保存され、部分領域単位で照合することを示している。符号列単位の区切りの範囲で互いに比較することで、部分照合を実現できる。照合対象の符号データとキャッシュに保存された符号データの同じ保存位置（先頭アドレスから同じメモリロケーション位置）の範囲を指定して該範囲にある符号データの照合をする。また、符号列の保存順の比較によって照合することもできる。
【０１２８】
図３４は、キャッシュデータの照合処理を示すフローチャートである。
クライアントのキャッシュデータの照合は、まず、符号データ全体の照合を行って、連続パケットが保存されている先頭アドレスを求め最後尾までのデータ長で比較し（Ｓ１０１）、データ長が一致、または、データ長が一致していてランダムに選んだ先頭アドレスから同じ長さのところに保存された符号が一致していれば（Ｓ１０２）、キャッシュデータの照合処理を行う（Ｓ１０３）。しかし、いずれも一致していなければ、不一致として処理を終了する（Ｓ１１３）。
【０１２９】
次に、部分符号データを照合する（Ｓ１０４〜Ｓ１１２）。
まず、照合単位（構造レベル）を構造データテーブルを使用して選択し（Ｓ１０４）、構造データテーブルを調べ、該範囲の部分符号データ（パケットの集合）を選択し（Ｓ１０５）、該範囲の部分符号データ（パケットの集合）の保存順で比較する（Ｓ１０６）。
不一致であれば（Ｓ１０７／ＮＯ）、不一致として処理を終了する（Ｓ１１３）。
一致していれば（Ｓ１０７／ＹＥＳ）、該範囲の部分符号データ（パケットの集合）の保存先である先頭アドレスと終端アドレスの部分データ長で比較する（Ｓ１０８）。
【０１３０】
部分データ長が不一致、または、データ長が一致していてランダムに選んだ先頭アドレスから同じ長さのところに保存された符号が不一致であれば（Ｓ１０９／ＹＥＳ）、不一致として処理を終了する（Ｓ１１３）。
一方、いずれも一致していれば（Ｓ１０９／ＮＯ）、パケット単位で該範囲の部分符号データ（パケットの集合）の保存先である先頭アドレスと終端アドレスの部分データ長で比較する（Ｓ１１０）。
【０１３１】
部分データ長が不一致、または、データ長が一致していてランダムに選んだ先頭アドレスから同じ長さのところに保存された符号が不一致であれば（Ｓ１１１／ＹＥＳ）、不一致として処理を終了する（Ｓ１１３）。
一方、いずれかが一致していれば（Ｓ１１１／ＮＯ）、キャッシュデータの照合処理を行って、処理を終了する（Ｓ１１２）。
【産業上の利用可能性】
【０１３２】
＜ｅ−文書法関連応用＞
近年、企業や自治体では、紙文書の保存のコスト削減や業務のスピードアップを図るため、大量に保存されている紙文書の電子化に対する要望が高まってきている。また、「ｅ−Ｊａｐａｎ」を推進する政府のＩＴ戦略本部では、法令により「紙」での保存が義務付けられている文書について、電子的な保存を認める法律（通称：「ｅ−文書法」）を施行すべく検討を進めている。ｅ−文書法は、法令により民間に保存が義務付けられている財務関係書類、税務関係書類等の文書・帳票について、電子での保存も容認するという法律である。
このような背景にあって、サーバに保存された機密文章の閲覧権限の制限が問題となる。本発明では、図１３に示しているような部分符号列を結合して重要なデータを併合（合成）して機密文書を不正に閲覧することを防止する効率的手段を提供する。また、構造化文書画像についても扱うことができる。
【図面の簡単な説明】
【０１３３】
【図１】階層符号化圧縮伸長アルゴリズムの基本の説明図である。
【図２】デコンポジション・レベルとサブバンドの説明図である。
【図３】タイル分割の基本の説明図である。
【図４】プレシンクトとコードブロックの説明図である。
【図５】コードストリームの構造の説明図である。
【図６】プレシンクト・データビンとメッセージとの関係を示す説明図である。
【図７】プレシンクト・データビンの例である。
【図８】キャッシュを持ったクライアントサーバモデルの構成図である。
【図９】クライアントサーバネットワークモデルの構成図である。
【図１０】出力表示例である。
【図１１】ＪＰＥＧ２０００のコードストリームのフォーマットである。
【図１２】ＪＰＥＧ２０００のコードストリームの例である。
【図１３】キャッシュデータとの照合の概念図である。
【図１４】クライアントサーバネットワークモデルの構成例である。
【図１５】クライアントサーバによる照合システムの構成図である。
【図１６】クライアントサーバモデルにおけるキャッシュデータの照合処理を示すフローチャートである。
【図１７】階層を選んで階層レベルでキャッシュデータの照合の基本処理を示すフローチャートである。
【図１８】照合処理部の構成図である。
【図１９】管理テーブルについての説明図である。
【図２０】保存データの構造を用いた符号長による照合に関する概念図である。
【図２１】キャッシュデータの構造化処理を示すフローチャートである。
【図２２】入れ替え単位の決定の説明図である（まとまって使用される単位でデータ照合）。
【図２３】キャッシュデータの構造化処理を示すフローチャートである。
【図２４】構造化文書データに関する構造管理テーブルの基本図である。
【図２５】階層を選んで階層レベルでキャッシュデータの照合の具体的処理を示すフローチャートである。
【図２６】符号長による照合処理を示すフローチャートである。
【図２７】キャッシュデータの照合単位選択処理を示すフローチャートである。
【図２８】キャッシュデータの照合単位選択処理を示すフローチャートである。
【図２９】照合単位についての説明図である。
【図３０】キャッシュ上の符号データの照合範囲の入れ替え方法を説明する概念図である。
【図３１】連続した物理領域への並び替えの説明図である。
【図３２】キャッシュデータを並び替え照合する処理を示すフローチャートである。
【図３３】メモリロケーションにおける照合の概念図である。
【図３４】キャッシュデータの照合処理を示すフローチャートである。
【符号の説明】
【０１３４】
１０１…クライアント、１０２…サーバ、１０３…キャッシュ、１０４…Ｊ２Ｋ復号器、１０５…出力画像、１０７…Ｊ２Ｋファイル、１０８…キャッシュ管理部、１０１０…符号データ解析部、１０１１…管理テーブル構造テーブル生成処理部、１０１２…管理テーブル構造テーブル変更処理部、１０１３…管理テーブル構造テーブル参照処理部、１０１４…符号データ保存処理部、１０１５…照合処理部、１０１５０…符号データ間整合処理部、１０１５１…階層単位毎の照合部、１０１５２…符号データのアップロード更新制御部、１１１…照合要求部、１１２…照合処理部、１１０…要求、１１３…応答、２０１，２０２，２２１，２２２，２４０…クライアント、２０３…サーバ、２１０，２１１…ＬＡＮ、２５０…大規模ネットワーク。
【図１】
2007043544.tif 000003
【図２】
2007043544.tif 000004
【図３】
2007043544.tif 000005
【図４】
2007043544.tif 000006
【図５】
2007043544.tif 000007
【図６】
2007043544.tif 000008
【図７】
2007043544.tif 000009
【図８】
2007043544.tif 000010
【図９】
2007043544.tif 000011
【図１０】
2007043544.tif 000012
【図１１】
2007043544.tif 000013
【図１２】
2007043544.tif 000014
【図１３】
2007043544.tif 000015
【図１４】
2007043544.tif 000016
【図１５】
2007043544.tif 000017
【図１６】
2007043544.tif 000018
【図１７】
2007043544.tif 000019
【図１８】
2007043544.tif 000020
【図１９】
2007043544.tif 000021
【図２０】
2007043544.tif 000022
【図２１】
2007043544.tif 000023
【図２２】
2007043544.tif 000024
【図２３】
2007043544.tif 000025
【図２４】
2007043544.tif 000026
【図２５】
2007043544.tif 000027
【図２６】
2007043544.tif 000028
【図２７】
2007043544.tif 000029
【図２８】
2007043544.tif 000030
【図２９】
2007043544.tif 000031
【図３０】
2007043544.tif 000032
【図３１】
2007043544.tif 000033
【図３２】
2007043544.tif 000034
【図３３】
2007043544.tif 000035
【図３４】
2007043544.tif 000036