JP4557985B2 - 双方向テレビジョン環境下での返信経路の制御 - Google Patents

Description

本発明は、全体的に電子通信の分野に関し、特に、双方向テレビジョン環境下での返信経路の制御に関する。

双方向（インタラクティブ）テレビジョンシステム（テレビシステム）は、多くの方法によって番組視聴者の体験を増強するように運営されている。第一に、番組制作者および／あるいは配信者は、視聴者に対して強化されたサービスおよび特集を提供する事ができる。例えば、双方向テレビシステムでは、双方向テレビ（iTV）アプリケーションを実行することができ、ユーザーの視聴体験を補い、増大させることができる。双方向番組ガイド(IPGs)からゲーム等に至るまでの広汎な双方向テレビアプリケーションを、双方向テレビシステムを介して、ユーザーにむけて提供する事ができる。

また、双方向テレビアプリケーションは、テレビ視聴体験を、単なる受身的な立場から、能動的、双方向的、もしくは活動的なものへと高めることができるため、番組視聴者にとって魅力的なものと言える。例えば、ショッピング双方向テレビアプリケーションは、テレビ放送（ブロードキャスト）を介して広告された商品を、ユーザーがその場で双方向的に注文することを可能とする。

双方向テレビアプリケーションは、一般的には、放送サービスプロバイダのヘッドエンドから、放送通信の一部である消費者のセットトップボックス(STB)へと配信するものである。そのような放送には、テレビ番組の部分（例えば、音声やビデオ）と双方向的部分とを含めることができる。双方向的部分は、アプリケーションコードを含むことができ、さらに、双方向テレビアプリケーションの情報を制御するものであってもよい。放送サービスプロバイダは、一般的には、テレビ番組と双方向的部分とを組み合わせて、ユーザーのロケーションへと放送する単独の信号とする。

ユーザー側において、ユーザー端末(例えば、セットトップボックス(STB))は、放送を受信し、双方向的部分を抽出し、そして放送の双方向的部分において具体化される一つもしくは複数の双方向テレビアプリケーションを構成し、実行する。

双方向部分を抽出して実行する事に加えて、そのユーザー端末に、例えばネットワーク（例えばインターネット）を介して、ユーザーのロケーションから放送サービスプロバイダに返信するため、または他のユーザーに向けて通信することができるようにするための、送信機能を備えてもよい。しかし、いくつかの実例もあるように、放送サービスプロバイダは、返信経路の容量が不十分である為に、ユーザー端末からの通信に対応できない可能性がある。例えば、モデムが、着呼したネットワーク呼び出しに応答する事ができないかもしれず、あるいは、サーバーが、そのサーバーの容量が飽和状態である為に、着呼したネットワーク呼び出しに応じた対応ができないかもしれない。さらに、着呼するネットワーク呼び出し間の区別をつけることができず、且つ、着呼するネットワーク呼び出しに優先順位をつける事が不可能であるために、放送サーバープロバイダが、返信経路の容量を最適に使用することが妨げられている。

ソースシステムにおいて双方向テレビ環境に関連した情報に基づいてヒントを生成する事、そしてそのソースシステムにおいて複数の受信システムに向けてヒントを放送する事を含み、そこでの各受信システムが、ヒントに基づいて返信経路を制御する事を特徴とする、双方向テレビ環境下でのソースシステムへの返信経路を制御するための方法。

本発明の他の特徴は、下記の詳細な記載および付図から明らかにされる。
本発明は、例により示されるものであるが、付図に限定されるものではなく、また、類似した参照番号は、類似した要素を示す。

双方向テレビ環境下でソースシステムへの返信経路を制御するためのシステムおよび方法を述べる。以下の記載においては、説明する事を目的として、本発明の全体的な理解を得るための多くの特定の詳細な記述を示している。しかし、本発明をこれらの特定の詳細な記述にかかわらず実施することができるという事は、当該技術分野における当業者には明らかである。

全体的に、下記に述べている実施形態は、受信システムに番組を放送し、ソースシステムに戻す為の通信返信経路を制御するソースシステムを特徴づけている。その通信返信経路は、放送番組を受信する受信システムによって使用され、ソースシステムへと戻す情報を伝達するか、あるいはソースシステムに戻す情報の伝達を試みる可能性がある視聴者に対してソースシステムに戻す情報の伝達を促す。そのソースシステムは、双方向テレビ環境下の状況を監視し、且つ、返信経路を使用するかどうか、または返信経路を使用する事を視聴者に促すかどうかを決定する為に受信システムが使用するヒントを生成する事によって、通信返信経路を制御する。

ヒントは、期待値と、返信経路の容量の予測に関するハードウェア構成の測定値からなる比としてもよい。そのようなヒントは、数値として表わされ、一つあるいは複数の受信システムによってリアルタイムに監視され、また、受信システムのそれぞれは、返信回路を使用するかどうか、あるいは双方向番組に対応して返信経路を使用する事を試みる視聴者にアクセス権を与えるかどうかを決定するために、ヒントを乱数と比較する。したがって、視聴者が返信経路へのアクセス権を得るときに、サーバー、モデム、あるいはいくつか他のシステムリソースが欠如した状態から来る不十分な返信経路容量によってサービスを拒否される事が少なくなり、視聴者は期待する品質のサービスを楽しむことができる。さらに、視聴者が返信経路の使用を試みる可能性を増やすあるいは減らす事を目的として、受信システムに放送する双方向番組を変える事ができる番組プロバイダは、ヒントを監視することができる。

図１は、本発明を配置することができる典型的な双方向テレビ環境10の概略図である。その双方向テレビ環境10は、配信システム14を経由して受信システム16にデータ（例えば、テレビ番組および双方向アプリケーションデータ）を伝達するソースシステム12を含んでいる。

