JP2005033801A - 部分的な書類画像へのネットワークアクセスを行なう方法、製造品及び装置 - Google Patents

Abstract

【課題】 １以上の要求に応答して、ネットワークを介して書類画像の一部を転送する方法及び装置を提供すること。
【解決手段】 一実施例では、本方法は、ＪＰＭファイルの複数部分についての複数の要求を受信し、その複数の要求に応答してＪＰＭファイルを部分的に送信する。
【選択図】 図２

Description

本発明は、ネットワークその他の通信チャネルを介して部分的な書類画像を転送する技術分野に関連し；特に、本発明は、要求に応じてＪＰＭファイルの部分を転送することに関する。

［ＪＰＥＧ２０００］
図１（Ａ）〜（Ｄ）は、一般的なＪＰＥＧ２０００システムにより実行される動作を示す。図１（Ａ）を参照するに、オリジナル画像（原画）が、タイル１０１のような規則的なタイルに分割される。これらのタイルは独立して圧縮される。従って、左上のタイルからの符号化データは、その画像の左上部分を再構築するのに充分である。同様に、その領域を分割する全てのタイルからのデータを取得すること、及びそれらをデコードすることによって、任意の領域が再構築されることが可能である。

各タイルに２次元ウエーブレット変換が施される。これは、サブバンド１０２のようなサブバンドにグループ化された一群のウエーブレット係数を導出する。サブバンドの１つは、その画像についての低解像度バージョンであり−−その画像及びサブサンプリング全体に特定のローパスフィルタを適用することで取得されるであろう画像と厳密に同じである。重要なことに、その画像についての中程度の解像度バージョンを形成するために、サブバンドは他のサブバンドと組合わせられることが可能である。これは、図１（Ｃ）に示されている。こうして、ＪＰＥＧ２０００コードストリームは画像へのアクセスを与え、その画像は、低解像度におけるもの及びその画像の最高の解像度に至るまでの水平及び垂直に２の因子だけ大きい解像度におけるものである。

ウエーブレット変換係数は再グループ化され、即ち図１（Ｂ）に示されるような「区域又は境界（ｐｒｅｃｉｎｃｔ）」に分割される。これらの区域は画像の空間領域にアクセスする別の手法を形成する。画像を圧縮する場合に、タイル及び区域は共に使用されることができる。両者が使用される場合に、タイルはその画像の領域への粗粒度（ｃｏａｒｓｅ ｇｒａｉｎ）のアクセスを与えるが、区域はより局所的な領域へのアクセスを与える。

最終的に、区域はコードブロックに分割され、ウエーブレット係数のこれらのグループは、最上位ビットに始まり最下位ビットに続く複数のパスと共に圧縮される。これらは図１（Ｄ）に示される。これらの「符号化パス（ｃｏｄｉｎｇ−ｐａｓｓ）」は、非損失的手法における統計的な冗長性を排除する。例えば、多数のゼロビットは、非常に短いコードによって置換される。ウエーブレット係数の固定サイズのブロックは、符号化データの可変長セグメントになる。セグメントの先頭部分は最も重要である、というのは、それがウエーブレット係数の最上位ビットに対応するからである。符号化データセグメントの後方部分がデコーダに利用可能でないならば、依然として画像が取得されることは可能であるが、それは低品質になる。

「コードストリーム」は、一連の「マーカーセグメント」より成るようなＪＰＥＧ２０００パート１に規定され、そのセグメントは、本質的には、データが続くコードストリーム中のデータの次のビットを識別する２バイトコードである。コードストリームは、その画像についてのエントロピー符号化データ全体と、その符号化データをデコードするために使用されるべき方法を記述するデータとを含む。例えば、コードストリームは、使用されるウエーブレット変換、タイルのサイズ、区域のサイズに関する情報、解像度数やファイル中のパケット順序等についての情報を含む。コードストリームは、エントロピー符号化データを画像サンプルにデコードするのに必要な全てのパラメータを含む必要がある。また、コードストリームは、例えばパケット長のような、符号化データの一部への速やかなアクセスを与えるための情報を含んでもよい。

「ファイルフォーマット」は、１以上のコードストリームについてのラッパ（ｗｒａｐｐｅｒ）である。ＪＰＥＧ２００１パート１は、単なる「ＪＰ２」ファイルフォーマットを規定する。ＪＰＥＧ２０００パート２は、より複雑な情報を格納するための「ＪＰＸ」フォーマットを規定する。ＪＰＥＧ２０００パート３は、動画ＪＰＥＧ２０００に関する「ＭＪ２」ファイルフォーマットを規定する。

ファイルフォーマットは、一般的には、音声、ＸＭＬ情報、画像捕捉条件等のような、コードストリームに含まれる画像データに関連付けられる「メタデータ」を提供する。また、ファイルフォーマットは、デコードされた画像データの色空間に関する情報を一般的には包含する。

ＪＰＥＧ２０００パート６は、複合的な書類に対する「ＪＰＭ」ファイルフォーマットを規定する。ＪＰＥＧ２０００コードストリームを含むことが可能なファイルフォーマットであってＪＰＥＧ２０００委員会により定義されていないファイルフォーマットも存在する。ＰＤＦはＪＰＥＧ２０００コードストリームを許容するように最近更新された。ＰＤＦ及びＪＰＭは、複数頁を有する書類に関する良いファイルフォーマットである。

［ＪＰＩＰ］
ＪＰＩＰはＪＰＥＧ２０００インタラクティブプロトコルを表し、国際規格ＩＳＯ／ＩＥＣ１５４４４−９になる。最終ドラフト段階に近づきつつあるＪＰＥＧ委員会は、この書類についての作業を行なっている。現在の書類は、“１５４４４−９（ＪＰＩＰ）ＥＣＤＳｔｕｄｙＴｅｘｔ０．１”ＩＳＯ／ＩＥＣ ＪＴＣ１ ＳＣ２９／ＷＧ１ Ｎ２３９６である。

ＪＰＩＰは、画像の一部についてサーバに要求を行なうためにクライアントが使用することの可能なシンタックスを規定する。また、ＪＰＩＰは２つの新しい「メディアタイプ」を規定し、それらはサーバがＪＰＥＧ２０００ファイル又はコードストリームの一部を返すために使用することができる。ＪＰＩＰの主な又はキーとなるファセットは、相互作用することになっていることである。したがって、同一画像からより多くのデータに関する要求を追跡することができ、返されるデータは、クライアントが既に受信したデータを反復する必要はない。

［ＪＰＩＰ要求］
ＪＰＩＰは、要求を行なうクライアントによって使用されることの可能ないくつかのパラメータを規定する。これらの要求は、クライアントが関心を持つサブ画像を示す。また、要求は、ユーザが関心を寄せるメタデータについての情報及びサーバにより与えられる応答種別を制御するための情報を提供してもよい。この開示目的に関するこれらのパラメータの内最も重要なものは、フレームサイズ、領域オフセット及び領域サイズである。

フレームサイズパラメータは、いくつかの例の中で“ｆｓｉｚ＝１２８，１２８”のように表され、領域にアクセスするためにクライアントが使用することを希望する画像全体のサイズを示す。（以下に説明されるように）何らの領域サイズパラメータもなければ、フレームサイズは、単に、クライアントが希望する画像サイズである。例えば、５１２×５１２のサンプルであって４レベルのウエーブレット変換によりエンコードされる画像は、５１２×５１２、２５６×２５６、１２８×１２８、６４×６４又は３２×３２のフレームサイズによりアクセスされることが可能である。サーバへの最初の要求では、クライアントは、利用可能な実際のフレームサイズを知らないかもしれない。その場合は、クライアントは希望するサイズ及び配信方法を示すことができ、サーバはそれに最も近いサイズを返すであろう（他のパラメータは、使用される実際のフレームサイズに適合するようにスケール化又は尺度変更されるであろう。）。

領域オフセットパラメータは、「ｒｏｆｆ＝６４，６４」のように使用され、これは、クライアントはその画像全体に関心はないが、その要求で与えられる２つの値で指定されるオフセットで始まる領域だけには関心があることを示す。オフセットは、要求フレームサイズに相対的である。

領域サイズパラメータは「ｒｓｉｚ＝６４，６４」のように使用され、クライアントによって望まれる領域のサイズを示す。３つのパラメータｆｓｉｚ，ｒｓｉｚ及びｒｏｆｆを与える代わりに、クライアントは、関心領域（ＲＯＩ：ｒｅｇｉｏｎｓ ｏｆ ｉｎｔｅｒｅｓｔ）の「ｒｏｉ」パラメータにより規定される、ファイル又はサーバの中での関心性を示してもよい。ｒｏｉパラメータは、ファイルフォーマットボックスの１つにて識別される言及された領域を要求するために使用されることが可能である。その値は、クライアントの何らかの知識に基づいて、サーバが適切な領域を選択すべきことを示すように、「ｒｏｉ＝ダイナミック」のように「ダイナミック」（動的に）に設定されてもよい。

［応答（レスポンス）］
ＪＰＩＰ応答は、３つの主要な形式をとることができ、それらは：完全画像ファイル、ＪＰＩストリームとも呼ばれるタイル−部分ストリーム、又はＪＰＰストリームとも呼ばれる区域ストリームである。完全画像ファイルリターン形式は、本質的には、その要求に基づいて生成されたカスタムファイルを返すようなものである。２つのストリーム種別は、一連の小さな「メッセージ」より成る複合的なレスポンスである。各メッセージは、そのタイプ、そのタイプ内のインデックス、そのタイプ及びインデックスに関する「データビン（ｄａｔａ−ｂｉｎ）」へのメッセージのオフセット、及びメッセージ長を識別するヘッダを有する。「データビン」は、クライアントがサーバ上のリソースに関して今までに要求した全情報を表すものと考えられる。単独の要求に応じて、サーバは幾つかの異なるデータビンの一部を配信してもよい。メッセージは典型的には完全なデータビンを含まず；その代わりに、クライアントに未だ送られていないデータビンの次の一部分を含む。小さなメッセージサイズは、画像の様々な部分に関するデータがインターリーブされることを許容し、クライアントにより指定された領域は、品質面で均一的にすることができる。同様に、画像データはメタデータと供にインターリーブされてもよい。各メッセージの長さを与えることは、そのストリームが任意のメッセージの末端で手際よく（エレガントに）終了することを可能にする。これは、サーバが１つの要求への応答を停止すること及び同じ通信チャネルでの新たな要求に応答開始することを可能にする。

