本発明は、ブロードキャスタから放送された信号を受信するように適合された受信器が、第１の独立したフィーチャの実行を処理する方法に関する。 本発明は、放送信号を送信するように適合されたブロードキャスタが、受信器により実行されるべき第１の独立したフィーチャを放送する方法にも関する。 本発明は、ブロードキャスタから放送された信号を受信するように適合され、第１の独立したフィーチャの実行を処理するように適合された受信器にも関する。 本発明は、放送信号を送信するように適合され、受信器により実行されるべき第１の独立したフィーチャを放送するように適合されたブロードキャスタにも関する。 更に、本発明は、受信器により実行されるべき第１の独立したフィーチャを放送する放送信号に関する。

マルチメディア・ホーム・プラットフォーム（ＭＨＰ）は、インタラクティブ・デジタル・フィーチャと、これらのフィーチャを実行する端末との間の汎用インターフェースを規定する。 このインターフェースは、異なるＭＨＰ端末インプリメンテーションの特定のハードウェア及びソフトウェアの細部から異なるプロバイダのフィーチャを切り離す。 これは、デジタル・コンテンツ・プロバイダが、ローエンドからハイエンドまでのセットトップボックス、統合デジタルテレビセット、及びマルチメディアＰＣに及ぶ全てのタイプの端末にアドレスすることを可能にする。 ＭＨＰは、既存の成功したＤＶＢオープンスタンダードを衛星、ケーブル、地上波及びマイクロ波システムを含む全ての伝送ネットワークにおける放送及びインタラクティブサービスに拡張する。

ＭＨＰフィーチャは、ディレクトリ構造内に配置された１つ又は複数のファイルからなる。 これらのファイルは、コード、データ及び／又は画像を含む。 このようなファイルシステムは、１つ（又は複数）のＤＳＭＣＣカルーセル内に配置される。

ＤＳＭ−ＣＣ規格の完全な説明は、ＩＳＯ／ＩＥＣ１３８１８−６内で見つけられることができる。 これは、ブロードキャスタが、ＭＰＥＧ−２プライベートセクションの上に“仮想ファイルシステム”を放送することを可能にする。 受信器は、この場合、この仮想ファイルシステムをナビゲートし、ここからデータを取り出すことができる。 前記規格は、サーバからクライアントにソフトウェアコンポーネントをダウンロードするプロトコルを提供する。 特に、ＤＳＭ−ＣＣシステムは、ビデオ・オン・デマンド（ＶＯＤ）、ニア・ビデオ・オン・デマンド（ＮＶＯＤ）、ホームショッピング、ニュース・オン・デマンド及び電子番組ガイド（ＥＰＧ）のようなインタラクティブ・マルチメディア・フィーチャを提供するＤＶＢ（デジタルビデオ放送）システムに適用可能である。

これらのフィーチャを実施するのに必要とされるデータをダウンロードする２つの原理が識別されることができる。 １つ目、双方向ダウンロードは、クライアントがサーバと共にダウンロード制御パラメータをセットアップし、次いでダウンロードされるべきソフトウェアモジュールを要求する場合に生じる。 この場合、実際のデータは、一連のメッセージとして前記サーバから前記クライアントに搬送される。 この原理は、前記クライアントが特定のソフトウェアモジュールを要求することができるように２方向通信を必要とする。 第２の原理、単方向ダウンロードは、１方向通信のみが利用可能である（例えばデジタルビデオ放送）システムに対して使用可能である。 このような放送の場合、前記クライアントが前記サーバにメッセージを送信する機構は必ずしも存在しない。 しかしながら、ダウンロード制御メッセージ、続いて放送チャネル上のダウンロードデータメッセージを繰り返し送信することにより前記サーバからクライアントにデータをダウンロードすることは依然として可能である。 これらの制御及びデータメッセージは、時間に対して周期的に送信され、前記クライアントは、これらを無視するか又は受信し、処理するかを選択することができる。 前記クライアントは、いつ様々なメッセージが送信されるかを制御することができない。 様々なモジュールを周期的に繰り返す放送のこのシステムは、データカルーセルシステムと称される。

