JP4690457B2 - 帯域幅を消費するメディアイベントをスケジューリングするための方策 - Google Patents

Description

本主題事項は、スケジュール内の競合を解決することに関する。より具体的な実装において、本主題事項は、それぞれのクライアントデバイスによるメディアプログラムの受信および記録を管理するスケジュール内の競合を解決するための方策に関する。

従来のデジタルビデオレコーダ（ＤＶＲ）の機能はスケジューラを使用する。スケジューラは、メディアプログラムの記録を調整する機能を備える。スケジューラは、スケジュールを作成し、続いて当該スケジュールにおいて識別されたメディアプログラムを記録することによって、このタスクを実行する。より詳細には、スケジュールは、それぞれのメディアプログラムを識別するエントリを含む。エントリは、タイミングに関連する情報と、対応するメディアプログラムの記録を管理するその他のデータとを含む。

時として、ユーザは、１つまたは複数の前から存在しているエントリと競合するエントリをスケジュールに追加しようと試みる。例えば、クライアントデバイスが、ヘッドエンドのソースからメディア情報を受信するための従来の物理的なチューナを使用する場合を考える。このチューナは、（例えば、メディアプログラムを搬送する規定の周波数にチューニングすることによって、）任意の所与の時間に、１つのメディアプログラムだけをチューニングして、その１つのメディアプログラムを受信することができる。したがって、ユーザが、別のメディアプログラムの放映と時間的に重なるメディアプログラムを識別するエントリをスケジュールに追加する場合、チューナは、同時に２つのメディアプログラムにチューニングすることができず、それらの２つのプログラムを受信することができないために、競合が発生する。スケジューラは、ユーザに競合を通知すること、および競合しているメディアプログラムのうちのどちらを選択するかをユーザに要求することによって、この競合を解決することができる。

より複雑なクライアントデバイスは、複数の物理的なチューナを使用することができる。このことは、クライアントデバイスが同時に複数のメディアプログラムを受信することを可能にする。ある場合、これらのチューナは、同じ種類のユニットとして実装することができる。別の場合、これらのチューナは、２つ以上の異なる種類のユニットとして実装することができる。例えば、第１のクラスのチューナは、第１の種類のメディアプログラム（標準画質メディアプログラムなど）を受信するために使用することができる一方、第２のクラスのチューナは、第２の種類のメディアプログラム（高画質メディアプログラムなど）を受信するために使用することができる。これらの種類のクライアントデバイスに関する競合解決は、単一のチューナの場合よりも複雑であるが、単一のチューナの場合に使用される基本的なパラダイムと根本的にはあまりかわらない。すなわち、スケジューラは、任意の所与の時間に、スケジュールにおいて識別された全てのメディアプログラムを記録するのに十分な物理的なチューナをクライアントデバイスが提供することができるかどうかを判定する。任意の所与の時間に記録されるべきメディアプログラムの数が利用可能なチューナの数を超える場合、競合が発生する。スケジューラは、上述の方法、すなわち、ユーザに競合を通知すること、および判定された競合を取り除くためにスケジュール内の１つまたは複数のエントリを削除するようユーザに促すことによって、競合を解決するように試みることができる。

本発明の譲受人は、上述した従来のモデルから脱却するクライアントデバイスを開発している。この種のクライアントデバイスは、仮想的なチューナ機能を使用する。仮想的なチューナ機能は、ユニキャスト形式および／またはマルチキャスト形式の可変の数のデジタルメディアプログラムのストリームに「チューニングする」ことによって、可変の数のデジタルメディアプログラムを受信するために、可変の数の仮想的なチューナを割り当てる。例えば、クライアントデバイスには、メディア情報を受信するために合計６つの帯域幅の単位（unit）が割り当てられると仮定する。さらに、各標準画質メディアプログラムが１単位の帯域幅を消費し、各高画質メディアプログラムが２単位の帯域幅を消費すると仮定する。これは、総消費帯域幅が６単位を超えない限り、仮想的なチューナ機能が、標準画質メディアプログラムと高画質メディアプログラムとの任意の組合せを使用できることを意味する。例えば、考えられる１つのことは、クライアントデバイスが６つの標準画質メディアプログラムを受信するために、６つの仮想的なチューナを割り当てることである。考えられる別の１つは、クライアントデバイスが３つの対応する高画質メディアプログラムを受信するために、３つの仮想的なチューナを割り当てることである。考えられるさらに別の１つは、クライアントデバイスが２つの高画質メディアプログラムを受信するために、２つの仮想的なチューナを割り当て、２つの標準画質メディアプログラムを受信するために、２つの仮想的なチューナを割り当てることなどである。そのようなクライアントデバイスを実装するための例示的な技術が、本発明の譲受人に譲渡された「TUNERLESS MEDIA PRESENTATION UNIT AND METHODS OF USE」という名称の米国特許出願番号１１／０５７４７７号明細書に記載されている。この特許出願は、２００５年２月１４日に出願されたものであり、発明者は、Ｄａｖｉｄ Ｌ． ｄｅ Ｈｅｅｒらである。この特許出願は、参照することにより、その全体が本明細書に組み込まれる。

競合解決は、仮想的なチューナ機能を使用するクライアントデバイスにおいては、より複雑である。これは、利用可能な物理的なチューナの総数ではなく、利用可能な帯域幅の総量によってクライアントデバイスが制限されるためである。このことは、上述した従来のスケジューリングパラダイムと比較して、スケジューリングの作成および変更におけるより多くの自由度を可能にする。例えば、利用可能な帯域幅の一部を消費するどのイベントも、スケジュール内の競合を潜在的に発生させる可能性があり、スケジュールの１つの部分に対してなされた変更が、スケジュール全体に影響を及ぼし、複雑である可能性がある変更が、スケジュール内のその他のエントリに対してなされることを要求する可能性がある。

したがって、仮想的なチューナ機能を使用してメディアプログラムを受信するクライアントデバイスのための競合解決の方策を提供する一般的な必要性が、当技術分野には存在する。

例示的な一態様によれば、仮想的なチューナ機能を使用するクライアントデバイスに影響を与えるスケジュールの競合を解決するための方法が説明される。この方法は、複数のメディアプログラムを指定するスケジュールを確立すること；少なくとも１つの帯域幅イベント（bandwidth event）によって引き起こされた、スケジュール内の少なくとも１つの競合を識別すること；前述した少なくとも１つの競合に対する少なくとも１つのソリューションを列挙することであって、前述した少なくとも１つのソリューションは、（ａ）メディアプログラムを受信するためにクライアントデバイスが利用できる帯域幅の総量、および（ｂ）スケジュール内の前述した複数のメディアプログラムの各々によって消費される帯域幅の量を考慮に入れる、列挙すること；および、前述した少なくとも１つのソリューションに基づいて、前述した少なくとも１つの競合を解決することを備える。

別の例示的な一態様によれば、前述した少なくとも１つの競合を前述したように識別することは、競合が存在する可能性がある少なくとも１つの候補時間セグメントにスケジュールを分割すること；および、前述した少なくとも１つの候補時間セグメントから、実際の競合が存在する少なくとも１つの競合している時間セグメントを判定することを含む。前述した少なくとも１つのソリューションを前述したように列挙することは、前述した少なくとも１つの競合している時間セグメントにおいて、特定の時間セグメントごとに、競合を解決する少なくとも１つのソリューションを順番に列挙することを含む。

別の例示的な一態様によれば、仮想的なチューナ機能を使用するクライアントデバイス用にメディアプログラムの処理をスケジューリングするための方法が説明される。この方法は、クライアントデバイスによるメディアプログラムのセットの記録に影響を与える少なくとも１つの帯域幅イベントを識別すること；当該メディアプログラムのセットにおいて、少なくとも１つのメディアプログラムの異なる帯域幅のバージョン（version）を識別すること；メディアプログラムが記録される品質に関するユーザの嗜好を識別すること；および、識別された帯域幅のバーションとユーザの嗜好とに基づいて、前述した少なくとも１つのメディアプログラムの記録を管理するスケジュールを提供することを備え、このスケジュールを提供することは、当該スケジュール内の少なくとも１つの競合が存在すると判定されるときに、そのような競合を解決することを含む。

さらなる例示的な態様については、以下で説明する。

同様のコンポーネントおよび特徴を参照するために、開示および図全体を通じて同じ番号を使用する。１００番台の番号は、図１で初めて見られた特徴を示し、２００番台の番号は、図２で初めて見られた特徴を示し、３００番台の番号は、図３で初めて見られた特徴を示す。その他の番号も同様である。

以下の記載では、仮想的なチューナ機能を使用するクライアントデバイスに関するメディアプログラムの処理（例えば、記録）をスケジューリングするためのスケジューリング機能を説明する。消費される帯域幅の総量が利用可能な帯域幅の総量を超えないことを条件として、仮想的なチューナ機能は、仮想的な方法で、１つまたは複数のメディアプログラムにチューニングし、同時に任意の数のメディアプログラムを消費することができる。換言すると、仮想的なチューナ機能を使用するクライアントデバイスは、メディアプログラムを消費する多種多様な方法で、利用可能な帯域幅を「切り分ける（carve up）」ことができる。この能力は、スケジュールを構築する際のさらなる自由度をもたらすので、（決まった数の物理的なチューナを使用するクライアントデバイスに関して実行されるスケジューリングと比較して、）メディアプログラムをスケジューリングするタスクをより複雑にする。本明細書において説明するスケジューリング機能は、より複雑になったタスクに対して効果的に対処する。

用語に関して、用語「メディア情報」は、ユーザが消費することができる、電子的な形式で表される任意のデータを指す。メディア情報には、オーディオリソース（例えば、音楽、言葉で語られた対象など）、静止画リソース（例えば、デジタル写真など）、動画リソース（例えば、オーディオビジュアルテレビメディアプログラム、映画など）などのオーディオ情報および／またはビデオ情報を伝送する任意の情報を含めることができる。

用語「メディアプログラム」は、クライアントデバイスが消費することができる、任意の単位のメディア情報を表す。例えば、メディアプログラムは、テレビメディアプログラム、映画、音楽などを表し得る。

用語「クライアントデバイス」は、メディア情報を処理して表示するための任意のユニットを指す。例えば、クライアントデバイスとしては、セットトップボックスモジュール、デジタルビデオレコーダ（ＤＶＲ）、書き換え可能デジタルビデオディスク（ＤＶＤ−ＲＷ）デバイス、統合されたメディア処理機能を有するテレビデバイス、メディア処理機能を備えたコンピュータなど、またはそのようなデバイスの何らかの組合せを挙げることができる。

用語「スケジュール」は、記録されるべきメディアプログラムに関する主要な情報を指定するエントリの集合を指す。例えば、エントリは、メディアプログラムが始まるタイミングおよび終わるタイミングを指定する。エントリは、メディアプログラムを提供するソース（例えば、チャネル）と、メディアプログラムのその他の考えられ得る特徴とを指定することもできる。一般に、スケジュール内に示される情報は、本明細書においては「スケジュール情報」と呼ばれる。

用語「メディアプログラムガイド」は、複数の異なるソース（例えば、チャネル）によって配信されるメディアプログラムのタイミングを規定するマスタスケジュール情報を指す。一般に、用語「メディアプログラムガイド情報」は、メディアプログラムガイド内に示される情報を指す。メディアプログラムガイド情報には、定期的に更新される電子メディアプログラムガイド（ＥＰＧ：Electric media Program Guide）情報が含まれ得る。

本開示は次のセクションを含む。セクションＡでは、スケジュール機能を実行するための例示的システムを説明する。セクションＢでは、セクションＡのシステムの動作を説明するフローチャートおよび付随する例を示す。

