JP4688932B2 - 仮想チューナ管理 - Google Patents

Description

本発明は視聴システムの仮想管理方法に関する。

従来、テレビ番組を受信するためには、ユーザは、アンテナを介してや、ケーブルテレビ業者からなどで受信されたテレビ番組の放送に制限されていた。たとえばユーザは、テレビ番組の放送を受信するために、従来の「無線」アンテナを設定することや、ケーブルをテレビに接続することなどを行っていたかもしれない。

しかし今日、ユーザは、かつてないほど多様で大量なコンテンツに絶え間なくさらされている。たとえばユーザは、現在、ＰＰＶ（ｐａｙ−ｐｅｒ−ｖｉｅｗ）コンテンツ（たとえば、映画およびスポーツイベント）、ＶＯＤ（ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ）、テレビゲームなどを受信して、それらと対話することができる。さらに、これらの多様なコンテンツとの対話は、さまざまな方法で行うことができる。たとえばユーザは、（たとえば、コンテンツのストリームの出力を一時停止するための一時停止バッファ（ｐａｕｓｅ ｂｕｆｆｅｒ）を使用することを通じて）コンテンツの出力を「タイムシフト」することや、デジタルビデオレコーダを使用してコンテンツの記録をスケジュールすることなどを行うことができる。しかし、コンテンツの多様性、およびコンテンツと対話するために利用できる技術の多様性が高まることによって、システム内のコンテンツを管理するために使用されている従来の技術が時代遅れになる可能性があり、それによって、そうした従来の技術以外の方法でならばユーザにとって利用可能になるであろうコンテンツを提供すること、およびそうしたコンテンツと対話することが制限されるおそれがある。

仮想チューナ管理について説明する。ある視聴システム（ｖｉｅｗｉｎｇ ｓｙｓｔｅｍ）は、たとえば、テレビ番組などのコンテンツをレンダリングするように構成されている複数のクライアントデバイスを含むことができる。この視聴システムは、それらのクライアントデバイスから利用できるリソースをプールすることができ、それによって、それぞれのクライアントデバイスは、そのクライアントデバイスによってローカルに提供される機能に制限されない。たとえば、あるクライアントデバイスは、コンテンツの記録が視聴システム内の他のクライアントデバイスによって実行されるようにスケジュールすることができる。視聴システム内のコンテンツ消費を管理するために、仮想チューナを採用することができ、それらの仮想チューナのそれぞれは、コンテンツプロバイダによって提供されるコンテンツ（たとえば、テレビ番組）の単一のストリームを消費するための視聴システムの能力を表す。

仮想チューナは、ストリームしているコンテンツにどのクライアントデバイスがアクセスできるかを管理するために利用することができる。そのような１つの技術は、仮想チューナを特定のクライアントデバイスに「ロック」し、それによって、その特定のクライアントデバイスは、希望するときにはいつでも、視聴システム内の他のクライアントデバイスと交渉することなく、コンテンツを消費することができる。別の技術においては、スケジュールの対立を解消するためにクライアントデバイスの優先順位が決定される。仮想チューナを管理するためのその他のさまざまな技術も、その趣旨および範囲から逸脱しない形で考えられる。

ここで述べる概要は、以降の発明を実施するための最良の形態においてさらに説明するコンセプトから抜粋したものを、簡略化された形式で紹介するために提供されている。ここで述べる概要は、特許請求されている主題の鍵となる特徴や必要不可欠な特徴を特定することを意図するものではなく、特許請求されている主題の範囲を確定する際の補助として使用されることを意図するものでもない。

説明における例では、同様の構造および構成要素を示すために、同じ参照番号が利用されている。

概要
ユーザは、かつてないほど大量で多様なコンテンツに絶え間なくさらされている。さらに、このコンテンツと対話するために採用できる技術のタイプも増大している。たとえば、１つの視聴システムは、コンテンツを消費するための別々のリソースを有する複数のクライアントデバイスを含むことができる。第１のクライアントデバイスは、たとえば、コンテンツを記録するためのストレージを含むことができ、その一方で別のクライアントデバイスは、この機能を有さなくてもよい。複数のクライアントデバイスによって利用できるリソースを全体として共有するために、視聴システム内のリソースをプールすることができ、それによって、それらのリソースをお互いに共有することができる。

リソースをプールすることを利用して、さまざまなさらなる機能を提供することもできる。たとえば、視聴システムにおけるリソース消費のスケジューリングは、「ローカル」な制限を伴わずに実行することができる。たとえばクライアントデバイスは、コンテンツの記録を、たとえその機能がそのクライアントデバイス上でローカルに利用可能でなくても、スケジュールすることができる。さらに、クライアントデバイスが（たとえば、デジタルビデオレコーダとしてローカルストレージを使用することを通じた）記録機能を実際に有する場合でさえ、そのクライアントデバイスは、さらなる記録が視聴システム内の他の場所で（たとえば、他のクライアントデバイスによって）同時に実行されるようにスケジュールすることができる。この方法においては、視聴システムがクライアントデバイスのリソースをプールし、それによって、それぞれのクライアントデバイスは、希望に応じてプールからリソースを引き出すことができる。

しかし、視聴システムにとって利用可能なリソースの量が制限されるおそれがある。たとえば、コンテンツプロバイダによってサービスを提供されるそれぞれの場所（たとえば家庭）に対して、ある特定の量のリソース（たとえば回線容量）が割り当てられる可能性がある。その一方で、その場所は、その場所に割り当てられているよりも多くのリソースを消費する能力を有しているかもしれない。たとえば、その場所は、その場所にとってコンテンツプロバイダから利用できるよりも多くの回線容量を全体として消費することができる数量のクライアントデバイスを有しているかもしれない。さらに、リソースの「プール」から利用できるリソースの量が制限されるおそれもある。たとえば、複数のクライアントデバイスが全体として、いかなる一時点においても限られた数量のコンテンツのストリームを保存するための、すなわちコンテンツを記録するための機能を有しているかもしれない。

したがって、視聴システムにとって利用可能なリソースを管理するための技術を採用することができる。そのような１つの技術としては、仮想チューナを使用することが含まれ、これらの仮想チューナのそれぞれは、コンテンツプロバイダからのコンテンツのストリームを消費するための（１つまたは複数のクライアントデバイスを介した）視聴システムの能力を表す。したがって仮想チューナは、たとえばストリームのレンダリングやストリームの記録などをスケジュールするために計画することができるコンテンツ消費の抽象化（ａｂｓｔｒａｃｔｉｏｎ）を提供する。

しかし、複数のクライアントデバイスがコンテンツの消費に関するスケジュールの対立に直面する場合に遭遇する可能性がある。たとえば視聴システムは、いかなる一時点においてもコンテンツの２つのストリームを記録するように構成されている可能性があり、その一方で３つのクライアントデバイスが、ある特定の時点におけるコンテンツの記録を要求するかもしれない。このような例においては、コンテンツを消費する能力をどのクライアントデバイスに提供するかを判断するための管理技術を使用することができる。たとえば、対立が生じた場合に、どのクライアントデバイスが「勝つ」か、したがってコンテンツを記録できるかに関して判断を下すことができるように、クライアントデバイスの優先順位を決めることができ、これに関するさらなる説明については、図３に関連して見ることができる。別の例においては、他のクライアントデバイスによって実行されるスケジューリングにかかわらずに、コンテンツを消費する能力を特定のクライアントデバイスに提供するように、コンテンツの消費を「ロック」することができ、これに関するさらなる説明については、図４に関連して見ることができる。

