(57)【要約】【課題】保護されたファイルデータの処理環境を改善する。【解決手段】所定フォーマットで保護されたファイルＡＲＦについて使用可否を検査する検査部１１０と、検査部１１０の検査結果に基づき当該ＡＲＦについて使用可否が設定される情報テーブル１０５ａと、このテーブル１０５ａに使用可否が設定されたＡＲＦを格納するファイルキャッシュ１０５と、このキャッシュ１０５に格納されたＡＲＦを使用して、暗号化されたデータオブジェクトの中身（Resource Data）を復号する復号処理部１０９を用いる。【選択図】  図１
2009099110.tif 000002
【特許請求の範囲】
【請求項１】
所定のフォーマットで保護された１以上のファイルを用いる装置であって、
前記1以上のファイルについて使用可否を検査する検査部と、
前記検査部の検査結果に基づき前記1以上のファイルについて使用可否が設定される情報テーブルと、
前記情報テーブルに使用可否が設定された前記1以上のファイルを格納するファイルキャッシュと、
前記ファイルキャッシュに格納された前記1以上のファイルを使用して、暗号化されたデータオブジェクトの中身を復号する復号処理部を備えた情報処理装置。
【請求項２】
前記1以上のファイルのうちの少なくとも１つが改竄検証データを用いて保護されている場合において、
前記改竄検証データに基づき前記少なくとも１つのファイルが改竄されているか否かを判定し、改竄されていると判定された場合は、改竄されていると判定されたファイルについて、前記情報テーブルに使用不可であることを設定し、改竄されていないと判定された場合はについて、前記情報テーブルに使用可であることを設定し、前記少なくとも１つのファイルの使用可否を前記情報テーブルに設定し、この少なくとも１つのファイルを前記ファイルキャッシュに格納するように構成された制御部をさらに備えた請求項１に記載の装置。
【請求項３】
前記1以上のファイルのうちの少なくとも１つが所定のフォーマットを用いて保護されている場合において、
前記少なくとも１つのファイルの保護フォーマットが前記所定のフォーマットに対応するか否かを確認し、前記所定フォーマットに非対応の場合は、非対応とされたファイルについて、前記情報テーブルに使用不可であることを設定し、前記所定フォーマットに対応する場合は、対応するとされたファイルについて、前記情報テーブルに使用可であることを設定し、前記少なくとも１つのファイルの使用可否を前記情報テーブルに設定し、この少なくとも１つのファイルを前記ファイルキャッシュに格納するように構成された制御部をさらに備えた請求項１または請求項２に記載の装置。
【請求項４】
前記暗号化されたデータオブジェクトの中身の復号には鍵情報が用いられ、前記1以上のファイルは、ファイル識別子および鍵ポインタを含むファイルヘッダと、ＣＢＣモードで暗号化されたリソースデータを含み、このリソースデータがイニシャルベクタと出力データで構成される復号用データブロックに細分化されている場合において、
前記復号処理部が、前記鍵ポインタにより前記復号に使用する前記鍵情報を特定し、前記イニシャルベクタを取得して前記復号用データブロックを復号するように構成された請求項１ないし請求項３のいずれか１項に記載の装置。
【請求項５】
前記ファイルキャッシュは、前記復号用データブロックを保持するサイズはあるが、前記1以上のファイルのサイズより大きいことは保証されていない固定サイズのファイルバッファを１以上含み、
前記ファイルキャッシュに前記ファイルヘッダを保持しつつ前記ファイルヘッダに後続する前記復号用データブロックのデータ部分を前記ファイルバッファに順次格納することで前記リソースデータの復号を行うように構成された請求項４に記載の装置。
【請求項６】
前記暗号化されたデータオブジェクトの中身の復号には鍵情報が用いられ、この鍵情報が更新されたときは、前記ファイルキャッシュに格納された前記1以上のファイルに対して使用可否の設定をやり直すように前記制御部が構成された請求項２ないし請求項５のいずれか１項に記載の装置。
【請求項７】
所定のフォーマットで保護された１以上のファイルを用いる方法であって、
前記1以上のファイルについて使用可否を検査し、
前記検査部の検査結果に基づき前記1以上のファイルについて使用可否を情報テーブルに設定し、
使用可否が設定された前記1以上のファイルをファイルキャッシュに格納し、
格納された前記1以上のファイルを使用して、暗号化されたデータオブジェクトの中身を復号する情報処理方法。
【請求項８】
前記1以上のファイルのうちの少なくとも１つが改竄検証データを用いて保護されている場合において、
前記改竄検証データに基づき前記少なくとも１つのファイルが改竄されているか否かを判定し、
改竄されていると判定された場合は、改竄されていると判定されたファイルについて、前記情報テーブルに使用不可であることを設定し、
改竄されていないと判定された場合は、改竄されていないと判定されたファイルについて、前記情報テーブルに使用可であることを設定し、
前記少なくとも１つのファイルの使用可否を前記情報テーブルに設定し、この少なくとも１つのファイルを前記ファイルキャッシュに格納するように構成された請求項７に記載の方法。
【請求項９】
前記1以上のファイルのうちの少なくとも１つが所定のフォーマットを用いて保護されている場合において、
前記少なくとも１つのファイルの保護フォーマットが前記所定のフォーマットに対応するか否かを確認し、
前記所定フォーマットに非対応の場合は、非対応とされたファイルについて、前記情報テーブルに使用不可であることを設定し、
前記所定フォーマットに対応する場合は、対応するとされたファイルについて、前記情報テーブルに使用可であることを設定し、
前記少なくとも１つのファイルの使用可否を前記情報テーブルに設定し、この少なくとも１つのファイルを前記ファイルキャッシュに格納するように構成された請求項７または請求項８に記載の方法。
【請求項１０】
前記暗号化されたデータオブジェクトの中身の復号には鍵情報が用いられ、前記1以上のファイルは、ファイル識別子および鍵ポインタを含むファイルヘッダと、ＣＢＣモードで暗号化されたリソースデータを含み、このリソースデータがイニシャルベクタと出力データで構成される復号用データブロックに細分化されている場合において、
前記鍵ポインタにより前記復号に使用する前記鍵情報を特定し、前記イニシャルベクタを取得して前記復号用データブロックを復号するように構成された請求項７ないし請求項９のいずれか１項に記載の方法。
【請求項１１】
前記ファイルキャッシュが、前記復号用データブロックを保持するサイズはあるが、前記1以上のファイルのサイズより大きいことは保証されていない固定サイズのファイルバッファを１以上含む場合において、
前記ファイルキャッシュに前記ファイルヘッダを保持しつつ前記ファイルヘッダに後続する前記復号用データブロックのデータ部分を前記ファイルバッファに順次格納することで前記リソースデータの復号を行うように構成された請求項１０に記載の方法。
【請求項１２】
前記暗号化されたデータオブジェクトの中身の復号には鍵情報が用いられ、この鍵情報が更新されたときは、前記ファイルキャッシュに格納された前記1以上のファイルに対して使用可否の設定をやり直すように構成された請求項８ないし請求項１１のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、次世代デジタルビデオ再生において、保護されたファイルデータを処理する情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
現在、ＤＶＤ（Digital Versatile Disc）ビデオが広く普及している。この従来ＤＶＤビデオの拡張としてのスタンダードコンテントと、従来ＤＶＤビデオを大幅に改修したアドバンスドコンテントの双方を扱う次世代ビデオも市販が開始され、これから普及しようとしている。この次世代ビデオにおいて、不正使用等から保護された情報の処理に関係する先行技術として、以下のものがある：
（１）ＣＢＣモードで暗号化されたデータをブロック単位で改竄検証し、結果を記録デバイスに格納、再生するデータ処理装置に関するもの（特許文献１参照）。ここでは、結果が悪い場合、格納と再生を中止するようにしている。しかし、この文献には、保護されたファイルの使用可否を示す情報テーブルの開示、あるいは保護されたデータの復号に用いる鍵が切り替えられた場合の情報テーブルの取り扱いに関する開示は見当たらない。
【０００３】
（２）暗号化コンテンツに必要とする暗号鍵情報と不正であると判定された情報記録媒体リボケーションリストを格納し、不正コピーを排除した情報記録媒体及び装置に関するもの（特許文献２参照）。
【０００４】
（３）ＣＢＣモードで暗号化された結果のデータをコンテンツに対応するヘッダに格納する構成とし、セキュリティを高めたデータ記憶装置に関するもの（特許文献３参照）。
【特許文献１】特開２００１−２１１１５１号公報（図２，２２参照）
【特許文献２】特開２００４−２９５３７３号公報（図１参照）
【特許文献３】特開２００２−１３２１４１号公報（図３４参照）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記特許文献１〜特許文献３に開示された技術では、保護されたデータを再生する場合において、このデータのサイズが大きいと、そのデータの使用を開始しようとしてから実際に使用できるようになるまでの時間が長くなる。また、上記特許文献１〜特許文献３に開示された技術では、保護されたファイルの処理に必要なファイルキャッシュサイズを削減することも難しい。
【０００６】
この発明の課題は、保護されたファイルデータの処理環境を改善すること（所要時間の短縮あるいは必要なファイルキャッシュサイズの削減等）である。
【課題を解決するための手段】
【０００７】
この発明の一実施に係る情報処理装置は、所定のフォーマット（図５〜図８）で保護された１以上のファイル（ＡＲＦ）を用いる。この装置は、前記1以上のファイル（ＡＲＦ）について使用可否を検査する検査部（１１０）と、前記検査部の検査結果に基づき前記1以上のファイル（ＡＲＦ）について使用可否が設定される情報テーブル（１０５ａ）と、前記情報テーブル（１０５ａ）に使用可否が設定された前記1以上のファイル（ＡＲＦ）を格納するファイルキャッシュ（１０５）と、前記ファイルキャッシュ（１０５）に格納された前記1以上のファイル（ＡＲＦ）を使用して、暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）を復号する復号処理部（１０９）を備えている。
【０００８】
また、この発明の一実施に係る情報処理方法では、所定のフォーマットで保護された１以上のファイル（ＡＲＦ）について使用可否を検査し（ＳＴ１０２、ＳＴ１０８等）、前記検査部の検査結果に基づき前記1以上のファイル（ＡＲＦ）について使用可否を情報テーブル（１０５ａ）に設定し（ＳＴ１０４、ＳＴ１１０等）、使用可否が設定された前記1以上のファイル（ＡＲＦ）をファイルキャッシュ（１０５）に格納し（ＳＴ１１２等）、格納された前記1以上のファイル（ＡＲＦ）を使用して（ＳＴ１３０等）、暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）を復号するようにしている。
【発明の効果】
【０００９】
次世代ビデオ（暗号化されたデータオブジェクトの中身）等の再生シーンにおいて、保護された１以上のファイル（ＡＲＦ）はその使用可否の情報とともにオブジェクト再生開始前に予め記憶されている。そのため、オブジェクト再生開始時は必要なファイル（ＡＲＦ）の使用をすぐに開始できるようになる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して、この発明の種々な実施の形態に係る情報処理装置および情報処理方法を説明する。図１は、この発明の一実施の形態に係る情報処理装置の構成例を説明するブロック図である。同図は、この発明の一実施の形態における次世代ビデオ再生装置のシステムモデルを例示している。図中、１０１は、次世代ドライブ（光ディスクドライブおよび／またはハードディスクドライブ）を示し、１０２はパージステントストレージ（Persistent Storage）を示し、１０３はネットワークサーバを示す。次世代ドライブ１０１、パージステントストレージ１０２、およびネットワークサーバ１０３からのデータストリームは、データアクセスマネージャ１０４に入力される。
【００１１】
データアクセスマネージャ１０４に入力されるデータストリームは、次世代のアドバンスドコンテント（Advanced Content）の情報を含む。このアドバンスドコンテントは、プレイリスト、プライマリビデオセット、セカンダリビデオセット、アドバンスドアプリケーション、およびアドバンスドサブタイトルで構成されている。プレイリストは、プライマリビデオセット、セカンダリビデオセット、アドバンスドアプリケーション、アドバンスドサブタイトルなどの再生オブジェクトを管理する情報である。
【００１２】
プライマリビデオセット（またはアドバンスドビデオタイトルセット）は、ビデオタイトルセット情報（属性情報）、タイムマップ情報、およびプライマリエンハンスドビデオオブジェクト（以下、適宜Ｐ−ＥＶＯＢと略記する）で構成される。セカンダリビデオセットは、タイムマップ情報およびセカンダリエンハンスドビデオオブジェクト（以下、適宜Ｓ−ＥＶＯＢと略記する）で構成される。
【００１３】
アドバンスドアプリケーションは、マニフェスト、マークアップ、およびスクリプトなどのアドバンスドナビゲーションと、ＪＰＥＧ（Joint Photograph Expert Group）、ＰＮＧ（Portable Network Graphics）、ＭＮＧ（Multiple-image Network Graphics）、ＬＰＣＭ（Linear PCM）、Open Typeなどのアドバンスドエレメントで構成される。また、アドバンスドサブタイトルはアドバンスドアプリケーションのサブセットであり、マニフェスト、マークアップ、アドバンスドエレメント（ＪＰＥＧ、ＰＮＧ、Open Typeなど）で構成されている。
【００１４】
データアクセスマネージャ１０４に入力されたデータストリームのうち、１０１〜１０３のいずれかからのストリームに含まれる暗号化された（encrypted）Ｐ−ＥＶＯＢのストリームは、Ｐ−ＥＶＯＢ用アクセス管理処理部１０６を介して復号され（decrypted）、プライマリビデオプレーヤ（データ再生処理部）２００に送られる。
【００１５】
データアクセスマネージャ１０４に入力されたデータストリームのうち、１０１〜１０３のいずれかからのストリームに含まれる暗号化された（encrypted）Ｓ−ＥＶＯＢのストリームは、ファイルキャッシュ１０５に併設されたストリーミングバッファ（図示せず）に送られるとともに、Ｓ−ＥＶＯＢ用アクセス管理処理部１０７を介して復号され（decrypted）、セカンダリビデオプレーヤ３００に送られる。
【００１６】
データアクセスマネージャ１０４に入力されたデータストリームのうち、１０１〜１０３のいずれかからのストリームに含まれるＰ−ＥＶＯＢ、Ｓ−ＥＶＯＢ以外のファイルデータ（アクセス管理で保護されたＡＲＦ）はファイルキャッシュ１０５に蓄えられる。このファイルキャッシュ１０５は、ナビゲーションマネージャ１０００内のファイルキャッシュマネージャ（図示せず）からのアドバンスドリソースファイルＡＲＦ（図５〜図８参照）を蓄えることができるようになっている。このファイルキャッシュ１０５は、後述する情報テーブル１０５ａおよびファイルバッファ部１０５ｂを含んでいる。このファイルバッファ部１０５ｂは、１以上のＡＲＦ（図７または図８参照）の全体サイズより大きいことは保証されていない、比較的小さな固定サイズ（例えば５１２バイトあるいはその数倍程度）のもので構成することができる。
【００１７】
ファイルキャッシュ１０５に蓄えられたファイルデータのうち、アドバンスドエレメント、フォント、アドバンストサブタイトルなどの情報を含むアドバンスドリソースファイル（以下、適宜ＡＲＦと略記する）のデータストリームおよび／または、データアクセスマネージャ１０４に入力されたデータストリームのうち、１０１〜１０３のいずれかからのストリームに含まれるカプセル化された（encapsulated）ＡＲＦのデータストリームは、ＡＲＦ用アクセス管理処理部１０８を介してカプセル化が解除され（decapsulated）、アドバンスドアプリケーション再生エンジン４００に送られる。アクセス管理処理部１０６〜１０８は、復号処理部１０９を構成している。また、プライマリビデオプレーヤ２００、セカンダリビデオプレーヤ３００およびアドバンスドアプリケーション再生エンジン４００は、再生エンジン１００を構成している。なお、アクセス管理には公知の暗号化技術を用いることができる。 
プライマリビデオプレーヤ（データ再生処理部）２００において、Ｐ−ＥＶＯＢのデータストリームからアドバンスドパック（以下、適宜ＡＤＶ＿ＰＣＫと略記する）が抽出される。抽出されたＡＤＶ＿ＰＣＫあるいはそこに含まれるアドバンスドパケット（以下、適宜ＡＤＶ＿ＰＫＴと略記する）は、ナビゲーションマネージャ１０００に転送される。ナビゲーションマネージャ１０００は、図１の構成を持つアドバンスドコンテントプレーヤの全ての機能モジュールを制御するとともに、図示しないリモコンや装置のフロントパネル等を介したユーザインターフェイスも制御する。
【００１８】
ナビゲーションマネージャ１０００内の図示しないファイルキャッシュマネージャ（前述）は、アクセス管理処理部１０８からのＡＲＦを、ファイルの使用可否検査部１１０に送る。この検査部１１０は、受け取ったＡＲＦのフォーマット確認および／または改竄検証を行う。具体的には、検査部１１０のフォーマット確認部は、受け取ったＡＲＦが図５〜図８のいずれのフォーマットに該当するのかの確認をおこなう。また、検査部１１０の改竄部は、受け取ったＡＲＦが改竄されているか否かを、既知のアクセス管理の処理手順に従い、検証済みのハッシュ表（図５）を用いるか、M*A*C（Message*Authentication*Code）計算値（図６）を用いて、ＡＲＦの改竄検証を行う。フォーマット確認／改竄検証後のカプセル化されたＡＲＦは、ファイルキャッシュ１０５内の情報テーブル１０５ａに送られる。なお、ファイルキャッシュ１０５、復号処理部１０９、ファイルの使用可否検査部１１０等におけるＡＲＦファイルの処理は、制御部（マイクロコンピュータで構成される）１１１のファームウエアにより制御されるようになっている。
【００１９】
図２は、図１の情報テーブル１０５ａにどんな情報が格納されるのかの一例を説明する図である。ここでは、検査部１１０におけるフォーマット確認および／または改竄検証により使用可能と判定されたＡＲＦ（この例でのファイル名はファイル＃１）、使用不可と判定されたＡＲＦ（この例でのファイル名はファイル＃２）、使用不可と判定されたＡＲＦ（この例でのファイル名はファイル＃３）等が例示されている。この例の情報テーブル１０５ａは、対応ファイルの使用可否のみならず、使用不可であった場合に再生装置がどのような動作をすべきか（例えば再生を停止するのか、該当ファイルなしとして再生動作を継続するのか等）の情報も、適宜記述できるように構成されている。
【００２０】
図３は、この発明の一実施の形態において用いられるオブジェクトのデータ構造の一例を説明する図である。プライマリビデオプレーヤ２００に入力されるＰ−ＥＶＯＢ（図３（ａ））は、データアクセス単位となる１以上のプライマリビデオオブジェクトユニット（以下、適宜Ｐ−ＥＶＯＢＵと略記する）で構成されている（図３（ｂ））。各Ｐ−ＥＶＯＢＵ（図３（ｃ））は、先頭にナビゲーションパック（以下、適宜ＮＶ−ＰＣＫと略記する）を持ち、その後に複数種類のデータパック（副映像パックＳＰ＿ＰＣＫ、サブビデオパックＶＳ＿ＰＣＫ、メインビデオパックＶＭ＿ＰＣＫ、アドバンスドパックＡＤＶ＿ＰＣＫ、メインオーディオパックＡＭ＿ＰＣＫ、サブオーディオパックＡＳ＿ＰＣＫ、等）を含んでいる。各Ｐ−ＥＶＯＢＵは、再生時間に換算して０．４秒〜１．００１秒の間の所定サイズを持っている。換言すれば、複数のＰ−ＥＶＯＢＵは、一定または所定の間隔で並んでいる。連続する２つのＰ−ＥＶＯＢＵの境界は、各Ｐ−ＥＶＯＢＵの先頭にあるＮＶ＿ＰＣＫを読み込むことで分かる。
【００２１】
各Ｐ−ＥＶＯＢＵに含まれる複数種類のデータパックのうち、ＶＭ＿ＰＣＫの集合でメインビデオストリーム（図３（ｄ））が形成され、ＡＭ＿ＰＣＫの集合でメインオーディオストリーム（図３（ｅ））が形成され、ＶＳ＿ＰＣＫの集合でサブビデオストリーム（図３（ｆ））が形成され、ＡＳ＿ＰＣＫの集合でサブオーディオストリーム（図３（ｇ））が形成され、ＡＤＶ＿ＰＣＫの集合でアドバンスドストリーム（図３（ｈ））が形成される。図２の構成では、図３（ａ）のデータストリームから図３（ｈ）のアドバンスドストリームが抽出されると、このアドバンスドストリーム中のＡＤＶ＿ＰＣＫがある程度の個数単位で複数の受信バッファ＃１〜＃Ｎのうちのいずれかを介してアドバンスドパック処理部２０５に転送されるようになっている。
【００２２】
図４は、この発明の一実施の形態において用いられるアドバンスドパケット（ＡＤＶ＿ＰＣＫ）のデータ構造を説明する図である。各ＡＤＶ＿ＰＣＫは、パックヘッダとアドバンスドパケット（ＡＤＶ＿ＰＫＴ）で構成される（図４（ａ））。各ＡＤＶ＿ＰＫＴは、ストリーム識別子（stream_id）を含むパケットヘッダと、当該データストリームがアドバンスドストリームであることを示すサブストリーム識別子（sub_stream_id）と、アドバンスドデータヘッダ（advanced_data_header）と、アドバンスドデータ（Advanced Data）を含んでいる。
【００２３】
ここで、アドバンスドデータヘッダは、アドバンスドストリーム内におけるＡＤＶ＿ＰＫＴの位置情報（advanced_pkt_status）と、複数存在し得るアーカイブファイルの識別子（advanced_identifier）と、当該パケットで構成されるアーカイブファイルのファイル名（advanced_file_name）の情報を含んでいる（図４（ｂ））。
【００２４】
１以上のＡＤＶ＿ＰＫＴに含まれるアドバンスドデータは、アーカイブデータ（Archiving Data）に対応している（図４（ｃ））。このアーカイブデータは、ファイルヘッダと、１以上のリソースデータサーチポインタ＃１〜＃ｎと、リソースデータサーチポインタ＃１〜＃ｎで示される１以上のリソースデータ＃１〜＃ｎで構成される。これらのリソースデータ＃１〜＃ｎはトータルでは比較的大きなサイズとなり得る。
【００２５】
ファイルヘッダは、該当するアーカイブデータのファイル識別子（FILE_ID）と、該当規格のバージョン（VERN）と、該当ファイルが圧縮データであるか否か等を示すファイルタイプ（FILE_TY）と、リソース名ストリングに用いられるテキストエンコードタイプ（ENC_TY）と、データサーチポインタの数（SRP_Ns）と、当該ファイルのサイズ（FILE_SZ）などの情報を含んでいる（図４（ｄ））。
【００２６】
複数のＡＤＶ＿ＰＣＫで運ばれる上記のリソースデータ＃１〜＃ｎは、１つづつアクセス管理で暗号化される。このようなリソースデータを含むアーカイブデータは、図１のナビゲーションマネージャ１０００内で処理され、これらのリソースデータに対応するＡＲＦは、ナビゲーションマネージャ１０００内の図示しないファイルキャッシュマネージャを介して検査部１１０に送られる。そして、検査後のカプセル化されたＡＲＦは、その検査結果（使用可否等）が情報テーブル１０５ａに書き込まれるとともに、ファイルキャッシュ１０５に戻され蓄えられるようになっている。
【００２７】
図５は、この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造の一例（ＡＲＦ第１フォーマット）を説明する図である。この例では、ＡＲＦのファイルヘッダが、FILE_IDと、Protection Type:12（ハッシュ値を用いるタイプ）と、Resource File Size（Nfs）と、Resource File Name field（ＤＲＦＮ）を含んでいる。このヘッダの後に、Resource Data（ＤＲＤ）とHash Pointerが続いて配置されている。図５のＡＲＦ第１フォーマットであることは、例えば、FILE_ID、Protection Type:12、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報により確認することができる。
【００２８】
このＡＲＦ第１フォーマットでは、ＤＲＦＮとＤＲＤがハッシュ用のデータ（Data for Hash）として用いられる。ここでは、別に検証されたハッシュ表（検証済みHash Table）が用意される。ＤＲＤの後のHash Pointerが検証済みHash Tableの例えばHash Value #nを指しているときに、Data for Hashから求めたハッシュ値ＳＨＡ１とHash Value #nを比較し、両者が一致するか否かでＡＲＦの改竄の有無を検証できる。なお、上記ＡＲＦのファイルヘッダはArchiving DataのFile Header（図４（ｃ））とは別のものである。
【００２９】
図６は、この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造の他例（ＡＲＦ第２フォーマット）を説明する図である。この例では、ＡＲＦのファイルヘッダが、FILE_IDと、Protection Type:02（M*A*C値を用いるタイプ）と、暗号鍵を示すポインタTITLE_KEY_PTRと、Resource File Size（Nfs）と、Resource File Name field（ＤＲＦＮ）を含んでいる。このヘッダの後に、Resource Data（ＤＲＤ）とリソースデータのM*A*C（Message*Authentication*Code of Resource Data）が続いて配置されている。図６のＡＲＦ第２フォーマットは、例えば、FILE_ID、Protection Type:02、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報により確認することができる。
【００３０】
このＡＲＦ第２フォーマットでは、ＤＲＦＮとＤＲＤがM*A*C用のデータ（Data for M*A*C）として用いられる。ここでは、暗号化されたタイトルキーファイル（Encrypted Title*Key*File）が用意される。TITLE_KEY_PTRがEncrypted Title*Key*Fileの例えばTITLE_KEY #nを指しているときに、TITLE_KEY #nから求めたM*A*C値とＡＲＦに格納されたM*A*Cの期待値を比較し、両者が一致するか否かでＡＲＦの改竄の有無を検証できる。
【００３１】
図７は、この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造のさらに他例（ＡＲＦ第３フォーマット）を説明する図である。この例では、ＡＲＦのファイルヘッダが、FILE_IDと、Protection Type:01（ＣＢＣモードを用いるタイプ）と、暗号鍵を示すポインタTITLE_KEY_PTRと、Resource File Size（Nfs）と、暗号化されたResource File Name field（ＤＲＦＮ）を含んでいる。このヘッダの後に、暗号化されたResource Data（ＤＲＤ）が続いて配置されている。図７のＡＲＦ第３フォーマットであることは、例えば、FILE_ID、Protection Type:01、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報により確認することができる。
【００３２】
ＡＲＦ第３フォーマットでは、暗号化にＣＢＣモードが利用されている。暗号化されたＤＲＤ内は、先頭に１６バイトのInitial Vector（ＩＶ）が配置されその後に出力用データを持つ復号用データ（Data for Decrypt）のブロックに細分化できるようになっている。この例で細分化された復号用データブロックは、図１のファイルバッファ部１０５ｂに対するInput dataとすることができる。この細分化された復号用データブロックのサイズは、例えば５１２バイトといった比較的小サイズとすることができる。
【００３３】
なお、上記のＣＢＣモードは、データ暗号化標準のData Encryption Standardで定められている。このＣＢＣモードでは、Initial Vector（ＩＶ）という初期値とＡＥＳ（Advanced Encryption Standard）でエンコードされたData #1の排他的論理和ＥＸＯＲで暗号化されたData #1*を生成し、生成したData #1*とＡＥＳエンコードされたData #2のＥＸＯＲで暗号化されたData #2*を生成する。以下同様に、生成したData #（n-1）*とＡＥＳエンコードされたData #nのＥＸＯＲで暗号化されたData #n*を生成する。このように、特定のＩＶを用いて、Data #1〜#nから暗号化されたData #1*〜#n*を生成できる。逆に、暗号化に用いたＩＶが与えられれば、暗号化とは逆のプロセスで、Data #n*〜#1*から復号されたData #n〜#1を得ることができる。このプロセスは公知である。
【００３４】
図８は、この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造のさらに他例（ＡＲＦ第４フォーマット）を説明する図である。この例では、ＡＲＦのファイルヘッダが、FILE_IDと、Protection Type:11（タイトルキーとハッシュ値を用いるタイプ）と、暗号鍵を示すポインタTITLE_KEY_PTRと、Resource File Size（Nfs）と、暗号化されたResource File Name field（ＤＲＦＮ）を含んでいる。このヘッダの後に、暗号化されたResource Data（ＤＲＤ）とHash Pointers #1〜#Nが続いて配置されている。図７のＡＲＦ第３フォーマットであることは、例えば、FILE_ID、Protection Type:11、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報により確認することができる。
【００３５】
ＡＲＦ第４フォーマットでは、FILE_IDからResource File Size（Nfs）までとHash Pointers #1〜#Nを暗号化されないPlain Dataとし、Resource File Name field（ＤＲＦＮ）とResource Data（ＤＲＤ）を暗号化されたEncrypted Data（Ｄｅ）としている。暗号化されたEncrypted Data（Ｄｅ）は、比較的小さな５１２バイトのデータブロック＃Ｎ個に分割されている。これにより、個々のデータブロックを、図１の小さなファイルバッファ部１０５ｂで扱うことができるようになる。
【００３６】
図８の例では、Encrypted Data（Ｄｅ）の暗号化にEncrypted Title*Key*File内のTitle*Keyを用い、ハッシュ値に基づくＡＲＦの改竄検証に５１２バイトのデータブロックを用いている。この例では、ハッシュ値算出に用いるデータ量が小さいので、改竄検証のための演算処理時間も短縮できる。
【００３７】
図９は、この発明の一実施の形態に係る情報処理方法（第１実施例）を説明するフローチャート図である。次世代ビデオにおいては、アクセス管理によって、図５に示す形式で保護されたＡＲＦ（Advanced Resource File）は、別に検証されたハッシュ表を用いた改竄検証を受けることができる。本願発明がなされるまでの次世代ビデオ再生装置では、図５のフォーマットで保護されたＡＲＦを使用するとき、当該ＡＲＦの全データを読み出し、そのフォーマット確認と、ハッシュ値計算を行い、ハッシュ表に格納されたハッシュ値と一致するか否かを確認していた。このやり方では時間がかかるので、この発明の一実施の形態に係る次世代ビデオ再生装置では、図５のフォーマットで保護されたＡＲＦをファイルキャッシュ１０５に格納する際に、改竄検証を行う。
【００３８】
すなわち、図９の処理において、まず、対象のファイルがフォーマットを確認する必要があるファイルなのか、あるいは改竄検証をする必要があるファイルなのかのチェックがおこなわれる（ＳＴ１００）。もし、フォーマット確認も改竄検証も必要でないときは（ＳＴ１００Ｎ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ１１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ１１２）。この例では、例えば図５のProtection Typeの存在から、フォーマット確認と改竄検証が必要であると判定する（ＳＴ１００Ｙ）。当該ＡＲＦが図５のフォーマットであると確認されないときは（ＳＴ１０２ＮＧ）、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ１０４）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ１１２）。その際（ＳＴ１０４）、使用不可の場合の動作も併せて情報テーブル１０５ａに設定しておく（図２参照）。
【００３９】
当該ＡＲＦが図５のフォーマットであるか否かは、例えば図５のFILE_ID、Protection Type:12、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報が図５のフォーマットのファイルに該当するか否かで判定できる。当該ＡＲＦが図５のフォーマットであると確認されたときは（ＳＴ１０２ＯＫ）、ハッシュ表を用いた改竄検証処理に移る（ＳＴ１０６）。ここでは、別に検証されたハッシュ表（検証済みHash Table）が用意される。図５の例において、Resource Dataの後のHash Pointerが検証済みHash Tableの例えばHash Value #nを指しているときに、Data for Hashから求めたハッシュ値ＳＨＡ１とHash Value #nを比較し、両者が一致するか否かで、当該ＡＲＦの改竄の有無を検証できる。
【００４０】
この検証で、改竄ありと判断された場合（ＳＴ１０８Ｙ）は、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ１０４）、ファイルキャッシュ１０５に格納する（ＳＴ１１２）。その際（ＳＴ１０４）、使用不可の場合の動作（アクセス管理処理部１０８によって決定された、当該ＡＲＦを使用しようとした場合の動作）も併せて情報テーブル１０５ａに設定しておく（図２参照）。改竄なしと判断された場合（ＳＴ１０８Ｎ）は、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ１１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ１１２）。
【００４１】
そして、次世代ビデオの再生シーン（ＳＴ１２０）において、当該ＡＲＦの使用を開始する際、図２に示す情報テーブル１０５ａを参照する（ＳＴ１２２）。このテーブル内にＡＲＦに関する情報がないとき、例えば当該ＡＲＦがファイル＃１であるときにファイル＃１についての使用可否情報が記載されていないとき（ＳＴ１２４Ｎ）は、ＡＲＦのフォーマット確認と改竄検証を行い（ＳＴ１０２、ＳＴ１０６）、情報テーブル１０５ａを更新する（ＳＴ１０４、ＳＴ１１０）。
【００４２】
情報テーブル１０５ａ内にＡＲＦに関する情報があるときは（ＳＴ１２４Ｙ）、当該ＡＲＦが使用可能であるかどうかをそのテーブルの記載から読み取る（ＳＴ１２６）。使用不可の場合（ＳＴ１２６Ｎ）は、使用不可の場合の動作設定（例えば当該ＡＲＦが図２のファイル＃２であれば再生停止）を行い（ＳＴ１２８）、図９の処理を終了する。
【００４３】
当該ＡＲＦ（図２の例では例えばファイル＃１）が使用可能の場合（ＳＴ１２６Ｙ）は、当該ＡＲＦを復号して、その使用を開始する（ＳＴ１３０）。このＡＲＦを使用した次世代ビデオ再生中に鍵（Title*Key）の更新があったときは（ＳＴ１４０Ｙ）、ＳＴ１０２に戻り、図５に示す形式で保護された全てのＡＲＦ（ファイルキャッシュ１０５に格納されたＡＲＦ）のフォーマット確認と改竄検証を再度行う。鍵（Title*Key）の更新がなく（ＳＴ１４０Ｎ）、再生が終了していない間は（ＳＴ１４４Ｎ）、このＡＲＦを使用した次世代ビデオ再生が継続される（ＳＴ１４２）。
【００４４】
以上のように、この実施の形態では、次世代ビデオの再生開始前にフォーマット確認／改竄検証済みのＡＲＦをファイルキャッシュに格納する（ＳＴ１１２）ようにしている。そのため、次世代ビデオの再生シーンにおいて、図５に示す形式で保護されたＡＲＦの使用を開始する際に、使用を開始しようとしてから、当該ＡＲＦの使用可否判断が終わり、実際に使用できるまでの時間を短縮できる。
【００４５】
図１０は、この発明の他の実施の形態に係る情報処理方法（第２実施例）を説明するフローチャート図である。次世代ビデオにおいては、アクセス管理によって図６に示す形式で保護されたＡＲＦ（Advanced Resource File）は、M*A*C（Message*Authentication*Code）を用いた改竄検証を受けることができる。本願発明がなされるまでの次世代ビデオ再生装置では、図６のフォーマットで保護されたＡＲＦを使用するとき、当該ＡＲＦの全データを読み出し、そのフォーマット確認と、M*A*C計算を行い、ＡＲＦに格納されたM*A*Cの期待値と一致するか否かを確認していた。このやり方では時間がかかるので、この発明の一実施の形態に係る次世代ビデオ再生装置では、図６のフォーマットで保護されたＡＲＦをファイルキャッシュ１０５に格納する際に、改竄検証を行う。
【００４６】
すなわち、図１０の処理において、まず、対象のファイルがフォーマットを確認する必要があるファイルなのか、あるいは改竄検証をする必要があるファイルなのかのチェックがおこなわれる（ＳＴ２００）。もし、フォーマット確認も改竄検証も必要でないときは（ＳＴ２００Ｎ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ２１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ２１２）。この例では、例えば図６のProtection Typeの存在から、フォーマット確認と改竄検証が必要であると判定する（ＳＴ２００Ｙ）。当該ＡＲＦが図６のフォーマットであると確認されないときは（ＳＴ２０２ＮＧ）、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ２０４）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ２１２）。その際（ＳＴ２０４）、使用不可の場合の動作も併せて情報テーブル１０５ａに設定しておく（図２参照）。
【００４７】
当該ＡＲＦが図６のフォーマットであるか否かは、例えば図６のFILE_ID、Protection Type:02、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報が図６のフォーマットのファイルに該当するか否かで判定できる。当該ＡＲＦが図６のフォーマットであると確認されたときは（ＳＴ２０２ＯＫ）、M*A*C値を用いた改竄検証処理に移る（ＳＴ２０６）。ここでは、暗号化されたタイトルキーファイル（Encrypted Title*Key*File）が用意される。図６の例において、TITLE_KEY_PTRがEncrypted Title*Key*Fileの例えばTITLE*KEY #nを指しているときに、TITLE_KEY #nから求めたM*A*C値とＡＲＦに格納されたM*A*Cの期待値を比較し、両者が一致するか否かでＡＲＦの改竄の有無を検証できる。
【００４８】
この検証で、改竄ありと判断された場合（ＳＴ２０８Ｙ）は、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ２０４）、ファイルキャッシュ１０５に格納する（ＳＴ２１２）。その際（ＳＴ２０４）、使用不可の場合の動作（アクセス管理処理部１０８によって決定された、当該ＡＲＦを使用しようとした場合の動作）も併せて情報テーブル１０５ａに設定しておく（図２参照）。改竄なしと判断された場合（ＳＴ２０８Ｎ）は、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ２１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ２１２）。
【００４９】
そして、次世代ビデオの再生シーン（ＳＴ２２０）において、当該ＡＲＦの使用を開始する際、図２に示す情報テーブル１０５ａを参照する（ＳＴ２２２）。このテーブル内にＡＲＦに関する情報がないとき、例えば当該ＡＲＦがファイル＃１であるときにファイル＃１についての使用可否情報が記載されていないとき（ＳＴ２２４Ｎ）は、ＡＲＦのフォーマット確認と改竄検証を行い（ＳＴ２０２、ＳＴ２０６）、情報テーブル１０５ａを更新する（ＳＴ２０４、ＳＴ２１０）。
【００５０】
情報テーブル１０５ａ内にＡＲＦに関する情報があるときは（ＳＴ２２４Ｙ）、当該ＡＲＦが使用可能であるかどうかをそのテーブルの記載から読み取る（ＳＴ２２６）。使用不可の場合（ＳＴ２２６Ｎ）は、使用不可の場合の動作設定（例えば当該ＡＲＦが図２のファイル＃３であれば、ファイルが存在しないものとして再生を継続する）を行い（ＳＴ２２８）、図１０の処理を終了する。
【００５１】
当該ＡＲＦ（図２の例では例えばファイル＃１）が使用可能の場合（ＳＴ２２６Ｙ）は、当該ＡＲＦを復号して、その使用を開始する（ＳＴ２３０）。このＡＲＦを使用した次世代ビデオ再生中に鍵（Title*Key）の更新があったときは（ＳＴ２４０Ｙ）、ＳＴ２０２に戻り、図６に示す形式で保護された全てのＡＲＦ（ファイルキャッシュ１０５に格納されたＡＲＦ）のフォーマット確認と改竄検証を再度行う。鍵（Title*Key）の更新がなく（ＳＴ２４０Ｎ）、再生が終了していない間は（ＳＴ２４４Ｎ）、このＡＲＦを使用した次世代ビデオ再生が継続される（ＳＴ２４２）。
【００５２】
以上のように、この実施の形態では、次世代ビデオの再生開始前にフォーマット確認／改竄検証済みのＡＲＦをファイルキャッシュに格納する（ＳＴ２１２）ようにしている。そのため、次世代ビデオの再生シーンにおいて、図６に示す形式で保護されたＡＲＦの使用を開始する際に、使用を開始しようとしてから、当該ＡＲＦの使用可否判断が終わり、実際に使用できるまでの時間を短縮できる。
【００５３】
図１１は、この発明の他の実施の形態に係る情報処理方法（第３実施例）を説明するフローチャート図である。この例では、アクセス管理によって、図７に示す形式で保護されたＡＲＦ（Advanced Resource File）は、１６バイト単位に、ＣＢＣモードで暗号化されている。本願発明がなされるまでは、図７のフォーマットで保護されたＡＲＦを使用するとき、当該ＡＲＦの全データを読み出し、そのフォーマット確認と、復号を行っていた。このやり方では時間がかかるので、この発明の一実施の形態に係る次世代ビデオ再生装置では、図７のフォーマットで保護されたＡＲＦをファイルキャッシュ１０５に格納する際に、フォーマット確認を行う。
【００５４】
すなわち、図１１の処理において、まず、対象のファイルがフォーマットを確認する必要があるファイルであるか否かのチェックがおこなわれる（ＳＴ３００）。もし、フォーマット確認が必要でないときは（ＳＴ３００Ｎ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ３１０）、当該ＡＲＦ（File HeaderとData for Decryptの部分）をファイルキャッシュ１０５に格納する（ＳＴ３１２）。この例では、例えば図７のProtection Typeの存在から、フォーマット確認が必要であると判定する（ＳＴ３００Ｙ）。当該ＡＲＦが図７のフォーマットであると確認されないときは（ＳＴ３０２ＮＧ）、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ３０４）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ３１２）。その際（ＳＴ３０４）、使用不可の場合の動作も併せて情報テーブル１０５ａに設定しておく（図２参照）。
【００５５】
当該ＡＲＦが図７のフォーマットであるか否かは、例えば図７のFILE_ID、Protection Type:01、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報が図７のフォーマットのファイルに該当するか否かで判定できる。当該ＡＲＦが図７のフォーマットであると確認されたときは（ＳＴ３０２ＯＫ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ３１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ３１２）。
【００５６】
そして、次世代ビデオの再生シーン（ＳＴ３２０）において、当該ＡＲＦの使用を開始する際、図２に示す情報テーブル１０５ａを参照する（ＳＴ３２２）。このテーブル内にＡＲＦに関する情報がないとき、例えば当該ＡＲＦがファイル＃１であるときにファイル＃１についての使用可否情報が記載されていないとき（ＳＴ３２４Ｎ）は、ＡＲＦのフォーマット確認を行い（ＳＴ３０２）、情報テーブル１０５ａを更新する（ＳＴ３０４、ＳＴ３１０）。
【００５７】
情報テーブル１０５ａ内にＡＲＦに関する情報があるときは（ＳＴ３２４Ｙ）、当該ＡＲＦが使用可能であるかどうかをそのテーブルの記載から読み取る（ＳＴ３２６）。使用不可の場合（ＳＴ３２６Ｎ）は、使用不可の場合の動作設定（例えば当該ＡＲＦが図２のファイル＃２であれば再生停止）を行い（ＳＴ３２８）、図１１の処理を終了する。
【００５８】
当該ＡＲＦ（図２の例では例えばファイル＃１）が使用可能の場合（ＳＴ３２６Ｙ）は、当該ＡＲＦを復号して、その使用を開始する（ＳＴ３３０）。このＡＲＦを使用した次世代ビデオ再生中に鍵（Title*Key）の更新があったときは（ＳＴ３４０Ｙ）、ＳＴ３０２に戻り、図７に示す形式で保護された全てのＡＲＦ（ファイルキャッシュ１０５に格納されたＡＲＦ）のフォーマット確認を再度行う。鍵（Title*Key）の更新がなく（ＳＴ３４０Ｎ）、再生が終了していない間は（ＳＴ３４４Ｎ）、このＡＲＦを使用した次世代ビデオ再生が継続される（ＳＴ３４２）。
【００５９】
以上のように、この実施の形態では、次世代ビデオの再生開始前にフォーマット確認済みのＡＲＦをファイルキャッシュに格納する（ＳＴ３１２）ようにしている。そのため、次世代ビデオの再生シーンにおいて、図７に示す形式で保護されたＡＲＦの使用を開始する際に、使用を開始しようとしてから、当該ＡＲＦの使用可否判断が終わり、実際に使用できるまでの時間を短縮できる。また、ＳＴ３３０での復号は図７のData for Decryptという比較的小さなサイズの単位で行えるため、ＡＲＦの復号作業に用いるワークメモリエリアも節約できる。
【００６０】
図１２は、この発明の他の実施の形態に係る情報処理方法（第４実施例）を説明するフローチャート図である。この例では、アクセス管理によって、図８に示す形式で保護されたＡＲＦ（Advanced Resource File）は、１６バイト単位に、ＣＢＣモードで暗号化されている。本願発明がなされるまでは、図８のフォーマットで保護されたＡＲＦを使用するとき、当該ＡＲＦの全データを読み出し、そのフォーマット確認と、復号を行っていた。このやり方では時間がかかるので、この発明の一実施の形態に係る次世代ビデオ再生装置では、図８のフォーマットで保護されたＡＲＦをファイルキャッシュ１０５に格納する際に、フォーマット確認を行う。
【００６１】
すなわち、図１２の処理において、まず、対象のファイルがフォーマットを確認する必要があるファイルであるか否かのチェックがおこなわれる（ＳＴ４００）。もし、フォーマット確認が必要でないときは（ＳＴ４００Ｎ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定し（ＳＴ４１０）、当該ＡＲＦを復号してファイルキャッシュ１０５に格納する（ＳＴ４１２）。この例では、例えば図８のProtection Typeの存在から、フォーマット確認が必要であると判定する（ＳＴ４００Ｙ）。当該ＡＲＦが図８のフォーマットであると確認されないときは（ＳＴ４０２ＮＧ）、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ４０４）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ４１２）（この場合は当該ＡＲＦを復号しなくてよい）。その際（ＳＴ４０４）、使用不可の場合の動作も併せて情報テーブル１０５ａに設定しておく（図２参照）。
【００６２】
当該ＡＲＦが図８のフォーマットであるか否かは、例えば図８のFILE_ID、Protection Type:11、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報が図８のフォーマットのファイルに該当するか否かで判定できる。当該ＡＲＦが図８のフォーマットであると確認されたときは（ＳＴ４０２ＯＫ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定し（ＳＴ４１０）、当該ＡＲＦを復号してファイルキャッシュ１０５に格納する（ＳＴ４１２）。
【００６３】
そして、次世代ビデオの再生シーン（ＳＴ４２０）において、当該ＡＲＦの使用を開始する際、図２に示す情報テーブル１０５ａを参照する（ＳＴ４２２）。このテーブル内にＡＲＦに関する情報がないとき、例えば当該ＡＲＦがファイル＃１であるときにファイル＃１についての使用可否情報が記載されていないとき（ＳＴ４２４Ｎ）は、ＡＲＦのフォーマット確認を行い（ＳＴ４０２）、情報テーブル１０５ａを更新する（ＳＴ４０４、ＳＴ４１０）。
【００６４】
情報テーブル１０５ａ内にＡＲＦに関する情報があるときは（ＳＴ４２４Ｙ）、当該ＡＲＦが使用可能であるかどうかをそのテーブルの記載から読み取る（ＳＴ４２６）。使用不可の場合（ＳＴ４２６Ｎ）は、使用不可の場合の動作設定（例えば当該ＡＲＦが図２のファイル＃２であれば再生停止）を行い（ＳＴ４２８）、図１２の処理を終了する。
【００６５】
当該ＡＲＦ（図２の例では例えばファイル＃１）が使用可能の場合（ＳＴ４２６Ｙ）は、当該ＡＲＦの復号結果の使用を開始する（ＳＴ４３０）。このＡＲＦを使用した次世代ビデオ再生中に鍵（Title*Key）の更新があったときは（ＳＴ４４０Ｙ）、ＳＴ４０２に戻り、図８に示す形式で保護された全てのＡＲＦ（ファイルキャッシュ１０５に格納されたＡＲＦ）のフォーマット確認を再度行う。鍵（Title*Key）の更新がなく（ＳＴ４４０Ｎ）、再生が終了していない間は（ＳＴ４４４Ｎ）、このＡＲＦを使用した次世代ビデオ再生が継続される（ＳＴ４４２）。
【００６６】
以上のように、この実施の形態では、次世代ビデオの再生開始前にフォーマット確認済みのＡＲＦをファイルキャッシュに格納する（ＳＴ４１２）ようにしている。そのため、次世代ビデオの再生シーンにおいて、図８に示す形式で保護されたＡＲＦの使用を開始する際に、使用を開始しようとしてから、当該ＡＲＦの使用可否判断が終わり、実際に使用できるまでの時間を短縮できる。
【００６７】
図１３は、この発明の他の実施の形態に係る情報処理方法（第５実施例）を説明するフローチャート図である。この例は、図１１の部分変形例ともいえる。この例でも、図７のフォーマットで保護されたＡＲＦをファイルキャッシュ１０５に格納する際に、フォーマット確認を行うようにしている。
【００６８】
すなわち、図１３の処理において、まず、対象のファイルがフォーマットを確認する必要があるファイルであるか否かのチェックがおこなわれる（ＳＴ５００）。もし、フォーマット確認が必要でないときは（ＳＴ５００Ｎ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ５１０）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ５１２）。この例では、例えば図７のProtection Typeの存在から、フォーマット確認が必要であると判定する（ＳＴ５００Ｙ）。当該ＡＲＦが図７のフォーマットであると確認されないときは（ＳＴ５０２ＮＧ）、当該ＡＲＦが使用不可であることを情報テーブル１０５ａに設定して（ＳＴ５０４）、当該ＡＲＦをファイルキャッシュ１０５に格納する（ＳＴ５１２）。その際（ＳＴ５０４）、使用不可の場合の動作も併せて情報テーブル１０５ａに設定しておく（図２参照）。
【００６９】
当該ＡＲＦが図７のフォーマットであるか否かは、例えば図７のFILE_ID、Protection Type:01、あるいは予約エリア（reserved）内の図示しないフォーマット識別情報が図７のフォーマットのファイルに該当するか否かで判定できる。当該ＡＲＦが図７のフォーマットであると確認されたときは（ＳＴ５０２ＯＫ）、当該ＡＲＦが使用可能であることを情報テーブル１０５ａに設定して（ＳＴ５１０）、当該ＡＲＦのFile Headerをファイルキャッシュ１０５に格納する（ＳＴ５１２）。
【００７０】
そして、次世代ビデオの再生シーン（ＳＴ５２０）において、当該ＡＲＦの使用を開始する際、図２に示す情報テーブル１０５ａを参照する（ＳＴ５２２）。このテーブル内にＡＲＦに関する情報がないとき、例えば当該ＡＲＦがファイル＃１であるときにファイル＃１についての使用可否情報が記載されていないとき（ＳＴ５２４Ｎ）は、ＡＲＦのフォーマット確認を行い（ＳＴ５０２）、情報テーブル１０５ａを更新する（ＳＴ５０４、ＳＴ５１０）。
【００７１】
情報テーブル１０５ａ内にＡＲＦに関する情報があるときは（ＳＴ５２４Ｙ）、当該ＡＲＦが使用可能であるかどうかをそのテーブルの記載から読み取る（ＳＴ５２６）。使用不可の場合（ＳＴ５２６Ｎ）は、使用不可の場合の動作設定（例えば当該ＡＲＦが図２のファイル＃２であれば再生停止）を行い（ＳＴ５２８）、図１３の処理を終了する。
【００７２】
当該ＡＲＦ（図２の例では例えばファイル＃１）が使用可能の場合（ＳＴ５２６Ｙ）は、ファイルキャッシュ１０５から当該ＡＲＦのFile Headerを読み出し、当該ＡＲＦのうち必用箇所を含む一部分（例えば５１２バイトのデータブロック１個、あるいは、必要に応じて所定個数分）を復号して、その使用を開始する（ＳＴ５３０）。このＡＲＦを使用した次世代ビデオ再生中に鍵（Title*Key）の更新があったときは（ＳＴ５４０Ｙ）、ＳＴ５０２に戻り、図７に示す形式で保護された全てのＡＲＦ（ファイルキャッシュ１０５に格納されたＡＲＦ）のフォーマット確認を再度行う。鍵（Title*Key）の更新がなく（ＳＴ５４０Ｎ）、再生が終了していない間は（ＳＴ５４４Ｎ）、このＡＲＦを使用した次世代ビデオ再生が継続される（ＳＴ５４２）。
【００７３】
以上のように、この実施の形態では、次世代ビデオの再生開始前にフォーマット確認済みのＡＲＦのFile Headerをファイルキャッシュに格納する（ＳＴ５１２）ようにしている。そのため、次世代ビデオの再生シーンにおいて、図７に示す形式で保護されたＡＲＦの使用を開始する際に、使用を開始しようとしてから、当該ＡＲＦの使用可否判断が終わり、実際に使用できるまでの時間を短縮できる。さらにＳＴ５３０での復号が小さなデータ単位（例えば５１２バイトのデータブロック１個ないし所定個数分）で行われるため、その復号結果を格納するためのメモリサイズ（あるいは復号処理に用いるワークメモリサイズ）を小さくすることができる。
【００７４】
図１４は、アクセス管理に基づく改竄検証に関わる各ファイルの関係を説明する図である。ここで、M*K*B（Media*Key*Block）１４１はT*K*Fを暗号化しているMedia*Keyを保護する仕組みを提供するもので、M*K*B１４１によって保護されたMedia*KeyがT*K*Fを暗号化している。T*K*F（Title*Key*File）１４２には、contentを暗号化しているTitle*Keyが格納されている。このT*K*F１４２は、図６あるいは図８のEncrypted Title*Key*Fileに対応している。
【００７５】
T*K*F１４２に格納されたTitle*Keyを用いて、ＡＲＦを暗号化し、あるいはＡＲＦに改竄検証情報（M*A*C等）を付加することができる。ＡＲＦ（Advanced Resource File）１４３は、次世代ビデオのAdvanced Contentに含まれるXML DocumentやImageなどに対応している。ＣＣ（Content Certificate）１４４は、Contentの署名が格納されているものを暗号化しており、ＣＨＴの 改竄検証情報（ハッシュ等）を格納することができる。
【００７６】
ＣＨＴ（Content Hash Table）１４５は、Contentのハッシュが格納されているものを暗号化している。なお、ＣＨＴには２種類存在し得る。１つはデータストリーム（次世代ビデオではAdvanced Stream）用のＣＨＴ＃１であり、他はＡＲＦ用のＣＨＴ＃２である。ＣＣ１４４の署名等により正しいものであると検証されたＣＨＴ＃２は、図５あるいは図８の検証済みHash Tableに対応している。
【００７７】
図１５は、ＡＲＦに対する改竄検証の一例を説明するフローチャート図である（図１４参照）。ＣＣ１４４の署名を確認し（ＳＴ１５１）、ＣＨＴ１４５がＣＨＴ＃２であることを確認したあと（ＳＴ１５２）、M*K*B１４１からMedia*Keyを導出する（ＳＴ１５３）。このMedia*Keyを用いて（アクセス管理に基づいて）T*K*Fを復号し（ＳＴ１５４）、続いてＡＲＦの復号と改竄検証（M*A*Cまたはハッシュを利用）を行う（ＳＴ１５５）。
【００７８】
図１５の改竄検証手順は、図９のＡＲＦ改竄検証ＳＴ１０６あるいは図１０のＡＲＦ改竄検証ＳＴ２０６で利用されてもよい。
【００７９】
＜実施の形態のポイント＞
１．再生装置が、一時記憶装置（キャッシュ）に格納されたデータそれぞれに対して、改竄検証で改竄無しと判断されたか否か、または非該当であるか等、使用可否についての情報を持つこと。
【００８０】
２．改竄検証データ（ハッシュ、M*A*C等）を用いて保護されたデータを一時記憶装置（キャッシュ）に読み込む際に、改竄検証を行うこと。
【００８１】
３．改竄検証データ（ハッシュ、M*A*C等）を用いて保護されたデータを一時記憶装置（キャッシュ）に読み込む際に、フォーマット確認を行うこと。
【００８２】
４．ＣＢＣモードで暗号化されたデータの、ファイルヘッダと対象領域手前の一定サイズの領域を使用して、使用する鍵の特定と、ＩＶ（Initial Vector）を取得し、対象領域の復号を行うこと。
【００８３】
５．ＣＢＣモードで暗号化されたデータを復号する際、予め読み出したファイルヘッダを保持し、後続部分を順次読み出すことにより、当該データのファイルサイズより大きいことが保証されていない固定サイズのファイルバッファを用いて、当該データの復号を行うこと。
【００８４】
６．鍵が切り替わる際、一時記憶装置に格納済みのデータの改竄検証をやり直すこと。
【００８５】
＜実施の形態と発明との対応関係＞
（１）所定のフォーマット（図５〜図８のいずれか）で保護された１以上のファイル（ＡＲＦ：図２のファイル＃１〜に対応）を用いる装置であって、
前記1以上のファイル（ＡＲＦ）について使用可否を検査する検査部（１１０）と、
前記検査部の検査結果に基づき前記1以上のファイル（ＡＲＦ）について使用可否が設定される情報テーブル（１０５ａ）と、
前記情報テーブル（１０５ａ）に使用可否が設定された前記1以上のファイル（ＡＲＦ）を格納するファイルキャッシュ（１０５）と、
前記ファイルキャッシュ（１０５）に格納された前記1以上のファイル（ＡＲＦ）を使用して（図９〜図１３のＳＴ１３０〜ＳＴ５３０）、暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）を復号する復号処理部（１０９）を備えた情報処理装置。
【００８６】
（２）前記1以上のファイルのうちの少なくとも１つ（図５または図６のＡＲＦ）が改竄検証データ（Data for HashまたはData for M*A*C）を用いて保護されている場合において、
前記改竄検証データ（別途検証済みのHash TableまたはTitle*Keyから算出されたM*A*C）に基づき前記少なくとも１つのファイル（図５または図６のＡＲＦ）が改竄されているか否かを判定し（図９のＳＴ１０６または図１０のＳＴ２０６）、
改竄されていると判定された場合は（ＳＴ１０８ＹまたはＳＴ２０８Ｙ）、改竄されていると判定されたファイル（図２のファイル＃２または＃３）について、前記情報テーブル（１０５ａ）に使用不可であることを設定し（ＳＴ１０４またはＳＴ２０４）、
改竄されていないと判定された場合は（ＳＴ１０８ＮまたはＳＴ２０８Ｎ）、改竄されていないと判定されたファイル（図２のファイル＃１）について、前記情報テーブル（１０５ａ）に使用可であることを設定し（ＳＴ１１０またはＳＴ２１０）、
前記少なくとも１つのファイル（図５または図６のＡＲＦ）の使用可否を前記情報テーブル（１０５ａ）に設定し、この少なくとも１つのファイル（図５または図６のＡＲＦ）を前記ファイルキャッシュ（１０５）に格納する（ＳＴ１１２またはＳＴ２１２）ように構成された制御部（１１１）をさらに備えた装置。
【００８７】
（３）前記1以上のファイルのうちの少なくとも１つ（図５〜図８のＡＲＦ）が所定のフォーマット（ＡＲＦの第１〜第４フォーマット）を用いて保護されている場合において、
前記少なくとも１つのファイルの保護フォーマット（図５〜図８のProtection Type）が前記所定のフォーマット（ＡＲＦの第１〜第４フォーマット：Protection Type = 01, 02, 11, or 12）に対応するか否かを確認し（図９〜図１３のＳＴ１０２、ＳＴ２０２、ＳＴ３０２、ＳＴ４０２、またはＳＴ５０２）、
前記所定フォーマットに非対応の場合は（ＳＴ１０２ＮＧ〜ＳＴ５０２ＮＧ）、非対応とされたファイル（図２のファイル＃２または＃３）について、前記情報テーブル（１０５ａ）に使用不可であることを設定し（ＳＴ１０４〜ＳＴ５０４）、
前記所定フォーマットに対応する場合は（ＳＴ１０２ＯＫ〜ＳＴ５０２ＯＫ）、対応するとされたファイル（図２のファイル＃１）について、前記情報テーブル（１０５ａ）に使用可であることを設定し（ＳＴ１１０〜ＳＴ５１０）、
前記少なくとも１つのファイル（図５〜図８のＡＲＦ）の使用可否を前記情報テーブル（１０５ａ）に設定し、この少なくとも１つのファイル（図５〜図８のＡＲＦ）を前記ファイルキャッシュ（１０５）に格納する（ＳＴ１１２〜ＳＴ５１２）ように構成された制御部（１１１）をさらに備えた装置。
【００８８】
（４）前記暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）の復号には鍵情報（Title*Key）が用いられ、
前記1以上のファイル（図７のＡＲＦ）は、ファイル識別子（File_ID）および鍵ポインタ（Title_KEY_PTR）を含むファイルヘッダと、ＣＢＣモードで暗号化されたリソースデータ（ＤＲＤ）を含み、このリソースデータがイニシャルベクタ（ＩＶ）と出力データ（Data for Output）で構成される復号用データブロック（Data for Decrypt）に細分化されている場合において、
前記復号処理部（１０９）が、前記鍵ポインタ（Title_KEY_PTR）により前記復号に使用する前記鍵情報（Title*Key）を特定し、前記イニシャルベクタ（ＩＶ）を取得して前記復号用データブロック（Data for Decrypt）を復号するように構成された装置。
【００８９】
（５）前記ファイルキャッシュ（１０５）は、前記復号用データブロック（Data for Decrypt）を保持するサイズはあるが、前記1以上のファイル（図７または図８のＡＲＦ）のサイズより大きいことは保証されていない固定サイズ（例えば512Byte）のファイルバッファ（１０５ｂ）を１以上含み、
前記ファイルキャッシュ（１０５）に前記ファイルヘッダを保持しつつ前記ファイルヘッダに後続する前記復号用データブロック（Data for Decrypt）のデータ部分を前記ファイルバッファ（１０５ｂ）に順次格納することで前記リソースデータ（ＤＲＤ）の復号を行うように構成された装置。
【００９０】
（６）前記暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）の復号には鍵情報（Title*Key）が用いられ、この鍵情報（Title*Key）が更新されたときは（ＳＴ１４０Ｙ〜ＳＴ５４０Ｙ）、前記ファイルキャッシュ（１０５）に格納された前記1以上のファイル（図５〜図８のＡＲＦ）に対して使用可否の設定をやり直すように前記制御部（１１１）が構成された装置。
【００９１】
（７）所定のフォーマットで保護された１以上のファイル（ＡＲＦ）を用いる方法であって、
前記1以上のファイル（ＡＲＦ）について使用可否を検査し（ＳＴ１０２、ＳＴ１０８等）、
前記検査部の検査結果に基づき前記1以上のファイル（ＡＲＦ）について使用可否を情報テーブル（１０５ａ）に設定し（ＳＴ１０４、ＳＴ１１０等）、
使用可否が設定された前記1以上のファイル（ＡＲＦ）をファイルキャッシュ（１０５）に格納し（ＳＴ１１２等）、
格納された前記1以上のファイル（ＡＲＦ）を使用して（図９〜図１３のＳＴ１３０〜ＳＴ５３０）、暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）を復号する情報処理方法。
【００９２】
（８）前記1以上のファイルのうちの少なくとも１つ（図５または図６のＡＲＦ）が改竄検証データ（Data for HashまたはData for M*A*C）を用いて保護されている場合において、
前記改竄検証データ（別途検証済みのHash TableまたはTitle*Keyから算出されたM*A*C）に基づき前記少なくとも１つのファイル（図５または図６のＡＲＦ）が改竄されているか否かを判定し（図９のＳＴ１０６または図１０のＳＴ２０６）、
改竄されていると判定された場合は（ＳＴ１０８ＹまたはＳＴ２０８Ｙ）、改竄されていると判定されたファイル（図２のファイル＃２または＃３）について、前記情報テーブル（１０５ａ）に使用不可であることを設定し（ＳＴ１０４またはＳＴ２０４）、
改竄されていないと判定された場合は（ＳＴ１０８ＮまたはＳＴ２０８Ｎ）、改竄されていないと判定されたファイル（図２のファイル＃１）について、前記情報テーブル（１０５ａ）に使用可であることを設定し（ＳＴ１１０またはＳＴ２１０）、
前記少なくとも１つのファイル（図５または図６のＡＲＦ）の使用可否を前記情報テーブル（１０５ａ）に設定し、この少なくとも１つのファイル（図５または図６のＡＲＦ）を前記ファイルキャッシュ（１０５）に格納する（ＳＴ１１２またはＳＴ２１２）ように構成された方法。
【００９３】
（９）前記1以上のファイルのうちの少なくとも１つ（図５〜図８のＡＲＦ）が所定のフォーマット（ＡＲＦの第１〜第４フォーマット）を用いて保護されている場合において、
前記少なくとも１つのファイルの保護フォーマット（図５〜図８のProtection Type）が前記所定のフォーマット（ＡＲＦの第１〜第４フォーマット：Protection Type = 01, 02, 11, or 12）に対応するか否かを確認し（図９〜図１３のＳＴ１０２、ＳＴ２０２、ＳＴ３０２、ＳＴ４０２、またはＳＴ５０２）、
前記所定フォーマットに非対応の場合は（ＳＴ１０２ＮＧ〜ＳＴ５０２ＮＧ）、非対応とされたファイル（図２のファイル＃２または＃３）について、前記情報テーブル（１０５ａ）に使用不可であることを設定し（ＳＴ１０４〜ＳＴ５０４）、
前記所定フォーマットに対応する場合は（ＳＴ１０２ＯＫ〜ＳＴ５０２ＯＫ）、対応するとされたファイル（図２のファイル＃１）について、前記情報テーブル（１０５ａ）に使用可であることを設定し（ＳＴ１１０〜ＳＴ５１０）、
前記少なくとも１つのファイル（図５〜図８のＡＲＦ）の使用可否を前記情報テーブル（１０５ａ）に設定し、この少なくとも１つのファイル（図５〜図８のＡＲＦ）を前記ファイルキャッシュ（１０５）に格納する（ＳＴ１１２〜ＳＴ５１２）ように構成された方法。
【００９４】
（１０）前記暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）の復号には鍵情報（Title*Key）が用いられ、
前記1以上のファイル（図７のＡＲＦ）は、ファイル識別子（File_ID）および鍵ポインタ（Title_KEY_PTR）を含むファイルヘッダと、ＣＢＣモードで暗号化されたリソースデータ（ＤＲＤ）を含み、このリソースデータがイニシャルベクタ（ＩＶ）と出力データ（Data for Output）で構成される復号用データブロック（Data for Decrypt）に細分化されている場合において、
前記鍵ポインタ（Title_KEY_PTR）により前記復号に使用する前記鍵情報（Title*Key）を特定し、前記イニシャルベクタ（ＩＶ）を取得して前記復号用データブロック（Data for Decrypt）を復号するように構成された方法。
【００９５】
（１１）前記ファイルキャッシュ（１０５）が、前記復号用データブロック（Data for Decrypt）を保持するサイズはあるが、前記1以上のファイル（図７または図８のＡＲＦ）のサイズより大きいことは保証されていない固定サイズ（例えば512Byte）のファイルバッファ（１０５ｂ）を１以上含む場合において、
前記ファイルキャッシュ（１０５）に前記ファイルヘッダを保持しつつ前記ファイルヘッダに後続する前記復号用データブロック（Data for Decrypt）のデータ部分を前記ファイルバッファ（１０５ｂ）に順次格納することで前記リソースデータ（ＤＲＤ）の復号を行うように構成された方法。
【００９６】
（１２）前記暗号化されたデータオブジェクト（Encrypted P-EVOB）の中身（Resource Data）の復号には鍵情報（Title*Key）が用いられ、この鍵情報（Title*Key）が更新されたときは（ＳＴ１４０Ｙ〜ＳＴ５４０Ｙ）、前記ファイルキャッシュ（１０５）に格納された前記1以上のファイル（図５〜図８のＡＲＦ）に対して使用可否の設定をやり直すように構成された方法。
【００９７】
＜実施の形態の効果＞
この発明の一実施の形態によれば、保護されたファイル（ＡＲＦ）のデータの処理において、
ａ）改竄検証データを用いて保護された、サイズの巨大なデータを再生に使用するシーンにおいて、当該データの改竄検証を予め行っておくことにより、再生装置が当該データの使用を開始しようとしたときから、実際に使用できるまでの時間が短くなる。
【００９８】
ｂ）ＣＢＣ暗号で保護された巨大なデータを再生するシーンにおいて、当該データのファイルサイズよりサイズの小さいバッファを用いて、当該データを復号して再生することが可能となった。このことにより、復号処理部に必要なワークメモリのサイズが小さくなる。
【００９９】
ｃ）ＣＢＣ暗号で保護された巨大なデータの一部分のみを再生に使用するシーンにおいて、当該データの使用部分のみを復号して再生することが可能となった。このことにより、再生装置が当該データの当該部分の使用を開始しようとしたときから、実際に使用できるまでの時間が短くなる。
【０１００】
この発明は上記した実施の形態そのままに限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で構成要素を種々変形して具体化することができる。
【０１０１】
さらに、上記した実施の形態に開示されている複数の構成要素を適宜に組み合わせることにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除しても良いものである。さらに、異なる実施の形態に係る構成要素を適宜組み合わせても良い。
【図面の簡単な説明】
【０１０２】
【図１】この発明の一実施の形態に係る情報処理装置の構成例を説明するブロック図。
【図２】図１の情報テーブル１０５ａの構成例を説明する図。
【図３】この発明の一実施の形態において用いられるオブジェクトのデータ構造の一例を説明する図。
【図４】この発明の一実施の形態において用いられるアドバンスドパケットのデータ構造を説明する図。
【図５】この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造の一例（ＡＲＦ第１フォーマット）を説明する図。
【図６】この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造の他例（ＡＲＦ第２フォーマット）を説明する図。
【図７】この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造のさらに他例（ＡＲＦ第３フォーマット）を説明する図。
【図８】この発明の一実施の形態において用いられるリソースファイル（ＡＲＦ）のデータ構造のさらに他例（ＡＲＦ第４フォーマット）を説明する図。
【図９】この発明の一実施の形態に係る情報処理方法（第１実施例）を説明するフローチャート図。
【図１０】この発明の他の実施の形態に係る情報処理方法（第２実施例）を説明するフローチャート図。
【図１１】この発明の他の実施の形態に係る情報処理方法（第３実施例）を説明するフローチャート図。
【図１２】この発明の他の実施の形態に係る情報処理方法（第４実施例）を説明するフローチャート図。
【図１３】この発明の他の実施の形態に係る情報処理方法（第５実施例）を説明するフローチャート図。
【図１４】改竄検証に関わる各ファイルの関係を説明する図。
【図１５】改竄検証の一例を説明するフローチャート図。
【符号の説明】
【０１０３】
１００…再生エンジン（Presentation Engine）、１０１…情報記憶媒体（次世代ビデオ用光ディスクドライブおよび／またはハードディスクドライブ）、１０２…パージステントストレージ（Persistent Storage）、１０３…ネットワークサーバ（Network Server）、１０４…データアクセスマネージャ（Data Access Manager）、１０５…データキャッシュメモリ（File Cache/Streaming Buffer）、１０５ａ…情報テーブル、１０５ｂ…ファイルバッファ部、１０６…Ｐ−ＥＶＯＢ用アクセス管理処理部、１０７…Ｓ−ＥＶＯＢ用アクセス管理処理部、１０８…ＡＲＦ用アクセス管理処理部、１０９…復号処理部、１１０…ファイルの使用可否検査部（フォーマット確認／改竄検証部）、１１１…制御部（ファームウエアを実行するマイクロコンピュータ）、２００…プライマリビデオプレーヤ（Primary Video Player）、３００…セカンダリビデオプレーヤ（Secondary Video Player）、４００…アドバンスドアプリケーション再生エンジン（Advanced Application Presentation Engine）、１０００…ナビゲーションマネージャ（Navigation Manager）。
【図１】
2009099110.tif 000003
【図２】
2009099110.tif 000004
【図３】
2009099110.tif 000005
【図４】
2009099110.tif 000006
【図５】
2009099110.tif 000007
【図６】
2009099110.tif 000008
【図７】
2009099110.tif 000009
【図８】
2009099110.tif 000010
【図９】
2009099110.tif 000011
【図１０】
2009099110.tif 000012
【図１１】
2009099110.tif 000013
【図１２】
2009099110.tif 000014
【図１３】
2009099110.tif 000015
【図１４】
2009099110.tif 000016
【図１５】
2009099110.tif 000017