JP2011516943A

JP2011516943A - クライアントによって生成された情報を表示する方法

Info

Publication number: JP2011516943A
Application number: JP2011500338A
Authority: JP
Inventors: デース，ワルテル; シュラブソール，ポール
Original assignee: Koninklijke Philips NV; Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2008-03-21
Filing date: 2009-03-17
Publication date: 2011-05-26
Also published as: WO2009115981A1; EP2258090A1; US20110010615A1; CN101978674A; RU2010143024A; MX2010010150A; TW200947298A; KR20110003343A

Abstract

本発明は、通信ネットワークに接続されたクライアントによって生成された情報を表示する方法に関する。本発明はまた、通信ネットワークに接続されているサーバーに対するクライアントとして機能する装置にも関する。ユーザーによる表示レンダリングの間の切り替えを防ぐための可能な解決策の一つは、ジャバスクリプトのようなスクリプトを用いることである。だが、これはセキュリティおよびプライバシー上の懸念につながりうる。本発明の方法は、プレースホルダーを含む第一の情報コンテンツを取得および表示すること；アピアランス〔見え方〕定義を含む第二の情報コンテンツを取得すること；前記クライアント（１０）から、前記クライアントによって生成および制御される第三の情報コンテンツを取得すること；前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示における位置に表示すること；前記第三の情報コンテンツを前記アピアランス定義に従って表示することを含む。機能的なコンテンツを「ルックアンドフィール」のコンテンツから分離することにより、機能的なコンテンツは、サービス・プロバイダーに見えたりアクセス可能になったりすることなく、クライアントによって提供されうる。それでいて、サービス・プロバイダーは一貫した「ルックアンドフィール」を維持できる。

Description

本発明は、通信ネットワークに接続されたクライアントによって生成された情報を表示する方法、コンピュータ上で実行されたときに該方法の全ステップを実行するためのプログラム・コードを有するコンピュータ・プログラムに関する。

本発明は、通信ネットワークに接続されたクライアントに情報コンテンツを供給する方法にも関する。

本発明は、通信ネットワークに接続されているサーバーに対するクライアントとして機能する装置にも関する。

ネットワーク接続されたデバイスの使用はますます広まりつつある。たとえばUPNP（Universal Plug and Play［ユニバーサル・プラグアンドプレイ］）ネットワークにおいて消費者装置のためにリモート・ユーザー・インターフェースを提供する家庭ネットワークの領域において、現在、多くの開発がなされている。そのようなネットワークは、UPnP家庭ネットワークを通じて他のUPnP装置上のアプリケーションをリモートに制御することをユーザーに許容することができ、また、インターネットに接続されている消費者装置を使ってインターネット・サービスと対話することをユーザーに許容することができる。それらの対話の一つは、映画のようなコンテンツがダウンロードできるようにするインターネット・サービスの利用でありうる。

インターネット・サービスの供給者の多さ、サービスの種類の多様さおよび消費者装置供給業者の多さは、ユーザーにとって最良の経験を提供するために通信プロトコルおよびインターフェースをできるだけ標準化することが好ましいことを意味している。

家庭ネットワークに好適な一つのそのような標準はCEA-2014またはWeb4CEという消費者電子協会（CEA: Consumer Electronics Association）規格である。この規格はUPnPサービスと、UPnPネットワークにおける消費者装置のためのリモート・ユーザー・インターフェースをねらいとするCE-HTMLと呼ばれるHTMLベースの規格とを指定する。Web4CEは二つの主要な用途をもつ：第一に、この規格は消費者が、UPnP家庭ネットワークを通じて他のUPnP装置上のアプリケーションをリモートに制御することを許容する。第二に、この規格は、インターネットに接続されている消費者装置を使ってインターネット・サービスと対話することを消費者に許容する。ユーザー対話は、単にCEA-2014互換ブラウザーを含む装置、たとえばメディア・アダプター（Media Adaptor）、テレビまたは携帯電話のリモコン、キーまたはタッチスクリーンを使って行える。

CEA-2014 Web4CE規格はUPnP装置またはインターネット・サービス（CE-HTMLウェブ・サーバーの役割をする）がグラフィック・ベースの対話的ユーザー・インターフェースをCEA-2014準拠HTMLページの形で転送することを許容する。Web4CEはUPnP装置のベンダーならびにインターネット・サービスの作者に、どの機能がリモート制御できるかだけでなく、消費者に示されるユーザー・インターフェースの「ルックアンドフィール」に対しても完全な制御を与える。「ルックアンドフィール」とは、ユーザーにとって知覚可能な諸側面であり、ユーザー・インターフェースの機能的な属性には関係しない。

