JP4451063B2 - 双方向テレビジョンでの表示のためにコンテンツを再フォーマットする方法及び装置 - Google Patents

Description

（著作権表示）
この特許文書の開示の一部に、著作権保護の請求が行われるもの（コード・リスティング及びメッセージ・リスティング）が含まれる。著作権所有者は、米国特許商標局の書類綴り又は記録に現れるこの特許文書又は特許開示の何人による写真複製にも異議を唱えないが、他のすべての権利を留保する。Copyright 2001 OpenTV, Inc.

本発明は、双方向テレビジョンの分野に関し、具体的には、双方向テレビジョン表示空間での視聴のために放送、インターネット、又はキャッシュによって提供されるコンテンツの再フォーマットに関する。

双方向テレビジョン・システムを使用して、視聴者にさまざまなサービスを提供することができる。双方向テレビジョン・システムは、通常のビデオ番組ストリーム、双方向テレビジョン・アプリケーション、テキスト及びグラフィック・イメージ、ウェブ・ページ、並びに他のタイプの情報を配信することができる。双方向テレビジョン・システムは、視聴者の動作又は反応を登録することもでき、マーケティング、エンターテイメント、及び教育などの目的に使用することができる。ユーザ又は視聴者は、宣伝された製品又はサービスの注文、ゲーム・ショーの参加者との競争、特定の番組に関する特殊化された情報の要求、又は情報のページを介するナビゲーションによって、システムと対話することができる。

通常、放送サービス・プロバイダ又はネットワーク・オペレータは、視聴者のテレビジョンへ送信するために双方向テレビジョン信号を生成する。双方向テレビジョン信号に、アプリケーション・コード又は制御情報からなる対話部分及びテレビジョン番組又は他の情報表示からなるオーディオ／ビデオ部分を含めることができる。放送サービス・プロバイダは、オーディオ／ビデオ部分と対話部分を組み合わせて、ユーザのテレビジョンに接続された受信器への送信のための単一の信号にする。この信号は、一般に、送信の前に圧縮され、ケーブル・テレビジョン（ＣＡＴＶ）回線又は直接衛星送信システムなどの通常の放送チャネルを介して放送される。

通常、テレビジョンに接続されたセット・トップ・ボックスによって、テレビジョンの対話機能性が制御される。セット・トップ・ボックスは、放送サービス・プロバイダによって送信された放送信号を受信し、対話部分をオーディオ−ビデオ部分から分離し、信号のめいめいの部分を圧縮解除する。セット・トップ・ボックスは、対話情報を使用して、たとえば、オーディオ／ビデオ情報がテレビジョンに送られている間にアプリケーションを実行する。セット・トップ・ボックスでは、オーディオ／ビデオ情報を、テレビジョンへの情報の送出の前に対話型アプリケーションによって生成された対話型のグラフィックス又はオーディオと組み合わせることができる。対話型のグラフィックス又はオーディオによって、追加情報を視聴者に提示することができ、あるいは、視聴者に入力を促すことができる。セット・トップ・ボックスによって、モデム接続又はケーブルを介する放送サービス・プロバイダに、視聴者の入力又は他の情報を供給することができる。

集合的な性質に従って、双方向テレビジョン・システムは、放送サービス・プロバイダ／ネットワーク・オペレータから情報を受け取るクライアント又は視聴者が理解できることが好ましいさまざまな異なる通信プロトコルでコンテンツを提供する。通常、クライアントはセット・トップ・ボックスであり、プロセッサは限られた処理能力及び通信帯域幅を有する。さまざまなプロトコルの変換は、通常のセット・トップ・ボックス・プロセッサで使用可能な限られた処理能力を超える。さらに、複数のウェブ・オーサリング・ツールを使用してコンテンツを作成する複数のソースがある。したがって、複数のソースからコンテンツを受信し、再構成し、その結果、過度の量の処理又は通信帯域幅なしで、クライアント又はセット・トップ・ボックスのプロセッサによってコンテンツを表示できるようにする、堅牢なサーバ・アーキテクチャの必要がある。

本発明は、上で説明した双方向テレビジョン環境の必要に対処する。

本発明は、複数のソース・コンテンツ・フォーマットを受け入れ、クライアント・デバイスでの表示のためにコンテンツを再構成する、ソフトウェア及びハードウェアを含む方法及び装置を提供する。コンテンツは、サーバで前処理され、その結果、クライアントでの再フォーマット及び変換が不要になる。また、前処理されたコンテンツは必要とする放送環境での帯域幅はより少なくてすむ。ＨＴＭＬコードは、クライアント・デバイスでの表示のための簡潔でコンパクトなコードにトランスコーディングされる。ＭＰＥＧ画像は、クライアント・デバイスでの表示のために再フォーマットされる。視聴者又はクライアントは、（ＳＴＢ）の視聴者、セルラー電話（携帯電話）ユーザ、ディジタル・アシスタント、ポケットＰＣ、又は他の電子受信デバイスとすることができる。

本発明の他の目的及び長所は、以下の詳細な説明を読み、添付図面を参照する時に明白になる。

本発明は、さまざまな修正形態及び代替形態が可能であるが、本発明の特定の実施形態を、図面で例として示し、本明細書で詳細に説明する。しかし、図面及びそれに対する詳細な説明が、開示される特定の形態に本発明を制限することを意図されたものではなく、逆に、本発明が、請求項によって定義される本発明の趣旨及び範囲に含まれるすべての修正形態、同等形態、及び代替形態を含むことを理解されたい。

以下の説明では、本発明の好ましい実施形態の複数の例を説明する。本発明では、クライアント・デバイスでのコンテンツの表示のために、標準ＨＴＭＬが、簡潔でコンパクトなコードにトランスコーディングされる。したがって、トランスコーダによって、ＨＴＭＬを解釈する作業が、クライアントからヘッド・エンドにオフロードされる。トランスコーダ・イメージは、元のイメージより相当に小さくすることができる。したがって、クライアント側で必要な処理能力及び通信帯域幅が少なくなる。本発明では、サイズ、色、及び形のイメージ情報を抽出し、これらのパラメータをレイアウト・エンジンに送る。本発明では、標準ＨＴＭＬ／ＪＰＥＧデータを、ＭＰＥＧイメージ、位置パラメータ、サイズ・パラメータ、及び色パラメータを含む修正されたトランスコードに変換する。トランスコーダは、まず、ＨＴＭＬ入力を解析するが、ページをどのようにレイアウトするかを知らない。本発明では、位置パラメータ、サイズ・パラメータ、色パラメータ、及び形パラメータを、標準ＨＴＭＬ入力から分離し、これらのパラメータを使用して、クライアント・デバイスで表示される修正されたページをレイアウトする。

標準ＨＴＭＬは、ページ指向のページ固有プレゼンテーションのために設計されており、ＨＴＭＬでは、各ＨＴＭＬ要素がページのどこに配置されなければならないかが正確に指定される。標準ＨＴＭＬ入力ではウェブ・ページ及びコンテンツをＪＰＥＧ、ＰＮＧ、又は他のビット・マップ指向イメージ・フォーマットを使用して表す。本発明では、ＭＰＥＧ及びレイアウト・パラメータを使用して、クライアント・デバイスで表示されるページのイメージを表す。

ＭＰＥＧは、モジュロ１６位置の位置決めを必要とし、したがって、本発明は、イメージのＭＰＥＧ表現を囲むバッファを設けて、ＭＰＥＧイメージのｘ位置及びｙ位置が、モジュロ１６に位置合せされることを確実にする。しかし、このモジュロ１６バッファ空間によって、イメージが元のサイズより大きくなる。したがって、より大きいイメージ・サイズが、そのイメージに隣接するテキスト又は他の画像とオーバーラップしないように、レイアウト・エンジンによってバッファ・サイズが考慮される。ＭＰＥＧ表現によって、本発明が、クライアント・デバイスでの表示のためにＭＰＥＧ背景の上でＭＰＥＧイメージを移動できるようになる。したがって、レイアウト・エンジンは、クライアント表示空間でのオーバーラップを避けるために、ＨＴＭＬレイアウトに厳密には従わない場合がある。

標準的なビット・マップ指向の表現では、ページを表す画像及びテキストのすべてが合併され、その結果、ページ内の個々のイメージを、ページ内で移動することができなくなる。標準ＨＴＭＬ／ＪＰＥＧ表現は、ＭＰＥＧ表現より一桁大きい。したがって、本発明によって生成されるトランスコードは、クライアント表示空間でより少ない伝送帯域幅を必要とする。たとえば、６００×６００画素スクリーンのビット・マップ式のイメージ・ページは、５００Ｋバイトのデータを占める可能性がある。同一のページを、ＭＰＥＧファイルとして、３０Ｋバイトで表現でき、このページが、トルゥー・カラー（ｔｒｕｅ ｃｏｌｏｒ）を有することができる。

本発明では、通常はＨＴＭＬと共に使用される標準カスケーディング・スタイル・シート（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔ、ＣＳＳ）が使用されない。本発明では、レイアウト・エンジンで、ＣＳＳをＨＴＭＬ要素ノード・ツリーに変換する。これは、クライアント側で、たとえば、修正されたＨＴＭＬ要素のノードのスタイル又は色を判定するためにＣＳＳを参照するのではなく、各ノードでローカルにスタイルを判定するのに有利である。クライアントのプロセッサは、通常は、限られた処理能力を有し、したがって、要素ノード・ツリーを使用しても、ＨＴＭＬ要素のノードのスタイルを判定するためＣＳＳを調べる必要がない。クライアントは、ノードのスタイルを判定するために、ノードがどのクラスに属するかを判定する必要がない。本発明では、ルートを計算し、ノード・ツリーの各ＨＴＭＬ要素ノードを用いてスタイル、色などを置く。したがって、クライアント側で１回、要素ノード・ツリーによって、望まれる場合に、クライアントが各ノードまで操作でき、ノードについて、たとえば色などの特性を変更できるようになる。これは、他の形で簡単に行うことはできず、たとえば、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒの場合に、ＣＳＳクラス構造及び属性の判定は、計算集中型であり、通常の安価なクライアント・プロセッサの少ない処理帯域幅には不適切である。

本発明では、標準ＨＴＭＬ表現と、たとえばテレビジョン又は他のクライアント・デバイスでのＮＴＳＣ表現との間で必要になる比率変動も計算される。比率変換は、クライアント・デバイスで表示される時に、ＨＴＭＬ形状がひずまないようにするために必要である。比率変換がないと、ＨＴＭＬの円が、クライアント・デバイスで楕円に見える場合がある。

本発明は、ＭＩＭＥハンドラを設けて、サイズ、位置、及び形についてＪＰＥＧ及びヘッダを読み取る。もう１つのＭＩＭＥハンドラが、比率変換を実行し、ＪＰＥＧをＭＰＥＧに変換する。ＭＰＥＧ画像の計算されるバッファ・ゾーンは、ＭＩＭＥハンドラによって計算され、レイアウト・エンジンに渡される。

