JP2008535102A - データ記憶装置を管理するためのメカニズム及び方法 - Google Patents

Abstract

【解決手段】メディアデータ記憶装置管理のための技術及びメカニズムが記述される。簡潔に述べると、メディア制御コンポーネントが、ローカルデバイス上のメディアファイル利用パターンをモニタする。利用パターンが所定の閾値よりも下がったメディアファイルは、トリム（trim）候補として識別される。メディア制御コンポーネントは、メディアファイルからデータ（コンテンツ）を削除することにより、これらトリム候補をトリムする。初めに立ち上げられたとき、トリムされたデータファイルが、適切に再現（render）し続けるように、データは、メディアファイルの後半部から削除される。削除されたメディアファイルが立ち上げられた場合、メディア制御コンポーネントは、削除されたデータを、メディアファイルのライブラリが格納されているコンテンツサーバから取得する。
【選択図】 図４

Description

本発明は、一般に、データ記憶装置の分野に関し、更に詳しくは、モバイルデバイス上のデータ記憶装置に関する。

デジタルマルチメディアはものすごい速度で成長している。ますます多くの人々が、自分たちのパーソナルメディアライブラリをデジタルメディアに変換している。更に、多くのカスタマは現在、最初からデジタルフォーマットで音楽及びその他のメディアを購入するので、変換処理がなくなっている。デジタルメディアは、非常にポータブルであるという利点を持っている。多くのハンドヘルド計算デバイスは、例えば運動している間、運転している間、飛行機に乗っている間、あるいはその他移動している間のように、ユーザが移動しながら、プレイされるデジタルメディアファイルを格納することができる。

この便利さによって、多くのユーザは、できるだけ多くのデジタルメディアライブラリを、自分のポータブルデバイス上に持つことを望んでいる。しかしながら、デジタルメディアファイルは、比較的大量の記憶スペースを使い、一般に、計算デバイスは、特にモバイルデバイスの場合、限られた記憶容量しか持っていない。したがって、ユーザは、モバイルデバイス上に、自己の全てよりも少ないライブラリしか持てないことを受け入れなければならない。この問題は、ポータブル計算デバイスでのメディアファイルのマニュアルでの移動が幾分面倒な処理になるという事実によって悪化する。これらの理由で、ユーザは、自己のモバイルデバイス上に格納されたコンテンツをさほど頻繁に変更しない傾向にある。

この問題を解決する２〜３の試みが進んでいる。そのような１つの試みは、本質的には、計算デバイスの記憶容量を拡大する「怪力」（brute force）方法である。ハードディスクドライブ又はフラッシュメモリドライブのように、益々大容量の記憶メディアが絶えず作られている。この方法に関する１つの問題は、ポータブルデバイスをより高価に、より電力を消費するように、そして、時には、望んでいるよりも大型にする。限られた記憶容量の問題は、ポータブルデバイス分野でより説得力があるのみならず、ラップトップ、ノートブック、デスクトップ、及びその他の計算デバイスのような他の分野にも当てはまる。

その問題に取り組む別の試みは、計算デバイス上に格納されたメディアファイルを交換する処理を自動化することを含む。幾つかの自動化処理は、例えばユーザのデスクトップ計算デバイスのようなパーマネント記憶装置から、ユーザのポータブルデバイスへメディアファイルをコピーするために存在する。実際に、ユーザがめったに実行（例えば、聴く又は見ることを）しないメディアファイルは、計算デバイスから完全に削除され、新たなメディアファイルが計算デバイスへコピーされる。しばしばこの処理は、ポータブルデバイスが、このライブラリを含むデバイスへ物理的に接続されている間に、同期処理中に実行される。

この処理の１つの欠点は、ポータブルデバイス上に含めるファイルを識別するために、ユーザは、完全なメディアライブラリが存在する場合には、常に、ポータブルデバイス上以外のどこかに存在する幾つかの遠隔データ管理ユーティリティと対話しなければならないことである。その理由により、ユーザは、ポータブルデバイス上に、どのコンテンツを含むべきかを容易に識別することができない。それよりもむしろ、ユーザは、データ管理ユーティリティが存在する計算デバイスへ戻らねばならない。これは、ユーザによる高度な計画性を必要とし、頻繁には行われない。代替案は、データ管理ユーティリティが、含める新たなファイルをランダムに選択することができる。しかしながら、これはもちろん、ユーザが個人的に選択したコンテンツとは一致しないだろう。

メディアデータ記憶装置を管理する適切な方法及びメカニズムは、今まで当業者を避けてきた。

本発明は、計算デバイスの外見上の記憶容量を増加させる方法及びメカニズムに向けられる。１つの局面では、本発明は、デバイス上のデータ記憶装置を管理する方法を示す。この方法は、デバイスのローカル記憶装置に格納された複数のファイルから、１又は複数のトリム候補を識別することを含む。ローカル記憶装置上のトリム候補の各々のある部分は、複数のファイルに関連した利用ヒューリスティック（heuristics）に基づいてトリムされる。特定のトリム候補がアクセスされ、特定のトリム候補がアクセスされているという指示を受けると、特定のトリム候補のトリムされた部分が、遠隔記憶装置から取得される。

別の局面では、この方法は、データを提供する方法を示す。この方法は、トリムされたコンテンツに対する要求を、モバイルデバイスから受け取ることを含む。ここで、トリムされたコンテンツは、モバイルデバイスが、モバイルデバイスのローカルなメディアフィルからトリムしたデータを含む。これによって、トリムされたコンテンツは、もはやメディアファイル上に存在することはない。その要求に応じて、トリムされたコンテンツは、通信リンクを介してモバイルデバイスへ提供される。

また別の局面では、本発明は、複数のファイルを有するデバイス上のデータ記憶装置を管理するメカニズムを示す。このメカニズムは、デバイスと遠隔コンテンツサーバとの間の通信を容易にするように構成された通信モジュールと、複数のファイルが存在する記憶メディアと、メディア制御コンポーネントとを含む。メディア制御コンポーネントは、トリム候補を識別するために、複数のファイルの利用をモニタするように構成されている。トリム候補は、所定の閾値よりもさほど頻繁にアクセスされないメディアファイルである。メディア制御コンポーネントは更に、記憶メディア上のトリム候補からデータを削除することによって、トリム候補をトリムするように構成されている。