接続されるUPnPデジタル家庭は、ユーザーが、家庭内の多様な製品から、多様な機能およびアプリケーションにアクセスすることを許容する。さらに、消費者製品は、ADSLやケーブルのようなブロードバンド・ネットワークを通じてサービス・プロバイダーによって家庭に送達されるインターネット・ベースのニュースおよび娯楽サービスへの直接アクセスを提供することによって、その機能を拡張しつつある。

Web4CEの主要なコンポーネントはCE-HTMLプロファイルである。これは、XHTMLコンテンツを使って、HDTV画面から携帯電話のディスプレイまでの幅広い種々の解像度およびサイズの画面上でレンダリングできるユーザー・インターフェースを定義する。基本技術としてXHTMLを使うことは、コンテンツが、広く受け入れられている既存のウェブ技術およびツールキットを使ってオーサリングおよびレンダリングできるということを意味する。さらに、これはHTMLツール供給者およびソフトウェア・ベンダーがCE-HTMLをサポートするのを非常に簡単かつコスト効率のよいものにする。

CE-HTMLは、CE-HTMLブラウザーを使って表示される。ブラウズ経験の重要な部分は、ブラウザー内の表示される情報（たとえばCE-HTMLページ）と、A/V（オーディオ／ビデオ）コンテンツのようなコンテンツをダウンロードするためのダウンロード・マネージャのようなローカルなクライアント側機能との間の対話である。このローカルなクライアント側機能は典型的にはその情報（状態、進行など）をローカルなネイティブUI〔ユーザー・インターフェース〕を通じて表示し、ブラウザー内の表示情報とは完全に独立に表示および制御される。

通信ネットワークに接続されたクライアントによって生成される情報を表示する方法を提供することが本発明の目的である。

本発明の第一の側面によれば、前記の目的は、通信ネットワークに接続されたクライアントによって生成される情報を表示する方法であって、前記通信ネットワークを通じてサーバーからプレースホルダーを含む第一の情報コンテンツを取得する段階と；前記第一の情報コンテンツをディスプレイ上に表示する段階と；前記サーバーからアピアランス〔外観〕定義を含む第二の情報コンテンツを取得する段階と；前記クライアントから、前記クライアントによって生成および制御される第三の情報コンテンツを取得する段階と；前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示〔ディスプレイ〕における位置に表示する段階と；前記第三の情報コンテンツを前記アピアランス定義に従って前記表示〔ディスプレイ〕において表示する段階とを含む方法によって達成される。

本発明のある側面によれば、前記サーバーから命令を取得する段階と；前記サーバーから前記第二の情報コンテンツを取得するために前記命令を実行する段階とをさらに含む方法が提供される。

本発明のこれらおよびその他の側面は以下に記載される実施形態を参照することから明白となり、明快にされるであろう。

通信ネットワークに接続されたクライアントに情報コンテンツを供給する方法を示す図である。命令を使って、通信ネットワークに接続されたクライアントによって生成された情報コンテンツを表示する方法を描いた図である。情報を供給するさらなる方法を示す図である。情報を供給するもう一つを描いた図である。図２、図３および図４に基づくダウンロード・マネージャによって表示される情報の例を描いた図である。

図面は純粋に図的なものであり、縮尺通りに描かれていない。特に、明確のため、一部の寸法は強く誇張されている。図面における同様な構成要素はできるだけ同じ参照符号によって表される。

図１は、家庭ネットワークのような通信ネットワーク（２０）に接続された消費者装置のようなクライアント（１０）を描いている。サーバー（３０）も同じネットワーク（２０）に接続されて設けられる。サーバー（３０）は、第二の消費者装置または通信ネットワーク（２０）と接触するいかなる装置内に含められていてもよい。

図１のシステムは、ユーザーが映画のようなコンテンツ（８０）を、該コンテンツ（８０）をサーバー（３０）上で利用可能にしたコンテンツ・プロバイダーからダウンロードすることを許可するよう構成される。