したがって、本発明によって、さまざまなウェブ・オーサリング・ツールによって生成される、さまざまなコンテンツ・プロバイダ（Ａｍａｚｏｎ．ｃｏｍなど）からの標準的な形のコンテンツを、クライアント・デバイスで表示できるようになる。クライアントの表示は、たとえばＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（ＩＥ）などの、標準的なブラウザの表示に似て見える。本発明によって、コンテンツ・プロバイダがクライアント・デバイスにコンテンツを提供するためのフォーマット用の特殊なツールを使用することを必要とせずに、この種々の要素を含むコンテンツの表示が可能になり、これによって、クライアント・デバイスへのコンテンツの提供が単純になる。

図１を参照すると、サービス・プラットフォーム５０に、おおまかに３つのカテゴリすなわち、コンテンツ変換２０４、トランザクション制御／ビジネス機能２０６、及びトランスポート変換２０７に分割されたアプリケーションのグループが含まれる。本サービス・プラットフォームによって、サービス２００がクライアント２１２と相互作用できる。サービス２００は、サービス・プラットフォーム５０への通信リンク２０２を介して通信する。サービス・プラットフォーム５０は、クライアント２１２と通信する。クライアント２１２は、ＳＴＢ、ディジタル・アシスタント、セルラー電話、又は、通信リンク２１０を介してサービス・プラットフォームと通信できる他の通信デバイスとすることができる。コンテンツ変換２０４サービス及びトランスポート変換２０７サービスは、トランスポートと通信の機能を提供し、ビジネス機能サービスがビジネス制御機能を提供する。

図２からわかるように、トランザクション制御／ビジネス機能２０６は、サービス・プラットフォームとクライアント２１２の間で分散される。たとえば、クライアントが、いくつかのビジネス機能を実行（たとえば、視聴される宣伝を選択するために、宣伝キャンペーン・ルール及び宣伝／ビジネス・フィルタを実施）でき、クライアント２１２により適するコンテンツを選択（たとえば、ユーザ・プロファイルに適する宣伝又はプログラムを選択）することができる。図２の機能を、図３で展開する。図３からわかるように、ビジネス機能２０６に、４つの主要な構成要素すなわち、サービス・マネージャ２３８、視聴者マネージャ２４０、トランザクション・マネージャ２４２、及び宣伝（Ａｄ）マネージャ２４４が含まれる。好ましい実施形態の高水準動作フローの１つの例を、下で示す。

ここで図３を参照すると、サービス２００は、ネットワーク・オペレータと交渉して、ヘッド・エンド・オペレータのサービス・プラットフォームを介して加入者にサービスを提供する。ネットワーク・オペレータ又はヘッド・エンド・オペレータは、サービス・マネージャ２３８を使用して、サービスと、そのサービスに関連する交渉されたビジネス・ルール２２２（たとえば、スケジュール、帯域幅要件、視聴者情報へのサービス・アクセス）を登録する。サービス・マネージャ２３８は、サービス・データ２１６（たとえば、ＵＲＬアドレス、コンテンツ）を保管する。ビジネス・ルール２２２及びサービス・データ２１６に基づいて、サービス・マネージャ２３８は、放送通信２３４機能と通信して、コンテンツ・プロバイダからコンテンツを検索する。

コンテンツが、サービス２００から検索される時に、そのコンテンツを、コンテンツ変換２０４及びコンテンツ・フィルタ２２４によって処理して、コンテンツをクライアント２１２に適する形に変換することができる。放送２３４機能は、コンテンツを、放送２３４網に適する形に変換する。クライアント２１２は、変換されたコンテンツを、放送リンク２４１を介して受け取る。クライアント２１２及びサービス２００は、ポイントツーポイント・リンク２１０及びポイントツーポイント機能２３２を介して相互作用し、ポイントツーポイント機能２３２は、トランスポート変換２０７の一部である。サービス２００に、ショッピング、オーディオ／ビデオ、ゲーム、投票、宣伝、メッセージング、又は他の任意のサービスを含めることができる。

クライアント２１２は、ポイントツーポイント２３２通信リンクを介して、サービス・プラットフォーム５０及びサービス２００と通信する。ロード・バランサ２３６が、ビジネス機能２０６と相互作用して、放送２３４通信リンク２４１とポイントツーポイント２３２通信リンク２１０の間での最適の負荷分散を判定する。プラットフォーム・ビジネス・エージェント２２６は、ビジネス・ルール２２２を使用して、サービス２００とクライアント２１２の間の相互作用及び情報の交換を制御する。たとえば、ネットワーク・オペレータが、ユーザ情報へのサービス２００アクセスを防止することを選択することができる。サービス２００は、ビジネス・ルール２２２及びサービス・データ２１６に基づいて、ユーザ情報へのアクセスのために支払うことが好ましい。

視聴者マネージャ２４０は、クライアント／ユーザ情報をユーザ・データ２２０に保管する。プラットフォーム・ビジネス・エージェント２２６は、サービス２００への視聴者情報の流れを制御する。トランザクション・マネージャ２４２は、サービス２００とクライアント２１２の間で交換されたトランザクション情報を記録する。ビジネス・ルール２２２及びユーザ・データ２２０に基づいて、宣伝マネージャ２４４は、どの宣伝及びどのタイプの宣伝が、放送２３４リンク２４１及びポイントツーポイント２３２リンク２１０を介してクライアントに提示されるかを決定する。

図４に、サービス・プラットフォーム５０の好ましい実施形態のもう１つの例を示す。サービス２００は、インターネットを介する、又はネットワーク・オペレータがアクセス可能な別のネットワークか又は通信チャネルを介するかのいずれかで、ショッピング、チャット、及び他のサービスを提供する。サービス・プラットフォームを使用して、ネットワーク・オペレータが、これらのサービスにアクセスする。サービス・マネージャ２３８を含むビジネス機能２０６が、カルーセル・マネージャ２５４と相互作用して、サービス２００からコンテンツを検索する。カルーセルには、サービス・プラットフォーム５０からクライアントへ放送されるオーディオ／ビデオ／対話データの繰り返されるストリームが含まれる。カルーセル・マネージャ２５４、トランザクション・マネージャ２４２、及びサービス・マネージャ２３８は、放送カルーセルへのコンテンツの挿入及び削除を制御する。サービス・コンテンツは、Ｈ２Ｏ ２４８によって検索され、クライアントに適するフォーマットに変換される。Ｈ２Ｏ ２４８は、コンテンツ変換２０４及びコンテンツ・フィルタ２２４の可能な実施形態である。Ｈ２Ｏは、ＨＴＭＬコンテンツを、サービス・プラットフォーム／クライアント可読コンテンツに変換する。変換されたコンテンツは、データ・カルーセルにフォーマットされ、クライアント２１２への放送のためにオープン・ストリーマ２５６によって多重化される。クライアント２１２は、サービスと相互作用し、必要な場合に、サービス・プラットフォーム及びサービス２００と通信する。ポイントツーポイント通信は、サービス・ゲートウェイ２４６を介して進む。サービス・ゲートウェイ２４６は、トランスポート変換を実行して、ＳＴＢプロトコルを、プラットフォーム・ビジネス・エージェント２２６及びＨ２Ｏ ２４８が期待し理解する形に変換する。ロード・バランサ２３６は、ビジネス機能２０６、カルーセル・マネージャ２５４、及びサービス・ゲートウェイ２４６と相互作用して、放送リンク２４１とポイントツーポイント通信リンク２１０の間の最適負荷を判定する。ビジネス機能２０６は、プラットフォーム・ビジネス・エージェント２２６と相互作用して、サービス２００とクライアント２１２の間のアクセス及び情報交換を制御する。

Ｈ２Ｏ
本発明の好ましい実施形態では、Ｈ２Ｏが、クライアント／サーバ・ソリューションであり、これによって、インターネット・コンテンツ開発者が、サービス・プラットフォームを稼動させるネットワーク・オペレータ用の双方向テレビジョンのアプリケーション及びサービスを作成できる。サービス・プラットフォームによって、視聴者が、双方向テレビジョン・アプリケーションの膨大な拡大しつつある全世界の市場から使用可能にされるインターネットのタレント及びコンテンツの大きいプールにアクセスできる。Ｈ２Ｏサーバは、インターネット・コンテンツ（ＨＴＭＬページ、ＥＣＭＡスクリプト、及びＨＴＭＬページ・フォーマット）を、サービス・プラットフォーム・アセット（ａｓｓｅｔ）に変換する。Ｈ２Ｏクライアントは、アセットをレンダリングし、クライアントと相互作用する。Ｔコマース／Ｅコマース・ケース・シナリオでは、Ｈ２Ｏによって、Ｅコマース・ショップが、既存のウェブ・ツールを使用し、標準ウェブ・プロトコルを使用して、ショッピング・サービスを作成でき、好ましいサービス・プラットフォーム（オペレータ）と相互作用できるようになる。

Ｈ２Ｏは、サービス・ゲートウェイ及び放送ツールへのプロキシとして働いて、ウェブ・コンテンツを変換する。ウェブ・サイトは、その現在のＨＴＴＰサーバ及びアプリケーション・サーバを使用して、双方向テレビジョン・コンテンツを生成する。好ましい実施形態では、Ｈ２Ｏが、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔなどのスクリプト、及びインターネット・グラフィックスを、クライアント互換コードに変換する。他の既知のプロトコル又は開発されるプロトコルも、Ｈ２Ｏの機能性に追加することができる。Ｈ２Ｏによって、サービス・プラットフォームが、ブラウザの全機能を備えてはいないクライアントのＳＴＢと通信でき、オリジナル・ユーザ・インターフェースを作成できる。Ｈ２Ｏによって、ＨＴＭＬだけを使用する任意のコマース・エンジンへのサービス・プラットフォーム接続が可能になる。Ｈ２Ｏは、ＨＴＭＬページ、ＪＰＧピクチャ、ｗａｖｅオーディオ・ファイルなどのウェブ・コンテンツを、クライアント・デバイス側の最小限の処理機能及び帯域幅で簡単に使用できるクライアント・デバイス互換リソースに変換する責任を負う。

Ｈ２Ｏのサーバ側は、ＨＴＴＰプロキシであり、Ｈ２ＯＳと称する。他の目的のために、Ｈ２ＯＳをＤＬＬ又はバッチ・ツールとしてパッケージ化することができる。Ｈ２Ｏのクライアント側であるＳＴＢ ＯＣＯＤアプリケーションは、Ｈ２ＯＣである。Ｈ２ＯＣは、サービス・ゲートウェイ・ライブラリ又はカルーセル・ロード・ライブラリなど、他のサービス・プラットフォーム・クライアント構成要素の上に構築される。Ｈ２Ｏによって、ＵＲＬを使用して、文書及びサービスをアドレッシングできる。Ｈ２Ｏによって、放送及びオンライン環境での追跡が可能になる。Ｈ２ＯＳは、ＨＴＴＰプロキシの機能性を提供する。サービス・プラットフォーム・アプリケーションは、Ｈ２Ｏを介して文書を要求する。Ｈ２Ｏは、文書を検索し、解析し、コンパイルし、要求元にその文書を返す。このＨ２Ｏの機能性によって、同一のエンジンを、異なる用途すなわちオンラインや放送に使用でき、スケーラビリティが容易になり、Ｈ２Ｏの柔軟性が可能になる。解析は、文書のタイプに依存し、たとえば、解析を、ＨＴＭＬ解析、ＧＩＦピクチャ、又はＭＪＰＧイメージなどとすることができる。Ｈ２Ｏを拡張可能にするために、Ｈ２Ｏは、新しいサード・パーティのコンバータ及びフィルタを「プラグイン」し、実行する機能を提供する。

