アプリケーションの表示を可能にするAPIに関連付けられたアプリケーションフレームワークを含んだウェブエンジンであってIPTV端末機能ITFのために構成されたウェブエンジンにおける方法であって、相互に関係する階層ツリー構造の中に配置された少なくとも2つのアプリケーションを記憶するステップと、少なくとも1つのアプリケーションを目標とするイベントを受信するステップと、少なくとも1つのアプリケーションを目標とする前記受信したイベントのディスパッチを制御するステップであって、前記受信したイベントを目標アプリケーションへディスパッチするステップを更に含む、ステップと、各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定するステップと、前記イベントが判定されるべきである場合に、前記判定対象アプリケーションのために前記イベントを処理するステップと、前記イベントが判定されるべきでない場合に、前記階層ツリー構造における後続のアプリケーションへと前記イベントをディスパッチするステップと、を備えることを特徴とする方法。前記制御するステップは、前記受信したイベントを目標アプリケーションへディスパッチする前記ステップの前に前記イベントをラップするステップを更に含み、前記イベントは、前記処理するステップの前にアンラップされることを特徴とする請求項1に記載の方法。各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定する前記ステップは、前記イベントを検査して前記イベントを前記判定対象アプリケーションに適用可能であるか否かをチェックすることにより実行されることを特徴とする請求項1に記載の方法。各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定する前記ステップは、アプリケーションマネージャによって実行されることを特徴とする請求項1に記載の方法。前記アプリケーションフレームワークは、前記アプリケーションを構築するために、ドキュメントオブジェクトモデルDOMベースのモデルを使用するように構成されることを特徴とする請求項1に記載の方法。前記ITFは、セットトップボックス、移動体端末、またはPCであることを特徴とする請求項1に記載の方法。ディスプレイデバイス上へのウェブアプリケーションの表示を可能にするアプリケーションフレームワークを実装したIPTV端末であって、前記アプリケーションフレームワークは、階層ツリー構造の中に組織された2以上のアプリケーションを記憶するメモリと、前記階層ツリー構造の中の前記2以上のアプリケーションのうちの1つを目標とするイベントを受信するアプリケーションマネージャと、を含み、前記アプリケーションマネージャは、前記階層ツリー構造の中の第1のアプリケーションが前記目標のアプリケーションであるか否かを判定する制御器と、前記第1のアプリケーションが前記目標のアプリケーションでない場合に、前記階層ツリー構造の中の第2のアプリケーションへと前記イベントをディスパッチするディスパッチャと、を含むことを特徴とするIPTV端末。前記アプリケーションマネージャは、イベントをラップしてアンラップするイベントラッパを更に含むことを特徴とする請求項7に記載のIPTV端末。前記制御器は、前記イベントの前記目標のアプリケーションを示す情報を記憶することを特徴とする請求項7に記載のIPTV端末。前記アプリケーションフレームワークは、前記アプリケーションを組織するために、ドキュメントオブジェクトモデルDOMベースのモデルを使用することを特徴とする請求項7に記載のIPTV端末。前記IPTV端末は、セットトップボックス、移動体端末、またはパーソナルコンピュータの中に組み込まれることを特徴とする請求項7に記載のIPTV端末。本発明の実施形態について、本発明の実施形態を示す添付の図面を参照しながら、下文に、より詳細に記述しよう。しかし、本発明の実施形態は、多くの異なる形態で実施されてもよく、本明細書で述べた実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本開示が徹底的かつ完全であり、かつ、当業者に本発明の範囲を十分に伝えるようにするために提供されている。図中で、類似の番号は、類似の要素を指す。また、当業者であれば、本明細書で以下に説明する手段および機能は、プログラムされたマイクロプロセッサまたは汎用コンピュータと併せて機能するソフトウェアを用いて、および/または、特定用途向け集積回路ASICを用いて実装されうることを理解するであろう。また、理解されるであろうが、現行の実施形態は、主に方法およびデバイスの形で記述されているが、実施形態は、コンピュータプログラム製品として、および、コンピュータプロセッサおよびプロセッサに結合されたメモリを備えたシステムとして実施されてもよく、ここで、メモリは、本明細書に開示された機能を実行しうる1つ以上のプログラムを使ってコーディングされる。本発明の実施形態は、一般に、W3Cウィジェットとウェブアプリケーションとの両方に適用可能なアプリケーションフレームワークを定義する。さらに、本発明の実施形態は、将来の必要条件のために容易に拡張できるように企図されており、TV環境以外の環境にも用いることができるであろう。OIPFOpenIPTVForumDAEDeclarativeApplicationEnvironment仕様v.1.1仕様書は、アプリケーションマネージャと対応するアプリケーションモデルとの定義を含んでいる。また、DAEアプリケーションモデルにW3Cウィジェットのサポートを追加するための、OIPFにおける進行中の作業項目も存在する。本発明の実施形態は、部分的にはDAEアプリケーションモデルと整合する。しかし、主な違いは以下のようである。DAEにおけるアプリケーションマネージャは、アプリケーションのフラットリストを示すにすぎない。しかし、本発明の実施形態では、各アプリケーションは、階層ツリーモデルとして構成され、ツリーモデルが直接、アプリケーションに示される。これは、実施形態が、個々のユーザエージェントがすでにサポートしているDOMDocumentObjectModelモデルと整合していることを意味し、そして、強力であると共に既存のウェブ標準に適合しているアプリケーションのためにDOMベースのイベントモデルを用いることも可能にすることを意味する。DOMは、HTML、XHTML、およびXML文書の中のオブジェクトを表現し、かつ、それらと対話するための、プラットフォーム間共通かつ言語非依存の規約である。DOMの態様例えばElements要素は、用いられるプログラミング言語のシンタックスの範囲内で対応され、処理されてもよい。DOMのパブリックインタフェースは、そのApplicationProgrammingInterfaceAPIの中に規定される。用語および定義APIアプリケーションプログラミングインタフェースとは、人間とコンピュータとの対話をユーザインタフェースが円滑化するのと同じように、他のソフトウェアとの対話を可能にするためにソフトウェアプログラムによって実装されるインタフェースである。APIは、アプリケーション、ライブラリ、およびオペレーティングシステムによって実装され、プログラマがそれらのサービスを利用するために採用すべき語彙と呼び出し規約とを決めるものである。APIインタフェースの実装者と消費者との間で通信するために用いられるルーチン、データ構造、オブジェクトクラス、プロトコルについての仕様が含まれることもあり、それによって、ウェブアプリケーションは、プラットフォーム上に実装されていた固有の機能性に到達することができる。ウェブエンジンとは、ウェブアプリケーションがその中で実行される固有のコンポーネントである。ウェブブラウザは、ウェブエンジンの典型的な例である。アプリケーションフレームワークとは、ウェブアプリケーションおよびウィジェットを管理および表示するための全体的なクライアント側環境である。それゆえ、ウェブアプリケーションは典型的には、DOMベースのマークアップ形式と、ブラウザがサポートする言語、典型的にはSVGまたはHTML文書/ファイルおよびJavaScript登録商標コードとを組み合わせたものを含むと考えられる。さらに、ソフトウェアエンジニアリングにおいて、ウェブアプリケーションとは、インターネットやイントラネットのようなネットワーク経由でウェブブラウザを介してアクセスされるアプリケーションである。また、ウェブアプリケーションという用語は、ブラウザに制御された環境例えばJava登録商標アプレットの中でホストされるかまたは、ブラウザにサポートされた言語例えば、HTMLのようなブラウザがレンダリングするマークアップ言語と組み合わせたJavascriptでコーディングされ、アプリケーションを実行可能にするために共通のウェブブラウザに依存するコンピュータソフトウェアアプリケーションを意味することもある。ウィジェットは、W3CWidgetsFamilyofSpecificationsの中に定義されている。基本的に、ウィジェットは、ダウンロードされうる、かつ、クライアント側にローカルに記憶されうる、定義されたパッケージングスキームを伴うウェブアプリケーションであると考えることができる。従って、ウィジェットは、オンラインでの実行とオフラインでの実行とのいずれにも適している。本記述の範囲において、ウィジェットの定義は、ウィジェットはウェブアプリケーションの特殊形態であり、すなわち、ウィジェットはW3C定義のウィジェットの動作と併せてウェブアプリケーションのすべての属性を有するということを述べるように拡張される。しかし、ウィジェットは、アプリケーションのフレームワークの中にロードされることなくデバイスにインストールされローカルに記憶されてもよいのに対して、アプリケーションは、リモート位置からフレームワークの中に直接ロードされるローカルにアプリケーションを記憶することはできない。留意すべきことだが、ウィジェットは、その属性を考えれば、UAユーザエージェントの中へのローカルな記憶インストールに適してはいるが、ウィジェットがインストールされなければならないという必要条件は存在しない。ユーザエージェントは、例えばウィジェットをローカルに記憶することを防止する、記憶の制限を有していてもよいが、それでもやはり、ウィジェットの実行を可能にしてもよい。その意味では、ウィジェットは、ウェブアプリケーションとまったく同じようにふるまうであろうが、それでもやはり、ウィジェット固有の属性を条件とするであろう。本明細書の文脈では、アプリケーションは、アプリケーションマネージャによって管理されるウェブアプリケーションまたはウィジェットであると考えられ、そして、本明細書で定義されるインタフェースまたはメカニズムに従う。留意されるべきだが、本明細書は、ウェブアプリケーション例えば基本的なHTMLページまたはウィジェットが、ウェブアプリケーションの/ウィジェットのマークアップまたはjavascriptコードをまったく修正することなくアプリケーションとして機能できるように書かれている。それゆえ、本明細書全体を通じて、アプリケーションという用語が、ウェブアプリケーションとウィジェットとの両方について用いられる。ウィジェットという用語は、議論されるのが特にアプリケーションのウィジェット特殊形態である場合に限って用いられる。アプリケーションマネージャとは、アプリケーションのレイアウトと管理とを制御するためのメカニズムである。アプリケーションマネージャは、プラットフォームプロバイダによって制御される。ユーザエージェントUAとは、本明細書によって適用可能な範囲で、ウィジェットユーザエージェントと呼ばれることもある実装である。IPTVセグメントにおけるユーザエージェントは、しばしば、ITFIPTVTerminatingFunctionsとも呼ばれるが、本明細書全体を通じて、より一般的な用語であるUAが用いられる。以下に、本発明の実施形態によるさまざまなステークホルダが定義され、ステークホルダ制御のためのモデルが定義される。ステークホルダ制御のためのモデルを図1に示す。プラットフォームステークホルダとは、プラットフォームのプロバイダであり、典型的には、STBまたはTV機器のプロバイダである。プラットフォームステークホルダは、プラットフォームの固有のユーザ体験UXとアプリケーションのレイアウトとを整合させるためにアプリケーションを制御することに関心がある。一例として、或るTV機器プロバイダXが、特定の時刻点において実行されているかもしれないサービスに依存せずに、TVの固有のルックフィールと整合するメニューの中に利用可能なウィジェットを表示することを望んでもよい。サービスステークホルダとは、サービスのプロバイダであり、典型的にはTVサービスを加入者に提供するオペレータである。オペレータは、サービスについての自分自身のUXUserExperienceを提供することと、固有のUXをできる限り隠すことに関心がある。これには、サービスUXの統合された部分としてアプリケーション制御を提供する能力が含まれる。例えば、TVサービスプロバイダYが、サービスプロバイダのポータルの中に統合されているメニューの中に、利用可能なウィジェットを表示することを望んでもよい。アプリケーションステークホルダとは、特定のアプリケーションのプロバイダである。アプリケーションステークホルダは、例えば、このアプリケーションプロバイダからのアプリケーションのリストを表示するために、自分自身から他のアプリケーションを制御することに関心を持つ可能性がある。定義された各ステークホルダは、以下のように、すなわち、プラットフォームステークホルダ、サービスステークホルダ、アプリケーションステークホルダの順で優先度を高い方から低い方へと付与される。最高の優先度が決定を行い、すなわち、プラットフォームステークホルダが、すべてのアプリケーションはプラットフォームによって制御されるUIユーザインタフェースを通じて制御されなければならないと決定した場合、サービスステークホルダもしくはアプリケーションステークホルダは、この決定より優位に立つことはできない。ステークホルダの優先度を制御する基本的なメカニズムは、アプリケーションマネージャと、それが制御するアプリケーションモデルとを通して行われる。各ステークホルダはアプリケーションマネージャを制御し、次には、アプリケーションマネージャが、アプリケーション属性の修正と、その他のアプリケーションの追加/呼び出しとに関するアプリケーションからのすべての要求を制御する。ここで、プラットフォームステークホルダは、アプリケーションマネージャを制御するのだから、他のステークホルダの力を制限する機会を有する。さらに、アプリケーションモデルは、ツリー構造を有しており、ルートノードはプラットフォームが制御するノードであり、ここではプラットフォームステークホルダが、例えば所定のイベントがモデルを通過するのを中止させることによって、他のステークホルダの制御を制限するための論理ロジックを加えることがある。同様に、ルートノードの下のノードは、典型的にはサービスステークホルダによって制御され、それゆえ、アプリケーションステークホルダの制御を制限するための同様の論理ロジックを含むことがある。アプリケーションマネージャによって制御されるアプリケーションモデルは、すべてのノードがアプリケーションであるような通常のDOMツリーモデルであってもよい。この場合、各アプリケーションは、アプリケーションモデルが通過されたり、アプリケーションが追加および削除されたりすることを可能にする、DOM3DOMLevel3CoreElement、ElementTraversalおよびNodeインタフェースの部分集合サブセットを継承する。ツリーの中のルートノードは、アプリケーションマネージャによって制御される、隠されたシステムノードである。それを削除したり修正したりすることはできず、すべてのアプリケーションは、隠されたノードに対する子ノードとして追加される。ルートノードは、例えば、内蔵の、固有の、ウィジェットバーであってもよいだろう。あるいは、例えばTVの電源を切るような、所定の機能性がすべてのウィジェットによって使用されるのを防ぐために所定のイベントがモデルの中に入っていくのを中止させるような、単なる見えないアプリケーションであってもよいだろう。図3は、単一のファイル/文書がアプリケーションマネージャの中にロードされる場合のアプリケーションモデルを示しており、例えば単純なSVGファイルのように、単一のウェブアプリケーションがUAによって表示される場合、モデルは図3に示すように見えるであろう。アプリケーションフレームワークの中の各アプリケーションは、ルートアプリケーションを除いて、関連のDocument文書オブジェクトを有する。文書は、特定のアプリケーションのDOMを表しており、モデルの中のいかなる他のアプリケーションにも非依存であり、すなわち、各アプリケーションは、別個のスクリプトコンテクストの中で実行される別個のDOMを有する。もっと大きいアプリケーションツリーの例を図4に示しており、図4は右側に、複数のアプリケーションがアプリケーションマネージャの中にロードされた場合のアプリケーションモデルを示す。左側の図は、各アプリケーションが画面上にどのように表示されうるかを示す。子ノードは、親ノードの属性を継承することができる。例えば、親が削除されたら、子は削除されるが、例えば透明度のようなその他の属性は、来たるべきバージョンのために考慮されてもよいだろう。或るアプリケーションが半透明であることになっているとユーザが言えるのであれば、子アプリケーションも半透明であるはずであろう。本発明の実施形態によるアプリケーションマネージャは、DOM2イベントモデルに基づくイベントモデルを用いてもよい。特定の時刻点における入力イベントキーイベント、マウスイベント等の目標は、DOMツリーの中のただ1つのノードである。これは、例えばキー入力のようなイベントは、目標アプリケーションに行くであろうが、それをする前に、最前面から目標アプリケーションまで、目標ノードのすべての親祖先のそばを通るであろうということを意味する。これを、キャプチャフェーズと呼ぶ。本発明の実施形態によると、通過する個々のノードは、イベントをキャプチャする、すなわち止めてもよい。イベントが目標アプリケーションに到達したら、その後、目標アプリケーションは、イベントをキャプチャ、すなわち止めることもできるし、同じ各ノードのそばを再び遡って通過させることもでき、それをバブルフェーズと呼ぶ。キャプチャおよびバブルフェーズは、DOMイベントモデルの一部である。イベントの目標が常に、現時点でのフォーカスされているアプリケーションであるような先行技術のソリューションとは対照的に、本発明の実施形態は、どのアプリケーションが現時点でのフォーカスされているアプリケーションであるかに依存せず、目標アプリケーションが、いかなるアプリケーションであってもよいようなモデルを導入する。しかし、DOM2のキャプチャフェーズもバブルフェーズもいずれも、本発明の実施形態によってサポートされる。DOM2イベントモデルによると、イベントは、ルートからスタートして、キャプチャフェーズの間に、目標アプリケーションに向かってツリーを通過する。本発明の実施形態に従って階層モデルを用いることにより、通過する個々のアプリケーションは、アプリケーションがフォーカスされているアプリケーションであるかどうかに依存せず、アプリケーションが目標アプリケーションであるならばイベントをキャプチャしてもよい。イベントが目標アプリケーションに到達すると、イベントは目標アプリケーションによって処理される。目標アプリケーションがイベントをキャプチャしない場合、イベントは、再び、ツリーを上方へルートまで通過するのだが、そのことをバブルフェーズと言う。通過する個々のアプリケーションは、その後のバブリングが行われないように、イベントを止めてすなわちキャプチャしてもよい。図5は、イベントが、イベント目標と呼ばれる目標アプリケーションに向かって通過する場合のDOM2キャプチャフェーズ/バブルフェーズを示す図である。どのアプリケーションがフォーカスされているアプリケーションであるかに依存せず、いかなるアプリケーションであっても目標アプリケーションであることを可能にするために、階層アプリケーションモデルは、イベントラッパと組み合わせられる。アプリケーションマネージャは、イベントラッパを備えており、イベントラッパは、目標アプリケーションへ向かって通過すべきイベントをラップするように構成される。それゆえ、ラップされたイベントは、アプリケーションのツリーを通って通過する。個々のアプリケーションは、自分がイベントを処理すべきかどうかをチェックするために、ラップされたイベントを検査するように構成される。判定対象アプリケーションが自分は目標アプリケーションであると判定した場合、アプリケーションマネージャは、イベントをアンラップし、そのアプリケーションは、アンラップされたイベントを受信して、アンラップされたイベントを通常のイベントとして処理する。判定対象アプリケーションが自分は目標アプリケーションではないと判定した場合、アプリケーションマネージャは、ラップされたイベントをツリーの中のそれに続くアプリケーションにディスパッチする。図2は、本発明の一実施形態によるアプリケーションフレームワーク203を示す。アプリケーションフレームワーク203は、アプリケーションマネージャ200と、階層順に配列された各アプリケーション202を記憶するメモリ204と、を備えている。さらに、アプリケーションマネージャ200は、イベントを受信するように構成された受信器205と、ディスパッチを制御するように構成された制御器207とを備えている。制御器207は、ディスパッチャ206によるディスパッチを制御し、また、イベントラッパ201を備えている。アプリケーションマネージャは各アプリケーション202を制御するのだから、アプリケーションマネージャ200は、ラップされたイベントを自分がアンラップすべきかどうか、あるいは、自分はラップされたイベントをそれに続くアプリケーションにディスパッチすべきかどうかを知っている。目標アプリケーションの祖先であるすべてのアプリケーションは、eventWrapperイベントをリッスン待ち受けするためのイベントリスナーをアプリケーションの文書ノード上に追加することによって、イベントをリッスンするように登録することができる。従って、いかなるウェブアプリケーションであってもイベントを受信するためには、そのイベントのためのリスナーを登録しなければならない。ユーザがアプリケーション上でマウスをクリックしても、アプリケーションがマウスイベントリスナーを登録していなかった場合には、何も起こらないであろう。同じことは、eventWrapperイベントにも当てはまる。eventWrapperイベントは、イベントラッパ201によって行われる、アプリケーションツリーを通り抜けるときの実際のイベントをラップする特別なイベントである。eventWrapperイベントが目標アプリケーションに到達した時、すなわち、イベントがアンラップされた時、ラップされていたイベントは、単一文書の環境ではそうであったはずであるように、目標アプリケーションに関連する文書上でディスパッチされる。アンラップされたイベントは、文書によって通常のやり方で処理される。文書から抜ける場合、キャプチャされないならば、イベントは、再びeventWrapperイベントの中にラップされて、アプリケーションツリーをバブルアップし始める。イベントラッピングについて、以下の例によって例示する。1.アプリケーションマネージャ200は、システムによって受信器205を介してイベント例えばキー1を受信する。イベントは、フレームワーク203の中のメモリ204に記憶されているアプリケーション202の1つを目標とする。2.アプリケーションマネージャ200のイベントラッパ201が、eventWrapperイベントewを作成してイベントをラップする。3.アプリケーションマネージャ200が、ラップされたイベントを、目標アプリケーションへ向かってモデルツリーの下方へ通過させる。ラップされたイベントは、ラップされたイベントが検査対象アプリケーションに適用可能かどうかチェックするために、それが通過する個々のアプリケーション202によって検査される。ラップされたイベントが検査対象アプリケーションに適用可能である場合、それは、検査対象アプリケーションが目標アプリケーションであることを意味するであろう。4.ラップされたイベントが目標アプリケーションに到達した時、アプリケーションマネージャ200は、イベントをアンラップし、アンラップされたイベントを目標アプリケーションにディスパッチする。5.イベントが目標アプリケーションによってキャプチャされない場合、アプリケーションマネージャは、イベントをイベントラッパに戻し入れ、そして、実際のイベントを含むラップされたイベントを、モデルの上方へバブルさせる。これは、他のアプリケーションがイベントを処理するかどうかをそのアプリケーションが気にしない場合に適用可能である。それゆえ、他のアプリケーションがイベントを用いるかどうかをそのアプリケーションが気にしないならば、そのアプリケーションはイベントをキャプチャすべきでない。以下では、この動作をさらに、図6と併せて例示する。同報されるTVチャネルを表示するTVアプリケーション601を考えよう。天気ウィジェット602が、TVアプリケーション601の最前面に表示され、天気ウィジェット602がフォーカスを持つ。天気ウィジェットがフォーカスを持っている場合、天気ウィジェットは、多様な日についての予報の間をナビゲートするのに用いられる左/右のキー操作をリッスンする。たとえ天気ウィジェットがフォーカスを持っていても、TVアプリケーションは、通常のキーの上/下を使ってユーザがチャネルを変えることを可能にしたいであろう。各アプリケーションは本発明の実施形態による階層モデルとして構成されているのだから、フォーカスされているアプリケーション以外のアプリケーションは、イベントを処理することができる。この場合、天気ウィジェットは、TVアプリケーションによって追加されたものであり、TVアプリケーションの子である。それゆえ、TVアプリケーションは、天気ウィジェットの親であり、天気ウィジェットまで下がる途中のキャプチャフェーズの間、すべてのイベントは、TVアプリケーションのそばを通過するであろう。従って、TVアプリケーションは、イベントがキーの押し上げまたは押し下げ操作であるかどうかをチェックするであろう。そうである場合には、TVアプリケーションは、イベントを処理するであろうし、そうでない場合は、アプリケーションマネージャは、イベントをさらに天気ウィジェットへとディスパッチするであろう。上記で説明したように、アプリケーションマネージャは、イベントをラップし、階層ツリーモデルを通してイベントをディスパッチする。ラップされたイベントは、目標アプリケーションの情報を含んでいる。ラップされたイベントが通過する個々のアプリケーションでは、判定対象アプリケーションが、イベントがそのアプリケーションによって処理されるべきかどうかを判定するために、ラップされたイベントを検査する。判定対象アプリケーションがイベントを処理すべき場合、それはそのアプリケーションが目標アプリケーションであることを意味するのだが、アプリケーションマネージャは通知されてイベントをアンラップし、その結果、アプリケーションがイベントを通常のイベントとして処理できる。アプリケーションでは、アプリケーションがどのようにしてイベントを処理すべきかが定義される。これを以下にコードの例によって例示する。TVアプリケーション天気アプリケーション上記のように、例えばキーイベントのような入力イベントがUAの中で行われた場合、アプリケーションマネージャのイベントラッパは、eventWrapperイベントによってイベントをラップし、図7aおよび図7bに示すように、それをアプリケーションツリーの下方へ送信する。図7a乃至図7cに示す例では、第1のストップは、図7aに示すようにアプリケーションツリーの隠されたルートノードである。ここでは、プラットフォームステークホルダが、もしそう望むなら、特定のイベントを処理してキャプチャする機会を有する。例えば、特定のキーが、固有のプラットフォームメニューに常に関連付けられてもよく、それ以外のものについては決して用いられてはならないというのでもよい。このキーは、ルートノードの中でキャプチャされるであろう。ルートノードから、ラップされたイベントは、図7bに示すようにアプリケーションマネージャによって制御されながら、目標へ向かってツリーを下方へ移動する。次のストップは、TVアプリケーションノードである。ここでTVアプリケーションは、上記のコード例に従ってキーイベントを検査し、イベントがチャネル変更イベントに関する場合、イベントを止める。代わりに、イベントが天気ウィジェットの管理に関する場合、TVアプリケーションは、ラップされたイベントを通過させるであろう。その次のストップは、図7cに示すように、実際のイベントの目標である天気アプリケーションである。目標アプリケーションでは、アプリケーションマネージャが、イベントをアンラップすることによってラッピングイベントを削除し、適用可能なアプリケーション文書上でキーイベントをディスパッチする。上記のコードの例によると、天気アプリケーションは、左/右のキーの場合には、イベントを処理し、止めるであろう。その他の場合にはすべて、イベントは、止められないであろう。イベントが止められない場合、アプリケーションマネージャは、eventWrapperイベントの中のイベントをアンラップして、それをツリーを通して上方へバブルさせ、キャプチャ/バブルフェーズを完了させる。留意すべきことだが、この最後のステップは、右側の絵には示されていない。本発明の第1の実施形態によると、図8に示すように、アプリケーションの表示を可能にするAPIに関連付けられたアプリケーションフレームワーク203を備えたITFIPTVTerminalFunction210例えばSTBset-top-boxのようなもののために構成されたウェブエンジンが提供される。アプリケーションフレームワーク203は、少なくとも2つのアプリケーション202を記憶するためのメモリ204を備えており、ここで各アプリケーション202は、相互に関係する階層ツリー構造の中に配置されていて、少なくとも2つのアプリケーションのうちの1つは、フォーカスされているアプリケーションであってもよい。アプリケーションフレームワーク203は、さらに、例えばキー操作のようなイベントを受信するための受信ユニット205と、ディスパッチを制御するための制御器206とを備えたアプリケーションマネージャ200を備えている。一実施形態によると、制御器206は、イベントをラップおよびアンラップするためのイベントラッパ201と、ラップされたイベントをアプリケーションツリーを通して下方へ転送するためのディスパッチャ207とを含んでいる。個々のアプリケーションノードおよびルートノードについては、アプリケーションマネージャ200は、判定対象アプリケーションによってイベントが処理されるべきかどうかを制御器206を用いて判定するように構成されている。それゆえ、アプリケーションマネージャ200の制御器206は、イベントのディスパッチを制御する。一実施形態によると、アプリケーションマネージャ200のイベントラッパ201がイベントをラップし、ディスパッチャ207が、ラップされたイベントを目標アプリケーションにディスパッチする。個々のアプリケーションについて、ラップされたイベントが判定対象アプリケーションによって処理されるべきかどうかに関してラップされたイベントを検査するように、判定対象アプリケーションが構成されてもよい。あるいは、アプリケーションマネージャが、そのイベントについての目標アプリケーションであるアプリケーションの情報をメモリ212の中に記憶するように構成されてもよい。ラップされたイベントが判定対象アプリケーションによって処理されるべき場合、アプリケーションマネージャ200のイベントラッパ201は、イベントが判定対象アプリケーションによって通常のイベントとして処理されうるように、判定対象アプリケーションのためにイベントをアンラップする。イベントが判定対象アプリケーションによって処理されるべきでない場合、アプリケーションマネージャ200は、ラップされたイベントをそれに続くアプリケーションにディスパッチする。ITF210は、各アプリケーション202を、サーバ250から、およびAPI208を用いることによって、取得することができる。アプリケーションは、図9に示すように画面260上に表示されてもよい。また、留意されるべきことだが、典型的なウェブエンジンは、他のコンポーネント、例えばHTMLHyperTextMarkupLanguageモデルおよびXMLeXtensibleMarkupLanguageパーサを含んでいるが、それは本発明の範囲内のものではない。アプリケーションマネージャは、アプリケーションマネージャの機能を実行するためのソフトウェアおよび/またはハードウェア部分を備えた1つ以上のプロセッサと、受信器205と、制御器206と、ディスパッチャ207と、イベントラッパ201とによって実装されてもよい。本発明の第2の実施形態によると、ウェブエンジンにおける方法が、図10に示すように提供される。ウェブエンジンは、各アプリケーションの表示を可能にするAPIに関連付けられたアプリケーションフレームワークを備えたITFのために構成される。方法は、少なくとも2つのアプリケーションを記憶すること1000と、ここで各アプリケーションは相互に関係する階層ツリー構造の中に配置されていて、少なくとも2つのアプリケーションのうちの1つはフォーカスされているアプリケーションであり、そして、イベントを受信すること1001と、フォーカスされているアプリケーションではない各アプリケーションがイベントを受信して処理することができるように、少なくとも1つのアプリケーションを目標とするイベントのディスパッチを制御すること1002とを含んでいる。イベントのディスパッチは、アプリケーションマネージャを用いて制御され、ここでアプリケーションマネージャは、イベントをラップおよびアンラップするイベントラッパを備えていてもよい。方法は、さらに、本発明の一実施形態による、イベントをラップするステップ1003と、ラップされたイベントを目標アプリケーションにディスパッチするステップ1004とを含んでいる。個々のアプリケーションについて、判定対象アプリケーションが目標アプリケーションかどうか判定される。これは、ラップされたイベントを検査するように各アプリケーションを構成するかまたは、或るイベントについてどのアプリケーションが目標アプリケーションであるかという情報をアプリケーションマネージャにメモリ212の中に記憶させることによって行うことができる。判定対象アプリケーションが目標アプリケーションであり、従って、ラップされたイベントがそのアプリケーションによって処理されるべきである場合1005、方法は、判定対象アプリケーションによってイベントが通常のイベントとして処理されうるようにそのアプリケーションについてイベントをアンラップすること1006を含んでいる。イベントが判定対象アプリケーションによって処理されるべきでない場合、アプリケーションマネージャは、ラップされたイベントをそれに続くアプリケーションにディスパッチする1007。本発明の階層アプリケーションモデルによって、新たなアプリケーションが含まれることが可能になる。新たなアプリケーションを含むことは、以下のステップによって達成されうる。1.ユーザが、loadApplication、またはウィジェット用のinstallWidgetloadApplicationを呼び出すことによって、新たなアプリケーションを要求する。2.要求が、アプリケーションマネージャ200のAPIによって取り扱われる。3.要求が、サービスプロバイダまたは別のコンテンツプロバイダによって管理されるサーバ250に送信される。4.サーバが、通常のHTTPGETを用いてアプリケーションをウェブエンジン209に送信することによって、要求に応答する。サーバ250がアプリケーションを提供できない場合、何も取得されないであろう。5.アプリケーションマネージャ200が、新たなアプリケーションをツリー構造に含める。新たなアプリケーションがツリーに追加された場合、それが自動的に表示される。本発明の実施形態は、上記の好適実施形態に限定されない。各種の代替形態、修正形態、および均等形態が用いられうる。従って、上記の実施形態は、本発明の範囲を限定しているとみなされるべきではなく、本発明の範囲は、添付の請求項によって定義される。本発明は、もちろん、本発明の範囲および必須の特性から逸脱することなく本明細書に記述したもの以外の特定のやり方で実行されうる。従って、本発明は、あらゆる点で例示的であるとみなされるべきであって、制限的であるとみなされるべきではなく、添付の請求項の意味と均等範囲とに入るすべての変更は、本発明に包含されることが意図される。