メディアデータ記憶装置管理用の様々な技術及びメカニズムの詳細説明を以下に示す。一般に、メディアファイルは、ローカルデバイス上に格納される。メディアファイルの利用はログされ、その利用が、所定の閾値を下回る毎にメディアファイルが「トリム」される。メディアファイルは、メディアファイル全体ではなく、メディアファイルからデータ（コンテンツ）を削除することによってトリムされる。データは、メディアファイルの後半部（すなわち、終わり）から削除され、これによって、トリムされたメディアファイルが、初めに立ち上げられたとき、適切に再現し続けることができる。トリムされたメディアファイルが立ち上げられると、メディアファイルが、ローカルデバイス上で再現されながら、削除されたデータが、コンテンツサーバから取得される。

図１は、本発明の実装が特に適用可能なサンプルモバイルデバイス１０１を一般に例示する機能ブロック図である。モバイルデバイス１０１は、セルラ電話、携帯情報端末、ポータブル音楽プレーヤ、ポータブルメディアセンタデバイス、グローバル測位衛星（ＧＰＳ）デバイス等のようなハンドヘルド計算デバイスでありうる。本明細書では、ハンドヘルド計算デバイスに関して記述しているが、本発明の実施は、例えば、ラップトップデバイス、デスクトップデバイス、又はサーバ計算デバイスのような他の分野における等しい適用範囲をも有することが理解されるべきである。

この例では、モバイルデバイス１０１は、プロセッサユニット１０４、メモリ１０６、及び記憶メディア１１３を含んでいる。プロセッサユニット１０４は、有利なことに、マイクロプロセッサ、又は、デジタル信号プロセッサ（ＤＳＰ）のような特別目的のプロセッサを含んでいるが、任意の従来式プロセッサ、コントローラ、マイクロコントローラ、又は状態機械でもありうる。

プロセッサユニット１０４は、メモリ１０６に接続されうる。メモリ１０６は、有利なことに、プロセッサ１０４によって実行されるソフトウェア命令を保持するＲＡＭメモリとして実現される。この実施形態では、メモリ１０６に格納されたソフトウェア命令は、オペレーティングシステム１１０、１又は複数のアプリケーション１１２、及びメディア制御コンポーネント１１１（後述する）を含んでいる。メモリ１０６は、内蔵式ＲＡＭでありうる。あるいは、プロセッサユニット１０４及びメモリ１０６は、ＡＳＩＣ内に集合的に存在しうる。代替実施形態では、メモリ１０６は、ファームウェア又はフラッシュメモリから構成されうる。

プロセッサユニット１０４はまた、記憶メディア１１３に結合される。記憶メディア１１３は、２〜３例を挙げると、例えばＲＯＭメモリ、フラッシュメモリ、磁気ディスクドライブのような非揮発性メモリとして実装されうる。記憶メディア１１３はまた、これら技術及び、例えば、キャッシュ（ＲＡＭ）メモリを備えた磁気ディスクドライブ等のような他の技術との組み合わせで実現されうる。この具体的な実施形態では、記憶メディア１１３は、モバイルデバイス１０１の電源がオフされた時又は電源が投入されていない期間の間、データを格納するために使用される。

モバイルデバイス１０１はまた、モバイルデバイス１０１と１又は複数の他の計算デバイスとの間の双方向通信を可能にする通信モジュール１２１を含んでいる。通信モジュール１２１は、セルラ電話ネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続、無線ローカルエリアネットワーク、あるいは恐らくは無線ワイドエリアネットワークのようなＲＦ無線通信又は他の無線通信を可能にするコンポーネントを含みうる。またこの通信モジュール１２１は、イーサネット（登録商標）接続、ユニバーサルシリアルバス接続、ＩＥＥＥ １３９４（Ｆｉｒｅｗｉｒｅ）接続等のような陸線又はハードワイヤネットワーク通信を可能にするコンポーネントを含みうる。これらは、非完全な（non-exhaustive）リストであることが意図され、その他多くの代替例も可能である。

図２は、上述した記憶メディア１１３とメディア制御コンポーネント１１１とを一般に例示する機能ブロック図である。上述したように、記憶メディア１１３は、モバイルデバイスが電源オフされた時、又は電源が投入されていない期間の間、データを格納するために使用される。記憶メディア１１３は、コンタクト情報、アポイントメント情報、ドキュメント、および恐らくはその他の情報を格納するために使用されうる。この具体的な例では、記憶メディア１１３は、ユーザのコレクション内にメディアファイル２１０を格納するために使用されるものである。メディアファイル２１０は、ＭＰＥＧレイヤ３（ＭＰ３）ファイルのような音楽ファイル、又はビデオファイルや写真のようなその他のメディアデータを含みうる。議論の簡潔さのために、本明細書において、メディアファイル２１０はデジタル音楽ファイルと称される。しかしながら、メディアファイル２１０は、ほとんどあらゆるフォーマットにおける任意のファイルコレクションとなりうることが注目されるべきである。

メディアファイル２１０の各々は、記憶メディア１１３上のスペースの大部分を使う。この例では、メディアファイル２１０は、記憶メディア１１３の利用可能な容量を使い果たしている。しかしながら、メディアファイル２１０は、ユーザのデジタルメディアライブラリの全体ではなく、記憶メディア１１３の利用可能な容量に適合しうるファイルのみを示しうる。ユーザの完全なライブラリ内のより多くのメディアコンテンツは、恐らくは、ネットワーク記憶装置あるいはその他の遠隔アクセス可能な計算システム上に格納されており、離れた場所に存在する。