Ｈ２Ｏによって、異なる言語を使用するスクリプティングが可能になる。すべてのサービス・プラットフォーム・サーバ構成要素で、アラウンド・モニタリング（ａｒｏｕｎｄ ｍｏｎｉｔｏｒｉｎｇ）、特に異なるプロセスをリモートから監視する能力が標準化されることが好ましい。ＳＮＭＰを使用して、基本機能（「プロセスＯＫ」、主要な問題に対するトラップ）を処理する。状況を検査するためのソケット上のコマンドライン・インタープリタも設けられる。パラメータを設定することによって、ウェブ・スクリプトを介するリモート管理及びウェブとの相互作用が可能になる。好ましい実施形態では、標準化された警告及びエラー・ログが提供される。

Ｈ２Ｏは、エラー通知のために、サービス・プラットフォーム・メッセージング・マネージャに電子メールを送る。サポートされない機能、タグなどが、ページの拒否を引き起こし、エラー・メッセージが送信される。Ｈ２Ｏによって、グラフィカル要素の制御された位置決め（ｘ、ｙ、ｚ）が可能になる。サービス・プラットフォームの出力に、放送内のアセットを複製しないリソースが含まれることが好ましい。Ｈ２Ｏは、画像（ＪＰＥＧ、ＢＭＰ、ＭＰＥＧ、ＧＩＦ）、オーディオ（セットトップ・ネイティブ）、及びフォント；アニメーション（ＧＩＦ）、バイナリ（サード・パーティ・ガジェットによって使用される）、ＣＬＵＴ（電子メール全体に固定）、及び任意の位置の動的制御を含むアセットをサポートする。

Ｈ２Ｏは、Ａ／Ｖ制御、チャネル制御、オン・スクリーン・ディスプレイ（ＯＳＤ）制御、及びトリガを含む特殊なタグをサポートする。Ｈ２ＯがサポートするＷ３Ｃタグには、グラフィカル要素の制御された位置決め（ｘ、ｙ、ｚ）が含まれる。Ｍａｔｈ、ＤＯＭ ｐａｒｔｉａｌ、及びＤａｔｅを含むＪａｖａＳｃｒｉｐｔライブラリが設けられる。Ｈ２Ｏのクライアント側であるＨ２０Ｃは、クライアント又はＳＴＢのグラフィックス・アセットを構成する。Ｈ２Ｏによって、受信時の、ユーザが見るページの更新表示が可能になる。Ｈ２ＯＣでは、他のサービス・プラットフォーム構成要素によって提供されるライブラリ（通信、カルーセル他）が使用される。Ｈ２Ｏによって、１ショットでのページ全体のリフレッシュが可能になるが、アセットがロードされる時の部分更新と、すべてのアセットがロードされるまで待つことの間での選択のオプションも提供される。Ｈ２Ｏによって、サード・パーティ・クラスの動的リンク／アンリンクが可能になる。

サーバがコンテキストを処理するので、ＨＴＭＬ／ＪＳは、任意選択として、ウェブのあるページから別のページへ情報を共用しない。放送モードでは、この配置は不十分である。放送モードでは、新しいページを開始する時にクリアされない、グローバル永続オブジェクトが提供される。永続オブジェクトによって、ページの間でコンテキストが維持される。サービス・プラットフォームによって提供される他の基本オブジェクトも、推移（たとえばステーション・コントロール（ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌ）、ＯＳＤなど）の際に永続的にされる。ガジェットは、新しいガジェットの作成、ガジェットの修正、及びコンパイラを変更しないメソッドの追加を可能にするインターフェース定義言語を介して定義される。

Ｈ２Ｏカルーセル特徴によって、カタログのリアルタイム更新、更新中のカタログの一貫性の維持、及び安全なトランザクショナル・モデルの提供がもたらされる。Ｈ２Ｏカルーセルによって、単一のトランザクションでの、単一のページ又はページの組全体の更新が可能になる。カルーセル管理によって、カルーセルのインデックス又はディレクトリの管理がもたらされる。インデックスには、カルーセルのデータにアクセスし、取り出すための情報が含まれる。すなわち、所与のページについて、カルーセル管理に、必要なすべてのモジュールのリストが含まれ、その結果、Ｈ２ＯＣが、処理をはかどらせるために１回で必要なすべてのモジュールを要求するようになる。

カルーセルは、データ圧縮、ページ上のメタ・データ（たとえば、ページの相対優先順位、どれほど頻繁にページを送信するか）、及びページ追跡（エレメンタル・ストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）を提供する。カルーセル・クライアントは、ＳＴＢ ＯＣＯＤライブラリであり、リソースのロードを処理する。カルーセル・クライアントは、リソースすなわち、新しいリソース、削除されたリソース、及び変更されたリソースの動的性を管理する。動的リソース管理によって、このライブラリのクライアント（Ｈ２ＯＣ）が、ダイナミック・コンテンツを提示できるようになる。カルーセル・クライアントは、メモリ割振り、リソースのプリフェッチ及びキャッシング、及びモジュールの圧縮解除を管理する。カルーセル・クライアントは、サブインデックス／ディレクトリを管理し、リソースの「ツリー」ではなくリソースの「セット」を管理し、これによって、アセットの共用が容易になる。

Ｈ２Ｏは、共用モジュール内の共用リソースなどの、テレビジョン・トリガ、性能、及び帯域幅を監視する。Ｈ２Ｏは、帯域幅利用を最適化する。Ｈ２Ｏは、マルチタスク、複数優先順位、データのビッド・ボリューム（ｂｉｄ ｖｏｌｕｍｅ）の管理を提供する。Ｈ２Ｏは、モジュール・レベルでのランタイムのプリフェッチ及びキャッシングを提供する。Ｈ２Ｏは、圧縮されたモジュールをサポートする。サーファー組込みＧＵＩは、最小限であり、０であることが好ましい。Ｈ２Ｏは、矢印キー及び直接キーのナビゲーション（たとえば数字又は色）、国際（中国）文字処理、ページ上のメタ・データ（たとえば、ページの相対優先順位、どれほど頻繁にページを送信するか）、及びページ追跡（エレメンタル・ストリーム）をサポートする。グローバルＧＵＩは、共用される、すなわち、直接キー・リンクが提供され、その結果、すべての他のページが、任意の情報ページを共用できるようになる。

Ｈ２Ｏは、ページ及びサブページを管理して、ページが１画面に収めるには大きすぎる場合を、スクロールの必要なしで処理する。Ｈ２Ｏによって、ＨＴＭＬを使用して、オンライン、ポイントツーポイント、及び放送でコンテンツを提示できるようになる。Ｈ２Ｏによって、放送構成要素とオンライン構成要素の混合を有するページの構成が可能になる。たとえば、ページがオンライン・サーバから来るが、その背景を放送されるものにすることができる。Ｈ２Ｏによって、クライアント／ＳＴＢでのコンテンツの合併が可能になる。たとえば、ＨＴＭＬページが放送される間に、銀行アプリケーションが、そのサーバから視聴者の最後の２０回のＶＩＳＡ（登録商標）トランザクションを送信することができる。ＪａｖａＳｃｒｉｐｔ関数によって、要求し（ＨＴＴＰ風）、その結果を使用し、あるＤＯＭ機能によって、その結果を表にパッチすることが好ましい。

図５及び６に移って、主要なＨ２Ｏ構成要素の説明を以下に示す。Ｈ２Ｏトランスコーダ２１１０が、ＨＴＭＬ入力２０６２をＨ２Ｏトランスコードに変換し、このＨ２Ｏトランスコードを、ＯｐｅｎＴＶ ＳＴＢ内のＨ２Ｏブラウザによって効果的に対話式に表示することができる。Ｈ２Ｏブラウザは、制限付きダイナミックＨＴＭＬ４の形でＨ２Ｏトランスコードを表示する。ＨＴＴＰプロキシ２００３などのホストが、Ｈ２Ｏトランスコーダ２００１を呼び出す。Ｈ２Ｏトランスコーダ２００１は、非ＨＴＭＬ ＭＩＭＥタイプのコンテンツ情報について、ＭＩＭＥハンドラ２０３６及びＭＩＭＥ情報２０２８と相互作用する。リソース・コンパイラはマルチスレッド・セーフである。Ｈ２Ｏトランスコーダが入力としてスクリプトをとるためにＨ２Ｏ ＪａｖａＳｃｒｉｐｔハンドラ２０００を呼び出し、外部スクリプト又はクラスＵＲＩが、ＪＳ２Ｏコンパイラを呼びだし、ＪａｖａＳｃｒｉｐｔを事前リンクする。ＪＳハンドラが、ＪＳカスタム・クラス２０７０及びＪＳ共用スクリプト２０６６を処理する。Ｈ２Ｏブラウザ２１００が、ＪａｖａＳｃｒｉｐｔサポートのためにＪＳ２Ｏ ＪａｖａＳｃｒｉｐｔランタイム２１２９とインターフェースする。Ｈ２Ｏブラウザは、ＵＲＩによってコンテンツを検索するために、ＵＲＩリトリーバ２１６２とインターフェースする。Ｈ２Ｏブラウザ２１００は、通常は、ＵＲＩリトリーバ２１６２を使用して、ＨＴＴＰ ＵＲＩ要求を行い、応答を入手し、クッキーを処理する。Ｈ２Ｏブラウザは、イメージ・ライブラリ及びイベント・ライブラリを使用する。Ｈ２Ｏトランスコーダが、高性能ＨＴＴＰプロキシ内のタスク（プロセス又はスレッド）の一部として、ライブラリとして呼び出される。Ｈ２Ｏトランスコーダには、その主要な構成要素としてＨＴＭＬパーサ／レイアウト・エンジン・ソースが含まれる。そのホスト環境（プロキシ・サーバ）がＨＴＭＬ ＵＲＩ要求を受け取り、ＨＴＭＬテキスト・ソースを取り出す情況において、Ｈ２Ｏトランスコーダは、環境のホスティングを制御するインターフェースを提供する。Ｈ２Ｏインターフェースには下記が含まれる。Ｈ２Ｏ＿ｔｒａｎｓｃｏｄｅｒ；ｍｅｔｈｏｄ：Ｈ２ＯＳ＿ｇｅｎｅｒａｔｅ＿ｔｒａｎｓｃｏｄｅ、Ｉｎｐｕｔ：ＭＩＭＥタイプｔｅｘｔ／ｈｔｍｌ、ターゲット・ビューのメモリ・ブロック、Ｒｅｔｕｒｎ：トランスコード・タイプのメモリ・ブロック、Ｂｅｈａｖｉｏｒ：入力ＨＴＭＬコンテンツを解析し、レイアウトし、トランスコード・タイプ（ＳＴＢであることが好ましいクライアント・デバイスで稼動するＨ２Ｏブラウザによって使用される準備ができている）を生成する。Ｈ２Ｏトランスコーダは、同期式に実行され、マルチスレッド・セーフである。

