JP2013524360A - Ｉｐｔｖ端末における方法および装置 - Google Patents

Abstract

本発明は、方法およびウェブエンジンに関する。本発明の第１の態様によって、アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワークを備えたＩＴＦ（ＩＰＴＶ Ｔｅｒｍｉｎａｌ Ｆｕｎｃｔｉｏｎ）（例えば、ＳＴＢ（ｓｅｔ−ｔｏｐ−ｂｏｘ））のために構成されたウェブエンジンが提供される。アプリケーションフレームワークは、少なくとも２つのアプリケーションを記憶するためのメモリを備えており、ここで、各アプリケーションは、相互に関係する階層ツリー構造の中に配置される。アプリケーションフレームワークは、さらに、イベント（例えばキー操作）を受信するための受信ユニットと、ディスパッチを制御するための制御器とを備えたアプリケーションマネージャを備えている。制御器は、イベントをラップおよびアンラップするためのイベントラッパと、ラップされたイベントをアプリケーションツリーを通して下方へ転送するためのディスパッチャとを備えていてもよい。個々のアプリケーションノード（さらにはルートノード）について、アプリケーションマネージャは、イベントが判定対象アプリケーションによって処理されるべきかどうかを判定するように構成される。

Description

関連出願
本願は、２０１０年４月９日に出願された米国仮特許出願第６１／３２２，４４４号の利益を請求するものであり、それを参照により本願に援用する。

技術分野
本発明の実施形態は、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）端末におけるイベント管理に関し、詳細には、ＩＰＴＶデバイスの中で利用可能なアプリケーションによるイベント処理に関する。

ＩＰＴＶプロバイダが拡張ソリューションを提供することへの需要が高まっているが、この場合、エンドユーザは、限られた機能の集合に限定されるのではなく、従来のＴＶサービスと併せて新しいアプリケーションをダウンロードして実行することができる。

ＩＰＴＶソリューションで用いられるウェブアプリケーションの場合、主な既存の技術は、Ｗ３Ｃウィジェットであり、これは、ウィジェットとしても知られるウェブアプリケーションについてのパッケージ化および配信方法、ならびにウィジェットに署名するメカニズムを定義するものである。

アプリケーションフレームワークは、クライアント側で実行され、ウィジェットのロード、管理、およびレイアウトを担う。Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）のウィジェット仕様は、ウィジェットが実行されるアプリケーションフレームワーク／ウィジェットフレームワークを定義していない。代わりに、多様な市場部分（マーケットセグメント）が、自らの特定の部分（セグメント）に適した、ウィジェット実行のための自分自身のアプリケーションマネージャを定義してきた。

従来のアプリケーションモデルでは、ディスプレイスタックの最前面にあるアプリケーションが、フォーカスされているアプリケーションであり、ユーザからの入力イベントを受信する。これは、例えば、ウィンドウズ（登録商標）によるＰＣ上で見ることができ、各アプリケーション（プログラム）は、ＰＣのデスクトップ上の長方形のエリアの中でユーザに対して表示される。最前面に表示されるアプリケーションは、フォーカスされているアプリケーションであり、それゆえ、例えばキーイベントおよびマウスイベントのようなすべての入力イベントを受信する。

ＩＰＴＶに適したアプリケーションモデルでは、必要条件は若干異なる。各アプリケーションは、同様のやり方でレイアウトされることが想定されるが、最前面にあるアプリケーションが常にすべての入力イベントを受信することは望まれていない。例えば、同報されるＴＶチャネルをＴＶの画面全体に表示するようなアプリケーションを考えてみよう。このアプリケーションの最前面には、天気ウィジェットが画面の小さなエリアに表示される。天気ウィジェットは、フォーカスされている場合は左／右のキー操作に対して反応するが、たとえフォーカスされている場合であっても、その基礎となる同報アプリケーションは、上／下のキーがチャネルザッピングのために用いられ、かつ、ユーザはチャネルザッピングが常に機能することを望むのだから、上／下のキー操作に反応することができなければならない。

従って、ＩＰＴＶソリューションに適したイベントインターセプションを達成することが望ましく、それは、フォーカスされているアプリケーション以外のアプリケーションがイベントをインターセプトできることを意味する。

ＩＰＴＶソリューションに適したイベントインターセプションを達成するため、本発明の諸実施形態は、フォーカスされているアプリケーション以外のアプリケーションがイベントをインターセプトできるようにする概念を導入する。

イベントインターセプションは、本発明の実施形態によるイベントラッピングによって達成される。アプリケーションフレームワークは、ＤＯＭベースのモデルを用いてフレームワーク内ですべてのアプリケーションを構築してもよい。このＤＯＭベースのモデルは、ＤＯＭイベントベースのモデルを用いて、イベントモデル全体にわたってイベントを処理する。ＩＰＴＶソリューションでは、特定のイベント、例えばキー操作イベントは、フォーカスされているアプリケーションでないこともありうる特定のアプリケーションを常に目標にするのだから、特定のイベントは、目標となる特定のアプリケーションによって認識されることができなければならないが、それでもやはり、通常のイベントとして処理されることができなければならない。これを達成するため、本発明の実施形態によるイベントラッピングが導入される。特定のアプリケーションを目標とするイベントが、アプリケーションモデルの中で行われる場合、アプリケーションマネージャが、ｅｖｅｎｔＷｒａｐｐｅｒ構造の中にイベントをラッピングした上で、イベントモデルを通してそれをディスパッチする。それが目標となる特定のアプリケーションに到達すると、アンラップされ、元のイベントが、以下に説明するように目標にディスパッチされる。

特定のアプリケーションは、前記特定のアプリケーションに向けられたイベントを認識し、従って、認識されたイベントは、先行技術の場合のようにフォーカスされているアプリケーションへと進むべきではない。

