JP4219680B2 - 不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録済みのオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法およびデバイス - Google Patents

Description

【０００１】
（関連出願の相互参照）
本願は、“不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのセキュリティが保護されたソフトウェアシステム”という２０００年１２月７日出願の米国仮特許出願第６０／２５１，７３１号に関連し、該仮特許出願を優先権主張の基礎とするものであり、さらに、本願は、本願と同日付で、本願と同じ発明者を有する米国で同時出願された、“不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録されたオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法および装置（代理人整理番号：Ｍ−９９１３ＵＳ）という米国特許出願に関連する。これらの出願は、本願において上記参照によりその全体が援用されている。
【０００２】
３７ＣＦＲ１．５２に従って、以下のファイルを含む添付書類としてコンパクトディスクでソースコードを提出する。上記ファイルの各々は本願において上記参照によりその全体が援用されている。

【０００３】
【発明の属する技術分野】
本発明は、一般にまた具体的には、メモリカード、コンパクトディスクまたはその他のメディアから得られるデジタル形式のオーディオ、ビデオまたはその他のコンテンツのセキュリティが保護された再生に関する。
【０００４】
【従来の技術】
別の通信システムによって、あるいは、小売店のキオスクを通じてインターネットによって著作権のある音楽の電子配信を実施する可能性には音楽の不法コピーに関する懸念による限界がある。これは他のオーディオ・コンテンツ並びにビデオコンテンツについても言えることである。一般にコンテンツは暗号化された形で最終顧客へ提供され、顧客は、パーソナル・コンピュータのメモリ、携帯用再生装置のメモリ、書込み可能なコンパクトディスク（ＣＤ）または不揮発性メモリカードのような何らかの記憶メディア上へ暗号化されたコンテンツファイルを記録する。コンテンツのプロバイダは、コンテンツの不法コピーが行われる可能性が取り除かれることを望んではいるが、不法に行われるコピーの量を最少化するステップをとることで満足せざるを得ない状況がある。これには記録メディア上のコンテンツに保護を与えることが含まれる。ここでは、具体例として、不揮発性メモリカード上に記憶されたコンテンツの保護について説明するが、この同じコンテンツ保護技法はコンパクトディスクや他の記録可能メディアにも適用可能である。
【０００５】
コンテンツデータの記憶メディアとして利用に適したいくつかの市販の不揮発性メモリカードが存在する。１つの不揮発性メモリカードとしてコンパクトフラッシュ（ＣＦ）カードがあり、別の不揮発性メモリカードとしてマルチメディアカード（ＭＭＣ）があり、さらに別の不揮発性メモリカードとしてＭＭＣカードと密接に関連するセキュリティの保護されたデジタル（ＳＤ）メモリカードがある。これら３つの不揮発性メモリカードのすべておよびその他の不揮発性メモリカードは、本願の譲受人であるカリフォルニア州サニーベールのサンディスク コーポレイションから発売されている様々な容量の記憶デバイスで利用可能である。物理的および電気的仕様は“マルチメディアカードシステム仕様”に示されている。この仕様は、カリフォルニア州クパティーノのマルチメディアカード協会（“ＭＭＣＡ”）により時折更新され、公開されている。当該仕様のバージョン２．１１と２．２（１９９９年６月および２０００年１月版）はそれぞれ明白に本願明細書に参照により援用されている。ＭＭＣ製品については“マルチメディアカード製品マニュアル”（“改訂２版、２０００年４月付、サンディスク コーポレイションにより発行）にも記載があり、このマニュアルは明白に本願明細書に参照により援用されている。ＭＭＣ製品についての電気的動作の或る局面については、Thomas N. ToombsとMicky Holtzmanによる同時継続特許出願第０９／１８５，６４９号および第０９／１８６，０６４号にも記載がある。上記特許出願は双方とも１９９８年１１月４日に出願され、サンディスク コーポレイションに譲渡されたものである。カードの物理的構造とその製造方法については、サンディスク コーポレイションに譲渡された米国特許第６，０４０，６２２号に記載がある。これらの特許出願と特許の双方も明白に本願明細書に参照により援用されている。
【０００６】
上記新しいＳＤカードはＭＭＣカードに類似したカードであり、平面図では同じ形をしている。これらのカード間の主要な相違点として、ＳＤカードがカードとホスト間のさらに高速なデータ転送を可能にするために追加のデータ用接点を備えているという点が挙げられる。ＳＤカードのその他の接点はＭＭＣカードの接点と同じであり、ＳＤカードを受け入れるように設計されているソケットはＭＭＣカードも受け入れるようにつくられている。ＳＤカードとの電気的インタフェースは、さらに、上記で引用したＭＭＣ製品の仕様書のバージョン２．１１に記載されているＭＭＣ製品と逆方向の互換性を有するように大部分がつくられており、双方のタイプのカードを適合させるように、ホストの動作に対応する２、３の変更を行う必要があるようにつくられている。ＳＤカードの電気的インタフェースおよびその動作については、２０００年８月１７日に出願の同時継続特許出願第０９／６４１，０２３号に記載がある。上記特許出願は本明細書にその全体が参照により援用されている。
【０００７】
（発明の開示）
暗号化されたコンテンツはアクセスが困難であり、暗号化されたコンテンツを含むメモリカードまたはコンパクトディスクは、暗号化コンテンツと未暗号化コンテンツにアクセスするための専用コマンドとルーチンとを必要とする固有の構造を各々有している。本発明のソフトウェアは簡単なソリューションであり、いずれの他社製部品組込み製品製造販売企業（ＯＥＭ）もインストールが可能で、無数の異なるタイプのマイクロプロセッサを備えた無数の異なるタイプのデバイス上で実行可能なソリューションである。これらのデバイスはパーソナル・コンピュータから携帯用デバイス、カーステレオまでをカバーし、これらのデバイスには、暗号化が可能なコンテンツへのアクセスを望む任意のデバイスが含まれる。上記携帯用デバイスとしては、携帯用オーディオ・プレイヤや携帯電話や携帯用情報機器あるいは、一般に、マイクロプロセッサにより制御される任意の携帯用デバイスを挙げることができる。記憶メディアとしてはフラッシュメモリまたは任意のタイプの記録可能ディスクを挙げることができる。デバイスとしては、少量または大量のメモリを持つ単純なまたは強力なマイクロプロセッサを備えたデバイスを挙げることができる。上記ソフトウェアは、暗号化を行うことを目的として小さなバッファのみを利用し、必要とするものであり、限られた処理パワーとメモリ環境においても効率的に機能するように設計されている。このソフトウェアは、任意のタイプの汎用マイクロプロセッサ、ＤＳＰやＡＳＩＣなどのような特定目的のマイクロプロセッサにより実行可能である。さらに、暗号化と解読（セキュリティ）エンジンのようなソフトウェアの計算要求部はＤＳＰによる実行が可能であり、一方ソフトウェアの別の部分は、別のマイクロプロセッサまたはＡＳＩＣにより実行が可能である。
【０００８】
上記ソフトウェアには、それぞれのタイプのファイルの各々に対するコマンドを受け取るためのオーディオ、ビデオおよび画像用インタフェースが含まれる。これらのインタフェースは、管理用再生リストおよびその他の都合のよい特徴を含む再生と記録の編成が可能である。したがって、デバイスは、その如何に関らず、インタフェースに対してコマンドを出すだけで十分であり、次いで、セキュリティ保護メディアからのデータの読出し処理または書込み処理、並びに、任意の周知のオーディオ、ビデオまたは画像ファイルフォーマットからのデータの復号化処理と解凍処理とがソフトウェアによりオーディオ、ビデオまたは画像エンジン内で行われる。
【０００９】
暗号化と解読は、アクセスが非常に困難な分離されたモジュール内で行われ、したがって該モジュールは、メディアまたはデバイスからファイルをコピーするために暗号化キーにアクセスしようとする、アクセス権限が与えられていない人からのいかなる試みからも分離されている。コンテンツは小部分で解読され、ダイナミックキーの作成および削除方法により解読対象キーの露出部分が最少化される。
【００１０】
【発明の実施の形態】
暗号化されたコンテンツはアクセスが困難であり、暗号化されたコンテンツを含むメモリカードまたはコンパクトディスクは、暗号化されたコンテンツと未暗号化コンテンツにアクセスするための専用コマンドとルーチンとを必要とする固有の構造を各々有している。本発明のソフトウェアは簡単なソリューションであり、いずれの他社製部品組込み製品製造販売企業（ＯＥＭ）もインストールが可能で、無数の異なるタイプのマイクロプロセッサを備えた無数の異なるタイプのデバイス上で実行可能なソリューションである。これらのデバイスはパーソナル・コンピュータから携帯用デバイス、カーステレオまでをカバーし、これらのデバイスには、暗号化が可能なコンテンツへのアクセスを望む任意のデバイスが含まれる。上記携帯用デバイスとしては、携帯用オーディオ・プレイヤや携帯電話や携帯用情報機器あるいは、一般に、マイクロプロセッサにより制御される任意の携帯用デバイスを挙げることができる。記憶メディアとしてはフラッシュメモリまたは任意のタイプの記録可能ディスクを挙げることができる。デバイスとしては、少量または大量のメモリを持つ単純なまたは強力なマイクロプロセッサを備えたデバイスを挙げることができる。上記ソフトウェアは、暗号化を行うことを目的として小さなバッファのみを利用し、必要とするものであり、限られた処理パワーとメモリ環境においても効率的に機能するように設計されている。このソフトウェアは、任意のタイプの汎用マイクロプロセッサ、ＤＳＰやＡＳＩＣなどのような特定目的のマイクロプロセッサにより実行可能である。さらに、暗号化と解読（セキュリティ）エンジンのようなソフトウェアの計算要求部はＤＳＰによる実行が可能であり、一方ソフトウェアの別の部分は、別のマイクロプロセッサまたはＡＳＩＣにより実行が可能である。関連出願の相互参照の欄で引用したソースコードは、本願の一部を形成し、本願において上記参照によりその全体が援用されている。
【００１１】
図１を参照して、コンテンツ保護が音楽のようなオーディオ・コンテンツに対して適用される例示システムについて説明する。ホスト・コンピュータデバイス１１は、図に示すようなパーソナル・コンピュータ（ＰＣ）（音楽やその他のコンテンツまたはその類似物を配信する小売店に置かれたキオスク）であってもよい。この例では、ＳＤメモリカード１３を用いて音楽が記憶される。カード１３は、このケースでは、携帯用デバイス（ＰＤ）１５である利用デバイスの中へ挿入することができる。上記携帯用デバイス（ＰＤ）１５は電池で作動し、カード１３に記録された音楽やその他のオーディオ・コンテンツの再生が個人のイヤホンを通じて行われる。カード１３がデバイス１５の中へ挿入されると、コンピュータ用のユニバーサル・シリアル・バス（ＵＳＢ）接続１７などを介してデバイス１５をホスト１１と接続することにより、そのカードに音楽を記憶することができる。或いは、デバイス１５にカード１３上へのコンテンツの記録能力が設けられていなければ、あるいは、デバイス１５が違った形で望ましいデバイスであれば、ＵＳＢ接続２１を介してコンピュータをカード書込み／読出し装置１９と接続してもよく、カードに音楽を記録するために、カード１３のコンピュータの中への挿入も可能である。次いで、書込み／読出し装置１９からカード１３を取り外し、このカードを携帯用デバイス１５の中へ挿入して、カードに記録されているオーディオ・コンテンツの再生が行われる。４ＣエンティティとＳＤグループのセキュリティおよび認証プロトコルに従ってコンテンツデータのカード１３への書込みおよびカード１３からのコンテンツデータの読出しに必要なソフトウェアがホスト１１に含まれている場合、ホスト１１は使用許諾を受けた対応モジュール（ＬＣＭ）と呼ばれる。
【００１２】
例示の携帯利用デバイス１５内の電子システムが図２に例示されている。好ましくは何らかの不揮発性フラッシュメモリ２５Ａを備えた計算用ユニット（ＭＣＵ）２５と、好ましくは高速ランダムアクセスメモリ（ＲＡＭ）であることが望ましいシステムメモリ２７と、メモリカード１３との接続用インタフェース回路２９とがバス２３を介して作動可能に一体に接続される。ＵＳＢ接続１７もオプションとしてＭＣＵ２５に設けられる。圧縮形式および／または暗号化形式で記憶された、オーディオまたはビデオデータのようなコンテンツデータの解凍用および／または解読に必要な場合、デジタル信号プロセッサ（ＤＳＰ）３１も含まれる。ＤＳＰ３１は、プロセッサの一部として設けられているＤＳＰ自身のＲＡＭメモリ３１Ａを有する。ＤＳＰ３１を設けてもよいし、設けなくてもよい。さらに、ＤＳＰプロセッサが設けられていれば、ＤＳＰプロセッサによるＭＣＵ２５の機能の実行が可能となり、したがって、ＭＣＵ２５を省くことが可能となる。リードオンリメモリ（ＲＯＭ）３２は本発明のソフトウェアの一部またはすべてを記憶することができる。ＲＯＭ３２内のソフトウェア命令とデータを実行したり、ＲＯＭ３２からこの命令とデータとを直接読出したり、デバイスの回路構成内のいずれかのＲＡＭメモリの中へこれらをまずコピーしたりすることができる。
【００１３】
記録可能メディアのコンテンツの保護仕様がインテル、ＩＢＭ、松下電気産業株式会社、東芝コーポレーション（４Ｃエンティティ）により共同で確定されている。特に本願と関連があるのは４Ｃエンティティの以下の３つの文献であり、これらの文献は明白に本願明細書に参照により援用されている。これらは、“記録可能メディア仕様のためのコンテンツ保護、導入、および共通暗号要素”（改訂版０．９４、２０００年１０月）、“記録可能メディア仕様書、ＳＤメモリカードブックのためのコンテンツ保護”（改訂版０．９５、２００１年５月）、および、“Ｃ２ブロック暗号仕様書”（改訂版０．９、２０００年１月１１日）と“記録可能メディア仕様書、ＤＶＤブックのためのコンテンツ保護”（改訂版０．９５、２００１年５月）である。ＳＤメモリカードに関するこれらの４Ｃエンティティ仕様を実現するための追加の詳細な仕様が松下電気産業株式会社（ＭＥＩ）、サンディスク コーポレイションおよび東芝コーポレーション（ＳＤグループ）により確定されている。
【００１４】
図３Ａを参照すると、メモリカード１３は４つの別個の層を有するものと考えることができる。このような層は別のタイプのセキュリティ保護メディアの中に存在するものであってもよい。
【００１５】
データの最も基本的レベルで、データは、メモリカード１３の物理層１３ｄのクラスタ内に構成されるメモリセルに記憶される。このデータは、著作権のあるもの、あるいは、暗号化に値するものであれば暗号化すなわちセキュリティの保護が行われる。セキュリティが保護されたコンテンツの暗号化と解読に用いるキーも暗号化され、物理層のセキュリティが保護された領域に記憶される。
【００１６】
本発明のソフトウェアはデバイス内で機能し、暗号化されたデータとキーとを含むメモリセルにアクセスするための非常に特殊な命令を製造業者（ＯＥＭ）がプログラムする必要なく、デバイスによる暗号化情報の記憶と検索とが可能となる。上記ソフトウェアには、デバイスへ暗号化データを送信し、デバイス内でデータを解読し、デバイスからの要求時にオーディオ、ビデオおよび画像ファイルを解凍し、このファイルの再生を行う方法が含まれる。要するに、デバイスは、“トラックを再生せよ”のようなコマンドを送信するだけで十分である。上記ソフトウェアはこのコマンドを受け入れ、メモリセルに記憶された暗号化データを検索し、暗号化キーを検索し、データの編成と解読とを行い、データの解凍とフォーマットとを行って歌を再生する。
【００１７】
論理層１３ｃには、物理層１３ｄのメモリセルとクラスタのための編成構造が含まれる。２つの層１３ｃと１３ｄにはカード１３のメモリが含まれ、これらの層によりカード１３のメモリが論理的に構造化される。カード１３はセキュリティが保護されたカードであるため、セキュリティ層１３ｂにより、下層に収納されているセキュリティが保護されたデータへのアクセスの制御と制限とが行われる。
【００１８】
アプリケーション層１３ａは、カードに記憶されたコンテンツにアクセスするデバイスと交信するメモリカード１３の一部である。アプリケーション層１３ａは、デバイスインタフェースまたは接点３９を介して上記交信を行う。メモリカード１３には、好ましくは、カードのすべての層１３ａ−ｄの制御と共に、カードの処理とアプリケーション層１３の機能とを管理するコントローラが含まれることが望ましい。
【００１９】
図３Ａの層１３ｃと１３ｄに対応する上記仕様に準拠する記録メディア（ＳＤカード１３）の物理構造と論理構造とが図３Ｂに例示されている。このカードにはメモリセル３３のアレイとメモリ・コントローラ３５とが含まれている。ユーザデータとコマンドと状態信号との交信が、コントローラ３５とメモリアレイ３３との間で回路３７を介して行われる。コントローラ３５は、カード上の一連の電気接点３９を介してカードが挿入されているソケットと接続されるホストデバイスと交信する。
【００２０】
アレイ３３のメモリセルは分割され、異なるタイプのデータを記憶するように個々に指定されるセルの４つの非オーバーラップ領域に分けられる。最大の記憶容量領域４１が指定されて、ユーザデータ、このケースでは、暗号化されたオーディオ、ビデオまたはその他のデータが記憶される。ユーザデータは、暗号化されていないデータを含むものであってもよいし、含まないものであってもよい。メモリのシステム領域４３はカード製造業者の６４ビットメディア識別子（ＩＤ_media ）と、４Ｃエンティティにより提供される１６個のメディアキー・ブロック（ＭＫＢ）とを記憶し、各ＭＫＢは最大４キロバイトのサイズを有する。これらはすべてカード製造業者により予め記録されている。１６ＭＫＢのうちの１ＭＫＢがオーディオユーザデータでの使用に指定されており、別の１ＭＫＢはビデオユーザデータ、画像データ等々の別の用途での使用に指定されている。システム領域４３はカードの外側からの読出し用としてアクセス可能な書込み領域である。隠された領域４５は、システム領域４３に記憶された１６個の別個のメディアキー・ブロック（ＭＫＢ）に対応する１６個の予め記録された一意的メディアキー（Ｋ_mu）を担持する。この隠された領域４５は、メモリカード自身でしかアクセスできない書込み保護領域である。この保護領域４７は、明確な相互認証に成功した後でしかアクセスできない読出し／書込み領域である。ランダムに選ばれたタイトルキー（Ｋ_t ）とコピー制御情報（ＣＣＩ）とが暗号化された形式で保護領域４７に記憶される。ユーザデータ領域４１に記憶されたコンテンツの各ピース（ファイル）は、やはり保護領域４７に暗号化された形式で記憶された一意的タイトルキーを用いて暗号化される。保護領域４７に記憶されたタイトルキーとＣＣＩは、一意的メディアキーによりまとめて連鎖され、暗号化される。上記一意的メディアキーは各メモリカードについて一意的に決められ、この一意的メディアキーの隠された領域４５に記憶される。
【００２１】
ユーザデータ領域４１のファイルシステムは一般に通常のＦＡＴファイルシステムである。ＦＡＴシステムは、どのようなメモリクラスタがどのようなトラックを形成しているかについておよびトラックの様々なサブコンポーネントについて記述する。ユーザデータ領域４１内のオーディオまたはビデオトラックは、図３Ｃに例示しているように、複数のファイルを含むものであってもよい。オーディオファイルはオーディオ・オブジェクト（ＡＯＢ）と呼ばれ、映像ファイルは映像オブジェクト（ＰＯＢ）と呼ばれる。トラックは双方のオブジェクトを含むものであってもよい。例えば、トラック３００はＡＯＢ３０４とＡＯＢ３０８とから構成され、トラック３０２はＡＯＢ３０６から構成され、最後のトラック×××はＡＯＢ×××とＰＯＢ×××とから構成される。各ＡＯＢまたはＰＯＢはサブコンポーネントにも分解される。ＡＯＢ３０４はＡＯＢブロック３１２に分解された形で示されている。これらのブロックはさらにヘッダ３１８を持つＡＯＢエレメント３１６に分解される。各エレメントはメモリカード１３の１以上のメモリクラスタに記憶することも可能である。ＡＯＢエレメントは最も低いコンポーネントレベルであるＡＯＢフレーム３２０に分割される。コンテンツの符号化と圧縮に相応して、２秒毎に変動するフレーム数を含むものであってもよい。タイムサーチ・テーブル（ＴＭＳＲＴ）には、フレーム数と“２秒毎”の再生に対応するデータサイズとに関する情報が含まれている。オーディオまたはビデオトラックおよびコンポーネントＡＯＢのエレメントとフレームにアクセスする際、速送りと巻き戻しのためにこの情報が利用される。また、図９と図１０とを参照しながら後述するように、この“２秒毎”のコンテンツにアクセスするのにかかる時間の間だけタイトルキー（Ｋ_t ）は解読状態になるが、１秒未満から１０秒までのコンテンツであればどの範囲のコンテンツでも同時に解読が可能である。さらなる詳細については、参照により援用されている前述したＣＰＲＭ仕様書、ＳＤメモリカードブックを参照されたい。
【００２２】
カードメモリのシステム領域４３に記憶されているようなメディアキー・ブロック（ＭＫＢ）には、一続きの連続するレコード、図４に例示されているような１つのレコードが含まれる。ＭＫＢ画像４９全体は６４キロバイトである。このＭＫＢ画像４９は５１２バイトからなる１２８チャンクに分割される。チャンク１は、第１のレコードの全てまたは一部を含み、図でＭＫＢチャンク５０のラベルがつけられているが、このチャンク１は拡大されて、その構成要素部分が示されている。チャンク５０は複数のレコードを含むものであってもよい。第１のフィールド５１にはレコードタイプが含まれ、第２のフィールド５３には上記レコードの全長が含まれ、残りのフィールド５５にはキー自身が含まれる。このレコードタイプのデータおよび長さフィールド５１と５３は暗号化されない。ＭＫＢの各レコードの全長は４の倍数のバイトである。図５のブロック５７により例示されているように、ＭＫＢのキーレコードは、携帯用デバイス（ＰＤ）、使用許諾を受けた対応モジュール（ＬＣＭ）、あるいは、メモリカードに記憶されたコンテンツデータの読出しまたはプログラミング用メモリカードを利用する別のデバイスに記憶されたデバイスキーにより解読される。デバイスキーＫｄ１、Ｋｄ２、Ｋｄ３…が、図２の携帯用オーディオ・プレイヤのＭＣＵ２５内の不揮発性フラッシュメモリのような利用デバイスのメモリの中へデバイス製造業者により書込まれる。これらのデバイスキーは４Ｃエンティティによりデバイス製造業者へ提供され、秘密に保持される。所定の利用デバイスに記憶されるデバイスキーの数はデバイスタイプに依存して決められる。
【００２３】
図５の処理を行う利用デバイス（ＰＤ、ＬＣＭまたは別のデバイス）はブロック５７の解読の一部としてメディアキーＫ_m を計算する。これについては図９と図１０を参照しながらさらに詳細に解説する。挿入されたメモリカードのシステム領域から読出されたＭＫＢの各レコード（図４）は通常以下のように処理される。ＭＫＢの処理の完了後、ブロック５７の秘密メディアキー出力として最も新しく計算されたＫ_m 値が用いられる。このメディアキーＫ_m とメディア識別子ＩＤ_media は図５のブロック５９により示されるようにＣ２の一方向機能により合成され、一意的メディアキーＫ_muが作成される。この処理についての追加の詳細は前に引用した４Ｃエンティティの文献を参照することにより得ることができる。
【００２４】
図６は、図３のメモリ空間割当てを有するメモリカード１３上へのオーディオ・コンテンツの記録時、または、上記メモリカード１３からのオーディオ・コンテンツの再生時のいずれかの際に行われる認証と暗号化処理の全てを示す。オーディオ・コンテンツまたは別のコンテンツのカード１３上への記録を行うための、パーソナル・コンピュータまたは別のＬＣＭ６３で行われる処理が例示されている。同様に、記録されたコンテンツをカード１３から読出すための携帯用オーディオまたは別の利用デバイス６５の処理が図示されている。図５と関連して記載した処理が上記双方のデバイスに含まれており、ブロック５７と５９の処理は利用デバイス６５の一部であり、対応するブロック５７’と５９’の処理はコンテンツ記録システム６３の一部である。
【００２５】
記録用コンテンツの一部として、任意に割り当てられたタイトルキーＫ_t が暗号化モジュール６９によりライン６７で入力され、ライン７１で入力されるオーディオ・コンテンツまたは別のコンテンツの１つのファイル（ピース）の暗号化に使用される。次いで、暗号化ファイルがメモリカード１３のユーザデータ領域４１に記憶される。記録されたコンテンツの解読にタイトルキーを利用できるようにするために、前述したように、タイトルキー（Ｋ_t ）の暗号化されたバージョンがセキュリティの保護されたカードの記憶領域４７に記憶される。タイトルキー（Ｋ_t ）の暗号化されたバージョンも、システムメモリ２７、ＭＣＵ２５のＲＡＭメモリ２５Ａ、または、ＤＳＰ３１のＲＡＭメモリ３１Ａのいずれかのメモリに記憶される。デバイスのメモリ内の暗号化されたタイトルキー（Ｋ_t ）を記憶することにより、セキュリティが保護されたカードの記憶領域４７にアクセスする必要がなくなる。これは重要なことである。なぜなら、そうすることによって、読出し毎に保護領域４７にアクセスする場合と比較して少なからぬ時間と処理能力の節減が行われるからである。このことについては図９を参照しながら後程解説する。ＬＣＭ６３内の一連の暗号化モジュール７５、７７、７９およびメモリカード６１のモジュール８１によりタイトルキーＫ_t とコピー制御情報ＣＣＩとが暗号化される。一意的メディアキーＫ_muはモジュール７７により使用される。認証キー交換（ＡＫＥ）モジュール８３は、一意的メディアキーＫ_muがモジュール５９’により計算された形でカード６１の隠された領域４５に記憶されたとき、一意的メディアキーＫ_muを合成して、モジュール７９と８１の各々が使用するセッションキーＫ_s を作成する。記録された暗号化コンテンツを解読できるようにするために、利用デバイス６５は、プライム記号（’）が付加して示したモジュールを除く同じ参照番号で示した対応モジュールを利用して、暗号化処理の逆の処理を行う。
【００２６】
図７は、認証、および、カードと何らかのＬＣＭまたは利用デバイス間でのキー交換（ＡＫＥ）呼掛／応答プロトコルを利用して、メモリカードの保護領域４７にアクセスする技法を示す。この認証が成功したとき、カードとその他のモジュールまたはデバイスはセキュリティが保護された共通のセッションキーＫ_s を共有することになる。前述の処理とプロトコルの追加の詳細については前に特定した４Ｃエンティティの文献を参照することにより得ることができる。
【００２７】
図８Ａと８Ｂは、前述した処理で暗号化した情報にアクセスするために、携帯用デバイスやＬＣＭ内で機能するように設計されたソフトウェアシステムの実施形態を例示する図である。サンディスク・ソフトウェア（ＳＷ１００）は、簡単に使用可能な完全なソフトウェアによるソリューションであり、ＯＥＭの音楽用プレイヤおよびレコーダの中にセキュリティが保護されたデジタル（ＳＤ）メモリカードが含まれるセキュリティ保護メディアを容易にサポートすることがこのソリューションにより可能となる。ＳＤカード１３にアクセスするために携帯用デバイス１５内に示されるＳＷ１００が用いられる。パーソナル・コンピュータのような使用許諾を受けた任意の対応モジュールにＳＷ１００をインストールすることも可能である。図８Ａで見られるように、ＳＷ１００は、その最上位のレベルで、デバイス１５（特にデバイス１５のユーザ・インタフェース）からのコールを受け取り、セキュリティが保護されたデジタルカード１３から暗号化されたコンテンツを検索し、解読されたコンテンツをデバイスへ返す。したがって、多くの複雑な処理を実行するのに簡単なコールしか必要としない。カード１３のメモリ位置に記憶された暗号化されたコンテンツを検索し、次いで、コンテンツの解読とフォーマットとを行う上記複雑な処理はＳＷ１００により処理される。
【００２８】
ＳＤメモリカードの認証領域にアクセスを行うには、前述したように、ＯＥＭが４Ｃエンティティから使用許諾を得る必要がある秘密デバイスキーの使用が要求される。ＳＤＫ ＳＷ１００ソフトウェア層の範囲内におけるこれらのキー値の保護およびこれらキー値の露出の制限は、このソフトウェアの設計時の中心的考慮事項の１つである。ＳＤメモリカードのデバイスドライバのようなセキュリティ保護メディアにより、これらの値に依存する処理の実行を可能にしながら、単一の内部モジュールの範囲内でのこれらのキー（およびセッションキーのような他の結果として生じる値）の分離が、頑丈でかつセキュリティが保護されたインタフェース方法論で達成される。再度、ＳＤメモリカードを用いて本発明を例示する。しかし、ＣＤや、カード内や遠隔地に配置された記憶デバイス内にさえ存在してもよいセキュリティが保護された他のメモリのような任意のセキュリティ保護メディアでも本発明の利用は可能である。
【００２９】
図８Ｂは、ＳＷ１００の積層構造をさらに詳細に示す図である。オーディオインタフェース１０５と、ビデオインタフェース１１０と、画像処理用インタフェース１１５とがデバイスとの通信ポイントである。これらのインタフェースにより、デバイス用の単一通信ポイントが提供され、一般にこのデバイスから単純なコマンドが受信され、それによってデバイスは、暗号化データをセキュリティ保護メディアから取得し、次いで、該データの解読と処理とを行うための複雑な処理に関与する必要がなくなる。これらの複雑な処理のすべてがＳＷ１００により処理される。再生リストの管理のような再生の構成と、アーティストの歌や種々の再生リストとアーティストの画像のような画像との相関関係もインタフェース１０５、１１０、１１５により管理される。アプリケーション・プログラミング・インタフェース（ＡＰＩ）１３０Ａはコマンド・ディスパッチャ（ＣＤ）１３０内に常駐する。ＣＤ１３０とＡＰＩ１３０Ａとにより、インタフェース１０５、１１０、１１５からコマンドが受信され、インタフェースへ情報がリレーされ、ＳＷ１００で行われる処理のすべてが編成される。上記処理には、セキュリティ保護メディアに記憶されたコンテンツの再生と記録に関連するデバイス１５の処理が含まれ、必須の暗号化、解読および圧縮アルゴリズムのすべてが上記処理に伴う。
【００３０】
ＳＤオーディオエンジン（ＳＤＡＥ）１４０、ＳＤビデオエンジン（ＳＤＶＥ）１５０、ＳＤ画像エンジン（ＳＤＩＥ）１６０は、ＣＤ１３０からの命令の受信時にセキュリティ保護メディアに常駐するオーディオ、ビデオおよび画像コンテンツをそれぞれ処理する。これは、ＳＤＡＥ１４０が、ＡＡＣ、ＷＭＡ、ＭＰ３のようなオーディオ用の周知のフォーマットのいずれをも処理できることを意味する。同様に、ＳＤＶＥ１５０は、ウィンドウズ・メディア・ファイルや、リアル・ネットワーク・ファイルＭＰＥＧや、他の任意の周知のタイプのビデオファイルのようなビデオクリップ用の周知のフォーマットのいずれをも処理可能である。最終的に、ＳＤＩＥ１６０は、ＴＩＦ、ＧＩＦ、ＪＰＥＧ、ビットマップなどの周知のタイプのいずれの画像ファイルでも処理することができる。各インタフェースはセキュリティが保護されたＡＰＩ（ＳＡＰＩ）と、セキュリティが保護されていないＡＰＩ（ＮＳＡＰＩ）とを備える。処理されたコンテンツは暗号化されていても、暗号化されていなくてもよい。暗号化されたコンテンツはＳＡＰＩ１４０Ａ、１５０Ａ、１６０Ａを介してアクセスされる。これらのＳＡＰＩはサンディスク・セキュリティ・マネージャ（ＳＳＭ）１８０と交信する。セキュリティが保護されたコンテンツと関係するすべてのコマンドがＳＳＭ１８０を通じて導かれる。セキュリティが保護されたデジタルセキュリティ・エンジン（ＳＤＳＥ）１７５については後程さらに詳細に説明するが、このエンジンによってすべての暗号化処理と解読処理とが行われる。メディアの認証とコンテンツの解読とに使用されるキーがＳＤＳＥ１７５内に含まれ、ＳＤＳＥ１７５により独占的に処理される。カードに常駐する未暗号化コンテンツはＮＳＡＰＩ１４０Ｂ、１５０Ｂ、１６０Ｂを介してアクセスされる。これらのＮＳＡＰＩは、メディアの未暗号化コンテンツにアクセスするために、セキュリティが保護されていないファイルインタフェース（ＮＳＦＩ）１７０と交信する。
【００３１】
記憶メディアにおけるデータの読出しまたは書込みを目的として、ＮＳＦＩ１７０とＳＤＳＥ１７５とはデバイスドライバ１９０と交信する。ＳＤカードの例でのデバイスドライバ１９０は、ＳＤカード１３のデバイスインタフェース３９の接点間を往来する信号を管理し、駆動する。デバイスドライバ１９０は、種々のデバイスまたはメディアの専用のタイプのデバイスインタフェース３９に合わせて特製される。メモリカードデバイスの場合、ドライバ１９０は、デバイス１５に配置されている接点間を往来する信号を管理し、駆動する。光学メディアの場合には、デバイスドライバ１９０は、光ピックアップユニットを備えた種々のハードウェア・コンポーネントから出される信号を管理し、駆動することができる。上記とは別に、ハードディスク・ドライブ（ＨＤＤ）の場合、デバイスドライバ１９０により必要なＨＤＤ信号の管理と駆動とが行われる。デバイスドライバ１９０には、セキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａと、セキュリティが保護されていないデバイスドライバ・インタフェース（ＮＳＤＤＩ）１９０Ｂとが含まれる。ＳＤＤＩ１９０ＡとＮＳＤＤＩ１９０Ｂとは、デバイスドライバ１９０内で互いに分離される。ＳＤＤＩ１９０ＡがＳＤＳＥ１７５と独占的に交信するのに対して、ＮＳＤＤＩ１９０ＢはＮＳＦＩ１７０と独占的に交信する。
【００３２】
デバイスキーおよびＳＤ−オーディオセキュリティ方式にとって必要なその他の値が、制限されたセキュリティソフトウェア・モジュールであるＳＤセキュリティ・エンジン（ＳＤＳＥ）１７５内に収納される。これらの値の全ての操作はこのモジュールだけに限られている。値が出入りして、ＳＤＳＥ１７５の上位に在るソフトウェア層へ渡されることは決してない。これらのキーを含むセキュリティ・サービスに対する全ての要求はこのセキュリティ・モジュールを遮蔽しているＳＳＭ１８０により制御され、モニタされる。このセキュリティ・モジュールの下で、ＳＤメモリカード・デバイスドライバ１９０がセキュリティ・アクセスを実行する。これらのドライバサービスに対する要求は、秘密のドライバセキュリティ・インタフェースであるセキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａを介して行われるが、このインタフェースはセキュリティ・モジュールにしか認知されない。ＳＤＳＥ１７５はこのインタフェース１９０Ａを用いて、Ｇｅｔ Ｍｅｄｉａ Ｋｅｙ Ｂｌｏｃｋ（ＭＫＢ）のような特別のセキュリティコマンドを実行する。セキュリティが保護されていないデバイスドライバ・インタフェース（ＮＳＤＤＩ）１９０Ｂもデバイスドライバ１９０を利用して、カード１３のユーザ領域４１内の任意の暗号化されていないファイルにアクセスする。
【００３３】
ＳＷ１００のアーキテクチャのセキュリティはこのアーキテクチャのキーのセキュリティの中に常駐する。秘密の“ソフトキー”はセキュリティが保護された一時領域に長時間記憶されることはない。なぜなら、長時間の記憶を行うことにより、上記キーを漏洩し、したがって、暗号化されたコンテンツを漏洩する可能性が高くなるからである。ＳＷ１００では、ＳＤＳＥ１７５内で必要なキー（または“ソフトキー”）を動的に作成し、当該専用キーの必要性が当面存在しなければ、当該キーを削除する方式が利用されている。
【００３４】
次に、ＳＷ１００の処理についてさらに詳細に説明する。ＳＷ１００、特に、コマンド・ディスパッチャ１３０／ＡＰＩ１３０Ａは、一定の機能を実行するためにコールすることができる複数のＡＰＩルーチンを有する。多くのルーチンが存在するが、デバイス１５が外からアクセスするのはそれらのルーチンのうちの２２個のルーチンである。これらのルーチンは、コマンドとも呼ばれるコールによりアクセスされる。メモリカード（または別のメディア）１３内のコンテンツの検索を目的として、デバイスは上記２２個のコールのうちの１つを送るだけで十分であり、それによってコンテンツの検索、および、必要な場合には解読並びに復号化が行われる。例えば、オーディオの場合には、デバイスは“再生（play）”コールを送るだけで十分であり、それによって音楽がスタートする。
【００３５】
以下にリストするＡＰＩによりセキュリティが保護されたデジタル（ＳＤ）規格に準拠するデバイスとのインタフェースが可能となる。本発明の実施構成がＳＤ規格の場合について例示されてはいるが、本発明は多くの異なる規格の場合について利用可能である。
表１ ＡＰＩルーチン／コール

