(57)【要約】  パブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと連通状態になるように構成されたインターフェイスを備えるホストデバイスを提供する。パブリックメモリエリアは、プライベートメモリエリアに格納されたコンテンツに関連付けられる仮想ファイルを格納する。また、ホストデバイスは、キャッシュと、ホストアプリケーションと、サーバと、を備える。サーバは、ホストアプリケーションから仮想ファイルのリクエストを受信し、仮想ファイルのリクエストをストレージデバイスに送信し、ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、コンテンツはキャッシュをバイパスすることによって受信され、ホストアプリケーションからのリクエストへのレスポンスを生成し、リスポンスはコンテンツを含み、かつホストアプリケーションへのレスポンスを送信するように構成される。１つの実施形態において、サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバである。別の実施形態において、サーバは、リクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、リクエストが通常ユーザ許可に関連することが決定される場合のみ、ホストアプリケーションにレスポンスを送信しうる。
2013530454.tif 000002
【特許請求の範囲】
【請求項１】
ホストデバイスであって、
パブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと連通状態になるように構成されたインターフェイスであって、前記パブリックメモリエリアは前記プライベートメモリエリアに格納されたコンテンツに関連付けられる仮想ファイルを格納するインターフェイスと、
キャッシュと、
前記キャッシュと連通状態にあるホストアプリケーションと、
前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、
前記ホストアプリケーションから仮想ファイルのリクエストを受信し、
仮想ファイルのリクエストを前記ストレージデバイスに送信し、
前記ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、前記コンテンツは前記キャッシュをバイパスすることによって受信され、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはコンテンツを含み、かつ
前記レスポンスを前記ホストアプリケーションに送信するように構成されたサーバと、
を備えるホストデバイス。
【請求項２】
請求項１記載のホストデバイスにおいて、
オペレーティングシステムをさらに備え、
前記サーバは、仮想ファイルのリクエストへのレスポンスを前記ストレージデバイスから受信すると、前記オペレーティングシステムが前記キャッシュをバイパスするように前記オペレーティングシステムに命令を送信するようにさらに構成されるホストデバイス。
【請求項３】
請求項２記載のホストデバイスにおいて、
前記キャッシュをバイパスする命令は、Ｏ＿ＤＩＲＥＣＴフラグを含むホストデバイス。
【請求項４】
請求項１記載のホストデバイスにおいて、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含むホストデバイス。
【請求項５】
請求項４記載のホストデバイスにおいて、
前記ＨＴＴＰサーバによって受信されるリクエストは、ＨＴＴＰ  Ｇｅｔリクエストを含むホストデバイス。
【請求項６】
請求項４記載のホストデバイスにおいて、
前記ＨＴＴＰサーバは、
前記ホストアプリケーションから仮想ファイルのユニバーサルリソースロケータ（ＵＲＬ）を受信し、かつ
前記ホストアプリケーションから受信されたＵＲＬを前記ストレージデバイスのパブリックメモリエリアにある仮想ファイルのアドレスに書き換えるようにさらに構成されるホストデバイス。
【請求項７】
請求項１記載のホストデバイスにおいて、
前記サーバは、前記コンテンツにアクセスする許可を前記ホストアプリケーションが有するかを決定するようにさらに構成されるホストデバイス。
【請求項８】
請求項７記載のホストデバイスにおいて、
前記サーバは、前記ホストアプリケーションから受信された識別子に基づいた許可を前記ホストアプリケーションが有するかを決定するようにさらに構成されるホストデバイス。
【請求項９】
請求項１記載のホストデバイスにおいて、
前記サーバは、仮想ファイルを開くために、前記ストレージデバイスのアクセス制御記録にログインするようにさらに構成されるホストデバイス。
【請求項１０】
請求項９記載のホストデバイスにおいて、
前記アクセス制御記録には許可制御記録が含まれ、
前記サーバは、前記コンテンツを受信する許可を前記ホストデバイスが有していることを前記許可制御記録が示す場合のみ、前記ストレージデバイスのプライベートエリアから仮想ファイルに関連付けられたコンテンツを受信するホストデバイス。
【請求項１１】
請求項１記載のホストデバイスにおいて、
前記サーバは、
前記ストレージデバイスとのセキュアセッションを確立し、
前記プライベートメモリエリアへのストリームを確立し、
前記ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するために読み出しストリーム演算を使用し、かつ
前記暗号化されたコンテンツを解読するようにさらに構成されるホストデバイス。
【請求項１２】
請求項１記載のホストデバイスにおいて、
前記サーバは、前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。
【請求項１３】
請求項１２記載のホストデバイスにおいて、
前記サーバは、前記ホストアプリケーションからのリクエストが、「ｒｏ．ｓｅｃｕｒｅ」システム特性を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定するようにさらに構成されるホストデバイス。
【請求項１４】
請求項１２記載のホストデバイスにおいて、
前記サーバは、前記ホストアプリケーションからのリクエストが、ユーザ識別子を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定するようにさらに構成されるホストデバイス。
【請求項１５】
ホストデバイスのキャッシュをバイパスすることによって、ストレージデバイスの仮想ファイルにアクセスする方法であって、
ホストデバイスのサーバであって、前記ホストデバイスがパブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと連通状態にあり、前記パブリックメモリエリアは前記プライベートメモリエリアに格納されたコンテンツに関連付けられる仮想ファイルを格納するホストデバイスのサーバにおいて、
前記ホストデバイスのホストアプリケーションから仮想ファイルのリクエストを受信し、
仮想ファイルのリクエストを前記ストレージデバイスに送信し、
前記ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、前記コンテンツは前記ホストデバイスのキャッシュをバイパスすることによって受信され、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはコンテンツを含み、かつ
前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。
【請求項１６】
請求項１５記載の方法において、
前記ホストデバイスは、オペレーティングシステムをさらに備え、
前記方法は、仮想ファイルのリクエストへのレスポンスを前記ストレージデバイスから受信すると、前記オペレーティングシステムが前記キャッシュをバイパスするように前記オペレーティングシステムに命令を送信することをさらに含む方法。
【請求項１７】
請求項１６記載の方法において、
前記キャッシュをバイパスする命令は、Ｏ＿ＤＩＲＥＣＴフラグを含む方法。
【請求項１８】
請求項１５記載の方法において、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含む方法。
【請求項１９】
請求項１８記載の方法において、
前記ＨＴＴＰサーバによって受信されたリクエストは、ＨＴＴＰ  Ｇｅｔリクエストを含む方法。
【請求項２０】
請求項１８記載の方法において、
前記ホストアプリケーションから仮想ファイルのユニバーサルリソースロケータ（ＵＲＬ）を受信し、かつ
前記ホストアプリケーションから受信されたＵＲＬを前記ストレージデバイスのパブリックメモリエリアにある仮想ファイルのアドレスに書き換えることをさらに含む方法。
【請求項２１】
請求項１５記載の方法において、
前記コンテンツにアクセスする許可を有するかを前記ホストアプリケーションが決定することをさらに含む方法。
【請求項２２】
請求項２１記載の方法において、
前記ホストアプリケーションから受信された識別子に基づいた許可を前記ホストアプリケーションが有するかを決定することをさらに含む方法。
【請求項２３】
請求項１５記載の方法において、
前記仮想ファイルを開くために、前記ストレージデバイスのアクセス制御記録にログインすることをさらに含む方法。
【請求項２４】
請求項２３記載の方法において、
前記アクセス制御記録には許可制御記録が含まれ、
前記方法は、前記コンテンツを受信する許可を前記ホストデバイスが有していることを前記許可制御記録が示す場合のみ、前記ストレージデバイスのプライベートエリアから仮想ファイルに関連付けられたコンテンツを受信することをさらに含む方法。
【請求項２５】
請求項１５記載の方法において、
前記ストレージデバイスとのセキュアセッションを確立し、
前記プライベートメモリエリアへのストリームを確立し、
前記ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するために読み出しストリーム演算を使用し、かつ
前記暗号化されたコンテンツを解読することをさらに含む方法。
【請求項２６】
請求項１５記載の方法において、
前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信することをさらに含む方法。
【請求項２７】
請求項２６記載の方法において、
前記ホストアプリケーションからのリクエストが、「ｒｏ．ｓｅｃｕｒｅ」システム特性を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定することをさらに含む方法。
【請求項２８】
請求項２６記載の方法において、
前記ホストアプリケーションからのリクエストが、ユーザ識別子を分析することによって、通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定することをさらに含む方法。
【請求項２９】
ホストデバイスであって、
ストレージデバイスと連通状態になるように構成されたインターフェイスと、
ホストアプリケーションと、
前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、
前記ホストアプリケーションからデータのリクエストを受信し、前記リクエストはホストアプリケーションによって直接アクセス不能なデータ場所を含み、
前記ホストアプリケーションから受信された場所を書き換えられた場所に書き換え、
前記書き換えられた場所を含むリクエストをデータのストレージデバイスに送信し、
前記ストレージデバイスからデータを受信し、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはデータを含み、
前記ホストアプリケーションに前記レスポンスを送信するように構成されたサーバと、を備えるホストデバイス。
【請求項３０】
請求項２９記載のホストデバイスにおいて、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含むホストデバイス。
【請求項３１】
請求項３０記載のホストデバイスにおいて、
前記ホストアプリケーションから受信された場所は、ユニバーサルリソース識別子（ＵＲＩ）を含むホストデバイス。
【請求項３２】
請求項２９記載のホストデバイスにおいて、
データは、前記ストレージデバイスのプライベートメモリエリアに格納されるホストデバイス。
【請求項３３】
請求項２９記載のホストデバイスにおいて、
前記サーバは、リクエストを待ち受けるポートを無作為化するようにさらに構成されるホストデバイス。
【請求項３４】
請求項２９記載のホストデバイスにおいて、
前記サーバは、プロセスまたはリクエストを送信するプロセスのユーザ識別子を確認するようにさらに構成されるホストデバイス。
【請求項３５】
請求項２９記載のホストデバイスにおいて、
前記サーバは、前記サーバに関連付けられたバッファがフルではない場合のみ、前記リクエストに応答するようにさらに構成されるホストデバイス。
【請求項３６】
請求項３１記載のホストデバイスにおいて、
前記ホストアプリケーションは、データのユニバーサルリソース識別子（ＵＲＩ）を無作為化するように構成されるホストデバイス。
【請求項３７】
請求項２９記載のホストデバイスにおいて、
前記サーバは、
前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。
【請求項３８】
ストレージデバイスと連通状態になるためにホストデバイスのサーバを使用する方法であって、
ストレージデバイスと連通状態にあるホストデバイスのサーバにおいて、
前記ホストデバイスのホストアプリケーションからデータのリクエストを受信し、前記リクエストは前記ホストアプリケーションによって直接アクセス不能なデータ場所を含み、
前記ホストアプリケーションから受信された場所を書き換えられた場所に書き換え、
前記書き換えられた場所を含むリクエストをデータのストレージデバイスに送信し、
データを前記ストレージデバイスから受信し、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスはデータを含み、かつ
前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。
【請求項３９】
請求項３８記載の方法において、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含む方法。
【請求項４０】
請求項３９記載の方法において、
前記ホストアプリケーションから受信された場所は、ユニバーサルリソース識別子（ＵＲＩ）を含む方法。
【請求項４１】
請求項３８記載の方法において、
データは、前記ストレージデバイスのプライベートメモリエリアに格納される方法。
【請求項４２】
請求項３８記載の方法において、
前記サーバがリクエストを待ち受けるポートを無作為化することをさらに含む方法。
【請求項４３】
請求項３８記載の方法において、
プロセスまたはリクエストを送信するプロセスのユーザ識別子を確認することをさらに含む方法。
【請求項４４】
請求項３８記載の方法において、
前記サーバに関連付けられたバッファがフルではない場合のみ、前記リクエストに応答することをさらに含む方法。
【請求項４５】
請求項４０記載の方法において、
前記ホストアプリケーションは、データのユニバーサルリソース識別子（ＵＲＩ）を無作為化するように構成される方法。
【請求項４６】
請求項３８記載の方法において、
前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信することをさらに含む方法。
【請求項４７】
ホストデバイスであって、
ストレージデバイスと連通状態になるように構成されたインターフェイスと、
ホストアプリケーションと、
前記ホストアプリケーションおよび前記インターフェイスと連通状態にあるサーバであって、
符号化され、前記ホストアプリケーションによって直接アクセス不能なデータのリクエストを前記ホストアプリケーションから受信し、
データのリクエストを前記ストレージデバイスに送信し、
前記ストレージデバイスからデータを受信し、
前記ホストアプリケーションによってアクセス可能な形式にデータを変換し、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスは変換されたデータを含み、
前記ホストアプリケーションに前記レスポンスを送信するように構成されたサーバと、を備えるホストデバイス。
【請求項４８】
請求項４７記載のホストデバイスにおいて、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含むホストデバイス。
【請求項４９】
請求項４７記載のホストデバイスにおいて、
符号化されたデータは暗号化され、データを変換することはデータを解読することを含むホストデバイス。
【請求項５０】
請求項４７記載のホストデバイスにおいて、
符号化されたデータは、前記ストレージデバイスのパブリックメモリエリアに格納されるホストデバイス。
【請求項５１】
請求項４７記載のホストデバイスにおいて、
前記サーバは、
前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成されるホストデバイス。
【請求項５２】
ストレージデバイスと連通状態になるためにホストデバイスのサーバを使用する方法であって、
ストレージデバイスと連通状態にあるホストデバイスのサーバにおいて、
符号化され、前記ホストアプリケーションによって直接アクセス不能なデータのリクエストを前記ホストアプリケーションから受信し、
データのリクエストを前記ストレージデバイスに送信し、
データを前記ストレージデバイスから受信し、
前記ホストアプリケーションによってアクセス可能な形式にデータを変換し、
前記ホストアプリケーションからのリクエストへのレスポンスを生成し、前記レスポンスは変換されたデータを含み、かつ
前記レスポンスを前記ホストアプリケーションに送信することを実行することを含む方法。
【請求項５３】
請求項５２記載の方法において、
前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバを含む方法。
【請求項５４】
請求項５２記載の方法において、
符号化されたデータは暗号化され、データを変換することはデータを解読することを含む方法。
【請求項５５】
請求項５２記載の方法において、
符号化されたデータは、前記ストレージデバイスのパブリックメモリエリアに格納される方法。
【請求項５６】
請求項５２記載の方法において、
前記ホストアプリケーションからのリクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられるかを決定し、かつ
前記リクエストが通常ユーザ許可に関連付けられることが決定される場合のみ、前記レスポンスを前記ホストアプリケーションに送信するようにさらに構成される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホストデバイスのキャッシュをバイパスすることで、ストレージデバイスの仮想ファイルにアクセスするホストデバイスおよび方法に関する。
【背景技術】
【０００２】
関連出願の相互参照
本願は、その全体が本願明細書において参照により援用されている、２０１０年５月２０日に出願された米国仮特許出願第６１／３４６，７９６号の利益を主張する２０１０年６月９日に出願された米国特許出願第１２／７９７，５１３号の一部継続出願である。
【０００３】
デジタル音声（例えば、音楽）および／または映像（例えば、映画）ファイルなどのコンテンツを格納するために、メモリカードなどのストレージデバイスが使用されることが多い。不正アクセスからコンテンツを保護するために、コンテンツは、認証されたホストしかアクセスできないストレージデバイスのプライベートメモリエリアに格納されうる。一般に、ホストは、認証を求めてストレージデバイスに証明書を与える。ホストが認証されれば、ストレージデバイスは、ホストがプライベートメモリエリアに格納されたコンテンツにアクセスするのを許容する。このセキュリティシステムにより、認証されていないホストは、プライベートメモリエリアに格納されたコンテンツにアクセスできなくなるが、認証されたホストがウイルスまたは他の悪意のあるソフトウェアに感染している場合に問題が起こりうる。この状況では、認証されたホストがプライベートメモリエリアへのアクセスが許容されると、ホストの悪意のあるソフトウェアがそのアクセスを利用して、プライベートメモリエリアに格納されたデータに無許可の行為を実行しうる。
【発明の概要】
【０００４】
本発明の実施形態は、特許請求の範囲によって規定され、この欄に記載されることは、特許請求の範囲に制限を及ぼすものとして解釈されるべきではない。
一例として、以下に記載する実施形態は、一般に、ホストデバイスと、ホストデバイスのキャッシュをバイパスすることで、ストレージデバイスの仮想ファイルにアクセスする方法とに関する。１つの実施形態において、パブリックメモリエリアおよびプライベートメモリエリアを有するストレージデバイスと通信するように構成されたインターフェイスがホストに設けられ、パブリックメモリエリアは、プライベートメモリエリアに格納されたコンテンツに関連付けられた仮想ファイルを格納する。ホストデバイスはまた、キャッシュと、ホストアプリケーションと、サーバと、を備える。サーバは、ホストアプリケーションから仮想ファイルのリクエストを受信し、仮想ファイルのリクエストをストレージデバイスに送信し、ストレージデバイスのプライベートメモリエリアから仮想ファイルに関連付けられたコンテンツを受信し、コンテンツはキャッシュをバイパスすることによって受信され、ホストアプリケーションからのリクエストへのレスポンスを生成し、レスポンスはコンテンツを含み、かつホストアプリケーションへのレスポンスを送信するように構成される。１つの実施形態において、サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバである。別の実施形態において、サーバは、リクエストが通常ユーザ許可またはスーパーユーザ許可に関連付けられているかを決定し、リクエストが通常ユーザ許可に関連付けられていることが決定される場合のみ、ホストアプリケーションにレスポンスを送信しうる。
他の実施形態が提供され、それらの実施形態の各々は、単独または組み合わせて使用されうる。以下、添付の図面を参照しながら、さまざまな実施形態について記載する。
【図面の簡単な説明】
【０００５】
【図１】一実施形態によるホストおよびストレージデバイスのブロック図である。
【図２】一実施形態によるホストおよびストレージデバイスのブロック図である。
【図３Ａ】一実施形態によるホストのブロック図である。
【図３Ｂ】一実施形態によるストレージデバイスのブロック図である。
【図４】ホストのキャッシュで起こりうる問題を示す、一実施形態によるホストおよびストレージデバイスのブロック図である。
【図５】ホストのキャッシュをバイパスすることによって、ストレージデバイスの仮想ファイルにアクセスされる一実施形態によるホストおよびストレージデバイスのブロック図である。
【発明を実施するための形態】
【０００６】
導入
以下の実施形態は、一般に、ストレージデバイスのプライベートメモリエリアにある複数の保護ファイルへのアクセスを与えるストレージデバイスのパブリックメモリエリアにある仮想ファイルに関し、より詳しく言えば、ホストデバイスのキャッシュをバイパスすることによって、仮想ファイルにアクセスするホストデバイスおよび方法に関する。一般に、ストレージデバイスのパブリックメモリエリアに格納された仮想ファイルは、ストレージデバイスのプライベートメモリエリアにある複数の保護ファイルへのゲートウェイとして作用する。ストレージデバイスは、ホストデバイスが仮想ファイルへのアクセスを試みていることを検出すると、複数の保護ファイルがあれば、どの保護ファイルがホストデバイスに提供されるべきかを決定する。このようにして、引き続き同じ仮想ファイルの読み取りを試みることで、ホストデバイスに異なるコンテンツが戻されうる。しかし、ホストデバイスが、以前に呼び出したデータを格納して性能を高めるためにキャッシュを使用する際、問題が起こりうる。詳しく言えば、仮想ファイルに対して引き続きリクエストが出されると、ホストデバイスは、仮想ファイルを静的ファイルとして見なすため、ストレージデバイスへアクセスする代わりに、単にキャッシュにアクセスすることになる。したがって、ストレージデバイスのプライベートメモリエリアに格納された複数の曲にアクセスするために仮想ファイルが使用されれば、ホストデバイスは、所望された異なる曲を再生する代わりに、仮想ファイルが読み出されるたびに同じ曲を再生してしまう。
この問題に対処する実施形態に進む前に、例示的な仮想ファイルの実施形態および例示的なストレージデバイスの概論を述べる。
【０００７】
例示的な仮想ファイルの実施形態
以下、図を参照すると、図１は、実施形態のストレージデバイス１００と連通状態にあるホスト（または「ホストデバイス」）５０のブロック図である。「連通状態」という用語は、本願明細書において使用される場合、コンポーネントが図に示されているかまたは本願明細書に記載されているかに関わらず、１つ以上のコンポーネントと直接的または間接的に連通状態にあることを意味する。ホスト５０は、専用コンテンツプレーヤ、移動携帯電話、パーソナルコンピュータ（ＰＣ）、ゲームデバイス、携帯用情報端末（ＰＤＡ）、キオスクおよびＴＶシステムなどの任意の適切な形態をとりうるが、これらに限定されるものではない。ストレージデバイス１００はまた、ハンドヘルド、取り外し可能なメモリカード（例えば、フラッシュストレージカード）、ユニバーサルシリアルバス（ＵＳＢ）デバイスおよびソリッドステートドライブなどの任意の適切な形態をとりうるが、これらに限定されるものではない。好ましくは、ストレージデバイス１００は、ホスト５０に取り外し可能に接続されるため、ユーザは、種々のホストでストレージデバイス１００を使用しうる。
【０００８】
図１に示すように、ストレージデバイス１００は、コントローラ１１０と、メモリ１２０とを備える。コントローラ１１０は、任意の適切な方法で実装されうる。例えば、コントローラ１１０は、マイクロプロセッサまたはプロセッサおよび（マイクロ）プロセッサによって実行可能なコンピュータ可読プログラムコード（例えば、ソフトウェアまたはファームウェア）を格納するコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックコントローラおよび埋め込みマイクロコントローラの形態をとりうる。コントローラの例は、以下のマイクロコントローラ、例えば、ＡＲＣ  ６２５Ｄ、Ａｔｍｅｌ  ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ  ＰＩＣ１８Ｆ２６Ｋ２０およびＳｉｌｉｃｏｎ  Ｌａｂｓ  Ｃ８０５１Ｆ３２０を含むが、これらに限定されるものではない。コントローラにおいて使用されうるさまざまなコンポーネントの例は、以下に記述する実施形態に記載され、関連する図に示される。また、コントローラ１１０は、メモリ制御論理の一部として実装されうる。
【０００９】
また、図１に示すように、ストレージデバイス１００は、任意の適切な形態をとりうるメモリ１２０を備える。１つの実施形態において、メモリ１２０は、ソリッドステート（例えば、フラッシュ）メモリの形態をとり、１回だけプログラム可能、数回プログラム可能または多数回プログラム可能なものでありうる。しかし、光学メモリおよび磁気メモリなどの他の形態のメモリも使用されうる。図１には単一のコンポーネントとして示されているが、コントローラ１１０および／またはメモリ１２０は、いくつかのコンポーネントとともに実装されうる。図１において、メモリ１２０は、パブリックメモリエリア１３０と、プライベートメモリエリア１４０とを備える。この実施形態において、パブリックおよびプライベートメモリエリア１３０、１４０は、単一のメモリデバイスの異なるパーティションであるが、他の実施形態において、パブリックおよびプライベートメモリエリア１３０、１４０は、異なるメモリデバイスである。パブリックメモリエリア１３０は、一般に、制限なしにアクセス可能であるが、プライベートメモリエリア１４０は、認証エンティティしかアクセスできず、典型的に、ホストには不可視である（例えば、隠しパーティション）。このように、プライベートメモリエリア１４０は、認証エンティティしかアクセスできない複数のコンテンツファイル（ここでは、ファイル１〜Ｎ）を格納するために使用されうる。「コンテンツファイル」は、デジタル映像（音声あり／なし）（例えば、映画、ＴＶ番組のエピソード、ニュース番組など）、音声（例えば、歌、ポッドキャスト、１つまたはひと続きのサウンド、オーディオブックなど）、静止画や動画（例えば、写真、コンピュータ生成ディスプレイなど）、テキスト（グラフィックスあり／なし）（例えば、記事、テキストファイルなど）、ビデオゲームや他のソフトウェアおよび２つ以上のこれらの形態のハイブリッドマルチメディアによる表現などの任意の適切な形態をとりうるが、これらの限定されるものではない。「コンテンツ」、「コンテンツファイル」および「ファイル」という用語は、本願明細書において相互交換可能に使用され、プライベートメモリエリア１４０に格納されたファイルは、「保護ファイル」と呼ばれる。
【００１０】
この実施形態において、パブリックメモリエリア１３０は、仮想ファイル１５０を含む。仮想ファイル１５０は、パブリックメモリエリア１３０のファイルアロケーションテーブル（ＦＡＴ）に割り当てられた論理ブロックアドレスとして存在するが、任意のデータを含まず、実際にはアクセス不能であるという意味で「仮想」である。仮想ファイル１５０に対してパブリックメモリエリア１３０に割り当てられた物理的な格納場所さえないこともある（しかし、以下に記述するように、いくつかの実施形態において、比較的少量の物理的な格納場所（例えば、１５ＭＢ）が、仮想ファイル１５０のパブリックメモリエリア１３０に割り当てられることもある）。しかし、仮想ファイル１５０が、パブリックメモリエリア１３０のＦＡＴテーブルに割り当てられた論理ブロックアドレスを有するため、仮想ファイル１５０は、ホスト５０に対して通常ファイルとして現れる。
【００１１】
この実施形態において、仮想ファイル１５０は、プライベートメモリエリア１４０の複数の保護ファイル１〜Ｎへのゲートウェイとして働く。すなわち、コントローラ１１０が、仮想ファイル１５０へのアクセスが試みられていることを認識すると（例えば、読み出しコマンドに指定された論理ブロックアドレスから）、コントローラ１１０は、仮想ファイル１５０へのアクセスをホスト５０に与える代わりに、特別な措置を講じる。例えば、コントローラ１１０が、仮想ファイル１５０へのアクセスを求めるリクエストをホスト５０から受信すると、コントローラ１１０は、プライベートメモリエリア１４０に格納された複数の保護ファイル１〜Ｎの１つを選択し、選択された保護ファイルへのアクセスをホスト５０に与えることによって、リクエストに応答しうる。後に同じ仮想ファイル１５０がアクセスされると、コントローラ１１０は、複数の保護ファイル１〜Ｎの異なるファイルを選択し、そのファイルへのアクセスを与えうる。例えば、仮想ファイル１５０が、「音声．ＭＰ３」という名前が付けられ、プライベートメモリエリア１４０に格納された２０曲のプレイリストに関連付けられているとすれば、ホスト５０が「音声．ＭＰ３」へのアクセスをリクエストするたびに、コントローラ１１０は、プレイリストにある別の曲を選択し、その曲へのアクセスを与えうる。
【００１２】
コントローラ１１０が仮想ファイル１５０へのホストリクエストを取り扱うことができるように、任意の適切な実施例が使用されうる。例えば、図２に示す１つの実施形態において、アプリケーション（またはカプレット１６０）が、コントローラ１１０がプライベートメモリエリア１４０の保護コンテンツを管理する方法を決めるルールセットを格納する（例えば、どの保護ファイルにいつアクセスするのか）。この実施形態において、カプレット１６０は、ハッカーがルールセットに不正変更を加えることができないように、プライベートメモリエリア１４０に格納される。コントローラ１１０は、仮想ファイル１５０へアクセスするようにホスト５０からのリクエストに反応する方法を決定するために、カプレット１６０にルールセットを使用する。プライベートメモリエリア１４０はまた、複数の保護ファイル１〜Ｎと仮想ファイル１５０とを関連付けるデータベース１７０を格納する。このようにして、データベース１７０は、複数の保護ファイル１〜Ｎのプレイリストとして作用する。１つの実施形態において、データベース１７０は、複数の保護ファイル１〜Ｎとともにストレージデバイス１００に予めロードされる。データベース１７０が暗号化されていれば、カプレット１６０は、データベース１７０を解読するためのキーを保有しうる。
【００１３】
動作中、ストレージデバイス１００が起動されると、カプレット１６０は、予めロードされたデータベース１７０に従って、ホスト５０による仮想ファイル１５０へのアクセスの試みを制御するように、コントローラ１１０をプログラムする。例えば、仮想ファイル１５０へのアクセスのリクエストに応答して、コントローラ１１０は、データベース１７０に基づいて、複数の保護ファイル１〜Ｎのうちの１つを選択し、そのファイルへのアクセスを与えうる。別の例として、コントローラ１１０は、ホスト５０が認証されているか、または認証されていないかを決定し、それに応じて、異なるタイプのコンテンツへのアクセスを与えうるが、このことは、ストレージデバイス１００が、認証されているホストかにかかわらず、種々のホストが使用可能なポータブルメモリカードであれば、望ましい場合もある。したがって、ホスト５０が認証プレーヤであれば、コントローラ１１０は、保護コンテンツへのアクセスを与えることによって、仮想ファイル１５０へアクセスするようにホスト５０からのリクエストに応答しうる。逆に、ホスト５０が認証プレーヤでなければ、コントローラ１１０は、代わりのファイルへのアクセスを与えることによって、ホストリクエストに応答しうる。このようにして、ルールセットは、ホスト５０へのアプリケーションが認証されれば、コントローラ１１０が保護ファイル（例えば、映画）へのアクセスを与えることを指定し、そうでなければ、コントローラ１１０は、パブリックまたはプライベートメモリエリア１３０、１４０に格納されてもよい代わりのファイル（例えば、映画の予告編）へのアクセスを与えうる。このようにして、仮想ファイル１５０へアクセスするための同様のホストリクエストは、ホスト５０が認証されたエンティティであるか、または認証されていないエンティティであるかに基づいて、コントローラ１１０によって別の方法での取り扱いが可能である（例えば、ユーザがログインしていないか、またはストレージデバイス１００によって認証されていなければ、ストレージデバイス１００が、専用のコマーシャルに戻しうる）。当然ながら、これは１つの例にすぎず、他のタイプのルールおよび条件も使用可能である。例えば、ファイルの選択は、時間、ユーザに関する情報、ホストによるストレージデバイス５０へのログイン状況および方法、または任意の他の適切な条件に基づくものでありうる。これらの例から分かるように、仮想ファイル１５０は、異なる状況において異なる方法で処理でき、プライベートメモリエリア１４０にある１つ以上の保護ファイルへのアクセスを与えるために、パブリックメモリエリア１３０にある単一の仮想ファイル１５０が使用されうる。
【００１４】
以下、図２を再び参照すると、この実施形態において、ホスト５０は、ホストアプリケーション６０と、メディアプレーヤ（ここでは、Ｊａｖａ（登録商標  以下同様）プレーヤ７０）とを実行する。ホストアプリケーション６０は、Ｊａｖａプレーヤ７０を制御するとともに、以下に記載するストレージデバイス１００のコントローラ１１０にさらなる命令を送信する。前述したように、この実施形態において、仮想ファイル１５０（例えば、「音声．ＭＰ３」という名前）は、プライベートメモリエリア１４０に格納された複数の保護ファイル１〜Ｎに関連付けられる。ホスト５０が、「音声．ＭＰ３」へのアクセスをリクエストするたびに、コントローラ１１０は、複数の保護ファイル１〜Ｎの異なるファイルを選択し、そのファイルへのアクセスを与えうる。この実施形態において、仮想ファイル１５０のサイズは、少なくとも、プライベートメモリエリア１４０の最大保護ファイルのサイズほどの大きさである。選択された保護コンテンツが、仮想ファイル１５０のサイズより小さければ、コントローラ１１０は、コンテンツを有効データでパディングするため、ホスト５０のＪａｖａプレーヤ７０が誤動作することはない。例えば、保護ファイルが音声ファイルであれば、コントローラ１１０は、実行中に、サイレントＭＰ３フレームや予測ヘッダ情報などの有効データで音声ファイルをパディングしうる。これは、異なるホストキャッシュアヘッド(host cash‐ahead)機構をサポート可能にするために行われる。コントローラ１１０がパディングデータを再生しないようにするために、コントローラ１１０は、ファイルの実際の再生長さをホスト５０に知らせ、ホスト５０は、パディングデータに達する前にファイルの再生を停止できる。
【００１５】
Ｊａｖａプレーヤ７０が、音声ファイルであると考えられる仮想ファイル１５０を読み出すためにＪＳＲ−１３５プロトコルを使用してストレージデバイス１１０にリクエストを送信する例を考慮する。ストレージデバイス１００のコントローラ１１０は、仮想ファイル１５０へのアクセスが試みられていることを検出し（例えば、リクエストに指定された論理ブロックアドレスから）、カプレット１６０のルールに基づいて、コントローラ１１０は、曲Ａを選択し、曲ＡへのアクセスをＪａｖａプレーヤ７０に与える。コントローラ１００はまた、前述したように、仮想ファイル１５０のサイズより小さいものでありうる曲Ａの実際のサイズをホストアプリケーション６０に知らせる。ホストアプリケーション６０は、再生をモニタし、曲Ａが完了すると、ホストアプリケーション６０は、ＪＳＲ−７５プロトコルを介して、ストリーミングデータを停止し、次の曲へスキップするように、コントローラ１１０へコマンドを送信する。（ＪＳＲ−１３５プロトコルは、このタイプのコマンドをサポートしていない）。このコマンドに応答して、コントローラ１１０は、次の曲（曲Ｂ）を指し示すようにデータベース１７０を更新する。ホストアプリケーション６０は、仮想ファイル１５０へのアクセスを再度リクエストするようにＪａｖａプレーヤ７０に命令を出す。しかし、このとき、コントローラ１１０は、曲Ｂ（曲Ａではない）を選択し、曲ＢへのアクセスをＪａｖａプレーヤ７０に与える。次に、前述したプロセスは、Ｊａｖａプレーヤ７０が追加の曲の再生をリクエストし続けると、繰り返される。
【００１６】
これらの実施形態とともに使用可能な代替例は数多くある。例えば、１つの実施形態において、ストレージデバイス１００は、ストレージデバイス１００が予めロードされた保護ファイルの位置を特定し、そのファイルにアクセスする時間を最小限に抑え、予めロードされた保護ファイル（例えば、トラック名、アーティスト名、アルバム名、トラック時間など）の詳細を抽出する時間を最小限に抑えるために、予めロードされた保護ファイルを再生するために「専用ファイルシステム」を使用する。このようにして、保護ファイルへゲートウェイの機能性を与える際に伴うコントローラ１１０のオーバーヘッドにかかわらず、仮想ファイル１５０にアクセスする時間は、別のタイプのファイルにアクセスする時間とほぼ同じである。この専用ファイルシステムを実行するために、保護ファイルは、連続的な論理ブロックアドレス（ＬＢＡ）の順序でプライベートメモリエリア１４０内に予めロードされうる。次に、ファイル持続時間などの任意の他の関連データとともに、各保護ファイルの正確な開始ＬＢＡを指定するために、テーブルは生産中に構築されうる。このようなテーブルの読み出しは、必要な情報を集めるためにファイルを開くより高速であるため、この専用ファイルシステムの使用により、レスポンス時間が高速化する。
【００１７】
前の記載から理解できるように、「専用ファイルシステム」は、予めロードされた異なるコンテンツの位置を特定しアクセスするために要求される時間量を短縮するために使用されうる。これは、再生に必要なデータのみを特定の方法で保存するための専用構造（例えば、テーブル）を規定することによって行われうる。このデータは、製品固有の要求（例えば、トラック名、アーティスト名、アルバム名、トラック時間など）に従って、異なる製品間で変更可能である。このデータ構造は、連続的なＬＢＡの順番で、以前に指定された他のデータとともに各ファイルの正確な開始ＬＢＡにおいて位置が特定されたデータを保有するテーブルを用いて、ストレージデバイス１００における安全な場所に予めロードされうる。テーブルのすべての入力は、テーブルの入力キーを使用して識別されうる特定のファイルを表しうる。特定のファイルへのアクセスのリクエストがあると、そのファイルのテーブルでの位置が特定され、関連するデータが呼び出される。例えば、仮想ファイル１５０を使用した最初から曲を再生するには、ファイルの開始ＬＢＡ、実際の持続時間、表示されるアルバム名の知識が要求されうる。このようなファイルの取り扱い方法において、ファイルの位置の特定および再生に要する時間は、ＦＡＴテーブルの取り扱いおよびファイルコンテンツの解析に必要な時間と比べると、著しく短縮される。
【００１８】
レスポンス時間を高速化する別の代替例として、ストレージデバイス１００は、「複合コマンド」の使用をサポートしうる。複合コマンドは、例えば、仮想ファイル状態および再生中の歌の両方の変更など、再生システムの異なる態様を制御する２つ以上のコマンドを組み込む単一のコマンドである。複合コマンドの使用は、特に、高速レスポンス時間の望まれる音声ストリーミングなどの環境において望ましい。例えば、複合コマンドは、「チャンネルをスキップ」および「２曲先にスキップ」または「曲をスキップして一時停止」を指定しうる。多くの状況において、いくつかのモード変更は、同時に起こることが必要な場合もある。例えば、「曲を再生して一時停止モードにし、次の歌にスキップする」シーケンスでは、スキップが起こったすぐ後に次の曲を開始することが要求されることもある。この場合、２つのコマンドは、この変更が行われるように、バス上で送信される必要がある。別の例において、システムの異なる態様は、仮想ファイル状態および再生中の曲の両方を変更する場合など、同時に制御されることが必要な場合もある。この場合も、考慮すべき点は、ストレージデバイス１００の状態変更の取り扱いに必要な時間量、およびホスト５０とストレージデバイス１０との間でコマンドのやりとりをする時間量を短縮することである。
【００１９】
さらなる別の代替例において、仮想ファイル１５０に対してパブリックメモリエリア１３０に実際のメモリを割り当てる代わりに、パブリックメモリエリア１３０が拡張ストレージエリアとしてホスト５０にエミュレートすることによって、メモリ消費は低減されうるため、拡張（エミュレートされた）ストレージエリアへのホストリクエストは、ストレージデバイスのプライベートメモリエリア１４０へのホストリクエストであるかのように、コントローラ１１０によって取り扱われる。その結果、仮想ファイル１５０は、パブリックメモリエリア１３０の実メモリを消費しない。これにより、貴重なメモリを消費することなく、大きなファイル（例えば、映画）を格納できる。例えば、仮想ファイル１５０が１５ＭＢで、パブリックメモリエリア１３０が３０ＭＢの状況を考えてみる。前述した技術を使用すると、ストレージデバイス１００は、３０ＭＢが物理アドレスにマッピングされ、１５ＭＢはマッピングされない４５ＭＢのパブリックメモリエリア１３０を有するものとして識別しうる。
【００２０】
前述した例は、ストレージデバイスの保護ファイルの読み出しに関するが、別の実施形態において、仮想ファイル１５０は、ホスト５０が認証されていれば、プライベートメモリエリア１４０に新しいコンテンツを追加するために使用される。例えば、ユーザが曲を購入するとき、ホストアプリケーション６０は、空いた空間に新しいコンテンツを追加し、その後、仮想ファイル１５０を使用して、新しい曲のデータをプライベートメモリエリア１４０に書き込むようにプライベートメモリエリア１４０を制御できる。別の例において、格納されたコマーシャルが、新しいコマーシャルに更新されうる。これは、仮想ファイル１５０をこのプライベートファイルにリンクした後、仮想ファイル１５０への書き込みによってコンテンツを変更することで達成されうる。ストレージデバイス１００は、書き込みコマンドを遮断し、書き込み動作をプライベートメモリエリア１４０の正確な位置に通す。これにより、プライベートメモリエリア１４０を更新し、更新されたコンテンツおよび購入したコンテンツを安全な方法で保有できる。
【００２１】
さらなる代替例は、コピープロテクト機構に関する。仮想ファイル１５０が、パブリックメモリエリア１３０においてアクセス可能であるため、仮想ファイル１５０は、任意のホストから単純なコピーコマンドで簡単にコピーされうる。以下の代替例は、仮想ファイル１５０のコピーを防止するために使用されうることで、プライベートメモリエリア１４０に格納された保護コンテンツへのアクセスが、コンテンツへのアクセスが許容された認証エンティティにのみ与えられる。このようにされなければ、ホスト５０は、仮想ファイル１５０をパブリックメモリエリア１３０の別のアドレスレンジに単にコピーして、保護コンテンツに自由にアクセスできることになる。
【００２２】
１つの例示的なコピープロテクト機構は、仮想ファイル１５０の読み出し動作によってストレージデバイス１００から送信された保護コンテンツを暗号化するために暗号化スキームを使用する。これは、ホストアプリケーション６０とストレージデバイス１００との間に認証プロセスが適用されるたびに更新されるセッションキーを使用して行われうる（例えば、ログイン中）。このセッションキーは、ホスト５０およびストレージデバイス１００の両方に知られているため、ストレージデバイス１００は、保護コンテンツを暗号化するためにセッションキーを使用でき、ホスト５０は、保護コンテンツを解読するためにセッションキーを使用できる。このようにしてセッションキーを使用すると、ストレージデバイス１００とホストアプリケーション６０との間のチャンネルが安全なものになる。
【００２３】
別の例示的なコピープロテクト機構は、ホスト５０によって読み出されたセクタをカウントするために、ストレージデバイス１００においてカウンタを使用する。カウンタがゼロに達すると、ストレージデバイス１００は、無音のバッファの送信を開始しうる。ホスト５０は、適切な認証後、カウンタを増やすように再生時間にわたってストレージデバイス１００に命令しうる。カウンタの設定のこの動作は、ファイルの読み出し中に行われうる（例えば、歌の再生中）。ファイルのコピーが試みられる場合、ストレージデバイス１００は、その試みを検出し、無効データをホスト５０に戻し始めうる。これにより、ハッカーは、カウンタを増やすことなく、ある容量の歌（例えば、５ＭＢの歌の１ＭＢ分の音声）しか呼び出すことができないため、歌のコピーが防止される。
【００２４】
さらなる別の例示的なコピープロテクト機構において、データレート制御（「ＤＲＣ」）は、ホスト５０から仮想ファイル１５０への読み出し動作のパターンを考察した後、ストレージデバイス１００によって実行される。これらの読み出し動作が予測通りに起こらなければ（例えば、ストレージデバイス１００が、仮想ファイル１５０のコピーが高速かつ迅速なファイルアクセスにより起こっていることを検出すれば）、ストレージデバイス１００は、無効データを戻すか、または読み出しプロセスを失敗させる。このようにして、ストレージデバイス１００は、ストレージデバイス１００から読み出された保護ファイルにデータレート制御を実行する。ホスト５０は、ストレージデバイス１００への適切な認証を有した後、現行のホスト５０の固有の特性を適合するようにストレージデバイスＤＲＣ機構を構成可能であってもよい。
【００２５】
また、「スライドウィンドウ」は、例示的なコピープロテクトスキームとしても使用されうる。この機構を用いて、ストレージデバイス１００により、ホスト５０は、特定のＬＢＡレンジ内のみ実データを読み出すことができる。このＬＢＡレンジ外のデータへアクセスすると、無音のバッファが戻される。ホスト５０は、適切な認証後、許容レンジを再構築しうる。許容レンジが動くため、許容レンジは、本願明細書において、「スライドウィンドウ」と呼ばれる。前述したカウンタの概念は、スライドウィンドウとして使用でき（例えば、現在のところ、１〜５００のコピー）、またはデータの再生が仮想ファイル１５０内の特定の場所からのみ許容されうる。
【００２６】
さらなる別の実施形態において、仮想ファイル１５０は、ネイティブメディアプレーヤから再生するために使用されうる。これは、コンテンツの各プレイリストに対して比較的大きな仮想ファイルを使用することによって行われうる。この仮想ファイルは、実行中に曲から曲へと継続的に接続しうる。ストレージデバイス１００はまた、ホストネイティブプレーヤに表示されるコンテンツの各チャンネルにＩＤ３タグを与えうる。このようにして、ストレージデバイス１００は、各ホスト（例えば、ハンドセット）または利用可能なオペレーティングシステム上で使用されうる。この解決策は、曲をスキップしようとする試みを検知する方法（例えば、ユーザが、早送り／巻き戻し／再生バーの操作を行おうとするときを検出することで）をストレージデバイスに許容することによって高められうる。
【００２７】
例示的なストレージデバイス
前述したように、これらの実施形態のストレージデバイスは、任意の適切な方法で実施されうる。以下の段落および参照する図は、１つの例示的な実施例を記載したものである。この実施例は、一例にすぎず、図に示すとともに本願明細書に記載される詳細は、本願明細書に明確な言及がない限り、特許請求の範囲に読み込まれるべきものではないことを理解すべきである。
【００２８】
図に戻ると、図３Ａおよび図３Ｂは、実施形態のストレージデバイス３００およびホスト３５０のブロック図である。最初に、図３Ｂから参照すると、ストレージデバイス３００は、コントローラ３１０と、メモリ３２０とを備える。コントローラ３１０は、メモリ３２０とのインターフェイスとなるメモリインターフェイス３１１と、ホスト３５０とのインターフェイスとなるホストインターフェイス３１２とを備える。コントローラ３１０はまた、中央演算処理装置（ＣＰＵ）３１３と、暗号および／または解読演算を与えるように動作する暗号エンジン３１４、リードアクセスメモリ（ＲＡＭ）３１５と、ストレージデバイス３００の基本演算用のファームウェア（論理）を格納する読み出し専用メモリ（ＲＯＭ）３１６と、暗号／解読演算用に使用されるデバイス特有のキーを格納する不揮発性メモリ（ＮＶＭ）３１７とを備える。ストレージデバイス特有のキーは、ストレージデバイス内の他のメモリエリアに格納されうることに留意すべきである。図３Ｂに示すコンポーネントは、任意の適切な方法で実装されうる。
【００２９】
この実施形態において、メモリ３２０は、ホスト３５０にファイルシステムによって管理されるパブリックパーティション３２５と、コントローラ３１０によって内部管理される隠し保護システムエリア３３５とを備える。隠し保護システムエリア３３５は、前述したように、コンテンツ暗号キー（ＣＥＫ）３４０と、コンテンツと、データベースと、カプレット３４２とを格納する。隠し保護システムエリア３３５は、コントローラ３１０（ホストコントローラ３６０ではなく）によって内部管理されるために「隠され」ており、このエリア３３５に格納されたオブジェクトが、コントローラ３１０の不揮発性メモリ３１７に格納された固有のキーで暗号化されるため、「保護」される。（ストレージデバイスハードウェアの固有のキーは、コントローラ３１０の不揮発性メモリ３１７またはストレージデバイス３００内の他のエリアに格納されうる）。したがって、このエリア３３５に格納されたオブジェクトにアクセスするために、コントローラ３１０は、暗号エンジン３１４および不揮発性メモリ３１７に格納されたキーを使用して、暗号化されたオブジェクトを解読する。ストレージデバイス３００は、サンディスク  コーポレイションによるＴｒｕｓｔｅｄＦｌａｓｈ（登録商標）プラットフォームに構築された製品群からセキュアプロダクトの形態をとることが好ましい。パブリックパーティション３２５は、仮想ファイル３３０を含む。
【００３０】
以下、図３Ａのホスト３５０を参照すると、ホスト３５０は、ストレージデバイス３００とのインターフェイスとなるストレージデバイスインターフェイス３６１を有するコントローラ３６０を備える。コントローラ３６０はまた、中央演算処理装置（ＣＰＵ）３６３と、暗号および／または解読演算を与えるように動作する暗号エンジン３６４、リードアクセスメモリ（ＲＡＭ）３６５と、読み出し専用メモリ（ＲＯＭ）３６６とを備える。ボックス３６０内の各コンポーネントは、全ホストシステムにおいて別のチップとして実装されうることに留意すべきである。ホスト３５０はまた、コンテンツエンジン３７１と、ファイルシステムＡＰＩ３７２と、コンテンツデコーダＡＰＩ３７３と、ホスト証明書３７４とを備えるアプリケーション３７０を備える。
【００３１】
ストレージデバイス３００およびホスト３５０は、ストレージデバイスインターフェイス３６１およびホストインターフェイス３１２を介して互いに連通状態にある。安全なデータ転送を伴う動作のために、ストレージデバイス３００およびホスト３５０の暗号エンジン３１４、３６４が、互いに相互に認証し、キー交換を行うために使用されることが好ましい。相互認証プロセスは、固有の証明ＩＤを交換するために、ホスト３５０およびストレージデバイス３００を必要とする。相互認証の完了後、ストレージデバイス３００とホスト３５０との間に安全な通信チャンネルを確立するためにセッションキーが使用されることが好ましい。
【００３２】
ホストデバイスのキャッシュのバイパスに関する実施形態
再度図を参照すると、図４は、実施形態のホストデバイス４００およびストレージデバイス４１０のブロック図である。ホストデバイス４００は、ストレージデバイス４１０、ホストアプリケーション４３０（例えば、メディアプレーヤ）およびキャッシュ４４０と連通状態になるように構成されたインターフェイス４２０を備える。ストレージデバイス４１０（例えば、ＳＤカード）は、インターフェイス（図示せず）と、コンテンツを格納するプライベートメモリエリア４５０と、プライベートメモリエリア４５０に格納されたコンテンツに関連付けられる仮想ファイル４７０を格納するパブリックメモリエリア４６０と、カプレット４８０とを備える。前述したように、パブリックメモリエリア４６０の仮想ファイル４７０は、プライベートメモリエリア４５０に格納されたセキュアコンテンツへのアクセスを与え、カプレット４８０は、セキュアデータへアクセスし、ホストデバイス４００へ流すための所定のルールセットを強化する。
【００３３】
しかし、ホストアプリケーション４３０が、ストレージデバイス４１０からファイルを読み出すときに性能を高めようとキャッシュ４４０を使用するとき、問題が起こりうる。詳細に言えば、ホストアプリケーション４３０が、以前に仮想ファイル４７０を読み出していれば、呼び出されたコンテンツは、ホストデバイスのキャッシュ４４０に格納される。ホストアプリケーション４３０が、ストレージデバイス４１０の仮想ファイル４７０にアクセスする代わりに、仮想ファイル４７０を再度読み出そうとする場合、ホストアプリケーション４３０は、データが静的であると見なすため、キャッシュ４４０に格納されたデータにアクセスするのみである。しかし、その後、仮想ファイル４７０を読み出そうとすると、ストレージデバイス４１０から異なるコンテンツが読み出されることがあるため、この状況でキャッシュ４４０を使用すると、ホストアプリケーション４３０に無効または不正確なデータが戻されることになる。例えば、プライベートメモリエリア４５０に格納された複数の曲にアクセスするために仮想ファイル４７０が使用されれば、ホストアプリケーション４３０は、仮想ファイルが読み出されるたびに、所望された異なる曲を再生する代わりに同じ曲を再生する。
【００３４】
図５に示すホストデバイス５００は、ホストデバイス５００によってファイルがキャッシュに入れられないようにすることによって、仮想ファイルから読み出されたデータが有効になるようにすることで、この問題を解消するために使用されうる。また、図４のホストデバイス４００のように、図５のホストデバイス５００は、インターフェイス５２０と、ホストアプリケーション５３０と、キャッシュ５４０とを備える。同様に、この実施形態におけるストレージデバイス５１０は、コンテンツを格納するプライベートメモリエリア５５０と、プライベートメモリエリア５５０に格納されたコンテンツに関連付けられた仮想ファイル５７０を格納するパブリックメモリエリア５６０と、カプレット５８０とを備える。しかし、この実施形態において、ホストデバイス５００はまた、サーバ５９０を備える。任意のタイプのサーバが使用されうるが、この実施形態では、サーバ５９０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバの形態をとる。この実施形態において、ホストアプリケーション５３０と一体化され、ホストデバイス５００で実行されるサーバ５９０は、ストレージデバイス５１０に格納された仮想ファイルを管理する役割を担う。この実施形態において、サーバ５９０は、ホストアプリケーション５３０の一体部品としてホストデバイス５００のスレッドとして実行され、ホストアプリケーション５３０が閉じると終了される。
【００３５】
一般に、サーバ５９０は、ホストアプリケーション５３０からの仮想ファイル５７０のリクエストを受信し、仮想ファイル５７０に対してストレージデバイス５１０にリクエストを送信し、ストレージデバイス５１０のプライベートメモリエリア５５０から仮想ファイル５７０に関連付けられたコンテンツを受信し、コンテンツを含むホストアプリケーション５３０からのリクエストへのレスポンスを生成し、キャッシュ５４０をバイパスしながら、ホストアプリケーション５３０へレスポンスを送信する。このサーバとクライアントとの相互作用はキャッシュ５４０をバイパスするため、この実施形態では、キャッシュ５４０から不正コンテンツが読み出される状況が回避される。
【００３６】
ストレージデバイス５１０のパブリックメモリエリア５６０に格納された各仮想ファイルに対して、ＨＴＴＰサーバ５９０を使用する特定の実施例において、ＨＴＴＰサーバ５９０は、特定のＵＲＬ（例えば、http://localhost:8000/vfile.mp3 ）をホストする。ＵＲＬのファイルパスは純粋に記号的なものであり、サーバ５９０は、ＵＲＬで指定されたファイルからストレージデバイス５１０のパブリックメモリエリア５６０に位置する特定の仮想ファイルへのマッピングを保有する。したがって、ＨＴＴＰサーバ５９０は、ホストアプリケーション５３０から仮想ファイルのＵＲＬを受信すると、受信したＵＲＬを、ストレージデバイス５１０のパブリックメモリエリア５６０にある仮想ファイル５７０のアドレスに書き換える。サーバ上のリモートファイルへのアクセス（「ＨＴＴＰ  Ｇｅｔ」リクエスト）が、ストレージデバイス１０上の仮想ファイル５７０の読み出しリクエストと同等のものである。
【００３７】
ホストデバイス５００が、リクエストされたリモートファイルがＨＴＴＰサーバ５９０にリモート格納され、ホストデバイス５００にローカル格納されていないのを把握しているため、ホストデバイス５００は、ファイルのデータをキャッシュしない。したがって、ファイルへの各アクセスには、「ＨＴＴＰ  Ｇｅｔ」リクエストを送信し、ＨＴＴＰレスポンスを解析することによって、ＨＴＴＰサーバ５９０からファイルのデータを読み出す必要がある。これにより、仮想ファイル５７０に関連付けられたデータを読み出すためには、ストレージデバイス５１０がアクセスされなければならなくなる。以下は１つの例示的な流れであるが、任意の適切な流れが使用されうる。第１に、ホストアプリケーション５３０が開始され、専用スレッドが開かれ、ＨＴＴＰサーバ５９０として作用する。ＨＴＴＰサーバスレッドは、サーバソケットを作り、入力ＨＴＴＰリクエストを待機する。ホストアプリケーション５３０が、仮想ファイル５７０のコンテンツを読み出そうとすると、仮想ファイル５７０のＵＲＬを指定する「ＨＴＴＰ  Ｇｅｔ」リクエストをＨＴＴＰサーバ５９０に送信する。「ＨＴＴＰ  Ｇｅｔ」リクエストは、ＨＴＴＰサーバ５９０によって受信される。随意に、ＨＴＴＰサーバ５９０は、プロセスまたはユーザ識別子または何らかの他のタイプの識別子をチェックすることによって、リクエストを送信するプロセスを有効化しうる。例えば、ＨＴＴＰサーバ５９０は、仮想ファイル５７０のコンテンツを読み出すためのアクセス許可を有するプロセスのテーブルもしくはツリー、またはユーザ識別子を格納しうる。プロセスまたはユーザ識別子が、仮想ファイル５７０のコンテンツを読み出すアクセス許可を有していなければ（例えば、プロセスまたは識別子が、テーブルまたはツリーにリストされていないため）、ＨＴＴＰサーバ５９０は、エラーレスポンスを戻しうる。しかし、プロセスまたはユーザ識別子がテーブルまたはツリーにリストされていれば、仮想ファイルのコンテンツを読み出すアクセス許可があり、ＨＴＴＰサーバ５９０は、読み出すために仮想ファイル５７０を開くために、ストレージデバイス５１０の専用アクセス制御記録（この場合、カプレット５８０）にログインする。（１つの好ましい実施形態において、アクセス制御記録は、サンディスク  コーポレイションからのＴｒｕｓｔｅｄＦｌａｓｈ（登録商標）ストレージデバイスにおいて使用されるタイプのものであるが、他のタイプのアクセス制御記録も使用されうる）。好ましくは、仮想ファイル５７０の真のコンテンツを受信するために、アクセス制御記録はログインされなければならない。仮想ファイル５７０のコンテンツを読み出しながら、アクセス制御記録がログインされない場合、無効データが戻されることが好ましい。
【００３８】
アクセス制御記録へログインするために、ホストデバイス５００は、ストレージデバイス５１０に対して認証を行う。１つの実施形態において、認証プロセスには３段階ある。すなわち、パブリックキー確認段階、プライベートキー確認段階およびセッションキー承諾段階である。パブリックキー確認段階の間、ホストデバイス５００は、ストレージデバイス５１０に証明書チェーンを送信するため、ストレージデバイス５１０は、ルート証明書に位置するルート証明書認可パブリックキーを使用して、証明書およびパブリックキーの真実性を確認できる。パブリックキー確認段階を無事通過すれば、プライベートキー確認段階が実行される。プライベートキー確認段階中、ストレージデバイス５１０は乱数を生成し、チャレンジとしてホストデバイス５００に乱数を送信する。ホストデバイス５００は、ストレージデバイス５１０のプライベートキーを使用してストレージデバイスの乱数にサインし、チャレンジへのレスポンスとしてサイン済みの乱数を送信する。このレスポンスは、ストレージデバイスのパブリックキーを使用して解読され、乱数と比較される。解読されたレスポンスが乱数と整合すれば、チャレンジのレスポンスは成功である。相互認証が実行されれば、ストレージデバイス５１０に対して同じプロセスが生じる。
【００３９】
プライベートキー確認段階を無事通過すれば、セッションキー承諾段階が実行される。セッションキー承諾段階中、乱数はホストデバイスのパブリックキーを使用して暗号化される。この乱数は、セッションキーになる。ホストデバイス５００は、ストレージデバイス５１０から暗号化された乱数を解読するために、プライベートキーを使用してセッションキーを得ることができる。ホストデバイス５００側でも同じプロセスが生じる。セッションキーを用いて、ホストデバイス５００とストレージデバイス５１０との間のセキュア通信が開始されうる。
【００４０】
ホストデバイス５００が、ストレージデバイス５１０のアクセス制御記録にログインした後、ストレージデバイス５１０は、ホストデバイス５００が、プライベートメモリエリア５５０から仮想ファイルの真のコンテンツへアクセスする許可を有しているかを決定しうる。１つの実施形態において、アクセス制御記録は、アクセス制御記録へのログインが成功したエンティティに与えられる権利（例えば、読み出しのみ、書き込みのみ、読み出しおよび書き込みアクセスなど）を示す許可制御記録を含む。したがって、ホストデバイス５００がアクセス制御記録にログインした後、ストレージデバイス５１０は、ホストデバイス５００が仮想ファイルの真のコンテンツにアクセスする許可を有するかを決定するために、許可制御記録を使用しうる。ホストデバイス５００が許可を有していれば、ホストデバイス５００に真のコンテンツが戻される。そうでなければ、データも無効データも戻されない。
【００４１】
前述した記載から分かるように、仮想ファイルの真のコンテンツがホストアプリケーション５３０に戻される前に、２回の「許可チェック」が実行されうる。１回目は、ホストアプリケーション５３０がホストアプリケーション５３０のプロセスまたはユーザ識別子を確認することによって、仮想ファイル５７０のコンテンツを読み出す許可を有するかどうかをＨＴＴＰサーバ５９０が決定しうる。２回目は、ホストデバイス５００がストレージデバイス５１０のアクセス制御記録にログインした後、アクセス制御記録の許可制御記録がホストデバイス５００が仮想ファイル５７０のコンテンツへアクセスする許可を有することを示すかどうかを、ストレージデバイス５１０が決定しうる。これらの許可チェックの一方または両方が、セキュリティ上の理由から好ましいものでありうるが、これらの許可チェックの使用は選択できるものであることに留意すべきである。
【００４２】
ホストデバイスのキャッシュ５４０をバイパスするために、ＨＴＴＰサーバ５９０は、キャッシュ５４０をバイパスするためにホストデバイスのオペレーティングシステムに命令を送りうる。１つの実施形態において、この命令は、Ｏ＿ＤＩＲＥＣＴフラグを含み、このフラグは、ファイルからの各読み出し演算が、ホストデバイスのキャッシュ５４０をバイパスし、ストレージデバイス５１０に向けられることを示す特別なフラグである。この命令により、ホストデバイス５００が、仮想ファイルに関連付けられたコンテンツを求めるＨＴＴＰサーバのリクエストに対して、ストレージデバイス５１０からのレスポンスを受信するため、オペレーティングシステムは、ＨＴＴＰサーバ５９０にストレージデバイスからのレスポンスを、キャッシュ５４０に格納することなく送信する。ＨＴＴＰサーバ５９０が、Ｏ＿ＤＩＲＥＣＴフラグを使用して仮想ファイル５７０を開き、仮想ファイル５７０のコンテンツを読み出した後、ＨＴＴＰサーバ５９０は、仮想ファイル５７０に関連付けられたプライベートメモリエリア５５０からのデータを含むＨＴＴＰレスポンスを生成する。次に、ホストアプリケーション５３０が、ＨＴＴＰサーバ５９０からレスポンスを受信し、仮想ファイル５７０のデータを解析する。この方法を用いて、仮想ファイル５７０から読み出されたデータは、キャッシュ５４０に格納された不正データの可能性のあるものの代わりに、ストレージデバイス５１０に格納されているファイルの実データである。これにより、ホストキャッシュ機構をバイパスし、ファイル５７０へのアクセスをモニタしながら、仮想ファイル５７０からデータを読み出すための単純かつ簡単な機構が得られる。
【００４３】
これらの実施形態とともに使用されうるいくつかの代替例がある。例えば、ホストデバイスのキャッシュをバイパスするためにサーバおよびコマンドを使用する代わりに、ホストは、仮想ファイルを読み出す試みがなされると、大量のデータ（すなわち、キャッシュに格納されているデータより多い量）を読み出すようにプログラムされうる。読み出しリクエストが、キャッシュに格納されたものより多いデータに対するものであるため、このような読み出しリクエストは、ホストキャッシュを効果的に無効化し、ストレージデバイスから仮想ファイルのデータをホストに直接獲得させる。別の代替例として、前述した実施形態は、既存のコマンド（ＴｒｕｓｔｅｄＦｌａｓｈ（登録商標）ストレージデバイスとともに使用されるものなど）で直接動くように修正されうるため、仮想ファイルの使用は回避されうる。この代替例において、ＨＴＴＰサーバは、ストレージデバイスとのセキュアセッションを作り、隠しパーティションへのストリームを作り、ストレージデバイスのプライベートメモリエリアから暗号化されたコンテンツを抽出するように読み出しストリーム演算を使用し、暗号化されたコンテンツを解読することによって、ストレージデバイスのプライベートメモリエリアからセキュアコンテンツを得ることができる。
【００４４】
前述した実施形態のいくつかは、ホストデバイスのキャッシュをバイパスするためにホストデバイスのサーバを使用しているが、より一般的には、ホストデバイスのサーバは、ユーザアプリケーションが再生エンジンへの入力を含むように許可しないオペレーティングシステムで、特定のファイルシステムコールシーケンスへの再生の依存性をバイパスするために、ホストデバイスのサーバが使用されうることに留意すべきである。詳細には、サーバは、ホストアプリケーションから受信した任意のユニバーサルリソース識別子（ＵＲＩ）をコンテンツに分けうるが、このように分けなければ、ホストアプリケーションはコンテンツを入手できない。次に、サーバは、ストレージデバイスから受信したコンテンツをホストアプリケーションの再生エンジンに流すことができ、この再生エンジンは、ネットワークストリーミングを実行し、ファイルアクセスを指示するようにのみ動作するものであってもよい。（データは符号化（例えば、暗号化）されうるが、この場合、サーバは、ストリーミングプロセス中に該当データを変換しうる（例えば、解読））。動作中、サーバ（例えば、ＨＴＴＰサーバ）は、ホストアプリケーションが直接的にアクセスできない場所のデータ（例えば、ＵＲＩ）を受信した後、その場所を書き換えて書き換えられた場所にする。次に、サーバは、書き換えられたアドレスを使用してストレージデバイスから（例えば、ストレージデバイスのプライベートパーティションから）データを呼び出し、その後、そのデータをホストアプリケーションに与える。
【００４５】
さらに、網羅的なリストではないが、以下の特徴は、前述した実施形態の任意のもののサーバに実装されうる。
１．ポートの無作為化：サーバが待ち受けるポートは無作為であり、例えば、ストリームが変更されるたびに変更されうる。
２．呼び出しプロセスまたはユーザ識別子チェック：ソケット接続プロセス識別子（ＰＩＤ）は、（ａ）メディアサーバプロセスからのもの、および（ｂ）インストール可能なアプリケーションからのものではないユーザ識別子（ＵＩＤ）を有することを確実にするためにチェックされうる。
３．バッファ進行整合：再生中、ＨＴＴＰサーバからのリクエストに対してバッファが整合され、バッファがフルであれば、リクエストは出されない。
４．ユニフォームリソース識別子（ＵＰＩ）の無作為化：リクエストに際してサーバに送信された実際のＵＲＩは、時間により異なるものでありうる。１つの実施形態において、プレーヤアプリケーション（またはサーバの呼び出し元）および実際の再生エンジンのみが、ＵＰＩの知識を有し、任意の他のＵＲＩは攻撃を試みるものと見なされる。また、ＵＲＩは、疑似ワンタイムパスワード（ＯＴＰ）アルゴリズムを使用して導き出され、不正ＵＲＩを用いてなされたリクエストはオープンソケットを残しうる。さらに、ＵＲＩは、サーバと呼び出しアプリケーションとの間のチャレンジ／レスポンスアルゴリズムを使用してネゴシエートされるトークンを含みうる。
【００４６】
ＵＲＩの無作為化に関して、保護メディアコンテンツが、ＨＴＴＰサーバからストリーミングされるとき、ホストアプリケーションは、着目するコンテンツへのパスを特定するためにＵＲＩを使用し、そのＵＲＩを下位メディアプレーヤサブシステムに渡しうる。前述したように、サーバパスおよび着目するメディアファイルを特定するＵＲＩは、無作為化され、一時的なものでありうる。好ましくは、ＵＲＩの無作為化はユニークであり、理想的には、同じホスト（例えば、ハンドセット）内で二度生成されることはない。また、ＵＲＩは、一時的なものであることが好ましく、発行されてからある一定のタイムフレーム（例えば、３０秒）内で期限切れになる。ＵＲＩが有効なプレーヤによってアクセスされると、ＨＴＴＰサーバは、ＵＲＩへの任意の他のアクセスを受けないことが好ましい。
【００４７】
例示的なＵＲＩフォーマットは、以下のもの、すなわち、ｖｉｄｅｏ／ｈａｓｈ／ｔｉｍｅｓｔａｍｐ／ｍｅｄｉａＦｉｌｅＮａｍｅになりうる。ここで、（ｉ）「ｖｉｄｅｏ」とは、映像コンテンツへのアクセスを示す定数列であり、（ｉｉ）「ｈａｓｈ」は、例えば、ＭＤ５．ｈａｓｈ（ｔｏｋｅｎ＋ｍｅｄｈｉａＦｉｌｅＮａｍｅ＋ｔｉｍｅｓｔａｍｐ）などのハッシュであり、ここで、トークンはストレージデバイスでメディアファイルごとにユニークであり、（ｉｉｉ）「ｔｉｍｅｓｔａｍｐ」は、１６進数列として与えられたタイムスタンプであり（例えば、１６進記数法で１９７０年１月１日００：００：００からの経過秒数）、（ｉｖ）「ｍｅｄｈｉａＦｉｌｅＮａｍｅ」は、コンテンツファイル（例えば、映像ファイル）の名前である。好ましくは、無作為化された一時ＵＲＩは、ネイティブアプリケーションインターフェイス（ＡＰＩ）を介してサーバから渡される。
【００４８】
別の代替例において、ホストのサーバ（例えば、ＨＴＴＰサーバ）は、ストレージデバイスから（例えば、ストレージデバイスのパブリックパーティションから）呼び出された符号化（例えば、暗号化）されたファイルを変換（例えば、復号化または解読）し、（例えば、「ＨＴＴＰ  Ｇｅｔ」リクエストに応答して）変換されたデータをホストアプリケーションに戻すように構成されうる。これにより、ホストアプリケーション（例えば、メディアプレーヤ）は、ストレージデバイスのパブリックパーティションに格納された符号化ファイルを再生できる。したがって、ストレージデバイスのパブリックパーティションに格納された仮想ファイルのコンテンツを読み出すか、またはストレージデバイスのプライベートパーティションからコンテンツを抽出する特殊なコマンドを送信する前述した実施形態とは異なり、サーバは、この代替例において、ストレージデバイスのパブリックパーティションに格納された専用ファイルを変換する。
【００４９】
別の代替例は、サーバのセキュリティ対策を改善することに関する。あるオペレーティングシステムにおいてコマンドを実行する許可は、２つのグループ、すなわち、通常ユーザ許可およびスーパーユーザ許可（「ａｄｍｉｎ」または「ｒｏｏｔ」許可としても知られている）に分けられる。ハッカーが、ルート許可を有することができるようにオペレーティングシステムを修正して、ホストデバイスに修正されたオペレーティングシステムをインストールすることもある。一旦インストールされると、ハッカーは、通常ユーザであるにもかかわらず、スーパーユーザの許可を有し、ストレージデバイスのプライベートメモリエリアに格納されたデータへ不正アクセスする許可を使用しうる。このようなことが起きないように、サーバは、「ルートチェック」を実行するように構成されうる。詳細には、サーバは、ホストアプリケーションからのリクエストが、通常ユーザ許可またはスーパーユーザ許可に関連付けられているかを決定するように構成され（例えば、ホストアプリケーションからのリクエストが、使用可能にされた「スーパーユーザ許可」を有しているかを決定することによって）、リクエストが通常ユーザ許可に関連付けられていると決定された場合のみ、ホストアプリケーションへのレスポンスを送信するようにさらに構成されうる。これにより、サーバは、ホストデバイスが「ルート」されるとき、ホストアプリケーションのリクエストに応答できなくなる。ホストデバイスが「ルート」されていなければ、サーバは、通常通りに挙動し、解読されたコンテンツファイル（例えば、ｍｐ３ファイル）のデータを有するレスポンスを送信しうる。
【００５０】
リクエストが、通常ユーザ許可またはスーパーユーザ許可に関連付けられているかを決定するために、任意の適切な方法が使用されうる。例えば、Ａｎｄｒｏｉｄのオペレーティングシステムを実行するホストデバイスにおいて、「ｒｏ．ｓｅｃｕｒｅ」システムの特性を分析することによって、スーパーユーザ権限の決定が行われうる。「ｒｏ．ｓｅｃｕｒｅ」システム特性が０に設定されていれば、プロセスは、スーパーユーザ権限を得てもよい。Ｌｉｎｕｘ（登録商標）系のオペレーティングシステムでは、特別なユーザ０の指定は、スーパーユーザ権限を示す。また、プロセスが、システム機能を用いてユーザＩＤを決定してもよい。例えば、プロセスが、ｓｅｔｕｉｄ（）またはｓｅｔｕｉｄ（）機能を用いて、有効ユーザＩＤを０に設定しようと試みてもよい。ユーザＩＤが０に設定されれば、プロセスはスーパーユーザ権限を有する。スーパーユーザ権限は、スーパーユーザ権限を有するべきではない呼び出しプロセス以外のプロセスに割り当てられてもよい。例えば、Ｌｉｎｕｘ（登録商標）系のオペレーティングシステムにおいて、ｐｒｏｃファイルシステム（／ｐｒｏｃ）は、ユーザＩＤを含むアクティブプロセスのすべてに関する情報を含んでもよい。これは、呼び出しプロセスまたは任意の依存が有するべき権限を超えているかを決定するために、各プロセスに対して既知の正確なユーザアカウントと比較されうる。
【００５１】
結論
前に詳述した記載は、本発明の定義としてではなく、本発明がとりうる選択された形態の説明として理解されることを意図したものである。請求された本発明の範囲を規定するように意図されるものは、すべての均等物を含む添付の特許請求の範囲のみである。最後に、本願明願細書に記載された任意の好ましい実施形態の任意の態様は、単独で、または互いに組み合わせて使用されうることに留意すべきである。
【図１】
2013530454.tif 000003
【図２】
2013530454.tif 000004
【図３Ａ】
2013530454.tif 000005
【図３Ｂ】
2013530454.tif 000006
【図４】
2013530454.tif 000007
【図５】
2013530454.tif 000008
【国際調査報告】
2013530454.tif 000009
2013530454.tif 000010