まずソースシステム12に関して見ていくと、ヘッドエンドシステム18は、放送送信としてデータを伝達するための制御を行う。この目的を達成するために、ヘッドエンドシステム18は、一つあるいは複数の放送サーバー（ブロードキャストサーバー）20、一つあるいは複数のアプリケーションサーバー22、一つあるいは複数のバックエンドサーバー24、一つあるいは複数のロード調節器25を含み、これらがローカルエリアネットワーク23を介してともに接続されているような、双方向テレビ環境の例示的な構成要素を含むものとして示されている。その放送サーバー20、アプリケーションサーバー22、バックエンドサーバー24、そしてロード調節器25のそれぞれは、それぞれの装置の情報を蓄積および検索するために使用するデータベースである管理情報ベース27（ＭＩＢ）、そしてＭＩＢ27からの情報を蓄積および検索する事をそれぞれの装置上で実行できるソフトウェアモジュールであるエージェントモジュール29を含んでいる。

それぞれの放送サーバー20は、様々なソース情報源から様々な種類のデータを受信し、エンコードし、パケット化し、多重化し、そして放送するための制御を行うことができる。本明細書では、例示的な実施形態として、ヘッドエンドシステム18からのデータを放送として送信することを記載しているが、適切なデータを、ソースシステム12から配信システム14を経由して受信システム16へとユニキャストもしくはマルチキャストする事もできるということを正しく理解することができる。別種の実施形態として、データは、ソースシステム12からネットワーク接続を介して受信システム16へ送信する事もできる。例示的な放送サーバー20に関するさらなる詳細については、図２を参照する以下の記述として示している。

本発明の例示的な一つの実施形態として、各アプリケーションサーバー22は、双方向データモジュールをコンパイルし、放送サーバー20へと提供する働きをする。双方向データモジュールは、双方向テレビアプリケーションによって使用されるデータ（例えば、スポーツイベントについての更新された統計的情報およびスコア、ニュースフィード、世論調査など）を含んでもよい。アプリケーションサーバー22は、例えば、双方向テレビアプリケーションと、様々な情報源から受信した音声および映像信号を伴うデータとを、多重化することができる多重化機能も含む。また、アプリケーションサーバー22は、多重双方向テレビアプリケーションを一つあるいは複数の放送サーバー20にフィードする機能(例えば、ストリームで)を備えて、受信システム16へ配信することも可能である。この目的を達成するために、各アプリケーションサーバー22は、いわゆる「カルーセル」方式を実装することができ、それによって、コードとデータモジュールを循環反復方式で放送サーバー20に与え、ヘッドエンドシステム18からの伝達の中に含めるようにすることができる。

また、ヘッドエンドシステム18は、一つあるいは複数のバックエンドサーバー24を含むことも示されており、バックエンドサーバー24は、アプリケーションサーバー22とロード調節器25とモデムプール26に接続している。特に、そのモデムプール26は、受信システム16からのデータを、ネットワーク28（例えば、インターネット）を経由して受信し、バックエンドサーバー24にこのデータを与える為に接続されている。そのバックエンドサーバー24は、受信システム16から受信したデータをアプリケーションサーバー22および放送サーバー20に与えることができる。従って、そのネットワーク28とモデムプール26は、返信経路やチャンネルとして機能し、受信システム16にソースシステム12との双方向性を提供している。返信チャンネルを介してヘッドエンドシステム18に与えられるデータは、一つの例として、受信システム16で実行される双方向テレビアプリケーションへのユーザー入力、あるいは受信システム16により生成され、ソースシステム12に伝達されるデータを含んでもよい。その返信チャンネル30は、ソースシステム12からのプログラムおよびアプリケーションを受信システム16に与える為のチャンネルも提供することもできる。

そのヘッドエンドシステム18は、一つあるいは複数のバックエンドサーバー24、そしてローカルエリアネットワーク23を介した一つあるいは複数のアプリケーションサーバー22およびモデムプール26に接続しているロード調節器25も含んでいるものとして示されている。特に、そのロード調節器25は、多重アプリケーションサーバー22あるいはバックエンドサーバー24あるいはモデムを用いて同一のネットワークアドレスを共有する事と、クラスター化したアプリケーションサーバー22あるいはクラスター化したバックエンドサーバー24あるいはクラスター化したモデム（例えば、同一のネットワークアドレスを共有しているクラスター化したサーバーもしくは装置）のうちの一つに対してリクエストを向けてリクエストを供給することにより、トラフィックを管理している。したがって、ロード調節器25は、同じ時間内により多くの仕事をこなせるように、双方向テレビ環境下のサーバー、モデム、他の機器に対して作業量を分配することができる。一実施形態として、ロード調節は、ハードウェアで行っても良い。また、別の実施形態としては、ロード調節は、ソフトウェアで行ってもよい。なおも別の実施形態としては、ロード調節は、ハードウェアとソフトウェアとの組み合わせで行ってもよい。

ソースシステム12内において、そのヘッドエンドシステム18は、外部ソースから任意にデータ（例えば、番組、暗号そしてアプリケーションデータ）を受信することができる。図1では、ネットワーク36（例えば、インターネット）を経由した一つあるいは複数の番組ソース32および一つあるいは複数のアプリケーションソース34と接続しているようなヘッドエンドシステム18を描いている。例えば、番組ソース32は、娯楽番組（例えば、映画）のプロバイダとすることができ、あるいはリアルタイムの動的なデータ（例えば、天気情報）のプロバイダとすることもできる。アプリケーションソース34は、任意の双方向テレビアプリケーションのプロバイダとすることができる。例えば、一つあるいは複数のアプリケーションソース34は、電子番組ガイド（ＥＰＧ）およびナビゲーションアプリケーション、メッセージおよび通信アプリケーション、情報アプリケーション、スポーツアプリケーション、ならびに／あるいはゲームおよびゲームをするためのアプリケーションを提供する事ができる。