ＨＴＭＬ入力を処理する時に、Ｈ２Ｏトランスコーダは、静的に参照され、ＨＴＭＬ入力に含まれるすべてのＵＲＩを発見する。Ｈ２Ｏトランスコーダは、ＵＲＩハンドラ２０３４を使用して、必要なＵＲＩ及び参照のリストを取り出し、Ｈ２Ｏトランスコーダが使用する情報を返す。Ｈ２Ｏトランスコーダは、ＵＲＩコンテンツ情報すなわち、レイアウト処理で使用される情報の幅及び高さを使用する。

ＭＩＭＥインターフェース・ハンドラは、次のようにＨ２Ｏトランスコーダに公開される。Ｉｎｔｅｒｆａｃｅ：ＭＩＭＥ＿ｈａｎｄｌｅｒ；ｍｅｔｈｏｄ：ＭＩＭＥＨａｎｄｌｅｒ＿ｈａｎｄｌｅ＿ｕｒｉ；Ｉｎｐｕｔ：受け入れられたＭＩＭＩＥタイプ、ビュー・オプション、処理オプションを有するＵＲＩストリング、ＭＩＭＥ ｔｙｐｅ：ｐｉｘｍａｐ、ｂｍｐ、ｇｉｆ、ｊｐｅｇ、フォント、カラー・テーブル、ＪａｖａＳｃｒｉｐｔテキスト、ＭＰＥＧオーディオ、ＳＰコード・モジュール、及びデータ・リソース・モジュール、Ｒｅｔｕｒｎ：必ずしもコンテンツ全体ではないＭＩＭＥコンテンツ情報；通常はレイアウト・エンジンのためにタイプ、高さ、及び幅の情報を含むイメージ。

Ｂｅｈａｖｉｏｒ：タスクとして稼動し、要求された時に、ホストＨＴＴＰプロキシを介してＭＩＭＥコンテンツを取り出し、ＭＩＭＥコンテンツを処理する。よりよい効率のためにキャッシング機構を処理するインターフェースが、プロキシ・ホストに設けられることが好ましい。Ｈ２Ｏトランスコーダは同期式に実行される。ＨＴＭＬ４特徴のサブセットがＨ２Ｏトランスコーダでサポートされる。ＨＴＭＬ４コンテンツは、トランスコーダによって特定のターゲット・ビューにレンダリングされ、そのレンダリング処理では、ＨＴＭＬ要素及び属性のほとんどすべてのルールが適用され、デフォルト・スタイルを含むスタイル・ルールが計算される。ＨＴＭＬ４の動的特徴（主にスタイル及びＤＯＭインターフェース）は、本発明では、限られたＤＯＭインターフェースを介して制限される。

Ｈ２Ｏブラウザは、ＨＴＭＬ４．０１ Ｗ３標準規格の選択されたサブセットをサポートする。Ｈ２Ｏブラウザは、テキストのサブセットすなわち段落、行、句と、リストのサブセットと、テーブルのサブセットと、リンクのサブセットをサポートする。Ｈ２Ｏブラウザは、Ｏｂｊｅｃｔ要素及びＩｍａｇｅ要素のサブセットもサポートする。Ｈ２Ｏブラウザは、フィルタ・オーサリング側オブジェクト（たとえばＩＥカスタム・オブジェクト）もサポートし、ＳＴＢのランタイム・カスタム・オブジェクト、オーサリング側（ＰＣ）とＳＴＢの両方のカスタム・オブジェクト・クラス開発、イメージ・マップのサブセット（クライアント側、サーバ側）、フォーム及びフォーム・コントロールのサブセット、さまざまなＳｃｒｉｐｔ要素、及びＪａｖａＳｃｒｉｐｔのサブセットをサポートする。

本発明は、カラー・マップ拡張要素を定義する機能性を提供する。本発明は、主にクライアント・ディスプレイ、好ましくはテレビジョン画面での視聴オプションのために、クライアントタグ拡張を定義し、ＣＳＳのサブセットをサポートし、ＣＳＳを制限する機能性を提供する。本発明は、Ｈ２Ｏトランスコーダで、Ｗ３標準ＣＳＳのサブセットをサポートする。ほとんどのＣＳＳ特徴がＨ２Ｏトランスコーダでサポートされる。ＣＳＳの動的特徴は、Ｈ２Ｏブラウザでは制限される。Ｈ２Ｏトランスコーダは、文書レイアウト及びプレゼンテーションにＣＳＳを適用する。Ｈ２Ｏトランスコーダでは、ＨＴＭＬノードに、要素ノード内の一度計算されたＣＳＳ情報が含まれる。追加のＣＳＳは、存在するとしても非常に限られたものが予約される。これは、ＣＳＳの動的カスケーディング・ルールとは基本的に異なる。スタイル変更が、１つのノードだけに適用されることが好ましいので、動的スタイルは制限される。これは、ＤＯＭを介して特定の要素のスタイルのプロパティを照会し、それによって有効な値が返されると期待するために、ＰＣエミュレーションが同様に振る舞うために、スタイル・プロパティ（たとえばｓｔｙｌｅ＝ｃｏｌｏｒ：ｒｅｄ）が、インライン・スタイルの内部で要素について明示的に指定されるか、ＪａｖａＳｃｒｉｐｔコードで明示的に作成されることを意味する。

本発明は、上下左右の絶対位置決めスタイルをサポートするが、ｚオーダリングをサポートしないことが好ましい。ただし、代替実施形態では、ｚオーダリングがサポートされる。Ｈ２Ｏトランスコーダでは、本文マージン、ビュー・スタイル（ＯＳＤ領域及び寸法、幅制限）、ｍｐｅｇ背景又は非ｍｐｅｇ背景、及び透明度ルールを含むレイアウト・エンジン用のターゲットＳＴＢスタイルが定義される。レイアウト・フロー内のＭｐｅｇスライス・イメージは、通常のブラウザ・レイアウトの形に適合しないＭｐｅｇの１６×１６ブロック位置合せ要件に適応するために、余分なレイアウト境界ボックス・サイズでパディングされる。本発明では、他のＭＩＭＥタイプ・コンテンツからのＭＰＥＧ背景及びスライスへのコンテンツの変換を指定する構成及び明示的指定によって、スタイル・ルール／属性が定義される。本発明では、複数行アンカ情報が、サーバ側で、最初の行アンカ又はイメージだけをアンカとして使用することによって解決される。Ｈ２Ｏトランスコーダは、フォーカス強調表示情報に関するスタイル情報を生成する。制限されたスタイル情報が、トランスコーダに保管される。

本発明は、Ｈ２ＯブラウザでＨＴＭＬ ＤＯＭのサブセットをサポートする。本発明はＨＴＭＬ解析例外処理も提供する。

本発明は、解析エンジンによって又は別の検証モジュール内のいずれかで、厳密に定義されたＨＴＭＬサブセットを実施する。ＨＴＭＬパーサ・エンジンは、無効なタグ順序、タグ・クロージング、タグ・ネスティング、及び許容可能な外見を有する属性を処理する。ＨＴＭＬパーサ・エンジンの例外処理（要素ツリーの差、レイアウトの差などをもたらす）は、Ｍｉｃｒｏｓｏｆｔ ＩＥ及び他の標準的なブラウザと異なる。

Ｈ２Ｏトランスコーダは、ＨＴＭＬエンジンの処理挙動を制御する。Ｈ２Ｏトランスコーダは、解析／レイアウト処理の生成されたデータ・モデルに完全にアクセスすることができる。ＨＴＭＬエンジンは、再入セーフであり、ライブラリとして実行することができる。本発明では、ＨＴＭＬパーサ・エンジンを呼び出して、ＨＴＭＬソースを解析し、エンジンの内部文書表現（ＯＯＭ）を生成する。解析エンジンは、Ｈ２Ｏ ＨＴＭＬ／ＣＳＳ機能性仕様に準拠するように修正される。本発明では、内部解析を制御して、ＨＴＭＬ４サブセット定義に基づいて要素を処理する。本発明によって、ＨＴＭＬ要素解析が使用可能にされ、使用不可にされ、拡張され、修正される。本発明では、内部データ・モデル又はエンジンに、必要な情報（たとえばイメージの幅及び高さ）が追加される。本発明によって、スクリプト要素も処理される。

本発明では、Ｈ２Ｏ ＪａｖａＳｃｒｉｐｔハンドラ・タスクを呼び出して、Ｓｃｒｉｐｔ要素データを処理する。ＪａｖａＳｃｒｉｐｔハンドラ・タスクは、スクリプトＵＲＩを取り出し、ＪＳ２Ｏ ＪａｖａＳｃｒｉｐｔコンパイラを呼び出す。ＪＳ２Ｏは、コンパイルされたＪａｖａＳｃｒｉｐｔコード・モジュールを含むデータ・パッケージを返す。ＪＳ２Ｏは、ＪａｖａＳｃｒｉｐｔスクリプトをキャッシングし、繰り返して、類似するＪａｖａＳｃｒｉｐｔスクリプトと突き合わせる。好ましいレイアウト・エンジンは、ＨＴＭＬ文書内の構成及び明示的指定によって、ターゲット・ビューの内部データ・モデルをレイアウトする。レイアウト・エンジンは、指定されたＨ２Ｏ ＨＴＭＬ／ＣＳＳ機能性仕様に準拠するように修正される。本発明では、複数行アンカ問題がサーバ側で解決され、最初の行アンカ又はイメージだけがアンカとして使用される。トランスコーダは、計算されたレイアウト／スタイル情報を生成し、これを内部データ・モデルにアタッチするか、データ・モデルを生成する。本発明のレイアウトは、提案された幅に適用されるが、レイアウトに制限された幅を強制はしない。

本発明では、レイアウト情報及び制限されたスタイル情報と共にパーサ・エンジン内部データ・モデルからのクライアント互換リソース及びＪａｖａＳｃｒｉｐｔコードを使用して、Ｈ２Ｏトランスコードを生成する。Ｈ２Ｏトランスコード・フォーマットの全般的な指定には、クライアント又はＳＴＢのために文書及びＪａｖａＳｃｒｉｐｔコードを表すクライアント互換リソースのトランスコード・セクションが含まれる。トランスコード・フォーマットに、ツリー構造での文書に関する情報が含まれる。このフォーマットは、効率的でコンパクトで拡張可能である。このフォーマットによって、クライアント又はＳＴＢの適合を保証するバージョン番号が提供される。このフォーマットでは、圧縮及び再配置が考慮されている。効率的なフォーマットによって、クライアント又はＳＴＢのブラウザによる効率的なロードが可能になる。このフォーマットには、Ｈ２Ｏブラウザがリンケージを効率的に解決するのに十分な情報が含まれる。パッケージ・フォーマットのバージョンは、Ｈ２Ｏブラウザなど、すべての関連する製品と同期化されることが好ましい。

