JP2004515863A - 携帯用コンピューティング・デバイスへのメディア・データの配信 - Google Patents

Abstract

このサブシステムがストリーミング・メディア・データを受信する場合、携帯用コンピューティング・デバイスの送受信サブシステム内の電力消費が減少される。携帯用コンピューティング・デバイスは、第１の通信チャネルを介してメディア・データの第１の部分を、及び第２チャネルを介してメディア・データの第２の部分を受信する。携帯用コンピューティング・デバイスは、第２の部分を受信する前に、第１の部分を得て、第２の部分を受信するために無線接続を使用する。携帯用コンピューティング・デバイスは、第２の部分が受信されると、無線通信を終了し、その結果、無線デバイス内での電力消費を全体で減少させる。携帯用コンピューティング・デバイス上のクライアント・アプリケーションは、第１及び第２の部分からメディア・ファイルを再組立てする。

Description

【０００１】
＜関連出願の相互参照＞
本出願は、２０００年２月１６日に提出された「Ａｕｄｉｏ Ｓｙｎｔｈｅｓｉｓ Ｕｓｉｎｇ Ｄｉｇｉｔａｌ Ｓａｍｐｌｉｎｇ ｏｆ Ｃｏｄｅｄ Ｗａｖｅｆｏｒｍｓ（コード化された波形のデジタル・サンプリングを使用する音声合成）」と題された米国特許出願第０９／５０５，４８６号の一部継続出願であり、それはここに参考文献として組み込まれる。また本出願は、２０００年１０月２７日に提出された「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｅｌｉｖｅｒｉｎｇ Ｍｅｄｉａ Ｄａｔａ ｖｉａ Ｗｉｒｅｌｅｓｓ Ｄｅｖｉｃｅｓ（無線デバイスを介してメディア・データを配信する方法及び装置」と題された暫定特許出願第６０／２４４，０５９号の、３５ＵＳＣ§１１９（ｅ）により優先権を要求するものであり、それはここに参考文献として組み込まれる。
＜発明者＞
Ｔｉｍ Ｂｒａｔｔｏｎ、Ｓｙｌｖａｉｎ Ｒｅｂａｕｄ、Ｊ．Ｐ．Ｌｅｓｔｅｒ、及びＭａｕｒｉｃｉｏ Ｇｒｅｅｎｅ
【０００２】
【発明の技術分野】
本発明は、コンピュータ化されたデバイス間でデータを伝送する方法及びシステムに関係する。特に、本発明の実施例では、サーバ・コンピュータが、第１の通信チャネルによって携帯用コンピューティング・デバイスにメディア・データファイルの第１の部分を送信し、第２の通信チャネルによって携帯用コンピューティング・デバイスにメディア・データファイルの第２の部分を送信できるようにする。
【０００３】
【従来の技術】
携帯用コンピューティング・デバイスは近年人気が増大した。携帯用コンピューティング・デバイスは、手持ち式のコンピュータ、無線電話、及び携帯情報端末（「ＰＤＡ」）を含む。時が経つと共に、携帯用コンピューティング・デバイスは機能を増加しており、今や多くのそのようなデバイスは、２〜３年前には不可能であった豊富な技術をユーザに提供している。例えば、多くの携帯用コンピューティング・デバイスは、今や無線で送受信する能力を含んでいる。無線で通信する能力は、携帯用コンピューティング・デバイスの適用範囲をさらに増大させた。無線通信は、携帯用コンピューティング・デバイスがインターネットのような電子ネットワークにアクセスすることを可能にする。従って、携帯用コンピューティング・デバイスは、パーソナル・コンピュータ・ユーザにとってインターネット上で利用可能なものに似た、豊富な対話型の技術をユーザに提供する。
【０００４】
携帯用コンピューティング・デバイスの「携帯性」は、通常、移動できるようにするための内部電源（例えばバッテリ）をそのデバイスが保有することが必要である。あいにく、携帯用コンピューティング・デバイスの無線接続の確立とその維持が、携帯用コンピューティング・デバイスの電源の消費量を増大させてしまう。さらに、いくつかの無線通信チャネルは、広範囲の利用を提供できるが、従来のデスクトップ・コンピュータで利用可能な多くのアプリケーション用の高帯域通信を十分にサポートできない。従って、ユーザは、バッテリ電力を温存するか、ますますバッテリ電力を縮小するかによって、限定的な無線通信を受けるか又は限定された期間に無線通信を受けるかとの選択をしなければならない。
【０００５】
携帯用コンピューティング・デバイスに備えられた他の機能をユーザが使うことによって、そのデバイスのバッテリが既に低減している場合、無線通信を確立する工程は、デバイスの残りのバッテリ電力を多く消費する。そのような状況の下では、携帯用コンピューティング・デバイスと別のコンピューティング・システムとの間の無線接続の確立及び維持は、任意に長時間可能である訳ではない。あいにく、携帯用コンピューティング・デバイスにメディア・データ（オーディオ、ビデオ及びテキスト・データ、並びにそれらの組合せ）を提供するには、ユーザがそのメディアと関わっている間中、通信チャネルが開いた状態のままであることが必要である。例えば、携帯用コンピューティング・デバイスに無線で転送された３分の長さの歌を聞くには、少なくとも３分の無線通信の維持が必要である。さらに、メディア・データの所有者の知的所有権を防御しようとする試みが、携帯用コンピューティング・デバイスが無線通信チャネルを維持する必要がある時間長を、さらに増大させる。
【０００６】
従って、携帯用コンピューティング・デバイスのユーザは、デバイスの内部電源の枯渇について心配せずに、メディア・データを実行するのに必要な時間長に対する制限も無しで、様々な形態のメディア・データを楽しむことができる、改良された携帯用コンピューティング・デバイスがあれば、有効である。もちろん、メディア・データの知的所有権の所有者もまた、携帯用コンピューティング・デバイス上でのメディア・データの使用の増大を望んではいるが、これらの所有者は、携帯用コンピューティング・デバイスに提供されるメディア・データに対する彼等の所有権を危険にさらしたいとは考えてはいない。
【０００７】
【課題を解決するための手段】
本発明の実施例は、携帯用コンピューティング・デバイス上のメディア・データの再生をしている間中、ストリーミング・メディアのソースへの無線接続を維持するように要求せずに、携帯用コンピューティング・デバイスにストリーミング・メディアを提供する。携帯用コンピューティング・デバイスは、少なくとも２つの部分でメディア・ファイルを受信し、メディア・ファイルを形成するためにそれらの部分を組み立てて、そしてメディア・ファイルの所有者の知的所有権を保護するためにメディア・ファイルを再生した後でメディア・ファイルを破壊する。携帯用コンピューティング・デバイスは、通常、別個の２つの通信チャネル上で２つのファイル部を受信する。いくつかの実施例では、通信チャネルの少なくとも１つが無線通信チャネルで、いったん第２のファイル部が受信されたならば、携帯用コンピューティング・デバイスが、デバイスの無線の送受信サブシステムを停止させることによって、デバイス内の電力消費を減少させるように設定される。携帯用コンピューティング・デバイスは、無線でデータを得る能力を持つ、手持ち式のコンピュータ、電話、ページャー、携帯情報端末（「ＰＤＡ」）、及び他の同じようなコンピューティング・デバイスを含む。メディア・ファイルは、オーディオ、ビデオ、及び（又は）テキストデータのフォーマットを含む。
【０００８】
さらに本発明の実施例は、携帯用コンピューティング・デバイス内でメディア・ファイルを再生する方法を提供する。その方法は、第１の通信チャネルを介して携帯用コンピューティング・デバイス内に第１のファイル部を受信する。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。第２のファイル部は、第２の通信チャネルを介して携帯用コンピューティング・デバイス内に受信される。ただし、第２のファイル部はメディア・ファイルとして使用不可能である。その後、メディア・ファイルが、第１のファイル部及び第２のファイル部から携帯用コンピューティング・デバイス内で作成される。
【０００９】
また本発明の実施例は、メディア・データを携帯用コンピューティング・デバイスに転送するための準備をする方法を提供する。その方法は、メディア・ファイルからエレメントを取り除くことによって第１のファイル部を作成するステップと、メディア・ファイルから取り除かれたエレメントから第２のファイル部を作成するステップとを含む。また第２のファイル部は、本発明の実施例に従って、メディア・ファイルを再度作成する際に必要な配列情報を保持する。
【００１０】
さらに本発明の実施例は、クライアント・コンピューティング・デバイスに第１のファイル部を要求するように構成されるメディア・クライアントを含む、携帯用コンピューティング・デバイスを提供する。また携帯用コンピューティング・デバイスは、無線通信チャネル上で第２のファイル部を受信するトランシーバを含む。第１及び第２のファイル部は、メディア・ファイルとして使用不可能である。さらにメディア・クライアントは、第１のファイル部及び第２のファイル部を使用して、メディア・ファイルを組み立てるように構成される。
【００１１】
本発明の実施例は、第１の通信チャネル上で第１のファイル部を受信するための第１の受信手段を含むメディア再生デバイスを提供する。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。また、メディア再生デバイスは、第２の通信チャネル上で第２のファイル部を受信するための第２の受信手段を含む。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。メディア再生デバイス内のメディア・アセンブリ手段は、第１のファイル部及び第２のファイル部からメディア・ファイルを組み立てる。
【００１２】
さらに本発明の実施例は、携帯用コンピューティング・デバイスにメディア・データを転送するためのメディア・サーバを提供する。メディア・サーバは、メディア・ファイルからエレメントを取り除くことによって第１のファイル部を作成する手段を持つ。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。またメディア・サーバは、メディア・ファイルから取り除かれたエレメントから第２のファイル部を作成する手段を含む。ただし、第２のファイル部はメディア・ファイルとして使用不可能である。
【００１３】
また本発明の実施例は、携帯用コンピューティング・デバイス上のメディア・ファイルを処理するためのメディア・クライアントを提供する。メディア・クライアントは、第１の通信チャネル上で第１のファイル部を要求する第１のファイル・マネージャを含む。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。メディア・クライアント上の第２のファイル・マネージャは、第２の通信チャネル上で第２のファイル部を要求する。ただし、第２のファイル部もまたメディア・ファイルとして使用不可能である。またメディア・クライアントは、第１のファイル部及び第２のファイル部からメディア・ファイルを復元するメディア・ファイル復元器を含む。
【００１４】
携帯用コンピューティング・デバイスに関連するメディア・クライアントによる実行用のメディア・データを提供するために、本発明の実施例はさらに、携帯用コンピューティング・デバイスとの接続の際に使用するためのコンピュータ・プログラム製品を提供する。携帯用コンピューティング・デバイスは、コンピュータ・プログラム製品を格納するメモリを含む。コンピュータ・プログラム製品は、複数のデータ・エレメントの除去によってメディア・データとして使用不可能にされた第１のファイル部を含む。またコンピュータ・プログラム製品は、メディア・クライアントによって再生されることのできるメディア・ファイルを生成するために、第１のファイル部から取り除かれた複数のデータ・エレメントと、取り除かれた複数のデータ・エレメントが第１のファイル部内のどこに配置されるべきであるかを説明する配列情報とを保持する第２のファイル部を含む。
【００１５】
また本発明の実施例は、メディア・ファイルを再生するために携帯用コンピューティング・デバイスを制御するための命令を保持するコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体の命令は、第１の通信チャネルを介して携帯用コンピューティング・デバイス内に第１のファイル部を受信するステップを含む。ただし、第１のファイル部はメディア・ファイルとして使用不可能である。またその命令は、第２の通信チャネルを介して携帯用コンピューティング・デバイス内に第２のファイル部を受信するステップを含む。ただし、第２のファイル部もまたメディア・ファイルとして使用不可能である。さらにその命令は、第１のファイル部及び第２のファイル部から、携帯用コンピューティング・デバイス内でメディア・ファイルを作成するステップを含む。
【００１６】
【発明の実施の態様】
本発明の実施例は、携帯用コンピューティング・デバイス上でのメディアの実行に渡って、ストリーミング・メディアのソースとの無線接続を維持し続けることを必要とすることなく、携帯用コンピューティング・デバイスにストリーミング・メディアを提供する。本発明の実施例に従って、携帯用コンピューティング・デバイスは、少なくとも２つの部分でメディア・ファイルを受信し、メディア・ファイルを形成するためにそれらの部分を組み立て、メディア・ファイルの所有者の知的所有権を保護するためにそれを破壊する前に、メディア・ファイルを再生する。携帯用コンピューティング・デバイスは、データを無線で得る能力を持つ、手持ち式のコンピュータ、電話、ページャ、携帯情報端末（「ＰＤＡ」）、及び他の同じようなコンピューティング・デバイスを含む。メディア・ファイルは、オーディオ、ビデオ、及び（又は）テキスト・データのフォーマットを含む。
【００１７】
携帯用コンピューティング・デバイスは、通常、デバイスの内部電源に負荷がかかっていない間に、及び（又は）高帯域通信チャネルを介して、メディア・ファイルの第１の部分を得る。例えば、クライアント・コンピュータは、携帯用コンピューティング・デバイスが有線の通信チャネルを介してクライアント・コンピュータに接続されている間、及び携帯用コンピューティング・デバイスが外部電源から電力供給されている間に、携帯用コンピューティング・デバイスに第１の部分を転送する。メディア・サーバは、通常、ディスエーブル状態のメディア・ファイルから第１の部分を形成し、第１の部分からメディア・ファイルを復元する際に役立つ情報を持った、第１の部分より通常は小さい第２の部分を形成する。ユーザがメディア・ファイルを再生したい場合、携帯用コンピューティング・デバイスが既に第１の部分を保有していれば、携帯用コンピューティング・デバイスは、第２の部分を受け取る間だけ、無線の受信デバイスを単に稼動させるだけでよい。
【００１８】
本発明の実施例は、このサブシステムがストリーミング・メディア・データを受信する時に、携帯用コンピューティング・デバイスの無線による送受信サブシステム（例えばトランシーバ）内の電力消費を減少させる。携帯用コンピューティング・デバイス内の電力節約を有効にすることは、一般に有利である。例えば、Ｒｉｏ ＭＰ３プレーヤのような、オーディオあるいはビデオ再生デバイス内のメディア再生チップは、通常、ＡＡバッテリで１０〜１５時間動作する。ＱｕａｌｃｏｍｍのＭＳＭ３３００チップセットによって可能となった無線デバイスのように、ＭＰ３の再生能力及びストレージを備えた新しい無線デバイスが発表されたことで、電力効率が良好なやり方でメディア・データにアクセスする要望が増大した。ストリーミングされるファイルの大きさを減少させることは、ファイルを受信する際に消費される電力量を減少させることができる。従って、メディア・サーバは、ＭＰ３ファイルをストリップし（取り外し）、取り外されたデータと再結合されるまで、それらを使用不可能にしておく。上記の第２のファイル部である、取り除かれたデータを保持しているファイルは、Ｅｓｓｅｎｔｉａｌ Ｍｅｄｉａ（ＥＭ）ファイルとして知られている。上記の第１のファイル部である、そこからデータが取り除かれたファイルは、Ｒｅｓｉｄｕａｌ Ｍｅｄｉａ（「ＲＭ」）ファイルとして知られている。メディア・ファイルを明確化しないＲＭファイルは、ユーザがメディア・ファイルを再生することを望むより前に、携帯用コンピューティング・デバイスに提供される。携帯用コンピューティング・デバイスのユーザがメディア・ファイルを再生したい時、携帯用コンピューティング・デバイスは、メディア・データファイル全体というよりも、それより小さなＥＭファイルを受信するための送受信サブシステムを必要とするだけなので、携帯用コンピューティング・デバイス内の全体的な電力消費が減少する。
【００１９】
ＲＭファイルは、通常、ＥＭファイルより時々はるかに大きい。携帯用コンピューティング・デバイスは、ＲＭファイルを受信し、メモリにそれらを格納する。本発明の実施例に従って、ＲＭファイルは有線のソース及び無線のソースの両方から提供されることができ、ＥＭファイルより先に受信される。いったんＥＭファイルが受け取られたならば、携帯用コンピューティング・デバイス上のメディア・クライアント・ソフトウエアは、ＲＭファイル及びＥＭファイルからメディア・ファイルを復元する。例えば、その後、携帯用コンピューティング・デバイス上のメディア・クライアント・ソフトウエアは、ユーザのために再生されるＭＰ３ファイルを再構築するために、ＲＭファイル及びＥＭファイルを結合する。メディア・クライアント・ソフトウエアは、メディア・ファイルがユーザに再生されると、メディア・ファイルを削除する。
【００２０】
上述したＭＳＭ３３００チップセットを使用する本発明の実施例は、さらに、携帯用コンピューティング・デバイス内の内部電力消費がいかに減少するかを示す。典型的なＭＰ３ファイルに対応するＥＭファイルは、通常約３０ＫＢでかなり小さく、最も携帯的なコンピューティング・デバイス内の受信器でも、わずか２、３秒で、ＥＭファイルの受信を完了することができる。基地局トランシーバとの接続の確立によりＥＭファイルを受信するために、携帯用コンピューティング・デバイスは、ＲＦＲ３３００、ＲＦＴ３１００、ＩＦＲ３３００、又はＰＡ３１００デバイスのようなその送受信回路を単に稼動させる。いったんＥＭファイルが携帯用コンピューティング・デバイス上に受信されたならば、送受信回路は出力を低下させられるか、又は電力を節約するためのスリープ・モードに入る。典型的なＭＰ３ファイルを再生するのに、通常は約３〜４分かかる。メディア・クライアント・ソフトウエアがメディア・ファイルを再生し終えた時、メディア・クライアント・ソフトウエアは、別のメディア・ファイル用に次のＥＭファイルを受信するために、再び電力を上げるよう送受信回路に指令する。もちろん、本発明のいくつかの実施例では、メディア・クライアント・ソフトウエアが、デバイスの送受信回路に再電力投入がなされる前に、いくつかのメディア・ファイルを復元し再生することができるよう、１つ以上のＥＭファイルが携帯用コンピューティング・デバイスに一度に提供される。メディア・クライアントがメディア・ファイルの実行をオフ・ラインにするように（例えば、ＥＭファイルを提供したメディア・サーバへの接続をアクティブにしないように）設定されている場合、メディア・クライアントは、メディア・ファイルの知的財産の所有者のためのロイヤルティの支払いを決定するための、メディア・ファイルが再生された回数を判定するカウンタを含む。
【００２１】
図１Ａは、本発明の実施例に従った、メディア・サーバ１０３からクライアント・コンピュータ１０５にメディア・ファイルの部分を配信するためのシステムのブロック・ダイアグラムである。メディア・サーバ１０３は、データ・レポジトリ１０１からメディア・ファイル１１９を取り出す。メディア・サーバ１０３は、アクセス権を持たない人々によってファイルが使用されたり、メディア・ファイル１１９への制限された使用権限しか持たない人々によって誤用されるのを防ぐやり方で、メディア・ファイル１１９を処理する。今まで言及されたように、メディア・サーバ１０３は、ＲＭファイル１２５を生成するためにメディア・ファイル１１９から、データを取り除く。本発明の実施例に従って、ＲＭファイル１２５は、どこからデータが取り除かれたかも、取り除かれたデータが何を含んでいたかも知らない者にとっては、使用不可能である。本発明の実施例に従って、セキュリティを追加する方策として、メディア・サーバ１０３はＲＭファイル１２５を暗号化する。例えば、ＲＭファイル１２５は、取り除かれる情報に由来したキーを使用して暗号化される。
【００２２】
ユーザは、いろいろな方法で、クライアント・コンピュータ１０５と携帯用コンピューティング・デバイス１０７との間のデータ接続１１１を作り出す。例えば、ユーザは、ドッキング・ステーション、すなわちクライアント・コンピュータ１０５と結び付ける同期用のクレイドルに、携帯用コンピューティング・デバイス１０７をはめ込むか、又は、周辺機器ポートを介してクライアント・コンピュータ１０５に携帯用コンピューティング・デバイス１０７を接続する。もちろん、携帯用コンピューティング・デバイスが適切なインターネット・プロトコルを処理するように構成されていれば、クライアント・コンピュータ１０５無しで、携帯用コンピューティング・デバイス１０７をインターネットにダイレクトに接続することも可能である。そのような実施例においては、例えば、クレイドルが、ＤＳＬモデム、ケーブル・ボックス、又はインターネット・アプリケーションに接続されることもできる。また、携帯用コンピューティング・デバイス１０７にデータを転送することが携帯用コンピューティング・デバイスのバッテリを枯渇させるので、クライアント・コンピュータ１０５と携帯用コンピューティング・デバイス１０７とを接続することは、携帯用コンピューティング・デバイス１０７に電源を提供することになる。
【００２３】
クライアント・コンピュータ１０５上のクライアント・モジュール１２３は、メディア・サーバ１０３との通信を確立する。クライアント・モジュール１２３は、メディア・サーバ１０３が、データ・レポジトリ１０１からクライアント・コンピュータ１０５にＲＭファイルを転送するよう要求する。クライアント・コンピュータ１０５とメディア・サーバ１０３との間の通信チャネルは、極めて高帯域である。クライアント・モジュール１２３は、ユーザのリクエストに基づいて行うのと同様に、所定の間隔でも、ＲＭファイル１２５を要求するようにプログラムされる。従って、クライアント・モジュール１２３は、携帯用コンピューティング・デバイスに関連するクライアント・コンピュータ１０５なしでも、ＲＭファイルを取り出すことができる。そのような環境では、クライアント・モジュール１２３は、クライアント・コンピュータ１０５に関連するメモリ内にＲＭファイル１２５を格納する。
【００２４】
携帯用コンピューティング・デバイス１０７に関連するメディア・クライアント１１７が、クライアント・コンピュータ１０５にＲＭファイル１２５を要求する。代案として、クライアント・モジュール１２３が、ＲＭファイル１２５を携帯用コンピューティング・デバイス１０７に配信してもよい。メディア・クライアント１１７は、携帯用コンピューティング・デバイス１０７上のメモリ１２９にＲＭファイル１２５を格納する。ＲＭファイル１２５は、メディア・ファイル１１９を再構築するために、対応するＥＭファイル１２７と結合されるまでのしばらくの間、携帯用コンピューティング・デバイス１０７上に留まる。
【００２５】
図１Ｂは、本発明の実施例に従った、メディア・サーバ１０３から携帯用コンピューティング・デバイス１０７にＥＭファイルを転送するためのシステムを示すブロック図である。上述したように、携帯用コンピューティング・デバイス１０７は、通常、ＥＭファイル１２７を受信する前にＲＭファイル１２５を受信する。携帯用コンピューティング・デバイス１０７のユーザがメディア・クライアントの機能を使う時、メディア・クライアント１１７は、ＲＭファイル１２５に対応するＥＭファイル１２７のセットを判定するために、そのメモリ１２９に格納された任意のＲＭファイル１２５にアクセスする。
【００２６】
ユーザがメディア・サービスを開始する場合、携帯用コンピューティング・デバイス１０７上のメディア・クライアント１１７は、トランシーバ１２１を通して、メディア・サーバ１０３に関連するトランシーバ１１３と無線通信１１５を開始する。メディア・クライアント１１７は、あらかじめダウンロードされるＲＭファイル１２５に対応するＥＭファイル１２７のすべて又はいくらかの部分を要求する。ＥＭファイル１２７が携帯用コンピューティング・デバイス１０７に到着すれば、メディア・クライアント１１７はメディア・サーバ１０３との無線通信１１５を終了する。
【００２７】
メディア・クライアント１１７がＥＭファイル１２７を得たならば、音楽再生プロセスが始まる。メディア・クライアント１１７は、ＲＭファイル１２５及びＥＭファイル１２７を使用して、メディア・ファイル１１９を復元する。メディア・クライアント１１７は、携帯用コンピューティング・デバイス１０７に関連する適切な出力を通して、メディア・ファイル１１９の再生を始める。対応する再生リスト内のメディア・ファイルがすべて実行されるまで、再生プロセスが繰り返される。一度メディア・クライアント１１７が全メディア・ファイル１１９を実行したならば、携帯用コンピューティング・デバイス１０７上のメディア・ファイル転送プロセスの別の繰り返しが始まる。
【００２８】
携帯用コンピューティング・デバイス１０７は、トランシーバ１２１を、メディア・サーバ１０３に関連するトランシーバ１１３との無線通信を確立するために使用する。通信が確立されたならば、メディア・クライアント１１７は、メディア・サーバ１０３に適切なＥＭファイル１２７を要求する。メディア・クライアント１１７は、任意の必要な口座及び（又は）支払い情報に加えて、要求されたＥＭファイル１２７を識別する。ＥＭファイル１２７を受信するためのメディア・クライアントの認証を確認した後に、メディア・サーバ１０３は、データ・レポジトリ１０１内の適切なＥＭファイル１２７を捜し出すために、メディア・クライアント１１７によって提供される識別情報を使用する。メディア・サーバ１０３は、ＥＭファイル１２７をトランシーバ１１３に転送する。トランシーバ１１３は、トランシーバ１２１を通して、携帯用コンピューティング・デバイス１０７にＥＭファイル１２７を転送する。
【００２９】
一度メディア・クライアント１１７がＥＭファイルの受信を確認すれば、メディア・クライアント１１７は、本発明の実施例に従って、トランシーバ１２１に、トランシーバ１１３から切断してシャットダウンするよう命じる。ＥＭファイル１２７は、比較的小さなファイルであり、それらの転送は、対応するＲＭファイルの転送よりも、はるかに速く実行される。
ＥＭファイルを受信した後、メディア・クライアント１１７は、ＲＭファイル１２５及びＥＭファイル１２７から、メディア・ファイルを復元する。復元は、基本的に、元のメディア・ファイル１１９からＲＭファイル１２５とＥＭファイル１２７を作成するために使用されたステップを逆行するステップである。上述したように、ＥＭファイル１２７の実施例は、メディア・ファイル１１９を再編成するための命令を含む。またメディア・ファイルを復元する際に、メディア・クライアントは、ファイルが再生された回数についてのカウンタを維持するような知的所有権に注意を向ける。
【００３０】
メディア・クライアント１１７は、様々なフォーマットで、ユーザにメディア・ファイル１１９を提供する。例えば、メディア・クライアント１１７は、ユーザに再生リストを提供したり、又はユーザに対してメディア・ファイル１１９を単に再生し始める。メディア・クライアント１１７は、ユーザに再生を行った後に続いて、メディア・ファイル１１９又はそれの一部を破壊するよう装備されている。メディア・ファイル１１９の破壊が、メディア・ファイルの所有者の様々な知的所有権を保護する。
【００３１】
図１Ｃは、本発明の実施例に従った、携帯用コンピューティング・デバイス１０７を図示するブロック図である。携帯用コンピューティング・デバイス１０７は、メモリ１２９、トランシーバ１２１、及びメディア・クライアント１１７を含む。
メディア・クライアント１１７は、メディア・クライアントのための様々なタスクを実行するように設定された様々なモジュールを含む。ＲＭファイル・マネージャ１３１は、携帯用コンピューティング・デバイス１０７上にＲＭファイルを取り出し、メモリ１２９にそれらを格納する。メディア・クライアント１１７がＲＭファイル・マネージャ１３１を使う場合、ＲＭファイル・マネージャ１３１は、携帯用コンピューティング・デバイス１０７が、図１Ａで示されるクライアント・コンピュータ１０５のようなクライアント・コンピュータとの接続を確立しているかどうかを最初に判定する。ＲＭファイル・マネージャ１３１がクライアント・コンピュータの接続を発見できない場合、ファイル・マネージャ１３１は、トランシーバ１２１を使用する無線接続を通してＲＭファイルを得ようと試みる。
【００３２】
同様に、ＥＭファイルマネージャ１３３は、携帯用コンピューティング・デバイス１０７上にＥＭファイルを取り出す。いくつかの実施例では、ＥＭファイルが直ちに使用されて、メモリ１２９には格納されない場合もあるが、ＥＭファイルマネージャ１３３は、メモリ１２９にＥＭファイルを格納するよう構成される。メディア・クライアント１１７がＥＭファイル・マネージャ１３３を使う場合、ＥＭファイルマネージャ１３３は、得られる必要のある相補的なＥＭファイルのセットを識別するために、もしあるならば、どのようなＲＭファイルがメモリ１２９に格納されているのかを判定する。ＥＭファイル・マネージャ１３３は、携帯用コンピューティング・デバイス１０７が、図１Ａで示されるクライアント・コンピュータ１０５のようなクライアント・コンピュータとの接続を確立しているかどうかを判定する。ＥＭファイル・マネージャ１３３がクライアント・コンピュータとの接続を発見できない場合、ＥＭファイル・マネージャ１３３は、トランシーバ１２１を使用する無線接続を通して、ＥＭファイルを得ようと試みる。
【００３３】
メディア・ファイル・レコンストラクタ（復元器）１３５は、ＲＭファイルを取り、それに合致するＥＭファイルを見つけ、元のメディア・ファイルを復元する。メディア・ファイル・プレーヤ１３７は、メディア・ファイルを再生、又は実行する。メディア・ファイル・プレーヤ１３７及びメディア・ファイル・レコンストラクタ１３５は、携帯用コンピューティング・デバイス１０７上に、メディア・ファイルの完全なコピーが一時たりとも決して存在しないように、共同して作業するよう構成される。例えば、メディア・ファイル・レコンストラクタ１３５は、メディア・ファイルの１つのセクション（例えば、全体のメディア・ファイルよりも小さい再生可能な量のメディア・ファイル）を復元し、それが再生されると直ちに、そのセクションを削除するメディア・ファイル・プレーヤ１３７に、そのセクションを提供する。メディア・ファイル・プレーヤ１３７が１つのメディア・ファイル・セクションを演奏している間、メディア・ファイル・レコンストラクタ１３５は、再生される次のメディア・ファイル・セクションを復元する。メディア・ファイルのセキュリティがさほどの関心事ではない本発明の実施例では、メディア・ファイル・レコンストラクタ１３５が、メディア・ファイルを復元し、復元されたメディア・ファイルをメディア・ファイル・プレーヤ１３７に提供するように設定される。
【００３４】
トランシーバ・コントローラ１３９は、トランシーバ１２１への命令を提供する。例えば、トランシーバ・コントローラ１３９は、ＲＭファイル又はＥＭファイルの受領があると、出力を低下させるか、又はスリープ・モードに入るようトランシーバ１２１に命令する。トランシーバ１２１内の電力消費量を削減することは、携帯用コンピューティング・デバイスの内部電源（例えばそのバッテリ）の有効寿命を延ばす。トランシーバ・コントローラ１３９は、メディア・サーバ及び他のファイル供給の中継器から、ＲＭファイル及びＥＭファイルを得る際に、ＲＭファイル・マネージャ１３１及びＥＭファイル・マネージャ１３３と共に動作する。例えば、本発明のいくつかの実施例では、１つの携帯用コンピューティング・デバイスから別のそれにファイルを送るＩＲトランシーバのような接続を使用して、他の携帯用コンピューティング・デバイスから、ＲＭファイルが得られる。トランシーバ・コントローラ１３９はまた、携帯用コンピューティング・デバイス１０７上の１つ以上のトランシーバと共に動作するように設定される。
【００３５】
図２Ａは、メディア・ファイル２０１を示す。メディア・ファイル２０１は、ビデオ・データ、オーディオ・データ、及びテキスト・データのような、様々なタイプ及びフォーマットを持つデータを含む。メディア・ファイル２０１は、通常、ファイルのコンテンツ及び構成を記述するヘッダ２２１を含む。
図２Ｂは、本発明の実施例に従った、ＲＭファイルを形成するためにメディア・サーバによって取り除かれるメディア・ファイル２０１の部分２０３を示す。取り除かれる部分２０３は、ヘッダ２２１、及び所定の式に従って選択されたファイルの他の部分を含む。例えば、１つの式は、Ｘバイト間隔で除去を指示する。ただし、Ｘは５０を越える正整数である。情報除去のスキームが、ＥＭファイルに組み込まれるか、又は他のある方式でメディア・クライアントに提供されるので、式は殆どランダムである。いずれにしても、メディア・クライアント１１７は、ＲＭファイルからメディア・ファイルを復元する時に、情報除去スキームにアクセスする。
【００３６】
図２Ｃは、本発明の実施例に従った、取り除かれた部分２０７を持つＲＭファイル２０５を示す。取り除かれた部分２０７は、すべて０か、すべて１か、又は別の任意のものであるか、そうでなければ無意味なパターンを保持する。またＲＭファイル２０５は、取り除かれた部分２０７用の充てん文字なしで、メディア・ファイル２０１から作成されてもよく、そのような実施例では、ＲＭファイル２０５は、一般に、取り除かれた部分２０７の合計だけ、元のメディア・ファイルより小さい。いずれにしても、ＲＭファイル２０５を調べる人もコンピュータ・プログラムも、メディア・データを保持しているものとしてそのファイルを識別するいかなる情報も見い出せないだろう。ファイルがメディア・データを保持していたと人が推測しても、人は元のメディア・ファイルに対するファイル・ヘッダ情報すら持っていないことになる。人がなんとかしてファイル・ヘッダを復元することができたと仮定しても、人は、どのメディア・データが取り除かれたのか、又はどこからそれが取り除かれたのかが、さらに分からないだろう。しかしながら、いくつかの実施例では、セキュリティ階層を追加するために、ＲＭファイル２０５が暗号化される。暗号化キーがさらに、取り除かれた部分２０３から引き出される。また図２Ｃは、少なくとも一部がメディア・ファイル２０１の取り除かれた部分２０３によって構築されたＥＭファイル２０９を示す。
【００３７】
図２Ｄは、本発明の実施例に従った、ＥＭファイル２０９の構成要素を示す。上述したように、ＥＭファイル２０９は、ＲＭファイル２０５から、メディア・ファイル２０１を復元する際にメディア・クライアントによって必要とされる情報を保持している。ＥＭファイル２０９は、ＲＭファイル２０５を復号化するために、メディア・クライアントによって使用される１つ以上のキー２１１を保持している。ＥＭファイル２０９は、メディア・ファイル２０１を再構築するために、取り除かれた部分２１５をＲＭファイル２０５のどこに、どのように追加すべきであるかを説明する配列情報２１３を保持している。上述したように、メディア・クライアントは、ファイルが再生されている間に、メディア・ファイル２０１を再構築し、それらが再生されると直ちに、メディア・ファイル２０１の再生された部分を破壊する。この方式で、メディア・クライアントは、メディア・ファイル２０１をコピーしようとする不正な試みを阻止する。
【００３８】
本発明の実施例は、メディア・ファイルから情報を取り除くことにより、及びファイルの暗号化により、メディア・ファイル２０１の知的所有権を保護する。本発明の別の代案となる実施例では、メディア・ファイルが暗号化だけで保護される一方で、本発明の代案となる実施例では、メディア・ファイルが、メディア・ファイルから情報を単に取り除くことによって保護される。図２Ｅ及び２Ｆは、それぞれ、本発明の実施例に従った、暗号化されたメディア・ファイルを表す対応するＲＭファイル２１７と、ＲＭファイル２１７用の復号化キーを保持しているＥＭファイル２１９と共に、メディア・ファイル２２３を示す。ＲＭファイル２１７は、メディア・ファイル２２３を不正なユーザから保護するために、暗号化技術だけで十分に設計される状況に対して適用される。例えば、メディア・ファイル２２３の暗号化されていないバージョンが、１個の全体として、携帯用コンピューティング・デバイス上に存在しないように、メディア・クライアントがファイルを再生しながら、ＲＭファイル２１７の小さな部分を復号化するよう適応されるならば、この実施例は有用である。
【００３９】
図３は、本発明の実施例に従った、メディア・サーバ１０３からメディア・ファイル・コンポーネント、例えばＲＭ及びＥＭファイルを、受信する複数の携帯用コンピューティング・デバイス１０７を示すブロック図である。図１Ａ及び１Ｂは、単一の携帯用コンピューティング・デバイス１０７が、どのようにしてメディア・ファイル・コンポーネント（例えばＲＭファイル及びＥＭファイル）を受信するかを示した。もちろん、本発明の実施例は、複数の携帯用コンピューティング・デバイス１０７に、複数の異なるＲＭファイル及びＥＭファイルを提供するように設定されたメディア・サーバ１０３を含む。
【００４０】
メディア・サーバ１０３は、複数のクライアント・コンピュータ１０５から、ＲＭファイル要求を受け取る。クライアント・コンピュータ１０５は、全体的なシステム構成及び利用者の好みに依存して、同じメディア・ファイルに対応するか、又は、異なるメディア・ファイルに対応するＲＭファイルを要求する。従って、別のクライアント・コンピュータ１０５がチベットの伝統的な舞踏のビデオに対応するＲＭファイルを要求する一方で、２つのクライアント・コンピュータ１０５が、ブルース音楽のコレクションに対応するＲＭファイルを要求してもよい。今まで説明されるように、様々なクライアント・コンピュータ１０５上に受信されるＲＭファイルは、対応する携帯用コンピューティング・デバイス１０７に転送される。例えば、クライアント・コンピュータ１０５及び携帯用コンピューティング・デバイス１０７は、ドッキング・ステーション、あるいは同期用のクライドルを通して、データ伝送接続を確立する。
【００４１】
携帯用コンピューティング・デバイス１０７がクライアント・コンピュータ１０５に接続されている間に、メディア・ファイルを再生することを望む携帯用コンピューティング・デバイスのユーザは、通常はクライアント・コンピュータ１０５を通してＲＭファイルに対応するＥＭファイルを得る。クライアント・コンピュータ１０５によって提供される通信チャネルは、携帯用コンピューティング・デバイス１０７に提供されることができる他の通信チャネル（例えば無線接続）より、通常は優れている。さらに、クライアント・コンピュータ１０５と携帯用コンピューティング・デバイス１０７との間のデータ接続は、携帯用コンピューティング・デバイス１０７にとって外部電源を意味する。従って、そのような状況では、ＥＭファイルはクライアント・コンピュータ１０５を通して得られてもよい。
【００４２】
携帯用コンピューティング・デバイス１０７がクライアント・コンピュータ１０５から切断される場合、携帯用コンピューティング・デバイス１０７は、トランシーバ１１３を介して無線でＥＭファイルを得る。一般に、ＥＭファイルの転送はすばやく達成されることができるので、トランシーバ１１３は多くの異なるＥＭファイルを、多くの異なる携帯用コンピューティング・デバイス１０７に伝送する。もちろん、メディア・サーバ１０３は、１つ以上のトランシーバ１１３を使用してもよいし、また、システムは、１つ以上のメディア・サーバ１０３を使用してもよい。
【００４３】
図３はまた、携帯用コンピューティング・デバイス１０７がＲＭファイルを得る別の方法を示す。１つの携帯用コンピューティング・デバイス１０７は、別の携帯用コンピューティング・デバイス１０７への無線接続３０１を確立するために１つのトランシーバ（例えばＩＲトランシーバ）を使用し、それから、別の携帯用コンピューティング・デバイス１０７にＲＭファイルを「送信する」。例えば、１人の友人が、彼女が楽しんだ音楽再生リストについて別の友人に伝え、それから、接続３０１を介して別の友人の携帯用コンピューティング・デバイス１０７に、対応するＲＭファイルを含む再生リストを送信する。その後、友人は上に説明された方法でＥＭファイルを得る。
【００４４】
図４は、本発明の実施例に従った、メディア・サーバと、クライアント・モジュールを装備したクライアント・コンピュータと、メディア・クライアントを装備した携帯用コンピューティング・デバイスとの間での、メディア・ファイル・コンポーネントの処理を示すダイアグラムである。
メディア・サーバは、今まで説明されたようなメディア・ファイル（例えば図２Ａ−２Ｆ）から、ＲＭファイル及びＥＭファイルを準備して（ステップ４０１）、データ・レポジトリにそれらを格納する。ある程度の後、クライアント・コンピュータは、メディア・サーバにＲＭファイルを要求する（ステップ４０３）。メディア・サーバは、データ・レポジトリからＲＭファイルを取り出し（ステップ４０５）、クライアント・コンピュータにそれらを送信する。その後、クライアント・コンピュータは、メディア・サーバから受信されたＲＭファイルを格納する（ステップ４０７）。
【００４５】
携帯用コンピューティング・デバイスがクライアント・コンピュータと接続される（例えば同期用の受け台を介して）場合、携帯用コンピューティング・デバイスのメディア・クライアントは、クライアント・コンピュータにＲＭファイル要求を送る（ステップ４０９）。クライアント・コンピュータは、ＲＭファイル要求を受け取り、メモリ内に格納されている任意のＲＭファイルを捜し出し、そのＲＭファイルを携帯用コンピューティング・デバイスに送る（ステップ４１１）。携帯用コンピューティング・デバイスは、ＲＭファイルを受け取り、それらをローカルメモリに格納する（ステップ４１３）。
【００４６】
後に、通常は、携帯用コンピューティング・デバイスがクライアント・コンピュータから切断された後に、携帯用コンピューティング・デバイスのユーザは、携帯用コンピューティング・デバイス上に格納されたＲＭファイルに対応するメディア・ファイルの再生を選択する。携帯用コンピューティング・デバイス上のメディア・クライアントは、メディア・サーバとの無線通信を開始する（ステップ４１５）。メディア・サーバはその通信を受け取り、メディア・クライアントは、２つのデバイス間の通信を同期させる（ステップ４１７）。その後、メディア・クライアントは、メディア・サーバに格納されたＲＭファイルに関連するＥＭファイルを要求する。任意の適切なセキュリティ及び（又は）支払い手続を完了した後に、メディア・サーバは、適切なＥＭファイルを捜し出し、それらを携帯用コンピューティング・デバイスに送る（ステップ４１９）。
【００４７】
携帯用コンピューティング・デバイスがＥＭファイルを受信した後、メディア・クライアントは、メディア・サーバとの無線通信を切断する（ステップ４２１）。いったんＥＭファイルが受信されて、この接続を終了すると、通常は、携帯用コンピューティング・デバイス内の電力消費が減少する。その後、メディア・クライアントは、ＲＭファイル及びＥＭファイルから、メディア・ファイルの復元４２３を指示する。その後、携帯用コンピューティング・デバイスは、復元されたメディア・ファイルをユーザのために再生する。
【００４８】
図５は、本発明の実施例に従った、クライアント・コンピュータ上のクライアント・モジュールによって引き起こされるプロシージャを図示するフローチャートである。例えば、このプロシージャは、図１Ａで示されるクライアント・コンピュータ１０５上のライアント・モジュール１２３によって使用される。
本発明の実施例に従って、クライアント・モジュールは、クライアント・モジュールのクライアント・コンピュータに接続された任意の携帯用コンピューティング・デバイスが、メディア・サーバとの、メディア・ファイル・コンポーネントに関わる無線通信中であるかどうかを判定する（ステップ５０１）。クライアント・モジュールは、携帯用コンピューティング・デバイス上のメディア・クライアントに適切な問合せを送ることによって、この判定を下す。携帯用コンピューティング・デバイスがメディア・サーバと無線通信中である場合、クライアント・モジュールは、携帯用コンピューティング・デバイスにメディア・サーバとの無線通信を終了させるように信号を送る（ステップ５０３）。携帯用コンピューティング・デバイスに関連するメディア・クライアントは、その無線通信を継続させることを選択してもよいが、そのような通信は、通常、クライアント・コンピュータがメディア・サーバと通信することができる効率で通信することはできない。さらに、無線通信は、携帯用コンピューティング・デバイスの内部電源（例えばバッテリ）をかなり消費する。どんな場合も、クライアント・モジュールの実施例は、そのようなチェックは携帯用コンピューティング・デバイス上の内部電源をメディア・クライアントが温存するのを助ける上で有用であるが、携帯用コンピューティング・デバイスが無線通信中であるかどうかを判定するチェックを必ずしも行う必要はない。
【００４９】
クライアント・モジュールは、メディア・サーバからＲＭファイルを要求する（ステップ５０５）。クライアント・モジュールは、メディア・サーバのアドレスのリスト、並びに（あるいは）、クライアント及び（又は）特定のコンテンツ・タイプへのプロキシミティに基づいてメディア・サーバ・アドレスを分配するるメタ・メディア・サーバの識別を維持する。メディア・サーバは、クライアント・コンピュータにそれらを送信する前に、ＲＭファイルに対する要求を検証し確認する。またメディア・サーバは、パスワード又は支払いといったような他の情報を求める。クライアント・モジュールは、メディア・サーバからＲＭファイルを受信し（ステップ５０７）、そのＲＭファイルを通常はクライアント・コンピュータのメモリ内に格納する（ステップ５０９）。
【００５０】
クライアント・モジュールは、携帯用コンピューティング・デバイスがクライアント・コンピュータと通信中であるかどうかを判定する（ステップ５１１）。現在、クライアント・コンピュータが、ＲＭファイルを受信することができる携帯用コンピューティング・デバイスと接続されていないならば、クライアント・コンピュータは １つ以上の携帯用コンピューティング・デバイスにＲＭファイルを転送することに関する操作を終了する。クライアント・コンピュータが１つ以上の携帯用コンピューティング・デバイスと通信中である場合、クライアント・コンピュータは携帯用コンピューティング・デバイス１０７にＲＭファイルを転送する（ステップ５１３）。上述したように、ＲＭファイルは、通常、ＲＭファイルの対応するＥＭファイルより、元のメディア・ファイルの中のより大きな部分を占める。
【００５１】
クライアント・コンピュータは、周期的な間隔で、携帯用コンピューティング・デバイスをチェックし、ＲＭファイルを転送するタスクを実行するように構成される。例えば、携帯用コンピューティング・デバイスが、クライアント・コンピュータに関連するドッキングステーション又は同期用のクレイドルに置かれる時に、携帯用コンピューティング・デバイスに関連するメディア・クライアントは、クライアント・モジュールにＲＭファイル要求を送信する。クライアント・モジュールは、ＲＭファイル要求を受け取り、以前にクライアント・コンピュータ上に格納されたＲＭファイルを捜し出し、それらをメディア・クライアントに転送する。クライアント・モジュールがメディア・サーバにＲＭファイルを要求する時、携帯用コンピューティング・デバイスは、既にクライアント・コンピュータの同期用のクレイドルの中にある。そのような状況の中では、メディア・クライアントがＲＭファイルを要求するのを待つというのではなく、クライアント・モジュールがＲＭファイルを受け取り、それらを携帯用コンピューティング・デバイスに提供する。
【００５２】
図６は、本発明の実施例に従った、携帯用コンピューティング・デバイス上のメディア・クライアントが、ＲＭ及びＥＭファイルのようなコンポーネントからメディア・ファイルをどのようにして復元するかを示すフローチャートである。例えば、図１Ａで示されるメディア・クライアント１１７は、このプロシージャに従う。
メディア・クライアントは、メディア・サービスを始めるというユーザの命令を受信する（ステップ６０１）。メディア・クライアントは、携帯用コンピューティング・デバイスのメモリがＲＭファイルを保持しているかどうかを判定する（ステップ６０３）。携帯用コンピューティング・デバイスのメモリがＲＭファイルを保持していない場合、メディア・クライアントは、ＲＭファイルを得るために図７に説明されたようなプロシージャに従う。
【００５３】
携帯用コンピューティング・デバイスのメモリがＲＭファイルを保持している場合、メディア・クライアントは、メディア・サーバと無線通信を開始するために、携帯用コンピューティング・デバイスのトランシーバに指示する（ステップ６０５）。メディア・クライアントは、メディア・サーバ及び（又は）そのトランシーバとの、完了される必要のあるすべてのハンドシェイク及び（又は）同期プロシージャを開始する（ステップ６０７）及び完了するステップにおいて、そのトランシーバを支援する。これでメディア・クライアントはメディア・サーバと交信できる。
【００５４】
メディア・クライアントは、適切なセットの対応するＲＭファイルであるかを判定するためにＲＭファイルを調べる。メディア・クライアントは、メディア・サーバに、適切なＥＭファイルを要求する（ステップ６０９）。メディア・クライアントは、メディア・サーバからＥＭファイルを受け取り（ステップ６１１）、そのＥＭファイルを携帯用コンピューティング・デバイスに関連するメモリ内に格納する（ステップ６１３）。これでメディア・クライアントは、それのローカルな配置に、ユーザのためのメディア・ファイルを再組立てし実行するために必要となるファイル・コンポーネント（例えばＥＭ及びＲＭファイル）をすべて持つ。ＥＭファイルを受け取り、既にＲＭファイルをメモリ内に持っているので、本発明の実施例によれば、メディア・クライアントは、メディア・ファイルを元に戻すために、それ以上の情報を必要としない。さらに、無線通信を切断することは、携帯用コンピューティング・デバイス内の電力消費を低下させる目的を達成するのに役立つであろう。ここで、メディア・クライアントは、メディア・サーバとの無線接続を終了させる（ステップ６１５）。無線通信を終了すると、携帯用コンピューティング・デバイスの送信器はスリープ・モードに入るか、又は単に停止する。無線接続を終了すると、デバイスは、メディア・サーバとの接続を維持するバッテリ電力をもはや使う必要がないので、一般に携帯用コンピューティング・デバイス内の電力消費が減少する。
【００５５】
メディア・クライアントは、様々な方法でメディア・ファイルを復元する。１つの実施例では、メディア・クライアントはＲＭファイルを復元するためのロードマップとしてＥＭファイルを使用する。メディア・クライアントは、ＲＭファイル及びＥＭファイルを使用してメディア・ファイルを復元する（ステップ６１７）。メディア・クライアントは、ＲＭファイル及びＥＭファイルからメディア・ファイルを再編成するための方法を記述している命令を、ＥＭファイルから取り出す。例えば、メディア・ファイルは、ＲＭファイルを復号化するために使用されるキーをＥＭファイルから取り出す。一度メディア・クライアントがＲＭファイルを復号化したならば、ＥＭファイルの命令は、どこのメディア・データがＲＭファイルから取り除かれたか、どれだけのメディア・データが取り除かれたか、取り除かれたメディア・データはＥＭファイル内のどこで発見されるかを示す。
【００５６】
メディア・クライアントは、ユーザの指示でメディア・ファイルを再生する（ステップ６１９）。例えば、復元されたメディア・ファイルは、２０曲の歌を保持していても、ユーザは２０曲の歌のうちの単に１０曲だけを聞きたいと思う。メディア・ファイルの所有者に対して追加のセキュリティを保証するために、メディア・クライアントは、最後の可能な瞬間まで、メディア・ファイル又はファイルのいくつかの部分の組み立てを差し控えて、メディア・ファイル又はファイルの一部が再生されると直ちにそれらを破壊する（ステップ６２１）。メディア・クライアントは、特定のメディア・ファイル用の再生リストの終了が現れたかどうかを判定する（ステップ６２３）。再生リストが終了されない場合、メディア・クライアントは次のメディア・ファイル又はメディア・ファイルの次の一部を取り出す。
【００５７】
再生リストがその終了に達した場合、メディア・クライアントは、携帯用コンピューティング・デバイスのユーザがより多くのメディア・ファイルを受信したいのかどうかを判定する（ステップ６２５）。ユーザがより多くのメディア・ファイルを受信することを望まないのならば、メディア・クライアントはその操作を終了する。他方、ユーザがもっと多くのメディア・ファイルを受信したいと望むならば、メディア・クライアントは、図７に説明されたようなプロシージャに従って、より多くのＲＭファイルを取り出す必要がある。
【００５８】
図７は、本発明の実施例に従った、メディア・サーバからＲＭファイルを取り出す際の、メディア・クライアントの作用を示すフローチャートである。上述したように、ＥＭファイルはＲＭファイルより通常は小さい。従って、携帯用コンピューティング・デバイスは、通常、ＥＭファイルを受信するのに必要とされるものよりも、ＲＭファイルを受信するためのより高い帯域幅通信チャネルから、より多くの利益を得る。
【００５９】
メディア・クライアントは、ＲＭファイルのための中継ソースへの可能な接続を決定する（ステップ７０１）。例えば、携帯用コンピューティング・デバイスがクライアント・コンピュータと同期したならば、クライアント・コンピュータは、ＲＭファイル転送用の高帯域を十分に提供することによって、メディア・サーバへの適切な中継器としての役割を果たす。また、クライアント・コンピュータの存在は、携帯用コンピューティング・デバイスが外部電源を利用できる可能性を増大させる。ＲＭファイルの他の様々な中継レポジトリが、携帯用コンピューティング・デバイスに利用可能であり、携帯用コンピューティング・デバイスはメディア・サーバからダイレクトにＲＭファイルを得ることもできる。例えば、図８で説明されるように、携帯用コンピューティング・デバイスは、メディア・サーバとの無線接続を確立し、無線接続を介してＲＭファイルを受信するためにトランシーバを使用する。
【００６０】
メディア・クライアントは、携帯用コンピューティング・デバイスが、クライアント・コンピュータ（あるいはＲＭファイルの別の中継ソース）と接続されているかどうかを判定する（ステップ７０３）。携帯用コンピューティング・デバイスがクライアント・コンピュータと接続されているならば、メディア・クライアントはクライアント・コンピュータにＲＭファイルを要求する（ステップ７０５）。クライアント・コンピュータが、携帯用コンピューティング・デバイスに転送すべきＲＭファイルを持っていない場合、クライアント・コンピュータは、メディア・サーバにＲＭファイルを要求する（例えば、図５に説明されたプロシージャを使用して）。その後、メディア・クライアントは、クライアント・コンピュータからＲＭファイルを受け取り（ステップ７０７）、携帯用コンピューティング・デバイスに関連したローカルメモリにそれらを格納する。
【００６１】
携帯用コンピューティング・デバイスが、ライアント・コンピュータと接続されていない場合、メディア・クライアントは、携帯用コンピューティング・デバイスがメディア・サーバと無線接続を確立することができるかどうかを判定する（ステップ７０９）。同様に、メディア・クライアントは、それがＲＭファイルの中継供給先との無線接続を確立することができるかどうかを判定する。メディア・クライアントは、通常は最初に、ＲＭファイル用の自分自身のメモリをチェックし、次に、上に説明されたように、無線接続をチェックする前に、クライアント・コンピュータとの接続をチェックする。いくつかの実施例で、メディア・クライアントは、ＲＭファイルを得るために広帯域通信チャネルを使用し、ＥＭファイルを受信するためにより狭い帯域チャネルを使用する。しかしながら、本発明のいくつかの実施例では、メディア・クライアントは、ＥＭ及びＲＭファイルの両方を受信するために、単純に同じチャネルを使用する。メディア・クライアントが、別のメディア・クライアントとのＩＲ接続のような、メディア・サーバ又はＲＭファイルの別の中継プロバイダとの無線接続を確立することができる場合、確立している接続がＲＭファイルの転送に十分な帯域幅を提供するかどうかを、メディア・クライアントは判定する（ステップ７１１）。時が経てば、帯域幅制約は、ＥＭファイル又はＲＭファイルを１本のチャネルか、異なる２本のチャネルを通して送るべきかどうかの選択が、帯域幅ではなくコスト及び即時利用の可能性の問題になるので、さほど厄介なものではない。どんな場合も、メディア・クライアントは通常、ＥＭ及びＲＭファイルが得られるプロトコルを使用する通信用に環境設定されることができる。
【００６２】
接続が十分な帯域幅を提供する場合、メディア・クライアントは無線接続を通してメディア・サーバにＲＭファイルを要求する（ステップ７１３）。メディア・サーバは、適切なＲＭファイル又は適切なセットのＲＭファイルを捜し出し、それらを携帯用コンピューティング・デバイスに送る。メディア・クライアントは、ＲＭファイルを受信し、それらを携帯用コンピューティング・デバイスに関連するローカルメモリに格納する（ステップ７１５）。その後、メディア・クライアントはメディア・サーバとの無線接続を終了する（ステップ７１７）。典型的な機器構成の中では、メディア・クライアントが無線接続を早く終了すればするほど、より多くの電力が、携帯用コンピューティング・デバイスの内部電源（例えばそれのバッテリ）に温存される。
【００６３】
メディア・クライアントがメディア・サーバへの無線接続を確立することができない場合、あるいはメディア・サーバと確立した接続が不十分な帯域幅である場合、メディア・クライアントは、携帯用コンピューティング・デバイスのユーザが、なぜ要求されたメディア・ファイルを再生することができないかを理解することができるように、適切なエラーメッセージを生成する（ステップ７１９）。
【００６４】
図８は、携帯用コンピューティング・デバイスが、第１の無線通信チャネル８１９を介してＲＭファイルを受信し、第２の無線通信チャネル８２１を介してＥＭファイルを受信する、本発明の実施例を示すブロック図である。携帯用コンピューティング・デバイス１０７上のメディア・クライアント１１７は、トランシーバ８０１を介してメディア・サーバ１０３にＲＭファイルを要求するためにトランシーバ８０５を使用する。トランシーバ８０１とトランシーバ８０５との間の通信チャネル８１９は、効率的なやり方でＲＭファイルを伝送するための十分な高帯域を持つと同時に、通信チャネル８２１は、ＥＭファイルを効率的に伝送するための十分な高帯域を持つ。携帯用コンピューティング・デバイスのトランシーバ８０３、８０５は、いくつかの実施例では単一のデバイスを表し、また同様に、メディア・サーバの関連するトランシーバ８０１、１１３は、いくつかの実施例では単一のデバイスを表す。時が経てば、帯域幅の問題は、様々な通信チャネルがＲＭ及びＥＭファイルの両方を分配するために使用されることができるというように、緩和される。なお、メディア・サーバは、分離したＲＭ及びＥＭファイルを分配するよう構成されるが、いくつかの実施例では、メディア・サーバが、１つの通信チャネルを介してこれらのファイルを提供する。一般的に、メディア・サーバ及びメディア・クライアントは、様々な通信チャネルを通してＥＭ及びＲＭファイルを処理するよう順応可能であるし、さらに、ＥＭ及びＲＭファイル要求が生成される瞬間に利用可能となるいかなる通信チャネルをも使用できるように順応されることができる。
【００６５】
通信チャネル８１９は、任意の適切な無線プロトコルによって動作する。例えば、トランシーバ８０１は、Ｂｌｕｅｔｏｏｔｈプロトコルによって動作する。本発明の実施例は、ユーザ（あるいは携帯用コンピューティング・デバイスのメディア・クライアント）が、メディア・ファイルを再生したい時に、ＥＭファイル用の無線ソースを捜し出すだけでよいような、ＲＭファイルを携帯用コンピューティング・デバイスに提供する様々な中継器、キオスク及び他のプラットホームを含む。例えば、本発明の実施例は、夜にガレージの中でＢｌｕｅｔｏｏｔｈトランシーバからＲＭファイルを受信し、昼間にユーザの選択に基づいて、適切なＥＭファイルのセットを無線で取り出す、自動車のラジオのように機能する。
【００６６】
ＲＭファイル１２５が受信され、メモリ８０７に格納されたならば、メディア・クライアント１１７はトランシーバ８０５を停止する。トランシーバ８０５を停止することは、携帯用コンピューティング・デバイス１０７内の電力消費を減少させるだろう。携帯用コンピューティング・デバイス１０７が外部電源を持っているならば、メディア・クライアント１１７は電力を温存する必要性は少ない。さらに、トランシーバ８０５は、メディア・ファイルと無関係な転送用に保持される必要がある。
【００６７】
ＲＭファイル１２５の検索は、メディア・クライアントが新しいＲＭファイルを集める毎に、携帯用コンピューティング・デバイスのユーザが必ずしもＲＭファイル検索機能に携わる必要がないような、自動モードで起こる。例えば、携帯用コンピューティング・デバイス１０７のユーザは、自宅から遠方に旅行する空港ロビーにいる間、メディア・クライアント１１７はメディア・サーバ１０３との高帯域接続を確立するためにトランシーバ８０５を使用する。本発明の実施例では、メディア・サーバ１０３は、それ自体が別のメディア・サーバから周期的なファイル更新を受け取るＲＭファイル・レポジトリ又は中継器を意味する。
【００６８】
ユーザの旅行中のある時点で、携帯用コンピューティング・デバイスのユーザが、彼のデバイスに利用可能になっているメディア・ファイルの１つ以上を再生することを選択する。例えば、メディア・クライアント１１７は既に、携帯用コンピューティング・デバイス上にローカルに格納された多くのＲＭファイルを持っている。ＲＭファイルがローカルに利用可能でない場合、メディア・クライアントは、上に説明された方法で高帯域ネットワークへの接続を確立する。一度ＲＭファイルがローカルに利用可能で、ユーザがファイルを再生したいならば、メディア・クライアントは、トランシーバ・デバイス１１３を通してメディア・サーバ１０３と無線接続を確立するためにトランシーバ８０３を使用する。ユーザは、現在ＲＭファイルのセットを受信した空港の町とは異なる町に居て、対応するＥＭファイルのセットをユーザがそこから受信しようとしているメディア・サーバはＲＭファイルを提供したものとは異なるメディア・サーバである。メディア・クライアント１１７は、トランシーバ８０３とトランシーバ１１３との間で確立されている通信を通して、メディア・サーバ１０３にＥＭファイルの適切なセットを要求する。
【００６９】
ＥＭファイルは通常、ＲＭファイルより著しく小さなサイズを持つので、チャネル８２１は通常、チャネル８１９より低い帯域幅を要求する。トランシーバ８０３とトランシーバ１１３との間で確立されている通信チャネル８２１は、本発明の実施例によれば、通信チャネル８１９より大きな伝送範囲に渡って動作する。上記の空港の例に戻って、ユーザは、トランシーバ８０１から携帯用コンピューティング・デバイスを引き離して移動する場合であっても、なおもトランシーバ１１３の範囲内に残る。例えば、トランシーバ８０１は、空港ターミナル（例えば出発ゲートのうちの１つの傍ら）の小さな部分でのみ動作する場合もある。対照的に、トランシーバ１１３とトランシーバ８０３との間で確立されているチャネル８２１は、無線電話ネットワークのように、より広範囲の無線ネットワークを表す。従って、携帯用コンピューティング・デバイス１０７が無線電話ネットワーク内の接続を確立することができる限り、メディア・クライアント１１７はＥＭファイルを得ることができる。もちろん、ＥＭファイルは、それ自体が別のメディア・サーバから周期的な更新を受信するレポジトリから提供されてもよい。空港の例を継続すると、ユーザは、航空機の電子機器装置を妨害しない方式で、携帯用コンピューティング・デバイス１０７にＥＭファイルを分配するＥＭファイルの中継器を含む航空機に搭乗してもよい。
【００７０】
図９は、本発明の実施例に従った、ＲＭファイル１２５を保持している取り外し可能なメモリ・デバイス９０３を持つ携帯用コンピューティング・デバイス１０７を示す図である。上述した実施例では、ＲＭファイル１２５が、ある通信チャネル（例えば、同期用のクレイドルあるいは無線で）を通して携帯用コンピューティング・デバイスに転送された。図９の実施例では、携帯用コンピューティング・デバイス１０７が、ＲＭファイルを保持しているメモリ・デバイス９０３に接続されるようになる。例えば、取り外し可能なメモリ・デバイス９０３は、１つ以上のＲＭファイルを装備した、ＰＭＣＩＡカード、ジュークボックスのメモリ・デバイス、又はディスケットでもよい。メモリ・デバイス９０３は、宣伝用資料として、又は予約申込み方式で携帯用コンピューティング・デバイスに関連するユーザに郵送されたり、手渡されてもよい。
【００７１】
連係されたとき、メディア・クライアント１１７は、携帯用コンピューティング・デバイス１０７上の利用可能なＲＭファイルのセットを監視する。メディア・クライアントによる監視は、どのＲＭファイルが利用可能であるかを判定するだけでなく、メディア・サーバ１０３に要求される予定のＥＭファイルを識別することを可能にする。メディア・クライアント１１７は、今まで説明された方法で、トランシーバ１１３との通信リンクを確立するためにトランシーバ１２１を使用する。その後、メディア・クライアント１１７は、メモリ・デバイス９０３内のＲＭファイルに対応するＥＭファイルのセットをメディア・サーバ１０３に求める。メディア・サーバ１０３はまた、携帯用コンピューティング・デバイス１０７にＥＭファイル１２７を送る前に、追加情報（例えば支払い）を要求する。メディア・クライアント１１７は、受信されたＥＭファイル１２７をメモリに格納し、トランシーバ１１３との接続を切断するようにトランシーバ１２１に命じる。ＥＭファイルを受信するメモリは、必ずしもメモリ９０３である必要はない。その後、メディア・クライアント１１７は、今まで説明された方法で、元のメディア・ファイルを再組立てして再生する。
【００７２】
上述したように、本発明の実施例は、図８で示されるトランシーバ８０１のような、ＲＭファイルを携帯用コンピューティング・デバイスに送信することができるトランシーバを使用する。携帯用コンピューティング・デバイスは、同様に、そのようなトランシーバとのデータ・リンクの確立をするための適切な送受信回路を持つ。一般的な当業者であれば、１つの受信器及び１つのトランシーバが、１つのトランシーバの代わりか、あるいは併せて使用されることが可能であることを理解する。適切なトランシーバは、Ｂｌｕｅｔｏｏｔｈの使用可能なデバイスというような、短い範囲又は中位の範囲の無線周波数を持つ通信デバイスを含むことができる。Ｂｌｕｅｔｏｏｔｈ通信プロトコルは、２つの電力レベル、つまりより短い通信範囲をカバーすることができるより低い電力レベルと、中位の通信範囲をカバーすることができるより高い電力レベルとを示す。本発明の実施例は、メディア・サーバと携帯用コンピューティング・デバイスとの間の所要の通信範囲に依存して、２つの電力レベルのどちらかか又は組合せを利用する。またトランシーバは、周波数ホッピング変調（「ＦＨＳＳ」）又は直接シーケンス・スペクトル拡散（「ＤＳＳ」）のいずれかを使用して、２．４ＧＨｚ帯域で１又は２Ｍｂｐｓを提供する８０２．１１デバイスとして動作する。そのトランシーバは、ＩＭＴ−２０００の全世界的体制下でＩＴＵによって定義されるような、第３世代（「３Ｇ」）の無線デバイスである。またそのトランシーバは、スペクトルの共有された部分の上に同時信号を伝送する方法である符号分割多重アクセス（「ＣＤＭＡ」）を用いて動作することができる。同様に、トランシーバは、キーボード、マウス、ジョイスティック、スキャナ、プリンタ及び電話デバイスのような低速周辺装置用のユニバーサル・シリアル・バス（「ＵＳＢ」）ハードウェア・インターフェースに従って動作することができる。同様に、トランシーバは、ＦＭサブキャリア・システム上で、及び（又は）時分割多重アクセス（「ＴＤＭＡ」）準拠のデバイスとして、及び（又は）グローバル移動体通信システム（「ＧＳＭ」）準拠のデバイスとして動作することができる。また、Ｌｏｃａｌ Ｍｕｌｔｉｐｏｉｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ（ローカル多方面分配サービス）（「ＬＭＤＳ」）及び（又は）Ｍｕｌｔｉｃｈａｎｎｅｌ Ｍｕｌｔｉｐｏｉｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ（多チャネル多方面分配サービス）（「ＭＭＤＳ」）のようなプロトコルだけでなく、衛星通信プロトコルに従った伝送が、そのトランシーバによって使用されることができる。またそのトランシーバは、ＭｏｂｉｌｅＳｔａｒブロードバンドの無線インターネット・アクセス・プロトコルに従って動作することができ、適切なトランシーバは、Ｗｉｒｅｌｅｓｓ Ｅｔｈｅｒｎｅｔ（登録商標） Ｃｏｍｐａｔｉｂｉｌｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ（「Ｗｉｆｉ」）の保証したデバイスであることができる。
【００７３】
本発明の実施例は、さらに、ＲＭ及びＥＭファイルを得るステップ、及び（又は）メディア・クライアントがＲＭファイルを周期的に取り出す試みを可能にするメディア・クライアント用の設定を選択するステップを通してユーザを導くウィザードを含むヘルプ・システムを含む。
メディア・クライアント及びクライアント・モジュールを実現するソフトウェアは、任意のコンピュータ・オペレーティング・システムによる操作用に、及び任意のコンピューティング環境での操作用に書かれている。さらに、いかなるそのようなソフトウェアも、ＣＯＲＢＡ、ＡＣＴＩＶＥＸ（登録商標）コントロール、ジャバ・スクリプト、及び（又は）ジャバ・アプレットを使用して設計される。本発明の１つの実施例によれば、ジャバ・アプレットは、携帯用コンピューティング・デバイス上で別のアプリケーションと共に使用するためのプラグ・イン・メディア・クライアントを提供する。
【００７４】
メディア・クライアント・モジュール及びクライアント・モジュールは、オブジェクト指向のプログラミング方法論を使用するか、又は適切な機能を持つコンピューティング・システムに帰着する他のプログラミング方法論を使用して、構築される。本発明は、コンピュータ・プログラムの用語で説明されたが、特定用途向け集積回路（「ＡＳＩＣ」）のような、同じような機能を実行するハードウェアを利用するシステムに対しても、同様に適用可能である。
これら及び他の変更が、上記の詳細な説明の観点から、本発明に為されることができる。一般的に、特許請求の範囲において使用される用語は、仕様及び特許請求の範囲で開示された特別の実施例に本発明を制限するように解釈されてはならないが、以下に示す特許請求の範囲で動作するシステム及び方法をすべて含むように解釈されるべきである。従って、本発明はその開示によって制限されない。
【図面の簡単な説明】
【図１】
Ａは、本発明の実施例に従った、クライアント・コンピュータにメディア・ファイルの部分を配信するための装置のブロック図である。
Ｂは、本発明の実施例に従った、メディア・サーバから携帯用コンピューティング・デバイスに、エッセンシャル・メディア（「ＥＭ」）ファイルを転送するところを示すブロック図である。
Ｃは、本発明の実施例に従った、携帯用コンピューティング・デバイスを示すブロック図である。
【図２】
Ａは、本発明の実施例に従った、代表的なメディア・ファイルの図である。
Ｂは、本発明の実施例に従った、リジデュアル・メディア（「ＲＭファイル」）を形成するために、メディア・サーバによって取り除かれるメディア・ファイルの部分を示す図である。
Ｃは、本発明の実施例に従った、取り除かれた部分を持つＲＭファイルを示す図である。
Ｄは、本発明の実施例に従った、ＥＭファイルのコンポーネントを示す図である。
Ｅは、本発明の実施例に従った、それ自体が暗号化されたメディア・ファイルからなる対応するＲＭファイルを持つメディア・ファイルを示す図である。
Ｆは、ＲＭファイル用の復号化キーを保持するＥＭファイルを示す図である。
【図３】
本発明の実施例に従った、メディア・サーバからメディア・ファイル・コンポーネント、例えばＲＭ及びＥＭファイルを、受信する複数の携帯用コンピューティング・デバイスを示すブロック図である。
【図４】
本発明の実施例に従った、メディア・サーバと、クライアント・コンピュータ上のクライアント・モジュールと、携帯用コンピューティング・デバイス上のメディア・クライアントとの間での、メディア・ファイル・コンポーネントの処理を示す図である。
【図５】
本発明の実施例に従った、クライアント・コンピュータ上のクライアント・モジュールによって引き起こされるプロセスを示するフローチャートである。
【図６】
本発明の実施例に従った、携帯用コンピューティング・デバイス上のメディア・クライアントが、ＲＭ及びＥＭファイルのようなコンポーネントからメディア・ファイルをどのようにして復元するかを示すフローチャートである。
【図７】
本発明の実施例に従った、メディア・サーバからＲＭファイルを取り出す際の、メディア・クライアントの作用を示するフローチャートである。
【図８】
携帯用コンピューティング・デバイスが、第１の無線通信チャネルを介してＲＭファイルを受信し、第２の無線通信チャネルを介してＥＭファイルを受信する、本発明の実施例を示すブロック図である。
【図９】
本発明の実施例に従った、ＲＭファイルを保持している取り外し可能なメモリ・デバイスを持つ携帯用コンピューティング・デバイスを示す図である。

