(57)【要約】  メディアファイルを含むファイルのメタデータの変更または改ざんを検知できるように、メディアファイルを含むファイル内のメタデータを処理するための方法及びシステム（並びに関連するデータ構造）が開示されている。ある実施形態によれば、メタデータは、コンテンツサーバによって生成されたハッシュ値とデジタル署名とを含む。これらハッシュ値とデジタル署名は、クライアントによりメタデータを認証するために用いることができる。【選択図】図３【特許請求の範囲】
【請求項１】
メタデータから構成される第一の部分と、メタデータ以外のデータから成る第二の部分とを有するファイル内のメタデータを処理する方法であって、前記方法は：
前記ファイル内の１番目の位置へ保存されるように適合された第一のメタデータのセットを選択するステップと；
前記第一のメタデータのセットの関数として及び前記第二の部分における前記データ以外のデータの関数としてハッシュ値を生成するステップと；
前記ハッシュ値を前記ファイル内の２番目の位置へ保存するステップと；
を備えることを特徴とする、メタデータを処理する方法。
【請求項２】
さらに少なくとも前記ハッシュ値の関数としてデジタル署名を生成するステップを備える、請求項１に記載の方法。
【請求項３】
前記ファイルはメディアファイルを含み、前記第二の部分はメディアデータから成り、前記第一の部分は前記第一のメタデータのセットを含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記メディアファイルは、ＭＰＥＧファイルを含むことを特徴とする、請求項３に記載の方法。
【請求項５】
前記メディアファイルはＭＰＥＧファイルを含み、前記１番目の位置はムービーレベルユーザデータボックス及びトラックレベルユーザデータボックスの一方であり、前記２番目の位置はムービーボックス内に収容される他のボックスであることを特徴とする、請求項３に記載の方法。
【請求項６】
さらに前記ファイル内の３番目の位置へ保存されるように適合された第二のメタデータのセットを選択するステップを備え、前記第一のメタデータのセットの関数としてハッシュ値を生成するステップは前記第一及び第二のメタデータのセットの関数として前記ハッシュ値を生成することを含むことを特徴とする、請求項１に記載の方法。
【請求項７】
さらに少なくとも前記ハッシュ値の関数としてデジタル署名を生成するステップを備える、請求項６に記載の方法。
【請求項８】
さらに、前記ファイル内の４番目の位置へ保存されるように及び暗号化されたデータのセットの復号化に用いられるように適合された第三のメタデータのセットを選択するステップを備え、前記暗号化されたデータのセットは暗号化されたメタデータ以外のデータであって前記第二の部分へ保存されるように適合されることを特徴とし；かつ
少なくとも前記ハッシュ値及び前記第三のメタデータのセットの関数としてデジタル署名を生成するステップを備える；
請求項６に記載の方法。
【請求項９】
メディアファイル内のメタデータを処理する方法であって：
前記メディアファイル内の１番目のボックスの中に保存されるように適合される第一の複数のユーザデータのセットを選択するステップと；
前記第一の複数のユーザデータのセットの関数として第一のハッシュ値を生成するステップと；
前記第一のハッシュ値を前記メディアファイル内の２番目のボックス内に保存するステップと；
前記メディアファイル内の３番目のボックスの中に保存されるように適合される第二の複数のユーザデータのセットを選択するステップと；
前記第二の複数のユーザデータのセットの関数として第二のハッシュ値を生成するステップと；
前記第二のハッシュ値を前記メディアファイル内の４番目のボックス内に保存するステップと；
を備える方法。
【請求項１０】
前記第一の複数のユーザデータのセットの関数として前記第一のハッシュ値を生成するステップは、前記第一の複数のユーザデータのセットの結合の関数として前記第一のハッシュ値を生成することを備えることと、前記第二の複数のユーザデータのセットの関数として前記第二のハッシュ値を生成するステップは、前記第二の複数のユーザデータのセットの結合の関数として前記第二のハッシュ値を生成することを備えることと、を特徴とする、請求項９に記載の方法。
【請求項１１】
さらに、少なくとも前記第一及び第二のハッシュ値の関数としてデジタル署名を生成するステップと；
前記デジタル署名を前記メディアファイル内の５番目のボックスに保存するステップと；
を備える、請求項９に記載の方法。
【請求項１２】
前記メディアファイルは、メディアデータの第一のトラックと、メディアデータの第二のトラックと、メディアデータの前記第一のトラックに関連したメディアデータを収容する第一のトラックボックスと、メディアデータの前記第二のトラックに関連したメディアデータを収容する第二のトラックボックスとを含むことと、
前記１番目のボックスは前記第一及び第二のトラックボックス内以外の場所に位置することと、
前記２番目、３番目、及び４番目のボックスは前記第一のトラックボックス内に位置することと、
を特徴とする、請求項９に記載の方法。
【請求項１３】
さらに前記第一のハッシュ値を前記第二のトラックボックス内の５番目のボックスに保存するステップを備える、請求項１２に記載の方法。
【請求項１４】
前記メディアファイルは、メディアデータの第一のトラックと、メディアデータの第二のトラックと、メディアデータの前記第一のトラックに関連したメディアデータを収容する第一のトラックボックスと、メディアデータの前記第二のトラックに関連したメディアデータを収容する第二のトラックボックスとを含むことと、
前記１番目及び２番目のボックスは前記第一のトラックボックス内に位置することと、
前記３番目及び４番目のボックスは前記第第二のトラックボックス内に位置することと、
を特徴とする、請求項９に記載の方法。
【請求項１５】
さらに、前記メディアファイル内の５番目のボックスの中に保存されるように適合される第三の複数のユーザデータのセットを選択するステップと；
前記第三の複数のユーザデータのセットの関数として第三のハッシュ値を生成するステップと；
前記第三のハッシュ値を前記メディアファイル内の６番目のボックス内に保存するステップと；
を備える、請求項９に記載の方法。
【請求項１６】
さらに、少なくとも前記第一及び第二のハッシュ値の関数として第一のデジタル署名を生成するステップと；
前記第一のデジタル署名を前記メディアファイル内の７番目のボックス内に保存するステップと；
少なくとも前記第一及び第三のハッシュ値の関数として第二のデジタル署名を生成するステップと；
前記第二のデジタル署名を前記メディアファイル内の８番目のボックス内に保存するステップと；
を備える、請求項１５に記載の方法。
【請求項１７】
前記メディアファイルは、メディアデータの第一のトラックと、メディアデータの第二のトラックと、メディアデータの前記第一のトラックに関連したメディアデータを収容する第一のトラックボックスと、メディアデータの前記第二のトラックに関連したメディアデータを収容する第二のトラックボックスとを含むことと、
前記１番目のボックスは前記第一及び第二のトラックボックス内以外の場所に位置することと、
前記２番目、３番目、及び４番目のボックスは前記第一のトラックボックス内に位置することと、
前記５番目及び６番目のボックスは前記第二のトラックボックス内に位置することと、
を特徴とする、請求項１５に記載の方法。
【請求項１８】
さらに前記第一のハッシュ値を前記第二のトラックボックス内の７番目のボックス内に保存するステップを備える、請求項１７に記載の方法。
【請求項１９】
第一の部分と第二の部分とを有するファイル内のメタデータを処理する方法であって、前記第一の部分はメタデータから構成され、前記第二の部分はメタデータ以外のデータから成り、前記方法は：
ハッシュ値以外のデータである、前記ファイル内の１番目の位置へ保存されるように適合された第一のメタデータのセットを選択するステップと；
少なくとも前記第一のメタデータのセットの関数として及び前記第二の部分のデータ以外のデータの関数としてデジタル署名を生成するステップと；
前記デジタル署名を前記ファイル内の２番目の位置へ保存するステップと；
を備えることを特徴とする、メタデータを処理する方法。
【請求項２０】
前記ファイルはメディアファイルを含み、前記第二の部分はメディアデータから成り、前記第一の部分は前記第一のメタデータのセットを含むことを特徴とする、請求項１９に記載の方法。
【請求項２１】
前記メディアファイルは、ＭＰＥＧファイルを含むことを特徴とする、請求項２０に記載の方法。
【請求項２２】
前記メディアファイルはＭＰＥＧファイルを含み、前記１番目の位置はムービーレベルユーザデータボックス及びトラックレベルユーザデータボックスの一方であり、前記２番目の位置はムービーボックス内に収容される他のボックスであることを特徴とする、請求項２１に記載の方法。
【請求項２３】
さらに前記ファイル内の３番目の位置へ保存されるように適合された第二のメタデータのセットを選択するステップを備え、前記第二のメタデータのセットはハッシュ値以外のデータであり、少なくとも前記第一のメタデータのセットの関数としてデジタル署名を生成するステップは少なくとも前記第一及び第二のメタデータのセットの関数としてデジタル署名を生成することを含むことを特徴とする、請求項１９に記載の方法。
【請求項２４】
データ構造であって：
メタデータから構成される第一の部分、及びメタデータ以外のデータから成る第二の部分と；
前記第一の部分の１番目の位置へ保存されるように適合された第一のメタデータのセットと；
前記第一の部分の２番目の位置へ保存されるハッシュ値と、前記ハッシュ値は前記第一のメタデータのセットの関数であって前記第二の部分の中のデータ以外の関数であることと；
を備えるデータ構造。
【請求項２５】
さらに前記第一の部分の３番目の位置に保存されるデジタル署名を備え、前記デジタル署名は少なくとも前記ハッシュ値の関数であることを特徴とする、請求項２４に記載のデータ構造。
【請求項２６】
前記データ構造はメディアファイルを含み、前記第二の部分はメディアデータから成ることを特徴とする、請求項２４に記載のデータ構造。
【請求項２７】
前記メディアファイルは、ＭＰＥＧファイルを含むことを特徴とする、請求項２６に記載のデータ構造。
【請求項２８】
前記メディアファイルはムービーボックスを有するＭＰＥＧファイルを含み、前記１番目の位置はムービーレベルユーザデータボックス及びトラックレベルユーザデータボックスの一方であり、前記２番目の位置はムービーボックス内に収容される他のボックスであることを特徴とする、請求項２６に記載のデータ構造。
【請求項２９】
さらに、前記第一の部分の３番目の位置へ保存されるように適合された第二のメタデータのセットと、
前記ハッシュ値は前記第一及び第二のメタデータのセットの関数であることと、
を備える、請求項２４に記載のデータ構造。
【請求項３０】
さらに前記第一の部分の４番目の位置に保存されるデジタル署名を備え、前記デジタル署名は少なくとも前記ハッシュ値の関数であることを特徴とする、請求項２９に記載のデータ構造。
【請求項３１】
さらに、前記第一の部分の４番目の位置に保存される第三のメタデータのセットと；
前記第二の部分の中に保存される暗号化されたデータのセットと、前記暗号化されたデータのセットは暗号化されたメタデータ以外のデータであることと、前記第三のメタデータのセットは前記暗号化されたデータの復号化に用いられるように適合されることと；
前記第一の部分の５番目の位置に保存されるデジタル署名と、前記デジタル署名は少なくとも前記ハッシュ値及び前記第三のメタデータのセットの関数であることと；
を備える、請求項２９に記載のデータ構造。
【請求項３２】
ファイル内のメタデータの処理の利用及び処理部を有する装置による利用のための製品であって、前記ファイルはメタデータから構成される第一の部分及びメタデータ以外のデータから成る第二の部分を有し、前記製品は：
少なくとも１つのコンピュータにより利用可能な媒体を含むことと、前記媒体には少なくとも１つのコンピュータプログラムが組み込まれることと、前記少なくとも１つのコンピュータプログラムは；
前記ファイル内の１番目の位置へ保存されるように適合された第一のメタデータのセットの選択と；
前記第一のメタデータのセットの関数として及び前記第二の部分における前記データ以外のデータの関数としてのハッシュ値の生成と；
前記ファイル内の２番目の位置への前記ハッシュ値の保存と；
を前記装置に実行させるよう適合されるコンピュータプログラムであることと、
を備える製品。
【請求項３３】
メタデータから構成される第一の部分及びメタデータ以外のデータから成る第二の部分を有するファイル内のメタデータを処理するシステムであって、前記システムは：
ソフトウェアルーチンを実行できる処理部を有する装置と、処理部により実行されるプログラムロジックと、前記プログラムロジックは；
前記ファイル内の１番目の位置へ保存されるように適合された第一のメタデータのセットを選択する手段と；
前記第一のメタデータのセットの関数として及び前記第二の部分における前記データ以外のデータの関数としてハッシュ値を生成する手段と；
前記ファイル内の２番目の位置へ前記ハッシュ値を保存する手段と；
を含むことと、
を備えるシステム。
【請求項３４】
さらに少なくとも前記ハッシュ値の関数としてデジタル署名を生成する手段を備える、請求項３３に記載のシステム。
【請求項３５】
前記ファイルはメディアファイルを含み、前記第二の部分はメディアデータの部分から成り、前記第一の部分は前記第一のメタデータのセットを含むことを特徴とする、請求項３３に記載のシステム。
【請求項３６】
前記メディアファイルは、ＭＰＥＧファイルを含むことを特徴とする、請求項３５に記載のシステム。
【請求項３７】
前記メディアファイルはムービーボックスを有するＭＰＥＧファイルを含み、前記１番目の位置はムービーレベルユーザデータボックス及びトラックレベルユーザデータボックスの一方であり、前記２番目の位置はムービーボックス内に収容される他のボックスであることを特徴とする、請求項３５に記載のシステム。
【請求項３８】
さらに前記ファイル内の３番目の位置へ保存されるように適合された第二のメタデータのセットを選択する手段を備え、前記第一のメタデータのセットの関数としてハッシュ値を生成する手段は前記第一及び第二のメタデータのセットの関数として前記ハッシュ値を生成することを含むことを特徴とする、請求項３３に記載のシステム。
【請求項３９】
さらに少なくとも前記ハッシュ値の関数としてデジタル署名を生成する手段を備える、請求項３８に記載のシステム。
【請求項４０】
さらに、前記ファイル内の４番目の位置へ保存されるように及び暗号化されたデータのセットの復号化に用いられるように適合された第三のメタデータのセットを選択する手段と、前記暗号化されたデータのセットは暗号化されたメタデータ以外のデータであって前記第二の部分へ保存されるように適合されることと；
少なくとも前記ハッシュ値及び前記第三のメタデータのセットの関数としてデジタル署名を生成する手段と；
を備えることを特徴とする、請求項３８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアファイルを含むファイルのデータ構造、並びにファイルに関連した所定のメタデータの改ざんを検知する方法及びシステムに関する。
【背景技術】
【０００２】
デジタル映像コンテンツ、音声コンテンツまたは他の形態のコンテンツのプロバイダは、効果的なコンテンツ保護がされることなくこれらコンテンツをインターネット上に配信することに消極的である場合が多い。インターネット上にコンテンツを提供するコンテンツプロバイダ向けの技術は存在するものの、デジタルコンテンツは、まさにそれ自身の性質として、所有権者の許可がある場合、無い場合のどちらにおいても、複製または変更が容易である。インターネットによって所有者からコンテンツを配信することは可能だが、同じ技術によって、無許可で複製されたコンテンツの広範囲の配信もまた可能になっている。
【０００３】
デジタル著作権管理（ＤＲＭ：Ｄｉｇｉｔａｌ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ）とは、近年ファイル配信の保護手段として用いられるようになってきたデジタルコンテンツの保護モデルである。ＤＲＭは、通常、デジタルメディアまたは他のデータを保護しコンテンツ所有者に収益を上げさせる、一連の複雑な技術及びビジネスモデルを包含する。
【０００４】
多くの知られたＤＲＭシステムは、コンテンツ所有者から提供された暗号化されていないコンテンツ（または他のデータ）の集合を収容する、コンピュータのハードディスクドライブコンポーネントなどの記憶部を使用する。記憶部内のコンテンツは、ファイアウォールの裏側の信頼区域（ｔｒｕｓｔｅｄ  ａｒｅａ）に置かれる。信頼区域の中では、記憶部上に置かれたコンテンツを暗号化することができる。コンテンツサーバは暗号化されたコンテンツを記憶部から受信し、その暗号化されたコンテンツを配信のためにパッケージ化する。ライセンスサーバは、暗号化されたコンテンツ及び暗号化鍵に関連する権利表現（ａ  ｄｅｓｃｒｉｐｔｉｏｎ  ｏｆ  ｒｉｇｈｔｓ）及び利用条件（ｕｓａｇｅ  ｒｕｌｅｓ）を保持する。（コンテンツサーバ及びライセンスサーバは、（スタジオなどの）コンテンツプロバイダまたはサービスプロバイダによって所有され、または制御されるコンテンツ提供システムの一部である場合がある。）再生装置またはクライアントは、表示するための暗号化されたコンテンツをコンテンツサーバから受信し、アクセス権を特定したライセンスをライセンスサーバから受信する。
【０００５】
いくつかのＤＲＭプロセスは、コンテンツアイテムの要求と、コンテンツ鍵によるアイテムの暗号化と、コンテンツデジタルライセンスへのコンテンツ鍵の保存と、暗号化されたコンテンツの再生装置への配信と、コンテンツ鍵を含むデジタルライセンスファイルの再生装置への送信と、コンテンツファイルの復号化と、デジタルライセンス内で特定された利用条件下でのコンテンツの再生とにより構成される。
【０００６】
しかしながら、コンテンツのある形態、特にマルチメディアファイルについては、コンテンツプロバイダが、利用者への配信に先立ってコンテンツのアイテム全体を暗号化することを望まないことがある。例えば、多くのマルチメディアファイル内では、作品のタイトル、アーティスト、及び他の内在する音声／映像コンテンツ自体の情報の識別に用いられるメタデータに、各ファイルの一部が充てられている。いくつかのコンテンツプロバイダは、こうした形態のメタデータをコンテンツ自体と一緒に暗号化することを望まない。それは、潜在的な利用者が、注文及び関連する復号化鍵を伴うライセンスの受信に先立って、購買の判断を行うためにそうした形態のメタデータにアクセスするのが望ましいと考えているためである。
【０００７】
その一方、メタデータを暗号化せずにコンテンツアイテムを放出すると、問題が生じることがある。悪意のある利用者は、暗号化されていないメタデータを変更することができ、それにより混同を生じさせ、過誤購入を引き起こし、または他の問題を発生させることができる。例えば、悪意のある利用者は、内在するコンテンツについて間違ったタイトルが反映されるようにマルチメディアコンテンツのアイテムのメタデータを変えることができる。そうすると、何も知らない利用者が変更されたメタデータを読み、変更されたメタデータを反映したコンテンツのタイトルに関するライセンスを購入すると、後になって購入したライセンスでその内在するコンテンツへのアクセスができないことを発見することになる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
よって、保護されたデータ又はコンテンツの配信を実現するために、保護の仕組みを改善した方法及びデータ構造が求められる。
【課題を解決するための手段】
【０００９】
開示されているのは、メタデータの変更または改ざんを検知できるようにするための、メディアファイルを含むファイル内のメタデータを処理する方法及びシステム（並びに関連するデータ構造）である。本発明に係るある実施形態によれば、メタデータは、コンテンツサーバによって生成されたハッシュ値とデジタル署名とを含む。これらハッシュと署名の値は、クライアントによってメタデータを認証することに用いることができる。
【００１０】
１つの特徴として、ファイルは第一の部分と第二の部分を有し、第一の部分はメタデータによって構成され、第二の部分はメタデータ以外のデータを含む。そして、ファイルの先頭の位置へ保存されるように適合された第一のメタデータのセットが選択される。次にハッシュ値が生成されると、ファイル内の二番目の位置に保存される。ハッシュ値は、第一のメタデータのセットの関数であり、第二の部分におけるデータ以外の関数である。少なくともハッシュ値の関数としてデジタル署名も生成される。
【００１１】
他の特徴として、ファイルはメディアファイルを含み、第二の部分はメディアデータから成る。第一の部分には、第一のメタデータのセットが含まれる。
【００１２】
他の特徴として、メディアファイルにはＭＰＥＧファイルを含む。先頭の位置は、ムービーレベルのユーザデータボックスまたはトラックレベルのユーザデータボックスのどちらかである。二番目の位置は、映像（“ｍｏｏｖ”）ボックス内に含まれるその他のボックスである。
【００１３】
代わりの実施形態として、データ構造は第一の部分と第二の部分とを含む。第一の部分はメタデータから構成され、第二の部分はメタデータ以外のデータから成る。暗号化されたメタデータ以外の暗号化されたデータのセットは、第二の部分に保存される。第一のメタデータのセットは第一の部分の先頭の位置に保存され、ハッシュ値は第一の部分の二番目の位置に保存される。第二及び第三のメタデータのセットは、第一の部分の三番目及び四番目の位置にそれぞれ保存される。第三のメタデータのセットは、暗号化されたデータのセットの復号化に使用されるよう適合される。ハッシュ値は、第一及び第二のメタデータのセットの関数である。最後に、デジタル署名が第一の部分の五番目の位置に保存され、少なくともハッシュ値と第三のメタデータのセットとの関数となる。
【００１４】
本発明には、さらなる特徴が存在する。そのため、ここまでの記述は単に本発明に係るいくつかの実施形態と特徴の簡単な要約でしかないことが、理解されるべきである。本発明に係るさらなる実施形態と特徴は、以下に言及される。また、本発明の思想または技術的範囲から外れることなく、開示された実施形態に対して多くの変更が可能であることが理解されるべきである。よって、ここまでの概要は本発明の技術的範囲を限定する意味を持つものではない。むしろ、本発明の技術的範囲は、添付の特許請求の範囲及びその均等物から判定されるべきである。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面に示された例としての本発明の実施形態について詳細に述べるが、その中で同一の参照番号は一貫して同一の要素へ言及するものである。ここで、他の実施形態を利用してもよく、本発明の技術的範囲から外れることなく構造的及び処理的な変更を加え得ることは、理解されるべきである。
【００１６】
図１を参照すると、本発明のある実施形態が適用されたコンテンツ提供システム１０の例としての構成が示されている。コンテンツ提供システム１０は、映像データ、音声データ、画像データ、テキストデータ等を含み得る保護されたコンテンツを取り扱う。ライセンスサーバ１２、コンテンツサーバ１４、及び課金（ａｃｃｏｕｎｔｉｎｇ）サーバ１６が、例えばインターネットであるネットワーク２０を介して、互いに、またそれぞれクライアント１８に接続される。この例において、ただ１つのクライアント１８が示されているが、いわゆる当業者であれば、何人のクライアントがネットワーク２０に接続してもよいことを理解するであろう。
【００１７】
コンテンツサーバ１４は、クライアント１８に対して、何らかのデータ保護属性を伴うメタデータ２４を有したコンテンツ２２のアイテムを提供する。ライセンスサーバ１２は、クライアント１８によるコンテンツ２２の利用に必要なライセンスの許可を与える。課金サーバ１６は、ライセンス２２が許可された際にクライアント１８に課金を行うために用いられる。図の実施形態にはクライアント１８と通信する３つのサーバが示されているが、これら３つのサーバ機能をここで示された３つよりも少ない、または多い数のサーバに含めることができることは理解されるであろう。
【００１８】
本発明のある実施形態によれば、メタデータ２４には、コンテンツサーバ１４によって生成されたハッシュ値及びデジタル署名が含まれる。後でより詳細に説明する通り、これらハッシュ値とデジタル署名は、クライアントによってメタデータを認証することに用いることができる。
【００１９】
図２は、コンテンツサーバ１４の一例としての構成を描いている。図２によれば、中央演算装置（ＣＰＵ）３０は、読取専用メモリ（ＲＯＭ）３２に保存され、または記憶部３４からランダムアクセスメモリ（ＲＡＭ）３６へロードされるプログラムの指示の通りに、様々な処理操作を実行する。ＲＡＭ３６には、必要に応じてＣＰＵ３０が様々な処理操作を実行するために求められるデータ等が保存される。
【００２０】
ＣＰＵ３０、ＲＯＭ３２、及びＲＡＭ３６は、バス３８を介して相互接続される。バス３８はさらに、例えばキーボード及びマウスから構成される入力装置４０と、例えばＣＲＴまたはＬＣＤに基づく表示部及びスピーカから構成される出力装置４２と、例えばハードディスクドライブに基づく記憶部３４と、例えばモデム、ネットワークインタフェースカード（ＮＩＣ）または他のターミナルアダプタに基づく通信装置４４とに接続される。
【００２１】
ＲＯＭ３２、ＲＡＭ３６、及び／または記憶部３４には、コンテンツサーバ１４の運用を可能とするために用いられるオペレーティングソフトウェアが保存される。通信装置４４は、ネットワーク２０を介して通信処理を実行し、ＣＰＵ３０から供給されるデータを送信し、そしてネットワーク２０から受信するデータのＣＰＵ３０、ＲＡＭ３６、及び記憶部３４への出力を行う。記憶部３４は、情報を保存及び削除するために、ＣＰＵ３０と共に情報の転送を行う。通信装置は、他の装置との通信に必要とされるアナログ信号またはデジタル信号の通信も行う。
【００２２】
バス３８はドライブ５０とも接続され、ドライブ５０上には、例えば磁気ディスク、光ディスク、磁気光学ディスク、または半導体メモリが、記憶部３４に取り付けられたこれら記録媒体のいずれかからコンピュータプログラムまたは他のデータを読み込むためにロードされる。
【００２３】
図示されてはいないものの、クライアント１８、ライセンスサーバ１２、及び課金サーバ１６（図１）もまた、それぞれ図２に示されたコンテンツサーバ１４と同様の構成を基本的に持つコンピュータとしてそれぞれ構成される。図２がコンテンツサーバ１４の１つの構成を示しているが、他のいかなる形態のコンピュータ装置も代替的な実施形態に含まれる。
【００２４】
コンテンツ提供システム１０において、ライセンスサーバ１２及びコンテンツサーバ１４は、ライセンス（図示されていない）及びコンテンツ２２をクライアント１８に送信する（図１）。ライセンスは、典型的には暗号化された形で保護されたコンテンツのクライアント１８による利用（即ち、表示、再生、複製、実行など）を可能とするために必要となる。
【００２５】
コンテンツの各アイテムは、サービスプロバイダの組織によって、１つ以上の暗号化鍵を用いて構成、暗号化される。クライアント１８は、ライセンス情報及びコンテンツに基づいて、受信したコンテンツアイテムの復号化と再生を行う。いくつかの実施形態において、例えばコンテンツアイテムが利用できなくなる期限日、コンテンツを利用できる回数、例えばＣＤなどの記録媒体にコンテンツを複製できる回数、及びコンテンツを携帯装置に持ち出すことのできる回数などの利用権（ｕｓａｇｅ  ｒｉｇｈｔｓ）が、ライセンス情報に含まれる。
【００２６】
図３には、本発明の１つの実施形態によるメタデータの保護のためのデータ構造を単純化した様子が描かれている。
【００２７】
図３を参照すると、第一の部分と第二の部分とを有する修正されたＭＰＥＧ４（“ＭＰ４”と呼ばれる場合がある）のデータ構造が示されており、それぞれメタデータ、内在する音声／映像コンテンツが含まれる。ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）は、映像及び音声データを含むマルチメディア表現を編成するための、マルチメディアの圧縮の標準フォーマットであるＭＰＥＧ４を整備してきた。ＭＰＥＧ４に加え、メディアデータを利用するための他のＭＰＥＧフォーマットもまた存在する。
【００２８】
ＭＰＥＧ４はオブジェクト指向のファイルフォーマットであり、データはアトム（“ａｔｏｍ”）またはボックス（“ｂｏｘｅｓ”）と呼ばれる構造にカプセル化される。ＭＰＥＧ４フォーマットは、全てのプレゼンテーションレベルの情報（即ちメタデータ）をマルチメディアの実データサンプル（メディアデータと呼ばれる場合がある）から分離し、メタデータをファイル内部のムービーボックス（“ｍｏｖｉｅ  ｂｏｘ”）と呼ばれる１つの完全な構造の中に置いている。この形態のファイル構造は、メタデータがメディアデータから分離されるため、一般的にはトラック指向（“ｔｒａｃｋ−ｏｒｉｅｎｔｅｄ”）と呼ばれる。図３には複数のボックスが描かれているが、実際のＭＰＥＧ４のファイルにはここで図示されていない多くの追加的なボックスが含まれる。
【００２９】
ボックス（またはアトム）は、図４に示されているボックス５２のような共通的な構造を有する。ボックス５２の中で、最初の４バイトはボックス５２のサイズをバイト数で表すサイズフィールド５４として設定される。次の４バイトは、ボックス５２のタイプを識別するタイプフィールド５６として設定される。ボックス５２のタイプは、４つの文字、即ち“４文字コード（ａ  ｆｏｕｒ  ｃｈａｒａｃｔｅｒ  ｃｏｄｅ）”によって識別される。例えば、ムービーボックスの場合には“ｍｏｏｖ”が設定され、ムービーデータボックスの場合には“ｍｄａｔ”が設定される。この４文字とのマッチングによって、ボックスのタイプを識別することができる。そして、タイプフィールド５６の後には、ボックスデータフィールド５８またはセクションが保存される。このボックスデータフィールド５８の構造は、各ボックス内で目的に応じて定義された構文（ｓｙｎｔａｘ）を有する。このボックスファイル構造を用いることで、あるボックスを他のボックスの中に挿入するといった、入れ子または階層化された形での保存を行うことができる。  
【００３０】
図３に描かれている実施形態において、新しいボックスタイプが定義される。後でより詳細に説明する通り、メタデータ完全性検査値（“ｍｉｃｖ”）ボックス６０には、所定のハッシュ及び署名の値がメタデータの認証に用いるために保持される。
【００３１】
しかし、まず、図示された他のボックスの所定の機能の概要を説明する。引き続き図３を参照すると、ＭＰＥＧ４のデータ構造には１つのムービー（“ｍｏｏｖ”）ボックス６４、及び少なくとも１つのメディアデータ（“ｍｄａｔ”）ボックス６６が含まれる。ｍｏｏｖボックス６４には、ＭＰＥＧ４のファイル全体のメタデータを復号化するために必要とされる情報等、即ち、例えばデータの復号化のための属性やアドレス等を表す情報などの、符号化されたメディアのコーデックデータストリームが格納される。ｍｄａｔボックス６６には、符号化されたメディアの実コーデックストリーム、即ち、映像ストリームまたは音声ストリームといったコンテンツデータが格納される。
【００３２】
ｍｏｏｖボックス６４は複数の他のボックスをカプセル化し、その中にはムービーヘッダ（“ｍｖｈｄ”）ボックス６８、１つ目のムービーレベルユーザデータ（“ｕｃｄｔ”）ボックス７０、２つ目のムービーレベルユーザデータ（“ｕｃｄ２”）ボックス７２、音声トラック（“ｔｒａｋ”）ボックス７４、及び映像トラック（“ｔｒａｋ”）ボックス７６が含まれる。ｍｖｈｄボックス６８には、プレゼンテーション全体を規定する情報が含まれる。このボックスには、ムービー全体の時間スケールと継続時間の情報、及びその表示特性が定義される。
【００３３】
音声及び映像トラックボックス７４、７６には、ｍｏｏｖボックス６４の中に含まれるメディアタイプに応じた各メディアのメタ情報を保持する他のボックスが含まれる。トラックボックスでは、ムービーの１つのトラックについて定義が行われる。各トラックは、ｍｏｏｖボックス６４内の他のトラックから独立しており、自身の時間的及び空間的な情報を保有している。トラックは、特にメディアデータ（メディアトラック）を包含し、さらに修飾（ｍｏｄｉｆｉｅｒ）トラックを包含するために用いられる。
【００３４】
後でより詳しく述べる通り、一般的に言えば、ユーザデータボックスを用いてムービー、トラック、またはメディアといったＭＰＥＧ４オブジェクトに関連付けられたデータを定義し保存することができる。ここには、著作権情報またはムービーがループすべきかといったＭＰＥＧ４が要求する情報と、ユーザのアプリケーションによってユーザのアプリケーションのために備えられるＭＰＥＧ４が無視する情報の両方が含められる。ムービーレベルユーザデータボックスの直接の親はムービーボックスであり、そこにはムービー全体に関するデータが含まれる。トラックレベルユーザデータボックスの直接の親はトラックボックスであり、そこにはその特定のトラックに関する情報が含まれる。１つのＭＰＥＧ４ファイルには、多くのユーザデータボックスを含んでもよい。
【００３５】
図の例においては、ムービーレベルユーザデータボックス７０、７２は、それぞれ“ｕｃｄｔ”及び“ｕｃｄ２”というボックスタイプを有している。各ユーザデータボックスの内部には、複数のユーザデータエントリボックスがあり、それぞれユーザデータのセットを含んでいる。例えば、ユーザデータエントリボックスは、ムービーの画面位置、再生特性、作製情報、タイトル、ジャンル、俳優の名前、作者名などに相当するユーザデータのセットを格納するために用いることができる。図３に示されている通り、１つ目のムービーレベルユーザボックス７０内のユーザデータエントリボックスに含まれるのは、この例ではＥｒｉｃ  Ｃｌａｐｔｏｎとなっているアーティスト名に相当するユーザデータのセットのための“＠ｎａｍ”ボックス７８、曲名のための“Ｃｎａｍ（Ｃは丸付き）”ボックス８０（“Ｃｈａｎｇｅ  ｔｈｅ  Ｗｏｒｌｄ”）、キーワード情報のための“＠ＫＷＤ”ボックス８２（“Ｐｈｉｌ  Ｃｏｌｌｉｎｓ”、“Ｐａｔｒｉｃｋ  Ｒｉｐｌｅｙ”など）、及び作品が作られた日付のための“Ｃｄａｙ（Ｃは丸付き）”ボックス８４である。ユーザ情報としての他の多くの項目に相当するユーザデータのセットを、さらに含めることもできる。
【００３６】
２つ目のムービーレベルユーザボックス（“ｕｃｄ２”）７２が含んでいるのは、ＭＰＥＧ４ファイルに含まれる他のメディアデータのためのムービーレベルデータである。図の例では、コマーシャルに関連するユーザデータエントリ情報として、コマーシャルのタイトルのための“Ｃｎａｍ（Ｃは丸付き）”ボックス８６（“Ｇａｐ  Ｃｏｍｍｅｒｃｉａｌ”）、コマーシャルの主演俳優のための“＠ｎａｍ”ボックス８８（“Ｓａｒａｈ  Ｊｅｓｓｉｃａ  Ｐａｒｋｅｒ”）がある。
【００３７】
音声トラックボックス７４、及び映像トラックボックス７６には、トラックレベルユーザボックス９０、９２が含まれる。これらには、ムービーレベルユーザボックス７０、７２について説明したのと同様の情報が格納されるが、トラックレベルの情報には親のボックスに関連する特定のトラック（例えば音声または映像）のみが関係する点で異なり、他のトラックやムービーレベルの情報を含める必要はない。
【００３８】
さらに映像トラックボックス７６には、復号化サンプル時間（ｄｅｃｏｄｉｎｇ  ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ）ボックス９４が含まれる。このボックスには、対応するデータサンプルとメディア内の時間の対応付けを提供する、メディアサンプルの継続時間の情報が格納される。サンプル時間ボックス９４内に含まれるサンプル時間ボックスのテーブルを検査することにより、メディア内のどういった時間でも適切なサンプルを判定することができる。
【００３９】
さらに、音声トラックボックス７４、及び映像トラックボックス７６には、保護スキーム情報ボックス（“ｓｉｎｆ”）９６、９８が含まれる。ｓｉｎｆボックスは、ＤＲＭまたは他のデータセキュリティ関連の方法に関係する情報を含む他のボックスの親ボックスである。これら他のボックスには、適用された暗号化変換とそのパラメータを理解し、かつ鍵管理システムの種類と場所等の他の情報を発見するために必要とされる所定の情報が格納される。
【００４０】
映像トラックｓｉｎｆボックス９８に含まれているのは、ＤＲＭシステムの種類と用いられるセキュリティ情報の構造を定義する、スキームタイプボックス（“ｓｃｈｍ”）１００である。さらに映像トラックｓｉｎｆボックス９８には、スキーム情報ボックス（“ｓｃｈｉ”）１０２が含まれる。これは、用いられているＤＲＭスキームによってのみ解釈されるコンテナである。暗号化システムが必要とする情報が、ここに格納される。このボックスの中身は、スキームタイプボックス１００内で宣言されたスキームによって定義されるタイプとフォーマットを持つ一連のボックスである。
【００４１】
ｓｃｈｉボックス１０２に含まれるのは、暗号化アルゴリズムボックス（“ｅａｌｇ”）１０４である。その名前から分かる通り、このボックスには暗号化アルゴリズムを識別するための情報が含まれ、さらにｍｄａｔボックス６６の中に位置するコンテンツの復号化に用いる初期ベクトルが含まれる。
【００４２】
また、ｓｃｈｉボックス１０２には、メタデータ完全性検査値ボックス（“ｍｉｃｖ”）６０も含まれる。図５を参照すると、ｍｉｃｖボックス６０は、完全性情報ボックス（“ｉｉｎｆ”）１０６のためのコンテナであり、さらに図５に示されていない他のボックスのコンテナでもある。そして、ｉｉｎｆボックス１０６は、完全性検査スキームボックス（“ｉｓｃｈ”）１０８、完全性ターゲットボックス（“ｉｔｒｇ”）１１０、及び完全性検査値ボックス（“ｉｃｖｉ”）１１２、及び図５に示されていない他のボックスのコンテナである。
【００４３】
ｉｓｃｈボックス１０８は、メタデータを保護するＤＲＭシステムを識別するために用いられる。これは、コンテンツに用いられるｓｃｈｍボックス１００内で識別されるＤＲＭシステムとは異なるＤＲＭシステムであってもよく、または同じＤＲＭシステムであってもよい。
【００４４】
ｉｔｒｇボックス１１０はハッシュ値を計算する対象となるメタデータの識別のために用いられ、または他の実施形態としては、デジタル署名のために用いられる。このボックス内のデータには、ターゲットタイプ情報、ターゲットサブタイプ情報、及びターゲットエントリ情報が含まれる。ターゲットタイプ情報は、ハッシュ値の計算にどのメタデータボックスを用いるかを特定する。後でより詳細に述べる通り、この情報で特定されるのは、例えばｕｃｄ２ボックスなどの、ムービーレベルまたはトラックレベルのいずれかのユーザデータボックスであって、そこからハッシュ計算のためのデータが取得される。ターゲットサブタイプ情報は、ユーザデータボックスがムービーレベルのメタデータなのか、トラックレベルのメタデータなのかを特定する。最後に、ターゲットエントリ情報は、（ターゲットタイプ及びサブタイプにより特定された）ユーザデータボックス内に含まれるどのユーザデータエントリボックスが実際にハッシュ計算、または他の実施形態ではデジタル署名に用いられるのかを特定する。
【００４５】
よって、例えば、次のエントリを伴うユーザデータエントリボックスを含むｕｃｄｔボックスの１つがあったとする（各左辺のＣは丸付き）：
【００４６】
＠ｎａｍ  ＝  Ｅｒｉｃ  Ｃｌａｐｔｏｎ
Ｃｎａｍｅ  ＝  Ｃｈａｎｇｅ  ｔｈｅ  Ｗｏｒｌｄ
＠ＫＷＤ  ＝  Ｐｈｉｌ  Ｃｏｌｌｉｎｓ  Ｐａｔｒｉｃｋ  Ｒｉｐｌｅｙ
Ｃｇｅｎ  ＝  Ｒｏｃｋ  Ｐｏｐｓ
Ｃｄａｙ  ＝  １２  Ｏｃｔｏｂｅｒ  １９９９．
【００４７】
そして、次のようなハッシュターゲットがターゲットエントリにより定義されているとする（Ｃは丸付き）：
【００４８】
ターゲットエントリ  ＝  “＠ｎａｍ”“＠ＫＷＤ”“Ｃｇｅｎ”
【００４９】
この場合は、ターゲットエントリから分かるハッシュターゲットは、ターゲットエントリの文字列結合であって、“Ｅｒｉｃ  Ｃｌａｐｔｏｎ  Ｐｈｉｌ  Ｃｏｌｌｉｎｓ  Ｐａｔｒｉｃｋ  Ｒｉｐｌｅｙ  Ｒｏｃｋ  Ｐｏｐｓ”となる。このターゲットエントリから得られるハッシュ値の結果（“完全性検査値”と呼ばれる場合がある）は、ｉｃｖｉボックス１１２内に格納される。ｉｃｖｉボックス１１２には、この完全性検査値のみが格納されるのではなく、ハッシュ値の計算に用いられたアルゴリズムの識別値も格納される。１つの実施形態において、ハッシュアルゴリズムとして用いられるのは、ＳＨＡ−１アルゴリズムである。しかしながら、他の実施形態として異なるハッシュアルゴリズムを用いてもよい。
【００５０】
よって、クライアントの装置がコンテンツを受信すると、クライアントはｉｔｒｇボックス１１０の中のターゲットエントリデータを検索してアクセスし、そのデータに対してハッシュ計算を実行してローカルハッシュ値を得る。このローカルハッシュ値は、同じターゲットエントリデータについてコンテンツサーバにより計算された完全性検査値（ｉｃｖｉボックス１１２に格納されている）と比較される。そして値が整合していれば、ユーザは、無権限の第三者にメタデータが変更されていないであろうと信じることができる。
【００５１】
図３及び図５には映像トラックｓｉｎｆボックスの中に含まれるボックスが描かれているが、音声トラックｓｉｎｆボックス９６の中にも同じｓｃｈｍ、ｓｃｈｉ、ｅａｌｇ、及びｍｉｃｖボックスを有する同様のデータ構造が含まれることは理解されるべきである。
【００５２】
代わりの実施形態としては、ハッシュアルゴリズムを用いるのではなく、デジタル署名が用いられる。言い換えれば、例えばターゲットエントリデータのハッシュを計算するのではなく、ターゲットエントリデータのデジタル署名が用いられる。
【００５３】
図６は、ハッシュ対象のメタデータの選択とデータ構造内の対応するハッシュ値の配置を示した単純化された図である。この例において、３つのムービーレベルのユーザデータエントリ１２８ａ、１２８ｂ、１２８ｃが、ｍｏｏｖボックス１２０内に位置したムービーレベルのｕｃｄｔボックス１２２から選択される。この図において、便宜的にこれらエントリは単純に、“Ｅｎｔｒｙ１”、“Ｅｎｔｒｙ４”、及び“Ｅｎｔｒｙ５”とされている。しかしながら、これらは、図３に示されたムービーレベルのｕｃｄｔボックス７０内に位置する“＠ｎａｍ”、“＠ＫＷＤ”等のエントリに相当するデータと同様のものである。これら３つのエントリのハッシュ１２９は、コンテンツ提供サーバによって計算され、次の２つの場所に配置される：（１）トラック１（音声）ボックス１２４内に位置するトラック１のｓｉｎｆボックス１３４の中の入れ子のｉｃｖｉボックス（図示されていない）、（２）トラック２（映像）ボックス１２６内に位置するトラック２のｓｉｎｆボックス１３６の中の入れ子のもう１つのｉｃｖｉボックス（図示されていない）。
【００５４】
加えて、４つのトラックレベルユーザデータエントリ１３０ａ−１３０ｄが、トラック１のｕｃｄｔボックス１３８から選択されてコンテンツ提供サーバによる別のハッシュ値１３１の計算に使用され、そのハッシュ値はトラック１（音声トラック）のｓｉｎｆボックス１３４内の入れ子のｉｃｖｉボックス（図示されていない）内に配置される。同様に、３つのトラックレベルユーザデータエントリ１３２ａ、１３２ｂ、１３２ｃが、トラック２（映像トラック）のｕｃｄｔボックス１３９から選択されてさらに別のハッシュ値１３３の計算に使用され、そのハッシュ値はトラック２（映像トラック）のｓｉｎｆボックス１３６内の入れ子のｉｃｖｉボックス（図示されていない）内に配置される。（図６では、単に図示の容易さのためにハッシュ値をｓｉｎｆボックス１３４、１３６内に直接配置している。実際は、これらの値は図３や図５に示されたｓｉｎｆボックスの数階層下の入れ子のｉｃｖｉボックス内に配置されることが理解されるべきである）。
【００５５】
（ｓｉｎｆボックス１３４、１３６内の入れ子の）ｉｃｖｉボックス内に格納されるハッシュ値に加えて、トラック１及びトラック２のｓｉｎｆボックス１３４、１３６にはそれぞれ、例えば暗号化鍵又は副鍵、コンテンツライセンス属性データ、または他のＤＲＭ関連セキュリティデータ等の、メディアデータの暗号化に用いるために適合された一連のメタデータを格納する追加的なセキュリティ情報ボックス１４０、１４２が、少なくとも１つずつ含まれる。ハッシュデータまたは追加的なセキュリティ情報ボックス１４０、１４２内のデータの改ざんが行われるのを防ぐために、トラック１のデジタル署名１４４が、ムービーレベルのハッシュ１２９、トラック１レベルのハッシュ１３１、及びトラック１のセキュリティ情報ボックス１４０のデータの関数として生成される。このトラック１のデジタル署名１４４は、トラック１のｓｉｎｆボックス１３４内に配置される。同様に、トラック２のデジタル署名１４６が、ムービーレベルのハッシュ１２９、トラック２レベルのハッシュ１３３、及びトラック２のセキュリティ情報ボックス１４２のデータについて計算される。このトラック２のデジタル署名１４６は、トラック２のｓｉｎｆボックス１３６内に配置される。ハッシュ及びセキュリティ情報データが改ざんされていないことを確かめるために、これらデジタル署名は、クライアントによってコンテンツ提供サーバ（またはいくつかの他の外部ソース）から得られる公開鍵を用いて検証することができる。
【００５６】
ここでは、修正されたＭＰＥＧ４フォーマットを用いて本発明の１つの実施形態について説明を行っているが、いわゆる当業者であれば、他の実施形態として他のＭＰＥＧファイルフォーマット並びに他のメディアフォーマット、他のストリーミングアプリケーションとフォーマット、及び他の形態のコンテンツまたはデータによって実装してもよいことを理解するであろう。
【００５７】
図７は、本発明の１つの実施形態によるメディアファイル内のメタデータを処理する方法の単純化されたフロー図である。まず、１５０において、第一の複数のユーザデータのセットが選択される。第一の複数のセットは、メディアファイル内の１番目のボックスの中に保存されるように適合される。そして、１５２において、第一の複数のユーザデータのセットの関数である第一のハッシュ値が生成される。次に、１５４において、第一のハッシュ値がメディアファイル内の２番目のボックス内に保存される。
【００５８】
１５６において、メディアファイル内の３番目のボックスに保存されるよう適合された第二の複数のユーザデータのセットが選択される。そして、１５８において、第二の複数のユーザデータのセットの関数である第二のハッシュ値が生成される。１６０において、第二のハッシュ値がメディアファイル内の４番目のボックス内に保存される。最後に、１６２において、少なくとも第一と第二のハッシュ値の関数としてデジタル署名が生成され、１６４において、メディアファイルの５番目のボックスの中に保存される。
【００５９】
本明細書では、メタデータの変更または改ざんを検知できるように、メディアファイルを含むファイル内のメタデータを処理するための方法及びシステム（並びに関連するデータ構造）が開示されている。ある実施形態によれば、メタデータは、コンテンツサーバによって生成されたハッシュ値とデジタル署名とを含む。これらハッシュ値とデジタル署名は、クライアントによりメタデータを認証するために用いることができる。
【００６０】
前述の説明は本発明の特定の実施形態に言及しているものの、本発明の思想から外れることなく多くの修正を加え得ることは理解されるであろう。特許請求の範囲は、本発明の真の技術的範囲及び思想の中にそれら修正を含むことを意図して記述されている。それ故、ここに開示された実施形態は全て限定ではなく説明の観点で考慮されるべきであり、本発明の技術的範囲はここまでの説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等な意味及び範囲内の全ての変更はそこに包含される。
【図面の簡単な説明】
【００６１】
本発明に係るこれらの及び／または他の特徴と利点は、添付図面を伴う好適な実施形態に関する説明から明らかとなり、より容易に理解されるであろう。
【図１】コンテンツ配信において利用されるいくつかの実施形態に応じたコンテンツ提供システムについて単純化されたブロック図である。
【図２】本発明の１つの実施形態に応じたコンテンツサーバ装置のハードウェア環境の単純化されたブロック図である。
【図３】本発明のいくつかの実施形態に応じたデジタルコンテンツのアイテムのデータ構造の単純化された図である。
【図４】デジタルコンテンツのアイテムのボックスコンポーネントのデータ構造の単純化された図である。
【図５】本発明のいくつかの実施形態に応じたデジタルコンテンツのアイテムの他のボックスコンポーネントのデータ構造の単純化された図である。
【図６】本発明のいくつかの実施形態に応じたデジタルコンテンツの他のアイテムのデータ構造の単純化された図である。
【図７】本発明の１つの実施形態に応じたメタデータの処理方法の単純化されたフロー図である。
【図１】
2008539525.tif 000002
【図２】
2008539525.tif 000003
【図３】
2008539525.tif 000004
【図４】
2008539525.tif 000005
【図５】
2008539525.tif 000006
【図６】
2008539525.tif 000007
【図７】
2008539525.tif 000008
【国際調査報告】
2008539525.tif 000009