Ａ．例示的システム（図１〜図４）
一般に、図を参照して説明する機能のいずれも、ソフトウェア、ファームウェア（例えば、固定されたロジック回路）、手動による処理、またはこれらの実装の組合せを用いて、実装することができる。一般に、本明細書において使用される用語「ロジック」、「モジュール」、または「機能」は、ソフトウェア、ファームウェア、またはソフトウェアおよびファームウェアの組合せを表す。例えば、ソフトウェアによる実装の場合、用語「ロジック」、「モジュール」、または「機能」は、１つまたは複数の処理デバイス（例えば、１つまたは複数のＣＰＵ）上で実行されるときに、指定されたタスクを実行するメディアプログラムコード（および／または宣言型の命令）を表す。メディアプログラムコードは、１つまたは複数のコンピュータ読み取り可能なメモリデバイスに記憶することができる。より一般的には、論理、モジュール、および機能を別々のユニットへ例示するように分割することは、そのようなソフトウェアおよび／またはハードウェアの実際の物理的なグループ化および割り当てを反映する可能性があるか、または単一のソフトウェアメディアプログラムおよび／またはハードウェアユニットによって実行される様々なタスクの概念的な割り当てに対応する可能性がある。例示された論理、モジュール、および機能は、（例えば、１つの処理デバイスによって実装されるように、）単一の場所に配置することもできるし、複数の場所に渡って分散させることもできる。

Ａ．１．例示的設計パラダイムの概要（図１）
図１は、ヘッドエンドのオペレーションセンタ（ＯＣ：Operation Center）１０２が複数のクライアントデバイス（１０４、１０６、．．．、１０８）にメディアプログラムを配信するシステム１００を示している。代表的なクライアントデバイス１０４は家庭１１０に置かれる。家庭１１０は、追加のクライアントデバイス（図示せず）を潜在的に有する可能性がある。例えば、家庭１１０は、家庭１１０の異なるそれぞれの部屋に置かれた異なるクライアントデバイスを有する可能性がある。以下の記載において、本発明の特徴を、家庭１１０に置かれた代表的なクライアントデバイス１０４に関連させて説明するが、特定された特徴は、その他のクライアントデバイスおよび家庭に対して同等の効力を有して当てはまる。

オペレーションセンタ１０２は、通信チャネル（「チャネル」）１１２を使用して、例示的家庭１１０にメディア情報を配信する。チャネル１１２は、家庭１１０にメディア情報をストリーミングするための規定された量の帯域幅１１４を含む。用語「帯域幅」は、所与の時間の間に、チャネル１１２を介して伝送することができる情報量を指す。ある場合には、オペレーションセンタ１０２は、帯域幅１１４に等しい一定のデータ速度で、チャネル１１２を介して情報を送信する。別の場合には、オペレーションセンタ１０２は、帯域幅１１４によって上限が決められた可変の速度で、チャネル１１２を介して情報を送信する。どの場合でも、チャネル１１２は、帯域幅１１４によって規定される「直径」を有する通信パイプと比喩的にみなすことができる。帯域幅１１４は、任意の所与の時間にこのパイプを通って流れることができる最大情報量を制御する。

帯域幅１１４は、家庭１１０に対するメディア情報の複数の識別されたストリームに対応し得る。このことは、単一のクライアントデバイス１０４が、そのクライアントデバイス１０４における同時表示のために、チャネル１１２を使用して、考えられ得るメディア情報の複数のストリームを抽出することを可能にする。さらに、このことは、ユーザが同時に複数のメディアプログラムを見ること、または記録することを可能にする。別の場合には、通信チャネル１１２は、同じチャネル１１２から「情報を得る」家庭１１０内の様々なクライアントデバイスによる受信のための複数のストリームを提供することができる。

帯域幅１１４は実質的に一定のままであるという単純な仮定が、本開示においてなされている。しかし、本明細書において説明するスケジューリングアルゴリズムは、帯域幅１１４が時間の経過と共に変化する場合にも適用することができる。例えば、スケジューリングアルゴリズムは、帯域幅１１４が一日のある時間では第１のレベルに設定され、一日のその他の時間では第２のレベルに設定される場合に適用することもできる。多くのその他の可変帯域幅の状況が存在し得る。これらの場合、スケジューリングアルゴリズムは、将来のプログラムを放映する際の利用可能な帯域幅を決定し、そのプログラムをスケジューリングするときにこの要因を考慮に入れる。

いかなるプログラムによって消費される帯域幅も、例えば、標準画質一定レベル、高画質一定レベルなど、実質的に一定のままであるというさらなる単純な仮定が、本開示においてなされている。しかし、本明細書において説明するスケジューリングアルゴリズムは、プログラムによって消費される帯域幅の量がそのプログラムの進行と共に変化する場合にも適用することができる。スケジューリングアルゴリズムは、これらの種類のプログラムをスケジューリングするときに、この追加の要因を考慮に入れることができる。

クライアントデバイス１０４は、チャネル１１２からメディアプログラムを受信するための仮想的なチューナ機能（図示せず）を使用する。例えば、オペレーションセンタ１０２が、インターネットグループ管理プロトコル（ＩＧＭＰ：Internet Group Management Protocol）などのマルチキャスト技術によってメディア情報を提供すると仮定する。ＩＧＭＰ技術において、メディア情報のソースは、配信ノード（distribution node）のツリーを使用して、受信側グループにメディア情報を配信する。この場合、仮想的なチューナ機能は、メディアプログラムのそのマルチキャストによる配信を利用することによって、メディアプログラムに「チューニングする」ことができ、仮想的なチューナ機能は、配信ノードのツリー内の適切な配信ノードを突き止めることによって、このタスクを実行することができる。代替として、オペレーションセンタ１０２が、ユニキャスト技術によってメディア情報を提供すると仮定する。ユニキャスト技術において、メディア情報のソースは、１対１形式で、対象とする受信側に対してメディア情報を配信する。この場合、仮想的なチューナ機能は、メディアプログラムを提供するソース（例えば、オペレーションセンタ１０２によって提供されるサーバマシンとすることができる）を識別することによって、メディアプログラムに「チューニングする」ことができる。さらに別の場合、仮想的なチューナ機能は、マルチキャスト技術およびユニキャスト技術の組合せ、または何らかのその他の１つもしくは複数の技術を使用することができる。

仮想的なチューナ機能は、異なるメディアプログラムを受信するために、その機能の異なるインスタンス（instance）を適用することができる。本明細書において使用する用語において、そのような別個のインスタンスは、別個の「仮想的なチューナ」を構成する。仮想的なチューナは、様々な点において従来の物理的なチューナとは異なる。例えば、仮想的なチューナは、（上述した方法で、）メディアプログラムを配信するソースを論理的に識別することによって、そのようなメディアプログラムに「チューニングする」。それに対して、物理的なチューナは、一般にメディアプログラムを変調する周波数を追尾することによって、メディアプログラムにチューニングする。さらに、仮想的なチューナ機能は、（仮想的なチューナによって消費される帯域幅の合計の量が、割り当てられた帯域幅１１４の総量を超えない限り、）任意の数の仮想的なチューナをサポートすることができる。それに対して、物理的なチューナは別個のハードウェアユニットを表すので、従来のクライアントデバイスは、ユニットを物理的に追加すること（または、取り除くこと）なしに変更することができない決まった数のそのようなユニットを提供する。仮想的なチューナ機能は、上述したまさにその理由により、「仮想的」であるとみなされる。

仮想的なチューナ機能の特徴のより詳細な説明が以下に続く。

通信チャネル１１２がＮ単位（N units）の帯域幅１１４を提供すると仮定する。さらに、メディアプログラムは、標準画質（ＳＤ：Standard Definition）記録品質および高画質（ＨＤ：High Definition）記録品質などの様々な記録品質で提供することができると仮定する。ＳＤストリームはＳ_ＳＤ単位の帯域幅を消費し、ＨＤストリームはＳ_ＨＤ単位の帯域幅を消費する。ここで、Ｓ_ＳＤ＜Ｓ_ＨＤである。考えられ得る別のフォーマットは、サムネイルバージョンのストリームを含むピクチャインピクチャ（ＰＩＰ：Picture-In-Picture）フォーマットであり、Ｓ_ＰＩＰ＜Ｓ_ＳＤである。クライアントデバイス１０４がＳＤストリームのみを受信する単純な場合において、チャネル１１２は、
Ｔ＝Ｎ／Ｓ_ＳＤ
であるＴ個の仮想的なチューナをサポートすることができる。
あるいは、別の表し方をすれば、
Ｋ（Ｓ_ＳＤ）≦Ｎ
となる。
この式は、Ｋ個のＳＤストリームが全体として消費する帯域幅が、合計Ｎの量の利用可能な帯域幅１１４以下でなければならないことを示している。

任意の量の帯域幅Ｓ_ｉを消費するストリームをクライアントデバイス１０４が受信することができるより一般的な場合においては、以下の式が全ての時点で成り立つ必要がある。

換言すると、受信ストリームによって消費される帯域幅の合計の量が、合計Ｎの量の利用可能な帯域幅１１４以下である必要がある。例えば、クライアントデバイス１０４が、各ＳＤストリームがＳ_ＳＤ単位の帯域幅を消費するＬ個のＳＤストリームと、各ＨＤストリームがＳ_ＨＤ単位の帯域幅を消費するＪ個のＨＤストリームとを受信する例示的な場合を考える。上記にて特定された制約は、
Ｌ×Ｓ_ＳＤ＋Ｊ×Ｓ_ＨＤ≦Ｎ
となる。

上述した式は概算を表している。実際の用途において、システム１００は、メディアプログラムの主要なストリーミング以外のその他のタスクを処理するために、システム１００の帯域幅１１４の一部を使用することができる。例えば、システム１００は、届かなかったパケットをクライアントデバイス１０４に提供するリトライ動作を処理するために、帯域幅の一部を使用することができる。以下で説明するように、利用可能な帯域幅上には、その他の可能な「消費（drain）」がある。例えば、チャネル１１２に接続されるエンティティ（例えば、パーソナルコンピュータ）は、例えば、インターネットから音楽をダウンロードすること、画像をウェブサイトにアップロードすること、電子メールを受信および／または送信することなどによって、帯域幅１１４の一部を消費する可能性がある。このように消費される帯域幅は、メディアプログラムを受信するために利用できる総帯域幅の量を減少させるので、プログラムのスケジューリングに影響を与える。

システム１００は、そのスケジューリング機能がクライアントデバイス１０４による消費のためにメディアプログラムの記録をスケジューリングするときに、上述した制約を使用するスケジューリング機能を提供する。ある場合には、スケジューリング機能は、オペレーションセンタ１０２において、ＯＣスケジューリング機能１１６として実装することができる。この実装において、ＯＣスケジューリング機能１１６は、オペレーションセンタ１０２の場所で、全てのクライアントデバイス（１０４、１０６、．．．、１０８）に関するスケジュールを保持する。別の場合には、スケジューリング機能は、代表的なクライアントデバイス１０４に配置されるクライアント側スケジュール処理機能１１８として実装することができる。（上述したように、この説明は代表的なクライアントデバイス１０４に焦点を置くが、その他のクライアントデバイス群がそれらのクライアントデバイス独自のそれぞれのクライアント側スケジュール処理機能を実装することができ、クライアントデバイス１０４に関して説明することは、その他のクライアントデバイス群に対して同等の効力を有して当てはまる。）さらに別の場合には、スケジューリング機能は、オペレーションセンタ１０２およびクライアントデバイス１０４において提供される機能の組合せにより分散させて実装することができる。説明を容易にするため、および１つの具体例を提供するために、この説明の残りの部分は、スケジューリング機能の中核が、ＯＣスケジューリング機能１１６により、オペレーションセンタ１０２において実行されると仮定する。

