JP2008512012A - デジタルテレビで双方向サービスを提供する方法及びシステム - Google Patents

Abstract

本発明はスクリーンに接続されたデジタル受信装置（例えば、セットトップボックス）上に双方向サービスを提供するための方法及びシステムに関するものであり、前記双方向サービスはスクリーン上に表示できるメディアコンテンツを含む。双方向サービスはサービスアプリケーションにより提供され、該サービスアプリケーションは、動的サービスロジックを含んだデジタル受信装置内で実行され、動的サービスロジックは、スクリーン上に視覚化される新しいメディアコンテンツを生成できる。動的サービスロジックは、サービスアプリケーション自体の中に記憶されるか又はサーバからダウンロードされるデータを用いることにより、動的情報をオンザフライで生成する能力を与えるアプリケーションロジックである。これらのデータは、スクリプト視覚表現を生成するよう作用する「生」の情報コンテンツを含む。動的サービスロジックは１以上のビジネスロジックを備え、このビジネスロジックは、例えばユーザーの要求を受けてランタイム時にコンテキスト依存コンテンツをクライアント側で生成することを担当する。セットトップボックス内で実行されるアプリケーションが、双方向性を与える動的シーンをローカルにて生成できる動的サービスロジックを含むので、双方向サービスをリターンチャンネルの無いセットトップボックスにおいても提供できる。

Description

本発明はセットトップボックスなどのデジタル受信装置に対して双方向テレビコンテンツを有効にし処理するためのシステム及び方法に関する。

デジタル伝送技術の最近の出現により、今では放送会社は従来のアナログ放送の映像よりも十分に多くのものを提供することができる。デジタル伝送ではアナログ伝送よりもかなり広い帯域幅を必要とするが、デジタル信号は圧縮することができる。ＭＰＥＧ（モーション・ピクチャー・エキスパート・グループの頭字語）規格などのコンピュータ技術を用いて、１つの画像とその次に続くものとの間で生じる変化を抜き出してそれだけを伝送する。デジタルテレビによりデータの放送が可能となり、デジタルテレビ環境において双方向サービスを導入することができる。

デジタル信号の伝送は様々な方法で行なうことができる。デジタル地上波テレビ（ＤＴＴ）網においては、放送信号を「無線」でアンテナまで伝送する。地上波、ケーブル及び衛星に加えて、ＩＰシステムはテレビを家庭に持ち込んで映像、音声及びデータコンテンツを受信する手段をユーザーに提供する実行可能な手段である。

現在、たいていのテレビ視聴者はセットトップボックス（ＳＴＢ）を介してデジタルテレビを見るが、このセットトップボックス（ＳＴＢ）が、デジタル信号を復号化してテレビモニター（又はデュアル・スクリーン・システムの場合にはＰＣモニター）上に表示する。先進のＳＴＢは単なる復号器以上のことができ、例えば、モデムと通信網（例えばＰＳＴＮ）を使用するサービス提供者によって遠隔コントロールを行なってユーザーと相互作用できるアプリケーションを実行するようにプログラミングできる。実際、ＳＴＢは一般にソフトウェアを実行するコンピュータを備え、信号を復号化し、音声又は映像ストリームと共に伝送されるソフトウェアを実行する。一方向システム用のＳＴＢは情報にアクセスしてそれをＴＶスクリーン上に重ねることができる。二方向システムはリターンチャンネルを介して放送会社（又はサービス提供者）に情報を返送する。一方向システムでは、双方向性はローカルで利用可能な情報に限定され（例えばユーザーはＳＴＢ上で利用可能なページを進むことができる）、一方、二方向システムでは、ユーザーは（例えばサービスを要求したり、情報を送信するために）遠隔のサーバと相互作用できる。

リターンチャンネルは、クライアントがサーバと相互作用すべくＳＴＢにより使用される物理経路である。例えば、双方向ＴＶのユーザーはリターンチャンネルを介して情報（例えば投票、アンケート、サービスの要求）をサービスセンターに返信できる。この物理経路は、電話やＡＤＳＬモデム回線などの有線接続、又は無線、例えばＧＰＲＳやＵＭＴＳとし得る。

デジタルテレビの場合、一般に双方向性とは、テレビ視聴者が番組やサービスと相互作用できるようにすることを意味している。しばしば、双方向性は２つの種類、すなわち高機能テレビと双方向サービスとに分けられる。一般に、高機能テレビとは、テレビ視聴者がテレビ番組を受動的に見る以上のことができることを意味する。このシステムにより、テレビ視聴者は高機能テレビ番組を見ながら、同時に番組に関連する追加の情報をダウンロードすることができる。高機能テレビでは、双方向性は「低レベル」であり、例えばアナログテレビの文字多重放送のアプリケーションで行われるようにページをブラウジングすることに非常に類似している。

一般に、双方向サービスでは、例えばユーザーがメニューの選択肢を押すとかコンテンツが更新されるとかの外部イベントに応じて情報が配信されることを仮定する。この情報は文脈依存的であり、オンザフライに生成できる。その場合、双方向サービスは、現在及び次回の番組についての告知、又は電子番組ガイド（ＥＰＧ）に関連した情報などの変化のない情報に関して、トランスポート・ストリームを探索可能にする機能を越えることができる。双方向サービスの一例として、電子小売業者により提供される取引サービスや、特定の空港からの定期便についての情報のオンデマンド配信が挙げられる。双方向サービスでは、コンテンツに関連する情報、すなわち放送されるＴＶコンテンツに依存した情報か、又は番組の流れから独立した情報にアクセスすることを伴う。しばしば、コンテンツに関連したサービスと流れに独立なサービスとの違いは、サービスを生成又は配信するためにサービス提供者が誰と契約しているか、すなわち、ＴＶチャンネル提供者（放送会社）かＭＶＰＤ（多チャンネル映像番組配信者）かに存する。この後者は、プラットフォームオペレータとして機能する。例として、実際、金融情報や株価のオンデマンド配信は、ビジネスチャンネルの番組に関連付けることもできるし、特定の番組の流れとは無関係に行なうこともできる。

以下、双方向サービスとは、双方向性に関与する番組の向上と、番組の流れとは独立した専用の双方向サービスとの両方を含むものとする。

双方向サービスは、ＴＶコンテンツを提供しているのと同じ放送チャンネルか、又は別の伝送回線、すなわちネットワーク接続を介して与えられる。一般に、双方向サービスにアクセスする方法は、赤外線信号を復号器に送るリモート制御機器又はリモートキーボードを用いる。

これらのサービスの多くがウエブを介して利用可能になってきている。ウエブサービスの形式で追加チャンネルを受信できる先進のセットトップボックスが市販されだしている。インターネットへの接続性は、組み込みモデムによるか、又は広帯域ホームネットワークへのＷｉＦｉ若しくはイーサネット接続により得ることができる。

このＳＴＢは一般に映像、音声及びデータの構成要素からなるデジタル放送信号を受信する。このデータ構成要素は、反復「カルーセル」方式で提供され、必要とされる際に受信者によりモジュールをダウンロードする。一般に、このモジュールは、Ｊａｖａ（登録商標）プログラミング言語で書かれた双方向アプリケーションを含む。このＳＴＢはＪａｖａ仮想マシン（ＪＶＭ）を備え、それがリンクするＪａｖａクラスファイルを受信し、双方向アプリケーションを実行する。

一般に、このＳＴＢはアプリケーションを開始するためにミドルウェアを必要とする。ミドルウェアはＳＴＢ内に常駐のソフトウェア及びハードウェアであり、アプリケーションが機能するのを共に助ける。ミドルウェア提供者は、ユーザーが番組や製品を選択し、インターネットに接続し、安全な取引をすることができるようにソフトウェアとインターフェースとを開発する。ミドルウェアの例としては、Ｌｉｂｅｒａｔｅ、Ｏｐｅｎ ＴＶ、Ｍｉｃｒｏｓｏｆｔ ＴＶ及びＪａｖａ ＴＶが挙げられる。

Ｊａｖａはプラットフォームに独立なオブジェクト指向プログラミング言語である。Ｊａｖａは、一般にアプレットと称される小さなプログラムを作成するために特に設計されている。このアプレットは、ネットワーク上の中央サーバに存在し、必要なときにのみクライアントマシンに配信される。Ｊａｖａプログラムは一回だけ書き込まれ、ＪＶＭを含む任意の種類のプラットフォーム上で実行できる。オブジェクト指向言語であるがゆえ、Ｊａｖａで書かれたソフトウェアはオブジェクト指向プログラミングの利点を利用できる。Ｊａｖａ言語では、プログラムデータは、プログラマーが生成したクラスであろうと、ＪａｖａプラットフォームＡＰＩ（アプリケーション・プログラミング・インターフェース）ライブラリから用いたクラスであろうと、クラス内に包まれる。クラスはデータと該データに作用するよう実行可能なコード（メソッドともいう）との両方を含む。Ｊａｖａでは、オブジェクトはクラスのランタイム・インスタンスであり、その挙動はメソッドに定義される。Ｊａｖａで書かれたプログラムは、まずＪａｖａコンパイラを用いてバイトコードにコンパイルされる。バイトコードは、ＪＶＭにより翻訳し実行できるプラットフォーム独立なコマンドである。このＪＶＭは、Ｊａｖａプログラムを実行しなければならない各プラットフォームに対してインプリメントしなければならない仮想コンピュータである。このＪＶＭは、コンパイルしたバイトコードと基礎のハードウェアプラットフォーム及びオペレーティングシステムとの間のアブストラクション・レイヤを与える。このＪＶＭがプログラムを実行する場合、Ｊａｖａバイトコードを取り込んで基礎のハードウェア用のマシンコード命令に翻訳又は変換し、このマシンコード命令を実行用のＣＰＵに送る。このようにして機能することにより、Ｊａｖａプログラムは一回だけ書き込まれて、ＪＶＭが利用可能などんなプラットフォーム上でも実行することができる。

