JP4907918B2 - 電子番組ガイドラインアップを構成し、編集する方法およびシステム - Google Patents

Description

本発明は、ユーザがテレビジョン番組などの番組を視聴し、記録することを可能にするエンターテイメントシステムとの関連で使用されるものなどのラインアップを構成する方法およびシステムに関する。

ラインアップは、放送されるサービスおよびそのサービスに同調できるようにするある量の同調情報（ｔｕｎｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）のリストとみなすことができる。サービスは、サービスプロバイダによって配布される放送コンテンツの製作者を指す。サービスの例として、２，３例を挙げると、たとえば、ＨＢＯ、ＣＮＮ、およびＢＢＣ Ｏｎｅが挙げられる。サービスに、音声のみのサービスまたはデータサービスも含めることができる。サービスと共に、スケジューリング情報（番組名、提示時間、および個々の番組に関連する他のデータを示す）を関連付けて、電子番組ガイド（ｅｌｅｃｔｒｏｎｉｃ ｐｒｏｇｒａｍ ｇｕｉｄｅ、ＥＰＧ）または単に「ガイド」を提供することができ、このＥＰＧは、通常、行および列を有するグリッドの形態でユーザに視覚的に提示される。名詞として使用される時に、「ガイド」は、番組およびそのスケジューリングされた放送に関する情報を格納するプラットフォームオブジェクトを指す。プラットフォームオブジェクトは、複数のプロセスまたはアプリケーションが使用できるコードの断片の抽象概念である。形容詞としての「ガイド」は、ガイドがそれから作成されるデータを記述するのに使用される。ＥＰＧおよびそれに関連する視覚的提示（すなわちグリッド）またはユーザインターフェース（ＵＩ）を使用して、ユーザまたは視聴者は、望みの番組がいつ放送されるかを確かめることができ、現在の特定の番組を見たり、たとえばパーソナルビデオレコーダ（ＰＶＲ）、ディジタルビデオレコーダ（ＤＶＲ）などに将来に記録するために特定の番組を選択したりするなど、適切な番組選択および視聴の判断を行うことができる。

しかし、ガイドの精度が損なわれたときに、ユーザの体験も損なわれる。例として、次を検討されたい。

一部のマーケットで、ガイド情報またはデータの完全なセットが入手可能でない場合がある。たとえば、必要なまたは正確な同調情報（すなわち、適切な信号を受信し、処理できるようにする情報）が、放送区域内の個々のサービスについて入手可能でない場合がある。具体的に言うと、世界の一部の国で、データプロバイダから受信される同調情報が、米国ほど正確でない。たとえば、地域から地域へ移動する時に、同一のサービスが異なる周波数で放送されていることに気付く場合がある。それにもかかわらず、同調情報を提供するデータプロバイダが、これらの異なる区域でのサービスに関する正確な同調情報を知らないか、提供できない場合がある。したがって、不正確な情報が、最終的にユーザに提示されることになる可能性があり、これが、ユーザの体験の質を低下させるだけではなく、データプロバイダが満足なサービスをカスタマに提供する能力にも悪影響する。

存在し得るもう１つの問題は、たとえば、ケーブルプロバイダまたはヘッドエンドの間の、非標準送信周波数の使用から生じる。具体的に言うと、いくつかのマーケットで、ヘッドエンドからヘッドエンドに移動する時に、送信周波数が、標準化されておらず、実際に変化することが観察された。ヘッドエンドは、ケーブル産業で、単一のラインアップに関する信号を放送することによって１つの地理的区域にサービスを提供する、ある物理的位置にある機器を指す。しかし、ディジタルヘッドエンドは、複数のラインアップをサポートすることができる。

さらに、チューニングスペース（ｔｕｎｉｎｇ ｓｐａｃｅ）という概念を検討されたい。チューニングスペースは、特定の放送媒体およびそれに同調する手段を指す。各チューニングスペースは、ガイドデータプロバイダがサポートする場合もしない場合もある異なった同調を必要とする場合がある。ガイドデータプロバイダが、適切なチューニングスペース情報を有しない場合に、ユーザは、関連する媒体で放送される番組に同調することができないか、前もって録画をスケジューリングすることができない。

これらの特定の状況ならびに他の状況のすべてが、視聴することに関連する製品およびサービスをユーザに提供することを望むものだけでなく、そのような製品およびサービスを消費することを望むものにも課題を提供する。

本発明の目的は、ユーザの地理的位置にかかわりなく、ユーザに正確なＥＰＧラインナップ構成およびＰＶＲスケジューリングを提供することである。

さまざまな実施形態が、ユーザの地理的位置にかかわりなく、ユーザに正確なＥＰＧラインナップ構成およびＰＶＲスケジューリングを提供する。説明される実施形態によれば、ガイドは、複数の使用可能なソース、特に帯域内スキャニングおよびＥＰＧメタデータダウンロードから、データを取り出し集める。次に、サービスを識別し、論理的に同等のグループに分類する。サービスをグループ化したならば、一実施形態によれば、その結果が、どのサービスを同調に使用するかを選択し、所与のチャンネル／プリセットでのスケジューリングにどのサービスを使用するかを選択することを対象とする分析を行う。さらに、さまざまな実施形態は、自動化された形で、プリセット／チャンネルにサービスを割り当てると同時に、ラインアップの編集、同調情報の変更、およびプリセット／チャンネルのパーソナライゼーションを行うユーザインターフェースおよび方法を提供することができる。