（代表的なクライアントデバイス１０４に関する）スケジューリング機能１１６の目的は、クライアントデバイス１０４がオペレーションセンタ１０２によって提供されたメディアプログラムを記録すべきタイミングを決定するクライアントデバイス１０４のためのスケジュールを保持することである。このように実行するために、クライアントデバイス１０４のユーザは、スケジュールを作成するために、スケジューリング命令をスケジューリング機能１１６に転送することができる。次いで、今度はスケジューリング機能１１６が、スケジュール内の識別されたメディアプログラムを記録する時間であることを当該スケジュールが示すときに、クライアントデバイス１０４に記録命令を送信することができる。次いで、クライアントデバイス１０４は、識別されたメディアプログラムをローカルストア１２０に記録する。

その他の実装において、スケジュールは、クライアントデバイス１０４における１つまたは複数のメディアプログラムの記録を必ずしも要求しない、クライアントデバイス１０４に対するこれらのメディアプログラムのストリーミングを決定するために、使用することができる。換言すると、スケジュールは、クライアントデバイス１０４に同時に複数のプログラムにチューニングするよう指示することができ、クライアントデバイス１０４は、例えばピクチャインピクチャ形式で、または何らかのその他の形式で、（必ずしもこれらのプログラムを記録することなく、）同時にこれらのプログラムを単に表示することができる。あるいは、クライアントデバイス１０４は、クライアントデバイス１０４が受信するいくつかのプログラムを、その他のプログラムを除いて記録することができる。さらに代替として、オペレーションセンタ１０２自体が、オペレーションセンタ１０２において、メディアプログラムを適切なメディアプログラムストア（図示せず）に記録することができ、この記録の後で、クライアントデバイス１０４における表示のために、これらのプログラムをクライアントデバイス１０４にストリーミングすることができる。しかし、最後に述べたシナリオは、スケジューリングの必要性を完全になくす。これは、オペレーションセンタ１０２においてプログラムを記録した後、ピクチャインピクチャのシナリオにおけるようにクライアントデバイス１０４が何らかの理由で複数の記録されたプログラムを同時に受信することを望まない限り、一般にクライアントデバイス１０４に複数のプログラムをストリーミングする必要がないためである。

いずれの場合でも、スケジューリング機能１１６は、スケジュール内の競合の存在を評価するために、上記にて特定された制約を適用する。より具体的には、スケジュールにおける任意の所与の時点で、上記にて特定された制約のうちの１つまたは複数が満たされないとき、競合が存在する。すなわち、これらの時点で、スケジュールは、利用可能な帯域幅を超える帯域幅を合計で消費するメディアプログラムを記録しようと試みている。

競合は、様々な種類のイベントが原因で生じる可能性がある。ある場合には、ユーザが、スケジュール内の１つまたは複数の前から存在しているメディアプログラムとの競合が生じる新しいメディアプログラムをスケジュールに追加する可能性がある。あるいは、ユーザがスケジュール内の既存のメディアプログラムを変更し、その結果、その既存のメディアプログラムがそのときにスケジュール内の１つまたは複数のその他のメディアプログラムと競合する可能性がある。例えば、利用可能な帯域幅１１４が、２つのＨＤメディアプログラムの受信に同時に対応すると仮定する。ユーザが３つのＨＤメディアプログラムを同時に記録しようと試みる場合、ユーザは、競合を引き起こしてしまっているであろう（これは、以下で説明するように、１つまたは複数のＨＤメディアプログラムの同等物（counterpart）を、１つまたは複数のＳＤメディアプログラムで置き換えることが可能でない場合、通信チャネル１１２が、要求される量のメディア情報を提供することが完全に不可能なためである）。別の場合には、競合は、メディアプログラムガイド情報の変更が原因で生じる可能性がある。例えば、スケジュールが、メディアプログラムが時間Ｘにおいて放映されるという想定に基づいているが、そのとき、そのスケジューリングされたメディアプログラムの放映を時間Ｙまで変更する新しいメディアガイド情報が到達すると仮定する。この新しい放映時間は、スケジュール内の１つまたは複数のその他のメディアプログラムと競合する可能性がある。別の場合には、競合は、割り当てられた帯域幅１１４を消費し、それにより、１つまたは複数の既にスケジューリングされたメディアプログラムを受信することを不可能にするシステム１００内の任意のその他のイベントが原因で生じる可能性がある。例えば、家庭１１０内のパーソナルコンピュータ（図示せず）が、クライアントデバイス１０４と通信チャネル１１２を共有すると仮定する。コンピュータは、インターネット（または、何らかのその他のエンティティ）と対話する際に、帯域幅を消費する可能性があり、それによって、クライアントデバイス１０４が消費できる利用可能な帯域幅１１４の総量を減少させる可能性がある。したがって、コンピュータが動作しているとき、コンピュータは、スケジュールに従ってクライアントデバイス１０４に同時にストリーミングされているプログラムとの競合を引き起こす可能性がある。上述した場合のいずれにおいても、スケジュールの任意のエントリに対する変更が生じるとき、その変更は、その他のエントリに影響を与える波及効果を有する可能性がある。これは、全てのエントリが帯域幅１１４の共有プール（common pool）を利用するので、この共有プールの減少が、スケジュール内の多くのエントリに対して、潜在的に影響を与える可能性があるためである。

後のセクションにおいて、スケジューリング機能１１６がスケジュール内の競合に対処する方法について詳細に説明する。導入として、スケジューリング機能１１６は、初めに帯域幅イベントを識別することができる。上述したように、このイベントは、帯域幅の利用の変更を表す任意の事象を規定するものである。このイベントは、帯域幅の過剰割り当て（over-allocation）を生じさせる可能性がある。次いで、スケジューリング機能１１６は、記録されるスケジューリングされるメディアプログラムの異なる帯域幅のバージョンと、こうしたメディアプログラムが記録されるべき方式（ＳＤ、ＨＤなど）に関するユーザの嗜好とを識別することができる。次いで、スケジューリング機能１１６は、帯域幅イベントと、メディアプログラムの利用可能な帯域幅のバージョンと、ユーザの嗜好とを考慮に入れるスケジュールを確立することができる。

スケジュールを形成する際、スケジューリング機能１１６は、生じる可能性があるあらゆる競合を解決するためのメカニズムを提供する。競合を解決するための１つの例示的メカニズムは、スケジュール内の過剰割り当てが行われる時間セグメントを識別すること、各時間セグメントに関してこのような競合に対するソリューションを列挙すること、および、ユーザインターフェース（ＵＩ）表示を介して、これらソリューションをユーザに示すことを含む。ＵＩ表示は、ユーザが、１つまたは複数の識別されたソリューションを選択することによって競合を解決することを可能にする。

Ａ．２．スケジューリング機能を含む例示的システム（図１）
図１のシステム１００のいくつかの特徴が、上述した導入となるセクションにおいて特定された。このセクションは、システム１００内の特徴のより包括的な概要を提供する。

まず第１に、オペレーションセンタ１０２は、メディア情報の１つまたは複数のソース１２４からそのようなメディア情報を供給するための取得機能１２２を含む。ソース１２４は、メディア情報を作成または提供する任意の種類のエンティティを表すことができる。そのようなエンティティには、ケーブルテレビプロバイダまたは衛星テレビプロバイダ、１つまたは複数のビデオオンデマンド（ＶＯＤ：Video-On-Demand）プロバイダ、１つまたは複数の情報出版社、１つまたは複数のライブラリソース、任意の種類のインターネット対応リポジトリ（repository）などがある。これらのソース１２４から受信されるメディア情報としては、ビデオ、オーディオ、静止画、および／またはその他のマルチメディアコンテンツを挙げることができる。メディアプログラムのソース１２４は、ＳＤ、ＨＤ、ＰＩＰ（サムネイルサイズ）などの多種多様な記録フォーマットで、メディアプログラム（または、そのメディアプログラムの何らかのサブセット）を提供することができる。このことは、好ましい記録フォーマットのメディアプログラムを視聴する、および好ましい記録フォーマットでメディアプログラムを記録するオプションをユーザに提供する。

取得機能１２２は、メディアプログラムガイドソース１２６からメディアプログラムガイド情報も受信する。メディアプログラムガイドソース１２６は、メディアプログラムガイド情報を作成または提供する任意の種類のエンティティを表すことができる。そのようなエンティティには、電子メディアプログラムガイド（ＥＰＧ）情報を編集および配信する商用サービスなどがある。一般に、メディアプログラムガイド情報は、１２日間などの特定の期間内に生じるメディアイベントを識別する。メディアプログラムガイド情報は、イベントを表すＩＤ情報、イベントが始まる時間および終わる時間、およびイベントを提供するソース（例えば、チャネル）などを提供することによって、イベントを識別することができる。

取得機能１２２自体が、リソース情報を取り出すタスクに従事する１つもしくは複数のサーバコンピュータ、またはその他の機能を含むことができる。

オペレーションセンタ１０２は、クライアントデバイス（１０４、１０６、．．．、１０８）へのメディア情報の配信の前にメディア情報を記憶するための情報コンテンツストア１２８を任意的に含む。情報コンテンツストア１２８は、１つまたは複数のデータベース、および関連するデータベース管理機能として実装することができる。

オペレーションセンタ１０２には、接続メカニズム１３２を介してメディア情報をクライアントデバイス（１０４、１０６、．．．、１０８）に提供するための情報配信機能１３０も含めることができる。様々なシステムが、様々な方法で、情報配信機能１３０を使用することができる。上述したように、システム１００は、取得機能１２２から（または、何らかのその他のソースから）受信されるときに、情報配信機能１３０を使用して、マルチキャスト形式で、ユニキャスト形式で、ユニキャスト形式およびマルチキャスト形式の組合せで、または何らかのその他の通信技術を使用して、メディア情報をクライアントデバイス１０４に送信することができる。

情報配信機能１３０は、クライアントデバイス（１０４、１０６、．．．、１０８）へのメディア情報の送信を容易にするサーバモジュール（図示せず）の集合として実装することができる。サーバモジュールは、当該サーバモジュールのいずれもがクライアントデバイス（１０４、１０６、．．．、１０８）のいずれかに同じサービスを提供するよう割り当てられ得るように、冗長なサービスを提供する場合がある。

どのような配信方策が使用されるにせよ、オペレーションセンタ１０２は、様々なパッケージングパラダイム（packaging paradigm）を使用して、メディア情報をクライアントデバイス（１０４、１０６、．．．、１０８）に配信することができる。ある場合には、オペレーションセンタ１０２は、様々なチャネルを用いて、ユーザに一連のメディアプログラムを提供することができる。この形態において、（チャネルが、物理的なチューナを使用する従来のアナログシステムの周波数に固有のコノテーション（connotation）を持たない可能性があるが、）オペレーションセンタ１０２は、従来のチャネル配信の方法で、決まったスケジュールに従ってメディアプログラムを提供することができる。別の場合には、オペレーションセンタ１０２は、決まった時間に、個々のメディアプログラムをユーザに提供することができる。

メディア情報自体は、ＭＰＥＧ−２規格、Ｍｉｃｒｏｓｏｆｔ社のＶＣ−１規格、ＩＳＯ／ＩＴＵのＨ．２６４規格などが含まれるがこれらに限定されない任意のフォーマットで表すことができる。コード化されたメディア情報は、リアルタイムトランスポートプロトコル（ＲＴＰ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）などが含まれるがこれらに限定されない任意のフォーマットを使用して、パケットにカプセル化することができる。