新たに現れた標準的な双方向テレビ（ｉＴＶ）用のプラットフォームは、マルチメディア・ホーム・プラットフォーム（ＭＨＰ）であり、これはデジタル・ビデオ・ブロードキャスティング（ＤＶＢ）（デジタルＴＶ放送の種々の面を標準化する産業主導型のコンソーシアム）により設計されたオープン・ミドルウェア・システムである。ＭＨＰは、すべての第三者が彼ら自身のｉＴＶアプリケーションを開発し操作することを可能にするＡＰＩセットである。一般に、ＭＨＰは例えばＳｕｎのＪａｖａＴＶネットワークに基づいてＪａｖａランタイム環境において定義される。

ＤＶＢ-ＭＨＰアプリケーションはＤＶＢ-Ｊａｖａ又はＤＶＢ-ＨＴＭＬアプリケーションとして分類できる。一般に、ＤＶＢ-Ｊａｖａ（又はＤＢＶ-Ｊ）アプリケーションはＸｌｅｔアプリケーションという。これらはすべてＳＴＢ内で実行され、ＳＴＢ内に常駐するか、又はオブジェクト及びデータカルーセル又はネットワークからダウンロードされ得る。Ｘｌｅｔアプリケーションはアプリケーションマネージャーにより制御され、このアプリケーションマネージャーは、システムソフトウェアの一部であり、ＳＴＢ内に常駐している。このアプリケーションマネージャーは、アプリケーションのライフサイクルを管理することを担当する。

Ｃ．ＰｅｎｇとＰ．Ｖｕｏｒｉｍａａは、「Ｄｉｇｉｔａｌ Ｔｅｌｅｖｉｓｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｒ」［ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｕｌｔｉｍｅｄｉａ ａｎｄ Ｅｘｐｏ ２００１（東京（日本）、２００１年８月２２〜２５日、ｐｐ．６８５-６８８）に発行］において、ＤＶＢ-ＭＨＰ規格のマルチメディアサービスにアクセスするための、プラットフォーム内のアプリケーションマネージャーの設計を発表している。実際には、ＤＶＢ-Ｊアプリケーションは、共に動作する１組のＪａｖａクラスであり、これらは、アプリケーションマネージャーがその状態の変化を制御できるように、１つのインスタンスとしてアプリケーションマネージャーに知らせる必要がある。この論文では、ダウンロード可能なアプリケーションのすべての情報がアプリケーション情報テーブル（ＡＩＴ）に記憶される、これは、他の基本的なストリームと共にＭＰＥＧ-２トランスポートストリームに多重化されて転送される。アプリケーションマネージャーは、場所を特定しアプリケーションの情報を知らせるためにこの情報を必要とする。このために、ＪａｖａクラスローダーとＪＶＭのクラス技術が用いられ、アプリケーションクラスを様々なソースからロードしてネームの衝突を解決した。

一般に、ユーザーにグラフィカルインターフェースを与えてサービスを選択させるため、ナビゲーター又は電子番組ガイド（ＥＰＧ）が用いられる。いったんサービスが選択されると、ＸｌｅｔがＤＶＢ端末にダウンロードされ、ＤＶＢ端末が、ユーザーにグラフィカルインターフェースを示してＸｌｅｔにより提供される機能を選択させる。Ｊ．Ｃｏｓｍａｓ他は「Ｐｒｏｖｉｄｉｎｇ Ｆａｓｔ Ｐｒｏｔｏｔｙｐｅｓ ｏｆ Ｓｅｒｖｉｃｅｓ ａｎｄ Ａｕｔｏｍａｔｅｄ Ｇｅｎｅｒａｔｉｏｎ ｏｆ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｃｏｎｖｅｒｇｅｄ Ｂｒｏａｄｃａｓｔ ａｎｄ Ｃｅｌｌｕｌａｒ Ｎｅｔｗｏｒｋｓ」（２００４年７月５日現在インターネットからｗｗｗ．ｉｓｔ-ｏｖｅｒｄｒｉｖｅ．ｏｒｇ／ＨｙＷｉＮ２００３／ｐｒｏｃｅｅｄｉｎｇｓ／２．４１．Ｈｙｗｉｎ-ＰａｐｅｒＳｅｒｖｉｃｅｓ２００３-ｌｌ-１６．ｐｄｆにてダウンロードされる）において、一般グラフィカル・プレゼンテーション・エンジンを与えるユーザーインターフェースを開示しており、このエンジンは、サービスユーザーインターフェースをユーザーに与えるグラフィカルユーザーインターフェースの下で動作する。このプレゼンテーションエンジンは、メタデータを解釈し、グラフィカルユーザーインターフェースを介したユーザーの相互作用を取り込み、メタデータにより記述された対応するコマンドを実行する。

ＷＯ０３／１０４９８０には放送会社により用いられる相対的に低いデータレートによるデータ転送において検出可能な遅延が生じる問題が述べられている。この特許出願には、ＪＶＭの操作方法が記載され、親Ｊａｖａクラスファイルを含んだモジュールをロードすること、及び親Ｊａｖａクラスファイル中に列挙された子孫Ｊａｖａクラスファイルを特定することを含む。この親Ｊａｖａクラスファイルは、この子孫Ｊａｖａクラスファイルの事前ロードと同時に実行される。

ＵＳ２００４／００３１０５２には、アプリケーションサーバとＴＶナビゲーターを実行している加入者ＳＴＢとの間で通信を行なうＣＡＴＶシステムが記載されている。このＴＶナビゲーターは、すべてのコンテンツ及びアプリケーションが書かれるミドルウェア環境である。アプリケーションはミドルウェアの先頭に常駐する。コンテンツとアプリケーションはもっぱら業界標準のＨＴＭＬとＪａｖａにて書かれる。従来のテレビコンテンツはＨＴＭＬ及びＪａｖａへのＴＶ特定エクステンションを用いてＷｅｂコンテンツと統合される。

一般に、高機能テレビコンテンツはＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｊａｖａ及びその他のＷｅｂ技術の組み合わせを用いて与えられる。ＷＯ０２／１７６３９には、テキストベース・スクリプト・エンハンスメント・ファイルをパーズしてプラットフォーム依存のエンハンスメント・ファイルを生成するシステム及び方法が開示されている。このスクリプトファイルはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋ-ｕｐ Ｌａｎｇｕａｇｅ）フォーマットで構成でき、パーサーはＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅ）トランスレータとし得る。このパーサーはＨＴＭＬ及びＪａｖａＳｃｒｉｐｔを他のアプリケーションからインポートしてもよい。

インターネット環境内で、近年、Ｗｅｂサイトの双方向性は、典型的には質疑応答又は賭け事システムにおいて用いられる動的Ｗｅｂページの出現によって強化されてきた。このシステムはソフトウェアプラットフォーム上で動作するＪａｖａ Ｗｅｂサーバを用いることによってセットアップできる。このサーバは顧客からの要求を処理し、データベースサーバを接続し、Ｗｅｂブラウザーから動的コンテンツを生成するためにＪａｖａサーブレットを用いる。

Ｃ．Ｐｅｎｇ及びＰ．Ｖｕｏｒｉｍａａ、「Ｉｎｔｅｒａｃｔｉｖｅ Ｄｉｇｉｔａｌ Ｔｅｌｅｔｅｘｔ Ｓｅｒｖｉｃｅ」（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ６ｔｈ Ｗｏｒｌｄ Ｍｕｌｔｉｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｙｓｔｅｍａｔｉｃｓ，Ｃｙｂｅｒｎｅｔｉｃｓ ａｎｄ Ｉｎｆｏｒｍａｔｉｃｓ，Ｊｕｌｙ １４-１８，２００２）には、Ｊａｖａ-ＸＭＬに基づいた解決策が記載されており、この解決策では、デジタルテレビインフラストラクチャーにより提供されるリターンチャンネルを用いることによってデジタル文字多重放送に双方向通信を付加することができる。このアプローチは、クライアント／サーバモデルに基づいており、ＸＭＬベースのメッセージング機構とＪａｖａサーブレット技術を利用する。

出願人は、動的ページの作成のためにＪａｖａサーブレットを用いる技術はクライアント-サーバアーキテクチャーに基づいており、サービスロジックはサーバ側にあるが、プレゼンテーションはクライアント側に存在することに注目した。出願人は、ＳＴＢがリターンチャンネルを使用しない場合、ユーザーとの相互作用により更新し得る動的コンテンツをＳＴＢに与えることができないと分かった。
ＷＯ０３／１０４９８０ ＵＳ２００４／００３１０５２ ＷＯ０２／１７６３９

ｉＴＶアプリケーションを展開する上で重大な問題は、たいていの市販のＳＴＢにおいて、ｉＴＶアプリケーションを記憶し処理するために用いる搭載メモリの量が限定的なことである。

出願人は、受信される双方向コンテンツがＸＭＬにて表されるとき双方向性を軽量ＳＴＢにおいて有利に維持し得ることが分かった。

ＸＭＬは標準汎用マークアップ言語（ＳＧＭＬ）のサブセットである。ＳＧＭＬはマークアップされた電子テキストを記述するための国際標準であり、メタ言語（言語を形式的に記述する手段）である。ＳＧＭＬはどのマークアップが可能か、どのマークアップが必要とされているか、及びどのようにしてマークアップをテキストと区別するかを規定する。一般に、「マークアップ」は「タグ」を使用し、このタグは特定の意味をもつ特定のワードである。タグは、文書を有効にする１組のルールをプログラマーが策定できるようにする。ＸＭＬでは、タグが文書中の要素を特定し、このタグがこれらの要素についての属性を含む。タグはデータ記述又はデータ関係を表し、複数のリソース間をリンクするための機構を与える。

