JP2014090491A - 番組の利用可能性をモニターするための方法と装置 - Google Patents

Abstract

【課題】複数の住居ユニットネットワークにおいて番組利用可能性を通信する衛星テレビのシステム及び方法を提供する。
【解決手段】衛星テレビＭＤＵシステム１００は、番組の要求を受信するステップと、要求された番組を保存された利用できる番組リストと比較するステップと、もし要求された番組が利用できない場合、代替を提供するステップとを有し、番組の要求をユーザから受け取るユーザインターフェースと、要求された番組を保存された利用できる番組のリストと比較するコントローラと、ソースから入手可能な番組が変更となった場合、ソースから入手可能な要求された番組に関するデータを受信し、要求された番組が入手可能であるとコントローラが判断する場合、要求された番組を伝送するネットワークインターフェースとを有する。
【選択図】図１

Description

本発明は、ネットワーク、およびデバイス通信に関する。より詳細には、複数住居ユニット（ＭＤＵ：Multi-dwelling unit）ネットワークにおいて、セットトップボックスとゲートウェイデバイス間との間の番組の通信およびチャネルの利用可能性に関する。

本出願は、２００７年８月８日に米国において出願された仮出願６０／９６３，９４に対する３５ＵＳＣ第１１９条の下での利益を要求する。

ここでの説明は、技術のさまざまな態様を開示することを目的とし、本願明細書に記載され、および／または以下にクレームされる本発明の開示のさまざまな態様と関連している。この説明は、さまざまな本発明の態様のより適切な理解を容易にするために読者に背景情報を提供しようとするものである。したがって、これらの記載は、上記の観点から理解されるべきであり、かつ従来技術の存在を認めるものではないと理解されなければならない。

多くの人々が認識しているように、衛星テレビシステムはここ数年来、広範囲に普及するようになった。事実、１９９４年以来、アメリカの１２００万世帯以上が、衛星テレビ受信契約者となっている。大部分のこれらの受信契約者は、衛星アンテナを設置し、かつこれに接続するのが比較的容易である単一家族の一軒家に住んでいる。例えば、衛星アンテナは、住宅の屋根上に取り付けられてもよい。

しかしながら、多くの可能な受信契約者は、複数住居ユニット（ＭＤＵ）のある住居（例えばホテルまたは高層のアパート）に住むか、一時的に宿泊している。残念なことに、ＭＤＵの範囲内に存在する個々のユニットに衛星テレビサービスを提供することには、困難が伴う。各家庭に１つの衛星アンテナを提供し、かつ接続することは、非実用的であり、かつ／また、極めて高価である。例えば、１０００世帯を有する高層のアパートで、最高１０００個の衛星アンテナを建物の屋根に載置することは、非実用的である。一部の従来システムは、単一の同軸ケーブルを経てディジタル衛星テレビジョン信号を複数の住居に送信することができるアナログ信号に変換することによって、これらの問題を回避した。しかしながら、これらの変換システムは、限られたチャネルを提供し、全てがディジタルなシステムと比較して劣化した品質を有し、かつ一軒家の家庭に住んでいるユーザが慣れ親しんでいる衛星テレビの経験を提供することはできない。

ＭＤＵの個々の住居に対して、直接衛星信号を配信することは、単一家族の家庭のユーザに類似した経験を提供することができるが、更に複雑化を招く。例えば、衛星アンテナからの衛星信号の配信は特別な信号分配装置、および配線を必要とする。そして、それはＭＤＵ装置には存在しないことがある。装置を改造するコストは無視できない。

また、信号受信のためのリソースを遠隔に設置し、これらの専用のリソースを使用して各住居ユニットがサービスを受信するシステムを構成することは可能である。例えば、メインチューニング機能は中央制御室に設置するようにして、そして個々の信号またはサービスは各々の住んでいるユニットに送ることができる。この接続は、建物の全体にわたって配信されるイーサネット（登録商標）または同軸ケーブルを使用してなされてもよい。理想的には、ビデオコンテンツを配信するシステムに対して、各々のエンドユーザは、それ自身の専用のチューニング、およびデコーディング回路を有しなければならない。これは、特に大規模なＭＤＵ装置に対して、費用を増大させ、かつ非効率的となり得る。ＭＤＵシステムが中央に設置されたゲートウェイで、各エンドユーザ間のチューニングリソースの管理および共有に対応するように構成した場合であっても、チャネル選択のためのユーザインターフェースを管理することのオペレーション上の難しさが難点となる。