イベントラッピングを導入することによって、ＤＯＭイベントモデルが、マルチドキュメント（すなわちマルチアプリケーション）シナリオにおいて動作するように拡張される。これは、ＤＯＭイベントからの共通の手順がすべて、マルチアプリケーション環境でも有益となることを意味する。これらの手順は、機能の観点から（アプリケーションが、どのタイプのイベントをそれらの子アプリケーションが処理できるかを制御する能力、複数のアプリケーションがイベントを共有する能力等）だけでなく、実装の観点からも（ウェブテクノロジのユーザエージェント、例えばブラウザは、ＤＯＭイベントについてのサポートをすでに含んでいるので、アプリケーションフレームワークをサポートする場合にこれを再利用することができる）、アプリケーション環境にとって非常に有益である。

従って、本発明の実施形態に関する目的は、たとえアプリケーションがフォーカスされているアプリケーションでない場合であっても、イベントがアプリケーションによって処理されることを可能にすることである。

これは、第１の態様によって、アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワークを備えたＩＴＦのために構成されたウェブエンジンにおける方法によって達成される。方法では、少なくとも２つのアプリケーションが記憶され、ここで、各アプリケーションは、相互に関係する階層ツリー構造の中に配置される。目標アプリケーションと呼ばれることもある少なくとも１つのアプリケーションを目標とするイベントが、受信される。方法は、さらに、少なくとも１つのアプリケーションを目標とする受信されたイベントのディスパッチの制御を含んでいる。これは、フォーカスされているアプリケーションではないアプリケーションがイベントを受信して処理することができることを意味する。制御することは、さらに、受信されたイベントを目標アプリケーションにディスパッチすることと、個々のアプリケーションについて、イベントが判定対象アプリケーションによって処理されるべきかどうかを判定することとを含んでおり、処理されるべき場合には、方法は、判定対象アプリケーションのためにイベントを処理することを含み、処理されるべきでない場合には、方法は、イベントを階層ツリー構造における後続のアプリケーションにディスパッチすることを含む。

一実施形態によると、制御することは、さらに、ディスパッチする前にイベントをラップすることを含み、次いでイベントは、処理の前にアンラップされる。

本発明の一実施形態によると、個々のアプリケーションについてラップされたイベントが判定対象アプリケーションによって処理されるべきかどうかを判定することは、ラップされたイベントを検査して、イベントが判定対象アプリケーションに適用可能かどうかをチェックすることによって行われる。あるいは、判定することは、アプリケーションマネージャによって行われる。

実施形態の目的は、さらに、第２の態様によって、アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワークを備えたＩＴＦのために構成されたウェブエンジンによって達成される。アプリケーションフレームワークは、少なくとも２つのアプリケーションを記憶するためのメモリを備えており、ここで、各アプリケーションは、相互に関係する階層ツリー構造の中に配置される。アプリケーションマネージャは、その少なくとも１つのアプリケーションを目標とするイベントを受信するための受信器と、その少なくとも１つのアプリケーションを目標とするイベントのディスパッチを制御するための制御器とを備えている。アプリケーションマネージャはさらに、受信されたイベントを目標アプリケーションに向けてディスパッチするためのディスパッチャを備えており、制御器はさらに、個々のアプリケーションについて、受信されたイベントは判定対象アプリケーションによって処理されるべきかどうかを判定するように構成されている。

本発明の一実施形態によると、制御器は、受信されたイベントをラップおよびアンラップするためのイベントラッパを備えている。

別の実施形態によると、制御器はさらに、イベントを検査して、イベントが判定対象アプリケーションによって処理されるべきかどうか判定するためにイベントが判定対象アプリケーションに適用可能かどうかをチェックするように構成される。あるいは、アプリケーションマネージャはさらに、どのアプリケーションがイベントについての目標アプリケーションなのかについての情報を記憶するように構成される。

さらに、一実施形態によると、アプリケーションフレームワークは、Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（ＤＯＭ）ベースのモデルを用いて、アプリケーションを構築するように構成され、そしてＩＴＦは、セットトップボックスと移動体端末とＰＣとのうちのいずれであってもよい。

本発明の諸実施形態の利点は、それによって、既存のアプリケーションフレームワークにおいて利用可能なものより、アプリケーション間の共存における柔軟性が高まることである。この柔軟性は、ＩＰＴＶアプリケーション環境において極めて重要である。

本発明の実施形態によるアプリケーションモデルとステークホルダの優先度の一例を示す図である。 本発明の実施形態によるアプリケーションフレームワークを示す図である。 本発明の実施形態によるアプリケーションマネージャの中に単一のファイル／文書がロードされた場合のアプリケーションモデルを示す図である。 本発明の実施形態による、複数のアプリケーションがアプリケーションマネージャの中にロードされた場合のアプリケーションモデルを右側に示し、アプリケーションモデルの見込まれる視覚化を左側に示す。 本発明の実施形態によるアプリケーションモデルにおけるＤＯＭキャプチャ、バブルフェーズを示す図である。 同報されたＴＶチャネルを表示するＴＶアプリケーションを示す図である。 本発明の実施形態によるイベントラッピングを示す図である。 本発明の実施形態によるイベントラッピングを示す図である。 本発明の実施形態によるイベントラッピングを示す図である。 本発明の実施形態による構成を示す図である。 本発明の実施形態による構成を示す図である。 本発明の一実施形態のフローチャートである。

本発明の実施形態について、本発明の実施形態を示す添付の図面を参照しながら、下文に、より詳細に記述しよう。しかし、本発明の実施形態は、多くの異なる形態で実施されてもよく、本明細書で述べた実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本開示が徹底的かつ完全であり、かつ、当業者に本発明の範囲を十分に伝えるようにするために提供されている。図中で、類似の番号は、類似の要素を指す。