発明の概要
本発明はスクリーン上に表示できるメディアコンテンツを含んだ双方向サービスをデジタル受信装置に提供する方法及びシステムに関するものである。メディアコンテンツは、テレビ視聴者のスクリーン上に視覚化されるシーンを表す記述ファイルによって記述される。記述ファイルは、スクリーン上にどのようにしてシーンを構築するかについての情報を好ましくはマークアップ言語コンテンツのフォーマットにて含む。１シーンは少なくともグラフィカル要素を含む。さらに、シーンは背景（静止画像）と映像コンテンツを含むこともできる。この映像コンテンツはアニメーション、画像又は映画から構成でき、必ずとは限らないが音声信号と組み合わせることができる。デジタル受信装置はハードウェアとソフトウェアを含んだ装置であり、双方向サービスを受信して該サービスを行なう。双方向サービスはスクリーン、例えばＴＶスクリーンやＰＣモニター上に視覚化される。好ましくは、このデジタル受信装置はテレビ視聴者のスクリーン上に表示されるデジタルＴＶ信号をも受信する。好ましくは、このデジタル受信装置はテレビ視聴者のテレビに連動接続されたデジタルセットトップボックス（ＳＴＢ）である。

実際、この双方向サービスはデジタル受信装置において実行されるソフトウェアアプリケーションに対応する。ソフトウェアアプリケーションは、クライアントの呼び出しを受けて、すなわち例えばユーザーのリクエストを受けてデジタル受信装置において開始させることができる。アプリケーションは、インターネット又は放送チャンネルなどの遠隔ネットワーク内に存在し得るサーバからダウンロードし得る。プル型サービスの場合のようにユーザーの要求により呼び出されるのに加えて、アプリケーションはプッシュモードにて開始させることができる、すなわち、クライアントはサーバが情報を送ると例えば新しいコンテンツが利用可能になるのでアプリケーションを自動的に開始する。代わりに、アプリケーションを事前にクライアント内に常駐させ、ユーザーにより自動開始又は起動させることができる。本発明は、受信装置においてダウンロード及び／又は開始できる放送アプリケーションと、常駐アプリケーションの両方に適する。

以下、双方向サービスを提供できるソフトウェアアプリケーションをサービスアプリケーションという。

出願人は、双方向サービスを提供するサービスアプリケーションが動的サービスロジックを含む場合、メディアコンテンツをクライアント側にて動的に生成できることを見いだした。この動的サービスロジックは、サービスアプリケーション自体に記憶されているか又はサーバからダウンロードされるデータを用いてオンザフライで動的情報を生成する能力を与えるアプリケーションロジックである。この動的サービスロジックは１又は複数のビジネスロジックから成り、例えば、ユーザーのリクエストを受けてクライアント側で実行時に文脈依存コンテンツを生成することを担う。この場合、ビジネスロジックは、例えばユーザーデータを変換若しくは編成するか、又はユーザーデータを他の情報と組み合わせるために、（何らかの）ユーザーデータに論理操作を行なうソフトウェア機能の処理構成要素である。このビジネスロジックはロジックマネージャーと称されるソフトウェア構成要素により「開始」すなわちインスタンス化され、このロジックマネージャーはまた、ビジネスロジックにより定められた論理操作を実行できるユーザーデータに対してビジネスロジックをアクセスさせる。ユーザーデータへの論理操作により、オンザフライで「新しい」メディアコンテンツが生成され、スクリーン上に視覚化される。ユーザーデータはスクリプトの視覚的表現を生成するよう機能する「生」の情報コンテンツを含む。

好ましくは、動的サービスロジックは１組のＪａｖａクラスとして定義される。Ｊａｖａクラスはクライアントプラットフォームのランタイム環境においてインスタンス化され得る。

デジタル受信装置は、サービスロジックを実行できる仮想マシンを含む。好ましくは、ロジックマネージャーは１より多いアプリケーションに共通のクライアントプラットフォームの部分であり、ビジネスロジックはサービスロジックのアプリケーション特定構成要素である。ビジネスロジック（１又は複数）とロジックマネージャーの両方とも、サービスアプリケーション中に含まれる動的サービスロジック内に含まれる。

詳細な説明ではクライアント／ＳＴＢの例を用いているが、本発明はパーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、ポケットパーソナルコンピュータ又は電子信号を受信でき且つテレビなどの映画表示装置に送信できるその他の任意の種類の電子装置を含めてすべてのクライアント装置に適用できる。ソフトウェアアプリケーションが携帯電話上にインプリメントされる場合には、表示装置を電話の組み込みディスプレーとするか、又は携帯電話を接続できるＤＴＶドックステーションとすることができる。

本発明の利点の一つは、ＳＴＢにおいて実行されるアプリケーションが、双方向性を与える動的シーンをローカルで生成するサービスロジックを含む場合、リターンチャンネルの無いＳＴＢにおいても双方向サービスを実行できることである。

本発明によるサービスアプリケーションは、生のアプリケーションデータと実行可能なコード部分とを含む。この実行可能なコード部分は、メディアコンテンツをスクリーン上に表示するための第１の実行可能なコードと、動的サービスロジック中に含まれて、新しいメディアコンテンツを生成できる第２の実行可能なコードとを含む。

好ましくは、新しいメディアコンテンツを生成するよう働き得るこの生の情報データは、少なくともマルチメディアファイル（例えば、映画、画像及び音楽）、すなわちユーザーデータを含まないデータ部分に対してＨＴＭＬ、ＷＭＬ及びＸＭＬなどのマークアップ言語を用いてフォーマットされる。さらに好ましくは、このフォーマットはＸＭＬ規格を用いて記述される。

詳細な説明
一般にサービスアプリケーションは一連のシーンを含む。１シーンはスクリーン上でのメディアコンテンツの「視覚的」構成である。換言すれば、シーンは、配信されたメディアコンテンツの映像（及びメディアコンテンツにサウンドが含まれている場合には音声）についてのスクリーンの視聴者による知覚である。シーンは、双方向サービスが放送される番組と少なくとも部分的に重なる場合にはデジタルＴＶ信号を含むこともできる。メディアコンテンツは、背景（静止画）、映像（映画又は画像）、及びテキストとグラフィックスとを含んだグラフィカル要素を含むことができる。グラフィカル要素はグラフィカル構成要素により表され、グラフィカル構成要素は、要素、選択時の特性又は一般に要素への作用を選択可能にする機能を定める。

シーンは、テキスト、音声、映像、音楽ファイルなどの要素の集合として表すことができ、その各々又は任意の組み合わせにより静止画及び／又は動画、テキスト及びサウンドを生じさせる。シーンは静止していてもよく、すなわち、アプリケーションが作られるときにそれらのコンテンツが完全に定められてもよく、又は動的にしてもよく、すなわち、アプリケーションが作られるときそれらのコンテンツ（の一部）は定められないが、文脈依存であり、例えばユーザーの要求、又はデータの更新を受けて生成される。換言すれば、動的シーンは、例えばＳＴＢのランタイム環境においてオンザフライにて生成及び配信される。

静止シーンは、Ｗｅｂブラウジング及びハイパーメディアリンク（すなわち、ハイパーリンク）に類似の機能によりナビゲーション中に探索できる。新しいコンテンツを生成しないシーン内でのシーンを介するナビゲーションに関連する機能は、ローカル双方向性ともいうが、これは「低レベル」の双方向性を意味する。

サービスアプリケーションは通常はデジタルＴＶ信号と同時に送信されるので、必ずではないが、グラフィカル構成要素を表示されたＴＶ画像に部分的に又は完全に重ねることができる。例えば、シーン中に含まれるウインドウ内にてＴＶ信号をサイズ変更して再生できる。シーン中に含まれる要素の例として、ＴＶスクリーン上でスクロールできるテキストリスト、テキストを挿入できるフィールド、相互に排他的な選択肢の選択可能なメニュー、及びＷｅｂページへの前方リンクとしてＵＲＬ（ユニホーム・リソース・ロケータ）が関連付けられたグラフィカル要素が挙げられる。

ソフトウェアアプリケーションがＷｅｂアプリケーションである特別な場合、シーンはＷｅｂページ、例えばインターネットから送信されたＨＴＭＬ又はＸＨＴＭＬデータである。

ソフトウェアアプリケーションは好ましくはＪａｖａにて実行されるが、このことは必須ではない。全体システムはソフトウェアに基づいており、オブジェクト指向プログラミング言語を用いて開発されることが分かる。アプリケーションデータ、少なくともマルチメディアコンテンツを含まないものは、好ましくはＸＭＬなどのマークアップ言語を用いて記述される。

図１は、本発明の態様により、スクリーン上に表示されるメディアコンテンツを受信するためのデジタル受信装置に与えられるサービスアプリケーション１０を概略的に示す。例えば、このアプリケーションは放送チャンネルから又は通信網からダウンロードできる。この態様では、サービスアプリケーション１０は、例えばＴＶ-ＳＣＡＲＴケーブルにより双方向サービスを表示するＴＶスクリーン３に接続されたＳＴＢにおいて開始される。アナログＴＶ表示システムの場合、ＳＴＢのコンピュータハードウェアとＴＶスクリーンとの間でデジタル-アナログ変換器（図１には図示せず）を接続してデジタル信号をアナログ信号に変換することもできる。アプリケーション１０はアプリケーション実行可能部分１、生のアプリケーションデータ２及び記述ファイル（１８）を含み、アプリケーションの後の二つの部分（２及び１８）は実行可能なコードを含まないデータを含む。生のアプリケーションデータ２は特定のアプリケーションに固有のものとし得る。実行可能なアプリケーション部分１はミドルウェアソフトウェア層（以下、「プラットフォーム」又は「クライアントプラットフォーム」という）を含み、このミドルウェアソフトウェア層は、実行可能なプログラムを含んだソフトウェアモジュール、すなわちパーサー８、アプリケーションコントローラ１６、ロジックマネージャー１４、スクリーンマネージャー１１、グラフィック構成要素９及びマルチメディア（ＭＭ）構成要素１５を備える。この実行可能なアプリケーション部分１はまた、アプリケーション特定のモジュール、すなわちビジネスロジックソフトウェアモジュール１２を含む。プラットフォームとアプリケーション特定の論理装置との違いは、単にソフトウェア開発者の側から見て好ましいインプリメンテーションとして理解すべきであり、限定的に考えるべきでない。

