ホストデバイスであって、パブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと連通状態になるように構成されたインターフェイスであって、前記パブリックメモリエリアは前記プライベートメモリエリアに格納されたコンテンツに関連付けられる仮想ファイルを格納するインターフェイスと、キャッシュと、前記キャッシュと連通状態にあるホストアプリケーションと、前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、前記ホストアプリケーションから仮想ファイルのリクエストを受信し、仮想ファイルのリクエストを前記ストレージデバイスに送信し、前記ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、前記コンテンツは前記キャッシュをバイパスすることによって受信され、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはコンテンツを含み、かつ前記レスポンスを前記ホストアプリケーションに送信するように構成されたサーバと、を備えるホストデバイス。請求項1記載のホストデバイスにおいて、オペレーティングシステムをさらに備え、前記サーバは、仮想ファイルのリクエストへのレスポンスを前記ストレージデバイスから受信すると、前記オペレーティングシステムが前記キャッシュをバイパスするように前記オペレーティングシステムに命令を送信するようにさらに構成されるホストデバイス。請求項2記載のホストデバイスにおいて、前記キャッシュをバイパスする命令は、O_DIRECTフラグを含むホストデバイス。請求項1記載のホストデバイスにおいて、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含むホストデバイス。請求項4記載のホストデバイスにおいて、前記HTTPサーバによって受信されるリクエストは、HTTPGetリクエストを含むホストデバイス。請求項4記載のホストデバイスにおいて、前記HTTPサーバは、前記ホストアプリケーションから仮想ファイルのユニバーサルリソースロケータURLを受信し、かつ前記ホストアプリケーションから受信されたURLを前記ストレージデバイスのパブリックメモリエリアにある仮想ファイルのアドレスに書き換えるようにさらに構成されるホストデバイス。請求項1記載のホストデバイスにおいて、前記サーバは、前記コンテンツにアクセスする許可を前記ホストアプリケーションが有するかを決定するようにさらに構成されるホストデバイス。請求項7記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションから受信された識別子に基づいた許可を前記ホストアプリケーションが有するかを決定するようにさらに構成されるホストデバイス。請求項1記載のホストデバイスにおいて、前記サーバは、仮想ファイルを開くために、前記ストレージデバイスのアクセス制御記録にログインするようにさらに構成されるホストデバイス。請求項9記載のホストデバイスにおいて、前記アクセス制御記録には許可制御記録が含まれ、前記サーバは、前記コンテンツを受信する許可を前記ホストデバイスが有していることを前記許可制御記録が示す場合のみ、前記ストレージデバイスのプライベートエリアから仮想ファイルに関連付けられたコンテンツを受信するホストデバイス。請求項1記載のホストデバイスにおいて、前記サーバは、前記ストレージデバイスとのセキュアセッションを確立し、前記プライベートメモリエリアへのストリームを確立し、前記ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するために読み出しストリーム演算を使用し、かつ前記暗号化されたコンテンツを解読するようにさらに構成されるホストデバイス。請求項1記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。請求項12記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションからのリクエストが、ro.secureシステム特性を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定するようにさらに構成されるホストデバイス。請求項12記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションからのリクエストが、ユーザ識別子を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定するようにさらに構成されるホストデバイス。ホストデバイスのキャッシュをバイパスすることによって、ストレージデバイスの仮想ファイルにアクセスする方法であって、ホストデバイスのサーバであって、前記ホストデバイスがパブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと連通状態にあり、前記パブリックメモリエリアは前記プライベートメモリエリアに格納されたコンテンツに関連付けられる仮想ファイルを格納するホストデバイスのサーバにおいて、前記ホストデバイスのホストアプリケーションから仮想ファイルのリクエストを受信し、仮想ファイルのリクエストを前記ストレージデバイスに送信し、前記ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、前記コンテンツは前記ホストデバイスのキャッシュをバイパスすることによって受信され、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはコンテンツを含み、かつ前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。請求項15記載の方法において、前記ホストデバイスは、オペレーティングシステムをさらに備え、前記方法は、仮想ファイルのリクエストへのレスポンスを前記ストレージデバイスから受信すると、前記オペレーティングシステムが前記キャッシュをバイパスするように前記オペレーティングシステムに命令を送信することをさらに含む方法。請求項16記載の方法において、前記キャッシュをバイパスする命令は、O_DIRECTフラグを含む方法。請求項15記載の方法において、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含む方法。請求項18記載の方法において、前記HTTPサーバによって受信されたリクエストは、HTTPGetリクエストを含む方法。請求項18記載の方法において、前記ホストアプリケーションから仮想ファイルのユニバーサルリソースロケータURLを受信し、かつ前記ホストアプリケーションから受信されたURLを前記ストレージデバイスのパブリックメモリエリアにある仮想ファイルのアドレスに書き換えることをさらに含む方法。請求項15記載の方法において、前記コンテンツにアクセスする許可を有するかを前記ホストアプリケーションが決定することをさらに含む方法。請求項21記載の方法において、前記ホストアプリケーションから受信された識別子に基づいた許可を前記ホストアプリケーションが有するかを決定することをさらに含む方法。請求項15記載の方法において、前記仮想ファイルを開くために、前記ストレージデバイスのアクセス制御記録にログインすることをさらに含む方法。請求項23記載の方法において、前記アクセス制御記録には許可制御記録が含まれ、前記方法は、前記コンテンツを受信する許可を前記ホストデバイスが有していることを前記許可制御記録が示す場合のみ、前記ストレージデバイスのプライベートエリアから仮想ファイルに関連付けられたコンテンツを受信することをさらに含む方法。請求項15記載の方法において、前記ストレージデバイスとのセキュアセッションを確立し、前記プライベートメモリエリアへのストリームを確立し、前記ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するために読み出しストリーム演算を使用し、かつ前記暗号化されたコンテンツを解読することをさらに含む方法。請求項15記載の方法において、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信することをさらに含む方法。請求項26記載の方法において、前記ホストアプリケーションからのリクエストが、ro.secureシステム特性を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定することをさらに含む方法。請求項26記載の方法において、前記ホストアプリケーションからのリクエストが、ユーザ識別子を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定することをさらに含む方法。ホストデバイスであって、ストレージデバイスと連通状態になるように構成されたインターフェイスと、ホストアプリケーションと、前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、前記ホストアプリケーションからデータのリクエストを受信し、前記リクエストはホストアプリケーションによって直接アクセス不能なデータ場所を含み、前記ホストアプリケーションから受信された場所を書き換えられた場所に書き換え、前記書き換えられた場所を含むリクエストをデータのストレージデバイスに送信し、前記ストレージデバイスからデータを受信し、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはデータを含み、前記ホストアプリケーションに前記レスポンスを送信するように構成されたサーバと、を備えるホストデバイス。請求項29記載のホストデバイスにおいて、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含むホストデバイス。請求項30記載のホストデバイスにおいて、前記ホストアプリケーションから受信された場所は、ユニバーサルリソース識別子URIを含むホストデバイス。請求項29記載のホストデバイスにおいて、データは、前記ストレージデバイスのプライベートメモリエリアに格納されるホストデバイス。請求項29記載のホストデバイスにおいて、前記サーバは、リクエストを待ち受けるポートを無作為化するようにさらに構成されるホストデバイス。請求項29記載のホストデバイスにおいて、前記サーバは、プロセスまたはリクエストを送信するプロセスのユーザ識別子を確認するようにさらに構成されるホストデバイス。請求項29記載のホストデバイスにおいて、前記サーバは、前記サーバに関連付けられたバッファがフルではない場合のみ、前記リクエストに応答するようにさらに構成されるホストデバイス。請求項31記載のホストデバイスにおいて、前記ホストアプリケーションは、データのユニバーサルリソース識別子URIを無作為化するように構成されるホストデバイス。請求項29記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。ストレージデバイスと連通状態になるためにホストデバイスのサーバを使用する方法であって、ストレージデバイスと連通状態にあるホストデバイスのサーバにおいて、前記ホストデバイスのホストアプリケーションからデータのリクエストを受信し、前記リクエストは前記ホストアプリケーションによって直接アクセス不能なデータ場所を含み、前記ホストアプリケーションから受信された場所を書き換えられた場所に書き換え、前記書き換えられた場所を含むリクエストをデータのストレージデバイスに送信し、データを前記ストレージデバイスから受信し、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはデータを含み、かつ前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。請求項38記載の方法において、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含む方法。請求項39記載の方法において、前記ホストアプリケーションから受信された場所は、ユニバーサルリソース識別子URIを含む方法。請求項38記載の方法において、データは、前記ストレージデバイスのプライベートメモリエリアに格納される方法。請求項38記載の方法において、前記サーバがリクエストを待ち受けるポートを無作為化することをさらに含む方法。請求項38記載の方法において、プロセスまたはリクエストを送信するプロセスのユーザ識別子を確認することをさらに含む方法。請求項38記載の方法において、前記サーバに関連付けられたバッファがフルではない場合のみ、前記リクエストに応答することをさらに含む方法。請求項40記載の方法において、前記ホストアプリケーションは、データのユニバーサルリソース識別子URIを無作為化するように構成される方法。請求項38記載の方法において、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信することをさらに含む方法。ホストデバイスであって、ストレージデバイスと連通状態になるように構成されたインターフェイスと、ホストアプリケーションと、前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、符号化され、前記ホストアプリケーションによって直接アクセス不能なデータのリクエストを前記ホストアプリケーションから受信し、データのリクエストを前記ストレージデバイスに送信し、前記ストレージデバイスからデータを受信し、前記ホストアプリケーションによってアクセス可能な形式にデータを変換し、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスは変換されたデータを含み、前記ホストアプリケーションに前記レスポンスを送信するように構成されたサーバと、を備えるホストデバイス。請求項47記載のホストデバイスにおいて、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含むホストデバイス。請求項47記載のホストデバイスにおいて、符号化されたデータは暗号化され、データを変換することはデータを解読することを含むホストデバイス。請求項47記載のホストデバイスにおいて、符号化されたデータは、前記ストレージデバイスのパブリックメモリエリアに格納されるホストデバイス。請求項47記載のホストデバイスにおいて、前記サーバは、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。ストレージデバイスと連通状態になるためにホストデバイスのサーバを使用する方法であって、ストレージデバイスと連通状態にあるホストデバイスのサーバにおいて、符号化され、前記ホストアプリケーションによって直接アクセス不能なデータのリクエストを前記ホストアプリケーションから受信し、データのリクエストを前記ストレージデバイスに送信し、データを前記ストレージデバイスから受信し、前記ホストアプリケーションによってアクセス可能な形式にデータを変換し、前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスは変換されたデータを含み、かつ前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。請求項52記載の方法において、前記サーバは、ハイパーテキスト転送プロトコルHTTPサーバを含む方法。請求項52記載の方法において、符号化されたデータは暗号化され、データを変換することはデータを解読することを含む方法。請求項52記載の方法において、符号化されたデータは、前記ストレージデバイスのパブリックメモリエリアに格納される方法。請求項52記載の方法において、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成される方法。導入以下の実施形態は、一般に、ストレージデバイスのプライベートメモリエリアにある複数の保護ファイルへのアクセスを与えるストレージデバイスのパブリックメモリエリアにある仮想ファイルに関し、より詳しく言えば、ホストデバイスのキャッシュをバイパスすることによって、仮想ファイルにアクセスするホストデバイスおよび方法に関する。一般に、ストレージデバイスのパブリックメモリエリアに格納された仮想ファイルは、ストレージデバイスのプライベートメモリエリアにある複数の保護ファイルへのゲートウェイとして作用する。ストレージデバイスは、ホストデバイスが仮想ファイルへのアクセスを試みていることを検出すると、複数の保護ファイルがあれば、どの保護ファイルがホストデバイスに提供されるべきかを決定する。このようにして、引き続き同じ仮想ファイルの読み取りを試みることで、ホストデバイスに異なるコンテンツが戻されうる。しかし、ホストデバイスが、以前に呼び出したデータを格納して性能を高めるためにキャッシュを使用する際、問題が起こりうる。詳しく言えば、仮想ファイルに対して引き続きリクエストが出されると、ホストデバイスは、仮想ファイルを静的ファイルとして見なすため、ストレージデバイスへアクセスする代わりに、単にキャッシュにアクセスすることになる。したがって、ストレージデバイスのプライベートメモリエリアに格納された複数の曲にアクセスするために仮想ファイルが使用されれば、ホストデバイスは、所望された異なる曲を再生する代わりに、仮想ファイルが読み出されるたびに同じ曲を再生してしまう。この問題に対処する実施形態に進む前に、例示的な仮想ファイルの実施形態および例示的なストレージデバイスの概論を述べる。例示的な仮想ファイルの実施形態以下、図を参照すると、図1は、実施形態のストレージデバイス100と連通状態にあるホストまたはホストデバイス50のブロック図である。連通状態という用語は、本願明細書において使用される場合、コンポーネントが図に示されているかまたは本願明細書に記載されているかに関わらず、1つ以上のコンポーネントと直接的または間接的に連通状態にあることを意味する。ホスト50は、専用コンテンツプレーヤ、移動携帯電話、パーソナルコンピュータPC、ゲームデバイス、携帯用情報端末PDA、キオスクおよびTVシステムなどの任意の適切な形態をとりうるが、これらに限定されるものではない。ストレージデバイス100はまた、ハンドヘルド、取り外し可能なメモリカード例えば、フラッシュストレージカード、ユニバーサルシリアルバスUSBデバイスおよびソリッドステートドライブなどの任意の適切な形態をとりうるが、これらに限定されるものではない。好ましくは、ストレージデバイス100は、ホスト50に取り外し可能に接続されるため、ユーザは、種々のホストでストレージデバイス100を使用しうる。図1に示すように、ストレージデバイス100は、コントローラ110と、メモリ120とを備える。コントローラ110は、任意の適切な方法で実装されうる。例えば、コントローラ110は、マイクロプロセッサまたはプロセッサおよびマイクロプロセッサによって実行可能なコンピュータ可読プログラムコード例えば、ソフトウェアまたはファームウェアを格納するコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路ASIC、プログラマブルロジックコントローラおよび埋め込みマイクロコントローラの形態をとりうる。コントローラの例は、以下のマイクロコントローラ、例えば、ARC625D、AtmelAT91SAM、MicrochipPIC18F26K20およびSiliconLabsC8051F320を含むが、これらに限定されるものではない。コントローラにおいて使用されうるさまざまなコンポーネントの例は、以下に記述する実施形態に記載され、関連する図に示される。また、コントローラ110は、メモリ制御論理の一部として実装されうる。また、図1に示すように、ストレージデバイス100は、任意の適切な形態をとりうるメモリ120を備える。1つの実施形態において、メモリ120は、ソリッドステート例えば、フラッシュメモリの形態をとり、1回だけプログラム可能、数回プログラム可能または多数回プログラム可能なものでありうる。しかし、光学メモリおよび磁気メモリなどの他の形態のメモリも使用されうる。図1には単一のコンポーネントとして示されているが、コントローラ110および/またはメモリ120は、いくつかのコンポーネントとともに実装されうる。図1において、メモリ120は、パブリックメモリエリア130と、プライベートメモリエリア140とを備える。この実施形態において、パブリックおよびプライベートメモリエリア130、140は、単一のメモリデバイスの異なるパーティションであるが、他の実施形態において、パブリックおよびプライベートメモリエリア130、140は、異なるメモリデバイスである。パブリックメモリエリア130は、一般に、制限なしにアクセス可能であるが、プライベートメモリエリア140は、認証エンティティしかアクセスできず、典型的に、ホストには不可視である例えば、隠しパーティション。このように、プライベートメモリエリア140は、認証エンティティしかアクセスできない複数のコンテンツファイルここでは、ファイル1~Nを格納するために使用されうる。コンテンツファイルは、デジタル映像音声あり/なし例えば、映画、TV番組のエピソード、ニュース番組など、音声例えば、歌、ポッドキャスト、1つまたはひと続きのサウンド、オーディオブックなど、静止画や動画例えば、写真、コンピュータ生成ディスプレイなど、テキストグラフィックスあり/なし例えば、記事、テキストファイルなど、ビデオゲームや他のソフトウェアおよび2つ以上のこれらの形態のハイブリッドマルチメディアによる表現などの任意の適切な形態をとりうるが、これらの限定されるものではない。コンテンツ、コンテンツファイルおよびファイルという用語は、本願明細書において相互交換可能に使用され、プライベートメモリエリア140に格納されたファイルは、保護ファイルと呼ばれる。この実施形態において、パブリックメモリエリア130は、仮想ファイル150を含む。仮想ファイル150は、パブリックメモリエリア130のファイルアロケーションテーブルFATに割り当てられた論理ブロックアドレスとして存在するが、任意のデータを含まず、実際にはアクセス不能であるという意味で仮想である。仮想ファイル150に対してパブリックメモリエリア130に割り当てられた物理的な格納場所さえないこともあるしかし、以下に記述するように、いくつかの実施形態において、比較的少量の物理的な格納場所例えば、15MBが、仮想ファイル150のパブリックメモリエリア130に割り当てられることもある。しかし、仮想ファイル150が、パブリックメモリエリア130のFATテーブルに割り当てられた論理ブロックアドレスを有するため、仮想ファイル150は、ホスト50に対して通常ファイルとして現れる。この実施形態において、仮想ファイル150は、プライベートメモリエリア140の複数の保護ファイル1~Nへのゲートウェイとして働く。すなわち、コントローラ110が、仮想ファイル150へのアクセスが試みられていることを認識すると例えば、読み出しコマンドに指定された論理ブロックアドレスから、コントローラ110は、仮想ファイル150へのアクセスをホスト50に与える代わりに、特別な措置を講じる。例えば、コントローラ110が、仮想ファイル150へのアクセスを求めるリクエストをホスト50から受信すると、コントローラ110は、プライベートメモリエリア140に格納された複数の保護ファイル1~Nの1つを選択し、選択された保護ファイルへのアクセスをホスト50に与えることによって、リクエストに応答しうる。後に同じ仮想ファイル150がアクセスされると、コントローラ110は、複数の保護ファイル1~Nの異なるファイルを選択し、そのファイルへのアクセスを与えうる。例えば、仮想ファイル150が、音声.MP3という名前が付けられ、プライベートメモリエリア140に格納された20曲のプレイリストに関連付けられているとすれば、ホスト50が音声.MP3へのアクセスをリクエストするたびに、コントローラ110は、プレイリストにある別の曲を選択し、その曲へのアクセスを与えうる。コントローラ110が仮想ファイル150へのホストリクエストを取り扱うことができるように、任意の適切な実施例が使用されうる。例えば、図2に示す1つの実施形態において、アプリケーションまたはカプレット160が、コントローラ110がプライベートメモリエリア140の保護コンテンツを管理する方法を決めるルールセットを格納する例えば、どの保護ファイルにいつアクセスするのか。この実施形態において、カプレット160は、ハッカーがルールセットに不正変更を加えることができないように、プライベートメモリエリア140に格納される。コントローラ110は、仮想ファイル150へアクセスするようにホスト50からのリクエストに反応する方法を決定するために、カプレット160にルールセットを使用する。プライベートメモリエリア140はまた、複数の保護ファイル1~Nと仮想ファイル150とを関連付けるデータベース170を格納する。このようにして、データベース170は、複数の保護ファイル1~Nのプレイリストとして作用する。1つの実施形態において、データベース170は、複数の保護ファイル1~Nとともにストレージデバイス100に予めロードされる。データベース170が暗号化されていれば、カプレット160は、データベース170を解読するためのキーを保有しうる。動作中、ストレージデバイス100が起動されると、カプレット160は、予めロードされたデータベース170に従って、ホスト50による仮想ファイル150へのアクセスの試みを制御するように、コントローラ110をプログラムする。例えば、仮想ファイル150へのアクセスのリクエストに応答して、コントローラ110は、データベース170に基づいて、複数の保護ファイル1~Nのうちの1つを選択し、そのファイルへのアクセスを与えうる。別の例として、コントローラ110は、ホスト50が認証されているか、または認証されていないかを決定し、それに応じて、異なるタイプのコンテンツへのアクセスを与えうるが、このことは、ストレージデバイス100が、認証されているホストかにかかわらず、種々のホストが使用可能なポータブルメモリカードであれば、望ましい場合もある。したがって、ホスト50が認証プレーヤであれば、コントローラ110は、保護コンテンツへのアクセスを与えることによって、仮想ファイル150へアクセスするようにホスト50からのリクエストに応答しうる。逆に、ホスト50が認証プレーヤでなければ、コントローラ110は、代わりのファイルへのアクセスを与えることによって、ホストリクエストに応答しうる。このようにして、ルールセットは、ホスト50へのアプリケーションが認証されれば、コントローラ110が保護ファイル例えば、映画へのアクセスを与えることを指定し、そうでなければ、コントローラ110は、パブリックまたはプライベートメモリエリア130、140に格納されてもよい代わりのファイル例えば、映画の予告編へのアクセスを与えうる。このようにして、仮想ファイル150へアクセスするための同様のホストリクエストは、ホスト50が認証されたエンティティであるか、または認証されていないエンティティであるかに基づいて、コントローラ110によって別の方法での取り扱いが可能である例えば、ユーザがログインしていないか、またはストレージデバイス100によって認証されていなければ、ストレージデバイス100が、専用のコマーシャルに戻しうる。当然ながら、これは1つの例にすぎず、他のタイプのルールおよび条件も使用可能である。例えば、ファイルの選択は、時間、ユーザに関する情報、ホストによるストレージデバイス50へのログイン状況および方法、または任意の他の適切な条件に基づくものでありうる。これらの例から分かるように、仮想ファイル150は、異なる状況において異なる方法で処理でき、プライベートメモリエリア140にある1つ以上の保護ファイルへのアクセスを与えるために、パブリックメモリエリア130にある単一の仮想ファイル150が使用されうる。以下、図2を再び参照すると、この実施形態において、ホスト50は、ホストアプリケーション60と、メディアプレーヤここでは、Java登録商標以下同様プレーヤ70とを実行する。ホストアプリケーション60は、Javaプレーヤ70を制御するとともに、以下に記載するストレージデバイス100のコントローラ110にさらなる命令を送信する。前述したように、この実施形態において、仮想ファイル150例えば、音声.MP3という名前は、プライベートメモリエリア140に格納された複数の保護ファイル1~Nに関連付けられる。ホスト50が、音声.MP3へのアクセスをリクエストするたびに、コントローラ110は、複数の保護ファイル1~Nの異なるファイルを選択し、そのファイルへのアクセスを与えうる。この実施形態において、仮想ファイル150のサイズは、少なくとも、プライベートメモリエリア140の最大保護ファイルのサイズほどの大きさである。選択された保護コンテンツが、仮想ファイル150のサイズより小さければ、コントローラ110は、コンテンツを有効データでパディングするため、ホスト50のJavaプレーヤ70が誤動作することはない。例えば、保護ファイルが音声ファイルであれば、コントローラ110は、実行中に、サイレントMP3フレームや予測ヘッダ情報などの有効データで音声ファイルをパディングしうる。これは、異なるホストキャッシュアヘッド機構をサポート可能にするために行われる。コントローラ110がパディングデータを再生しないようにするために、コントローラ110は、ファイルの実際の再生長さをホスト50に知らせ、ホスト50は、パディングデータに達する前にファイルの再生を停止できる。Javaプレーヤ70が、音声ファイルであると考えられる仮想ファイル150を読み出すためにJSR-135プロトコルを使用してストレージデバイス110にリクエストを送信する例を考慮する。ストレージデバイス100のコントローラ110は、仮想ファイル150へのアクセスが試みられていることを検出し例えば、リクエストに指定された論理ブロックアドレスから、カプレット160のルールに基づいて、コントローラ110は、曲Aを選択し、曲AへのアクセスをJavaプレーヤ70に与える。コントローラ100はまた、前述したように、仮想ファイル150のサイズより小さいものでありうる曲Aの実際のサイズをホストアプリケーション60に知らせる。ホストアプリケーション60は、再生をモニタし、曲Aが完了すると、ホストアプリケーション60は、JSR-75プロトコルを介して、ストリーミングデータを停止し、次の曲へスキップするように、コントローラ110へコマンドを送信する。JSR-135プロトコルは、このタイプのコマンドをサポートしていない。このコマンドに応答して、コントローラ110は、次の曲曲Bを指し示すようにデータベース170を更新する。ホストアプリケーション60は、仮想ファイル150へのアクセスを再度リクエストするようにJavaプレーヤ70に命令を出す。しかし、このとき、コントローラ110は、曲B曲Aではないを選択し、曲BへのアクセスをJavaプレーヤ70に与える。次に、前述したプロセスは、Javaプレーヤ70が追加の曲の再生をリクエストし続けると、繰り返される。これらの実施形態とともに使用可能な代替例は数多くある。例えば、1つの実施形態において、ストレージデバイス100は、ストレージデバイス100が予めロードされた保護ファイルの位置を特定し、そのファイルにアクセスする時間を最小限に抑え、予めロードされた保護ファイル例えば、トラック名、アーティスト名、アルバム名、トラック時間などの詳細を抽出する時間を最小限に抑えるために、予めロードされた保護ファイルを再生するために専用ファイルシステムを使用する。このようにして、保護ファイルへゲートウェイの機能性を与える際に伴うコントローラ110のオーバーヘッドにかかわらず、仮想ファイル150にアクセスする時間は、別のタイプのファイルにアクセスする時間とほぼ同じである。この専用ファイルシステムを実行するために、保護ファイルは、連続的な論理ブロックアドレスLBAの順序でプライベートメモリエリア140内に予めロードされうる。次に、ファイル持続時間などの任意の他の関連データとともに、各保護ファイルの正確な開始LBAを指定するために、テーブルは生産中に構築されうる。このようなテーブルの読み出しは、必要な情報を集めるためにファイルを開くより高速であるため、この専用ファイルシステムの使用により、レスポンス時間が高速化する。前の記載から理解できるように、専用ファイルシステムは、予めロードされた異なるコンテンツの位置を特定しアクセスするために要求される時間量を短縮するために使用されうる。これは、再生に必要なデータのみを特定の方法で保存するための専用構造例えば、テーブルを規定することによって行われうる。このデータは、製品固有の要求例えば、トラック名、アーティスト名、アルバム名、トラック時間などに従って、異なる製品間で変更可能である。このデータ構造は、連続的なLBAの順番で、以前に指定された他のデータとともに各ファイルの正確な開始LBAにおいて位置が特定されたデータを保有するテーブルを用いて、ストレージデバイス100における安全な場所に予めロードされうる。テーブルのすべての入力は、テーブルの入力キーを使用して識別されうる特定のファイルを表しうる。特定のファイルへのアクセスのリクエストがあると、そのファイルのテーブルでの位置が特定され、関連するデータが呼び出される。例えば、仮想ファイル150を使用した最初から曲を再生するには、ファイルの開始LBA、実際の持続時間、表示されるアルバム名の知識が要求されうる。このようなファイルの取り扱い方法において、ファイルの位置の特定および再生に要する時間は、FATテーブルの取り扱いおよびファイルコンテンツの解析に必要な時間と比べると、著しく短縮される。レスポンス時間を高速化する別の代替例として、ストレージデバイス100は、複合コマンドの使用をサポートしうる。複合コマンドは、例えば、仮想ファイル状態および再生中の歌の両方の変更など、再生システムの異なる態様を制御する2つ以上のコマンドを組み込む単一のコマンドである。複合コマンドの使用は、特に、高速レスポンス時間の望まれる音声ストリーミングなどの環境において望ましい。例えば、複合コマンドは、チャンネルをスキップおよび2曲先にスキップまたは曲をスキップして一時停止を指定しうる。多くの状況において、いくつかのモード変更は、同時に起こることが必要な場合もある。例えば、曲を再生して一時停止モードにし、次の歌にスキップするシーケンスでは、スキップが起こったすぐ後に次の曲を開始することが要求されることもある。この場合、2つのコマンドは、この変更が行われるように、バス上で送信される必要がある。別の例において、システムの異なる態様は、仮想ファイル状態および再生中の曲の両方を変更する場合など、同時に制御されることが必要な場合もある。この場合も、考慮すべき点は、ストレージデバイス100の状態変更の取り扱いに必要な時間量、およびホスト50とストレージデバイス10との間でコマンドのやりとりをする時間量を短縮することである。さらなる別の代替例において、仮想ファイル150に対してパブリックメモリエリア130に実際のメモリを割り当てる代わりに、パブリックメモリエリア130が拡張ストレージエリアとしてホスト50にエミュレートすることによって、メモリ消費は低減されうるため、拡張エミュレートされたストレージエリアへのホストリクエストは、ストレージデバイスのプライベートメモリエリア140へのホストリクエストであるかのように、コントローラ110によって取り扱われる。その結果、仮想ファイル150は、パブリックメモリエリア130の実メモリを消費しない。これにより、貴重なメモリを消費することなく、大きなファイル例えば、映画を格納できる。例えば、仮想ファイル150が15MBで、パブリックメモリエリア130が30MBの状況を考えてみる。前述した技術を使用すると、ストレージデバイス100は、30MBが物理アドレスにマッピングされ、15MBはマッピングされない45MBのパブリックメモリエリア130を有するものとして識別しうる。前述した例は、ストレージデバイスの保護ファイルの読み出しに関するが、別の実施形態において、仮想ファイル150は、ホスト50が認証されていれば、プライベートメモリエリア140に新しいコンテンツを追加するために使用される。例えば、ユーザが曲を購入するとき、ホストアプリケーション60は、空いた空間に新しいコンテンツを追加し、その後、仮想ファイル150を使用して、新しい曲のデータをプライベートメモリエリア140に書き込むようにプライベートメモリエリア140を制御できる。別の例において、格納されたコマーシャルが、新しいコマーシャルに更新されうる。これは、仮想ファイル150をこのプライベートファイルにリンクした後、仮想ファイル150への書き込みによってコンテンツを変更することで達成されうる。ストレージデバイス100は、書き込みコマンドを遮断し、書き込み動作をプライベートメモリエリア140の正確な位置に通す。これにより、プライベートメモリエリア140を更新し、更新されたコンテンツおよび購入したコンテンツを安全な方法で保有できる。さらなる代替例は、コピープロテクト機構に関する。仮想ファイル150が、パブリックメモリエリア130においてアクセス可能であるため、仮想ファイル150は、任意のホストから単純なコピーコマンドで簡単にコピーされうる。以下の代替例は、仮想ファイル150のコピーを防止するために使用されうることで、プライベートメモリエリア140に格納された保護コンテンツへのアクセスが、コンテンツへのアクセスが許容された認証エンティティにのみ与えられる。このようにされなければ、ホスト50は、仮想ファイル150をパブリックメモリエリア130の別のアドレスレンジに単にコピーして、保護コンテンツに自由にアクセスできることになる。1つの例示的なコピープロテクト機構は、仮想ファイル150の読み出し動作によってストレージデバイス100から送信された保護コンテンツを暗号化するために暗号化スキームを使用する。これは、ホストアプリケーション60とストレージデバイス100との間に認証プロセスが適用されるたびに更新されるセッションキーを使用して行われうる例えば、ログイン中。このセッションキーは、ホスト50およびストレージデバイス100の両方に知られているため、ストレージデバイス100は、保護コンテンツを暗号化するためにセッションキーを使用でき、ホスト50は、保護コンテンツを解読するためにセッションキーを使用できる。このようにしてセッションキーを使用すると、ストレージデバイス100とホストアプリケーション60との間のチャンネルが安全なものになる。別の例示的なコピープロテクト機構は、ホスト50によって読み出されたセクタをカウントするために、ストレージデバイス100においてカウンタを使用する。カウンタがゼロに達すると、ストレージデバイス100は、無音のバッファの送信を開始しうる。ホスト50は、適切な認証後、カウンタを増やすように再生時間にわたってストレージデバイス100に命令しうる。カウンタの設定のこの動作は、ファイルの読み出し中に行われうる例えば、歌の再生中。ファイルのコピーが試みられる場合、ストレージデバイス100は、その試みを検出し、無効データをホスト50に戻し始めうる。これにより、ハッカーは、カウンタを増やすことなく、ある容量の歌例えば、5MBの歌の1MB分の音声しか呼び出すことができないため、歌のコピーが防止される。さらなる別の例示的なコピープロテクト機構において、データレート制御DRCは、ホスト50から仮想ファイル150への読み出し動作のパターンを考察した後、ストレージデバイス100によって実行される。これらの読み出し動作が予測通りに起こらなければ例えば、ストレージデバイス100が、仮想ファイル150のコピーが高速かつ迅速なファイルアクセスにより起こっていることを検出すれば、ストレージデバイス100は、無効データを戻すか、または読み出しプロセスを失敗させる。このようにして、ストレージデバイス100は、ストレージデバイス100から読み出された保護ファイルにデータレート制御を実行する。ホスト50は、ストレージデバイス100への適切な認証を有した後、現行のホスト50の固有の特性を適合するようにストレージデバイスDRC機構を構成可能であってもよい。また、スライドウィンドウは、例示的なコピープロテクトスキームとしても使用されうる。この機構を用いて、ストレージデバイス100により、ホスト50は、特定のLBAレンジ内のみ実データを読み出すことができる。このLBAレンジ外のデータへアクセスすると、無音のバッファが戻される。ホスト50は、適切な認証後、許容レンジを再構築しうる。許容レンジが動くため、許容レンジは、本願明細書において、スライドウィンドウと呼ばれる。前述したカウンタの概念は、スライドウィンドウとして使用でき例えば、現在のところ、1~500のコピー、またはデータの再生が仮想ファイル150内の特定の場所からのみ許容されうる。さらなる別の実施形態において、仮想ファイル150は、ネイティブメディアプレーヤから再生するために使用されうる。これは、コンテンツの各プレイリストに対して比較的大きな仮想ファイルを使用することによって行われうる。この仮想ファイルは、実行中に曲から曲へと継続的に接続しうる。ストレージデバイス100はまた、ホストネイティブプレーヤに表示されるコンテンツの各チャンネルにID3タグを与えうる。このようにして、ストレージデバイス100は、各ホスト例えば、ハンドセットまたは利用可能なオペレーティングシステム上で使用されうる。この解決策は、曲をスキップしようとする試みを検知する方法例えば、ユーザが、早送り/巻き戻し/再生バーの操作を行おうとするときを検出することでをストレージデバイスに許容することによって高められうる。例示的なストレージデバイス前述したように、これらの実施形態のストレージデバイスは、任意の適切な方法で実施されうる。以下の段落および参照する図は、1つの例示的な実施例を記載したものである。この実施例は、一例にすぎず、図に示すとともに本願明細書に記載される詳細は、本願明細書に明確な言及がない限り、特許請求の範囲に読み込まれるべきものではないことを理解すべきである。図に戻ると、図3Aおよび図3Bは、実施形態のストレージデバイス300およびホスト350のブロック図である。最初に、図3Bから参照すると、ストレージデバイス300は、コントローラ310と、メモリ320とを備える。コントローラ310は、メモリ320とのインターフェイスとなるメモリインターフェイス311と、ホスト350とのインターフェイスとなるホストインターフェイス312とを備える。コントローラ310はまた、中央演算処理装置CPU313と、暗号および/または解読演算を与えるように動作する暗号エンジン314、リードアクセスメモリRAM315と、ストレージデバイス300の基本演算用のファームウェア論理を格納する読み出し専用メモリROM316と、暗号/解読演算用に使用されるデバイス特有のキーを格納する不揮発性メモリNVM317とを備える。ストレージデバイス特有のキーは、ストレージデバイス内の他のメモリエリアに格納されうることに留意すべきである。図3Bに示すコンポーネントは、任意の適切な方法で実装されうる。この実施形態において、メモリ320は、ホスト350にファイルシステムによって管理されるパブリックパーティション325と、コントローラ310によって内部管理される隠し保護システムエリア335とを備える。隠し保護システムエリア335は、前述したように、コンテンツ暗号キーCEK340と、コンテンツと、データベースと、カプレット342とを格納する。隠し保護システムエリア335は、コントローラ310ホストコントローラ360ではなくによって内部管理されるために隠されており、このエリア335に格納されたオブジェクトが、コントローラ310の不揮発性メモリ317に格納された固有のキーで暗号化されるため、保護される。ストレージデバイスハードウェアの固有のキーは、コントローラ310の不揮発性メモリ317またはストレージデバイス300内の他のエリアに格納されうる。したがって、このエリア335に格納されたオブジェクトにアクセスするために、コントローラ310は、暗号エンジン314および不揮発性メモリ317に格納されたキーを使用して、暗号化されたオブジェクトを解読する。ストレージデバイス300は、サンディスクコーポレイションによるTrustedFlash登録商標プラットフォームに構築された製品群からセキュアプロダクトの形態をとることが好ましい。パブリックパーティション325は、仮想ファイル330を含む。以下、図3Aのホスト350を参照すると、ホスト350は、ストレージデバイス300とのインターフェイスとなるストレージデバイスインターフェイス361を有するコントローラ360を備える。コントローラ360はまた、中央演算処理装置CPU363と、暗号および/または解読演算を与えるように動作する暗号エンジン364、リードアクセスメモリRAM365と、読み出し専用メモリROM366とを備える。ボックス360内の各コンポーネントは、全ホストシステムにおいて別のチップとして実装されうることに留意すべきである。ホスト350はまた、コンテンツエンジン371と、ファイルシステムAPI372と、コンテンツデコーダAPI373と、ホスト証明書374とを備えるアプリケーション370を備える。ストレージデバイス300およびホスト350は、ストレージデバイスインターフェイス361およびホストインターフェイス312を介して互いに連通状態にある。安全なデータ転送を伴う動作のために、ストレージデバイス300およびホスト350の暗号エンジン314、364が、互いに相互に認証し、キー交換を行うために使用されることが好ましい。相互認証プロセスは、固有の証明IDを交換するために、ホスト350およびストレージデバイス300を必要とする。相互認証の完了後、ストレージデバイス300とホスト350との間に安全な通信チャンネルを確立するためにセッションキーが使用されることが好ましい。ホストデバイスのキャッシュのバイパスに関する実施形態再度図を参照すると、図4は、実施形態のホストデバイス400およびストレージデバイス410のブロック図である。ホストデバイス400は、ストレージデバイス410、ホストアプリケーション430例えば、メディアプレーヤおよびキャッシュ440と連通状態になるように構成されたインターフェイス420を備える。ストレージデバイス410例えば、SDカードは、インターフェイス図示せずと、コンテンツを格納するプライベートメモリエリア450と、プライベートメモリエリア450に格納されたコンテンツに関連付けられる仮想ファイル470を格納するパブリックメモリエリア460と、カプレット480とを備える。前述したように、パブリックメモリエリア460の仮想ファイル470は、プライベートメモリエリア450に格納されたセキュアコンテンツへのアクセスを与え、カプレット480は、セキュアデータへアクセスし、ホストデバイス400へ流すための所定のルールセットを強化する。しかし、ホストアプリケーション430が、ストレージデバイス410からファイルを読み出すときに性能を高めようとキャッシュ440を使用するとき、問題が起こりうる。詳細に言えば、ホストアプリケーション430が、以前に仮想ファイル470を読み出していれば、呼び出されたコンテンツは、ホストデバイスのキャッシュ440に格納される。ホストアプリケーション430が、ストレージデバイス410の仮想ファイル470にアクセスする代わりに、仮想ファイル470を再度読み出そうとする場合、ホストアプリケーション430は、データが静的であると見なすため、キャッシュ440に格納されたデータにアクセスするのみである。しかし、その後、仮想ファイル470を読み出そうとすると、ストレージデバイス410から異なるコンテンツが読み出されることがあるため、この状況でキャッシュ440を使用すると、ホストアプリケーション430に無効または不正確なデータが戻されることになる。例えば、プライベートメモリエリア450に格納された複数の曲にアクセスするために仮想ファイル470が使用されれば、ホストアプリケーション430は、仮想ファイルが読み出されるたびに、所望された異なる曲を再生する代わりに同じ曲を再生する。図5に示すホストデバイス500は、ホストデバイス500によってファイルがキャッシュに入れられないようにすることによって、仮想ファイルから読み出されたデータが有効になるようにすることで、この問題を解消するために使用されうる。また、図4のホストデバイス400のように、図5のホストデバイス500は、インターフェイス520と、ホストアプリケーション530と、キャッシュ540とを備える。同様に、この実施形態におけるストレージデバイス510は、コンテンツを格納するプライベートメモリエリア550と、プライベートメモリエリア550に格納されたコンテンツに関連付けられた仮想ファイル570を格納するパブリックメモリエリア560と、カプレット580とを備える。しかし、この実施形態において、ホストデバイス500はまた、サーバ590を備える。任意のタイプのサーバが使用されうるが、この実施形態では、サーバ590は、ハイパーテキスト転送プロトコルHTTPサーバの形態をとる。この実施形態において、ホストアプリケーション530と一体化され、ホストデバイス500で実行されるサーバ590は、ストレージデバイス510に格納された仮想ファイルを管理する役割を担う。この実施形態において、サーバ590は、ホストアプリケーション530の一体部品としてホストデバイス500のスレッドとして実行され、ホストアプリケーション530が閉じると終了される。一般に、サーバ590は、ホストアプリケーション530からの仮想ファイル570のリクエストを受信し、仮想ファイル570に対してストレージデバイス510にリクエストを送信し、ストレージデバイス510のプライベートメモリエリア550から仮想ファイル570に関連付けられたコンテンツを受信し、コンテンツを含むホストアプリケーション530からのリクエストへのレスポンスを生成し、キャッシュ540をバイパスしながら、ホストアプリケーション530へレスポンスを送信する。このサーバとクライアントとの相互作用はキャッシュ540をバイパスするため、この実施形態では、キャッシュ540から不正コンテンツが読み出される状況が回避される。ストレージデバイス510のパブリックメモリエリア560に格納された各仮想ファイルに対して、HTTPサーバ590を使用する特定の実施例において、HTTPサーバ590は、特定のURL例えば、httplocalhost8000vfilemp3をホストする。URLのファイルパスは純粋に記号的なものであり、サーバ590は、URLで指定されたファイルからストレージデバイス510のパブリックメモリエリア560に位置する特定の仮想ファイルへのマッピングを保有する。したがって、HTTPサーバ590は、ホストアプリケーション530から仮想ファイルのURLを受信すると、受信したURLを、ストレージデバイス510のパブリックメモリエリア560にある仮想ファイル570のアドレスに書き換える。サーバ上のリモートファイルへのアクセスHTTPGetリクエストが、ストレージデバイス10上の仮想ファイル570の読み出しリクエストと同等のものである。ホストデバイス500が、リクエストされたリモートファイルがHTTPサーバ590にリモート格納され、ホストデバイス500にローカル格納されていないのを把握しているため、ホストデバイス500は、ファイルのデータをキャッシュしない。したがって、ファイルへの各アクセスには、HTTPGetリクエストを送信し、HTTPレスポンスを解析することによって、HTTPサーバ590からファイルのデータを読み出す必要がある。これにより、仮想ファイル570に関連付けられたデータを読み出すためには、ストレージデバイス510がアクセスされなければならなくなる。以下は1つの例示的な流れであるが、任意の適切な流れが使用されうる。第1に、ホストアプリケーション530が開始され、専用スレッドが開かれ、HTTPサーバ590として作用する。HTTPサーバスレッドは、サーバソケットを作り、入力HTTPリクエストを待機する。ホストアプリケーション530が、仮想ファイル570のコンテンツを読み出そうとすると、仮想ファイル570のURLを指定するHTTPGetリクエストをHTTPサーバ590に送信する。HTTPGetリクエストは、HTTPサーバ590によって受信される。随意に、HTTPサーバ590は、プロセスまたはユーザ識別子または何らかの他のタイプの識別子をチェックすることによって、リクエストを送信するプロセスを有効化しうる。例えば、HTTPサーバ590は、仮想ファイル570のコンテンツを読み出すためのアクセス許可を有するプロセスのテーブルもしくはツリー、またはユーザ識別子を格納しうる。プロセスまたはユーザ識別子が、仮想ファイル570のコンテンツを読み出すアクセス許可を有していなければ例えば、プロセスまたは識別子が、テーブルまたはツリーにリストされていないため、HTTPサーバ590は、エラーレスポンスを戻しうる。しかし、プロセスまたはユーザ識別子がテーブルまたはツリーにリストされていれば、仮想ファイルのコンテンツを読み出すアクセス許可があり、HTTPサーバ590は、読み出すために仮想ファイル570を開くために、ストレージデバイス510の専用アクセス制御記録この場合、カプレット580にログインする。1つの好ましい実施形態において、アクセス制御記録は、サンディスクコーポレイションからのTrustedFlash登録商標ストレージデバイスにおいて使用されるタイプのものであるが、他のタイプのアクセス制御記録も使用されうる。好ましくは、仮想ファイル570の真のコンテンツを受信するために、アクセス制御記録はログインされなければならない。仮想ファイル570のコンテンツを読み出しながら、アクセス制御記録がログインされない場合、無効データが戻されることが好ましい。アクセス制御記録へログインするために、ホストデバイス500は、ストレージデバイス510に対して認証を行う。1つの実施形態において、認証プロセスには3段階ある。すなわち、パブリックキー確認段階、プライベートキー確認段階およびセッションキー承諾段階である。パブリックキー確認段階の間、ホストデバイス500は、ストレージデバイス510に証明書チェーンを送信するため、ストレージデバイス510は、ルート証明書に位置するルート証明書認可パブリックキーを使用して、証明書およびパブリックキーの真実性を確認できる。パブリックキー確認段階を無事通過すれば、プライベートキー確認段階が実行される。プライベートキー確認段階中、ストレージデバイス510は乱数を生成し、チャレンジとしてホストデバイス500に乱数を送信する。ホストデバイス500は、ストレージデバイス510のプライベートキーを使用してストレージデバイスの乱数にサインし、チャレンジへのレスポンスとしてサイン済みの乱数を送信する。このレスポンスは、ストレージデバイスのパブリックキーを使用して解読され、乱数と比較される。解読されたレスポンスが乱数と整合すれば、チャレンジのレスポンスは成功である。相互認証が実行されれば、ストレージデバイス510に対して同じプロセスが生じる。プライベートキー確認段階を無事通過すれば、セッションキー承諾段階が実行される。セッションキー承諾段階中、乱数はホストデバイスのパブリックキーを使用して暗号化される。この乱数は、セッションキーになる。ホストデバイス500は、ストレージデバイス510から暗号化された乱数を解読するために、プライベートキーを使用してセッションキーを得ることができる。ホストデバイス500側でも同じプロセスが生じる。セッションキーを用いて、ホストデバイス500とストレージデバイス510との間のセキュア通信が開始されうる。ホストデバイス500が、ストレージデバイス510のアクセス制御記録にログインした後、ストレージデバイス510は、ホストデバイス500が、プライベートメモリエリア550から仮想ファイルの真のコンテンツへアクセスする許可を有しているかを決定しうる。1つの実施形態において、アクセス制御記録は、アクセス制御記録へのログインが成功したエンティティに与えられる権利例えば、読み出しのみ、書き込みのみ、読み出しおよび書き込みアクセスなどを示す許可制御記録を含む。したがって、ホストデバイス500がアクセス制御記録にログインした後、ストレージデバイス510は、ホストデバイス500が仮想ファイルの真のコンテンツにアクセスする許可を有するかを決定するために、許可制御記録を使用しうる。ホストデバイス500が許可を有していれば、ホストデバイス500に真のコンテンツが戻される。そうでなければ、データも無効データも戻されない。前述した記載から分かるように、仮想ファイルの真のコンテンツがホストアプリケーション530に戻される前に、2回の許可チェックが実行されうる。1回目は、ホストアプリケーション530がホストアプリケーション530のプロセスまたはユーザ識別子を確認することによって、仮想ファイル570のコンテンツを読み出す許可を有するかどうかをHTTPサーバ590が決定しうる。2回目は、ホストデバイス500がストレージデバイス510のアクセス制御記録にログインした後、アクセス制御記録の許可制御記録がホストデバイス500が仮想ファイル570のコンテンツへアクセスする許可を有することを示すかどうかを、ストレージデバイス510が決定しうる。これらの許可チェックの一方または両方が、セキュリティ上の理由から好ましいものでありうるが、これらの許可チェックの使用は選択できるものであることに留意すべきである。ホストデバイスのキャッシュ540をバイパスするために、HTTPサーバ590は、キャッシュ540をバイパスするためにホストデバイスのオペレーティングシステムに命令を送りうる。1つの実施形態において、この命令は、O_DIRECTフラグを含み、このフラグは、ファイルからの各読み出し演算が、ホストデバイスのキャッシュ540をバイパスし、ストレージデバイス510に向けられることを示す特別なフラグである。この命令により、ホストデバイス500が、仮想ファイルに関連付けられたコンテンツを求めるHTTPサーバのリクエストに対して、ストレージデバイス510からのレスポンスを受信するため、オペレーティングシステムは、HTTPサーバ590にストレージデバイスからのレスポンスを、キャッシュ540に格納することなく送信する。HTTPサーバ590が、O_DIRECTフラグを使用して仮想ファイル570を開き、仮想ファイル570のコンテンツを読み出した後、HTTPサーバ590は、仮想ファイル570に関連付けられたプライベートメモリエリア550からのデータを含むHTTPレスポンスを生成する。次に、ホストアプリケーション530が、HTTPサーバ590からレスポンスを受信し、仮想ファイル570のデータを解析する。この方法を用いて、仮想ファイル570から読み出されたデータは、キャッシュ540に格納された不正データの可能性のあるものの代わりに、ストレージデバイス510に格納されているファイルの実データである。これにより、ホストキャッシュ機構をバイパスし、ファイル570へのアクセスをモニタしながら、仮想ファイル570からデータを読み出すための単純かつ簡単な機構が得られる。これらの実施形態とともに使用されうるいくつかの代替例がある。例えば、ホストデバイスのキャッシュをバイパスするためにサーバおよびコマンドを使用する代わりに、ホストは、仮想ファイルを読み出す試みがなされると、大量のデータすなわち、キャッシュに格納されているデータより多い量を読み出すようにプログラムされうる。読み出しリクエストが、キャッシュに格納されたものより多いデータに対するものであるため、このような読み出しリクエストは、ホストキャッシュを効果的に無効化し、ストレージデバイスから仮想ファイルのデータをホストに直接獲得させる。別の代替例として、前述した実施形態は、既存のコマンドTrustedFlash登録商標ストレージデバイスとともに使用されるものなどで直接動くように修正されうるため、仮想ファイルの使用は回避されうる。この代替例において、HTTPサーバは、ストレージデバイスとのセキュアセッションを作り、隠しパーティションへのストリームを作り、ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するように読み出しストリーム演算を使用し、暗号化されたコンテンツを解読することによって、ストレージデバイスのプライベートメモリエリアからセキュアコンテンツを得ることができる。前述した実施形態のいくつかは、ホストデバイスのキャッシュをバイパスするためにホストデバイスのサーバを使用しているが、より一般的には、ホストデバイスのサーバは、ユーザアプリケーションが再生エンジンへの入力を含むように許可しないオペレーティングシステムで、特定のファイルシステムコールシーケンスへの再生の依存性をバイパスするために、ホストデバイスのサーバが使用されうることに留意すべきである。詳細には、サーバは、ホストアプリケーションから受信した任意のユニバーサルリソース識別子URIをコンテンツに分けうるが、このように分けなければ、ホストアプリケーションはコンテンツを入手できない。次に、サーバは、ストレージデバイスから受信したコンテンツをホストアプリケーションの再生エンジンに流すことができ、この再生エンジンは、ネットワークストリーミングを実行し、ファイルアクセスを指示するようにのみ動作するものであってもよい。データは符号化例えば、暗号化されうるが、この場合、サーバは、ストリーミングプロセス中に該当データを変換しうる例えば、解読。動作中、サーバ例えば、HTTPサーバは、ホストアプリケーションが直接的にアクセスできない場所のデータ例えば、URIを受信した後、その場所を書き換えて書き換えられた場所にする。次に、サーバは、書き換えられたアドレスを使用してストレージデバイスから例えば、ストレージデバイスのプライベートパーティションからデータを呼び出し、その後、そのデータをホストアプリケーションに与える。さらに、網羅的なリストではないが、以下の特徴は、前述した実施形態の任意のもののサーバに実装されうる。1.ポートの無作為化:サーバが待ち受けるポートは無作為であり、例えば、ストリームが変更されるたびに変更されうる。2.呼び出しプロセスまたはユーザ識別子チェック:ソケット接続プロセス識別子PIDは、aメディアサーバプロセスからのもの、およびbインストール可能なアプリケーションからのものではないユーザ識別子UIDを有することを確実にするためにチェックされうる。3.バッファ進行整合:再生中、HTTPサーバからのリクエストに対してバッファが整合され、バッファがフルであれば、リクエストは出されない。4.ユニフォームリソース識別子UPIの無作為化:リクエストに際してサーバに送信された実際のURIは、時間により異なるものでありうる。1つの実施形態において、プレーヤアプリケーションまたはサーバの呼び出し元および実際の再生エンジンのみが、UPIの知識を有し、任意の他のURIは攻撃を試みるものと見なされる。また、URIは、疑似ワンタイムパスワードOTPアルゴリズムを使用して導き出され、不正URIを用いてなされたリクエストはオープンソケットを残しうる。さらに、URIは、サーバと呼び出しアプリケーションとの間のチャレンジ/レスポンスアルゴリズムを使用してネゴシエートされるトークンを含みうる。URIの無作為化に関して、保護メディアコンテンツが、HTTPサーバからストリーミングされるとき、ホストアプリケーションは、着目するコンテンツへのパスを特定するためにURIを使用し、そのURIを下位メディアプレーヤサブシステムに渡しうる。前述したように、サーバパスおよび着目するメディアファイルを特定するURIは、無作為化され、一時的なものでありうる。好ましくは、URIの無作為化はユニークであり、理想的には、同じホスト例えば、ハンドセット内で二度生成されることはない。また、URIは、一時的なものであることが好ましく、発行されてからある一定のタイムフレーム例えば、30秒内で期限切れになる。URIが有効なプレーヤによってアクセスされると、HTTPサーバは、URIへの任意の他のアクセスを受けないことが好ましい。例示的なURIフォーマットは、以下のもの、すなわち、video/hash/timestamp/mediaFileNameになりうる。ここで、ivideoとは、映像コンテンツへのアクセスを示す定数列であり、iihashは、例えば、MD5.hashtokenmedhiaFileNametimestampなどのハッシュであり、ここで、トークンはストレージデバイスでメディアファイルごとにユニークであり、iiitimestampは、16進数列として与えられたタイムスタンプであり例えば、16進記数法で1970年1月1日00:00:00からの経過秒数、ivmedhiaFileNameは、コンテンツファイル例えば、映像ファイルの名前である。好ましくは、無作為化された一時URIは、ネイティブアプリケーションインターフェイスAPIを介してサーバから渡される。別の代替例において、ホストのサーバ例えば、HTTPサーバは、ストレージデバイスから例えば、ストレージデバイスのパブリックパーティションから呼び出された符号化例えば、暗号化されたファイルを変換例えば、復号化または解読し、例えば、HTTPGetリクエストに応答して変換されたデータをホストアプリケーションに戻すように構成されうる。これにより、ホストアプリケーション例えば、メディアプレーヤは、ストレージデバイスのパブリックパーティションに格納された符号化ファイルを再生できる。したがって、ストレージデバイスのパブリックパーティションに格納された仮想ファイルのコンテンツを読み出すか、またはストレージデバイスのプライベートパーティションからコンテンツを抽出する特殊なコマンドを送信する前述した実施形態とは異なり、サーバは、この代替例において、ストレージデバイスのパブリックパーティションに格納された専用ファイルを変換する。別の代替例は、サーバのセキュリティ対策を改善することに関する。あるオペレーティングシステムにおいてコマンドを実行する許可は、2つのグループ、すなわち、通常ユーザ許可およびスーパーユーザ許可adminまたはroot許可としても知られているに分けられる。ハッカーが、ルート許可を有することができるようにオペレーティングシステムを修正して、ホストデバイスに修正されたオペレーティングシステムをインストールすることもある。一旦インストールされると、ハッカーは、通常ユーザであるにもかかわらず、スーパーユーザの許可を有し、ストレージデバイスのプライベートメモリエリアに格納されたデータへ不正アクセスする許可を使用しうる。このようなことが起きないように、サーバは、ルートチェックを実行するように構成されうる。詳細には、サーバは、ホストアプリケーションからのリクエストが、通常ユーザ許可またはスーパーユーザ許可に関連付けられているかを決定するように構成され例えば、ホストアプリケーションからのリクエストが、使用可能にされたスーパーユーザ許可を有しているかを決定することによって、リクエストが通常ユーザ許可に関連付けられていると決定された場合のみ、ホストアプリケーションへのレスポンスを送信するようにさらに構成されうる。これにより、サーバは、ホストデバイスがルートされるとき、ホストアプリケーションのリクエストに応答できなくなる。ホストデバイスがルートされていなければ、サーバは、通常通りに挙動し、解読されたコンテンツファイル例えば、mp3ファイルのデータを有するレスポンスを送信しうる。リクエストが、通常ユーザ許可またはスーパーユーザ許可に関連付けられているかを決定するために、任意の適切な方法が使用されうる。例えば、Androidのオペレーティングシステムを実行するホストデバイスにおいて、ro.secureシステムの特性を分析することによって、スーパーユーザ権限の決定が行われうる。ro.secureシステム特性が0に設定されていれば、プロセスは、スーパーユーザ権限を得てもよい。Linux登録商標系のオペレーティングシステムでは、特別なユーザ0の指定は、スーパーユーザ権限を示す。また、プロセスが、システム機能を用いてユーザIDを決定してもよい。例えば、プロセスが、setuidまたはsetuid機能を用いて、有効ユーザIDを0に設定しようと試みてもよい。ユーザIDが0に設定されれば、プロセスはスーパーユーザ権限を有する。スーパーユーザ権限は、スーパーユーザ権限を有するべきではない呼び出しプロセス以外のプロセスに割り当てられてもよい。例えば、Linux登録商標系のオペレーティングシステムにおいて、procファイルシステム/procは、ユーザIDを含むアクティブプロセスのすべてに関する情報を含んでもよい。これは、呼び出しプロセスまたは任意の依存が有するべき権限を超えているかを決定するために、各プロセスに対して既知の正確なユーザアカウントと比較されうる。結論前に詳述した記載は、本発明の定義としてではなく、本発明がとりうる選択された形態の説明として理解されることを意図したものである。請求された本発明の範囲を規定するように意図されるものは、すべての均等物を含む添付の特許請求の範囲のみである。最後に、本願明願細書に記載された任意の好ましい実施形態の任意の態様は、単独で、または互いに組み合わせて使用されうることに留意すべきである。