ＯコードＨＴＭＬブラウザ
Ｈ２Ｏブラウザ２１００は、制限されたダイナミックＨＴＭＬ４の形でＨ２Ｏトランスコードを表示する。Ｈ２Ｏブラウザは、ＪＳ２Ｏランタイム・モジュール２１２９と相互作用し、Ｈ２Ｏブラウザには、内部構成要素すなわち、ＯＯＭ（クライアント互換オブジェクト・モデル）、コントローラ、及びレベル２ＨＴＭＬ４データ・モデルが含まれる。

ＨＴＭＬブラウザは、ＨＴＭＬ ＤＯＭ標準規格のサブセットをサポートする。ＨＴＭＬブラウザは、ＨＴＭＬ ＤＯＭノードのトラバーサル、作成、破壊、及び挿入をサポートし、ユニークＩＤによる要素ルックアップをサポートする。ＨＴＭＬブラウザは、挿入中のオブジェクトの初期化及び参照を解決する。ＨＴＭＬブラウザは、ノード・クローニングをサポートする。ＨＴＭＬブラウザは、ＤＯＭの部分（たとえばｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ（））への変換のためのＨＴＭＬスクリプトの動的解析を提供しないことが好ましい。ＨＴＭＬブラウザでは、ＨＴＭＬ ＤＯＭオブジェクトに対する変更を反映するために文書ビューが更新される順序が定義される。好ましいＨＴＭＬブラウザは、ＤＯＭを介するＨＴＭＬの修正を反映するためのＳＴＢのレイアウト・フローの動的な再レイアウトをサポートしない。レイアウト・フロー・テキストに対して行われる変更は、テキストをラップする再レイアウトをもたらさない。レイアウト・フロー・テキストは、ラップされないことが好ましい。レイアウト・フロー・テキストに対する変更は行われないが、Ｔｅｘｔエリア（テキストをラップすることができる）又はＩｎｐｕｔなどのノード・オブジェクト内のテキスト・プロパティに対する変更をビュー内で更新することができる。これらによって、ＵＩオブジェクトの動的更新の効果が達成される。ＨＴＭＬブラウザは、ＨＴＭＬ ＤＯＭインターフェースのサブセット、及びＨＴＭＬ ＤＯＭオブジェクトを操作するＪａｖａＳｃｒｉｐｔのオブジェクトを提供する。ＨＴＭＬブラウザは、Ｃプログラムに関する同一のサポートを提供する。ＨＴＭＬブラウザは、ＨＴＭＬ ＤＯＭイベントを処理し、オーサリング側のフォントをクライアント互換のフォントにマッピングする機構を提供する。Ｈ２Ｏ ＤＯＭインターフェースによって、クライアント互換フォント情報が操作される。

ＯＯＭ（クライアント互換オブジェクト・モデル）
ＯＯＭは、開発者がカスタム・クラスを開発するために提供される。ＯＯＭによって、カスタム・オブジェクト・クラスを開発し、クラスをロード／登録／登録解除／アンロードし、カスタム・オブジェクトを操作するためにクラス・インターフェース・コードにアクセスする機構が提供される。ＯＯＭの設計及び実装では、ＪａｖａＳｃｒｉｐｔオブジェクト・モデルを使用して、労力の重複を避ける。ＯＯＭによって、ＪａｖａＳｃｒｉｐｔ及びＣプログラムの両方がオブジェクトを操作するインターフェースが提供される。ＨＴＭＬ、ＯＯＭ、及びＣのプログラムはＪａｖａＳｃｒｉｐｔなしで機能する。本発明は選択されたネーミング方式を有する軽量クライアント側クラス・レジストリを提供する。レジストリによって、クラス・モジュールを名前及びルックアップに関連付けることができる。ＯＯＭによって、クラス・モジュールがロードされ、そのモジュールが登録される。クラスに関するインターフェースは１つだけある。オブジェクト・プロトタイプ・プロパティは動的に束縛されない。このインターフェースには、メソッドだけが含まれる。各メソッドは、このインターフェースのスコープ内で一意のストリング名に関連する。ＯＯＭによって、クラス及びＰｒｏｖｉｄｅクラス参照機構からオブジェクト・インスタンスを作成する機構が提供される。ＯＯＭは、クラスのアンロードを処理する。ＯＯＭでは、Ｈ２Ｏ ＨＴＭＬとＪａｖａＳｃｒｉｐｔエンジンの間の制御フロー及びデータ・フローが定義される。ＯＯＭによって、ＪａｖａＳｃｒｉｐｔエンジンのブラウザ・オブジェクトがインスタンス化される。ＯＯＭによって、ＤＯＭオブジェクトのアクセスが、ＪａｖａＳｃｒｉｐｔエンジンに公開される（実装チューニングを伴うウィンドウ・オブジェクトのグローバル変数プロパティのプロパティ設定を介して）。あるクラスのオブジェクトは、そのメソッド・プロパティがクラス・インターフェースのメソッドであるオブジェクトである。ＯＯＭでは、ビュー構造体、ビュー更新、イベント処理、フォーカス、及び共用システム・リソースへのアクセスにカスタム・オブジェクトを統合するＳＤＫ ＡＰＩのインターフェース、ガイドライン、サブセットが定義される。

コントローラが、ブラウザの挙動及び構成要素を制御し、イベントを処理する。このコントローラは、スタートアップ中のビジュアル表示などのさまざまな技法によって達成される高速スタートアップ時応答を提供する。本発明の好ましいコントローラでは、システム・リソースすなわち、イベント、ダウンロード、ｍｐｅｇ、ｏｓｄ、Ａ／Ｖなどが使用され、データ・モデル及び視聴が制御される。このコントローラは、生のＯｐｅｎＴＶイベント２１４６を処理する。このコントローラは、プリミティブ・オブジェクト・イベントを処理し、このイベントによって、ＤＯＭイベント２１４０及び２１３４を生成することができる。本発明は、ＤＯＭイベント２１３８のバブリング及び処理をサポートし、開始ノードとしてフォーカスがあるノードを使用する。ＤＯＭイベントは、ＪａｖａＳｃｒｉｐｔイベント・ハンドラ２１３８コードによって処理することができる。

文書ツリー、イベント・プロパティ、及びスタイル（長方形）を使用してフォーカス・イベントを処理し、曖昧さを処理するフォーカス・ナビゲーション・ハンドラ２１４８が本発明によって提供される。オブジェクト識別子及びｘ、ｙ位置によってフォーカス・ヒストリを記録し、最適の一致を見つける。コントローラによって、イベント・ディスパッチ、イベント処理、データ更新、及びビュー更新の制御フローが定義されることが好ましい。

好ましいコントローラによって、要素クラスが事前に定義され、したがって、好ましいコントローラは、カスタム・クラスより効率的である。コントローラは、ＵＲＩリトリーバを使用して、ＵＲＩコンテンツを入手し、ＨＴＴＰ：ｇｅｔ及びｐｏｓｔ（ｆｏｒｍ ｐｏｓｔ）要求を行い、応答を入手し、文書のオープン機能及び後退／前進機能を提供する。好ましい実施形態では、データ・モデルが、主に、ランタイムＨＴＭＬ ＤＯＭ及びランタイム・データ・モデルの他のカテゴリである。ＨＴＭＬ ＤＯＭには、所期の効果を反映する視聴情報も含まれる。

データ・モデルによって、文書ソースから開始することができる単一のランタイムＨＴＭＬ文書が処理され、前の文書が破壊される。データ・モデルでは、データ・モデルのロード／インスタンス化／参照／操作／破壊がサポートされることが好ましい。本発明では、データをシリアライズし、文書の間でデータを共用するために、持続的なデータ保存／読取が提供される。好ましい実施形態では、視聴が、実際に、データ・モデルのＵＩルックを反映し、主に、ＨＴＭＬ ＤＯＭの実際のスタイルを反映する。視聴機能性は、主に内部で定義される形状を使用して、データ・モデルに緊密に組み込まれる。ＨＴＭＬページでは、それがどの視聴オプションを使用するかが正確に指定される。本発明では、画面の寸法及び比率、色、及びｍｐｅｇ特性などの特定の視聴制限が定義される。１つのランタイムＨＴＭＬ文書に１つの好ましいビューがある。

視聴では、異なるカラー・スタイルがサポートされることが好ましく、カラー・テーブルが共用リソースとして扱われる。好ましい実施形態では、ＭＩＭＥタイプ・ハンドラの制限された組が、メモリを節約するために、構成に応じて提供される。ＰＣ環境用の人気のあるＨＴＭＬブラウザでは、操作するために、通常は、ＪａｖａＳｃｒｉｐｔランタイム用のブラウザ固有のホスト・オブジェクトが公開される。本発明では、ＪａｖａＳｃｒｉｐｔランタイム用のＭｉｃｒｏｓｏｆｔ ＩＥ５ホスト・オブジェクトのサブセットがサポートされる。

トランスコーダは、次のようにパーサ・エンジンを呼び出す：
HTMLengine_parse_html(C_MIME_HTML *p_in_html_text, C_ELEMENT_TREE **pp_out_element_tree)。Ｃ＿ＥＬＥＭＥＮＴ＿ＴＲＥＥによって、パーサ・エンジンによって生成される内部要素ツリーがカプセル化される。パーサ・エンジンでは、ＡＰＰＬＥＴ、ＢＤＯ、ＦＩＥＬＤＳＥＴ、ＦＲＡＭＥ、ＦＲＡＭＥＳＥＴ、ＩＦＲＡＭＥ、ＩＳＩＮＤＥＸ、ＬＡＢＥＬ、ＬＥＧＥＮＤ、Ｑ、Ｓ、ＳＴＲＩＫＥ、Ｕをディスエーブルするための正しいアプローチを見つける。

パーサ・エンジン、機能性は、拡張要素を解析し、拡張要素ノードを生成するために設けられる。内部クライアント互換拡張要素には、カルーセルのリンク属性、表示メタデータ（ＮＴＳＣ／ＰＡＬ、ＭＰＥＧ背景／スライス、ＯＳＤ領域）、カラー・テーブル・スタイル（カラー・ビット数、カラー・ネーム／インデックス・マッピング）、フォント（ＯｐｅｎＴＶフォント・ファイルからのフォント情報の読取）が含まれる。