このデータカルーセルは、サーバが、カルーセルのコンテンツを１回以上周期的に繰り返すことにより前記クライアントにおけるデコーダに相異なるデータモジュールのセットを提示することを可能にするトランスポート機構として説明されることができる。 データカルーセル概念の周知例は、テレテキストシステムであり、テレテキストページの完全なセットは、アクティブな画像の一部ではないアナログビデオ信号の幾つかのラインにおいて周期的に放送される。 ユーザがページを要求する場合、前記ユーザは、通常は、前記ページが放送される次の回を待たなくてはならない。

データカルーセル内で、データは複数のモジュールに構造化され、前記モジュールはファイルのコンテンツを含むことができる。 第１のモジュールが“file1”に関する場合、第２のモジュールは“file2”に関し、第３のモジュールは“file3”に関する。 各モジュールは、それぞれＤＳＭ−ＣＣのダウンロードデータブロック（DownloadDataBlock）シンタックスを使用して規定される１つ又は複数のダウンロードデータメッセージのペイロードを形成するように分割される。 このようなダウンロードデータメッセージの数は、前記モジュールのサイズ及び各ダウンロードデータメッセージの最大ペイロードに依存する。 論理グループ分け及び各モジュールを説明する情報は、適切にＤＳＭ−ＣＣのダウンロードサーバイニシエイト（DownloadServerInitiate）シンタックス又はダウンロードインフォインディケーション（DownloadInfoIndication）シンタックスのいずれかを使用して規定されるダウンロード制御メッセージにより提供される。

一般に、どれだけ頻繁に特定のメッセージが前記カルーセルに挿入されるか、並びに前記メッセージの順序及び相対的位置に制限は存在しない。 これは、前記データカルーセルが、特定の使用に最良に適するような様式で作成されることを可能にする。

オブジェクトカルーセルとして既知の前記データカルーセル（xletレベル）の上の追加のプロトコルは、前記クライアントにおいて仮想ファイルシステムを提供するのに使用されることができる。 オブジェクトカルーセルが使用される場合、（ファイル及びディレクトリのような）実際のＤＳＭ−ＣＣオブジェクトは、前記データカルーセルが前記ダウンロードデータメッセージから抽出するモジュール内部のクライアントに搬送されることができる。 前記オブジェクトカルーセルの使用は、制限されたローカル記憶部（例えばセットトップボックス）を持つ又は持たないクライアントに、ＤＳＭ−ＣＣオブジェクトがローカルであるかのようにアクセスすることができる仮想ファイルシステムを提供することを可能にする。

ＤＳＭ−ＣＣオブジェクトカルーセルは、ディレクトリオブジェクト、ファイルオブジェクト及びストリームオブジェクトを使用して放送サーバから放送受信器（クライアント）にオブジェクトの構造化されたグループの送信を容易化する。 実際のディレクトリ及びコンテンツ（オブジェクトインプリメンテーション）は、前記サーバに位置する。 前記サーバは、前記オブジェクトカルーセルプロトコルを使用してＤＶＢ準拠ＭＰＥＧ−２トランスポートストリームに上述のオブジェクトを繰り返し挿入する。

送信されたストリームオブジェクトが前記放送における他のストリームに対するリファレンスであると同時に、前記ディレクトリ及びファイルオブジェクトは、前記サーバにおいて前記ディレクトリ及びファイルを再構築するのに必要とされるデータを含む。 前記ストリームオブジェクトは、特定のストリーム内で放送されるＤＳＭ−ＣＣイベントに関する情報をも含むことができる。 ＤＳＭ−ＣＣイベントは、正規のストリームデータを用いて放送されることができ、ＤＳＭ−ＣＣフィーチャを始動するために使用されることができる。

