(57)【要約】【課題】チューナのコンフリクトが発生した場合に、チューナリソースをチューナのコンシューマに割り振るためのシステム、方法、およびコンピュータプログラムを提供すること。【解決手段】システムまたはネットワークのチューナリソースが中央サーバに常駐している場合に、それらのチューナが、チューナの要求の優先度および現在のチューナの優先度に従って割り振られる。使用中のチューナの１つよりも優先度が高いチューナの要求は許可される。しかし、警告なしにチューナがコンシューマから取られることはない。チューナのコンフリクトは、必要に応じて、それぞれのチューナの優先度を下げることによっても防ぐことができる。【選択図】　　　　図１
2004007592.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のセットトップボックスを含むコンシューマが中央サーバに配置されているチューナを使用し、ネットワーク中の前記コンシューマにソースからコンテンツを配信するために前記チューナが必要とされるネットワークにおいて、チューナをコンシューマに割り振る方法であって、
前記中央サーバにおいてコンシューマからチューナの要求を受け取るステップであって、前記チューナの要求がチューナの優先度に関連するステップと、
前記チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが前記要求しているコンシューマに割り振られないようにするステップであって、前記チューナの要求はチューナのコンフリクトがない場合に許可されるステップと、
前記チューナの要求に関連する前記チューナの優先度よりも低優先度の特定のチューナを前記コンシューマに提供することによって前記チューナの要求を解決するステップであって、前記特定のチューナの前記優先度が、前記チューナの要求に関連する前記チューナの優先度と等しいかそれよりも高い場合には、前記特定のチューナは前記コンシューマに割り振られないステップと
を含むことを特徴とする方法。
【請求項２】
前記中央サーバにおいてチューナの要求を受け取るステップは、さらに、
チューナの番組を録画する要求または録画バッファの要求を受け取るステップと、
チューナのライブ番組を見る要求またポーズバッファの要求を受け取るステップであって、チューナの番組を録画する要求が、チューナがライブ番組を見るのに使用されるよりも優先度が高いステップと、
チューナのデータサービスを使用する要求を受け取るステップであって、チューナのライブ番組を見る要求が、チューナがデータサービス用に使用されるよりも優先度が高いステップと、
チューナのピクチャインピクチャウィンドウの要求を受け取るステップであって、チューナのデータサービスを使用する要求が、チューナがピクチャインピクチャウィンドウ用に使用されるよりも優先度が高いステップ
のうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求がチューナのコンフリクトを引き起こすかどうかを判断するステップは、さらに、すべてのチューナがコンシューマによって使用されているかどうかを判断するステップであって、アイドル状態のチューナはコンシューマによって使用されておらず前記要求しているコンシューマへの割り振りが可能なステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記チューナの前記要求を解決するステップは、さらに、
他のコンシューマにメッセージをブロードキャストするステップであって、前記ブロードキャストメッセージにより、コンシューマが特定のチューナを使用中かを判断するステップと、
前記メッセージへの応答が受け取られなかった場合に、前記要求しているコンシューマに前記特定のチューナを割り振るステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記要求しているコンシューマはユーザであり、チューナがシステムの延期可能イベント用に使用される方法であって、前記システムの延期可能イベントを中断するステップと、前記チューナを前記要求しているコンシューマに割り振るステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記チューナの前記要求を解決するステップはさらに、コンシューマに、前記チューナの現在の優先度よりも高優先度のスケジュールされたイベントのため、チューナの使用が終了する可能性があることを通知するステップを含むことを特徴とする請求項５に記載の方法。
【請求項７】
コンシューマが１つ以上のノードセットトップボックスを含み、サーバがソースから前記ノードセットトップボックスにコンテンツを配布し、前記中央サーバが、前記中央サーバおよび前記１つ以上のノードセットトップボックスにより使用される１つ以上のチューナを含むシステムにおいて、前記１つ以上のチューナを前記コンシューマに割り振る方法であって、
コンシューマからチューナの要求を受け取るステップであって、前記チューナの要求がチューナのコンフリクトを発生させて、そのために前記要求しているコンシューマに割り振ることができる利用可能なチューナがないようにするステップと、
前記コンシューマに、
録画済みの番組をユーザに対して表示するステップであって、前記録画済みの番組を表示するのにチューナが必要とされず、前記チューナのコンフリクトが解決されるステップと、
スケジュールされたイベントを変更して、前記チューナの要求とのコンフリクトを生じている前記スケジュールされたイベントに関連する特定のチューナが、もはや前記チューナの要求とコンフリクトしないようにするステップのうち少なくとも１つを選択させることで前記チューナの要求を解決するステップと、
前記特定のチューナを前記コンシューマに割り振るステップと
を含むことを特徴とする方法。
【請求項８】
コンシューマからチューナの要求を受け取るステップは、さらに、
チューナの番組を録画する要求または録画バッファの要求を受け取るステップと、
チューナのライブ番組を見る要求またポーズバッファの要求を受け取るステップであって、チューナの番組を録画する要求が、チューナがライブ番組を見るのに使用されるよりも優先度が高いステップと、
チューナのデータサービスを使用する要求を受け取るステップであって、チューナのライブ番組を見る要求が、チューナがデータサービス用に使用されるよりも優先度が高いステップと、
チューナのピクチャインピクチャウィンドウの要求を受け取るステップであって、チューナのデータサービスを使用する要求が、チューナがピクチャインピクチャウィンドウ用に使用されるよりも優先度が高いステップ
のうち少なくとも１つを含むことを特徴とする請求項７に記載の方法。
【請求項９】
スケジュールされたイベントを変更するステップは、さらに、
スケジュールされたイベントを再スケジュールして、前記スケジュールされたイベント用に使用されている前記特定のチューナが、もはや前記チューナの要求とコンフリクトしないようにするステップと、
スケジュールされたイベントを取り消して、前記スケジュールされたイベント用に使用されている前記特定のチューナが、もはや前記チューナの要求とコンフリクトしないようにするステップと
を含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記チューナの要求を解決するステップは、さらに、
他のコンシューマにメッセージをブロードキャストして、コンシューマが特定のチューナを使用中かを判断するステップと、
前記メッセージへの応答が受け取られなかった場合に、前記要求しているコンシューマに前記特定のチューナを割り振るステップと
を含むことを特徴とする請求項７に記載の方法。
【請求項１１】
前記チューナの要求を解決するステップはさらに、特定のチューナが前記チューナの要求に関連する優先度よりも低優先度の場合には、前記特定のチューナを前記要求しているコンシューマに割り振るステップを含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記チューナの要求を解決するステップはさらに、特定のチューナの使用が終了したときにチューナの優先度を下げることによって、前記チューナのコンフリクトを防ぐステップを含むことを特徴とする請求項７に記載の方法。
【請求項１３】
前記チューナのコンフリクトを防ぐステップはさらに、前記チューナの使用が終了したときに、特定のチューナをアイドル状態に置くステップを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記チューナの使用は、
番組を録画すること、
ブロードキャストメッセージへの応答を受け取らないこと、
セットトップボックスがスクリーンセーバモードに入っているときはユーザの応答を受け取らないこと
のうちの１つであることを特徴とする請求項１３に記載の方法。
【請求項１５】
１つ以上のセットトップボックスを含むコンシューマが中央サーバに配置されているチューナを使用し、ネットワーク中の前記コンシューマにソースからコンテンツを配信するために前記チューナが必要とされるネットワークにおいて、チューナをコンシューマに割り振る方法を実施するためのコンピュータプログラムであって、
前記方法を実施するためのコンピュータ実行可能命令を備えたコンピュータ可読媒体を含み、前記方法は、
前記中央サーバにおいてコンシューマからチューナの要求を受け取るステップであって、前記チューナの要求がチューナの優先度に関連するステップと、
前記チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが前記要求しているコンシューマに割り振られないようにするステップであって、前記チューナの要求はチューナのコンフリクトがない場合に許可されるステップと、
前記チューナの要求に関連する前記チューナの優先度よりも低優先度の特定のチューナを前記コンシューマに提供することによって前記チューナについての要求を解決するステップであって、前記特定のチューナの前記優先度が、前記チューナの要求に関連する前記チューナの優先度と等しいかそれよりも高い場合には、前記特定のチューナは前記コンシューマに割り振られないステップと
を含むことを特徴とするコンピュータプログラム。
【請求項１６】
前記中央サーバにおいてチューナの要求を受け取るステップは、さらに、
チューナの番組を録画する要求または録画バッファの要求を受け取るステップと、
チューナのライブ番組を見る要求またポーズバッファの要求を受け取るステップであって、チューナの番組を録画する要求が、チューナがライブ番組を見るのに使用されるよりも優先度が高いステップと、
チューナのデータサービスを使用する要求を受け取るステップであって、チューナのライブ番組を見る要求が、チューナがデータサービス用に使用されるよりも優先度が高いステップと、
チューナのピクチャインピクチャウィンドウの要求を受け取るステップであって、チューナのデータサービスを使用する要求が、チューナがピクチャインピクチャウィンドウ用に使用されるよりも優先度が高いステップ
のうちの少なくとも１つを含むことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１７】
前記要求がチューナのコンフリクトを引き起こすかどうかを判断するステップは、さらに、すべてのチューナがコンシューマによって使用されているかどうかを判断するステップであって、アイドル状態のチューナはコンシューマによって使用されておらず前記要求しているコンシューマへの割り振りが可能なステップ含むことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１８】
前記チューナに対する要求を解決するステップは、さらに、
他のコンシューマにメッセージをブロードキャストするステップであって、前記ブロードキャストメッセージにより、コンシューマが特定のチューナを使用中かを判断するステップと、
前記メッセージへの応答が受け取られなかった場合に、前記要求しているコンシューマに前記特定のチューナを割り振るステップと
を含むことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１９】
前記要求しているコンシューマはユーザであり、チューナがシステムの延期可能イベント用に使用されるコンピュータプログラムであって、前記システムの延期可能イベントを中断するステップと、前記チューナを前記要求しているコンシューマに割り振るステップとを含むことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項２０】
前記チューナの前記要求を解決するステップはさらに、コンシューマに、前記チューナの現在の優先度よりも高優先度のスケジュールされたイベントのため、チューナの使用が終了する可能性があることを通知するステップを含むことを特徴とする請求項１９に記載のコンピュータプログラム。
【請求項２１】
コンシューマが１つ以上のノードセットトップボックスを含み、サーバがソースから前記ノードセットトップボックスにコンテンツを配布し、前記中央サーバが前記中央サーバおよび前記１つ以上のノードセットトップボックスが使用する１つ以上のチューナを含むシステムにおいて、前記１つ以上のチューナを前記コンシューマに割り振る方法を実施するためのコンピュータプログラムであって、
前記方法を実施するためのコンピュータ実行可能命令を備えたコンピュータ可読媒体を含み、前記方法は、
コンシューマからチューナの要求を受け取るステップであって、前記チューナの要求がチューナのコンフリクトを発生させて、そのために前記要求しているコンシューマに割り振ることができる利用可能なチューナがないようにするステップと、
前記コンシューマに、
録画済みの番組をユーザに対して表示するステップであって、前記録画済みの番組を表示するのにチューナが必要とされず、前記チューナのコンフリクトが解決されるステップと、
スケジュールされたイベントを変更して、前記チューナの要求とのコンフリクトを生じている前記スケジュールされたイベントに関連する特定のチューナがもはや前記チューナの要求とコンフリクトしないようにするステップ
のうち少なくとも１つを選択させることで前記チューナの要求を解決するステップと、
前記特定のチューナを前記コンシューマに割り振るステップと
を含むことを特徴とするコンピュータプログラム。
【請求項２２】
コンシューマからチューナを受け取るステップは、さらに、
チューナの番組を録画する要求または録画バッファの要求を受け取るステップと、
チューナのライブ番組を見る要求またポーズバッファの要求を受け取るステップであって、チューナの番組を録画する要求が、チューナがライブ番組を見るのに使用されるよりも優先度が高いステップと、
チューナのデータサービスを使用する要求を受け取るステップであって、チューナのライブ番組を見る要求が、チューナがデータサービス用に使用されるよりも優先度が高いステップと、
チューナのピクチャインピクチャウィンドウの要求を受け取るステップであって、チューナのデータサービスを使用する要求が、チューナがピクチャインピクチャウィンドウ用に使用されるよりも優先度が高いステップ
のうち少なくとも１つを含むことを特徴とする請求項２１に記載のコンピュータプログラム。
【請求項２３】
スケジュールされたイベントを変更するステップは、さらに、
スケジュールされたイベントを再スケジュールして、前記スケジュールされたイベント用に使用されている前記特定のチューナが、もはや前記チューナの要求とコンフリクトしないようにするステップと、
スケジュールされたイベントを取り消して、前記スケジュールされたイベント用に使用されている前記特定のチューナが、もはや前記チューナの要求とコンフリクトしないようにするステップと
を含むことを特徴とする請求項２１に記載のコンピュータプログラム。
【請求項２４】
前記チューナの要求を解決するステップは、さらに、
他のコンシューマにメッセージをブロードキャストして、コンシューマが特定のチューナを使用中かを判断するステップと、
前記メッセージへの応答が受け取られなかった場合に、前記要求しているコンシューマに前記特定のチューナを割り振るステップと
を含むことを特徴とする請求項２１に記載のコンピュータプログラム。
【請求項２５】
前記チューナの要求を解決するステップはさらに、特定のチューナが前記チューナの要求に関連する優先度よりも低優先度の場合には、前記特定のチューナを前記要求しているコンシューマに割り振るステップを含むことを特徴とする請求項２２に記載のコンピュータプログラム。
【請求項２６】
前記チューナの要求を解決するステップはさらに、特定のチューナの使用が終了したときにチューナの優先度を下げることによって、前記チューナのコンフリクトを防ぐステップを含むことを特徴とする請求項２１に記載のコンピュータプログラム。
【請求項２７】
前記チューナのコンフリクトを防ぐステップはさらに、前記チューナの使用が終了したときに、特定のチューナをアイドル状態に置くステップを含むことを特徴とする請求項２６に記載のコンピュータプログラム。
【請求項２８】
前記チューナの使用は、
番組を録画すること、
ブロードキャストメッセージへの応答を受け取らないこと、
セットトップボックスがスクリーンセーバモードに入っているときはユーザの応答を受け取らないこと
のうちの１つであることを特徴とする請求項２７に記載のコンピュータプログラム。
【請求項２９】
その中で分配されるチューナをコンシューマが使用し、ネットワーク中の前記コンシューマにソースからコンテンツを配信するために前記チューナが必要とされるネットワークにおいて、チューナをコンシューマに割り振る方法であって、
前記ネットワークにおけるチューナの使用を支配するルールに従って前記ネットワーク中のチューナをコンシューマに割り振るステップと、
コンシューマがチューナに、前記ネットワーク中で分配される前記チューナから要求を行った場合に、前記チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが前記要求しているコンシューマに割り振られないようにするステップであって、前記チューナの要求はチューナのコンフリクトがない場合に許可されて、そのためにチューナが前記要求しているコンシューマに割り振られるステップと、
前記チューナの要求に関連するチューナの優先度よりも低優先度の特定のチューナを前記コンシューマに割り振ることによって前記チューナのコンフリクトを解決するステップであって、前記特定のチューナの前記優先度が、前記チューナの要求に関連する前記チューナの優先度と等しいかそれよりも高い場合には、前記特定のチューナは前記コンシューマに割り振られないステップと
を含むことを特徴とする方法。
【請求項３０】
前記チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが前記要求しているコンシューマに割り振られないようにするステップは、さらに、
前記チューナの要求が、番組を録画する要求か録画バッファの要求かを判断するステップと、
前記チューナの要求が、ライブ番組を見る要求かポーズバッファの要求かを判断するステップであって、チューナの番組を録画する要求が、チューナがライブ番組を見るのに使用されるよりも優先度が高いステップと、
前記チューナの要求がデータサービスを使用する要求かを判断するステップであって、チューナのライブ番組を見る要求が、チューナがデータサービス用に使用されるよりも優先度が高いステップと、
前記チューナの要求がピクチャインピクチャウィンドウの要求かを判断するステップであって、チューナのデータサービスを使用する要求が、チューナがピクチャインピクチャウィンドウ用に使用されるよりも優先度が高いステップ
のうち少なくとも１つを含むことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが前記要求しているコンシューマに割り振られないようにするステップはさらに、すべてのチューナがコンシューマによって使用されているかどうかを判断するステップであって、アイドル状態のチューナはコンシューマによって使用されておらず、前記要求しているコンシューマへの割り振りが可能なステップを含むことを特徴とする請求項２９に記載の方法。
【請求項３２】
前記チューナのコンフリクトを解決するステップは、さらに、
他のコンシューマにメッセージをブロードキャストするステップであって、前記ブロードキャストメッセージにより、コンシューマが特定のチューナを使用中かを判断するステップと、
前記ブロードキャストメッセージへの応答が受け取られなかった場合に、前記要求しているコンシューマに前記特定のチューナを割り振るステップと
を含むことを特徴とする請求項２９に記載の方法。
【請求項３３】
前記要求しているコンシューマはユーザであり、チューナがシステムの延期可能イベント用に使用され、前記システムの延期可能イベントを中断するステップと、前記チューナを前記要求しているコンシューマに割り振るステップとを含むことを特徴とする請求項２９に記載の方法。
【請求項３４】
前記チューナのコンフリクトを解決するステップはさらに、コンシューマに、前記チューナの現在の優先度よりも高優先度のスケジュールされたイベントのため、チューナの使用が終了する可能性があることを通知するステップを含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
前記ネットワーク中の各セットトップボックスは、ブロードキャストメッセージに対してどのユーザも応答しなかった場合にデフォルトとしてどのチューナが取られるかを判定する優先度を持っていることを特徴とする請求項２９に記載の方法。
【請求項３６】
前記ルールは、
各ライブテレビイベントについて別個のチューナを割り振ること、
各録画イベントについて別個のチューナを割り振ること、
コンシューマがポーズバッファを共用しないように、各ポーズバッファについて別個のチューナを割り振ること、
コンシューマが録画バッファを共用しないように、各録画バッファについて別個のチューナを割り振ること、
録画イベントを開始するコンシューマが前記録画イベント用の録画バッファに戻ることを可能にすること、
それが録画されている間に別のコンシューマが見ているときには録画イベントを終了させないようにすることであって、それが録画されている間に１人のコンシューマしか見ていない場合には前記録画イベントを終了することができること、
他のコンシューマにメッセージをブロードキャストしてチューナが使用中かを判断するステップであって、前記メッセージに応答しないコンシューマに割り振られている前記チューナから少なくとも１つが、前記要求しているコンシューマのために取られること、
チューナの優先度に従ってチューナを取ること、
前記要求しているコンシューマに、利用可能なチューナがないことを知らせること
のうちの１つ以上を含むことを特徴とする請求項２９に記載の方法。
【請求項３７】
その中で分配されるチューナをコンシューマが使用し、ネットワーク中のコンシューマにソースからコンテンツを配信するためにチューナが必要とされるネットワークにおいて、チューナの使用に応じてチューナを割り振る方法であって、
チューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが要求しているコンシューマに割り振られないようにするステップであって、チューナの要求はチューナのコンフリクトがない場合にルールエンジンが管理するルールに従って許可され、前記ルールが、
各イベントに別個のチューナを割り当てること、各ポーズバッファに別個のチューナを割り当てること、および、各録画バッファに別個のチューナを割り当てることを含むステップと、
コンフリクトがない場合にはルールエンジンが前記ルールに従ってチューナを割り振るステップであって、どのコンシューマも、ブロードキャストを受け取ることなくチューナを失うことがなく、さらに、チューナを失う前記コンシューマがチューナの優先度に従って判定されるステップと
を含むことを特徴とする方法。
【請求項３８】
第１のコンシューマおよび第２のコンシューマが異なるセットトップボックスを使って同じイベントを見ており、前記ルールは、前記第１のコンシューマにポーズバッファ用の第１のチューナを割り当てることと、前記第２のコンシューマに別個のポーズバッファ用の第２のチューナを割り当てることを含むこと特徴とする請求項３７に記載の方法。
【請求項３９】
前記ルールはさらに、ライブテレビイベントを録画するため、および前記ライブテレビイベントを見るためにコンシューマがチューナを使用できるようにすることを含み、この場合、前記コンシューマがチューナを必要とする別の機能を実行することを望む場合には、前記コンシューマが別のチューナを必要とすることを特徴とする請求項３７に記載の方法。
【請求項４０】
前記チューナは、イベントの録画用に使用される場合にはスケジューラによってコントロールされることを特徴とする請求項３９に記載の方法。
【請求項４１】
録画イベントは別のコンシューマによって中断されることがないことを特徴とする請求項３７に記載の方法。
【請求項４２】
要求しているコンシューマのためにチューナを取得することを試みるメッセージをブロードキャストするステップをさらに含むことを特徴とする請求項３７に記載の方法。
【請求項４３】
最下位優先度のチューナが前記要求しているコンシューマに再割り振りされるように、前記要求しているコンシューマのためにチューナの優先度に従ってチューナを取るステップをさらに含むことを特徴とする請求項３７に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散システムにおけるチューナリソースの割り振りに関する。本発明は、さらに、チューナリソースが分散システム中に分配される分散システムにおいて、チューナリソースを割り振るためのシステム、方法、およびコンピュータプログラム（ｃｏｍｐｕｔｅｒ　ｐｒｏｇｒａｍ　ｐｒｏｄｕｃｔｓ）に関し、より詳細には、チューナリソースが中央サーバに常駐している場合のチューナリソースの割り振りに関する。
【０００２】
【従来の技術】
衛星およびケーブルテレビシステムなど、オーディオ／ビデオ（ＡＶ）コンテンツを配信するシステムの利点の１つは、数が増えつつあるチャネルおよび選択対象をユーザに配信できることである。また、デジタル衛星システムおよびケーブルテレビシステムは、ユーザが選択することができる何百ものテレビチャネルを提供する。ＡＶコンテンツの配信に加えて、これらのシステムは、コンピュータまたはその他の処理装置に記憶することができる他のタイプのコンテンツまたはデータを配信することもできる。
【０００３】
しかし、様々なタイプのコンテンツを受け取るためには、ユーザが適切なチャネルに合わせることが要求される場合がある。実際、衛星およびケーブルシステムを介して受け取るコンテンツの多くは、チューナを必要とする。したがって、チューナは、様々なソースからコンテンツを検索する際に不可欠な役割を果たすため、重要なリソースである。例えば、ライブテレビを見るためにはチューナが必要である。ユーザがピクチャインピクチャ（ＰＩＰ）機能を所望する場合は、一般にＰＩＰウィンドウ用の第２のチューナが必要とされる。テレビ番組を録画することは、チューナを必要とする別の機能である。ガイドデータなどのコンテンツを検索する、またはソフトウェアのアップデート版を受け取るなどのその他の機能も、チューナを必要とすることがある。
【０００４】
ユーザが同時にいくつかの動作を行うことができるかどうかは、ユーザが利用可能なチューナの数によって限定されることが多い。１つのチューナしか備えていないシステムの場合、ユーザが前に録画済みの番組を見ることが可能であったとしても、一度に１つの番組またはチャネルに合わせることしかできない。１つのチューナしか備えていないシステムが番組を録画している場合、ユーザが録画を終了しない限り、そのチューナを別の目的で使用することはできない。２つのチューナを備えているシステムは、ユーザにとってはよりフレキシブルである。この場合、ユーザは、第１のチューナを使ってある番組を録画し、第２のチューナを使って別の番組を見ることができる。あるいは、ユーザは、同時に２つの番組を録画することができる。
【０００５】
システムによっては、コンテンツをゲートウェイまたは中央サーバにおいて受け取り、次いで様々なノードに配布するものもある。チューナはゲートウェイや中央サーバに配置されることが多く、また、チューナの数は限定されるので、コンテンツの検索のためにチューナが頻繁に使用されて、チューナのコンフリクトが生じる可能性がある。チューナを必要とするコンシューマの間におけるチューナのコンフリクトまたは競合は避けられない。
【０００６】
【発明が解決しようとする課題】
ユーザから見た場合、以下のシナリオが、チューナの使用に関して発生し得るコンフリクトのいくつかを説明する。あるシナリオでは、ユーザが、テレビ番組を見ること、またはテレビ番組を録画することを望んでいるが、利用可能なチューナがない。この状況では、ユーザは、このコンフリクトを解決できない限り、テレビを見ることもテレビ番組を録画することもできない。別のシナリオでは、ユーザがテレビを見ており、かつ、別のユーザまたはシステムがチューナを要求している。この要求しているコンシューマにチューナを提供するために、テレビを見ているユーザに中断させることは望ましくない。したがって、このコンフリクトを解決する必要がある。
【０００７】
あるいは、ユーザがテレビを見ることを望んでいるが、テレビチャネルに合わせるためにすべてのチューナが使用されていることがある。しかし、システムは、それらのチューナによって合わせてあるチャネルを実際に誰かが見ているかどうかを判断することはできない。この場合、チューナは利用可能であり得るが、それを確かめることは難しい。チューナのコンフリクトに関するその他のシナリオも発生し得る。しかし、これらのシステムの制限ファクターは、一般に、チューナのコンシューマの数が分散システムにおいて利用可能なチューナの数よりも多いことである。これらのシステムは、チューナリソースに大きく依存しているため、チューナリソースは不足リソースであり、チューナのコンフリクトは、予想可能に解決する必要がある。
【０００８】
【課題を解決するための手段】
本発明は、従来技術の限界を認識し、また、チューナリソースを割り振るためのシステム、方法、及びコンピュータプログラムの必要を認識するものである。ソースからのコンテンツが中央サーバを通して受け取られ、また、チューナが主として中央サーバに常駐しているネットワークまたはシステムにおいては、一般に、チューナを必要とするコンシューマの数が中央サーバ上または分散システム中において利用可能なチューナの数よりも多いため、チューナが不足リソースとなってチューナの使用に関するコンフリクトが発生する可能性がある。本発明は、チューナがすべて中央サーバに配置されているわけではなく、システムまたはネットワーク全体に分散されている状況にも適用される。
【０００９】
システムまたは中央サーバは、特定の数のビデオストリーム（チューナの数に等しい）が同時に使用できることしか保証できない。潜在的なチューナのコンフリクトのため、中央サーバは、チューナルールおよびチューナの優先度を実施するチューナアービタを使ってコンフリクトを管理し、コンシューマにチューナを割り振る。チューナの要求が受信されてチューナのコンフリクトが発生すると、チューナアービタは、これらのルールおよび優先度に従ってチューナのそのコンフリクトを予想可能に解決する。
【００１０】
本発明によれば、以下のルールおよび優先度が適用される。各ライブテレビイベント（ｌｉｖｅ　ｔｅｌｅｖｉｓｉｏｎ　ｅｖｅｎｔ）は、２人のユーザが異なるセットトップボックスによって同じ番組を見ているときにも１つのチューナを必要とする。同様に、各録画イベントも１つのチューナを必要とする。
【００１１】
一般に、ライブテレビイベントを一時的に録画するのに使用されるポーズバッファは、ユーザ間で共用されない。ポーズバッファが共用された場合には、あるユーザがテレビを見ていられることが、別のユーザがチャネルを変えたときに中断される可能性がある。ビデオストリームを録画するために使用される録画バッファは、潜在的なチューナのコンフリクトをもたらさない限定された状況において共用される。
【００１２】
あるコンシューマがチューナを要求し、あるチューナが利用可能な場合、その要求しているコンシューマにそのチューナが割り振られる。コンフリクトがある場合には、その分散システムまたは中央サーバのチューナアービタが、そのコンフリクトを解決する。各チューナは、部分的にそれがどのように使用されるかによって決定される特定の優先度を持っている。例えば、番組を録画するチューナは優先度が高く、一方、アイドル状態のチューナは優先度が低い。チューナのコンフリクトの解決は、チューナ間の相対的優先度とチューナ要求に関連するチューナの優先度に依存する。場合によっては、コンシューマが、相対的優先度によってチューナを失うこともあり得る。
【００１３】
ルールおよび／または優先度に基づいてチューナを割り振ることに加えて、本発明は、ユーザにオプションまたは選択対象を提供することによってコンフリクトを解決する。チューナが使用不能であって、優先度に基づいて割り振ることができない場合、現在のチューナの使用（ｕｓａｇｅ）を変更するオプションがユーザに与えられる。例えば、現在、録画中のスケジュールされていたイベントを、要求しているユーザがそのチューナを使用できるように再スケジュールすることができる。チューナを解放するその他のオプションも、ユーザに提供することができる。
【００１４】
本発明はまた、チューナのコンフリクトを、それが発生する前に防ぐことを試みる。これは、チューナの優先度を積極的にモニタすることによって、また可能な場合にはそれらの優先度を下げることによって行われる。例えば、ビデオストリームを録画するために使用されるチューナの優先度を、その録画が終了したときに下げる。したがって、チューナのコンフリクトを防ぐことは本発明の別の態様であり、チューナリソースをコンシューマに割り振ることの一部である。
【００１５】
本発明のさらなる特徴および利点を以下の説明に記載する。その一部はその説明から明らかになるであろうし、または本発明の実施によって理解されるであろう。本発明の特徴および利点は、頭記の特許請求の範囲で特に指摘している手段および組み合わせによって実現し、得ることができる。本発明のこれらおよびその他の特徴は、以下の説明および頭記の特許請求の範囲からより完全に明らかになるであろう。あるいは、以下に記載する本発明を実施することにより理解することができよう。
【００１６】
本発明の上記およびその他の利点および特徴を得ることができる方法を説明するために、上記に簡単に説明した本発明を、添付の図面において例示しているその特定の実施形態を参照することによって、より詳細に説明する。これらの図面が本発明の代表的な実施形態を示すものにすぎず、したがって、その範囲を限定するものとみなされるべきものではないという理解のもとに、本発明を、添付の図面を使用することによって、さらなる特定性および詳細をもって記載し、説明する。
【００１７】
【発明の実施の形態】
本発明は、分散システムまたはネットワークにおけるチューナリソースの割り振りに関する。これらのシステムまたはネットワークでは、一般に、チューナリソースを使用または必要とするコンシューマの数が、割り振りに使用できるチューナの数よりも多く、特に、チューナが中央サーバまたはセットトップボックスに常駐している場合にはそれが言える。本発明は、チューナをコンシューマに割り振り、チューナの使用およびチューナの要求に関して発生するコンフリクトを解決する。これらのチューナは予想可能に割り振られ、それによって、コンシューマが、予め警告を受けることなしに、またはチューナの放棄を依頼されることなしに、チューナのコントロールを失うことがないようにする。本発明はスケーラブルであり、システムまたはネットワーク中に常駐する任意の数のチューナに適合させることができる。
【００１８】
本発明の利点の１つは、ユーザがチューナをコントロールしているときに、予めユーザに警告せずに、またはそのチューナをユーザに請求することなしに、ユーザからそのチューナを取るようなことはないという点である。本発明はまた、例えば、場合によっては再スケジュールしてもらうことによって、あるいは、番組の録画のためにチューナが要求された場合に、ユーザにそのチューナが使用できない可能性があることを知らせることによって、スケジュールされた録画が行われることを奨励する。本発明はまた、コンシューマが実際にチューナを使用しているかどうかの判断を試みることによって、チューナのコンフリクトを防ぐことを試みる。最後に、ユーザは、別のユーザにチューナの放棄を強制することはできない。
【００１９】
以下の説明では、次の用語を適用する。コンシューマとは、チューナリソースを使用するエンティティを指し、ユーザ、セットトップボックス、スケジューラなどを非限定的に含む。チューナまたはチューナリソースは、ソースからコンテンツまたはデータを検索または受け取るために使用され、これには、衛星システム、特定の衛星トランスポンダまたはケーブルシステムが非限定的に含まれる。ポーズバッファは、テレビ番組など、現在のイベントを一時的に記憶するために使用される。ポーズバッファは、録画されていないイベントのために使用され、ポーズバッファに関連するチューナはユーザがコントロールする。録画バッファは、現在録画中のイベントのためのバッファであり、録画バッファに関連するチューナはスケジューラがコントロールする。ユーザが録画済みの番組を見たい場合は、チューナは必要とされない。テレビウィンドウは、フルスクリーンウィンドウ、中型スクリーンウィンドウ、ピクチャインピクチャ（ＰＩＰ）ウィンドウなどにすることができる。スケジューラは、録画イベントを含めて、イベントの保持および管理を行うコンポーネントである。
【００２０】
図１は、本発明を実施するための例示的環境を示す。図１は、ネットワーク１１０に接続されているソース１００を示す。例示的ソースには、衛星システム１０２、ケーブルシステム１０４、およびインターネット１０６が非限定的に含まれる。ソース１００から入手可能なコンテンツまたはデータには、オーディオ／ビデオデータ、ビデオストリーム、テキスト、ガイドデータ、サービス、ソフトウェアのアップデート版、広告、画像データ、その他のデータなど、またはそれらのいずれかの組み合わせが非限定的に含まれる。
【００２１】
図１に示すネットワーク１１０は、例えば、中央サーバ１２０、および１つまたは複数のノードセットトップボックス１１４、１１６、１１８を含む。中央サーバ１２０は、しばしば、ネットワーク１１０とソース１００の間のゲートウェイとして機能する。したがって、特定のノードセットトップボックスまたは中央サーバに宛てられたコンテンツまたはデータは、一般に、中央サーバ１２０を通る。しかし、場合によっては、ノードセットトップボックスは、ソース１００に直接アクセスできることもある。例えば、セットトップボックス１１４が、インターネット１０６に別個に接続している場合もある。
【００２２】
セットトップボックスは、コンテンツを受け取り、送り、処理することができる例示的コンピューティング環境である。例示的セットトップボックスには、デジタルビデオレコーダ（ＤＶＲ）、衛星受信機、インターネット端末、ケーブルボックス、デジタル衛星システム（ＤＳＳ）、コンピュータなど、およびそれらの組み合わせが非制限的に含まれる。中央サーバ１２０は、例えば、ネットワーク１１０のサーバコンピュータとして機能することもできる。ノードセットトップボックス１１４、１１６、１１８に配信されるコンテンツまたはデータの多くは、中央サーバ１２０が配布および配信する。
【００２３】
図２は、例えば、それらの潜在的コンシューマに割り振られる、または分配される中央サーバのいくつかの例示的リソースを示す。特に、図２に示す中央サーバ１２０は、チューナ１２２、チューナ１２４、およびチューナ１２６として示してあるチューナリソースを含む。中央サーバ１２０は、任意の数のチューナを含むことができることを理解されよう。これらのチューナは、中央サーバ１２０に集約されており、図１に示すどのノードセットトップボックスでもそれらを使用することができる。ノードセットトップボックスまたは中央サーバのいずれかがチューナを使用する場合、そのチューナは、そのセットトップボックスに分配される、または割り振られる。もちろん、これによって、ノードセットトップボックスがそれ自身のチューナを備えることができないわけではない。しかし、この例では、ネットワーク１１０（図１の）のチューナリソースは、中央サーバ１２０上に常駐している。本発明は、中央サーバ１２０に加えて、ネットワーク１１０上の様々なセットトップボックスにチューナが配置されているネットワークにも適用することができる。
【００２４】
図２はまた、中央サーバのリソースの例示的コンシューマ、ユーザ１２８、ユーザ１３０、ユーザ１３２、ＰＩＰ１３４、およびスケジューラ１４０も示す。ユーザ１２８、１３０、１３２は、チューナリソースを必要とする特定の機能のためにノードセットトップボックスを使用しているユーザである。ＰＩＰ１３４は、ユーザの１人に対して表示され、チューナリソースを必要とする別個のウィンドウである。スケジューラ１４０は、ネットワークのイベントのスケジュールおよび管理を行うコンポーネントである。この例では、スケジューラ１４０は、合わせた、スケジュールされたイベントを録画することができる。この例では３つのチューナを示しているため、スケジューラ１４０は、録画１４２、録画１４４、録画１４６として示す、３つの同時録画イベントをコントロールすることができる。
【００２５】
図２は、潜在的コンシューマの数が中央サーバ１２０のチューナの数よりも多いことを示す。前に述べたように、中央サーバ１２０のチューナリソースを多数の様々な目的に使用することができる。これには、非限定的に、テレビ番組のオーディオ／ビデオデータを検索すること、ソースからサービス（映画データ、株価、スポーツの得点など）を受け取ること、ソースからソフトウェアのアップデート版を検索すること、ユーザに対して表示される広告を受け取ること（これは、ユーザがチューナを使用していなそうな夜間に行われることが多い）、サテライトディッシュを調整すること、および、例えば、ネットワーク１１０を介してソース１００からアクセスできるテレビ番組を説明するガイドデータを受け取ることが含まれる。チューナが必要とされる機能のいくつかは延期可能なイベントである。例えば、ソフトウェアのアップデート版を受け取ること、または新しいガイドデータを受け取ることは、場合によっては延期が可能である。
【００２６】
図３は、チューナリソースの使用（ｕｓａｇｅ）または機能のいくつかを例示したものであり、また、ポーズバッファと録画バッファの違いを示したものである。例えば、セットトップボックス３０６のユーザがライブまたは現在のテレビ番組を見ている場合、ディスプレイ装置３０８にはビデオが表示される。現在のテレビ番組にはチューナが必要とされ、この例では、チューナ３００が、ユーザが選択したチャネルおよび番組に合わせてある。ユーザがその番組を録画している場合には、録画バッファ３０４を使用して番組を録画する。録画中、チューナ３００は、図２のスケジューラ１４０によってコントロールされている。録画は、中央サーバまたはノードセットトップボックスのいずれかに記憶される。ユーザが番組を録画していない場合には、同様にポーズバッファ３０２を使用して番組を録画する。ポーズバッファは一時的なものであり、例えばユーザがチャネルを変える度に、新しいポーズバッファが開始する。チューナ３００がポーズバッファ３０２を使っている場合は、ユーザがチューナ３００をコントロールする。
【００２７】
図４は、例示的チューナの優先度リスト４００を示す。優先度リスト４００を使って、特定のチューナの優先度レベルを決定する。優先度リスト４００はまた、チューナの要求に関連する優先度レベルを識別するためにも使用される。したがって、優先度リスト４００は、チューナの割り振りの際に使用される。例えば、優先度が低いチューナを、より高い優先度に関連するチューナの要求に割り振ることができる。録画に使用されるチューナ（４０１）は、優先度が最も高い。次のレベルの優先度は、ポーズバッファに書き込む、または関連付けられるチューナ（４０２）に割り当てられる。言い換えれば、ポーズバッファが使用されているので、ライブテレビを見るのに使用されるチューナの優先度は、このレベルである。ある例では、中央サーバのポーズバッファのために使用されるチューナは、ノードセットトップボックスのためのポーズバッファに書き込むチューナよりも優先度が高い。あるいは、２つ以上のポーズバッファがある場合には、一番最近のユーザの入力に関連するチューナの優先度が最も高い。
【００２８】
データサービスに使用されるチューナ（４０３）は、次の優先度を持っている。データサービスは、一般に、特定のタイプのデータをユーザに提供し、そのデータにアクセスして検索するためにチューナが必要となる。例えば、映画サービスは、映画関連のデータをユーザに提供することができる。その他のデータサービスには、ソフトウェアのアップデート版、ユーザプロファイルデータなどが、非限定的に含まれる。データサービスによってはリアルタイムデータを提供するものもあり、これらのサービスは、その他のデータサービスよりも優先度が高い。ノードセットトップボックスにおいて発生するデータサービスと、中央サーバにおいて発生するデータサービスの間に何も違いはない。前述したように、多くのデータサービスは延期可能イベントである。しかし、イベントによっては、延期不可能であって、高優先度イベントにさえ優先するものもある。例えば、セットトップボックスからフィードが取り除かれると、中央サーバによってチューナが取り去られる。
【００２９】
次のレベルの優先度は、チューナがＰＩＰウィンドウのためのポーズバッファに書き込む場合である。この場合、ユーザは２つのチューナをコントロールすることができる。１つは通常のウィンドウのためのチューナ、もう１つはＰＩＰウィンドウのためのチューナである。他の用途でチューナが必要になった場合、優先順位リスト４００で優先度が比較的低いため、ＰＩＰチューナが取られる。最下位優先度は、アイドル状態のチューナ（４０５）に割り当てられる。明らかに、アイドル状態のチューナはどのような要求にも利用可能であり、そのときには、チューナの使用（ｕｓａｇｅ）に基づいてより高い優先度が与えられる。
【００３０】
チューナがコンシューマによって要求されたとき、および／またはコンシューマに割り振られたときに、チューナの優先度レベルが決定される。最下位優先度のチューナが、要求しているコンシューマに再割り振りされる可能性がある候補者である。しかし、コンシューマの要求の優先度レベルおよび要求しているコンシューマの識別（例えば、ユーザかシステムか）も考慮されるため、そのチューナが常に再割り振りされるとは限らない。
【００３１】
図５は、チューナリソースを必要とすることがある様々なコンシューマに、チューナリソースを割り振る、または分配する、チューナアービタを示す構成図である。チューナアービタ５００は、ルールエンジン５０２を利用して、チューナ１２２、１２４、１２６を様々なコンシューマに割り振る責任を負っている。ルールエンジン５０２は、チューナアービタ５００がチューナリソースに対するコンフリクトを解決することを可能にする、ルールを実施する。ルールエンジン５０２も、チューナのコンフリクトを解決する際に優先度リスト４００を考慮する。
【００３２】
中央サーバ１２０の各チューナは、関連するチューナドライバを備えている。当業者であれば、その他のドライバの実装も可能であることを認識されよう。この実施形態において、この例では、チューナドライバ１２１がチューナ１２２をコントロールし、チューナドライバ１２３がチューナ１２４をコントロールし、チューナドライバ１２５がチューナ１２６をコントロールする。各チューナドライバは、一般に、チューナの状態（アイドル、使用中、ポーズバッファに、録画バッファに、など）、チャネル、スケジューラによる録画などを非制限的に含めて、情報を保持している。このチューナ情報を使って、例えば、チューナの優先度レベルを決定、または現在のチューナの使用を判断することができる。チューナアービタ５００は、例えば、チューナが、番組の録画のため、テレビを見るため、データサービスを受け取るため、またはその他の機能のために使用されているかどうかを判断することができる。したがって、チューナの特定のアクティビティは、他のコンシューマからのチューナの要求に対して影響力を持っている。一般に、チューナの要求よりも優先度が高いチューナは、取られることはない。例えば、番組を録画するために使用されているチューナが、ユーザがライブテレビを見ることを可能にするために取られることはない。
【００３３】
ルールエンジン５０２はまた、部分的に、以下の原則またはルールにも基づいている。各原理またはルールを、図１および図４に関して説明する。チューナの要求の解決、およびチューナリソースの割振りは、以下に説明するルールおよび／または前述のチューナの優先度を使って行われる。以下に説明する各状況において、チューナは、前述したように、対応する優先度レベルを備えている。チューナの要求を受け取ると、システムまたは中央サーバは、そのチューナの要求がチューナのコンフリクトを引き起こすかどうかを判断して、チューナが割り振られないようにする。チューナのコンフリクトが発生すると判断された場合には、そのチューナのコンフリクトを解決する際に下記のルールが使用される。
【００３４】
各ライブテレビイベントまたは番組は、単一のチューナを必要とする。例えば、あるユーザがセットトップボックス１１４で番組を見ており、別のユーザがセットトップボックス１１６で同じ番組を見ている。各ユーザは、中央サーバ１２０のチューナアービタ５００によって割り振られた別個のチューナを使っている。前に録画済みの番組を見る場合はチューナリソースが必要ではないため、この例は、見ている番組が前に録画済みの番組ではないことも前提としている。チューナがライブテレビイベントのために使用されている場合、そのチューナはポーズバッファへの書込みを行っており、対応する優先度レベルを備えている。
【００３５】
各録画イベントも単一のチューナを必要とする。例えば、ユーザが、セットトップボックス１１４によって録画されるように番組をスケジュールする。番組が録画されている場合に、ユーザがその番組を見たい場合は、追加チューナが必要である。言い換えれば、ユーザがセットトップボックス１１４上のその番組を見ている場合には、中央サーバの２つのチューナが使用されている。番組を録画するために使用されているチューナはスケジューラがコントロールし、もう一方のライブテレビを見るために使用されているチューナはユーザがコントロールする。録画イベントのために使用されるチューナも、前述のように優先度レベルを備えている。
【００３６】
録画バッファは、一般に、共用されない。この場合の例外は、ユーザがあるチャネルに合わせて、そのチャネルの録画を開始する場合である。ユーザがそのチャネルの録画を開始すると、チューナのコントロールがユーザからスケジューラに移る。ユーザがその録画されているチャネルを見続けている限り、同じチューナが使用される。しかし、ユーザがチャネルを変えることを望む場合は、この例では、スケジューラが録画に使用されているチューナをコントロールしているため、また、録画イベントはライブテレビを見るために使用されるチューナよりも優先度が高いため、第２のチューナが必要とされる。別のチューナが使用不能な場合には、チューナアービタが、ルールエンジン５０２および優先順位リスト４００を参照してそのコンフリクトを解決する。
【００３７】
ユーザが、録画されている番組を見ていて、チャネルを変え、次に、録画されているチャネルまたは番組に戻ることを望む場合には、録画バッファを使用することができる。チャネルまたは番組がもはや録画されていない場合は、ユーザは録画バッファではなくポーズバッファを使用する。録画が終了したときにスケジューラが放棄したチューナのコントロールが、再びユーザに移る。別のセットトップボックスのユーザが、第１のユーザが録画しているチャネルまたは番組を見ることを望む場合、そのユーザは、録画バッファを使用することはできず、自分自身のチューナが必要となる。
【００３８】
ポーズバッファは、ユーザ間で共用されない。異なるセットトップボックスで同じチャネルまたは番組にダイヤルを合わせている２人のユーザは、同じポーズバッファを共用しない。ポーズバッファを共用しない理由の１つは、チューナの予想可能性とコントロールに関する。例えば、中央サーバ１２０が、セットトップボックス１１４、１１６の２人のユーザが同じ番組を見ていることを検出したと仮定する。したがって、中央サーバ１２０は、これらのユーザにチューナおよび対応するポーズバッファを共用させることを決める。放棄されたチューナを別のコンシューマに再割り振りし、中央サーバ１２０の残りのチューナリソースは使用中である。ポーズバッファを別のユーザと共用しているユーザが別の番組に変えることを決めると、両方のユーザの番組が中断されないようにするために、追加チューナの必要が生じる。他のチューナはどれもアイドル状態ではないため、一方のユーザが番組を見続けることができなくなる。未知のユーザによる行動の結果としてコンフリクトが生じるのは望ましくなく、回避されるべきである。この理由から、ポーズバッファは共用されない。
【００３９】
録画は、別のユーザがその録画を見ている場合には、停止または削除することはできない。しかし、録画されているときに、その録画をたった１人のユーザしか見ていない場合には、その録画を停止および／または削除することができる。
【００４０】
コンシューマのチューナの要求またはその他のイベントに応答して、コンフリクトがチューナアービタによって検出された場合には、そのコンフリクトがブロードキャストメッセージを送らずに解決できる場合を除き、ノードセットトップボックスにブロードキャストメッセージが送られる。ブロードキャストメッセージは、ユーザがチューナを解放する方法で応答するとすぐに消える。例えば、ブロードキャストメッセージによってあるユーザが録画を終了すると、チューナが解放されて、要求しているコンシューマが使用できるようになる。ブロードキャストメッセージにどのユーザも応答しない場合、システムは、最下位優先度のチューナを取ることができる。これらのルールおよびチューナの優先度リストは、ルールエンジン５０２またはチューナアービタ５００がチューナのコンフリクトを解決するために使用する。
【００４１】
ユーザは、コンフリクトの解決またはその他の理由でチューナを失っても、一般に、同じアプリケーションの中に留まっている。例えば、あるユーザが、チューナが取られたときにガイドデータを見ていた場合、そのユーザはガイドデータアプリケーションの中に留まっており、現在、どのチューナも使用不能であることを示すメッセージが現れる。
【００４２】
通常、チューナは、チューナの要求が現在のチューナの使用よりも優先度が高い場合にのみ、既存のユーザから取り去られる。しかし、チューナの再割り振りが行われる場合もある。例えば、ユーザがブロードキャストメッセージに応答しなかった場合、あるいは、ユーザの現在のチューナの使用がＰＩＰウィンドウのためである場合、要求しているユーザにチューナが再割り振りされることがある。チューナがＰＩＰウィンドウのために使用されており、現在のユーザがポーズバッファを録画バッファとして捉えたいという場合には、このチューナの再割り振りによって、録画が時期尚早に終了されることがある。一貫性を推進するために、チューナの再割り振りは、一般に、ユーザがブロードキャストメッセージに応答しなかった場合にのみ行われる。このアプローチによって、悪影響を受けるユーザは実際にチューナを使っていないユーザであり、また、チューナが取られるユーザは、単にチューナを放棄しなかっただけであることが保証される。
【００４３】
チューナの優先度の決定の別の態様は、どのユーザに対しても妨害または照会することなく、チューナのコンフリクトを回避または解決することである。したがって、本発明は、ある状況においてはチューナの優先度を変更することによって、チューナのコンフリクトをそれらが発生する前に解決することを試みる。
【００４４】
ユーザが依然としてチューナを必要としているかどうかを判断または検出することが難しい場合がある。例えば、ノードセットトップボックスでテレビ番組を見ているユーザが、単にそのセットトップボックスをオフにせずに席を立ったというだけの場合、ノードセットトップボックスも中央サーバもそのチューナが利用可能であることがわからない。チューナアービタまたは中央サーバから見ると、ユーザがそこには居ないにもかかわらず、チューナが依然としてユーザに使用されているように見える。
【００４５】
コンシューマまたはユーザが依然としてチューナを使用しているかどうかの判断は、アイドル時間を設定することによって行うことができる。アイドル時間内にセットトップボックスへのユーザの入力（チャネルの変更など）が何もなかった場合に、チューナの状態を自動的にアイドル状態に設定することができる。アイドル時間はユーザが定義できる。セットトップボックスは、アイドル時間が終了すると、チューナが使用中ではないことを確認するメッセージをブロードキャストすることもできる。このブロードキャストメッセージは、問題のチューナリソースを使用しているセットトップボックスに特有のものであることが可能である。
【００４６】
チューナの状態を記憶するチューナドライバを使うことによって、チューナアービタ５００は、チューナの優先度に関してよりよい決定を下すことができる。例えば、以下の状況においては、チューナをアイドル状態にする、または放棄することができる。チューナは、録画を終了すると、優先度が最も低いアイドル状態になる。ユーザが、チューナを必要としない、録画済みの番組を見ることを決めると、ユーザが使っていたチューナもアイドル状態になる。セットトップボックスをオフにすると、チューナは放棄されてアイドル状態になる。アイドル状態のチューナは、コンシューマによる使用が可能である。これらおよびその他の状況においては、チューナの優先度を下げることによって将来のコンフリクトの可能性が低減される。
【００４７】
ユーザがライブテレビ番組を見ていないが、ガイドデータアプリケーションなど、チューナを必要とする可能性があるアプリケーションに居る状況においては、セットトップボックスはスクリーンセーバモードに入ることができる。セットトップボックスは、一般に、ライブテレビが表示されている場合にはスクリーンセーバモードが可能ではない。セットトップボックスがスクリーンセーバモードに入っている場合に、そのスクリーンセーバモードが特定の時間、中断されなかった場合、ユーザの入力がなければ、チューナは積極的に使用されていないとみなすのが妥当なため、チューナは放棄されてアイドル状態になる。一方、ユーザの入力は、ユーザが積極的にアプリケーションに関わっており、チューナを使用していることを表す。このような状況の場合、チューナの状態は、優先度が最も低く、コンシューマのチューナの要求に対して利用可能な、アイドル状態に設定される。
【００４８】
チューナは、利用可能な場合、要求しているコンシューマに自由に割り振ることができる。図６は、ユーザが利用可能なチューナがない場合、すなわちすべてのチューナが何かの機能のために使用されている場合に、チューナリソースを割り振るための例示的方法を示す。チューナの割り振りは、チューナの使用の優先度に関連し、コンフリクトは、部分的にそのチューナの優先度に基づいて解決される。チューナが使用不能であることは、使用されているチューナが、チューナの要求と同じまたはそれよりも高い優先度を持っていることを意味する。例えば、ライブテレビを見たいというユーザの要求によって、ライブテレビを見ている別のユーザからチューナが取り上げられることはない。しかし、ライブテレビのためのチューナの要求によって、延期可能イベントから、あるいは優先度がそれよりも低いチューナの使用から、チューナが取られる場合はある。
【００４９】
この場合、チューナは使用不能である。ユーザが、テレビを見るなど、チューナを必要とする目的でセットトップボックスを使い始めると、ユーザは、チューナが、現在、使用不能であることを知らされる（６００）。ユーザは、録画済みの番組またはショーを見る（６０１）か、またはユーザがチューナを入手できるようにするその他のオプション６０２を選ぶかの選択を与えられる。ユーザが録画済みの番組を見ることを選ぶと、チューナは必要とされず、コンフリクトは解決される。
【００５０】
ユーザがオプション６０２を選ぶと、最初に、現在録画している番組を再スケジュールするオプション（６０４）が提示される。このオプションは、一般に、中央サーバが番組を再スケジュールすることができる場合に提供される。この例では、セットトップボックスは、ガイドデータをサーチして、そのショーが別の日付および時刻に行われるかどうかを判断することができる。セットトップボックスが、例えば、その番組を再スケジュールすることができないと判断した場合には、ユーザには、現在の録画を取り消すオプション（６０６）が提示される。しかし、ユーザが録画を取り消すことができるかどうかは、前述のルールに左右される。
【００５１】
これらのオプションがチューナを解放しない場合、あるいは、これらのオプションが遂行されない場合には、ユーザが実際にチューナを使用しているかどうかを判断するために、その他のセットトップボックスを実際に調べるオプション（６０８）がユーザに提示されることがある。これは、その他のセットトップボックス上にメッセージをブロードキャストすることによって行われることが多い。その他のセットトップボックスを調べている間に、中央サーバは、チューナの状態に基づいて、チューナの使用を判断することができる。チューナが録画バッファに関連する場合には、番組が録画されており、チューナの優先度は高い。チューナがポーズバッファに関連する場合には、ユーザは、もし居るとすれば、テレビを見ている。
【００５２】
したがって、メッセージをブロードキャストすることによって、ユーザが実際にテレビを見ているかどうかという、チューナの状態からは判断できない行動が判断できる。この、その他のセットトップボックスへのブロードキャストメッセージは、ユーザがテレビを見ているかどうか、またはそうでない場合にはチューナを使っているかどうかを尋ねる。実際にユーザにブロードキャストされるメッセージは、ユーザがその質問を理解できない場合があるため、「あなたはチューナを使っていますか？」という形ではない。そうではなく、ユーザは、例えば、テレビを見ているかどうかという、暗にチューナを必要とすることを尋ねられる。したがって、このブロードキャストメッセージに対して応答がないということは、チューナがチューニングされていてポーズバッファへの書込みを行っている可能性があるが、ユーザが居ず、またチューナを使っていないことを示唆している。この状況においては、ユーザの応答を受け取らなかったチューナのコントロールが、チューナを要求しているユーザに与えられて、コンフリクトは解決される。利用可能なチューナがない場合には、ユーザは、一般に、利用可能なチューナがないという知らせを受ける。チューナが利用可能になったときにその旨を通知するという知らせを受ける場合もある。
【００５３】
別のタイプのチューナのコンフリクトは、システムがチューナを要求または必要とする場合に生じる。第１の例は、スケジューラが、スケジュールされている番組を録画するためにチューナを必要とする場合に発生する。録画のチューナは優先度が高い。この場合、システムは、スケジュールされている録画の間はチューナを使用することができなくなり、また、スケジューラがそのチューナを必要とするときには現在のチューナの使用が終了することをユーザに知らせる。
【００５４】
しかし、このシナリオで、システムは、ユーザにいくつかのオプションも提供する。ユーザは、スケジュール通りに番組を録画するか、あるいは録画を再スケジュールすることができる。再スケジュールを選択した場合は、スケジューラが番組を録音するためのチューナを必要としなくなるので、コンフリクトが取り除かれる。ユーザは、チューナをスケジューラに取られることがないと知りながらチューナを使い続けることができる。番組の再スケジュールができない場合には、録画を取り消すオプションがユーザに与えられる。ユーザが録画を取り消すことを決めた場合、チューナは利用可能なままであり、チューナのコントロールが放棄されてスケジューラに移ることはない。ユーザが取り消さない場合、または録画を再スケジュールする場合は、ユーザはチューナをスケジューラに取られ、スケジューラは、ユーザが現在コントロールしているチューナを使って（その間に別のチューナが利用可能にならない限り）、番組を録画することになる。
【００５５】
あるいは、システムはメッセージをブロードキャストして、チューナ（またはテレビ）が使用中かどうかを判断する。何人かのユーザから肯定の応答を受け取った場合、それらのチューナは使用不能のままである。チューナのユーザの１人から応答がなかった場合には、そのチューナが、要求しているコンシューマに割り振られる。場合によっては、システムが直ちにチューナを必要として、最下位優先度のチューナを取る。例えば、ボックスの背面から衛星フィードを取り除くと、チューナは、使用不能になり、取り上げられる。
【００５６】
別の状況は、システムが延期可能イベントのためにチューナを必要とする場合である。現在、利用可能なチューナがない場合、システムはチューナが利用可能になるまで待つ。これによって、ユーザが中断されないことが保証される。システムの延期可能イベントに使用されているチューナをユーザが要求する状況では、システムはチューナを取られて、チューナはユーザに割り振られる。しかし、ユーザの要求の優先度は、一般に延期可能イベントよりも高い。例えば、２つのチューナが録画に使用されており、一方のチューナがシステムの延期可能イベントに使用されていると想定する。ユーザがテレビを見るためにテレビをオンにすると、システムの延期可能イベントは中断されて、チューナは、ユーザがテレビを見るために割り振られる。システムの延期可能イベントは、通常、テレビを見るために使用されるチューナよりも優先度が低い。
【００５７】
チューナの優先度の決定およびチューナの割り振りに組み込むことができる別のファクターは、ネットワーク内のテレビの様々なセットトップボックスに優先度を割り当てることである。例えば、家庭では、主として使用されるセットトップボックスが最高位優先度を持ち、親のセットトップボックスが次に高い優先度を持つことがある。これを使って、例えば、どのセットトップボックスがブロードキャストメッセージを受け取るかを決め、あるいは、ブロードキャストメッセージに対して何も応答がなかった場合に、デフォルトとしてどのチューナを取るかを決めることができる。
【００５８】
図７は、チューナのコンフリクトを解決する別の例である。７００で、チューナの要求が中央サーバで受け取られる。７０２で、中央サーバまたはチューナアービタが、チューナのコンフリクトが存在しているかどうかを判断する。コンフリクトが存在しない場合は、要求しているコンシューマにチューナが割り振られる（７０４）。コンフリクトが存在する場合には、７１０で、そのコンフリクトが解決される。
【００５９】
チューナのコンフリクトを解決するには、チューナアービタが、現在のチューナの優先度および関連するチューナの使用を識別する必要がある。コンフリクトを解決するのに、この情報だけで十分なことがしばしばある。例えば、ライブテレビを見たいという要求は、ＰＩＰウィンドウのために使用されるチューナよりも優先度が高い。この場合、ＰＩＰウィンドウに使用されるチューナは、要求しているコンシューマに割り振られる。チューナのコンフリクトがチューナの優先度を使用しても解決できない場合には、前述のように、メッセージがブロードキャストされる（７１６）。要求しているコンシューマのためにコンフリクトがうまく解決された場合には、その要求しているコンシューマにチューナが割り振られる（７１８）。うまく解決されなかった場合には、要求しているコンシューマは、チューナが利用可能になるまで待たなければならない。
【００６０】
本発明は、分散システムにおいてチューナリソースを割り振るための方法およびシステムの両方を対象とする。本発明の実施形態は、下記に詳説するように、様々なコンピュータハードウェアを含めて、専用または汎用コンピュータを含むことができる。本明細書で説明しているセットトップボックスは、専用コンピュータの例である。
【００６１】
本発明の範囲内の実施形態はまた、記憶されたコンピュータ実行可能命令またはデータ構造を運ぶ、または備えるコンピュータ可読媒体も含む。このようなコンピュータ可読媒体は、汎用または専用コンピュータがアクセスできる任意の利用可能媒体であってよい。例として、このようなコンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶装置、あるいは、所望のプログラムコード手段をコンピュータ実行可能命令またはデータ構造の形で運ぶ、または記憶するために使用することができ、また、汎用または専用コンピュータがアクセスできる、いずれかのその他の媒体を非限定的に含めることができる。ネットワークまたは別の通信接続（ハードワイヤード、無線、あるいはハードワイヤードまたは無線の組み合わせのいずれか）を介して、情報がコンピュータに転送または提供される場合、コンピュータは、当然、その接続をコンピュータ可読媒体として見る。したがって、このような接続はどれも、正しくコンピュータ可読媒体と呼ばれる。上記の組み合わせも、コンピュータ可読媒体の範囲に含まれるべきものである。コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置に、特定の機能または機能グループを実行させる命令およびデータを含む。
【００６２】
図８および以下の説明は、本発明を実施することができる適切なコンピューティング環境を、簡単かつ一般的に記載することを意図している。必要とはしないが、本発明を、ネットワーク環境でコンピュータにより実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な状況において説明する。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書で開示している方法のステップを実行するためのプログラムコード手段の例を表す。このような実行可能命令または関連するデータ構造の特定のシーケンスは、このようなステップにおいて説明している機能を実施するための、対応する動作の例を表している。
【００６３】
当業者は、本発明を、多くのタイプのコンピュータシステム構成を使ったネットワークコンピューティング環境において実施できることを理解されよう。これには、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明はまた、通信ネットワークを介してリンクされている（ハードワイヤードリンク、無線リンク、あるいはハードワイヤードまたは無線リンクの組み合わせのいずれかによって）、ローカルおよびリモートの処理装置によってタスクが実行される、分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、プログラムモジュールを、ローカルおよびリモートの両方のメモリ記憶装置に配置することができる。
【００６４】
図８を参照すると、本発明を実施するための例示的システムは、処理装置２１、システムメモリ２２、およびシステムメモリ２２を含めて様々なシステムコンポーネントを処理装置２１に結合する、システムバス２３を含む、従来のコンピュータ２０という形の汎用コンピューティング装置を含む。システムバス２３は、様々なバスアーキテクチャのいずれかを使った、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、何種類かのバス構造のいずれかであってよい。システムメモリは、読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。スタートアップ時の間などに、コンピュータ２０内のエレメント間での情報の転送を手伝う基本ルーチンを含む、基本入出力システム（ＢＩＯＳ）２６は、ＲＯＭ２４に記憶することができる。
【００６５】
コンピュータ２０はまた、磁気ハードディスク３９からの読取りまたはそれへの書込みを行うための磁気ハードディスクドライブ２７、リムーバブル磁気ディスク２９からの読取りまたはそれへの書込みを行うための磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたはその他の光媒体などのリムーバブル光ディスク３１からの読取りまたはそれへの書込みを行うための光ディスクドライブ３０も含む。磁気ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ドライブインタフェース３４によって、システムバス２３に接続されている。ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ実行可能命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性記憶をコンピュータ２０に提供する。本明細書に記載の例示的環境は、磁気ハードディスク３９、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用しているが、磁気カセット、フラッシュメモリカード、ＤＶＤ（デジタル多用途ディスク）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含めて、データを記憶するためのその他のタイプのコンピュータ可読媒体を使用することができる。
【００６６】
１つ以上のプログラムモジュールを含むプログラムコード手段は、オペレーティングシステム３５、１つ以上のアプリケーションプログラム３６、その他のプログラムモジュール３７、およびプログラムデータ３８を含めて、ハードディスク３９、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に記憶することができる。ユーザは、キーボード４０、ポインティングデバイス４２、または、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどのその他の入力装置（図示せず）を通して、コンピュータ２０にコマンドおよび情報を入力することができる。これらおよびその他の入力装置は、システムバス２３に結合されたシリアルポートインタフェース４６を通して、処理装置２１に接続されることが多い。あるいは、入力装置を、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などのその他のインタフェースによって接続することもできる。モニタ４７または別のディスプレイ装置も、ビデオアダプタ４８などのインタフェースを介して、システムバス２３に接続される。モニタに加えて、パーソナルコンピュータは、一般に、スピーカおよびプリンタなど、その他の周辺出力装置（図示せず）を含む。
【００６７】
コンピュータ２０は、リモートコンピュータ４９ａ、４９ｂなどの１台または複数のリモートコンピュータへの論理接続を使って、ネットワーク化された環境で動作することができる。リモートコンピュータ４９ａ、４９ｂは、それぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の一般的なネットワークノードであってよく、図８にはメモリ記憶装置５０ａ、５０ｂ、およびそれらに関連するプリケーションプログラム３６ａ、３６ｂしか示していないが、一般に、コンピュータ２０に関連して上記に説明したエレメントの多くまたはすべてを含む。図８に示す論理接続は、例として非限定的にここに提供しているローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス内または企業内のコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
【００６８】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ２０は、ネットワークインタフェースまたはアダプタ５３を通してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用される場合は、コンピュータ２０は、モデム５４、無線リンク、またはインターネットなど、広域ネットワーク５２を介して通信を確立するためのその他の手段を含むことができる。モデム５４は、内部でも外部でもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続されている。ネットワーク化された環境では、コンピュータ２０に関連して示しているプログラムモジュール、またはその一部を、リモートメモリ記憶装置に記憶することができる。示してあるネットワーク接続は例であって、広域ネットワーク５２を介して通信を確立するその他の手段を使用することができることを理解されよう。
【００６９】
本発明は、その趣旨または基本的な特徴を逸脱することなく、その他の特定の形態で実施することができる。記載の実施形態は、すべての点において例示的なものにすぎず、限定的なものではないとみなされるべきものである。したがって、本発明の範囲は、前述の説明によってではなく、頭記の特許請求の範囲によって示されている。特許請求の範囲と同等の意味および範囲に含まれるすべての変更は、特許請求の範囲内に包含されるものとする。
【図面の簡単な説明】
【図１】本発明のシステム、方法、およびコンピュータプログラムを実施するための例示的環境を示す図である。
【図２】限定されたチューナリソースを有する中央サーバ、およびそれらのリソースを奪い合うコンシューマを示す図である。
【図３】チューナに関連付けることができる、ポーズバッファおよび録画バッファを示す構成図である。
【図４】例示的チューナの優先度リストを示す図である。
【図５】ルールおよびチューナの優先度に従って中央サーバのチューナをコンシューマに割り振る責任を有する、中央サーバのチューナアービタを示す図である。
【図６】要求しているユーザが使用できるチューナがない場合に、チューナのコンフリクトを解決する方法を示す流れ図である。
【図７】チューナのコンフリクトを解決する方法の別の例を示す図である。
【図８】本発明に適した動作環境を提供する、例示的システムを示す図である。
【符号の説明】
２０　コンピュータ
２１　処理装置
２２　システムメモリ
２３　システムバス
２４　ＲＯＭ
２５　ＲＡＭ
２６　基本入出力システム（ＢＩＯＳ）
２７　磁気ハードディスクドライブ
２８　磁気ディスクドライブ
２９　リムーバブル磁気ディスク，磁気ディスク
３０　光ディスクドライブ
３１　リムーバブル光ディスク（光ディスク）
３２　ハードディスクドライブインタフェース
３３　磁気ディスクドライブインタフェース
３４　光ドライブインタフェース
３５　オペレーティングシステム
３６，３６ａ，３６ｂ　アプリケーションプログラム
３７　その他のプログラムモジュール
３８　プログラムデータ
３９　磁気ハードディスクドライブ，ハードディスク
４０　キーボード
４２　ポインティングデバイス
４６　シリアルポートインタフェース
４７　モニタ
４８　ビデオアダプタ
４９ａ，４９ｂ　リモートコンピュータ
５０ａ，５０ｂ　メモリ記憶装置
５１　ローカルエリアネットワーク
５２　広域ネットワーク
５３　ネットワークインタフェース，アダプタ
５４　モデム
１００　ソース
１０２　衛星システム
１０４　ケーブルシステム
１０６　インターネット
１１０　ネットワーク
１１４，１１６，１１８　ノードセットトップボックス，セットトップボックス
１２０　中央サーバ
１２１，１２３，１２５　チューナドライバ
１２２，１２４，１２６，３００　チューナ
１２８，１３０，１３２　ユーザ
１３４　ＰＩＰ
１４０　スケジューラ
１４２，１４４，１４６　録画
３０２　ポーズバッファ
３０４　録画バッファ
３０６　セットトップボックス
３０８　ディスプレイ装置
４００　チューナの優先度リスト，優先度リスト
４０１　録画に使用されるチューナ
４０２　ポーズバッファに書き込む，または関連付けられるチューナ
４０３　データサービスに使用されるチューナ
４０５　アイドル状態のチューナ
５００　チューナアービタ
５０２　ルールエンジン
【図１】
2004007592.tif 000003
【図２】
2004007592.tif 000004
【図３】
2004007592.tif 000005
【図４】
2004007592.tif 000006
【図５】
2004007592.tif 000007
【図６】
2004007592.tif 000008
【図７】
2004007592.tif 000009
【図８】
2004007592.tif 000010