クライアント（１０）は、クライアント（１０）上でローカルに実行されるアプリケーションによってコンテンツがアクセス、たとえばロードおよび再生、されうるよう、記憶装置（６５）を設けられる。ダウンロード機能を助けるため、クライアント（１０）は、サーバー（３０）からの情報コンテンツ（７０）を表示するためのローカル・プレーヤー（４０）アプリケーションおよびダウンロード・マネージャ（６０）を設けられてもよい。

たとえば、情報コンテンツ（７０）は、映画のようなコンテンツ（８０）がダウンロードのために選択されうる環境へのアクセスを提供してもよい。該環境はサービス・プロバイダーによって提供される。典型的には、ローカル・プレーヤー・アプリケーション（４０）はブラウザーであり、情報コンテンツ（７０）はHTML、CE-HTML、XMLまたはSVGのようなマークアップ言語を含む。

動作の際、ローカル・プレーヤー・アプリケーション（４０）はサーバー（３０）から情報コンテンツ（７０）を取得し、それをユーザーに対して表示する（５０）。ユーザーがダウンロードしたいコンテンツ（８０）を見出したとき、ダウンロード・アプリケーション（６０）が実行されてコンテンツ（８０）をサーバー（３０）から取得する。ダウンロード・アプリケーション（６０）はダウンロードの状態をユーザーに対して表示する（５５）。

ダウンロード・マネージャ（６０）の際に有意でありうる状態情報は、次のものを含みうる：
・ダウンロード状態、たとえば接続中、進行中、一時停止、中断、完了；
・ダウンロード進行度、たとえば0、25、50、75、99%；
・予想される完了までの時間；
・記憶装置（６５）の記憶容量；および
・残りの空き記憶容量、たとえば10、20、30、40%。

典型的には、ブラウザー（４０）による表示（５０）およびダウンロード・マネージャ（６０）による表示（５５）は、クライアント（１０）によって別個にレンダリングされる。ひとたびダウンロードが開始されたら、ダウンロードの状態をモニタリングする唯一の方法は、ブラウザーのレンダリングされた表示（５０）とダウンロード・マネージャのレンダリングされた表示（５５）との間を行ったり来たりする切り替えをユーザーにさせることによる。これは、CEA-2014規格に基づく動作中は特に問題である。というのも、サービス・プロバイダーに、ブラウザーに対する完全な画面制御を与えることが決定されたからである。そうなると、表示レンダリング間のこの切り換えは、ユーザーが全画面ウィンドウの間の切り換えをすることを要求し、これはユーザー経験の興をそぐ。

さらなる問題は、それらの表示が二つの異なるアプリケーションによって与えられるということである。これは、それらの表示の「ルックアンドフィール」、すなわち情報がユーザーに対して表示されるときの該情報のユーザーに知覚される側面が著しく異なりうるということを意味する。これもユーザー経験の興をそぐ。

同様の問題は、下記のような他のローカル・アプリケーションがクライアントによって実行されるときに生じる：
・DRMエージェント。表示される状態は、ライセンス期限切れ、ライセンス・サーバーへの接続中、ライセンス検証中を含みうる；
・パーソナル・ビデオ・レコーダー（PVR）マネージャ。表示される状態は、録画開始、残りの空き記憶容量、リストのメンバーの一つを灰色表示にすることによるリスト内で視聴済みのコンテンツの指示を含みうる；
・パーソナル・テレビ・チャンネル・マネージャ。表示される状態は、お気に入り、記録されるコンテンツの名前、視聴されたコンテンツの名前およびユーザー・プロファイルを含みうる；
・クライアントを実行している装置の制御インターフェース。表示されるコントロールは、スタンバイ、再生、巻き戻し、早送り、スキップなどを含みうる。

これらのアプリケーション、たとえばダウンロード・マネージャとDRMエージェントが必要に応じて組み合わされてもよいこと、本発明がクライアント上で実行される他の同様のアプリケーションにも適用されうることは当業者には明白であろう。

図２は、通信ネットワーク（２０）に接続されているクライアント（１０）によって生成される情報を表示する方法であって、上述した問題に対処するものを描いている。図２の方法は、下記に述べる追加的側面を除けば図１の方法と同じである。

クライアント（１０）は、サーバー（１７７）から取得されうる好適な命令（１７７）を実行するための、ジャバスクリプトのようなエンジン（４５）を設けられる。エンジン（４５）はブラウザー・アプリケーション（４０）に統合されてもよい。その場合、命令（１７７）は情報コンテンツ（７０）に統合されてもよい。