クライアントは、繰り返し送信されたカルーセルデータを読み取り、したがってローカルオブジェクトインプリメンテーションにおいて前記サーバのオブジェクトを模倣することにより前記オブジェクトインプリメンテーションをリカバすることができる。 前記オブジェクトカルーセルは、たとえ前記サーバとのインタラクティブな接続が存在しなくても、クライアントがフィーチャ及びこれらのフィーチャにより使用されるコンテンツにアクセスする方法を提供することがわかる。

ＤＳＭ−ＣＣデータカルーセル規格によると、各モジュールは、ダウンロードデータブロックメッセージにおいて運ばれる１つ又は複数のブロックに分割される。 各ダウンロードデータブロックメッセージは、（より小さいサイズであり得る前記モジュールの最後のブロックを除き）同じサイズであり、ＭＰＥＧ−２プライベートセクションにおいて送信される。 ダウンロードデータブロックメッセージ及びＭＰＥＧ−２プライベートセクションのカプセル化規則は、ブロックが、一般にデマルチプレクサにおいて見つけられるハードウェアフィルタを使用して前記トランスポートストリームから直接的に取得されることができるようになっている。

ブロードキャスタが複数のフィーチャを放送することを望む場合、それぞれの独立したフィーチャを単一のxletに入れることを決定することができる。 しかしながら、前記ブロードキャスタは複数のフィーチャが同時にアクティブになることを望む場合、ＭＨＰミドルウェアフィーチャは、複数のフィーチャの同時アクティブ化をサポートしなければならない。

本発明の目的は、上述の問題を解決し、特に複数のフィーチャのアクティブ化をサポートしていない標準的なＭＨＰミドルウェア上で複数のフィーチャをアクティブ化することを可能にする方法を提供することである。

これは、ブロードキャスタから放送された信号を受信するように適合された受信器が、第１の独立したフィーチャの実行を処理する方法であって、前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータの少なくとも一部が、少なくとも第２の独立したフィーチャを実行するのに必要とされるフィーチャデータと一緒に前記放送信号に含まれ、前記フィーチャデータがデータカルーセルとして放送され、前記方法が、
前記第１のフィーチャを識別する命令であって、更に前記識別された第１のフィーチャが実行されることになる識別を含む当該命令を受信するステップと、
前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードするステップと、
前記識別されたフィーチャを実行するステップと、
を有する当該方法により得られる。

特定のフィーチャが実行されるべき場合に、前記フィーチャをアクティブ化し、フィーチャデータをロードすることのみによって、前記ブロードキャスタは、使用されていないカルーセルを除去し、新しいカルーセルを持ち込むことにより、放送中にアプリケーションを追加／除去／交換することができる。 全てのアプリケーションを１つのxletに配置することにより、前記xletにより提供される全ての機能がアクティブになる。 したがって、例えばネットワークポータルは、常に１つのキー（key）だけ離れている。

特定の実施例において、前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードするステップは、
前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータを有するデータカルーセルをマウントするステップと、
前記第１のフィーチャ専用のクラスローダを作成するステップと、
を有する。

ＪＡＶＡ（登録商標）クラスファイルの場合、フィーチャ特有クラスローダは、前記フィーチャが、他のフィーチャに影響を与えずに全てのフィーチャ特有データと一緒に除去されることができる。 これは、フィーチャが停止された場合に、フィーチャ特有クラスローダに対する全てのリファレンスを除去することのみにより、最適な量のメモリリソースが解放されることができる。

特定の実施例において、前記方法は更に、
フィーチャを識別する命令であって、更に前記識別されたフィーチャが終了されることになる識別を含む当該命令を受信するステップと、
前記フィーチャを終了するステップと、
前記識別されたフィーチャに関するフィーチャデータを前記受信器のメモリから除去するステップと、
を有する。

使用後にメモリからフィーチャを除去することにより、前記受信器がメモリを使い果たさないことが保証される。 終了されたフィーチャにより使用されたメモリリソースを解放するだけでなく、チューナモデム又はグラフィックス装置のような他のリソースも解放されることができる。