［ＪＰＭ］
ＪＰＭは書類画像用の格納部（ストレージ）を与える。ＪＰＥＧ２０００により圧縮された画像を包含するために一般的に使用される他のファイルフォーマットを上回るＪＰＭの主な利点の１つは、多数のページを処理する能力である。つまり、ＪＰＭ規格に対するイントロダクションは、百科事典全部を格納するためのＪＰＭの利用を説明している。他のファイルを包含する能力に起因して、百科事典のページを格納する多くのファイルが存在するが、必要なファイル全てを通じて進行するユーザエージェントにより、ページ１から終わりまで「ブラウズ」することができる。

ＪＰＭファイル中の全データは「ボックス」内に表われる。ボックスは、ある長さ及びタイプを常に有する組織ユニットである。これら２つのフィールドにより、ファイルにアクセスするプログラム又はユーザは、そのタイプを判別することができる。このタイプがデコーダにより理解されていない場合又は特定のタスクに不要である場合に、そのプログラム又はユーザは、その長さを使用して、次のボックスを見出すことができる。ボックスのタイプの全てを知ることなしに、多くのファイルがデコードされ、或いは効果的に使用されることが可能である。いくつかのボックスは、他のボックスの中でのみ表われる。再び、ボックスが「ファイルレベル」で表われようと別のボックスの中で表われようと、長さフィールドは、未知である或いは現在のタスクには不要であるボックスをスキップするために使用可能である。幾つかのボックスはデータ値を含み、そのデータ値は、ファイルの開始から、何らかのデータ、通常的には他のボックス又は圧縮されたコードストリームの一部までのバイト数を示す。これらのデータ値は、何か別の場所を示すことに起因して「ポインタ」と言及されることも間々ある。また、これらのデータ値は、それらがファイルの開始からの距離（バイト）を示すことに起因して「オフセット」と呼ばれることも間々ある。

［重要ボックス］
ＪＰＭファイルフォーマットは、多くの異なるボックスタイプを使用することを許容する。いくつかの具体的なボックスが以下に詳細に説明される。

［データリファレンスボックス］
データリファレンスボックスは、現在のファイルを充分にデコードするのに必要な外部ファイル全てを列挙する。データリファレンスボックスは、ＪＰＭファイルの完全利用を可能にすること及び短い２バイトコードを外部データセグメントに与える方法を提供することの双方に必要な他のファイル全てのリストを与える。ＪＰＭファイル以外のデータを利用するＪＰＭファイル内の他のデータは、データリファレンスｉｄ番号のみを含み、その番号は外部リファレンスのリスト中での番号である。データリファレンスボックスのみが、他のファイルに至る実際の「経路」又は「ＵＲＬ」（おそらくは非常に長く且つ確実に異なる長さである）を有する。この特徴は、１つのボックスのみを更新することで、あるファイルから別のファイルへ外部リファレンスを変更することを簡単にする。

［連続的なコードストリームボックス］
連続的なコードストリームボックスは、完全なコードストリームを含む。コードストリームは、マスク又は画像オブジェクトを作成するために、通常のＪＰＭデコーダを用いることによってデコードされる。コードストリームボックス自体は、そのコードストリームの目的を示さず；むしろ、他のボックスが連続的なコードストリームボックスに対するリファレンスを含んでもよい。従って、同じコードストリームが、おそらくは様々なページにおける多数のオブジェクトに使用可能である。

［フラグメントテーブルボックス］
フラグメントテーブルボックスは、レイアウトオブジェクトに対するコードストリームをアドレス指定する別の手段である。連続的なコードストリームはコードストリーム全体を整然と含む必要があるが、フラグメントテーブルボックスは、フラグメント（断片）と呼ばれる小さなセグメントとしてコードストリームが別の場所に格納されることを許容する。フラグメントテーブルボックスは、コードストリームのフラグメントのリストを含む。各フラグメントは連続的でなければならないが、通常的には離散的なフラグメントを連結することによって、完全なコードストリームが得られる。フラグメントは、同一ファイル内にフラグメントテーブルボックスとして、又はデータリファレンスボックスに列挙された外部ファイル内に或いは双方に格納されることが可能である。同一ファイル内のフラグメントは、通常的にはメディアデータボックス内にある。

［ページ収集ボックス及びページテーブルボックス］
ページ収集ボックスは、ページ収集ボックスは、ページ及び他のページ収集ボックスのリストであるページテーブルボックスを含む。他のページ収集情報を含めることにより、非常に長い「書類」が表現可能である。例えば、最高レベルのページ収集は、「書籍」を表現するページ収集の各々、章を表現する次のレベルのページ収集の各々及びその章でページを列挙するページ収集ボックスを備える「ライブラリ」を表現する。ページ収集及びページテーブルボックスには何らの画像データも含まれておらず；それらはページボックスへのポインタを単に含む。

［ページボックス及びヘッダボックス］
ページボックスは、ページヘッダボックス及びページについてのレイアウトオブジェクトボックスを含む他のボックス群を有する。ページヘッダボックスは、ページ：幅、高さ、向き及び色に関する情報を包含する。

［レイアウトオブジェクトボックス及びレイアウトオブジェクトヘッダボックス］
レイアウトオブジェクトボックスは、レイアウトオブジェクトヘッダボックス、オブジェクトボックス及び選択的に付加的なボックスを含む。レイアウトオブジェクトヘッダボックスは、（画像データの）識別子、高さ、幅、水平及び垂直のオフセット並びにスタイル等のようなレイアウトオブジェクトに関する情報を有するフィールドを含む。

［オブジェクトボックス及びオブジェクトヘッダボックス］
オブジェクトボックスは、オブジェクトヘッダボックス及び選択的に付加的なボックスを含む。オブジェクトヘッダボックスは、そのオブジェクト（マスク又は画像）に関する情報を有するフィールドを含む。フィールドは：（画像データの）タイプ、コードストリームインジケータ、水平及び垂直のオフセット、連続的なコードストリームボックス又はフラグメントテーブルボックスのオフセット及びデータリファレンス番号であり、これらはそのファイル以外に格納されているデータリファレンスボックスにより他のファイルにアクセスすることを可能にする。この開示に最も重要な要素は、コードストリームボックスのオフセット及び長さであり、なぜなら、これらの要素は画像を表すためのアクセスに必要である。

［共用データ入力ボックス］
共用データ入力ボックスは、ファイル内で反復的に使用されるボックスを含むように設計される。ボックスは、ｉｄ値及び共用されるデータより成る。ＪＰＭファイル中の様々な場所で何度もボックスを含める代わりに、共用データリファレンスボックスを使用し、共用データ入力ボックス内のデータを使用することができる。これは、コンテンツがボックスである規格により期待される。しかしながら、共用データ入力ボックス内のデータは何でもよい、なぜなら、それは共用データリファレンスボックスが使用されない限り読み取られないからである。

［共用データリファレンスボックス］
共用データリファレンスボックスは、単に、全てのボックスが含んでいる長さとタイプのフィールド及びｉｄフィールドから成る。ｉｄフィールドは、共用データ入力ボックスを識別するために使用され、共用データリファレンスボックスのロケーションにおける共用データリファレンスボックスの代わりに使用されるべきである。例えば、同じレイアウトオブジェクトがファイルの複数ページに使用され、レイアウトオブジェクトヘッダボックスが共用データ入力ボックス内に一旦格納されるならば、レイアウトオブジェクトヘッダボックスの完全なコピーを通常的には含む各ページボックス内の各レイアウトボックスでは、共用データリファレンスボックスが代わりに使用可能である。共用データリファレンスボックスが使用する共用データ入力ボックスは、共用データリファレンスボックスと同じファイル内であって同一のｉｄを有する任意の共用データリファレンスボックスの前に表われる必要がある。

図５は、ボックス及びオフセット用に関する詳細と共にＪＰＭファイル例の概略を示す。ファイルは、後述の図４の左側に示される２ページ書類の可能なエンコード内容に対応する。図５は、ファイル中の各ボックスにつき１つのラインを、そのボックスがファイル中で登場する順序で示す。図５の左側から始まるボックス名は、ＪＰＭファイルのトップレベルに表われる。インデントされた（字下げされた）ボックス名は、図５の左側に近いものにおける第１ボックスのサブボックスであるところのボックスを表現する。要求されたボックスが示されているが、本発明をわかりにくくすることを避けるために、多くの最適なボックスが示されていない。ボックス内のいくつかのフィールド名は、ボックス名の後の行に示され、図５にイタリック体（斜体）で示される。ほとんどのフィールド名は全く示されていないが、オフセットを含むフィールド名の多くは示されている。これらは、オフセットが向かう場所を指す矢印と共に示される。

図５における特定のファイルは、１次的なページ収集ボックスに対するポインタを除いて、現在のオブジェクトを超えるオブジェクトを指す全てのオフセットを有する。これは、正規の順序であるが、必須ではない。例えば、共用データ入力ボックスは、複合的な画像ヘッダボックスに速やかに従い、フラグメントテーブルボックスは共用データ入力ボックスに従い、ページボックスはフラグメントテーブルボックス及び連続的なコードストリームボックスに従い、ページ収集ボックスは最後に登場する。この順序では、全てのオフセットは、ファイル内で既に登場した項目である。オフセットはポインタのように引き出されているが、それらはファイルの開始からの実際のオフセットであり、ファイル中の現在のロケーションからのものではないことに留意を要する。従って、１次的なページ収集ボックスに対する全てのポインタは、同じ値を有する。

図５では、テキスト的なオブジェクトの各々が単独のコードストリームによりエンコードされ、連続的なコードストリームボックスに格納されている。画像的なオブジェクトの各々はＪＰＥＧ２０００によりコード化され、そのＪＰＥＧ２０００コードストリームは、その後に、１対の共用データ入力ボックスに分割され、フラグメントテーブルボックスによりアドレス指定される。

図６は、ファイルにおける具体的な順序が示されていないこと（それは変化するかもしれないからである）及びファイルのトップレベルにおけるボックスのみが示さされていることを除いて、図５と同様な情報を示す。通常的に示されるポインタは、図５に示されたような、トップレベルボックス内に深い入れ子になって表われる。しかしながら、図６はそのファイルの「構造」が、より平面的に描かれることを可能にする。ＪＰＭクライアントサーバ内で実行される多くの処理は、トップレベルファイルボックス及びファイルの全体構造を考察することで理解される。また、図６は、共用データ入力ボックス以外のメディアデータボックスに格納されたコードストリームを有する。