概要
さまざまな実施形態が、ユーザの地理的位置にかかわりなく、ユーザに正確なＥＰＧラインナップ構成およびＰＶＲスケジューリングを提供する。説明される実施形態によれば、ガイドは、複数の使用可能なデータソース、特に帯域内スキャニングおよびＥＰＧメタデータダウンロードから、データを取り出し集める。メタデータは、限定するものではないが、データに関するデータと考えることができる。この文書の文脈では、メタデータを、特定の放送に同調するのに使用できる同調情報、ならびに、番組タイトルおよびスケジューリングされた番組放送時間を記述するスケジューリング情報と、俳優、プロットなどの特定の番組に関する情報を含むと考えることができる。

識別されたならば、サービスを、論理的に同等のグループに分類する。サービスをグループ化したならば、一実施形態によれば、その結果が、どのサービスを同調に使用するかを選択し、所与のチャンネル／プリセットでのスケジューリングにどのサービスを使用するかを選択することを対象とする分析を行う。この文書の文脈で、チャンネルおよびプリセットという用語は、交換可能に使用される。「チャンネル」および「プリセット」という用語は、ユーザが、ガイド内のサービスに同調またはジャンプするために、通常はリモートコントロールを使用して入力する、サービスに関連する番号を指す。さらに、チャンネル／プリセットは、通常、サービスが見つかるグリッド内の行のとなりに表示される番号である。さらに、さまざまな実施形態は、自動化された形で、プリセット／チャンネルにサービスを割り当てると同時に、ラインアップの編集、同調情報の変更、およびプリセット／チャンネルのパーソナライゼーションを行うユーザインターフェースおよび方法を提供することができる。

例示的なシステム
図１に、前述の実施形態に従って使用できる、ローカルデバイスまたはクライアントデバイス１００の形態の例示的なシステムを示す。ローカルデバイス１００に、テレビジョン番組などの番組を見るか別の方法で消費するためにユーザまたは消費者が使用できる、すべての適切なタイプのデバイスを含めることができる。ローカルデバイスの１つの特定のタイプの例を、この文書の末尾で提供するが、請求される主題の趣旨および範囲から逸脱することなく、そのようなデバイスを変更することができることを理解されたい。

図示の例では、複数の異なるデータソースが設けられ、これらのデータソースが、サービスに関連するデータを提供することができる。この文書において、サービスを、主サービスおよび副サービスとして指定することができる。主サービスは、同調情報を含むサービスである。主サービスは、スケジューリング情報を関連付けられることもできるが、そうである必要はない。図示し、説明する実施形態では、ＥＰＧグリッド（その例を図３に示し、下で詳細に説明する）の可視行のそれぞれは、１つの主サービスと関連付けられるものであるが、この主サービスは、下でより明らかとなろう。副サービスは、スケジューリング情報および番組データ情報を含むサービスである。副サービスに、必ずしもすべてのまたは正確な同調情報は含まれない。図示し、説明する実施形態では、ＥＰＧグリッドの各行が、０個以上の関連する副サービスを有することができる。

図示し、説明する実施形態では、データソースには、限定するものではないが、ローカルデバイスの外部のガイドデータサービス１０２、周波数スキャナ１０４、ユーザインターフェース１０６、事前配布ファイル１０８、ユーザ供給ファイル（ｕｓｅｒ−ｐｒｏｖｉｄｅｄ ｆｉｌｅ）１１０、および／またはユーザ共有可能ファイル１１２が含まれる。これらのエンティティのそれぞれが、ラインアップおよびその後に、表示されるグリッドをそれから構成できるデータを供給することができる。

ガイドデータサービス１０２は、ガイドデータまたは「メタデータ」が通常そこから受信または別の方法でダウンロードされる従来のエンティティと考えることができる。周波数スキャナ１０４は、ローカルデバイスに常駐するが、放送された信号をスキャンし、帯域内データからどのサービスが利用可能であるかを確かめる。

ユーザインターフェース１０６は、下で明らかになるように、ラインアップを編集するのに使用されるソースデータをそれによりユーザが提供することができる機構を提供する。事前配布ファイル１０８は、ローカルデバイスに事前にインストールしておくことができるファイルを指す。ユーザ供給ファイル１１０は、ユーザが、インターネットなどの外部ソースからダウンロードしておくことができるファイルを指す。ユーザ共有可能ファイル１１２は、ユーザが他のユーザと共有できるファイルを指す。たとえば、ローカルデバイス１００のユーザが、プリセットとサービスの間の彼自身の特定のマッピングを提供した可能性がある。ユーザ共有可能ファイルを使用することによって、このユーザは、他のユーザによる消費および使用のために彼のファイルをアップロードすることができる。

これらのソースのそれぞれまたはいずれかによって供給されるデータは、最終的に、処理され、ＥＰＧデータベース１１４に格納される。ここで、ガイドデータサービス１０２および周波数スキャナ１０４から受け取られたデータだけを使用してラインアップが構成される状況を検討されたい。次の議論では、図１と図２の流れ図の両方を参照するが、図２には、一実施形態による方法が示されている。この方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはこれらの組合せに関連して実施することができる。図示の実施形態では、この方法が、ローカルデバイスに常駐するソフトウェアで実施される。上で注記したように、これから説明する方法を実施することができるローカルデバイスの一例を、図４に示し、下で詳細に説明する。

図２において、ステップ２００で、複数の異なるソースからサービス関連データを受信する。これは、図１では、ＥＰＧデータベース１１４に流れ込むデータによって表されている。図１に示された例では、複数のソースが、多数の異なるソースを構成する。しかし、現在の例において、ガイドデータサービス１０２および周波数スキャナ１０４だけが使用されると仮定する。