Claims (60)

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. 請求項３３記載のメディア・サーバにおいて、該サーバはさらに、
    キーを使用して、第１のファイル部を暗号化する手段と、
    該キーを第２のファイル部に配置する手段と
    を含むことを特徴とするメディア・サーバ。
35. 請求項３２記載のメディア・サーバにおいて、該サーバはさらに、
    携帯用コンピューティング・デバイスに第１のファイル部を転送するよう構成されたクライアント・コンピュータに第１のファイル部を転送する手段
    を含むことを特徴とするメディア・サーバ。
36. 請求項３２記載のメディア・サーバにおいて、該サーバはさらに、
    携帯用コンピューティング・デバイスに第２のファイル部を転送するよう構成されたトランシーバ
    を含むことを特徴とするメディア・サーバ。
37. 請求項３２記載のメディア・サーバにおいて、該サーバはさらに、
    第１の通信チャネルを介して携帯用コンピューティング・デバイスにアクセス可能な第１のデータ・レポジトリ内に第１のファイル部を格納するための手段と、
    第２の通信チャネルを介して携帯用コンピューティング・デバイスにアクセス可能な第２のデータ・レポジトリに第２のファイル部を格納するための手段と
    を含むことを特徴とするメディア・サーバ。
38. 請求項３７記載のメディア・サーバにおいて、第２のデータ・レポジトリは、第１のデータ・レポジトリ内に含まれることを特徴とするメディア・サーバ。
39. 携帯用コンピューティング・デバイス上のメディア・ファイルを処理するためのメディア・クライアントにおいて、
    第１の通信チャネル上で、メディア・ファイルとして使用不可能な第１のファイル部を要求するように設定された第１のファイル・マネージャと、
    第２の通信チャネル上で、メディア・ファイルとして使用不可能な第２のファイル部を要求するように設定された第２のファイル・マネージャと、
    第１のファイル部及び第２のファイル部からメディア・ファイルを復元するよう構成されたメディア・ファイル復元器と
    を含むことを特徴とするメディア・クライエント。