放送サービスのそのような態様によって影響を受ける衛星サービスとしては、番組またはチャネル利用可能性の判定が含まれる。典型的なサービス形態において、セットトップボックス（ＳＴＢ）は、最初のスタートアップまたはブートアップの時に番組ガイドを得る。この番組ガイド情報は、ユーザのためのチャネルリストの作成に使用され得る。リストに載っている全ての番組は、常にユーザによって利用できるとみなされる。この構成では、衛星ネットワーク利用可能性は変更されないと仮定される。したがって、ＳＴＢが番組ガイドを介して、ネットワークの利用可能性の情報を得ることで充分である。

しかしながら、ＭＤＵネットワークでは、チャネル利用可能性の変更があり得る。あるいは、クライアントＳＴＢの再起動またはスタートアップなしで、ゲートウェイデバイスのブートがなされ得る。クライアントＳＴＢが起動するかあるいはブートアップしたあと、ネットワークが利用できなくなった場合、ユーザのチャネルリストがあるにもかかわらず、ネットワークに関連づけられた全てのチャネルが、ユーザに利用できないこととなる。その結果、ユーザのチャネルのアップダウンコマンドは、これらの利用できないチャネルにおいて依然として上下するだけとなる。加えて、特定のチャネルは、サービス提供者の問題ではなく、ネットワークの問題によって利用できなくなることがある。ネットワークによってチャネルの利用ができない場合、チャネルリストの中でユーザが利用できないチャネルが一定数存在することとなり得る。更に、ユーザは、チャネルのアップダウンコマンドあるいは、直接にチャネル選局コマンドを使用し、結局チャネルが表示されず、そのチャネルが表示されない理由はフィードバックされないことがあり得る。したがって、複数の住居ユニットネットワークにおいて番組利用可能性を通信する改良されたシステム及び方法のニーズが存在する。

開示された実施例の範囲に対応する特定の態様を以下に記載する。これらの態様は単に本発明が必要し得る特定の形式の概要を提供するためだけのものであり、これらの態様が本発明の範囲を制限することを目的としていない点を理解すべきである。実際、本発明は、後述する以外の種々の態様を含んでもよい。

実施例において、方法は、番組のための要求を受信するステップと、要求された番組を利用できる番組の保存されたリストと比較するステップと、要求された番組が利用できない場合、代替のものを提供するステップと、を有する発明が開示されている。

別の実施例としては、ネットワークから利用できる番組のリストを取得する手段と、番組の要求を受信する手段と、番組のための要求を利用できる番組のリストと比較する手段と、を含む装置が開示されている。

更なる態様において、ネットワーククライアント装置であって、ユーザからの番組の要求を受信するユーザインターフェース、ユーザインターフェースに接続されたコントローラを含み、前記コントローラは、要求された番組を利用できる番組の保存されたリストと比較し、ネットワークインターフェースは、前記コントローラに接続され、前記ネットワークインターフェースは、ソースから入手できる番組が変更された場合に、ソースから入手できる番組に関するデータを受信し、かつ、要求された番組が入手できると前記コントローラが判断した場合にのみ要求された番組を送信するネットワーククライアント装置が開示されている。

本発明の衛星テレビのＭＤＵシステムの実施例のブロック図である。 本発明のＳＴＢの実施例のブロック図である。 本発明のＭＤＵシステムの番組アップデートを通信するための方法の実施例のフローチャートである。 本発明のＳＴＢおよびＭＤＵゲートウェイ間の通信のための方法の実施例のフローチャートである。

本発明の特徴、および効果は以下の説明から、より明確となる。

本発明の開示の一つ以上の特定の実施例について、以下に述べる。これらの実施例の簡潔な説明を提供するため、実際のインプリメンテーションの全ての特徴が、明細書に記載されているというわけではない。実際のインプリメンテーションのいずれにおいても、いかなる工学的または設計プロジェクトにおいて、開発者の特定の目的を達成するために多数のインプリメンテーションに特有の決定がなされる。たとえば、個々のインプリメンテーションにおいて異なるシステム上の制約、およびビジネス上の制約に適合することが必要となることは言うまでもない。例えば、本実施例は、異なる媒体によって提供される信号を利用するために修正されてもよい。例えば、媒体としては、空中伝送や、ケーブル伝送等が挙げられる。さらに、このような開発努力は、複雑であり、時間のかかるものかもしれないが、開示の利益を享受する当業者が設計、組み立て、および製造における日常的な仕事であると理解されなければならない。本願明細書において、「チャネル」および「番組（program）」の用語は、相互に置換可能であるものとして用いている。この意味で、両者は、本願発明において同じように操作されるよう取り扱われている。