ステップ２０２で、サービス関連データを取り出し、事前定義の判断基準に従ってサービスを分類する。少なくとも１つの実施形態で、ステップ２０２のサービスの分類が、論理的に同等のサービスを一緒にグループ化するように設計されている。論理的に同等のサービスには、番組情報、スケジューリング情報、および同調情報など、同一の放送サービスを記述するメタデータが含まれる。複数のソースが、一般に、サービスの同一のセットに関するメタデータを提供し、そのようなものとして、このステップは、同一のサービスを記述する複数のソースからのこの情報を同等と見なす。

任意の適切な事前定義の判断基準を使用することができる。一例で、事前定義の判断基準には、各サービスのコールサインが含まれる。サービス名、仮想チャンネル番号（たとえば、サービスがグリッド内で見つかる標準チャンネル。たとえば、英国では、ＢＢＣ１がチャンネル１で見つかり、ユーザは、ＢＢＣ１が放送される周波数に無関係に、リモートコントロールの「１」を押してそれを視聴する。米国では、仮想チャンネル番号が、同調周波数に対応する。したがって、所与のマーケットで、ＦＯＸ系列局に、仮想チャンネル番号１３を関連付けることができ、ＡＢＣ系列局に、チャンネル７を関連付けることができ、ＥＳＰＮ系列局に、チャンネル３５を関連付けることができる。異なるマーケットで、ＦＯＸ系列局に、仮想チャンネル番号２を関連付けることができ、ＡＢＣ系列局に、チャンネル３を関連付けることができ、ＥＳＰＮ系列局に、チャンネル４０を関連付けることができる。米国のアナログ信号に関して、その関連付けられた番号は、仮想チャンネル番号および同調情報であり、これらは、グローバル一意識別子（ＧＵＩＤ）など、事前定義の判断基準の一部としてを使用することができる。このステップは、図１では、「Ａ」と指定された大括弧の中で表されており、ここで、複数のサービスが、まず取り出され（大括弧の上部で）、次に事前定義の判断基準に従って分類される（大括弧の下部で）。この特定の例では、それぞれ「ＢＢＣ１」、「ＩＴＶ」、および「ＨＢＯ」と示された３つの別々のサービスが示されているが、通常は、より多くのサービスが処理される。

上で説明したようにサービスが分類されたならば、ステップ２０４で、サービスを主サービスおよび副サービスに分離する。主サービスが、同調情報を含むサービスであり、副サービスが、スケジューリング情報および番組データ情報を含むが必ずしも同調情報を含まないサービスであることを思い出されたい。図１の図では、このステップが、大括弧「Ｂ」の中に図式で表されている。具体的に言うと、この例では、ＢＢＣ１と称するものとして識別されるサービスの第１セットが処理されることが示されている。すなわち、第１のＢＢＣ１サービスが、「ＢＢＣ１ Ｗａｌｅｓ」と識別され、第２のＢＢＣ１サービスが、「ＢＢＣ１ Ｌｏｎｄｏｎ」と識別されている。「（ＧＬＩＤ）」指定は、関連するデータが周波数スキャナ１０４から来たことを示す。現実には、２つの異なるＢＢＣ１サービスがある理由は、ユーザの受信範囲内でＢＢＣ１を送信している２つの送信塔があるという事実が原因であるのかもしれない。

この例では、分離された副サービスが、図１のガイドデータサービス１０２からのファイルダウンロード（たとえば、「（Ｆｉｌｅ ｄ／１）」からの出所（ｏｒｉｇｉｎ）を有することに留意されたい。この例では、これらの副サービスが、スケジューリング情報を有するが、同調情報を有する場合とそうでない場合がある。一般的な実践で、周波数スキャナからの同調データが、ファイルダウンロードデータより正確であるが、番組データおよびスケジューリングデータは、アナログ放送についてより不正確であることがわかっている。したがって、周波数スキャナデータが存在する場合、通常、この周波数スキャナデータが、まず主サービスを識別するのに使用される。

プロセスのこの時点で、本発明の方法が行ったことを検討されたい。効果的に、本方法は、可能なサービスのリストを可能な信号（同調要求によって表される）のリストから分離し、さらに、同調情報をスケジューリング情報および番組情報から分離している。可能なサービスのリストと可能な信号のリストを分離することによって、事前に配布された情報より特定のスキャニングソースを優先する、事前に配布されたデータよりガイドデータサービスを優先する、ガイドデータサービスより特定のスキャニングソースを優先する、またはスキャンされたデータよりユーザ供給データを優先するといったことを含む強力なヒューリスティックまたはアルゴリズムの適用を可能にすることができる。さらに、この環境で適用されるヒューリスティックは、たとえば２つの送信塔がある場合に、所与のユーザまたはローカルデバイスに対して最良の信号を有する塔について選択を行えるなど、ルールベースの（ｒｕｌｅ−ｂａｓｅｄ）信号選択を可能にすることができる。

説明を続けると、サービスを主サービスおよび副サービスに分離したならば、ステップ２０６で、個々の主サービスおよび副サービスのペアリングまたは関連付けの確立を試みる。これを行う１つの方法が、最終的にユーザに対して表示されるグリッド内の同一の行に現れることを望む主サービスおよび副サービスのペアリングまたは関連付けを試みることである。図示し、説明している実施形態で、これらの関連付けは、主サービスおよび副サービスのそれぞれに関連するある値の比較に基づいて構築される。本実施例では、この値に、主サービスおよび副サービスのそれぞれに関連するプリセット番号またはチャンネル番号が含まれる。