【００３６】
デバイス１５によるコールが可能な主要ＡＰＩルーチンについて以下詳細に説明する。図８Ａ〜図８Ｅを参照する。
【００３７】
図８Ｃで見ることができるように、予備再生処理８０５と再生処理８１０とが存在する。図８Ｃの処理中、図８Ｅのブロックが形成される。デバイス１５のユーザ・インタフェースによりコールされた場合、関連するＡＰＩモジュールが実行される。オーディオ再生の場合、図８Ｂで見られるように、デバイス１５のユーザ・インタフェースは上記モジュールへのコールをオーディオ・インタフェース１０５へ送る。フローチャートにリストされている機能を実行する一次コール／モジュールが右側に示されている。これらのモジュールの多くは、内部および外部でアクセスされる別のモジュールを実行するが、上記リストは網羅的であることを意図するものではなく、前述の参照により援用された、本願の一部を形成するコンパクトディスクのソフトウェアコードの１つのリファレンスであることを意図するものである。さらなる詳細については上記ソフトウェアコードを参照されたい。
【００３８】
ステップ８０３で、デバイスはまずパワー・アップされ、次いで、予備再生処理８０５が始まる。この予備再生処理には、パワー・アップの初期設定段８０５．１０と、オーディオコンテンツの初期設定段８０５．２０との２つの主要な段が含まれる。図８Ｄを参照しながらオーディオコンテンツの初期設定段についてさらに詳細に説明する。
【００３９】
一般的に言えば、予備再生処理８０５で、デバイスとメディアの初期設定が行われ、メディアから一定情報が読出され、この情報はデバイス１５のＲＡＭメモリのバッファに記憶される。前に図２で見たように、このＲＡＭメモリは、システムメモリ２７、ＤＳＰ３１のＲＡＭメモリ３１ＡまたはＭＣＵ２５のＲＡＭメモリ２５Ａのいずれかであってもよい。ステップ８０５Ａで、ＳＷ１００はメディアのドライブ番号を取得する。あるアプリケーションでは、デバイス１５がアクセスする２以上のメモリカードまたはディスクが存在する場合もある。このステップでは、上記デバイスが、ドライブの各々のコンテンツに正しくアクセスできるようにすべてのドライブ番号を取得する。これは、ＡＰＩルーチン（ＳｄＩｎｉｔＡｕｄｉｏＳｙｓｔｅｍ）を用いて行われ、デバイス１５がコールするか、ＳＷ１００が予備再生ルーチンの一部として内部でコールするかのいずれかが可能である。次いで、ＳＷ１００はＳＷ１００内でＳＳＭ１８０とＳＤＳＥ１７５の初期設定を行う。メディアからのいずれの暗号化されたキーとコンテンツの処理前にもこの初期設定が必要である。ＳＷ１００によってカード１３内の再生リストとトラックマネージャの初期設定も行われる。
【００４０】
ステップ８０５Ｂで、ＳＷ１００はメディアの初期設定と検証とを行う。ここに例示するＳＤカードの場合、図５〜図７のＭＫＢ処理が実行される。このＭＫＢ処理はステップ８０５Ａの間にも実行可能であり、前に実行されていれば、ステップ８０５Ｂで再度実行されることはない。この処理のさらなる詳細については、図５〜図７、並びに、参照により援用されている前述した４Ｃの文献を参照されたい。この処理について図１０を参照しながらさらに詳細に解説する。ステップ８０５Ｂで、メディア情報値がカード１３からコピーされ、デバイス１３のＲＡＭメモリ内の図８Ｅのメディア情報ブロック８５０の位置に記憶される。これは、ＡＰＩルーチン（ＳｄＭｏｕｎｔＡｕｄｉｏ）を用いて行われ、デバイス１５がコールするか、ＳＷ１００が予備再生ルーチンの一部として内部でコールするかのいずれかが可能である。したがって、再生リスト一般情報（ｐＴＧＩｎｆｏ）、メディアの有効番号（ＳａｎＤｉｓｋ）、ドライブ番号（ｄｒｉｖｅｎｕｍ）、メディアのセキュリティ・システム（ｓｅｃｕｒｉｔｙ）、メディアの装着状態（ｍｏｕｎｔｅｄ）の値が、これらの値のそれぞれの位置の中へ入力される。次いで、任意のＡＰＩコール番号によりこれらの位置がコールされると、カード１３から読出す必要なく、デバイス１５のＲＡＭからこれらの位置をその後読出すことが可能となる。
【００４１】
パワー・アップの初期設定８０５．１０の完了後、オーディオコンテンツの初期設定８０５．２０が始まる。一般的に言えば、オーディオコンテンツの初期設定８０５．２０中、個々のトラックおよび複数のオーディオトラック（再生リスト）の暗号化されたオーディオコンテンツの位置並びに順序を指定する情報がカード（または他のメディア）１３からデバイス１５のＲＡＭ内の小さなバッファの中へコピーされる。したがって、図８Ｅのブロックに示すこの情報は、デバイス内で迅速かつ容易にアクセス可能であり、カード１３から常に読出したり、後続の再生処理８１０中カード１３へ更新したりする必要はない。
【００４２】
図８Ｄを参照しながら、オーディオコンテンツの初期設定段８０５．２０についてさらに詳細に説明する。この段は、メモリカード（または他のメディア）１３の暗号化されたコンテンツに対してローカルなロードマップすなわちディレクトリとして機能する複数の構造を形成する。
【００４３】
ステップ８０５Ｃで、デバイス１５はＡＰＩモジュール（ＳｄＧｅｔＰｌａｙＬｉｓｔＣｏｕｎｔ）をコールする。このコール、および、以下のコールのすべては、一般に、デバイス１５のユーザ・インタフェースのソフトウェアからＳＷ１００のインタフェース・モジュールのうちの１つへ送られる。オーディオ再生を示すこの例図では、コールはユーザ・インタフェースからオーディオ・インタフェース１０５へ送られる。ビデオ再生の場合、コールは、ビデオ・インタフェース１１０へ送られ、画像再生の場合には、コールは、画像処理用インタフェース１１５へ送られる。次いで、このコールは、ＡＰＩ１３０Ａ内のＡＰＩモジュールを含むコマンド・ディスパッチャ１３０へリレーされる。
【００４４】
ステップ８０５Ｄで、ＳｄＧｅｔＰｌａｙＬｉｓｔＣｏｕｎｔは、カード１３からデバイス１５のＲＡＭメモリの中へ情報をコピーすることにより再生リスト情報ブロック８６０に関連する値を入力する。ＳｄＧｅｔＰｌａｙＬｉｓｔＣｏｕｎｔは、メディア情報ブロック８５０を参照することによりアクセス権限が与えられた適切なドライブを選択する。アクセス権限が与えられたすべてのドライブの再生リストの総数がデバイス１５のＲＡＭの中へコピーされる。
【００４５】
ステップ８０５Ｅで、デバイス１５はＡＰＩモジュール（ＳｄＧｅｔＰｌａｙＬｉｓｔ）をコールする。
【００４６】
ステップ８０５Ｆで、ＳｄＧｅｔＰｌａｙｌｉｓｔは、カード１３からデバイス１５のＲＡＭメモリの中へ情報をコピーすることにより再生リスト情報ブロック８６０に関連する値を入力する。ＳｄＧｅｔＰｌａｙｌｉｓｔは、メディア情報ブロック８５０を参照することにより再生リスト情報が常駐するアクセス権限が与えられた適切なドライブを選択する。ミリ秒で表される選択されたまたはデフォルトの再生リストの総再生時間（ｐＬｉｓｔＴｉｍｅ）、再生リスト内のトラック数（ｔｒａｃｋｓＩｎＰｌｉｓｔ）、現在の再生リストに対応するインデックス番号（ｉｎｄｅｘ）、再生リスト名ストリング長（Ｌｅｎｇｔｈ）、再生リスト名（ｐＬｉｓｔＮａｍｅ）が再生リスト情報ブロック８６０のこれらの情報のそれぞれの位置の中へ入力される。
【００４７】
ステップ８０５Ｇで、デバイス１５はＡＰＩモジュール（ＳｄＧｅｔＴｒａｃｋＩｎｆｏ）をコールする。
【００４８】
ステップ８０５Ｈで、ＳｄＧｅｔＴｒａｃｋＩｎｆｏは、カード１３からデバイス１５のＲＡＭの中へ情報をコピーすることによりトラック情報ブロック８７０に関連する値を入力する。ＳｄＧｅｔＴｒａｃｋＩｎｆｏは、メディア情報ブロック８５０を参照することにより再生リスト情報が常駐するアクセス権限が与えられた適切なドライブを選択する。ＳｄＧｅｔＴｒａｃｋＩｎｆｏは、再生リスト情報ブロック８６０を参照することにより各再生リスト内でトラックを選択する。トラック内の関連するトラックユニット（“ＴＫＩ”）を含むミリ秒で表される総トラックタイム（ｔｒａｃｋＴｉｍｅ）と、バイトで表される関連するＴＫＩを含む総トラックサイズ（ｂｙｔｅｓｉｚｅ）と、トラック内のトラックユニット数（ｔｋｉｓＩｎＴｒａｃｋ）と、トラック番号（ｔｒａｃｋｎｕｍ）と、現在のトラックに対応するインデックス（ｉｎｄｅｘ）と、メディアからのトラック情報（ｔｒｋＩｎｆｏｒｍａｔｉｏｎ）とがこれらの情報のそれぞれの位置の中へ入力される。
【００４９】
ステップ８０５Ｉで、デバイス１５はＡＰＩモジュール（ＳｄＯｐｅｎＴｒａｃｋ）をコールする。
【００５０】
ステップ８０５Ｊで、ＳｄＯｐｅｎＴｒａｃｋは、カード１３からデバイス１５のＲＡＭの中へ情報をコピーすることによりトラック一般情報ブロック８８０に関連する値のいくつかを入力する。ＳｄＯｐｅｎＴｒａｃｋは、メディア情報ブロック８５０を参照することにより適切なドライブを選択し、次いで、再生リスト情報ブロック８６０とトラック情報ブロック８７０と、ミリ秒で表される再生リストの総再生時間（ｐＬｉｓｔＴｉｍｅ）と、現在の再生リスト番号（ｐｌｉｓｔｎｕｍ）と、再生対象のトラック番号（ｔｒａｃｋｎｕｍ）と、トラックの第１のＡＯＢブロック（ｆｉｒｓｔＡＯＢ）と、解読されている現在のＡＯＢ（ｃｕｒｒｅｎｔＡＯＢ）とを参照することにより、適切な再生リストとトラックの範囲内でのトラックを選択する。
【００５１】
ステップ８０５Ｋで、ＳｄＯｐｅｎＴｒａｃｋは、カード１３からデバイス１５のＲＡＭの中へ情報をコピーすることによりトラックインデックス情報ブロック８７５にデータを入力する。ＳｄＯｐｅｎＴｒａｃｋは、メディア情報ブロック８５０と再生リスト情報ブロック８６０とを参照することにより再生リスト情報が常駐するアクセス権限が与えられたドライブを選択し、再生リスト情報ブロック８６０とトラック情報ブロック８７０とを参照することにより適切な再生リスト内の適切なトラックを選択する。
【００５２】
ステップ８０５Ｌで、トラック情報ブロック８７０を形成した後、ＳｄＯｐｅｎＴｒａｃｋは、カード１３からデバイス１５のＲＡＭの中へ情報をコピーすることによりトラック一般情報ブロック８８０の残りの値を入力する。以下の値が、ブロック８８０のこれら値のそれぞれの位置の中へ入力される。これら値は、メディアの検証番号（ＳａｎＤｉｓｋ）、処理コマンド（ＣＭＤ）、ＭＰ３、ＡＡＣまたはＷＭＡのようなオーディオ用フォーマット（ａｕｄｉｏｆｏｒｍａｔ）、コーデック用サンプリング周波数（ｓａｍｐｆｒｅｑ）、音楽、ブック画像などのアプリケーション属性（ａｐｐＡｔｒｉｂ）、バイトで表されるオーディオ・オブジェクトのサイズ（ｓｉｚｅＡＯＢ）、トラック用の最後のＡＯＢブロック（ｌａｓｔＡＯＢ）、トラック用ＡＯＢの総数（ｃｏｕｎｔＡＯＢ）、ヘッダとしても知られるＡＯＢ内での同期位置の現在位置（ｓｙｎｃｗｏｒｄ）、ＡＯＢ内での検索位置（ｓｅｅｋｐｏｓＡＯＢ）、ミリ秒で表されるトラックの経過時間（ｔｒｋＥｌａｐｓｅｄＴｉｍｅ）、ミリ秒で表されるトラックの総再生時間（ｔｒｋＴｏｔａｌＴｉｍｅ）、関連するトラックユニットを含むバイトで表される総トラックサイズ（ｂｙｔｅｓｉｚｅ）、ミリ秒で表される各エレメントの再生時間（ｅｌｅｍｅｎｔｐｌａｙｔｉｍｅ）、順方向シークタイム（ｆｗＴｉｍｅ）、次のトラックまでの時間（ｆｗＮｅｘｔ）、再生リスト内のトラック数（ｔｒａｃｋｓＩｎＰｌｉｓｔ）、現在のエレメントのサイズ（ｅｌｅｍｅｎｔｓｉｚｅ）、現在のエレメント内のオフセット値（ｅｌｅｍｅｎｔ ｏｆｆｓｅｔ）、ＡＯＢ内の現在のエレメント（ｃｕｒｒｅｎｔｅｌｅｍｅｎｔ）、ＡＯＢ内のエレメントの総数（ｔｏｔａｌｅｌｅｍｅｎｔｓ）、ＡＯＢのファイル処理（ｆｄＡＯＢ）である。本発明の異なる実施形態では、ステップ８０５Ｊによりトラック一般情報ブロック８８０の値が完全に入力され、ステップ８０５Ｋは不要となる。トラックインデックス情報ブロック８７５はトラック一般情報ブロック８８０のサブセットであり、スペースと処理時間との節減を行うように設計される。情報を閲覧する場合にデバイス１５のユーザ・インタフェースは、トラックインデックス情報ブロック８７５の参照を意図する。一旦ユーザ・インタフェースが再生用として特定のトラックを選択すると、ブロック８７５の中に含まれるサブセット情報を含めて、トラック一般情報ブロック８８０が入力される。
【００５３】
ＳｄＯｐｅｎＴｒａｃｋは、デバイス１５によりコールされるか、ＳＷ１００が予備再生ルーチンの一部として内部でコールされるかのいずれかが可能となる。
【００５４】
上記ブロック、並びに、デバイスのメモリに含まれる上記ブロックについての情報を持つことは利点である。なぜなら、再生処理時に何らかの故障が生じた場合、メディアをリセットする（すなわちパワー・アップの初期設定８０５．１０のステップ８０５Ａまたは８０５Ｂを実行する）必要がないからである。また、カード１３からの再生に必要な情報を読出す必要がなくなることが一般に望ましい。上記ブロック内の情報を用いて次のコンテンツ（オーディオ、ビデオなど）フレームへのアクセスが可能である。なぜなら、ブロック８５０、８６０、８７０、８７５、８８０内の情報が、次のフレームに含まれるコンテンツへのポインタとして用いられるからである。図８Ｅのブロックは、上記ファイルとエレメントとフレームのメモリカード１３内での配置を詳述する図であり、図３Ｃに関して前述したようなオーディオまたはビデオトラックがメモリカード１３内に配置される。
【００５５】
ステップ８０５の予備再生処理は、複数回のコール（表１で括弧内の数はコール回数を示す）によりトリガーが可能である。図８Ｃで見られるように、オーディオコンテンツの初期設定８０５．２０をトリガーする外部からのコールは、ＳｄＯｐｅｎＴｒａｃｋ、ＳｄＧｅｔＰｌａｙｌｉｓｔＣｏｕｎｔ、ＳｄＧｅｔＰｌａｙｌｉｓｔおよびＳｄＧｅｔＴｒａｃｋＩｎｆｏである。ＳｄＯｐｅｎＴｒａｃｋ（１０）は、ＳｄＮｅｘｔＴｒａｃｋ（１２）、ＳｄＳｔｏｐＰｌａｙ（１３）およびＳｄＲｅｓｅｔＰｌａｙｌｉｓｔ（１６）により内部でコールされる。ＡＰＩモジュール（ＳｄＧｅｔＰｌａｙｌｉｓｔＣｏｕｎｔ、ＳｄＧｅｔＰｌａｙｌｉｓｔおよびＳｄＧｅｔＴｒａｃｋＩｎｆｏ）も、ＳｄＯｐｅｎＴｒａｃｋにより内部でのコールが可能である。一般に、トラックタイムの表示、巻き戻し、早送り、再生リストの変更、グラフィック・ユーザ・インタフェースの表示の変更あるいはトラックの削除のようなデバイス機能と関連してデバイス１５によりコールされる。一旦予備再生処理８０５が完了すると、再生処理８１０の開始が可能となる。
【００５６】
再生処理８１０の際に、図８Ｂのオーディオ・インタフェース１０５、ビデオ・インタフェース１１０または画像処理用インタフェース１１５により、１以上のオーディオまたはビデオトラックの再生の開始、停止または休止を行うコールがステップ８１０Ａで受信される。これらのコールは、図８Ｃの再生処理８１０の隣りに示されており、ＳｄＰｌａｙＴｒａｃｋ、ＳｄＮｅｘｔＴｒａｃｋ、ＳｄＳｔｏｐＰｌａｙ、ＳｄＰａｕｓｅＴｒａｃｋ、ＳｄＲｅｓｕｍｅＴｒａｃｋ、ＳｄＲｅｓｅｔＰｌａｙＬｉｓｔ、ＳｄＦｏｒｗａｒｄ、ＳｄＡｄｄＴｋＩｔｏＰＬＭ、ＳｄＤｅｌＴＫＩｔｏＰＬＭ、ＳｄＤｅｌＴＫＩｔｏＴＭＧ、ＳｄＣｏｎｖｅｒｔＭＰ３ＴｏＳＡ１およびＳｄＣｏｎｖｅｒｔＡＡＣＴｏＳＡ１である。
【００５７】
内部でコールされる場合あるいはデバイスによりコールされる場合のいずれの場合でも、いくつのＡＰＩモジュールが実行されるかにかかわらず、２つの一次モジュールがオーディオトラックの再生には常時必要となる。これらのモジュールはＳｄＯｐｅｎＴｒａｃｋ（１０）とＳｄＰｌａｙＴｒａｃｋ（１１）である。メモリカード１３のクラスタのメモリ位置における暗号化されたコンテンツにアクセスするために、ＳｄＯｐｅｎＴｒａｃｋ（１０）とＳｄＰｌａｙＴｒａｃｋ（１１）とはトラック一般情報ブロック８８０で情報を読出す。
【００５８】
ＳｄＯｐｅｎＴｒａｃｋ（１０）は、ＳｄＮｅｘｔＴｒａｃｋ（１２）、ＳｄＳｔｏｐＰｌａｙ（１３）、ＳｄＲｅｓｅｔＰｌａｙｌｉｓｔ（１６）により内部でコールされる。一般に、ＳｄＯｐｅｎＴｒａｃｋ（１０）は、トラックタイムの表示、巻き戻し、早送り、再生リストの変更、グラフィック・ユーザ・インタフェースの表示の変更あるいはトラックの削除のようなデバイス機能と関連してデバイス１５によりコールされる。
【００５９】
ＳｄＰｌａｙＴｒａｃｋ（１１）は、音楽またはビデオトラックを再生する核心となるＡＰＩである。ＳｄＰｌａｙＴｒａｃｋ（１１）は、ユーザが現在のトラック、次のトラックの再生を望む場合や、ユーザがトラック内で巻き戻しや早送りを望む対象デバイスにより一般に使用される。ＳｄＰｌａｙＴｒａｃｋ（１１）は、ＳｄＮｅｘｔＴｒａｃｋ（１２）、ＳｄＲｅｓｕｍｅＴｒａｃｋ（１５）、ＳｄＦｏｒｗａｒｄ（１７）のような別のＡＰＩによりコールされる。ＳｄＰｌａｙＴｒａｃｋは、選択トラック用ＡＯＢを見つけ、オーディオ用フォーマット（ＭＰ３、ＡＡＣまたはＷＭＡなど）をチェックし、トラックの復号化を行う。
【００６０】
図８Ｂ、９、１０を参照しながら、暗号化されたトラックの再生（図８Ｃのステップ８１０Ｂ）について以下説明する。
【００６１】
暗号化されたコンテンツが所望のものであれば、ＯＥＭの４Ｃから使用許諾を受けた使用デバイスキーを必要とするコマンドがデバイス１５とＳＷ１００から／デバイス１５とＳＷ１００へ出される。これらのキーの全ての処理は、ＳＳＭ１８０の下に収納されるＳＤＳＥ１７５モジュールだけに限定されている。セキュリティが保護されていないコンテンツあるいは未暗号化コンテンツが要求された場合、ＮＳＦＩ１７０とＮＳＡＰＩの１４０Ｂ、１５０Ｂ、１６０ＢおよびＮＳＤＤ１９０Ｂがコンテンツにアクセスする。
【００６２】
ＳＳＭ１８０は、セキュリティ・サービスに対する要求を受け取ると、ＳＤＳＥ１７５内のｐｒｏｃｅｓｓ＿ｓｅｃｕｒｉｔｙファンクションへコマンド要求パケットを渡すことによりこの要求を実行する。キー値が上記要求パケット内に含まれることは決してない。あるいはキー値がＳＤＳＥ１７５の上に在るソフトウェア層で露出されることも決してない。
【００６３】
ＳＤＳＥ１７５がデバイスキーを内部で必要とする場合、デバイスキーはファンクションコールを介して検索され、該キーはＯＥＭにより供給されるライブラリの中へ入れられる。ＳＤＳＥ１７５のライブラリ（ｓｅｃｕｒｉｔｙ．ｌｉｂ）には、解読されたキーがシステムのセキュリティが保護された領域に常駐する時間を短縮するように設計された以下のＡＰＩが含まれる。
１）ＳＥＣ＿ＡＫＥ ＡＰＩ
２）ＳＥＣ＿ＥＮＣ＿ＴＫＥＹ ＡＰＩ
３）ＳＥＣ＿ＤＥＣ＿ＴＫＥＹ ＡＰＩ
４）ＳＥＣ＿ＧＥＴＣＣＩ ＡＰＩ
５）ＳＥＣ＿ＵＰＤＡＴＥＣＣＩ ＡＰＩ
【００６４】
ＳＷ１００の機能と構造は本願明細書に記載されているが、さらに詳細には、上記ＡＰＩ１〜５の機能が図９のフローチャートに示されている。ＡＰＩは、その対応する実行機能の隣に示されている。これらのＡＰＩ並びにＳＷ１００のすべての実行についてのさらなる詳細は本願の添付書類で提出したソースコードで見ることができる。
【００６５】
デバイスキーは、一旦取得されると、ＳＤメモリカードから得られるメディアキー・ブロック（ＭＫＢ）と合成されて、“メディアキー”が形成される。この値はＳＤＳＥ１７５内に保持され、後続の要求を処理する際に利用される。しかし、“一意的メディアキー”（Ｋ_mu）がＳＤＳＥ１７５の内部に保持されることは決してないことに留意されたい。この値はすべてのセキュリティ・アクセスの基となる値であり、セキュリティ上の特別の予防策としてリアルタイム・ベースで常に計算され（かつ決してキャッシュされることはない）。ＳＤＳＥ１７５内でのキー処理の詳細な説明を以下続ける。
【００６６】
暗号化処理は、一般的用語で言えば、セキュリティ保護メディアに配置されているコンテンツの不法コピーを止めさせるように設計される。本発明にはこの暗号化処理を行う多くの局面が存在する。まず、例えば歌などのファイル全体が直ちに解読され、このファイル全体が危険に曝される可能性があるメモリの中へ記憶されることは決してない。携帯用デバイスによりバッファが割り当てられ、ＳＤＳＥ１７５により暗号化されたコンテンツのチャンクが一度に読出されて、これらのチャンクの解読が行われ、次いで、ファイルが終了するまで同じバッファ上に何度も書込みが行われる。
【００６７】
図６と図７で見られたように、一意的メディアキー（Ｋ_mu）とタイトルキー（Ｋ_t ）とはコンテンツの解読に最終的に用いられるキーである。このタイトルキーを保護する多くの方法がある。１つの方法として、デバイス１５の非常に良くセキュリティが保護された領域にキーを記憶する方法があり、別の方法として、暗号化されたバッファを読出し、解読する度に、カード１３の保護領域４７からタイトルキーを読出す方法がある。図９はこの好ましい方法を描くフローチャートである。
【００６８】
図９に戻ると、ステップ２０５で、図４で見られるような６４キロバイトのＭＫＢ画像が読出されて、図６に見られるようなメディアキー（Ｋ_m ）が処理され、一意的メディアキー（Ｋ_mu）が作成される。このステップがさらに詳細に図１０に示されているが、これについては後程説明する。デバイスとメディアとの相互認証がステップ２０５で完了した後、ＡＫＥ処理にかけられ、セッションキー（Ｋ_s ）が作成される。このセッションキーは、ステップ２１０で、（デバイスのスイッチが入っている限り、あるいは、デバイスが活動状態にある限り）当該セッションの間でしか使用することはできない。再度図６を参照することによりＡＫＥ処理を理解することができる。ステップ２１３で、一意的メディアキー（Ｋ_mu）は削除される。ステップ２１５で、セッションキー（Ｋ_s ）は、メモリカード１３の保護領域４７に記憶された２重暗号化タイトルキーＥ（Ｅ（Ｋ_t ））の解読に用いられる。その結果は単独に暗号化されたタイトルキー（Ｅ（Ｋ_t ））となる。ステップ２２０で、この暗号化されたタイトルキー（Ｅ（Ｋ_t ））はデバイス１５のメモリに記憶される。このタイトルキー（Ｅ（Ｋ_t ））は、システムメモリ２７、ＭＣＵ２５のＲＡＭメモリ２５Ａ、またはＤＳＰ３１のＲＡＭメモリ３１Ａに記憶されたものであってもよい。このタイトルキーＫ_t は、オーディオの領域ではトラックと呼ばれている各タイトルのための専用のキーであり、本発明を例示するために図９で使用される。各トラックは、例えば、長い古典的な歌などの場合には複数のファイルからつくられたものであってもよい。大きなビデオクリップの場合、タイトルの中に多くのファイルが含まれる場合がある。したがって、トラックの暗号化されたコンテンツのすべての後続する読出しと解読の場合、メモリカードからタイトルキーの検索を行う必要がなくなる。なぜなら、タイトルキーはローカル・メモリに記憶されており、貴重な時間と計算リソースの節減が可能であるが、同時に、このタイトルキーはセキュリティを保護することを目的として暗号化されたままとなっているからである。
【００６９】
ステップ２２５でトラックの一部が再生される。この部分はトラックを含むファイルのいずれであってもよい。ステップ２２５ａで、一意的メディアキー（Ｋ_mu）が再計算される。ステップ２２５ｂで、ローカル・メモリに記憶された暗号化タイトルキーが解読される。次いで、ステップ２２５ｃで、タイトルキーを用いて、デバイス１５のバッファから得られるコンテンツが解読されるが、上記バッファには、メモリカード１３のユーザ領域４１から得たコンテンツが含まれている。バッファが解読された直後に、タイトルキーはステップ２２５ｄで削除され、一意的メディアキーがステップ２２５ｅで削除される。ステップ２２５ｄと２２５ｅの順序は重要ではないが、トラック部分の読出しにかかる時間の間、双方のキーが専ら露出されるという点が重要である。このトラック部分は、１秒の数分の１の再生（解読、解凍、復号化）コンテンツ（オーディオやその他）から、約１０秒までのコンテンツのどの部分であってもよい。好ましくは上記部分は２秒であることが望ましい。この部分の読出しにかかる時間は、デバイスの処理速度とバッファ・サイズを含む多くのファクタに依存して決められる。前述したように、ＭＣＵ２５またはＤＳＰ３１のいずれかによりＳＷ１００の実行が可能であり、さらに、デバイス１５のメモリ２７、２５Ａ、３１Ａまたは３２のうちのいずれかにＳＷ１００を記憶することが可能であり、これによって処理時間の変更が可能となる。これは、ステップ２３０で見られるように、トラックのすべての部分が読出されるまで繰り返される。一旦すべての部分が読出されると、ステップ２３５に示すように、再生を続ける場合、システムは次のトラックへ移ることができる。例えば、ユーザが再生リスト全体の再生を選択した場合にこれが当てはまるかもしれない。
【００７０】
トラックのすべての部分が読出された後、次のトラックの読出しが始まると、ステップ２１５で処理が再開され、この処理によりカード１３の保護領域４７から次の２重暗号化タイトルキーが検索される。これは、一般に、ユーザが、複数のトラックを含む再生リスト全体の再生のために動いているデバイスをセットした場合のケースである。セッションが閉じられた（すなわち、デバイス１５のスイッチがオンかオフになった）場合、新しいセッションキーを作成する必要があり、ステップ２１０で処理が始まる。メモリカードが取り外されるか、新しく挿入された場合、デバイスとメディアは再認証を受ける必要があり、トラックの読出しをするためにステップ２０５で処理が再開する。
【００７１】
図１０は、メディアキー・ブロックの処理動作（上述の図９のステップ２０５）を示す図である。図４で見たように、ＭＫＢ画像４９は長さが６４キロバイトである。画像４９全体を同時に読出して、ＭＫＢを計算することは効率的ではなく、大容量のＲＡＭと長い処理時間とを必要とする。このシステムはＲＡＭ要件の低減と、処理時間の短縮とを図るものである。ＭＫＢ画像４９はチャンク１〜１２８に分割される。各チャンクは５１２バイトであり、ＭＫＢの４つの異なるタイプのレコード、すなわち、０×８１として知られる検証用メディアキーレコード（ＶＭＫＲ）と、０×０１として知られる計算用メディアキーレコード（ＣＭＫＲ）と、０×８２として知られる条件計算用メディアキーレコード（ＣＣＭＫＲ）、または０×０２として知られる終了用メディアキーレコード（ＥＭＫＲ）のうちの１つを各チャンクが含むものであってもよい。これらのレコードについては、前に引用した４Ｃエンティティの記録可能メディア（ＣＰＲＭ）仕様のコンテンツ保護に記載されている。
【００７２】
この例では、チャンク長とバッファ長は同じである。しかし、バッファ長とチャンク長は双方とも２５６バイトから４０９６バイトまでの範囲に及ぶ場合がある。各レコードがチェックされ、そのレコードタイプに基づいて専用の処理が行われて、或るデータが保存され、このデータはメディアキーを取得するために後で使用される。レコードが識別される度にそのレコード長がバッファオフセットの全長に加算される。この全長をチャンク長で除することによりチャンク番号が計算される。このチャンク番号は、選択されたチャンクデータのメディアキー・ブロックに対するインデックスである。全長の残り部分は選択されたチャンクデータに対するオフセット値である。行と列とを用いて、暗号化されたメディアキーと条件つきの暗号化されたメディアキーとがどこにあるかが計算される。これらの暗号化キーは保存され、次いで電子コードブックモード・アルゴリズムでの解読Ｃ２暗号化が実行されてメディアキーが取得される。次いで、このメディアキーは正しい最終メディアキー（Ｋ_m ）について検証される。
【００７３】
レコード数と関連するＭＫＢからメディアキー（Ｋ_m ）を取得するのに必要な、ＭＫＢチャンク当たりの読出し回数Ｔを以下に示す。
レコード数＜Ｔ＜（レコード数^* ２）
Ｔ：ＭＫＢチャンクのアクセスに必要な回数
【００７４】
各レコードは異なる長さとデータ値とを有する。各レコードの情報は２回の読出しの範囲内で取得が可能である。４つレコードが存在するため、４〜８回の読出しがＭＫＢチャンクの処理とレコードの取得には必要となる。
したがって、読出し回数Ｔは下記のようになる。
４＜Ｔ＜８
【００７５】
５１２バイトのＭＫＢデータのアクセスにＮミリ秒かかると仮定する。第１の方法では、６４ＫのＭＫＢ画像全体にアクセスして、メディアキーを取得するのに（１２８^* Ｎ）ミリ秒かかることになる。第２の方法では、最悪のケースのシナリオとしても、メディアキーを取得するのに（８^* Ｎ）ミリ秒しかかからない。したがって、この方式を利用すると相当の時間の節減になる。平均して、メディアキー（Ｋ_m ）の取得時の読出し回数は４〜６の範囲になり、必要な時間は上に示したものよりも比例して短くなる。
【００７６】
図１０で拡大されている図９のステップ２０５は、ステップ２０５．７５で最終メディアキーが作成されるまで、あるいは、ステップ２０５．８０でメディアが拒絶されるまで実行される。メディアキーの算出のために、１２８チャンクのすべてを読出す必要はない。また、チャンク当たり５１２バイトのすべてを読出す必要もない。ＭＫＢデータの処理は、１回に１チャンクのデータを必要とし、当該特定チャンク内の所望の位置を指示し、取得した値を計算する処理である。すべてのＭＫＢデータが必要となるわけではない。図１０に描かれているアルゴリズムは、どのようなチャンクのＭＫＢデータを必要とするか、どのようなレコードを処理すべきか、どこに暗号化データが位置するかを正確に計算するための数学的計算を行うものである。
【００７７】
ステップ２０５．５で、バッファポインタがデータバッファにセットされ、バッファオフセットがクリアされる。次に、ステップ２０５．１０で、チャンク番号が最大チャンク番号以上かどうかを調べるチェックが行われる。チャンク番号が最大チャンク番号以上であれば、ステップ２０５．１５でエラーが返される。チャンク番号が最大チャンク番号未満であれば、チャンク番号は増分され、ステップ２０５．２０で新しいデータがバッファの中へロードされる。次いで、ステップ２０５．２５でバッファオフセット値が更新される。このようにして正しい位置（チャンク番号＋オフセット値）にポインタをセットすることが可能となる。ステップ２０５．３０で、バッファポインタがバッファオフセット値にセットされる。ステップ２０５．４０で、ポインタが位置するオフセット位置からバッファが読出される。次いで、システムは、どのようなタイプのレコードが読出されているかを検出する。ステップ２０５．４０に示されているように、システムは、どのようなタイプのレコードが読出されているか、および、どのようなレコード長が当該レコードと関連するかのチェックをまず行う。その後に続くアクションはレコードタイプとレコード長とに応じて異なるものとなる。各レコードのレコード長を用いて、後続レコードの読出し時にバッファポインタがどこに位置するかが決定される。これはステップ２０５．４９により反映され、バッファオフセット値の更新と新しいオフセット値でバッファポインタのセットが行われる。
【００７８】
ステップ２０５．４２に示すようにレコードがＣＭＫＲであれば、システムは、ステップ２０５．４９で、暗号化されたメディアキー（Ｋ_m ）が位置する正しいＭＫＢ位置にバッファのチャンク番号とオフセット値とを更新する。各カードは１６ＭＫＢを持つ。したがって、システムは、暗号化されたメディアキーが存在する位置でオフセット値を取得し、特定のＭＫＢチャンク番号を見つけ、バッファ（１６ブロック×５１２バイト）を割り当て、各ブロック内のオフセット値へ進み、暗号化されたメディアキーを読出すことになる。次いで、システムは、デバイス１５から供給されたデバイスキー（Ｋ_d ）を用いて、ステップ２０５．５０でメディアキーの解読（計算）を行う。一旦メディアキーが計算されると、次のステップはメディアキーの検証である。
【００７９】
レコードがステップ２０５．４４で評価されたようなＶＭＫＲであれば、ステップ２０５．５０の第１の試み、あるいは、ステップ２０５．６５の後続の試みのいずれかの試みで前回計算されたメディアキーが、ステップ２０５．５５で基準メディアキー（Ｋ_m ）と比較される。これを行うために、基準メディアキーはまずローカルに記憶される。上記キーが同じであれば、パス（１６進でＤＥＡＤＢＥＥＦ）が返され、システムはメディアキーの条件計算を行う必要がなくなる。次のレコードの読出しをどこから開始するかを計算するために、ＶＭＫＲのレコード長を用いてバッファポインタを次のレコードへ移す。上記キーが同じでなければ、ステップ２０５．４６でＣＣＭＫＲレコードが読出されたとき、メディアキーの再計算が行われる。上記ＣＣＭＫＲレコードが読出されると、バッファポイントがセットされて、ステップ２０５．４９で更新されたバッファオフセット値で読出しが行われた後、ステップ２０５．６５でメディアキーが再計算され、次いで、このメディアキーは次のＶＭＫＲが読出されるとき、続いて検証される。ＣＣＭＫＲの最大計算回数がシステムにより設定されるが、この回数は好ましくは１回であることが望ましい。
【００８０】
第１の計算はＣＭＫＲが発見されたときに行われる。ＶＭＫＲが発見されたとき、開始された検証処理中にメディアキー（Ｋ_m ）が決定された形でメディアキーの計算に成功した場合、メディアキー（Ｋ_m ）の条件計算を行う必要はなくなる。検証が不成功に終わった場合、ＣＣＭＫＲが発見されれば、メディアキー（Ｋ_m ）の再計算と再検証とが行われる。これはメディアキーを計算する２つのチャンスが存在することを意味する。最後に、上記レコードが、ステップ２０５．４８で評価されるようなＥＭＫＲであれば、ステップ２０５．７５で、システムにより、上記レコードの終端に有効なメディアキー（Ｋ_m ）が存在すること、および、ステップ２０５．４９でバッファポインタがこのタイプのレコードに対する適切なオフセット値でセットされた後、ステップ２０５．７５で最終メディアキー（Ｋ_m ）の作成が検証される。しかし、ステップ２０５．７０で有効なメディアキーが返されなければ、ステップ２０５．８０でメディアは拒絶される。最終メディアキーがステップ２０５．７０で返されれば、ステップ２０５．８５により示されているように処理は図９のステップ２１０で継続する。このようにしてＭＫＢの処理は完了する。
【００８１】
ＳＤＳＥ１７５内のファンクションは、デバイスドライバ１９０と接続するセキュリティが保護されたデバイスドライバ・インタフェース（ＳＤＤＩ）１９０Ａを用いることにより、Ｇｅｔ ＭＫＢのようなセキュリティ・アクセスを実行する。この同じデバイスドライバ（ＳＤＤＩ１９０Ａ）は、直接呼び出しが可能なＳＤＳＥ１７５内のファンクションも利用する。例えば、認証領域の読出し命令を出す前に、ＳＤＤＩ１９０Ａは、ＳＤＳＥ１７５内のｓｅｃ＿ａｋｅファンクションをまず呼び出す必要がある。次いで、ｓｅｃ＿ａｋｅファンクションはＳＤＤＩ１９０Ａの中へコールバックを行う。ＳＤＳＥ１７５内でのデバイスキーの分離を容易にするこの“デュアル呼び出し関係”は、ＳＤオーディオ規格のＳＷ１００の実施構成にユニークなものである。
【００８２】
ＳＤＳＥ１７５は、すべてのキー指向型処理を処理し、さらに、オーディオインタフェース１０５、ビデオインタフェース１１０、あるいは、画像インタフェース１１５が一定のＳＤコマンドを受信した場合、デバイスドライバは、これらの値を必要とするので、直接呼び出しが可能なＳＤＳＥ１７５内のファンクションを利用しなければならない。これらのファンクションを実行する場合、ＳＤＳＥモジュール１７５は、デバイスドライバ１９０の秘密のセキュリティ・インタフェース（ＳＤＤＩ１９０Ａ）の中へ次にコールバックを行わなければならない。この“デュアル呼び出し関係”により、ＳＤＳＥ１７５とデバイスドライバ１９０間でのない交ぜの（interwoven）要求が可能となり、これによってセキュリティ・モジュール内でキー値の分離が可能となる。
【００８３】
ＳＤＳＥ１７５ソフトウェア層は、セキュリティ・ドライバ要求パケットを開始し、要求パケットポインタを通過するセキュリティ・ドライバインタフェース・エントリポイントを呼び出すことにより、秘密のインタフェースを介してセキュリティデバイスドライバ・サービスの呼び出しを行う。
【００８４】
参照により援用されている添付のソースコードを明らかにするために、以下のテーブルが提供される。
【００８５】
要求パケット（ｓｄａｐｉ．ｈに定義される）は、以下のように定義されるデータ型ＳＳＭＳＥＲＶＥから構成される。
表２