また、当業者であれば、本明細書で以下に説明する手段および機能は、プログラムされたマイクロプロセッサまたは汎用コンピュータと併せて機能するソフトウェアを用いて、および／または、特定用途向け集積回路（ＡＳＩＣ）を用いて実装されうることを理解するであろう。また、理解されるであろうが、現行の実施形態は、主に方法およびデバイスの形で記述されているが、実施形態は、コンピュータプログラム製品として、および、コンピュータプロセッサおよびプロセッサに結合されたメモリを備えたシステムとして実施されてもよく、ここで、メモリは、本明細書に開示された機能を実行しうる１つ以上のプログラムを使ってコーディングされる。

本発明の実施形態は、一般に、Ｗ３Ｃウィジェットとウェブアプリケーションとの両方に適用可能なアプリケーションフレームワークを定義する。さらに、本発明の実施形態は、将来の必要条件のために容易に拡張できるように企図されており、ＴＶ環境以外の環境にも用いることができるであろう。

ＯＩＰＦ（Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ） ＤＡＥ（Ｄｅｃｌａｒａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）仕様ｖ．１．１仕様書は、アプリケーションマネージャと対応するアプリケーションモデルとの定義を含んでいる。また、ＤＡＥアプリケーションモデルにＷ３Ｃウィジェットのサポートを追加するための、ＯＩＰＦにおける進行中の作業項目も存在する。本発明の実施形態は、部分的にはＤＡＥアプリケーションモデルと整合する。しかし、主な違いは以下のようである。

ＤＡＥにおけるアプリケーションマネージャは、アプリケーションのフラットリストを示すにすぎない。しかし、本発明の実施形態では、各アプリケーションは、階層ツリーモデルとして構成され、ツリーモデルが直接、アプリケーションに示される。これは、実施形態が、個々のユーザエージェントがすでにサポートしているＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）モデルと整合していることを意味し、そして、強力であると共に既存のウェブ標準に適合しているアプリケーションのためにＤＯＭベースのイベントモデルを用いることも可能にすることを意味する。ＤＯＭは、ＨＴＭＬ、ＸＨＴＭＬ、およびＸＭＬ文書の中のオブジェクトを表現し、かつ、それらと対話するための、プラットフォーム間共通かつ言語非依存の規約である。ＤＯＭの態様（例えば「Ｅｌｅｍｅｎｔｓ（要素）」）は、用いられるプログラミング言語のシンタックスの範囲内で対応され、処理されてもよい。ＤＯＭのパブリックインタフェースは、そのＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）の中に規定される。

用語および定義
ＡＰＩ（アプリケーション・プログラミング・インタフェース）とは、人間とコンピュータとの対話をユーザインタフェースが円滑化するのと同じように、他のソフトウェアとの対話を可能にするためにソフトウェアプログラムによって実装されるインタフェースである。ＡＰＩは、アプリケーション、ライブラリ、およびオペレーティングシステムによって実装され、プログラマがそれらのサービスを利用するために採用すべき語彙と呼び出し規約とを決めるものである。ＡＰＩインタフェースの実装者と消費者との間で通信するために用いられるルーチン、データ構造、オブジェクトクラス、プロトコルについての仕様が含まれることもあり、それによって、ウェブアプリケーションは、プラットフォーム上に実装されていた固有の機能性に到達することができる。

ウェブエンジンとは、ウェブアプリケーションがその中で実行される固有のコンポーネントである。ウェブブラウザは、ウェブエンジンの典型的な例である。

アプリケーションフレームワークとは、ウェブアプリケーションおよびウィジェットを管理および表示するための全体的なクライアント側環境である。それゆえ、ウェブアプリケーションは典型的には、ＤＯＭベースのマークアップ形式と、ブラウザがサポートする言語、典型的にはＳＶＧまたはＨＴＭＬ文書／ファイルおよびＪａｖａＳｃｒｉｐｔ（登録商標）コードとを組み合わせたものを含むと考えられる。さらに、ソフトウェアエンジニアリングにおいて、ウェブアプリケーションとは、インターネットやイントラネットのようなネットワーク経由でウェブブラウザを介してアクセスされるアプリケーションである。また、ウェブアプリケーションという用語は、ブラウザに制御された環境（例えばＪａｖａ（登録商標）アプレット）の中でホストされるかまたは、ブラウザにサポートされた言語（例えば、ＨＴＭＬのようなブラウザがレンダリングするマークアップ言語と組み合わせたＪａｖａｓｃｒｉｐｔ）でコーディングされ、アプリケーションを実行可能にするために共通のウェブブラウザに依存するコンピュータソフトウェアアプリケーションを意味することもある。

ウィジェットは、Ｗ３Ｃ Ｗｉｄｇｅｔｓ Ｆａｍｉｌｙ ｏｆ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓの中に定義されている。基本的に、ウィジェットは、ダウンロードされうる、かつ、クライアント側にローカルに記憶されうる、定義されたパッケージングスキームを伴うウェブアプリケーションであると考えることができる。従って、ウィジェットは、オンラインでの実行とオフラインでの実行とのいずれにも適している。本記述の範囲において、ウィジェットの定義は、ウィジェットはウェブアプリケーションの特殊形態であり、すなわち、ウィジェットはＷ３Ｃ定義のウィジェットの動作と併せてウェブアプリケーションのすべての属性を有するということを述べるように拡張される。しかし、ウィジェットは、アプリケーションのフレームワークの中にロードされることなくデバイスにインストールされ（ローカルに記憶され）てもよいのに対して、アプリケーションは、リモート位置からフレームワークの中に直接ロードされる（ローカルにアプリケーションを記憶することはできない）。

留意すべきことだが、ウィジェットは、その属性を考えれば、ＵＡ（ユーザエージェント）の中へのローカルな記憶（インストール）に適してはいるが、ウィジェットがインストールされなければならないという必要条件は存在しない。ユーザエージェントは、例えばウィジェットをローカルに記憶することを防止する、記憶の制限を有していてもよいが、それでもやはり、ウィジェットの実行を可能にしてもよい。その意味では、ウィジェットは、ウェブアプリケーションとまったく同じようにふるまうであろうが、それでもやはり、ウィジェット固有の属性を条件とするであろう。