接続メカニズム１３２は、オペレーションセンタ１０２をクライアントデバイス（１０４、１０６、．．．、１０８）に接続する。この接続メカニズム１３２は、様々な技術的環境および商業的環境に適合するよう、様々な方法で実装することができる。例えば、接続メカニズム１３２には、ワイドエリアネットワーク（例えば、インターネット）、イントラネット、デジタル加入者線（ＤＳＬ）ネットワークインフラストラクチャ、ポイントツーポイント接続インフラストラクチャなどの任意の種類のネットワーク（または、ネットワークの組合せ）を含めることができる。接続メカニズム１３２は、任意の種類のプロトコルまたはプロトコルの組合せを使用することができるか、または含むことができる。情報を配信するために１つまたは複数のデジタルネットワークが使用される場合、接続メカニズム１３２には、様々な有線および／または無線リンク、ルータ、ゲートウェイ、ネームサーバなどを含めることができる。情報を配信するためにＤＳＬインフラストラクチャが使用される場合、接続メカニズム１３２は、電話接続インフラストラクチャのサービスの一部とＤＳＬ処理機能とを利用することができる。

接続メカニズム１３２は、オペレーションセンタ１０２とクライアントデバイス（１０４、１０６、．．．、１０８）の間の双方向通信を可能にする。例えば、この双方向通信は、クライアントデバイス１０４が（パス１３４を介して）オペレーションセンタ１０２にスケジュールの選択を送信することを可能にし、オペレーションセンタ１０２が（家庭１１０に対するパス１１２を介して）クライアントデバイス１０４に記録命令およびメディア情報を送信することを可能にする。オペレーションセンタ１０２をクライアントデバイス１０４に接続するチャネル１１２は、クライアントデバイス１０４をオペレーションセンタ１０２に接続するチャネル１３４と同じ通信メカニズムを使用して、実装することができる。代替として、これらのチャネルは、異なる通信メカニズムを使用して実装することもできる。

次に、システム１００のクライアント側の側面を参照すると、クライアントデバイス（１０４、１０６、．．．、１０８）自体は、様々な方法で実装することができる。任意の所与のクライアントデバイス（１０４、１０６、．．．、１０８）は、内蔵型のＩＰインターフェース／処理機能を備えたテレビセット、テレビセットに接続された関連するセットトップボックスを有する当該テレビセット、デジタルビデオレコーダ（ＤＶＲ）デバイス、書き換え可能デジタルビデオディスク（ＤＶＤ−ＲＷ）デバイス、ＡＶデコード機能を有するパーソナルコンピュータなど（、ならびにこれらのデバイスの任意の組合せ）を表し得る。あるいは、所与のクライアントデバイス（１０４、１０６、．．．、１０８）は、個人用携帯電話、携帯情報端末（ＰＤＡ）、タブレット型コンピュータデバイス、任意の種類のウェアラブルコンピュータ（例えば、腕時計型コンピュータデバイス）などの形態を取ることができる。

いかなる方法でクライアントデバイス（１０４、１０６、．．．、１０８）が実装されるにしても、それらのクライアントデバイスには、メディア表示モジュールに通信可能に接続されるメディア処理モジュールを含めることができる。例えば、クライアントデバイス１０４は、メディア表示モジュール１３８に接続されたメディア処理モジュール１３６を含み、クライアントデバイス１０６は、メディア表示モジュール１４２に接続されたメディア処理モジュール１４０を含み、クライアントデバイス１０８は、メディア表示モジュール１４６に接続されたメディア処理モジュール１４４を含む。メディア処理モジュール（１３６、１４０、．．．、１４４）には、メディア情報を処理するための機能を含めることができ、メディア表示モジュール（１３８、１４２、．．．、１４６）には、メディア処理モジュール（１３６、１４０、．．．、１４４）の出力を表示するための機能を含めることができる。メディア処理モジュール（１３６、１４０、．．．、１４４）は、（例えば、メディア処理モジュールがそれぞれのＩＰ対応テレビセットに統合される場合、）メディア表示モジュール（１３８、１４２、．．．、１４６）と統合することができ、またはメディア処理モジュール（１３６、１４０、．．．、１４４）は、（例えば、メディア処理モジュールが、テレビセットに接続されるそれぞれのセットトップボックスに収容される場合、）メディア表示モジュール（１３８、１４２、．．．、１４６）と分離することができる（しかし、それらのメディア表示モジュールには接続されている）。

上述したように、代表的なクライアントデバイス１０４は、メディア処理モジュール１３６を含み、そして、そのメディア処理モジュール１３６には、任意的なクライアント側スケジュール処理機能１１８を含めることができる。このスケジュール処理機能１１８が存在する場合、このスケジュール処理機能１１８は、オペレーションセンタ１０２に配置されたスケジューリング機能１１６と協働するために必要とされるあらゆるタスクを実行する。最後に、メディア処理デバイス１０４は、ローカルストア１２０も含む。ローカルストア１２０は、オペレーションセンタ１０２からの命令に応答してメディア情報のストリームを記憶するためなどに、使用することができる。

上述したように、システム１００は、スケジューリング機能を全面的にＯＣスケジューリング機能１１６に割り当てることができる。あるいは、システム１００は、スケジューリング機能を全面的にクライアント側スケジューリング処理機能１１８に割り当てることができる。あるいは、システム１００は、ＯＣスケジューリング機能１１６およびクライアント側スケジュール処理機能１１８の両方に、スケジューリング機能を分散させて割り当てることができる。上述したように、本開示は、ＯＣスケジューリング機能１１６が、スケジュールを作成および保持する役割、ならびにスケジュール内で生じる競合を解決する役割を課せられる実装に焦点を置いている。クライアント側スケジュール処理機能１１８は、ＯＣスケジューリング機能１１６と対話する役割、およびローカルストア１２０へのメディアプログラムの記憶を調整するようＯＣスケジューリング機能１１６によって要求されたときに、そのような調整を行う役割が課される。

（下記の）セクションＡ．４では、ＯＣスケジューリング機能１１６の１つの例示的実装に関する追加の情報を提供する。

Ａ．３．例示的なクライアント側の詳細（図２）
図２は、（図１と関連させて紹介した）代表的なクライアントデバイス１０４に関するさらなる詳細を提供する。図２に示されるクライアントデバイス１０４の構成は、多くの可能な実装のうちの１つの代表であるに過ぎない。

クライアントデバイス１０４は、メディア表示モジュール１３８と接続された、上記にて特定されたメディア処理モジュール１３６を含む。ある場合には、メディア処理モジュール１３６には、単一の統合されたデバイス（例えば、単一のＩＰ対応テレビセット）においてメディア表示モジュール１３８と組み合わされたＡＶ処理機能を含めることができる。別の場合には、メディア処理モジュール１３６には、メディア表示モジュール１３８（例えば、テレビ画面）に通信可能に接続する別個のセットトップボックスもしくはＤＶＲユニット（、またはその他の種類の別個のユニット）を含めることができる。

メディア処理モジュール１３６には、そのメディア処理モジュールに与えられたタスクを実行するためのいくつかのモジュールを含めることができる。まず第１に、メディア処理モジュール１３６は、ネットワークインターフェースモジュール２０２を含む。ネットワークインターフェースモジュール２０２は、任意の接続メカニズムを使用して、オペレーションセンタ１０２からメディア情報を受信するための任意の機能を表すことができる。例えば、ネットワークインターフェースモジュール２０２としては、イーサネット（登録商標）ＮＩＣ、ＤＳＬモデム、ケーブルモデム、無線ネットワークインターフェース、またはその他の種類のネットワークインターフェース機器を挙げることができる。

メディア処理モジュール１３６は、メモリ２０４も含む。メモリ２０４の一部には、メディア情報がデコードされるのに先立ってメディア情報を記憶するためのＦＩＦＯ型バッファを含めることができる。

メディア処理モジュール１３６は、受信メディア情報をビデオコンポーネントおよびオーディオコンポーネントにデコード（および復元）するためのオーディオビジュアル（ＡＶ）デコーダ２０６も含む。デコードは、（順序がくるって受信された場合に）パケットを整列すること、受信パケットのストリームからメディア情報を抽出すること、および、さらにメディア情報の再生を制御するタイミング情報を抽出することを含む。デコーダ２０６は、例えばユニキャスト技術および／もしくはマルチキャスト技術、または何らかのその他の技術を使用してメディア情報の１つまたは複数の識別されたストリームにチューニングするためのロジックを含めることによって、上述した仮想的なチューナ機能を実装することもできる。

メディア処理モジュール１３６は、メディア処理モジュール１３６の機能を実行する命令を実行するための１つまたは複数のプロセッサ２０８も含む。

メディア処理モジュール１３６には、１つまたは複数の入力デバイス（例えば、リモートコントローラ２１２、ＰＣ２１４、ジョイスティック（図示せず）、タッチスクリーン入力メカニズム（図示せず）など）を介して、消費者と対話するためのＩ／Ｏインターフェース２１０も含めることができる。

メディア処理モジュール１３６は、メディア表示モジュール２２０に適切なフォーマットで（例えば、適切な色空間で）メディア情報を提供するためのＡ／Ｖインターフェースモジュール２１６も含む。

メディア処理モジュールは、メディア情報および／またはその他の情報を記憶するための、上記にて特定されたローカルストア１２０も含む。（任意的なクライアント側スケジュール処理機能１１８が使用される場合、）一般に、クライアントデバイス１０４によって配置された記憶デバイス（例えば、メモリ２０４、ローカルストア１２０など）の任意の組合せを、クライアント側スケジュール処理機能１１８を実行する命令を記憶するために、使用することができる。

最後に、クライアントの処理モジュール１３６には、図には具体的に挙げられていない様々なその他のモジュール２１８を含めることができる。例えば、クライアントの処理モジュール１３６には、ＡＶデコーダ２０６からのメディア情報の映像コンポーネントをグラフィックス情報とフレームごとに合成するためのグラフィックス合成器を含めることができる。グラフィックス情報は、メディア情報の上に重ねられる様々なユーザインターフェース表示を含んでもよい。

メディア表示モジュール１３８は、ＣＲＴ型デバイス、ＬＣＤ型デバイスなどを含む、ＡＶ情報を表示するための任意の種類のデバイスを含んでもよい。いずれの場合も、メディア表示モジュール１３８は、表示面２２０を画定する。メディア処理モジュール１３６は、表示面２２０上に、１つまたは複数のユーザインターフェース表示２２２を示すことができる。例えば、ユーザがスケジュールを作成し、見直し、変更することを可能にするユーザインターフェース表示（図示せず）を提供することができる。このインターフェースは、（オペレーションセンタ１０２の）スケジューリング機能１１６によって、もしくはローカルでクライアント側スケジュール処理機能１１８によって（、またはそのような機能の組合せによって、）提供することができる。

Ａ．４．例示的スケジューリング機能の詳細（図３）
図３は、例示的なスケジューリング機能１１６の詳細を示している。図３に示されたコンポーネントは、単一のヘッドエンドの場所に一緒に配置することもできるし、複数の場所に渡って分散させることもできる。一般に、図３に示されたロジックは例示的であり、その他の機能が、本明細書において説明する基本的な設計原理を実装するための異なるロジックモジュールを適用することもできる。

まず第１に、スケジューリング機能１１６は、クライアントデバイス（１０４、１０６、．．．、１０８）および関連するユーザとの対話に用いるためのクライアントインターフェースモジュール３０２を含む。

スケジューリング機能１１６は、スケジュール３０６を作成し、見直し、変更するための機能を提供するスケジュール設定モジュール３０４も含む。スケジュール設定モジュール３０４は、これらのスケジュール３０６をスケジュールストア３０８に記憶する。スケジュール３０６は、それぞれのクライアントデバイス（１０４、１０６、．．．、１０８）における再生のために、メディア情報（テレビメディアプログラムなど）の記録を管理する。（代替として、クライアントデバイス群は、それらのクライアントデバイス独自のそれぞれのスケジュールを、それらクライアントデバイスのローカルストアに記憶することができ、これらのスケジュールの処理を、ヘッドエンドのスケジューリング機能１１６に任せることができる。）各スケジュールには、関連するメディア表示メディアプログラムを説明する１つまたは複数のエントリを含めることができる。例えば、エントリは、メディアプログラムの開始時間と、終了時間と、ソース（例えば、メディアプログラムが表示されるチャネル）と、メディアプログラムのその他の主要な特徴とを特定することによって、メディアプログラムを説明することができる。