図１に移ると、現在の開示の衛星テレビＭＤＵシステム１００の実施例のブロック図が示されている。受信アンテナ１１０ａないし１１０ｎは、一つ以上の衛星に設置されるトランスポンダから衛星信号を受け取る。受信アンテナ１１０ａないし１１０ｎの数は、例えば、使用されている衛星の数および／または位置に依存する。受信アンテナ１１０ａないし１１０ｎは、信号源から出力されるオーディオ、ビデオ、およびデータ信号を受信して、かつＭＤＵゲートウェイ１１２にそれらの信号を提供する。通常は、信号源は、サービス提供者（例えば衛星サービス提供者ＤｉｒｅｃＴＶ）である。

ＭＤＵゲートウェイ１１２は、サービス提供者、およびＭＤＵネットワークのユーザ間の信号および通信インターフェースを提供する。ＭＤＵゲートウェイ１１２は、チューニング、復調、およびデマルチプレクシングモジュール１１４と、ネットワーク利用可能性データベース１１６と、ゲートウェイインターフェース１１８とを有する。チューニング、復調、およびデマルチプレクシングモジュール１１４は、アンテナ１１０ａないし１１０ｎからの信号の全てを受信し、ゲートウェイインターフェース１１８またはＭＤＵゲートウェイ１１２の他のセクションからの入力に基づいて、信号の一部分を同調し、復調し、デマルチプレクスする回路を含む。チューニング、復調、およびデマルチプレクシングモジュール１１４は、入力信号を個々のチャネルまたは番組にチューニング、復調、およびデマルチプレクシングするために使用される並列回路のセットを使用してインプリメントされてもよい。チューニング、復調、およびデマルチプレクシングモジュール１１４は、サービス提供者によって提供される全ての可能なチャネルを同時に再現するのに十分なチューニングリソースまたは処理バンド幅を含んでいなくてもよい。その結果、ＭＤＵゲートウェイ１１２は、しばしば一部のチャネルまたは番組を利用できなくすることを含むチューニングリソースの配分を管理してもよい。

ＭＤＵゲートウェイ１１２のゲートウェイインターフェース１１８はチューニングされ、復調され、デマルチプレクスされたオーディオ、およびビデオ信号に、他のコントロールおよびデータ信号（例えばネットワーク利用可能性データベース１１６から引き出される利用可能性データ）を加えてローカル配信ネットワーク１２０に提供する。ローカル配信ネットワーク１２０は、いくつかの配信方法、およびプロトコル（例えばインターネットプロトコル（ＩＰ）、同軸ケーブル、イーサネット（登録商標）または送電線通信標準）のいずれかを経由して、選択された番組、およびデータ情報を各々のクライアントＳＴＢ１２２ａないし１２２ｍに配信する。ＭＤＵの各々の住居ユニットは一つ以上のクライアントＳＴＢを有してもよい。１２２ａないし１２２ｍのクライアントＳＴＢの数は、受信アンテナ１１０ａないし１１０ｎの数、サービス提供者から入手可能なチャネル数、またはＭＤＵゲートウェイ１１２のチューニングリソースの数よりも多くてもよい点に留意すべきである。

好ましい実施例において、チャネル情報、番組ガイドデータ、および番組利用可能性データは、サービス提供者からＭＤＵゲートウェイ１１２に絶えず受け取られ、ダウンロードされる。データは、ＭＤＵゲートウェイ１１２の中で生成されたその番組／チャネル利用可能性に関する追加データとともに、ネットワーク利用可能性データベース１１６において保持されてもよい。サービス提供者またはＭＤＵゲートウェイ１１２またはローカル配信ネットワーク１２０からの利用可能性の変更によって、ネットワーク利用可能性データベースに利用可能性の変更が生じたときはいつでも、最新情報が、ＭＤＵゲートウェイ１１２によって、各々のクライアントＳＴＢ１２２ａないし１２２ｍにネットワークマルチキャスト通信で供給されてもよい。

