JP2008527599A - データ再生装置および方法並びに記録媒体 - Google Patents

Abstract

コンデンツプロバイダによって提供されるコンテンツおよびユーザの再生システムを保護することによって、コンデンツプロバイダは安全にコンテンツを提供し、ユーザは安心してコンテンツを再生できるようにし、より便利な機能を提供するデータ再生装置および方法並びに記録媒体を提供する。記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されるタイトルを再生する方法において、前記タイトルに対応するオブジェクトファイルから前記タイトルと関連したアプリケーションを識別する情報を確認するステップと、前記関連したアプリケーションを認証するステップと、前記アプリケーションを実行し、前記タイトルを再生するステップとを含むデータ再生方法が開示される。

Description

本発明は、記録媒体および／またはローカルストレージ内のデータの再生に係り、特に、データ再生装置および方法並びに記録媒体に関する。

記録媒体として大容量のデータを記録できる光ディスクが広く使用されている。なかでも最近では高画質のビデオデータと高音質のオーディオデータを長時間記録して保存することのできる新しい高密度記録媒体、例えば、ブルーレイディスク(以下、「ＢＤ」という。)が開発されてきている。

次世代記録媒体技術であるＢＤは、既存のＤＶＤを顕著に凌駕するデータを備えうる次世代光記録ソリューションとされ、近来、他のデジタル機器と共にこれに対する開発が行われている。

光記録／再生器は、ＢＤを記録／再生する基本機能の他に、周辺の関連デジタル機器との統合的な使用を考慮した付加的な機能も考慮しなければならない。よって、外部入力信号を受信してこれをディスプレイする一般機能と、外部入力信号と共にＢＤを再生する機能は必ず備えるべきと思われる。

そこで、ＢＤの規格を応用した光記録／再生器が開発し始まっているが、未だＢＤの標準規格は完備しておらず、完成した光記録／再生器を開発するのには多くの制約がある。

特に、コンテンツプロバイダによって提供されたコンテンツとユーザの再生システムを保護する好ましい方法などは知られておらず、本格的なＢＤ基盤の光記録／再生器を開発するのには多くの制約があるのが現状である。

したがって、本発明は、関連技術の限界および欠点による一つ以上の問題点を実質的に防止するデータ再生装置および方法並びに記録媒体に関する。

本発明の１つの目的は、真正なコンデンツプロバイダによって提供されるコンテンツとユーザの再生システムを保護するデータ再生装置および方法並びに記録媒体を提供することにある。

本発明の他の目的は、アプリケーションを認証しこのアプリケーションを実行することによって、コンテンツと再生システムを保護するデータ再生方法および再生装置並びに記録媒体を提供することにある。

本発明の付加的な利点、目的および特徴は、本技術分野における当業者にとっては下記の説明における本発明の説明から明らかになるだろう。本発明の目的および他の利点は、添付の図面と特許請求の範囲および詳細な説明に具体的に指摘された構造によって実現および取得されることができる。

上記の目的を達成するために、本発明は、記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されるタイトルを再生する場合において、前記タイトルに対応するオブジェクトファイルから前記タイトルと関連付けられたアプリケーションを識別する情報を確認するステップと、前記関連付けられたアプリケーションを認証するステップと、前記アプリケーションを実行し、前記タイトルを再生するステップとを含むデータ再生方法を提供する。

例えば、前記アプリケーションは、このアプリケーションを構成するファイルの認証によって認証される。

例えば、前記ファイルは、ＪＡＲファイルである。

例えば、前記ファイルの認証は、前記ファイル内の署名ブロックファイルを用い、前記アプリケーションに署名したエンティティの電子署名を検証することを含む。

例えば、前記検証は、前記署名ブロックファイル内の公開キーを用いて行われる。

例えば、前記公開キーは、前記電子署名の生成に使われた個人キーに対応する公開キーである。

例えば、前記検証は、前記署名ブロックファイル内の認証書チェーンの認証書を検証することを含む。

例えば、前記ファイルの認証は、前記ファイル内の署名ファイルを用いて、前記ファイル内のマニフェストファイルの完全性を確認することを含む。

例えば、前記ファイルの認証は、前記ファイル内のマニフェストファイルを用いて、前記ファイルの実際データに対する完全性を確認することを含む。

例えば、前記認証は、ジャバ仮想マシンで行われる。

例えば、前記認証が失敗した場合、前記アプリケーションが実行されない。

例えば、前記認証が失敗した場合、前記アプリケーションはジャバ仮想マシンのサンドボックス（Ｓａｎｄｂｏｘ）内で実行される。

例えば、前記情報は、アプリケーション管理テーブル（ＡＭＴ）である。

また、本発明は、コンテンツの記録されるデータ領域と、前記コンテンツの再生を管理する管理領域とを含み、前記データ領域には、少なくとも一つの署名されたアプリケーションを含んで構成されたタイトルが記録され、前記管理領域には、前記タイトルと関連付けられたアプリケーションを識別する情報を含むオブジェクトファイルが記録され、前記署名されたアプリケーションは署名ファイルおよび署名ブロックファイルを含む記録媒体を提供する。

例えば、前記署名ファイルは、前記アプリケーションに対するマニフェストファイルのダイジェストを含む。

例えば、前記ダイジェストは、前記マニフェストファイルをＳＨＡ−1ダイジェストアルゴリズムに適用して算出される。

例えば、前記署名ブロックファイルは、前記アプリケーションに署名したエンティティの電子署名を含む。

例えば、前記電子署名は、署名アルゴリズムによって前記署名ファイルのダイジェストを前記エンティティの個人キーで暗号化して生成される。

例えば、前記署名アルゴリズムはＲＳＡである。

また、本発明は、記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されたタイトルに対応するオブジェクトファイルから、前記タイトルと関連付けられたアプリケーションを識別する情報を確認し、前記関連付けられたアプリケーションを認証する制御部と、前記アプリケーションの実行によって前記タイトルを再生するデコーダとを含むデータ再生装置を提供する。

例えば、前記制御部は、前記アプリケーションを構成するファイルのデータがジャバ仮想マシンにロードされる間に前記ファイルを認証することによって、前記アプリケーションを認証する。

例えば、前記認証は、前記ファイル内の署名ブロックファイルを用いて、前記ファイルに署名したエンティティの電子署名を検証することを含む。

例えば、前記検証は、前記署名ブロックファイル内の公開キーを用いて行われる。

例えば、前記公開キーは、前記電子署名の生成に用いられた個人キーに対応する公開キーである。

例えば、前記認証は、前記ファイル内の署名ファイルを用いて、前記ファイル内のマニフェストファイルの完全性を確認することを含む。

例えば、前記認証が成立しない場合、前記制御部は、前記アプリケーションが実行されないように制御する。

例えば、前記認証が成立しない場合、前記制御部は、前記アプリケーションがジャバ仮想マシン内のサンドボックス（ｓａｎｄｂｏｘ）で実行されるように制御する。

本発明についての上記の一般的な説明および次の詳細説明は、例示的な説明に過ぎないもので、請求された本発明をより明瞭に説明するために提供されたものとして解釈されなければならない。

以下、本発明の好適な実施例を、添付の図面を参照しつつ詳細に説明する。図面中、同一の構成要素には可能な限り同一の参照番号を付する。

以下、本発明は、説明の便宜上、記録媒体として光ディスク、特に「ブルーレイディスク（ＢＤ）」）について説明するが、本発明の技術思想は他の記録媒体にも同一に適用可能であることは明らかである。

本発明において「ローカルストレージ」とは、光気録／再生装置（図１）内に備えられた一種の保存手段で、必要な情報およびデータをユーザが任意に保存して用いる要素のことを意味する。すなわち、現在、一般に使われるローカルストレージには、「ハードディスク」、「システムメモリ）」、「フラッシュメモリ」などがあるが、本発明では、この限りではない。

特に、本発明において、「ローカルストレージ」は記録媒体（例えば、ブルーレイディスク）と関連したデータを保存する手段としても用いられる。この記録媒体と関連してローカルストレージ内に保存されるデータは、通常、外部からダウンロードされる。

なお、記録媒体から一部許容されたデータが直接読み取られる、または、記録媒体の記録／再生と関連したシステムデータ（例えば、ｍｅｔａｄａｔａ等）が生成されて前記ローカルストレージに保存されることも可能であることは明らかである。

説明の便宜のために、記録媒体に記録されたデータを「オリジナルデータ」と命名し、ローカルストレージに保存されたデータのうち、記録媒体と関連したデータを「アディショナルデータ」と命名する。