アプリケーション実行可能な部分１は第１及び第２の実行可能なコードを含み、この第１の実行可能なコードはスクリーンマネージャー１１及びグラフィカル構成要素９（及び好ましくはＭＭ構成要素１５）中に含まれ、ロジックマネージャー１４とビジネスロジック１２とが第２の実行可能なコードを含む。好ましくは、このアプリケーション実行可能な部分はパーサー８とアプリケーションコントローラ１６とを含む。

いくつかのアプリケーションでは１又は複数の内部データベースを構築しなければならないかもしれず、この内部データベースにおいて、テキスト又はマルチメディアである生のデータが、アプリケーションの実行可能な部分のソフトウェアモジュールにより読み取り理解できるフォーマットにて記憶されるか、又はそれらのソフトウェアモジュールにより使用されるのに適した様にデータを編成できる。図１に示された態様では、アプリケーション１０はデータベース（ＤＢ）１３を含む。ＤＢ１３は図１においてアプリケーション１０の実行可能な部分１中にグラフィカルに表されているが、当然ながらＤＢ１３は実行可能なコードを含まない。

この態様では、プラットフォームは特定のアプリケーションに限定されない実行可能なソフトウェアの部分を含む。このプラットフォームは例えば様々な双方向サービス、すなわちＳＴＢにおいて実行し得る様々なアプリケーションを生成するためにアプリケーション開発者が使用できる。当然に、サービスアプリケーションのプラットフォームは、ＭＨＰなどの一般にＳＴＢ内に常駐するミドルウェア層のレベルよりも高いアプリケーションレベルに配置されたミドルウェア層である。プラットフォームは永続的にＳＴＢ内に常駐し得るが、このことはＳＴＢの持続的な記憶容量が十分に大きいことを意味する。ハードウェアリソースが限定的なＳＴＢの場合、プラットフォーム（及び実際にはサービスアプリケーション）はランタイム中に例えばＳＴＢの揮発性キャッシュメモリを駆動する。

以下の説明から明らかになるように、ビジネスロジック１２とロジックマネージャー１４はサービスアプリケーションの動的サービスロジック中に含まれ、クライアント側で文脈依存メディアコンテンツを生成できる。

実行可能なコードは、一連の命令を含んだファイルとしてしばしば扱われる１つの（又は一部の）実行可能なプログラムである。実行可能なコードはメソッドとも言われる。好ましい態様では、アプリケーションの実行可能なコード（メソッド）はバイトコードやｐコードなどの中間コードであり、これはプロセッサにより理解されるコンパイルされたファイル（すなわちオブジェクトコード）である。ソフトウェアアプリケーション１０のコードを実行可能にするため、ＳＴＢは仮想マシンを備え、この仮想マシンは、該コードを実行できるソフトウェアの一部であり、コンピュータプラットフォーム、すなわちアプリケーションプログラムが実行できる基礎のコンピュータシステムと、ソフトウェアを操作できるエンドユーザーとの間の環境を作ることができる。特に、この仮想マシンはホストハードウェア（例えばＳＴＢ内にあるコンピュータハードウェア）上にてネイティブコードで書かれたプログラムであり、このホストハードウェアが一般中間コードをハードウェア上で使用可能なコードに翻訳する。好ましくは、この仮想マシンシステムはＪａｖａ実行可能なアプリケーションを実行させるＪａｖａ仮想マシン（ＪＶＭ）である。特に、ＪＶＭはＪａｖａクラスを読み出し、クラスファイルの実行可能な部分を実行する。

図１に示された態様のＳＴＢはリターンチャンネルをもたない。生のアプリケーションデータ２はユーザーデータ７とマルチメディアコンテンツ１７とを含み、一方、記述ファイル１８はコンフィギュレーションファイル４、静止シーンの定義用の記述ファイル（ページ５をいう）、動的シーンの記述用のテンプレートファイル（テンプレート６という）を含む。ユーザーデータ７はエンドユーザーに伝達されるテキスト情報、例えば、特定の宛先にオンデマンドでスケジュールを与える双方向サービスのアプリケーションにおける完全な列車運転時刻表などを表す。このユーザーデータは「生」のテキスト情報コンテンツを含み、これをエラボレートして視覚化されるテキストを生成する。もちろん、このテキストはシンボル、ブレット又は一般にスクリプト視覚表現に含まれるその他のフィールドを含むことができる。

構成要素マルチメディアコンテンツ１７は、シーンを構成するため、場合によっては他のグラフィカル要素と共に、エラボレートされていないマルチメディアファイルを含む。マルチメディアファイルの例としては、背景写真、アイコン、アニメーション、サウンド又は音楽の一節が挙げられる。マルチメディアファイルはＪＰＥＧ、ＧＩＦ、ＰＮＧ及びＭＰ３などの様々なフォーマットにし得る。

記述ファイル１８はスクリーン上に視覚化されるシーンを表す。後で明らかになるように、双方向サービスの場合、記述ファイルの一部、すなわちテンプレートファイル６は、ある特定のアプリケーションデータに基づいて新しいメディアコンテンツを生成可能にするプログラム（すなわち、実行可能なコード）へのリンク（１又は複数）を含む。換言すれば、シーンの一部、例えば情報提供コンテンツを依然として生成しなければならないので、テンプレートファイルは全体のシーンの記述を含まない。

コンフィギュレーションファイル４は、アプリケーションの開始段階で用いられ、グラフィック構成要素９及びマルチメディア（ＭＭ）構成要素１５の初期化に関する情報を含む。グラフィック構成要素９及びマルチメディア（ＭＭ）構成要素１５は、例えば背景、ロゴ、メニュー選択肢用のフッターのレイアウト又はＴＶスクリーン上でのその位置及びサイズを定めるため、アプリケーションのすべてのシーンに共通である。

ページ５は（例えば情報提供Ｗｅｂページのための）静止シーンを記述するのに用いられる１組の記述ファイルを含み、例えば開発段階にてサービス開発者によりアプリケーションが作られるとき、これらのコンテンツが作られる。この記述ファイルはランタイム時には変えられない。この記述ファイルは、どのようにシーンをＴＶスクリーン上に与えるか、及びローカルの双方向性、例えばブラウジングをどのように管理しなければならないかについて、完全な記述を含む。記述ファイルはグラフィック構成要素９中のメソッドを呼び出す。グラフィック構成要素は、例えばコンテンツのフォーマット及び位置やそれらの関係を定義する（例えばコンテンツは別のコンテンツの表示が終了した後にコンテンツが現れる中心がどこにあるかに依存する）。特に、記述ファイルがＸＭＬフォーマットならば、記述ファイルはＸＭＬタグを含み、その各タグは特定のグラフィック構成要素を示し、タグに関連の属性はそのグラフィック構成要素のメソッド（１又は複数）に対応している。メソッドはスクリーンマネージャー１１により呼び出される。Ｊａｖａにおいて、グラフィック構成要素はクラスにより表され、ＸＭＬタグの属性はグラフィック構成要素におけるそのクラスのクラス名を含む。このタグ属性は当該クラスに関連のメソッドに対応し、スクリーンマネージャーはランタイムオブジェクトを生成することにより当該クラスをインスタンス化する。これらのＸＭＬタグは「記述的」ＸＭＬタグということができる。というのは、後で詳細に説明するように、先進の双方向性特徴をインプリメントするのに用いられるテンプレート中に含まれる「呼び出し」タグ（又は「ユーザーデータ」タグ）と混同すべきでないが、シーン中にどのようにコンテンツを提示するかを記述するのに用いられるからである。静止シーンの場合、記述的タグのみが用いられ、サポートされる唯一の「双方向性」は、例えばシーン内でシーンを通じてナビゲーションを可能にするハイパーリンクである。

テンプレートモジュール６は、動的コンテンツ、すなわちオンザフライで生成され文脈依存であるコンテンツの場合に用いられる。構成要素テンプレートは、少なくとも１つのテンプレートファイルを含み、一般にはテンプレートファイルの集合を含む。テンプレートファイルは記述ファイルと同様であると考えることができるが、後に詳細に説明するように、動的情報を構築する動的サービスアプリケーションロジックの論理要素へのリンク（１又は複数）を含むことにより、動的情報の生成をサポートする。特に、動的シーンの場合、そのシーンに対するテンプレートファイルは、マークアップ言語、好ましくはＸＭＬにより記述され、また、動的サービスロジックにおいてメソッドを呼び出す動作への論理リンクである「呼び出し」タグを含む。この動的サービスロジックはアプリケーション１０の実行可能な部分１に含まれ、ロジックマネージャー１４及びビジネスロジック構成要素１２を含む。特に、この呼び出しタグはロジックマネージャーに対し、ビジネスロジックユニット１２において特定のビジネスロジック（すなわち、タグ中に特定された）中に含まれるプログラムを実行することを要求する。換言すれば、この呼び出しタグは、所与のユーザーデータに特定の論理操作を実行するビジネスロジックのインスタンス化を要求する。このビジネスロジックはロジックマネージャーによりインスタンス化され、このロジックマネージャーは、クライアントプラットフォームの他の部分とビジネスロジックとの間で何らかの論理インターフェースとして機能する。このロジックマネージャーは、ビジネスロジックの実行の要求の流れを制御し、その実行から出力ファイルを受け取り、よって出力ファイルの流れも制御する。ロジックマネージャーはビジネスロジックにおけるプログラム中にメソッドを呼び出すことによりビジネスロジックをインスタンス化し、論理操作を実行する必要のあるデータを与え、そして論理操作の結果、すなわちビジネスロジックの出力を得る。特に、インスタンス化されるとき、このビジネスロジックは、例えば、ＤＢ１３又はその特定部分へのデータポインタ（すなわち有効リンク）によって当該コンテンツにアクセスするロジックマネージャーによって、コンテンツを受信する。

