(57)【要約】  分散形記憶サービスを提供する様々な方法、デバイスおよびシステムを開示する。データ記憶デバイスは、データ記憶デバイスに直接結合されたローカルホストコンピュータなどの外部エンティティ、リモートサーバコンピュータ、または直接リモートデータ記憶デバイスと、ローカルホストコンピュータによる介入があるかまたは介入なしで通信セッションを開始することができる（逆の場合も同様である）。
2011513804.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングシステムであって、
ホストデバイス（ＨＤ）と、
前記ＨＤによって管理されるローカル記憶デバイス（ＬＳＤ）であって、前記ＬＳＤは、前記ＨＤによって提供されるインターフェイス以外には前記ＨＤの外部にあるデバイスに対する何らのインターフェイスも利用せず、またＬＳＤ論理リクエストを使用して、前記ＬＳＤと起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示することで、前記ＨＤにリクエストされたプロセスを実行するように間接的に指示し、前記ＬＳＤおよび前記起動アプリケーションは前記ＨＤによる介入なしに前記通信パス上で論理的に対話し、前記論理的対話は前記リクエストされたプロセスを前記ＨＤが実行するように前記起動アプリケーションに指示させ、前記ＬＳＤ論理リクエストはＨＤによって開始されたプロセスに役立つように作成されたものではないローカル記憶デバイス（ＬＳＤ）と、
を備えるコンピューティングシステム。
【請求項２】
請求項１記載のコンピューティングシステムにおいて、
前記ＨＤと前記ＬＳＤとの間の通信パスを提供するＨＤ／ＬＳＤインターフェイスと、
前記ＨＤ内にあり、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）と、
前記ＬＳＤ内にあり、少なくとも前記ＨＤＦＳによって管理される少なくとも１つの記憶エリアであって、前記ＨＤＦＳは、前記ＨＤ／ＬＳＤインターフェイスを経由して前記少なくとも１つの記憶エリアに渡されるブロックコマンドを生成することによって、前記少なくとも１つの記憶エリアを管理するものである少なくとも１つの記憶エリアと、
をさらに備えるコンピューティングシステム。
【請求項３】
請求項２記載のコンピューティングシステムにおいて、
前記ＬＳＤは、
前記ホストデバイスが前記ＬＳＤにポーリングを行っていれば、前記ＬＳＤが前記ＬＳＤ論理リクエストを用いて前記ホストデバイスのポーリングに応答するが、前記ホストデバイスのポーリングはＨＤＦＳにより開始されたプロセスまたはＬＳＤドライバにより開始されたプロセスのいずれからも独立している場合、そうでなければ、
前記ＬＳＤ論理リクエストを生成し、前記ＬＳＤ論理リクエストとＬＳＤ割り込み信号とを関連付け、前記ホストデバイス宛てに前記ＬＳＤ割り込み信号を発生させる場合のいずれかによって、
前記ＬＳＤ論理リクエストを使用して、前記ＬＳＤと前記起動アプリケーションとの間に前記通信パスを確立するように前記ＨＤに指示するコンピューティングシステム。
【請求項４】
請求項３記載のコンピューティングシステムにおいて、
前記ＬＳＤ論理リクエストは、前記ホストデバイスと、前記ＨＤおよび前記ＬＳＤの外部にありネットワークに含まれるデバイスに関連したリモート起動アプリケーションとの間に、ネットワークインターフェイスを利用してネットワークリンクとして前記通信パスを提供するように前記ホストデバイスに指示するか、または前記ＬＳＤと、前記ＬＳＤの外部にあるローカルデバイスに関連したローカル起動アプリケーションとの間に、前記ネットワークリンクではないローカル通信パスとして前記通信パスを提供するように前記ホストデバイスに指示するコンピューティングシステム。
【請求項５】
請求項４記載のコンピューティングシステムにおいて、
前記ローカルデバイスは前記ＨＤにより管理されるＳＩＭカードであり、前記ＳＩＭカードは、ＳＩＭアプリケーションツールキットコマンドセットに準拠するか、またはＵＳＩＭアプリケーションツールキットコマンドセットに準拠するコンピューティングシステム。
【請求項６】
請求項４記載のコンピューティングシステムにおいて、
前記ホストデバイスおよび前記ＬＳＤの外部にあるデバイスは、ネットワークデバイス（ＮＤ）であるコンピューティングシステム。
【請求項７】
請求項６記載のコンピューティングシステムにおいて、
前記ネットワークがＩＰプロトコルベースのネットワークであるならば、前記ＬＳＤおよび前記ＳＩＭカードはそれぞれＬＳＤ  ＩＰアドレスおよびＳＩＭ  ＩＰアドレスを付与され、前記ホストデバイスはホストデバイスＩＰアドレスを付与され、前記ＮＤはＮＤ  ＩＰアドレスを付与されるコンピューティングシステム。
【請求項８】
請求項７記載のコンピューティングシステムにおいて、
前記リクエストされたプロセスは、ブラウザアプリケーションの起動であるコンピューティングシステム。
【請求項９】
請求項８記載のコンピューティングシステムにおいて、
前記ブラウザアプリケーションは、前記ＬＳＤをポイントし、またユーザ入力を受け取るように構成されたユーザインターフェイス（ＵＩ）を開くコンピューティングシステム。
【請求項１０】
請求項９記載のコンピューティングシステムにおいて、
前記ブラウザアプリケーションは、前記ＬＳＤと前記ＵＩとの間の論理的対話を促進し、その結果、前記ＬＳＤにユーザに対する直接アクセスを提供するコンピューティングシステム。
【請求項１１】
ホストデバイス（ＨＤ）と前記ＨＤによって管理されるローカル記憶デバイス（ＬＳＤ）とを有するコンピューティングシステムにおいて、リクエストされたプロセスを実行するように間接的に前記ＨＤに指示する方法であって、前記ＬＳＤは、前記ＨＤによって提供されるインターフェイス以外には前記ＨＤの外部にあるデバイスに対する何らのインターフェイスも利用しないものである前記方法において、
ＨＤによって開始されたプロセスに役立つように作成されたものではないＬＳＤ論理リクエストを使用して、前記ＬＳＤと起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示するステップと、
前記ＨＤによる介入なしに前記通信パス上で論理的に対話するステップと、
前記リクエストされたプロセスを前記ＨＤが実行するように前記起動アプリケーションに指示させるステップと、
前記リクエストされたプロセスを実行するステップと、
を含む方法。
【請求項１２】
請求項１１記載の方法において、
前記コンピューティングシステムは、
前記ＨＤと前記ＬＳＤとの間の通信パスを提供するＨＤ／ＬＳＤインターフェイスと、
前記ＨＤ内にあり、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）と、
前記ＬＳＤ内にあり、少なくとも前記ＨＤＦＳによって管理される少なくとも１つの記憶エリアであって、前記ＨＤＦＳは、前記ＨＤ／ＬＳＤインターフェイスを経由して前記少なくとも１つの記憶エリアに渡されるブロックコマンドを生成することによって、前記少なくとも１つの記憶エリアを管理するものである少なくとも１つの記憶エリアと、
をさらに備える方法。
【請求項１３】
請求項１２記載の方法において、
前記ＬＳＤは、
前記ホストデバイスが前記ＬＳＤにポーリングを行っていれば、前記ＬＳＤが前記ＬＳＤ論理リクエストを用いて前記ホストデバイスのポーリングに応答するが、前記ホストデバイスのポーリングはＨＤＦＳにより開始されたプロセスのいずれからも独立している場合、そうでなければ、
前記ＬＳＤ論理リクエストを生成し、前記ＬＳＤ論理リクエストとＬＳＤ割り込み信号とを関連付け、前記ホストデバイス宛てに前記ＬＳＤ割り込み信号を発生させる場合のいずれかによって、
前記ＬＳＤ論理リクエストを使用して、前記ＬＳＤと前記起動アプリケーションとの間に前記通信パスを確立するように前記ＨＤに指示する方法。
【請求項１４】
請求項１３記載の方法において、
前記ＬＳＤ論理リクエストは、前記ホストデバイスと、前記ＨＤおよび前記ＬＳＤの外部にありネットワークに含まれるデバイスに関連した前記起動アプリケーションとの間に、ネットワークインターフェイスを利用してネットワークリンクとして前記通信パスを提供するように前記ホストデバイスに指示するか、または前記ＬＳＤと、前記ＬＳＤの外部にあるローカルデバイスに関連したローカル起動アプリケーションとの間に、前記ネットワークリンクではないローカル通信パスとして前記通信パスを提供するように前記ホストデバイスに指示する方法。
【請求項１５】
請求項１４記載の方法において、
前記ローカルデバイスは前記ホストデバイスにより管理されるＳＩＭカードであり、前記ＳＩＭカードは、ＳＩＭアプリケーションツールキットコマンドセットに準拠するか、またはＵＳＩＭアプリケーションツールキットコマンドセットに準拠する方法。
【請求項１６】
請求項１５記載の方法において、
前記ホストデバイスおよび前記ＬＳＤの外部にあるデバイスは、ネットワークデバイス（ＮＤ）である方法。
【請求項１７】
請求項１６記載の方法において、
前記ネットワークがＩＰプロトコルベースのネットワークであるならば、前記ＬＳＤおよび前記ＳＩＭカードはそれぞれＬＳＤ  ＩＰアドレスおよびＳＩＭ  ＩＰアドレスを付与され、前記ホストデバイスはホストデバイスＩＰアドレスを付与され、前記ＮＤはＮＤ  ＩＰアドレスを付与される方法。
【請求項１８】
請求項１７記載の方法において、
前記リクエストされたプロセスは、ブラウザアプリケーションの起動である方法。
【請求項１９】
請求項１８記載の方法において、
前記ブラウザアプリケーションは、前記ＬＳＤをポイントし、またユーザ入力を受け取るように構成されたユーザインターフェイス（ＵＩ）を開く方法。
【請求項２０】
請求項１９記載の方法において、
前記ブラウザアプリケーションは、前記ＬＳＤと前記ＵＩとの間の論理的対話を促進し、その結果、前記ＬＳＤにユーザに対する直接アクセスを提供する方法。
【請求項２１】
少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイを備えるＬＳＤであって、
前記第１および前記第２の部分は互いに独立し、第１のアプリケーションが前記第１の部分内の第１のアプリケーションコンテンツを管理し、第２のアプリケーションが前記第２の部分内の第２のアプリケーションコンテンツを管理し、前記第１および前記第２のアプリケーションは互いに独立して実行され、前記第１のアプリケーションによる前記第１のアプリケーションコンテンツの管理は前記第２のアプリケーションによる前記第２のアプリケーションコンテンツの管理から独立し、前記ＬＳＤは前記第１の部分に格納される前記第１のアプリケーションコンテンツを前記第２のアプリケーションに通知し、前記ＬＳＤによる通知はホストデバイス（ＨＤ）から独立しているＬＳＤ。
【請求項２２】
請求項２１記載のＬＳＤにおいて、
前記第１のアプリケーションによる管理は第１のアプリケーションコンテンツ管理ポリシーに基づいて実行され、前記第２のアプリケーションによる管理は第２のアプリケーションコンテンツ管理ポリシーに基づいて実行されるＬＳＤ。
【請求項２３】
請求項２２記載のＬＳＤにおいて、
前記第２のアプリケーションは、前記第１の部分に格納される前記第１のアプリケーションコンテンツの情報であって、前記ＬＳＤによって前記第２のアプリケーションに提供される情報を使用して、前記第１のアプリケーションコンテンツ管理ポリシーを推定するＬＳＤ。
【請求項２４】
請求項２３記載のＬＳＤにおいて、
前記第２のアプリケーションは、前記推定された第１のアプリケーションコンテンツ管理ポリシーを使用して、前記第２のアプリケーションコンテンツ管理ポリシーを更新するＬＳＤ。
【請求項２５】
請求項２４記載のＬＳＤにおいて、
前記第２のアプリケーションは、前記更新された第２のアプリケーションコンテンツ管理ポリシーを使用して、その後の第１のアプリケーション管理動作を予測するＬＳＤ。
【請求項２６】
請求項２５記載のＬＳＤにおいて、
前記第２のアプリケーションは、前記予測されたその後の第１のアプリケーション管理動作に基づいて、第２の部分の管理動作を開始するＬＳＤ。
【請求項２７】
請求項２６記載のＬＳＤにおいて、
前記ＬＳＤは前記ＨＤと通信し、前記ＨＤはホストデバイスファイルシステム（ＨＤＦＳ）を含み、前記ＬＳＤによる通知は前記ＨＤＦＳから独立しているＬＳＤ。
【請求項２８】
請求項２７記載のＬＳＤにおいて、
前記第１の部分は前記ＨＤＦＳによって管理され、前記第１のアプリケーションは前記ＨＤＦＳを使用して前記第１の部分内の前記第１のアプリケーションコンテンツを管理し、前記第２の部分は前記ＨＤＦＳによって管理されず、また前記ＨＤＦＳに認識もされないＬＳＤ。
【請求項２９】
請求項２８記載のＬＳＤにおいて、
前記ホストデバイス（ＨＤ）は前記ＨＤが通信パスを確立するために使用するネットワークインターフェイスを含み、前記通信パス上で、前記第２の部分は前記ネットワークインターフェイスにアクセスし、前記ＨＤが前記通信パスを確立すると、前記通信パスの保持を除いて前記ＨＤによるそれ以上の介入はないＬＳＤ。
【請求項３０】
請求項２９記載のＬＳＤにおいて、
前記第１のアプリケーションはブラウザキャッシュマネージャであり、前記第２のアプリケーションはプロキシキャッシュマネージャであるＬＳＤ。
【請求項３１】
請求項３０記載のＬＳＤにおいて、
前記第２の部分は前記プロキシキャッシュマネージャによって管理されるプロキシキャッシュを少なくとも含み、前記プロキシキャッシュマネージャはプロキシキャッシュ管理ポリシーに従って前記プロキシキャッシュ内の前記プロキシキャッシュコンテンツを管理するＬＳＤ。
【請求項３２】
請求項３１記載のＬＳＤにおいて、
前記第１の部分は前記ブラウザキャッシュマネージャによって管理されるブラウザキャッシュを少なくとも含み、前記ブラウザキャッシュマネージャはブラウザキャッシュ管理ポリシーに従って前記ブラウザキャッシュ内の前記ブラウザキャッシュコンテンツを管理するＬＳＤ。
【請求項３３】
請求項３２記載のＬＳＤにおいて、
前記プロキシキャッシュマネージャは、前記ＬＳＤによって提供される前記ブラウザキャッシュコンテンツについての情報に基づいて、前記プロキシキャッシュ管理ポリシーを変更するＬＳＤ。
【請求項３４】
請求項３３記載のＬＳＤにおいて、
前記プロキシキャッシュマネージャは、前記変更されたプロキシキャッシュ管理ポリシーを使用して、ブラウザキャッシュ動作を予測するＬＳＤ。
【請求項３５】
請求項３４記載のＬＳＤにおいて、
前記プロキシキャッシュマネージャは、前記予測されたブラウザキャッシュ動作を使用して、前記プロキシキャッシュコンテンツを更新するＬＳＤ。
【請求項３６】
コンピューティングシステムであって、
ホストデバイスファイルシステム（ＨＤＦＳ）およびネットワークインターフェイスを含むホストデバイスと、
ローカル記憶デバイス（ＬＳＤ）であって、
少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイであって、前記第１および前記第２の部分は互いに独立し、前記第１の部分は第１のアプリケーションが前記ＨＤＦＳを使用して前記第１の部分内の第１のアプリケーションコンテンツを管理するように前記ＨＤＦＳによって管理され、前記第２の部分は前記第２の部分が前記ＨＤＦＳに認識されないように前記ＨＤＦＳによって管理されず、前記第１および第２のアプリケーションは互いに独立して実行され、前記第１のアプリケーションによる前記第１のアプリケーションコンテンツの管理は第２のアプリケーションによる第２のアプリケーションコンテンツの管理から独立し、前記ＬＳＤは前記第１の部分に格納される前記第１のアプリケーションコンテンツを前記第２のアプリケーションに通知し、前記通知は前記ＨＤＦＳに認識されないものであるメモリアレイを含むローカル記憶デバイス（ＬＳＤ）と、
を備えるコンピューティングシステム。
【請求項３７】
請求項３６記載のコンピューティングシステムにおいて、
前記第１のアプリケーションによる管理は第１のアプリケーションコンテンツ管理ポリシーに基づいて実行され、前記第２のアプリケーションによる管理は第２のアプリケーションコンテンツ管理ポリシーに基づいて実行されるコンピューティングシステム。
【請求項３８】
請求項３７記載のコンピューティングシステムにおいて、
前記第２のアプリケーションは、前記第１の部分に格納される前記第１のアプリケーションコンテンツの情報であって、前記ＬＳＤによって前記第２のアプリケーションに提供される情報を使用して、前記第１のアプリケーションコンテンツ管理ポリシーを推定するコンピューティングシステム。
【請求項３９】
請求項３８記載のコンピューティングシステムにおいて、
前記第２のアプリケーションは、前記推定された第１のアプリケーションコンテンツ管理ポリシーを使用して、前記第２のアプリケーションコンテンツ管理ポリシーを更新するコンピューティングシステム。
【請求項４０】
請求項３９記載のコンピューティングシステムにおいて、
前記第２のアプリケーションは、前記更新された第２のアプリケーションコンテンツ管理ポリシーを使用して、その後の第１のアプリケーション動作を予測するコンピューティングシステム。
【請求項４１】
請求項４０記載のコンピューティングシステムにおいて、
前記第２のアプリケーションは、前記予測されたその後の第１のアプリケーション動作に基づいて、第２の部分の動作を開始するコンピューティングシステム。
【請求項４２】
請求項４１記載のコンピューティングシステムにおいて、
前記ホストデバイス（ＨＤ）は、前記ＨＤが前記第２の部分へのネットワークアクセスを促進するために使用するネットワークインターフェイスを含むコンピューティングシステム。
【請求項４３】
請求項４２記載のコンピューティングシステムにおいて、
前記第１のアプリケーションはブラウザキャッシュマネージャであり、前記第２のアプリケーションはプロキシキャッシュマネージャであるコンピューティングシステム。
【請求項４４】
請求項４３記載のコンピューティングシステムにおいて、
前記第２の部分は前記プロキシキャッシュマネージャによって管理されるプロキシキャッシュを少なくとも含み、前記プロキシキャッシュマネージャはプロキシキャッシュ管理ポリシーに従って前記プロキシキャッシュ内のプロキシキャッシュコンテンツを管理するコンピューティングシステム。
【請求項４５】
請求項４４記載のコンピューティングシステムにおいて、
前記第１の部分は前記ブラウザキャッシュマネージャによって管理されるブラウザキャッシュを少なくとも含み、前記ブラウザキャッシュマネージャはブラウザキャッシュ管理ポリシーに従って前記ブラウザキャッシュ内のブラウザキャッシュコンテンツを管理するコンピューティングシステム。
【請求項４６】
請求項４４記載のコンピューティングシステムにおいて、
前記プロキシキャッシュマネージャは、前記ＬＳＤによって提供される前記ブラウザキャッシュコンテンツについての情報に基づいて、前記プロキシキャッシュ管理ポリシーを変更するコンピューティングシステム。
【請求項４７】
請求項４６記載のコンピューティングシステムにおいて、
前記プロキシキャッシュマネージャは、前記変更されたプロキシキャッシュ管理ポリシーを使用して、ブラウザキャッシュ動作を予測するコンピューティングシステム。
【請求項４８】
請求項４７記載のコンピューティングシステムにおいて、
前記プロキシキャッシュマネージャは、前記予測されたブラウザキャッシュ動作を使用して、前記プロキシキャッシュコンテンツを更新するコンピューティングシステム。
【請求項４９】
デジタルコンテンツプロバイダによってＤＲＭ方式に従い少なくとも１つの制限を加えられた、保護されているデジタルコンテンツを取得および消費する方法であって、前記方法はメモリアレイを有するローカル記憶デバイス（ＬＳＤ）を含むシステムによって実行され、前記ＬＳＤは前記メモリアレイの少なくとも一部分を管理するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）を少なくとも有するホストデバイス（ＨＤ）と結合される前記方法において、
前記保護されているデジタルコンテンツを前記ＬＳＤによって取得するステップと、
前記取得された保護されているデジタルコンテンツを前記ＬＳＤによって前記メモリアレイにセキュアに格納するステップであって、前記取得するステップおよび前記セキュアに格納するステップはそれぞれ、前記ＤＲＭ方式に従い、どちらも前記ＨＤＦＳによって開始されるものではないようにしたセキュアに格納するステップと、
前記保護されているデジタルコンテンツを消費するステップであって、
前記セキュアに格納された保護されているデジタルコンテンツの少なくとも一部をデジタルデータストリームに変換するステップと、
前記ＬＳＤによって前記デジタルデータストリームをストリーミングするステップであって、前記デジタルデータストリームに使用制限である前記少なくとも１つの制限が加えられていれば、前記ＬＳＤは前記使用制限を強制するようにしたストリーミングするステップと、によって前記保護されているデジタルコンテンツを消費するステップと、
を含む方法。
【請求項５０】
請求項４９記載の方法において、
前記保護されているデジタルコンテンツはデジタルコンテンツおよび対応する権利オブジェクトを含み、前記使用制限は前記保護されているデジタルコンテンツの不正コピーを防ぐことを含むかまたは前記保護されているデジタルコンテンツの所定回数の使用を許可する方法。
【請求項５１】
請求項５０記載の方法において、
前記メモリアレイは、前記ＨＤＦＳによって管理され、前記ＨＤＦＳに認識される少なくとも第１の部分と、前記ＨＤＦＳによって管理されず、前記ＨＤＦＳに認識されない少なくとも第２の部分とをさらに含み、
前記保護されているデジタルコンテンツをセキュアに格納するステップは、
暗号化されたデジタルコンテンツを前記メモリアレイのうちの前記ＨＤＦＳに認識される前記第１の部分に格納するステップと、
前記デジタルコンテンツに対応する前記権利オブジェクトを前記メモリアレイのうちの前記ＨＤＦＳに認識されない前記第２の部分に格納するステップと、
をさらに含む方法。
【請求項５２】
請求項５０記載の方法において、
前記保護されているデジタルコンテンツをセキュアに格納するステップは、
前記保護されているデジタルコンテンツを暗号化するステップと、
前記暗号化された保護されているデジタルコンテンツを前記メモリアレイのうちの前記ＨＤＦＳに認識される第１の部分に格納するステップと、
をさらに含む方法。
【請求項５３】
請求項４９記載の方法において、
前記ＬＳＤは前記デジタルデータストリームを前記ＬＳＤの外部のエージェントへストリーミングし、前記少なくとも１つの制限がアクセス制限を含めば、前記外部エージェントが前記ＤＲＭ方式にとって容認可能なアクセス資格を有する認証された外部エージェントである場合にのみ、前記外部エージェントは前記デジタルデータストリームを処理することができる方法。
【請求項５４】
請求項５３記載の方法において、
前記外部エージェントは、インターフェイスを経由して前記ＨＤに接続される第２のＬＳＤに存在する方法。
【請求項５５】
請求項５４記載の方法において、
前記外部エージェントは、前記ＨＤ内で実行されるローカルのデジタルメディアプレーヤレンダラアプリケーションである方法。
【請求項５６】
請求項５４記載の方法において、
前記保護されているデジタルコンテンツは、前記ＨＤおよび前記ＬＳＤの外部にありネットワークに含まれるリモートデバイス（ＲＤ）から取得される方法。
【請求項５７】
請求項５６記載の方法において、
前記保護されているデジタルコンテンツの取得より前に、前記ＬＳＤおよび前記ＲＤを相互認証するステップと、
相互認証が無事に終了した場合にのみ、前記ＬＳＤによる前記ＲＤからの前記デジタルコンテンツの取得を開始するステップと、
をさらに含む方法。
【請求項５８】
請求項５７記載の方法において、
前記ＨＤは、前記ＨＤにネットワークへのアクセスを提供するネットワークインターフェイスをさらに含む方法。
【請求項５９】
請求項５８記載の方法において、
前記保護されているデジタルコンテンツを取得するステップは、
前記ＲＤによって、前記ＬＳＤと前記ＲＤとの間に前記ネットワークインターフェイスを使用して通信パスを確立するように前記ＨＤに指示するステップであって、前記ＨＤによって前記通信パスが確立されると、前記通信パスの保持を除いて前記ＨＤによるそれ以上の介入はないようにした指示するステップ、または
前記ＬＳＤによって、前記ＬＳＤと前記ＲＤとの間に前記ネットワークインターフェイスを使用して前記通信パスを確立するように前記ＨＤに指示するステップであって、前記ＨＤによって前記通信パスが確立されると、前記通信パスの保持を除いて前記ＨＤによるそれ以上の介入はないようにした指示するステップと、
前記ＬＳＤおよび前記ＲＤによって、前記通信パス上で論理的に対話するステップであって、前記論理的対話は前記ＨＤに認識されないようにした対話するステップと、
をさらに含む方法。
【請求項６０】
請求項５９記載の方法において、
前記論理的対話は、前記ＲＤに前記保護されているデジタルコンテンツを前記ＲＤから前記ＬＳＤへ送らせ、また前記ＬＳＤに前記保護されているデジタルコンテンツを前記メモリアレイに強制的に格納させるＲＤコマンドを含むか、または前記ＬＳＤに前記ＲＤが前記デジタルコンテンツを前記ＲＤから前記ＬＳＤへ送ることをリクエストさせるＬＳＤコマンドを含む方法。
【請求項６１】
請求項６０記載の方法において、
前記セキュアに格納された保護されているデジタルコンテンツの少なくとも一部を前記デジタルデータストリームに変換するステップは、
前記保護されているデジタルコンテンツを前記メモリアレイから読み込むステップと、
前記メモリアレイから読み込まれた前記保護されているデジタルコンテンツを少なくとも１つのデータストリームに構成するステップと、
を含む方法。
【請求項６２】
請求項６１記載の方法において、
前記保護されているデジタルコンテンツを前記ＬＳＤによって前記メモリアレイからストリーミングするステップは、
ストリーミングチャネルを形成するステップと、
前記保護されているデジタルコンテンツを前記ストリーミングチャネル上でストリーミングするステップと、
を含む方法。
【請求項６３】
請求項６２記載の方法において、
前記ＤＲＭが、前記ストリーミングチャネルがセキュアなストリーミングチャネルであることを要求すれば、
前記セキュアなストリーミングチャネルを形成し、
前記保護されているデジタルコンテンツを前記セキュアなストリーミングチャネル上でストリーミングする方法。
【請求項６４】
請求項４９記載の方法において、
前記保護されているデジタルコンテンツは、ＭＰ３オーディオファイルおよび／またはビデオファイルを含むデジタルメディアファイルである方法。
【請求項６５】
請求項４９記載の方法において、
前記システムは、別のＤＲＭ方式に従って少なくとも１つの制限を加えられる他の保護されているデジタルコンテンツを同時に取得および消費するように構成される方法。
【請求項６６】
ローカル記憶デバイス（ＬＳＤ）と通信するホストデバイス（ＨＤ）を有するコンピューティングデバイスであって、前記ＬＳＤは複数のデータブロックを含むメモリアレイを含み、前記メモリアレイは前記ＨＤにとって前記データブロックによってアクセス可能であるコンピューティングデバイスにおいて、前記ＬＳＤの前記メモリアレイに格納されるデータに関して検索インデックスを生成する方法であって、
前記ＬＳＤの前記メモリアレイに格納されるデータに関してインデックスデータを前記ＬＳＤによって前記ＨＤの関与なしに生成するステップと、
前記生成されたインデックスデータを前記ＬＳＤによって前記検索インデックスの少なくとも一部として前記ＬＳＤ上に格納するステップと、
を含む方法。
【請求項６７】
請求項６６記載の方法において、
前記ＬＳＤの前記メモリアレイに格納される前記データに関してインデックスデータを生成するステップは、
前記ＨＤによる、前記ＬＳＤの前記メモリアレイに関連するデータアクセス動作の結果としての前記ＬＳＤに対するアクセスを前記ＬＳＤによって確認するステップであって、前記データアクセス動作の結果、前記メモリアレイへまたは前記メモリアレイからデータブロックが提供されるようにした確認するステップと、
前記確認されたデータアクセス動作を特徴付けるデータを前記ＬＳＤによって判断するステップと、
前記判断された特徴付けデータに少なくとも部分的に基づいて前記インデックスデータを生成するステップと、
を含む方法。
【請求項６８】
請求項６７記載の方法において、
前記確認されたデータアクセス動作を特徴付けるデータを判断するステップは、前記確認されたデータアクセス動作においてアクセスされる前記データのコンテンツ以外のデータを少なくとも含むデータを判断するステップを含む方法。
【請求項６９】
請求項６８記載の方法において、
前記データアクセス動作は、メディアコンテンツのデータにアクセスする動作を含み、
前記確認されたデータアクセス動作を特徴付けるデータを判断するステップは、前記メディアコンテンツに関連する確認されたデータアクセス動作によって表される挙動を特徴付けるデータと、前記アクセスされたメディアコンテンツ自体のデータ以外のデータを少なくとも含むデータとを判断するステップを含む方法。
【請求項７０】
請求項６７記載の方法において、
前記ＨＤはホストデバイスファイルシステム（ＨＤＦＳ）を含み、前記ＨＤによる前記ＬＳＤの前記メモリアレイに関連するデータアクセス動作はＨＤＦＳの動作を含む方法。
【請求項７１】
請求項６６記載の方法において、
前記ＬＳＤの前記メモリアレイに格納されるデータに関してインデックスデータを生成するステップは、前記メモリアレイに格納されるデータを少なくとも含むようにインデックスデータを生成するステップを含む方法。
【請求項７２】
請求項７１記載の方法において、
前記メモリアレイに格納されるデータを少なくとも含むようにインデックスデータを生成するステップは前記メモリアレイに格納されるデータから成るコンテンツを抽出するステップを含み、前記コンテンツは前記メモリアレイに格納されるデータである方法。
【請求項７３】
請求項６６記載の方法において、
前記ＬＳＤの前記メモリアレイに格納されるデータに関してインデックスデータを生成するステップは前記メモリアレイに格納されるデータに対して認識アルゴリズムを実行するステップを含み、前記生成されるインデックスデータは前記認識アルゴリズムの結果を示す方法。
【請求項７４】
請求項６６記載の方法において、
前記ＬＳＤの前記メモリアレイに格納されるデータに関してインデックスデータを生成するステップは、前記ＨＤの関与なしに前記ＬＳＤによって、前記ＬＳＤの前記メモリアレイの前記データにアクセスするステップと、前記データに関して前記インデックスデータを生成するステップとを含む方法。
【請求項７５】
請求項６６記載の方法において、
前記ＬＳＤによって検索クエリを受け取るステップと、
前記ＬＳＤによって、前記検索インデックスに関して前記検索クエリを処理し、前記検索クエリに応答して検索結果を提供するステップと、
をさらに含む方法。
【請求項７６】
請求項７５記載の方法において、
前記検索クエリを受け取るステップは、前記ＨＤから検索クエリを受け取るステップを含む方法。
【請求項７７】
請求項７５記載の方法において、
前記検索クエリを受け取るステップは、前記ＨＤ以外のデバイスから検索クエリを受け取るステップを含む方法。
【請求項７８】
請求項６６記載の方法において、
前記検索インデックスを前記ＬＳＤから前記ホストデバイスに提供するステップをさらに含む方法。
【請求項７９】
請求項６６記載の方法において、
前記検索インデックスを前記ＬＳＤから前記ホストデバイス以外のデバイスに提供するステップをさらに含む方法。
【請求項８０】
請求項６６記載の方法において、
前記ＬＳＤによって、前記ＬＳＤの前記メモリアレイ内の特定のコンテンツのデータアクセスリクエストを前記ＨＤから受け取るステップと、
前記生成されたインデックスデータを、前記ＬＳＤによって、前記データアクセスリクエストに基づき前記データアクセスリクエストの前記特定のコンテンツを考慮して処理し、前記アクセスリクエストをブロックするかどうかを判断するステップと、
をさらに含む方法。
【請求項８１】
請求項６６記載の方法において、
前記ＬＳＤ内に格納される前記生成されたインデックスデータを、前記ＨＤによって、前記ＬＳＤの前記メモリアレイ内の特定のコンテンツのデータアクセスリクエストに基づき前記データアクセスリクエストの前記特定のコンテンツを考慮して処理し、前記アクセスリクエストをブロックするかどうかを判断するステップをさらに含む方法。
【請求項８２】
システムであって、
データ記憶アレイと、
論理データブロックとして前記データ記憶アレイに格納されるデータを管理するようになっている第１の論理インターフェイスと、
論理データブロックとして格納される前記データに対応するデータオブジェクトを管理するようになっている第２の論理インターフェイスであって、論理データブロックとして格納される前記データの少なくとも一部が前記第１の論理インターフェイスを経由して変更されると、前記変更されたデータは前記第１および前記第２の論理インターフェイスの両方を経由してアクセス可能であり、前記第２の論理インターフェイスを経由して前記アクセス可能であることはデータオブジェクトプロパティの所定のセットを同時に管理することと前記変更されることとを伴うものである第２の論理インターフェイスと、
を備えるシステム。
【請求項８３】
請求項８２記載のシステムにおいて、
前記データオブジェクトプロパティの所定のセットを同時に管理することは同期化ユニットによって促進され、前記促進は前記データオブジェクトと前記オブジェクトプロパティの所定のセットとを同期化することを含むシステム。
【請求項８４】
請求項８２記載のシステムにおいて、
前記データオブジェクトプロパティの所定のセットは、オブジェクト名と、オブジェクトサイズと、前記オブジェクトがアクセスされた回数とを含むシステム。
【請求項８５】
請求項８２記載のシステムにおいて、
前記データ記憶アレイ、前記第１の論理インターフェイス、および前記第２の論理インターフェイスは、ローカル記憶デバイス（ＬＳＤ）に含まれるシステム。
【請求項８６】
請求項８５記載のシステムにおいて、
前記ＬＳＤは、ホストアプリケーションと、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）とを有するホストデバイス（ＨＤ）に結合されるシステム。
【請求項８７】
請求項８６記載のシステムにおいて、
同期化ユニットは、前記ＨＤに含まれるシステム。
【請求項８８】
請求項８３記載のシステムにおいて、
前記データ記憶アレイは、第１の部分および第２の部分を含むように設定されるシステム。
【請求項８９】
請求項８８記載のシステムにおいて、
前記第１の部分は前記論理データブロックおよび前記対応するデータオブジェクトを格納するように構成された前記第１および前記第２の論理インターフェイスと通信する大容量記憶部分であり、前記第２の部分は前記データオブジェクトプロパティの所定のセットを格納するように構成されるシステム。
【請求項９０】
請求項８９記載のシステムにおいて、
前記第１の部分内のオブジェクトが変更されるならば、前記同期化ユニットは、前記第２の部分に格納される対応する前記データオブジェクトプロパティを更新するシステム。
【請求項９１】
ローカル記憶デバイス（ＬＳＤ）であって、
データ記憶アレイと、
論理データブロックとして前記データ記憶アレイに格納されるデータを管理するようになっている第１の論理インターフェイスと、
論理データブロックとして格納される前記データに対応するデータオブジェクトを管理するようになっている第２の論理インターフェイスであって、論理データブロックとして格納される前記データの少なくとも一部が前記第１の論理インターフェイスを経由して変更されると、前記変更されたデータは前記第１および前記第２の論理インターフェイスの両方を経由してアクセス可能であり、前記第２の論理インターフェイスを経由して前記アクセス可能であることはデータオブジェクトプロパティの所定のセットを同時に管理することと前記変更されることとを伴うものである第２の論理インターフェイスと、
を備えるローカル記憶デバイス（ＬＳＤ）。
【請求項９２】
請求項９１記載のＬＳＤにおいて、
前記ＬＳＤは、ホストアプリケーションと、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）とを有するホストデバイス（ＨＤ）に結合されるＬＳＤ。
【請求項９３】
請求項９２記載のＬＳＤにおいて、
前記データオブジェクトプロパティの所定のセットを同時に管理することは同期化ユニットによって促進され、前記促進は前記データオブジェクトと前記データオブジェクトプロパティの所定のセットとを同期化することを含むＬＳＤ。
【請求項９４】
請求項９３記載のＬＳＤにおいて、
前記同期化ユニットは、前記ＨＤに含まれるＬＳＤ。
【請求項９５】
請求項９４記載のＬＳＤにおいて、
前記オブジェクトプロパティの所定のセットは、オブジェクト名と、オブジェクトサイズと、前記オブジェクトがアクセスされた回数とを含むＬＳＤ。
【請求項９６】
請求項９４記載のＬＳＤにおいて、
前記データ記憶アレイは、第１の部分および第２の部分を含むように設定されるＬＳＤ。
【請求項９７】
請求項９６記載のＬＳＤにおいて、
前記第１の部分は前記論理データブロックおよび前記対応するデータオブジェクトを格納するように構成された前記第１および前記第２の論理インターフェイスと通信する大容量記憶部分であり、前記第２の部分は前記データオブジェクトプロパティの所定のセットを格納するように構成されるＬＳＤ。
【請求項９８】
請求項９７記載のＬＳＤにおいて、
前記第１の部分内のオブジェクトが変更されるならば、前記同期化ユニットは、前記第２の部分に格納される対応する前記データオブジェクトプロパティを更新するＬＳＤ。
【請求項９９】
方法であって、
データ記憶アレイにおいて、
論理データブロックとして前記データ記憶アレイに格納されるデータを第１のインターフェイスを経由して管理するステップと、
前記データ記憶アレイに格納されるデータオブジェクトを第２のインターフェイスを経由して管理するステップであって、前記データオブジェクトは論理データブロックとして格納されるデータに対応し、論理データブロックとして格納されるデータが前記第１のインターフェイスを経由して変更されると、前記変更されたデータは前記第１および前記第２のインターフェイスの両方を経由してアクセス可能であり、前記第２のインターフェイスを経由してアクセス可能であることはデータオブジェクトプロパティの所定のセットを同時に管理することを伴うものである管理するステップと、
を含む方法。
【請求項１００】
請求項９９記載の方法において、
前記データオブジェクトプロパティの所定のセットを同時に管理することは同期化ユニットによって促進され、前記促進は前記データオブジェクトと前記データオブジェクトプロパティの所定のセットとを同期化することを含む方法。
【請求項１０１】
請求項１００記載の方法において、
前記データオブジェクトプロパティの所定のセットは、オブジェクト名と、オブジェクトサイズと、前記オブジェクトがアクセスされた回数とを含む方法。
【請求項１０２】
請求項１００記載の方法において、
前記データ記憶アレイ、前記第１の論理インターフェイス、および前記第２の論理インターフェイスは、ローカル記憶デバイス（ＬＳＤ）に含まれる方法。
【請求項１０３】
請求項１０２記載の方法において、
前記ＬＳＤは、ホストアプリケーションと、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）とを有するホストデバイス（ＨＤ）に結合される方法。
【請求項１０４】
請求項１０３記載の方法において、
同期化ユニットは、前記ＨＤに含まれる方法。
【請求項１０５】
請求項１０４記載の方法において、
前記データ記憶アレイは、第１の部分および第２の部分を含むように設定される方法。
【請求項１０６】
請求項１０５記載の方法において、
前記第１の部分は、前記論理データブロックおよび前記対応するデータオブジェクトを格納するように構成された前記第１および前記第２のインターフェイスと通信する大容量記憶部分であり、前記第２の部分は前記データオブジェクトプロパティの所定のセットを格納するように構成される方法。
【請求項１０７】
請求項１０６記載の方法において、
前記第１の部分内のオブジェクトが変更されるならば、前記同期化ユニットは、前記第２の部分に格納される対応する前記データオブジェクトプロパティを更新する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にデジタルデバイスに関する。特に、本発明は、デジタルデバイス用のクロスプラットフォーム大容量記憶サービスを提供することに関する。本発明はさらに、キャッシュ管理に関し、デジタルコンテンツのセキュアな配布および消費を提供すること、およびローカル記憶デバイスを用いて仮想記憶を提供することに関する。本発明はさらに、ローカル記憶デバイスが動作可能なように結合されているホストデバイスの関与なしに、ローカル記憶デバイス内のデータにインデックスを付ける能力を含むローカル記憶デバイスに関する。
【背景技術】
【０００２】
従来技術では、リムーバブルメディア（例えば、ＣＤ−ＲＯＭまたはフラッシュメディア）が挿入されると何らかのアクションを自動的に行う能力を、「自動実行」または「自動再生」機能がコンピュータＯＳに提供している。リムーバブルメディア上で配布されるソフトウェアが、ディスク挿入時にインストーラを自動的に起動できるため、これは便利な機能である。しかし、残念ながら、「自動実行」機能はセキュリティリスクをもたらす（すなわち、悪意のあるソフトウェアが配布される可能性がある）と一部の製造業者に考えられている。このリスクを回避するために、自動実行（または自動再生）機能は無効化されることが多く、ローカル記憶デバイスが直接ユーザと対話することができるメカニズムが提供されない。
【０００３】
インターネットテクノロジーは、特にネットワーク最適化の領域において、特にエンドユーザのブラウジング体験を改善するように急速に発展している分野であり、過去も、さらに今もなおそうあり続けている。コンピュータネットワークにおいて、プロキシサーバは、そのクライアントのリクエスト（例えば、ウェブページ、接続確立などのリクエスト）を、他のサーバへ、典型的にはウェブサーバへリクエストを送信することによって処理するサーバ（コンピュータシステムまたはアプリケーションプログラム）である。
【０００４】
インターネットアプリケーション（例えば、ＦＴＰプロトコルを使用するＦＴＰクライアント、またはそのほかＷＥＢブラウザなどの任意のインターネットアプリケーション）は、通常、少なくとも２つの関連インターフェイスを管理する。ローカル大容量記憶デバイスへの第１のインターフェイスは大容量記憶装置インターフェイスと呼ばれ、これを介してインターネットアプリケーションは、ホストデバイスファイルシステム（ＨＤＦＳ）を使用しキャッシュマネージャによりキャッシュに格納されているコンテンツを管理する。なお、より一般的には、任意の数のインターネットアプリケーションそれぞれが、その個別の論理インターフェイスを介して、ローカル大容量記憶デバイスに格納されているそれ用のコンテンツを管理することができ、こうした個々の記憶エリアはそれぞれ、それ用の規則のセットによって管理される。代表的なインターネットアプリケーションがブラウザアプリケーションという形をとる場合、ブラウザキャッシュマネージャが、ブラウザキャッシュポリシーとも呼ばれる規則のセットを使用して、適切なコンテンツをブラウザに供給する。レスポンスタイムを改善してネットワーク帯域幅を保つために、典型的にブラウザキャッシュは、キャッシュポリシーによって規定される関連規則（単数または複数）に基づいてコンテンツを格納する。例えば、ブラウザキャッシュマネージャ（特定のブラウザ向けに確立された関連キャッシュポリシーに従う）は、以前に読み出されたＷＥＢページに基づき、近い将来ブラウザが再びその特定のＷＥＢページをリクエストする可能性があると予想して、コンテンツ（例えば、ＷＥＢページ形式）を格納することができる。こうすることで、ブラウザキャッシュマネージャは、ブラウザキャッシュにローカルに格納されている関連ＷＥＢページを、貴重なネットワークリソースを使用せずに読み出すことができる。
【０００５】
インターネットアプリケーションによって使用されるもう１つのインターフェイスは、ネットワークリソースとの通信においてネットワーク接続上で送られるＨＴＴＰコマンドの管理など、インターネット接続性のために使用することができ、ネットワークリソースは、ローカルリソースまたはリモートリソースのいずれかとすることができる。モバイルブラウジングの場合、ブラウザは通常、プロキシサーバを介してリモートリソース／サーバにアクセスする。プロキシサーバは、貴重なモバイルリンクリソースを保つためにコンテンツ最適化／適合／フィルタリング／圧縮などを実行することができる。プロキシサーバは、インターネットのエッジでアクセス制御などの付加的なタスクを必要とする企業システムにおいても使用することができる。もう１つの有用な点は、プロキシキャッシュの管理にあり、「インターネットのエッジ」（すなわち、ユーザのブラウザのより近く）にコンテンツをプリキャッシュするために「コンテンツプリフェッチテクニック」を適用することができる。こうすることで、必要とされるとき、リクエスト対象のコンテンツが保有されていることから、ブラウジング体験を加速することができる。
【０００６】
しかし、ブラウザキャッシュおよびプロキシキャッシュは互いに独立して管理されるため、互いのキャッシュポリシーからの、またはそれについての「学習」は、ほとんどあり得ないか全くあり得ない。したがって、プロキシキャッシュおよびブラウザキャッシュはそれ用の規則のセットを指針とするが、ブラウザアプリケーションおよびプロキシが別々のベンダによって供給される可能性があることから、この規則のセットを他方が知っていることも知らないこともあり、そのため全体的なキャッシュ管理ポリシーが存在しないことがある。このような全体的なキャッシュ管理ポリシーの欠如は、効率の悪さをもたらす恐れがあり、その結果、記憶リソースの非効率的な割り当てが一因となり、最適とはいえないブラウジング体験をもたらしかねない。前述した非効率性として、例えば、プロキシキャッシュおよびブラウザキャッシュの両方に重複したコンテンツが格納されることが考えられ、これにより、ネットワークおよび記憶リソースの非効率的な使用（すなわち、ネットワークリンク上でブラウザコンテンツが不必要に送られること）をもたらす。
【０００７】
提案される解決策は、ブラウザと、プロキシキャッシュとの同期のために、クライアントエージェントをモバイルハンドセット上に統合することを含む。なお、クライアントエージェントは、典型的にアプリケーション特有であることから、その使用は特定のプラットフォームに限られている。特にモバイルプラットフォームでは、ホストオペレーティングシステムの異機種性が一因となり、クライアントエージェントの実用性がかなり制限されることもある。この異機種性は、Ｗｉｎｄｏｗｓ（登録商標）、Ｓｙｍｂｉａｎ（登録商標）、および同様のものなどの「オープン」オペレーティングシステムの場合とは対照的に、「クローズド」オペレーティングシステム（Ｎｕｃｌｅｕｓなど）の場合にさらに悪化する。種々のモバイルハンドセットが異なるオペレーティングシステム上で実行され得ることから、典型的に、前述した実施例には、複雑なソフトウェア統合が必要となる。このソフトウェア統合は、非オープンオペレーティングシステム上で実行されるモバイルハンドセットを使用する場合、さらに複雑であると分かることもある。
【０００８】
デジタルコンテンツの配布には、コンテンツダウンロードおよびコンテンツストリーミングという少なくとも２つの異なる手法がある。一般的に言えば、コンテンツダウンロードとは、第１のデバイスに格納されているデジタルコンテンツを、転送されたデジタルコンテンツが格納される第２のデバイスへ転送することであると考えることができる。コンテンツダウンロードは、第１のデバイスから第２のデバイスへデジタルコンテンツを転送するための、「プッシュ」および「プル」の両方の手法を包含することができる。例えば、デジタルコンテンツの転送を開始するのが第１のデバイスであるということで、第１のデバイスに格納されているデジタルコンテンツが第１のデバイスから第２のデバイスに「プッシュされる」ことが可能である。あるいは、第１のデバイスから第２のデバイスへのデジタルコンテンツの転送を開始するのが第２のデバイスであるということで、第１のデバイスに格納されているデジタルコンテンツは、第１のデバイスから第２のデバイスにプルされることが可能である。プッシュまたはプルのどちらも、通常のダウンロード（ＨＴＴＰベースなど）によって、またはプログレッシブダウンロードテクノロジー（すなわち、コンテンツをダウンロードしている間に再生を開始する）によって実現することができる。いずれにせよ、デジタルコンテンツが第２のデバイスにて受け取られると、そのデジタルコンテンツは第２のデバイスにてローカルに永続的に格納される。こうすることで、第２のデバイスに格納されたデジタルコンテンツを１つのデジタルデバイスから別のデバイスに移動させることができ（完全にユーザの制御の下で）、ユーザのプライバシーが保護される（例えば、アダルトコンテンツの場合）などということになる。
【０００９】
しかし、１つの欠点は、「コンテンツをコピー」しようとする著作権侵害者の試みを阻止するためにコンテンツプロバイダ（例えば、ハリウッドスタジオなど）が高いセキュリティレベルを要求し、その結果コンテンツの移植性が制限されるということにある。ここでは、通常、デジタル著作権管理（ＤＲＭ）テクノロジーが、コンテンツの利用／コピーの制限を目的とした権利オブジェクト（ＲＯ）の定義を用いて介入する。ＤＲＭ  ＲＯは、典型的には、カリフォルニア州ミルピタスのサンディスク  コーポレイションによって製造されたＴｒｕｓｔｅｄＦｌａｓｈ（登録商標）メモリデバイスなどの専用ハードウェアソリューションと関係している。そのようなハードウェアソリューションは、本物のコンテンツおよびＲＯ移植性を提供するために、ユーザがリムーバブルメディア（例えば、ＳＤ（セキュアデジタル）記憶デバイス）上にＲＯをセキュアに格納できるようにする。しかし、現実には、ＲＯはＤＲＭ方式に依存し、全面的に採用されたＤＲＭ標準がない状態では、対応するＤＲＭテクノロジーをサポートするデジタルメディアプレーヤ（またはホストプラットフォーム）のみに完全な移植性が限定されるため、移植性は実現されていない。
【００１０】
コンテンツストリーミングは、少数の業界標準化プロトコル（例えば、ＲＴＳＰ／ＲＴＰなど）によって実装可能であるが、ユーザは、ストリーミングサーバへのネットワーク接続性を得ている場合にのみコンテンツにアクセスできることから、コンテンツを永続的にローカルに格納することは不可能である。この手法の利点の１つは、サポートされているストリーミングプロトコルに対応しているプレーヤに、広いコンテンツアクセスが保証されるということである（すなわち、レガシープレーヤの多くは標準のＲＴＳＰ／ＲＴＰを利用する）。コンテンツプロバイダのセキュリティ要件がより軽いことから、ストリーミングインターフェイスを通るコンテンツの「スニッフィングおよび記録」以外には、コンテンツコピーのリスクはほとんどまたは全くない。これは、制約のある環境と、クローズドであることの多いオペレーティングシステムとが、潜在的な著作権侵害に対して大きな障害となるモバイルデバイスに特に当てはまるが、保護されていないストリームの記録を広く利用可能なツールによってかなり容易に実行できるパーソナルコンピュータの場合はそうではない。
【００１１】
このようなリスクは、ストリーミングクライアントと、サーバとの間の相互認証（モバイルシステムでは必要と考えられることも、または考えられないこともある）によるセキュアな通信チャネルの構築などの、標準のサービスレベル保護によって部分的になくすことができる。しかし、この手法の欠点の１つは、接続されているデバイスのみがコンテンツにアクセスできる（接続性がないときはストリーミングサーバにアクセスできないため）ことから、完全な移植性（購入したコンテンツをユーザが制御する）を実装できないということである。さらに、この移植性の欠如によって、有効なビジネスモデルが制限される。さらに、サービスプロバイダがユーザの好みおよび利用を知ることになるため、プライバシーの侵害となり得る。
【００１２】
このコンセプトは、従来、予め静的に定められた物理メモリアレイに基づいて構築されるが、この物理メモリアレイの一部は、ホストファイルシステムから、したがってユーザから隠され、ユーザのリクエストに応じてのみ有効化が可能である。そのようなユーザのリクエストは、デバイスコントローラによってリモートで開始可能であり、支払いを含むこともある。しかし、この手法には、重要なこととして以下のことを含むいくつかの欠点がある。製造されるメモリアレイのサイズが生産時に決定され、その結果ユーザは、所定の隠し容量を超えてメモリアレイの記憶容量をそれ以上拡大できず、すなわち利用に柔軟性などがなく、さらに、隠しメモリと公開メモリとの比率が、生産時、またはいずれにせよローカル記憶デバイスがユーザに届く前には決定されている。例として、デバイスのベンダは、２ＧＢの総記憶容量をそれぞれ有するいくつかのメモリデバイスを製造することもある。しかし、このメモリデバイスは、１ＧＢのメモリデバイスとして販売されることもあり、残りの１ＧＢは、ユーザから隠されるか、または少なくともユーザがアクセスできない状態にされる。ユーザが支払いを行うと２番目の１ＧＢがアクセス可能になる場合であっても、メモリデバイスの製造業者はリスクを負う。つまり、ユーザはまず製造業者に支払いを行わなければ２番目の隠された１ＧＢにアクセスできない。
【００１３】
このような、物理的に拡張可能な記憶デバイスの限界を克服する１つの方法が、ローカル（すなわち、レガシー大容量記憶装置コマンドを介してエージェントによりアクセスされる）またはリモート（すなわち、ネットワークプロトコルを介してエージェントによりアクセスされる）にかかわらず記憶装置の抽象化を提供する、ホストに統合された専有クライアントエージェントによるものである。この特定の手法は、Ｐｅｒｓｏｎａｌｉｔｅ  Ｎｕｍｅｒｉｑｕｅ製造の、仏国公開特許出願第０４１２１９９号（特許文献１）に記載されているものなど、様々な製品において実装されてきた。しかし、クライアントエージェントは典型的にアプリケーション特有であることから、その使用は特定のプラットフォームに限られている。特にモバイルプラットフォームでは、ホストオペレーティングシステムの異機種性が一因となり、クライアントエージェントの実用性がかなり制限されることもある。さらに、種々のモバイルハンドセットが、異なる様々なオペレーティングシステム上で実行され得ることから、前述したような実施例には、典型的に複雑なソフトウェア統合が必要となる。このソフトウェア統合は一般的に、Ｗｉｎｄｏｗｓ、Ｓｙｍｂｉａｎ、および同様のものなどの「オープン」オペレーティングシステムのものとは対照的に、「クローズド」オペレーティングシステム（Ｎｕｃｌｅｕｓなど）上で実行されるモバイルハンドセットが使用される場合、さらに複雑であることが分かっている。
【００１４】
したがって、前述した制限を克服する一方で、依然としてレガシーＬＢＡ／大容量記憶モードでの動作可能性を提供する（すなわち、流通している従来のホストファイルシステムに対応する）方法、システムおよび装置が望まれている。
大容量記憶デバイス（ＳＤおよびＭＭＣ（マルチメディアカード）タイプの大容量記憶デバイスを含むＦＬＡＳＨメモリデバイスなど）は、記憶容量と、関連した大容量記憶デバイスコントローラの能力（すなわち、処理リソース）との両方において大きく拡大した。このような利用可能な記憶容量の拡大は、利用可能なメモリに能力が大きく左右されるデバイス（「ホストデバイス」）の全般的な利用可能性に相乗効果をもたらした。前述したデバイスには、携帯メディアプレーヤなどの携帯デジタルデバイス、インタラクティブパーソナル通信デバイス（携帯電話、ＰＤＡ（個人用携帯情報端末）など）、および同様のものがある。こうして、フラッシュメモリなどの大容量記憶デバイスの記憶能力を使用するデジタル製品にデジタルコンシューマが接触することが非常に増えた。
【００１５】
このような接触は主として、接続または未接続の複数のホストデバイスにまで広がったり、有線対無線、固定対モバイルなどの複数アクセスモードにまで広がったりしている。そのそれぞれは特有の記憶要件を有する。大容量記憶デバイス上に格納されているデータのインデックス生成に対して提案されている構成は、一般に、各ホストデバイスに対して異なるホスト特有プログラムを使用することを含む。当該プログラムは、典型的には、ホストデバイス上、および／またはホストデバイスが常にもしくは時々接続されるリモートサーバ上にインストールされる。
【００１６】
その結果、提案されているインデックス付け構成は、概して、ホストデバイスに密結合されたプログラムを含む。したがって、例えば、ホストデバイスに密結合されているそのようなインデックス付けプログラムは、一般に、当該ホストデバイスとともに動作するようにカスタマイズされなければならない。さらに、データのインデックス付けにおけるホストデバイスの関与が大きいと、他の機能に望まれ得るかまたは必要とされ得るホストデバイスの処理能力が、奪われる可能性がある。
【００１７】
レガシーインデックス付け構成について考えられるもう１つの欠点は、例えばモバイルホストデバイスがＵＳＢケーブルを介してコンピュータに接続され、コンテンツが記憶デバイスに格納される「コンテンツサイドロード」に見られる。この場合、デバイスを管理するのは、モバイルホストが接続されているコンピュータのファイルシステムであり、結果として、モバイルインデックス付けアプリケーションは、コンピュータによって実行される記憶動作を感知しないため、コンテンツにインデックス付けを行わない。
【００１８】
典型的には周知の標準に従う「バス」と呼ばれる複数の導線を使用して、ホストプロセッサを種々のデバイスに接続することは、普通のこととなった。バスに接続されるデバイスには、メモリ／記憶デバイス、通信デバイス、検出デバイスなどが含まれると考えられ、こうしたデバイスは、固定またはリムーバブルのいずれでもよい。多くの場合、バスを定義するワイヤの一部または全部が、バスに接続されているデバイスのいずれかおよび／または全部に共有される。バスに結合されているデバイスは、同じ導線を共有することから、各デバイスは、典型的に一意のＩＤまたはバス上のアドレスを付与され、その一意のＩＤ／アドレスに宛てられたメッセージのみに応答するように設定される。このようにして、バスを形成する同じ導線を複数のデバイスが共有することができ、そうでない場合に必要とされるバスサイズよりも大幅に縮小されたバスサイズがもたらされる。
【００１９】
典型的に、バスにはマスタ／スレイブバスプロトコルが採用される。マスタ／スレイブは、１つのデバイスまたはプロセスが、１つ以上の他のデバイスに対して一方向の制御権を有する通信プロトコルのモデルである。従来のシステムでは、デバイス間またはプロセス間のマスタ／スレイブ関係が確立されると、制御の方向は常にマスタからスレイブであり、すなわち、スレイブはトランザクションを開始できない。一部のシステムでは、適格な複数デバイスのグループからマスタが選ばれ、他のデバイスはスレイブの役割を果たす。従来のシステムでは、データがスレイブデバイス間で直接転送されることはない。代わりに、データは典型的に、共通バス上でソーススレーブ記憶デバイスからホストコントローラまたはそのほかの中間段階へ渡され、データはそこに一時的にキャッシュされてから、ホストコントローラによって共通バス上に再出力されて宛先スレイブ記憶デバイスがターゲットとされ、続いて宛先スレイブ記憶デバイスにおいてデータがバスから読み込まれて格納される。
【００２０】
従来のシステムは十分に機能するが、デバイス間でデータを転送するのに必要なホストＣＰＵリソースを軽減し、さらにホストおよび／または他の一時記憶デバイスのバス利用およびメモリ要件を軽減することが望ましい。
市場に出ている携帯形（すなわち、小さな形態的要素でハンドヘルドの）コンシューマ電子製品の数および種類は急増している。こうした携帯コンシューマ電子製品には、例えば、ＰＤＡ、メディアプレーヤ、セルラー電話、およびカメラがある。競争および他の理由から、こうしたコンシューマ電子製品の機能性が拡大されてきた。例えば、セルラー電話にＰＤＡおよびカメラの機能性が追加され、ＰＤＡにセルラー電話および音楽プレーヤの機能性が追加され、メディアプレーヤにＰＤＡおよびビデオゲームの機能性が追加されるなどしている。
【００２１】
携帯コンシューマ電子製品は、その主要機能を提供するために、ホストデバイスを使用してホストアプリケーションを実行し、ホストアプリケーションは従来の大容量記憶デバイスに格納されているコンテンツを使用する。その結果として、ホストアプリケーションは、ハンドヘルドコンシューマ製品の主要機能に直接関係するコアサービスと、記憶デバイスに格納されているコンテンツの操作および管理に関係する補助サービスとの両方を提供することができる。例えば、メディアプレーヤがＭＰ３ファイルなどのメディアファイルを再生するために、ホストアプリケーションは、メディアプレーヤアプリケーションという形のコアアプリケーションを使用して、記憶デバイスに格納されている音楽ファイル（ＭＰ３ファイル形式）を読み出して再生することができる。ホストアプリケーションは、補助サービスアプリケーションを使用して、記憶デバイスに格納されている音楽ファイルを管理する機能をユーザに提供することもできる。そのようなユーザ管理には、プレイリストの操作および生成、特定の音楽ファイル、音楽ジャンル、アーティストなどの並べ替えおよび検索が含まれ得る。イメージ（静止およびビデオの両方）を表示するように構成されているメディアプレーヤの場合には、コアアプリケーションは、赤目軽減、白黒変換、イメージクロッピング、および回転などの修整機能をユーザに提供するフォト表示・編集用アプリケーションという形をとることができる。関連の補助サービスアプリケーションは、ユーザがイメージの並べ替え、記憶、および分類を行えるようにするイメージおよび／またはビデオ管理プログラムという形をとることができる。
【００２２】
したがって、コアサービス（ＭＰ３ファイルの再生、イメージファイルの表示、またはビデオファイル（ＭＰ４）の再生など）と、コンテンツ管理および操作に関係する補助サービス（イメージの並べ替えおよび分類、ＭＰ３ファイルの並べ替え、プレイリストの編集、コンテンツ検索、インデックス付けなど）との両方を提供するには、ホストアプリケーションを要求することができる。なお、ホストアプリケーションがコアサービスを提供するように要求されるか、または補助サービスを提供するように要求されるかにかかわらず、ホストアプリケーションは、記憶デバイス内に格納されているデータにアクセスしなければならない。記憶デバイスには、論理ブロックフォーマットを使用してすべてのファイルが格納されている。典型的には、データを論理ブロックフォーマットで格納することによってコアアプリケーション（例えば、音楽ファイルの再生）に過度の負担がもたらされることはないが、大容量記憶デバイスが、論理ファイルレベルではなく大容量記憶デバイスブロックの粒度で動作することから、補助サービスが最適に構成されない可能性がある。多くのファイル（ＭＰ３など）は所定サイズのものであり、こうしたファイルは、従来の大容量記憶デバイスによって強いられる論理ブロックとしてではなくデータオブジェクトとして格納されるほうがより自然であることから、特に当てはまる。
【００２３】
こうした携帯製品は、処理リソースおよび利用可能なＲＡＭの両方が限られていることから、論理ブロックとして格納されているが、データオブジェクトとして格納されたほうがより自然であろうデータを、ホストアプリケーション（特に、補助アプリケーション）が処理することを必要とするプロセス集中形のタスクの実行を携帯コンシューマ電子製品が要求されると、問題が生じる恐れがある。特に、補助サービスとの関連でホストの処理リソースを最も消費するのは、典型的に検索／クエリ動作（すなわち、「読み込み関係」コマンド）であり、これは、ホストプロセッサによる過度の電力消費につながる恐れがあり、さらに、実行時間が長くなり、結果として応答性が遅くなる恐れがある。こうして、ユーザは通常、遅くてバッテリー寿命が短い製品を好まないことから、ユーザが不快なユーザ体験をすることになる恐れがある。
したがって、こうした欠点に対処するインデックス付け方法、システム、および装置が望まれる。
【先行技術文献】
【特許文献】
【００２４】
【特許文献１】仏国公開特許出願第０４１２１９９号
【特許文献２】米国特許出願第１２／０２９，３５６号
【発明の概要】
【００２５】
本発明の種々の実施形態により、分散形記憶サービスを提供する様々な方法、デバイスおよびシステムについて開示する。前述したサービスには、ローカル記憶デバイスとエンドユーザとの直接対話を提供することが含まれる。
【００２６】
本発明の一実施形態では、少なくともホストデバイス（ＨＤ）およびＨＤに管理されているローカル記憶デバイス（ＬＳＤ）を備えるコンピューティングシステムについて記載する。ＬＳＤは、ＨＤによって提供される当該インターフェイス以外にはＨＤの外部にあるデバイスに対する何らのインターフェイスも利用しない。ＬＳＤは、ＬＳＤ論理リクエストを使用して、ＬＳＤと起動アプリケーション (launching application)との間に通信パスを確立するようにＨＤに指示することで、ＨＤにリクエストされたプロセスの実行を間接的に指示する。ＬＳＤおよび起動アプリケーションは、ＨＤによる介入なしに通信パス上で論理的に対話する。論理的対話は、リクエストされたプロセスをＨＤが実行するように起動アプリケーションに指示させる。
【００２７】
本発明の一態様において、起動アプリケーションは、ＨＤによって管理されるＳＩＭ（加入者識別モジュール）カードに関連する。ＳＩＭカードは、ＳＩＭアプリケーションツールキットコマンドセットまたはＵＳＩＭアプリケーションツールキットセットコマンドセット準拠とすることができる。
【００２８】
別の実施形態では、コンピューティングシステムにおいて、リクエストされたプロセスを実行するように間接的にＨＤに指示する方法について記載する。コンピューティングシステムは、ホストデバイス（ＨＤ）と、ＨＤによって管理されているローカル記憶デバイス（ＬＳＤ）とを備え、ＬＳＤは、ＨＤによって提供される当該インターフェイス以外にはＨＤの外部にあるデバイスに対する何らのインターフェイスも利用しない。この方法は、少なくとも以下の動作、すなわち、
ＨＤによって開始されたプロセスに役立つように作成されるものではないＬＳＤ論理リクエストを使用して、ＬＳＤと起動アプリケーションとの間に通信パスを確立するようにＨＤに指示することと、通信パス上で論理的に対話することと、リクエストされたプロセスをＨＤが実行するように起動アプリケーションに指示させることと、リクエストされたプロセスを実行することとによって実行される。
【００２９】
本発明の種々の実施形態による、改善されたインターネットアプリケーション（ブラウザなど）パフォーマンスを提供する様々な方法、デバイスおよびシステムについて記載する。一実施形態では、ローカル記憶デバイス（ＬＳＤ）について記載する。ＬＳＤは、互いに独立して管理されている、少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイを少なくとも含む。第１のアプリケーションは、第１の部分内の第１のアプリケーションコンテンツを管理し、第２のアプリケーションは、第２の部分内の第２のアプリケーションコンテンツを管理する。第１および第２のアプリケーションは、互いに独立して実行され、第１のアプリケーションコンテンツの第１のアプリケーションによる管理は、第２のアプリケーションコンテンツの第２のアプリケーションによる管理から独立している。ＬＳＤは、ホストデバイスから独立して、第１の部分に格納されている第１のアプリケーションコンテンツを第２のアプリケーションに通知する。
【００３０】
別の実施形態では、ホストデバイスファイルシステム（ＨＤＦＳ）およびネットワークインターフェイスを含むホストデバイスと、少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイを含むローカル記憶デバイスＬＳＤとを少なくとも備えるコンピューティングシステムについて記載し、第１および第２の部分は互いに独立して管理される。第１の部分は、第１のアプリケーションがＨＤＦＳを使用して第１の部分内の第１のアプリケーションコンテンツを管理するように、ＨＤＦＳによって管理され、第２の部分は、第２の部分がＨＤＦＳに認識されないように、ＨＤＦＳによって管理されない。第１および第２のアプリケーションは、互いに独立して実行され、第１のアプリケーションコンテンツの第１のアプリケーションによる管理は、第２のアプリケーションコンテンツの第２のアプリケーションによる管理から独立している。ＬＳＤは、第１の部分において利用可能な第１のアプリケーションコンテンツを第２のアプリケーションに通知し、この通知はＨＤから独立している。
【００３１】
ローカル記憶デバイス（ＬＳＤ）によって実行される方法について記載する。ＬＳＤは、少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイを含み、第１および第２の部分は、互いに独立して管理され、第１のアプリケーションが、第１の部分内の第１のアプリケーションコンテンツを管理し、第２のアプリケーションが、第２の部分内の第２のアプリケーションコンテンツを管理する。第１および第２のアプリケーションは、互いに独立して実行され、第１のアプリケーションコンテンツの第１のアプリケーションによる管理は、第２のアプリケーションコンテンツの第２のアプリケーションによる管理から独立している。この方法は、少なくとも以下の動作、すなわち、ＬＳＤによって、第１の部分内に格納されている第１のアプリケーションコンテンツをホストデバイスから独立して第２のアプリケーションに通知することによって実行される。
【００３２】
別の実施形態では、ホストデバイス（ＨＤ）と通信しているローカル記憶デバイス（ＬＳＤ）を備えるシステムによって実行されるコンピュータプログラム製品について記載する。ＬＳＤは、互いに独立した、少なくとも第１の部分および少なくとも第２の部分を含むように論理的に構成されたメモリアレイを含む。第１のアプリケーションは、第１の部分内の第１のアプリケーションコンテンツを管理し、第２のアプリケーションは、第２の部分内の第２のアプリケーションコンテンツを管理する。第１および第２のアプリケーションは、互いに独立して実行され、第１のアプリケーションコンテンツの第１のアプリケーションによる管理は、第２のアプリケーションコンテンツの第２のアプリケーションによる管理から独立している。このコンピュータプログラム製品は、ＬＳＤによって、第１の部分内に格納されている第１のアプリケーションコンテンツを第２のアプリケーションに通知するコンピュータコードと、このコンピュータコードを格納するコンピュータ可読媒体とを含み、通知はＨＤから独立している。
【００３３】
本発明の種々の実施形態による、保護されているデジタルコンテンツをセキュアに配布および消費する様々な方法、デバイスおよびシステムについて記載する。一実施形態では、デジタルコンテンツプロバイダによってＤＲＭ方式に従い少なくとも１つの制限が加えられた、保護されているデジタルコンテンツを取得および消費する方法について記載する。この方法は、メモリアレイを有するローカル記憶デバイス（ＬＳＤ）を備えるシステムによって実行可能であり、ＬＳＤは、メモリアレイの少なくとも一部分を管理するように構成されているホストデバイスファイルシステム（ＨＤＦＳ）を少なくとも有するホストデバイス（ＨＤ）と結合されている。この方法は、保護されているデジタルコンテンツをＬＳＤによって取得すること、取得された保護されているデジタルコンテンツをＬＳＤによってメモリアレイにセキュアに格納すること、および保護されているデジタルコンテンツを消費することによって実行でき、当該取得することおよびセキュアに格納することといった動作はそれぞれ、ＤＲＭ方式に従い、どちらもＨＤＦＳによって開始されるものではない。保護されているデジタルコンテンツの消費は、セキュアに格納された保護されているデジタルコンテンツの少なくとも一部をデジタルデータストリームに変換することと、そのデジタルデータストリームをＬＳＤによってストリーミングすることとによって実行可能である。デジタルデータストリームに、使用制限である少なくとも１つの制限が加えられていれば、ＬＳＤはその使用制限を強制する。
【００３４】
別の実施形態では、デジタルコンテンツプロバイダによってＤＲＭ方式に従い少なくとも１つの制限が加えられた、保護されているデジタルコンテンツを取得および消費するためのコンピュータプログラム製品について記載する。このコンピュータプログラム製品は、メモリアレイを有するローカル記憶デバイス（ＬＳＤ）を備えるシステムに含まれているプロセッサによって実行可能であり、ＬＳＤは、メモリアレイの少なくとも一部分を管理するように構成されているホストデバイスファイルシステム（ＨＤＦＳ）を少なくとも有するホストデバイス（ＨＤ）と結合されている。このコンピュータプログラム製品は、保護されているデジタルコンテンツをＬＳＤによって取得するためのコンピュータコードと、取得された保護されているデジタルコンテンツをＬＳＤによってメモリアレイにセキュアに格納するためのコンピュータコードであって、当該取得することおよびセキュアに格納することはそれぞれ、ＤＲＭ方式に従い、どちらもＨＤＦＳによって開始されるものではないコンピュータコードと、セキュアに格納された保護されているデジタルコンテンツの少なくとも一部をデジタルデータストリームに変換して、このデジタルデータストリームをＬＳＤによってストリーミングすることによって、保護されているデジタルコンテンツを消費するためのコンピュータコードであって、このデジタルデータストリームに、使用制限である少なくとも１つの制限が加えられていれば、ＬＳＤはその使用制限を強制するものであるコンピュータコードと、コンピュータコードを格納するコンピュータ可読媒体とを少なくとも含む。
【００３５】
さらに別の実施形態では、デジタルコンテンツプロバイダによってＤＲＭ方式に従い少なくとも１つの制限が加えられた、保護されているデジタルコンテンツを取得および消費するためのシステムについて記載する。このシステムは、少なくともホストデバイスファイルシステム（ＨＤＦＳ）を有するホストデバイス（ＨＤ）と、メモリアレイを含みホストデバイス（ＨＤ）と結合されているローカル記憶デバイス（ＬＳＤ）とを含み、メモリアレイの少なくとも一部分はＨＤＦＳによって管理されている。ＬＳＤは、保護されているデジタルコンテンツを取得し、メモリアレイにセキュアに格納し、当該取得することおよびセキュアに格納することはそれぞれ、ＤＲＭ方式に従い、どちらもＨＤＦＳによって開始されるものではない。保護されているデジタルコンテンツは、セキュアに格納された保護されているデジタルコンテンツの少なくとも一部をデジタルデータストリームに変換することと、そのデジタルデータストリームをＬＳＤによってストリーミングすることとによって消費される。デジタルデータストリームに、使用制限である少なくとも１つの制限が加えられていれば、ＬＳＤはその使用制限を強制する。
【００３６】
さらに別の実施形態では、コンピューティングシステムについて記載する。このコンピューティングシステムは、少なくともホストデバイスファイルシステムおよびＬＳＤドライバを有するホストデバイス（ＨＤ）と、ホストデバイスファイルシステム（ＨＤＦＳ）によって管理される少なくとも１つの記憶エリアを有するローカル記憶デバイス（ＬＳＤ）と、ＬＳＤの外部にありＨＤと通信しているリクエスト元アプリケーションとを備え、リクエスト元アプリケーションは、ＨＤＦＳまたはＬＳＤドライバのいずれとも、何らの通信パスも利用しない。リクエスト元アプリケーションは、ＨＤＦＳによる介入なしに、少なくとも１つの記憶エリアに格納されているデータの選択された部分を、ＬＳＤに強制的に読み込ませ、次にＬＳＤは、少なくとも１つの記憶エリアから読み込まれた選択されたデータを外部アプリケーションにストリーミングする。
【００３７】
本発明の一態様では、少なくとも１つの記憶エリアに格納されたデータの選択された部分が、デジタルコンテンツプロバイダによってＤＲＭ方式に従い少なくとも１つの制限が加えられた、保護されているデジタルコンテンツであれば、ＬＳＤは、少なくとも１つの記憶エリアから読み込まれた保護されているデジタルコンテンツを、少なくとも１つの制限が加えられているデジタルデータストリームに変換することによって、少なくとも１つの記憶エリアから読み込まれた保護されているデジタルコンテンツを外部アプリケーションにストリーミングする。デジタルデータストリームに加えられている少なくとも１つの制限が使用制限であれば、ＬＳＤはその使用制限を強制する。
【００３８】
本発明の特定の実施形態による、ホストデバイス（ＨＤ）からローカル記憶デバイス（ＬＳＤ）へ送られる管理コマンドを処理する様々な方法、デバイスおよびシステムについて記載する。一態様では、ホストデバイス（ＨＤ）内のホストデバイスファイルシステム（ＨＤＦＳ）から送られた管理コマンドを、ＨＤと通信しているローカル記憶デバイス（ＬＳＤ）によって処理する方法について記載する。この方法は、関連した論理アドレスに対して動作を実行するようにＬＳＤに命令する第１の管理コマンドをＬＳＤにて受け取ることを含む。第１の管理コマンドが論理アドレスの少なくとも第１のセットと関連していれば、この方法は、少なくとも、リモートデバイス（ＲＤ）内のメモリ位置に対して動作を実行するようにＲＤに命令する第２の管理コマンドをＬＳＤの外部にあるＲＤに送ることによって、第１の管理コマンドをＬＳＤによって処理することを含む。様々な実施形態において、第２の管理コマンドをＲＤへ送ることおよび第１の管理コマンドに関連した動作をＲＤ内のメモリ位置に対して実行することは、ＨＤＦＳに認識されない。第１の管理コマンドが、論理アドレスの第１のセットと関連していなければ、この方法は、ＬＳＤ内のメモリ位置に対してＬＳＤによって実行される動作によってのみ、ＬＳＤによって第１の管理コマンドを処理することを含む。様々な実施形態おいて、ＬＳＤは、ＨＤを介して提供される物理インターフェイス以外には、ＬＳＤの外部にある他のいかなるデバイスに対して、他の何らの物理インターフェイスも利用しない。
【００３９】
特定の実施形態によれば、管理コマンドが、論理アドレスの少なくとも第１のセットと関連していれば、この方法は、ＬＳＤによって、ＬＳＤとＲＤとの間にＨＤを介する通信パスを確立するようにＨＤに指示することをさらに含む。好適な実施形態では、通信パスが確立されると、その通信パスの保持を除いて、ＨＤによるそれ以上の介入は必要ない。
【００４０】
本発明のシステムの態様において、少なくともホストデバイスファイルシステム（ＨＤＦＳ）を有するホストデバイス（ＨＤ）と、ＨＤ／ＬＳＤインターフェイスを用いてＨＤと結合されたローカル記憶デバイス（ＬＳＤ）とを備えるコンピューティングシステムについて記載する。ＬＳＤは、メモリアレイと、このメモリアレイをローカルで管理するように構成されているＬＳＤコントローラとを含む。メモリアレイは、ＨＤ／ＬＳＤインターフェイスを経由してＬＳＤコントローラに管理コマンドを送ることによって、ＬＳＤコントローラを介してＨＤＦＳにより外部から管理される、少なくとも１つの大容量記憶領域を含むように論理的に構成されている。管理コマンドは、関連したメモリアドレス上で動作を実行するように、ＬＳＤに命令するとよい。特定の実施形態によれば、ＨＤＦＳから受け取られた第１の管理コマンドが論理アドレスの少なくとも第１のセットに関連するとＬＳＤコントローラが判断すれば、ＬＳＤコントローラは少なくとも、ＬＳＤの外部にあるデバイス（ＲＤ）に、ＲＤ内のメモリ位置に対して動作を実行するようにＲＤに命令する第２の管理コマンドを送ることによって、第１の管理コマンドを処理し、ＲＤへ第２の管理コマンドを送ること、および第１の管理コマンドに関連した動作をＲＤ内のメモリ位置に対して実行することは、ＨＤＦＳに認識されない。さらに、一部の実施形態では、ＨＤＦＳから受け取られた第１の管理コマンドが、論理アドレスの少なくとも第２の部分に関連するとＬＳＤコントローラが判断すると、ＬＳＤコントローラは、ＬＳＤ大容量記憶領域内のメモリ位置に対してＬＳＤによって実行される動作によって、第１の管理コマンドを処理する。
【００４１】
別の態様では、少なくともホストデバイスファイルシステム（ＨＤＦＳ）を有するホストデバイス（ＨＤ）を備えるコンピュータシステムについて記載する。このシステムは、ＨＤ／ＬＳＤインターフェイスを用いてＨＤに結合されたローカル記憶デバイス（ＬＳＤ）をさらに含み、ＬＳＤは、メモリアレイと、メモリアレイをローカルで管理するように構成されているＬＳＤコントローラとを含み、かつＨＤ／ＬＳＤインターフェイスを経由してＬＳＤコントローラへ管理コマンドを送ることによって、ＨＤＦＳによりＬＳＤコントローラを介して外部から管理される、少なくとも１つの大容量記憶領域を含むように論理的に構成されている。様々な実施形態において、ＨＤＦＳは、第２の管理コマンドをリモートデバイス（ＲＤ）に送信するようにＬＳＤに命令する第１の管理コマンドをＬＳＤに送ることによって、ＬＳＤの外部にあるＲＤを、ＬＳＤを介して管理するようにさらに設定されている。
【００４２】
さらに別の態様において、ＬＳＤと通信しているホストデバイス（ＨＤ）内のホストデバイスファイルシステム（ＨＤＦＳ）から送られた管理コマンドを処理するように、ローカル記憶デバイス（ＬＳＤ）内の１つ以上の有形媒体に符号化された論理について記載する。この論理は実行されると、ＬＳＤにて、関連した論理アドレス上で動作を実行するようにＬＳＤに命令する第１の管理コマンドを受け取り、第１の管理コマンドが論理アドレスの少なくとも第１のセットに関連していれば、少なくとも、リモートデバイス（ＲＤ）内のメモリ位置に対して動作を実行するようにＲＤに命令する第２の管理コマンドを、ＬＳＤの外部にあるＲＤに送ることによって、第１の管理コマンドをＬＳＤによって処理し、ＲＤへ第２の管理コマンドを送ること、および第１の管理コマンドに関連した動作をＲＤ内のメモリ位置に対して実行することは、ＨＤＦＳに認識されず、第１の管理コマンドが論理アドレスの少なくとも第１のセットに関連していなければ、ＬＳＤ内のメモリ位置に対してＬＳＤによって実行される動作によってのみ、ＬＳＤによって第１の管理コマンドを処理するように動作可能である。
【００４３】
一態様に従い、ホストデバイス（ＨＤ）を有するコンピューティングデバイスは、ローカル記憶デバイス（ＬＳＤ）と通信し、ＬＳＤはメモリアレイを含む。方法は、ＬＳＤのメモリアレイに格納されたデータに関する検索インデックスを生成するように動作する。ＬＳＤによって、ＨＤの関与なしに、ＬＳＤのメモリアレイに格納されたデータに関してインデックスデータが生成される。生成されたインデックスデータは、ＬＳＤによって、少なくとも検索インデックスの一部としてＬＳＤ上に格納される。このインデックスは、ＬＳＤのデータに関する検索クエリに応答するために使用可能なデータを含むとよい。クエリは、ＨＤからまたはＬＳＤ内から生じるとよい。インデックスの使用は、検索クエリへの応答に限定されない。例えば、インデックスは、コンテンツの選別に使用され得る。
【００４４】
種々の実施形態による、記憶サービスを提供する様々な方法、デバイスおよびシステムについて記載する。一実施形態は、システムについて記載する。このシステムは、少なくとも、データ記憶アレイ、論理データブロックとしてデータ記憶アレイに格納されているデータを管理するのに適した第１の論理インターフェイスと、論理データブロックとして格納されているデータに対応するデータオブジェクトを管理するのに適した第２の論理インターフェイスとを備える。論理データブロックとして格納されているデータの少なくとも一部が、第１のインターフェイスを経由して変更されると、変更されたデータは、第１および第２のインターフェイスの両方を経由してアクセス可能であり、第２のインターフェイスを経由してアクセス可能であることは、データオブジェクトプロパティの所定のセットを同時に管理することを伴う。
【００４５】
別の実施形態では、ローカル記憶デバイス（ＬＳＤ）について記載する。このローカル記憶デバイスは、データ記憶アレイ、論理データブロックとしてデータ記憶アレイに格納されているデータを管理するのに適した第１の論理インターフェイスと、論理データブロックとして格納されているデータに対応するデータオブジェクトを管理するのに適した第２の論理インターフェイスとを備える。論理データブロックとして格納されたデータの少なくとも一部が、第１のインターフェイスを経由して変更されると、変更されたデータは、第１および第２のインターフェイスの両方を経由してアクセス可能である。第２のインターフェイスを経由してアクセス可能であることは、データオブジェクトプロパティの所定のセットを同時に管理することを伴う。
【００４６】
さらに別の実施形態では、方法について記載する。この方法は、データ記憶アレイにおいて少なくとも以下の動作を実行することによって実行される。論理データブロックとしてデータ記憶アレイに格納されているデータを第１のインターフェイスを経由して管理することと、データ記憶アレイに格納されているデータオブジェクトを第２のインターフェイスを経由して管理することとであり、データオブジェクトは、論理データブロックとして格納されているデータに対応する。論理データブロックとして格納されたデータが、第１のインターフェイスを経由して変更されると、変更されたデータは、第１および第２のインターフェイスの両方を経由してアクセス可能である。第２のインターフェイスを経由してアクセス可能であることは、データオブジェクトプロパティの所定のセットを同時に管理することを伴う。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施形態に従ったシステムの象徴的表現を示す。
【図２Ａ】本発明の実施形態に従ったホストデバイス／ローカル記憶デバイスシステムを示す。
【図２Ｂ】本発明の実施形態に従ったホストデバイス／ローカル記憶デバイスシステムを示す。
【図２Ｃ】本発明の実施形態に従ったホストデバイス／ローカル記憶デバイスシステムを示す。
【図３Ａ】本発明の実施形態に従ったコンピューティングシステムを示す。
【図３Ｂ】本発明の実施形態に従ったコンピューティングシステムを示す。
【図４】本発明の実施形態に従ったコンピューティングシステムを示す。
【図５Ａ】図３に示されているネットワークのさらに詳細な図を示す。
【図５Ｂ】図３に示されているネットワークのさらに詳細な図を示す。
【図６】本発明の実施形態に従ったプロセスを詳述するフローチャートを示す。
【図７】本発明の実施形態に従ったプロセスを詳述するフローチャートを示す。
【図８】本発明の実施形態に従った典型的なメディアネットワークを示す。
【図９】本発明に従った典型的なコンピューティングシステムを示す。
【図１０】図９に示されているコンピューティングシステムの特定の実施例を示す。
【図１１】本発明の実施形態に従ったローカル記憶デバイスの典型的な実施例を示す。
【図１２Ａ】本発明の実施形態を示す。
【図１２Ｂ】本発明の実施形態を示す。
【図１３】本発明の実施形態に従ったホストデバイス／ローカル記憶デバイスシステムを示す。
【図１４Ａ】本発明の実施形態に従ったローカル記憶デバイス（ＬＳＤ）のマッピングテーブルの図表現を示す。
【図１４Ｂ】本発明の実施形態に従ったローカル記憶デバイス（ＬＳＤ）の把握される記憶容量の図表現を示す。
【図１５】本発明の実施形態に従った管理コマンドを処理するプロセスを示すフローチャートである。
【図１６】図１５のプロセスで使用するのに適したシステムを示す。
【図１７】ＬＳＤのメモリアレイに格納されたデータにインデックスを付けるようにＬＳＤが設定されている、ホストデバイス（ＨＤ）およびローカル記憶デバイスを含むコンピューティングシステムを示す。
【図１８】ＨＤによるＬＳＤに対するデータアクセスに基づきインデックスデータが生成される例を示す。
【図１９】インデックス付けデータがＨＤにより獲得および／または使用され得るシステムの構成例を示す。
【図２０】インデックス付けデータがマスタ／スレイブパラダイム外の外部デバイスに転送されることが可能な構成例を示す。
【図２１】ＬＳＤのメモリアレイに格納されたデータを示すインデックス付けデータをＬＳＤが判断していける方法を広い見方で示すフローチャートである。
【図２２】本発明の実施形態に従ったシステムの簡略化したブロック図を示す。
【図２３】本発明の実施形態に従った記憶デバイスの例の簡略化したブロック図を示す。
【図２４】記憶デバイス間で直接データを転送するプロセスを示すフローチャートを示す。
【図２５】本発明の実施形態に従ったデイジーチェーン構成で配列された複数の記憶デバイスを含むシステムの簡略化したブロック図を示す。
【図２６】ホストデバイス（ＨＤ）およびローカル記憶デバイス（ＬＳＤ）を含むシステムを示す。
【図２７】同期化装置の実施形態である。
【図２８】記載される実施形態との関連で実行可能な様々な動作を示す。
【図２９】記載される実施形態との関連で実行可能な様々な動作を示す。
【図３０】記載される実施形態に従ったフローチャートを示す。
【図３１】ホストデバイス２０４において典型的に見られる追加コンポーネントを示す典型的なシステム９００を示す。
【発明を実施するための形態】
【００４８】
以下、本発明の特定の実施形態を詳しく参照するが、その例が添付の図面に示されている。本発明について、特定の実施形態と併せて記載するが、当然のことながら、記載されている実施形態に本発明を限定することを目的としていない。反対に、添付の特許請求の範囲によって定義される本発明の意図および範囲内に含まれると考えられる代替物、変更物、等価物を対象とするものとする。なお、本願明細書に記載されるいずれの機能ブロックまたは機能構成も、物理エンティティもしくは論理エンティティのいずれかとして、または両方の組み合わせとして実装することができる。
【００４９】
記憶デバイスコントローラの能力が向上することで、記憶デバイスコントローラによって利用可能にされる処理リソースを使用して記憶デバイス内からソフトウェアアプリケーションを実行することが可能になる。このような記憶デバイスコントローラの運用性の強化により、ユーザ指向の記憶サービスなど、新たな（かつ従来は実行不可能であった）対話モードのパラダイムがもたらされる。このようなユーザ指向の記憶サービスは、主として、特有の記憶要件をそれぞれが有する、接続もしくは未接続の複数のデバイスにまで広がったり、または有線対無線、固定対モバイルなどの複数アクセスモードにまで広がったりしている、ユーザのデジタルコンテンツ消費体験を改善するために使用することができる。
【００５０】
「ユーザ中心」（従来の「デバイス中心」とは対照的）の記憶管理手法のサポートを提供するために、本発明は、ホストにより管理されるＬＢＡベースの大容量記憶パラダイムの厳しい制限を越えて、レガシー大容量記憶デバイスと完全な下位互換性があると同時に他の種類の対話を用いて大容量記憶装置を強化する記憶サービスパラダイムを提供する。他の種類の対話は、例えば、記憶リソースおよびサービス構築ブロックを、場合によっては様々な物理的位置（すなわち、データ記憶デバイス、ホストコンピュータ内、またはネットワーク中）にわたって分散させることを可能にする。
【００５１】
これを考慮して、この記憶サービスパラダイムは、ローカルデータ記憶デバイスが今後、（１）同じホストコンピュータに存在する他のデータ記憶デバイスまたはリモートサーバコンピュータ上で実行されているアプリケーションとの対話を行うことができ、（２）その対話が、データ記憶デバイス自体によっても、ホストアプリケーションによっても、またはリモートサーバによっても開始可能となるように規定する。
【００５２】
本発明はさらに、前に説明したメモリデバイスを含む電子システムに関することができる。メモリデバイス（すなわち、メモリカード）は、様々な電子製品で使用されるデジタルデータを格納するために一般に使用されている。メモリデバイスは、格納されたデジタルデータを持ち運び可能なように電子システムからリムーバブルであることが多い。本発明によるメモリデバイスは、比較的小さな形態的要素を有することができ、カメラ、ハンドヘルドまたはノートブック形コンピュータ、ネットワークカード、ネットワークアプライアンス、セットトップボックス、ハンドヘルドまたはそのほかの小形メディア（例えば、オーディオプレーヤ／レコーダ（例えば、ＭＰ３デバイス））、および医療用モニタなど、データを取得する電子製品のデジタルデータを格納するために使用可能である。
【００５３】
以下、本発明の実施形態について、図１〜３１を参照しながら説明する。なお、当業者には当然のことながら、本発明はこうした限られた実施形態に収まらないため、こうした図面に関して本願明細書で与えられる詳細な説明は、単に説明を目的としたものである。なお、本発明は、マルチメディアカード（ＭＭＣ）およびセキュアデジタルカード（ＳＤ）などの不揮発性メモリを含むことができる、任意のタイプのローカルデータ記憶デバイスに使用可能であると考えられる。
【００５４】
図１は、本発明の実施形態に従ったマスタデバイス／スレイブシステム１００の象徴的表現を示す。例として、本願明細書に記載される特定の実施形態によれば、スレイブデバイスは、限定はされないが、前に説明したローカル記憶デバイスのいずれかなどのローカル記憶デバイスという形をとるとよく、マスタデバイスは、限定はされないが、前に説明したホストデバイスのいずれかなどのホストデバイスという形をとる。なお、マスタ／スレイブは、１つのデバイスまたはプロセスが１つ以上の他のデバイスに対して一方向の制御権を有する通信プロトコルのモデルである。従来のシステムでは、デバイス間またはプロセス間のマスタ／スレイブ関係が確立されると、制御の方向は常にマスタからスレイブである。一部のシステムでは、マスタは、適格な複数デバイスのグループから選ばれ、他のデバイスがスレイブの役割を果たす。したがって、マスタ／スレイブシステム１００（以下、簡単にシステム１００と呼ぶ）は、従来のマスタ／スレイブパラダイム１０６もあって互いに関係し合ったマスタデバイス１０２およびスレイブデバイス１０４を含む。なお、さらに、スレイブデバイス１０４は、マスタデバイス１０２によって提供されるインターフェイス以外には、マスタデバイス１０２の外部にあるいずれのデバイスに対しても、何らのインターフェイスも利用しない。
【００５５】
マスタデバイス１０２は、いくつかのマスタデバイスプロセス１０８を動作させることができる。マスタデバイスプロセスとは、マスタデバイスのためだけに実行されるプロセスのことである。そのようなマスタデバイスプロセスには、例えば、マスタデバイス１０２に実行可能な命令を提供するのに役立つフェッチ命令コマンドなど、任意の数およびタイプのプロセスが含まれ得る。マスタデバイスプロセス１０８は、マスタデバイスプロセス１１０、１１２および１１４を含むことができ、そのそれぞれが、処理ユニット１１６によって実行されるとよい。プロセス１１０、１１２または１１４のうちの任意のものが、スレイブデバイスサービス１１８からのサービスをリクエストすることができる。例えば、プロセス１１０は、マスタデバイスリクエスト１２０を生成することで、スレイブデバイスサービス１１８のサービスをリクエストすることができる。スレイブデバイスサービス１１８は、スレイブサービスレスポンス１２２を用いてマスタデバイスリクエスト１２０に応答するとよい。例えば、マスタデバイスリクエスト１２０は、ＲＥＡＤコマンドという形をとってもよく、リクエストされたスレイブサービスレスポンス１２２は、ＤＡＴＡという形をとってもよい。しかし、従来のマスタ／スレイブパラダイム１０６の範囲の中では、スレイブデバイス１０４はマスタデバイス１０２に、マスタデバイスプロセス１０８のほかのいかなるプロセスも実行するように指示できず、いかなる方法でも実行させることができない。言い換えれば、従来のマスタ／スレイブパラダイム１０６という状況の中では、マスタデバイス１０２のみが、マスタデバイスプロセス１０８のうちの少なくとも１つを実行できる。
【００５６】
しかし、本発明は、スレイブデバイス１０４が、リクエストされるプロセス１２４をスレイブデバイス１０４のために実行するようにプロセッサ１１６に指示できるようにすることで、従来のマスタ／スレイブパラダイム１０６を回避する。このようにして、リクエストされるプロセス１２４は、プロセッサ１１６によって実行可能であり、なおかつマスタデバイスプロセス１０８のいずれからも完全に独立して無関係とすることができる。スレイブデバイス１０４は、スレイブデバイスプロセス１２８とスレイブデバイス論理リクエスト１３０とを関連付けることができるスレイブデバイスエージェント１２６を含むとよい。マスタデバイス１０２は、プロセッサ１１６と通信し、さらにスレイブデバイス論理リクエスト１３０によってスレイブデバイス１０４と通信するマスタデバイスエージェント１３２を含むとよい。こうすることで、マスタデバイスエージェント１３２は、スレイブデバイス論理リクエスト１３０を使用して、リクエストされるスレイブデバイスプロセス１２４を実行するようにプロセッサ１１６に指示することができる。このようにして、スレイブデバイスによって生成された論理リクエストは、マスタデバイスによって開始されるいかなるプロセスとも無関係かつ独立した、マスタデバイス提供の物理的レスポンスに変換されることが可能である。
【００５７】
図２Ａは、本発明の実施形態に従ったコンピューティングシステム２００を示す。システム２００は、スレイブデバイス１０４を含むことができ、スレイブデバイス１０４は、ローカル記憶デバイス（ＬＳＤ）２０４という形をとることができる。ＬＳＤ２０４は、比較的小さな形態的要素を有するメモリカードなどのリムーバブルメモリデバイスという形をとることができ、カメラ、ハンドヘルドまたはノートブック形コンピュータ、ネットワークカード、ネットワークアプライアンス、セットトップボックス、ハンドヘルドまたはそのほかの小形オーディオプレーヤ／レコーダ（例えば、ＭＰ３デバイス）、および医療用モニタなど、電子製品のデジタルデータを格納するために使用可能である。メモリカードの例には、ＰＣカード（以前はＰＣＭＣＩＡデバイス）、フラッシュカード（例えば、コンパクトフラッシュタイプＩおよびＩＩ）、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ＡＴＡカード（例えば、コンパクトフラッシュカード）、メモリスティック、ＳｍａｒｔＭｅｄｉａ（登録商標）カードがある。さらに、ＬＳＤ２０４は、カリフォルニア州ミルピタスのサンディスク  コーポレイションによって製造されたＳＤ対応のｉＮＡＮＤ（登録商標）を組み込んだフラッシュドライブなどの非リムーバブルメモリデバイスという形をとることもできる。
【００５８】
ＬＳＤ２０４は、ホストデバイス（ＨＤ）２０２という形のマスタデバイス１０２とＨＤ／ＬＳＤインターフェイス２０６を経由して通信することができる。なお、ＨＤ／ＬＳＤ２０６は、ＨＤ２０２およびＬＳＤ２０４が機械的に接続することができる機械的エンティティ（ソケットまたは相互接続バスなど）として構成可能である。いくつかの実施形態では、ＨＤ／ＬＳＤ２０６は無線インターフェイスという形をとることができる。ＨＤ２０２がマスタデバイスであることから、ＨＤ２０２はプロセッサを含む。なお、明瞭にするために、ＨＤ２０２に含まれているプロセッサは、図に示されることも、この説明の中でさらに言及されることもないが、それでも想定上は存在しているものとする。ＬＳＤ２０４は、物理的に、ＨＤ２０２に排他的に接続可能であり、したがって、ＨＤ２０２による介入なしにコンピューティングシステム２００の外部の回路および／またはアプリケーションにアクセスすること、または他の形でそれと通信することはできない。典型的には、ＬＳＤ２０４は、ＨＤ２０２によって提供される当該インターフェイス以外には、ＨＤ２０２の外部のデバイスに対する何らのインターフェイスも利用しない。
【００５９】
ＨＤ２０２は、ＬＳＤドライバ２１０と通信しているホストデバイスファイルシステム（ＨＤＦＳ）２０８を含む。記載されている実施形態では、ＨＤＦＳ２０８は、ＬＳＤ管理コマンド２１２をＬＳＤドライバ２１０へ発行することができる。ＬＳＤドライバ２１０は、次に、ＬＳＤ管理コマンド２１２（適切にフォーマットされている）を、ＨＤ／ＬＳＤインターフェイス２０６を経由してＬＳＤ２０４に渡すことができる。例えば、ＬＳＤ管理コマンド２１２は、ＬＳＤ２０４が論理ブロックアドレス（ＬＢＡ）アーキテクチャを有するデータ記憶アレイを含むように設定されている場合、ブロックコマンドという形をとることができる。ＨＤ２０２は、（内部）ソフトウェアアプリケーション２１４も含むことができる。内部アプリケーションとは、ソフトウェアアプリケーション２１４が、ＨＤＦＳ２０８およびＬＳＤドライバ２１０を利用してＬＳＤ２０４と通信できるということである。そのようなソフトウェアアプリケーションは、ホストデバイスオペレーティングシステム（ＨＤＯＳ）２１６およびアプリケーション２１８を含むことができ、それぞれ、典型的に、ホストデバイスのメインメモリ（ハードディスクドライブ、すなわちＨＤＤならびにフラッシュメモリなどの不揮発性メモリという形をとることができる）に存在する。
【００６０】
記載されている実施形態では、ソフトウェアアプリケーション２１４は、ＨＤＦＳ２０８およびＬＳＤドライバ２１０を利用してＬＳＤ２０４と通信することができ、したがって、ＨＤＦＳ２０８に「認識」される。しかし、アプリケーション２１４とは対照的に、外部アプリケーション２２０（以下、ターゲットアプリケーションと呼ぶ）は、ターゲットアプリケーション２２０と、ＨＤＦＳ２０８およびＬＳＤドライバ２１０のいずれとの間にも何らの通信パスも利用せずにＬＳＤ２０４と通信することから、ＨＤＦＳ２０８に「認識」されない。記載される実施形態では、ターゲットアプリケーション２２０は、ローカルまたはリモートのいずれかで、任意数の位置およびデバイスに存在することができる。そのような位置およびデバイスには、例えば、ＨＤ２０２（ローカルアプリケーション２２０−１を有する）または外部デバイス２２２（ローカルアプリケーション２２０−２を有する）など、ＨＤ２０２およびＬＳＤ２０４の外部にあるがそれでもシステム２００内にある任意のデバイスが含まれると考えられる。記載される実施形態では、外部デバイス２２２は、インターフェイス２２３を経由してＨＤ２０２に結合された第２のＬＳＤ２２２という形をとることができる。さらに、当該位置およびデバイスは、ＨＤ２０２とネットワークリンク２２８を経由してネットワークインターフェイス２３０にて通信しているネットワーク２２６に含まれシステム２００の外部にあるデバイス２２４（リモートアプリケーション２２０−３を有する）も含むことができる。このようにして、ネットワークリンク２２８を使用するコマンドパスを、外部デバイス２２４とＨＤ２０２との間に確立可能であり、ここを情報２３２が通ることができる。
【００６１】
ＨＤ２０２は、ネットワークインターフェイス２３０を経由して、ネットワーク２２６と通信することができる。記載される実施形態では、ネットワークインターフェイス２３０は、ネットワークリンク２２８を経由した、ＨＤ２０２とネットワーク２２６との間の通信を促進する。例えば、ネットワーク２２６がＩＰ（インターネットプロトコル）プロトコルタイプのネットワークであれば、ネットワークインターフェイス２３０は、例えばアプリケーション２１８とネットワーク２２６に含まれる任意のネットワークデバイス（ＮＤ）２２４との間にＩＰプロトコルベースのネットワークリンク２２８（ＵＲＬなど）を確立することができる。なお、ネットワークインターフェイス２３０は、適切と判断される任意の場所に物理的に位置することができる。例えば、ネットワークインターフェイス２３０をＨＤ２０２に組み入れることが可能である。ただし、ネットワークインターフェイス２３０は、ＨＤ２０２（またはシステム２００）に含まれない任意の物理的位置に位置するが、それでもＨＤ２０２によってネットワーク２２６との適切なネットワークリンク２２８を確立するために利用することも可能である。したがって、ネットワークインターフェイス２３０は、ＨＤ２０２内に物理的に組み入れられるように、またはその極めて近くにあるように制限されるものではない。
【００６２】
マスタデバイスエージェント１３２は、マスタデバイスエージェント１３２に関して前述した機能に加えて、ＬＳＤ２０４により提供される記憶サービスと任意の利用可能な外部リソースとの間のブリッジ機能性を少なくとも提供するホストデバイスエージェント２３４という形をとることができる。記載される実施例では、ホストデバイスエージェント２３４は、適切な任意の手段（以下にさらに詳しく記載するポーリングまたは割り込みなど）によるＬＳＤ論理リクエストを特定するために使用可能である。さらに、ホストデバイスエージェント２３４は、ターゲットアプリケーションへの通信パス／ターゲットアプリケーションからの通信パスがホストデバイスエージェント２３４によって確立されてからは、このルーティングおよび／または保持を行うように設定可能である。さらに、ホストデバイスエージェント２３４は、任意のタイプのターゲットアプリケーションに役立つように、アプリケーション中立とすることができる。
【００６３】
ＬＳＤ２０４は、コントローラ２３６と、第１の記憶アレイ２４０および第２の記憶アレイ２４２を含む大容量記憶アレイ２３８とを含むことができる。なお、記憶アレイ２３８は、メモリセル（フラッシュメモリセルなど）のアレイから形成可能である。この特定の場合では、大容量記憶アレイ２３８をフラッシュメモリセルのアレイと仮定することができるが、本発明は任意の適切なタイプのメモリセルとともに使用可能であると考えられるため、本発明はフラッシュタイプのメモリセルのみに限定されない。コントローラ２３６は、第１の記憶アレイ２４０を、ホスト／ＬＳＤパラダイム１０６の範囲内で管理する（すなわち、ＨＤＦＳ２０８の命令通りに機能する）ことができるファイルマネージャ２４３を含む。特に有用な構成では、第１の記憶エリア２４０は、ＬＢＡベースの大容量記憶アレイとすることができる。こうすることで、第１の記憶アレイ２４０はレガシー設置基盤に対応する。したがって、第１の記憶エリア２４０に格納されるデータのブロックの位置は、論理ブロックアドレッシング（ＬＢＡ）を使用して指定することができ、各ブロックは、例えばそれぞれ５１２または１，０２４バイトのオーダとすることができる。こうすることで、第１の記憶エリア２４０は、任意の考えられるレガシー大容量記憶装置アーキテクチャと完全な下位互換性を持つことができ（すなわち、従来のホストとともに機能できる）、より詳しく言えばＬＢＡタイプのシステムと完全な下位互換性を持つことができる。特に、ＬＳＤ２０４（特に、第１の記憶エリア２４０）は、レガシーインターフェイス、バス、およびすべての関連したプロトコルを使用する標準のＬＢＡアーキテクチャのもとで動作することができ、レガシー製品の設置基盤との完全な互換性が提供される。
【００６４】
コントローラ２３６は、インターフェイス２４６を使用して、第１の記憶エリア２４０と第２の記憶領域２４２との間のブリッジ（後述する）として機能することができるＬＳＤエージェント２４４も含むことができる。ＬＳＤエージェント２４４は、内部ＬＳＤアプリケーション２５０が、外部デバイスおよび／またはターゲットアプリケーションと、標準プロトコル（インターネットプロトコル、すなわちＩＰなど）および任意の利用可能なネットワークリソースを使用しＬＳＤインターフェイス２５２を経由して通信するためのメカニズムとを提供するネットワークスタック／インターフェイス２４８も管理することができる。特に、ＬＳＤ２０４は、ホストデバイスエージェント２３４が、命令（メッセージフェッチなど）をＨＤ／ＬＳＤインターフェイス２０６のＬＢＡベースの実施例に適切な形で実行できるようにするために、任意のネットワーク通信（ＬＳＤ論理リクエスト１３０など）を標準フォーマット（物理バスベースのフォーマットなど）に変えることができる。このようにして、例えば、フェッチされた任意のメッセージを、ホストデバイスエージェント２３４とリモートアプリケーション２２０−３との間に作成されたネットワークリンク２２８（またはローカルアプリケーション２２０−１もしくは２２０−２とＬＳＤ２０４との間のローカル通信パス）上で無事に伝達可能である。この関連で、ネットワークスタック／インターフェイス２４８は、ＬＳＤエージェント２４４の一部と考えることが可能である。ＬＳＤエージェント２４４はさらに、認証およびセキュリティサービスをＬＳＤアプリケーション２５０に提供すること、ならびに到着する任意のサービスリクエストを管理することができる。
【００６５】
第１の記憶エリア２４０もしくは第２の記憶エリア２４２のいずれか（または両方）は、別々の内部領域に分割可能である。この分割された領域はそれぞれ、互いに、さらに／またはＬＳＤ２０４の外部にある回路および／もしくはソフトウェアアプリケーションと任意の適切な形で対話できるように作用することが可能である。そのような外部電気回路は、例えば、ＨＤ２０２（その中にホストファイルシステム２０８などのすべてのコンポーネントを含む）、ＬＳＤ２２２、またはＮＤ２２４などのネットワーク２２６に含まれるいくつかの外部デバイスのいずれかを含むことができる。
【００６６】
第２の記憶エリア２４２は、領域２５４を含むように分割可能である。記載される実施形態では、領域２５４は、ＨＤＦＳ２０８に「認識」されないように設定することが可能であり、したがって、隠された記憶エリア（ＣＳＡ）２５４として指定することができる。こうすることで、ＣＳＡ２５４のいかなるデータコンテンツまたはデータコンテンツに対する変更も、ＨＤＦＳ２０８による検出はできなくなる（それについて報告されない限り）。ただし、ＨＤＦＳ２０８は、前述した任意のデータコンテンツまたはデータコンテンツの変更について報告を受けることができる。例えば、以下にさらに詳しく記載するように、ＨＤＦＳ２０８と通信していない任意の回路またはソフトウェアアプリケーション（ＮＤ２２４に存在するリモートアプリケーション２２０−３、ＨＤ２０２内のローカルアプリケーション２２０−１、およびＬＳＤ２２２内のローカルアプリケーション２２０−２など）が、それ自体とＣＳＡ２５４との間にＨＤＦＳ２０８によって認識されることなく通信パス２５６を確立するように、ＨＤ２０２に指示することができる。反対に、ＬＳＤ２０４は、ＬＳＤ２０４と任意の指定のアプリケーション２２０との間に通信パス２５６を確立するように、ＨＤ２０２に指示することができる。なお、確立されると、情報（情報２３２、情報２５８、および情報２６０など）はＨＤ２０２によるそれ以上の介入なしで（データパケットルーティングなど、データの受け渡しに関係する任意の介入を除き）、かつＨＤＦＳ２０８に認識されずに渡されることが可能である。しかし、場合によっては、ＣＳＡ２５４が、そのような任意の変化についてＨＤＦＳ２０８に報告を提供することができる。
【００６７】
第１の記憶エリア２４０は、領域２６０を含むように分割可能である。記載される実施形態では、領域２６０は、ＨＤＦＳ２０８または通信がＨＤＦＳ２０８によって取り次がれる限りはそのほか任意の適切な外部回路にとって、完全にアクセス可能とすることができる（例えば、いくつかの実施形態において前に多少詳しく記載したＬＢＡベースのコマンドを使用して）。したがって、領域２６０は、ホストデバイスファイルシステム２０８がホスト記憶エリア（ＨＳＡ）２６０を管理するということを踏まえて、ＨＳＡ２６０と表すことができる。本発明の一態様では、ＣＳＡ２５４およびＨＳＡ２６０は、ＨＤＦＳ２０８から独立しているインターフェイス２４６を経由して互いに通信することができる。記載される実施形態では、インターフェイス２４６は、ＬＳＤエージェント２４４の一部として、第１の記憶エリア２４０と第２の記憶エリア２４２との橋渡しをすることができる。ＬＳＤエージェント２４４は、内部ファイル管理システム（例えば、ＬＳＤ  ＦＳ）を含むことができ、これは例えば、ＨＤＦＳ２０８によって管理されているファイルアロケーションテーブル（ＦＡＴ）を読み取ることができる。ＬＳＤエージェント２４４はさらに、ＣＳＡ２５４への書き込み、ＣＳＡ２５４からＨＳＡ２６０への書き込みを、例えばダミーコンテンツを有するプレースホルダファイルを使用して行うことができる。このように、ＣＳＡ２５４およびＨＳＡ２６０は、ＨＤＦＳ２０８には見えない通信パス２６２上で互いに通信することができる。場合によっては、ＣＳＡ２５４および／またはＨＳＡ２６０のすべて（または一部のみ）を、それぞれ保護されている部分２６４および２６６として指定可能である。保護されているとは、ＨＤＦＳ２０８が、許可されない限りはこうした保護されている領域にアクセスできないということである。そのような許可は、例えば許可サーバなど、コンピューティングシステム２００の外部にあるデバイスによって提供可能である。前述したように、ＬＳＤ２０４は、リクエストされたプロセス１２４をＬＳＤ２０４のために実行するように、ＨＤ２０２に指示することができる。なお、ホストコマンド（例えば、読み込み／書き込み）がＬＳＤ論理リクエスト１３０の生成をトリガする場合でも、ＬＳＤ論理リクエスト１３０が、ホストコマンドに役立つものであることはない。
【００６８】
このように、リクエストされたプロセス１２４は、ホストプロセス１０８のいずれとも完全に独立し、無関係とすることができる。特に、ＬＳＤ２０４は、例えば、ローカルアプリケーション２２０−１および／または２２０−２のいずれかに対するネットワークリンク２２８の確立および／または通信パス２５６の確立を、ＨＤ２０２に指示することができ、これはすべてＨＤＦＳ２０８に認識されない。なお、リクエストされたプロセス１２４が実行される（すなわち、例えば適切な通信パスが確立される）と、ＨＤ２０２によるそれ以上の介入は何ら必要ない（任意のルーティングまたはそのほかのハウスキーピング機能を除いて）。ＨＤ２０２は、ＬＳＤ論理リクエスト１３０の実行を、いくつかの方法でＬＳＤ２０４により指示することが可能である。
【００６９】
場合によっては、リクエストされたプロセスの実行をＨＤ２０２に間接的に指示することが、ＬＳＤ２０４にとって望ましいことがある。間接的とは、ＬＳＤ２０４が、リクエストされたプロセスを実行するように、ＨＤエージェント２３４とは別の異なる中間エージェントを使用して、ＨＤ２０２に指示するということである。リクエストされたプロセスの間接的な指示について、図２Ｂのコンピューティングシステム２７０を参照して説明することができる。図に示すように、ＬＳＤ２０４内のエージェント２４４は、エージェント２４４とターゲットアプリケーション２７４（起動アプリケーションとも呼ばれる）との間に通信パス２７２を確立するように、ＬＳＤ論理リクエスト１３０を使用してＨＤ２０２に指示することができる。なお、起動アプリケーション２７４は、ローカルまたはリモートに位置することができる。例えば、エージェント２４４がＬＳＤ２０４に存在し、起動アプリケーション２７４がＮＤ２２４に存在することができ、その場合、ＨＤ２０２は、ネットワークインターフェイス２３０を使用して、通信パス２７２（すなわち、ネットワークリンク２２８に類似する）を確立する。あるいは、起動エージェント２７４は外部デバイス２２２またはＨＤ２０２内に存在することができ、その場合、通信パス２７２はローカル通信パス２５６に類似することになる。
【００７０】
いずれの場合でも、通信パス２７２が確立されると、エージェント２４４は、通信パス２７２上で、ＨＤ２０２によるそれ以上の介入なしに（通信パス２７２の保持を除いて）起動アプリケーション２７４と論理的に対話できる。この論理的対話の一部として、エージェント２４４は、トリガコマンド２７６を起動アプリケーション２７４に渡すことができる。起動アプリケーション２７４は、コマンド２８０を送ることで、リクエストされたプロセス２７８を実行するようにＨＤ２０２に指示することによって、トリガコマンド２７６に応答することができる。その結果、ＨＤ２０２は、リクエストされたプロセス２７８を実行することができる。リクエストされたプロセス２７８は、もとのエージェント２４４をポイントすることができる。このように、エージェント２４４と、リクエストされたプロセス２７８とは、論理的に対話することができる。
【００７１】
本発明のこの態様の特に有用な実施形態は、ユーザと論理的に対話することがＬＳＤ２０４にとって望ましいと考えられる状況で実現される。この実施形態の特定の実施例が図２Ｃに示され、起動アプリケーション２７４は、外部デバイス２２２に存在することができる（ただし、前述したように、起動アプリケーション２７４は、リモートまたはローカルに存在することができることに留意するべきである）。この例では、外部デバイス２２２は、加入者識別モジュール（ＳＩＭ）カード２２２という形をとることができる。当該技術分野では周知のように、ＳＩＭカード２２２は、モバイルコンピュータおよびモバイル電話などのモバイルセルラー電話デバイスに使用することができる。ＳＩＭカードは、加入者を識別するために使用されるサービス加入者キー（ＩＭＳＩ）をセキュアに格納することができる。さらに、ＳＩＭカードは、ユーザが、単にＳＩＭカードを１つのモバイル電話から取り外してそれを別のモバイル電話または広帯域電話デバイスに挿入することで、その加入を保ちながら電話（またはそのほかの広帯域通信デバイス）を変更できるようにする。この例では、ＳＩＭカード２２２は、ＳＩＭカード２２２がＨＤ２０２（例えば、携帯電話という形をとることができる）上のプロセスを主体的に起動できるようにするＳＩＭアプリケーションツールキット（ＳＴＫ）コマンドセットに準拠している。ＳＴＫコマンドセットは、ＳＩＭカードがどのようにして外界と直接対話すべきかを定義するＳＩＭカードにプログラムされた命令を含み、ハンドセットおよびネットワークから独立してコマンドを開始する。これによって、ＳＩＭカードは、ネットワークアプリケーションとエンドユーザとの間のインタラクティブなやり取りを確立し、ネットワークにアクセスすることまたはネットワークへのアクセスを制御することができる。ＳＩＭカードは、ハンドセットにも、メニューを表示してユーザ入力を求めるなどのコマンドを与える。
【００７２】
したがって、直接の通信パスを確立し、その結果エンドユーザと対話するためにＬＳＤ１０２が使用できる１つの手法は、次のように実装することができる。リクエストされたプロセスのＨＤ２０２上での実行を、起動アプリケーション２７４を使用してＨＤ２０２に主体的に指示するように構成されたＳＩＭカード２２２への通信パス２７２を確立するように、エージェント２４４がＨＤ２０２に指示することができる。なお、ＩＳＯインターフェイスベースのＳＩＭカードでは、通信パス２７２は、ＳＩＭ側でＢＩＰ（ベアラ独立プロトコル）を使用して確立可能である。一方、ＵＳＢインターフェイスベースのＳＩＭカードでは、通信パス２７２は、ＳＩＭ側でイーサネットエミュレーション（ＥＥＭ）クラスを使用して確立可能である。
【００７３】
この場合、ＳＩＭカード２２２は、ＳＴＫ準拠のＳＩＭカード２２２とすることができる。しかし、以下のように、本発明は特定の通信テクノロジーにもネットワークタイプにも限定されない。いずれの場合でも、エージェント２４４は、例えばブラウザアプリケーション２７８という形をとることができるリクエストされたプロセス２７８を実行するようにＨＤ２０２に指示するべく、ＳＴＫ準拠のＳＩＭカード２２２（起動アプリケーション２７４を使用する）をトリガすることができる。記載される実施形態では、ブラウザアプリケーション２７８はエージェント２４４（およびＬＳＤ２０４）をポイントする。ブラウザアプリケーション２７８は、ユーザインターフェイス（ＵＩ）２８０を、例えばディスプレイユニット２８２上に表示させることができる。ＵＩ２８０は、ユーザ入力２８４をアイコン２８６にて受け取ることができる。このように、ＵＩ２８０およびエージェント２４４は論理的に対話することができ、その結果、ＬＳＤ２０４に、ＵＩ２８０およびユーザ入力２８４を提供するユーザに対する直接アクセスを提供する。場合によっては、ＳＩＭ２２２が、ブラウザ２７８とＬＳＤ２０４との間の中間段階として機能する必要があることもある。いずれの場合でも、ＬＳＤ２０４およびＵＩ２８０は、ＨＤ２０２の介入なしに論理的に対話することができる（ＨＤ２０２がブラウザ２７８を実行して、様々な通信パスの保持に関して適切なハウスキーピング任務を提供するということを除いて）。
【００７４】
例えば、ＵＩ２８０は、ユーザ入力２８４を受け取ることができる。ユーザ入力２８４を、例えばユーザ選択イベント２８８として、ブラウザアプリケーション２７８により処理することが可能である。ブラウザアプリケーション２７８は、エージェント２４４をポイントすることができることから、エージェント２４４は、ブラウザアプリケーション２７８とエージェント２４４との間の論理的対話の一部として、ユーザ選択イベント２８８をＨＤ２０２による介入なしに（ＨＤ２０２が、様々な通信パスを保持し、ブラウザアプリケーション２７８を実行するということを除いて）受け取ることができる。ほぼ同じように、エージェント２４４は、論理的対話によって、ＵＩ２８０またはディスプレイユニット２８２を使用して情報をユーザに渡すことができる。そのような情報には、例えば、ＬＳＤ２０４の現在の状態、選択された格納されているコンテンツのリストなどが含まれ得る。
【００７５】
なお、ネットワークおよび対応するテクノロジーに応じて、ＳＩＭカードには様々な呼び方がある。例えば、３Ｇタイプのネットワークでは、ＳＩＭカードはＵＳＩＭカードと呼ばれる。したがって、ＵＳＩＭアプリケーションツールキット、すなわちＵＳＡＴを参照することになる。いずれの場合でも、本発明は、任意のネットワークおよび対応するテクノロジー（ＳＴＫ、ＵＳＡＴなど）で使用可能である。
【００７６】
図３Ａは、本発明の実施形態に従ったポーリング方式３００を示す。ＨＤ２０２は、ポーリング信号（ＰＳ）３０２をＬＳＤ２０４へ送ることによって、ＬＳＤ２０４にポーリングを行うことができる。ＰＳ３０２は、ＬＳＤエージェント２４４によって傍受される。記載される実施形態では、ＬＳＤエージェント２４４は、ＬＳＤ論理リクエスト１３０を生成することによってＰＳ３０２に応答する論理リクエストジェネレータ３０４を含むことができる。論理リクエストジェネレータ３０４は、その後、ＬＳＤ論理リクエストをホストデバイスエージェント２３４に送り返す。なお、記載されるポーリングプロセスは、ＨＤ２０２が、ＬＳＤ２０４から特定の応答があることを要求または期待していることを条件としたものではない。このように、ＬＳＤ２０４は、単にポーリング信号３０２にＬＳＤ論理リクエスト１３０を用いて応答することによって、ＨＤ２０４に、リクエストされたプロセス１２４を実行するようにいつでも指示することができる。記載される実施形態では、ＬＳＤ論理リクエスト１３０は、ＬＳＤによりリクエストされたプロセス１２４を実行するようにＨＤ２０２に指示することができるコマンド情報を含む。なお、コマンド情報は、ＨＤ２０２によって完了されるべき特定の動作（コマンドパス２５６の設定など）を示すコマンドコードなどのデータを含むことができる。
【００７７】
コマンド情報は、例えばターゲットデバイス識別（ＩＤ）、ターゲットデバイス位置（例えば、ＩＰアドレス）などのデバイス情報も含むことができる。しかし、場合によっては、ＬＳＤ２０４もＨＤ２０２も、要求されるタスクを完了するための十分な情報を保有していない。例えば、ＬＳＤ２０４は、特定の動作を示すコマンド情報を提供することができるが、特定のターゲットデバイスＩＤまたはターゲットデバイス位置を欠くこともある。こうした状況では、例えば、欠けているが必要な情報を獲得するために、ＬＳＤ２０４がネットワークリンク２２８を経由してクエリを行うことができる発見サーバコンピュータを利用することができることもある。例えば、ＬＳＤ２０４は、いつでも単にＬＳＤ論理リクエスト１３０を用いてＰＳ３０２に応答することによって、ターゲット記憶デバイス上での記憶動作を開始することができる。ＬＳＤ論理リクエスト１３０は、ＬＳＤ２０４とターゲット記憶デバイスとの間のコマンドパスを確立するための、ＨＤ２０２に対する命令を備えたコマンドを含むことができる。なお、ターゲット記憶デバイスは、ＨＤ２０２が適切なコマンドパスを確立できる限り、任意の位置にあってよい。例えば、ターゲット記憶デバイスがネットワーク２２６内のＮＤ２２４であれば、ＨＤ２０２は、ネットワークインターフェイス２３０とＮＤ２２４との間にネットワークリンク２２８を確立することによって、ＬＳＤ論理リクエスト１３０に応答することができる。
【００７８】
リクエストされたプロセス１２４を実行するようにＬＳＤ２０４がＨＤ２０２に指示することができるもう１つのメカニズムについて、図３Ｂに示されているＬＳＤによって生成される割り込みの観点から記載する。ＬＳＤ論理リクエストジェネレータ３０４から受け取られたＬＳＤ論理リクエスト１３０と、ＬＳＤが生成した割り込み４０４とを関連付けるＬＳＤ割り込みアソシエータ４０２とを使用して、ＬＳＤ２０４は、リクエストされたプロセス１２４を実行するようにＨＤ２０２に指示することができる。ＬＳＤ論理リクエスト１３０がＬＳＤ割り込み４０４と関連付けられると、ＬＳＤ２０４は、ＨＤ２０２宛てに割り込み４０４を発生させる。ＨＤ２０２は、リクエストされたプロセス１２４を実行することによって、ＬＳＤ割り込み４０４に関連付けられた論理リクエスト１３０に応答する。
【００７９】
ＬＳＤ２０４は、第２のＬＳＤ２２２などの他のローカル記憶デバイス（単数または複数）との通信を確立するようにＨＤ２０２に命じることもできる。例えば、コンピューティングシステム２００を、例えば第２のＬＳＤ２２２とＬＳＤ２０４との間でメディアファイルを同期するためにパーソナルコンピュータに結合可能な携帯メディアプレーヤとすることができる（この場合、ＬＳＤ２０４は、ＭＰ３形式のオーディオファイルなど、様々なデジタルメディアファイルを格納する）。この例では、ＬＳＤ２０４は、適切な同期化動作を開始することができ、それによって、ＨＤＦＳ２０８には認識されずに、ＬＳＤ２２２およびＬＳＤ２０４の両方の間でデータコンテンツを比較しかつ更新する。
【００８０】
別の例では、ＬＳＤ２０４は、任意の数の動作を実行して結果を生成し、その結果に基づいて関連した論理リクエストを生成することができる。次に、この論理リクエストを、適切なＬＳＤプロセスを実行するようにＨＤ２０４に指示するためにＬＳＤ２０４によって使用することが可能である。例えば、ＬＳＤ２０４は、ＬＳＤパラメータのセットの検出動作を実行することができる。記載される実施形態では、検出されるＬＳＤパラメータのセットには、データコンテンツバックアップパラメータ、データコンテンツパラメータ（ファイルサイズ、ファイルタイプ、ファイル名、およびファイルキーワードなど）、論理記憶パラメータ（残りの容量、および適切な場合はＬＳＤ  ＩＰアドレスなど）、物理記憶パラメータ（摩耗度、不良ブロック数、ビット反転数など）、規則違反パラメータ、およびホストデバイスＩＰアドレスなどのパラメータが含まれ得る。ＬＳＤ２０４が検出動作を完了すると、検出動作の結果が生成される。なお、場合によっては、生成される結果は、検出されたパラメータがＬＳＤの動作を統制する規則のセットの範囲に入るということでＮＵＬＬ結果となる。一方、他の場合には、生成される結果を、ターゲットアプリケーションへの通信パスを確立するようにＨＤ２０２に指示することができる検出論理リクエスト１３０として、ＬＳＤ論理リクエスト１３０と関連付けることが可能である。前述したターゲットアプリケーションには、ローカルアプリケーション２２０−１、２２０−２、またはリモートアプリケーション２２０−３が含まれ得る。なお、ローカルアプリケーション２２０−１および２２０−２の場合には、通信パスはローカル通信パスと呼ばれる。前述した通信パスが確立されると、ＬＳＤ２０４およびターゲットアプリケーション２２０は、リクエストされた検出プロセスを実行するために論理的に対話することができる。なお、通信パスが確立されると、通信パスの保持およびそのほか任意のハウスキーピング任務を除いて、ＨＤ２０２によるそれ以上の介入は必要ない。リクエストされる検出プロセスには、コンテンツバックアッププロセス、コンテンツ共有プロセス、イベント報告プロセス、リモート命令のリクエストプロセス、使用／アクセス権のリクエストプロセス、リモートサーバへのレジストレーションプロセスが含まれ得る。
【００８１】
一実施形態では、ＬＳＤ２０４は、検出論理リクエストと、ホストデバイスによるポーリングとを関連付ける。一方、他の実施形態では、ＬＳＤ２０４は、検出論理リクエストと、ＬＳＤ割り込みとを関連付け、ＨＤ２０２宛てにＬＳＤ割り込みを発生させる。いずれの場合も、ＨＤ２０２は、リクエストされた適切な検出プロセスを実行するように指示を受けることができる。
【００８２】
なお、ＬＳＤ２０４および／またはシステム２００の外部にある任意の回路またはソフトウェアアプリケーションが、リクエスト元デバイスとターゲットデバイスＬＳＤ２０４との間に通信パスを確立するためのメカニズムとしてＨＤ２０４を使用して、ＬＳＤ２０４をターゲットとすることができることから、本発明は、本質的に対称的である。このように、ＬＳＤ２０４は、外部回路または外部ソフトウェアアプリケーションから生じるリクエストに応答することができる（例えば、現在のステータス情報、現在の容量の提供など）。例えば、図４は、リモートアプリケーション２２０−３が、ＨＤＦＳ２０８から独立して、第１の記憶エリア２４０にいくつかの記憶動作のうちのいずれかを強制的に実行させる状況を示している。例えば、ホストデバイスファイルシステム（ＨＤＦＳ）２０８に認識され、したがって管理可能である事前確立されているプロキシファイル４５０（プレースホルダファイルとも呼ばれる）にデータを書き込むことによって、外部アプリケーション２２０−３は記憶エリア２４０にデータを書き込むことができる。しかし、プレースホルダファイル４５０は、リモートアプリケーション２２０−３が、ＨＤＦＳ２０８に「目撃される」ことなく（報告されない限り）プロキシファイル内のデータに対するアクセス／変更を行うことができるメカニズムの一部にすぎないということから、プレースホルダファイル４５０に含まれるあらゆるデータは、「ダミー」データと見なすことができる。
【００８３】
例えば、外部アプリケーション２２０−３は、プレースホルダファイル４５０に書き込まれるべきデータ４５４を送信することによって、ＨＤＦＳ２０８の介入なしに、プレースホルダファイル４５０にデータ４５４を書き込むことができる。一実施例では、データ４５４は、プレースホルダファイル４５０へ直接送られるか、またはデータ４５４の選択された部分をバッファに入れるためにＣＳＡ２５４をキャッシュとして使用することができる。ＣＳＡ２５４が、データ４５４をキャッシュするために使用される場合、データ４５４は、通信パス２５６を経由して、ＨＤ２０２による介入なしに（通信パス２５６の確立を除いて）プレースホルダファイル４５０に渡される。このように、リモートアプリケーション２２０−３（またはさらに言えば任意の外部アプリケーション２２０）は、ＨＤＦＳ２０８の介入なしに、プレースホルダファイル４５０にデータを書き込むか、またはデータ４５４をプレースホルダファイル４５０からストリーミングすることができる。
【００８４】
例えば、ＬＳＤ２０４は、第１の記憶アレイ２４０の利用可能な記憶容量が所定量に満たないと判断する検出動作を実行することができる。その結果に基づいて、ＬＳＤ論理リクエストジェネレータ３０４は、ＬＳＤ２０４とリモートアプリケーション２２０−３との間に通信パス２２８を確立するようにＨＤ２０２に指示するＬＳＤ検出論理リクエスト１３０を生成することができる。通信パス２２８が確立されてからは、ＨＤ２０２は例えばモデム、ルータ、またはそのほかデータパケットのルーティングに使用される同様のデバイスに等しい役割を担うことから、ＨＤ２０２は介入できない。リモートアプリケーション２２０−３およびＬＳＤ２０４が通信パス２２８を経由して結合されると、ＬＳＤ２０４およびリモートアプリケーション２２０−３は通信パス２２８上で論理的に対話することができる。例えば、ＬＳＤ２０４は、検出動作の結果をリモートアプリケーション２２０−３に送信する。リモートアプリケーション２２０−３は、データ４５４（ユーザ通知、宣伝などの形）をプレースホルダファイル４５０にプッシュする（書き込む）ことによって応答することができる。データ４５４がプレースホルダファイル４５０に格納されると、それからデータ４５４は、ＨＤＦＳ２０８により認識され、様々な方法でＨＤ２０２による処理を行うことが可能である。例えば、データ４５４は、追加の記憶容量が必要であるという報告を表示するために、さらには購入製品、購入場所および購入価格を提案するために、ＨＤ２０４によって使用可能である。
【００８５】
図５Ａは、本発明の実施形態に従ったネットワーク５００のさらに詳細な図を示す。具体的には、ネットワーク５００は、図３に示されているネットワーク２２６の一実施形態である。具体的には、ネットワーク５００は、分散したコマンドパスを経由してコンピューティングシステム２００に結合されたサーバコンピュータ５０２を含むように示されている。このような分散したコマンドパスは、無線通信（ＷｉＦｉ、ブルートゥースなど）ならびに有線通信などを含むことができる。記載されている実施形態では、サーバコンピュータ５０２は、例えば、ＨＴＴＰ／ＳＯＡＰベースのウェブサービスなど、標準のウェブテクノロジーなどを使用した何らかの明瞭かつ明確なインターフェイスを、デベロッパおよびそのほかのユーザに提供することも行うサーバコンポーネント５０４を含む。記載される実施形態では、例えばリモートアプリケーションとＬＳＤ２０４との間のセキュアなチャネルが必要なときはいつでも、サーバコンポーネント５０４が少なくとも許可および認証サービスを提供できる。こうすることで、ネットワークからもたらされる攻撃、スパイウェア、マルウェアなどの可能性に対する効率的な防御を提供することができる。さらに、許可されていない第三者によってエンドユーザコンテンツ使用が追跡されないことを保証するためのプライバシー保護、場合によっては何らかの圧縮テクニックを使用する記憶デバイスを用いた最適化された通信プロトコルが提供され、さらに、サーバコンピュータはブロードキャストおよび／またはマルチキャスト機能も含むことができる。デバイスレジストレーションモジュール５０６および／または発見サービスモジュール５０８を、サーバコンピュータ５０２に含むか、または結合することが可能である。
【００８６】
デバイスレジストレーションモジュール５０６および発見サービスモジュール５０８は、それぞれレジストレーションサービスおよび発見サービスを提供する。レジストレーションサービスとは、ネットワーク２２６に含まれるか、追加されるか、またはそこから削除されるデバイスレジストレーションモジュール５０６に登録された任意のデバイスが関連したレジストレーションデータを有するということであり、このデータは、対応するデバイスの現在のステータスと一致するように更新される。このようなレジストレーションデータは、デバイスタイプ、デバイス位置（ネットワークＩＰプロトコルベースのネットワークであればＩＰアドレス）などを含むことができる。
【００８７】
一実施形態では、デバイス（またはソフトウェアアプリケーション）に関連したレジストレーションデータは、いくつかの異なる方法でレジストレーションモジュール５０６によって更新することができる。１つの手法は、レジストレーションモジュール５０６がデバイスステータスの変化（すなわち、デバイスが追加された、削除された、またはネットワーク２２６内で位置が移動したなど）の報告を受けることに依存する。本発明の一部の態様では、処理リソースならびにネットワーク帯域幅を保つために、すべての変化がレジストレーションモジュール５０６に報告するほど重要と見なされるとは限らない。しかし、デバイスステータスの変化が生じ、報告が保証されている状況では、レジストレーションモジュール５０６がネットワーク２２６に含まれているすべてのデバイスに継続的にｐｉｎｇを実行して各デバイスに現在のステータス情報を返すようにリクエストすることによって、レジストレーションモジュール５０６はステータスの変化について報告を受けることができる。前のデバイスステータスに関して変化し、報告すべきステータスを表すと判断された任意のステータス情報が、デバイスレジストレーションモジュール５０６での報告イベントを呼び出すことになる。
【００８８】
この報告イベントに応答して、レジストレーションモジュール５０６は、変化したステータスを有するデバイスが現在のデバイスステータス情報をレジストレーションモジュール５０６に送信するようにリクエストすることができる。そのデバイスに関連するステータス情報は、レジストレーションモジュール５０６により受け取られると、レジストレーションモジュール５０６において更新され、発見サーバ５０８に送信されることが可能である。別の手法は、各デバイスが、ステータスに変化が生じるたびに、その現在の詳しいステータスをデバイスレジストレーションモジュール５０６に送ることができるということから、デバイスレジストレーションモジュール５０６により受動的な手法をとらせることができる。この場合もやはり、コンピューティングリソースおよびネットワーク帯域幅を保つために、本発明の一部の態様は、すべてのステータス変化ではなく特定のステータス変化のみのレポートだけを提供する。
【００８９】
いずれの場合でも、現在のステータス情報が受け取られて適切に処理されると、レジストレーションモジュール５０６は、現在のステータス情報を発見サービスモジュール５０８に送信することができ、発見サービスモジュール５０８では、リクエスト元デバイスまたはソフトウェアアプリケーションに後から発見サービスを提供するためにそのステータス情報が格納される。そのような情報は、例えば、リクエスト元デバイス（ソフトウェアアプリケーションがあればそれを含む）と、ターゲットデバイスまたはターゲットアプリケーションとの間のコマンドパスの確立を促進するために、ネットワーク３２４に含まれている任意のデバイスに関係する任意の情報を含むことができる。
【００９０】
さらに図５Ａを参照すると、ＬＳＤ２２２が以前にＨＤ２０４と結合されたことがなくても、ＬＳＤ２０４をインターフェイス２２３に挿入することによってある時点でＬＳＤ２２２がＨＤ２０４に結合される（例えば、セキュアデジタル（ＳＤ）カードを、ネットワークと通信している携帯用コンピュータ、デジタルカメラなどに挿入するなど）と、その結果ＬＳＤ２２２は、本発明の一態様において、それがネットワーク２２６に参加したことをデバイスレジストレーションモジュール５０６に報告することができる。しかし、本発明のさらに別の態様では、デバイスレジストレーションサービス５０６は、例えばコンピューティングシステム２００にｐｉｎｇを実行して、報告すべき変化が生じたと判断することによって、ネットワーク２２６にＬＳＤ２２２が入ったことを能動的に判断することができる。
【００９１】
ＬＳＤ２２２が、ステータスの変化（この場合はネットワーク２２６にＬＳＤ２２２が追加されたこと）をデバイスレジストレーションサービス５０６に能動的に報告する場合、ＬＳＤ２２２は、ＨＤ２０２からネットワーク２２６へのネットワークリンク２２８およびネットワーク２２６からレジストレーションサービス５０６へのコマンドパスを含むコマンドパスを、ＬＳＤ２２２とデバイスレジストレーションサービス５０６との間に確立するように、前述したメカニズムのうちの少なくとも１つを使用してＨＤ２０２にリクエストすることができる。なお、ＬＳＤ２０４が、デバイスレジストレーションサービス５０６の位置を知らなければ、ＨＤ２０２がその位置をデフォルト位置として提供するか、またはネットワークサービスがステータス変化を所定の位置へ自動的にダイレクトする。
【００９２】
ＬＳＤ２０４とレジストレーションサービスとの間の通信が確立すると、続いてデバイスレジストレーションサービス５０６は、ＬＳＤ２２２の現在のステータスを更新（受動的または能動的に）することができる（ＬＳＤ２２２の現在のステータスは、ＬＳＤ２２２によってプッシュされるか、またはレジストレーションサーバ５０６によってプルされる）。更新されると、次にデバイスレジストレーションサービス５０６は、ＬＳＤ２２２の現在のステータスを発見サービスモジュール５０８へ送信することができ、そこで、このステータスは、リモートデバイスがＬＳＤ２２２をターゲットとするときに後からいつでも読み出しできるように格納される。なお、レジストレーション情報は、デバイスに関係する任意の関連情報を含むことができる。そのような関連情報（データ記憶デバイスの場合）は、デバイスの、どちらかというと不変の特徴である、論理記憶デバイスパラメータ（残っている利用可能な記憶容量、デバイスのＩＰアドレス、デバイス上の利用可能な記憶アプリケーション、ファームウェアバージョンおよび特徴など）を含むことができる。さらに、前述した情報は、例えば現在利用可能なデータ記憶容量、格納されているデータの質、デバイスの位置など、ならびにファイルサイズ、ファイルタイプ、ファイル名、およびファイルキーワードを含むことができるデータコンテンツパラメータなど、より一時的な情報を含むことができる。
【００９３】
発見サービス５０８が更新されると、発見サービス５０８は、そこにデータが格納されている任意のターゲットデバイス（またはターゲットソフトウェアアプリケーション）について、リクエストされた発見情報を、任意のリクエスト元デバイス（またはソフトウェアアプリケーション）に提供することができる。例えば、リモート記憶デバイス５１４に加えてリモートホストデバイス５１２を有するリモートコンピューティングデバイス５１０は、まずリモートコンピューティングデバイス５１０とＬＳＤ２０４との間にコマンドパスを確立することによって、発見サービス５０８を使用してＬＳＤ２０４などのターゲットデバイス上での記憶動作をリモート呼び出しすることができる。コマンドパスは、リモートコンピューティングデバイス５１０が、発見リクエスト５１６を発見サービス５０８に送ってターゲットデバイスＬＳＤ２０４の発見情報をリクエストすることによって確立することができる。そのような発見情報には、ターゲットデバイス位置情報、ターゲットデバイスの現在の動作ステータス情報、ターゲットデバイスの現在のパラメータ情報などが含まれ得る。発見リクエストに応答して、発見サービス５０８は、適切なターゲットデバイス発見情報を含む発見サーバレスポンス５１８を、リクエスト元デバイス（すなわち、リモートコンピューティングデバイス５１０）に送り返すことができる。
【００９４】
リモートコンピューティングデバイス５１０が、ターゲットデバイスＬＳＤ２０４に関する適切なターゲット発見情報を受け取ると、続いて図５Ｂに示されているように、リモートコンピューティングデバイス５１０は、ターゲットデバイスＬＳＤ２０４との間に（ＨＤ１０４を中継点として使用して）、少なくともネットワークリンク２２８を含むコマンドパスを確立することができる。コマンドパスがターゲットデバイスＬＳＤ２０４とリモートコンピューティングデバイス５１０との間に確立されると、次に、リモートコンピューティングデバイス５１０は、ターゲットデバイスＬＳＤ２０４上での任意の数およびタイプの記憶動作をリモート呼び出しすることができる。そのような動作には、例えば、データの読み込み、書き込みおよび／または消去が含まれ得る。
【００９５】
図６は、本発明の実施形態に従ったプロセス６００を詳述するフローチャートを示す。プロセス６００は、６０２にて、ホストデバイスがローカル記憶デバイスと通信しているかどうかを判断することで開始する。通信とは、ホストデバイスおよびローカル記憶デバイスの間に有効なコマンドパスが確立されているということである。有効な通信とは、ホストデバイスと、ローカル記憶デバイスとの間に、情報を渡すことができる物理接続が確立されているか、無線接続が確立されているか、または論理接続が確立されているかということである。ホストデバイスとローカル記憶デバイスとの間に有効な通信パスが存在すると判断されると、次に６０４にて、ローカル記憶デバイスに、ＬＳＤにより開始された保留中イベントがあるかどうかが判断される。ＬＳＤにより開始されたイベントとは、いかなるホストデバイスまたはホストデバイスファイルシステムのプロセスとも無関係であり、それらと独立しているイベントのことである。６０４にて、ＬＳＤにより開始された保留中イベントがないと判断されると、その結果プロセス６００は終了する。そうでなければ、６０６にて、ホストデバイスがローカル記憶デバイスに継続してポーリングを行っているか否かが判断される。ホストデバイスがローカル記憶デバイスにポーリングを行っていなければ、その結果、ローカル記憶デバイスが６０８にて、ＬＳＤにより開始された保留中イベントに関係する情報を含むＬＳＤ論理リクエストを生成し、６１２にて、ローカル記憶デバイスがＬＳＤ論理リクエストに関連した割り込みフラグを立てる。６１２にて、ホストデバイスが割り込みフラグに応答する。
６０６に戻ると、ホストデバイスが継続してローカル記憶デバイスにポーリングを行っていれば、６１４にて、ローカル記憶デバイスは、ＬＳＤにより開始された保留中イベントに関係する情報を含むＬＳＤポーリングレスポンスを用いて、ホストデバイスのポーリングに応答する。６１８にて、ホストデバイスがＬＳＤポーリングレスポンスに応答する。
【００９６】
図７は、本発明の実施形態に従ったプロセス７００を示す。プロセス７００は、７０２にて、リモートデバイスがローカルターゲットデバイス上の動作を呼び出したいかどうかを判断することで開始する。肯定であれば、次に７０４にて、ターゲットデバイス情報を獲得するためにリモートデバイスが発見サーバへクエリを送るかどうかが判断される。リモートデバイスが、発見サーバにクエリを行う必要がないと判断すれば、次に７０６にてリモートデバイスは、ローカルデバイスとコンタクトを取る。一方、リモートデバイスが、ターゲットデバイスの発見情報が必要であると判断すれば、次に７０８にて、発見サーバがターゲットデバイス発見情報を有するか否かが判断される。発見サーバがリクエストされたターゲットデバイス発見情報を有しないと判断されると、次に７１０にて、リクエストされたターゲットデバイス情報をレジストレーションサーバが有するか否かが判断される。レジストレーションサーバがリクエストされたターゲットデバイス情報を有しないと判断されると、その結果プロセス７００は終了する。そうでなければ、レジストレーションサーバは、７１２にて、リクエストされたターゲットデバイス発見情報を発見サーバへ送信する。７０８に戻ると、発見サーバが、リクエストされたターゲットデバイス発見情報を有すると判断した場合、次に７１４にて、リモートデバイスが、発見情報リクエストを発見サーバへ送り、７１６にて、リクエストされたターゲットデバイス発見情報を発見サーバが提供する。７０６にて、リモートデバイスは、ターゲットデバイスとコンタクトを取り、いずれの場合でも７１８にて、ターゲットデバイスがリモートデバイスに応答する。
【００９７】
図８は、本発明の背景を提供するものである。ネットワーク２２６の特定の構成としてのメディアネットワーク８００は、メディアプレーヤなどのメディアデバイスをいくつか含む。この例では、コンピューティングシステム２００は、いくつかのデジタルメディア項目（例えば、ビデオ、ＭＰ３ファイルとしてのこともあるオーディオなど）を格納するように構成されたメディアプレーヤ１００とすることができる。ネットワーク８００は、有線ネットワーク８０２および無線ネットワーク８０４のいずれかまたは両方として構成された分散通信を含むことができる。記載される実施形態では、有線データネットワーク８０２はワールドワイドウェブのある一部に関連する。パーソナルコンピュータ８０６は、有線ネットワーク８０２に結合できる（この場合、第２のインターフェイスにてＵＳＢケーブルを経由してコンピューティングシステム１００に接続されている）。無線データネットワーク８０４も、有線データネットワーク８０２に結合可能である。無線データネットワーク８０４は、例えばセルラーネットワーク、ＷｉＦｉネットワーク、ＷｉＭＡＸネットワークなどの１つ以上の無線データネットワークを含むことができる。
【００９８】
メディアネットワーク８００は、多数のメディア項目を格納するか、または多数のメディア項目にアクセスできる中央メディアサーバ８０８を含む。さらに、ネットワーク８００は、携帯メディアプレーヤ２００、８１０、８１２および８１４などの携帯メディアデバイスという形をとることができるネットワークデバイスとして構成された１つ以上の追加のコンピューティングシステム８１０をサポートし、この携帯メディアプレーヤの一部は、レガシー大容量記憶装置のみを有するものとして構成可能であり、他のものは、図２に示されているコンピューティングシステム２００として構成可能である。携帯メディアデバイス２００、８１０、８１２および８１４の任意のものが、有線リンク８１６または無線リンク８１８上でパーソナルコンピュータ８０６と通信することができる。例として、有線リンク８１６は、可能な場合には携帯メディアデバイス８１０をパーソナルコンピュータ８０６に相互接続することができるケーブル（例えば、ＵＳＢケーブル）に相当するものとすることができる。無線リンク８１８は、例えばブルートゥース、赤外線などの無線機能によって提供可能である。典型的には、携帯メディアデバイス８１０は、有線リンク８１６、無線リンク８１８のいずれかまたは両方を使用して、パーソナルコンピュータ８０６と通信できると考えられる。
【００９９】
携帯メディアデバイス８１４は、無線リンク８２０によって無線データネットワーク８０４に結合することができる。同じく、携帯メディアデバイス８１２は、無線リンク８２２によって無線データネットワーク８０４に結合することができる。この関連で、携帯メディアデバイス８１４および８１２は、無線データネットワーク８０４を介して中央メディアサーバ８０８にアクセスすることができる。さらに、携帯メディアデバイス８１０、８１２および８１４は、互いに無線でアクセスすることができ、それによってメディア項目データを携帯メディアデバイス間で交換することができる。
【０１００】
コンピューティングシステム２００は、ＭＰ３プレーヤなどの携帯メディアプレーヤに関連できるメディアデバイス、ならびにＬＳＤ２０４およびＨＤ２０２を含むことができるモバイル電話などの無線デバイスという形をとることができる。こうしたモバイルデバイスは、モバイルデバイス上で動作するホストコンピュータ上のメディア管理アプリケーションを含むことができる。モバイルデバイスの携帯性を考えると、モバイルデバイスは、小形化され、リソース（例えば、記憶容量）が縮小されている。したがって、モバイルデバイス上で使用されるように設計されたメディア管理アプリケーションは、例えばパーソナルコンピュータなどのより大きく性能の高いコンピューティングデバイス上で動作するメディア管理アプリケーションに相当するものが提供すると考えられる機能および能力よりも、少ない機能および能力を提供すると考えられる。モバイルデバイスが、中央メディアサーバ８０８に無線アクセスできることを前提とすると、モバイルデバイスは、メディアサーバ８０８と対話してメディア項目データ（または他のデータ）をリクエストしかつ／または受け取ることができる。この関連で、モバイルデバイス上で動作しているメディア管理アプリケーションは、メディアサーバ８０８と通信して、サーバにある利用可能なメディアコンテンツをナビゲートすること（メディア格納のナビゲーションなど）、メディアデバイスに対するメディアコンテンツの定期的な配信を受け取ること（サーバからメディアデバイスへのメディア項目データの毎日のプッシュなど）などを含む様々なタスクを実行することができる。
【０１０１】
本願明細書で説明されるローカル記憶デバイスは、オーディオ、ビデオまたはピクチャファイルなどのデジタルメディアを管理するために使用されるセキュアデジタル（ＳＤ）メモリカードフォーマットおよびプロトコルなど、任意のメモリカードフォーマットまたはプロトコルに対応しているとよい。記憶デバイスは、マルチメディアカード（ＭＭＣ）メモリカードフォーマット、コンパクトフラッシュ（ＣＦ）メモリカードフォーマット、フラッシュＰＣ（例えば、ＡＴＡフラッシュ）メモリカードフォーマット、スマートメディアメモリカードフォーマット、またはそのほか任意の業界標準仕様に対応しているとよい。こうしたメモリカードの供給業者の１つが、カリフォルニア州ミルピタスのサンディスク  コーポレイションである。不揮発性メモリは、そのメモリまたは格納された状態を電源がなくなっても維持する。この記憶デバイスは、これらに限定されるものではないが、電気的に消去可能でプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、ＥＰＲＯＭ、ＭＲＡＭ、ＦＲＡＭ強誘電体および磁気メモリを含む他の消去可能でプログラム可能なメモリテクノロジーにも適用可能である。なお、記憶デバイスの構成は、リムーバブルメモリのタイプに依存せず、フラッシュメモリであっても別のタイプのメモリであっても、任意のタイプのメモリを用いて実装されるとよい。記憶デバイスは、ワンタイムプログラマブル（ＯＴＰ）メモリチップおよび／または３次元メモリチップテクノロジーを用いて実装されることもできる。
【０１０２】
そのようなメモリカードが使用されるホストシステムには、セルラー電話、パーソナルコンピュータ、ノートブック形コンピュータ、ハンドヘルドコンピューティングデバイス、カメラ、オーディオ再生デバイス、およびそのほかリムーバブルデータ記憶装置を必要とする電子デバイスが含まれる。フラッシュＥＥＰＲＯＭシステムは、ホストシステムに組み込まれたバルク大容量記憶装置として利用することもできる。記憶デバイスは、ＰＤＡ（個人用携帯情報端末）、モバイルハンドセット、およびそのほかの様々な電子デバイス上に実装され得るローカルプロキシシステムの一部としてもよい。ＰＤＡは典型的に、数例を挙げればアドレス帳、予定表、および電子手帳など、様々な個人情報管理アプリケーションを用いて実装される、ユーザが持つコンピュータシステムとして既知である。
【０１０３】
本願明細書に記載されているように、コンピューティングシステムは、ホストデバイス（ＨＤ）およびローカル記憶デバイス（ＬＳＤ）を含むことができる。ＬＳＤは、大容量記憶デバイスとしても、またはネットワークアクセス可能なデバイスとしても、同時に機能できる。こうすることで、いくつかのアプリケーションの、コンピューティングシステムによる実行が可能である。そのようなアプリケーションは、互いに独立して実行可能であり、それぞれ、ＬＳＤ上に格納されているコンテンツの対応するセットを独立して管理することができる。なお、コンテンツの管理には、ＬＳＤによって実行されるか、またはＬＳＤ上に格納されているコンテンツに対して実行される任意の数の動作が含まれ得る。そのような動作には、これらに限定されるものではないが、データの読み込み、データの書き込み、データの消去、データのコピー、データのフォーマットなどが含まれ得る。本発明により提示される利点の１つは、各アプリケーションには互いに何の関係がなくても、一方のアプリケーションに、もう一方のアプリケーションがＬＳＤ上で利用可能にするコンテンツについて通知するＬＳＤの能力にある。こうすることで、独立したアプリケーション間の相乗効果を得ることができ、協力的な環境が提供され、例えばコンピューティングシステムの動作改善、リソース（すなわち、メモリ、帯域幅、処理）割り当ておよび使用、ならびにそのほかの要素の改善をもたらすことができる。
【０１０４】
例えば、図９は、本発明の実施形態に従ったコンピューティングシステム１１００を示す。システム１１００は、メモリアレイ１１０６を有するＬＳＤ１１０４と通信しているホストデバイス（ＨＤ）１１０２を含む。ＨＤ１１０２は、アプリケーション１１０８を実行しているとよい。アプリケーション１１０８は、ＬＳＤ１１０４上の関連したローカル（ブラウザ）キャッシュ１１１４を管理するブラウザキャッシュマネージャ（ＢＣＭ）１１１２を有するブラウザアプリケーション１１１０などのインターネットアプリケーションを含むことができる。ＢＣＭ１１１２は、メモリコントローラ１１２０およびＬＳＤドライバ１１２２を含むことができ大容量記憶パス１１１８と呼ぶことができるものを使用して、ＨＤＦＳ１１１６を経由してブラウザキャッシュ１１１４を管理できる。ＬＳＤ１１０４は、ネットワークインターフェイス１１３０を含むネットワークパス１１２８を経由してリモートプロキシキャッシュマネージャ（ＲＰＣＭ）１１２６によって管理されるプロキシキャッシュ１１２４を含むことができる。なお、ネットワークパス１１２８を、ＨＤＦＳ１１１６から独立して、ＬＳＤ１１０４の指示に応じてＨＤ１１０２によって確立することが可能である。さらに、ネットワークパス１１２８がＨＤ１１０２によって確立されると、ネットワークパス１１２８の何らかの保持（およびそのほか任意の「ハウスキーピング」任務）を除いて、ＨＤ１１０２によりそれ以上介入されることはない。
【０１０５】
動作中、ＲＰＣＭ１１２６は、先行方式で、ＬＳＤ１１０４に、プリフェッチされたコンテンツ１１３８を直接プッシュすることができる。先行方式とは、ＢＣＭ１１１２によってコンテンツ１１３８の任意のリクエストが実際にあるより前に、プリフェッチされたコンテンツ１１３８をＬＳＤ１１０４にプッシュ可能であるということであり、その結果、ネットワークパス１１２８上でＲＰＣＭ１１２６へ実際のリクエストが送られる必要がなくなる。こうすることで、ネットワーク帯域幅が保たれる。
【０１０６】
その結果、ＢＣＭ１１１２とＲＰＣＭ１１２６とは、違う形で使用されるということは明らかである。例えば、ＢＣＭ１１１２は、大容量記憶パス１１１８を介して、ブラウザアプリケーション１１１０によって既にリクエストされたコンテンツ１１４０を、ＬＳＤ１１０４内のブラウザキャッシュ１１１４にローカルにキャッシュするように機能することができる。その一方で、ＲＰＣＭ１１２６は、典型的には、コンテンツのプリフェッチ（すなわち、その特定のコンテンツがリクエストされる前にコンテンツを読み出すこと）など、ＢＣＭ１１１２をサポートする機能を実行する。しかし、ＢＣＭ１１１２およびＲＰＣＭ１１２６は、典型的には様々なベンダから提供されることから、ＢＣＭ１１１２およびＲＰＣＭ１１２６は別々のキャッシングポリシーを有する可能性が高い。さらに、大容量記憶パス１１１８およびネットワークパス１１２８が互いに交差（すなわち、通信）しないことから、ＢＣＭ１１１２およびＲＰＣＭ１１２６が同期された形で機能することはできない。
【０１０７】
この同期性の欠如は、ＢＣＭ１１１２／ＲＰＣＭ１１２６の全体的なパフォーマンスの観点から、明らかに最適とは言えない。例えば、ＲＰＣＭ１１２６が、ＢＣＭ１１１２によって既に格納されたコンテンツを格納し（およびその逆も）、その結果、貴重なメモリ、処理、および帯域幅リソースを無駄にする可能性がある。このリソースの無駄は、ほとんどまたはすべてのリソースの価値が非常に高いモバイル環境では特に問題となり得る。しかし、本発明は、従来通り構成されたシステムにはできない形で協働するＲＰＣＭ１１２６およびＢＣＭ１１１２を提供する。例えば、ＬＳＤ１１０４は、ＢＣＭ１１１２がブラウザキャッシュ１１１４にキャッシュするブラウザコンテンツ１１４０のタイプおよび性質についてＲＰＣＭ１１２６に通知することができる。こうすることで、ＲＰＣＭ１１２６は、例えば、ＢＣＭ１１１２によってブラウザキャッシュ１１１４に既にキャッシュされたページのリンクに対応する任意のページを自動的にプリフェッチすることができる。さらに、ＲＰＣＭ１１２６は、既にブラウザキャッシュ１１１４に格納されているコンテンツ１１４０をキャッシュするのに必要な作業の繰り返しを避け、貴重なリソースの非生産的使用をさらに削減することができる。さらに、ＲＰＣＭ１１２６は、ＢＣＭ１１１２のキャッシングポリシーの「リバースエンジニアリング」を行い、それによって、ＲＰＣＭ１１２６がＢＣＭ１１１２のアクションを予測する能力が改善され、その結果、ＲＰＣＭ１１２６とＢＣＭ１１１２との対話の全体的な効率を改善することができる。この効率改善は、エンドユーザのインターネット体験の大幅な改善をもたらすことができる。
【０１０８】
図１０は、図９に示されているシステム１００の特定の実施形態を例示するシステム１２００を示す。システム１２００は、ローカル記憶デバイス（ＬＳＤ）１２０４に接続されているか、または他の方法でＬＳＤ１２０４と通信しているホストデバイス（ＨＤ）１２０２を含むことができる。ＬＳＤ１２０４とは、ＨＤ／ＬＳＤインターフェイス１２０６を経由してＨＤ１２０２と通信できる。ＬＳＤ１２０４は、比較的小さな形態的要素を有するメモリカードなどのリムーバブルメモリデバイスという形をとることができ、カメラ、ハンドヘルドまたはノートブック形コンピュータ、ネットワークカード、ネットワークアプライアンス、セットトップボックス、ハンドヘルドまたはそのほかの小形オーディオプレーヤ／レコーダ（例えば、ＭＰ３デバイス）、および医療用モニタなどの電子製品のデジタルデータを格納するために使用可能である。メモリカードの例には、ＰＣカード（以前はＰＣＭＣＩＡデバイス）、フラッシュカード（例えば、コンパクトフラッシュタイプＩおよびＩＩ）、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ＡＴＡカード（例えば、コンパクトフラッシュカード）、メモリスティック、ＳｍａｒｔＭｅｄｉａカードがある。さらに、ＬＳＤ１２０４は、カリフォルニア州ミルピタスのサンディスク  コーポレイションによって製造されたＳＤ対応のｉＮＡＮＤ（登録商標）を組み込んだフラッシュドライブなどの非リムーバブルメモリデバイスという形をとることができる。
【０１０９】
なお、ＨＤ／ＬＳＤインターフェイス１２０６は、ＨＤ１２０２およびＬＳＤ１２０４が機械的に接続することができる機械的エンティティ（ソケットまたは相互接続バスなど）として構成可能である。いくつかの実施形態では、ＨＤ／ＬＳＤ１２０６は、無線インターフェイスという形をとることができる。ＨＤ１２０２はプロセッサを含むが、明瞭にするために、ＨＤ１２０２に含まれているプロセッサは、図に示されることも、この説明の中でさらに言及されることもない。しかし、それでもなお存在しているものと想定される。ＬＳＤ１２０４は、物理的に、ＨＤ１２０２に排他的に接続可能であり、したがって、ＨＤ１２０２による介入なしにシステム１２００の外部の回路および／またはアプリケーションにアクセスしたり、または他の形でそれと通信したりすることはできない。典型的には、ＬＳＤ１２０４は、ＨＤ１２０２によって提供される当該インターフェイス以外には、ＨＤ１２０２の外部のデバイスに対する何らのインターフェイスも利用しない。
【０１１０】
ＨＤ１２０２は、ホストデバイスファイルシステム（ＨＤＦＳ）１２０８を含む。ＨＤＦＳ１２０８は、ＬＳＤ管理コマンド１２１０を発行することができ、このコマンド１２１０を、ＬＳＤドライバ（図示せず）およびＨＤ／ＬＳＤインターフェイス１２０６を経由してＬＳＤ１２０４に渡すことが可能である。例えば、ＬＳＤ管理コマンド１２１０は、ＬＳＤ１２０４が論理ブロックアドレス（ＬＢＡ）アーキテクチャを有するデータ記憶エリアを含むように設定されている場合には、ブロックコマンドという形をとることができる。システム１２００は、ＬＳＤ１２０４またはＨＤ１２０２上に常駐するいくつかのアプリケーションを有することができ、このアプリケーションは互いに独立して実行可能である。さらに、アプリケーションはそれぞれ、それ自体のデータの特定のキャッシュをＬＳＤ１２０４上で管理することができ、これもそれぞれ互いに独立している。そのようなアプリケーションには、例えば、ＨＤＦＳ１２０８を利用して、前に説明した大容量記憶パス１１１８を使用しＬＳＤ１２０４と通信することができるＢＣＭ１１１２によってサポートされる、ブラウザ１２１２などのインターネットアプリケーションが含まれ得る。ブラウザアプリケーション１２１２に加えて、独立したアプリケーション１２１４が、ＨＤＦＳ１２０８を利用してＬＳＤ１２０４と通信することができ、したがってこれはＨＤＦＳ１２０８に「認識」される。一方、アプリケーション１２１４とは対照的に、特定の独立したアプリケーションは、大容量記憶パス１１１８を利用せずにデータをＬＳＤ１２０４に格納する。そのようなアプリケーションは、外部またはターゲットアプリケーション１２１６と呼ぶことができ、したがってこれはＨＤＦＳ１２０８に「認識」されない。
【０１１１】
記載される実施形態では、ターゲットアプリケーション１２１６は、ローカルまたはリモートのいずれかで、任意の数の位置およびデバイスに存在することができる。そのような位置およびデバイスには、例えば、ＨＤ１２０２（ローカルアプリケーション１２１６−１を有する）または外部デバイス１２１８（その中にローカルアプリケーション１２１６−２が存在する）など、ＨＤ１２０２およびＬＳＤ１２０４の外部にあるがそれでもシステム１２００内にある任意のデバイスが含まれると考えられる。記載される実施形態では、外部デバイス１２１８は、インターフェイス１２２０を経由してＨＤ１２０２に結合された第２のＬＳＤ１２１８という形をとることができる。さらに、前述した位置およびデバイスは、リモートデバイス１２２２（その中に、プロキシキャッシュ１１２４を管理するのに適したＲＰＣＭ１１２６という形をとることができるリモートアプリケーション１２１６−３が存在する）も含むことができる。
【０１１２】
ＬＳＤ１２０４は、コントローラ１２２４およびデータ記憶エリア１２２６を含むことができる。データ記憶エリア１２２６は、ＨＤＦＳ１２０８によって大容量記憶パス１１１８を使用して管理される大容量記憶エリア１２２８を少なくとも含むように論理的に構成可能である。特に有用な構成では、大容量記憶エリア１２２８は、ＬＢＡベースの大容量記憶エリアとすることができる。データ記憶エリア１２２６はさらに、ＨＤＦＳ１２０８に認識されない部分１２３０を含むように論理的に構成可能である。ＨＤＦＳ１２０８に認識されないとは認識されない部分１２３０は、ＨＤＦＳ１２０８によって管理されず、その結果ＨＤＦＳ１２０８にとって直接アクセス可能でないということになる。
【０１１３】
大容量記憶エリア１２２８は、ブラウザ１２１２のサポートとしてＢＣＭ１１１２によって提供されるブラウザコンテンツ１１４０を含むことができるブラウザキャッシュ１１１４を含むように、さらに論理的に構成可能である。ブラウザ１２１２によって以前に使用された情報をブラウザキャッシュ１１１４にてローカルにキャッシュすることによって、ブラウザ１２１２を提供するために使用されるネットワーク帯域幅の量が削減される。利用可能なネットワーク帯域幅は限られていると考えられるため、特に、モバイルネットワーク帯域幅の削減は、モバイルネットワークの効率的な動作に不可欠であることもある。認識されない部分１２３０は、プロキシキャッシュ１１２４を含むように論理的に構成可能である。
【０１１４】
キャッシングメカニズムのパフォーマンスに関係する問題は、コンテンツがどのようにキャッシュに入れられそこから削除されるかを決定するキャッシングポリシーである。キャッシングポリシーは、典型的には、アプリケーションデベロッパによって公布される最適化命令から形成され、これに従ってコンピュータ上に格納されている情報のキャッシュが管理される。キャッシュサイズは通常限られ、キャッシュが満杯であれば、キャッシングポリシーによって、どの項目を破棄するかが選択され、新たな項目の空間がつくられなければならない。最も効率的なキャッシングアルゴリズム（キャッシングヒューリスティックとも呼ばれる）は、常に、将来最も長時間にわたって必要とされない情報を破棄することであると考えられる。どのくらい先に情報が必要となるか予測することは不可能であることから、これは実用的ではない。実用上の最小は実験をしてからのみ計算でき、実際に選択されたキャッシュアルゴリズムの有効性と最適最小とを比較することは可能である。様々なキャッシングポリシーの例には、最長時間未使用法（ＬＲＵ）、最短時間未使用法（ＭＲＵ）、擬似ＬＲＵ、および適応置換キャッシュ（ＡＲＣ）が含まれる。
【０１１５】
キャッシュに格納されたリソースの一時的な性質に加えて、格納されているコンテンツ自体の性質も重要な検討事項であり得る。格納されているコンテンツの性質は、コストが異なる項目（入手に長時間かかる項目など、獲得コストが高い項目を保持する）、より多くキャッシュを占有する項目（各項目のサイズが異なれば、キャッシュは大きな項目を破棄していくつかの小さな項目を格納したいこともある）、ならびに時間が経つと満期になる項目とすることができる。アプリケーションデベロッパが、アプリケーションに関連するキャッシュに適用されるキャッシングポリシーを策定するとき、こうした検討事項の全部または一部のみを、程度の差はあっても考慮に入れることができる。
【０１１６】
ブラウザ１２１２の場合、ブラウザキャッシュ１１１４に適用される適切なキャッシングポリシーは、特にブラウザ１２１２が使用されることになるモバイル環境の観点から見て、前述した検討事項のいずれかまたは全部によって決めることができる。ブラウザ１２１２はモバイル環境で使用されることになるため、ネットワークトラフィック、利用可能な帯域幅などのことになると特に大きな負担となる項目に特別に配慮することができる。したがって、ブラウザデベロッパは、特にモバイルＷＥＢ環境で使用されたときにブラウザ１２１２のパフォーマンスを最適化するように調整されたブラウザキャッシュポリシーを作成する。プロキシキャッシュ１１２４に適用される任意のキャッシングポリシーは、ブラウザキャッシュ１１１４に適用される当該キャッシュポリシーとは大きく異なる可能性がある。プロキシキャッシュのキャッシングポリシーと、ブラウザキャッシュのキャッシングポリシーとについて生じ得るずれは、ブラウザ１２１２によって示される大きな非効率性およびパフォーマンス損失をもたらす恐れがある。例えば、プロキシキャッシュ１１２４に適用されるプロキシキャッシュのキャッシングポリシーが、そこに格納されるリソースの「新しさ」を犠牲にして利用可能なキャッシュメモリスペースを保つことを目的とすることもあり、その一方で、ブラウザキャッシュ１１１４に適用されるブラウザキャッシングポリシーは、まさに正反対のことを目的とし、「最も新しい」リソースを、他のいかなる要因も犠牲にして維持することに焦点を合わせることもある。その結果、この例では、プロキシキャッシュのキャッシングポリシーとブラウザキャッシュのキャッシングポリシーとが相反する目的で機能し、そのプロセスにおいて、プロキシキャッシュ１１２４とブラウザキャッシュ１１１４との動作に基本的対立が引き起こされる。明らかに、ローカルキャッシュシステムの全体的な効率および利用を改善するためには、プロキシキャッシュ１１２４およびブラウザキャッシュ１１１４が可能な限り協調して機能することが望ましい。
【０１１７】
本発明の特徴の１つは、ＬＳＤ１２０４が、ブラウザキャッシュ１１１４に格納されているデータの性質（すなわち、ファイルのサイズ、ファイルの種類）とブラウザ１１１４に格納されているデータの動態（すなわち、ファイル保存の長さ）とに基づき、ブラウザキャッシュのキャッシングポリシーを推定（すなわち、リバースエンジニア）できるということである。例えば、ブラウザキャッシュコンテンツ１１４０の現在の状態と、ブラウザキャッシュコンテンツ１１４０の任意の数の以前の状態とを比較することができる。こうすることで、ブラウザキャッシュコンテンツ１１４０の経時的な状態変化を示すパターンを作成することができる。次にこのパターンを、ＬＳＤ１２０４によって、例えばブラウザキャッシュのキャッシングポリシーを推定するために使用することが可能である。例えば、ＬＳＤ１２０４が、ブラウザキャッシュ１１１４は最長時間未使用の項目を最初に破棄していると判断すると、その結果ＬＳＤ１２０４は、ブラウザキャッシュ１１１４がＬＲＵタイプのキャッシングポリシーに沿って構築されたブラウザキャッシュのキャッシングポリシーにより指示されていると推定することができる。その一方で、ＬＳＤ１２０４が、ブラウザキャッシュ１１１４は最短時間未使用の項目を最初に破棄していると推定すると、その結果ＬＳＤ１２０４は、ブラウザキャッシュ１１１４がＭＲＵタイプのキャッシングポリシーに沿って構築されたキャッシュポリシーに従っていると推定することができる。いずれの場合でも、ＬＳＤ１２０４がブラウザキャッシュのキャッシングポリシーを推定すると、次にＬＳＤ１２０４は、推定したブラウザキャッシュのキャッシングポリシーを使用してプロキシキャッシュのキャッシングポリシーに変更を加え、ローカルキャッシュシステムの効率性の全般的な改善をもたらすことができる。
【０１１８】
例えば、ＬＳＤ１２０４が、ブラウザキャッシュ１１１４はＬＲＵタイプのキャッシングポリシーに従っていると推定すれば、ＬＳＤ１２０４は、プロキシキャッシュのキャッシングポリシーに変更を加えて、最長時間未使用のプロキシキャッシュコンテンツを優先的に破棄することができる。このようにして、全体的なコンテンツの重複が削減され、ローカルキャッシュシステムの利用を全体的に改善することができる。反対に、ＬＳＤ１２０４がブラウザキャッシュ１１１４はＭＲＵタイプのキャッシングポリシーに従っていると推定すれば、ＬＳＤ１２０４は、プロキシキャッシュのキャッシングポリシーに変更を加えて、最短時間未使用のプロキシキャッシュコンテンツを優先的に破棄することができる。いずれの場合でも、ＬＳＤ１２０４は、適切であると考えられる通りに、プロキシキャッシュのキャッシングポリシーに自由に変更を加えることができる。
【０１１９】
例えば、モバイルＷＥＢ環境では、ウェブページのプリフェッチを実行することが、プロキシキャッシュマネージャの重要な用途である。ブラウザは、エンドユーザに最も近いインターネットのエッジにあることから、ブラウザパフォーマンスのあらゆる改善により、エンドユーザの全般的なブラウジング体験を大幅に向上させることができる。したがって、プロキシキャッシュマネージャの動作を指示するのに使用されるキャッシュポリシーに変更を加えることによって、プロキシキャッシュマネージャは、例えば、ブラウザキャッシュに既に格納されているブラウザキャッシュコンテンツに関連したプロキシキャッシュコンテンツ（ＷＥＢページなど）を自動的にプリフェッチすることによって、確認されるブラウザパフォーマンスを改善することができる。例えば、ブラウザキャッシュにページＰが格納されていれば、プロキシキャッシュは、ページＰのリンクに現れる任意のＷＥＢページを自動的にプリフェッチすることができる（すなわち、ページＰ＋１など）。
【０１２０】
図１１は、本発明の実施形態に従ったＬＳＤ１１０４に含まれる典型的なコントローラ１３００を示す。コントローラ１３００は、図９に示されているコントローラ１１２０の特定の実施形態であり、コントローラ１１２０上で実行されるアプリケーションを表す様々な機能ブロックを示す。したがって、コントローラ１３００は、ＨＤＦＳ１２０８と通信している管理ブロック１３０２を含む。管理ブロック１３０２はさらに、大容量記憶フィルタブロック１３０４と通信している。大容量記憶フィルタブロック１３０４は、インターネットファイルマネージャブロック１３０６およびプロキシキャッシュマネージャブロック１３０８の両方と通信する。インターネットファイルマネージャブロック１３０６およびプロキシキャッシュマネージャブロック１３０８は、どちらもそれぞれプロキシサーバブロック１３１０と通信できる。記載される実施形態では、大容量記憶フィルタブロック１３０４は、ブラウザキャッシュ１１１４に格納されているブラウザキャッシュコンテンツ１１４０についての情報を、プロキシキャッシュマネージャブロック１３０８に提供することができる。格納されているコンテンツの性質を推論し、この推論をＲＰＣＭに伝達するために使用することができるテクニックがいくつかある。テクニックの１つは、格納されているコンテンツファイルに関連した名前およびその対応するファイル拡張子（「．ｈｔｍ」など）の判断を提供する。この情報が分かれば、ＲＰＣＭに伝達するとよい。プロキシキャッシュマネージャブロック１３０８は、ＬＳＤ１１０４のローカルにあるとよい。一部の実施例では、プロキシキャッシュマネージャブロック１３０８は、リモートプロキシサーバ１１２６などのリモートデバイスに存在することができる。
【０１２１】
コンテンツ配布に対して少なくともプッシュ／プル手法の利点を提供する、保護されているデジタルコンテンツのセキュアな配布および消費のためのソリューションを提供する方法、システム、および装置について記載する。この説明の中で、「保護されているデジタルコンテンツ」は、使用およびアクセスの制限などの制限をコンテンツプロバイダによって課されているデジタルコンテンツを指す。例えば、使用制限には、例えばコンテンツを特定回数または特定期間のみ再生できること、ならびに不正コピーを防ぐことが含まれ得る。アクセス制限は、保護されているデジタルコンテンツへのアクセスを、適切なアクセス資格を持つエンティティのみに制限することができる。保護されているデジタルコンテンツは、コンテンツプロバイダによって課されるすべての制限を保つように、特定のＤＲＭ方式に応じて任意の関連する設定をカバーすることができる。ＬＳＤにて受け取られる保護されているコンテンツは、コンテンツのみを含むかまたは「結合配信 (combined delivery)」と呼ばれ、保護されている１つのコンテンツおよび任意の関連した権利オブジェクト（ＲＯ）を含むかまたは対応する保護されている１つのコンテンツが既にＬＳＤに格納されていれば「分離配信 (separate delivery)」と呼ばれ、ＲＯを含むことができる。
【０１２２】
本発明は、ホストデバイスファイルシステム（ＨＤＦＳ）を有するホストデバイス（ＨＤ）と、メモリコントローラによって制御される大容量記憶メモリアレイを有するローカル記憶デバイス（ＬＳＤ）とを含むコンピューティングシステムの観点から記載することができる。本願明細書に記載される実施形態では、ＨＤＦＳは、ＬＳＤドライバを含む大容量記憶パスを経由して大容量記憶メモリアレイを管理する。場合によっては、メモリアレイには、予めロードされたデジタルコンテンツが格納されていることがある。予めロードされたデジタルコンテンツとは、製造業者、ＯＥＭ、または任意のコンテンツプロバイダによってメモリアレイに格納されたデジタルコンテンツのことである。そのような予めロードされたデジタルコンテンツには、歌曲、音楽、および／またはビデオなどのメディア項目が含まれると考えられ、これにはさらに、保護されている予めロードされたメディア項目および保護されていない予めロードされたメディア項目の両方が含まれ得る。メモリアレイが、予めロードされたデジタルコンテンツを含んでいても、または含んでいなくても、ＬＳＤは、デジタルコンテンツサーバからデジタルコンテンツを取得することができ、ここで、この取得はＨＤＦＳには認識されない。しかし、場合によっては、メモリアレイに予めロードされたデジタルコンテンツが格納されていれば、ＬＳＤは、受け取ったデジタルコンテンツを格納できないか、またはそもそもデジタルコンテンツサーバからデジタルコンテンツを受け取れないほうが望ましいこともある。この状況には、例えば、コンテンツ発信者が、デジタルコンテンツ（音楽、歌曲などを含む専有コンテンツなど）をメモリアレイに予めロードし、追加のコンテンツ（この専有デジタルコンテンツに関連しない）をＬＳＤに格納されたくない場合が含まれ得る。こうした場合には、ＬＳＤは、いかなるデジタルコンテンツの取得もできないようにされてもよいし、あるいはメモリアレイにデジタルコンテンツを格納することはできないが、それでもなお予めロードされたデジタルコンテンツをメモリアレイからストリーミングすることはできてもよい。
【０１２３】
いずれの場合でも、デジタルコンテンツがＬＳＤによって取得されるときはいつでも、この取得はＨＤＦＳに認識されず、より一般には、この取得は大容量記憶パスに認識されない。ＬＳＤは、取得した保護されているデジタルコンテンツを、様々な方法でセキュアにメモリアレイに格納することができる。場合によっては、ＬＳＤにて受け取られる保護されているデジタルコンテンツの何らかの変換が生じることもある。例えば、権利オブジェクト（ＲＯ）を、暗号化されていない形式で（すなわち、「プレーンテキストで」）、メモリアレイのうちのＨＤＦＳに認識されない部分に格納することが可能であり、その一方で、対応するデジタルコンテンツを、アレイのうちのＨＤＦＳに認識される部分に格納することが可能である。あるいは、ＲＯを、暗号化された形式ではあるが、ＨＤＦＳに認識されるメモリアレイの部分に格納することができる。いずれの場合でも、デジタルコンテンツは、デジタルコンテンツにより維持される使用制限内で、ユーザ制御の下、ローカルでセキュアに格納することができる。さらに、ＨＤ内の大容量記憶パスに追加のＤＲＭソフトウェアを追加または統合する必要がなく、その結果、最先端のセキュリティとの互換性が保持され、それによってコンテンツプロバイダの要件が満たされる。メモリアレイに格納されると、そのデジタルコンテンツの全部または一部を、ＬＳＤがメモリアレイからストリーミングできる（例えば、ユーザが特定のメディア項目を再生するように選択したときなど）。
【０１２４】
図１２Ａは、保護されているデジタルコンテンツをセキュアに配布および消費するのに適した、本発明の実施形態に従ったシステム２９００を示す。システム２９００は、ＨＤ２０２、ＬＳＤ２０４、およびデジタルコンテンツ２９０４を格納するように構成されたデジタルコンテンツサーバ２９０２を含む。デジタルコンテンツ２９０４は、保護されているデジタルコンテンツまたは保護されていないデジタルコンテンツを含むことができる。デジタルコンテンツの保護に使用される方式は多数あり、その多くは、デジタル著作権管理、すなわちＤＲＭ（発行者および著作権保持者によって、デジタルメディアまたはデバイスの使用を限定するために使用されるアクセス制御テクノロジーを指す包括的用語）に該当する。特定のＤＲＭ方式は、通常、少なくとも、保護されているデジタルコンテンツ（ＰＤＣ）取得方法（分離配信の場合にはＲＯ取得方法を意味する）、および少なくとも、保護されているデジタルコンテンツの消費方法を定義し、任意の使用／アクセス制限のセキュアな強制を可能にする（ＲＯ強制方法を含むこともできる）。セキュアなＰＤＣ取得およびセキュアなＰＤＣ消費方法の定義と同時に、コンテンツプロバイダは通常、堅牢性規則のセットを規定して、「セキュア」が何を意味するのかを定義する。これは通常、不正使用および／またはアクセスを回避するために、どのメカニズム（すなわち、ソフトウェアまたはハードウェア）によって、保護されているデジタルコンテンツがローカルに格納されるべきかを表すセキュア記憶規定を含む。この説明との関連で、任意の所与のＤＲＭ方式に関して、ＬＳＤは、コンテンツプロバイダにより要求される任意の必要なセキュア記憶規定に少なくとも対応していると仮定される。
【０１２５】
従来のシステムでは、ＨＤ２０２は、保護されているデジタルコンテンツ２９０４が配布され、最終的にエンドユーザによって消費されるために必要となる特定のＤＲＭプログラムを含まなければならない。従来技術では、これは通常、コンテンツ／関連ＲＯが確実に許可された形で消費されるように、ＤＲＭ特有コンテンツを処理することができる何らかのＤＲＭ特有アプリケーションを大容量記憶パスに統合することによって達成される。ここでは、所与のＤＲＭ方式に関して、ＬＳＤが、要求される「セキュア記憶規定」に少なくとも対応しているということが前提となっている。一方、デジタルコンテンツサーバ２９０２から受け取られてＬＳＤ２０４にて格納されるあらゆるデジタルコンテンツがすべての制限を維持するため、大容量記憶パスへの追加のＤＲＭ特有エージェントの統合を必要としないことから、本発明は、いかなる特定のＤＲＭモジュール／アプリケーションをＨＤＦＳまたはＨＤと統合することも、ＨＤ２０２に要求しない。記載される実施形態では、記憶アレイ２３８は、大容量記憶パスを使用してＨＤＦＳ２０８によって管理される大容量記憶エリア２９０８を含み、さらにＨＤＦＳに認識されない記憶エリア２９１０を含むように論理的に構成可能である。ＨＤＦＳ２０８に認識されないとは、ＨＤＦＳ２０８が、認識していない記憶エリア２９１０を管理しないということである。こうすることで、ＨＤＦＳ２０８は、認識していない記憶エリア２９１０にて実行されるいかなる記憶動作も、そこに格納されるコンテンツも感知しない。
【０１２６】
動作中、ＨＤ２０２は、大容量記憶エリア２９０８が予めロードされた保護されている任意のデジタルコンテンツ２９１２を含むかどうかを判断する。そのような予めロードされた保護されているデジタルコンテンツには、例えば、例として宣伝に関係するデジタル音楽ファイル、デジタルビデオファイル、デジタルメディアファイルなどの専有デジタルファイルが含まれると考えられる。ＨＤ２０２が、大容量記憶エリア２９０８には、予めロードされた保護されているデジタルコンテンツ２９１２は格納されていないと判断すれば、ＬＳＤ２０４は、ＬＳＤ２０４とデジタルコンテンツサーバ２９０２との間に通信パス２９１４を確立するように、ＨＤ２０２に指示することができる。（なお、デジタルコンテンツサーバ２９０２は、通信パス２９１４を確立するようにＨＤ２０２に指示することができる。）通信パス２９１４が確立されてからは、ＨＤ２０２は、通信パス２９１４の保持を除いて、それ以上は関与しない。ＬＳＤ２０４およびデジタルコンテンツサーバ２９０２は、ＨＤ２０２によるそれ以上の介入なしに（通信パス２９１４の保持を除いて）通信パス２９１４上で論理的に対話できる。この論理的対話の一部として、ＬＳＤ２０４およびリモートデジタルコンテンツサーバ２９０２の両方が互いに認証を行うために、デジタルコンテンツサーバ２９０２またはＬＳＤ２０４のいずれかが、リモートデジタルコンテンツサーバ２９０２とＬＳＤ２０４との間の認証セッションを開始できる。
【０１２７】
認証セッションが無事に完了すると（すなわち、ＬＳＤ２０４およびデジタルコンテンツサーバ２９０２が認証済み）、ＬＳＤ２０４およびデジタルコンテンツサーバ２９０２は通信パス２９１４上での論理的対話を再開できる。より一般的には、保護されている任意のデジタルコンテンツの取得メカニズムを、コンテンツプロバイダのセキュリティ要件を満たすように実装可能である。そのような取得メカニズムの一例は、ＯＭＡ（オープンモバイルアライアンス）ＤＲＭの場合であれば、権利オブジェクト取得プロトコル（ＲＯＡＰ）である。論理的対話の一部として、ＬＳＤ２０４が、保護されているデジタルコンテンツ２９０４（例えば、権利オブジェクトのみを含むことができる）のリモートデジタルコンテンツサーバ２９０２からＬＳＤ２０４への転送を開始するか、またはデジタルコンテンツサーバ２９０２が、保護されているデジタルコンテンツのデジタルコンテンツサーバ２９０２からＬＳＤ２０４への転送を開始することができる。いずれの場合でも、保護されているデジタルコンテンツ２９０４が受け取られると、コントローラ２３６は、保護されているデジタルコンテンツ２９０４をメモリアレイ２３８にセキュアに格納できる。場合によっては、コントローラ２３６は、保護されているデジタルコンテンツ２９０４を大容量記憶エリア２９０８に格納することができる。しかし、大容量記憶エリア２９０８に格納されるあらゆるデータは、ＨＤＦＳ２０８に認識されるため、その結果、そのようなデータはいずれも暗号化するとよい。一方、コントローラ２３６が、認識されないエリア２９１０に保護されているデジタルコンテンツ２９０４を格納する場合は、そのような暗号化は必要ない。例えば、デジタルコンテンツおよび対応する権利オブジェクト（ＲＯ）から成る保護されているデジタルコンテンツのセキュアな格納は、コンテンツおよびＲＯの両方をＨＤＦＳに認識されないエリアに格納するか、あるいは暗号化された当該コンテンツを認識されるパーティションに格納して対応するＲＯを認識されないパーティションに格納するなどによって達成することができる。
【０１２８】
図１２Ｂに示されているように、コントローラ２３６は、デジタルコンテンツストリーミングサーバ２９１６を含むように論理的に構成可能である。デジタルコンテンツストリーミングサーバ２９１６は、メモリアレイ２３８に格納されている任意のデジタルコンテンツ（予めロードされたデジタルコンテンツを含む）を読み込むことができる。デジタルコンテンツストリーミングサーバ２９１６は、記憶アレイ２３８から読み込まれた任意のデータを、データストリーム２９２０に編成することができる。データストリーム２９２０は、例えば当業者には周知であるヘッダおよびペイロードから形成可能な少なくとも１つのデータパケット２９２２を含むことができる。場合によっては、データパケット２９２２は暗号化可能である。ＬＳＤ２０４は、ストリーミングチャネル２９２４を確立するようにＨＤ２０２に指示することができ、ストリーミングチャネル２９２４上で、データパケット２９２２がデータストリーム２９２０の形式で移送されることが可能である。ストリーミングチャネル２９２４は、元のコンテンツプロバイダの要件により、セキュアなチャネルまたはセキュアでないチャネルとすることができる。データパケット２９２２が暗号化されている場合、暗号化されたデータパケット２９２２をセキュアなチャネル２９２４上で渡すことによって、不正使用に対するさらなる保護を実装することができる。本発明のもう１つの特徴として、例えば許可サーバ２９２８を使用して外部エージェント２９２６にサービスを提供するときに、保護されているデジタルコンテンツの使用／アクセス制限を解釈および強制するＬＳＤの能力（例えば、ＲＯのデクリメント）がある。このように、ＬＳＤがあらゆる制限を強制することから、いずれのプレーヤまたはそのほかの当該アプリケーションも、レガシーアプリケーションとすることができる。
【０１２９】
なお、チャネルはセキュアでないチャネルとすることができ（すなわち、認証されていないプレーヤがモバイル環境などでデジタルコンテンツを再生できる）、その場合には、使用制限がＬＳＤによって適用されるとよい（例えば、２度再生するとかあるいは１月１日から再生するなど）。あるいは、チャネルはセキュアなチャネルとすることができ（すなわち、例えばプレーヤの資格のストリーミングサーバによる承認が可能であるということで、相互認証が行われる）、この場合には、ＬＳＤは「アクセス制限」も強制することができる（例えば、許可された所定のプレーヤのみがコンテンツを再生できる）。典型的にモバイル環境では、セキュリティおよびそのほかの検討事項の観点から、セキュアでないチャネルで十分であることが多く、それと同時に、ＤＲＭタイプシステム固有の利点（権利オブジェクトのセマンティクスの使用など）も維持される。このように、本発明は従来技術と違い、専有ソフトウェアをＨＤプラットフォームに統合する必要なしに、それでもコンテンツプロバイダの制限を、全部ではないとしてもほとんど保持しながら、クローズド／専有ＤＲＭシステムとレガシープレーヤの世界とを結びつける能力を提供する。
【０１３０】
データパケット２９２２を処理するように構成されている外部エージェント２９２６は、外部エージェント２９２６−１としてリモートにまたはローカルエージェント２９２６−２としてローカルに位置することができる。この例では、ローカルエージェント２９２６−２は、ＨＤ２０２に位置すると考えられる。リモートエージェント２９２６−１は、データパケット２９２２を、ストリーミングチャネル２９２４を経由して受け取ることができる。特に有用な実施形態では、リモートエージェント２９２６−１を許可されたエージェントとすることができる。許可されたとは、リモートエージェント２９２６−１が、データパケット２９２２（暗号化されているかまたは暗号化されていない）を無事に処理する適切な資格を所有しているということである。適切な資格は、当該技術分野で周知の様々な方法で取得可能である。例えば認証および許可サーバ２９２８が、データパケット２９２２の処理に必要な適切な資格を提供することができる。そのようなサーバは、リモートに位置する（ネットワーク２２６または別のローカルデバイス内など）か、またはサーバ２９２８など、ローカルに位置することができる。記載される実施形態では、アプリケーション２９２６の資格は、オフバンド(off-band)で取得可能である。ローカル認証／許可サーバ２９２８は、任意の使用／アクセス制限を強制（例えば、デクリメント）できる。いずれの場合でも、アクセス制限がＬＳＤによって強制され、適切な資格を所有しているエージェントのみがデータパケット２９２２を処理することができる。こうすることで、保護されているデジタルコンテンツのプロバイダは、保護されているデジタルコンテンツがいずれも適切な資格を有するユーザのみに利用可能となると確信することができる。最も可能性が高い実施形態では、アプリケーション２９２６は、ＨＤ２０２において実行されストリーミング標準（例えば、ＲＴＰ／ＲＴＳＰ）に準拠しているローカルデジタルメディアプレーヤ／レンダラという形をとることができる。したがって、アプリケーション２９２６は、ＤＲＭソフトウェアをＨＤ２０２に追加するように要求することなく、保護されているデジタルコンテンツを再生／レンダリングすることができると考えられる。さらに、モバイル環境においてさらなるセキュリティをエージェント２９２６に要求することはできない可能性が高く、その結果、レガシープレーヤの使用が可能になり、その場合には、相互のサーバ／プレーヤ認証がなければ、使用制限のみをＬＳＤによって強制することができる。
【０１３１】
このように、本発明は、保護されているデジタルコンテンツのセキュアな配布および消費のためのソリューションを提供する。保護されているデジタルコンテンツは、ユーザ制御の下でローカルに格納することができ、その一方で同時に、レガシープレーヤ／プラットフォームによって最も広範に受け入れられ（すなわち、さらなるソフトウェアを追加したりまたは統合したりする必要がない）、それでもコンテンツプロバイダの要件を満たすように「最先端のセキュリティ」に対応し続け、有利である。
【０１３２】
本発明の特定の実施形態は、関連した管理ホストデバイスに認識されるローカル記憶デバイスの記憶容量の、リモートで有効化される仮想拡張を提供する。ローカル記憶デバイスのリモートでの／ユーザ制御された拡張というコンセプトは新しくはないが、本発明は、新しく革新的な手法を提供する。概して、すべての不揮発性記憶デバイスは、予め静的に定められた物理メモリアレイを含む。しかし、メモリアレイの一部は一般に、ホストデバイスファイルシステムから隠され、結果として、ホストデバイス、さらに結局のところユーザから隠されている。従来の実施例では、製造されるメモリアレイのサイズは生産の時点で決定され、したがって、ユーザは、メモリアレイの物理的な記憶容量を、所定の隠し容量の範囲を越えてさらに拡張させることはできない。すなわち、メモリアレイの総記憶容量には柔軟性がない。対照的に、本発明の目的は、ホストデバイスのホストデバイスファイルシステムにより把握されるローカル記憶デバイスの記憶容量の柔軟な拡張を提供することである。
【０１３３】
適切な任意の記憶デバイスが使用されるとよいと考えられるが、以下の特定の実施形態の記載では、記憶デバイスは不揮発性記憶デバイスであると想定される。ただし、本発明は、揮発性記憶デバイス上での実装も可能である。例として、不揮発性記憶デバイスは、フラッシュまたはＥＥＰＲＯＭベースの記憶デバイスとしてもよい。記憶デバイスはさらに、リムーバブルまたは非リムーバブル（固定）デバイスのいずれかとするとよい。周知のように、非リムーバブルデバイスは、一度ホストに接続されると後でホストから取り外すことは目的とされていないのに対して、リムーバブルデバイスは、取り外しまたはホストへの追加が容易にできるように構成されている。
【０１３４】
本発明の実施例に非常に適しているリムーバブルデバイスの１つのタイプが、メモリカードである。メモリカードは、様々な電子製品で使用されるように、デジタルデータを格納するために一般に使用されている。メモリカードは、格納されたデジタルデータを携帯できるように、電子システムから取り外しできることが多い。メモリカードは、比較的小さな形態的要素を有するとよく、カメラ、メディアプレーヤ／レコーダ（例えば、ＭＰ３デバイス）ハンドヘルドまたはノートブック形コンピュータ、個人用携帯情報端末（ＰＤＡ）、セルラー電話、ネットワークカード、ネットワークアプライアンス、セットトップボックス、およびハンドヘルドまたはそのほかのデバイスなどの、データを取得する電子製品のデジタルデータを格納するために使用可能である。
【０１３５】
本願明細書で説明されるローカル記憶デバイスは、オーディオ、ビデオまたはピクチャファイルなどのデジタルメディアを管理するために使用されるセキュアデジタル（ＳＤ）メモリカードフォーマットなど、任意のメモリカードフォーマットに対応しているとよい。記憶デバイスはさらに、マルチメディアカード（ＭＭＣ）メモリカードフォーマット、コンパクトフラッシュ（ＣＦ）メモリカードフォーマット、フラッシュＰＣ（例えば、ＡＴＡフラッシュ）メモリカードフォーマット、スマートメディアメモリカードフォーマット、またはそのほか任意の業界標準仕様に対応しているとよい。こうしたメモリカードの供給業者の１つが、カリフォルニア州ミルピタスのサンディスク  コーポレイションである。この記憶デバイスは、これらに限定されるものではないが、電気的に消去可能でプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、ＥＰＲＯＭ、ＭＲＡＭ、ＦＲＡＭ強誘電体および磁気メモリを含む他の消去可能でプログラム可能なメモリテクノロジーにも適用可能である。なお、記憶デバイスの構成は、リムーバブルメモリのタイプに依存せず、フラッシュメモリであっても別のタイプのメモリであっても、任意のタイプのメモリを用いて実装されるとよい。記憶デバイスを、ワンタイムプログラマブル（ＯＴＰ）メモリチップおよび／または３次元メモリチップテクノロジーを用いて実装することもできる。
【０１３６】
そのようなメモリカードが使用されるホストシステムには、パーソナルコンピュータ、ノートブック形コンピュータ、ハンドヘルドコンピューティングデバイス、セルラー電話、カメラ、オーディオ再生デバイス、およびそのほかリムーバブルデータ記憶装置を必要とする電子デバイスが含まれる。フラッシュＥＥＰＲＯＭシステムは、ホストシステムに組み込まれたバルク大容量記憶装置として利用することもできる。記憶デバイスは、ＰＤＡ（個人用携帯情報端末）、モバイルハンドセット、およびそのほかの様々な電子デバイス上に実装され得るローカルプロキシシステムの一部としてもよい。ＰＤＡは典型的に、数例を挙げればアドレス帳、予定表、および電子手帳など、様々な個人情報管理アプリケーションを用いて実装される、ユーザが持つコンピュータシステムとして既知である。
【０１３７】
以下の説明から明らかとなるように、マスタデバイスによって提供される物理的レスポンスを開始させるスレイブデバイスの能力を、マスタデバイスにさらなる利点を提供するために利用することができ、有利である。例として、本発明によれば、第１のスレイブデバイスは、マスタデバイスに第１のスレイブデバイスと第２のスレイブデバイスとの間の通信パスを確立させる、マスタデバイス提供の物理的レスポンスを開始させるとよい。両スレイブデバイスが記憶デバイスである特定の実施形態によれば、マスタデバイスは、第１の記憶デバイスに送られるマスタデバイスコマンドによって記憶動作を開始するとよい。少なくとも、マスタデバイスコマンドに対するいかなるレスポンスも、第１の記憶デバイスを介してマスタデバイスに伝送されるという点において、マスタデバイスコマンドは常に第１の記憶デバイスによって「処理される」が、第１の記憶デバイスは、コマンドに一部基づいて、リクエストされた記憶動作をそれ自体に対して実行するか、かつ／または第１の記憶デバイスの命令通りに確立された通信パスを経由してコマンドを第２の記憶デバイスへ送信し、そこでリクエストされた記憶動作を第２のデバイスがそれ自体に対して実行できるかを決定する。さらに、通信パスの確立と、第１および第２のスレイブデバイス間の論理的対話とは、どちらもマスタデバイスのファイルシステムからは隠されているとよい。
【０１３８】
図１３は、本発明の実施形態に従ったコンピューティングシステム２００を示す。システム２００は、ローカル記憶デバイス（ＬＳＤ）２０４という形をとるスレイブデバイスを含む。システム２００は、ホストデバイス（ＨＤ）２０２という形をとるマスタデバイスも含む。ＬＳＤ２０４は、ＨＤ／ＬＳＤインターフェイス２０６を経由してＨＤ２０２と通信するとよい。なお、ＨＤ／ＬＳＤインターフェイス２０６は、ＨＤ２０２およびＬＳＤ２０４が機械的に接続するとよい機械的エンティティ（ソケットまたは相互接続バスなど）として構成可能である。ただし、いくつかの実施形態では、ＨＤ／ＬＳＤインターフェイス２０６は、無線インターフェイスという形をとることができる。ＨＤ２０２は必ずプロセッサを含むが、明瞭にするために、ＨＤ２０２に含まれているプロセッサは、図に示されることも、この説明の中でさらに言及されることもない。しかし、それでもなお存在しているものと想定される。多数の実施形態において、ＬＳＤ２０４は、ＨＤ２０２によって提供される当該インターフェイス以外には、ＨＤ２０２の外部のデバイスに対する何らのインターフェイスも利用しない。言い換えれば、ＬＳＤ２０４は、ＨＤ２０２に排他的に接続可能であり、したがって、ＨＤ２０２による介入なしにコンピューティングシステム２００の外部の回路および／またはアプリケーションにアクセスしたり、または他の形でそれと通信したりすることはできないと考えられる。
【０１３９】
ＨＤ２０２は、ＬＳＤドライバ２１０と通信しているホストデバイスファイルシステム（ＨＤＦＳ）２０８を含む。典型的には、ＨＤＦＳ２０８は、ホストデバイスオペレーティングシステム（ＨＤＯＳ）２１６の一部であり、これは、典型的に、ホストデバイスのメインメモリ（ハードディスクドライブ、すなわちＨＤＤ、ならびにフラッシュメモリなどの不揮発性メモリという形をとり得る）に存在する。記載されている実施形態では、ＨＤＦＳ２０８は、ＬＳＤ管理コマンド２１２をＬＳＤドライバ２１０へ発行するように設定されている。ＬＳＤドライバ２１０は、次に、ＬＳＤ管理コマンド２１２（適切にフォーマットされている）を、ＨＤ／ＬＳＤインターフェイス２０６を経由してＬＳＤ２０４に渡すとよい。例として、ＬＳＤ管理コマンド２１２は、ＬＳＤ２０４が、論理ブロックアドレス（ＬＢＡ）アーキテクチャを有するデータ記憶アレイを含むように設定されている場合に、ブロックコマンドという形をとるとよい。ＨＤ２０２は、（内部）ソフトウェアアプリケーション２１４も含むとよい。内部アプリケーションとは、ソフトウェアアプリケーション２１４が、ＨＤＦＳ２０８およびＬＳＤドライバ２１０を利用してＬＳＤ２０４と通信し得るということである。記載されている実施形態では、ソフトウェアアプリケーション２１４は、ＨＤＦＳ２０８およびＬＳＤドライバ２１０を利用してＬＳＤ２０４と通信するとよく、したがって、ＨＤＦＳ２０８に「認識」される。
【０１４０】
システム２００は、少なくとも第２の記憶デバイスも含む。第２の記憶デバイスは、ローカルまたはリモートのいずれかで、任意の数の位置に存在することができる。一実施形態では、第２の記憶デバイスは、インターフェイス２２３を経由してＨＤ２０２に結合された第２のＬＳＤ２２２という形の外部デバイスである。他の実施形態では、第２の記憶デバイスは、ネットワークインターフェイス２３０にてネットワークリンク２２８を経由してＨＤ２０２と通信している、ネットワーク２２６に含まれるリモートデバイス２２４であるとよい。このようにして、ネットワークリンク２２８を使用するコマンドパスが、リモートデバイス２２４とＨＤ２０２との間に確立されるとよく、この中を情報が通るとよい。さらに他の実施形態では、第２の記憶デバイスは、ＨＤ２０２内に組み込まれた非リムーバブルデバイスとしてもよい。
【０１４１】
記載される実施形態では、ネットワークインターフェイス２３０は、ネットワークリンク２２８を経由したＨＤ２０２とネットワーク２２６との間の通信を促進する。例として、ネットワーク２２６がＩＰプロトコルタイプのネットワークであれば、ネットワークインターフェイス２３０は、例えばアプリケーション２１４と、ネットワーク２２６に含まれる任意のネットワークデバイス、例えばリモートデバイス２２４との間にＩＰプロトコルベースのネットワークリンク２２８を確立するとよい。なお、ネットワークインターフェイス２３０は、適切と判断される任意の場所に物理的に設置されるとよい。例えば、ネットワークインターフェイス２３０は、ＨＤ２０２に組み入れられてもよい。ただし、ネットワークインターフェイス２３０は、ＨＤ２０２（またはシステム２００）に含まれない物理的な位置に設置されるが、それでもＨＤ２０２によってネットワーク２２６との適切なネットワークリンク２２８を確立するために利用されてもよい。したがって、ネットワークインターフェイス２３０は、ＨＤ２０２内に物理的に組み入れられるようにまたはその極めて近くにあるように制限はされない。
【０１４２】
マスタデバイスエージェント１３２は、マスタデバイスエージェント１３２に関して前述した機能に加えて、ＬＳＤ２０４により提供される記憶サービスと、任意の利用可能な外部リソースとの間のブリッジ機能性を少なくとも提供するホストデバイスエージェント２３４という形をとることもできる。記載される実施例では、ホストデバイスエージェント２３４は、適切な任意の手段（ポーリングまたは割り込みなど）によるＬＳＤ論理リクエストを特定するために使用されるとよい。さらに、ホストデバイスエージェント２３４は、外部デバイス２２２またはリモートデバイス２２４などの外部デバイスと、ＬＳＤ２０４との外部デバイスへの通信パス／外部デバイスからの通信パスが確立されると、そのルーティングおよび／または保持を行うように設定されているとよい。
【０１４３】
ＬＳＤ２０４は、コントローラ２３６と、少なくとも第１の大容量記憶領域２４０を有する記憶アレイ２３８とを含む。なお、記憶アレイ２３８は、メモリセル（フラッシュメモリセルなど）のアレイから成るとよい。記載されている実施形態において、記憶アレイ２３８は、フラッシュメモリセルのアレイであると想定されるとよいが、本発明は任意の適切なタイプのメモリセルとともに使用され得ると考えられるため、本発明はフラッシュタイプのメモリセルのみに限定されない。コントローラ２３６には、少なくともホスト／ＬＳＤパラダイム１０６に従って大容量記憶領域２４０を管理するとよいフラッシュマネージャ２４３が含まれている（すなわち、ＨＤＦＳ２０８の命令通りに、かつＨＤＦＳによって発行されるコマンドに従って機能する）。より詳しく言えば、フラッシュマネージャ２４３は、物理的／アレイレベルのフラッシュコマンドを、論理ブロック／セクタレベルのコマンドに変えるとともに、その逆を行うように設定されているとよい。コントローラ２３６は、マッピングモジュール２４５（以下にさらに詳しく記載する）も含み、これは、記載される実施形態ではフラッシュマネージャ２４３の一部であるとよい。特に有用な構成では、記憶アレイ２３８は、ＬＢＡベースの大容量記憶領域を含むとよい。さらに、ＬＢＡベースの大容量記憶領域は大容量記憶領域２４０を含むとよい。こうすることで、大容量記憶領域２４０はレガシー設置基盤に対応するとよい。したがって、大容量記憶領域２４０に格納されるデータのブロックの位置は、論理ブロックアドレッシング（ＬＢＡ）を使用して指定されるとよく、各ブロックは、例えばそれぞれ５１２または１，０２４バイトのオーダであるとよい。こうすることで、大容量記憶領域２４０は、任意の考えられるレガシー大容量記憶装置のアーキテクチャ、より詳しく言えばＬＢＡタイプシステムと完全な下位互換性を持つとよい（すなわち、レガシーホストとともに機能できる）。特に、ＬＳＤ２０４（より詳しくは大容量記憶領域２４０）は、レガシーインターフェイス、バス、およびすべての関連したプロトコルを使用する標準のＬＢＡアーキテクチャのもとで動作するとよく、従来製品の設置基盤との完全な互換性が提供される。
【０１４４】
コントローラ２３６はＬＳＤエージェント２４４も含み、これは、コントローラ２３６の命令通りに、フラッシュマネージャ２４３、特にマッピングモジュール２４５と、外部記憶デバイス２２２またはリモートデバイス２２４との間に、ホストデバイスエージェント２３４を介した通信パス２５６を確立するブリッジとして機能するとよい。なお、この通信パス２５６は、ＨＤＦＳ２０８によってルーティングされず、したがって、ＨＤＦＳ２０８には認識されないと考えられる。なお、様々な実施形態において、ＬＳＤエージェント２４４は、記憶領域２４０に対して様々な記憶動作（例えば、読み込み動作）を実行することもでき、さらに、ファイルシステム構造と、大容量記憶領域２４０内に格納されているデータに関連付けられたメタデータとを理解しているとよい。そのようなファイル構造の理解は、ファイルアロケーションテーブル内のデータを含め、大容量記憶領域２４０内に格納されているファイルメタデータを読み込みトラバースするように、ＬＳＤエージェント２４４を設定することによって実装されるとよい。
【０１４５】
ＬＳＤエージェント２４４は、いくつかの実施形態ではコントローラ２３６の一部とすることもできるネットワークスタック／インターフェイス２４８も管理するとよく、これにより、コントローラ２３６が、標準プロトコル（インターネットプロトコル、すなわちＩＰなど）および任意の利用可能なネットワークリソースを使用して外部デバイスおよび／またはターゲットアプリケーションと通信するためのメカニズムを提供する。特に、ＬＳＤ２０４は、ホストデバイスエージェント２３４が、ＨＤ／ＬＳＤインターフェイス２０６のＬＢＡベースの実施例に適切な形で命令（メッセージフェッチなど）を実行できるようにするために、任意のネットワーク通信（ＬＳＤ論理リクエスト１３０など）を標準フォーマット（物理バスベースのフォーマットなど）に変えるとよい。このようにして、例えば、フェッチされた任意のメッセージを、ホストデバイスエージェント２３４と外部デバイスとの間に作成されたネットワークリンク２２８上で、無事に伝達するとよい。この関連で、ネットワークスタック／インターフェイス２４８を、ＬＳＤエージェント２４４の一部と考えるとよい。ＬＳＤエージェント２４４はさらに、認証およびセキュリティサービスを、コントローラ２３６から実行されるとよいＬＳＤアプリケーション２５０に提供し、さらに、到着する任意のサービスリクエストを管理するとよい。
【０１４６】
当然のことながら、大容量記憶領域２４０は、別々の内部領域に分割されるとよい。この分割された領域はそれぞれ、互いに、さらに／またはＬＳＤ２０４の外部にある回路および／またはソフトウェアアプリケーションと任意の適切な形で対話できるよう作用されるとよい。そのような外部電気回路は、例えば、ＨＤ２０２（その中にホストファイルシステム２０８などのすべてのコンポーネントを含む）、外部ＬＳＤ２２２、またはリモートデバイス２２４などのネットワーク２２６に含まれるいくつかの外部デバイスのいずれかを含むとよい。
【０１４７】
ＨＤＦＳ２０８は、記憶アレイ２３８の大容量記憶領域２４０を効果的に管理するが、フラッシュマネージャ２４３が、ＨＤＦＳ２０８と、物理メモリアレイとの間の変換レイヤとしての機能を果たす。より詳しく言えば、フラッシュマネージャ２４３は、ＨＤＦＳ２０８から受け取られた論理アドレス／ユニット（例えば、クラスタ）をターゲットとするコマンドを、大容量記憶領域２４０内の物理アドレス／ユニット（例えば、ブロック、ページなど）に対して実行されるアクションに変える。記載される実施形態では、ＨＤＦＳ２０８は、フラッシュマネージャ２４３を介して、クラスタと呼ばれる論理エリアの形でデータを格納する。１つ以上のクラスタが、ＬＳＤ２０４によって格納される各ファイルに割り当てられる。当業者には当然のことながら、クラスタは、ファイルに割り当てられるとよいメモリスペースの最小単位であり、したがって、すべてのファイルに、クラスタの整数が割り当てられなくてはならない。なお、さらに、特定のファイルが隣接した複数のクラスタに格納されることは要求されない。実際に、特定のファイルを格納するために使用される複数のクラスタは、物理メモリアレイ中に分散していることが多い。言い換えれば、ファイルはより小さな複数の断片に分割されてから利用可能なメモリアレイ中に格納されることから、ファイルは一般に「断片化」される。クラスタは、従来の大容量記憶システムにおいて、所与のファイルに割り当てられるとよいメモリスペースの最小単位であるが、ファイルシステムによって論理的にアドレス指定可能なメモリアレイの最小記憶セグメントは、セクタと呼ばれる。複数のセクタがクラスタを形成する。従来のシステムでは、各セクタが、５１２バイトまでのデータを格納できる。当業者には当然のことながら、特にフラッシュメモリデバイスは、単一の物理ブロックが繰り返し上書きされると損耗しやすい。したがって、一般に、ＬＳＤドライバ２１０および／またはフラッシュマネージャ２４３が、大容量記憶領域２４０中に平均して均等に書き込み動作を分散させることが望ましい。
【０１４８】
記載される実施形態では、ＨＤＦＳ２０８は、ファイルアロケーションテーブル（ＦＡＴ）２５５を利用して、大容量記憶領域２４０を管理する。しかし、代わりの実施形態では、ＨＤＦＳ２０８は、ＦＡＴベースのファイルシステムでなくてもよい。例として、他の実施形態では、ＨＤＦＳ２０８は、特にｅｘｔ２、ｅｘｔ３、ＮＴＦＳ、およびＪＦＦＳに基づくファイルシステムとしてもよい。したがって、本発明は他のファイルシステムを用いて実施されてもよいが、以下の記載は、ＦＡＴベースのファイルシステムの実施形態に焦点を合わせる。例として、ＦＡＴファイルシステムは、当該技術分野で既知であるＦＡＴ１６またはＦＡＴ３２ファイルシステムとするとよい。ＦＡＴ２５５は、他の任意のデータのように大容量記憶領域２４０に格納されるとよい。ＦＡＴ２５５は、ＬＳＤ２０４によって格納されたファイルの論理位置（単数または複数）を追跡するデータベースと見なされるとよい。ただし、いくつかの実施形態では、ＬＳＤ２０４によって格納されるファイルのすべてを、ＦＡＴ２５５を用いて追跡できるとは限らないことに留意するべきである。すなわち、記憶アレイ２３８に格納される一部のファイルは、ＨＤＦＳ２０８によって管理されないこともあり、ひいては、当該領域に格納されるデータはＨＤＦＳ２０８に認識されないということになる。例として、特定のデータをＨＤＦＳ２０８から隠すことが望ましく、したがって、このデータがＨＤＦＳ２０８によって管理されないメモリアレイ２３８の部分に格納されるとよいこともある。しかし、ＨＤＦＳ２０８によって管理されるファイル（例えば、大容量記憶領域２４０内のもの）に関しては、ＦＡＴ２５５が、各ファイルに付与／割り当てされているセクタの論理アドレスおよびクラスタを追跡する。例として、ＨＤＦＳにより管理されるファイルはそれぞれ、対応するディレクトリエントリまたはメモリアドレスをＦＡＴ２５５内に有する。ＨＤＯＳ２１６またはホストデバイスアプリケーションなどのオペレーティングシステム（ＯＳ）またはソフトウェアアプリケーションは、ＦＡＴ２５５にアクセスして、ファイル内のデータが論理的にどこに位置するかを判断するとよい。特に、ＦＡＴ２５５内の各ファイルエントリは、特定のファイルに割り当てられている対応するクラスタのクラスタ番号を含む。各クラスタエントリは、現在のクラスタを、そのファイルによって使用されている次のクラスタにリンクするクラスタ番号も含む。使用されていない各クラスタは、典型的には、ゼロまたはそのほか何らかの所定値で、ＦＡＴ２５５内の対応するクラスタエントリにおいて示されている。これが、ＯＳまたは他のアプリケーションに、クラスタが空いていて付与可能であることを知らせる。このように、ＦＡＴ２５５は、特定のファイルがどのクラスタに格納されているかとともに、さらにどのクラスタが使用可能であるかをＨＤＦＳ２０２に通知するとよい。このようにして、ＨＤＦＳ２０８は、ＬＳＤ２０４の利用可能な記憶容量および総記憶容量を確認できる。
【０１４９】
本発明の特定の実施形態によれば、ＦＡＴ２５５内で特定されるメモリアドレスはクラスタに関連付けられているとよく、さらにクラスタは、セクタの２つ以上のセットに関連付けられているとよい。例として、ＬＳＤ２０４内の第１の記憶エリア２４０内に物理的に位置するセクタ（以下、実セクタと呼ぶ）に関連付けられた論理アドレスは、論理アドレスの第１のセットＸを表すとよい。特定の一実施形態では、論理アドレスの第１のセットＸは、ＦＡＴ２５５において特定される連続した論理アドレスの固定範囲に対応するとよい。代表的な実施形態では、第１の範囲Ｘ内の論理アドレスはすべて、第１の記憶エリア２４０内に物理的に位置する実セクタに関連付けられる。さらに、ＦＡＴ２５５は例として、外部ＬＳＤ２２２またはリモートデバイス２２４などの外部デバイス内のセットＹなど、ＬＳＤ２２２の外部にあるデバイス内の記憶アレイに物理的に位置するセクタの１つ以上の他のセット（またはいくつかの実施形態では範囲）に関連付けられたクラスタを含むとよい。ＬＳＤ２０４の外部にあるデバイス内のセクタは、仮想セクタと呼ばれるとよい。したがって、この例では、ＨＤＦＳ２０８が利用可能なセクタは、セットＸおよびＹの両方を含む。
【０１５０】
特定の実施形態によれば、ＨＤＦＳ２０８は、ＸとＹとを区別しなくてもよい。すなわち、ＨＤＦＳは、論理アドレスのセットＸおよびＹは、ＬＳＤ２０４の大容量記憶領域２４０内に物理的に位置するセクタにすべて関連付けられていると把握する。より詳しくは、ＦＡＴ２５５内で特定されているクラスタに関連付けられた様々なセクタの物理的位置は、ＦＡＴ２５５を介して得ることはできず、したがってＨＤＦＳ２０８には知られない。その結果、ＨＤＦＳ２０８が見る把握されている記憶容量（以下、仮想記憶容量とも呼ぶ）は、実際には、ＬＳＤ２０４および外部デバイスにそれぞれあるセットＸおよびＹの論理アドレスに関連付けられた実セクタおよび仮想セクタの組み合わせた記憶容量の合計である。したがって、ＬＳＤ記憶領域２４０内に物理的に位置する実セクタの記憶容量は固定されているが、ＦＡＴ２５５を読み込むことによってＨＤＦＳ２０８により判断される、把握される記憶容量は、外部デバイス内に物理的に位置する仮想セクタを含むように効率的に拡張される。
【０１５１】
記載される実施形態では、マッピングモジュール２４５は、特定の論理セクタと、ローカルの実セクタまたは外部の仮想セクタのいずれかとを対応付けるかまたは関連付けするように設定されている。すなわち、マッピングモジュール２４５および／またはフラッシュマネージャ２４３は、特定の論理セクタ番号に関連する実セクタおよび仮想セクタと、大容量記憶領域２４０内または外部デバイスに物理的に存在する記憶領域内の実際の物理アドレス（すなわち、ブロック、ページなど）との関連付けを担当する。したがって、いくつかの特定の実施形態では、クラスタレベルで論理アドレスをターゲットとするＨＤＦＳ２０８から受け取られたコマンドは、論理セクタ番号に変換され、次にマッピングモジュール２４５によって、大容量記憶領域２４０および外部デバイス内の実セクタおよび仮想セクタにそれぞれ関連付けられた物理アドレス／ユニット（すなわち、ブロック、ページなど）に対して実行されるアクションに変換される。一実施形態では、クラスタレベルアドレスからセクタレベルアドレスへの変換は、フラッシュマネージャ２４３によって実行されるとよい。別の実施形態では、この変換はＨＤＦＳ自体によって実行されるとよい。
【０１５２】
なお、様々な好適な実施形態において、マッピングモジュール２４５は、実セクタに格納されるデータ対仮想セクタに格納されるデータの比率を動的に変更できる。特に、特定のファイルに関連付けられたデータ、ならびにそのファイルに関連付けられたメタデータ、さらにＦＡＴ２５５自体の各部分さえも含む特定のコンテンツに対する、実セクタおよび仮想セクタの割り当てを動的に調整することが望ましいこともある。すなわち、例えば、マッピングモジュール２４５の命令通りに、外部デバイス内の１つ以上の仮想セクタから記憶領域２４０内の１つ以上の実セクタにデータが転送されてもよく、その逆が行われてもよい。なお、好適な実施形態では、ＦＡＴ２５５の更新は必要なく、そのためこの再割り当てはＨＤＦＳ２０８には認識されない。
【０１５３】
特定の一実施形態では、マッピングモジュール２４５および／またはＬＳＤエージェント２４４は、ＦＡＴ２５５内で特定されたクラスタと、ＨＤＦＳ２０８に知られていない実セクタおよび／または仮想セクタとを関連付ける別個のマッピングテーブル３５６をさらに保持していてもよい。これは、例として、マッピングモジュール２４５が同じクラスタまたはファイルに属するセクタ内のデータをプリフェッチおよびキャッシュする（すなわち、ＨＤＦＳ２０８からの特定の命令なしに）ように設定されている実施形態など、ある程度の最適化が望ましい実施形態において有益である。
【０１５４】
なお、この場合もやはり、特定の実施形態によれば、ＦＡＴ２５５において特定されているクラスタが実際には大容量記憶領域２４０内の物理アドレスに対応する実セクタならびに外部デバイスに存在する物理アドレスに対応する任意の仮想セクタの両方に論理的に関連付けられている可能性があっても、ＨＤＦＳ２０８は、ＦＡＴ２５５において特定されているすべてのクラスタを、大容量記憶領域２４０内に存在するセクタおよび対応する物理アドレスと関連付けられているものと把握する。さらに、幅広く変化する数の外部記憶デバイスがＨＤ２０２に結合可能であり、それによって、ＨＤＦＳ２０８によって把握されるＬＳＤ２０４の仮想記憶容量の拡張に大きな柔軟性がもたらされることにも注目すべきである。すなわち、対応する外部デバイス内の仮想セクタに関連付けることが可能なファイルアドレスエントリがＦＡＴ２５５内で利用可能である限り、ＬＳＤ２０４の仮想記憶容量は拡張することができる。さらに、ＬＳＤエージェント２４４が、内部ファイルシステムについて理解している（例えば、ファイル構造およびメタデータを理解している）実施形態では、ＬＳＤエージェント２４４は、それ自体のクラスタ／セクタマッピングテーブルを管理するとよい。
【０１５５】
図１４Ａは、ＬＳＤエージェント２４４および／またはマッピングモジュール２４５がクラスタの実セクタおよび仮想セクタへのマッピングを管理するように設定されている特定の実施形態に従ったマッピングテーブル３３５６の図表現を示す。マッピングテーブル３３５６は、マッピングテーブル内で行によって表されるいくつかのクラスタエントリ３３５７を含む。各エントリ３３５７は、いくつかのセクタエントリ３３５８を含む。図１４Ａに示されている例では、特定のクラスタエントリ３３５７は、例えば、大容量記憶領域２４０において互いに物理的に隣接してもしなくてもよいエントリＲＳ１およびＲＳ２によって表される実セクタ、ならびに例えば、同じ外部デバイス内に存在しても存在しなくてもよいエントリＶＳ１およびＶＡ２によって表される仮想セクタの両方と関連付けられているとよい。したがって、エントリ３３５７によって表されるクラスタは、実セクタＲＳ１およびＲＳ２を用いて記憶アレイ２４０内ならびにセクタＶＳ１およびＶＳ２を用いて１つ以上の外部デバイスに存在する記憶エリア内の両方に格納されたデータを含む。すなわち、図に示されている実施形態では、特定のクラスタに関連するセクタのすべてが、実セクタを用いて完全にローカルに格納されることも、または仮想セクタを用いて完全に外部に格納されることも要求されない。
【０１５６】
図１４Ｂは、所与の範囲（例えば、００００〜ｘｘｘｘ）のすべての論理アドレスが実セクタに関連付けられ、所与の範囲（例えば、ｙｙｙｙ〜ＦＦＦＦ）のすべての論理アドレスが仮想セクタに関連付けられている実施形態におけるＨＤＦＳ２０８によって読み込まれるＬＳＤ２０４の把握される記憶容量の表現を示す。より詳しくは、図１４Ｂは、１６進法の表記法でのメモリアドレスと、メモリアドレスに関連付けられた物理セクタとの間の関係を示す。なお、この関係は、特定の一実施形態のみを表し、様々な代わりの実施形態などのように、所与の論理アドレスと関連したクラスタ（単数または複数）との間の関係、ならびに所与のクラスタと対応するセクタとの間の関係は、どちらも動的に変更され得る。ボックス３３６０全体が、把握されるＬＳＤ２０４の記憶容量を表す。図に示されている実施形態では、ボックス３３６０の上部３３６２が、例えばＦＡＴ１６アドレッシングの場合、００００で始まり値ｘｘｘｘで終わるメモリアドレスを表し、これは記憶アレイ２４０の実際の記憶容量、すなわち記憶アレイ２４０内に位置するＲＳ１およびＲＳ２などの実セクタに関連付けられている。反対に、ボックス３３６０の下部３３６４は、ＦＡＴ１６アドレッシングの場合ｙｙｙｙ（ｘｘｘｘまたはｘｘｘｘの後）で始まりＦＦＦＦで終わるメモリアドレスを表し、これは、ＬＳＤ２０４の仮想記憶容量、すなわちＶＳ１およびＶＳ２などの外部デバイスに存在するクラスタに関連付けられている。
【０１５７】
本発明の少数の特定の実施形態を説明するために、図１５のフローチャートおよび図１６のシステムを参照して、ＨＤ３５０２からＬＳＤ３５０４へ送られる管理コマンドのＬＳＤ３５０４による処理のプロセス３４００について記載する。プロセス３４００は、３４０２にて、ＨＤＦＳ３５０８が、ＦＡＴ３５５５にアクセスすることで開始するとよい。これによって、ＨＤＦＳ３５０８は、ＨＤＦＳが実際にＬＳＤ３５０４によって記憶アレイ３５３８内に格納されていると想定しているデータの対応付けを確認して、後の記憶動作のために論理アドレスを特定することができる。ただし、場合によっては、ＦＡＴ３５５５は、ＨＤ３５０２内のローカルメモリ内に既にキャッシュされていることもあり、論理アドレスおよび対応するクラスタが既に特定されていることもある。前者の場合、いくつかの実施形態では、フラッシュマネージャ３５４３および／またはマッピングモジュール３５４５は、アクセス３４０２の間にＨＤＦＳ３５０８がどの論理アドレス（単数または複数）を対象としていたかを判断するとよい。特に、こうした実施形態では、マッピングモジュール３５４５は、ＨＤＦＳ３５０８がどのセクタに対して記憶動作を意図しているかを認識することができ、その結果、ＨＤＦＳ３５０８からの後からのコマンドによってどのセクタがターゲットとされるかを予想することができる。
【０１５８】
３４０４にて、フラッシュマネージャ３５４３は、所望の記憶動作をリクエストする管理コマンド３５１２をＨＤＦＳ３５０８から受け取る。例として、管理コマンド３５１２は、読み込み、書き込み、または消去コマンド、および記憶動作が実行されるべき関連した論理アドレス、さらに書き込みコマンドの場合は論理アドレスに書き込まれるデータを含むとよい。いくつかの実施形態では、このコマンドが予測されるとよい（例えば、従来技術で既知である何らかのインテリジェントプリフェッチメカニズムに基づく）。３４０６にて、フラッシュマネージャ３５４３は、論理セクタ番号と、関連した実セクタおよび仮想セクタとの間のマッピングを管理／保持するマッピングモジュール３５４５に問い合わせを行う。３４０８にて、マッピングモジュール３５４５は、ＨＤＦＳ３５０８によって送られたコマンドに関連する論理アドレスの一部または全部が、ＬＳＤ３５０４の外部にあるデバイス３５２２（例えば、第２のＬＳＤ、リモートネットワークデバイス、またはＨＤ内に組み込まれた非リムーバブルデバイス）に物理的に存在するセクタを指す仮想セクタ（例えば、仮想セクタＶＳ１またはＶＳ２）に関連付けられているかどうかを判断する。好適な実施形態では、マッピングモジュール３５４５によってとられるアクションはＨＤＦＳ３５０８とは独立し、ＨＤＦＳ３５０８にはトランスペアレントである。このように、ＨＤＦＳ３５０８またはＬＳＤドライバ３５１０などのレガシーコンポーネントに対する更新またはそのほかの変更は必要ない。３４０８にて、セクタがすべて、記憶アレイ３５３８の大容量記憶領域３５４０に物理的に存在する実セクタ（例えば、実セクタＲＳ１またはＲＳ２）であると判断されれば、フラッシュマネージャ３５４３は３４１０にて、コマンド３５１２を処理するとよい。より詳しくは、マッピングモジュール３５４５が、管理コマンド３５１２は完全に実セクタに関連付けられていると判断すれば、３４１０にて、リクエストされた記憶動作が、ターゲットとされたこの実セクタに対してリアルタイムで実行されるとよい。コマンド３５１２の処理は、一般に、ＬＳＤ３５０４からＨＤＦＳ３５０８にレスポンスを伝送することも含む。レスポンスは、リクエストされた動作が実行されたという肯定応答および／またはリクエストされた動作に関連したデータを含むとよい。
【０１５９】
一方、３４０８にて、マッピングモジュール３５４５が、管理コマンド３５１２に関連したセクタの少なくとも一部が仮想セクタであると判断すれば、３４１２にてＬＳＤエージェント３５４４は、ＬＳＤ３５０４と、仮想セクタ（例えば、ＶＳ１およびＶＳ２）の物理的位置を含む関連した記憶アレイを有する外部デバイス３５２２との間に通信パスが確立されているかどうかを判断する。通信パスとは、ＨＤ３５０２を介して、ＬＳＤ３５０４と外部デバイス３５２２との間に有効なコマンドパスが確立されているということである。有効とは、ＬＳＤエージェント３５４４、ホストデバイスエージェント３５３４、およびインターフェイス３５３０を介して、ＬＳＤ３５０４と外部デバイス３５２２との間に物理的接続が確立されているということ、無線接続が確立されているということ、または論理接続が確立されているということであり、それを介して情報が渡されるとよく、さらに好適な実施形態では、これはＨＤＦＳ３５０８には知られない。
【０１６０】
図に示されている実施形態では、３４１２にて、ＬＳＤ３５０４と外部デバイス３５２２との間に通信パス３５５６が確立されていると判断されれば、ＬＳＤエージェント３５４４は３４１４にて、管理コマンド３５１２に基づく管理コマンド３５１３を外部デバイス３５２２へ送信し、このコマンドが外部デバイス３５２２に、いくつかの仮想セクタに対してリクエストされた記憶動作を実行するように命令する。いくつかの実施形態では、前述したように、通信パス３５５６の確立は、実際にＨＤＦＳ３５０８から管理コマンド３５１２を受け取る前に、予測される管理コマンドに基づいて開始されるとよい。並行して、記憶領域３５４０に対して何らかのローカルキャッシュ管理動作があってもよい。いくつかの実施形態では、ローカルキャッシュ３５５８は記憶領域３５４０の一部であってもよく、他の実施形態では、キャッシュは記憶アレイ３５３８の外のＲＡＭ内に位置してもよい。ローカルキャッシュ３５５８の管理は、ローカルに格納されるデータ（例えば、書き込み動作の場合はＨＤ３５０２から外部デバイス３５２２に書き込まれるデータ、または読み込み動作の場合はＨＤＦＳ３５０８に伝送される外部デバイス３５２２からＬＳＤエージェント３５４４によってフェッチされたデータ）に十分な記憶空間がキャッシュ３５５８にあることを最も適切な形で保証するために、フラッシュマネージャ３５４３（および／またはマッピングモジュール３５４５）とＬＳＤエージェント３５４４との協働を必要とすることもある。キャッシュ３５５８からローカルデータを消去すること、書き込まれるローカルデータをローカルキャッシュ３５５８から外部デバイス３５２２に転送すること、またはローカルキャッシュ３５５８から読み込まれＨＤ３５０２に転送されるローカルデータを転送することによって、十分な記憶空間が空けられてもよい。
【０１６１】
いくつかの実施形態では、ＬＳＤエージェント３５４４がファイルシステム構造について何らかの理解を有し、それによってＬＳＤエージェント３５４４がキャッシュ管理にある程度の最適化をもたらすことができることもあるため、ＬＳＤエージェント３５４４がキャッシュ管理動作に関与してもよい。特に、例えばＬＳＤエージェント３５４４が、所与のファイルに関係するクラスタのフェッチすべき残りのセクタを理解していれば、ＬＳＤエージェント３５４４は、ＬＳＤ内のローカルキャッシュ３５５８に十分な記憶場所があることを前もって確認するとよい。さらに、ファイルシステム構造の理解によって、ＬＳＤエージェント３５４４は、キャッシュ３５５８に格納されている、ローカルに保持することが望ましい現在のコンテンツを特定することができるようになると考えられる。したがって、ＬＳＤエージェント３５４４は、ある程度のインテリジェントキャッシングを実行するとよい。
【０１６２】
３４１８にて、外部デバイス３５２２は、管理コマンド３５１３に応答して（かつ間接的に管理コマンド３５１２を介して）、リクエストされた記憶動作を仮想セクタに対して実行する。なお、外部デバイス３５２２に送られる第２のコマンド３５１３は、必ずしも、第１のコマンド３５１２において特定された論理アドレスに関連付けられている仮想セクタに対して記憶動作を実行するように外部デバイスに命令するとは限らなくてもよい。すなわち、場合によっては、管理コマンド３５１２において特定される論理アドレスがすべて実セクタと関連付けられていても、第１の管理コマンド３５１２に関連付けられていない大容量記憶領域３５４０内の実セクタからのデータを外部デバイス３５２２内の仮想セクタに書き込むことによって大容量記憶領域３５４０内の記憶スペースを解放することが望ましいこともある。したがって、第２のコマンド３５１３は、大容量記憶領域３５４０内の実セクタからのデータを含み、実セクタからのデータを外部デバイス内の仮想セクタに書き込むよう外部デバイス３５２２に命令する書き込みコマンドであってもよい。さらに、ＨＤＦＳ３５０８によって送られる管理コマンド３５１２が、実セクタおよび仮想セクタの両方に関連付けられたアドレスを含んでいる場合、フラッシュマネージャ３５４３は、３４１０にて、外部デバイス３５２２に管理コマンド３５１３を送信するのと並行して、および／または外部デバイス３５２２によってリクエストされた記憶動作が仮想セクタに対して実行されるのと並行して、リクエストされた記憶動作を実セクタに対して実行するとよい。
【０１６３】
あるいは、特定の実施形態によれば、３４１２にて通信パス３５５６が存在しないと判断されれば、３４１６にてＬＳＤエージェント３５４４が、ＬＳＤ３５０４と外部デバイス３５２２との間に通信パス３５５６を確立するように、ＨＤエージェント３５３４を経由してＨＤ３５０２に指示する。特に、図１３の通信パス２５６を参照して前に説明したように、例えばＬＳＤ３５０４は、リクエストされたプロセスを実行してネットワークインターフェイスまたはローカル通信パスを使用して外部デバイス３５２２への通信パス３５５６を確立するように、ＨＤ３５０２に指示してもよい。しかし、確立されると、ＨＤ３５０２によるそれ以上の介入なしに（データパケットルーティングなど、データを渡すことに関係する任意の介入を除いて）、かつＨＤＦＳ３５０８には認識されずに、ＬＳＤ３５０４と外部デバイス３５２２との間で情報が渡されるとよい。通信パス３５５６が確立されると、プロセスは３４１４に進み、そこで管理コマンド３５１３が外部デバイス３５２２へ送られ、この時点で、外部デバイス３５２２が、リクエストされた記憶動作を仮想セクタに対して実行するとよい。
【０１６４】
したがって、様々な実施形態において、ＨＤＦＳ３５０８によって開始される単一のコマンド３５１２の処理は、概して、ＬＳＤ３５０４内部の動作ならびに外部デバイス３５２２に関係する動作の両方をいくつか含み得る。前述したプロセス３４００は、本発明の様々な実施形態の概略的な実施例を表すが、以下の記載は、本発明の特定の実施形態のさらに具体的な実施例を提供する。
【０１６５】
より詳しくは、管理コマンド３５１２が書き込みコマンドである場合、その書き込みコマンド３５１２において特定されている論理アドレスのいずれかが記憶領域３５４０に存在する実セクタに関連付けられていれば、データは、前述したように、３４１０にて、ターゲットとされている実セクタにリアルタイムで書き込まれるとよい。次に、書き込みコマンドが処理されたという肯定応答を含むレスポンスが、ＨＤＦＳ３５０８に送られるとよい。一方、論理アドレスの一部または全部が仮想セクタに関連付けられていれば、ＬＳＤエージェント３５４４は、前述したように、ＨＤＦＳ３５０８に知られずに、書き込みコマンド３５１３および関連したデータを通信パス３５５６に沿って外部デバイス３５２２に送信し、外部デバイス３５２２に存在する仮想セクタの、関連のある物理的対応部分に、関連したデータを書き込むように外部デバイス３５２２に命令する。
【０１６６】
あるいは、データおよび書き込みコマンド３５１３を外部デバイス３５２２に送る前に待機することが望ましいこともある。例として、特定の所定の条件が満たされるまで、ＬＳＤ３５０４内のキャッシュ３５５８内にデータを一時的に格納すると有利であることもある。例として、通信パス３５５６上で所定レベルの帯域幅が利用可能になるまで、データをキャッシュ３５５８に一時的に格納して、そのキャッシュされたデータの外部デバイス３５２２への送信を待つことが望ましいこともある。さらに、所定量のデータがキャッシュされるまで待ってから外部デバイス３５２２にデータを送り、それからそこにデータが書き込まれると、より効率的であることもある。こうした検討事項およびそのほかの検討事項のために、書き込みコマンド３５１２の処理は、まずデータを一時的にキャッシュして、書き込みコマンドが処理されたという肯定応答を含むレスポンスをＨＤＦＳ３５０８に送ることを含むとよい（しかし、他の実施形態では、肯定応答レスポンスは、ＨＤＦＳが要求する時間的制約の範囲内で肯定応答が送られさえすれば、後で送られてもよい）。その結果、処理には、書き込みコマンド３５１２に関連する仮想セクタに書き込まれるべきデータ（またはコマンド３５１３自体さえも）が、現在のクロックウィンドウ中に外部デバイス３５２２へ送信されるべきか否かについて判断することが含まれるとよい。この判断と同時か、その前または後に、フラッシュマネージャ３５４３によって実セクタに書き込まれるべき他のデータ部分が、３４１０にて書き込まれるとよい。データが、現在のクロックウィンドウ中に送信されるべきであれば、そのデータが送信され、次にデータは外部デバイス３５２２内の仮想セクタに書き込まれる。いくつかの実施形態では、データの送信は徐々に実行されるとよい。すなわち、データの様々な「まとまり」または部分が、可能なときかまたは他の形で適切と判断されたときに送信されるとよい。現在のクロックウィンドウ中にデータが外部デバイス３５２２へ送信されない場合には、データはキャッシュ３５５８に格納され、コントローラ３５３６は、書き込みのためにデータが外部デバイス３５２２へ送信されるべきであると判断するまで、そこにとどまるとよい。
【０１６７】
なお、特定の実施形態では、仮想セクタを行先とするデータ部分がキャッシュされても、ＦＡＴ３５５５に変更が加えられる必要はない。さらに、一実施形態では、ＨＤＦＳ３５０８によってアクセスされるＦＡＴ３５５５に変更を加える必要がないように、フラッシュマネージャ３５４３および／またはマッピングモジュール３５４５は、仮想セクタ位置（単数または複数）を一時キャッシュ位置（単数または複数）に対応付けるとよい。実際には、ＦＡＴ３５５５において特定されているクラスタに関連付けられた実セクタおよび仮想セクタは両方とも、一般に、必ずしも記憶領域３５４０内または外部デバイス内の同じ物理セクタに対応するとは限らないと考えられる。
【０１６８】
管理コマンド３５１２が読み込みコマンドである場合、読み込みコマンド３５１２において特定されている論理アドレスのいずれかが、記憶領域３５４０に存在する実セクタに関連付けられていれば、データは３４１０にて実セクタから読み込まれ、続いてＨＤＦＳ３５０８へ伝送されるとよい。一方、論理アドレスの一部または全部が仮想セクタに関連付けられていれば、ＬＳＤエージェント３５４４は３４１４にて、前述したように、ＨＤＦＳ３５０８に知られずに、読み込みコマンド３５１３を通信パス３５５６に沿って外部デバイス３５２２に送信し、外部デバイス３５２２に存在する仮想セクタの関連のある物理的対応部分から読み込みを行うように外部デバイス３５２２に命令する。外部デバイス３５２２から読み込まれたデータは、次に、通信パス３５５６に沿ってＬＳＤ３５０４に送信されるとよく、そこで次に、データは一時的にキャッシュ３５５８にローカルに格納されてから、記憶領域３５４０から直接読み込まれたかのようにＨＤＦＳ３５０８へ送信されるとよい。
【０１６９】
なお、ＬＳＤ３５０４とＨＤ３５０２との間、特にフラッシュマネージャ３５４３とＨＤＦＳ３５０８との間のデータの管理および転送は、通常、タイムアウトなどを含むいくつかの制限を受ける（すなわち、例えばＳＤ、ＭＭＣなどのレガシー記憶バスでは、ＨＤは、ＬＳＤからのレスポンスを限られた期間（例えば、最大１００ｍｓ）内に受け取ることを要求し、その期間が過ぎるとそのリクエストが失敗したと見なされ、その結果システムが再設定されることになる場合もある・・）。したがって、従来のレガシーホストデバイス、記憶デバイスおよびバスは、データの通信および転送管理を、「保証されたレスポンスタイム」に基づいて行うが、ＬＳＤ３５０４（特に、ＬＳＤエージェント３５４４）と外部デバイス３５２２との間のデータの通信および転送は「ベストエフォート」に基づいていてもよい。
【０１７０】
特定の実施形態によれば、インテリジェントマッピングおよび／またはキャッシングの使用によって、この問題が軽減されるとよい。特に、フラッシュマネージャ３５４３および／またはマッピングモジュール３５４５は、実セクタ／仮想セクタマッピングを動的に管理するとよい。例として、フラッシュマネージャ３５４３および／またはマッピングモジュール３５４５は、どのファイルが最も多く使用されているかに注目し、その結果として、確実に、最も多く使用されているファイルが実セクタに格納され、最も使用されていないファイルが外部デバイスの仮想セクタに格納されるように、セクタの実割り当ておよび仮想割り当てを動的に変更するとよい（ＨＤＦＳ３５０８にトランスペアレントに、さらに場合によりバックグランド動作として）。すなわち、仮想セクタに格納されている特定のファイルの使用が多ければ（例えば、頻繁に読み込まれる）、マッピングモジュール３５４５およびフラッシュマネージャ３５４３は、その非常によく使われているファイルに関連したデータの、外部デバイス３５２２内の仮想セクタから記憶領域３５４０を用いる実セクタへの転送を、動的に開始するとよい。あるいは、非常によく読み込まれているデータが、先行して（かつ少なくとも一時的に）キャッシュ３５５８内に格納されてもよい。反対に、まれにアクセスされるファイルに関連したデータは、記憶領域３５４０内の実セクタから外部デバイス３５２２内の仮想セクタへ、マッピングモジュール３５４５および／またはフラッシュマネージャ３５４３の命令通りに動的に転送されるとよい。
【０１７１】
さらに、いくつかの実施形態において、ＬＳＤドライバまたはＨＤＦＳ３５０８は、さらなる柔軟性がサポートされていればそのような柔軟性を可能にするように設定されているとよい。例として、記憶動作が、記憶装置インターフェイス標準によって定義された「保証されたレスポンスタイム」内に実行されないと考えられれば（例えば、外部デバイス３５２２が別のＬＳＤであり、通信が高速な場合）再試行メッセージが送られるとよい。さらに、制限時間の制約下でのＬＳＤ３５０４と外部デバイス３５２２との間のデータの処理および転送を可能にするために、サービス品質（ＱＯＳ）パラダイムが設定されてもよい。例として、ＱＯＳパラダイムは多数ある中でも、利用可能な帯域幅、転送されるデータの量、および既にキャッシュされたデータの量などの要素を含むとよい。
【０１７２】
本願発明者らは、ローカル記憶デバイス（ＬＳＤ）において、ホストデバイス（ＨＤ）の関与なしにＬＳＤのメモリアレイ内のデータにインデックスを付ける機能性を提供することが望ましいということに気づいた。したがって、例えばＬＳＤのデータは、ＬＳＤが複数のＨＤによって使用されている場合でもインデックス付けされるとよい。さらに、監視および特徴付け機能性がＨＤプラットフォームから独立していることから、この機能性が様々なＨＤプラットフォームに移植される必要はない。インデックス付けは、ＬＳＤのデータに関する検索クエリに応答するために使用可能なデータの集合を生成することを含むとよい。クエリは、ＨＤからまたはＬＳＤ内から生じ得る。
【０１７３】
インデックス付けの結果の使用は、検索クエリへの応答に限定されない。例えばインデックス付け結果は、コンテンツの選別、すなわち、ＬＳＤのメモリアレイにある不正コンテンツへのアクセスを禁止するために、「ポルノ」のような特定のストリングを探すアプリケーションに使用されてもよい。コンテンツの選別は、例えばＨＤにおいて実行されてもよく（例えば、ＬＳＤのメモリアレイ内の特定コンテンツへのアクセスリクエストを回避することにつながる）、または別の例として、ＬＳＤ自体において実行されて、書き込みアクセスリクエストでも読み込みアクセスリクエストでも、ＨＤから受け取られるアクセスリクエストがブロックされてもよい。
【０１７４】
記憶デバイスコントローラの能力が向上し、記憶デバイスコントローラによって利用可能にされる処理リソースを使用して記憶デバイス内からソフトウェアアプリケーションを実行することが可能になる。このような記憶デバイスコントローラの運用性の強化により、例えばホストデバイスの関与なしに記憶デバイス上のデータにインデックスを付けるのに有用な、新たなインデックス付けモードのパラダイムがもたらされる。このようなインデックス付けは、例えば主として、接続もしくは未接続の複数のデバイスにまで広がったり、有線対無線、固定対モバイルなどの複数アクセスモードにまで広がったりしている、ユーザのデジタルコンテンツ消費体験を改善するために使用することができる。
【０１７５】
インデックスは、例えば、サービスプロバイダに公開されても、提供されても、またはサービスプロバイダによってアクセス可能であってもよく、サービスプロバイダはその代わりに改善された検索またはそのほかの使用能力をユーザに提供する。例えば、記憶デバイスは、予めロードされたコンテンツを含むとよく、さらにユーザは、コンテンツをダウンロードする（小売業者に関連したウェブサイトからなど）ように勧められるとよい。代わりにユーザは、記憶デバイスからのインデックス提供を承諾してもよく、さらに、例えば場合により、小売業者および／または関連したエンティティから焦点を合わせた提案を受けることさえもある。別の例として、記憶デバイスのベンダが、ターゲットを絞ったサービスをその顧客基盤に提供できるようにしてもよい。
【０１７６】
本発明は、「ユーザ中心」（従来の「デバイス中心」とは対照的）インデックス付け手法に対するサポートを提供するために、ホストにより管理される、ＬＢＡベースの（「ＬＢＡ」は論理ブロックアドレッシングの省略形）大容量記憶パラダイムの厳しい制限を越えて、レガシー大容量記憶デバイスと完全な下位互換性を持つことができるが、さらに大容量記憶装置のインデックス付けを改善し、その結果デジタルコンテンツの読み出し／検索の使用を改善するインデックス付けパラダイムを提供する。さらに、このようにして生成されたインデックスのレポートは、ホストデバイスにおけるインデックス付け機能性に依存する必要はない。
【０１７７】
図１７は、ホストデバイス（ＨＤ）４１０２およびローカル記憶デバイス（ＬＳＤ）４１０４を含むコンピューティングシステム４１００を示す。ＨＤ４１０２は、ホストデバイスファイルシステム（ＨＤＦＳ）４１０６を含む。ＬＳＤ４１０４は、比較的小さな形態的要素を有するメモリカードなどのリムーバブルメモリデバイスという形をとることができ、カメラ、ハンドヘルドまたはノートブック形コンピュータ、ネットワークカード、ネットワークアプライアンス、セットトップボックス、ハンドヘルドまたはそのほか小形オーディオプレーヤ／レコーダ（例えば、ＭＰ３デバイス）、および医療用モニタなどの電子製品のデジタルデータを格納するために使用可能である。メモリカードの例には、ＰＣカード（以前はＰＣＭＣＩＡデバイス）、フラッシュカード（例えば、コンパクトフラッシュタイプＩおよびＩＩ）、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ＡＴＡカード（例えば、コンパクトフラッシュカード）、メモリスティック、ＳｍａｒｔＭｅｄｉａカードがある。さらに、ＬＳＤ４１０４は、カリフォルニア州ミルピタスのサンディスク  コーポレイションによって製造されたＳＤ対応のｉＮＡＮＤ（登録商標）を組み込んだフラッシュドライブなどの非リムーバブルメモリデバイスという形をとることができる。
【０１７８】
ＬＳＤ４１０４は、ＨＤ／ＬＳＤインターフェイス４１１２を経由してＨＤ４１０２と通信することができる。なお、ＨＤ／ＬＳＤ４１１２は、ＨＤ４１０２およびＬＳＤ４１０４が機械的に接続することができる機械的エンティティ（ソケットまたは相互接続バスなど）として構成可能である。いくつかの実施形態では、ＨＤ／ＬＳＤインターフェイス４１１２は、無線インターフェイスという形をとることができる。一般に、ＨＤ４１０２はプロセッサを含む。ただし、明瞭にするために、ＨＤ４１０２に含まれているプロセッサは、図に示されることも、この説明の中でさらに言及されることもないが、それでもなお存在しているものと想定される。ＬＳＤ４１０４は、物理的に、ＨＤ４１０２に排他的に接続可能であり、したがって、ＨＤ４１０２による介入なしにコンピューティングシステム４１００の外部の回路および／またはアプリケーションにアクセスしたり、あるいは他の形でそれと通信したりすることはない。典型的には、ＬＳＤ４１０４は、ＨＤ４１０２によって提供される当該インターフェイス以外には、ＨＤ４１０２の外部のデバイスに対する何らのインターフェイスも利用しないが、場合によっては、ＬＳＤ４１０４は、ＨＤ４１０２の外部のデバイスに直接インターフェイスで接続することもある。
【０１７９】
ＨＤ４１０２は、ＬＳＤドライバ４１０８と通信しているホストデバイスファイルシステム（ＨＤＦＳ）４１０６を含む。記載されている実施形態では、ＨＤＦＳ４１０６は、ＬＳＤ管理コマンド４１１０をＬＳＤドライバ４１０８へ発行することができる。ＬＳＤドライバ４１０８は、次に、ＬＳＤ管理コマンド４１１０（適切にフォーマットされている）を、ＨＤ／ＬＳＤインターフェイス４１１２を経由してＬＳＤ４１０４に渡すことができる。例えば、ＬＳＤ管理コマンド４１１０は、ＬＳＤ４１０４が、論理ブロックアドレス（ＬＢＡ）アーキテクチャのデータ記憶アレイを含むように設定されている場合、ブロックコマンドという形をとることができる。ＬＳＤ管理コマンド４１１０は、ＬＳＤ４１０４とＨＤ４１０２との間のデータ４１１１のフローをもたらす。
【０１８０】
ＨＤ４１０２は、（内部）ソフトウェアアプリケーション４１１４も含むことができる。内部アプリケーションとは、ソフトウェアアプリケーション４１１４が、ＨＤＦＳ４１０６（典型的にはホストデバイスオペレーティングシステム４１１６の一部）およびＬＳＤドライバ４１０８を利用してＬＳＤ４１０４と通信できるということである。そのようなソフトウェアアプリケーションは、アプリケーション４１１８を含むことができ、それぞれ、典型的に、ホストデバイスのメインメモリ（ハードディスクドライブ、すなわちＨＤＤならびにフラッシュメモリなどの不揮発性メモリという形をとることができる）に存在する。
【０１８１】
例えば、コンピューティングシステム４１００は携帯メディアプレーヤとすることができ、アプリケーション４１１８はメディアプレーヤアプリケーションとしてもよい。この場合、例えばＬＳＤ４１０４は、ＭＰ３形式のオーディオファイル、ＭＰ４形式のビデオ／オーディオファイル、またはＪＰＥＧ形式の静止写真ファイルなどの様々なデジタルメディアファイルを格納するとよい。ＬＳＤ管理コマンド４１１０は、例えば、ファイルのデータをＬＳＤ４１０４から読み出すデータアクセスコマンドとしてもよい。
【０１８２】
図１７の例では、データアクセスコマンドは、ＬＳＤ４１０４の大容量記憶エリア４１２０に格納されたファイルアロケーションテーブル（ＦＡＴ）の一部を読み込み、続いて大容量記憶エリア４１２０から１つ以上のデータブロックを読み込むＨＤＦＳコマンドであるとよい。例えば、大容量記憶エリア４１２０は、メモリアレイであるとよく、大容量記憶エリアは、ＬＳＤ４１０４のローカルのファイルシステムによってではなくＨＤＦＳ４１０６によって管理されるとよい。例えば、ＬＳＤ４１０４は、コントローラ４１２２と、第１の記憶エリア４１２４および第２の記憶エリア４１２６を有する大容量記憶アレイ４１２０とを含むことができる。なお、記憶アレイ４１２０は、メモリセル（フラッシュメモリセルなど）のアレイから形成可能である。この特定の場合では、大容量記憶アレイ４１２０を、フラッシュメモリセルのアレイと想定することができるが、本発明は、任意の適切なタイプのメモリセルとともに使用可能であると考えられるため、本発明はフラッシュタイプのメモリセルのみに限定されない。
【０１８３】
コントローラ４１２２は、ＨＤＦＳ４１０６の命令通りに機能して第１の記憶エリア４１２４を管理できるフラッシュマネージャ４１２８を含む。特に有用な構成では、第１の記憶エリア４１２４は、ＬＢＡベースの大容量記憶アレイとすることができる。したがって、第１の記憶エリア４１２４に格納されるデータのブロックの位置は、論理ブロックアドレッシング（ＬＢＡ）を使用して指定することができ、各ブロックは、例えばそれぞれ５１２または１，０２４バイトのオーダとすることができる。こうすることで、第１の記憶エリア４１２４は、任意の考えられるレガシー大容量記憶装置のアーキテクチャ、より詳しく言えばＬＢＡタイプのシステムと完全な下位互換性を持つことができる（すなわち、レガシーホストとともに機能できる）。特に、ＬＳＤ４１０４（特に、第１の記憶エリア４１２４）は、レガシーインターフェイス、バス、およびすべての関連したプロトコルを使用する標準のＬＢＡアーキテクチャのもとで動作することができ、レガシー製品の設置基盤との完全な互換性が提供される。
【０１８４】
コントローラ４１２２は、ホストデバイス４１０２の関与なしにＬＳＤ４１０４の第１の記憶エリア４１２４内に格納されているデータにインデックス付けするように設定されたインデクサ４１３０をさらに含む。一例では、インデクサ４１３０は、ＨＤ４１０２によってデータが第１の記憶エリア４１２４に格納されるときおよび／または第１の記憶エリア４１２４から読み込まれるときに、データにインデックスを付ける。したがって、例えば、インデクサ４１３０は、第１の記憶エリア４１２４とＨＤ４１０２との間で転送されるデータコンテンツを認識するとよく、それに基づいて第１の記憶エリア４１２４内のデータにインデックスを付ける。監視およびインデックス付けは、ＬＳＤ４１０４によって行われ、結果は「インデックスデータ」として大容量記憶アレイ４１２０の第２の記憶エリア４１２６に格納される。もう１つの例として、インデクサ４１３０は、第１の記憶エリア４１２４にアクセスするためにホストデバイス４１０２によって使用されるコマンドに基づき、インデックスデータを生成してもよい。さらにもう１つの例として、インデクサ４１３０は、ホストデバイス４１０２の関与なしに、第１の記憶エリア４１２４内のデータにアクセスして、第１の記憶エリア４１２４内のデータに関してインデックスデータを生成してもよい。
【０１８５】
図１８は、ＨＤ４１０２によるＬＳＤ４１０４へのデータアクセス動作の確認に基づき、どのようにデータのインデックス付けが生じ得るかの例をさらに詳しく示している。この確認には、ＨＤ４１０２は関与しない。図１８を参照する。コマンド４１１０が、ＨＤ４１０２からＬＳＤ４１０４へ、ＨＤ／ＬＳＤインターフェイス４１１２を介して提供される。前述したように、第１の記憶エリア４１２４を管理するために、コマンド４１１０は、ＨＤＦＳ４１０６の命令通りに機能する、コントローラ４１２２のフラッシュマネージャ４１２８に提供される。インデクサ４１３０は、コマンド４１１０を確認し、第１の記憶エリア４１２４に格納されるか、またはそこから読み込まれるのを確認されたデータ４１１１とともにこのコマンド４１１０に基づいて、第１の記憶エリア４１２４内のデータにインデックスを付ける。コマンド４１１０は、データアクセスを特徴付けるために使用されて、インデックス付け機能性に情報が与えられるとよい。インデックス情報が提供され、記憶アレイ４１２０の第２の記憶エリア４１２６に格納される。
【０１８６】
コマンド４１１０は、ＨＤＦＳ４１０６の命令通りに機能する、コントローラのフラッシュマネージャ４１２８に提供されるように図に示されているが、他の例では、ＨＤＦＳ動作の結果としてではないコマンドまたは他の信号が、ＨＤ４１０２からＬＳＤ４１０４へ提供される。例えば、そのようなコマンドまたは他の信号は、ＨＤＦＳ動作の結果としてではないドライバレベルの動作など、他の動作に基づいて提供され得る。
【０１８７】
データアクセスの特徴付けは、例えば、ビデオ、音楽、または写真であるとインデックス付けされるデータ間の区別に役立つこともあり、これはインデックス付け機能性に情報を与えることができる。したがって、記憶アレイ４１２０の第２の記憶エリア４１２６に格納されるように提供されるインデックス情報は、判断されたデータアクセスの特徴付けそのままであっても、または判断されたデータアクセスの特徴付けをさらに処理した結果であっても、インデクサ４１３０によるデータアクセスの特徴付けに少なくとも部分的に基づいているとよい。
【０１８８】
例えば、データブロック読み込みコマンドである単一データ読み込みコマンドを、コマンド４１１０としてＨＤ４１０２が提供することがインデクサ４１３０によって認識され、関連するデータ読み込みコマンドがそれ以上なければ、インデクサ４１３０は、ＨＤ４１０２による第１の記憶エリア４１２４からの写真の読み込みが生じたと判断するとよい。もう１つの例として、ＨＤ４１０２が、第１の記憶エリア４１２４のファイルアロケーションテーブル（ＦＡＴ）を読み込むコマンド４１１０を提供する（おそらくデータ位置を対応付けるため）ことが認識され、続いて、固定速度／スループットで第１の記憶エリア４１２４からデータブロックを読み込むためのコマンド４１１０をＨＤ４１０２が提供することが認識されれば、インデクサ４１３０は、このコマンドグループが、第１の記憶エリア４１２４からの音楽ファイルの読み込みに該当すると認識することができる。さらにもう１つの例として、使用データコレクタ４１３０によって、ＨＤ４１０２が、第１の記憶エリア４１２４のファイルアロケーションテーブル（ＦＡＴ）を読み込むコマンド４１１０を提供する（おそらくデータ位置を対応付けるため）ことが認識され、続いてインデクサ４１３０が、可変速度／スループットで第１の記憶エリア４１２４からデータブロックを読み込むためのコマンド４１１０をＨＤ４１０２が提供することを認識すれば、このコマンドグループは、第１の記憶エリア４１２４からのビデオファイルの読み込みとして特徴付けできる。（しかし、場合によっては、ＦＡＴデータはＨＤにキャッシュされることもあり、したがって、後のデータアクセスコマンドとＦＡＴ読み込みとの相互関係を明らかにすることが難しいかまたは不可能であることも考えられる。）これらは、ＨＤ４１０２からＬＳＤ４１０４に対するコマンド４１１０から、インデクサ４１３０が認識できることの例であり、他の例もあり得る。本願明細書の例の多くは、読み込みデータアクセスに関連しているが、特徴付けられるデータアクセスはさらに（または代わりに）、メディアファイルを第１の記憶エリア４１２４にロードするための書き込みデータアクセスなど、書き込みデータアクセスを含んでもよい。
【０１８９】
これらがデータアクセスパターンの例であるが、当然のことながら、パターンがＬＳＤ４１０４に予めロードされ（場合によっては動的に更新されることさえもあり、その例は本願において後述される）、データアクセスの詳しいタイプを特定するために、インデクサ４１３０によって参照用に使用されることも可能である。使用時、パターンは、例にあるようにかなり単純であってもよく、またははるかに複雑であってもよい。
【０１９０】
さらに、インデクサ４１３０は、メモリアレイ４１２４に格納されているデータのインデックス情報を提供する過程で、ＨＤ４１０２とＬＳＤ４１０４の第１の記憶エリア４１２４との間で転送されている（例えば、読み込みおよび書き込み方向のいずれかまたは両方で）データブロック４２０２のコンテンツを使用してもよい。例えば、インデクサ４１３０は、データブロックのコンテンツがストリング「ＪＦＩＦ」を含むと認識して、データブロックを写真（ＪＰＥＧ）に対応すると特徴付けて、この特徴付けを、インデックス情報の提供過程で使用してもよい。別の例として、ＭＰ３ファイルは典型的にストリング「ＩＤ３」で始まる「タグ」を有し、ＰＤＦファイルは「％ＰＤＦ」で始まり、ｍｐ４ビデオファイルはストリング「ｆｔｙｐ３ｇｐ」を含む。したがって、例えば各「タグ」が、そのほか任意のパターンのように予めロードしたり、更新したり、あるいはそのほかの形でなどの操作が可能な、１つの特定のパターンタイプとして見なされてもよい。
【０１９１】
データの特徴付けは、例えば、インデックスデータの一部としてインデックス内に格納されてもよい。したがって、例えばデータの特徴付けは、検索結果を判断するためおよび／または検索結果をさらに絞り込むために使用されるとよい。検索結果は、絞り込みが行われなければ言葉またはデータのインデックスのみに基づいて提供されると考えられる。
さらに、インデクサ４１３０は、メモリアレイ４１２４の第１の部分に格納されているデータのインデックスデータとして、ＨＤ４１０２とＬＳＤ４１０４の第１の記憶エリア４１２４との間で転送されている（例えば、読み込みおよび書き込み方向のいずれかまたは両方で）データブロック４２０２のコンテンツを直接採用してもよい。そのようなコンテンツは、例えば、データブロック４２０２のコンテンツに直接含まれているテキストデータまたはメタデータを含むとよい。
【０１９２】
いくつかの例では、インデックス付けされるコンテンツは、それによって間接的に表されているデータを認識するべくさらに処理されてもよい。したがって、例えば、インデクサ４１３０によって、データがオーディオファイルとして特徴付けられたと判断されれば、インデックス付けされるコンテンツデータ（例えば、話された言葉または歌われた言葉）を認識するために、デジタル音声認識が使用されてもよい。同様に、インデクサ４１３０によって、データがビデオファイルとして特徴付けられたと判断されれば、コンテンツを認識するためにイメージ処理が使用されてもよい。したがって、例えば、ビデオファイルの全般的な主題または具体的な細部さえも認識できる可能性があり、その結果それを検索インデックスの一部として格納することができる。いくつかの例では、インデックスはさらにまたは代わりに、カタログの特徴を有してもよい。その結果、当該インデックスを、検索結果にあることが望まれるコンテンツに基づくのみではなく、むしろ、さらにまたは代わりに、ＬＳＤのメモリアレイに格納されている特定のドキュメント（メディアなど）に関する挙動（またはそのほかのメタデータ、厳密にはコンテンツベースでない）に基づく検索クエリに応答するために使用できる。例えば、ＨＤにおいて実行されてＬＢＡベースのコマンドを使用してメディアにアクセスする１つ以上のプログラムによるメディアの管理に、インデックス付けが適用されてもよく、以下のものなどのカタログ内の情報に基づいて検索を行うことが望ましいこともある。
・ＬＳＤのメモリアレイに格納されている歌曲は何回再生されたか？
・ＬＳＤのメモリアレイに格納されている歌曲が最後に再生されたのはいつか？
・ＬＳＤのメモリアレイに格納されている歌曲は最後まで再生されたか、または再生は中断されたか？
【０１９３】
例えばメディア項目が再生されているとき、インデクサ４１３０は、「最終再生日」または「再生回数」など、その項目に関するカタログ内のいくつかのフィールドを更新するように動作するとよい。
さらに、例えば、カタログは、コマンド４１１０および／またはデータ４１１１からの、以下のことなどの動作の認識に基づいて更新されるとよい。
・新たな再生リストの定義―新たなレコードが再生リストカタログへ追加されること、および
・項目の削除―レコードがカタログから削除されること。
カタログの検索は、「ｓｅａｒｃｈ？ａｒｔｉｓｔ＝ｍａｄｏｎｎａ＆ｎｕｍｂｅｒ＿ｔｉｍｅｓ＿ｐｌａｙｅｄ＝０」などのクエリとして行われるとよく、これは「再生したことがないマドンナの歌曲をすべて見つける」という意味である。検索は、さらにまたは代わりに、「ロンドン」または「ギターソロ」などの歌曲中のコンテンツ、またはインデクサ４１３０によって認識されインデックス付けされた他のコンテンツに基づいてもよい。
【０１９４】
インデクサ４１３０は、ホストデバイス４１０２とＬＳＤ４１０４との間で渡されるコマンド４１１０およびデータ４１１１の監視に加えて、大容量記憶エリア４１２４内のデータに直接アクセスすることによって動作してもよい。したがって、例えばこのようにしてインデクサは、バックグラウンドなどでインデックス４１２６に格納するインデックスデータを生成するように動作してもよく、インデックス４１２６のポピュレートにホストデバイス４１０２が関与することはやはりない。
第２の記憶エリア４１２６は、インデクサ４１３０によって生成されたインデックスを含むとよい。例えば、図１８では、第２の記憶エリア４１２６は、１つ以上の検索クエリに応答してデータのコーパスに関連する検索結果を返すために検索エンジンによって使用可能であることが現在既知であるかまたは将来既知となる、様々なタイプのインデックスデータのうちのいずれかを含むとよい。
インデックスは、記憶アレイ４１２０に格納されるとよく、場合によってはさらにＨＤＦＳ４１０６に認識されなくてもよい。ＬＳＤ４１０４によってどのようにインデックスデータが生成されるとよいかについていくつかの例を記載してきたが、以下ではインデックスがどのように使用され得るかの例をいくつか説明する。概して、インデックスデータは、ＬＳＤ４１０４自体によって、ＨＤ４１０２によって、および／または外部プロセスによって使用され得る。
【０１９５】
図１７を再び参照すると、検索インデックス４１２６がＨＤ４１０２によって獲得および／または使用され得るように、システム４１００が構成されているとよい。例えば、検索インデックス４１２６は、記憶アレイ４１２０の大容量記憶エリア４１２４内に格納されているとよい。例えば、ＬＳＤの大容量記憶エリアに、このエリアが外部ファイルシステム（ＨＤＦＳ）によって管理されていても書き込みを行う方法の例が記載されている米国特許出願第１２／０２９，３５６号（特許文献２）を参照されたい。この場合、他の場合では一般に大容量記憶エリア４１２４内のデータにアクセスするために使用されると考えられる動作を使用して、ＨＤ４１０２は検索インデックス４１２６にアクセス可能である。したがって、例えば、ＨＤＦＳ４１０６が、ＬＳＤドライバ４１０８およびＨＤ／ＬＳＤインターフェイス４１１２を介してコマンド４１１０をＬＳＤ４１０４に提供するように、ＨＤ４１０２上で実行されているアプリケーション４１１８が動作するとよい。当該コマンド４１１０は、検索インデックス４１２６がデータ４１１１としてＨＤ／ＬＳＤインターフェイス４１１２を介してＨＤ４１０２に提供されるように、フラッシュマネージャ４１２８に提供されるとよい。
【０１９６】
このようにしてＨＤ４１０２によって獲得された検索インデックスは、例えば、ＨＤ４１０２によって実行されているアプリケーション４１１８により使用されてもよい。このようにして獲得された検索インデックスは、ＨＤ４１０２から、ＨＤ４１０２が接続されているとよいコンピュータまたはそのほかのサーバ上のメディア管理システムなど、外部デバイスまたはシステムに提供されてもよい。そのような検索インデックスは、例えば、その外部デバイスまたはシステムがどのようにＨＤ４１０２と対話するか、またはそのほかの形で動作するかを判断するために、少なくとも部分的に、その外部デバイスまたはシステムによって使用されてもよい。
【０１９７】
以下、図１９を参照すると、ＬＳＤ４１０４自体によって実行される検索エンジン４３０２によってインデックスが使用されるとよいシステムの構成例を示す。例では、フラッシュマネージャ４１２８が、検索クエリ４３０４であるコマンド４１１０またはコマンド４１１０の一部をホストデバイス４１０２から受け取るように動作するとよい。検索エンジン４３０２は、検索インデックス４１２６にアクセスし、検索クエリ４３０４に基づいて検索結果４３０６をホストデバイス４１０２に返すとよい。もう１つの例として、インデックス付けの結果は、ＬＳＤによるコンテンツの選別、すなわちＬＳＤのメモリアレイにある不正コンテンツへのアクセスを禁止するために「ポルノ」のような特定のストリングを探すアプリケーションに使用されてもよい。コンテンツの選別は、例えばＨＤにおいて実行されてもよく（例えば、ＬＳＤのメモリアレイ内の特定のコンテンツへのアクセスリクエストを回避することにつながる）、または別の例として、ＬＳＤ自体において実行されて、書き込みアクセスリクエストでも読み込みアクセスリクエストでも、ＨＤから受け取られるアクセスリクエストがブロックされてもよい。
もう１つの例として、アプリケーション４３０８（例えば、ブラウザまたはＳＱＬエージェントなどのウェブアプリケーション）が、ホストデバイス４１０２上で動作しているとよく、検索エンジン４３０２と対話して（データアクセス動作に使用される論理インターフェイス以外の論理インターフェイス４３１０を介してなど）、検索クエリ４３０４に応答しての検索結果４３０６を獲得するとよい。
【０１９８】
図２０は、例えばホストアプリケーション４１１４、ＨＤＦＳ４１０６、およびＬＳＤ４１０４の処理と協働するＬＳＤドライバ４１０８などによって実装されているマスタ／スレイブパラダイム外にある外部デバイス（ネットワーク４４０８を介してＨＤ４１０２に結合されたデバイス４４０６など）に、検索インデックス４１２６の一部または全部が転送されるかまたはアクセス可能であるとよい構成例を示す。従来のマスタ／スレイブ（またはホスト／スレイブ）パラダイム外のデータ転送またはデータアクセスの例は、例えば、米国特許出願第１２／０２９，３５６号（特許文献２）に記載されている。
さらに図２０を参照すると、ＬＳＤ４１０４上のエージェント４４０２は、ＨＤ４１０２上のエージェント４４０４と通信している。したがって、例えば、ＬＳＤ４１０４上のエージェント４４０２とＨＤ４１０２上のエージェント４４０４との間の通信は、ＨＤＦＳ４１０６による介入を必要としないセキュアなパスを介するとよく、さらに／または転送されるインデックスデータは他の形でＨＤ４１０２上の処理（ホストアプリケーション４１１４など）がアクセスできないようになっているとよい。
【０１９９】
さらに、デバイス４４０６は、（前述したように、）検索インデックス４１２６または検索インデックスの一部の消去、検索インデックスの判断に使用される情報（例えば、音声認識またはイメージ認識処理を実行するのに使用されるパラメータなど）、あるいはそのほかの当該情報の変更など、検索インデックス４１２６に関する記憶動作も実行するとよい。
さらに、デバイス４４０６に検索インデックス４１２６を転送することなく、検索クエリに応答することなどのために、セキュアなパスを使用してデバイス４４０６によりインデックス４１２６がアクセスされてもよい。一例では、エージェント４４０２は、外部デバイス４４０６からエージェント４４０２に提供された検索クエリに基づき、ＬＳＤ４１０４上で検索インデックス４１２６を処理することによって、外部デバイス４４０６にクエリレスポンスを提供することができる検索エンジン機能性を含むとよい。前述したように、検索クエリは、クエリレスポンスを判断するべく、特定のコンテンツを検索することおよび／またはインデックス４１２６内のメタデータを利用することであるとよい。
【０２００】
一般に、図２０の構成を例として使用すれば、検索インデックス４１２６を処理するアプリケーションは、ＨＤ内（またはＬＳＤ内）の任意の関連アプリケーションと共有される論理インターフェイスを介してアクセスされるとよい。ＬＳＤが、インターネット／ＩＰ／ネットワークインターフェイスを公開することによって、ＨＤ内の標準インターネットクライアントアプリケーションが、標準サーバとしてのＬＳＤ内のインデックスにアクセスしやすくなる。したがって、標準インターネット／ＩＰベースのクライアントアプリケーション（例えば、ウェブブラウザまたはＳＱＬクライアント）がＨＤ上で実行されるとよく、インデックス４１２６はＬＳＤ内のサーバ（例えば、ウェブサーバまたはＳＱＬサーバ）としてアクセスされるとよい。いずれの場合でも、サーバはＨＤ内ではなくＬＳＤ内にあり、クライアントはＨＤ内またはリモートデバイス内のいずれかにある。
【０２０１】
以下、ＬＳＤ上のインデックス４５０２のインデックスデータをＬＳＤが生成していける方法を広い見方で例示するフローチャートである図２１を参照する。４５０４にて、ＨＤの関与なしに、ＬＳＤが、ＬＳＤのメモリアレイに格納されたデータに関してインデックスデータを生成する。ＬＳＤのメモリアレイは、ＨＤによってデータブロックとして管理されている。４５０６にて、ＬＳＤは、生成されたインデックスデータを、検索インデックス４５０２の少なくとも一部としてＬＳＤ上に格納する。したがって、例えば、検索クエリが受け取られ（４５０８）、その検索クエリがインデックス４５０２に関して処理されて（４５１０）、検索クエリへのレスポンスが生成されるとよい。
【０２０２】
このように、ＬＳＤが、ホストデバイス（ＨＤ）の関与なしにＬＳＤのメモリアレイ内のデータにインデックス付けするとよいシステムおよび方法について記載してきた。さらに、そのインデックスがどのように、例えば検索クエリに応答するために処理されるかについて記載してきた。さらに、例えば検索インデックスがどのようにコンテンツの選別に用いられ得るかについて記載してきた。
【０２０３】
図２２は、本発明の実施形態に従ったマスタ／スレイブシステム５１００の簡略化したブロック図を示す。例として、本願明細書に記載される特定の実施形態によれば、スレイブデバイスは、限定されるものではないが、前に説明した記憶デバイスのいずれかなどのローカル記憶デバイスという形をとるとよく、マスタデバイスは、限定されるものではないが、前に説明したホストデバイスのいずれかなどのホストデバイスという形をとる。前に背景技術の欄で説明したように、マスタ／スレイブは、１つのデバイスまたはプロセスが、１つ以上の他のデバイスに対して一方向の制御権を有する通信プロトコルのモデルである。従来のシステムでは、デバイス間またはプロセス間のマスタ／スレイブ関係が確立されると、制御の方向は常にマスタからスレイブであり、すなわちスレイブはトランザクションを開始できない。一部のシステムでは、マスタは、適格な複数のデバイスのグループから選ばれ、他のデバイスがスレイブの役割を果たす。したがって、マスタ／スレイブシステム５１００（以下、簡単にシステム５１００とも呼ぶ）は、少なくともマスタデバイス５１０２（以下、ホストデバイス５１０２またはホストコントローラ５１０２とも呼ぶ）、第１のスレイブデバイス５１０４（以下、記憶デバイス５１０４とも呼ぶ）、および第２のスレイブデバイス５１０６（以下、記憶デバイス５１０６とも呼ぶ）を含み、これらは、少なくとも従来のマスタ／スレイブパラダイムによって互いに関係している。
【０２０４】
システム５１００は、ホストデバイス５１０２と、周辺記憶デバイス５１０４および５１０６とを接続するために使用されるいくつかの通信または信号線５１０８（以下、バス５１０８と呼ぶ）も含む。なお、周辺記憶デバイスは２つのみ示されているが、これより多いまたは少ない記憶デバイスを、バス５１０８に容易に結合できる。バス５１０８を構成する信号線の実際の数も、広く多様なものとなり得る。例として、現代のバスの一部は、比較的少数の信号線（例えば、８〜１６の信号線）を有し、その一方で、他の現代のバスは１００を超える線を有することもあり、それがサブバス（例えば、アドレスバス、制御バス、データバスなど）として事実上機能する線のサブセットに論理的に分割されることもある。
【０２０５】
各記憶デバイスは、典型的には、対応する一意的かつ永久的なデバイス識別子を含む。一部のバスプロトコルでは、永久的なデバイス識別子が、バス通信でデバイスを特定するために使用される。他のプロトコルでは、ホストコントローラが、一時的なデバイス識別子および／または関連したアドレスセットを、バスに結合されたデバイスそれぞれに付与する。典型的には、そのような一時的なデバイス識別子および／またはアドレスは、各記憶デバイス５１０４もしくは５１０６と、バス５１０８およびホストコントローラ５１０２とを接続して初期化するか、またはリムーバブルメモリカードの場合には関連したカードリーダにカードを挿入すると、付与される。バスプロトコルおよびメモリ管理プロトコルの詳細は、用いられる特定のバスおよび記憶デバイスの性質に基づき異なるが、ホストコントローラ５１０２は典型的に、各記憶デバイスのそれぞれのデバイス識別子（単数または複数）を理解している。
【０２０６】
典型的には、バス５１０８に取り付けられている特定のデバイスには、ホスト５１０２から送られる通信に基づき、特定の通信またはコマンドに応答しなければならないかどうかが分かる。ホスト５１０２は、典型的に、特定の記憶デバイスを通信／コマンドのターゲットとするために、デバイス識別子および／またはアドレスを使用する。すなわち、一部のプロトコルでは一般に、各通信が、それがその通信のターゲットであるか否かを記憶デバイスに通知するデバイス識別子を含む。他のプロトコルでは、デバイス識別子は、各メモリ関係通信の一部として明示的に送出はされない。代わりに、コマンドが、そのコマンド（例えば、読み込み、書き込みまたは消去コマンド）がアドレス指定されているアドレスを特定することもある。一般に、通信で特定またはアドレス指定されていないデバイスは、単にその通信を無視する。
【０２０７】
図に示されている実施形態では、通信は、共有バス５１０８上で、記憶デバイス５１０４および５１０６へ適切なバスプロトコルによって送られる。バスプロトコルは、バス上でどのように情報が伝達されるかを規定する。この場合もやはり、適切なバスプロトコルにはセキュアデジタルカード（ＳＤ）プロトコル、マルチメディアカード（ＭＭＣ）プロトコル、およびユニバーサルシリアルバス（ＵＳＢ）プロトコルが含まれるが、他の多種多様なバスプロトコルが同様に使用され得る。さらに、当業者には当然のことながら、現在の記憶デバイスは、多種多様な種々のアーキテクチャを用い、新たなアーキテクチャの開発が続くことが予想される。概して、本発明は、記憶デバイスが適切な処理能力を有する限り、多種多様な種々のタイプのメモリとともに用いられ得る。
【０２０８】
図２３は、本発明の一実施形態に従った記憶デバイス５１０４および５１０６それぞれをさらに詳しく表す記憶デバイス５２００の概略の構造を示すブロック図である。様々な実施形態において、記憶デバイス５２００は、従来の記憶デバイスであっても、またはレガシー記憶デバイスであってもよい。前述したように、記憶デバイス５２００は、リムーバブルデバイスまたは非リムーバブルデバイスのいずれかであるとよい。図に示されている実施形態では、記憶デバイス５２００は、従来のリムーバブルフラッシュメモリカードであり、一般に、メモリコントローラ５２１４および大容量記憶領域５２１６を含む。メモリコントローラ５２１４は、メモリマネージャ５２１８およびプロトコルパーサ５２２０を含む。
【０２０９】
当業者には当然のことながら、プロトコルパーサ５２２０は、バス５１０８上で送られる通信を解析するように設定されている。より詳しく言えば、プロトコルパーサ５２２０は、ホスト５１０２から送られた通信を解析して、記憶デバイス５２００がこのバス通信の意図されたターゲットであるかどうかを、通信の一部として指定されているデバイス識別子またはアドレスに基づいて判断するように設定されている。そのバス通信が、記憶デバイス５２００に向けられたメモリ動作であれば、その通信はメモリマネージャ５２１８に渡され、その結果としてメモリマネージャ５２１８は、大容量記憶領域５２１６にアクセスしてリクエストされた動作を実行する。記憶デバイス５２００に向けられた他の命令は、必要に応じて、プロトコルパーサ５２２０またはメモリマネージャ５２１８のいずれかによって応答される。他のデバイスに向けられた命令および通信は、一般に、単に記憶デバイス５２００からは無視される。
【０２１０】
記憶デバイスの少なくとも１つがリムーバブルである実施形態では、記憶デバイス識別子は、ターゲットとされる記憶デバイスに関連した永久的なデバイス識別子であることが好ましい。当業者には当然のことながら、フラッシュメモリカードなどの多数のタイプの記憶デバイスが、このために使用されるとよい関連した永久的なデバイス識別子を有する。一方、永久的なデバイス識別子を含まない記憶デバイスを利用する実施形態では、ホスト５１０２によって付与されるデバイス識別子が使用されるとよい。ここで注目すべきは、場合によっては単一の物理デバイスが、その物理デバイス内に、２つ以上のアドレス指定可能な記憶領域（またはデバイス）を含み得るということである。この場合、各記憶領域が、対応するデバイス識別子および／または論理アドレスのセットを有するとよい。さらに、特定のコマンドが、バス５１０８上のすべての記憶デバイスにアドレス指定される場合は、コマンドがバス上のすべてのデバイスにアドレス指定されたことを示すブロードキャスト識別子、またはターゲットとされるすべてのデバイス識別子のリストのいずれかが使用されるとよい。
【０２１１】
一般に、ホスト５１０２から伝送されるコマンドなどの通信は、実行されるべきバスプロトコル動作のタイプを特定する動作識別子を含む。特定される動作は、読み込み、書き込み、および消去動作などのメモリ動作、ターゲットとされた記憶デバイスに対するパーティション作成命令などのメモリ管理コマンド、初期化および認証リクエスト、割り込み、肯定応答、エラー信号、およびそのほか任意のバス関係のコマンドまたは動作であればよい。
【０２１２】
再びシステム５１００を参照すると、ホスト５１０２は、記憶デバイス５１０４および５１０６の様々な動作を制御する。例として、ホストは、記憶デバイスにコマンドを伝送して、データの書き込み、データの読み込み、および消去を、他のハウスキーピング動作に加えて記憶デバイスに命令する。コマンドは、ホスト５１０２からバス５１０８上で、バスに接続されている１つ以上の、ターゲットとされた記憶デバイスに伝達される。所与のコマンドによってターゲットとされた（例えば、コマンド内のデバイス識別子および／またはアドレスによって）記憶デバイス（単数または複数）のみが、コマンドを受理し、そのコマンドに基づき動作を実行する。なお、記載される実施形態では、ホスト５１０２のみがバス５１０８上でコマンドを伝送できる。
【０２１３】
本発明の特定の実施形態の基本的な例を説明するために、図２４のフローチャートおよび図２２のシステムを参照して、ソース記憶デバイス５１０４から宛先記憶デバイス５１０６にデータを書き込むプロセス５３００について記載する。プロセス５３００は、５３０２にて、ホスト５１０２が、記憶デバイス５１０６をターゲットとするＬＩＳＴＥＮ／ＷＲＩＴＥコマンドをバス５１０８上で送って、バスをリッスンしてバスからのデータをデバイスのメモリに書き込むように記憶デバイス５１０６に命令することで開始する。一実施形態では、ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドは、記憶デバイス５１０６に、特定の時間Ｔ１にバス５１０８のリッスンを開始し、バスからのデータを、時間Ｔ１の後にデバイスのメモリに書き込むように命令する。より詳しく言えば、バス５１０８上でのデータの転送を構成するために時分割多重方式プロトコルが使用される実施形態では、ホスト５１０２は、特定のタイムスロットＸ１にバス５１０８のリッスンを開始するように記憶デバイス５１０６に命令するとよい。さらにもう１つの実施形態では、スレイブデバイス５１０６が、すぐにリッスンを開始して書き込むべきデータがバス５１０８で入手可能になるまで待つように命令されることも可能である。
【０２１４】
ホスト５１０２はさらに、５３０４にて、記憶デバイス５１０４をターゲットとし、データをデバイスのメモリから読み込んでそのデータをバス５１０８上へ出力するように記憶デバイス５１０４に命令するＲＥＡＤコマンドを、バス５１０８上で送る。一実施形態では、ＲＥＡＤコマンドは、特定の時間に、好適にはいかなるデータも喪失しないようにＴ１またはＴ１の後に、データの読み込みを開始してバス５１０８上へ出力するように記憶デバイス５１０４に命令する。この場合もやはり、バス５１０８上でのデータ転送を構成するために時分割多重方式プロトコルが使用される実施形態では、ホスト５１０２は、特定のタイムスロットＸ１にデータの読み込みおよびバス５１０８への出力を開始するように、記憶デバイス５１０４に命令するとよい。別の実施形態では、スレイブデバイス５１０４は、すぐにデータの読み込みおよびバス上への出力を行うように命令される。
【０２１５】
このように、記憶デバイス５１０６は、記憶デバイス５１０４から直接出力されたデータを、バス５１０８からプルし、そのデータをメモリに書き込む。特に、従来の構成とは違って、記憶デバイス５１０４から出力されたデータが、バス５１０８からプルされて記憶デバイス５１０６に書き込まれる前にまず一時的にホスト５１０２またはそのほか任意のデバイスにキャッシュされるということはない。したがって、ホスト５１０２は、記憶デバイス５１０４と記憶デバイス５１０６との間でのデータのトランザクションを開始するが、ホスト５１０２は、データの格納および／または伝送には関与しない。
【０２１６】
したがって、様々なマスタ／スレイブバスプロトコル（ＳＤプロトコルなど）は、ホストのみがトランザクションを開始し、コマンドを送ることができると規定しているが、本発明はこの従来のパラダイムを回避する。すなわち、本発明は、記憶デバイス５１０４と５１０６との間の直接のデータ転送を可能にし、その一方で、各記憶デバイスは、それがバス５１０８上で送出または受領するデータはホスト５１０２へ送られているかまたはホスト５１０２から受け取られていると推定するため、レガシーなデバイスおよびマスタ／スレイブプロトコルの使用を可能にする。さらに、当然のことながら、こうすることでバス５１０８上で伝送されるデータの総量は約半分に減らされると考えられる。すなわち、データが、まずキャッシュされて次にキャッシングデバイスによって再送されるのではなく、１つの記憶デバイスから別の記憶デバイスへ直接書き込まれることが可能であるため、あるトランザクションに関してバス５１０８上で伝送されるデータの量を、ほぼ半分に削減することが可能であり、したがって、必要な総帯域幅も同じく削減されると考えられる。結果として、記憶デバイス同士の間のデータ転送速度が上がり、さらにホスト５１０２のプロセッサ要件が緩和されると考えられる。
【０２１７】
一実施形態では、記憶デバイス５１０４は、ホスト５１０２が５３０６にて、デバイス５１０４をターゲットとして、記憶デバイス５１０４にデータの読み込みおよびバス５１０８上への出力を止めるように命令するＳＴＯＰ＿ＲＥＡＤＩＮＧコマンドを発行するときまで、データの読み込みおよびバス５１０８上への出力を継続する。同じく、記憶デバイス５１０６は、ホスト５１０２が５３０８にて、デバイス５１０６をターゲットとして、記憶デバイス５１０６にバスからデータをプルすることを止めるように命令するＳＴＯＰ＿ＬＩＳＴＥＮＩＮＧコマンドを発行するときまで、バス５１０８からデータをプルし続ける。
【０２１８】
代わりの実施形態では、ＲＥＡＤコマンドはさらに、期間Ｄ１が経過する時点までバス５１０８上にデータを出力し続けるように記憶デバイス５１０４に命令する。同じく、ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドも、期間Ｄ２が経過するまでバス５１０８からデータをプルし続けるように記憶デバイス５１０６に命令してもよい。好適な実施形態では、いかなるデータも喪失しないように、Ｄ２は少なくともＤ１と同じ長さである。例として、ホスト５１０２が、転送されるデータ量（例えば、ビット数）およびバス５１０８の動作周波数を知っていれば、ホストはそのデータの転送に必要な期間を計算して、その後に記憶デバイス５１０４にこの期間データを出力するように命令し、記憶デバイス５１０６に、この期間データのリッスンおよび書き込みを継続するように命令することができる。
【０２１９】
もう１つの代わりの実施形態では、ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドは、特定のタイムスロットＸｎの間バス５１０８をリッスンするように記憶デバイス５１０６に命令し、このタイムスロットＸｎは、連続的であっても、連続的でなくてもよい。その結果、タイムスロットＸｎの間、バス５１０８上のデータはデバイスのメモリに書き込まれる。この代わりの実施形態では、ＲＥＡＤコマンドは、同じく、特定のタイプのスロットＸｎの間データの読み込みおよびバス５１０８上への出力を開始するように記憶デバイス５１０４に命令する。なお、この場合もやはりタイムスロットは連続的でなくてもよい。より詳しくは、ホスト５１０２が、タイムスロットＸ１、Ｘ２、Ｘ３およびＸ４においてデータＡをバス５１０８上へ出力するように記憶デバイス５１０４に命令してもよく、このタイムスロットは、この場合もやはりいくつかの実施形態において連続的でなくてもよい。その結果、ホスト５１０２は、タイムスロットＸ１、Ｘ２、Ｘ３およびＸ４の間にバス５１０８をリッスンしてデータをそこからプルするように記憶デバイス５１０６に命令することになる。
【０２２０】
説明のために、前述した記載は、特定の例を使用して本発明の完全な理解を提供した。しかし、当業者には当然のことながら、特定の詳細事項は本発明を実践するために必須ではない。したがって、本発明の特定の実施形態の前述した説明は、説明および記載のために示されたものである。それらは、包括的であること、または開示された厳密な形に本発明を限定することを目的としたものではない。当業者には当然のことながら、前述した教示を考慮して多数の変更および変形が可能である。
【０２２１】
例えば、プロセス５３００は、単一の記憶デバイス５１０４からもう１つの単一の記憶デバイス５１０６へのデータ転送を参照して記載されたが、当然のことながら、ホスト５１０２は、複数の記憶デバイスに特定の時間にバスをリッスンして関連データをメモリに書き込むよう命令するマルチキャストまたはブロードキャストコマンドを発行してもよい。こうすることで、データの複数のコピーを複数のデバイスに同時に格納することができる。
【０２２２】
さらに、前述した説明は、１つのメモリデバイスからデータを読み込み、それが格納される別のメモリデバイスへデータを転送するという状況で記載されたが、同じく当然のことながら、本発明の各態様は、特に記憶デバイスとして構成されたデバイス以外のデバイスにも適用可能である。例として、本発明の各態様は、通信およびデータを、外部ネットワークへおよび外部ネットワークから転送するのに有用であると考えられる。より詳しく言えば、バスに結合された第１のスレイブデバイスは、ＷｉＭａｘ、ＷｉＦｉ、またはブルートゥースなど、外部ネットワークまたはプロトコルへのネットワークブリッジとして機能するネットワークカードであってもよく、第２のスレイブデバイスは、バスと結合された記憶デバイスであってもよい。例として、マスタデバイスは、外部ネットワークから受け取るかまたは受け取ったデータを、バスを介して直接第２のスレイブデバイスに渡すように第１のスレイブデバイスに命令してもよいし、あるいは外部ネットワーク上で伝達されるべきデータを第１のスレイブデバイスに送るように第２のスレイブデバイスに命令してもよい。このような実施形態では、ネットワークカードはＳＤＩＯプロトコルを使用するＳＤバス上のカードであってもよい。
【０２２３】
さらに、前述した説明は、特定のバス／デバイス構成に関して記載されたが、代わりの実施形態では、記憶デバイスは他の適切な構成または配置で接続されてもよい。例として、図２５に示されている実施形態では、スレイブ記憶デバイス５４０４、５４０６、および５４０８を含む各デバイスがデイジーチェーン構成で直列接続されている。このような構成は、特に、様々な高速コンシューマ電子アプリケーションにおいて望ましいと考えられる。図２５に示されている実施形態では３つの記憶デバイスしか示されていないが、当然のことながら、これより多いまたは少ないデバイスがデイジーチェーン構成において配置されてもよい。一般に、このような構成では、典型的には２つから５つのデバイスが接続される。
【０２２４】
デイジーチェーン構成とは、１つのデバイスのピンが隣接するデバイスのピンに電気的に接続されるということである。接続は、硬ろう付けによるか、あるいはプリント回路レイアウトまたはソケットピンの接続によることができる。例えば、記憶デバイス５４０４からのピンの第２のセットを、記憶デバイス５４０６からのピンの第１のセットに、通信線５４３２のセットを介して接続することが可能であり、記憶デバイス５４０６のピンの第２のセットを、通信線５４３４のセットを介して記憶デバイス５４０８のピンの第１のセットに接続することが可能であるなどである。このように、デイジーチェーン構成の最初および最後のデバイス以外の記憶デバイスはすべて、直接隣接した２つの近隣デバイスに接続される。なお、他の記憶デバイスとは違い、記憶デバイス５４０４のピンの第１のセットは、マスタデバイスとしての機能を果たすホスト５４０２と、通信線５４３０のセットとを介して接続される。一実施形態では、すべての記憶デバイスがクロックを共有するが、各デバイスがそれ用のクロックを生成してもよいため、これは必須条件ではない。
【０２２５】
図に示されている実施形態では、記憶デバイス５４０４、５４０６、および５４０８を互いに、およびホスト５４０２へ相互接続する共通バスはない。代わりに、この構成では各デバイスが、それ自体にアドレス指定されていないホスト５４０２からのコマンドを、チェーンの下流にある次のデバイスへ渡す。すなわち、チェーン内の第１のデバイス（例えば、記憶デバイス５４０４）以外の各記憶デバイス（例えば、記憶デバイス５４０６および５４０８）は、チェーン内の上流デバイスを介してホスト５４０２に結合される。すなわち、ホスト５４０２から特定の記憶デバイスに渡される通信または情報は、まず、チェーン内の他のすべての上流デバイスを順に通過しなければならない。事実上、記憶デバイス５４０４、５４０６および５４０８は、通信線５４３０、５４３２および５４３４とともに、通信および情報をホストから記憶デバイスへ、および記憶デバイスからホストへ渡す機能をする実質的な通信バスを形成する。
【０２２６】
記憶デバイス５４０４、５４０６、および５４０８が、デイジーチェーン構成に配置されている一実施形態例では、ホスト５４０２が、デイジーチェーンで接続された一連のデバイスへＬＩＳＴＥＮ／ＷＲＩＴＥコマンドを伝送するとよい。例として、ホスト５４０２は、記憶デバイス５４０６をターゲットとするＬＩＳＴＥＮ／ＷＲＩＴＥコマンドを通信線５４３０上で伝送するとよく、このコマンドはまず記憶デバイス５４０４によって受け取られる。次に、記憶デバイス５４０４は、ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドを通信線５４３２上で渡すとよく、続いてコマンドはターゲット記憶デバイス５４０６にて受け取られる。ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドは、記憶デバイス５４０６に、通信線５４３４を特定の時間にリッスンし、その特定の時間から通信線５４３４からのデータの書き込みを始めるように命令してもよい。ホスト５４０２は、記憶デバイス５４０８をターゲットとするＲＥＡＤコマンドも通信線５４３０上で伝送するとよい。ＲＥＡＤコマンドは、ターゲット記憶デバイス５４０８に到着するまで、記憶デバイス５４０４および５４０６により、通信線５４３２および５４３４に沿って渡されるとよく、メモリからデータを読み込み、そのデータを特定の時間に通信線５４３４上へ出力するように記憶デバイス５４０８に命令するとよい。このように、記憶デバイス５４０６は、ＬＩＳＴＥＮ／ＷＲＩＴＥコマンドによって命令された特定の時間に通信線５４３４をリッスンし、通信線５４３４からプルするデータを書き込むとよく、このデータは、まずデータをホスト５４０２へ転送することなく、直接記憶デバイス５４０８から読み込まれて記憶デバイス５４０８によって通信線５４３４上へ出力されたものである。
【０２２７】
他の実施形態では、別個の共通バスが、記憶デバイス同士を相互接続し、さらにホスト５４０２と相互接続して、記憶デバイス５４０４、５４０６および５４０８を図２５にあるようなデイジーチェーン構成に配列することが可能である。こうすることで、従来の構成とは違い、デイジーチェーンで接続されたデバイス間の信号または通信パスが、バスとは切り離されて異なるものとなり、その結果、やはり従来の手法とは違い、通常であれば情報および／またはデータを記憶デバイスとホスト５４０２との間で渡すために使用されると考えられるバスリソースが、消費されない。
【０２２８】
より高い機能性を提供し、その結果より高いユーザ満足度を提供するために、最新の携帯コンシューマ電子製品（特に、ホストデバイスに含まれるプロセッサ）は、既に提供されているコアサービス（例えば、メディアプレーヤ）に加えて、さらに多くのユーザサポート（補助）機能を実行することを要求されている。しかし、こうした携帯コンシューマ電子製品はプロセッサリソースおよびＲＡＭの両方が限られ、追加機能はいずれも、プロセッサの動作を遅くし、プロセッサに過度の電力を消費させ、決して満足を与えるものではないユーザ体験をもたらす恐れがある。最も使用され頼られている補助サービスの１つは（特に、ユーザがアクセス可能な、格納されている多数のデータファイルという点から見ると）、検索／クエリ関数およびそのほかそのような関連した読み込み関数である。検索／クエリ関数は、データが厳密に論理ブロックとして格納される場合に大容量メモリデバイスに適用されると、問題となり得る。例えば、カリフォルニア州ミルピタスにあるサンディスク  コーポレイションは、モバイルデバイス用の８ＧＢフラッシュメモリカードを現在販売し、１６ＧＢのサポートを発表した、世界的なフラッシュメモリベンダである。この容量は、時が経ち競争が大きくなるにつれてさらに大きく増大するばかりであると考えられる。このような、このサイズの大容量メモリは、文字通り何千ものイメージファイル（ＪＰＥＧ）、音楽ファイル（ＭＰ３）、または何百ものビデオファイル（ＭＰ４）を収容することができ、これを、コンピュータなどの外部システムから携帯コンシューマ電子機器へ、それぞれマイクロソフト  コーポレイション(Microsoft Corporation)による画像転送プロトコル（ＰＴＰ）またはメディア転送プロトコル（ＭＴＰ）などのオブジェクト転送プロトコルを使用して転送することができる。オブジェクトプロトコルは、デジタル写真またはＭＰ３音楽ファイルなど、所定量のデータを含むファイルを転送するのに特に適している。例えば、そのようなプロトコルは、デジタルカメラとＰＣとの間でデジタル写真を転送するため、またはホストコンピュータ（ＰＣなど）からＭＰ３プレーヤへＭＰ３音楽ファイルを転送するために使用されるとよい。なお、オブジェクト転送プロトコル（ＭＴＰなど）は、「書き込み関係」コマンド（例えば、ＣｏｐｙＯｂｊｅｃｔ、ＭｏｖｅＯｂｊｅｃｔなど）のほうにより焦点を合わせているが、「読み込み関係」コマンドも含んでいる（例えば、ＧｅｔＰａｒｔｉａｌＯｂｊｅｃｔ、ＧｅｔＯｂｊｅｃｔＰｒｏｐＶａｌｕｅなど）。
【０２２９】
格納されたデータファイルがそのように多数あると、いかなる検索／クエリ関数も、大量のプロセッサリソースを消費し、完了までに過度の時間を要する。従来の大容量記憶デバイスでは、コンテンツが論理ブロックの粒度で格納されるのに対して、検索／クエリ関数は、データがデータオブジェクトの粒度で格納されている場合のほうが効率的に実行可能なことから、これが特に当てはまる。例えば、データベース管理言語（例えば、ＳＱＬ）は、オブジェクトの粒度でデータのクエリおよび操作を行うのに特によく適している（例えば、リレーショナルデータベース管理システム、すなわちＤＢＭＳによりリレーショナル方式で編成されることが場合によって可能なデータのＳＱＬの場合であればＳＥＬＥＣＴコマンドによる読み出し）。補助サービスとの関連では、ホストプロセッサの処理リソースを最も消費するのは典型的に、検索／クエリ動作（すなわち、「読み込み関係」コマンド）であることから、クエリ言語（ＳＱＬなどのデータベース管理言語など）が携帯コンシューマ電子製品において、好適には例えばクエリ／検索などの読み込み動作を実行するために使用できれば、補助サービス（およびシステム全体）の性能の全体的な改善に役立つと考えられる。なお、さらに、ＳＱＬなどのデータゲース言語は「書き込み関係コマンド」（例えば、ＣＲＥＡＴＥ、ＡＬＴＥＲ、またはＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ）も含むが、携帯コンシューマ電子製品の性能改善との関連における、そのようなデータベース言語の最も有利な使用法は、クエリなどの読み込み関数の実行であると考えられる。
すべてのコンテンツを、論理ブロックではなくデータオブジェクトとして格納することが、この問題に対する対策であるように思われるかもしれないが、レガシー製品および設置基盤との下位互換性を保持するためには、「オブジェクト指向」パラダイムへの完全な切り替えは非生産的であり、かつ不要である。
【０２３０】
したがって、様々な実施形態に従い、ホストデバイスと通信しているローカル記憶デバイス（ＬＳＤ）のメモリアレイに格納されるコンテンツの二重表現を提供することによって、ホストデバイスコンピューティングリソースのより効率的な割り当てが実装される。二重表現とは、ＬＳＤに格納されているコンテンツが、論理ブロック表現（すなわち、レガシー大容量記憶装置インターフェイスを介してアクセス可能）と、データオブジェクトインターフェイスを介してアクセス可能でありオブジェクトまたはオブジェクトのプロパティを操作可能なオブジェクト表現との両方で提供されるということである。格納されているコンテンツの二重表現により、リクエスト元アプリケーションにとって最も適した形式でデータを提供することでホストアプリケーションの動作の合理化がもたらされる。さらに、論理ブロック表現とオブジェクト表現との間で、格納されているコンテンツの同期化を提供する同期化サービスが実行される。より詳しく言えば、同期化は、記憶アレイの一部分に格納されたオブジェクトプロパティ情報と、アレイの大容量記憶部分に格納された対応するオブジェクトとの同期化を提供する。したがって、論理ブロック表現およびデータオブジェクト表現としての両方で格納されているコンテンツの二重表現、ならびにオブジェクトプロパティが最新であることを保証する同期化サービスを提供するように論理的に設定されたメモリアレイが少なくとも提供される。
【０２３１】
このように、ホストアプリケーションの特定のコンポーネントの効率的な実行に関し、いずれか最適なほうの表現に容易にアクセス可能である。例えば、ホストデバイスがマルチメディアプレーヤであり、コアアプリケーションがＭＰ３デコーダであれば、ＭＰ３デコーダは、論理ブロックとして格納されているＭＰ３ファイルに優先的にアクセスすることになる。一方、マルチメディアプレーヤのユーザが、メモリアレイに格納されているすべての利用可能なオーディオファイルを検索したい場合には、検索アプリケーションが、例えばオブジェクトプロパティを頼りに、オブジェクトとして表現されている格納されたコンテンツを優先的に使用して、検索リクエストを完了することになる。なお、オブジェクト指向環境では、オブジェクトメタデータは、ヘッダ内など、オブジェクト自体の一部であると見なされるプロパティの所定のセットを指す。なお、記載される実施形態は、オブジェクト情報に加えて、オブジェクトの外部から定義でき（オブジェクトが格納されるＬＳＤによってなど）必ずしもオブジェクトとともに伝達されないオブジェクトプロパティも考慮する。例えば、オブジェクトがアクセスおよび／または再生された回数などが、オブジェクトプロパティと見なされ得る。
【０２３２】
格納されたコンテンツの二重表現は、論理ブロックの粒度ならびにオブジェクトの粒度でメモリアレイの大容量記憶部分に格納されたコンテンツを含むことができる。格納されているオブジェクトに関連したオブジェクトプロパティは、オブジェクト自体が格納されている部分とは論理的または物理的に切り離されている記憶アレイの部分に格納されることが可能である。例えば、オブジェクトは、記憶アレイの公開部分（すなわち、ＨＤＦＳが認識できる部分）とすることができ、その一方で、オブジェクトプロパティは、メモリアレイの非公開部分に格納されることが可能である。さらに、記載される実施形態は、ブロック表現で対応する同じコンテンツが格納されているオブジェクトに対応するオブジェクトプロパティの同期化を提供する。こうすることで、大容量記憶部分に格納されているオブジェクトは、メモリアレイの他の部分に格納された関連したオブジェクトプロパティ（ファイル、テーブルなどとして格納される）を有することができる。格納されているオブジェクトに対するあらゆる変更が、関連したプロパティに反映されるように保証するのが、同期化装置の機能である。
【０２３３】
図２６は、ホストデバイス（ＨＤ）６１０２およびローカル記憶デバイス（ＬＳＤ）６１０４を含むコンピューティングシステム６１００を示す。ＬＳＤ６１０４は、比較的小さな形態的要素を有するメモリカードなどのリムーバブルメモリデバイスという形をとることができ、カメラ、ハンドヘルドまたはノートブック形コンピュータ、ネットワークカード、ネットワークアプライアンス、セットトップボックス、ハンドヘルドまたはそのほかの小形オーディオプレーヤ／レコーダ（例えば、ＭＰ３デバイス）、および医療用モニタなどの電子製品のデジタルデータを格納するために使用可能である。メモリカードの例には、ＰＣカード（以前はＰＣＭＣＩＡデバイス）、フラッシュカード（例えば、コンパクトフラッシュタイプＩおよびＩＩ）、セキュアデジタル（ＳＤ）カード、マルチメディアカード（ＭＭＣ）、ＡＴＡカード（例えば、コンパクトフラッシュカード）、メモリスティック、ＳｍａｒｔＭｅｄｉａカードがある。さらに、ＬＳＤ６１０４は、カリフォルニア州ミルピタスのサンディスク  コーポレイションによって製造されたＳＤ対応のｉＮＡＮＤ（登録商標）を組み込んだフラッシュドライブなどの非リムーバブルメモリデバイスという形をとることができる。
【０２３４】
ＬＳＤ６１０４は、ＨＤ／ＬＳＤインターフェイス６１０６を経由してホストデバイス６１０２と通信することができる。なお、ＨＤ／ＬＳＤ６１０６は、ＨＤ６１０２およびＬＳＤ６１０４が機械的に接続することができる機械的エンティティ（ソケットまたは相互接続バスなど）として構成可能である。いくつかの実施形態では、ＨＤ／ＬＳＤ６１０６は、無線インターフェイスという形をとることができる。ＨＤ６１０２はプロセッサを含む。ただし、明瞭にするために、ＨＤ６１０２に含まれているプロセッサは、図に示されることも、この説明の中でさらに言及されることもないが、それでもなお存在しているものと想定される。典型的には、ＬＳＤ６１０４は、ＨＤ６１０２によって提供される当該インターフェイス以外には、ＨＤ６１０２の外部のデバイスに対する何らのインターフェイスも利用しない。
【０２３５】
ＨＤ６１０２は、レガシー大容量記憶パス６１０７を含む。レガシー大容量記憶パス６１０７は、レガシー大容量記憶装置ドライバ６１１０と通信しているホストデバイスファイルシステム６１０８（典型的にはホストデバイスオペレーティングシステム（ＨＤＯＳ）の一部）を含む。なお、ＨＤＦＳ６１０８は、様々なファイルシステムに基づいて動作するように設定可能である。例えば、ＨＤＦＳ６１０８は、ファイルアロケーションテーブル（ＦＡＴ）ベースのファイルシステムとすることができる。一方、他の実施形態では、ＨＤＦＳ６１０８は、特にｅｘｔ２、ｅｘｔ３、ＮＴＦＳ、およびＪＦＦＳに基づくファイルシステムとしてもよい。したがって、記載される実施形態は、他のファイルシステムを用いて実施されてもよいが、以下の記載は、ＦＡＴベースのファイルシステムの実施形態に焦点を合わせる。例として、ＦＡＴファイルシステムは、当該技術分野で既知であるＦＡＴ１６またはＦＡＴ３２ファイルシステムとするとよい。
【０２３６】
記載される実施形態では、ＨＤＦＳ６１０８は、大容量記憶パスを使用してＬＳＤ６１０４へＬＳＤブロックコマンド６１１２を発行することができ、この大容量記憶パスは、論理インターフェイスの形をとってもよいし、あるいは大容量記憶パス６１０７などの物理インターフェイスとしての形をとってもよい。次に、レガシー大容量記憶装置ドライバ６１１０が、ＬＳＤブロックコマンド６１１２を、ＨＤ／ＬＳＤインターフェイス６１０６を経由してＬＳＤ６１０４に渡すことができる。ＬＳＤ６１０４に格納されているデータのオブジェクト表現を利用するためには、ＨＤ６１０２は、オブジェクト関連コマンド６１１３をＨＤ／ＬＳＤ記憶装置（物理）インターフェイス／バス６１０６上でＬＳＤ６１０４に伝達するように構成されたオブジェクトベース（ＯＢ）のインターフェイス６１０９（論理インターフェイスまたは物理インターフェイスのいずれかとして構成可能）を利用することができる。ＯＢインターフェイス６１０９は、ドライバレベルまたはＯＳレベルで、あるいはアプリケーションレベルでも（この場合、部分的に大容量記憶パス６１０７を使用することになる）統合可能であると考えられる。記載される実施形態では、ＯＢインターフェイス６１０９は、論理ＩＰ（インターネットプロトコル）ネットワークインターフェイスを利用することができ、この場合、ＯＢインターフェイス６１０９は、通常ＩＰ上に定義されるアプリケーション、オブジェクトベースプロトコル（例えば、ＳＱＬオーバーＩＰまたはＭＴＰオーバーＩＰなど）を伝達することができる。
【０２３７】
ＨＤ６１０２は、ホストアプリケーション６１１４も含むことができ、ホストアプリケーション６１１４は、ＨＤＦＳ６１０８およびレガシー大容量記憶装置ドライバ６１１０を利用してＬＳＤ６１０４と通信できる。ホストアプリケーション６１１４は、コアサービス（メディアファイルの再生、イメージの表示など）を提供するように構成されたコアアプリケーション６１１８と、補助サービス（キーワード検索、プレイリストの変更など）を提供するように構成された補助サービスアプリケーション６１２０とを含むことができ、補助サービスは、ＬＳＤ６１０４に格納されているコンテンツの管理および／または実行においてホストアプリケーション６１１４を支援するために使用可能である。なお、補助サービスは、ホストアプリケーション６１１４からのサポートなしにＬＳＤ６１０４から実行することもできる。こうすることで、ＬＳＤ６１０４は、それ用の補助サービスのセットを、ＨＤ６１０２から独立して提供することも、適切と判断された場合にＨＤ６１０２をサポートして提供することもできる。なお、さらに、そのような補助サービスは、本願明細書に記載されたアーキテクチャの任意のレベルで動作することができる。例えば、アプリケーション６１２０がオペレーティングシステム（ＯＳ）の一部であることも十分にあり得る。さらに、アプリケーション６１２０を、ＬＳＤ６１０４内の格納されているデータのオブジェクトベース表現を使用するリモートアプリケーションとすることができ、その場合、アプリケーション６１２０は、リモートデバイス、またはＬＳＤ６１０４とは切り離されているがＨＤ６１０２／ＬＳＤ６１０４と通信している別のＬＳＤに存在することができる。
【０２３８】
ＬＳＤ６１０４は、コントローラ６１２２と、少なくとも第１の部分６１２６および第２の部分６１２８を含むように設定された（論理的または物理的のいずれか）記憶アレイ６１２４とを含むことができる。なお、記憶アレイ６１２４は、メモリセル（フラッシュメモリセルなど）のアレイから形成可能である。この特定の場合には、記憶アレイ６１２４は、フラッシュメモリセルのアレイと想定されることが可能であるとはいえ、実施形態は、任意の適切なタイプのメモリセルとともに使用可能であると考えられ、そのため実施形態はフラッシュタイプのメモリセルのみに限定されない。コントローラ６１２２は、ＨＤＦＳ６１０８の命令通りに機能し、少なくとも第１の部分６１２６を管理することができるフラッシュマネージャ６１３０を含むことができる。特に有用な構成では、データは、ＬＢＡプロトコルを使用して第１の部分６１２６に格納可能である。したがって、大容量記憶エリア６１２６に格納されるデータのブロックの位置は、ＬＢＡプロトコルを使用して指定することができ、各ブロックは、例えばそれぞれ５１２または１，０２４バイトのオーダとすることができる。こうすることで、大容量記憶エリア６１２６は、任意の考えられるレガシー大容量記憶装置のアーキテクチャと完全な下位互換性を持つことができる（すなわち、レガシーホストとともに機能できる）。したがって、ＬＳＤ６１０４は、レガシーインターフェイス、バス、およびすべての関連したプロトコルを使用して動作し、レガシー製品の設置基盤との完全な互換性を提供することができる。このように、大容量記憶エリア６１２６は、データオブジェクトまたは論理データブロックとして表されるデータの格納に使用されることが可能である。
【０２３９】
コントローラ６１２２は、第２の部分６１２８にオブジェクト管理サービスを提供するように構成されたオブジェクトベース管理システム（ＯＢＭＳ）６１３２を含むことができ、これを使用して、大容量記憶エリア６１２６に格納されたデータオブジェクト６１３６を表しそれに対応するデータオブジェクトプロパティ情報６１３４の、格納および読み出しを行うことができる。そのようなＯＢＭＳ６１３２の典型的な例は、データベース（ＤＢ）内のデータの編成、記憶、管理および読み出しを制御するように設計されたデータベース管理システム（ＤＢＭＳ）とすることができる。ＯＢＭＳは、任意のＤＢクエリ／管理言語（ＳＱＬなど）に応答することができる。したがって、オブジェクトを、ＤＢのフォーマットに従って、すなわち特にデータ構造として（すなわち、フィールド、レコード、ファイルおよびオブジェクト）エリア６１２６に格納することができる。論理オブジェクト管理レイヤをフラッシュマネージャ６１３０の上に提供することによって、ＯＢＭＳ６１３２は、エリア６１２６および６１２８にアクセスするため／それを管理するためにフラッシュマネージャ６１３０を利用することができる。しかし、いくつかの実施形態では、ＯＢＭＳ６１３２は、フラッシュマネージャ６１３０から切り離された、それ専用のフラッシュ管理レイヤを組み込むことができる。
【０２４０】
ＯＢＭＳ６１３２によって提供されるオブジェクト管理サービスは、メモリ記憶エリア６１２６に格納されているデータオブジェクト６１３６に関連したオブジェクトプロパティ情報の読み出しおよび格納を含むことができる。データオブジェクト情報は、データオブジェクト情報データセットを含むことができる。さらに、エリア６１２６に格納されているオブジェクトに関連したクラスタ／ブロックの位置も、エリア６１２８に格納可能なオブジェクトプロパティの一部と見なすことができる。説明された実施形態では、データオブジェクト情報データセットは、オブジェクト６１３６のコアプロパティの概要を提供することができる。こうしたコアプロパティは、例えば、オブジェクト６１３６のデータコンポーネントのサイズと、各データオブジェクトの関連付けならびにデバイス上の階層ファイルシステムの記述に使用可能なオブジェクトの関連付けとを含むことができる。なお、データオブジェクトプロパティは、オブジェクト自体とは別に、オブジェクト記述情報を交換するためのメカニズムを提供することができる。オブジェクトプロパティの利点の１つは、ファイルシステムにかかわらず、大きな記憶内容を迅速に列挙できるようにすることである。
【０２４１】
大容量記憶エリア６１２６に格納されているオブジェクトが、エリア６１２８に一貫性のあるオブジェクト表現を確実に有するように、同期化装置６１３８（ＬＳＤ６１０４またはＨＤ６１０２に存在することができる）を使用して、大容量記憶エリア６１２６に格納されている更新されたオブジェクトに対応する、エリア６１２８に格納されているオブジェクトプロパティを更新することができる。更新とは、大容量記憶エリア６１２６に格納されている（または格納されるべき）データファイルに関して、またはそれに対して実行可能な、データオブジェクトに関連した任意の特徴を修正または変更する任意の動作のことである。なお、ＯＢＭＳ６１３２によって管理され、「オブジェクト表現」を介して提供されるプロパティ（すなわち、同期化装置６１３８によって処理される）の数および性質は、補助アプリケーション６１２０またはＬＳＤ６１０４自体のいずれかによって、または両方によって定義可能である。さらに、ＯＢＭＳ６１３２によって管理されるオブジェクトプロパティは、オブジェクト自体に応じて異なる。そのようなオブジェクトプロパティは、例えば、名前、サイズ、一部のものについては作者、他のものについてはユーザ生成のタグ、およびコンテンツ再生回数を含むことができる。なお、コンテンツがＨＤ６１０２またはＬＳＤ６１０４などによって特定されると、そのコンテンツに関連した情報の種々のセットを、ＯＢＭＳ６１３２によって管理することが可能である。
【０２４２】
同期化装置６１３８は、双方向同期化動作と呼ばれるものを実行することができる。例えば、大容量記憶パス６１０７を介して伝達される大容量記憶エリア６１２６に対する書き込みコマンドは、オブジェクト（ＯＢ）パス６１１１を介した読み込みおよび／または操作に利用可能な、新規オブジェクトまたは更新されたオブジェクトをもたらすことができる。さらに、ＯＢインターフェイス６１０９を経由して伝達される書き込み関係コマンド（例えば、オブジェクトの更新または移動）は、大容量記憶パス６１０７を介した読み込みまたは操作に利用可能となり得る。その結果、ＯＢインターフェイス６１０９を経由して伝達される（少なくともドライバ６１１０を使用して）「書き込み」ベースのコマンド（例えば、オブジェクトの変更、オブジェクトの移動）は、同期化装置６１３８によってエリア６１２８と同期されることが可能である。
【０２４３】
したがって、書き込み関係コマンド（例えば、オブジェクトの変更または移動）が、ＯＢパス６１０９を介して、ＯＢパス６１１１を使用しＬＳＤ６１０４へ伝達されると、オブジェクトは、大容量記憶エリア６１２６に書き込まれることが可能であると同時に、同期化装置６１３８によってエリア６１２８において対応するプロパティが更新される。しかし、エリア６１２６は、ＨＤＦＳ６１０８によって管理される（任意のＦＡＴ情報をＨＤ６１０２上にキャッシュすることを含む管理）ことから、ＨＤＦＳ６１０８は、エリア６１２６上において内部で生じるいかなる変更も感知しないことになる。したがって、オブジェクトが大容量記憶エリア６１２６に書き込まれるときに、プロパティが最終的にエリア６１２８において同期されることを確実にするために、ＨＤＦＳ６１０８によって認識される大容量記憶エリア６１２６に位置する所定サイズのプレースホルダを使用した内部書き込みコマンドを使用可能である。
【０２４４】
図２７は、説明された実施形態に従った同期化装置６１３８の特定の実施形態を示す。同期化装置６１３８は、ＨＤ６１０２とＬＳＤ６１０４との間の大容量記憶パスに結合可能であり、従って、ＨＤ６１０２からＬＳＤ６１０４へ渡されるあらゆるＬＳＤブロックコマンド６１１２を確認することができる。説明された実施形態では、ＬＳＤブロックコマンド６１１２は、データ部分６２０２に情報およびデータを含むことができ、コントローラ６１２２に、実行されるべき動作（読み込み、書き込み、コピーなど）のタイプで命令するコマンド命令部分６２０４を含むことができるＦＡＴブロックベースのコマンドである。同期化装置６１３８は、オブジェクトの顕著なプロパティを抽出するように構成されたオブジェクトプロパティ抽出ユニット６２１０を少なくとも含むことができる。抽出ユニット６２１０は、適切なオブジェクトプロパティ（ファイル名、フォーマット、ファイルサイズなど）を抽出することができ、これは情報ユニット６２１２に渡される。更新された情報はいつでもＯＢＭＳ６１３２に渡されることが可能であり、その結果として、ＯＢＭＳ６１３２は、エリア６１２８内の適切なデータオブジェクトプロパティを特定しかつ更新する。
【０２４５】
さらに、データが大容量記憶エリア６１２６に書き込まれるとき、同期化装置６１３８は、大容量記憶エリア６１２６に書き込まれるデータの「ＦＡＴ構造」を理解することから、同期化装置６１３８は、ＬＳＤブロックコマンド６１１２を確認して、オブジェクトプロパティを「オンザフライ」で特定および更新することができる。例えば、データ抽出ユニット６２１０は、使用データコレクタ６２１０という形をとることができる。使用データコレクタ６２１０は、コマンド６１１２を確認し、それに基づき、例えば記憶エリア６１２８内にプロパティとして格納されるべき、使用カウンタなどのデータアクセス特徴付けを判断することができる。コマンド６１１２は、ＨＤＦＳ６２０８の命令通りに機能する、コントローラ６１２２のフラッシュマネージャ６１３０に提供されるが、他の例では、ＨＤＦＳ動作の結果としてではないコマンドまたは他の信号が、ＨＤ６１０２からＬＳＤ６１０４へ提供される。例えば、そのようなコマンドまたは他の信号は、ＨＤＦＳ動作の結果としてではないドライバレベルの動作など、他の動作に基づいて提供されるとよい。データアクセス特徴付け６２０６は、使用データコレクタ６２１０によって、データアクセスを特徴付けるべく、読み込みおよび／または書き込み動作の頻度に基づき推論されるとよい。いずれの場合でも、同期化装置６１３８は、非同期的にまたはバックグラウンドで動作し、エリア６１２６から読み込みを行って同期化が必要な任意のプロパティを特定することができる。
【０２４６】
図２８は、コアサービス（ＭＰ３ファイルの読み込みなど）を実行するコアアプリケーション６１１８を示し、これは、大容量記憶パス６１０７を経由してＬＳＤ６１０４へ伝達される読み込みコマンド６３０２により、大容量記憶エリア６１２６に格納されているデータを読み込むことを必要とする。同期化装置６１３８は、アクセスされたオブジェクトのプロパティが変更されていないことから、その結果ＯＢＭＳ６１３２によってエリア６１２８内の対応するプロパティを更新する必要がないと判断する（例えば、カウンタが更新されない限り）。
【０２４７】
図２９は、ＨＤ６１０２が、大容量記憶パス６１０７を経由してＬＳＤ６１０４へ伝達される書き込みコマンド６４０２（または、大容量記憶エリア６１２６内に格納されているオブジェクトの変更をもたらすことになる他の任意のコマンド）を発行した状況を示す。同期化装置６１３８は、大容量記憶エリア６１２６内のオブジェクトに関連したプロパティが、コマンド６１０８の実行によって変更されることを確認し、ＯＢＭＳ６１３２にエリア６１２８に格納されているオブジェクトプロパティを更新させることによって応答する。なお、同期化装置６１３８は、大容量記憶エリア６１２６を周期的および定期的に読み込んで、そこに格納されているオブジェクトに何らかの変更が生じたかどうかを判断することによって、大容量記憶エリア６１２６内のコンテンツのステータスを定期的に確認（例えば、バックグラウンドで）することもできる。いくつかの実施形態では、同期化装置６１３８は、大容量記憶エリア６１２６へのアクセスのパターンを特定し、そのパターンに基づき、大容量記憶エリア６１２６に格納されているオブジェクトのプロパティを推定することができる。いずれの場合でも、ＯＢＭＳ６１３２は、記憶エリア６１２８に格納されている適切なオブジェクトプロパティを更新する。
【０２４８】
図３０は、記載される実施形態のうちの１つに従ったプロセス６５００を表すフローチャートを示す。プロセス６５００は、６５０２にて、データ記憶アレイを提供することによって開始する。次に６５０４にて、論理データブロック形式のデータがデータ記憶アレイに提供される。６５０６にて、論理データブロックが第１の論理インターフェイスによって管理される。６５０８にて、論理データブロックに対応するデータオブジェクトが、データ記憶アレイに提供される。６５１０にて、データオブジェクトが第２の論理インターフェイスによって管理される。６５１２にて、論理データブロックとして格納されたデータが、第１のインターフェイスによって変更される。６５１４にて、変更されたデータが第２のインターフェイスおよび第１のインターフェイスを経由してアクセス可能になる。６５１４と同時に、６５１６にて、オブジェクトプロパティの所定のセットが管理される。
【０２４９】
図３１は、ホストデバイス２０４において典型的に見られる追加コンポーネントを示す典型的なシステム９００を示す。システム９００は、中央処理装置（ＣＰＵ）９１０、ランダムアクセスメモリ（ＲＡＭ）９２０、読み出し専用メモリ（ＲＯＭ）９３０、ならびに一次記憶デバイス９４０および９５０を含む。当該技術分野で周知のように、ＲＯＭ９３０は、データおよび命令を一方向にＣＰＵ９１０へ転送するように機能し、ＲＡＭ９２０は典型的に、データおよび命令を双方向の形で転送するように使用される。ＣＰＵ９１０は、一般的に任意の数のプロセッサを含むとよい。一次記憶デバイス９４０および９５０はどちらも、任意の適切なコンピュータ可読媒体を含むとよい。ＣＰＵ９１０はさらに、コンピュータハードウェアおよびソフトウェア技術の当業者にはよく知られている１つ以上の入出力デバイス９６０に結合される。
【０２５０】
記載される実施形態では、モバイルデバイス（例えば、携帯メディアデバイス）は互いに通信することができる。このタイプの通信は、ピアツーピア対話と呼ぶことができる。その際、１つのモバイルデバイスは、別のモバイルデバイスと直接通信することができる（例えば、ユニキャスト）。別の例では、１つのモバイルデバイスが複数の他のモバイルデバイスに通信することができる（例えば、ブロードキャスト、エニーキャスト、またはマルチキャスト）。ピアツーピア環境では、１つのモバイルデバイスが、すぐ近くの１つ以上の他の電子デバイス（モバイルでも固定されたものでも）と通信することができる。そのような通信が利用可能なとき、データ共有を実行可能である。
【０２５１】
データ転送は、モバイルデバイスと、ホームコンピュータまたは別のモバイルデバイスなどのコンピューティングデバイスとの間であってもよい。典型的には、モバイルデバイスおよびコンピューティングデバイスは、特定のユーザに関連すると考えられる。例えば、モバイルデバイスがホームコンピュータ（またはホームネットワーク）の範囲内にあると、モバイルデバイスとホームコンピュータとの間でデータ転送の実行が可能である。データ転送は、２つ以上のモバイルデバイス間、または２つ以上の非モバイルデバイス間でも可能である。データ転送は、何らのユーザアクションもなく自動とすることもできるし、もう１つの方法として、ユーザによる手動の承認を必要とすることもできる。ネットワークデバイスを、識別番号またはそのほかの適切なメカニズムによって互いに関連付けることが可能である。
【０２５２】
データの受信、伝送および／または格納ができるモバイルデバイスまたは非モバイルデバイスは「データデバイス」と呼ぶこともできる。データがデータデバイスに到着する方法は実施例によって決まるとよい。例えば、データがデータデバイスに直接転送されてもよいし、あるいはデータがデータデバイスに間接的に転送されてもよい。例えば、データ転送は、１つのデータデバイスともう１つのデータデバイスとの間であってもよい。あるいは、１つのデータデバイスがもう１つのデータデバイスに、所望のデータを受信側のデータデバイスへ転送させてもよい。
【０２５３】
共有データは、ファイル転送またはストリーミングによって受信側のデバイスへ転送可能である。転送されたデータは、１つ以上のデータデバイスにより受信可能である。データデバイスの例には、メディアプレーヤ、ＰＤＡ、スピーカユニット、無線送受信ユニットなどが含まれる。データデバイスのユーザは、コンテンツを作成してデータ共有によって配布することもできる。ストリーミングは、同時にデータを受信するデータデバイス数を制限するように限定することができる。その一方で、データデバイスのユーザがストリーミングコンテンツへの加入者であれば（すなわち、加入している）、加入者に関してストリーミングを無制限とすることができる。メディア項目メタデータに関連付けられたメディア項目コンテンツのある一部の管理（格納を含む）も、メディア項目コンテンツのストリーミングを促進するために行われるとよい。例えば、ユーザは、メディア項目コンテンツの以前に格納された当該部分の再生を、残りのコンテンツのストリーミングが開始してもいないうちから開始することが可能である。
【０２５４】
データは、購入後に共有可能である。例えば、受信側がデータをリモートサーバから購入することができる。その結果、リモートサーバは、購入されたデータを受信側のデータデバイスに配信させる。購入を、リアルタイムで実行することも可能であるし、後の時点まで保留することも可能である。その後、購入されたデータを、受信側のデータデバイスから別のデータデバイスへと共有することが可能である。
【０２５５】
例えば、職場環境または他のネットワーク環境において、ユーザが雇用主の事務所に仕事のために入ってくるときに、ユーザのモバイルデバイスが、ユーザの仕事用コンピュータまたは事務所のネットワークサーバにデータを転送することができる。データ転送は、何らのユーザアクションもなく自動としたり、または代わりに、ユーザによる手動の承認を必要としたりすることができる。モバイルデバイスのユーザは、同僚またはネットワークのそのほかのユーザのモバイルデバイスと通信して、データを交換することもできる。
【０２５６】
特定の環境にかかわらず、データ転送は無線とすることができる。無線データ転送を、無線ネットワークによって促進することが可能である。１つのモバイルデバイスが、１つのモバイルデバイスから別のモバイルデバイスまたは固定されたコンピューティングデバイスへ、ユニキャスト方式でデータを無線で伝送することができる。さらに加えて、１つのモバイルデバイスが、データを、マルチキャストまたはブロードキャスト方式で、複数の他のモバイルデバイスに無線で伝送することができる。なお、任意のホームサーバコンピュータが、コンピューティングデバイス２００が属するネットワーク内のいくつかの他のデータ記憶デバイスのいずれかに存在することができる。
【０２５７】
本発明の利点は多数ある。種々の実施形態または実施例が、以下の利点の１つ以上を生じさせると考えられる。本発明の利点の１つは、システムハードウェアの変更を考えることなく、レガシーデバイスを追加または除去できることである。本発明の別の利点は、本発明が変更なしで任意のホストコンピュータとともに使用可能であり、したがってコストが削減され、本発明の適用性が高くなっていることである。本発明の別の利点は、ＬＳＤ内のデータに、ＨＤの機能性の変更を考えることなくインデックス付け可能であることである。さらに、ＬＳＤが複数のＨＤとともに使用されている場合でも、インデックスを特定のＬＳＤに関連付けることが可能である。
【０２５８】
本発明の多数の特徴および利点は、記載されている説明から明らかであり、したがって、添付の特許請求の範囲により、本発明のそのような特徴および利点のすべてが網羅されるものとする。さらに、当業者であれば、多数の変更および変化に容易に気づくと考えられることから、本発明を図に示しかつ記載された厳密な構造および動作に制限することは望まれていない。したがって、適切な変更および等価物はすべて、本発明の範囲に入るものとして用いられるとよい。
【図１】
2011513804.tif 000003
【図２Ａ】
2011513804.tif 000004
【図２Ｂ】
2011513804.tif 000005
【図２Ｃ】
2011513804.tif 000006
【図３Ａ】
2011513804.tif 000007
【図３Ｂ】
2011513804.tif 000008
【図４】
2011513804.tif 000009
【図５Ａ】
2011513804.tif 000010
【図５Ｂ】
2011513804.tif 000011
【図６】
2011513804.tif 000012
【図７】
2011513804.tif 000013
【図８】
2011513804.tif 000014
【図９】
2011513804.tif 000015
【図１０】
2011513804.tif 000016
【図１１】
2011513804.tif 000017
【図１２Ａ】
2011513804.tif 000018
【図１２Ｂ】
2011513804.tif 000019
【図１３】
2011513804.tif 000020
【図１４Ａ】
2011513804.tif 000021
【図１４Ｂ】
2011513804.tif 000022
【図１５】
2011513804.tif 000023
【図１６】
2011513804.tif 000024
【図１７】
2011513804.tif 000025
【図１８】
2011513804.tif 000026
【図１９】
2011513804.tif 000027
【図２０】
2011513804.tif 000028
【図２１】
2011513804.tif 000029
【図２２】
2011513804.tif 000030
【図２３】
2011513804.tif 000031
【図２４】
2011513804.tif 000032
【図２５】
2011513804.tif 000033
【図２６】
2011513804.tif 000034
【図２７】
2011513804.tif 000035
【図２８】
2011513804.tif 000036
【図２９】
2011513804.tif 000037
【図３０】
2011513804.tif 000038
【図３１】
2011513804.tif 000039
【手続補正書】
【提出日】平成22年10月26日(2010.10.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピューティングシステムであって、
ホストデバイス（ＨＤ）と、
前記ＨＤによって管理されるローカル記憶デバイス（ＬＳＤ）であって、前記ＬＳＤは、前記ＨＤによって提供されるインターフェイス以外には前記ＨＤの外部にあるデバイスに対する何らのインターフェイスも利用せず、またＬＳＤ論理リクエストを使用して、前記ＬＳＤと起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示することで、前記ＨＤにリクエストされたプロセスを実行するように間接的に指示し、前記ＬＳＤおよび前記起動アプリケーションは前記ＨＤによる介入なしに前記通信パス上で論理的に対話し、前記論理的対話は前記リクエストされたプロセスを前記ＨＤが実行するように前記起動アプリケーションに指示させ、前記ＬＳＤ論理リクエストはＨＤによって開始されたプロセスに役立つように作成されたものではないローカル記憶デバイス（ＬＳＤ）と、
を備えるコンピューティングシステム。
【請求項２】
請求項１記載のコンピューティングシステムにおいて、
前記ＨＤと前記ＬＳＤとの間の通信パスを提供するＨＤ／ＬＳＤインターフェイスと、
前記ＨＤ内にあり、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）と、
前記ＬＳＤ内にあり、少なくとも前記ＨＤＦＳによって管理される少なくとも１つの記憶エリアであって、前記ＨＤＦＳは、前記ＨＤ／ＬＳＤインターフェイスを経由して前記少なくとも１つの記憶エリアに渡されるブロックコマンドを生成することによって、前記少なくとも１つの記憶エリアを管理するものである少なくとも１つの記憶エリアと、
をさらに備えるコンピューティングシステム。
【請求項３】
請求項１または２記載のコンピューティングシステムにおいて、
前記ＬＳＤは、
前記ＨＤが前記ＬＳＤにポーリングを行っていれば、前記ＬＳＤが前記ＬＳＤ論理リクエストを用いて前記ＨＤのポーリングに応答する方法であって、前記ＨＤのポーリングはＨＤＦＳにより開始されたプロセスまたはＬＳＤドライバにより開始されたプロセスのいずれからも独立している方法か、
別の方法として、前記ＬＳＤ論理リクエストを生成し、前記ＬＳＤ論理リクエストとＬＳＤ割り込み信号とを関連付け、前記ＨＤ宛てにＬＳＤ割り込みを発生させる方法か、
のいずれかによって、前記ＬＳＤ論理リクエストを使用して、前記ＬＳＤと前記起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示するコンピューティングシステム。
【請求項４】
請求項２または３記載のコンピューティングシステムにおいて、
前記ＬＳＤ論理リクエストは、前記ＨＤと、前記ＨＤおよび前記ＬＳＤの外部にありネットワークに含まれるデバイスに関連したリモート起動アプリケーションとの間に、ネットワークインターフェイスを利用してネットワークリンクとして通信パスを提供するように前記ＨＤに指示するか、または前記ＬＳＤと、前記ＬＳＤの外部にあるローカルデバイスに関連したローカル起動アプリケーションとの間に、前記ネットワークリンクではないローカル通信パスとして通信パスを提供するように前記ＨＤに指示するコンピューティングシステム。
【請求項５】
請求項１〜４のいずれか記載のコンピューティングシステムにおいて、
前記ローカルデバイスは前記ＨＤにより管理されるＳＩＭカードであり、前記ＳＩＭカードは、ＳＩＭアプリケーションツールキットコマンドセットに準拠するか、またはＵＳＩＭアプリケーションツールキットコマンドセットに準拠するコンピューティングシステム。
【請求項６】
請求項１〜５のいずれか記載のコンピューティングシステムにおいて、
前記ＨＤおよび前記ＬＳＤの外部にあるデバイスは、ネットワークデバイス（ＮＤ）であるコンピューティングシステム。
【請求項７】
請求項６記載のコンピューティングシステムにおいて、
前記ネットワークがＩＰプロトコルベースのネットワークであるならば、前記ＬＳＤおよび前記ＳＩＭカードはそれぞれＬＳＤ  ＩＰアドレスおよびＳＩＭ  ＩＰアドレスを付与され、前記ＨＤはＨＤ  ＩＰアドレスを付与され、前記ＮＤはＮＤ  ＩＰアドレスを付与されるコンピューティングシステム。
【請求項８】
請求項７記載のコンピューティングシステムにおいて、
前記リクエストされたプロセスは前記ＬＳＤをポイントするブラウザアプリケーションを起動するためのブラウザアプリケーションの起動であり、前記ブラウザアプリケーションの起動はユーザ入力を受け取るように構成されたユーザインターフェイス（ＵＩ）を開くコンピューティングシステム。
【請求項９】
請求項８記載のコンピューティングシステムにおいて、
前記ブラウザアプリケーションは、前記ＬＳＤと前記ＵＩとの間の論理的対話を促進し、その結果、前記ＬＳＤにユーザに対する直接アクセスを提供するコンピューティングシステム。
【請求項１０】
ホストデバイス（ＨＤ）と前記ＨＤによって管理されるローカル記憶デバイス（ＬＳＤ）とを有するコンピューティングシステムにおいて、リクエストされたプロセスを実行するように間接的に前記ＨＤに指示する方法であって、前記ＬＳＤは、前記ＨＤによって提供されるインターフェイス以外には前記ＨＤの外部にあるデバイスに対する何らのインターフェイスも利用しないものである前記方法において、
ＨＤによって開始されたプロセスに役立つように作成されたものではないＬＳＤ論理リクエストを使用して、前記ＬＳＤと起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示するステップと、
前記ＨＤによる介入なしに前記通信パス上で論理的に対話するステップと、
前記リクエストされたプロセスを前記ＨＤが実行するように前記起動アプリケーションに指示させるステップと、
前記リクエストされたプロセスを実行するステップと、
を含む方法。
【請求項１１】
請求項１０記載の方法において、
前記コンピューティングシステムは、
前記ＨＤと前記ＬＳＤとの間の通信パスを提供するＨＤ／ＬＳＤインターフェイスと、
前記ＨＤ内にあり、ブロックコマンドを生成するように構成されたホストデバイスファイルシステム（ＨＤＦＳ）と、
前記ＬＳＤ内にあり、少なくとも前記ＨＤＦＳによって管理される少なくとも１つの記憶エリアであって、前記ＨＤＦＳは、前記ＨＤ／ＬＳＤインターフェイスを経由して前記少なくとも１つの記憶エリアに渡されるブロックコマンドを生成することによって、前記少なくとも１つの記憶エリアを管理するものである少なくとも１つの記憶エリアと、
をさらに備える方法。
【請求項１２】
請求項１１記載の方法において、
前記ＬＳＤは、
前記ＨＤが前記ＬＳＤにポーリングを行っていれば、前記ＬＳＤが前記ＬＳＤ論理リクエストを用いて前記ＨＤのポーリングに応答する方法であって、前記ＨＤのポーリングはＨＤＦＳにより開始されたプロセスのいずれからも独立している方法か、
別の方法として、前記ＬＳＤ論理リクエストを生成し、前記ＬＳＤ論理リクエストとＬＳＤ割り込み信号とを関連付け、前記ＨＤ宛てにＬＳＤ割り込みを発生させる方法か、
のいずれかによって、前記ＬＳＤ論理リクエストを使用して、前記ＬＳＤと前記起動アプリケーションとの間に通信パスを確立するように前記ＨＤに指示する方法。
【請求項１３】
請求項１２記載の方法において、
前記ＬＳＤ論理リクエストは、前記ＨＤと、前記ＨＤおよび前記ＬＳＤの外部にありネットワークに含まれるデバイスに関連した前記起動アプリケーションとの間に、ネットワークインターフェイスを利用してネットワークリンクとして通信パスを提供するように前記ＨＤに指示するか、または前記ＬＳＤと、前記ＬＳＤの外部にあるローカルデバイスに関連したローカル起動アプリケーションとの間に、前記ネットワークリンクではないローカル通信パスとして通信パスを提供するように前記ＨＤに指示する方法。
【請求項１４】
請求項１３記載の方法において、
前記ＨＤおよび前記ＬＳＤの外部にあるデバイスはネットワークデバイス（ＮＤ）であり、前記ネットワークがＩＰプロトコルベースのネットワークであるならば、前記ＬＳＤおよびＳＩＭカードはそれぞれＬＳＤ  ＩＰアドレスおよびＳＩＭ  ＩＰアドレスを付与され、前記ＨＤはＨＤ  ＩＰアドレスを付与され、前記ＮＤはＮＤ  ＩＰアドレスを付与される方法。
【請求項１５】
請求項１４記載の方法において、
前記リクエストされたプロセスは前記ＬＳＤをポイントするブラウザアプリケーションを起動するためのブラウザアプリケーションの起動であり、前記ブラウザアプリケーションは、ユーザ入力を受け取るように構成されたユーザインターフェイス（ＵＩ）を開き、また前記ＬＳＤと前記ＵＩとの間の論理的対話を促進し、その結果、前記ＬＳＤにユーザに対する直接アクセスを提供する方法。
【国際調査報告】
2011513804.tif 000040
2011513804.tif 000041
2011513804.tif 000042
2011513804.tif 000043
2011513804.tif 000044
2011513804.tif 000045
2011513804.tif 000046