本明細書の文脈では、アプリケーションは、アプリケーションマネージャによって管理されるウェブアプリケーションまたはウィジェットであると考えられ、そして、本明細書で定義されるインタフェースまたはメカニズムに従う。留意されるべきだが、本明細書は、ウェブアプリケーション（例えば基本的なＨＴＭＬページ）またはウィジェットが、ウェブアプリケーションの／ウィジェットのマークアップまたはｊａｖａｓｃｒｉｐｔコードをまったく修正することなくアプリケーションとして機能できるように書かれている。

それゆえ、本明細書全体を通じて、アプリケーションという用語が、ウェブアプリケーションとウィジェットとの両方について用いられる。ウィジェットという用語は、議論されるのが特にアプリケーションのウィジェット特殊形態である場合に限って用いられる。

アプリケーションマネージャとは、アプリケーションのレイアウトと管理とを制御するためのメカニズムである。アプリケーションマネージャは、プラットフォームプロバイダによって制御される。

ユーザエージェント（ＵＡ）とは、本明細書によって適用可能な範囲で、ウィジェットユーザエージェントと呼ばれることもある実装である。ＩＰＴＶセグメントにおけるユーザエージェントは、しばしば、ＩＴＦ（ＩＰＴＶ Ｔｅｒｍｉｎａｔｉｎｇ Ｆｕｎｃｔｉｏｎｓ）とも呼ばれるが、本明細書全体を通じて、より一般的な用語であるＵＡが用いられる。

以下に、本発明の実施形態によるさまざまなステークホルダが定義され、ステークホルダ制御のためのモデルが定義される。ステークホルダ制御のためのモデルを図１に示す。

プラットフォームステークホルダとは、プラットフォームのプロバイダであり、典型的には、ＳＴＢまたはＴＶ機器のプロバイダである。プラットフォームステークホルダは、プラットフォームの固有のユーザ体験（ＵＸ）とアプリケーションのレイアウトとを整合させるためにアプリケーションを制御することに関心がある。一例として、或るＴＶ機器プロバイダＸが、特定の時刻点において実行されているかもしれないサービスに依存せずに、ＴＶの固有のルック＆フィールと整合するメニューの中に利用可能なウィジェットを表示することを望んでもよい。

サービスステークホルダとは、サービスのプロバイダであり、典型的にはＴＶサービスを加入者に提供するオペレータである。オペレータは、サービスについての自分自身のＵＸ（Ｕｓｅｒ Ｅｘｐｅｒｉｅｎｃｅ）を提供することと、固有のＵＸをできる限り隠すことに関心がある。これには、サービスＵＸの統合された部分としてアプリケーション制御を提供する能力が含まれる。例えば、ＴＶサービスプロバイダＹが、サービスプロバイダのポータルの中に統合されているメニューの中に、利用可能なウィジェットを表示することを望んでもよい。

アプリケーションステークホルダとは、特定のアプリケーションのプロバイダである。アプリケーションステークホルダは、例えば、このアプリケーションプロバイダからのアプリケーションのリストを表示するために、自分自身から他のアプリケーションを制御することに関心を持つ可能性がある。

定義された各ステークホルダは、以下のように、すなわち、プラットフォームステークホルダ、サービスステークホルダ、アプリケーションステークホルダの順で優先度を高い方から低い方へと付与される。最高の優先度が決定を行い、すなわち、プラットフォームステークホルダが、すべてのアプリケーションはプラットフォームによって制御されるＵＩ（ユーザインタフェース）を通じて制御されなければならないと決定した場合、サービスステークホルダもしくはアプリケーションステークホルダは、この決定より優位に立つことはできない。

ステークホルダの優先度を制御する基本的なメカニズムは、アプリケーションマネージャと、それが制御するアプリケーションモデルとを通して行われる。各ステークホルダはアプリケーションマネージャを制御し、次には、アプリケーションマネージャが、アプリケーション属性の修正と、その他のアプリケーションの追加／呼び出しとに関するアプリケーションからのすべての要求を制御する。ここで、プラットフォームステークホルダは、アプリケーションマネージャを制御するのだから、他のステークホルダの力を制限する機会を有する。さらに、アプリケーションモデルは、ツリー構造を有しており、ルートノードはプラットフォームが制御するノードであり、ここではプラットフォームステークホルダが、例えば所定のイベントがモデルを通過するのを中止させることによって、他のステークホルダの制御を制限するための論理（ロジック）を加えることがある。同様に、ルートノードの下のノードは、典型的にはサービスステークホルダによって制御され、それゆえ、アプリケーションステークホルダの制御を制限するための同様の論理（ロジック）を含むことがある。

アプリケーションマネージャによって制御されるアプリケーションモデルは、すべてのノードがアプリケーションであるような通常のＤＯＭツリーモデルであってもよい。この場合、各アプリケーションは、アプリケーションモデルが通過されたり、アプリケーションが追加および削除されたりすることを可能にする、ＤＯＭ３（ＤＯＭ Ｌｅｖｅｌ３ Ｃｏｒｅ）Ｅｌｅｍｅｎｔ、ＥｌｅｍｅｎｔＴｒａｖｅｒｓａｌおよびＮｏｄｅインタフェースの部分集合（サブセット）を継承する。

ツリーの中のルートノードは、アプリケーションマネージャによって制御される、隠されたシステムノードである。それを削除したり修正したりすることはできず、すべてのアプリケーションは、隠されたノードに対する子ノードとして追加される。ルートノードは、例えば、内蔵の、固有の、ウィジェットバーであってもよいだろう。あるいは、例えばＴＶの電源を切るような、所定の機能性がすべてのウィジェットによって使用されるのを防ぐために所定のイベントがモデルの中に入っていくのを中止させるような、単なる見えないアプリケーションであってもよいだろう。