本発明において「タイトル」とは、ユーザとのインターフェースをなす再生単位で、それぞれのタイトルは、特定のオブジェクトファイルとリンク（ｌｉｎｋ）されており、このオブジェクトファイル内のコマンドあるいはプログラムによって、ディスクに記録されたこのタイトルに対するストリームが再生される。説明の便宜上、ディスクに記録されたタイトルのうち、ＭＰＥＧ２圧縮方式による動映像映画およびインタラクティブ情報の記録されたタイトルを特に「ＨＤＭＶタイトル」と命名し、ジャバプログラムによって実行される動映像映画およびインタラクティブ情報の記録されたタイトルを「ＢＤ−Ｊタイトル」と命名する。

本発明においてタイトルは、インデックステーブルに存在するインデクシング項目を意味することもある。すなわち、記録媒体がロードされると、最初に再生される画面に関する情報を持つ「Ｆｉｒｓｔ Ｐｌａｙｂａｃｋ」と、メニュー画面を提供する「Ｔｏｐ Ｍｅｎｕ」も同様にタイトルの一種である。すなわち、ユーザとインターフェースをなす再生単位であれば、その名称にかかわることなくいずれも本発明のタイトルに該当するわけである。

また、このタイトルは、記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されることを特徴とする。ローカルストレージ内のデータは、タイトルの再生中にダウンロードされるデータを含むことができる。

図１は、本発明の概念的理解を助けるためのもので、光記録／再生器１０と周辺機器間の統合的な使用を説明する図である。

図１を参照すると、本発明の「光記録／再生器１０」は、多用途な規格の光ディスクを記録または再生可能な機器で、設計によっては特定規格（例えば、ＢＤ）の光ディスクのみを記録／再生可能にしても良く、また、記録は除いて再生のみ可能にしても良い。以下では、本発明が解決しようとするブルーレイディスク（ＢＤ）と周辺機器とのインタラクティビティを考慮し、ブルーレイディスク（ＢＤ）を再生するプレーヤー（ＢＤ−Ｐｌａｙｅｒ）またはブルーレイディスク（ＢＤ）を記録／再生するレコーダ（ＢＤ−Ｒｅｃｏｒｄｅｒ）を例にして説明する。本発明の「光記録／再生器１０」は、コンピュータなどに内蔵可能な「ドライブ」になりうることは周知の事実である。

本発明の光記録／再生器１０は、光ディスク３０を記録／再生する機能の他にも、外部入力信号を受信してこれを信号処理した後、他の外部ディスプレイ２０を介してユーザに画面として伝達する機能を持つ。この場合、入力可能な外部信号には特に制限はないが、デジタルマルチメディア放送およびインターネットなどがその代表になりうる。特に、インターネットは、現在誰でも容易に接近できる媒体で、光記録／再生器１０を介してインターネット上の特定データをダウンロードして用いれば良い。

これと関連して、外部ソースとしてコンテンツを提供する者を「コンデンツプロバイダ（ＣＰ）」と総称する。

本発明において、タイトルを構成するコンテンツは、記録媒体の製作者によって提供されるデータのことを意味する。

特に、本発明は、コンデンツプロバイダによって提供されるコンテンツを保護するとともに、ユーザの再生システムを保護することに関する。

オリジナルデータとアディショナルデータについて具体的に説明すると、次の通りである。例えば、光ディスクに記録されたオリジナルデータとしては、特定タイトル用の多重化されたＡＶストリームを記録しておき、インターネット上のアディショナルデータとしては、オリジナルデータのオーディオストリーム（例えば、韓国語）と異なるオーディオストリーム（例えば、英語）を提供すると、ユーザにとっては、インターネット上のアディショナルデータであるオーディオストリーム（例えば、英語）をダウンロードし、オリジナルデータであるＡＶストリームと共に再生したい要求、または、アディショナルデータのみを再生したい要求がありうる。これを実現可能にするには、オリジナルデータとアディショナルデータ間の連関性が規定されなければならなく、また、これらのデータをユーザの要求に応じて管理／再生する体系化した方法が必要とされる。

上記では、説明の便宜上、ディスクに記録された信号をオリジナルデータとし、ディスクの外部に存在する信号をアディショナルデータとしたが、これは、それぞれのデータを取得する方法によって区分しただけで、オリジナルデータとアディショナルデータが必ずしも特定のデータに限定されるわけはない。

したがって、一般に、オーディオ、プレゼンテーショングラフィック（ＰＧ：Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃ）、インタラクティブグラフィック（ＩＧ：Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃ）、テキストサブタイトルなどがアディショナルデータに該当するが、これに限定されることはない。これら列挙したデータとビデオを全部含む多重化されたＡＶストリームが、アディショナルデータになっても良い。すなわち、光ディスクの外部に存在しながら、オリジナルデータと関連付けられたデータであれば、いずれの属性のデータもアディショナルデータになることができる。

また、アディショナルデータは、インデックスファイル（ｉｎｄｅｘ）、プレイリストファイル（＊．ｍ２ｔｓ）またはクリップ情報ファイル（＊．ｃｌｐｉ）別に、それぞれダウンロードされることができる。また、コンテンツ単位またはタイトル単位にダウンロードされることも可能である。

上記のユーザの要求を実現可能にするためには、オリジナルデータとアディショナルデータの相互間のファイル構造を必ず持つことが重要である。以下、図２および図３に基づいて、ブルーレイディスク（ＢＤ）で使用可能なファイル構造およびデータ記録構造について詳細に説明する。

図２は、本発明の記録媒体に記録されるファイル構造を示す図である。

図２を参照すると、本発明の再生管理ファイル構造は、一つのルートディレクトリの下に少なくとも一つのＢＤＭＶディレクトリが存在する。このＢＤＭＶディレクトリ内には、ユーザとのインタラクティビティを保障するための一般ファイル（上位ファイル）情報としてインデックスファイル（「ｉｎｄｅｘ．ｂｄｍｖ」）およびオブジェクトファイル（「ＭｏｖｉｅＯｂｊｅｔ．ｂｄｍｖ」）が位置する。なお、ＢＤＭＶディレクトリは、実際ディスクに記録されたデータに関する情報とこれを再生する方法などに関する情報を持つディレクトリで、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリと、ＢＤ−Ｊオブジェクトファイルを含むＢＤＪＯディレクトリと、ＪＡＲファイルを含むＪＡＲディレクトリとを含み、ディスク再生に関連した補助データからなるＡＵＸＤＡＴＡディレクトリを含む。以下、ディレクトリおよびディレクトリ内に含まれるファイルについて詳細に説明する。

ＳＴＲＥＡＭディレクトリは、ディスク内に特定フォーマットで記録されたＡＶストリームファイルを含み、ストリームファイル（０１０００．ｍ２ｔｓ，…）の拡張名として「＊．ｍ２ｔｓ」を使用する。特に、一般に、動映像データが本発明と関連したコンテンツとしてストリームファイルに記録される。

ＣＬＩＰＩＮＦディレクトリは、それぞれのストリームファイルと一対一対応するクリップ情報ファイル（ｃｌｉｐ ｉｎｆｏｒｍａｔｉｏｎ ｆｉｌｅ）（０１０００．ｃｌｐｉ，…）を含む。特に、クリップ情報ファイル（＊．ｃｌｐｉ）は、対応するストリームファイルの属性情報およびタイム情報（ｔｉｍｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）等を含んでいる。特に、ストリームファイル（＊．ｍ２ｔｓ）と一対一対応するクリップ情報ファイル（＊．ｃｌｐｉ）をまとめて「クリップ（ｃｌｉｐ）」と命名する。すなわち、一つのストリームファイル（＊．ｍ２ｔｓ）には必ず対応するクリップ情報ファイル（＊．ｃｌｐｉ）が存在することになる。

ＰＬＡＹＬＩＳＴディレクトリは、プレイリストファイル（０００００．ｍｐｌｓ，…）を含む。それぞれのプレイリストファイル（＊．ｍｐｌｓ）は、特定クリップが再生される時間間隔を指定する少なくとも一つのプレイアイテムを含んでいる。プレイアイテムは、再生したい特定クリップ、すなわち、プレイアイテム内でクリップ名（クリップ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｆｉｌｅ＿ｎａｍｅ）によって指定されるクリップの再生開始時間（ＩＮ−Ｔｉｍｅ）と再生終了時間（ＯＵＴ−Ｔｉｍｅ）に関する情報を持っている。

すなわち、プレイリストファイル（＊．ｍｐｌｓ）は、少なくとも一つのプレイアイテムの組合によって所望のクリップの再生を行う、全体再生管理ファイル構造内の基本的再生管理ファイル単位である。

特に、プレイリストファイル（＊．ｍｐｌｓ）は、前述したオブジェクトファイル内の特定オブジェクトによるコマンドに応じてのみ動作する。したがって、ディスク再生シナリオ観点で、オブジェクトファイルは動的なシナリオを、プレイリストファイル（＊．ｍｐｌｓ）は静的なシナリオを実行または管理する。