40. 請求項３９記載のメディア・クライエントにおいて、該クライアントはさらに、
    メディア・ファイル復元器によって復元されたメディア・ファイルを実行するよう構成されたメディア・ファイル・プレーヤ
    を含むことを特徴とするメディア・クライエント。
41. 請求項４０記載のメディア・クライエントにおいて、
    メディア・ファイル復元器はさらに、メディア・ファイル・セクション内のメディア・ファイルを復元し、各復元されたメディア・ファイル・セクションをメディア・ファイル・プレーヤに提供するよう構成され、
    メディア・ファイル・プレーヤはさらに、メディア・ファイル・セクションが再生された場合に、それらを削除するよう構成される
    ことを特徴とするメディア・クライエント。
42. 請求項３９記載のメディア・クライエントにおいて、該クライアントはさらに、
    第２のファイル部が受け取られたときに、第２の通信チャネルから切断するようトランシーバに命令するよう構成されたトランシーバ・コントローラ
    を含むことを特徴とするメディア・クライエント。
43. 請求項３９記載のメディア・クライエントにおいて、メディア・ファイル復元器はさらに、配列データを捜し出すために第２のファイル部を調べるよう構成され、メディア・ファイル復元器はさらに、第２のファイル部からデータを捜し出すために配列データを用いるよう構成され、かつメディア・ファイルを復元するためにそのデータを第１のファイル部に追加するよう構成されることを特徴とするメディア・クライエント。
44. 請求項３９記載のメディア・クライエントにおいて、メディア・ファイル復元器はさらに、キーを捜し出すために第２のファイル部を調べるよう構成され、メディア・ファイル復元器はさらに、メディア・ファイルを得るために第１のファイル部を復号化するためにキーを使用するよう構成されることを特徴とするメディア・クライエント。
45. 請求項３９記載のメディア・クライエントにおいて、第１の通信チャネルが携帯用コンピューティング・デバイスとクライアント・コンピュータとの間の接続であり、第１のファイル・マネージャはさらに、第１のファイル部の転送を要求する要求を、第１の通信チャネル上に送信するよう構成されることを特徴とするメディア・クライエント。
46. 請求項３９記載のメディア・クライエントにおいて、第１の通信チャネルが携帯用コンピューティング・デバイスとメディア・サーバとの間の無線接続であり、第１のファイル・マネージャはさらに、第１のファイル部の転送を要求する要求を、第１の通信チャネル上に送信するよう構成されることを特徴とするメディア・クライエント。
47. 請求項３９記載のメディア・クライエントにおいて、第１の通信チャネルが携帯用コンピューティング・デバイスと別の携帯用コンピューティング・デバイスとの間の無線接続であり、第１のファイル・マネージャはさらに、第１のファイル部の転送を要求する要求を、第１の通信チャネル上に送信するよう構成されることを特徴とするメディア・クライエント。
48. 請求項３９記載のメディア・クライエントにおいて、第１のファイル・マネージャはさらに、携帯用コンピューティング・デバイス上のメモリ内に第１のファイル部を格納するように設定されることを特徴とするメディア・クライエント。
49. 請求項３９記載のメディア・クライエントにおいて、第１のファイル・マネージャはさらに、少なくとも１つのメディア・ファイルに対する要求を受け取ると、少なくとも１つの第１のファイル部のために携帯用コンピューティング・デバイス上のメモリを調べるよう構成されることを特徴とするメディア・クライエント。
50. 請求項３９記載のメディア・クライエントにおいて、第２の通信チャネルが携帯用コンピューティング・デバイスとメディア・サーバとの間の無線接続であり、第２のファイル・マネージャはさらに、第２のファイル部の転送を要求する要求を、第２の通信チャネル上に送信するよう構成されることを特徴とするメディア・クライエント。
51. 携帯用コンピューティング・デバイスに関連するメディア・クライアントによる実行用にメディア・データを提供するために、携帯用コンピューティング・デバイスとの接続に用いるためのコンピュータ・プログラム製品において、携帯用コンピューティング・デバイスはコンピュータ・プログラム製品を格納するように設定されたメモリを含み、該コンピュータ・プログラム製品は、
    複数のデータ・エレメントの除去によって、メディア・データとして使用不可能にされた第１のファイル部と、
    第１のファイル部から取り除かれた複数のデータ部、並びにメディア・ファイルを生成するために、取り除かれた複数のデータ・エレメントが第１のファイル部内のどこに配置されるべきであるかを記述する配列情報を含む第２のファイル部と
    を含むことを特徴とするコンピュータ・プログラム製品。