エンジン（４５）は状態情報を取得するためにダウンロード・マネージャ（６０）とのインターフェースをもち、エンジン（４５）はダウンロード・マネージャ（６０）からの状態情報を、情報コンテンツ（１７０）のブラウザー（４０）による表示（５０）と同時に表示する（１５５）。

図５は、図２、図３および図４の方法が実行されるときにユーザーに対して表示されうる状態情報の例を示している。ブラウザー（４０）による表示（５０）は、映画の名前または映画のポスターの画像といったコンテンツ情報（５８）を含む。エンジン（４５）による表示（１５５）は、ダウンロード状態および進行度（１５２）および記憶装置空きスペース（１５７）といったダウンロード・マネージャについて適切な状態情報を含む。

ダウンロードが進行するにつれ、エンジン（４５）はダウンロード・マネージャ（６０）から状態情報を取得し、動的に表示（１５５）をレンダリングし、それにより示される状態の現在値を与える。

図２の方法にはいくつかの不都合な点がある。

１．消費者装置として提供されるクライアント（１０）とサービス・プロバイダーとの間の無数の組み合わせについて正しく動作するためには、命令（１７７）は好ましくは標準化されることになろう。たとえば、ジャバスクリプトを使うとき、クライアント装置に現在状態について問い合わせするためのgetDownloadStatus()〔ダウンロード状態取得〕、getDownloadProgress()〔ダウンロード進行度取得〕、getExpectedDownloadTime()〔予想されるダウンロード時間取得〕といった拡張が定義されうる。しかしながら、これらの拡張を扱うための多数の新しいジャバスクリプトAPI（Application Programming Interface［アプリケーション・プログラミング・インターフェース］）をもつことは、DVB-HTMLのような非常に複雑な規格につながりうる。

２．ダウンロード表示（１５５）を動的にレンダリングするためにジャバスクリプトのような命令（１７７）を使うことは、深刻なパフォーマンス上のペナルティを受けることがありえ、クライアント（１０）に余計な負担をかける。

３．ある種の状況では、スクリプト利用を無効にすることが望ましい。たとえば、サーバーによるポップアップ通知ウィンドウの望ましくない制御を防止するため、スクリプト利用はデフォルトで無効にされてもよい。それにより、たとえば、通知はある時間期間後に消えるようにされうる。

４．命令（１７７）がサービス・プロバイダーによって提供される。これらの命令（１７７）をクライアント（１０）上で実行することは、クライアント（１０）およびそれが走っている装置をサーバー（３０）にさらすことになる。これは、セキュリティおよびプライバシー上の懸念を生む。セキュリティ上の懸念というのは、エンジン（４５）が盲目的にサーバーから取得された命令（１７７）を実行してサーバー（３０）にクライアント装置およびたとえば記憶装置（６５）のファイル・システムへのアクセスを与えるからである。

プライバシーが問題となるのは、情報の一部が機微な情報であることがありうるからである。何が機微であるかは使用されるローカルなアプリケーションに依存する。たとえば：
・PVRがクライアント（１０）で走っている場合、現在記録されている番組のタイトル（１５５）；
・パーソナル・テレビ・チャンネル・マネージャについては、現在視聴されているコンテンツのタイトル；
・DRMエージェントについては、ライセンス検証試行の数。

図３に描かれている情報表示方法は、図３の方法に関連する問題に対処する。図３の方法は、下記に述べる追加的側面を除けば図１の方法と同じである。

クライアント（１０）は、HTMLのような第一の情報コンテンツ（２７０）を表示するためのブラウザー（２４０）のようなプレーヤーが設けられる。ブラウザー（２４０）は状態情報を取得するためにダウンロード・マネージャ（６０）とインターフェースをもち、ブラウザー（２４０）はダウンロード・マネージャ（６０）からの状態情報を、情報コンテンツ（１７０）のブラウザー（２４０）による表示（５０）と同時に表示する（１５５）。ブラウザー（２４０）はまた、サーバー（３０）から第二の情報コンテンツ（２７５）を取得するようにも構成される。第二の情報コンテンツ（２７５）は別個であってもよく、第一の情報コンテンツ（２７０）に統合されていてもよく、それらの組み合わせであってもよい。