では次に配信システム14について検討してみるが、一つの実施形態として配信システム14は、ソースシステム12から受信システム16へのデータの放送配信を示している。図のように、その配信システム14は衛星、ケーブル、地上波あるいはデジタル加入者回線（ＤＳＬ）ネットワーク、あるいはそのようなネットワークのいくつかの組み合わせを含んでいる。

一つの例示的な実施形態として、その受信システム16は、配信システム14を介してデータを受信するセットトップボックス（ＳＴＢ）38、ヘッドエンドシステム18および任意の他の外部システムへの返信チャンネルを通信するためのモデム40、ユーザー入力装置43（例えば、キーボード、遠隔入力装置、マウスなど）、ならびに、セットトップボックス38で受信する番組を表示するためにセットトップボックス38に接続しているディスプレイ装置42を含むようなものとして示されている。一つの例示的な実施形態として、ディスプレイ装置42はテレビセットであってもよい。

セットトップボックス38は、ソフトウェアの３つのレイヤー、すなわち、制御システム44、ミドルウェア46そして一つあるいは複数の双方向テレビアプリケーション48を実行することができる。そのミドルウェア46は、双方向テレビアプリケーション48を、種々のオペレーションシステム44の相違から保護する為に、種々のセットトップボックス38のハードウェア内で動作している。このために、ミドルウェア46は、ドライバアプリケーションプログラムインターフェイス（ＡＰＩｓ）およびライブラリを提供し、双方向テレビアプリケーション48から受け取った命令を、セットトップボックスのハードウェア（例えば、モデム、インターフェイスポート、スマートカードリーダーなど）が認識できる低レベルのコマンド内へと翻訳を行うことができるようにしている。

図２は、本発明の典型的な実施形態の一部として本発明を備えているようなヘッドエンドシステム18およびセットトップボックス38の構成要素に関するさらなる詳細を描いているブロック図であって、本発明の例示的な実施形態の一部として配置することができるものである。特に、図2は、マルチプレクサ50へ入力を与える多くの並列経路を含んでいるようなモジュールのカルーセルを備えることができる放送サーバー20を示しており、ここでのそれぞれの並列経路は、エンコーダー52およびパケット化装置54を含んでいる。各エンコーダー52は、一つあるいは複数のソースからの入力を受信するように動作する事ができる。例えば、エンコーダー52aは、アプリケーションサーバー22からのストリーム化されたアプリケーションモジュールを受信するものとして示しており、一つもしくは複数のアプリケーションソース34からアプリケーションデータを受信する為に順次接続される。そのアプリケーションソース34は、ヘッドエンドシステム18の内部あるいは外部にあってもよい。同様に、エンコーダー52bは、一つあるいは複数の番組ソース32から番組データを受信するために接続しているものとして示されており、また、番組ソース32は、ヘッドエンドシステム18の内部あるいは外部にあってもよい。

各放送サーバー20は、マルチプレクサ50に入力を与えている任意の数のソース（例えば、アプリケーションソース34および／あるいは番組ソース36）に接続された、任意の数の並列経路を含んでいてもよい。さらに、ヘッドエンドシステム18は、任意の数の放送サーバー20を備えてもよい。

各エンコーダー52は、例えば、Motion Picture Expert Group(MPEG)比較(comparison)アルゴリズムのような一つあるいは複数の圧縮アルゴリズムのいくつかを利用して、データをエンコードするように動作する。各エンコーダー52は、また同期化の目的のためにタイムスタンプデータを制御する。特定のデータタイプは、エンコーディングによる影響を受けずに、エンコーダー52を通過したり、あるいは迂回したりする事ができ、また、エンコードされていない状態でパケット化装置54に与えることができるという事が、正しく理解される。

パケット化装置54は、エンコードされたデータおよびエンコードされていないデータの両方を受け取り、配信システム14（例えば、放送チャンネル）を介して最終的に送信する前に、このデータをフォーマットしてパケット化する為に接続している。

各パケット化装置54は、マルチプレクサ50にパケットを与え、マルチプレクサ50は、パケットを多重化して、配信システム14を介して配信するための搬送シグナルとする。
受信システム16のセットトップボックス38は、配信システム14を介したヘッドエンドシステム18から伝送された搬送信号を受信するために、一般にネットワーク入力（例えば、モデム）、ケーブル入力、衛星パラボナアンテナあるいはアンテナと接続している。その後、搬送信号は、入力56（例えば、受信器、ポートなど）に送られる。入力56が受信器を含む場合、例えば、入力56は、送信された信号が放送される放送チャンネルを選択するように作動するチューナー（図示せず）を含んでもよい。パケット化された搬送信号は、入力56からデマルチプレクサ58へと送られ、デマルチプレクサ58は、その送信信号を構成しているアプリケーションおよび番組データを脱多重化(demultiplexes)する。特に、デマルチプレクサ58は、音声・映像デコーダー60にむけて番組データを与え、そしてコンピューターシステム64にむけてアプリケーションデータを与える。その音声・映像デコーダー60は、番組データを、例えば、テレビ信号にデコードする。例えば、その音声・映像デコーダー60は、受信した番組データを、ＮＴＳＣ，ＰＡＬ，ＨＤＴＶ信号のような適切なテレビ信号としてデコードすることができる。その後、テレビ信号は、音声・映像デコーダー60からディスプレイ装置42に与えられる。

