本発明は、ホストとメモリカードの間でアプリケーション特有の命令を伝送するための技法を呈示している。アプリケーション特有プロトコル用のコマンドは、ホストとメモリカードの間で通信するのに用いられる伝送プロトコルのデータ部分に、シグネチャーと共に埋め込まれている。これによって、伝送プロトコルに対応するコマンドを欠いているアプリケーション特有コマンドの伝送でも、なおそのプロトコルで伝送できるようになる。本方法は、ホスト側で、デバイスドライバレベル、又はファイルレベルの何れでも実施することができる。アプリケーション特有プロトコルの読み取りコマンドを実施するために、読み取りコマンドが埋め込まれている第１プロトコルの書き込みコマンドが、先ず、論理アドレスに送られ、続いて、第２読み取りコマンドが同じ論理アドレスに送られる。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概括的には、取り外し可能な電子回路カードの使用と構造に、より具体的には、パーソナルコンピューター又は他のホストが、メディア特有のカードコマンドを、これらのコマンドをサポートしないリーダー及び／又はホストソフトウェアを通して、使用できるようにすることに関する。
【背景技術】
【０００２】
最近、コンパクトフラッシュカード、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ｘＤ、及びソニーメモリスティック／メモリスティックＰｒｏの様な小型フォーマットフラッシュメモリカードが、消費者に広く受け容れられている。これらのデバイスは、主に、デジタルカメラ及びフラッシュメモリ音楽プレーヤーの様な消費者用電子機器のために設計されている。しかしながら、それらは、更に、データをアップロード及びダウンロードするために、パーソナルコンピューターへ使い勝手良く接続できるようになっているのが望ましい。
【０００３】
カードが違えば、電気的インターフェースも異なり、そのカード用のホストが使うことのできるメディア特定のコマンドを有していることも多い。更に、カードプロトコルは、カードのフォームファクタ相互間で異なるだけでなく、同じフォームファクタを有する様々なカード相互間でも異なるが、それは、これらのカードが、カード毎に異なることがある追加的機能でオーバーロードになった状態で開始されるからである。コマンドは、しばしば、特別な入力−出力（Ｉ／Ｏ）及びセキュリティオペレーションの様な固有の機能を有している。その様なカードの使用法は更に多様になり、より多くの型式のアプリケーションで用いられるので、これらの新規のアプリケーションは、既存のプロトコルには無い機能又はコマンドを伴うことも多い。
【０００４】
異なる機械的及び／又は電気的インターフェースを有する市販の不揮発性メモリカードの例には、本出願の譲受人であるカリフォルニア州サニーベールのＳａｎＤｉｓｋ（サンディスク）社から販売されている同類のマルチメディアカード（「ＭＭＣ」）とセキュアデジタル（「ＳＤ」）メモリカードが含まれる。国際標準化機構（「ＩＳＯ」）と国際電気標準会議（「ＩＥＣ」）の標準に準拠している他のカードもあり、広く実施されている例は、ＩＳＯ／ＩＥＣ７８１６標準として知られている。
【０００５】
ＭＭＣの物理的及び電気的仕様は、「マルチメディアカードシステム仕様書」に定められており、カリフォルニア州クパチーノのマルチメディアカード協会（「ＭＭＣＡ」）によって時々更新され、発行されている。１９９９年６月、２０００年１月、２００１年６月、及び２００４年２月付けの、その仕様書の２．１１、２．２、３．１、及び４．０バージョンを、それぞれ参考文献として明確にここに援用する。１枚のカードに１２８メガバイトまでの様々な記憶容量を有するＭＭＣ製品は、現在ＳａｎＤｉｓｋ社から販売されている。これらの製品については、ＳａｎＤｉｓｋ社が発行した２０００年４月付けの「マルチメディアカード製品マニュアル」改訂第２版に記載されており、このマニュアルを参考文献として明確にここに援用する。ＭＭＣ製品の電気的オペレーションの或る態様については、米国特許第６，２７９，１４４号と、１９９８年１１月４日出願の米国特許出願第０９／１８６，０６４号にも記載されている。物理的なカード構造と、それを製造する方法は、米国特許第６，０４０，６２２号に記載されている。ＳａｎＤｉｓｋ社に譲渡されているこれらの特許出願及び特許を、参考文献として明確にここに援用する。
【０００６】
更に新しいＳＤカードは、ＭＭＣカードに似ており、追加のメモリチップを収容する厚み増加以外は、同じ寸法を有している。両者の大きな違いは、ＳＤカードが、カードとホストの間のデータ転送をより速くできるようにするため、追加的データ接点を含んでいることである。（追加的データ接点を備えたＭＭＣカードのバージョンも入手できる――、先に述べたＭＭＣ仕様書のバージョン４．０を参照されたい。）ＳＤカードの別の接点は、ＳＤカードを受け入れるように設計されているソケットがＭＭＣカードも受け入れるようにするため、ＭＭＣカードの接点と同じになっている。ＳＤカードとの電気的及び機能的なインターフェースは、更に、米国特許第６，８２０，１４８号に記載されている様に、ＳＤカードを受け入れるように設計されているソケットを、ＭＭＣカードも受け入れることができるように作られており、上記特許を参考文献としてここに援用する。ＳＤカードの或る態様については、２０００年８月１７日出願の米国特許出願第０９／６４１，０２３号に記載されており、同出願を参考文献としてここに援用する。（ＳＤカードの仕様書は、ＳＤ協会（ＳＤＡ）のメンバー会社には入手可能である。）
【０００７】
ＩＳＯ／ＩＥＣ７８１６標準に従って作られたカードは、形状が異なり、異なる位置に表面接点を有しており、ＭＭＣ及びＳＤカードとは異なる電気的インターフェースを有している。ＩＳＯ／ＩＥＣ７８１６標準は、「識別（ＩＤ）カード−接点を備えた集積回路カード」という総タイトルを有しており、１９９４年から２０００年までの個別のデータを担持する第１−１０部で構成されている。この標準は、その複写をスイスのジュネーブのＩＳＯ／ＩＥＣから入手可能であり、参考文献として明確にここに援用する。ＩＳＯ／ＩＥＣ７８１６カードは、認可されていない方式でデータを読み取ることを極めて難しく又は不可能にする安全な方式でデータを記憶しなければならない用途では、特に有用である。小さなＩＳＯ／ＩＥＣ７８１６カードは、各種用途の中でも、携帯電話で広く用いられている。先に述べた様に、その様なメモリカードが新しい用途に用いられる場合、それらは、プロトコルの既存のバージョンに欠けている機能又はコマンドを必要とすることがある。この状況を図１に示している。図１の上部に示している様に、目的は、ホスト側とカード側の特定のアプリケーションの間でコマンドとデータを交換すること、換言すると安全なデータ転送又はｅコマース・アプリケーションにある。これを実施するために、コマンドは、ホストとカードの間で伝送される必要があり、図１の下部は、ホスト側の幾つかのソフトウェア層と、カード側の幾つかのファームウェア層を示している。ホストのアプリケーション層からの命令は、オペレーティングシステム、ファイル層、及びデバイス（カード）ドライバを通して送られ、命令がカードに伝送されるプロトコルで終了する。カード内で、命令は、標準的なカード操作を取り扱うデバイス層のファームウェアによって取り上げられ、ファームウェアのアプリケーション層に送られる。伝送プロトコルの命令は、用いられている設備次第で、ホストからカードへ直接に、又は、適用されているリーダー又はハードウェアを通して、の何れかで交換されることになり、そのリーダー又はハードウェアは、１つのプロトコルから別のプロトコルに翻訳するのに用いられる自身のソフトウェア／ファームウェア層を有してもよい。問題が生じ得るのは、これらの層の間の翻訳における或る段階で、アプリケーションの意図された命令が、途中のある点で、対応するコマンドを欠いていることがある場合である。
【０００８】
１つの例として、カードは、しばしば、ホストシステムからのコマンドを受け入れるハードウェアアダプター（例えば、ＵＳＢ用）を使用することにより、ＰＣホストと接続される。しかしながら、ＰＣホストのホストアプリケーションが、これらのコマンドをカードアプリケーションに伝送したくても、メディア特定コマンドの多くは、ホストとハードウェアアダプターが通信するプロトコルで利用できない。
【０００９】
図２は、第１ホストとカードのシステムを示しており、カード１０１は、スロット１５３に挿入するなど直接に、又はある種のアダプターを通して、の何れかでホスト１５１に接続することができる。カードのファームウェアは、ＦＷ１０５で示されている。（図３のカードファームウェア１０５とリーダーファームウェア３３５の両方に関して、より一般的には、これらの機能は、ハードウェア、ソフトウェア、又はこれらの或る組み合わせで実現されるものと理解されたい。）その様なホスト１５１の一例は、デジタルカメラ又は電話である。多数の型式のその様なカードが、目下使用されており、開発されている。カードとホストは、多数の特定のプロトコルを通して通信し、その多くが特定のメディアに特有のものであり、プロトコルは様々なメディア特定のコマンドを含んでいることがある。コマンドの多くはメディア特有であってもよいので、その様なコマンドがホストとメディアの間で交換されるとき、ラインに沿ったどこかで、コマンドを、メディア特有のコマンドをサポートしていない別のプロトコルに翻訳しなければならない場合がある。この別のプロトコルが対応するコマンドを有していない場合、ホストは、コマンドを成功裏に発行することができなくなる。
【００１０】
例えば、カードをホスト内で使用するだけでなく、ユーザーが、パーソナルコンピューター上でカードにアクセスするのも一般的である。例えば、デジタルカメラで使用したカードの場合、カードに記憶されている写真にパーソナルコンピューター上でアクセスしたいと思うのも普通のことである。この状況を、図３のボックス線図で示している。カード１０１は、通常、カード１０１の受口３３３を有するカードリーダー３３１を通して、パーソナルコンピューターＰＣ３５１と通信できるようにするが、カードがＰＣ３５１に直接取り付けられてもよい場合もある。リーダー３３１とＰＣ３５１は、通常、カード１０１がホスト１５１と通信するのに使用するプロトコルとは少なくともある程度は異なる或るプロトコルを通して通信することになる。リーダー３３１は、ファームウェア３３５（又はハードウェア、ソフトウェア、又はそれらの組み合わせ）に基づいて、ＰＣ３５１からのコマンドを、カード１０１に適した形態に翻訳するが、その際一般的には、この機能は、実施形次第で、ソフトウエァとハードウェアの何らかの組み合わせで実行できるものと理解されたい。このプロセスを、図４に概略的に示している。
【００１１】
具体的な例を提供するため、図４では、リーダー３３１は、ＳＣＳＩコマンドセットを使用してＰＣ３５１と通信するＵＳＢデバイスとしており、カード１０１は、ＳＤカードとしている。ＰＣ３５１とリーダー３３１は、ＳＣＳＩプロトコルを使用するので、ホストがリーダーを通してコマンドをカードに発行したいとき、ホストは、コマンド４０１をＳＣＳＩコマンドセットで発行する。コマンド４０１をリーダーに転送するために、コマンドは、ＵＳＢラッパー４０３内に置かれ、ＵＳＢ接続に沿ってリーダーに伝送され、そこでＵＳＢラッパーが取り外される。カードリーダー３３１は、次に、コマンド４０１を、ＳＣＳＩコマンドセットから、ＳＤセットの対応する１つ又は複数のコマンド４０５に翻訳し、それがカード１０１に送られるようになるが、リーダーが、ＳＣＳＩコマンドセットとＳＤコマンドセットの間で所与のコマンドを翻訳する場合、両方のセットで等価なコマンドとなる必要がある。従って、ホストが、例えば、ＳＤプロトコルで安全な読み取りコマンドを発行することによって、ＳＤカードの安全領域の読み取りを実行したい場合は、その様なＳＣＳＩ等価物がないので、リーダーは、それがＳＣＳＩコマンドセット内では見つからないため、これを翻訳する方法がなく、読み取り要求は、ユーザーのアクセス権が不十分な領域に向けられているとみなされることになる。同じ状況は、ホストがリーダーにリーダーが理解するプロトコルで送るための１つ又は複数の等価なＳＣＳＩコマンドが無い場合、様々なカード型式用の他のメディア特定コマンドにも当て嵌まる。
【００１２】
従って、その様なメディアカード特有のコマンドは、アダプターのファームウェア又はメディアカードをホストするリーダーを変えて、メディアカードがホストと通信するのに使用するプロトコルに対応するコマンドを導入すること無く、ホストからカードに送ることはできない。別体のカードリーダーでなくても、通信経路に沿った何処かにプロトコルの変化が必要なとき、又は、ホストのオペレーティングシステムがカードの特徴に気付かないときは、同様の状況が生じ得る。
【００１３】
先行技術では、この問題の対処法は、アダプターのファームウェアを変えてアダプターを通してその様な命令を送るための特別なコマンドをサポートするか、又はリーダー−ホストプロトコルで新しいコマンドを作成するかの何れかであり、その何れも、例えば、ＳＤカードのプロトコルで、チャレンジコマンドを送信し、応答コマンドを受信するなどに対応するコマンドの様な、特定のメディアコマンドに合わせて作られる。これらの対処法は、多くの理由で、実用的ではない。先ず、プロトコルは、有用であるためには広く受け入れられる必要があるので、普通は標準に基づいており、あまり複雑でないコマンドセットが好まれる傾向があり、従って、新しいメディアが導入されると既存のメディアは進化するので、様々な新しいメディア特定のコマンドをコマンドセットに導入するのは難しい。代わりに、特別なコマンドが、自体をサポートしないメディア特定コマンドを通過できるようにアダプターのファームウェアが変更されれば、その様なアダプターの各ベンダのソフトウェアは、適切なファームウェアの変更を受け入れて、作る必要がある。従って、リーダーのファームウェア又はホスト−リーダープロトコルの何れかを変える必要無しに、パーソナルコンピューターが様々なメディア特定コマンドを利用できるようにする方法を導入することは、非常に有用である。
【００１４】
より一般的には、カードがホストに直接接続されているときでも、新しいアプリケーション特定コマンドが導入されると、プロトコルは更新される必要がある。既存のプロトコルが新しい機能を組み込むように拡張され、標準化されたとしても、このことにより、旧バージョン又はそれらの他のベンダとの互換性に関わる問題が持ち込まれ、標準化されたプロトコルの実用性が大きく害される。更に、プロトコルを、新しいアプリケーションに適合させてもよいが、カードの使用を拡げるために更に多くのアプリケーションが生じてくるので、一時的な解決法に過ぎない。従って、やはり、ホストのオペレーティングシステムがメディア特定コマンドをサポートしない場合に適応する必要がある。
【特許文献１】米国特許第６，２７９，１４４号
【特許文献２】米国特許出願０９／１８６，０６４号
【特許文献３】米国特許第６，０４０，６２２号
【特許文献４】米国特許第６，８２０，１４８号
【特許文献５】米国特許出願第０９／６４１，０２３号
【特許文献６】米国特許出願第１０／２５６，６８９号
【特許文献７】米国特許出願第２９／２０３，６９３号
【特許文献８】米国特許出願第１０／８２６，８０１号
【特許文献９】米国特許出願第１０／８２６，７９６号
【特許文献１０】米国仮特許出願第６０／６３８，８０４号
【特許文献１１】米国特許出願第１１／０６７，２９８号
【特許文献１２】米国特許出願第１０／７０３，４７１号
【特許文献１３】米国特許出願第１０／８９９，２６０号
【特許文献１４】米国特許出願第１１／０５０，０１３号
【特許文献１５】米国特許出願第１０／８４１，３７９号
【特許文献１６】米国特許出願第１１／０６０，２４９号
【特許文献１７】米国特許出願第１１／０６０，１７４号
【特許文献１８】米国特許出願第１１／０６０，２４８号
【非特許文献１】「マルチメディアカードシステム仕様書」２．１１、２．２、３．１、及び４．０版
【非特許文献２】「マルチメディアカード製品マニュアル」改訂第２版
【非特許文献３】ＩＳＯ／ＩＥＣ７８１６標準「識別カード−接点を備えた集積回路カード」
【発明の開示】
【課題を解決するための手段】
【００１５】
従って、本発明は、簡潔且つ概括的には、（メモリカード又は他の集積回路カードの様な）デバイスが、アプリケーション又はメディア特定コマンドをホストと交換する方法と技法を提供する。ホストとカードは、直接に、又はリーダー又はハードウェアアダプターを通して、の何れかで通信し、メディア特定コマンドの等価物を持っていないプロトコルを通して、アプリケーション特定コマンドを伝送する。例えば、１つの実施形態では、ＰＣは、たとえカードリーダーがその様なコマンドをサポートしていなくても、カードリーダーを通してＳＤ（セキュアデジタル）メモリカードの安全なデータ領域を読み取ることができる。
【００１６】
より具体的には、ホストは、ホストとカード間の通信経路間でサポートされているプロトコルのコマンドを有する命令を形成するが、実際のメディア又はアプリケーション特有コマンドは、その命令の中に埋め込まれている。代表的な実施形態では、メディア特有コマンドは、命令のデータ部分に埋め込まれている。次に、カードは、ホストと通信するプロトコルで命令を受信し、それをアプリケーションのプロトコルに翻訳する。埋め込まれたコマンドは、トランスペアレントな方法で送られる。例えば、伝送プロトコルは、実際にはデータにメディア特有コマンドが入っているのに、データであるとみなしたものを単にカードに送る。一旦カードに入ると、カードは、実際のコマンドが命令の中に埋め込まれていることを認識し、それを抽出する。このことは、コマンドのデータ部分がシグネチャーを含んでいると判断することによって行われ、シグネチャーが見つかれば、埋め込まれたコマンドが抽出されて実行され、シグネチャーが見つからなければ、伝送プロトコルのコマンドが実行される。代表的な実施形態では、シグネチャーと埋め込まれたコマンドは、データ部分の第１セクター内に置かれている。変換はデバイス側で実施され、実際のコマンドが抽出され、ホスト側では、コマンドがデバイスのドライバレベル又はファイルシステムレベルの何れかに埋め込まれる。デバイスのドライバレベルの実施では、コマンドを特定の論理ブロックのアドレスに指定するが、ファイルレベルでは、何れかの論理ブロックアドレスを用いることもできる。デバイスのドライバレベルの実施には、オーバーヘッドをあまり必要としないが、多くのオペレーティングシステムでは、ユーザーが持ち合わせないアクセス特権を必要とすることもある。
【００１７】
本発明の様々な態様は、カードプロトコルが、ホストとハードウェアカードリーダーの間で用いられるプロトコルに等価物を持っていないコマンドを有する場合に限定されず、中間プロトコルが、中間プロトコルに足りないコマンドを搬送しなければならない場合もある。第１組の実施形態は、カードが、自身のプロトコルで直接ホストと通信できるが、カード（又は他のデバイス）は、使用するには追加の一組のコマンドを必要とする、追加の一組の機能を備えたアプリケーションを有している場合を考えている。これらのコマンドは、ホストとカードが通信するのに使用する標準的なプロトコルの一部ではなく、即ちホスト上の標準的なオペレーティングシステムによってサポートされていない。従って、これらのコマンドを、カード上のアプリケーション（ファームウェアレベルで実施可能）とホスト上のアプリケーション（ソフトウェアレベルで実施可能）の間で送受信するには、特別な手段が必要である。本発明の基本的な態様では、アプリケーションコマンドは、中間プロトコル、この場合はカードプロトコル内の命令のデータ部分に埋め込まれている。本発明の別の態様では、これは、ホストアプリケーションからデバイスへの経路の開放、閉鎖、及び管理に関係する一組のコマンドを有することによって達成される。
【００１８】
第２の代表的な実施形態は、デバイス（カード）ドライバレベルで実施され、特定の論理ブロックアドレス（ｌｏｇｉｃａｌ ｂｌｏｃｋ ａｄｄｒｅｓｓ）（ＬＢＡ）、カードパススルー（ＣＰＴ）モードＬＢＡをデータセクターの特別なシグネチャーによって指定して、そのセクターに特別なコマンドが埋め込まれていることをカードに通知する命令を使用する。これは、ＣＰＴモードをサポートするようなカードのファームウェアの変更として実施される。これにより、各メディア特定コマンドに従ってアダプターのファームウェアを変える必要が無くなるので、カードは、メディア特定の適合構造を作る必要無しに（即ち、カードがどの様なＯＳの下でも使用できるようにホストのオペレーティングシステムを変更する必要無しに）、例えばどの様なＵＳＢリーダー又はアダプターででも実行させることができる。カードのファームウェアは、通常の読み取り／書き込みコマンドを尊重し続ける。特定のＬＢＡオフセットへの読み取り／書き込みコマンドがあれば、シグネチャーが検査され、データが、埋め込まれているメディアカード特定コマンドを含んでいるか否か判断される。プロトコルは、どの様なメディアカードのファームウェアででも実施することができる。従って、リーダーのファームウェアへの変更無しに、アダプター又はＵＳＢ又は他のリーダー又はホストＯＳにファームウェアの変更を必要としない。
【００１９】
第３組の代表的な実施形態は、ホスト側のファイルレベルで実施される。メディア特定コマンドは、ここでも中間プロトコルに埋め込まれているが、ハードウェア特定の、特別なプロトコルを参照することに依存するのではなく、埋め込まれたコマンドと付随するデータは、全て、ファイルのデータ部分に置かれ、それがメディアに転送され、そこで、ファームウェアが実際のコマンドを再抽出する。これらの実施形態では、ホストは、ファイルをメモリデバイスに書き込むようファイルシステムに告げるだけで、そこでデバイス特定のコマンドが再びデータ部分に埋め込まれる。どの様なＬＢＡへの読み取り／書き込みコマンドでも、特定の論理アドレスとは対照的に、デバイスはシグネチャーを検査し、データが、埋め込まれているメディアカード特定コマンドを含んでいるか否か判断する。代表的な実施形態は、このシグネチャーを、書き込みコマンドと関係付けられている全てのファイルのデータの第１セクターに置いている。適切なシグネチャーが見つかれば、埋め込まれたコマンドは抽出され、シグネチャーが見つからなければ、コマンドは、中間プロトコルの標準的なコマンドとして解釈される。この様に、本発明のファイルレベルの実施形態は、デバイスへのファイルの書き込みは、一般的にオペレーティングシステム内で許可されているので、デバイスレベルアプリケーションで特定の論理アドレスを使用させることになる特権問題を回避することができる。
【００２０】
全ての代表的な実施形態において、埋め込まれたコマンドは、中間プロトコルの書き込みコマンドのデータ部分に置かれる。例えば、デバイス又はアプリケーション特定プロトコルの、例えばＮ個のセクターの書き込みコマンドは、（Ｎ＋１）個のデータセクターを有する中間プロトコルの書き込みコマンドから成り、第１セクターには、実際に埋め込まれている書き込みコマンドが入り、残りのＮ個のセクターには、書き込まれる実際のデータが入る。より一般的には、コマンド（及びシグネチャー）は、埋め込まれたコマンドによってデバイスに転送されることになるあらゆるデータと共に、関係付けられたデータ部分を受け入れる全てのコマンド内に置かれる。データがデバイスからホストへ転送されることを要求するデバイス又はアプリケーション特定プロトコルで読み取り又は他のコマンドを実施するために、代表的な実施形態は、一対のコマンドを使用しており、第１コマンドは、ここでも、埋め込まれている読み取りコマンドに対応する、中間プロトコルの１つのデータセクターを備えている書き込みコマンドであり（埋め込まれている読み取りコマンドに関係付けられた実データは無い）、デバイスからホストへの実際のデータ転送は、次に、第２コマンドによって行われ、ホストの読み取りは、第１コマンドと同じ論理アドレスに指定される。
【００２１】
本発明の更なる詳細、特徴、及び利点は、以下の説明を添付図面と関連付けて読めば明白になるであろう。
【発明を実施するための最良の形態】
【００２２】
主要な態様では、本発明は、標準的なカードプロトコルの一部ではない（即ち、ホスト上の標準的なＯＳによってサポートされていない）コマンドを、ホスト上のアプリケーション（通常、カード上のアプリケーションを使用するソフトウェア）と、カード上のアプリケーション（通常、カード上の特定アプリケーションとしてこれらの追加的機能を実施するカードのファームウェア）の間で送受信できるようにしている。代表的な実施形態は、書き込みの様な、何れのホストもサポートする標準的なコマンドに特別なコマンドを埋め込むことによって、これを達成する。これにより、背景技術に記載した様なメモリカードが、全ての標準的なホスト装置及びＰＣに認識され、連結され、使用されるようになる一方で、標準としてサポートされていない追加の非標準的な機能が、システム内に組み込まれるようになる。
【００２３】
具体例として、技術背景で図２−４に関して論じた特定の事例では、これらの方法は、安全な読み取りの様な、ＳＤカードに特定のコマンドを、等価なコマンドを持ち合わせていないＵＳＢプロトコルを通して伝送できるようにしている。一般的に言えば、これは、伝送プロトコル内に在るコマンド部分と、メディア特定コマンドが埋め込まれているデータ部分とから成る命令を形成することによって達成される。例えば、書き込みコマンドは、何れのメモリカードシステムにも基本的なものなので、伝送プロトコル内に存在し、関係付けられたデータ部分を有している。実際のアプリケーション特定コマンドは、データ部分に、メディア特定コマンドが実行されるべきであることを示すシグネチャーと共に置かれる。デバイスに転送されることになる実際の埋め込まれているメディア特定コマンドに関係付けられた全てのデータも、伝送プロトコルのコマンドのデータ部分に置かれる。ＳＤ／ＵＳＢの例では、１０個のセクターの書き込み読み取りをＵＳＢプロトコル内でＳＤカードに送るために、命令は、１つのコマンドと１１個のデータセクターで構成されているＵＳＢプロトコルで発行され、第１データセクターには、実際のＳＤ安全書き込みコマンドが、シグネチャー及び関連情報と共に入っており、その後に、書き込まれるデータの１０個のセクターが続いている。カード内に受信すると、ファームウェアは、実際の安全書き込みコマンドを抽出し、シグネチャーを検査し、データの読み取りを実行する。
【００２４】
読み取り（及びデータをデバイスからホストへ転送する他のコマンド）では、中間プロトコルの書き込みコマンドは、ここでも、埋め込まれている読み取りコマンドを搬送するのに用いられるが、データがホストに送り返されるという規定は無いので、中間プロトコルの第２の読み取りコマンドと対になる。より具体的には、この対の第１コマンドは、ホストからの、埋め込まれている読み取りコマンドによる、論理ブロックアドレスＬＢＡ＝ＸＹＺへの（中間プロトコルでの）書き込みである。デバイスのドライバレベルでの実施では、それは特定のアドレスへのものとなるが、ファイルレベルの実施では、これは何れのアドレスでもよい。この対の第２のコマンドは、この同じアドレスＬＢＡ＝ＸＹＺへの標準的なホスト読み取りである。指定されたデータは、ホストに転送される。
【００２５】
より具体的には、本発明は、システムが使用できる媒介又は伝送プロトコルの命令の中に、所望のコマンドを、付随するデータと共に埋め込むことによって、アプリケーション又はメディア特定命令を、ホストとカードの間で交換できるようにする。特定のコマンドは、一方のホストで実行されている特定のアプリケーションと、他方の特定のカード上の対応するアプリケーションとの間で分割される。伝送経路に沿った中間点で、命令は、中間プロトコルによる通常のコマンドとして現れ、実際のアプリケーション特定コマンドは、トランスペアレントな方式で送られる。代表的な実施形態では、これは、書き込みコマンドの様なデータ部分を受け入れる伝送プロトコルのコマンドを使用し、実際のアプリケーション又はメディア特定コマンドをこのデータ部分に埋め込むことによって行われる。（或るやり方では、これは、２００２年９月２６日出願の同時係属中の共有譲渡されている米国特許出願第１０／２５６，６８９号に記載されている発明の拡張であり、同出願を参考文献としてここに援用する。）命令が（伝送プロトコルで）カードに到着すると、データ部分は、それが適切なシグネチャーを含んでいるか否かを知るために検査され、含んでいれば、埋め込まれたコマンドが抽出される。これを、図５に概略的に示している。
【００２６】
図５は、アプリケーション特定コマンドが、本発明の具体的な実施形態に従って、どの様にプロトコル内に埋め込まれて、プロトコルを、ホストアプリケーションからカード側のアプリケーションに送るのに使われるかを示す概略図である。アプリケーション又はメディア特定の命令がコマンド部分、ＣＭＤ、及び幾つかの対応するデータを有する事例を考えてみる。例えば、ＣＭＤは、アプリケーション特定の書き込みでもよい。この命令を伝送するために、ホスト側は伝送プロトコル内に、例えば書き込みコマンドの様な対応するデータ部分を有するＣＭＤ’と呼ぶコマンドを取り込む。この命令のデータ部分に置かれているものは何でも簡単に送られるので、実際に意図するアプリケーション特定コマンドＣＭＤが（その対応するデータと共に）このデータ部分に埋め込まれていれば、コマンドＣＭＤが伝送プロトコルで認識されなくても、それは、カードに伝送される。カードに入ると、コマンドＣＭＤは、データ部分から抽出されなければならない。これは、カードパススルー（ｃａｒｄ ｐａｓｓ ｔｈｒｏｕｇｈ）シグネチャー（ＣＰＴシグネチャー）を、同様にデータ部分に置くことによって行われる。即ち、入ってくる命令がカードに達すると、データ部分は、シグネチャーが検査され、シグネチャーが見つかれば、実際のコマンドが抽出される。
【００２７】
図５で、埋め込まれたコマンドが入っている伝送プロトコルの命令を５１０で示している。コマンド部分５１１は、コマンドＣＭＤ’を有しており、実際には実行されない一種の「ダミー」コマンドと考えることができるが、データ部分５１３をカード側へ送る働きをする。データ部分５１３は、シグネチャー及び実際のコマンドＣＭＤを備えた第１部分５１３ａと、ＣＭＤに対応する何らかのデータの第２部分５１３ｂに分割される。例えば、ＣＭＤが書き込みコマンド型式であれば、５１３ｂは書き込まれるデータであり、それが、例えば状態検査であれば、５１３ｂは無い。（後で詳しく述べる様に、埋め込まれている読み取りコマンドは、幾らか更に含有しており、この実施形態では、伝送プロトコルの区分５１１内の書き込みコマンドＣＭＤ’、データ部分の区分５１３ａ内の埋め込まれている読み取りコマンドＣＭＤ、および実際のデータが無い部分５１３ｂを送ることを含んでいる。）カード側では、５１３ａは、シグネチャーが検査され、見つからなければ、コマンドＣＭＤ’が、データとして全ての５１３と共に実行される。シグネチャーが見つかれば、コマンドＣＭＤを備えたコマンド部分５３１と、データ部分５３３内の全ての対応するデータとを有する実際の命令５３０が抽出される。（ＳＣＳＩプロトコルの様な、コマンド部分５１１に十分な余裕があるプロトコルでは、ＣＰＴシグネチャー、コマンドＣＭＤ、又はそれら両方を、データ部分ではなく、伝送プロトコルのコマンド部分に埋め込むこともできる。）
【００２８】
図１と本発明のより抽象的な説明に戻るが、本発明は、アプリケーションのホスト側とカード側が、経路に沿う何処かでアプリケーションに適合していないプロトコルを使って互いに通信しなければならない場合でも、通信できるようにしている。これは、背景技術で説明したように、アダプターが、カードの特徴に気付かない場合に起こり得るが、ホストのオペレーティングシステムがカードの特徴に気付かない場合も同様である。このことは、メディア又はアプリケーション特定コマンド両方のシステムに関する問題を、ホストとカードの間に在るホストアダプターが有っても無くても、解決する。更に、カードプロトコルが、カードの形状情報で異なる場合だけでなく、これらのカードはカード毎に異なる追加の機能でオーバーロードになるので、同じ形状情報であってもカード間で異なっている場合も許容する。呈示されている取り決めは、カードアダプターとホストＯＳが特定のカードプロトコルに無関心なシステムを考えており、そのカードプロトコルは、一方ではホスト側でそして他方では特定のカード側で実行されている特定のアプリケーションの間で分割される特定コマンドを有している。
【００２９】
ホスト側では、本発明は、ファイルモードでアプリケーションがホストファイルシステムを使用し、ファイルに書き込むファイルシステムレベル、又はデバイスドライバを使用するモードのデバイスドライバレベル、の何れかで実施することができる。両方のバージョンの具体例を以下に提供する。どの型式の実施形態が望ましいかは、具体的なアプリケーションやオペレーティングシステムの詳細の様な細目によることが多い。例えば、デバイスドライバレベルでの実施の方が簡単で、ソフトウェア／ファームウェアのオーバーヘッドが少なくて済むが、論理アドレスへの直接書き込みを使用することになり、その様な直接的な書き込みには、ユーザーは持ち合わせていない管理者の特権が必要となる。代わりに、ファイルシステムレベルでの実施を使用することによって、これらの面倒さを回避できるが、追加オーバーヘッドの経費が必要になる。
【００３０】
本発明を、３つの特定の実施形態に関して、より詳細に説明する。これらの全ては、新しい機能をサポートするためにホストカードプロトコルを変えること無く、又は追加のプロトコルをサポートしない中間ソフトウェア／ハードウェアを通してそれを使用しながら、特別な非標準的機能を、ホスト上で使用されるカード内で実施されるようにする。第２及び第３組の実施形態は、ホスト側で（それぞれ、デバイスドライバレベルとファイルシステムレベルで）実施される２つの方法について述べており、一方第１は、カード側の実施について述べている。この第１の実施形態は、第２と第３を補い、カード側がどの様に作動するかを説明しており、全ての実施形態のために全体的な詳細を提供するのに用いられることになる。以下に更に詳しく述べる様に、これは、標準的な利用可能なコマンドを使って、非標準的なコマンドを包むために行われる。これら事例のそれぞれで、代表的な実施形態は、何処でもサポートされる標準的な読み書きを選定する。なお、これら特定の実施形態では、これらの実施形態の全てで、カードには特定の論理ブロックアドレス（ＬＢＡ）への書き込みが見えているので、カードは、ファイルの概念を認識する必要はない。このＬＢＡは、デバイスドライバモードでの様に、この目的のために特別に割り当てられている（又は再度割り当てられる）か、又は、ファイルドライバモードでは任意のアドレスか、の何れでもよい。主な違いはホスト側にあり、アプリケーションは、ファイルモードでは、ホストファイルシステムを使用し、ファイルに書き込んでおり、第１モードでは、デバイスドライバを使用し、直接ＬＢＡに書き込んでいる。
【００３１】
以下に、本発明の様々な態様を、数多くの特定の実施形態の例で呈示する。例えば、本実施形態は、メディア特定コマンドを、書き込みコマンドのデータ部分に埋め込んでおり、より一般的には、メディア又はアプリケーション特定コマンドは、他のコマンドに埋め込むことができる。更に、上記背景技術の議論は、特定プロトコル領域を備えた特定のハードウェア設備に基づいており、即ち、そこでは、ＰＣ／ホストは、ホストとリーダーの間の１つのプロトコルと、リーダーとカードの間の第２のプロトコルを使用して、ハードウェアリーダーを通してカードと通信する。これらの実施形態は、全てが、数多くの手法で一般化し、拡張することができる。
【００３２】
上記背景技術の議論は、カードとＰＣがリーダーを通して通信する例に焦点を当てた。より一般的には、本発明の様々な態様は、ホスト（例えば、ＰＣ）と最終行先の間の経路の何処かで、伝送する必要のある１つ又は複数のコマンドの等価物を持っていないプロトコルが用いられるときに当て嵌まる。先に述べた様に、ハードウェアのカードリーダーが、ホストがカードに送りたいと思っているカードプロトコル（例えば、ＳＤカードの安全読み取り）のメディア特定コマンドの等価物を持っていないプロトコル（例えば、ＵＳＢ／ＳＣＳＩ）でホストと通信するときに問題が発生するだけでなく、カードが直接ホストに取り付けられるときにも発生する。更に複雑な場合、幾つかの中間プロトコルがあってもよく、その場合、第２例に見られる様に、幾つかの埋め込み層を用いることもできる。
【００３３】
別体のカードリーダーを必要としない場合の１つの具体的な例では、カードに２セットの接点があり、一方はＵＳＢポート用であり、他方は標準的なカード接点のセット（ＭＭＣ、ＳＤ、ＣＦなど）用である。（その様な二重接点カードの例について、２００４年４月１６日出願の米国特許出願第２９／２０３，６９３号、第１０／８２６，８０１号、及び第１０／８２６，７９６号に記載されており、それら全てを参考文献としてここに援用する。）「通常の」カード接点を使って、カードは、第１ホストと、メディア特定コマンドが使用可能なカード特定プロトコルで通信することができる。第２セットの接点（ここではＵＳＢ）を使って、カードは、メディア特定コマンドの等価物を持ち合わせていない別の異なるプロトコルで、ＰＣの様な他のホストと通信することができる。この場合、第２ホストと他のプロトコルは、本発明に従って、メディア特定コマンドを埋め込むことにより、例えば、ＵＳＢ接点を使って、カードは、ＵＳＢポートでＰＣに直接接続することができ、カードとＰＣは、ＵＳＢを通して、ＳＣＳＩプロトコルで、先に述べた様にＳＣＳＩプロトコルに埋め込まれている任意のＳＤ特定コマンドを使って、通信する。
【００３４】
先に述べた様に、具体的な関心事の一組の実施形態では、ホストとカードは、カードのプロトコルで通信するが、ホストアプリケーションは、カードの「通常の」メモリ機能が気付かない層内で、カードのアプリケーションと、コマンド及びデータを交換したいと望むかもしれない。例えば、ＳＤメモリカードでは、デバイスのアプリケーション層のパーティションは、ＳＤ特定ファームウェア層から隠すことができる。ホストとカードは、標準的なＳＤプロトコルを使って通信するが、隠されているデバイスアプリケーションは、アプリケーション特定コマンドをＳＤプロトコル内に埋め込むことによって、対応するホストアプリケーションと通信することができる。第１の代表的な実施形態は、この性質を備えている。
【００３５】
代表的な実施形態は、メディア特定（又はアプリケーション特定）コマンドを書き込みコマンド内に埋め込んでいる。例として用いられている書き込みコマンドは、コマンドを中間プロトコルのデータ部分に埋め込み、書き込みコマンドは、本来的にデータ部分を有している。より一般的には、書き込みコマンドのみならず、データ部分を受け入れる何れのコマンドでも、同様に用いることができる。書き込みは、データを転送するためのプロトコル内の基本的な命令なので、以下の代表的な実施形態では、書き込みについて述べていく。更に、全ての例で、メディア又はアプリケーション特定コマンドは、分かり易くするためデータ部分の最初に埋め込まれているが、より一般的には、それらは、データ部分の何処に置いてもよく、シグネチャーによって識別されることになる。（先に述べた様に、より一般的には、シグネチャー、アプリケーションコマンド、又はそれらの両方は、ＳＣＳＩプロトコルの様な、コマンド部分に十分な余裕を有しているプロトコルの伝送プロトコルのコマンド部分に埋め込んでもよい。）
【００３６】
本発明が関与している問題は、より抽象的なレベルで表すことができる。ホストアプリケーションが、デバイスアプリケーションと、コマンドのセット（α、β、γ、...）を有するプロトコルで通信しなければならないが、通信経路の何処かで、コマンドのセット（Ａ、Ｂ、...）を有する別のプロトコルを用いなければならない場合を考えてみる。背景技術の例では、（α、β、γ、...）はＳＤプロトコルであり、中間コマンドのセット（Ａ、Ｂ、...）はＳＣＳＩプロトコルとした。以下の議論で、（α、β、γ、...）は特別なアプリケーション（隠しパーティションの様な）のコマンドセットであり、（Ａ、Ｂ、...）はカードコマンドのセットとする。Ａ←→α、Ｂ←→βなどの対応があれば、問題は無い。メディア又はアプリケーション特定コマンドγ、例えば、ＳＤプロトコルの安全読み取りがあるのに、中間プロトコルに等価物が無い場合、即ち？←→γの場合に、問題が生じる。先行技術では、その様な各γに対して、γに等価な新しいコマンド、即ち、Ｃ←→γを導入する必要がある。代わりに、本発明によれば、新しいコマンドを導入するのではなく、メディア特定コマンドが、中間プロトコルの既存のコマンドに埋め込まれ、Ａ（γ）←→γ、ここにＡ（γ）は、例えばγが埋め込まれている書き込みコマンドを示している。
【００３７】
一般化では、コマンド（Ｆと呼ぶ）は、アプリケーションのホスト側とデバイス側のパイプを開いて通信できるように、（α、β、γ、...）プロトコルに導入される。パイプが開くと、メディア又はアプリケーション特定コマンドを送ることができる。これは、Ａ[Ｆ（γ）]←→γと表される。この技法は、第１例で展開される。これは、コマンドの失敗や他の微妙なことの取り扱いを考慮している。コマンド失敗に関わる問題は、中間プロトコルが埋め込まれているコマンドの性質に関する知識を持っていなかったということであり、なぜなら、中間プロトコルがそれを知っていれば、簡単な書き込みコマンドを送信しているに過ぎないからである。埋め込まれたコマンドが、例えば読み取りであれば、ＰＣは、読み取りが失敗するという事象の際には、何が起こったか分からない。中間プロトコルでは、書き込み失敗とみなされ、埋め込まれている読み取りの失敗とは解釈されず、従って、ホストは、実行すべき適切な回復ステップを理解できない。アプリケーションのホスト側とカード側の間のパイプを開くことによって、その様な困難を容易に追跡し、それに対処することができる。
【００３８】
（第１の代表的な実施形態）
第１の代表的な実施形態は、ホスト側では第１レベルで実施されるものであり、本発明の様々な態様を説明するのに用いられる。カード側での実施は、ホスト側がファイルレベルで実施されるか或いはデバイスのドライバレベルで実施されるかに関わらず大部分が同じである。この実施形態の具体的なアプリケーションを参照すると、メモリカードの隠しパーティションの説明で提供され、メモリは、公開のアクセス可能な部分と、私的又は「隠された」部分に分割されている。その様な取り決めについては、２００４年１２月２１日出願の米国仮特許出願第６０／６３８，８０４号に記載されており、同出願を参考文献としてここに援用するが、詳細の大部分はそれに限定されない。ホスト側の部分、特にデバイスのドライバについて先ず説明し、その後、カードの詳細について説明する。隠しパーティションの他の使用例は、２００５年２月２５日出願の第１１／０６７，２９８号、２００３年１１月１０日出願の第１０／７０３，４７１号、２００４年７月２６日出願の第１０／８９９，２６０号、及び２００５年２月２日出願の第１１／０５０，０１３号の特許出願に記載されており、それらの全てを参考文献としてここに援用する。
【００３９】
図６は、デバイス側の代表的な構造を示す概略ブロック図である。カード１００１側では、１つ又は複数のデバイスアプリケーション１０２３は、それぞれ、ホスト側１０５１の１つ又は複数のホストアプリケーション１０５３へのゲートウェイ又は「パイプ」を、非標準的な、この特定の形状情報用のカードの特徴、ここでは隠されているパーティションに提供する。ホスト側の層については、以下に図７で詳しく説明する。カード側では、デバイスアプリケーション１０２３が、パーティションアクセス（読み取り及び書き込み）、状態、及び他のデバイスアプリケーション情報を提供する。デバイスアプリケーション１０２３は、以下に記載されている代表的なプロトコルを介してホストアプリケーション１０５３と通信し、メディア層１０２５を通してカードシステムとメモリリソースを使用する。メモリ自体は、メモリ１０１１に示されており、普通はＮＯＲ又はＮＡＮＤ種のフラッシュメモリであるが、２００４年５月７日出願の米国特許出願第１０／８４１，３７９号に記載のものを含め他の不揮発性メモリでもよく、同特許出願を参考文献としてここに援用する。ＦＥ（フロントエンド）層１０２１は、ホスト側からの（ＣＦ、ＳＤ、ＭＭＣなどのプロトコルの様なカード型式のインターフェースでの）コマンドを取り扱うファームウェア層である。ＢＥ（バックエンド）層１０２７は、メモリに対する読み取りと書き込みを含めメモリ１０１１の管理を取り扱うファームウェア層である。メディア層１０２５は、デバイスアプリケーションファームウェア１０２３をＢＥ層１０２７と接続させ、更に、アプリケーションファームウェアをコントローラーのＲＡＭリソースとインターフェースさせるが、それについてはこの図では具体的に示していない。
【００４０】
命令がホスト１０５１から送られると、その命令は、最初にデバイス１００１のフロントエンド（ＦＥ）層１０２１で受信される。コマンドは、ホストとデバイスの間で用いられる中間プロトコル、例えばＳＤプロトコルにある。コマンドは、ＦＥ層１０２１に到着すると、コマンドパススルーシグネチャーが検査され、シグネチャーが見つからなければ、命令は、中間プロトコルからの標準的な命令として扱われ、メモリにアクセスし、そうでなければ、標準的な方法で実行することができ、シグネチャーが見つかれば、埋め込まれているアプリケーション特定コマンドが抽出され、適切なデバイスアプリケーション１０２３に送られて実行される。（ホスト側で）デバイスドライバレベルで実施される場合は、以下の第２の代表的な実施形態での様に、コマンドは、特定の論理アドレスに指定され、一方、ファイルレベルで実施される場合は、この例と以下の第３例の両方での様に、コマンドは、何れの論理アドレスに指定されてもよく、デバイス側から見ると、両実施は、ほぼ同じである。
【００４１】
シグネチャーが見つかって、埋め込まれたコマンドが抽出されると、（この例では）隠されているパーティションは、カード１００１内に常駐する対応するデバイスアプリケーション１０２３を介して、ホストアプリケーション１０５３に利用できるようになる。ホスト及びデバイスのアプリケーションは、ホスト側とカード側の間の読み取り及び書き込みをカバーするプロトコルを使って、並びにパーティション情報に関する報告を行って、通信することになる。この代表的な実施形態では、デバイスは、アプリケーションに対する権利を制御する。権利（読み取り、書き込み）は、デバイスがホストアプリケーションの証明書を確認すると与えられ、承認されると、デバイスアプリケーションは、ホスト／デバイスプロトコルを通して、そのパーティションに対する読み取り及び書き込み特権を認可する。ホストアプリケーションが有効にされると、デバイスは、信頼されている環境内で作動していると想定される。
【００４２】
先に述べた様に、第１の代表的な実施形態はファイルレベルで実施され、埋め込まれたコマンドは、書き込みファイルの第１データセクターに置かれる。本実施形態は、どの様な特定の論理アドレスへの参照にも依存せず、具体的なパターン又はシグネチャー用の第１データセクターの検査に依存する。パーティション内のファイルは、ホストによって管理されており、つまり、隠されているパーティションの例では、ホストアプリケーションは、隠されているパーティション内のファイルシステムの所有者である。ホストアプリケーションがアプリケーションへの権利を獲得すると、コンテンツを完全に制御できるようになる。
【００４３】
隠されているパーティションのＦＡＴは、オペレーティングシステム（ＯＳ）によるアクセス特権問題のために読み取れないことが多いので、ホストアプリケーション１０５３は、ファイルシステム層を実施することになる。隠されているパーティションへのアクセスについては、ＦＡＴは、アプリケーションへのパイプが開いた後にだけ、利用可能である。（ホストアプリケーションによるコマンド転送は、定義されており、以下に説明する。）ホストアプリケーションは、カードの隠されていない、即ち公開パーティションに在り、ＯＳには、大容量記憶装置で又は取り外し可能なデバイスレベルで見ることができる。幾つかのその様なホストアプリケーションは、この領域に常駐していてもよく、ユーザーは、どれを実行するのか分かるようになっており、それはホスト側で実行される。
【００４４】
ホスト側のソフトウェア層について、図７でより詳しく説明する。デバイスドライバ１０５５は、２つの役割を持っている。それは、バスドライバとして機能し、（中間）プロトコルとファイルシステム１０５７によってサポートされる標準的なクライアントアプリケーションのＩＯオペレーションを実行する。更に、それは、アプリケーションと、デバイス又はアプリケーション特定プロトコルを実施する。標準的なＩＯ ＡＰＩ及び実施は、全てのカード族、例えば、標準的なＳＤカードのオペレーションに共通していてもよい。アプリケーション又はデバイス特定ＡＰＩ及び実施は、生来プロトコル特定のものである。図７は、共通部分のコード共有と、異なるアプリケーション特定プロトコルの間の簡単なポータビリティを可能にする階層構造の例を示している。
【００４５】
ホストアプリケーション層１０５３とファイルシステム層１０５７に加えて、ホスト構造は、デバイスアプリケーションに特定の層１０５９も組み込んでいる。アプリケーション特定のオペレーションを組み込んでいない「標準的な」デバイスのオペレーションには、層１０５９は使用されず、層１０５３、１０５７、及び１０５５が、先行技術と同様に主に作動する。アプリケーション特定の命令が用いられる場合は、アプリケーション特定コマンドをフォーマットし、埋め込むために、デバイスアプリケーション層１０５９が、ファイルシステム１０５７とホスト層１０５３の間に挿入される。
【００４６】
デバイスドライバ１０５５は、共通の機能性を提供するためインターフェース及びパイプサブ層を含んでいてもよいし、全てのアプリケーション特定プロトコルを最小限変更して使用することもできる。ホストのアプリケーションは、具体的なアプリケーションに従ってプロトコル層と整合していなければならない。インターフェースサブ層は、標準的な一組のデバイス機能を公開する。例えば、これらには、ハードウェアの初期化と設定、ドライブ開閉ルーチン、読み取り及び書き込み動作、及び消去が含まれる。それは、更に、適切な通信方法に対する機能を含んでおり、然るべくパイプを初期化する。
【００４７】
図５の５１０の様な命令が伝送されるとき、場合によっては、オペレーティングシステム（ＯＳ）がそれを幾つかの部片に分割するので、他の命令の部片が差し挟まれることもある。その場合、ファイルシステム１０５７とデバイスドライバ１０５５は、命令５１０を分割することができるので、そうすると、コマンド部分５１１は、全データ部分５１３の何処にでも取り付けられ、残りのデータ部分は、それに続く１回又は複数回で転送される。その場合、残りのデータの部分の後に続く転送は、区分５１３ａのシグネチャー部分を持ち合わせておらず、標準的なコマンドの様に見える。その様な分割は、読み取り動作でカードからホストへ転送されるデータにも起こる。ＯＳが命令を分割しないか、又はＯＳが十分に制御されているので、そのようにしないよう命令されているか、の何れかであることが分かっている場合は、手順は簡素化できる。このことを、先ず、図１０Ａの流れと、図１２Ａの対応する状態マシン図に関して論じる。より一般的な場合については、図１０Ｂに関して後で論じる。更に、議論を簡潔にするために、図１０Ａに関する論議は、主に、単一のアプリケーションの場合に基づいているが、一般的には、多数の異なる動作中のアプリケーションがある。図１０Ｂのより一般的な場合は、これをより明示的なものにする。
【００４８】
第１の代表的な実施形態では、簡単な隠されているパーティションのプロトコルが、例証のために用いられる。メモリ１０１１は、２つのパーティションに分割される。第１パーティションは、製品の標準的なパーティションである。標準的なホストは、このパーティションにだけ気付く。第２パーティションは、隠されているパーティションであり、アプリケーション特定コマンドを通してのみアクセス可能である。標準的なホストは、このパーティションに気付かず、それにアクセスする手段を持たない。例の隠されているパーティションのプロトコルは、５つの機能を定めており、それを通して、デバイスとアプリケーションが通信する。
１．隠しパーティションを開く：ユーザーを認証し、読み取り及び書き込み動作を可能にするのに用いられる。
２．隠しパーティションを閉じる：読み取り及び書き込み動作を使用不可能にする。
３．隠しパーティションの状態を得る：図８に示されているデータを戻す。
４．隠しパーティションを読み取る：パーティションが開かれていれば、隠されているパーティションから読み取る。閉じられていれば、エラーを戻す。
５．隠しパーティションに書き込む：パーティションが開かれていれば、隠されているパーティションに書き込む。閉じられていれば、エラーを戻す。
プロトコル層は、安全なプロトコルを実施するのに必要な追加のＡＰＩを提供する。隠されているパーティションの有る特定の例では、プロトコルは、読み取りと書き込みに加えて、パーティションを開く、パーティションを閉じる、パーティションの状態を得る、という３つのサービスを要求する。これらのコマンドを以下の表１に示しており、図８と共にそれらについて更に論じる。
【００４９】
パイプサブ層は、メディアコマンド通過の原則による、カードとの通信を担っている。先に述べた様に、メディアコマンド通過プロトコルにおける主題は、特別なコマンド（標準的な製品仕様の一部ではないコマンド）が、標準的な読み取り及び書き込みオペレーション内に埋め込まれていることである。コマンドを標準的な読み取り及び書き込みオペレーションに埋め込むことによって、標準的なホスト及びドライバと共に作業できるようになる。
【００５０】
代表的な実施形態では、全てのコマンドは、書き込みコマンドを、メディアカードの或るＬＢＡに送ることによって開始される。アプリケーション特定書き込みコマンドは、最初のセクターがコマンドの引数を保持し、残りのデータブロックが、もしあれば、関連データを保持している、複数のセクターの転送を含んでいる。読み取りコマンドは、２つの部分で実行される。
１．先ず、書き込みコマンドを、読み取りコマンドの性質について説明する適切なデータと共に、選定されたＬＢＡに送ることによって、読み取りコマンドを開始する。
２．書き込みコマンドが、カードアプリケーションを正しい転送状態に設定した後で、書き込みコマンドから選定されたＬＢＡに読み取りコマンドが送られ、実際にカードからホストへデータが転送される。
【００５１】
全てのコマンドは、先ず、図９に示しているセクターフォーマットを使って書き込みコマンドを送る。ホストアプリケーションが、書き込みコマンドを送ると決定すると、転送される第１セクターは、上記フォーマットを有することになる。ホストから送られる次のデータブロックは、カードに関する実際のデータを有することになる。ホストアプリケーションは、読み取りコマンドを開始するよう選定すると、先ず、書き込みコマンドを、上記単一のセクターフォーマットを使って、選定されたＬＢＡ（ＬＢＡ＝ＬＢＡ＿ＸＹＺ）に送り、次に、同じＬＢＡに読み取りコマンドを送る。これについては、以下に詳しく論じる図１０Ａと図１０Ｂの流れ図で示している。
【００５２】
多数の考えられる実施が、メディアコマンド通過プロトコルで可能である。このセクションの例は、ファイルシステム、例えばウインドウズ（登録商標）のファイルシステムの運用を使用する。次のセクションの例は、デバイスと、デバイスドライバレベルで直接通信し、ファイルシステムがオーバーヘッドを有していない。別の実施は、ポケットＰＣ（ＰＰＣ）である。この事例では、読み取り及び書き込みオペレーションは、ＰＰＣ記憶ドライバに直接アクセスすることができる。現時点では、ポケットＰＣ装置用の標準的な記憶装置ドライバは無いので、この方法が全てのＰＰＣ装置上で作動する保障は無い。クライアントアプリケーションベンダは、共に作動しようと意図する一組のＰＰＣ装置で、この方法を試験しなければならない。
【００５３】
本例のファイルシステムの実施に戻るが、パイプサブ層は、ＯＳが命令全体を１回の転送で転送する場合は、図１０ＡでＬＢＡ＿ＸＹＺと示されている同一のファイル場所に対して読み取り及び書き込みを行うことによって、コマンド通過ＬＢＡに対する読み取り及び書き込みオペレーションを開始する。これは、次のセクションの例にあるような予め決められたアドレスである必要は無いが、何れかの論理ブロックアドレスでなければならない。この例では、実施は、ウインドウズの標準的なファイルシステムＡＰＩ−ＣｒｅａｔｅＦｉｌｅ、ＲｅａｄＦｉｌｅ、ＷｒｉｔｅＦｉｌｅ、及びＳｅｔＦｉｌｅＰｏｉｎｔｅｒを使用する。実施のセットは、４つ又は５つの部分、即ち、事前要件と、通信パイプの確立と、ファイル長さの検証と、アプリケーション書き込みコマンドと、データが読み取られることになるか、ホストへ戻された他の情報である場合は、読み取りコマンドと、に分割される。
【００５４】
ファイルレベルの実施では、ファイルシステムは、埋め込まれているアプリケーション特定コマンドを、認識されずに伝送するのに用いられる。実際の埋め込まれているコマンドは、ファイルシステムが目下送っていると思っている中間プロトコルのコマンドとは性質が異なるので、適切なステップを踏まなければ、衝突が起こり得る。例えば、エラーが生じると、ファイルシステムは、実際のエラーが埋め込まれているコマンド（例えば、読み取り）にあるかもしれないとき、これを中間プロトコルで搬送しているコマンド（書き込み）のエラーとみなすので、エラー回復は複雑なものになりかねない。同様に、ファイルシステムがキャッシングを採用していれば、不調和な結果となりかねない。
【００５５】
ファイルのセグメント化からも問題の生じることがあり、代表的な実施は、同一ファイル場所（図１０ＡのＬＢＡ＿ＸＹＺ）に対する読み取りと書き込みに依存しているので、ファイル全体を、メモリ内の連続したセクターのグループに記憶しなければならない。ＬＢＡ ＸＹＺで開始して記憶されることになるデータが、利用可能なセグメントより大きい場合、ファイルシステムは、それを分割する。その結果、アプリケーション特定コマンドの最大データ長さは、最小のＯＳファイル割り当てユニット（クラスター）より大きくてはいけないので、使用される論理アドレス（ＬＢＡ＿ＸＹＺ）は、十分な空間を有する論理ブロックアドレスと関係付けられる。
【００５６】
ウインドウズの例では、ファイルシステム実施での事前要件は、少なくとも１２８個の連続するセクターが入っている標準的なファイルを必要とする。その様なファイルの存在を保証するために、その様なファイルが、フォーマットされたドライブ上に作られる。従って、ホストアプリケーションのベンダがこの方法を選定すれば、アプリケーションとの通信ファイルを展開しなければならない。この例では、設計は、「ファイルパイプ（ＦｉｌｅＰｉｐｅ）」と名づけられたファイル（以下に指定されている特定の属性を有する）がデバイスのユーザー領域内に存在していると想定している。その様なファイルが存在していなければ、ドライバは、それを作ろうとする。失敗すれば、アプリケーションは、ユーザーに、ドライブをフォーマットし、アプリケーションをフォーマットされたドライブに再インストールすることを求めることができる。
【００５７】
通信パイプを確立するために、デバイスドライバ１０５５は、
共有されていない
バッファリングしない
隠されている
という属性を有する通信ファイルを開くことが望ましい。共有されていない状態は、他のアプリケーションが、コマンド通過ＬＢＡにアクセスするのを防ぐために、ホストアプリケーションだけがファイルにアクセスすることを保証する。バッファリングしない状態は、システムに、中間バッファリング又はキャッシングの無いファイルを開くように命令する。従って、このファイルに対する／からの、書き込み又は読み取りは、キャッシングされたバージョンではなく、カードに対する／からの、読み取り／書き込みコマンドになる。（ファイルがカードにフラッシュされることを保証するために、「バッファリングしない」フラグと「書き込みスルー」フラグの両方を設定しなければならない場合もある。）実際のアプリケーション又はメディア特定コマンドは、別のプロトコルのコマンド内に埋め込まれているので、例えば書き込みエラーがあるときは、ホストは、これを、埋め込まれたコマンドのエラーではなく、中間プロトコルの書き込みコマンドに関するエラーと解釈する。バッファリングしない状態は、データ転送を、意図した埋め込まれたコマンドに繋がれた状態に保つ。隠されている状態は、エンドユーザーが、これをシステムファイルと見ることを意味している。
【００５８】
次の実施ステップは、ファイルに、連続している少なくとも１２８個のセクターが入っていることを検証することである。
【００５９】
アプリケーションの書き込みコマンド、即ち、隠されているパーティション例での安全な書き込みでは、書き込みバッファは、先に述べた道筋に沿って準備される。次に、ファイルポインタは、読み取り及び書き込みオペレーションが同一ＬＢＡ（＝ＬＢＡ ＸＹＺ）に対してであることを保証するようリセットされる。バッファは、次に、「ＦｉｌｅＰｉｐｅ」の名前を有する「ＷｒｉｔｅＦｉｌｅ」コマンドを呼び出すことによってデバイスに送られる。
【００６０】
アプリケーションの読み取りコマンド、即ち、隠されているパーティション例での安全な読み取りでは、ファイルポインタが先ずリセットされ、次いで「ＷｒｉｔｅＦｉｌｅ」コマンドを実行することによって、コマンドバッファが送られる。ファイルポインタは、次に、書き込み及び読み取りオペレーションが同一ＬＢＡで行われることを保証するため、再度リセットされる。次に、デバイスから安全が保証されたデータを得るため、「ＲｅａｄＦｉｌｅ」が実行される。
【００６１】
カード側に戻るが、デバイスアプリケーション１０２３は、（この例では）隠されているパーティションを管理し、読み取りと書き込みが、ホストアプリケーションの有効性確認次第となるようにしている。リソースとメモリのアクセスは、隠しパーティションのフェーズでは、メディア層１０２５を通して行われる。メディア層１０２５は、デバイスのアプリケーションデータ転送の全てを、メモリ１０１１の隠されているパーティションに向かわせる。
【００６２】
先に述べた様に、デバイスアプリケーション１０２３は、その特定のコマンドを、ホストアプリケーション１０５３から、通常のカードプロトコルの読み取り／書き込みコマンドを通して受け取る。例えば、ＳＤカードプロトコルを代表的な実施形態とすると、各コマンドインデクス及び引数は、コマンドセクターにＳＤ書き込みコマンドを介して送られる。読み取りコマンドがデバイスアプリケーションから要求されるとき、ホストアプリケーションは、先ず、書き込みコマンドを（ＳＤ書き込みコマンドを通して）送り、その後、実際の読み取りコマンド（ＳＤ読み取りコマンド）を送る。読み取りコマンドのコンテキストは、例えば、デバイスアプリケーション専用のＲＡＭ空間内に、書き込みコマンドがコマンドセクターに送られている間に保存される。読み取りコマンドが後に続くときは、デバイスアプリケーションは、次に、保存されている読み取りコンテキストをロードし、要求されたデータを転送する。保存されている読み取りコンテキストは、別の読み取りコンテキストに取って代わられるまでは、そのまま残される。これにより、ホストは、別の読み取りコマンド＋コマンドセクターを送ること無く、読み取り再試行を実行することができる。
【００６３】
殆どのプロトコルコマンドが読み取り／書き込みコマンドとして動作するので、アプリケーション特定の新しいコマンドを、或るＬＢＡへの読み取りと書き込みを通して転送することができる。代表的な実施形態では、全てのコマンドは、書き込みコマンドをメディアカードの或るＬＢＡに送ることによって開始されることになる。アプリケーション特定の書き込みコマンドは、複数のセクター転送を含み、第１セクターは、コマンドの引数を保持し、残りのデータブロックは、関連データがあれば、それを保持する。
【００６４】
先に述べた様に、読み取りコマンドは、２つの部分で実行され、即ち、
１．先ず、書き込みコマンドを、選定されたＬＢＡに、読み取りコマンドの性質について説明する適切なデータと共に送ることによって、読み取りコマンドを開始し、
２．書き込みコマンドがカードアプリケーションを正しい転送状態に設定した後で、書き込みコマンドから、選定されたＬＢＡへの読み取りコマンドが送られて、実際にカードからホストへデータが転送される。
【００６５】
図９に戻るが、全てのコマンドは、先ず書き込みコマンドを送らなければならず、図９は、引数データセクターの代表的なフォーマットを示している。図９に示している様に、バイト０−３１は、アプリケーションパススルーシグネチャー（例えば、「サポートされているパススルーモード」）を保持し、バイト３２はアプリケーションのＩＤを保持し、バイト３３は、埋め込まれているコマンドのアプリケーションコマンドオペレーションコードインデクスを保持し、アプリケーションコマンド引数データが残りのセクターを埋めている。
【００６６】
この実施形態では、ホストアプリケーション１０５３が、書き込みコマンドを送ると決定すると、転送される第１セクターは、図９のフォーマットを有することになる。ホスト１０５１から送られる次のデータブロックは、カード用の埋め込まれたコマンドの実際のデータを有することになる。ホストアプリケーションは、読み取りコマンドを開始するよう選定すれば、先ず、書き込みコマンドを、選定されたＬＢＡに上記単一のセクターフォーマットで送り、次に、読み取りコマンドを同一のＬＢＡに送り、読み取りを行わせる。
【００６７】
ホストアプリケーション１０５３は、図１０Ａに示している、デバイスから見た通信の流れに従う、先に述べたコマンドの開始に責任を負っている。これを行うために、ホストアプリケーションは、先に述べた様に、埋め込まれたコマンドを搬送することになるカードプロトコルの読み取り及び書き込みオペレーション用の目標ＬＢＡを制御する。１つのＬＢＡで１つのコマンドのみと説明しているが、図１０Ａ（及び図１１Ａ−Ｃ、図１２など）に示すプロセスは、複数のＬＢＡで起こることもあり、それは、ＬＢＡが全て通過モードシグネチャーを信頼していることもあるからである。（この事例については、図１０Ｂに関して後で詳しく説明するが、同図では、各種ＬＢＡを添え字ＬＢＡ_ｉで示している。）デバイスは同時に複数のファイルを扱うことができるので、特定のＬＢＡは、デバイスの状態マシン（後で図１２に関して論じる）に信頼されているに過ぎない。
【００６８】
プロセスは、ステップ１１０１で、ここではＬＢＡ＝ＬＢＡ ＸＹＺと表されている選定されたＬＢＡへの書き込みが受信されると始まる。シグネチャーが検査され（１１０３）、アプリケーションパススルーシグネチャーであるか否か調べられ、そうでなければ、カードは標準的なＩＯオペレーション（１１０５）に連動し、そうであれば、ＣＭＤ通過モードに入る。ステップ１１０９は、コマンドの方向（デバイスから見て）がアウトか否かを判断する。方向がアウト（例えば、デバイスのメモリへの書き込み）であれば、コマンドが実行される（１１１１）。
【００６９】
コマンドの方向がアウトでなければ、メモリデバイスは、１１１３で、読み取り対の第２コマンド、即ちアプリケーション読み取り要求を待つ。代わりに書き込みが到着すれば（１１２１）、待機状態（１１１３）に戻る前に標準的なＩＯオペレーション（１１２３）へ進む。読み取りコマンドが受信されると、ＬＢＡが検査され（１１１７）、それが選定されたＬＢＡへのものであれば、それは、読み取り対の第２コマンドであり、読み取りが実行され（１１１９）、ＬＢＡが合致しなければ、１１２３へ進む。
【００７０】
２つ以上の可能な実施方式があり、実施の詳細は、目標のプラットフォームによって変わる。ウインドウズＮＴベースのデスクトップに適用され、ホスト側に関して先に述べた１つの一般的な方式は、仮想ファイルと標準的なウインドウズファイルシステムＡＰＩを使用する方式である。他には、次の例で述べる様に、ウインドウズＳＣＳＩ通過ＡＰＩを使って、カードプロトコル（例えばＳＤ）の読み取り及び書き込みオペレーションを直接開始させる方式である。この方式は、ウインドウズＮＴベースのデスクトップにも適用されるが、カードドライバレベルでの実施に関して先に論じた様に管理権を必要とする。
【００７１】
カードのファームウェアとアプリケーションのファームウェアの間のコマンドインターフェースに関して言えば、第１ステップで、カード−ＦＷはアプリケーション特定コマンドを受け取る。カード通過モードがサポートしているシグネチャーを検証した後、カードのＦＥ層１０２１は、書き込みコマンドと共にアプリケーションＩＤとコマンドＯＰ−コード用に選定されたＬＢＡに来た引数データセクターを解析する。アプリケーション特定コマンドインタープリターは、アプリケーションインターフェースルーチンをホストデータバッファへのポインタで呼び出す。第２ステップで、アプリケーション特定コマンドシーケンスを開始するとき、アプリケーションＦＷは、その自身の状態マシンを、アプリケーションコマンドシーケンスを扱うように設定し、更に、フラグを、選定されたＬＢＡへの次の読み取り／書き込みコマンドがアプリケーションＦＷへのものであることを示すように設定しなければならない。読み取りコマンドがカード（選定されたＬＢＡ）に送られる度に、カードのＦＷは、先ず、このフラグを検査し、このアプリケーション特定読み取りコマンドを、このＬＢＡへの通常の読み取りコマンドと区別する。
【００７２】
隠しパーティションのアプリケーション用のプロトコルの例について説明する。図１１Ａ−Ｃは、図１０Ａと同じプロセスの幾つかを示しているが、ホストとデバイスの間のシステムバスの動作に関して示している。認証と保護パーティションのＦＡＴ読み取りのプロセスを図１１Ａに示している。先ず、ホストは、認証のためにユーザー名＋パスワードをカードに送る。認証されると、カードは、アプリケーションが、保護され、隠されているパーティションからＦＡＴを読み取ることができるようにする。パーティションは、ホストがセッションを終了するまで、又はデバイスがパワーサイクルを使い果たすまで、開いたままである。パーティションが開いている限り、隠しパーティションへのホストアプリケーションによる読み取りと書き込みは、許される。
【００７３】
図１１Ｂは、保護パーティション内のファイルのホスト読み取りを示している。先に述べた様に、アプリケーション特定読み取りコマンドは、２つのカードプロトコルコマンド、即ち、読み取りコマンドおよび引数の性質を指定する書き込みコマンド、ならびに実際の読み取りコマンド、内で発生する。
【００７４】
図１１Ｃは、隠しパーティションへのホスト書き込みを示している。認証に合格すると、ホストは、パーティションのＦＡＴにアクセスし、新しいファイルをホストへ転送する権利を得る。ホストは、書き込みコマンドを、書き込み開始アドレス及びセクター数と共に保護パーティションに送る。
【００７５】
図８は、上で紹介したデバイスアプリケーション状態の実施形態を、隠されているパーティション例の代表的な値と共に示している。幾つかの異なるパーティションも許されるので、デバイスアプリケーションパーティションＩＤのバイト１は、例では「１」として呈示されている。次の４つのバイトは、パーティションのサイズを示し、ここでは１０メガバイト分のセクターとして示されている。バイト５は、パーティションが目下開放されているか否かを示し、次の４つのバイトは、デバイスアプリケーションのバージョンを示すために与えられている。バイト１０は、動作状態を提供する。バイト１０−５１１は、セクターを形成するためゼロが詰められている。或るバリエーションでは、バイト１１は、最新のトランザクションで書き込まれたセクターの数を記録するのに用いられてもよい。
【００７６】
表１は、隠しパーティションのデバイスアプリケーションに送られるアプリケーションプロトコルコマンドの例を載せている。ＣＭＤインデクスは、コマンドセクターのバイト３３に置かれ、コマンド引数は、バイト３４から、表に書き込まれた指定順に置かれている。
【表１】