研究は、コンシューマの音楽を聴く傾向が、アンバランスであることを示している。言い換えれば、コンシューマが、１００枚のコンパクトディスクを所有している場合、それら１００枚のおのおののディスクを等しく聴くことはない。コンシューマの傾向は、新しい音楽や、古いお気に入りを、コレクション中の他のタイトルよりもはるかに頻繁に聴くことである。従って、メタ情報２２０は、メディアファイル２１０における各ファイルに対するユーザのアクセスパターンを識別する。例えば、メディアファイル２１０が全て曲であった場合には、メタ情報２２０は、ユーザが、幾つかの曲の各々をどれ位の頻度で聴くかに関するヒューリスティックデータを含みうる。メタ情報２２０は、ファイルが記憶メディア１１３上にいつ格納されたか、最後にアクセス又は変更されたのはいつか、誰がデータを所有しているか、各ファイルのうちの幾つがローカルに格納されているか等のようなメディアファイル２１０に関する他のメタデータや、恐らくはメディアファイル２１０に関するセキュリティ又はデータ権利管理情報を示しうる。メタ情報２２０は、オペレーティングシステムコンポーネントや特別目的コンポーネントのような任意のメカニズムによって、あるいは、メディア制御コンポーネント１１１によってでも収集されうる。

メディア制御コンポーネント１１１は、記憶メディア１１３上の、特別なメディアファイル２１０内に格納されたデータを管理するように構成されたメカニズムである。メディア制御コンポーネント１１１の中心的役割は、メタ情報２２０内の利用データに基づいて、あるメディアファイル２１０をトリムすることである。一般的に説明すると、メディア制御コンポーネント１１１は、２つの機能を実行する。第１に、メディア制御コンポーネント１１１は、メディアファイル２１０のうち、（例えば、音楽ファイルを聞く場合）ユーザが最も低い頻度でアクセスするものを判定し、これらファイルを、その全体サイズよりも幾分小さく「トリム」すなわち切り詰める。第２に、メディア制御コンポーネント１１１は、トリムされたファイルのうちの失われた部分にユーザがアクセスした場合、通信モジュール１２１を用いて、それらがダウンロードされるようにする。

更に詳しくは、メディア制御コンポーネント１１１は、メタデータ２２０を定期的又はランダムにレビューして、メディアファイル２１０の中から、トリム候補を識別する。トリム候補は、ユーザがある期間アクセスされていないファイルであるか、長期間にわたって、ある閾回数よりもアクセスされていないファイルでありうる。メディア制御コンポーネント１１１は、アクセス頻度順にメディアファイル２１０を並べ替えるか、あるいは、頻繁にアクセスされる、頻繁にアクセスされる訳ではない、ほとんどアクセスされない、全くアクセスされない等といったグループのうちの１つにファイルを割り当てる。これらは、単なる例であり、その他多くの実施が可能である。

トリム候補が一旦識別されると、メディア制御コンポーネント１１１は、これらトリム候補のうちの少なくとも幾つかの部分をトリムする。説明目的のため、ファイルを「トリム」することは、ファイルが引き続き読取可能なように、好ましくは、ファイルの初めからではない部分からデータを削除することを含む。言い換えれば、音楽ファイルの場合、メディア制御コンポーネント１１１が、ユーザがさほど頻繁に聴く訳ではない曲を識別すると、曲の後ろから始めに向かって曲をトリムし、この曲の始めを記憶メディア１１３上に残すものの、ローカルに格納されるファイルのサイズは減少する。トリムされた部分は単に削除するもできるが、メディアファイルからカットすることも、別の場所に格納することもできる。メディアファイルをトリムする一例の技術は、図４に例示され、以下に述べられる。

図３は、本発明の１つの実施形態に従ってファイルのセットをトリムした後の図２に示す記憶メディアを一般に例示する機能ブロック図である。図示するように、メディア制御コンポーネント１１１は、メタ情報２２０内のメタデータを用いて、幾つかのトリム候補を識別する。これらは、ユーザが頻繁にアクセスする訳ではないメディアファイル３１０である。その後、メディア制御コンポーネント１１１は、これらトリム候補をトリムして、トリムされていないオリジナルサイズよりも幾分小さなサイズにする。トリムされたファイル３１２の例は、水平線を有して図３に例示される。ユーザがより頻繁にアクセスする他のメディアファイル３１０はトリムされない。トリムされないファイル３１４の例は、斜線を有して図３に例示される。トリムされたファイルを含んでいるメディアファイル３１０の集合の全体サイズは、図２に示される全くトリムされていないメディアファイル２１０の集合よりも小さい。これによって、更なる記憶のために使用可能な記憶メディア１１３上の空きスペース３５０が増える。ファイルトリミングによって生成される必然的なギャップに適応するために、バックグランドで、ファイルシステムフラグメンテーション問題が管理されうる。

上述した一般技術を利用することにより、本発明の実施により、記憶メディア１１３の容量を増加することなく、ユーザのメディアライブラリの大部分、恐らくはその全てへのアクセスが可能となろう。その代わり、デバイスは、多くの又は幾つかのメディアファイルの完全バージョン、及び、その他のメディアファイルの部分バージョンのみを格納するために使用される制限された記憶量を含む。あるいは、記憶メディア１１３上に格納された全てのファイルは、ファイル全体のうちの部分バージョンでありうる。記憶メディア１１３上の空きスペース３５０は、ユーザのメディアライブラリ内の残りのエントリの一部を格納するために使用されてもよい。例えば、ユーザのミュージックライブラリ内の各曲の始まりだけが、記憶メディア１１３上にローカルに格納されても良い。あるいは、ユーザのメディアライブラリ内の残りのエントリを識別するコンテンツテーブル等が含まれうる。同様に、空きスペース３５０（又はそのある一部）は、新たなメディアコンテンツ（例えば、モバイルデバイスを用いて購入された新たな音楽ファイル）、モバイルデバイス上の他のアプリケーションによって使用される通常のデータ、あるいはその他のデータを含む任意の情報を格納するために使用されうる。