ＢＤＪＯディレクトリは、ＢＤ−Ｊタイトルを再生するためのＢＤ−Ｊオブジェクトファイルを含む。

ＪＡＲディレクトリは、ＢＤ−Ｊのための全ての「ｘｘｘｘｘ．ＪＡＲ」ファイルを含む。ＪＡＲ（Ｊａｖａ ａｒｃｈｉｖｅ）ファイルは、複数のファイル集を配布するのに使われる圧縮ファイルで、このＪＡＲファイルは、通常、特定ジャバプログラムと関連したジャバクラスファイル、補助リソース、メタデータなどで構成される。様々なアプリケーションがＪＡＲファイルによって構成されることができる。

ＡＵＸＤＡＴＡディレクトリは、ディスク再生と関連した補助的な情報を含むファイルで構成される。例えば、再生時にクリックサウンドおよびメニューサウンド情報などを提供するサウンドファイル（「Ｓｏｕｎｄ．ｂｄｍｖ」）と、テキストサブタイトルの再生時にフォント情報を提供するフォントファイル（「１１１１１．ｏｔｆ」）を含むことができる。

ＭＥＴＡディレクトリは、メタデータを備える。メタデータは、データに対するデータで、サーチファイルまたはディスクライブラリ用ファイルなどを含む。

上述のファイルおよびディレクトリの位置は一実施例に過ぎず、場合によって、その位置が変更可能であることは自明である。例えば、ＢＤ−Ｊオブジェクトディレクトリ（ＢＤＪＯ）とジャバディレクトリ（ＪＡＲ）をサブディレクトリとして持つディレクトリが、ルートディレクトリの下に別に構成される、または、ジャバディレクトリが上位ディレクトリとしてルートディレクトリの下に構成されても良い。

また、ルートディレクトリは、記録媒体に記録されたデータおよび／またはローカルストレージにダウンロードされるデータの保護に関する情報を含むディレクトリを含むことができる。図２の認証書（ＣＥＲＴＩＦＩＣＡＴＥ）ディレクトリがそれである。アプリケーションおよびバインディングユニットの認証に用いられるルート認証書ファイルが、認証書ディレクトリに含まれる。

図３は、本発明によって光ディスクに記録されるデータ記録構造を示す図で、前述したファイル構造に関連した情報がディスク内に記録される形態を示している。

図３を参照すると、ディスクの内周から、全体ファイルを管理するためのシステム情報としてのファイルシステム情報領域（、記録されたストリーム（＊．ｍ２ｔｓ）を再生するためのインデックスファイル、オブジェクトファイル、プレイリストファイル、クリップ情報ファイルおよびメタデータファイルが記録された領域（データベース領域）、および、オーディオ／ビデオ／グラフィックなどで構成されたストリームまたはＪＡＲファイルが記録されるストリームまたはデータ領域が存在する。

また、前記データ領域内のコンテンツを再生するためのファイル情報などを記録する領域を管理領域といい、ファイルシステム情報領域（およびデータベース領域）がこれに該当する。ただし、図３の各領域は一例として提示したもので、本発明が図３に示す各領域の配列構造に限定されないことは明らかである。

図４は、本発明の一実施例による光記録／再生器を示すブロック図である。

図４を参照すると、本発明の光記録／再生器は、基本的に、光ディスクに記録されたオリジナルデータおよび再生管理ファイル情報を含む管理情報を再生するためのピックアップ１１と、ピックアップ１１の動作を制御するサーボ１４と、ピックアップ１１から受信した再生信号を所望の信号値に再生し、または、記録される信号を光ディスクに記録可能な信号に変調して伝達する信号処理部１３と、全般動作を制御するマイコン１６とを含む。

制御部１２は、ユーザ命令などによって光ディスクの外部に存在するアディショナルデータをダウンロードしてローカルストレージ１５に保存する。また、制御部１２は、ローカルストレージ１５内のバインディングユニットマニフェストファイルに記録された情報を用いてバインディングユニットを生成し、記録媒体データとローカルストレージ内のデータを再生するために、バインディングユニットマニフェストファイルに記録されたネームマッピング情報を用いて、仮想パッケージを生成する。制御部１２は、前記生成された仮想パッケージを用いて、オリジナルデータおよび／またはアディショナルデータをユーザの要求に応じて再生する。

仮想パッケージは、仮想ファイルシステムによって行われるバインディング動作で生成され、異なる領域にそれぞれ保存されている、ディスク内のオリジナルデータで構成されたオリジナルクリップとローカルストレージ内のアディショナルデータで構成されたアディショナルクリップを再生管理するファイル構造である。

バインディングユニットマニフェストファイルは、仮想パッケージを生成するバインディング動作に用いられる情報を含む。バインディングユニットマニフェストファイルがないと、ローカルストレージ１５内のデータを記録媒体内のファイル構造（ディスクパッケージ）とバインディングできず、仮想パッケージの生成が不可能となる。

ネームマッピング情報は、バインディングユニットマニフェストファイルに記録されている情報で、バインディングユニットと記録媒体内に記録されたデータが仮想パッケージにおいて存在すべき位置を指定する。

新しく生成された仮想パッケージは、以降の再利用のためにローカルストレージ１５に保存される、または、別のダイナミックメモリに一時的に保存されて用いられる。

本発明において、制御部１２は、実行されるアプリケーションが欠陥のないアプリケーションなのかを認証した後、このアプリケーションを実行させる。これにより、権限のないエンティティによって配布されたアプリケーションが、真正なコンデンツプロバイダが提供したコンテンツにアクセスするのを防止する。しかも、アプリケーションの悪意的な作用からユーザの再生システムを保護することが可能になる。このアプリケーションの認証については図５を参照して後述する。

再生システム１７は、制御部１２の制御によって出力データを最終的にデコードしてユーザに提供する。再生システム１７は、特に、ＡＶ信号をデコードするデコーダと、前述した特定タイトルの再生と関連してオブジェクトコマンドあるいはアプリケーションおよび制御部１２から入力されるユーザ命令を解析することによって再生方向を決定するプレーヤーモデルを含む。この再生システム１７は以降、 図５で詳細に説明される。

ＡＶエンコーダ１８は、光ディスクに信号を記録する機能を行うために、制御部１２の制御によって入力信号を特定フォーマットの信号、例えば、ＭＰＥＧ２トランスポートストリームに変換して信号処理部１３に提供する。

図５は、本発明の一実施例による再生システムを用いたデータ再生装置を示すブロック図である。

まず、「再生システム」とは、光記録／再生器内に備えられたプログラム（ソフトウェア）および／またはハードウェアで構成される集合的な再生処理手段で、光記録／再生器内にロードされた記録媒体を再生する他、記録媒体に関連付けられてローカルストレージ内に保存された（例えば、外部からダウンロードした）データを共に再生および管理するためのシステムのことを意味する。

図５を参照すると、仮想ファイルシステム４０は、記録媒体がロードされると、記録媒体に記録されたオリジナルデータとローカルストレージのアディショナルデータとをバインディングして仮想パッケージ５１を生成する。ただし、ロードされた記録媒体に対応するバインディングユニットがローカルストレージにない場合、仮想ファイルシステム４０は、記録媒体内のディスクパッケージのみを用いて仮想パッケージ５１を生成できる。

仮想ファイルシステム４０は、仮想パッケージのバインディング動作を提供するとともに、仮想パッケージ５１に属するファイルへのアクセスメカニズムを制御する。仮想ファイルシステム４０によって行われる仮想パッケージ５１の生成は、バインディングユニットマニフェストファイルによって決定される。バインディングユニットマニフェストファイルは、バインディング動作の管理情報を含み、仮想パッケージに一緒にバインディングされるファイルの有効な組合せを定義する。

仮想ファイルシステム４０によって生成された仮想パッケージ５１は、ＢＤ−ＪモードとＨＤＭＶモードのいずれにおいても使用される。ＢＤ−Ｊモードにおいて、記録媒体またはローカルストレージに位置するアプリケーションが、仮想ファイルシステム４０を介して仮想パッケージ５１にアクセスできる。ＨＤＭＶモードでは、ムービーオブジェクト（ｍｏｖｉｅ ｏｂｊｅｃｔ）が仮想パッケージにアクセスできる。

記録媒体がロードされると、インデックステーブルがユーザに提供される。インデックステーブルは、仮想パッケージによるインデクシング項目をユーザに提供する。すなわち、仮想パッケージが記録媒体内のディスクパッケージのみを用いて生成された場合、記録媒体内のインデックステーブルがユーザに提供される。記録媒体内のデータとローカルストレージ内のデータとをバインディングして仮想パッケージを生成した場合、バインディングした結果を再生できるインデックステーブルがユーザに提供される。