トランスコーダは、次のようにレイアウトのＵＲＩ参照を発見し、要求する：
int HHTM_resolve_referenced_uri(C_ELEMENT_TREE *p_in_element_tree);
好ましいトランスコーダは、int MIME_image_handler MIME_TYPE in_type, char *p_in_uri, URI_INFO **pp_out_uri_info)を呼び出す。トランスコーダは、要素ツリーをトラバースし、必要な時にＵＲＩ及び処理オプション（たとえば、寸法オプション及びＮＴＳＣ／ＰＡＬ比率オプションと共に、イメージをｍｐｅｇスライスに変換するかどうかとその方法）を用いてＭＩＭＥハンドラを呼び出し、イメージの幅及び高さ、フォント、及びカラー・テーブルなどの情報を要素ノードに書き込むことが好ましい。ＭＰＥＧスライスになるイメージ及び判定されないその位置について、本発明は、イメージ要素属性ｓｉｚｅを拡張して、幅と高さの両方でモジュロ１６画素を達成する。

本発明は、Ｈ２Ｏ ＪａｖａＳｃｒｉｐｔタイプ・ハンドラを呼び出す。ＪＳハンドラは、要素ツリーをトラバースして、ＪａｖａＳｃｒｉｐｔグローバル・コード、関数、外部スクリプトのリンク参照、オブジェクト・クラス・リンク参照、及びホスト・コードを収集する（イベント・ハンドラ属性から）。Ｈ２Ｏ ＪａｖａＳｃｒｉｐｔハンドラを呼び出し、そのコレクションを渡す。ＪａｖａＳｃｒｉｐｔハンドラ・タスクは、スクリプト及びクラスＭＩＭＥコンテンツを取り出し、ＪＳ２Ｏ ＪａｖａＳｃｒｉｐｔコンパイラを呼び出し、このコンパイラは、コンパイルされたＪａｖａＳｃｒｉｐｔコードを含むクライアント互換コード・モジュールを返す。スクリプト・コレクションは、コードへのハンドルを担持する。この関数は、次のように呼び出される：
int HHTM_collect_script (C_ELEMENT_TREE *p_in_element_tree, C_SCRIPT_COLLECTION **pp_out_script_collection);
HJS: Ｈ２ＯトランスコーダＪａｖａＳｃｒｉｐｔタイプ・ハンドラ。
int HJS_handler_handle_script(C_SCRIPT_COLLECTION *p_in_script_collection, C_JS_CODE_MODULE **pp_out_js_code_module);

レイアウト・エンジンは、次のように呼び出される：
Int HTMLengine_layout_html(C_ELEMENT_TREE *p_in_element_tree, C_OTV_STYLE_RULES *p_in_default_style);

レイアウト・エンジンは、要素ツリー内の情報及びレイアウトに関するそれ自体のスタイル構成機構を使用する。デフォルト・スタイルは、レイアウト・エンジンのスタイル構成及びレイアウト・ターゲット・ビューに転送される。スタイル構成は、スタイル情報を要求するコールバックの形をとることができる。レイアウト・エンジンは、レイアウト結果を要素ツリーに保管する。レイアウト・エンジンは、要素ツリーをトラバースし、スタイル・ボックス・モデルなどの別のデータ・モデルを生成することができる。レイアウト・エンジンは、特定の要素ノードについて計算されたＣＳＳ情報をインターセプトし、対応する要素ノードを見つけ、制限されたカスケーディング・スタイル情報を有するインライン・スタイルとして、スタイル結果を特定の要素ノードに保管することができる。

レイアウト結果には、必要なスタイル情報（位置、色、フォント、背景）が含まれる。位置スタイルは絶対位置スタイルに変換される。レイアウト・エンジンは、すべてのアンカ情報をトラバースする。必要な場合に、レイアウト・エンジンは、アンカ情報を修正して、最初のボックス又はイメージだけをアンカとして使用する。レイアウト・エンジンは葉ノードをトラバースし、相互作用できる（クリック・イベント、キー押下げイベント、ブラー・イベント、フォーカス・イベントを処理できる）葉ノードをフォーカス可能としてマークする。

トランスコーダは、要素ノード・ツリーをトラバースし、内部クライアント互換リソース・ジェネレータを使用して、Ｈ２Ｏトランスコードを生成する。本発明では、構成要素、ディスプレイ、スタートアップなどが構成される。静的構成及び動的構成は、コンパイル時に静的に判定される。本発明は、Ｈ２Ｏブラウザを初期化する。本発明では、まず、コントローラが初期化され、そのコントローラが、ＯＯＭ、ＤＯＭ、ＪＳ２Ｏランタイムを初期化し、イベント・ループ及びイベント・ハンドラを登録し、ＵＲＩリトリーバを初期化し、イメージ・ライブラリを初期化し、ビュー・オプションを読み取り、ホスト・オブジェクトを初期化する。

本発明はＤＯＭ組込みクラスを提供する。ルート・クラスは関数のコレクションとして実装され、すべてのＤＯＭノード・オブジェクト・インスタンスは、ルート・クラスが動作するために計画された共通のデータ・メンバを有する。関数ポインタは、メソッド・アトム照会をオンに切り替え、関数ポインタを返すｖｔａｂｌｅ事前定義関数によって得られる。イベント・ハンドラは、イベント・タイプによって参照されるＪＳイベント・ハンドラ関数ポインタのリストである。特定の制御要素クラスが、関数のコレクションとして実装され、すべてのＤＯＭノード・オブジェクト・インスタンスは、ルート・クラスが動作するために計画された共通のデータ・メンバを有する。

以下は、Ｈ２Ｏアーキテクチャ及びサンプル・トランザクションの論理ビューを使用するＨ２Ｏプロキシ環境の概要である。ＵＲＩに関する要求は、異なるＨ２Ｏ構成要素、たとえばＳＴＢ／ＳＶＷ及びカルーセルから来る可能性がある。以下のコンテキスト概要では、要求を発行するＳＴＢ／ＳＶＷに焦点を合わせるが、情報の全般的な流れは、同一である。

視聴者が、そのテレビジョン・ウェブ・ページと対話することを選択し、したがって、ＳＴＢからＨ２Ｏシステムに要求を発行し、応答を待つ。ＳＴＢ要求は、トランスポート・プロトコルとしてのＤＡＴＰメッセージにカプセル化された軽量ＨＴＴＰ要求（ＬＨＴＴＰ）を使用して、ＳＧＷに送られる。要求されたオブジェクトが、同一のチャネル及びプロトコルを介して返される。ＳＧＷは、ＬＨＴＴＰプロトコルを標準的なＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰに変換し、その要求をウェブ・キャッシュに発行する。

コンパイル済みオブジェクト・キャッシュ（Ｃｏｍｐｉｌｅｄ Ｏｂｊｅｃｔ Ｃａｃｈｅ、ＣＯＣ）は、その内部ディスク空間を使用して、サービスできるすべての要求をサービスする（オブジェクトの生存期間を考慮に入れたヒューリスティックに続いて）。その役割は、Ｈ２Ｏプロキシに照会せずに、したがってＨ２Ｏプロキシの処理負荷を減らしながら、すべての静的オブジェクト（照会なしのポスト形式でない標準ＵＲＬ）をサービスすることである。このアーキテクチャでは、ＣＯＣが、コンパイル済みオブジェクト（Ｈ２Ｏモジュール）だけを保管する。ＣＯＣマシンは入出力駆動である。

図７に移ると、Ｈ２Ｏプロキシ２４８は、異なるＨ２Ｏコンパイラ（又はフィルタ）が稼動するスケーラブルな環境を提供する。Ｈ２Ｏプロキシは、ＨＴＴＰ要求及び応答を「オン・ザ・フライ」で処理しており、したがって、Ｈ２Ｏプロキシ・マシンは、処理駆動である。Ｈ２Ｏ ＨＴＭＬコンパイラ１４２０は、ＨＴＭＬからＳＰへのリソース・コンパイルを担当する。レンダラ１４２２へのテレビジョン・レイアウトを計算するために、この構成要素は、組み込まれたイメージのサイズに基づいて、自動的にＨＴＴＰ要求を発行する。このコンパイラは、クライアント表示デバイス、たとえばテレビジョンにおさまるように、ウェブ・ベースのイメージを再配置する。

ＭＰＥＧコンパイラ１４２６は、通常のウェブ・イメージ・フォーマットからＳＰ Ｈ２９ ＭＰＥＧリソースへの変換を指示する。ソース・フォーマットに、ＪＰＥＧ及びＧＩＦが含まれ、ＰＮＧを含めることができる。ＵＲＬを介する引数渡しによって、変換処理を駆動することができる。ＰＩＸＭＡＰコンパイラは、通常のウェブ・イメージからＳＰ Ｈ２Ｏリソースへの変換を担当する。ソース・フォーマットに、ＧＩＦが含まれ、ＰＮＧを含めることができる。

要求パッチャ１４２４は、要求又は応答を完了するか修正して、別のシステムから来るデータ（たとえばクレジット・カード番号）を組み込む。要求パッチャ１４２４は、外部のプロセス又はデータベースと通信して、顧客情報を取り出す。ＳＰ構成要素は、ユーザ情報の中央リポジトリを提供する。要求パッチャは、この構成要素と通信して、要求又は応答をパッチするのに必要なデータを得る。

コンパイルされないオブジェクト・キャッシュ１４３０は、その内部ディスク空間を使用して、サービスできるすべての要求をサービスする（オブジェクトの生存期間を考慮に入れたヒューリスティックに続いて）。キャッシングされるオブジェクトには、静的ＨＴＭＬ、ＧＩＦイメージ、ＪＰＥＧイメージ、及びすべての標準ウェブ・フォーマット・ファイルが含まれる。その役割は、インターネットに照会せず、したがって、オブジェクトを得る待ち時間を減らし、ある種のフォールトトレランスをシステムに与えながら、すべての静的オブジェクト（照会なしのポスト形式でない標準ＵＲＬ）をサービスすることである。顧客ウェブ・サイトは、Ｈ２Ｏシステムを介する公開のためにウェブ・サイトを保持する。

図８に、既にキャッシングされた静的ページに関する要求を示す。ＳＴＢユーザが、ＨＴＭＬページをロードする要求を発行する１５２０。この要求は、ＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰを使用してＳＧＷ２４８に送られる。ＳＧＷは、この要求をＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰに変換し、コンパイル済みオブジェクト・キャッシュ１４１０に転送する１５２２。コンパイル済みオブジェクト・キャッシュ１４１０は、その内部ハード・ディスク空間に保管された要求された（モジュールにコンパイルされた）ＨＴＭＬページを有する。オブジェクトの生存期間が満了していない場合に、コンパイル済みオブジェクト・キャッシュは、コンパイルされたＨＴＭＬページを用いて要求をサービスする。コンパイル済みオブジェクト・キャッシュは、ＨＴＴＰ応答１４２４を、ＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰを使用してＳＧＷに送信する。ＳＧＷは、プロトコルをＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰからＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰに変換する。ＳＴＢは、要求されたページ１５２６（コンパイル済み）をそのメモリにロードし、解釈のために、これをＨ２Ｏブラウザ・エンジンに与える。Ｈ２Ｏブラウザ・エンジンは、ＳＧＷに、ｕｒｌに対する変換オプション（ｍｐｅｇ又はｐｉｘｍａｐ、幅、高さなど）と共に、テレビジョンの画面をレンダリングするのに必要なイメージを得るように要求する１５２８。ＳＧＷは、コンパイル済みオブジェクト・キャッシュにＨＴＴＰ要求を送る１５３０。コンパイル済みオブジェクト・キャッシュは、その内部ハード・ディスク空間に保管された要求された（モジュールにコンパイルされた）イメージを有する。オブジェクト生存期間が満了しておらず、コンパイル済みオブジェクト・キャッシュは、コンパイルされたイメージを用いて要求をサービスする１５３２、１５３４。このシナリオでは、Ｈ２Ｏプロキシが、要求を容赦され、したがって、他の要求を処理することができる。