図２に移ると、現在の開示のクライアントＳＴＢ２００の実施例のブロック図が示されている。クライアントＳＴＢ２００の動作は、図１に示されているいかなるクライアントＳＴＢ１２２ａないし１２２ｍとも類似している点に留意する必要がある。クライアントＳＴＢ２００は、ローカル配信ネットワーク１２０と、ネットワークインターフェース２１２を介してインターフェースをとっている。ネットワークインターフェース２１２は、Ａ／Ｖ入力およびディスプレイ回路２１４、番組ガイドプロセッサ２１６、および通信および制御プロセッサ２１８に接続される。番組ガイドプロセッサ２１６は、Ａ／Ｖ入力およびディスプレイ回路２１４に接続される。通信および制御プロセッサ２１８は、番組ガイドプロセッサ２１６、メモリ２２４、およびユーザインタフェースモジュール２２６に接続される。なお、他のブロックおよび接続、例えば、電源、電源接続、および通常存在する他の制御信号は、図示されていない。示されているブロックの一つ以上は、より大きな処理ブロックに統合されてもよい点に留意すべきである。例えば、ブロックの全ては、単一の集積回路（例えばマイクロプロセッサ）に統合されてもよい。更に、ブロックにより実現されている機能の多くは、ハードウェア、ソフトウェア、ファームウェアまたはこれらのいかなる組合せを使用してインプリメントされてもよい。

ネットワークインターフェース２１２は、ローカル配信ネットワーク１２０から入力信号を解析して、そして、Ａ／Ｖ入力およびディスプレイ回路２１４、番組ガイドプロセッサ２１６、および通信および制御プロセッサ２１８に対して必要な信号を提供する。Ａ／Ｖ入力および表示回路２１４は、ネットワークインターフェース２１２から受け取られるオーディオ、およびビデオ信号をフォーマットし、そして適切なオーディオおよびビデオディスプレイ出力信号２２０を出力する。番組ガイドプロセッサ２１６は、インタラクティブ番組ガイドデータを編集し、そしてＡ／Ｖ入力およびディスプレイ回路２１４にデータを送信する。番組ガイド情報は、通常、ユーザーリクエストの後に表示される。これは、ビデオディスプレイ出力にオーバレイされるか、そのときのビデオディスプレイ出力の一部と置換される。

通信および制御プロセッサは２１８、クライアントＳＴＢ２００のオペレーションを維持し、かつ管理する。また、通信および制御プロセッサ２１８は、メモリ２２４、およびユーザインタフェースモジュール２２６を管理する。メモリ２２４は、セットトップボックスを動作させるオペレーティングシステム、番組ガイドデータ、先に述べたネットワーク利用可能性データベース１６のゲートウェイ１２において保存される番組利用可能性データに対応する番組利用可能性データを有する。ユーザインタフェースモジュール２２６は、クライアントＳＴＢ２００のオペレーションを制御するためのユーザ入力命令の結果として、ユーザ入力信号２２８を受信する。ユーザ入力信号２２８は、ボタン、キーパッドまたはタッチスクリーンを含むフロントパネルディスプレイによって生成されてもよい。ユーザ入力信号２２８はまた、（不図示の）リモート制御インターフェースで生成されてもよい。ユーザ入力コマンドは、通信および制御プロセッサ２１８によって解読され、そしてクライアントＳＴＢ２００によって実行される。必要に応じて、ユーザの入力した命令（例えば、番組およびチャネル要求）は、さらに、ネットワークインターフェース２１２に提供され、さらにローカル配信ネットワーク１２０を介してゲートウェイ１１２に出力されてもよい。好ましい実施例によれば、ユーザがチャネルアップまたはダウンの命令を入力すると、例えば、ユーザインタフェースモジュール２２６は命令を解読して、それを通信および制御プロセッサ２１８に送信する。通信および制御プロセッサ２１８は、スキャンリストの次のチャネルを決定して、メモリ２２４に保存される番組利用可能性データをチェックする。要求された番組またはチャネルが利用できる場合、命令はネットワークインターフェース２１２、およびローカル配信ネットワーク１２０に送られ、ゲートウェイ１１２で動作する。要求されたチャネルが利用できない場合、通信および制御プロセッサ２１８は自動的にこの要求されたチャネルをスキップし、スキャンリストに続く次のチャネルに移る。このプロセスは、スキャンリストに残っているものがある限り、続けられる。このようにして、チャネルのアップダウンのオペレーションは、利用できないチャネルを選ぶ試みなしで、途切れることなく達成される。