【００７７】
埋め込まれて隠されているパーティションコマンドはＳＤプロトコルの様なデバイスの書き込みプロトコルを通して転送されるので、パーティションのコマンドインタープリターは、書き込み又は読み取りコマンドが実際にはパーティションのデバイスアプリケーション用であり、ＳＤの通常のオペレーション用ではないことを証明した後で、例えばＳＤコマンドインタープリターによって呼び出される。コマンドインタープリターは、コマンドセクターを解析した後で、適切なルーチンを呼び出す。或る特定の実施形態では、アプリケーションのコマンドは、ＭＤコマンドが読み取りコマンド又は書き込みコマンドの何れであるかを示すパラメーターを、第１引数として有することができる。第２パラメーターは、ポインタを、割り当てられたＲＡＭ内の、コマンドセクターが置かれている場所へ送ることができる。パーティションのデバイスアプリケーション用の関連情報は、セクターのこの点で始まるので、ポインタは、バイト３３、コマンドオペレーションコードインデクスを指す。この第２パラメーターによって指し示されるバッファのサイズは、第３パラメーター内に指定される。
【００７８】
既に述べた様に、デバイスアプリケーション用の書き込みコマンドは、コマンドセクターがカードプロトコルの順序と同じ順序で解析された直後に実行されるので、簡潔である。例えば、ＳＤの場合は、
１．ＳＤ書き込みコマンド（１つ以上のセクター）が受け取られ、第１セクターは、代表的な実施形態では、常にコマンドセクターである。
２．カード層は、第１セクターの最初の３２バイトを解析し、コマンドセクターのシグネチャーを認識する。デバイスアプリケーションコマンド解析器（インタープリター）は、ポインタとともにコマンドセクターに呼び出される。
３．コマンドインタープリターは、埋め込まれているアプリケーションコマンドを識別した後で、埋め込まれたコマンドを実行してアプリケーションのコマンドプロセスを開始することになる、対応するルーチンを呼び出す。
４．隠されているパーティションのアプリケーション用のコマンドプロセスが行われ、状態がカード層に戻され、ＳＤ書き込みコマンドプロセスが終了するとシーケンスが終了に向かう。ＳＤカードはアイドル状態に入る。
【００７９】
これも先に述べた様に、隠されているパーティションのアプリケーションプロトコルの読み取りコマンドは、２段階のプロセスであり、（ここでも、ＳＤ実施形態では）ＳＤ−書き込みコマンドと、その後のＳＤ−読み取りコマンドで構成されている。第１ステップはＳＤ−書き込みコマンドであり、
１． ホストによって送られた１つのデータブロック（５１２バイト）によるＳＤ−書き込みコマンド−第１セクターは、代表的な実施形態では、常にコマンドセクターである。
２． カード層は、第１セクターの最初の３２バイトを解析し、コマンドセクターのシグネチャーを認識する。デバイスアプリケーションのコマンド解析器（インタープリター）は、ポインタでコマンドセクターに呼び出される。
３． コマンドインタープリターは、埋め込まれているアプリケーションコマンドを識別した後で、（次のＳＤ−読み取りコマンドで）実行されることになる埋め込まれている読み取りコマンドを識別し、このコマンド識別子を保存する。次に、コマンドインタープリターは、カード層読み取りコマンドフラグを設定する。
４． アプリケーションのコマンドプロセスが行われ、状態がカード層に戻され、ＳＤ−書き込みコマンドプロセスが終了するとシーケンスが終了に向かう。ＳＤカードは、アイドル状態に入る。
第２ステップはＳＤ−読み取りコマンドであり、
１． ＳＤ読み取りコマンド。
２． ＳＤカード層は、アプリケーションカード層読み取りコマンドフラグを検査し、通常のＳＤ読み取りコマンドを呼び出すのではなく、デバイスアプリケーションコマンドインタープリターを、読み取りコマンド指示によって呼び出すように設定されていることを見つける。
３． デバイスアプリケーションコマンドインタープリターは、パーティション読み取りコマンドフラグを識別し、先の書き込みコマンドに保存されていたパーティション読み取りコマンド識別子を呼び戻す。識別子は、対応するパーティション読み取りルーチンに命じて、パーティション読み取りシーケンスを開始する。
４． パーティション読み取りシーケンスが行われ、戻された状態がカード層に送られる。
５． カード層は、ＳＤ−読み取りプロセスを終了し、カードはアイドル状態に入る。
【００８０】
読み取り及び書き込みプロセスが、カード側アプリケーションのコマンド状態マシンにより示されており、図１２にＳＤベースの実施形態で示されている。これらの埋め込まれたコマンドはＳＤ書き込みコマンドによって送られ、隠されているパーティションの読み取りコマンドを実行しなければならないとき、ホストは、コマンドセクターをＳＤ読み取りコマンドで送ることができないので、デバイスアプリケーション（１０２３）コマンドインタープリターは、状態マシンを、どの読み取りコマンドがホストアプリケーション１０５３によって実行されているかを管理し知っているように維持しなければならない。この図で、バブルは、デバイスアプリケーション層（図６、１０２３）で実行されるデバイス特定アプリケーションコマンドを指し、添付のコメントは、中間（ここではＳＤ）プロトコルにあるＦＥ層（図６、１０２１）に見られるコマンドを指す。図１２の右側（Ａ経路）は、書き込みプロセス用のプロセスであり、データがデバイスに転送されるか、データが転送されないかの何れかであるどの様なプロセスでも、同様な流れを辿ることになる。図１２の左側は、データがデバイスからホストへ転送される読み取り又は他のプロセスに対応している。読み取りの流れは、読み取りに必要な対の第１コマンド用のＢ経路と、対の第２コマンド用のＣ経路とで構成されている。
【００８１】
書き込みの流れと読み取りの流れは、共に同じように始まり、ＳＤ書き込みコマンドを受け取り、その書き込みコマンドから、シグネチャーが検出された後で、埋め込まれたコマンドが解析される。書き込みの流れでは、書き込みフラグが駐在しており、書き込みプロセスが実行される。しかしながら、読み取りの流れの最初のフェーズでは、読み取りフラグが設定されることになる。このカード層（ＳＤ）読み取りプロセスフラグは、ホストからの読み取りプロセスが検出されるときに、デバイスアプリケーション（１０２３）によって設定される。フラグは、（ＳＤバス上の）ホストからの次の読み取りコマンドは通常のカード読み取りではなく、取り扱うためデバイスアプリケーション（１０２３）に送らねばならないことを、カード層に示す。これは、読み取りの流れのフェーズ２で起こり、そこでは、対の第２コマンドに応答して、データがデバイスから転送される。フラグは、カード層が初期設定するときにリセットされる。
【００８２】
表１に挙げたコマンドを見ると、ＯＰＥＮ＿ＰＡＲＴＩＴＩＯＮコマンド（ＯＰ−コード ０ｘ０１）は、ユーザー名とパスワードを受け入れ、それらを検証する。それらが、デバイスアプリケーションの記憶されている名前及びパスワードに合致すれば、パーティションは、ホストのアクセス（読み取り、書き込み）に対して開かれる。この時点で、１つの認証フレーズが送られ、デバイスアプリケーションのコードのフレーズに対して検証される。このプロセスを図１３Ａに示している。パーティションは、ＣＬＯＳＥ ＰＡＲＴＩＴＩＯＮがパーティションを閉じるまで、又は次のパワーサイクルまで、開かれたままになる。
【００８３】
ＣＬＯＳＥ ＰＡＲＴＩＴＩＯＮコマンド（ＯＰ−コード ０ｘ０２）を使用するのは、アプリケーション作業セッションを閉じ、パーティションを開いたままにしないためである。或る実施形態を図１３Ｂに示している。
【００８４】
ＲＥＡＤ ＰＡＲＴＩＴＩＯＮコマンド（ＯＰ−コード ０ｘ０３）の使用について図１３Ｃに示している。パーティションが開いていれば（１６３３から１６３５までのイエス経路）、このコマンドは、ホストアプリケーションが、パーティション（１６３９、１６４１）に記憶されているデータを読み取ることができるようにする。代表的な実施形態で、このルーチンは、「フラッシュ読み取り」ＡＰＩルーチンを呼び出し、このルーチンは、隠されているパーティション空間へのデータ転送を命じる。
【００８５】
ＷＲＩＴＥ ＰＡＲＴＩＴＩＯＮコマンド（ＯＰ−コード ０ｘ０４）は、データを、ホストからカード上の隠されているパーティションに送る。図１３Ｄに示している様に、このコマンドは、パーティションフラグが設定された（１６５３）ときにだけ、デバイスアプリケーションによって実行される。このルーチンは、「フラッシュ書き込み」（１６５９、１６６１）ＡＰＩルーチンを呼び出し、このルーチンは、隠されているパーティション空間へのデータ転送を命じる。
【００８６】
ＲＥＡＤ ＰＡＲＴＩＴＩＯＮ＿ＳＴＡＴＵＳコマンド（ＯＰ−コード ０ｘ０５）は、図８に示している情報を提供する。これは、図８に関して先に論じた構造を備えたアプリケーション読み取りコマンドである。コマンドが入ってくると、ルーチンは、全ての情報を集め、それを上記構造内に置き、ホストへ送る。
【００８７】
先に述べた様に、或るオペレーティングシステムは、時には命令を分割するので、データ部分の全てが、その対応するコマンド部分に取り付けられるわけではない。この場合、書き込み命令のデータの一部は、カードパススルーシグネチャー無しにカードに現れるので、シグネチャーが取り付けられていない伝送プロトコル内の標準的なコマンドと見えるものは、実際には、アプリケーション特定コマンドの残りのこともある。具体例として、例えば１０ブロックのデータ部分５１３を有する図５の命令５１０の場合を考える。この命令をカードに伝送する際に、ホストのオペレーティングシステムは、データ部分の最初の５ブロックだけを命令に取り付けて送り、残りの５つのブロックを後で伝送することもある。この後者のデータブロックのセットは、送られるときは、シグネチャーとアプリケーションプロトコル用の実際のコマンドが入っている最初のデータブロック５１３ａを欠いており、伝送プロトコルからの標準的なコマンドの一部の様に見える。その様なセグメント化は、埋め込まれたアプリケーション特定コマンドが読み取り型式のコマンドであるときにも起こり得るので、データは、複数の部分でカードからホストへ送られる。図１０Ｂは、図１０Ａの流れを拡張したもので、アプリケーション特定の読み取り及び書き込みコマンド両方におけるその様なセグメント化を、読み取り及び書き込みプロセスにおいて１つの論理ブロックアドレスＬＢＡ＝ＬＢＡ＿ＸＹＺを論理アドレスＬＢＡ_Ｒｉ及びＬＢＡ_Ｗｉと置き換えることによって、説明している。読み取りにＬＢＡ_Ｒｉ、そして書き込みにＬＢＡ_Ｗｉを定義することによって、デバイスは、何れの方向にアプリケーションデータを転送する際の中断にも対処することができる。添え字ｉは、複数のアプリケーション及び複数のユーザーのホスト装置からの複数のアプリケーション特定コマンドの同時実施を考慮している。
【００８８】
図１０Ｂのプロセスは、これも、ＳＤプロトコルを伝送プロトコルとして使用するＳＤカードの例に基づいており、デバイスがＳＤアイドル状態にあり、コマンドを１２０１で受け取ることで始まる。次に、プロセスは、受け取った命令がＳＤ書き込み（１２０３）であるか否か、そしてそうでなければ、それがＳＤ読み取り（１２０５）であるか否かを判断する。それがＳＤ書き込みでもＳＤ読み取りでもなければ、ＳＤコマンドが実行され（１２０７）、デバイスはアイドル状態へ戻る（１２０９）。
【００８９】
受け取った命令が、ステップ１２０３でＳＤ書き込みであれば、次に、パススルーシグネチャーが検査される（１２１４）。１２１４でシグネチャーが見つかれば、これは新しい埋め込まれたコマンドの開始を示しており、このコマンドは次に抽出することができる。１２３１で、読み取り及び書き込み論理ブロックアドレスＬＢＡ_{Ｒｉ；Ｗｉ}の全てに対し、入ってくるコマンドの論理ブロックアドレスＬＢＡ_ＣＭＤが、目下の書き込みプロセスに割り当てられている論理ブロックアドレスと同じ、即ちＬＢＡ_ＣＭＤ＝ＬＢＡ_Ｗｉであれば、対応するＬＢＡ_{Ｒｉ；Ｗｉ}がクリアされる。通常は、割り当てられているＬＢＡ_ＣＭＤを使用すべきでないが、それが既に他のプロセスに割り当てられている場合は、それを打ち切り、アドレスをクリアすることになる。
【００９０】
次に、アプリケーション特定コマンドのデータ方向が判断される（１２３３）。データ転送を伴っていなければ、アプリケーション特定コマンドが実行され（１２４５）、デバイスはアイドル状態へ戻る（１２４９）。
【００９１】
アプリケーションのコマンドが書き込みであれば、対応する論理アドレスは、ＬＢＡ_Ｗｉ＝ＬＢＡ_ＣＭＤ＋データブロック数と設定され（１２５１）、アプリケーションデータが書き込まれる（１２５３）。先に論じた様に、ホストのＯＳは、命令を分割するかもしれないので、コマンドに、対応するデータの全てが伴っているわけではない。埋め込まれたコマンドが抽出され、解析されると、カードは、コマンドがどれだけの数のデータブロックを含んでいるかを知ることになる。１２５５で、カードは、全データが含まれており書き込まれたか否かを調べるために検査する。そうであれば、ＬＢＡ_Ｗｉはクリアされ（１２５７）、そうでなければ、残りのデータは、エラーやシャットダウンで中断されなければ、最終的には後に続き、上で計算されたアドレスである（このコマンドに対して）連続したカードアドレスへの標準的なＳＤ書き込みコマンドの様になるので、クリアされない。デバイスは、次に、アイドル状態へ戻り（１２５９）、更なるコマンドを待つことになる。
【００９２】
１２３１に戻り、アプリケーションコマンドが読み取りであれば、デバイスは、ＬＢＡ_Ｒｉ＝ＬＢＡ_ＣＭＤを設定し、データタイプ_Ｒｉ＝データタイプ_ＣＭＤを設定して（１２３５）、第２読み取りフェーズでの１２６３における後続のデータ転送への準備とする。デバイスは、次に、ＳＤアイドルモードに進み、読み取りプロセスの第２フェーズを待つ。この解決法の異なるバリエーションは、ＬＢＡ_ＣＭＤを使用しないが、異なるアドレスＬＢＡ_ＲＥＡＤは、書き込みコマンドのパラメーター内に明示的に定義される。この方法は、ＯＳのキャッシング機構の回りで作業する。幾つかのシステムでは、ホストＯＳは、書き込まれたばかりのカードアドレスを読み返そうとしない。ホストＯＳは、データバッファをホストキャッシュバッファからホストアプリケーションに戻すのではなく、このデータは、書き込まれたばかりなので、カードが有しているデータであると想定している。この場合、データバッファは、カードの応答ではなく、アプリケーション特定コマンドを含んでいる。
【００９３】
１２１４に戻り、（伝送プロトコル内の）コマンドは書き込みである（１２０３からのイエス経路）が、シグネチャーが無い（１２１４からのノー経路）場合、コマンドは、実際には、伝送（ここではＳＤ）プロトコル内の書き込みコマンドかもしれないし、アプリケーションプロトコル内の書き込みへの追加データかもしれない。これは、１２１５で判定され、何れのＬＢＡ_Ｗｉに対してもＬＢＡ_ＣＭＤ≠ＬＢＡ_Ｗｉであれば、それは標準的なＳＤ書き込みであり、１２１７で実行され、その後、カードはＳＤアイドル状態に入る（１２１９）。ＬＢＡ_ＣＭＤがＬＢＡ_Ｗｉの１つと合致すれば、コマンドは、実際には、対応するアプリケーションコマンドのデータ部分の追加分であり、流れは１２５１へ進み、この追加のアプリケーションデータが書き込まれる。
【００９４】
ステップ１２０５に戻り、コマンドがＳＤ読み取りであれば、それが実際にＳＤ読み取りであるか、又はアプリケーション読み取りの第２フェーズであるかが判定される。これは、１２２６でＬＢＡ_ＣＭＤとＬＢＡ_Ｒｉを比較することによって判定され、何れのＬＢＡ_Ｒｉに対してもＬＢＡ_ＣＭＤ≠ＬＢＡ_Ｒｉであれば、それは標準的なＳＤ読み取りであり、１２７７で実行され、その後、カードはＳＤアイドル状態に入る（１２２９）。そうではなくＬＢＡ_ＣＭＤが何れかのＬＢＡ_Ｒｉの１つと合致すれば、それはアプリケーション読み取りの第２フェーズである。
【００９５】
ＬＢＡ_ＣＭＤ＝ＬＢＡ_Ｒｉであれば、対応する論理アドレスは、ＬＢＡ_Ｒｉ＝ＬＢＡ_ＣＭＤ＋データブロック数と設定され（１２６１）、アプリケーションデータが読み取られる（１２６３）。デバイスはＳＤアイドル状態に入る（１２６９）。アプリケーション読み取りプロセスでは、代表的な流れは、アプリケーション書き込み側のステップ１２５５と１２５７に相当するものが欠けている。全ての対応するデータにアクセスされていても、これにより、対応する読み取りフラグの設定が維持される。ＬＢＡ_Ｒｉを開いた状態に保つことによって、エラーの場合にデータを再び読み取ることができる。この様にしておくと、アドレスが、例えばステップ１２３１での様に他の目的に再割り当てされた場合、ＬＢＡ_Ｒｉがクリアされるだけである。
【００９６】
１０Ｂで、図１０Ａに追加されているのは、アプリケーションデータの転送時の中断を考慮していることである。それらは、同じ論理アドレスに対する読み取りと書き込みの必要性を取り除いてもいる。これらは、オペレーティングシステムが十分に制御されていない場合に本技法を使用できるようにするが、それは、図１０Ａの実施形態に必要なある種の制御は、既知の制御可能なプラットフォームを必要とするかもしれないからである。更に、再度指摘するが、図１０Ｂは、複数のホストアプリケーションがあってもよく、それぞれが独立してカードと通信している場合、データ転送の中断は、１つのプロトコルからの命令の一部を他のプロトコルからの命令の部分の間に差し挟むかもしれないことを、より明示的に組み込んでいる。更に、読み取り及び書き込みプロセス両方で、別々のＬＢＡは、デバイスドライバ層内の何れの読み取り又は書き込みキャッシングでも迂回できるようにしている。
【００９７】
（第２の代表的な実施形態）
第１の例は、ファイルレベルで実施された。本発明の様々な態様は、デバイスドライバレベルで実施することもでき、ホストがウインドウズのオペレーティングシステムを使用している場合は、ウインドウズの標準的記憶デバイスドライバの様なデバイスドライバに要求を送ることによって、読み取り及び書き込みオペレーションを開始する。このコマンド通過方法の実施は、デバイスと直接通信し、ファイルシステムのオーバーヘッドを持っていない。しかしながら、この方法は、管理権を必要とする。ホストアプリケーションは、この方法を第１選択として試して使用し、それが失敗すれば、ファイルシステムオペレーションに移ることができる。インターフェース機能は、その方法の間で選択し、それに従って通信パイプを初期化するのに用いることができる。クライアントアプリケーションは、他のオペレーションの前に、このコマンドを呼び出す。アプリケーションが適切な管理権を欠いていれば、この方法で作業するのは例外になり、例外取り扱いコードに従って処理することができる。
【００９８】
本例は、上記背景技術で問題となった議論に基づいている。背景技術の議論は、ハードウェアカードリーダーを通してＰＣに接続されているメモリカードのコンテキストで問題を呈示したが、ここに提供されている他の例と同様に、以下において、状況がより一般的であることが分かる。メモリデバイスは、それが第２ホストに直接接続されているときでさえ、その様なプロトコル翻訳問題、又は、より正確には、無翻訳問題を抱えていることがある。この状況は、メモリデバイスが、メモリデバイスから見て、完全ではないプロトコルを有するホストに接続されているときに生じることがある。これが生じることがある１つの場合は、カードが、２セットの接点を有しており、一方はＵＳＢポートで使用し、他方は標準的なカード接点のセットに使用する場合である。（その様な二重接点のカード例については、２００４年４月１６日出願の米国特許出願第２９／２０３，６９３号、第１０／８２６，８０１号、及び第１０／８２６，７９６号に記載されている。）第３組の実施形態で論じている様に、プロトコル翻訳は、メモリデバイス自体の中に完全に入っており、ホストには分からない。更に、以下の通り、実施形態を、取り外し可能なメモリカードについて説明しているが、この議論は、埋め込まれているメモリデバイスに適用することもできる。
【００９９】
第２の代表的な実施形態の第１組の実施形態では、メディアカード特定コマンドを、メディアカードをホストするアダプター又はリーダーのファームウェアを変えること無くホストからカードに送ることができるようにするために、本発明は、指定された論理ブロックアドレス（ＬＢＡ）、即ちカード通過モードＬＢＡを使用し、データセクター内の特別なシグネチャーが、特別なコマンドがセクター内に埋め込まれていることをカードに通知する。これは、ファームウェア変更してコマンド通過（ＣＰＴ）モードをサポートすることによって、実施することができる。これは、アダプターのファームウェア変更を必要としないので、カードは、何れのＵＳＢリーダー又はアダプターでも実行することができる。
【０１００】
背景技術で論じた様に、様々な小型フォーマットフラッシュメモリカード（コンパクトフラッシュカード、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ｘＤ、及びソニーメモリスティック／メモリスティックＰｒｏなど）は、ホスト（デジタルカメラ、フラッシュメモリ音楽プレイヤー）と共に使用するための、異なる電気的インターフェースと、しばしばメディア特定コマンドとを有しており、このコマンドは、ＰＣとハードウェアアダプターの間で使用されるコマンドセットには見られない、ＰＣがカードを読み取ることができるようにしているものである。
【０１０１】
主要な態様では、本発明は、通常の読み取り／書き込みコマンドを尊重するため、カードのファームウェア変更を使用している。しかしながら、特定のＬＢＡへの読み取り／書き込みコマンドがオフセットすると、シグネチャーが検査され、コマンドのデータ部分に、メディアカードの特定コマンドが埋め込まれているか否か判定される。プロトコルは、どの様なメディアカードのファームウェアでも実施できる。従って、プロトコルは、アダプター、ＵＳＢリーダー、又はＰＣ（又は、完全なメディア特定コマンドセットにアクセスしない他のホスト）が使用する他のリーダーへ何らのファームウェア変更を要求しない。実際を言えば、カード製造者がこれをする方が、全てのリーダーのベンダでカードコマンドの全てに対してリーダーファームウェア変更を実施するよりも簡単である。
【０１０２】
本発明の様々な態様は、例を議論する際に、しばしば、セキュアデジタル（ＳＤ）又は小型フラッシュ（ＣＦ）の様な特定のカードや、ＳＣＳＩまたはＡＴＡの様な特定のプロトコルについて説明されることになるが、この様々な態様は、他の様々なメモリカードやステムにも適用されるものと理解されたい。カード構造とオペレーションに関する様々な詳細については、更に、本明細書で参考文献として援用している特許及び出願に記載されている。
【０１０３】
図１４は、カードとパーソナルコンピューター（又は、より一般的には、カードを読むのにハードウェアアダプターを必要とする全てのホスト）がリーダーを使って通信するプロセスを示している。図１４は、ＵＳＢラッパー又は同様の構造の明示的導入が無視されている場合もあることを除けば、図４と同様であり、これについては以下の議論でも削除されている。背景技術で述べた様に、カードとリーダーは、２０１で示す様に、カードのプロトコルのコマンドセットからの命令を使って通信する。ホストとリーダーは、通常は、２０３で示す様に、別のコマンドセットからの命令を使って通信する。リーダーは、２つのコマンドセットの間で、そのファームウェアを使って翻訳する。（ここで、そして以下でも、ファームウェアが引き合いに出されているが、これは、より一般的には、ハードウェア、ソフトウェア、又はこれらの組み合わせで実施することができる。）難しいのは、コマンド２０１が、ＰＣがリーダと通信するのに使用するプロトコルに等価物を持っていないカードのコマンドセットからのコマンドであるときである。この場合、その様な等価な命令２０３が無いので、リーダーは、２０１を、対応するコマンド２０３に翻訳することができず、他のやり方についても同様である。従って、ホストが、カードのメディア特定の命令の１つを使用したい場合、先行技術では、ＰＣハードウェアアダプタープロトコルのコマンドセットを変更すること無く、これにリーダーを通過させる手段が無い。
【０１０４】
この特定の例は、ホストからリーダーへはＳＣＳＩプロトコルを使用し、リーダーからカードへはＳＤプロトコルを使用しており、ＳＤコマンド、即ち、安全な書き込みの例は、埋め込まれたコマンドとしてＳＣＳＩプロトコルには存在しない。従って、このコマンドを、ＳＤカードで直接伝送することはできるが、本発明の態様を用いて、アプリケーションのホスト側が、ホストとリーダーの間でコマンドを搬送する中間ＳＣＳＩプロトコルで命令を伝送することができるようにしなければならない。リーダーでは、ダミーコマンドは、各プロトコルにバージョンを有しており、データとして扱われている実際の埋め込まれたコマンドとともに、プロトコル間で翻訳され得る。例えば、ダミーコマンドは、ここでも書き込みと取られる。従って、ホストとアダプターの間では、それはＳＣＳＩ書き込みコマンドと表され、アダプターとカードの間では、ＳＤコマンドと表されるが、どちらの場合も、実際のコマンドはデータ部分に埋め込まれている。従って、この例では、埋め込まれたコマンドは、第２プロトコルに在るが、このやり方に沿った或る時点では、このアプリケーション特定コマンドを欠いたプロトコルで送られるので、それはまだ埋め込まれている。従って、これは、同じプロトコルのコマンドに埋め込まれている第１プロトコルのコマンドになるので、それと、埋め込まれているコマンドの等価物を持ち合わせていない別の第２プロトコルとの間の翻訳が可能になる。これは、図１５に示されている。この議論は、主にＳＣＳＩとＳＤ実施形態について論じているが、より一般的には他のプロトコルにも適用されるものと理解されたい。
【０１０５】
図１５は、ＰＣ−リーダーのコマンドセット内に等価物を有していないカードのコマンドセットからのコマンドが、両方のコマンドセットの表現を有しているＰＣ−リーダープロトコルの命令２０３に埋め込まれているときの、本発明の基本的態様の概略図である。代表的な実施形態では、メディア特定コマンドは、ここでも、ＰＣ−リーダープロトコルのデータ部分に埋め込まれている。すると、ＰＣとリーダーは、リーダーが対応するコマンド２０１に翻訳することのできるコマンド２０３を交換することができる。しかしながら、このコマンド内には、別のメディア特定コマンド６０１が埋め込まれている。リーダーは、このコマンドを、そのオペレーションにトランスペアレントな方式で通過して翻訳する。代表的な実施形態の機構は、両方のコマンドセットの表現を有する命令２０１／２０３が、カードのメモリ内の予め決められた論理アドレスへのアクセスであるということである。例えば、カードは、指定された論理アドレスへの読み取りコマンドを受け取ると、これがメディア特定コマンド６０１であると警告される。（以下に説明する様に、以下の実施形態は、その様な指定された論理アドレス、より一般的には、書き込みコマンドだけに依存せず、データ部分を備えたあらゆるコマンドが利用されてもよい。）カードは、次に、その様なコマンドのシグネチャーを検査し、これを検証し、次いでコマンド６０１を抽出する。代表的な実施形態では、ＳＣＳＩ及び他のプロトコルでは、メディア特定コマンドを命令のコマンド部分に埋め込むのに都合のよい場所が無いことが多いので、コマンド６０１は、命令のデータ部分の内側に置かれる。
【０１０６】
例えば、ＰＣがＳＤカードの安全な領域の書き込みを行いたければ、命令２０３を形成するが、その命令は、指定された論理ブロックアドレス（ＬＢＡ）への書き込みコマンドで構成されており、コマンドパススルー（ＣＰＴ）シグネチャーが入っていて、実際の安全な書き込みコマンド６０１がデータ部分に埋め込まれている。次に、ＰＣは、この命令２０３をリーダーに送り、リーダーは、それを、ＳＣＳＩプロトコルの標準的な書き込み命令として解釈する。次に、これは、リーダーによって、ＳＤプロトコルで標準的な書き込み命令２０１に翻訳される。リーダーは、安全な書き込みコマンド６０１を、それが書き込みコマンドに取り付けられているデータの一部分であると想定して、通過するだけである。命令２０１がカードに到着すると、書き込みのために指定されたＬＢＡに基づいて、ファームウェアは、カードが、命令はそうではなくてメディア特定コマンドであると判定できるようにする。コントローラーは、次に、安全な書き込みであると認識するコマンド６０１を抽出し、命令の実際のデータ部分の安全な書き込みを実行することによってコマンドを実行することに着手する。
【０１０７】
図１６は、ＮセクターのデータのＳＤカードへの安全なデータ書き込みを実行する例に関する具体的な実施形態について、より詳細に述べている。一番上の行は、ホストによって形成される命令を示している。安全なデータ書き込みは、例のＳＣＳＩプロトコルの類似物を有していないので、コマンド部分は、ＳＣＳＩプロトコルのコマンドＣＭＤ’、ここでは両方のコマンドセットに存在している書き込み、で構成されている。書き込みは、指定されたコマンド通過論理ブロックアドレスＣＰＴＬＢＡ（議論を単純化するため、他のコマンドの詳細については示さない）に行われる。破線の右側のデータ部分は、最初のセクターで構成され、メディア特定コマンドが入っており、それに実際のデータのＮ個のセクターが続いている。最初のデータセクターは、コマンドパススルーシグネチャー、実際のメディア特定コマンド、及び後続のデータが書き込まれることになる実際のアドレスを含んでいる。論理ブロックアドレスＣＰＴＬＢＡは、先に論じた第１の代表的な実施形態の議論に用いられている論理ブロックアドレスＬＢＡ＿ＸＹＺに相当する（例えば、図１０Ａ参照）。異なるラベル付けは、ホスト側でデバイスドライバレベルで実施されている本例では、用いられている論理ブロックアドレスが、具体的な指定された論理ブロックアドレスであり、ファイルレベルで実施されている先の例では、それは何れのアドレスでもよい、ということを示すのに用いられている。
【０１０８】
図１６は、先に論じた図５と似ているが、命令５１０は、この例で明示的に示されている（ホストからリーダーへ、リーダーからデバイスへの）各伝送プロトコル毎に一回繰り返される。図５の命令５１０は、アプリケーションのホスト側とデバイス側の間の伝送経路に沿った何処かで起こるコマンドＣＭＤの埋め込みを示しており、命令５３０は、アプリケーションのデバイス側で使用されることになる抽出された形態を示している。図１６は、幾つかの中間プロトコルが存在してもよく、実際のコマンド（ＣＭＤ）は、埋め込まれたコマンドが特定の中間プロトコルに類似物を有する場合でも、これらの内の幾つかを通して埋め込まれることを示している。
【０１０９】
リーダーから見ると、第１データセクターは、指定された論理ブロックアドレスに書き込まれることになるＮ＋１個のデータセクターとして見えるものの最初の１つに過ぎない。従って、これらは、コンテンツが変更すること無く通過する。命令のコマンド部分は、リーダーによって、ＰＣ／リーダープロトコル（ＣＭＤ’）の表現から、カードのプロトコル（ＣＭＤ）の表現に翻訳される。この時点で、命令は、カードに伝えることはできるが、まだ、例えばＣＰＴＬＢＡへの書き込みコマンドの後にＮ＋１個のデータセクターが続く形態を有している。
【０１１０】
カードに入ると、ファームウェアは、実際のコマンドを解きほぐすことができる。ファームウェアは、コマンドが指定されたアドレスを使用すると判定すると、第１データセクターに進み、ＣＰＴ署名を検査し、実際のメディア特定コマンドを抽出する。これは、実際の命令のコマンドを形成し、その後に、Ｎ個の実際のデータセクターが続く。
【０１１１】
従って、図１６に関して述べた様に、Ｎ個のデータセクターを備えたメディア特定書き込みコマンドは、ＰＣとリーダーの間で用いられる伝送プロトコルにＮ＋１個のデータセクターとして埋め込まれる。Ｎ個のデータセクターを読み取るために、メディア特定読み取りコマンドは、ＰＣとリーダーの間で用いられる読み取り（又はデータを受け入れる他のコマンド）又は伝送プロトコルに１つのデータセクターとして埋め込まれる。この様に、メディア特定読み取りコマンドは、メディア特定読み取りコマンドがデータセクターだけに埋め込まれた書き込みコマンドとして実施することができる。カードは、やはり指定された論理アドレス（ＣＰＴＬＢＡ）と署名に基づいて、メディア特定コマンドを抽出し、メディア特定読み取りで指定された要求された論理ブロックアドレスからのデータに応答する。書き込み又は読み取り失敗の様な複雑なものに対処するための読み取り実施と方法の詳細については、第１の代表的な実施形態に関して先に詳しく展開した。
【０１１２】
指定された論理アドレス（ＣＰＴＬＢＡ）は、ファイルシステムで普通は使用されないセクターであるのが望ましく、そうしておけば、このセクターに送られてくるかもしれない標準的な読み取り又は書き込みコマンドとの衝突を回避できる。例えば、ＤＯＳでは、普通は、マスターブートレコードの後に、通常はアクセスされない幾つかの隠されたセクターがある。（オペレーティングシステムの中には、この領域にアクセスするには管理者特権を必要とし、次のセクションのファイルベースの実施において起こり得る厄介なことを迂回できるようになっているものもある。）この論理アドレスを指定された論理アドレスとすることにより、このアドレスへのアクセスは、実際にそこでデータの読み取り又は書き込みを行うためではなく、実際のコマンドは埋め込まれているメディア特定コマンドであることを検査する目的のためである。リーダーは、このコマンドを、通常のデータアクセスとして通過するだけで、カードが全てをソートする。
【０１１３】
図１７Ａ−１７Ｌは、コマンドの様々な例を、どの様にデータセクターに埋め込むことができるかの１つの実施形態を示している。先に述べた様に、メディアカードへの書き込みが実行されると、データ部分の第１セクターには、ＣＰＴ（カード通過）コマンドが入る。それは、ＣＰＴ機能が実行されることを示している。従って、１０個のセクターに書き込む際は、第１セクターはＣＰＴヘッダーなので、実際には、１１個のセクターに書き込む。１０個のセクターを読み取るには、ユーザーは、ＣＰＴコマンドの１つの書き込みを送り、次いで１０個のセクターを読み取らなければならない。実際のアプリケーションは、通常の読み取り又は書き込みコマンドでは達成できない特定のコマンドを実行することである。例えば、ＣＰＴモードは、ＡＫＥ（認証キー交換）の様なメディア特定コマンドか、又はＳＤカード用のアプリケーションコマンドに用いることができる。
【０１１４】
図１７Ａは、埋め込まれたコマンドフォーマットの実施形態を示している。バイト０−３１のＣＰＴシグネチャーは、シグネチャーがコマンドと合致することを検査するためのコマンドに依存する文字列である。バイト３２のコマンドは、
０−ＣＰＴモードチェック：ＣＰＴモードサポートに関しメディアカードを検査する
シグネチャー「カード通過モード検査」
１−データアウト：メディアカードに書き込まれるデータ
シグネチャーカード通過出力コマンド」
２−データイン：メディアカードから読み取られるデータ
シグネチャー「カード通過入力コマンド」
３−データ転送が無いコマンド
シグネチャー「カード通過ノーＩ／Ｏコマンド」
４−ＣＰＴコマンド打ち切り
シグネチャー「カード通過打ち切りコマンド」
５−ＣＰＴモードリセット
シグネチャー「カード通過リセットコマンド」
６−ＣＰＴ状態読み取り
シグネチャー「カード通過状態読み取り」
データ転送長さ（バイト３３−３５）は、転送されるデータの量（バイト数として）を指定し、データはセクターに転送されるので、不完全なセクターには０が詰められる。データ（バイト３６、ビット１）は、データ転送のフラグであり、次のコマンドにデータ転送が無ければ「０」であり、次のコマンドにデータ転送があれば「１」である。同様に、方向（バイト３６、ビット０）は、データ転送方向のフラグであり、データ転送が次のコマンドへの入力のためであれば「０」であり、データ転送が次のコマンドへの出力のためであれば「１」である。
【０１１５】
メディアカード特定コマンド領域（バイト４８−５１１）は、コマンドが抽出されるとメディアカードが実行する実際のコマンドである。メディアカード特定フラグ領域（バイト３６、ビット０）は、メディア依存フラグのためのものである。
【０１１６】
メディアカードは、カード通過コマンドプロトコルをサポートするか否か、実際のコマンドが送られる前に検査されねばならない。先に述べた様に、ＬＢＡ（ＣＰＴＬＢＡ−カード通過ＬＢＡ）は、プロトコルに対して指示される。ＬＢＡは、カードの０から最終セクターまでのどの様な数でもよい。例では、これが、ＬＢＡ２であり、ＦＡＴファイルシステム内のマスターブートレコード後の第２の隠されたセクターであり、通常、データを保持するのには用いられない。ＬＢＡに有効データが入っている場合でも、このプロトコルは、その値を留保することに注目されたい。モードサポートを検査するには、２つの選択肢がある。
【０１１７】
プロトコルのサポートに関して問合せる第１の選択肢は、メディアカードがＣＰＴモードサポートシグネチャーをＣＰＴＬＢＡセクターに置くときのものである。しかしながら、これは、ＣＰＴＬＢＡが、有効な情報を有するセクター、例えば、ＦＡＴ／ディレクタリ又はユーザーデータ領域内のセクターである場合は望ましくない。ＣＰＴモードがサポートされている場合は、随意的に、カードは、図１７Ｂに示している様に、ＣＰＴＬＢＡセクターをシグネチャーと共に戻すことができ、バイト０−３１は「カード通過モードはサポートされている（空白で詰められている）」であり、バイト３２−５１１は０である。
【０１１８】
プロトコルのサポートに関して問合せる第２の選択肢は、ＣＰＴＬＢＡセクターに、ＣＰＴモードをサポートするシグネチャーが入っていない場合に用いることができる。この場合、以下のプロトコルが、モードサポートを検査するのに用いられ、
ａ）ホストメモリ領域のＣＰＴＬＢＡセクターを読み取り、保存する。
（サポートするシグネチャーは無い）
ｂ）ＣＰＴＬＢＡに、ＣＰＴモードサポートを問合せるためのシグネチャーが入っているセクターを書き込む。
ｃ）ＣＢＴモードサポートの応答を検査するため、ＣＰＴＬＢＡセクターを読み取る。
ｄ）ＣＰＴＬＢＡに、保存されたメモリ領域からのオリジナルセクターを書き込む。
ステップａ）は、指定された論理アドレス（ＣＰＴＬＢＡ）を、ホストがＣＰＴＬＢＡセクターを読み取り、且つ、メモリに保存するときに、中に入っている全てのデータを維持したままで、サポートに関して検査することができるようにしている。これは、メディアカードがカード通過モードをサポートしていない場合に、セクターを復元するためである。この書き込みは、ＣＰＴモードコマンドを使用しない。
【０１１９】
図１７Ｃは、ステップｂ）、ＣＰＴＬＢＡに問合せるためのシグネチャーが入っているセクターを書き込むことを示している。バイト０−３１は、ホストが、バイト０−３１のＣＰＴＬＢＡセクター「カード通過モード検査」（空白で詰められている）と書き込むことを含み、その後、バイト３２−４７では、コマンドとフラグが続く。バイト４８−５１１は０である。
【０１２０】
ステップｃ）ホストは、応答するためにＣＰＴＬＢＡセクターを読み取る。応答が図１７Ｄの様に、バイト０−３１は「カード通過モードはサポートされている」（空白で詰められている）であり、バイト３２−５１１は０であれば、カード通過モードがサポートされており、他の場合は、カードはＣＰＴプロトコルをサポートしていない。このプロトコルは、プロトコルのサポートに関して問合せるための第１選択肢とは異なることに注目されたい。ＣＰＴモード検査コマンドが発行されるときに、シグネチャーに応答がある。
【０１２１】
ステップｄ）で、ホストは、保存されているメモリ領域からＣＰＴＬＢＡセクターのオリジナルデータを書き込む。カードがカード通過モードをサポートしていても、適正なシグネチャーが無いので、この書き込みは、特別なＣＰＴコマンドと解釈されないことに注目されたい。
【０１２２】
図１７Ｅ−１７Ｇに関し、入力／出力プロトコルを説明する。データをメディアカードに出力するには、先ず、ＣＰＴＬＢＡに出力用のシグネチャーを書き込み、その後、データ転送長さに基づいてデータを書き込む。ＣＰＴＬＢＡに出力用のシグネチャーを書き込むために、ホストは、書き込みコマンドをメディアカードに送るが、データは、メディアカード特定コマンドが埋め込まれているＣＰＴコマンドフォーマットを有している。長さは、「データ転送長さ」とＣＰＴコマンドフォーマット用の１個のセクターを加えたものである。これは図１７Ｅに示されており、バイト３２の１は、「メディアカードに書き込まれることになるデータ」に対応する。
【０１２３】
データ転送長さに基づく実際の書き込みを図１７Ｆに示しており、メディアカードがデータをどの様に扱うかは、メディアカード特定コマンド次第である。図１７Ａについて述べたように、この例の「データ転送長さ」情報は、バイトで言えばバイト３３−３５（ＭＳＢ、ＬＭＳＢ、ＬＳＢ）で表現されている。しかしながら、読み取り／書き込みデータがカードとセクターのリーダーの間で転送されるとき、不完全なセクターは、必要に応じて０を詰められる。（例えば、ＳＤカードでは、認証キー交換（ＡＫＥ）プロセスは、チャレンジ・レスポンスに８バイトを使用する。）従って、ホストは、データセクターに、チャレンジ１とレスポンス２のデータに対して５０４バイトの０を詰め、カードは、同様にチャレンジ２とレスポンス１のデータを詰める。
【０１２４】
データをメディアカードから入力する際は、ホストは、ＣＰＴＬＢＡに入力用のシグネチャーを書き込み、データ転送長さに基づいてデータを読み取る。図１７Ｇは、読み取られるデータを示すために送られることになるＣＰＴコマンドを示しており、バイト３２における２は「メディアカードから読み取られるデータ」に対応する。データ転送長さに基づいてデータを読み取る際は、ホストが読み取りコマンドをメディアカードに送った後、読み取られるセクターの数は[（データ転送長さ）／５１２]である。（これは、セクター当たり５１２バイトを想定しており、より一般的には、実際のセクター長さが異なる場合は、５１２に置き換わる。）開始セクターはＣＰＴＬＢＡである。先のコマンドはＣＰＴ入力コマンドなので、カードは、メディアカード特定コマンドに基づいて、そのデータをホストへ送る。
【０１２５】
入力又は出力の無いコマンドの例には、「データ転送の無いコマンド」、「ＣＰＴコマンド打ち切り」、及び「ＣＰＴモードリセット」が含まれる。図１７Ｈは、バイト３２における３で示す「データ転送の無いコマンド」を示している。
【０１２６】
図１７Ｉは、バイト３２における６で示す「状態読み取り」コマンドを示しており、これは、ホストがＣＰＴ状態を読み取れるようにする。例えば、ＳＤカードでは、状態は応答データとして実施することができる。状態は、読み返されたデータの最初の数バイトである。
【０１２７】
具体例が必要な場合はＳＤカードを取り上げているが、図１７Ａ−１７Ｉは、どの様な特定のメディアプロトコルにも限定されず、また、メディア特定コマンドにも限定されない。メディア特定コマンドの例を挙げると、図１７Ｊは、ＳＤ又はＭＭＣカードに特定の埋め込まれたコマンドを示しており、図１７Ｌは、コンパクトフラッシュカードに特定の埋め込まれたコマンドを示している。
【０１２８】
図１７Ｊでは、ＳＤ／ＭＭＣの例のためにコマンドのフォーマットを示している。バイト０−３５は上記の通りである。ＳＤ／ＭＭＣコマンドは、メディアカード特定コマンドフィールドを満たしている。バイト４８−５３は、ＳＤコマンド、例えば安全な読み取りである。メディアカード特定フラグフィールドには、幾つかのフラグが必要であり、定義されている。ＢＬＫＨは、コマンドが、１つのセクター用か、複数のセクター用かを示し、１つのセクターコマンドが用いられる場合は０、複数のセクターコマンドが用いられる場合は１である。アプリケーションコマンドの場合、ＡＰＰ＝１である。応答型式は、コマンドインデクス次第のＳＤ応答型式である。バイト４８−５２の様々なエントリは、ＳＤコマンドの実際の要素であり、バイト５３のＣＲＣ７は、随意に０に設定してもよい。
【０１２９】
ＳＤコマンドの応答データを得る際は、ユーザーは、状態読み出しを送って応答を得ることができる。これは、図１７Ｋに示されている。応答データは、読み取りされたセクターの最初の６バイトとして戻される。
【０１３０】
図１７Ｌは、埋め込まれたコマンド用の小型フラッシュ（ＣＦ）コマンドフォーマットを示している。この場合、コマンドは、バイト４８−５４にあり、ＣＦコマンドを備えるのに必要な要素を提供する。図１７Ｌでは、メディアカード特定フラグ（バイト３６−ビット２からバイト３７）が、将来の様々なカードに対するコマンド特定フォーマットに備えて予約されている。
【０１３１】
（第３の代表的な実施形態）
第３の代表的な実施形態は、第１の代表的な実施形態と同じく、ファイルレベルで実施される。ここで、議論は、ホスト側のファイル内に置かれているものの詳細の方に焦点を当てる。デバイス特定コマンドはファイル内に埋め込まれているので、ＦＡＴ領域の様なファイルシステム特定データに害を与える術は無い。カードの視点からは、異なる代表的な実施形態は、同様に見え、大きな違いは、情報がホスト側でどのように詰め込まれるかである。具体的なアプリケーションを参照する必要がある場合、第３の代表的な実施形態は、２００４年１２月２１日出願の米国仮特許出願第６０／６３８，８０４号に呈示されている様な、安全なバスへの安全なリンクの実施形態であり、同出願は、先に参考文献として援用されている。
【０１３２】
ファイルレベルの実施では、デバイスドライバレベルの実施で生じ得る特権問題の類を克服するだけでなく、特別なコマンドを送る特別なハードウェアを持つことに対して起こり得る必要性も克服することができる。例えば、デバイスドライバレベルの幾つかの場合では、ＳＤカードの安全な領域にアクセスするために特別なコマンドを送らなければならない場合があるが、ファイルレベルの実施では、情報がファイルに詰め込まれているので、最早その必要がない。そのため、ファイルに対する書き込みと読み取りが行える限り、どの様なコマンドセットでも、この実施で送信し受信することができる。
【０１３３】
先行するセクションの実施形態は、デバイスの入力／出力レベルで作動するカードドライバの実施である。ホスト又はＰＣアプリケーションとデバイス又はカードドライバの間にオペレーティングシステム（ＯＳ）ファイルシステムがある。第３組の実施形態は、ＯＳファイルシステムで作動するファイルＩ／Ｏ実施である。これらの実施形態では、ホストは、ファイルをメモリデバイスに書き込むようにファイルシステムに告げるだけであり、デバイス特定コマンドはここでも埋め込まれている。ファイルのフラッシュメモリへの書き込みの更なる詳細については、２００５年２月１６日出願の米国特許出願第１１／０６０，２４９号、第１１／０６０，１７４号、及び第１１／０６０，２４８号に記載されており、それら全てを参考文献としてここに援用する。これらの実施形態は、デバイスレベルの実施形態より少し多いファームウェアのオーバーヘッドを必要とするが、数多くの利点を有している。例えば、デバイスレベルでは、アプリケーションが開発される際に、ハードウェアに関する知識を有する必要があるのに対して、ファイルシステムを使うことによって、これは、ハードウェアからも、下部レベルのプロトコルの多くの詳細からも独立したものになる。
【０１３４】
デバイスレベルの実施形態と同様に、ファイルレベルの実施形態は、ベンダ特定コマンドを、ウインドウズ９８／ＭＥ／９５／ＤＯＳ及び同様の例に見られる高度ＳＣＳＩプログラミングインターフェース（ＡＳＰＩ）の様な各ベンダ製品に送るのに用いられる。先に述べたデバイスレベルの実施形態では、使用法は、特定の論理アドレスＣＰＴＬＢＡへの書き込みで作られた。しかしながら、多くのオペレーティングシステムでは、この論理アドレスにアクセスするには、或るアクセス特権が必要である。例えば、或る種のＳＣＳＩコマンドは、ユーザーが管理者特権を持っていなければ、ベンダ製品に送ることができない。オペレーティングシステムは、一般的にファイルの書き込みを許容するので、本発明のファイルレベルの実施形態は、メディア特定コマンドをファイルに埋め込み、ファイルをデバイスに書き込み、デバイスへの実際の埋め込みを元に戻すことによって、この特権問題を回避する。ウインドウズオペレーティングシステムの多くのバージョンでは、代表的なＣＰＴＬＢＡを使用しているカードレベルの実施形態は、管理者特権を必要とするのに対して、ファイルの書き込みは、その様な特別なアクセス特権を何ら必要としない。先のように、代表的な実施形態は、メディア特定コマンドを命令のデータ部分に埋め込んだ。
【０１３５】
オペレーティングシステムのファイルシステムレベルでの実施は、これも、プロトコルに従い、プロトコルを認識するように作られているカードのカードファームウェアによって実施される。シグネチャーは、何れかのＬＢＡへの読み取り／書き込みコマンドによって、検査され、埋め込まれているメディアカード特定コマンドがデータに入っているか否か判定される。この差が、特定アドレスを使用するデバイスのドライバ実施を形成する。他のやり方では、カードから見ると、このセクションのデバイスドライバレベル実施形態と、先のセクションのファイルシステムレベル実施形態との間に殆ど差は無い。
【０１３６】
先行セクションでのように、ファイルベース実施の代表的な実施形態は、プロトコルを、メディア特定コマンドが埋め込まれる「命令」部分と、コマンドが何らかのデータ転送を伴っていれば、コマンドに関係付けられたデータを保持する「データイン／アウト」部分とに分割する。プロトコルコマンドをカードが受け取ると、ファームウェアは、読み取り又は書き込みオペレーション中に特別なシグネチャーについて検査し、所与のＬＢＡが命令部分であるか否かを判定するが、これは、シグネチャーが常に最初のデータセクターに埋め込まれている実施形態では、プロトコルコマンドの最初のデータセクターで行う必要があるだけである。ホスト側のプログラマーから見ると、クライアントアプリケーションは、命令部分と、恐らくはデータイン／アウト部分とを有する簡単なファイル又は論理セクター（ＬＢＡ）書き込みオペレーションを発行する。ファームウェアは、コマンドがメディアに対するデータの読み取り又はデータの書き込みの何れかを伴っている場合は、論理対物理マッピングを実行する。ファームウェアは、ＡＰＩ命令部分を伝送プロトコルから書き込み又は読み取りとして受け取る際に、それを検出することになる。
【０１３７】
或る代表的な実施形態では、プロトコルコマンドの命令部分には、シグネチャー、問合せコマンド、ベンダ特定コマンド、及び更新可能フィールドが入っている。ここでは、サイズが、（最も一般的に使用されているデータブロックのサイズである）５１２バイトの倍数に制限される。代表的な実施形態の命令ページのフォーマットを図１８Ａに示しており、これは図１７Ａと非常に良く似ているが、更に詳しい。最初の３６バイトは暗号化されず、残りは、サポートされている暗号化アルゴリズムの存在を述べる暗号化／復号情報に従って暗号化／復号される。
【０１３８】
図１８Ａに示す様々なフィールドについて述べると、バイト０と１は、ＡＰＩ命令ページの候補になり得るＬＢＡを示すのに用いられるシグネチャーバイトである。ファームウェアは、これら２つのバイトが合致するか否か、ＡＰＩシグネチャーを検査する。以下の例では、バイト０は１９であり、バイト１は７３である。ＡＰＩシグネチャーは、ビット２−３４に続いており、文字による単一の列である。以下の例では、シグネチャーは「高度プログラミングインターフェース」とする。
【０１３９】
バイト３５は、ファームウェアに、後続の命令ページとデータページが暗号化されているか否かを告げる、暗号化／復号（Ｅ／Ｄ）情報である。暗号化されていなければ、このフィールドは、ＡＰＩ＿ＮＯ＿ＥＮＣＲＹＰＴＩＯＮと設定され、そうでなければ、暗号化名に設定されるので、ファームウェアは、バイト３６から始まる単数又は複数の命令ページと、データページを復号及び暗号化することができる。バイト３６−３９は、ファームウェア作動状態フィールドのフィールドであり、オペレーションの成功又は失敗に基づいて更新される。全てが上手く行けば、ＡＰＩ ＯＰ ＳＵＣＣＥＳＳと設定され、そうでなければ、エラー値又はＡＰＩ ＯＰ ＮＯ ＳＵＣＣＥＳＳと設定されることになる。そのデフォルト値は、コマンドを発行するときに、０ｘＦＦＦＦＦＦＦＦに設定されることが示唆されている。書き込み後に、発呼者は、命令ページを読み取り、要求したオペレーションが成功したか否かを検証することができる。ベンダ識別子フィールド（バイト４０−４３）を、固有のベンダ識別子として使用してもよい。このフィールドは、ファームウェアも有効なベンダＩＤを必要とする場合は、ファームウェアに対して自身を識別するために呼び出し環境によって使用することができる。
【０１４０】
命令ページ数のフィールド（バイト４４）は、ファームウェアに命令ページの総数を告げるが、命令ページは、５１２バイトが限界である。同様に、データページ数のフィールド（バイト４５−４６）は、ファームウェアに、命令部分に取り付けられているデータイン／アウトページの総数を告げる。データページのサイズは、必ずしもバイトでのデータサイズではなく、場合によっては、データバイトの最後に詰め込みが追加されることもある。例えば、ＤＥＳは、バイトでのデータサイズが８の倍数でなければならないことを要求する。バイトフィールド（バイト４７−５０）でのデータサイズは、有効なデータの入っているデータページ内のファームウェアのバイト総数を告げる。メディアから読み取る場合は、このフィールドを、ファームウェアによって、ページ領域内の実際の処理されたバイトサイズで更新しなければならない。データをメディアに書き込むことに関して、これは、データサイズのバイトでの長さである。データが暗号化されている場合、ファームウェアは、先ず、データページの全コンテンツを復号し、次に抽出を行う。バイト５１で、ビット０はデータ転送用のフラグであり、目下のコマンドがデータ転送を要求していない場合は「０」に設定され、目下のコマンドがデータ転送を要求している場合は「１」に設定される。
【０１４１】
バイト５１、ビット１と２は、データ転送の方向用のフラグである。数値「００」は、データ転送が目下のコマンドでは入力用であることを示しており、ファームウェアは、書き込み時間中にコマンドを処理し、一旦メディアへ書き込まれたデータページを無効にする。数値「０１」は、データ転送が目下のコマンドでは入力用であることを示しており、ファームウェアは、書き込み時間中に、無効にすることなくコマンドを処理する。数値「１０」は、データ転送が目下のコマンドでは出力用であることを示している。数値「１１」は、留保されている。バイト５１、ビット３からバイト５２は、メディアカード特定フラグであり、メディアカードの型式に依る。バイト５３−６３は、将来使用するために予約されているフィールドである。
【０１４２】
メディアカード問合せコマンドフィールド（バイト６４）は、メディアカードの目下の状態と能力を問合せるのに用いられる。既知のサポートには、ＡＰＩプロトコルにサポートされている、Ｅ/Ｄアルゴリズムにサポートされる、及びＡＰＩプロトコルサポートを使用不能にする、が含まれる。メディアカード問合わせコマンド戻し状態フィールド（バイト６５−６８）は、メディアカード問合せコマンドの戻し値を保持するのに用いられる。
【０１４３】
メディアカード特定コマンド長さ（バイト６９−７０）は、コマンドフィールドが記憶するコマンドバイトの総数を指定し、メディアカードが実行することになる実際のコマンドは、メディアカード特定コマンドに入っている（バイト７１−５１１）。
【０１４４】
命令ページには、あらゆるデータイン／アウトページが添付されることになる。確立された暗号システムアルゴリズムに基づく発呼者の環境とファームウェアは、コンテンツを暗号化／復号する。データページをメディアに書き込むのが望ましくない場合もあり、その場合は、ファームウェアが、書き込み前にコマンドを処理し、命令ページをメディアだけに書き込んで、ユーザーがそれを読み取り、オペレーションの状態を理解できるようにする。
【０１４５】
図１８Ｂ−Ｆは、実際のコマンドが送られる前に、メディアカードがＡＰＩプロトコルをサポートしているか否かに関して検査するのに用いられるＡＰＩプロトコルのサポートに関する問合せの様な、メディア特定問合せコマンドの幾つかの例を提供している。具体的な手順は、図１８Ｂと図１８Ｃに示されている。メディアにアクセスするのにファイルシステムが用いられる場合、ファイルは、１つの命令ページだけのコンテンツを有するように書き込まれる。図１８Ｂと図１８Ｃの例は、ファイルシステムを通して、どの様にプロトコルに問合せるかを例証している。
【０１４６】
呼び出し環境はファイル、例えば「ｍｙＡＰＩ．ｂｉｎ」を開く。プロトコルのサポートを問合せるために、発呼者は、図１８Ｂに示している５１２バイトをファイルに書き込み、書き込みファイルコマンドを発行する。書き込みファイルコマンドを発行した後で、メディアは、ファイルをメディアに書き込む間又はそれを読み取る間のどちらであっても適切な動作をする。例えば、メディアカードは、書き込む前に命令ページを処理すると仮定する。この場合、以下の動作が行われることになり、即ち、
ａ）シグネチャーバイトを検証する
ｂ）合致すれば、ＡＰＩシグネチャーを検証する
ｃ）合致すれば、メディア特定フラグがあればそれを通過する
ｄ）１であるメディアカード問合せコマンド要求を検査する
ｅ）データ転送が無いときは、データフィールドと方向フィールドが０であることを検証する。
ｆ）コマンドを処理し、フィールドを更新し、メディアにファイルを書き込む。
ユーザーがメディアからファイル、ｍｙＡＰＩ．ファイルを読み取ると、発呼者は、２つのフィールドを検査しなければならず、即ち：（１）ファームウェア作動状態：コマンドオペレーションが成功裏に完了していれば、このフィールドは、ＡＰＩ＿ＯＰ＿ＳＵＣＣＥＳＳで更新され、失敗していれば、或るエラー値で更新される、（２）メディアカード問合せコマンド戻し状態は、コマンドオペレーションが成功裏に完了したときにだけ検査されることになる。プロトコルがサポートされていれば、フィールドは１で更新され、サポートされていなければ０で更新される。図１８Ｃを参照のこと。
プロトコルがサポートされていなければ、又はカードがこのプロトコルサポートに対して使用不能になっていれば、これら２つの更新可能なフィールドは、最初のデフォルト値０ｘＦＦＦＦＦＦＦＦを維持することになる。
【０１４７】
メディア特定問合せコマンドの第２例は、どの暗号化／復号アルゴリズムがサポートされているかを判定するための問合せであり、この問合せ前に、ＡＰＩプロトコルがサポートされているか否か、および稼働中であるか否か、メディアカードを検査しなければならない。これは、図１８Ｄと図１８Ｅを使って示されている。図１８Ｂと図１８Ｃに関して論じたＡＰＩプロトコルのサポートに関する問合せと同様に、ファイル型式システムを使ってメディアにアクセスするときには、１つの命令ページだけのコンテンツを有するファイルが書き込まれることになる。呼び出し環境はファイル、例えば以前と同じ例を使用するとｍｙＡＰＩ．ｂｉｎ、を書き込むことになる。
【０１４８】
呼び出し環境はファイル、例えばｍｙＡＰＩ．ｂｉｎを書き込むことになる。このコマンドのサポートについて問合せるために、ユーザーは、図１８Ｄに示している５１２バイトを組み込んで、書き込みファイルコマンドを発行することになる。メディアカードは書き込む前に命令ページを処理すると仮定すると、代表的な動作のセットは以下の通りで、
ａ）シグネチャーバイトを検証する
ｂ）合致すれば、ＡＰＩシグネチャーを検証する
ｃ）合致すれば、メディア特定フラグがあれば、それを通過する
ｄ）メディアカード問合せコマンド要求、それは２である、を検査する
ｅ）データ転送が無いときは、データフィールドと方向フィールドが０であることを検証する。
ｆ）コマンドを処理し、フィールドを更新し、メディアにファイルを書き込む。
ユーザーがメディアからファイル、ｍｙＡＰＩ．ｂｉｎを読み取ると、発呼者は、２つのフィールドを検査することになり、即ち：（１）ファームウェア作動状態：コマンドオペレーションが成功裏に完了していれば、このフィールドは、ＡＰＩ ＯＰ ＳＵＣＣＥＳＳで更新され、失敗していれば、或るエラー値で更新される、（２）メディアカード問合せコマンド戻し状態は、コマンドオペレーションが成功裏に完了したときにだけ検査されることになる。このフィールドは、３２ビットの整数を戻し、０は、何らの暗号化／復号アルゴリズムもサポートされていないことを意味する。そうでなければ、各所定の暗号化／復号アルゴリズム毎に各ビットが設定されることになる。例えば、ＤＥＳがビット１、３ＤＥＳがビット３、ＡＥＳがビット３２にあるとすれば、戻し値は、
ＭＳＢ １０００００００ ００００００００ ００００００００ ００００１０１０ ＬＳＢ となる。
結果を図１８Ｅに示している。アルゴリズムの最大数は、この代表的な実施形態では３２であることに注目されたい。戻し値に基づいて、サポートされているＥ／Ｄアルゴリズムの型式を判定できるので、同じ所定のアルゴリズム名をバイト３５に設定することによって、命令ページ（バイト３６から開始している）とデータページを暗号化することができる。バイト３５は、何れの所与の時点でも設定される１ビットだけを有することに注目されたい。２ビット以上が設定されれば、それは失敗になる。
【０１４９】
メディア特定問合せコマンドの別の例は、メディアカードがＡＰＩプロトコルをサポートしているか否かを判定するための問い合わせであり、サポートしていれば、それを使用不能にする。どの暗号化／復号アルゴリズムがサポートされているかを判定するための問合せと同様に、ファイルが開かれ、このファイルのコンテンツは１つの命令ページだけを有することになる。呼び出し環境はファイル、例えばここでもｍｙＡＰＩ．ｂｉｎ、を開くことになる。このコマンドのサポートについて問合せるために、ユーザーは、図１８Ｆに示されている５１２バイトをファイルに組み込んで、書き込みファイルコマンドを発行することができる。
【０１５０】
ファイルを書き込んだ後、ユーザーは、フィールドを読み取り、先ず、（１）ファームウェア作動状態を検査することによって、オペレーションが成功裏に完了しているか否かを検証し、コマンドオペレーションが成功裏に完了していれば、このフィールドは０で更新され、失敗していれば１で更新され、（２）メディアカード問合せコマンド戻し状態は、コマンドオペレーションが成功裏に完了しているときにだけ検査される。プロトコルが使用不能であれば１になり、失敗の場合は０になる。
【０１５１】
図１８Ｇと図１８Ｈは、ファイルシステムベースのメディア特定読み取り及び書き込みコマンドの具体的な例を示している。ファームウェアコマンドをメディアカードに発行する前に、カードは、それがＡＰＩプロトコルをサポートしているか否かを調べるために検査される。先のプロトコルと同様に、メディアにアクセスするのにファイルシステムが用いられる場合は、ファイルは、１つ又は複数の命令ページとあらゆる関係付けられたデータのページのコンテンツによって開かれる。メディア特定書き込みコマンドの例を図１８Ｇに示している。
【０１５２】
より具体的には、発呼者がコマンド（例えば、ＳＤカードコマンドセットの「Ｄ５」）を発行して、データページを取り、それを隠されている領域に書き込みたいと思っているとしよう。呼び出し環境がファイルを開き、ユーザーは、図１８Ｇに示しているデータページを準備することになる。バイト００−３４は、図１８Ａ−図１８Ｆに示している通りで、この例の命令のバイト３５は、暗号化が使用されていないことを示している。バイト３６−３９は、ここでも、ファームウェアの作動状態を示しており、イタリック体（ここ及び前の両方）は、フィールドが更新可能なファームウェアであることを示しており、ベンダ又はメディア識別子（本例は、ベンダ識別子を「ＳＮＤＫ」として使用する）がバイト４０−４３内で続いている。埋め込まれたコマンドは、このメディア／ベンダに特定のものである。バイト４４−５０は、ここでは示されているページ（ＮＩＰ＝１）だけの命令ページ数、本例ではこれも１（ＮＤＰ＝１）のデータページ数、及びバイト数として、ここでは１セクターの５１２バイト（ＤＳＩＢ＝５１２）とされている、指定されているデータサイズ、を示している。命令のバイト５１−６８は、特定のコマンドに必要な、先に述べた命令情報を提供する。
【０１５３】
実際の埋め込まれているコマンドは、（バイトでの）長さがバイト６９−７０に指定されており、この場合は、１つのバイト７１であり、そこに予約されているか、又は安全な領域への書き込みを示す代表的な「Ｄ５」命令が含まれている。メディア特定命令に割り当てられる残りの領域（バイト７２−５１１）は、完全なセクターにするためにゼロを詰められている。実際の特定のコマンド用のデータの（ここでの）５１２バイトは、次のセクターに続いている。
【０１５４】
図１８Ｇでは、データフィールド（ＤＡＴＡ＝１）は、この命令に「入力」が入っており、方向フィールド（方向＝００）が、ファームウェアに、データを処理してページをメディアに書き込むことを告げていることに注目されたい。ファイルシステムは、データページをメディアに書き込むので（ファイルシステムで見ると１０２４バイト、最初の５１２は埋め込まれたコマンド用）、ファームウェアは、必要に応じて、データページに０又はＦＦを詰める。
【０１５５】
発呼者は、メディアカードからファイルを読み取り、ファームウェア作動状態フィールドを検査することによって、オペレーションが成功したか否かを検証する。オペレーションが成功裏に完了していれば、このフィールドは、ＡＰＩ ＯＰ ＳＵＣＣＥＳＳで更新され、成功していなければ、或るエラー値又はＡＰＩ ＯＰ ＮＯ ＳＵＣＣＥＳＳで更新される。方向が００だったので、データページは０又はＦＦとなることに注目されたい。
【０１５６】
メディアカードは書き込む前に命令ページを処理すると仮定すると、代表的な動作のセットは以下の通りで、
ａ）シグネチャーバイトを検証する
ｂ）シグネチャーが合致すれば、ＡＰＩシグネチャーを検証する
ｃ）命令ページ（バイト３６から）が暗号化されているか否か検査する
ｄ）暗号化されていれば、命令ページ（バイト３６から）とデータページを復号する
ｅ）ベンダＩＤシグネチャーを検証する。
ｆ）ベンダＩＤが合致すれば、メディア特定フラグ（もしあれば）を通過する
ｇ）方向とデータフィールドを検査する
ｈ）実際の埋め込まれているメディア特定コマンドを処理する
ｉ）命令ページのファームウェア作動状態フィールドを更新し、（要求されれば）バイト３６の後の命令ページを暗号化し、それをメディアに書き込む。方向が００なので、必要に応じてデータページを０又はＦＦと書き込む。
【０１５７】
メディア特定読み取りコマンドは、数多くの方法で実施することができ、その内の幾つかについて、以下のセクションで更に論じる。ファイルシステムベースのメディア特定読み取りコマンドの実施は、構造が図１８Ｇの書き込み構造と似ているが、ここで図１８Ｈに関して説明する。
【０１５８】
メディアから読み取れる様に、メディア特定コマンドはＤ６で、方向は１０である。更に、用いられているコマンド及び確立されているプロトコルに基づいて、コンテンツを修正する柔軟性がある。例えば、カードには、このファイルを書き込むよう告げることができ、ファイルは、書き込む前にコンテンツを暗号化するようファームウェアに告げる特別なコマンドを有している。従って、書き込まれたコンテンツは、書き込まれる前に、他の形態に変換してもよい。同じことを読み取りオペレーションにも適用することができる。
【０１５９】
図１８Ｈは、発呼者がコマンド（例えば、ＳＤカードコマンドセットの「Ｄ６」）を発行し、隠されている領域からのデータセクターを読み取り、それをデータページの下に置きたいと思っている場合を示している。呼び出し環境はファイルを開くことになり、ユーザーは、図１８Ｈに示しているようなデータページを準備し、ベンダ識別子は、ここでも「ＳＮＤＫ」とされている。
【０１６０】
データフィールドは、これが「出力」であると表示するので、データページは更新され、方向フィールドは、ファームウェアに、読み取り中にデータを処理するよう告げる。ファームウェアにとってもう１つの可能性は、コマンドを処理し、データページを更新し、それをメディアに書き込むことである。従って、ファームウェアは、１０２４バイトをメディアに書き込む。ファームウェアは、ファイルを読み取ると、これが命令ページであることを検出し、次に、コマンドを読み取り、データフィールドを適切に更新する。発呼者は、メディアカードからファイルを読み取ることによって、オペレーションが成功したか否かを検証する。ファイルが読み取られると、発呼者は、ファームウェア作動状態のフィールドを検査することができる。コマンドが成功裏に完了したオペレーションになっていれば、このフィールドは、ＡＰＩ ＯＰ ＳＵＣＣＥＳＳで更新され、成功していなければ、ＡＰＩ ＯＰ ＮＯ ＳＵＣＣＥＳＳの様な或るエラー値で更新される。読み取られたデータの量も、ＤＳＩＢフィールドを検査し、それが５１２に更新されているか否かを調べることによって検証することができる。
【０１６１】
以上、本発明の様々な態様について、具体的な実施形態について述べてきたが、本発明は、特許請求の範囲に述べる全ての範囲内で保護されるものと理解されたい。
【図面の簡単な説明】
【０１６２】
【図１】ホストカードシステムの層の概略図である。
【図２】ホストカードシステムのブロック図である。
【図３】カードが、リーダー又はハードウェアアダプターを使って別のホストと通信するシステムのブロック図である。
【図４】図３のシステムでデータ及びコマンドを転送するための先行技術の技法の概略図である。
【図５】本発明の代表的な実施形態による、アプリケーション特定コマンドがどの様に埋め込まれるかを示している。
【図６】ファームウェア層の関係に関する代表的な構造を示すブロック図である。
【図７】デバイスのドライバ層の概略図である。
【図８】パーティション状態コマンドへの応答に含まれている情報を示している。
【図９】引数データセクターの代表的なフォーマットを示している。
【図１０Ａ】ホスト側の通信の流れを示している。
【図１０Ｂ】ホスト側の通信の流れを示している。
【図１１Ａ】ホストアプリケーション−デバイスアプリケーションプロトコルを示している。
【図１１Ｂ】ホストアプリケーション−デバイスアプリケーションプロトコルを示している。
【図１１Ｃ】ホストアプリケーション−デバイスアプリケーションプロトコルを示している。
【図１２】隠しパーティションアプリケーションのコマンドの状態マシン図である。
【図１３Ａ】隠しパーティションプロトコルの一組のコマンドのプロセスの流れを示している。
【図１３Ｂ】隠しパーティションプロトコルの一組のコマンドのプロセスの流れを示している。
【図１３Ｃ】隠しパーティションプロトコルの一組のコマンドのプロセスの流れを示している。
【図１３Ｄ】隠しパーティションプロトコルの一組のコマンドのプロセスの流れを示している。
【図１４】図４の簡素化バージョンである。
【図１５】本発明の態様による、図３のシステムでデータとコマンドを転送するための技法の概略図である。
【図１６】特定の実施形態による、図１５の詳細を示す。
【図１７Ａ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｂ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｃ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｄ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｅ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｆ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｇ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｈ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｉ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｊ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｋ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１７Ｌ】多数のコマンドに対する、図１６の実施形態の構造の詳細を示す。
【図１８Ａ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｂ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｃ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｄ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｅ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｆ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｇ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。
【図１８Ｈ】ファイルレベルの実施形態に関する、図１７Ａ−図１７Ｌと同様の図である。