一実施例において、前記識別されたフィーチャに関するフィーチャデータを前記受信器のメモリから除去するステップは、
前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータを有する前記データカルーセルをアンマウントし、前記データカルーセルを前記メモリから除去するステップと、
前記第１のフィーチャ専用の前記クラスローダに対する全てのリファレンスを除去し、前記全てのリファレンスを前記メモリから除去するステップと、
を有する。

フィーチャ特有クラスローダを使用するＪＡＶＡ（登録商標）クラスファイルの場合、前記フィーチャは、前記受信器メモリからこれらのクラスローダを除去することにより更に整理されることができる。

他の実施例において、前記第１の独立したフィーチャを識別する前記命令は、前記ブロードキャスタから受信される。 これにより前記ブロードキャスタは前記フィーチャを制御し、例えば前記受信器上でフィーチャをアクティブ化又は終了することにより前記受信器上で実行されるフィーチャのライフサイクルを制御する。

他の実施例において、前記第１の独立したフィーチャを識別する前記命令は、前記受信器と通信するユーザから受信される。 これにより前記ユーザは、前記受信器上の前記フィーチャを制御することができ、例えば前記受信器上でフィーチャをアクティブ化又は終了する。

一実施例において、前記受信器は、前記放送された独立フィーチャの少なくとも一部の識別を前記ユーザに提示し、前記第１の独立したフィーチャを識別する前記命令は、前記提示に基づく。

放送フィーチャの識別は、放送フィーチャテーブル内に存在し、前記フィーチャテーブル内の情報を使用することにより、前記受信器は、利用可能なフィーチャをユーザインターフェース上に容易に提示することができる。 前記ユーザは、したがって、フィーチャを選択するのにこの提示を使用することができ、前記ユーザが利用可能なフィーチャの間で選択することのみができることを保証する。 更に、ユーザ命令は、開始／アクティブ化、停止／終了／非アクティブ化、隠蔽／アイコン化／最小化、又は表示／非アイコン化／最大化であることができる。

本発明は更に、放送信号を送信するブロードキャスタが、受信器により実行されるべき第１の独立したフィーチャを放送する方法に関し、ここで前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータの少なくとも一部は、少なくとも第２の独立したフィーチャを実行するのに必要とされるフィーチャデータと一緒に前記放送信号に含まれ、前記フィーチャデータは、データカルーセルとして放送され、前記方法は、第３の独立したフィーチャを実行するのに必要とされるフィーチャデータを放送するステップを有し、前記第３の独立したフィーチャは、前記受信器が、
前記第１のフィーチャを識別する命令であって、更に前記識別された第１のフィーチャが実行されることになる識別を含む当該命令を受信し、
前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードし、
前記識別されたフィーチャを実行することにより、
前記第１の独立したフィーチャの実行を処理することを可能にする。

本発明は、ブロードキャスタから放送信号を受信するように適合された受信器にも関し、前記受信器は、第１の独立したフィーチャの実行を処理するように適合され、前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータの少なくとも一部は、少なくとも第２の独立したフィーチャを実行するのに必要とされるフィーチャデータと一緒に前記放送信号に含まれ、前記フィーチャデータはデータカルーセルとして放送され、前記受信器は、
前記第１のフィーチャを識別する命令であって、更に前記識別された第１のフィーチャが実行されることになる識別を含む当該命令を受信する手段と、
前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードする手段と、
前記識別されたフィーチャを実行する手段と、
を有する。

本発明は、放送信号を送信するように適合され、受信器により実行されるべき第１の独立したフィーチャを放送するように適合されたブロードキャスタにも関し、前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータの少なくとも一部が、少なくとも第２の独立したフィーチャを実行するのに必要とされるフィーチャデータと一緒に前記放送信号に含まれ、前記フィーチャデータがデータカルーセルとして放送され、前記ブロードキャスタが、第３の独立したフィーチャを実行するのに必要とされるフィーチャデータを放送する手段を有し、前記第３の独立したフィーチャは、前記受信器が、
前記第１のフィーチャを識別する命令であって、更に前記識別された第１のフィーチャが実行されることになる識別を含む当該命令を受信し、
前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードし、
前記識別されたフィーチャを実行することにより、
前記第１の独立したフィーチャの実行を処理することを可能にする。