具体的に言うと、図１の例では、２つのＢＢＣ１主サービス（すなわち、ＷａｌｅｓおよびＬｏｎｄｏｎ）があり、このそれぞれが、「１」の割り当てられたプリセットを有する。これは、主サービスのそれぞれが、ユーザに表示されるグリッドの第１行に置かれることを求めていることを意味する。この場合に、本発明の方法では、主サービスと副サービスの間の最良の関連付けを行うことを試みる。これを行うために、ステップ２０６で、主サービスのプリセットと等しいプリセットを有する副サービスを見つけることを試みる。この特定の例では、ＢＢＣ１ Ｗａｌｅｓが、副サービスＢＢＣ１ Ｎｏｒｔｈと同様に、「１」のプリセットを有する。したがって、この主サービスおよび副サービスが、それらのプリセットまたはチャンネル「１」との関連でペアリングされる。

この場合に、本方法は、主サービスに関連付けられる次の副サービス、この例ではＢＢＣ１ Ｌｏｎｄｏｎを探す。この例では、２つの副サービスがあり、１つはプリセット「１２」を有するＢＢＣ１ Ｓｏｕｔｈと示されたもの、１つはプリセット「１３」を有するＢＢＣ１ Ｅａｓｔと示されたものであることに留意されたい。したがって、本方法は、次の同等の主サービス（この場合ではＢＢＣ１ Ｌｏｎｄｏｎ）と次の２つの副サービスの両方を関連付ける。別の主ＢＢＣ１サービスがある場合には、ＢＢＣ１ Ｌｏｎｄｏｎは、対応する副サービスの１つだけとペアリングされる。

この例で、すべての副サービスが、１つの主サービスとマッチングされることに留意されたい。すなわち、本方法の目標は、各副サービスを対応する主サービスに関連付けることを試みることである。副サービスが、対応する主サービスを有しない場合、その副サービスは、孤児になり（ｏｒｐｈａｎｅｄ）、したがって、デフォルトラインアップの最終的構成で使用されない。

主サービスと副サービスの間でプリセット間の一致がない場合には、ステップ２０６は、主サービスとペアリングできる副サービスを突き止めることを試みる。たとえば、「１」のプリセットを有する副サービスがないと仮定する。この場合に、本方法は、対応するグループから次の関連する副サービスを探す。これが、主サービスＢＢＣ１ Ｗａｌｅｓと副サービスＢＢＣ１ Ｓｏｕｔｈ（「１２」のプリセットを有する）の間の関連付けをもたらす可能性がある。これによって、次に、ＢＢＣ１ Ｌｏｎｄｏｎという主サービスが、副サービスＢＢＣ１ Ｅａｓｔ（「１３」のプリセットを有する）だけと関連付けられるようになる。

主サービスが、１つまたは複数の副サービスに関連付けられたならば、ステップ２０８で、各関連付けにプリセット番号またはチャンネル番号を割り当てる。主サービスの間でプリセット間に衝突がない場合に、この処理は、単に、主サービスの所望のプリセットを、グリッドに表示される実際のプリセットにマッピングする。図１の例で、ＢＢＣ１ Ｌｏｎｄｏｎという主サービスが「１２」のプリセットを有すると仮定する。この場合に、主サービスＢＢＣ１ Ｗａｌｅｓは、単に、「１」のプリセットを割り当てられ、ＢＢＣ１ Ｌｏｎｄｏｎは、「１２」のプリセットが割り当てられる。しかし、この例では、個々の主サービスのそれぞれが、「１」のプリセットを示し、したがって、衝突が生じている。

２つのセットの主／副サービス関連付けの間の衝突の場合に、第１の主／副サービス関連付けのセットに、プリセットが割り当てられ、後続の衝突する主／副関連付けのセットは、すべての残りの衝突しない関連付けが特定のプリセットを割り当てられるまでとっておかれる。したがって、本実施例では、主サービスＢＢＣ１ ＷａｌｅｓとＢＢＣ１ Ｌｏｎｄｏｎが、同一のプリセットを示すことによって衝突しているので、ＢＢＣ１ Ｗａｌｅｓを含む関連付けに、「１」のプリセットが割り当てられ、ＢＢＣ１ ＬｏｎｄｏｎとＢＢＣ１ Ｓｏｕｔｈ／ＢＢＣ１ Ｅａｓｔの関連付けは、当面はとっておかれる。次に、本方法は、図１のステップＡで表されるすべての残りのサービスグループの衝突しないすべての関連付けのセットすなわち主サービスが同一のプリセットを有しない関連付けのセットに対するプリセットの割り当てを継続する。

衝突しない関連付けのセットのすべてにプリセットが割り当てられたならば、衝突する関連付けのセットに、グリッドの末尾から始めてプリセットを割り当てる。図１の例では、これが、ＢＢＣ１ Ｌｏｎｄｏｎの主サービスからプリセット「Ｎ」に延びる矢印によって示されている。

この手法では、ユーザの期待を満たす表示可能グリッドを提供することを試みる。すなわち、多くのマーケットで、最初のＮ個のサービスについて、どのプリセットまたはチャンネルがどの主サービスにマッピングされるかに関する期待がある。たとえば、英国では、最初の５つのサービスのマッピングに関する消費者の期待がある。他のマーケットでは、そのような期待が異なる可能性がある。とっておく動作が衝突の場合に実行されない場合に、この消費者の期待が満たされない。具体的に言うと、とって置くことが実行されない場合に、衝突する主サービスは、次の順のプリセットを割り当てられ、したがって、消費者が期待するプリセット／サービスの関連付けが置き換えられる可能性がある。

少なくともいくつかの実施形態で、ステップ２０８で行われる処理の一部として手動ステップを実行することができる。すなわち、主／副サービス関連付けのセットに、消費者の期待を守るように指示される形でプリセットまたはチャンネルを手動で割り当てることができる。たとえば、いくつかの情況で、データソース（たとえば、データソース１０２、１０４）から受け取ったデータが、関連付けられたプリセット情報を有しない場合がある。この情況で、手動ステップによって、消費者の期待を満たす関連付けのセットおよびプリセットの割り当てを提供することを試みることができる。