他の実施例によれば、ユーザが直接のチャネルの入力によって特定のチャネルを選んだ場合、命令はユーザインタフェースモジュール２２６によって解読され、通信および制御プロセッサ２１８に送信される。プロセッサ２１８は、そのチャネルまたは番組の利用可能性を確認するために、メモリ２２４に問い合わせる。要求されたチャネルまたは番組が利用できる場合、要求はＭＤＵゲートウェイ１１２にネットワークインターフェース２１２を介して送られる。要求されたチャネル／番組が利用できない場合、スクリーン上のメッセージは生成されて、そしてディスプレイ信号２２０のビデオ成分の一部として提供される。実施例において、表示メッセージは、要求された番組が利用できないことをユーザに知らせる。メッセージは、サービス提供者の停止またはネットワークの停止のような、番組が現在利用できない理由、および番組が再び利用できる時期を更に示してもよい。別の実施例において、メッセージは、要求されるものと類似している他のチャネルまたは番組の示唆を提供してもよい。例えば、要求された番組は比較されてもよい。そして、番組ガイドの情報を使用して、番組タイプ（例えばスポーツ、映画またはコメディ）によって分類されてもよい。そして、同じカテゴリの代替番組またはチャネルを、ユーザ選択のためのオプションのリストとして示してもよい。その結果、代替え番組の自動同調による空のチャネルの表示を最小化し、番組の選択が利用できない理由を知らせることを更に行ってもよく、これによって、ユーザ経験が改善される。

図３に移ると、本発明における、ＭＤＵシステムの番組アップデートを通信するための方法３００の実施例のフローチャートが示されている。方法３００は、主に図１のＭＤＵシステム１００に関連して図示されている。既に記載されているように、番組利用可能性はサービス提供者または特定の、および一時的なサービス提供者の番組停止または番組変更の結果として、変更される。番組利用可能性は、また、いずれかのゲートウェイまたはネットワーク資源マネージメントに基づいてＭＤＵゲートウェイ１１２のオペレーションの結果として、変更され得る。番組に関連する利用可能性の変更の情報を、できる限りクライアントＳＴＢ１２２ａないし１１２ｍに提供することによって、不必要なネットワーク通信転送、およびＭＤＵゲートウェイ処理を防止することができる。

ステップ３１０で、ガイドおよび番組利用可能性の最新版がゲートウェイＭＤＵ１１２によってサービス提供者から受け取られる。最新版は、サービス提供者から定期的に提供されてもよい。ゲートウェイＭＤＵ１１２は、最新版が適切に特定され、かつ管理されることを保証するために、利用可能性検出システムを使用してもよい。次に、ステップ３２０、検出されたガイドおよび番組利用可能性データは、ＭＤＵゲートウェイ１１２のネットワーク利用可能性データベース１１６に保存される。サービス提供者からのガイドおよび番組利用可能性の最新版に加えて、ＭＤＵゲートウェイ１１２によってなされる利用可能性の変更も、またネットワーク利用可能性データベース１１６に保存されてもよい。他の情報、すなわち利用可能性変更の原因または番組がどれくらい利用できないかに関する変更の持続時間に関する情報も、またネットワーク利用可能性データベース１１６に保存されてもよい。

次に、ステップ３３０で、サービス提供者による変更およびＭＤＵネットワーク生成された変更を含んだ更新されたガイドおよび番組利用可能性データは、各々のクライアントＳＴＢ１２２ａないし１２２ｍに送信される。番組利用可能性データは一定の時間間隔、あるいはサービス提供者またはＭＤＵネットワーク利用可能性データ変更が生ずる場合にだけ、送られてもよい。更に、ＭＤＵゲートウェイ１１２は、利用可能性データの全体のマップまたは一組を送信してもよい。あるいは、前に送られた利用可能性変更からのインクリメントとしての変更だけを送ってもよい。最後に、ステップ３４０で、新規なガイドおよび番組の利用可能性データは、クライアントＳＴＢ１２２ａないし１２２ｍによって受け取られ、クライアントＳＴＢメモリ（例えばメモリ２２４）に保存される。ＭＤＵゲートウェイ１１２が現在の利用可能性に関連した変更だけを送信した場合、更にクライアントＳＴＢ１２２ａないし１２２ｍは、適切なメモリ比較ステップを実行し、適切にメモリ２２４を更新し、かつ変更を保存してもよい。