【００８６】
コマンド・インデックス（ＩＮＴ１６ｏｐＣｏｄｅ）は、要求されたサービスに対するコマンドを保持する。サポートされるコマンドには以下が含まれる。
表３

【００８７】
セキュリティ・デバイスドライバ・サービス要求がＳＤＳＥ１７５モジュールから出される。例えば、呼掛１生成関数は以下のように呼掛１を送る。
表４−呼掛１の生成

【００８８】
すべてのキー操作はＳＤＳＥ１７５に限られているため、認証キー交換（ＡＫＥ）の実行またはバスの両端にわたって転送されるデータの解読を行うにはＳＳＤＩ１９０ＡはＳＤＳＥ１７５のファンクションに依拠しなければならない（バスの両端にわたって送られるすべてのデータは、各ＡＫＥから作成される“セッションキー”を用いてまず暗号化されることに留意されたい）。
【００８９】
ＡＫＥの実行時に、ＳＤＳＥ１７５はＳＤメモリカード１３へコマンドを送らなければならない。したがって、ＳＤＳＥ１７５はＳＤＤＩ１９０Ａの中へ次に呼び込みを行わなければならない。この呼び出し関係は、認証領域の読出し処理に必要なステップを描く図７に概略が示されている。
【００９０】
ＳＤＳＥ１７５内のｓｅｃ＿ａｋｅ関数は、セキュリティＳＤＤＩ１９０Ａにより呼び出されたとき、秘密のドライバインタフェースを介してセキュリティ・デバイスドライバの中へ４回のコールバックを行うことに留意されたい。これら４回の要求はＳＤＤＲＶ＿ＳＥＴＣＨＡＬＧＥ、ＳＤＤＲＶ＿ＧＥＴＣＨＡＬＧＥ、ＳＤＤＲＶ＿ＳＥＴＲＥＳＰ、ＳＤＤＲＶ＿ＧＥＴＲＥＳＰから構成される。これによって、図７に示すセキュリティ・モジュールによる必須の呼掛のセット／呼掛の取得、応答のセット／応答の取得ステップの実行が可能となる。この結果生じるセッションキーはセキュリティ・モジュール内に記憶される。セキュリティ・デバイスドライバが、ＳＤＤＩ１９０Ａから情報を得るために、ＳＤＳＥ１７５のｂｕｓ＿ｄｅｃｒｙｐｔファンクションの中へ呼び込まれるとき、上記セッションキーを用いてデータが解読される。
【００９１】
本発明のシステムおよび方法は多くの点で従来の技法よりも優れた利点を有する。本発明により、他社製部品組込み製品製造販売企業が記憶メディアのメモリ構造に関する知識を全く持つ必要なく暗号化されたコンテンツへのアクセスが可能となる容易なソリューションが提供される。上記解読処理自体は非常に複雑である。さらに、メモリカードやコンパクトディスクへの単なる読出しと書込みもそれ自体複雑である。製造業者が行う必要があるのは、単に“再生”または“次のトラック”のような簡単なコマンドの送信を行い、メモリデバイスがたまたまどのようなものであれ、そのメモリデバイスから解読されたコンテンツの返送を行うことだけである。
【００９２】
デバイスキーと、結果として得られるセッションキーとがはっきりと分離され、保護されたソフトウェア層の中で操作される。これらのキーは上位層の中で露出されることは決してない。低位のデバイスドライバ層でさえキーへの直接アクセスは与えられない。メディアキーの作成時に、デバイスキーはＯＥＭから供給されるライブラリから検索される。このキーはセキュリティ・エンジン内に保持されるが、このセキュリティ方式の核心部分である一意的メディアキー（Ｋ_mu）には決して記憶されない。セキュリティ・エンジンとつながる秘密のインタフェースによって、すべてのセキュリティ関連キー（例えば、デバイスキー、メディアキー、セッションキーなど）の露出をセキュリティ・エンジン内に制限して保持しながら、セキュリティ・エンジンがメモリカードへの低レベルのアクセスを得ることが可能となる。“デュアル呼び出し関係”により、セキュリティ・エンジンとセキュリティ・デバイスドライバとが相互のサービスのない交ぜの（interwoven）利用を行うことが可能となる。
【００９３】
本発明の特定の実施形態とそれらの利点について図示し、説明してきたが、添付の請求項により画定されるような本発明の精神と範囲から逸脱することなく種々の改変、代替および変更を行うことが可能であることを理解されたい。例えば、本発明の機能を例示するためにＳＤメモリカードの利用を示したが、本発明は、暗号化されたコンテンツを含むいずれのメディアに対しても利用可能である。本発明は、任意のタイプのデバイスによっても利用可能である。さらに、固定デバイスであれ、取り外し可能デバイスであれ、また、半導体素子を用いて構成されたものであれ、回転式のものであれ、任意のタイプのメモリデバイスから暗号化されたコンテンツの解読が可能である。このコンテンツはオーディオまたはビデオに限定されるものではなく、暗号化に値する任意のコンテンツであってもよい。
【図面の簡単な説明】
【図１】 セキュリティ保護メディアの読出しと書込みとを行うデバイスを示す例図である。
【図２】 セキュリティ保護メディアのアクセスに使用するデバイスの概略図である。
【図３Ａ】 セキュリティ保護メディア層の概略の例図である。
【図３Ｂ】 セキュリティ保護メディアのメモリセルの物理構造と論理構造とを示す例図である。
【図３Ｃ】 トラック構造とトラックの構成要素部分とを示す例図である。
【図４】 メディアキー・ブロック（ＭＫＢ）の構成要素のチャンクに分割されたメディアキー・ブロック画像を示す例図である。
【図５】 認証および解読処理部を示す例図である。
【図６】 認証および暗号化処理を示す例図である。
【図７】 図６に示す認証キー交換処理を示す概略図である。
【図８Ａ】 本発明のソフトウェアのブロック図である。
【図８Ｂ】 本発明のソフトウェアのモジュールを例示するブロック図である。
【図８Ｃ】 関連するＡＰＩモジュール／コールを示す本発明に基づく予備再生処理と再生処理のフローチャートの概略図である。
【図８Ｄ】 図８Ｃのオーディオコンテンツの初期設定段を拡大したフローチャートである。
【図８Ｅ】 図８Ｃの予備再生処理８０５中に形成される情報ブロックを示す例図である。
【図９】 本発明に基づくオーディオトラックの再生を示すフローチャートの概観図である。
【図１０】 図９の１ステップである、図４に示すＭＫＢ画像の処理を示すフローチャートである。