１つの実施では、メディア制御コンポーネント１１１は、記憶メディア１１３のコンテンツを、ユーザの変化する音楽好みに積極的かつアルゴリズム的に適応させる。頻繁にアクセスされるファイルは、完全に格納される一方、さほど頻繁にアクセスされないファイルに対しては「デジタル劣化」アルゴリズムが適用されうる。この実施では、メディア制御コンポーネント１１１は、利用パターンに基づいて、幾つかのファイルの複数のトリムを行い、ほとんどアクセスされないファイルのローカルサイズを徐々に減らす。頻繁にアクセスされるファイルは、全くトリムされないかもしれない。

図６を用いて詳述するが、トリムされたファイルの失われた部分は、オンデマンドで動的に取得される。言い換えれば、部分的にしかローカルに存在していないファイル（例えば、曲）にユーザがアクセスする場合、メディア制御コンポーネント１１１は、ローカルなコンテンツを再現しながら、失われたコンテンツを積極的に取得する。例えば、ファイルを聴こうとユーザがファイルを起動した場合、曲がローカルに部分的にしか存在しないのであれば、メディア制御コンポーネント１１１は、ローカルであるその曲の一部をプレイし始め、プレイ中に、その曲のトリムされた部分を取得する。このようにして、ユーザは、ユーザのメディアファイルの全てがローカルに存在しているという錯覚を経験し、ユーザは、ローカルに部分的にしか存在していないメディアを直ちに楽しみ始めることができる。失われたコンテンツ（すなわち、トリムされたコンテンツ）は、「バックグランド」で取得され、ユーザは、そのファイル全体がローカルに存在していなかったことさえも気が付かないかもしれない。失われた部分を取得する適用可能な幾つかの技術が存在する。図６は、無線モバイルデバイス用の特定の利用可能性を有する１つの技術を示す。

図４は、本発明の実施形態に従ってローカル記憶容量を改善するためにトリムされるサンプルメディアファイルの概念例である。図４に例示しているものは、ユーザのメディアライブラリ内の１つのエントリを示すメディアファイル４１０である。この例では、メディアファイル４１０は、例えば、デジタル音楽コンテンツに広く使用されているポピュラーなＭＰＥＧレイヤ３（「ＭＰ３」）フォーマットのように、非常に多くの異なるメディアフォーマットのうちの１つでありうる。

しばしば、メディアファイル４１０のようなメディアファイルは、フレーム４１２のような「フレーム」と呼ばれるより小さな部分から構築される。概して言えば、フレームは、全体として共に適合するメディアコンテンツの独立した要素である。また、各フレームはそれぞれ、そのフレームにデータを記述する情報とともに自身のヘッダを持っている。グローバルなファイルヘッダはないかもしれないので、正しくなされた場合には、メディアファイル４１０は、幾つかの場所における１又は複数において「カット」され、ファイルの残りの部分が、メディアプレーヤ上で正しく再現するだろう。ヘッダがフレームを正しく識別し続けることができるように、ファイル４１０をカットすることは、フレーム境界上でなされるべきである。しかしながら、多くのメディア再現は、正しくないヘッダを取り扱うかもしれない。

幾つかのメディアフォーマットでは、フレームは互いに依存し、上述したように簡単に分析されるものではない。例えば、ポピュラーなＭＰ３フォーマットで符号化された幾つかのメディアファイル内のフレームは、相互依存しており、残っているメディアファイル４１０の部分が適切に再現されることを保証するためには、更なる複雑な分析が実行されねばならない。しかしながら、メディアファイルをトリム又は切り取ることは一般に行われているので、本説明は、単にこの処理の概要にとどめる。

上述したように、メディアファイル４１０の利用が、ある予め定めた閾値を下回る場合、メディア制御コンポーネント１１１は、メディアファイル４１０の一部を、コンテンツの終わりから始まりに向かって、好適にはフレーム境界上でカットすることによってメディアファイル１１をトリムし、トリムされたメディアファイル４５０を得る。トリムされたメディアファイル４５０は、メディアファイル４１０のトリムされていない最初の部分を表し、ユーザによってアクセスされると、メディアの始まり部分をプレイする。

トリムされるメディアファイル４１０の量は、幾つかの理由によって変わりうる。例えば、メディアファイル４１０のファイルフォーマットは、部分的に使用可能であり続けながら、どれ位の量をトリムできるかを管理しうる。１つの実装では、メディアファイル４１０がトリム候補になった最初の時、メディアファイル４１０は最小サイズにトリムされうる。「最小サイズ」の１つの定義は、図５と共に後述する。別の実装では、メディアファイル４１０は、使用頻度に基づいて異なる量でトリムされうる。例えば、ある初期閾値よりも少なくアクセスされたメディアファイルは、例えば５０％のような初期量までトリムされうる。メディアファイルがアクセスされることなく、ある追加時間が経過した場合、このメディアファイルは、例えば更に５０％のような追加量までトリムされ、これによって、メディアファイルは、そのオリジナルのサイズの２５％となる。アクセスのない時間が更に続いた後は、メディアファイルの更に多くがトリムされうる。メディアファイルがある最小サイズに到達するまで、この手順が繰り返されうる。ユーザインタフェースは、「パーセントローカル」等を示し、どのファイルが完全に存在しているか、及びどのファイルが部分的に存在しているかに関する指示を提供する。

実例のため、メディアファイル４１０は、３分の長さの曲であり、１２８ビットＭＰ３を用いて１０：１の圧縮比で符号化されたものと仮定する。これらの条件の下では、メディアファイル４１０は、約２．８ＭＢの記憶量を占有するかもしれない。この曲がプレイされずに時間が経過すると、メディアファイル４１０は、初めは１分に、次は３０秒に、次は１５秒に、最後に５秒にトリムされる。その時点では、トリムされたメディアファイル４５０によって使用される記憶スペースは、約８０ＫＢである。このトリムされたメディア４５０にユーザがアクセスした時、無線アクセス可能なサーバ等に存在するユーザの完全なライブラリから、残りの２．７ＭＢが取得されうる。