第一の情報コンテンツ（２７０）はプレースホルダーを含む。これはダウンロード状態の表示（１５５）の位置を決定するために使われる。第二の情報コンテンツ（２７５）は、ダウンロード状態を表示する（１５５）ときにブラウザーが適用できる、スタイル定義のようなアピアランス〔外観〕に関係する定義を含む。

動作の際、ブラウザー（２４０）は第一（２７０）および第二（２７５）の情報コンテンツの両方を取得する。ブラウザー（２４０）は、ダウンロード・マネージャ（６０）から状態情報をも取得する。このダウンロード状態情報は、プレースホルダーによって決定される位置に、アピアランス定義に従って表示される（１５５）。

このようにして、ローカルなアプリケーションからの情報、この場合にはダウンロード状態が、何が表示されているかをサーバーが判別できることなく、クライアントによる制御のもとに、ブラウザー表示（５０）に埋め込まれる。サーバー（３０）の影響は、表示においてダウンロード状態がどのように見えるかおよびその位置に制限される。よって、一貫した「ルックアンドフィール」が維持されうる。

第二の情報コンテンツ（２７５）の一部として提供されるアピアランス定義は、たとえば、ブラウザーが理解するスタイル定義、背景画像のような画像およびそれらの組み合わせでありうる。これは、どの状態が表示される必要があるかの示唆をも含んでもよい。

スタイル定義は、HTMLスタイル定義であってもよい。これは第一の情報コンテンツ（２７０）内のスタイル・タグとして、あるいは別個のスタイルシートとしてとして、あるいはそれらの組み合わせで提供されてもよい。

購入、ダウンロード、もう一度ダウンロードといった限られた数の状態のみが表示されるのであれば、アピアランス定義はこれらの状態それぞれについての画像――すなわち適切な背景にスーパーインポーズされた適切な語の画像――を含んでもよい。そのような限られた数の状態は、クライアントが生成したエラーが表示される場合にも適用可能でありうる。

情報コンテンツ（２７０）がHTMLを含む場合、プレースホルダーはHTMLの<object>タグを含みうる
例１：HTMLコード・ソース <object>プレースホルダー
<object id="01" type="application/download">
<param name="State1" value="Style1"/>
</object>。

第二の情報コンテンツ（２７５）が第一の情報コンテンツ（２７０）に統合される場合、アピアランス定義はHTMLの<style>タグを含みうる
例２：HTMLコード・ソース <style>タグのアピアランス定義
<style>
#01
.Style1
{
background-color:#FF0000;
font-size:20pt
}
</style>。

ブラウザー（２４０）がダウンロード・マネージャ（６０）からパラメータState1を取得し、第一の情報コンテンツ（２７０）が<object>タグ・プレースホルダー（例１）および<style>タグ・アピアランス定義（例２）を含む場合、State1が表示される（１５５）ときにアピアランス定義Style1が適用される、すなわちState1が赤い背景色およびフォント・サイズ20ptで現れる。

あるいはまた、アピアランス定義は完全にまたは部分的にCSSスタイルシートに含まれてもよい。この場合、ブラウザー（２４０）が第二の情報コンテンツ（２７５）を取得しうるよう、第一の情報コンテンツ（２７０）はHTMLリンク・タグを含むことになる
例３：HTMLコード・ソース <link>タグ
<link rel="stylesheet" type="text/css" href="appearance.css"/>。

第二の情報コンテンツ（２７５）はappearance.cssと名付けられた、適切なアピアランス定義を含むCSSスタイルシートであってもよい。たとえば、アピアランス定義はスタイル属性を含みうる：
例４：HTMLコード・ソーススタイルシート・アピアランス定義
#01
.Style1
{
background-color:#FF0000;
font-size:20pt
}。

ブラウザー（２４０）がパラメータState1をダウンロード・マネージャ（６０）から取得し、第一の情報コンテンツ（２７０）は<link>タグ（例３）および<param>タグ・プレースホルダー（例１）を含み、第二の情報コンテンツ（２７５）はスタイルシート・アピアランス定義（例４）を含む場合、State1が表示される（１５５）ときにアピアランス定義Style1が適用される、すなわち、State1が赤い背景色およびフォント・サイズ20ptで現れる。