Claims (18)

1. 暗号化されたオーディオコンテンツまたはビデオコンテンツの再生用にメモリカードに常駐する、オーディオ用またはビデオ用デバイスで利用されるソフトウェアプログラムであって、
   前記デバイスのユーザ・インタフェースから再生コマンドを含むコマンドを受け取り、
   （ａ）一意的メディアキーを計算するステップと、その後、
   （ｂ）前記デバイスのメモリに記憶されたタイトルキーを前記一意的メディアキーを用いて解読するステップと、その後、
   （ｃ）トラック全体よりも少ないトラックの一部を有する１グループのフレームを解読するステップと、その後、
   （ｄ）前記解読したタイトルキーを削除するステップと、
   （ｅ）前記一意的メディアキーを削除するステップと、
   （ｆ）前記トラック全体が完了するまで（ａ）から（ｅ）を反復するステップと、を含む処理によって暗号化されたオーディオコンテンツまたはビデオコンテンツを前記メモリカードから解読するように構成されることを特徴とするソフトウェアプログラム。
2. 請求項１記載のソフトウェアプログラムにおいて、
   前記暗号化されたコンテンツの位置情報を前記オーディオ／ビデオ用デバイスのメモリの中へコピーし、
   前記オーディオ／ビデオ用デバイスのメモリから前記位置情報にアクセスし、
   前記アクセスした位置情報を用いて前記メモリカード内に前記暗号化されたコンテンツを配置するようにさらに構成されることを特徴とするソフトウェアプログラム。