ＪＰＭファイルに格納されたオフセットがボックスの第１バイトに対するものならば、その矢印はボックスのトップを指すように示される。ＪＰＭファイルに格納されたオフセットが、ボックスの内容に対するものであり、その含んでいるボックス以外のコードストリームのバイトを指すならば、矢印はボックスの横を指すように示される。この場合において、様々なオフセットがボックス中の様々な場所をアドレス指定することが可能である。例えば、メディアデータボックスへの２つの矢印を有するフラグメントテーブルボックスは、各フラグメントについて、異なる範囲のメディアデータをアドレス指定するのが一般的であろう。

１より多くの要求に応じて書類画像の一部をネットワークを介して伝送する方法及び装置を提供すること。

本発明の一態様による方法は、ＪＰＭファイルの一部に対する複数の要求を受信し、その複数の要求に応じてＪＰＭファイルを部分的に送信する。

本発明は、以下になされる詳細な説明により及び本発明の様々な実施例に関する図面により一層理解されるであろう。しかしながら、その説明は、本発明を具体的な実施例に限定するように解釈すべきではなく、説明内容及び理解を支援するものに過ぎない。

１以上の要求に応じてネットワーク上で書類画像の一部を伝送する技術が、特にＪＰＭファイルに関連して説明される。ＪＰＭファイルはいくつもの画像データのページを有するファイルを格納するのに良く適しているので、及び画像データは印刷解像度で格納されるかもしれないので、そのファイルは非常に大きくなり得る。データの一部のみを見ることがしばしば望まれる。例えば、一部のページ群、ページの一部分のみ、又はページの一部の低解像度バージョン等が望まれるかもしれない。以下、書類の一部にアクセスすることを支援するようにどのようにして大きなＪＰＭファイルが格納されるか、書類の一部に関する要求をクライアントがどのようにして発行するか、及びどのようにしてサーバが要求に応じるか等を説明する。多くの場合に、非常に過剰なデータをクライアントに送信し、その結果所望のデータ部分を見る（又は使用する）機能を手間取らせることを避けるために、新たなファイルがサーバにより作成される。

以下の説明では、本発明に関するより充分な説明を行なうために多くの詳細が説明される。しかしながら、本発明がそれらの具体的詳細にとらわれずに実現されてもよいことを当業者は認識するであろう。場合によっては、本発明をわかりにくくすることを避けるために、周知の構造及び装置が、詳細ではないブロック図形式で示される。

以下の詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビットに関する動作を表現するアルゴリズム及び記号で示される。これらのアルゴリズム的な記述及び表現は、当業者の仕事内容を他の当業者に最も効率的に伝えるために、データ処理技術分野の当業者により使用されるものである。ここで、アルゴリズムは、一般的には、所望の結果を導出するための一貫した一連のステップであるとされる。これらのステップは、物理量の物理的な取扱いを要するものである。通常的には、必須ではないが、これらの量は、格納され、伝送され、組合わせられ、比較され及び他の処理がなされることの可能な電気的又は磁気的な信号の形式をとる。基本的には一般的な用法に起因して、ビット、値、エレメント、記号、キャラクタ、言葉、数等としてそれらの信号に言及することが便利なことが間々ある。

しかしながら、これら及び同様な用語の全ては、適切な物理量に関連するものであり、それらの量に適用される便宜的なラベルに過ぎないことに留意を要する。以下の説明から明らかなように、特に言及しない限り、説明を通じて理解されることは、「処理」又は「コンピューティング」又は「計算」又は「決定」又は「表示」等のような用語を用いる説明は、コンピュータシステム又は同様な電子的コンピューティング装置の動作及び処理を示し、そのシステム及び装置は、コンピュータシステムのレジスタ及びメモリ内の物理的な（電子的な）量として表現されるデータを、コンピュータシステムメモリ又はレジスタその他の情報ストレージ、伝送又は表示装置内の物理量として同様に表現される他のデータに処理及び変換することである。

本発明は、その動作を実行する装置にも関連する。本装置は、要求された目的のために特別に構築されてもよいし、或いはコンピュータに格納されたコンピュータプログラムによって選択的に起動又は再構築される汎用コンピュータから構築されてもよい。そのようなコンピュータプログラムは、限定ではないが、フロッピディスク、光ディスク、ＣＤ−ＲＯＭ及び磁気光ディスクを含む任意の種類のディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光学カード、又は電子的な命令を格納するのに適しており、コンピュータシステムバスにそれぞれ接続される任意の種類の媒体のように、コンピュータ読み取り可能な記憶媒体に格納される又はネットワークを介して配信される。

ここに与えられるアルゴリズム及びディスプレイは、特定のコンピュータその他の装置に固有に関連するものではない。様々な汎用システムが、ここでの教示内容に従うプログラムにより使用されてもよいし、又は要求された方法手順を実行するために、より特殊化した装置を構築するのに好都合でもある。多様なこれらのシステムに要求される構造は、以下の説明により明らかになるであろう。更に、本発明は、何らかの特定のプログラミング言語で説明されるものではない。ここに説明されるような本発明の教示内容を実現するために、様々なプログラミング言語が使用され得ることが認識されるであろう。

機械読み取り可能な媒体は、装置（例えば、コンピュータ）により読み取り可能な形式で情報を格納又は伝送する任意の手段を含む。例えば、機械読み取り可能な媒体は、読み取り専用メモリ（ＲＯＭ）；ランダムアクセスメモリ（ＲＡＭ）；磁気ディスク記憶媒体；光記憶媒体；フラッシュメモリ装置；電気的な、光学的な、音響的な又は他の形式の伝送信号（例えば、搬送波、赤外線信号、ディジタル信号、等）；等を含む。

［クライアント、サーバ及びネットワーク］
図２は、圧縮された画像を通信するためのクライアントサーバシステムを示す。図２を参照するに、サーバ２０２は一般的には画像全体を有し、或いは少なくとも画像の一部へ(画像を有する場所へ)のアクセスを与える。これらの画像はＪＰＭファイルとしてメモリ２３２に格納される。サーバ２０２は、ある種のネットワーク又は他の通信チャネルを介して、クライアント２０１のような少なくとも１つのクライアントに接続される。一実施例では、クライアント２０１は、ユーザ２５０のような人的なユーザにより制御される「プログラム」である。別の実施例では、クライアント２０１は自動化システムより成る。

クライアント２０１は、画像の一部分に対する要求２１０のような要求を発行し、何らかの方法でその要求に応じる圧縮データ画像を含む応答２１１のような応答を受信する。ネットワーク帯域、サーバ２０２のリソース又は要求されたファイルの構造に起因して、クライアント２０１は、要求した画像のその部分よりも多い又は少ないデータを受信する。クライアント２０１は一般的には画像の別の部分についての付加的な要求を発行し、以前に受信したデータを補う更なる符号化データを受信する。

クライアント２０１は画像のその別の部分をキャッシュメモリ２２１に格納する。ＪＰＭデコーダ２２２は、独立的に又は共に、処理された画像２２３を生成するために、キャッシュメモリ２２１に格納されたＪＰＭファイルの別の部分をデコードする機能を有する。サーバ２０２はクライアントキャッシュモデル２３１を格納し、このモデルは、クライアント２０１が既に有している部分をサーバ２０２に示すための、クライアント２０１のキャッシュ２２１のモデルである。

図３は、ネットワーク例を示す。ネットワーク例は一般的には複数のクライアント及び複数のサーバを有する。１つのサーバは、多数の様々なクライアントに、同一画像の異なる部分を与えてもよい。１つのクライアントは、いくつかのサーバから画像その他のデータ（例えば、ＨＴＭＬページ）を受信してもよい。プロキシサーバは、ネットワーク内で、オリジナルサーバと連絡をすることを必要とせずに、いくつかの要求に迅速に応答することを可能にする。利用可能な帯域及び帯域のコストは、様々なクライアント及び同一のサーバの間で又は異なるサーバの間で、幅広く相違してもよい。

最も通常使用されるネットワークは、インターネット又はワールドワイドウェブ（ＷＷＷ）であるが、ここに説明される技法は、ローカルエリアネットワーク（ＬＡＮ）又は任意の一般的な相互接続システムに適用可能である。同様に、一実施例では、圧縮された書類が、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）「の上位に」転送される。しかしながら、ここに説明される技法は、例えば、ＴＣＰ／ＩＰ及びＵＤＰを含む他の転送プロトコルと共に利用可能である。いくつかの技法はＨＴＴＰで説明されるが、他のプロトコル用に容易に修正可能である。

図４は、２ページの複合的な書類、要求及び応答を示す。図４を参照するに、２ページの書類４０１はサーバに格納される。書類４０１のページ１は３つのレイアウトオブジェクト４１１−４１３を有する。クライアントは、特にクライアントの有する利用可能な表示サイズよりも書類４０１が大きい場合には、書類４０１の全部を希望しないかもしれない。例えば、クライアントは、限定された表示サイズを有するパーソナルディジタルアシスタント（ＰＤＡ）であるかもしれないし、ページ１の上半分のみを希望するかもしれない。それ故に、クライアントは、最高解像度の６４０×４８０におけるページ１の上半部分について、要求を送る。要求４２１はレイアウトオブジェクトを指定していないことに留意を要する。これに応答して、サーバは、いくつかのレイアウトオブジェクトを有するファイルを含む応答４２２を生成し、クライアントに応答４２２を送る。即ち、サーバはどのレイアウトオブジェクトがその要求に関連するかを判別する。これは、部分的なページに対応して、低解像度でクライアントがディスプレイ４３１用の画像を生成することを可能にする。

［部分的なＪＰＭ配信のための技法］
ＪＰＭファイルの一部を配信するために多数の技法が使用可能である。その配信は、クライアントからの要求に応答してなされ、且つＪＰＭファイルの一部にサーバがアクセスすることで、及びその部分をクライアントに送ることで実行される。以下、部分的な書類を要求する例示的な要求シンタックス、サーバにおけるＪＰＭファイルの組織例及びサーバからの応答についての例示的な応答タイプを説明する。