好ましくは、ビジネスロジックはプラットフォームの外部にあり、ロジックマネージャーはプラットフォームに含まれる。というのは、プラットフォームが１より多いアプリケーションに共通のプログラムを含むことができるように、ビジネスロジックは特定のサービスアプリケーションに限定されたビジネスロジックを含むことができるからである。

好ましくは、アプリケーションデータは記述ファイル１８及びユーザーデータ７（すなわち画像又はサウンドを除く）の一般コンテンツフォーマットとしてＸＭＬを用いる。この利点は、異種ソースからのコンテンツを統合することである。さらに、メッセージの大きさは相対的に小さく、例えば双方向ＴＶ（例えばＤＶＢ-ＨＴＭＬ）の場合にＨＴＭＬファイルの大きさよりも小さいので、このメッセージ指向のアプローチはＧＰＲＳ、インターネット又は放送チャンネルに情報を送信するのに適している。よって、コンフィギュレーションファイル４、ページ５、テンプレート６及びユーザーデータ７は好ましくはＸＭＬフォーマットにする。マルチメディアコンテンツ１７は、ＭＰＥＧ、ＪＰＥＧ、ＭＰ２などの様々なフォーマットで表現できる例えば写真、音楽、ビデオクリップなどを含んだマルチメディアファイルを含む。

一般には、パーサー８は、所与の公式の文法、すなわち公式言語の記述に基づいて入力ファイルの文法構造を解析するコンピュータプログラム又はプログラムの構成要素であり、このプロセスは構文解析として知られている。マークアップ言語に基づいた（例えばＸＭＬに基づいた）アーキテクチャーでは、パーサーはプログラム、例えばマークアップ言語にてファイルを読み取ることができるＪａｖａソフトウェアの一部である。次に、パーサーは入力文書を構成単位（例えば、ＸＭＬタグやタグの一部）に分解する、すなわち、他のプログラムにより管理できるように入力文書をパーズする。特に、パーサー８はコンフィギュレーション４、記述５、テンプレート６及びユーザーデータ７を形成するＸＭＬファイルを読み取り、それらをアプリケーションコントローラ１６に対して「翻訳」することができる。

アプリケーションコントローラ１６は、実行する操作が静的情報のエラボレーションであるか又は動的情報のエラボレーションであるかにそれぞれ依存して、コマンド（例えばＸＭＬタグ）をスクリーンマネージャー１１か又はロジックマネージャー１４に送るコンピュータプログラム（又は部分）である。このアプリケーションコントローラは、生のアプリケーションデータ及び記述ファイルから発した（パーズされた）情報の一種の論理コーディネータとして機能する。さらに、アプリケーションコントローラは、ユーザー相互作用によりトリガーされたイベントに対応するスクリーンマネージャーからの要求を受け取る。

図１ではそれらは夫々の論理機能を分離するため２つの別個のソフトウェアモジュールとして表されているが、パーサーとアプリケーションコントローラは１つの実行可能なプログラムとでき、例えば同じＪａｖａクラスの異なるメソッドとし得る。

スクリーンマネージャー１１はグラフィック構成要素９の構成及び管理に関してアプリケーションコントローラ１６から入力を受け取る。これらの入力は記述ファイル１８中に含まれる。特に、これは、グラフィック構成要素、それらの属性（例えば大きさ、位置、色及びテキストフォーマッティング）及び反応（例えばフォーカスされたときの色の変化）についての情報を受け取る。換言すれば、スクリーンマネージャー１１はグラフィック構成要素９を管理し、画像レンダリング及びＴＶスクリーン上のフォーカス管理を担う。さらに、スクリーンマネージャーはユーザーの操作をアプリケーションコントローラへの要求に変換する。

グラフィック構成要素９は、１より多いサービスアプリケーションに共通にし得るグラフィックライブラリ（例えばコンボボックス、スクロールリスト）、又は特定のアプリケーションに限定しうるグラフィックライブラリ（例えばロゴ、背景及び仮想キーボード）を表す。グラフィカル構成要素の例としては、コンボボックスやラジオボタンが挙げられる。Ｊａｖａでは、グラフィカル構成要素はグラフィカルユーザーインターフェース（ＧＵＩ）（しばしばウィジェット又はコントロールという）にて編成され、低レベルの作図や相互作用ルーチンのためのアブストラクション・レイヤを提供する。よって、ＧＵＩはＴＶスクリーン上にグラフィックス／ウィジェットを描き、遠隔コントロールによりユーザーから情報を入力する機能を含む。より一般には、ＧＵＩ及び一般にグラフィック構成要素は、シーンの要素により表されるソフトウェアツールであり、ユーザーとアプリケーションの内部作用との間を取り持つ。グラフィック構成要素は、遠隔コントロールなどのユーザーインターフェースを介してユーザーにより少なくとも部分的に選択可能とし得る。この場合、各グラフィック構成要素に対してユーザー相互作用に関連した反応（例えばメニューの循環性やフォーカスされた要素をどのように強調するか）を定義できる。

ロジックマネージャー１４はビジネスロジックを取り扱うプログラムである。図１の表現では、このビジネスロジックはソフトウェアモジュールであるビジネスロジック１２中に含まれる。このビジネスロジックは、ユーザーの動作に基づいた動的コンテンツの生成など（例えば要求データの抽出、新しい情報を生成するためのデータの結合、データ順序付けなど）の先進の双方向性特徴をインプリメントするのに用いられる。ロジックマネージャーの活動の一部は、論理リンク（例えばタグ）をロジックマネージャーに送るアプリケーションコントローラ１６により制御され、ロジックマネージャーが、特定のビジネスロジック及びそのメソッドの実行に関連したオブジェクトのインスタンス化を要求する。Ｊａｖａインプリメンテーションでは、このビジネスロジックは、Ｊａｖａクラスによって表されるロジックマネージャーによりインスタンス化された１又は複数のＪａｖａクラス（一般に１つ）である。ビジネスロジックをインプリメントするクラスと、実行すべきメソッド（１又は複数）との両方が、呼び出しタグの属性として規定される。ビジネスロジックに関連したクラスは、ロジックマネージャーにより特定（提供）されたユーザーデータ７から取り込まれた何らかの特定コンテンツ上でインスタンス化される。好ましくは、サービスアプリケーションはＪａｖａにて実行され、サービスアプリケーションの実行可能なソフトウェアモジュールは１組のＪａｖａクラスとして定義される。Ｊａｖａでは、ロジックマネージャーの活動は、リフレクションと称するＪａｖａ技術に基づいており、所与のクラス名に対してオブジェクトをインスタンス化し、所与のメソッド名に対して静的メソッド及びインスタンスメソッドを呼び出し、１又は複数のＡＰＩをインプリメントするランタイム時にクラスを生成することを可能にする。これらのクラス名はビジネスロジックに含まれるものである。テンプレート中の呼び出しタグに対応して、アプリケーションコントローラは、ビジネスロジックのクラスに対応した１以上のオブジェクトをインスタンス化し、そのメソッドを呼び出すことをロジックマネージャーに要求する。

ビジネスロジック１２に対応したオブジェクトは、ロジックマネージャーにより特定されるデータソースによってインスタンス化される。データは、サービスアプリケーションがパーサー８及びアプリケーションコントローラ１６によりそれとインターフェースすべくコードを書く場合には、例えばルックアップテーブル（例えばＸＭＬルックアップテーブル）から、又はデータベース（図１のＤＢ１３）から取り込まれる。したがって、この外部のデータソースはユーザーデータ７（又はその一部）又はルックアップテーブル又はデータベースであり、これはユーザーデータから抽出されたデータを含み、この抽出されたデータは必要ならパーズされて適当なデータ構造に分析される。

実際、データベース（ＤＢ）１３は、ビジネスロジックが扱うことのできる適当な構造にてユーザーデータ７を記憶するために、ロジックマネージャー１４により生成さる。換言すれば、ロジックマネージャーのメソッドは、パーズされたユーザーデータをパーサー８から取り込み、ビジネスロジックが読み取ることのできるフォーマット及び構造に編成する。Ｊａｖａでは、ロジックマネージャー中のメソッドは、ハッシュテーブルなどのＪａｖａ構造（しばしばリンクリストのアレイとして編成される）を構築するように、パーズされたユーザーデータを編成する。

好ましい態様では、ビジネスロジックのインスタンス化と共に用いるユーザーデータ（一部）は、コンフィギュレーション４又はテンプレート６中に含められ得る「ユーザーデータ」タグによって定められる。ユーザーデータタグを読み取るとき、アプリケーションコントローラはそのタグをロジックマネージャーに送る。ロジックマネージャー中のメソッドは、ユーザーデータタグの属性中に定められたデータ（一部）を取り込み、データポインタにより記述されるデータ構造をＤＢ１３中に作る。このデータポインタは、当該ビジネスロジックのインスタンス化が要求されるとき呼び出しタグにより呼び出されるビジネスロジックにロジックマネージャーによって与えられる。

アプリケーションがＳＴＢにおいて開始されるとき、パーサー８はコンフィギュレーションファイル４を読み取るが、このコンフィギュレーションファイル４は、使用される共通ファイルについての情報（例えば、スタイルシートやポーリングデータ）を提供し、視覚化される第１のシーンへのリンクを含む。この第１のシーンが静的であるならば、このリンクはページ５中の記述ファイルに向かう。この第１のシーンが動的であるならば、このリンクはテンプレート６中のテンプレートファイルに向かう。好ましくは、コンフィギュレーション、ページ、テンプレート及びユーザーデータはＸＭＬファイルである。よって、好ましくは、このコンフィギュレーションは、スクリーン上に提示される第１のシーンを特定するのに用いられるタグを含んだＸＭＬファイルである。このタグはインデックスページを識別するためにｗｅｂアプリケーション中で用いられるタグに類似している。この第１のシーンは記述ファイル（静的）又はテンプレートファイル（動的）であり得るＸＭＬファイルにより記述される。次に、パーサーは記述又はテンプレートファイルの分析を開始し、ファイルについてパーズされた情報をアプリケーションコントローラに送る。第１のシーンが静的か又は動的かに依存して、アプリケーションコントローラが異なる論理手順に従ってアプリケーションデータを処理する。

