(57)【特許請求の範囲】
【請求項１】
テレビジョンシステムにおいて、イベント予約を仲介および管理する方法であって、
イベントブローカ（３０）でイベント予約の要求を受け取る工程であって、該要求が第１のイベントと、該第１のイベントが発生するとすぐに取られる第１の動作とを識別する、工程と、
該イベント予約要求を登録する工程であって、該イベントブローカ（３０）が該第１のイベントに対応する第１のイベントマネージャ（３１）に通知し、該第１の動作に対応する第１の動作ハンドラ（３２）に通知する、工程と、
該第１のイベントマネージャ（３１）によって、該第１のイベントを検知する工程と、
該第１のイベントマネージャ（３１）が、該第１のイベントの検知を該イベントブローカ（３０）に通知する工程と、
該イベントブローカ（３０）が、該第１のイベントの検知の通知を該第１の動作ハンドラ（３２）に提供する工程と、
該イベントブローカ（３０）からの該通知の検知に応答して、該第１の動作ハンドラ（３２）によって該第１の動作を開始する工程と、
を包含する、方法。
【請求項２】
前記イベントブローカ（３０）が複数のイベント予約を受信するように構成されており、該イベント予約の各々が特定のイベントと該特定のイベントが発生するとすぐに取られる特定の動作とを識別する、請求項１に記載の方法。
【請求項３】
前記イベントブローカ（３０）が、複数のイベントマネージャから前記第１のイベントマネージャ（３１）を識別し、選択する工程をさらに包含し、該第１のイベントマネージャ（３１）は、前記第１のイベントに対応するタイプのイベントを検知するように構成される、請求項１に記載の方法。
【請求項４】
前記第１のイベントマネージャ（３１）が前記第１の動作ハンドラ（３２）と、直接通信するように構成されない、請求項１に記載の方法。
【請求項５】
前記イベントブローカ（３０）から、前記イベント予約の通知を受け取った後に、該イベント予約の前記第１のイベントマネージャ（３１）による受け入れ決定に応答して、該第１のイベントマネージャ（３１）が該イベントブローカ（３０）に対して肯定の確認を提供する、請求項３に記載の方法。
【請求項６】
前記イベント予約の受け入れに応答して、前記第１のイベントマネージャ（３１）が前記第１の動作ハンドラ（３２）に要求を伝え、該第１のイベントマネージャ（３１）からの該要求の受け取りの後に、該第１の動作ハンドラ（３２）による該イベント予約の受け入れ決定に応答して、該第１の動作ハンドラ（３２）が、該第１のイベントマネージャ（３１）に肯定の確認を提供する、請求項５に記載の方法。
【請求項７】
前記第１の動作が、アプリケーションのダウンロード、アプリケーションの起動、ポップアップの立ち上げ、および実行中のアプリケーションへのイベントの発生の通知からなる群から選択される、請求項１に記載の方法。
【請求項８】
前記イベントブローカ（３０）が、前記第１の動作完了の検知に応答して、前記イベント予約の登録を解除する工程をさらに含む、請求項１に記載の方法。
【請求項９】
前記登録する工程が、格納デバイスに前記イベント予約を格納する工程を含み、前記登録を解除する工程が該イベント予約を該格納デバイスから削除する工程を含む、請求項８に記載の方法。
【請求項１０】
イベント予約のさらなる要求を受け取る工程と、
該さらなるイベント予約要求を登録する工程と、
前記イベントブローカ（３０）が前記イベント予約要求と該さらなるイベント予約要求との間に、リソース競合が存在することを決定し、該リソース競合を解消する工程と、
をさらに包含する、請求項１に記載の方法。
【請求項１１】
前記リソース競合を解消する工程が、前記イベントブローカ（３０）が前記イベント予約要求および前記さらなるイベント予約要求のランク付けを行う工程を包含し、該イベント予約要求が該さらなるイベント予約要求より高いランクを有し、該さらなるイベント予約要求によって示される動作を、該イベント予約要求によって識別される前記第１の動作の完了まで遅延させる、請求項１０に記載の方法。
【請求項１２】
前記方法が、記憶媒体に格納された実行可能なプログラムインストラクションによって実行される、請求項１に記載の方法。
【請求項１３】
イベント予約を仲介および管理するデバイスであって、
放送信号を受信するように構成される信号受信ユニットと、
第１のイベントマネージャ（３１）であって、該第１のイベントマネージャ（３１）が特定タイプのイベントを検知するように構成される、第１のイベントマネージャ（３１）と、
第１の動作ハンドラ（３２）であって、該第１の動作ハンドラ（３２）が特定タイプの動作を開始するように構成される、該第１の動作ハンドラ（３２）と、
イベントブローカ（３０）メカニズムと、
を含み、
該メカニズムは、イベント予約要求を受け取り、該イベント予約要求を登録するように構成されており、該要求が第１のイベントと、該第１のイベントが発生するとすぐに取られる第１の動作とを識別し、該イベントブローカ（３０）が該第１のイベントマネージャ（３１）および該第１の動作ハンドラ（３２）に通知し、
該第１のイベントマネージャ（３１）が該第１のイベントを検知し、該第１のイベントの該検知を該イベントブローカ（３０）に通知するように構成されており、
該第１の動作ハンドラ（３２）が、該イベントブローカ（３０）からの該第１のイベントの検知を知らせる通知の受け取りに応答して、該第１の動作を開始するように構成される、デバイス。
【請求項１４】
前記メカニズムが複数のイベント予約を受け取るように構成されており、該複数のイベント予約の各々が特定のイベントと、該特定のイベントが発生するとすぐに取られる特定の動作とを識別する、請求項１３に記載のデバイス。
【請求項１５】
前記メカニズムがさらに、前記第１のイベントマネージャ（３１）を、複数のイベントマネージャから識別し、選択するように構成されており、該第１のイベントマネージャ（３１）が、前記第１のイベントに対応する１つのタイプのイベントを検知するように構成されるものとして識別される、請求項１３に記載のデバイス。
【請求項１６】
前記第１のイベントマネージャ（３１）が前記第１の動作ハンドラ（３２）と直接通信するように構成されない、請求項１３に記載のデバイス。
【請求項１７】
前記メカニズムから前記イベント予約の通知を受け取った後に、前記第１のイベントマネージャ（３１）は、該イベント予約が該第１のイベントマネージャ（３１）に受け入れられるかどうかを決定し、該イベント予約の受け入れ決定に応答して、該メカニズムに肯定の確認を提供するように構成される、請求項１３に記載のデバイス。
【請求項１８】
前記イベント予約の受け入れに応答して、前記第１のイベントマネージャ（３１）が前記第１の動作ハンドラ（３２）に要求を伝えるように構成されており、該第１のイベントマネージャ（３１）からの該要求を受け取った後に、該第１の動作ハンドラ（３２）は該イベント予約が該第１の動作ハンドラ（３２）によって受け入られるかどうかを決定し、該イベント予約の該第１の動作ハンドラ（３２）による受け入れ決定に応答して、該第１のイベントマネージャ（３１）に肯定の確認を提供するように構成される、請求項１７に記載のデバイス。
【請求項１９】
前記第１の動作が、アプリケーションのダウンロード、アプリケーションの起動、ポップアップの立ち上げ、および実行中のアプリケーションへのイベントの発生の通知からなる群から選択される、請求項１３に記載のデバイス。
【請求項２０】
前記メカニズムがさらに、前記第１の動作完了の検知に応答して、前記イベント予約の登録を解除するように構成される、請求項１３に記載のデバイス。
【請求項２１】
さらに格納デバイスを含み、前記メカニズムが、該格納デバイス上に、前記イベント予約に対応する情報を格納するように構成されており、該メカニズムが、前記第１の動作の完了の検知に応答して、該格納デバイスから該情報を削除するように構成される、請求項２０に記載のデバイス。
【請求項２２】
前記メカニズムはさらに、
イベント予約のさらなる要求を受け取り、
該さらなるイベント予約要求を登録し、
前記イベント予約要求と該さらなるイベント予約要求との間に、リソース競合が存在するかを決定し、
該リソース競合を解消するように構成され、該さらなる要求が第２の動作を示す、請求項１３に記載のデバイス。
【請求項２３】
前記リソース競合を解消するために、前記メカニズムが前記イベント予約要求および前記さらなるイベント予約要求のランク付けを行い、該イベント予約要求が該さらなる予約要求より高いランクを有するという検知に応答して、前記第１の動作が完了するまで前記第２の動作を遅延させるように構成され、該イベント予約要求が該さらなるイベント予約要求より高いランクを有する、請求項２２に記載のデバイス。
【請求項２４】
前記デバイスが放送システムの受信器である、請求項１３に記載のデバイス。
【請求項２５】
前記メカニズムがプログラムインストラクションを実行する処理デバイスを含み、該プログラムインストラクションは、実行されたときに、該処理デバイスに、前記要求を受け取る機能および前記イベントを登録する機能を実行させる、請求項１３に記載のデバイス。
【請求項２６】
前記第１のイベントマネージャ（３１）および前記第１の動作ハンドラ（３２）が、前記デバイスにおいて実行するオペレーティングシステムからのアクセス可能なライブラリ拡張を含む、請求項２５に記載のデバイス。
【請求項２７】
前記メカニズムが複数の固有クライアントからの複数イベント予約を保持するように構成される、請求項１３に記載のデバイス。
【請求項２８】
前記イベント予約の各々が、対応するイベントを検知するように構成されるイベントマネージャ、および対応する動作を開始するように構成される動作ハンドラを識別する、請求項１３に記載のデバイス。
【請求項２９】
前記メカニズムが、前記イベント予約へのアクセスを、該アクセスおよび該イベント予約に関連付けられた認可に基づいて管理するように構成される、請求項１３に記載のデバイス。
【請求項３０】
前記イベント予約の各々が対応する満期時間を有し、前記メカニズムが、該イベント予約のうちの該満期時間を経過したイベント予約の登録を解除するように構成される、請求項２８に記載のデバイス。
【発明の詳細な説明】
【０００１】
（発明の背景）
（１.発明の分野）
本発明は概して放送テレビジョンシステムに関し、さらに詳細には、放送テレビジョン受信器におけるイベントの検知に応答して、それらのイベントを予約し、動作を開始するシステムおよび方法に関する。
【０００２】
（２．関連技術の説明）
特定のイベントを検知し、こうしたイベントに応答して、特定の動作を開始できることはコンピュータシステムにおいて有用なことである。例えば、デスクトップコンピュータシステムでは、Ｅメールが受信されると、Ｅメールアイコンが表示されることが望ましいことがあり得る。さらに、コンピュータシステムは特定の時間に特定のアプリケーションを起動するように構築され得る。同様のメカニズムがビデオカセットレコーダ（ＶＣＲ）にもあり得る。これらのＶＣＲは通常、内部クロックが所定時間になると特定チャンネルの録画を予約することができるように構成される。さらに、ＶＣＲは放送信号のアナログ垂直帰線消去期間（ＶＢＩ）で送信された特定の情報（例えば、特定のテレビ番組の開始を示す情報）を受信する場合に、あるチャンネルの録画を開始するようにも構成され得る。Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｆｏｒｕｍ（ＡＴＶＥＦ）によって提案されるテレビジョンシステムでは、テレビジョン放送信号のトリガによって、テレビジョン受信器が特定のＨＴＭＬページを表示する。
【０００３】
しかしながら、上記のシステムには制約があり、そのために放送テレビジョン受信器における一般化されたイベント予約メカニズムにまで広げられない。例えば、デスクトップコンピュータシステムのＥメールノーティファイアおよびカレンダーサービスの場合は、検知できるイベントおよびそれに応答して開始できる動作は特に特定のアプリケーション用に定義されている（例えば、Ｅメールアプリケーションは新規のＥメールメッセージの受信に応答して、アイコンを表示する）。このようなアプリケーションは他のアプリケーションが用いることができない内部メカニズムを持っている。異なるアプリケーションがさらなるタイプのイベントを検知して、さらなるタイプの動作を開始する必要がある場合、通常、このアプリケーションはそうしたイベントタイプを検知し、各動作を開始するために、独自のメカニズムを備える必要がある。このタイプのメカニズムは静的に定義されたイベントおよび動作を有し、さらなるアプリケーションコード（ならびにコードを格納するさらなるメモリ）も要求するので、このタイプのメカニズムは放送テレビジョン受信器の限られたリソースには適さない。放送信号で送信されたトリガ（例えばＶＢＩまたはＡＴＶＥＦトリガ）を用いるメカニズムはこれと同じ制約を受ける。これらのトリガは静的に定義されたイベントを検知して、静的に定義された動作を開始する。さらに、動作にアプリケーションの起動が含まれる場合は、そのアプリケーションが存在していなければならない。すなわちイベントを検知する際にアプリケーションをダウンロードし、起動することはできない。従って、これらのメカニズムは放送テレビジョン受信器における一般化されたイベント予約システムには適さない。
ＷＯ９８／４３４２７において、以下のようなデジタル衛星ラジオで使用する受信器／デコーダまたはテレビジョンシステムが公知である。そのテレビジョンシステムは、デコーダを含み、マイクロプロセッサを備えるクレジットカードまたは銀行カードを受け入れるようになっており、クレジットカードまたは銀行カードが有するデータが読み取られ得、データをクレジットカードまたは銀行カードが有するマイクロプロセッサに入力され得るようにクレジットカードまたは銀行カードがその受信器／デコーダの動作位置に挿入された場合、そのマイクロプロセッサとインタラクトするようになっている。ＰＩＮ番号は、記載されている遠距離コントローラを使って、安全に受信器／デコーダに送信され得る。本発明の用途は、ペイパービューテレビジョン、テレショッピング、テレバンキングを含み、ＷＯ９８／１１７２４においては、圧縮デジタルテレビジョン放送スタジオ（１００）のコマンドおよび制御アーキテクチャを含む。そのアーキテクチャは、セッションマネージメント、スタジオ活動のリアルタイム制御、高レベルの制御を提供しないオブジェクトとの通信を確立するための代用オブジェクトの使用、スタジオフィルタデバイス（１５４）の制御、およびストリームマネージメントの供給を含む。本発明は、特にデジタルスタジオに適したオブジェクトアーキテクチャを含む。
【０００４】
（発明の要旨）
前述で概要を述べた問題のうち、１つ以上の問題は本発明の種々の実施形態によって解決され得る。これらの実施形態は、放送テレビジョンシステムに関連したイベントを予約し、予約されたイベントの発生に応答して動作を開始する方法、フレームワーク、およびデバイスを含み得る。
【０００５】
１つの実施形態は、クライアントがイベントの記述やイベントが発生したらすぐに実行されなければならない動作の記述を登録することによって、そのイベントを予約する方法を含む。また、イベントを検知するために使用されるエージェント（または「イベントマネージャ」）もまた動作を開始する動作ハンドラと同様に、特定され得る。イベントおよび動作を記述する情報（「イベント予約」）はイベントブローカによって格納される。この情報はイベントブローカによって適当なイベントマネージャおよび動作ハンドラに伝えられる。イベントを検知するとすぐに、イベントマネージャは、今度はイベントの発生をイベントブローカに通知する。イベントブローカは、今度は動作ハンドラにイベントの発生を通知する。その後動作ハンドラが動作を開始する。動作が完了すると、イベントブローカはイベント予約を解除する（例えば、予約されたイベントのリストからイベント予約を削除する）。
【０００６】
実施形態の１つは、前述の方法を実現するコンピュータ読取記録媒体を含む。記憶媒体はフロッピー（登録商標）ディスク、磁気テープ、光ディスク、ＲＡＭ、ＲＯＭ、フラッシュメモリなどを含み得る。記憶媒体はプロセッサの作業を管理する、格納されるプログラムインストラクションを有する。プログラムインストラクションは上述の方法を実行するプロセッサによって実行可能である。
【０００７】
１つの実施形態では、イベント予約メカニズムは、双方向テレビジョン受信器のソフトウェアフレームワークを含む。そのフレームワークは、受信器のオペレーティングシステムコアへの拡張であるライブラリで実行される。ライブラリは、イベントブローカ、ならびに１つ以上のイベントマネージャおよび動作ハンドラを含む。イベントブローカはイベントエントリを登録および追跡するように構成されており、各エントリガイベントとそれに対応する動作を記述している。イベントブローカはイベントが予約される場合、適切なイベントマネージャに通知し、またイベントが発生するときに適切な動作ハンドラに通知するように構成される。イベントブローカは、それぞれが異なるタイプのイベントを検知するように構成されるイベントマネージャと、それぞれが異なるタイプの動作を開始するように構成される動作ハンドラとの集中管理を提供する。このフレームワークによって提供されるモジュラリティは、イベントブローカが新規のイベントマネージャおよび動作ハンドラによって簡単に更新されることを可能にする。
【０００８】
１つの実施形態では、イベント予約メカニズムは放送テレビジョンシステムの受信器で実行される。１つ以上のクライアント（例えば、受信器で実行しているアプリケーション）は、対応するイベントが発生するとすぐに特定の動作が取られることを要求する。動作は、アプリケーション起動、ポップ−アップダイアログボックスを開くこと、実行アプリケーションへのデータ供給、その他の動作等を含む。イベントは、テレビ番組の開始、ダウンロードされたモジュールの受信、特定の信号またはデータの受信、所定の回数への到達等を含み得る。受信器は、受信器内のプロセッサ上で実行しているイベントブローカを使って、クライアントがイベントとその対応動作を予約することができるように構成されている。イベントブローカは、イベントおよび動作を登録して、受信器のメモリに格納する。各イベントについて、イベントブローカはそのイベントの受信環境を監視するように、イベントマネージャに通知する。イベントが検知されると、イベントマネージャはイベントブローカに通知する。今度はイベントブローカは対応する動作を開始する動作ハンドラに通知する。
【０００９】
（好適な実施形態の詳細な説明）
本発明のその他の目的および利点は、以下の詳細な説明を読み、以下の添付図面を参照にすればすぐに、明らかになる。
【００１０】
本発明の１つの実施形態を以下に述べる。本実施形態は双方向テレビジョンシステムの受信器で実行されるメカニズムを含む。このメカニズムはクライアントアプリケーションがイベントおよびそれに対応する動作を特定することを可能にし、イベントが発生する場合、動作が開始される。メカニズムは、概してイベントブローカ、１つ以上のイベントマネージャ、および１つ以上の動作ハンドラを含む。イベントはイベントブローカを介して予約（または登録）される（本明細書中に述べる「予約されたイベント」とは、対応する動作を含み得、イベントが予約される場合にイベントブローカによって記録される他の関連情報を含み得る）。イベントブローカは、イベントが予約されたことをイベントマネージャのうちの１つに通知する。その後、そのイベントマネージャは予約されたイベントについての受信器のデータおよび動作を監視する。予約されたイベントが検知される場合、イベントマネージャはイベントブローカに通知し、今度はイベントブローカが動作ハンドラのうちの１つに通知する。その後、動作ハンドラは検知されたイベントに対応した動作を開始する。
【００１１】
イベントブローカが、予約されたイベントに関する情報の集中管理と格納を提供するようになっている一方、イベントマネージャはそれぞれ、特定タイプのイベントを検知するようになっている。例えば、１つのイベントマネージャはＥメールの受信を検知するように構成され得、別のイベントマネージャは放送信号のプログラムモジュールを検知するように構成され得る。各イベントマネージャによって検知されるイベントのタイプは任意に決定され、１つのイベントマネージャは１つまたはいくつかのタイプのイベントを検知するように構成され得る。同様に、各動作ハンドラは、アプリケーションの起動またはポップ−アップウィンドウの立ち上げのような特定タイプの動作を開始するようになっている。イベント予約メカニズムは複数のイベントマネージャおよび動作ハンドラをサポートしているので、第３者がメカニズムに組込み可能な独自のイベントマネージャと動作ハンドラを開発することができるモジュール様式で、イベント予約メカニズムを実現することができる。（開示されるイベント予約メカニズムはモジュラマネージャおよび動作ハンドラを採用し得るが、既存のアプリケーションに含まれるイベントマネージャおよび動作ハンドラも採用し得ることに注意しなければならない。例えば、クライアントアプリケーションは、Ｅメールアプリケーションのイベントマネージャを使って、入ってくるＥメールを検知するイベント予約を登録し得る）。
【００１２】
従って、検知される必要があり得る各タイプのイベント毎に、対応するイベントマネージャがある。開始される必要のある各タイプの動作毎に、対応する動作ハンドラがある。各イベントマネージャはイベントブローカと対話して、その特定のイベントマネージャに対応するタイプのイベントを監視し、検知する。同様に、各動作ハンドラはその特定の動作ハンドラに対応するタイプの動作を開始し得る。このようにイベント予約メカニズムは、イベント予約の集中管理を提供するが、イベント予約メカニズムは十分柔軟性があるので、多くの異なるタイプのイベントおよび対応する動作に適応し得る。これによって、双方向テレビジョンシステムのような制限されたリソースを有するシステムに適した、用途の広い、しかしコンパクトなイベント予約メカニズムが提供される。
【００１３】
上記で示されたように、１つの実施形態は双方向テレビジョンシステムで実現される。図１を参照すると、放送ステーション１１から、複数の受信ステーション１２〜１４への双方向テレビジョン信号の配信を示す構成図が示されている。双方向テレビジョン信号は送信媒体１５を介して、各受信ステーションに配信される。送信媒体は、サテライト、ケーブル、テレコ、ＭＭＤＳ（マイクロ波）または地上送信システムを含む、任意の適切な放送媒体を含み得る。いずれの送信媒体が用いられようとも、放送ステーションおよび受信ステーションは適切な送信器および受信器で構成されると想定される。
【００１４】
図２を参照すると、受信ステーションで使用され得る受信器２０が示されている。本実施形態では、受信器２０はテレビジョン用セット−トップボックスで実現される。その他の実施形態では、受信器に連結されるテレビジョンのような受信ステーションの他の構成要素の回路に、受信器は組み込まれ得る。受信ステーションへの放送である双方向テレビジョン信号は、信号受信器２１によって受信される。放送信号に含まれるテレビジョン番組編成は処理回路２２によって処理され、表示回路２３による表示用にフォーマットされ得る。その後、フォーマットされた信号はテレビジョンに送信され得る。そして、その信号はテレビジョンでユーザに表示され得る。
【００１５】
双方向テレビジョン信号は、テレビジョン番組編成に加えて、情報を含み得る。例えば、双方向性アプリケーションモジュールまたは管理信号が放送信号に組み込まれ得る。このさらなる情報は、受信器２０の構成要素のうちの１つ、例えば、処理ユニット２２、またはさらに信号受信器２１などによって、信号から分離し得る。さらなる情報は信号の双方向性コンテンツとみなされ得るが、このさらなる情報は、典型的には、プロセッサ２４および／またはメモリ２５に提供される。アプリケーションを含む双方向性コンテンツは、プロセッサ２４によって実行され得る。他の双方向性コンテンツはプロセッサ２４によって解釈され得、ユーザのテレビジョンに出力される双方向性オーディオまたはビデオが発生され得る。ユーザはＩ／Ｏインターフェース２６に連結するＩ／Ｏデバイスを介して、アプリケーションまたは他の双方向性コンテンツとインタラクトし得る。（双方向テレビジョンシステムの機能性についての前述の説明は、このようなシステムのほんの１例であり、これに限らないことに注意しなければならない。）
受信器２０に入力される放送信号は、受信器の環境の一部を形成する。受信器の環境はまた、受信器内で実行しているアプリケ−ションからの信号、ユーザの受信器へのＩ／Ｏ入力、外部（例えば、モデム）信号、クロック信号、カレンダー信号、ならびに受信器内部の（そうでない場合には、受信器にとって利用可能な）他の信号及び条件も含む。イベント予約メカニズムは受信器の環境の信号および条件を監視して、イベントを検知し、その後トリガに関連付けられた動作を検知する。
【００１６】
イベント予約メカニズムは受信器のプロセッサ上で実行する。イベント予約メカニズムは、クライアントがイベントと、イベントが生じる場合にトリガされる必要がある動作とを特定することを可能にする。図３を参照すると、１つのイベント予約に関するこれらの構成要素間のインタラクションが例示されている。図３では、イベント予約メカニズムの機能は、イベントブローカ３０と、特定のイベントマネージャ３１と、特定の動作ハンドラ３２とに分けられる。イベントブローカはイベント予約をクライアント３３から受けとる。イベントブローカは、そのイベントと対応動作を登録し、その後、特定されたイベントの受信器環境を監視するように、イベントマネージャに通知する。次いで、イベントが発生する場合、イベントマネージャはイベントブローカに通知する。イベントブローカは、今度はイベントが検知されたことを動作ハンドラに通知する。動作ハンドラは、その後、もともとクライアントによって特定された動作を開始する。
【００１７】
イベントブローカはイベントの登録または予約を担当する。イベントブローカは、予約された各イベントに関する情報を中央部に格納することによって、イベントの登録または予約を行う。この中央部は必ずしも１つのメモリデバイスであるとは限らず、リストまたはイベント予約がまとめられている他のなんらかのタイプのデータ構造を含み得る。（イベント予約は、受信器が再起動したときに失われないように、好ましくは不揮発性メモリに格納されることに注意しなければならない。）イベントブローカは、予約されたイベントの照会、修正または終了を含む、予約されたイベントへのアクセスを管理し得る。
【００１８】
イベントブローカによって格納された情報は、検知されるイベントやそのイベントの検知に応答して、取られる動作を定義する（複数の動作が１つのイベントに関連付けられ得るが、この特定の実施形態では、動作はイベントが検知された後に順次行わなければならない）。１つの実施形態では、イベントは、イベントおよびイベントを記述する文字列を検知するために使われるイベントマネージャの名前によって定義される。この文字列はイベントマネージャのシンタックスを使用してイベントを識別するキャラクター文字列である。文字列はイベントブローカにとって理解できないものであり得る。しかし、イベントブローカは単にイベントマネージャにイベントが予約されたことを通知し、その文字列を渡す必要があるだけなので、イベントブローカはその文字列を理解する必要はない。同様に、動作はこの実施形態においては、動作ハンドラの名前と動作ハンドラのシンタックスを使ってイベントを識別する文字列とによって定義される。文字列はイベントブローカにとって理解できるものである必要はない。
【００１９】
実施形態によっては、イベントが予約されるときに格納される情報は他の情報を含み得る。例えば、情報は、動作によって用いられてイベントブローカに受信器のリソースを管理させ得るリソースのリストとイベントおよび／または動作のユーザ読取可能記述を含むキャラクター文字列と、イベントのタイムリミットまたは終了期日と、あるいは予約されたイベントへのアクセス、修正、または終了することが可能なアプリケーションまたはクライアントを定義するイベントに関連付けられた特権とを含み得る。（他の実施形態では、イベント予約の管理において有用になり得る、異なる情報を含み得る。）特権は、所定の様態で割り当てられ得る（例えば、特定のクライアントまたはクライアントグループに与えられる）か、または他のメカニズム（例えば、クライアントが有し、予約されたイベントへのアクセスが求められる場合、イベントブローカに提示される資格）を使って決定され得ることに注意しなければならない。
【００２０】
イベントブローカは同じリソースを要求する２つ以上の動作がトリガされ得る場合、リソース競合の解消を行う。すなわち、２つの動作が同じリソースを要求する場合、動作の１つだけを開始され得るので、イベントブローカはどの動作が開始され、どの動作が遅延されるかを決定する必要がある。イベントブローカがこれらの競合を解消する必要性から、１つの実施形態では、イベントブローカはまた、予約されたイベントのランクを決定するようにも構成されている。一旦、より高いランクの動作が完了したら、次に高いランクの動作がトリガされ得る。イベントブローカは予約されたイベントをランク付けするように構成され得る。１つの実施形態では、イベントブローカによって付けられるランクはイベントが予約された順番に基づく。ランクはまた適切な特権を有する管理アプリケーションによって明確に設定され得る。管理アプリケーションはランキングセッションを開き、予約されたイベントのランクを設定し、その後イベントブローカを呼び出して、新たなランクを確認し格納し得る。
【００２１】
各イベントマネージャは、１つ以上の特定のイベントタイプを検知するように構成される。イベントマネージャは、種々の信号および受信器の環境の条件を監視して、イベントがいつ発生するかを決定する。イベントは、単一の信号または条件であり得るか、またはこのような信号および条件の１セットでもあり得る。イベントは予約されたときにイベントブローカが格納した情報によって定義され得る。複数のイベントマネージャが同時に受信器環境を監視して、対応するイベントを検知し得る。複数の動作が１つのイベントに関連付けられ得るということにも注意しなければならない。１つの実施形態では、単一のイベントマネージャが、記述されたイベントを検知し、１つ以上の動作ハンドラが関連付けられた動作を行う。この実施形態では、動作は順次行われるが、他の実施形態ではそれらの動作は同時に行われ得る。同様に、複数のイベント予約が複数のイベントを単一の動作に関連付け得る。
【００２２】
各動作ハンドラは、１つ以上の特定タイプの動作を開始するように構成される。場合によっては、動作のタイプは比較的広く定義され得る。例えば、動作はアプリケーション起動からなり得る。明らかに、この動作は広範囲の環境において求められ得る。なぜならそれぞれが関連付けられたアプリケーションの起動をトリガするようになっている、多くの異なるイベントを検知することが望ましいことがあり得るからである。複数の動作が同時に作動するようにトリガされ得るが、本実施形態において、イベントブローカが動作間のリソース競合があるかどうかを決定し、それらの競合を解消する役割を、（最高ランクの動作をトリガし、競合動作をトリガする前に、その動作を完了させることによって）果たす。
【００２３】
上記で説明したように、イベント予約メカニズムはあるタイプのイベントまたは動作のみの処理に限定されない。多くの異なるタイプのイベントおよび動作を提供し得る。これは、複数のイベントマネージャおよび複数の動作ハンドラと関連して稼動し得る単一のイベントブローカの使用を介して達成される。各イベントマネージャは、特定タイプのイベントを検知するように構成される。イベントが予約される場合、その特定タイプのイベントを検知するように構成されたイベントマネージャに通知される。同様に、イベントが検知される場合、その検知されたイベントに対応する特定タイプの動作が開始するように構成された動作ハンドラに通知される。必要ならば、イベントブローカは、予約されるいくつかのイベントそれぞれに対して、異なるイベントマネージャおよび異なる動作ハンドラを呼び出し得る。反対に、いくつかのイベントは同じイベントマネージャまたは同じ動作ハンドラを使用し得る。（それゆえ、イベントマネージャおよび動作ハンドラは、特有のタイプのイベントまたは動作あるいはイベントまたは動作のセットを処理するように構成され得るという点において独特であり得るが、これは各イベントマネージャまたは動作ハンドラが１回しか使用または実行できないことを意味しないことに注意しなければならない。）
前述の説明は例示することを意図していることに注意しなければならない。他の実施形態では、イベント予約メカニズムにおける特定の構成要素に関して上記で説明された機能のなかには、再区分され得るものもある。例えば、イベントが検知される場合、イベントマネージャは、イベントブローカに通知し、イベントブローカから動作ハンドラに通知させるのではなく、関連付けられた動作ハンドラに直接通知するように構成され得る。このような変更例は、本開示範囲内であるとする。
【００２４】
図４を参照すると、受信器において実行するソフトウェアの層が示される。受信器ソフトウェアはいくつかの層のソフトウェアからなる。カーネルおよびドライバ層は直接ハードウェアとインターフェースをとる。本明細書中では、その次の層を「ミドルウェア」と呼ぶ。ミドルウェア層はカーネルおよびドライバに依存しており、ミドルウェア層自身は各ハードウェアプラットフォームについて再コンパイルされ得る１セットのライブラリからなる。アプリケーション層は、ミドルウェアのライブラリによって利用可能になるサービスを使うアプリケーションからなる。図４で示す本実施形態では、イベント予約メカニズムはミドルウェアの一部である。それゆえ、アプリケーション層は他のミドルウェアライブリと共に、イベント予約メカニズムとインターフェースをとる。
【００２５】
アプリケーションがミドルウェアによって提供されるサービスに依存しているので、アプリケーションのライフサイクルはある程度、ミドルウェアによって制御される。例えば、ときにはアプリケーションが、インタプリタを使用して実行される必要があるハードウェア独立フォーマットまたはミドルウェアで書きこまれることがある。同様に、イベント予約は、ある程度イベント予約ライブリに依存している。利用可能なイベントマネージャまたは動作ハンドラが更新される場合、またはシステムが再起動して、イベントマネージャまたは動作ハンドラが削除される場合は、利用できないイベントマネージャまたは動作ハンドラに依存しているイベント予約は予約リストから削除されなければならないこともあり得る。あるいは、互換性のあるイベントマネージャまたは動作ハンドラが、利用できない互換性のあるイベントマネージャまたは動作ハンドラの代用となり得る。
【００２６】
上記で示すように、本実施形態におけるイベント予約メカニズムはミドルウェアライブラリとして実現される。このライブラリはオペレーティングシステムコアの拡張である。ライブラリは、初期的には、制限された１セットのイベントマネージャおよび動作ハンドラしか含む必要がないと考えられる。例えば、最初はカレンダマネージャおよび１つ以上のイベントマネージャで十分である。同様に、基本的なインプリメンテーションでは、ダイアログボックスをポップアップさせ、アプリケーションを起動させる動作ハンドラで十分であり得る。さらなるイベントマネージャおよび動作ハンドラが、必要に応じて追加され得る。新規イベントマネージャおよび動作ハンドラは、新規のイベントタイプおよび動作タイプを提供する必要があるときに書き込まれ得る。さらなるイベントマネージャおよび動作ハンドラは、イベント予約メカニズム全体を修正する必要なしに、ライブラリに追加され得る。イベント予約メカニズムはこの特定の実施形態においてライブラリで実行されるが、他の実施形態ではアプリケーションレベルで実行され得ると考えられることが注意されるべきである。
【００２７】
図５を参照すると、イベント予約メカニズムによって実行される基本的な方法の高レベルフローチャートが示されている。クライアントアプリケーションは、イベントブローカを使ってイベントを予約して、イベントおよび対応する動作を特定する。イベントブローカは適切なイベントマネージャおよび動作ハンドラにイベントおよび対応動作を通知して、その後予約されたイベントを格納する。（この実施形態では、そのイベントを予約すべきかどうかを確認するために、イベントマネージャおよび動作ハンドラにイベントおよび動作を通知することに注意しなければならない。この確認は他の実施形態では行われ得ない。）その後イベントマネージャは、そのイベントについて受信器の環境を監視する。（点線の矢印はイベントが検知される前に複数の発生が介在し得ることを示す。）イベントが検知される場合、イベントマネージャはイベントブローカに通知する。イベントブローカは、イベントが検知されたことをイベントマネージャによって通知される場合、そのイベントに対応する動作が行われる必要があることを動作ハンドラに通知する。
【００２８】
図６〜図９を参照すると、本実施形態でのイベント予約メカニズムの動作がさらに詳細に示されている。図中では、イベントブローカ（ＥＢ）、イベントマネージャ（ＥＭ）、および動作ハンドラ（ＡＨ）はそれぞれ省略形で示されていることに注意する。これらの構成要素のうちの１つから別の構成要素への通信は、送信器から受信器への矢印で示されていることにも注意しなければならない。
【００２９】
本実施形態におけるイベントの予約が、図６のフローチャートで示されている。クライアントのアプリケーションは、まずイベント予約に必要な情報をイベントブローカに送信する。イベントブローカは、どのイベントマネージャに通知する必要があるかを決定して、そのイベントマネージャにイベントを予約する要求を送る。イベントマネージャがイベントを予約し得る場合、確認がイベントブローカに送られる。イベントマネージャがそのイベントを予約できない場合、非確認がイベントブローカに送られ、その後イベントブローカがクライアントにエラー通知を送る。イベントマネージャが予約要求を受け入れる場合は、それと同様の要求を、その要求において識別される動作ハンドラに送る。動作ハンドラが要求を受け入れない場合は、非確認がイベントマネージャに送られ、今度は、イベントマネージャがエラー通知をクライアントに送る。要求が動作ハンドラによって受け入れられる場合は、確認がイベントマネージャに送られる。その後イベントブローカは新規イベントが予約されたことをコントロールタスクに通知する。
【００３０】
前述の説明で、イベントブローカは、新規イベントが予約されたことをコントロールタスクに通知する前に、要求（または通知）をイベントマネージャおよび動作ハンドラに送る。イベントブローカはイベントおよび動作が適切に記述されているという確認をイベントマネージャおよび動作ハンドラから得るために、この動作を行う。本実施形態では、上記で説明したように、イベントマネージャおよび動作ハンドラが、それぞれ、理解できるシンタックスを使ってイベントおよび動作を定義されるので、これが必要である。それゆえ、イベントブローカは、イベントマネージャおよび動作ハンドラの助けなしではイベント予約情報を確認できないこともあり得る。
【００３１】
イベント検知後の動作トリガが、図７のフローチャートに示されている。イベントマネージャがイベントを検知する場合、イベントブローカに通知する。イベントブローカは関連付けられた動作を実行するために必要なリソースが、他のユーザ（例えば、現在他のイベントに応答して作動している動作）のリソースと競合を提示するかどうかを判定する。リソース競合がない場合、イベントブローカはイベントマネージャに動作開始要求を送る。リソース競合がある場合、イベントブローカは、検知されたイベントと関連付けられた動作が、競合する動作間で最優先のものかどうかを決定する。その動作が最優先であれば、イベントブローカは競合を示す現在実行中の動作より優先させるように、動作ハンドラに要求を送る。動作ハンドラはこの要求を除外するか、または拒否し得る。要求が受け入れられる場合、イベントブローカはイベントマネージャに動作開始要求を送る。動作ハンドラが現在実行中の動作に取って代わるというイベントブローカの要求を除外しなかった場合、その動作は休止中になる。すなわち、イベント予約メカニズムは保留動作の終了を待ち、その後、リソースの競合チェックから始めて、前述のステップを繰り返す。
【００３２】
イベントブローカがイベントマネージャに動作開始要求を送った後、イベントマネージャは要求を受け入れるかまたは拒否し得る。要求が拒否された場合は、その動作は休止する。この例では、動作は単に保留動作が終了するまで休止するのではない。その動作はイベントマネージャまたはイベントブローカが再作動またはその動作を終了するまで休止する。イベントマネージャが動作開始要求を受け入れる場合、同様の要求がイベントブローカから動作ハンドラに送られる。動作ハンドラがその要求を拒否する場合、イベントブローカはイベントマネージャに動作が中止されたことを通知する。動作ハンドラが要求を受け入れる場合、動作は動作ハンドラによって開始される。動作ハンドラはまた、イベントブローカに確認を送る。
【００３３】
上記で述べた実施形態では、イベントブローカは、動作に対応するイベントが検知されるとすぐにその動作の開始を試みるのではないことに注意しなければならない。その代わり、イベントブローカはリソース競合をチェックし、他の動作に取って代わる要求を出し得る。その結果、その間にイベントを定義する条件のいくつかが変化し得るような遅延があり得る。従って、イベントに関連付けられた動作がすでに古くなり得る。それゆえ、イベントブローカは、リソースチェック後、および動作開始前に、イベントマネージャに照会する。
【００３４】
動作が一旦開始すると、完了するか、または終了するかのいずれかであり得る。図８は、動作の正常完了のフローチャートである。動作が正常に完了する場合、動作完了後すぐに動作ハンドラはイベントブローカに通知を送る。今度は、イベントブローカがイベントマネージャに完了の通知を送る。その後、イベントはイベントブローカによって、予約されたイベントのリストから削除される。イベントが「単発の」イベントである場合のみ削除されることに注意しなければならない。イベント予約が、そのイベントの複数回の発生に適用するようになっている（例えば、毎週同じ時間にテレビ番組を録画する）場合、イベントは削除されない。
【００３５】
図９は、動作終了のフローチャートである。この図では、クライアントが動作の終了を要求する。要求はイベントブローカに送信される。イベントブローカは動作ハンドラに終了要求を送る。動作ハンドラは動作を終了させ、イベントブローカに確認を送る。その後イベントブローカはイベントマネージャに終了の通知を送る。イベントマネージャに通知した後、（そのイベント予約が複数回の発生に適用されない場合）イベントブローカは予約されたイベントリストから対応するイベントを削除する。
【００３６】
前述の例が１つの実施形態において用いられている方法に対するものであることに注意しなければならない。この例は制限ではなく例示することを意図するものである。説明されている方法に対して、種々の改良が本発明の他の実施形態において採用され得る。
【００３７】
前述の創意に富む予約メカニズムは、多くの状況で利用できる。以下にその例を記載する。
【００３８】
一例としては、イベントマネージャはテレビ番組が開始する時間と日付を検知するように構成されたカレンダエージェントであり得る。指定された時間に、カレンダエージェントはイベントブローカに通知し得る。イベントブローカは一定時間、ＶＣＲ録画を開始するように構成される動作ハンドラに通知し得る。あるいは、動作ハンドラが、テレビ番組の録画を承認するようにユーザに促すダイアログボックス、または単にテレビ番組が始まることをユーザに通知するダイアログボックスをポップアップし得る。
【００３９】
また、別の例としては、イベントマネージャは、放送信号における特定タイプのサービス情報を待つように構成されたブックマークエージェント（例えば、１６／９フォーマットでサッカーおよび映画に関するテレビ番組を識別するメタデータ）であり得る。指定されたサービス情報が検知される場合、イベントブローカに通知される。その後イベントブローカは動作ハンドラに通知し、その動作ハンドラはこの情報をユーザに提示するか、番組または映画の録画を開始し得る。
【００４０】
さらに別の例では、イベントマネージャはテレテキストストリーム内の特定の情報（例えば、株式情報）を見るように構成されたテレテキストエージェントであり得る。この情報が検知される場合、イベントブローカに通知し、今後はイベントブローカは、情報を捕捉し、その情報をユーザに提示する動作ハンドラに通知する。
【００４１】
また別の例では、イベントマネージャは特定のネットワーク、または特定グループチャンネル（ときにはブーケと呼ばれる）内でテレビチャンネルを検知するように構成されたサービスリストエージェントであり得る。イベントマネージャがチャンネルを検知する場合、イベントブローカに通知して、イベントブローカは動作ハンドラに通知する。動作ハンドラはテレビチャンネルを識別し、そのチャンネルをチャンネルリストに追加するように構成される。このように、チャンネルのリストが動的に構築され得る。予約されたイベントが定義されるので、チャンネルリストが完成する場合、アプリケーションが起動してユーザがリストをブラウズすることを可能にする。
【００４２】
さらに別の例では、イベントマネージャは放送信号で実現されるＥメールを検知するように構成され得る。Ｅメールを検知するとすぐに、イべントブローカおよび動作ハンドラに通知する。動作ハンドラは、受信器にユーザに対してブザーを鳴らさせるか、テレビジョン画面にアイコンを表示させてＥメールが到着したことをユーザに知らせる小さなアプリケーションを起動するように構成されている。
【００４３】
さらに別の例では、イベントマネージャは、特定のカルーセルファイルまたはモジュール用の放送信号を監視するように構成され得る。対応動作ハンドラは、ファイルまたはモジュールが受信された場合、あるいは修正または更新されたコピーが受信された場合はいつでも、アプリケーション（例えば株式表示器アプリケーション）に通知するかまたはアプリケーションを起動するように構成され得る。
【００４４】
さらに別の例では、イベントマネージャはセット−トップボックス（受信器）に格納される必要がある放送プロバイダが作成したユーザプロフィールを検知するように構成され得る。動作ハンドラはユーザプロフィールを獲得しそれをセット−トップボックスに格納するように構成される。
【００４５】
本発明は特定の実施形態に関して説明されてきたが、実施形態は例示のためのものであり、本発明の範囲はこれらの実施形態に限られないことが理解される。説明されている実施形態に対して多くの変更例、改良、追加、改善が可能である。これらの変更例、改良、追加、および改善は、前述の請求項において詳細に記載される、本発明の範囲内に収まり得る。
【図面の簡単な説明】
【図１】    図１は、１つの実施形態における、１つの放送ステーションから複数の受信ステーションへの、双方向テレビジョン信号の配信を示したブロック図である。
【図２】  図２は、１つの実施形態における、双方向テレビジョンシステムで使用される受信器の機能ブロック図である。
【図３】  図３は、１つの実施形態における、イベントブローカ、イベントマネージャおよび動作ハンドラ間のインタラクションを示すブロック図である。
【図４】  図４は、１つの実施形態における、受信器で実行するソフトウェアの層を示す図である。
【図５】  図５は、１つの実施形態における、イベント予約メカニズムによって実現される基本的な方法の高レベルフローチャートである。
【図６】  図６は、１つの実施形態における、イベントの予約を示すフローチャートである。
【図７】  図７は、１つの実施形態における、イベント検知後の動作のトリガを示すフローチャートである。
【図８】  図８は、１つの実施形態における、動作の正常な完了を示すフローチャートである。
【図９】  図９は、１つの実施形態における、動作の終了を示すフローチャートである。
【図１】
0004455799.tif 000002
【図２】
0004455799.tif 000003
【図３】
0004455799.tif 000004
【図４】
0004455799.tif 000005
【図５】
0004455799.tif 000006
【図６】
0004455799.tif 000007
【図７】
0004455799.tif 000008
【図８】
0004455799.tif 000009
【図９】
0004455799.tif 000010