補足強化機能は、ユーザの利用パターンに基づいて、ファイルになされるトリム量を変更することでありうる。そのような実施では、トリムが生じる閾値は、異なるユーザの音楽好みに適合するだろう。したがって、例えば、同じ音楽のセットを繰り返し何度も聴くユーザは、幅広く様々な音楽を聴くユーザとは異なり低い閾値を経験しうる。閾値はまた、ユーザ設定とすることもでき、これによって、ユーザは、どれくらい多くの音楽がローカルに格納されているか、どれくらい多くの音楽が遠隔場所から取得されるかについて制御することができる。

図５は、本発明の１つの実施形態に従って、時間の関数としてローカルに格納されたメディアファイルのパーセンテージを、時間の関数としてプレイされるメディアファイルのパーセンテージと比較したグラフを示す。「プレイ曲線」５１０、及び「ローカル曲線」５５０が示される。プレイ曲線５１０は、ユーザがファイルにアクセスした場合、メディアファイルのうちのどれ位が再現されプレイされたかを全体に対するパーセンテージで示している。プレイ長さ５１２は、ファイル全体を再現するのに要する全体の時間の長さを表す。

一方、ローカル曲線５５０は、ローカルに存在しているメディアファイルの量を、全体に対するパーセンテージで示している。初めは、例えばファイルの３５％のように、メディアファイル全体よりも少ない量がローカルに存在する。ダウンロード時間５１６は、この例の場合６５％であるメディアファイルの失われた部分をダウンロード又は取得するために要する時間である。「セットアップ」時間５１８は、ローカルデバイスが、メディアファイルのうちの失われた部分が存在する遠隔デバイスとのセッションを確立し、かつ、失われたコンテンツの取得又はダウンロードを開始するために要する時間である。

図５に例示するように、ユーザにシームレスなリプレイ経験を提供しながら、トリムされるメディアファイルのパーセンテージは、セットアップ時間５１８及びダウンロード時間５１６によって制御される。言い換えれば、セットアップ時間５１８及びダウンロード時間５１６がプレイ長さ５１２を越えない限り、失われたコンテンツは、ユーザが最初にプレイバックを開始した時に、ファイル全体がローカルに存在している訳ではないことをユーザが認識することなく取得される。このセットアップ時間５１８は、ローカルデバイスが、ユーザライブラリを含む遠隔デバイスとの通信セッションの開始及びネゴシエートを行い、かつ、メディアファイルの失われた部分のダウンロード又は取得を開始するまでに要する時間の関数である。通信プロトコル及びハードウェアに基づいて、セットアップ時間５１８は、ミリ秒から数秒までの任意の時間長さでありうる。ダウンロード時間５１６は、ローカルデバイスとサーバとの間の通信リンクの帯域幅の関数である。リンクが高レイテンシ接続又は低帯域幅接続である場合、ダウンロード時間５１６は長くなりうる。逆に、リンクが高帯域接続又は低レイテンシ接続である場合、ダウンロード時間５１６は非常に速くなり、数秒であるかもしれない。通信リンクが非常に高速である場合、ファイル全体がローカルであるという錯覚を犠牲にすることなく、メディアファイルの大部分がトリムされうる。

更に、失われたコンテンツはユーザがその欠如に気付くことなく取得されうるが、それは本発明に必要ではないことが注目されるべきである。言い換えれば、本発明は、メディアの一部が失われているという事実をユーザが感じるという実施形態において実施されうる。例えば、コンテンツをトリムするための閾値は十分にアグレッシブであるので、そのような場合、失われたコンテンツは、幾つかのファイルのプレイバックにおけるスキップ又は躊躇（hesitation）を回避するほど十分早くは取得されない。この構成は、少なくとも部分的ではあるが、ローカル記憶メディアにおけるメディアファイルの最大数が示されるという利点を有する。あるいは、閾値は十分保守的（conservative）であるので、失われたコンテンツは常に（又はほとんど常に）プレイ長さ５１２の終了前に取得されるだろう。この構成は、帯域幅が制限され、規制され、利用料金の発生を招く無線環境において問題となる取得を最低量のデータしか要しないという更なる利点を有する。

図６は、本発明が実現される１つのシステム６０１を一般に例示する機能ブロック図である。システム６０１は、モバイルデバイス６１０及びサーバ６５０を含んでいる。モバイルデバイス６１０は、メディアコンテンツが格納されうるあらゆる計算デバイスでありえる。ユーザのデジタルメディアコレクションのうちの少なくとも一部がモバイルデバイス６１０に格納され、モバイルデバイス６１０上の少なくとも１つのメディアファイルは、上述したように部分的にトリムされている。モバイルデバイス６１０は、アクセスされているファイルに応じて、メディアファイルの失われたコンテンツを取得又はダウンロードするように構成されたメディア制御コンポーネント６１１を含んでいる。

この実施形態では、モバイルデバイス６１０は、無線リンク６２０によってサーバ６５０と通信している。一例では、モバイルデバイス６１０は、ハンドヘルドセルラ電話でありうる。サーバ６５０は、無線リンク６２０を介してコンテンツを利用可能にするファイルホスティングサービスの一部でありえる。サーバ６５０は、コンテンツを、モバイルデバイス６１０によるオンデマンドダウンロードのために利用可能にするように構成される。特に、サーバ６５０は、モバイルデバイス６１０によって識別されたファイル内の位置から、部分的なファイルコンテンツのダウンロードを可能にするように構成される。サーバ６５０は、ライブラリ６５２内に、ユーザの完全なデジタルメディアコレクションを含み、メディアファイル６１２からトリムされた失われたコンテンツ６５４を少なくとも含む。

この実施形態に従って、部分的に存在するメディアファイル６１２にユーザがアクセスする場合、メディア制御コンポーネント６１１は、メディアファイル６１２の再現を直ちに行う。例えば、メディアファイル６１２が曲である場合、メディア制御コンポーネント６１１は、この曲に対して、メディアファイル６１２のうちローカルに存在する部分のプレイを開始させうる。更に、メディア制御コンポーネント６１１は、メディアファイル６１２の失われた部分を、サーバ６５０から取得する。