第１のシーンが静的であるならば、呼び出しタグはアプリケーションコントローラにより読み取られないので、外部（すなわちプラットフォームの外部）のメソッド、すなわちビジネスロジックは呼び出されない。アプリケーションコントローラはパーズされたデータをページ５中の記述ファイルからスクリーンマネージャーに送り、スクリーンマネージャーはそれを用いてシーンを構築し管理する。限定するものではないが、このパーズされたデータは、下記１）〜３）についての情報を含む。１）どんな要素をシーン内に含めるか（例えばメニュー、コンボボックス及びサイズ変更されたＴＶ信号を表示するウインドウなど）；２）表示される要素の属性（例えば大きさ、位置及びグラフィック特徴［例えば、色、フォントタイプ、サイズなど］）；及び３）例えばユーザーの相互作用の結果としての外部入力を受けて要素がどのように視覚的に振る舞うかを定める要素の反応。要素の反応は、どのように要素をスクリーン上にフォーカスし得るか、それを他の要素により認識できるか否か、すなわち、他のオブジェクトがオブジェクトのステータスを「見る」ことができるか否か、及び認識されたオブジェクトのステータスに従ってそれらのステータスを変更できるか否かを含み得る（この機能は例えばＤＶＢ-Ｊａｖａにおいて定義される）。パーズされたデータは、要素に含まれるべき静止テキスト（例えばメニュー中の項目）、又はマルチメディアコンテンツモジュール１７中に含まれるマルチメディアコンテンツのＵＲＬを含むこともできる。最後に、これらのデータは、シーンを管理するのに適した情報、例えばシーン内のナビゲーション経路、新しいシーンのＵＲＬ、又はシーンの変化をもたらすイベント（例えばユーザーがキーを押すこと又は経過時間）を含み得る。アプリケーションコントローラは、プレーンテキストにより「記述的タグ」、シーンの「要素」、すなわちグラフィック構成要素のインプリメンテーション、それらの位置及びそれらの特性を認識する。グラフィック構成要素のインプリメンテーションは、スクリーン上の視覚的構成からなるシーンの構造を含み、それらの特性は、要素の反応、すなわちユーザーの相互作用を受けて要素がどのように反応するかを含む。シーンのインプリメンテーションの反応の例は、色又はフォントの変更、及びメニューの選択肢を選択した結果のウインドウのポップアップである。ＸＭＬでは、この反応は、記述（又はテンプレート）ファイル中に含まれた記述的タグの属性によって定義される。この情報はグラフィック構成要素からスクリーンマネージャーに送られる。

シーンのコンテンツに関しては、マルチメディアコンテンツはマルチメディアファイル（例えば、ＭＰＥＧ-１、ＪＰＥＧ、ＧＩＦ、ＰＮＧ、ＭＰ３）を含んだ１７から取り込まれ、ユーザーデータコンテンツはＤＢ１３から取り込まれる。シーンを構築するため、スクリーンマネージャー１１はグラフィック構成要素９及び（ＭＭ）構成要素１５においてそれぞれメソッドを呼び出す。ＭＨＰ規格では、グラフィック構成要素はＨＡＶＩ（ホーム・オーディオ-ビデオ・インターオペラビリティ）又はＪａｖａ ＡＷＴ（アブストラクト・ウインドウ・ツールキット）ＡＰＩなどのグラフィックライブラリから取り込まれる。ＭＭ構成要素１５は、ＭＭファイルの実行（例えばＭＰ３ファイルから一曲の音楽を演奏することなど）を可能にするプログラム、例えばＪａｖａクラスを含む。よって、ＭＭ構成要素の例は、音楽プレーヤー又は映像プレーヤー、一般にはマルチメディアプレーヤーである。

以下、動的コンテンツ、例えばユーザーにより押されるソフトキーなどの何らかのイベントの発生に依存した項目リストを含んだシーンの場合を考える。この場合、このシーンはテンプレート６中のテンプレートファイルにより記述される。このファイルのコンテンツの構造及び種類はページ５中の記述ファイルと同様であるが、少なくとも呼び出しタグ、すなわち、プラットフォームの外部にあるプログラムの実行を要求するタグを含む。アプリケーションコントローラ１６がテンプレートファイルを分析している間に呼び出しタグを見つけると、実行すべきプログラムについての情報をロジックマネージャー１４に送る。この呼び出しタグは、発生したイベントに関連のメディアコンテンツをオンザフライで生成するために、この態様ではプラットフォームの外部にあるビジネスロジック１２中の１以上のビジネスロジックを呼び出さなければならないことを示す。換言すれば、表示すべきコンテンツは、外部イベントに従って１以上のビジネスロジックによりランタイムにて生成する必要がある。

この構文解析プロセスは、パーサー８が呼び出しタグに出くわすまで静止シーンについて説明したプロセスに類似している。アプリケーションコントローラ１６は呼び出しタグを検出し、関連のメソッドを認識する。Ｊａｖａインプリメンテーションにおいて、アプリケーションコントローラは、呼び出しタグに関連したクラス及びメソッドが、ビジネスロジック１２のクラスに固有であることを認識する。このクラス（又は一般に実行可能なコード）は、動的コンテンツを生成するために用いられるビジネスロジックのインプリメンテーションである。アプリケーションコントローラが呼び出されたクラスを認識したら、ロジックマネージャー１４に対し（呼び出しタグ中に含まれるリクエストを送ることにより）、１２において呼び出されたビジネスロジックをインプリメントすることにより当該クラスをインスタンス化することを「要求」する。ロジックマネージャーは呼び出されたビジネスロジックにおいて特定されたメソッドをトリガーする。

呼び出されたビジネスロジックは、この態様のＤＢ１３において外部データソースを有するロジックマネージャーによってインスタンス化される。このテンプレートファイルは呼び出しタグの前にアプリケーションコントローラにより検出される「ユーザー-データ」タグを含む。このユーザー-データタグは、ロジックマネージャーをトリガーして、ユーザーデータ７からデータを抽出し、ユーザーデータ（の一部）に対するデータポインタにより記述されるデータ構造、例えば、データベース（ＤＢ）１３を作らせる。

このロジックマネージャーは、呼び出しタグにより要求されるビジネスロジックをインスタンス化するとき、ＤＢ１３へのデータポインタを当該ビジネスロジックに与える。

ユーザー-データタグは、テンプレートファイル中に含ませる代わりに、４のコンフィギュレーションファイル中に埋め込むことができる。この場合、必要なすべてのデータは、サービスアプリケーションが開始されるとき、サービスアプリケーションの実行可能な部分に「ダウンロード」され、すなわち、ＤＢ１３において適当なフォーマットに変換される。しかしながら、ユーザー-データタグがテンプレートＸＭＬファイル中に存在して呼び出しタグの前に検出可能である態様では、呼び出されたビジネスロジックに関連したデータのみが存在する小さいＤＢの作成が可能になるので好ましい。この好ましい態様では、新しいビジネスロジックを実行する必要があるたびにビジネスロジックのみが実行されるので、その新しいビジネスロジックに関連したデータを前に実行したビジネスロジックのデータ上に上書きすることができる。

入力データへの論理操作の結果、ビジネスロジックは表示されるデータ１９を含んだＸＭＬファイルを生成する。

ＸＭＬファイル１９はロジックマネージャー１４に戻され、ロジックマネージャー１４がそれをパーサー８に送る。パーサーはＸＭＬファイル１９を解釈し、パーズされたファイルをアプリケーションコントローラに送り、アプリケーションコントローラが、この「動的情報」（すなわち、ちょうどオンザフライで生成されたもの）をスクリーンマネージャー１１に送りシーンを構成する。スクリーンマネージャーはテンプレートにより特定されるシーン内の場所、例えばメニュー中の特定の場所にこの情報を挿入し、グラフィック構成要素の適当なメソッドをインスタンス化することによって動的コンテンツを含むグラフィックオブジェクトを生成する。

例えば、この動的情報は、外部イベントの結果として生成する必要のある新しい項目リスト、例えば、列車の時刻表のアプリケーションの場合に特定の目的地に結び付けられた列車の駅のリストとし得る。アプリケーションコントローラは、シーンを構築するためにテンプレート中に含まれる情報をスクリーンマネージャーに送る。アプリケーションコントローラは要求リストに関連した呼び出しタグを読み取ると、項目リストはテンプレートファイルにおいて利用可能でなく、ビジネスロジックにより生成しなければならないことを理解する。よって、アプリケーションコントローラは、テンプレートにおいて特定されるクラスのメソッド（１又は複数）を呼び出すことによって動的コンテンツを生成する要求をロジックマネージャーに送り、例えば、該メソッドにより引き起こされる動作は、「ＤＢ１３から取り込まれたデータからリストを生成」できる（この例ではデータは既にＤＢ１３中に存在していると仮定する）。ロジックマネージャーは、リフレクションを用いることにより、クラスをインスタンス化し関連のメソッド（１又は複数）を呼び出す。メソッドにより引き起こされる動作の他の例は、ユーザーにより規定される何らかの基準に従ってＤＢ１３からのデータをフィルタリングすること、ユーザーにより規定されたようにＤＢ１３から取り込まれたいくつかのデータをマージすること、及びデータのプレゼンテーションを順序付け構造化することである。ビジネスロジックは、新しいリストに含まれるべき項目と共にＸＭＬファイル１９をロジックマネージャーに戻す。ロジックマネージャーはこのファイル１９をパーサーに送る。（パーズされたファイルに埋め込まれた）これらの項目は、スクリーンマネージャー、パーサー及びアプリケーションコントローラに与えられる。スクリーンマネージャーは当該項目をリスト中に挿入し、テンプレートにより示されたように該リストをシーン中に挿入する。

