情報記録再生装置
【課題】AACSにて不正ドライブとされる場合にも、AACSにて制限されることのない機能を効果的に実行し得る情報記録再生装置を提供する。
【解決手段】ドライブにディスク１００が装着されると、入出力制御部１０１と復号処理部１０２を介して、ディスク１００からDRLが読み出される。ＤＲＬ処理部１０４は、ドライブＩＤ格納部１０７に格納されている自己のDrive IDがDRL中に存在するかを判別し、存在すれば、その旨を判別するためのフラグ情報等からリボケーション情報を生成してリボケーション情報格納部１０８に格納する。リボケーション情報が格納されている場合、ホスト側からGET CONFIGURALIONを受信したことに応じて、CPPMに対応可能であるとの応答がホスト側に返される。これにより、ホスト側は、ドライブがAACSにおいて不正であるかを判別せず、ドライブとの間でCPPMによるプロトコル処理を確立する。
【解決手段】ドライブにディスク１００が装着されると、入出力制御部１０１と復号処理部１０２を介して、ディスク１００からDRLが読み出される。ＤＲＬ処理部１０４は、ドライブＩＤ格納部１０７に格納されている自己のDrive IDがDRL中に存在するかを判別し、存在すれば、その旨を判別するためのフラグ情報等からリボケーション情報を生成してリボケーション情報格納部１０８に格納する。リボケーション情報が格納されている場合、ホスト側からGET CONFIGURALIONを受信したことに応じて、CPPMに対応可能であるとの応答がホスト側に返される。これにより、ホスト側は、ドライブがAACSにおいて不正であるかを判別せず、ドライブとの間でCPPMによるプロトコル処理を確立する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、光ディスク等の記録メディアに対し情報の記録および／または再生を行う情報再生装置に関する。
【背景技術】
【０００２】
ＨＤ−ＤＶＤやＢｌｕ−ｒａｙディスク等の次世代光ディスクに記録されるデジタルコンテンツの管理技術としてAACS（Advanced Access Content System）が提案されている（非特許文献１）。また、主にパーソナルコンピュータがその周辺装置を制御することを目的とするパケットコマンドを用いながら、AACSプロトコルを実現するための規格化も進められている（非特許文献２）。
【０００３】
AACSでは、たとえば次世代光ディスク装置（ドライブ）によってディスクから読み出したデータをパーソナルコンピュータ（ホスト）等で再生するような場合に、ホスト側の正当性のみならずドライブ側の正当性も併せて検証が行われる。この検証は、ホスト−ドライブ間で暗号化通信路を確立する際に行われる。
【０００４】
かかる暗号化通信路の確立処理において、まず、ホストは、ドライブに対し、自身がAACSに対応しているか否かの問い合わせを発行する。この問い合わせに対する応答によって、ドライブがAACSに対応していることが確認されると、次に、ホストは、ドライブから識別ID（Drive ID）を取得し、このDrive IDが、不正ドライブを規定するDRL（Drive Revocation List）に存在しないかを判定する。そして、ドライブから取得したDrive IDがDRLに存在しなければ、当該ドライブは不正ドライブではないとして、ホスト−ドライブ間でDrive KeyやHost Key等の交換が行われ、ホスト−ドライブ間に暗号化通信路が確立される。
【０００５】
一方、ドライブから取得したDrive IDがDRLに存在する場合には、ホストは、当該ドライブは不正ドライブであるとし、以後の暗号化通信路の確立処理を中止する。
【非特許文献１】Advanced Access Content System(AACS) Introduction and Common Cryptographic Elements（Page 16-19, 30-34）
【非特許文献２】Mt. Fuji Commands for Multimedia Devices Version 6(INF8090 v6) (Page 407-410, 452, 639-643, 681,684-686)
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記処理によってドライブが不正ドライブであると判断されると、ホスト側では、当該ドライブとの通信を一切中止するとの処理が行われる可能性がある。
【０００７】
しかし、ディスクには、暗号化コンテンツの他に非暗号化コンテンツが記録されていることもあり、この場合に、上記のようにホスト側で一切の通信が拒否されると、本来再生が許されるべき非暗号化コンテンツの再生までが不可能になるとの不都合が生じる。また、ドライブには、CPPM（Content Protection for Prerecorded Media）機能等、AACS以外のコンテンツ保護機能が配備される場合があり、この場合に、上記のように一切の通信が拒否されると、通常はこの機能を用いた通信が可能であるにも拘わらず、この機能を用いた通信が拒否されるとの不都合も起こり得る。
【０００８】
この場合、使用者は、当該ドライブが不正ドライブであることを認識しない限り、これらの不都合の原因を知り得ない。この点、上記の処理では、ホスト側にて不正ドライブの判断が行われるため、ホストに不正ドライブであることを明示させることにより、使用者に不正ドライブの存在を知らしめることができる。しかし、上記では、暗号化通信路の確立処理過程の中で不正ドライブの判断が行われるため、この過程を踏まない限り、不正ドライブの判断は行われない。その一方、暗号化通信路の確立処理過程は、使用者からの指示によって任意に行われるものではなく、使用者からの指示とは別に、使用者の知り得ない状態にて、ホスト−ドライブ間で独自に行われる。このため、一般に、使用者からの指示により任意に不正ドライブの確認をホストに行わせることは困難である。
【０００９】
そこで、本発明は、AACSにて不正ドライブとされる場合にも、AACSにて制限されることのない機能を効果的に実行し得る情報記録再生装置を提供することを課題とする。また、AACSにて不正ドライブとされたことを使用者において簡易に認知し得る情報記録再生装置を提供することを課題とする。
【課題を解決するための手段】
【００１０】
上記課題に鑑み本発明は、それぞれ以下の特徴を有する。
【００１１】
請求項１の発明は、記録媒体に対し情報の記録および／または再生を行う情報記録再生装置において、通信先装置との間で情報の送受信を行う通信処理部と、第１の情報管理技術に従った情報処理を行う情報処理部と、前記第１の情報管理技術に基づいて自己の正当性を判断する判断処理部と、前記判断処理部にて自己が不正であると判断されたとき前記第１の情報管理技術による情報処理能力がないことを前記通信先装置に通知する通知処理部を有することを特徴とする。
【００１２】
本発明によれば、第１の情報処理技術（たとえば、AACS）において自己が不正ドライブであると判別されると、第１の情報管理技術による情報処理能力がないことが、当該情報記録再生装置から通信先装置（たとえば、ホスト）に通知される。この場合、この通知により当該情報記録再生装置には第１の情報管理技術による情報処理能力がないと確認されるため、通信先装置において、当該情報記録再生装置が第１の情報処理技術において正当であるかの認定処理がさらに行われることはない。よって、実際には当該情報記録再生装置が第１の情報処理技術において不正であっても、そのことを理由に、通信先装置が、当該情報記録再生装置との通信を一切拒否するといった事態も起こり得ない。
【００１３】
したがって、本発明によれば、記録媒体に非暗号化コンテンツが格納されている場合や、第１の情報管理技術（たとえば、AACS）以外の情報管理技術にて再生可能なコンテンツが格納されている場合にも、通信先装置（たとえば、ホスト）側にて、これらのコンテンツを記録媒体から読み出して再生するとの処理が採られ得る。
【００１４】
請求項２の発明は、請求項１に記載の情報記録再生装置において、前記通知処理部は、前記通信先装置から自己の情報処理能力を問い合わせるコマンドに対する応答に、前記第１の情報管理技術による情報処理能力がないことを示す情報を含めることを特徴とする。
【００１５】
この発明によれば、前記コマンドが通信先装置（たとえば、ホスト）から情報記録再生装置に対し使用者において任意に発行できるものであれば、このコマンドを適宜情報記録再生装置に発行することにより、使用者は、情報記録再生装置が第１の情報管理技術において不正とされるかを認知することができる。すなわち、このコマンドに対する応答の内容を参照することにより、使用者は、情報記録再生装置が不正ドライブであるかを知ることができる。
【００１６】
請求項３の発明は、請求項２に記載の情報記録再生装置において、前記通知処理部は、前記応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含めることを特徴とする。
【００１７】
この発明によれば、通信先装置（たとえば、ホスト）と当該情報記録再生装置との間に第２の情報管理技術（たとえば、CPPM等）による情報処理が確立され得る。よって、当該情報記録再生装置に配備された第２の情報管理技術が無駄となることが回避され得る。
【００１８】
請求項４の発明は、請求項３に記載の情報記録再生装置において、前記通知処理部は、前記第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べるために前記通信先装置から発行された前記コマンドに対する応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含めることを特徴とする。
【００１９】
この発明によれば、第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べる際に、第２の情報管理技術に従った情報処理能力を有することが通信先装置（たとえば、ホスト）に通知されるため、通信先装置において、第２の情報管理技術に従った情報処理の確立処理へと移行され易くなる。
【００２０】
請求項５の発明は、請求項１ないし４の何れか一項に記載の情報記録再生装置において、自己を識別するための識別情報を格納するＩＤ格納部をさらに備え、前記判断処理部は、当該情報記録再生装置に装着された記録媒体から前記第１の情報管理技術において不正とされる情報記録再生装置を規定する識別情報を取得し、取得した識別情報の中に、前記ＩＤ格納部に格納されている自己の識別情報が含まれているときに、前記第１の情報管理技術において自己が不正であると判断することを特徴とする。
【００２１】
この発明によれば、自己が第１の情報管理技術において不正であることを円滑に判別することができる。
【００２２】
請求項６の発明は、請求項１ないし４の何れか一項に記載の情報記録再生装置において、前記判断処理部にて不正であると判断されたことを報知する報知手段をさらに有することを特徴とする。
【００２３】
この発明によれば、たとえば、ＬＥＤやスピーカ等の報知手段によって、情報記録再生装置から使用者に直接、自己が不正ドライブであることが報知されるため、通信先装置からコマンドを発行する必要が無く、不正ドライブの確認を簡便化することができる。
【００２４】
なお、上記発明における「通信処理部」は、以下の実施形態において、パケットコマンド処理部１０６にて具現化されている。また、上記発明における「情報処理部」は、以下の実施形態において、ＡＡＣＳプロトコル処理部１０５にて具現化されている。また、上記発明における「判断処理部」は、以下の実施形態において、ＤＲＬ処理部１０４およびリボケーション情報格納部１０８にて具現化されている。また、上記発明における「通知処理部」は、以下の実施形態において、パケットコマンド処理部１０６にて具現化されている。また、上記発明における「ＩＤ格納部」は、以下の実施形態において、ドライブＩＤ部１０７にて具現化されている。また、上記発明における「報知手段」は、以下の実施形態において、ドライブに配されたＬＥＤ等の表示手段にて具現化されている。
【００２５】
ただし、以下の実施形態は、本発明の技術的範囲を何ら制限するものではない。
【発明の効果】
【００２６】
上記の如く、本発明によれば、情報記録再生装置の使用価値を高めながら、同時に、情報記録再生装置が第１の情報管理技術において不正であることを使用者において簡易に認知することができる。
【００２７】
本発明の特徴ないし意義は、以下に示す実施の形態の説明により更に明らかとなろう。ただし、以下の実施形態は、あくまでも、例示であって、本発明ないし各構成要件の用語の意義は、以下の実施の形態に記載されたものに制限されるものではない。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の実施の形態について説明する。なお、本実施の形態は、次世代光ディスクに情報を記録再生する情報記録再生装置に本発明を適用したものである。
【００２９】
図１は、情報記録再生装置（ドライブ）の全体横成を示す図である。
【００３０】
図示の如く、ドライブは、入出力処理部１０１と、復号処理部１０２と、符号処理部１０３と、ＤＲＬ処理部１０４と、ＡＣＣＳプロトコル処理部１０５と、パケットコマンド処理部１０６と、ドライブＩＤ格納部１０７と、リボケーション情報格納部１０８と、制御部１０９を備えている。
【００３１】
入出力処理部１０１は、ディスク１００にアクセスして情報の記録・再生を行う。入出力処理部１０１は、光ピックアップおよびそのドライブ機構を備えている。また、光ピックアップのアクセス制御やレーザ光の発光制御等を行うサーボ回路を備えている。
【００３２】
復号処理部１０２は、入出力処理部１０１を介してディスク１００から読み出した信号に、デジタル復調および誤り訂正復号等を施し、コンテンツを復号する。符号処理部１０３は、記録対象のコンテンツにデジタル復調および誤り訂正符号化等の符号化処理を施して記録信号を生成する。
【００３３】
ＤＲＬ処理部１０４は、ディスク１００から読み出したDRLの正当性を検証するとともに、DRLを解析して不正ドライブの識別IDを抽出する。また、抽出した識別IDの中に自己のDrive ID（ドライブＩＤ格納部１０７に格納）が含まれている場合に、その旨を示すリボケーション情報を生成し、リボケーション情報格納部１０８に格納させる。なお、リボケーション情報の生成は、追って図４を参照して説明する。
【００３４】
ＡＡＣＳプロトコル処理部１０５は、ＡＡＣＳプロトコルにおいてドライブ側で必要な処理を行う。
【００３５】
パケットコマンド処理部１０６は、ホスト等との間でパケットコマンドを送受するとともに、受信したパケットの解析等の処理を行う。
【００３６】
ドライブＩＤ格納部１０７は、自己の識別ＩＤであるDrive IDを保持している。具体的には、ドライブＩＤ格納部１０７には、Drive Certificationが格納されており、このDrive Certification中にDrive IDが記述されている。この他、Drive Certificationには、自身の正当性を検証するための電子署名が記述されている。
【００３７】
リボケーション情報格納部１０８は、ＤＲＬ処理部１０４にて生成されたリボケーション情報を格納する。 制御部１０９は、ドライブ全体の処理を制御する。
【００３８】
図２は、HRL（Host Revocation List）とDRL（Drive Revocation List）の構造を示す図である。なお、HRLには、秘密裏に保管しておくべき情報（たとえば秘密鍵）が露呈した不正ホストの識別IDが記載されている。また、DRLには、秘密裏に保管しておくべき情報（たとえば秘密鍵）が露呈した不正ドライブの識別IDが記載されている。なお、HRLおよびDRLには上記以外の情報も記載されているが、本発明に直接関係ないため、ここでは説明を割愛する。これらHRLとDRLは、ディスク製造時にディスク１００の所定のエリアに記録される。
【００３９】
図示の如く、HRLは、“Record Type”と、“Record Length"と、“Total Number of Entries”と、“Number of Entries in this Block i"と、“Host Revocation List Entries(j)”と、“Signature for Block i"から構成されている。
【００４０】
この内、“Record Type”には、HRLの識別コードが格納される。また、“Record Length"は、“Total Number of Entries”以降に格納されるデータのデータ長が格納されている。“Total Number of Entries”は、当該HRLに格納されている“Host Revocation List Entries(j)”の総数である。“Number of Entries in this Block i"は、当該Block i 中に含まれる“Host Revocation List Entries(j)”の個数である。“Host Revocation List Entries(j)”には、不正ホストの識別IDが格納されている。“Signature for Block i"は、当該Block i 中に含まれる“Host Revocation List Entries(j)”の正当性を検証するための電子署名が記述されている。
【００４１】
同様に、DRLは、“Record Type”と、“Record Length"と、“Total Number of Entries”と、“Number of Entries in this Block i"と、“Drive Revocation List Entries(j)”と、“Signature for Block i"から構成されている。
【００４２】
この内、“Record Type”には、DRLの識別コードが格納される。また、“Record Length"は、“Total Number of Entries”以降に格納されるデータのデータ長が格納されている。“Total Number of Entries”は、当該DRLに格納されている“Drive Revocation List Entries(j)”の総数である。“Number of Entries in this Block i"は、当該Block i 中に含まれる“Drive Revocation List Entries(j)”の個数である。“Drive Revocation List Entries(j)”には、不正ドライブの識別IDが格納されている。“Signature for Block i"は、当該Block i 中に含まれる“Drive Revocation List Entries(j)”の正当性を検証するための電子署名が記述されている。
【００４３】
１．暗号化通信路の確立処理（通常の処理）
次に、図３を参照して、AACSにおける通常の暗号化通信路の確立処理について説明する。なお、図３に示す処理は、ドライブが不正ドライブではないときの処理の流れを示している。また、このドライブは、AACSに対応する通信機能の他、CCPM等の他の通信機能を備えている。当該他の通信機能に従うプロトコル処理部は、図１において図示省略されている。
【００４４】
まず、ホストは、ドライブにパケットコマンド（GET CONFIGURATION）を発行し、ドライブがAACSに対応しているか否か等、ドライブがどのような機能を備えているか調査を行う（Ｓ１）。
【００４５】
ドライブは、GET CONFIGURATIONを受信すると、ＡＡＣＳプロトコル処理部１０５にて、AACS Feature Descriptorを作成し、自己の機能を示す他のFeature Descriptorと共にHostに送信する（Ｓ２）。なお、この処理の際、ドライブは、後述の如く、自己が不正ドライブでないかを判別する。そして、不正ドライブでないと判別したときに、上記のように、AACS Feature Descriptorを作成し、自己の機能を示す他のFeature Descriptorと共にHostに送信する（Ｓ２）。
【００４６】
ホストは、この応答にAACS Feature Descriptorが含まれているかを確認し、AACS Feature Descriptorが含まれている場合に、当該ドライブがAACS対応であると判断する。また、ドライブ側のディスク１００からDRLを読み出す。
【００４７】
さらに、ホストは、ドライブにパケットコマンド（REPORT KEY）を発行し、AACSプロトコルセッションの識別IDであるAuthentication Grand IDを要求する（Ｓ３）。
【００４８】
ドライブは、REPORT KEYを受信すると、ＡＡＣＳプロトコル処理部１０５に格納されているAuthentication Grand IDをもとに、パケットコマンド処理部１０６にて、REPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ４）。
【００４９】
ホストは、公開鍵およびそのライセンサによる署名文を含むHost Certification等からSEND KEY Parameter Listを作成し、ドライブにパケットコマンド（SEND KEY）を発行する（Ｓ５）。
【００５０】
ドライブは、SEND KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Host Certificationの正当性を検証する。また、ディスク１００からHRLを読み出し、検証したHost Certificationに記載されたホストIDがHRLに存在しないことを確認する（Ｓ６）。なお、ドライブは、この処理の際に、HRLの正当性をも検証する。この検証は、HRLの正当性を検証するために予めライセンサから配布された検証用公開鍵を用いて所定の演算を行うことにより行われる。
【００５１】
次いで、ホストは、パケットコマンド（REPORT KEY）を発行し、公開鍵およびそのライセンサによる署名文を含むDrive Certificationをドライブに要求する（Ｓ７）。
【００５２】
ドライブは、REPORT KEYを受信すると、ドライブＩＤ格納部１０７に格納されているDrive Certification等からREPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ８）。
【００５３】
ホストは、REPORT KEY Data Format を受信すると、Drive Certificationの正当性を検証する。また、検証したDrive Certificationに記載されたDrive IDがDRLに存在しないことを確認する（Ｓ９）。なお、ホストは、この処理の際に、DRLの正当性をも検証する。この検証は、DRLの正当性を検証するために予めライセンサから配布された検証用公開鍵を用いて所定の演算を行うことにより行われる。
【００５４】
さらに、ホストは、パケットコマンド（REPORT KEY）を発行し、共通鍵を生成するためのセッション鍵であるDrive KEYをドライブに要求する（Ｓ１０）。
【００５５】
ドライブは、REPORT KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Drive Keyおよびその署名文を生成する。また、これらDrive Key等から、パケットコマンド処理部１０６にて、REPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ１１）。
【００５６】
ホストは、Drive CertificationのDrive公開鍵によりDrive Keyの正当性を検証する。そして、所定の演算により、共通鍵を生成するためのセッション鍵であるHost Keyおよびその署名文を生成する（Ｓ１２）。また、Host KeyとDrive Keyより、共通鍵であるBus Keyを所定の演算により生成する（Ｓ１３）。
【００５７】
次に、ホストは、Host Key等からSEND KEY Parameter Listを作成し、ドライブにパケットコマンド（SEND KEY）を発行する（Ｓ１４）。
【００５８】
ドライブは、SEND KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Host Keyを用いながら共通鍵であるBus Keyを所定の演算により生成する（Ｓ１５）。
【００５９】
以上の手順により、ホストとドライブは、相互の認証を行いながら、共通鍵であるBus Keyを共有する。これにより、ホストとドライブの間に暗号化通信路が確立される。
【００６０】
２．コンテンツの記録再生処理
以上のようにして暗号化通信路が確立されると、次に、ホストは、暗号化通信路を介して、セキュア情報をディスク１００から読み出す。そして、読み出したセキュア情報に所定の演算を施してコンテンツの暗号鍵を取得する。
【００６１】
ディスク１００からコンテンツを再生する場合、ホストはドライブにパケットコマンド（READ）を発行する。ドライブは、READを受信すると、ディスク１００から入出力処理部１０１を介してコンテンツデータを読み出し、これを復号処理部１０２にて復号する。そして、復号したコンテンツデータを、パケットコマンド処理部１０６を介してホストに送信する。
【００６２】
ホストは、ドライブから受信したコンテンツデータを、上記セキュア情報から取得した暗号鍵にて復号する。そして、復号したコンテンツデータに再生処理を施し、モニターやスピーカ等の出力手段から出力する。
【００６３】
ディスク１００にコンテンツデータを記録する場合、ホストは、コンテンツデータを上記暗号鍵で暗号化し、ドライブにパケットコマンド（WRITE）を発行する。ドライブは、WRITEを受信すると、パケットコマンド処理部１０６を介してコンテンツデータを受信し、受信したコンテンツデータに対して、符号化処理部１０３にて、デジタル変調および誤り訂正符号化等の符号化処理を施す。そして、符号化後のコンテンツデータを、入出力制御部１０１を介してディスク１００に記録する。
【００６４】
３．リボケーション情報の生成処理
次に、図４を参照して、リボケーション情報の生成処理について説明する。
【００６５】
ドライブにディスク１００が装着されると、入出力制御部１０１と復号処理部１０２を介して、ディスク１００からDRLが読み出され、これがＤＲＬ処理部１０４に送られる（Ｓ１０１）。ＤＲＬ処理部１０４は、まず、図２に示す“Signature for Block i"を用いて、受け取ったDRLの正当性を検証する（Ｓ１０２）。
【００６６】
なお、DRLの正当性の検証は、図３のＳ４にて行われるHRLの正当性の検証と同様の演算処理にて行われる。すなわち、ドライブは、HRLの正当性の検証のため予めライセンサから配布された検証用公開鍵を用いてDRLの検証を行うことができる。
【００６７】
DRLが正当でない場合（S１０３：Ｎ）、リボケーション情報の生成処理は中止される。DRLが正当である場合（Ｓ１０３：Ｙ）、ＤＲＬ処理部１０４は、当該DRLを解析して、当該DRL中に記述されたDrive Revocation List Entriesを順次参照する（Ｓ１０４）。そして、ドライブＩＤ格納部１０７に格納されている自己のDrive IDがDRL中に存在するかを判別する（Ｓ１０５）。
【００６８】
ここで、自己のDrive IDがDRL中に存在しなければ（Ｓ１０５：Ｎ）、リボケーション情報の生成処理は中止される。一方、自己のDrive IDがDRL中に存在する場合（Ｓ１０５：Ｙ）、ＤＲＬ処理部１０４は、その旨を判別するためのフラグ情報やDRLのバージョン情報（図２には図示省略）等から構成されるリボケーション情報を生成し、これをリボケーション情報格納部１０８に格納する（Ｓ１０６）。
【００６９】
４．ホストからGET CONFIGURATIONを受信したときの処理
次に、ホストからGET CONFIGURATIONを受信したときにドライブにて行われる処理について、図５を参照して説明する。
【００７０】
ホストからパケットコマンド（GET CONFIGURATION）を受信すると（S２１０:Ｙ）、パケットコマンド処理部１０６は、リボケーション情報格納部１０８にリボケーション情報が格納されているかを判別する（Ｓ２０２）。ここで、リボケーション情報が格納されていなければ（Ｓ２０２：Ｎ）、上記図３のＳ２にて説明したとおり、AACS Feature Descriptorが作成され（Ｓ２０３）、さらに、自己の機能を示す他のFeature Descriptorが生成されて（Ｓ２０４）、これらがHostに送信される（Ｓ２０５）。
【００７１】
一方、リボケーション情報格納部１０８にリボケーション情報が格納されている場合、すなわち、自己が不正ドライブである場合（Ｓ２０２：Ｙ）には、AACS Feature Descriptorの作成処理（Ｓ２０３）がスキップされ、自己の機能を示す他のFeature Descriptorが生成される（Ｓ２０４）。そして、他のFeature Descriptorのみがホストに送信される（Ｓ２０５）。
【００７２】
図５に示す処理は、上記図３の暗号化通信路の確立処理のＳ１にて、ドライブがホストからパケットコマンド（GET CONFIGURATION）を受信した場合の他、使用者が、ホストを介してドライブに、任意にパケットコマンド（GET CONFIGURATION）を発行した場合にも行われる。
【００７３】
このうち、暗号化通信路の確立処理にてドライブがホストからパケットコマンド（GET CONFIGURATION）を受信した場合（図３のＳ１）には、以下の処理が行われる。
【００７４】
すなわち、Ｓ２０５にて、AACS Feature Descriptorと他のFeature Descriptorがホスト側に送信された場合（当該ドライブが不正ドライブである場合）には、上記図３に示すＳ３以降の処理が行われる。
【００７５】
一方、Ｓ２０５にて、他のFeature Descriptorのみがホスト側に送信された場合（当該ドライブが不正ドライブである場合）には、ドライブからのレスポンスにAACS Feature Descriptorが含まれていないため、ホストは、当該ドライブをAACSに対応できないものと判定し、上記図３のＳ３以降の処理を中止する。この場合、当該ドライブに対する正当性の認証処理がホストにおいて行われることはない。したがって、ホストは、当該ドライブを不正ドライブとして認識せず、単に、AACSに対応できないドライブとして判定する。
【００７６】
この場合、ホスト側において、当該ドライブとの通信を一切拒否するとの処理が取られることはない。よって、ディスク１００に非暗号化コンテンツが格納されている場合や、AACS以外のコンテンツ保護機能にて再生可能なコンテンツが格納されている場合にも、ホスト側において、これらのコンテンツをディスク１００から読み出して再生するとの処理が採られ得る。
【００７７】
さらに、パケットコマンド（GET CONFIGURATION）は、暗号化通信路の確立処理の他、使用者において、ホストからドライブに任意に発行し得るコマンドであるから、使用者は、適宜、このコマンドをドライブに発行してそのレスポンスの内容を確認することにより、通信先ドライブが不正ドライブであるかを知ることができる。すなわち、通信先ドライブがAACS対応ドライブであるにも係らず、GET CONFIGURATIONのレスポンスにAACS Feature Descriptorが含まれていなければ、当該ドライブを不正ドライブとして認識することができる。
【００７８】
このように、本実施の形態によれば、不正ドライブの使用価値を高めながら、同時に、通信先ドライブが不正ドライブであることを使用者において簡易に認知することができる。なお、本実施の形態においても、AACSによって保護されたコンテンツが不正ドライブによってディスクから読み出されることはなく、AACSによるコンテンツの保護機能は高く維持される。
【００７９】
以上、本発明の実施の形態について説明したが、本発明は、上記実施の形態に限定されるものではない。
【００８０】
たとえば、上記実施の形態では、パケットコマンド（GET CONFIGURATION）に対する応答内容から、使用者において、通信先ドライブが不正ドライブであることを認知できるようにしたが、この他、ドライブにＬＥＤ等の表示手段を設け、これにより、ユーザに不正ドライブであることを直接報知するようにすることもできる。
【００８１】
本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。
【図面の簡単な説明】
【００８２】
【図１】実施の形態に係る情報記録再生装置（ドライブ）の構成を示す図
【図２】実施の形態に係るＨＲＬとＤＲＬのデータ構造を示す図
【図３】実施の形態に係る暗号化通信路確立の際の流れを説明する図
【図４】実施の形態に係るリボケーション情報生成時の処理フローチャート
【図５】実施の形態に係るパケットコマンド（GET CONFIGURATION）受信時の処理フローチャート
【符号の説明】
【００８３】
１０４ ＤＲＬ処理部
１０５ ＡＡＣＳプロトコル処理部
１０６ パケットコマンド処理部
１０７ ドライブＩＤ格納部
１０８ リボケーション情報格納部
１０９ 制御部
【技術分野】
【０００１】
本発明は、光ディスク等の記録メディアに対し情報の記録および／または再生を行う情報再生装置に関する。
【背景技術】
【０００２】
ＨＤ−ＤＶＤやＢｌｕ−ｒａｙディスク等の次世代光ディスクに記録されるデジタルコンテンツの管理技術としてAACS（Advanced Access Content System）が提案されている（非特許文献１）。また、主にパーソナルコンピュータがその周辺装置を制御することを目的とするパケットコマンドを用いながら、AACSプロトコルを実現するための規格化も進められている（非特許文献２）。
【０００３】
AACSでは、たとえば次世代光ディスク装置（ドライブ）によってディスクから読み出したデータをパーソナルコンピュータ（ホスト）等で再生するような場合に、ホスト側の正当性のみならずドライブ側の正当性も併せて検証が行われる。この検証は、ホスト−ドライブ間で暗号化通信路を確立する際に行われる。
【０００４】
かかる暗号化通信路の確立処理において、まず、ホストは、ドライブに対し、自身がAACSに対応しているか否かの問い合わせを発行する。この問い合わせに対する応答によって、ドライブがAACSに対応していることが確認されると、次に、ホストは、ドライブから識別ID（Drive ID）を取得し、このDrive IDが、不正ドライブを規定するDRL（Drive Revocation List）に存在しないかを判定する。そして、ドライブから取得したDrive IDがDRLに存在しなければ、当該ドライブは不正ドライブではないとして、ホスト−ドライブ間でDrive KeyやHost Key等の交換が行われ、ホスト−ドライブ間に暗号化通信路が確立される。
【０００５】
一方、ドライブから取得したDrive IDがDRLに存在する場合には、ホストは、当該ドライブは不正ドライブであるとし、以後の暗号化通信路の確立処理を中止する。
【非特許文献１】Advanced Access Content System(AACS) Introduction and Common Cryptographic Elements（Page 16-19, 30-34）
【非特許文献２】Mt. Fuji Commands for Multimedia Devices Version 6(INF8090 v6) (Page 407-410, 452, 639-643, 681,684-686)
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記処理によってドライブが不正ドライブであると判断されると、ホスト側では、当該ドライブとの通信を一切中止するとの処理が行われる可能性がある。
【０００７】
しかし、ディスクには、暗号化コンテンツの他に非暗号化コンテンツが記録されていることもあり、この場合に、上記のようにホスト側で一切の通信が拒否されると、本来再生が許されるべき非暗号化コンテンツの再生までが不可能になるとの不都合が生じる。また、ドライブには、CPPM（Content Protection for Prerecorded Media）機能等、AACS以外のコンテンツ保護機能が配備される場合があり、この場合に、上記のように一切の通信が拒否されると、通常はこの機能を用いた通信が可能であるにも拘わらず、この機能を用いた通信が拒否されるとの不都合も起こり得る。
【０００８】
この場合、使用者は、当該ドライブが不正ドライブであることを認識しない限り、これらの不都合の原因を知り得ない。この点、上記の処理では、ホスト側にて不正ドライブの判断が行われるため、ホストに不正ドライブであることを明示させることにより、使用者に不正ドライブの存在を知らしめることができる。しかし、上記では、暗号化通信路の確立処理過程の中で不正ドライブの判断が行われるため、この過程を踏まない限り、不正ドライブの判断は行われない。その一方、暗号化通信路の確立処理過程は、使用者からの指示によって任意に行われるものではなく、使用者からの指示とは別に、使用者の知り得ない状態にて、ホスト−ドライブ間で独自に行われる。このため、一般に、使用者からの指示により任意に不正ドライブの確認をホストに行わせることは困難である。
【０００９】
そこで、本発明は、AACSにて不正ドライブとされる場合にも、AACSにて制限されることのない機能を効果的に実行し得る情報記録再生装置を提供することを課題とする。また、AACSにて不正ドライブとされたことを使用者において簡易に認知し得る情報記録再生装置を提供することを課題とする。
【課題を解決するための手段】
【００１０】
上記課題に鑑み本発明は、それぞれ以下の特徴を有する。
【００１１】
請求項１の発明は、記録媒体に対し情報の記録および／または再生を行う情報記録再生装置において、通信先装置との間で情報の送受信を行う通信処理部と、第１の情報管理技術に従った情報処理を行う情報処理部と、前記第１の情報管理技術に基づいて自己の正当性を判断する判断処理部と、前記判断処理部にて自己が不正であると判断されたとき前記第１の情報管理技術による情報処理能力がないことを前記通信先装置に通知する通知処理部を有することを特徴とする。
【００１２】
本発明によれば、第１の情報処理技術（たとえば、AACS）において自己が不正ドライブであると判別されると、第１の情報管理技術による情報処理能力がないことが、当該情報記録再生装置から通信先装置（たとえば、ホスト）に通知される。この場合、この通知により当該情報記録再生装置には第１の情報管理技術による情報処理能力がないと確認されるため、通信先装置において、当該情報記録再生装置が第１の情報処理技術において正当であるかの認定処理がさらに行われることはない。よって、実際には当該情報記録再生装置が第１の情報処理技術において不正であっても、そのことを理由に、通信先装置が、当該情報記録再生装置との通信を一切拒否するといった事態も起こり得ない。
【００１３】
したがって、本発明によれば、記録媒体に非暗号化コンテンツが格納されている場合や、第１の情報管理技術（たとえば、AACS）以外の情報管理技術にて再生可能なコンテンツが格納されている場合にも、通信先装置（たとえば、ホスト）側にて、これらのコンテンツを記録媒体から読み出して再生するとの処理が採られ得る。
【００１４】
請求項２の発明は、請求項１に記載の情報記録再生装置において、前記通知処理部は、前記通信先装置から自己の情報処理能力を問い合わせるコマンドに対する応答に、前記第１の情報管理技術による情報処理能力がないことを示す情報を含めることを特徴とする。
【００１５】
この発明によれば、前記コマンドが通信先装置（たとえば、ホスト）から情報記録再生装置に対し使用者において任意に発行できるものであれば、このコマンドを適宜情報記録再生装置に発行することにより、使用者は、情報記録再生装置が第１の情報管理技術において不正とされるかを認知することができる。すなわち、このコマンドに対する応答の内容を参照することにより、使用者は、情報記録再生装置が不正ドライブであるかを知ることができる。
【００１６】
請求項３の発明は、請求項２に記載の情報記録再生装置において、前記通知処理部は、前記応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含めることを特徴とする。
【００１７】
この発明によれば、通信先装置（たとえば、ホスト）と当該情報記録再生装置との間に第２の情報管理技術（たとえば、CPPM等）による情報処理が確立され得る。よって、当該情報記録再生装置に配備された第２の情報管理技術が無駄となることが回避され得る。
【００１８】
請求項４の発明は、請求項３に記載の情報記録再生装置において、前記通知処理部は、前記第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べるために前記通信先装置から発行された前記コマンドに対する応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含めることを特徴とする。
【００１９】
この発明によれば、第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べる際に、第２の情報管理技術に従った情報処理能力を有することが通信先装置（たとえば、ホスト）に通知されるため、通信先装置において、第２の情報管理技術に従った情報処理の確立処理へと移行され易くなる。
【００２０】
請求項５の発明は、請求項１ないし４の何れか一項に記載の情報記録再生装置において、自己を識別するための識別情報を格納するＩＤ格納部をさらに備え、前記判断処理部は、当該情報記録再生装置に装着された記録媒体から前記第１の情報管理技術において不正とされる情報記録再生装置を規定する識別情報を取得し、取得した識別情報の中に、前記ＩＤ格納部に格納されている自己の識別情報が含まれているときに、前記第１の情報管理技術において自己が不正であると判断することを特徴とする。
【００２１】
この発明によれば、自己が第１の情報管理技術において不正であることを円滑に判別することができる。
【００２２】
請求項６の発明は、請求項１ないし４の何れか一項に記載の情報記録再生装置において、前記判断処理部にて不正であると判断されたことを報知する報知手段をさらに有することを特徴とする。
【００２３】
この発明によれば、たとえば、ＬＥＤやスピーカ等の報知手段によって、情報記録再生装置から使用者に直接、自己が不正ドライブであることが報知されるため、通信先装置からコマンドを発行する必要が無く、不正ドライブの確認を簡便化することができる。
【００２４】
なお、上記発明における「通信処理部」は、以下の実施形態において、パケットコマンド処理部１０６にて具現化されている。また、上記発明における「情報処理部」は、以下の実施形態において、ＡＡＣＳプロトコル処理部１０５にて具現化されている。また、上記発明における「判断処理部」は、以下の実施形態において、ＤＲＬ処理部１０４およびリボケーション情報格納部１０８にて具現化されている。また、上記発明における「通知処理部」は、以下の実施形態において、パケットコマンド処理部１０６にて具現化されている。また、上記発明における「ＩＤ格納部」は、以下の実施形態において、ドライブＩＤ部１０７にて具現化されている。また、上記発明における「報知手段」は、以下の実施形態において、ドライブに配されたＬＥＤ等の表示手段にて具現化されている。
【００２５】
ただし、以下の実施形態は、本発明の技術的範囲を何ら制限するものではない。
【発明の効果】
【００２６】
上記の如く、本発明によれば、情報記録再生装置の使用価値を高めながら、同時に、情報記録再生装置が第１の情報管理技術において不正であることを使用者において簡易に認知することができる。
【００２７】
本発明の特徴ないし意義は、以下に示す実施の形態の説明により更に明らかとなろう。ただし、以下の実施形態は、あくまでも、例示であって、本発明ないし各構成要件の用語の意義は、以下の実施の形態に記載されたものに制限されるものではない。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の実施の形態について説明する。なお、本実施の形態は、次世代光ディスクに情報を記録再生する情報記録再生装置に本発明を適用したものである。
【００２９】
図１は、情報記録再生装置（ドライブ）の全体横成を示す図である。
【００３０】
図示の如く、ドライブは、入出力処理部１０１と、復号処理部１０２と、符号処理部１０３と、ＤＲＬ処理部１０４と、ＡＣＣＳプロトコル処理部１０５と、パケットコマンド処理部１０６と、ドライブＩＤ格納部１０７と、リボケーション情報格納部１０８と、制御部１０９を備えている。
【００３１】
入出力処理部１０１は、ディスク１００にアクセスして情報の記録・再生を行う。入出力処理部１０１は、光ピックアップおよびそのドライブ機構を備えている。また、光ピックアップのアクセス制御やレーザ光の発光制御等を行うサーボ回路を備えている。
【００３２】
復号処理部１０２は、入出力処理部１０１を介してディスク１００から読み出した信号に、デジタル復調および誤り訂正復号等を施し、コンテンツを復号する。符号処理部１０３は、記録対象のコンテンツにデジタル復調および誤り訂正符号化等の符号化処理を施して記録信号を生成する。
【００３３】
ＤＲＬ処理部１０４は、ディスク１００から読み出したDRLの正当性を検証するとともに、DRLを解析して不正ドライブの識別IDを抽出する。また、抽出した識別IDの中に自己のDrive ID（ドライブＩＤ格納部１０７に格納）が含まれている場合に、その旨を示すリボケーション情報を生成し、リボケーション情報格納部１０８に格納させる。なお、リボケーション情報の生成は、追って図４を参照して説明する。
【００３４】
ＡＡＣＳプロトコル処理部１０５は、ＡＡＣＳプロトコルにおいてドライブ側で必要な処理を行う。
【００３５】
パケットコマンド処理部１０６は、ホスト等との間でパケットコマンドを送受するとともに、受信したパケットの解析等の処理を行う。
【００３６】
ドライブＩＤ格納部１０７は、自己の識別ＩＤであるDrive IDを保持している。具体的には、ドライブＩＤ格納部１０７には、Drive Certificationが格納されており、このDrive Certification中にDrive IDが記述されている。この他、Drive Certificationには、自身の正当性を検証するための電子署名が記述されている。
【００３７】
リボケーション情報格納部１０８は、ＤＲＬ処理部１０４にて生成されたリボケーション情報を格納する。 制御部１０９は、ドライブ全体の処理を制御する。
【００３８】
図２は、HRL（Host Revocation List）とDRL（Drive Revocation List）の構造を示す図である。なお、HRLには、秘密裏に保管しておくべき情報（たとえば秘密鍵）が露呈した不正ホストの識別IDが記載されている。また、DRLには、秘密裏に保管しておくべき情報（たとえば秘密鍵）が露呈した不正ドライブの識別IDが記載されている。なお、HRLおよびDRLには上記以外の情報も記載されているが、本発明に直接関係ないため、ここでは説明を割愛する。これらHRLとDRLは、ディスク製造時にディスク１００の所定のエリアに記録される。
【００３９】
図示の如く、HRLは、“Record Type”と、“Record Length"と、“Total Number of Entries”と、“Number of Entries in this Block i"と、“Host Revocation List Entries(j)”と、“Signature for Block i"から構成されている。
【００４０】
この内、“Record Type”には、HRLの識別コードが格納される。また、“Record Length"は、“Total Number of Entries”以降に格納されるデータのデータ長が格納されている。“Total Number of Entries”は、当該HRLに格納されている“Host Revocation List Entries(j)”の総数である。“Number of Entries in this Block i"は、当該Block i 中に含まれる“Host Revocation List Entries(j)”の個数である。“Host Revocation List Entries(j)”には、不正ホストの識別IDが格納されている。“Signature for Block i"は、当該Block i 中に含まれる“Host Revocation List Entries(j)”の正当性を検証するための電子署名が記述されている。
【００４１】
同様に、DRLは、“Record Type”と、“Record Length"と、“Total Number of Entries”と、“Number of Entries in this Block i"と、“Drive Revocation List Entries(j)”と、“Signature for Block i"から構成されている。
【００４２】
この内、“Record Type”には、DRLの識別コードが格納される。また、“Record Length"は、“Total Number of Entries”以降に格納されるデータのデータ長が格納されている。“Total Number of Entries”は、当該DRLに格納されている“Drive Revocation List Entries(j)”の総数である。“Number of Entries in this Block i"は、当該Block i 中に含まれる“Drive Revocation List Entries(j)”の個数である。“Drive Revocation List Entries(j)”には、不正ドライブの識別IDが格納されている。“Signature for Block i"は、当該Block i 中に含まれる“Drive Revocation List Entries(j)”の正当性を検証するための電子署名が記述されている。
【００４３】
１．暗号化通信路の確立処理（通常の処理）
次に、図３を参照して、AACSにおける通常の暗号化通信路の確立処理について説明する。なお、図３に示す処理は、ドライブが不正ドライブではないときの処理の流れを示している。また、このドライブは、AACSに対応する通信機能の他、CCPM等の他の通信機能を備えている。当該他の通信機能に従うプロトコル処理部は、図１において図示省略されている。
【００４４】
まず、ホストは、ドライブにパケットコマンド（GET CONFIGURATION）を発行し、ドライブがAACSに対応しているか否か等、ドライブがどのような機能を備えているか調査を行う（Ｓ１）。
【００４５】
ドライブは、GET CONFIGURATIONを受信すると、ＡＡＣＳプロトコル処理部１０５にて、AACS Feature Descriptorを作成し、自己の機能を示す他のFeature Descriptorと共にHostに送信する（Ｓ２）。なお、この処理の際、ドライブは、後述の如く、自己が不正ドライブでないかを判別する。そして、不正ドライブでないと判別したときに、上記のように、AACS Feature Descriptorを作成し、自己の機能を示す他のFeature Descriptorと共にHostに送信する（Ｓ２）。
【００４６】
ホストは、この応答にAACS Feature Descriptorが含まれているかを確認し、AACS Feature Descriptorが含まれている場合に、当該ドライブがAACS対応であると判断する。また、ドライブ側のディスク１００からDRLを読み出す。
【００４７】
さらに、ホストは、ドライブにパケットコマンド（REPORT KEY）を発行し、AACSプロトコルセッションの識別IDであるAuthentication Grand IDを要求する（Ｓ３）。
【００４８】
ドライブは、REPORT KEYを受信すると、ＡＡＣＳプロトコル処理部１０５に格納されているAuthentication Grand IDをもとに、パケットコマンド処理部１０６にて、REPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ４）。
【００４９】
ホストは、公開鍵およびそのライセンサによる署名文を含むHost Certification等からSEND KEY Parameter Listを作成し、ドライブにパケットコマンド（SEND KEY）を発行する（Ｓ５）。
【００５０】
ドライブは、SEND KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Host Certificationの正当性を検証する。また、ディスク１００からHRLを読み出し、検証したHost Certificationに記載されたホストIDがHRLに存在しないことを確認する（Ｓ６）。なお、ドライブは、この処理の際に、HRLの正当性をも検証する。この検証は、HRLの正当性を検証するために予めライセンサから配布された検証用公開鍵を用いて所定の演算を行うことにより行われる。
【００５１】
次いで、ホストは、パケットコマンド（REPORT KEY）を発行し、公開鍵およびそのライセンサによる署名文を含むDrive Certificationをドライブに要求する（Ｓ７）。
【００５２】
ドライブは、REPORT KEYを受信すると、ドライブＩＤ格納部１０７に格納されているDrive Certification等からREPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ８）。
【００５３】
ホストは、REPORT KEY Data Format を受信すると、Drive Certificationの正当性を検証する。また、検証したDrive Certificationに記載されたDrive IDがDRLに存在しないことを確認する（Ｓ９）。なお、ホストは、この処理の際に、DRLの正当性をも検証する。この検証は、DRLの正当性を検証するために予めライセンサから配布された検証用公開鍵を用いて所定の演算を行うことにより行われる。
【００５４】
さらに、ホストは、パケットコマンド（REPORT KEY）を発行し、共通鍵を生成するためのセッション鍵であるDrive KEYをドライブに要求する（Ｓ１０）。
【００５５】
ドライブは、REPORT KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Drive Keyおよびその署名文を生成する。また、これらDrive Key等から、パケットコマンド処理部１０６にて、REPORT KEY Data Formatを作成し、これをホストに送信する（Ｓ１１）。
【００５６】
ホストは、Drive CertificationのDrive公開鍵によりDrive Keyの正当性を検証する。そして、所定の演算により、共通鍵を生成するためのセッション鍵であるHost Keyおよびその署名文を生成する（Ｓ１２）。また、Host KeyとDrive Keyより、共通鍵であるBus Keyを所定の演算により生成する（Ｓ１３）。
【００５７】
次に、ホストは、Host Key等からSEND KEY Parameter Listを作成し、ドライブにパケットコマンド（SEND KEY）を発行する（Ｓ１４）。
【００５８】
ドライブは、SEND KEYを受信すると、ＡＡＣＳプロトコル処理部１０５にて、Host Keyを用いながら共通鍵であるBus Keyを所定の演算により生成する（Ｓ１５）。
【００５９】
以上の手順により、ホストとドライブは、相互の認証を行いながら、共通鍵であるBus Keyを共有する。これにより、ホストとドライブの間に暗号化通信路が確立される。
【００６０】
２．コンテンツの記録再生処理
以上のようにして暗号化通信路が確立されると、次に、ホストは、暗号化通信路を介して、セキュア情報をディスク１００から読み出す。そして、読み出したセキュア情報に所定の演算を施してコンテンツの暗号鍵を取得する。
【００６１】
ディスク１００からコンテンツを再生する場合、ホストはドライブにパケットコマンド（READ）を発行する。ドライブは、READを受信すると、ディスク１００から入出力処理部１０１を介してコンテンツデータを読み出し、これを復号処理部１０２にて復号する。そして、復号したコンテンツデータを、パケットコマンド処理部１０６を介してホストに送信する。
【００６２】
ホストは、ドライブから受信したコンテンツデータを、上記セキュア情報から取得した暗号鍵にて復号する。そして、復号したコンテンツデータに再生処理を施し、モニターやスピーカ等の出力手段から出力する。
【００６３】
ディスク１００にコンテンツデータを記録する場合、ホストは、コンテンツデータを上記暗号鍵で暗号化し、ドライブにパケットコマンド（WRITE）を発行する。ドライブは、WRITEを受信すると、パケットコマンド処理部１０６を介してコンテンツデータを受信し、受信したコンテンツデータに対して、符号化処理部１０３にて、デジタル変調および誤り訂正符号化等の符号化処理を施す。そして、符号化後のコンテンツデータを、入出力制御部１０１を介してディスク１００に記録する。
【００６４】
３．リボケーション情報の生成処理
次に、図４を参照して、リボケーション情報の生成処理について説明する。
【００６５】
ドライブにディスク１００が装着されると、入出力制御部１０１と復号処理部１０２を介して、ディスク１００からDRLが読み出され、これがＤＲＬ処理部１０４に送られる（Ｓ１０１）。ＤＲＬ処理部１０４は、まず、図２に示す“Signature for Block i"を用いて、受け取ったDRLの正当性を検証する（Ｓ１０２）。
【００６６】
なお、DRLの正当性の検証は、図３のＳ４にて行われるHRLの正当性の検証と同様の演算処理にて行われる。すなわち、ドライブは、HRLの正当性の検証のため予めライセンサから配布された検証用公開鍵を用いてDRLの検証を行うことができる。
【００６７】
DRLが正当でない場合（S１０３：Ｎ）、リボケーション情報の生成処理は中止される。DRLが正当である場合（Ｓ１０３：Ｙ）、ＤＲＬ処理部１０４は、当該DRLを解析して、当該DRL中に記述されたDrive Revocation List Entriesを順次参照する（Ｓ１０４）。そして、ドライブＩＤ格納部１０７に格納されている自己のDrive IDがDRL中に存在するかを判別する（Ｓ１０５）。
【００６８】
ここで、自己のDrive IDがDRL中に存在しなければ（Ｓ１０５：Ｎ）、リボケーション情報の生成処理は中止される。一方、自己のDrive IDがDRL中に存在する場合（Ｓ１０５：Ｙ）、ＤＲＬ処理部１０４は、その旨を判別するためのフラグ情報やDRLのバージョン情報（図２には図示省略）等から構成されるリボケーション情報を生成し、これをリボケーション情報格納部１０８に格納する（Ｓ１０６）。
【００６９】
４．ホストからGET CONFIGURATIONを受信したときの処理
次に、ホストからGET CONFIGURATIONを受信したときにドライブにて行われる処理について、図５を参照して説明する。
【００７０】
ホストからパケットコマンド（GET CONFIGURATION）を受信すると（S２１０:Ｙ）、パケットコマンド処理部１０６は、リボケーション情報格納部１０８にリボケーション情報が格納されているかを判別する（Ｓ２０２）。ここで、リボケーション情報が格納されていなければ（Ｓ２０２：Ｎ）、上記図３のＳ２にて説明したとおり、AACS Feature Descriptorが作成され（Ｓ２０３）、さらに、自己の機能を示す他のFeature Descriptorが生成されて（Ｓ２０４）、これらがHostに送信される（Ｓ２０５）。
【００７１】
一方、リボケーション情報格納部１０８にリボケーション情報が格納されている場合、すなわち、自己が不正ドライブである場合（Ｓ２０２：Ｙ）には、AACS Feature Descriptorの作成処理（Ｓ２０３）がスキップされ、自己の機能を示す他のFeature Descriptorが生成される（Ｓ２０４）。そして、他のFeature Descriptorのみがホストに送信される（Ｓ２０５）。
【００７２】
図５に示す処理は、上記図３の暗号化通信路の確立処理のＳ１にて、ドライブがホストからパケットコマンド（GET CONFIGURATION）を受信した場合の他、使用者が、ホストを介してドライブに、任意にパケットコマンド（GET CONFIGURATION）を発行した場合にも行われる。
【００７３】
このうち、暗号化通信路の確立処理にてドライブがホストからパケットコマンド（GET CONFIGURATION）を受信した場合（図３のＳ１）には、以下の処理が行われる。
【００７４】
すなわち、Ｓ２０５にて、AACS Feature Descriptorと他のFeature Descriptorがホスト側に送信された場合（当該ドライブが不正ドライブである場合）には、上記図３に示すＳ３以降の処理が行われる。
【００７５】
一方、Ｓ２０５にて、他のFeature Descriptorのみがホスト側に送信された場合（当該ドライブが不正ドライブである場合）には、ドライブからのレスポンスにAACS Feature Descriptorが含まれていないため、ホストは、当該ドライブをAACSに対応できないものと判定し、上記図３のＳ３以降の処理を中止する。この場合、当該ドライブに対する正当性の認証処理がホストにおいて行われることはない。したがって、ホストは、当該ドライブを不正ドライブとして認識せず、単に、AACSに対応できないドライブとして判定する。
【００７６】
この場合、ホスト側において、当該ドライブとの通信を一切拒否するとの処理が取られることはない。よって、ディスク１００に非暗号化コンテンツが格納されている場合や、AACS以外のコンテンツ保護機能にて再生可能なコンテンツが格納されている場合にも、ホスト側において、これらのコンテンツをディスク１００から読み出して再生するとの処理が採られ得る。
【００７７】
さらに、パケットコマンド（GET CONFIGURATION）は、暗号化通信路の確立処理の他、使用者において、ホストからドライブに任意に発行し得るコマンドであるから、使用者は、適宜、このコマンドをドライブに発行してそのレスポンスの内容を確認することにより、通信先ドライブが不正ドライブであるかを知ることができる。すなわち、通信先ドライブがAACS対応ドライブであるにも係らず、GET CONFIGURATIONのレスポンスにAACS Feature Descriptorが含まれていなければ、当該ドライブを不正ドライブとして認識することができる。
【００７８】
このように、本実施の形態によれば、不正ドライブの使用価値を高めながら、同時に、通信先ドライブが不正ドライブであることを使用者において簡易に認知することができる。なお、本実施の形態においても、AACSによって保護されたコンテンツが不正ドライブによってディスクから読み出されることはなく、AACSによるコンテンツの保護機能は高く維持される。
【００７９】
以上、本発明の実施の形態について説明したが、本発明は、上記実施の形態に限定されるものではない。
【００８０】
たとえば、上記実施の形態では、パケットコマンド（GET CONFIGURATION）に対する応答内容から、使用者において、通信先ドライブが不正ドライブであることを認知できるようにしたが、この他、ドライブにＬＥＤ等の表示手段を設け、これにより、ユーザに不正ドライブであることを直接報知するようにすることもできる。
【００８１】
本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。
【図面の簡単な説明】
【００８２】
【図１】実施の形態に係る情報記録再生装置（ドライブ）の構成を示す図
【図２】実施の形態に係るＨＲＬとＤＲＬのデータ構造を示す図
【図３】実施の形態に係る暗号化通信路確立の際の流れを説明する図
【図４】実施の形態に係るリボケーション情報生成時の処理フローチャート
【図５】実施の形態に係るパケットコマンド（GET CONFIGURATION）受信時の処理フローチャート
【符号の説明】
【００８３】
１０４ ＤＲＬ処理部
１０５ ＡＡＣＳプロトコル処理部
１０６ パケットコマンド処理部
１０７ ドライブＩＤ格納部
１０８ リボケーション情報格納部
１０９ 制御部
【特許請求の範囲】
【請求項１】
記録媒体に対し情報の記録および／または再生を行う情報記録再生装置において、
通信先装置との間で情報の送受信を行う通信処理部と、
第１の情報管理技術に従った情報処理を行う情報処理部と、
前記第１の情報管理技術に基づいて自己の正当性を判断する判断処理部と、
前記判断処理部にて自己が不正であると判断されたとき前記第１の情報管理技術による情報処理能力がないことを前記通信先装置に通知する通知処理部を有する、
ことを特徴とする情報記録再生装置。
【請求項２】
請求項１において、
前記通知処理部は、前記通信先装置から自己の情報処理能力を問い合わせるコマンドに対する応答に、前記第１の情報管理技術による情報処理能力がないことを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項３】
請求項２において、
前記通知処理部は、前記応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項４】
請求項３において、
前記通知処理部は、前記第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べるために前記通信先装置から発行された前記コマンドに対する応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項５】
請求項１ないし４の何れか一項において、
自己を識別するための識別情報を格納するＩＤ格納部をさらに備え、
前記判断処理部は、当該情報記録再生装置に装着された記録媒体から前記第１の情報管理技術において不正とされる情報記録再生装置を規定する識別情報を取得し、取得した識別情報の中に、前記ＩＤ格納部に格納されている自己の識別情報が含まれているときに、前記第１の情報管理技術において自己が不正であると判断する、
ことを特徴とする情報記録再生装置。
【請求項６】
請求項１ないし４の何れか一項において、
前記判断処理部にて不正であると判断されたことを報知する報知手段をさらに有する、
ことを特徴とする情報記録再生装置。
【請求項１】
記録媒体に対し情報の記録および／または再生を行う情報記録再生装置において、
通信先装置との間で情報の送受信を行う通信処理部と、
第１の情報管理技術に従った情報処理を行う情報処理部と、
前記第１の情報管理技術に基づいて自己の正当性を判断する判断処理部と、
前記判断処理部にて自己が不正であると判断されたとき前記第１の情報管理技術による情報処理能力がないことを前記通信先装置に通知する通知処理部を有する、
ことを特徴とする情報記録再生装置。
【請求項２】
請求項１において、
前記通知処理部は、前記通信先装置から自己の情報処理能力を問い合わせるコマンドに対する応答に、前記第１の情報管理技術による情報処理能力がないことを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項３】
請求項２において、
前記通知処理部は、前記応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項４】
請求項３において、
前記通知処理部は、前記第１の情報管理技術に従う情報処理を当該情報記録再生装置との間で相互に適用可能かを調べるために前記通信先装置から発行された前記コマンドに対する応答に、前記第１の情報管理技術とは相違する第２の情報管理技術に従った情報処理能力を有することを示す情報を含める、
ことを特徴とする情報記録再生装置。
【請求項５】
請求項１ないし４の何れか一項において、
自己を識別するための識別情報を格納するＩＤ格納部をさらに備え、
前記判断処理部は、当該情報記録再生装置に装着された記録媒体から前記第１の情報管理技術において不正とされる情報記録再生装置を規定する識別情報を取得し、取得した識別情報の中に、前記ＩＤ格納部に格納されている自己の識別情報が含まれているときに、前記第１の情報管理技術において自己が不正であると判断する、
ことを特徴とする情報記録再生装置。
【請求項６】
請求項１ないし４の何れか一項において、
前記判断処理部にて不正であると判断されたことを報知する報知手段をさらに有する、
ことを特徴とする情報記録再生装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００７−２５００３８（Ｐ２００７−２５００３８Ａ）
【公開日】平成１９年９月２７日（２００７．９．２７）
【国際特許分類】
【出願番号】特願２００６−６８９４９（Ｐ２００６−６８９４９）
【出願日】平成１８年３月１４日（２００６．３．１４）
【出願人】（０００００１８８９）三洋電機株式会社 (18,308)
【Ｆターム（参考）】
【公開日】平成１９年９月２７日（２００７．９．２７）
【国際特許分類】
【出願日】平成１８年３月１４日（２００６．３．１４）
【出願人】（０００００１８８９）三洋電機株式会社 (18,308)
【Ｆターム（参考）】
[ Back to top ]