更に詳しくは、モバイルデバイス６１０は、メディア制御コンポーネント６１１の制御の下、サーバ６５０とのセッションを開始し、失われたコンテンツ６５４のダウンロードを要求する。サーバ６５０もモバイルデバイス６１０に対して、モバイルデバイス６１０のユーザが、失われたコンテンツ６５４を取得する権利を有することを保証するために、適切な信用証明を提供するように要求する。セッションが確立された場合、サーバ６５０は、失われたコンテンツ６５４を、無線リンク６２０を介してモバイルデバイス６１０へ送信する。メディア制御コンポーネント６１１は、失われたコンテンツを、再現されるようにメディアファイル６１２へ再び組み込む。

たとえメディアファイル６１２がサーバ６５０から部分的に取り出されても、ユーザは即時アクセスのうちの１つしか感じないことが認識されるべきである。サーバ６５０から取得されるコンテンツの量は可変である。メディアファイルがより長期間「休止している」（つまり、最近アクセスされていない）と、サーバ６５０からより多くのコンテンツを取得する必要があるだろう。例えば、極く最近デジタル的に価値が下がり始めた曲は、最短のover-the-airダウンロードしか必要ないだろう。一旦ダウンロードされると、この曲は、再び「新鮮味がなくなる」までモバイルデバイス６１０上に存在し続ける。この技術のネット効果は、ユーザの要求においてのみ、古いコンテンツを、シームレスに、バックグランドで取得しながら、ユーザが最も頻繁にアクセスするコンテンツを保持し続けることである。

図７は、本発明の１つの実施に従って、モバイルデバイス上のメディアファイルをトリムする処理７００を一般に維持する動作フロー図である。この処理７００は、モバイル計算デバイス又は固定式計算デバイスのようにメディアファイルが格納されている計算デバイス上で実施されうる。メディアファイルは、メディアファイルのライブラリの少なくとも一部を表す。

処理はステップ７００で始まり、格納されているメディアファイルの各々に対して、利用データ又はヒューリスティックスが収集される。この利用データは、メディアファイルの各々が、計算デバイス上でどれくらいの頻度でアクセスされるかを識別する。一例では、メディアファイルが曲である場合、利用データは、これら曲の各々が、どれくらいの頻度で、及び／又は、どれくらい最近プレイされたかを示す。

ステップ７２０では、計算デバイス上に格納されたメディアファイルから「トリム候補」が識別される。これらトリム候補は、コンピュータデバイス上で最も低い頻度でアクセスされるメディアファイルのサブセットを表す。これらトリム候補は、計算デバイスのコンポーネントによって収集された利用データ又はヒューリスティックデータから識別されうる。

ステップ７３０では、トリム候補の各々がトリムされる。これは、トリム候補として識別されたメディアファイルのコンテンツの一部が、計算デバイス上のローカル記憶装置から削除されることを意味する。言い換えれば、これらトリム候補は、より小さく切り詰められたトリムメディアファイルでありうる。好適には、トリム候補は、メディアファイルの終わりから始まりに向かってトリムされる。これによって、計算デバイス上に、メディアの始まりを残す。トリムは、ステップ７１０で収集された利用ヒューリスティックスに基づきうる。利用ヒューリスティックスは、トリムされるメディアファイルの量を増減するために使用される。

図８は、計算デバイスにおいて、メディアファイルからトリムされたコンテンツを取得する処理８００を一般に例示する別の動作フロー図である。この処理８００は、トリムされたメディアファイルを含むメディアファイルが格納されるモバイルデバイス上で実行される。モバイルデバイスという用語は、完全なメディアファイルのライブラリを含むコンテンツサーバとは別の計算デバイスを記述するために一般に使用され、実際に、モバイルでもポータブルでもない計算デバイスを含みうる。

ステップ８１０では、特定のトリム候補がアクセスされているという指示が、計算デバイスにおいて受信される。例えば、頻繁にアクセス（例えばプレイ）されずにトリムされたメディアファイルが、今、ユーザによって立ち上げられた。トリムされたメディアファイルを立ち上げることによって、トリムされたメディアファイルの再現が直ちに開始され、トリムされたコンテンツを取得するとの通知が発行される。トリムされたメディアファイルを再現することは、この処理８００の残りのステップのうちの１又は複数が実行されている間になされているかもしれず、これによって、メディアファイルがトリムされていないという幻覚をユーザに与えることが注目されるべきである。

ステップ８２０では、通信セッションが開始され、トリムされたコンテンツが遠隔記憶装置から取得される。例えば、トリムされたコンテンツの取得をサポートするために、セルラ通信セッションのような無線リンク、又は、従来のイーサネット（登録商標）ネットワーク接続のような有線リンクを使用する通信セッションが確立されうる。このセッションは、ユーザのメディアライブラリに関連付けられたメディアファイルが存在するサーバ計算デバイスでありうる遠隔コンテンツサーバと確立される。遠隔記憶装置は、少なくとも、計算デバイスから削除された特定のトリム候補の部分を含む。

ステップ８３０では、特定のトリム候補がアクセスされると、トリムされたコンテンツが遠隔記憶装置から取得される。更に詳しくは、トリム候補を再現することは、ステップ８１０の前に、またはステップ８１０と連携して開始される（例えば、音楽ファイルをプレイすることが開始される）。そして、トリム候補が再現されている間、メディアファイルの失われた部分（すなわち、トリムされたコンテンツ）が、遠隔記憶装置から取得され、メディアファイルへ再び組み込まれる。好適には、トリムされたコンテンツは、メディアファイルの再現がシームレスに、かつ躊躇なく行われるように再び組み込まれるので、通信リンクによるメディアコンテンツをダウンロードすることに関して普通に関連付けられる。

コンテンツを取得するメカニズムは、利用法、あるいは恐らくはある仮定に再度基づき、ヒューリスティックを適用することによって更に向上が図られる。例えば、ユーザが特定のアルバム（又は他のメディアのコレクション）のプレイを開始したのであれば、計算デバイスは、全ての曲が更なるダウンロードなく利用可能であることを保証するために、アルバム上の存在しない曲の任意の部分をダウンロードし始めうる。同様に、計算デバイスが、音楽ライブラリからランダム順に曲をプレイするように設定されたのであれば、存在しない曲は、単一のネットワーク接続の間に、事前に取得されうる。