更に、本発明は、受信器により実行されるべき第１の独立したフィーチャを放送する放送信号にも関し、前記第１の独立したフィーチャを実行するのに必要とされるフィーチャデータの少なくとも一部が、少なくとも第２の独立したフィーチャを実行するのに必要とされるフィーチャデータと一緒に前記放送信号に含まれ、前記フィーチャデータがデータカルーセルとして放送され、前記放送信号が、更に、第３の独立したフィーチャを実行するのに必要とされるフィーチャデータを有し、前記第３の独立したフィーチャは、前記受信器が、
前記第１のフィーチャを識別する命令であって、更に前記識別された第１のフィーチャが実行されることになる識別を含む当該命令を受信し、
前記データカルーセルから前記受信器のメモリに前記第１のフィーチャに関するフィーチャデータをロードし、
前記識別されたフィーチャを実行することにより、
前記第１の独立したフィーチャの実行を処理することを可能にする。

以下に本発明の好適実施例は、図面を参照して説明される。

図１において、放送信号１０３を放送するブロードキャスタ１０１、並びに放送信号１０３を受信するように適合された複数の受信器１０５，１０７，１０９及び１１１を有する放送システムが図示される。 放送信号１０３は、複数の独立したフィーチャＡ、Ｂ、Ｃ、Ｄ及びＦＷを組み合わせるアプリケーションを有し、これらのフィーチャは単一のxletとして送信され、ここでフレームワークフィーチャ（ＦＷ）は、この場合、異なるフィーチャ間のナビゲーションを管理し、他のフィーチャＡ、Ｂ、Ｃ及びＤは、テレビガイド、番組通知、クイズ及びクロックのようなフィーチャであることができる。 特定の実施例において、フレームワーク機能は、フィーチャＡ、Ｂ、Ｃ及びＤ上に広げられることができる。

ブロードキャスタ１０１は、現在放送され且つ現在のステータスであるフィーチャに関してフレームワークフィーチャに情報を提供しなくてはならない。 この情報は、フィーチャテーブル１０４に備えられてもよい。 このようなテーブルは、少なくとも以下のフィールドを含むべきである。
フィーチャ名−受信器１０５のユーザに示されるべきである。
カルーセル識別−ＭＨＰ規格で指定されるように前記xletを含むカルーセルのアドレスである。
開始クラス名−このフィーチャの実行を開始する最初のクラスである。
フィーチャステータス−前記フィーチャのライフサイクルを制御するためにブロードキャスタ１０１により使用されるべきであり、ブロードキャスタ制御が必要とされない場合にはこのフィールドは必要ではない。

この情報は、フレームワークが、前記受信器のユーザにフィーチャを提示し、前記ユーザのコマンドでフィーチャを開始／停止し、前記ブロードキャスタのコマンドでフィーチャを開始／停止／追加／除去することを可能にする。

前記フレームワークフィーチャにより管理される別個のフィーチャとして送信される場合、各フィーチャは独自のファイル構造を持つ。 例えば、上述のクロックフィーチャは、以下のファイル、即ち、
com\philips\xlets\clock\ClockXlet.class
com\philips\xlets\clock\ClockHand.class
com\philips\xlets\clock\bankground.gif
からなることができる。

前記クロックフィーチャがxletとして放送される場合、ＤＳＭＣＣカルーセルは、以下の構造、即ち、
\com\philip\xlets\clock\ClockXlet.class
\com\philip\xlets\clock\ClockHand.class
\com\philip\xlets\clock\background.gif
を持つ。