インデックステーブルのインデクシング項目のうち、ＨＤＭＶタイトルの再生命令があると、管理ファイル構造のムービーオブジェクトに備えられたコマンドによって該当するプレイリストファイルが実行される。以降、プレイリストファイル情報に基づいて、タイトルを構成する少なくとも一つのクリップが特定プレイアイテム（ＰｌａｙＩｔｅｍ）および／またはサブプレイアイテム（ＳｕｂＰｌａｙＩｔｅｍ）によって再生される。

本発明は、タイトルの再生に関するもので、少なくとも一つのアプリケーションを含むタイトルを対象とする。記録媒体および／またはローカルストレージのデータを再生するための再生単位であるタイトルは、アプリケーションと関連したＡ／Ｖデータを含むことができる。ただし、タイトルが、アプリケーションを含まず、単にＡ／Ｖデータを再生することもできる。例えば、自動再生プレイリストは、関連したアプリケーションなしに実行されることもできる。同様に、タイトルが必ずＡ／Ｖデータの上映（ｐｒｅｓｅｎｔａｔｉｏｎ）を含む必要はない。例えば、ゲームのように一つまたはそれ以上のアプリケーションのみで構成されたタイトルが存在することもできる。

本発明は、少なくとも一つのアプリケーションを含んでなるタイトルの再生において、タイトルと関連したアプリケーションを認証し、このタイトルを再生することによって、記録媒体およびローカルストレージのデータを保護することを特徴とする。

以下では、アプリケーションを含んでなるタイトルのうち、ＢＤ−Ｊタイトルを例にして説明する。図５を参照して、ＢＤ−Ｊタイトルの再生について説明すると、次の通りである。

まず、ＢＤ−Ｊタイトルは、関連したＢＤ−Ｊオブジェクト４２を一つ持つ。各ＢＤ−Ｊオブジェクトは、別の「ｘｘｘｘｘ．ｂｄｊｏ」ファイルに保存される。ＢＤ−Ｊオブジェクトは、関連したＢＤ−Ｊタイトルの管理情報を含む。ＢＤ−Ｊタイトルが選択されると、関連したＢＤ−Ｊオブジェクトが有効となる。管理情報には、「ＫｅｙＩｎｔｅｒｅｓｔＴａｂｌｅ（４２ａ）」、「ＴｅｒｍｉｎａｌＩｎｆｏ（４２ｂ）」、「ＡＭＴ（４２ｃ）」および「ＡｐｐＣａｃｈｅＩｎｆｏ（４２ｄ）」などがある。

インデクシングテーブル中のＢＤ−Ｊタイトルの再生命令があると、ＢＤ−Ｊタイトルを活性化（ａｃｔｉｖａｔｅ）するために、モジュールマネジャ１７１は、ＢＤ−Ｊタイトルに対応するＢＤ−ＪオブジェクトＩＤをＢＤ−Ｊモジュールに送る。ＢＤ−Ｊモジュールは、受信したＢＤ−ＪオブジェクトＩＤに対応するＢＤ−Ｊオブジェクトをロードする。ＢＤ−Ｊオブジェクト内のアプリケーション管理テーブル（ＡＭＴ）４２ｃは、ＢＤ−Ｊモジュールによってアプリケーションマネジャ１７４ａに送られ、アプリケーションキャッシュ情報（ＡｐｐＣａｃｈｅＩｎｆｏ）４２ｄはアプリケーションキャッシュマネジャ１７４ｃに送られる。また、ＢＤ−Ｊモジュール１７３は、キーインタレストテーブル（ＫｅｙＩｎｔｅｒｅｓｔＴａｂｌｅ）４２ａをユーザーイベントマネジャ１７１ａにロードし、ターミナル情報（ＴｅｒｍｉｎａｌＩｎｆｏ）４２ｂをモジュールマネジャ１７１にロードする。

アプリケーション管理テーブル４２ｃは、タイトルと関連したアプリケーションを識別し、ライフサイクル、媒介変数、プロファイルおよびバージョン、ユーザなど、各アプリケーションに関する包括的な情報を提供する。アプリケーション管理テーブル４２ｃがアプリケーションマネジャ１７４ａにロードされると、アプリケーションマネジャ１７４ａはアプリケーション管理テーブル４２ｃに表示された（ｓｉｇｎａｌｅｄ）オートランアプリケーションを実行させる。

ここで、アプリケーションとは、アプリケーションプログラムの略で、ユーザまたは他のアプリケーションに特定の機能を直接行うように設計されたプログラムのことをいう。このアプリケーションは、ジャバ仮想マシン１７５ｂで実行される。このアプリケーションは、ＡＰＩを用いて他のプログラムに対して公式的に作業をリクエストしたり通信する。

このアプリケーションは、例えば、記録媒体の外部からアディショナルデータをダウンロードする動作のように、光記録／再生器内のネットワーク機能を管理する。また、ローカルストレージ１５内に保存されたファイルを編集したりディスクパッケージにバインディングして仮想パッケージを生成する動作のように、ローカルストレージ１５を管理することもできる。すなわち、アプリケーションによって再生システム内で特定の機能が行われる。

多様なアプリケーションがＪＡＲファイルによって構成されることができる。ＪＡＲ（Ｊａｖａ ａｒｃｈｉｖｅ）ファイルは、複数のファイル集合を配布するために用いられる圧縮ファイルで、ここには、通常、特定プログラムと関連したジャバクラスファイル、補助リソースおよびメタデータなどが保存されることは、図２の説明で明らかにした。

アプリケーションは、記録媒体内に存在しても良く、ローカルストレージ内に存在しても良い。すなわち、特定アプリケーションを構成するＪＡＲファイルは、記録媒体に存在しても良く、ローカルストレージに存在しても良い。ＪＡＲファイルがローカルストレージに存在する場合、ＪＡＲファイルは記録媒体の外部からダウンロードされても良い。これは、ロードされた記録媒体から読み取られても良いことは無論である。

再生されるＢＤ−Ｊタイトルと関連したアプリケーションを実行するために、アプリケーションを行うクラスなどのデータが、アプリケーションマネジャ１７４ａによって仮想パッケージ５１のＪＡＲファイルから「Ｊａｖａ ＶＭ」にロードされる。アプリケーションマネジャ１７４ａは、アプリケーションキャッシュ１７３ｃからアプリケーションをロードできる。

アプリケーションキャッシュ１７３ｃは、アプリケーションのローディングの間に、ディスクからＡＶデータのシームレスな再生を保障し、データローディングの遅れを減らすために用いられる。すなわち、アプリケーションキャッシュ１７３ｃは、ＢＤ−Ｊに対するプリロードバッファーといえよう。ただし、プレーヤは、クラスファイルを含む、プリロードされないデータを使用することができる。ローカルストレージ内のＪＡＲファイルからのローディングがその一例となる。どのファイルが仮想パッケージからアプリケーションキャッシュ１７４ｄに伝達されるかは、「ＡｐｐＣａｃｈｅＩｎｆｏ（４２ｄ）」によって決定される。

本発明では、データがアプリケーションを構成するＪＡＲファイルからロードされるときに、「Ｊａｖａ ＶＭ（１７４ｂ）」がＪＡＲファイルを認証する。次に、図６から図１１を参照しながら、アプリケーションを構成するＪＡＲファイルの構成とその認証について説明する。

本発明によってアプリケーションを構成するＪＡＲファイルが認証されると、このアプリケーションが実行されてＢＤ−Ｊタイトルが再生される。最初は「ＡＭＴ（４２ｃ）」に自動実行で表示されたアプリケーションが実行される。アプリケーションによって、タイトルと関連した他のアプリケーションが実行されても良い。

アプリケーションの実行によって、再生制御エンジン１７６は、実際のディスクまたはローカルストレージに存在するプレイリストファイル情報を解析し、プレーヤーの再生環境および再生状態の保存されている再生レジスタ１７６ｂを参照して該当のプレイリストを実行する。プレイリストの実行によって再生されるクリップは、プレゼンテーションエンジン１７７に提供され、ストリームの種類によってビデオ／オーディオ／グラフィック／テキストサブタイトルのいずれかにデコードされる。このデコードされたストリームは、プレーンを通してユーザに表示される。

再生制御エンジン１７６は、実際にすべての再生を管理する再生制御ファンクション１７６ａと、プレーヤー状態レジスタ（（ＰＳＲ）および一般目的レジスタ（ＧＰＲ）を保存する再生レジスタ１７６ｂとを備える。場合によっては、再生制御ファンクション１７６ａが再生制御エンジン１７６を意味する。