以降の説明においては、はじめに、仮想チューナ管理技術を採用するように機能する例示的な環境について説明する。次いで、この例示的な環境によって、ならびにその他の環境において実施することができる例示的な手順について説明する。そして、この例示的な環境において採用することができる例示的なシステムについて説明する。

例示的な環境
図１は、仮想チューナ管理技術を採用するように構成されている例示的な一実装形態における環境１００を示している。図１の環境１００は、ＩＰベースのテレビ（ＩＰＴＶ：ＩＰ−ｂａｓｅｄ ｔｅｌｅｖｉｓｉｏｎ）環境として示されているが、環境１００は、従来のテレビ放送環境や、バックチャネル通信機能（ｂａｃｋ−ｃｈａｎｎｅｌ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）を有する放送環境など、その他のさまざまな構成を前提とすることができる。

環境１００は、（複数のコンテンツプロバイダを代表することができる）コンテンツプロバイダ１０２と、クライアントデバイス１０６（１）〜１０６（Ｎ）として図示されている任意の数のクライアントデバイスを含むことができる視聴システム１０４とを含む。視聴システム１０４は、テレビ番組などのコンテンツを視聴するためのいくつかの視聴エリア（たとえば、別々の部屋）を有する家庭用視聴システムとして図示されている。視聴システム１０４は、特定の建物（たとえば家庭）内で採用されるものとして示されているが、視聴システム１０４を、その趣旨および範囲から逸脱することなく、複数の建物において採用することもできるということは明らかなはずである。

視聴システム１０４は、通信ネットワーク１０８（この例では、ＩＰベースのネットワークである）を介してコンテンツプロバイダ１０２と通信するように構成されている。コンテンツプロバイダ１０２は、ストレージ１１２、たとえばコンピュータ可読メディア内に保存されているさまざまなコンテンツ１１０（ｃ）（ここでの「ｃ」は、１から「Ｃ」までの任意の整数とすることができる）を含むものとして図示されている。

コンテンツ１１０（ｃ）は、さまざまな方法で（たとえば、コンテンツマネージャーモジュール１１４を実行することを通じて）通信ネットワーク１０８を介して配信されるように構成することができる。たとえばコンテンツ１１０（ｃ）は、任意の形態のテレビ番組、コマーシャル、音楽、映画、ＶＯＤ（ｖｉｄｅｏ ｏｎ−ｄｅｍａｎｄ）、ＰＰＶ（ｐａｙ−ｐｅｒ−ｖｉｅｗ）、映画およびその他のメディアコンテンツ、記録されたメディアコンテンツ、インタラクティブゲーム、ネットワークベースのアプリケーション、ならびにその他の任意の類似のオーディオコンテンツ、ビデオコンテンツ、および／またはイメージコンテンツを含むことができる。さらに、コンテンツ１１０（ｃ）は一般に、コンピューティングデバイスからテレビベースのセットトップボックスなどのクライアントデバイス１０６（１）〜１０６（Ｎ）のうちの１つまたは複数へストリームされる音楽を含むことができ、そしてサーバから配信されるＶＯＤ（ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ）メディアコンテンツ、フォトスライドショー、ならびに任意のタイプのコンテンツソースから受信されるその他の任意のオーディオコンテンツ、ビデオコンテンツ、および／またはイメージコンテンツを含むこともできる。

通信ネットワーク１０８上から受信されるコンテンツ１１０（ｃ）（ならびにローカルで利用可能なコンテンツ）の消費をコントロールするために、クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれは、それぞれのコンテンツモジュール１１６（１）〜１１６（Ｎ）を含むものとして図示されている。コンテンツモジュール１１６（１）〜１１６（Ｎ）は、コンテンツの消費に関連したさまざまな機能を提供するために実行することができる。たとえばコンテンツモジュール１１６（１）〜１１６（Ｎ）は、特定のコンテンツ１１０（ｃ）を要求する目的でコンテンツプロバイダ１０２（より詳細には、コンテンツマネージャーモジュール１１４）と通信するために実行することができる。たとえばコンテンツモジュール１１６（１）は、実行されると、ＶＯＤやＰＰＶなどを注文するための認証および課金の情報を提供することができる。別の例においては、コンテンツモジュール１１６（１）〜１１６（Ｎ）は、通信ネットワーク１０８から受信されたコンテンツ１１０（ｃ）を解凍して復号化し、またその他のデジタル権利管理機能を提供するために実行することができる。その他のさまざまな例も考えられる。

クライアントデバイス１０６（１）は、たとえば、オーディオデータ、ビデオデータ、および／またはイメージデータを提供する任意のタイプのテレビ、モニタ、あるいは類似のテレビベースのディスプレイシステムなどのディスプレイデバイス１２０へ通信可能に結合されているセットトップボックス１１８によって実装されるものとして図示されている。クライアント１０６（１）はまた、ＤＶＲ（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｒｅｃｏｒｄｅｒ）機能を含むものとして図示されている。たとえばクライアントデバイス１０６（１）は、コンテンツモジュール１１６（１）を実行することを通じて、コンテンツプロバイダ１０２から通信ネットワーク１０８を介して受信されたコンテンツ１１０（ｃ）をストレージ１２２内にコンテンツ１２４（ｏ）として記録することができ、ここでの「ｏ」は、１から「Ｏ」までの任意の整数とすることができる。したがってクライアントデバイス１０６（１）は、その後にクライアントデバイス１０６（１）のユーザによる希望に応じてコンテンツ１２４（ｏ）をストレージ１２２から出力することができる。さらに、クライアントデバイス１０６（１）は（たとえば、コンテンツモジュール１１６（１）を実行することを通じて）、たとえば一時停止バッファを使用することを通じてコンテンツ１２４（ｏ）の再生を一時停止することによってコンテンツ１２４（ｏ）の出力を「タイムシフト」することなど、その他のＤＶＲ関連機能を提供することができる。

視聴システム１０４は、コンテンツを記録するためのその他のさまざまな技術を利用することもできる。たとえば、ストレージ１２２を視聴システム１０４の独立したコンポーネントとして実装して、マネージャークライアントデバイス１０６（１）に接続することができる。代替としては、ストレージ１２２は、図示されているように、他のリモートクライアントデバイス１０６（２）〜１０６（Ｎ）のうちの任意のデバイスから開始された記録を管理するマネージャークライアントデバイス１０６（１）のコンポーネントとして実装することができる。さらに別の実施形態においては、ストレージ１２２は、マネージャークライアントデバイス１０６（１）によって中央で管理される記録メディアをクライアントデバイス１０６（１）〜１０６（Ｎ）のうちの任意の１つまたは複数が含む分散型の記録システムとすることができる。またさらに別の実施形態においては、ストレージ１２２は、（たとえば、ヘッドエンドとして構成される場合には）コンテンツプロバイダ１０２によって実装して、ＮＤＶＲ（「ｎｅｔｗｏｒｋ ｄｉｇｉｔａｌ ｖｉｄｅｏ ｒｅｃｏｒｄｅｒ」）としてマネージャークライアントデバイス１０６（１）によって管理することができる。すなわちストレージ１２２は、クライアントデバイス１０６（１）〜１０６（Ｎ）のうちの１つまたは複数に応答する「空中のドライブ（drive in the sky）」として提供することもできる。