この処理のこの時点で、ラインアップが構成され、ステップ２１０で、グリッドをユーザに表示することができる。

例示的なグリッドを、図３に示す。図３では、グリッド３００には、主サービス（すなわち、ＴＭＦ、Ｔｈｅ ＨＩＴＳ、ＵＫＢｒｉｇｈｔ…など）とそれに関連付けられたプリセットまたはチャンネルの割り当て（それぞれ１、２、３）のラインアップ３０２ならびに関連する副サービス３０４（使用可能な場合で、プリセット２２について副サービスが使用可能でないことに留意されたい）が含まれる。

図示のグリッドでは、各行が、１つまたは複数のサービスによって支持される。図１の例では、チャンネル１を表示する（すなわち、ＢＢＣ１ Ｗａｌｅｓに対応する）グリッド行が、２つのサービスによって支持されている。一方のサービスは、同調情報（すなわち、周波数スキャナから獲得された主サービス）のために使用され、他方のサービスは、スケジューリング情報（すなわち、ファイルダウンロードから獲得された副サービス）のために使用される。しかし、外見では、グリッド３００などのグリッドは、ユーザには、単一の統一されたサービスに見える。グリッドを描画するために、スケジューリング情報が、図１のシステムによって、副サービスから獲得される。しかし、ユーザが特定の行をクリックした時に、このシステムは、主サービスを使用して同調情報を獲得する。

アーキテクチャ的に、この例では、チャンネルオブジェクト１５０（図１）などのチャンネルオブジェクトが、グリッドの各行に関連する。チャンネルオブジェクトは、上で説明した機能をサポートする関連するＡＰＩ呼び出し（ＡＰＩ ｃａｌｌ）を有する。この特定の例では、チャンネルオブジェクト１５０は、同調情報を取り出すＡＰＩ呼び出し１５２と、スケジューリング情報および表示情報を取り出すＡＰＩ呼び出し１５４を有する。ＡＰＩ呼び出しは、主サービスを使用して同調情報を取り出し、副サービスを使用してスケジューリング情報を取り出す。もちろん、あるチャンネルオブジェクトによってサポートされるＡＰＩ呼び出しの個数およびタイプは、そのチャンネルオブジェクトの特定の構造およびそれが動作している環境に応じて変更することができる。

興味深いことには、この時点で、上のパラダイムが、シームレス、コヒーレント、かつ統合された方法で、データの複数の異なる共通点のないソースを処理し、グリッドを介してユーザに提示することを可能にする。ユーザにとって、１つのサービスがまるでグリッドの行のそれぞれを支持するように見える。しかし、その背後で、複数のデータソースおよびサービスが、シームレスに一緒に一体化されている。

この手法およびインフラストラクチャは、前にマーケットで入手可能でなかった機能に関する能力も提供する。たとえば、ガイドデータサービスから受信されたガイドデータが不正確である（たとえば、ラインアップが誤っている場合がある）場合に、ユーザは、ユーザインターフェース１０６を介して、ラインアップを変更することができる。すなわち、ユーザは、プリセット番号またはチャンネル番号のサービスへのマッピングを変更するか、主／副サービスの関連付けを変更する能力を与えられる。さらに、送信周波数が変化する情況で、本発明の手法により、ガイドデータプロバイダに、たとえば主サービスに関連付けられた不正確な同調情報をオーバーライドする能力が与えられる。したがって、その後にユーザに提供される情報は、同調情報に関する限り正確である。さらに、上で述べたように、周波数スキャナコンポーネント１０４（図１）は、ガイドデータサービスによって提供される同調情報をオーバーライドする能力を提供する。この場合に、ガイドデータサービスは、それらが提供する同調情報が不正確であることを知らない可能性がある。この不正確さにかかわらず、周波数スキャナは、ガイドデータサービスが提供するものより正確である可能性が高い同調情報を自動的に獲得する能力を提供する。

プリセット／サービスと主／副サービスの分離の拡張
上で述べたように、本発明の手法は、主サービスと副サービスを効果的に分離する。さらに、本発明の手法は、プリセットまたはチャンネルとサービスとの分離も行う。この分離によって、さまざまな堅牢なパラダイムが、ユーザの体験だけでなく、ガイドプロバイダの正確なガイドデータを提供する能力も強化することを可能にする。次の例を検討されたい。

上で説明した方法によれば、今、１つのサービスを複数の同調要求に関連付けることができる。たとえば、データプロバイダは、複数の同調要求を、複数の周波数で放送されている所与のサービスに関連付けることができる。ランタイムヒューリスティックは、そのような関連付けを使用して、その品質または強度に基づいて、同調すべき最良の周波数を判定することができる。

さらに、１つのチャンネル／プリセットを、多数の異なるサービスに関連付けることができる。たとえば、グリッドの特定の行を、５つ以上のサービスによって支持することができ、これらのサービスのすべてが、同調情報および／またはスケジューリング情報を有することができる。ユーザが、視聴するために特定のプリセットまたはチャンネルを選択する時に、同調のためにどのサービスの同調要求を使用するかの判断を、その時に行うことができる。この判断は、たとえば、信号強度に基づいて行うことができる。したがって、最も強い信号を有するサービスを選択することができる。その代わりにまたはそれに加えて、判断を、時刻に基づくものとすることができる。たとえば、おそらく所定の時刻の間に、１つのサービスが同調要求に関連付けられ、別の時間に、異なるサービスがその同調要求に関連付けられる。

