セキュアコンテンツおよびアプリケーションのコピーを防ぐセキュリティメカニズムを有するメモリカードのアップグレード
セキュアフラッシュメモリカードあるいはフラッシュドライブは、ユーザコンテンツを無許可の複写からプロテクトする。しかし、プロテクトされるユーザコンテンツであっても、１つのフラッシュカードあるいはドライブから他の１つへその正当な所有者またはライセンシーによって移すことができる。さらに、付加的な機能性をカードに付け加えるために何時でもフラッシュカードに付け加えられるセキュアファームウェアアプリケーションも、その多くは装置特有であってハードウェアの１つの特定のピースの上でだけ動作するようにも設計されているけれども、移すことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはセキュアコンテンツとコピープロテクトメカニズムとを有するメモリカードに関し、特に、アップグレードが行われる場合に他のメモリカードへのセキュアコンテンツの転送を可能にすることに関する。
【背景技術】
【０００２】
デジタルコンテンツの無許可のコピーおよび複写を防止するいろいろなプロテクトメカニズムがある。それらの多くは、しばしば、大雑把に１種のデジタル著作権管理（「ＤＲＭ」）と称され、そのようなものとして考えられている。特に複写と、装置から装置への転送とを防止するために多大の努力が行われてきている。例えば、無許可の複写などが挙げられるたぐいのものを防止するために、音楽あるいは視聴覚コンテンツをｉＰｏｄから他のｉＰｏｄへ転送することはできない。同様に、セキュアメモリカードあるいはＵＳＢフラッシュドライブ（以降、全体として「カード」と称される）において、プロテクトされるコンテンツをカードからカードへ移すことはできない。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願第１１／２８５，６００号
【特許文献２】米国特許出願第１１／３１７，３３９号
【特許文献３】米国特許出願第１１／３１７，８６２号
【特許文献４】米国特許出願第１１／３１３，４４７号
【特許文献５】米国特許出願第１１／３１３，５３６号
【特許文献６】米国特許出願第１１／３１４，０５５号
【特許文献７】米国特許出願第１１／３２２，７６６号
【特許文献８】米国特許出願第１１／３１４，０３０号
【特許文献９】米国特許出願第１１／３１９，８３５号
【発明の概要】
【０００４】
本発明の種々の実施形態は、ユーザが容量のより大きなカードへアップグレードしたい時にカードのコンテンツを同等かまたはそれ以上の容量のカードへ移すあるいは転送することを可能にする。その同等またはそれ以上の容量のカードはターゲットと称され、ターゲットは、コピープロテクトされるコンテンツをターゲットへ移す場合には、ソースと同等あるいはそれ以上のレベルのセキュリティを持っていなければならない。プロテクトされるコンテンツを移す前に、ターゲットの真正性を判定するためにいろいろな方法が使用される。カードのファームウェアおよび他のソフトウェアが、それがロードされたオリジナルカード以外のどのカードにおいても動作できないようなカードの実施形態では、この障害を本発明の実施形態が克服し、転送されたコピープロテクトされるコンテンツが復号化され得るようにそれらを新しいカードに再バインド(re-bind)する。本発明でなければ、許可されたアップグレードを除いては厳格に禁止される。
【０００５】
本発明の付加的な態様、利点および特徴は、その代表的な例についての以下の記述に含まれる。その記述は添付図面と関連して検討されるべきであり、そこでは同様の数字は、別様に明示されていない限り、図面全体にわたって同じ特徴を記述するために使われる。
【図面の簡単な説明】
【０００６】
【図１Ａ】セキュア装置１００のブロック図である。
【図１Ｂ】ホスト１５０を介して他のエンティティとネットワーク化されたセキュア装置１００の略図である。
【図２】ダイバーシフィケーションの図である。
【図３】図１Ａのメモリ１０８の図である。
【図４Ａ】ソースからターゲットへのアップグレードを示す図である。
【図４Ｂ】本発明の１つの実施形態に従ってアップグレード中にマテリアルがソースからターゲットへどのようにコピーされるかをさらに示す図である。
【図５Ａ】本発明の１つの実施形態に従うアップグレードプロトコルを示す。
【図５Ｂ】本発明の１つの実施形態に従うアップグレード状態マシンの状態を示す。
【図５Ｃ】本発明の１つの実施形態に従うアップグレードプロセスを示すフローチャートである。
【図６】本発明の１つの実施形態に従う認証プロセスを示す図である。
【発明を実施するための形態】
【０００７】
図１Ａは、セキュアシステムの一実施形態であるセキュア大容量記憶装置１００を示す。前述したように、セキュアフラッシュ大容量メモリカードまたはＵＳＢフラッシュドライブ（全体として「カード」またはセキュア装置と称される）では、プロテクトされるコンテンツは１つより多くのカードでは使用され得ない。セキュア装置（「ＳＤ」）１００は、好ましくはＮＡＮＤフラッシュ型の大容量記憶メモリ１０８と、データおよび制御線１０６を介してメモリ１０８に通信するセキュアメモリコントローラ１０４とを含む。セキュア装置は、ホストインターフェイス１０２を介してホスト１５０と通信する。セキュアメモリコントローラ１０４は、メモリ１０８への／メモリ１０８からのデータ格納およびデータ取り出しとホスト１０５への／ホスト１０５からの転送との全てを制御する。セキュアメモリコントローラ１０４（カードファームウェアと関連して）セキュリティをＳＤ１００に提供する。メモリコントローラは、暗号化または暗号エンジン１１０と、好ましくは暗号化エンジン１１０の中に置かれて暗号化エンジン１１０だけがアクセスできるハードウェアキー１１２とを含む。ハードウェアキー１１２は、そのソフトウェア／ファームウェアがカードの内側に置かれて動作するか外側に置かれて動作するかに関わらずにどんなソフトウェア／ファームウェアもそれにアクセスできないので、ソフトキーとは異なる。換言すれば、ハードウェアキー１１２はユーザファイルを暗号化するために使用されるべく意図されてはいない。ハードウェアキーは、カードを動作させるファームウェアを暗号化するためあるいはそれに署名するために使用される。実際上、カードのファームウェアを、そのファームウェアが他のどのカードに存在する場合にもそのファームウェアが使用不能となるように、カードの特定のハードウェアにバインドする。そのハードウェアを暗号化しハードウェアに署名した特定のコントローラおよび暗号化エンジンが存在しなければ、ファームウェアは動作しない。これは、無許可コピーを許すかもしれない、詐欺で手に入れたファームウェアを妨げる。セキュアシステムのこの実施形態に関するさらなる情報については、M. Holtzman らによる「Hardware Driver Integrity Check of Memory Card Controller Firmware」という米国特許出願第１１／２８５，６００号（特許文献１）を参照されたい。
【０００８】
図１Ｂは、例えばインターネットなどを介してホスト１５０とネットワーク化された種々のエンティティに通信するＳＤ１００を示す。ＳＤ１００、ホスト１５０、および種々のネットワーク化されたエンティティの間でセキュアトランザクションあるいは他の相互作用が行われることができる。
【０００９】
図２はダイバーシフィケーションを示し、コンテンツを特定の装置に限定するためにしばしば利用される他の１つの技術である。図２に示されているダイバーシフィケーションはソフトキーに関連し、コンテンツを暗号化し復号化し、それによってコンテンツおよび他のファイルの無許可複写を防止するためにカードのファームウェアおよび他のセキュアアプリケーションにより使用されるキーである。ソフトキー１２８を作るためにダイバーシフィケーションデータ１２０およびマスターキー１２４がキー生成アルゴリズムに入力される。ダイバーシフィケーションデータは、例えばカードのシリアルナンバーまたは（トラステッド(trusted) ）ＩＤなどのように、特定のカードに対して一意であることができ、あるいは特定のユーザに対して一意であることができる。ソフトキー１２８は、ダイバーシフィケーションデータの関数であり、従ってまた一意であるので、マスターキーが含まれても、全てがグローバルベースで(on a global basis) 失われることはない。ダイバーシフィケーションデータは、リファレンスおよび値の両方を含むことができる。そのような場合、値は、好ましくは図２に示されているダイバーシフィケーション関数のために使用される。ソフトキーは、一種のクレデンシャルとも称することができ、名前またはタイトルと値との両方を含むことができる。キー生成関数は、ホストとカード自体との両方において異なるアプリケーションについて異なり得る。セキュアアプリケーション１４２などのカードアプリケーションは、以下でより詳しく論じられる。
【００１０】
カードのファームウェアは、ユーザファイルの無許可の複写または転送を防止する任意の数の異なるセキュリティルーチンおよびメカニズムを持つことができる。ＳＤ１００に存在する他のセキュリティメカニズムおよび技術に関するこれ以上の情報については、その全体が本願明細書において参照により援用されている、M. Holtzman らによる「Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory 」という米国特許出願第１１／３１７，３３９号（特許文献２）、M. Holtzman らによる「Secure Memory Card With Life Cycle Phases 」という米国特許出願第１１／３１７，８６２号（特許文献３）、M. Holtzman らによる「In Stream Data Encryption/Decryption and Error Correction Method」という米国特許出願第１１／３１３，４４７号（特許文献４）、F. Jogand-Coulomb らによる「Control Structure for Versatile Content Control 」という米国特許出願第１１／３１３，５３６号（特許文献５）、F. Jogand-Coulomb らによる「System for Creating Control Structure for Versatile Content Control 」という米国特許出願第１１／３１４，０５５号（特許文献６）、B. Qawami らによる「Mobile Memory System for Secure Storage and Delivery of Media Content 」という米国特許出願第１１／３２２，７６６号（特許文献７）、およびM. Holtzman らによる「In Stream Data Encryption/Decryption Method 」という米国特許出願第１１／３１４，０３０号（特許文献８）を参照されたい。本願は、前述した特許出願のこれらのセキュリティ技術またはメカニズムに限定されるべきではない。
【００１１】
或るカードの場合には、セキュアアプリケーション１４２がカードの寿命中にカードにロードされることもある。これらのアプリケーションは、システムファームウェアの上で動作し、機密データの付加的操作を必要とし得る。例えば、メモリカードまたはＵＳＢフラッシュドライブの機能性を高めるために、パスワード管理を可能にするアプリケーションが付加され得る。これに関するこれ以上の情報については、Gonzalezらによる「Mass Storage Device With Automated Credentials Loading」という米国特許出願第１１／３１９，８３５号（特許文献９）を参照されたい。他の例として、医療または金融上の記録に関連するアプリケーションがカードにロードされ得る。これらのソフトウェアまたはファームウェアアプリケーションは、カードのプロセッサだけまたはカードのプロセッサとホスト装置のプロセッサとの共同により実行されて、機密情報を処理できるだけではなくて、カードのコンテンツを暗号化し保護するために使用される秘密情報も処理することができる。それゆえ、それらは深く相関してカード内のセキュリティメカニズムおよび情報に依存することができる。或る場合には、アプリケーション自体のセキュリティメカニズムはカード特有の情報を利用し、他のカード上では機能しない。アプリケーション自体は、それらがコピーされハッキングされるのを防止するために暗号化され、そして装置特有であり得る。
【００１２】
本質的に、これらのセキュリティメカニズムは、セキュアなユーザファイルあるいは「コピープロテクトされている」ユーザファイルを別の装置にコピーし、その後にそれらをその別の装置で利用することを不可能にすることを目指している。例として、或るカードでは、コピーされた歌は、カードまたはそのカードに結合されたホストからは再生され得ない。このことは、或る装置では、プロテクトされているコンテンツの許可された所有者またはライセンシーでさえもそれを自分の装置のうちの１つから他の１つへ、移動の前後にそのコンテンツの唯一のインスタンスが存在するだけなのに、移動させることができないという不幸な結果を有する。
【００１３】
図３を参照すると、大容量記憶フラッシュメモリ（「ＭＳＭ」）１０８のメモリ空間が示されている。ＭＳＭ１０８は、ユーザ／ホストから秘密にされたシステムパーティションまたは領域１０８Ａを含む。システムパーティション１０８Ａにはシステムファームウェア１３０およびソフトキー１３４が格納されている。システムファームウェア１３０は、ＳＤ１００の全てのデータ記憶操作と、ホスト装置１５０との通信とを制御するオペレーティングファームウェアである。ソフトキーは、ＳＤ１００内のデータを暗号化し復号化するために、ファームウェアを含む装置のソフトウェアにより利用され得るキーである。これは、前述したようにユーザファイルの一般的な暗号化／復号化に利用できないハードウェアキー１１２とは異なる。ＭＳＭ１０８は、プライベートパーティション１０８Ｂおよびユーザパーティション１０８Ｃも含む。セキュアアプリケーション１４２およびプロテクトされるデータ１３８はプライベートパーティション１０８Ｂに格納され得る。プロテクトされるデータは、自由なアクセス（それがユーザパーティション１０８Ｃに格納されたならば実際にそうなる）から保護されるために望ましい任意のタイプの操作用パラメータまたは他のデータであり得る。セキュアアプリケーション１４２は、システムファームウェア１３０の上で動作し、そしてソフトキー１３４を、単独でまたはセキュアアプリケーション自体により提供されるキーと組み合わせて、利用するセキュリティルーチンを含むことができる。これらのアプリケーション１４２は、代表的なデータ記憶操作に加えて付加的な機能性をカードに提供するものであって、カードの寿命中に何時でもユーザにより付加され得る。さらに、セキュアアプリケーションは、アプリケーションがロードされた特定のカードにおいてのみ機能するカードに特有の情報（例えば、ダイバーシフィケーションデータ１２０）を使用することができる。例えば、セキュアアプリケーションは、カードのシリアルナンバーまたは他のダイバーシフィケーションデータを用いてワンタイムパスワードを生成することができ、その後、それらをユーザまたはユーザのアカウントのログインまたはベリファイのために提示することができる。これは一例に過ぎなくて、セキュリティまたは他の機能に使用される任意の数のアルゴリズムがカード特有のデータに少なくとも部分的に基づくことができる。アプリケーションは、ユーザによって、何時でもロードされ得る。これらのアプリケーションの全ては、理想的にはターゲットカードに転送されて、アップグレード後に、下にあるハードウェアが変わったという事実にも関わらずに機能するべきである。この困難は、後に扱われる。
【００１４】
ユーザパーティション１０８に格納されているデータは一般的に公然利用可能である。ユーザパーティション１０８Ｃは、ダイバーシフィケーションデータ１２０、コピープロテクトされるコンテンツ１５２、およびプロテクトされないコンテンツ１５６を含む。ダイバーシフィケーションデータ１２０は、導出されたキーが含まれたならば特定のファイルの全てのインスタンスが著作権侵害され得るかあるいは自由に複製され得るとは限らなくなるように、１つまたは複数のマスターキーを、その１つまたは複数のマスターキーから導出されたけれども装置またはユーザのサブセットに限定される複数のキーに多様化するために使用される情報を含む。コピープロテクトされるコンテンツとは、転送されないように制限されるコンテンツ、あるいは転送またはコピーされ得るけれども、それにアクセスするための適切な手段がなければ役に立たないコンテンツのことである。セキュリティは、システムファームウェア１３０、ソフトキー１３４、および／またはセキュアアプリケーション１４２により提供され得る。多くの実施形態において、コピープロテクトされるコンテンツは通例暗号化され、その暗号化されたコンテンツは、コピーはされ得るけれども、装置が認証またはオーソライズされかつコンテンツを復号化するための適切なキーを持っていなければ、コンテンツは復号化されることはできない。
【００１５】
図４Ａは、ソース１１０Ｓのメモリ１０８Ｓのコンテンツがターゲット１００Ｔのメモリ１０８Ｔに転送されるアップグレードプロセスを描いている。前述したように、装置１００の１つの実施形態では、各々の特定のコントローラは、少なくとも装置１００のシステムファームウェア１３０をコントローラにバインドする一意なハードウェアキーを有する。従って、初めにソース１００Ｓにロードされてソース１００Ｓのコントローラおよび他のハードウェアにバインドされたシステムファームウェアは、いったんターゲット１００にコピーされたならば機能しない。これは、単に、カード１００Ｔがデフォルトでは機能しないということを意味する。或る実施形態では、セキュアアプリケーション１４２およびソフトキー１３４も、唯一のハードウェアにバインドすることができて、それらがバインドされていないハードウェアにとっては機能不能でかつアクセス不能である。これは、首尾よいアップグレードでは克服されなければならない。
【００１６】
図４Ｂは、ソース大容量記憶メモリ１０８Ｓに格納されている種々のアイテムの、ターゲット大容量記憶メモリ１０８Ｔへの転送を示す。転送は、ローカルであるかあるいは遠くに置かれることのできる１つ以上のホストを通して行われる。ステップ４０２に見られるように、システムパーティション１０８Ａのシステムファームウェア１３０およびソフトキー１３４は、ソースＨＷキー１１２Ｓで復号化され、セッションキーで暗号化され、その後、ターゲットで受け取られる時にセッションキーで復号化され、そこでそれらはターゲットＨＷキー１１２Ｔで再び暗号化される。このようにしてシステムファームウェアおよびソフトキーはソースＨＷからバインド解除(unbind)され、その後にターゲットＨＷに再バインドされる。セッションキーは、データを、それがソースからターゲットへ移送されている間プロテクトし、そして或る実施形態では不要かもしれないし、かつ／または利用されなくてもよいけれども、好ましくは使用される。ＨＷターゲットキーによる暗号化は、好ましくは、それらがターゲットの暗号化エンジン１１０Ｔを通過する時に「即座に(on the fly)」行われる。「即座の」暗号化／復号化に関するさらなる情報については、M. Holtzman らによる「In Stream Data Encryption/Decryption and Error Correction Method」という米国特許出願第１１／３１３，４４７号（特許文献４）を参照されたい。
【００１７】
プライベートパーティション１０８Ｂのプロテクトされるデータ１３８およびセキュアアプリケーションも、ステップ４０４に見られるようにソースからターゲットに転送される。それらがＨＷキーで暗号化されているならば、それらはソースＨＷキーで復号化され、移送のためにセッションキーで暗号化され、その後に復号化され、前述したようにターゲットＨＷキーで再び暗号化される。それらが単にソフトキー１３４またはセキュアアプリケーション１４２の他のキーで暗号化される実施形態において、それらは好ましくはセッションキーで暗号化され、移送後にセッションキーで復号化される。再び、前述したように、セッションキーの使用は好ましくはあるけれども、それは、一定の実施形態において、例えばホストおよび移送プロセスが既知の安全な環境であるいは私的ネットワークを介して行われ得るというシナリオにおいては、省略されてもよい。
【００１８】
ダイバーシフィケーションデータ１２０は、ステップ４０８により表されているように、セッションキーで暗号化されるかあるいは暗号化されていない状態で送られることができる。プロテクトされないコンテンツ１５６についても同様である。
【００１９】
音楽、映画および他の繊細なコンテンツなどのコピープロテクトされているコンテンツ１５２も、ステップ４１２により表されているように、ソースからターゲットに転送される。前に述べられたように、コンテンツのコピープロテクトは、システムファームウェア１３０だけにより、またはセキュアアプリケーション１４２と共同するシステムファームウェア１３０により提供される。それは、ソフトキー１３４だけで、あるいはセキュアアプリケーション１４２のプロバイダにより提供される他のキーで暗号化される。セキュアアプリケーションは、セキュリティルーチンおよび／またはシステムファームウェアのソフトキーをファームウェアのＡＰＩを通して呼び出すことができ、あるいはセキュアアプリケーションと共にまたセキュアアプリケーションにより提供されるキーを利用することができる。さらに、セキュアアプリケーションは、システムファームウェア１３０およびソフトキー１３４により提供されるものに加えて追加の暗号化の層を提供することができる。いずれの場合にも、コピープロテクトされるコンテンツを、ターゲットに格納されるので転送することができ、あるいは、ターゲットに到着した時に当該セッションキーで復号化される前の移送の間、セッションキーでさらに暗号化することができる。
【００２０】
付加的な無許可のコピーが作られないように、かつプロテクトされるコンテンツがソースと１つ以上のターゲットとの両方で利用可能ではあり得ないように、コピープロテクトされるコンテンツが複写されないことは重要である。装置は、中断されたアップグレード、および他のハッキングあるいは攻撃から自分自身を保護しなければならず、同時に、アップグレードプロセス中の偶発的故障の場合にソースおよびターゲットの両方が機能し得る状態に留まることを保証しなければならない。装置の状態マシンは、システムファームウェアと共同してこれを可能にする。
【００２１】
或る実施形態では、アップグレードが行われた後、ターゲットは、ターゲットの原ダイバーシフィケーションデータとソースのダイバーシフィケーションデータとの両方を含む。これは、ターゲットのコンテンツがソースの既存のコンテンツと合併される場合に特に有益である。或る実施形態では、ダイバーシフィケーションデータと同様に、アップグレード後のソフトキーおよび／またはクレデンシャルはターゲットのものとソースのものとの両方を含むことができる。
【００２２】
図５Ａは、本発明の１つの実施形態に従うアップグレードプロトコルを示す。ソース１００Ｓからターゲット１００Ｔへの転送は１つのコンピュータないし数台のネットワーク化されたコンピュータを含み得る通信プロキシを介して行われる。例えば、その通信プロキシは、インターネットを通して数台の他のコンピュータに、そしてついにはターゲットに結合されるホスト１５０を含むことができる。アップグレードは、ソースデータをホストにロードする前にしばらくの間一時的に遠くに格納しておいて、順次に行われてもよい。
【００２３】
プロトコルは５つの主な段階、フェーズ、あるいはステップを含む。これらは状態マシンの状態に関連させられている。まず、ステップ４５０に見られるように、アップグレードのための装置のセットアップである。プロキシは、ソースおよびターゲットの両方をデータ送受信のために準備させる。それらの各々は、次に、自分たちの準備が整ったことを知らせる。
【００２４】
プロトコルの第２の状態／ステップは、ステップ４６０に見られるように、認証である。これは、ターゲットの認証、あるいはソースおよびターゲットの両方の認証を含み得る。或る実施形態では、認証は、ソースおよびターゲットの両方が互いに相手を認証する相互認証を含む。このタイプの認証はキー交換を含む。認証の幾つかの好ましい方法が図５Ｃおよび６に関して後に論じられる。
【００２５】
プロトコルの第３の状態／ステップは、ステップ４７０に見られるように、アップグレード転送自体である。この状態の一部として、プロキシはセキュアデータベースを送るようにソースに指令し、システムファームウェア１３０、ソフトキー１３４、並びに任意選択で、そうあるならば、プロテクトされるデータ１３８およびセキュアアプリケーション１４２を含む。ソースはその後、セキュアデータベースのコピーをプロキシを通してターゲットに送る。プロキシは、その後、ソースからパーティションマップを得て、パーティションマップがターゲットのためにリサイズされるべきか否かを判定する。ターゲットはソースと同じかまたはもっと大きい記憶容量を有する。そして、任意の数の理由からパーティションマップを変更しかつ／またはリサイズするのが望ましいかもしれない。さらに、パーティションをリサイズし、従ってパーティションマップを変更することをユーザが要求し、また入力がそれを指令することもできる。マップがリサイズされなくてもよければ、パーティションデータはソースから取り出されて、先に更新されることなくターゲットに送られ得る。
【００２６】
プロトコルの第４の状態／ステップは、ステップ４８０に見られるように、コピー肯定応答である。プロキシは、コピー操作が首尾よく完了したことをターゲットが知らせるようにリクエストし、それが行われたならばソースにコピー操作が首尾よく完了したことを知らせる。
【００２７】
プロトコルの第５の状態／ステップは、ステップ４９０に見られるように、ソースの消去操作である。消去は、コピー操作が成功した場合に限って行われる。さもなければ、ソースもターゲットもメモリの完全なコンテンツを持っていないことになるという危険がある。プロキシは、消去が完了したことを知らせるようにソースにリクエストし、その肯定応答が受け取られた時、ターゲットに通知が行われる。この情報があれば、ターゲットは使用され得る。或る実施形態では、これはアクティブ化ステップを伴う。
【００２８】
図５Ｂは、図５Ａに示されているプロトコルあるいは他のアップグレードプロトコルまたはプロセスに関係する時の装置１００のカードアップグレード状態マシンの状態を示す状態図である。状態マシンとアップグレードプロトコルとは、アップグレードプロセスが何らかの理由で中断されてもアップグレードがセキュリティの侵害を伴わずに再開され、アップグレードが何らかの理由で不可能であってもターゲットおよびソースの両方が使用可能な状態に留まることを保証するように設計される。矢印に沿うテキストは、状態変化を引き起こすイベントを記述する。矢印にテキストがなければ、前述したプロトコルのフェーズ／状態が終わった時に生じる。装置あるいはカードのパワーアップ後に、ダイアモンド４０４に見られるように、カードの状態が標準状態かどうかを調べるために状態フラグが検査される。そうでなれば、装置が失敗したアップグレードから回復しつつあることを示し、装置は、ボックス４０６により示されているように、失敗した認証であり得るものを回復しようと試みるか、あるいはターゲットについて再認証しようと試みる。認証（回復）が成功しなければ、装置は最認証しようと有限回数試みる。認証の試みが所定のしきい値を越えたならば、装置は標準モード／状態に戻る。認証プロセスの一部として、装置のトラステッドＩＤまたはシリアルナンバーが読み出される。ダイアモンド４０８に見られるように、装置から読み出されたトラステッドＩＤが格納されているトラステッドＩＤと同じであれば、ダイアモンド４１２に見られるように、状態フラグが検査される。カードがアップグレード状態にあることをフラグが示していれば、ボックス４３２に見られるようにカードはアップグレードモードであると判定される。アップグレードモードでなければ、ダイアモンド４４６に見られるように、コピー肯定応答状態であるか否かが判定される。コピー肯定応答状態／モードであるならば、ボックス４４０により表されるように、状態はそのようなものとして示される。そうでなければ、ボックス４４０により表されるように、消去状態にあるかあるいは消去状態にセットされる。最後に、ボックス４４４により表されるように、カードは消去状態に達する。
【００２９】
あるいは、ダイアモンド４０４で判定されたように状態フラグが標準であると判定され、ボックス４２０により表されるように、アップグレードイベントがトリガされたならば、状態は、ボックス４２４により表されるようにカードセットアップ状態に進められる。これは図５Ａの状態／ステップ４５０に対応する。次の状態は、ボックス４２８により表されるように、認証状態である。カードは、この状態あるいはカードセットアップ状態の間、ソースまたはターゲットの役割を割り当てられる。図５Ａのステップ４６０で認証が成功したならば、例えば、状態は、装置がカードアップグレードモード／状態にあることを反映するように更新され、カードのトラステッドＩＤ（またはシリアルナンバー）が格納される。次の状態は、ボックス４３６により表されるコピー肯定応答状態（図５Ａのステップ／フェーズ４８０に対応する）である。コピー肯定応答がいったん受信されれば、装置は、ボックス４４０により表されるように、消去状態に遷移させられ、その結果としてボックス４４４で表されるように消去が通知される。その後、状態は、ボックス４２０により表される標準使用状態に進められる。従って、装置は再び標準使用され得る状態となる。
【００３０】
図５Ｃは、本発明の１つの実施形態に従うカードアップグレードプロセスを示すフローチャートである。ステップ５０２で、ソースはレセプタクルに挿入されるか、あるいは、他の場合に、既に挿入されているならば、選択される。ソースカードが挿入されるかあるいは選択され、次のステップのうちの幾つかが実行されてから充分後に生じ得るステップ５０４において、ターゲットが挿入されかつ／または選択される。ステップ５０６で、アップグレードまたは転送がリクエストされる。次に、ステップ５０８に見られるように、ホストはアップグレードリクエストを受け取り、ターゲット証明書をソースに渡す。その時、ソースは、ターゲットがターゲットとして動作する資格を有すること、およびそれがアップグレードをサポートすることを確認する。ターゲットは、ソースと同等かまたはそれより大きな容量を持っていなければならず、また同等あるいはそれ以上のレベルのセキュリティを持っていなければならない。アップグレードのために他の基準も必要かもしれない。ステップ５１２に見られるように、ターゲットおよびソースがアップグレードのための資格を有するならば、アップグレードリクエストは有効であると判定され、ソースはその時ターゲットがトラステッド（信頼される）装置であることを確認する。これは、証明書を、例えばＰＫＩ証明書オーソリティ(PKI certificate authority) などの証明書オーソリティと照合することによって行われる。しかし、リクエストが有効でなければ、ステップ５１４により表されるように、アップグレードはアボートされる。ステップ５１８で判定されるようにターゲットが信頼される（トラステッド）ならば、ソースはステップ５２０でセキュリティアイテムをパッケージ化するが、それは少なくともソフトキー１３４を含み、また、システムファームウェア１３０、プロテクトされるデータ１３８、およびセキュアアプリケーション１４２も含むことができる。それはまた任意選択によりプロテクトされるコンテンツおよび／またはプロテクトされないコンテンツの一部または全部およびダイバーシフィケーションデータも含むことができるが、そのような用心はコンテンツのためには通例不要である。ソースは、その後、ステップ５２２でパッケージをターゲット公開キーで暗号化する前にステップ５２０の一部としてセキュリティパッケージのチェックサムを行うか、あるいはパッケージに暗号法により署名する。
【００３１】
ステップ５２４で、ソースは暗号化されたパッケージに自分自身の秘密キーで署名し、暗号化されたパッケージにソース証明書を付ける。ステップ５２６で、暗号化されたパッケージおよび証明書は、ホストまたは他のプロキシを介して、選択されたターゲットに渡される。その後、ステップ５２８で、ターゲットは、例えばＰＫＩ証明書オーソリティで調べることによって、ソースが信頼される装置であることを確認する。ステップ５３０で、ソースが信頼されるものであると認められなければ、アップグレード／転送は、ステップ５３２に見られるように、アボートされる。その代わりに、ソースが信頼されるならば、ステップ５３４で、ターゲットはデータの完全性を調べ、結果をホストを介してソースに返す。この調べは、ステップ５２０からのチェックサムまたは暗号署名を比較することを含み得る。パッケージの完全性がステップ５３６でベリファイされなければ、ステップ５３８に見られるようにプロセスは再びアボートされる。代わりに、パッケージの完全性がベリファイされたならば、ソースはステップ５４０でホストを介してアクティブ化コードをターゲットに渡し、パッケージ化されたセキュリティアイテムはステップ５４２でソースから削除される。ステップ５４６で、ソースはアクティブ化コードを使ってパッケージをアンパックし、必要ならばそれをカードの既存のコンテンツと併合する。その後、ステップ５４８で、カードのコンテンツ、すなわちユーザパーティション１０８Ｃ内のプロテクトされるファイルおよび／またはプロテクトされないファイルが、ソースからターゲットにコピーされる。暗号化されているコピープロテクトされるファイルは、適切なキーがなければ役に立たないので、セキュアパッケージのために提供される用心なしで自由にコピーされ得る。
【００３２】
図６は、アップグレードプロセスに用いられる認証技術の実施形態を示す。当該技術分野で知られている他の認証技術も使用することができ、本発明は、決してこのような特定の技術や前述した特定の技術に限定されるべきではない。図６の技術は副産物としてセッションキーを作り、セッションキーは図４Ｂに関連して記載されたセッションキーとして利用され得る。
【００３３】
図６は、ＡＥＳキーを利用するダブルチャレンジ(double challenge)方法を示す。この方法はベリファイフェーズ６０５を含み、これは、装置のうちの開始装置で第１の乱数を生成してそれを装置のうちの応答装置に渡すことと、第１の乱数を応答装置で暗号化することと、第１の乱数を暗号化された形で開始装置に戻すことと、その後に、その暗号化されている第１の乱数を開始装置で復号化し、それを前の生成されたままの数と比較することとを含む。これは６０４というラベルが付された乱数Ａと共に見られる。この方法は、さらに、応答装置で第２の乱数を生成して開始装置に渡し、それを暗号化し、その後にそれを暗号化された型で応答装置に戻し、それを前の生成されたままの数と比較することを含む。これは、図６において６０６というラベルが付されている乱数Ｃと共に見られる。
【００３４】
セキュアチャネル作成フェーズ６１５も図６に示されている。セキュアチャネルを確立することは、装置のうちの開始装置で第３の乱数を生成することと、第３の乱数を開始装置で暗号化することと、第３の乱数を応答装置に渡すことと、それを応答装置で復号化することと、第４の乱数を応答装置で生成することと、復号化された第２の乱数と第３の乱数とに対して応答装置において排他的論理和演算を実行することとを含む。これは、６０８というラベルが付された乱数Ｂおよび６１０というラベルが付された乱数Ｄと共に見られる。論理和演算は６１２および６１４というラベルを付されている。
【００３５】
認証が完了したならば、前述したセキュアデータベースおよびパーティションマップは、或る実施形態では、排他的論理和演算の結果に基づいて暗号化され得る。この結果はセッションキー６１６または６１６’である。
【００３６】
本発明の種々の態様をその代表的な実施形態に関して記載してきたけれども、本発明は添付されている特許請求の範囲全体の中で保護を受ける権利を有することが理解されるべきである。
【技術分野】
【０００１】
本発明は、一般的にはセキュアコンテンツとコピープロテクトメカニズムとを有するメモリカードに関し、特に、アップグレードが行われる場合に他のメモリカードへのセキュアコンテンツの転送を可能にすることに関する。
【背景技術】
【０００２】
デジタルコンテンツの無許可のコピーおよび複写を防止するいろいろなプロテクトメカニズムがある。それらの多くは、しばしば、大雑把に１種のデジタル著作権管理（「ＤＲＭ」）と称され、そのようなものとして考えられている。特に複写と、装置から装置への転送とを防止するために多大の努力が行われてきている。例えば、無許可の複写などが挙げられるたぐいのものを防止するために、音楽あるいは視聴覚コンテンツをｉＰｏｄから他のｉＰｏｄへ転送することはできない。同様に、セキュアメモリカードあるいはＵＳＢフラッシュドライブ（以降、全体として「カード」と称される）において、プロテクトされるコンテンツをカードからカードへ移すことはできない。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願第１１／２８５，６００号
【特許文献２】米国特許出願第１１／３１７，３３９号
【特許文献３】米国特許出願第１１／３１７，８６２号
【特許文献４】米国特許出願第１１／３１３，４４７号
【特許文献５】米国特許出願第１１／３１３，５３６号
【特許文献６】米国特許出願第１１／３１４，０５５号
【特許文献７】米国特許出願第１１／３２２，７６６号
【特許文献８】米国特許出願第１１／３１４，０３０号
【特許文献９】米国特許出願第１１／３１９，８３５号
【発明の概要】
【０００４】
本発明の種々の実施形態は、ユーザが容量のより大きなカードへアップグレードしたい時にカードのコンテンツを同等かまたはそれ以上の容量のカードへ移すあるいは転送することを可能にする。その同等またはそれ以上の容量のカードはターゲットと称され、ターゲットは、コピープロテクトされるコンテンツをターゲットへ移す場合には、ソースと同等あるいはそれ以上のレベルのセキュリティを持っていなければならない。プロテクトされるコンテンツを移す前に、ターゲットの真正性を判定するためにいろいろな方法が使用される。カードのファームウェアおよび他のソフトウェアが、それがロードされたオリジナルカード以外のどのカードにおいても動作できないようなカードの実施形態では、この障害を本発明の実施形態が克服し、転送されたコピープロテクトされるコンテンツが復号化され得るようにそれらを新しいカードに再バインド(re-bind)する。本発明でなければ、許可されたアップグレードを除いては厳格に禁止される。
【０００５】
本発明の付加的な態様、利点および特徴は、その代表的な例についての以下の記述に含まれる。その記述は添付図面と関連して検討されるべきであり、そこでは同様の数字は、別様に明示されていない限り、図面全体にわたって同じ特徴を記述するために使われる。
【図面の簡単な説明】
【０００６】
【図１Ａ】セキュア装置１００のブロック図である。
【図１Ｂ】ホスト１５０を介して他のエンティティとネットワーク化されたセキュア装置１００の略図である。
【図２】ダイバーシフィケーションの図である。
【図３】図１Ａのメモリ１０８の図である。
【図４Ａ】ソースからターゲットへのアップグレードを示す図である。
【図４Ｂ】本発明の１つの実施形態に従ってアップグレード中にマテリアルがソースからターゲットへどのようにコピーされるかをさらに示す図である。
【図５Ａ】本発明の１つの実施形態に従うアップグレードプロトコルを示す。
【図５Ｂ】本発明の１つの実施形態に従うアップグレード状態マシンの状態を示す。
【図５Ｃ】本発明の１つの実施形態に従うアップグレードプロセスを示すフローチャートである。
【図６】本発明の１つの実施形態に従う認証プロセスを示す図である。
【発明を実施するための形態】
【０００７】
図１Ａは、セキュアシステムの一実施形態であるセキュア大容量記憶装置１００を示す。前述したように、セキュアフラッシュ大容量メモリカードまたはＵＳＢフラッシュドライブ（全体として「カード」またはセキュア装置と称される）では、プロテクトされるコンテンツは１つより多くのカードでは使用され得ない。セキュア装置（「ＳＤ」）１００は、好ましくはＮＡＮＤフラッシュ型の大容量記憶メモリ１０８と、データおよび制御線１０６を介してメモリ１０８に通信するセキュアメモリコントローラ１０４とを含む。セキュア装置は、ホストインターフェイス１０２を介してホスト１５０と通信する。セキュアメモリコントローラ１０４は、メモリ１０８への／メモリ１０８からのデータ格納およびデータ取り出しとホスト１０５への／ホスト１０５からの転送との全てを制御する。セキュアメモリコントローラ１０４（カードファームウェアと関連して）セキュリティをＳＤ１００に提供する。メモリコントローラは、暗号化または暗号エンジン１１０と、好ましくは暗号化エンジン１１０の中に置かれて暗号化エンジン１１０だけがアクセスできるハードウェアキー１１２とを含む。ハードウェアキー１１２は、そのソフトウェア／ファームウェアがカードの内側に置かれて動作するか外側に置かれて動作するかに関わらずにどんなソフトウェア／ファームウェアもそれにアクセスできないので、ソフトキーとは異なる。換言すれば、ハードウェアキー１１２はユーザファイルを暗号化するために使用されるべく意図されてはいない。ハードウェアキーは、カードを動作させるファームウェアを暗号化するためあるいはそれに署名するために使用される。実際上、カードのファームウェアを、そのファームウェアが他のどのカードに存在する場合にもそのファームウェアが使用不能となるように、カードの特定のハードウェアにバインドする。そのハードウェアを暗号化しハードウェアに署名した特定のコントローラおよび暗号化エンジンが存在しなければ、ファームウェアは動作しない。これは、無許可コピーを許すかもしれない、詐欺で手に入れたファームウェアを妨げる。セキュアシステムのこの実施形態に関するさらなる情報については、M. Holtzman らによる「Hardware Driver Integrity Check of Memory Card Controller Firmware」という米国特許出願第１１／２８５，６００号（特許文献１）を参照されたい。
【０００８】
図１Ｂは、例えばインターネットなどを介してホスト１５０とネットワーク化された種々のエンティティに通信するＳＤ１００を示す。ＳＤ１００、ホスト１５０、および種々のネットワーク化されたエンティティの間でセキュアトランザクションあるいは他の相互作用が行われることができる。
【０００９】
図２はダイバーシフィケーションを示し、コンテンツを特定の装置に限定するためにしばしば利用される他の１つの技術である。図２に示されているダイバーシフィケーションはソフトキーに関連し、コンテンツを暗号化し復号化し、それによってコンテンツおよび他のファイルの無許可複写を防止するためにカードのファームウェアおよび他のセキュアアプリケーションにより使用されるキーである。ソフトキー１２８を作るためにダイバーシフィケーションデータ１２０およびマスターキー１２４がキー生成アルゴリズムに入力される。ダイバーシフィケーションデータは、例えばカードのシリアルナンバーまたは（トラステッド(trusted) ）ＩＤなどのように、特定のカードに対して一意であることができ、あるいは特定のユーザに対して一意であることができる。ソフトキー１２８は、ダイバーシフィケーションデータの関数であり、従ってまた一意であるので、マスターキーが含まれても、全てがグローバルベースで(on a global basis) 失われることはない。ダイバーシフィケーションデータは、リファレンスおよび値の両方を含むことができる。そのような場合、値は、好ましくは図２に示されているダイバーシフィケーション関数のために使用される。ソフトキーは、一種のクレデンシャルとも称することができ、名前またはタイトルと値との両方を含むことができる。キー生成関数は、ホストとカード自体との両方において異なるアプリケーションについて異なり得る。セキュアアプリケーション１４２などのカードアプリケーションは、以下でより詳しく論じられる。
【００１０】
カードのファームウェアは、ユーザファイルの無許可の複写または転送を防止する任意の数の異なるセキュリティルーチンおよびメカニズムを持つことができる。ＳＤ１００に存在する他のセキュリティメカニズムおよび技術に関するこれ以上の情報については、その全体が本願明細書において参照により援用されている、M. Holtzman らによる「Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory 」という米国特許出願第１１／３１７，３３９号（特許文献２）、M. Holtzman らによる「Secure Memory Card With Life Cycle Phases 」という米国特許出願第１１／３１７，８６２号（特許文献３）、M. Holtzman らによる「In Stream Data Encryption/Decryption and Error Correction Method」という米国特許出願第１１／３１３，４４７号（特許文献４）、F. Jogand-Coulomb らによる「Control Structure for Versatile Content Control 」という米国特許出願第１１／３１３，５３６号（特許文献５）、F. Jogand-Coulomb らによる「System for Creating Control Structure for Versatile Content Control 」という米国特許出願第１１／３１４，０５５号（特許文献６）、B. Qawami らによる「Mobile Memory System for Secure Storage and Delivery of Media Content 」という米国特許出願第１１／３２２，７６６号（特許文献７）、およびM. Holtzman らによる「In Stream Data Encryption/Decryption Method 」という米国特許出願第１１／３１４，０３０号（特許文献８）を参照されたい。本願は、前述した特許出願のこれらのセキュリティ技術またはメカニズムに限定されるべきではない。
【００１１】
或るカードの場合には、セキュアアプリケーション１４２がカードの寿命中にカードにロードされることもある。これらのアプリケーションは、システムファームウェアの上で動作し、機密データの付加的操作を必要とし得る。例えば、メモリカードまたはＵＳＢフラッシュドライブの機能性を高めるために、パスワード管理を可能にするアプリケーションが付加され得る。これに関するこれ以上の情報については、Gonzalezらによる「Mass Storage Device With Automated Credentials Loading」という米国特許出願第１１／３１９，８３５号（特許文献９）を参照されたい。他の例として、医療または金融上の記録に関連するアプリケーションがカードにロードされ得る。これらのソフトウェアまたはファームウェアアプリケーションは、カードのプロセッサだけまたはカードのプロセッサとホスト装置のプロセッサとの共同により実行されて、機密情報を処理できるだけではなくて、カードのコンテンツを暗号化し保護するために使用される秘密情報も処理することができる。それゆえ、それらは深く相関してカード内のセキュリティメカニズムおよび情報に依存することができる。或る場合には、アプリケーション自体のセキュリティメカニズムはカード特有の情報を利用し、他のカード上では機能しない。アプリケーション自体は、それらがコピーされハッキングされるのを防止するために暗号化され、そして装置特有であり得る。
【００１２】
本質的に、これらのセキュリティメカニズムは、セキュアなユーザファイルあるいは「コピープロテクトされている」ユーザファイルを別の装置にコピーし、その後にそれらをその別の装置で利用することを不可能にすることを目指している。例として、或るカードでは、コピーされた歌は、カードまたはそのカードに結合されたホストからは再生され得ない。このことは、或る装置では、プロテクトされているコンテンツの許可された所有者またはライセンシーでさえもそれを自分の装置のうちの１つから他の１つへ、移動の前後にそのコンテンツの唯一のインスタンスが存在するだけなのに、移動させることができないという不幸な結果を有する。
【００１３】
図３を参照すると、大容量記憶フラッシュメモリ（「ＭＳＭ」）１０８のメモリ空間が示されている。ＭＳＭ１０８は、ユーザ／ホストから秘密にされたシステムパーティションまたは領域１０８Ａを含む。システムパーティション１０８Ａにはシステムファームウェア１３０およびソフトキー１３４が格納されている。システムファームウェア１３０は、ＳＤ１００の全てのデータ記憶操作と、ホスト装置１５０との通信とを制御するオペレーティングファームウェアである。ソフトキーは、ＳＤ１００内のデータを暗号化し復号化するために、ファームウェアを含む装置のソフトウェアにより利用され得るキーである。これは、前述したようにユーザファイルの一般的な暗号化／復号化に利用できないハードウェアキー１１２とは異なる。ＭＳＭ１０８は、プライベートパーティション１０８Ｂおよびユーザパーティション１０８Ｃも含む。セキュアアプリケーション１４２およびプロテクトされるデータ１３８はプライベートパーティション１０８Ｂに格納され得る。プロテクトされるデータは、自由なアクセス（それがユーザパーティション１０８Ｃに格納されたならば実際にそうなる）から保護されるために望ましい任意のタイプの操作用パラメータまたは他のデータであり得る。セキュアアプリケーション１４２は、システムファームウェア１３０の上で動作し、そしてソフトキー１３４を、単独でまたはセキュアアプリケーション自体により提供されるキーと組み合わせて、利用するセキュリティルーチンを含むことができる。これらのアプリケーション１４２は、代表的なデータ記憶操作に加えて付加的な機能性をカードに提供するものであって、カードの寿命中に何時でもユーザにより付加され得る。さらに、セキュアアプリケーションは、アプリケーションがロードされた特定のカードにおいてのみ機能するカードに特有の情報（例えば、ダイバーシフィケーションデータ１２０）を使用することができる。例えば、セキュアアプリケーションは、カードのシリアルナンバーまたは他のダイバーシフィケーションデータを用いてワンタイムパスワードを生成することができ、その後、それらをユーザまたはユーザのアカウントのログインまたはベリファイのために提示することができる。これは一例に過ぎなくて、セキュリティまたは他の機能に使用される任意の数のアルゴリズムがカード特有のデータに少なくとも部分的に基づくことができる。アプリケーションは、ユーザによって、何時でもロードされ得る。これらのアプリケーションの全ては、理想的にはターゲットカードに転送されて、アップグレード後に、下にあるハードウェアが変わったという事実にも関わらずに機能するべきである。この困難は、後に扱われる。
【００１４】
ユーザパーティション１０８に格納されているデータは一般的に公然利用可能である。ユーザパーティション１０８Ｃは、ダイバーシフィケーションデータ１２０、コピープロテクトされるコンテンツ１５２、およびプロテクトされないコンテンツ１５６を含む。ダイバーシフィケーションデータ１２０は、導出されたキーが含まれたならば特定のファイルの全てのインスタンスが著作権侵害され得るかあるいは自由に複製され得るとは限らなくなるように、１つまたは複数のマスターキーを、その１つまたは複数のマスターキーから導出されたけれども装置またはユーザのサブセットに限定される複数のキーに多様化するために使用される情報を含む。コピープロテクトされるコンテンツとは、転送されないように制限されるコンテンツ、あるいは転送またはコピーされ得るけれども、それにアクセスするための適切な手段がなければ役に立たないコンテンツのことである。セキュリティは、システムファームウェア１３０、ソフトキー１３４、および／またはセキュアアプリケーション１４２により提供され得る。多くの実施形態において、コピープロテクトされるコンテンツは通例暗号化され、その暗号化されたコンテンツは、コピーはされ得るけれども、装置が認証またはオーソライズされかつコンテンツを復号化するための適切なキーを持っていなければ、コンテンツは復号化されることはできない。
【００１５】
図４Ａは、ソース１１０Ｓのメモリ１０８Ｓのコンテンツがターゲット１００Ｔのメモリ１０８Ｔに転送されるアップグレードプロセスを描いている。前述したように、装置１００の１つの実施形態では、各々の特定のコントローラは、少なくとも装置１００のシステムファームウェア１３０をコントローラにバインドする一意なハードウェアキーを有する。従って、初めにソース１００Ｓにロードされてソース１００Ｓのコントローラおよび他のハードウェアにバインドされたシステムファームウェアは、いったんターゲット１００にコピーされたならば機能しない。これは、単に、カード１００Ｔがデフォルトでは機能しないということを意味する。或る実施形態では、セキュアアプリケーション１４２およびソフトキー１３４も、唯一のハードウェアにバインドすることができて、それらがバインドされていないハードウェアにとっては機能不能でかつアクセス不能である。これは、首尾よいアップグレードでは克服されなければならない。
【００１６】
図４Ｂは、ソース大容量記憶メモリ１０８Ｓに格納されている種々のアイテムの、ターゲット大容量記憶メモリ１０８Ｔへの転送を示す。転送は、ローカルであるかあるいは遠くに置かれることのできる１つ以上のホストを通して行われる。ステップ４０２に見られるように、システムパーティション１０８Ａのシステムファームウェア１３０およびソフトキー１３４は、ソースＨＷキー１１２Ｓで復号化され、セッションキーで暗号化され、その後、ターゲットで受け取られる時にセッションキーで復号化され、そこでそれらはターゲットＨＷキー１１２Ｔで再び暗号化される。このようにしてシステムファームウェアおよびソフトキーはソースＨＷからバインド解除(unbind)され、その後にターゲットＨＷに再バインドされる。セッションキーは、データを、それがソースからターゲットへ移送されている間プロテクトし、そして或る実施形態では不要かもしれないし、かつ／または利用されなくてもよいけれども、好ましくは使用される。ＨＷターゲットキーによる暗号化は、好ましくは、それらがターゲットの暗号化エンジン１１０Ｔを通過する時に「即座に(on the fly)」行われる。「即座の」暗号化／復号化に関するさらなる情報については、M. Holtzman らによる「In Stream Data Encryption/Decryption and Error Correction Method」という米国特許出願第１１／３１３，４４７号（特許文献４）を参照されたい。
【００１７】
プライベートパーティション１０８Ｂのプロテクトされるデータ１３８およびセキュアアプリケーションも、ステップ４０４に見られるようにソースからターゲットに転送される。それらがＨＷキーで暗号化されているならば、それらはソースＨＷキーで復号化され、移送のためにセッションキーで暗号化され、その後に復号化され、前述したようにターゲットＨＷキーで再び暗号化される。それらが単にソフトキー１３４またはセキュアアプリケーション１４２の他のキーで暗号化される実施形態において、それらは好ましくはセッションキーで暗号化され、移送後にセッションキーで復号化される。再び、前述したように、セッションキーの使用は好ましくはあるけれども、それは、一定の実施形態において、例えばホストおよび移送プロセスが既知の安全な環境であるいは私的ネットワークを介して行われ得るというシナリオにおいては、省略されてもよい。
【００１８】
ダイバーシフィケーションデータ１２０は、ステップ４０８により表されているように、セッションキーで暗号化されるかあるいは暗号化されていない状態で送られることができる。プロテクトされないコンテンツ１５６についても同様である。
【００１９】
音楽、映画および他の繊細なコンテンツなどのコピープロテクトされているコンテンツ１５２も、ステップ４１２により表されているように、ソースからターゲットに転送される。前に述べられたように、コンテンツのコピープロテクトは、システムファームウェア１３０だけにより、またはセキュアアプリケーション１４２と共同するシステムファームウェア１３０により提供される。それは、ソフトキー１３４だけで、あるいはセキュアアプリケーション１４２のプロバイダにより提供される他のキーで暗号化される。セキュアアプリケーションは、セキュリティルーチンおよび／またはシステムファームウェアのソフトキーをファームウェアのＡＰＩを通して呼び出すことができ、あるいはセキュアアプリケーションと共にまたセキュアアプリケーションにより提供されるキーを利用することができる。さらに、セキュアアプリケーションは、システムファームウェア１３０およびソフトキー１３４により提供されるものに加えて追加の暗号化の層を提供することができる。いずれの場合にも、コピープロテクトされるコンテンツを、ターゲットに格納されるので転送することができ、あるいは、ターゲットに到着した時に当該セッションキーで復号化される前の移送の間、セッションキーでさらに暗号化することができる。
【００２０】
付加的な無許可のコピーが作られないように、かつプロテクトされるコンテンツがソースと１つ以上のターゲットとの両方で利用可能ではあり得ないように、コピープロテクトされるコンテンツが複写されないことは重要である。装置は、中断されたアップグレード、および他のハッキングあるいは攻撃から自分自身を保護しなければならず、同時に、アップグレードプロセス中の偶発的故障の場合にソースおよびターゲットの両方が機能し得る状態に留まることを保証しなければならない。装置の状態マシンは、システムファームウェアと共同してこれを可能にする。
【００２１】
或る実施形態では、アップグレードが行われた後、ターゲットは、ターゲットの原ダイバーシフィケーションデータとソースのダイバーシフィケーションデータとの両方を含む。これは、ターゲットのコンテンツがソースの既存のコンテンツと合併される場合に特に有益である。或る実施形態では、ダイバーシフィケーションデータと同様に、アップグレード後のソフトキーおよび／またはクレデンシャルはターゲットのものとソースのものとの両方を含むことができる。
【００２２】
図５Ａは、本発明の１つの実施形態に従うアップグレードプロトコルを示す。ソース１００Ｓからターゲット１００Ｔへの転送は１つのコンピュータないし数台のネットワーク化されたコンピュータを含み得る通信プロキシを介して行われる。例えば、その通信プロキシは、インターネットを通して数台の他のコンピュータに、そしてついにはターゲットに結合されるホスト１５０を含むことができる。アップグレードは、ソースデータをホストにロードする前にしばらくの間一時的に遠くに格納しておいて、順次に行われてもよい。
【００２３】
プロトコルは５つの主な段階、フェーズ、あるいはステップを含む。これらは状態マシンの状態に関連させられている。まず、ステップ４５０に見られるように、アップグレードのための装置のセットアップである。プロキシは、ソースおよびターゲットの両方をデータ送受信のために準備させる。それらの各々は、次に、自分たちの準備が整ったことを知らせる。
【００２４】
プロトコルの第２の状態／ステップは、ステップ４６０に見られるように、認証である。これは、ターゲットの認証、あるいはソースおよびターゲットの両方の認証を含み得る。或る実施形態では、認証は、ソースおよびターゲットの両方が互いに相手を認証する相互認証を含む。このタイプの認証はキー交換を含む。認証の幾つかの好ましい方法が図５Ｃおよび６に関して後に論じられる。
【００２５】
プロトコルの第３の状態／ステップは、ステップ４７０に見られるように、アップグレード転送自体である。この状態の一部として、プロキシはセキュアデータベースを送るようにソースに指令し、システムファームウェア１３０、ソフトキー１３４、並びに任意選択で、そうあるならば、プロテクトされるデータ１３８およびセキュアアプリケーション１４２を含む。ソースはその後、セキュアデータベースのコピーをプロキシを通してターゲットに送る。プロキシは、その後、ソースからパーティションマップを得て、パーティションマップがターゲットのためにリサイズされるべきか否かを判定する。ターゲットはソースと同じかまたはもっと大きい記憶容量を有する。そして、任意の数の理由からパーティションマップを変更しかつ／またはリサイズするのが望ましいかもしれない。さらに、パーティションをリサイズし、従ってパーティションマップを変更することをユーザが要求し、また入力がそれを指令することもできる。マップがリサイズされなくてもよければ、パーティションデータはソースから取り出されて、先に更新されることなくターゲットに送られ得る。
【００２６】
プロトコルの第４の状態／ステップは、ステップ４８０に見られるように、コピー肯定応答である。プロキシは、コピー操作が首尾よく完了したことをターゲットが知らせるようにリクエストし、それが行われたならばソースにコピー操作が首尾よく完了したことを知らせる。
【００２７】
プロトコルの第５の状態／ステップは、ステップ４９０に見られるように、ソースの消去操作である。消去は、コピー操作が成功した場合に限って行われる。さもなければ、ソースもターゲットもメモリの完全なコンテンツを持っていないことになるという危険がある。プロキシは、消去が完了したことを知らせるようにソースにリクエストし、その肯定応答が受け取られた時、ターゲットに通知が行われる。この情報があれば、ターゲットは使用され得る。或る実施形態では、これはアクティブ化ステップを伴う。
【００２８】
図５Ｂは、図５Ａに示されているプロトコルあるいは他のアップグレードプロトコルまたはプロセスに関係する時の装置１００のカードアップグレード状態マシンの状態を示す状態図である。状態マシンとアップグレードプロトコルとは、アップグレードプロセスが何らかの理由で中断されてもアップグレードがセキュリティの侵害を伴わずに再開され、アップグレードが何らかの理由で不可能であってもターゲットおよびソースの両方が使用可能な状態に留まることを保証するように設計される。矢印に沿うテキストは、状態変化を引き起こすイベントを記述する。矢印にテキストがなければ、前述したプロトコルのフェーズ／状態が終わった時に生じる。装置あるいはカードのパワーアップ後に、ダイアモンド４０４に見られるように、カードの状態が標準状態かどうかを調べるために状態フラグが検査される。そうでなれば、装置が失敗したアップグレードから回復しつつあることを示し、装置は、ボックス４０６により示されているように、失敗した認証であり得るものを回復しようと試みるか、あるいはターゲットについて再認証しようと試みる。認証（回復）が成功しなければ、装置は最認証しようと有限回数試みる。認証の試みが所定のしきい値を越えたならば、装置は標準モード／状態に戻る。認証プロセスの一部として、装置のトラステッドＩＤまたはシリアルナンバーが読み出される。ダイアモンド４０８に見られるように、装置から読み出されたトラステッドＩＤが格納されているトラステッドＩＤと同じであれば、ダイアモンド４１２に見られるように、状態フラグが検査される。カードがアップグレード状態にあることをフラグが示していれば、ボックス４３２に見られるようにカードはアップグレードモードであると判定される。アップグレードモードでなければ、ダイアモンド４４６に見られるように、コピー肯定応答状態であるか否かが判定される。コピー肯定応答状態／モードであるならば、ボックス４４０により表されるように、状態はそのようなものとして示される。そうでなければ、ボックス４４０により表されるように、消去状態にあるかあるいは消去状態にセットされる。最後に、ボックス４４４により表されるように、カードは消去状態に達する。
【００２９】
あるいは、ダイアモンド４０４で判定されたように状態フラグが標準であると判定され、ボックス４２０により表されるように、アップグレードイベントがトリガされたならば、状態は、ボックス４２４により表されるようにカードセットアップ状態に進められる。これは図５Ａの状態／ステップ４５０に対応する。次の状態は、ボックス４２８により表されるように、認証状態である。カードは、この状態あるいはカードセットアップ状態の間、ソースまたはターゲットの役割を割り当てられる。図５Ａのステップ４６０で認証が成功したならば、例えば、状態は、装置がカードアップグレードモード／状態にあることを反映するように更新され、カードのトラステッドＩＤ（またはシリアルナンバー）が格納される。次の状態は、ボックス４３６により表されるコピー肯定応答状態（図５Ａのステップ／フェーズ４８０に対応する）である。コピー肯定応答がいったん受信されれば、装置は、ボックス４４０により表されるように、消去状態に遷移させられ、その結果としてボックス４４４で表されるように消去が通知される。その後、状態は、ボックス４２０により表される標準使用状態に進められる。従って、装置は再び標準使用され得る状態となる。
【００３０】
図５Ｃは、本発明の１つの実施形態に従うカードアップグレードプロセスを示すフローチャートである。ステップ５０２で、ソースはレセプタクルに挿入されるか、あるいは、他の場合に、既に挿入されているならば、選択される。ソースカードが挿入されるかあるいは選択され、次のステップのうちの幾つかが実行されてから充分後に生じ得るステップ５０４において、ターゲットが挿入されかつ／または選択される。ステップ５０６で、アップグレードまたは転送がリクエストされる。次に、ステップ５０８に見られるように、ホストはアップグレードリクエストを受け取り、ターゲット証明書をソースに渡す。その時、ソースは、ターゲットがターゲットとして動作する資格を有すること、およびそれがアップグレードをサポートすることを確認する。ターゲットは、ソースと同等かまたはそれより大きな容量を持っていなければならず、また同等あるいはそれ以上のレベルのセキュリティを持っていなければならない。アップグレードのために他の基準も必要かもしれない。ステップ５１２に見られるように、ターゲットおよびソースがアップグレードのための資格を有するならば、アップグレードリクエストは有効であると判定され、ソースはその時ターゲットがトラステッド（信頼される）装置であることを確認する。これは、証明書を、例えばＰＫＩ証明書オーソリティ(PKI certificate authority) などの証明書オーソリティと照合することによって行われる。しかし、リクエストが有効でなければ、ステップ５１４により表されるように、アップグレードはアボートされる。ステップ５１８で判定されるようにターゲットが信頼される（トラステッド）ならば、ソースはステップ５２０でセキュリティアイテムをパッケージ化するが、それは少なくともソフトキー１３４を含み、また、システムファームウェア１３０、プロテクトされるデータ１３８、およびセキュアアプリケーション１４２も含むことができる。それはまた任意選択によりプロテクトされるコンテンツおよび／またはプロテクトされないコンテンツの一部または全部およびダイバーシフィケーションデータも含むことができるが、そのような用心はコンテンツのためには通例不要である。ソースは、その後、ステップ５２２でパッケージをターゲット公開キーで暗号化する前にステップ５２０の一部としてセキュリティパッケージのチェックサムを行うか、あるいはパッケージに暗号法により署名する。
【００３１】
ステップ５２４で、ソースは暗号化されたパッケージに自分自身の秘密キーで署名し、暗号化されたパッケージにソース証明書を付ける。ステップ５２６で、暗号化されたパッケージおよび証明書は、ホストまたは他のプロキシを介して、選択されたターゲットに渡される。その後、ステップ５２８で、ターゲットは、例えばＰＫＩ証明書オーソリティで調べることによって、ソースが信頼される装置であることを確認する。ステップ５３０で、ソースが信頼されるものであると認められなければ、アップグレード／転送は、ステップ５３２に見られるように、アボートされる。その代わりに、ソースが信頼されるならば、ステップ５３４で、ターゲットはデータの完全性を調べ、結果をホストを介してソースに返す。この調べは、ステップ５２０からのチェックサムまたは暗号署名を比較することを含み得る。パッケージの完全性がステップ５３６でベリファイされなければ、ステップ５３８に見られるようにプロセスは再びアボートされる。代わりに、パッケージの完全性がベリファイされたならば、ソースはステップ５４０でホストを介してアクティブ化コードをターゲットに渡し、パッケージ化されたセキュリティアイテムはステップ５４２でソースから削除される。ステップ５４６で、ソースはアクティブ化コードを使ってパッケージをアンパックし、必要ならばそれをカードの既存のコンテンツと併合する。その後、ステップ５４８で、カードのコンテンツ、すなわちユーザパーティション１０８Ｃ内のプロテクトされるファイルおよび／またはプロテクトされないファイルが、ソースからターゲットにコピーされる。暗号化されているコピープロテクトされるファイルは、適切なキーがなければ役に立たないので、セキュアパッケージのために提供される用心なしで自由にコピーされ得る。
【００３２】
図６は、アップグレードプロセスに用いられる認証技術の実施形態を示す。当該技術分野で知られている他の認証技術も使用することができ、本発明は、決してこのような特定の技術や前述した特定の技術に限定されるべきではない。図６の技術は副産物としてセッションキーを作り、セッションキーは図４Ｂに関連して記載されたセッションキーとして利用され得る。
【００３３】
図６は、ＡＥＳキーを利用するダブルチャレンジ(double challenge)方法を示す。この方法はベリファイフェーズ６０５を含み、これは、装置のうちの開始装置で第１の乱数を生成してそれを装置のうちの応答装置に渡すことと、第１の乱数を応答装置で暗号化することと、第１の乱数を暗号化された形で開始装置に戻すことと、その後に、その暗号化されている第１の乱数を開始装置で復号化し、それを前の生成されたままの数と比較することとを含む。これは６０４というラベルが付された乱数Ａと共に見られる。この方法は、さらに、応答装置で第２の乱数を生成して開始装置に渡し、それを暗号化し、その後にそれを暗号化された型で応答装置に戻し、それを前の生成されたままの数と比較することを含む。これは、図６において６０６というラベルが付されている乱数Ｃと共に見られる。
【００３４】
セキュアチャネル作成フェーズ６１５も図６に示されている。セキュアチャネルを確立することは、装置のうちの開始装置で第３の乱数を生成することと、第３の乱数を開始装置で暗号化することと、第３の乱数を応答装置に渡すことと、それを応答装置で復号化することと、第４の乱数を応答装置で生成することと、復号化された第２の乱数と第３の乱数とに対して応答装置において排他的論理和演算を実行することとを含む。これは、６０８というラベルが付された乱数Ｂおよび６１０というラベルが付された乱数Ｄと共に見られる。論理和演算は６１２および６１４というラベルを付されている。
【００３５】
認証が完了したならば、前述したセキュアデータベースおよびパーティションマップは、或る実施形態では、排他的論理和演算の結果に基づいて暗号化され得る。この結果はセッションキー６１６または６１６’である。
【００３６】
本発明の種々の態様をその代表的な実施形態に関して記載してきたけれども、本発明は添付されている特許請求の範囲全体の中で保護を受ける権利を有することが理解されるべきである。
【特許請求の範囲】
【請求項１】
フラッシュストレージドライブ上のデータをプロテクトし、その後に、リクエストされたならば、そのプロテクトされる、通常は転送不能のデータを、ソースフラッシュストレージドライブからターゲットフラッシュストレージドライブに転送する方法であって、
転送不能であり、かつ単一のドライブに前記ドライブの寿命の間一意に関連付けられ、さらに前記ドライブのどのソフトウェアもアクセスできないハードウェアキーを前記ソースドライブにおいて提供するステップと、
前記ソースドライブのオペレーティングファームウェアを前記ハードウェアキーで暗号化するステップと、
前記ソースドライブの秘密の、ホスト装置がアクセスできないシステムパーティションに、前記ハードウェア暗号化されたオペレーティングファームウェアを格納するステップと、
ソフトウェアに基づく暗号化キーのグループを前記ソースドライブの前記システムパーティションに格納するステップと、
前記ソースドライブのユーザファイルと、存在するならばアプリケーションとを含む前記ソースドライブのコンテンツを前記ターゲットドライブに転送するためのリクエストを受け取るステップと、 前記ターゲットドライブの真正性を判定するステップと、
真性であると判定されたならば、前記ソースカードの前記オペレーティングファームウェアを前記ソースドライブに特有の前記ハードウェアキーで復号化するステップと、
前記ソースドライブと前記ターゲットドライブとの間のセキュアセッションを確立して、前記セキュアセッションの間に前記オペレーティングファームウェアを前記ソースドライブから前記ターゲットドライブに転送するステップと、
転送不能であり、かつ前記ターゲットドライブに前記ドライブの寿命の間一意に関連付けられるターゲットハードウェアキーで、前記ターゲットドライブにおいて前記オペレーティングファームウェアを再暗号化し、これにより前記ターゲットドライブが前記オペレーティングファームウェアを利用することを一意に可能にするステップと、
を含む方法。
【請求項２】
請求項１記載の方法において、
前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップは、前記アプリケーションを秘密パーティションに格納するステップを含む方法。
【請求項３】
請求項１記載の方法において、
前記暗号化され格納されたファイルはホスト装置にとっては自由にアクセス可能であり、従って適切なソフトウェアキーを持っていないホスト装置は前記ファイルを自由にコピーできるけれどもそれらを復号化することができない方法。
【請求項４】
請求項１記載の方法において、
前記セキュアセッションの間に前記オペレーティングファームウェアを前記ソースドライブから前記ターゲットドライブに転送するステップは、
転送の前に前記復号化されたオペレーティングファームウェアを、前記ソースドライブおよび前記ターゲットドライブの両方の前記ハードウェアキーおよびソフトウェアキーから独立しているセッションキーで暗号化するステップと、
前記オペレーティングファームウェアを、前記ターゲットへの到着の直後に前記セッションキーで復号化するステップと、その後に
前記オペレーティングファームウェアを前記ターゲットドライブにおいてハードウェアキーで再暗号化するステップと、
を含む方法。
【請求項５】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループを前記ハードウェアキーで暗号化するステップをさらに含む方法。
【請求項６】
請求項１記載の方法において、
前記ハードウェアに適切にバインドされていないファームウェアは前記ソフトキーにも前記ドライブの他のコンテンツにもアクセスできない方法。
【請求項７】
請求項１記載の方法において、
前記ハードウェア暗号化されたオペレーティングファームウェアを前記ターゲットドライブのシステムパーティションに格納するステップをさらに含む方法。
【請求項８】
請求項１記載の方法において、
前記ソースドライブから前記ターゲットドライブへの転送の間、前記オペレーティングファームウェア、前記ソフトウェアに基づく暗号化キーのグループ、前記アプリケーション、および前記ユーザファイルのうちの１つ以上は前記ソースドライブから前記ターゲットドライブへのルート上で前記ソースドライブあるいは前記ターゲットドライブ以外の中間記憶ユニットに一時的に格納される方法。
【請求項９】
請求項１記載の方法において、
前記ソースドライブ上で動作するソフトウェアアプリケーションを、前記ソフトウェアに基づく暗号化キーのグループのうちの１つで暗号化するステップをさらに含む方法。
【請求項１０】
請求項９記載の方法において、
前記ソースストレージドライブの前記ハードウェアキーから独立しているアプリケーション特有のセキュリティメカニズムを有する前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップと、
前記暗号化されたアプリケーションの前記アプリケーション特有のセキュリティメカニズムを用いてユーザファイルを暗号化するステップと、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブの前記フラッシュメモリに格納するステップと、
ユーザファイルにアクセスするためのリクエストを前記ホスト装置のファイルマネージャから時々受け取るステップと、
前記オペレーティングファームウェアで、前記ファイルを、前記ファイルにアクセスするために使用されるアプリケーションに相関させ、かつ前記アプリケーションのアプリケーション特有のセキュリティメカニズムを呼び出すことによって、リクエストされた時に前記ユーザファイルにアクセスするステップと、
をさらに含む方法。
【請求項１１】
請求項７記載の方法において、
前記ターゲットドライブの前記真正性がベリファイされたならば、前記ソフトウェアに基づく暗号化キーのグループと前記アプリケーションとを前記ソースドライブから前記ターゲットドライブに転送するステップと、
前記アプリケーションを暗号化されたフォーマットで前記ターゲットフラッシュストレージドライブのフラッシュメモリに格納するステップと、
をさらに含む方法。
【請求項１２】
請求項１１記載の方法において、
前記ターゲットドライブの前記ユーザファイルを前記ストレージドライブに転送するステップをさらに含む方法。
【請求項１３】
請求項１１記載の方法において、
前記オペレーティングファームウェア、前記ソフトウェアに基づく暗号化キーのグループ、および前記アプリケーションが前記ソースドライブから前記ターゲットドライブに転送されたことをベリファイするステップをさらに含む方法。
【請求項１４】
請求項１３記載の方法において、
ベリファイが成功したならば、前記ユーザファイルを前記ソースドライブから削除するステップをさらに含む方法。
【請求項１５】
請求項１３記載の方法において、
ベリファイが成功したならば、ターゲットカードをアクティブ化するステップをさらに含む方法。
【請求項１６】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループのうちの少なくとも１つは、前記ソースドライブを一意に特定する情報の関数である方法。
【請求項１７】
請求項１６記載の方法において、
前記ソースドライブを一意に特定する前記情報は、前記ドライブのシリアルナンバーを含む方法。
【請求項１８】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループのうちの少なくとも１つは、前記ドライブのユーザに関連付けられた情報の関数である方法。
【請求項１９】
請求項１８記載の方法において、
前記ユーザに関連付けられた前記情報は、ドライブからドライブへと転送可能である方法。
【請求項２０】
請求項１９記載の方法において、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップは、アプリケーションプログラミングインターフェイスのリクエストに応答して１つ以上のファイルを暗号化するために前記ソフトウェアに基づく暗号化キーのうちの１つ以上を利用するステップをさらに含む方法。
【請求項２１】
請求項１記載の方法において、
アプリケーション特有のセキュリティメカニズムは、前記ソースドライブを一意に特定する情報の関数であるダイバーシフィケーション方法を利用する方法。
【請求項２２】
請求項２１記載の方法において、
アプリケーションがリモートサーバについて認証を受けるために前記ソースドライブに特有の情報に依存し、前記アプリケーションがターゲットドライブに転送されるならば、前記認証のための前記ソースドライブに特有の情報も前記ターゲットドライブに転送される方法。
【請求項２３】
フラッシュストレージドライブ上のデータをプロテクトし、その後に、リクエストされたならば、そのプロテクトされる、通常は転送不能のデータを、ソースフラッシュストレージドライブからターゲットフラッシュストレージドライブに転送する方法であって、
転送不能であり、かつ単一のドライブに前記ドライブの寿命の間一意に関連付けられるハードウェアキーを前記ソースドライブにおいて提供するステップと、
前記ソースドライブのオペレーティングファームウェアを前記ハードウェアキーで暗号化するステップと、
前記ソースドライブの、ホスト装置がアクセスできない第１の秘密パーティションに、前記ハードウェア暗号化されたオペレーティングファームウェアを格納するステップと、
ソフトウェアに基づく暗号化キーのグループを前記ソースドライブの前記第１の秘密パーティションに格納するステップと、
前記ソフトウェアに基づく暗号化キーのグループのうちの１つでアプリケーションを暗号化するステップと、
前記ソースストレージドライブの前記ハードウェアキーから独立しているアプリケーション特有のセキュリティメカニズムを有する前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップと、
前記暗号化されたアプリケーションの前記アプリケーション特有のセキュリティメカニズムを用いてユーザファイルを暗号化するステップと、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブの前記フラッシュメモリに格納するステップと、
を含む方法。
【請求項２４】
第１の携帯型大容量記憶装置から第２の携帯型大容量記憶装置にアップグレードする方法であって、前記第１および第２の携帯型大容量記憶装置の両方は、前記装置に格納されているコンテンツのコピーがコピーされてもそれが他の装置上で動作するのを防止するためのファームウェアを有する、方法において、
（ａ）前記第２の携帯型大容量記憶装置が前記第１の携帯型大容量記憶装置のものと同等かまたはそれ以上の容量を有すると判定するステップと、
（ｂ）前記第２の携帯型大容量記憶装置が、前記第１の携帯型大容量記憶装置とコンパチブルなセキュリティメカニズムを含むセキュアタイプであると判定するステップと、
（ｃ）（ａ）および（ｂ）が首尾よく判定されたならば、前記第１の携帯型大容量記憶装置と前記第２の携帯型大容量記憶装置との間にセキュアチャネルを確立するステップと共に前記第２の携帯型大容量記憶装置の真正性をベリファイするステップと、
（ｄ）ステップ（ｃ）で前記真正性がベリファイされたならば、
（ｅ）オペレーティングファームウェアおよびセキュリティパラメータを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｆ）前記第１の携帯型大容量記憶装置のパーティションマップをリサイズするべきか否かを、それを前記第２の携帯型大容量記憶装置に転送する前に、判定するステップと、
（ｇ）前記パーティションマップを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｈ）前記パーティションマップ内の各パーティションについて、パーティションデータを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｉ）ステップ（ａ）から（ｈ）までの完全な実行を確認するステップと、
（ｊ）ステップ（ｉ）で確認が受け取られなければ、前記第１の携帯型大容量記憶装置を、ステップ（ｉ）から前記確認が受け取られるまで、それが使用不能の状態に留まるモードにするステップと、
を含む方法。
【請求項２５】
請求項２４記載の方法において、
ステップ（ｉ）で確認が受け取られたならば、前記オペレーティングファームウェアおよび前記セキュリティパラメータおよび前記パーティションマップおよび前記パーティションデータを前記第１の携帯型大容量記憶装置から削除するステップをさらに含む方法。
【請求項２６】
請求項２４記載の方法において、
前記第１の携帯型大容量記憶装置の前記真正性をベリファイし、これにより、前記第１の装置および前記第２の装置の両方を互いに対して認証するダブルチャレンジプロセスを完了させるステップをさらに含む方法。
【請求項２７】
請求項２４記載の方法において、
前記真正性をベリファイするステップは、
前記装置のうちの開始装置において第１の乱数を生成し、それを前記装置のうちの応答装置に渡すステップと、
前記第１の乱数を前記応答装置で暗号化するステップと、
前記第１の乱数を暗号化された形で前記開始装置に渡すステップと、その後に
前記暗号化されている第１の乱数を前記開始装置で復号化し、それを生成されたままの前記数と比較するステップと、
を含む方法。
【請求項２８】
請求項２７記載の方法において、
前記真正性をベリファイするステップは、
前記装置のうちの応答装置で第２の乱数を生成し、それを前記装置のうちの開始装置に渡すステップと、
前記第２の乱数を前記開始装置で暗号化するステップと、
前記第２の乱数を暗号化されている形で前記応答装置に戻すステップと、その後に
前記暗号化されている第２の乱数を前記応答装置で復号化し、それを生成されたままの前記数と比較するステップと、
をさらに含む方法。
【請求項２９】
請求項２４記載の方法において、
前記セキュアチャネルを確立するステップは、
前記装置のうちの前記開始装置で第３の乱数を生成するステップと、
前記第３の乱数を前記開始装置で暗号化するステップと、
前記第３の乱数を前記応答装置に渡すステップと、
それを前記応答装置で復号化するステップと、
第４の乱数を前記応答装置で生成するステップと、
前記復号化された第３の乱数と前記第４の乱数とに対して前記応答装置で排他的論理和演算を実行するステップと、
を含む方法。
【請求項３０】
請求項２９記載の方法において、
セキュアデータベースおよび前記パーティションマップを前記排他的論理和演算の結果に基づいて暗号化関数で暗号化するステップをさらに含む方法。
【請求項３１】
請求項２４記載の方法において、
前記真正性をベリファイするステップは、
アノニマス公開キーをアノニマス秘密キーでベリファイするステップであって、それらのアノニマスキーがアイデンティティのプルーフを提供できないものである、ベリファイするステップと、
前記装置の前記アイデンティティを、それが信頼されるオーソリティの署名を有することを判定することによって、ベリファイするステップと、
を含む方法。
【請求項３２】
請求項３１記載の方法において、
前記アノニマス公開キーおよび前記アノニマス秘密キーは、ＲＳＡキーペアを構成する方法。
【請求項３３】
請求項３２記載の方法において、
前記アノニマス公開キーは、ＰＫＩ証明書に含まれる方法。
【請求項３４】
同じタイプの他のドライブからコピーされたプロテクトされるコンテンツの使用を許さないフラッシュメモリドライブにおいて、オペレーティングファームウェアおよびプロテクトされるコンテンツをソースドライブからターゲットドライブに、前記ターゲットドライブが前記ファームウェアを利用することができかつ前記ソースドライブから転送された前記コンテンツにアクセスできるように、転送するための方法であって、
前記ターゲットドライブからの前記ターゲットドライブのアイデンティティを証明する証明書を取り出させるステップと、
前記ターゲットドライブ証明書を前記ソースドライブに送らせるステップと、
前記ソースドライブにおいて前記ターゲットドライブ証明書をベリファイするステップと、
前記プロテクトされるコンテンツをコンテンツキーで暗号化させて前記ソースドライブから前記ターゲットドライブに送らせ、その直後に前記ソースドライブを、前記プロテクトされるコンテンツの使用が最早許されない状態にロックするステップと、
前記コンテンツキーをターゲット公開キーで暗号化させるステップと、
暗号化された前記コンテンツキーを前記ターゲットに送らせるステップと、
前記プロテクトされるコンテンツを前記ターゲットに格納させるステップと、
を含む方法。
【請求項３５】
請求項３４記載の方法において、
前記コンテンツが前記ターゲットドライブに格納されたということの署名入り肯定応答を送るステップと、
前記プロテクトされるコンテンツを前記ソースドライブから消去させるステップと、
をさらに含む方法。
【請求項３６】
請求項３５記載の方法において、
前記署名入り肯定応答は、前記ターゲット秘密キーで暗号化されたマテリアルを含む方法。
【請求項３７】
請求項３４記載の方法において、
前記ターゲットドライブ証明書は、中間のホストを介して前記ソースドライブに送られる方法。
【請求項３８】
請求項３４記載の方法において、
前記ターゲットドライブからの前記ターゲットドライブのアイデンティティを証明する証明書を取り出させるステップは、前記ターゲットがホスト装置に接続された後にトリガされる方法。
【請求項３９】
請求項３４記載の方法において、
前記ターゲットドライブ証明書は、中間のホストを介して前記ソースドライブに送られる方法。
【請求項１】
フラッシュストレージドライブ上のデータをプロテクトし、その後に、リクエストされたならば、そのプロテクトされる、通常は転送不能のデータを、ソースフラッシュストレージドライブからターゲットフラッシュストレージドライブに転送する方法であって、
転送不能であり、かつ単一のドライブに前記ドライブの寿命の間一意に関連付けられ、さらに前記ドライブのどのソフトウェアもアクセスできないハードウェアキーを前記ソースドライブにおいて提供するステップと、
前記ソースドライブのオペレーティングファームウェアを前記ハードウェアキーで暗号化するステップと、
前記ソースドライブの秘密の、ホスト装置がアクセスできないシステムパーティションに、前記ハードウェア暗号化されたオペレーティングファームウェアを格納するステップと、
ソフトウェアに基づく暗号化キーのグループを前記ソースドライブの前記システムパーティションに格納するステップと、
前記ソースドライブのユーザファイルと、存在するならばアプリケーションとを含む前記ソースドライブのコンテンツを前記ターゲットドライブに転送するためのリクエストを受け取るステップと、 前記ターゲットドライブの真正性を判定するステップと、
真性であると判定されたならば、前記ソースカードの前記オペレーティングファームウェアを前記ソースドライブに特有の前記ハードウェアキーで復号化するステップと、
前記ソースドライブと前記ターゲットドライブとの間のセキュアセッションを確立して、前記セキュアセッションの間に前記オペレーティングファームウェアを前記ソースドライブから前記ターゲットドライブに転送するステップと、
転送不能であり、かつ前記ターゲットドライブに前記ドライブの寿命の間一意に関連付けられるターゲットハードウェアキーで、前記ターゲットドライブにおいて前記オペレーティングファームウェアを再暗号化し、これにより前記ターゲットドライブが前記オペレーティングファームウェアを利用することを一意に可能にするステップと、
を含む方法。
【請求項２】
請求項１記載の方法において、
前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップは、前記アプリケーションを秘密パーティションに格納するステップを含む方法。
【請求項３】
請求項１記載の方法において、
前記暗号化され格納されたファイルはホスト装置にとっては自由にアクセス可能であり、従って適切なソフトウェアキーを持っていないホスト装置は前記ファイルを自由にコピーできるけれどもそれらを復号化することができない方法。
【請求項４】
請求項１記載の方法において、
前記セキュアセッションの間に前記オペレーティングファームウェアを前記ソースドライブから前記ターゲットドライブに転送するステップは、
転送の前に前記復号化されたオペレーティングファームウェアを、前記ソースドライブおよび前記ターゲットドライブの両方の前記ハードウェアキーおよびソフトウェアキーから独立しているセッションキーで暗号化するステップと、
前記オペレーティングファームウェアを、前記ターゲットへの到着の直後に前記セッションキーで復号化するステップと、その後に
前記オペレーティングファームウェアを前記ターゲットドライブにおいてハードウェアキーで再暗号化するステップと、
を含む方法。
【請求項５】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループを前記ハードウェアキーで暗号化するステップをさらに含む方法。
【請求項６】
請求項１記載の方法において、
前記ハードウェアに適切にバインドされていないファームウェアは前記ソフトキーにも前記ドライブの他のコンテンツにもアクセスできない方法。
【請求項７】
請求項１記載の方法において、
前記ハードウェア暗号化されたオペレーティングファームウェアを前記ターゲットドライブのシステムパーティションに格納するステップをさらに含む方法。
【請求項８】
請求項１記載の方法において、
前記ソースドライブから前記ターゲットドライブへの転送の間、前記オペレーティングファームウェア、前記ソフトウェアに基づく暗号化キーのグループ、前記アプリケーション、および前記ユーザファイルのうちの１つ以上は前記ソースドライブから前記ターゲットドライブへのルート上で前記ソースドライブあるいは前記ターゲットドライブ以外の中間記憶ユニットに一時的に格納される方法。
【請求項９】
請求項１記載の方法において、
前記ソースドライブ上で動作するソフトウェアアプリケーションを、前記ソフトウェアに基づく暗号化キーのグループのうちの１つで暗号化するステップをさらに含む方法。
【請求項１０】
請求項９記載の方法において、
前記ソースストレージドライブの前記ハードウェアキーから独立しているアプリケーション特有のセキュリティメカニズムを有する前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップと、
前記暗号化されたアプリケーションの前記アプリケーション特有のセキュリティメカニズムを用いてユーザファイルを暗号化するステップと、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブの前記フラッシュメモリに格納するステップと、
ユーザファイルにアクセスするためのリクエストを前記ホスト装置のファイルマネージャから時々受け取るステップと、
前記オペレーティングファームウェアで、前記ファイルを、前記ファイルにアクセスするために使用されるアプリケーションに相関させ、かつ前記アプリケーションのアプリケーション特有のセキュリティメカニズムを呼び出すことによって、リクエストされた時に前記ユーザファイルにアクセスするステップと、
をさらに含む方法。
【請求項１１】
請求項７記載の方法において、
前記ターゲットドライブの前記真正性がベリファイされたならば、前記ソフトウェアに基づく暗号化キーのグループと前記アプリケーションとを前記ソースドライブから前記ターゲットドライブに転送するステップと、
前記アプリケーションを暗号化されたフォーマットで前記ターゲットフラッシュストレージドライブのフラッシュメモリに格納するステップと、
をさらに含む方法。
【請求項１２】
請求項１１記載の方法において、
前記ターゲットドライブの前記ユーザファイルを前記ストレージドライブに転送するステップをさらに含む方法。
【請求項１３】
請求項１１記載の方法において、
前記オペレーティングファームウェア、前記ソフトウェアに基づく暗号化キーのグループ、および前記アプリケーションが前記ソースドライブから前記ターゲットドライブに転送されたことをベリファイするステップをさらに含む方法。
【請求項１４】
請求項１３記載の方法において、
ベリファイが成功したならば、前記ユーザファイルを前記ソースドライブから削除するステップをさらに含む方法。
【請求項１５】
請求項１３記載の方法において、
ベリファイが成功したならば、ターゲットカードをアクティブ化するステップをさらに含む方法。
【請求項１６】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループのうちの少なくとも１つは、前記ソースドライブを一意に特定する情報の関数である方法。
【請求項１７】
請求項１６記載の方法において、
前記ソースドライブを一意に特定する前記情報は、前記ドライブのシリアルナンバーを含む方法。
【請求項１８】
請求項１記載の方法において、
前記ソフトウェアに基づく暗号化キーのグループのうちの少なくとも１つは、前記ドライブのユーザに関連付けられた情報の関数である方法。
【請求項１９】
請求項１８記載の方法において、
前記ユーザに関連付けられた前記情報は、ドライブからドライブへと転送可能である方法。
【請求項２０】
請求項１９記載の方法において、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップは、アプリケーションプログラミングインターフェイスのリクエストに応答して１つ以上のファイルを暗号化するために前記ソフトウェアに基づく暗号化キーのうちの１つ以上を利用するステップをさらに含む方法。
【請求項２１】
請求項１記載の方法において、
アプリケーション特有のセキュリティメカニズムは、前記ソースドライブを一意に特定する情報の関数であるダイバーシフィケーション方法を利用する方法。
【請求項２２】
請求項２１記載の方法において、
アプリケーションがリモートサーバについて認証を受けるために前記ソースドライブに特有の情報に依存し、前記アプリケーションがターゲットドライブに転送されるならば、前記認証のための前記ソースドライブに特有の情報も前記ターゲットドライブに転送される方法。
【請求項２３】
フラッシュストレージドライブ上のデータをプロテクトし、その後に、リクエストされたならば、そのプロテクトされる、通常は転送不能のデータを、ソースフラッシュストレージドライブからターゲットフラッシュストレージドライブに転送する方法であって、
転送不能であり、かつ単一のドライブに前記ドライブの寿命の間一意に関連付けられるハードウェアキーを前記ソースドライブにおいて提供するステップと、
前記ソースドライブのオペレーティングファームウェアを前記ハードウェアキーで暗号化するステップと、
前記ソースドライブの、ホスト装置がアクセスできない第１の秘密パーティションに、前記ハードウェア暗号化されたオペレーティングファームウェアを格納するステップと、
ソフトウェアに基づく暗号化キーのグループを前記ソースドライブの前記第１の秘密パーティションに格納するステップと、
前記ソフトウェアに基づく暗号化キーのグループのうちの１つでアプリケーションを暗号化するステップと、
前記ソースストレージドライブの前記ハードウェアキーから独立しているアプリケーション特有のセキュリティメカニズムを有する前記暗号化されたアプリケーションを前記ソースフラッシュストレージドライブのフラッシュメモリに格納するステップと、
前記暗号化されたアプリケーションの前記アプリケーション特有のセキュリティメカニズムを用いてユーザファイルを暗号化するステップと、
前記アプリケーション特有のメカニズムでプロテクトされる前記ユーザファイルを前記ソースフラッシュストレージドライブの前記フラッシュメモリに格納するステップと、
を含む方法。
【請求項２４】
第１の携帯型大容量記憶装置から第２の携帯型大容量記憶装置にアップグレードする方法であって、前記第１および第２の携帯型大容量記憶装置の両方は、前記装置に格納されているコンテンツのコピーがコピーされてもそれが他の装置上で動作するのを防止するためのファームウェアを有する、方法において、
（ａ）前記第２の携帯型大容量記憶装置が前記第１の携帯型大容量記憶装置のものと同等かまたはそれ以上の容量を有すると判定するステップと、
（ｂ）前記第２の携帯型大容量記憶装置が、前記第１の携帯型大容量記憶装置とコンパチブルなセキュリティメカニズムを含むセキュアタイプであると判定するステップと、
（ｃ）（ａ）および（ｂ）が首尾よく判定されたならば、前記第１の携帯型大容量記憶装置と前記第２の携帯型大容量記憶装置との間にセキュアチャネルを確立するステップと共に前記第２の携帯型大容量記憶装置の真正性をベリファイするステップと、
（ｄ）ステップ（ｃ）で前記真正性がベリファイされたならば、
（ｅ）オペレーティングファームウェアおよびセキュリティパラメータを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｆ）前記第１の携帯型大容量記憶装置のパーティションマップをリサイズするべきか否かを、それを前記第２の携帯型大容量記憶装置に転送する前に、判定するステップと、
（ｇ）前記パーティションマップを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｈ）前記パーティションマップ内の各パーティションについて、パーティションデータを前記第１の携帯型大容量記憶装置から前記第２の携帯型大容量記憶装置にコピーするステップと、
（ｉ）ステップ（ａ）から（ｈ）までの完全な実行を確認するステップと、
（ｊ）ステップ（ｉ）で確認が受け取られなければ、前記第１の携帯型大容量記憶装置を、ステップ（ｉ）から前記確認が受け取られるまで、それが使用不能の状態に留まるモードにするステップと、
を含む方法。
【請求項２５】
請求項２４記載の方法において、
ステップ（ｉ）で確認が受け取られたならば、前記オペレーティングファームウェアおよび前記セキュリティパラメータおよび前記パーティションマップおよび前記パーティションデータを前記第１の携帯型大容量記憶装置から削除するステップをさらに含む方法。
【請求項２６】
請求項２４記載の方法において、
前記第１の携帯型大容量記憶装置の前記真正性をベリファイし、これにより、前記第１の装置および前記第２の装置の両方を互いに対して認証するダブルチャレンジプロセスを完了させるステップをさらに含む方法。
【請求項２７】
請求項２４記載の方法において、
前記真正性をベリファイするステップは、
前記装置のうちの開始装置において第１の乱数を生成し、それを前記装置のうちの応答装置に渡すステップと、
前記第１の乱数を前記応答装置で暗号化するステップと、
前記第１の乱数を暗号化された形で前記開始装置に渡すステップと、その後に
前記暗号化されている第１の乱数を前記開始装置で復号化し、それを生成されたままの前記数と比較するステップと、
を含む方法。
【請求項２８】
請求項２７記載の方法において、
前記真正性をベリファイするステップは、
前記装置のうちの応答装置で第２の乱数を生成し、それを前記装置のうちの開始装置に渡すステップと、
前記第２の乱数を前記開始装置で暗号化するステップと、
前記第２の乱数を暗号化されている形で前記応答装置に戻すステップと、その後に
前記暗号化されている第２の乱数を前記応答装置で復号化し、それを生成されたままの前記数と比較するステップと、
をさらに含む方法。
【請求項２９】
請求項２４記載の方法において、
前記セキュアチャネルを確立するステップは、
前記装置のうちの前記開始装置で第３の乱数を生成するステップと、
前記第３の乱数を前記開始装置で暗号化するステップと、
前記第３の乱数を前記応答装置に渡すステップと、
それを前記応答装置で復号化するステップと、
第４の乱数を前記応答装置で生成するステップと、
前記復号化された第３の乱数と前記第４の乱数とに対して前記応答装置で排他的論理和演算を実行するステップと、
を含む方法。
【請求項３０】
請求項２９記載の方法において、
セキュアデータベースおよび前記パーティションマップを前記排他的論理和演算の結果に基づいて暗号化関数で暗号化するステップをさらに含む方法。
【請求項３１】
請求項２４記載の方法において、
前記真正性をベリファイするステップは、
アノニマス公開キーをアノニマス秘密キーでベリファイするステップであって、それらのアノニマスキーがアイデンティティのプルーフを提供できないものである、ベリファイするステップと、
前記装置の前記アイデンティティを、それが信頼されるオーソリティの署名を有することを判定することによって、ベリファイするステップと、
を含む方法。
【請求項３２】
請求項３１記載の方法において、
前記アノニマス公開キーおよび前記アノニマス秘密キーは、ＲＳＡキーペアを構成する方法。
【請求項３３】
請求項３２記載の方法において、
前記アノニマス公開キーは、ＰＫＩ証明書に含まれる方法。
【請求項３４】
同じタイプの他のドライブからコピーされたプロテクトされるコンテンツの使用を許さないフラッシュメモリドライブにおいて、オペレーティングファームウェアおよびプロテクトされるコンテンツをソースドライブからターゲットドライブに、前記ターゲットドライブが前記ファームウェアを利用することができかつ前記ソースドライブから転送された前記コンテンツにアクセスできるように、転送するための方法であって、
前記ターゲットドライブからの前記ターゲットドライブのアイデンティティを証明する証明書を取り出させるステップと、
前記ターゲットドライブ証明書を前記ソースドライブに送らせるステップと、
前記ソースドライブにおいて前記ターゲットドライブ証明書をベリファイするステップと、
前記プロテクトされるコンテンツをコンテンツキーで暗号化させて前記ソースドライブから前記ターゲットドライブに送らせ、その直後に前記ソースドライブを、前記プロテクトされるコンテンツの使用が最早許されない状態にロックするステップと、
前記コンテンツキーをターゲット公開キーで暗号化させるステップと、
暗号化された前記コンテンツキーを前記ターゲットに送らせるステップと、
前記プロテクトされるコンテンツを前記ターゲットに格納させるステップと、
を含む方法。
【請求項３５】
請求項３４記載の方法において、
前記コンテンツが前記ターゲットドライブに格納されたということの署名入り肯定応答を送るステップと、
前記プロテクトされるコンテンツを前記ソースドライブから消去させるステップと、
をさらに含む方法。
【請求項３６】
請求項３５記載の方法において、
前記署名入り肯定応答は、前記ターゲット秘密キーで暗号化されたマテリアルを含む方法。
【請求項３７】
請求項３４記載の方法において、
前記ターゲットドライブ証明書は、中間のホストを介して前記ソースドライブに送られる方法。
【請求項３８】
請求項３４記載の方法において、
前記ターゲットドライブからの前記ターゲットドライブのアイデンティティを証明する証明書を取り出させるステップは、前記ターゲットがホスト装置に接続された後にトリガされる方法。
【請求項３９】
請求項３４記載の方法において、
前記ターゲットドライブ証明書は、中間のホストを介して前記ソースドライブに送られる方法。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図５Ｃ１】
【図５Ｃ２】
【図５Ｃ３】
【図６】
【図１Ｂ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図５Ｃ１】
【図５Ｃ２】
【図５Ｃ３】
【図６】
【公表番号】特表２０１０−５１５１５９（Ｐ２０１０−５１５１５９Ａ）
【公表日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願番号】特願２００９−５４４１８２（Ｐ２００９−５４４１８２）
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８７９００
【国際公開番号】ＷＯ２００８／０８２９４９
【国際公開日】平成２０年７月１０日（２００８．７．１０）
【出願人】（５０６１９７９０１）サンディスク コーポレイション (175)
【Ｆターム（参考）】
【公表日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８７９００
【国際公開番号】ＷＯ２００８／０８２９４９
【国際公開日】平成２０年７月１０日（２００８．７．１０）
【出願人】（５０６１９７９０１）サンディスク コーポレイション (175)
【Ｆターム（参考）】
[ Back to top ]