［部分的な書類についての要求シンタックス］
ＪＰＭフォーマットに格納された圧縮された書類の一部をクライアントが要求するためのいくつかの可能な技法が存在する。これらのいくつかが以下に説明されるが、部分的な書類を返す技法は、要求を作成するシンタックスには依存しない。書類の一部を要求する１つの手法が存在することが単に想定される。一実施例では、要求シンタックスで指定される可能性のある項目は：希望ページ、ページ上の希望する領域、返送データの希望する解像度、返送されるデータを受信するための希望する方法であり、もしかすると既に受信したデータでもある。

［ＪＰＥＧ２０００パート６付録Ｅ］
ＪＰＭ規格は、「ＪＰＭファイルのＵＲＬを構築するためのガイドライン」と呼ばれる付録を含んでいる。この付録は、ＪＰＭファイルのサブエレメントを識別するための一群の例を与える。完全な例示群は、ＪＰＭ規格付録Ｅに与えられる：

上記の全ての例は、ファイル名“ｆｏｏ．ｊｐｍ”の一部にアクセスするために使用される。

この付録におけるシンタックスは、今日のｈｔｔｐ要求と共に一般的な「名称＝値」（“ｎａｍｅ＝ｖａｌｕｅ”）タイプである。このシンタックスの要素は：ページ（ｐａｇｅ）、オブジェクト（ｏｂｊ）、タイプ（ｔｙｐｅ）、インデックス（ｉｎｄｅｘ）、ｍタイプ（ｍｔｙｐｅ）、ラベル（ｌａｂｅｌ）、コル（ｃｏｌｌ）、オフ（ｏｆｆ）及びレン（ｌｅｎ）である。

「ページ」は、メインページ収集内のページ数、又は「コル」パラメータが使用されるならば他のページ収集のものを示す。

「オブジェクト」は、ページ中のレイアウトオブジェクトを示す。

「タイプ」は、オブジェクトに関するメタデータ又は画像データを返送することを可能にする。

「インデックス」は、最初のもの以外の項目が返送されることを可能にする。一例では、ラベル「ＩＰＲ−ｉｎｆｏ」を有する２番目のメタデータが要求される。

「Ｍタイプ」は、返送される様々な種類のメタデータを指定する。

「ラベル」は、ＪＰＭファイル中の他のいくつかのボックス内で使用されることの可能なラベルボックスを表す。これは、クライアントがファイル中のページ数又は場所を知らない場合であって、何かのラベルが分かっている場合にアクセスを可能にする。例えば、ラベルが「図（ｆｉｇｕｒｅ）」であるとし、クライアントが「図」の全ての求め、オブジェクトに「図」の言葉が付されたたラベルボックスを有する任意のオブジェクトを取得する。（レイアウトは、ページボックス又はオブジェクトボックスに関連付けることができる。）
「コル」は、ページ収集（ページコレクション）を表す。

「オフ」は、ファイル内のバイトオフセットを表す。

「レン」は、指定されたオフセットにて望まれるバイト数（長さ）を示す。

ＪＰＥＧ２０００パート６付録Ｅは、これら任意の要求に対して何が返されるべきかを指定しない。一例では、具体的に、「ここでのデコーダの動作は未定であること」が述べられる。更に、記述れたシンタックスにより、ページの空間的な一部分を、又はより低解像度のものを、又はページの範囲を、又は列挙されたもの以外のボックスを要求することは不可能である。これらの要求に対する可能な返答値は、以下に説明される。

［パート６付録Ｅの拡張］
パート６に記述されたシンタックスを、いっそう有用にするために、一実施例では、シンタックス（構文）が１以上の多くの方法で拡張される。この付加的なシンタックスを用いて、クライアントは、所望のコンテンツを、より多くの方法で指定することができる。サーバはこの付加的なシンタックスを認識し、要求された書類データをクライアントに与えるように、そのようなシンタックスに応答することができる。

一実施例では、シンタックスは任意のボックスタイプが要求されることを許容する。このことは重要である、なぜなら、任意のボックスタイプを取得することは、例えばページ中で使用される特定のコードレスストリームにアクセスするのに有用だからである。より具体的には、一実施例では、「ボックスタイプ」パラメータが、上述した現在の「ページ」及び「コル」パラメータを一般化する手段として付加される。「ボックスタイプ」の値は、１つのボックスにつき、４文字タイプのフィールドとしてもよい。印刷できない文字は、ＵＲＬに関する一般的な方法にて拡張可能である。例えば、特定の「印刷可能でない」文字は、％ｘｘで置換可能であり、ここで、ｘｘはその文字に関する数値的なコードである。

ＪＰＭファイルにおける多くのリファレンスは、オフセットの分だけファイル内部にあるので、特定のオフセットから始まるボックスを要求しすること及びボックス全体を取得することを可能にするのに有益である。一実施例では、これを行なうために、「レン」パラメータは、「レン＝ボックス長」（ｌｅｎ＝ｂｏｘｌｅｎｇｔｈ）のような特定の値である「ボックス長」を採用することが許容される。この場合に、その要求の「オフ」パラメータで指定されるオフセットから始まるボックスが提供される。

小さな表示部を備える装置は、書類の低解像度バージョン又は書類の一部分のみを希望するかもしれないので、一実施例では、これらのバージョン又は部分を指定するためのパラメータが含まれる。ＪＰＩＰにて使用される「ｆｓｉｚ」，「ｒｓｉｚ」及び「ｒｏｆｆ」パラメータは、この目的のために包含され使用されることが可能である。「ｆｓｉｚ」パラメータは、その表示装置で取得する全ページのサイズを指定するために使用される。「ｒｓｉｚ」及び「ｒｏｆｆ」パラメータは、ページ内で要求される画像の部分を指定するために使用される。例えば、ページの右上部分のみを表示することを望む場合に、２４０×３２０画面を有する携帯式装置は、
“ｆｓｉｚ＝４８０，６４０＆ｒｓｉｚ＝２４０，３２０＆ｒｏｆｆ＝２４０，０”
を指定することができる。

一実施例では、「インデックス」又は「ページ」パラメータが、サポートする範囲の拡張性を含む。これは、１より多くのページが一度にアクセスされることを可能にする。例えば、
ｆｏｏ．ｊｐｍ？ｐａｇｅ＝１−５
ｆｏｏ．ｊｐｍ？ｐａｇｅ＝１＆ｔｙｐｅ＝ｍｅｔａ＆ｉｎｄｅｘ＝１−５
のような要求が有益である。後者の要求は、ページ１についてメタデータボックス１−５内のデータをサーバが提供するように告げる。

一実施例では、「ボックスタイプ」（又は「ページ」又は「コル」又は「オブジェクト」）パラメータは、サブボックス（二次的なボックス）を含むように拡張される。例えば、「ボックスタイプ＝ページ／ＢＣＬＲ」（ｂｏｘｔｙｐｅ＝ｐａｇｅ／ＢＣＬＲ）は、ページボックスの基本色サブボックスを指定することができる。

［ＪＰＩＰ（ＪＰＥＧ２０００パート９）］
ＪＰＥＧ２０００パート９は、一部のＪＰＥＧ２０００コードストリーム及びメタデータを返すように規定された３０を上回る「名称＝値」（ｎａｍｅ＝ｖａｌｕｅ）パラメータによる拡張的なシンタックスを指定する。例えば、ＪＰＩＰは「サブターゲット」と呼ばれるパラメータを与え、このパラメータは、ＪＰＩＰサーバが、特定の領域に関する要求をファイルの一部のみに適用することを可能にする。ＪＰＭに関し、これは、ＪＰＭファイル内部からＪＰＥＧ２０００コードストリームの一部を要求するために使用されることが可能である。例えば、ページボックス及び関連するオブジェクトボックスを受信したクライアントは、オブジェクトボックスからのオフセットフィールドを使用して、オブジェクトボックスのオフセットフィールドにより指定されたＪＰＥＧ２０００コードストリームの一部分のみ（例えば、左上隅）を要求できる。例えば、
“ｆｏｏ．ｊｐｍ？ｓｕｂｔａｒｇｅｔ＝１３３２２４−＆ｆｓｉｚ＝１０２４，１０２４＆ｒｓｉｚ＝５１２，５１２＆ｒｏｆｆ＝０，０”
のようなＵＲＬは、ファイルｆｏｏ．ｊｐｍのバイトオフセット１３３２２４から始まるコードストリームの左上隅が、１０２４×１０２４サンプルのオブジェクトの画像全体を形成するのに充分な解像度で配信されることを要求する。

一実施例では、クライアントは、特定のページ上の特定の画像に関する特定のコードストリームを指定するための整数値又は「スコープトークン」（ｓｃｏｐｅ−ｔｏｋｅｎ）と共にＪＰＩＰの「ストリーム」パラメータを使用する。「スコープトークン」はＩＳＯの定義に予約されているが、適切に定義されるならば、「ページ５、レイアウトオブジェクト３、画像」“ｐａｇｅ５，ｌａｙｏｕｔ ｏｂｊｅｃｔ３，ｉｍａｇｅ”に関連するコードストリームに関して要求が発行されることを許容できる。

ＪＰＩＰ要求シンタックスの１つの欠点は、範囲及び解像度に関する要求が、ページではなく単独のコードストリームに適用されることである。ページの上半分が望まれる場合であって、コードストリームがページの上半分でのみ表われる場合に、コードストリームの上半分だけではなく、コードストリームの全画像に関するＪＰＭ中のデータが、サーバにより返される。クライアントがページボックスを有するとすると、そのページにおける各コードストリームの適切な部分を取得する要求が作成可能である。ＪＰＩＰはＪＰＥＧ２０００でないコードストリームをサポートしないが、ＪＰＭはＪＢＩＧ、ＪＢＩＧ２その他の圧縮規格を利用する。

［ＪＰＭのＪＰＩＰに対する拡張］
書類画像についてＪＰＩＰシンタックスを更に有用にするために、それを拡張することができる。

一実施例では、ＪＰＩＰシンタックスは、領域を記述するパラメータと共に機能するように「ページ」要求パラメータを付加するよう拡張される。「ページ」パラメータが使用されると、「ｆｓｉｚ」、「ｒｓｉｚ」及び「ｒｏｆｆ」パラメータは、そのページ内の個々のコードストリームではなく、そのページに適用される。サーバはそのページに関する要求を受け、そのページ中の所望のオブジェクト領域にそれを適切に変換する。