3. 請求項１記載のソフトウェアプログラムにおいて、
   前記１以上の解読されたキーを削除する前に、前記１以上の解読されたキーを用いて１秒から１０秒のコンテンツを同時に解読することを特徴とするソフトウェアプログラム。
4. 請求項１記載のソフトウェアプログラムにおいて、
   前記１以上のキーを削除する前に、前記１以上の解読されたキーを用いて２秒のコンテンツを同時に解読することを特徴とするソフトウェアプログラム。
5. マイクロプロセッサとランダムアクセスメモリと前記マイクロプロセッサが実行するソフトウェアプログラムとを備えた携帯用デバイスであって、
   再生コマンドを含む１グループのコマンドを前記携帯用デバイスのユーザ・インタフェースから受信し、
   取り外し可能な記憶メディアの中に常駐する暗号化されたデータを前記コマンドの受信時に検索し、
   前記デバイスのメモリ内に前記暗号化されたデータを記憶し、
   （ａ）一意的メディアキーを計算するステップと、その後、
   （ｂ）前記デバイスのメモリに記憶されたタイトルキーを前記一意的メディアキーを用いて解読するステップと、その後、
   （ｃ）トラック全体よりも少ないトラックの一部を有する１グループのフレームを解読するステップと、その後、
   （ｄ）前記解読したタイトルキーを削除するステップと、
   （ｅ）前記一意的メディアキーを削除するステップと、
   （ｆ）前記トラック全体が完了するまで（ａ）から（ｅ）を反復するステップと、を含む処理によって前記デバイスのメモリ内に記憶された暗号化されたデータを解読し、
   前記デバイスがフラッシュメモリの読出し／書込みアルゴリズムを直接取り扱う必要がないように、解読されたオーディオコンテンツまたはビデオコンテンツを出力するように構成されることを特徴とする携帯用デバイス。