クライアントデバイス１０６（１）〜１０６（Ｎ）のわずかな例について説明したが、クライアントデバイス１０６（１）〜１０６（Ｎ）は、無線電話、ゲーム機、「メディアセンター」など、その他のさまざまな方法で構成することもできる。たとえばクライアントデバイス１０６（Ｎ）は、図１のクライアントデバイス１０６（１）とは異なり、ＤＶＲ機能を含まないセットトップボックスとして図１に示されている。したがって、クライアントデバイス１０６（１）〜１０６（Ｎ）をさまざまな異なる方法で実装して、任意の数および組合せの異なるコンポーネントを有する異なる分量の機能（たとえば、「軽量な」デバイスや「重厚な」デバイス）を提供することができ、これに関する例については、図５に示されている例示的なクライアントデバイス１０６（ｎ）を参照してさらに説明する。同様に、環境１００は、任意の数および組合せの異なるコンポーネントと共に実装することができ、これに関する例については、図６に示されている例示的なエンターテイメント／インフォメーションシステム（ｅｎｔｅｒｔａｉｎｍｅｎｔ ａｎｄ ｉｎｆｏｒｍａｔｉｏｎ ｓｙｓｔｅｍ）６００を参照して後述する。

コンテンツ１１０（ｃ）は、さまざまな方法でコンテンツプロバイダ１０２によってクライアントデバイス１０６（１）〜１０６（Ｎ）に割り当てることができる。たとえば、コンテンツプロバイダ１０２によってサービスを提供される建物のうちのそれぞれ（たとえば、図示されている家庭）に特定の回線容量を割り当てることができる。そしてそれらの建物は、その割り当てられた回線容量の部分をどのクライアント１０６（１）１０６（Ｎ）が受け取るかを決定するための１つまたは複数の技術を使用することができる。すなわち、視聴システム１０４に割り当てられた回線容量のどの部分が特定のクライアントデバイス１０６（１）〜１０６（Ｎ）に提供されるかを、その視聴システム１０４（そのもの）が割り当てることができる。しかし、視聴システム１０４に割り当てられているコンテンツの量が、その視聴システムによって消費できるコンテンツの量よりも少ない可能性があり、たとえば、その視聴システムは、コンテンツプロバイダ１０２から利用できるストリームの数よりも多くのクライアントデバイスを含む可能性がある。さらに、クライアントデバイスのそれぞれによって提供される機能は、前述のように、お互いに異なる可能性がある。

したがって、視聴システム１０４内の（より詳細には、その視聴システム内のクライアントデバイス１０６（１）〜１０６（Ｎ）による）コンテンツの消費を管理するために、そして機能を共有するために、１つまたは複数の仮想チューナ１２６（ｖ）を採用することができ、ここでの「ｖ」は、１から「Ｖ」までの任意の整数とすることができる。仮想チューナ１２６（ｖ）のそれぞれは、コンテンツプロバイダ１０２からのコンテンツのストリームを消費するための視聴システム１０４の少なくとも一部分の能力を表す。たとえば、コンテンツ１１０（ｃ）をレンダリングするために、クライアントデバイス１０６（Ｎ）によってある仮想チューナ１２６（ｖ）の使用をスケジュールすることができる。同様に、コンテンツ１１０（ｃ）をストレージ１２２内にコンテンツ１２４（ｏ）として保存するために、クライアントデバイス１０６（１）によって仮想チューナ１２６（ｖ）のうちの別の１つをスケジュールすることができる。さらにクライアントデバイス１０６（１）は、コンテンツをレンダリングする目的でも、仮想チューナ１２６（ｖ）のうちの別の１つの使用をスケジュールすることができる。

クライアントデバイス１０６（１）〜１０６（Ｎ）は、スケジューリングを行うそれらのクライアントデバイス１０６（１）〜１０６（Ｎ）自体から利用できる分量を超えるコンテンツを消費するために仮想チューナ１２６（ｖ）の使用をスケジュールすることもできる。たとえばクライアントデバイス１０６（Ｎ）は、たとえローカルストレージデバイスを有していなくても、対応するスケジューリングモジュール１２８（Ｎ）を実行して、コンテンツの複数のストリームを同時に記録するようにスケジュールすることができる。クライアントデバイス１０６（１）も、自分のそれぞれのスケジューリングモジュール１２８（１）を実行することを通じて同様のスケジューリングを行うことができる。したがってクライアントデバイス１０６（１）〜１０６（Ｎ）は、視聴システム１０４内の複数のクライアントデバイス１０６（１）〜１０６（Ｎ）によって全体として提供されているリソースの「プールから引き出しを行う」ことができる。

リソースが視聴システム１０４内にプールされるため、対立を回避するための、そしてクライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれによって視聴システム１０４内のリソースを効率よく使用するための管理技術が使用される。たとえば、クライアントデバイス１０６（１）〜１０６（Ｎ）のお互いに対する優先順位を決めることができ、それによって、スケジュールの対立に直面した際に「勝者」を判定することができ、これに関するさらなる説明については、図３に関連して見ることができる。

別の例においては、仮想チューナ１２６（ｖ）を特定のクライアントデバイス１０６（１）に「ロック」することができる。たとえばクライアントデバイス１０６（Ｎ）は、ある家庭では親の寝室に配置されている可能性がある。したがって、クライアントデバイス１０６（Ｎ）にとって希望するときにはいつでもコンテンツ１１０（ｃ）が必ず利用可能であるようにしておくために、仮想チューナ１２６（ｖ）をクライアントデバイス１０６（Ｎ）にロックすることができ、それによってクライアントデバイス１０６（１）は、たとえばスケジューリングモジュール１２８（１）を実行することを通じて、仮想チューナ１２６（ｖ）の使用をスケジュールすることはできない。仮想チューナをロックすることに関するさらなる説明については、図４に関連して見ることができる。

一般に、本明細書に記載されている機能のいずれも、ソフトウェア、ファームウェア（たとえば、固定論理回路（ｆｉｘｅｄ ｌｏｇｉｃ ｃｉｒｃｕｉｔｒｙ））、手動による処理、あるいはこれらの実装形態の組合せを使用して実装することができる。「モジュール」、「機能」、および「論理」という用語は、本明細書において使用される際には、一般にソフトウェア、ファームウェア、あるいはソフトウェアおよびファームウェアの組合せを表す。ソフトウェアによる実装形態の場合には、モジュール、機能、あるいは論理は、プロセッサ（たとえば、１つまたは複数のＣＰＵ）上で実行された際に指定のタスクを実行するプログラムコードに相当する。このプログラムコードは、コンピュータで読み取り可能な１つまたは複数のメモリデバイス内に格納することができ、これに関するさらなる説明については、図２に関連して見ることができる。以降で説明するコンテンツの消費および管理に関する技術の特徴は、プラットフォームに依存せず、つまりこれらの技術は、さまざまなプロセッサを有するさまざまな市販のコンピューティングプラットフォーム上に実装することができる。