【特許請求の範囲】
【請求項１】
メモリカードと、データ及びコマンドを前記カードと交換することのできるホストと、を備えているシステムを作動させる方法であって、前記ホストと前記カードの間のデータ及びコマンドの交換は、第１プロトコルの第１コマンドセットを前記伝送プロセスの或る段階で使用し、前記ホストと前記カードは、第２プロトコルの第２コマンドセットを使用するアプリケーションを含み、前記方法は、
第１プロトコルからの第１命令に、前記第１コマンドセット内に対応するコマンドがない、前記第２コマンドセットからのコマンドを埋め込む段階と、
前記第１命令を前記ホストから前記メモリカードに伝送する段階と、
前記カード内で前記埋め込まれたコマンドを抽出する段階と、
を含む方法。
【請求項２】
第２プロトコルの第２コマンドセットを使用する前記アプリケーションは、複数のアプリケーションの中の１つであり、且つ、前記第２プロトコルは、複数の対応する第２プロトコルの中の特定の１つであり、前記複数のアプリケーションの中の複数のアプリケーションは同時に作動させることができる、請求項１に記載の方法。
【請求項３】
前記埋め込む段階は、前記ホストによって、前記ファイルシステムレベルで実施される、請求項１に記載の方法。
【請求項４】
前記コマンドは、データを、前記ホストから前記カードに転送するためのものであり、前記データは、前記第１命令に対応するファイルのデータ部分に置かれ、前記方法は、更に、前記ファイルをセグメント化して保持するのに十分な前記カード上の論理アドレスを判定する段階を更に含んでいる、請求項３に記載の方法。
【請求項５】
前記コマンドが、前記カードから前記ホストにデータを転送するためのものであるか否かを判定する段階と、
前記コマンドが、前記カードから前記ホストにデータを転送するためのものであるという判定を受けて、前記転送用のフラグを設定する段階と、
前記カードから、前記コマンドに関係付けられたデータを転送する段階と、
を更に含んでいる、請求項１に記載の方法。
【請求項６】
前記転送されたデータは、前記コマンドに関係付けられた前記データの全てよりも少ない、請求項５に記載の方法。
【請求項７】
第２コマンドに応答して、前記カードから、前記コマンドに関係付けられた前記データを再転送する段階を更に含んでいる、請求項５に記載の方法。
【請求項８】
前記埋め込む段階は、前記ホストによって、カードドライバレベルで実施される、請求項１に記載の方法。
【請求項９】
前記システムは、ハードウェアアダプターを更に備え、それを通して前記ホストとカードが前記データとコマンドを交換するようになっており、前記ホストとハードウェアアダプターは、前記第１プロトコルによって通信し、前記第１命令を前記ホストから前記メモリカードに伝送する前記段階が、
前記第１命令を前記ホストから前記ハードウェアアダプターに伝送する段階と、
前記ハードウェアアダプター内で、前記第１命令を、前記第２プロトコルの対応する命令に翻訳する段階と、
前記対応する命令を、前記ハードウェアアダプターから前記メモリカードに伝送する段階と、
を含んでいる、請求項１に記載の方法。
【請求項１０】
前記第１プロトコルからの前記命令が、前記第１プロトコルからのコマンドとデータ部分を含んでいるコマンド部分を有し、前記埋め込まれているコマンドは、前記データ部分に埋め込まれている、請求項１に記載の方法。
【請求項１１】
前記データ部分は、前記埋め込まれているコマンドに関係付けられたデータを更に含んでいる、請求項１０に記載の方法。
【請求項１２】
前記方法は、前記データ部分に含まれている、前記埋め込まれているコマンドに関係付けられたデータが、前記埋め込まれているコマンドに関係付けられたデータの全てであるか否かを判定する段階を更に含んでいる、請求項１１に記載の方法。
【請求項１３】
前記方法は、前記データ部分に含まれている、前記埋め込まれているコマンドに関係付けられた前記データが、前記埋め込まれているコマンドに関係付けられた前記データの全てではないとする判定を受けて、フラグを、前記埋め込まれているコマンドに関係付けられた追加データを受け取るための設定状態のままに残しておく段階を更に含んでいる、請求項１２に記載の方法。
【請求項１４】
前記カードで、前記埋め込まれているコマンドを抽出する前記段階は、
前記データ部分がシグネチャーを含んでいることを判定する段階と、
前記命令内の前記シグネチャーの確認に応じて、前記埋め込まれているコマンドを前記データ部分から抽出する段階と、を含んでいる、請求項１０に記載の方法。
【請求項１５】
前記対応する命令は、前記第２プロトコルからのコマンドを含んでいるコマンド部分と、データ部分と、を有しており、前記埋め込まれているコマンドは、前記データ部分に埋め込まれている、請求項１０に記載の方法。
【請求項１６】
前記第１プロトコルからの前記コマンドは、所定の論理アドレスへのものである、請求項１に記載の方法。
【請求項１７】
前記伝送された、前記カード内の対応する命令を受け取った後で、前記カード内で前記埋め込まれているコマンドを抽出する前に、
前記対応するコマンドが前記所定の論理アドレスへのものであることを判定する段階と、
前記対応するコマンドが前記所定の論理アドレスへのものであるとする判定に対応して、前記命令内のシグネチャーを確認する段階であって、前記埋め込まれているコマンドは、前記シグネチャーの確認に対応して抽出される、確認する段階と、を更に含んでいる、請求項１６に記載の方法。
【請求項１８】
前記対応するコマンドが前記所定の論理アドレスへのものであることを判定する前記段階と、前記命令内のシグネチャーを確認する前記段階と、前記埋め込まれているコマンドを抽出する段階は、前記カードのファームウェアによって実行される、請求項１７に記載の方法。
【請求項１９】
前記埋め込まれているコマンドを実行する段階を更に含んでいる、請求項１に記載の方法。
【請求項２０】
前記第２プロトコルはＳＤプロトコルである、請求項１に記載の方法。
【請求項２１】
前記埋め込まれているコマンドは、安全なデータアクセスである、請求項２０に記載の方法。
【請求項２２】
前記第２プロトコルは、ＭＭＣプロトコルである、請求項１に記載の方法。
【請求項２３】
前記第２プロトコルは、ＡＴＡプロトコルである、請求項１に記載の方法。
【請求項２４】
前記第１プロトコルは、ＳＣＳＩプロトコルである、請求項１に記載の方法。
【請求項２５】
前記コマンドは、前記ホストと前記カードの間でデータを転送するためのものであり、前記データは、前記ホスト内にキャッシュされていない、請求項１に記載の方法。
【請求項２６】
メモリカードと、データ及びコマンドを前記カードと交換することができるホストと、を備えているシステムを作動させる方法であって、前記ホストと前記カードの間のデータ及びコマンドの交換は、第１プロトコルの第１コマンドセットを伝送プロセスの或る段階で使用し、前記ホストと前記カードは、第２プロトコルの第２コマンドセットを使用するアプリケーションを含み、前記方法は、
前記第１プロトコルからの第１命令に、前記第２コマンドセットからのコマンドと、シグネチャーを埋め込む段階であって、前記第１命令は、コマンド部分とデータ部分を含んでおり、前記シグネチャーと、前記第２コマンドセットからの前記コマンドは、前記データ部分に埋め込まれている、埋め込む段階と、
前記ホストからの前記第１命令を前記メモリカードに伝送する段階と、
前記第１命令の前記データ部分に前記シグネチャーが入っているか否か判定する段階と、
前記第１命令に前記シグネチャーが入っていること対応して、前記第２コマンドセットからの前記コマンドを、前記第１命令の前記データ部分から抽出する段階と、を含んでいる方法。
【請求項２７】
第２プロトコルの第２コマンドセットを使用する前記アプリケーションは、複数のアプリケーションの中の１つであり、且つ、前記第２プロトコルは、複数の対応する第２プロトコルの中の特定の１つであり、前記複数のアプリケーションの中の複数のアプリケーションは、同時に作動させることができる、請求項２６に記載の方法。
【請求項２８】
前記データ部分は、更に、前記第２コマンドセットからの前記コマンドに関係付けられたデータを含んでいる、請求項２６に記載の方法。
【請求項２９】
前記方法は、前記データ部分に含まれている、前記第２コマンドセットからの前記コマンドに関係付けられた前記データが、前記第２コマンドセットからの前記コマンドに関係付けられた前記データの全てであるか否かを判定する段階を更に含んでいる、請求項２８に記載の方法。
【請求項３０】
前記方法は、前記データ部分に含まれている、前記第２コマンドセットからの前記コマンドに関係付けられた前記データが、前記第２コマンドセットからの前記コマンドに関係付けられた前記データの全てではないとする判定を受けて、フラグを、前記第２コマンドセットからの前記コマンドに関係付けられた追加データを受け取るための設定状態のままに残しておく段階を更に含んでいる、請求項４に記載の方法。
【請求項３１】
前記コマンドは、データを前記カードから前記ホストへ転送するためのものであるか否かを判定する段階と、
前記コマンドが、データを前記カードから前記ホストへ転送するためものであるとする判定を受けて、前記転送用にフラグを設定する段階と、
前記カードから、前記コマンドに関係付けられたデータを転送する段階と、を更に含んでいる、請求項２６に記載の方法。
【請求項３２】
前記転送されたデータは、前記コマンドに関係付けられた前記データの全てよりも少ない、請求項３１に記載の方法。
【請求項３３】
第２コマンドに応答して、前記カードから、前記コマンドに関係付けられた前記データを再転送する段階を更に含んでいる、請求項３１に記載の方法。
【請求項３４】
前記第１命令は書き込みである、請求項２６に記載の方法。
【請求項３５】
前記第２コマンドセットからの前記コマンドは、読み取りである、請求項２６に記載の方法。
【請求項３６】
前記シグネチャーは、前記データ部分の所定のセクションに入っている、請求項２６に記載の方法。
【請求項３７】
前記命令は、第１論理アドレスでデータにアクセスするためのものであり、前記命令の前記データ部分にシグネチャーが入っているか否かを判定する前記段階は、所定の論理アドレスに対応している前記第１論理アドレスに応じるものである、請求項２６に記載の方法。
【請求項３８】
前記埋め込む段階は、前記ホストによって、前記ファイルドライバレベルで実施される、請求項２６に記載の方法。
【請求項３９】
前記コマンドは、データを、前記ホストから前記カードに転送するためのものであり、前記データは、前記第１命令に対応するファイルのデータ部分に置かれており、前記方法は、更に、前記カード上の論理アドレスが前記ファイルをセグメント化して保持するのに十分であるかを判定する段階を含んでいる、請求項３８に記載の方法。
【請求項４０】
前記埋め込む段階は、前記ホストによって、前記カードドライバレベルで実施される、請求項２６に記載の方法。
【請求項４１】
前記システムは、ハードウェアアダプターを更に備え、前記ハードウェアアダプターを通して前記ホストとカードが前記データとコマンドを交換し、前記ホストとハードウェアアダプターは、前記第１プロトコルによって通信し、前記第１命令を前記ホストから前記メモリカードに伝送する前記段階は、
前記第１命令を前記ホストから前記ハードウェアアダプターに伝送する段階と、
前記ハードウェアアダプター内で、前記第１命令を、前記第２プロトコルの対応する命令に翻訳する段階と、
前記対応する命令を、前記ハードウェアアダプターから前記メモリカードに伝送する段階と、を含んでいる、請求項２６に記載の方法。
【請求項４２】
前記第１プロトコルからの前記命令は、前記第１プロトコルからのコマンドを含んでいるコマンド部分と、データ部分と、を備えており、前記埋め込まれているコマンドは、前記データ部分に埋め込まれている、請求項２６に記載の方法。
【請求項４３】
前記第１プロトコルからの前記コマンドは、所定の論理アドレスへのものである、請求項２６に記載の方法。
【請求項４４】
前記埋め込まれているコマンドを実行する段階を更に含んでいる、請求項２６に記載の方法。
【請求項４５】
前記第２プロトコルはＳＤプロトコルである、請求項２６に記載の方法。
【請求項４６】
前記埋め込まれているコマンドは安全なデータアクセスである、請求項４５に記載の方法。
【請求項４７】
前記第２プロトコルはＭＭＣプロトコルである、請求項２６に記載の方法。
【請求項４８】
前記第２プロトコルはＡＴＡプロトコルである、請求項２６に記載の方法。
【請求項４９】
前記第１プロトコルはＳＣＳＩプロトコルである、請求項２６に記載の方法。
【請求項５０】
前記コマンドは、前記ホストと前記カードの間でデータを転送するためのものであり、前記データは、前記ホスト内にキャッシュされない、請求項２６に記載の方法。
【請求項５１】
不揮発性メモリカードを作動させる方法において、
コマンド部分とデータ部分を含んでいる、命令を受け取る段階と、
前記命令の前記データ部分にシグネチャーが入っているか否かを判定する段階と、
前記命令に前記シグネチャーが入っていることに対応して、前記命令の前記データ部分からコマンドを抽出する段階と、を含む方法。
【請求項５２】
前記コマンドは、前記カードからデータを転送するためのものであるか否かを判定する段階と、
前記コマンドが前記カードからデータを転送するためのものであるという判定に対応して、前記転送用のフラグを設定する段階と、
前記カードから、前記コマンドに関係付けられたデータを転送する段階と、を更に含んでいる、請求項５１に記載の方法。
【請求項５３】
第２コマンドに応えて、前記カードから前記コマンドに関係付けられた前記データを再転送する段階を更に含んでいる、請求項５２に記載の方法。
【請求項５４】
前記データ部分は、前記抽出されたコマンドに関係付けられたデータを更に含んでいる、請求項５１に記載の方法。
【請求項５５】
前記方法は、前記データ部分に含まれている、前記抽出されたコマンドに関係付けられた前記データが、前記抽出されたコマンドに関係付けられた前記データの全てであるか否かを判定する段階を更に含んでいる、請求項５４に記載の方法。
【請求項５６】
前記方法は、前記データ部分に含まれている、前記抽出されたコマンドに関係付けられた前記データが、前記抽出されたコマンドに関係付けられた前記データの全てではないという判定に対応して、フラグを、前記抽出されたコマンドに関係付けられた追加データの受け取りのための設定状態のままに残しておく段階を更に含んでいる、請求項５５に記載の方法。
【請求項５７】
前記シグネチャーが、前記データ部分の所定のセクションに入っている、請求項５１に記載の方法。
【請求項５８】
前記命令は、第１コマンドセットを有する第１プロトコル内にあり、前記抽出されたコマンドは、第２プロトコルの第２コマンドセットからであり、前記第１コマンドセット内に対応するコマンドを有していない、請求項５１に記載の方法。
【請求項５９】
前記第２プロトコルは、複数のアプリケーションの中の１つのためのものであり、前記第２プロトコルは、複数の対応するアプリケーションプロトコルの中の特定の１つであり、前記複数のアプリケーションの中の複数のアプリケーションは、同時に作動させることができる、請求項５８に記載の方法。
【請求項６０】
前記命令は、第１論理アドレスでデータにアクセスするためのものであり、前記命令の前記データ部分にシグネチャーが入っているか否かを判定する前記段階は、所定の論理アドレスに対応している前記第１論理アドレスに応じるものである、請求項５１に記載の方法。
【請求項６１】
前記命令にシグネチャーが入っていると判定する前記段階と、前記命令の前記データ部分からコマンドを抽出する段階は、前記カードのファームウェアによって実行される、請求項５１に記載の方法。
【請求項６２】
前記抽出されたコマンドを実行する段階を更に含んでいる、請求項５１に記載の方法。
【請求項６３】
前記命令はＳＤプロトコルにある、請求項５１に記載の方法。
【請求項６４】
前記抽出されたコマンドは安全なデータアクセスである、請求項５１に記載の方法。
【請求項６５】
前記命令はＭＭＣプロトコルにある、請求項５１に記載の方法。
【請求項６６】
前記命令はＡＴＡプロトコルにある、請求項５１に記載の方法。
【請求項６７】
第１プロトコルからのコマンドを伝送する方法において、
第２プロトコルからの、関係付けられたデータ部分を受け入れるコマンドを含んでいる、命令を形成する段階と、
前記命令の前記関係付けられたデータ部分に、前記第１プロトコルからの前記コマンドと、前記命令に前記第１プロトコルからのコマンドが入っていることを示すシグネチャーと、を置く段階と、
前記命令を伝送する段階と、を含む方法。
【請求項６８】
前記第１プロトコルは、複数のアプリケーションの中の１つのためのものであり、前記第１プロトコルは、複数の対応するアプリケーションプロトコルの中の特定の１つであり、前記複数のアプリケーションの中の複数のアプリケーションは、同時に作動させることができる、請求項６７に記載の方法。
【請求項６９】
前記第１プロトコルからの前記コマンドに関係付けられたデータを、前記関係付けられたデータ部分に置く段階を更に含んでいる、請求項６７に記載の方法。
【請求項７０】
前記方法は、前記データ部分に含まれている、前記第１プロトコルからの前記コマンドに関係付けられた前記データが、前記第１プロトコルからの前記コマンドに関係付けられた前記データの全てであるか否かを判定する段階を更に含んでいる、請求項６９に記載の方法。
【請求項７１】
前記方法は、前記データ部分に含まれている、前記第１プロトコルからの前記コマンドに関係付けられた前記データが、前記第１プロトコルからの前記コマンドに関係付けられた前記データの全てではないという判定に対応して、フラグを、前記第１プロトコルからのコマンドに関係付けられた追加データの受け取りのための設定状態のままに残しておく段階を更に含んでいる、請求項７０に記載の方法。
【請求項７２】
前記第２プロトコルからの前記命令は、書き込みである、請求項６７に記載の方法。
【請求項７３】
前記第１プロトコルからの前記コマンドは、読み取りである、請求項６７に記載の方法。
【請求項７４】
前記シグネチャーは、前記関係付けられたデータ部分の所定のセクションに置かれている、請求項６７に記載の方法。
【請求項７５】
前記埋め込む段階は、前記ホストによって、前記ファイルドライバレベルで実施される、請求項６７に記載の方法。
【請求項７６】
前記関係付けられたデータ部分は、ファイルの一部として形成される、請求項６７に記載の方法。
【請求項７７】
前記第２プロトコルからの前記命令は、所定の論理アドレスに伝送される、請求項６７に記載の方法。
【請求項７８】
前記第１プロトコルからの前記コマンドは、データを転送するためのものであり、前記データは、前記伝送装置内にキャッシュされない、請求項６７に記載の方法。
【請求項７９】
メモリカードと、データ及びコマンドを前記カードと交換することのできるホストと、を備えているシステムを作動させる方法であって、前記ホストと前記カードの間のデータ及びコマンドの交換は、第１プロトコルの第１コマンドセットを前記伝送プロセスの或る段階で使用し、前記ホストと前記カードは、第２プロトコルの第２コマンドセットを使用するアプリケーションを含み前記方法は、
第１プロトコルからの第１命令に、前記第２コマンドセットからのコマンドを埋め込む段階と、
前記第１命令を前記ホストから前記メモリカードの第１論理アドレスに伝送する段階と、
前記埋め込まれているコマンドが、データを前記カードから前記ホストへ転送するためのものであるか否かを判定する段階と、
その後、第２命令を前記ホストから前記メモリカードに伝送する段階と、
前記埋め込まれているコマンドが、データを前記カードから前記ホストへ転送するためのものであるという判定に応えて、前記第２命令が、前記メモリカードの前記第１論理アドレスへのものであるか否かを判定する段階と、
前記第２命令が、前記メモリカードの前記第１論理アドレスへのものであるということに対応して、データを前記カードから前記ホストへ転送する段階と、を含む方法。
【請求項８０】
前記第１命令は、書き込みである、請求項７９に記載の方法。
【請求項８１】
前記第２命令からの前記コマンドは、読み取りである、請求項７９に記載の方法。
【請求項８２】
前記シグネチャーは、前記第１命令の所定のセクションに入っている、請求項７９に記載の方法。
【請求項８３】
前記埋め込む段階は、前記ホストによって、前記ファイルドライバレベルで実施される、請求項７９に記載の方法。
【請求項８４】
前記コマンドは、前記ホストと前記カードの間でデータを転送するためのものであり、前記データは、前記ホスト内にキャッシュされていない、請求項７９に記載の方法。
【請求項８５】
不揮発性メモリと、
第１プロトコルに従って前記カードが接続されているホストと命令を交換するためのフロント層であって、前記第１層は、前記第１プロトコルの入ってくる命令のデータ部分にシグネチャーが入っているか否かを判定し、前記シグネチャーが無いとする判定に対応して、前記第１プロトコルの前記命令に従って前記メモリにアクセスする、フロント層と、
アプリケーション層であって、前記第１プロトコルの入ってくる命令にシグネチャーが入っているとする判定に対応して、前記入ってくる命令は、前記フロント層から前記アプリケーションへ転送され、第２プロトコルの命令が、前記入ってくる命令の前記データ部分から抽出され、前記第２プロトコルの前記命令に従って前記メモリにアクセスする、アプリケーション層と、を備えているメモリカード構造。
【請求項８６】
前記シグネチャーは、前記データ部分の所定のセクションに入っている、請求項８５に記載のメモリカード構造。
【請求項８７】
前記命令は、第１コマンドセットを有する第１プロトコルにあり、前記抽出されたコマンドは、第２プロトコルの第２コマンドセットからであり、前記第１コマンドセット内に対応するコマンドを有していない、請求項８５に記載のメモリカード構造。
【請求項８８】
前記命令は、第１論理アドレスでデータにアクセスするためのものであり、前記命令の前記データ部分にシグネチャーが入っているか否かの前記判定は、所定の論理アドレスに対応している前記第１論理アドレスに応じるものである、請求項８５に記載のメモリカード構造。
【請求項８９】
前記フロント層と前記アプリケーション層は、ファームウェアで実施される、請求項８５に記載のメモリカード構造。
【請求項９０】
前記メモリカード構造は、複数の前記命令を同時に処理することができる、請求項８５に記載のメモリカード構造。
【請求項９１】
前記アプリケーション層は、複数のアプリケーションを含んでおり、同時に処理される前記複数の命令は、前記アプリケーションの内の２つ以上からのものである、請求項９０に記載のメモリカード構造。
【請求項９２】
前記入ってくる命令が、前記カードからデータを転送するためのものであるという判定に対応して、前記アプリケーション層は、転送フラグを設定し、前記入ってくる命令に関係付けられたデータを、前記カードから転送する、請求項８５に記載のメモリカード構造。
【請求項９３】
２番目に入ってくる命令に対応して、前記入ってくる命令に関係付けられた前記データを、前記カードから再転送する、請求項９２に記載のメモリカード構造。
【請求項９４】
前記アプリケーション層は、前記データ部分が、前記第２プロトコルの前記命令に関係付けられたデータを更に含んでいるか否かを判定する、請求項８５に記載のメモリカード構造。
【請求項９５】
前記アプリケーション層は、前記データ部分に含まれている、前記第２プロトコルの前記命令に関係付けられた前記データが、前記第２プロトコルの前記命令に関係付けられたデータの全てであるか否かを判定する、請求項９４に記載メモリカード構造。
【請求項９６】
前記データ部分に含まれている、前記第２プロトコルの前記命令に関係付けられた前記データが、前記第２プロトコルの前記命令に関係付けられたデータの全てではないという判定に対応して、前記アプリケーション層は、フラグを、前記第２プロトコルの前記命令に関係付けられた追加データの前記受け取りのために設定された状態のままに残しておく、請求項９５に記載のメモリカード構造。
【請求項９７】
前記転送されたデータは、前記コマンドに関係付けられた前記データの全てよりも少ない、請求項５１に記載の方法。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０Ａ】