スケジュールを作成する際、スケジューリング設定モジュール３０４は、（ガイドソース１２６からの）ガイドソース情報と、ユーザ嗜好情報３１０との両方にアクセスすることができる。メディアプログラムガイド情報は、特定の時間に、および特定のチャネルで、どのメディアプログラムが放映されているかを指定する。メディアプログラムガイド情報は、メディアプログラムの利用可能なフォーマット（ＳＤ、ＨＤなど）も指定することができる。ユーザ嗜好情報３１０は、例えばユーザによって選択されたメディアプログラムを記録するために使用されるべきフォーマットに関する、ユーザの記録の嗜好を示す。例えば、クライアントデバイス１０４のユーザは、そのユーザが（ＳＤフォーマットで記録されるべき）ニュースメディアプログラムを除く全てのメディアプログラムがＨＤフォーマットで記録されるべきであることを好むことを示すことができる。このユーザが新しいメディアプログラムをスケジュールに追加する場合、スケジュール設定モジュール３０４は、（所望の記録フォーマットが利用可能な場合、）その所望の記録フォーマットを有するメディアプログラムのバージョンを指定するスケジュール内のエントリを自動的に作成するように構成することができる。

上述したように、様々なイベントが記録の競合を引き起こす可能性がある。１つのそのようなイベントは、（１つまたは複数の時間セグメントに関して、全ての指定されたメディアプログラムを記録することが、利用可能な帯域幅を超える帯域幅を要するために、）１つまたは複数の前から存在しているメディアプログラムと偶然に競合する新しいメディアプログラムをユーザがスケジュールに追加するときに生じる。ユーザが前から存在しているメディアプログラムを変更し、その結果、その前から存在しているメディアプログラムがそのときにスケジュール内の１つまたは複数のその他のメディアプログラムと競合するとき、別のイベントが生じる。メディアプログラムガイド情報のプロバイダが、スケジューリングされたメディアプログラムのタイミングまたはフォーマットを変更し、その結果、そのメディアプログラムがそのときにスケジュール内の１つまたは複数のその他のメディアプログラムと競合するとき、別のイベントが生じる。さらなる追加の競合原因が存在し得る。

競合が生じた場合、スケジューリング機能１１６は、競合分析機能３１２を使用して、その競合を識別し、解決する。代表的な競合分析機能３１２は、その競合分析機能の役割の様々な側面を実行するためのいくつかのモジュールを含む。

第１に、競合識別モジュール３１４が、スケジュール内の競合を識別する。１つの技術において、このモジュール３１４は、スケジュールを別個の時間セグメントに分割することによって、このタスクを実行する。各時間セグメントは、その時間セグメントが時間的に前の時間セグメントとは異なる組合せのメディア消費イベントを表すという事実によって区別される。各時間セグメントは、競合が存在する新たな可能性も示す。例えば、新しいメディアプログラムの開始は、新しい時間セグメントの始まりの境界を定める。その時間セグメントの終わりは、任意のメディアプログラムの開始または終了といった任意の後続の帯域幅イベントに対応する可能性がある。これらの時間セグメントの一部は競合を含み、その他の時間セグメントは競合を含まない。したがって、セグメントを形成した後、競合識別モジュール３１４は、（例えば、要求される帯域幅の量が、利用可能な帯域幅１１４の量を超えるときに、）実際の競合が存在する時間セグメントを識別することができる。

ソリューション列挙モジュール３１６が、競合識別モジュール３１４によって識別された競合に対するソリューションを列挙する。図４ａは、競合を解決するホリゾンタルメソッド（horizontal method）を示し、図４ｂは、バーティカルメソッド（vertical method）を示している。これらの場合の両方において、初めにユーザは、これらの図において示された図示された期間中に発生するメディアプログラムＡ、Ｂ、およびＣを識別するスケジュールを作成すると仮定する。メディアプログラムＢがメディアプログラムＣと時間的に重なるときよりも前に、メディアプログラムＡがメディアプログラムＣと時間的に重なる連接点（juncture）においてさえ、この時点で、通信チャネル１１２が、合計３つのこれらのメディアプログラムを記録するのに十分な帯域幅を含むので、競合は存在しない。しかし、続いてユーザがメディアプログラムＤを記録するためのスケジュールエントリを作成すると仮定する。これにより、少なくとも１つの競合が生じる。帯域幅１１４が、（メディアプログラムＡ、Ｃ、およびＤが重なる連接点において、）メディアプログラムＡ、Ｃ、およびＤを受信するのに十分でない、かつ／または、（メディアプログラムＢ、Ｃ、およびＤが重なる連接点において、）メディアプログラムＢ、Ｃ、およびＤを受信するのに十分でないと仮定する。

図４ａに示されたホリゾンタルメソッドは、全ての競合に対する完全なソリューションを提供する。例えば、この問題に対する可能なソリューションは、（１）メディアプログラムＣを記録しないこと、または（２）メディアプログラムＡおよびＢを記録しないこと、または（３）メディアプログラムＤを記録しないことであろう。これらのソリューションのうちのいずれか１つを選択することは、スケジュールによって包含される期間全体（この場合は５ｐｍから１０ｐｍまでによって規定される期間）に対する全ての競合を解決する。

図４ｂに示されたバーティカルメソッドは、各時間セグメントに対するソリューションを列挙する。例えば、ソリューション列挙モジュール３１６が、セグメントＳ１およびＳ２が競合を含むと判定するものと仮定する。このことは、時間セグメントＳ１に関して、利用可能な帯域幅１１４が、メディアプログラムＡ、Ｃ、およびＤを記録するためには不十分であり、時間セグメントＳ２に関して、利用可能な帯域幅１１４が、メディアプログラムＢ、Ｃ、およびＤを記録するためには不十分であることを意味する。この場合、ソリューション列挙モジュール３１６は、時間セグメントＳ１および時間セグメントＳ２に対して異なるソリューションのセットを識別する。例えば、セグメントＳ１に関する問題に対するソリューションは、（１）メディアプログラムＡを記録しないこと、または（２）メディアプログラムＣを記録しないこと、または（３）メディアプログラムＤを記録しないことであろう。プログラムが同じ量の帯域幅を消費する場合、バーティカルな手法は、（複数のプログラムの組合せを除外することによって競合を解決するソリューションとは対照的に、）単一のプログラムを除外することによって競合を解決するソリューションを提供する。

ある状況では、ソリューション列挙モジュール３１６は、競合を解決する際、１つまたは複数のメディアプログラムが重要な役割を果たさないと判定する。すなわち、これらのメディアプログラムに関しては、それらのメディアプログラムが記録されるのか否かということが違いをもたらさない。一例において、あるメディアプログラムは、競合を解決するのに十分な帯域幅がこのメディアプログラムの除外によって開放されないので、重要ではないとみなされる。より一般的には、メディアプログラムは、そのメディアプログラムがいかなる一意なソリューションに対しても必要な貢献をもたらさないときに、重要ではないとみなされる。例えば、１つの一意なソリューションが、３つのＳＤプログラムＸ、Ｙ、およびＺ全てを取り消すことである場合を考える。この場合、これらのプログラムの３つ全てが「重要」であり、分析から除外されるべきでない。一方、ＸおよびＹが、組み合わされたときに競合を解決するのに十分であるＨＤプログラムである場合を考える。ＺがＳＤプログラムであるならば、（Ｘ＋Ｚも、Ｙ＋Ｚもソリューションではないと仮定すると、）Ｚはいずれの一意なソリューションに対しても貢献し得ない。１つまたは複数のメディアプログラムが重要でないと判定される場合、これらのメディアプログラムは、ユーザの判断を不必要に混乱させないように、分析から効果的に除外することができる。

最後に、図３に戻ると、競合分析機能３１２は競合解決モジュール３１８を含む。競合解決モジュール３１８は、ソリューション列挙モジュール３１６によって決定されたソリューションのうちの１つまたは複数を使用して、競合識別モジュール３１４によって評価された競合を解決する。例えば、ユーザが新しいメディアプログラムＤをスケジュールに追加しようと試みるときに競合が生じると仮定する。このとき、競合解決モジュール３１８は、競合と、その競合の可能なソリューションとをユーザに通知することができ、次いで、ユーザは、ソリューションのうちの１つまたは複数を手動で選択することが可能になる（以下で説明するように、ユーザが手動で競合を解決する要求に応じることができない場合、競合分析機能３１２は、様々なルールに基づいて、自動的に競合を解決するように試みることができる）。

例えば、ホリゾンタルメソッドを使用して、ソリューションを列挙する場合を考える。この場合、競合解決モジュール３１８は、ユーザに対して様々なソリューションを連続的に表示することができる（ここで、各ソリューションは、スケジュール内の全ての競合を取り除く）。例えば、初めに、競合解決モジュール３１８は、ユーザがメディアプログラムＣの記録を見送りたいと望むかどうかをユーザに求めることができる。ユーザがこのソリューションを拒否する場合、競合解決モジュール３１８は、ユーザがメディアプログラムＡおよびＢの両方の記録を見送りたいと望むかどうかをユーザに求めることができる。ユーザがこのソリューションを拒否する場合、競合解決モジュール３１８は、ユーザがメディアプログラムＤの記録を見送りたいと望むかどうかをユーザに求めることなどができる。

バーティカルメソッドは、競合を解決することに対して同様の手法を適用することができる。すなわち、様々なソリューションをユーザに続けて段階的に提供することによって、競合を解決する。しかし、この場合、競合解決モジュール３１８は、競合が存在するそれぞれのセグメントに順番に対処し、ユーザにそれぞれのセグメントに対するソリューションを選択するように求める。１つの例示的な場合では、第１のセグメントに関するユーザの選択（例えば、そのセグメントに関する特定のメディアプログラムの記録を見送ること）は、そのメディアプログラムをスケジュールから完全に除去することになる。このことは、後に発生するセグメントに関する競合状況を変更する影響を有するかもしれない（すなわち、この後のセグメントに関する競合も取り除くことによって、影響を有し得る）。代替として、競合しているセグメントに関するメディアプログラムを取り除くというユーザの指示が、そのセグメント内の当該メディアプログラムの競合している部分だけを取り除き、かつ後のセグメント内の当該メディアプログラムの残りの部分を記録することができるように、競合解決モジュール３１８を構成することができる。例えば、たとえユーザがフットボールの試合の最初の部分を見ることができないとしても、そのユーザがその試合の最後のクォータを見たいと望む場合、ユーザは、競合するメディアプログラムの一部を記録することにまだ関心があるので、ユーザは、このオプションを望む可能性がある。

様々なユーザインターフェース技術を使用して、ユーザによるソリューションの選択を容易にすることができる。１つの技術において、競合解決モジュール３１８は、（例えば、図４ａおよび図４ｂに示された表示のように、）重なり合うメディアプログラムを表示するグラフィカルなタイムバー表示と共に、可能なソリューションを特定するテキスト情報を表示する。その場合、ユーザは、所望の１つまたは複数のソリューションに対応するテキスト情報の上をクリックすることができる。別の場合には、競合解決モジュール３１８は、ユーザがグラフィカルなタイムバー表示自体と対話することを可能にすることができる。例えば、競合解決モジュール３１８は、利用可能な帯域幅１１４の制限内で記録することができるメディアプログラムのセットを表すタイムバー上の視覚的な印（色の付いた点やその他の記号など）を提供することができる。