図２は、システム２００の例示的な一実装形態を示しており、図１の視聴システム１０４によってコンテンツプロバイダ１０２からのコンテンツを消費するために仮想チューナを使用することをさらに詳細に示している。図示されている視聴システム１０４は、複数のクライアントデバイス１０６（１）、１０６（２）、１０６（３）、１０６（４）、および１０６（Ｎ）を含む。このシステムにおいては、クライアントデバイス１０６（１）は、４つの仮想チューナ１２６（１）〜１２６（４）の使用を仲裁するマネージャークライアントデバイスである。仮想チューナ１２６（１）〜１２６（４）によって表される機能は、対応するクライアントデバイス１０６（１）〜１０６（４）からローカルに利用できるとは必ずしも限らないということを示すために、仮想チューナ１２６（１）〜１２６（４）は破線（ｐｈａｎｔｏｍ）で示されている。たとえばその機能は、前述のように、視聴システム１０４内において利用可能なリソースの「プール」から引き出すことができる。

マネージャークライアントデバイス１０６（１）は、４つの仮想チューナ１２６（１）〜１２６（４）のコントロールを仲裁することによって、通信ネットワーク１０８を介したコンテンツプロバイダ１０２からの４つのコンテンツストリームの消費をコントロールすることができる。たとえばコンテンツストリームは、「リモート」クライアントデバイス１０６（２）〜１０６（Ｎ）（すなわち、コントロールを仲裁する権限を有さないクライアントデバイス）によってマネージャークライアントデバイス１０６（１）を通じて得ることができる。別の例においては、ストリームはマネージャークライアントデバイス１０６（１）によって管理されるが、リモートクライアントデバイス１０６（２）〜１０６（Ｎ）は、通信ネットワーク１０８を介してコンテンツプロバイダ１０２から直接ストリームを受信する。その他のさまざまな例も考えられる。

コンテンツストリームは具体的に示されていないが、図示されている通信リンクは、コンテンツストリームを通信するように構成されているさまざまな通信リンクを例示している。さらに、これらの通信リンクは、一方向の通信リンクとして解釈されることを意図するものではなく、むしろ双方法の通信に相当することもできる。第１のコンテンツストリームからの視聴選択（ｖｉｅｗｉｎｇ ｓｅｌｅｃｔｉｏｎ）が、マネージャークライアントデバイス１０６（１）におけるディスプレイデバイス上で視聴するためにレンダリングされているものとして示されている。第２のコンテンツストリームは、マネージャークライアントデバイス１０６（１）からリモートクライアントデバイス１０６（２）へ導かれるものとして示されている。同様に、第３のコンテンツストリームは、マネージャークライアントデバイス１０６（１）からリモートクライアントデバイス１０６（３）へ導かれ、第３のコンテンツストリームからの視聴選択は、個別のディスプレイデバイス上で視聴するためにレンダリングされているものとして示されている。同様に、第４のコンテンツストリームは、マネージャークライアントデバイス１０６（１）からリモートクライアントデバイス１０６（４）へ導かれ、第４のコンテンツストリームからの視聴選択は、個別のディスプレイデバイス上で視聴するために示されている。

しかし前述のように、視聴システム１０４にとって利用可能な回線容量は、存在するクライアントデバイスと同じ数のコンテンツストリームを受け入れることができないかもしれない。図２に示されているように、たとえばある家庭が、その家庭の全体にわたってさまざまな部屋に、そしてさまざまな場所に５台以上のテレビを有することは珍しくない。この例においては、クライアントデバイスの数は、コンテンツプロバイダ１０２から視聴システム１０４に割り当てられているコンテンツストリームの数を超えている。たとえば視聴システム１０４は、少なくとも１つの第５のクライアントデバイス１０６（Ｎ）を含むものとして示されている。クライアントデバイス１０６（Ｎ）の対応するディスプレイデバイスは、ビデオストリームが利用不可能であることを示しており、これは、仮想チューナ１２６（１）〜１２６（４）を介して消費されるコンテンツストリーム（たとえば、４つのコンテンツストリーム）が、他のクライアントデバイス１０６（１）〜１０６（４）によって既にスケジュールされているためである。

マネージャークライアントデバイス１０６（１）は、仮想チューナ１２６（１）〜１２６（４）を使用することを通じて分割された消費のスケジュール２０２を保持するものとして図示されている。たとえばスケジュール２０２は、仮想チューナ２０４（たとえば、仮想チューナ１２６（１）〜１２６（４））を識別する複数の項目と、その識別された仮想チューナを使用するクライアントデバイス（たとえば、クライアント１０６（１）〜１０６（４））のクライアントＩＤ ２０６と、その識別された仮想チューナ２０４が使用されている時間２０８とを含むことができる。

スケジュールの対立を解消するために、スケジュール２０２は、識別された仮想チューナ２０４をスケジュールした、クライアントＩＤ ２０６によって識別されたクライアントのクライアント優先順位２１０を識別することもできる。たとえば、クライアントデバイス１０６（１）〜１０６（４）のそれぞれには、仮想チューナ１２６（１）〜１２６（４）の消費をコントロールするための優先順位数値（ｎｕｍｅｒｉｃａｌ ｐｒｉｏｒｉｔｙ）を与えることができる。クライアントデバイス１０６（４）が、たとえば仮想チューナ１２６（４）の使用をスケジュールする際には、そのクライアントデバイス１０６（４）に割り当てられているクライアント優先順位２１０と、クライアントＩＤ ２０６とが、スケジュール２０２内に保存される。しかし、クライアント１０６（Ｎ）が仮想チューナの使用をスケジュールしようとすると、仮想チューナ１２６（１）〜１２６（４）のそれぞれは、他のクライアントデバイス１０６（１）〜１０６（４）によって使用されるように既にスケジュールされている。したがって、どのクライアントデバイス１０６（１）〜１０６（４）、１０６（Ｎ）がコンテンツを消費するかを管理するために、クライアントデバイス１０６（Ｎ）のクライアント優先順位をスケジュール２０２内のそれぞれのクライアント優先順位２１０と比較して、クライアント１０６（Ｎ）が、仮想チューナの既存のスケジュールされた使用を「無効にする」ことができるかどうかを判定することができる。このようにして、コンテンツプロバイダ１０２からのコンテンツを消費するために視聴システム１０４のリソースを使用しようとする際に「誰が勝つか」を判定する目的で、クライアントに割り当てられている優先順位を使用することができる。

別の例においては、それぞれのクライアントデバイスがユーザ入力を受け取っていない時間に基づいてクライアントに優先順位を割り当てることによってなど、動的な優先順位を確立することができる。通知を使用することもでき、したがって、最も低い優先順位を有するクライアントから仮想チューナを自動的に「取る」のではなく、そのクライアントのユーザに許可を求めることができる。その他のさまざまな例も考えられ、それらに関するさらなる説明については、図３に関連して見ることができる。