さらに、チャンネル５が、ＮＴＳＣサービス（すなわち、アナログサービス）およびＡＴＳＣサービス（すなわち、ディジタルサービス）を有することができる。この場合に、プリセット５が、これらのサービスの両方を指すことができ、各サービスが、同一のスケジュールを有することができる。この場合に、本方法は、この２つの間のディジタル／アナログの相違を考慮してサービス間で選択することができる。そのような選択は、どちらのチューナが空いているか／ビジーであるか、および／またはある事前定義のユーザプリファレンスに基づいてユーザが好んでテレビを視聴するトランスポートのタイプに基づくものとすることができる。さらに、空きディスクスペースまたは、多分、ユーザが、映画を高精細度でタイムシフトし、それ以外のすべてに標準の精細度を使用することを好むかどうかに基づくものとすることができる。

さらに、あるサービスを、多数の異なるプリセットに関連付けることができる。たとえば、あるサービスを複数の周波数で見つけることができ、ユーザが、グリッド内の単一の行ではなく、同一のサービス用のグリッドの複数の行を見ることを好む場合がある。次に、ヒューリスティックによって、同調するサービスを決定することができる。たとえば、視聴者が、ＤｉｒｅｃｔＴＶおよびアナログケーブルでＣｏｍｅｄｙ Ｃｅｎｔｒａｌを受信する場合がある。しかし、アナログケーブルバージョンが、ホームショッピングチャンネルと共有され、その結果、夕方のみ使用可能である場合がある。このユーザは、フルタイムのＣｏｍｅｄｙ Ｃｅｎｔｒａｌ用とパートタイムのＣｏｍｅｄｙ Ｃｅｎｔｒａｌ用の２つの行がグリッドにあることを望むかもしれない。

例示的なシステム
次の説明は、上で説明したさまざまな本発明の方法を使用できる例示的なシステムを対象とする。そのようなシステムには、放送ＴＶ網、対話型ＴＶ網、ケーブル網、およびインターネット対応ＴＶ網などのテレビジョンベースのシステムまたはディジタルラジオネットワーク（たとえば、ＤＡＢ）さえも含む、さまざまなオーディオおよび／またはグラフィックスのエンターテイメントシステムおよび情報システムが含まれる。上で説明したシステムおよび方法の諸態様は、任意の個数のテレビジョンベースのエンターテイメントシステムおよび情報システムで、および任意の個数およびタイプのクライアントデバイス内で、実施することができる。したがって、次の例は、特許請求される主題の応用例を限定することを意図したものではない。

図４に、ＴＶ番組を視聴し、録画するための例示的なシステム４００を示す。システム４００には、クライアントデバイスまたはローカルデバイス４０２、ディスプレイ４０４（たとえば、テレビジョン、モニタなど）、および１つまたは複数のコンテンツプロバイダ４０６が含まれる。コンテンツプロバイダ４０６は、映画、ＴＶ番組、コマーシャル、音楽、および同様のオーディオコンテンツ、ビデオコンテンツ、および／またはイメージコンテンツなど、オンデマンドのおよび／または放送されるメディアコンテンツ４０８の配布を制御する。コンテンツプロバイダ４０６は、衛星オペレータ、ネットワークテレビジョンオペレータ、ケーブルオペレータ、ウェブベースのコンテンツプロバイダなどを表す。さらに、１つまたは複数のガイドデータサービス４０９が、上で説明したようにガイドデータを提供することができる。

クライアントデバイス４０２は、コンテンツプロバイダ４０６によって配布されるメディアコンテンツ４０８およびガイドデータサービスによって提供されるガイドデータを受信し、格納する。具体的に言うと、クライアントデバイス４０２は、コンテンツプロバイダ４０６によって放送または別の方法で送信されるＴＶ番組を受信し、記録するように構成されている。ＴＶ番組の例には、ニュース、ホームコメディ、コメディ、ＴＶ映画、インフォマーシャル、トークショー、スポーツイベントなどが含まれる。クライアントデバイス４０２は、ＴＶ対応コンピュータ、コンピュータベースのメディアサーバ、セットトップボックス、衛星放送受信器、ハードディスク付きＴＶレコーダ、ディジタルビデオレコーダ（ＤＶＲ）、ゲーム機、情報機器などを含む多くの手段で実施することができる。

クライアントデバイス４０２は、衛星伝送、無線通信、ケーブル伝送などのさまざまな伝送媒体４１０を介して、ならびに／またはネットワーク（たとえば、インターネットまたはイントラネット）上のファイル転送プロトコルおよび／またはデータパケット通信などの任意の数の他の伝送媒体などのさまざまな伝送媒体４１０を介して、メディアコンテンツ４０８を受信する。クライアントデバイス４０２には、１つまたは複数のメディアコンテンツ入力４１２が含まれ、このメディアコンテンツ入力４１２は、テレビジョン信号を受信するためのさまざまな周波数またはチャンネルに同調できるチューナおよび／またはＩＰベースのネットワークを介してメディアコンテンツのストリームが受信されるインターネットプロトコル（ＩＰ）入力を含めることができる。

クライアントデバイス４０２には、１つまたは複数のプロセッサ４１４も含まれ、このプロセッサ４１４は、さまざまな命令を処理して、クライアントデバイス４０２の動作を制御し、クライアントデバイスに格納されたアプリケーションを実行し、他の電子デバイスまたはコンピューティングデバイスと通信する。プロセッサ４１４には、さらに、メディアコンテンツおよび番組データを受け取り、処理し、デコードするコンテンツプロセッサを含めることができる。クライアントデバイス４０２は、オーディオデータおよびビデオデータを、ディスプレイ４０４に供給し、または、オーディオデータおよびビデオデータを処理し、かつ／または表示し、あるいは別の方法でレンダリングする他のデバイスに供給するオーディオ／ビデオ出力４１６も備える。ビデオ信号およびオーディオ信号は、クライアントデバイス４０２からディスプレイ４０４に、ＲＦ（ラジオ周波数）リンク、Ｓビデオリンク、コンポジットビデオリンク、コンポーネントビデオリンク、アナログオーディオ接続、または他の類似する通信リンクを介して通信することができる。