52. 請求項５１記載のコンピュータ・プログラム製品において、第１のファイル部が暗号化されており、第２のファイル部はさらに、第１のファイル部を復号化するために使用されるキーを保持していることを特徴とするコンピュータ・プログラム製品。
53. 携帯用コンピューティング・デバイスを制御するための命令であって、実行されたときにメディア・ファイルを再生する命令を保持しているコンピュータ読取り可能な媒体において、コンピュータ読取り可能な媒体の命令は、
    第１の通信チャネルを介して、携帯用コンピューティング・デバイス内にメディア・ファイルとして使用不可能な第１のファイル部を受信するステップと、
    第２の通信チャネルを介して、携帯用コンピューティング・デバイス内にメディア・ファイルとして使用不可能な第２のファイル部を受信するステップと、
    第１のファイル部及び第２のファイル部から、携帯用コンピューティング・デバイス内にメディア・ファイルを作成するステップと
    を含むことを特徴とするコンピュータ読取り可能な媒体。
54. 請求項５３記載のコンピュータ読取り可能な媒体において、
    第２の通信チャネルを介して、携帯用コンピューティング・デバイス内に第２のファイル部を受信するための命令はさらに、
    第２のメディア・ファイルを受信するために、第２の通信チャネルに、携帯用コンピューティング・デバイス上の無線トランシーバを接続するステップであって、第２の通信チャネルが無線通信チャネルである、ステップと、
    第２のファイル部が受信された場合に、第２の通信チャネルから携帯用コンピューティング・デバイス上のトランシーバを切断するステップと
    を含むことを特徴とするコンピュータ読取り可能な媒体。