図４に移ると、クライアントＳＴＢ２００、および本発明のＭＤＵゲートウェイ１１２間の通信のための方法４００の実施例のフローチャートが示されている。方法４００は、ユーザの番組要求、およびネットワークにおける要求された番組の利用可能性の評価の結果として、クライアントＳＴＢ２００、およびＭＤＵゲートウェイ１１２間の通信を含む。前述のように、現在利用可能でない番組、またはサービス提供者からの入手不能、ＭＤＵゲートウェイ１１２からの入手不能、およびその他のネットワークの問題による入手不能を含む理由があっても、ユーザは、その番組を要求してもよい。ネットワーク資源、およびバンド幅の不必要な使用を制限するために、要求された番組が利用できない場合、方法４００は不必要なネットワーク要求を予防する。方法４００は、主に図２に示されるクライアントＳＴＢ２００に関連して図示されている。

ステップ４１０で、ユーザは、新規な番組を要求する。ユーザーリクエストは、前述したように前面パネルからの命令またはリモート制御入力で作られてもよい。ステップ４１０のユーザーリクエストに基づいて、要求された番組がメモリ２２４の現在利用可能な番組としてリストアップされているかどうか、ステップ４２０で判断がなされる。上述の通り、利用可能性アップデートに基づく、ガイド情報、番組利用可能性および変更が、ＭＤＵゲートウェイ１１２からクライアントＳＴＢ２００に提供される。

ステップ４２０で、現在要求された番組が利用できるとクライアントＳＴＢ２００が判断する場合、ステップ４３０で、番組要求がＭＤＵゲートウェイ１１２に送られる。ステップ４２０で、現在要求された番組が利用できないとＳＴＢが判断する場合、ステップ４４０で、ユーザーリクエストのタイプに関する第２の判定がなされる。ステップ４４０で、要求タイプがチャネルスキャン入力である場合、ステップ４５０で、特定チャネルスキャンリストに続く次の番組またはチャネルが選ばれる。通常は、スキャンリストユーザーコマンド入力は、チャネルアップまたはチャネルダウン命令を使用してなされる。多くの異なるチャネルスキャンリストが利用可能であり、利用されてもよい点に留意するべきである。例えば、可能なチャネルスキャンリストとしては、サービス提供者から当初より入手できる全てのチャネル、ＭＤＵゲートウェイによって提供される全てのチャネル、または、ユーザが作成した好みのチャネルのリストが挙げられる。各々のこれらのスキャンリストは、クライアントＳＴＢ２００のメモリ中に保存され、更に異なるユーザ入力コマンドでアクセスされてもよい。

ユーザーリクエストの代わりとして、特定のスキャンリストの次のチャネルが、ステップ４２０へ提供され、評価される。それから、前述したように、方法は、スキャンリストに利用できると判断される番組があれば、ステップ４２０を続ける。

ステップ４４０で、要求タイプがチャネルスキャンでない場合、ステップ４６０でメッセージを提供し、ユーザに表示する。生成された表示メッセージは、例えば、要求された番組が利用できないことをユーザに知らせてもよい。生成された表示メッセージは、クライアントＳＴＢ２００に接続されるテレビジョンスクリーンまたは他の表示装置に表示されてもよい。表示メッセージは、また、番組が現在利用できない理由の情報がクライアントＳＴＢ２００のメモリ２２４に保存される場合、この理由を提供してもよい。あるいは、メッセージは、要求されるものと類似している他のチャネルまたは番組の示唆を提供してもよい。例えば、要求された番組と共通する一部の特徴に基づいて、ダウンロードされた番組ガイド情報から取り出される利用できる番組のリストが表示されてもよい。この特徴としては、年齢カテゴリ、長さ、番組タイプ（すなわちスポーツ、コメディ、映画）または最近の視聴習慣を含むが、これに限定されるものではない。ユーザは、それから一覧に示される代替番組のうちの１つを選択してもよい。方法４００は、番組要求がＭＤＵゲートウェイにステップ４３０で送信されるか、または利用可能性表示メッセージをステップ４６０で提供したあと、ステップ４７０で終了する。

