(57)【特許請求の範囲】
【請求項１】
サーバからクライアントへオブジェクトの適合バージョンを含むファイルを転送する方法であって、
該サーバは、
マークアップ言語で書かれ、前記オブジェクトの基本バージョンを有する基本プログレッシブ・ファイルが記述される基本文書と、一つ以上の変換された文書を取得するため前記基本文書に適用される１以上の所定の変換規則とを保持するメモリと、
プロセッサと、
を有し、
前記方法は、前記プロセッサによって実行される、
前記クライアントのプロファイルの関数として前記１以上の所定の変換規則から所定の変換規則を選択する手順と、
変換された文書を作成するため前記選択された変換規則を前記基本文書に適用する変換手順と、
該変換された文書に基づいて該オブジェクトの該適合バージョンを格納する転送ファイルを作成する手順と、
前記転送ファイルを前記サーバから前記クライアントに転送する手順と、
を有し、
前記基本文書には、前記基本プログレッシブ・ファイルの構造が記述され、
前記変換手順は、前記基本プログレッシブ・ファイルを復号化することなく別のフォーマットのプログレッシブ・ファイルに変換することを特徴とするファイルを転送する方法。
【請求項２】
前記基本文書がタグによって区切られ、一つ以上の属性を有することが可能な一つ以上の要素を格納するとき、前記変換手順は、一つ以上の要素を抑制し、一つ以上の属性及び／又は一つ以上の要素の値を変更することを有する、
ことを特徴とする請求項１記載の方法。
【請求項３】
前記所定の変換規則は、前記マークアップ言語で記述された文書を該マークアップ言語で記述された別の文書に変換するための規則を定義することができる変換言語で書かれていることを特徴とする、請求項１記載の方法。
【請求項４】
請求項１記載の方法の各手順を実行するための命令を有するプログラム。
【請求項５】
前記サーバと前記クライアントが相互に離れているとき、該クライアントは、オブジェクト転送に関係する要求を該サーバへ送信するものであり、
前記サーバは、
サーバ・モジュールと、
処理モジュールと、
変換モジュールと、
を有し、
前記サーバ・モジュールは、前記要求を受信する機能と前記要求に対する応答を送信する機能を有し、
前記処理モジュールは、前記要求に対応した基本文書を検出する機能と、該検出した基本文書に関係する要求を前記サーバ・モジュールに送信する機能と、前記クライアントへ転送される前記オブジェクトの適合バージョンを格納するファイルを作成する機能と、前記作成されたファイルを、前記クライアントへ送信するため、前記サーバ・モジュールへ送信する機能を有し、
前記変換モジュールは、前記基本文書に関係する要求を前記サーバ・モジュールから受信する機能と、前記変換規則を選択し、前記選択した変換規則を前記基本文書に適用する機能と、前記適用する機能によって変換された文書を前記処理モジュールへ送信するため、前記変換された文書を前記サーバ・モジュールへ送信する機能と、を有する、
ことを特徴とする請求項１記載のファイルを転送する方法。
【請求項６】
前記要求は、前記サーバが前記クライアントのプロファイルを決定することを可能にさせ、
前記変換モジュールによって適用される変換規則は、前記プロファイルの関数である、ことを特徴とする請求項５記載のファイルを転送する方法。
【請求項７】
前記プロファイルは、前記サーバと前記クライアントの間の交渉段階を経て決定されることを特徴とする請求項６記載のファイルを転送する方法。
【発明の詳細な説明】
【０００１】
本発明は、オブジェクトの適合バージョンを含むファイルを、送信元エンティティから宛先エンティティへ転送する方法に関する。本発明は、オブジェクトの適合バージョンを含むファイルを作成する方法にも関する。
【０００２】
本発明は、更に、このようなファイル作成方法を実施するために適した機器と、このようなファイル転送方法を実施するために適した伝送システムと、に関する。
【０００３】
更に、本発明は、
マークアップ言語で書かれた文書と、
プログレッシブ・ファイルを格納する少なくとも一つのメイン・ボックス、及び、マークアップ言語で書かれた文書を格納する少なくとも一つのサイド・ボックスを含むボックスにフォーマットされたファイルと、
このような文書、又は、このようなファイルが保存される記憶媒体と、
に関する。
【０００４】
本発明は、インターネットの分野で特に興味深いアプリケーションが見出される。インターネットにアクセスできる機器の台数は増加し続けている。例えば、パーソナルコンピュータ、携帯電話機、携帯情報端末（ＰＤＡ）、ポータブルコンピュータ、ポケットコンピュータなどは、そのような機器の例である。これらの機器は、リソース（画面、計算能力、記憶容量など）に多少の制限があり、速度が変化するリンク（無線リンク、有線リンク、光リンクなど）を用いてインターネットに接続される。転送されるオブジェクトは、受信機のプロファイルに応じて適合させられるべきである。これにより、特に、受信機が使用できないようなデータを無駄に送信することが回避され、通過帯域を節約することが可能である。
【０００５】
1999年8月19日に公開された国際特許出願公開番号WO99/41734号には、プログレッシブ・セクションに編成されたグラフィック・ファイルと、このようなファイルを選択的に転送する方法とが記載されている。この方法では、受信側は、プログレッシブ・ファイル内で必要なセクションを指定する。
【０００６】
この方法では、受信側がグラフィック・ファイルの構造を知っていること、及び、受信側が獲得したい解像度若しくは品質に応じて、再生されるべきセクションを決定する方法を知っていること、が前提とされている。
【０００７】
本発明の目的は、特に、ユーザからの特定の情報を必要とはせずに、適合バージョンのオブジェクトを含むファイルを転送する方法を提案することである。
【０００８】
この目的を達成するため、冒頭の段落で説明した転送方法は、送信元エンティティがマークアップ言語で書かれた基本文書を保持するメモリを具備し、基本文書は基本バージョンのオブジェクトを格納する基本プログレッシブ・ファイルを記述し、当該方法は、
上記適合バージョンに応じて所定の変換を選択する手順と、
選択された変換を上記基本文書に適用し、変換された文書を作成する変換手順と、
上記変換された文書に基づいて上記オブジェクトの上記適合バージョンを格納するファイルを作成する手順と、
作成されたファイルを転送する手順と、
を有することを特徴とする。
【０００９】
このようにバージョンの適合は、送信元エンティティ側で行われる。従って、宛先エンティティ側で特別の知識が要求されることは無い。
【００１０】
本発明によれば、送信元エンティティは、マークアップ言語で書かれた基本文書を使用し、この基本文書は転送されるべき基本バージョンのオブジェクトを格納する基本プログレッシブ・ファイルを記述する。送信元エンティティは、一つ以上の変換された文書を獲得するため、この基本文書を適用対象とする一つ上の所定の変換を備えている。転送されるファイルは、獲得された変換後の文書から作成される。転送されるファイルは、転送される適合バージョンのオブジェクトを格納する。この適合バージョンは、基本バージョンとは異なる。
【００１１】
本発明は、特に、オブジェクトをマークアップ言語で記述し、記述された内容に変換を適用する。以下では、この記述された内容を文書と呼ぶ。このようなマークアップ言語を用いることによって、基本プログレッシブ・ファイルの構造を記述できるようになる。即ち、基本プログレッシブ・ファイルの構造は、得られた文書の中に現れる。従って、これらの文書に当てはまる変換を定義することが可能である。これらの変換は簡単な様式で表現され、これらの変換を使用するために必要な計算は少ない。
【００１２】
基本プログレッシブ・ファイルの構造が現れている文書に関して変換を実行することにより、基本プログレッシブ・ファイルを別のフォーマットに再符号化するため、基本プログレッシブ・ファイルを復号化する必要が無くなる。これにより、計算負荷がかなりの程度で制限される。
【００１３】
更に、本発明によれば、基本文書を送信元エンティティに保存するだけで十分であり、一部の実施例では、基本文書に由来する基本プログレッシブ・ファイル、及び、所定の変換も送信元エンティティに保存すれば足りる。転送されるファイルは、必要に応じて、適合した変換を適用することによって基本文書から作成される。したがって、転送されるファイルを送信元エンティティのメモリに保存する必要はない。かくして、送信元エンティティのレベルで保存されるべき情報量は非常に削減される。
【００１４】
本発明の好ましい一実施例では、基本文書は、タグによって区切られ、一つ以上の属性が与えられ得る一つ以上の要素を格納し、上記変換は、一つ以上の要素を抑制し、一つ以上の属性と一つ以上の要素のうちの少なくとも一方の値を変更する。
【００１５】
所定の変換は、有利的には、マークアップ言語で記述された文書を当該マークアップ言語で記述された別の文書に変換するための規則を定義することができる変換言語で書かれている。
【００１６】
一例として、マークアップ言語はＸＭＬ言語（拡張マークアップ言語）であり、変換言語はＸＳＬ言語（拡張スタイル・シート言語）であり、ＸＭＬ言語とＸＳＬ言語の両方はＷ３Ｃコンソーシアムによって規定されている。
【００１７】
本発明のもう一つの目的は、所与の文字の組を用いて、マークアップ言語で書かれた文書を提案することであり、この文書は、バイナリ・データ、マーカー、及び、一つ以上のマーカーに関連付けられたパラメータを格納するバイナリ・ファイルを記述する。本発明によれば、このような文書は、
・コンテンツと、一つ以上の属性と、一つ以上のサブ要素とのうちの少なくとも一つを格納する要素を含み、
・各マーカーに関連付けられた要素、上記要素のサブ要素若しくは属性を構成する上記マーカーに関連付けられる可能性のあるパラメータ、並びに、上記文字の形式である一つ以上の要素のコンテンツは、上記バイナリ・データと結び付けられている。
【００１８】
第１の実施例では、上記文書のコンテンツの少なくとも一部は、上記文字の組に変換された上記バイナリ・ファイルのバイナリ・データに対応する。
【００１９】
この第１の実施例では、文書は、バイナリ・ファイルとは独立している。なぜならば、文書自体がバイナリ・ファイルのデータを格納しているからである。しかし、バイナリ・データを文字に変換することは、これらのデータのある種の拡張を意味する。
【００２０】
第２の実施例では、上記文書のコンテンツの少なくとも一部は、上記バイナリ・ファイル内での上記バイナリ・データへの一つ以上のポインタに対応する。
【００２１】
この第２の実施例では、文書は、データにアクセスするためにバイナリ・ファイルに戻る。文書が記述するバイナリ・ファイルは文書に添付されていると役に立つ。本実施例では、データの拡張は無い。
【００２２】
本発明のもう一つの目的は、本発明によるファイル転送方法を実現するため有利に用いられる特定のバイナリ・ファイルを提案することである。
【００２３】
このようなバイナリ・ファイルは、ボックスの形式にフォーマットされ、バイナリ・ファイルは、少なくとも、
プログレッシブ・ファイルを含むメイン・ボックスと、
マークアップ言語で書かれ、上記プログレッシブ・ファイルを記述する文書を格納する少なくとも一つの補助的なボックスと、
を含む。補助的なボックスは、有利的には、上記文書を適用対象とする一つ以上の変換を格納する。
【００２４】
かくして、オブジェクトに関係するすべての情報は、単一のファイルに再編され、これは、ファイル管理の観点から見ると有利である。
【００２５】
このようなファイルは、例えば、ＪＰＥＧ２００ファイルである。本例の場合、補助的なボックスは、例えば、ＪＰＥＧ２０００標準に規定されたオプションのＸＭＬボックスによって構成される。補助的なボックスは、新しい専用のボックスによって構成してもよい。
【００２６】
送信元エンティティと宛先エンティティが互いに離れている場合、宛先エンティティは、有利的には、オブジェクト転送に関する要求を送信元エンティティへ送信しようとする。宛先エンティティは、
要求と要求に対する応答を送受信するサーバ・モジュールと、
オブジェクト転送に関係した要求を受信し、上記要求に対応した基本文書を見つけ出し、上記基本文書に関係した要求を上記サーバ・モジュールに送信し、転送されるオブジェクトの適合バージョンを格納するファイルを作成し、作成されたファイルを、宛先エンティティへ送信するため、サーバ・モジュールへ送信する処理モジュールと、
上記基本文書に関係する上記要求を上記サーバ・モジュールから受信し、変換を選択し、変換された文書を上記処理モジュールへ送信するため、変換された文書を上記サーバ・モジュールへ送信する変換モジュールと、
を含む。
【００２７】
更に、宛先エンティティによって送信された要求は、送信元エンティティが宛先エンティティのプロファイルを決定できるようにさせ、変換モジュールによって適用された変換は、上記プロファイルの関数である。例えば、上記要求は、送信元エンティティが宛先エンティティのプロファイルを決定できるようにするため、送信元エンティティと宛先エンティティの間の交渉フェーズを含む。
【００２８】
本発明は、送信元エンティティから宛先エンティティへある特定のバージョンのオブジェクトを転送する方法に関する。本発明による転送方法は、この転送のため使用されるバージョン（のオブジェクト）を作成するステップを含む。このバージョンの作成は、基本文書に基づいて行われる。基本文書は、マークアップ言語で書かれ、上記オブジェクトの基本バージョンを格納する基本プログレッシブ・ファイルを記述する。このステップは、変換された文書を作成することができる。最終的に、変換された文書は、適合バージョンと呼ばれるオブジェクトの別のバージョンを格納するファイルを作成するため使用される。このファイルが宛先エンティティへ転送されるファイルである。
【００２９】
図１は、本発明によるファイル転送方法のステップを概略的に説明するブロック図である。ブロックＢ１は、オブジェクトＯのある特定のバージョンに対応する基本プログレッシブ・ファイルＦ（Ｏ）を表す。ブロックＢ２は、マークアップ言語で書かれ、基本プログレッシブ・ファイルを記述する基本文書ＤＯＣ（Ｏ）を表す。ブロックＢ３−１乃至Ｂ３−Ｎは、変換された文書を作成するため、基本文書ＤＯＣ（Ｏ）に適用されることになっている変換ＴＲｉ（Ｏ）を表す。選択ステップＳは、オブジェクトＯに関するバージョンと、選択されたバージョンの関数である適用される変換と、を選択できるようにする。ブロックＢ４ｉは、変換ＴＲｉ（Ｏ）を基本文書ＤＯＣ（Ｏ）に適用することにより作成された変換後の文書ＤＯＣｉ（Ｏ）を表現する。最後に、ブロックＢ５ｉは、変換後の文書ＤＯＣｉ（Ｏ）から作成されたファイルＦｉ（Ｏ）を表現し、ファイルＦｉ（Ｏ）はオブジェクトＯの別のバージョンを格納する。最終的に、ステップＴにおいて、ファイルＦｉ（Ｏ）は宛先エンティティへ送信される。
【００３０】
このファイル転送方法は、基本ファイルのプログレッシブ性による利益を得る。このファイル転送方法は、オブジェクトの適合バージョンを作成するため操作できるようにするため、プログレッシブ基本ファイルのシンタックス（構文）を文書に記述する。
【００３１】
このような方法は、有利的には、送信元エンティティと宛先エンティティが互いに離れている本発明による伝送システムに使用される。このような伝送システムの一例は、図２に示されている。このシステムは、送信元エンティティと、少なくとも一つの宛先エンティティとを含み、送信元エンティティと宛先エンティティの各々は、インターネットにアクセスすることができ、これらのアクセスは同図に参照番号４及び５で示されている。
【００３２】
実際上、送信元エンティティは、１台若しくは多数の機械に拡散される。多数の機械に拡散されることにより、タスクを分散させ、送信元エンティティのレベルでの過負荷を防止することが可能になる。以下では、説明を簡略化するため、送信元エンティティは、サーバと呼ばれる１台の機械に収容されている場合を考える。
【００３３】
サーバ１は、メモリ１０及びプロセッサ組立体１２を含む。メモリ１０は、例えば、リード・オンリー・メモリＲＯＭ、ランダム・アクセス・メモリＲＡＭ、ハードディスクＨＤの形式であり、場合によっては、フレキシブルディスクタイプの着脱式記憶媒体ＦＤ、ＣＤ−ＲＯＭ、ＤＶＤなどの形式であり、これらの媒体を読み取る機能を備えたリーダーに挿入される。メモリ１０は、特に、
基本プログレッシブ・ファイルＦ（Ｏ）と、
基本プログレッシブ・ファイルを記述する基本文書ＤＯＣ（Ｏ）と、
基本プログレッシブ・ファイルを適用対象とする少なくとも一つの変換ＴＲｉ（Ｏ）と、
本発明によるファイル転送方法を実現するためプロセッサ１２による実行対象であるプログラムＰ１０の組と、
を含む。
【００３４】
クライアント機器２は、メモリ２０と、プロセッサ組立体２２と、画面２３と、例えば、キーパッド、音声コントロール、マウスなどを備えたユーザ・インタフェース２４と、を含む。メモリ２２は、例えば、リード・オンリー・メモリＲＯＭと、ランダム・アクセス・メモリＲＡＭとにより構成される。ある種のケースでは、メモリは、ハードディスクＨＤの形式や、着脱式記憶媒体ＦＤ、ＣＤ−ＲＯＭ、ＤＶＤなどの形式でもよく、着脱式記憶媒体は媒体に記憶されたデータを読み取る機能を備えたリーダーに挿入される。メモリ２２は、特に、本発明による転送方法を実現するためプロセッサ２２によって実行されるプログラムＰ２０の既知の組を格納する。
【００３５】
クライアント機器２は、通常の通り、インターネットに接続され、リソース識別子を含むＨＴＴＰタイプの要求を送出する（ＨＴＴＰは、ＩＥＴＦのＲＦＣ２６１６に規定されたネットワーク・プロトコルであり、リソース識別子のフォーマットは、ＩＥＴＦのＲＦＣ２３９６に規定されている。）。このリソースを収容する機器は、当該クライアント機器に対して、ＨＴＭＬ文書を転送することによって応答する。このＨＴＭＬ文書は、文書のコンテンツを機器の画面に表示させるため、クライアント機器によって解釈される（ＨＴＭＬは、コンテンツを記述するための言語であり、インターネット上で普及している言語であり、Ｗ３Ｃコンソーシアムによって規定されている。）。よく知られているように、ＨＴＭＬ文書は画面に表示する対象のページを記述し、このようなページは、ユーザがある特定のオブジェクトを格納しているファイルをダウンロードするため選択するリンク（例えば、ボタン若しくはアイコンの形式）を格納している。ユーザがこのようなリンクを選択したとき、クライアント機器は、ファイルの転送を依頼するためＨＴＴＰタイプの要求を送信する。
【００３６】
図３には、送信元エンティティ１のソフトウェア構造の一例が示されている。図３によれば、送信元エンティティ１は、サーバ・モジュール３０と、処理モジュール３２と、変換モジュール３４の三つのソフトウェア・モジュールを含む。サーバ・モジュール３０は、例えば、ＡＰＡＣＨＥ（ＡＰＡＣＨＥは、Apacheソフトウェア財団によって開発されたｈｔｔｐサーバである。）という名称で知られているモジュールの形式である。サーバ・モジュールは、ある種の要求を他のモジュールへ送信するように構成される。サーバ・モジュール３０は、プログレッシブ・フォーマット（例えば、ＪＰＥＧ２００ファイル）を有するファイルに関係した要求を処理モジュール３２へ送信し、マークアップ言語で書かれたファイル（例えば、ＸＭＬファイル）に関係する要求を変換モジュール３４へ送信する。変換モジュール３４は、例えば、ＣＯＣＯＯＮという名称で知られているモジュールにより形成される（ＣＯＣＯＯＮは、ＡＰＡＣＨＥ  ＸＭＬプロジェクトにおいてＪａｖａ（Ｒ）言語で開発されたアプリケーションである）。
【００３７】
処理モジュール３２は、特に、宛先エンティティによる送信要求に示されたプログレッシブ・ファイル・フォーマットに対応した基本文書ＤＯＣ（Ｏ）を見つけ出す機能と、この基本文書ＤＯＣ（Ｏ）に関係する要求をサーバ・モジュール３０へ送信する機能と、を備えている。サーバ・モジュール３０は、この要求を受信すると、変換モジュール３４によって処理されるべきマークアップ・フォーマット（例えば、ＸＭＬ）を認識し、その要求を変換モジュール３４へ送信する。
【００３８】
変換モジュール３４は、変換された文書ＤＯＣｉ（Ｏ）を生成するため、基本文書ＤＯＣ（Ｏ）を復元し、基本文書ＤＯＣ（Ｏ）に適用される変換ＴＲｉ（Ｏ）を選択する機能を備えている。変換モジュール３４は、変換された文書ＤＯＣｉ（Ｏ）をサーバ・モジュール３０へ返し、サーバ・モジュール３０は、変換された文書ＤＯＣｉ（Ｏ）を処理モジュール３２へ送信する。
【００３９】
処理モジュール３２は、転送されるオブジェクトの適合バージョンを格納するバイナリ・ファイルＦｉ（Ｏ）を作成し、サーバ・モジュール３０がそのオブジェクトを宛先エンティティ２へ送信できるようにそのオブジェクトをサーバ・モジュール３０へ返す機能を備えている。
【００４０】
図３には、送信元エンティティ１から宛先エンティティ２へ適合バージョンを転送するために必要な種々のステップが、番号付きの矢印で示されている。
【００４１】
矢印Ｆ１は、宛先エンティティ２によるオブジェクトの転送に関係する要求の送信を表現する。
【００４２】
ステップＦ２では、サーバ・モジュール３０は、宛先エンティティから送信された要求を受信し、プログレッシブ・フォーマットを認識し、その要求を処理モジュール３２へ送信する。
【００４３】
ステップＦ３では、処理モジュールは、プログレッシブ・フォーマットに対応した基本文書を見つけ出し、当該文書に関係する要求ｈｔｔｐ  ＧＥＴを出す。基本文書を復元するため、処理モジュールは、暗黙的な規則を適用するか（例えば、転送されるオブジェクトを含むファイルの名前がimage.jp2であるとき、関連したＸＭＬ文書の名前はimage.xmlであると決定する）、又は、明示的な規則を適用する（例えば、各基本プログレッシブ・ファイルに関連付けられた基本文書の名前を格納した対応関係のテーブルが利用できる。）。
【００４４】
ステップＦ４では、サーバ・モジュール３０は、基本文書に関係する要求を変換モジュール３４へ送信する。
【００４５】
ステップＦ５では、変換モジュール３４は、基本文書を復元し、変換を選択し、変換された文書を作成するため選択された変換を適用し、変換後の文書をサーバ・モジュール３０へ返す。
【００４６】
ステップＦ６では、サーバ・モジュール３０は、変換モジュール３４によって返された変換後の文書を処理モジュール３２へ送信する。
【００４７】
ステップＦ７では、処理モジュール３２は、変換後の文書に基づいて、転送されるオブジェクトの適合バージョンを格納したバイナリ・ファイルを作成し、作成されたバイナリ・ファイルをサーバ・モジュール３０へ返す。
【００４８】
最後に、ステップＦ８において、サーバ・モジュール３０は、オブジェクトの適合バージョンを格納したファイルを宛先エンティティ２へ送信する。
【００４９】
３種類のモジュールが別々の機械に収容されている場合、有利的には、三つのモジュールのすべては、本発明による転送方法を実現するために必要なデータ、即ち、より具体的には、
基本プログレッシブ・ファイルＦ（０）と、
これらの基本プログレッシブ・ファイルを記述する基本文書ＤＯＣ（Ｏ）と、
基本プログレッシブ・ファイルを適用対象とする変換ＴＲｉ（Ｏ）と、
が記憶されている同じディスクにアクセスすることができる。
【００５０】
処理モジュール３２及び変換モジュール３４は、例えば、「サーブレット」、即ち、サーバ上で実行されることが予定されているＪａｖａ（Ｒ）言語で開発されたアプリケーションである（例えば、ｃｏｃｏｏｎはサーブレットである。）。
【００５１】
次に、図３を参照して説明したサーバ・クライアント型アーキテクチャが使用されている本発明によるファイル転送方法の様々なアプリケーションを説明する。
【００５２】
図４に示されたアプリケーションの第１例によると、クライアント２によって送信された要求Ｊ１は、サーバ１がクライアント２のプロファイルＰＰを決定できるようにさせる。第１の実施例（図示せず）では、要求Ｊ１は、クライアント２のプロファイルＰＰを直接的に指定する。図４に示された第２の実施例では、サーバ１が要求Ｊ１を受信したとき、サーバ１は、交渉フェーズＪ２を開始することによって応答する。サーバ１（より厳密には、サーバ１の変換モジュール３４）は、クライアントのプロファイルＰＰに応じて、適切なファイルを作成するため、基本文書ＤＯＣ（Ｏ）に適用される変換を選択する。一例として、このような交渉フェーズは、1998年にＩＥＴＦによって発行された、"Transparent Content Negotiation in HTTP"という名称のＲＦＣ２２９５に記載されているタイプの交渉フェーズ、又は、1999年10月10日に無線アプリケーション・プロトコル・フォーラム(Wireless Application Protocol Forum)によって発行された文献"Wireless Application Group, User Agent Profile Specification"に記載されているタイプの交渉フェーズである。
【００５３】
アプリケーションの第２例は、ウェブ・ページが低解像度のオブジェクト（屡々、画像）を含み、クライアントが同じオブジェクトの完全な解像度のものをダウンロードするため、そのオブジェクトをクリックする場合に関係する。この場合、サーバ１の変換モジュール３４は、クライアントが既に使用したデータを補完するデータだけを格納するファイルを作成するため、特定の変換を適用する。
【００５４】
アプリケーションの第３例は、同じウェブサイト上で、画像が、異なるフォーマットで、或いは、異なる解像度で、数回に亘って（例えば、異なるページに）提供される場合に関係する。クライアントがページ間で行き来するとき、サーバは、同じ画像の様々なバージョンを次から次へと送信させられる。変換モジュール３４は、望ましいバージョンを作成するために適切な変換を毎回適用するので、送信された様々な画像バージョンをサーバに保存する必要はない。
【００５５】
本発明は、図３に示されたタイプのクライアント・サーバ型アーキテクチャを使用する形態に限定されない。本発明は、ユーザによってローカルに使用されるオブジェクトの適合バージョンを格納するファイルを作成する方法にも関係する。例えば、このようなファイル作成方法は、有利的には、大きい画像に基づいて小さい画像を作成しようとするユーザによって使用される。
【００５６】
本発明は、例えば、マルチメディア・オブジェクト、即ち、固定画像、音声又は映像に適用される。
【００５７】
このタイプのオブジェクトのあるバージョンを格納しているファイルは、例えば、ＪＰＥＧ２０００フォーマット、ＧＩＦフォーマット、又は、ＭＰＥＧ４フォーマットのファイルである。以下の説明中、これらのファイルは、バイナリ・ファイルとしてみなされる。なぜならば、物理的に、これらのファイルは、任意のビットシーケンスとして現れるからである。
【００５８】
プログレッシブ・ファイルは、ファイルの一部だけを復元することによってオブジェクトの低品質バージョンを獲得できるように編成される。プログレッシブ性には様々な種類が存在する。より多くのデータを復元することにより、例えば、信号の品質を高め、より大きいサイズの画像を取得し、階調画像ではなくカラー画像を取得し、映像のフレーム周波数を増加させることなどが可能になる。例えば、ＪＰＥＧ２０００ファイルは、プログレッシブ・ファイルである。
【００５９】
画像ファイルのある種のフォーマットは、画像ファイルに格納されている画像の低品質バージョン（屡々、小サイズのバージョン）である「サムネイル」を画像ファイルに取り込むことが可能である。例えば、Exif2.1ファイル（"Digital Stll Camera Image File Format Standard; Exchangeable image file format for Digital Still Cameras: Exif, Version 2.1", 1998年6月12日、日本電子工業振興協会(JEIDA)）は、その一例である。このタイプのファイルは、本発明におけるプログレッシブ・ファイルである。このタイプのファイルに関連した基本文書は、一方で、サムネイルを記述し、他方で、画像を記述する。例えば、基本文書からサムネイルに関係した一部を抽出できる変換が定義されるので、サムネイルを記述する変換後の文書が作成され、変換後の文書は当該サムネイルを格納したバイナリ・ファイルを作成するために使用されることになる。
【００６０】
一般的に、マークアップ言語は、データセットの構文を記述するために、タグを利用し、これらのタグの用法を規定する言語を意味していると考えられる。このような言語は、データセットを構造化し、データセットの構造をデータセットの内容から分離することが可能である。
【００６１】
ＸＭＬは、このようなマークアップ言語の典型的な例である。ＸＭＬの長所は、インターネットの世界で広範に亘って使用されていることである。ＸＭＬの別の長所は、ある程度の数のツール、特に、ＸＭＬ文書に適用可能な変換を定義することができるＸＳＬＴという名称のツールを提供することである。変換の定義は、ＸＳＬＴスタイル・シートを用いて行われる。ＸＳＬＴ変換の場合、ＸＳＬＴプロセッサは、ＸＭＬ文書とＸＳＬＴスタイル・シートを読み、別の文書、例えば、ＸＭＬ文書を作成する。ＸＭＬ及びＸＳＬＴは、このように、本発明を実施するために特に適している。
【００６２】
以下の説明では、具体的な例を挙げるため、ＪＰＥＧ２０００フォーマットのファイルを記述する文書を作成するためにＸＭＬ言語が使用される。しかし、このような例に限定されるものではない。別のタイプのマークアップ言語と他のプログレッシブ・ファイル・フォーマットを使用してもよい。
【００６３】
ＪＰＥＧ２０００標準は、"JPEG 2000 Final Draft International Standard"というタイトルの文書ISO/IEC FCD 15444-1に記載されている。
【００６４】
主要なＪＰＥＧ２０００符号化ステップは、
ａ）Ｙがルミナンスを表し、Ｃｒがクロミナンス成分赤を表し、Ｃｂがクロミナンス成分青を表すとき、空間Ｙ−Ｃｒ−Ｃｂでの画像の表現を得るため入力画像をオプション的に変換するステップと、
ｂ）画像成分のウェーブレット変換ステップと、
ｃ）獲得された係数の定量化ステップと、
ｄ）符号化ステップと、
ｅ）ある種のプログレッシブ方式に従って、獲得されたデータをビットストリームに挿入するステップと、
を有する。
【００６５】
符号化すべき画像が非常に大きい場合、予備ステップは、画像を、相互に独立して符号化される様々なタイルに分割することができる。以下では、説明を簡単化するため、画像が単一のタイルにより構成されている場合に限定する。しかし、このような場合に限定されるものではない。
【００６６】
ＪＰＥＧ２０００は、解像度と、品質と、空間位置と、成分とを用いた４通りの基本プログレッシブ方式を使用する。ＪＰＥＧ２０００は、これらの基本方式の５通りの組み合わせを提案する。各プログレッシブ方式は、データをビットストリーム内で順序付ける特定の方式に対応する。
【００６７】
ビットストリームは、パケットヘッダと、符号化により得られた有効なデータを収容するパケットを含む。有効なデータの各パケットは、成分（ｉ）と、レイヤ（ｊ）と、解像度のレベル（ｋ）と、パーティション位置（ｍ）とに対応する。ビットストリームは、四つのループを用いて構築される。ループの順番は、使用されるプログレッシブ方式を決定する。
【００６８】
成分によるプログレッシブ性を備えたビットストリームの場合、４個のループの順番は、例えば、成分毎、解像度毎、レイヤ毎、パーティション位置毎の順番で、パケットをビットストリームに書き込む。解像度によるプログレッシブ性を備えたビットストリームの場合、４個のループの順番は、例えば、解像度毎、成分毎、レイヤ毎、パーティション位置毎の順番で、パケットをビットストリームに書き込む。以下の説明では、これらの２通りのプログレッシブ性の例に限定されているが、本発明は、あらゆるタイプのプログレッシブ性に適用可能である。
【００６９】
ＪＰＥＧ２０００の用語では、画像に関係するすべての情報は、コードストリームに合成される。コードストリームは、メイン・ヘッダと、一つ以上のタイル部ヘッダとを含み、各タイルヘッダ部は、後にビットストリームが続き、エンドマーカーによって終了する。メイン・ヘッダ及びタイル部ヘッダは、マーカーとマーカー・セグメントに編成される。最終的に、コードストリーム自体は、バイナリ・ファイルに格納される。
【００７０】
図５は、ＪＰＥＧ２０００コードストリームの一例の構造の説明図である。このコードストリームＣＳは、メイン・ヘッダ１００から始まり、メイン・ヘッダ１００は、マーカーＳＯＣ（コードストリームの始まり）と、マーカー・セグメントＳＩＺ（画像及びタイルのサイズ）と、ＣＯＤ（符号化スタイルデフォルト）と、ＱＣＤ（量子化デフォルト）と、を含む。コードストリームＣＳは、次に、タイル部ヘッダ１１０を含み、タイル部ヘッダ１１０は、マーカー・セグメントＳＯＴ（タイル部の始まり）と、マーカーＳＯＤ（データの始まり）と、を含む。コードストリームＣＳは、最後に、ビットストリーム１２０を含む。ビットストリーム１２０は、オプションとして、パケットの先頭にマークを付けるため使用されるマーカーＳＯＰ（パケットの始まり）が先行する種々のパケットの形式である。コードストリームＣＳは、エンドマーカーＥＯＣ（コードストリームの終わり）によって終了する。ここで使用されている名称は、ＪＰＥＧ２０００勧告で使用されている名称である。より詳細には、マーカーは、２個のオクテットからなるコードである。マーカー・セグメントは、マーカーと、マーカーに関連付けられたパラメータと、を含む。
【００７１】
次に、ＸＭＬ言語ベースについて説明する。この言語は、1998年2月10日に発行されたＷ３Ｃコンソーシアムの勧告REC-xml-19980210に記載されている。
【００７２】
物理的な観点から、ＸＭＬ文書は、解析可能なエンティティと、解析できないエンティティと、を含む。解析可能なエンティティは、テキスト、即ち、タグ若しくはテキストデータを表現し、所定の文字集団に属する文字のシーケンスを格納する。解析できないエンティティは、テキスト以外のもの、或いは、ＸＭＬテキストではないテキストを含む。
【００７３】
論理的な観点から、ＸＭＬ文書は、一つ以上の要素を含み、要素の境界は、オープニングタグとクロージングタグによってマークされている。要素は、相互にインターリーブしていても構わない。各要素は名前によって識別される。要素はコンテンツを収容してもよい。属性詳細の組を要素に関連付けることも可能である。各属性詳細は、名前と値を含む。同一のスタートタグに同じ属性名が複数回現れることはない。
【００７４】
次に、ＸＭＬ言語を用いてＪＰＥＧ２０００コードストリームを構築する方法を説明する。
【００７５】
本例では、ＪＰＥＧ２０００ファイルの各マーカー・セグメント用のＸＭＬ要素を作成するため、以下の規則を適用することによって選択が行われる。
・要素はマーカーの３文字コードの名前をとって命名される。
・マーカーの長さ、マーカーの値、並びに、可能であればマーカーに関連付けられた他のパラメータが要素の属性として定義される。
・パラメータ若しくはパラメータグループが繰り返されるとき、属性の代わりにサブ要素が作成される。なぜならば、ＸＭＬ言語は、同一スタートタグ内の同一名に２個以上の属性が与えられること（本例では、例えば、マーカー・セグメントＳＩＺが画像の各成分に対して繰り返される３個のパラメータＳｓｉｚ、ＸＲｓｉｚ及びＹＲｓｉｚのグループによって終端されること）を許可しないからである。
・ビットストリームのパケットは要素のコンテンツの形式で文書に組み込まれる。
【００７６】
しかし、ビットストリームは、全くのバイナリ・データにより構成されるので、（ある種の明瞭な文字だけを許容する）ＸＭＬ文書にビットストリームをそのまま組み入れることは不可能である。
【００７７】
第１の実施例では、ビットストリームは文字に変換される。この目的のため、有利的には、「ベース６４」という名称で知られている符号化方法が使用される。「ベース６４」は、ＩＥＴＦによって発行された文書RFC2045の第6.8節に記載されている。この方法は、ビットストリームを、６ビットのグループに分割し、６ビットの各グループに、アルファベット文字からの文字を関連付ける。この方法は、データを３３％ずつ拡張するという欠点がある。
【００７８】
第２の実施例では、ビットストリームを文字に変換し、ＸＭＬ文書に挿入するのではなく、ポインタがＸＭＬ文書に導入され、このポインタは、基本ファイルの中でバイナリ・データを格納している領域を指定する。本実施例では、ＸＭＬ文書は、基本ファイルに依存する。
【００７９】
非限定的な例として、例１には、成分によるプログレッシブ性を説明する図５に表されたＪＰＥＧ２０００コードストリームを記述するＸＭＬ文書が掲載されている。本例の場合、パケットの内容は、１ラインだけを占有するように切り捨てられている。
【００８０】
次に、画像の改良バージョンを記述する変換されたＸＭＬ文書を作成するため、ＸＭＬ文書に適用される変換の二つの例を説明する。変換には、一般に、基本ＸＭＬ文書のある種の要素を抑制すること、並びに、コードストリーム集合の一貫性が保たれるように、ある種の属性とある種の要素のうちの少なくとも一方の値を変更することが含まれる。
【００８１】
変換の第１例は、成分プログレッシブ性を用いて符号化された画像に適用可能な変換であり、カラー画像から階調画像まで通用する。このような変換は、クロミナンス成分に対応するビットストリームのパケットを抑制（隠蔽）する。この目的のため、この変換は、
・クロミナンスパケットに対応する要素ＳＯＰを抑制するステップと、
・クロミナンス成分に関係した属性Ｓｓｉｚ、ＸＲｓｉｚ及びＹＲｓｉｚを格納する要素を抑制するステップと、
・成分の個数を示す要素ＳＩＺの属性Ｃｓｉｚを変更するステップと（旧い値３→新しい値１）、
・マーカー・セグメントＳＩＺのサイズを示す要素ＳＩＺの属性ＭａｒｋＳｅｇＬｅｎを変更するステップと（旧い値３８＋３．３＝４７→新しい値３８＋３．１＝４１）と、
を含む。
【００８２】
このような変換は、有利的には、ＸＳＬスタイル・シートに定義されている。非限定的な例として、例２には、例１に掲載されたＸＭＬ文書に適用されるＸＳＬスタイル・シートが掲載されている。
【００８３】
変換の第２例は、解像度によってプログレッシブ符号化された画像に適用される変換であり、大きいサイズの画像から小さいサイズの画像までの変化を許容する。このような変換は、獲得されるべき解像度の数を定義する入力パラメータＮｒｅｓｏｕｔを使用する。この変換は、Ｎｒｅｓｏｕｔよりも高い解像度に対応するビットストリームのパケットを抑制する。この目的のため、この変換は、
・Ｎｒｅｓ、ＮｃｏｍｐおよびＮｌａｙｅｒｓがそれぞれプログレッシブ基本ファイルで使用される解像度の数、成分の数及びレイヤの数を表すとき、ビットストリームの（Ｎｒｅｓ−Ｎｒｅｓｏｕｔ）．Ｎｃｏｍｐ．Ｎｌａｙｅｒｓの最後のパケットに対応する要素ＳＯＰを抑制するステップと、
・画像のサイズに関係する要素ＳＩＺの属性を変更するステップ（属性Ｘｓｉｚ、ＸＴｓｉｚ、Ｙｓｉｚ及びＹＴｓｉｚに含まれる値を２Nres-Nresoutで除算）と、
・分割レベルの数に関係した要素ＣＯＤの属性を変更するステップ（ｎＤｅｃｏｍｐＬｅｖｅｌ＝Ｎｒｅｓｏｕｔ）と、
・要素ＱＣＤの属性Ｓｑｃｄによって示された定量化スタイルに応じて、最後の要素ＳＰｑｃｄを抑制するステップと、
・属性ｍａｒｋＳｅｇＬｅｎを要素ＱＣＤと適合させるステップと、
を含む。
【００８４】
上述の変換の２例は限定的な例ではない。本発明は、他のタイプの変換にも適用される。例えば、レイヤによってプログレッシブ符号化された画像に適用され、種々の信号対雑音比を得ることができる変換を定義してもよい。
【００８５】
図６は、本発明によるＪＰＥＧ２０００フォーマットのバイナリ・ファイルの一例の説明図である。図６によると、ＪＰＥＧ２０００フォーマットのバイナリ・ファイルＦＦは、本発明における基本プログレッシブ・ファイルを構成するコードストリームＣＳを格納したメイン・ボックスＢＸ１を含む。ＪＰＥＧ２０００フォーマットのバイナリ・ファイルＦＦは、ＤＯＣという名称のＸＭＬ文書を格納した補助的なボックスＢＸ２を更に含む。文書ＤＯＣは、コードストリームＣＳを記述する。補助的なボックスＢＸ２は、更に、文書ＤＯＣを適用対象とし、ＴＲという名前が付けられた変換ＸＳＬを格納している。
【００８６】
【表１】
0004824266.tif 000002
【００８７】
【表２】
0004824266.tif 000003
【００８８】
【表３】
0004824266.tif 000004
【００８９】
【表４】
0004824266.tif 000005
【００９０】
【表５】
0004824266.tif 000006
【図面の簡単な説明】
【図１】  本発明によるファイル転送方法の種々のステップを説明するブロック図である。
【図２】  本発明による伝送システムの一例の構成図である。
【図３】  本発明による伝送システムのサーバのソフトウェア構造の一例の説明図である。
【図４】  図３に示されているようなクライアント・サーバ型アーキテクチャを利用する本発明によるファイル転送方法のアプリケーションの一例の説明図である。
【図５】  ＪＰＥＧ２０００コードストリームの概略的な説明図である。
【図６】  本発明によるバイナリ・ファイルの一例の概略的な説明図である。
【図１】
0004824266.tif 000007
【図２】
0004824266.tif 000008
【図３】
0004824266.tif 000009
【図４】
0004824266.tif 000010
【図５】
0004824266.tif 000011
【図６】
0004824266.tif 000012