本発明の再生システム１７でモジュールマネジャ１７１、ＨＤＭＶモジュール１７５、ＢＤ−Ｊモジュール１７４、再生制御エンジン１７６はソフトウェアとして処理可能である。実際、ハードウェア構成よりはソフトウェアとすることが設計上より有用である。ただし、プレゼンテーションエンジン１７７、デコーダおよびプレーン（ｐｌａｎｅｓ）はハードウェア的に設計されることが一般的である。特に、ソフトウェア的に処理される構成要素（例えば、図面符号１７１，１７４，１７５，１７６）の場合は、図４で前述した制御部１２の一部分として構成されても良い。したがって、本発明の構成は、その意味として理解すべきであり、ハードウェア的構成かソフトウェア的構成かに限定されてはいけない。

本発明の再生システム１７の特徴について説明すると、次の通りである。

第１に、ＨＤＭＶタイトルのためのＨＤＭＶモジュール１７５とＢＤ−ＪタイトルのためのＢＤ−Ｊモジュール１７４が独立的に構成され、同時に両モジュール１７４、１７５は実行されない。すなわち、ＨＤＭＶタイトル再生中にはＢＤ−Ｊタイトルを再生できなく、その逆も同様である。

第２に、ＨＤＭＶタイトルとＢＤ−Ｊタイトルはそれぞれ別途方式のユーザ命令を受信し、ユーザ命令を行う方式が相互独立的である。キーイベントハンドラ１７２は、ユーザ命令を受信してＨＤＭＶモジュール１７５、ＢＤ−Ｊモジュール１７４またはモジュールマネジャー１７１／ナビゲータ１７３のいずれかに伝達する役割を果たす。例えば、キーイベントハンドラ１７２は、受信した命令がユーザオペレーション（ＵＯ）によるユーザ命令であると、これをモジュールマネジャー１７１に転送し、受信した命令がキーイベントによるユーザ命令であると、これをＢＤ−Ｊモジュール１７４に転送する。

第３に、前述した再生制御エンジン１７６の管理（これを「マスター」ともいう）は、現在動作中のモジュール１７４、１７５のいずれかが担当する。すなわち、ＨＤＭＶタイトル再生中にはＨＤＭＶモジュール１７５がマスターとなり、ＢＤ−Ｊタイトルを再生中にはＢＤ−Ｊモジュール１７４がマスターとなる。

なお、ナビゲータ１７３は、いつでもユーザの制御の下にタイトル選択を行うことができるようにし、ユーザに記録媒体とタイトルメタデータを提供できる。

図６は、本発明によって、署名されたアプリケーションを構成するＪＡＲファイルを示す図である。

図６を参照すると、ＪＡＲファイルは一種の圧縮ファイルで、複数のファイルを一つに集めるのに用いられる。ＪＡＲファイルが署名された場合、このＪＡＲファイルを署名されたＪＡＲファイルといい、署名されたＪＡＲファイルによって構成されたアプリケーションを署名されたアプリケーションという。この署名されたＪＡＲファイルは、マニフェストファイルがアップデートされ、ＭＥＴＡＩＮＦＯディレクトリに署名ファイルと署名ブロックファイルが追加される以外は、本来のＪＡＲファイルと同一である。

データの認証に用いられるファイルを認証メッセージという。本発明では、認証メッセージがＪＡＲファイルに含まれることが好ましい。ＪＡＲファイルとして行われる限り、アプリケーションがディスク上に存在するか、ネットワークを通して得られるかにかかわらず、本発明によるアプリケーションの認証が可能になる。

図６のアプリケーションは、署名されたアプリケーションであり、このアプリケーションを構成するＪＡＲファイルは、「Ａｐｐ０」ファイルとＭＥＴＡＩＮＦＯディレクトリ６１とを含む。「Ａｐｐ０」ファイルは、「ｃｌａｓｓｅｓ」ファイルと「ｄａｔａ」ディレクトリとを含み、この「ｄａｔａ」ディレクトリには「Ａｐｐ０．ｄａｔ」ファイルが存在する。「ｃａｌｓｓｅｓ」ファイルは、「Ａｐｐ０．ｃｌａｓｓ」ファイルと「ｓｕｂｃｌａｓｓｅｓ」ディレクトリとを含み、この「ｓｕｂｃｌａｓｓｅｓ」ディレクトリには「ｓｕｂ１．ｃｌａｓｓ」と「ｓｕｂ２．ｃｌａｓｓ」が存在する。ＪＡＲファイルによって構成されるアプリケーションの実行命令があると、ＪＡＲファイル内のクラスがロードされる。

ＭＥＴＡＩＮＦＯディレクトリ６１は、マニフェストファイル（ＭＡＮＩＦＥＳＴ．ＭＦ）６１１、署名ファイル（ＸＸＸ．ＳＦ）６１２および署名ブロックファイル（ＸＸＸ．ＲＳＡ）６１３を含む。これらのファイルによってアプリケーションの認証がなされる。ここで、ファイル名「ＸＸＸ」は、ＪＡＲファイルに署名したエンティティを表す。ファイル名「ＸＸＸ」をコンデンツプロバイダの署名仮名（ｓｉｇｎａｔｕｒｅ ａｌｉａｓ）ともいう。マニフェストファイル、署名ファイル、署名ブロックファイルが本発明によるアプリケーションの認証に用いられる認証メッセージである。これらの認証メッセージについて具体的に説明すると、次の通りである。

マニフェストファイル６１１は、署名された各ファイルに対するメッセージダイジェストと共にこれらファイルのリストをＪＡＲファイルに含む。

ＪＡＲファイル内の全てのファイルがマニフェストファイルにエントリとしてリストされるのではない、署名された全てのファイルはリストされなければならない。したがって、図６の実施例で、ＪＡＲファイル内の全てのクラスファイル（Ａｐｐ１．ｃｌａｓｓ，ｓｕｂ１．ｃｌａｓｓ，ｓｕｂ２．ｃｌａｓｓ）が署名された場合、「Ａｐｐ０．ｃｌａｓｓ」ファイル、「ｓｕｂ１．ｃｌａｓｓ」ファイル、「ｓｕｂ２．ｃｌａｓｓ」ファイルに対するエントリは、マニフェストファイル６１１にリストされなければならない。

署名ファイル６１２は、マニフェストファイルのダイジェストを含む。署名ファイルは、権威のある機関によって署名されたデータである。メッセージダイジェストが署名ファイル６１２のコンテンツを使用して計算された後、計算された結果を個人キーを用いて署名アルゴリズムによって暗号化すると、電子署名が生成される。すなわち、電子署名は、署名ファイルの署名されたバージョンといえる。生成された電子署名は、署名ブロックファイル６１３内に位置することになる。各署名ファイルは複数の電子署名を持つことができるが、これらの電子署名は同じ法的なエンティティによって生成されなければならない。

ここで、個人キーは、署名ブロックファイル６１３に存在する公開キーに対応する個人キーである。公開キーは、署名ブロックファイル６１３内の認証書のリーフ認証書中の一つに位置する。

署名ブロックファイル６１３は、署名検証に用いられる一つ以上の認証書チェーンを含む。署名ブロックファイル６１３は、デジタル署名ファイルともいう。デジタル署名ファイルは、署名ファイル６１２と同じファイル名を持つが、拡張子が異なる。拡張子は、署名アルゴリズムによって定められ、例えば「．ＲＳＡ」または「．ＤＳＡ」などがある。

図７は、本発明の一実施例による、署名されたＪＡＲファイルを構成する流れを示す図である。

図７を参照すると、まず、ＪＡＲファイルに含まれたファイルのデータに対するダイジェストが算出される（Ｓ７１０）。マニフェストファイルが生成され、算出された結果がマニフェストファイルに保存される（Ｓ７２０）。ＪＡＲファイルに含まれたファイルのデータに対するダイジェストは、ユーザに提供されるアプリケーションの内容が変わっていないことを証明するのに用いられる。

なお、ダイジェストはダイジェストアルゴリズムによって算出される。ダイジェストアルゴリズムとは、データをハッシュ処理した後、各データに対応する一定の長さのハッシュを求めるアルゴリズムのことを意味する。算出されたダイジェストは、該当のデータと一対一にマッピングされるため、情報の内容を証明できるコードとして活用できる。すなわち、あるデータをダイジェストアルゴリズムによってダイジェストに計算すると、該当ダイジェストを用いてデータの修正、順序変更、削除、添加のようなデータの完全性がチェックされることができる。