図９からわかるように、ＳＴＢ２１２のユーザは、ＨＴＭＬページ（ｈｏｍｅ．ａｓｐ）をロードする要求を発行し１６１０、要求ヘッダのホスト及びユーザ情報に、ＳＴＢモデル＋ＳＴＢ通し番号及びユーザのアクセス・カードＩｄが保持される。この要求１６１０は、ＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰを使用してＳＧＷに送られる。ＳＧＷは、この要求をＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰに変換し、コンパイル済みオブジェクト・キャッシュに転送する１６１２。要求されたオブジェクトは、ウェブ・キャッシュのディスク空間内で使用できない。ウェブ・キャッシュは、この要求をＨ２Ｏプロキシに転送する１６１４。Ｈ２Ｏプロキシは、ＳＰにユーザの名前（Ａｍａｚｏｎ．ｃｏｍサービスに関する）を返す１６２０ように要求する１６１６。Ｈ２Ｏプロキシは、ユーザの名前を用いて要求をパッチし、この要求を「コンパイルされないオブジェクト・キャッシュ」に発行する１６２２。「コンパイルされないオブジェクト・キャッシュ」は、そのディスク空間内に要求されたＨＴＭＬページを保持せず、したがって、ターゲットのウェブ・サーバ、ここではＡｍａｚｏｎ．ｃｏｍに要求を発行する１６２４。ターゲットのウェブ・サーバは、ユーザ情報を与えられてＨＴＭＬページを計算し、そのページを「コンパイルされないオブジェクト・キャッシュ」に返す１６２６。コンパイルされないオブジェクト・キャッシュ」は、そのＨＴＭＬページをＨ２Ｏプロキシに返す１６２８。

Ｈ２Ｏプロキシは、ＨＴＴＰ要求を「コンパイルされないオブジェクト・キャッシュ」に送って１６３０、レイアウト計算に必要なイメージ（ｇｉｆ、ｊｐｅｇなど）を得る１６３２、１６３４、１６３６。Ｈ２Ｏプロキシは、ＨＴＭＬページをコンパイルする、すなわち、レイアウトを計算し、埋め込みイメージｕｒｌをパッチし、結果のＯｐｅｎＴＶリソースを（ＳＰリソースｍｉｍｅタイプと共に）「コンパイル済みオブジェクト・キャッシュ」に送り返す１６４６。コンパイル済みオブジェクト・キャッシュは、オブジェクトをその内部ディスク空間に保管し、コンパイル済みＨＴＭＬページをＳＧＷに送り返す１６４８。ＳＧＷは、応答をＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰに変換し、ＳＴＢに送り返す１６５０。ＳＴＢは、要求されたオブジェクトをそのメモリにロードし、解釈のためにＨ２Ｏブラウザに与える。

Ｈ２Ｏブラウザ・エンジンは、ＳＧＷに要求を発行して１６５２、レンダリングに必要なイメージ（パッチされたｕｒｌを介して：ここではｌｏｇｏ．ｇｉｆ ｕｒｌに、ｐｉｘｍａｐリソース・フォーマットのディレクティブが含まれる）：ｐｉｘ／ｌｏｇｏ．ｇｉｆを得る。ＳＧＷは、この要求をＨＴＴＰ ｏｖｅｒ ＴＣＰ／ＩＰに変換し１６５２、コンパイル済みオブジェクト・キャッシュに転送する。「コンパイル済みオブジェクト・キャッシュ」は、既に、正しいフォーマットの要求されたｇｉｆイメージを有し（ユーザが前にこのイメージを既に要求しているので）、イメージが、ＳＧＷに直接に返される１６５４。ＳＧＷは、応答をＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰに変換し、ＳＴＢに送り返す１６５６。Ｈ２Ｏブラウザ・エンジンは、ＳＧＷに要求を発行して１６５８、レンダリングに必要なイメージｍｐｇ／ｂａｎｎｅｒ．ｊｐｇを得る。「コンパイル済みオブジェクト・キャッシュ」は、そのディスク空間に要求されたイメージを保持せず、したがって、Ｈ２Ｏプロキシに要求を発行する１６６０。Ｈ２Ｏプロキシは、ＨＴＴＰ要求を「コンパイルされないオブジェクト・キャッシュ」に送って１６６２、／ｂａｎｎｅｒ．ｊｐｇイメージを得る。

「コンパイルされないオブジェクト・キャッシュ」は、そのキャッシュにそのイメージを保持し、Ｈ２Ｏプロキシに即座にそのイメージを返す１６６４。Ｈ２Ｏプロキシは、ｕｒｌで与えられるパラメータ（ｍｐｇフォーマット、幅、高さなど）を使用してイメージを変換し、その結果をコンパイル済みオブジェクト・キャッシュに返す１６６８。コンパイル済みオブジェクト・キャッシュは、そのオブジェクトを内部ディスク空間に保管し、変換されたｍｐｅｇイメージをＳＧＷに送り返す１６６８。ＳＧＷは、応答をＬＨＴＴＰ ｏｖｅｒ ＤＡＴＰに変換し、ＳＴＢに送り返す１６７０。ＳＴＢは、ＨＴＭＬページを画面にレンダリングする。

Ｈ２Ｏプロキシ構成要素は、他のＨ２Ｏ構成要素又はコンパイラに、堅牢でスケーラブルなアーキテクチャ、「コンパイラ」構成用のインターフェース、及びエラーをログ記録する能力を与える。定義されたイベントの際に管理者に警告する能力；及び、「コンパイラ」をデバッグトレースする能力。提供されるＨ２Ｏプロキシ環境及びＡＰＩから、コンパイラは、ＨＴＴＰ要求及び応答をオン・ザ・フライで「パッチ」し、最終的に、外部のデータベース、ファイル、又はプロセスにアクセスしてそれを行う。コンパイラは、特定のＨＴＴＰヘッダ（ＳＴＢ識別子、アクセス・カード識別子など）を除去することによって、特定のＨＴＴＰヘッダ（ユーザ名、クレジット・カード番号など）を追加することによって、着信ｐｏｓｔ要求にＨＴＭＬ Ｆｏｒｍフィールド（Ｖｉｓａカード番号など）を追加することによって、及び文字列置換（＄ＵＩＤ＄→ユーザ識別子）を実行することによって、ＨＴＴＰ要求をパッチし、コンパイラは、ウェブ・オブジェクト・フォーマット及びｍｉｍｅタイプを「オン・ザ・フライ」でＨＴＴＰ応答に変換し、自動的にＨＴＴＰ要求を発行し、その代わりに応答オブジェクトを得る。

図１０からわかるように、好ましい実施形態では、Ｈ２Ｏプロキシが、それを囲むソフトウェア（ウェブ・プロキシ、ファイヤウォール、ウェブ・サーバ、又は他のソフトウェア）の拡張を開発することによって実装される。このホスト・ソフトウェアは、Ｈ２Ｏスレディング及びＨ２Ｏタスクのスケジューリング、ならびに、Ｈ２Ｏ「コンパイラ」構成要素及びパッチング構成要素を実装するのに必要な機能性の一部を提供する。

プロキシ・ホスト・ソフトウェアによって提供されるＡＰＩを使用して、ＡＰＩの組（Ｈ２ＯプロキシＡＰＩ）を提供して、Ｈ２Ｏプロキシ・ホスト・ソフトウェア・サービスに欠けている、Ｈ２Ｏコンパイラが必要とする機能性を実装し、Ｈ２Ｏプロキシ・ホスト・ソフトウェアから使用可能なサービスのより高度な抽象レベルを提供する。要求パッチャ１４２４構成要素は、ＨＴＭＬページに関する着信ＨＴＴＰ要求を読み取り、別のプロセス又はファイル又はデータベースからの情報を用いてその要求を完了する。ＨＴＭＬ２ＲＥＳコンパイラ１４２０は、返されたＨＴＭＬページをＳＰリソース・ファイルにコンパイルし、ＨＴＴＰ応答ヘッダのｍｉｍｉタイプを、新しいフォーマット：Ｍｉｍｅ−Ｔｙｐｅ：ｔｅｘｔ／ｏｔｖｒｅｓに合うように変更する。

ＧＩＦ２ＰＩＸコンパイラ１４２２は、返されたＧＩＦイメージをＳＰリソース・ファイルに変換し、ＨＴＴＰ応答ヘッダのｍｉｍｅタイプを、新しいフォーマット：Ｍｉｍｅ−Ｔｙｐｅ：ｉｍａｇｅ／ｏｔｖｐｉｘに合うように変更する。２ＭＰＥＧコンパイラ１４２６は、返されたＧＩＦイメージ又はＪＰＥＧイメージをＳＰリソース・ファイルに変換し、ＨＴＴＰ応答ヘッダのｍｉｍｅタイプを、新しいフォーマット：Ｍｉｍｅ−Ｔｙｐｅ：ｉｍａｇｅ／ｏｔｖｍｐｇに合うように変更する。

図１１に移ると、ＨＴＭＬページ・シーケンス図に関する動的要求が示されている。オブジェクト・キャッシュは、このシーケンス図に示されておらず、この相互作用の「受動的」構成要素である。ユーザＳＴＢ２１２が、ＨＴＴＰ要求を介してページ（ｈｏｍｅ．ａｓｐ）の要求を発行する１８１０。要求パッチャ１４２４は、外部プロセス／ファイル／データベース／ｕｒｌにアクセスして１８１２、１８１４、ユーザ名を入手し、要求をパッチし、ＨＴＭＬ２ＲＥＳコンパイラに送る１８１６。ＨＴＭＬ２ＲＥＳコンパイラは、その要求をターゲット・ウェブ・サイト（ａｍａｚｏｎ．ｃｏｍ）に送る１８１８。ウェブ・サイトは、要求を計算し、結果のＨＴＭＬページをＨＴＭＬ２ＲＥＳコンパイラに送り返す１８２０。ＨＴＭＬ２ＲＥＳコンパイラは、ファイルを解析してイメージ・リンクＵＲＬを入手し、ウェブ・サイトに要求を発行して１８２２、イメージ・ファイル（ｌｏｇｏ．ｇｉｆ、ｂａｎｎｅｒ．ｊｐｇ）を得る１８２４。ＨＴＭＬ２ＲＥＳコンパイラは、ページのテレビジョン・レイアウトを計算し、ＳＰリソース・ファイルにコンパイルし、ＳＴＢに送り返す１８３０。ＳＴＢは、ＨＴＭＬページをテレビジョンにレンダリングする。