例えば、初めにホリゾンタルソリューションの場合を考える。最初に、競合解決モジュール３１８は、図４ａに示されたタイムバーと共に、メディアプログラムＡ、メディアプログラムＢ、およびメディアプログラムＤに関するタイムバー上の赤い点を表示することができる（これは、ソリューションのうちの１つである）。これは、ユーザがこのソリューションを受け入れる場合に、メディアプログラムＡ、Ｂ、およびＤは記録されることになるが、メディアプログラムＣは記録されないことになることを意味する。メディアプログラムＣが記録されることをユーザが望む場合、競合解決モジュール３１８は、ユーザがメディアプログラムＣに関するタイムバー上をクリックすることを可能にすることができる。これは、赤い点がメディアプログラムＣ上に表示されるようにし、場合によっては、赤い点がメディアプログラムＡおよびＢから取り除かれるようにする。このソリューションが十分でない場合、ユーザは、メディアプログラムＡおよびＢに関するタイムバーのいずれかの上をクリックする可能性がある。このクリックは、赤い点がこれらのタイムバー上に再び表示されるようにするが、メディアプログラムＤに関するタイムバーからの赤い点の除去を引き起こす。このようにして、ユーザは、可能なソリューションをサイクルさせることができる。タイムバーのグラフィカルな表示、および関連する記録の印は、ユーザが可能な記録の順列を容易に理解することを可能にする。同じグラフィカルなパラダイムを使用して、バーティカルな技術に関するソリューションを見直して選択することができる。しかし、この場合、競合解決モジュール３１８は、それぞれの時間セグメントに対する様々なソリューションを次々にグラフィカルに順序付けることができる。

競合解決モジュール３１８がある１つの解決法を繰り返す前に可能な各ソリューションに到達することを確実にするために、上述したソリューションサイクルメカニズムにロジックを追加することができる。これは、競合解決モジュール３１８が２つのソリューション間を「行ったり来たりする（ping-pong）」ことを防止するための有用な特徴となり得る。例えば、ユーザが、色の付いた点をタイムバーＣに追加するために、メディアプログラムＣに関するタイムバー上をクリックする場合、タイムバーＤから色の付いた点を取り除き、タイムバーＡおよびＢに関する色の付いた点を残すことが適切である可能性がある。しかし、次にユーザがタイムバーＤ上をクリックするならば、色の付いた点をタイムバーＣから再び取り除くことは、（ユーザがこのソリューションが十分でないことを指示したばかりであるので、）有効ではない。それよりも、色の付いた点をタイムバーＡおよびＢから取り除き、色の付いた点をタイムバーＣおよびＤ上に残すことの方がより建設的である。このことにより、競合解決モジュール３１８が利用可能なオプション全てを順序付けることが確実になる。この特徴は、可能なソリューションのリストを保持することによって、および、当該リストにおける全てのオプションに到達されるまで、いかなるソリューションも繰り返されないことを確実にすることによって、実行することができる。

上述したＵＩエクスペリエンス（UI experience）を向上させるために、その他の特徴も使用することができる。例えば、競合解決モジュール３１８は、例えばソリューションの潜在的な望ましさに従ってそのソリューションを順序付けることによって、リスト中のソリューションを順序付けることができる。望ましさを評価するために、様々なルールを使用することができる。例えば、１つのルールは、複数のメディアプログラムの除去を伴うソリューションに到達する前に、１つのメディアプログラムのみの除去を伴う全てのソリューションを順序付けることである。例えば、バーティカルな手法において、プログラムＡ、Ｂ、およびＣが既にスケジューリングされている場合を考える。プログラムＡおよびＢは、１単位の帯域幅を消費し、プログラムＣは、２単位の帯域幅を消費する。２単位の帯域幅を消費するプログラムＤを記録する試みが次に存在すると仮定する。１つのソリューションは、プログラムＡおよびＢを取り除くことであり、別のソリューションは、プログラムＣを取り除くことである。上述したソリューション順序付けルールは、（１つのプログラムを取り除くことが、２つのプログラムを取り除くことよりも悪影響が少ないという仮定の下で、）プログラムＡおよびＢを両方取り除くことより前にプログラムＣを取り除くことを検討するようユーザに促す。別のルールは、ユーザが明示的に規定する選択基準を利用することであり、例えば、ユーザは、当該ユーザがニュースメディアプログラムよりもスポーツメディアプログラムを高く評価するよう指示することができ、したがって、２種類のメディアプログラム間で選択しなければならない場合、競合解決モジュール３１８は、ニュースメディアプログラムが取り除かれるソリューションを最初に表示する。これらは例示的なルールに過ぎず、その他の用途に対して異なるルールを採用してもよい。

別の特徴によれば、スケジュール内の１つまたは複数のメディアプログラムは、異なる記録品質を有する放映である場合がある。例えば、最初にユーザが、スポーツメディアプログラムをＨＤモードで記録したいと望むことを指示すると仮定する。しかし、後になってユーザがこのスポーツメディアプログラムと競合する別のメディアプログラムをスケジュールに追加すると仮定する。競合解決モジュール３１８は、ＳＤなどの異なるフォーマットの選択が競合を解決する場合には、このフォーマットによるスポーツメディアプログラムの利用可能性をユーザに通知するように構成することができる。代替的な記録フォーマットの利用可能性は、様々な方法でユーザに通知することができる。例えば、図４ａに示されるように、競合解決モジュール３１８は、競合を解決する可能性があるより低品質の記録が特定のメディアプログラムに対して利用可能であることを示す視覚的な印（例えば、吹き出しメッセージ）を、（このメディアプログラムに関連付けられた）タイムバーに追加することができる。ユーザは、印の上をクリックして、より低品質の記録を生じさせることができる。

別の特徴によれば、１つまたは複数のメディアプログラムが、（これらのメディアプログラムの除去が競合を解決する可能性が全くないために）ソリューションの一部を担わない場合、競合解決モジュール３１８は、これらのメディアプログラムがＵＩ表示上に現れないよう、これらのメディアプログラムを除外することができる。このことは、これらのメディアプログラムの除外がより整然としたＵＩ表示をもたらし、ＵＩ表示を潜在的により理解し易くし、ユーザの意志決定を容易にするので、有益である。

別の特徴によれば、プロバイダは、利用可能な帯域幅１１４をどのように仮想的なチューナに割り当てることができるかを制御する「人為的な」制約を追加することができる。すなわち、上述したように、消費される帯域幅の合計が利用可能な帯域幅１１４を超えないと仮定すると、仮想的なチューナ機能は通常、利用可能な帯域幅を任意の数のストリームに切り分けることができる。しかし、プロバイダは、２つのＨＤの仮想的なチューナおよび２つのＳＤの仮想的なチューナなど、最大数の仮想的なチューナのみが配置されることを指定したいと望む可能性がある。適用可能な場合、競合分析機能３１２は、その競合分析機能の競合解決技術において、この「人為的な」制約を考慮に入れることができる。

スケジューリング機能１１６のさらに別の特徴および変形形態があり得る。仮想的なチューニング環境におけるプログラムのスケジューリングの場合に適用可能なさらなるユーザインターフェース機能およびその他の特徴が、同時係属中の、本発明の譲受人に譲渡された、「Video Recording Conflict Management and User interface」という名称の米国特許出願第＿＿＿＿＿＿＿号明細書（代理人整理番号１３７６８．５２０／３０８４８２．０１）に記載されている。この特許出願における発明者は、Ａａｒｏｎ Ｊ． ＤｅＹｏｎｋｅｒ、Ｐｅｔｅｒ Ｊ． Ｐｏｔｒｅｂｉｃ、Ｔｈｏｍａｓ Ｈ． Ｔａｙｌｏｒ、およびＪｅｆｆｅｒｙ Ｃ． Ｆｏｎｇである。この特許出願は、参照することにより、その全体が本明細書に組み込まれる。

最後のトピックとして、ユーザのアクションに直接応じないアクションによって、その他の競合が引き起こされる可能性がある。例えば、メディアプログラムガイド情報は、定期的に更新され得る。新しいメディアプログラムガイド情報が、スケジューリングされたエントリの時間枠の変更や、そのスケジューリングされたエントリの記録品質の変更を示す場合、競合分析機能３１２は、これらの変更がもたらし得るあらゆる競合を解決しようと試みるよう動作し始めることができる。ある場合には、可能であれば、競合分析機能３１２は、次にユーザが当該ユーザのクライアントデバイス１０４と対話するときに、ユーザによる後の解決のために競合に対してフラグを設定することができる。これが不可能な場合、競合分析機能３１２は、競合を自動的に解決するように試みることができる。これは、（ソリューション群がそれらの評価された望ましさに基づいて順序付けられる）上記にて特定された例示的なルールに基づいて最善であると判定されたソリューションを自動的に選択することによって、実行することができる。例えば、１つのルールは、（たとえプログラムをＨＤで記録することがユーザの通常の嗜好であるとしても、）競合を解決するために、１つまたは複数のプログラムに関する記録品質を、ＨＤからＳＤに自動的に落とすことである。

Ｂ．例示的な動作方法（図５〜図１０）
残りの図は、フローチャートの動作を明確にする特定の例と関連させて、スケジューリング機能１１６の動作をフローチャートの形態で示す。説明を容易にするために、特定の動作が、特定の順序で実行される異なるステップを構成するものとして説明する。そのような実装は例示的なものであって、限定的なものではない。本明細書において説明する特定のステップは、一緒にまとめて実行することもできるし、単一の動作として実行することもできる。また、特定のステップは、本開示において説明する例で使用される順序と異なる順序で実行することもできる。これらのフローチャートで説明する多くの機能は前のセクションで既に説明したので、このセクションは、主にそれらの機能の見直しとして役立つことになるであろう。

Ｂ．１．スケジューリング機能の動作方法（図５および図６）
図５に示される手順５００は、図１および図３のスケジューリング機能１１６の例示的な動作方法の概要を提供する。

ステップ５０２において、スケジューリング機能１１６は、スケジュールの競合を生じる可能性がある１つまたは複数の帯域幅イベントを識別する。上述したように、第１の種類のイベントは、スケジュ―ルへの新しいメディアプログラムの追加か、または（例えば、既存のメディアイベントの記録品質を変更することによる）当該既存のメディアイベントの変更を表す。第２の種類のイベントは、競合を生じさせるメディアプログラムガイド情報の変更（または、ユーザのアクションによって直接的に引き起こされないその他のイベント）を表す。

ステップ５０４において、（実際に、ステップ５０２において評価された帯域幅イベントが、スケジュールに追加されている新しいメディアプログラムに対応する場合、）スケジューリング機能１１６は、スケジュールに追加されている新しいメディアプログラムの異なる帯域幅のバージョンを識別する。ステップ５０４には、スケジュール内の前から存在しているメディアプログラムの異なる帯域幅の種類を判定することも任意的に含めることができる。これは、新しいメディアプログラムの導入に対応するためにスケジュール内の１つまたは複数の前から存在しているメディアプログラムの記録品質を変更することが適切である場合、有用な情報である。例示的な記録品質には、ＳＤ、ＨＤ、ＰＩＰなどがある。

ステップ５０６において、スケジューリング機能１１６は、記録品質に関するユーザの嗜好を識別する。例えば、ユーザは、そのユーザが特定の種類の全てのメディアプログラムがＳＤフォーマット、ＨＤフォーマットなどで記録されることを好むことを指示することができる。