ダイジェストアルゴリズムは、任意の長さを持つデータを受信し、一定の長さを有する結果を算出する。特に、本発明で用いられるダイジェストアルゴリズムは、単方向ハッシュ関数である。したがって、この算出されたダイジェストから元来のデータを推論できないため、このダイジェストアルゴリズムは本発明による記録媒体に適している。ダイジェストアルゴリズムには、ＳＨＡ−１（ｓｅｃｕｒｅ ｈａｓｈ ａｌｇｏｒｉｔｈｍ−１）またはＭＤ５（ｍｅｓｓａｇｅ ｄｉｇｅｓｔ ａｌｇｏｒｉｔｈｍ ５）などが用いられることができる。

ＪＡＲファイルに含まれたファイルのデータに対するダイジェストを含む、マニフェストファイルのダイジェストが算出される（Ｓ７３０）。署名ファイルを生成し、ここにマニフェストファイルのダイジェストが保存される（Ｓ７４０）。この署名ファイルはマニフェストファイルの完全性を保障するために用いられる。

この署名ファイルは、ＪＡＲファイルを提供するコンデンツプロバイダの個人キーを用いて署名される。すなわち、署名ファイルのデータを用いてダイジェストが計算（Ｓ７５０）された後、この署名ファイルのダイジェスト計算の結果は、個人キーを用いて暗号化（Ｓ７６０）される。暗号化された結果が認証書と共に署名ブロックファイルに付加されて保存される（Ｓ７７０）。

なお、署名ファイルの暗号化された結果が電子署名され、電子署名の生成には署名アルゴリズムが用いられる。署名アルゴリズムとは、一種の暗号化アルゴリズムのことをいう。暗号化アルゴリズムとしては、例えば、ＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｅｌｍａｎ）、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）などが用いられることができる。図８を参照して、電子署名の生成についてより具体的に説明する。

アプリケーションのプロバイダは、生成されたマニフェストファイル、署名ファイル、および署名ブロックファイルをバインディングし、署名されたＪＡＲファイルを生成してユーザに提供する。

図８は、本発明の一実施例によって電子署名を構成する過程を示す図である。

図８を参照すると、アプリケーションを提供するコンデンツプロバイダは、ユーザに提供するアプリケーションの真正性を保障すべくアプリケーションを構成するＪＡＲファイルに署名し、この署名されたＪＡＲファイルを提供する。アプリケーションが真正なエンティティによって提供されたか否かを確認するために電子署名が用いられる。また、電子署名は、アプリケーションの提供の過程でアプリケーションが変調されたり偽造される弊害を防止するために用いられる。秘密キーを持つ者は署名できるし、署名をしたエンティティが自分であることを証明しなければならない。また、署名されたアプリケーションは変更されない。

署名されたＪＡＲファイルに含まれる署名ファイル内のデータがダイジェストアルゴリズム６０１０に適用される。このダイジェストアルゴリズムによって署名ファイルに対するダイジェスト６０１１が算出される。署名ファイルに対するダイジェストを署名アルゴリズム６０１２に適用すると電子署名が生成される。アプリケーションを提供するコンデンツプロバイダの個人キー６０１３が署名アルゴリズムに用いられる。

このように生成された電子署名は、署名ブロックファイルに含まれ、ＪＡＲファイルの形態で記録媒体またはネットワークを通してユーザに提供される。

なお、個人キーは、公開キー暗号システム（ｃｒｙｐｔｏｓｙｓｔｅｍ）で用いられる、１エンティティの非対称キー対のうち、公開されないキーのことをいう。場合によっては、対称キー暗号化方式で用いられるキーを意味する。個人キーに対応するキーを公開キーといい、公開キーとは、公開キー暗号システムで用いられる一対のエンティティの非対称キー対のうち、公開されるキーのことをいう。公開キーは、署名システムで署名の真偽を判断するのに用いられることから検証キーとも呼ばれる。

図９は、本発明の一実施例によって、署名されたアプリケーションを構成するＪＡＲファイル内のファイル（ａ ｆｉｌｅ）の認証フローを示す図である。

図９を参照すると、マニフェストファイルを分析（ｐａｒｓｅ）するとき、まず、署名が署名ファイルに対して検証される（Ｓ９１０）。電子署名は、署名ブロックファイルに存在する。具体的に説明すると、前記署名ファイルに対応する署名ブロックファイルが見つけられ、この署名ブロックファイルから認証書が読み出される。これらの認証書のうちのリーフ認証書には、署名ファイルの生成に用いられた個人キーに対応する公開キーが存在する。

署名ブロックファイル内に存在する暗号化された電子署名が公開キーを用いてダイジェストに復元される。復元されたダイジェストは、署名ファイルのダイジェストと比較される。比較されたダイジェストが相互に同一な場合、電子署名の検証が実行される。電子署名の検証に失敗する場合、ファイルに対する認証は失敗とされる（Ｓ９７０）。ここで、公開キーは、電子署名の生成に使われた個人キーに対応するキーである。

認証されるファイルの有効性を確認するために、マニフェストファイルに対するダイジェストが計算される（Ｓ９２０）。計算されたダイジェストが、署名ファイルに存在するダイジェストと比較される（Ｓ９３０）。比較された両ダイジェストが相互に異なる場合、ファイルの認証は失敗とされる（Ｓ９７０）。比較された両ダイジェストが総合に同一な場合、マニフェストファイルに対する完全性が確認される。

認証される前記ファイルの実際データに対するダイジェストが計算される（Ｓ９４０）。計算されたダイジェストは、マニフェストファイル内のダイジェストと比較される（Ｓ９５０）。比較された両ダイジェストが相互に同一な場合、ファイルの有効性は確認され、認証に成功（Ｓ９６０）する。しかしながら、比較された両ダイジェストが相互に異なると、ファイルの認証は失敗（Ｓ９７０）とされる。

本発明は、アプリケーションを構成するファイル内のファイルを認証する場合において、署名ファイルを用いてマニフェストファイルの完全性を確認し、署名ブロックファイルを用いて電子署名を検証することを特徴とする。また、マニフェストファイルを用いてＪＡＲファイルの実際データに対する完全性を確認することを特徴とする。

したがって、ＪＡＲファイルの実際データに対する完全性確認（Ｓ９４０、Ｓ９５０）、マニフェストファイルの完全性確認（Ｓ９２０、Ｓ９３０）および電子署名の検証（Ｓ９１０）は個別的に具現されることができる。すなわち、図９の実施例で説明した認証フローの順に制約されるわけはなく、再生システムによってその順序は変動されても良い。

なお、アプリケーションの認証において、認証されるファイルがマニフェストファイルからリストされたものかについて、認証されるファイルの実際データに対するダイジェストが計算（Ｓ９４０）される前に確認されても良い。

また、電子署名に対する検証結果（Ｓ９１０）とマニフェストファイルに対する完全性確認の結果（Ｓ９３０）は、以降の使用のために保存されても良い。この場合、Ｓ９１０〜Ｓ９３０の段階は、一つのＪＡＲファイルの認証過程で一回のみ行われる。

電子署名の検証と関連して、電子署名の検証に用いられる認証書は、署名ブロックファイル内の認証書フィールドに存在する。認証書フィールドは、少なくとも一つの認証書チェーンを含む。リーフ認証書内の公開キーを用いて署名ブロックファイルの電子署名を検証する際に、認証書チェーンの各チェーンも検証されなければならない。認証書チェーンの検証は、ルート認証書まで行われる。ルート認証書とこのルート認証書に達する中間認証書の検証まで満足すると、認証されるファイルの認証が成立されることができる。

なお、認証書チェーンの認証書は記録媒体に記録されてユーザに提供されても良く、記録媒体の外部からユーザにダウンロードされても良い。認証書は、バージョン、シリアルナンバー、署名アルゴリズム、発行者、有効期間、認証対象（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｕｂｊｅｃｔ）、公開キーなどを含むことができる。

図１０は、本発明の一実施例によって電子署名を検証するフローを示す図で、ＪＡＲファイル内のファイルの認証過程のうち、電子署名を検証する方法の理解を助けるためのものである。

図１０を参照すると、電子署名は、電子署名に用いられた個人キー６０１３に対応する公開キー６０１７を用いて署名アルゴリズム６０１６に基づいてダイジェスト６０１８に復元されることができる。この電子署名において、暗号化アルゴリズムの特性の上、個人キー６０１３で暗号化された情報は必ず個人キーに対応する公開キー１０１７を用いて復元されなければならない。すなわち、電子署名の生成に用いられた個人キー６０１３に対応する公開キー６０１７がない場合、電子署名はダイジェスト６０１８に復元されることができない。この場合、提供されたアプリケーションが適法なコンデンツプロバイダによって提供されたことを認証できなくなる。公開キー６０１７は、認証書内に含まれ、この認証書は署名ブロックファイル内に保存されてユーザに提供される。