［他の可能なシンタックス］
当然に、多くの可能な要求シンタックスが存在する。ＪＰＥＧ２０００パート６及びＪＰＥＧ２０００パート９に示されるいくつかのシンタックスの組合せが使用されてもよい。また、画像の一部にアクセスするためにＸＭＬシンタックスが使用されてもよい。これは、ＪＰＩＰシンタックスを基礎とするが、正式なＸＭＬとして編成される。これは、部分的な書類アクセスを提供するための一般的方法になる可能性のある「ウェブサービス」に有益であろう。

ここに説明されたＪＰＭファイルの一部を返す技法は、要求に使用されるシンタックスそのものに依存しない。

［サーバにおけるＪＰＭファイルの組織化］
ＪＰＭファイルを用いて複合的な書類を格納する多くの方法があり、その方法は、厳密に同じ完全な書類がデコードされることを許容する。これらの相違は、ファイル中の情報の順序、同様な目的を達成できる別のボックスタイプの利用性、外部ファイルの利用性及び異なるレイアウトオブジェクトへの画素の割り当て等と関係がある。これらの差異の各々は、特定のデコーダの全体的なデコード速度、一部の書類を発見する容易性、全体的なファイルサイズ及び他の要因に影響を与える可能性がある。ファイル割当のいくつかの特定の選択肢はクライアントサーバ動作に有益である。

［外部ファイルストレージ］
マスク又は画像オブジェクトを形成するためにデコードされるコードストリームは、連続的なコードストリームボックス内の若しくはメディアデータボックス内の又は共用データ入力ボックス内のＪＰＭファイル内に格納可能である。また、コードストリームはＪＰＭファイル以外のファイルに格納されてもよい。ＪＰＭファイルは、コードストリームが別ファイル内に、そのファイル中のあるオフセットにあることを示すので、コードストリームは様々な方法でラップされることが可能である。コードストリームはＪＰ２ファイルに存在可能であり、コードストリームはヘッダデータを全く有しないが他のコードストリームのコレクションと共にファイル内に存在可能であり、或いはコードストリームは外部ファイルのコンテンツだけでもよい。ＪＰＭファイル中のコードストリームを格納する１つの利点は、それらが、コピーのような一般的なファイルシステム動作によってファイルから分離されないことである。また、単独のファイルとして格納される場合に、単独の要求により全書類を取得することが可能である。コードストリームを外部に格納することのいくつかの利点は、例えば、１度だけ格納されることを要する会社のロゴ又はレターヘッドのようなコードストリームが複数の書類の間で共用できることである。

更に、外部ストレージにより、多くの手法でコードストリームを要求することが可能になる。別個のファイル内のコードストリームを指すＪＰＭファイルのいくつかの要求は、そのファイルが返送される原因となる。或いは、クライアントは外部ファイルを直接的に要求することができる。また、外部ファイルは、複合的な書類の様々な部分を別々に保護することを可能にする。例えば、あるクライアントは、あるファイルにアクセスする許可を与えられていないかもしれないし、あるファイルは暗号化されているかもしれない。

［フラグメントテーブル対連続的なコードストリームボックス］
コードストリームを格納する際にサーバが作成することの可能な他の選択肢は、連続的なコードストリームボックスにファイルを格納すること、又はフラグメントテーブルボックスによりコードストリームを示すことである。連続的なコードストリームボックスの利用は、そのコードストリームが全部一緒であるので、最も簡易な手法である。これはサーバにとって好都合であろう、なぜなら、サーバは、コードストリームにアクセスするためにそのファイル中の（又は他のファイルでさえも）多くの別々の場所を見渡す必要がないからである。しかしながら、フラグメントテーブルボックスを利用することは、コードストリームが外部に格納されることを許容し、ＪＰＭファイル内に格納される場合にはコードストリームが分割されることを許容する。コードストリームは、共に共通にアクセスされる複数の部分に分割されることが可能である。分割に更にいくつかの特有の意義を与えることが可能であり、例えば、第１フラグメントは低解像度であり、第２フラグメントは中程度の解像度であり、第３フラグメントは高解像度である。

［共用データ入力ボックスにおけるコードストリームの格納］
フラグメントテーブルボックスを用いてアドレス指定されるコードストリームは、任意のファイルにおける任意のオフセットのものであり得る。それらが正規のＪＰＭファイルにあるならば、それらはメディアデータボックス、フリーボックス、共用データ入力ボックス及び連続的なコードストリームボックスに格納可能である。コードストリームは、ラベルボックス、ＸＭＬボックス、ＵＵＩＤボックス又は更なる補助的なページボックス（但し、これはあるＪＰＭデコーダに問題を生じさせるので、推奨されない）のような他のボックスタイプ内に更に隠されることも可能である。最も一般的なストレージは、おそらくはメディアデータボックスであり、特定のコードストリームが１以上のメディアデータボックスに表われることが可能である。フリーボックスにコードストリームを格納することは、そのコードストリームが画像のデコードに本質的でなければ有益であろう。有用な情報を含むフリーボックスを認識しないエディタは、それを破棄する。メディアデータボックスではなく、共用データ入力ボックスにコードストリームを格納することは、何らかの意味がそのインデックスに与えられている場合にのみ有用であろう。

固定的な意味に関する数字を利用することは有意義である。例えば、インデックスは共用データ入力ボックスの各々に割り当てられてもよい。そして、デコーダはＪＰＭファイル中を進行し、共用データ入力ボックス内の情報を何らデコードせずに、インデックス番号のみに基づいて、あるボックスを除去し、別のものをファイル中に残してもよい。

［リターンタイプ］
［一括全画像返送］
一実施例では、クライアントは、完全な圧縮画像を受信することで部分的な画像要求への応答を受信し、その圧縮画像は、要求に対する回答として、圧縮解除され表示されることが可能である。

極端には、サーバは、メモリ内の完全な書類を圧縮解除し、クライアントに望まれるページ数、領域及び解像度に縮減し、その画像を（ＪＰＭファイルとして又はＪＰＥＧやＰＤＦのような他のフォーマットとして）再圧縮し、それをクライアントに送信する。この方法は、クライアント側の旧式の圧縮内容と後方互換性を可能にするが、いくつかの欠点を有する。これは、サーバにとって極度に重い演算負担となる（完全な圧縮解除１回、部分的な圧縮１回）。また、それはＪＰＭファイルの特徴的利点を活用しない。更に、要求の後に続く多くの重複する画像データが、いくらかの同一符号化データの再送信を招く点で、それは効率的ではない。しかしながら、これは非常に簡易な有益な手法である。

クライアント側で処理を更に簡単にする手法は、サーバのために、完全なＪＰＭファイルを「分析」し、クライアントの特定の要求に適切な全てのボックスを収集することである。何らの画像データもデコードされないが、コードストリームの高解像度部分を含む不要なページ及びコードストリームは、送信前に破棄される。容易にデコード可能なファイルを作成するために、サーバは、送信されるのに必要な部分を取り、且つファイル中の新しいロケーションに対するリファレンスを調整することによって及び外部ファイルに対する全てのポインタを削除することによって、新しいＪＰＭファイルを作成する。ページ数及びページ内のオブジェクト数は、クライアント要求を満たすのに必要なページ及びオブジェクトのみに調整可能である。

要求のために新たなＪＰＭファイルを形成することは、クライアントによる非常に簡易な動作、即ち受信したファイルをデコードすることを可能にする。更に、返送されたデータの部分は、理解されるように以後の要求に有利であろう。

［各要求についての新たなＪＰＭファイル］
図７は図６と同様に描かれた３つの別個のファイルを示し、３つの要求に応じてクライアントが受信したものである。第１の要求に応じてクライアントが受信した第１のファイルは、図７の左側に示される完全に自立型のＪＰＭファイルである。より多くのデータについて更なる（第２の）要求を行なった後に、クライアントは、図７中央に示される第２のＪＰＭファイルを受信する。このファイルは、第１のファイル内のいくつかのボックスの繰り返しを含む。この場合に、ＪＰＥＧ２０００シグネチャボックス、ファイルタイプボックス、複合的画像ヘッダボックス及びページ収集ボックスが反復される。しかしながら、新たなファイルにおけるページボックスは、２つだけではなく、３つのオブジェクトに対するポインタを含む。ページボックスによりアドレス指定される第１のコードストリームは、サーバが以前にクライアントに送信したＪＰＭファイル内に格納される。他のファイルへのオフセットは、ファイルのトップレベルの何処かにあるデータリファレンスボックスを要し、これは図７の中央下側に示される。

第２ＪＰＭファイルは、第１の応答にて送信されたコードストリームの一部を利用する；しかしながら、現ファイルのメディアデータボックス内に付加的なデータを含めることで、そのコードストリームを拡張する。即ち、フラグメントテーブルボックスは、以前の応答によるの１つのフラグメント及び現在のファイルによるものをアドレス指定する。

第３の要求がなされる場合に、第３の応答は新たなＪＰＭファイルから成る。このファイルは、以前に受信したファイル双方を利用し、再び更なる情報を含める。図７の右側に示される例では、第１のページボックスは、以前に送信されたデータを利用するが、第２のページボックスは新たなコードストリームを含む。これは典型的には、ユーザが、あるページから次へスクロールした場合に起こる。

図７は、ある応答から次へ多数繰り返すように示され、以前に送信した数個のボックスのみを利用しているが、反復されるボックスは相対的には少ない。ＪＰＧＥ２０００シグネチャボックス、ファイルタイプボックス、複合的画像ヘッダボックス、ページ収集ボックス及びページボックスは、高々数千バイトで送信できる。たとえファイル全体が最終的に送信されたとしても、相互的なアクセスを与えるための小さなオーバーヘッドが存在するに過ぎず、関心のある部分へのアクセスは非常に効率的になる。

サーバがキャッシュモデル（図２の２３１）を維持する必要がないという意味において、全ての画像応答は一般に「ステートレス」（ｓｔａｔｅｌｅｓｓ）であると考えられるが、図７，８に示される完全画像返送は、クライアントの以前の要求及びサーバの以前の応答に関する情報をサーバが維持することによる利益を受ける。効率的にするために、サーバはファイル中の任意のデータの場所を追跡する必要があり、サーバは以前の応答で送信したそのファイルを参照する。一実施例では、サーバはコードストリームフラグメント（又は完全なコードストリーム）の場所を追跡する。更に、サーバが以前のページテーブル又はフラグメントテーブルを利用することを予定するならば、それらの場所も追跡されるべきである。サーバはこれらの場所を個々に追跡しないかもしれない；その代わりに、サーバが応答を生成するために一貫した方法を使用するならば、要求及び以前に送信した応答のサイズを追跡できる。そして、以後の要求がなされると、サーバはそれが以前の要求にどのように応答したかを判別する。このことはサーバが項目の場所を判別することを許容し、その項目は現在の要求で参照されるものである。