図３は、単一のファイル／文書がアプリケーションマネージャの中にロードされる場合のアプリケーションモデルを示しており、例えば単純なＳＶＧファイルのように、単一のウェブアプリケーションがＵＡによって表示される場合、モデルは図３に示すように見えるであろう。

アプリケーションフレームワークの中の各アプリケーションは、ルートアプリケーションを除いて、関連のＤｏｃｕｍｅｎｔ（文書）オブジェクトを有する。文書は、特定のアプリケーションのＤＯＭを表しており、モデルの中のいかなる他のアプリケーションにも非依存であり、すなわち、各アプリケーションは、別個のスクリプトコンテクストの中で実行される別個のＤＯＭを有する。

もっと大きいアプリケーションツリーの例を図４に示しており、図４は（右側に）、複数のアプリケーションがアプリケーションマネージャの中にロードされた場合のアプリケーションモデルを示す。左側の図は、各アプリケーションが画面上にどのように表示されうるかを示す。子ノードは、親ノードの属性を継承することができる。例えば、親が削除されたら、子は削除されるが、例えば透明度のようなその他の属性は、来たるべきバージョンのために考慮されてもよいだろう。或るアプリケーションが半透明であることになっているとユーザが言えるのであれば、子アプリケーションも半透明であるはずであろう。

本発明の実施形態によるアプリケーションマネージャは、ＤＯＭ２イベントモデルに基づくイベントモデルを用いてもよい。

特定の時刻点における入力イベント（キーイベント、マウスイベント等）の目標は、ＤＯＭツリーの中のただ１つのノードである。これは、例えばキー入力のようなイベントは、目標アプリケーションに行くであろうが、それをする前に、最前面から目標アプリケーションまで、目標ノードのすべての親（祖先）のそばを通るであろうということを意味する。これを、キャプチャフェーズと呼ぶ。本発明の実施形態によると、通過する個々のノードは、イベントをキャプチャする、すなわち止めてもよい。イベントが目標アプリケーションに到達したら、その後、目標アプリケーションは、イベントをキャプチャ、すなわち止めることもできるし、同じ各ノードのそばを再び遡って通過させる(pass up)こともでき、それをバブルフェーズと呼ぶ。キャプチャおよびバブルフェーズは、ＤＯＭイベントモデルの一部である。

イベントの目標が常に、現時点でのフォーカスされているアプリケーションであるような先行技術のソリューションとは対照的に、本発明の実施形態は、どのアプリケーションが現時点でのフォーカスされているアプリケーションであるかに依存せず、目標アプリケーションが、いかなるアプリケーションであってもよいようなモデルを導入する。しかし、ＤＯＭ２のキャプチャフェーズもバブルフェーズもいずれも、本発明の実施形態によってサポートされる。

ＤＯＭ２イベントモデルによると、イベントは、ルートからスタートして、キャプチャフェーズの間に、目標アプリケーションに向かってツリーを通過する。本発明の実施形態に従って階層モデルを用いることにより、通過する個々のアプリケーションは、アプリケーションがフォーカスされているアプリケーションであるかどうかに依存せず、アプリケーションが目標アプリケーションであるならばイベントをキャプチャしてもよい。イベントが目標アプリケーションに到達すると、イベントは目標アプリケーションによって処理される。目標アプリケーションがイベントをキャプチャしない場合、イベントは、再び、ツリーを上方へルートまで通過するのだが、そのことをバブルフェーズと言う。通過する個々のアプリケーションは、その後のバブリングが行われないように、イベントを止めて（すなわちキャプチャして）もよい。

図５は、イベントが、イベント目標と呼ばれる目標アプリケーションに向かって通過する場合のＤＯＭ２キャプチャフェーズ／バブルフェーズを示す図である。

どのアプリケーションがフォーカスされているアプリケーションであるかに依存せず、いかなるアプリケーションであっても目標アプリケーションであることを可能にするために、階層アプリケーションモデルは、イベントラッパと組み合わせられる。アプリケーションマネージャは、イベントラッパを備えており、イベントラッパは、目標アプリケーションへ向かって通過すべきイベントをラップするように構成される。それゆえ、ラップされたイベントは、アプリケーションのツリーを通って通過する。個々のアプリケーションは、自分(current application)がイベントを処理すべきかどうかをチェックするために、ラップされたイベントを検査するように構成される。判定対象アプリケーション(current application)が自分は目標アプリケーションであると判定した場合、アプリケーションマネージャは、イベントをアンラップし、そのアプリケーションは、アンラップされたイベントを受信して、アンラップされたイベントを通常のイベントとして処理する。判定対象アプリケーションが自分は目標アプリケーションではないと判定した場合、アプリケーションマネージャは、ラップされたイベントをツリーの中のそれに続くアプリケーションにディスパッチする。図２は、本発明の一実施形態によるアプリケーションフレームワーク２０３を示す。アプリケーションフレームワーク２０３は、アプリケーションマネージャ２００と、階層順に配列された各アプリケーション２０２を記憶するメモリ２０４と、を備えている。さらに、アプリケーションマネージャ２００は、イベントを受信するように構成された受信器２０５と、ディスパッチを制御するように構成された制御器２０７とを備えている。制御器２０７は、ディスパッチャ２０６によるディスパッチを制御し、また、イベントラッパ２０１を備えている。アプリケーションマネージャは各アプリケーション２０２を制御するのだから、アプリケーションマネージャ２００は、ラップされたイベントを自分がアンラップすべきかどうか、あるいは、自分はラップされたイベントをそれに続くアプリケーションにディスパッチすべきかどうかを知っている。

