(57)【要約】【課題】書類画像の一部へのネットワークアクセスのための新規な方法、装置及び製品をもたらすこと。【解決手段】一部の書類画像へのネットワークアクセスのための方法、装置及び製品が説明される。一実施例による方法は、書類中のページの或る領域を求めるクライアントから発せられるリクエストを受信するステップと、ページ中の領域を横切る、２つ又はそれより多くのコードストリームを有するソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップと、ファイル中の情報の一部分を含む応答を返すステップとを有する。【選択図】図１
2007234027.tif 000002
【特許請求の範囲】
【請求項１】
書類中のページの或る領域を求めるクライアントから発せられるリクエストを受信するステップと、
前記ページ中の前記領域を横切る、２つ又はそれより多くのコードストリームを有するソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップと、
前記ファイル中の情報の一部分を含む応答を返すステップと、
を有することを特徴とする方法。
【請求項２】
前記ソースファイルがJPMファイルである
ことを特徴とする請求項１記載の方法。
【請求項３】
前記要求がJPIPシンタックスを利用している
ことを特徴とする請求項１記載の方法。
【請求項４】
前記ソースファイル中の少なくとも１つのオブジェクトについてのロケーション情報を含む補助情報ファイルにアクセスするステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項５】
前記補助情報ファイルが、ページ情報、ページでの空間的位置情報及びファイルのデータ位置情報を前記ソースファイルの少なくとも１つのオブジェクトについて含んでいる
ことを特徴とする請求項４記載の方法。
【請求項６】
前記情報が、JPMファイルの少なくとも２つの異なるボックスから来ている
ことを特徴とする請求項５記載の方法。
【請求項７】
前記補助情報ファイルにアクセスするステップが、要求されたページの前記領域を横切る、前記ソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップ
を更に有することを特徴とする請求項４記載の方法。
【請求項８】
前記ソースファイルが複数のファイルタイプについての構造情報を含み、当該方法が、前記要求に基づいて複数のタイプの内の１つの構造情報を送信するステップを更に含む
ことを特徴とする請求項１記載の方法。
【請求項９】
前記ファイルのJPM部分及び前記ファイルのPDF部分双方へのアクセスをもたらすステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項１０】
前記ソースファイルが、有効なPDFファイルを含む
ことを特徴とする請求項１記載の方法。
【請求項１１】
前記ソースファイルが、JPMファイルを含むPDFファイルである
ことを特徴とする請求項１記載の方法。
【請求項１２】
前記ソースファイルが、クライアントがJPIPインタラクションを始めることを許すURLを含むPDFファイルである
ことを特徴とする請求項１記載の方法。
【請求項１３】
書類中のページの或る領域を求めるクライアントから発せられるリクエストを受信するネットワークインターフェースと、
前記ページ中の前記領域を横切る、ソースファイル中の１つ又はそれより多くのオブジェクトを確認するプロセッサと、
を有するサーバーであって、前記ソースファイルは２つ又はそれより多くのコードストリームを有し、当該サーバーは、前記ネットワークインターフェースを介して応答が送られるようにし、前記応答は前記ファイル中の情報の一部分を含む
ることを特徴とするサーバー。
【請求項１４】
前記ソースファイルがJPMファイルである
ことを特徴とする請求項１３記載のサーバー。
【請求項１５】
前記要求がJPIPシンタックスを利用している
ことを特徴とする請求項１３記載のサーバー。
【請求項１６】
前記ソースファイル中の少なくとも１つのオブジェクトについてのロケーション情報を含む補助情報ファイルが、前記プロセッサによりアクセスされる
ことを特徴とする請求項１記載のサーバー。
【請求項１７】
前記補助情報ファイルが、ページ情報、ページでの空間的位置情報及びファイルのデータ位置情報を前記ソースファイルの少なくとも１つのオブジェクトについて含んでいる
ことを特徴とする請求項１６記載のサーバー。
【請求項１８】
前記情報が、JPMファイルの少なくとも２つの異なるボックスから来ている
ことを特徴とする請求項１７記載のサーバー。
【請求項１９】
要求されたページの前記領域を横切るオブジェクトであって前記ソースファイル中の１つ又はそれより多くのオブジェクトが、前記プロセッサにより確認される
ことを特徴とする請求項１６記載のサーバー。
【請求項２０】
前記ソースファイルが複数のファイルタイプについての構造情報を含み、前記要求に基づいて複数のタイプの内の１つの構造情報が当該サーバーから送信される
ことを特徴とする請求項１３記載のサーバー。
【請求項２１】
前記ファイルのJPM部分及び前記ファイルのPDF部分双方が前記プロセッサによりアクセスされる
ことを特徴とする請求項１３記載のサーバー。
【請求項２２】
前記ソースファイルが、有効なPDFファイルを含む
ことを特徴とする請求項１３記載のサーバー。
【請求項２３】
前記ソースファイルが、JPMファイルを含むPDFファイルである
ことを特徴とする請求項１３記載のサーバー。
【請求項２４】
前記ソースファイルが、クライアントがJPIPインタラクションを始めることを許すURLを含むPDFファイルである
ことを特徴とする請求項１３記載のサーバー。
【請求項２５】
書類中のページの或る領域を求めるクライアントから発せられるリクエストを受信するステップと、
前記ページ中の前記領域を横切る、２つ又はそれより多くのコードストリームを有するソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップと、
前記ファイル中の情報の一部分を含む応答を返すステップと、
をコンピュータに実行させるコンピュータプログラム。
【請求項２６】
前記ソースファイルがJPMファイルである
ことを特徴とする請求項２５記載のコンピュータプログラム。
【請求項２７】
前記要求がJPIPシンタックスを利用している
ことを特徴とする請求項２５記載のコンピュータプログラム。
【請求項２８】
前記ソースファイル中の少なくとも１つのオブジェクトについてのロケーション情報を含む補助情報ファイルにアクセスするステップ
を更にコンピュータに実行させることを特徴とする請求項２５記載のコンピュータプログラム。
【請求項２９】
前記補助情報ファイルが、ページ情報、ページでの空間的位置情報及びファイルのデータ位置情報を前記ソースファイルの少なくとも１つのオブジェクトについて含んでいる
ことを特徴とする請求項２８記載のコンピュータプログラム。
【請求項３０】
前記情報が、JPMファイルの少なくとも２つの異なるボックスから来ている
ことを特徴とする請求項２９記載のコンピュータプログラム。
【請求項３１】
前記補助情報ファイルにアクセスするステップが、要求されたページの前記領域を横切る、前記ソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップ
を更にコンピュータに実行させることを特徴とする請求項２８記載のコンピュータプログラム。
【請求項３２】
前記ソースファイルが複数のファイルタイプについての構造情報を含み、当該コンピュータプログラムが、前記要求に基づいて複数のタイプの内の１つの構造情報を送信するステップを更にコンピュータに実行させる
ことを特徴とする請求項２５記載のコンピュータプログラム。
【請求項３３】
前記ファイルのJPM部分及び前記ファイルのPDF部分双方へのアクセスをもたらすステップ
を更にコンピュータに実行させることを特徴とする請求項２５記載のコンピュータプログラム。
【請求項３４】
前記ソースファイルが、有効なPDFファイルを含む
ことを特徴とする請求項２５記載のコンピュータプログラム。
【請求項３５】
前記ソースファイルが、JPMファイルを含むPDFファイルである
ことを特徴とする請求項２５記載のコンピュータプログラム。
【請求項３６】
前記ソースファイルが、クライアントがJPIPインタラクションを始めることを許すURLを含むPDFファイルである
ことを特徴とする請求項２５記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像データ処理の技術分野に関連し、特に本発明はネットワークアクセスを介して画像ファイルの一部にアクセスすることに関連する。
【背景技術】
【０００２】
JPEG2000は周知の圧縮規格である。この規格には多数のパートがあり、各パートは複数の付録−アネックス(Annex)を有する。
【０００３】
JPEG2000パート6は、公式にはISO/IEC15444-6:2003,Information  Technology−JPEG2000  image  coding  system−Part6：Compound  image  file  formatとして知られており、ここではJPM規格として言及される。この規格はJPMファイルの内容及び利用性を述べている。JPM規格のアネックスEは、「JPMファイルのコンストラクションURLに関するガイドライン」“Guidelines  for  Construction  URLs  for  JPM  Files.”と題するものである。JPM規格及びファイルフォーマットは、書類画像の格納に備えて設計され、JPEG2000及び他の方法(特に、G4,JBIG2及びJBIG)を介した圧縮を可能にし、G4等はテキストを含む２進画像を圧縮するのにJPEG2000よりも適している。
【０００４】
JPM規格は、JPMファイルにアクセスするのに有用かもしれない情報をリスト化するが、具体例でシンタックスを決めるに過ぎない。特に、“page=43”のようなリターンタイプの要求は決められていない。それは、JPMファイルレベルの如何なるボックスもなしに、JPMファイル中のページ４３に関連するボックス、ページ４３だけを含むように分析されたJPMファイル又はJPEG2000フォーマットで提示されたページに関連するかもしれない。
【０００５】
JPEG2000パート6アネックスEは、リクエストURLの例を列挙している。JPM規格アネックスEのリクエストURLの例は以下の項目を含む（BNFの形式で決められており、UINTは符号無しの整数であり、TOKENは何らかの制約を有する文字列である。）：
Page=UNIT/“thumb”
obj=UINT
type=“meta”/“img”/“thumb”
index=UINT
mtype=“text”/“xml”
label=string
coll=“main”/TOKEN
offset=UINT
len=UINT
JPEG2000パート9は、公式にはITU-T  Recommendation  T.808|ISO/IEC15444-9:2004,  Information  technology−JPEG2000  image  coding  system−Part9:  Interactivity  tools,APIs  and  protocols,(JPIP)と呼ばれ、ここでは一般にJPIP規格として言及され、ネットワークを介する対話式のJPEG2000画像伝送のシンタックス及びプロトコルを決めている。JPIPセクションC.4.7コードストリームコンテキストは、特定のファイルタイプに適切な高度の用語を用いて１以上のコードストリームにアクセスする手段になるように設計されている。このセクションは、JPXファイルの様々な構成レイヤに関するシンタックスを含み、それらは何らかの構造命令に依存してビューウインドウを修正する命令と共に、JPEG2000パート2で定義される。JPIPを有するこのシンタックスの利用例は“context=jpxl<0-4:2>[s5I２]”のようなものであり、これは構成レイヤ0,2,4を要求し、フレームサイズ及び画像領域を第6命令セットボックスの第3命令を用いて再配置する。JPIPのその同じセクションは、様々なトラックに関連するコードストリームをMJ2ファイルから如何にして取得するかをも説明しており、それはJPEG2000パート3及びJPEG2000パート12で決められている。
【０００６】
既存の他の書類伝送技術が存在する。例えば、リニアライズド（linearized）PDFはPDFフォーマットで書類画像を伝送する技術である。この技術は、ファイルの始めに格納されるインデックス情報を含む特殊なフォーマットでPDFを記述することによる。このやりとりはクライアントによって完全に制御される。具体例は以下の非特許文献１で説明されている。
【０００７】
NECはドキュメントスキッパー(Document  Skipper)と呼ばれる、書類画像への対話的なアクセスをもたらすサーバーソフトウエア製品を提供している。ドキュメントスキッパーは、MEAPを備えたキャノンの複合装置からJPEGフォーマットで画像を受信し、受信した画像を多重解像度及び空間的アクセスを提供するためにJPEG2000に変換する。
【非特許文献１】Rowe,  Edward  R.,  Priyadarshan,  Eswa;  Taft,  Edward  A.;  McQuarrie,  “Method  and  Apparatus  for  Reading  multi-page  electronic  documents,”  published  1998,  Adobe  Systems
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、ネットワークを介して画像ファイルの一部にアクセスするための新規な方法、装置及び製品を提供ことである。
【課題を解決するための手段】
【０００９】
一部の書類画像へのネットワークアクセスのための方法、装置及び製品が説明される。一実施例では、本方法は、書類中のページの或る領域を求めるクライアントから発せられるリクエストを受信するステップと、前記ページ中の前記領域を横切る、２つ又はそれより多くのコードストリームを有するソースファイル中の１つ又はそれより多くのオブジェクトを確認するステップと、前記ファイル中の情報の一部分を含む応答を返すステップとを有する方法である。
【発明を実施するための最良の形態】
【００１０】
本発明は本発明の様々な実施例に関する以下の説明により及び添付図面により更に十分に理解されるであろう。しかしながら本発明は具体的な実施例に限定されず、実施例は単なる説明及び理解を促すためのものに過ぎない。
【実施例１】
【００１１】
ネットワークを介して書類画像を伝送するための方法及び装置が説明される。一実施例では、ここで説明される技法は、JPMファイルに格納された書類画像についてJPIPの対話機能を提供する。その伝送をサポートするためのシンタックス例が説明されることに加えて、その書類画像伝送を取り扱うサーバー及びクライアントで使用される方法も説明される。
【００１２】
特定のサーバー実現法、特定のクライアント実現法及びジョイントPDF/JPMインタラクションも説明される。これらは、JPIP-JPM  (例えば、プレースホルダボックス使用法、プレファレンスマーカー使用法、キャッシュファイルでのURLの仕組み及びクライアント制御JPIP-JPM)及びPDF/JPM(例えば、JPEG2000及びJPIP-JPMを備えた他の圧縮ストリームを含むPDFファイルを提供すること、完全に有効なPDFファイルを含むJPMファイル、JPMファイルを含むPDFファイルを提供すること、JPM又は完全なPDFファイルの何れかとしてPDFを含むJPMファイルを提供すること、及び非常に小さな付加的な空間と共にJPM又はPDFを提供すること)の具体的な実現手段の詳細を含む。更に、ここで説明される技法はPDFファイルフォーマットと共にJPIP規格を使用する。コードストリームを繰り返さずに書類のPDF及びJPMバージョン双方を効率的に格納する技法も説明される。
【００１３】
以下の説明では、本発明の更に充実した説明をもたらすために多くの詳細な説明がなされる。しかしながら本発明はそれらの具体的詳細によらず実現されてもよいことは当業者に明白であろう。場合によっては、本発明を曖昧にすることを避けるため、周知の構造及び装置は、詳細なものではなくブロック図形式で示される。
【００１４】
以下の詳細な説明の或る部分は、コンピュータメモリ内のデータビットに関する処理の象徴的な表現及びアルゴリズムの観点からなされる。アルゴリズム的な説明及び表現は、当業者が彼らの業務内容を他者に最も効果的に伝えるために当業者により使用される手段である。ここでアルゴリズムは概して所望の結果に至る一貫した一連のステップと考えられる。これらのステップは物理量の物理的な処理を要するものである。通常的にはこれらの量は、必須ではないが、格納、転送、結合、比較及びその他の処理をすることが可能な電気的な又は磁気的な信号の形態をとる。一般的な使用法に起因して、ビット、値、エレメント、シンボル、キャラクタ、期間、数等でそれらの信号を示すことがしばしば便利であることが分かる。
【００１５】
しかしながら、これら及び類義語の全ては、適切な物理量に関連すること及びそれらの量に便宜的に付されたラベルに過ぎないことに留意を要する。以下の説明で明白なように、具体的に述べていない限り、本説明を通じて、「処理する(processing)」、「演算する(computing)」、「計算する(calculating)」、「決定する(determining)」又は「表示する(displaying)」等の用語を用いる議論は、コンピュータシステム又は同様な電子コンピュータ装置の動作及び処理に関連し、コンピュータシステム等は、そのコンピュータシステムのレジスタ及びメモリ内の物理的な（電子的な）量として表現されるデータを処理し、そのデータを、コンピュータシステムメモリ若しくはレジスタ内の又は他のそのような情報ストレージ、伝送若しくは表示装置内で物理量として表現される他の同様なデータに変換するものであることが理解されるべきである。
【００１６】
本発明はここでの処理を実行する装置にも関連する。この装置は要求される目的に応じて特別に構築されてもよいし、或いはコンピュータに格納されるコンピュータプログラムによって選択的に起動又は再構築される汎用コンピュータで構成されてもよい。そのようなコンピュータプログラムは、コンピュータ読み取り可能な媒体（限定ではないが、フロッピディスク、光ディスク、CD-ROM及び磁気光ディスクを含むディスク、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光カード等の如何なるタイプのものでもよい）の中に格納されてもよいし、電子命令を格納するのに適した如何なるタイプの媒体に格納されてもよく、それら各々はコンピュータシステムに結合される。
【００１７】
ここで提示されるアルゴリズム及び表示は特定のどのコンピュータにも他のどの装置にも固有に関連するものではない。様々な汎用システムがここで教示されるものに従うプログラムと共に使用されてよいし、或いは必要な方法ステップを実行するために更に特化された装置を構築することが有用であることが判明するかもしれない。様々なこれらのシステムに必要な構造は以下の説明から明白になるであろう。更に本発明は何らかの特定のプログラミング言語に関連して説明されるものではない。本発明の教示内容をここで説明されるように実現するために、様々なプログラミング言語が使用されてよいことが理解されるであろう。
【００１８】
機械(マシン)読み取り可能な媒体は、マシン(例えば、コンピュータ)で読み取り可能な形式で情報を格納及び伝送する如何なる手段をも含む。例えば、マシン読み取り可能な媒体はリードオンリメモリ(ROM)；ランダムアクセスメモリ(RAM)；磁気ディスクストレージ媒体；光ストレージ媒体；フラッシュメモリ装置；電気的に、光学的に、音響的に又はその他の形式で伝搬する信号（例えば、搬送波、赤外線信号、ディジタル信号等）；等である。
【００１９】
JPMファイルへのJPIPアクセス
JPIPはJPMファイルを供給するのに使用されてよい。JPIPでなされる要求及び応答の通信に関するシンタックスを用いて、JPM(書類画像)ファイルの一部をネットワークを介して伝送する技法が説明される。その際、ページの領域及び特定のオブジェクトへのアクセスがなされるかもしれない。JPIPで定義されたメタデータビン(bin)は、所望のウインドウを表現するのに必要なオブジェクトについてのコードストリームの全部又は一部を返すのに使用される。JPMソフトウエアは、JPMファイルの追加的デコードをもたらし、JPMファイルへのアクセスを提供するJPIPサーバーで必要なインデックス情報を用意（提供）する。クライアントの具体例及びサーバーの具体例が説明され、双方共にJPMファイルにアクセスするプロセスに含まれる。
【００２０】
図１はネットワークに接続されたクライアント及びサーバーの一例を示すブロック図である。図１を参照するに、ネットワークはクライアント１００及びサーバー１０１を接続する。クライアント１００はJPMファイル中のページの或る領域についての要求１１０を作成する。その要求はユーザインターフェースを利用するユーザに応じて生じてもよい。例えば、クライアント１００は画面上で左にスクロール、右にスクロール、上にスクロール、下にスクロール、拡大及び／又は縮小を行ってもよい。更に、ユーザはページを進めること、ページを戻すこと及びページオプションに飛ぶことをユーザインターフェースのボタン又は他のユーザインターフェース要素を用いて起動してもよい。要求はページナンバーを含んでもよい。
【００２１】
サーバー１０１は要求信号１１０を受信し、それに応じて、JPMファイル１２０のどのレイアウトオブジェクトが要求された領域を横切っている（intersect）かを確認する。サーバー１０１はファイルの概要(ファイルサマリー)を返送する。ファイルサマリーはファイルをデコードするのに必須のデータを含んでいてよいとしても、JPIP規格はそれをメタデータビンとして言及する。なぜなら画素をアッシュ記したサンプルデータではないからである。一実施例では、メタデータがメタデータビンで送信される（例えば、「メタデータビン０」）。サマリーはJPMファイル１２０から直接的にコピーしたいくつかのボックス、及び多数のボックスを置き換えるプレースホルダを含む（特に、コードストリームを含む多数のボックスに関し、一般にこれらのボックスはメディアデータボックス(mdat)又は連続コードストリームボックスである。）。「メタデータビン０」に加えて、サーバー１０１は、所望の領域を与えるためにクライアント１００に必要な他のボックス（例えば、コードストリーム）の一部を返送する。サーバー１０１は、クライアント１００に送った情報をクライアントキャッシュモデル１３０を用いて追跡し、クライアント１００がJPMファイルの一部についての追加要求をなした場合にその情報を再送しなくて済むようにする。
【００２２】
クライアント１００は要求１１０に対する応答１１１を受信し、それをキャッシュ１５０に格納する。JPMデコーダ１６０を利用して、クライアント１００は、その領域を表示するのに必要なキャッシュ１５０からコードストリームの圧縮を解除し（解凍し）、そのファイルからコードストリーム及び何らかの一定のカラーオブジェクトを構築し、与えられた画像１７０を表示する。
【００２３】
ユーザの入力に基づいて（又は前もって）、クライアント１００は以後JPMファイルの、様々な領域、様々なスケール又は様々なページについて新たな要求（図示せず）を行ってよい。サーバー１０１は新たな要求を調べ、おそらくは現在の応答をさえぎり、その新たな応答に相応しいデータを選択し、新たな応答に適切な以前には送信されてないデータを送信する。
【００２４】
メタデータビン及びプレースホルダボックスの概要
［データビン］
JPIPサーバーにより返されるデータはメッセージとして送信される。これらのメッセージは特定のデータビンからのバイトの集まりである。一実施例では、各メッセージはヘッダを含み、ヘッダはデータビンのタイプを区別し、そのタイプのデータビンからメッセージの内容（コンテンツ）がもたらされ、ヘッダはそのタイプのデータビンの数を区別する（ここでは「インクラスid(in  class  id)」として言及される。）。一実施例では、４つのタイプのデータビンがあり、それらは：メタデータ、メインヘッダ、タイル及び区域(precinct)である。メタデータ及びメインヘッダデータビンは、タイルベース（JPTストリーム）及び区域ベース（JPPストリーム）のJPIPサーバー双方によって使用される。タイルデータビンはJPTストリームセッションに関するJPEG2000コードストリームの一部を含む。区域データビンはJPPストリームセッションに関するJPEG2000コードストリームの一部を含む。ファイル中の非コードストリームデータの全てであるファイルフォーマット情報は、メタデータビンにより用意される。サーバー１０１は僅かな制約しか課せられていないメタデータビンにファイルをどのようにして分割するかを決定することができる。その制約はJPIP規格のセクションA.3に説明されている。
【００２５】
一実施例では、ファイルレベルの各ボックスはメタデータビン０内にあってもよいし、或いはメタデータビン０のボックスについてプレースホルダボックスがあってもよい。以下に説明されるプレースホルダボックスは、メタデータビン０に含まれていない何らかのボックスについてのメタデータビンを含む。→ここまで。
【００２６】
［プレースホルダボックス］
プレースホルダボックスはJPIP規格のセクションA.3.6.3で決められている。プレースホルダボックスは、オリジナルファイルがネットワークを介して送信され且つクライアントで格納される場合に、オリジナルファイルからボックスの場所を取得する。プレースホルダボックスはボックスであるので、プレースホルダボックスは長さ及びタイプ(‘plhd’)と共に始まる。プレースホルダボックスはオリジナルのボックス長さ及びタイプも含む。こうしてプレースホルダボックスを受信するクライアント１００は、置き換えられた情報のタイプを知る。プレースホルダボックスは、オリジナルボックスのコンテンツについてのメタデータビン番号も含む。メタデータビンはクライアント１００に利用可能でなくてもよい。つまり、多くの場合、クライアント１０１はオリジナルボックスのコンテンツを取得せず、そうして帯域を節約する。典型的には、サーバー１０１はメタデータビンのコンテンツを、それが要求に適切ならば送信する。
【００２７】
一実施例では、プレースホルダボックスは付加的な情報を含む。１つの選択的な情報は、コードストリームID番号である。この番号は、メタデータビンを用いるのではなく、JPTストリーム又はJPPストリーム(及びタイルデータビン又は区域データビン)を用いてコードストリームデータを通信するためにJPIPにより使用される。
【００２８】
要求及び応答についてのJPIP/JPMプロトコル要素
［リクエストエレメント］
一実施例では、或るページの或る領域についての一般的な要求(リクエスト)は、次のようなものである：
GET  /two_page.jpm?fsiz=370,218&rsiz=370,218&cid=16807&context=jpmp<2>  HTTP/1.1  
Host:www.example.com
上記の２行フォーマットはhttp及びJPIPプロトコルにより使用されるが；１行のユニバーサルリソースロケータURLのような要求を表現する方がより一般的であり、それを行うことについては後述されることに留意を要する。ブラウザはユーザ入力又はhtmlリンクからの１行URLを、そのチャネルでの伝送に使用される複数のリクエストに自動的に変換する。上記の要求は、次の等価なURLを有する：
http://www.example.com/two_page.jpm?fsiz=370,218&rsiz=3770,218&cid=16807&context=jpmp<2>
この要求の要素全部は通常のJPIPと同様であるが、所望のページ数を示すのに使用される“context=jpmp<2>”が異なる。“context=”の要求フィールドはJPIP規格で規定されており、このフィールドの用法はJPX及びMJ2をサポートするために規定される。JPIP規格に対する改訂１(amendment  1)は、JPMファイルのコンテンツフィールドの利用性を拡張する。
【００２９】
ページ番号に加えて、特定のレイアウトオブジェクト及びマスク又は画像領域を要求する機能がサポートされる。一実施例では、これは要求の中で指定されている情報を用いて達成される。要求シンタックスの一例はBNFで次のように与えられる：
【００３０】
【数１】
2007234027.tif 000003
このシンタックス(構文)では、マスクオブジェクトについての要求例は次のようになる：
context=jpmp<0>[1-3:mask]
この場合、サーバーは、第１ページ(上記のシンタックスでは“0”の番号が付されている)で初めの３つのレイアウトオブジェクト中のマスクオブジェクトに対応する全てのデータを返すように要求される。この要求は、例えばページボックス、レイアウトオブジェクトボックスだけでなくこれらのオブジェクトで参照される如何なるコードストリーム等でも、所望の領域を与えるのに必要な全てのボックスを含む。
【００３１】
かくてビューウインドウのない要求は次のようにできる：
jpip://www.example.com/file.jpm?context=jpmp<“figures”:2-3>[1-:mask]
これは“figures”のページ集合中のページ２及び３における全てのマスクオブジェクトを要求する。
【００３２】
より一般的で簡易な要求は、メインページコレクション中のページ２だけかもしれない：
http://www.example.com/file.jpm?context=jpmp<2>
JPIPの修正版の最も簡易な用法は、シングルページを与えるのに必要な全ての項目について要求が作成されることを許容する。より複雑な用法はレイアウトオブジェクトの一部分のみ又は或るタイプのオブジェクトのみの要求を許容する。一実施例では、jpmコンテキストは特定のページについての要求を含み；ページコレクション、レイアウトオブジェクトのリスト及びオブジェクトタイプについての仕様を含んでもよい。
【００３３】
ページコレクションが一切用意されない場合、JPMファイルからのメインページコレクションが仮定される。文字列(ストリング)が指定されていた場合には、それはターゲットJPMファイルのページコレクションボックスのラベルに対応する。
【００３４】
ある範囲のページはjpmコンテキストの要求部分になる。ページ範囲は“0−”でもよく、それはページコレクション中の全ページを指定する。一実施例では、JPMファイルのページ及びページコレクションの縦型探索(depth  first  search)を実行し、到達した最初のページに番号０を割り当て、次に１を割り当て、以下同様にすることでページに番号が付される。
【００３５】
Jpmコンテキストがjpmオブジェクトレンジ項目を一切含んでいなかったならば、それは“1−”であるように考えられ、それはページ中のサムネイルを除く全てのオブジェクトに対応する。jpmオブジェクトレンジは、jpmページレンジ中の全ページでどのレイアウトオブジェクトが要求されているかを示す。
【００３６】
jpmコンテンツがjpmオブジェクトを一切含んでいなかったならば、マスク及びイメージに加えて、そのマスク及びイメージの場所及び構成を理解するのに必要な他のボックスが要求される。jpmオブジェクトタイプが「マスク」であったならば、マスクオブジェクトだけがその要求についての関心事である。jpmオブジェクトタイプが「イメージ」であったならば、イメージオブジェクトだけが関心事である。jpmオブジェクトタイプが“nostrm”であったならば、コードストリームを含んでいないボックスのみが関心事である。
【００３７】
Jpmコンテキストパラメータがフレームサイズ要求(fsiz)のない要求の中に表れるならば、そのフレームサイズ値fx及びfyはページ幅及びページ高さに設定される。jpmコンテキストパラメータが領域サイズ要求(rsiz)のない要求の中に表れるならば、領域サイズ値rx及びryはフレームサイズ値fx及びfyに設定される（必要であれば、fx及びfyがページ幅及び高さに設定された後になされる。）。
【００３８】
［要求コードストリームの確認］
jpmコンテキストパラメータが使用される場合、その要求は各ページに独自に適用されるビューウインドウに対応する。フレームサイズ値fx及びfyは、JPM規格のページヘッダボックスのPwidth及びPheightエレメント(幅及び高さの要素)で指定されるようなページ幅及び高さに対応付けられる。
【００３９】
一実施例では、ページ内のレイアウトオブジェクトは、以下の全ての条件が真の場合であってその場合に限り、要求の一部と考えられる：
ox’<=LHoff+LWidth
ox’+sx’>=LHoff
oy’<=LVoff+LHeight
oy’+sy’>=Lvoff
ここで、
ox’=ox*Pwidth/fx
oy’=oy*Pheight/fy
sx’=sx*Pwidth/fx
sy’=sy*Pheight/fy
である。fx,fy,ox,oy,sx及びsyはビューウインドウ要求によって与えられ、LHoff,LVoff,LHeight及びLWidthはJPM規格のレイアウトオブジェクトヘッダボックスからのものである。
【００４０】
一実施例では、レイアウトオブジェクト０はそのページのサムネイル画像用に予約されており、０がjpmオブジェクトレンジに含まれていた場合であってその場合に限り、ビューウインドウによらず要求の一部が考察される。
【００４１】
［コードストリームビューウインドウパラメータの確認］
クライアントは、ビューウインドウとやりとりするマスク又はイメージに関する何らかのコードストリームを要求するように考えられる。言い換えれば、そのような場合に、サーバーはこれらのオブジェクトをクライアントにより要求されているように考える。コードストリームがJPEG2000で圧縮されていなかった場合、その要求は完全なコードストリームに関するものである。コードストリームがJPEG2000で圧縮されていた場合、ページ上のリクエストウインドウをオブジェクト上のリクエストウインドウに以下のようにマッピングすることで、等価なビューウインドウが特定のコードストリームについて決定可能である：
fx’=fx*Lwidth/Pwidth
fy’=fy*Lheight/Pheight
ox’=MAX(ox-LHoff*fx/Pwidth,0)
oy’=MAX(oy-LVoff*fy/Pheight,0)
sx’=MIN(ox+sx-LHoff*fx/Pwidth,Lwidth*fx/Pwidth)-ox’
sy’=MIN(oy+sy-LVoff*fy/Pheight,Lheight*fy/Pheight)-oy’
かくて、サーバーはJPMファイル上の１つの要求をJPEG2000コードストリーム上の１以上のリクエストに対応付ける。一実施例ではJPEG2000コードストリームでの要求は次のようにJPIPシンタックスを有する：
File.jp2?fsiz=fx’,fy’&roff=ox’,oy’&rsiz=sx’,xy’
ここで、プライムの付いた値(例えば、ox’)は整数のアスキー表現で置換される。
【００４２】
JPEG2000ファイルがそのページよりも高い解像度でデータを含んでいた場合、完全な解像度のJPEG2000コードストリームを得るために、そのページの幅及び高さより大きな値のフレームサイズ要求の発行が要求されてもよいことに留意を要する。代替的に、クライアントは、コードストリーム番号を決定し、適切に選択されたビューウインドウと共にそのコードストリームについて直接的に要求を発行してもよい。
【００４３】
［応答エレメント］
一実施例では、サーバーはJPIP規格のセクションA.3.6に規定されているようなメタデータビンと共に応答する。トップレベルのファイルはメタデータビン０に表れる。一部のボックス（特に、コードストリームを含む大きなボックス）はプレースホルダボックスで置換される。JPEG2000以外のコードストリームに関し、コードストリームが要求に必要とされていたならば、コードストリーム全体が送信される。要求されているJPEG2000コードストリームは、まさに他のコードストリームと同様にファイルから単にコピーすることで、又はJPPストリームやJPTストリームのデータビンを用いることで送信可能である（プレースホルダボックスは、このようにして用意されるコードストリーム各々についてコードストリーム番号を指示する。）。
【００４４】
JPMサーバーは、コンテキスト要求を修正する（典型的には、より小さなサイズに減らす）場合には、“http”ヘッダラインを含むことに留意を要する。JPMサーバーはこのヘッダラインを用いて、コンテキストレンジに関連するコードストリーム番号を指示する。
【００４５】
JPMサーバーの動作
一実施例では、JPMファイルをJPMサーバーから供給するために、補助レイアウトオブジェクト情報ファイルが作成され、JPMファイルとして同じディレクトリに格納される。これは以降の段落で「JPM情報ファイル(JPM  info  file)」と呼ばれる。このファイルはJPMファイル中のレイアウトオブジェクト全てのリストを含む。各オブジェクトについて、ページ番号、ｘオフセット、ｙオフセット、高さ及び幅が格納され、ある要求に関してオブジェクトが交差するか否かを判定するのに使用される。ページサイズはJPM情報ファイルにも含まれている。更に、各レイアウトオブジェクトについてコードストリームのJPMファイルのオフセットが格納される。
【００４６】
図２はJPMファイル、JPM情報ファイル及び特定のJPMファイルについてのJPMサーバーコンテンツを示す。図２を参照するに、JPMファイルに関してサーバーにより使用される表現は、JPMボックスタイプ２０１、JPMボックスサイズ２０２、メタデータビン０  ２０３及び別ボックス各々についての選択的な他のメタデータビン(例えば、２０４)を含む。サンプルJPMファイルの情報ファイル例２１０が、図２の下の部分に示されている。このファイル例のフィールドは次のとおりである：ページ番号（この例では、０でなく１から始まるページ番号）、ページ幅、ページ高さ、レイアウトオブジェクト数、オブジェクトタイプ（マスク、イメージ又は組み合わせられたマスクイメージ）、非コードストリーム、データ参照番号、ファイル中のコードストリームのオフセット、LHoff、LVoff、LWidth及びLHeight。
【００４７】
サーバーは、ファイル中のオブジェクトのリストを用いて、JPMファイル中のどのオブジェクトがクライアント要求で指定されている領域を横切っているかを見つける。一実施例では、サーバーは、そのサイズのページの表示を伸縮する機能を使用し、要求され伸縮された領域がとにかくオブジェクトを横切っていた場合に、「１」を返す。この判定はオブジェクトリストファイル中のオブジェクトの範囲、オブジェクト位置及びページサイズを必要とする。
【００４８】
サーバーは次にオブジェクトのリストを利用して、クライアントが指定領域を提供可能にするために送信されなければならないJPMファイルのボックスを確認する。一実施例では、オブジェクトに対するデータリファレンス番号及びそのファイルへのオフセットを利用することでサーバーはその機能を実行する。一実施例では、JPMサーバーは、要求がなされたのと同じファイル内のコードストリームだけ（即ち、ゼロのデータリファレンス番号を有するもののみ）を返し、クライアントはJPMファイル外からデータを受信するための別個のリクエストを発行する。
【００４９】
JPMファイルでのリクエストに関し、サーバーは要求されたファイルをスキャンし、全ボックス及び内部利用に備えたそれらの位置のリストを作成する。如何なる連続的なコードストリームもそれに関して作成されたプレースホルダを有する。メタデータビン及びプレースホルダボックスの詳細なJPIP規格については、セクションA.3.6を参照されたい。
【００５０】
JPMサーバーは何らかのファイルについての最初のリクエストと共にメタデータビン０を返す。このバイトストリームは、ファイル中のどのトップレベルボックスのプレースホルダをも又は完全なボックスを含んでいる。一実施例では、JPMサーバーは連続的なコードストリームボックスだけをプレースホルダボックスで置換する。別の実施例では、他のボックスがメタデータビンと置換される。例えば、サイズ閾値より大きな全てのボックスがメタデータビンで置換されてもよい。これは、大量のメタデータがJPMファイルに格納されていた場合に生じるかもしれない。
【００５１】
図２は左上にJPMファイルを示し、ボックスのサイズと共にリスト化された各トップレベルボックスがJPMファイルと共に示されている。JPMファイルの右側に、メタデータビン０のコンテンツが示されている。一実施例では、JPMサーバーはディスク上で又はメモリ内でメタデータビン０を完全には作成しない。メタデータビン０の一部であるボックスは、応答の一部として送信される場合に、オリジナルJPMファイルからコピーされる。プレースホルダボックスは、各コードストリームについてメモリ内に作成され、その応答の一部として送信される。
【００５２】
図２には、JPMファイルのJPM情報ファイルの内容も示されている。この場合の最大数はそのオブジェクトからオリジナルJPMファイルへのオフセットになる。ページ１を送信するために、JPMサーバーはページ１の全てのオブジェクトを調べ、各オブジェクトについて、どのコードストリームが必要とされるかを確認する。コードストリームはメタデータビン０から除外されているので、JPMサーバーは必要なコードストリーム各々について適切なメタデータを送信する。図２の例では、メタデータビン１，３が必要になる。
【００５３】
一実施例では、サーバーに利用可能なJPM情報ファイルを有しないJPMファイルについての要求が受信された場合に、JPMサーバーはJPM情報ファイルを自動的に生成する。或いは、JPM情報ファイルは、JPMファイルがサーバーに加えられたときに生成されてもよい。或いは、サーバーはJPM情報ファイルを保存することを全く必要とせず、情報はJPMファイルを供給するサーバーコードと共に統合されてもよい。そのような場合には、サーバーは各ファイルが開かれた時にオブジェクトリストを確認する。利用可能な情報ファイルを前もって持つことで、大きなJPMファイルを分析することに比べてしばしば高速化できる。
【００５４】
一実施例では、JPMサーバーは送信された全メタデータビンのバイト範囲を追跡するので、たとえ異なるレイアウトオブジェクトが同じコードストリームを利用しても、そのデータは一度だけしか送信されない。これは図２に示されており、オフセット16229及び1383のコードストリームが複数回使用されている。いくつかのレイアウトオブジェクトはコードストリームを一切有しない（例えば、JPM情報ファイルの6番目のエントリ）。JPMサーバーは、これらのレイアウトオブジェクトについてアクションを一切行わず、それらに必要なもの全てがそのレイアウトオブジェクト内で用意される。サーバーがページボックスを複数のデータビンに分割する場合には、JPM情報ファイルはどのメタデータビンが送信されるべきかを判定するためにも使用される。
【００５５】
一実施例では、JPMサーバーは、画像改善量に基づく順序でオブジェクトを送信する。上述したように、JPMサーバーは、要求された表示を横切る全てのオブジェクトを確認し、それらのオブジェクトをファイル中で表れた順序で返す。重なっている量が計算され、要求されるイメージと共に重なり（オーバーラップ）の大きい順にオブジェクトが返される。
【００５６】
一実施例では、JPMサーバーはメタデータビン以外のJPEG2000コードストリームを用意する。クライアント及びサーバー双方は部分的なJPEG2000コードストリームの伝送をサポートしているので、これらのコードストリームは、メタデータビンではなくタイルデータビンで又は区域データビンで送信される。
【００５７】
JPMクライアントの動作
JPMクライアントはユーザインターフェースを管理する。一実施例では、インターフェースは、マルチページJPMファイルの場合に以前のページ及び次のページへのアクセスを許容するボタンを含む。パン及びズーム操作用のボタン並びに他のユーザインターフェース要素が含まれていてもよい。
【００５８】
最初のページ以外のページを要求する場合、クライアントは“content=jpmp<n>”をクエリストリングに加える。クライアントはキャッシュディレクトリ中で受信したメタデータビン全てを、オリジナルファイルの名前、+“.cache.j2c”+“mc”+メタデータビンのクラス+“.bin”+メタデータビンのインクラスid番号と共に格納する。JPIP規格のアネックスＡは全てのデータビンクラスを指定する。メタデータビンはクラス８であり、JPMサーバーはファイル中で表れる連続的なコードストリームの順序でビンに番号を付ける。こうして“two_page.jpm”の最初のページについて全てのデータを受信した後に、JPMクライアントは以下のファイルと共にキャッシュを持つことになる：
-rw-r--r  1  gormish  wheel  1623  21  Feb  10:37  two_page.jpm.cache.j2c.mc8.bin0
-rw-r--r  1  gormish  wheel  8804  21  Feb  10:37  two_page.jpm.cache.j2c.mc8.bin1
-rw-r--r  1  gormish  wheel  223  21  Feb  10:37  two_page.jpm.cache.j2c.mc8.bin3
図３ではこれが図で説明されている。メタデータビン０は有効なJPMボックスを含むので、ファイルの始まりはJPMファイルである；しかしながら、JPMサーバーはプレースホルダボックス、JPMページボックスのファイルオフセット及び他のファイルオフセットで一部のボックスを置換しているので、ファイルの正確な場所を指し示さない。プレースホルダボックスは置換されるボックスより小さいので、そのオフセットはメタデータビン以外を指す傾向があり、正確な場所を指し示さないであろう。プレースホルダボックスで指示されるメタデータビン全てがクライアントに利用可能であるとは限らない。
【００５９】
一実施例では、メタデータビン０内のボックスは不正確なオフセットを有するので、JPMクライアントは新たな疑似JPMファイルを作成する。このファイルを作成するため、メタデータビンからの正規のボックスがコピーされ、プレースホルダボックスは、JPMサーバーから受信した適切なメタデータビンのコンテンツで置換される。メタデータビンが利用可能でない場合又は部分的にしか受信されなかった場合、クライアントは疑似JPMファイルを要求長の０バイト（又は何らかの他の値）で満たす。ボックスの適切なタイプ及び長さは、メタデータビン０のプレースホルダから分かることに留意を要する。今のこの疑似JPMファイルは提示されるボックスについて正確なオフセットを有するが、いくつかのjp2cボックスが正規のコードストリームを含んでいないので、それは「正規の」JPMファイルではない。
【００６０】
JPMサーバーが、要求されたビューウインドウで要求されたコードストリーム全てを送信したとすると、あたかも完全なファイルがJPMクライアントで利用可能であるかのように、クライアントはそのページの要求領域に適用する全てのビットをデコードし、同じ情報を表示することができる。
【００６１】
上述したように、一実施例では、連続的なコードストリームを除く全てのデータが、最初の要求と共に返される。メタデータが非常に長かった場合、メタデータは、要求される場合を除いて返されない。
【００６２】
一実施例では、JPMデコーダは失ったデータを処理し、おそらくはプレースホルダボックスを直接的に読み取る。この場合、デコード用に大きな「疑似JPM」ファイルを形成する必要はないかもしれない。サーバーは依然として項目を同じ順序及び一群のメタデータビンで伝送できるが、JPMデコーダは、オリジナルファイルのオフセットの場所を計算し、メタデータビン内の位置に変換しなければならない。
【００６３】
一実施例では、JPMクライアントは、受信していてもいなくても、メタデータビンに対する外部リファレンスを用いてJPMファイルを書き直すことで、失ったデータを処理する。受信したデータビンはデコード可能である。これはメタデータビン０とは異なるファイルを記述する必要があるが、そのファイルはゼロで満たされたファイルよりも実質的に小さく異であろう。外部リファレンスを用いることで、デコーダが外部ファイルのタイムスタンプを検査し、コードストリームが更新されているか否か及び再びデコードされるべきか否かを判定する。
【００６４】
一実施例ではJPMクライアント及びJPMサーバーは、ページ番号と共にリクエストをサポートする。例えば、これらのリクエストはページコレクション、ページ番号、レイアウトオブジェクト、マスク及びイメージについてのものでもよい。
【００６５】
一実施例では、JPMクライアント及びサーバーは、フラグメントテーブルをサポートする。フラグメントテーブルが使用される場合であって、フラグメントテーブルが例えば‘mdat’ボックスの中での内部オフセットを指定するならば、JPIPサーバーはコードストリームを含む‘mdat’についてのメタデータビンの部分だけを供給し、クライアントはこれらの部分だけを受信する場合にデコードすることができる。
【００６６】
［JPMデコーダ及び使用法］
一実施例では、JPMクライアントは受信したメタデータビンを別個のファイルに格納し、それは十分に効率的であって不要なデータの消去を許容する。しかしながら、JPMデコーダがJPIPで使用されるプレースホルダボックスを理解できなかったならば、受信した全てのデータのコピーがデコードされる毎に作成され、それに加えて、受信されてないデータについて疑似ファイルにゼロバイトが格納される。かくてクライアントはサーバーに格納したようなオリジナルのファイルサイズを２回利用する。
【００６７】
一実施例では、JPMデコーダはJPIPクライアントと共に統合される。そのような場合に、JPMデコーダはプレースホルダを読み取り、その情報を利用してJPMファイルの全ての場所でオフセットを訂正する。
【００６８】
JPMデコーダがJPIPと独立に使用される一実施例では、何らかのメタデータビンについての何らかの新たな情報は、必要なコードストリーム全てが再びデコードされることを引き起こす。これは不可避的である。なぜなら、JPMデコーダには完全に新たなファイルが与えられ、JPMデコーダはどの部分が新しくてどの部分が古いかが分からないからである。一実施例では、JPMデコーダはプレースホルダボックス及びメタデータビンを直接的に使用し、どのメタデータビンが新たな情報を有し、どのコードストリームが再びデコーされ構築される必要があるかを検出する。
【００６９】
ドキュメントスケルトン
一実施例では、比較的低速の電子リンクで伝送される信号量はスケルトンファイル(skeleton  file)を用いて調整され、スケルトンファイルは書類と同様に取り扱ってよいが、コードストリームの代わりにポインタを含んでいる。このスケルトンファイルはJPMファイルであってもよい。
【００７０】
JPMフォーマットはコードストリームフラグメントの概念を含む。コードストリームは、そのページの一部分について圧縮されたイメージデータである。フラグメントはコードストリームの連続的な部分であり、ファイル中の所定のバイト範囲内で発見される。ページを与えるのに必要なコードストリームフラグメントは、ヘッダと同じファイル内に格納可能である又はおそらくは或るネットワークを介してのみ利用可能な別のファイル内に格納可能である。必要なコードストリームフラグメントは、データリファレンスボックスと呼ばれるリファレンスのテーブル内のエントリを参照することで判別され、ファイル中のオフセット及びフラグメントの長さはフラグメントテーブルボックスに格納される。一実施例では、このJPMの特性はスケルトン書類を作るのに使用される。そのような書類は完全に有効なJPMファイルであるが、そのローカルファイル内の完全なページを与えるのに必要なコードストリームの小さな部分集合しか含んでいない。スケルトンファイル中のほとんどの又は全てのコードストリームは含まれておらず、リファレンスだけがファイルに含まれる。スケルトンファイルは、包含されるどのコードストリームもなしに、書類構造のコピーを作成することで作成されてよい。完全な書類からスケルトン書類を作成するために、処理論理装置(ロジック)は、ソース書類中のコードストリーム各々について、フラグメントテーブルボックス(ftbl)及びフラグメントリストボックス(flst)を作成する。ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータや専用マシンで動作するようなもの)又はそれらの組み合わせで構成されてよい論理装置で作成プロセスが実行される。一実施例では、コードストリームについて適切なブロックサイズが選択され、フラグメントリストが生成され、複数のブロックに予め区分けされる。このサイズは一定のバイト数でもよく、そのバイト数はネットワーク伝送に好都合なものであってもよいし、例えばJPEG2000コードストリームのタイルパートに対応するようなコードストリームのコンテンツに関連付けてもよい。
【００７１】
図４はクライアントにより又はユーザアプリケーションによりスケルトン書類と共に行われてよい動作を示すフローチャートである。図５はスケルトン書類例を示す。図５を参照するに、スケルトン書類は２つのフラグメントテーブルボックス(ftbl)501,502を含み、その各々は２つのエントリと共に１つのフラグメントリストボックスを含む。双方のエントリはソースファイル中のコードストリームデータを指す。
【００７２】
図４を参照するに、本プロセスは、例えば図５に示されるようなスケルトン書類を受信する又は取得することで開始される(処理ブロック４０１)。スケルトン書類が読み取られると、フラグメントテーブルボックスのポインタはアクセス可能になり、新たなコードストリームのフラグメントが受信される。この追加的なコードストリームデータは、メディアデータボックス(mdat)のファイルの後ろにバイトを付けることでローカルファイルに移動可能である(処理ブロック４０２)。処理論理は（ブロック５０１に見受けられるような）フラグメントリストエントリを新たな場所を指すように更新する（処理論理４０３）。一実施例では、フラグメントリストエントリはローカルファイル中の場所に対して変更されたオフセットを有し、データリファレンスエントリもそのローカルファイルを指すように変更される。フラグメントリストエントリは一定のサイズであるので、既存のコンテンツの新たなコピーを作成せずにファイルは適所に書き直されてよい。コードストリームフラグメントが１以上のメディアデータボックスのファイルに付けられると、処理ロジックも、添付されたデータの直後にフラグメントリストエントリのオリジナルコンテンツを記載する（処理ブロック４０４）。処理ブロック４０２，４０３及び４０４は何らかの順序でデータをファイルに転送するために何回も反復されてよい。ファイル中の全ての外部フラグメントについて処理が反復されると、必要なコードストリーム全てを含むファイルが取得され、どの部分を与える際にもソースファイルへのアクセスは必要でない。アプリケーションがメモリ又はディスクの空間を元に戻すよう希望するならば、その場所からオリジナルフラグメントテーブルエントリを復元し、ローカルコードストリームフラグメントを消去することで、mdatファイルに格納されていたオリジナルのフラグメントリストエントリが、ファイルからデータを除去するために使用される。
【００７３】
メディアデータボックスのスケルトン書類の後ろに全てのデータが添付され、フラグメントリストエントリは固定サイズなので、これはファイルの開始部分を書き直さずに行うことができる。重要なことに、オリジナルのスケルトンファイルは、固定長のフラグメントテーブルリストエントリを除く如何なるデータをも書き換える必要なしに、何度も更新可能である。処理論理(４０４)の完了後の各時点で、有効なファイルがローカルに利用可能である。その長さは変わらないので、これらの更新は限られたメモリで速やかに処理される。完全な新規ファイルを記述すること及び古いものを削除することの一般的な処理は必要ではなくなる。
【００７４】
十分なコードストリームが転送された後では、たいていはローカルファイルを指す読み取り可能な初期ページと共に有効なJPMファイルが存在する。一実施例では、第１ページは画像処理され、ネットワーク接続なしでさえも、そのカバーシートを評価可能にする。図６では、ローカルに格納されたデータ部分と共に及び依然としてソースファイル中の部分と共にJPMファイルの具体例が示されている。
【００７５】
一実施例では、図５のソースファイルはJPMファイルであり、そのJPMファイルからスケルトンファイルが引き出される。別の実施例では、コードストリームは個々のファイル内にあってもよいし、それらは他のファイルに含まれていてもよいし、特にそれらはPDF、SVG、SMIL又はフラッシュペーパーファイルの一部であってもよい。
【００７６】
コードストリームをどのようにして最良に区分するかを考察することは有意義である。１つの手法は１つの固定サイズのブロック化を使用することであり、この手法はJPEG及びJBIGのような比較的簡易なメディアエンコーディングに能く機能する。しかしながら、JPEG2000コードストリームはタイルサイズ及び解像度に基づいて特殊な区分けを行ってよい。そのような区分けは、特定のページ、ページ領域及び解像度が、適切なフラグメントを選択し且つ必要な領域に関連するコードストリームフラグメントだけを動かすことでロードされることを許容する。
【００７７】
ここで説明されるスケルトン書類は以下に説明されるように有利である。第１に、それらは有効なJPM書類である。また、それらは完全な書類よりも非常に小さく、速やかに伝送できる。ネットワークが利用可能でない場合に、ローカルに保持される部分的なコードストリームコンテンツと共に、スケルトン書類は書類のローカルなコピーに備えてキャッシュとして使用可能である。書類は完全に書き直さずに新たなコードストリームデータに添付可能であり、このことは容量の制限されたストレージ装置の場合に重要になる。コードストリームフラグメントは、特定の解像度での完全なページの効率的なコピーに備えて分析される。或る解像度での表示に十分な情報がローカルにキャッシュされているか否かが容易に確認でき、最小限の必要な情報の要求が可能になる。多くのキャッシュ済みコードストリームを有する書類は、スケルトン書類が通信チャネルを介して流れ出すように、スケルトンに迅速に切り詰められる。書類のキャッシュ済みコードストリームデータは移動可能であって置換可能であり、キャッシュの効率的な適切な管理を可能にする。
【００７８】
クライアントキャッシング
クライアントが部分的なJPMファイルを受信すると、いくらかのコードストリームは完全に受信されているかもしれないし、いくらかのコードストリームは全く受信されていないかもしれないし、いくらかのコードストリームは部分的に受信されているかもしれない。JPEG2000コードストリームが部分的に受信されている場合には、受信データはファイルを提供するのに非常に有用になり得る。例えば、あるJPMファイルについて低解像度情報を受信し、そのJPMファイルを低解像度表示装置で用意するクライアントは、その低解像度データが表示画像を形成するのに使用される場合に、最終的な画像に如何なる変化も目にしないかもしれない。
【００７９】
クライアントが更に高い解像度の画像バージョンを必要とするならば、おそらくはその画像が高解像度装置（例えばプリンタ）で表示されることに起因して又はユーザがその画像の或る領域を拡大したいことに起因して、クライアントはそのデータを求める新たな要求をサーバーに発行する。サーバーとのJPIPトランザクション(やりとり)に含まれているものに起因して及びそのトランザクションで受信したメッセージヘッダにアクセスしたことに起因して、クライアントは、より多くのデータが必要なことに気付く。しかしながら、クライアント及びサーバー間の接続がなされている場合であって、サーバーが状態情報をクライアントとのトランザクションから破棄してよいある時点では、サーバーはもはやクライアントキャッシュモデルを所有していない。
【００８０】
クライアントはサーバーとのトランザクションに関連する全てのファイルを、そのキャッシュの中で、ウェブクライアントと同様な手法で維持することができ、ウェブクライアントは何日かの間キャッシュを維持する又は或るメモリ制限に達するまでキャッシュを維持する。データを維持することは、ユーザが以前に見たデータを利用することを可能にする。
【００８１】
しかしながら、クライアントも受信した画像を或る形式で格納したいかもしれない。その形式は「通常の」デコーダに有利であり、その通常のデコーダは、クライアントのトランザクションメモリにアクセスしない、或いはメタデータビンのような特殊なJPIP構造をどのように処理するかの情報にアクセスしないものである。
【００８２】
一実施例では、JPIP-JPMキャッシュファイルを他のアプリケーションで有用なフォーマットで格納するために、及び追加的な状態情報を格納せずにサーバーとのやりとりをクライアントが再開するのを許容するために、クライアントは特殊なJPMファイルを使用する。このファイルは、ページコレクションボックス、ページボックス及びレイアウトオブジェクトボックスで表現されるようなJPMファイルの構造を含む。コードストリームの全部又は一部は、JPMファイルのデータリファレンスボックスで指定された場所を利用して外部に格納される。これはJPMスケルトンファイルに関する通常の状況である。しかしながら、通常的には、スケルトンファイルは、ディスク上のローカルファイル、サーバー上のファイル又はそれらの組み合わせに対するリファレンスを含む。
【００８３】
ストレージを取得し及び相互運用可能な恩恵を受けるために、データリファレンスボックス内の値は、ローカルに格納されるJPEG2000ファイルの一部に関する情報を含むことができ、その部分はリファレンスにおけるJPIPキャッシュモデルシンタックスを利用することでサーバーに格納される。
【００８４】
例えば、サーバーのexample.comがJPMファイルdocument.jpm(image1.j2kと呼ばれるJPEG2000コードストリームを利用する又は制限される)を用意し、クライアントはJPIPを介してそのファイルの一部を受信し、ローカルファイルimage1_cache.j2kにそれを格納するとする。クライアントは、そのバージョンのdocument.jpmを、次のようなデータリファレンスボックスのリファレンスと共に格納できる：
jpip://example.com/image1.j2k?fsiz=1024,1024&rsiz=1024,1024model=t*r0-2:L4
‘?’の後の部分はJPIPシンタックスであり；‘model=’で始まるJPIPシンタックスの部分は、そのクライアントが要求ウインドウの全てのタイル(t*)について解像度レベル0,1,2(r0-2)の最初の４つの品質レイヤ(L4)を有することを示す。かくてこのファイルを検査すると、デコーダは、そのファイルの部分が既に受信されており、即ちその部分はキャッシュモデルステートメントで示されていることが分かる。デコーダは、サーバーのexample.comから“image1.j2k”が格納されている場所の中でそのファイルのローカルな部分を（あたかもその画像について新たな要求がなされているかのように）探す。デコーダは、モデルステートメントを調べることで、より多くのファイルが必要か否かを確認し、データが存在するか否かを確認する（これは、ファイル全体を検査するよりも極めて迅速である。）。デコーダがJPEG2000コードストリームから更に多くのデータを必要としていた場合（ひょっとするとそれが印刷される場合に）、そのデータを取得するためのサーバーへの要求としてリファレンスが使用される。
【００８５】
このタイプのリファレンスは、タイル部分に基づくJPTストリームに特に有用である。この場合、キャッシュファイルは、サーバーから受信したデータの連結でもよく、追求要求による追加的なエータも添付されてよい。リファレンスは“tpmodel”が“model”の代わりに使用される点を除いて同じに見える。例えば、
jpip://example.com/image.j2k?fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1
のようなデータリファレンスエントリは、最初の６つのタイルからのタイルパート0,1がキャッシュファイルに存在することを示す。他のキャッシュモデルJPIPシンタックスは、  “tpneed”及び“need”を含む同様な目的に使用可能である。
【００８６】
別の可能性はキャッシュ中にファイルを示すデータリファレンスを使用することである。具体例は次のようなものである。file://my_browser_cache/image1_cache.j2k?fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1
この例では、オリジナルサーバーへのリンクがない。しかしながら、追加的な要求を行う予定が無く且つキャッシュファイルのデフォルト場所を知らないデコーダにとっては特に有用である。別の例では、URLはローカルファイルに使用されるが、サーバー上のロケーションを指定するためにJPIPターゲットファイルを使用する。例えば次のようなものである。
file:/tmp/cache1.jpm?target=www.example.com/server_dir/original_file.jpm&fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1
JPMはファイルが転送される場合に特に有用である。例えば、クライアント装置がファイルを取得し、JPMデコーダにそれが或るサイズであることを通知する場合、JPMデコーダはそのファイルをデコードする。クライアント装置は、如何なるネットワークアクセスもしないように且つ自身が有する情報と共にファイルを与えることしかしないように決定するかもしれない。しかしながら、別のクライアントである必要のあるクライアントがファイルを転送するように決定すると、そのクライアントはネットワークアクセスを確立し、自身が有するファイルコピーの中に未だ所有していない情報だけを要求することができる。
【００８７】
PDF/JPM動作
一実施例では、JPMファイルは１つ又はそれより多くのPDFファイルを含むことができる。図７にはその具体例が示されている。図７を参照するに、JPMファイル７００はボックス７０１と共に示されており、そのボックスはJPMファイル(シグネチャボックス(jp)、ファイルタイプボックス(ftyp))、コンパウンドイメージヘッダボックス(mhdr)、ページボックス(page)、ページコレクションボックス(ftbl)を始めとする。連続的なコードストリームボックス(jp2c)とは異なり、このJPMファイルはフラグメントリストボックス(flst)を含むフラグメントテーブルボックス(ftbl)を利用し、flstはコードストリームに対するオフセットを含む。JPMリーダーはメディアデータボックス(mdat)７０２に至るまでファイルを読み取り、フラグメントリストボックスからのオフセットを利用してそのコードストリームにアクセスする。しかしながら実際にはメディアデータボックスが完全なPDFファイル７０３を含んでいる。このPDFファイルは、JPEG2000コードストリーム704及びJBIG2コードストリーム705を含むPDFオブジェクトを含む。この構成ではPDFファイル703は正規の(legitimate)PDFファイルである。即ち、仮にJPMファイル700の他の部分が削除されたとすると、PDFファイル703はアドビアクロバットのようなPDFリーダーを用いて読み取ること及び開くことができる。しかしながら、JPMファイルそれ自身が他のJPMファイルと同じ形式で動作し、その情報、JPMヘッダ及びページ情報がJPEG2000コードストリーム704及びJBIG2コードストリーム705へのアクセスに使用されることを許可する。JPEG2000及びJBIGコードストリームの重複は一切無い。JPMファイル中のボックスの具体的な順序は一例に過ぎず、それ以外の多くの可能性があることに留意を要する。特に、MDATボックスがファイルの先頭近辺に現れるようにし、PDFファイルのようなファイルにアクセスする場合に、サーバーがそのJPM部分に一層迅速にスキップできるようにしてもよい。正規のJPMファイルをそのままにするため、順序に関して或る制約が存在する、即ちファイルタイプボックスはJPEG2000シグネチャボックスの後に続かなければならない。
【００８８】
PDFファイルは１つ又はそれより多くのJPMファイルを含んでよい。図８は１つのJPMファイルを含むPDFファイルの具体例を示す。図８を参照するに、PDFファイル８０１は、JPEG2000コードストリーム802、JBIG2コードストリーム803及びPDFアタッチメント804を含む。PDFアタッチメント804は、如何なるコードストリームも含まないJPM「スケルトン」ファイルを含む。その代わりJPMファイルは、PDFファイルの名称を提供するデータリファレンスボックス‘dtbl’を含む。JPMファイルはフラグメントリストボックスと共にフラグメントテーブルボックスも含む。フラグメントリストボックスは、JPEG2000及びJBIG2コードストリームのPDFのPDFファイル内でのオフセットを含む。PDFファイル800では、JPMヘッダ及びページ情報805がPDFファイルの後ろに現れているが、その項目はPDFファイルの定義に依存して様々なロケーションに格納可能である。JPMファイルがPDFファイルからコピーされるが、データリファレンスボックス内のリファレンスは依然としてPDFファイルを指す場合、独自のJPMファイルがPDFファイル内でコードストリームを捜し出して使用してもよい。図中JPMファイルが多くの空間を占めるかのように描かれているが、コードストリームのないJPMファイルの実際のファイルサイズはそれらのコードストリームより非常に小さいのが一般的である。
【００８９】
一実施例では、サーバーは１つのファイルから双方のフォーマットへのアクセスをもたらす。従って、装置からのリクエストを受信したことに応答して、そのリクエスト中の情報を介して又はクライアントとの過去の情報交換により、クライアント装置の能力を知っているサーバーは、１つのファイルを利用して必要な情報をクライアント装置に提供し、そのクライアント装置が書類を表示及び／又は処理できるようにする。例えば、スマートサーバーがクライアント装置はアクロバットリーダーを備えているがJPM情報を処理できないことを知っていた場合、スマートサーバーはJPMファイル700のようなファイルにアクセスし、JPMヘッダに関連する部分を破棄し、それによりクライアント装置に提供可能なPDFファイル703を残すことができる。同様に、クライアントから要求されたファイルがPDFファイル800のようなPDFファイルであって、スマートサーバーが、そのファイルを要求しているクライアント装置はPDFファイルを処理できないことを知っていた場合、スマートサーバーはJPMファイル情報(JPMヘッダ及びページ情報805、JPEG2000コードストリーム802及びJBIGコードストリーム803)をクライアント装置に提供してもよい。
【００９０】
図９はPDFファイル901及び別個のJPMファイル902を示す。この状況はあるサーバーでPDFファイル及びJPMファイル双方を提供に備えて維持しつつ、コードストリームだけをPDFファイルに維持するのに使用されるかもしれない。この状況は、JPMファイルが図８に示されるようなPDFファイルからコピーされる場合に起こる。この状況は、クライアントがネットワークを介してJPMスケルトンファイルを受信したが、そのＰＤＦファイルは依然としてサーバーにある場合にも起こる。
【００９１】
クライアントがJPMファイル及びJPIPデータビンを受信できる場合、サーバーは一部の書類コンテンツを求める要求に応答しても良い。JPMファイルヘッダ及びボックスを利用して、サーバーは必要なページやコードストリームを選択し、それらをメタデータビンに、タイルデータビンに及び区域データビンに含めることができる。サーバーでのフォーマットが実際にはPDFファイルであること又はJPMファイルがPDFファイルを含むことを、クライアントは知らなくてもよい。
【００９２】
サーバーでのフォーマットがPDFファイルを含むJPMファイルであった場合、ファイルのPDF部分がメタデータとしてクライアントに伝送可能である。そしてクライアントは受信したJPMデータビンからPDFファイルを再構築することができる。クライアントでのファイルは、PDF及びJPMリーダー双方で利用可能であるように二重の役割を再度演じてもよい。
【００９３】
コンピュータシステム例
図１０はここで説明された１つ又はそれより多くの動作を実行してよいコンピュータシステム例のブロック図である。図１０を参照するに、コンピュータシステム1000は例示的なクライアント又はサーバーコンピュータシステムを含んでよい。コンピュータシステムは複合装置(MFP:  Multi-Functional  Peripheral)の一部分でもよく、そのMFPは上述のJPIP/JPMファイル用のサーバーとして機能してもよいし、或いはクライアントとして機能してもよい。
【００９４】
コンピュータシステム1000は、情報を通信するための通信手段又はバス1011、及び情報を処理するためにバス1011に結合されたプロセッサ1012を含む。プロセッサ1012はマイクロプロセッサを含み、マイクロプロセッサは、限定ではないが、例えばペンティアム(登録商標)、パワーPC(商標)、アルファ(商標)等である。
【００９５】
システム1000は、プロセッサ1012で実行される命令や情報を格納するためにバス1011に結合されたランダムアクセスメモリ(RAM)又は他のダイナミックストレージ装置1004(メインメモリと言及される)を含む。メインメモリ1004はプロセッサ1012による命令の実行中に一時的な変数その他の中間的な情報を格納するように使用されてもよい。
【００９６】
また、コンピュータシステム1000は、プロセッサ1012用の命令や静的な情報を記憶するためにバス1011に結合されたリードオンリメモリ(ROM)及び／又は他のスタティックストレージ装置1006と、磁気ディスク又は光ディスク及びその対応するディスクドライブのようなデータストレージ装置1007とを含む。
【００９７】
コンピュータシステム1000は、コンピュータユーザに情報を表示するためにバス1011に結合された、陰極線管(CRT)又は液晶ディスプレイ(LCD)のような表示装置1021にも結合されてよい。英数字入力装置1022は、英数字及び他のキーを含み、情報及び命令選択内容をプロセッサ1012に通知するためにバス1011に結合されてもよい。更なるユーザ入力装置はマウス、トラックボール、トラックパッド、スタイラス又はカーソル方向キーのようなカーソル制御部1023であり、方向情報及びコマンド選択内容をプロセッサ1012に通知するために及びディスプレイ1021でのカーソルの動きを制御するためにバス1011に結合される。
【００９８】
バス1011に結合されてよい他の装置はハードコピー装置1024であり、それは紙やフィルムのような媒体に又は同様なタイプの媒体に情報を記す（記録する）ために使用される。バス1011に結合されてよい他の装置は、電話機又は携帯装置と通信する有線／無線通信機能部1025である。
【００９９】
システム1000及び関連するハードウエアの構成要素のどれでも又は全てが本発明で使用されてよいことに留意を要する。しかしながらコンピュータシステムの他の構成例は本装置の全部又は一部を含んでよいことが理解されるであろう。
【０１００】
本発明に関する多くの代替例及び修正例は本説明を読み終えた当業者にとっては疑いなく明白になり、例示的に提示及び説明された特定のどの実施例も限定的に解釈されることを意図するものでないことは理解されるべきである。従って、様々な実施例の詳細に関するものは、特許請求の範囲を限定しようとするものではなく、特許請求の範囲が本発明に本質的な特徴だけを記載している。
【０１０１】
以下、本件基礎出願の第１４項以降に列挙されている手段を例示的に列挙する。
【０１０２】
（付記１４）
要求を生成するステップと、
メタデータビン中にJPMソースファイルのサマリーを有する応答を受信するステップと、
を有することを特徴とする方法。
【０１０３】
（付記１５）
前記サマリーをファイル形式で格納し、前記ファイルに対応するトランザクションメモリにアクセスすることなしに１以上のアプリケーションでファイルを利用可能にするステップを更に有する
ことを特徴とする付記１４記載の方法。
【０１０４】
（付記１６）
プレースホルダボックスを一切含まない新たな疑似JPMファイルを前記要求から作成するステップを更に含む
ことを特徴とする付記１４記載の方法。
【０１０５】
（付記１７）
メタデータビンが利用可能でなかった場合又は部分的にしか受信されなかった場合に、前記新たな疑似JPMファイルを埋め込みバイトで満たすステップを更に有する
ことを特徴とする付記１６記載の方法。
【０１０６】
（付記１８）
前記疑似JPMファイルにより参照される１以上のコードストリームの部分が、前記ファイル外部の場所に格納され、該場所は前記疑似JPMファイルのデータリファレンスボックスで指定される
ことを特徴とする付記１６記載の方法。
【０１０７】
（付記１９）
前記疑似JPMファイルが、メタデータビンについての外部リファレンスを含む
ことを特徴とする付記１６記載の方法。
【０１０８】
（付記２０）
前記応答からの少なくとも１つのメタデータビンを、キャッシュディレクトリ内に、前記少なくとも１つのメタデータビンに関連するオリジナルファイルを示す情報と共に格納するステップを更に有する
ことを特徴とする付記１４記載の方法。
【０１０９】
（付記２１）
前記情報が、ユニフォームリソースロケータ(URL)を含む
ことを特徴とする付記２０記載の方法。
【０１１０】
（付記２２）
前記少なくとも１つのメタデータビンが、ローカルに格納されているJPEG2000コードストリームの量及びサーバーに格納されているJPEG2000コードストリームの量を表す情報を含むデータリファレンスボックスを有する
ことを特徴とする付記２０記載の方法。
【０１１１】
（付記２３）
前記データリファレンスボックスが、JPIPキャッシュモデルシンタックスを使用する情報を含む
ことを特徴とする付記２２記載の方法。
【０１１２】
（付記２４）
データが前記ファイル中に有るか否かの判定に基づいて、前記ファイルの追加的なデータの要否を判定するステップと、
前記ファイル中のリファレンスを用いてサーバーから前記追加的なデータを要求するステップと、
を更に有することを特徴とする付記１４記載の方法。
【０１１３】
（付記２５）
PDFファイル内のJPMスケルトンファイルを用いてサーバーにアクセスするステップ
を更に有することを特徴とする付記１４記載の方法。
【０１１４】
（付記２６）
前記サーバーが、PDFファイルに含まれている情報により確認される
ことを特徴とする付記２５記載の方法。
【０１１５】
（付記２７）
前記サーバーにアクセスするステップが、前記PDFファイルに基づいて、コードストリームフラグメントにアクセスするためにクライアントがJPIP要求を始めるステップを有する
ことを特徴とする付記２５記載の方法。
【０１１６】
（付記２８）
ネットワークに対してリクエストを発行し、メタデータビン中にJPMファイルのサマリーを含む応答を受信するネットワークインターフェースと、
前記ネットワークインターフェースに結合され、前記サマリーを処理するプロセッサと、
を有することを特徴とするコンピュータシステム。
【０１１７】
（付記２９）
スケルトンファイルを読み取るステップと、
1以上のメディアデータボックス中のファイルの後ろにコードストリームフラグメントのバイトを付けるステップと、
1以上のフラグメントリストエントリを、各々が前記ファイル中の各自のオフセットを指すように書き直すステップと、
前記ファイル中のリファレンスを、データがもはや前記ファイル外でないことを示すように変えるステップと、
を有することを特徴とする方法。
【０１１８】
（付記３０）
前記フラグメントリストエントリの当初の値を、前記ファイルの後に付けられるコードストリームフラグメントと共に格納するステップを更に有する
ことを特徴とする付記２９記載の方法。
【０１１９】
（付記３１）
コードストリームデータを前記スケルトンファイルから除去し、フラグメントリストボックスでの情報を復元し、スケルトンファイルを作成するステップを更に有する
ことを特徴とする付記２９記載の方法。
【図面の簡単な説明】
【０１２０】
【図１】クライアント−サーバーネットワークの一例を示すブロック図である。
【図２】サーバー及びクライアントに関するJPMファイル及び表現物の内容を示す図である。
【図３】JPM書類例の内容を示す図である。
【図４】スケルトン書類を利用するプロセスのフローチャートである。
【図５】JPM書類としてのスケルトン書類例を示す図である。
【図６】ローカルコードストリームフラグメントを有するスケルトン書類例を示す図である。
【図７】PDFファイルを含むJPMファイル例を示す図である。
【図８】１以上のJPMファイルを含むPDFファイル例を示す図である。
【図９】PDFファイルを参照するJPMファイル例を示す図である。
【図１０】コンピュータシステムの一例を示すブロック図である。
【符号の説明】
【０１２１】
１００  クライアント
１０１  サーバー
１２０  JPMファイル
１３０  クライアントキャッシュモデル
１５０  キャッシュ
１６０  JPMデコーダ
２０１  JPMボックスタイプ
２０２  JPMボックスサイズ
２０３，２０４  メタデータビン
２１０  JPM情報ファイル
５０１，５０２  フラグメントテーブルボックス
７００  JPMファイル
７０１  ページコレクションボックス
７０２  メディアデータボックス
７０３  PDFファイル
７０４  JPEG2000コードストリーム
７０５  JBIG2コードストリーム
８０１  PDFファイル
８０２  JPEG2000コードストリーム
８０３  JBIG2コードストリーム
８０４  PDFアタッチメント
８０５  JPMファイル
９０１  PDFファイル
９０２  JPMファイル
１００４  メインメモリ
１００６  スタティックメモリ
１００７  大容量ストレージメモリ
１０１１  バス
１０１２  プロセッサ
１０２１  ディスプレイ
１０２２  キーボード
１０２３  カーソル制御装置
１０２４  ハードコピー装置
１０２５  無線通信部
【図１】
2007234027.tif 000004
【図２】
2007234027.tif 000005
【図３】
2007234027.tif 000006
【図４】
2007234027.tif 000007
【図５】
2007234027.tif 000008
【図６】
2007234027.tif 000009
【図７】
2007234027.tif 000010
【図８】
2007234027.tif 000011
【図９】
2007234027.tif 000012
【図１０】
2007234027.tif 000013