スケジュール２０２は、ロック項目２１２を含むこともでき、このロック項目２１２は、識別された仮想チューナ２０４が、識別されたクライアント２０６デバイスにロックされているということを示す。たとえば、図２に示されている家庭は、各クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれが配置されている別々の部屋を含む可能性がある。ユーザ（たとえば親）は、希望するときに必ず家庭内の特定の場所（たとえば、親の寝室）でコンテンツを消費できるようにするために、仮想チューナ（たとえば、仮想チューナ１２６（１））の使用を、特定の場所、たとえば親の寝室に配置されている特定のクライアントデバイス１０６（１）にロックすることができる。したがって、ロックされた仮想チューナ１２６（１）は、視聴システム内の他のクライアントデバイス１０６（２）〜１０６（Ｎ）にとって利用可能にはならない。一実装形態においては、ロックされた仮想チューナ（たとえば、この例においては仮想チューナ１２６（１））は、対応するクライアントデバイス、たとえばクライアントデバイス１０６（１）によって使用されていない場合でさえ、他のクライアントデバイス１０６（２）〜１０６（Ｎ）にとって利用可能にはならない。さらに、ロックされた仮想チューナ１２６（１）を有するクライアントデバイス１０６（１）は、他の仮想チューナ１２６（２）〜１２６（４）が利用可能な場合には、それらの仮想チューナ１２６（２）〜１２６（４）を依然として活用することができる。したがって、この例においてクライアントデバイス１０６（１）は、４つの仮想チューナ１２６（１）〜１２６（４）のすべてにアクセスすることができ、その一方で他のクライアントデバイス１０６（２）〜１０６（Ｎ）は、「ロックされていない」仮想チューナ１２６（２）〜１２６（４）にアクセスすることができる。その他のさまざまな例も考えられ、それらに関するさらなる説明については、図４に関連して見ることができる。

例示的な手順
以降の説明では、前述のシステムおよびデバイスを利用して実施することができる仮想チューナ管理技術について説明する。これらの手順のそれぞれの態様は、ハードウェア、ファームウェア、またはソフトウェア、あるいはそれらの組合せで実装することができる。これらの手順は、１つまたは複数のデバイスによって実行されるオペレーションを指定する一式のブロックとして示されており、それぞれのブロックによるオペレーションを実行するために示されている順序に必ずしも限定されない。以降の説明の複数の部分においては、図１の環境１００および図２のシステム２００を参照する。

図３は、例示的な一実装形態における手順３００を示しており、ここでは、複数の仮想チューナを採用することによって、コンテンツを消費するための視聴システム内のリソースがプールされ、それらの仮想チューナのスケジューリングは、スケジューリング優先順位に基づいて管理される。複数のクライアントデバイスを有する視聴システム内にコンテンツ消費リソース（ｃｏｎｔｅｎｔ ｃｏｎｓｕｍｐｔｉｏｎ ｒｅｓｏｕｒｃｅ）がプールされる（ブロック３０２）。たとえば視聴システム１０４は、複数のクライアントデバイス１０６（１）〜１０６（Ｎ）、すなわち、コンテンツプロバイダ１０２からのコンテンツ１１０（ｃ）をレンダリングすること、コンテンツ１１０（ｃ）をストレージ(記憶装置)内に保存してＤＶＲ機能を提供することなどのコンテンツ消費能力を有する複数のクライアントデバイス１０６（１）〜１０６（Ｎ）を含むことができる。さらに、それらのクライアントデバイスによって提供される機能は、お互いに異なる可能性があり、それによって、視聴システム内のあるクライアントデバイスは、別のクライアントデバイス上では利用できないコンテンツ消費リソースを単独で有する可能性がある。これらのクライアントデバイス１０６（１）〜１０６（Ｎ）は、リソースを「プール」するためにお互いに通信することができ、それによって、クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれは、全体としての視聴システム１０４から利用できる機能にアクセスすることができる。

コンテンツプロバイダからのコンテンツの単一のストリームを消費するのに十分な視聴システムのリソースのそれぞれの部分が、仮想チューナとして表される（ブロック３０４）。上述の例について続けると、視聴システム１０４は、クライアントデバイス１０６（１）〜１０６（Ｎ）を使用することを通じて、コンテンツプロバイダ１０２からのコンテンツをレンダリングおよび記録することができる。コンテンツ１０２を消費するために利用できるリソースが、複数の仮想チューナへと分割され、それらの仮想チューナは、視聴システム１０４内のクライアントデバイス１０６（１）〜１０６（Ｎ）のいずれによっても「利用」することができる。したがって、クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれは、他のクライアントデバイスによって提供される視聴システム１０４のリソースにアクセスすることができる。

一実装形態においては、視聴システム１０４内で利用できる仮想チューナの数もまた、コンテンツプロバイダ１０２から利用できるコンテンツ１１０（ｃ）の量によって制限される。たとえばコンテンツプロバイダ１０２は、いかなる一時点においても視聴システム１０４にコンテンツの４つのストリームを提供するように構成することができる。したがって、この例における仮想チューナの数は、４つに制限することができる。その他のさまざまな例も考えられる。

スケジューリング優先順位が、クライアントデバイスのうちの１つまたは複数に割り当てられる（ブロック３０６）。たとえば、図２のクライアントデバイス１０６（１）、１０６（２）、１０６（３）、１０６（４）、および１０６（Ｎ）のそれぞれに対して「１」、「２」、「３」、「４」、および「５」といった具合に、クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれに一意の優先順位数値を割り当てることができる。そしてスケジューリング優先順位に従って仮想チューナのスケジューリングを管理することができる（ブロック３０８）。この例においては、クライアントデバイス１０６（１）〜１０６（Ｎ）の優先順位は、「小さい数字」から「大きい数字」へという順になっており、これによって、より小さい数字がより大きい数字に「勝つ」。したがって、スケジュールの対立に直面した場合には、クライアントデバイス１０６（１）〜１０６（Ｎ）に割り当てられている優先順位を使用して、それらの対立を解消することができる。たとえば、「より高い」優先順位を有するクライアントデバイスは、「より低い」優先順位を有するクライアントデバイスによるスケジュールされている消費を、たとえそれが前もってスケジュールされていたものであっても、無効にすることができる。前述のように動的な優先順位付けを使用することを通じてなど、仮想チューナの使用におけるスケジュールの対立を解消するために優先順位を使用するその他のさまざまな例も、その趣旨および範囲から逸脱しない形で考えられる。

図４は、例示的な一実装形態における手順４００を示しており、ここでは、コンテンツプロバイダからのコンテンツの単一のストリームを消費するために視聴システム内で利用できるリソースを表す仮想チューナが、その視聴システム内の特定のクライアントデバイスによって使用されるようにロックされている。複数のクライアントデバイスを有する視聴システムが、複数の仮想チューナを使用してコンテンツ消費リソースをプールするように構成される（ブロック４０２）。前述のように、クライアントデバイス１０６（１）〜１０６（Ｎ）は、リソースを共有するために通信することができ、それによって、コンテンツを消費するために視聴システム１０４内で利用できる機能が、視聴システム１０４内のクライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれにとって利用可能になる。