目標アプリケーションの祖先であるすべてのアプリケーションは、ｅｖｅｎｔＷｒａｐｐｅｒイベントをリッスン（待ち受け）するためのイベントリスナーをアプリケーションの文書ノード上に追加することによって、イベントをリッスンするように登録することができる。従って、いかなるウェブアプリケーションであってもイベントを受信するためには、そのイベントのためのリスナーを登録しなければならない。ユーザがアプリケーション上でマウスをクリックしても、アプリケーションがマウスイベントリスナーを登録していなかった場合には、何も起こらないであろう。同じことは、ｅｖｅｎｔＷｒａｐｐｅｒイベントにも当てはまる。ｅｖｅｎｔＷｒａｐｐｅｒイベントは、イベントラッパ２０１によって行われる、アプリケーションツリーを通り抜けるときの実際のイベントをラップする特別なイベントである。

ｅｖｅｎｔＷｒａｐｐｅｒイベントが目標アプリケーションに到達した時、すなわち、イベントがアンラップされた時、ラップされていたイベントは、単一文書の環境ではそうであったはずであるように、目標アプリケーションに関連する文書上でディスパッチされる。アンラップされたイベントは、文書によって通常のやり方で処理される。文書から抜ける場合、キャプチャされないならば、イベントは、再びｅｖｅｎｔＷｒａｐｐｅｒイベントの中にラップされて、アプリケーションツリーをバブルアップし始める。

イベントラッピングについて、以下の例によって例示する。

１．アプリケーションマネージャ２００は、システムによって受信器２０５を介してイベント（例えばキー「１」）を受信する。イベントは、フレームワーク２０３の中のメモリ２０４に記憶されているアプリケーション２０２の１つを目標とする。

２．アプリケーションマネージャ２００のイベントラッパ２０１が、ｅｖｅｎｔＷｒａｐｐｅｒイベント（ｅｗ）を作成してイベントをラップする。

３．アプリケーションマネージャ２００が、ラップされたイベントを、目標アプリケーションへ向かってモデルツリーの下方へ通過させる。ラップされたイベントは、ラップされたイベントが検査対象アプリケーション(current application)に適用可能かどうかチェックするために、それが通過する個々のアプリケーション２０２によって検査される。ラップされたイベントが検査対象アプリケーションに適用可能である場合、それは、検査対象アプリケーションが目標アプリケーションであることを意味するであろう。

４．ラップされたイベントが目標アプリケーションに到達した時、アプリケーションマネージャ２００は、イベントをアンラップし、アンラップされたイベントを目標アプリケーションにディスパッチする。

５．イベントが目標アプリケーションによってキャプチャされない場合、アプリケーションマネージャは、イベントをイベントラッパに戻し入れ、そして、実際のイベントを含むラップされたイベントを、モデルの上方へバブルさせる。これは、他のアプリケーションがイベントを処理するかどうかをそのアプリケーションが気にしない場合に適用可能である。それゆえ、他のアプリケーションがイベントを用いるかどうかをそのアプリケーションが気にしないならば、そのアプリケーションはイベントをキャプチャすべきでない。

以下では、この動作をさらに、図６と併せて例示する。

同報されるＴＶチャネルを表示するＴＶアプリケーション６０１を考えよう。天気ウィジェット６０２が、ＴＶアプリケーション６０１の最前面に表示され、天気ウィジェット６０２がフォーカスを持つ。天気ウィジェットがフォーカスを持っている場合、天気ウィジェットは、多様な日についての予報の間をナビゲートするのに用いられる左／右のキー操作をリッスンする。

たとえ天気ウィジェットがフォーカスを持っていても、ＴＶアプリケーションは、通常のキーの上／下を使ってユーザがチャネルを変えることを可能にしたいであろう。各アプリケーションは本発明の実施形態による階層モデルとして構成されているのだから、フォーカスされているアプリケーション以外のアプリケーションは、イベントを処理することができる。この場合、天気ウィジェットは、ＴＶアプリケーションによって追加されたものであり、ＴＶアプリケーションの子である。それゆえ、ＴＶアプリケーションは、天気ウィジェットの親であり、天気ウィジェットまで下がる途中のキャプチャフェーズの間、すべてのイベントは、ＴＶアプリケーションのそばを通過するであろう。従って、ＴＶアプリケーションは、イベントがキーの押し上げまたは押し下げ操作であるかどうかをチェックするであろう。そうである場合には、ＴＶアプリケーションは、イベントを処理するであろうし、そうでない場合は、アプリケーションマネージャは、イベントをさらに天気ウィジェットへとディスパッチするであろう。

上記で説明したように、アプリケーションマネージャは、イベントをラップし、階層ツリーモデルを通してイベントをディスパッチする。ラップされたイベントは、目標アプリケーションの情報を含んでいる。ラップされたイベントが通過する個々のアプリケーションでは、判定対象アプリケーションが、イベントがそのアプリケーションによって処理されるべきかどうかを判定するために、ラップされたイベントを検査する。判定対象アプリケーションがイベントを処理すべき場合、それはそのアプリケーションが目標アプリケーションであることを意味するのだが、アプリケーションマネージャは通知されてイベントをアンラップし、その結果、アプリケーションがイベントを通常のイベントとして処理できる。アプリケーションでは、アプリケーションがどのようにしてイベントを処理すべきかが定義される。これを以下にコードの例によって例示する。

ＴＶアプリケーション

天気アプリケーション

上記のように、例えばキーイベントのような入力イベントがＵＡの中で行われた場合、アプリケーションマネージャのイベントラッパは、ｅｖｅｎｔＷｒａｐｐｅｒイベントによってイベントをラップし、図７ａおよび図７ｂに示すように、それをアプリケーションツリーの下方へ送信する。

図７ａ乃至図７ｃに示す例では、第１のストップは、図７ａに示すようにアプリケーションツリーの隠されたルートノードである。ここでは、プラットフォームステークホルダが、もしそう望むなら、特定のイベントを処理してキャプチャする機会を有する。例えば、特定のキーが、固有のプラットフォームメニューに常に関連付けられてもよく、それ以外のものについては決して用いられてはならないというのでもよい。このキーは、ルートノードの中でキャプチャされるであろう。