あるいはまた、プレースホルダーは第一の情報コンテンツ（２７０）内で以下のものを使って定義されてもよい：
・HTMLの<div>タグ。これは規格に加えられるべきあらかじめ定義されたCSSスタイルシートクラス定義を使う。
例５：HTMLコード・ソース <div>タグ・プレースホルダー
<div id="d1" class="download"/>
・HTMLの<iframe>タグ。だが、これはローカルなURIスキームまたはあらかじめ定義されるべきURIスキームを必要とする。
例６：HTMLコード・ソース <iframe>プレースホルダー
<iframe id="d1" class="" src="download"/>
・通常の使用のように各アプリケーションについてではなく各アプリケーション状態についてのMIME型またはクラスをもつ<object>タグ。だが、これは多数のMIMEクラス定義を標準に加えることを必要とする。
例７：HTMLコード・ソース <object>タグMIME型プレースホルダー
<object id="01" type="application/download_in_progress"</object>
<object id="02" type="application/download_completed"</object>。

代替的な方法が図４に描かれている。これは、下記に述べる追加的側面を除けば図３の方法と同じである。

クライアント（１０）は、ジャバスクリプト・エンジンのようなエンジン（４５）を設けられる。これはブラウザー（２４０）に統合されていてもよいし、別個のアプリケーションであってもよい。エンジン（４５）はサーバー（３０）から命令（２７７）を取得するよう構成される。エンジン（４５）はさらに、命令（２７７）を実行することによって第二の情報コンテンツ（２７５）を取得し、ブラウザー（２４０）に第二の情報コンテンツ（２７５）を提供するよう構成される。

動作の際、命令（２７７）がエンジン（４５）によってサーバーから取得され、エンジン（４５）に第二の情報コンテンツ（２７５）を取得して第二の情報コンテンツ（２７５）をブラウザー（２４０）に渡させる。

エンジン（４５）はブラウザー・アプリケーション（２４０）に統合されていてもよい。その場合、アピアランス定義がどこで取得されうるかを示す<script>タグを使って命令（２７７）も情報コンテンツ（２７０）に統合されてもよい。これは、画像またはスタイルシートのURLを使ってできる。次の例は、例４のスタイルシートを取得するためにスクリプトを使っている：
例８：HTMLコード・ソース <script>タグ
<script>
styleDownloadStates("connecting",appearances.css,
"downloading",appeances.css, ...)
</script/>。

ブラウザー（２４０）がパラメータState1をダウンロード・マネージャ（６０）から取得し、第一の情報コンテンツ（２７０）が<script>タグ（例８）および<param>タグ・プレースホルダー（例１）を含み、第二の情報コンテンツ（２７５）がスタイルシート・アピアランス定義（例４）を含む場合、State1が表示される（１５５）ときにアピアランス定義Style1が適用される、すなわち、State1が赤い背景色およびフォント・サイズ20ptで現れる。

図４の実施形態は命令が取得され、実行されることを要求するので、セキュリティ上の懸念は当てはまらない。というのも、エンジンは機能を直接さらすわけではなく、表示をレンダリングすることをローカル・クライアント機能に委ねるからである。

クライアント（１０）を、アピアランス定義が適用されたという確認〔アクノレッジ〕をサーバー（３０）に与えるよう構成することが有利であることもありうる。ランタイムで交換機能を提供することによって、白い背景に白いテキスト・ラベルを表示するといったミスが防止されうる。

本発明に基づく方法は高度な柔軟性を提供するが、可能なアピアランス定義を、背景色およびフォント・サイズだけなど、比較的少数の選択肢に制約することが有利でありうる。

起こりうる問題の一つは、ローカルなアプリケーションが、ユーザーが読めるようにテキスト・ラベルを十分大きく表示したいことがありうる、あるいはテキスト・ラベルをクリップするボーダーが適用されることがありうるということである。上記の実施形態に基づくアピアランス定義は、そのようなことを考えることなく、サーバー（３０）から取得され、適用される。

したがって、規格において最小値および最大値に対処することが有利でありうる。クライアント（１０）上のローカル・アプリケーションがサーバー（３０）に、必要とされる最小ウィンドウ・サイズについて通知することも有利でありうる。それにより、この最小ウィンドウ・サイズについて適切なアピアランス定義が取得される。

上述した実施形態は、本発明を限定するというよりは例解するものであること、当業者は付属の請求項の範囲から外れることなく数多くの代替的な実施形態を設計できるであろうことを注意しておくべきであろう。