図１２に移ると、イメージ・ファイルの要求、シーケンス図が示されている。ユーザＳＴＢにロードされたＨＴＭＬページが、その画面をレンダリングするためにイメージを必要とする。２ＭＰＧコンパイラに、イメージ（ＵＲＬ組込み変換オプション）に関するＨＴＴＰ要求が発行される１９１０。２ＭＰＧコンパイラは、ターゲット・サイト（ａｍａｚｏｎ．ｃｏｍ）にイメージを要求する１９１２。ターゲット・サイトは、ｂａｎｎｅｒ．ｊｐｇイメージ・ファイルを２ＭＰＧコンパイラに返す１９１４。２ＭＰＧコンパイラは、ＵＲＬで与えられたオプションを使用してｂａｎｎｅｒ．ｊｐｇファイルを変換し、その結果を、ｉｍａｇｅ／ｏｔｖｍｐｇ ｍｉｍｅ−ｔｙｐｅと共にＳＴＢに返す１９１６。ＳＴＢは、イメージを画面にレンダリングする。

図１３からわかるように、標準ＨＴＭＬ１３０２は、ページ指向のページ固有プレゼンテーション用に設計され、ＨＴＭＬによって、各ＨＴＭＬ要素がページのどこに配置されるかが正確に指定される。標準ＨＴＭＬ入力では、ＪＰＥＧ、ＰＮＧ、又は他のビット・マップ指向イメージ・フォーマットを使用して、ウェブ・ページ及びコンテンツを表す。本発明では、ＭＰＥＧ及びレイアウト・パラメータを使用して、クライアント・デバイスでの表示用のページ上のイメージ１３０４を表す。

ＭＰＥＧは、モジュロ１６位置の位置決めを必要とし、したがって、本発明は、イメージのＭＰＥＧ表現を囲むバッファを提供して、ＭＰＥＧイメージ１３０４のｘ位置１３１０及びｙ位置１３１２が、バッファ空間１３０６内でモジュロ１６に位置合せされるように調整されることを確実にする。元のＨＴＭＬイメージの境界の原点１３０８は、モジュロ１６位置合わせされていない場合がある。クライアント・デバイスで表示されるＭＰＥＧイメージの原点及びサイズは、モジュロ１６でなければならないので、元のＨＴＭＬイメージの原点及びサイズを、図１３に示されているように、モジュロ１６に調整する。レイアウト・エンジンは、元のＨＴＭＬイメージより大きい、大きいバッファ・サイズを考慮に入れて、クライアント・ディスプレイでの他のページ要素とのオーバーラップを避ける。しかし、このモジュロ１６バッファ空間によって、イメージが元のサイズより大きくなる。したがって、より大きいイメージ・サイズが、そのイメージに隣接するテキスト又は他の画像とオーバーラップしないように、レイアウト・エンジンによってバッファ・サイズが考慮される。ＭＰＥＧ表現によって、本発明が、クライアント・デバイスでの表示のためにＭＰＥＧ背景の上でＭＰＥＧイメージを移動できるようになる。したがって、レイアウト・エンジンは、クライアント表示空間でのオーバーラップを避けるために、ＨＴＭＬレイアウトに厳密には従わない場合がある。

本発明を、好ましい実施形態の双方向テレビジョンで説明したが、本発明は、サーバ及びクライアント・デバイスを含む分散コンピュータ・システムでも実施することができる。もう１つの実施形態では、本発明が、現在既知又は未知である、ＲＯＭ、ＲＡＭ、ＣＤ ＲＯＭ、フラッシュ、又は他のコンピュータ可読媒体を含むコンピュータ可読媒体上の、実行される時にコンピュータに本発明の方法を実施させる命令の組として実施される。

コンテンツをクライアント・デバイスに供給するヘッド・エンドを示す図である。 コンテンツをクライアント・デバイスに供給するヘッド・エンドを示す図である。 コンテンツをクライアント・デバイスに供給するヘッド・エンドを示す図である。 コンテンツをクライアント・デバイスに供給するヘッド・エンドを示す図である。 Ｈ２Ｏ ＨＴＭＬトランスコーダ・アーキテクチャを示す図である。 Ｈ２Ｏブラウザの処理及びデータ・フローを示す図である。 コンテンツ変換用のアーキテクチャ、Ｈ２Ｏを示す図である。 クライアント／ＳＴＢ、Ｈ２Ｏ、及びアプリケーション・サービス・プロバイダの間の競争の提供及び表示のシナリオを示す図である。 クライアント／ＳＴＢ、Ｈ２Ｏ、及びアプリケーション・サービス・プロバイダの間の競争の提供及び表示のシナリオを示す図である。 クライアント／ＳＴＢ、Ｈ２Ｏ、及びアプリケーション・サービス・プロバイダの間の競争の提供及び表示のシナリオを示す図である。 クライアント／ＳＴＢ、Ｈ２Ｏ、及びアプリケーション・サービス・プロバイダの間の競争の提供及び表示のシナリオを示す図である。 クライアント／ＳＴＢ、Ｈ２Ｏ、及びアプリケーション・サービス・プロバイダの間の競争の提供及び表示のシナリオを示す図である。 クライアント・デバイスでの表示のための、標準ＨＴＭＬイメージのモジュロ１６（ｍｏｄｕｌｏ １６）ＭＰＥＧイメージへの変換を示す図である。

Claims (2)

1. 少なくとも１つのサーバと１つのクライアント・デバイスを含む分散コンピュータ・システムで表示のためにコンテンツをフォーマットする方法であって、
   前記サーバで、オリジナル・イメージを含むコンテンツをサービス・プロバイダから受け取るステップと、
   パーサ・エンジンで、レイアウト・パラメータを含むＨＴＭＬオリジナル・イメージ情報を前記コンテンツから抽出するステップと、
   ＭＰＥＧイメージを形成するために前記オリジナル・イメージをＭＰＥＧフォーマットに変換するステップであって、前記ＭＰＥＧイメージの寸法が両方ともモジュロ１６であるのに必要な最小量だけ、オリジナル・イメージのｘ寸法及びｙ寸法であるＸ＿ｏｒｉｇｉｎａｌ及びＹ＿ｏｒｉｇｉｎａｌを拡大することにより前記オリジナル・イメージのサイズを変えるステップを含むステップと、
   前記ＭＰＥＧイメージのｘ寸法及びｙ寸法が画素バッファと共にモジュロ１６であり、Ｘ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ及びＹ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙがバッファ・スペースの寸法であり、そして（１６＜＝Ｘ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ−Ｘ＿ｏｒｉｇｉｎａｌ＜３２）かつ（１６＜＝Ｙ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ−Ｙ＿ｏｒｉｇｉｎａｌ＜３２）であるように、ＭＰＥＧイメージの境界に画素バッファを加えることにより前記ｘ寸法及びｙ寸法で前記バッファ・スペースを計算するステップであって、
   前記オリジナル・イメージ・レイアウト・パラメータと前記ＭＰＥＧイメージをレイアウト・エンジンに渡すステップと、
   前記バッファ・スペースの少なくとも１つのｘおよびｙ座標が前記オリジナル・イメージの前記オリジナルｘおよびｙ座標と整列するようにクライアント・デバイスのディスプレイの位置に前記バッファ・スペースを位置付けるステップと、
   付加的イメージ・コンテンツが前記バッファ・スペースとオーバラップしないように前記ＭＰＥＧイメージ以外の前記付加的イメージ・コンテンツを前記クライアント・デバイスでの表示のために位置付けるステップと、
   前記ＭＰＥＧイメージのｘ寸法およびｙ寸法がモジュロ１６に整列されるように前記クライアント・デバイスでの表示のためにレイアウト・エンジン内で前記ＭＰＥＧイメージを位置決めするステップと、
   ユーザへの表示のために、前記位置決めされたイメージを前記クライアント・デバイスに送るステップと、
   カスケーディング・スタイル・シート（ＣＳＳ）を要素ノード・ツリーに変換するステップと、そして
   前記要素ノード・ツリーを前記クライアント・デバイスに送信するステップと
   を含む方法。
2. 少なくとも１つのサーバと１つのクライアント・デバイスを含む双方向テレビジョン・システムで表示のためにコンテンツをフォーマットする方法であって、
   前記サーバで、オリジナル・イメージを含むコンテンツをサービス・プロバイダから受け取るステップと、
   パーサ・エンジンで、レイアウト・パラメータを含むＨＴＭＬオリジナル・イメージ情報を前記コンテンツから抽出するステップであって、前記ＭＰＥＧイメージの寸法が両方ともモジュロ１６であるのに必要な最小量だけ、オリジナル・イメージのｘ寸法及びｙ寸法であるＸ＿ｏｒｉｇｉｎａｌ及びＹ＿ｏｒｉｇｉｎａｌを拡大することによりオリジナル・イメージのサイズを変えるステップを含むステップと、
   前記ＭＰＥＧイメージのｘ寸法及びｙ寸法が画素バッファと共にモジュロ１６であり、Ｘ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ及びＹ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙがバッファ・スペースの寸法であり、そして（１６＜＝Ｘ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ−Ｘ＿ｏｒｉｇｉｎａｌ＜３２）かつ（１６＜＝Ｙ＿ｍｏｄｉｆｉｅｄ＿ｂｏｕｎｄａｒｙ−Ｙ＿ｏｒｉｇｉｎａｌ＜３２）であるように、前記ＭＰＥＧイメージの境界に前記画素バッファを加えることによりｘ寸法及びｙ寸法で前記バッファ・スペースを計算するステップと、
   前記オリジナル・イメージ・レイアウト・パラメータと前記ＭＰＥＧイメージをレイアウト・エンジンに渡すステップと、
   前記バッファ・スペースの少なくとも１つのｘおよびｙ座標が前記オリジナル・イメージのオリジナルｘおよびｙ座標と整列するように前記クライアント・デバイスのディスプレイの位置に前記バッファ・スペースを位置付けるステップと、
   付加的イメージ・コンテンツが前記バッファ・スペースとオーバラップしないように前記ＭＰＥＧイメージ以外の前記付加的イメージ・コンテンツを前記クライアント・デバイスでの表示のために位置付けるステップと、
   前記ＭＰＥＧイメージのｘ寸法およびｙ寸法がモジュロ１６に整列されるように前記クライアント・デバイスでの表示のためにレイアウト・エンジン内で前記ＭＰＥＧイメージを位置決めするステップと、
   ユーザへの表示のために、位置決めされたイメージを前記クライアント・デバイスに送るステップと
   カスケーディング・スタイル・シート（ＣＳＳ）を要素ノード・ツリーに変換するステップと、そして
   前記要素ノード・ツリーを前記クライアント・デバイスに送信するステップと
   を含む方法。

Images