(57)【要約】【課題】本発明は、通信メカニズムを介してコードストリームの一部をトランスポートする方法及び装置の提供を目的とする。【解決手段】一実施例において、本発明の方法は、ネットワークを介して要求を送信し、ネットワークから、要求に対する応答の一部のようなリターンタイプとしてＪＰＥＧ２０００に準拠したコードストリームのタイルパーツを受信する。【選択図】      図２
2004208266.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して要求を送信する手順と、
ネットワークから、要求に対する応答の一部のようなリターンタイプとしてＪＰＥＧ２０００に準拠したコードストリームのタイルパーツを受信する手順と、
を含む方法。
【請求項２】
ネットワークは、ローカル・エリア・ネットワーク（ＬＡＮ）と、ワイド・エリア・ネットワーク（ＷＡＮ）と、インターネットと、ワールド・ワイド・ウェブ（ＷＷＷ）とからなる群より選択された一つのネットワークを含む、請求項１記載の方法。
【請求項３】
応答はＨＴＴＰ応答を含む、請求項１記載の方法。
【請求項４】
ＨＴＴＰチャンク形式転送エンコーディングを使用する手順を更に含む、請求項３記載の方法。
【請求項５】
ＨＴＴＰチャネルを閉じることなく応答を終了する手順を更に含む、請求項４記載の方法。
【請求項６】
ユーザがコードストリームに対応した画像の範囲内でビューポートを変更した場合に、新しい要求に対する新しい応答を始める手順を更に含む、請求項５記載の方法。
【請求項７】
少なくとも一つのタイルパーツをＨＴＴＰを用いてサーバへアップロードする手順を更に含む、請求項１記載の方法。
【請求項８】
ネットワークを介して要求を送信する手順と、
ネットワークから、要求に対する応答の一部のようなリターンタイプとしてＪＰＥＧ２０００に準拠したコードストリームのタイルパーツを受信する手順と、
をコンピュータに実行させるためのプログラム。
【請求項９】
ネットワークは、ローカル・エリア・ネットワーク（ＬＡＮ）と、ワイド・エリア・ネットワーク（ＷＡＮ）と、インターネットと、ワールド・ワイド・ウェブ（ＷＷＷ）とからなる群より選択された一つのネットワークを含む、請求項８記載のプログラム。
【請求項１０】
応答はＨＴＴＰ応答を含む、請求項８記載のプログラム。
【請求項１１】
ネットワークを介して要求を送信する手段と、
ネットワークから、要求に対する応答の一部のようなリターンタイプとしてＪＰＥＧ２０００に準拠したコードストリームのタイルパーツを受信する手段と、
を有する装置。
【請求項１２】
ネットワークは、ローカル・エリア・ネットワーク（ＬＡＮ）と、ワイド・エリア・ネットワーク（ＷＡＮ）と、インターネットと、ワールド・ワイド・ウェブ（ＷＷＷ）とからなる群より選択された一つのネットワークを含む、請求項１１記載の装置。
【請求項１３】
応答はＨＴＴＰ応答を含む、請求項１１記載の装置。
【請求項１４】
クライアントと、
クライアントに接続され、プロトコルを使用してネットワークを介して圧縮コードストリームの一部分を交換するサーバと、
を有し、
クライアントで処理されるサーバからの要求及び応答は画像オブジェクトを含み、
サーバで処理されるクライアントからの要求及び応答はバイトレンジを含む、システム。
【請求項１５】
バイトレンジはプログラム呼び出しを用いて指定される、請求項１４記載のシステム。
【請求項１６】
プログラムはＣ言語プログラムを含む、請求項１５記載のシステム。
【請求項１７】
プログラム呼び出しは、ｆｓｅｅｋ（）呼び出しとｆｒｅａｄ（）呼び出しのシーケンスを含む、請求項１６記載のシステム。
【請求項１８】
応答はＨＴＴＰ応答を含む、請求項１４記載のシステム。
【請求項１９】
サーバ及びクライアントは、要求と応答を交換するため、ＨＴＴＰチャンク形式転送エンコーディングを使用する、請求項１４記載のシステム。
【請求項２０】
ＨＴＴＰチャネルを閉じることなく少なくとも一つの応答を終了させる、請求項１４記載のシステム。
【請求項２１】
一連のステージを用いてクライアントとサーバの間で圧縮データのコードストリームをトランスポートする方法であって、
圧縮画像オブジェクト応答及びビューポートのシーケンスを画像データに変換する第１ステージと、
ビューポート要求を圧縮データオブジェクト要求へ変換する第２ステージと、バイトレンジ応答に応じて圧縮画像オブジェクトを作成する第３ステージと、
圧縮画像オブジェクト要求をバイトレンジ要求に変換する第４ステージと、
を有する方法。
【請求項２２】
二つ以上のステージは単一の場所で実行される、請求項２１記載の方法。
【請求項２３】
二つ以上のステージは、サーバとクライアントの間に通信可能に接続されたプロキシ・サーバによって実行される、請求項２２記載の方法。
【請求項２４】
二つ以上のステージが第２ステージを構成する、請求項２３記載の方法。
【請求項２５】
二つ以上のステージが第３ステージを構成する、請求項２３記載の方法。
【請求項２６】
第１ステージ、第２ステージ、第３ステージ及び第４ステージはサーバで実行される、請求項２１記載の方法。
【請求項２７】
第１ステージはクライアントで実行される、請求項２１記載の方法。
【請求項２８】
第２ステージ、第３ステージ及び第４ステージはサーバで実行される、請求項２１記載の方法。
【請求項２９】
第１ステージ及び第２ステージはクライアントで実行される、請求項２１記載の方法。
【請求項３０】
第３ステージ及び第４ステージはサーバで実行される、請求項２１記載の方法。
【請求項３１】
第１ステージ、第２ステージ、第３ステージ及び第４ステージはクライアントで実行される、請求項２１記載の方法。
【請求項３２】
受信データに対してデコーダを作動させる伸長ステージを更に有する、請求項２１記載の方法。
【請求項３３】
デコーダは着目領域を復号化する、請求項３２記載の方法。
【請求項３４】
着目領域は、クライアントによって指定された着目領域である、請求項３３記載の方法。
【請求項３５】
デコーダはＪＰＥＧ２０００伸長器を含む、請求項３２記載の方法。
【請求項３６】
デコーダは、完全解像度画像を生成し、完全解像度画像内の着目領域をクロッピングすることによりクロップ状画像を生成し、そのクロップ状画像を別の解像度に拡大縮小することが可能である、請求項３２記載の方法。
【請求項３７】
デコーダは、望ましい解像度、着目領域、コンポーネント及び品質に必要なコードストリームの部分だけを復号化する、請求項３２記載の方法。
【請求項３８】
第２ステージの間に、第１ステージへ移される応答のリストを維持する、請求項２１記載の方法。
【請求項３９】
第２ステージの間に、画像の望ましい着目領域を基準グリッド単位に変換し、着目領域と交差するタイルを判定し、指定された解像度及び品質を使用してタイルパーツを選択する、請求項２１記載の方法。
【請求項４０】
第２ステージの間に、タイルパーツをクライアントへ送信すべきかどうかを示す１ビットと、タイルパーツが送信されたかどうかを示す１ビットと、を記憶する、請求項２１記載の方法。
【請求項４１】
第２ステージの間に、各タイルパーツ毎の優先順位を示す補助的な情報を記憶する、請求項２１記載の方法。
【請求項４２】
第３ステージの間に、画像オブジェクト要求のシーケンスを一時記憶する、請求項２１記載の方法。
【請求項４３】
第３ステージの間に、
望ましいデータを獲得し、
返却されたデータをＨＴＴＰ応答でラッピングし、
返却されたデータを含むＨＴＴＰ応答を第２ステージへ送る、
請求項２１記載の方法。
【請求項４４】
第３ステージの間に、返却されたデータを識別子でラッピングする、請求項２１記載の方法。
【請求項４５】
識別子は新しいヘッダを含む、請求項４４記載の方法。
【請求項４６】
識別子は、応答内の符号化データよりも先行するメッセージ本体中にタイプのシーケンスにより構成される、請求項４４記載の方法。
【請求項４７】
第４ステージの間に、要求の場所を判定するために多数の読み出しが使用された場合に限り、要求画像オブジェクトを返却する、請求項２１記載の方法。
【請求項４８】
第４ステージの間に、
メインヘッダのＳＯＣマーカー及びＳＩＺマーカーを読み取り、
各タイルパーツの長さを獲得するためＳＯＴマーカーを読み取り、
レンジを識別するため各タイルパーツの始まりと長さのリストを使用することによりバイトレンジ要求を生成する、
請求項２１記載の方法。
【請求項４９】
ＪＰＥＧ２０００デコーダで復号化されるＪＰＥＧ２０００コードストリームを形成するため応答を要求に連結する、請求項２１記載の方法。
【請求項５０】
上記ＪＰＥＧ２０００デコーダはプロトコルを理解できないデコーダである、請求項４９記載の方法。
【請求項５１】
圧縮画像オブジェクト応答及びビューポートのシーケンスを画像データに変換する第１手順と、
ビューポート要求を圧縮データオブジェクト要求へ変換する第２手順と、
バイトレンジ応答に応じて圧縮画像オブジェクトを作成する第３手順と、
圧縮画像オブジェクト要求をバイトレンジ要求に変換する第４手順と、
をコンピュータに実行させ、一連のステージを用いてクライアントとサーバの間で圧縮データのコードストリームをトランスポートさせるためのプログラム。
【請求項５２】
二つ以上の手順は単一の場所で実行される、請求項５１記載のプログラム。
【請求項５３】
二つ以上の手順は、サーバとクライアントの間に通信可能に接続されたプロキシ・サーバによって実行される、請求項５２記載のプログラム。
【請求項５４】
二つ以上の手順が第２手順を構成する、請求項５３記載のプログラム。
【請求項５５】
二つ以上の手順が第３手順を構成する、請求項５３記載のプログラム。
【請求項５６】
第１手順、第２手順、第３手順及び第４手順はサーバで実行される、請求項５１記載のプログラム。
【請求項５７】
第１手順はクライアントで実行される、請求項５１記載のプログラム。
【請求項５８】
第２手順、第３手順及び第４手順はサーバで実行される、請求項５１記載のプログラム。
【請求項５９】
第１手順及び第２手順はクライアントで実行される、請求項５１記載のプログラム。
【請求項６０】
第３手順及び第４手順はサーバで実行される、請求項５１記載のプログラム。
【請求項６１】
第１手順、第２手順、第３手順及び第４手順はクライアントで実行される、請求項５１記載のプログラム。
【請求項６２】
受信データに対してデコーダを作動する伸長手順をコンピュータに更に実行させる、請求項５１記載のプログラム。
【請求項６３】
一連のステージを用いてクライアントとサーバの間で圧縮データのコードストリームをトランスポートする装置であって、
圧縮画像オブジェクト応答及びビューポートのシーケンスを画像データに変換する第１ステージと、
ビューポート要求を圧縮データオブジェクト要求へ変換する第２ステージと、
バイトレンジ応答に応じて圧縮画像オブジェクトを作成する第３ステージと、
圧縮画像オブジェクト要求をバイトレンジ要求に変換する第４ステージと、
を有する装置。
【請求項６４】
二つ以上のステージは単一の場所で実行される、請求項６３記載の装置。
【請求項６５】
二つ以上のステージは、サーバとクライアントの間に通信可能に接続されたプロキシ・サーバによって実行される、請求項６３記載の装置。
【請求項６６】
二つ以上のステージが第２ステージを構成する、請求項６５記載の装置。
【請求項６７】
二つ以上のステージが第３ステージを構成する、請求項６５記載の装置。
【請求項６８】
第１ステージ、第２ステージ、第３ステージ及び第４ステージはサーバで実行される、請求項６３記載の装置。
【請求項６９】
第１ステージはクライアントで実行される、請求項６３記載の装置。
【請求項７０】
第２ステージ、第３ステージ及び第４ステージはサーバで実行される、請求項６３記載の装置。
【請求項７１】
第１ステージ及び第２ステージはクライアントで実行される、請求項６３記載の装置。
【請求項７２】
第３ステージ及び第４ステージはサーバで実行される、請求項６３記載の装置。
【請求項７３】
第１ステージ、第２ステージ、第３ステージ及び第４ステージはクライアントで実行される、請求項６３記載の装置。
【請求項７４】
受信データに対してデコーダを作動する伸長ステージを更に有する、請求項６３記載の装置。
【請求項７５】
サーバが要求を受信する手順と、
サーバがＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手順と、
を含む、方法。
【請求項７６】
サーバがＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手順は、タイルパーツをコードストリームのメインヘッダへ対応付けることができるようにするためＰＯＣマーカーを使用する手順を含む、請求項７５記載の方法。
【請求項７７】
サーバで要求を受信する手順と、
サーバでＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手順と、
をコンピュータに実現させるためのプログラム。
【請求項７８】
サーバでＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手順は、タイルパーツをコードストリームのメインヘッダへ対応付けることができるようにするためＰＯＣマーカーを使用する手順を含む、請求項７７記載のプログラム。
【請求項７９】
要求を受信する手段と、
サーバがＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手段と、
を含む、装置。
【請求項８０】
ＪＰＥＧ２０００に準拠したコードストリームに連結できるタイルパーツを生成する手段は、タイルパーツをコードストリームのメインヘッダへ対応付けることができるようにするためＰＯＣマーカーを使用する手段を含む、請求項７９記載の装置。
【請求項８１】
タイルパーツを第１の順序でサーバに格納する手順と、
サーバがクライアントからクライアントが当該タイルパーツの順序として期待する第２の順序を指定するタイルパーツに関する要求を受信する手順と、
サーバがタイル内でタイルを第２の順序に並べ替える手順と、
並べ替えられたタイルパーツをネットワークを介して送信する手順と、
を有する方法。
【請求項８２】
サーバが返却されたタイルパーツの一部を用いてＰＯＣマーカーを書き込む手順を更に有する、請求項８１記載の方法。
【請求項８３】
ＰＯＣマーカーは、該タイルパーツ毎に格納されている解像度、レイヤ、及び、コンポーネントを指定する、請求項８２記載の方法。
【請求項８４】
ＪＰＥＧ２０００コードストリームの一部であるＪＰＥＧ２０００画像の一部をネットワークを介してトランスポートする方法であって、
ＪＰＥＧ２０００コードストリームの一部を要求する手順と、
ＪＰＥＧ２０００コードストリームの一部をタイルパーツとして受信する手順と、
を有する方法。
【請求項８５】
ＪＰＥＧ２０００コードストリームの一部はＨＴＴＰ応答を用いて受信される、請求項８４記載の方法。
【請求項８６】
ＪＰＥＧ２０００コードストリームの一部を要求する手順は、レンジヘッダを用いてタイルパーツを要求する手順を含む、請求項８４記載の方法。
【請求項８７】
レンジヘッダはＨＴＴＰレンジヘッダを含む、請求項８４記載の方法。
【請求項８８】
サーバがタイルパーツは要求を満たすためにクライアントへ送信しなければならないデータだけであることを決定できるようにするためクライアントで利用可能なデータを指示する手順を更に有する、請求項８４記載の方法。
【請求項８９】
利用可能なデータはクライアントが前に受信した領域を含む、請求項８８記載の方法。
【請求項９０】
利用可能なデータはクライアントが前に受信したタイルパーツを含む、請求項８８記載の方法。
【請求項９１】
低い解像度のタイルパーツがより高解像度のタイルパーツよりも前に格納されるように、サーバ側のファイルにプログレッション順にコードストリームを格納する手順を更に有する、請求項８４記載の方法。
【請求項９２】
プログレッション順は、解像度−レイヤ−コンポーネント−位置（ＲＬＣＰ）の順のプログレッション順である、請求項９１記載の方法。
【請求項９３】
プログレッション順は、タイルパーツがあらゆる解像度及びあらゆるレイヤで分割されるような順序である、請求項９２記載の方法。
【請求項９４】
プログレッション順は、レイヤ−解像度−コンポーネント−位置（ＬＲＣＰ）の順のプログレッション順である、請求項９１記載の方法。
【請求項９５】
プログレッション順は、少なくとも一つのタイルがレイヤ境界だけでタイルパーツに分割されるような順序である、請求項９４記載の方法。
【請求項９６】
プログレッション順は、損失の無い表現用の符号化データを含む、請求項９４記載の方法。
【請求項９７】
損失の無い表現用の符号化データは、プログレッション順の最後のタイルパーツに格納される、請求項９６記載の方法。
【請求項９８】
コードストリームを形成するため、応答を複数の要求に連結する手順を更に有する、請求項８４記載の方法。
【請求項９９】
クライアントが着目している一つ以上のボックスを指示するため、第３ティアー要求のパラメータに対する一つ以上のボックスを指定する手順を更に有する、請求項８４記載の方法。
【請求項１００】
一つ以上のサブボックスを指定する手順を更に有する、請求項９９記載の方法。
【請求項１０１】
画像レベルのデータと、バイトレンジでのメタデータの少なくとも一部分を要求する手順を更に有する、請求項８４記載の方法。
【請求項１０２】
クライアントからサーバへの要求とサーバからクライアントへの応答を処理する一連のステージを使用するトランスポート方法であって、
一連のステージを使用する手順は、
ビューポートをタイルの組へマッピングすることによりビューポート要求をタイルパーツに変換する手順と、
画像オブジェクト要求をバイトレンジ要求に変換する手順と、
バイトレンジ応答を生成する手順と、
バイトレンジ応答から画像オブジェクトを作成する手順と、
を含む、
トランスポート方法。
【請求項１０３】
画像オブジェクトに対して伸長器を作動させる手順を更に有する、請求項１０２記載のトランスポート方法。
【請求項１０４】
完全解像度画像を生成する手順と、
着目領域を獲得するため、完全解像度画像をクロッピングする手順と、
着目領域を所定の着目領域へ拡大縮小する手順と、
を更に有する、請求項１０２記載のトランスポート方法。
【請求項１０５】
ビューポートをタイルの組へマッピングすることによりビューポート要求をタイルパーツに変換する手順と、
画像オブジェクト要求をバイトレンジ要求に変換する手順と、
バイトレンジ応答を生成する手順と、
バイトレンジ応答から画像オブジェクトを作成する手順と、
をコンピュータに実行させるためのプログラム。
【請求項１０６】
画像オブジェクトに対して伸長器を作動させる手順を更にコンピュータに実行させるための請求項１０５記載のプログラム。
【請求項１０７】
完全解像度画像を生成する手順と、
着目領域を獲得するため、完全解像度画像をクロッピングする手順と、
着目領域を所定の着目領域へ拡大縮小する手順と、
を更にコンピュータに実現させるための請求項１０５記載のプログラム。
【請求項１０８】
ビューポートをタイルの組へマッピングすることによりビューポート要求をタイルパーツに変換する手段と、
画像オブジェクト要求をバイトレンジ要求に変換する手段と、
バイトレンジ応答を生成する手段と、
バイトレンジ応答から画像オブジェクトを作成する手段と、
を含む、
装置。
【請求項１０９】
画像オブジェクトに対して伸長器を作動させる手段を更に有する、請求項１０８記載の装置。
【請求項１１０】
完全解像度画像を生成する手段と、
着目領域を獲得するため、完全解像度画像をクロッピングする手段と、
着目領域を所定の着目領域へ拡大縮小する手段と、
を更に有する、請求項１０８記載の装置。
【請求項１１１】
請求項８乃至１０、５１乃至６２、７７、７８、１０５乃至１０７のうち何れか一項記載のプログラムを格納した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は画像通信の分野に関する。特に、本発明は、通信チャネルを介した、画像の一部分と、関連したメタデータの通信に関する。
【０００２】
【従来の技術】
ＪＰＥＧ２０００は、ＪＰＥＧ２０００ファイルの全体を復号化することなく、画像の様々な領域、解像度、及び、品質レベルを利用できるようにするため設計された。多様なプログレッション順序が定義され、低速の通信チャネルを介して伝送されたファイルは、例えば、低解像度から高解像度へ、若しくは、低品質から高品質へ、ある種の方法で「進行（プログレス）」する。また、ファイルが蓄積された順序とは異なる順序で画像の一部を選択し得る機能も興味がある。一般的に、伝送のために画像の領域と品質が対話的に選択される。
【０００３】
仮想メディア（Ｖｍｅｄｉａ）アクセス・プロトコルが提案され、Ｖｍｅｄｉａを用いる双方向性ＪＰＥＧ２０００ブラウザが開発されている（例えば、非特許文献１を参照。）。
【０００４】
ＪＰＥＧ２０００画像を伝送するためのクライアント／サーバ環境も規定されている（例えば、非特許文献２を参照。）。非特許文献２には、スマート・クライアント、ダム・クライアント、スマート・サーバ、ダム・サーバが規定され、「パン・アンド・ズーム」セッションでのＪＰＥＧ２０００バイト使用法の例が与えられ、インターネット・イメージング・プロトコル（ＩＩＰ）、バージョン１．０．５、１９９７年１０月６日に基づくプロトコルが記載されている。このプロトコルは、非特許文献３に記載されているアイデアの一部を拡張しているが、しかし、非特許文献４に記載されているような転送用のＨＴＴＰに基づいている。
【０００５】
ＪＰＥＧ２０００画像はＨＴＴＰを使用して送信される（例えば、非特許文献５を参照。）。しかし、ヘッダ情報を含む別々のインデックス・ファイルが送信され、望ましい画像構成要素を得るためＨＴＴＰバイトレンジ要求（リクエスト）が使用される。このプロトコルは、要求のパイプライン化が可能であるが、割り込みはできない。インデックス・ファイルを取得するために余分なラウンド・トリップ時間を必要とする。それらの例は、非常に非効率的である。なぜならば、複数のバイトレンジが境界値を含む「コンテント−タイプ：マルチパート／バイトレンジ」によって送信されるからである。あるケースでは、４８バイトのデータに対して７０バイトのオーバーヘッドが存在する。
【０００６】
バイトｊｐボックス、ｊ２ｋパケットのような値をもつＨＴＴＰ「アクセプト−レンジ」が使用されている（例えば、非特許文献６を参照。）。このアプローチの主要な欠点は、補助的なレンジ・タイプをサポートするサーバを決定した後に、初期コネクションを終了し、新しいコネクションを開設しなければならないことである。
【０００７】
ＪＰＥＧ２０００ファイル転送の基本要素としてプリーシンクト（ｐｒｅｃｉｎｃｔｓ）及びコードブロックが使用されている（例えば、非特許文献７を参照。）。この文献では、バイナリ・コンテナを使用し、アクノリッジ及びセッション情報を指定し、基本リターンタイプとしてプリーシンクトのバイトレンジを使用するプロトコルが定義されている。これに対して、このプロトコルは、通信の基本要素として、セルフラベリング型タイルパーツを使用する。このようにして、クライアントとサーバの両方が有効なＪＰＥＧ２０００コードストリームの複製を入手する。
【０００８】
ＪＰＥＧ２０００双方向プロトコル（ＪＰＩＰ）の提案の募集が発表されている（例えば、非特許文献８を参照。）。この文献には、ブラウザと共に使用され、効率の指標が求められるパンとズームのステップのシーケンスが記載されている。
【０００９】
この提案募集への回答として、完全なプロトコルと、ＪＰＥＧ２０００ファイルの個別のコードブロック又はより大きい部分へのアクセスが規定されている（例えば、非特許文献９を参照。）。この提案には、プロトコル用のアプリケーション・プログラマーズ・インタフェース（ＡＰＩ）も規定されている。
【００１０】
【非特許文献１】
Ｊ．Ｌｉ，  Ｈ．Ｈ．Ｓｕｎ著、“Ｖｉｒｔｕａｌ  Ｍｅｄｉａ  （Ｖｍｅｄｉａ）  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ  ａｎｄ  ｉｔｓ  Ａｐｐｌｉｃａｔｉｏｎ  ｉｎ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｉｍａｇｅ  Ｂｒｏｗｓｉｎｇ”、Ｐｒｏｃ．  ＳＰＩＥ  Ｃｏｎｆ．  ｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｃｏｍｐｕｔｉｎｇ  ａｎｄ  Ｎｅｔｗｏｒｋｉｎｇ、２００１年１月２２−２３日、Ｓａｎ  Ｊｏｓｅ，  ＣＡ、第４３１２巻、ｐ．９９−１１０
【非特許文献２】
Ｍ．Ｂｏｌｉｅｋ，  Ｇ．Ｋ．Ｗｕ，  Ｍ．Ｊ．Ｇｏｒｍｉｓｈ著、“ＪＰＥＧ２０００  ｆｏｒ  Ｅｆｆｉｃｉｅｎｔ  Ｉｍａｇｉｎｇ  ｉｎ  Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ  Ｅｎｖｉｒｏｎｍｅｎｔ”、Ｐｒｏｃ．  ＳＰＩＥ  Ｃｏｎｆ．  ｏｎ  Ａｐｐ．  ｏｆ  Ｄｉｇｉｔａｌ  Ｉｍａｇｉｎｇ、２００１年７月３１−８月３日、Ｓａｎ  Ｄｉｅｇｏ，  ＣＡ、第４４７２巻、ｐ．２１２−２２３
【非特許文献３】
Ｂｏｌｉｅｋ外、“ＪＰＥＧ  ２０００  ｆｏｒ  Ｅｆｆｉｃｉｅｎｔ  Ｉｍａｇｉｎｇ  ｉｎ  Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ  Ｅｎｖｉｒｏｎｍｅｎｔ”、Ｐｒｏｃ．  ＳＰＩＥ  Ｃｏｎｆ．  ｏｎ  Ａｐｐ．  ｏｆ  Ｄｉｇｉｔａｌ  Ｉｍａｇｉｎｇ、２００１年７月３１日−８月３日、Ｓａｎ  Ｄｉｅｇｏ，  ＣＡ、第４４７２巻、ｐｐ．２１２−２２３、
【非特許文献４】
Ｒ．Ｆｉｅｌｄｉｎｇ，  Ｊ．Ｇｅｔｔｙｓ，  Ｊ．Ｃ．Ｍｏｇｕｌ，  Ｈ．Ｆｒｙｓｔｙｋ，  Ｌ．Ｍａｓｉｎｔｅｒ，  Ｐ．Ｌｅａｃｈ，  Ｔ．Ｂｅｒｎｅｒｓ−Ｌｅｅ（編）、“Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ＿  ＨＴＴＰ／１．１”、ＲＦＣ２６１６、１９９９年６月
【非特許文献５】
Ｓａｃｈｉｎ  Ｄｅｓｈｐａｎｄｅ  ａｎｄ  Ｗｅｎｕｊｎ  Ｚｅｎｇ、“Ｓｃａｌａｂｌｅ  Ｓｔｒｅａｍｉｎｇ  ｏｆ  ＪＰＥＧ２０００  Ｉｍａｇｅｓ  ｕｓｉｎｇ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ”、Ｐｒｏｃ．  ＡＣＭ  Ｃｏｎｆ．  ｏｎ  Ｍｕｌｔｉｍｅｄｉａ、２００１年１０月２−４日、ｐ．３７２−３８１
【非特許文献６】
Ｗｒｉｇｈｔ，  Ｒ．Ｃｌａｒｋ，  Ｇ．Ｃｏｌｙｅｒ、“Ａｎ  ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｏｆ  ＪＰＩＰ  ｂａｓｅｄ  ｏｎ  ＨＴＴＰ”、ＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １  Ｎ２４２６、２００２年２月１４日、Ｅｌｙｓｉｕｍ  Ｌｔｄ．、英国
【非特許文献７】
Ｄ．Ｔａｕｂｍａｎ、“Ａ  Ｖｅｒｙ  Ｓｉｍｐｌｅ  Ｐｒｏｐｏｓａｌ  ｆｏｒ  ＪＰＩＰ”、ＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ１  Ｎ２４４５、２００２年３月１３日、ニュー・サウズ・ウェールズ大学、オーストラリア
【非特許文献８】
Ｒ．Ｐｒａｎｄｏｌｉｎｉ，  Ｓ．Ｈｏｕｃｈｉｎ，  Ｒ．Ｃｌａｒｋ、“Ｃａｌｌ  ｆｏｒ  ＪＰＩＰ  Ｔｅｃｈｎｏｌｏｇｙ  Ｐｒｏｐｏｓａｌｓ”、ＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １  Ｎ２５５０、２００２年３月２１日
【非特許文献９】
Ｃａｎｏｎ、“Ｐｒｏｐｏｓａｌ  ｆｏｒ  ＪＰＩＰ  Ｔｉｅｒ２  ｐｒｏｔｏｃｏｌ”、ＷＧ１Ｎ２６０８、２００２年６月２８日
【００１１】
【発明が解決しようとする課題】
本発明は、コードストリームの一部分を通信メカニズムを用いて転送する方法及び装置を提供する。
【００１２】
【課題を解決するための手段】
一実施例によれば、本発明の方法は、ネットワークを介して要求を送信し、ネットワークから要求への応答（レスポンス）の一部のようなリターンタイプとしてＪＰＥＧ２０００に準拠したコードストリームのタイルパーツを受信する。
【００１３】
【発明の実施の形態】
本発明は、以下の詳細な説明と、本発明の様々な形態についての添付図面とからより十分に理解されるであろう。しかし、以下の説明及び添付図面は、本発明を特定の実施例に限定するために用いられるべきではなく、本発明の解説と理解だけのために用いられる。
【００１４】
ＪＰＥＧ２０００画像（或いは、その他の圧縮画像）の一部分をネットワークを介して通信する方法及び装置を説明する。ＨＴＴＰに基づき、画像及びオブジェクトのアクセスを可能にする要求及び応答の通信用シンタックスを説明する。ファイルフォーマット・オブジェクトは、ボックスを指定することによりアクセスされ、コードストリーム要素は、タイルパーツ、即ち、コードストリームの本来の要素で返される。要求シンタックスを解釈し、応答を定義するプロトコルも説明される。画像通信の試みを分割するアーキテクチャが提示される。
【００１５】
〔概要〕
図１は、画像アクセスを実現するトランスポート・プロトコルの説明図である。図１では、クライアントは、サーバ（例えば、アパッチ（Ａｐａｃｈｅ）サーバ、専用画像サーバなど）へ初期要求１０６を出す。サーバは、画像１０２を獲得するため伸長することができる少なくとも一つのＪＰＥＧ２０００コードストリームを含むＪＰＥＧ２０００ファイルを格納している。システムは、リターンチャネル１０４を介して、ＪＰＥＧ２０００コードストリーム１０１の一部分（例えば、タイルパーツ）をクライアントへ配信する。このクライアントは、直前に受信したタイル１０３を正当なＪＰＥＧ２０００コードストリームとして使用し、画像のある部分を形成するためこのコードストリームを復号化することができる。クライアント側の画像は、例えば、空間領域が縮小され、品質が低下し、コンポーネントの個数が削減し、或いは、解像度が低下するなどのいく通りかの方法で、サーバ上の画像よりも小さくなる場合がある。配信は、ネットワーク（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、ワールド・ワイド・ウェブ（ＷＷＷ）など）のような通信設備を介して行われる。一実施例において、システムは、遠隔地からＪＰＥＧ２０００ファイルへアクセスするため、ある種のパラメータ及び拡張と共にＨＴＴＰ／１．１を使用する。一実施例では、これを実現するため、ＨＴＴＰ／１．１とＪＰＥＧ２０００ファイルフォーマット及びコードストリームの両方の既存の機能が以下に詳述するように使用される。別の実施例では、システムは、ＪＰＥＧ２０００ファイルへアクセスするため、例えば、ＴＣＰ／ＩＰ、ＵＤＰ、ＳＯＮＥＴのような他のプロトコルを利用する。
【００１６】
一実施例では、クライアントとサーバの間の様々な区分のためのサポートが存在する。クライアント側では、画像オブジェクトが使用され、起点サーバ側では（即ち、クライアントと起点サーバの間に中間サーバが存在し得る）、バイトレンジが使用される。一連のステージは、画像オブジェクトからバイトレンジへ進むため使用される。あるステージから次のステージへの移行は、ネットワーク経由で、ＨＴＴＰコネクションによって、若しくは、ローカルに関数呼び出しを用いて行われる。クライアントとサーバの双方のためのプロトコル及び多重レベルＡＰＩは定義される。
【００１７】
非常に多種多様なクライアントは、ここでの教示を利用する。一実施例において、表示装置の外部にメモリを具備しないクライアントは、画像オブジェクトが供給される。他の実施例では、システムの一つ以上のクライアントは、典型的なサーバよりもＪＰＥＧ２０００について詳しく理解し、望ましいコードストリームの部分を指定する。
【００１８】
或いは、ＨＴＴＰに基づいていないプロトコルを使用してもよい。しかし、ＨＴＴＰに基づいていないプロトコルは、ファイアウォール通過、プロキシ及びキャッシング技術（例えば、ワールド・ワイド・ウェブ（ＷＷＷ）で利用可能な技術）、セキュリティ、認証、並びに、文書変更時間判定技術のうちの一つ以上の機能を獲得する手法を提供する必要がある。
【００１９】
以下に説明するトランスポート技術は、任意のＪＰＥＧ２０００ファイル若しくはコードストリームで動作するが、タイルに分割されたこれらのコードストリームは、より効率的にトランスポートされる。一実施例において、ＪＰＥＧ２０００ファイルは、プロトコルを使用する前にトランスポートのため準備される。したがって、ここで説明するプロトコルは、作成されるすべての種類のＪＰＥＧ２０００ファイルに対し最適化する必要はない。これにより、要求されるシンタックス要素の個数と、クライアント及びサーバ側で要求される処理は著しく減少する。
【００２０】
〔トランスポート・アーキテクチャ〕
図２は、トランスポート・プロトコル・ソフトウェア構造の一実施例の説明図である。クライアントとサーバの間の通信は、図２に示されるように４ステージを通過するものとして考えられる。一実施例において、これらの４ステージは、伸長器又はデコンプレッサ（ステージ１）と、ビューポート−画像マッパー（ステージ２）と、画像オブジェクト・ラッパー（ステージ３）と、画像オブジェクト要求−バイトレンジ・コンバータ（ステージ４）と、を含む。
【００２１】
図２を参照すると、クライアントは、ウェブ・ブラウザのようなアプリケーション２００を含み、サーバは、ファイルシステム若しくはオンザフライ画像発生器２０５を含む。一実施例において（例えば、図３を参照）、ＪＰＥＧ２００ファイルを取り扱うすべてのＪＰＥＧ２０００機能は、サーバ上に存在し、即ち、第１ステージ２０１と、第２ステージ２０２と、第３ステージ２０３と、第４ステージ２０４とは、すべてファイルシステム２０５と同じシステム上に存在する。クライアント・アプリケーション２０１は、認識しているフォーマット（例えば、ＪＰＥＧフォーマット）で完全な画像ファイルを送信する。これは、従来のクライアントに対して有効である。なぜならば、サーバは、クライアント・アプリケーション２０１が使用可能な画像を返すことが可能であるからである（ＪＰＥＧ若しくはＰＮＧを返す）。或いは、これは、クライアント・アプリケーション２０１のメモリ若しくは計算能力が非常に制限されているとき、従来のクライアントに対して有効である。
【００２２】
図２に示された各ステージにおいて、要求タイプが一方のティアー（層）から別のティアーへ変換されるか、応答タイプが一方のティアーから別のティアーへ変換される。ここで、各ティアーは通信のタイプである。かくして、クライアント端の要求及び応答は、画像オブジェクトであると考えられる。一実施例において、画像オブジェクトは、画面の領域、又は、一枚の紙であり、そこに、これらの領域を埋める画像と圧縮されていないカラー変換ビットを配置することが望ましい。ファイルシステム側では、通信は、バイトレンジの形で行われる。一実施例では、バイトレンジ通信は、Ｃ言語プログラムが使用するｆｓｅｅｋ（）呼び出し及びｆｒｅａｄ（）呼び出しのシーケンスにより構成される。別の実施例では、バイトレンジ通信は、不必要なデータが捨てられたｆｒｅａｄ（）呼び出しだけにより構成される。尚、本発明の教示はＣプログラミングには限定されず、その他のプログラミング言語若しくはシステム（並びに、関連した呼び出し）も使用される。例えば、ワシントン州レッドウッドのＭｉｃｒｏｓｏｆｔ  Ｃｏｍｐｕｔｅｒは、異なる呼び出しの組を使用する製品をもっている。別の方式でバイトレンジ通信を実行するため、カリフォルニア州マウンテンビューのＳｕｎ  ＭｉｃｒｏｓｙｓｔｅｍｓのＪａｖａ（登録商標）を使用することも可能である。また、ファイルは、メモリに取り込み、メモリアクセスを使用してもよい。
【００２３】
一実施例において、クライアントとサーバの間の区分は、図２に点線で示されている５箇所のいずれの箇所でも行うことができる。一実施例において、クライアントは、サーバとの通信が圧縮形式で行えるように第１ステージの処理を含む。クライアント（例えば、ウェブ・ブラウザ）は、ライブラリを用いてＪＰＥＧ２０００伸長を実行する。一実施例において、クライアントとサーバが特定の点線で区分されているとき、その点線を超える通信はＨＴＴＰを用いて行われる。このような場合、一実施例では、クライアント若しくはサーバが点線の両側を含んでいるならば、通信は関数呼び出しによる。
【００２４】
より詳細に説明すると、図２において、Ｔ１はバイトレンジ・アクセスを表し、Ｔ２はＪＰＥＧ２０００画像オブジェクト・アクセスを表し、Ｔ３はビューポート／完全画像アクセスを表す。クライアントとサーバの間の区分が第２ステージと第３ステージの間にあるとき、クライアントは、ＪＰＥＧ２０００画像オブジェクトのｈｔｔｐ要求を行う。プロトコルの区分が第４ステージとファイルシステム２０５の間で行われるとき、クライアントは、すべてのＪＰＥＧ２０００の知識をもっている。
【００２５】
図３は、クライアントとサーバの間の区分がクライアント・アプリケーション２００と伸長器（第１ステージ）との間で行われる第３ティアー通信の説明図である。このコンフィギュレーションには多数の潜在的な用途が存在する。例えば、これは、キャッシュを具備せず、ＤＣＴベースのＪＰＥＧデコーダだけを具備しているクライアントに使用できる。この区分は、ローカル・サーバに接続されたアプリケーション用のＡＰＩ、又は、既存のブラウザへの下位互換性が要求される状況用のＡＰＩにも使用される。
【００２６】
図４は、クライアントとサーバの間の区分が第１ステージと第２ステージの間で行われる第３ティアー要求及び第２ティアー応答の説明図である。このコンフィギュレーションの潜在的な用途には、簡単な要求及び効率的なトランスポートと、パンとズームのクライアントと、ＪＰＥＧ２０００がプラグインされたブラウザ若しくは始めからＪＰＥＧ２０００をサポートするブラウザと、が含まれる。
【００２７】
図５は、クライアント２０１とサーバ２０２の間の区分が第２ステージと第３ステージの間で行われる第２ティアー要求及び第２ティアー応答の説明図である。このようなシステムは、クライアントがサーバよりもユーザのニーズを知っている場合に潜在的な用途がある。
【００２８】
図６は、クライアントとサーバの間の区分が第４ステージとファイルシステム２０５の間で行われる第１ティアー要求と第１ティアー応答の説明図である。これは、サーバがＪＰＩＰを認識しない場合に使用できる。
【００２９】
図７は、プロキシ・サーバが使用される状況の説明図である。図７を参照するに、第１ステージと第２ステージの間、並びに、第４ステージとファイルシステム２０５の間に区分が存在する。より詳しく説明すると、プロキシ・サーバ７０３は、第２ステージから第４ステージまでを担当する。一実施例において、ファイルシステム２０５は、Ａｐａｃｈｅサーバである。本実施例では、従来型のサーバ（例えば、バイトレンジ要求をサポートするＡｐａｃｈｅサーバなど）が使用され、ＪＰＥＧ２０００クライアントのパン／ズームは、これまでに良く知られた形式でサポートされ、中間プロキシ・サーバが使用される。同図には、１台のプロキシ・サーバしか示されていないが、クライアントとサーバの間には、１段以上のステージを取り扱う２台以上のサーバを設けてもよい。或いは、プロキシ・サーバ７０３によって扱われるステージは、ステージ２からステージ４までよりも多くても少なくても構わない。
【００３０】
このアーキテクチャの場合、クライアントとサーバの相互作用は１回に限られない。例えば、クライアント・アプリケーションは、完全画像オブジェクトだけと通信するコードを含む。画像を表示するため、クライアント・アプリケーションは、ローカル・サーバと通信する。このローカル・サーバは、高帯域幅接続によって接続してもよい。これに対して、サーバは、第３ティアー要求を使用して低帯域幅接続を介して別のサーバと通信し、第２ティアー応答を受信する。この２番目のサーバは、画像の「発生元」サーバでもよく、或いは、高帯域通信を介して、バイトレンジ要求だけを認識する「ダム」サーバと通信してもよい。これらの各サーバは、キャッシュを保持することができる。
【００３１】
クライアント若しくはサーバ内の構成要素は、図示されるようなステージに分割することが可能であるが、必ずしもこのように分割しなくてもよい。サーバは、例えば、第２ステージから第４ステージまでの多数のステージを一括して取り扱う単一のコード本体部を収容してもよい。これにより、メインヘッダのようなある種の画像情報を様々なステージにおいて重複することなく１回だけ記憶することが可能になる。
【００３２】
〔第１ステージ：伸長器（デコンプレッサー）〕
一実施例において、伸長器ステージは、第２ティアー応答のシーケンス及び現在の「ビューポート」を画像データに変換する。ビューポートは、クライアントが着目している全画像のうちの一部分である。ビューポートは、屡々、コンポーネントの部分集合、低解像度、或いは、小さい空間領域である。本質的に、伸長器ステージは、受信データに対して「普通」のＪＰＥＧ２０００伸長器を動かし、クライアントが希望する領域を復号化する。一実施例において、伸長器は、完全（フル）解像度の全画像を生成するためデコーダを動かし、着目している領域までクロッピングし、着目している解像度まで拡大縮小すことによって実現される。一実施例では、望ましい解像度、領域、コンポーネント、及び、品質に必要なファイルの部分だけが復号化される。これにより、計算資源とメモリが節約される。代替的な実施例では、システムは、既に望ましいコンポーネント数及び望ましい解像度で画像全体を復号化している。
【００３３】
一実施例において、伸長器は、Ｋａｋａｄｕ式ＪＰＥＧ２０００でデコーダを使用する。ｋｄｕ＿ｅｘｐａｎｄプログラムは、低解像度の復号化と、着目している領域の復号化と、コンポーネント数の削減とを可能にさせる。ウィンドウ問い合わせとデコーダのコマンドラインとの間には、ディレクション関係が存在する。
【００３４】
一実施例では、伸長器は、実際にｋｄｕ＿ｅｘｐａｎｄプログラムをスタートさせるのではなく、等価的な機能が動的リンクライブラリ（ＤＬＬ）に集められる。一実施例では、伸長器は、受信ＪＰＥＧ２０００コードストリームと、画面に表示される復号化画像のための外部ファイルを使用する。これにより、クライアントが終了させられたとき、簡単にキャッシングが行える。一実施例では、復号化画像用の外部ファイルを使用するのではなく、画像をメモリに収容するため、ＪＰＥＧ２０００ライブラリが呼び出される。これにより、応答速度を速めることが可能である。
【００３５】
その他のＪＰＥＧ２０００ライブラリをＫａｋａｄｕの代わりに使用してもよい。例えば、要求された領域を最近接のタイル境界へ拡張し、全タイルを復号化するライブラリを使用してもよい。クライアントは、タイル境界と交差することなくパンニングする際に、このライブラリを使用して、画像の表示速度を速めることが可能である。このライブラリを用いて復号化された画像は、ユーザに要求されたビューだけを見せるためにクロッピングされるが、ビューポートを僅かに変更することにより、既に復号化された画像の簡単な再クロッピングと表示が行われる。同様に、ユーザの領域要求が新しいタイルからの素材に含まれるとき、これらのタイルだけを復号化し、それらをメモリ内の再構成画像に追加することが可能である。この場合、完全なクライアントのビュー上でＪＰＥＧ２０００デコーダを動かすことは、新しい符号化データが受信されたときに、表示される画像の品質を向上させる場合に限り必要である。
【００３６】
〔第２ステージ：Ｊ２Ｋマッパーへのビューポート〕
このビューポート−ＪＰＥＧ２０００マッパーのステージは、ビューポート要求をタイルパーツに変換するため、ＪＰＥＧ２０００ファイルに関する情報を使用する。一実施例において、このステージは、未だヘッダ情報を取得していない場合には、そのヘッダ情報を要求する。一実施例では、このステージは画像ヘッダ情報のコピーを保持するので、未来のビューポートは、ＪＰＥＧ２０００タイルパーツに直ぐに変換することが可能である。このステージは、既に第１ステージへ転送された画像オブジェクトの要求の繰り返しを避けるため、第１ステージへ転送された応答のリストを保持する。
【００３７】
タイルパーツによる通信のため、ビューポイントのタイルパーツの組へのマッピングが行われる。マッパーは、画像の望ましい領域を、ＪＰＥＧ  ２０００  Ｐａｒｔ  １  ｓｔａｎｄａｒｄ  （ＩＴＵ−Ｔ  Ｒｅｃ．  ｜８００  ＩＳＯ／ＩＥＣ  １５４４４−１：２００２−ＪＰＥＧ  ２０００  Ｉｍａｇｉｎｇ  Ｃｏｄｉｎｇ  Ｓｔａｎｄａｒｄ）に規定されている「基準グリッド単位（ｒｅｆｅｒｅｎｃｅ  ｇｒｉｄ  ｕｎｉｔｓ）」へ変換する。マッパーは、どのタイルパーツが着目している領域と交差しているかを判定するため、ＳＩＺマーカー・セグメントのＸＴｓｉｚ、ＹＴｓｉｚ、ＸＴＯｓｉｚ、ＹＴＯｓｉｚ、ＸＯｓｉｚ、及び、ＹＯｓｉｚ部分を使用する。第３ティアー要求シンタックスから獲得された解像度、品質及び領域は、必要なタイルパーツを決定するため使用される。一実施例において、マッパーは、タイルパーツの場所を指定するＳＩＺマーカーによって指定された場合に、（問い合わせ文字列によって指定されるような）着目している領域と交差するタイルパーツだけに注目する。
【００３８】
より詳細に説明すると、タイルパーツを用いた通信のため、ビューポイントがタイルパーツの組（集合）へマッピングされる。画像の部分（解像度、空間領域、品質及びコンポーネント）は、クライアント要求に、明示的に、若しくは、デフォルト値を用いて与えられる。マッパーは、画像の望ましい領域を、ＪＰＥＧ  ２０００  Ｐａｒｔ  １  ｓｔａｎｄａｒｄ  （ＩＴＵ−Ｔ  Ｒｅｃ．  ｜８００  ＩＳＯ／ＩＥＣ  １５４４４−１：２００２−ＪＰＥＧ  ２０００  Ｉｍａｇｉｎｇ  Ｃｏｄｉｎｇ  Ｓｔａｎｄａｒｄ）に規定されている基準グリッド単位へ変換する。各タイルパーツの基準グリッド単位は、ＪＰＥＧ２０００コードストリーム内のＳＩＺマーカー・セグメントのＸＴｓｉｚパラメータ、ＹＴｓｉｚパラメータ、ＸＴＯｓｉｚパラメータ、及び、ＹＴＯｓｉｚパラメータによって決定される。要求された領域と交差するタイルからのタイルパーツだけが送信される。タイルの中のどのタイルパーツを送信すべきであるかは、要求された解像度及び品質と、符号化データのタイルパーツへの編成の仕方と、に依存する。簡単な一実施例では、低解像度から高解像度までの解像度毎に一つのタイルパーツが使用される。この場合、配信されるタイルパーツの個数は、要求された解像度だけに依存する。
【００３９】
図９は、ビューポート問い合わせパラメータと、ＳＩＺマーカー・セグメント・パラメータとの間の対応関係の説明図である。図９を参照するに、ＸＴＯｓｉｚ、ＹＴＯｓｉｚ、ＸＯｓｉｚ、ＸＴｓｉｚ、ＹＴｓｉｚ、Ｘｓｉｚ、及び、Ｙｓｉｚはすべて、ＳＩＺマーカー・セグメントから得られ、ｘｏ、ｙｏ、ｗ及びｈは、ビューポート要求パラメータである。二つのパラメータ集合の間の対応関係は次のようになる。Ｘｓｉｚ−ＸＯｓｉｚが、問い合わせパラメータ空間内の水平方向で１．０に対応する基準グリッドサンプルの個数を表し、ｗ及びｘｏは、（Ｘｓｉｚ−ＸＯｓｉｚ）で乗算することによって基準グリッド単位へ変換される。同様に、垂直方向に関して、ｈ及びｙｏは、Ｙｓｉｚ−ＹＯｓｉｚを乗算することによって基準グリッド単位へ変換される。
【００４０】
一実施例において、各タイルパーツに関する情報は構造に記憶される。この構造は、第２ステージ用のメモリでもよい。この構造は２ビットの構造であり、一方のビットは、タイルパーツが現在要求に対するクライアントへ送信されるべきであるかどうかを指定し、他方のビットは、タイルパーツが送信され終えたかどうかを指定する。このように、タイルパーツ毎に２ビットが存在する。タイルパーツがキャッシュに存在する場合、２番目のビットがターンオンされ、タイルパーツは送信しなくてもよい旨が示される。タイルパーツがキャッシュに存在しない場合、１番目のビットによって示されるような必要に応じて、タイルパーツがクライアントへ送信され、再送信を防止するため２番目のビットがターンオンされる。或いは、この構造は、送信してもよいかどうかを示す１ビットだけを使用するのではなく、各タイルパーツの優先順位を表す情報を記憶するために拡張できる。
【００４１】
コードストリームから、ＳＯＴマーカーは、タイル索引の細部と、各タイルパーツに必要なバイト数と、を与える。一実施例では、コードストリームから、送信されるべきタイルパーツに対応した適切なバイトがクライアント側へ送信される。ビューポートが変化し、対応した関連するタイルが変化した場合、先に送信されていないタイルだけが表示画像を更新するために送信される。
【００４２】
〔第３ステージ：画像オブジェクト・ラッパー〕
第３ステージは、バイトレンジ応答を取得し、画像オブジェクトを作成する。一実施例において、画像オブジェクト・ラッパーは、画像オブジェクト要求のシーケンスを一時記憶する。その結果として、第４ステージからの応答、例えば、
ＨＴＴＰ／１．１  ２００  ＯＫ
［ｏｔｈｅｒ  ｈｅａｄｅｒ  ｌｉｎｅ］
Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ：２００−５００／２３３８２
ＣＲＬＦ
Ｄａｔａ
のような応答は、画像オブジェクト表現の応答に変換される。完全タイルパーツだけが返される場合、このステージは、ＨＴＴＰ応答から”Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ”行を削除するだけである。一実施例では、このステージは、異なるヘッダでデータを包む（ラップする）。
【００４３】
一実施例において、第３ステージ及び第４ステージは完全に統合される。この結合されたステージは、望ましいデータを取得し、返却されたデータをＨＴＴＰ応答に包みこみ、第２ステージへ供給するため、ｆｓｅｅｋ（）呼び出しとｆｒｅａｄ（）呼び出しを実行するであろう。
【００４４】
一実施例において、トランスポート・プロトコルは、タイルパーツ及びボックスとは異なり、セルフラベリングされないオブジェクトをサポートするように拡張される。この場合、画像オブジェクト・ラッパーは、返却されたデータを識別子で包み込む。一実施例では、このラッピングは、次の形式：
Ｐａｃｋｅｔ：＝０＆ｌａｙｅｒ＝０＆ｃｏｍｐｏｎｅｎｔ＝２＆ｐｏｓｉｔｉｏｎ＝５＆ｔｉｌｅ＝７
のＨＴＴＰヘッダでもよい。この新しいヘッダは、符号化データよりも先行するメッセージ本体内のバイトのシーケンスでもよい。
【００４５】
〔第４ステージ：Ｊ２Ｋ−バイトレンジ・コンバータ〕
Ｊ２Ｋからバイトレンジへのコンバータ（第４ステージ）は、圧縮画像オブジェクト要求をバイトレンジ要求に変換する役割を担う。一実施例では、このために、メインヘッダ、様々なコードストリーム・ボックスの場所、及び、タイルパーツを獲得するため、幾つかのバイトレンジ要求を作成することが必要である。殆どの場合、このコンバータは、多重アクセスを防止するため、情報を一時記憶する。コンバータは、たとえ、ＪＰＥＧ２０００ファイル内でのタイルパーツのバイトレンジを参照する要求の場所を決定するために多重読み出しが必要であるとしても、要求された画像オブジェクトだけを返す。
【００４６】
一実施例では、ヘッダを送信する前に、サーバは、ＪＰＥＧ２０００コードストリームのヘッダに達するまで、ＪＰＥＧ２０００ファイルの構文を解析する。このとき、サーバは、コードストリーム・ヘッダ、或いは、構文解析されたファイルを、コンバータへ送信する。このようにして、コンバータは、０ｘ６Ａ７０３２６３によって示されるコードストリーム・ボックス・ヘッダの開始よりも前のすべてのデータを無視する。コードストリーム内のすべてのタイルパーツは、ＳＯＴマーカー・セグメントから始まる。ＳＯＴマーカー・セグメントは、タイルパーツの長さを含む。コンバータは、タイルパーツの長さを得るため、ＳＯＴマーカーを読み、タイルパーツの長さ、及び、タイルパーツの場所をＪＰＥＧ２０００ファイルに保存し、コンバータは、次のＳＯＴマーカーへ進む。したがって、ビューポイント−Ｊ２Ｋマッパーがタイルパーツの組を要求する旨を示した後、コンバータは、作成されたメモリ構造から、タイルパーツの対応したファイル場所を獲得する。即ち、コンバータは、ファイルを構文解析すると共に、タイルパーツをメモリに記憶し、タイルパーツをクライアントへ送信する。コードストリームのメインヘッダ内のＴＬＭマーカーは、タイルパーツの場所及び長さを格納する。したがって、一実施例では、ＴＬＭマーカーは、ＪＰＥＧ２０００ファイル内のタイルパーツの位置を決定するため使用される。
【００４７】
換言すると、バイトレンジ要求は、ＪＰＥＧ２０００コードストリームのメインヘッダ内のＴＬＭマーカー・セグメントを使用して、或いは、各ＴＬＴマーカーを読み出すこと（及び、次のＴＬＴマーカー・セグメントへ進むこと）によって作成される。いずれの場合も、第４ステージは、タイル索引と、タイルパーツの個数と、ファイルの先頭からのオフセットと、タイルパーツの長さ、の４個のエントリーを含むリストを構築することが可能である。タイル索引、タイルパーツの個数、及び、長さは、すべて、ＴＬＴマーカー・セグメントの一部である。第４ステージが各ＴＬＴマーカー・セグメントを読み出すとき、第４ステージはファイルの先頭からのオフセットを保存することが可能である。次に、特定のタイル索引及び部分番号に対する要求が生成されるとき、第４ステージは、生成されたリスト内のタイルパーツを見つける。オフセット及び長さのリスト内のエントリーは、バイトレンジ要求のため使用される。
【００４８】
構文解析中に、コンバータは、ＪＰＥＧ２０００コードストリームの前にすべてのバイトを読む。スピードアップは、「ボックス」ヘッダを読み出すことにより、即ち、「ボックス」タイプ及び「ボックス」長さを読み出し、関連していないボックスを飛ばすことにより、達成される。
【００４９】
一実施例において、コンバータは、ファイルシステムに接続され、ファイルを読むためにシステムコールを行う。コンバータは、ＪＰＩＰをサポートしていないがバイトレンジ要求をサポートしているサーバ（例えば、Ａｐａｃｈｅサーバ）に接続される。或いは、このステージは、ＪＰＥＧ２０００画像を蓄積する役割を担うデータベースに接続してもよい。
【００５０】
〔第３ティアーはＪＰＥＧファイル又はＰＮＧファイルを返す〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、第３ティアー応答は、ビューポートを埋めるために適したＰＮＧファイル若しくはＪＰＥＧファイルである。
【００５１】
〔第２ティアーはボックス及びタイルパーツを返す〕
第２ティアーは、更なるラッピングを行うことなく、ボックス及びタイルパーツを返すので、要求に対する応答は、有効なＪＰＥＧ２０００ファイル若しくはコードストリームを形成するために連結され得る。これは、典型的に、第１ステージを実行するクライアント若しくはコンピュータシステム、又は、装置によって行われる。クライアントは、ＰＩＰ若しくはトランスポートを理解できないＪＰＥＧ２０００デコーダを利用することが可能である。ブラウザ用のローカル・ディスク・キャッシュは、他のディレクトリへコピーすることができる有効な画像で埋められ、有効な画像は他のディレクトリへコピーされない場合には、ＪＰＥＧ２０００ファイルとして操作される。
【００５２】
一実施例において、トランスポート・プロトコルは、信頼性の高い順序付けされたチャネルを前提とするＨＴＴＰを使用する。これにより、クライアント若しくはステージは、ある程度のエラー検出を行わなくても済むようになる。
【００５３】
〔トランスポート・プロトコル定義〕
〔要求シンタックス〕
要求は、第３ティアー「全体の画像オブジェクト」、第２ティアー「符号化されたデータオブジェクトレベル」、及び、第１ティアー「バイトレンジ」の３種類のティアーで行われ得る。しかし、一実施例では、すべての要求は、ＨＴＴＰシンタックスを使用し、一部のオーバーラップが生ずる。例えば、画像以外のデータ、例えば、ＪＰＥＧ２０００におけるボックスに対する要求は、画像及びオブジェクトレベルで同一である。更に、クライアントは、画像レベルで殆どのデータへアクセスすることを望むかもしれないが、メタデータの一部分、例えば、画像に関連付けられた音（サウンド）は、（特に、他のチャネルの使用と干渉するかもしれない程度に大きいならば）バイトレンジでアクセスされる。例えば、約２０００バイト以上のメタデータが必要ではないときには、要求を作成するオーバーヘッドは補われる。ある種のデータにバイトレンジでアクセスすると、サーバが理解できないメタデータを含むＪＰＥＧ２０００ファイルは、ボックス全体よりも小さい単位でアクセスできるようになる。
【００５４】
〔第３ティアー要求〕
一実施例において、第３ティアーの要求は、
ＧＥＴ  ｆｉｌｎｅｎａｍｅ．ｊｐ２？ｒｅｓ＝２  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
のように表される。
【００５５】
これらはすべて、標準ＨＴＴＰ要求のコンポーネントである。”ＧＥＴ”はメソッドである。”ｆｉｌｅｎａｍｅ．ｊｐ２”は、ファイル名、若しくは、より一般的には完全なＵＲＬであり、サーバのルート・ディレクトリからの完全なパスでもよい。”？”の後のすべての項目は、ＣＧＩ相互作用に典型的な「名前＝値」のペアである。この問い合わせ文字列は、スペースを含まない（それらは、％２０として組み込むことが可能である。）。ＨＴＴＰ  ｒｆｃ、例えば、Ｆｉｅｌｄｉｎｇ，  Ｇｅｔｔｙｓ，  Ｍｏｇｕｌ，  Ｆｒｙｓｔｙｋ，  Ｍａｓｉｎｔｅｒ，  Ｌｅａｃｈ，  Ｂｅｒｎｅｒｓ−Ｌｅｅ  （編）、”Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ＿  ＨＴＴＰ／１．１”、ＲＦＣ  ２６１６、１９９９年６月を参照せよ。この文献は、以下の説明では、ＨＴＴＰ標準と呼ぶ。最終的なＨＴＴＰ／１．１は、プロトコルを規定する。プロトコルの一部は、バージョン１．１よりも前のバージョンのＨＴＴＰと連動する。ＨＴＴＰ要求は、２個のキャリッジリターンとラインフィードのペアによって終了する。”ＣＲＬＦ”は、キャリッジリターンとラインフィードを表現するが、本例の場合、その文字は、行内の唯一の文字ではない限り、各行の終わりで省略されている。
【００５６】
一実施例では、ＨＴＴＰ  ＧＥＴ要求の問い合わせ文字列にパラメータを組み込む代わりに、パラメータは、ＨＴＴＰ  ＰＯＳＴ要求の本体部に組み込まれる。これは、後述のオプションが長い場合に有効である。
【００５７】
一実施例において、ＰＯＳＴ要求の一例は、
ＰＯＳＴ  ／ｃｇｉ−ｂｉｎ／ｊ２ｋ＿ｓｅｒｖｅｒ．ｃｇｉ  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  Ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：  ２６
ＣＲＬＦ
ｆｉｌｅｎａｍｅ＝ｐｉｃｔｕｒｅ．ｊｐ２＆ｒｅｓ＝２
である。
【００５８】
第３ティアーのビューポートを記述するために利用可能なオプションは次の表１に掲載されている。要求に影響を与える補助パラメータは表２に掲載されている。これらのオプションは、ｇｅｔメソッドとｐｏｓｔメソッドに対して同一である。
【００５９】
【表１】
2004208266.tif 000003
尚、これらのパラメータのすべてが必要というわけではない。一部のパラメータは、デフォルト値を取り、例えば、デフォルトですべてのコンポーネントは、画像にマッチする領域に関して送信される。一実施例では、それらをすべて省略してもよく、デフォルト値が使用される。
【００６０】
〔パラメータの説明〕
パラメータｘｏ、ｙｏ、ｗ及びｈは、画像の領域を指定する。０は左上の端を表し、１は右下を表す。幅及び高さは画像の画分を指定し、１は全高若しくは全幅を表す。かくして、一実施例において、ｘｏ＝０＆ｙｏ＝０＆ｗ＝１＆ｈ＝１は、画像の全体（デフォルト）を指定する。これに対して、画像の中央セクションは、ｘｏ＝０．２５＆ｙｏ＝０．２５＆ｗ＝０．５＆ｈ＝０．５によって与えられる。左端は、基準グリッド上のＸＯｓｉｚの位置に存在し、上端は、ＹＯｓｉｚの位置に存在するものとする。図９と、パート１の付録ＡにおけるＳＩＺマーカーの定義［ＩＴＵ−Ｔ  Ｒｅｃ．  Ｔ．８００｜ＩＳ  １５４４４−１：２０００、Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  ＿  ＪＰＥＧ  ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ：  Ｃｏｒｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ］を参照のこと。
【００６１】
パラメータｒｅｓは、画像を縮小するための解像度の数である。ｒｅｓ＝１は、画像を水平方向並びに垂直方向に約２倍の倍率で縮小する。この縮小は、ＪＰＥＧ２０００の様式で行われるので、画像７のグリッド点の幅は、ＳＩＺマーカーのオフセットの値に依存して、４サンプル若しくは３サンプルの幅に縮小される。
【００６２】
パラメータｍａｘｗ及びｍａｘｈは、クライアントが受信することに関心をもっているサンプルの最大個数を指定する。これは、「ｒｅｓ＝」パラメータを使用して縮小の量を指定することの代わりである。例えば、原画像のサイズを知らないクライアントは、１２８サンプルを含む最大高若しくは最大幅の画像を要求する。サーバは解像度を低下させる。サーバは、要求が満たされるまで、或いは、ＬＬサブバンドだけが返されるまで、解像度を低下させる。かくして、ウェーブレット変換の零レベルが圧縮の際に利用されているならば、１２８×１２８の最大画像の要求は５１２×５１２の画像を返し続ける可能性がある（しかし、起こりそうにない。）。
【００６３】
コンポーネント・パラメータは、どのコンポーネントを組み込むかを指定する文字列である。一実施例において、コンポーネントは、零から番号が付けられる。レンジを使用してもよい。かくして、コンポーネント＝０−２、５は、例えば、コンポーネント０、１、２及び５を返す。
【００６４】
品質パラメータは、サーバが送信すべきデータの量を決定するために役立つ。サーバは、返却するレイヤの数として、品質値を使用することを選んでもよい。一実施例において、品質に関する０ｘＦＦＦＦの要求は、領域内のタイルパーツについてサーバが保有するすべてのデータを要求することである。
【００６５】
表２には、応答の他の面を制御するため、問い合わせと共に使用される補助的なパラメータの組が掲載されている。第３ティアー値は、”ｐｎｇ”若しくはＤＣＴベースのＪＰＥＧフォーマットの完全な画像として応答を要求する。
【００６６】
【表２】
2004208266.tif 000004
ボックスパラメータは、クライアントが着目しているボックスのリストを指定するための一方法である。ボックスは、ＪＰＥＧ２０００パート１、パート２、パート３及びパート６において様々のＪＰＥＧ２０００ファイルフォーマットに対して規定されている。これらは、コードストリームの一番上のレベルにある。ボックスの内部のボックスは、スーパーボックス及びサブボックスをリストにすることによって要求される。複数のボックスの場合、サーバは、そのタイプのすべてのボックスを返却するか、若しくは、そのタイプの最初のボックスだけを返却するかを選択する。ボックスのレンジは、括弧を用いて指定される。［０−］という形式のレンジは、サーバがこのタイプのすべてのボックスを返却することを保証する。
【００６７】
最大ボックスサイズパラメータは、指定されたバイト数に満たないすべてのボックスを返却させることができる。これにより、通信が非常に遅くならない限り、存在するであろうすべてのボックスを獲得できるようになる。
【００６８】
尚、許容可能なセットの範囲外の文字を使用するタイプのボックスは、ＵＲＬ符号化される。ＵＲＬ符号化に関する更なる情報は、ＲＦＣ  ２３９６のＨＴＴＰ  ｒｆｃ［ＨＴＴＰ標準］を参照せよ。
【００６９】
ボックスもノットボックスもリストに掲載されていない場合、サーバは、返却すべきボックスを決定する。一実施例では、サーバは、すべてのボックスを返却すること、コードストリームより前のすべてのボックスを返却すること、画像をサーバに蓄積するときに画像の作成者が指定したすべてのボックスを返却すること、或いは、全くボックスを返却しないこと、を決定する。一実施例では、サーバのコンフィギュレーション・ファイルは、これらのオプションの任意の部分若しくは全部を許可する。コードストリームの一部分は、Ｎｏｔｂｏｘｅｓ＝ｊｐ２ｃではない限り返却される。
【００７０】
要求パラメータ、値のペア、及び、それらの意味の例は以下の通りである。
ｂｏｘｅｓ＝ｊｐ２ｈ
ｇｅｔ  ｔｈｅ  ＪＰ２  Ｈｅａｓｅｒ  ｂｏｘ．
ｂｏｘｅｓ＝ｊｐ２ｈ／ｉｈｄｒ
ｇｅｔ  ｏｎｌｙ  ｔｈｅ  Ｉｍａｇｅ  Ｈｅａｄｅｒ  ｂｏｘ  ｗｉｔｈｉｎ  ｔｈｅ  ＪＰ２  Ｈｅａｄｅｒ  ｂｏｘ
ｂｏｘｅｓ＝ｕｕｉｄ［５−７］
ｇｅｔ  ｔｈｅ  ５ｔｈ  ６ｔｈ，  ａｎｄ  ７ｔｈ  ＵＵＩＤ  ｂｏｘｅｓ  （ｉｆ  ｔｈｅｙ  ｅｘｉｓｔｓ）．
ｍａｘｂｏｘｓｉｚｅ＝４０９６
ｒｅｔｕｒｎ  ｂｏｘｅｓ  ４０９６  ｂｙｔｅｓ  ｏｒ  ｓｍａｌｌｅｒ
【００７１】
優先順位パラメータは、ある要求の他の要求に対する重要度を示す。新しい優先順位が前の優先順位と一致する場合、サーバは、新しい要求に関しても有効であるならば、旧い要求に関するバイトを送信し続ける。新優先順位と旧優先順位の差が１以上であるならば、サーバは、次の機会に旧い要求を停止し、新しい要求を開始する。優先順位が”Ｉｎｆ”である場合、サーバは新しい要求のために旧い要求を止める。サーバは、現在の要求に適用されるデータを送信し終えたとき、以前に中断された要求に関するデータを後で送信するように選択してもよい。
【００７２】
〔第３ティアーのための補助的なＨＴＴＰヘッダライン〕
次の表３には、クライアント側で利用可能なデータを指定するため使用可能な二つのヘッダラインが示されている。
【００７３】
【表３】
2004208266.tif 000005
Ｔ３キャッシュ（Ｔ３ｃａｃｈｅ）は、クライアントが現在のセッション又は前のセッションで既に受信した領域を指定できるようにする。サーバは、要求に対して送信されたタイルパーツが再度送信されることがないようにタイルパーツを計算するため、このＴ３キャッシュを使用する。サーバはこのパラメータを無視してもよい。例えば、認識する能力に欠けるサーバは、このパラメータを無視するであろう。
例：
Ｔ３ｃｈａｃｈｅ：  ｘｏ＝０．０＆ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２
Ｔ３ｃｈａｃｈｅ：  ｍａｘｗ＝１２８＆ｍａｘｈ＝１２８
【００７４】
尚、キャッシュの内容は、先行のビューポート要求への応答である。一実施例では、一つのＴ３キャッシュライン当たりに一つの要求が存在する。この要求は、問い合わせ文字列の一部としては送信されないが、ＨＴＴＰヘッダラインとして送信される。Ｔ３キャッシュが使用されているならば、メインヘッダは受信されている、と考えられる。クライアントは、キャッシュされたすべての要求のリストを作成しなければならないわけではない。実際上、クライアントは、受信された各要求をリストに掲載し、このラインをアクノリッジとして使用する。サーバは、前の要求をタイルパーツのリストに翻訳し、これらのタイルを送信済みとしてマークすることができる。したがって、これらのタイルパーツは、現在の要求が翻訳されるときに、再送信されない。
【００７５】
Ｔ２キャッシュは、クライアントが受信されたタイルパーツのリストを作成できるようにする。シンタックスは次のように定義される。これは、タイルパーツを要求する典型的な方法に対応する。ここでも一実施例では、このラインは、問い合わせ文字列の一部分ではなく、ＨＴＴＰヘッダラインである。一例は、次の通りである。
Ｔ２ｃａｃｈｅ：  ４．０，  ４．１，  ５．０−６．２
【００７６】
〔第２ティアー要求〕
第２ティアーは、第３ティアーと同じようにボックスに対する要求をサポートする。タイルパーツは、ＨＴＴＰレンジヘッダを用いて明示的に要求され得る。タイルパーツに対する第２ティアー要求の効率的な用法は、符号化データのタイルパーツへのある分割に同意したクライアントとサーバに依存する。タイルは、あらゆる解像度若しくはあらゆるレイヤで、或いは、その他の方法でタイルパーツに分割しなければならない。一つの有効な分割法を次に詳しく説明する。第２ティアーの要求の例は、次の通りである。
ＧＥＴ  ｆｉｌｅ．ｊｐ２  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
Ｒａｎｇｅ：  ｔｉｌｅｓ−ｐａｒｔｓ＝４．０，  ５．０，  ８．０−９．２
ＣＲＬＦ
【００７７】
ピリオドの前の値はタイル番号であり、ピリオドの後の値はタイルパーツ番号である。ＪＰＥＧ２０００パート１の付録ＡからのＩｓｏｔ及びＴＰｓｏｔを参照のこと（文献：ＩＴＵ−Ｔ  Ｒｅｃ．  Ｔ．８００｜ＩＳ  １５４４４−１：２０００，  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  ＿  ＪＰＥＧ  ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ：  Ｃｏｒｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ）。尚、一実施例では、タイル番号及びタイルパーツ番号は、どちらも０から番号を付けられる。タイルパーツのレンジは、スタートタイルからストップタイルまでのすべてのタイルと、スタートからストップまでのこれらのタイルに関するすべての部分と、を含む。例えば、８．０−９．２は、８．０、８．１、８．２、９．０、９．１、９．２と等価的である。
【００７８】
一実施例では、タイルパーツは２個のパラメータ（タイルに対するＩｓｏｔと部分に対するＴＰｓｏｔ）をもつので、１次元のレンジのため設計された”Ｒａｎｇｅｓ”の代わりに、新しいＨＴＴＰヘッダラインを使用する方がよい。例えば、”Ｔｉｌｅ−ｐａｒｔ：”ヘッダは、
Ｔｉｌｅ−ｐａｒｔｓ：  ８．０，  ．８．１，  １０．０−１２．２
のように使用される。
【００７９】
〔第１ティアー要求シンタックス〕
第１ティアーの要求は、ＨＴＴＰ（ＨＴＴＰ標準）に規定されているように厳格なバイトレンジ要求である。例えば、
ＧＥＴ  ｆｉｌｅ  ．ｊｐ２  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｈｏ．ｃｏｍ
Ｒａｎｇｅ：  ｂｙｔｅｓ＝２００−５００，  １０００−１５００
ＣＲＬＦ
である。
【００８０】
上述の通り、要求は、位置２００で始まる３００バイトと、位置１０００で始める５００バイトである。このような要求は、典型的に、クライアントが所定のバイトレンジで期待すべきものを知っている場合に限り有効である。しかし、これらの要求は、例えば、画像に関連付けられたオーディオ・ストリームの全体を転送することなく、オーディオ・ストリームの一部分にアクセスするために有効である。
【００８１】
一実施例では、別々のラインでキャッシュ情報のリストを作成するのではなく、クライアントは、キャッシュ情報をＨＴＴＰ問い合わせ文字列自体に組み入れることが可能である。例えば、ユーザが、以下の問い合わせ文字列：
ＧＥＴ  ｆｉｌｅｎａｍｅ．ｊｐ２？ｘｏ＝０．０＆Ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２＆ｍａｘｘ＝７５０＆ｍａｘｙ＝７５０  ＨＴＴＰ／１．１
を入力する場合を考える。
【００８２】
クライアントは、第２ステージ（ビューポート・ツー・ＪＰＥＧ２０００マッパー）で説明したようにサーバ側のファイルを解析したのと同様に、キャッシュ内のファイルを解析する。クライアントは、既にキャッシュ内に保有するタイルパーツのリストを形成し、サーバへ送信する前に問い合わせ文字列に付加する。したがって、サーバは、問い合わせ文字列：
ＧＥＴ  ｆｉｌｅｎａｍｅ．ｊｐ２ｘｏ＝０．０＆ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２＆ｍａｘｘ＝７５０＆ｍａｘｙ＝７５０＆Ｔ２ｃａｃｈｅ＝４．０，  ５．０，  ８．０，  ８．１，  ８．２，  ８．３，  ９．０，  ９．１，  ９．２，  ９．３  ＨＴＴＰ／１．１
を取得する。
【００８３】
勿論、様々なシンタックスがビューポートを指定するため使用され得る。ＪＰＥＧ２００パート９標準の最新版は、以下のシンタックスに類似したシンタックスを使用する。殆どのパラメータは、当業者が要求シンタックスの様々なタイプの間で翻訳できる。
【００８４】
【表４】
2004208266.tif 000006
〔パラメータの説明〕
パラメータＯｆｆｓｅｔ＝Ｐｘ，Ｐｙ及びＳｉｚｅ＝Ｓｘ，Ｓｙは、左端のＰｘサンプルから始まり、右側へサンプルＰｘ個分だけ拡がり、一番上のＰｙサンプルから始まり、下方へサンプルＰｙ個分だけ拡がる画像の領域を指定する。左端は基準グリッドのＸＯｓｉｚの位置にあり、一番上はＹＯｓｉｚの位置にある場合を考える。ＳＩＺマーカー・セグメントの定義については、ＪＰＥＧ２０００パート１の付録Ａを参照のこと。これらのサンプルは、フレームサイズパラメータによって指定された解像度である。
【００８５】
パラメータＦｒａｍｅ−ｓｉｚｅ＝Ｒｘ，Ｒｙは、クライアントが画像を見ることを望む解像度である。Ｒｘ及びＲｙは、０から画像の寸法まで変化する。しかし、ＪＰＥＧ２０００のドメインでは、復号化された画像は、有限のレベルの解像度でしか見ることができない。そのため、クライアントの要求に応じて、サーバは、Ｒ’ｘ≧Ｒｘ並びにＲ’ｙ≧Ｒｙとなるような解像度Ｒ’ｘ及びＲ’ｙを送信する。Ｒ’ｘ及びＲ’ｙがＲｘ及びＲｙとは異なる場合、サーバはこの情報をヘッダで送信する必要がある。ＪＰＥＧ２０００パート１に記載されているように、解像度低下画像は、正確な位置に応じて、左端（左縁）と右端（右縁）で丸められる。例えば、画像７グリッド点幅は、ＳＩＺマーカーのオフセットの値に依存して、４サンプル分若しくは３サンプル分だけ幅が縮小する。
【００８６】
Ｒ’ｘ及びＲ’ｙに依存して、要求された領域の左上隅のオフセット、幅、及び、高さは、
Ｐ’ｘ＝Ｐｘ＊Ｒ’ｘ／Ｒｘ，  Ｐ’ｙ＝Ｐｙ＊Ｒ’ｙ／Ｒｙ，  Ｓ’ｘ＝Ｓｘ＊Ｒ’ｘ／Ｒｘ，  及び  Ｓ’ｙ＝Ｓｙ＊Ｒ’ｙ／Ｒｙ
のように変化し、ここで、Ｐ’ｘ及びＰ’ｙは実際のオフセットを表し、Ｓ’ｘ及びＳ’ｙはクライアント側のキャンバスに表示された画像の実際の幅及び高さを表す。
【００８７】
コンポーネントパラメータは、どのコンポーネントを取り入れるべきであるかを指定する整数のリストである。コンポーネントは０から順番に番号付けされている。レンジを使用してもよい。かくして、Ｃｏｍｐｏｎｅｎｔｓ＝０−２，５は、コンポーネント０、１、２及び５を返す。
【００８８】
Ｌ＝ｑｕａｌｉｔｙパラメータは、サーバが送信すべきデータの量を決定する際に役立つ。サーバは、返却すべきレイヤの数として品質値を使用することを選択することもある。いずれの場合でも、品質に対する０ｘＦＦＦＦの要求は、サーバが領域内のタイルパーツに関して保有するすべてのデータを要求する。
【００８９】
パラメータＢｈ及びＢｓはオプションパラメータであり、サーバは、このパラメータを用いて、実際に送信されるバイト数に関するハードリミット若しくはソフトリミットを設定することができる。低解像度のタイルパーツが最初に送信され、高解像度のタイルパーツは、このリミットに達するまで送信される。このフィールドが存在しない場合、サーバは、特定の解像度で要求された領域を表示するために必要なタイルパーツを送信することができる。
【００９０】
フラグＡＤＤが肯定（ｙｅｓ）にセットされている場合、新しい要求を前に要求されたウィンドウと連結することができる。デフォルトとして、このフラグは、無効にされ、新しいウィンドウが要求されると、クライアントは前のウィンドウを置き換える。
【００９１】
〔応答シンタックス〕
〔第３ティアー応答〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、画像オブジェクトは、ビューポートを埋めるために適したＰＮＧファイル若しくはＪＰＧファイルである。このタイプの応答は以下のような応答である。
ＨＴＴＰ／１．１  ２００  ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ｉｍａｇｅ／ｊｐｅｇ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：  ２０３８７
ＣＲＬＦ
ＪＰＥＧ  Ｃｏｍｐｒｅｓｓｅｄ  Ｉｍａｇｅ  Ｄａｔａ
【００９２】
尚、以下の第２ティアー応答に関して説明されるようなチャンク形式転送コーディングを使用することが好ましいが、チャンク形式転送コーディングを使用しなければならない訳ではない。
【００９３】
〔第２ティアー応答〕
第２ティアー応答は、ＨＴＴＰヘッダでラップされチャンク形式転送エンコーディングを使用して送信された、要求されたボックスと、（前に送信されていならば）コードストリーム・メインヘッダと、連結されている要求されたタイルパーツと、により構成される。第２ティアー応答は、非常に大きくなり、送信するために非常に長い時間を要する可能性があるので、送信の途中で中断できることが重要である。例えば、１Ｋ×１Ｋのタイルを含む画像は、１．５メガバイトの応答を生ずる（遅いリンクを用いる場合、これは、長い時間を要する）。チャンク形式転送エンコーディングが指定されない限り、ＨＴＴＰ要求は、”Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：”ヘッダの本体部の全長を指定するか、又は、接続を終えることによりデータの終了を示すことが必要である。どちらも実現可能ではあるが、望ましくはない。なぜならば、現在の応答を停止し、新しい要求のために同じコネクション上で更なるデータを送信することが望ましいからである。チャンク形式の場合、各チャンクの長さが送信され、応答を終了するため、長さ零が送信される。このように、一旦チャンクが開始されると、チャンクを終了させる必要があるが、応答を終了する前にすべての応答を完了させる必要はない。
【００９４】
以下にチャンク形式応答の例を示す。
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ：  ０−２０００，  ４０００−１０２００／８６７３７０
Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ：  ｃｈｕｎｋｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ｉｍａｇｅ／ｊｐｅｇ２０００
ＣＲＬＦ
１０００
［４０９６  （ｏｒ  １０００  ＨＥＸ−ＤＥＣＩＭＡＬ）  ｂｙｔｅｓ  ｏｆ  ＪＰＥＧ  ２０００  ｄａｔａ］
１０００
［４０９６  （ｏｒ  １０００  ＨＥＸ−ＤＥＣＩＭＡＬ）  ｂｙｔｅｓ  ｏｆ  ＪＰＥＧ  ２０００  ｄａｔａ］
８
［８  ｂｙｔｅｓ  ｏｆ  ＪＰＥＧ  ２０００  ｄａｔａ］
０
【００９５】
上記の例の最初のヘッダラインは、応答が完全なファイルではないことを示すため「部分コンテンツＰａｒｔｉａｌ  Ｃｏｎｔｅｎｔ」ヘッダを使用する。”Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ”ヘッダは、ファイルのどの部分が送信されるかを示すため使用される。転送エンコーディング”Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ：”ヘッダは、データがチャンク形式であることを示すため使用される。データのタイプが与えられる。なぜならば、応答は、”ｉｍａｇｅ／ｊｐｅｇ２０００”というタイプが与えられた復号可能なＪＰＥＧ２０００ファイルであるからである。他のタイプを使用してもよい。
【００９６】
１番目よりも後の応答の場合、応答は、有効なＪ２Ｋコードストリームを格納していない（メインヘッダが含まれないことは非常に稀である。）。この場合、別のタイプ、例えば、”ｉｍａｇｅ／ｊＰｉＰ”を用いてそのことを示すことが望ましい。
【００９７】
一実施例において、４０９６バイトの第１のチャンクを送信した後に新しい要求が受信され、サーバが伝送を終了させることに決定した場合、サーバは、現在のボックス、メインヘッダ、若しくは、タイルパーツを完了し、長さ０のチャンクを示す。次に、新しい応答が新しいＨＴＴＰヘッダを用いて開始される。
【００９８】
〔第１ティアー応答〕
一実施例では、第１ティアー応答は、ＨＴＴＰ［ＨＴＴＰ標準］に規定されているバイトレンジ応答と同じである。データを簡単に終端できるように、チャンク形式転送エンコーディングを使用することが望ましい。
【００９９】
〔要求／応答セマンティックス〕
要求を受信した後、サーバはチャンクを送信している間に更なる要求を受信しようとしている。
【０１００】
サーバは、新しい要求の優先順位が十分であるならば、現在の応答を正常に終了し、新しい要求に応答し始める。一実施例では、十分な優先順位は、”Ｉｎｆ”優先順位の要求によって示される。サーバは、現在のタイルパーツを終え、現在の要求に対してこれ以上チャンクが送信されないことを示すチャンクサイズ０を送信する。一実施例において、サーバは、ＨＴＴＰフッターを付加し、次の応答を開始する。
【０１０１】
サーバが”Ｉｎｆ”以外の優先順位を受信した場合、サーバは、現在の要求の中で継続すべき要求の量を決定する。現在の要求が新しい要求に対する良好な回答であるならば、アクションは必要ではない。例えば、新しい要求は異なるビューであっても、依然として同じ部分のセットが必要である場合がある。新しい要求の優先順位が前の要求の優先順位よりも１だけ高い場合、旧い要求は、新しい要求のために現在のタイルパーツの終わりで一時中断させることが提案される。
【０１０２】
最終的には、一実施例では、サーバは、すべての要求に適合する簡単な応答を送信する。或いは、応答が複数の要求に回答することを示すために規定されたシンタックスが使用される。この場合、サーバは、現在の転送を停止することなく、かつ、新しいＨＴＴＰヘッダから開始することなく、新しい要求若しくは旧い要求に関連したタイルパーツを送信し続ける。一実施例では、この場合、サーバは、拡張され得る要求を開始するときに、”Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ：”ヘッダを使用しない。
【０１０３】
〔サーバデータ記憶フォーマット〕
一実施例において、トランスポート・プロトコルは、すべてのＪＰＥＧ２０００ファイルフォーマット及びコードストリームで機能する。しかし、このような方式での機能は、必ずしも効率的ではない。例えば、タイルが使用されない場合、領域の要求は、コードストリーム全体を返すことがある。
【０１０４】
トランスポート・プロトコルと共に使用する最も効率的な画像圧縮方法は、期待されるアクセスの性質に依存する。”Ｃａｌｌ  ｆｏｒ  ＪＰＩＰ  ｔｅｃｈｎｏｌｏｇｙ  ｐｒｏｐｏｓａｌｓ”［ＪＰＩＰ  Ｅｄｉｔｏｒｓ  （Ｐｒａｎｄｏｌｉｎｉ，  Ｈｏｕｃｈｉｎ，  Ｃｌａｒｋ），  Ｃａｌｌ  ｆｏｒ  ＪＰＩＰ  ｔｅｃｈｎｏｌｏｇｙ  ｐｒｏｐｏｓａｌｓ，  ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ  ２５５０，  ２１  Ｍａｒｃｈ  ２００２］に規定されているような「パン及びズーム」動作のシーケンスの場合、Ｎ／１６×Ｎ／１６のタイルサイズを使用することは、Ｎ×Ｎ画素のサイズの矩形画像に対して優れている。
【０１０５】
使用されるコードストリームに対する一つのプログレッション順序は、解像度−レイヤ−コンポーネント−位置（ＲＬＣＰ）である。タイルは、あらゆる解像度及びあらゆるレイヤでタイルパーツに分割可能である。一実施例において、低解像度のすべてのタイルパーツは、より高解像度のタイルパーツよりも前にファイルに保存される。これにより、低解像度部分は、最小回数のディスクアクセスで入手できるようになる。一実施例において、十分な品質は、タイル境界アーティファクトを回避するため、最初のレイヤに記憶される。
【０１０６】
場合によっては、無損失で保存された画像の低解像度バージョンをブラウズできることが望ましい。ＲＬＣＰ順の場合、画像が無損失に蓄積されるとは、低解像度画像のために多数のビットが使用されることを意味する。これは、クライアントとサーバの間の低速コネクションによる画像のパンとズームのブラウジングを遅くする。この問題は、画像をサーバに特殊な方法で格納することによって解決される。レイヤ−解像度−コンポーネント−位置（ＬＲＣＰ）プログレッション順序は、コードストリームのために使用されるが、最初のレイヤは、主として解像度順にデータを格納するため使用される。最後のレイヤは、画像の損失のない表現を記憶するため使用される。各レイヤには固有のタイルパーツが割り当てられるので、サーバは、完全なタイルパーツを送信することによって、望ましい解像度をクライアントに供給することが可能である。例えば、３レベルの解像度レベルのある単一の２５６×２５６タイルは、以下のように編成される。
【０１０７】
タイルパーツ０は、（すべてのコンポーネント及び位置に対して総計で）１２８バイトの解像度０のデータを格納するレイヤ０を収容する。これにより、かなり高品質であるが、依然として損失の多い画像（ビューイング解像度で１画素当たり１ビットと等価的な画像）がクライアントへ供給される。
【０１０８】
タイルパーツ１は、解像度０と解像度１の３８４バイトのデータを格納するレイヤ１を収容する。解像度０と解像度１のデータのバイト数は、解像度１の表示解像度で画質（画像品質）を最大にするように選択される。
【０１０９】
タイルパーツ２は、解像度０と解像度１と解像度２の１５３６バイトのデータを格納するレイヤ２を収容する。殆どのバイトは、解像度２であり、他の解像度は解像度２の表示解像度で最適な画質を得るために十分である。
【０１１０】
タイルパーツ３は、解像度０、１、２及び３の６１４４バイトのデータを格納するレイヤ３を収容する。タイルパーツ０〜３は、最適化された１ｂｐｐ画像を完全な解像度で格納する。
【０１１１】
タイルパーツ４は、損失の無い画像を得るために必要なすべての解像度の残りのデータを格納するレイヤ４を収容する。おそらく、階調画像については２４０００バイト、カラー画像についてはそれ以上のバイト数が必要である。勿論、タイルパーツは、２．０ビット／画素の画像と、損失の無い画像を得るため、補助的なタイルパーツに分割してもよい。或いは、ある最大タイルパーツサイズを維持するため、タイルパーツに分割してもよい。
【０１１２】
〔トランスポート・プロトコル性能〕
〔ディスクアクセスと要求される係数の数〕
以下の表４は、画像要求に応答するサーバによってアクセスされるファイル内の個別の場所の数のリストである。表４には、タイル全体又はプリーシンクトが要求に応じて送信されるならば、送信されるべき係数の数も掲載されている。勿論、送信されるべきバイト数は、主として圧縮比に依存するが、タイル若しくはプリーシンクトのサイズとは無関係に等しい圧縮を考慮すると、それらの値は応答サイズに関連付けられる。
【０１１３】
表４は、幾つかの異なるビューポイントに対するデータを表し、前の要求に対するデータが送信されたときに、新しいビューポイントに要求される補助的なアクセス／係数だけを表す。
【０１１４】
表４の値に対し、圧縮のため使用されるコマンドは以下の通りである。
Ｔｉｌｉｎｇ：  ｋｄｕ＿ｃｏｍｐｒｅｓｓ  −ｉ  ｌｅｎａ．ｂｍｐ  −ｏ  ｏｕｔ．ｊｐ２  −ｒａｔｅ  −，  ０．２５  Ｃｌａｙｅｒｓ＝３０  Ｃｒｅｖｅｒｓｉｂｌｅ＝ｙｅｓ  Ｓｔｉｌｅｓ＝｛１２８，  １２８｝
Ｃｏｒｄｅｒ＝ＲＬＣＰ
タイルサイズ：１２８×１２８；２５６×２５６；５１２×５１２；１０２４×１０２４  アンタイルに対する結果が表に掲載されている。
Ｐｒｅｃｉｎｃｔｓ：  ｋｄｕ＿ｃｏｍｐｒｅｓｓ  −ｉ  ｌｅｎａ．ｂｍｐ  −ｏ  ｏｕｔ．ｊｐ２  −ｒａｔｅ  −，  ０．２５  Ｃｌａｙｅｒｓ＝３０  Ｃｒｅｖｅｒｓｉｂｌｅ＝ｙｅｓ  Ｃｐｒｅｃｉｎｃｔｓ＝｛１２８，  １２８｝  ｃｏｒｄｅｒ＝ＲＰＣＬ
プリーシンクトサイズ３２×３２；６４×６４；１２８×１２８；２５６×２５６；５１２×５１２に対する結果は表に掲載され、同じサイズのプリーシンクトが各解像度で使用される。
【０１１５】
表４は、プリーシンクトとタイルパーツの比較であるとみなすべきではない。なぜならば、プリーシンクトは、各解像度で、タイルに要求されるよりも小さいサイズを使用できるからである。
【０１１６】
【表５】
2004208266.tif 000007
【０１１７】
【表６】
2004208266.tif 000008
〔セッション持続性〕
一実施例において、プロトコルは、幾つかのメカニズムによって時間的に分離された多重接続上であってもデータの再送信を回避する。これは、既にクライアントへ送信されたデータを示すために、クライアントに、ｈｔｔｐヘッダのうちの一つ（例えば、Ｔ２ｃａｃｈｅ）を使用させることによって達成される。セッション持続性を与える代替的なメカニズムは、現在の多数の商業ウェブサイトで行われているように、セッションＩＤを維持するため、クッキー（ｃｏｏｋｉｅ）を使用することである。勿論、サーバは、セッションの記録を残さないこともあり、クライアントが全く保存していないと考えられるコードストリームの部分を送信するに過ぎない。
【０１１８】
〔エラー処理〕
エラー処理に関して、ＨＴＴＰは、エラー条件に対する様々な応答メッセージを含む。これらのすべては、このプロトコルと共に使用するために利用できる。エラーが検出された場合、ステージ間で再送信を要求することができる。ＨＴＴＰフッターは、送信データのチェックサムを送信するため使用可能であり、これにより、エラーを検出する。
【０１１９】
〔速度（レート）制御〕
速度制御に関して、トランスポート・レベル・プロトコルと、ソケットを実現するライブラリは、例えば、典型的に、クライアントが処理できる速度よりも速い速度でクライアントにデータが送信されていないことを保証する。殆どのソケットライブラリにおいて、”ｓｅｎｄ”呼び出しは、大量のデータが送信される場合、データが送信されるまでエラーを阻止するか、又は、エラーを返す。チャンク形式で大量の応答を送信することは、単一の”ｓｅｎｄ”が非常に大きくなることを阻止するはずである。一実施例において、最大バイトパラメータのようなパラメータは、バイト数を制限するため使用される。また、クライアント及び／又はサーバは、速度制御を行うことが許可される。これにより、遅いリンク上のバッファの充填が制御されるであろう。
【０１２０】
トランスポート・プロトコルは、クライアントが有効な最大画像を指定できるようにするｍａｘｈパラメータ及びｍａｘｗパラメータを与えない。クライアントは、ＪＰＥＧ若しくはＰＮＧへの翻訳を要求する。
【０１２１】
〔同時アクセスのためのサポート〕
ここで説明しているトランスポート・プロトコルは、サーバ上の同じ画像への同時アクセスを制限しない。一実施例では、単独のクライアントが同じサーバ上の同じリソースへ多重接続を開設する場合、各接続は、その接続についての要求の順序で扱われる。クライアントが望むならば、クライアントは、受信したＴ３ｃａｃｈｅ若しくはＴ２ｃａｃｈｅヘッダを用いて、所与の接続に要求していないデータを指定することができる。さもなければ、サーバは、二つの接続が全く同一のクライアントに対してなされていることを知ることができない。
【０１２２】
代替的な実施例では、セッション鍵は、別々の要求をつなぐため、要求及び応答のすべてのレベルに対するＨＴＴＰへ付加してもよい。これにより、上記のプロトコルは、ＨＴＴＰ１．１のデフォルトの「生かしておく（キープアライブ）」機能を用いることなく動作できる。また、これにより、信頼性の低いネットワーク上でもより巧く利用できるようになる。セッション内の要求を順番に並べるために要求番号を付加することが有効である。かくして、ＴＣＰ上でＨＴＴＰを用いる場合であっても、多重接続を作成し使用することが可能である。セッション鍵は、クッキーヘッダを用いて、或いは、要求パラメータとして組み込むことが可能である。
【０１２３】
〔ＪＰＩＰ要求バインディング〕
ＨＴＴＰは、ＴＣＰ／ＩＰ以外のチャネルによっても搬送することができる。したがって、このプロトコルを、ＴＣＰ／ＩＰ以外のＨＴＴＰをサポートするチャネルで使用することが望まれるならば、新しい定義は不要である。一実施例では、未訂正のエラー若しくはパケット損を含むチャネルに対してプロトコル・バインディングを指定することが望ましい場合、チャンク形式転送エンコーディングを使用する応答の各チャンクは、固有のネットワークパケットになる。他のすべての要求及び応答は、ネットワークパケット内に適合する。一実施例において、これらは、コネクション優先チャネルのため送出される順番にパケット番号が与えられる。尚、ＨＴＴＰ以外のプロトコルを使用しても構わないことにも注意する必要がある。
【０１２４】
〔キャパビリティ交換とネゴシエーション〕
一実施例では、キャパビリティは、応答のヘッダだけを要求するＨＴＴＰメソッド”ＨＥＡＤ”を用いて要求され、クライアントは、”ＧＥＴ”要求を用いて受信した応答のタイプを決定することが可能である。一例は、
ＨＥＡＤ  ｆｉｌｅｎａｍｅ．ｊｐ２？ｒｅｓ＝２  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
のように表される。
【０１２５】
一実施例において、サーバのキャパビリティは、ＨＴＴＰメソッド”ＯＰＴＩＯＩＮＳ”、例えば、
ＯＰＴＩＯＮＳ  ＊  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
を用いて要求される。
【０１２６】
一実施例において、特定の画像上の動作のキャパビリティは、
ＯＰＴＩＯＮＳ  ｆｉｌｅｎａｍｅ．ｊｐ２  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
を用いて決定される。
【０１２７】
ＨＴＴＰ  １．１  ＲＦＣは、キャパビリティを示すメカニズムを含む。ここで説明されている画像プロトコルの場合、サーバは、以下のラインを含むヘッダを返す。
Ａｃｃｅｐｔ−Ｒａｎｇｅｓ：  ｂｙｔｅｓ，  ｔｉｌｅ−ｐａｒｔｓ
Ａｃｃｅｐｔ：  ｉｍａｇｅ／ｊｐｅｇ２０００；ｑ＝０．９  ｉｍａｇｅ／ｇｉｆ；ｑ＝０．５  ｉｍａｇ／ｊｐｉｇＴ２；ｑ＝０．９５  ｉｍａｇｅ／  ｊｐｉｐＴ３；ｑ＝０．１
Ａｌｌｏｗ：  ＧＥＴ，  ＨＥＡＤ，  ＰＯＳＴ，  ＯＰＴＩＯＮＳ，  ＴＲＡＣＥ
Ｖａｒｙ：  ａｃｃｅｐｔ，  ＊
【０１２８】
ＨＴＴＰ  １．１  ＲＦＣは、ここで説明されている画像プロトコルの場合、以下のようなヘッダが役に立つ。
Ａｃｃｅｐｔ−Ｒａｎｇｅｓ：  ｂｙｔｅｓ，  ｔｉｌｅ−ｐａｒｔｓ
【０１２９】
”Ａｃｃｅｐｔ−Ｒａｎｇｅｓ：  ｂｙｔｅｓ”は、正当なＨＴＴＰ／１．１コマンドである。一実施例において、サーバは、直接バイトレンジ要求に応答する能力を示すため、トランスポート・プロトコルでこれを使用する。このような場合、洗練されたクライアントは、コードストリーム又はファイルフォーマットの望ましい部分を正確に抽出する。
【０１３０】
”Ａｃｃｅｐｔ−Ｒａｎｇｅｓ：  ｔｉｌｅ−ｐａｒｔｓ”の使用は、サーバがタイルパーツに対する直接要求に応答する能力を示すための一つの方法である。
Ａｃｃｅｐｔ：  ｉｍａｇｅ／ｊｐｅｇ２０００；ｑ＝０．９  ｉｍａｇｅ／ｇｉｆ；ｑ＝０．５  ｉｍａｇｅ／ｊｐｉｐＴ２；ｑ＝０．９５  ｉｍａｇｅ／ｊｐｉｐＴ３；ｑ＝０．１
尚、ＨＴＴＰは、Ａｃｃｅｐｔヘッダ内で能力を示すだけではなく、優先度を示す。画像をトランスコードする能力を備えたＪＰＥＧ  ２０００画像サーバは、クライアントとサーバの両方が最高優先度でサポートするタイプのビューポート要求を返す。或いは、サーバは、より優先度の低いタイプを返すことに決定してもよい。なぜならば、その方がサーバに対する負荷が軽いからである（例えば、サーバは、サーバの負荷が高い場合には、伸長及び再圧縮を必要としないタイプを返すかもしれない。）。或いは、サーバは、最終的に、多数の要求によって帯域幅が低下するかもしれない。
Ａｌｌｏｗ：  ＧＥＴ，  ＨＥＡＤ，  ＰＯＳＴ，  ＯＰＴＩＯＮＳ，  ＴＲＡＣＥ
【０１３１】
このＨＴＴＰラインは、サーバが許可するコマンドを示す。これらのコマンドは、今まで使用されていたのと同じように画像サーバで使用される。
Ｖａｒｙ：  ａｃｃｅｐｔ，  ＊
【０１３２】
Ｖａｒｙヘッダは、応答が、クライアントが許容することを示すリターンタイプに依存することを示す。”＊”は、応答がｈｔｔｐヘッダ以外のものに依存するかもしれないことを示す。ここで説明しているプロトコルを使用するシステムにおけるサーバにおいて、返却される正確な内容は、前の要求に依存するかもしれない。例えば、サーバは、既にクライアントが保有していることを確信するタイルパーツを返さない。これは、ＨＴＴＰプロキシを実現するために重要である。なぜならば、返却されたデータは、同じタイルパーツの組をもたないクライアントからの等価的な要求に対して優れたデータではない可能性があるからである。
【０１３３】
〔画像の一意識別〕
ＨＴＴＰは、リソースを一意に識別するメカニズムを備えていることに注意する必要がある。”Ｅｔａｇ”は応答を一意に識別する（ＨＴＴＰ  １．１  ＲＦＣ  ２６１６［ＨＴＴＰ標準］のセクション１４．１９を参照。）。
【０１３４】
ＪＰＥＧ  ２０００パートＩは、ＵＵＩＤボックスを識別する（ＩＴＵ−Ｔ  Ｒｅｃ．  Ｔ．８００｜ＩＳ１５４４４−１：２０００，  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  ＿  ＪＰＥＧ  ２０００  ｉｍａｇｉｎｇ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ：  Ｃｏｒｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍのセクションＩ．７．２を参照。）。ここで説明されるプロトコル要求シンタックスは、ボックスの返却を可能にさせ、このボックスは画像の一意性を判定するために要求され得る。
【０１３５】
”Ｅｘｐｉｒｅｓ”のようなＨＴＴＰヘッダを用いることにより、クライアントは、キャッシュされたデータが有効ではなくなるときを知ることができる。ＨＴＴＰ標準のセクション１４．２１を参照。
【０１３６】
〔サーバへの画像アップローディング〕
完全な画像は、ＨＴＴＰメソッドＰＯＳＴを使用してアップロードできる。この場合、シンタックスは、他のファイルアップロードと全く同じようにみえる。トランスポート・プロトコルは、全タイルパーツのアップローディングを可能にさせる。この場合、ヘッダは、Ｔｉｅｒ２シンタックスを使用してアップロードされているタイルパーツがどのタイルパーツであるかを示す。クライアントは、アップロードされたタイル毎にすべてのタイルパーツを与える。サーバは、アップロードされたタイルのすべてのタイルパーツを削除し、新しいタイルパーツを格納する。サーバは、元のファイルの順序とは異なる順序でタイルパーツを格納するように選択する。更に、ＴＬＭを更新しなければならない。サーバは、ＰＰＭマーカー・セグメントを使用して画像を更新することを拒絶するように選択してもよい。勿論、サーバは、画像又はタイルパーツを全くアップロードしないように選択してもよい。一部のサーバは、ＨＴＴＰメソッドＤＥＬＥＴＥをサポートすることを選択する。このメソッドの場合、ＪＰＥＧ２０００画像に対して特別なシンタックスは要求されない。
【０１３７】
〔その他の能力〕
１回の要求の後に画像を返す能力は有用である。最も顕著な例は、インライン形イメージを含むウェブページである。画像タグは、画像の返却を可能にさせる。ウェブページの作成者は、組み込まれる画像と、ページのレイアウトについての知識があり、ＵＲＬを設定しているので、おそらく、サーバの能力についても知っているであろう。「キャパビリティ交換（ｅｘｃｈａｎｇｅ  ｃａｐａｂｉｌｉｔｉｅｓ）」と画像獲得の必要性はない。
【０１３８】
一実施例において、ブラウザがＪＰＥＧ  ２０００画像を理解できるようにするため、個々で説明しているプロトコルは、
＜ｉｍｇ  ｓｒｃ＝”ｈｔｔｐ：／／ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ／ｎａｍｅ．ｊｐ２？ｒｅｓ＝２”  ｗｉｄｔｈ＝”１２８”  ｈｅｉｇｈｔ＝”１１５”＞
のような呼び出しをサポートする。このコールは、低解像度部分を含むｊｐ２ファイルを返す。一実施例において、ブラウザは、ＪＰＥＧ画像及びＧＩＦ画像のように、作成者が望む１２８×１１５のウィンドウに巧く収まるように画像を拡大縮小する。
【０１３９】
すべてのブラウザが画像を読み取れることを保証するため、画像タグは、画像がＰＮＧ（或いは、ＧＩＦ若しくはＪＰＥＧ）に変換されることを要求できる。
＜ｉｍｇ  ｓｒｃ＝”ｈｔｔｐ：／／ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ／ｎａｍｅ．ｊｐ２？ｒｅｓ＝２＆ｔｉｅｒ３＝ＰＮＧ”  ｗｉｄｔｈ＝”１２８”  ｈｅｉｇｈｔ＝”１１５”＞
【０１４０】
サーバがＪＰ２ファイルにアクセスし続けるとしても、配信する前に変換されるであろう。
【０１４１】
〔拡張／代案〕
〔タイルパーツ「オンザフライ」を書き換えるためにＰＯＣマーカーを使用〕
一実施例では、ここで説明するプロトコルは、サーバに現れるようなタイルパーツだけに役立つ。異なる領域をバラバラの順序でアクセスしてもよいが、すべてのタイルパーツは順番にアクセスされる。そのため、クライアントがコンポーネント２にアクセスすることを望み、コンポーネント０及び１が最初にタイルパーツに格納されるならば、すべての典型的なプログレッション順の場合と同様に、要求されていないデータが送信される。
【０１４２】
しかし、代替実施例では、サーバは、クライアントによって要求された順序通りになるように、タイル内でタイルパーツを再配置することができる。一実施例では、サーバは、解像度、レイヤ、及び、タイルパーツに格納されたコンポーネントを指定するため、各タイルパーツに関してＪＰＥＧ２０００標準のＰＯＣマーカーを使用する。これは、サーバ側でのバッファリングを要求する。キャッシングの方がより一層難しい。なぜならば、サーバは、コードストリームが並べ替えられた状況を把握しているからである。一実施例では、これは、要求コマンドを追跡することによって行われる。一実施例において、サーバは、要求及び応答を行うため、内部データ構造を使用する。一実施例では、サーバは、クライアントが要求した順序でファイルのコピーを書き込む。
【０１４３】
サーバが、各解像度について１個ずつのタイルパーツがＲＬＣＰ順に並べられている３コンポーネントＪＰＥＧ２０００ファイルを格納している場合を考える。さらに、一つのタイルパーツに関して１個のレイヤと１個のプリーシンクトだけが存在すると仮定する。このとき、タイルパーツデータは、
ＳＯＴ  ｍａｒｋｅｒ  ｓｅｇｍｅｎｔ（Ｔｉｌｅ  ０，  Ｌｅｎｇｔｈ  ｏｆ  ｔｉｌｅ−ｐａｒｔ，  Ｐａｒｔ  ０，  Ｎｕｍｂｅｒ  ｏｆ  Ｐａｒｔ  ０）
ＳＯＤ  ｍａｒｋｅｒ
Ｐａｃｋｅｔ  Ｈｅａｄｅｒ／Ｂｏｄｙ  ｏｆ  Ｒｅｓｏｌｕｔｉｏｎ  ０，  Ｌａｙｅｒ  ０，  Ｃｏｍｐｏｎｅｎｔ  ０，  Ｐｏｓｉｔｉｏｎ  ０（Ｒ０Ｌ０Ｃ０Ｐ０）
Ｐａｃｋｅｔ  Ｈｅａｄｅｒ／Ｂｏｄｙ  ｏｆ  Ｒ０Ｌ０Ｃ１Ｐ０
Ｐａｃｋｅｔ  Ｈｅａｄｅｒ／Ｂｏｄｙ  ｆｏｒ  Ｒ０Ｌ０Ｃ２Ｐ０
のように見えるであろう。
【０１４４】
クライアントが最初のコンポーネント（番号０）だけを要求する場合、サーバは、コンポーネント１及び２からのデータを含むすべてのタイルパーツを送信する。これは、望んでいないコンポーネントに対するデータが大量である場合には、非効率的である。そこで、サーバは、最初のコンポーネントだけを収容するファイルには実際に現れないタイルパーツを作成し、クライアントへ送信する。メインヘッダは、ファイル内に２個以上のコンポーネントが存在することを示すので、サーバは、このタイルパーツが１個のコンポーネントしか含まないことを示す。サーバは、数通りの方法を用いて、状況の順番を変えるためにファイルを変更することができる。
【０１４５】
プログレッション順は、ＣＰＲＬに変更してもよく、クライアントは、最初にコンポーネント０が現れることを予想する。これは、クライアントが最初にコンポーネント２ではなく、コンポーネント０を要求する場合に機能する。
【０１４６】
他のコンポーネントに対するパケットは、零データを保有するように変更できる。これは、他のコンポーネントに対するデータが後のパケットまで現れないようにレイヤ割り当てを変更することと等価的である。しかし、プレースホルダーとしての役割を果たすためには、スキップされたパケット毎に１バイトパケットヘッダを組み込むことが依然として必要である。更に、他のコンポーネントからのデータが要求されるとき、パケットヘッダは、正しいレイヤ情報を組み込むために書き込まれなければならない。
【０１４７】
一実施例において、ＰＯＣマーカー・セグメントは、タイルパーツヘッダに収容される。タイルパーツは、
ＳＯＴ  ｍａｒｋｅｒ  ｓｅｇｍｅｎｔ（Ｔｉｌｅ  ０，  Ｌｅｎｇｔｈ  ｏｆ  ｔｉｌｅ−ｐａｒｔ，  Ｐａｒｔ  ０，  Ｎｕｍｂｅｒ  ｏｆ  Ｐａｒｔ  ０）
ＰＯＣ  ｍａｒｋｅｒ  ｓｅｇｍｅｎｔ（Ｒｅｓｏｌｕｔｉｏｎ  ｓｔａｒｔ＝０，  Ｃｏｍｐｏｎｅｎｔ  ｓｔａｒｔ＝０，  ｌａｙｅｒ  ｅｎｄ＝１，  ｒｅｓｏｌｕｔｉｏｎ  ｅｎｄ＝１，  ｃｏｍｐｏｎｅｎｔ  ｅｎｄ＝１）
ＳＯＤ  ｍａｒｋｅｒ
Ｐａｃｋｅｔ  Ｈｅａｄｅｒ／Ｂｏｄｙ  ｏｆ  Ｒｅｓｏｌｕｔｉｏｎ  ０，  Ｌａｙｅｒ  ０，  Ｃｏｍｐｏｎｅｎｔ  ０，  Ｐｏｓｉｔｉｏｎ  ０（Ｒ０Ｌ０Ｃ０Ｐ０）
のように表される。
【０１４８】
このタイルパーツは、要求されたデータだけを格納する。更なる要求によって、新しいタイルパーツが生成され、新しいタイルパーツは、要求されたデータだけを格納する新しいＰＯＣマーカーを含む。
【０１４９】
パケット自体は変更する必要がなく、パケットを送信する順序だけが変更される。
【０１５０】
いずれにしても、この技術の一つの重要な利点は、クライアントが、受信したコードストリームの部分を追跡するための補助的な構造を用いることなく、常に正当なＪＰＥＧ２０００ファイルを保有し続けることである。
【０１５１】
〔補助的な用途の場合：メモリもデコーダも無いクライアント〕
非常に簡単なクライアントは、クライアントの表示エリアよりも少ないメモリしか備えていないにもかかわらず、非常に大きい画像をブラウズすることを望む場合がある。圧縮画像データをキャッシュすることは期待できない。クライアントはＪＰＥＧ２０００デコーダを具備しない場合もある。しかし、このクライアントは、ＪＰＥＧ２０００サーバと通信し、Ｔｉｅｒ３要求を作成し、Ｔｉｅｒ３応答を受信することが可能である。
【０１５２】
〔典型的なコンピュータシステム〕
図８は、上記の一つ以上の動作を実行する典型的なコンピュータシステムのブロック図である。図８によると、コンピュータシステム８００は、典型的なクライアント若しくはサーバを構成する。コンピュータシステム８００は、情報を通信する通信メカニズム若しくはバス８１１と、バス８１１に接続され情報を処理するプロセッサ８１２と、を含む。プロセッサ８１２は、例えば、Ｐｅｎｔｉｕｍ（登録商標）、ＰｏｗｅｒＰＣ（登録商標）、Ａｌｐｈａ（登録商標）などのマイクロプロセッサを含むが、これらのマイクロプロセッサには限定されない。
【０１５３】
システム８００は、バス８１１に接続され、情報を記憶し、プロセッサ８１２によって実行される命令を記憶するランダム・アクセス・メモリ（ＲＡＭ）、若しくは、ダイナミック記憶装置８０４（メインメモリと呼ばれる）を更に含む。メインメモリ８０４は、プロセッサ８１２による命令の実行中に、一時的な変数、若しくは、他の中間情報を記憶するためにも使用される。
【０１５４】
コンピュータシステム８００は、バス８１１に接続され、プロセッサ８１２のための静的情報及び命令を記憶するリード・オンリー・メモリ（ＲＯＭ）及び／又はその他のスタティック記憶装置８０６と、磁気ディスク若しくは光ディスク及び対応したディスクトドライブを備えたデータ記憶装置８０７と、を更に含む。データ記憶装置８０７は、バス８１１に接続され、情報と命令を記憶する。
【０１５５】
コンピュータシステム８００は、バス８１１に接続され、情報をコンピュータのユーザへ提示する陰極線管（ＣＲＴ）若しくは液晶ディスプレイ（ＬＣＤ）のような表示装置８２１に接続される。英数字キー及びその他のキーを備えた英数字入力装置８２２もバス８１１に接続され、情報及びコマンド選択をプロセッサ８１２へ通知する。補助的なユーザ入力装置は、マウス、トラックボール、トラックパッド、スタイラス、或いは、カーソル方向キーのようなカーソル制御装置８２３であり、バス８１１に接続され、方向情報及びコマンド選択をプロセッサ８１２へ通知し、表示装置８２１上のカーソルの動きを制御する。
【０１５６】
バス８１１に接続され得るその他の装置には、命令、データ、若しくは、その他の情報を、紙、フィルム、若しくは、類似したタイプの媒体などのような媒体に印刷するため使用されるハードコピー装置８２４が含まれる。更に、スピーカー及び／又はマイクロホンのような音声記録及び再生装置がバス８１１に接続され、コンピュータシステム８００との間で音声インタフェースを実現する場合もある。バス８１１に接続できる他の装置には、電話機、又は、ハンドヘルド型の手のひらサイズの装置若しくはコンピュータやサーバと通信する有線／無線通信設備８２５が含まれる。
【０１５７】
バスに接続できる別の装置は、例えば、デジタル信号プロセッサ（ＤＳＰ）若しくは特殊な圧縮（及び／又は伸長）ハードウェアを構成するコ・プロセッサ８３５である。
【０１５８】
システム８００と関連したハードウェアの一部若しくは全部が本発明で使用される。しかし、他のコンピュータシステムのコンフィギュレーションでも、一部若しくは全部の装置を収容できることが明らかである。
【０１５９】
上述の説明では、種々の特定の細部が本発明の全体の理解が得られるように解説されている。当業者に明らかであるように、本発明は、これらの特定の細部を用いることなく実施できる。別の例では、構造及び装置は、本発明がわかり難くなることを避けるためブロック図の形式で示されている。
【０１６０】
以下の詳細な説明の一部は、コンピュータメモリ内のデータビットに関する演算のアルゴリズム及び記号表現の形で与えられている。これらのアルゴリズム記述及び表現は、データ処理技術の当業者が自分の業績の要旨を他の当業者にできるだけ効率的に伝達するため使用する手段である。本明細書において、並びに、一般的に、アルゴリズムは、希望の結果を生ずる首尾一貫したステップ（手順）の系列であると考えられる。ステップは、物理量の物理的な操作を必要とする。通常、必須的ではないが、これらの量は、記憶、転送、合成、比較及びその他の操作を加えることができる電気信号若しくは磁気信号の形式をとる。主として慣用されているという理由から、これらの信号は、ビット、値、エレメント、シンボル、文字、項、数などのように呼ばれる。
【０１６１】
しかし、これらのすべての用語、並びに、類似した用語は、適切な物理量と関連付けられるべきであり、これらの量に適用された便利なラベルに過ぎない。特に断らない限り、以下の説明から明らかであるように、説明全体を通じて、「処理」、「コンピューティング」、「計算」、「決定」、「表示」などのような用語を利用する議論は、コンピュータシステム、若しくは、類似した電子コンピューティング装置の動作及び処理について言及するものであり、コンピュータシステムは、コンピュータシステムのレジスタ及びメモリ内で物理（電子的）量として表現されたデータを操作し、コンピュータシステムのメモリ若しくはレジスタ、或いは、他のこのような情報記憶装置、伝送装置又は表示装置内で物理量として同じように表現された他のデータに変換する。
【０１６２】
本発明は、上記の演算を実行する装置にも関する。この装置は、要求された目的のため特別に構築されるか、或いは、コンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ状態にされるか、又は、再構築される汎用コンピュータを具備する。このようなコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に保持される。コンピュータ読み取り可能な記録媒体の例には、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスクなどの任意のタイプのディスクと、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード若しくは光カード、或いは、電子命令を記憶するために好適である任意のタイプの媒体が含まれるが、これらの例に限定されるものではない。各媒体はコンピュータシステムのバスに接続される。
【０１６３】
以下の説明におけるアルゴリズム及びディスプレイは、特定のコンピュータ若しくはその他の装置に本来的に関連付けられていない。多様な汎用システムが、上記の教示に従うプログラムと共に使用され、或いは、要求された方法の手順を実行するために、より特殊化された装置を構築する方が好都合であることが判明することもある。これらの多様なシステムのため要求される構造は、上記の説明から明らかになるであろう。更に、本発明は、特定のプログラミング言語に関しては説明されていない。上述の本発明の教示を実施するため、種々のプログラミング言語が使用される。
【０１６４】
機械読み取り可能な媒体は、機械（たとえば、コンピュータ）によって読み取り可能な形式で情報を記憶若しくは伝送する任意のメカニズムを含む。たとえば、機械読み取り可能な媒体は、読み出し専用メモリ（ＲＯＭ）と、ランダム・アクセス・メモリ（ＲＡＭ）と、磁気ディスク記憶媒体と、光記憶媒体と、フラッシュメモリ装置と、電気的、光学的、音響的若しくはその他の形式の伝搬信号（たとえば、搬送波、赤外線信号、デジタル信号など）と、を含む。
【０１６５】
以上の説明から分かるように、本発明の多数の代替例及び変形例は当業者にとって明白であり、例示的に説明され図示された特定の実施例は本発明を限定することを意図したものではないことが理解されるべきである。したがって、様々な実施例の細部に関する記述は、本発明に不可欠であると考えられる事項のみが記載されている請求項に係る発明の範囲を限定するものではない。
【０１６６】
【発明の効果】
本発明によれば、効率的な画像通信が実現される。
【図面の簡単な説明】
【図１】簡単な画像アクセスの説明図である。
【図２】典型的なソフトウェア構造の説明図である。
【図３】クライアントとサーバの区分の例の説明図である。
【図４】クライアントとサーバの区分の例の説明図である。
【図５】クライアントとサーバの区分の例の説明図である。
【図６】クライアントとサーバの区分の例の説明図である。
【図７】クライアントとサーバの区分の例の説明図である。
【図８】コンピュータシステムの一実施例の構成図である。
【図９】ビューポート質問パラメータとＳＩＺマーカー・セグメント・パラメータの間の対応関係の説明図である。
【符号の説明】
２００  アプリケーション
２０１  第１ステージ
２０２  第２ステージ
２０３  第３ステージ
２０４  第４ステージ
２０５  ファイルシステム、オンザフライ画像発生器又はバイトレンジサーバ
８０４  メインメモリ
８０６  スタティック・メモリ
８０７  大容量メモリ
８１１  バス
８１２  プロセッサ
８２１  表示装置
８２２  キーボード
８２３  カーソル制御装置
８２４  ハードコピー装置
８２５  無線／電話インタフェース
８３５  コ・プロセッサ
【図１】
2004208266.tif 000009
【図２】
2004208266.tif 000010
【図３】
2004208266.tif 000011
【図４】
2004208266.tif 000012
【図５】
2004208266.tif 000013
【図６】
2004208266.tif 000014
【図７】
2004208266.tif 000015
【図８】
2004208266.tif 000016
【図９】
2004208266.tif 000017
【外国語明細書】
2004208266.tif 000018
2004208266.tif 000019
2004208266.tif 000020
2004208266.tif 000021
2004208266.tif 000022
2004208266.tif 000023
2004208266.tif 000024
2004208266.tif 000025
2004208266.tif 000026
2004208266.tif 000027
2004208266.tif 000028
2004208266.tif 000029
2004208266.tif 000030
2004208266.tif 000031
2004208266.tif 000032
2004208266.tif 000033
2004208266.tif 000034
2004208266.tif 000035
2004208266.tif 000036
2004208266.tif 000037
2004208266.tif 000038
2004208266.tif 000039
2004208266.tif 000040
2004208266.tif 000041
2004208266.tif 000042
2004208266.tif 000043
2004208266.tif 000044
2004208266.tif 000045
2004208266.tif 000046
2004208266.tif 000047
2004208266.tif 000048
2004208266.tif 000049
2004208266.tif 000050
2004208266.tif 000051
2004208266.tif 000052
2004208266.tif 000053
2004208266.tif 000054
2004208266.tif 000055
2004208266.tif 000056
2004208266.tif 000057
2004208266.tif 000058
2004208266.tif 000059
2004208266.tif 000060
2004208266.tif 000061
2004208266.tif 000062
2004208266.tif 000063
2004208266.tif 000064
2004208266.tif 000065
2004208266.tif 000066
2004208266.tif 000067
2004208266.tif 000068
2004208266.tif 000069
2004208266.tif 000070
2004208266.tif 000071
2004208266.tif 000072
2004208266.tif 000073
2004208266.tif 000074
2004208266.tif 000075
2004208266.tif 000076
2004208266.tif 000077
2004208266.tif 000078
2004208266.tif 000079
2004208266.tif 000080
2004208266.tif 000081
2004208266.tif 000082
2004208266.tif 000083
2004208266.tif 000084
2004208266.tif 000085
2004208266.tif 000086
2004208266.tif 000087
2004208266.tif 000088
2004208266.tif 000089
2004208266.tif 000090
2004208266.tif 000091
2004208266.tif 000092
2004208266.tif 000093
2004208266.tif 000094
2004208266.tif 000095
2004208266.tif 000096
2004208266.tif 000097
2004208266.tif 000098
2004208266.tif 000099
2004208266.tif 000100
2004208266.tif 000101