記録装置及び記録方法並びにサーバ装置
【課題】ダウンロードしたストリームの特に暗号化対象領域について円滑な記録処理を行なうことができる記録装置及び記録方法並びにサーバ装置を提供する。
【解決手段】ストリームと、ストリームの暗号化対象領域を示すアドレス情報を受ける受信部（１１）と、ストリームを記録媒体の各セクタに記録すると共に、暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部（２１，１９）をもつ記録装置。
【解決手段】ストリームと、ストリームの暗号化対象領域を示すアドレス情報を受ける受信部（１１）と、ストリームを記録媒体の各セクタに記録すると共に、暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部（２１，１９）をもつ記録装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ストリームとこのストリームの暗号化対象領域を示すアドレス情報を受けて、暗号化対象領域のデータが記録される記録媒体のセクタに管理情報を記録する記録装置及び記録方法並びにこのストリームを供給するサーバ装置に関する。
【背景技術】
【０００２】
周知のように、次世代の記録媒体の記録処理に対しては、ＡＡＣＳ（Advanced Access Control System）規格等のフォームが知られている。特許文献１は、ＡＡＣＳによって著作権保護されたコンテンツが記録されたメディアを再生する場合、メディア鍵の生成に要する処理負荷を低減することができるメディア鍵生成方法を提供している。
【特許文献１】特開２００７−０１３４４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、特許文献１の従来技術は、ＡＡＣＳ規格に準じたストリームをダウンロードして、ＢＥ暗号等を行ない光ディスク等にストリームを記録しようとする場合、ストリームを受けたアプリケーション等は、少なくとも、ＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳ等のファイルからＢＥフラグの情報を取得しなければならない。そして、ダウンロードしたイメージファイルからＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳ等のファイルを検出し、このファイル中のＢＥフラグがあれば、『．ＥＶＯファイル』を探索し、ＥＶＯファイルのＬＢＡを取得してＢＥフラグを設定するＬＢＡリストを作成し、ストリームのうち暗号化対象領域のデータであれば、セクタヘッダにＢＥフラグを記録しなければならない。
【０００４】
しかし、ストリームをダウンロードするアプリケーションにとっては、この作業は非常に負荷の高い作業となり、円滑な処理動作が困難となる。
【０００５】
本発明は、ダウンロードしたストリームの特に暗号化対象領域について円滑な記録処理を行なうことができる記録装置及び記録方法並びにサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
課題を解決するための一実施形態は、
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受ける受信部（１１）と、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部（２１，１９）と、
を具備することを特徴とする記録装置である。
【発明の効果】
【０００７】
サーバ装置からストリームと、ストリームの暗号化対象領域を示すアドレス情報であるＢＥ対象のＬＢＡ管理テーブルも一緒にアプリケーション等にダウンロードする。これにより、アプリケーションで『．ＥＶＯファイル』を探索しＬＢＡリストを生成するという高負荷な工程が不要となり、光ディスク等への円滑な記録処理が可能となる。
【発明を実施するための最良の形態】
【０００８】
以下、この発明の実施の形態について図面を参照して詳細に説明する。
【０００９】
＜本発明の一実施形態である記録システムの構成の一例＞
初めに、本発明の一実施形態である記録システムの構成の一例を図面を用いて説明する。図１は、本発明の一実施形態に係る記録システムの構成の一例を示す説明図である。図２は、同じく記録装置の構成の一例を示すブロック図である。
【００１０】
本発明の一実施形態である記録システムＲＳは、図１に示すように、ＢＥコンテンツイメージを配信する配信サーバＳと、これにインターネット等のネットワークを介して接続されるハードディスクレコーダ１０を有している。ここで、ハードディスクレコーダ１０は、内蔵される記録処理及び再生処理を行なうアプリケーション１０−１と、バスＢ等でハードディスクレコーダ１０の処理回路に接続される光ディスクドライブ部１９を含んでおり、更に、光ディスクドライブ部１９とアプリケーション部１０−１は、ＡＴＡＰＩドライバ１９−１を用いてバスＢでデータ転送を行なっている。
【００１１】
（ハードディスクレコーダ１０の構成）
次に、図２に示すハードディスクレコーダ１０の構成を示す。ハードディスクレコーダ１０は、２種類のディスクドライブ部を有する。まず、ビデオファイルを構築できる情報記録媒体である第１のメディアとしての光ディスクＤを回転駆動し、情報の読み書きを実行する光ディスクドライブ部１９を有する。ここで、光ディスクＤは、一例として、ＨＤ ＤＶＤであるがこれに限定されるものではない。又、第２のメディアとしてのハードディスクを駆動するハードディスクドライブ部１８を有する。制御部３０は、全体の動作を司るべくバスＢを介して各部に接続されている。
【００１２】
又、図２に示されるハードディスクレコーダ１０は、録画側を構成するエンコーダ部２１と、再生側を構成するＭＰＥＧデコーダ部２３と、装置本体の動作を制御する制御部３０とを主たる構成要素としている。ハードディスクレコーダ１０は、入力側のセレクタ部１６と出力側のセレクタ部１７とを有しており、入力側のセレクタ部１６には、ＬＡＮ等の通信部１１と、いわゆる衛星放送（ＢＳ／ＣＳ）チューナ部１２と、いわゆる地上波チューナ部１３とが接続され、エンコーダ部２１に信号を出力する。又、ＢＳ／ＣＳチューナ部１２には衛星アンテナが、地上波チューナ部１３には地上波アンテナが接続されている。又、ハードディスクレコーダ１０は、エンコーダ部２１と、エンコーダ部２１の出力を受け、データ編集等の所望のデータ処理を行うデータ編集部２０と、データ編集部２０に接続されるハードディスクドライブ部１８と、光ディスクドライブ部１９を有している。更に、ハードディスクレコーダ１０は、ハードディスクドライブ部１８と、光ディスクドライブ部１９からの信号を受けてデコードするＭＰＥＧデコーダ部２３と、エンコーダ部２１と、バッファ部２２と、ＭＰＥＧデコーダ部２３と、多重化部２８と、分離部２９と、制御部３０と、映像画面に所望の映像を合成するＯＳＤ部３１と、後述するＢＥ暗号化処理及び復号処理等を行なうＢＥ暗号管理部４２と、予約リストや番組表画像を生成する予約録画部４３を有している。これらの各部は、バスＢを介して制御部３０に接続されている。更に、セレクタ部１７の出力は、外部の受像機４１に接続されるか、外部装置との通信を行うインターフェース部２７を介して、外部装置に供給される。
【００１３】
なお、ここで図１で示したアプリケーション部１０−１は、再生機能及び記録機能に該当するものであり、図２においては、制御部３０、ＢＥ暗号管理部４２、エンコーダ部２１、ＭＰＥＧデコーダ部２３等を主な構成とする。
【００１４】
更に、ハードディスクレコーダ１０は、バスＢを介して制御部３０に接続され、ユーザの操作やリモコンＲの操作を受ける操作部３２を有している。ここで、リモコンＲは、ハードディスクレコーダ１０の本体に設けられる操作部３２とほぼ同等の操作を可能とするものであり、ハードディスクドライブ部１８や光ディスクドライブ部１９の記録再生指示や、編集指示、チューナの操作、予約録画の設定等の各種設定が可能である。
【００１５】
（基本動作）
このような構成のハードディスクレコーダ１０において、光ディスクに例を取って、再生処理と記録処理の概要を説明する。すなわち、制御部３０の制御下において、所定速度に回転される光ディスクＤは、レーザ光が照射されその反射光が光ピックアップにより検出され、これに基づく検出信号が出力される。この検出信号に基づいて、ＲＦ信号が生成され、データの読取処理に続いて再生処理が行われる。
【００１６】
又、光ディスクの記録処理は、制御部３０の制御下において、例えば図示しない入力部を介しセレクタ部１６を介して供給されたデータは、エンコーダ部２１に供給され、コード化されて出力される。このコード化出力と制御部３０の出力に応じて、レーザドライバの駆動電流が光ピックアップに供給され、光ディスクＤの記憶領域に照射することで、記録処理が行われるものである。
【００１７】
＜本発明の一実施形態である記録システムのＢＥ暗号化処理＞
次に、上述した本発明の一実施形態である記録システムＲＳのＢＥ暗号化処理の概要を図面を用いて説明する。図３は、本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の一例を示す説明図である。図４は、同じく記録装置が扱うＢＥ対応コンテンツのデータ構造の一例を示す説明図である。図５は、同じく記録装置のコンテンツの再生方法の一例を示すフローチャートである。図６は、同じく記録装置が扱うＢＥ対応コンテンツのイメージ構造の他の一例を示す説明図である。
【００１８】
なお、以下の図５、図７、図８、図１１のフローチャートの各ステップは、回路ブロックに置き換えることができ、従って、各フローチャートのステップは、全てブロックに定義しなおすことが可能である。
【００１９】
本発明の一実施形態である記録システムＲＳのハードディスクレコーダ１０が行なうＢｕｓＥｎｃｒｙｐｔｉｏｎ機能について、以下に説明する。
【００２０】
ＡＡＣＳ規格では、ＢｕｓＥｎｃｒｙｐｔｉｏｎ（ＢＥ）機能が新規機能として提案されつつある状況となっている。
【００２１】
ＢＥ機能とは、不当な第三者がバスＢ等からコンテンツデータを不正にコピーする等の行為に対する保護を目的として設けられる暗号化復号機能である。従って、ＢＥ機能は、ＨＤ ＤＶＤ−ＲＯＭ／Ｒメディアなどを再生する際に、光ディスクドライブ部１９と、アプリケーション部１０−１の間で共有された秘密鍵を用いて、光ディスクドライブ部１９で暗号化したデータをアプリケーション部１０−１のＢＥ暗号管理部４２で復号しながらデータ転送を行う機能のことである。
【００２２】
同様に、ＢＥ機能は、ストリームデータをＲメディアなどに記録する場合、アプリケーション部１０−１のＢＥ暗号管理部４２で暗号化したデータを光ディスクドライブ部１９で復号しながらデータ転送する機能も含まれる。
【００２３】
ＨＤ ＤＶＤ−ＶＩＤＥＯ規格のコンテンツデータにＢＥ機能を適用した場合、図４に示すように、ＢＥ暗号化対象となるファイルは、『．ＥＶＯ拡張子』を持つファイル１３２，１３４，１３６のみとなる。
【００２４】
ここで注目すべきは、光ディスクドライブ部１９がＢＥ暗号化対象領域を判別する方法と、アプリケーション部１０−１がＢＥ暗号化対象領域を判別する方法は以下のように異なっている。
【００２５】
（光ディスクドライブ部１９がＢＥ暗号化対象領域を判別する方法）
ＢＥ暗号化対象領域を含むＨＤ ＤＶＤ−ＶＩＤＥＯ規格のコンテンツデータは、光ディスクＤで図３に示すようなセクタ構造、すなわち、セクタＳＴの先端にセクタヘッダＳＨをもっており、セクタヘッダＳＨには、フラグ情報Ｆが記録されている。
【００２６】
光ディスクドライブ部１９は、セクタヘッダＳＨの情報のみ認識可能であるので、図３のセクタヘッダＳＨ内に書かれたＢＥ有無を示すフラグ情報Ｆを参照して、ＢＥ暗号化を行うためのＢＥ暗号化対象領域を判別することになる。
【００２７】
（アプリケーション部１０−１がＢＥ暗号化対象領域を判別する方法）
一方、アプリケーション部１０−１はセクタヘッダＳＨの情報は参照できない。ＡＡＣＳ規格では、図４に示すように、ルート１０１の下のＡＡＣＳ１０２の下のＣｏｎｔｅｎｔ＿Ｃｅｒｔｉｆｉｃａｔｉｏｎファイル（ＣＣファイル）１０３に、コンテンツがＢＥ対象であるか否かのフラグ情報が記述されていることになっている。従って、このフラグ情報が有効な場合、アプリケーション部１０−１はメディア上の『．ＥＶＯファイル』１３２，１３４，１３６が全てＢＥ暗号化対象領域であると認識して、ＢＥ復号を行うなどの処理をすることになる。
【００２８】
図３及び図４に示すように、記録媒体にＢＥ暗号化対象領域を含むコンテンツを記録する際は、記録媒体の『．ＥＶＯファイル』が配置される物理的なセクタＳＴに対応するセクタヘッダＳＨに、正しくフラグ情報Ｆを記録する必要があることが分かる。
【００２９】
（光ディスクドライブ部１９でＢＥ暗号化しアプリケーション部１０−１でＢＥ復号しながら再生する方法）
一方、上述した図３及び図４の特徴に基づく、ＢＥ暗号化復号により行なわれるコンテンツデータの再生処理を、図５のフローチャートを用いて、詳細に説明する。
【００３０】
すなわち、アプリケーション部１０−１は、初めに、ＣＣファイルのリードコマンドを送信する（ステップＳ１１）。これに対して、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩ読出コマンドを供給する（ステップＳ１２）。これに対して、光ディスクドライブ部１９は、セクタデータのＡＴＡＰＩドライバ１９−１への返却を行なう（ステップＳ１３）。
【００３１】
ＡＴＡＰＩドライバ１９−１は、セクタデータをアプリケーション部１０−１に返却し、アプリケーション部１０−１は、ＣＣファイルの読み込みを行なう（ステップＳ１４）。すなわち、アプリケーション部１０−１は、セクタヘッダＳＨを読み取ることができず、図６のように、セクタに格納されたデータを読み出すことしかできないため、ＣＣファイル内のＢＥフラグを確認する（ステップＳ１５）。
【００３２】
アプリケーション部１０−１は、ＥＶＯＢの読み出し処理を行なう（ステップＳ１６）。これに対して、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩ読み出しコマンドを光ディスクドライブ部１９に供給する（ステップＳ１７）。光ディスクドライブ部１９は、セクタヘッダにＢＥフラグがあるかどうかを判断する（ステップＳ１８）。その結果、ＢＥフラグがあればセクタデータを暗号化する（ステップＳ１９）。ＢＥフラグがなければセクタデータを暗号化することなく、アプリケーション部１０−１に返却する（ステップＳ２０）。リードコマンドがアプリケーションに戻る（ステップＳ２１）。
【００３３】
これに対して、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあるかを判断する（ステップＳ２２）。あれば、セクタデータを復号する（ステップＳ２３）。そして、復号したデータを再生するが、ＣＣファイル中にＢＥフラグがなければ復号することなく復号したデータを再生する（ステップＳ２４）。
【００３４】
このように、ＢＥ暗号化復号により行なわれるコンテンツデータの再生処理を行なうことができる。
【００３５】
＜記録システムでのＬＢＡ管理テーブルを用いない記録処理＞
次に、本発明の一実施形態である記録システムにおいて、ＬＢＡ（ＬＢＡ：Logical Block Address）管理テーブルを用いることなく、配信サーバＳからストリームを供給し、ハードディスクレコーダ１０等のアプリケーション部１０−１でストリームの記録処理を行なう場合を、フローチャートを用いて説明する。図７は、本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャートである。図８は、同じく記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャートである。
【００３６】
（暗号化復号処理を行なわない場合）
初めに、ハードディスクレコーダ１０等のアプリケーション部１０−１は、コンテンツ要求を配信サーバＳに対してネットワーク等を介して行なう(ステップＳ３１)。これに対して、配信サーバＳは、ストリームをネットワーク等を介してダウンロードし、ダウンロードが完了したら完了したことをアプリケーションに通知する(ステップＳ３２)。
【００３７】
これに対して、アプリケーション部１０−１は、ダウンロードしたイメージファイルの中で『．ＥＶＯファイル』の書かれているセクタヘッダにのみＢＥフラグを設定する必要がある。従って、ダウンロードしたイメージファイルの中で『．ＥＶＯファイル』の配置されているＬＢＡ（ＬＢＡ：Logical Block Address）を知る必要がある。
【００３８】
この処理工程は、具体的にはステップＳ３３に示すように、初めに、アプリケーション部１０−１により、仮想的にイメージファイルを記憶領域にマウントすることから始まる。次に、イメージファイルのディレクトリをサーチして、ファイルリストを配信サーバＳに要望する。これに対して、アプリケーション部１０−１は、イメージファイルからファイルリストを取得し、図４に示すＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳファイル１０３（ＣＣファイル）を取得する。そして、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあるかどうかを判断する。
【００３９】
ここで、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがないと判断すれば、ＢＥ対応コンテンツイメージではないので、そのまま、光ディスクＤにストリームデータを記録する(ステップＳ３４)。
【００４０】
しかし、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあると判断すれば、『．ＥＶＯファイル』を探索し、『．ＥＶＯファイル』のＬＢＡ（ＬＢＡ：Logical Block Address）をＢＥ対応コンテンツイメージから取得する。そして、ＢＥフラグを設定するＬＢＡのリストを生成する。
【００４１】
更に、アプリケーション部１０−１は、イメージファイルのアンマウントを行なった後(ステップＳ３５)、ＢＥフラグを設定するＬＢＡを指定する(ステップＳ３６)。これに対して、ＡＴＡＰＩドライバ１９−１は、ＬＢＡ指定コマンドを発行する(ステップＳ３７)。これに対して、光ディスクドライブ部１９は、ＢＥフラグ設定し、ＬＢＡを記憶する(ステップＳ３８)。
【００４２】
一方、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し(ステップＳ４２)、ＡＴＡＰＩドライバ１９−１に、イメージファイルを書き込む(ステップＳ４３)。ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩライトコマンドを光ディスクドライブ部１９に供給する(ステップＳ４４)。光ディスクドライブ部１９は、ステップＳ３８のＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡならば、図３のセクタヘッダＳＨにフラグ情報Ｆを記録しながら、必要なストリームデータをセクタに順次、記録していく(ステップＳ３９)。
【００４３】
これらの処理が完了すれば、光ディスクドライブ部１９は、完了信号をＡＴＡＰＩドライバ１９−１に供給し(ステップＳ４０)、ＡＴＡＰＩドライバ１９−１は、書込み完了信号をアプリケーション部１０−１に供給する(ステップＳ４１)。
【００４４】
このようにして、配信サーバＳから供給されたストリームを、光ディスクドライブ部１９により、光ディスクＤ等の記録媒体へ記録を行なうものである。
【００４５】
以上のステップＳ３３に記載された一連の処理は、ＰＣ機器など仮想ドライブの技術が発達した環境では、コンテンツイメージからＬＢＡ情報を取得することはそれほど負荷の高い作業ではない。しかしながら、組み込み機器などにおいては、このようなステップＳ３３に記載された一連の処理は、非常に負荷の高い作業となるため、ストリームのダウンロードから記録処理を円滑に行なうことが難しいという問題がある。
【００４６】
なお、図７のフローチャートにおいては、ＢＥ暗号化復号処理を行なってはいない。これは、ハードディスクレコーダ１０等の構造が比較的セキュアであり、処理の負担となるＢＥ暗号化復号処理を省略しても、ストリームは安全であるとの考えに基づくものである。
【００４７】
しかし、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合は、図８のフローチャートに示すように、本来のＢＥ暗号化復号処理を行なうことで、セキュリティの確保に勤めるものである。
【００４８】
なお、ＡＡＣＳ規格では、ＲＯＭメディアだけでなくネットワーク経由でダウンロードされるコンテンツについても、ＢＥ対象のコンテンツとして扱うことを検討している。
【００４９】
（暗号化復号処理を行なう場合）
次に、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合について、暗号化復号処理を行なう際の動作を、図８のフローチャートを用いて説明する。ここでは、図７のフローチャートと共通した記載は説明を省略し、異なる記載のみについて、説明を行なう。
【００５０】
すなわち、ステップＳ４２において、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、先に作成したＬＢＡリストに基づき、その領域のデータが暗号化対象領域であると判断すれば(ステップＳ５１)、アプリケーション部１０−１は、ＢＥ暗号管理部４２等により、ストリームデータを暗号化する(ステップＳ５２)。しかし、アプリケーション部１０−１は、ＬＢＡリストに基づきその領域のデータが非暗号化対象領域であると判断すれば、ストリームデータの暗号化は行なわない。
【００５１】
次に、アプリケーション部１０−１は、必要に応じて暗号化を行なったストリームデータをＡＴＡＰＩドライバ１９−１に供給し、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩｗｒｉｔｅコマンドを光ディスクドライブ部１９に供給する(ステップＳ５４)。光ディスクドライブ部１９では、ステップＳ３８で記憶しているＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡなら、そのセクタヘッダＳＨにフラグ情報Ｆをセットする。そして、光ディスクドライブ部１９は、供給された暗号化されたストリームデータのＢＥ復号を順次行い、復号されたストリームデータを所定のセクタに記録していく(ステップＳ５５)。
【００５２】
このようにして、ＢＥ暗号化復号処理を暗号化対象領域のストリームデータに施すことにより、ストリームデータの安全性を確保するものである。
【００５３】
＜本発明の一実施形態である記録システムのＬＢＡ管理テーブルを用いる記録処理＞
しかしながら、上述した記録システムにおいては、アプリケーション部１０−１において、ステップＳ３３に示すように、ＢＥ対応コンテンツイメージからＣＣファイルを読み出し、ＢＥフラグを検出し、『．ＥＶＯファイル』を探索し、これに基づいてＬＢＡリストを生成するという、非常に高負荷な処理を必要としていた。このため、特に、処理能力が十分ではない装置においては、円滑な記録処理を困難にしていた。
【００５４】
これに対して、本発明の一実施形態である記録システムでは、配信サーバＳにおいて、ストリームの暗号化対象領域と非暗号化対象領域を判断するためのアドレス情報であるＢＥ対象ＬＢＡの管理テーブルを用意し、これをストリームと共に、アプリケーション部１０−１を有する装置に供給する。これにより、アプリケーション部１０−１は、ステップＳ３３に示すような高負荷な処理を行なう必要がなくなるため、円滑で迅速な記録媒体への記録処理を可能にする。
【００５５】
以下、本発明の一実施形態である記録システムのＬＢＡ管理テーブルを用いる記録処理を図面を用いて詳細に説明する。図９は、同じく記録システムが供給するＬＢＡ管理テーブルの一例を示す説明図である。図１０は、同じく記録システムの記録方法の一例を示すフローチャートである。図１１は、同じく記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャートである。
【００５６】
初めに、配信サーバＳからＢＥ対応コンテンツイメージと共に供給されるＢＥ対応ＬＢＡの管理テーブル１４１を図９に示す。この管理テーブル１４１には、ＢＥ対応有無のフラグと、ＢＥ対象領域の個数（ｎ）と、ＢＥ対象ＬＢＡ（１）と、ＢＥ対象ＬＢＡ（１）からの長さが各々示されている。このＬＢＡの管理テーブル１４１により、コンテンツイメージから直接『．ＥＶＯファイル』のＬＢＡを検索しなくとも、コンテンツイメージとは別の管理テーブルを配信サーバが予め用意しておくことにより、書込みアプリの実装負荷を軽減することができる。
【００５７】
（暗号化復号処理を行なわない場合）
次に、このＢＥ対応対象ＬＢＡの管理テーブルを用いた暗号化復号処理を行なわない場合の記録処理を図１０のフローチャートを用いて説明する。
【００５８】
ハードディスクレコーダ１０のアプリケーション部１０−１は、コンテンツイメージをＬＢＡ管理テーブルの要求をネットワーク等を介して、配信サーバＳに行なう（ステップＳ６１）。配信サーバＳは、これに対して、コンテンツイメージと、図９に示したＬＢＡの管理テーブル１４１をハードディスクレコーダ１０のアプリケーション部１０−１に供給する(ステップＳ６２)。
【００５９】
アプリケーション部１０−１は、ＬＢＡの管理テーブル１４１にてＢＥ対応有無フラグの確認を行い(ステップＳ６３)、ＢＥ対応ではないと判断すれば、ＢＥ対応コンテンツイメージではないとして、ストリームデータをそのまま光ディスクＤ等に記録するべく、ＡＴＡＰＩドライバ１９−１を介して、光ディスクドライブ部１９に命令する。
【００６０】
アプリケーション部１０−１は、ＬＢＡの管理テーブル１４１にてＢＥ対応有無フラグがありと判断すれば、次に、ＬＢＡの管理テーブル１４１に基づいて、全ての『．ＥＶＯ拡張子』ファイルのＬＢＡを取得する(ステップＳ６５)。そして、ＢＥフラグを設定するＬＢＡを指定する(ステップＳ６６)。ＡＴＡＰＩドライバ１９−１は、これに対して、ＬＢＡ指定コマンドを光ディスクドライブ部１９に発行する(ステップＳ６７)。光ディスクドライブ部１９は、これに対して、ＢＥフラグ設定ＬＢＡを記憶する(ステップＳ６８)。
【００６１】
一方、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、ＡＴＡＰＩドライバ１９−１に、イメージファイルを書き込む(ステップＳ６９)。ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩライトコマンドを光ディスクドライブ部１９に供給する(ステップＳ７０)。光ディスクドライブ部１９は、ステップＳ６８のＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡならば、図３のセクタヘッダＳＨにフラグ情報Ｆを記録しながら、必要なストリームデータをセクタに順次、記録していく(ステップＳ７１)。
【００６２】
これらの処理が完了すれば、光ディスクドライブ部１９は、完了信号をＡＴＡＰＩドライバ１９−１に供給し(ステップＳ７２)、ＡＴＡＰＩドライバ１９−１は、書込み完了信号をアプリケーション部１０−１に供給する(ステップＳ７３)。
【００６３】
このようにして、配信サーバＳから供給されたストリームを、同じく供給されたＬＢＡの管理テーブル１４１に基づいて、光ディスクドライブ部１９により、光ディスクＤ等の記録媒体へ迅速に記録を行なうものである。
【００６４】
ここで、図１０のフローチャートにおいては、ＢＥ暗号化復号処理を行なってはいない。これは、ハードディスクレコーダ１０等の構造が比較的セキュアであり、処理の負担となるＢＥ暗号化復号処理を省略しても、ストリームは安全であるとの考えに基づくものである。
【００６５】
しかし、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合は、次に示す図１１のフローチャートのように、本来のＢＥ暗号化復号処理を行なうことで、セキュリティの確保に勤めるものである。
【００６６】
（暗号化復号処理を行なう場合）
次に、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合について、暗号化復号処理を伴う場合のＢＥ対応対象ＬＢＡの管理テーブルを用いた記録処理を図１１のフローチャートを用いて説明する。ここでは、図１０のフローチャートと共通した記載は説明を省略し、異なる記載のみについて、説明を行なう。
【００６７】
すなわち、ステップＳ８１において、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、ＢＥ対応対象ＬＢＡの管理テーブルに基づき、その領域のデータが暗号化対象領域であると判断すれば、アプリケーション部１０−１は、ＢＥ暗号管理部４２等により、ストリームデータを暗号化する(ステップＳ８２)。しかし、アプリケーション部１０−１は、ＬＢＡリストに基づきその領域のデータが非暗号化対象領域であると判断すれば、ストリームデータの暗号化は行なわない。
【００６８】
次に、アプリケーション部１０−１は、必要に応じて暗号化を行なったストリームデータをＡＴＡＰＩドライバ１９−１に供給し、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩｗｒｉｔｅコマンドを光ディスクドライブ部１９に供給する(ステップＳ８３)。光ディスクドライブ部１９では、ステップＳ６８で記憶しているＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡなら、そのセクタヘッダＳＨにフラグ情報Ｆをセットする。そして、光ディスクドライブ部１９は、供給された暗号化されたストリームデータのＢＥ復号を順次行い、復号されたストリームデータを所定のセクタに記録していく(ステップＳ８５)。
【００６９】
このようにして、配信サーバＳから供給されたＢＥ対応対象ＬＢＡの管理テーブル１４１を利用して、ＢＥ暗号化復号処理を暗号化対象領域のストリームデータに施すことにより、ストリームデータの安全性を低負荷な処理において実現するものである。
【００７０】
以上記載した様々な実施形態により、当業者は本発明を実現することができるが、更にこれらの実施形態の様々な変形例を思いつくことが当業者によって容易であり、発明的な能力をもたなくとも様々な実施形態へと適用することが可能である。従って、本発明は、開示された原理と新規な特徴に矛盾しない広範な範囲に及ぶものであり、上述した実施形態に限定されるものではない。
【図面の簡単な説明】
【００７１】
【図１】本発明の一実施形態に係る記録システムの構成の一例を示す説明図。
【図２】本発明の一実施形態に係る記録装置の構成の一例を示すブロック図。
【図３】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の一例を示す説明図。
【図４】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのデータ構造の一例を示す説明図。
【図５】本発明の一実施形態に係る記録装置のコンテンツの再生方法の一例を示すフローチャート。
【図６】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の他の一例を示す説明図。
【図７】本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャート。
【図８】本発明の一実施形態に係る記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャート。
【図９】本発明の一実施形態に係る記録システムが供給するＬＢＡ管理テーブルの一例を示す説明図。
【図１０】本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャート。
【図１１】本発明の一実施形態に係る記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャート。
【符号の説明】
【００７２】
Ｄ…光ディスク、１０…ハードディスクレコーダ、１９…光ディスクドライバ、Ｓ…配信サーバ。
【技術分野】
【０００１】
この発明は、ストリームとこのストリームの暗号化対象領域を示すアドレス情報を受けて、暗号化対象領域のデータが記録される記録媒体のセクタに管理情報を記録する記録装置及び記録方法並びにこのストリームを供給するサーバ装置に関する。
【背景技術】
【０００２】
周知のように、次世代の記録媒体の記録処理に対しては、ＡＡＣＳ（Advanced Access Control System）規格等のフォームが知られている。特許文献１は、ＡＡＣＳによって著作権保護されたコンテンツが記録されたメディアを再生する場合、メディア鍵の生成に要する処理負荷を低減することができるメディア鍵生成方法を提供している。
【特許文献１】特開２００７−０１３４４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、特許文献１の従来技術は、ＡＡＣＳ規格に準じたストリームをダウンロードして、ＢＥ暗号等を行ない光ディスク等にストリームを記録しようとする場合、ストリームを受けたアプリケーション等は、少なくとも、ＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳ等のファイルからＢＥフラグの情報を取得しなければならない。そして、ダウンロードしたイメージファイルからＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳ等のファイルを検出し、このファイル中のＢＥフラグがあれば、『．ＥＶＯファイル』を探索し、ＥＶＯファイルのＬＢＡを取得してＢＥフラグを設定するＬＢＡリストを作成し、ストリームのうち暗号化対象領域のデータであれば、セクタヘッダにＢＥフラグを記録しなければならない。
【０００４】
しかし、ストリームをダウンロードするアプリケーションにとっては、この作業は非常に負荷の高い作業となり、円滑な処理動作が困難となる。
【０００５】
本発明は、ダウンロードしたストリームの特に暗号化対象領域について円滑な記録処理を行なうことができる記録装置及び記録方法並びにサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
課題を解決するための一実施形態は、
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受ける受信部（１１）と、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部（２１，１９）と、
を具備することを特徴とする記録装置である。
【発明の効果】
【０００７】
サーバ装置からストリームと、ストリームの暗号化対象領域を示すアドレス情報であるＢＥ対象のＬＢＡ管理テーブルも一緒にアプリケーション等にダウンロードする。これにより、アプリケーションで『．ＥＶＯファイル』を探索しＬＢＡリストを生成するという高負荷な工程が不要となり、光ディスク等への円滑な記録処理が可能となる。
【発明を実施するための最良の形態】
【０００８】
以下、この発明の実施の形態について図面を参照して詳細に説明する。
【０００９】
＜本発明の一実施形態である記録システムの構成の一例＞
初めに、本発明の一実施形態である記録システムの構成の一例を図面を用いて説明する。図１は、本発明の一実施形態に係る記録システムの構成の一例を示す説明図である。図２は、同じく記録装置の構成の一例を示すブロック図である。
【００１０】
本発明の一実施形態である記録システムＲＳは、図１に示すように、ＢＥコンテンツイメージを配信する配信サーバＳと、これにインターネット等のネットワークを介して接続されるハードディスクレコーダ１０を有している。ここで、ハードディスクレコーダ１０は、内蔵される記録処理及び再生処理を行なうアプリケーション１０−１と、バスＢ等でハードディスクレコーダ１０の処理回路に接続される光ディスクドライブ部１９を含んでおり、更に、光ディスクドライブ部１９とアプリケーション部１０−１は、ＡＴＡＰＩドライバ１９−１を用いてバスＢでデータ転送を行なっている。
【００１１】
（ハードディスクレコーダ１０の構成）
次に、図２に示すハードディスクレコーダ１０の構成を示す。ハードディスクレコーダ１０は、２種類のディスクドライブ部を有する。まず、ビデオファイルを構築できる情報記録媒体である第１のメディアとしての光ディスクＤを回転駆動し、情報の読み書きを実行する光ディスクドライブ部１９を有する。ここで、光ディスクＤは、一例として、ＨＤ ＤＶＤであるがこれに限定されるものではない。又、第２のメディアとしてのハードディスクを駆動するハードディスクドライブ部１８を有する。制御部３０は、全体の動作を司るべくバスＢを介して各部に接続されている。
【００１２】
又、図２に示されるハードディスクレコーダ１０は、録画側を構成するエンコーダ部２１と、再生側を構成するＭＰＥＧデコーダ部２３と、装置本体の動作を制御する制御部３０とを主たる構成要素としている。ハードディスクレコーダ１０は、入力側のセレクタ部１６と出力側のセレクタ部１７とを有しており、入力側のセレクタ部１６には、ＬＡＮ等の通信部１１と、いわゆる衛星放送（ＢＳ／ＣＳ）チューナ部１２と、いわゆる地上波チューナ部１３とが接続され、エンコーダ部２１に信号を出力する。又、ＢＳ／ＣＳチューナ部１２には衛星アンテナが、地上波チューナ部１３には地上波アンテナが接続されている。又、ハードディスクレコーダ１０は、エンコーダ部２１と、エンコーダ部２１の出力を受け、データ編集等の所望のデータ処理を行うデータ編集部２０と、データ編集部２０に接続されるハードディスクドライブ部１８と、光ディスクドライブ部１９を有している。更に、ハードディスクレコーダ１０は、ハードディスクドライブ部１８と、光ディスクドライブ部１９からの信号を受けてデコードするＭＰＥＧデコーダ部２３と、エンコーダ部２１と、バッファ部２２と、ＭＰＥＧデコーダ部２３と、多重化部２８と、分離部２９と、制御部３０と、映像画面に所望の映像を合成するＯＳＤ部３１と、後述するＢＥ暗号化処理及び復号処理等を行なうＢＥ暗号管理部４２と、予約リストや番組表画像を生成する予約録画部４３を有している。これらの各部は、バスＢを介して制御部３０に接続されている。更に、セレクタ部１７の出力は、外部の受像機４１に接続されるか、外部装置との通信を行うインターフェース部２７を介して、外部装置に供給される。
【００１３】
なお、ここで図１で示したアプリケーション部１０−１は、再生機能及び記録機能に該当するものであり、図２においては、制御部３０、ＢＥ暗号管理部４２、エンコーダ部２１、ＭＰＥＧデコーダ部２３等を主な構成とする。
【００１４】
更に、ハードディスクレコーダ１０は、バスＢを介して制御部３０に接続され、ユーザの操作やリモコンＲの操作を受ける操作部３２を有している。ここで、リモコンＲは、ハードディスクレコーダ１０の本体に設けられる操作部３２とほぼ同等の操作を可能とするものであり、ハードディスクドライブ部１８や光ディスクドライブ部１９の記録再生指示や、編集指示、チューナの操作、予約録画の設定等の各種設定が可能である。
【００１５】
（基本動作）
このような構成のハードディスクレコーダ１０において、光ディスクに例を取って、再生処理と記録処理の概要を説明する。すなわち、制御部３０の制御下において、所定速度に回転される光ディスクＤは、レーザ光が照射されその反射光が光ピックアップにより検出され、これに基づく検出信号が出力される。この検出信号に基づいて、ＲＦ信号が生成され、データの読取処理に続いて再生処理が行われる。
【００１６】
又、光ディスクの記録処理は、制御部３０の制御下において、例えば図示しない入力部を介しセレクタ部１６を介して供給されたデータは、エンコーダ部２１に供給され、コード化されて出力される。このコード化出力と制御部３０の出力に応じて、レーザドライバの駆動電流が光ピックアップに供給され、光ディスクＤの記憶領域に照射することで、記録処理が行われるものである。
【００１７】
＜本発明の一実施形態である記録システムのＢＥ暗号化処理＞
次に、上述した本発明の一実施形態である記録システムＲＳのＢＥ暗号化処理の概要を図面を用いて説明する。図３は、本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の一例を示す説明図である。図４は、同じく記録装置が扱うＢＥ対応コンテンツのデータ構造の一例を示す説明図である。図５は、同じく記録装置のコンテンツの再生方法の一例を示すフローチャートである。図６は、同じく記録装置が扱うＢＥ対応コンテンツのイメージ構造の他の一例を示す説明図である。
【００１８】
なお、以下の図５、図７、図８、図１１のフローチャートの各ステップは、回路ブロックに置き換えることができ、従って、各フローチャートのステップは、全てブロックに定義しなおすことが可能である。
【００１９】
本発明の一実施形態である記録システムＲＳのハードディスクレコーダ１０が行なうＢｕｓＥｎｃｒｙｐｔｉｏｎ機能について、以下に説明する。
【００２０】
ＡＡＣＳ規格では、ＢｕｓＥｎｃｒｙｐｔｉｏｎ（ＢＥ）機能が新規機能として提案されつつある状況となっている。
【００２１】
ＢＥ機能とは、不当な第三者がバスＢ等からコンテンツデータを不正にコピーする等の行為に対する保護を目的として設けられる暗号化復号機能である。従って、ＢＥ機能は、ＨＤ ＤＶＤ−ＲＯＭ／Ｒメディアなどを再生する際に、光ディスクドライブ部１９と、アプリケーション部１０−１の間で共有された秘密鍵を用いて、光ディスクドライブ部１９で暗号化したデータをアプリケーション部１０−１のＢＥ暗号管理部４２で復号しながらデータ転送を行う機能のことである。
【００２２】
同様に、ＢＥ機能は、ストリームデータをＲメディアなどに記録する場合、アプリケーション部１０−１のＢＥ暗号管理部４２で暗号化したデータを光ディスクドライブ部１９で復号しながらデータ転送する機能も含まれる。
【００２３】
ＨＤ ＤＶＤ−ＶＩＤＥＯ規格のコンテンツデータにＢＥ機能を適用した場合、図４に示すように、ＢＥ暗号化対象となるファイルは、『．ＥＶＯ拡張子』を持つファイル１３２，１３４，１３６のみとなる。
【００２４】
ここで注目すべきは、光ディスクドライブ部１９がＢＥ暗号化対象領域を判別する方法と、アプリケーション部１０−１がＢＥ暗号化対象領域を判別する方法は以下のように異なっている。
【００２５】
（光ディスクドライブ部１９がＢＥ暗号化対象領域を判別する方法）
ＢＥ暗号化対象領域を含むＨＤ ＤＶＤ−ＶＩＤＥＯ規格のコンテンツデータは、光ディスクＤで図３に示すようなセクタ構造、すなわち、セクタＳＴの先端にセクタヘッダＳＨをもっており、セクタヘッダＳＨには、フラグ情報Ｆが記録されている。
【００２６】
光ディスクドライブ部１９は、セクタヘッダＳＨの情報のみ認識可能であるので、図３のセクタヘッダＳＨ内に書かれたＢＥ有無を示すフラグ情報Ｆを参照して、ＢＥ暗号化を行うためのＢＥ暗号化対象領域を判別することになる。
【００２７】
（アプリケーション部１０−１がＢＥ暗号化対象領域を判別する方法）
一方、アプリケーション部１０−１はセクタヘッダＳＨの情報は参照できない。ＡＡＣＳ規格では、図４に示すように、ルート１０１の下のＡＡＣＳ１０２の下のＣｏｎｔｅｎｔ＿Ｃｅｒｔｉｆｉｃａｔｉｏｎファイル（ＣＣファイル）１０３に、コンテンツがＢＥ対象であるか否かのフラグ情報が記述されていることになっている。従って、このフラグ情報が有効な場合、アプリケーション部１０−１はメディア上の『．ＥＶＯファイル』１３２，１３４，１３６が全てＢＥ暗号化対象領域であると認識して、ＢＥ復号を行うなどの処理をすることになる。
【００２８】
図３及び図４に示すように、記録媒体にＢＥ暗号化対象領域を含むコンテンツを記録する際は、記録媒体の『．ＥＶＯファイル』が配置される物理的なセクタＳＴに対応するセクタヘッダＳＨに、正しくフラグ情報Ｆを記録する必要があることが分かる。
【００２９】
（光ディスクドライブ部１９でＢＥ暗号化しアプリケーション部１０−１でＢＥ復号しながら再生する方法）
一方、上述した図３及び図４の特徴に基づく、ＢＥ暗号化復号により行なわれるコンテンツデータの再生処理を、図５のフローチャートを用いて、詳細に説明する。
【００３０】
すなわち、アプリケーション部１０−１は、初めに、ＣＣファイルのリードコマンドを送信する（ステップＳ１１）。これに対して、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩ読出コマンドを供給する（ステップＳ１２）。これに対して、光ディスクドライブ部１９は、セクタデータのＡＴＡＰＩドライバ１９−１への返却を行なう（ステップＳ１３）。
【００３１】
ＡＴＡＰＩドライバ１９−１は、セクタデータをアプリケーション部１０−１に返却し、アプリケーション部１０−１は、ＣＣファイルの読み込みを行なう（ステップＳ１４）。すなわち、アプリケーション部１０−１は、セクタヘッダＳＨを読み取ることができず、図６のように、セクタに格納されたデータを読み出すことしかできないため、ＣＣファイル内のＢＥフラグを確認する（ステップＳ１５）。
【００３２】
アプリケーション部１０−１は、ＥＶＯＢの読み出し処理を行なう（ステップＳ１６）。これに対して、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩ読み出しコマンドを光ディスクドライブ部１９に供給する（ステップＳ１７）。光ディスクドライブ部１９は、セクタヘッダにＢＥフラグがあるかどうかを判断する（ステップＳ１８）。その結果、ＢＥフラグがあればセクタデータを暗号化する（ステップＳ１９）。ＢＥフラグがなければセクタデータを暗号化することなく、アプリケーション部１０−１に返却する（ステップＳ２０）。リードコマンドがアプリケーションに戻る（ステップＳ２１）。
【００３３】
これに対して、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあるかを判断する（ステップＳ２２）。あれば、セクタデータを復号する（ステップＳ２３）。そして、復号したデータを再生するが、ＣＣファイル中にＢＥフラグがなければ復号することなく復号したデータを再生する（ステップＳ２４）。
【００３４】
このように、ＢＥ暗号化復号により行なわれるコンテンツデータの再生処理を行なうことができる。
【００３５】
＜記録システムでのＬＢＡ管理テーブルを用いない記録処理＞
次に、本発明の一実施形態である記録システムにおいて、ＬＢＡ（ＬＢＡ：Logical Block Address）管理テーブルを用いることなく、配信サーバＳからストリームを供給し、ハードディスクレコーダ１０等のアプリケーション部１０−１でストリームの記録処理を行なう場合を、フローチャートを用いて説明する。図７は、本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャートである。図８は、同じく記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャートである。
【００３６】
（暗号化復号処理を行なわない場合）
初めに、ハードディスクレコーダ１０等のアプリケーション部１０−１は、コンテンツ要求を配信サーバＳに対してネットワーク等を介して行なう(ステップＳ３１)。これに対して、配信サーバＳは、ストリームをネットワーク等を介してダウンロードし、ダウンロードが完了したら完了したことをアプリケーションに通知する(ステップＳ３２)。
【００３７】
これに対して、アプリケーション部１０−１は、ダウンロードしたイメージファイルの中で『．ＥＶＯファイル』の書かれているセクタヘッダにのみＢＥフラグを設定する必要がある。従って、ダウンロードしたイメージファイルの中で『．ＥＶＯファイル』の配置されているＬＢＡ（ＬＢＡ：Logical Block Address）を知る必要がある。
【００３８】
この処理工程は、具体的にはステップＳ３３に示すように、初めに、アプリケーション部１０−１により、仮想的にイメージファイルを記憶領域にマウントすることから始まる。次に、イメージファイルのディレクトリをサーチして、ファイルリストを配信サーバＳに要望する。これに対して、アプリケーション部１０−１は、イメージファイルからファイルリストを取得し、図４に示すＣＯＮＴＥＮＴ＿ＣＥＲＴ．ＡＡＣＳファイル１０３（ＣＣファイル）を取得する。そして、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあるかどうかを判断する。
【００３９】
ここで、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがないと判断すれば、ＢＥ対応コンテンツイメージではないので、そのまま、光ディスクＤにストリームデータを記録する(ステップＳ３４)。
【００４０】
しかし、アプリケーション部１０−１は、ＣＣファイル中にＢＥフラグがあると判断すれば、『．ＥＶＯファイル』を探索し、『．ＥＶＯファイル』のＬＢＡ（ＬＢＡ：Logical Block Address）をＢＥ対応コンテンツイメージから取得する。そして、ＢＥフラグを設定するＬＢＡのリストを生成する。
【００４１】
更に、アプリケーション部１０−１は、イメージファイルのアンマウントを行なった後(ステップＳ３５)、ＢＥフラグを設定するＬＢＡを指定する(ステップＳ３６)。これに対して、ＡＴＡＰＩドライバ１９−１は、ＬＢＡ指定コマンドを発行する(ステップＳ３７)。これに対して、光ディスクドライブ部１９は、ＢＥフラグ設定し、ＬＢＡを記憶する(ステップＳ３８)。
【００４２】
一方、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し(ステップＳ４２)、ＡＴＡＰＩドライバ１９−１に、イメージファイルを書き込む(ステップＳ４３)。ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩライトコマンドを光ディスクドライブ部１９に供給する(ステップＳ４４)。光ディスクドライブ部１９は、ステップＳ３８のＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡならば、図３のセクタヘッダＳＨにフラグ情報Ｆを記録しながら、必要なストリームデータをセクタに順次、記録していく(ステップＳ３９)。
【００４３】
これらの処理が完了すれば、光ディスクドライブ部１９は、完了信号をＡＴＡＰＩドライバ１９−１に供給し(ステップＳ４０)、ＡＴＡＰＩドライバ１９−１は、書込み完了信号をアプリケーション部１０−１に供給する(ステップＳ４１)。
【００４４】
このようにして、配信サーバＳから供給されたストリームを、光ディスクドライブ部１９により、光ディスクＤ等の記録媒体へ記録を行なうものである。
【００４５】
以上のステップＳ３３に記載された一連の処理は、ＰＣ機器など仮想ドライブの技術が発達した環境では、コンテンツイメージからＬＢＡ情報を取得することはそれほど負荷の高い作業ではない。しかしながら、組み込み機器などにおいては、このようなステップＳ３３に記載された一連の処理は、非常に負荷の高い作業となるため、ストリームのダウンロードから記録処理を円滑に行なうことが難しいという問題がある。
【００４６】
なお、図７のフローチャートにおいては、ＢＥ暗号化復号処理を行なってはいない。これは、ハードディスクレコーダ１０等の構造が比較的セキュアであり、処理の負担となるＢＥ暗号化復号処理を省略しても、ストリームは安全であるとの考えに基づくものである。
【００４７】
しかし、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合は、図８のフローチャートに示すように、本来のＢＥ暗号化復号処理を行なうことで、セキュリティの確保に勤めるものである。
【００４８】
なお、ＡＡＣＳ規格では、ＲＯＭメディアだけでなくネットワーク経由でダウンロードされるコンテンツについても、ＢＥ対象のコンテンツとして扱うことを検討している。
【００４９】
（暗号化復号処理を行なう場合）
次に、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合について、暗号化復号処理を行なう際の動作を、図８のフローチャートを用いて説明する。ここでは、図７のフローチャートと共通した記載は説明を省略し、異なる記載のみについて、説明を行なう。
【００５０】
すなわち、ステップＳ４２において、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、先に作成したＬＢＡリストに基づき、その領域のデータが暗号化対象領域であると判断すれば(ステップＳ５１)、アプリケーション部１０−１は、ＢＥ暗号管理部４２等により、ストリームデータを暗号化する(ステップＳ５２)。しかし、アプリケーション部１０−１は、ＬＢＡリストに基づきその領域のデータが非暗号化対象領域であると判断すれば、ストリームデータの暗号化は行なわない。
【００５１】
次に、アプリケーション部１０−１は、必要に応じて暗号化を行なったストリームデータをＡＴＡＰＩドライバ１９−１に供給し、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩｗｒｉｔｅコマンドを光ディスクドライブ部１９に供給する(ステップＳ５４)。光ディスクドライブ部１９では、ステップＳ３８で記憶しているＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡなら、そのセクタヘッダＳＨにフラグ情報Ｆをセットする。そして、光ディスクドライブ部１９は、供給された暗号化されたストリームデータのＢＥ復号を順次行い、復号されたストリームデータを所定のセクタに記録していく(ステップＳ５５)。
【００５２】
このようにして、ＢＥ暗号化復号処理を暗号化対象領域のストリームデータに施すことにより、ストリームデータの安全性を確保するものである。
【００５３】
＜本発明の一実施形態である記録システムのＬＢＡ管理テーブルを用いる記録処理＞
しかしながら、上述した記録システムにおいては、アプリケーション部１０−１において、ステップＳ３３に示すように、ＢＥ対応コンテンツイメージからＣＣファイルを読み出し、ＢＥフラグを検出し、『．ＥＶＯファイル』を探索し、これに基づいてＬＢＡリストを生成するという、非常に高負荷な処理を必要としていた。このため、特に、処理能力が十分ではない装置においては、円滑な記録処理を困難にしていた。
【００５４】
これに対して、本発明の一実施形態である記録システムでは、配信サーバＳにおいて、ストリームの暗号化対象領域と非暗号化対象領域を判断するためのアドレス情報であるＢＥ対象ＬＢＡの管理テーブルを用意し、これをストリームと共に、アプリケーション部１０−１を有する装置に供給する。これにより、アプリケーション部１０−１は、ステップＳ３３に示すような高負荷な処理を行なう必要がなくなるため、円滑で迅速な記録媒体への記録処理を可能にする。
【００５５】
以下、本発明の一実施形態である記録システムのＬＢＡ管理テーブルを用いる記録処理を図面を用いて詳細に説明する。図９は、同じく記録システムが供給するＬＢＡ管理テーブルの一例を示す説明図である。図１０は、同じく記録システムの記録方法の一例を示すフローチャートである。図１１は、同じく記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャートである。
【００５６】
初めに、配信サーバＳからＢＥ対応コンテンツイメージと共に供給されるＢＥ対応ＬＢＡの管理テーブル１４１を図９に示す。この管理テーブル１４１には、ＢＥ対応有無のフラグと、ＢＥ対象領域の個数（ｎ）と、ＢＥ対象ＬＢＡ（１）と、ＢＥ対象ＬＢＡ（１）からの長さが各々示されている。このＬＢＡの管理テーブル１４１により、コンテンツイメージから直接『．ＥＶＯファイル』のＬＢＡを検索しなくとも、コンテンツイメージとは別の管理テーブルを配信サーバが予め用意しておくことにより、書込みアプリの実装負荷を軽減することができる。
【００５７】
（暗号化復号処理を行なわない場合）
次に、このＢＥ対応対象ＬＢＡの管理テーブルを用いた暗号化復号処理を行なわない場合の記録処理を図１０のフローチャートを用いて説明する。
【００５８】
ハードディスクレコーダ１０のアプリケーション部１０−１は、コンテンツイメージをＬＢＡ管理テーブルの要求をネットワーク等を介して、配信サーバＳに行なう（ステップＳ６１）。配信サーバＳは、これに対して、コンテンツイメージと、図９に示したＬＢＡの管理テーブル１４１をハードディスクレコーダ１０のアプリケーション部１０−１に供給する(ステップＳ６２)。
【００５９】
アプリケーション部１０−１は、ＬＢＡの管理テーブル１４１にてＢＥ対応有無フラグの確認を行い(ステップＳ６３)、ＢＥ対応ではないと判断すれば、ＢＥ対応コンテンツイメージではないとして、ストリームデータをそのまま光ディスクＤ等に記録するべく、ＡＴＡＰＩドライバ１９−１を介して、光ディスクドライブ部１９に命令する。
【００６０】
アプリケーション部１０−１は、ＬＢＡの管理テーブル１４１にてＢＥ対応有無フラグがありと判断すれば、次に、ＬＢＡの管理テーブル１４１に基づいて、全ての『．ＥＶＯ拡張子』ファイルのＬＢＡを取得する(ステップＳ６５)。そして、ＢＥフラグを設定するＬＢＡを指定する(ステップＳ６６)。ＡＴＡＰＩドライバ１９−１は、これに対して、ＬＢＡ指定コマンドを光ディスクドライブ部１９に発行する(ステップＳ６７)。光ディスクドライブ部１９は、これに対して、ＢＥフラグ設定ＬＢＡを記憶する(ステップＳ６８)。
【００６１】
一方、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、ＡＴＡＰＩドライバ１９−１に、イメージファイルを書き込む(ステップＳ６９)。ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩライトコマンドを光ディスクドライブ部１９に供給する(ステップＳ７０)。光ディスクドライブ部１９は、ステップＳ６８のＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡならば、図３のセクタヘッダＳＨにフラグ情報Ｆを記録しながら、必要なストリームデータをセクタに順次、記録していく(ステップＳ７１)。
【００６２】
これらの処理が完了すれば、光ディスクドライブ部１９は、完了信号をＡＴＡＰＩドライバ１９−１に供給し(ステップＳ７２)、ＡＴＡＰＩドライバ１９−１は、書込み完了信号をアプリケーション部１０−１に供給する(ステップＳ７３)。
【００６３】
このようにして、配信サーバＳから供給されたストリームを、同じく供給されたＬＢＡの管理テーブル１４１に基づいて、光ディスクドライブ部１９により、光ディスクＤ等の記録媒体へ迅速に記録を行なうものである。
【００６４】
ここで、図１０のフローチャートにおいては、ＢＥ暗号化復号処理を行なってはいない。これは、ハードディスクレコーダ１０等の構造が比較的セキュアであり、処理の負担となるＢＥ暗号化復号処理を省略しても、ストリームは安全であるとの考えに基づくものである。
【００６５】
しかし、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合は、次に示す図１１のフローチャートのように、本来のＢＥ暗号化復号処理を行なうことで、セキュリティの確保に勤めるものである。
【００６６】
（暗号化復号処理を行なう場合）
次に、ハードディスクレコーダ１０等の装置の構造が、例えば、ＰＣ等であり、第３者の不正なコンテンツ取得の脅威に晒されていると判断する場合について、暗号化復号処理を伴う場合のＢＥ対応対象ＬＢＡの管理テーブルを用いた記録処理を図１１のフローチャートを用いて説明する。ここでは、図１０のフローチャートと共通した記載は説明を省略し、異なる記載のみについて、説明を行なう。
【００６７】
すなわち、ステップＳ８１において、アプリケーション部１０−１は、ＢＥ対応コンテンツイメージを取得し、ＢＥ対応対象ＬＢＡの管理テーブルに基づき、その領域のデータが暗号化対象領域であると判断すれば、アプリケーション部１０−１は、ＢＥ暗号管理部４２等により、ストリームデータを暗号化する(ステップＳ８２)。しかし、アプリケーション部１０−１は、ＬＢＡリストに基づきその領域のデータが非暗号化対象領域であると判断すれば、ストリームデータの暗号化は行なわない。
【００６８】
次に、アプリケーション部１０−１は、必要に応じて暗号化を行なったストリームデータをＡＴＡＰＩドライバ１９−１に供給し、ＡＴＡＰＩドライバ１９−１は、ＡＴＡＰＩｗｒｉｔｅコマンドを光ディスクドライブ部１９に供給する(ステップＳ８３)。光ディスクドライブ部１９では、ステップＳ６８で記憶しているＢＥフラグ設定ＬＢＡに基づき、ＢＥ対象ＬＢＡなら、そのセクタヘッダＳＨにフラグ情報Ｆをセットする。そして、光ディスクドライブ部１９は、供給された暗号化されたストリームデータのＢＥ復号を順次行い、復号されたストリームデータを所定のセクタに記録していく(ステップＳ８５)。
【００６９】
このようにして、配信サーバＳから供給されたＢＥ対応対象ＬＢＡの管理テーブル１４１を利用して、ＢＥ暗号化復号処理を暗号化対象領域のストリームデータに施すことにより、ストリームデータの安全性を低負荷な処理において実現するものである。
【００７０】
以上記載した様々な実施形態により、当業者は本発明を実現することができるが、更にこれらの実施形態の様々な変形例を思いつくことが当業者によって容易であり、発明的な能力をもたなくとも様々な実施形態へと適用することが可能である。従って、本発明は、開示された原理と新規な特徴に矛盾しない広範な範囲に及ぶものであり、上述した実施形態に限定されるものではない。
【図面の簡単な説明】
【００７１】
【図１】本発明の一実施形態に係る記録システムの構成の一例を示す説明図。
【図２】本発明の一実施形態に係る記録装置の構成の一例を示すブロック図。
【図３】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の一例を示す説明図。
【図４】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのデータ構造の一例を示す説明図。
【図５】本発明の一実施形態に係る記録装置のコンテンツの再生方法の一例を示すフローチャート。
【図６】本発明の一実施形態に係る記録装置が扱うＢＥ対応コンテンツのイメージ構造の他の一例を示す説明図。
【図７】本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャート。
【図８】本発明の一実施形態に係る記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャート。
【図９】本発明の一実施形態に係る記録システムが供給するＬＢＡ管理テーブルの一例を示す説明図。
【図１０】本発明の一実施形態に係る記録システムの記録方法の一例を示すフローチャート。
【図１１】本発明の一実施形態に係る記録システムの暗号復号処理を伴う記録方法の一例を示すフローチャート。
【符号の説明】
【００７２】
Ｄ…光ディスク、１０…ハードディスクレコーダ、１９…光ディスクドライバ、Ｓ…配信サーバ。
【特許請求の範囲】
【請求項１】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受ける受信部と、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部と、
を具備することを特徴とする記録装置。
【請求項２】
前記管理情報はＢＥフラグであることを特徴とする請求項１記載の記録装置。
【請求項３】
前記アドレス情報に基づき、前記ストリームのうちの前記暗号化対象領域のデータを暗号化してバスに供給する暗号化部と、
前記バスを介して前記暗号化データを受け、これを復号して前記記録部に供給する復号部を更に有することを特徴とする請求項１記載の記録装置。
【請求項４】
前記暗号化部は、前記ストリームをＡＡＣＳ規格のＢｕｓＥｎｃｒｙｐｔｉｏｎにより暗号化することを特徴とする請求項３記載の記録装置。
【請求項５】
前記アドレス情報は、ＬＢＡ管理テーブルであることを特徴とする請求項１記載の記録装置。
【請求項６】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受け、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録することを特徴とする記録方法。
【請求項７】
前記管理情報はＢＥフラグであることを特徴とする請求項６記載の記録方法。
【請求項８】
前記アドレス情報に基づき、前記ストリームの暗号化対象領域のデータを暗号化し、
バスを介して前記暗号化データを受け、これを復号して前記記録媒体のセクタに記録することを特徴とする請求項６記載の記録方法。
【請求項９】
前記暗号化処理は、前記ストリームをＡＡＣＳ規格のＢｕｓＥｎｃｒｙｐｔｉｏｎにより暗号化することを特徴とする請求項８記載の記録方法。
【請求項１０】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を通信路を介して外部装置に供給することを特徴とするサーバ装置。
【請求項１】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受ける受信部と、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録する記録部と、
を具備することを特徴とする記録装置。
【請求項２】
前記管理情報はＢＥフラグであることを特徴とする請求項１記載の記録装置。
【請求項３】
前記アドレス情報に基づき、前記ストリームのうちの前記暗号化対象領域のデータを暗号化してバスに供給する暗号化部と、
前記バスを介して前記暗号化データを受け、これを復号して前記記録部に供給する復号部を更に有することを特徴とする請求項１記載の記録装置。
【請求項４】
前記暗号化部は、前記ストリームをＡＡＣＳ規格のＢｕｓＥｎｃｒｙｐｔｉｏｎにより暗号化することを特徴とする請求項３記載の記録装置。
【請求項５】
前記アドレス情報は、ＬＢＡ管理テーブルであることを特徴とする請求項１記載の記録装置。
【請求項６】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を受け、
前記ストリームを記録媒体の各セクタに記録すると共に、前記暗号化対象領域のデータが記録されるセクタのセクタヘッダに管理情報を記録することを特徴とする記録方法。
【請求項７】
前記管理情報はＢＥフラグであることを特徴とする請求項６記載の記録方法。
【請求項８】
前記アドレス情報に基づき、前記ストリームの暗号化対象領域のデータを暗号化し、
バスを介して前記暗号化データを受け、これを復号して前記記録媒体のセクタに記録することを特徴とする請求項６記載の記録方法。
【請求項９】
前記暗号化処理は、前記ストリームをＡＡＣＳ規格のＢｕｓＥｎｃｒｙｐｔｉｏｎにより暗号化することを特徴とする請求項８記載の記録方法。
【請求項１０】
ストリームと、前記ストリームの暗号化対象領域を示すアドレス情報を通信路を介して外部装置に供給することを特徴とするサーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−５９４２０（Ｐ２００９−５９４２０Ａ）
【公開日】平成２１年３月１９日（２００９．３．１９）
【国際特許分類】
【出願番号】特願２００７−２２５８９１（Ｐ２００７−２２５８９１）
【出願日】平成１９年８月３１日（２００７．８．３１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２１年３月１９日（２００９．３．１９）
【国際特許分類】
【出願日】平成１９年８月３１日（２００７．８．３１）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]