クライアントデバイス４０２は、揮発性メモリおよび不揮発性メモリの両方を含むさまざまなタイプのメモリコンポーネントを備える。この例では、クライアントデバイス４０２が、記録媒体４２０およびキャッシュ４２２を有する。記録媒体４２０は、ハードディスクドライブ、冗長ディスクアレイシステム（たとえば、ＲＡＩＤシステム）、記録可能および／または書換可能ディスクなど、さまざまな不揮発性記憶媒体を使用してさまざまな形で実施することができる。キャッシュ４２２は、たとえば、クライアントデバイス４０２でのデータ処理中の高速アクセスのためのランダムアクセスメモリ（ＲＡＭ）として実施することができる。図示されていないが、クライアントデバイスには、さらに、１つまたは複数のデータメモリコンポーネントならびにアプリケーションを格納するプログラムメモリを含めることができる。

１つまたは複数のアプリケーションプログラムを、プログラムメモリに格納し、プロセッサ４１４によって実行することができる。図４に示された代表的なアプリケーションに、ラインアップ構成アプリケーション４３０、ユーザインターフェース（ＵＩ）アプリケーション４３２、電子番組ガイド（ＥＰＧ）アプリケーション４３４、ならびにＤＶＲおよび再生アプリケーション４３６が含まれる。オペレーティングシステム（図示せず）も、ストレージ内で維持し、プロセッサ４１４で実行することができる。

ラインアップ構成アプリケーションは、上で説明した機能を実施するように構成することができる。このアプリケーションは、ＵＩアプリケーション４３２およびＥＰＧアプリケーション４３４と共に、協力して、ユーザが適切な視聴の判断または消費判断を行うために可視グリッドを提示する。

ＤＶＲおよび再生アプリケーション４３６は、コンテンツプロバイダ４０６から受信したメディアコンテンツを記録媒体４２０に記録する。記録されたメディアコンテンツ４４０に、視聴者が後で見るために記録したＴＶ番組が含まれる。ＤＶＲおよび再生アプリケーション４３６は、ディスプレイ４０４での記録されたメディアコンテンツ４４０の再生も容易にする。

ＵＩアプリケーション４３２は、ユーザが、クライアントデバイス４０２で記録されたコンテンツをブラウズし、選択することを可能にする。ＵＩアプリケーション４３２は、記録媒体４２０に格納されたメディアコンテンツ４４０を識別し、ある形でのメディアコンテンツ４４０の処理のオプションを提供する、対話型グラフィカルＵＩスクリーンをサポートする。たとえば、ＵＩスクリーンは、さまざまな記録されたコンテンツ（たとえば、オーディオ、静止画、ビデオ、ＴＶ番組など）へのナビゲートを可能にし、最近記録されたコンテンツをリストし、または特定のコンテンツに関する詳細な情報を提供することができる。さらに、ＵＩアプリケーションは、上で説明したように、ユーザが、ユーザ自身のマッピング（たとえば、さまざまなサービスへのプリセットまたはチャンネルのマッピング）を作成することを可能にすることができる。

１つの例示的なＵＩスクリーン４４２が、ディスプレイ４０４に示されている。このＵＩスクリーン４４２には、最も最近に記録されたＴＶ番組が示されている。

ＥＰＧアプリケーション４３４が、ディスプレイ４０４上で提示する番組ガイドまたはグリッドを生成し、ＵＩアプリケーション４３２が、ディスプレイ上でそのグリッドを消費し、レンダリングする。番組ガイドに、特定のコンテンツが視聴のためにいつ放送されるかおよびどのチャンネルでそのコンテンツが放送されるかを示すスケジュールが含まれる。ＥＰＧアプリケーション４３４は、視聴者が、番組ガイドを通じてナビゲートし、放送される番組、記録された番組、ビデオオンデマンド番組、ビデオオンデマンド映画、対話型ゲームセレクション、およびその視聴者が関心を持つ他のメディアアクセス情報またはコンテンツを突き止めることを可能にする。ＥＰＧデータ４４４が、コンテンツプロバイダ４０６および／またはガイドデータサービス４０９からダウンロードされ、記録媒体４２０に格納され、そこで、ＥＰＧアプリケーション４３４によってアクセスされて、番組ガイドに投入される。

ユーザまたは視聴者は、リモートコントロールハンドセット４５４またはキーボードおよびマウスなどの入力デバイスを使用して、スクリーン４４２またはガイドをナビゲートすることができる。ハンドセット４５４を用いて、視聴者は、たとえば上で述べたプリセット／サービスマッピングの変更など、記録または視聴または他のユーザ入力を提供するために適切な選択を行うことができる。

結論
プリセット／チャンネルとサービスの間の関連付けのみならず、サービス情報、同調情報、プログラム情報、およびスケジュール情報の間の関連付けも分離することによって、アルゴリズムの豊富で堅牢なセットを使用して、ユーザの体験の質を高めるだけでなく、消費者の見る選択および消費する選択に関連するデータの正確な配布および使用を容易にすることができる。

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

一実施形態による、ローカルデバイスまたはクライアントデバイスを含む例示的なコンポーネントを示すブロック図である。 一実施形態による方法のステップを説明する流れ図である。 ユーザに提示される例示的な電子番組ガイドグリッドを示すスクリーンショットである。 さまざまな発明的実施形態を使用できる例示的なシステムを示すブロック図である。