【図１０Ｂ】

【図１１Ａ】

【図１１Ｂ】

【図１１Ｃ】

【図１２】

【図１３Ａ】

【図１３Ｂ】

【図１３Ｃ】

【図１３Ｄ】

【図１４】

【図１５】

【図１６】

【図１７Ａ】

【図１７Ｂ】

【図１７Ｃ】

【図１７Ｄ】

【図１７Ｅ】

【図１７Ｆ】

【図１７Ｇ】

【図１７Ｈ】

【図１７Ｉ】

【図１７Ｊ】

【図１７Ｋ】

【図１７Ｌ】

【図１８Ａ】

【図１８Ｂ】

【図１８Ｃ】

【図１８Ｄ】

【図１８Ｅ】

【図１８Ｆ】

【図１８Ｇ】

【図１８Ｈ】

【公表番号】特表２００９−５１８７５９（Ｐ２００９−５１８７５９Ａ）
【公表日】平成２１年５月７日（２００９．５．７）
【国際特許分類】
【出願番号】特願２００８−５４４６１２（Ｐ２００８−５４４６１２）
【出願日】平成１８年１１月３０日（２００６．１１．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０６１４１６
【国際公開番号】ＷＯ２００７／０７６２１４
【国際公開日】平成１９年７月５日（２００７．７．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．コンパクトフラッシュ
【出願人】（５０７２０８２８８）サンディスク　コーポレーション (11)
【Ｆターム（参考）】