テレビガイド、番組通知、クイズ及びクロックのようなフィーチャが１つの単一のxletに組み合わされる場合、前記xletは複数のカルーセルからなる。 各フィーチャに対して１つのカルーセルがあり、前記フレームワークに対して１つの追加のカルーセルがある。
フレームワークフィーチャ
\com\philip\xlets\framework\FrameworkXlet.class
\com\philip\xlets\framework\AppsAdministration.dat
\com\philip\xlets\framework\<other framework classes and files>
クロックフィーチャ
\com\philip\xlets\clock\ClockXlet.class
\com\philip\xlets\clock\ClockHand.class
\com\philip\xlets\clock\background.gif
クイズフィーチャ
\com\philip\xlets\quizl\QuizlAppl.class
\com\philip\xlets\quizl\<other EPG classes and files>
番組ガイドフィーチャ
\com\philip\xlets\epg\EpgAppl.class
\com\philip\xlets\epg\<other EPG classes and files>
通知フィーチャ
\com\philip\xlets\notifier\NotifierAppl.class
\com\philip\xlets\notifier\<other Notifier classes and files>

前記ブロードキャスタは、複数のデータカルーセルを有する１つのオブジェクトカルーセルを使用することができるか、又は複数のオブジェクトカルーセルを使用することができる。

受信器１０５のユーザが前記フィーチャの１つを使用することを望む場合、前記フレームワークは、このフィーチャに対する専用のクラスローダを作成する。 第二に、これは、前記カルーセルにアクセスし、前記フィーチャをアクティブ化する。 前記フレームワークは、画面及びキー管理に関与するが、前記アクティブなフィーチャも画面及びキーにアクセスすることができる。

同じフィーチャがもはや必要とされない場合、前記フレームワークは、前記フィーチャを非アクティブ化し、除去する。 前記専用フィーチャクラスローダが除去される場合、全ての（フィーチャに関する）クラスがメモリから除去され、前記メモリは他の目的に再使用されることができる。 関連したＤＳＭＣＣカルーセルがアンマウントされる場合、前記関連したカルーセルのＤＳＭＣＣキャッシュも消去されることができる。

例えばQuiz1フィーチャがQuiz2により交換されなければならない場合、オペレータは、コンテンツQuiz1を有するカルーセルを除去することができる。 前記フレームワークは、Quiz1のインスタンスを停止し、メモリから関連したデータを除去することができる。 Quiz2が新しいカルーセル内に配置される。 ＤＳＭＣＣカルーセル生成器は、Quiz2カルーセルの注入を開始する。 これによりQuiz1の帯域幅及び受信器リソースは、Quiz2により再使用される。

図２において、ブロードキャスタ２００が追加のフィーチャＥを放送し始める場合に、どのように新しいフィーチャＥが受信器２０６のユーザに利用可能にされるかが図示される。 初めに２０１において、前記ブロードキャスタは、放送される信号２０４にＥフィーチャが追加される（add E）べきであるという情報を与え、前記Ｅフィーチャは、前記放送される信号内のフィーチャテーブルに追加される（U_F）。 次いで２０３において、ＤＳＭＣＣ生成器は、更新されたテーブルを有する放送信号２０４を放送し始める。 ２０５において、新しいＤＳＭＣＣカルーセルが放送され、２０７において、前記フレームワークが、更新（U_F）を検出し、これに対応してローカルに記憶されたフィーチャテーブルを更新し（U_FT）、受信器２０６により前記ユーザに提示されるユーザインターフェースに前記フィーチャを追加する（add E_UI）ことにより前記ユーザに新しいフィーチャを提示する。

図３において、ブロードキャスタ３００がフィーチャの放送を停止する場合に、どのようにしてフィーチャＥの利用可能性が受信器３０６のユーザから除去されるかが図示される。 初めに３０１において、前記ブロードキャスタは、放送される信号３０４からＥフィーチャが除去される（rem E）べきであるという情報を与え、前記Ｅフィーチャは、放送される信号３０４内の前記フィーチャテーブルから除去される（U_F）。 次いで３０３において、前記ＤＳＭＣＣ生成器は、更新されたテーブル（U_F）を有する放送信号３０４を放送し始める。 ３０５において、新しいＤＳＭＣＣカルーセルが放送され、３０７において、前記フレームワークが、更新（U_F）を検出し、これに対応してローカルに記憶されたフィーチャテーブルを更新し（U_FT）、フィーチャの更新された選択を表示し、ここで前記Ｅフィーチャは、受信器３０６により前記ユーザに提示されるユーザインターフェースからフィーチャＥを除去する（rem E_UI）ことにより除去されている。