ある仮想チューナを対応するクライアントデバイスにロックしたいということを指定する入力が、複数のクライアントデバイスのうちの１つのクライアントデバイスにおいて受け取られる（ブロック４０４）。たとえばユーザは、クライアントデバイス１０６（１）と対話して、仮想チューナ１２６（１）をそのクライアントデバイスにロックしたいということを示すことができる。この例においては、ユーザは、自分が対話しているクライアントデバイスに仮想チューナをロックするが、ユーザは、その趣旨および範囲から逸脱することなく、クライアントデバイス１０６（１）との対話を通じて他のクライアントデバイス１０６（２）〜１０６（Ｎ）を仮想チューナにロックすることもできるということは明らかなはずである。

仮想チューナが、対応するクライアントデバイスにロックされ、それによって、クライアントデバイスのうちの別のクライアントデバイスは、そのロックされた仮想チューナを使用したコンテンツの消費をスケジュールすることはできない（ブロック４０６）。たとえば、仮想チューナ１２６（１）がクライアントデバイス１０６（１）にロックされると、その仮想チューナは、他のクライアントデバイス１０６（２）〜１０６（Ｎ）によってコンテンツを消費するためのスケジューリングには利用できない。したがって、他のクライアントデバイス１０６（２）〜１０６（Ｎ）は、仮想チューナ１２６（２）〜１２６（４）を使用することを通じてコンテンツの消費をスケジュールすることができ、それらの仮想チューナ１２６（２）〜１２６（４）のスケジューリングについては、図３に関連して前述した優先順位付けの技術を使用することを通じて決定することができる。さらにクライアントデバイス１０６（１）は、さらなるコンテンツ消費のスケジューリングを希望する場合には、他の仮想チューナ１２６（２）〜１２６（４）の使用をスケジュールすることもできる。その他のさまざまな例も考えられる。

例示的なシステム
図５は、クライアントデバイス１０６（ｎ）（これは、図２のクライアントデバイス１０６（１）〜１０６（Ｎ）のうちの１つまたは複数に相当してもよく、あるいは相当しなくてもよい）の例示的な一実装形態５００をさらに詳しく示している。クライアントデバイス１０６（ｎ）は、任意の形態のコンピューティングクライアントデバイス、電子クライアントデバイス、および／またはテレビベースのクライアントデバイスとして実装することができる。

クライアントデバイス１０６（ｎ）は、図５に示されているように、１つまたは複数のメディアコンテンツ入力５０２を含み、このメディアコンテンツ入力５０２は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）入力を含むことができ、このＩＰ入力を介して、メディアコンテンツのストリームがＩＰベースのネットワークを経由して受信される。クライアントデバイス１０６（ｎ）は、（１つまたは複数の）通信インターフェース５０４をさらに含み、この通信インターフェース５０４は、シリアルインターフェースおよび／またはパラレルインターフェース、無線インターフェース、任意のタイプのネットワークインターフェース、モデムのうちの任意の１つまたは複数として、またその他の任意のタイプの通信インターフェースとして実装することができる。無線インターフェースは、クライアントデバイス１０６（ｎ）が、リモートコントロールデバイス５０８、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）５１０、携帯電話５１２から、あるいは別のＩＲ（ｉｎｆｒａｒｅｄ）入力デバイス、８０２．１１入力デバイス、Ｂｌｕｅｔｏｏｔｈ入力デバイス、または類似のＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）入力デバイスからなど、入力デバイスからコントロール入力コマンド５０６およびその他の情報を受信できるようにする。

ネットワークインターフェースは、クライアントデバイス１０６（ｎ）と通信ネットワークとの間における接続を提供し、これによって、他の電子デバイスおよびコンピューティングデバイスは、デバイス１０６（ｎ）とデータを通信することができる。同様に、シリアルインターフェースおよび／またはパラレルインターフェースは、クライアントデバイス１０６（ｎ）と他の電子デバイスやコンピューティングデバイスとの間において直接データ通信を提供する。モデムは、従来の電話線、ＤＳＬ（ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）接続、ケーブル、および／またはその他のタイプの接続を介したクライアントデバイス１０６（ｎ）と他の電子デバイスおよびコンピューティングデバイスとの通信を容易にする。

クライアントデバイス１０６（ｎ）はまた、１つまたは複数のプロセッサ５１４（たとえば、マイクロプロセッサ、コントローラなどのいずれか）を含み、これらのプロセッサ５１４は、他の電子デバイスおよびコンピューティングデバイスと通信するためなど、クライアントデバイス１０６（ｎ）のオペレーションをコントロールするためのさまざまなコンピュータ実行可能命令を処理する。クライアントデバイス１０６（ｎ）は、１つまたは複数のメモリコンポーネントなどのコンピュータ可読メディア５１６と共に実装することができ、それらの例としては、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、不揮発性メモリ（たとえば、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュメモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどのうちの任意の１つまたは複数）、およびディスクストレージデバイスが含まれる。ディスクストレージデバイスは、ハードディスクドライブ、記録可能なおよび／または書き換え可能なＣＤ（ｃｏｍｐａｃｔ ｄｉｓｃ）、ＤＶＤ、ＤＶＤ＋ＲＷなど、任意のタイプの磁気ストレージデバイスや光ストレージデバイスを含むことができる。単一のコンピュータ可読メディア５１６が図示されているが、コンピュータ可読メディア５１６は、複数のタイプおよび組合せのコンピュータ可読メディアを表すことができるということは明らかなはずである。

コンピュータ可読メディア５１６は、ソフトウェアアプリケーション、ならびにクライアントデバイス１０６（ｎ）のオペレーション上の側面に関連したその他の任意のタイプの情報およびデータなど、さまざまな情報および／またはデータを保存するためのデータストレージメカニズムを提供する。たとえば、オペレーティングシステム５１８および／またはその他のアプリケーションモジュール５２０は、コンピュータ可読メディア５１６を用いてソフトウェアアプリケーションとして保持して、（１つまたは複数の）プロセッサ５１４上で実行することができる。

たとえば、その他のアプリケーションモジュール５２０のうちの１つまたは複数は、番組ガイドデータを処理して表示用の番組ガイドを作成する番組ガイドアプリケーションとして実装することができる。番組ガイドによって、視聴者は、画面上の表示内をナビゲートして、自分にとって関心のある放送番組、録画された番組、ＶＯＤ（ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ）、映画、選りすぐりのインタラクティブゲーム、ネットワークベースのアプリケーション、およびその他のメディアアクセス情報やコンテンツを見つけ出すことができる。同様に、コンピュータ可読メディア５１６は、図１〜図４に関連して前述したように仮想チューナの使用をスケジュールするために使用されるスケジューリングモジュール５２２および／またはスケジュール５２４を格納することもできる。クライアントデバイス１０６（ｎ）は、コンテンツモジュール５２８（これは、図１のコンテンツモジュール１１６（１）〜１１６（Ｎ）に相当してもよく、あるいは相当しなくてもよい）と、記録されたコンテンツ５５２を保持するための記録用メディア５５０（これは、図１のストレージ１２２に相当してもよく、あるいは相当しなくてもよい）とを有するＤＶＲシステム５２６を含むこともできる。