最後に、上述したように動的に構築されたシーンは、ＴＶスクリーン３上に提示できる。スクリーンマネージャーにより実行されるシーン構築の論理的な処理とＴＶスクリーン上でのレンダリングとは、前に静止シーンについて説明したのと同様とし得る。

アプリケーションコントローラが呼び出しタグを読み取ると、シーンの構築が「スタンバイ」になり、呼び出しタグに関連した情報がロジックマネージャーに送られることに留意されたい。本発明の好ましい態様によると、ランタイムにてインスタンス化されたＪａｖａクラスがアプリケーションの動的サービスロジック、すなわち、ロジックマネージャー及びビジネスロジックをインプリメントする。ランタイムオブジェクト中へのＸＭＬ呼び出しタグのインスタンス化、すなわち呼び出されたＪａｖａクラスの実行は、Ｊａｖａクラスのメソッドが呼び出されたときにのみオブジェクトが作られることを意味する。

好ましくは、サービスアプリケーションに必要なグラフィック及び／又はＭＭ構成要素のみが９及び／又は１５に存在し、他のグラフィック又はＭＭ構成要素は必要な場合にのみランタイムにてダウンロードされ得る。

第１のページはハイパーリンクに類似の機能により別のページを指し示すことができる。別法として、ユーザーの要求の結果として別のシーンを作成する必要がある。例えば、グラフィック構成要素のインプリメンテーションのために１以上の記述的タグがシーン内に含まれる。スクリーン上のグラフィック選択肢をユーザーが選択した後で、その選択に関連した記述的タグの属性は、ページ５中の記述ファイル又はテンプレート６中のテンプレートファイルへのＵＲＬである。テンプレート又は記述ファイルはＳＴＢのランタイム中に記憶し得る。第２のシーンの構築は、静止シーンと動的シーンとの間の同じ違いを有して第１のシーンの構築の場合と同じ論理的推移に従う。したがって、図１に関する上記詳細な説明は、シーン、すなわち第１のシーンの構築について行われたが、この論理プロセスは（一般に、アプリケーションの初期化が既に実施されている場合にコンフィギュレーション４を取り込むことなく）本態様においてサービスアプリケーションを形成する如何なるシーンの構築に対しても当てはまることが分かる。

図２は、本発明の第２の態様を示し、この態様ではクライアントはサービスセンターのバックエンド、すなわち少なくともサーバを備えると共に特に複数のサーバからなる分散システムとし得るソフトウェアシステムに直接接続される。図１に示された要素に対応するサービスアプリケーション２０の要素には同じ参照番号が付与されており、それらの詳細な説明は省略する。この態様のＳＴＢはリターンチャンネルを備え、リターンチャンネルが、遠隔通信網２４と双方向サービスアプリケーション２０をホストするクライアントとを接続する。遠隔ネットワーク２４は例えばＩＰ、ＧＰＲＳ又はＵＭＴＳネットワークとし得る。リターンチャンネルは有線又は無線の物理経路とし得る。

標準的なクライアント-サーバアーキテクチャー又はＷｅｂサービスに基づいて双方向サービスを実施するのに、リターンチャンネルを使用できる。Ｗｅｂサービスは、アプリケーション間でデータを交換するのに用いられるプロトコル及び規格の集合である。種々のプログラミング言語で書かれ種々のプラットフォーム上で実行されるソフトウェアアプリケーションは、通信網、一般にワールドワイドウェブ上でデータを交換するためにＷｅｂサービスを使用できる。Ｗｅｂサービスはサービス指向のアーキテクチャーアプローチを反映しており、一般にＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）などのオープン規格ＸＭＬプロトコルを用いることにより通信網上で互いに通信する緩く連結されたソフトウェア構成要素である。サービス提供者は、例えばＸＭＬベースの言語であるＷＳＤＬ（Ｗｅｂサービス記述言語）を用いて提供される特定サービスの構造を記述できる。

図２の表現では、クライアント／サーバシステムをフロントエンドとバックエンドとに分離することのアブストラクションが用いられる。フロントエンドはサービスセンターの一部であり、これがユーザーからの入力を集めて処理し、それらを適当なフォーマット、すなわちＨＴＴＰ、ＳＯＡＰなどのようにサーバ（１又は複数）によりサポートされたプロトコルに変換することを担う。バックエンド２３は、フロントエンドからの入力を処理して出力をフロントエンドに与えることができるサービスセンターの部分である。フロントエンドの機能はクライアントとバックエンドとの間のインターフェースと見ることができる。本発明によると、一般にフロントエンドはサーバ側でホストされるが、フロントエンドはユーザーの構内に位置して例えばＳＴＢ内で作動し、また動的サービスロジック内に含まれる。動的サービスロジックについて上記述べたように、それは、ソフトウェア構成要素入力２６及び出力２７を備えたビジネスロジック構成要素２２中のロジックマネージャー及びビジネスロジックを用いて、図２に表されるようにオンザフライで動的情報を生成する能力を与えるロジックを意味する。

サービスアプリケーション２０はＳＴＢ内で実行され、例えばバックエンド２３からＳＴＢにダウンロードされる。テンプレート６及びページ５はＳＴＢのランタイム中に存在するか、又はリターンチャンネル上にてダウンロードされ得る。図２の態様では、ビジネスロジック２２は入力ロジック２６と出力ロジック２７とを備え、これらはロジックマネージャー１４によりクライアントプラットフォームにプラグインされる。アプリケーション２０のクライアントプラットフォームは、ロジックマネージャー１４の他にもパーサー８、アプリケーションコントローラ１６、スクリーンマネージャー１１、及びリターンチャンネル（ＲＣ）マネージャー２５を備える。ＲＣマネージャー２５は遠隔ネットワークとの物理的な接続の設定及び解消を担当する。例えば、リターンチャンネルがＰＳＴＮに接続された電話線である場合、ＲＣマネージャーは電話番号をダイヤルし、呼が開放又は閉鎖されたときロジックマネージャーに知らせることを担う。クライアントプラットフォームはまた、グラフィック構成要素９及びＭＭ構成要素１５を備える。

サービスアプリケーションは、特定メッセージをサーバに送ることによりバックエンド２３（すなわちサーバ）にサービスを要求する。シーンの作成及び管理は、第１の態様で述べたことと同様である。第１の態様との主な相違点の一つは、ビジネスロジックに関連のデータを第１の態様のようにユーザーデータ７から「ローカル」にて取り込むことができるか、又はバックエンド２３から取り込むことができるかである。

この態様では、テンプレートファイルは、２つのビジネスロジック、すなわち、ユーザーデータをサーバに要求するための入力ロジック２６とサーバからの返答メッセージを渡すための出力ロジック２７とを特定する呼び出しタグを含む。前の態様と同様に、呼び出しタグは、特定ユーザーデータ上でビジネスロジックをインスタンス化することをロジックマネージャーに要求する。この態様によるロジックマネージャーは、入力データを含んだメッセージを準備する入力２６においてビジネスロジックをインスタンス化し、該メッセージはバックエンド２３により用いられるプロトコル（例えば、ＨＴＴＰ及びＳＯＡＰ）に基づいたフォーマットにある。例えば、入力データは、例えばＳＴＢのリモート制御機器又は仮想キーボード上で利用可能なマルチタップ機能を用いることにより埋められる電子リクエストフォーム中にユーザーが挿入できる。入力中のビジネスロジックによるメッセージの生成はまた、入力データへの論理操作、例えば入力データを７から取り込まれた他のユーザーデータと関連付けることを含み得る。

入力２６中のビジネスロジックは、メッセージをバックエンド２３に送ることをロジックマネージャーに要求する。それから、ロジックマネージャーはＲＣマネージャー２５を用いることによりメッセージを送る。換言すれば、ロジックマネージャーはバックエンド２３への接続を開設することをＲＣマネージャーに要求する。接続が作動中の場合、ロジックマネージャーは、入力２６から受信したメッセージ（ユーザーからの入力データを含む）をバックエンドに送る。

サーバは、入力データを含んだメッセージをエラボレートし、ＲＣマネージャーにより管理されたリターンチャンネルを介してリプライとして返答メッセージをロジックマネージャーに送り返す。ロジックマネージャーは返答メッセージを受信すると、出力２７中のビジネスロジックをインスタンス化し、返答メッセージをクライアントプラットフォームにより読み取り可能なフォーマット、例えば、ＸＭＬフォーマットに変換する。出力ロジック２７の出力は、ロジックマネージャーがパーサー８に送る１組のＸＭＬデータ２９である。パーサーがＸＭＬデータ２９を解釈し、それをアプリケーションコントローラに送り、アプリケーションコントローラが、（サーバにより生成され、出力によって適当なフォーマットに変換された）この「動的情報」をシーンの構築のためにスクリーンマネージャー１１に送る。スクリーンマネージャーはこの情報をテンプレートにより特定される場所に挿入し、グラフィック構成要素の適当なクラス、例えばグラフィックライブラリ中のＡＰＩをインスタンス化することにより、動的コンテンツを含んだグラフィックオブジェクトを生成する。

図２に示されるアーキテクチャーの利点は、入力データ（及び／又は他のユーザーデータ）の翻訳及び処理が「ローカル」にて、すなわちＳＴＢのランタイム中に行われるので、ｗｅｂサービスのサービスロジックの使用ができること、及びクライアント側アプリケーションとバックエンドとの間での通信が十分に効率的になったことである。

図１は、本発明の態様により、スクリーン上に表示されるメディアコンテンツを受信するためのデジタル受信装置に与えられるサービスアプリケーション１０を概略的に示す。 図２は、本発明の第２の態様を示し、この態様ではクライアントはサービスセンターのバックエンド、すなわち少なくともサーバを備えると共に特に複数のサーバからなる分散システムとし得るソフトウェアシステムに直接接続される。

符号の説明

１ アプリケーション実行可能部分
２ 生のアプリケーションデータ
３ ＴＶスクリーン
１０ サービスアプリケーション