6. 請求項５記載の携帯用デバイスにおいて、
   前記デバイスのメモリに２秒の暗号化されたデータを記憶し、次いで、前記暗号化されたデータを削除する前に前記データの解読を行うことを特徴とする携帯用デバイス。
7. 請求項５記載の携帯用デバイスにおいて、
   前記取り外し可能な記憶メディアが、半導体メモリカードであることを特徴とする携帯用デバイス。
8. 請求項５記載の携帯用デバイスにおいて、
   ＡＡＣ、ＭＰ３またはＷＭＡフォーマットのいずれかのフォーマットでオーディオコンテンツを解凍し復号化するように、前記デバイスのソフトウェアをさらに構成することを特徴とする携帯用デバイス。
9. 請求項５記載の携帯用デバイスにおいて、
   前記デバイスのソフトウェアが、
   前記取り外し可能な記憶メディアから前記デバイスのメモリの中へ再生リスト情報とトラック情報とをコピーし、
   前記再生リストとトラック情報とに基づいて検索できるように、前記暗号化されたデータを前記デバイスのメモリの範囲内に配置するようにさらに構成されることを特徴とする携帯用デバイス。
10. 請求項９記載の携帯用デバイスにおいて、
    前記トラック情報が、各トラックに関連して、
    前記トラックに含まれるオーディオ・オブジェクトの数と、
    前記トラックに含まれる第１のオーディオ・オブジェクトと、
    前記トラックに含まれる最後のオーディオ・オブジェクトと、
    解読する現在のオーディオ・オブジェクトと、
    前記現在のオーディオ・オブジェクトのオフセット値と、
    を有することを特徴とする携帯用デバイス。