再生システム１７は、認証されるＪＡＲファイルの署名ファイルのデータにダイジェストアルゴリズム６０１４を適用してダイジェスト６０１５を算出する。このダイジェストアルゴリズムは、電子署名の生成過程で用いられたダイジェストアルゴリズムである。算出されたダイジェスト６０１５は、電子署名を復元して生成されたダイジェスト６０１８と比較される。これら比較されたダイジェストが同一でない場合、電子署名の検証は失敗とされる。

また、公開キー６０１７の信頼性を保証する認証書チェーンの認証書の検証に失敗する場合にも、電子署名の検証は失敗とされる。アプリケーションが真正なコンデンツプロバイダによって署名されたことが判断できず、アプリケーションの認証は成立しなくなる。

図１１は、本発明によるＪＡＲファイルの認証に用いられる認証書チェーン（ｃｅｒｔｉｆｉｃａｔｅ ｃｈａｉｎ）を示す図である。

図１１を参照すると、信頼できるルート認証機関が認証機関（ｃｅｒｔｉｆｉｃａｔｅ ａｕｔｈｏｒｉｔｙ）を保証（１１０２，１１０３）できる。認証される認証機関は、ＡＡＣＳ（Ａｄｖａｎｃｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｅｎｔ Ｓｙｓｔｅｍ）またはＣＰＳ（Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）でありうる。場合によって、ＡＡＣＳまたはＣＰＳは直接ルート認証機関にもなりうる。

ＡＡＣＳ、ＣＰＳまたはその他の認証機関は、光記録／再生器、コンデンツプロバイダなどの下部構造を独立的に保証（１１０２ａ、１１０２ｂ、１１０２ｃ）することができる。このような構造を認証書チェーンという。認証書チェーンにおいて、信頼できる認証機関（ＣＡ）を保証できる上位の認証機関は存在せず、この場合、信頼できる認証機関はそれ自身で保証（１１０１）するようになり、これはルート認証（１１０１）に該当する。

各認証機関は自分自身または下部構造に対する保証の結果に対して各認証機関の電子署名を含む認証書を提供することになる。認証書チェーンの最下位の認証機関が提供する認証書をリーフ認証書といい、認証書チェーンの最上位の認証機関が提供する認証書をルート認証書という。図１０で説明したように、これらの認証書は、電子署名の検証過程で電子署名を復元する公開キーの信頼性を確保することができる。

場合によって、各認証機関は、認証書廃棄リスト（ｃｅｒｔｉｆｉｃａｔｅ ｒｅｖｏｃａｔｉｏｎ ｌｉｓｔ）（ＣＲＬ）を作成することができる。この場合、コンデンツプロバイダおよびユーザは、認証書廃棄リストをダウンロードし、該認証書を介して認証するに先立ち、認証に使用しようとする認証書が廃棄されたか否かを検査する。認証書が廃棄されていると認証は成立しなく、認証書が廃棄されていないと、他の認証要件を満足する限り認証が成立する。

なお、信頼できる認証機関が提供する信頼できるルート認証書は、記録媒体の特定の領域にファイルと同じ形態で保存されてユーザに提供される、または、記録媒体の外部からダウンロードされて光記録／再生器のキーストアに保存されることができる。

アプリケーションが認証される間に、光記録／再生器は、署名ブロックファイル内のルート認証書が、記録媒体内またはキーストアに保存された信頼できるルート認証書と同一か否か確認する。これらの認証書が同一でないと、アプリケーションは「Ｊａｖａ ＶＭ」にロードされない。たとえアプリケーションが「Ｊａｖａ ＶＭ」にロードされても、このアプリケーションは実行されないことが好ましい。

図１２は、本発明によるタイトルの再生フローを示す図である。

図１２を参照すると、ＢＤ−Ｊタイトルを例に挙げると、再生されるＢＤ−Ｊタイトルのために、ＢＤ−Ｊモジュールは、このＢＤ−Ｊタイトルに対応するＢＤ−Ｊオブジェクトをロードする（Ｓ１２１０）。このＢＤ−Ｊオブジェクトは、ＢＤ−Ｊタイトルと関連した管理情報を含む。管理情報のうちの「ＡＭＴ」、すなわち、アプリケーション管理テーブルがＢＤ−Ｊモジュール内のアプリケーションマネジャーにロードされる（Ｓ１２２０）。この管理情報には「ＡｐｐＣａｃｈｅＩｎｆｏ」が含まれ、この「ＡｐｐＣａｃｈｅＩｎｆｏ」はＢＤ−Ｊモジュール内のアプリケーションキャッシュマネジャーに提供され、これにより、どのファイルが仮想パッケージからアプリケーションキャッシュに伝達されるかが決定される。

この仮想パッケージのＪＡＲファイルからＢＤ−Ｊタイトルの再生に関連したアプリケーションを構成するクラスがロードされる。これらの仮想パッケージのＪＡＲファイルは、記録媒体またはローカルストレージに存在しても良い。ＪＡＲファイルがローカルストレージに存在する場合、このＪＡＲファイルはローカルストレージ内のアプリケーションデータ領域に存在するわけである。アプリケーションデータ領域は、アプリケーションを構成するデータが保存される領域である。

本発明は、クラスがロードされる間に、アプリケーションを認証することを特徴とする。このアプリケーションの認証は、「Ｊａｖａ ＶＭ」によって行われる。アプリケーションの認証は、アプリケーションを構成するＪＡＲファイルを認証（Ｓ１２３０）することによってなされる。

署名されたＪＡＲファイルの認証は、署名ファイルを用いてマニフェストファイルの完全性を確認し、署名ブロックファイルを用いて電子署名を検証することを含む。署名されたＪＡＲファイルの実際データに対する完全性は、ＪＡＲファイルに対するマニフェストファイルから確認できる。

電子署名が本発明によって検証され、マニフェストファイルおよびＪＡＲファイル内の実際データに対する完全性が確認される場合、アプリケーションの認証が成立する。

本発明によってデータの認証に成功する場合、「Ｊａｖａ ＶＭ」でアプリケーションが実行される（Ｓ１２４０）。ＢＤ−Ｊアプリケーションは、ＡＰＩを用いて再生システムの実際リソースにアクセスする。再生システムのリソースは、ディスクファイルシステム、メディアデコーダ、静的コンデンツデコーダ、ストレージ装置、ネットワーク接続を含む。このようなリソースへのアクセスによって、アプリケーションはＢＤ−Ｊタイトルの再生に必要な特定機能を行うようになる。アプリケーションの実行によって、ＢＤ−Ｊタイトルを構成する記録媒体内のデータおよび／またはローカルストレージ内のデータが再生される。

署名されたアプリケーションの場合、電子署名が検証されない、または、マニフェストファイルまたはＪＡＲファイル内の実際データに対する完全性が確認されないと、アプリケーションの認証が成立しなくなる。

署名されていないアプリケーション（ｕｎｓｉｇｎｅｄ ａｐｐｌｉｃａｔｉｏｎ）は、署名されていないＪＡＲファイルによって構成される。署名されていないＪＡＲファイルには、署名ファイルと署名ブロックファイルが存在しない。したがって、マニフェストファイルの完全性を確認することができない。ただし、マニフェストファイルが有効であるとの前提の下に、署名されていないＪＡＲファイル内の実際データに対する完全性は確認されることができる。要するに、署名されていないアプリケーションの場合、本発明によるアプリケーションは成立しない。

アプリケーションの認証に失敗する場合、アプリケーションを「Ｊａｖａ ＶＭ」にロードしたり実行しないことが好ましい。ただし、これは、光記録／再生器の具現に関する問題である。したがって、認証されていないアプリケーションは「Ｊａｖａ ＶＭ」内の制限された範囲で実行されても良い。これをサンドボックスというが、認証されていないアプリケーションはサンドボックスの保安政策によって、再生システムのリソースへのアクセスが制限されることになる。したがって、サンドボックスによって再生システムのリソースへのアクセスの許容されたアプリケーションは、自身の作業は行えるが、サンドボックスで再生システムのリソースへのアクセスが許容されないアプリケーションは、リソース内のファイルを読取または変更できないため、再生システムに損傷を与えることがない。

この署名されていないアプリケーションの場合、アプリケーションの配布者を区別しにくいため、再生システムの保護のために、アプリケーションが実行されないことが好ましい。これは、アプリケーションの悪用によって再生システムが損傷する恐れがあるためである。たとえ署名されていないアプリケーションが実行されても、制限されたリソースへのアクセスのみを許容するサンドボックス内で実行されることが好ましい。

署名されたアプリケーションの場合、認証されていないアプリケーションは実行させないか、サンドボックス内で実行させることが好ましい。ただし、認証されていない署名されたアプリケーションの場合には、アプリケーションの電子署名を用いてアプリケーションを配布したコンデンツプロバイダが判別できる。したがって、アプリケーションの悪用によって再生システムが損傷された場合、コンデンツプロバイダにアプリケーションの配布に対する責任を問うことができるわけである。