一実施例では、クライアントに格納されているファイルをサーバが参照できることを認める取り決めが存在する。この取り決めは、規格委員会によって又は事実上の標準（デファクトスタンダード）によって設定可能である。クライアント側のファイルを参照することを認める取り決めが無い場合には、サーバは、クライアントが以前の要求に使用したＵＲＬを利用することができる。以前の要求がキャッシュ可能にマーク付けされたならば、スマートなクライアントはそれを再び生成しない。一実施例では、クライアントが再び要求を発行する場合に、同一データが返送され、デコードが依然として行なわれ、データの再送信に起因してそれは非効率的になる。

［全ＪＰＭファイル返送−コードストリーム格納例］
図７のようにＪＰＭファイルにコードストリームを含めるのではなく、コードストリームは外部ファイルに保持されてもよい。サーバ上のファイルは、ＪＰＭファイル外部のコードストリームと共に格納されてもよい。これらのコードストリームを示すＪＰＭファイルを返送することは、それらをＪＰＭファイルと組合わせることよりも容易である。

特定の要求を考察すると、外部のコードストリームを指し示すＪＰＭファイルと、その要求に適切なコードストリームの部分との双方を、サーバは返送することができる。この場合に、返送タイプは複数のファイルより成る。ＨＴＴＰでは、「コンテンツ−タイプ：」（Ｃｏｎｔｅｎｔ−ｔｙｐｅ：）は、複数部分のマイム（ＭＩＭＥ）である。即ち、ＪＰＭファイル及び外部コードストリームの双方は、共にラップされ、マイムファイルとして送信される。一実施例では、クライアントは受信したファイルを格納し、デコード操作が行なわれると、サーバにより与えられた解像度でローカルなコードストリームにアクセスする。この方法の利点は、所望の結果を出す簡易な要求にある。欠点は、複数部分の要求を用いることであり、受信したコードストリームを他の領域に拡張する際に困難になる。ＪＰＭファイル及び２つのコードストリームフラグメントによる１つの応答は、図８の左側に示されている。

図８は相互的な要求に対する３つの応答を示す。この場合に、全てのコードストリームはＪＰＭファイル外部に格納される。第１の応答は、２つのコードストリームをアドレス指定することを要し、そのためＪＰＭファイル内に２つのフラグメントテーブルボックスがあり、各々が別々のコードストリームをアドレス指定する。上記と同様に外部ファイルと共に完全が画像返送を受信した後に、クライアントは補足的な要求を発行してもよい。例えば、クライアントはページをスクロールダウンし、新たなレイアウトオブジェクトを要求し、それらのオブジェクトは、第１の要求領域と何らの共通部分も有しないので、当初はスキップ（迂回）される。補足的要求に対する応答は、図８の中央に示される。この場合に、応答は新たな完全なＪＰＭファイルである。このファイルは、第１の要求よりも多くのレイアウトオブジェクトを含む。しかしながら、このファイルは、第１の要求により使用されたのと同じコードストリームを参照する。それらは以前の要求と共に返送されるので、クライアントはそれらをそのキャッシュ（図２の２２１）に更に持つべきである。以前のＪＰＭファイル内に何らのボックスも利用する必要はないが、外部に格納されたコードストリームは再利用される。コードストリームは一般的にはアドレッシング情報よりも大きいので、新たなＪＰＭボックスを送信することは非効率的ではない。

一実施例では、新たなページついて第３の要求が今回なされる場合に、新たなＪＰＭファイルが応答として返送される。今回は、ＪＰＭファイルは、付加的なページを含み、そのページに必要な外部コードストリームを指し示す。これは図８の右側に示される。第３の応答もＪＰＭファイルであり、以前の応答によるコードストリームを再びアドレッシングする。この場合に、第１のページボックスは、別のＪＰＭファイルによるフラグメントテーブルボックスを利用するが、応答は、直接的にフラグメントテーブルボックスを含み、第２のＪＰＭファイルの必要性を回避することもできる。

コードストリームを外部ファイルに格納する複数の手法が存在することに留意を要する。コードストリームはそれ自身によりコードストリーム全体としてファイルに格納可能である。コードストリームは、各ファイルにおけるコードストリームのほんの一部と共にいくつかのファイルにわたって分散させることさえできる。コードストリームはＪＰ２ファイルに格納可能である。この場合に、ＪＰＭファイルにおけるフラグメントテーブルボックスは、そのコードストリームが表われるＪＰ２ファイルまでを指し示す。或いは、ＪＰＭファイルにおけるページテーブルボックスは、ＪＰ２ファイル中の連続的なコードストリームボックスを指し示すことができる。連続的なコードストリームボックス及びコードストリームのみを含むが他のボックスは無いファイルさえも存在可能である。これは、ＪＰＭページテーブルボックスが、ファイルのオフセット０を指すことを許容する。連続的なコードストリームファイルボックスの欠点は、ほとんどのＪＰＥＧ２０００コーデックスでそれ自身により認識されないことである。

［１ファイル外部ポインタ］
複数の部分応答において外部コードストリームをＪＰＭファイルと共に返送する代わりに、一実施例では、サーバ上の必要なコードストリームに対する外部リファレンスと共にＪＰＭファイルのみを、サーバが返送する。そして、クライアントは各コードストリームについて直接的に分離要求を発行する。個々のコードストリームに関する要求は、ＪＢＩＧ及びＪＢＩＧ２コードストリーム用のバイトレンジ要求、並びにＪＰＥＧ２０００コードストリーム用のＪＰＥＧ２０００パート９で指定されるようなＪＰＩＰ要求とすることができる。この多重要求構造は、受信したデータに関するクライアントによる非常に細粒どの制御を可能にする。これは、明らかに、単独の自立型のＪＰＭファイルを単に取得するよりもクライアントにとっては複雑になり、複数の往復又は送受信（ラウンドトリップ）を必要とし、これはデータの受信を遅らせるかもしれない。

別の実施例では、サーバはページを又はページからレイアウトオブジェクトを除去しないが、サーバ上のファイルを示す要求の一部ではないオブジェクト用のリファレンスを変更し、包含されるオブジェクトがローカルに示す。従って、第１応答を受信した後のクライアントは、ページ数及びＪＰＭファイルの大きさを知り、要求された部分に関するローカルにデコード可能なファイルを有する。

図９は、要求に応答して返送され得るＪＰＭファイルを示す。この場合に、ＪＰＭファイルは、その書類中にページ及びレイアウトオブジェクトの全てについてのボックスを含むという意味において「完全（ｃｏｍｐｌｅｔｅ）」である。全てのコードストリームは依然としてサーバにある。クライアントがより多くのデータ要求を行なうと、コードストリームの一部を又は完全なコードストリームさえ受信してもよい。そして、これらはローカルに格納される。クライアントは以前に受信したＪＰＭファイルを、それがローカルに利用可能なコードストリームを指し示すように、更新することができる。そのＪＰＭファイルは、いくらかのローカルに利用可能なコードストリーム及びいくらかのサーバに残るものと共に、書類全体を表現する正当なファイル（ＪＰＭファイル形式にのっとったファイル）であり続ける。

［１ファイル部分的返送］
返送されるＪＰＭファイルのポインタを調整するのではなく、一実施例では、サーバが、識別され返送される部分と共にＪＰＭファイルの一部を返送する。図１０に、部分的に送信される１つのＪＰＭファイルの例が示される。図１０を参照するに、図１０の左側に見られるように、サーバ上に完全なファイルがある。要求に基づいて、サーバは、ファイルの一部を選択し、クライアントにそれらを送信し、クライアントは送信された部分を識別（確認）する。これらの部分は図１０の第２列に示されている。それらの部分の確認は、部分的なコンテンツ及び要求されたボックスのバイト範囲を示すＨＴＴＰ応答により行なうことができる。このようにして返送されたファイルを利用するために、クライアントは、ファイルのどの部分が受信され、何が依然として欠けているかを追跡する。一実施例では、図１０の右列に示されるように、クライアントは、「フリーボックス」（Ｆｒｅｅ ｂｏｘｅｓ）でファイル中のギャップを埋めることでこれを行なう。付加的なデータが受信されると、フリーボックスのサイズが調整される又はフリーボックスが完全に削除される。要求に必要な全てのボックス及びコードストリーム部分をサーバが返送する限り、標準的なＪＰＭデコーダはそのファイル上で動作することができ、要求された領域をデコードする。理想的には、デコーダは、そのファイルが「穴又はホール」（ｈｏｌｅ）を有することに気付くべきであり、なぜなら、要求された領域外のボックスは送信されず且つ存在しないデータを指し示すポインタがファイル中に存在するからである。クライアントは、最終的には、サーバから利用可能なファイル全体を蓄積することができる。

［メディアデータビン及びプレースホルダ］
ＪＰＰストリーム及びＪＰＴストリームの中でファイルフォーマットボックスを返送する手法として、ＪＰＩＰ規格はメタデータビンを規定している。メタデータビンを利用するために、サーバは、図１０に使用されるもの及び図１１の左側に繰り返されるものと同じファイルを使用してもよい。要求がなされると、ファイルフォーマットボックスは、メタデータビンの一部として返送される。ファイルのトップレベルに表われる全てのボックスは、メタデータビン番号０内にあるか、又はメタデータビン０内のボックスの代わりにプレースホルダが存在する。「プレースホルダーボックス」は、サーバにより作成され、オリジナルのＪＰＭファイルには存在しないかもしれない。メタデータビン０にてプレースホルダで置換されるボックスは、他のメタデータビンに表われる。

サーバは、任意の順序でメタデータビンを送信することを選択することができ、特定のメタデータビンの最初の部分のみを送信してもよい。クライアントは、サーバから受信したメタデータビンを維持し、スマートＪＰＭデコーダは、各メタデータビンにどのようなオフセットがあるかについてのマップを維持することで、メタデータビンをナビゲートすることができる。メタデータビン及びスマートＪＰＭデコーダを利用することは、「フリー」ボックスとラベル付けされた多くのデータを有する大量のファイルを、クライアントが格納しなくて済むようにする。コードストリーム用のデータは、タイル又は区域のデータビンとメタデータビンを組合わせることで、ボックス用のデータと容易に組み合わされる。