Claims (38)

1. スクリーン（３）に連動接続されると共に、前記スクリーン上に表示できるテレビ信号を受信するよう構成されたデジタル受信装置であって、前記デジタル受信装置は、メディアコンテンツを含んだ双方向サービスを提供するためのサービスアプリケーション（１０）を有し、該メディアコンテンツは、第１の実行可能なコードを実行することにより前記スクリーン上に視覚化される一連のシーンを表す記述ファイル（１８）により記述され、
   前記サービスアプリケーションはユーザーデータ（７）を含むと共に、前記ユーザーデータ（７）に論理操作を行なうことができる第２の実行可能なコードを含んだ動的サービスロジック（１２、１４）を有し、前記第２の実行可能なコードは、デジタル受信装置内で実行されて、前記スクリーン上に視覚化される新しいメディアコンテンツを生成することを特徴とするデジタル受信装置。
2. 前記動的サービスロジックが前記第２の実行可能なコードを前記ユーザーデータ（７）に実行できる少なくとも第１のソフトウェア構成要素、すなわちビジネスロジック（１２）と、前記第２の実行可能なコードをインスタンス化することができると共に前記ビジネスロジックに前記ユーザーデータへのアクセスをさせることができる第２のソフトウェア構成要素、すなわちロジックマネージャー（１４）とを含むことを特徴とする請求項１に記載のデジタル受信装置。
3. 前記サービスアプリケーションが前記装置のソフトウェア環境のランタイムにおいて実行されることを特徴とする請求項１又は２に記載のデジタル受信装置。
4. 前記装置がテレビ視聴者のテレビに連動接続されたデジタルセットトップボックスであることを特徴とする請求項１に記載のデジタル受信装置。
5. 前記第１及び第２の実行可能なコードを処理する仮想マシンを更に備えることを特徴とする請求項１に記載のデジタル受信装置。
6. 前記サービスアプリケーション（１０）が、前記記述ファイル（１８）と前記ユーザーデータ（７）をパーズすることができる第１のソフトウェア構成要素、すなわちパーサー（８）を更に含むことを特徴とする請求項２に記載のデジタル受信装置。
7. 前記記述ファイル（１８）がマークアップ言語コンテンツフォーマットを使用することを特徴とする請求項２に記載のデジタル受信装置。
8. 前記マークアップ言語がＸＭＬ言語であることを特徴とする請求項７に記載のデジタル受信装置。
9. 前記記述ファイル（１８）がマークアップ言語コンテンツフォーマットを使用し、前記パーサー（８）は、記述ファイル（１８）を表すマークアップファイルを第１及び第２の実行可能なコードに準拠した文書に変換すること、及びタグと属性を前記マークアップファイルから抽出することによって前記記述ファイル（１８）をパーズすることができることを特徴とする請求項６に記載のデジタル受信装置。
10. 前記ロジックマネージャー（１４）と前記ビジネスロジック（１２）がＪａｖａクラスとしてインプリメントされることを特徴とする請求項２〜９のいずれか一項に記載のデジタル受信装置。
11. 前記ロジックマネージャーがＪａｖａリフレクション技術を用いることにより前記ビジネスロジックを規定するＪａｖａクラスをインスタンス化することを特徴とする請求項１０に記載のデジタル受信装置。
12. Ｊａｖａ仮想マシン（ＪＶＭ）を更に含むことを特徴とする請求項１０又は１１に記載のデジタル受信装置。
13. 前記ユーザーデータ（７）がマークアップ言語をコンテンツフォーマットとして使用することを特徴とする請求項２に記載のデジタル受信装置。
14. 前記マークアップ言語がＸＭＬ言語であることを特徴とする請求項１６に記載のデジタル受信装置。
15. 前記記述ファイル（１８）が少なくともテンプレートファイル（６）を含み、前記テンプレートファイルが第１のタグ、すなわちユーザー-データタグを含み、該第１のタグが、前記ユーザーデータ（７）を取得すること、及びデータポインタにより記述されたデータ構造（１３）を作ることを前記ロジックマネージャーに要求できることを特徴とする請求項７又は８に記載のデジタル受信装置。
16. 前記データ構造（１３）がＪａｖａデータ構造であり、前記ビジネスロジックが前記第２の実行可能なコード及びデータを含んだＪａｖａクラスであり、前記Ｊａｖａクラスの前記データが前記Ｊａｖａデータ構造を有することを特徴とする請求項１５に記載のデジタル受信装置。
17. 前記テンプレートファイルが第２のタグ、すなわち呼び出しタグを更に含み、該第２のタグが、前記データ構造（１３）上で前記第２の実行可能なコードのインスタンス化を前記ロジックマネージャーに要求することを特徴とする請求項１５又は１６に記載のデジタル受信装置。
18. 前記装置に連動接続されると共に、入力情報をユーザーから受信するフィードバック装置を更に備えることを特徴とする請求項１に記載のデジタル受信装置。
19. 前記サービスアプリケーション（１０）が前記第１の実行可能なコードを含んだ第２のソフトウェア構成要素、すなわちグラフィック構成要素（９）を更に含み、前記グラフィック構成要素が前記メディアコンテンツを前記スクリーン上に表示すること、及び前記フィードバック装置を用いることにより前記ユーザーから情報を入力することができることを特徴とする請求項１８に記載のデジタル受信装置。
20. 前記サービスアプリケーションが前記第１の実行可能なコードを含んだ第３のソフトウェア構成要素、すなわちスクリーンマネージャー（１１）を更に含み、前記第３のソフトウェア構成要素は、前記シーンの表現のために前記記述ファイル（１８）に含まれた命令を受け取ると共に、前記グラフィック構成要素（９）を使用することによりこれらの命令を用いて前記シーンを形成することを特徴とする請求項１９に記載のデジタル受信装置。
21. 前記グラフィック構成要素（９）と前記スクリーンマネージャー（１１）がＪａｖａクラスとしてインプリメントされることを特徴とする請求項２０に記載のデジタル受信装置。
22. 前記サービスアプリケーションがマルチメディアコンテンツ（１７）を更に含むことを特徴とする請求項１に記載のデジタル受信装置。
23. 第１の実行可能なコードが前記マルチメディアコンテンツを再生し表示するためにマルチメディア構成要素（１５）を含むことを特徴とする請求項２２に記載のデジタル受信装置。
24. 前記装置を遠隔の通信網（２４）に接続するためのリターンチャンネルを更に備えることを特徴とする請求項２に記載のデジタル受信装置。
25. 前記サービスアプリケーションが、前記遠隔の通信網との接続を管理するためにリターンチャンネルマネージャー（２５）を更に備え、前記リターンチャンネルマネージャーは、前記接続のステータスについて前記ロジックマネージャーに知らせるために、前記ロジックマネージャー（１４）に論理接続されることを特徴とする請求項２４に記載のデジタル受信装置。
26. スクリーン（３）に連動接続された少なくともデジタル受信装置上に双方向サービスを提供する方法であって、前記双方向サービスは、前記スクリーン上に視覚化される一連のシーンを表す記述ファイル（１８）により記述されるメディアコンテンツを含み、
    ａ）前記デジタル受信装置においてサービスアプリケーション（１０）を実行する工程であって、前記サービスアプリケーションは前記シーンを前記スクリーン上に視覚化するための第１の実行可能なコードと、第２の実行可能なコードを含んだ動的サービスロジック（１２、１４）とを含んだ工程；
    ｂ）ユーザーデータ（７）を前記サービスアプリケーション（１０）に提供する工程；
    ｃ）前記第２の実行可能なコードにユーザーデータへのアクセスをさせる工程、及び
    ｄ）前記ユーザーデータに論理操作を行い、前記スクリーン上で視覚化される新しいメディアコンテンツを生成するために、前記ユーザーデータ上で前記第２の実行可能なコードをインスタンス化する工程、
    を含むことを特徴とする方法。
27. 前記ユーザーデータ（７）がマークアップ言語をコンテンツフォーマットとして使用することを特徴とする請求項２６に記載の方法。
28. 前記記述ファイル（１８）がマークアップ言語をコンテンツフォーマットとして使用することを特徴とする請求項２６に記載の方法。
29. 前記マークアップ言語がＸＭＬ言語であることを特徴とする請求項２７又は２８に記載の方法。
30. 前記工程ｃ）の前に前記ユーザーデータ（７）をパーズする工程を更に含むことを特徴とする請求項２６〜２９のいずれか一項に記載の方法。
31. 工程ｃ）が前記ユーザーデータ（７）を取得する工程と、データポインタにより記述されたデータ構造（１３）を作る工程とを含むことを特徴とする請求項２６〜３０のいずれか一項に記載の方法。
32. 前記工程ｃ）の前に記述ファイル（１８）をパーズする工程を更に含み、このバーズ工程は、前記記述を前記第１及び第２の実行可能なコードに準拠した文書に変換すること、及びタグと属性を前記記述ファイルから抽出することを含むことを特徴とする請求項２８又は２９に記載の方法。
33. 少なくとも記述ファイル（６）中に含まれた第１のタグ、すなわち呼び出しタグにおいて規定された１以上の属性により工程ｄ）を要求することを特徴とする請求項３２に記載の方法。
34. 動的サービスロジック（１２、１４）を、前記第２の実行可能なコードを含んだＪａｖａクラスとしてインプリメントすることを特徴とする請求項２６〜３３のいずれか一項に記載の方法。
35. Ｊａｖａリフレクション技術を用いて工程ｄ）を実行することを特徴とする請求項３４に記載の方法。
36. 前記第１の実行可能なコードがＪａｖａに準拠していることを特徴とする請求項２６〜３５のいずれか一項に記載の方法。
37. デジタルＴＶ信号を前記デジタル受信装置に配信する工程を更に含むことを特徴とする請求項２５に記載の方法。
38. 前記少なくともデジタル装置がテレビ視聴者のテレビに連動接続されたデジタルセットトップボックスであることを特徴とする請求項３５に記載の方法。