以下、図４および図５を参照して、本発明によるデータ再生装置について説明する。

まず、本発明によるローカルストレージを用いたデータ再生装置は、再生されるタイトルに対応するオブジェクトファイルから、このタイトルと関連したアプリケーションを識別する情報を確認し、関連したアプリケーションを認証する制御部１２と、アプリケーションの実行によってこのタイトルを再生するデコーダとを備える。このデコーダは再生システム１７の一部を構成する。アプリケーションは記録媒体またはローカルストレージに存在する。

本発明で、制御部１２は、アプリケーションを構成するファイルのデータがロードされる間に、このファイルを認証することによってアプリケーションを認証する。

なお、アプリケーションを構成するファイルの認証は、このファイル内の署名ブロックファイルを用いて、アプリケーションに署名したエンティティの電子署名を検証することを含む。

電子署名の検証は、署名ブロックファイル内の公開キーを用いてなされる。公開キーは、電子署名の生成に用いられた個人キーに対応する公開キーが好ましい。

また、アプリケーションを構成するファイルの認証は、ファイル内の署名ファイルを用いて、ファイルに含まれたファイルの完全性を確認することを含む。

制御部１２は、アプリケーションが認証されていない場合、このアプリケーションが実行されないように制御できる。また、制御部１２は、認証が成立しなかったアプリケーションがジャバ仮想マシン１７４ｂに構成されたサンドボックス（Ｓａｎｄｂｏｘ）で実行されるように制御することもできる。

本発明によれば、認証されていないアプリケーションから再生システムが保護される。また、認証されていないアプリケーションのコンテンツへのアクセスを制御することによって、コンテンツを保護することができる。

以上の本発明の実施例は例示的なもので、添付の特許請求の範囲に開示された本発明の技術的思想とその技術的範囲内で、様々な改良、変更、代替または付加された実施例が可能であることは、当業者にとっては明らかである。したがって、本発明は、特許請求の範囲およびこれと均等な範囲内における本発明の改良および変更された事項も含むことは当然である。

本発明は、コンデンツプロバイダによって提供されるコンテンツおよびユーザの再生システムを提供でき、さらにコンデンツプロバイダは安全にコンテンツを提供でき、ユーザは安心してコンテンツを再生できることが可能になる。したがって、本発明は、より便利な機能を提供することができる。

本発明の概念的理解を助けるためのもので、光記録／再生器と周辺機器間の統合的な使用を示す例示図である。 ＢＤ−ＲＯＭのような本発明の記録媒体に記録されるファイル構造を示す図である。 本発明によって光ディスクに記録されるデータ記録構造を示す図である。 本発明の一実施例による光記録／再生器のブロック図である。 本発明の一実施例による再生システムを用いたデータ再生装置のブロック図である。 本発明の一実施例によって、署名されたアプリケーションを構成するＪＡＲファイルを示す図である。 本発明の一実施例によって署名されたＪＡＲファイルを構成するフロー図である。 本発明の一実施例よって電子署名を構成する過程を示す図である。 本発明の一実施例によって、署名されたアプリケーションを構成するＪＡＲファイル内のファイルを認証する過程を示すフロー図である。 本発明の一実施例によってＪＡＲファイル内のファイル認証過程で電子署名を検証する過程を示す図である。 本発明によるＪＡＲファイルの認証に用いられる認証書チェーンを示す図である。 本発明によってタイトルを再生する方法を示すフロー図である。

Claims (27)

1. 記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されるタイトルを再生する方法であって、
   前記タイトルに対応するオブジェクトファイルから前記タイトルと関連付けられたアプリケーションを識別する情報を確認するステップと、
   前記関連付けられたアプリケーションを認証するステップと、
   前記アプリケーションを実行して、前記タイトルを再生するステップと
   を備えることを特徴とするデータ再生方法。
2. 前記アプリケーションは、前記アプリケーションを構成するファイルの認証によって認証されることを特徴とする請求項１に記載のデータ再生方法。
3. 前記ファイルは、ＪＡＲファイルであることを特徴とする請求項２に記載のデータ再生方法。
4. 前記ファイルの前記認証は、前記ファイル内の署名ブロックファイルを用いて、前記アプリケーションに署名したエンティティの電子署名を検証することを含むことを特徴とする請求項２に記載のデータ再生方法。
5. 前記検証は、前記署名ブロックファイル内の公開キーを用いて行われることを特徴とする請求項４に記載のデータ再生方法。
6. 前記公開キーは、前記電子署名の生成に用いられた個人キーに対応することを特徴とする請求項５に記載のデータ再生方法。
7. 前記検証は、前記署名ブロックファイル内の認証書チェーンの認証書を検証することを含むことを特徴とする請求項４に記載のデータ再生方法。
8. 前記ファイルの認証は、前記ファイル内の署名ファイルを用いて、前記ファイル内のマニフェストファイルの完全性を確認することを含むことを特徴とする請求項２に記載のデータ再生方法。
9. 前記ファイルの認証は、前記ファイル内のマニフェストファイルを用いて、前記ファイルの実際データに対する完全性を確認することを含むことを特徴とする請求項２に記載のデータ再生方法。
10. 前記認証は、ジャバ仮想マシンで行われることを特徴とする請求項１に記載のデータ再生方法。
11. 前記認証が失敗した場合、前記アプリケーションは実行されないことを特徴とする請求項１に記載のデータ再生方法。
12. 前記認証が失敗した場合、前記アプリケーションはジャバ仮想マシンのサンドボックス内で実行されることを特徴とする請求項１に記載のデータ再生方法。
13. 前記情報は、アプリケーション管理テーブル（ＡＭＴ）であることを特徴とする請求項１に記載のデータ再生方法。
14. コンテンツが記録されるデータ領域と、
    前記コンテンツの再生を管理する管理領域とを備え、
    前記データ領域には、少なくとも一つの署名されたアプリケーションを含んで構成されたタイトルが記録され、
    前記管理領域には、前記タイトルと関連付けられたアプリケーションを識別する情報を含むオブジェクトファイルが記録され、
    前記署名されたアプリケーションは、署名ファイルおよび署名ブロックファイルを含むことを特徴とする記録媒体。
15. 前記署名ファイルは、前記アプリケーションに対するマニフェストファイルのダイジェストを含むことを特徴とする請求項１４に記載の記録媒体。
16. 前記ダイジェストは、前記マニフェストファイルをＳＨＡ−１ダイジェストアルゴリズムに適用して算出することを特徴とする請求項１４に記載の記録媒体。
17. 前記署名ブロックファイルは、前記アプリケーションに署名したエンティティの電子署名を含むことを特徴とする請求項１４に記載の記録媒体。
18. 前記電子署名は、署名アルゴリズムによって前記署名ファイルのダイジェストを前記エンティティの個人キーで暗号化することによって生成されることを特徴とする請求項１７に記載の記録媒体。
19. 前記署名アルゴリズムは、ＲＳＡであることを特徴とする請求項１８に記載の記録媒体。
20. 記録媒体内のデータおよび／またはローカルストレージ内のデータで構成されたタイトルに対応するオブジェクトファイルから、前記タイトルと関連付けられたアプリケーションを識別する情報を確認し、前記関連付けられたアプリケーションを認証する制御部と、
    前記アプリケーションの実行によって前記タイトルを再生するデコーダと
    を備えたことを特徴とするデータ再生装置。
21. 前記制御部は、前記アプリケーションを構成するファイルのデータがジャバ仮想マシンにロードされる間に、前記ファイルを認証することによって前記アプリケーションを認証することを特徴とする請求項２０に記載のデータ再生装置。
22. 前記認証は、前記ファイル内の署名ブロックファイルを用いて、前記ファイルに署名したエンティティの電子署名を検証することを含むことを特徴とする請求項２１に記載のデータ再生装置。
23. 前記検証は、前記署名ブロックファイル内の公開キーを用いて行われる、請求項２２に記載のデータ再生装置。
24. 前記公開キーは、前記電子署名の生成に用いられた個人キーに対応することを特徴とする請求項２３に記載のデータ再生装置。
25. 前記認証は、前記ファイル内の署名ファイルを用いて、前記ファイル内のマニフェストファイルの完全性を確認することを含むことを特徴とする請求項２１に記載のデータ再生装置。
26. 前記認証が失敗した場合、前記制御部は、前記アプリケーションが実行されないように制御することを特徴とする請求項２０に記載のデータ再生装置。
27. 認証が失敗した場合、前記制御部は、前記アプリケーションがジャバ仮想マシン内のサンドボックスで実行されるように制御することを特徴とする請求項２０に記載のデータ再生装置。

Images