本発明が特定の実施形態及び実装に関して説明されたが、これらは単なる例示であり、本発明の範囲は、これら実施形態に限定されないと理解されるべきである。上述した実施形態に対する多くの変形、修正、追加、及び改良が可能である。これら変形、修正、追加、及び改良は、特許請求の範囲内で詳述されるように、本発明の範囲内にあると考えられる。

図１は、本発明の実装が特に適用可能なモバイルデバイスを一般的に例示する機能ブロック図である。 図２は、本発明の実施形態に従って構成されたメディア制御デバイスによって制御されているファイルのセットを有する記憶メディアを一般的に例示する機能ブロック図である。 図３は、本発明の実施形態に従ってローカル記憶容量を改善するためにトリムされるサンプルメディアファイルの概念例である。 図４は、本発明の実施形態に従ってファイルのセットをトリムした後の図２に示される記憶メディアを一般に例示する機能ブロック図である。 図５は、本発明の１つの実施形態に従って、時間の関数としてローカルに格納されるメディアファイルのパーセンテージを、時間の関数としてプレイされるメディアファイルのパーセンテージと比較したグラフを例示する。 図６は、本発明の１つの実施形態に従って、ユーザのメディアライブラリに関連するコンテンツを利用可能としかつ取得するためのシステムの機能ブロック図である。 図７は、本発明の１つの実装に従って、モバイルデバイス上のメディアファイルをトリムするための処理を一般に例示する動作フロー図を示す。 図８は、計算デバイスにおいてメディアファイルからトリムされたコンテンツを取得する処理を一般に例示する別の動作フロー図である。

Claims (34)

1. デバイス上のデータ記憶装置を管理する方法であって、
   ローカル記憶装置上の複数のファイル内の各ファイルの利用パターンを判定することと、
   前記各ファイルの利用パターンに基づいて、前記複数のファイルから、１又は複数のトリム候補を識別することと、
   前記ローカル記憶装置上のトリム候補の一部をトリムすることと
   を備える方法。
2. 特定のトリム候補がアクセスされているという指示に応じて、前記特定のトリム候補がアクセスされている間、前記特定のトリム候補のトリムされた部分を取得することを更に備える請求項１に記載の方法。
3. 前記ローカル記憶装置上の複数のファイルは、デジタルメディアファイルを備える請求項１に記載の方法。
4. 前記デバイスは、モバイル計算デバイスを備え、前記複数のファイルは、メディアファイルを備え、各メディアファイルの利用パターンは、前記メディアファイルが前記モバイル計算デバイス上に再現される頻度を備える請求項１に記載の方法。
5. 前記トリム候補を識別することは、所定の閾値よりも少ない頻度で再現されるメディアファイルを識別することを備える請求項４に記載の方法。
6. 前記トリム候補の一部をトリムすることは、
   開始部分から終了部分へ向かって再現されるように構成されているメディアファイルの、前記開始部分及び終了部分を識別することと、
   前記メディアファイルを前記終了部分から前記開始部分に向かって切り詰めることと
   を備える請求項１に記載の方法。
7. 前記メディアファイルが前記開始部分から再現されている場合、前記切り詰められた分が取得されるように、必要な量の前記メディアファイルが切り詰められない請求項６に記載の方法。
8. デバイス上のデータ記憶装置を管理する方法であって、
   ローカル記憶装置に格納された複数のファイルから、１又は複数のトリム候補を識別することと、
   前記ローカル記憶装置上のトリム候補の各々の一部を、前記複数のファイルに関連付けられた利用ヒューリスティックに基づいてトリムすることと、
   特定のトリム候補がアクセスされているという指示を受け取ることと、
   前記特定のトリム候補がアクセスされている場合、前記特定のトリム候補のトリムされた部分を遠隔記憶装置から取得することと
   を備える方法。
9. 前記デバイスは、モバイル計算デバイスを備え、前記複数のファイルは、メディアファイルを備え、前記メディアファイルの利用ヒューリスティックは、前記メディアファイルがどれくらいの頻度で前記モバイル計算デバイス上に再現されるのかを識別する請求項８に記載の方法。
10. 前記トリム候補を識別することは、所定の閾値よりも少ない頻度で再現されるメディアファイルを識別することを備える請求項９に記載の方法。
11. 前記トリム候補の一部をトリムすることは、
    開始部分から終了部分へ向かって再現されるように構成されているメディアファイルの、前記開始部分及び終了部分を識別することと、
    前記メディアファイルを前記終了部分から前記開始部分に向かって切り詰めることと
    を備える請求項８に記載の方法。
12. 前記メディアファイルが前記開始部分から再現されている場合、前記切り詰められた分が取得されるように、必要な量の前記メディアファイルが切り詰められない請求項１１に記載の方法。
13. 前記必要な量は、前記切り詰められた分が格納されている遠隔サーバと前記デバイスとの間の通信リンクの特性に基づいて決定される請求項１２に記載の方法。
14. 前記必要な量は、前記切り詰められた分の予期されるダウンロード時間と、前記切り詰められた分が格納されている遠隔サーバと前記デバイスとの間の通信リンクのセットアップ時間とに基づいて決定される請求項１２に記載の方法。
15. 前記通信リンクのセットアップ時間と、前記切り詰められた分のダウンロード時間との合計は、前記メディアファイルのプレイ長さよりも短い請求項１４に記載の方法。
16. データを提供する方法であって、
    トリムされたコンテンツを求める要求をモバイルデバイスから受け取ることと、
    前記トリムされたコンテンツを、通信リンクによって前記モバイルデバイスへ提供することとを備え、
    前記トリムされたコンテンツは、前記モバイルデバイスが、前記モバイルデバイスのローカルなメディアファイルからトリムしたデータを含み、前記メディアファイル上にもはや存在しない方法。