図４において、他のフィーチャと一緒の前記フレームワークフィーチャの構造が図示される。 前記フレームワークを有する単一のxletが前記受信器により受信される場合、前記フレームワークが実行され、フレームワーク４０１は、この場合、他のフィーチャＡ、Ｂ、Ｃ及びＤの実行及び終了を管理する。 フィーチャの実行及び終了は、受信器４０５のユーザから受信されるコマンドに基づくか、又はブロードキャスタ４０３から受信されるコマンドに基づくかのいずれかであることができる。

以下に、それぞれ前記ブロードキャスタ及び前記受信器のユーザがフィーチャを実行及び終了するシナリオが記載される。

図５において、受信器のユーザがフィーチャを開始する場合に受信器上でフィーチャを実行するステップが図示される。 最初に、前記フレームワークは、前記受信器上のユーザインターフェースを介して利用可能なフィーチャを前記ユーザに提示している。 ５０１において、前記フィーチャテーブルにより利用可能なフィーチャを提示する前記ユーザインターフェースに基づいて、前記ユーザは、例えば、キーボード又はリモートコントローラのような前記受信器に接続された入力装置を使用することにより、フィーチャＡをアクティブ化する。 次に、フィーチャＡを開始する（ST_A）ように指示するコマンドが前記フレームワークに送信される。 ５０３において、前記フレームワークフィーチャは、前記コマンドを受信し、前記フレームワークフィーチャは、フィーチャＡに関連するフィーチャデータが、前記カルーセルから前記受信器のメモリにロードされることを確認する。 前記フレームワークフィーチャは、初めに５０５においてアプリケーションＡを含むカルーセル（DSMCC C_A）をマウントする（m）ことによりこのロードを開始し、５０７において前記フレームワークフィーチャは、Ａに関連したクラスローダを例示する（instantiating）ことにより専用クラスローダの作成をアクティブ化する。 最後に、５０９において前記フレームワークフィーチャがアプリケーションＡを開始する（ST_A）。

図６において、受信器のユーザがフィーチャを停止する場合に受信器上でフィーチャを終了するステップが図示される。 ６０１において、前記フィーチャテーブルにより利用可能なフィーチャを提示するユーザインターフェースに基づいて、前記ユーザは、例えば、マウス又はリモートコントローラのような前記受信器に接続された入力装置を使用することによりフィーチャＡを終了する。 次に、フィーチャＡを停止する（STP_A）ことを指示するコマンドが前記フレームワークに送信される。 ６０３において、前記フレームワークフィーチャは前記コマンドを受信し、６０９において前記フレームワークフィーチャはフィーチャＡを停止する（STP_A）。 ６０７において、前記フレームワークフィーチャは、Ａに関連する前記クラスローダに対する全てのリファレンスを除去することにより前記専用クラスローダを非アクティブ化する。 次に、６０５において、アプリケーションＡを含むカルーセル（DSMCC C_A）がアンマウントされる（u_m）。 最後に、ガーベジコレクタ６１１は、前記受信器のメモリから前記カルーセル、前記クラスローダ及び前記フィーチャに対してそれぞれ使用されたデータを除去する（G_C）。