たとえば、実施形態は単一のサーバー（３０）に言及しているが、情報コンテンツ（７０、１７０、１７７、２７０、２７５、２７７）およびダウンロード可能コンテンツ（８０）は複数のサーバー（３０）にわたって分散されてもよい。第一の情報コンテンツ（１７０、２７０）のような単一の情報コンテンツを諸部分において複数のサーバーにわたって分散させることも有利でありうる。

本発明の方法は、一つまたは複数のプログラム内のプログラム・コードとしてエンコードされ、それにより、そうしたプログラムが一つまたは複数のコンピュータ上で実行されたときに前記の方法が実行されてもよい。プログラム・コードは、コンピュータ可読媒体上に記憶されてもよく、コンピュータ・プログラム・プロダクトに含められてもよい。

これらのプログラムの一つが実行されるプラットフォームはスタンドアローンの専用ユニットでもよく、あるいは本発明の方法を実行するためのプログラム・コードまたはソフトウェアを与えられたPCでもよいし、あるいはPCのためのハードウェア・アドオンとしてであってもよい。プラットフォームは、PDAまたは携帯電話のようなポータブルな電子装置に統合されてもよい。

プラットフォームは、通信ネットワークに接続されているサーバーに対するクライアントとして動作する装置に統合されてもよい。前記装置は：
・通信ネットワーク（２０）に接続するためのインターフェースと；
・通信ネットワーク（２０）を通じてサーバー（３０）から、プレースホルダーを含む第一の情報コンテンツ（２７０）を取得する第一の取得器と；
・前記第一の情報コンテンツ（２７０）をディスプレイ上に表示（５０）するよう構成された第一の出力と；
・前記サーバーからアピアランス〔外観〕定義を含む第二の情報コンテンツ（２７５）を取得する第二の取得器と；
・前記クライアント（１０）から、前記クライアント（１０）によって生成および制御される第三の情報コンテンツを取得する第三の取得器と；
・前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示における位置に表示（１５５）する第二の出力とを有し、前記第二の出力は、前記第三の情報コンテンツを前記アピアランス定義に従って前記表示において表示（１５５）するよう構成される。

前記装置は、さらに前記ディスプレイを含むよう修正されてもよい。

同様に、通信ネットワーク（２０）への言及は、クライアント（１０）とサーバー（３０）との間の通信経路として広く解釈されるべきである――これは二つの物理的な装置の間のケーブルという簡単なものであってもよいし、あるいはサーバーやルーターのような一つまたは複数の装置によって接続される一つまたは複数のネットワークを含んでいてもよい。

上記の実施形態は、ローカル・アプリケーションによって表示（５５、１５５）中に制御オプションがレンダリングされるよう修正されてもよい。それにより、ユーザー・インターフェースの機能がクライアント（１０）によって決定および制御されることを許容するとともに、「ルックアンドフィール」がサービスまたはコンテンツ・プロバイダーによって決定されることを許容する。ウェブカメラ制御マネージャのようなローカル・アプリケーションが、パン、チルト、ズーム、フォーカスおよびアパーチャといったコントロールを表示する（５５、１５５）ためにクライアント上で走らされてもよい。それによりそれらのコントロールは、サービスまたはコンテンツ・プロバイダーからの包含するCE-HTMLページのルックアンドフィールにフィットする。

請求項において、括弧内に参照符号があったとしてもその請求項を限定するものと解釈してはならない。動詞「有する」およびその活用形の使用は請求項において述べられているもの以外の要素またはステップの存在を排除しない。要素の単数形の表現はそのような要素の複数の存在を排除しない。本発明は、いくつかの相異なる要素を有するハードウェアによって実装されてもよい。いくつかの手段を列挙している装置請求項においては、それらの手段のいくつかが同一のハードウェア項目によって具現されてもよい。ある種の施策が互いに異なる従属請求項において言及されているというだけの事実がそれらの施策の組み合わせが有利に使用できないことを示すものではない。

まとめると、本発明は、通信ネットワークに接続されたクライアント（１０）によって生成される情報を表示する方法に関する。表示レンダリングの間でユーザーが切り替えることを防ぐための可能な解決策の一つは、ジャバスクリプトのようなスクリプトを用いることである。だが、これはセキュリティおよびプライバシー上の懸念につながりうる。

本発明の方法は、プレースホルダーを含む第一の情報コンテンツを取得および表示すること；アピアランス〔見え方〕定義を含む第二の情報コンテンツを取得すること；前記クライアントから、前記クライアントによって生成および制御される第三の情報コンテンツを取得すること；前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示における位置に表示すること；前記第三の情報コンテンツを前記アピアランス定義に従って表示することを含む。

