(57)【要約】【課題】プロキシのようなネットワーク媒介物が終端間セキュリティ保証を損なうことなくマルチメディア・データをコード変換することを可能にする方法及びシステムを提供する。【解決手段】１つの実施例では、コンテンツ・プロバイダがデータ・ストリームを複数のコンポーネントに分解する。それらコンポーネントの各々が独立して暗号化される。望ましい実施例では、媒介物又はプロキシが、各コンポーネントと関連した暗号化されてないクリア・テキストのメタデータに従って、所定のコンポーネントを優先順位づけすること及びドロップすることによって、コンポーネントのコード変換を行う。クリア・テキストのメタデータは、相互に関してコンポーネントの絶対的又は相対的重要度／優先順位に関する意味的な理解を提供し、それによって、コード変換プロセスを促進することが望ましい。その後、宛先／クライアント装置は、コード変換プロキシによって送られたコンポーネントを暗号化解除でき、それをオリジナル・データ・コンテンツの表示に再アセンブルできる。【選択図】図９
2004511037.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ・プロバイダからのデータをクライアント装置による使用のために安全にコード変換するための方法にして、
前記データを圧縮解除したものである複数のデータ・コンポーネントをコンテンツ・プロバイダにおいて生成するステップと、
前記データ・コンポーネントの各々を暗号化するステップと、
前記暗号化されたデータ・コンポーネントを前記コンテンツ・プロバイダからコード変換プロキシに送信するステップと、
前記暗号化されたデータ・コンポーネントを前記コード変換プロキシにおいてコード変換するステップと、
前記コード変換された暗号化されたデータ・コンポーネントを選択的に操作するステップと、
前記コード変換プロキシによって生成された前記操作された暗号化されたデータ・コンポーネントを前記クライアント装置に送信するステップと、
を含む方法。
【請求項２】
前記暗号化されたデータ・コンポーネントをコード変換プロキシに送信するステップは、
前記コンテンツ・プロバイダにおいて、少なくとも１つの暗号化されたコンポーネント部分を含む少なくとも１つのメッセージをアセンブルするステップと、
前記少なくとも１つのメッセージを前記コード変換プロキシに送信するステップと、
を含む、請求項１に記載の方法。
【請求項３】
前記コード変換プロキシにおいて、前記コード変換プロキシにより受信された前記少なくとも１つのメッセージから前記少なくとも１つの暗号化されたコンポーネント部分を取り出すステップを更に含む、請求項２に記載の方法。
【請求項４】
前記コード変換プロキシにおいて、前記コード変換されたデータ・コンポーネントを選択的に操作するステップは、前記暗号化されたデータ・コンポーネントの少なくとも１つをドロップすることによって前記コード変換されたコンポーネントをフィルタリングするステップを更に含む、請求項１乃至請求項３のいずれか１つに記載の方法。
【請求項５】
前記コード変換プロキシにおいて、前記コード変換されたデータ・コンポーネントを選択的に操作するステップは、前記暗号化されたデータ・コンポーネントの少なくとも１つに対して別のデータを代用することによって前記コード変換されたコンポーネントをフィルタリングするステップを更に含む、請求項１乃至請求項３のいずれか１つに記載の方法。
【請求項６】
前記操作されたコード変換されたデータ・コンポーネントをクライアント装置に送信するステップは、
前記コード変換プロキシにおいて、少なくとも１つの操作されたコンポーネント部分を含む少なくとも１つのメッセージをアセンブルするステップと、
前記少なくとも１つのメッセージを前記クライアント装置に送信するステップと、
を含む、請求項１に記載の方法。
【請求項７】
前記クライアント装置において、前記クライアント装置によって受信された前記少なくとも１つのメッセージから前記少なくとも１つの操作されたコンポーネント部分を取り出すステップと、
前記少なくとも１つの操作されたコンポーネント部分を暗号化解除するステップと、
前記少なくとも１つの暗号化解除されたコンポーネント部分から前記データのコード変換された表示を再アセンブルするステップと、
を更に含む、請求項６に記載の方法。
【請求項８】
前記データ・コンポーネントの意味的な理解を与えるメタデータでもって前記データ・コンポーネントの少なくとも１つを注釈するステップを更に含む、請求項１乃至請求項７のいずれか１つに記載の方法。
【請求項９】
前記注釈するステップは、暗号化されてないクリア・テキスト・メタデータ・ヘッダを作成することを含む、請求項８に記載の方法。
【請求項１０】
前記クリア・テキスト・メタデータ・ヘッダは、データ・コンポーネントを一意的に識別する少なくとも１つのラベルを含む、請求項９に記載の方法。
【請求項１１】
前記クリア・テキスト・メタデータ・ヘッダは、少なくとも１つのデータ・コンポーネントと関連した優先順位を記述した情報を含む、請求項９に記載の方法。
【請求項１２】
前記クリア・テキスト・メタデータ・ヘッダ及び少なくとも１つの暗号化されたデータ・コンポーネントを結合する少なくとも１つのメッセージをアセンブルするステップと、
前記少なくとも１つのアセンブルされたメッセージを前記コード変換プロキシに送信するステップと、
を更に含む、請求項９乃至請求項１１のいずれか１つに記載の方法。
【請求項１３】
前記コード変換プロキシにおいて、前記少なくとも１つのアセンブルされたメッセージを逆アセンブルして前記メッセージから前記クリア・テキスト・メタデータ・ヘッダ及び前記少なくとも１つの暗号化されたデータ・コンポーネントを取り出すステップと、
前記少なくとも１つのクリア・テキスト・メタデータ・ヘッダから得られたメタデータ情報に従って前記少なくとも１つの暗号化されたデータ・コンポーネントを選択的に操作するステップと、
を更に含む、請求項１２に記載の方法。
【請求項１４】
前記コード変換プロキシにおいて、前記クリア・テキスト・メタデータ・ヘッダ及び前記少なくとも１つの操作された暗号化されたデータ・コンポーネントを結合する少なくとも１つのコード変換されたメッセージをアセンブルするステップと、
前記少なくとも１つのコード変換されたメッセージを前記クライアント装置に送信するステップと、
を更に含む、請求項１３に記載の方法。
【請求項１５】
前記クライアント装置によって受信された前記少なくとも１つのコード変換されたされたメッセージを逆アセンブルして前記クリア・テキスト・メタデータ・ヘッダ及び前記少なくとも１つの操作された暗号化されたデータ・コンポーネントを取り出すステップと、
前記少なくとも１つの操作されたデータ・コンポーネントを暗号化解除するステップと、
前記少なくとも１つの暗号化解除された操作されたデータ・コンポーネントから前記データのコード変換された表示を再アセンブルするステップと、
を更に含む、請求項１４に記載の方法。
【請求項１６】
前記クリア・テキスト・メタデータ・ヘッダの第２バージョンを作成するステップと、
前記クリア・テキスト・メタデータ・ヘッダの第２バージョンを暗号化するステップと、
を更に含む、請求項９に記載の方法。
【請求項１７】
前記クリア・テキスト・メタデータ・ヘッダ、前記クリア・テキスト・メタデータ・ヘッダの暗号化された第２バージョン、及び少なくとも１つの暗号化されたデータ・コンポーネントを含む少なくとも１つのメッセージをアセンブルするステップと、
前記少なくとも１つのアセンブルされたメッセージを前記コード変換プロキシに送信するステップと、
を更に含む、請求項１６に記載の方法。
【請求項１８】
前記クライアント装置によって受信された前記少なくとも１つのアセンブルされたされたメッセージを逆アセンブルして前記クリア・テキスト・メタデータ・ヘッダ、前記クリア・テキスト・メタデータ・ヘッダの暗号化された第２バージョン、及び少なくとも１つの操作された暗号化されたデータ・コンポーネントを取り出すステップと、
前記クリア・テキスト・メタデータ・ヘッダの暗号化された第２バージョンを暗号化解除するステップと、
前記少なくとも１つの操作された暗号化されたデータ・コンポーネントを暗号化解除するステップと、
前記少なくとも１つの暗号化解除された操作されたデータ・コンポーネントから前記データのコード変換された表示を再アセンブルするステップと、
を更に含む、請求項１７に記載の方法。
【請求項１９】
前記クライアント装置によって受信された前記クリア・テキスト・メタデータ・ヘッダの暗号化解除された第２バージョンを前記クリア・テキスト・メタデータ・ヘッダと比較して前記クリア・テキスト・メタデータ・ヘッダの不正使用を検出するステップを更に含む、請求項１８に記載の方法。
【請求項２０】
前記クリア・テキスト・メタデータ・ヘッダの暗号化解除された第２バージョンに含まれた情報を前記少なくとも１つの操作された暗号化解除されたデータ・コンポーネントと比較して前記少なくとも１つの操作された暗号化解除されたデータ・コンポーネントの不正使用を検出するステップを更に含む、請求項１８に記載の方法。
【請求項２１】
前記データ・コンポーネントを生成するステップは、前記データを前記データの非オーバラップの区分けに対応した複数の相互に排他的なコンポーネントに分解することを含む、請求項１乃至請求項２０のいずれか１つに記載の方法。
【請求項２２】
マルチメディア・データを安全にコード変換するためのシステムにして、
前記マルチメディア・データから複数のコンポーネントを生成し、前記複数のコンポーネントの各々を暗号化する少なくとも１つのコンテンツ・プロバイダと、
前記少なくとも１つのコンテンツ・プロバイダに動作関係に接続され、少なくとも１つの暗号化されたコンポーネントを前記コンテンツ・プロバイダから受信し、前記少なくとも１つの暗号化されたコンポーネントを選択的に操作する少なくとも１つのコード変換プロキシと、
前記少なくとも１つのコード変換プロキシに動作関係に接続され、前記少なくとも１つの暗号化されたコンポーネントを受信及び暗号化解除し、前記少なくとも１つの操作された暗号化解除されたコンポーネントから前記マルチメディア・データのコード変換されたバージョンを再アセンブルする少なくとも１つのクライアント装置と、
を含む、システム。
【請求項２３】
前記コード変換プロキシは、前記コンポーネントの各々と関連した優先順位情報に従って前記少なくとも１つの暗号化されたコンポーネントを選択的に操作し、
前記優先順位情報は、対応するコンポーネントの絶対的重要度及び対応するコンポーネントの他のコンポーネントに関する相対的重要度を記述する、
請求項２２に記載のシステム。
【請求項２４】
コンピュータ可読記憶媒体に記憶され、コンピュータ上で実行される時、請求項１乃至請求項２１に記載の方法を遂行するコンピュータ・プログラムを含むコンピュータ・プログラム製品。
【発明の詳細な説明】
【０００１】
【技術分野】
本発明の方法及び装置は、概して云えば、コード変換（ｔｒａｎｓｃｏｄｉｎｇ）システムに関し、更に詳しく云えば、コード変換プロキシが、暗号化されたマルチメディア・コンテンツを、そのコンテンツの暗号化解除を必要としない方法で、安全にコード変換するシステムに関するものである。
【０００２】
【背景技術】
この分野で理解されているコード変換は、マルチメディア・コンテンツ（例えば、テキスト、イメージ、オーディオ、ビデオ等）を、そのマルチメディア・コンテンツがエンコードされた第１のオリジナル・フォーマットから、第２のフォーマットに変換する技法を呼ぶ。コード変換器は、特定のタスクに対するコード変換機能を技術的に実現したものである。コード変換技法は、コンテンツをそれのオリジナル・フォーマットでディスプレイ又はプレーバックするためのサポートをほとんど或いはまったく行わないクライアント装置において、表示のためにそのコンテンツを適応させる場合に不可欠である。例えば、本来、セル電話及びワイヤレスのパーソナル・ディジタル・アシスタント（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ − ＰＤＡ）上に表示されるように設計されてないウェブ・ページが、そのような装置においてディスプレイ／プレーバックするようにコード変換されることが可能である。更に、ウェブ・コンテンツのコード変換は、低速のインターネット・アクセス・リンクにおけるマルチメディア・コンテンツの圧縮を増進してそのコンテンツに対するアクセスの速度を改善するために使用され得る。
【０００３】
コード変換は、コンテンツ・プロバイダのウェブ及びクライアント装置のウェブ・ブラウザの間に設けられた媒介物又はプロキシによって行われることが多い。プロキシにおけるコード変換のための一般的な方法は、データをコード変換することができるようにするために、データが暗号化されてないことが必要である。マルチメディア・データが初期に暗号化された場合、コード変換プロキシは、データをコード変換する前に先ずそのデータを暗号化解除しなければならない。しかし、マルチメディア・データを暗号化解除することは、コンテンツ・プロバイダ及びクライアント以外の第三者（例えば、プロキシ）が暗号化解除されたデータ・ストリームを盗聴（ｅａｖｅｓｄｒｏｐ）することができるので、終端間のセキュリティ保証を害することになる。
【０００４】
コード変換をマルチメディア・コンテンツに適用するための主要な目的は２つある。第１の目的は、モデム・リンク及びワイヤレス・アクセス・リンクのような低帯域幅のアクセス・リンクを介したウェブ・ページのダウンロード遅延を少なくすることである。一般に、コード変換機能は媒介物又はプロキシ内に存在する。コード変換プロキシは、一般に、マルチメディア・コンテンツのバイトにおけるサイズを減少させるために何らかの無損失圧縮又は有損失圧縮を使用するコード変換器である（例えば、イメージは更に圧縮され、テキストは要約される等）。アクセス・リンクを通して転送されるバイトの数を少なくすることによって、コード変換プロキシは、受信者にコンテンツをもっと速く配送することができ、それによって、感知応答時間をかなり減少させることができる。コード変換は、ビデオ・コンテンツのビット・レートを減少させるべくビデオにも適用されており、従って、低帯域幅のリンクを介して接続されたクライアントは、その減少したビデオ・ストリームを受信することができる。待ち時間（ｌａｔｅｎｃｙ）の減少（例えば、低帯域幅のリンクを介した圧縮による減少）がコード変換に対する主要な動機づけである時、ディスティレーション（ｄｉｓｔｉｌｌａｔｉｏｎ）、サマライゼーション（ｓｕｍｍａｒｉｚａｔｉｏｎ）、ダイナミック・レート・シェーピング（ｄｙｎａｍｉｃ ｒａｔｅ ｓｈａｐｉｎｇ）及びフィルタリング（ｆｉｌｔｅｒｉｎｇ）という用語がコード変換に対する同義語として使用されることが多い。
【０００５】
コード変換をマルチメディア・コンテンツに適用するための第２の目的は、クライアント装置によりサポートされたデコーディング・フォーマットとマルチメディア・コンテンツのプロバイダにより使用されたエンコーディング・フォーマットとの間のミスマッチを解決することである。マルチメディア・コンテンツに対してミスマッチしたクライアント装置においてそのマルチメディア・コンテンツをプレーバック又はディスプレイを可能にするために、コード変換器は、一般に、マルチメディア・コンテンツを、最初にエンコードされたフォーマットから、クライアント装置によって理解されるデコーディング・フォーマットに変換する。コーダ／デコーダ（コーデック）のミスマッチは、クライアント装置及び（又は）コンテンツ・プロバイダにおけるハードウェア、ソフトウェア、環境上の制約及び人間の行動上の制約のために生じることがある。コード変換テクノロジの２つの伝統的な例は、音声認識（即ち、音声からテキストへのコード変換）及び音声合成（即ち、テキストから音声へのコード変換）である。この場合、マルチメディア・コンテンツは、コンテンツ・プロバイダとそのコンテンツを利用するクライアント装置との間のコーデック・ミスマッチを解決するように変換される。
【０００６】
コード変換は、現在では、携帯用ＰＤＡがウェブをブラウズすることを可能にするためにウェブ・ページ（例えば、イメージ及びＨＴＭＬテキスト）を変換するためにも使用される。ＰＤＡクライアント装置は、それらの比較的小さいスクリーン・サイズ、限定されたディスプレイの厚さ、限定されたメモリ、遅いプロセッサ、及びメディア・タイプの限定されたサポートによって制約されることが多い。そのような装置に対して、コード変換プロキシは、例えば、カラーＧＩＦ及びＪＰＥＧイメージを２ビットのグレイスケール・ビットマップに変換してＰＤＡのソフトウェア制約に適応させるために、及びダウンスケールしたサムネイルに変換して小さいスクリーン・サイズのＰＤＡのハードウェア制約に適応させるためにも応用される。なお、トランスレーション（ｔｒａｎｓｌａｔｉｏｎ）、コンテント・リパーポージング（ｃｏｎｔｅｎｔ ｒｅｐｕｒｐｏｓｉｎｇ）、コンテント・アダプテーション（ｃｏｎｔｅｎｔ ａｄａｐｔａｔｉｏｎ）、リフォーマッティング（ｒｅｆｏｒｍａｔｔｉｎｇ）、データ・トランスフォーメーション（ｄａｔａ ｔｒａｎｓｆｏｒｍａｔｉｏｎ）、メディア・コンバージョン（ｍｅｄｉａ ｃｏｎｖｅｒｓｉｏｎ）、クリッピング（ｃｌｉｐｐｉｎｇ）、ユニバーサル・アクセス（ｕｎｉｖｅｒｓａｌ ａｃｃｅｓｓ）、フォーマット・コンバージョン（ｆｏｒｍａｔ ｃｏｎｖｅｒｓｉｏｎ）、及びフィルタリング（ｆｉｌｔｅｒｉｎｇ）という用語が、コード変換をクライアントの異機種混合（ｈｅｔｅｒｏｇｅｎｅｉｔｙ）に適応するように応用する時、そのコード変換に対して同義的に使用されることが多い。
【０００７】
中間的なプロキシにコード変換機能を設けることはセキュリティ問題を引き起こすことになる。プロキシにおけるコード変換のための一般的な方法は、データが、コード変換されるためには暗号化されてないことを必要とする。マルチメディア・データが初期に暗号化された場合、コード変換プロキシは、データがコード変換される前に、先ず、そのデータを暗号化解除しなければならない。データを暗号化解除し得るためには、プロキシは、そのデータを暗号化するために使用されたキーを持たなければならない。このタイプのプロキシは、一般に、トラステッド・プロキシ（ｔｒｕｓｔｅｄ ｐｒｏｘｙ）と呼ばれる。しかし、この方式は、ソース装置又は宛先装置との如何なる関係も持たないプロキシに、そのソース又は宛先装置がキーを送らなければならないので、実用上の困難を有する。この方式は、コンテンツ・プロバイダ及びクライアント以外の第三者（プロキシ）が潜在的にその暗号化解除されたデータを盗聴することができるので、終端間のセキュリティ保証を損なう。
【０００８】
安全なコード変換システムを提供しようとする従来の試みは、プロキシによるデータの安全なコード変換と関連した独特の問題を処理及び（又は）解決することができなかった。マルチメディア・コンテンツを複数のコンポーネントに細分することに関する従来技術の方法は、プログレッシブ・イメージ・トランスミッション（Ｐｒｏｇｒｅｓｓｉｖｅ Ｉｍａｇｅ Ｔｒａｎｓｍｉｓｓｉｏｎ − ＰＩＴ）及び階層化ビデオ・マルチキャストを含む。ＰＩＴでは、各イメージが、一般には知覚的に最も重要度の高いものから最も重要度の低いものに配列された複数のコンポーネントに分割される。コンテンツ・プロバイダは、知覚的に最も重要度の高いコンポーネントを先ずクライアント装置に送り、それに続いて低い重要度のコンポーネントを後続させる。ＰＩＴがイメージ配送の知覚される遅延を少なくする（最も重要なコンポーネントが到着し、最初に表示されるので）ことはわかっているけれども、コンテンツ・プロバイダとクライアント装置との間におけるコード変換は実現していない。
【０００９】
階層化されたビデオ・マルチキャストでは、ビデオ・ストリームが複数のコンポーネントに細分される。ビデオ・セッションに加入する受信者は、それらコンポーネントのサブセットに加入するであろう。受信者のアクセス・リンクが低い帯域幅を有する場合、受信クライアントは、ビデオ・ストリームの最も基本的なコンポーネントにしか加入しないであろう。マルチキャスト・ルーティング・プロトコルをサポートするルータは受信者の加入リクエストを考慮し、望ましくないマルチキャスト・コンポーネントを選択的にフィルタリング又はドロップする。しかし、階層化されたビデオ・マルチキャスト（又は、階層化された一般的なコーディング）方法は、安全な選択的フィルタリング／コード変換を可能にするけれども、送られる情報を保護する方法を扱うものではない。この方法は、不正使用（ｔａｍｐｅｒｉｎｇ）を検出するための手段を提供するものではない。
【００１０】
ＩＢＭ社のチューリッヒ研究所における ＳＥＲＶＡＮＴ プロジェクトは、コード変換される必要があるコンテンツ・フィールドに対する不信なコード変換器のアクセスを依然として許容するけれども、クライアント及びサーバが安全なセッションを確立することを可能にするための機構を提案している。コード変換器は、サーバがセキュリティ・センシティブなコンテンツ・フィールドを選択的に暗号化することができるので信用される必要はなく、コンテンツの各フィールドをコード変換する方法を述べたそのコンテンツの信号要約ドキュメントを含むことが可能である。従って、セキュリティ・センシティブなコンテンツはコード変換器から保護され、クライアントは、そのクライアントに代わって行われるコード変換がサーバの意図に従っているということを確認することができる。ＳＥＲＶＡＮＴ は、コンテンツを２つのビン、即ち、安全なビン及び安全でないビンに分ける。しかし、そのコード変換プロキシは、依然として、コンテンツの「安全」な部分をコード変換することができず、従って、前述の問題点を処理するものではない。
【００１１】
一般的な不正使用検出方法に関しては、不正使用検出機構における従来技術は、可視的又は非可視的なウォータマーク（ｗａｔｅｒｍａｒｋ）の使用を含む。可視的ウォータマーク及び非可視的ウォータマークはいずれも或る形式のパターン、バー・コード、ディジタル署名等をデータの中に組み込んでいる。データの不正使用は、ウォータマークの不整合又は不存在によって検出され得る。しかし、従来技術は、すべてのデータがクリア・テキスト（暗号化されてないテキスト）形式のものである場合に関連しているので、従来技術によって扱われた問題は、本発明によって扱われる問題点とは異なる。
【００１２】
既存の方法及び装置は、コード変換システムを通して終端間のセキュリティを維持するけれども、クライアント装置による使用のためにコンテンツ・プロバイダ又は同様のソースからのデータをコード変換プロキシがコード変換することを可能にするというその問題に対する解決方法を扱うものではなく、或いはそれを提供するものでもない。従って、媒介物又はプロキシによりマルチメディア・コンテンツの安全なコード変換を提供するという要求がコード変換の分野において残っている。
【００１３】
【発明の開示】
第１の局面によれば、本発明は、クライアント装置による使用のためにコンテンツ・プロバイダからのデータを安全にコード変換する方法を提供する。その方法は、データを分解したものである複数のデータ・コンポーネントをコンテンツ・プロバイダにおいて生成するステップ、そのデータ・コンポーネントの各々を暗号化するステップ、その暗号化されたデータ・コンポーネントをコンテンツ・プロバイダからコード変換プロキシに送信するステップ、その暗号化されたデータ・コンポーネントをコード変換プロキシにおいてコード変換するステップ、そのコード変換された暗号化されたデータ・コンポーネントを選択的に操作するステップ、及びコード変換プロキシによって生成されたその操作されたコード変換されたデータ・コンポーネントをクライアント装置に送信するステップを含む。
【００１４】
第２の局面によれば、本発明は、マルチメディア・データを安全にコード変換するためのシステムを提供する。そのシステムは、前記マルチメディア・データから複数のコンポーネントを生成し、それら複数のコンポーネントの各々を暗号化する少なくとも１つのコンテンツ・プロバイダと、その少なくとも１つのコンテンツ・プロバイダに動作関係に接続され、前記コンテンツ・プロバイダから少なくとも１つの暗号化されたコンポーネントを受信し、その少なくとも１つの暗号化されたコンポーネントを選択的に操作する少なくとも１つのコード変換プロキシと、その少なくとも１つのコード変換プロキシに動作関係に接続され、その少なくとも１つの操作された暗号化されたコンポーネントを受信し且つ暗号化解除し、その少なくとも１つの暗号化解除されたコンポーネントからマルチメディア・データのコード変換されたバージョンを再アセンブルする少なくとも１つのクライアント装置を含む。
【００１５】
第３の局面によれば、本発明は、コンピュータ可読記憶媒体に記憶され、コンピュータにおいて実行される時に上記の方法を遂行するコンピュータ・プログラム・コードを含むコンピュータ・プログラム製品を提供する。
【００１６】
本発明の利点は、媒介物又はプロキシによってマルチメディア・コンテンツを安全にコード変換するための方法及び装置を提供することである。
【００１７】
本発明のもう１つの利点は、プロキシがデータを暗号化解除することなく、即ち、その暗号化解除した場合における終端間のシステム・セキュリティの保証を損なうことなく、プロキシによってデータをコード変換するための方法及び装置を提供することである。
【００１８】
本発明は、コード変換プロキシによって引き起こされるセキュリティ問題に対する解決方法を提供する。その解決方法は、１つの実施例によれば、先ず、コンテンツ・プロバイダにデータ（例えば、マルチメディア・コンテンツ）を複数のコンポーネントに細分する又はコンポーネント化することを含むことが望ましい。そこで、これらのコンポーネントの各々は独立して暗号化され得る。コンテンツ・プロバイダのコード変換プロキシのダウンストリームは、暗号化されたコンポーネントのうちのいくつかを選択的にフィルタリング又はドロップすることが望ましい。選択的なフィルタリングは、コンテンツの圧縮ベースのコード変換を達成し、それによって、コンテンツにおける如何なるコンポーネントの暗号化解除も必要とすることなく遅いアクセス・リンクにおけるコンテンツ配送の速度を改善する。
【００１９】
１つの実施例では、本発明は、３つの分散エンティティ又は機能的ユニットを含み、それらは、それぞれ、マルチメディア・コンテンツをエンコードし、安全にコード変換し、そしてデコードする。第１のエンティティ（例えば、コンテンツ・プロバイダ）は、既存のマルチメディア・オブジェクトを取り出し、ソース・データを複数のデータ・コンポーネントに細分することが望ましい。更に、これらのコンポーネントの各々は、コンポーネント識別フィールド及び特定のコンポーネントの相対的な重要度／優先順位に関する情報を含むがそれに限定されないメタデータ・ヘッダでもって注釈されることが望ましい。各コンポーネントに対して、コンテンツ・プロバイダは、クリア・テキスト（暗号化されてない）のメタデータ・ヘッダと、そのメタデータ・ヘッダの暗号化されたバージョンと、暗号化されたコンポーネントとを含むメッセージをエンコード又はアセンブルすることが望ましい。各コンポーネントに対して、コンテンツ・プロバイダは、対応するアセンブルされたメッセージを第２のエンティティ、コード変換プロキシ、又は媒介物に送信することが望ましい。
【００２０】
コード変換プロキシは、各コンポーネントに対応した複数のメッセージを受信し、各メッセージのメタデータ・ヘッダを調べてどの暗号化されたコンポーネントが選択的にフィルタリングされるべきかを決定する。残りのメッセージは、オリジナル・マルチメディア・オブジェクトの安全にコード変換されたバージョンを含み、そこで、第３のエンティティであるクライアント装置に送信される。
【００２１】
クライアント装置は、それら残りのメッセージを受信する。各送信されたメッセージに対して、クライアント装置はそのメッセージを暗号化解除し、メタデータ・ヘッダの暗号化解除バージョンをクリア・テキスト・メタデータ・ヘッダと比較する。それらヘッダの両方ともメッセージから抽出されたものである。２つのヘッダが所定の受容可能な程度内で一致しない場合、恐らく不正使用が行われたであろう。２つのヘッダが一致する場合、クライアント装置は、不正使用がなかったという結論になり、そのメッセージの暗号化解除されたコンポーネントをデコードすることによって進行する。
【００２２】
望ましくは、この方法は、少なくとも１つのデータ・コンポーネントを暗号化する前にそのコンポーネントを圧縮することを更に含む。
【００２３】
望ましくは、この方法は、クライアント装置において、少なくとも１つのデータ・コンポーネントを暗号化解除した後にそのコンポーネントを圧縮解除することを更に含む。
【００２４】
望ましくは、データはマルチメディア・オブジェクトである。
【００２５】
望ましくは、マルチメディア・オブジェクトは、テキスト・ぺージ、イメージ、オーディオ、ビデオ、リレーショナル・データ、ＸＭＬドキュメント、及びハイブリッド・オブジェクトより成るグループから選択される。なお、ハイブリッド・オブジェクトは、マルチメディア・オブジェクトの組み合わせである
【００２６】
【発明の実施の形態】
図１は、チャネルを介して送信されるデータをエンコード及びデコードするための通信システムを示す。当業者には明らかなように、チャネル自体は、例えば、セルラー、サテライト、マイクロウェーブ、又は起電力（ｅｌｅｃｔｒｏｍｏｔｉｖｅ ｆｏｒｃｅ）ネットワークを含む１つ又は複数の専用データ回線又は無線通信リンクのような任意の既知の形態で実現され得る。１つの代表的な通信プロセスでは、データ・ソース又はコンテンツ・プロバイダによって送られたデータは、通常、そのデータがそれの宛先（例えば、ユーザ）に到達する前にソース・エンコーディング及びデコーディング、並びにチャネル・エンコーディング及びデコーディングを通過するであろう。
【００２７】
図１を参照すると、ソース・エンコーディング１０１及びソース・デコーディング１０４は、一般的な意味では、ソース・データにおける何らかの冗長度を利用することによってそのソース・データの総量を縮小又は圧縮するための方法及び装置のことである。この分野では、種々の圧縮技法が知られており、例えば、無損失圧縮（例えば、ランレングス・コーディング、ハフマン・コーディング、アリスメティック・コーディング、及びＵＮＩＸにおけるジージップ（ｇｚｉｐ）コマンドにおいて使用されるＬＺ方法）、有損失圧縮（例えば、離散コサイン変換（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ − ＤＣＴ）及びウェーブレッツ（ｗａｖｅｌｅｔｓ））、又はそれらの任意の組み合わせ（例えば、ＪＰＥＧ）を含み得る。
【００２８】
データが圧縮された後、そのデータがＡＣ結合のトランスミッタ／レシーバを介して送られることを可能にするようそのデータからＤＣ成分を除去するために、そのデータは、例えば、ファイバ・チャネル及びギガビット・イーサネット用の８Ｂ／１０Ｂコーディングのようなチャネル・エンコーディング１０２を必要とするであろう。更に、チャネル・エンコーディングは、高速のデータ同期化を可能にするために十分なデータ遷移を保証する。対応するチャネル・デコーディング１０３は、付加されたデータ及び（又は）遷移を除去するために必要とされる。
【００２９】
トランスミッタによって利用されるチャネル・エンコーディング方法がレシーバによって使用されるチャネル・デコーディング技法とは異なる時、図２に示されるように、そのチャネルを通過するデータにチャネル・コード変換を適用することが可能である。この方法を使用すると、チャネル・コード変換器２０３が、一般には、チャネル・エンコーダ２０２及びチャネル・デコーダ２０４の間に挿入される。ソース・エンコーダ２０１及びソース・デコーダ２０５は、本質的には影響されない。
【００３０】
図３は、ソース・コード変換方法が、レシーバによって使用される方法とは異なる場合の一般的な方式を示す。図３を参照すると、ソース・エンコーダ３０１において使用される方法がソース・デコーダ３０７において使用される方法とは異なる時、ソース・コード変換器３０４が必要である。更に、チャネル・エンコーダ３０２によってエンコードされたデータ・チャネルをデコードするために、チャネル・デコーダ３０３がソース・コード変換器３０４の前に付加されなければならない。ソース・コード変換器３０４によってコード変換されたデータは、その後、チャネル・エンコーダ３０５によってチャネル・エンコードされる必要があり且つレシーバにおいてそのレシーバのチャネル・デコーダ３０６によって再びデコードされる必要がある。
【００３１】
例えば、ＴＣＰ／ＩＰ通信プロトコルに基づいたネットワーク環境（例えば、インターネット）では、クライアントとサーバとの間にプロキシ・サーバ又はソック・サーバを導入することが知られている。この方法では、プロキシは、種々のネットワーク・オペレーションを遂行するようめにクライアントに代わって作用するであろう。図４は、そのようなプロキシ・サーバを含む一般的なアーキテクチャを示す。そこで、図４を参照すると、ブラウザ４０９（例えば、ネットスケープ（ネットスケープ・ナビゲータは、ネットスケープ・コミュニケーションズ社の商標である）及びインターネット・エクスプローラ（インターネット・エクスプローラは、マイクロソフト社の商標である））及びウェブ・サーバ４０１（例えば、アパッチ・サーバ又はロータス・ドミノ・サーバ）の両方とも、例えば、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）のようなステートレス通信プロトコルに基づいて動作し得る。ＨＴＴＰプロトコルは、ステートフルＴＣＰプロトコルを呼び出すであろう。一方、ステートフルＴＣＰプロトコルは、ステートレスＩＰ（４０２、４０５、４０７、４１０）を呼び出す。図４の例では、ＩＰパケットが、メディア・アクセス・プロトコル（ＭＡＣ）４０３、４０４、４０８、４１１（例えば、イーサネット、ファイバ・チャネル、非同期転送モード）にとって必要な更なるヘッダによって断片化及びカプセル化されるであろう。一般に、ブラウザ４０９が、最初に、プロキシ４０６に接続する。その後、プロキシ４０６は、ウェブ・サーバ４０１との接続を確立する責任があるであろうし、本質的には、ブラウザ４０９とウェブ・サーバ４０１との間で送信されるデータをリレーするように働く。当業者には明らかなように、プロキシは、例えば、ブラウザからの各入力接続が検証され且つターゲット・アドレスが制御されるように、ファイアウォールとして広範に使用される。
【００３２】
図５は、ウェブ・サーバ５０２において記憶され得るＧＩＦイメージ・フォーマット５０１がブラウザ５１３によって検索される時の状況の一例を示す。この例では、プロキシ５０７は、コード変換を行うように適応したコード変換モジュール５０８を使用して、ＧＩＦイメージ・フォーマット５０１からＪＰＥＧフォーマット５１４への変換又はコード変換を遂行し得る。少なくとも見方によっては、ソース・イメージのデータ量を少なくするためにこれが望ましいことがある。図５の例において示されるように、ブラウザ５１３、プロキシ５０７、及びウェブ・サーバ５０２が、すべて、ＴＣＰ／ＩＰ（５０３、５０６、５０９、５１２）及びＭＡＣ（５０４、５０５、５１０、５１１）プロトコルによって相互にコミュニケーションを行うということは明らかである。
【００３３】
データの安全な送信のために、ブラウザ及びウェブ・サーバは、セキュア・ソケット層（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ − ＳＳＬ）を介してコミュニケーションを行うことができる。ＳＳＬでは、ＤＥＳ及び公開キーのような既知の暗号化方法が、順序保存セキュリティ（ｏｒｄｅｒ ｐｒｅｓｅｒｖｅ ｓｅｃｕｒｉｔｙ）によってデータを暗号化するために呼び出され得る。一般的な安全な通信テクノロジが図６に示される。図６を参照すると、セキュア層（例えば、ＳＳＬ）６０７、６０２は、一般に、クライアント側におけるブラウザ６０８とＴＣＰ／ＩＰ６０６との間及びサーバ側におけるウェブ・サーバ６０１とＴＣＰ／ＩＰ６０３との間にある。セッション毎を基準として、セキュリティが課せられる。当業者には知られているように、ブラウザ側におけるＳＳＬ６０７は、先ず、ウェブ・サーバ側におけるＳＳＬ６０２との接続を確立することを要求する。サーバ側のＳＳＬ６０２はその接続を許可し、公開キーをブラウザ６０８に送る。そこで、ブラウザ側のＳＳＬ６０７は、サーバ６０１から受信した公開キーを使用してセッション・キーを暗号化する。そのセッション・キーはサーバに送られる。そこで、サーバ側のＳＳＬ６０２は、それ自身の秘密キーを使用してそのセッション・キーを暗号化解除する。次に、ブラウザ６０８及びサーバ６０１の両方は、同じセッション・キーを通してコミュニケーションを行うであろう。ブラウザ及びサーバによって送られたすべてのデータが同じセッション・キーによって暗号化されるであろう。
【００３４】
ＳＳＬがサーバ側及びブラウザ側それぞれにおけるＴＣＰ／ＩＰ６０３、６０６及びＭＡＣ層６０４、６０５にとって透明であることは明らかである。更に、プロキシのようなサービス（例えば、ファイアウォール）がブラウザとサーバとの間に導入される時、そのプロキシは、ＴＣＰ／ＩＰが使用されると仮定すると、ＩＰアドレスに基づいてリクエスタ（ブラウザ）及び宛先（サーバ）を検証することができるであろう。しかし、プロキシは、データがすべて暗号化される時、そのデータを調べることができないであろう。代表的な暗号化方法の一例が図７に示される。図７に示されるように、コンテンツ・プロバイダは、データ圧縮を（例えば、任意の既知のソース・コーディング技法、例えば、ＪＰＥＧを通して）行うことができ（７０２）、そのデータを、この例では、イメージを暗号化する（７０１）。そこで、その暗号化されたデータ７０５は、ネットワーク通信チャネルを介して、そのデータを要求しているクライアント装置に送られる。クライアント装置が信頼されている（即ち、安全である）と仮定すると、そのクライアント装置は、そのデータを暗号化解除し（７０４）、圧縮解除して（７０３）オリジナル・イメージを実質的に再構成するためのアルゴリズムを保持している。暗号化されたデータがコンテンツ・プロバイダとクライアント・デバイスとの間のそのネットワークに沿った任意のポイントで観察される場合、その暗号化されたデータは、暗号化解除アルゴリズムを保持しないと解読され得ないので、観察者は盗聴することができないであろう。従って、観察者は、スクランブルされたデータを見るだけであろう。
【００３５】
図７の従来例のシステムに示されるように、送信者（即ち、コンテンツ・プロバイダ）では、一般に、暗号化に続いて圧縮が生じる。通常の圧縮（ソース・コーディング）アルゴリズムは、一般に、データにおける統計上の冗長性を排除するように適応するが、その結果生じた出力データのサイズは減少している。対照的に、暗号化アルゴリズムは、一般に、データをランダムな（即ち、統計上の冗長度が排除されている）ものに見せるような方法でデータをスクランブルするが、データのサイズは、オリジナル入力データに比べて減少せず、増加することさえある。データの暗号化が圧縮ステップに先行する場合、暗号化ステップは、統計上の冗長度が、たとえあったとしても、ほんのわずかとなるようにデータをスクランブルし、圧縮段階でそれを排除する。その結果、データ圧縮は、ほとんど又はまったく行われないであろう。更に、暗号化によりもたらされたランダム性は非常に大きく、圧縮アルゴリズムがデータのサイズを減少させるのではなく、実際には、むしろ拡大することがある。このために、送信側における実行の順序は、先ず、圧縮があり、続いて暗号化があることが望ましい。
【００３６】
図８に示されるように、コード変換プロキシは、コンテンツ・プロバイダとクライアント装置との間に媒介物として導入され得る。プロキシは、本質的には、データのサイズが減少し、従って、応答時間（即ち、データ・スループット）を改善するよう、或いは、データのフォーマットがクライアント装置における表示に適応したフォーマットに変換されるよう、データをコード変換する働きをする。いずれの場合も、コード変換プロキシがシステムに存在する時、コード変換のための標準的な方法は、先ず、コード変換が行われる前に、暗号化されたデータ・ストリーム（コンテンツ・プロバイダによって圧縮され且つ暗号化されている）を暗号化解除することを必要とする。図８を参照すると、コード変換プロキシは、先ず、データを暗号化解除し（８０４）、そのデータを圧縮解除し（８０３）、しかる後、そのデータを再圧縮するための圧縮アルゴリズムを適用し（８０６）、それによってデータのサイズ及び（又は）それのフォーマットを変更する。プロキシは、最終的には、そのコード変換されたデータを再暗号化し（８０５）ネットワークを介してクライアント装置へ送信する。クライアント側では、コード変換プロキシからの新たな圧縮（ソース・コーディング）アルゴリズムを使用して、そのデータは、再び、暗号化解除され（８０７）そして圧縮解除される（８０８）。
【００３７】
この一般的なコード変換方法の重要な且つ潜在的には厳しい結果は、図８に示されるように、一旦、データがコード変換プロキシによって暗号化解除されると、それが再び暗号化される前に、第三者がその暗号化されてないデータを盗聴できることである。この状態は、暗号化の使用においてプライバシ・インプリシット（ｐｒｉｖａｃｙ ｉｍｐｌｉｃｉｔ）の終端間セキュリティ保証を損なう。この場合、送信者及び受信者だけがスクランブルされてない状態におけるデータをアクセスすることができる。或る場合には、コード変換プロキシが、データを暗号化解除するものとして送信者及び受信者によって信用されたエンティティであることは可能であるけれども、一般には、コード変換プロキシは滅多に信用されないであろう。
【００３８】
従来技術のコード変換システム及び方法は、一般に、暗号化されてないデータのみに圧縮が適用され得るものであると仮定される。これは、コード変換器によって使用される圧縮アルゴリズムが、一般に、データのサイズを減少させるためにはそのデータに関するセマンティクス及び（又は）統計の厳密な理解を必要とするためである。今までは、データがスクランブルされてない／暗号化解除されている時にだけこの意味的な理解を得ることができるものと仮定されていた。
【００３９】
本発明は、例えば、ウェブ・サーバであってもよい１つ又は複数のデータ・ソース（例えば、マルチメディア・コンテンツ・プロバイダ）と、例えば、ウェブ・ブラウザ又は他の装置であってもよい１つ又は複数のクライアント装置との間に設置された媒介物又はプロキシによってデータを安全にコード変換するための方法及び装置に関するものである。本発明によれば、コード変換オペレーションは、暗号化されたデータの暗号化解除を先ず必要とすることなく、その暗号化されたデータに関して遂行される。望ましい実施例では、本発明は３つの分散ユニット又はエレメントを含む。それの第１のユニット（例えば、コンテンツ・プロバイダ）は、ソース・データ（例えば、マルチメディア・オブジェクト）に関してエンコーディング・オペレーションを遂行し、第２のユニットは、データを安全にコード変換し、そして第３のユニット（例えば、クライアント装置又はブラウザ）は、コード変換ユニットから受け取ったデータをデコードする。これらの３つの主要なユニットの各々に関する望ましい実施例を示すフローチャートがそれぞれ図９乃至図１１に示される。更に、このトポロジに限定されないけれども、図１２は、本発明に従って形成された安全なコード変換システム全体の例を示す。
【００４０】
ここでは、３つの個別の機能的ブロック又はユニットを含むものとして説明されるけれども、本発明のシステムでは、３つの機能的ブロックが、相互に関して物理的に別々の又は遠隔のロケーションに存在する必要はないことが明らかであろう。例えば、個別のコード変換プロキシが使用されないものと仮定して、コンテンツ・プロバイダと共に又はクライアント装置と共にそのコード変換装置を物理的に存在させることは、本発明の技術的範囲内である。
【００４１】
次に、図９を参照すると、データ・コンテンツ・プロバイダによって実現され得るような、本発明に従って形成されるエンコーディング・ユニットの一実施例が、既存のマルチメディア・オブジェクト又は同様のデータ９００を入力として取り入れること、及びデータの分解９０１のようなことによってそのデータから所定数のコンポーネント９０６を生成すること（即ち、コンポーネント化）によって、エンコーディング手順を開始することが望ましい。データ・オブジェクトのコンポーネント化は、その結果として、Ｋ個のコンポーネントの生成を生じる。なお、この例におけるＫは、１よりも大きいか又は１に等しい。データ・コンポーネント９０６は、重畳したデータ又は冗長なデータを含み得る。例えば、各データ・コンポーネントは、オリジナル・オブジェクトのコピーを含み得る。同様に、データ・コンポーネント９０６は、相互に関して互いに排他的であってもよい。例えば、イメージが複数の非重畳的な地理的領域に区分けされ得るので、各領域が個別のコンポーネントとして表されることによって、それら領域すべての連合体がオリジナル・イメージを完全に再構成し得る。分解、即ち、コンポーネント化プロセス９０１は、当業者には明らかなように、既知の技法を使用して、例えば、サブバンド・コーディング（ｓｕｂ−ｂａｎｄ ｃｏｄｉｎｇ）及びウェーブレット技法のようなプログレッシブ・エンコーディング・アルゴリズム又は階層化アルゴリズムによって遂行され得る。
【００４２】
本発明の望ましい実施例（図９には示されてない）では、各データ・コンポーネント９０６がその後に圧縮又はコード化され得る（例えば、図１２における参照番号１２０２参照）。以後、「圧縮」という用語は、圧縮及び（又は）コーディングを意味するように使用されるであろう。「コーディング」という用語は、それが伝統的に理解され得る時、圧縮よりももっと一般的な用語であり、マルチメディア・オブジェクト又は他のソース・データのディジタル表示を生成するプロセスとして定義されることが多いことは明らかである。しかし、圧縮とは異なり、コーディングは、オブジェクトの入力ディジタル表示よりも少量の出力ディジタル表示を生成する必要がない。
【００４３】
圧縮が使用されると仮定すると、特定のデータ・コンポーネントに適用される圧縮アルゴリズム又は技法が、他のコンポーネントに適用される圧縮アルゴリズムと同じである必要はないが、本発明は、同様に、単一の圧縮手段が使用され得ることを意図する。コンポーネントに適用される圧縮アルゴリズムは、利用される圧縮の程度及び（又は）タイプに影響し得るマルチメディア・オブジェクトに関連した他の情報のようなオリジナル・オブジェクトに対応するたコンポーネント・データ以外の情報も入力パラメータとして受容し得る。図１２は、圧縮アルゴリズム「Ｃ」１２０２が個々のデータ・コンポーネントを受け取るという例を示している。
【００４４】
データ・ソース／コンテンツ・プロバイダは、ステップ９０３においてデータ・コンポーネント９０６に加えられる又はそれに組み込まれるメタデータ情報も生成することが望ましい。当業者には知られているように、メタデータは、それが付加されるデータを特徴づけるために広範に使用され、本質的には、それは「データに関するデータ」である。このメタデータは、例えば、コンポーネントを識別するために使用される注釈ラベルを含み得るし、特定のコンポーネントの相対的又は絶対的重要度に関する記述を含み得る。コンポーネント又はオブジェクト全体の意味的なコンテンツに関する情報、シーケンス番号、不正使用検出のために利用されるコンポーネント・データの一方向性ハッシュ（ｏｎｅ−ｗａｙ ｈａｓｈ）、又はその後のコード変換プロセスの助けになり得る何らかの他の情報も、メタデータ情報に含まれ得る。更に、メタデータは、コンテンツ・プロバイダ、コード変換プロキシ、及びクライアント装置と互換性のある任意の適当な言語又はフォーマット内にあってもよい。例えば、メタデータは、拡張可能マークアップ言語（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ − ＸＭＬ）でも書かれてもよい。なお、ＭＰＥＧは、ＸＭＬの変形である。以後、本願で説明されるメタデータは、「メタデータ・ヘッダ」と呼ばれるが、メタデータがメッセージ内のどこにでも実際に存在し、メッセージ又はデータ・ストリームの始めに限定されないことは明らかである。
【００４５】
図９を続けて参照すると、コンテンツ・プロバイダ又はデータ・ソースは、コンポーネントと結合されるべき２つのバージョンのメタデータ情報、即ち、暗号化が行われるバージョンを生成すること（９０３）及び暗号化されてないフォーマットのまま（クリア・テキストのまま）の第２のバージョンを生成すること（９０５）が望ましい。図９は、２つのタイプのメタデータの生成しか示してないけれども、本発明は、同様に、複数のバージョンのメタデータが生成され得ることを意図している。なお、それらのバージョンの各々は、暗号化を受けても或いは受けなくてもよく、単一のバージョンのメタデータしか生成されなくてもよい。結局、メタデータ・ヘッダの２つのバージョンは、他の有用なアプリケーションのうち、不正使用を検出するためにクライアント装置によって使用されることが望ましい。メタデータ・ヘッダのクリア・テキスト・バージョン（９０５による）は、暗号化を受けるメタデータ・ヘッダ（９０３による）と同じである必要はない。しかし、不正使用検出方法がクライアント装置によって使用されると仮定すると、暗号化されるべきメタデータ・バージョンは、少なくとも送信されたメタデータ情報の不正使用を検出するために、メタデータ・ヘッダの２つの受信されたバージョン（９０３、９０５による）をクライアント装置が比較することを可能にするに十分な情報を含まなければならない。
【００４６】
オリジナル・データ９００の各コンポーネント９０６に対して、コンテンツ・プロバイダは、クリア・テキスト・メタデータ・ヘッダ（９０５による）、メタデータ・ヘッダの暗号化バージョン（９０４による）、及び（又は）１つ又は複数のコンポーネントからのデータの暗号化コンポーネント部分９０６を結合した１つ又は複数のメッセージ９０７をクライアント装置への送信のためにアセンブルすることが望ましい。本願では、コンポーネント部分は、特定のコンポーネントを表すデータのサブセットとして定義される。その特定のコンポーネント自体は、マルチメディア・オブジェクト９００を表すデータのサブセットである。オブジェクト９００の各コンポーネント９０６は、１つ又は複数のコンポーネント部分を含むことが望ましく、それらコンポーネント部分の各々は、特定のタイプ及び（又は）機能のデータを含むものとして定義される。例えば、コンポーネントは、暗号化されたデータ部分及びクリア・テキスト・メタデータ部分を含み得る。コンポーネント部分は、圧縮前に、圧縮プロセスから又は暗号化プロセスから生成され得る。アセンブルされたメッセージと関連したクリア・テキスト・メタデータ・ヘッダ（９０５における）は、同じメッセージに組み込まれたコンポーネント部分を識別したり、記述したり、或いはそれに関連付けたりする必要のないメタデータを含み得る。予想される状況では、メタデータは、同じメッセージに組み込まれたコンポーネント部分の必ずしもすべてではないけれども、１つ又は複数のコンポーネント部分を識別及び（又は）記述する。
【００４７】
メタデータ・ヘッダ（９０３における）及び圧縮されたコンポーネント・データ（９０２における）の結合に適用される暗号化アルゴリズム又はプロセス９０４は、コンポーネント及び（又は）コンポーネント部分全体にわたって異なっていてもよい。たとえ各コンポーネントに対する暗号化アルゴリズムが同じであっても、暗号化アルゴリズム（９０４における）への入力として使用される暗号化キーは、メタデータ・ヘッダ（９０３における）、種々のコンポーネントの間で、又はメッセージ９０７におけるコンポーネント部分の間でさえ異なることがある。本質的には、本発明の望ましい実施例は、メッセージの各部分が、それがメタデータ・ヘッダ又はコンポーネント部分であっても、独立して且つ異なって暗号化されることを可能にする。簡単な場合、例えば、各メッセージのすべてのメタデータ・ヘッダ及びすべてのコンポーネント、従って、すべてのコンポーネント部分が、同じアルゴリズム及び同じ暗号化キーを使用して暗号化され得る。暗号手法の分野における既知の専門用語と調和させるためには、当業者には明らかなように、暗号化キーは、公開キー又は対称キーであってもよい。
【００４８】
マルチメディア・オブジェクトの種々のコンポーネントを、任意の付加的に組み込まれた情報と共に表すアセンブルされたメッセージ９０７は、通信チャネルを介してコード変換プロキシに送信されることが望ましい。前述のように、通信チャネル自体は、例えば、セルラ、サテライト、又はマイクロウェーブ・ネットワークを含む専用のデータ回線又は無線通信リンクとして任意の既知の方法で実現され得る。図１０に示されたコード変換プロキシ・オペレーションの望ましい実施例では、コード変換プロセスは、そのコード変換プロキシがマルチメディア・オブジェクトの種々のコンポーネントを表すアセンブルされたメッセージをコンテンツ・プロバイダから受信する時に開始される（１００１）。コード変換プロキシは、クリア・テキスト（即ち、暗号化されてない）部分がその受信されたメッセージに存在するものと仮定して、そのようなクリア・テキストのメタデータ・ヘッダを各アセンブルされたメッセージから抽出することが望ましい（１００２）。抽出されたメタデータ・ヘッダにおいて与えられた情報を使用して、コード変換プロキシは、受信されたメッセージのどの暗号化されたコンポーネント又はコンポーネント部分をフィルタリングすべきかを決定することによって、その受信されたコンポーネントを選択的に操作する（１００３）。マルチメディア・オブジェクト・データをクライアント装置による使用に適したフォーマットに変換するために、他の形式のデータ操作が同様に本発明によって使用され得ることは明らかである。
【００４９】
この説明に関連して、所定のコンポーネント又はそれの部分をドロップ又は置換することを意味するために「フィルタリング」という用語が使用されるが、コード変換オペレーションによって要求され得るような他の適当な変換オペレーションが本発明によって同様に意図される。コード変換プロキシは、単一のメッセージのメタデータ・ヘッダによって与えられた情報における、又は複数のメッセージのメタデータ・ヘッダに含まれた情報におけるコンポーネント又はコンポーネント部分をフィルタリングすべきか否かの判断をベースとすることが望ましい。そこで、プロキシは、メタデータ情報によって識別されているメッセージの部分をドロップするか、メッセージ全体をドロップするか、又は、そのようなメッセージ部分がデータ置換を受けることをメタデータが表しているものと仮定して、そのメッセージの所定部分を他のデータと置換することがあり得る。本願では、メッセージの一部分が、そのメッセージにおける１つ又は複数の暗号化されたコンポーネント部分として定義される。フィルタリング・プロセスの後に残っていて、全体的に又は部分的に修正されたメッセージが、オリジナル・データ（例えば、マルチメディア・オブジェクト）の安全にコード変換されたバージョンを構成する。これらのコード変換されたメッセージの各々は、その後、通信チャネルを介してクライアント装置に送信される（１００４）。
【００５０】
本発明によれば、コード変換プロキシによるデータ操作（例えば、選択的にフィルタリングする、即ち、暗号化された注釈コンポーネントをドロップ又は置換する操作）のプロセスは、結果として生じるマルチメディア・オブジェクトのサイズが、オブジェクトを表す如何なるデータ（即ち、コンポーネント）の圧縮解除化も必要とすることなく、媒介物によって圧縮されるので、安全なコード変換目的を達成する。各メッセージに伴うデータ・ヘッダ又は他の適当な同等の注釈データは、どのコンポーネントをフィルタリングすべきか及びどのコンポーネントをクライアント装置に送るべきかに関する決定を行うに十分なそのコンポーネントに関する意味的な理解によってコード変換プロキシを供給することが望ましい。
【００５１】
コード変換のための一般的な方法は、対照的に、別個のメタデータ・ヘッダ又は同様の注釈を使用するのではなく意味的な理解を行うデータ自体に依存するということを想起することが重要である。従って、そのような伝統的なコード変換技法は、データをコード変換するために必要な意味情報に対するアクセスを得るために、先ず、データが暗号化解除されることを必要とする。本発明は、それがこの要件を回避するという点で有利であり、暗号化され且つ注釈付きのコンポーネント化されたコンテンツの選択的なフィルタリングによるコード変換が安全なコード変換（例えば、暗号化されたデータのサイズの圧縮）を、そのデータが媒介物によって暗号化解除されることを必要とすることなく、達成できることを示す。このように、終端間のセキュリティが本発明のシステムによって維持される。
【００５２】
次に、図１１を参照すると、本発明の望ましい実施例に従って、クライアント装置の処理のための流れ図が示される。クライアント装置は、専用のデータ回線又は無線通信リンクのような通信チャネルによってコード変換プロキシに動作関係に接続されることが望ましいということを想起してほしい。クライアント装置又はブラウザにおけるデコーディング・プロセスが、コード変換プロキシによって送信される変換されたメッセージ・コンポーネントの受信（１１０１）によって始まる。受信された各メッセージに対して、クライアント装置が、メッセージに含まれたメタデータ・ヘッダの暗号化された部分を暗号化解除し（１１０２）、その暗号化解除されたヘッダ・バージョンとメッセージに組み込まれたクリア・テキストのメタデータ・ヘッダとを比較し、又は検証する（１１０３）ことが望ましい。それら２つのヘッダ・バージョン（即ち、暗号化解除されたバージョン及びクリア・テキスト）が一致するかどうかを決定するための基準がクライアント装置自体によって決定されることが望ましく、従って、その一致が厳密である必要がないことは明らかである。更に、コード変換システム全体によって必要とされる一致の程度がコンテンツ・プロバイダによって決定され得るということも同様に意図される。
【００５３】
２つのメタデータ・ヘッダ・バージョンが一致しない場合（１１０６）、クライアント装置は、メタデータ情報の不正使用があったことを任意の適当な方法でユーザに表示することが望ましい。そのような不正使用の表示が可視的なもの、例えば、クライアント装置によって表示されるインディケータ・ライト又はテキスト・メッセージであってもよく、或いは、そのような表示が、可聴的な形式のものであってもよい。２つのメタデータ・ヘッダが一致する（即ち、不正使用が検出されなかった）場合（１１０７）、クライアント装置は、メッセージの暗号化されたコンポーネント部分の処理を続けることが望ましい。メタデータ・ヘッダが暗号化解除された直後にクライアント装置がその暗号化されたコンポーネント・データを暗号化解除する場合、メッセージの圧縮解除／デコーディングだけがこの時点で行われるであろう。代わりに、ステップ１１０３がそのデータを検証した後、クライアント装置がその暗号化されたコンポーネント・データを暗号化解除する場合、暗号化されたコンポーネント・データの暗号化解除及び圧縮解除／デコーディングの両方が遂行されるであろう。
【００５４】
暗号化された一方向ハッシュ（メッセージ内のコンポーネント部分の不正使用を検出するためのもの）、シーケンス番号、又はタイム・スタンプのようなその暗号化されたメタデータ・ヘッダに組み込まれた他の情報が、不正使用検出オペレーションを更に拡張してマルチメディア・オブジェクト全体にわたるクロス・メッセージの不正使用を考察するために使用され得ることは明らかである。例えば、暗号化されたメタデータ・ヘッダがコンポーネント部分の１つ又は複数の暗号化された一方向ハッシュを含む場合、暗号化されたコンポーネント部分の不正使用はクライアント装置によって高い確率で検出され得る。更に、暗号化されたメタデータ・ヘッダが、「これはＫのメッセージ１である」、「これはＫのメッセージ２である」等のようなシーケンス番号を含む場合、クライアント装置は、クライアント装置によって使用される不正使用の定義次第で、不正使用を暗示し得る一連の受信データにおいて１つ又は複数の紛失コンポーネントを検出できるであろう。
【００５５】
単なる例として、図１２は、本発明に従って形成された安全なコード変換システムのブロック図を示す。図１２に示されるように、システム全体は、コンテンツ・プロバイダ又は同様のデータ・ソース、コード変換プロキシ、及びコード変換されたデータの予定された受信者としてのクライアント装置を含むことが望ましい。図１２の構成では、コンテンツ・プロバイダからのアセンブルされたメッセージが共用の通信チャネルを介してコード変換プロキシに送信される。この実施例では、１つ又は複数のマルチプレキシング（ＭＵＸ）／デマルチプレキシング（ＤＥＭＵＸ）機能１２０８、１２０９、１２１０、及び１２１９が示されるが、これらの機能は、エンコーディング機能が実装される基礎オペレーティング・システムによっても提供され得る。本発明のもう１つの実施例では、各アセンブルされたメッセージ又はコンポーネントが、別のパスを通ってコード変換プロキシに到達してもよく、従って、マルチプレキシング及びデマルチプレキシングの必要性が本質的に排除され得る。
【００５６】
この安全なコード変換システムのコンテンツ・プロバイダ側に関して、オリジナル・ソース・データ・オブジェクトが、便宜上、２つのコンポーネントにコンポーネント化される（１２０１）。「Ｍ」１２０６と呼ばれる機能的ボックスがメタデータ・ヘッダを生成するために使用され、「Ｈ」１２０７と呼ばれる機能的ボックスが対応するクリア・テキスト・マルチメディア・ヘッダを生成するために使用される。クリア・テキスト・メタデータの生成は、メタデータ・ヘッダ１２０６に対して既に生成されている情報を使用することが望ましいであろう。最も簡単な場合、メタデータ・ヘッダの両バージョンが同じであることが望ましいであろうが、本発明はこの方法に限定されない。コンポーネント１に対する暗号化されるべきメタデータ・ヘッダは、「メタデータ１」と呼ばれるが、コンポーネント１に対するメタベータ・ヘッダの対応するクリア・テキスト・バージョンは、「メタデータ１Ｂ」と呼ばれる。同様に、コンポーネント２に対する暗号化されるべきメタデータ・ヘッダは、「メタデータ２」と呼ばれ、コンポーネント２に対するメタデータ・ヘッダの対応するクリア・テキスト・バージョンは、「メタデータ２Ｂ」と呼ばれる。
【００５７】
プロセス１２０６及び１２０７によって生成されたメタデータ・ヘッダ１及び１Ｂは、コンポーネント１のデータからのみ取り出されることが望ましい。メタデータ・ヘッダは、圧縮１２０２に起因する情報の既存のパケット又はコンポーネントに付加される（１２０３）。第１に、メタデータ・ヘッダ１が、コンポーネント１の圧縮されたデータに付加され、このコレクションが暗号化される（１２０４）。第２に、クリア・テキストのメタデータ・ヘッダ１Ｂが、メタデータ・ヘッダ及び圧縮されたコンポーネント・データを含む暗号化されたコレクションに付加される（１２０５）。第２の付加オペレーション１２０５の出力は、アセンブルされたメッセージ１である。この例では、メッセージ１のすべての部分（クリア・テキスト・メタデータ・ヘッダ、暗号化されたメタデータ・ヘッダ、及び暗号化されたコンポーネント・データ）がコンポーネント１から排他的に取り出され、他のいずれのコンポーネントからも取り出されないことが望ましい。同様に、他のメッセージがコンポーネント２に基づいて排他的に生成される。この例は、１つのコンポーネントを複数のコンポーネント部分に更に分割するという一般的な場合を示すものではなく、１つのメッセージが種々のコンポーネントから生じるコンポ−ネント部分を含み得ることを示すものでもないが、これらのすべてが本発明の技術範囲内にあることに留意してほしい。更に、メッセージのアセンブリは、図１２に示されるように、２つの順次付加オペレーションに限定されない。
【００５８】
次に、図１２の例示的システムにおけるコード変換プロキシを参照すると、そのコード変換プロキシは、２つのコンポーネントを受信するものとして示される。これらのコンポーネントは、デマルチプレックスされ（１２０９）、それらのクリア・テキスト・メタデータ・ヘッダが（メタデータ１Ｂ及びメタデータ２Ｂとして）抽出される（１２１３）ことが望ましい。この例では、コード変換プロキシは、コンポーネント２をドロップする（１２１１）こと及び残りのコンポーネント１をそれの宛先、即ち、クライアント装置に向けて搬送することによってそれらのコンポーネントを操作する。しかし、一般には、Ｋ個のメッセージが存在し得るし、プロキシは、これらのメッセージのうちのＬ個をドロップし得る。但し、ＬはＫよりも小さいか又はＫに等しい。プロキシは、フィルタリングのようなこと（例えば、メッセージ又はメッセージ部分を代用すること）によって残りのＫ−Ｌ個のメッセージを修正し得る。残りのメッセージは、その後、１２１２において再アセンブルされ得る（例えば、メタデータ・ヘッダは、それらと共に到着したそれぞれのデータと結合される）。
【００５９】
フィルタリング・プロセスそのものに関して、１つのメッセージを１つのコンポーネントに排他的にマッピングする効果は、コード変換プロキシのダウンストリームが、相互に関してそれらコンポーネントの相対的な重要度に基づくのではなくむしろ絶対的な優先順位情報に基づいたそれのフィルタリング判断だけを基礎にすることができる。換言すれば、例えば、メッセージ１を受信するコード変換プロキシは、それの対応するメタデータ・ヘッダ１Ｂを調べるであろう。なお、メタデータは、他のコンポーネント情報に基づくものではないので、メタデータ・ヘッダ１Ｂは、コンポーネント１の絶対的な重要度だけしか伝達することができない。例えば、メッセージ１は、絶対的な優先順位５０を持つものとしてそれ自身を説明し得る。プロキシが、混雑時に１０よりも低い優先順位を有するすべてのパケット／メッセージをドロップするというポリシを利用する場合、そのプロキシは、このメッセージをドロップするという決定を行わないであろう。プロキシがこの判断をするに当たり、マルチメディア・オブジェクトの他のコンポーネントに関する更なる情報は必要ない。比較的簡単なアーキテクチャを必要とするけれども、幾つかの理由で、この方法は、すべてのアプリケーションに対して十分に適合し得ないことがある。
【００６０】
従って、本発明の安全なコード変換アーキテクチャは、相互に関してコンポーネントの相対的な重要度／優先順位に基づいて特定のコンポーネントをフィルタリングすべきか（或いは、操作／変換すべきか）どうかの決定を基礎としているケースを同様にサポートすると云うことに留意することが重要である。この実施例では、１つ又は複数のメッセージからのメタデータ・ヘッダは、プロキシにおいて収集されそしてプロキシがどのコンポーネント、コンポーネント部分及び（又は）メッセージをフィルタリングすべきか決定し得る前に比較されなければならない相対的ランキング又は優先順位又は優先順位情報を含むことが望ましい。例えば、コンポーネント１は、絶対的な優先順位の代わりにそれの相対的な重要度（例えば、コンポーネント１がコンポーネント２よりも重要である又は高い優先順位を有するということ）だけしか伝達し得ない。この場合、プロキシは、それのフィルタリングの判断を行う前に十分なメタデータ情報を収集するために所定の期間待機しなければならない。
【００６１】
図１２の例示システムにおけるクライアント・サイドの処理に関して、デマルチプレックスされた（１２１９）各コンポーネントに対し、クライアント装置は、先ず、クリア・テキスト・メタデータ・ヘッダ（メタデータ１Ｂ）を抽出する（１２１８）ことが望ましい。このクリア・テキスト・メタデータは、メタデータ・ヘッダ（メタデータ１）の暗号化解除バージョンとのその後の比較（１２１４）のために記憶されることが望ましい。クリア・テキスト・メタデータ・ヘッダを抽出した後、クライアント装置は、暗号化されたメタデータ・ヘッダ及び暗号化されたコンポーネント・データの両方を暗号化解除する（１２１７）ことが望ましい。そこで、暗号化解除されたメタデータ・ヘッダ（メタデータ１）がその暗号化解除されたコンポーネント・データから抽出され（１２１６）、起こり得る不正使用を検出するためにクリア・テキスト・メタデータ・ヘッダに比較される（１２１４）。不正使用が見つからなかったと仮定すると、クライアント装置は、ユーザへお表示のためにコンポーネント・データを圧縮解除する（１２１５）ことが望ましい。不正使用が検出された場合（メタデータ・ヘッダのそれら２つのバージョンが受容可能な程度まで一致しない場合）、クライアント装置の能力次第で、不正使用の表示がユーザに与えられることが望ましい。別の方法として、クライアント装置は、データを、破壊された可能性のあるものとして単にを無視するだけであってもよい。
【００６２】
既存の安全ソケット層（ＳＳＬ）インフラストラクチャを使用して本発明のシステムを実現することができる。これの例が図１３に示される。この例の実施方法では、送信者又はコンテンツ・プロバイダ・サイド１３１５におけるセッション・マネージャ１３０３が複数のＳＳＬ接続を形成し、これらＳＳＬ接続をすべて同時に管理することが望ましい。セッション・マネージャ１３０３は、セッション情報がコード変換プロキシ１３１６によりクリア・テキストにおいてインターセプトされるように１つ又は複数の非ＳＳＬ接続を形成する責任もある。望ましくは、コード変換プロキシは、送信者からクリア・テキスト・チャネルを通して送られたメタデータに基づいて、ＴＣＰ接続がリレーされるか又はドロップされるかを決定する責任があるであろう。受信者又はクライアント・サイド（ブラウザ）のセッション・マネージャ１３１２は、着信チャネルをアセンブルして（１３１４）、ブラウザ１３１７による使用のための単一のメッセージにする責任がある。この実施方法では、個々の各コンポーネントに対するメタデータがセッション・マネージャ間ではセクションｉｄによって暗黙指定されることに留意してほしい。クリア・テキスト・フォーマットであることを必要とする更なるメタデータに関しても、更なる非ＳＳＬ接続によってコミュニケーションが行われることが望ましい。
【００６３】
本発明は、マルチメディア・オブジェクトのようなデータを媒介物又はコード変換プロキシによって安全にコード変換するための手段を可能にするネットワークされた情報を配布散するための方法及び装置を提供する。ソース・データは、先ず、コンポーネント・プロバイダにおいて、オリジナル・ソース・データを表す複数のデータ・コンポーネントにコンポーネント化される。暗号化されてないメタデータ・ヘッダが、プロキシにメッセージとして送られる前に各コンポーネントに付加される。プロキシは、受信したメッセージから取り出された暗号化されてない（クリア・テキスト）メタデータ又はデータ・コンポーネントの意味的な理解を与える他のデータに基づいてデータ・コンポーネントを操作し、クライアント装置において表示するように適応した所定のコンポーネントだけをクライアント装置に送信する。本発明のシステムによって、コンテンツ・プロバイダからのネットワークされた情報は、コンテンツ・プロバイダに動作関係に接続されたプロキシにより、そのプロキシがソース・データを暗号化解除することなく、安全にコード変換され得る。
【００６４】
本発明の説明的な実施例を、添付図面を参照して開示したけれども、本発明がそれらの詳細な実施例に限定されないこと及び発明の精神から逸脱することなく、他の種々の変更及び修正が当業者によって施され得ることは理解されるべきである。
【図面の簡単な説明】
【図１】
データのチャネル・エンコーディング及びデコーディングのための一般的な通信システムを示すブロック図である。
【図２】
チャネル・エンコーディング及びデコーディングと関連してソース・エンコーディング及びデコーディングを使用する一般的なシステムの一例を示すブロック図である。
【図３】
ソース・コード変換に加えて、ソース及びチャネル・エンコーディング／デコーディングを使用する一般的なシステムを示すブロック図である。
【図４】
サーバ及びクライアントの間にプロキシを含むネットワーク環境においてデータをコード変換するための一般的なシステムを示すブロック図である。
【図５】
ウェブ・サーバからのＧＩＦフォーマットにおけるイメージがコード変換プロキシを通してＪＰＥＧフォーマットに変換され、ブラウザにおいて表示される従来例を示すブロック図である。
【図６】
ウェブ・サーバ及びブラウザの間でデータを安全に送信するための安全ソケット層（ＳＳＬ）を使用するネットワーク環境における通信システムの従来例を示すブロック図である。
【図７】
暗号化されたデータの終端間セキュリティを保証すると同時にコンテンツ・プロバイダ及びクライアントの間でデータを送信するための一般的なシステムを示す概念的なブロック図である。
【図８】
コンテンツ・プロバイダ及びクライアントの間でデータを送信するための一般的なシステムにおけるコード変換プロキシによって引き起こされるセキュリティ問題を示す概念的なブロック図である。
【図９】
本発明の一実施例に従ってデータをエンコード／暗号化するための方法を示す論理的な流れ図である。
【図１０】
図９に示された本発明のシステムを使用してエンコード／暗号化されたデータをコード変換するための方法を示す論理的な流れ図である。
【図１１】
本発明の一実施例に従って、コード変換されたデータを受信する時、クライアント装置においてデータをデコード／暗号化解除するための方法を示す論理的な流れ図である。
【図１２】
本発明の一実施例に従って形成された安全なコード変換システムの３つのコンポーネントを示す概念的なブロック図である。
【図１３】
本発明の他の実施例に従って、プロキシを含むネットワーク環境においてデータをコード変換するための、及び安全ソケット層（ＳＳＬ）を使用するためのシステムを示すブロック図である。
【符号の説明】
９００　オリジナル・データ
９０６　コンポーネント
９０７　メッセージ
【図１】
2004511037.tif 000003
【図２】
2004511037.tif 000004
【図３】
2004511037.tif 000005
【図４】
2004511037.tif 000006
【図５】
2004511037.tif 000007
【図６】
2004511037.tif 000008
【図７】
2004511037.tif 000009
【図８】
2004511037.tif 000010
【図９】
2004511037.tif 000011
【図１０】
2004511037.tif 000012
【図１１】
2004511037.tif 000013
【図１２】
2004511037.tif 000014
【図１３】
2004511037.tif 000015
【国際公開パンフレット】
2004511037.tif 000016
2004511037.tif 000017
2004511037.tif 000018
2004511037.tif 000019
2004511037.tif 000020
2004511037.tif 000021
2004511037.tif 000022
2004511037.tif 000023
2004511037.tif 000024
2004511037.tif 000025
2004511037.tif 000026
2004511037.tif 000027
2004511037.tif 000028
2004511037.tif 000029
2004511037.tif 000030
2004511037.tif 000031
2004511037.tif 000032
2004511037.tif 000033
2004511037.tif 000034
2004511037.tif 000035
2004511037.tif 000036
2004511037.tif 000037
2004511037.tif 000038
2004511037.tif 000039
2004511037.tif 000040
2004511037.tif 000041
2004511037.tif 000042
2004511037.tif 000043
2004511037.tif 000044
2004511037.tif 000045
2004511037.tif 000046
2004511037.tif 000047
2004511037.tif 000048
2004511037.tif 000049
2004511037.tif 000050
2004511037.tif 000051
2004511037.tif 000052
2004511037.tif 000053
2004511037.tif 000054
2004511037.tif 000055
2004511037.tif 000056
2004511037.tif 000057
【国際公開パンフレット（コレクトバージョン）】
2004511037.tif 000058
2004511037.tif 000059
【国際調査報告】
2004511037.tif 000060
2004511037.tif 000061