ステップ５０８において、スケジューリング機能１１６は、前のステップの結果を処理して、例えば、所望の記録品質を有する新しいメディアプログラムをスケジュールに追加することによって、スケジュールを更新する。また、ステップ５０８では、ステップ５０２において識別された帯域幅イベントが解決される必要がある競合を引き起こすかどうかが評価される。解決される必要がある競合を引き起こさない場合、スケジューリング機能１１６は、更新されたスケジュールをスケジュールストア３０８に記憶する。しかし、競合が生じる場合は、処理は図６の手順６００に進む。手順６００は、上述したバーティカルな技術を使用して競合を解決するための１つの例示的方法を提供する。概要として、この技術は、スケジュールをそのスケジュールの構成要素の時間セグメントに分割すること、および、続いてセグメントごとに１つの競合（または複数の競合）に対処することを含む。

より具体的には、ステップ６０２において、スケジューリング機能１１６は、競合を含むスケジュールを、そのスケジュールの構成要素の時間セグメントに分解することから始まる。各時間セグメントは、その時間セグメントの直前の時間セグメントとは異なる組合せの帯域幅イベントを表す。例えば、新しいメディアプログラムの開始は、新しい時間セグメントの開始を示す。任意のメディアプログラムの終了、または任意のメディアプログラムの開始が、その時間セグメントの終了を示す。このように生成された時間セグメントの一部は競合を含み、その他の時間セグメントは競合を含まない可能性がある。

ステップ６０４において、スケジューリング機能１１６は、いかなる競合も含まない時間セグメントを除外し、競合を含む時間セグメントのみを残す。こうした競合している時間セグメントにおいて、ユーザが記録したいと望むメディアプログラムの全てを記録するのに十分な帯域幅がないことを意味する帯域幅の過剰割り当てが存在する。

ステップ６０６において、スケジューリング機能１１６は、競合が生じる各時間セグメントに関して、競合に対する全てのソリューションを列挙することができる。すなわち、各時間セグメントに関して、スケジューリング機能１１６は、ソリューションのセットのいずれもがそのセグメントに関する競合を解決する当該ソリューションのセットを特定する。

ステップ６０８において、スケジューリング機能１１６は、（可能であれば）時間セグメントの複雑さを解消させて、ステップ６０６の結果を反映する。例えば、ステップ６０６において、１つまたは複数のメディアプログラムが、ソリューションに全く貢献することができないと判定されると仮定する。一例において、これは、これらメディアプログラムを除去しても、競合を解決するのに十分な帯域幅を開放しないためである。この場合、ステップ６０８では、重要でないメディアプログラムをスケジュールから除外することができ、時間セグメントを決定し直すことができる。このことは、１つまたは複数の前に規定された時間セグメントを合併する影響を有する場合がある。

ステップ６１０において、スケジューリング機能１１６は、上述したＵＩ技術を使用して競合を解決する。例えば、スケジューリング機能１１６は、可能なソリューション間をグラフィカルにサイクルさせて各時間セグメントに関する競合に対する所望のソリューションを順番にユーザが選択することを可能にすることができる。

Ｂ．２．例示的な例（図７〜図１０）
残りの図は、図５および図６において説明した手順の例を提供する。

初めに図７の導入的な場合を考える。この場合、総割り当て帯域幅１１４は３単位であると仮定する。ＳＤストリームは１単位の帯域幅を消費し、ＨＤストリームは２単位の帯域幅を消費するものと仮定する。（帯域幅に関するこれらの少ない単位の値は単に、本セクションにおける手引きの目的で役立つに過ぎず、すなわち、これらの値はそれら自体にとって、およびそれら自体が重要なわけではない。）さらに、ユーザがＳＤメディアプログラムＡ、ＨＤメディアプログラムＢ、そして最後に新しいＨＤメディアプログラムＣを記録したいものと仮定する。メディアプログラムＡ、Ｂ、およびＣが重なる部分において、合計で１＋２＋２＝５単位の帯域幅が必要とされる一方、利用可能な帯域幅は３単位しかないので、競合が存在する。

この場合、メディアプログラムＡがメディアプログラムＣと重なるが、メディアプログラムＡは、競合に対するいかなるソリューションの一部にもなっていない。これは、メディアプログラムＡを取り消しても、競合を解決するのに十分な帯域幅を開放しないためである。あるいは、より一般的に言うと、メディアプログラムＡを除去することは、いかなる一意なソリューションの必要な構成要素も形成しない（例えば、メディアプログラムＡおよびＢを取り消すことによって、競合を解決することが可能であるが、メディアプログラムＢを除去することだけで十分であり、メディアプログラムＡの除去を不必要にする）。したがって、競合に対するソリューションの列挙は、２つの可能なソリューション、すなわち、（１）（メディアプログラムＣが記録されるように）メディアプログラムＢを記録しないこと、または（２）新しいメディアプログラムＣを記録しないこと（したがって、現状を維持する）という結果になる。

第２のシナリオでは、再度同じ図７を参照して、メディアプログラムＡがＳＤメディアプログラムであり、メディアプログラムＢがＨＤメディアプログラムであり、しかし今度はメディアプログラムＣがＳＤメディアプログラムであると仮定する。

この場合、新しい要求がＳＤメディアプログラムであるので、メディアプログラムＡまたはメディアプログラムＢのいずれかを取り消すことにより、十分な帯域幅が開放され、メディアプログラムＣを記録することが可能になる。したがって、競合に対するソリューションの列挙は、３つの可能なソリューション、すなわち、（１）メディアプログラムＡを記録しないこと、または（２）メディアプログラムＢを記録しないこと、または（３）新しいメディアプログラムＣを記録しないこと（したがって、現状を維持する）という結果になる。

（図８ａ、図８ｂ、および図８ｃを含む）図８のシナリオは、より複雑な場合を示し、図６の手順６００に従って実行される分析を段階的に示す。この例において、再度、システムが３単位の帯域幅１１４を提供し、ＳＤメディアプログラムが１単位の帯域幅を消費し、ＨＤメディアプログラムが２単位の帯域幅を消費すると仮定する。この例において、メディアプログラムＡおよびＢはＨＤストリームであり、メディアプログラムＣはＳＤストリームであり、新しいメディアプログラムＤはＨＤストリームである。

ステップ６０２において、全ての時間セグメントが決定され、その決定により、図８ａに示される結果がもたらされる。各セグメントは新しい競合の可能性を表すが、各時間セグメントは、実際には競合を含まない可能性がある。

ステップ６０４において、帯域幅の過剰割り当てを示さない、したがって競合が生じないセグメントを除外することが実行される。これにより、図８ｂに示される結果がもたらされる。図示されるように、図８ａにおいて示された５つのセグメントのうち、２つのセグメント（セグメントＳ１およびＳ２）だけが、実際に評価された競合を含む。スケジューリング機能１１６は、（セクションＡ．１で定義された）上記にて特定された制約式を利用して、各時間セグメント内に過剰割り当てが存在するかどうかを判定することができる。

ステップ６０６において、各時間セグメントに関して可能なソリューションを列挙することによって、各時間セグメントに関する１つまたは複数のソリューションのセットを生成することが実行される。例えば、セグメントＳ１に関して、２つのソリューション、すなわち、（１）メディアプログラムＡを記録しないこと、または（２）メディアプログラムＤを記録しないことが存在する。時間セグメントＳ２に関して、やはりちょうど２つのソリューション、すなわち、（１）メディアプログラムＢを記録しないこと、または（２）メディアプログラムＤを記録しないことが存在する。この特定のシナリオにおいて、このメディアプログラムＣの除去によっては競合が解決されないので、メディアプログラムＣを記録するか否かは問題にならない。この理由で、図８ｃに示されるように、メディアプログラムＣは、ユ―ザに対して表示されるＵＩから効果的に除外することができる。

最後に、ステップ６１０では、上述した方法で競合を解決することが実行される。これは、上述した方法で各部分に関するソリューションを次々にグラフィカルに順序付けることを含んでもよい。

（図９ａ、図９ｂ、図９ｃ、および図９ｄを含む）図９は、別の例を示している。この場合でも、再度、システムが合計３単位の帯域幅１１４を提供し、ＳＤストリームが１単位の帯域幅を消費し、ＨＤストリームが２単位の帯域幅を消費するものと仮定する。ここで、メディアプログラムＡおよびＢはＳＤストリームであり、メディアプログラムＣはＨＤストリームであり、新しいメディアプログラムＤはＨＤストリームである。

図６に示された手順６００が再度適用される。ステップ６０２において、スケジューリング機能１１６は、新しい競合が生じる可能性がある全ての時間セグメントを決定する。これにより、図９ａに示される５つの時間セグメントがもたらされる。

ステップ６０４では、過剰割り当てを示さない（したがって競合を示さない）時間セグメントを除外することが実行される。これにより、３つの時間セグメント（Ｓ１、Ｓ２、およびＳ３）がスケジュール内に残る図９ｂに示される結果がもたらされる。

ステップ６０６では、競合が存在する各時間セグメントに関するソリューションを列挙することが実行される。この場合、メディアプログラムＡおよびＢを除去しても、評価された競合のいずれも取り除かれないので、メディアプログラムＡおよびＢは、いかなるソリューションにも貢献しない。したがって、メディアプログラムＡおよびＢは、図９ｃに示されるタイムバー表示を生成するために、ＵＩから除外することができる。３つの時間セグメントの各々に対する可能なソリューションは、（１）メディアプログラムＣを記録しないこと、または（２）メディアプログラムＤを記録しないことである。

ステップ６０８では、ステップ６０６の結果に応じて、ＵＩを再セグメント化することが実行される。すなわち、ステップ６０６において、この分析により、メディアプログラムＡおよびＢが除外された。このことは、図９ｄに示されるように、スケジューリング機能１１６が、３つの時間セグメントを単一の時間セグメントに合併することを可能にする。

ステップ６１０では、ＵＩを使用して上述した方法で競合を解決することが実行される。この場合、ユーザの意志決定を容易にする、図９ｄに示される単純化されたＵＩ表示を、ユーザに提供することができる。

（図１０ａおよび図１０ｂを含む）図１０は、最後の例を示している。この場合、システムが合計４単位の帯域幅１１４を提供し、ＳＤストリームが１単位の帯域幅を消費し、ＨＤストリームが２単位の帯域幅を消費するものと仮定する。メディアプログラムＡおよびＢはＨＤストリームであり、メディアプログラムＣおよびＤはＳＤストリームである。新しいメディアプログラムＸはＨＤストリームである。

図６に示された手順６００が再度適用される。ステップ６０２において、スケジューリング機能１１６は、競合が生じる可能性がある全ての時間セグメントを決定する。これにより、図１０ａに示される５つの時間セグメントがもたらされる。

ステップ６０４において、スケジューリング機能１１６は、いかなる競合も生じない時間セグメントを除外する。これにより、図１０ｂに示される結果がもたらされる。残りの時間セグメントＳ１およびＳ２は、帯域幅の過剰割り当てを含んでいる。

ステップ６０６において、スケジューリング機能１１６は、時間セグメントＳ１およびＳ２の各々に対する可能なソリューションを列挙する。時間セグメントＳ１において、ソリューションは、（１）メディアプログラムＡを記録しないこと、または（２）メディアプログラムＣおよびＤを記録しないこと、または（３）メディアプログラムＸを記録しないことを含む。同様のソリューションが、時間セグメントＳ２にも当てはまる（しかし、メディアプログラムＡではなく、メディアプログラムＢの除外を指示するソリューションが含まれる）。

ステップ６１０において、スケジューリング機能１１６は、上述したＵＩに基づく手法を使用して、評価された競合の解決をユーザに要請する。

結びに、いくつかの特徴が、これらの特徴が対処することができる例示的な問題を初めに識別することによって、本明細書において説明された。この説明の仕方は、他の者が本明細書で具体的に説明した方法でそれらの問題を認識した、かつ／または明確に述べたことを認めるものではない。関連する技術分野に存在するそれらの問題の認識および明確な表明は、本発明の一部として理解されるべきである。

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