11. 請求項１０記載の携帯用デバイスにおいて、
    前記トラック情報が、
    バイトで表される前記トラックのサイズと、
    前記トラックの総再生時間と、
    前記オーディオ・オブジェクト内の現在のエレメント番号のトラックの経過時間と、
    再生対象トラックの現在のエレメントと、
    前記現在のエレメントのオフセット値と、
    前記オーディオ・オブジェクト内でのエレメントの総数と、
    をさらに有することを特徴とする携帯用デバイス。
12. セキュリティ保護メディアに記憶した暗号化されたオーディオコンテンツまたはビデオコンテンツをデバイスを用いて再生する方法であって、
    予備再生処理であって、
    再生対象トラックに関する１以上のグループの情報を前記デバイスのメモリの中へコピーするステップを有する予備再生処理と、
    再生処理であって、
    再生を開始するためにユーザ・インタフェースから１以上のコマンドを受け取るステップと、
    前記デバイスのメモリから前記１以上のグループの情報にアクセスするステップと、
    前記ＲＡＭメモリの中へコピーされた前記１以上のグループの情報の中から得られる情報に基づくシーケンスに従って、前記セキュリティ保護メディアから前記デバイスのメモリの中へ暗号化されたコンテンツをコピーするステップと、
    （ａ）一意的メディアキーを計算するステップと、その後、
    （ｂ）前記デバイスのメモリに記憶されたタイトルキーを前記一意的メディアキーを用いて解読するステップと、その後、
    （ｃ）トラック全体よりも少ないトラックの一部を有する１グループのフレームを解読するステップと、その後、
    （ｄ）前記解読したタイトルキーを削除するステップと、
    （ｅ）前記一意的メディアキーを削除するステップと、
    （ｆ）前記トラック全体が完了するまで（ａ）から（ｅ）を反復するステップと、を 含む処理によって前記１以上のグループの情報の中から得られる情報に基づくシーケンスで前記セキュリティ保護メディアから前記暗号化情報を解読するステップと、を有する再生処理と、
    を有することを特徴とする方法。
13. 請求項１２記載の方法において、
    １秒から５秒の前記暗号化されたコンテンツをコピーし、同時に解読することを特徴とする方法。
14. 請求項１２記載の方法において、
    前記１以上のグループの情報が、再生リストとトラック情報とを有することを特徴とする方法。
15. 請求項１２記載の方法において、
    前記１以上のグループの情報が、どの再生リストを再生すべきか、前記再生リスト内のどのトラックを再生すべきかを指定することを特徴とする方法。
16. 請求項１５記載の方法において、
    前記１以上のグループの情報が、前記トラック内のどのオーディオ・オブジェクトを再生すべきかについての情報をさらに有し、前記セキュリティ保護メディア内に前記オーディオ・オブジェクトを配置することを特徴とする方法。
17. 請求項１６記載の方法において、
    前記１以上のグループの情報が、前記オーディオ・オブジェクト内のどのエレメントを再生すべきか、前記エレメント内のどのフレームを再生すべきかについての情報をさらに有することを特徴とする方法。
18. 請求項１２記載の方法において、
    前記予備再生処理が、前記セキュリティ保護メディアを認証するステップをさらに有することを特徴とする方法。

Images