共有データ保護方法及び保護装置並びにローカルストレージを用いた記録媒体再生方法及び再生装置
共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び再生装置が開示される。本発明は、ローカルストレージに記録媒体と関連した共有データをダウンロードし、共有データに対する有効なアクセス情報を持つアプリケーションのみが共有データにアクセスできるように許容する。また、本発明は、ローカルストレージに記録媒体と関連した暗号化された共有データをダウンロードし、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって共有データを含むバーチャルパッケージを生成し、バーチャルパッケージを用いて共有データを解読し、解読された共有データを再生することを含む。したがって、真のコンテンツプロバイダによって提供されたコンテンツ及び変質していないコンテンツのみが再生されるようにすることによって共有データを保護できる。また、権限のないアプリケーションによる悪意的な機能から共有データを保護することもできる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は記録媒体の再生に関し、特に、共有データ（shared data）を保護する方法及び装置と、ローカルストレージを用いて記録媒体からデータを再生する方法及び装置に関する。
【背景技術】
【０００２】
記録媒体として大容量のデータを記録できる光ディスクが広く使用されている。なかでも最近では高画質のビデオデータと高音質のオーディオデータを長時間記録格納することができる新しい高密度記録媒体、例えば、ブルーレイディスク(ＢＤ：Blu-ray Disc（登録商標）)が開発されている。
【０００３】
次世代記録媒体技術であるＢＤは、既存のＤＶＤを顕著に凌駕する量のデータを備える次世代光記録ソリューションである。近来、他のデジタル機器と共にＢＤを研究し、開発する多くの努力が行われている。
【０００４】
ＢＤ規格を応用した光記録再生装置が開発され始めている。しかし、未だＢＤ規格は完備しておらず、完成した光記録／再生装置を開発するのに多くの難題が生じている。
【０００５】
特に、上記のような光記録再生装置は、ＢＤに記録し、およびＢＤを再生する基本機能の他に、周辺のデジタル機器との統合的使用を考慮した付加的な機能も考慮しなければならない。すなわち、光記録再生装置は、外部入力信号を受信してこれをディスプレイするか、外部入力信号とＢＤを共に用いて再生する機能を必ず備えなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、外部入力信号及びＢＤを再生する場合において、コンテンツプロバイダによって提供された共有データを保護する好ましい方法が提案されておらず、また開発されておらず、本格的なＢＤ基盤の光記録再生装置を開発するのに多くの制約がある。
【０００７】
したがって、本発明は関連技術における制約及び不便による１又は複数の問題を除去するために、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置に関する。
【０００８】
本発明の一つの目的は、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置を提供することによって、信頼のおけるコンテンツプロバイダによって提供される共有データを保護し、権限のないアプリケーションによってその共有データが使用されるのを防止することにある。
【０００９】
本発明の他の目的は、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置を提供することによって、共有データを保護することにある。
【００１０】
本発明の付加的な長所、目的、特徴は以下の詳細な説明に一部記述され、以下の実施形態によって、または本発明の実施によって一部当業者に明らかとなる。本発明の目的及び他の長所は、添付図面の他に、発明の詳細な説明及び特許請求の範囲において特に指摘される構造によって実現され、そして達成される。
【課題を解決するための手段】
【００１１】
これらの目的及び長所を達成するために、そして、本発明の目的にしたがって、本明細書において具体化され、広く説明されているように、本発明による共有データを保護する方法は、ローカルストレージに記録媒体と関連した共有データをダウンロードするステップと、共有データに対する有効なアクセス情報（接近情報）を持つアプリケーションが共有データにアクセス（接近）できるように許容する（permit）ステップと、を含む。
【００１２】
例えば、そのアクセス情報は、アプリケーションのクレデンシャル情報（Credential）である。
【００１３】
例えば、クレデンシャル情報は、パーミッション要求ファイル（permission request file）に含まれる。
【００１４】
例えば、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在する。
【００１５】
例えば、クレデンシャル情報は、供与者識別情報（Grantoridentifier）、有効期間（Expirationdate）、ファイル名（Filename）、署名（Signature）、およびＣｅｒｔｃｈａｉｎｆｉｌｅｉｄを含む。
【００１６】
例えば、アプリケーションが共有データにアクセスする前に、共有データを認証（authenticate）するステップをさらに含む。
【００１７】
例えば、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダの証明書（certificate）を用いて認証される。例えば、その証明書は、コンテンツプロバイダの署名を含む。
【００１８】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることができる。
【００１９】
例えば、その証明書は、コンテンツプロバイダ共同の署名（common signature）を含む。
【００２０】
本発明の他の態様においては、ローカルストレージを用いて記録媒体を再生する方法は、記録媒体と関連する暗号化した共有データをローカルストレージにダウンロードするステップと、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって共有データを含むバーチャルパッケージ（virtual package）を生成するステップと、バーチャルパッケージを用いて共有データを解読する（decrypt）ステップと、解読されたデータを再生するステップと、を含む。
【００２１】
例えば、共有データは、共有データにアクセスするアプリケーションの実行によって再生される。
【００２２】
例えば、アプリケーションは、共有データに対するアクセス情報としてアプリケーションのクレデンシャル情報を含む。
【００２３】
例えば、共有データは、アプリケーションに含まれたキーを用いて解読される。
【００２４】
例えば、共有データは、記録媒体内に格納されたキーを用いて解読される。
【００２５】
例えば、共有データは、光ディスクプレーヤー内に格納されたキーを用いて解読される。
【００２６】
例えば、バーチャルパッケージを生成するときに、共有データは、バーチャルパッケージを生成するために、認証される。
【００２７】
例えば、共有データが、１つのコンテンツプロバイダによって提供される記録媒体間で共有される場合、その共有データは、コンテンツプロバイダの１つの証明書内の１つの署名を用いて認証される。
【００２８】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの１つの証明書中の１つの共同の署名によって認証される。
【００２９】
例えば、共有データが、１つのコンテンツプロバイダによって提供される記録媒体間で共有される場合、その共有データは、コンテンツプロバイダのキーを用いて認証される。
【００３０】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダに合致する１つのキーを用いて認証される。
【００３１】
本発明のさらに他の態様においては、共有データを保護する装置は、記録媒体と関連したダウンロードされた共有データを格納するローカルストレージと、その共有データに対する有効なアクセス情報を持つアプリケーションがその共有データにアクセスするように制御する制御装置と、を含む。
【００３２】
例えば、アクセス情報は、アプリケーションのクレデンシャル情報である。
【００３３】
また、クレデンシャル情報は、パーミッション要求ファイルに含まれることが好ましい。
【００３４】
また、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在することが好ましい。
【００３５】
また、制御装置は、アプリケーションが共有データにアクセスする前に、その共有データを認証することが好ましい。
【００３６】
また、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダの証明書を用いて認証されることが好ましい。
【００３７】
また、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの１つの証明書を用いて認証されることが好ましい。
【００３８】
また、本発明のさらに別の態様においては、ローカルストレージを用いて記録媒体を再生する装置は、記録媒体と関連したダウンロードされた暗号化された共有データを格納するローカルストレージと、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって、共有データを含むバーチャルパッケージを生成し、そのバーチャルパッケージを用いて共有データを解読して再生する制御装置と、を含む。
【００３９】
共有データを解読するときに、制御装置は、共有データに対する有効なアクセス情報を有するアプリケーションが共有データにアクセスするように制御することが好ましい。
【００４０】
また、アクセス情報は、共有データにアクセスするアプリケーションのクレデンシャル情報であることが好ましい。
【００４１】
また、バーチャルパッケージを生成するときに、制御装置は、共有データを認証してバーチャルパッケージを生成することが好ましい。
【００４２】
また、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、制御装置は、共有データをコンテンツプロバイダの１つの証明書を用いて認証することが好ましい。
【００４３】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、制御装置は、複数のコンテンツプロバイダの証明書中の１つの共同の署名を用いて共有データを認証する。
【００４４】
例えば、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダのキーを使用して暗号化される。
【００４５】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダに合致するキーを使用して暗号化される。
【００４６】
例えば、共有データを解読するときに、制御装置は、共有データにアクセスするアプリケーションに含まれたキーを用いて共有データを解読する。
【００４７】
例えば、共有データを解読するときに、制御装置は、記録媒体内に格納されたキーを使用して共有データを解読する。
【００４８】
例えば、共有データを解読するときに、制御装置は、光記録再生装置に格納されたキーを使用して共有データを解読する。
【００４９】
したがって、本発明によれば、アプリケーションの悪意的な機能（malicious function）から再生システムを保護することが可能であり、さらには安全なコンテンツの提供が可能になる。したがって、本発明は、より便利な機能をユーザに提供する。
【００５０】
上述の一般的な説明及び後述する本発明の詳細な説明は、例示的かつ説明目的のためのものであり、特許請求の範囲として本発明のさらなる説明を提供することが意図される。
【発明の効果】
【００５１】
本発明は、次のような効果及び／または長所を提供する。
【００５２】
第一に、共有データを認証することによって、認証されたコンテンツプロバイダによって提供されたコンテンツ及び変質していないコンテンツのみを再生することができ、それによって、共有データを保護することができる。
【００５３】
第二に、また、アプリケーションに共有データに対するアクセス情報を提供することによって、権限のないアプリケーションによる悪意的な機能から共有データを保護することができる。
【００５４】
第三に、共有データを暗号化することによって、共有データが権限のないアプリケーションによって使用されることを防止できる。
【発明を実施するための最良の形態】
【００５５】
以下、本発明のさらなる理解を提供するために含まれ、本願の一部に組み込まれ、そして構成する添付図面は、本発明の実施形態及び本発明の原理を説明するのに役に立つ記述を用いて説明する。参照番号は、本発明の好ましい実施形態や添付図面に説明されている実施例に対して詳細に付される。同一または類似な構成要素については、可能なかぎり同一の参照符号を図面全体を通して使用する。
【００５６】
説明の便宜上、本発明は、記録媒体の一例として光ディスク、特に“ブルーレイディスク（ＢＤ）”をとりあげる。しかしながら、本発明の技術思想は、他の記録媒体にも同一に適用可能であることは自明である。
【００５７】
本発明において“ローカルストレージ（local storage）”とは、図１に示す光記録再生装置内に備えられた一種の格納手段であり、利用される必要な情報及びデータをユーザが任意に格納することができる構成要素を意味する。すなわち、現在一般的に使われるローカルストレージは、“ハードディスク”、“システムメモリ”、“フラッシュメモリ”などを含むが、本発明は必ずしもこれに限定されることはない。
【００５８】
特に、“ローカルストレージ”は、記録媒体（例えば、ブルーレイディスク）と関連したデータを格納する手段として用いられる。ローカルストレージ内に格納される記録媒体と関連したデータは、外部からダウンロードしたデータを含むことが一般的である。
【００５９】
また、記録媒体から直接読み取られた許容されたデータ（permitted data）、または記録媒体の記録再生操作と関連した生成されたシステムデータ（例えば、メタデータ等）は、ローカルストレージ内に格納されることができることは自明である。
【００６０】
本発明の説明の便宜上、記録媒体内に記録されたデータを“オリジナルデータ（original data）”と命名し、一方、ローカルストレージ内に格納されたデータのうち、記録媒体と関連したデータを“付加データ（additional data）”と命名する。
【００６１】
本発明において、“タイトル（Ｔｉｔｌｅ）”とは、ユーザとのインターフェースを構成する再生単位（reproduction unit）である。それぞれのタイトルは、特定のオブジェクトとリンクしている。ディスク内に記録された該当タイトルに関連したストリームは、オブジェクトファイル内のコマンドあるいはプログラムによって再生される。特に、本発明では、説明の便宜上、ディスク内に記録されたタイトルのうち、ＭＰＥＧ２圧縮方式による動画、映画及びインタラクティブ情報を有するタイトルを、“ＨＤＭＶタイトル”と命名する。また、ディスク内に記録されたタイトルのうち、Ｊａｖａプログラムによって実行される動画、映画及びインタラクティブ情報を有するタイトルを、“ＢＤ−Ｊタイトル”と命名する。
【００６２】
本発明において、タイトルは、インデックステーブルに存在するインデックス項目（indexing item）を意味する。すなわち、記録媒体がロードされると初期に再生される画面情報を有する“ファーストプレイバック（First Playback）”およびメニュー画面を提供する“トップメニュー（Top Menu）”は、タイトルの一種である。すなわち、ユーザとインターフェースを構成する再生単位は、その名称にかかわらず本発明のタイトルに該当する。
【００６３】
また、タイトルは、記録媒体内のデータ及び／またはローカルストレージ内のデータで構成されることを特徴とする。ローカルストレージ内のデータは、タイトルの再生中にダウンロードされるデータを含むことができる。
【００６４】
図１は、本発明の概念的理解を助けるために、光記録再生装置１０及び周辺機器間の統合的使用を説明する例示的な図である。
【００６５】
図１を参照すると、本発明の“光記録再生装置１０”は、様々な規格による光ディスクの記録または再生を可能にする装置である。そして、本発明の“光記録再生装置１０”は、特定の規格の光ディスク（例えば、ＢＤ）を記録／再生するように設計することができる。また、本発明の“光記録再生装置１０”は、光ディスクを再生だけするように作成しても良い。本発明の以下の説明では、ブルーレイディスク（ＢＤ）と周辺機器とのインタラクティブ性を考慮して、ＢＤプレーヤー（BD-Player）またはＢＤレコーダ（BD-Recorder）を一例としてとりあげる。また、本発明の“光記録再生装置１０”が、コンピュータなどにロード可能な“ドライブ”を含むことは自明である。
【００６６】
本発明の光記録再生装置１０は、光ディスク３０を記録再生する機能の他にも、外部入力信号を受信し、受信した信号を信号処理して、他の外部ディスプレイ２０を介してユーザに該当画面を伝達する機能を持つ。この場合、外部入力信号に特に制限はない。デジタルマルチメディア放送（ＤＭＢ：Digital multimedia broadcast）またはインターネットなどは、代表的な外部入力信号である。特に、容易にアクセス可能な媒体であるインターネットの場合、インターネット上の特定のデータは、光記録再生装置１０を介してダウンロードされて活用される。
【００６７】
また、外部ソースとしてコンテンツを提供する者をまとめて“コンテンツプロバイダ（ＣＰ）”と総称する。
【００６８】
また、本発明において、コンテンツとは、タイトルを構成する内容であって、記録媒体の製作者によって提供されるデータのことを意味する。
【００６９】
特に、本発明の目的は、“コンテンツプロバイダ”によって提供されるコンテンツを保護し、ユーザの再生システムを保護することにある。
【００７０】
オリジナルデータ及び付加データは、以下のように説明される。
【００７１】
例えば、特定のタイトルについての多重化されたＡＶストリームが光ディスク内に記録されたオリジナルデータとして記録され、かつオリジナルデータのオーディオストリーム（例えば、韓国語）とは異なるオーディオストリーム（例えば、英語）がインターネット上の付加データとして提供される場合、インターネット上の付加データであるオーディオストリーム（例えば、英語）をダウンロードしてオリジナルデータのＡＶストリームと共に再生しようとする要求、または、インターネット上の付加データであるオーディオストリーム（例えば、英語）をダウンロードしてそれだけを再生しようとする要求がユーザによっては存在する。このような要求を可能にするために、オリジナルデータ及び付加データ間の関連性（association）を規定する必要があり、これらのデータをユーザの要求に応じて管理／再生する体系化した方法が必要となる。
【００７２】
上記で説明の便宜上、ディスク内に記録された信号をオリジナルデータとし、ディスク外部に存在する信号を付加データと命名したが、これは単にそれぞれのデータを取得する方法によって区分したものであり、オリジナルデータまたは付加データは特定のデータに限定されることはない。
【００７３】
したがって、一般的な付加データには、オーディオ、プレゼンテーショングラフィック（ＰＧ：Presentation Graphic）、インタラクティブグラフィック（ＩＧ：Interactive Graphic）、テキストサブタイトル（Text subTitle）等が含まれるが、これらに限定されない。付加データは、列挙したデータ及びビデオを全て含む多重化されたＡＶストリームに相当する場合もある。すなわち、光ディスク外部に存在し、かつオリジナルデータと関連するいかなる種類の属性のデータも付加データになりうる。
【００７４】
また、付加データを、インデックスファイル（ｉｎｄｅｘ）、プレイリストファイル（＊．ｍ２ｔｓ）、またはクリップ情報ファイル（＊．ｃｌｐｉ）ごとに別個にダウンロードすることができる。また、付加データを、コンテンツ単位またはタイトル単位にダウンロードすることができる。
【００７５】
ユーザの要求を実現するためには、オリジナルデータ及び付加データ間のファイル構造を提供することが必要である。以下、図２及び図３を参照して、ブルーレイディスク（ＢＤ）用に使用可能なファイル構造及びデータ記録構造について詳細に説明する。
【００７６】
図２は、本発明による記録媒体（例えば、ＢＤ−ＲＯＭ）内に記録されるファイル構造の一実施例を示す図である。
【００７７】
図２を参照すると、本発明の再生管理ファイル構造には、１つのルートディレクトリの下に少なくとも１つのＢＤＭＶディレクトリが存在する。ＢＤＭＶディレクトリ内には、ユーザとの双方向性（interactivity）を保証する一般ファイル（上位ファイル）として、インデックスファイル（“ｉｎｄｅｘ．ｂｄｍｖ”）及びオブジェクトファイル（“ＭｏｖｉｅＯｂｊｅｔ．ｂｄｍｖ”）が存在する。
【００７８】
ＢＤＭＶディレクトリは、実際にディスク内に記録されたデータに関する情報とその記録されたデータを再生することに関する情報を持つディレクトリであり、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤ−Ｊオブジェクトファイルを含むＢＤＪＯディレクトリ、ＪＡＲファイルを含むＪＡＲディレクトリを含む。また、ＢＤＭＶディレクトリは、ディスク再生に関連した補助データを含むＡＵＸＤＡＴＡディレクトリも含む。以下、ディレクトリ及び各ディレクトリ内に含まれるファイルについて詳細に説明する。
【００７９】
ＳＴＲＥＡＭディレクトリには、ディスク内に特定フォーマットで記録されたＡＶストリームファイルが存在し、例えば、ストリームファイル（０１０００．ｍ２ｔｓ、…）の拡張子名として“＊．ｍ２ｔｓ”が使用される。すなわち、動映像データは、一般的に、ストリームファイル内に本発明と関連したコンテンツとして記録される。
【００８０】
ＣＬＩＰＩＮＦディレクトリは、それぞれのストリームファイルと対応するクリップ情報ファイル（０１０００．ｃｌｐｉ、…）を含む。特に、クリップ情報ファイル（＊．ｃｌｐｉ）は、対応するストリームファイルの属性情報及びタイミング情報を含む。特に、ストリームファイル（＊．ｍ２ｔｓ）と一対一対応するクリップ情報ファイル（＊．ｃｌｐｉ）をまとめて“クリップ（ｃｌｉｐ）”と命名できる。すなわち、このことは、対応する１つのストリームファイル（＊．ｍ２ｔｓ）には、１つのクリップ情報ファイル（＊．ｃｌｐｉ）が必ず存在する、ということを意味する。
【００８１】
ＰＬＡＹＬＩＳＴディレクトリは、プレイリストファイル（０００００．ｍｐｌｓ、…）を含む。それぞれのプレイリストファイル（＊．ｍｐｌｓ）は、特定のクリップの再生時間を指定する少なくとも１つのプレイアイテム（ＰｌａｙＩｔｅｍ）を含む。プレイアイテムは、再生される特定のクリップ、すなわち、プレイアイテム内でクリップ名（ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｆｉｌｅ＿ｎａｍｅ）として指定されるクリップの再生開始時間（ＩＮ−Ｔｉｍｅ）及び再生終了時間（ＯＵＴ−Ｔｉｍｅ）に関する情報を有する。
【００８２】
すなわち、プレイリストファイル（＊．ｍｐｌｓ）は、少なくとも１つまたは複数のプレイアイテムの組み合わせによって特定のクリップの再生を実行する、全体再生管理ファイル構造内の基本的再生管理ファイル単位となる。
【００８３】
特に、プレイリストファイル（＊．ｍｐｌｓ）は、オブジェクトファイル内の特定のオブジェクトファイルによるコマンドによって操作されうる。したがって、ディスク再生シナリオの観点では、オブジェクトファイルは、動的なシナリオ（Dynamic scenario）を実行し、または管理し、そして、プレイリストファイル（＊．ｍｐｌｓ）は、静的なシナリオ（Static scenario）を実行し、または管理する。
【００８４】
ＢＤＪＯディレクトリは、ＢＤ−Ｊタイトルを再生するためのＢＤ−Ｊオブジェクトファイルを含む。
【００８５】
ＪＡＲディレクトリは、ＢＤ−Ｊについての全ての“ｘｘｘｘｘ．ｊａｒ”を含む。ＪＡＲ（Java archive）ファイルは、複数のファイルのまとまりを配布する際に使われる圧縮ファイルである。ＪＡＲファイルは、通常、特定のｊａｖａプログラムと関連したｊａｖａクラスファイル、補助リソース（auxiliary resource）、及びメタデータなどで構成される。様々なアプリケーションをＪＡＲファイルによって構成することができる。
【００８６】
ＡＵＸＤＡＴＡディレクトリは、ディスク再生と関連した補助的な情報を含むファイルを含む。例えば、ＡＵＸＤＡＴＡディレクトリは、再生時にクリックサウンド情報及びメニューサウンド情報などを提供するサウンドファイル（“Ｓｏｕｎｄ．ｂｄｍｖ”）と、テキストサブタイトルの再生時にフォント情報を提供するフォントファイル（“１１１１１．ｏｔｆ”）とを含むことができる。
【００８７】
ＭＥＴＡディレクトリは、メタデータを備える。メタデータは、データに対するデータである。例えば、メタデータは、サーチファイル及びディスクライブラリファイルなどを含む。
【００８８】
上述したファイル及びディレクトリの位置は、一つの例に過ぎない。必要に応じてその位置が変更されることは自明である。例えば、ＢＤＪＯディレクトリ及びＪＡＲディレクトリをサブディレクトリとして、ルートディレクトリの下に別個に構成することも可能である。もう一つの例として、ＪＡＲディレクトリを上位ディレクトリとしてルートディレクトリの下に構成しても良い。
【００８９】
また、ルートディレクトリは、記録媒体内に記録されたデータの保護に関する情報、またはローカルストレージにダウンロードされるデータの保護に関する情報を有するディレクトリを含むことができる。このことは、図２に示す実施形態では、ＣＥＲＴＩＦＩＣＡＴＥディレクトリとして表される。アプリケーション認証及びバインディングユニット認証のためのルート証明書ファイルが、ＣＥＲＴＩＦＩＣＡＴＥディレクトリ内に位置している。
【００９０】
図３は、本発明による記録媒体に記録されるデータ記録構造を示す図であり、前述したファイル構造に関連した情報がディスク内に記録されるフォーマットを示している。
【００９１】
図３を参照すると、ディスクの内周から順に、ファイル全体を管理するシステム情報であるファイルシステム情報領域と、記録されたストリーム（＊．ｍ２ｔｓ）を再生するための、インデックスファイル、オブジェクトファイル、プレイリストファイル、クリップ情報ファイル及びメタデータファイルが記録された領域（“データベース領域”）と、及びオーディオ／ビデオ／グラフィックなどで構成されたストリームまたはＪＡＲファイルが記録されるストリーム領域またはデータ領域（“ＡＶストリーム領域”）と、が存在する。
【００９２】
また、データ領域内のコンテンツを再生するためのファイル情報などを記録する領域を管理領域と名付ける。ファイルシステム情報領域およびデータベース領域は、管理領域に該当する。ただし、図３に示した各領域は、一例として提示されている。本発明が図３に示す各領域の配列構造に限定されないということは自明である。
【００９３】
図４は、本発明の一実施形態による光記録再生装置１０のブロック図である。
【００９４】
図４を参照すると、本発明の一実施形態による光記録再生装置は、光ディスクに記録されたオリジナルデータ及び再生管理ファイル情報を含む管理情報を再生するピックアップ１１と、ピックアップ１１の動作を制御するサーボ１４と、ピックアップ１１から受信した再生信号を特定の信号値に復元し、記録される信号を光ディスクに記録される信号に変調し、その変調された信号を伝達する信号処理部１３と、上記動作を制御するマイクロプロセッサ１６と、を備える。
【００９５】
光ディスク外に存在する付加データは、制御装置１２によってローカルストレージ１５にダウンロードされる。制御装置１２は、ローカルストレージ１５内のバインディングユニットマニフェストファイル（Binding Unit Manifest File）に記録された情報を用いてバインディングユニット（binding unit）を生成する。また、制御装置１２は、記録媒体のデータ及びローカルストレージ１５内のデータを再生するために、ローカルストレージ１５内のバインディングユニットマニフェストファイルに記録されたネームマッピング情報を用いてバーチャルパッケージを生成する。制御装置１２は、生成されたバーチャルパッケージを用いてオリジナルデータ及び／または付加データをユーザの要求に応じて再生する。
【００９６】
また、バーチャルパッケージは、バーチャルファイルシステム（virtual file system）によって行われるバインディングオペレーションを介して生成され、ディスク内の相異なる領域に格納されているオリジナルデータで構成されたオリジナルクリップ（original clip）およびローカルストレージ１５内の付加データで構成された付加クリップ（additional clip）を再生管理する１つのファイル構造となる。
【００９７】
バインディングユニットマニフェストファイルは、バーチャルパッケージを生成するバインディングオペレーションに使用される情報を含む。バインディングユニットマニフェストファイルがないと、ローカルストレージ１５内のデータを記録媒体内のファイル構造（ディスクパッケージ）とバインディングしてバーチャルパッケージを生成することができない。
【００９８】
ネームマッピング情報は、バインディングユニットマニフェストファイルに記録されている情報であり、記録媒体内に記録されたデータがバーチャルパッケージにおいてどの位置に存在しているかを示す情報である。
【００９９】
新しく生成されたバーチャルパッケージを後々の再利用のためにローカルストレージ１５に格納し、または、別のダイナミックメモリを用いて一時的に格納することができる。
【０１００】
本発明において、制御装置１２は、アプリケーション及びコンテンツが真のコンテンツプロバイダ（ＣＰ）によって提供されたか否かを認証し、アプリケーションのコンテンツへのアクセスを制御する。アプリケーションの認証については、図５の記述において詳細に説明する。
【０１０１】
また、再生システム１７は、制御装置１２の制御のもと、出力データを最終的にデコードしてユーザに提供する。再生システム１７は、ＡＶ信号をデコードするデコーダと、前述した特定のタイトルの再生と関連したオブジェクトコマンドあるいはアプリケーション、および制御装置１２を介して入力されるユーザコマンドを解析することによって再生方向を決定するプレーヤーモデルと、を含む。再生システム１７については、図１２の記述でさらに詳細に説明する。
【０１０２】
光ディスクに信号を記録する機能を果たすために、ＡＶエンコーダ１８は、制御装置１２の制御によって入力信号を特定のフォーマットの信号、例えば、ＭＰＥＧ−２トランスポートストリームに変換し、その変換された信号を信号処理部１３に提供する。
【０１０３】
図５は、本発明によるローカルストレージ１５内のファイル構造の一実施形態を示す図である。
【０１０４】
図５を参照すると、ローカルストレージには、記録媒体から読み取られたデータまたは記録媒体の外部ソースからダウンロードされたデータを格納することができる。データを格納する領域は、大きく、アプリケーションデータを格納する際に使用される“アプリケーションデータ領域６２０”とバーチャルパッケージの生成に用いられる“バインディングユニットデータ領域６１０”とに区分されることができる。
【０１０５】
図５の一実施形態において、ローカルストレージ１５内の“バインディングユニットデータ領域６１０”には、プロバイダ（organization-dependent）ディレクトリが３個（ｏｒｇ１＿ＩＤ、ｏｒｇ２＿ＩＤ、ｏｒｇ３＿ＩＤ）存在する。これらは、それぞれのコンテンツプロバイダ（ＣＰ）を意味する。例えば、映画の場合には、映画会社または映画配給会社がその組織（organization）に該当する。
【０１０６】
また、プロバイダ共有（organization-dependent shared）ディレクトリも存在することができる。コンテンツプロバイダ間で共有されるデータは、その共有ディレクトリ６１０ａに存在する。
【０１０７】
プロバイダディレクトリである“ｏｒｇ１＿ＩＤ”は、下位ディレクトリとしてディスク（disc-dependent）ディレクトリの“ｄｉｓｃ１＿ＩＤ”、“ｄｉｓｃ２＿ＩＤ”及びディスク共有（disc-dependent shared）ディレクトリ６１０ｂを含む。ディスク共有ディレクトリ６１０ｂには、“ｏｒｇ１＿ＩＤ”が提供した“ｄｉｓｃ１＿ＩＤ”と“ｄｉｓｃ２＿ＩＤ”記録媒体間で共有されるデータが存在する。
【０１０８】
“ｄｉｓｃ１＿ＩＤ”には、“ｏｒｇ１”が提供する“ｄｉｓｃ１”とバインディングされるバインディングユニット（binding unit）が存在する。バインディングユニットには、プレイリストファイルの“Ａｐｒ２００５．ｍｐｌｓ（６１１）”とクリップ情報ファイルの“Ａｐｒ２００５．ｃｌｐｉ（６１２）”と、ストリームファイルの“Ａｐｒ２００５．ｍ２ｔｓ（６１３）”と、が存在する。これらのファイルと記録媒体内のデータとがバインディングすることによってバーチャルパッケージを生成する方法が、図１３を参照して後で説明される。
【０１０９】
“アプリケーションデータ領域６２０”には、供給者（organization-dependent）ディレクトリが３個（ｏｒｇ１＿ＩＤ、ｏｒｇ２＿ＩＤ、ｏｒｇ３＿ＩＤ）存在する。“ｏｒｇ１＿ＩＤ”の下位ディレクトリとして“ｄｉｓｃ１＿ＩＤ” ディレクトリ及び“ｄｉｓｃ２＿ＩＤ”ディレクトリが存在する。“ｄｉｓｃ１＿ＩＤ”ディレクトリは、特定のアプリケーションをそれぞれ構成するＪＡＲファイルである“Ａｐｐ０．ｊａｒ（６２１）”及び“Ａｐｐ１．ｊａｒ（６２２）”を含む。 “ｄｉｓｃ２＿ＩＤ”ディレクトリは、ＪＡＲファイルである“Ａｐｐ０．ｊａｒ（６２３）”を含む。
【０１１０】
また、アプリケーションは、特定の機能を行うプログラムを意味する。その機能を行うために、アプリケーションは、全てのデータ、ファイル、及び再生システム１７のハードウェア構成またはソフトウェア構成などにアクセス可能になっていなければならない。例えば、“ｄｉｓｃ１＿ＩＤ”ディレクトリの“Ａｐｐ０．ｊａｒ（６２１）”によって構成されるアプリケーション（以下、“Ａｐｐ０”という）が特定の機能を行い、その機能を行うために“ｏｒｇ１＿ＩＤ”であるコンテンツプロバイダが提供した記録媒体間で共有されるデータ“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”のデータが必要な場合には、“Ａｐｐ０”は、“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”にアクセスする。
【０１１１】
本発明は、同一のコンテンツプロバイダ（ＣＰ）が提供した記録媒体間で共有されるデータ（例えば、ディスク共有ディレクトリ６１０ｂに存在するデータである、図５の“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”）、または、コンテンツプロバイダ（ＣＰ）間で共有されるデータ（例えば、共有ディレクトリ６１０ａに存在するデータ）を保護するためのセキュリティ案を提供しようとする。
【０１１２】
このような共有データを保護するための３つのセキュリティ案のレベルが考慮されることができる。
【０１１３】
まず、第１のレベルは、全てのアプリケーションに全ての共有データへのアクセスを許容する場合である。この場合にはいかなるセキュリティメカニズムも要求されないので、本発明では第１のレベルは述べない。
【０１１４】
したがって、本発明が提供しようとするセキュリティ案のレベルは、第２のレベルと第３のレベルとなる。なかでも２番目は、共有データに対する認証が共有データを保護するのに充分であると仮定する。これは、共有データを用いるアプリケーションが共有データへのアクセスがそれぞれ許容される場合には、アプリケーションの動作が信頼できることを前提とする。
【０１１５】
第３のレベルは、共有データへのアクセスが許容されたアプリケーションの悪意的な機能を排除できないとの仮定の下に、共有データを暗号化してユーザに提供することによって、共有データを保護するやり方である。したがって、共有データにアクセスするアプリケーションは、共有データを解読できなければならない。
【０１１６】
以下、図６乃至図１０に基づき、本発明が提供する第２のセキュリティレベルについて説明する。また、図１１では、第３のセキュリティレベルおよびこの第３のセキュリティレベルが適用された場合の共有データの再生について説明する。
【０１１７】
図６乃至図９は、本発明による共有データ保護のための共有データ及びアプリケーションの認証について示す。図１０は、共有データにアクセスするアプリケーションのためにアクセス情報を提供することによって共有データを保護する方法を示す。
【０１１８】
図６は、本発明の一実施形態による共有データ認証を示す図である。
【０１１９】
図６を参照すると、コンテンツプロバイダ（ＣＰ）は、データを提供する際に、そのデータに対する証明書をユーザに提供する。その証明書は、記録媒体内に記録された形態でユーザに提供されても良く、記録媒体外からダウンロードされてユーザに提供されても良い。
【０１２０】
この証明書は、バージョン、シリアル番号、署名アルゴリズム（signature algorithm）、発行人（issuer）、有効期間、認証対象、公開鍵（public key）などを含むことができる。
【０１２１】
ここで、公開鍵とは、公開鍵暗号体系で用いられる１つのエンティティの非対称キーペア（key pair）の、公開されているキーを意味する。その公開鍵は、署名システムで署名の真偽を判断するのに用いられ、検証キー（verification key）ともいう。一方、秘密鍵（private key）とは、公開鍵暗号体系で用いられる１つのエンティティの非対称キーペアの中で公開されないキーのことをいう。ある場合には、秘密鍵は、対称キー暗号体系で用いられるキーを意味する。
【０１２２】
証明書は、ユーザに提供されるデータが適法なコンテンツプロバイダによって提供されたことを証明するために用いられる。また、その証明書は、証明書を発行した証明書権威者（ＣＡ：certificate authority）のデジタル署名を含む。図６の実施形態では、例えば、コンテンツプロバイダが自分自身で証明をする。したがって、証明書権威者（ＣＡ）は、コンテンツプロバイダ（ＣＰ）自身となる。証明書の証明については、図７で詳細に説明する。
【０１２３】
コンテンツプロバイダ（ＣＰ）は、ＳＨＡ−１（Secure Hash Algorithm-1）及びＭＤ５（Message Digest algorithm 5）などのダイジェストアルゴリズム６０１０を用いて、コンテンツダイジェスト６０１１を生成してユーザに提供する。
【０１２４】
ここで、コンテンツダイジェストとは、それぞれのコンテンツごとに固有に算出されるように作られた簡単な文字列のことを意味する。そのコンテンツダイジェストは、任意の長さのコンテンツに無方向のハッシュ関数を反復適用することによって、簡潔にされた一定の長さのビット列として表現される。各コンテンツ（メッセージ、文章、ファイルなど）ごとに１つのコンテンツダイジェストが算出される。そして、異なる文書から同一のコンテンツダイジェストを算出することはできない。この結果、コンテンツダイジェストは、原文の偽造有無を確認する手段として使用することができる。
【０１２５】
生成されたコンテンツダイジェスト６０１１は、コンテンツプロバイダの秘密鍵６０１３を用いて署名アルゴリズム６０１２を介してデジタル署名になる。コンテンツプロバイダは、デジタル署名を含む証明書をコンテンツと共にユーザに提供する。
【０１２６】
ここで、署名アルゴリズムとは、ＲＳＡ（Rivest-Shamir-Adelman）、ＤＳＡ（digital signature algorithm）などの暗号化アルゴリズムの一種である。
【０１２７】
デジタル署名は、上記デジタル署名に用いられた秘密鍵６０１３に対応する公開鍵６０１７を用いて署名アルゴリズム６０１６を介してコンテンツダイジェスト６０１８に復元されることができる。公開鍵６０１７は、証明書中に含まれてユーザに提供される。デジタル署名の生成に用いられた秘密鍵６０１３に対応する公開鍵６０１７が存在しない場合、デジタル署名をコンテンツダイジェスト６０１８に復元することができない。この場合には、提供されたアプリケーションが適法なコンテンツプロバイダによって提供されたものと認証されない。
【０１２８】
また、公開鍵６０１７の存在により、デジタル署名をコンテンツダイジェスト６０１８に復元したとしても、提供されたコンテンツが変質した場合には認証に失敗する。
【０１２９】
すなわち、コンテンツプロバイダによって提供されたコンテンツは、ダイジェストアルゴリズム６０１４を介してコンテンツダイジェスト６０１５として算出される。算出されたコンテンツダイジェスト６０１５は、デジタル署名を用いて復元されたコンテンツダイジェスト６０１８と比較される（６０１９）。コンテンツが変質した場合、復元されたコンテンツダイジェスト６０１８は、提供されたコンテンツから算出されたコンテンツダイジェスト６０１５とは異なる。このため、コンテンツの認証は失敗する。
【０１３０】
共有データの認証に失敗する場合には、その共有データの再生が制限されることが好ましい。すなわち、本発明において、共有データは、再生される記録媒体の外部からローカルストレージにダウンロードされても良い。記録媒体がロードされ、かつ共有データがロードされた記録媒体と関連する場合には、その共有データは、記録媒体内のディスクパッケージにバインディングされる。このバインディングオペレーションは、上述した再生システム１７のバーチャルファイルシステムによって行われる。もし、共有データの認証に失敗する場合には、バーチャルファイルシステムは、共有データをディスクパッケージにバインディングしなくても良い。これにより、ダウンロード中に損傷した、またはハッキングなどによって変質した共有データが記録媒体と共に再生されることを防ぐことができる。また、権限のないコンテンツプロバイダによって提供された共有データが再生されることを防止できる。したがって、記録媒体のコンテンツプロバイダ及び共有データのプロバイダを保護することが可能になる。
【０１３１】
図７は、本発明によるデータ認証に用いられる証明書チェーン（certificate chain）を示す図である。
【０１３２】
複数個の証明書が階層的連結構造を形成しながらコンデンツに含まれることができる。ここで、１つの証明書はその以前の証明書の真偽を証明する。証明書の階層構造の最上位は、ルートＣＡであるが、このルートＣＡは、他のＣＡからの証明書がなくても信頼される。証明書は、記録媒体やＢＤ端末内に位置するキーデータベース（key database）に格納される。
【０１３３】
具体的に説明すると、信頼されたルート証明書権威者（ＣＡ）が証明書権威者７０２、７０３、７０４を認証できる。認証される証明書権威者は、ＡＡＣＳ（Advanced Access Content System）、またはＣＰＳ（Content Protection System）でありうる。場合によっては、ＡＡＣＳやＣＰＳ自身がルート証明書権威者にもなりうる。
【０１３４】
ＡＡＣＳ、ＣＰＳ、または他の証明書権威者は、光記録再生装置、コンテンツプロバイダ等（７０２ａ、７０２ｂ、７０２ｃ、７０２ｄ）などの下位構造を独立的に認証できる。このような構造を証明書チェーンという。
【０１３５】
このような証明書チェーンにおいては、信頼された証明書権威者（ＣＡ）を認証できる上位の証明書権威者は存在しない。この場合、信頼された証明書権威者は、自分自身（７０１）を認証するが、これはルート認証（root certification）に該当する。
【０１３６】
それぞれの証明書権威者は、自分自身またはその下位構造の認証の結果に対して、それぞれの証明書権威者のデジタル署名を含む証明書を提供する。証明書チェーンの最下位の証明書権威者が提供する証明書をリーフ証明書（leaf certificate）といい、証明書チェーンの最上位の証明書権威者が提供する証明書をルート証明書という。これらの証明書はデジタル署名の検証過程でデジタル署名を復元する公開鍵のインテグリティを保証することができる。
【０１３７】
なお、信頼された証明書権威者が提供する信頼されたルート証明書は、記録媒体の特定の領域にファイルの形態などで格納されてユーザに提供される、または、記録媒体の外部からダウンロードされて光記録再生装置のキーストア（key store）に格納されることもできる。
【０１３８】
本発明は、共有データの認証を通じて共有データを保護することを意図する。したがって、共有データが、同一のコンテンツプロバイダ、例えば、コンテンツプロバイダ１（ＣＰ１）が提供した記録媒体間で共有される場合には、コンテンツプロバイダ１の証明書７０２ｂが共有データの認証に用いられる。
【０１３９】
また、共有データが複数のコンテンツプロバイダ、例えば、コンテンツプロバイダ１（ＣＰ１）及びコンテンツプロバイダ２（ＣＰ２）によって提供される記録媒体間で共有される場合には、コンテンツプロバイダ１、２両方の証明書７０２ｄが共有データの認証に用いられる。
【０１４０】
証明書チェーンを通じて生成された証明書は、記録媒体の特定の領域にファイルの形態などで格納されて認証に用いられるか、または、ネットワーク上での認証に用いられることができる。
【０１４１】
場合によっては、それぞれの証明書権威者は、証明書破棄リスト（Certificate Revocation List：ＣＲＬ）を作成することができる。この場合、コンテンツプロバイダ及びユーザは、証明書破棄リスト（ＣＲＬ）をダウンロードして受信し、証明書を介して認証する前に、認証に使用する証明書が破棄されたか否かを検査する。万一、認証しようとする証明書が破棄された場合は、認証が成立しない。一方、証明書が破棄されなかった場合は、他の認証要件を満足する限り認証が成立する。
【０１４２】
本発明が提供する第２のセキュリティレベルでは、特定の機能を行う各アプリケーションが認定された場合、アプリケーションの動作が信頼するに値するということを前提とする。このため、共有データへのアクセス権限があるアプリケーションのみが共有データにアクセスすることが認められる。アプリケーションの動作が信頼されるためには、当該アプリケーションが認証される必要がある。このことを図８乃至図１０を参照して、以下のように詳細に説明する。
【０１４３】
図８及び図９は、本発明によるアプリケーションの認証について示す図である。図１０は、本発明による共有データに対するアクセス情報を持つアプリケーションを構成するＪＡＲファイルを示す図である。ここで、署名されたアプリケーション（signed application）を例に挙げて図８及び図９について説明する。
【０１４４】
図８は、本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図を示す。
【０１４５】
図８を参照すると、圧縮ファイルの一種であるＪＡＲファイルは、複数のファイルを１つにまとめるのに用いられている。ＪＡＲファイルが署名されている場合、このＪＡＲファイルを“署名されたＪＡＲファイル”という。この署名されたＪＡＲファイルによって構成されたアプリケーションを“署名されたアプリケーション”という。この署名されたＪＡＲファイルは、マニフェストファイル（Manifest file）がアップデートされていること、並びに署名ファイル（Signature file）及び署名ブロックファイル（Signature Block file）がＭＥＴＡＩＮＦＯディレクトリに追加されていること以外は、元々のＪＡＲファイルと同一である。
【０１４６】
図８のアプリケーションは、署名されたアプリケーションである。このアプリケーションを構成するＪＡＲファイルは、“Ａｐｐ０”ファイル及びＭＥＴＡＩＮＦＯディレクトリ８１を含む。“Ａｐｐ０”ファイルは、“ｃｌａｓｓｅｓ”ファイルとデータディレクトリを含む。このデータディレクトリには“Ａｐｐ０．ｄａｔ”ファイルが存在する。“ｃｌａｓｓｅｓ”ファイルは、“Ａｐｐ０．ｃｌａｓｓ”ファイルと“ｓｕｂｃｌａｓｓｅｓ”ディレクトリを含む。この“ｓｕｂｃｌａｓｓｅｓ”ディレクトリには、“ｓｕｂ１．ｃｌａｓｓ”及び“ｓｕｂ２．ｃｌａｓｓ”が存在する。また、図８の実施形態では、例えば、全てのクラスファイル（Ａｐｐ０．ｃｌａｓｓ、ｓｕｂ１．ｃｌａｓｓ、ｓｕｂ２．ｃｌａｓｓ）が署名される。
【０１４７】
ＭＥＴＡＩＮＦＯディレクトリ８１は、１つのマニフェストファイル８１１（ＭＡＮＩＦＥＳＴ．ＭＦ）及び１つの署名ブロックファイル８１３（ＸＸＸ．ＲＳＡ）を含む。これらのファイルによってアプリケーションの認証がなされる。
【０１４８】
マニフェストファイル８１１は、１つのＪＡＲファイル内に、署名された各ファイルに対するメッセージダイジェスト（message digest）とともにファイルのリストを含む。また、ＪＡＲファイル内の全てのファイルがマニフェストファイル８１１にエントリー（entry）としてリストされる必要はない。しかし、署名される全てのファイルはリストされなければならない。したがって、“Ａｐｐ０．ｃｌａｓｓ”ファイル、“ｓｕｂ１．ｃｌａｓｓ”ファイル、“ｓｕｂ２．ｃｌａｓｓ”ファイルに対するエントリーは、マニフェストファイル８１１にリストされなければならない。
【０１４９】
署名ファイル８１２は、マニフェストファイルのダイジェストを含む。署名ファイルは、権限ある供給者（authorizing organization）によって署名されたデータとなる。
【０１５０】
署名ファイル８１２のコンテンツを使用してメッセージダイジェストを計算した後、秘密鍵を用いて署名アルゴリズムを介して、その計算された結果を暗号化することによってデジタル署名が生成される。デジタル署名は、署名ファイルの署名されたバージョンになることができる。生成されたデジタル署名は、署名ブロックファイル８１３内に位置する。各署名ファイルは、多数のデジタル署名を持つことができるが、この複数の署名は同一の適法なエンティティによって生成されなければならない。
【０１５１】
また、この秘密鍵は、署名ブロックファイル８１３に存在する公開鍵に対応する秘密鍵である。この公開鍵は、署名ブロックファイル内の証明書のリーフ証明書のいずれか１つに位置する。この公開鍵を認証する証明書は、署名ブロックファイルに含まれる。
【０１５２】
署名ブロックファイル８１３は、デジタル署名ファイルとも呼ぶことができる。デジタル署名ファイルは、署名ファイル８１２と同じファイル名を持つが、異なる拡張子を持っている。この拡張子は、署名アルゴリズムによって定められる。例えば、この拡張子には、“．ＲＳＡ”または“．ＤＳＡ”などが相当する。
【０１５３】
共有データにアクセスするアプリケーションの認証は、アプリケーションを構成するＪＡＲファイル内のファイルを認証するやり方で行われる。署名されたＪＡＲファイル内のファイルの認証について、図９を参照して以下のように具体的に説明する。
【０１５４】
図９は、本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイル内のファイルの認証過程のフローチャートであり、アプリケーションの認証は、図６で示すようなコンテンツの認証と類似する方式で行われる。
【０１５５】
図９を参照して説明すると、１つのマニフェストファイルが最初に解析される（parse）とき、ある署名ファイルに対する署名は初めて検証（verify）される（Ｓ１０）。デジタル署名は、署名ブロックファイルに存在する。具体的に説明すると、この署名ファイルに対応する署名ブロックファイルを探し、その署名ブロックファイルから証明書を読み取る。これらの証明書のうち、リーフ証明書内には、この署名ファイルの生成に用いられた秘密鍵に対応する公開鍵が存在する。署名ブロックファイル内に存在する秘密鍵を用いて暗号化されたデジタル署名は、この公開鍵を用いてダイジェスト値に復元される。復元されたダイジェスト値は、署名ファイルのダイジェスト値と比較される。この比較の結果、両者が同一であると、デジタル署名の検証が実行される。デジタル署名の検証に失敗する場合、ファイルに対する認証は失敗となる（Ｓ７０）。
【０１５６】
認証されるファイルの有効性を確認するために、マニフェストファイルに対するダイジェスト値が計算される（Ｓ２０）。計算されたダイジェスト値が、署名ファイル内に存在するダイジェスト値と比較される（Ｓ３０）。比較された両ダイジェスト値が異なる場合、ファイルの認証は失敗となる（Ｓ７０）。比較された両ダイジェスト値が同一である場合、マニフェストファイルに対するインテグリティが確認される。
【０１５７】
比較されたダイジェスト値が同一である場合、認証されるファイルの実際のデータに対するダイジェスト値が計算される（Ｓ４０）。計算されたダイジェスト値がマニフェストファイル内のダイジェスト値と比較される（Ｓ５０）。
【０１５８】
比較された両ダイジェスト値が同一であるとファイルの有効性が確認され、ファイルの認証に成功する（Ｓ６０）。一方、比較された両ダイジェット値が異なるとファイルの認証は失敗となる（Ｓ７０）。
【０１５９】
本発明は、アプリケーションを構成するＪＡＲファイル内のファイルを認証する際に、署名ファイルを用いてマニフェストファイルのインテグリティを確認し、署名ブロックファイルを用いてデジタル署名を検証することを特徴とする。また、マニフェストファイルを用いてＪＡＲファイルの実際のデータに対するインテグリティを確認することを特徴とする。
【０１６０】
したがって、ＪＡＲファイルの実際のデータに対するインテグリティ確認（Ｓ４０、Ｓ５０）、マニフェストファイルのインテグリティ確認（Ｓ２０、Ｓ３０）、及びデジタル署名の検証（Ｓ１０）は、個別的に実行可能である。すなわち、図９の実施形態で説明した認証フローの順序は必須ではなく、再生システムによって順序が変わっても良い。
【０１６１】
また、アプリケーションを認証する際に、認証されるファイルがマニフェストファイルでリストされたものかを、認証されるファイルの実際のデータに対するダイジェスト値が計算（Ｓ４０）される前に確認することも可能である。
【０１６２】
また、デジタル署名に対する検証結果（Ｓ１０）とマニフェストファイルに対するインテグリティ確認の結果（Ｓ３０）は、後々に使用するために格納されても良い。この場合、Ｓ１０〜Ｓ３０のステップは、１つのＪＡＲファイルの認証過程で１回しか行われない。
【０１６３】
アプリケーションの認証に失敗しても、プレーヤーの実装によって共有データへのアクセスを許容することができる。しかし、共有データの保護のためにアクセスが制限されることが好ましい。このアクセス制限の程度は、プレーヤーの実装によって、認証されなかったアプリケーションが全ての共有データにアクセスすることを制限されるように設定することが可能である。または、プレーヤーによっては、制限された範囲の共有データにのみアクセスできるように制御しても良い。
【０１６４】
図１０は、本発明の一実施形態によるアプリケーションを構成するＪＡＲファイルの図である。
【０１６５】
図１０を参照すると、共有データへのアクセス権限があるアプリケーションのみが前記共有データにアクセスできるようにすべく、本発明は共有データをリソースとするアプリケーションのために共有データに対するアクセス情報を使用する。有効なアクセス情報を持つアプリケーションのみが共有データにアクセス可能になるため、権限のないアプリケーションによる共有データの利用を防ぐことができる。
【０１６６】
アクセス情報は、アプリケーションに対するクレデンシャル情報でありうる。クレデンシャル情報はパーミッション要求ファイルに含まれることができる。パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在できる。
【０１６７】
図１０のＪＡＲファイル（Ａｐｐ０．ｊａｒ）は、アプリケーションを構成するファイルである。このＪＡＲファイルには、クレデンシャル情報を含むパーミッション要求ファイル（Ａｐｐ０．ｐｅｒｍ）が存在する。クレデンシャル情報としては、“供与者識別子（Grantor identifier）”、“有効期間（Expiration date）”、“ファイル名（Filename）”、“署名（Signature）”、“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”などが存在する。
【０１６８】
この“供与者識別子（Grantor identifier）”は、アプリケーションを提供する主体に関する情報である。“供与者識別子（Grantor identifier）”としては、例えば、“ｏｒｇ１＿ＩＤ”などがありうる。
【０１６９】
この“有効期間”は、クレデンシャル情報の有効期間を意味する。例えば、“有効期間”が“２３／０２／２０３５”と与えられた場合、このクレデンシャル情報を含むアプリケーションは、２０３５年０２年２３日が経過した後には共有データにアクセスできなくなる。
【０１７０】
この“ファイル名”は、アプリケーションがアクセスしようとする共有データの位置およびその共有データに対して付与される読取り／書込み権限に関する情報である。例えば、“ファイル名読取り”情報が”真（true）”と与えられ、“ファイル名”が前記ファイルの存在する位置で表現されて、“ＢＵＤＡ／ｏｒｇ１＿ＩＤ／Ｓｈａｒｅｄ／Ｊａｐａｎｅｓｅ．ｏｔｆ”と与えられることができる。図６を参照して説明すると、次の通りである。クレデンシャル情報を持つアプリケーションは、ローカルストレージ内のバインディングユニットデータ領域の“ｏｒｇ１＿ＩＤ”ディレクトリのディスク共有（disc-dependent shared）ディレクトリである“Ｓｈａｒｅｄ”ディレクトリ内に存在する“Ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”ファイルにアクセスすることによって、“Ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”ファイルを読み取ることができることを意味する。
【０１７１】
“署名”は、アプリケーションプロバイダからの署名を含む。そして、“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”は、署名ブロックファイル内の特定の証明書の位置を表すのに用いられる。“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”は、認証に用いられるリーフ証明書のシリアル番号に対応する特定のｓｅｒｉａｌ Ｎｕｍｂｅｒおよび認証に用いられるリーフ証明書の主体に対応する発行者の情報を含む。署名の公開鍵に通じる証明書は、署名ブロックファイル内の“ｃｅｒｔｉｆｃａｔｅｓ”フィールドに存在しなければならない。クレデンシャル情報のｃｅｒｔｃｈａｉｎｆｉｅｌｄフィールドのコンテンツに対応する発行者フィールドのシーケンス番号及び組織（organization）ＩＤが一緒に見つけられるまで、各証明書は確認されなければならない。もし、対応する証明書が前記署名ブロックファイル内に存在すると、ファイルアクセスは許容されない。
【０１７２】
アプリケーションに対するクレデンシャル情報が認証され、かつ共有データに対する有効な“ファイル名”を含む場合、当該アプリケーションは、共有データにアクセスできる。これに対し、クレデンシャル情報が有効でない場合、当該アプリケーションは信頼できず、当該アプリケーションの共有データへのアクセスは制限される。結果として、本発明によれば、共有データにアクセスするアプリケーションにクレデンシャル情報をおくことによって共有データを保護することができる。
【０１７３】
また、バーチャルパッケージを構成する間に、ローカルストレージにあるＪＡＲファイルが、記録媒体内の対応するＪＡＲファイルよりも優先権を持つ場合がある。この場合、記録媒体内のＪＡＲファイルがクレデンシャル情報を含むとしても、ローカルストレージ内のクレデンシャル情報が用いられる。
【０１７４】
また、パーミッション要求ファイルがＪＡＲファイル内にある時、パーミッション要求ファイルは認証されなければならない。
【０１７５】
図１１は、本発明の一実施形態による共有データ再生方法のフローチャートである。
【０１７６】
まず、本発明が提供するもう１つのセキュリティレベルは、共有データへのアクセスが許容されたアプリケーション（権限を与えられたアプリケーション）の悪意的な機能（malicious function）を排除できないと仮定する。したがって、本発明は、共有データの保護のために共有データを暗号化してユーザに提供することを特徴とする。共有データにアクセスするアプリケーションは、その共有データを解読できなければならない。
【０１７７】
共有データが暗号化されて提供される場合、アプリケーションが共有データにアクセスできたとしても、当該アプリケーションが共有データを用いて特定の機能を行えるためにはその共有データが解読されなければならない。
【０１７８】
本発明によって暗号化されて保護される共有データを再生する方法ついて、図１１を参照して以下の通り説明する。
【０１７９】
図１１を参照すると、記録媒体と関連付けられ、暗号化されている共有データが記録媒体外からローカルストレージにダウンロードされる（Ｓ１１１０）。このため、共有データをダウンロードするアプリケーションは、ネットワークを介して共有データにアクセスできるアプリケーションでなければならない。
【０１８０】
記録媒体がロードされると、記録媒体と関連した共有データがローカルストレージに存在する場合、記録媒体内に記録されたデータと共有データがバインディングオペレーションによってバインディングされ、バーチャルパッケージが生成される（Ｓ１１２０）。
【０１８１】
ここで、共有データがダウンロードされる前に既にバーチャルパッケージが存在している場合には、ダウンロードされた共有データだけでなく、バーチャルパッケージもアップデートされる。
【０１８２】
バーチャルパッケージの生成前に共有データを認証することが好ましい。共有データの認証に失敗した場合、バーチャルファイルシステムは、ロードされた記録媒体内のディスクパッケージを用いてバーチャルパッケージを生成する。この場合、不正確な共有データを含むバーチャルパッケージの生成を遮断することによって、真のコンテンツプロバイダを保護可能になる。
【０１８３】
このバーチャルパッケージを用いて、ローカルストレージ内のデータと記録媒体内に記録されたデータが共に再生される。再生を行うために、再生を行うアプリケーションが記録媒体内のデータにバインディングされた共有データにアクセスする（Ｓ１１３０）。
【０１８４】
共有データが暗号化された場合、共有データはデコーダによって再生可能な形態に復元されなければならず、暗号化された共有データは解読されなければならない。したがって、暗号化された共有データにアクセスするアプリケーションは、共有データを解読できる情報を含むことができる。この情報は、共有データにアクセスするアプリケーションが直接共有データを解読できる情報でもありうる。また、この情報は、共有データを解読できるアプリケーションを実行させることができる。
【０１８５】
共有データにアクセスするアプリケーションが、共有データを解読できる有効な情報を持つ場合、当該情報を用いて共有データが解読される（Ｓ１１４０）。共有データが解読されると、解読された共有データがデコーダに提供されてバーチャルパッケージ内の他のファイルと共に再生される（Ｓ１１５０）。
【０１８６】
なお、共有データと共にローカルストレージに存在する他のデータも記録媒体内のデータとバインディングされることによって再生されることができる。共有データと共に再生される他のデータが暗号化された場合、それらのデータは、解読完了後に再生しても良い。
【０１８７】
本発明によって共有データを暗号化すると、誤りのあるアプリケーションが共有データにアクセスしたとしても、その共有データを用いて特定の機能を行うことはできない。したがって、共有データを悪意的な機能から保護できるという長所がある。
【０１８８】
本発明には、共有データに対する様々な暗号化／解読体系が可能である。共有データを暗号化／解読するキー発生の側面においては、同一のコンテンツプロバイダによって提供された記録媒体間で共有されるデータには、コンテンツプロバイダ固有のキーが用いられることができる。
【０１８９】
共有データが暗号化された場合、前記共有データを解読できるように暗号化／解読キーまたはキーを生成するための秘密情報（secret information）がユーザに配布される必要がある。当該キーペアまたはキーを生成するための秘密情報は、記録媒体内に格納されてユーザに提供されることができる。これは、キーを持つ記録媒体がＢＤ端末にある時に限って、ローカルストレージにあるデータがアクセス可能であるという仮定の下で動作する。
【０１９０】
当該キーペアまたはキー生成のための秘密情報は、共有データを利用するアプリケーションに同封（enclose）されてユーザに提供されても良い。また、当該キーペアあるいはキー生成のための秘密情報は、場合によっては光記録再生装置内のキーストア（key store）に格納されても良い。
【０１９１】
プレーヤーは、暗号化された共有データを用いて特定の機能を行わなければならない場合、記録媒体、アプリケーション、キーストアなどから暗号化された共有データを解読を行えるキーを読み取り（キー生成のための秘密情報である場合、キー生成のための秘密情報を読み取ってキーを生成し）、当該共有データを解読する。
【０１９２】
データの暗号化体系には、対称暗号化方法（symmetric cryptographic method）および非対称暗号化方法（asymmetric cryptographic method）がある。代表的な対称暗号化方法としては、ＡＥＳ（Advanced Encryption Standard）、ＤＥＳ（Data Encryption Standard）、またはＩＤＥＡ（International Data Encryption Algorithm）などがある。一方、代表的な非対称暗号化方法としては、ＲＳＡ（Rivest-Shamir-Adelman）またはＤＳＡ（Digital Signature Algorithm）等がある。
【０１９３】
本発明による、共有データを暗号化することによって共有データを保護するセキュリティ案において、暗号化された共有データにアクセスするアプリケーションは、共有データに対するアクセス情報を含むアプリケーションでありうる。このアクセス情報は、当該アプリケーションのクレデンシャル情報でありうる。場合によっては、クレデンシャル情報のないアプリケーションも、暗号化された共有データにアクセスできるように許容されることができる。
【０１９４】
プレーヤーが暗号化された共有データにアクセスするアプリケーションの認証に失敗する場合がありうる。この場合、アプリケーションの共有データへのアクセスを許容するか否かは、プレーヤーの実装による。すなわち、認証に失敗したとしても、アプリケーションが共有データにアクセスできるようにすることができる。本発明によって、共有データが暗号化されて提供されると、認証されたアプリケーションが共有データにアクセスしようとしても、共有データは保護されることができる。
【０１９５】
また、署名されたアプリケーションは、図８及び図９の説明に関して例として取り上げられた。しかし、署名されなかったアプリケーションも同様に存在することができる。署名されなかったアプリケーションの場合、その有効性は検証できない。したがって、署名されなかったアプリケーションは、共有データへのアクセスは許容されないことが好ましい。
【０１９６】
図１２は、本発明の一実施形態による再生システムを用いた記録媒体再生装置のブロック図である。
【０１９７】
まず、“再生システム”は、光記録再生装置内に備えられるプログラム（ソフトウェア）及び／またはハードウェアで構成される集合的再生処理手段を含む。この再生システムは、光記録再生装置内にロードされた記録媒体を再生し、同時に、記録媒体に関連してローカルストレージ内に格納された（例えば、外部からダウンロードした）データを再生し、かつ管理するシステムである。
【０１９８】
特に、再生システム１７は、“キーイベントハンドラ１７１”、“モジュールマネージャ１７２”、“ナビゲータ１７３”、“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、“再生制御エンジン１７６”、“プレゼンテーションエンジン１７７”、及び“バーチャルファイルシステム４０”で構成される。これを詳細に説明すると、次の通りである。
【０１９９】
まず、ＨＤＭＶタイトル及びＢＤ−Ｊタイトルをそれぞれ再生するための、別個の再生処理管理手段として、ＨＤＭＶタイトルについての“ＨＤＭＶモジュール１７４”及びＢＤ−Ｊタイトルについての“ＢＤ−Ｊモジュール１７５”が独立的に構成される。“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”のそれぞれは、既に述べたオブジェクトファイル（ＭｏｖｉｅＯｂｊｅｃｔまたはＢＤ−Ｊ Ｏｂｊｅｃｔ）内のコマンドまたはプログラムを受信して処理するようにする制御機能を持つ。“ＨＤＭＶモジュール１７４”及び前記“ＢＤ−Ｊモジュール１７５”のそれぞれは、再生システムのハードウェア構成からコマンドあるいはアプリケーションを分離し、このコマンドあるいはアプリケーションのポータビリティ（portability）を可能にする。
【０２００】
コマンドあるいはアプリケーションなどを受信して処理する手段として、“ＨＤＭＶモジュール１７４”内には“コマンドプロセッサ１７４ａ”が備えられており、一方、“ＢＤ−Ｊモジュール１７５”内には“Ｊａｖａ ＶＭ１７５ａ”及び“アプリケーションマネージャ１７５ｂ”、“アプリケーションキャッシュ１７５ｃ”が備えられている。
【０２０１】
“Ｊａｖａ ＶＭ １７５ａ”は、アプリケーションを実行する“仮想マシン（Virtual Machine）”である。“アプリケーションマネージャ１７５ｂ”は、アプリケーションのライフサイクルを管理するアプリケーション管理機能を含む。“アプリケーションマネージャ１７５ｂ”は、アプリケーションキャッシュ１７５ｃからアプリケーションをロードできる。アプリケーションキャッシュ１７５ｃの目的は、アプリケーションがロードされる間に記録媒体からＡＶデータが切れることなく再生されるようにすることと、データをロードする際の待ち時間（latency）を減少させることである。すなわち、アプリケーションキャッシュ１７５ｃは、ＢＤ−Ｊのためのプリロード（preload）バッファである。しかし、プレーヤーは、プリロードされないクラスファイルを含む付加データを使用することも可能である。その一例には、ローカルストレージ内のＪＡＲファイルからデータをロードする場合がある。
【０２０２】
また、“モジュールマネージャ１７２”は、“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”にユーザ命令を伝達するため、および“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”の動作を制御するために提供される。また、“ＨＤＭＶモジュール１７４”または“ＢＤ−Ｊモジュール１７５”の再生命令によって、ディスク内に記録されたプレイリストファイル情報を解析し、対応する再生機能を行う“再生制御エンジン１７６”が提供される。
【０２０３】
また、“再生制御エンジン１７６”によって再生管理される特定のストリームをデコードし、画面中にデコードされたストリームを表示するための“プレゼンテーションエンジン１７７”が提供される。
【０２０４】
特に、“再生制御エンジン１７６”は、全ての再生を実際に管理する“再生制御機能１７６ａ”と、プレーヤーステータスレジスタ（ＰＳＲ）及び一般目的レジスタ（ＧＰＲ）を格納する“プレーヤーレジスタ１７６ｂ”と、を含む。場合によっては、“再生制御機能１７６ａ”が“再生制御エンジン１７６”を意味することもある。
【０２０５】
前述した本発明の再生システムにおいて、“モジュールマネージャ１７２”、“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、及び“プレイバック制御エンジン１７６”は、それぞれソフトウェア的な処理が可能である。実際に、ハードウェア構成よりはソフトウェア的処理をすることが設計においては有用である。ただし、“プレゼンテーションエンジン１７７”、デコーダ、及びプレーン（Plane）は、ハードウェア的に設計されることが一般的である。特に、ソフトウェア的に処理される構成要素（例えば、図面符号１７２、１７４、１７５、１７６）の場合は、制御装置１２の一部分として構成されても良い。したがって、本発明の構成はその意味として理解すべきであり、ハードウェア的構成かソフトウェア的構成かに限定されない。
【０２０６】
本発明による再生システム１７は、以下の特徴を有する。
【０２０７】
第１に、ＨＤＭＶタイトルについての“ＨＤＭＶモジュール１７４”およびＢＤ−Ｊタイトルについての“ＢＤ−Ｊモジュール１７５”は、独立的に構成される。したがって、これら両モジュール１７４、１７５は同時に実行されない。すなわち、ＨＤＭＶタイトル再生中にはＢＤ−Ｊタイトルを再生できなく、その逆も同様である。
【０２０８】
第２に、外部から付加データをダウンロードする動作のように光記録再生装置内のネットワーク機能を管理し、かつローカルストレージ１５内に格納されたファイルを編集することによって、またはディスクパッケージにファイルをバインディングすることによって、バーチャルパッケージを生成する動作のようにローカルストレージ１５を管理するプログラムであるアプリケーションが、再生システム１７内に備えられる。すなわち、これらのアプリケーションは、ディスク内のファイルシステム及びローカルストレージのファイルシステムを１つのシステムとして管理するバーチャルファイルシステム４０を形成し、当該形成されたバーチャルファイルシステム４０を介してオリジナルデータ及び付加データを再生するためのバーチャルパッケージを生成し、かつ管理する。
【０２０９】
第３に、ＨＤＭＶタイトル及びＢＤ−Ｊタイトルは、それぞれ別個の方式のユーザ命令を受信し、相互にそれぞれ独立してユーザ命令を行う。“キーイベントハンドラ１７１”は、ユーザ命令を受信して“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、および“モジュールマネージャ１７２／ナビゲータ１７３”のいずれか１つに伝達する。例えば、“キーイベントハンドラ１７１”は、受信した命令が“ユーザーオペレーション（ＵＯ）”によるユーザ命令であると、 “モジュールマネージャ１７２”に伝送するやり方で当該命令を実行する。一方、“キーイベントハンドラ１７１”は、受信された命令が“キーイベント”によるユーザ命令であると、 “ＢＤ−Ｊモジュール１７５”に伝送するやり方で当該命令を実行する。
【０２１０】
第４に、“再生制御エンジン１７６”の管理（これを“マスター”ともいう）は、現在動作中のモジュール１７４、１７５のいずれか１つが担当する。すなわち、ＨＤＭＶタイトル再生中には“ＨＤＭＶモジュール１７４”がマスターとなる。または、ＢＤ−Ｊタイトル再生中には“ＢＤ−Ｊモジュール１７５”がマスターとなる。
【０２１１】
“ナビゲータ１７３”は、いつでもユーザの制御の下でタイトル選択を行うことができ、ユーザに記録媒体及びタイトルメタデータを提供できる。
【０２１２】
図１３は、本発明による共有データ保護を説明する例示的な図であり、図１３ではバーチャルパッケージが具体的に示される。
【０２１３】
ロードされたディスク内には、特定のファイル構造（例えば、図２のような構造）が記録されており、これを特にディスクパッケージともいう。ローカルストレージ内にはローカルストレージファイルシステムが存在する。ロードされたディスク（例えば、ｄｉｓｃ１＿ＩＤ）にバインディングされるバインディングユニット及びバインディングユニットマニフェストファイルが該当ファイルシステム内に含まれる。
【０２１４】
また、バインディングユニットマニフェストファイルは、ネームマッピング情報を含む。ネームマッピング情報は、バインディングユニットについての情報である。例えば、バインディングユニットを生成するファイルのリストをディスクにバインディングする場合には、ネームマッピング情報は、バーチャルパッケージ内の位置、ファイル名等についての情報を含む。
【０２１５】
したがって、バーチャルファイルシステム４０は、ネームマッピング情報を用いることによって、ロードされたディスク内のディスクパッケージにバインディングユニットをバインディングするバインディングオペレーションを介して新しいバーチャルパッケージを生成する。また、バーチャルファイルシステム４０は、バーチャルパッケージに属するファイルへのアクセスメカニズムを制御する役割を果たす。
【０２１６】
バーチャルファイルシステムによって生成されたバーチャルパッケージは、ＢＤ−Ｊモード及びＨＤＭＶモードの両方に用いられる。ＢＤ−Ｊモードでは、記録媒体またはローカルストレージ上に位置したアプリケーションがバーチャルファイルシステムを介してバーチャルパッケージにアクセスできる。ＨＤＭＶモードでは、ＭｏｖｉｅＯｂｊｅｃｔがバーチャルパッケージにアクセスできる。
【０２１７】
図１３を参照すると、ディスク内の記録媒体ファイル構造（ディスクパッケージ）４２１において、ルートディレクトリの下位ディレクトリであるＢＤディレクトリ（ＢＤＭＶ）は、インデックスファイル（Ｉｎｄｅｘ．ｂｄｍｖ）、オブジェクトファイル（ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ）、プレイリストファイル（０００００．ｍｐｌｓ）、クリップ情報ファイル（０１０００．ｃｌｐｉ）、ストリームファイル（０１０００．ｍ２ｔｓ）、補助データファイル（ｓｏｕｎｄ．ｂｄｍｖ）を含む。ロードされたディスク（例えば、ｏｒｇ１＿ＩＤであり、ｄｉｓｃ２＿ＩＤであるディスク）に関連したバインディングユニット６１には、特定のプレイリストファイル６１１（Ａｐｒ２００５．ｍｐｌｓ）、当該プレイリストファイル６１１によって管理されるクリップであるクリップ情報ファイル６１２（Ａｐｒ２００５．ｃｌｐｉ）、及びストリームファイル６１３（Ａｐｒ２００５．ｍ２ｔｓ）が含まれる。
【０２１８】
また、コンテンツプロバイダが提供した共有データとして補助データファイル６１４（Ｊａｐａｎｅｓｅ．ｏｔｆ）がディスク共有（disc-dependent shared）ディレクトリ（Ｓｈａｒｅｄ）に存在する場合において、バーチャルパッケージ５１を生成する方法は、次の通りである。
【０２１９】
ネームマッピング情報によって次のようにファイル名が変更される。バインディングユニット６１内のプレイリストファイル６１１（Ａｐｒ２００５．ｍｐｌｓ）は、バーチャルパッケージ５１内のＰＬＡＹＬＩＳＴディレクトリのプレイリストファイル５１１（０００００．ｍｐｌｓ）にファイル名が変更される。同様に、クリップ情報ファイル６１２（Ａｐｒ２００５．ｃｌｐｉ）は、バーチャルパッケージ５１内のＣＬＩＰＩＮＦディレクトリのクリップ情報ファイル５１２（０２０００．ｃｌｐｉ）にファイル名が変更される。ストリームファイル６１３（Ａｐｒ２００５．ｍ２ｔｓ）は、バーチャルパッケージ５１内のストリーム（ＳＴＲＥＡＭ）ディレクトリのストリームファイル５１３（０２０００．ｍ２ｔｓ）に、補助データファイル６１４（Ｊａｐａｎｅｓｅ．ｏｔｆ）は、ＡＵＸＤＡＴＡディレクトリの補助データファイル５１４（１１１１１．ｏｔｆ）にファイル名が変更される。
【０２２０】
バーチャルパッケージ５１は、ルートディレクトリの下位ディレクトリであるＢＤＭＶディレクトリに、バーチャルパッケージによるインデックスファイル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルを含む。ＰＬＡＹＬＩＳＴディレクトリには、バインディングユニットのプレイリストファイルによって代替されたプレイリストファイル５１１（０００００．ｍｐｌｓ）がくる。ＣＬＩＰＩＮＦディレクトリでは、記録媒体のクリップ情報ファイル（０１０００．ｃｌｐｉ）にバインディングユニットのクリップ情報ファイル５１２（０２０００．ｃｌｐｉ）が追加される。ＳＴＲＥＡＭディレクトリでは、記録媒体のストリームファイル（０１０００．ｍ２ｔｓ）にバインディングユニットのストリームファイル５１３（０２０００．ｍ２ｔｓ）が追加される。ＡＵＸＤＡＴＡディレクトリでは、記録媒体の補助データファイル（ｓｏｕｎｄ．ｂｄｍｖ）にバインディングユニットの補助デートファイル５１４（１１１１１．ｏｔｆ）が追加される。
【０２２１】
なお、バーチャルパッケージ内の上位ファイルであるインデックスファイル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルは、新しく生成されるプレイリストファイル５１１（０００００．ｍｐｌｓ）に基づいて既存ディスク内のインデックステーブル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルからアップデートされることができる。特に、バーチャルパッケージ内のプレイリストファイル５１１（０００００．ｍｐｌｓ）によってタイトルが変更される場合に、インデックスファイル及びＭｏｖｉｅＯｂｊｅｃｔファイルがアップデートされる。この場合に、タイトル変更は、新しいタイトルが追加されること、既存のタイトルが変更されること、またはタイトル再生のシナリオが変更されること等を意味する。
【０２２２】
本発明が提供するセキュリティレベルのうち、共有データの認証を通じて共有データを保護するセキュリティレベルの場合には、共有データの認証に失敗すると、光記録再生装置のバーチャルファイルシステム４０は、前記共有データを含むバーチャルパッケージ５１を生成しなくて良い。ただし、記録媒体内のディスクパッケージのみを使用してバーチャルパッケージを生成することになる。この場合、プレーヤーは、ローカルストレージ内に格納された共有データである“１１１１１．ｏｔｆ”を再生できない。結果として、権限のないプロバイダの共有データが記録媒体と共に再生されるのを防止することによって、真のコンテンツプロバイダを保護することができる。
【０２２３】
また、共有データの認証に成功して共有データを含むバーチャルパッケージを生成したとしても、共有データにアクセスするアプリケーションのクレデンシャル情報が有効でない場合、アプリケーションは共有データにアクセスできない。したがって、共有データが再生されることを防ぎ、有効でないアプリケーションによる再生を防止することによって、共有データを保護できる。
【０２２４】
本発明が提供するさらに他のセキュリティレベルによれば、暗号化されたデータを解読できないアプリケーションによっては共有データを再生できない。したがって、バーチャルパッケージ内の共有データである“１１１１１．ｏｔｆ（５１４）”が暗号化されたファイルである場合、当該暗号化されたファイルを解読できるアプリケーションのみによって当該ファイルが再生される。アプリケーションが権限のない供与者によって提供された場合には、当該アプリケーションは共有データを解読できる情報を持っていないはずである。したがって、認証されなかったアプリケーションが共有データにアクセスできたとしても、共有データを解読することができず、共有データは保護される。
【０２２５】
本発明による記録媒体再生装置について図４を参照して以下のように説明する。
【０２２６】
本発明によるローカルストレージを用いた記録媒体再生装置は、記録媒体と関連した共有データがダウンロードされて格納されるローカルストレージ１５と、共有データに対する有効なアクセス情報を持つアプリケーションのみが共有データにアクセスするように制御する制御装置１２と、を備える。当該アクセス情報は、当該アプリケーションのクレデンシャル情報を含むことができ、当該クレデンシャル情報は、パーミッション要求ファイルに含まれることができる。
【０２２７】
このパーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在することができる。この場合、パーミッション要求ファイルは、認証されることが好ましい。
【０２２８】
制御装置１２は、アプリケーションが共有データにアクセスする前に共有データを認証することによって共有データを保護することができる。
【０２２９】
共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合には、その共有データは、コンテンツプロバイダの証明書を用いて認証されることができる。一方、共有データが複数のコンテンツプロバイダ間で共有されるデータである場合には、その共有データは、これらコンテンツプロバイダの証明書を用いて認証されることができる。
【０２３０】
本発明によるローカルストレージを用いた記録媒体再生装置は、記録媒体と関連した暗号化された共有データがダウンロードされて格納されるローカルストレージ１５と、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって、共有データを含むバーチャルパッケージを生成する制御装置１２と、を備える。
【０２３１】
制御装置１２は、バーチャルパッケージを用いて共有データをローカルストレージ１５内の他のデータ及び／または記録媒体内のデータと共に再生する。この時、共有データが暗号化されて提供されるため、制御装置１２は共有データを解読後に再生する。
【０２３２】
共有データを解読するに当たり、制御装置１２は、共有データに対する有効なアクセス情報を持つアプリケーションのみが共有データにアクセスするようにすることができる。アクセス情報は、共有データにアクセスするアプリケーションのクレデンシャル情報である。また、アクセス情報は、パーミッション要求ファイルに存在でき、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイルに含まれることができる。
【０２３３】
バーチャルパッケージを生成するときに、制御装置１２は、共有データを認証し、バーチャルパッケージを生成することが好ましい。この時、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合に、その共有データは、コンテンツプロバイダの証明書内の署名を用いて認証できる。一方、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合に、その共有データをこれらのコンテンツプロバイダの各証明書内の共同の署名で認証できる。
【０２３４】
共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合には、その共有データは、当該コンテンツプロバイダのみのキーを用いて暗号化されてユーザに提供される。これに対し、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合には、その共有データは、これらのコンテンツプロバイダだけに合致するキーを用いて暗号化されてユーザに提供される。
【０２３５】
暗号化された共有データは、解読された後に再生されることができる。この解読には、その共有データにアクセスするアプリケーションに含まれるキーが用いられることができる。また、記録媒体に格納されたキーを用いることも可能である。場合によっては、解読に光記録再生装置に格納されたキーが解読に用いられても良い。
【０２３６】
したがって、本発明によって、真のコンテンツプロバイダによって提供されたコンテンツ及び変質していないコンテンツのみが再生されるようにすることによって、共有データを保護することができる。
【０２３７】
本発明の要旨または範囲から離れることなく、さまざまな修正及び変形を行いうることは、当業者にとっては明らかである。したがって、本発明は、特許請求の範囲及びその均等範囲内における本発明の改良及び変更された事項も含むことは自明である。
【図面の簡単な説明】
【０２３８】
【図１】本発明の概念的理解を助ける、光記録再生装置及び周辺機器間の統合的使用の一例を説明する図である。
【図２】例えばＢＤ−ＲＯＭなどの本発明の記録媒体内に記録されるファイル構造の図である。
【図３】本発明の記録媒体に記録されるデータ記録構造の図である。
【図４】本発明の一実施形態による光記録再生装置のブロック図である。
【図５】本発明のローカルストレージ内のファイル構造の一実施形態を示す図である。
【図６】本発明の一実施形態による共有データ認証プロセスを説明する図である。
【図７】本発明によるデータ認証に用いられる証明書チェーンの図である。
【図８】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図である。
【図９】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイル内のファイルの認証プロセスのフローチャートである。
【図１０】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図である。
【図１１】本発明の一実施形態による共有データ再生方法のフローチャートである。
【図１２】本発明の一実施形態による再生システムを用いた記録媒体再生装置のブロック図である。
【図１３】バーチャルパッケージが詳細に示される、本発明による共有データ保護を説明する例示的な図である。
【技術分野】
【０００１】
本発明は記録媒体の再生に関し、特に、共有データ（shared data）を保護する方法及び装置と、ローカルストレージを用いて記録媒体からデータを再生する方法及び装置に関する。
【背景技術】
【０００２】
記録媒体として大容量のデータを記録できる光ディスクが広く使用されている。なかでも最近では高画質のビデオデータと高音質のオーディオデータを長時間記録格納することができる新しい高密度記録媒体、例えば、ブルーレイディスク(ＢＤ：Blu-ray Disc（登録商標）)が開発されている。
【０００３】
次世代記録媒体技術であるＢＤは、既存のＤＶＤを顕著に凌駕する量のデータを備える次世代光記録ソリューションである。近来、他のデジタル機器と共にＢＤを研究し、開発する多くの努力が行われている。
【０００４】
ＢＤ規格を応用した光記録再生装置が開発され始めている。しかし、未だＢＤ規格は完備しておらず、完成した光記録／再生装置を開発するのに多くの難題が生じている。
【０００５】
特に、上記のような光記録再生装置は、ＢＤに記録し、およびＢＤを再生する基本機能の他に、周辺のデジタル機器との統合的使用を考慮した付加的な機能も考慮しなければならない。すなわち、光記録再生装置は、外部入力信号を受信してこれをディスプレイするか、外部入力信号とＢＤを共に用いて再生する機能を必ず備えなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、外部入力信号及びＢＤを再生する場合において、コンテンツプロバイダによって提供された共有データを保護する好ましい方法が提案されておらず、また開発されておらず、本格的なＢＤ基盤の光記録再生装置を開発するのに多くの制約がある。
【０００７】
したがって、本発明は関連技術における制約及び不便による１又は複数の問題を除去するために、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置に関する。
【０００８】
本発明の一つの目的は、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置を提供することによって、信頼のおけるコンテンツプロバイダによって提供される共有データを保護し、権限のないアプリケーションによってその共有データが使用されるのを防止することにある。
【０００９】
本発明の他の目的は、共有データを保護する方法及び装置、並びにローカルストレージを用いて記録媒体からデータを再生する方法及び装置を提供することによって、共有データを保護することにある。
【００１０】
本発明の付加的な長所、目的、特徴は以下の詳細な説明に一部記述され、以下の実施形態によって、または本発明の実施によって一部当業者に明らかとなる。本発明の目的及び他の長所は、添付図面の他に、発明の詳細な説明及び特許請求の範囲において特に指摘される構造によって実現され、そして達成される。
【課題を解決するための手段】
【００１１】
これらの目的及び長所を達成するために、そして、本発明の目的にしたがって、本明細書において具体化され、広く説明されているように、本発明による共有データを保護する方法は、ローカルストレージに記録媒体と関連した共有データをダウンロードするステップと、共有データに対する有効なアクセス情報（接近情報）を持つアプリケーションが共有データにアクセス（接近）できるように許容する（permit）ステップと、を含む。
【００１２】
例えば、そのアクセス情報は、アプリケーションのクレデンシャル情報（Credential）である。
【００１３】
例えば、クレデンシャル情報は、パーミッション要求ファイル（permission request file）に含まれる。
【００１４】
例えば、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在する。
【００１５】
例えば、クレデンシャル情報は、供与者識別情報（Grantoridentifier）、有効期間（Expirationdate）、ファイル名（Filename）、署名（Signature）、およびＣｅｒｔｃｈａｉｎｆｉｌｅｉｄを含む。
【００１６】
例えば、アプリケーションが共有データにアクセスする前に、共有データを認証（authenticate）するステップをさらに含む。
【００１７】
例えば、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダの証明書（certificate）を用いて認証される。例えば、その証明書は、コンテンツプロバイダの署名を含む。
【００１８】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることができる。
【００１９】
例えば、その証明書は、コンテンツプロバイダ共同の署名（common signature）を含む。
【００２０】
本発明の他の態様においては、ローカルストレージを用いて記録媒体を再生する方法は、記録媒体と関連する暗号化した共有データをローカルストレージにダウンロードするステップと、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって共有データを含むバーチャルパッケージ（virtual package）を生成するステップと、バーチャルパッケージを用いて共有データを解読する（decrypt）ステップと、解読されたデータを再生するステップと、を含む。
【００２１】
例えば、共有データは、共有データにアクセスするアプリケーションの実行によって再生される。
【００２２】
例えば、アプリケーションは、共有データに対するアクセス情報としてアプリケーションのクレデンシャル情報を含む。
【００２３】
例えば、共有データは、アプリケーションに含まれたキーを用いて解読される。
【００２４】
例えば、共有データは、記録媒体内に格納されたキーを用いて解読される。
【００２５】
例えば、共有データは、光ディスクプレーヤー内に格納されたキーを用いて解読される。
【００２６】
例えば、バーチャルパッケージを生成するときに、共有データは、バーチャルパッケージを生成するために、認証される。
【００２７】
例えば、共有データが、１つのコンテンツプロバイダによって提供される記録媒体間で共有される場合、その共有データは、コンテンツプロバイダの１つの証明書内の１つの署名を用いて認証される。
【００２８】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの１つの証明書中の１つの共同の署名によって認証される。
【００２９】
例えば、共有データが、１つのコンテンツプロバイダによって提供される記録媒体間で共有される場合、その共有データは、コンテンツプロバイダのキーを用いて認証される。
【００３０】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダに合致する１つのキーを用いて認証される。
【００３１】
本発明のさらに他の態様においては、共有データを保護する装置は、記録媒体と関連したダウンロードされた共有データを格納するローカルストレージと、その共有データに対する有効なアクセス情報を持つアプリケーションがその共有データにアクセスするように制御する制御装置と、を含む。
【００３２】
例えば、アクセス情報は、アプリケーションのクレデンシャル情報である。
【００３３】
また、クレデンシャル情報は、パーミッション要求ファイルに含まれることが好ましい。
【００３４】
また、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在することが好ましい。
【００３５】
また、制御装置は、アプリケーションが共有データにアクセスする前に、その共有データを認証することが好ましい。
【００３６】
また、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダの証明書を用いて認証されることが好ましい。
【００３７】
また、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダの１つの証明書を用いて認証されることが好ましい。
【００３８】
また、本発明のさらに別の態様においては、ローカルストレージを用いて記録媒体を再生する装置は、記録媒体と関連したダウンロードされた暗号化された共有データを格納するローカルストレージと、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって、共有データを含むバーチャルパッケージを生成し、そのバーチャルパッケージを用いて共有データを解読して再生する制御装置と、を含む。
【００３９】
共有データを解読するときに、制御装置は、共有データに対する有効なアクセス情報を有するアプリケーションが共有データにアクセスするように制御することが好ましい。
【００４０】
また、アクセス情報は、共有データにアクセスするアプリケーションのクレデンシャル情報であることが好ましい。
【００４１】
また、バーチャルパッケージを生成するときに、制御装置は、共有データを認証してバーチャルパッケージを生成することが好ましい。
【００４２】
また、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、制御装置は、共有データをコンテンツプロバイダの１つの証明書を用いて認証することが好ましい。
【００４３】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、制御装置は、複数のコンテンツプロバイダの証明書中の１つの共同の署名を用いて共有データを認証する。
【００４４】
例えば、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、その共有データは、コンテンツプロバイダのキーを使用して暗号化される。
【００４５】
例えば、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、その共有データは、複数のコンテンツプロバイダに合致するキーを使用して暗号化される。
【００４６】
例えば、共有データを解読するときに、制御装置は、共有データにアクセスするアプリケーションに含まれたキーを用いて共有データを解読する。
【００４７】
例えば、共有データを解読するときに、制御装置は、記録媒体内に格納されたキーを使用して共有データを解読する。
【００４８】
例えば、共有データを解読するときに、制御装置は、光記録再生装置に格納されたキーを使用して共有データを解読する。
【００４９】
したがって、本発明によれば、アプリケーションの悪意的な機能（malicious function）から再生システムを保護することが可能であり、さらには安全なコンテンツの提供が可能になる。したがって、本発明は、より便利な機能をユーザに提供する。
【００５０】
上述の一般的な説明及び後述する本発明の詳細な説明は、例示的かつ説明目的のためのものであり、特許請求の範囲として本発明のさらなる説明を提供することが意図される。
【発明の効果】
【００５１】
本発明は、次のような効果及び／または長所を提供する。
【００５２】
第一に、共有データを認証することによって、認証されたコンテンツプロバイダによって提供されたコンテンツ及び変質していないコンテンツのみを再生することができ、それによって、共有データを保護することができる。
【００５３】
第二に、また、アプリケーションに共有データに対するアクセス情報を提供することによって、権限のないアプリケーションによる悪意的な機能から共有データを保護することができる。
【００５４】
第三に、共有データを暗号化することによって、共有データが権限のないアプリケーションによって使用されることを防止できる。
【発明を実施するための最良の形態】
【００５５】
以下、本発明のさらなる理解を提供するために含まれ、本願の一部に組み込まれ、そして構成する添付図面は、本発明の実施形態及び本発明の原理を説明するのに役に立つ記述を用いて説明する。参照番号は、本発明の好ましい実施形態や添付図面に説明されている実施例に対して詳細に付される。同一または類似な構成要素については、可能なかぎり同一の参照符号を図面全体を通して使用する。
【００５６】
説明の便宜上、本発明は、記録媒体の一例として光ディスク、特に“ブルーレイディスク（ＢＤ）”をとりあげる。しかしながら、本発明の技術思想は、他の記録媒体にも同一に適用可能であることは自明である。
【００５７】
本発明において“ローカルストレージ（local storage）”とは、図１に示す光記録再生装置内に備えられた一種の格納手段であり、利用される必要な情報及びデータをユーザが任意に格納することができる構成要素を意味する。すなわち、現在一般的に使われるローカルストレージは、“ハードディスク”、“システムメモリ”、“フラッシュメモリ”などを含むが、本発明は必ずしもこれに限定されることはない。
【００５８】
特に、“ローカルストレージ”は、記録媒体（例えば、ブルーレイディスク）と関連したデータを格納する手段として用いられる。ローカルストレージ内に格納される記録媒体と関連したデータは、外部からダウンロードしたデータを含むことが一般的である。
【００５９】
また、記録媒体から直接読み取られた許容されたデータ（permitted data）、または記録媒体の記録再生操作と関連した生成されたシステムデータ（例えば、メタデータ等）は、ローカルストレージ内に格納されることができることは自明である。
【００６０】
本発明の説明の便宜上、記録媒体内に記録されたデータを“オリジナルデータ（original data）”と命名し、一方、ローカルストレージ内に格納されたデータのうち、記録媒体と関連したデータを“付加データ（additional data）”と命名する。
【００６１】
本発明において、“タイトル（Ｔｉｔｌｅ）”とは、ユーザとのインターフェースを構成する再生単位（reproduction unit）である。それぞれのタイトルは、特定のオブジェクトとリンクしている。ディスク内に記録された該当タイトルに関連したストリームは、オブジェクトファイル内のコマンドあるいはプログラムによって再生される。特に、本発明では、説明の便宜上、ディスク内に記録されたタイトルのうち、ＭＰＥＧ２圧縮方式による動画、映画及びインタラクティブ情報を有するタイトルを、“ＨＤＭＶタイトル”と命名する。また、ディスク内に記録されたタイトルのうち、Ｊａｖａプログラムによって実行される動画、映画及びインタラクティブ情報を有するタイトルを、“ＢＤ−Ｊタイトル”と命名する。
【００６２】
本発明において、タイトルは、インデックステーブルに存在するインデックス項目（indexing item）を意味する。すなわち、記録媒体がロードされると初期に再生される画面情報を有する“ファーストプレイバック（First Playback）”およびメニュー画面を提供する“トップメニュー（Top Menu）”は、タイトルの一種である。すなわち、ユーザとインターフェースを構成する再生単位は、その名称にかかわらず本発明のタイトルに該当する。
【００６３】
また、タイトルは、記録媒体内のデータ及び／またはローカルストレージ内のデータで構成されることを特徴とする。ローカルストレージ内のデータは、タイトルの再生中にダウンロードされるデータを含むことができる。
【００６４】
図１は、本発明の概念的理解を助けるために、光記録再生装置１０及び周辺機器間の統合的使用を説明する例示的な図である。
【００６５】
図１を参照すると、本発明の“光記録再生装置１０”は、様々な規格による光ディスクの記録または再生を可能にする装置である。そして、本発明の“光記録再生装置１０”は、特定の規格の光ディスク（例えば、ＢＤ）を記録／再生するように設計することができる。また、本発明の“光記録再生装置１０”は、光ディスクを再生だけするように作成しても良い。本発明の以下の説明では、ブルーレイディスク（ＢＤ）と周辺機器とのインタラクティブ性を考慮して、ＢＤプレーヤー（BD-Player）またはＢＤレコーダ（BD-Recorder）を一例としてとりあげる。また、本発明の“光記録再生装置１０”が、コンピュータなどにロード可能な“ドライブ”を含むことは自明である。
【００６６】
本発明の光記録再生装置１０は、光ディスク３０を記録再生する機能の他にも、外部入力信号を受信し、受信した信号を信号処理して、他の外部ディスプレイ２０を介してユーザに該当画面を伝達する機能を持つ。この場合、外部入力信号に特に制限はない。デジタルマルチメディア放送（ＤＭＢ：Digital multimedia broadcast）またはインターネットなどは、代表的な外部入力信号である。特に、容易にアクセス可能な媒体であるインターネットの場合、インターネット上の特定のデータは、光記録再生装置１０を介してダウンロードされて活用される。
【００６７】
また、外部ソースとしてコンテンツを提供する者をまとめて“コンテンツプロバイダ（ＣＰ）”と総称する。
【００６８】
また、本発明において、コンテンツとは、タイトルを構成する内容であって、記録媒体の製作者によって提供されるデータのことを意味する。
【００６９】
特に、本発明の目的は、“コンテンツプロバイダ”によって提供されるコンテンツを保護し、ユーザの再生システムを保護することにある。
【００７０】
オリジナルデータ及び付加データは、以下のように説明される。
【００７１】
例えば、特定のタイトルについての多重化されたＡＶストリームが光ディスク内に記録されたオリジナルデータとして記録され、かつオリジナルデータのオーディオストリーム（例えば、韓国語）とは異なるオーディオストリーム（例えば、英語）がインターネット上の付加データとして提供される場合、インターネット上の付加データであるオーディオストリーム（例えば、英語）をダウンロードしてオリジナルデータのＡＶストリームと共に再生しようとする要求、または、インターネット上の付加データであるオーディオストリーム（例えば、英語）をダウンロードしてそれだけを再生しようとする要求がユーザによっては存在する。このような要求を可能にするために、オリジナルデータ及び付加データ間の関連性（association）を規定する必要があり、これらのデータをユーザの要求に応じて管理／再生する体系化した方法が必要となる。
【００７２】
上記で説明の便宜上、ディスク内に記録された信号をオリジナルデータとし、ディスク外部に存在する信号を付加データと命名したが、これは単にそれぞれのデータを取得する方法によって区分したものであり、オリジナルデータまたは付加データは特定のデータに限定されることはない。
【００７３】
したがって、一般的な付加データには、オーディオ、プレゼンテーショングラフィック（ＰＧ：Presentation Graphic）、インタラクティブグラフィック（ＩＧ：Interactive Graphic）、テキストサブタイトル（Text subTitle）等が含まれるが、これらに限定されない。付加データは、列挙したデータ及びビデオを全て含む多重化されたＡＶストリームに相当する場合もある。すなわち、光ディスク外部に存在し、かつオリジナルデータと関連するいかなる種類の属性のデータも付加データになりうる。
【００７４】
また、付加データを、インデックスファイル（ｉｎｄｅｘ）、プレイリストファイル（＊．ｍ２ｔｓ）、またはクリップ情報ファイル（＊．ｃｌｐｉ）ごとに別個にダウンロードすることができる。また、付加データを、コンテンツ単位またはタイトル単位にダウンロードすることができる。
【００７５】
ユーザの要求を実現するためには、オリジナルデータ及び付加データ間のファイル構造を提供することが必要である。以下、図２及び図３を参照して、ブルーレイディスク（ＢＤ）用に使用可能なファイル構造及びデータ記録構造について詳細に説明する。
【００７６】
図２は、本発明による記録媒体（例えば、ＢＤ−ＲＯＭ）内に記録されるファイル構造の一実施例を示す図である。
【００７７】
図２を参照すると、本発明の再生管理ファイル構造には、１つのルートディレクトリの下に少なくとも１つのＢＤＭＶディレクトリが存在する。ＢＤＭＶディレクトリ内には、ユーザとの双方向性（interactivity）を保証する一般ファイル（上位ファイル）として、インデックスファイル（“ｉｎｄｅｘ．ｂｄｍｖ”）及びオブジェクトファイル（“ＭｏｖｉｅＯｂｊｅｔ．ｂｄｍｖ”）が存在する。
【００７８】
ＢＤＭＶディレクトリは、実際にディスク内に記録されたデータに関する情報とその記録されたデータを再生することに関する情報を持つディレクトリであり、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤ−Ｊオブジェクトファイルを含むＢＤＪＯディレクトリ、ＪＡＲファイルを含むＪＡＲディレクトリを含む。また、ＢＤＭＶディレクトリは、ディスク再生に関連した補助データを含むＡＵＸＤＡＴＡディレクトリも含む。以下、ディレクトリ及び各ディレクトリ内に含まれるファイルについて詳細に説明する。
【００７９】
ＳＴＲＥＡＭディレクトリには、ディスク内に特定フォーマットで記録されたＡＶストリームファイルが存在し、例えば、ストリームファイル（０１０００．ｍ２ｔｓ、…）の拡張子名として“＊．ｍ２ｔｓ”が使用される。すなわち、動映像データは、一般的に、ストリームファイル内に本発明と関連したコンテンツとして記録される。
【００８０】
ＣＬＩＰＩＮＦディレクトリは、それぞれのストリームファイルと対応するクリップ情報ファイル（０１０００．ｃｌｐｉ、…）を含む。特に、クリップ情報ファイル（＊．ｃｌｐｉ）は、対応するストリームファイルの属性情報及びタイミング情報を含む。特に、ストリームファイル（＊．ｍ２ｔｓ）と一対一対応するクリップ情報ファイル（＊．ｃｌｐｉ）をまとめて“クリップ（ｃｌｉｐ）”と命名できる。すなわち、このことは、対応する１つのストリームファイル（＊．ｍ２ｔｓ）には、１つのクリップ情報ファイル（＊．ｃｌｐｉ）が必ず存在する、ということを意味する。
【００８１】
ＰＬＡＹＬＩＳＴディレクトリは、プレイリストファイル（０００００．ｍｐｌｓ、…）を含む。それぞれのプレイリストファイル（＊．ｍｐｌｓ）は、特定のクリップの再生時間を指定する少なくとも１つのプレイアイテム（ＰｌａｙＩｔｅｍ）を含む。プレイアイテムは、再生される特定のクリップ、すなわち、プレイアイテム内でクリップ名（ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｆｉｌｅ＿ｎａｍｅ）として指定されるクリップの再生開始時間（ＩＮ−Ｔｉｍｅ）及び再生終了時間（ＯＵＴ−Ｔｉｍｅ）に関する情報を有する。
【００８２】
すなわち、プレイリストファイル（＊．ｍｐｌｓ）は、少なくとも１つまたは複数のプレイアイテムの組み合わせによって特定のクリップの再生を実行する、全体再生管理ファイル構造内の基本的再生管理ファイル単位となる。
【００８３】
特に、プレイリストファイル（＊．ｍｐｌｓ）は、オブジェクトファイル内の特定のオブジェクトファイルによるコマンドによって操作されうる。したがって、ディスク再生シナリオの観点では、オブジェクトファイルは、動的なシナリオ（Dynamic scenario）を実行し、または管理し、そして、プレイリストファイル（＊．ｍｐｌｓ）は、静的なシナリオ（Static scenario）を実行し、または管理する。
【００８４】
ＢＤＪＯディレクトリは、ＢＤ−Ｊタイトルを再生するためのＢＤ−Ｊオブジェクトファイルを含む。
【００８５】
ＪＡＲディレクトリは、ＢＤ−Ｊについての全ての“ｘｘｘｘｘ．ｊａｒ”を含む。ＪＡＲ（Java archive）ファイルは、複数のファイルのまとまりを配布する際に使われる圧縮ファイルである。ＪＡＲファイルは、通常、特定のｊａｖａプログラムと関連したｊａｖａクラスファイル、補助リソース（auxiliary resource）、及びメタデータなどで構成される。様々なアプリケーションをＪＡＲファイルによって構成することができる。
【００８６】
ＡＵＸＤＡＴＡディレクトリは、ディスク再生と関連した補助的な情報を含むファイルを含む。例えば、ＡＵＸＤＡＴＡディレクトリは、再生時にクリックサウンド情報及びメニューサウンド情報などを提供するサウンドファイル（“Ｓｏｕｎｄ．ｂｄｍｖ”）と、テキストサブタイトルの再生時にフォント情報を提供するフォントファイル（“１１１１１．ｏｔｆ”）とを含むことができる。
【００８７】
ＭＥＴＡディレクトリは、メタデータを備える。メタデータは、データに対するデータである。例えば、メタデータは、サーチファイル及びディスクライブラリファイルなどを含む。
【００８８】
上述したファイル及びディレクトリの位置は、一つの例に過ぎない。必要に応じてその位置が変更されることは自明である。例えば、ＢＤＪＯディレクトリ及びＪＡＲディレクトリをサブディレクトリとして、ルートディレクトリの下に別個に構成することも可能である。もう一つの例として、ＪＡＲディレクトリを上位ディレクトリとしてルートディレクトリの下に構成しても良い。
【００８９】
また、ルートディレクトリは、記録媒体内に記録されたデータの保護に関する情報、またはローカルストレージにダウンロードされるデータの保護に関する情報を有するディレクトリを含むことができる。このことは、図２に示す実施形態では、ＣＥＲＴＩＦＩＣＡＴＥディレクトリとして表される。アプリケーション認証及びバインディングユニット認証のためのルート証明書ファイルが、ＣＥＲＴＩＦＩＣＡＴＥディレクトリ内に位置している。
【００９０】
図３は、本発明による記録媒体に記録されるデータ記録構造を示す図であり、前述したファイル構造に関連した情報がディスク内に記録されるフォーマットを示している。
【００９１】
図３を参照すると、ディスクの内周から順に、ファイル全体を管理するシステム情報であるファイルシステム情報領域と、記録されたストリーム（＊．ｍ２ｔｓ）を再生するための、インデックスファイル、オブジェクトファイル、プレイリストファイル、クリップ情報ファイル及びメタデータファイルが記録された領域（“データベース領域”）と、及びオーディオ／ビデオ／グラフィックなどで構成されたストリームまたはＪＡＲファイルが記録されるストリーム領域またはデータ領域（“ＡＶストリーム領域”）と、が存在する。
【００９２】
また、データ領域内のコンテンツを再生するためのファイル情報などを記録する領域を管理領域と名付ける。ファイルシステム情報領域およびデータベース領域は、管理領域に該当する。ただし、図３に示した各領域は、一例として提示されている。本発明が図３に示す各領域の配列構造に限定されないということは自明である。
【００９３】
図４は、本発明の一実施形態による光記録再生装置１０のブロック図である。
【００９４】
図４を参照すると、本発明の一実施形態による光記録再生装置は、光ディスクに記録されたオリジナルデータ及び再生管理ファイル情報を含む管理情報を再生するピックアップ１１と、ピックアップ１１の動作を制御するサーボ１４と、ピックアップ１１から受信した再生信号を特定の信号値に復元し、記録される信号を光ディスクに記録される信号に変調し、その変調された信号を伝達する信号処理部１３と、上記動作を制御するマイクロプロセッサ１６と、を備える。
【００９５】
光ディスク外に存在する付加データは、制御装置１２によってローカルストレージ１５にダウンロードされる。制御装置１２は、ローカルストレージ１５内のバインディングユニットマニフェストファイル（Binding Unit Manifest File）に記録された情報を用いてバインディングユニット（binding unit）を生成する。また、制御装置１２は、記録媒体のデータ及びローカルストレージ１５内のデータを再生するために、ローカルストレージ１５内のバインディングユニットマニフェストファイルに記録されたネームマッピング情報を用いてバーチャルパッケージを生成する。制御装置１２は、生成されたバーチャルパッケージを用いてオリジナルデータ及び／または付加データをユーザの要求に応じて再生する。
【００９６】
また、バーチャルパッケージは、バーチャルファイルシステム（virtual file system）によって行われるバインディングオペレーションを介して生成され、ディスク内の相異なる領域に格納されているオリジナルデータで構成されたオリジナルクリップ（original clip）およびローカルストレージ１５内の付加データで構成された付加クリップ（additional clip）を再生管理する１つのファイル構造となる。
【００９７】
バインディングユニットマニフェストファイルは、バーチャルパッケージを生成するバインディングオペレーションに使用される情報を含む。バインディングユニットマニフェストファイルがないと、ローカルストレージ１５内のデータを記録媒体内のファイル構造（ディスクパッケージ）とバインディングしてバーチャルパッケージを生成することができない。
【００９８】
ネームマッピング情報は、バインディングユニットマニフェストファイルに記録されている情報であり、記録媒体内に記録されたデータがバーチャルパッケージにおいてどの位置に存在しているかを示す情報である。
【００９９】
新しく生成されたバーチャルパッケージを後々の再利用のためにローカルストレージ１５に格納し、または、別のダイナミックメモリを用いて一時的に格納することができる。
【０１００】
本発明において、制御装置１２は、アプリケーション及びコンテンツが真のコンテンツプロバイダ（ＣＰ）によって提供されたか否かを認証し、アプリケーションのコンテンツへのアクセスを制御する。アプリケーションの認証については、図５の記述において詳細に説明する。
【０１０１】
また、再生システム１７は、制御装置１２の制御のもと、出力データを最終的にデコードしてユーザに提供する。再生システム１７は、ＡＶ信号をデコードするデコーダと、前述した特定のタイトルの再生と関連したオブジェクトコマンドあるいはアプリケーション、および制御装置１２を介して入力されるユーザコマンドを解析することによって再生方向を決定するプレーヤーモデルと、を含む。再生システム１７については、図１２の記述でさらに詳細に説明する。
【０１０２】
光ディスクに信号を記録する機能を果たすために、ＡＶエンコーダ１８は、制御装置１２の制御によって入力信号を特定のフォーマットの信号、例えば、ＭＰＥＧ−２トランスポートストリームに変換し、その変換された信号を信号処理部１３に提供する。
【０１０３】
図５は、本発明によるローカルストレージ１５内のファイル構造の一実施形態を示す図である。
【０１０４】
図５を参照すると、ローカルストレージには、記録媒体から読み取られたデータまたは記録媒体の外部ソースからダウンロードされたデータを格納することができる。データを格納する領域は、大きく、アプリケーションデータを格納する際に使用される“アプリケーションデータ領域６２０”とバーチャルパッケージの生成に用いられる“バインディングユニットデータ領域６１０”とに区分されることができる。
【０１０５】
図５の一実施形態において、ローカルストレージ１５内の“バインディングユニットデータ領域６１０”には、プロバイダ（organization-dependent）ディレクトリが３個（ｏｒｇ１＿ＩＤ、ｏｒｇ２＿ＩＤ、ｏｒｇ３＿ＩＤ）存在する。これらは、それぞれのコンテンツプロバイダ（ＣＰ）を意味する。例えば、映画の場合には、映画会社または映画配給会社がその組織（organization）に該当する。
【０１０６】
また、プロバイダ共有（organization-dependent shared）ディレクトリも存在することができる。コンテンツプロバイダ間で共有されるデータは、その共有ディレクトリ６１０ａに存在する。
【０１０７】
プロバイダディレクトリである“ｏｒｇ１＿ＩＤ”は、下位ディレクトリとしてディスク（disc-dependent）ディレクトリの“ｄｉｓｃ１＿ＩＤ”、“ｄｉｓｃ２＿ＩＤ”及びディスク共有（disc-dependent shared）ディレクトリ６１０ｂを含む。ディスク共有ディレクトリ６１０ｂには、“ｏｒｇ１＿ＩＤ”が提供した“ｄｉｓｃ１＿ＩＤ”と“ｄｉｓｃ２＿ＩＤ”記録媒体間で共有されるデータが存在する。
【０１０８】
“ｄｉｓｃ１＿ＩＤ”には、“ｏｒｇ１”が提供する“ｄｉｓｃ１”とバインディングされるバインディングユニット（binding unit）が存在する。バインディングユニットには、プレイリストファイルの“Ａｐｒ２００５．ｍｐｌｓ（６１１）”とクリップ情報ファイルの“Ａｐｒ２００５．ｃｌｐｉ（６１２）”と、ストリームファイルの“Ａｐｒ２００５．ｍ２ｔｓ（６１３）”と、が存在する。これらのファイルと記録媒体内のデータとがバインディングすることによってバーチャルパッケージを生成する方法が、図１３を参照して後で説明される。
【０１０９】
“アプリケーションデータ領域６２０”には、供給者（organization-dependent）ディレクトリが３個（ｏｒｇ１＿ＩＤ、ｏｒｇ２＿ＩＤ、ｏｒｇ３＿ＩＤ）存在する。“ｏｒｇ１＿ＩＤ”の下位ディレクトリとして“ｄｉｓｃ１＿ＩＤ” ディレクトリ及び“ｄｉｓｃ２＿ＩＤ”ディレクトリが存在する。“ｄｉｓｃ１＿ＩＤ”ディレクトリは、特定のアプリケーションをそれぞれ構成するＪＡＲファイルである“Ａｐｐ０．ｊａｒ（６２１）”及び“Ａｐｐ１．ｊａｒ（６２２）”を含む。 “ｄｉｓｃ２＿ＩＤ”ディレクトリは、ＪＡＲファイルである“Ａｐｐ０．ｊａｒ（６２３）”を含む。
【０１１０】
また、アプリケーションは、特定の機能を行うプログラムを意味する。その機能を行うために、アプリケーションは、全てのデータ、ファイル、及び再生システム１７のハードウェア構成またはソフトウェア構成などにアクセス可能になっていなければならない。例えば、“ｄｉｓｃ１＿ＩＤ”ディレクトリの“Ａｐｐ０．ｊａｒ（６２１）”によって構成されるアプリケーション（以下、“Ａｐｐ０”という）が特定の機能を行い、その機能を行うために“ｏｒｇ１＿ＩＤ”であるコンテンツプロバイダが提供した記録媒体間で共有されるデータ“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”のデータが必要な場合には、“Ａｐｐ０”は、“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”にアクセスする。
【０１１１】
本発明は、同一のコンテンツプロバイダ（ＣＰ）が提供した記録媒体間で共有されるデータ（例えば、ディスク共有ディレクトリ６１０ｂに存在するデータである、図５の“ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”）、または、コンテンツプロバイダ（ＣＰ）間で共有されるデータ（例えば、共有ディレクトリ６１０ａに存在するデータ）を保護するためのセキュリティ案を提供しようとする。
【０１１２】
このような共有データを保護するための３つのセキュリティ案のレベルが考慮されることができる。
【０１１３】
まず、第１のレベルは、全てのアプリケーションに全ての共有データへのアクセスを許容する場合である。この場合にはいかなるセキュリティメカニズムも要求されないので、本発明では第１のレベルは述べない。
【０１１４】
したがって、本発明が提供しようとするセキュリティ案のレベルは、第２のレベルと第３のレベルとなる。なかでも２番目は、共有データに対する認証が共有データを保護するのに充分であると仮定する。これは、共有データを用いるアプリケーションが共有データへのアクセスがそれぞれ許容される場合には、アプリケーションの動作が信頼できることを前提とする。
【０１１５】
第３のレベルは、共有データへのアクセスが許容されたアプリケーションの悪意的な機能を排除できないとの仮定の下に、共有データを暗号化してユーザに提供することによって、共有データを保護するやり方である。したがって、共有データにアクセスするアプリケーションは、共有データを解読できなければならない。
【０１１６】
以下、図６乃至図１０に基づき、本発明が提供する第２のセキュリティレベルについて説明する。また、図１１では、第３のセキュリティレベルおよびこの第３のセキュリティレベルが適用された場合の共有データの再生について説明する。
【０１１７】
図６乃至図９は、本発明による共有データ保護のための共有データ及びアプリケーションの認証について示す。図１０は、共有データにアクセスするアプリケーションのためにアクセス情報を提供することによって共有データを保護する方法を示す。
【０１１８】
図６は、本発明の一実施形態による共有データ認証を示す図である。
【０１１９】
図６を参照すると、コンテンツプロバイダ（ＣＰ）は、データを提供する際に、そのデータに対する証明書をユーザに提供する。その証明書は、記録媒体内に記録された形態でユーザに提供されても良く、記録媒体外からダウンロードされてユーザに提供されても良い。
【０１２０】
この証明書は、バージョン、シリアル番号、署名アルゴリズム（signature algorithm）、発行人（issuer）、有効期間、認証対象、公開鍵（public key）などを含むことができる。
【０１２１】
ここで、公開鍵とは、公開鍵暗号体系で用いられる１つのエンティティの非対称キーペア（key pair）の、公開されているキーを意味する。その公開鍵は、署名システムで署名の真偽を判断するのに用いられ、検証キー（verification key）ともいう。一方、秘密鍵（private key）とは、公開鍵暗号体系で用いられる１つのエンティティの非対称キーペアの中で公開されないキーのことをいう。ある場合には、秘密鍵は、対称キー暗号体系で用いられるキーを意味する。
【０１２２】
証明書は、ユーザに提供されるデータが適法なコンテンツプロバイダによって提供されたことを証明するために用いられる。また、その証明書は、証明書を発行した証明書権威者（ＣＡ：certificate authority）のデジタル署名を含む。図６の実施形態では、例えば、コンテンツプロバイダが自分自身で証明をする。したがって、証明書権威者（ＣＡ）は、コンテンツプロバイダ（ＣＰ）自身となる。証明書の証明については、図７で詳細に説明する。
【０１２３】
コンテンツプロバイダ（ＣＰ）は、ＳＨＡ−１（Secure Hash Algorithm-1）及びＭＤ５（Message Digest algorithm 5）などのダイジェストアルゴリズム６０１０を用いて、コンテンツダイジェスト６０１１を生成してユーザに提供する。
【０１２４】
ここで、コンテンツダイジェストとは、それぞれのコンテンツごとに固有に算出されるように作られた簡単な文字列のことを意味する。そのコンテンツダイジェストは、任意の長さのコンテンツに無方向のハッシュ関数を反復適用することによって、簡潔にされた一定の長さのビット列として表現される。各コンテンツ（メッセージ、文章、ファイルなど）ごとに１つのコンテンツダイジェストが算出される。そして、異なる文書から同一のコンテンツダイジェストを算出することはできない。この結果、コンテンツダイジェストは、原文の偽造有無を確認する手段として使用することができる。
【０１２５】
生成されたコンテンツダイジェスト６０１１は、コンテンツプロバイダの秘密鍵６０１３を用いて署名アルゴリズム６０１２を介してデジタル署名になる。コンテンツプロバイダは、デジタル署名を含む証明書をコンテンツと共にユーザに提供する。
【０１２６】
ここで、署名アルゴリズムとは、ＲＳＡ（Rivest-Shamir-Adelman）、ＤＳＡ（digital signature algorithm）などの暗号化アルゴリズムの一種である。
【０１２７】
デジタル署名は、上記デジタル署名に用いられた秘密鍵６０１３に対応する公開鍵６０１７を用いて署名アルゴリズム６０１６を介してコンテンツダイジェスト６０１８に復元されることができる。公開鍵６０１７は、証明書中に含まれてユーザに提供される。デジタル署名の生成に用いられた秘密鍵６０１３に対応する公開鍵６０１７が存在しない場合、デジタル署名をコンテンツダイジェスト６０１８に復元することができない。この場合には、提供されたアプリケーションが適法なコンテンツプロバイダによって提供されたものと認証されない。
【０１２８】
また、公開鍵６０１７の存在により、デジタル署名をコンテンツダイジェスト６０１８に復元したとしても、提供されたコンテンツが変質した場合には認証に失敗する。
【０１２９】
すなわち、コンテンツプロバイダによって提供されたコンテンツは、ダイジェストアルゴリズム６０１４を介してコンテンツダイジェスト６０１５として算出される。算出されたコンテンツダイジェスト６０１５は、デジタル署名を用いて復元されたコンテンツダイジェスト６０１８と比較される（６０１９）。コンテンツが変質した場合、復元されたコンテンツダイジェスト６０１８は、提供されたコンテンツから算出されたコンテンツダイジェスト６０１５とは異なる。このため、コンテンツの認証は失敗する。
【０１３０】
共有データの認証に失敗する場合には、その共有データの再生が制限されることが好ましい。すなわち、本発明において、共有データは、再生される記録媒体の外部からローカルストレージにダウンロードされても良い。記録媒体がロードされ、かつ共有データがロードされた記録媒体と関連する場合には、その共有データは、記録媒体内のディスクパッケージにバインディングされる。このバインディングオペレーションは、上述した再生システム１７のバーチャルファイルシステムによって行われる。もし、共有データの認証に失敗する場合には、バーチャルファイルシステムは、共有データをディスクパッケージにバインディングしなくても良い。これにより、ダウンロード中に損傷した、またはハッキングなどによって変質した共有データが記録媒体と共に再生されることを防ぐことができる。また、権限のないコンテンツプロバイダによって提供された共有データが再生されることを防止できる。したがって、記録媒体のコンテンツプロバイダ及び共有データのプロバイダを保護することが可能になる。
【０１３１】
図７は、本発明によるデータ認証に用いられる証明書チェーン（certificate chain）を示す図である。
【０１３２】
複数個の証明書が階層的連結構造を形成しながらコンデンツに含まれることができる。ここで、１つの証明書はその以前の証明書の真偽を証明する。証明書の階層構造の最上位は、ルートＣＡであるが、このルートＣＡは、他のＣＡからの証明書がなくても信頼される。証明書は、記録媒体やＢＤ端末内に位置するキーデータベース（key database）に格納される。
【０１３３】
具体的に説明すると、信頼されたルート証明書権威者（ＣＡ）が証明書権威者７０２、７０３、７０４を認証できる。認証される証明書権威者は、ＡＡＣＳ（Advanced Access Content System）、またはＣＰＳ（Content Protection System）でありうる。場合によっては、ＡＡＣＳやＣＰＳ自身がルート証明書権威者にもなりうる。
【０１３４】
ＡＡＣＳ、ＣＰＳ、または他の証明書権威者は、光記録再生装置、コンテンツプロバイダ等（７０２ａ、７０２ｂ、７０２ｃ、７０２ｄ）などの下位構造を独立的に認証できる。このような構造を証明書チェーンという。
【０１３５】
このような証明書チェーンにおいては、信頼された証明書権威者（ＣＡ）を認証できる上位の証明書権威者は存在しない。この場合、信頼された証明書権威者は、自分自身（７０１）を認証するが、これはルート認証（root certification）に該当する。
【０１３６】
それぞれの証明書権威者は、自分自身またはその下位構造の認証の結果に対して、それぞれの証明書権威者のデジタル署名を含む証明書を提供する。証明書チェーンの最下位の証明書権威者が提供する証明書をリーフ証明書（leaf certificate）といい、証明書チェーンの最上位の証明書権威者が提供する証明書をルート証明書という。これらの証明書はデジタル署名の検証過程でデジタル署名を復元する公開鍵のインテグリティを保証することができる。
【０１３７】
なお、信頼された証明書権威者が提供する信頼されたルート証明書は、記録媒体の特定の領域にファイルの形態などで格納されてユーザに提供される、または、記録媒体の外部からダウンロードされて光記録再生装置のキーストア（key store）に格納されることもできる。
【０１３８】
本発明は、共有データの認証を通じて共有データを保護することを意図する。したがって、共有データが、同一のコンテンツプロバイダ、例えば、コンテンツプロバイダ１（ＣＰ１）が提供した記録媒体間で共有される場合には、コンテンツプロバイダ１の証明書７０２ｂが共有データの認証に用いられる。
【０１３９】
また、共有データが複数のコンテンツプロバイダ、例えば、コンテンツプロバイダ１（ＣＰ１）及びコンテンツプロバイダ２（ＣＰ２）によって提供される記録媒体間で共有される場合には、コンテンツプロバイダ１、２両方の証明書７０２ｄが共有データの認証に用いられる。
【０１４０】
証明書チェーンを通じて生成された証明書は、記録媒体の特定の領域にファイルの形態などで格納されて認証に用いられるか、または、ネットワーク上での認証に用いられることができる。
【０１４１】
場合によっては、それぞれの証明書権威者は、証明書破棄リスト（Certificate Revocation List：ＣＲＬ）を作成することができる。この場合、コンテンツプロバイダ及びユーザは、証明書破棄リスト（ＣＲＬ）をダウンロードして受信し、証明書を介して認証する前に、認証に使用する証明書が破棄されたか否かを検査する。万一、認証しようとする証明書が破棄された場合は、認証が成立しない。一方、証明書が破棄されなかった場合は、他の認証要件を満足する限り認証が成立する。
【０１４２】
本発明が提供する第２のセキュリティレベルでは、特定の機能を行う各アプリケーションが認定された場合、アプリケーションの動作が信頼するに値するということを前提とする。このため、共有データへのアクセス権限があるアプリケーションのみが共有データにアクセスすることが認められる。アプリケーションの動作が信頼されるためには、当該アプリケーションが認証される必要がある。このことを図８乃至図１０を参照して、以下のように詳細に説明する。
【０１４３】
図８及び図９は、本発明によるアプリケーションの認証について示す図である。図１０は、本発明による共有データに対するアクセス情報を持つアプリケーションを構成するＪＡＲファイルを示す図である。ここで、署名されたアプリケーション（signed application）を例に挙げて図８及び図９について説明する。
【０１４４】
図８は、本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図を示す。
【０１４５】
図８を参照すると、圧縮ファイルの一種であるＪＡＲファイルは、複数のファイルを１つにまとめるのに用いられている。ＪＡＲファイルが署名されている場合、このＪＡＲファイルを“署名されたＪＡＲファイル”という。この署名されたＪＡＲファイルによって構成されたアプリケーションを“署名されたアプリケーション”という。この署名されたＪＡＲファイルは、マニフェストファイル（Manifest file）がアップデートされていること、並びに署名ファイル（Signature file）及び署名ブロックファイル（Signature Block file）がＭＥＴＡＩＮＦＯディレクトリに追加されていること以外は、元々のＪＡＲファイルと同一である。
【０１４６】
図８のアプリケーションは、署名されたアプリケーションである。このアプリケーションを構成するＪＡＲファイルは、“Ａｐｐ０”ファイル及びＭＥＴＡＩＮＦＯディレクトリ８１を含む。“Ａｐｐ０”ファイルは、“ｃｌａｓｓｅｓ”ファイルとデータディレクトリを含む。このデータディレクトリには“Ａｐｐ０．ｄａｔ”ファイルが存在する。“ｃｌａｓｓｅｓ”ファイルは、“Ａｐｐ０．ｃｌａｓｓ”ファイルと“ｓｕｂｃｌａｓｓｅｓ”ディレクトリを含む。この“ｓｕｂｃｌａｓｓｅｓ”ディレクトリには、“ｓｕｂ１．ｃｌａｓｓ”及び“ｓｕｂ２．ｃｌａｓｓ”が存在する。また、図８の実施形態では、例えば、全てのクラスファイル（Ａｐｐ０．ｃｌａｓｓ、ｓｕｂ１．ｃｌａｓｓ、ｓｕｂ２．ｃｌａｓｓ）が署名される。
【０１４７】
ＭＥＴＡＩＮＦＯディレクトリ８１は、１つのマニフェストファイル８１１（ＭＡＮＩＦＥＳＴ．ＭＦ）及び１つの署名ブロックファイル８１３（ＸＸＸ．ＲＳＡ）を含む。これらのファイルによってアプリケーションの認証がなされる。
【０１４８】
マニフェストファイル８１１は、１つのＪＡＲファイル内に、署名された各ファイルに対するメッセージダイジェスト（message digest）とともにファイルのリストを含む。また、ＪＡＲファイル内の全てのファイルがマニフェストファイル８１１にエントリー（entry）としてリストされる必要はない。しかし、署名される全てのファイルはリストされなければならない。したがって、“Ａｐｐ０．ｃｌａｓｓ”ファイル、“ｓｕｂ１．ｃｌａｓｓ”ファイル、“ｓｕｂ２．ｃｌａｓｓ”ファイルに対するエントリーは、マニフェストファイル８１１にリストされなければならない。
【０１４９】
署名ファイル８１２は、マニフェストファイルのダイジェストを含む。署名ファイルは、権限ある供給者（authorizing organization）によって署名されたデータとなる。
【０１５０】
署名ファイル８１２のコンテンツを使用してメッセージダイジェストを計算した後、秘密鍵を用いて署名アルゴリズムを介して、その計算された結果を暗号化することによってデジタル署名が生成される。デジタル署名は、署名ファイルの署名されたバージョンになることができる。生成されたデジタル署名は、署名ブロックファイル８１３内に位置する。各署名ファイルは、多数のデジタル署名を持つことができるが、この複数の署名は同一の適法なエンティティによって生成されなければならない。
【０１５１】
また、この秘密鍵は、署名ブロックファイル８１３に存在する公開鍵に対応する秘密鍵である。この公開鍵は、署名ブロックファイル内の証明書のリーフ証明書のいずれか１つに位置する。この公開鍵を認証する証明書は、署名ブロックファイルに含まれる。
【０１５２】
署名ブロックファイル８１３は、デジタル署名ファイルとも呼ぶことができる。デジタル署名ファイルは、署名ファイル８１２と同じファイル名を持つが、異なる拡張子を持っている。この拡張子は、署名アルゴリズムによって定められる。例えば、この拡張子には、“．ＲＳＡ”または“．ＤＳＡ”などが相当する。
【０１５３】
共有データにアクセスするアプリケーションの認証は、アプリケーションを構成するＪＡＲファイル内のファイルを認証するやり方で行われる。署名されたＪＡＲファイル内のファイルの認証について、図９を参照して以下のように具体的に説明する。
【０１５４】
図９は、本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイル内のファイルの認証過程のフローチャートであり、アプリケーションの認証は、図６で示すようなコンテンツの認証と類似する方式で行われる。
【０１５５】
図９を参照して説明すると、１つのマニフェストファイルが最初に解析される（parse）とき、ある署名ファイルに対する署名は初めて検証（verify）される（Ｓ１０）。デジタル署名は、署名ブロックファイルに存在する。具体的に説明すると、この署名ファイルに対応する署名ブロックファイルを探し、その署名ブロックファイルから証明書を読み取る。これらの証明書のうち、リーフ証明書内には、この署名ファイルの生成に用いられた秘密鍵に対応する公開鍵が存在する。署名ブロックファイル内に存在する秘密鍵を用いて暗号化されたデジタル署名は、この公開鍵を用いてダイジェスト値に復元される。復元されたダイジェスト値は、署名ファイルのダイジェスト値と比較される。この比較の結果、両者が同一であると、デジタル署名の検証が実行される。デジタル署名の検証に失敗する場合、ファイルに対する認証は失敗となる（Ｓ７０）。
【０１５６】
認証されるファイルの有効性を確認するために、マニフェストファイルに対するダイジェスト値が計算される（Ｓ２０）。計算されたダイジェスト値が、署名ファイル内に存在するダイジェスト値と比較される（Ｓ３０）。比較された両ダイジェスト値が異なる場合、ファイルの認証は失敗となる（Ｓ７０）。比較された両ダイジェスト値が同一である場合、マニフェストファイルに対するインテグリティが確認される。
【０１５７】
比較されたダイジェスト値が同一である場合、認証されるファイルの実際のデータに対するダイジェスト値が計算される（Ｓ４０）。計算されたダイジェスト値がマニフェストファイル内のダイジェスト値と比較される（Ｓ５０）。
【０１５８】
比較された両ダイジェスト値が同一であるとファイルの有効性が確認され、ファイルの認証に成功する（Ｓ６０）。一方、比較された両ダイジェット値が異なるとファイルの認証は失敗となる（Ｓ７０）。
【０１５９】
本発明は、アプリケーションを構成するＪＡＲファイル内のファイルを認証する際に、署名ファイルを用いてマニフェストファイルのインテグリティを確認し、署名ブロックファイルを用いてデジタル署名を検証することを特徴とする。また、マニフェストファイルを用いてＪＡＲファイルの実際のデータに対するインテグリティを確認することを特徴とする。
【０１６０】
したがって、ＪＡＲファイルの実際のデータに対するインテグリティ確認（Ｓ４０、Ｓ５０）、マニフェストファイルのインテグリティ確認（Ｓ２０、Ｓ３０）、及びデジタル署名の検証（Ｓ１０）は、個別的に実行可能である。すなわち、図９の実施形態で説明した認証フローの順序は必須ではなく、再生システムによって順序が変わっても良い。
【０１６１】
また、アプリケーションを認証する際に、認証されるファイルがマニフェストファイルでリストされたものかを、認証されるファイルの実際のデータに対するダイジェスト値が計算（Ｓ４０）される前に確認することも可能である。
【０１６２】
また、デジタル署名に対する検証結果（Ｓ１０）とマニフェストファイルに対するインテグリティ確認の結果（Ｓ３０）は、後々に使用するために格納されても良い。この場合、Ｓ１０〜Ｓ３０のステップは、１つのＪＡＲファイルの認証過程で１回しか行われない。
【０１６３】
アプリケーションの認証に失敗しても、プレーヤーの実装によって共有データへのアクセスを許容することができる。しかし、共有データの保護のためにアクセスが制限されることが好ましい。このアクセス制限の程度は、プレーヤーの実装によって、認証されなかったアプリケーションが全ての共有データにアクセスすることを制限されるように設定することが可能である。または、プレーヤーによっては、制限された範囲の共有データにのみアクセスできるように制御しても良い。
【０１６４】
図１０は、本発明の一実施形態によるアプリケーションを構成するＪＡＲファイルの図である。
【０１６５】
図１０を参照すると、共有データへのアクセス権限があるアプリケーションのみが前記共有データにアクセスできるようにすべく、本発明は共有データをリソースとするアプリケーションのために共有データに対するアクセス情報を使用する。有効なアクセス情報を持つアプリケーションのみが共有データにアクセス可能になるため、権限のないアプリケーションによる共有データの利用を防ぐことができる。
【０１６６】
アクセス情報は、アプリケーションに対するクレデンシャル情報でありうる。クレデンシャル情報はパーミッション要求ファイルに含まれることができる。パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在できる。
【０１６７】
図１０のＪＡＲファイル（Ａｐｐ０．ｊａｒ）は、アプリケーションを構成するファイルである。このＪＡＲファイルには、クレデンシャル情報を含むパーミッション要求ファイル（Ａｐｐ０．ｐｅｒｍ）が存在する。クレデンシャル情報としては、“供与者識別子（Grantor identifier）”、“有効期間（Expiration date）”、“ファイル名（Filename）”、“署名（Signature）”、“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”などが存在する。
【０１６８】
この“供与者識別子（Grantor identifier）”は、アプリケーションを提供する主体に関する情報である。“供与者識別子（Grantor identifier）”としては、例えば、“ｏｒｇ１＿ＩＤ”などがありうる。
【０１６９】
この“有効期間”は、クレデンシャル情報の有効期間を意味する。例えば、“有効期間”が“２３／０２／２０３５”と与えられた場合、このクレデンシャル情報を含むアプリケーションは、２０３５年０２年２３日が経過した後には共有データにアクセスできなくなる。
【０１７０】
この“ファイル名”は、アプリケーションがアクセスしようとする共有データの位置およびその共有データに対して付与される読取り／書込み権限に関する情報である。例えば、“ファイル名読取り”情報が”真（true）”と与えられ、“ファイル名”が前記ファイルの存在する位置で表現されて、“ＢＵＤＡ／ｏｒｇ１＿ＩＤ／Ｓｈａｒｅｄ／Ｊａｐａｎｅｓｅ．ｏｔｆ”と与えられることができる。図６を参照して説明すると、次の通りである。クレデンシャル情報を持つアプリケーションは、ローカルストレージ内のバインディングユニットデータ領域の“ｏｒｇ１＿ＩＤ”ディレクトリのディスク共有（disc-dependent shared）ディレクトリである“Ｓｈａｒｅｄ”ディレクトリ内に存在する“Ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”ファイルにアクセスすることによって、“Ｊａｐａｎｅｓｅ．ｏｔｆ（６１４）”ファイルを読み取ることができることを意味する。
【０１７１】
“署名”は、アプリケーションプロバイダからの署名を含む。そして、“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”は、署名ブロックファイル内の特定の証明書の位置を表すのに用いられる。“Ｃｅｒｔｃｈａｉｎｆｉｌｅｉｄ”は、認証に用いられるリーフ証明書のシリアル番号に対応する特定のｓｅｒｉａｌ Ｎｕｍｂｅｒおよび認証に用いられるリーフ証明書の主体に対応する発行者の情報を含む。署名の公開鍵に通じる証明書は、署名ブロックファイル内の“ｃｅｒｔｉｆｃａｔｅｓ”フィールドに存在しなければならない。クレデンシャル情報のｃｅｒｔｃｈａｉｎｆｉｅｌｄフィールドのコンテンツに対応する発行者フィールドのシーケンス番号及び組織（organization）ＩＤが一緒に見つけられるまで、各証明書は確認されなければならない。もし、対応する証明書が前記署名ブロックファイル内に存在すると、ファイルアクセスは許容されない。
【０１７２】
アプリケーションに対するクレデンシャル情報が認証され、かつ共有データに対する有効な“ファイル名”を含む場合、当該アプリケーションは、共有データにアクセスできる。これに対し、クレデンシャル情報が有効でない場合、当該アプリケーションは信頼できず、当該アプリケーションの共有データへのアクセスは制限される。結果として、本発明によれば、共有データにアクセスするアプリケーションにクレデンシャル情報をおくことによって共有データを保護することができる。
【０１７３】
また、バーチャルパッケージを構成する間に、ローカルストレージにあるＪＡＲファイルが、記録媒体内の対応するＪＡＲファイルよりも優先権を持つ場合がある。この場合、記録媒体内のＪＡＲファイルがクレデンシャル情報を含むとしても、ローカルストレージ内のクレデンシャル情報が用いられる。
【０１７４】
また、パーミッション要求ファイルがＪＡＲファイル内にある時、パーミッション要求ファイルは認証されなければならない。
【０１７５】
図１１は、本発明の一実施形態による共有データ再生方法のフローチャートである。
【０１７６】
まず、本発明が提供するもう１つのセキュリティレベルは、共有データへのアクセスが許容されたアプリケーション（権限を与えられたアプリケーション）の悪意的な機能（malicious function）を排除できないと仮定する。したがって、本発明は、共有データの保護のために共有データを暗号化してユーザに提供することを特徴とする。共有データにアクセスするアプリケーションは、その共有データを解読できなければならない。
【０１７７】
共有データが暗号化されて提供される場合、アプリケーションが共有データにアクセスできたとしても、当該アプリケーションが共有データを用いて特定の機能を行えるためにはその共有データが解読されなければならない。
【０１７８】
本発明によって暗号化されて保護される共有データを再生する方法ついて、図１１を参照して以下の通り説明する。
【０１７９】
図１１を参照すると、記録媒体と関連付けられ、暗号化されている共有データが記録媒体外からローカルストレージにダウンロードされる（Ｓ１１１０）。このため、共有データをダウンロードするアプリケーションは、ネットワークを介して共有データにアクセスできるアプリケーションでなければならない。
【０１８０】
記録媒体がロードされると、記録媒体と関連した共有データがローカルストレージに存在する場合、記録媒体内に記録されたデータと共有データがバインディングオペレーションによってバインディングされ、バーチャルパッケージが生成される（Ｓ１１２０）。
【０１８１】
ここで、共有データがダウンロードされる前に既にバーチャルパッケージが存在している場合には、ダウンロードされた共有データだけでなく、バーチャルパッケージもアップデートされる。
【０１８２】
バーチャルパッケージの生成前に共有データを認証することが好ましい。共有データの認証に失敗した場合、バーチャルファイルシステムは、ロードされた記録媒体内のディスクパッケージを用いてバーチャルパッケージを生成する。この場合、不正確な共有データを含むバーチャルパッケージの生成を遮断することによって、真のコンテンツプロバイダを保護可能になる。
【０１８３】
このバーチャルパッケージを用いて、ローカルストレージ内のデータと記録媒体内に記録されたデータが共に再生される。再生を行うために、再生を行うアプリケーションが記録媒体内のデータにバインディングされた共有データにアクセスする（Ｓ１１３０）。
【０１８４】
共有データが暗号化された場合、共有データはデコーダによって再生可能な形態に復元されなければならず、暗号化された共有データは解読されなければならない。したがって、暗号化された共有データにアクセスするアプリケーションは、共有データを解読できる情報を含むことができる。この情報は、共有データにアクセスするアプリケーションが直接共有データを解読できる情報でもありうる。また、この情報は、共有データを解読できるアプリケーションを実行させることができる。
【０１８５】
共有データにアクセスするアプリケーションが、共有データを解読できる有効な情報を持つ場合、当該情報を用いて共有データが解読される（Ｓ１１４０）。共有データが解読されると、解読された共有データがデコーダに提供されてバーチャルパッケージ内の他のファイルと共に再生される（Ｓ１１５０）。
【０１８６】
なお、共有データと共にローカルストレージに存在する他のデータも記録媒体内のデータとバインディングされることによって再生されることができる。共有データと共に再生される他のデータが暗号化された場合、それらのデータは、解読完了後に再生しても良い。
【０１８７】
本発明によって共有データを暗号化すると、誤りのあるアプリケーションが共有データにアクセスしたとしても、その共有データを用いて特定の機能を行うことはできない。したがって、共有データを悪意的な機能から保護できるという長所がある。
【０１８８】
本発明には、共有データに対する様々な暗号化／解読体系が可能である。共有データを暗号化／解読するキー発生の側面においては、同一のコンテンツプロバイダによって提供された記録媒体間で共有されるデータには、コンテンツプロバイダ固有のキーが用いられることができる。
【０１８９】
共有データが暗号化された場合、前記共有データを解読できるように暗号化／解読キーまたはキーを生成するための秘密情報（secret information）がユーザに配布される必要がある。当該キーペアまたはキーを生成するための秘密情報は、記録媒体内に格納されてユーザに提供されることができる。これは、キーを持つ記録媒体がＢＤ端末にある時に限って、ローカルストレージにあるデータがアクセス可能であるという仮定の下で動作する。
【０１９０】
当該キーペアまたはキー生成のための秘密情報は、共有データを利用するアプリケーションに同封（enclose）されてユーザに提供されても良い。また、当該キーペアあるいはキー生成のための秘密情報は、場合によっては光記録再生装置内のキーストア（key store）に格納されても良い。
【０１９１】
プレーヤーは、暗号化された共有データを用いて特定の機能を行わなければならない場合、記録媒体、アプリケーション、キーストアなどから暗号化された共有データを解読を行えるキーを読み取り（キー生成のための秘密情報である場合、キー生成のための秘密情報を読み取ってキーを生成し）、当該共有データを解読する。
【０１９２】
データの暗号化体系には、対称暗号化方法（symmetric cryptographic method）および非対称暗号化方法（asymmetric cryptographic method）がある。代表的な対称暗号化方法としては、ＡＥＳ（Advanced Encryption Standard）、ＤＥＳ（Data Encryption Standard）、またはＩＤＥＡ（International Data Encryption Algorithm）などがある。一方、代表的な非対称暗号化方法としては、ＲＳＡ（Rivest-Shamir-Adelman）またはＤＳＡ（Digital Signature Algorithm）等がある。
【０１９３】
本発明による、共有データを暗号化することによって共有データを保護するセキュリティ案において、暗号化された共有データにアクセスするアプリケーションは、共有データに対するアクセス情報を含むアプリケーションでありうる。このアクセス情報は、当該アプリケーションのクレデンシャル情報でありうる。場合によっては、クレデンシャル情報のないアプリケーションも、暗号化された共有データにアクセスできるように許容されることができる。
【０１９４】
プレーヤーが暗号化された共有データにアクセスするアプリケーションの認証に失敗する場合がありうる。この場合、アプリケーションの共有データへのアクセスを許容するか否かは、プレーヤーの実装による。すなわち、認証に失敗したとしても、アプリケーションが共有データにアクセスできるようにすることができる。本発明によって、共有データが暗号化されて提供されると、認証されたアプリケーションが共有データにアクセスしようとしても、共有データは保護されることができる。
【０１９５】
また、署名されたアプリケーションは、図８及び図９の説明に関して例として取り上げられた。しかし、署名されなかったアプリケーションも同様に存在することができる。署名されなかったアプリケーションの場合、その有効性は検証できない。したがって、署名されなかったアプリケーションは、共有データへのアクセスは許容されないことが好ましい。
【０１９６】
図１２は、本発明の一実施形態による再生システムを用いた記録媒体再生装置のブロック図である。
【０１９７】
まず、“再生システム”は、光記録再生装置内に備えられるプログラム（ソフトウェア）及び／またはハードウェアで構成される集合的再生処理手段を含む。この再生システムは、光記録再生装置内にロードされた記録媒体を再生し、同時に、記録媒体に関連してローカルストレージ内に格納された（例えば、外部からダウンロードした）データを再生し、かつ管理するシステムである。
【０１９８】
特に、再生システム１７は、“キーイベントハンドラ１７１”、“モジュールマネージャ１７２”、“ナビゲータ１７３”、“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、“再生制御エンジン１７６”、“プレゼンテーションエンジン１７７”、及び“バーチャルファイルシステム４０”で構成される。これを詳細に説明すると、次の通りである。
【０１９９】
まず、ＨＤＭＶタイトル及びＢＤ−Ｊタイトルをそれぞれ再生するための、別個の再生処理管理手段として、ＨＤＭＶタイトルについての“ＨＤＭＶモジュール１７４”及びＢＤ−Ｊタイトルについての“ＢＤ−Ｊモジュール１７５”が独立的に構成される。“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”のそれぞれは、既に述べたオブジェクトファイル（ＭｏｖｉｅＯｂｊｅｃｔまたはＢＤ−Ｊ Ｏｂｊｅｃｔ）内のコマンドまたはプログラムを受信して処理するようにする制御機能を持つ。“ＨＤＭＶモジュール１７４”及び前記“ＢＤ−Ｊモジュール１７５”のそれぞれは、再生システムのハードウェア構成からコマンドあるいはアプリケーションを分離し、このコマンドあるいはアプリケーションのポータビリティ（portability）を可能にする。
【０２００】
コマンドあるいはアプリケーションなどを受信して処理する手段として、“ＨＤＭＶモジュール１７４”内には“コマンドプロセッサ１７４ａ”が備えられており、一方、“ＢＤ−Ｊモジュール１７５”内には“Ｊａｖａ ＶＭ１７５ａ”及び“アプリケーションマネージャ１７５ｂ”、“アプリケーションキャッシュ１７５ｃ”が備えられている。
【０２０１】
“Ｊａｖａ ＶＭ １７５ａ”は、アプリケーションを実行する“仮想マシン（Virtual Machine）”である。“アプリケーションマネージャ１７５ｂ”は、アプリケーションのライフサイクルを管理するアプリケーション管理機能を含む。“アプリケーションマネージャ１７５ｂ”は、アプリケーションキャッシュ１７５ｃからアプリケーションをロードできる。アプリケーションキャッシュ１７５ｃの目的は、アプリケーションがロードされる間に記録媒体からＡＶデータが切れることなく再生されるようにすることと、データをロードする際の待ち時間（latency）を減少させることである。すなわち、アプリケーションキャッシュ１７５ｃは、ＢＤ−Ｊのためのプリロード（preload）バッファである。しかし、プレーヤーは、プリロードされないクラスファイルを含む付加データを使用することも可能である。その一例には、ローカルストレージ内のＪＡＲファイルからデータをロードする場合がある。
【０２０２】
また、“モジュールマネージャ１７２”は、“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”にユーザ命令を伝達するため、および“ＨＤＭＶモジュール１７４”及び“ＢＤ−Ｊモジュール１７５”の動作を制御するために提供される。また、“ＨＤＭＶモジュール１７４”または“ＢＤ−Ｊモジュール１７５”の再生命令によって、ディスク内に記録されたプレイリストファイル情報を解析し、対応する再生機能を行う“再生制御エンジン１７６”が提供される。
【０２０３】
また、“再生制御エンジン１７６”によって再生管理される特定のストリームをデコードし、画面中にデコードされたストリームを表示するための“プレゼンテーションエンジン１７７”が提供される。
【０２０４】
特に、“再生制御エンジン１７６”は、全ての再生を実際に管理する“再生制御機能１７６ａ”と、プレーヤーステータスレジスタ（ＰＳＲ）及び一般目的レジスタ（ＧＰＲ）を格納する“プレーヤーレジスタ１７６ｂ”と、を含む。場合によっては、“再生制御機能１７６ａ”が“再生制御エンジン１７６”を意味することもある。
【０２０５】
前述した本発明の再生システムにおいて、“モジュールマネージャ１７２”、“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、及び“プレイバック制御エンジン１７６”は、それぞれソフトウェア的な処理が可能である。実際に、ハードウェア構成よりはソフトウェア的処理をすることが設計においては有用である。ただし、“プレゼンテーションエンジン１７７”、デコーダ、及びプレーン（Plane）は、ハードウェア的に設計されることが一般的である。特に、ソフトウェア的に処理される構成要素（例えば、図面符号１７２、１７４、１７５、１７６）の場合は、制御装置１２の一部分として構成されても良い。したがって、本発明の構成はその意味として理解すべきであり、ハードウェア的構成かソフトウェア的構成かに限定されない。
【０２０６】
本発明による再生システム１７は、以下の特徴を有する。
【０２０７】
第１に、ＨＤＭＶタイトルについての“ＨＤＭＶモジュール１７４”およびＢＤ−Ｊタイトルについての“ＢＤ−Ｊモジュール１７５”は、独立的に構成される。したがって、これら両モジュール１７４、１７５は同時に実行されない。すなわち、ＨＤＭＶタイトル再生中にはＢＤ−Ｊタイトルを再生できなく、その逆も同様である。
【０２０８】
第２に、外部から付加データをダウンロードする動作のように光記録再生装置内のネットワーク機能を管理し、かつローカルストレージ１５内に格納されたファイルを編集することによって、またはディスクパッケージにファイルをバインディングすることによって、バーチャルパッケージを生成する動作のようにローカルストレージ１５を管理するプログラムであるアプリケーションが、再生システム１７内に備えられる。すなわち、これらのアプリケーションは、ディスク内のファイルシステム及びローカルストレージのファイルシステムを１つのシステムとして管理するバーチャルファイルシステム４０を形成し、当該形成されたバーチャルファイルシステム４０を介してオリジナルデータ及び付加データを再生するためのバーチャルパッケージを生成し、かつ管理する。
【０２０９】
第３に、ＨＤＭＶタイトル及びＢＤ−Ｊタイトルは、それぞれ別個の方式のユーザ命令を受信し、相互にそれぞれ独立してユーザ命令を行う。“キーイベントハンドラ１７１”は、ユーザ命令を受信して“ＨＤＭＶモジュール１７４”、“ＢＤ−Ｊモジュール１７５”、および“モジュールマネージャ１７２／ナビゲータ１７３”のいずれか１つに伝達する。例えば、“キーイベントハンドラ１７１”は、受信した命令が“ユーザーオペレーション（ＵＯ）”によるユーザ命令であると、 “モジュールマネージャ１７２”に伝送するやり方で当該命令を実行する。一方、“キーイベントハンドラ１７１”は、受信された命令が“キーイベント”によるユーザ命令であると、 “ＢＤ−Ｊモジュール１７５”に伝送するやり方で当該命令を実行する。
【０２１０】
第４に、“再生制御エンジン１７６”の管理（これを“マスター”ともいう）は、現在動作中のモジュール１７４、１７５のいずれか１つが担当する。すなわち、ＨＤＭＶタイトル再生中には“ＨＤＭＶモジュール１７４”がマスターとなる。または、ＢＤ−Ｊタイトル再生中には“ＢＤ−Ｊモジュール１７５”がマスターとなる。
【０２１１】
“ナビゲータ１７３”は、いつでもユーザの制御の下でタイトル選択を行うことができ、ユーザに記録媒体及びタイトルメタデータを提供できる。
【０２１２】
図１３は、本発明による共有データ保護を説明する例示的な図であり、図１３ではバーチャルパッケージが具体的に示される。
【０２１３】
ロードされたディスク内には、特定のファイル構造（例えば、図２のような構造）が記録されており、これを特にディスクパッケージともいう。ローカルストレージ内にはローカルストレージファイルシステムが存在する。ロードされたディスク（例えば、ｄｉｓｃ１＿ＩＤ）にバインディングされるバインディングユニット及びバインディングユニットマニフェストファイルが該当ファイルシステム内に含まれる。
【０２１４】
また、バインディングユニットマニフェストファイルは、ネームマッピング情報を含む。ネームマッピング情報は、バインディングユニットについての情報である。例えば、バインディングユニットを生成するファイルのリストをディスクにバインディングする場合には、ネームマッピング情報は、バーチャルパッケージ内の位置、ファイル名等についての情報を含む。
【０２１５】
したがって、バーチャルファイルシステム４０は、ネームマッピング情報を用いることによって、ロードされたディスク内のディスクパッケージにバインディングユニットをバインディングするバインディングオペレーションを介して新しいバーチャルパッケージを生成する。また、バーチャルファイルシステム４０は、バーチャルパッケージに属するファイルへのアクセスメカニズムを制御する役割を果たす。
【０２１６】
バーチャルファイルシステムによって生成されたバーチャルパッケージは、ＢＤ−Ｊモード及びＨＤＭＶモードの両方に用いられる。ＢＤ−Ｊモードでは、記録媒体またはローカルストレージ上に位置したアプリケーションがバーチャルファイルシステムを介してバーチャルパッケージにアクセスできる。ＨＤＭＶモードでは、ＭｏｖｉｅＯｂｊｅｃｔがバーチャルパッケージにアクセスできる。
【０２１７】
図１３を参照すると、ディスク内の記録媒体ファイル構造（ディスクパッケージ）４２１において、ルートディレクトリの下位ディレクトリであるＢＤディレクトリ（ＢＤＭＶ）は、インデックスファイル（Ｉｎｄｅｘ．ｂｄｍｖ）、オブジェクトファイル（ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ）、プレイリストファイル（０００００．ｍｐｌｓ）、クリップ情報ファイル（０１０００．ｃｌｐｉ）、ストリームファイル（０１０００．ｍ２ｔｓ）、補助データファイル（ｓｏｕｎｄ．ｂｄｍｖ）を含む。ロードされたディスク（例えば、ｏｒｇ１＿ＩＤであり、ｄｉｓｃ２＿ＩＤであるディスク）に関連したバインディングユニット６１には、特定のプレイリストファイル６１１（Ａｐｒ２００５．ｍｐｌｓ）、当該プレイリストファイル６１１によって管理されるクリップであるクリップ情報ファイル６１２（Ａｐｒ２００５．ｃｌｐｉ）、及びストリームファイル６１３（Ａｐｒ２００５．ｍ２ｔｓ）が含まれる。
【０２１８】
また、コンテンツプロバイダが提供した共有データとして補助データファイル６１４（Ｊａｐａｎｅｓｅ．ｏｔｆ）がディスク共有（disc-dependent shared）ディレクトリ（Ｓｈａｒｅｄ）に存在する場合において、バーチャルパッケージ５１を生成する方法は、次の通りである。
【０２１９】
ネームマッピング情報によって次のようにファイル名が変更される。バインディングユニット６１内のプレイリストファイル６１１（Ａｐｒ２００５．ｍｐｌｓ）は、バーチャルパッケージ５１内のＰＬＡＹＬＩＳＴディレクトリのプレイリストファイル５１１（０００００．ｍｐｌｓ）にファイル名が変更される。同様に、クリップ情報ファイル６１２（Ａｐｒ２００５．ｃｌｐｉ）は、バーチャルパッケージ５１内のＣＬＩＰＩＮＦディレクトリのクリップ情報ファイル５１２（０２０００．ｃｌｐｉ）にファイル名が変更される。ストリームファイル６１３（Ａｐｒ２００５．ｍ２ｔｓ）は、バーチャルパッケージ５１内のストリーム（ＳＴＲＥＡＭ）ディレクトリのストリームファイル５１３（０２０００．ｍ２ｔｓ）に、補助データファイル６１４（Ｊａｐａｎｅｓｅ．ｏｔｆ）は、ＡＵＸＤＡＴＡディレクトリの補助データファイル５１４（１１１１１．ｏｔｆ）にファイル名が変更される。
【０２２０】
バーチャルパッケージ５１は、ルートディレクトリの下位ディレクトリであるＢＤＭＶディレクトリに、バーチャルパッケージによるインデックスファイル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルを含む。ＰＬＡＹＬＩＳＴディレクトリには、バインディングユニットのプレイリストファイルによって代替されたプレイリストファイル５１１（０００００．ｍｐｌｓ）がくる。ＣＬＩＰＩＮＦディレクトリでは、記録媒体のクリップ情報ファイル（０１０００．ｃｌｐｉ）にバインディングユニットのクリップ情報ファイル５１２（０２０００．ｃｌｐｉ）が追加される。ＳＴＲＥＡＭディレクトリでは、記録媒体のストリームファイル（０１０００．ｍ２ｔｓ）にバインディングユニットのストリームファイル５１３（０２０００．ｍ２ｔｓ）が追加される。ＡＵＸＤＡＴＡディレクトリでは、記録媒体の補助データファイル（ｓｏｕｎｄ．ｂｄｍｖ）にバインディングユニットの補助デートファイル５１４（１１１１１．ｏｔｆ）が追加される。
【０２２１】
なお、バーチャルパッケージ内の上位ファイルであるインデックスファイル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルは、新しく生成されるプレイリストファイル５１１（０００００．ｍｐｌｓ）に基づいて既存ディスク内のインデックステーブル（Ｉｎｄｅｘ）及びＭｏｖｉｅＯｂｊｅｃｔファイルからアップデートされることができる。特に、バーチャルパッケージ内のプレイリストファイル５１１（０００００．ｍｐｌｓ）によってタイトルが変更される場合に、インデックスファイル及びＭｏｖｉｅＯｂｊｅｃｔファイルがアップデートされる。この場合に、タイトル変更は、新しいタイトルが追加されること、既存のタイトルが変更されること、またはタイトル再生のシナリオが変更されること等を意味する。
【０２２２】
本発明が提供するセキュリティレベルのうち、共有データの認証を通じて共有データを保護するセキュリティレベルの場合には、共有データの認証に失敗すると、光記録再生装置のバーチャルファイルシステム４０は、前記共有データを含むバーチャルパッケージ５１を生成しなくて良い。ただし、記録媒体内のディスクパッケージのみを使用してバーチャルパッケージを生成することになる。この場合、プレーヤーは、ローカルストレージ内に格納された共有データである“１１１１１．ｏｔｆ”を再生できない。結果として、権限のないプロバイダの共有データが記録媒体と共に再生されるのを防止することによって、真のコンテンツプロバイダを保護することができる。
【０２２３】
また、共有データの認証に成功して共有データを含むバーチャルパッケージを生成したとしても、共有データにアクセスするアプリケーションのクレデンシャル情報が有効でない場合、アプリケーションは共有データにアクセスできない。したがって、共有データが再生されることを防ぎ、有効でないアプリケーションによる再生を防止することによって、共有データを保護できる。
【０２２４】
本発明が提供するさらに他のセキュリティレベルによれば、暗号化されたデータを解読できないアプリケーションによっては共有データを再生できない。したがって、バーチャルパッケージ内の共有データである“１１１１１．ｏｔｆ（５１４）”が暗号化されたファイルである場合、当該暗号化されたファイルを解読できるアプリケーションのみによって当該ファイルが再生される。アプリケーションが権限のない供与者によって提供された場合には、当該アプリケーションは共有データを解読できる情報を持っていないはずである。したがって、認証されなかったアプリケーションが共有データにアクセスできたとしても、共有データを解読することができず、共有データは保護される。
【０２２５】
本発明による記録媒体再生装置について図４を参照して以下のように説明する。
【０２２６】
本発明によるローカルストレージを用いた記録媒体再生装置は、記録媒体と関連した共有データがダウンロードされて格納されるローカルストレージ１５と、共有データに対する有効なアクセス情報を持つアプリケーションのみが共有データにアクセスするように制御する制御装置１２と、を備える。当該アクセス情報は、当該アプリケーションのクレデンシャル情報を含むことができ、当該クレデンシャル情報は、パーミッション要求ファイルに含まれることができる。
【０２２７】
このパーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイル内に存在することができる。この場合、パーミッション要求ファイルは、認証されることが好ましい。
【０２２８】
制御装置１２は、アプリケーションが共有データにアクセスする前に共有データを認証することによって共有データを保護することができる。
【０２２９】
共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合には、その共有データは、コンテンツプロバイダの証明書を用いて認証されることができる。一方、共有データが複数のコンテンツプロバイダ間で共有されるデータである場合には、その共有データは、これらコンテンツプロバイダの証明書を用いて認証されることができる。
【０２３０】
本発明によるローカルストレージを用いた記録媒体再生装置は、記録媒体と関連した暗号化された共有データがダウンロードされて格納されるローカルストレージ１５と、ローカルストレージ内のデータを記録媒体内のデータにバインディングすることによって、共有データを含むバーチャルパッケージを生成する制御装置１２と、を備える。
【０２３１】
制御装置１２は、バーチャルパッケージを用いて共有データをローカルストレージ１５内の他のデータ及び／または記録媒体内のデータと共に再生する。この時、共有データが暗号化されて提供されるため、制御装置１２は共有データを解読後に再生する。
【０２３２】
共有データを解読するに当たり、制御装置１２は、共有データに対する有効なアクセス情報を持つアプリケーションのみが共有データにアクセスするようにすることができる。アクセス情報は、共有データにアクセスするアプリケーションのクレデンシャル情報である。また、アクセス情報は、パーミッション要求ファイルに存在でき、パーミッション要求ファイルは、アプリケーションを構成するＪＡＲファイルに含まれることができる。
【０２３３】
バーチャルパッケージを生成するときに、制御装置１２は、共有データを認証し、バーチャルパッケージを生成することが好ましい。この時、共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合に、その共有データは、コンテンツプロバイダの証明書内の署名を用いて認証できる。一方、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合に、その共有データをこれらのコンテンツプロバイダの各証明書内の共同の署名で認証できる。
【０２３４】
共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合には、その共有データは、当該コンテンツプロバイダのみのキーを用いて暗号化されてユーザに提供される。これに対し、共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合には、その共有データは、これらのコンテンツプロバイダだけに合致するキーを用いて暗号化されてユーザに提供される。
【０２３５】
暗号化された共有データは、解読された後に再生されることができる。この解読には、その共有データにアクセスするアプリケーションに含まれるキーが用いられることができる。また、記録媒体に格納されたキーを用いることも可能である。場合によっては、解読に光記録再生装置に格納されたキーが解読に用いられても良い。
【０２３６】
したがって、本発明によって、真のコンテンツプロバイダによって提供されたコンテンツ及び変質していないコンテンツのみが再生されるようにすることによって、共有データを保護することができる。
【０２３７】
本発明の要旨または範囲から離れることなく、さまざまな修正及び変形を行いうることは、当業者にとっては明らかである。したがって、本発明は、特許請求の範囲及びその均等範囲内における本発明の改良及び変更された事項も含むことは自明である。
【図面の簡単な説明】
【０２３８】
【図１】本発明の概念的理解を助ける、光記録再生装置及び周辺機器間の統合的使用の一例を説明する図である。
【図２】例えばＢＤ−ＲＯＭなどの本発明の記録媒体内に記録されるファイル構造の図である。
【図３】本発明の記録媒体に記録されるデータ記録構造の図である。
【図４】本発明の一実施形態による光記録再生装置のブロック図である。
【図５】本発明のローカルストレージ内のファイル構造の一実施形態を示す図である。
【図６】本発明の一実施形態による共有データ認証プロセスを説明する図である。
【図７】本発明によるデータ認証に用いられる証明書チェーンの図である。
【図８】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図である。
【図９】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイル内のファイルの認証プロセスのフローチャートである。
【図１０】本発明の一実施形態による署名されたアプリケーションを構成するＪＡＲファイルの図である。
【図１１】本発明の一実施形態による共有データ再生方法のフローチャートである。
【図１２】本発明の一実施形態による再生システムを用いた記録媒体再生装置のブロック図である。
【図１３】バーチャルパッケージが詳細に示される、本発明による共有データ保護を説明する例示的な図である。
【特許請求の範囲】
【請求項１】
記録媒体と関連した共有データをローカルストレージにダウンロードするステップと、
前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスすることを可能にするステップと
を備えることを特徴とする共有データ保護方法。
【請求項２】
前記アクセス情報は、前記アプリケーションのクレデンシャル情報であることを特徴とする請求項１に記載の方法。
【請求項３】
前記クレデンシャル情報は、パーミッション要求ファイルに含まれることを特徴とする請求項２に記載の方法。
【請求項４】
前記パーミッション要求ファイルは、前記アプリケーションを構成するＪＡＲファイル内に存在することを特徴とする請求項３に記載の方法。
【請求項５】
前記クレデンシャル情報は、供与者識別情報、有効期間、ファイル名、署名、およびＣｅｒｔｃｈａｉｎｆｉｌｅｉｄを含むことを特徴とする請求項２に記載の方法。
【請求項６】
前記アプリケーションが前記共有データにアクセスする前に、前記共有データを認証するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項６に記載の共有データ保護方法。
【請求項８】
前記証明書は、前記コンテンツプロバイダの署名を含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項６に記載の方法。
【請求項１０】
前記証明書は、前記複数のコンテンツプロバイダの共同の署名を含むことを特徴とする請求項９に記載の方法。
【請求項１１】
ローカルストレージに記録媒体と関連した暗号化した共有データをダウンロードするステップと、
ローカルストレージ内のデータを前記記録媒体内のデータにバインディングすることによって、前記共有データを含むバーチャルパッケージを生成するステップと、
前記バーチャルパッケージを用いて前記共有データを解読するステップと、
前記解読された共有データを再生するステップと
を備えることを特徴とするローカルストレージを用いた記録媒体再生方法。
【請求項１２】
前記共有データは、前記共有データにアクセスするアプリケーションを実行することによって再生されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記アプリケーションは、前記共有データに対するアクセス情報として前記アプリケーションのクレデンシャル情報を含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記共有データは、前記アプリケーションに含まれたキーを用いて解読されることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記共有データは、前記記録媒体内に格納されたキーを用いて解読されることを特徴とする請求項１１に記載の方法。
【請求項１６】
前記共有データの解読は、光記録再生装置内に格納されたキーを用いて解読されることを特徴とする請求項１１に記載の方法。
【請求項１７】
前記バーチャルパッケージを生成するときに、
前記共有データは前記バーチャルパッケージを生成するために認証されることを特徴とする請求項１１に記載の方法。
【請求項１８】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書内の署名を使用することによって認証されることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書内の共同の署名を使用して認証されることを特徴とする請求項１７に記載の方法。
【請求項２０】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダのキーを用いて認証されることを特徴とする請求項１１に記載の方法。
【請求項２１】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダに一致するキーを使用して認証されることを特徴とする請求項１１に記載の方法。
【請求項２２】
記録媒体と関連したダウンロードされた共有データを格納するローカルストレージと、
前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスするように制御する制御装置と
を備えたことを特徴とする共有データ保護装置。
【請求項２３】
前記アクセス情報は、前記アプリケーションのクレデンシャル情報であることを特徴とする請求項２２に記載の装置。
【請求項２４】
前記クレデンシャル情報は、パーミッション要求ファイルに含まれることを特徴とする請求項２３に記載の装置。
【請求項２５】
前記パーミッション要求ファイルは、前記アプリケーションを構成するＪＡＲファイル内に存在することを特徴とする請求項２４に記載の装置。
【請求項２６】
前記制御装置は、前記アプリケーションが前記共有データにアクセスする前に前記共有データを認証することを特徴とする請求項２２に記載の装置。
【請求項２７】
前記共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項２６に記載の装置。
【請求項２８】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項２６に記載の装置。
【請求項２９】
記録媒体と関連したダウンロードされた暗号化された共有データを格納するローカルストレージと、
前記ローカルストレージ内のデータを前記記録媒体内のデータにバインディングすることによって、前記共有データを含むバーチャルパッケージを生成し、前記バーチャルパッケージを用いて前記共有データを解読後に再生する制御装置と
を備えたことを特徴とするローカルストレージを用いた記録媒体再生装置。
【請求項３０】
前記共有データを解読するときに、
前記制御装置は、前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスするように制御することを特徴とする請求項２９に記載の装置。
【請求項３１】
前記アクセス情報は、前記共有データにアクセスする前記アプリケーションのクレデンシャル情報であることを特徴とする請求項３０に記載の装置。
【請求項３２】
前記バーチャルパッケージを生成するときに、
前記制御装置は、前記共有データを認証して、前記バーチャルパッケージを生成することを特徴とする請求項３０に記載の装置。
【請求項３３】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記制御装置は、前記共有データを前記コンテンツプロバイダの証明書内の署名を使用して認証することを特徴とする請求項３２に記載の装置。
【請求項３４】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記制御装置は前記共有データを複数のコンテンツプロバイダの証明書を用いて認証し、
前記証明書は、複数のコンテンツプロバイダの共同の署名を含むことを特徴とする請求項３２に記載の装置。
【請求項３５】
前記共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダのキーを用いて暗号化されることを特徴とする請求項２９に記載の装置。
【請求項３６】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダに一致するキーを用いて暗号化されることを特徴とする請求項２９に記載の装置。
【請求項３７】
前記共有データを解読するときに、
前記制御装置は、前記共有データにアクセスするアプリケーションに含まれたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【請求項３８】
前記共有データを解読するときに、
前記制御装置は、前記記録媒体内に格納されたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【請求項３９】
前記共有データを解読するときに、
前記制御装置は、光記録再生装置に格納されたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【請求項１】
記録媒体と関連した共有データをローカルストレージにダウンロードするステップと、
前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスすることを可能にするステップと
を備えることを特徴とする共有データ保護方法。
【請求項２】
前記アクセス情報は、前記アプリケーションのクレデンシャル情報であることを特徴とする請求項１に記載の方法。
【請求項３】
前記クレデンシャル情報は、パーミッション要求ファイルに含まれることを特徴とする請求項２に記載の方法。
【請求項４】
前記パーミッション要求ファイルは、前記アプリケーションを構成するＪＡＲファイル内に存在することを特徴とする請求項３に記載の方法。
【請求項５】
前記クレデンシャル情報は、供与者識別情報、有効期間、ファイル名、署名、およびＣｅｒｔｃｈａｉｎｆｉｌｅｉｄを含むことを特徴とする請求項２に記載の方法。
【請求項６】
前記アプリケーションが前記共有データにアクセスする前に、前記共有データを認証するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項６に記載の共有データ保護方法。
【請求項８】
前記証明書は、前記コンテンツプロバイダの署名を含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項６に記載の方法。
【請求項１０】
前記証明書は、前記複数のコンテンツプロバイダの共同の署名を含むことを特徴とする請求項９に記載の方法。
【請求項１１】
ローカルストレージに記録媒体と関連した暗号化した共有データをダウンロードするステップと、
ローカルストレージ内のデータを前記記録媒体内のデータにバインディングすることによって、前記共有データを含むバーチャルパッケージを生成するステップと、
前記バーチャルパッケージを用いて前記共有データを解読するステップと、
前記解読された共有データを再生するステップと
を備えることを特徴とするローカルストレージを用いた記録媒体再生方法。
【請求項１２】
前記共有データは、前記共有データにアクセスするアプリケーションを実行することによって再生されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記アプリケーションは、前記共有データに対するアクセス情報として前記アプリケーションのクレデンシャル情報を含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記共有データは、前記アプリケーションに含まれたキーを用いて解読されることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記共有データは、前記記録媒体内に格納されたキーを用いて解読されることを特徴とする請求項１１に記載の方法。
【請求項１６】
前記共有データの解読は、光記録再生装置内に格納されたキーを用いて解読されることを特徴とする請求項１１に記載の方法。
【請求項１７】
前記バーチャルパッケージを生成するときに、
前記共有データは前記バーチャルパッケージを生成するために認証されることを特徴とする請求項１１に記載の方法。
【請求項１８】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書内の署名を使用することによって認証されることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記共有データが、複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書内の共同の署名を使用して認証されることを特徴とする請求項１７に記載の方法。
【請求項２０】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダのキーを用いて認証されることを特徴とする請求項１１に記載の方法。
【請求項２１】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダに一致するキーを使用して認証されることを特徴とする請求項１１に記載の方法。
【請求項２２】
記録媒体と関連したダウンロードされた共有データを格納するローカルストレージと、
前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスするように制御する制御装置と
を備えたことを特徴とする共有データ保護装置。
【請求項２３】
前記アクセス情報は、前記アプリケーションのクレデンシャル情報であることを特徴とする請求項２２に記載の装置。
【請求項２４】
前記クレデンシャル情報は、パーミッション要求ファイルに含まれることを特徴とする請求項２３に記載の装置。
【請求項２５】
前記パーミッション要求ファイルは、前記アプリケーションを構成するＪＡＲファイル内に存在することを特徴とする請求項２４に記載の装置。
【請求項２６】
前記制御装置は、前記アプリケーションが前記共有データにアクセスする前に前記共有データを認証することを特徴とする請求項２２に記載の装置。
【請求項２７】
前記共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項２６に記載の装置。
【請求項２８】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダの証明書を用いて認証されることを特徴とする請求項２６に記載の装置。
【請求項２９】
記録媒体と関連したダウンロードされた暗号化された共有データを格納するローカルストレージと、
前記ローカルストレージ内のデータを前記記録媒体内のデータにバインディングすることによって、前記共有データを含むバーチャルパッケージを生成し、前記バーチャルパッケージを用いて前記共有データを解読後に再生する制御装置と
を備えたことを特徴とするローカルストレージを用いた記録媒体再生装置。
【請求項３０】
前記共有データを解読するときに、
前記制御装置は、前記共有データに対する有効なアクセス情報を有するアプリケーションのみが前記共有データにアクセスするように制御することを特徴とする請求項２９に記載の装置。
【請求項３１】
前記アクセス情報は、前記共有データにアクセスする前記アプリケーションのクレデンシャル情報であることを特徴とする請求項３０に記載の装置。
【請求項３２】
前記バーチャルパッケージを生成するときに、
前記制御装置は、前記共有データを認証して、前記バーチャルパッケージを生成することを特徴とする請求項３０に記載の装置。
【請求項３３】
前記共有データが１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記制御装置は、前記共有データを前記コンテンツプロバイダの証明書内の署名を使用して認証することを特徴とする請求項３２に記載の装置。
【請求項３４】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記制御装置は前記共有データを複数のコンテンツプロバイダの証明書を用いて認証し、
前記証明書は、複数のコンテンツプロバイダの共同の署名を含むことを特徴とする請求項３２に記載の装置。
【請求項３５】
前記共有データが、１つのコンテンツプロバイダが提供した記録媒体間で共有されるデータである場合、
前記共有データは、前記コンテンツプロバイダのキーを用いて暗号化されることを特徴とする請求項２９に記載の装置。
【請求項３６】
前記共有データが複数のコンテンツプロバイダ間で共有されるデータである場合、
前記共有データは、複数のコンテンツプロバイダに一致するキーを用いて暗号化されることを特徴とする請求項２９に記載の装置。
【請求項３７】
前記共有データを解読するときに、
前記制御装置は、前記共有データにアクセスするアプリケーションに含まれたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【請求項３８】
前記共有データを解読するときに、
前記制御装置は、前記記録媒体内に格納されたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【請求項３９】
前記共有データを解読するときに、
前記制御装置は、光記録再生装置に格納されたキーを用いて前記共有データを解読することを特徴とする請求項２９に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２００８−５２７５９８（Ｐ２００８−５２７５９８Ａ）
【公表日】平成２０年７月２４日（２００８．７．２４）
【国際特許分類】
【出願番号】特願２００７−５５０２８４（Ｐ２００７−５５０２８４）
【出願日】平成１８年１月２日（２００６．１．２）
【国際出願番号】ＰＣＴ／ＫＲ２００６／０００００２
【国際公開番号】ＷＯ２００６／０７３２５１
【国際公開日】平成１８年７月１３日（２００６．７．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５９６０６６７７０）エルジー エレクトロニクス インコーポレーテッド (384)
【Ｆターム（参考）】
【公表日】平成２０年７月２４日（２００８．７．２４）
【国際特許分類】
【出願日】平成１８年１月２日（２００６．１．２）
【国際出願番号】ＰＣＴ／ＫＲ２００６／０００００２
【国際公開番号】ＷＯ２００６／０７３２５１
【国際公開日】平成１８年７月１３日（２００６．７．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５９６０６６７７０）エルジー エレクトロニクス インコーポレーテッド (384)
【Ｆターム（参考）】
[ Back to top ]