ステップ４４０の決定ステップは、ステップ４１０で要求された番組の代替のものを提供する。１つのケースにおいて、代替のものは、適切なスキャンリストにある代替番組を要求することとなり得る。他のケースにおいて、要求された番組が利用できないという情報、および可能ならば、それが利用できない理由を提供するメッセージが表示されてもよい。両方の選択肢において、番組のための要求は、ＭＤＵゲートウェイ１１２へネットワークによって提供されない。この種のクライアントＳＴＢ２００は、関連づけられた情報を送信することを効果的に防止する。ユーザが適切な動作を選ぶよう、ステップ４５０、およびステップ４６０で示される両方の選択肢が提供される点に留意すべきである。現在要求された番組が利用できない場合、更なる、他の代替のものとしては、一組の代替番組の中から選択することをユーザに紹介することを含んでもよい。

なお、本明細書および図面を用いて特定の実施例を説明したが、本発明はさまざまな変更態様、および変形例を含みうるものである。実施例は、開示された特定の形式に限定することを目的としていないことは、理解されなければならない。むしろ、開示は、下記の添付の請求の範囲に記載の本発明の範囲内の全ての変更態様、均等物、および代替のものをカバーするものである。

Claims (15)

1. ネットワーク上のゲートウェイデバイスと接続されたセットトップボックスにおける番組要求を処理する方法であって：
   ネットワークから、番組の利用可能性に関する情報を取得するステップであって、前記情報は、前記ネットワーク上の各セットトップボックスにマルチキャスト通信として送信される、ステップと；
   番組の要求を受信するステップと；
   前記要求された番組と、利用可能な番組がメモリに保存されたリストとを比較するステップと；
   前記要求された番組が前記ゲートウェイデバイスから配信できないことを、前記比較するステップの結果が示す場合、前記ゲートウェイデバイスに前記要求を送信する前に、前記要求された番組とは異なる代替のものを選択するステップと；
   を有する方法。
2. 前記代替のものを選択するステップは、前記要求された番組とは異なる利用可能な番組の前記保存されたリストから番組を選択するステップ、を含む請求項１記載の方法。
3. 前記保存されたリストは、好みの番組のスキャンリストである、請求項２記載の方法。
4. 前記保存されたリストから番組を選択するステップは、前記好みの番組のスキャンリストにおいて次の順番の利用可能な番組を選択するステップ、を含む請求項３記載の方法。
5. 前記代替のものを選択するステップは、メッセージをディスプレイに提供するステップ、を有する請求項１記載の方法。
6. 前記メッセージは、前記要求された番組が利用できないことを示す、請求項５記載の方法。
7. 前記メッセージは、前記番組が利用できない理由に関する情報を含む、請求項５記載の方法。
8. 前記ネットワークからの番組の前記利用可能性に関する前記情報を、前記利用可能な番組の保存されたリストに保存するステップ；
   を更に有する請求項１記載の方法。
9. 前記要求された番組が利用できない場合、前記要求された番組に関する情報の通信をネットワーク上で防止するステップ、を更に有する請求項１記載の方法。
10. ネットワークから利用可能な番組のリストを取得する手段であって、利用可能な番組の前記リストは、ゲートウェイデバイスから各セットトップボックスにマルチキャスト通信として送信される、手段と；
    番組の要求を受信する手段と；
    前記番組の要求と、利用可能な番組がメモリに保存されたリストとを比較する手段と；
    前記要求された番組が前記ゲートウェイデバイスから配信できないことを、前記比較する手段の結果が示す場合、前記ネットワークに前記要求を送信する前に、前記要求された番組とは異なる代替のものを選択する手段と；
    を有する装置。
11. 前記利用可能な番組のリストを更新する手段、を更に有する請求項１０記載の装置。
12. 前記利用可能な番組のリストを保存する手段、を更に有する請求項１０記載の装置。
13. 前記代替のものを選択する手段は、利用可能な番組のリストに載っている代替え番組を要求する手段、及び前記要求された番組が利用できない場合、メッセージを表示する手段、の少なくとも１つを有する請求項１０記載の装置。
14. 前記要求された番組が利用できない場合、前記番組の要求を前記ネットワーク上で通信しない手段、を更に有する請求項１０記載の装置。
15. 前記要求された番組が利用可能な場合、前記番組の要求をネットワーク上で通信する手段、を有する請求項１０記載の装置。

Images