符号の説明

１０２ ガイドデータサービス
１０４ 周波数スキャナ
１０６ ユーザインターフェース
１０８ 事前配布ファイル
１１０ ユーザ供給ファイル
１１２ ユーザ共有可能ファイル
１１４ ＥＰＧデータベース

Claims (20)

1. 複数の異なるソースから論理的に同等のサービスのデータを含むサービス関連データをローカルデバイスが受信することであって、複数の異なるソースは、論理的に同等のサービスの同調情報およびスケジュール情報をそれぞれが提供する第１のソースと第２のソースを少なくとも含み、論理的に同等のサービスは前記複数の異なるソースのそれぞれによって提供され、同一のサービスを記述するスケジュール情報および同調情報を含み、前記第１のソースからの前記論理的に同等のサービスの同調情報は前記複数の異なるソースの全てに亘って最も正確であり、前記第２のソースからの論理的に同等のサービスのスケジュール情報は前記複数の異なるソースの全てに亘って最も正確である、受信することと、
   前記サービス関連データを、複数の異なるソースのそれぞれから論理的に等しいサービスを含むデータがグループの１つに一緒になるように、グループに分類することと、
   各グループ内のデータを、論理的に同等のサービスについて、前記複数の異なるソースのそれぞれによって提供される同調情報を含む主サービスと、前記複数の異なるソースのそれぞれによって提供されるスケジュール情報を含む副サービスに分離すること、
   １又は２以上のポリシーに基づいて、前記グループのそれぞれの中の主サービスと副サービスの間の１又は２以上の個々の関連を確立することであって、論理的に同等のサービスを有するそれぞれのグループについて、複数の主サービスから選択された主サービスと複数の副サービスから選択された副サービスとの間の個々の関連は、主サービスが第１のソースからの最も正確な同調情報を含み、関連する副サービスが第２のソースからのもっとも正確なスケジュール情報を含むように確立される、確立することと、
   グループのそれぞれの個々の関係にチャネルを割り当てることによってラインナップを構築することと、
   ローカル装置に、チャネルと主サービスおよび関連する副サービスを含む詳細な情報をそれぞれが示す１つ又は２つ以上の列を含む、ラインアップを統合した電子番組ガイド（ＥＰＧ）グリッドを表示することとを備えることを特徴とするコンピュータで実施される方法。
2. 前記ソースの１つは、少なくとも１つのガイドデータサービスを含むことを特徴とする請求項１に記載の方法。
3. 前記ソースの１つは、少なくとも１つの周波数スキャナを含むことを特徴とする請求項１に記載の方法。
4. 前記ソースの１つは、ユーザインターフェースを含むことを特徴とする請求項１に記載の方法。
5. 前記ソースの１つは、少なくとも１つの事前配布ファイルを含むことを特徴とする請求項１に記載の方法。
6. 前記ソースの１つは、少なくとも１つのユーザ供給ファイルを含むことを特徴とする請求項１に記載の方法。
7. 前記ソースの１つは、少なくとも１つのユーザ共有可能ファイルを含むことを特徴とする請求項１に記載の方法。
8. 前記ソースは、少なくとも１つのガイドデータサービスおよび少なくとも１つの周波数スキャナを含むことを特徴とする請求項１に記載の方法。
9. 処理する前記動作は、同調情報をスケジューリング情報および番組情報から分離することを含むことを特徴とする請求項１に記載の方法。
10. 処理する前記動作は、事前定義の判断基準に従ってサービスをグループに分類することを含むことを特徴とする請求項１に記載の方法。
11. 分類する前記動作は、サービスコールサインを含む事前定義の判断基準に従ってサービスをグループ化することを試みることを特徴とする請求項１０に記載の方法。
12. 処理する前記動作は、サービスを一緒に、論理的に同等のサービスのグループに分類することを含むことを特徴とする請求項１に記載の方法。
13. 処理する前記動作は、事前定義の判断基準に従ってサービスを一緒にグループに分類することと、その後、各グループ内のサービスを、少なくとも同調情報を含む主サービスと少なくともスケジューリング情報を含む副サービスとに分離することを含むことを特徴とする請求項１に記載の方法。
14. 個々の主サービス関連付けおよび個々の副サービス関連付けを確立することを試みることをさらに備えることを特徴とする請求項１３に記載の方法。
15. 試みる前記動作は、サービスがそこに現れるということをサービスが示すのがＥＰＧグリッドのどの行であるかに少なくとも基づいて関連付けを確立することによって実行されることを特徴とする請求項１４に記載の方法。
16. 試みる前記動作は、主サービスの間に何らかの衝突があるかどうかを確かめ、そうである場合に前記衝突の解決を試みることを含むことを特徴とする請求項１４に記載の方法。
17. 確かめる前記動作は、複数の主サービスがそれらがＥＰＧグリッドの同一の行を占めることを示すかどうかを確かめることを含むことを特徴とする請求項１６に記載の方法。
18. 衝突の場合に、プリセット／チャンネルを第１の前記主／副サービス関連付けに割り当て、衝突する主サービスの少なくとも第２の関連付けを、追加の衝突しない主／副サービス関連付けがプリセット／チャンネルに割り当てられるまでとっておくことをさらに含むことを特徴とする請求項１７に記載の方法。
19. 少なくともいくつかの確立された関連付けについてプリセット／チャンネルを割り当てることをさらに備えることを特徴とする請求項１４に記載の方法。
20. 割り当てる前記動作は、少なくとも１つのプリセット／チャンネルを手動で割り当てることを含むことを特徴とする請求項１９に記載の方法。

Images