(57)【要約】本発明は、画像データと他のデータとの交信のためのシステムを具備する。本システムは、JPEGデータを有するJPEGファイル、少なくとも1つのJPEGでないデータとコンピュータとを具備する。コンピュータは、あらかじめ定められたシーケンシャルバイト数のJPEGでないデータを読み込むことがプログラムされている。またコンピュータは、JPEGマーカーを含んでおり、ローケーターバイトを決定するシーケンシャルバイトにおいて、各バイトの位置を決定するようにプログラムされている。ここで、ローケーターバイトはJPEGマーカーを含むシーケンシャルバイトにおけるすべてのバイトの位置を表示することができる。コンピュータはさらに、ローケーターバイトをJPEGファイルに書き込み、エンコードされたバイトをJPEGファイルに書き込むことがプログラムされている。コンピュータは、シーケンシャルバイトの各バイトに対して、もしそのバイトがJPEGマーカーを含んでいなければ、シーケンシャルバイトにおいて、このようなバイトが発生した順に、各バイトを好ましくは０と書かれたビットに置き換えるようなやり方で、JPEGファイル内にエンコードされたバイトを書きこむ。もしそのバイトがJPEGマーカーを含んでいる場合は、JPEGマーカーを含むバイトは、シーケンシャルバイトにおいてこのようなバイトが発生した順に、好ましくは1と書かれたホールダービットに置き換えられる。
2004532548.tif 000002
【特許請求の範囲】
【請求項１】
JPEGファイル内にJPEGでないデータを保存する方法であって、
（Ａ）JPEGでないデータにおいて、あらかじめ定められた数のシーケンシャルバイトを読み込むステップと、
（Ｂ）当該シーケンシャルバイトにおいて、JPEGマーカーを含む各バイトの位置を決定するステップと、
（Ｃ）JPEGマーカーを含むシーケンシャルバイトの各バイトの位置を表示することができるローケーターバイトを決定するステップと、
（Ｄ）エンコードされたバイトを決定するステップと、
を含み、
エンコードされたバイトには、
（ａ）ローケーターバイトと、
（ｂ）JPEGマーカーを含まないシーケンシャルバイトの各バイトと、
（ｃ）JPEGマーカーを含むシーケンシャルバイトの各バイトに対するプレースホールダーバイトと、
を具備する方法。
【請求項２】
エンコードされたバイトをあらかじめ定められた順番に書きこむステップを含む、請求項１に記載の方法。
【請求項３】
ローケーターバイトが最も目立つ位置に書きこまれる、請求項２に記載の方法。
【請求項４】
シーケンシャルバイト内でその発生順にシーケンシャルバイトが書きこまれ、プレースホールダーバイトが置き換えたバイトの順にプレースホールダーバイトが書きこまれる、請求項２に記載の方法。
【請求項５】
エンコードされたバイトがJPEGファイル中に書きこまれる、請求項２に記載の方法。
【請求項６】
JPEGファイル中のエンコードされたバイトの前にアプリケーションデータマーカーを書きこむステップをさらに含む、請求項５に記載の方法。
【請求項７】
あらかじめ定められた数のシーケンシャルバイトの数は７である、請求項１に記載の方法。
【請求項８】
JPEGマーカーは０ｘＦＦを含む、請求項１に記載の方法。
【請求項９】
プレースホールダーバイトには０ｘ００を含む、請求項１に記載の方法。
【請求項１０】
プレースホールダーバイトは０ｘ００から０ｘ７Ｆの間である、請求項１に記載の方法。
【請求項１１】
０ｘ００のローケーターバイトは、シーケンシャルバイトがどれもJPEGマーカーを含まないことを示す、請求項１に記載の方法。
【請求項１２】
JPEGでないデータには、音声データを含む、請求項１に記載の方法。
【請求項１３】
請求項１において、さらに、
（Ａ）JPEGファイル中にアプリケーションデータマーカーを置くステップと、
（Ｂ）JPEGファイル中の当該アプリケーションデータマーカーの後にエンコードされたバイトを書きこむステップと、
を含む、請求項１に記載の方法。
【請求項１４】
請求項１において、さらに、
（Ａ）請求項１におけるＡからＤまでのステップをすべてのJPEGでないデータについて繰り返すステップと、
（Ｂ）エンコードされたバイトの総数を決定するステップと、
（Ｃ）もしエンコードされたバイトの総数がJPEGフィールド長を超えていた場合は、
（ａ）エンコードされたファイルをセグメントに分割し、各セグメントにおけるバイト数を最大JPEGフィールド長より短くするステップと、
（ｂ）セグメントをJPEGファイル中に書きこむステップと、
を含む、請求項１に記載の方法。
【請求項１５】
エンコードされたバイトと共にJPEGファイルを記録するステップをさらに含む、請求項１３に記載の方法。
【請求項１６】
ローケーターバイト及びエンコードされたバイトと共にJPEGファイルを伝送するステップをさらに含む、請求項１３に記載の方法。
【請求項１７】
請求項１３において、さらに、
（Ａ）JPEGファイル中のエンコードされたバイトを読み込むステップと、
（Ｂ）ローケーターバイトを決定するステップと、
（Ｃ）ローケーターバイトからエンコードされたバイト中のプレースホールダーバイトの位置を決定するステップと、
（Ｄ）各プレースホールダーバイトをJPEGマーカーを含んだバイトに変換し、それによりエンコードされたバイトをデコードしシーケンシャルバイトを得るステップと、
を含む、請求項１３に記載の方法。
【請求項１８】
アプリケーションプログラム中に、シーケンシャルバイトを使うステップをさらに含む、請求項１７に記載の方法。
【請求項１９】
シーケンシャルバイトを記録するステップをさらに含む、請求項１７に記載の方法。
【請求項２０】
JPEGファイルにコントロールデータを書きこむステップをさらに含み、当該コントロールデータはJPEGでないデータに関連したものである、請求項１３に記載の方法。
【請求項２１】
画像データ及び他のデータと交信を行うシステムであって、
（Ａ）JPEGデータを含有するJPEGファイルと、
（Ｂ）JPEGでないデータと、
（Ｃ）コンピュータと、
を備え、
当該コンピュータは、
（ａ）JPEGでないデータにおいて、あらかじめ定められた数のシーケンシャルバイトを読み込むステップと、
（ｂ）当該シーケンシャルバイトにおいて、JPEGマーカーを含む各バイトの位置を決定するステップと、
（ｃ）JPEGマーカーを含むシーケンシャルバイトの各バイトの位置を表示することができるローケーターバイトを決定するステップと、
（ｄ）エンコードされたバイトを決定するステップと、
ここで、エンコードされたバイトには、
（i）ローケーターバイトと、
（ii）JPEGマーカーを含まないシーケンシャルバイトの各バイトと、
（iii）JPEGマーカーを含むシーケンシャルバイトの各バイトに対するプレースホールダーバイトと、
を備え、
（ｅ）JPEGファイル中にエンコードされたバイトを書きこみ、エンコードされたバイトはあらかじめ定められた順番に書きこむステップと、
を含むコンピュータである、
画像データ及び他のデータと交信を行うシステム。
【請求項２２】
コンピュータと交信する伝送装置であって、エンコードされたバイトと共にJPEGファイルを送信するよう構成された伝送装置をさらに備える請求項２１に記載のシステム。
【請求項２３】
コンピュータと交信する画像データ入力装置であって、JPEGデータを提供するよう構成された画像データ入力装置をさらに備える請求項２１に記載のシステム。
【請求項２４】
前記画像データ入力装置にはディジタルカメラを含む、請求項２３に記載のシステム。
【請求項２５】
コンピュータと交信するJPEGでないデータの入力装置であって、JPEGでないデータを提供するよう構成されたJPEGでないデータの入力装置をさらに備える請求項２１に記載のシステム。
【請求項２６】
前記JPEGでないデータの入力装置には音声記録装置を含む、請求項２１に記載のシステム。
【請求項２７】
前記コンピュータはアプリケーションデータマーカーの後のJPEGファイル中にエンコードされたファイルを書きこむようさらにプログラムされている、請求項２１に記載のシステム。
【請求項２８】
前記コンピュータはJPEGファイル中に、JPEGでないデータと関係があるコントロールデータを書きこむようさらにプログラムされている、請求項２１に記載のシステム。
【請求項２９】
請求項21に記載のシステムであって、前記コンピュータと交信する２番目のコンピュータを備え、当該２番目のコンピュータは、
（Ａ）JPEGファイル中のエンコードされたバイトを読み込むステップと、
（Ｂ）ローケーターバイトを決定するステップと、
（Ｃ）ローケーターバイトからエンコードされたバイト中のプレースホールダーバイトの位置を決定するステップと、
（Ｄ）各プレースホールダーバイトをJPEGマーカーを含んだバイトに変換し、それによりエンコードされたバイトをデコードしシーケンシャルバイトを得るステップと、
を実行するよう構成されたコンピュータである、請求項21に記載のシステム。
【請求項３０】
前記コンピュータはJPEGでないデータを用いるよう構成された請求項２６に記載のシステム。
【請求項３１】
JPEGファイル中にJPEGでないデータを保存する方法であって、
（Ａ）JPEGでないデータを読み込むステップと、
（Ｂ）JPEGでないデータのどのバイトがあらかじめ定められたJPEGマーカーを包含するかを決定するステップと、
（Ｃ）エンコードされたバイトを決定するステップと、
を含み、
エンコードされたバイトは、
（ａ）JPEGマーカーを具備しないJPEGでないデータの各バイトと、
（ｂ）あらかじめ定められたJPEGマーカーを具備するJPEGでないデータの各バイトのプレースホールダーバイトと、
（ｃ）少なくとも１つのローケーターバイトであって、どのエンコードされたバイトがプレースホールダーバイトであるかを表示することができるローケーターバイトと、
を具備する、JPEGファイル中にJPEGでないデータを保存する方法。
【請求項３２】
あらかじめ定められた順序で、エンコードされたバイトを書きこむステップをさらに含む請求項３１に記載の方法。
【請求項３３】
ローケーターバイトが最も目立つ位置に書きこまれる、請求項３２に記載の方法。
【請求項３４】
エンコードされたバイトがJPEGファイル中に書きこまれる、請求項３２に記載の方法。
【請求項３５】
JPEGファイル中のエンコードされたバイトの前にアプリケーションデータマーカーを書きこむステップをさらに含む、請求項３４に記載の方法。
【請求項３６】
JPEGマーカーは０ｘＦＦを含む、請求項３１に記載の方法。
【請求項３７】
プレースホールダーバイトは０ｘ００を含む、請求項３１に記載の方法。
【請求項３８】
０ｘ００のローケーターバイトは、JPEGでないデータのどのバイトもJPEGマーカーを含まないことを示す、請求項３１に記載の方法。
【請求項３９】
JPEGでないデータには音声データを含む、請求項３１に記載の方法。
【請求項４０】
請求項３１において、さらに
（Ａ）JPEGファイル中にアプリケーションデータマーカーを置くステップと、
（Ｂ）JPEGファイル中に当該アプリケーションデータマーカーの後にエンコードされたバイトを書きこむステップと、
を含む、請求項３１に記載の方法。
【請求項４１】
請求項３１において、さらに、
（Ａ）エンコードされたバイトの総数を決定するステップと、
（Ｂ）もしエンコードされたバイトの総数がJPEGフィールド長を超えていた場合は、
（ａ）エンコードされたファイルをセグメントに分割し、各セグメントにおけるバイト数を最大JPEGフィールド長より短くするステップと、
（ｂ）セグメントをJPEGファイル中に書きこむステップと、
を含む、請求項３１に記載の方法。
【請求項４２】
エンコードされたバイトと共にJPEGファイルを記録するステップをさらに含む、請求項３４に記載の方法。
【請求項４３】
ローケーターバイト及びエンコードされたバイトと共にJPEGファイルを伝送するステップをさらに含む、請求項３４に記載の方法。
【請求項４４】
請求項３４において、さらに、
（Ａ）JPEGファイル中のエンコードされたバイトを読み込むステップと、
（Ｂ）ローケーターバイトを決定するステップと、
（Ｃ）ローケーターバイトからエンコードされたバイト中のプレースホールダーバイトの位置を決定するステップと、
（Ｄ）各プレースホールダーバイトを、JPEGマーカーを含んだバイトに変換し、それによりエンコードされたバイトをデコードしシーケンシャルバイトを得るステップと、
を含む、請求項３４に記載の方法。
【請求項４５】
アプリケーションプログラム中に、シーケンシャルバイトを使うステップをさらに含む、請求項３４に記載の方法。
【請求項４６】
JPEGファイルにコントロールデータを書きこむステップをさらに含み、当該コントロールデータはJPEGでないデータに関連したものである、請求項３４に記載の方法。
【発明の詳細な説明】
【０００１】
関連特許
本出願は、２００２年５月１５日付け米国出願出願と２００１年５月１９日付け米国出願、暫定的出願番号６０／２７７，６０９に基づく優先権の利益を主張する。
【０００２】
発明の背景
発明の分野
本発明は、JPEGファイルデータ保存システム及び方法に関する。
【０００３】
関連技術の説明
JPEGファイル
JPEGとは、ディジタル画像データを圧縮、保存及び伝達するために用いられるファイルフォーマットの標準である。ここで使われているとおり、「JPEG」という用語は、「JPEG」及び「JPEG2000」を含むすべてのバージョン、修正版、及び公開されたフォーマットに適用される。このフォーマットは、ジョイント・フォトグラフィック・エキスパートグループにより開発され、現在最も人気があり広く使われている画像フォーマットである。JPEGの利点の一つは、一般的に使われるどんなビットマップ・フォーマットに対しても最大限に圧縮し、装置やユーザーが最小限の保存スペースを使って画像ファイルを保存することが出来るようにすることである。この圧縮能力は、JPEGが、インターネットを使って画像を送信するときのフォーマットとして最も一般的に使われるようになっているJPEGの特徴の１つでもある。ユーザーは、他の多くのフォーマットより高い画像の質を保ちながら、より高速度にJPEG画像を伝送し受け取ることができる。
【０００４】
JPEGフォーマットはファイルをセグメントに分割するマーカーを使う。マーカーは０ｘＦＦの値を持つ最初のバイトを具備する。JPEG・マーカーは、２つの一般的なタイプすなわちスタンドアローンとデータとにグループ分けすることができる。スタンドアローン・マーカーは２バイトのマーカー以外のデータは持たない。データ・マーカーはこのマーカーの直後に、データのバイト数を示す２バイトが付随する。例えば、データ・マーカーは以下のように現れる。
【０００５】
０ｘＦＦ  ０ｘＮＮ  ０ｘＣＨ  ０ｘＣＬ
この例では、０ｘＦＦはJPEGセグメントまたはフィールドの始まりを示し、０ｘＮＮはフィールドのタイプを表示し、そして０ｘＣＨと０ｘＣＬは合わせてフィールドの長さを示している。このマーカーにはデータやインストラクションを付随させても良い。
【０００６】
対象となる画像のデータに加えて、JPEGは、JPEGでないデータやアプリケーションデータをJPEGファイルの中に蓄えられるようにすることができる。このアプリケーションデータは、画像データを使うアプリケーション以外のアプリケーション用データを含んでいても良い。例えば、画像をとらえたカメラのセッティングあるいは画像を作った者の身元を示すデータをJPEGファイルに挿入することができる。このように、JPEGの利点の一つは、対象となる画像データ以外のデータをJPEGファイル自身に保存し伝送することができる点である。
【０００７】
任意のデータをJPEGファイルに組み込むことは多くの実際のユーザーに提供されている。例えば、静止画像や写真は、恐らくはその写真について説明する人の声である音声ファイルとともに、インターネットを介して伝送することができる。このことは、家族が家族のメンバーの声と写真を共有すること、不動産業者が不動産の写真をその不動産を説明する声と共に提供すること、医療専門家が診断画像を音声による診断や説明と共に提供すること、及び、その他さまざまな用途に使うことを可能にする。
【０００８】
しかし、JPEGファイルにアプリケーションデータを保存することに関連する問題の１つは、アプリケーションデータはマーカーコードを含むことが出来ないことである。例として、デコーダーがアプリケーションデータにおける０ｘＦＦをJPEGマーカーとして読み込む場合があり、このことが修復不可能なデコーディングのプロセスの失敗をもたらす。もしJPEGファイル中のアプリケーションデータがマーカーコードを含んでいたら、そのマーカーはJPEGデコーダーを壊してしまうので、そのファイルは使用できなくなる。
【０００９】
この問題の一つの解決手段は、アプリケーションデータからすべての０ｘＦＦのインスタンスあるいは他のマーカーコードを取り除くことである。このことによりデータの蓄積が可能となり、JPEGデコーダーを壊す恐れなしにJPEGファイル内に送り込むことができる。しかし、もし１以上のマーカーコードがアプリケーションデータから取り除かれたなら、そのデータは、通常は大きく改変され目的のアプリケーションプログラムに使うことが出来なくなる。
【００１０】
それゆえに、JPEGファイルにデータが蓄積されているときにアプリケーションデータからマーカーコードを取り除き、アプリケーションプログラムを使用するときデータをそのオリジナルの状態に戻すための、システム及び方法のニーズが存在する。
【００１１】
オーディオファイルと画像ファイルの結合
任意のデータとJPEGファイルとを結合する技術は存在する。例えば、サウンドの付加されたディジタル画像を創りたいと望むユーザーは画像ファイルに別のオーディオ、例えば、wavファイルを付け加えることができる。しかしwavファイルは、伝達または蓄積される時に、しばしば簡単に書き換えられ消去されてしまう。wavファイルに関するもう一つの問題は、保存し使用するためにマイクロソフト（登録商標）のメディアソフトウエアのような特別なソフトウエアを必要とすることである。
【００１２】
他の任意のデータとJPEGファイルとを結合する技術は、Ota他により発行された米国特許番号5,032,918、及びHashimoto他により発行された米国特許番号5,815,201により公開された技術に含まれている。ここでは、オーディオファイルと画像ファイルとは別々に記録されお互いに結合される。オータその他により公開された発明の欠点の1つは、2つの別々のファイルを保持することが必要とされる点である。これは、特に大容量のファイルを扱うとき、あるいは長時間にわたって実行されるときに、大変煩わしく結合関係を失いやすいものである。
【００１３】
McIntyre他により発行された米国特許番号6,102,505は不可視性のインクにより画像データとオーディオデータとの永久的な結合を作り出すものである。Akamine他により発行された米国特許番号5,644,557及びNozaki他により発行された欧州特許番号EP0964304A1は、各々、フィルム上の磁気による記録及びフィルム上の光ピクセルによるデータ記録を公開している。Akamine他及びNozaki他に関連する問題の1つは、オーディオデータのハードコピーを蓄えるために物理的にフィルムを必要とすることであり、これはディジタル画像データには十分適したものではない。
【００１４】
他のオーディオデータと画像データを蓄積する技術は、Paoliniにより発行された米国特許番号5,276,866により公開された発明に含まれており、ここでは、オーディオデータはビデオストリームの中の画像フレームとして蓄えられ、そして圧縮される。Case他により発行された米国特許番号5,440,677は、関連付けて再生することを可能とするファイルを付加してCD-ROMにオーディオファイルと画像ファイルを蓄積する技術を公開している。PaoliniとCase他についての問題は、先の特許と同様、データを回復、表示あるいは再生の前に、データの送信及び受信の双方ために特別なプログラムが必要なことである。
【００１５】
つまり、画像データとアプリケーションデータの結合において本来的に備わっているファイルの保守の必要性を削減するニーズが存在している。また、インターネットのような種々の媒体を介して効率的にまた便利に伝達できるような、アプリケーションデータと画像データの永久的な結合を作り出すことのニーズも存在している。さらに、効率的にまた便利にアプリケーションデータと画像データを結合し画像データを１つのファイルにすることのニーズも存在している。アプリケーションデータと画像データの保存、回復、表示、あるいは使用のために、特別なあるいはあまり広く使われていないアプリケーションを必要とせず、アプリケーションデータを画像データとともに保存することのニーズもさらに存在している。
【００１６】
発明の概要
本発明の利点
本発明の利点の１つは、画像データの添付されたアプリケーションデータの信頼性のある保存ができることである。
【００１７】
本発明の他の利点は、画像デーコーダーと相いれないアプリケーションデータを画像データと共に保存できることである。
【００１８】
本発明の他の利点は、画像データとアプリケーションデータの結合において本来的に必要とする保守を削減することである。
【００１９】
本発明の他の利点は、アプリケーションプログラムに既存のアプリケーションを検出させることで、画像データとアプリケーションデータを結合させ1つのファイルにするシステム及び方法を提供することである。
【００２０】
本発明の他の利点は、JPEGデコーダーがデータ０ｘＦＦを含むアプリケーションデータを読み込んだとき、JPEGデコーダーの回復不可能な失敗を防止する点である。
【００２１】
本発明の他の利点は、マーカーコードのインスタンスを取り除き、同時に、元のアプリケーションデータの信頼性の高い再構築を可能とする順序、保全及び識別データを具備するデータを提供することである。
【００２２】
本発明の他の利点は、アプリケーションデータと画像データの保存、回復、表示、あるいは使用のために、特別なあるいはあまり広く使われていないアプリケーションを必要とせず、アプリケーションデータを画像データとともに保存するシステムと方法を提供することである。
【００２３】
本発明の他の利点は、アプリケーションデータを復活させるデコーディングメカニズムを提供することである。
【００２４】
本発明の他の利点は、各JPEGアプリケーションレコードの最初の部分に付加的なデータレコードを挿入するエンコーディングメカニズムを提供することである。
【００２５】
本発明の他の利点は、アプリケーションではない多くのデータを、少なくとも1つの画像ファイルに永久的に結合させることである。
【００２６】
本発明の他の利点は、データを失うことなく、元のデータをエンコードすることである。
【００２７】
本発明の他の利点は、元のデータをエンコードするあいだ、再生パラメータ、言語識別、複数トラック情報、タイミング、その他の付加的な情報を含む元のデータを保存することである。
【００２８】
本発明の他の利点は、受信システムがアプリケーションデータを無視したとしても、コンピュータが画像データにアクセスできるようにしていることである。
【００２９】
本発明の他の利点は、音声と共にディジタル画像を提供することである。
【００３０】
本発明の他の利点は、修正したアプリケーションデータの安全性を保障するような方法で、アプリケーションを画像ファイルに保存する方法を提供することである。
【００３１】
本発明の他の利点は、アプリケーションデータの再構築を可能とする画像ファイル内のマーカーを提供することである。
【００３２】
本発明の他の利点は、画像ファイル中に、画像ファイルの最大フィールド長さより長いデータを保存する方法を提供することである。
【００３３】
本発明の他の利点は、再生アプリケーションにより使用可能なデータを画像ファイルの中に著相する方法を提供することである。
【００３４】
本発明のこれらや他の利点は、本明細書の残りの部分、請求の範囲及び要約を参照することにより実現される。
【００３５】
発明の簡単な説明
本発明は、画像データと他のデータとの交信のためのシステムを具備する。本システムは、JPEGデータを有するJPEGファイル、少なくとも1つのJPEGでないデータとコンピュータとを具備する。コンピュータは、あらかじめ定められたシーケンシャルバイト数のJPEGでないデータを読み込むことがプログラムされている。またコンピュータは、JPEGマーカーを含んでおり、ローケーターバイトを決定するシーケンシャルバイトにおいて、各バイトの位置を決定するようにプログラムされている。ここで、ローケーターバイトはJPEGマーカーを含むシーケンシャルバイトにおけるすべてのバイトの位置を表示することができる。コンピュータはさらに、ローケーターバイトをJPEGファイルに書き込み、エンコードされたバイトをJPEGファイルに書き込むことがプログラムされている。コンピュータは、シーケンシャルバイトの各バイトに対して、もしそのバイトがJPEGマーカーを含んでいなければ、シーケンシャルバイトにおいて、このようなバイトが発生した順に、各バイトを好ましくは０と書かれたビットに置き換えるようなやり方で、JPEGファイル内にエンコードされたバイトを書きこむ。もしそのバイトがJPEGマーカーを含んでいる場合は、JPEGマーカーを含むバイトは、シーケンシャルバイトにおいてこのようなバイトが発生した順に、好ましくは1と書かれたホールダービットに置き換えられる。
【００３６】
以上の説明は、以下に述べる最適実施例の詳細な説明が良くわかり、本発明の技術に対する寄与度がより理解できるように、本発明の重要な特徴を広く述べたものである。本発明は、以下に述べるようにまた特許請求の範囲の対象となる付加的な特徴が有ることは言うまでもない。この点について、本発明の少なくとも1つの最適実施形態の詳細説明にあたって、本発明は以下の説明に述べられ、図面に記載されたような構成や要素の組合せに限定されて適用されるものではないということは了解されるべきである。本発明は、他の実施形態が可能であり種々の方法で実行され実施され得るものである。また、ここで使われる用語や述語は説明目的のためのものであり発明を限定するものと解釈するべきでないことは了解されるべきである。
【００３７】
好ましい実施の形態の詳細な説明
以下の好ましい実施の形態についての詳細説明中の添付図面について言及する。この図面は本出願の一部をなす。本図面は、説明図という形で、本発明が実行されたときの具体的形態を示すものである。本発明の範囲から外れることなく他の実施形態や構成要素の変更が可能であることは了解されるべきである。
【００３８】
本発明は画像データと共にアプリケーションデータを保存するシステムと方法からなり、概念的に参照番号１０に示されている。本方法は、一般に、画像データとアプリケーションデータの収集２２、１つの単独JPEGファイルの生成２４、及び画像データとアプリケーションデータの表示および／あるいは使用２６とで構成される。
【００３９】
入力データの収集
入力データは画像データ１００とアプリケーションデータ１０４とから成る。本発明の１つの用途として、アプリケーションデータ１０４はオーディオファイルを包含する。他のアプリケーションデータとして、テキスト、ワープロドキュメント、Eメールメッセージ、スプレッドシート、人事ファイル、指紋、その他を含むことができる。アプリケーションデータは当該技術分野で周知のあらゆるディジタルフォーマットであってもよい。
【００４０】
図１の上部に例示したように、画像データとアプリケーションデータを収集するのに用いる装置はディジタルカメラ１０２である。画像ファイル入力１００はJPEG圧縮フォーマットで保存されることが好ましい。カメラ１０２は、マイクロフォン、アナログからディジタルへのコンバーター、プロセッサー、及びメモリーのような音声をディジタルで記録する装置で構成される。
【００４１】
ひとたび画像ファイル入力１００と音声ファイル入力１０４を手に入れると、入力ファイルは単独JPEGファイル３２に変換される。
【００４２】
アプリケーションデータのエンコード
図２に示すように、画像ファイル１００とアプリケーションデータ１０４とを結合して単独JPEGファイル３２にするため、アプリケーションデータをエンコードし２８、データを解析し２９、もし必要ならエンコードされたアプリケーションデータを画像データと結合させエンコードされたアプリケーションデータが組み込まれた単独JPEGファイルを形成する３２。アプリケーションデータのエンコーディングステップ２８は、一般にバイト０ｘＦＦを含むエンコードされていないアプリケーションデータ中のすべてのバイト位置を決定するステップを有し、バイト０ｘＦＦのすべての位置を示す少なくとも１つのローケーターバイトを決定し、そのデータからバイト０ｘＦＦを除去する。
【００４３】
図３に示すように、本発明におけるエンコーディングプロセスは、データのあらかじめ定められたシーケンシャルバイトの数値を評価することから始まる。好ましい実施の形態においては、アプリケーションデータファイル１０４から７バイトのシーケンシャルデータが評価される。ローケーターバイト１１５が７個のシーケンシャルバイト１１２に付け加えられる。デコーディングを簡単にするために、ファイルの記憶において、７個のシーケンシャルバイトにローケーターバイトを先行させる。ローケーターバイト１１５は、バイト０ｘＦＦを含むエンコードの前に７個のシーケンシャルバイト中のその位置を指示するために使われる。ローケーターバイト１１５と７個のシーケンシャルバイトは結合されて８バイトのパケットを形成する。
【００４４】
図４及び図５はローケーターバイト１１５の値を決定する１つの方法を図示したものである。この方法によれば、マスク値１１６が７個のシーケンシャルバイトの各バイト位置に割り付けられる。マスク値１１６の最上位ビット１１３はローケーターバイト１１５が０ｘＦＦにならないことを確かなものにするため、ゼロにすることが好ましい。演算手順はまず、最初のバイトについてバイト０ｘＦＦが含まれていないかどうかを決定するためのテストを行う１２０。このバイト値が含まれていない場合は、そのテスト結果は「偽」ということになり、ポインターは次のバイトポジションにシフトする１２２。この例では、図３及び図４に示されており、最初のバイトは０ｘ０１である。従って、テストは「偽」ということになりポインターは２番目のバイトに移動し、結果は００００００００となる。２番目のバイトは０ｘ２２なので、ポインターは３番目のバイトに移動し、結果は００００００００を維持する。
【００４５】
このテストとシフトプロセスはバイトテストが「真」となるか又は７個すべてのバイトについてテストが完了するまで繰り返される１２８。図３及び図４に示された例では、ポインターはテスト結果が「真」となるまでに５ポジションシフトされるであろう。テストが「真」のとき、演算手順はフラグビット１をマスク１１６により示される位置にセットする１２６。したがって、結果１１７は０００００１００となる。６番目のバイト位置では、テストは「偽」となり結果は変化しない。７番目のバイト位置では、テストは「真」となり結果は０００００１０１となる。この結果はローケーターバイト１１５の値として使われ、これは、本例では、１６進数表示での０ｘ０５に対応する。もし、７個のシーケンシャルバイトのどれにもバイト０ｘＦＦが含まれていなければ、ローケーターバイトの値は０ｘ００となる。
【００４６】
図３に示すように、いったんローケーターバイト１１５の値が決定されると、このローケーターバイトはシーケンシャルバイト１１２と結合される。しかし、０ｘＦＦを含むどんなバイトも０ｘ００に変換され、あらかじめ定められたプレースホールダーバイト１２８となる。０ｘＦＦを含まないバイトは同じ値を維持する１３０。同時に、これらの８バイトはアプリケーションデータのエンコードされたパケットを形成する１３１。
【００４７】
０ｘＦＦを除去し、ローケーターバイトを加えたので、０ｘＦＦが存在することによるファイルの破壊は避けられ、同時に、元のデータの完全性は保たれる。もちろん、ローケーターバイトの値１１５を決めるために用いることができる別の付番方法や別の演算手順を用いても良い。このような変更も本発明の範囲内である。
【００４８】
画像データ１００に関しては、画像データは、離散コサイン変換（ＤＣＴ）とハフマンエンコーディングのようなJPEG方式を使ってエンコードすることができる。
【００４９】
エンコードされたパケットのJPEGファイルへの挿入
エンコードの後、エンコードされたパケット１３１は画像ファイルの位置に挿入され、単独JPEGファイルを生成する。図６に示すように、JPEGレコードは、最初のバイトがＦＦ（１３２）、２番目がヘッダータイプバイト（１３４）、３番目（１３６）４番目のバイト（１３８）が結合されて、長さバイトを含む１６ビット長のレコードとなるようなフォーマットに従う。エンコードされたパケット１３１は既存のJPEGパケット１４０，１４４の間に挿入することができる。図７に示すように、JPEGヘッダー１３２、アプリケーションヘッダータイプ０ｘＥＡ（１３４）、１０バイトの長さバイト１３６，１３８及び８バイトのエンコードされたアプリケーションデータとから成る新しいJPEGパケットは、２つの既存のJPEGパケット１４０（図６参照），１４４の間に挿入される。
【００５０】
当業者は、もしデータがJPEGフォーマットに課せられた６５，５３５バイトの制限を越える場合、正しい順序にデータを再構成するための仕組みを実行する必要があることを理解するだろう。また当業者は、このようなアプリケーションデータを読み込むシステムは、他のアプリケーションが同じヘッダーコードを使っていた場合でも、既存のデータを信頼度高く検出することができなければならないことを理解するだろう。特にJPEGは１６のアプリケーションコードの使用を許すが、JPEG2000は１つだけであることを考慮すれば、その通りである。
【００５１】
本発明は、これらの懸案事項に対して各JPEGアプリケーションレコードの先頭に追加のデータレコードを挿入することで対処している。これらのヘッダーには順序、セキュリティ手段、及び識別データが含まれ信頼度高く元のアプリケーションファイルを再構築できるようにしている。追加されたヘッダー情報はさらに、組み込まれたデータファイルの検出を可能とする役割、元のデータの変更の追跡を可能とする役割、そして再生アプリケーションに使われる情報の提供を行う役割を果たす。追加されたヘッダーはデータ保存構造の体裁を取ることができ、ここではこれをブロックと呼ぶ。ブロックタイプは、JPEGに準拠し、JPEGデータを壊さないことを担保するために、少なくとも最初の１２バイトの後は、ＦＦコードを除去することが好ましい。各ブロックにあるバイトの意味及びバイト数はプログラミングの対象に応じて変化させて良いのはもちろんである。ここで表１にインデックスブロックが示される。
【００５２】
【表１】
2004532548.tif 000003
【００５３】
インデックスブロックはファイル全体に適用可能なグローバル情報を含んでいる。バイト１−１２は挿入されたデータを自動的に検出させる。ASCII文字列をレコード内（バイト５−１２）に置くことは、エディターでファイルを見るときに、再生アプリケーションが音声／画像ファイルを特定することを容易にさせる。もし再生アプリケーションが識別レコードを見つけなければ、画像は普通に表示される。もし音声IDが検出されたら、その音声データはヘッダーから読み込まれ、単純な音声ファイルとして再構築される。画像は音声データを取り除くことなく表示される。なぜなら、０ｘＦＦは取り除かれており、現状の復元システムが音声パケットをアプリケーションデータとして特定することができ画像表示に影響を与えることなくスキップすることができるからである。
【００５４】
画像とデータ文書の結合に何らかの変更がなされていた場合にエラーフラグが表示されるような安全担保及びディジタル透かしをパケット（バイト１７及び１８）に加えても良い。この機能により暗号キーのようなデータを用いることができ、調査し、探求し、あるいは証拠写真を用いて警察への正式な報告を作成するのに実用的であろう。
【００５５】
バイト２０−２１及び２２−２４はオプションであり、将来のプログラム・オブジェクトを完成させるために留保しておく。バイト２５−Ｎは、情報の読解能力のあるアプリケーションソフトに、処理を行わせるために拡張された情報を意味する。拡張ファイル情報のフラグタイプは拡張ファイル情報が始まることを明らかにするため０ｘＦＥとするのが好ましい。２番目のバイトは長さフィールドとし０ｘＦＥあるいは０ｘＦＦを含まないようにするのが好ましい。拡張情報は、情報を読解できないアプリケーションが、従うべき情報のタイプを表示する識別子及びデータを読み飛ばすことができるように、長さ表示を含むことが好ましい。表２は拡張されたファイル情報のタイプのいろいろな識別子を示す。すべての識別子は０ｘＦＥに先導されて情報のタグや長さ表示に拡張されるのが好ましい。
【００５６】
【表２】
2004532548.tif 000004
【００５７】
例えば、複数言語のファイルを伴う場合を想定する。０１のＥＦＩタイプIDは、ファイルに複数言語が組み込まれた場合を表示する。０ｘ０１のタイプは、このファイルに存在する相異なる言語の数を記載するバイトが後に続くことを表示する。従って、５言語のファイルについての拡張ファイル情報領域は、０ｘＦＥ  ０ｘ０２  ０ｘ０１  ０ｘ０５のようになる。したがって、拡張ファイル情報を用いることは書式に柔軟性を持たせ、将来の追加事項を扱う上での拡張性を与える。
【００５８】
追加のヘッダーはさらにヘッダーブロックにより成り立つ。ヘッダーブロックはJPEGファイルに含まれるすべてのファイルデータを有している。このデータは、例えば、音声データとスライドショーのための画像データを含む。データには、ワードプロセッシングファイル、スプレッドシート、及び他のランダムなデータもまた含むことができる。ヘッダーブロックとしての基本１４バイトは下記表３に示される。
【００５９】
【表３】
2004532548.tif 000005
【００６０】
データ書式タグ（バイト５−１２）はそれに続くデータのタイプを定義する8ビットのテキストフィールドを使うことが好ましい。音声データは、SPXAUDIOとして表現するのが好ましい。画像データは、SPXIMAGE、SPXTRADEまたはSPXTHUMBとして表現するのが好ましい。テキストデータは、SPXTEXTとして表現するのが好ましい。サポートされていないファイルデータは、SPXEXTRAとして表現しファイルデータブロックに置くのが好ましい。データ書式タグはさらに多くのデータタイプを組み込むことができ、また、与えられたデータタイプをどう処理するかを再生システムに知らせる。例えば、MSWORD（登録商標）のデータフォーマットタグのデータと共にワードドキュメントをファイルに組み込むことができる。これは、同一又はそれより高いバージョンの再生装置にMSWORD（登録商標）書式タグを認識させ、データを直接マイクロソフトワードに送信する。
【００６１】
さらに画像データヘッダーを含む追加ヘッダーは下記表4に示される。
【表４】
2004532548.tif 000006
2004532548.tif 000007
【００６２】
さらにファイルデータヘッダーを含む追加ヘッダーは下記表５に示される。
【表５】
2004532548.tif 000008
【００６３】
さらにテキストデータヘッダーを含む追加ヘッダーは下記表６に示される。
【表６】
2004532548.tif 000009
【００６４】
さらにユーザーデータブロックを含む追加ヘッダーは下記表７に記載される。ユーザーデータブロックは、ユーザーが各種の情報を蓄えることを可能とする。具体的には、このフィールドタイプは、画像タイトルなどのユーザーが選ぶ情報やメタデータに使うことを想定している。説明フィールドは、開発者がこの領域に蓄えられたデータに意味のある名前を割り当てる事を可能とする。データフィールドには情報を蓄えることが好ましい。データフィールドに蓄えられたすべての情報はXMLフォーマットになっていることが好ましい。このフォーマットは、この領域に複数のパラメータを蓄えることを可能とし、ユーザーにデータを蓄える上での自由度を与える。例えば、ユーザーが「Summer 2001」のタイトルを蓄えようとするとき、データ領域に<Title>Summer 2001＜/Title＞を入力する。この特徴を説明フィールドと共に使えば、ユーザーは関連するデータをグループにして1つのデータブロックにまとめ1つの状態に保持できる。
【００６５】
【表７】
2004532548.tif 000010
【００６６】
追加ヘッダーはさらにデータブロックを含む。データブロックはヘッダーブロックに記載されたデータを保存する。下記表8に示すように、IDフィールドを用い、シーケンスフィールドと共同して、アプリケーションは関連するヘッダーブロックから与えられた情報をベースに、データを首尾よくデコードするとともに、採るべきアクションを認識する。
【００６７】
【表８】
2004532548.tif 000011
【００６８】
図8に示すとおり、表１‐８に記載した追加ヘッダーはJPEGアプリケーションマーカー１３２で始まるJPEGファイルに挿入される。示された実施例では、追加ヘッダーはインデックスヘッダー１４６とデータ書式１４８の形をとっている。
【００６９】
出力として違った形式のプレゼンティングファイル
組み込まれた単一のJPEGファイル存在すると、それは再生装置２６に送信される。再生装置は、パーソナルコンピュータ、携帯情報端末（PDA）、携帯電話、トーキングピクチャーフレームのような特別なアプリケーションプレーヤー、等の少なくとも画像データを表示する能力があるものが好ましい。ファイルは、ディスクやEメールあるいは他の情報伝達手段を介して、カメラやディスプレイ装置あるいはアプリケーションコンピュータにも転送することができる。
【００７０】
デコーディングにおいては、再生装置２６は組み込まれたデータを検出し、JPEG画像データから切り離し、デコードしてもとのデータフォーマットに戻し、出力として２つのファイルを表示する。図９は本発明のデコード方法を示す。再生装置２６はローケーターバイト１１５をテストすることによりエンコードされたデータの読み込みを開始する（１４４）。もしローケーターバイト１１５が０ｘ００なら、再生装置２６は続く7バイトを変更せずに転送する１４６。再生装置２６は残りの一連のデータを読み込む。もしローケーターバイト１１５が０ｘ００でないなら、再生装置２６はローケーターバイト１１５の各ビットをテストする（１４８）。もしビットが1なら、対応するバイトは０ｘFFに設定される（１５０）。もしビットが1でないなら、再生装置２６はすべての７ビットがテストされるまで残りのビットをテストする（１５２，１５４）。
【００７１】
JPEGに組み込まれたアプリケーション
以下に列挙するのはJPEGに組み込まれたランダムなデータに対する実用的ないくつかのアプリケーションである。JPEGに組み込まれたランダムなデータが音声ファイルであるとき、静止画像は、演奏可能な音声ファイルと共に、コンピュータやPDAあるいは携帯電話のような装置に表示することができる。静止画像と音声ファイルとが１つのJPEGに結合されていると、視聴者は、画像として描かれているものについての説明を聞くために、画像をクリックすることができる。音声による説明は、インターネットオークションやカタログサイトからの製品の宣伝や実際の不動産の宣伝、開発活動、家族活動、調査、あるいはニュースレターであっても良い。研究者あるいは調査員は、仲間が成果を見ている間に、所見や分析を音声により聞かせるために、画像ファイルに音声ファイルを付加することができる。画像は、X線のスキャン、超音波スキャン、特別な装置により収集された画像ファイル、その他公知のディジタル画像の形式とすることができる。音声コンテンツを介して画像の検索と類別を行うシステムを提供するため、スピーカーを識別するための音声とスピーカー認識ソフトウェアが本発明に含まれていても良い。本発明のシステムを、ユーザーが、保存されたサムネイルや保存された縮減画像あるいはオリジナル画像から選択できるようにすると共に、ユーザーがオリジナル音声あるいは縮減された音声から選択して演奏するように構成しても良い。
【００７２】
JPEGでないデータが、違った言語による複合スピーチのような多数の音声ファイルを含んでいる場合、本発明によれば、ユーザーが保存した環境あるいはアクセスを提供したサイトあるいは最も良く使用されている言語のユーザーが使う環境のいずれかにより特定された言語で、ユーザーが音声を保存し演奏することができる。次に、任意のデータが時間に関係付けられたデータを含むとき、音声の再生と同時に特定の時間に多数の画像を保存しあるいは表示することができる。あるいは、多数の音声ファイルが特定の開始時刻に再生されるようにしても良い。これはスライドショーを作る上で最も現実的である
秘密書類、ID写真、セキュリティ・データ、テキスト、他の画像、個人的なファイル、表計算シート、あるいは指紋によるバイオメトリクスなどの任意のデータは１つの画像データとし、ペーパーレス記録又はペーパーレスデータベースとしても良い。
【００７３】
任意のデータが、レーザーによるスキャンその他の方法で得た３次元の立体モデルの情報を含んでいる場合、このような任意のデータを、画像として保存されたビジュアルイメージと結合することができ、それにより、立体モデルにビジュアルイメージをマッピングさせ、さらにリアルなモデルにすることができる。
【００７４】
結論
本発明は先行技術に関連する多くの問題を解決する。本発明はさらにアプリケーションに関連付けられた新しい独特のJPEGを提供する。本発明は画像ファイルと共に任意のデータを高信頼度で保存することを可能とする。本発明は画像ファイルとアプリケーションデータとを結合したときに固有のメンテナンスの必要性を低減する。さらに本発明は、コンピュータが入力データに０ｘFFが含まれているアプリケーションデータを読み込んだ場合に修復不可能な障害の発生を防止すると共に、組み込まれたデータの検出を可能とするヘッダーを提供し、オリジナルのアプリケーションファイルの信頼度の高い再構築を可能とし、再生アプリケーションに利用可能な情報を提供し、データに施されたどんな変更も追跡可能としている。
【００７５】
以上の通り詳細に説明したが、以上の説明は発明の範囲を制限するものと解釈すべきではなく、単に本発明の現在の最適実施例を説明したものと解釈すべきである。したがって、本発明の範囲は、記載の実施例ではなく添付の請求の範囲及びその法的な均等物により決定されるべきである。
【図面の簡単な説明】
【００７６】
【図１】図１は本発明に係るシステム及び方法を概念的に示す構成図である。
【図２】図２は画像データとアプリケーションデータを含むJPEGファイルの作成過程を概念的に示す構成図である。
【図３】図３は本発明のエンコーディングプロセスの一例を概念的に示した図である
【図４】図４は本発明のエンコーディングプロセスの一例を概念的に示した図である
【図５】図５は本発明の０ｘＦＦを検出するプロセスを概念的に示したフローチャートである。
【図６】図６は１６進数フォーマットのJPEGファイルの概念的な一例である。
【図７】図７は本発明によりエンコードされたアプリケーションデータが付加されたJPEGファイルの概念的な一例である。
【図８】図８は本発明によりマルチプルエンコードされたアプリケーションセグメントが付加されたJPEGファイルの概念的な一例である。
【図９】図９は本発明によるデコーディングプロセスの概念的な部分である。
【図１】
2004532548.tif 000012
【図２】
2004532548.tif 000013
【図４】
2004532548.tif 000014
【図５】
2004532548.tif 000015
【図９】
2004532548.tif 000016
【国際公開パンフレット】
2004532548.tif 000017
2004532548.tif 000018
2004532548.tif 000019
2004532548.tif 000020
2004532548.tif 000021
2004532548.tif 000022
2004532548.tif 000023
2004532548.tif 000024
2004532548.tif 000025
2004532548.tif 000026
2004532548.tif 000027
2004532548.tif 000028
2004532548.tif 000029
2004532548.tif 000030
2004532548.tif 000031
2004532548.tif 000032
2004532548.tif 000033
2004532548.tif 000034
2004532548.tif 000035
2004532548.tif 000036
2004532548.tif 000037
2004532548.tif 000038
2004532548.tif 000039
2004532548.tif 000040
2004532548.tif 000041
2004532548.tif 000042
2004532548.tif 000043
2004532548.tif 000044
2004532548.tif 000045
2004532548.tif 000046
2004532548.tif 000047
2004532548.tif 000048
2004532548.tif 000049
2004532548.tif 000050
2004532548.tif 000051
2004532548.tif 000052
2004532548.tif 000053
2004532548.tif 000054
2004532548.tif 000055
2004532548.tif 000056
2004532548.tif 000057
2004532548.tif 000058
【国際公開パンフレット（コレクトバージョン）】
2004532548.tif 000059
2004532548.tif 000060
【国際調査報告】
2004532548.tif 000061