ルートノードから、ラップされたイベントは、図７ｂに示すようにアプリケーションマネージャによって制御されながら、目標へ向かってツリーを下方へ移動する。次のストップは、ＴＶアプリケーションノードである。ここでＴＶアプリケーションは、上記のコード例に従ってキーイベントを検査し、イベントがチャネル変更イベントに関する場合、イベントを止める。

代わりに、イベントが天気ウィジェットの管理に関する場合、ＴＶアプリケーションは、ラップされたイベントを通過させるであろう。その次のストップは、図７ｃに示すように、実際のイベントの目標である天気アプリケーションである。

目標アプリケーションでは、アプリケーションマネージャが、イベントをアンラップすることによってラッピングイベントを削除し、適用可能なアプリケーション文書上でキーイベントをディスパッチする。上記のコードの例によると、天気アプリケーションは、左／右のキーの場合には、イベントを処理し、止めるであろう。その他の場合にはすべて、イベントは、止められないであろう。

イベントが止められない場合、アプリケーションマネージャは、ｅｖｅｎｔＷｒａｐｐｅｒイベントの中のイベントをアンラップして、それをツリーを通して上方へバブルさせ、キャプチャ／バブルフェーズを完了させる。留意すべきことだが、この最後のステップは、右側の絵には示されていない。

本発明の第１の実施形態によると、図８に示すように、アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワーク２０３を備えたＩＴＦ（ＩＰＴＶ Ｔｅｒｍｉｎａｌ Ｆｕｎｃｔｉｏｎ）２１０（例えばＳＴＢ（ｓｅｔ−ｔｏｐ−ｂｏｘ）のようなもの）のために構成されたウェブエンジンが提供される。アプリケーションフレームワーク２０３は、少なくとも２つのアプリケーション２０２を記憶するためのメモリ２０４を備えており、ここで各アプリケーション２０２は、相互に関係する階層ツリー構造の中に配置されていて、少なくとも２つのアプリケーションのうちの１つは、フォーカスされているアプリケーションであってもよい。アプリケーションフレームワーク２０３は、さらに、例えばキー操作のようなイベントを受信するための受信ユニット２０５と、ディスパッチを制御するための制御器２０６とを備えたアプリケーションマネージャ２００を備えている。一実施形態によると、制御器２０６は、イベントをラップおよびアンラップするためのイベントラッパ２０１と、ラップされたイベントをアプリケーションツリーを通して下方へ転送するためのディスパッチャ２０７とを含んでいる。個々のアプリケーションノード（およびルートノード）については、アプリケーションマネージャ２００は、判定対象アプリケーションによってイベントが処理されるべきかどうかを制御器２０６を用いて判定するように構成されている。

それゆえ、アプリケーションマネージャ２００の制御器２０６は、イベントのディスパッチを制御する。一実施形態によると、アプリケーションマネージャ２００のイベントラッパ２０１がイベントをラップし、ディスパッチャ２０７が、ラップされたイベントを目標アプリケーションにディスパッチする。個々のアプリケーションについて、ラップされたイベントが判定対象アプリケーションによって処理されるべきかどうかに関してラップされたイベントを検査するように、判定対象アプリケーションが構成されてもよい。あるいは、アプリケーションマネージャが、そのイベントについての目標アプリケーションであるアプリケーションの情報をメモリ２１２の中に記憶するように構成されてもよい。ラップされたイベントが判定対象アプリケーションによって処理されるべき場合、アプリケーションマネージャ２００のイベントラッパ２０１は、イベントが判定対象アプリケーションによって通常のイベントとして処理されうるように、判定対象アプリケーションのためにイベントをアンラップする。イベントが判定対象アプリケーションによって処理されるべきでない場合、アプリケーションマネージャ２００は、ラップされたイベントをそれに続くアプリケーションにディスパッチする。

ＩＴＦ２１０は、各アプリケーション２０２を、サーバ２５０から、およびＡＰＩ２０８を用いることによって、取得することができる。アプリケーションは、図９に示すように画面２６０上に表示されてもよい。また、留意されるべきことだが、典型的なウェブエンジンは、他のコンポーネント、例えばＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）モデルおよびＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）パーサを含んでいるが、それは本発明の範囲内のものではない。

アプリケーションマネージャは、アプリケーションマネージャの機能を実行するためのソフトウェアおよび／またはハードウェア部分を備えた１つ以上のプロセッサと、受信器２０５と、制御器２０６と、ディスパッチャ２０７と、イベントラッパ２０１とによって実装されてもよい。

本発明の第２の実施形態によると、ウェブエンジンにおける方法が、図１０に示すように提供される。ウェブエンジンは、各アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワークを備えたＩＴＦのために構成される。方法は、少なくとも２つのアプリケーションを記憶すること１０００と、ここで各アプリケーションは相互に関係する階層ツリー構造の中に配置されていて、少なくとも２つのアプリケーションのうちの１つはフォーカスされているアプリケーションであり、そして、イベントを受信すること１００１と、フォーカスされているアプリケーションではない各アプリケーションがイベントを受信して処理することができるように、少なくとも１つのアプリケーションを目標とするイベントのディスパッチを制御すること１００２とを含んでいる。

イベントのディスパッチは、アプリケーションマネージャを用いて制御され、ここでアプリケーションマネージャは、イベントをラップおよびアンラップするイベントラッパを備えていてもよい。方法は、さらに、本発明の一実施形態による、イベントをラップするステップ１００３と、ラップされたイベントを目標アプリケーションにディスパッチするステップ１００４とを含んでいる。