仮想的なチューナ機能を使用するクライアントデバイスに関するスケジューリングを実行するための例示的システムを示す図である。 図１のシステムにおいて使用するための例示的クライアントデバイスを示す図である。 図１のシステムによる使用のための例示的スケジューリング機能を示す図である。 図３のスケジューリング機能が競合を解決するために使用することができる、「ホリゾンタルな」技術を示す図である。 図３のスケジューリング機能が競合を解決するために使用することができる、「バーティカルな」技術を示す図である。 図６と共に、図１のシステムの動作の例示的な方法を説明する手順を示す図である。 図５と共に、図１のシステムの動作の例示的な方法を説明する手順を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。 図１のシステムにおいて、スケジュール内で競合が発生する特定の例の解決に対する適用を示す図である。

Claims (16)

1. 仮想的なチューナ機能を使用するクライアントデバイスに影響を与えるスケジュールの競合を解決する方法であって、
   前記クライアントデバイスが所与の時間に通信チャネルを介して複数のメディアプログラムを受信および記録するためのスケジュールを確立するステップであって、前記スケジュールは、前記複数のメディアプログラムを、第１の帯域幅の量を必要とする第１のフォーマットバージョンで前記所与の時間に前記通信チャネルを介して前記クライアントデバイスに伝送することを指定する、当該確立するステップと、
   前記スケジュールの前記複数のメディアプログラムの各々を前記第１のフォーマットバージョンで伝送することによって消費される前記通信チャネルの帯域幅の量が、前記クライアントデバイスが前記通信チャネルを介して前記複数のメディアプログラムを受信することに利用できる帯域幅の総量を超えるか否かを考慮することによって、少なくとも１つの帯域幅イベントによって引き起こされる前記スケジュールの少なくとも１つの競合を識別するステップと、
   前記スケジュールにおける前記少なくとも１つの競合を識別したことに応答して、前記複数のメディアプログラムに利用できるフォーマットバージョンを示すメディアプログラムガイドソース情報を参照して、前記第１のフォーマットバージョンで伝送されるようにスケジュールされた前記複数のメディアプログラムのうち１つまたは複数のメディアプログラムが、前記第１の帯域幅の量よりも少ない第２の帯域幅の量を必要とする第２のフォーマットバージョンで利用できると判定するステップと、
   前記複数のメディアプログラムのうちの前記１つまたは複数のメディアプログラムを前記第１のフォーマットバージョンから前記第２のフォーマットバージョンに置き換えることによって前記少なくとも１つの競合が解決されるかどうかを判定するステップであって、前記１つまたは複数のメディアプログラムを前記第１のフォーマットバージョンから前記第２のフォーマットバージョンに置き換えることによって、前記複数のメディアプログラムの伝送によって消費される前記通信チャネルの帯域幅の量が、前記クライアントデバイスが前記通信チャネルを介して前記複数のメディアプログアムを受信することに利用できる帯域幅の総量以下に低減されるときに、前記少なくとも１つの競合が解決されると判定するステップと、
   前記スケジュールにおける前記少なくとも１つの競合を解決するための少なくとも１つのソリューションを前記クライアントデバイスのユーザに提供するステップであって、前記１つまたは複数のメディアプログラムを前記第１のフォーマットバージョンから前記第２のフォーマットバージョンに置き換えることによって前記少なくとも１つの競合が解決されると判断されたとき、前記少なくとも１つのソリューションは、前記１つまたは複数のメディアプログラムを前記第２のフォーマットバージョンに置き換えることにより前記スケジュールを変更することを含む、当該提供するステップと、
   前記少なくとも１つのソリューションによって前記スケジュールの前記少なくとも１つの競合を解決するステップと
   を備えることを特徴とする方法。
2. 前記少なくとも１つの帯域幅イベントは、前記クライアントデバイスの前記ユーザによる新しいメディアプログラムの選択を含むことを特徴とする請求項１に記載の方法。
3. 前記少なくとも１つの帯域幅イベントは、前記クライアントデバイスの前記スケジュールに影響を与えるメディアプログラムガイド情報の変更を含むことを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つの競合を識別するステップは、
   前記スケジュールを、競合が存在する可能性がある複数の候補時間セグメントに分割するステップと、
   前記複数の候補時間セグメントのうち、実際に競合が存在する少なくとも１つの競合している時間セグメントを識別するステップと
   を含むことを特徴とする請求項１に記載の方法。
5. 前記少なくとも１つのソリューションを提供するステップは、
   前記少なくとも１つの競合している時間セグメントごとに、各時間セグメントにおいて存在している前記競合を解決するためのソリューションを順番に提供すること
   を含むことを特徴とする請求項４に記載の方法。
6. 前記少なくとも１つのソリューションを提供するステップは、
   前記複数のメディアプログラムの各々を表すタイムバーを含み、前記少なくとも１つの競合を解決するための前記少なくとも１つのソリューションを視覚的に示すユーザインターフェース表示を、前記クライアントデバイスの前記ユーザに提供することを含み、
   前記少なくとも１つのソリューションにより前記スケジュールの前記少なくとも１つの競合を解決するステップは、前記ユーザによって前記ユーザインターフェース表示内の前記１つまたは複数のメディアプログラムに対応する前記タイムバーが選択されたことに応答して、前記少なくとも１つのソリューションにより前記スケジュールの前記少なくとも１つの競合を解決することを含むことを特徴とする請求項１に記載の方法。
7. 前記ユーザインターフェース表示は、所定の優先順位に従った順序付けを表すように前記少なくとも１つのソリューションを視覚的に示すことを特徴とする請求項６に記載の方法。
8. 前記１つまたは複数のメディアプログラムを前記第１のフォーマットバージョンから前記第２のフォーマットバージョンに置き換えることによって、前記複数のメディアプログラムの伝送によって消費される前記通信チャネルの帯域幅の量が、前記クライアントデバイスが前記通信チャネルを介して前記複数のメディアプログアムを受信することに利用できる帯域幅の総量以下に低減されるとき、前記１つまたは複数のメディアプログラムを前記第２のフォーマットバージョンに自動的に置き換えることにより、前記スケジュールの前記少なくとも１つの競合を解決するステップをさらに備えることを特徴とする請求項１に記載の方法。
9. 前記メディアプログラムガイドソース情報に基づいて前記複数のメディアプログラムに利用できるフォーマットバージョンを識別するステップと、
   メディアプログラムの記録品質に関するユーザ嗜好情報を識別するステップと
   をさらに備え、
   前記スケジュールを確立するステップは、識別された前記複数のメディアプログラムに利用できるフォーマットバージョンと前記ユーザ嗜好情報とに基づいて、前記クライアントデバイスの前記スケジュールを確立することを含むことを特徴とする請求項８に記載の方法。
10. 前記１つまたは複数のメディアプログラムを前記第２のフォーマットバージョンに自動的に置き換えることにより、前記スケジュールの前記少なくとも１つの競合を解決するステップは、前記ユーザ嗜好情報において前記１つまたは複数のメディアプログラムを前記第１のフォーマットバージョンで記録するように指定されているかどうかに関わらず、前記１つまたは複数のメディアプログラムを前記第２のフォーマットバージョンに自動的に置き換えることにより、前記スケジュールの前記少なくとも１つの競合を解決することを含むことを特徴とする請求項９に記載の方法。
11. 前記少なくとも１つの競合を識別するステップは、前記複数のメディアプログラムのうち前記少なくとも１つの競合を発生させている、少なくとも２つのメディアプログラムを識別することを含み、
    前記少なくとも１つのソリューションは、前記少なくとも２つのメディアプログラムのうちの少なくとも一方を前記スケジュールから除去することにより、前記少なくとも１つの競合を解決することを含むことを特徴とする請求項１に記載の方法。
12. 仮想的なチューナ機能を使用するクライアントデバイスに影響を与えるスケジュールの競合を解決するスケジューリング機能を提供するためのシステムであって、
    クライアントデバイスが複数のメディアプログラムを受信および記録するためのスケジュールを確立し、該システムのメモリ内に記憶するように構成されたスケジュール設定モジュールであって、前記スケジュールは、前記複数のメディアプログラムを、前記クライアントデバイスに第１の帯域幅の量を必要とする高画質のフォーマットバージョンで所与の時間に所与の通信チャネルを介して伝送することを指定する、当該スケジュール設定モジュールと、
    前記スケジュールに従って前記複数のメディアプログラムを前記高画質のフォーマットバージョンで伝送することによって消費される前記通信チャネルの帯域幅の量が、前記クライアントデバイスが前記通信チャネルを介して前記複数のメディアプログラムを受信することに利用できる帯域幅の総量を超えるか否かを考慮することによって、前記スケジュールの少なくとも１つの競合を識別するように構成された競合識別モジュールと、
    前記少なくとも１つの競合を解決するための少なくとも１つのソリューションを前記複数のメディアプログラムとともに表示した、ユーザインターフェース表示により前記クライアントデバイスのユーザに提供するように構成されたソリューション列挙モジュールと、
    前記少なくとも１つのソリューションにより前記少なくとも１つの競合を解決するように構成された競合解決モジュールと
    を備え、
    前記ソリューション列挙モジュールは、メディアプログラムガイドソース情報に基づいて、前記高画質のフォーマットバージョンで伝送されるようにスケジュールされた前記複数のメディアプログラムのうち１つまたは複数のメディアプログラムが、前記第１の帯域幅の量よりも少ない第２の帯域幅の量を必要とする標準画質のフォーマットバージョンで利用できると判定されたとき、前記１つまたは複数のメディアプログラムを前記高画質のフォーマットバージョンから前記標準画質のフォーマットバージョンに置き換えることによって前記少なくとも１つの競合が解決されるかどうかを判定するように構成され、
    前記ソリューション列挙モジュールは、前記１つまたは複数のメディアプログラムを前記高画質のフォーマットバージョンから前記標準画質のフォーマットバージョンに置き換えることによって、前記複数のメディアプログラムの伝送によって消費される前記通信チャネルの帯域幅の量が、前記クライアントデバイスが前記通信チャネルを介して前記複数のメディアプログアムを受信することに利用できる帯域幅の総量以下に低減されるとき、前記１つまたは複数のメディアプログラムを前記高画質のフォーマットバージョンから前記標準画質のフォーマットバージョンに置き換えることにより前記スケジュールを変更することを、前記少なくとも１つのソリューションとして提供するように構成されることを特徴とするシステム。
13. 前記競合識別モジュールは、
    前記スケジュールを、競合が存在する可能性がある複数の候補時間セグメントに分割すること、および、
    前記複数の候補時間セグメントのうち、実際に競合が存在する少なくとも１つの競合している時間セグメントを識別すること
    によって、前記少なくとも１つの競合を識別するように構成されることを特徴とする請求項１２に記載のシステム。
14. 前記ソリューション列挙モジュールは、前記少なくとも１つの競合している時間セグメントごとに、各時間セグメントに存在している前記競合を解決するためのソリューションを順番に提供するように構成されることを特徴とする請求項１３に記載のシステム。
15. 前記ソリューション列挙モジュールは、前記スケジュールの前記複数のメディアプログラムのうち前記少なくとも１つの競合を発生させていないメディアプログラムを前記ユーザインターフェース表示から除外するように構成され、
    前記競合識別モジュールは、前記ソリューション列挙モジュールによる前記メディアプログラムの除外に応じて、前記少なくとも１つの競合している時間セグメントを決定し直すように構成されることを特徴とする請求項１３に記載のシステム。
16. 請求項１に記載の方法を実行するための命令を記録したことを特徴とする、１つまたは複数のマシン読み取り可能な記憶媒体。

Images