機能的なコンテンツを「ルックアンドフィール」のコンテンツから分離することにより、機能的なコンテンツは、サービス・プロバイダーに見えたりアクセス可能になったりすることなく、クライアントによって提供されうる。それでいて、サービス・プロバイダーは一貫した「ルックアンドフィール」を維持できる。

Claims

通信ネットワークに接続されたクライアントによって生成される情報を表示する方法であって：
・前記通信ネットワークを通じてサーバーからプレースホルダーを含む第一の情報コンテンツを取得する段階と；
・前記第一の情報コンテンツをディスプレイ上に表示する段階と；
・前記サーバーからアピアランス定義を含む第二の情報コンテンツを取得する段階と；
・前記クライアントから、前記クライアントによって生成および制御される第三の情報コンテンツを取得する段階と；
・前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示における位置に表示する段階と；
・前記第三の情報コンテンツを前記アピアランス定義に従って前記表示において表示する段階とを含む、
方法。
請求項１記載の方法であって、さらに：
・前記サーバーから命令を取得する段階と；
・前記サーバーから前記第二の情報コンテンツを取得するために前記命令を実行する段階とを含む、
方法。
前記命令がジャバスクリプトを含む、請求項２記載の方法。
前記第一の情報コンテンツがマークアップ言語を含む、請求項１または２記載の方法。
前記マークアップ言語が、HTML、CE-HTML、XML、SVGおよびそれらの任意の組み合わせからなる群から選択される、請求項４記載の方法。
前記プレースホルダーが、object、param、div、iframeおよびそれらの任意の組み合わせからなる群から選択される一つまたは複数のHTMLタグを含む、請求項１または２記載の方法。
前記プレースホルダーが、objectタグおよびMIME型を含む、請求項１または２記載の方法。
前記第三の情報コンテンツが、ダウンロード・マネージャ、DRMエージェント、パーソナル・ビデオ・レコーダー、パーソナル・テレビ・チャンネル・マネージャまたはそれらの任意の組み合わせからなる群から選択されるローカル・アプリケーションによって生成される情報を含む、請求項１または２記載の方法。
コンピュータ上で実行されたときに請求項１または２記載の全段階を実行するためのプログラム・コード手段を含むコンピュータ・プログラム。
コンピュータ上で実行されたときに請求項１または２記載の方法を実行するための、コンピュータ可読媒体上に記憶されたプログラム・コード手段を含むコンピュータ・プログラム。
通信ネットワークに接続されたクライアントに情報コンテンツを供給する方法であって：
・前記通信ネットワークを通じて第一の情報コンテンツを供給する段階であって、前記第一の情報コンテンツはディスプレイ上に表示するのに好適でありプレースホルダーを含み、前記プレースホルダーは前記表示において前記クライアントによって生成および制御される第三の情報コンテンツの位置を決定するのに好適である、段階と；
・アピアランス定義を含む第二の情報コンテンツを供給する段階とを含み、
前記アピアランス定義は、前記表示における前記第三の情報コンテンツのアピアランスを決定するよう構成されている、
方法。
請求項１０記載の情報コンテンツを供給する方法であって、さらに：
・命令を前記クライアントに供給する段階と；
・前記命令を実行する前記クライアントから要求を受信する段階と；
・前記要求に応答して前記第二の情報コンテンツを供給する段階とを含む、
方法。
通信ネットワークに接続されているサーバーに対してクライアントとして動作する装置であって：
・前記通信ネットワークに接続するためのインターフェースと；
・前記通信ネットワークを通じて前記サーバーから、プレースホルダーを含む第一の情報コンテンツを取得する第一の取得器と；
・前記第一の情報コンテンツをディスプレイ上に表示するよう構成された第一の出力と；
・前記サーバーからアピアランス定義を含む第二の情報コンテンツを取得する第二の取得器と；
・前記クライアントから、前記クライアントによって生成および制御される第三の情報コンテンツを取得する第三の取得器と；
・前記第三の情報コンテンツを前記プレースホルダーによって決定される前記表示における位置に表示する第二の出力とを有し、前記第二の出力は、前記第三の情報コンテンツを前記アピアランス定義に従って前記表示において表示するよう構成される、
装置。
前記ディスプレイをさらに有する、請求項１２記載の装置。