情報アクセス管理方法および装置および情報記録媒体
【課題】ＡＡＣＳ等のアクセス管理方式を著作権保護されたフォントなどを含む高度機密情報の保護に利用する。
【解決手段】記録先がＡＡＣＳに対応したメディアであるか否かをチェックする（ＳＴ５００）。記録先がＡＡＣＳ対応メディアである場合は（ＳＴ５００Ｙ）、著作権付フォント等を用いたメニュー画面を作成し（ＳＴ５０２）、著作権付きのフォント等をＡＡＣＳで暗号化してメディアに記録する（ＳＴ５０４）。一方、記録先がＡＡＣＳ非対応メディアである場合は（ＳＴ５００Ｎ）、著作権付フォント等を用いないで見かけが別のメニューを作成する（ＳＴ５１０）。
【解決手段】記録先がＡＡＣＳに対応したメディアであるか否かをチェックする（ＳＴ５００）。記録先がＡＡＣＳ対応メディアである場合は（ＳＴ５００Ｙ）、著作権付フォント等を用いたメニュー画面を作成し（ＳＴ５０２）、著作権付きのフォント等をＡＡＣＳで暗号化してメディアに記録する（ＳＴ５０４）。一方、記録先がＡＡＣＳ非対応メディアである場合は（ＳＴ５００Ｎ）、著作権付フォント等を用いないで見かけが別のメニューを作成する（ＳＴ５１０）。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、暗号鍵等を利用した情報アクセス管理に関する。特に、光ディスク等の情報記録媒体に記録する高度機密情報（Highly Confidential Data）の保護に関する。
【背景技術】
【０００２】
近年、ディスクメディア等に記録されたコンテンツにアクセスするデジタル機器が種々開発されている。このような機器でアクセスされるディスクに記録されたデータには、不正アクセスあるいは違法コピーを防止するため、暗号化処理が施されている。この暗号化されたデータには、ＤＶＤ（Digital Versatile Disc）では主にＣＳＳ（Content Scramble System）方式に準拠した暗号化方式が採用されている。
【０００３】
一方、より高度な暗号化方式として、ＡＡＣＳ（Advanced Access Content System）が提案されている（特許文献１）。このＡＡＣＳ方式を採用する場合、例えばセットメーカーは、ライセンシーが持つ鍵マトリクスから特定の鍵セットを入手し、異なる組み合わせの鍵を暗号化して、個々の機器に組み込んでいる。
【０００４】
ＡＡＣＳでは、コンテンツを正当に記録再生する機器毎に付与されたデバイスキーとランダムに発生させた乱数とにより、複数のキーそれぞれを暗号化して乱数とともにキーファイルに登録して、メディアに記録する。コンテンツを再生する場合には、このキーファイルに登録されている暗号化キーを、乱数と再生しようとする機器のデバイスキーとで復号化する。そして、復号化されたキーでコンテンツを復号化して、コンテンツを再生する。
【０００５】
ＡＡＣＳ方式を採用するHD_DVD Video Recording Formatでは、HD_DVD−Videoプレーヤで再生できるInteroperable Contentの記録が可能となっている。このInteroperable Contentで使用するフォント（著作権保護されたベクターフォント等）を用いると、高精細で美しく多彩なメニューを作成できる（特許文献２）。
【特許文献１】特開２００５−３９４８０号公報
【特許文献２】特開２００５−３３２５２１号公報（段落００３６〜００３８参照）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献２で述べているアドバンスドコンテンツは市販パッケージメディアのようなＲＯＭメディアに記録することを前提としており、記録系のメディアにアドバンスドコンテンツを作成する際に著作権の付いたフォントなどのリソースデータをどのように扱うかについては、配慮されていない。特許文献１でも著作権付きリソースデータの保護についての配慮に欠けている。
【０００７】
この発明の課題の１つは、ＡＡＣＳ等のアクセス管理方式を、著作権保護されたフォントなどを含む高度機密情報（Highly Confidential Data）の保護に利用することである。
【課題を解決するための手段】
【０００８】
この発明の一実施の形態に係る情報アクセス管理は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（メニューあるいはビデオプログラム中の各画面等）の情報を情報記録媒体（１００）に適宜記録する際に用いられる。この管理においては、情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かがチェックされる（ＳＴ５００）。情報記録媒体（１００）が前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（例えばメニュー画面：図１３の画面５２ａ等）を作成し（ＳＴ５０２）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する（ＳＴ５０４）。一方、情報記録媒体（１００）が前記所定の暗号化方式（ＡＡＣＳ）に対応していないメディアである場合は（ＳＴ５００Ｎ）、前記資源情報の前記部分（著作権付フォント等）を用いないで前記所定画面（例えば見かけが別のメニュー：図１３の５２ｃ等）を作成するか、または前記所定画面（メニュー）を作成しない（ＳＴ５１０）。
【発明の効果】
【０００９】
使用するメディアがＡＡＣＳ非対応の場合は著作権保護されたリソース（フォント等）をそのメディアに記録しない（著作権保護されたリソースを除いた形の記録はできる）ので、著作権保護されたリソース（フォント等）の不正な流用を防ぐことができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照してこの発明の種々な実施の形態を説明する。光ディスク等の情報記録媒体に対して情報を記録する場合、情報を暗号化して記録することが要求される場合がある。その場合、例えば著作権保護されたコンテンツを暗号鍵で暗号化して暗号化コンテンツとし、さらに暗号化に用いた前記暗号鍵を秘匿させるため、他の暗号鍵で暗号化して暗号化鍵としている。そして前記暗号化鍵と暗号化コンテンツを一緒に記録媒体に記録し、違法コピー防止している。
【００１１】
現在、急速にマーケットを拡大しているＤＶＤ（Digital Versatile Disc）では、著作権保護に関して、次のような対応が図られている。即ち、ＤＶＤビデオでは、ＤＶＤ ＣＣＡ（DVD Copy Control Association）がライセンスしているＣＳＳ（Content Scramble System）方式を利用しており、ＤＶＤオーディオではＣＰＰＭ（Content Protection for Prerecorded Media）方式を利用している。また、記録メディアに記録されるコンテンツの著作権保護方式ではＣＰＲＭ（Content Protection for Recordable Media）方式が利用されている。ＣＰＰＭ方式とＣＰＲＭ方式のライセンスは、特定の団体（例えば４Ｃ Ｅｎｔｉｔｙ， ＬＬＣと称される団体）が行っている。
【００１２】
一方では、更に高精細映像や高品質多チャネル音声信号などを記録再生可能とする、大容量の次世代ＤＶＤ等の開発が進められている。このような次世代記録媒体へ高品位著作物を記録する場合の著作権保護方式は、従来以上にセキュリティー能力を高めた方式の導入が要求されている。その具体例として、ＡＡＣＳ（Advanced Access Content System）方式がある。以下、ＨＤ＿ＤＶＤ−ＶＲ（High Density Digital Versatile Disc Video Recording）フォーマットで採用するコンテンツ保護技術であるＡＡＣＳにおけるコンテンツ鍵の管理方法を説明する。
【００１３】
従来のＣＰＲＭ方式では、ディスクの中に存在するメディアキーブロック（ＭＫＢ）とメディアＩＤ（Media ID）を用いて暗号鍵を生成してコンテンツを暗号化していた。一方、ＡＡＣＳ方式では、ディスク内のコンテンツは共通の１つの暗号鍵ではなく、コンテンツ毎の暗号鍵によって暗号化されている。
【００１４】
図１はメディア１００内のデータの構成例を示す図である。この例では、同一のメディア内には、ＭＰＥＧ２−ＰＳなどの形式のコンテンツであるビデオオブジェクト（ＶＯＢ）、ＭＰＥＧ２−ＴＳなどの形式のコンテンツであるストリームオブジェクト（ＳＯＢ）をそれぞれ規格上最大１９９８個保存することが可能となっている。従来の方式ではこれらの全オブジェクトで１つの暗号鍵を使用しているが、ＡＡＣＳ方式ではコンテンツ毎にそれぞれ異なる暗号鍵によって暗号化がなされている。そしてこのコンテンツごとの暗号鍵はタイトルキーファイル（ＴＫＦ）に記憶されている。即ち、ビデオオブジェクト用タイトルキーファイルとストリームオブジェクト用タイトルキーファイルが設けられ、それぞれのタイトルキーファイルには暗号化されたタイトルキー（Encrypted Title Key：略してＥ−ＴＫ）が最大１９９８個保存可能となっている。
【００１５】
図２は、メデイア１００に記録された暗号化コンテンツ（Encrypted Contents）を復号する処理を説明する図である。図２には、コンテンツなどを記録したメディア１００に格納されている情報と、情報記録再生装置２００に設けられた処理機能及びそれらの間のデータの流れを表している。
【００１６】
HD_DVD Video Recording Formatで採用するコンテンツ保護技術はＡＡＣＳである。ＡＡＣＳにおけるコンテンツ鍵の管理方法を図２を用いて説明する。ＡＡＣＳ処理で使用するディスクの上書き換え不能な領域に記録されているデータには、
・Media ID
・Lead-in MKB
がある。
【００１７】
一方、ＡＡＣＳ処理で使用するものであってディスク１００上でファイルとして存在するデータには、
・Read Write MKB
・Title Key File
・Usage Rule File
がある。またTitle Key Fileの先頭アドレスのプロテクト領域にはBinding Nonceという乱数を基にしたデータが記録されている。
【００１８】
ＡＡＣＳでは、コンテンツを暗号化するための「タイトル鍵（Ｋｔ）」を生成する処理は、大きくいって、次の順番で実行される。すなわち、まずLead-in MKBとRead Write MKBのバージョンの新しいほうを使用してＭＫＢ処理を行う。この処理で生成される鍵を「メディア鍵（Ｋｍ）」と呼ぶ。このメディア鍵ＫｍとBinding Nonceを入力としてProtected Area Key処理（Ｋｐａ処理）を行うと「プロテクテッドエリアキー（Ｋｐａ）」が生成される。このＫｐａとUsage Rule FileのデータとTitle Key Fileのデータを入力としてTitle Key処理（ＴＫ処理）を行うことで、Title Key Fileに記載されている暗号化されたタイトル鍵（Encrypted Title Key）を本来のタイトル鍵Ｋｔに変換することができる。
【００１９】
ＭＫＢとはMedia Key Blockと呼ばれるデータであり、メディア鍵Ｋｍが暗号化されて記録されたものである。またＭＫＢには不正機器の情報も記録されており、不正機器はＫｍを取り出すことができないようになっている。不正機器の情報は更新されるため、ＭＫＢも新しいものを使うようにする必要がある。このためＨＤ＿ＤＶＤのＡＡＣＳでは、メディアのLead-in Areaに埋め込まれているLead-in MKB、ディスク上にファイルとして保存されているRead Write MKB、及び機器自体が内部の不揮発メモリに保存するDevice MKBの３種類のＭＫＢが存在し、このうちもっとも新しいＭＫＢをRead Write MKBに上書きすることが定められている。但し、ＭＫＢが新しいものに更新されるということはＫｍの値が変更されることになるため、Ｋｍ以降のすべての鍵情報（Ｋｐａ、Ｋｔ等）は再生成する必要がある。
【００２０】
なお、図２の情報記録再生装置２００には、制御部２１０、読み出し部２２０、書込み部２３０が設けられている。制御部２１０は、図２に示す情報記録再生装置２００の各機能及び各処理動作を制御する。読出し部２２０は、メディア１００よりデータを情報記録再生装置２００に読み込む。書込み部２３０は、情報記録再生装置２００内のデータをメディア１００に書き込む。
【００２１】
メディア１００の読み取り専用リードイン領域にはLead-in MKB（Media Key Block）が格納され、書き換え可能領域であるUser Data AreaにはRead Write MKBが格納されている。ＭＫＢは、コンテンツ暗号化のベース鍵であるメディアキー（Ｋｍ）を、情報記録再生装置２００に秘密鍵として設置されるデバイスキー（Ｋｄ）の集合体で暗号化して数学的体系を整えた、「メディアキーブロック」である。
【００２２】
図２のＳ１０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、バージョンの新しいＭＫＢをMedia MKBとして読み出す。そして、Ｓ１１において情報記録再生装置２００で保存されているデバイスキーセット（Set of Device KeysあるいはDevice Key Set）とMedia MKBとを用いてＭＫＢ処理を行う。このデバイスキーセットは、複数のデバイスキーＫｄで構成されている。
【００２３】
ここで、ＭＫＢにはプロテクテッドエリアキー（Ｋｐａ）を生成するための情報が暗号化されて保存されているが、そのほかに、リボーク情報（Revoke Information：取消情報あるいは無効化情報）も含まれている。即ち、あるデバイスキーセットにセキュリティホールが存在し、ライセンサが該当するデバイスキーＫｄを使用禁止としたときは、該当するデバイスキーＫｄに関するリボーク情報が記載される。このリボーク情報によって、該当するデバイスキーＫｄを持ったデバイスでは暗号を解くことができなくなる（つまりリボークされた情報を再生できなくなる）。不正機器の情報は時間経過に伴い漸次更新されるため、ＭＫＢも新しいもの（最新の更新されたＭＫＢ）を使うようにする必要がある。そのため上述のようにバージョンの新しいほうをMedia MKBとして使用する。
【００２４】
このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。図２のＳ１２において、生成されたメディア鍵を検証する。生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなして、ＡＡＣＳに関する処理を終了する。
【００２５】
一方、タイトルキーファイル（ＴＫＦ）の先頭アドレスのプロテクト領域には、Binding Nonceというファイルと結合した「乱数を基にしたデータ」が記録されている。このBinding Nonceは、例えば、ＰＣ（パソコン）のWrite命令ではコピー不可であり、ＡＡＣＳで定義された命令のみによってコピーが可能である。このように、ＡＡＣＳのライセンスを受けたハードでのみコピー可能とすることで、ＰＣを介した情報の流出を防いでいる。
【００２６】
次に、図２のＳ１３において、ＫｍとBinding Nonceを用いて、暗号処理であるＫｐａ処理を実施する。このＫｐａ処理には、暗号アルゴリズムであるＡＥＳ（Advanced Encrypted Standard）−Ｇを用いる。このＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。
【００２７】
次に、Ｋｐａからタイトルキー（ＴＫ）を生成するための、タイトルキー処理について説明する。この処理は図２のＳ１４で示されている。タイトルキーファイル（ＴＫＦ）には、ＴＫＦＮ（Title Key File Nonce）という乱数データが記憶されている。このＴＫＦＮは暗号化処理（後述）において、タイトルキーを暗号化するために用いられた乱数データである。また、ディスク１００にはコンテンツの利用規則を記述したUsage Rule Fileが備わっている。このUsage Rule Fileには、複数の使用規則それぞれについて、その使用規則を適用するか否かの情報（Usage Rule）が、０または１のＢｉｔ情報として記述されている。
【００２８】
さらに、ディスク１００のリードイン領域より内側に設けられた読取専用のバーストカッティングエリア（ＢＣＡ）には、Media IDが記録されている。Media IDは、メディア毎に付加されている固有ＩＤである。そして、書き換え可能領域であるユーザデータエリアには、Media IDを用いた改ざん防止コードＭＡＣ（Message Authentication Code）であるMedia ID MACが格納されている。
【００２９】
図２のＳ１４に示すタイトルキー処理では、上述のUsage Ruleを処理した結果とＫｐａとＴＫＦＮとに基いてＡＥＳ−Ｄのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫ）を復号してタイトルキー（ＴＫ）を生成する。なお、この際ＢＣＡに格納されているMedia IDを用いて生成したＭＡＣと、ディスクに格納されているMedia ID MACとを比較して改ざんがなされていないことが検証される。図２のＳ１５において、このようにして生成されたＴＫと暗号化されたコンテンツ（Encrypted contents）とをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成し、Ｓ１６において、このコンテンツキーを用いて暗号化されたコンテンツ（Encrypted contents）を復号してコンテンツを生成する。
【００３０】
図３は、コンテンツを暗号化してHD_DVD-R/RW/RAM等の光ディスク１００に記録する処理を説明する図である。なお、使用する用語は図２と同一であるため、重複する説明は省略する。図３のＳ２０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、バージョンの新しいＭＫＢをMedia MKBとして読み出す。次に、Media MKBと、情報記録再生装置２００が保有するDevice MKBとのバージョンを比較する。Device MKBのバージョンの方が新しい場合は、Ｓ２１において、ＭＫＢ更新処理を起動しRead Write MKBにDevice MKBの値を更新する。但し、Media MKBのバージョンの方が新しい場合にDevice MKBの値を更新するかどうかは、セット仕様となる。そして、図３のＳ２２において、情報記録再生装置２００で保存されているデバイスキーセットとMedia MKBとを用いてＭＫＢ処理を行う。このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。
【００３１】
図３のＳ２３において、生成されたメディア鍵を検証し、生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなしてＡＡＣＳに関する処理を終了する。一方、図３のＳ２４において、ＫｍとBinding Nonceとを用いて、暗号処理であるＫｐａ処理を実施する。ＡＥＳ−Ｇを用いたＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。
【００３２】
図３のＳ２５において、タイトルキー（ＴＫ）とコンテンツとをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成する。そして、Ｓ２６において、このコンテンツキーを用いてコンテンツを暗号化してEncrypted contentsを生成し、メディア１００に記録する。また、Ｓ２７において、Media IDとＴＫとを用いてＭＡＣを生成し、メディア１００にMedia ID MACとして格納する。一方、Ｓ２８において、タイトルキーを暗号化するために用いられる乱数データを生成し、Title Key File Nonceとしてメディア１００に記録する。そして、Ｓ２９において、Usage Ruleをハッシュ処理（公知技術）した結果とＫｐａとＴＫとに基いてＡＥＳ−Ｅのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫ）を生成してメディア１００に格納する。なお、Usage RuleはＳ３０においてメディア１００に記録する。
【００３３】
上述のように、コンテンツの暗号化、復号化においてはタイトルキー等が重要な役割を担っている。しかし、このタイトルキー等はRead/Write可能なファイルとしてメディア１００に記録されているため、メディア表面が例えば指紋などで汚れた場合、簡単にコンテンツの読み出し不能の状態に至るおそれがある。そこで、ＡＡＣＳではこれらのタイトルキー等の情報を格納したタイトルキーファイル（ＴＫＦ）についてバックアップが図られている。
【００３４】
図４は、タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造例を示す説明図である。なお、このバックアップ方法の説明では、タイトルキーファイルをＴＫＦ１とし、バックアップファイルとしてのタイトルキーファイルをＴＫＦ２，ＴＫＦ３と表す。なお、ＴＫＦ１〜３は、メディア１００に格納している。
【００３５】
それぞれのタイトルキーファイル（ＴＫＦ１〜３）は、Binding Nonce１〜３（ＢＮ１〜３）と、Title Key File Generation１〜３（ＴＫＦＧ１〜３）と、Title Key File Nonce〜３（ＴＫＦＮ１〜３）と、Encrypted Title Key１〜３（暗号化タイトルキーＥＴＫ１〜３）とをそれぞれ登録した構成となっている。ここで、Binding Nonce１〜３（ＢＮ１〜３）は、上述のように自身のタイトルキーファイルの暗号化に用いられる乱数データである。Title Key File Generation１〜３（ＴＫＦＧ１〜３）は、タイトルキーファイル（ＴＫＦ１〜３）それぞれの変更回数を表している。Title Key File Nonce〜３（ＴＫＦＮ１〜３）は、自身のタイトルキーファイルまたはバックアップファイル以外のファイルの暗号化タイトルキー（ＥＴＫ１〜３）を生成するための乱数である。
【００３６】
Encrypted Title Key１〜３（暗号化タイトルキー：ＥＴＫ１，ＥＴＫ２，ＥＴＫ３）は、次の（eq.1）〜（eq.3）式で示される：
ＥＴＫ１＝f（ＴＫ，ＢＮ１，ＴＫＦＮ３） …（eq.1）
ＥＴＫ２＝f（ＴＫ，ＢＮ２，ＴＫＦＮ１） …（eq.2）
ＥＴＫ３＝f（ＴＫ，ＢＮ３，ＴＫＦＮ２） …（eq.3）
ここで、ＴＫは暗号化されていない平文のタイトルキーを示し、暗号処理関数fは、第１パラメタ（ＴＫ）に第２パラメタ（ＢＮ１〜３）と第３パラメタ（ＴＫＦＮ１〜３）を暗号鍵として暗号処理を施すことを示している。暗号処理fには、たとえばＡＥＳ（Advanced Encryption Standard）などの公知の暗号アルゴリズムを用いればよい。
【００３７】
すなわち、ＴＫＦ１は、ＴＫＦ３と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ１）と、関連づけられたＴＫＦ３の（ＴＫＦＮ３）とで暗号化したものとなっている。また、ＴＫＦ２は、ＴＫＦ１と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ２）と、関連づけられたＴＫＦ１の（ＴＫＦＮ１）とで暗号化したものとなっている。さらに、ＴＫＦ３は、ＴＫＦ２と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ３）と、関連づけられたＴＫＦ２の（ＴＫＦＮ２）とで暗号化したものとなっている。
【００３８】
このようにタイトルキーファイルＴＫＦ１と各バックアップファイルＴＫＦ２，ＴＫＦ３は、互いに他のファイルと関連付けられており、暗号化タイトルキー（Ｅ−ＴＫ１，Ｅ−ＴＫ２，Ｅ−ＴＫ３）は、自己のファイルに登録された（ＢＮ１，ＢＮ２，ＢＮ２）と、関連づけられている他のファイルに登録されている（ＴＫＦＮ１，ＴＫＦＮ２，ＴＫＦＮ３）とでタイトルキー（ＴＫ）を暗号化したものとなっている。
【００３９】
上記のようにＴＫＦを３つ保存し、ＴＫＦＮを別ファイルに保存することにより、１つのＴＫＦがデータ破損などにより壊れてしまっても、残り２つのＴＫＦのデータから、壊れたデータを復元できる。
【００４０】
なお、前述したBinding Nonceを特殊なドライブ用コマンドでしか読み書きできないデータとしておくことにより、不正コピーを防止できる。すなわち、仮にＴＫＦがコピーされてもそれに付随するBinding Nonceはコピーされないため、悪意のある第三者による不正な暗号化／復号化行為を防ぐことができる。
【００４１】
なお、タイトルキーファイルと各バックアップファイルの他のファイルのＴＫＦＮとの関連づけは、上記（eq.1）〜（eq.3）式に限定されるものではなく、（eq.1）〜（eq.3）式以外のパターンでタイトルキーファイルとバックアップファイルのＴＫＦＮと関連付けるように構成してもよい。
【００４２】
図５、図６、図７を参照しつつ、ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを詳細に説明する。メディア１００上のProtected Area、即ち、Ｅ−ＴＫが格納されているファイルのProtected Areaには、Binding Nonce及びそのバックアップデータが格納されている。また、メディア１００の読取専用エリアにあるＢＣＡ（Burst Cutting Area）にはMedia IDが記録され、リードイン領域（後述する図１１では１１０）にはLead-in MKBが記録されている。
【００４３】
メディア１００上のユーザデータエリアには、ビデオオブジェクト（ＶＯＢ）および／またはストリームオブジェクト（ＳＯＢ）のCopy Protection Pointerに関する情報である管理情報が格納されている。また、ユーザデータエリアには、Read Write MKB、暗号化されたタイトルキー（Ｅ−ＴＫ）、Media ID MAC、Usage Rule及びそれらのバックアップファイルが格納されている。さらに、ユーザデータエリアは、暗号化されたコンテンツが最大１９９８個まで格納が可能となっている。
【００４４】
図８は、暗号化されたタイトルキーファイル（Ｅ−ＴＫＦ）の構造を示している。なお、図８はストリームオブジェクト（ＳＯＢ）についてのＥ−ＴＫＦの構造であるが、ビデオオブジェクト（ＶＯＢ）についても同様の構造である。バイト位置でいって０〜１５バイトには、タイトルキーファイルを特定するための固定情報（ＳＴＫＦ＿ＩＤ、ＨＲ＿ＳＴＫＦ＿ＥＡ）が記載され、３２〜３３バイトには、ＡＡＣＳのバージョン番号が記載されている。そして、１２８〜１４３バイトには、Title Key File Generationが格納され、１４４〜１５９バイトにはTitle Key File Nonceが格納されている。また、１６０〜６４０９５バイトには、Title Key Information（ＫＴＩ）として、暗号化されたタイトルキー（Ｅ−ＴＫ）とMedia ID MACとが１９９８組記載されている。
【００４５】
それぞれのコンテンツはこの１９９８個のタイトルキーのうちの１つの鍵を使って暗号化されている。但し、１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは０という数値をＴＫ処理で暗号化したものを記述する。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。上述のようにタイトルキーファイルはバックアップ用に合計３つのファイルを備えている。そしてこの３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。
【００４６】
次にタイトルキーファイルの更新方法について説明する。ＡＡＣＳが適用されるメディアの種類には、リライタブルメディアとライトワンスメディアがある。リライタブルメディアでは、例えば、新しいコンテンツが追加記録される毎に新しいタイトルキーが追加されるため、タイトルキーファイル中の全タイトルキーを新しいＫｐａを用いて再暗号化する必要がある。即ち、タイトルキーファイルの更新が必要となる。
【００４７】
ところで、タイトルキーファイルのプロテクト領域には、Binding Nonceという乱数を基にした数値が記載されているが、このBinding Nonceは不正な暗号解除を防止するために使用されるものであり、従って、Binding Nonceもタイトルキーファイルを更新する都度、更新される。
【００４８】
一方、ライトワンスメディアでは、タイトルキーファイルを更新すると毎回新しいアドレスにタイトルキーファイルが書き込まれることになる。このためBinding Nonceの書き込まれるアドレスも毎回異なる。しかし、ＡＡＣＳではBinding Nonceは同一個所に上書きすることが求められているため、ライトワンスメディアの場合は、タイトルキーファイルの更新を行わないようにしなければならない。従って、リライタブルメディアとライトワンスメディアでは、タイトルキーファイルの更新条件が異なることになる。
【００４９】
図８のTitle Key Fileの中には１９９８個の暗号化されたタイトル鍵（Encrypted Title Key）が記録されている。コンテンツはこの１９９８個のうちの１つの鍵を使って暗号化されている。１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは“０”という数値をＴＫ処理で暗号化したものを記述することになっている。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。Title Key Fileはタイトル鍵を保存するものであり、メディア上の欠陥等により読めなくなるとコンテンツの再生がまったく不能になる。このためバックアップ用に３つのファイルに書き込んでいる。この３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。
【００５０】
メディア１００上のTitle Key Fileが書き込まれているアドレスのプロテクト領域に、Binding Nonceという乱数を基にした数値を記録している。プロテクト領域とはＡＡＣＳ専用の特殊コマンドでのみ読み書きができる領域であり、この部分にＫｐａを構成する要素を記録しておくことで、パソコン等を使った不正な暗号解除を防ぐことができる。
【００５１】
Title Key File内のタイトル鍵は、プロテクテッドエリアキーとBinding Nonceの組み合わせてＴＫ処理を行うことで暗号化している。このとき、Title Key File#1の暗号化にはTitle Key File#2のBinding Nonceを使い、Title Key File#2の暗号化のBinding Nonceを使う、というようにしている。こうすることにより、３つのTitle Key Fileのうち１つが破損してしまっても、他の２つのファイルを用いることによって復元ができる。このようにBinding Nonceはタイトル鍵の暗号に用いているものであるので、Title Key Fileを更新する都度更新する。
【００５２】
一方、Binding Nonceはファイルが書き込まれるアドレスに依存しており、HD_DVD-R等のライトワンスメディアの場合、Title Key File自体が毎回新しいアドレスに保存されることになり、Binding Nonceの書き込まれる位置も一箇所ではなくなる。しかしＡＡＣＳではBinding Nonceは同一箇所に上書きすることが求められているので、ライトワンスメディアの場合はTitle Key Fileの更新を行わないようにする。
【００５３】
Title Key Fileには１９９８個のタイトル鍵を保存することが出来る。これはビデオオブジェクト（ＶＯＢ）及びストリームオブジェクト（ＳＯＢ）の個数と一致しており、ビデオオブジェクト毎にタイトル鍵（Ｋｔ）を変えることを前提としている。これは、例えばそのディスクから他のメディアにコンテンツをムーブする場合、使用しているタイトル鍵を消去しないと不正コピーができる抜け穴が残ってしまうためである。タイトル鍵を削除すると、同じタイトル鍵を共用している他のオブジェクトが復号できなくなるので、極力オブジェクトごとに異なる鍵を割り当てる必要がある。このため、録画再生装置においては、1回の録画処理毎にタイトル鍵を新規に生成し、そのタイトル鍵によってビデオオブジェクト及びストリームオブジェクトを暗号化する。
【００５４】
一方、特にストリームオブジェクト（ＳＯＢ）による録画の場合、記録対象のデジタル放送の内容によってストリームオブジェクトを動的に分割する必要がある。具体的には番組の境界で音声ストリームの個数が変わるなどストリームオブジェクト（ＳＯＢ）の構成要素が変わった場合は、自動的にそこでＳＯＢを分割する。このような場合、そこでタイトル鍵を切り替えるのは事実上不可能である（タイトル鍵を切り替えようとすると、新たな鍵の生成に時間を要するため、分割後のＳＯＢの録画を開始する際その先頭部分の録画が欠けてしまう）。このような場合は同じタイトル鍵を使った暗号を引き続き行う。
【００５５】
なお、ディスクがライトワンスメディア（上書きできないメディア）である場合はTitle Key Fileの更新ができないため、録画開始時に鍵を生成する処理において、既に存在するタイトル鍵を用いることになる。
【００５６】
図９は、メディア１００としてリライタブルメディア（HD_DVD-RW/RAMあるいはHDD等）を用いる場合において、リライタブルメディアのタイトルキーファイルの更新手続きを示すフローチャートである。従って、リライタブルメディアには、既にタイトルキーファイルが生成されて書き込まれている。なお、図９に示す処理動作は、情報記録再生装置２００の制御部２１０（あるいは後述する図１３のＡＡＣＳ処理部２１０ａのファームウエア）により実現される。
【００５７】
例えばユーザが情報記録再生装置２００の電源をＯＮし、図９のＳ４０においてリライタブルメディアを挿入すると、ＭＫＢ処理（Ｓ４１）とＴＫＦ読み込み処理（Ｓ４２）が一括して実行される。ＭＫＢ処理（Ｓ４１）では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理（Ｓ４２）では、メディアにあるタイトルキーファイルをＳＤＲＡＭ（後述する図１３の２２など）上に展開する。
【００５８】
そして、Ｓ４３、Ｓ４４において、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの更新を行うかどうかを判断する。即ち、以下の３つの条件のうちの少なくとも１つが満たされたときのみ、タイトルキーファイルを更新する。
【００５９】
（１）コンテンツの記録、削除が行われた場合
コンテンツの記録、削除が行われると、タイトルキーファイル内のEncrypted Title Keyが新たに追加、削除される。そのため、タイトルキーファイルを更新する。
【００６０】
（２）ＭＫＢが更新された場合
例えば、情報記録再生装置２００の内部で保持しているＭＫＢであるDevice MKBのバージョンがRead Write MKBのバージョンよりも新しい場合、Device MKBの値をRead Write MKBにコピーしてDevice MKBのメディア鍵（Ｋｍ）が変更される。このため、タイトルキーファイルを更新してタイトルキーの再暗号化を行う。
【００６１】
（３）３つのTitle Key File Generationの１つだけが異なる場合
上述のように３つのタイトルキーファイルの内の１つが破損していることになる。そのため、正常な残りの２つのタイトルキーファイルを用いて破損したタイトルキーファイルを修復（更新）する。すなわち、上述の３つの条件のうちの少なくとも１つが成立する場合は（Ｓ４４Ｙ）、タイトルキーファイルの更新を行う（Ｓ４５）。上述の３つの条件の全てが成立しない場合は（Ｓ４４Ｎ）、タイトルキーファイルを更新せずに処理を終了する（Ｓ４６）。
【００６２】
図１０は、メディア１００としてライトワンスメディア（片面１層のHD_DVD-Rあるいは片面２層のHD_DVD-R:DL等）を用いる場合において、ライトワンスメディアのタイトルキーファイルの書込み手続きを示すフローチャートである。なお、図９と同様に図１０に示す処理動作は、情報記録再生装置２００の制御部２１０（あるいは図１３のＡＡＣＳ処理部２１０ａ）により実行できる。
【００６３】
例えばユーザが情報記録再生装置２００の電源をＯＮし、図１０のＳ５０においてライトワンスメディアを挿入すると、ＭＫＢ処理（Ｓ５１）とＴＫＦ読み込み処理（Ｓ５２）が一括して実行される。ＭＫＢ処理（Ｓ５１）では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理（Ｓ５２）では、メディアにあるタイトルキーファイルをＳＤＲＡＭ（図１３の２２など）上に展開する。
【００６４】
そして、Ｓ５３、Ｓ５４において、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの書込みを行うかどうかを判断する。即ち、以下の２つの条件が満たされれば、タイトルキーファイルを書き込む。
【００６５】
（１＊）コンテンツの記録が行われた場合
（２＊）ディスクにタイトルキーファイルが記録されていなかった場合。
【００６６】
ＡＡＣＳではTitle Key Fileを同一箇所に上書きすることが求められているため、ライトワンスメディアの場合は、（１＊）と（２＊）の条件を同時に満たしたときにのみTitle Key Fileを書き込む。そうする理由を以下に述べる。
【００６７】
（１＊）の条件のみでは、コンテンツの記録が行われる度に書き込み要求が起こるため、同一箇所に上書き不可能なライトワンスメディアでは問題となる。（２＊）の条件のみでは、ディスクにコンテンツを記録していない状態では、有効なコンテンツキーは生成されていないため、無効なEncrypted Title KeyのみのTitle Key Fileとなり問題となる。（１＊）と（２＊）の条件を共に満たす場合には、ディスクにTitle Key Fileが記録されていない状態で記録が行われたときに書き込むこととなるため、有効なEncrypted Title Keyが１つだけ生成されたTitle Key Fileが記録されることになる。
【００６８】
上述の２つの条件がともに成立する場合は（Ｓ５４Ｙ）、タイトルキーファイルをディスクに書き込む（Ｓ５５）。上述の２つの条件が全て成立しない場合は（Ｓ５４Ｎ）、タイトルキーファイルの書き込みを行わずに処理を終了する（Ｓ５６）。
【００６９】
以上説明した実施の形態によれば、メディア種別ごとにタイトルキーファイルを書き込む条件を設け、その条件に合致するときのみにディスクに書き込む。この条件によれば、リライタブルメディアの場合は無駄にTitle Key Fileを更新することがなくなり、ディスクに書き込む回数を削減することができる。ライトワンスメディアの場合は、問題のあるTitle Key Fileを書き込こんでしまうことを排除することができる。
【００７０】
図１１は、この発明の一実施の形態に係るデータ構造例を説明する図である。RecordableあるいはRe-writableな情報記憶媒体の代表例として、ＤＶＤディスク（波長650nm前後の赤色レーザあるいは波長405nm以下の青紫ないし青色レーザを用いた、単記録層または複数記録層の、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、ＤＶＤ−ＲＡＭ等）１００がある。このディスク１００は、図１１に示すように、ファイルシステムが入っているボリューム／ファイル構造情報領域１１１とデータファイルを実際に記録するデータ領域１１２を含んで構成されている。上記ファイルシステムは、どのファイルがどこに記録されているかを示す情報で構成されている。
【００７１】
データ領域１１２は、一般のコンピュータが記録する領域１２０、１２２と、オーディオビデオデータ（ＡＶデータ）を記録する領域１２１を含んでいる。ＡＶデータ記録領域１２１は、ＡＶデータの管理をするためのビデオマネージャファイル（VMGまたはHDVR_MG）があるＡＶデータ管理情報領域１３０と、DVD-Video（ROM Video）規格に準じたオブジェクトデータのファイルが記録されるROM_Videoオブジェクト群記録領域１３１と、ビデオレコーディング（ＶＲ）規格に準じたオブジェクトデータ（ESOBS：Extended Video Object Set）のファイル（ＶＲＯファイル）が記録されるＶＲオブジェクト群記録領域１３２と、デジタル放送に対応したオブジェクトが記録されているストリームオブジェクトデータ（ESOBS：Extended Stream Object Set）ファイル（ＳＲＯファイル）が記録される記録領域１３３を含んで構成されている。なお、ＳＲＯファイルのためのレコーディング規格は、適宜、ストリームレコーディング（ＳＲ）規格と表記する。
【００７２】
図１２は、この発明の一実施の形態に係るファイル構造例を説明する図である。DVD_HDVRディレクトリは、図１２に示すように、HD_DVD-VRフォーマットの管理情報ファイルであるHR_MANGER.IFO、アナログビデオ入力のオブジェクトファイルであるＶＲＯファイル（最大レートが30.24Mbpsまで許されたEVOBファイル）を含むHDVR_VOBディレクトリ、デジタル放送対応用のＳＲＯファイル（ESOBファイル）を含むHDVR_SOBディレクトリ等を含んで構成されている。また、DVD_HDVRディレクトリと同じルートディレクトリ下のDVD_RTAVディレクトリは、DVD-VRフォーマットの管理情報ファイルであるVR_MANGER.IFO、アナログビデオ入力のオブジェクトファイルであるＶＲＯファイル（最大レートが10.08Mbpsに抑えられた従来DVD-VRのVOBファイル）等を含んで構成されている。
【００７３】
つまり、この実施の形態に係るファイル構造では、HDVRのMPEG2-TSデータファイルもHDVRのMPEG2-PSデータファイルもVRのMPEG2-PSデータファイルも同じルートディレクトリ下でファイル管理されている。例えば、HR_MOVIE.VROにリンクされたショートカットファイルをタイトルサムネールＡ、Ｃとし、VR_MOVIE.VROにリンクされたショートカットファイルをタイトルサムネールＢとし、HR_STRnn.SROにリンクされたショートカットファイルをタイトルサムネールＤとすれば、これらのタイトルサムネールＡ〜Ｄを同じメニュー画面上に表示することができる（図１３のモニタ画面５２ａの表示例参照）。これにより、ユーザは、別々のオブジェクト（MPEG2-PS、MPEG2-TSが混在するオブジェクト）を同じ画面操作環境でメニュー操作できるようになる。
【００７４】
図１３は、この発明の一実施の形態に係る記録再生装置（HD_DVDレコーダ）の構成例を説明するブロック図である。衛星デジタルＴＶ放送、地上デジタルＴＶ放送、および地上アナログＴＶ放送の受信機能を持つTV tuner１０のアナログＡＶ出力は、Video ADC１４およびAudio ADC１６に入力される。外部アナログ入力端子１２からのアナログＡＶ入力もまた、Video ADC１４およびAudio ADC１６に入力される。Video ADC１４でデジタル化されたビデオストリームおよびAudio ADC１６でデジタル化されたオーディオストリームはMPEG Encoder２０に入力される。外部デジタル入力端子１８からのデジタルストリーム（MPEG2-TS等）は、IEEE1394（あるいはHDMI）等のインターフェース１９を介して、MPEG Encoder２０に入力される。図示しないが、TV tuner１０からのデジタルストリーム（MPEG2-TS等）も適宜MPEG Encoder２０に入力される。MPEG Encoder２０は、入力されたMPEG2-TSをパススルーする場合以外は、入力されたストリームをMPEG2-PSにエンコードするか、MPEG4-AVCにエンコードする。
【００７５】
ここで、MPEG2-PSにエンコードする場合としては、DVD-VR規格に基づきMPEG2-PSにエンコードする場合（最大レート10.08Mbps；最大解像度720x480または720x576）と、HD_DVD-VR規格に基づきMPEG2-PSに高レートエンコードする場合（最大レート30.24Mbps；最大解像度1920x1080）と、HD_DVD-VR規格の枠内でMPEG2-PSに低レートエンコードする場合（最大レート10.08Mbps；最大解像度720x480または720x576）がある。
【００７６】
MPEG Encoder２０でエンコードされ（またはパススルーした）ストリームデータは、SDRAM（Synchronous Dynamic Random Access Memory）２２等の高速メモリに一旦バッファリングされる。このSDRAM２２上で、下記の１〜３のストリーム書き換え処理が適宜行われる：
1.AudioがLiner PCMである場合、Audio Packのsub_stream_idの値を書き換える；
2.RDI-PCKの記載内容を書き換える；
3.一度CPRMの暗号を復号し、ＡＡＣＳに再暗号化を行う、もしくはその逆を行う。
【００７７】
SDRAM２２にバッファリングされそこで処理されたストリームデータは、その内容に応じて、所定のタイミングでＨＤＤ１０４かHD_DVD Drive２６かDVD Drive２８に転送される。ＨＤＤ１０４としては大容量ハードディスクドライブ（例えば１ＴＢ）が用いられる。また、HD_DVD Drive２６には青色レーザ（例えば波長λ=405nm）が用いられ、DVD Drive２８には赤色レーザ（例えば波長λ=650nm）が用いられる。
【００７８】
HD_DVD Drive２６およびDVD Drive２８はDrive Unit２４を構成している。Drive Unit２４は、回転駆動系を含めて独立した２基のドライブを備えている場合と、回転駆動系が共通で青色レーザの光ヘッドと赤色レーザの光ヘッドを個別に有するHD_DVD/DVDコンパチブルドライブ（ツインピックアップタイプ）を備えている場合と、回転駆動系および光ヘッドの機構が共通で青色レーザまたは赤色レーザを切替使用する２波長光学系を有する場合（シングルピックアップタイプ）がある。
【００７９】
図１３の実施の形態では、回転駆動系を含めて独立した２基のDrive２６およびDrive２８がある場合を例示している。これらのドライブで使用される情報記憶媒体（青色レーザ用光ディスク１００、赤色レーザ用光ディスク１０２）としては、青色レーザ使用の場合も赤色レーザ使用の場合も、-R/−RW/RAMタイプの光ディスクの他に、+R/+RWタイプの光ディスクが利用可能である。将来的には、ホログラムを利用した大容量光ディスクを用いることも可能である。
【００８０】
HD_DVD Drive２６はHD_DVD-VR規格に基づく記録再生に対応し、DVD Drive２８はDVD-VR規格に基づく記録再生に対応している。DVD Drive２８はさらに、HD_DVD-VR規格に基づきエンコードされたデータであっても、最大レートやビデオ属性等がDVD-VR規格の枠内に収まるMPEG-PSのデータについては、DVD-VR規格のディスク（片面１層のDVD-R/RW/RAM、片面２層のDVD-R、両面各１層のDVD-RAM等）１０２を用いて等速または高速で記録再生することができるように構成されている。（具体例を挙げれば、最大レート10.08MbpsでＨＤＤ１０４に記録されたNTSCのビデオのMPEG2-PSデータは、それがHD_DVD-VR規格に基づきエンコードされたデータであっても、DVD-VR規格のディスク１０２に高速コピー／高速ダビングできるように構成される。言うまでもないが、このHD_DVD-VR規格に基づきエンコードされたMPEG2-PSデータは、HD_DVD-VR規格のディスク１００にも高速コピー／高速ダビングできる。）
HD_DVD Drive２６、DVD Drive２８、および／またはＨＤＤ１０４から再生されたストリームデータは、SDRAM２２を介してMPEG Decoder３０に転送される。MPEG Decoder３０は、転送されてきたストリームに応じて、MPEG2-TSをデコードする機能、MPEG2-PSをデコードする機能、MPEG4-AVCをデコードする機能、その他のデコード機能（例えばHD_DVD-VR規格で定められているVC-1をデコードする機能）を備えている。MPEG Decoder３０でデコードされたビデオデータ（MPEG2-TSまたはMPEG2-PS）はVideo DAC３２により標準画質または高精細画質のアナログビデオ信号に変換されてVideo Out端子３６から出力される。また、MPEG Decoder３０でデコードされたオーディオデータはAudio DAC３４によりアナログオーディオ信号に変換されてAudio Out端子３８から出力される。さらに、デコードされたデータがMPEG2-TSの場合は、適宜、IEEE1394（あるいはHDMI）等のインターフェース３７を介してDigital Out端子３９から外部出力される。MPEG Decoder３０でデコードされDAC３２、３４でＤ／Ａ変換されたＡＶ信号（アナログビデオ信号およびアナログオーディオ信号）は、外部モニタに入力される。
【００８１】
図１３の記録再生装置（HD_DVDレコーダ）の動作は、ＭＰＵ４０により制御される。ＭＰＵ４０にはファームウエアや種々な制御パラメータを格納するＥＥＰＲＯＭ４２、ワークＲＡＭ４４、タイマ４６等が付属している。ＭＰＵ４０のファームウエアの中身としては、グラフィックユーザインターフェースを提供するＧＵＩ表示制御部４００、エンコードパラメータ検出処理部４０２、高速コピー（高速ダビング）処理部４０４、レート変換コピー（等速コピー／等速ダビング）制御部４０６、記録／再生制御部（管理情報処理部）４０８、ＡＡＣＳ処理部２１０ａ（図２の制御部２１０に対応）等がある。ＧＵＩ表示制御部４００の処理結果は、オンスクリーン表示部（ＯＳＤ）５０を介して外部モニタにて画面表示される（タイトルサムネールの表示画面５２ａ、５２ｃ等はＯＳＤ５０の処理で得ることができる）。
【００８２】
図１３の実施の形態において、ＨＤＤ１０４については、１台の超大容量ＨＤＤ（例えば１ＴＢ）でも、複数の大容量ＨＤＤの併用（例えば５００ＧＢ＋５００ＧＢ）でもよい。また、ＨＤＤの記録エリアの使い方としては、その記録エリアを論理的に複数パーティションに分けて使用する場合と、物理的なＨＤＤ毎に用途を特定する場合がある。前者の場合としては、例えば１ＴＢのうち４００ＧＢの第１パーティションをデジタル高精細放送のMPEG2-TS記録用（ＴＳタイトル用）に割り当て、４００ＧＢの第２パーティションをデジタル高精細放送のMPEG4-AVC記録用（ＨＤＶＲタイトル用）に割り当て、２００ＧＢの第３パーティションをアナログ放送またはデジタル放送もしくは外部入力のMPEG2-PS記録用（ＶＲタイトル用）に割り当てるなどが考えられる。また、後者の場合としては、例えば第１の４００ＧＢＨＤＤをMPEG2-TS記録用（ＴＳタイトル用）に割り当て、第２の４００ＧＢＨＤＤをMPEG4-AVC記録用（ＨＤＶＲタイトル用）に割り当て、第３の２００ＧＢＨＤＤをMPEG2-PS記録用（ＶＲタイトル用）に割り当てるなどが考えられる。
【００８３】
なお、この発明の一実施の形態では、ＶＲタイトルには、現行のDVD-VR規格によるMPEG2-PS記録の他に、次世代HD_DVD規格において最大レートを10.08Mbpsに抑えたMPEG2-PS記録も含まれる。あるＶＲタイトルのストリームデータがDVD-VR規格によるMPEG2-PSなのかHD_DVD規格において最大レートを10.08Mbpsに抑えたMPEG2-PSなのかの区別は、オブジェクトデータレベルでは、オブジェクトデータ内の特定情報（例えばプログラム最大レート “program_mux_rate”）の記述内容が「10.08Mbps」なのか「30.24Mbps」なのかで行うことができる。また、管理情報レベルでは、そのタイトルの再生開始前に、管理情報内の特定情報（例えばビデオ属性“V_ATR”）が現行DVD-VR規格ではあり得ない解像度（例えば1280x1080）を含んでいるかどうかで行うことができる。
【００８４】
前述した複数種類のタイトル（ＴＳタイトル、ＨＤＶＲタイトル、ＶＲタイトル）は、この発明の一実施の形態では、図１２に例示するように同じディレクトリ内でファイル管理される。そのため、複数種類のタイトル（ＴＳタイトル、ＨＤＶＲタイトル、ＶＲタイトル）のアイコンまたはサムネールを同一画面５２ａ（または５２ｃ）上で表示できる。このことから、ユーザは、複数タイトルの各々がどんな規格（HD_DVD-VR、DVD-VR等）のどのような状況下で録画されたものでも（最大レートが10.08MbpsのHD_DVD-VR録画、最大レートが10.08MbpsのDVD-VR録画等）、それらを同様に操作できる。
【００８５】
なお、メニュー画面５２ａでは、各タイトルのサムネールが、著作権行使をしないフォントＦｚおよび著作権を行使しないイメージ文字パターンＦｙの他に、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘが用いられている。メニュー画面５２ａの情報およびそれに対応するタイトルのオブジェクト（ＶＯＢおよび／またはＳＯＢ）はＡＡＣＳで暗号化され、ＡＡＣＳ対応のメディア１００に記録される（図１８を参照して後述する）。
【００８６】
ここで、「著作権行使をしないフォントＦｚ」とは、著作権の期限切れでパブリックドメインになったフォントのほかに、著作権が生きていても、著作権者が第三者の自由な利用を認容あるいは黙認しているフォントも含む。一方、仮にパブリックドメインにあったフォントでも、例えば図１３の機器のメーカにより変更が加えられた結果新たなlook-and-feelを備えるようになったフォントは、著作権付きフォントとなり得る。
【００８７】
記録先がＡＡＣＳに対応していないメディア（例えば従来のＤＶＤ−Ｒ／ＲＷ／ＲＡＭディスク１０２、あるいはＨＤ＿ＤＶＤ以外の規格によるメディア）であるときは、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘのないメニュー画面５２ｃが作成され、その情報がＡＡＣＳ非対応のメディア１０２に記録される（この場合オブジェクトの暗号化には、例えばＣＳＳ（Content Scramble System）方式が用いられる。
【００８８】
もしくは、記録先がＡＡＣＳに対応していないメディア（例えばHD_DVDのドライブで使用可能に作製されていてもＡＡＣＳで必要なMedia IDが記録されていないディスク）であるときは、メニューを作成しない（結果的にメニューがＡＡＣＳ非対応ディスクに記録されることはない）ようにしてもよい。HD_DVDのInteroperable Contentの場合、従来のDVD Videoと同じくメニューはオプション扱いとなっている。このため、HD_DVDで使用可能に作製されていてもＡＡＣＳに対応していないディスクがドライブに挿入されたら、何も表示せずに即、そのディスクに記録されたタイトルを（管理情報VMG/HDVR_MG内のプログラムチェーン情報の記述に従って）順番に再生することも可能である。この場合は著作権保護付きフォントは使わずに済む。
【００８９】
図１４は、この発明の一実施の形態に係る記録方法を説明するフローチャートである。この記録方法の処理は、あるオブジェクト（ＶＯＢまたはＳＯＢ）の１回の記録が行われる毎に実行される。例えば、著作権保護されたデジタル放送の番組Ａと番組Ｂが電子プログラムガイド（ＥＰＧ）等を用いることで録画予約されているとする。この場合、番組Ａの予約録画が行われるときに図１４の処理が（ある暗号鍵を用いて）実行されて、例えば番組Ａ相当のビデオオブジェクトＶＯＢ（ＭＰＥＧ４ＡＶＣ等）が暗号化されて光ディスク（例えば図１３の１００）またはハードディスク（例えば図１３の１０４）に記録される。また、番組Ｂの予約録画が行われるときには図１４の処理が（別の暗号鍵を用いて）改めて実行されて、例えば番組Ｂ相当のストリームオブジェクトＳＯＢ（ＭＰＥＧ２ＴＳ等）が暗号化されて光ディスク（１００）またはハードディスク（１０４）に記録される。
【００９０】
上記のような１回の記録が開始されると、ＡＡＣＳ方式の暗号化に用いる鍵（タイトル鍵ＫｔまたはContents key）が生成される（ＳＴ１００）。この鍵生成処理は、図３を参照して説明した処理と同様に行うことができる。なお、記録先の媒体がハードディスクやHD_DVD-RW/RAM等の上書き可能なメディアであればＳＴ１００で新たに鍵の生成を行う。
【００９１】
しかし、記録先の媒体がHD_DVD-R（または片面２層のHD_DVD-R：DL）等の上書き不能なライトワンスメディアであるときは、後述する図１７の処理により、所望数の鍵（Title Keys）を同じファイル（Title Key File）内に予め用意しておく。そして、これらの予め用意された複数鍵を適宜（あるいは順次）用いることで、上書き不能なライトワンスメディアにおいても、鍵の更新を実質的に可能としている。
【００９２】
これらの鍵は更新で使い切ることがないように必要十分な数が予め用意される。しかし、もし、何らかの理由で予め用意した複数鍵を全て使い切ってしまった場合は、最後に更新された鍵をそのメディアでの既存の鍵（Ｋｔ）とし、以後はその既存鍵（Ｋｔ）を利用するようにしてもよい（ＳＴ１００での最後の括弧書き参照）。
【００９３】
記録対象のオブジェクトの記録中、そのオブジェクトの分割がないときは（ＳＴ１０２Ｎ）、ＳＴ１００で生成された鍵を用いて（ＡＡＣＳ方式により）オブジェクトを暗号化しつつ（ＳＴ１０６）、暗号化されたオブジェクトを記録媒体（ハードディスクまたは光ディスクもしくは半導体メモリ）に記録する（ＳＴ１０８）。記録対象のオブジェクトに対する１回の記録が終了していない間は（ＳＴ１１０Ｎ）、ＳＴ１０２〜ＳＴ１１０の処理が反復される。
【００９４】
記録対象のオブジェクト（例えば番組ＢのＳＯＢ）の記録中、そのオブジェクトが例えば録画ポーズあるいはビデオ属性の変更などにより分割されたときは（ＳＴ１０２Ｙ）、その後の記録処理を別の記録処理としてカウントすると、見かけ上１回の録画処理でなくなる。しかし、その場合は１回の録画処理内の出来事とみなし、分割前のオブジェクト（例えば番組Ｂの前半のＳＯＢ）の暗号化で用いた鍵（Ｋｔ）を分割後のオブジェクト（例えば番組Ｂの後半のＳＯＢ）に適用する（ＳＴ１０４）。このようにすると、新たな鍵生成処理（図３を参照して述べたような処理）を省略できるため、新たな鍵生成のためのタイムラグがなくなり、分割後のオブジェクトの暗号化（ＳＴ１０６）とその記録（ＳＴ１０８）を滞りなく実行できる（具体的には、分割後のオブジェクトの記録を継続する際にその冒頭が切れてしまう恐れを払拭できる）。
【００９５】
以上のようにして、記録対象のオブジェクトの１回の記録が終了すると（ＳＴ１１０Ｙ）、記録されたオブジェクトを再生する際に必要な種々な管理情報がHR_MANGR.IFOファイル（図１２参照）に記録されて（ＳＴ１１２）、図１４の記録処理は終了する。
【００９６】
図１５は、この発明の一実施の形態に係る再生方法を説明するフローチャートである。図１４のような処理でオブジェクトデータ（ＶＯＢおよび／またはＳＯＢ）および管理情報が記録されたディスク１００から、再生しようとするオブジェクト（例えば番組ＢのＳＯＢ）の管理情報が読み取られる（ＳＴ２００）。この管理情報（例えば図１２のHR_MANGR.IFO）は、ディスク１００に記録された複数タイトル（オブジェクト）のうちユーザが再生対象を選択する際に用いるメニュー（例えば図１３の５２ａあるいは５２ｃ）の情報も含むことができる。読み取られた管理情報は、再生機器のワークメモリ（図１３の４４等）に一旦記憶される。
【００９７】
この再生機器（図２の２００相当）は、再生しようとするオブジェクトの暗号化に関する情報（Ｋｍ，Ｋｐａ，Ｋｔ等を生成するための元になる情報）を光ディスク（例えば図１３の１００）またはハードディスク（例えば図１３の１０４）から読み取り（ＳＴ２０２）、読み取った情報から復号鍵（ＫｔまたはContents Key）を生成する（ＳＴ２０４）。ここで、Ｋｍ，Ｋｐａ，Ｋｔ等を生成するための元になる情報とは、Lead-in MKB、Read Write MKB、Binding Nonce、Title Key File、Usage Rule Fileなどを言う（図２参照）。この復号鍵生成処理は、図２を参照して説明した処理と同様に行うことができる。こうして読み取られた管理情報（HR_MANGR.IFOファイル）と生成した復号鍵（ＫｔまたはContents Key）を用いて、再生対象オブジェクトを復号しながら再生する（ＳＴ２０６）。この再生処理が再生対象オブジェクトの末尾まで済むと（あるいはユーザもしくは装置の制御プログラムが再生停止を指示すると）（ＳＴ２０８Ｙ）、図１５の再生処理は終了する。
【００９８】
ところで、メディア１００上のTitle Key Fileが書き込まれているアドレスのプロテクト領域には、Binding Nonceという乱数を基にした数値が記録されている。プロテクト領域とはＡＡＣＳ専用の特殊コマンドでのみ読み書き（アクセス）ができる領域であり、この部分にProtected Area Key（Ｋｐａ）を構成する要素を記録しておくことで、パソコン（ＰＣ）等を使った不正な暗号解除を防ぐことができる。このBinding NonceはTitle Key Fileを更新する都度更新する必要がある。
【００９９】
一方、Binding Nonceはファイルが書き込まれるアドレスに依存しており、HD DVD-R等のライトワンスメディアの場合、Title Key File自体が毎回新しいアドレスに保存されることになり、Binding Nonceの書き込まれる位置も一箇所ではなくなる。しかしＡＡＣＳではBinding Nonceは同一箇所に上書きすることが求められているので、ライトワンスメディアの場合、Title Key Fileの更新は、ＡＡＣＳを採用する限りできないことになる。
【０１００】
このようにライトワンスメディアではTitle Key Fileの更新ができないため、そのメディアを記録に初めて使用する際、一番最初にTitle Key Fileを作成するときに予め必要な数分だけTitle Keyを生成しておく。しかし最大数である１９８８個もTitle Keyを作る必要はなく、必要最低限の個数のみ作成すれば良い。必要最低限の個数とは、全コンテンツを１つの鍵で共通とすれば１つあれば良いことになる。しかし、それでは１枚のライトワンスメディアにＡＡＣＳで管理される個別の複数コンテンツ（例えば個別の複数デジタル放送番組）を記録できなくなる。
【０１０１】
ＡＡＣＳには、Title Usage Rule Fileという、コンテンツごとの利用制限などが記載されたファイルがある。このTitle Usage Rule Fileの例が図１６に示されている。利用制限のルールを記述する欄は図１６（ａ）のUsage Rule#1〜Rule#1998まで１９９８個用意されており、これはTitle Keyの番号と対応が取られている。つまり、Title Key#1のUsage RuleはUsage Rule#1に相対する。
【０１０２】
図１６（ｂ）はUsage Ruleのデータ構造であり、UR_FLGはこのルールの有効・無効を示すビットである。無効なルールの場合はUR_FLGのビットには０が記載される。その後のＤＯＴ−Ｐ、ＤＯＴというのがルール（使用規則あるいは利用制限）の本体であり、例えばＤＯＴ（Digital Only Token）が1の場合はそのコンテンツをアナログ出力してはならないというルールとなる。前述のようにルールはTitle Keyと相対しているため、コンテンツに暗号化を施す際の採用ルールが異なる場合は、Title Keyも異ならなくてはならない。このため、Usage Ruleの種類の数に応じて、そのルールを適用したTitle Key、ルールを適用しないTitle Keyの２つのTitle Keyが必要になる。現時点ではＤＯＴとＤＯＴ−Ｐの２つのルールがＡＡＣＳで定義されているため、実際の運用上は最小限４種類のTitle Keyを予め作成しておく必要がある。
【０１０３】
また、コンテンツを暗号化するための鍵のほかに、Interoperable ContentのAdvanced Resource Fileを暗号化するためにも鍵が必要である。すべてのResource Fileで共通の鍵を使っても構わないので、Interoperable ContentのAdvanced Resource Fileを暗号化するための鍵の最低個数は1となる。（なお、“Interoperable Content”とは、記録再生系のHD_DVD-Video Recording規格内で記録されるコンテンツのうち再生系のHD_DVD-Video規格に準拠したプレーヤでも再生できるコンテンツをいう。）
従って、ライトワンスメディア１００に最初にTitle Key Fileを作成する際は、Title Usage Rule Fileの個数＋１個のコンテンツ用タイトル鍵と、1個のAdvanced Resource File用タイトル鍵を予め生成しておけば、Title Key Fileが更新できないライトワンスメディアであっても、ＡＡＣＳの運用を行うことが可能になる。
【０１０４】
図１７は、ライトワンスメディアに最初にTitle Key Fileを書き込む際の処理手順の一例を説明するフローチャートである。不正アクセスから保護しようとするコンテンツ（Title）をＡＡＣＳにより暗号化するための鍵（Title KeyまたはＫｔ）のファイル（Title Key File）を最初に作成するのは、例えば図１４のスタートから図１７の処理にエンターする際（あるいは図１４のＳＴ１００の処理内）である。その際に、Usage Rule File内の規則数（例えば図１６ｂのＤＯＴとＤＯＴ−Ｐの２つ）に対応する数（Usage Ruleの組み合わせの数、例えば４つ）分、Title Key（またはＫｔ）を作成する（ＳＴ３００〜ＳＴ３０２）。また、著作権保護されたAdvanced Resource File（ＡＲＦ）がある場合、もしくはそのようなＡＲＦが今後作成され得る場合（ＡＲＦが将来作成される見込みがある場合）（ＳＴ３０４Ｙ）は、そのＡＲＦ用のTitle Key（またはＫｔ）を別途作成する（ＳＴ３０６）。こうして、所望数（Usage Ruleの組み合わせの数および、適宜、ＡＲＦ用Title Keyの数）だけTitle Key（またはＫｔ）を作成する（ＳＴ３００〜ＳＴ３０６）。作成した数のTitle Key（またはＫｔ）はTitle Key Fileに書き込まれる（ＳＴ３０８）。
【０１０５】
その後、図１４の処理へリターンし、Title Key Fileに書き込まれたTitle Key（またはＫｔ）を用いて（ＳＴ１００）コンテンツ（Title）を暗号化し（ＳＴ１０６）、暗号化されたコンテンツ（Title）をライトワンスメディア（HD_DVD-R等）に記録する（ＳＴ１０８〜ＳＴ１１２）。
【０１０６】
ここで、コンテンツ（Title）とは別に保護すべき内容を含む資源情報、すなわち前記Advanced Resource File（ＡＲＦ）の具体例としては、フォント、効果音、静止画等の情報がある。とくに、高精細画面で用いられる美しいベクターフォント（例えば図１３のモニタ画面５２ａで表示される各タイトル文字やその番組説明のフォント、あるいは図示しないがメニュー以外の画面における字幕等のフォント）は著作権保護の必要性が高い（パソコン等を用いてそのフォントが著作権者に無断で不正使用される可能性が高い）。そのため、このような高精細フォントは、著作権保護されている（パブリックドメインでない）限り、ＡＡＣＳによる暗号化・復号化の対象となり得る。
【０１０７】
図１７の処理を簡単に整理すると、次のようになる。まずUsage Rule Fileにいくつルールを書き込むかを求め（ＳＴ３００）、その個数だけTitle Keyを生成する（ＳＴ３０２）。またAdvanced Resource Fileの暗号が必要である場合には（ＳＴ３０４Ｙ）、更に１つTitle Keyを生成する（ＳＴ３０６）。そこで生成されたTitle KeyをＴＫ処理で暗号化したものをTitle Key File内に書き込む（ＳＴ３０８）。
【０１０８】
なお、記録先のメディアがライトワンスメディアでなく反復書き換え可能なメディア（例えばHD_DVD-RAM、ハードディスク、半導体フラッシュメモリ等）の場合は、図１７のＳＴ３００をスキップし、ＳＴ３０２のところでTitle Keyを１つ生成するようにしてもよい。
【０１０９】
図１８は、著作権保護された情報資源（フォント等）をメニュー等に利用する場合の処理手順の一例を説明するフローチャートである。例えば図１３のHD_DVD Drive２６にディスクが装填されると、図１３のＭＰＵ４０のファームウエアは、そのディスクのＢＣＡあるいはリードインエリア内の情報を読み取ることで、そのディスクがＡＡＣＳ対応メディアであるか否かのチェックを行う（ＳＴ５００）。そのディスクがＡＡＣＳに対応したメディアである場合は（ＳＴ５００Ｙ）、図１７のＡＲＦ等の資源情報（著作権付フォント等）を用いて、例えば図１３のメニュー画面５２ａを作成する（ＳＴ５０２）。そして、ＡＲＦの一部分（メニューで用いられるフォントのうち著作権付きのフォント等）をＡＡＣＳで暗号化（図１７のＳＴ３０６と同様）してメディア１００に記録する（ＳＴ５０４）。
【０１１０】
一方、ＡＡＣＳに対応していないメディアである場合は（ＳＴ５００Ｎ）、ＡＲＦの前記一部分（著作権付フォント等）を用いないで、例えば見かけが別のメニュー（図１３の５２ｃ等）を作成する（ＳＴ５１０）。もしくは、記録先がＡＡＣＳに対応していないメディア（例えば従来のＤＶＤ−Ｒ／ＲＷ／ＲＡＭディスク１０２、あるいはＨＤ＿ＤＶＤ以外の規格によるメディア）であるときは、ＳＴ５１０の処理において、メニューを作成しない（結果的にメニューがＡＡＣＳ非対応ディスクに記録されることはない）ようにしてもよい。
【０１１１】
ところで、HD_DVD Video Recording Formatでは、ＶＯＢで構成されたコンテンツをHD_DVD Video Playerでも再生できるように、「Interoperable Contentと呼ばれるHD_DVD VideoのAdvance Content形式のＸＭＬ形式のスクリプト」をレコーダ（例えば図１３）側で記録することが必須機能となっている。
【０１１２】
Interoperable Contentでは、例えばメニュー中にテキストを表示するのに使うフォントはディスク内のAdvance Resource File（ＡＲＦ）というファイルに保存されている。従って、レコーダでフォントをディスクに書き込まないと、メニューに文字を表示することができない。このフォントデータはOpen Type Font形式であり、パソコンなどでも使用可能な一般的なものである。従ってレコーダでフォントのデータをディスクに書き込むと、そのフォントは他の目的にも流用可能になってしまう。
【０１１３】
これを防ぐため、HD_DVDのAdvance Resource FileはＡＡＣＳで暗号を施すことが規格上許されている。暗号化されていれば、そのHD_DVDディスクからファイルをコピーしても解読することができず、フォントの流用を防ぐことができる。ＡＡＣＳは、対応のメディアに記録されているMedia ID等を利用して暗号化を施す。従って、ＡＡＣＳ非対応メディアに対しては暗号化を施すことができない。このため、まずＡＡＣＳ対応・非対応の判定を行い、ＡＡＣＳ非対応メディアの場合はInteroperable Contentのメニュー等にテキストを使用せず暗号化の不要なイメージデータ等（図１３の例ではＦｙ，Ｆｚ）のみを使い、著作権保護されたフォント等（図１３の例ではＦｘ，Ｉｘ）をディスクに保存しないようにする。一方ＡＡＣＳ対応メディア１００の場合は、フォントが暗号によって保護されるので、テキストを用いたメニューを生成し（図１８のＳＴ５０２）、フォントデータ（そのデータを含むファイル）はＡＡＣＳで暗号化する（図１８のＳＴ５０４）。
【０１１４】
なお、図１３のメニュー画面５２ａでは、各タイトルのサムネールが、著作権行使をしないフォントＦｚおよび著作権を行使しないイメージ文字パターンＦｙの他に、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘが用いられている。メニュー画面５２ａの情報およびそれに対応するタイトルのオブジェクト（ＶＯＢおよび／またはＳＯＢ）はＡＡＣＳで暗号化され、ＡＡＣＳ対応のメディア１００に記録される。
【０１１５】
一方、記録先がＡＡＣＳに対応していないメディア（例えば従来のDVD_R/RW/RAMディスク１０２）であるときは、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘのいずれもないメニュー画面５２ｃが作成され（図１８のＳＴ５１０）、その情報がＡＡＣＳ非対応のメディア１０２に記録される（この場合オブジェクトの暗号化には、例えばＣＳＳ（Content Scramble System）方式が用いられる。
【０１１６】
なお、対象メディアが「ＡＡＣＳ対応メディア」であるか否かは、例えばそのメディアの種類に応じて適宜判定できる。例えば、メディアがHD_DVD-R/RW/RAMディスクの場合は、そのディスクのリードインエリアの内側の一部に、そのディスクに固有の情報がバーコード状のパターンで記録されるＢＣＡ（Burst Cutting Area）が設けられている。このＢＣＡのレコード中に、ＨＤ＿ＤＶＤの規格識別子（HD_DVD book type Identifier）を含む情報（BCA Record ID）、ＨＤ＿ＤＶＤの規格形式とディスク形式の情報（Book type and Disc type）等を記述することができる。このような情報を含むＢＣＡレコードからそのディスクがＨＤ＿ＤＶＤ規格のディスクであると判明すれば、そのディスクは「ＡＡＣＳ対応メディア」であると判定できる（ＢＣＡレコードがＨＤ＿ＤＶＤ規格のディスクでないことを示すときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１１７】
なお、対象メディアのＢＣＡ中に前述したMedia IDがあるときは、このMedia IDから「ＡＡＣＳ対応メディアであるか否か」の判定を行う方法もある。
【０１１８】
また、ディスクのリードインエリア内にＲＭＡ（Recording Management Area）が設けられ、このＲＭＡ内にそのディスクがＨＤ＿ＤＶＤ規格のディスクであることを識別するディスク固有の情報（Unique Disc ID）が記述されておれば、その記述内容から、そのディスクは「ＡＡＣＳ対応メディア」であると判定する方法もある（Unique Disc IDからＨＤ＿ＤＶＤ規格のディスクであると識別できないときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１１９】
さらに、メディアがHD_DVD-R/RW/RAMあるいはHD_DVD Video（ROM disc）の場合では、そのディスクのリードインエリアの内側に物理フォーマット情報（Physical format information）を記録することができる。この物理フォーマット情報内にＨＤ＿ＤＶＤの規格形式とそのパートバージョンの情報（Book type and Part version）が記述されておれば、その記述内容から、そのディスクは「ＡＡＣＳ対応メディア」であると判定できる（Book type and Part versionがＨＤ＿ＤＶＤ規格に該当しないときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１２０】
＜実施の形態のまとめ＞
（１）ＨＤ＿ＤＶＤメディアに対してHD DVD Video Recording Formatで記録する録画再生装置において、その装置のディスクドライブに挿入されたメディアがＡＡＣＳに対応したものである場合、Interoperable Contentで使用するフォントをAdvanced Resource FileとしてＡＡＣＳで暗号化して記録する。
【０１２１】
（２）ＨＤ＿ＤＶＤメディアに対してHD DVD Video Recording Formatで記録する録画再生装置において、その装置のディスクドライブに挿入されたメディアがＡＡＣＳに対応していないものである場合、（著作権保護されたフォントの）文字は使用せず、イメージデータのみ（あるいは著作権が行使されないフォントとイメージデータ）で構成されるメニューを表示するようなInteroperable Contentを生成する。
【０１２２】
＜実施の形態の効果＞
Interoperable Contentを生成する際、Interoperable Contentが記録されるメディアのＡＡＣＳ対応／非対応の別により、（著作権保護された）フォントをディスクに記録する／しない（あるいはそのようなフォントを含むメニューをディスクに記録する／しない）を分けることで、フォントの不正な流用を防ぐことができる。
【０１２３】
＜その他＞
（01）この発明の一実施の形態に係る情報アクセス管理方法は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（メニューあるいはビデオプログラム中の各画面等）の情報を情報記録媒体（１００）に適宜記録する際に利用される。ここでは、前記情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かをチェックし（ＳＴ５００）、前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（例えばメニュー画面：図１３の画面５２ａ等）を作成し（ＳＴ５０２）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する（ＳＴ５０４）。一方、前記所定の暗号化方式（ＡＡＣＳ）に対応していないメディアである場合は（ＳＴ５００Ｎ）、前記資源情報の前記部分（著作権付フォント等）を用いないで前記所定画面（例えば見かけが別のメニュー：図１３の５２ｃ等）を作成するか、または前記所定画面（メニュー）を作成しない（ＳＴ５１０）。
【０１２４】
（02）前記情報記録媒体（１００）が、前記所定の暗号化方式（ＡＡＣＳ）に対応した記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテント（Interoperable Content）を記録できるメディア（HD_DVD-R/RW/RAM等）である場合は、前記インターオペラブルコンテントで用いられるフォントを用いてメニュー（図１３の５２ａ）を作成し（ＳＴ５０２）、前記インターオペラブルコンテントで用いられるフォントを所定のファイル（Advanced Resource File：ＡＲＦ）に格納し、このファイル（ＡＲＦ）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化して前記情報記録媒体（１００）に記録する（図１７のＳＴ３０６、ＳＴ３０８）。
【０１２５】
（03）前記情報記録媒体（１００）が、前記所定の暗号化方式（ＡＡＣＳ）に対応しない記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテント（Interoperable Content）を記録できるメディア（HD_DVD-R/RW/RAM等）である場合は、前記インターオペラブルコンテントで用いられるフォントを用いないでメニュー（図１３の５２ｃ）を作成するか、またはメニューを作成しない（ＳＴ５１０）。
【０１２６】
（04）前記メニュー（図１３の５２ａまたは５２ｃ）の情報が記録された前記情報記録媒体（１００）から、このメニューの情報を含む管理情報（HR_MANGR.IFO）を読み取り（ＳＴ２００）、この管理情報で管理されるオブジェクトを再生する（ＳＴ２０２〜ＳＴ２０６）ことができる。
【０１２７】
（05）この発明の一実施の形態に係る記録装置（図１３のエンコード側）は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（図１３の５２ａ等）の情報を情報記録媒体（１００）に記録するように構成される。この装置は、前記情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かをチェックし（図１８のＳＴ５００）、前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（図１３の５２ａ等）を作成する手段と（図１８のＳＴ５０２を処理する図１３の２１０ａ、４００）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する手段と（図１８のＳＴ５０４を処理する図１３の２１０ａ、４０８、２０〜２４）を具備している。
【０１２８】
（06）この発明の一実施の形態に係る再生装置（図１３のデコード側）は、所定の鍵（Title KeyまたはＫｔ）を用いて所定の暗号化方式（ＡＡＣＳ）により暗号化されたコンテンツ（Title）および暗号化されたリソースファイル（ＡＲＦ）を前記所定の暗号化方式（ＡＡＣＳ）に対応した情報記録媒体（１００）から再生するように構成される。この装置は、前記コンテンツ（Title）の管理情報（HR_MANGR.IFO）を前記情報記録媒体（１００）から読み取る手段（ＳＴ２００の処理を行う４０８、２２〜２４）と、前記暗号化に関する情報（Ｋｔ等を生成する元になる情報）を前記情報記録媒体（１００）から読み取って復号鍵（ＫｔまたはContents Key）を生成する手段（ＳＴ２０２〜ＳＴ２０４の処理を行う２１０ａ、２２〜２４）と、前記情報記録媒体（１００）から読み取った前記管理情報（HR_MANGR.IFO）および生成した前記復号鍵（ＫｔまたはContents Key）を用いて、前記暗号化されたリソースファイル（ＡＲＦ）または前記暗号化されたコンテンツ（Title）を復号しながら再生する手段（ＳＴ２０６の処理を行う２１０ａ、４０８、２２〜３０）とを具備している。
【０１２９】
（07）この発明の一実施の形態に係る情報記憶媒体（ＡＡＣＳで暗号化されたフォント等を含むＡＲＦが記録されるディスク）は、所定の暗号化方式（ＡＡＣＳ）に対応した記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテントを記録できるメディア（HD_DVD-R/RW/RAM等）である。この情報記録媒体（１００）は、前記インターオペラブルコンテントで用いられるフォントを用いて作成（ＳＴ５０２）されたメニュー（図１３の５２ａ）の情報を格納するエリア（HR_MANGR.IFO）と、前記インターオペラブルコンテントで用いられるフォントを格納し、前記所定の暗号化方式（ＡＡＣＳ）で暗号化された所定のファイル（ＡＲＦ）を格納するエリア（HR_MANGR.IFO）とを具備している。
【０１３０】
なお、この発明は前述した実施の形態に限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で種々に変形することが可能である。
【０１３１】
また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、この構成要件が削除された構成が発明として抽出され得る。
【図面の簡単な説明】
【０１３２】
【図１】この発明の一実施の形態に係るメディア（情報記録媒体）内のデータ（タイトルキーファイル）の構成を説明する図。
【図２】メデイアに記録された暗号化コンテンツを復号する処理例を説明する図。
【図３】コンテンツを暗号化してＤＶＤに記録する処理例を説明する図。
【図４】タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造を示す説明図。
【図５】この発明の一実施の形態で採用される暗号化方式（ＡＡＣＳ方式）を用いた記録再生処理で必要となるメデイア上のデータを示す図。
【図６】ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。
【図７】ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。
【図８】暗号化されたタイトルキーファイル（Ｅ−ＴＫＦ）の構造例を示す図。
【図９】リライタブルメディアのタイトルキーファイルの更新手続きを説明するフローチャート図。
【図１０】ライトワンスメディアのタイトルキーファイルの書込み手続きを説明するフローチャート図。
【図１１】この発明の一実施の形態に係るデータ構造例を説明する図。
【図１２】この発明の一実施の形態に係るファイル構造例を説明する図。
【図１３】この発明の一実施の形態に係る記録再生装置（HD_DVDレコーダ）の構成例を説明するブロック図。
【図１４】この発明の一実施の形態に係る記録方法を説明するフローチャート図。
【図１５】この発明の一実施の形態に係る再生方法を説明するフローチャート図。
【図１６】Title Usage Rule Fileの構造例を示す図。
【図１７】HD_DVD-R等の情報記録媒体に最初にTitle Key Fileを書き込む際の処理手順の一例を説明するフローチャート図。
【図１８】著作権保護された情報資源（フォント等）をメニュー等に利用する場合の処理手順の一例を説明するフローチャート図。
【符号の説明】
【０１３３】
２０…エンコーダ；２４…光ディスクドライブユニット；２６…青レーザ使用光ディスクドライブ（HD_DVD Drive）；２８…赤レーザ使用光ディスクドライブ（DVD-R/RW/RAM Drive）；３０…デコーダ；４０…制御用マイクロプロセサ（MPU）；４００…グラフィックユーザインターフェース（GUI）表示制御部（ファームウエア）；４０２…エンコードパラメータ検出処理部（ファームウエア）；４０４…高速コピー／高速ダビング処理部（ファームウエア）；４０６…レート変換コピー／レート変換ダビング制御部（ファームウエア）；４０８…記録／再生制御部（管理情報処理部）（ファームウエア）；２１０ａ…ＡＡＣＳ処理部；５０…オンスクリーン表示（OSD）部；５２ａ、５２ｂ…モニタ表示例；１００、１０２…情報記憶媒体（光ディスク）；１０４…情報記憶媒体（ハードディスクドライブ）；２００…情報記録再生装置、２１０…制御部、２２０…読出し部、２３０…書込み部。
【技術分野】
【０００１】
この発明は、暗号鍵等を利用した情報アクセス管理に関する。特に、光ディスク等の情報記録媒体に記録する高度機密情報（Highly Confidential Data）の保護に関する。
【背景技術】
【０００２】
近年、ディスクメディア等に記録されたコンテンツにアクセスするデジタル機器が種々開発されている。このような機器でアクセスされるディスクに記録されたデータには、不正アクセスあるいは違法コピーを防止するため、暗号化処理が施されている。この暗号化されたデータには、ＤＶＤ（Digital Versatile Disc）では主にＣＳＳ（Content Scramble System）方式に準拠した暗号化方式が採用されている。
【０００３】
一方、より高度な暗号化方式として、ＡＡＣＳ（Advanced Access Content System）が提案されている（特許文献１）。このＡＡＣＳ方式を採用する場合、例えばセットメーカーは、ライセンシーが持つ鍵マトリクスから特定の鍵セットを入手し、異なる組み合わせの鍵を暗号化して、個々の機器に組み込んでいる。
【０００４】
ＡＡＣＳでは、コンテンツを正当に記録再生する機器毎に付与されたデバイスキーとランダムに発生させた乱数とにより、複数のキーそれぞれを暗号化して乱数とともにキーファイルに登録して、メディアに記録する。コンテンツを再生する場合には、このキーファイルに登録されている暗号化キーを、乱数と再生しようとする機器のデバイスキーとで復号化する。そして、復号化されたキーでコンテンツを復号化して、コンテンツを再生する。
【０００５】
ＡＡＣＳ方式を採用するHD_DVD Video Recording Formatでは、HD_DVD−Videoプレーヤで再生できるInteroperable Contentの記録が可能となっている。このInteroperable Contentで使用するフォント（著作権保護されたベクターフォント等）を用いると、高精細で美しく多彩なメニューを作成できる（特許文献２）。
【特許文献１】特開２００５−３９４８０号公報
【特許文献２】特開２００５−３３２５２１号公報（段落００３６〜００３８参照）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献２で述べているアドバンスドコンテンツは市販パッケージメディアのようなＲＯＭメディアに記録することを前提としており、記録系のメディアにアドバンスドコンテンツを作成する際に著作権の付いたフォントなどのリソースデータをどのように扱うかについては、配慮されていない。特許文献１でも著作権付きリソースデータの保護についての配慮に欠けている。
【０００７】
この発明の課題の１つは、ＡＡＣＳ等のアクセス管理方式を、著作権保護されたフォントなどを含む高度機密情報（Highly Confidential Data）の保護に利用することである。
【課題を解決するための手段】
【０００８】
この発明の一実施の形態に係る情報アクセス管理は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（メニューあるいはビデオプログラム中の各画面等）の情報を情報記録媒体（１００）に適宜記録する際に用いられる。この管理においては、情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かがチェックされる（ＳＴ５００）。情報記録媒体（１００）が前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（例えばメニュー画面：図１３の画面５２ａ等）を作成し（ＳＴ５０２）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する（ＳＴ５０４）。一方、情報記録媒体（１００）が前記所定の暗号化方式（ＡＡＣＳ）に対応していないメディアである場合は（ＳＴ５００Ｎ）、前記資源情報の前記部分（著作権付フォント等）を用いないで前記所定画面（例えば見かけが別のメニュー：図１３の５２ｃ等）を作成するか、または前記所定画面（メニュー）を作成しない（ＳＴ５１０）。
【発明の効果】
【０００９】
使用するメディアがＡＡＣＳ非対応の場合は著作権保護されたリソース（フォント等）をそのメディアに記録しない（著作権保護されたリソースを除いた形の記録はできる）ので、著作権保護されたリソース（フォント等）の不正な流用を防ぐことができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照してこの発明の種々な実施の形態を説明する。光ディスク等の情報記録媒体に対して情報を記録する場合、情報を暗号化して記録することが要求される場合がある。その場合、例えば著作権保護されたコンテンツを暗号鍵で暗号化して暗号化コンテンツとし、さらに暗号化に用いた前記暗号鍵を秘匿させるため、他の暗号鍵で暗号化して暗号化鍵としている。そして前記暗号化鍵と暗号化コンテンツを一緒に記録媒体に記録し、違法コピー防止している。
【００１１】
現在、急速にマーケットを拡大しているＤＶＤ（Digital Versatile Disc）では、著作権保護に関して、次のような対応が図られている。即ち、ＤＶＤビデオでは、ＤＶＤ ＣＣＡ（DVD Copy Control Association）がライセンスしているＣＳＳ（Content Scramble System）方式を利用しており、ＤＶＤオーディオではＣＰＰＭ（Content Protection for Prerecorded Media）方式を利用している。また、記録メディアに記録されるコンテンツの著作権保護方式ではＣＰＲＭ（Content Protection for Recordable Media）方式が利用されている。ＣＰＰＭ方式とＣＰＲＭ方式のライセンスは、特定の団体（例えば４Ｃ Ｅｎｔｉｔｙ， ＬＬＣと称される団体）が行っている。
【００１２】
一方では、更に高精細映像や高品質多チャネル音声信号などを記録再生可能とする、大容量の次世代ＤＶＤ等の開発が進められている。このような次世代記録媒体へ高品位著作物を記録する場合の著作権保護方式は、従来以上にセキュリティー能力を高めた方式の導入が要求されている。その具体例として、ＡＡＣＳ（Advanced Access Content System）方式がある。以下、ＨＤ＿ＤＶＤ−ＶＲ（High Density Digital Versatile Disc Video Recording）フォーマットで採用するコンテンツ保護技術であるＡＡＣＳにおけるコンテンツ鍵の管理方法を説明する。
【００１３】
従来のＣＰＲＭ方式では、ディスクの中に存在するメディアキーブロック（ＭＫＢ）とメディアＩＤ（Media ID）を用いて暗号鍵を生成してコンテンツを暗号化していた。一方、ＡＡＣＳ方式では、ディスク内のコンテンツは共通の１つの暗号鍵ではなく、コンテンツ毎の暗号鍵によって暗号化されている。
【００１４】
図１はメディア１００内のデータの構成例を示す図である。この例では、同一のメディア内には、ＭＰＥＧ２−ＰＳなどの形式のコンテンツであるビデオオブジェクト（ＶＯＢ）、ＭＰＥＧ２−ＴＳなどの形式のコンテンツであるストリームオブジェクト（ＳＯＢ）をそれぞれ規格上最大１９９８個保存することが可能となっている。従来の方式ではこれらの全オブジェクトで１つの暗号鍵を使用しているが、ＡＡＣＳ方式ではコンテンツ毎にそれぞれ異なる暗号鍵によって暗号化がなされている。そしてこのコンテンツごとの暗号鍵はタイトルキーファイル（ＴＫＦ）に記憶されている。即ち、ビデオオブジェクト用タイトルキーファイルとストリームオブジェクト用タイトルキーファイルが設けられ、それぞれのタイトルキーファイルには暗号化されたタイトルキー（Encrypted Title Key：略してＥ−ＴＫ）が最大１９９８個保存可能となっている。
【００１５】
図２は、メデイア１００に記録された暗号化コンテンツ（Encrypted Contents）を復号する処理を説明する図である。図２には、コンテンツなどを記録したメディア１００に格納されている情報と、情報記録再生装置２００に設けられた処理機能及びそれらの間のデータの流れを表している。
【００１６】
HD_DVD Video Recording Formatで採用するコンテンツ保護技術はＡＡＣＳである。ＡＡＣＳにおけるコンテンツ鍵の管理方法を図２を用いて説明する。ＡＡＣＳ処理で使用するディスクの上書き換え不能な領域に記録されているデータには、
・Media ID
・Lead-in MKB
がある。
【００１７】
一方、ＡＡＣＳ処理で使用するものであってディスク１００上でファイルとして存在するデータには、
・Read Write MKB
・Title Key File
・Usage Rule File
がある。またTitle Key Fileの先頭アドレスのプロテクト領域にはBinding Nonceという乱数を基にしたデータが記録されている。
【００１８】
ＡＡＣＳでは、コンテンツを暗号化するための「タイトル鍵（Ｋｔ）」を生成する処理は、大きくいって、次の順番で実行される。すなわち、まずLead-in MKBとRead Write MKBのバージョンの新しいほうを使用してＭＫＢ処理を行う。この処理で生成される鍵を「メディア鍵（Ｋｍ）」と呼ぶ。このメディア鍵ＫｍとBinding Nonceを入力としてProtected Area Key処理（Ｋｐａ処理）を行うと「プロテクテッドエリアキー（Ｋｐａ）」が生成される。このＫｐａとUsage Rule FileのデータとTitle Key Fileのデータを入力としてTitle Key処理（ＴＫ処理）を行うことで、Title Key Fileに記載されている暗号化されたタイトル鍵（Encrypted Title Key）を本来のタイトル鍵Ｋｔに変換することができる。
【００１９】
ＭＫＢとはMedia Key Blockと呼ばれるデータであり、メディア鍵Ｋｍが暗号化されて記録されたものである。またＭＫＢには不正機器の情報も記録されており、不正機器はＫｍを取り出すことができないようになっている。不正機器の情報は更新されるため、ＭＫＢも新しいものを使うようにする必要がある。このためＨＤ＿ＤＶＤのＡＡＣＳでは、メディアのLead-in Areaに埋め込まれているLead-in MKB、ディスク上にファイルとして保存されているRead Write MKB、及び機器自体が内部の不揮発メモリに保存するDevice MKBの３種類のＭＫＢが存在し、このうちもっとも新しいＭＫＢをRead Write MKBに上書きすることが定められている。但し、ＭＫＢが新しいものに更新されるということはＫｍの値が変更されることになるため、Ｋｍ以降のすべての鍵情報（Ｋｐａ、Ｋｔ等）は再生成する必要がある。
【００２０】
なお、図２の情報記録再生装置２００には、制御部２１０、読み出し部２２０、書込み部２３０が設けられている。制御部２１０は、図２に示す情報記録再生装置２００の各機能及び各処理動作を制御する。読出し部２２０は、メディア１００よりデータを情報記録再生装置２００に読み込む。書込み部２３０は、情報記録再生装置２００内のデータをメディア１００に書き込む。
【００２１】
メディア１００の読み取り専用リードイン領域にはLead-in MKB（Media Key Block）が格納され、書き換え可能領域であるUser Data AreaにはRead Write MKBが格納されている。ＭＫＢは、コンテンツ暗号化のベース鍵であるメディアキー（Ｋｍ）を、情報記録再生装置２００に秘密鍵として設置されるデバイスキー（Ｋｄ）の集合体で暗号化して数学的体系を整えた、「メディアキーブロック」である。
【００２２】
図２のＳ１０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、バージョンの新しいＭＫＢをMedia MKBとして読み出す。そして、Ｓ１１において情報記録再生装置２００で保存されているデバイスキーセット（Set of Device KeysあるいはDevice Key Set）とMedia MKBとを用いてＭＫＢ処理を行う。このデバイスキーセットは、複数のデバイスキーＫｄで構成されている。
【００２３】
ここで、ＭＫＢにはプロテクテッドエリアキー（Ｋｐａ）を生成するための情報が暗号化されて保存されているが、そのほかに、リボーク情報（Revoke Information：取消情報あるいは無効化情報）も含まれている。即ち、あるデバイスキーセットにセキュリティホールが存在し、ライセンサが該当するデバイスキーＫｄを使用禁止としたときは、該当するデバイスキーＫｄに関するリボーク情報が記載される。このリボーク情報によって、該当するデバイスキーＫｄを持ったデバイスでは暗号を解くことができなくなる（つまりリボークされた情報を再生できなくなる）。不正機器の情報は時間経過に伴い漸次更新されるため、ＭＫＢも新しいもの（最新の更新されたＭＫＢ）を使うようにする必要がある。そのため上述のようにバージョンの新しいほうをMedia MKBとして使用する。
【００２４】
このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。図２のＳ１２において、生成されたメディア鍵を検証する。生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなして、ＡＡＣＳに関する処理を終了する。
【００２５】
一方、タイトルキーファイル（ＴＫＦ）の先頭アドレスのプロテクト領域には、Binding Nonceというファイルと結合した「乱数を基にしたデータ」が記録されている。このBinding Nonceは、例えば、ＰＣ（パソコン）のWrite命令ではコピー不可であり、ＡＡＣＳで定義された命令のみによってコピーが可能である。このように、ＡＡＣＳのライセンスを受けたハードでのみコピー可能とすることで、ＰＣを介した情報の流出を防いでいる。
【００２６】
次に、図２のＳ１３において、ＫｍとBinding Nonceを用いて、暗号処理であるＫｐａ処理を実施する。このＫｐａ処理には、暗号アルゴリズムであるＡＥＳ（Advanced Encrypted Standard）−Ｇを用いる。このＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。
【００２７】
次に、Ｋｐａからタイトルキー（ＴＫ）を生成するための、タイトルキー処理について説明する。この処理は図２のＳ１４で示されている。タイトルキーファイル（ＴＫＦ）には、ＴＫＦＮ（Title Key File Nonce）という乱数データが記憶されている。このＴＫＦＮは暗号化処理（後述）において、タイトルキーを暗号化するために用いられた乱数データである。また、ディスク１００にはコンテンツの利用規則を記述したUsage Rule Fileが備わっている。このUsage Rule Fileには、複数の使用規則それぞれについて、その使用規則を適用するか否かの情報（Usage Rule）が、０または１のＢｉｔ情報として記述されている。
【００２８】
さらに、ディスク１００のリードイン領域より内側に設けられた読取専用のバーストカッティングエリア（ＢＣＡ）には、Media IDが記録されている。Media IDは、メディア毎に付加されている固有ＩＤである。そして、書き換え可能領域であるユーザデータエリアには、Media IDを用いた改ざん防止コードＭＡＣ（Message Authentication Code）であるMedia ID MACが格納されている。
【００２９】
図２のＳ１４に示すタイトルキー処理では、上述のUsage Ruleを処理した結果とＫｐａとＴＫＦＮとに基いてＡＥＳ−Ｄのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫ）を復号してタイトルキー（ＴＫ）を生成する。なお、この際ＢＣＡに格納されているMedia IDを用いて生成したＭＡＣと、ディスクに格納されているMedia ID MACとを比較して改ざんがなされていないことが検証される。図２のＳ１５において、このようにして生成されたＴＫと暗号化されたコンテンツ（Encrypted contents）とをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成し、Ｓ１６において、このコンテンツキーを用いて暗号化されたコンテンツ（Encrypted contents）を復号してコンテンツを生成する。
【００３０】
図３は、コンテンツを暗号化してHD_DVD-R/RW/RAM等の光ディスク１００に記録する処理を説明する図である。なお、使用する用語は図２と同一であるため、重複する説明は省略する。図３のＳ２０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、バージョンの新しいＭＫＢをMedia MKBとして読み出す。次に、Media MKBと、情報記録再生装置２００が保有するDevice MKBとのバージョンを比較する。Device MKBのバージョンの方が新しい場合は、Ｓ２１において、ＭＫＢ更新処理を起動しRead Write MKBにDevice MKBの値を更新する。但し、Media MKBのバージョンの方が新しい場合にDevice MKBの値を更新するかどうかは、セット仕様となる。そして、図３のＳ２２において、情報記録再生装置２００で保存されているデバイスキーセットとMedia MKBとを用いてＭＫＢ処理を行う。このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。
【００３１】
図３のＳ２３において、生成されたメディア鍵を検証し、生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなしてＡＡＣＳに関する処理を終了する。一方、図３のＳ２４において、ＫｍとBinding Nonceとを用いて、暗号処理であるＫｐａ処理を実施する。ＡＥＳ−Ｇを用いたＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。
【００３２】
図３のＳ２５において、タイトルキー（ＴＫ）とコンテンツとをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成する。そして、Ｓ２６において、このコンテンツキーを用いてコンテンツを暗号化してEncrypted contentsを生成し、メディア１００に記録する。また、Ｓ２７において、Media IDとＴＫとを用いてＭＡＣを生成し、メディア１００にMedia ID MACとして格納する。一方、Ｓ２８において、タイトルキーを暗号化するために用いられる乱数データを生成し、Title Key File Nonceとしてメディア１００に記録する。そして、Ｓ２９において、Usage Ruleをハッシュ処理（公知技術）した結果とＫｐａとＴＫとに基いてＡＥＳ−Ｅのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫ）を生成してメディア１００に格納する。なお、Usage RuleはＳ３０においてメディア１００に記録する。
【００３３】
上述のように、コンテンツの暗号化、復号化においてはタイトルキー等が重要な役割を担っている。しかし、このタイトルキー等はRead/Write可能なファイルとしてメディア１００に記録されているため、メディア表面が例えば指紋などで汚れた場合、簡単にコンテンツの読み出し不能の状態に至るおそれがある。そこで、ＡＡＣＳではこれらのタイトルキー等の情報を格納したタイトルキーファイル（ＴＫＦ）についてバックアップが図られている。
【００３４】
図４は、タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造例を示す説明図である。なお、このバックアップ方法の説明では、タイトルキーファイルをＴＫＦ１とし、バックアップファイルとしてのタイトルキーファイルをＴＫＦ２，ＴＫＦ３と表す。なお、ＴＫＦ１〜３は、メディア１００に格納している。
【００３５】
それぞれのタイトルキーファイル（ＴＫＦ１〜３）は、Binding Nonce１〜３（ＢＮ１〜３）と、Title Key File Generation１〜３（ＴＫＦＧ１〜３）と、Title Key File Nonce〜３（ＴＫＦＮ１〜３）と、Encrypted Title Key１〜３（暗号化タイトルキーＥＴＫ１〜３）とをそれぞれ登録した構成となっている。ここで、Binding Nonce１〜３（ＢＮ１〜３）は、上述のように自身のタイトルキーファイルの暗号化に用いられる乱数データである。Title Key File Generation１〜３（ＴＫＦＧ１〜３）は、タイトルキーファイル（ＴＫＦ１〜３）それぞれの変更回数を表している。Title Key File Nonce〜３（ＴＫＦＮ１〜３）は、自身のタイトルキーファイルまたはバックアップファイル以外のファイルの暗号化タイトルキー（ＥＴＫ１〜３）を生成するための乱数である。
【００３６】
Encrypted Title Key１〜３（暗号化タイトルキー：ＥＴＫ１，ＥＴＫ２，ＥＴＫ３）は、次の（eq.1）〜（eq.3）式で示される：
ＥＴＫ１＝f（ＴＫ，ＢＮ１，ＴＫＦＮ３） …（eq.1）
ＥＴＫ２＝f（ＴＫ，ＢＮ２，ＴＫＦＮ１） …（eq.2）
ＥＴＫ３＝f（ＴＫ，ＢＮ３，ＴＫＦＮ２） …（eq.3）
ここで、ＴＫは暗号化されていない平文のタイトルキーを示し、暗号処理関数fは、第１パラメタ（ＴＫ）に第２パラメタ（ＢＮ１〜３）と第３パラメタ（ＴＫＦＮ１〜３）を暗号鍵として暗号処理を施すことを示している。暗号処理fには、たとえばＡＥＳ（Advanced Encryption Standard）などの公知の暗号アルゴリズムを用いればよい。
【００３７】
すなわち、ＴＫＦ１は、ＴＫＦ３と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ１）と、関連づけられたＴＫＦ３の（ＴＫＦＮ３）とで暗号化したものとなっている。また、ＴＫＦ２は、ＴＫＦ１と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ２）と、関連づけられたＴＫＦ１の（ＴＫＦＮ１）とで暗号化したものとなっている。さらに、ＴＫＦ３は、ＴＫＦ２と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ３）と、関連づけられたＴＫＦ２の（ＴＫＦＮ２）とで暗号化したものとなっている。
【００３８】
このようにタイトルキーファイルＴＫＦ１と各バックアップファイルＴＫＦ２，ＴＫＦ３は、互いに他のファイルと関連付けられており、暗号化タイトルキー（Ｅ−ＴＫ１，Ｅ−ＴＫ２，Ｅ−ＴＫ３）は、自己のファイルに登録された（ＢＮ１，ＢＮ２，ＢＮ２）と、関連づけられている他のファイルに登録されている（ＴＫＦＮ１，ＴＫＦＮ２，ＴＫＦＮ３）とでタイトルキー（ＴＫ）を暗号化したものとなっている。
【００３９】
上記のようにＴＫＦを３つ保存し、ＴＫＦＮを別ファイルに保存することにより、１つのＴＫＦがデータ破損などにより壊れてしまっても、残り２つのＴＫＦのデータから、壊れたデータを復元できる。
【００４０】
なお、前述したBinding Nonceを特殊なドライブ用コマンドでしか読み書きできないデータとしておくことにより、不正コピーを防止できる。すなわち、仮にＴＫＦがコピーされてもそれに付随するBinding Nonceはコピーされないため、悪意のある第三者による不正な暗号化／復号化行為を防ぐことができる。
【００４１】
なお、タイトルキーファイルと各バックアップファイルの他のファイルのＴＫＦＮとの関連づけは、上記（eq.1）〜（eq.3）式に限定されるものではなく、（eq.1）〜（eq.3）式以外のパターンでタイトルキーファイルとバックアップファイルのＴＫＦＮと関連付けるように構成してもよい。
【００４２】
図５、図６、図７を参照しつつ、ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを詳細に説明する。メディア１００上のProtected Area、即ち、Ｅ−ＴＫが格納されているファイルのProtected Areaには、Binding Nonce及びそのバックアップデータが格納されている。また、メディア１００の読取専用エリアにあるＢＣＡ（Burst Cutting Area）にはMedia IDが記録され、リードイン領域（後述する図１１では１１０）にはLead-in MKBが記録されている。
【００４３】
メディア１００上のユーザデータエリアには、ビデオオブジェクト（ＶＯＢ）および／またはストリームオブジェクト（ＳＯＢ）のCopy Protection Pointerに関する情報である管理情報が格納されている。また、ユーザデータエリアには、Read Write MKB、暗号化されたタイトルキー（Ｅ−ＴＫ）、Media ID MAC、Usage Rule及びそれらのバックアップファイルが格納されている。さらに、ユーザデータエリアは、暗号化されたコンテンツが最大１９９８個まで格納が可能となっている。
【００４４】
図８は、暗号化されたタイトルキーファイル（Ｅ−ＴＫＦ）の構造を示している。なお、図８はストリームオブジェクト（ＳＯＢ）についてのＥ−ＴＫＦの構造であるが、ビデオオブジェクト（ＶＯＢ）についても同様の構造である。バイト位置でいって０〜１５バイトには、タイトルキーファイルを特定するための固定情報（ＳＴＫＦ＿ＩＤ、ＨＲ＿ＳＴＫＦ＿ＥＡ）が記載され、３２〜３３バイトには、ＡＡＣＳのバージョン番号が記載されている。そして、１２８〜１４３バイトには、Title Key File Generationが格納され、１４４〜１５９バイトにはTitle Key File Nonceが格納されている。また、１６０〜６４０９５バイトには、Title Key Information（ＫＴＩ）として、暗号化されたタイトルキー（Ｅ−ＴＫ）とMedia ID MACとが１９９８組記載されている。
【００４５】
それぞれのコンテンツはこの１９９８個のタイトルキーのうちの１つの鍵を使って暗号化されている。但し、１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは０という数値をＴＫ処理で暗号化したものを記述する。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。上述のようにタイトルキーファイルはバックアップ用に合計３つのファイルを備えている。そしてこの３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。
【００４６】
次にタイトルキーファイルの更新方法について説明する。ＡＡＣＳが適用されるメディアの種類には、リライタブルメディアとライトワンスメディアがある。リライタブルメディアでは、例えば、新しいコンテンツが追加記録される毎に新しいタイトルキーが追加されるため、タイトルキーファイル中の全タイトルキーを新しいＫｐａを用いて再暗号化する必要がある。即ち、タイトルキーファイルの更新が必要となる。
【００４７】
ところで、タイトルキーファイルのプロテクト領域には、Binding Nonceという乱数を基にした数値が記載されているが、このBinding Nonceは不正な暗号解除を防止するために使用されるものであり、従って、Binding Nonceもタイトルキーファイルを更新する都度、更新される。
【００４８】
一方、ライトワンスメディアでは、タイトルキーファイルを更新すると毎回新しいアドレスにタイトルキーファイルが書き込まれることになる。このためBinding Nonceの書き込まれるアドレスも毎回異なる。しかし、ＡＡＣＳではBinding Nonceは同一個所に上書きすることが求められているため、ライトワンスメディアの場合は、タイトルキーファイルの更新を行わないようにしなければならない。従って、リライタブルメディアとライトワンスメディアでは、タイトルキーファイルの更新条件が異なることになる。
【００４９】
図８のTitle Key Fileの中には１９９８個の暗号化されたタイトル鍵（Encrypted Title Key）が記録されている。コンテンツはこの１９９８個のうちの１つの鍵を使って暗号化されている。１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは“０”という数値をＴＫ処理で暗号化したものを記述することになっている。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。Title Key Fileはタイトル鍵を保存するものであり、メディア上の欠陥等により読めなくなるとコンテンツの再生がまったく不能になる。このためバックアップ用に３つのファイルに書き込んでいる。この３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。
【００５０】
メディア１００上のTitle Key Fileが書き込まれているアドレスのプロテクト領域に、Binding Nonceという乱数を基にした数値を記録している。プロテクト領域とはＡＡＣＳ専用の特殊コマンドでのみ読み書きができる領域であり、この部分にＫｐａを構成する要素を記録しておくことで、パソコン等を使った不正な暗号解除を防ぐことができる。
【００５１】
Title Key File内のタイトル鍵は、プロテクテッドエリアキーとBinding Nonceの組み合わせてＴＫ処理を行うことで暗号化している。このとき、Title Key File#1の暗号化にはTitle Key File#2のBinding Nonceを使い、Title Key File#2の暗号化のBinding Nonceを使う、というようにしている。こうすることにより、３つのTitle Key Fileのうち１つが破損してしまっても、他の２つのファイルを用いることによって復元ができる。このようにBinding Nonceはタイトル鍵の暗号に用いているものであるので、Title Key Fileを更新する都度更新する。
【００５２】
一方、Binding Nonceはファイルが書き込まれるアドレスに依存しており、HD_DVD-R等のライトワンスメディアの場合、Title Key File自体が毎回新しいアドレスに保存されることになり、Binding Nonceの書き込まれる位置も一箇所ではなくなる。しかしＡＡＣＳではBinding Nonceは同一箇所に上書きすることが求められているので、ライトワンスメディアの場合はTitle Key Fileの更新を行わないようにする。
【００５３】
Title Key Fileには１９９８個のタイトル鍵を保存することが出来る。これはビデオオブジェクト（ＶＯＢ）及びストリームオブジェクト（ＳＯＢ）の個数と一致しており、ビデオオブジェクト毎にタイトル鍵（Ｋｔ）を変えることを前提としている。これは、例えばそのディスクから他のメディアにコンテンツをムーブする場合、使用しているタイトル鍵を消去しないと不正コピーができる抜け穴が残ってしまうためである。タイトル鍵を削除すると、同じタイトル鍵を共用している他のオブジェクトが復号できなくなるので、極力オブジェクトごとに異なる鍵を割り当てる必要がある。このため、録画再生装置においては、1回の録画処理毎にタイトル鍵を新規に生成し、そのタイトル鍵によってビデオオブジェクト及びストリームオブジェクトを暗号化する。
【００５４】
一方、特にストリームオブジェクト（ＳＯＢ）による録画の場合、記録対象のデジタル放送の内容によってストリームオブジェクトを動的に分割する必要がある。具体的には番組の境界で音声ストリームの個数が変わるなどストリームオブジェクト（ＳＯＢ）の構成要素が変わった場合は、自動的にそこでＳＯＢを分割する。このような場合、そこでタイトル鍵を切り替えるのは事実上不可能である（タイトル鍵を切り替えようとすると、新たな鍵の生成に時間を要するため、分割後のＳＯＢの録画を開始する際その先頭部分の録画が欠けてしまう）。このような場合は同じタイトル鍵を使った暗号を引き続き行う。
【００５５】
なお、ディスクがライトワンスメディア（上書きできないメディア）である場合はTitle Key Fileの更新ができないため、録画開始時に鍵を生成する処理において、既に存在するタイトル鍵を用いることになる。
【００５６】
図９は、メディア１００としてリライタブルメディア（HD_DVD-RW/RAMあるいはHDD等）を用いる場合において、リライタブルメディアのタイトルキーファイルの更新手続きを示すフローチャートである。従って、リライタブルメディアには、既にタイトルキーファイルが生成されて書き込まれている。なお、図９に示す処理動作は、情報記録再生装置２００の制御部２１０（あるいは後述する図１３のＡＡＣＳ処理部２１０ａのファームウエア）により実現される。
【００５７】
例えばユーザが情報記録再生装置２００の電源をＯＮし、図９のＳ４０においてリライタブルメディアを挿入すると、ＭＫＢ処理（Ｓ４１）とＴＫＦ読み込み処理（Ｓ４２）が一括して実行される。ＭＫＢ処理（Ｓ４１）では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理（Ｓ４２）では、メディアにあるタイトルキーファイルをＳＤＲＡＭ（後述する図１３の２２など）上に展開する。
【００５８】
そして、Ｓ４３、Ｓ４４において、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの更新を行うかどうかを判断する。即ち、以下の３つの条件のうちの少なくとも１つが満たされたときのみ、タイトルキーファイルを更新する。
【００５９】
（１）コンテンツの記録、削除が行われた場合
コンテンツの記録、削除が行われると、タイトルキーファイル内のEncrypted Title Keyが新たに追加、削除される。そのため、タイトルキーファイルを更新する。
【００６０】
（２）ＭＫＢが更新された場合
例えば、情報記録再生装置２００の内部で保持しているＭＫＢであるDevice MKBのバージョンがRead Write MKBのバージョンよりも新しい場合、Device MKBの値をRead Write MKBにコピーしてDevice MKBのメディア鍵（Ｋｍ）が変更される。このため、タイトルキーファイルを更新してタイトルキーの再暗号化を行う。
【００６１】
（３）３つのTitle Key File Generationの１つだけが異なる場合
上述のように３つのタイトルキーファイルの内の１つが破損していることになる。そのため、正常な残りの２つのタイトルキーファイルを用いて破損したタイトルキーファイルを修復（更新）する。すなわち、上述の３つの条件のうちの少なくとも１つが成立する場合は（Ｓ４４Ｙ）、タイトルキーファイルの更新を行う（Ｓ４５）。上述の３つの条件の全てが成立しない場合は（Ｓ４４Ｎ）、タイトルキーファイルを更新せずに処理を終了する（Ｓ４６）。
【００６２】
図１０は、メディア１００としてライトワンスメディア（片面１層のHD_DVD-Rあるいは片面２層のHD_DVD-R:DL等）を用いる場合において、ライトワンスメディアのタイトルキーファイルの書込み手続きを示すフローチャートである。なお、図９と同様に図１０に示す処理動作は、情報記録再生装置２００の制御部２１０（あるいは図１３のＡＡＣＳ処理部２１０ａ）により実行できる。
【００６３】
例えばユーザが情報記録再生装置２００の電源をＯＮし、図１０のＳ５０においてライトワンスメディアを挿入すると、ＭＫＢ処理（Ｓ５１）とＴＫＦ読み込み処理（Ｓ５２）が一括して実行される。ＭＫＢ処理（Ｓ５１）では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理（Ｓ５２）では、メディアにあるタイトルキーファイルをＳＤＲＡＭ（図１３の２２など）上に展開する。
【００６４】
そして、Ｓ５３、Ｓ５４において、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの書込みを行うかどうかを判断する。即ち、以下の２つの条件が満たされれば、タイトルキーファイルを書き込む。
【００６５】
（１＊）コンテンツの記録が行われた場合
（２＊）ディスクにタイトルキーファイルが記録されていなかった場合。
【００６６】
ＡＡＣＳではTitle Key Fileを同一箇所に上書きすることが求められているため、ライトワンスメディアの場合は、（１＊）と（２＊）の条件を同時に満たしたときにのみTitle Key Fileを書き込む。そうする理由を以下に述べる。
【００６７】
（１＊）の条件のみでは、コンテンツの記録が行われる度に書き込み要求が起こるため、同一箇所に上書き不可能なライトワンスメディアでは問題となる。（２＊）の条件のみでは、ディスクにコンテンツを記録していない状態では、有効なコンテンツキーは生成されていないため、無効なEncrypted Title KeyのみのTitle Key Fileとなり問題となる。（１＊）と（２＊）の条件を共に満たす場合には、ディスクにTitle Key Fileが記録されていない状態で記録が行われたときに書き込むこととなるため、有効なEncrypted Title Keyが１つだけ生成されたTitle Key Fileが記録されることになる。
【００６８】
上述の２つの条件がともに成立する場合は（Ｓ５４Ｙ）、タイトルキーファイルをディスクに書き込む（Ｓ５５）。上述の２つの条件が全て成立しない場合は（Ｓ５４Ｎ）、タイトルキーファイルの書き込みを行わずに処理を終了する（Ｓ５６）。
【００６９】
以上説明した実施の形態によれば、メディア種別ごとにタイトルキーファイルを書き込む条件を設け、その条件に合致するときのみにディスクに書き込む。この条件によれば、リライタブルメディアの場合は無駄にTitle Key Fileを更新することがなくなり、ディスクに書き込む回数を削減することができる。ライトワンスメディアの場合は、問題のあるTitle Key Fileを書き込こんでしまうことを排除することができる。
【００７０】
図１１は、この発明の一実施の形態に係るデータ構造例を説明する図である。RecordableあるいはRe-writableな情報記憶媒体の代表例として、ＤＶＤディスク（波長650nm前後の赤色レーザあるいは波長405nm以下の青紫ないし青色レーザを用いた、単記録層または複数記録層の、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、ＤＶＤ−ＲＡＭ等）１００がある。このディスク１００は、図１１に示すように、ファイルシステムが入っているボリューム／ファイル構造情報領域１１１とデータファイルを実際に記録するデータ領域１１２を含んで構成されている。上記ファイルシステムは、どのファイルがどこに記録されているかを示す情報で構成されている。
【００７１】
データ領域１１２は、一般のコンピュータが記録する領域１２０、１２２と、オーディオビデオデータ（ＡＶデータ）を記録する領域１２１を含んでいる。ＡＶデータ記録領域１２１は、ＡＶデータの管理をするためのビデオマネージャファイル（VMGまたはHDVR_MG）があるＡＶデータ管理情報領域１３０と、DVD-Video（ROM Video）規格に準じたオブジェクトデータのファイルが記録されるROM_Videoオブジェクト群記録領域１３１と、ビデオレコーディング（ＶＲ）規格に準じたオブジェクトデータ（ESOBS：Extended Video Object Set）のファイル（ＶＲＯファイル）が記録されるＶＲオブジェクト群記録領域１３２と、デジタル放送に対応したオブジェクトが記録されているストリームオブジェクトデータ（ESOBS：Extended Stream Object Set）ファイル（ＳＲＯファイル）が記録される記録領域１３３を含んで構成されている。なお、ＳＲＯファイルのためのレコーディング規格は、適宜、ストリームレコーディング（ＳＲ）規格と表記する。
【００７２】
図１２は、この発明の一実施の形態に係るファイル構造例を説明する図である。DVD_HDVRディレクトリは、図１２に示すように、HD_DVD-VRフォーマットの管理情報ファイルであるHR_MANGER.IFO、アナログビデオ入力のオブジェクトファイルであるＶＲＯファイル（最大レートが30.24Mbpsまで許されたEVOBファイル）を含むHDVR_VOBディレクトリ、デジタル放送対応用のＳＲＯファイル（ESOBファイル）を含むHDVR_SOBディレクトリ等を含んで構成されている。また、DVD_HDVRディレクトリと同じルートディレクトリ下のDVD_RTAVディレクトリは、DVD-VRフォーマットの管理情報ファイルであるVR_MANGER.IFO、アナログビデオ入力のオブジェクトファイルであるＶＲＯファイル（最大レートが10.08Mbpsに抑えられた従来DVD-VRのVOBファイル）等を含んで構成されている。
【００７３】
つまり、この実施の形態に係るファイル構造では、HDVRのMPEG2-TSデータファイルもHDVRのMPEG2-PSデータファイルもVRのMPEG2-PSデータファイルも同じルートディレクトリ下でファイル管理されている。例えば、HR_MOVIE.VROにリンクされたショートカットファイルをタイトルサムネールＡ、Ｃとし、VR_MOVIE.VROにリンクされたショートカットファイルをタイトルサムネールＢとし、HR_STRnn.SROにリンクされたショートカットファイルをタイトルサムネールＤとすれば、これらのタイトルサムネールＡ〜Ｄを同じメニュー画面上に表示することができる（図１３のモニタ画面５２ａの表示例参照）。これにより、ユーザは、別々のオブジェクト（MPEG2-PS、MPEG2-TSが混在するオブジェクト）を同じ画面操作環境でメニュー操作できるようになる。
【００７４】
図１３は、この発明の一実施の形態に係る記録再生装置（HD_DVDレコーダ）の構成例を説明するブロック図である。衛星デジタルＴＶ放送、地上デジタルＴＶ放送、および地上アナログＴＶ放送の受信機能を持つTV tuner１０のアナログＡＶ出力は、Video ADC１４およびAudio ADC１６に入力される。外部アナログ入力端子１２からのアナログＡＶ入力もまた、Video ADC１４およびAudio ADC１６に入力される。Video ADC１４でデジタル化されたビデオストリームおよびAudio ADC１６でデジタル化されたオーディオストリームはMPEG Encoder２０に入力される。外部デジタル入力端子１８からのデジタルストリーム（MPEG2-TS等）は、IEEE1394（あるいはHDMI）等のインターフェース１９を介して、MPEG Encoder２０に入力される。図示しないが、TV tuner１０からのデジタルストリーム（MPEG2-TS等）も適宜MPEG Encoder２０に入力される。MPEG Encoder２０は、入力されたMPEG2-TSをパススルーする場合以外は、入力されたストリームをMPEG2-PSにエンコードするか、MPEG4-AVCにエンコードする。
【００７５】
ここで、MPEG2-PSにエンコードする場合としては、DVD-VR規格に基づきMPEG2-PSにエンコードする場合（最大レート10.08Mbps；最大解像度720x480または720x576）と、HD_DVD-VR規格に基づきMPEG2-PSに高レートエンコードする場合（最大レート30.24Mbps；最大解像度1920x1080）と、HD_DVD-VR規格の枠内でMPEG2-PSに低レートエンコードする場合（最大レート10.08Mbps；最大解像度720x480または720x576）がある。
【００７６】
MPEG Encoder２０でエンコードされ（またはパススルーした）ストリームデータは、SDRAM（Synchronous Dynamic Random Access Memory）２２等の高速メモリに一旦バッファリングされる。このSDRAM２２上で、下記の１〜３のストリーム書き換え処理が適宜行われる：
1.AudioがLiner PCMである場合、Audio Packのsub_stream_idの値を書き換える；
2.RDI-PCKの記載内容を書き換える；
3.一度CPRMの暗号を復号し、ＡＡＣＳに再暗号化を行う、もしくはその逆を行う。
【００７７】
SDRAM２２にバッファリングされそこで処理されたストリームデータは、その内容に応じて、所定のタイミングでＨＤＤ１０４かHD_DVD Drive２６かDVD Drive２８に転送される。ＨＤＤ１０４としては大容量ハードディスクドライブ（例えば１ＴＢ）が用いられる。また、HD_DVD Drive２６には青色レーザ（例えば波長λ=405nm）が用いられ、DVD Drive２８には赤色レーザ（例えば波長λ=650nm）が用いられる。
【００７８】
HD_DVD Drive２６およびDVD Drive２８はDrive Unit２４を構成している。Drive Unit２４は、回転駆動系を含めて独立した２基のドライブを備えている場合と、回転駆動系が共通で青色レーザの光ヘッドと赤色レーザの光ヘッドを個別に有するHD_DVD/DVDコンパチブルドライブ（ツインピックアップタイプ）を備えている場合と、回転駆動系および光ヘッドの機構が共通で青色レーザまたは赤色レーザを切替使用する２波長光学系を有する場合（シングルピックアップタイプ）がある。
【００７９】
図１３の実施の形態では、回転駆動系を含めて独立した２基のDrive２６およびDrive２８がある場合を例示している。これらのドライブで使用される情報記憶媒体（青色レーザ用光ディスク１００、赤色レーザ用光ディスク１０２）としては、青色レーザ使用の場合も赤色レーザ使用の場合も、-R/−RW/RAMタイプの光ディスクの他に、+R/+RWタイプの光ディスクが利用可能である。将来的には、ホログラムを利用した大容量光ディスクを用いることも可能である。
【００８０】
HD_DVD Drive２６はHD_DVD-VR規格に基づく記録再生に対応し、DVD Drive２８はDVD-VR規格に基づく記録再生に対応している。DVD Drive２８はさらに、HD_DVD-VR規格に基づきエンコードされたデータであっても、最大レートやビデオ属性等がDVD-VR規格の枠内に収まるMPEG-PSのデータについては、DVD-VR規格のディスク（片面１層のDVD-R/RW/RAM、片面２層のDVD-R、両面各１層のDVD-RAM等）１０２を用いて等速または高速で記録再生することができるように構成されている。（具体例を挙げれば、最大レート10.08MbpsでＨＤＤ１０４に記録されたNTSCのビデオのMPEG2-PSデータは、それがHD_DVD-VR規格に基づきエンコードされたデータであっても、DVD-VR規格のディスク１０２に高速コピー／高速ダビングできるように構成される。言うまでもないが、このHD_DVD-VR規格に基づきエンコードされたMPEG2-PSデータは、HD_DVD-VR規格のディスク１００にも高速コピー／高速ダビングできる。）
HD_DVD Drive２６、DVD Drive２８、および／またはＨＤＤ１０４から再生されたストリームデータは、SDRAM２２を介してMPEG Decoder３０に転送される。MPEG Decoder３０は、転送されてきたストリームに応じて、MPEG2-TSをデコードする機能、MPEG2-PSをデコードする機能、MPEG4-AVCをデコードする機能、その他のデコード機能（例えばHD_DVD-VR規格で定められているVC-1をデコードする機能）を備えている。MPEG Decoder３０でデコードされたビデオデータ（MPEG2-TSまたはMPEG2-PS）はVideo DAC３２により標準画質または高精細画質のアナログビデオ信号に変換されてVideo Out端子３６から出力される。また、MPEG Decoder３０でデコードされたオーディオデータはAudio DAC３４によりアナログオーディオ信号に変換されてAudio Out端子３８から出力される。さらに、デコードされたデータがMPEG2-TSの場合は、適宜、IEEE1394（あるいはHDMI）等のインターフェース３７を介してDigital Out端子３９から外部出力される。MPEG Decoder３０でデコードされDAC３２、３４でＤ／Ａ変換されたＡＶ信号（アナログビデオ信号およびアナログオーディオ信号）は、外部モニタに入力される。
【００８１】
図１３の記録再生装置（HD_DVDレコーダ）の動作は、ＭＰＵ４０により制御される。ＭＰＵ４０にはファームウエアや種々な制御パラメータを格納するＥＥＰＲＯＭ４２、ワークＲＡＭ４４、タイマ４６等が付属している。ＭＰＵ４０のファームウエアの中身としては、グラフィックユーザインターフェースを提供するＧＵＩ表示制御部４００、エンコードパラメータ検出処理部４０２、高速コピー（高速ダビング）処理部４０４、レート変換コピー（等速コピー／等速ダビング）制御部４０６、記録／再生制御部（管理情報処理部）４０８、ＡＡＣＳ処理部２１０ａ（図２の制御部２１０に対応）等がある。ＧＵＩ表示制御部４００の処理結果は、オンスクリーン表示部（ＯＳＤ）５０を介して外部モニタにて画面表示される（タイトルサムネールの表示画面５２ａ、５２ｃ等はＯＳＤ５０の処理で得ることができる）。
【００８２】
図１３の実施の形態において、ＨＤＤ１０４については、１台の超大容量ＨＤＤ（例えば１ＴＢ）でも、複数の大容量ＨＤＤの併用（例えば５００ＧＢ＋５００ＧＢ）でもよい。また、ＨＤＤの記録エリアの使い方としては、その記録エリアを論理的に複数パーティションに分けて使用する場合と、物理的なＨＤＤ毎に用途を特定する場合がある。前者の場合としては、例えば１ＴＢのうち４００ＧＢの第１パーティションをデジタル高精細放送のMPEG2-TS記録用（ＴＳタイトル用）に割り当て、４００ＧＢの第２パーティションをデジタル高精細放送のMPEG4-AVC記録用（ＨＤＶＲタイトル用）に割り当て、２００ＧＢの第３パーティションをアナログ放送またはデジタル放送もしくは外部入力のMPEG2-PS記録用（ＶＲタイトル用）に割り当てるなどが考えられる。また、後者の場合としては、例えば第１の４００ＧＢＨＤＤをMPEG2-TS記録用（ＴＳタイトル用）に割り当て、第２の４００ＧＢＨＤＤをMPEG4-AVC記録用（ＨＤＶＲタイトル用）に割り当て、第３の２００ＧＢＨＤＤをMPEG2-PS記録用（ＶＲタイトル用）に割り当てるなどが考えられる。
【００８３】
なお、この発明の一実施の形態では、ＶＲタイトルには、現行のDVD-VR規格によるMPEG2-PS記録の他に、次世代HD_DVD規格において最大レートを10.08Mbpsに抑えたMPEG2-PS記録も含まれる。あるＶＲタイトルのストリームデータがDVD-VR規格によるMPEG2-PSなのかHD_DVD規格において最大レートを10.08Mbpsに抑えたMPEG2-PSなのかの区別は、オブジェクトデータレベルでは、オブジェクトデータ内の特定情報（例えばプログラム最大レート “program_mux_rate”）の記述内容が「10.08Mbps」なのか「30.24Mbps」なのかで行うことができる。また、管理情報レベルでは、そのタイトルの再生開始前に、管理情報内の特定情報（例えばビデオ属性“V_ATR”）が現行DVD-VR規格ではあり得ない解像度（例えば1280x1080）を含んでいるかどうかで行うことができる。
【００８４】
前述した複数種類のタイトル（ＴＳタイトル、ＨＤＶＲタイトル、ＶＲタイトル）は、この発明の一実施の形態では、図１２に例示するように同じディレクトリ内でファイル管理される。そのため、複数種類のタイトル（ＴＳタイトル、ＨＤＶＲタイトル、ＶＲタイトル）のアイコンまたはサムネールを同一画面５２ａ（または５２ｃ）上で表示できる。このことから、ユーザは、複数タイトルの各々がどんな規格（HD_DVD-VR、DVD-VR等）のどのような状況下で録画されたものでも（最大レートが10.08MbpsのHD_DVD-VR録画、最大レートが10.08MbpsのDVD-VR録画等）、それらを同様に操作できる。
【００８５】
なお、メニュー画面５２ａでは、各タイトルのサムネールが、著作権行使をしないフォントＦｚおよび著作権を行使しないイメージ文字パターンＦｙの他に、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘが用いられている。メニュー画面５２ａの情報およびそれに対応するタイトルのオブジェクト（ＶＯＢおよび／またはＳＯＢ）はＡＡＣＳで暗号化され、ＡＡＣＳ対応のメディア１００に記録される（図１８を参照して後述する）。
【００８６】
ここで、「著作権行使をしないフォントＦｚ」とは、著作権の期限切れでパブリックドメインになったフォントのほかに、著作権が生きていても、著作権者が第三者の自由な利用を認容あるいは黙認しているフォントも含む。一方、仮にパブリックドメインにあったフォントでも、例えば図１３の機器のメーカにより変更が加えられた結果新たなlook-and-feelを備えるようになったフォントは、著作権付きフォントとなり得る。
【００８７】
記録先がＡＡＣＳに対応していないメディア（例えば従来のＤＶＤ−Ｒ／ＲＷ／ＲＡＭディスク１０２、あるいはＨＤ＿ＤＶＤ以外の規格によるメディア）であるときは、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘのないメニュー画面５２ｃが作成され、その情報がＡＡＣＳ非対応のメディア１０２に記録される（この場合オブジェクトの暗号化には、例えばＣＳＳ（Content Scramble System）方式が用いられる。
【００８８】
もしくは、記録先がＡＡＣＳに対応していないメディア（例えばHD_DVDのドライブで使用可能に作製されていてもＡＡＣＳで必要なMedia IDが記録されていないディスク）であるときは、メニューを作成しない（結果的にメニューがＡＡＣＳ非対応ディスクに記録されることはない）ようにしてもよい。HD_DVDのInteroperable Contentの場合、従来のDVD Videoと同じくメニューはオプション扱いとなっている。このため、HD_DVDで使用可能に作製されていてもＡＡＣＳに対応していないディスクがドライブに挿入されたら、何も表示せずに即、そのディスクに記録されたタイトルを（管理情報VMG/HDVR_MG内のプログラムチェーン情報の記述に従って）順番に再生することも可能である。この場合は著作権保護付きフォントは使わずに済む。
【００８９】
図１４は、この発明の一実施の形態に係る記録方法を説明するフローチャートである。この記録方法の処理は、あるオブジェクト（ＶＯＢまたはＳＯＢ）の１回の記録が行われる毎に実行される。例えば、著作権保護されたデジタル放送の番組Ａと番組Ｂが電子プログラムガイド（ＥＰＧ）等を用いることで録画予約されているとする。この場合、番組Ａの予約録画が行われるときに図１４の処理が（ある暗号鍵を用いて）実行されて、例えば番組Ａ相当のビデオオブジェクトＶＯＢ（ＭＰＥＧ４ＡＶＣ等）が暗号化されて光ディスク（例えば図１３の１００）またはハードディスク（例えば図１３の１０４）に記録される。また、番組Ｂの予約録画が行われるときには図１４の処理が（別の暗号鍵を用いて）改めて実行されて、例えば番組Ｂ相当のストリームオブジェクトＳＯＢ（ＭＰＥＧ２ＴＳ等）が暗号化されて光ディスク（１００）またはハードディスク（１０４）に記録される。
【００９０】
上記のような１回の記録が開始されると、ＡＡＣＳ方式の暗号化に用いる鍵（タイトル鍵ＫｔまたはContents key）が生成される（ＳＴ１００）。この鍵生成処理は、図３を参照して説明した処理と同様に行うことができる。なお、記録先の媒体がハードディスクやHD_DVD-RW/RAM等の上書き可能なメディアであればＳＴ１００で新たに鍵の生成を行う。
【００９１】
しかし、記録先の媒体がHD_DVD-R（または片面２層のHD_DVD-R：DL）等の上書き不能なライトワンスメディアであるときは、後述する図１７の処理により、所望数の鍵（Title Keys）を同じファイル（Title Key File）内に予め用意しておく。そして、これらの予め用意された複数鍵を適宜（あるいは順次）用いることで、上書き不能なライトワンスメディアにおいても、鍵の更新を実質的に可能としている。
【００９２】
これらの鍵は更新で使い切ることがないように必要十分な数が予め用意される。しかし、もし、何らかの理由で予め用意した複数鍵を全て使い切ってしまった場合は、最後に更新された鍵をそのメディアでの既存の鍵（Ｋｔ）とし、以後はその既存鍵（Ｋｔ）を利用するようにしてもよい（ＳＴ１００での最後の括弧書き参照）。
【００９３】
記録対象のオブジェクトの記録中、そのオブジェクトの分割がないときは（ＳＴ１０２Ｎ）、ＳＴ１００で生成された鍵を用いて（ＡＡＣＳ方式により）オブジェクトを暗号化しつつ（ＳＴ１０６）、暗号化されたオブジェクトを記録媒体（ハードディスクまたは光ディスクもしくは半導体メモリ）に記録する（ＳＴ１０８）。記録対象のオブジェクトに対する１回の記録が終了していない間は（ＳＴ１１０Ｎ）、ＳＴ１０２〜ＳＴ１１０の処理が反復される。
【００９４】
記録対象のオブジェクト（例えば番組ＢのＳＯＢ）の記録中、そのオブジェクトが例えば録画ポーズあるいはビデオ属性の変更などにより分割されたときは（ＳＴ１０２Ｙ）、その後の記録処理を別の記録処理としてカウントすると、見かけ上１回の録画処理でなくなる。しかし、その場合は１回の録画処理内の出来事とみなし、分割前のオブジェクト（例えば番組Ｂの前半のＳＯＢ）の暗号化で用いた鍵（Ｋｔ）を分割後のオブジェクト（例えば番組Ｂの後半のＳＯＢ）に適用する（ＳＴ１０４）。このようにすると、新たな鍵生成処理（図３を参照して述べたような処理）を省略できるため、新たな鍵生成のためのタイムラグがなくなり、分割後のオブジェクトの暗号化（ＳＴ１０６）とその記録（ＳＴ１０８）を滞りなく実行できる（具体的には、分割後のオブジェクトの記録を継続する際にその冒頭が切れてしまう恐れを払拭できる）。
【００９５】
以上のようにして、記録対象のオブジェクトの１回の記録が終了すると（ＳＴ１１０Ｙ）、記録されたオブジェクトを再生する際に必要な種々な管理情報がHR_MANGR.IFOファイル（図１２参照）に記録されて（ＳＴ１１２）、図１４の記録処理は終了する。
【００９６】
図１５は、この発明の一実施の形態に係る再生方法を説明するフローチャートである。図１４のような処理でオブジェクトデータ（ＶＯＢおよび／またはＳＯＢ）および管理情報が記録されたディスク１００から、再生しようとするオブジェクト（例えば番組ＢのＳＯＢ）の管理情報が読み取られる（ＳＴ２００）。この管理情報（例えば図１２のHR_MANGR.IFO）は、ディスク１００に記録された複数タイトル（オブジェクト）のうちユーザが再生対象を選択する際に用いるメニュー（例えば図１３の５２ａあるいは５２ｃ）の情報も含むことができる。読み取られた管理情報は、再生機器のワークメモリ（図１３の４４等）に一旦記憶される。
【００９７】
この再生機器（図２の２００相当）は、再生しようとするオブジェクトの暗号化に関する情報（Ｋｍ，Ｋｐａ，Ｋｔ等を生成するための元になる情報）を光ディスク（例えば図１３の１００）またはハードディスク（例えば図１３の１０４）から読み取り（ＳＴ２０２）、読み取った情報から復号鍵（ＫｔまたはContents Key）を生成する（ＳＴ２０４）。ここで、Ｋｍ，Ｋｐａ，Ｋｔ等を生成するための元になる情報とは、Lead-in MKB、Read Write MKB、Binding Nonce、Title Key File、Usage Rule Fileなどを言う（図２参照）。この復号鍵生成処理は、図２を参照して説明した処理と同様に行うことができる。こうして読み取られた管理情報（HR_MANGR.IFOファイル）と生成した復号鍵（ＫｔまたはContents Key）を用いて、再生対象オブジェクトを復号しながら再生する（ＳＴ２０６）。この再生処理が再生対象オブジェクトの末尾まで済むと（あるいはユーザもしくは装置の制御プログラムが再生停止を指示すると）（ＳＴ２０８Ｙ）、図１５の再生処理は終了する。
【００９８】
ところで、メディア１００上のTitle Key Fileが書き込まれているアドレスのプロテクト領域には、Binding Nonceという乱数を基にした数値が記録されている。プロテクト領域とはＡＡＣＳ専用の特殊コマンドでのみ読み書き（アクセス）ができる領域であり、この部分にProtected Area Key（Ｋｐａ）を構成する要素を記録しておくことで、パソコン（ＰＣ）等を使った不正な暗号解除を防ぐことができる。このBinding NonceはTitle Key Fileを更新する都度更新する必要がある。
【００９９】
一方、Binding Nonceはファイルが書き込まれるアドレスに依存しており、HD DVD-R等のライトワンスメディアの場合、Title Key File自体が毎回新しいアドレスに保存されることになり、Binding Nonceの書き込まれる位置も一箇所ではなくなる。しかしＡＡＣＳではBinding Nonceは同一箇所に上書きすることが求められているので、ライトワンスメディアの場合、Title Key Fileの更新は、ＡＡＣＳを採用する限りできないことになる。
【０１００】
このようにライトワンスメディアではTitle Key Fileの更新ができないため、そのメディアを記録に初めて使用する際、一番最初にTitle Key Fileを作成するときに予め必要な数分だけTitle Keyを生成しておく。しかし最大数である１９８８個もTitle Keyを作る必要はなく、必要最低限の個数のみ作成すれば良い。必要最低限の個数とは、全コンテンツを１つの鍵で共通とすれば１つあれば良いことになる。しかし、それでは１枚のライトワンスメディアにＡＡＣＳで管理される個別の複数コンテンツ（例えば個別の複数デジタル放送番組）を記録できなくなる。
【０１０１】
ＡＡＣＳには、Title Usage Rule Fileという、コンテンツごとの利用制限などが記載されたファイルがある。このTitle Usage Rule Fileの例が図１６に示されている。利用制限のルールを記述する欄は図１６（ａ）のUsage Rule#1〜Rule#1998まで１９９８個用意されており、これはTitle Keyの番号と対応が取られている。つまり、Title Key#1のUsage RuleはUsage Rule#1に相対する。
【０１０２】
図１６（ｂ）はUsage Ruleのデータ構造であり、UR_FLGはこのルールの有効・無効を示すビットである。無効なルールの場合はUR_FLGのビットには０が記載される。その後のＤＯＴ−Ｐ、ＤＯＴというのがルール（使用規則あるいは利用制限）の本体であり、例えばＤＯＴ（Digital Only Token）が1の場合はそのコンテンツをアナログ出力してはならないというルールとなる。前述のようにルールはTitle Keyと相対しているため、コンテンツに暗号化を施す際の採用ルールが異なる場合は、Title Keyも異ならなくてはならない。このため、Usage Ruleの種類の数に応じて、そのルールを適用したTitle Key、ルールを適用しないTitle Keyの２つのTitle Keyが必要になる。現時点ではＤＯＴとＤＯＴ−Ｐの２つのルールがＡＡＣＳで定義されているため、実際の運用上は最小限４種類のTitle Keyを予め作成しておく必要がある。
【０１０３】
また、コンテンツを暗号化するための鍵のほかに、Interoperable ContentのAdvanced Resource Fileを暗号化するためにも鍵が必要である。すべてのResource Fileで共通の鍵を使っても構わないので、Interoperable ContentのAdvanced Resource Fileを暗号化するための鍵の最低個数は1となる。（なお、“Interoperable Content”とは、記録再生系のHD_DVD-Video Recording規格内で記録されるコンテンツのうち再生系のHD_DVD-Video規格に準拠したプレーヤでも再生できるコンテンツをいう。）
従って、ライトワンスメディア１００に最初にTitle Key Fileを作成する際は、Title Usage Rule Fileの個数＋１個のコンテンツ用タイトル鍵と、1個のAdvanced Resource File用タイトル鍵を予め生成しておけば、Title Key Fileが更新できないライトワンスメディアであっても、ＡＡＣＳの運用を行うことが可能になる。
【０１０４】
図１７は、ライトワンスメディアに最初にTitle Key Fileを書き込む際の処理手順の一例を説明するフローチャートである。不正アクセスから保護しようとするコンテンツ（Title）をＡＡＣＳにより暗号化するための鍵（Title KeyまたはＫｔ）のファイル（Title Key File）を最初に作成するのは、例えば図１４のスタートから図１７の処理にエンターする際（あるいは図１４のＳＴ１００の処理内）である。その際に、Usage Rule File内の規則数（例えば図１６ｂのＤＯＴとＤＯＴ−Ｐの２つ）に対応する数（Usage Ruleの組み合わせの数、例えば４つ）分、Title Key（またはＫｔ）を作成する（ＳＴ３００〜ＳＴ３０２）。また、著作権保護されたAdvanced Resource File（ＡＲＦ）がある場合、もしくはそのようなＡＲＦが今後作成され得る場合（ＡＲＦが将来作成される見込みがある場合）（ＳＴ３０４Ｙ）は、そのＡＲＦ用のTitle Key（またはＫｔ）を別途作成する（ＳＴ３０６）。こうして、所望数（Usage Ruleの組み合わせの数および、適宜、ＡＲＦ用Title Keyの数）だけTitle Key（またはＫｔ）を作成する（ＳＴ３００〜ＳＴ３０６）。作成した数のTitle Key（またはＫｔ）はTitle Key Fileに書き込まれる（ＳＴ３０８）。
【０１０５】
その後、図１４の処理へリターンし、Title Key Fileに書き込まれたTitle Key（またはＫｔ）を用いて（ＳＴ１００）コンテンツ（Title）を暗号化し（ＳＴ１０６）、暗号化されたコンテンツ（Title）をライトワンスメディア（HD_DVD-R等）に記録する（ＳＴ１０８〜ＳＴ１１２）。
【０１０６】
ここで、コンテンツ（Title）とは別に保護すべき内容を含む資源情報、すなわち前記Advanced Resource File（ＡＲＦ）の具体例としては、フォント、効果音、静止画等の情報がある。とくに、高精細画面で用いられる美しいベクターフォント（例えば図１３のモニタ画面５２ａで表示される各タイトル文字やその番組説明のフォント、あるいは図示しないがメニュー以外の画面における字幕等のフォント）は著作権保護の必要性が高い（パソコン等を用いてそのフォントが著作権者に無断で不正使用される可能性が高い）。そのため、このような高精細フォントは、著作権保護されている（パブリックドメインでない）限り、ＡＡＣＳによる暗号化・復号化の対象となり得る。
【０１０７】
図１７の処理を簡単に整理すると、次のようになる。まずUsage Rule Fileにいくつルールを書き込むかを求め（ＳＴ３００）、その個数だけTitle Keyを生成する（ＳＴ３０２）。またAdvanced Resource Fileの暗号が必要である場合には（ＳＴ３０４Ｙ）、更に１つTitle Keyを生成する（ＳＴ３０６）。そこで生成されたTitle KeyをＴＫ処理で暗号化したものをTitle Key File内に書き込む（ＳＴ３０８）。
【０１０８】
なお、記録先のメディアがライトワンスメディアでなく反復書き換え可能なメディア（例えばHD_DVD-RAM、ハードディスク、半導体フラッシュメモリ等）の場合は、図１７のＳＴ３００をスキップし、ＳＴ３０２のところでTitle Keyを１つ生成するようにしてもよい。
【０１０９】
図１８は、著作権保護された情報資源（フォント等）をメニュー等に利用する場合の処理手順の一例を説明するフローチャートである。例えば図１３のHD_DVD Drive２６にディスクが装填されると、図１３のＭＰＵ４０のファームウエアは、そのディスクのＢＣＡあるいはリードインエリア内の情報を読み取ることで、そのディスクがＡＡＣＳ対応メディアであるか否かのチェックを行う（ＳＴ５００）。そのディスクがＡＡＣＳに対応したメディアである場合は（ＳＴ５００Ｙ）、図１７のＡＲＦ等の資源情報（著作権付フォント等）を用いて、例えば図１３のメニュー画面５２ａを作成する（ＳＴ５０２）。そして、ＡＲＦの一部分（メニューで用いられるフォントのうち著作権付きのフォント等）をＡＡＣＳで暗号化（図１７のＳＴ３０６と同様）してメディア１００に記録する（ＳＴ５０４）。
【０１１０】
一方、ＡＡＣＳに対応していないメディアである場合は（ＳＴ５００Ｎ）、ＡＲＦの前記一部分（著作権付フォント等）を用いないで、例えば見かけが別のメニュー（図１３の５２ｃ等）を作成する（ＳＴ５１０）。もしくは、記録先がＡＡＣＳに対応していないメディア（例えば従来のＤＶＤ−Ｒ／ＲＷ／ＲＡＭディスク１０２、あるいはＨＤ＿ＤＶＤ以外の規格によるメディア）であるときは、ＳＴ５１０の処理において、メニューを作成しない（結果的にメニューがＡＡＣＳ非対応ディスクに記録されることはない）ようにしてもよい。
【０１１１】
ところで、HD_DVD Video Recording Formatでは、ＶＯＢで構成されたコンテンツをHD_DVD Video Playerでも再生できるように、「Interoperable Contentと呼ばれるHD_DVD VideoのAdvance Content形式のＸＭＬ形式のスクリプト」をレコーダ（例えば図１３）側で記録することが必須機能となっている。
【０１１２】
Interoperable Contentでは、例えばメニュー中にテキストを表示するのに使うフォントはディスク内のAdvance Resource File（ＡＲＦ）というファイルに保存されている。従って、レコーダでフォントをディスクに書き込まないと、メニューに文字を表示することができない。このフォントデータはOpen Type Font形式であり、パソコンなどでも使用可能な一般的なものである。従ってレコーダでフォントのデータをディスクに書き込むと、そのフォントは他の目的にも流用可能になってしまう。
【０１１３】
これを防ぐため、HD_DVDのAdvance Resource FileはＡＡＣＳで暗号を施すことが規格上許されている。暗号化されていれば、そのHD_DVDディスクからファイルをコピーしても解読することができず、フォントの流用を防ぐことができる。ＡＡＣＳは、対応のメディアに記録されているMedia ID等を利用して暗号化を施す。従って、ＡＡＣＳ非対応メディアに対しては暗号化を施すことができない。このため、まずＡＡＣＳ対応・非対応の判定を行い、ＡＡＣＳ非対応メディアの場合はInteroperable Contentのメニュー等にテキストを使用せず暗号化の不要なイメージデータ等（図１３の例ではＦｙ，Ｆｚ）のみを使い、著作権保護されたフォント等（図１３の例ではＦｘ，Ｉｘ）をディスクに保存しないようにする。一方ＡＡＣＳ対応メディア１００の場合は、フォントが暗号によって保護されるので、テキストを用いたメニューを生成し（図１８のＳＴ５０２）、フォントデータ（そのデータを含むファイル）はＡＡＣＳで暗号化する（図１８のＳＴ５０４）。
【０１１４】
なお、図１３のメニュー画面５２ａでは、各タイトルのサムネールが、著作権行使をしないフォントＦｚおよび著作権を行使しないイメージ文字パターンＦｙの他に、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘが用いられている。メニュー画面５２ａの情報およびそれに対応するタイトルのオブジェクト（ＶＯＢおよび／またはＳＯＢ）はＡＡＣＳで暗号化され、ＡＡＣＳ対応のメディア１００に記録される。
【０１１５】
一方、記録先がＡＡＣＳに対応していないメディア（例えば従来のDVD_R/RW/RAMディスク１０２）であるときは、著作権付きフォントを用いたテキストＦｘおよび著作権付き画像Ｉｘのいずれもないメニュー画面５２ｃが作成され（図１８のＳＴ５１０）、その情報がＡＡＣＳ非対応のメディア１０２に記録される（この場合オブジェクトの暗号化には、例えばＣＳＳ（Content Scramble System）方式が用いられる。
【０１１６】
なお、対象メディアが「ＡＡＣＳ対応メディア」であるか否かは、例えばそのメディアの種類に応じて適宜判定できる。例えば、メディアがHD_DVD-R/RW/RAMディスクの場合は、そのディスクのリードインエリアの内側の一部に、そのディスクに固有の情報がバーコード状のパターンで記録されるＢＣＡ（Burst Cutting Area）が設けられている。このＢＣＡのレコード中に、ＨＤ＿ＤＶＤの規格識別子（HD_DVD book type Identifier）を含む情報（BCA Record ID）、ＨＤ＿ＤＶＤの規格形式とディスク形式の情報（Book type and Disc type）等を記述することができる。このような情報を含むＢＣＡレコードからそのディスクがＨＤ＿ＤＶＤ規格のディスクであると判明すれば、そのディスクは「ＡＡＣＳ対応メディア」であると判定できる（ＢＣＡレコードがＨＤ＿ＤＶＤ規格のディスクでないことを示すときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１１７】
なお、対象メディアのＢＣＡ中に前述したMedia IDがあるときは、このMedia IDから「ＡＡＣＳ対応メディアであるか否か」の判定を行う方法もある。
【０１１８】
また、ディスクのリードインエリア内にＲＭＡ（Recording Management Area）が設けられ、このＲＭＡ内にそのディスクがＨＤ＿ＤＶＤ規格のディスクであることを識別するディスク固有の情報（Unique Disc ID）が記述されておれば、その記述内容から、そのディスクは「ＡＡＣＳ対応メディア」であると判定する方法もある（Unique Disc IDからＨＤ＿ＤＶＤ規格のディスクであると識別できないときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１１９】
さらに、メディアがHD_DVD-R/RW/RAMあるいはHD_DVD Video（ROM disc）の場合では、そのディスクのリードインエリアの内側に物理フォーマット情報（Physical format information）を記録することができる。この物理フォーマット情報内にＨＤ＿ＤＶＤの規格形式とそのパートバージョンの情報（Book type and Part version）が記述されておれば、その記述内容から、そのディスクは「ＡＡＣＳ対応メディア」であると判定できる（Book type and Part versionがＨＤ＿ＤＶＤ規格に該当しないときは、ＡＡＣＳ非対応メディアとして扱うことができる）。
【０１２０】
＜実施の形態のまとめ＞
（１）ＨＤ＿ＤＶＤメディアに対してHD DVD Video Recording Formatで記録する録画再生装置において、その装置のディスクドライブに挿入されたメディアがＡＡＣＳに対応したものである場合、Interoperable Contentで使用するフォントをAdvanced Resource FileとしてＡＡＣＳで暗号化して記録する。
【０１２１】
（２）ＨＤ＿ＤＶＤメディアに対してHD DVD Video Recording Formatで記録する録画再生装置において、その装置のディスクドライブに挿入されたメディアがＡＡＣＳに対応していないものである場合、（著作権保護されたフォントの）文字は使用せず、イメージデータのみ（あるいは著作権が行使されないフォントとイメージデータ）で構成されるメニューを表示するようなInteroperable Contentを生成する。
【０１２２】
＜実施の形態の効果＞
Interoperable Contentを生成する際、Interoperable Contentが記録されるメディアのＡＡＣＳ対応／非対応の別により、（著作権保護された）フォントをディスクに記録する／しない（あるいはそのようなフォントを含むメニューをディスクに記録する／しない）を分けることで、フォントの不正な流用を防ぐことができる。
【０１２３】
＜その他＞
（01）この発明の一実施の形態に係る情報アクセス管理方法は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（メニューあるいはビデオプログラム中の各画面等）の情報を情報記録媒体（１００）に適宜記録する際に利用される。ここでは、前記情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かをチェックし（ＳＴ５００）、前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（例えばメニュー画面：図１３の画面５２ａ等）を作成し（ＳＴ５０２）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する（ＳＴ５０４）。一方、前記所定の暗号化方式（ＡＡＣＳ）に対応していないメディアである場合は（ＳＴ５００Ｎ）、前記資源情報の前記部分（著作権付フォント等）を用いないで前記所定画面（例えば見かけが別のメニュー：図１３の５２ｃ等）を作成するか、または前記所定画面（メニュー）を作成しない（ＳＴ５１０）。
【０１２４】
（02）前記情報記録媒体（１００）が、前記所定の暗号化方式（ＡＡＣＳ）に対応した記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテント（Interoperable Content）を記録できるメディア（HD_DVD-R/RW/RAM等）である場合は、前記インターオペラブルコンテントで用いられるフォントを用いてメニュー（図１３の５２ａ）を作成し（ＳＴ５０２）、前記インターオペラブルコンテントで用いられるフォントを所定のファイル（Advanced Resource File：ＡＲＦ）に格納し、このファイル（ＡＲＦ）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化して前記情報記録媒体（１００）に記録する（図１７のＳＴ３０６、ＳＴ３０８）。
【０１２５】
（03）前記情報記録媒体（１００）が、前記所定の暗号化方式（ＡＡＣＳ）に対応しない記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテント（Interoperable Content）を記録できるメディア（HD_DVD-R/RW/RAM等）である場合は、前記インターオペラブルコンテントで用いられるフォントを用いないでメニュー（図１３の５２ｃ）を作成するか、またはメニューを作成しない（ＳＴ５１０）。
【０１２６】
（04）前記メニュー（図１３の５２ａまたは５２ｃ）の情報が記録された前記情報記録媒体（１００）から、このメニューの情報を含む管理情報（HR_MANGR.IFO）を読み取り（ＳＴ２００）、この管理情報で管理されるオブジェクトを再生する（ＳＴ２０２〜ＳＴ２０６）ことができる。
【０１２７】
（05）この発明の一実施の形態に係る記録装置（図１３のエンコード側）は、不正アクセスから保護しようとする部分（著作権付フォント等）を含む資源情報（フォント、効果音、静止画等）を利用した所定画面（図１３の５２ａ等）の情報を情報記録媒体（１００）に記録するように構成される。この装置は、前記情報記録媒体（１００）が所定の暗号化方式（ＡＡＣＳ）に対応したメディアであるか否かをチェックし（図１８のＳＴ５００）、前記所定の暗号化方式（ＡＡＣＳ）に対応したメディアである場合は（ＳＴ５００Ｙ）、前記資源情報（著作権付フォント等）を用いて前記所定画面（図１３の５２ａ等）を作成する手段と（図１８のＳＴ５０２を処理する図１３の２１０ａ、４００）、前記資源情報の前記部分（メニューで用いられるフォントのうち著作権付きのフォント等）を前記所定の暗号化方式（ＡＡＣＳ）で暗号化（図１７のＳＴ３０６と同様）して前記メディアに記録する手段と（図１８のＳＴ５０４を処理する図１３の２１０ａ、４０８、２０〜２４）を具備している。
【０１２８】
（06）この発明の一実施の形態に係る再生装置（図１３のデコード側）は、所定の鍵（Title KeyまたはＫｔ）を用いて所定の暗号化方式（ＡＡＣＳ）により暗号化されたコンテンツ（Title）および暗号化されたリソースファイル（ＡＲＦ）を前記所定の暗号化方式（ＡＡＣＳ）に対応した情報記録媒体（１００）から再生するように構成される。この装置は、前記コンテンツ（Title）の管理情報（HR_MANGR.IFO）を前記情報記録媒体（１００）から読み取る手段（ＳＴ２００の処理を行う４０８、２２〜２４）と、前記暗号化に関する情報（Ｋｔ等を生成する元になる情報）を前記情報記録媒体（１００）から読み取って復号鍵（ＫｔまたはContents Key）を生成する手段（ＳＴ２０２〜ＳＴ２０４の処理を行う２１０ａ、２２〜２４）と、前記情報記録媒体（１００）から読み取った前記管理情報（HR_MANGR.IFO）および生成した前記復号鍵（ＫｔまたはContents Key）を用いて、前記暗号化されたリソースファイル（ＡＲＦ）または前記暗号化されたコンテンツ（Title）を復号しながら再生する手段（ＳＴ２０６の処理を行う２１０ａ、４０８、２２〜３０）とを具備している。
【０１２９】
（07）この発明の一実施の形態に係る情報記憶媒体（ＡＡＣＳで暗号化されたフォント等を含むＡＲＦが記録されるディスク）は、所定の暗号化方式（ＡＡＣＳ）に対応した記録可能メディアであり、かつ再生専用のプレーヤ（HD_DVDビデオプレーヤ）で再生可能なインターオペラブルコンテントを記録できるメディア（HD_DVD-R/RW/RAM等）である。この情報記録媒体（１００）は、前記インターオペラブルコンテントで用いられるフォントを用いて作成（ＳＴ５０２）されたメニュー（図１３の５２ａ）の情報を格納するエリア（HR_MANGR.IFO）と、前記インターオペラブルコンテントで用いられるフォントを格納し、前記所定の暗号化方式（ＡＡＣＳ）で暗号化された所定のファイル（ＡＲＦ）を格納するエリア（HR_MANGR.IFO）とを具備している。
【０１３０】
なお、この発明は前述した実施の形態に限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で種々に変形することが可能である。
【０１３１】
また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、この構成要件が削除された構成が発明として抽出され得る。
【図面の簡単な説明】
【０１３２】
【図１】この発明の一実施の形態に係るメディア（情報記録媒体）内のデータ（タイトルキーファイル）の構成を説明する図。
【図２】メデイアに記録された暗号化コンテンツを復号する処理例を説明する図。
【図３】コンテンツを暗号化してＤＶＤに記録する処理例を説明する図。
【図４】タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造を示す説明図。
【図５】この発明の一実施の形態で採用される暗号化方式（ＡＡＣＳ方式）を用いた記録再生処理で必要となるメデイア上のデータを示す図。
【図６】ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。
【図７】ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。
【図８】暗号化されたタイトルキーファイル（Ｅ−ＴＫＦ）の構造例を示す図。
【図９】リライタブルメディアのタイトルキーファイルの更新手続きを説明するフローチャート図。
【図１０】ライトワンスメディアのタイトルキーファイルの書込み手続きを説明するフローチャート図。
【図１１】この発明の一実施の形態に係るデータ構造例を説明する図。
【図１２】この発明の一実施の形態に係るファイル構造例を説明する図。
【図１３】この発明の一実施の形態に係る記録再生装置（HD_DVDレコーダ）の構成例を説明するブロック図。
【図１４】この発明の一実施の形態に係る記録方法を説明するフローチャート図。
【図１５】この発明の一実施の形態に係る再生方法を説明するフローチャート図。
【図１６】Title Usage Rule Fileの構造例を示す図。
【図１７】HD_DVD-R等の情報記録媒体に最初にTitle Key Fileを書き込む際の処理手順の一例を説明するフローチャート図。
【図１８】著作権保護された情報資源（フォント等）をメニュー等に利用する場合の処理手順の一例を説明するフローチャート図。
【符号の説明】
【０１３３】
２０…エンコーダ；２４…光ディスクドライブユニット；２６…青レーザ使用光ディスクドライブ（HD_DVD Drive）；２８…赤レーザ使用光ディスクドライブ（DVD-R/RW/RAM Drive）；３０…デコーダ；４０…制御用マイクロプロセサ（MPU）；４００…グラフィックユーザインターフェース（GUI）表示制御部（ファームウエア）；４０２…エンコードパラメータ検出処理部（ファームウエア）；４０４…高速コピー／高速ダビング処理部（ファームウエア）；４０６…レート変換コピー／レート変換ダビング制御部（ファームウエア）；４０８…記録／再生制御部（管理情報処理部）（ファームウエア）；２１０ａ…ＡＡＣＳ処理部；５０…オンスクリーン表示（OSD）部；５２ａ、５２ｂ…モニタ表示例；１００、１０２…情報記憶媒体（光ディスク）；１０４…情報記憶媒体（ハードディスクドライブ）；２００…情報記録再生装置、２１０…制御部、２２０…読出し部、２３０…書込み部。
【特許請求の範囲】
【請求項１】
不正アクセスから保護しようとする部分を含む資源情報を利用した所定画面の情報を情報記録媒体に適宜記録するものであって、
前記情報記録媒体が所定の暗号化方式に対応したメディアであるか否かをチェックし、
前記所定の暗号化方式に対応したメディアである場合は、前記資源情報を用いて前記所定画面を作成し、前記資源情報の前記部分を前記所定の暗号化方式で暗号化して前記メディアに記録し、
前記所定の暗号化方式に対応していないメディアである場合は、前記資源情報の前記部分を用いないで前記所定画面を作成するか、または前記所定画面を作成しない情報アクセス管理方法。
【請求項２】
前記情報記録媒体が、前記所定の暗号化方式に対応した記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアである場合において、前記インターオペラブルコンテントで用いられるフォントを用いてメニューを作成し、前記インターオペラブルコンテントで用いられるフォントを所定のファイルに格納し、このファイルを前記所定の暗号化方式で暗号化して前記情報記録媒体に記録する請求項１に記載の方法。
【請求項３】
前記情報記録媒体が、前記所定の暗号化方式に対応しない記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアである場合において、前記インターオペラブルコンテントで用いられるフォントを用いないでメニューを作成するか、またはメニューを作成しない請求項１に記載の方法。
【請求項４】
請求項２または請求項３に記載の前記メニューの情報が記録された前記情報記録媒体から、このメニューの情報を含む管理情報を読み取り、この管理情報で管理されるオブジェクトを再生する方法。
【請求項５】
不正アクセスから保護しようとする部分を含む資源情報を利用した所定画面の情報を情報記録媒体に記録するものであって、
前記情報記録媒体が所定の暗号化方式に対応したメディアであるか否かをチェックし、前記所定の暗号化方式に対応したメディアである場合は、前記資源情報を用いて前記所定画面を作成する手段と、
前記資源情報の前記部分を前記所定の暗号化方式で暗号化して前記メディアに記録する手段とを具備した記録装置。
【請求項６】
所定の鍵を用いて所定の暗号化方式により暗号化されたコンテンツおよび暗号化されたリソースファイルを前記所定の暗号化方式に対応した情報記録媒体から再生する装置であって、
前記コンテンツの管理情報を前記情報記録媒体から読み取る手段と、
前記暗号化に関する情報を前記情報記録媒体から読み取って復号鍵を生成する手段と、
前記情報記録媒体から読み取った前記管理情報および生成した前記復号鍵を用いて、前記暗号化されたリソースファイルまたは前記暗号化されたコンテンツを復号しながら再生する手段とを具備した再生装置。
【請求項７】
所定の暗号化方式に対応した記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアであって、
前記インターオペラブルコンテントで用いられるフォントを用いて作成されたメニューの情報を格納するエリアと、
前記インターオペラブルコンテントで用いられるフォントを格納し前記所定の暗号化方式で暗号化された所定のファイルを格納するエリアとを具備した情報記録媒体。
【請求項１】
不正アクセスから保護しようとする部分を含む資源情報を利用した所定画面の情報を情報記録媒体に適宜記録するものであって、
前記情報記録媒体が所定の暗号化方式に対応したメディアであるか否かをチェックし、
前記所定の暗号化方式に対応したメディアである場合は、前記資源情報を用いて前記所定画面を作成し、前記資源情報の前記部分を前記所定の暗号化方式で暗号化して前記メディアに記録し、
前記所定の暗号化方式に対応していないメディアである場合は、前記資源情報の前記部分を用いないで前記所定画面を作成するか、または前記所定画面を作成しない情報アクセス管理方法。
【請求項２】
前記情報記録媒体が、前記所定の暗号化方式に対応した記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアである場合において、前記インターオペラブルコンテントで用いられるフォントを用いてメニューを作成し、前記インターオペラブルコンテントで用いられるフォントを所定のファイルに格納し、このファイルを前記所定の暗号化方式で暗号化して前記情報記録媒体に記録する請求項１に記載の方法。
【請求項３】
前記情報記録媒体が、前記所定の暗号化方式に対応しない記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアである場合において、前記インターオペラブルコンテントで用いられるフォントを用いないでメニューを作成するか、またはメニューを作成しない請求項１に記載の方法。
【請求項４】
請求項２または請求項３に記載の前記メニューの情報が記録された前記情報記録媒体から、このメニューの情報を含む管理情報を読み取り、この管理情報で管理されるオブジェクトを再生する方法。
【請求項５】
不正アクセスから保護しようとする部分を含む資源情報を利用した所定画面の情報を情報記録媒体に記録するものであって、
前記情報記録媒体が所定の暗号化方式に対応したメディアであるか否かをチェックし、前記所定の暗号化方式に対応したメディアである場合は、前記資源情報を用いて前記所定画面を作成する手段と、
前記資源情報の前記部分を前記所定の暗号化方式で暗号化して前記メディアに記録する手段とを具備した記録装置。
【請求項６】
所定の鍵を用いて所定の暗号化方式により暗号化されたコンテンツおよび暗号化されたリソースファイルを前記所定の暗号化方式に対応した情報記録媒体から再生する装置であって、
前記コンテンツの管理情報を前記情報記録媒体から読み取る手段と、
前記暗号化に関する情報を前記情報記録媒体から読み取って復号鍵を生成する手段と、
前記情報記録媒体から読み取った前記管理情報および生成した前記復号鍵を用いて、前記暗号化されたリソースファイルまたは前記暗号化されたコンテンツを復号しながら再生する手段とを具備した再生装置。
【請求項７】
所定の暗号化方式に対応した記録可能メディアであり、かつ再生専用のプレーヤで再生可能なインターオペラブルコンテントを記録できるメディアであって、
前記インターオペラブルコンテントで用いられるフォントを用いて作成されたメニューの情報を格納するエリアと、
前記インターオペラブルコンテントで用いられるフォントを格納し前記所定の暗号化方式で暗号化された所定のファイルを格納するエリアとを具備した情報記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００７−３３５０３５（Ｐ２００７−３３５０３５Ａ）
【公開日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【出願番号】特願２００６−１６７８３６（Ｐ２００６−１６７８３６）
【出願日】平成１８年６月１６日（２００６．６．１６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成１９年１２月２７日（２００７．１２．２７）
【国際特許分類】
【出願日】平成１８年６月１６日（２００６．６．１６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]