17. デバイス上のデータ記憶装置を管理するコンピュータ実行可能命令でコード化されたコンピュータ読取可能媒体であって、前記命令は、
    ローカル記憶装置に記憶された複数のファイルから１又は複数のトリム候補を識別することと、
    前記ローカル記憶装置上の前記トリム候補の各々の一部をトリムすることと、
    特定のトリム候補がアクセスされているという指示を受け取ることと、
    前記特定のトリム候補がアクセスされている場合、前記特定のトリム候補のトリムされた部分を遠隔記憶装置から取得することと
    を備えるコンピュータ読取可能媒体。
18. 前記デバイスは、モバイル計算デバイスを備え、前記複数のファイルは、メディアファイルを備え、前記メディアファイルの利用ヒューリスティックは、前記メディアファイルがどれくらいの頻度で前記モバイル計算デバイス上に再現されるのかを識別する請求項１７に記載のコンピュータ読取可能媒体。
19. 前記トリム候補を識別することは、所定の閾値よりも少ない頻度で再現されるメディアファイルを識別することを備える請求項１８に記載のコンピュータ読取可能媒体。
20. 前記トリム候補の一部をトリムすることは、
    開始部分から終了部分へ向かって再現されるように構成されているメディアファイルの、前記開始部分及び終了部分を識別することと、
    前記メディアファイルを前記終了部分から前記開始部分に向かって切り詰めることとを備える請求項１７に記載のコンピュータ読取可能媒体。
21. 前記メディアファイルが前記開始部分から再現されている場合、前記切り詰められた分が取得されるように、必要な量の前記メディアファイルが切り詰められない請求項２０に記載のコンピュータ読取可能媒体。
22. 前記必要な量は、前記切り詰められた分が格納されている遠隔サーバと前記デバイスとの間の通信リンクの特性に基づいて決定される請求項２１に記載のコンピュータ読取可能媒体。
23. 前記必要な量は、前記切り詰められた分の予期されるダウンロード時間と、前記切り詰められた分が格納されている遠隔サーバと前記デバイスとの間の通信リンクのセットアップ時間とに基づいて決定される請求項２１に記載のコンピュータ読取可能媒体。
24. 前記通信リンクのセットアップ時間と、前記切り詰められた分のダウンロード時間との合計は、前記メディアファイルのプレイ長さよりも短い請求項２３に記載のコンピュータ読取可能媒体。
25. データを提供するコンピュータ実行可能命令でコード化されたコンピュータ読取可能媒体であって、前記命令は、
    トリムされたコンテンツを求める要求をモバイルデバイスから受け取ることと、
    前記トリムされたコンテンツを、通信リンクによって前記モバイルデバイスへ提供することとを備え、
    前記トリムされたコンテンツは、前記モバイルデバイスが、前記モバイルデバイスのローカルなメディアファイルからトリムしたデータを含み、前記メディアファイル上にもはや存在しないコンピュータ読取可能媒体。
26. 複数のファイルを有するデバイス上のデータ記憶装置を管理するメカニズムであって、
    前記デバイスと遠隔コンテンツサーバとの間の通信を容易にするように構成された通信モジュールと、
    複数のファイルが存在する記憶メディアと、
    前記複数のファイルの利用度をモニタして、トリム候補を識別するように構成されたメディア制御コンポーネントとを備え、
    前記トリム候補は、所定の閾値よりも少ない頻度でアクセスされるメディアファイルであり、前記メディア制御コンポーネントは更に、前記記憶メディア上のトリム候補からデータを削除することによって前記トリム候補をトリムするように構成されたメカニズム。
27. 前記メディア制御コンポーネントは更に、特定のメディアファイルのアクセスの低い頻度に基づいて、前記特定のトリム候補からデータの大部分を削除するように構成された請求項２６に記載のメカニズム。
28. 前記複数のファイルは、メディアファイルを備える請求項２６に記載のメカニズム。
29. 前記メディア制御コンポーネントは更に、特定のトリム候補の前記削除されたデータを取得するように構成されている一方、前記特定のトリム候補は、前記特定のトリム候補がアクセスされているという指示に応じてアクセスされる請求項２６に記載のメカニズム。
30. 前記削除されたデータは、前記通信モジュールを用いて、前記遠隔コンテンツサーバから取得される請求項２９に記載のメカニズム。
31. 前記通信モジュールは、無線通信リンクを用いて通信するように構成された請求項２９に記載のメカニズム。
32. 前記通信モジュールは、ハードワイヤ通信リンクを用いて通信するように構成された請求項２９に記載のメカニズム。
33. データ記憶装置を管理するシステムであって、
    メディアファイルのライブラリと、
    前記メディアファイルのライブラリ内のメディアファイルのうちの少なくとも一部を提供するように構成されたサーバ通信モジュールと
    を含むコンテンツサーバと、
    前記コンテンツサーバとモバイルデバイスとの間の通信を容易にするように構成された通信モジュールと、
    前記複数のメディアファイルが存在する記憶メディアと、
    前記複数のメディアファイルの利用度をモニタして、トリム候補を識別するように構成されたメディア制御コンポーネントと
    を含むモバイルデバイスであって、前記トリム候補は、所定の閾値よりも少ない頻度でアクセスされるメディアファイルであり、前記メディア制御コンポーネントは更に、前記記憶メディア上のトリム候補からデータを削除することによって前記トリム候補をトリムするように構成され、前記メディア制御コンポーネントは更に、特定のトリム候補がアクセスされている間、前記特定のトリム候補がアクセスされているという指示に応じて、前記特定のトリム候補のために、前記削除されたデータを前記コンテンツサーバから取得するように構成されたモバイルデバイスと
    を備えるシステム。
34. 複数のファイルを有するデバイス上のデータ記憶装置を管理するメカニズムであって、
    前記デバイスと遠隔コンテンツサーバとの間の通信を容易にする通信手段と、
    前記複数のファイルを格納する記憶手段と、
    前記複数のファイルの利用特性をモニタして、所定の閾値よりも少ない頻度でアクセスされるメディアファイルであるトリム候補を識別するとともに、前記記憶手段上のトリム候補からデータを削除することによって前記トリム候補をトリムするメディア制御手段と
    を備えるメカニズム。

Images