クライアントデバイス１０６（ｎ）はまた、図示されているように、オーディオおよび／またはビデオの入力／出力５５４を含む。オーディオ／ビデオ入力／出力５５４は、オーディオレンダリングおよび／またはディスプレイシステム５５６に、ならびに／あるいはオーディオデータ、ビデオデータ、およびイメージデータを処理し、表示し、および／またはその他の形で提供するその他のデバイスにオーディオおよびビデオを提供するためなど、さまざまな目的で利用することができる。ビデオ信号およびオーディオ信号は、たとえばＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）リンク、Ｓ−ビデオリンク、コンポジットビデオリンク、コンポーネントビデオリンク、アナログオーディオ接続（ａｎａｌｏｇ ａｕｄｉｏ ｃｏｎｎｅｃｔｉｏｎ）、あるいはその他のそのような１つまたは複数の通信リンクを介して、クライアントデバイス１０６（ｎ）からテレビ５５８へ（あるいは、その他のタイプのディスプレイデバイスへ）通信することができる。

図６は、例示的な一実装形態におけるシステム６００を示しており、コンテンツプロバイダ１０２が、さらに詳しく示されている。システム６００は、番組コンテンツ、番組ガイドデータ、および広告コンテンツを複数の視聴者へ、そして複数の視聴システムへ配信することを容易にする。システム６００は、コンテンツプロバイダ１０２および複数のクライアントデバイス１０６（１）〜１０６（Ｎ）を含み、それらのそれぞれは、ＩＰベースのネットワーク１０８を介して通信するように構成されている。クライアントデバイス１０６（１）〜１０６（Ｎ）のそれぞれは、たとえば、コンテンツプロバイダ１０２からの１つまたは複数のコンテンツストリームを受信し、そして視聴システム１０４内の１つまたは複数の他のリモートクライアントデバイスへコンテンツストリームを配信するためのストリームの割り当て（たとえば、それぞれのクライアントデバイスごとに１つのコンテンツストリーム）を仲裁することができる。

通信ネットワーク１０８は、ワイドエリアネットワーク（たとえばインターネット）、イントラネット、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）ネットワークインフラストラクチャー、ポイントツーポイント接続インフラストラクチャー（ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｃｏｕｐｌｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）など、さまざまな方法で実装することができる。さらに通信ネットワーク１０８は、任意のタイプのネットワークトポロジーおよび任意のネットワーク通信プロトコルを使用して実装することができ、複数のネットワークの組合せとして表したり、あるいはその他の形で実装したりすることができる。デジタルネットワークは、コンテンツプロバイダ１０２とクライアントデバイス１０６（１）〜１０６（Ｎ）との間における通信を容易にするためのさまざまな有線リンクおよび／または無線リンク６０２（１）〜６０２（Ｎ）、ルータ、ゲートウェイなどを含むことができる。クライアントデバイス１０６（１）〜１０６（Ｎ）は、コンテンツプロバイダ６０２の（１つまたは複数の）コンテンツサーバ６０４から通信ネットワーク１０８を介してコンテンツ（たとえば、テレビ番組、番組ガイドデータ、広告コンテンツ、字幕データなど）を受信する。

システム６００はまた、特定のタイプのコンテンツを入手して提供することなどの機能を提供するためのさまざまなサーバを含むことができる。たとえば、図示されているシステム６００は、メディアサーバ６０６を含み、このメディアサーバ６０６は、コンテンツソース６０８から番組コンテンツを、番組ガイドソース６１０から番組ガイドデータを、そして広告ソース６１２から広告コンテンツを受信する。一実施形態においては、メディアサーバ６０６は、コンテンツソース６０８からオーディオおよびビデオの番組コンテンツを受信する取得サーバ（ａｃｑｕｉｓｉｔｉｏｎ ｓｅｒｖｅｒ）、番組ガイドソース６１０から番組ガイドデータを受信するＥＰＧサーバ、および／または広告ソース６１２から広告コンテンツを受信する広告管理サーバに相当する。

コンテンツソース６０８、番組ガイドソース６１０、および広告ソース６１２は、番組コンテンツ、番組ガイドデータ、および広告コンテンツをメディアサーバ６０６へ、および／またはその他のサーバへ配信することをコントロールする。番組コンテンツ、番組ガイドデータ、および広告コンテンツは、衛星伝送、無線伝送、ケーブル伝送、および／またはその他の任意の数の有線や無線の伝送メディアを介してなど、さまざまな伝送メディア６１４を介して配信される。この例においては、メディアサーバ６０６は、番組コンテンツ、番組ガイドデータ、および広告コンテンツをコンテンツプロバイダ１０２へ通信するシステム６００の独立したコンポーネントとして示されている。代替実装形態においては、メディアサーバ６０６は、コンテンツプロバイダ１０２のコンポーネントとして実装することができる。

図６のシステム６００におけるコンテンツプロバイダ１０２は、たとえば番組コンテンツ、番組ガイドデータ、および広告コンテンツを複数の受信契約者、たとえばクライアントデバイス１０６（１）〜１０６（Ｎ）に提供するテレビベースのコンテンツ配信システムにおけるヘッドエンドサービスを表している。コンテンツプロバイダ１０２は、映画、テレビ番組、コマーシャル、音楽、ならびにその他のオーディオコンテンツ、ビデオコンテンツ、および／またはイメージコンテンツなどの番組コンテンツおよび広告コンテンツをクライアントデバイス１０６（１）〜１０６（Ｎ）へ配信することをコントロールするために、衛星オペレータ、ネットワークテレビオペレータ（ｎｅｔｗｏｒｋ ｔｅｌｅｖｉｓｉｏｎ ｏｐｅｒａｔｏｒ）、ケーブルオペレータなどのさまざまな方法で実装することができる。

コンテンツプロバイダ１０２は、受信契約者マネージャー６１６、デバイスモニタ６１８、およびコンテンツサーバ６０４など、コンテンツの処理および配信を容易にするためのさまざまなコンポーネントを含む。受信契約者マネージャー６１６は、受信契約者データを管理し、デバイスモニタ６１８は、クライアントデバイス１０６（１）〜１０６（Ｎ）（たとえば、および受信契約者）をモニタし、そしてモニタしたクライアント状態情報を保持する。

コンテンツプロバイダ１０２のさまざまなマネージャー、サーバ、およびモニタ（一実施形態においてはメディアサーバ６０６を含む）は、コンテンツプロバイダ１０２の分散型の独立したコンポーネントとして図示され説明されているが、それらのマネージャー、サーバ、およびモニタのうちの任意の１つまたは複数をコンテンツプロバイダ１０２の１つの多機能コンポーネントとして統合して実装することができる。