本発明に関する多くの代替例及び修正は、上記の説明に目を通した当業者には確実に明白であり、例として提示及び説明された特定の実施例は、限定的に解釈されることを意図するものではない。仕上がって、様々な実施例の詳細に対する参照内容は、本発明に本質的な特徴のみを列挙する特許請求の範囲を限定するようには意図されない。

ＪＰＥＧ２０００システムの動作を示す図である。 圧縮された画像を通信するためのクラアイント及びサーバを示す図である。 ネットワーク例を示す図である。 表示用に分析されたレイアウトオブジェクトと共に書類画像を示す図である。 ポインタを有するボックスのリストとしてＪＰＭファイルを示す図である。 １つのＪＰＭファイルの主要なファイル構造を示す図である。 内包コードストリームにより複数のＪＰＭファイルとの相互的なアクセスの様子を示す図である。 外部コードストリームにより複数のＪＰＭファイルとの相互的なアクセスの様子を示す図である。 １つのＪＰＭファイル及び外部コードストリームによる相互的なアクセスの様子を示す図である。 バイト範囲を用いて送信されたファイルの一部による相互的なＪＰＭアクセスの様子を示す図である。 メタデータビンによる相互的なＪＰＭアクセスの様子を示す図である。

符号の説明

１０１ タイル
１０２ サブバンド
２０１ クライアント
２０２ サーバ
２１０ 要求
２１１ 応答
２２１ キャッシュ
２２２ デコーダ
２３１ クライアントキャッシュモデル
２３２ メモリ
２５０ ユーザ
４０１ 書類
４１１−４１３ レイアウトオブジェクト
４２１ 要求
４２２ 応答
４３１ ディスプレイ

Claims (82)

1. ＪＰＭファイルの複数部分に関する複数の要求を受信するステップ；及び
   前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップ；
   を有し、各部分がＪＰＭファイル形式にのっとったファイルである
   ことを特徴とする方法。
2. 前記複数部分が、１以上の望まれるページ、ページ中の１以上の望まれる領域、返送されるデータに望まれる解像度、返送されるデータを受信するのに望まれる技法、及び既に受信したＪＰＭファイル中のデータの指標より成る群から選択される
   ことを特徴とする請求項１記載の方法。
3. 前記要求が、ページに関する空間的部分、ページに関する低い解像度、ページの範囲及びラベル付けされていないボックスより成る群から選択される
   ことを特徴とする請求項１記載の方法。
4. 少なくとも１つの要求がＪＰＭファイルのボックスタイプを指定し、前記ＪＰＭファイルの少なくとも一部が、前記少なくとも１つの要求で指定された各ボックスタイプの１以上に格納された情報を含む
   ことを特徴とする請求項１記載の方法。
5. 前記少なくとも１つの要求が、更に、ボックスタイプに関連するサブボックスを指定し、前記応答が前記ボックスタイプの前記サブボックスに関連するデータを含む
   ことを特徴とする請求項４記載の方法。
6. 前記複数の要求の少なくとも１つが、あるオフセットから始まるＪＰＭファイル中のボックスを指定する
   ことを特徴とする請求項１記載の方法。
7. 前記応答が、前記ボックスのコンテンツの全てを返送する
   ことを特徴とする請求項６記載の方法。
8. 前記複数の要求の少なくとも１つが、ＪＰＭファイル中のページがディスプレイに表示されるところのページサイズを指定し、前記ページ内で要求された画像部分を指定する
   ことを特徴とする請求項１記載の方法。
9. 前記複数の要求の少なくとも１つにおける少なくとも１つのパラメータが、範囲を指定する
   ことを特徴とする請求項１記載の方法。
10. 前記複数の要求の少なくとも１つが、オフセットにより示されるコードストリームの部分を取得するために、オブジェクトボックスからのオフセットを含む
    ことを特徴とする請求項１記載の方法。
11. 前記複数の要求の少なくとも１つが、取得するコードストリームの部分を識別するためのフレームサイズ、領域オフセット及び領域サイズを指定する
    ことを特徴とする請求項１記載の方法。
12. 前記複数の要求の少なくとも１つが、ページ要求パラメータを含む
    ことを特徴とする請求項１記載の方法。
13. 外部ファイルストレージを用いて、サーバ上のＪＰＭファイルを格納するステップ
    を更に有することを特徴とする請求項１記載の方法。
14. 共用データ入力ボックス内の複数のコードストリームと共に、サーバ上のＪＰＭファイルを格納するステップ
    を更に有することを特徴とする請求項１記載の方法。
15. 前記複数の要求の少なくとも１つに関連するＪＰＭファイル内のボックスを収集するステップ；
    少なくとも１つの要求に関連する前記ボックスと共に、前記ファイル中の新たな場所に対するボックスのリファレンスを調整し、新たなＪＰＭファイルを作成するステップ；及び
    前記新たなＪＰＭファイルを送信するステップ；
    を更に有することを特徴とする請求項１記載の方法。
16. 新たなＪＰＭファイルを作成するステップが、外部ファイルに対するポインタを除去するステップを有する
    ことを特徴とする請求項１５記載の方法。
17. 新たなＪＰＭファイルを作成するステップが、ページ数及びページ上のオブジェクト数を調整するステップを有する
    ことを特徴とする請求項１５記載の方法。
18. ページ数及びページ上のオブジェクト数を調整するステップが、前記複数の要求の少なくとも１つを満たすのに必要なページ及びオブジェクトのみに調整するステップを有する
    ことを特徴とする請求項１７記載の方法。
19. 前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップが、少なくとも１つの外部に格納されたファイルに対する少なくとも１つのリファレンスと共に、別のＪＰＭファイルを送信するステップを有する
    ことを特徴とする請求項１記載の方法。
20. 前記少なくとも１つの外部に格納されたファイルが、少なくとも１つの外部に格納されたコードストリームを有する
    ことを特徴とする請求項１９記載の方法。
21. 以前に送信されたＪＰＭファイルのデータに対するリファレンスと共に別のＪＰＭファイルを送信するステップ
    を更に有することを特徴とする請求項１９記載の方法。
22. 外的に参照されるファイルによりＪＰＭファイルをグループ化し、前記複数の要求の少なくとも１つに応じて該グループを送信するステップ
    を更に有することを特徴とする請求項１記載の方法。
23. 前記グループがＭＩＭＥファイルである
    ことを特徴とする請求項２２記載の方法。
24. 前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップが、ページ又はレイアウトオブジェクトを除去せずに、サーバ上のファイルを指し示すための、１以上の要求の一部ではないオブジェクト用の変更されたリファレンスと共に前記ＪＰＭファイルを送信するステップを有する
    ことを特徴とする請求項１記載の方法。
25. 以前に送信されたＪＰＭファイル内で１以上のコードストリームを拡張するコードストリームデータを含む別のＪＰＭファイルを送信するステップ
    を更に有することを特徴とする請求項２４記載の方法。
26. 実行可能な命令を格納する１以上の記録可能な媒体を有する製造品であって、該命令は、システムにより実行される場合に、前記システムに：
    ＪＰＭファイルの複数部分に関する複数の要求を受信するステップ；及び
    前記複数の要求に応答して、ＪＰＭファイルを部分的に送信するステップ；
    を有する方法を実行させ、各部分がＪＰＭファイル形式にのっとったファイルである
    ことを特徴とする製造品。
27. 前記複数部分が、１以上の望まれるページ、ページ中の１以上の望まれる領域、返送されるデータに望まれる解像度、返送されるデータを受信するのに望まれる技法、及び既に受信したＪＰＭファイル中のデータの指標より成る群から選択される
    ことを特徴とする請求項２６記載の製造品。
28. 前記要求が、ページに関する空間的部分、ページに関する低い解像度、ページの範囲及びラベル付けされていないボックスより成る群から選択される
    ことを特徴とする請求項２６記載の製造品。
29. 少なくとも１つの要求がＪＰＭファイルのボックスタイプを指定し、前記ＪＰＭファイルの少なくとも一部が、前記少なくとも１つの要求で指定された各ボックスタイプの１以上に格納された情報を含む
    ことを特徴とする請求項２６記載の製造品。
30. 前記少なくとも１つの要求が、更に、ボックスタイプに関連するサブボックスを指定し、前記応答が前記ボックスタイプの前記サブボックスに関連するデータを含む
    ことを特徴とする請求項２９記載の製造品。
31. 前記複数の要求の少なくとも１つが、あるオフセットから始まるＪＰＭファイル中のボックスを指定する
    ことを特徴とする請求項２６記載の製造品。
32. 前記応答が、前記ボックスのコンテンツの全てを返送する
    ことを特徴とする請求項３１記載の製造品。
33. 前記複数の要求の少なくとも１つが、ＪＰＭファイル中のページがディスプレイに表示されるところのページサイズを指定し、前記ページ内で要求された画像部分を指定する
    ことを特徴とする請求項２６記載の製造品。
34. 前記複数の要求の少なくとも１つにおける少なくとも１つのパラメータが、範囲を指定する
    ことを特徴とする請求項２６記載の製造品。
35. 前記複数の要求の少なくとも１つが、オフセットにより示されるコードストリームの部分を取得するために、オブジェクトボックスからのオフセットを含む
    ことを特徴とする請求項２６記載の製造品。
36. 前記複数の要求の少なくとも１つが、取得するコードストリームの部分を識別するためのフレームサイズ、領域オフセット及び領域サイズを指定する
    ことを特徴とする請求項２６記載の製造品。
37. 前記複数の要求の少なくとも１つが、ページ要求パラメータを含む
    ことを特徴とする請求項２６記載の製造品。
38. 外部ファイルストレージを用いて、サーバ上のＪＰＭファイルを格納するステップ
    を前記方法が更に有することを特徴とする請求項２６記載の製造品。
39. 共用データ入力ボックス内の複数のコードストリームと共に、サーバ上のＪＰＭファイルを格納するステップ
    を前記方法が更に有することを特徴とする請求項２６記載の製造品。