プロセッサとメモリを含むコンピューターシステム64は、デマルチプレクサ58によってそこに供給されたアプリケーションデータから、一つあるいは複数の双方向テレビアプリケーションを再構築する。上述したように、アプリケーションデータは、双方向テレビアプリケーション48によって用いられるアプリケーションコードおよび／もしくはアプリケーション情報の両方を含んでもよい。そのコンピューターシステム64は、双方向テレビアプリケーション48を再構築する事に加えて、こうしたアプリケーション48を実行し、セットトップボックス38で一つあるいは複数の操作を実施させるようにする。そのコンピューターシステム64は、ディスプレイ装置42（例えば、音声・映像デコーダー60からディスプレイ装置に与えられる信号により生成される画像上にオーバーレイする、画像もしくはグラフィカルユーザーインターフェイス（ＧＵＩ））に信号を出力してもよい。ユーザー入力装置43（例えば、キーボード、遠隔入力機器、マウス、マイクロホン、カメラなど）もまた入力56に接続するように示しており、ユーザーがセットトップボックス38に入力を行えるようになっている。そのような入力は、例えば、英数字、音声、映像、あるいはコントローラー（例えば、ユーザーインターフェイス内に存在するオブジェクトの操作をする）の入力であってもよい。

また、コンピューターシステム64を、音声・映像デコーダー60に接続するものとして示しており、コンピューターシステム64がこのデコーダー60を操作できるようになっている。また、コンピューターシステム64は、デコーダー60から音声信号および／あるいは映像信号を受信して、この信号を生成した信号と組み合わせることにより、コンピューターシステム64が、ディスプレイ装置42に対して組み合わせた信号を与える事ができるようになっている。

また、そのコンピューターシステム64は、出力66（例えば、送信器、出力ポートなど）に接続するものとして示されており、それを通じてセットトップボックス38が出力データを送ることができるようになっており、この出力データは、返信チャンネル30を介して、例えばヘッドエンドシステム18のような外部機器に与える事ができる。このために、出力66は、受信システム16のモデム40と接続するものとして示している。

受信システム16は、図１においてディスプレイ装置42に接続しているセットトップボックス38を含むものとして図示されてはいるが、受信システム16の構成物を単独の装置（例えば、コンピューターシステム）として組み合わせる事もでき、あるいは多くの独立システム間に分配することもできるという事を、容易に正しく理解することができる。例えば、別々の受信装置が、ディスプレイ装置42に接続されたセットトップボックス38に入力を与えてもよい。

図３は、本発明の例示的な実施形態に係る、ヘッドエンドシステム18およびセットトップボックス38の様々なソフトウェアおよびハードウェア部分を描いているブロック図である。

ヘッドエンドシステム18は、ヒント生成モジュール70および放送モジュール72を含む放送サーバー20を含んでいる。ヒント生成モジュール70は、ヒントを生成する事を目的として、双方向テレビ環境に関連する情報を検索するために双方向テレビ環境を監視している。例えば、ヒント生成モジュール70は、放送サーバー20、アプリケーションサーバー22、バックエンドサーバー24、モデムプール26、そしてロード調節器25に関連して、エージェントモジュール29から情報を要求し、ヒントを生成するために検索した情報を使用する。他の実施形態として、双方向テレビ環境下で付加的な装置を含んでもよい。一つの実施形態として、ヒント生成モジュール70は、複合ネットワークを管理するためのプロトコルのセットである簡易ネットワーク管理プロトコル（ＳＮＭＰ）を使用する。当該技術分野において公知であるように、ＳＮＭＰは、エージェントと呼ばれるＳＮＭＰコンプライアント装置にメッセージを送る。エージェントは、管理情報ベース（ＭＩＢ）のそれぞれの装置についてのデータを格納し、ＳＮＭＰリクエスターへ以前に格納したデータを返信する。

放送モジュール72は、ヒント生成モジュール70からヒントを受け取り、そして配信システム14を介してヒントをセットトップボックス38に放送する。
セットトップボックス38は、ヒント読み取りモジュール74を含んでいる。そのヒント読み取りモジュール74は、ヒントを受け取り、返信チャンネル30を調整するためにヒントを使用する。例えば、一つの実施形態として、ヒント読み取りモジュール74は、セットトップボックス38に関するユーザーに対して、入力を促すべきかどうかを判断し、ユーザーに返信チャンネル30を介してヘッドエンドシステム18に送るデータを生成することを許可する。別の実施形態としては、ヒント読み取りモジュール74は、ヘッドエンドシステム18への情報（例えば、通信するためにセットトップボックスにおいてすでに待機していた情報）の通信を可能とすることができる。

図４は、本発明の例示的実施形態に係る、双方向テレビ環境下でのソースシステムへの返信経路を調節する方法80を描いている、双方向フローチャート図である。本例示的実施形態は、視聴者の持つセットトップボックス38を用いて答えることができる質問を、観衆中の視聴者に問いかける双方向生中継テレビニュース番組を表している。ヘッドエンドおよびセットトップボックスの動作が描かれている。

本発明の例示的な実施形態によれば、方法80は、ヒント生成モジュール70が図５に示されているようにヒントを生成することをともなうボックス82から開始している。
図５におけるボックス120において、ヒント生成モジュール70は、モデムプール26に関連しているエージェントモジュール29からステータス情報を要求するためにＳＮＭＰプロトコルを使用する。それに応じて、エージェントモジュール29は、モデムプール26に関連しているＭＩＢを読み込み、現在のモデム可用性（ＣＭＡ）（例えば、利用可能であるモデムの数）を含んだモデムプールに関連するステータス情報を報告する。