個々のアプリケーションについて、判定対象アプリケーションが目標アプリケーションかどうか判定される。これは、ラップされたイベントを検査するように各アプリケーションを構成するかまたは、或るイベントについてどのアプリケーションが目標アプリケーションであるかという情報をアプリケーションマネージャにメモリ２１２の中に記憶させることによって行うことができる。判定対象アプリケーションが目標アプリケーションであり、従って、ラップされたイベントがそのアプリケーションによって処理されるべきである場合１００５、方法は、判定対象アプリケーションによってイベントが通常のイベントとして処理されうるようにそのアプリケーションについてイベントをアンラップすること１００６を含んでいる。イベントが判定対象アプリケーションによって処理されるべきでない場合、アプリケーションマネージャは、ラップされたイベントをそれに続くアプリケーションにディスパッチする１００７。

本発明の階層アプリケーションモデルによって、新たなアプリケーションが含まれることが可能になる。新たなアプリケーションを含むことは、以下のステップによって達成されうる。

１．ユーザが、ｌｏａｄＡｐｐｌｉｃａｔｉｏｎ、またはウィジェット用のｉｎｓｔａｌｌＷｉｄｇｅｔ＋ｌｏａｄＡｐｐｌｉｃａｔｉｏｎを呼び出すことによって、新たなアプリケーションを要求する。

２．要求が、アプリケーションマネージャ２００のＡＰＩによって取り扱われる。

３．要求が、サービスプロバイダまたは別のコンテンツプロバイダによって管理されるサーバ２５０に送信される。

４．サーバが、通常のＨＴＴＰ ＧＥＴを用いてアプリケーションをウェブエンジン２０９に送信することによって、要求に応答する。サーバ２５０がアプリケーションを提供できない場合、何も取得されないであろう。

５．アプリケーションマネージャ２００が、新たなアプリケーションをツリー構造に含める。新たなアプリケーションがツリーに追加された場合、それが自動的に表示される。

本発明の実施形態は、上記の好適実施形態に限定されない。各種の代替形態、修正形態、および均等形態が用いられうる。従って、上記の実施形態は、本発明の範囲を限定しているとみなされるべきではなく、本発明の範囲は、添付の請求項によって定義される。

本発明は、もちろん、本発明の範囲および必須の特性から逸脱することなく本明細書に記述したもの以外の特定のやり方で実行されうる。従って、本発明は、あらゆる点で例示的であるとみなされるべきであって、制限的であるとみなされるべきではなく、添付の請求項の意味と均等範囲とに入るすべての変更は、本発明に包含されることが意図される。

Claims (11)

1. アプリケーションの表示を可能にするＡＰＩに関連付けられたアプリケーションフレームワークを含んだウェブエンジンであってＩＰＴＶ端末機能（ＩＴＦ）のために構成されたウェブエンジンにおける方法であって、
   相互に関係する階層ツリー構造の中に配置された少なくとも２つのアプリケーションを記憶するステップと、
   少なくとも１つのアプリケーションを目標とするイベントを受信するステップと、
   少なくとも１つのアプリケーションを目標とする前記受信したイベントのディスパッチを制御するステップであって、前記受信したイベントを目標アプリケーションへディスパッチするステップを更に含む、ステップと、
   各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定するステップと、
   前記イベントが判定されるべきである場合に、前記判定対象アプリケーションのために前記イベントを処理するステップと、
   前記イベントが判定されるべきでない場合に、前記階層ツリー構造における後続のアプリケーションへと前記イベントをディスパッチするステップと、
   を備えることを特徴とする方法。
2. 前記制御するステップは、前記受信したイベントを目標アプリケーションへディスパッチする前記ステップの前に前記イベントをラップするステップを更に含み、前記イベントは、前記処理するステップの前にアンラップされる
   ことを特徴とする請求項１に記載の方法。
3. 各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定する前記ステップは、前記イベントを検査して前記イベントを前記判定対象アプリケーションに適用可能であるか否かをチェックすることにより実行される
   ことを特徴とする請求項１に記載の方法。
4. 各アプリケーションについて、前記イベントが判定対象アプリケーションによって処理されるべきであるか否かを判定する前記ステップは、アプリケーションマネージャによって実行される
   ことを特徴とする請求項１に記載の方法。
5. 前記アプリケーションフレームワークは、前記アプリケーションを構築するために、ドキュメントオブジェクトモデル（ＤＯＭ）ベースのモデルを使用するように構成される
   ことを特徴とする請求項１に記載の方法。
6. 前記ＩＴＦは、セットトップボックス、移動体端末、またはＰＣである
   ことを特徴とする請求項１に記載の方法。
7. ディスプレイデバイス上へのウェブアプリケーションの表示を可能にするアプリケーションフレームワークを実装したＩＰＴＶ端末であって、
   前記アプリケーションフレームワークは、
   階層ツリー構造の中に組織された２以上のアプリケーションを記憶するメモリと、
   前記階層ツリー構造の中の前記２以上のアプリケーションのうちの１つを目標とするイベントを受信するアプリケーションマネージャと、
   を含み、
   前記アプリケーションマネージャは、
   前記階層ツリー構造の中の第１のアプリケーションが前記目標のアプリケーションであるか否かを判定する制御器と、
   前記第１のアプリケーションが前記目標のアプリケーションでない場合に、前記階層ツリー構造の中の第２のアプリケーションへと前記イベントをディスパッチするディスパッチャと、
   を含む
   ことを特徴とするＩＰＴＶ端末。
8. 前記アプリケーションマネージャは、イベントをラップしてアンラップするイベントラッパを更に含む
   ことを特徴とする請求項７に記載のＩＰＴＶ端末。
9. 前記制御器は、前記イベントの前記目標のアプリケーションを示す情報を記憶する
   ことを特徴とする請求項７に記載のＩＰＴＶ端末。
10. 前記アプリケーションフレームワークは、前記アプリケーションを組織するために、ドキュメントオブジェクトモデル（ＤＯＭ）ベースのモデルを使用する
    ことを特徴とする請求項７に記載のＩＰＴＶ端末。
11. 前記ＩＰＴＶ端末は、セットトップボックス、移動体端末、またはパーソナルコンピュータの中に組み込まれる
    ことを特徴とする請求項７に記載のＩＰＴＶ端末。

Images