(57)【要約】  装置は、第１記憶媒体、入出力アーキテクチャ、第２記憶媒体及びプロセッサを有する。プロセッサは、前記第１記憶媒体に格納されているファイルにアクセスするリクエストに応答して、前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出し、前記ファイルの第１部分を送信し、前記ファイルの第２部分を前記第２記憶媒体に格納するよう構成される。
2008521264.tif 000002
【特許請求の範囲】
【請求項１】
第１記憶媒体、入出力アーキテクチャ、第２記憶媒体及びプロセッサを有する装置であって、
前記プロセッサは、前記第１記憶媒体に格納されているファイルにアクセスするリクエストに応答して、前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出し、前記ファイルの第１部分を送信し、前記ファイルの第２部分を前記第２記憶媒体に格納するよう構成される装置。
【請求項２】
前記入出力アーキテクチャは、トランシーバを有する、請求項１記載の装置。
【請求項３】
当該装置は、第２装置から前記第１記憶媒体に格納されている前記ファイルにアクセスするリクエストを無線受信する、請求項２記載の装置。
【請求項４】
前記プロセッサはさらに、前記ファイルのデータレートを確認するため、前記第１記憶媒体から前記ファイルを呼び出す前に、前記ファイルのメタデータにアクセスするよう構成される、請求項１乃至３何れか一項記載の装置。
【請求項５】
前記第１記憶媒体は、ハードディスクドライブを有する、請求項１乃至４何れか一項記載の装置。
【請求項６】
前記第２記憶媒体は、ソリッドステートメモリを有する、請求項１乃至５何れか一項記載の装置。
【請求項７】
前記プロセッサはさらに、リクエストに応答して、前記ファイルの第２部分を送信するよう構成される、請求項１乃至６何れか一項記載の装置。
【請求項８】
当該装置は、携帯電話機を有する、請求項１乃至７何れか一項記載の装置。
【請求項９】
当該装置は、モバイル音声／映像サーバを有する、請求項１乃至７何れか一項記載の装置。
【請求項１０】
装置の動作方法であって、
第１記憶媒体に格納されているファイルにアクセスするリクエストを受け付けるステップと、
前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出すステップと、
前記ファイルの第１部分を送信するステップと、
前記ファイルの第２部分を第２記憶媒体に格納するステップと、
を有する方法。
【請求項１１】
前記第１記憶媒体に格納されている前記ファイルにアクセスするリクエストは、トランシーバを介し受信される、請求項１０記載の方法。
【請求項１２】
前記トランシーバは、リモート装置から前記第１記憶媒体に格納されている前記ファイルにアクセスするリクエストを無線受信する、請求項１１記載の方法。
【請求項１３】
前記ファイルのデータレートを確認するため、前記第１記憶媒体から前記ファイルを呼び出す前に、前記ファイルのメタデータにアクセスするステップをさらに有する、請求項１０乃至１２何れか一項記載の方法。
【請求項１４】
前記第１記憶媒体は、ハードディスクドライブを有する、請求項１０乃至１３何れか一項記載の方法。
【請求項１５】
前記第２記憶媒体は、ソリッドステートメモリを有する、請求項１０乃至１４何れか一項記載の方法。
【請求項１６】
リクエストに応答して、前記ファイルの第２部分を送信するステップをさらに有する、請求項１０乃至１５何れか一項記載の方法。
【請求項１７】
当該方法は、携帯電話機の一部を構成するプロセッサによって実行される、請求項１０乃至１６何れか一項記載の方法。
【請求項１８】
当該方法は、モバイル音声／映像サーバの一部を構成するプロセッサによって実行される、請求項１０乃至１６何れか一項記載の方法。
【請求項１９】
第１記憶媒体に格納されているファイルにアクセスするリクエストを受け付ける命令と、
前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出す命令と、
前記ファイルの第１部分を送信する命令と、
前記ファイルの第２部分を第２記憶媒体に格納する命令と、
のコンピュータ実行可能命令を有するコンピュータ可読媒体を有するコンピュータプログラム。
【請求項２０】
前記第１記憶媒体に格納されている前記ファイルにアクセスするリクエストは、トランシーバを介し受信される、請求項１９記載のコンピュータプログラム。
【請求項２１】
前記トランシーバは、リモート装置から前記第１記憶媒体に格納されている前記ファイルにアクセスするリクエストを無線受信する、請求項２０記載のコンピュータプログラム。
【請求項２２】
前記ファイルのデータレートを確認するため、前記第１記憶媒体から前記ファイルを呼び出す前に、前記ファイルのメタデータにアクセスする命令をさらに有する、請求項１９乃至２１何れか一項記載のコンピュータプログラム。
【請求項２３】
前記第１記憶媒体は、ハードディスクドライブを有する、請求項１９乃至２２何れか一項記載のコンピュータプログラム。
【請求項２４】
前記第２記憶媒体は、ソリッドステートメモリを有する、請求項１９乃至２３何れか一項記載のコンピュータプログラム。
【請求項２５】
リクエストに応答して、前記ファイルの第２部分を送信する命令をさらに有する、請求項１９乃至２４何れか一項記載のコンピュータプログラム。
【請求項２６】
当該コンピュータプログラムは、携帯電話機の一部を構成するプロセッサによって実行される、請求項１９乃至２５何れか一項記載のコンピュータプログラム。
【請求項２７】
当該コンピュータプログラムは、モバイル音声／映像サーバの一部を構成するプロセッサによって実行される、請求項１９乃至２５何れか一項記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶媒体を有する装置及び当該装置の動作方法に関する。
【背景技術】
【０００２】
極めて多数の電子装置に、データ及びプログラムを格納するための１以上の記憶媒体が設けられている。光、磁気又はソリッドステートとすることができる記憶媒体は、多くの装置において大変重要である。記憶媒体の動作では、媒体のサイズ、スピード及びエネルギー消費などの各種パラメータが重要である。装置のタイプやそれが利用される可能性のある環境が、これらのパラメータの何れが最も重要であるか決定する。
【０００３】
ハードディスクドライブ（ＨＤＤ）として知られている１つのタイプの記憶媒体が周知であり、計算の世界において利用されている。このようなＨＤＤはまた、携帯電話機や携帯情報端末（ＰＤＡ）などのマルチメディア装置などの携帯電子装置に搭載されている。ＨＤＤは、高速なリード／ライト機能によって相対的に大量のデータが記憶媒体に格納可能であるという効果を有している。しかしながら、上記のような記憶媒体は、ハードディスクを回転させるのにモータが必要であるため、ソリッドステート装置に使用されるものと比較して大量の電力を消費する電力消費が大きいことが知られている。特に、ＨＤＤが非アクティブ状態からアクティブ状態に移行するとき、相対的に大量の電力がディスクの回転を開始するため消費される。
【０００４】
米国特許ＵＳ６５１２６５２は、コンピュータディスクドライブのための電力セーブ方法及び装置を開示している。電力セーブ方法及び装置は、コンピュータメモリディスクドライブのための動作又は準動作状態を維持する。マイクロプロセッサは、ディスクドライブが非アクティブ状態であるか判断するため、マイクロコード命令を実現する。これは、何れかのファイルが現在オープンされているか、又はデータがディスク装置によって転送されているか確認するため、インタフェースを介しコントロールユニットをチェックすることによって実行される。何れのファイルもオープンされておらず、及び／又は何れのデータ転送も行われていない場合、ドライブは非アクティブとみなされる。非アクティブ期間が所定の基準動作レベルより長い期間継続した場合、ドライブスピンドルモータの回転速度をそれの最も低い動作レベルに低減するか、又はディスクを停止させることのない最も低い動作レベル以下に低減させるためのアクションが行われる。スピンドルモータは、スピンドルモータコントロールユニットを介しマイクロプロセッサによってアクセスされる。一定の線速度のディスクドライブの場合には、スピンドルモータは、マイクロプロセッサがディスク媒体の外周近くのトラックにデータヘッドを移動するためのメッセージをアクチュエータに送信することによって間接的に制御される。一定の線速度を維持するため、スピンドルコントロールはモータの角速度を低速化し、これにより消費電力の低減がもたらされる。再びデータにアクセスする必要があるとき、ドライブはアクティブ状態に入り、ヘッドはマイクロプロセッサの“シーク（ｓｅｅｋ）”コマンドによって移動される。選択可能なスピードを有する一定の角速度ディスクドライブの場合、マイクロプロセッサは、モータスピードを直接的に制御する。ディスクが所定の閾値期間非アクティブ状態であったと判断すると、マイクロプロセッサは利用可能な最も低い動作速度である一定の速度を選択する。このことは、ディスクドライブについて電力セーブモードが実現されることを可能にする。ドライブは、マイクロプロセッサの“シーク”命令によって通常の動作速度に戻る。さらなる節約のため、より長時間非アクティブ状態に放置されるとき、モータは停止又は“スピンダウン”される。
【０００５】
上記特許に記載される解決手段は、ハードディスクドライブについての相対的に直接的な電力セーブ方法である。ファイルの利用及びデータ転送をモニタリングすることによって、装置がハードディスクからのメモリ呼び出しの要求がないと認識すると、ディスクドライブをアイドル状態に戻すことができる。しかしながら、この手段は、データがハードディスクから呼び出されている状況では、電力消費を最小化しない。
【０００６】
米国特許出願公報ＵＳ２００３／０００４９４８は、ネットワーク環境におけるディスクからデータを抽出するシステム及び方法を開示する。ディスクからデータを抽出するシステム及び方法は、クライアントとサーバとの間のネットワーク接続のネットワーク転送レートを決定することを含む。ネットワーク接続を介しクライアントからサーバによってデータリクエストが受信されると、要求されたデータの第１部分がディスクから抽出され、ネットワークを介したクライアントへの第１データ部分の送信が開始される。クライアントへの第１データ部分を送信するのに必要とされる時間は、ネットワーク連想レートに基づき計算され、ディスクからの要求されたデータの以降の部分を抽出すべき時点の決定は、計算された時間が経過したか否かに部分的に基づき行われる。ディスクから以降のデータ部分を抽出すべき時点の決定はさらに、メモリ利用又はディスク電力消費及び熱発散などのシステムパラメータを最小化しようとする要求に基づくものであってもよい。
【０００７】
上記特許出願の手段は、ディスクドライブが動作する速度（データ転送レートに対応する）をネットワーク接続の速度まで実質的に低減することである。これは、ディスクドライブの安定的な回転速度を保証し、これにより、ドライブのスタート及び停止を低減する。しかしながら、当該方法は、パケットベースであるネットワークプロトコルを利用し、“ベストエフォート”タイプの送信システムを利用する状況において生じるように、ネットワーク速度が利用可能でない状況では、又はネットワーク速度が関連性のない状況では機能しないため、相対的に少数の状況しかカバーするものでない。これらのプロトコルは、ネットワーク接続の速度よりかなり低い有効速度しか有しない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、既知の技術を向上させることである。
【課題を解決するための手段】
【０００９】
本発明の第１の特徴によると、第１記憶媒体、入出力アーキテクチャ、第２記憶媒体及びプロセッサを有する装置であって、前記プロセッサは、前記第１記憶媒体に格納されているファイルにアクセスするリクエストに応答して、前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出し、前記ファイルの第１部分を送信し、前記ファイルの第２部分を前記第２記憶媒体に格納するよう構成される装置が提供される。
【００１０】
本発明の第２の特徴によると、装置の動作方法であって、第１記憶媒体に格納されているファイルにアクセスするリクエストを受け付けるステップと、前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出すステップと、前記ファイルの第１部分を送信するステップと、前記ファイルの第２部分を第２記憶媒体に格納するステップとを有する方法が提供される。
【００１１】
本発明の第３の特徴によると、第１記憶媒体に格納されているファイルにアクセスするリクエストを受け付ける命令と、前記ファイルの実質的なデータレートにより前記第１記憶媒体から前記ファイルを呼び出す命令と、前記ファイルの第１部分を送信する命令と、前記ファイルの第２部分を第２記憶媒体に格納する命令とのコンピュータ実行可能命令を有するコンピュータ可読媒体を有するコンピュータプログラムが提供される。
【発明の効果】
【００１２】
本発明によると、最大のエネルギー効率によって第１記憶媒体を有する装置を動作させることが可能となる。本装置は第１記憶媒体に格納されているファイルに対するリクエストを受け付けると、当該ファイルに対するリクエストがそれがストリーミングされるためのリクエストであるか否かに関係なく、ファイルのデータレートにより第１記憶媒体から当該ファイルをストリーミングする。すぐには必要でないファイルの部分は、第２記憶媒体に格納される。典型的には、第１記憶媒体は、スタート及び停止せず一定のレートにより動作するときに最もエネルギー効率的となるハードディスクドライブであり、第２記憶媒体は、ソリッドステートメモリ装置である。
【００１３】
まだ送信されないファイルの部分がソリッドステートメモリである第２記憶媒体に格納されるとき、ネットワーク速度及び／又は遅延などの装置外部の状況の装置による知識を要求されず、また何れのタイプのプロトコルが装置からファイルを要求しているかは問題とならない。従って、いわゆる“ベストエフォート”プロトコルが利用されているとき、パケットがリクエストされていない期間中は、以降にソリッドステートメモリから送信されるパケットに対するさらなるリクエストに準備するため、データはハードディスクドライブからソリッドステートメモリに効果的にストリーミングされる。
【００１４】
将来的な携帯マルチメディア装置は、それらのローカルストレージからリアルタイム（すなわち、音声及び映像コンテンツをストリーミングする）とベストエフォート（静止画像、データベースアクセス、ウェブコンテンツなど）の両方のデータ転送をミックスされた方法により処理可能となることを要求する。このような装置のローカルストレージは、ハードディスクドライブ（ＨＤＤ）となる可能性が最も高いが、スモール・フォーム・ファクタ・オプティカル（ＳＦＦＯ）ドライブとすることも可能である。当該データはしばしばＨＴＴＰを介しリモートアクセスされるため（すなわち、モバイル装置は、ウェブサーバとして動作する）、他方のエンドがリアルタイムに又はベストエフォートモードによりデータにアクセスしようとしているか常に明らかであるとは限らない。これは、ウェブベース技術にかなりの部分基づくユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ）などのプロトコルについて特に真である。通常、ベストエフォート及びリアルタイムリクエストは、ミックスされた方法により受信される。
【００１５】
ＵＰｎＰメディアサーバがプロトコルとしてＨＴＴＰを用いてデータを転送する場合、ＨＴＴＰはプル転送であるため、サーバはリモートクライアントがデータブロック（すなわち、リクエストされたコンテンツの一部）を読み出す時点を制御できない。明示的なストリームが設定されず、アドミッションコントロールが行われないため、このタイプのベストエフォートは、エネルギーセーブディスクスケジューリングを大きく妨害するかもしれない。これは、ベストエフォートリクエストが、装置がエネルギーをセーブするためＨＤＤをスイッチオフした期間に処理される可能性があるという事実によって引き起こされる。ＨＤＤをスピンさせる必要があるとき、リクエストを実行し、ＨＤＤを再びダウンさせることはエネルギーの浪費となる。本発明は、これらの機会に対するドライブの制御されないスピンアップを回避する方法を提供する。
【００１６】
効果的には、入出力アーキテクチャはトランシーバを有し、本装置は、第２装置から第１記憶媒体に格納されているファイルにアクセスするリクエストを無線受信する。本装置は、典型的には、それらの間のプッシュ及びプルデータ接続による無線ネットワークにおける携帯電話機又は同様のマルチメディアおうちである。本方法はまた、そのような状況のほとんどにおいて電力消費は重要な問題ではないが、本装置が有線通信している場合も機能する。
【００１７】
好ましくは、プロセッサはさらに、第１記憶媒体からファイルを呼び出す前に、当該ファイルのデータレートを確認するため、ファイルのメタデータにアクセスするよう構成される。これは、リクエストを受信したファイルのデータレートを装置が求める最もシンプルな方法である。
【００１８】
理想的には、プロセッサはさらに、リクエストに応答して、ファイルの第２部分を送信するよう構成される。第２記憶媒体であるソリッドステートメモリに格納されているファイルの第２部分は、前方への送信に対するリクエストについて利用可能である。
【発明を実施するための最良の形態】
【００１９】
図１は、第１記憶媒体１２、入出力アーキテクチャ１４、第２記憶媒体１６及びプロセッサ１８を有する装置１０を示す。入出力アーキテクチャ１４はまた、無線通信を送受信するトランシーバ１９を有する。第１記憶媒体１２は、相対的に大きな記憶容量を有するハードディスクドライブであり、第２記憶媒体１６は、相対的に小さいが、動作させるのに最小限の電力しか必要としないソリッドステートメモリである。実質的なメモリ利用のすべては、装置１０を動作させるためのファイル及び実行可能と、メッセージや画像などのユーザデータ及びファイルのすべてを有する第１記憶媒体１２を介しチャネル処理される。第２記憶媒体１６は、効果的には、要求に応じて使用されるキャッシュメモリである。
【００２０】
装置１０はマルチメディア携帯電話１０であり、またディスプレイ、ユーザインタフェース（ディスプレイの一部であるかもしれない）、電源などの図示されないいくつかのコンポーネントを含む。携帯電話機１０は、典型的には、ＵＭＴＳなどの第３世代携帯電話サービスに加入可能なタイプのものであり、Ｂｌｕｅｔｏｏｔｈ及び／又はＷｉＦｉ（ＩＥＥＥ８０２．１１ｂ）などの１以上の短距離無線機能を有する。
【００２１】
図１に示される装置１０などの携帯電話機は、現在それらが加入するワイドエリアワイヤレスネットワーク（ＵＭＴＳなど）を介しインターネットにアクセス可能であり、デジタル画像を送受信可能であり、ビデオファイル及びリアルタイムストリームビデオを受信可能である。技術が進歩し、処理パワーが増大し、記憶媒体がより安価、大型化及び効率化されるに従って、電話機１０などの携帯マルチメディア装置１０はまた、要求に応じてビデオファイルを送信可能となる。これは、第２装置と短距離でコンタクトする第１装置が、ビデオファイルの第１装置への送信を要求する場合に行われる。
【００２２】
装置１０はまた、ローカル又はワイドエリア無線ネットワークに加入する携帯音声／映像サーバ１０とすることが可能である。このようなサーバ１０を用いたネットワークでは、携帯電話機などの携帯装置はサーバ１０と通信し、サーバにより要求元装置に送信されるべきファイルに対するリクエストを送信する。
【００２３】
図２は、通信を行う２つの携帯マルチメディア装置１０及び２０を示す。当該通信は、短距離無線リンクを介し可能であるか、又はＵＭＴＳネットワークなどのワイドエリアネットワークを介し可能である。２つの装置１０及び２０は、ＵＭＴＳシステムのセルラーネットワークのセルに存在する可能性があるか、又はそれらは異なるセルに存在する可能性もある。第１装置１０によって格納される短いビデオファイルなどのファイル２２を第２装置２０がリクエストすることによって、通信がトリガーされる。装置２０からのリクエストは、典型的には、インターネットに関する通信について一般的なＨＴＴＰプロトコル（又はより一般的でないＲＴＰプロトコル）を利用している。装置１０は、第２装置２０から第１記憶媒体１２に格納されているファイル２２にアクセスするためのリクエストを無線により受信する。
【００２４】
通信が開始されると、携帯装置１０のプロセッサ１８は、第１記憶媒体１２に格納されているファイル２２にアクセスするためのリクエストに応答して、ファイル２２の実質的なデータレートにより第１記憶媒体１２からファイル２２を呼び出すよう構成される。プロセッサ１８は、第１記憶媒体１２からファイル２２を呼び出す前に、ファイル２２のメタデータにアクセスし、ファイル２２のデータレートを確認するよう構成される。ここでは、データレートは、ファイル２２が当初に作成されたときに使用されたレートであり、ファイルをストリーミングすることが可能となる、すなわち、バッファリングを要することなくファイルのコンテンツを同時にリード及びレンダリングすることが可能となるのに求められる帯域幅に対応する。
【００２５】
プロセッサ１８は、ファイル２２の第１部分２１を送信し、ファイル２２の第２部分２３を第２記憶媒体１６に格納するよう構成される。装置１０は、ファイル２２の第１部分２１を要求元装置２０に送信し、ファイル２２のデータレートによって残りをソリッドステートメモリ１６にストリーミングする。さらなるリクエストがファイル２２のさらなる部分について装置２０から受信されると、プロセッサ１８は、リクエストに応じてファイル２２の第２部分２３を送信するよう構成される。
【００２６】
装置１０により送信される第１部分２１は、第２記憶媒体１６を介しルーティングされてもよい。このように、プロセッサ１８は、第２装置２０がリクエストするとき、ファイル２２の部分が送信されることによって、ファイル２２のデータレートにより第２記憶媒体１６にファイル２２を効果的に読み出すよう第１記憶媒体１２の動作を制御している。もちろん、実質的にすべての実際的な状況において、第１記憶媒体からのファイル２２の呼び出しをトリガーする第２装置２０からのリクエストが、ファイル２２の第１部分２１に対するリクエストであるとき、ファイル２２の第１部分２１は即座に送信される。
【００２７】
効果的には、追加的な機能が、事前のアプリケーションの知識に基づきより効率的な方法によりプルベースストリーミングを処理するため（ＨＴＴＰなどを介し）ディスクスケジューリングアルゴリズムに追加される。これは、ＨＤＤがパワーダウン又はスタンバイ状態からウェークアップされることを回避する。モバイルサーバがコンテンツ（すなわち、音声又はデータファイル）をストリーミングするリクエストを取得するとすぐに、ディスクスケジューラは、それをベストエフォートリクエストとしては処理せず、リアルタイムストリーミングに対するリクエストとして処理する。
【００２８】
モバイルサーバは、それがファイルの特性についての知識を有しているため（メタデータの形式により）、上記判断を自ら行うことができる。例えば、それはＭＩＭＥタイプを利用して、コンテンツがストリーミングされるべきか否か判断することができる。ストリーミングコンテンツのビットレートは、メタデータデータベースの何れかに格納され、又は媒体に格納されたファイルに埋め込まれる。その後、記憶媒体からネットワークへのストリームは、上述した特性により開始される。当該方法は、図３のフローチャートに詳細に説明される。
【００２９】
図３は、実際的にこれがどのような動作可能であるかの一例を示す。モバイルサーバは、ＨＴＴＰリクエストの形式によりクライアントからリクエストを受信する。ＨＴＴＰリクエストにおけるファイル拡張又はＭＩＭＥタイプに基づき、サーバは、リクエストされたコンテンツがストリーミングコンテンツであるか特定することができる。ストリーミングコンテンツでない場合、当該リクエストは通常のベストエフォートにより処理される。ストリーミングコンテンツがリクエストされた場合、サーバはＨＴＴＰヘッダのＵＲＬを抽出し、ストリーミングコンテンツのビットレートを抽出するため、関連するメタデータをクエリする。ビットレートは、その後にストリーミングコンテンツが所望のビットレートにより利用可能であることを確認するため、ＨＤＤスケジューリングアルゴリズムがバッファ充填を制御するのに利用される。リアルタイム保証が満足させることができない場合、ファイルはベストエフォートにより処理される。ストリームが要求されたレートによりサービス可能である場合、バッファは充填され、ストリーミングをスタートすることができる。
【００３０】
本方法はＨＴＴＰに限定されるものでなく、ストリーミング・アンアウェア（ｓｔｒｅａｍｉｎｇ  ｕｎａｗａｒｅ）である他の（ベストエフォート）プロトコルについて機能することが理解されるべきである。当該方法を利用して、プル機構を介し抽出されるストリーミングコンテンツは、実際にはプッシュモデルを用いて配信される（ストリームが明示的にスケジューリングされた場合）。
【００３１】
当該方法を介して、リモートクライアント（ファイルをリクエストするモバイル装置）が、スケジューラバッファを介しプルされる代わりに、データが実際にプッシュされるという事実を認識せずに、電力セーブモバイルスケジューリングの効果が維持される。クライアントにとって、あたかもそれがプル機構を介しデータを抽出しているかのように見える。
【００３２】
ディスクスケジューラは、ハードディスクドライブをパワーダウンし、エネルギーをセーブすることが可能になるようにするため、１つのバーストによりスケジューラバッファ（第２記憶媒体）を充填する。これは、ファイルに対するリクエストのスタート時に（接続の他方の側のバッファを充填するため）、又はデータが可能な最大速度によりプルされている状況において（この場合、ディスクがパワーダウン状態から何れかの方法によりウェークアップする必要がある）、行われる。当該方法はまた、電力フレンドリーである（それのバースト性質により）。
【００３３】
提案された方法の大きな効果は、ストリーミングコンテンツがネットワーク接続を介しサーバからクライアントにプルされているとき、ディスクへの予期せぬベストエフォートアクセスが存在しないということである。このように、電力セーブ方策は完全に影響を受けない。このことは、予期せぬディスクアクセスによる追加的な電力消費又はパフォーマンスのペナルティを解消する。
【図面の簡単な説明】
【００３４】
【図１】図１は、２つの記憶媒体を有する装置の概略図である。
【図２】図２は、第２装置と通信する図１の装置の概略図である。
【図３】図３は、図１の装置の動作方法のフローチャートである。
【図１】
2008521264.tif 000003
【図２】
2008521264.tif 000004
【図３】
2008521264.tif 000005
【国際調査報告】
2008521264.tif 000006
2008521264.tif 000007
2008521264.tif 000008