ボックス124において、ヒント生成モジュール70は、アプリケーションサーバー22に関連しているエージェントモジュール29からステータス情報を要求する。それに応じて、アプリケーションサーバー22上のエージェントモジュール29は、（例えば、夜のニュース番組における）視聴者の数の期待値（ＥＮＶ）および参加人数比（ＰＲ）を含むステータス情報を通知する。ＣＭＡ、ＰＲ、ＥＮＶといったパラメーターは、投票型の質問を提示する視聴者の比あるいは割合を決めるために用いることになるヒントを生成するために使用できる。例えば、ネットワークオペレーターは、視聴者の数の期待値に提供する為の利用可能な千個のモデムを有する事ができる。経験的に、そのオペレーターには、投票を促されている視聴者の10％が実際に参加するということがわかっている。一般に、そのオペレーターは、投票を促せる視聴者の数を最大にしたいが、混雑している回線で応答を決定する視聴者の不満をなくしたいとも考える。

ボックス126において、ヒント生成モジュール70は、下記の公式を使用することによってヒントをコンピュータ計算する。
CMA×PR／ENV＝ヒント （ここでのヒントは、ヒント>０である。）
したがって、本発明の典型的な実施形態においては、ヒントは、パーセンテージで表される「アプリケーションXプロンプト比」("application X prompt ratio)であって、モデム可用性の増加、参加人数比の増加、視聴者の数の期待値の減少につれて１に近づいてゆく。後述するように、そのヒントは、視聴者を促すかどうかを決定する為に、０から１の間の乱数と比較される。したがって、１に近づいているヒントは、一人の視聴者を参加させる可能性をより大きなものとする。視聴者を参加させる可能性はリアルタイムで増加もしくは減少し、これは、双方向テレビ環境に関連する情報が、動的あるいは連続的に変化する（例えば、現在のモデム可用性、参加人数の比、そして視聴者の数の期待値）可能性があるためであり、且つ、そのような情報は、連続的に監視され、下記で述べているようにリアルタイムに評価できる場合には、セットトップボックス38へと放送される比率もしくは割合として表すことができるためである、ということを、当業者は正しく理解することができる。

図４の説明に戻ると、ボックス84において、ヒント生成モジュール70は、双方向テレビ環境においてセットトップボックス38にヒントを放送する放送モジュール72にヒントを通知する。

ボックス86において、セットトップボックス38上のヒント読み取りモジュール74は、ヒントを受け取り、メモリに保存する。
ボックス88において、ヒント読み込みモジュール74は、メモリからヒントを読み込む。

ボックス100において、ヒント読み込みモジュール74は、乱数発生器を用いて０から１までの乱数を生成する。別の実施形態としては、ヒント読み込みモジュール74は、乱数を発生させる為にセットトップボックス38に関連する受信IDの一つあるいは複数のビットを用いてもよい。

決定ボックス102において、ヒント読み込みモジュール74は、ヒントと乱数を比較する事によって返信経路を調節する。もし乱数がヒントよりも小さければ、ボックス108へと分岐する。そうでない場合は、決定ボックス104に分岐する。例えば、後述の疑似コードを、視聴者を促すかどうかを決定するために用いる事ができる。

while(the_viewer_is _watching_application_X() and
more _retries()
{
ratio=get_application_X_prompt_ratio_from_broadcast();
radom=get_random_between_0_and_1();

if(random<ratio)
prompt_viewer();
}

決定ボックス104において、そのヒント読み込みモジュール74は、再試行すべきであるかどうかを決定する。もし再試行すべきであるならば、ボックス106に分岐し、そうでないならば、方法80は終了する。一つの実施形態としては、一定の回数の再試行を行ってもよく、別の実施形態としては、行う再試行の回数は動的とすることができる。また、別の実施形態としては、特定のアプリケーション、または双方向テレビ環境などに関するいくつかの他の情報に基づいたアプリケーションとして、或る回数の再試行を行ってもよい。

ボックス106において、ヒント読み込みモジュール74は、劇的に変化する期間、あるいは所定の期間まで待機する。他の実施形態としては、特定のアプリケーションもしくは双方向テレビ環境に関連したいくつかの他の情報に基づいて期間を決定する事ができる。

ボックス108において、ヒント読み込みモジュール74は、図６で描いているように質問をユーザーに提示する。
図６は、画像132（例えば刑務所の囚人のテレビ画像）を表示するような例示的なユーザーインターフェイス130を描いている。そのユーザーインターフェイス130は、画像132に相当するXYZニュースサービスにより提起される死刑に関する投票形式の質問を含む書き込み式のデータを含んでいる。例えば、ユーザーインターフェイス130は、「死刑は禁じるべきか？」という質問をユーザーに問いかけるテキスト206を含む。また、テキスト206中に示されているように、ユーザーが投票に答えるためのチェックボックスがある。そのインターフェイス130の内部には、ユーザーや視聴者のための英数字入力機能であるヴァーチュアルキーボード208が存在する。ヴァーチュアルキーボード208は、例えば、セットトップボックス38を用いて通信するための普通の遠隔入力器を使用することによって操作することもできる。視聴者は、その質問に肯定的な返答を示す「Y」あるいはその質問に否定的な返答を示す「N」を選択するためにヴァーチュアルキーボード208を使用してもよい。視聴者は、図４のボックス110で描いているようにヘッドエンドシステムの返信経路にデータを返送するための送信キー212を選ぶことによって返答を送る。

図４に戻り、ボックス112において、そのデータはモデムプール26で受信され、ボックス114に示したように、適切なサーバー（例えば、アプリケーションサーバー22、バックエンドサーバー24、放送サーバー20）に通知される。

したがって、例示的な本発明の実施形態として双方向生中継テレビニュースショー形式として示した双方向テレビ環境におけるソースシステムへの返信経路を調節するための方法80は、視聴者のセットトップボックスで答える事ができる投票形式の質問を観衆中の幾人かの視聴者に問いかけることを示している。また、方法80は、例示的な実施形態として双方向テレビ環境における格納および転送および並列使用量型処理として示している。

［格納および転送の制御］
格納および転送型の制御は、セットトップボックス38から入力され、選択した購入物を検索する為に使用される。例えば、その格納および転送型制御は、セットトップボックス38のスマートカードを介してローカルで行われるビデオオンデマンド（ＶＯＤ）の形態における購入物を検索する為に使用され、一般的にヘッドエンドシステム１８によって一ヶ月に一度検索されるようにすることができる。別の実施形態として、その格納および転送制御は、電子商取引の形態での購入物を検索する為に使用してもよく、それぞれの購入物は、ヘッドエンドシステム18の返信チャンネル30を介した即時のライブ接続のトリガーとなって購入を取り消すことになる閾値よりも額面が下になるように行われる。両方の実施形態において、通常、モデムプール26中の少数のモデム（M）は、多数のクライアント（N）から上述したように選択された購入物に対するインカミング呼出を受信することのみに使われる。さらに、上述したように選択した購入物を提供する為に用いるモデムの使用可能な数（M）は、モデムプール26のリソースに対する累積的な要求に基づいた時間に応じて、変化させることができる。したがって、モデムプール26の使用が失敗してしまう試行を回避し、モデムプール26のリソースを利用することを避け、優先度の高い制御に代わって上述の優先度の低い購入物を提供するために、モデム使用比率の形態であるヒントを、リアルタイムに連続的に放送してもよい。そのヒントは、以下のようにコンピュータ計算してもよい。

M／N＝ヒント （ここで、１＞ヒント＞０である。）
上述のヒントは、以下にある疑似コードを用いたヒント読み込みモジュール74によって処理することができる。

while(the_set-top_box_has_report_to_make())
{
ratio=get_modem_ratio_usage_ratio_from_broadcast();
random=random_between_0_and_1();

if (random<ratio)
try_to_send_report();
else
wait_a_little_bit();
}

［並列使用量制御］
並列使用量制御は、双方向番組プロバイダ間で双方向テレビリソースを分配することを含んでもよい。例えば、一つの例示的実施形態においては、放送オペレーターが占有しているモデムは、上述したような双方向生放送テレビニュースのような、多重テレビチャンネルおよび／あるいは多重双方向アプリケーションによって使用することができる。この実施形態において、各テレビチャンネルおよび／あるいは各アプリケーションは、参加している双方向番組プロバイダ間でのモデムリソースの使用を分配するために用いることができる対応するヒントもしくはモデム使用比率に関連させることができ、これによって、共通返信チャンネル30へのアクセスを調節する。例えば、モデムプール中の３００個のモデムを、５チャンネルの専用として、残りの７００個のモデムを、他のチャンネルの専用とする事ができる。この例では、５チャンネルに関連しているヒントは、３０％を下回ることは決してなく、いくつかの例において、他のチャンネルが必要とする使用量に基づいて３０％よりも実質的に多くに増やす事ができる。

別の実施形態として、サーバーとサーバーのクラスは、重要なリソースによって決められる。例えば、チャットサーバー形式のアプリケーションサーバー22は、たとえ放送オペレーターがインカミング呼出を提供するために２０００個のモデムを用意していたとしても、最大で５０の並列チャットセッションを制御する事ができるだけである。したがって、そのチャットサーバーは、もしヒントが、チャットアプリケーションに対して分配したモデムに基づいているならば、すぐに処理超過になってしまう。この例において、調整しているヒントは、アプリケーションサーバー22のリソースに基づくものとし、モデムプール26のリソースには基づいていない。これは、使用可能なリソースに基づいて提供できる最高水準のサービスを可能とするためである。確認として、ヒントは、双方向テレビ環境（例えば、放送サーバー20、アプリケーションサーバー22、バックエンドサーバー24、ロード調節器25、モデムプール26など）中の任意のリソースのために、コンピュータ計算され、放送され、使用されることができる。さらに、ヒントは、特定の双方向番組プロバイダ（例えば、アプリケーション、TVチャンネルなど）に分配するためのリソースのために、コンピュータ計算され、放送され、使用されることができ、これによって、ネットワークオペレーターが、双方向テレビ環境の一部を、双方向番組プロバイダ（例えば、保証されている最低のサービス）に「売る」あるいは「貸す」ことができるようになる。さらに、双方向番組プロバイダは、ヒントの瞬間的な値に基づいて、放送番組を変更できるということも、正しく理解される。したがって、上述した例において、チャットセッション専用となったアプリケーションサーバー22は、リアルタイムに連続的にコンピュータで再計算されるヒントの瞬間的な値に基づいて、空になったチャットルームを閉じる事ができる。別の例として、生中継のテレビニュース番組は、リアルタイムに連続的にコンピュータで再計算されるヒントの瞬間的な値に基づいて、テレビショー中に観衆にむけて放送する投票形式の質問の予定される数を増やしたり減らしたりする事ができる。

図７は、コンピューターシステム300の例示的な形態における機器の概略図であって、機器に本明細書で記した一つあるいは複数の方法論のいずれかを実施させる為の実行可能な命令一式を含めて示している。別の実施形態として、その機器は、スタンドアローン装置として動作してもよく、あるいは他の機器に接続（例えばネットワーク接続）するものであってもよい。ネットワーク化された配置として、その機器は、サーバー−クライアントネットワーク環境内のサーバーの容量あるいはクライアント機器の容量で動作することができ、または、ピアツーピア（あるいは、分配された）ネットワーク環境内のピア機器として動作することもできる。その機器は、サーバー、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス(STB)、携帯情報端末（PDA）、携帯電話、webアプライアンス、ネットワークルータ、スイッチあるいはブリッジ回路、あるいは機器で行われる動作を特定するための（逐次的あるいはそれ以外の）命令一式を実行する能力を有する可能性がある任意の機器としてもよい。さらに、単一の機器のみを示してはいるが、「機器」と言う語は、本明細書で述べられている任意の一つあるいは複数の方法論を実施するための命令一式（あるいは複数の命令一式）を、個別にあるいはまとめて実行するための、いくつかの機器の集合体を含むものとして考えていただきたい。

その例示的なコンピューターシステム300は、プロセッサ302（例えば、中央処理ユニット（CPU）、画像処理ユニット（GPU）、あるいはその両方）、メインメモリ304、およびスタティックメモリ306を含んでおり、それらはバス308を介して互いに接続している。その例示的なコンピューターシステム300は、ビデオディスプレイユニット310（例えば、液晶ディスプレイ（LCD）あるいはブラウン管（CRT））を含んでもよい。また、そのコンピューターシステム300は、英数入力装置312（例えば、キーボード）、ユーザーインターフェイス（UI）ナビゲーションあるいはカーソルコントローラー装置314（例えば、マウス）、ディスクドライブユニット33、信号生成装置318（例えば、スピーカー）そしてネットワーク接続装置320も含む。

そのディスクドライブ装置33は、本明細書で述べている一つあるいは複数の方法論あるいは機能のいずれかを実行する一つあるいは複数の命令一式（例えば、ソフトウェア324）を格納する機器が読み取り可能である媒体322を含んでいる。そのソフトウェア324は、機器が読み取り可能な媒体を構成しているコンピューターシステム300、メインメモリ304、およびプロセッサ302によって実行される間には、メインメモリ304および／あるいはプロセッサ302内部に完全に、あるいは少なくとも部分的に収められることになる。

そのソフトウェア324は、さらにネットワークインターフェイス装置320を経由したネットワーク326を介して送信あるいは受信してもよい。
機器が読み取り可能な媒体322を、例示的な実施形態として単独の媒体として示してはいるが、その「機器が読み取り可能な媒体」という語は、一つあるいは複数の命令一式を格納する単独の媒体あるいは複合媒体（例えば、集積化した、もしくは分割化したデータベースならびに／あるいは関連したキャッシュおよびサーバー）を含むものとして考えていただきたい。また、「機器が読み取り可能な媒体」という語は、機器によって実行される命令一式を格納、エンコード、もしくは搬送する事ができ、且つ、本発明の一つあるいは複数の方法論のいずれかを機器に実施させることができるような任意の媒体を含むものとして考えていただきたい。したがって、「機器が読み取り可能な媒体」という語は、固体素子メモリ、光学および磁気メディア、およびキャリア波信号を含むものであるとして考えるべきものであるが、これらに限定はされない。

以上のように、双方向テレビ環境下でのソースシステムへの返信経路を調節する為の方法とシステムを記載した。本発明は、特定の実施形態としての参考例を記載してきたが、様々な修正および変化を発明の範囲や概念の域を超えることなく、これらの実施形態に対して施すことができるのは明らかである。したがって、本明細書および図は、限定的な意味では無く、具体例としてみなされるものである。

図１は、本発明を配置することができる、例示的な双方向テレビ環境を図示している。 図２は、本発明の例示的な実施形態におけるヘッドエンドシステムおよびセットトップボックスに関する、構成の詳細を示すブロック図である。 図３は、本発明の一つの実施形態に係る、生成されるヒントモジュール、放送モジュール、そして読み込みヒントモジュールの構成要素を描いているブロック図である。 図４は、本発明の一つの例示的な実施形態に係る、双方向テレビ環境下でソースシステムへの返信経路を制御する為の方法を描いている双方向フローチャートである。 図５は、本発明の例示的な実施形態に係る、ヒントを生成するための方法を示すフローチャートである。 図６は、本発明の例示的な実施形態に係るユーザーインターフェイスを描いており、それは、ユーザーが書き込む事ができて、書き込んだ内容の伝送を可能とするための書き込みアプリケーションとして示すことができるものである。 図７は、コンピューターシステムの例示的な形態における機器を描いているブロック図であり、その機器は、本明細書で述べた任意の方法を機器で実施するための命令一式を格納し、実行する事ができるものである。

Claims (24)

1. 双方向テレビ環境下でのソースシステムへの返信経路を調節するための方法において、
   前記ソースシステムにおいて、前記双方向テレビ環境下でのモデムプール中のモデムの可用性および投票を促された視聴者の参加人数比に基づいて前記モデムの可用性と前記参加人数比の積に比例するヒント値を生成するステップと、
   前記ソースシステムにおいて、複数の受信システムに前記ヒント値を放送するステップであって、ここで前記受信システムのそれぞれは、前記ヒント値と前記受信システムのそれぞれで生成された乱数とを比較して、前記返信経路へのアクセスを調節するものであるステップと
   を含むことを特徴とする方法。
2. 双方向テレビ環境下でのソースシステムへの返信経路を調節するための方法において、
   前記ソースシステムにおいて、前記双方向テレビ環境下でのモデムプール中のモデムの可用性および投票を促された視聴者の参加人数比に基づいて、期待値と、前記モデムの可用性と前記参加人数比の積との比を表すヒント値を生成するステップと、
   前記ソースシステムにおいて、複数の受信システムに前記ヒント値を放送するステップと、
   前記受信システムの１つが、乱数を生成し、前記ヒント値と前記乱数を比較することによって、前記返信経路の調節をするステップ
   を含むことを特徴とする方法。
3. 前記双方向テレビ環境に関連した情報に基づいて前記ヒント値を生成する前記ステップが、
   前記ヒント値を決定するために前記双方向テレビ環境の状況を監視するステップを含むことを特徴とする請求項１または２記載の方法。
4. 前記状況を監視する前記ステップが、
   モデムプール状況におけるモデムの可用性を監視するステップと、
   バックエンドサーバー状況の可用性を監視するステップと、
   バックエンドサーバーのクラス内の前記バックエンドサーバーの可用性を監視するステップと、
   第一アプリケーションの状況に応じたモデムプール内のモデムの割り当てを監視するステップと
   のうちの少なくともひとつのステップを含むことを特徴とする請求項３記載の方法。
5. 前記ヒント値を生成する前記ステップ、および前記ヒント値を放送する前記ステップが、リアルタイムに繰り返し実行されることを特徴とする請求項１または２記載の方法。
6. 前記受信システムがセットトップボックスを含む請求項１または２記載の方法。
7. 前記受信システムが、前記返信経路へのアクセス権を与えるかどうかを決定することで、前記返信経路の調節をすることを特徴とする請求項２記載の方法。
8. 前記返信経路への前記アクセス権を提供する前記ステップが、視聴者へ促すステップを含むことを特徴とする請求項８記載の方法。
9. 前記受信システムが、前記返信経路を使用するかどうかを決定することで、前記返信経路を調節することを特徴とする請求項１または２記載の方法。
10. 前記受信システムに関連している受信器の識別番号に基づいて、前記受信システムの１つが、前記乱数を生成するための乱数発生器を使用するステップを含むことを特徴とする請求項１または２記載の方法。
11. 前記ヒント値を放送する前記ステップが、前記ヒント値を、前記ヒント値に基づいて放送番組を変更する双方向番組プロバイダに対して伝達するステップを含むことを特徴とする請求項１または２記載の方法。
12. 双方向テレビ環境下で、ソースシステムへの返信経路を調整するためのシステムにおいて、
    前記ソースシステムにおいて、前記双方向テレビ環境下でのモデムプール中のモデムの可用性および投票を促された視聴者の参加人数比に基づいて前記モデムの可用性と前記参加人数比の積に比例するヒント値を生成するためのヒント生成モジュールと、
    前記ソースシステムにおいて、複数の受信システムへと前記ヒント値を放送するためのヒント放送モジュールと
    を含み、前記受信システムのそれぞれは、前記ヒント値と前記受信システムのそれぞれで生成された乱数とを比較して、前記返信経路へのアクセスを調節することを特徴とするシステム。
13. 双方向テレビ環境下で、ソースシステムへの返信経路を調整するためのシステムにおいて、
    前記ソースシステムにおいて、前記双方向テレビ環境下でのモデムプール中のモデムの可用性および投票を促された視聴者の参加人数比に基づいて、期待値と、前記モデムの可用性と前記参加人数比の積との比を表すヒント値を生成するためのヒント生成モジュールと、
    前記ソースシステムにおいて、複数の受信システムへと前記ヒント値を放送するためのヒント放送モジュールと
    を含み、前記受信システムのそれぞれは、乱数を生成し、前記ヒント値と前記乱数を比較することによって、前記返信経路の調節をすることを特徴とするシステム。
14. 前記ヒント生成モジュールが、前記ヒント値を決定するために、前記双方向テレビ環境内の状況を監視することを特徴とする請求項１２または１３に記載のシステム。
15. 前記ヒント生成モジュールが、
    モデムプール状況におけるモデムの可用性と、
    バックエンドサーバー状況の可用性と、
    バックエンドサーバーのクラスの状況における前記バックエンドサーバーの可用性と、
    第一アプリケーションの状況に応じたモデムプール内のモデムの割り当てと
    のうちの少なくともひとつを監視することを特徴とする請求項１４記載のシステム。
16. 前記ヒント生成モジュールが、前記ヒント値をリアルタイムで繰り返し生成し、
    前記放送ヒントモジュールが、前記ヒント値をリアルタイムで繰り返し放送する
    ことを特徴とする請求項１２または１３に記載のシステム。
17. 前記受信システムが、セットトップボックスを含むことを特徴とする請求項１２または１３に記載のシステム。
18. 前記受信システム上のヒント読み込みモジュールが、前記返信経路へのアクセス権を与えるかどうかを決定することを特徴とする請求項１２または１３に記載のシステム。
19. 前記ヒント読み込みモジュール中で、ユーザーに前記返信経路へのアクセス権を与えるよう促すことを特徴とする請求項１８記載のシステム。
20. 前記受信システム上のヒント読み込みモジュールが、前記返信経路を使用するかどうかを決定することを特徴とする請求項１２または１３に記載のシステム。
21. 前記乱数が、前記受信システムに関連している受信器の識別番号を用いて前記乱数を生成するための乱数生成器によって生成されるものであることを特徴とする請求項１２または１３に記載のシステム。
22. 前記放送モジュールが、前記ヒント値に基づいて放送番組を変える双方向番組プロバイダに対して、前記ヒント値をさらに伝達するように放送することを特徴とする請求項１２または１３に記載のシステム。
23. 機器によって実行された際に、上述した任意の方法を前記機器によって実施させる命令一式を格納している機器が読み取り可能な媒体。
24. 双方向テレビ環境下でソースシステムへの返信経路を調整するためのシステムにおいて、
    前記ソースシステムにおいて、前記双方向テレビ環境下でのモデムプール中のモデムの可用性および投票を促された視聴者の参加人数比に基づいて、前記モデムの可用性と前記参加人数比の積に比例するヒント値を生成する為の第一手段と、
    前記ソースシステムにおいて、前記ヒント値を複数の受信システムに対して放送する為の第二手段と
    を含み、ここで、前記受信システムのそれぞれは、前記ヒント値と前記受信システムのそれぞれで生成された乱数とを比較して、前記返信経路へのアクセスを調節することを特徴とするシステム。

Images