40. 前記複数の要求の少なくとも１つに関連するＪＰＭファイル内のボックスを収集するステップ；
    少なくとも１つの要求に関連する前記ボックスと共に、前記ファイル中の新たな場所に対するボックスのリファレンスを調整し、新たなＪＰＭファイルを作成するステップ；及び
    前記新たなＪＰＭファイルを送信するステップ；
    を前記方法が更に有することを特徴とする請求項２６記載の製造品。
41. 新たなＪＰＭファイルを作成するステップが、外部ファイルに対するポインタを除去するステップを有する
    ことを特徴とする請求項４０記載の製造品。
42. 新たなＪＰＭファイルを作成するステップが、ページ数及びページ上のオブジェクト数を調整するステップを有する
    ことを特徴とする請求項４０記載の製造品。
43. ページ数及びページ上のオブジェクト数を調整するステップが、前記複数の要求の少なくとも１つを満たすのに必要なページ及びオブジェクトのみに調整するステップを有する
    ことを特徴とする請求項４２記載の製造品。
44. 前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップが、少なくとも１つの外部に格納されたファイルに対する少なくとも１つのリファレンスと共に、別のＪＰＭファイルを送信するステップを有する
    ことを特徴とする請求項２６記載の製造品。
45. 前記少なくとも１つの外部に格納されたファイルが、少なくとも１つの外部に格納されたコードストリームを有する
    ことを特徴とする請求項４４記載の製造品。
46. 以前に送信されたＪＰＭファイルのデータに対するリファレンスと共に別のＪＰＭファイルを送信するステップ
    を前記方法が更に有することを特徴とする請求項４４記載の製造品。
47. 外的に参照されるファイルによりＪＰＭファイルをグループ化し、前記複数の要求の少なくとも１つに応じて該グループを送信するステップ
    を前記方法が更に有することを特徴とする請求項２６記載の製造品。
48. 前記グループがＭＩＭＥファイルである
    ことを特徴とする請求項４７記載の製造品。
49. 前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップが、ページ又はレイアウトオブジェクトを除去せずに、サーバ上のファイルを指し示すための、１以上の要求の一部ではないオブジェクト用の変更されたリファレンスと共に前記ＪＰＭファイルを送信するステップを有する
    ことを特徴とする請求項２６記載の製造品。
50. 以前に送信されたＪＰＭファイル内で１以上のコードストリームを拡張するコードストリームデータを含む別のＪＰＭファイルを送信するステップ
    を前記方法が更に有することを特徴とする請求項４９記載の製造品。
51. ＪＰＭファイルの複数部分に関する複数の要求を受信する入力；及び
    前記複数の要求に応答してＪＰＭファイルを部分的に送信するサーバコア；
    を有し、各部分がＪＰＭファイル形式にのっとったファイルである
    ことを特徴とする装置。
52. 前記複数部分が、１以上の望まれるページ、ページ中の１以上の望まれる領域、返送されるデータに望まれる解像度、返送されるデータを受信するのに望まれる技法、及び既に受信したＪＰＭファイル中のデータの指標より成る群から選択される
    ことを特徴とする請求項５１記載の装置。
53. 前記要求が、ページに関する空間的部分、ページに関する低い解像度、ページの範囲及びラベル付けされていないボックスより成る群から選択される
    ことを特徴とする請求項５１記載の装置。
54. 少なくとも１つの要求がＪＰＭファイルのボックスタイプを指定し、前記ＪＰＭファイルの少なくとも一部が、前記少なくとも１つの要求で指定された各ボックスタイプの１以上に格納された情報を含む
    ことを特徴とする請求項５１記載の装置。
55. 前記少なくとも１つの要求が、更に、ボックスタイプに関連するサブボックスを指定し、前記応答が前記ボックスタイプの前記サブボックスに関連するデータを含む
    ことを特徴とする請求項５４記載の装置。
56. 前記複数の要求の少なくとも１つが、あるオフセットから始まるＪＰＭファイル中のボックスを指定する
    ことを特徴とする請求項５１記載の装置。
57. 前記応答が、前記ボックスのコンテンツの全てを返送する
    ことを特徴とする請求項５６記載の装置。
58. 前記複数の要求の少なくとも１つが、ＪＰＭファイル中のページがディスプレイに表示されるところのページサイズを指定し、前記ページ内で要求された画像部分を指定する
    ことを特徴とする請求項５１記載の装置。
59. 前記複数の要求の少なくとも１つにおける少なくとも１つのパラメータが、範囲を指定する
    ことを特徴とする請求項５１記載の装置。
60. 前記複数の要求の少なくとも１つが、オフセットにより示されるコードストリームの部分を取得するために、オブジェクトボックスからのオフセットを含む
    ことを特徴とする請求項５１記載の装置。
61. 前記複数の要求の少なくとも１つが、取得するコードストリームの部分を識別するためのフレームサイズ、領域オフセット及び領域サイズを指定する
    ことを特徴とする請求項５１記載の装置。
62. 前記複数の要求の少なくとも１つが、ページ要求パラメータを含む
    ことを特徴とする請求項５１記載の装置。
63. 前記サーバコアが、外部ファイルストレージを用いて、サーバ上のＪＰＭファイルを格納する
    ことを特徴とする請求項５１記載の装置。
64. 前記サーバコアが、共用データ入力ボックス内の複数のコードストリームと共に、ＪＰＭファイルを格納する
    ことを特徴とする請求項５１記載の装置。
65. 前記サーバコアが、少なくとも１つの外部に格納されたファイルに対する少なくとも１つのリファレンスと共に、別のＪＰＭファイルを送信することで、前記複数の要求に応答してＪＰＭファイルを部分的に送信する
    ことを特徴とする請求項５１記載の装置。
66. 前記少なくとも１つの外部に格納されたファイルが、少なくとも１つの外部に格納されたコードストリームを有する
    ことを特徴とする請求項６５記載の装置。
67. 以前に送信されたＪＰＭファイルのデータに対するリファレンスと共に別のＪＰＭファイルを送信する
    ことを特徴とする請求項６５記載の装置。
68. 前記サーバコアが、ページ又はレイアウトオブジェクトを除去せずに、サーバ上のファイルを指し示すための、１以上の要求の一部ではないオブジェクト用の変更されたリファレンスと共に前記ＪＰＭファイルを送信することで、前記複数の要求に応答してＪＰＭファイルを部分的に送信する
    ことを特徴とする請求項５１記載の装置。
69. 以前に送信されたＪＰＭファイル内で１以上のコードストリームを拡張するコードストリームデータを含む別のＪＰＭファイルが送信される
    ことを特徴とする請求項６８記載の装置。
70. 複数の要求の少なくとも１つに関連するＪＰＭファイル内のボックスを収集するステップ；
    前記少なくとも１つの要求に関連するボックスと共に、ファイル内の新たな場所に対するボックスのリファレンスを調整し、新たなＪＰＭファイルを作成するステップ；
    前記新たなＪＰＭファイルを送信するステップ；
    を有することを特徴とする方法。
71. 新たなＪＰＭファイルを作成するステップが、外部ファイルに対するポインタを除去するステップを有する
    ことを特徴とする請求項７０記載の方法。
72. 新たなＪＰＭファイルを作成するステップが、ページ数及びページ上のオブジェクト数を調整するステップを有する
    ことを特徴とする請求項７０記載の方法。
73. ページ数及びページ上のオブジェクト数を調整するステップが、前記複数の要求の少なくとも１つを満たすのに必要なページ及びオブジェクトのみに調整するステップを有する
    ことを特徴とする請求項７２記載の方法。
74. 実行可能な命令を格納する１以上の記録可能な媒体を有する製造品であって、該命令は、システムにより実行される場合に、前記システムに：
    複数の要求の少なくとも１つに関連するＪＰＭファイル内のボックスを収集するステップ；
    前記少なくとも１つの要求に関連するボックスと共に、ファイル内の新たな場所に対するボックスのリファレンスを調整し、新たなＪＰＭファイルを作成するステップ；
    前記新たなＪＰＭファイルを送信するステップ
    を有する方法を実行させることを特徴とする製造品。
75. 複数の要求の少なくとも１つに関連するＪＰＭファイル内のボックスを収集する手段；
    前記少なくとも１つの要求に関連するボックスと共に、ファイル内の新たな場所に対するボックスのリファレンスを調整し、新たなＪＰＭファイルを作成する手段；
    前記新たなＪＰＭファイルを送信する手段；
    を有することを特徴とする装置。
76. ＪＰＭファイルの複数部分についての複数の要求を受信するステップ；
    前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップ；及び
    送信される部分の指標と共に前記ＪＰＭファイルの部分を送信するステップ；
    を有することを特徴とする方法。
77. 送信される部分の指標と共に前記ＪＰＭファイルの部分を送信するステップが、返送されるボックスの部分的内容及びバイト範囲を示すＨＴＴＰ応答を使用するステップを有する
    ことを特徴とする請求項７６記載の方法。
78. 受信したＪＰＭファイル内のギャップをフリーボックスで埋めるステップ
    を更に有することを特徴とする請求項７６記載の方法。
79. 受信したＪＰＭファイル内の１以上のギャップを埋める新たなデータが到来するように、前記フリーボックスのサイズを調整するステップ
    を更に有することを特徴とする請求項７８記載の方法。
80. 実行可能な命令を格納する１以上の記録可能な媒体を有する製造品であって、該命令は、システムにより実行される場合に、前記システムに：
    ＪＰＭファイルの複数部分についての複数の要求を受信するステップ；
    前記複数の要求に応答してＪＰＭファイルを部分的に送信するステップ；及び
    送信される部分の指標と共に前記ＪＰＭファイルの部分を送信するステップ；
    を有する方法を実行させることを特徴とする製造品。
81. 複数の要求を生成するステップ；及び
    前記複数の要求に対する応答の一部として、ＪＰＭファイルを部分的に受信するステップ；
    を有し、少なくとも１つの部分が、ＪＰＭファイルの以前に受信された部分として、受信されたＪＰＭファイルの部分を指し示す
    ことを特徴とする方法。
82. 実行可能な命令を格納する１以上の記録可能な媒体を有する製造品であって、該命令は、システムにより実行される場合に、前記システムに：
    複数の要求を生成するステップ；及び
    前記複数の要求に対する応答の一部として、ＪＰＭファイルを部分的に受信するステップ；
    を有する方法を実行させ、少なくとも１つの部分が、ＪＰＭファイルの以前に受信された部分として、受信されたＪＰＭファイルの部分を指し示すことを特徴とする製造品。

Images