クライアントデバイス１０６（１）〜１０６（Ｎ）は、前述のように、セットトップボックス、ＤＶＲ（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｒｅｃｏｒｄｅｒ）および再生システム、ＰＶＲ（ｐｅｒｓｏｎａｌ ｖｉｄｅｏ ｒｅｃｏｒｄｅｒ）、家電デバイス（ａｐｐｌｉａｎｃｅ ｄｅｖｉｃｅ）、ゲーミングシステム、およびテレビベースのエンターテイメント／インフォメーションシステム内に実装することができるその他の任意のタイプのクライアントデバイスとしてなど、任意の数の実施形態において実装することができる。代替実施形態においては、クライアントデバイス１０６（Ｎ）は、コンピューティングデバイスを介して実装される。さらに、クライアントデバイス１０６（１）〜１０６（Ｎ）のうちのいずれも、本明細書に記載されているようなマネージャー／リモートコンテンツアーキテクチャーの機能および実施形態を実装することができる。

結論
本発明について、構造的な特徴および／または方法論的な行為に特有の言葉で説明したが、添付の特許請求の範囲において定義される本発明は、それらの説明した特定の特徴や行為に必ずしも限定されるものではないということを理解されたい。むしろ、それらの特定の特徴および行為は、特許請求されている本発明を実施する例示的な形態として開示されている。

仮想チューナ管理技術を採用するように機能する例示的な一実装形態における環境を示す図である。 あるシステムの例示的な一実装形態を示す図であり、図１の視聴システムによってコンテンツプロバイダからのコンテンツを消費するために仮想チューナを使用することをさらに詳細に示している。 例示的な一実装形態における手順を示す流れ図であり、ここでは、複数の仮想チューナを採用することによって、コンテンツを消費するための視聴システム内のリソースがプールされ、それらの仮想チューナのスケジューリングは、スケジューリング優先順位（ｓｃｈｅｄｕｌｉｎｇ ｐｒｉｏｒｉｔｙ）に基づいて管理される。 例示的な一実装形態における手順を示す流れ図であり、ここでは、コンテンツプロバイダからのコンテンツの単一のストリームを消費するために視聴システム内で利用できるリソースを表す仮想チューナが、その視聴システム内の特定のクライアントデバイスによって使用されるようにロックされている。 図１および図２のクライアントデバイスの例示的な一実装形態をさらに詳しく示す図である。 例示的な一実装形態におけるシステムを示す図であり、図１および図２のコンテンツプロバイダが、さらに詳しく示されている。

Claims (8)

1. 複数のクライアントデバイスを有する視聴システムにおいてコンテンツ消費リソースを管理する方法であって、
   前記視聴システムが前記複数のクライアントデバイスの中の１つにおいて入力を受け取るステップであって、
   前記複数のクライアントデバイスはそれぞれが通信ネットワークを介してコンテンツプロバイダから受信した出力をレンダリングするように構成されており、
   前記視聴システムでは、複数の仮想チューナを用いてコンテンツを消費することが可能であり、
   前記複数のクライアントデバイスの中の１又は複数は、前記複数の仮想チューナによる前記コンテンツ消費をスケジュールするように構成されており、
   前記入力の指定により、前記複数の仮想チューナの中の少なくとも１つが前記複数のクライアントデバイスの中の対応するクライアントデバイスにロックされる、
   ステップと、
   前記視聴システムが、前記複数のクライアントデバイスの中の対応するクライアントデバイスを前記複数の仮想チューナの中の第１の部分集合にロックすることにより、前記対応するクライアントデバイスのみが、前記第１の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールすることが可能となり、同時に、前記対応するクライアントデバイスのみが、前記複数の仮想チューナの中の前記第１の部分集合とは異なる第２の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールすることが可能となるステップであって、前記複数のクライアントデバイスの中の残りのクライアントデバイスは、前記第２の部分集合を構成する仮想チューナを用いてコンテンツのストリームの消費をスケジュールすることのみが可能になる、ステップと、
   優先順位を用いて、前記視聴システムが、前記複数のクライアントデバイスの中の前記残りのクライアントデバイスのスケジューリング優先順位を決定し、前記複数の仮想チューナの中の前記第２の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールするステップと、
   を含むことを特徴とする方法。
2. 請求項１記載の方法において、
   前記視聴システムが、前記複数のクライアントデバイスによる使用に割り当てられたスケジューリング優先順位に従って、前記複数のクライアントデバイスによる前記複数の仮想チューナのスケジューリングを管理するステップを更に含んでおり、
   前記クライアントデバイスの中の少なくとも１つは、前記複数の仮想チューナの中の少なくとも２つを同時に用いてコンテンツを消費するように構成されていることを特徴とする方法。
3. 複数のクライアントデバイスを含む視聴システムであって、
   前記複数のクライアントデバイスは、通信ネットワークを介してコンテンツプロバイダから受信したコンテンツのストリームを消費するためにリソースをプールし、
   前記リソースは複数の仮想チューナによって分割されるのであるが、前記複数の仮想チューナとは、それぞれが、前記コンテンツのストリームを消費することができる手段であり、
   前記複数のクライアントデバイスは、それぞれが、前記複数の仮想チューナの中の１又は複数による前記コンテンツの消費をスケジュールするように構成されており、
   前記複数の仮想チューナの中の第１の部分集合を構成する仮想チューナが、前記複数のクライアントデバイスの中の対応するクライアントデバイスにロックされることにより、前記対応するクライアントデバイスのみが、前記第１の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールすることが可能になり、同時に、前記対応するクライアントデバイスのみが、前記複数の仮想チューナの中の前記第１の部分集合とは異なる第２の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールすることが可能になり、
   前記複数のクライアントデバイスの中の残りのクライアントデバイスは、前記第２の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールすることのみが可能になり、
   前記対応するクライアントデバイスへのユーザからの入力により、前記第１の部分集合を構成する仮想チューナが前記対応するクライアントデバイスにロックされることが可能であり、
   優先順位により、前記第２の部分集合を構成する仮想チューナを用いたコンテンツのストリームの消費をスケジュールするように、前記複数のクライアントデバイスの中の前記残りのクライアントデバイスのスケジューリング優先順位が決定されることを特徴とする視聴システム。
4. 請求項３記載の視聴システムにおいて、前記コンテンツプロバイダから前記複数のクライアントデバイスまで前記コンテンツをストリームするのに利用可能な回線容量は所定の限度を有することを特徴とする視聴システム。
5. 請求項３記載の視聴システムにおいて、前記コンテンツプロバイダはヘッドエンドであり、前記コンテンツの少なくとも一部はテレビ番組であることを特徴とする視聴システム。
6. 請求項３記載の視聴システムにおいて、この視聴システムはＩＰ−ＴＶ（インターネット・プロトコル・テレビジョン）システムであることを特徴とする視聴システム。
7. 請求項３記載の視聴システムにおいて、前記コンテンツ消費の前記スケジューリングは、前記複数のクライアントデバイスの中の１又は複数による前記コンテンツの保存のスケジューリングを含むことを特徴とする視聴システム。
8. 請求項３記載の視聴システムにおいて、前記対応する前記クライアントデバイスは、前記複数の仮想チューナの中の別の１つによるコンテンツの消費をスケジュールするように構成されていることを特徴とする視聴システム。

Images