図７において、ブロードキャスタ７００が受信器７０６上でフィーチャを開始する場合に受信器７０６上で放送されるフィーチャを実行するステップが図示される。 初めに７０１において、ブロードキャスタ７００は、前記放送される信号において放送されるべきフィーチャテーブルにおいてＡのステータスを開始にセットする（SA_ST）ことにより、Ａフィーチャが開始されるべきであるという情報を与える。 次いで７０３において、ＤＳＭＣＣ生成器（G_DSMCC）は、更新されたテーブル（U_F）を有する放送信号７０４を放送し始める。 ７０５において、新しいＤＳＭＣＣカルーセルが放送され、７０７において、前記フレームワークは、更新（U_F）を検出し、これに対応してローカルに記憶されたフィーチャテーブルを更新する（U_AT）。 前記フレームワークフィーチャは、フィーチャＡに関連したフィーチャデータが、前記カルーセルから前記受信器７０６のメモリにロードされることを確認する。 前記フレームワークフィーチャは、初めに７０９においてアプリケーションＡを含むカルーセル（DSMCC C_A）をマウントする（m）ことによりこのロードを開始し、７１１において、前記フレームワークフィーチャは、Ａに関連したクラスローダを例示することにより専用クラスローダの作成をアクティブ化する。 最後に、７１３において前記フレームワークフィーチャがアプリケーションＡを開始する（ST_A）。

図８において、ブロードキャスタ８００がフィーチャを停止又は終了する場合に受信器上でフィーチャを終了するステップが図示される。 初めに８０１において、ブロードキャスタ８００は、放送される信号８０４において放送されるべきフィーチャテーブルにおいてＡのステータスを停止にセットする（SA_STP）ことによりＡフィーチャが停止されるべきであるという情報を与える。 次いで８０３においてＤＳＭＣＣ生成器（G_DSMCC）は、更新されたテーブル（U_F）を有する放送信号８０４を放送し始める。 ８０５において、更新されたＤＳＭＣＣカルーセルが放送され、８０７において、前記フレームワークが、更新（U_F）を検出し、これに対応してローカルに記憶されたフィーチャテーブルを更新する（U_AT）。 ８１３において、前記フレームワークフィーチャはフィーチャＡを停止する（STP_A）。 ８１１において、前記フレームワークフィーチャは、Ａに関連したクラスローダに対する全てのリファレンスを除去することにより前記専用クラスローダを非アクティブ化する。 次に８０９において、アプリケーションＡを含むカルーセル（DSMCC C_A）はアンマウントされる（u_m）。 最後に、ガーベジコレクタ８１５は、それぞれ前記カルーセル、前記クラスローダ及び前記フィーチャに対するデータにより占められていた受信器８０６のメモリを解放する（G_C）。

上述の実施例が、本発明を制限するのではなく説明し、当業者が、添付の請求項の範囲から外れることなく多くの代替実施例を設計することができることに注意すべきである。 請求項において、括弧の間に配置された参照符号は、請求項を制限するように解釈されるべきでない。 単語'有する'は、請求項にリストされた要素又はステップ以外の要素又はステップの存在を除外しない。 本発明は、幾つかの異なる要素を有するハードウェアを用いて、及び適切にプログラムされたコンピュータを用いて実施されることができる。 幾つかの手段を列挙する装置請求項において、これらの手段の幾つかはハードウェアの同一アイテムにより実施されることができる。 特定の方策が相互に異なる従属請求項に記載されるという単なる事実は、これらの方策の組み合わせが有利に使用されることができないことを示さない。

放送信号を放送するブロードキャスタと、前記放送信号を受信するように適合された複数の受信器とを有する放送システムを示す。

ブロードキャスタが追加のフィーチャの放送を開始する場合に、新しいフィーチャを受信器のユーザに利用可能にするステップを示す。

ブロードキャスタがフィーチャの放送を停止する場合に受信器のユーザに対するフィーチャの利用可能性を除去するステップを示す。

フレームワークフィーチャ及び他のフィーチャの構造を図示する。

受信器のユーザがフィーチャを開始する場合に受信器上でフィーチャを実行するステップを示す。

受信器のユーザがフィーチャを停止する場合に受信器上でフィーチャを終了するステップを示す。

ブロードキャスタがフィーチャを開始する場合に受信器上で放送されたフィーチャを実行するステップを示す。

ブロードキャスタがフィーチャを停止する場合に受信器上でフィーチャを終了するステップを示す。