55. 請求項５３記載のコンピュータ読取り可能な媒体において、命令はさらに、
    携帯用コンピューティング・デバイス上のメディア・ファイルを再生するステップと、
    該ファイルが再生された場合に、メディア・ファイルを削除するステップと
    を含むことを特徴とするコンピュータ読取り可能な媒体。
56. 請求項５３記載のコンピュータ読取り可能な媒体において、
    第１の通信チャネルが携帯用コンピューティング・デバイスとクライアント・コンピュータとの間の接続であり、命令はさらに、
    クライアント・コンピュータから携帯用コンピューティング・デバイス内に第１のファイル部を受信するステップと、
    携帯用コンピューティング・デバイス上に第１のファイル部を格納するステップと
    を含むことを特徴とするコンピュータ読取り可能な媒体。
57. 請求項５６記載のコンピュータ読取り可能な媒体において、
    接続は、クライアント・コンピュータ及び携帯用コンピューティング・デバイスに関連する、ドッキングステーション又は同期用のクレイドルのうちの少なくとも一方によって提供されることを特徴とするコンピュータ読取り可能な媒体。
58. 請求項５３記載のコンピュータ読取り可能な媒体において、
    第１の通信チャネルが携帯用コンピューティング・デバイス上のトランシーバとメディア・ファイル・レポジトリに関連するトランシーバとの間の無線接続であり、命令はさらに、
    第１のファイル部の転送要求をメディア・ファイル・レポジトリに転送するステップと、
    第１のファイル部が携帯用コンピューティング・デバイス上で受信された場合に、第１の通信チャネルを終了するステップと
    を含むことを特徴とするコンピュータ読取り可能な媒体。
59. 請求項５３記載のコンピュータ読取り可能な媒体において、メディア・ファイルを作成するための命令はさらに、
    メディア・ファイルを作成するために、第２のメディア・ファイルのエレメントが第１のファイル部内のどこに配置されるべきかを記述する、第２のファイル部内の配列情報を調べるステップ
    を含むことを特徴とするコンピュータ読取り可能な媒体。
60. 請求項５９記載のコンピュータ読取り可能な媒体において、命令はさらに、
    第２のファイル部から得られるキーを使用して、第１のファイル部を復号化するステップ
    を含むことを特徴とするコンピュータ読取り可能な媒体。

Images