(57)【特許請求の範囲】
【請求項１】
スケジュール・リストを含む電子サービス・ガイド（ＥＳＧ）のデータをサーバから受信するステップと、  前記サーバと、前記サーバからの放送コンテンツを記憶する受信モジュールを含むクライアントとの間の通信チャネルの帯域幅を特定するステップと、  前記スケジュール・リストを新たな放送コンテンツについて反復適用するステップと、  前記特定された帯域幅と、前記新たなコンテンツの開始時刻および終了時刻を含む前記スケジュール・リストとから前記新たなコンテンツのサイズを推定するステップと、  前記新たなコンテンツの前記推定されたサイズと、ユーザによって予め提供された好みとに基づいて、前記クライアントに前記新たなコンテンツを記憶するために前記受信モジュールに対して動作電源を供給するかどうかを決定するステップと、  前記動作電源が前記受信モジュールに供給される場合、前記新たなコンテンツが記憶された後に前記受信モジュールの前記動作電源を切るステップと、を含み、  前記新たなコンテンツが記憶された後に前記新たなコンテンツの実際のサイズを測定するステップと、  前記新たなコンテンツの前記実際のサイズに従って、前記帯域幅を特定するステップのためのパラメータを調節するステップとをさらに含む、方法。
【請求項２】
前記新たなコンテンツの前記推定されたサイズに基づいて前記クライアントの記憶スペースの制限を定めるステップをさらに含み、  前記好みは、前記新たなコンテンツを前記クライアント上の既存のコンテンツと置き換えることによって記憶することを含む、請求項１に記載の方法。
【請求項３】
ネットワークを介したサーバとの通信チャネルを有するクライアントと、  前記クライアントに含まれるメモリと、  前記サーバからの放送コンテンツを前記メモリに記憶するように動作する、前記クライアントに含まれる受信モジュールと、を含み、  前記クライアントは、  スケジュール・リストを含む電子サービス・ガイド（ＥＳＧ）のデータを前記サーバから受信し、  前記サーバと前記クライアントとの間の通信チャネルの帯域幅を特定し、  前記スケジュール・リストを新たな放送コンテンツについて反復適用し、  前記特定された帯域幅と、前記新たなコンテンツの開始時刻および終了時刻を含む前記スケジュール・リストとから前記新たなコンテンツのサイズを推定し、  前記新たなコンテンツの前記推定されたサイズと、ユーザによって予め提供された好みとに基づいて、前記新たなコンテンツを記憶するために前記受信モジュールに対して前記動作電源を供給するかどうかを決定し、  前記動作電源が前記受信モジュールに供給される場合、前記新たなコンテンツが記憶された後に前記受信モジュールの動作電源を切るように動作し、  前記クライアントは、前記新たなコンテンツが記憶された後に前記新たなコンテンツの実際のサイズを測定するように動作し、  前記クライアントは、前記新たなコンテンツの前記実際のサイズに従って、前記帯域幅の特定のためのパラメータを調節するように動作する、装置。
【請求項４】
前記クライアントは、前記新たなコンテンツの前記推定されたサイズに基づいて前記メモリの記憶スペースの制限を定めるように動作し、  前記好みは、前記新たなコンテンツを前記メモリ上の既存のコンテンツと置き換えることによって記憶することを含む、請求項３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送ネットワークに関し、より詳しくは、ファイルのサイズをファイルの受信前に推定することに関する。
【背景技術】
【０００２】
例えばＤＶＢ−Ｈのような放送技術により、低電力の携帯可能なクライアント・デバイスへのデータの配信が可能になり、これにより、コンテンツのオン・デマンド・サービスが可能になっている。このようなサービスでは、コンテンツは、クライアントにおいて継続的に受信され、エンド・ユーザは、そのコンテンツをその場であるいは後で消費（視聴）できる。場合によっては、記憶すべきコンテンツの量が、クライアントの記憶容量により制限されてしまう。サービスがコンテンツの更新を頻繁に行う場合、受信データの記憶と置き換えを迅速に行えることが望ましい。そのようなサービスにおいては、受信しようとしているコンテンツのサイズを、実際のデータ送信の前に推定することが、既に記憶されているコンテンツを置き換える際、あるいは、今後どのコンテンツを記憶すべきかを決定する際に役立つことがある。
【発明の概要】
【０００３】
本原理の一態様によれば、放送ネットワークにおける通信チャネルを通じたファイル・サイズ推定方法は、放送スケジュール情報を用いて、ファイルのサイズを、ファイルを実際に受信する前に推定することと、ファイルを受信して記憶すべきか否かを、クライアント・デバイスへファイルを自動的に及び／又はユーザの介入を必要とすることなくダウンロードする前に、決定することとを含む。この決定は、クライアント・デバイス上のユーザ・プロファイル内に記憶されているユーザの好みに基づく。この方法は、通信チャネルの帯域幅を特定することを更に含むことが可能である。
【０００４】
ファイル・サイズの推定は、放送スケジュールから当該ファイルの開始時刻と終了時刻とを求めることによって行うことが可能である。別の実施形態において、ファイル・サイズの推定は、サービス・プロバイダから得られる、ファイルに関する電子サービス・ガイド（ＥＳＧ）情報を用いる。
【０００５】
帯域幅の特定は、通信チャネルの帯域幅を推定することによって、あるいは、通信チャネルの帯域幅についての既知の値を得ることによって、行うことが可能である。
【０００６】
本原理の他の態様による装置は、メモリを内蔵するモバイル・クライアント・デバイスを含んでおり、モバイル・クライアント・デバイスは、放送スケジュール情報を用いてファイル・サイズをファイルを実際に受信する前に推定するように構成されており、且つ、ファイルを受信して記憶すべきか否かを、ファイルをデバイスのメモリに自動的に及び／又はユーザの介入を必要とすることなくダウンロードする前に、自動的に決定するように構成されている。
【０００７】
モバイル・クライアント・デバイスは、更に、モバイル・デバイスへファイルを送信する通信チャネルの帯域幅を特定するように構成されている。
【０００８】
クライアント・デバイスのメモリに記憶されたユーザ・プロファイルは、ユーザによる介入を必要とすることなく、クライアント・デバイスが上記の自動的な決定を行うことを可能にする。
【０００９】
本原理の他の態様による装置は、メモリを内蔵するモバイル・クライアント・デバイスを含む。メモリは、モバイル・クライアント・デバイスを動作させる際に使用される読み取り可能なプログラム・コードが組み込まれているコンピュータ・プログラム・プロダクトを含む。プログラム・プロダクトは、放送スケジュール情報を用いて、ファイルのサイズをファイルを実際に受信する前に推定するプログラム・コードと、ファイルを受信して記憶するか否かを、ファイルをモバイル・クライアント・デバイスにユーザの介入を必要とすることなくダウンロード前に決定するプログラム・コードとを含む。クライアント・デバイスは、推定されたファイル・サイズを用いて、クライアント・デバイスにおける記憶スペースの制限を定めるプログラム・コードを更に含む。この決定は、クライアント・デバイスのメモリに記憶されたユーザ・プロファイル内に記憶されている好みに基づいて行われる。
【００１０】
本原理のその他の実施形態及び特徴は、各添付図面を参照しつつ読まれるべき以下の詳細な説明から明らかになるであろう。なお、各図面は、説明の目的のためのみに作成されたものであり、本原理の範囲を確定するものとして作成されたものではない。本原理の範囲については、特許請求の範囲を参照されたい。更に、各図面は、必ずしも、一定の率で縮尺又は拡大した訳ではなく、特に断りのない限り、本明細書に記載の各構造及び手順を単に概念的に例示したものに過ぎない。
【図面の簡単な説明】
【００１１】
各図面において、同一の参照番号は、類似の構成部分を示している。
【図１】既知の例による双方向放送ネットワークのシナリオのブロック図である。
【図２】既知の例による片方向放送ネットワークのブロック図である。
【図３】クリップと、クリップが放送される時点とを表す図である。
【図４】放送されるクリップＡとクライアント・デバイス内に記憶された数個のクリップとを表した図である。
【図５】本原理の一実施形態によるファイル・サイズ推定方法のフローチャートである。
【図６Ａ】本原理の一実施形態による方法のブロック図である。
【図６Ｂ】本原理の他の実施形態によるファイル・サイズ推定方法のフローチャートである。
【発明を実施するための形態】
【００１２】
任意のチャネルの瞬時帯域幅を推定する方法が幾つか知られている。この推定は、通常、双方向ポイント・ツー・ポイントのネットワークにおいて、既知量のデータを取得するのに要する時間を測定することによって行われる。図１には、双方向ポイント・ツー・ポイントのネットワーク１００が例示されており、そのネットワークにおいて、サーバ１０２とクライアント１０６とが、ネットワーク１０４を介して互いに双方向通信可能になっている。
【００１３】
殆どの双方向クライアント／サーバ・ネットワークのアーキテクチャでは、クライアントが、既知量のデータを要求し、サーバとの間で送受信する一連のネットワーク・パケットを介してデータ送信の開始時刻と終了時刻を記録してチャネル容量を推定する。
【００１４】
図２には、片方向クライアント／サーバ・ネットワークのアーキテクチャ２００が例示されており、このアーキテクチャにおいて、サーバ２０２が１つ以上のクライアント２０４Ａ〜２０４Ｃにデータを送信する。
【００１５】
ファイルの配信は、ＦＬＵＴＥ（Ｆｉｌｅ＿Ｄｅｌｉｖｅｒｙ＿ｏｖｅｒ＿Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ＿Ｔｒａｎｓｐｏｒｔ）プロトコルを用いて行うことができる。ＦＬＵＴＥは、マルチキャスト・ファイル配信用プロトコルであり、片方向ネットワークを介してデータあるいはコンテンツを送信するのに使用できる。クライアントは、任意の時点で流れているデータの量をモニタして、この情報によりチャネル容量を推定できる。チャネル容量が一定である環境では、この測定は一度だけ行えばよい。容量が変動するチャネルの場合、チャネル容量（すなわち、帯域幅）のベスト・エフォートを維持し、かつ常時更新することができる。
【００１６】
個人用放送ビデオ・システムは、ネットワークの帯域幅を効率良く使用し、かつ受信装置のバッテリの使用を最小限に抑えつつ、個人用の簡易ユーザ・インタフェースを提供している。受信装置におけるユーザ・プロファイルは、ユーザの興味の対象を示す。放送される個別の各クリップは、電子サービス・ガイド（ＥＳＧ）で送られる、例えばキーワードのようなフレキシブル・メタデータ・タグと対応付けられている。ＥＳＧには、放送予定のテレビジョン番組についての情報が含まれており、一般的に、個別番組についての記述データ、すなわちメタデータ、例えば、その番組の名称、概要（あらすじ）、俳優、ディレクタ等、更に、放送の予定日時、継続時間、及び、チャネルが含まれている。
【００１７】
ＤＶＢ−ＣＢＭＳ規格は、ＤＶＢ−Ｈを使用して、例えば圧縮されたビデオ・ファイル又はオーディオ・ファイルのようなマルチメディア・コンテンツ・ファイルの放送用サービスを可能にしている。ＤＶＢ−ＨのＥＳＧは規格化されたＥＳＧを提供しており、この規格化されたＥＳＧは、ＴＶ−Ａｎｙｔｉｍｅプログラミング、すなわち、Ｏｎ−ｄｅｍａｎｄプログラミングに準拠している。ＤＶＢ−ＨのＥＳＧでは、個々のコンテンツが、コンテンツ・フラグメントのＣｏｎｔｅｎｔＩＤの属性によって固有に識別される。
【００１８】
個人用放送ビデオ・システムのサービスが提供される場合、コンテンツは、継続的に放送され、クライアントの好みに基づいて受信されて記憶される。しかし、このような場合、クライアントは、電源が常にオンになる傾向があり、従って、電力使用が非効率的になってしまう。好みのコンテンツを受信するときにだけクライアントが電源をオンにすれば、電力管理はより効率的になる。しかし、これを行うには、クライアントは、どのコンテンツを自己の記憶装置の限度に基づいて保存できるかを、コンテンツの実際の放送前に決定する必要がある。本原理の一実施形態によれば、この決定はクライアント・デバイス内に記憶されたユーザ・プロファイルの好みに従って行われ、その結果、ユーザによる介入が不要になる。
【００１９】
ＤＶＢ−ＨのＥＳＧは、Ｓｔｏｒａｇｅ識別子のもとで、ＦｉｌｅＤｏｗｎｌｏａｄＣｏｍｐｏｎｅｎｔＣｈａｒａｃｔｅｒｉｓｔｉｃという名称のＣｏｍｐｏｎｅｎｔＣｈａｒａｃｔｅｒｉｓｔｉｃタイプのＡｃｑｕｉｓｉｔｉｏｎフラグメントにおけるファイル・サイズ・パラメータの使用を公表している。しかし、これは、メガバイト単位のファイル・サイズを示すのみであり、この精度は、コンテンツを実際の放送の前に予め通知するのには不十分である。
【００２０】
上述したように、片方向ネットワーク、すなわち、放送ネットワークでは、クライアントからのフィードバックが無い。クライアントは、放送されるデータを受信するだけである。このようなシナリオでは、クライアントは、データ・パケットを受動的にモニタすることによって、帯域幅を推定できる。これから放送されるコンテンツのファイル・サイズを推定するためには、チャネルの帯域幅の推定値を求める必要がある。これは、ある期間に亘ってサンプリングされた帯域幅の統計表、あるいは、その他の任意の帯域幅の推定方法を用いて行うことができる。
【００２１】
一例として、帯域幅の推定は、Ｓｅｓｓｉｏｎ＿Ｄｅｓｃｒｉｐｔｉｏｎ＿Ｐｒｏｔｏｃｏｌ（ＳＤＰ）ファイルに規定された「ｂ＝」識別子を用いて行える。このＳＤＰファイルには、コンテンツの取得に関連する一組の識別子が含まれている。
【００２２】
他の例では、クライアントは、パケット送信の開始をタイムスタンプにより記録し、一定期間後に、データがどれだけ受信されたかを求めることができる。これは、クライアントがチャネルの帯域幅を推定するのに役立つ。ここでは、チャネルの帯域幅＝単位時間当たりの受信バイト数である。
【００２３】
他の帯域幅推定方法は、クライアントに対するサーバ提供データを用いて行われる。例えば、ＤＶＢ−ＨのＥＳＧ仕様を用いることによって、Ｓｔｏｒａｇｅ識別子を、これから放送されるコンテンツ・ファイルのファイル・サイズの大まかな推定値として使用できる。この大まかな推定値と、クライアント・デバイスに既に受信されたスケジュールＥＳＧフラグメントから得られた放送の開始時点及び終了時点とを用いて、初期の期間に亘って、帯域幅を推定できる。これは、特に、チャネルの帯域幅が変動する場合に有効である。クライアント・デバイスは、この方法を用いて、概算の帯域幅を推定できる。また、クライアントは、この方法を用いて、推定におけるエラーも算出できる。例えば、ファイル全体が一旦ダウンロードされると、そのファイルの実際のサイズが判明し、これを用いて帯域幅を再算定でき、従って、その後の推定がより正確になるように各推定パラメータを調節できる。
【００２４】
ファイル・ダウンロード・サービスは、ダウンロード用コンテンツをファイルの形態で提供するサービスと定義してもよい。これらのファイルは、受信機アプリケーションで消費（処理）されてユーザに提示される。このサービスのプロバイダは、クライアント・デバイスの電力及び記憶装置のニーズについて配慮する必要がある。コンテンツは継続的に放送されており、新たなコンテンツがクライアント・デバイスに記憶される一方、古いコンテンツがそれに置き換えられる。古いコンテンツの置き換えは、電力と共に時間にも配慮する必要がある。クライアント・デバイスは、コンテンツのファイル・サイズを事前に知っていれば、デバイス上のコンテンツを置き換える際にインテリジェントな選択を行え、それと同時に、受信のためのより優れた電力管理を行える。
【００２５】
一旦、帯域幅が推定されると、これから放送されるコンテンツのサイズが推定できる。
【００２６】
図３及び図４を参照し、クリップＡが近い将来の時刻Ｔ１に放送され、クライアント・デバイス４００が、自己のメモリ領域４０２に記憶済みのファイル・コンテンツ・クリップＢ，Ｃ及びＤを含んでいるシナリオを考える。クライアントは、先に受信した送信データから得たスケジュールＥＳＧ情報をパース（解析）することによって、クリップＡの放送時間を知ることができる。受信機（クライアント・デバイス４００）は、クリップＡを記憶すべきか否かを決定する必要がある。本例の説明の便宜上、クリップＢ，Ｃ及びＤが共にデバイス上の記憶スペースのかなりの割合を占有していると仮定する。本例におけるメモリ領域４０２は、コンテンツ及び／又はクライアント・デバイスの動作に関するプログラミング情報を記憶するための任意のタイプの既知のメモリであってもよい。一実施形態では、メモリ４０２には、本明細書に開示する本原理の各方法及び各処理を実施するプログラミングが含まれている。
【００２７】
クライアント・デバイス４００は、クリップＡのサイズを用いて、そのクリップを記憶するかどうかを決定する。クライアントは、クリップＡの推定ファイル・サイズを用いて、クリップＡを記憶するか否かを事前に決定できる。例えば、クライアント・デバイスは、クリップＡの実際のサイズを知ることなく、時刻Ｔ１で電源がオンになり、クリップＡの全てを受信する。ファイルのダウンロード完了（時刻Ｔ２）の後に、そのクリップのファイル・サイズが判る。クライアント・デバイスは、このファイル・サイズとクリップＡのその他の特徴（例えば、キーワード等）に基づいて、クリップＡを記憶する一方、既存のコンテンツ（クリップＢ、Ｃ及びＤ）の一部をこれに置き換えるか、あるいは、クリップＡを廃棄することができる。クリップＡを受信する電力を消費した後にクリップＡを廃棄することは、電力使用の観点から浪費であり、バッテリ寿命を減らすことになる。
【００２８】
クライアント・デバイスは、クリップＡの推定ファイル・サイズを用いて、クリップＡを記憶すべきか否かを事前に決定できる。デバイスは、クリップＡの記憶が不要であると決定した場合、そのクリップの放送期間中、電源をオンにする必要はなく、従って、その期間の間、自己の受信処理部の電源を切ることによって、デバイスの電源使用を低減できる。
【００２９】
図５には、コンテンツを記憶するか否かに関係なく、受信モジュール（すなわち、クライアント・デバイス）の電源をオンにする必要がある方法５００が示されている。その必要の主たる理由は、受信モジュールが、ＥＳＧスケジュールの受信（５０２）直後に起動される（５０４）ためである。コンテンツが受信され（５０６）、コンテンツの受信が終了したか否かが判定される（５０８）。コンテンツが完全に受信されると、ダウンロード済みサイズが算出され（５１０）、クライアント・デバイスが、コンテンツを記憶するか否かを決定する（５１２）。記憶しない場合、受信コンテンツは削除され（５１４）、デバイスはスケジュール受信状態に戻る。記憶する場合、受信コンテンツは記憶され（５１６）、デバイスはスケジュール受信状態に戻る。上述のように、この方法は、常に、クライアント・デバイス、すなわちユーザ・デバイスの電源をオンにして受信モード状態にする必要があり、従って、特にコンテンツを完全に受信した後に、ユーザが受信したコンテンツを削除する決定をした場合に、バッテリの電力使用が非効率となり得る。
【００３０】
図６Ａには、本原理の一実施形態による方法６００が示されている。この方法では、クライアント・デバイスにおける電源使用がより効率的に管理される。先ず、通信チャネルの帯域幅が特定される（６０２）。上述したように、この特定は、実際のＢＷ（帯域幅）であってもよいし、既知のＢＷ（帯域幅）であってもよいし、あるいは、任意の適切な既知のチャネル帯域幅推定方法を用いて推定してもよい。一旦、帯域幅が判ると、先に受信したＥＳＧ情報を用いて、ファイル（コンテンツ）のサイズが推定できる（６０４）。ファイル・サイズが特定あるいは推定されると、スマート・クライアント・デバイスは、ユーザの介入を必要とすることなく、クライアント・デバイスにそのファイル（コンテンツ）をダウンロード（記憶）すべきか否かを決定できる（６０６）。この決定は、ユーザによってクライアント・デバイスのメモリに記憶されたユーザ・プロファイルに事前に設定されたユーザの好みに基づいて行われる。
【００３１】
図６Ｂには、図６Ａのステップ６０４及び６０６の更に詳しいブロック図が示されている。先ず、スケジュールＥＳＧが受信される（６０８）。受信済みスケジュール・リストが、新たな今後のコンテンツ放送について反復適用されるか、あるいは、新たな今後のコンテンツ放送について見直される（６１０）。次に、ファイル・サイズが、放送の開始時間及び終了時間を用いて、スケジュール情報から算出（すなわち、推定）される（６１２）。この情報により、クライアント・デバイスは、コンテンツを記憶すべきか否かを決定できる（６０６）。クライアント・デバイスが記憶すべきであると決定すると、受信モジュールの電源がオンにされて、新たなコンテンツの受信が開始される（６１４）。クライアント・デバイスがそのコンテンツを受信し始めて（６１６）、そのコンテンツの全部が受信されると（６１８）、そのコンテンツが記憶され（６２０）、本プロセスは、最初に戻る。クライアント・デバイスは、本プロセスが完了すると、自動的に電源が落とされる。一般的に、クライアント・デバイスはアクティブでない場合には、電源が落とされる。クライアント・デバイスは、アクティブ状態にある場合、自己の受信処理ハードウェア構成部の電源を落とす。
【００３２】
本原理の一実施形態によれば、帯域幅が変動するチャネル、あるいは、帯域幅が一定であるチャネルについてのファイル・サイズの算出における各ステップは、ＥＳＧから得られ、次の通りである。
放送の継続時間＝放送終了時刻（EndBroadcastTime）−放送開始時刻（StartBroadcastTime）
ファイル・サイズ＝（チャネルの帯域幅）×（放送の継続時間）
【００３３】
本原理は、ハードウェア、ソフトウェア、ファームウェア、特定用途プロセッサ、あるいは、それらの組み合わせの様々な形態で実施できることを理解されたい。好ましくは、本原理は、ハードウェアとソフトウェアとの組み合わせとして実施される。更に、ソフトウェアは、プログラム記憶装置に実装されたアプリケーション・プログラムとして実施されることが好ましい。アプリケーション・プログラムは、任意の適切なアーキテクチャを備えたマシンにアップロードして、そのマシンにより実行できる。好ましくは、そのマシンは、１又は２つ以上の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、及び入力／出力（Ｉ／Ｏ）インタフェース等のハードウェアを有するコンピュータ・プラットフォーム上に実装される。コンピュータ・プラットフォームには、オペレーティング・システムとマイクロインストラクション・コードが含まれていてもよい。本明細書に記載された種々の処理と機能は、オペレーティング・システムを介して実行されるマイクロインストラクション・コードの一部、あるいは、アプリケーション・プログラムの一部、あるいは、それらの組み合わせであってもよい。更に、増設データ記憶装置、及び印刷装置等の種々のその他の周辺機器をコンピュータ・プラットフォームに接続してもよい。
【００３４】
更に、添付図面に示された各構成システム・コンポーネント及び方法ステップの一部はソフトウェアの形態で実施されることが望ましいため、システムのコンポーネント相互間、あるいは、プロセスのステップ相互間の実際の接続は、本原理がプログラムされる態様によって異なり得ることを理解されたい。本明細書に記載された各開示事項により、当業者であれば、本原理のような、及び、同様な実施形態、あるいは、同様なコンフィギュレーション（環境設定、機器構成等）を考案できるであろう。  いくつかの付記を記載しておく。〔付記１〕  スケジュール・リストを含む電子サービス・ガイド（ＥＳＧ）のデータをサーバから受信するステップと、  前記サーバと、前記サーバからの放送コンテンツを記憶する受信モジュールを含むクライアントとの間の通信チャネルの帯域幅を特定するステップと、  前記スケジュール・リストを新たな放送コンテンツについて反復適用するステップと、  前記特定された帯域幅と、前記新たなコンテンツの開始時刻および終了時刻を含む前記スケジュール・リストとから前記新たなコンテンツのサイズを推定するステップと、  前記新たなコンテンツの前記推定されたサイズと、ユーザによって予め提供された好みとに基づいて、前記クライアントに前記新たなコンテンツを記憶するために前記受信モジュールに対して動作電源を供給するかどうかを決定するステップと、  前記動作電源が前記受信モジュールに供給される場合、前記新たなコンテンツが記憶された後に前記受信モジュールの前記動作電源を切るステップと、を含む方法。〔付記２〕  前記新たなコンテンツの前記推定されたサイズに基づいて前記クライアントの記憶スペースの制限を定めるステップをさらに含み、  前記好みは、前記新たなコンテンツを前記クライアント上の既存のコンテンツと置き換えることによって記憶することを含む、付記１に記載の方法。〔付記３〕  前記新たなコンテンツが記憶された後に前記新たなコンテンツの実際のサイズを測定するステップと、  前記新たなコンテンツの前記実際のサイズに従って、前記帯域幅を特定するステップのためのパラメータを調節するステップと、をさらに含む、付記１に記載の方法。〔付記４〕  ネットワークを介したサーバとの通信チャネルを有するクライアントと、  前記クライアントに含まれるメモリと、  前記サーバからの放送コンテンツを前記メモリに記憶するように動作する、前記クライアントに含まれる受信モジュールと、を含み、  前記クライアントは、  スケジュール・リストを含む電子サービス・ガイド（ＥＳＧ）のデータを前記サーバから受信し、  前記サーバと前記クライアントとの間の通信チャネルの帯域幅を特定し、  前記スケジュール・リストを新たな放送コンテンツについて反復適用し、  前記特定された帯域幅と、前記新たなコンテンツの開始時刻および終了時刻を含む前記スケジュール・リストとから前記新たなコンテンツのサイズを推定し、  前記新たなコンテンツの前記推定されたサイズと、ユーザによって予め提供された好みとに基づいて、前記新たなコンテンツを記憶するために前記受信モジュールに対して前記動作電源を供給するかどうかを決定し、  前記動作電源が前記受信モジュールに供給される場合、前記新たなコンテンツが記憶された後に前記受信モジュールの動作電源を切るように動作する、装置。〔付記５〕  前記クライアントは、前記新たなコンテンツの前記推定されたサイズに基づいて前記メモリの記憶スペースの制限を定めるように動作し、  前記好みは、前記新たなコンテンツを前記メモリ上の既存のコンテンツと置き換えることによって記憶することを含む、付記４に記載の装置。〔付記６〕  前記クライアントは、前記新たなコンテンツが記憶された後に前記新たなコンテンツの実際のサイズを測定するように動作し、
前記クライアントは、前記新たなコンテンツの前記実際のサイズに従って、前記帯域幅の特定のためのパラメータを調節するように動作する、付記４に記載の装置。
【図１】
0005868888.tif 000002
【図２】
0005868888.tif 000003
【図３】
0005868888.tif 000004
【図４】
0005868888.tif 000005
【図５】
0005868888.tif 000006
【図６Ａ】
0005868888.tif 000007
【図６Ｂ】
0005868888.tif 000008