(57)【特許請求の範囲】
【請求項１】
背景および一つまたは複数の前景オブジェクトを有する第一のウィンドウを画面上に表示する方法であって、該第一のウィンドウの背景を通して下にあるオブジェクトが可視であり、該第一のウィンドウの前景オブジェクトを通しては下にあるオブジェクトは可視でなく、
前記第一のウィンドウの下にある領域が変化したかどうかを判断するステップと、
変化した場合には、前記第一のウィンドウの前景の少なくとも一部を再描画するステップとを有する方法。
【請求項２】
前記第一のウィンドウの下にある領域内の変化によって影響を及ぼされる、前記第一のウィンドウの領域を特定するステップと、
影響を及ぼされる領域内で前景オブジェクトを特定するステップと、
影響を及ぼされうる前記第一のウィンドウのクライアントに前記第一のウィンドウの少なくとも一部を再描画するよう命令する信号を受信したのち、前記影響を及ぼされる領域内の前記前景オブジェクトの少なくとも一部を再描画するステップとをさらに有する、請求項１記載の方法。
【請求項３】
前記再描画ステップの後には、前記前景オブジェクトが該前景オブジェクトの下にある領域を少なくとも部分的に隠す、請求項２記載の方法。
【請求項４】
第二のウィンドウを表示するステップをさらに有し、前記第二のウィンドウの背景を通して下にあるオブジェクトが可視である、請求項１ないし３のうちいずれか一項記載の方法。
【請求項５】
前記第一のウィンドウの少なくとも一部が前記第二のウィンドウの下にある、請求項４記載の方法。
【請求項６】
前記第一のウィンドウに影響を及ぼす、前記第二のウィンドウ内での描画を補正できるように、前記第二のウィンドウ内での描画を監視することをさらに有する、請求項１ないし５のうちいずれか一項記載の方法。
【請求項７】
背景および一つまたは複数の前景オブジェクトを有する第一のウィンドウを画面上に表示する手段を有し、該第一のウィンドウの背景を通して下にあるオブジェクトが可視であり、該第一のウィンドウの前景オブジェクトを通しては下にあるオブジェクトは可視でなく、
前記第一のウィンドウの下にある領域が変化したかどうかを判断する手段と、
前記第一のウィンドウの下にある領域が変化した場合には、前記第一のウィンドウの前景の少なくとも一部を再描画する手段とを有しており、
テレビセットとともに使用するためであることを特徴とする受信機／デコーダ。
【請求項８】
前記第一のウィンドウの下にある領域内の変化によって影響を及ぼされる前記第一のウィンドウの領域を特定する手段と、
影響を及ぼされる領域内で前景オブジェクトを特定する手段と、
影響を及ぼされうる前記第一のウィンドウのクライアントに前記第一のウィンドウの少なくとも一部を再描画するよう命令する信号を受信したのち、影響を及ぼされる領域内の前記前景オブジェクトの少なくとも一部を再描画する手段とをさらに有する、請求項７記載の受信機／デコーダ。
【請求項９】
再描画手段の動作の結果、前記前景オブジェクトが該前景オブジェクトの下にある領域を少なくとも部分的に隠す、請求項８記載の受信機／デコーダ。
【請求項１０】
第二のウィンドウを表示するための手段をさらに有し、前記第二のウィンドウの背景を通して下にあるオブジェクトが可視である、請求項７ないし９のうちいずれか一項記載の受信機／デコーダ。
【請求項１１】
前記第一のウィンドウの少なくとも一部が、前記第二のウィンドウの下にある、請求項１０に記載の受信機／デコーダ。
【請求項１２】
前記第一のウィンドウに影響を及ぼす、前記第二のウィンドウ内での描画を補正できるように前記第二のウィンドウ内での描画を監視するための手段をさらに有する、請求項７ないし１１のうちいずれか一項記載の受信機／デコーダ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ウィンドウを表示する、ウィンドウの中に描画する、及びナビゲータディスプレイ、受信機／デコーダ、テレビシステム、コンピュータプログラム製品、コンピュータ読み取り可能媒体、及び信号を表示する装置及び方法に関する。
発明は、受信機／デコーダとともに使用するための複数ウィンドウ制御システムに特定の用途を有する。
参照は、その内容がここに参照して組み込まれ、そこから条約優先権が請求される欧州特許出願番号第９９４０２３５３．９号、第９９４０２７２１．７号、及び第００３００８３２．３号に対してなされる。
【０００２】
複数ウィンドウ制御システムは、テキストまたはグラフィック画像などのグラフィックオブジェクトなどのさまざまなウィンドウコンテンツを、画面上のウィンドウとして知られるさまざまな領域に同時に表示できるようにするために使用される。従来の複数ウィンドウ制御システムでのウィンドウは、その領域内でグラフィックオブジェクトが、不透過的な背景に対する表示のために描画されてよい矩形を備える。ウィンドウは、通常、画面の選択された領域を占有し、ウィンドウのサイズ、背景色、及び位置は、通常、ウィンドウを開いたときに定められ、開いた後には改変可能である。
【０００３】
従来の複数ウィンドウ制御システムは、それらが情報を画面上に提示できるようにする方法において柔軟性を欠くことがある。例えば、２つのウィンドウが重複する場合には、一番前のウィンドウが下にあるウィンドウの重複部分を隠す。
【０００４】
本発明の第１態様においては、ウィンドウが下にあるオブジェクトが可視である背景を有する画面にウィンドウを表示する方法が提供される。１つの特に好まれている態様では、この方法は、受信機／デコーダによって実施され、該受信機／デコーダは好ましくはテレビセットと使用するためである。
発明は、複数ウィンドウ制御システムの利点のいくつかまたは全てを備えて画面上に情報が提示されてよいが、ウィンドウの下にあるオブジェクトがウィンドウを通して少なくとも部分的に見られてよいという優位点を提供することができる。
発明は、いくつかの予防措置が講じられるのであれば、ウィンドウが透過的な背景を有してよいという理解から生じる。このような予防措置は、ウィンドウがいったん描画されるとウィンドウの後ろに描画しないこと、あるいは描画のあらゆる影響を補正するためにウィンドウの後ろの描画を監視することを含む。
【０００５】
方法は、さらに、ウィンドウのフレームを描画することを備えてよく、その結果、ウィンドウの範囲は可視である。ウィンドウのサイズは、画面のサイズとは無関係でよく、ウィンドウは画面上でサイズ変更可能且つ移動可能であってよい。
好ましくは、ウィンドウは、ウィンドウディスプレイを備える画面の部分を形成し、方法は、さらに、ビデオ画像とウィンドウディスプレイを結合することを備える。ウィンドウディスプレイは、２つを融合することによりビデオ画像と結合されてよいが、単に（好ましくはさらに大きい領域）ビデオ画像上に上書きされてよく、両方とも好ましくはハードウェア手段を使用し、ウィンドウディスプレイの後ろのビデオ画像を隠す。透過ウィンドウによって提供されるコンパクトさの増大から部分的に生じ、これが、受信機／デコーダの状況で特に有利である場合がある、ビデオ画像上でのメニュー等の侵入を最小限に抑えることができる。
【０００６】
好ましくは、方法は、さらにテレビ画面にウィンドウを表示することを備える。本発明は、特に、典型的にコントラストがさらに低い混合方法との比較によって、テレビディスプレイに適用できる。
好ましくは、方法は、さらに、
ウィンドウのサイズを定めるステップと、
ウィンドウ内に前景オブジェクトを描画するステップと、
ウィンドウの背景を配列するステップと、
を備える。
【０００７】
この機能も関係なく提供される。従って、発明は、ウィンドウのサイズを定義するステップと、ウィンドウの中に前景オブジェクトを描画するステップと、背景の下にあるオブジェクトが可視となるようにウィンドウの背景を配列するステップとを備えるウィンドウを表示する方法も提供する。背景は、好ましくは、前景オブジェクトが描画されないウィンドウのそれらの部分である。
【０００８】
前景オブジェクトを描画するステップは、前景ピクセルを所望される値に設定することを備えてよい。背景オブジェクトは、直線、曲線、ボックス、円、三角形及び活字印刷用の文字のいずれかまたは全てを備えてよく、好ましくは少なくとも２つの描画動作で描画される。前景オブジェクトは、対話制御機構を備えてよい。制御機構は、例えばクリック可能ボタン、ラジオボタン、テキストボックス、クリック可能な矢印等を備えてよい。これは、任意の形状の浮動パネルを作成できるようになる。
【０００９】
背景を配列するステップは、少なくとも１つのピクセル値を未改変のまま残すこと、あるいは好ましくは背景を画定する領域内で下にある画像のピクセル値と少なくとも１つのピクセル値を融合することを備えてよい。このようにして、下にあるオブジェクトは、背景を部分的または完全にのどちらかで透過的にすることによって、背景を通して可視であってよい。
【００１０】
ある実施形態では、背景は完全に透過的であり、背景ピクセル値は描画されない。別の実施形態では、背景には透過性係数が割り当てられ、少なくとも１つの背景ピクセル値が、透過性係数に依存して下にあるオブジェクトの少なくとも１つのピクセル値と融合される。これが、背景内の画像を、下にあるオブジェクトと同時に可視とすることを可能にする。例えば、背景は、可視であるが、それを通して下にあるオブジェクトが見られてよい、ロゴまたは透かし模様を有してよい。透過性係数は、例えば、ユーザによって、あるいはウィンドウのクライアントの制御したで調整可能であってよい。追加実施形態では、異なる透過性係数が、背景のさまざまな部分に割り当てられる。例えば、背景のいくつかの部分は完全に透過的であるが、他方の部分は、下にあるオブジェクトのピクセル値と融合される背景ピクセル値を有してよい。
【００１１】
好ましくは、背景の下にあるオブジェクトの少なくとも１つが、ウェブページの要素を備え、要素は、例えば、テキスト、ハイパーリンクまたはその他のＨＴＭＬ要素であるだろう。このようにして、さらに柔軟な形状が、例えばナビゲーションバーをさらに効率的に表示し、ウェブページのさらに大きなビューを指定できるようにするために、制御パネルについて可能にすることができる。
【００１２】
方法は、さらに、下にあるオブジェクトが可視である背景を有する追加ウィンドウを表示することを備えてよい。従って、複数の「透過ウィンドウ」が提供されてよい。積み重ねられた透過ウィンドウを達成するためには、第１ウィンドウの少なくとも一部が追加ウィンドウの下にあってよい。
【００１３】
本発明に従って特定された問題とは、透過的な背景のウィンドウの下にあるウィンドウに描画すると、透過ウィンドウの中で画像が破損される結果となることがあるという点である。例えば、透過ウィンドウ内の前景オブジェクトは、描画によって上書きされてよい。従って、方法は、前記ウィンドウに影響を及ぼす追加ウィンドウでの描画が補正できるように追加ウィンドウ内の描画を監視することを備えてよい。
【００１４】
この特徴は、独立して提供されてもよく、このようにして発明は、ウィンドウ、好ましくは少なくとも、その下にあるオブジェクトが可視である背景を有する、部分的に上に来るウィンドウの下にあってよいウィンドウ内に描画する方法も提供し、該方法は、上に来るウィンドウに影響を及ぼす描画を補正できるように、ウィンドウ内に描画し、描画を監視することを備え、該方法は、好ましくは受信機／デコーダによって実施される。
【００１５】
上に来るウィンドウ内での描画を補正するために、方法は、さらに、描画によって影響を及ぼされてよいウィンドウを決定することと、そのウィンドウの少なくとも一部を描画し直すために影響を及ぼされてよいウィンドウのクライアントに指示する信号（例えば、露光イベント）を送信することを備えてよい。
信号は、Ｊａｖａイベントであってよい。それは、好ましくは関数呼び出しを介して送信されるメッセージであってもよい。
【００１６】
ある実施形態では、信号は、各描画動作の後に送信されてよい。しかしながら、本発明に従って、このようにして信号を送信すると、多数の再描画動作につながってよく、結果として大量の処理が再描画専用となることが明らかにされた。発明の好ましい実施形態によって、この問題は、少なくとも１つの描画動作の間、信号の送信を抑制することにより克服される。ここに使用されるような用語「信号の送信を抑制する」及び類似する用語は、好ましくは、送信されていない、または受信されていないかのどちらかの信号を言外に含む。例えば、２つの関係者の間で遷移中の信号を傍受及び除去することと、最初に信号を送信しないことは、ともに信号の抑制を構成する。
【００１７】
機能はまた、独立して提供されてもよく、このようにして発明の別の態様では、ウィンドウ、好ましくは下にあるオブジェクトが可視である背景を有するウィンドウの少なくとも部分的に下にあるウィンドウ内で描画する方法が提供され、該方法は、信号（例えば、露光イベント）が、描画によって影響を及ぼされてよいウィンドウのクライアントに、そのウィンドウの少なくとも一部を再描画するように指示する各描画動作の後に送信される第１モードを提供すること、及び信号の送信が抑制される第２モードを提供することを備える。
【００１８】
発明の前記態様は、相対的に簡略な描画動作が第１モードで実施されてよく、そのケースでは影響を受けるウィンドウが絶えず更新されるが、さらに複雑な複数の描画動作は第２モードで実施されてよく、それが再描画に関連する処理の量を削減してよいという優位点を提供できる。
【００１９】
信号は、ウィンドウマネージャから送信されてよい。代わりに、信号はウィンドウのクライアントから送信されてよく、好ましくは描画を実施したクライアントによって送信され、好ましくはウィンドウマネージャに送信されてよい。方法は、好ましくは、さらにウィンドウの透過性に関係する情報をウィンドウマネージャが使用できるようにすることを備え、方法は、さらに、ウィンドウの属性として情報を記憶することを備えてよい。ウィンドウの透過性に関係する情報をウィンドウマネージャが使用できるようにすることにより、再描画などの動作は、集中した、効率的な方法で実行できる。さらに、透過ウィンドウの特徴をアプリケーションに追加するために必要とされる作業をより少なくすることができ、各アプリケーションで透過ウィンドウを実現するために必要とされる余分なコード化の料を削減することができる。
【００２０】
ここに使用されるような用語「ウィンドウの属性」は、好ましくは、ウィンドウに関連付けられるなんらかの形のデータを言外に含み、データはウィンドウマネージャによって理解され、典型的にはウィンドウマネージャによって維持され、その他のウィンドウ属性を含むメモリのブロックの中に記憶される。好ましくは、方法は、さらに、好ましくはメッセージの中で、または関数呼び出しを介して、ウィンドウマネージャに情報を送信することを備える。信号の送信は、情報に依存して抑制されてよい。
【００２１】
信号の送信は、ウィンドウの関係性に依存して抑制されてよい。例えば、描画されるアクティブなウィンドウに対する一定の関係性を有するウィンドウがそのウィンドウとは重複せず、そのケースでは、なんらかの処理がこのようなウィンドウを無視することによって省かれてよいことが既知であってよい。例えば、アクティブなウィンドウに対する以下の関係性を有するウィンドウは、無視できるだろう。
・母、すなわちアクティブウィンドウがそこから開かれたウィンドウ
・上位者、すなわち母、その母等
・姉妹、すなわちアクティブウィンドウと同じウィンドウから開かれたウィンドウ
・娘、すなわちアクティブウィンドウから開かれたウィンドウ
・下位者、すなわち、娘、その娘等
代わりに、全てのウィンドウは無視できる、あるいは全ての透過ウィンドウは無視できるだろう。
【００２２】
方法は、さらに、数多くの描画動作の後の信号の送信を備えてよく、数は好ましくは少なくとも１つの描画動作の前に決定され、好ましくは１、３、５、１０、３０、５０または１００より大きい。これは、各描画動作後の再描画よりさらに効率的であるが、多数の描画動作が一度の移動で実行されなければならない場合に、（美的に不愉快である可能性がある）重なるウィンドウがかなりの長さの時間再描画されない状況を回避することができる。方法は、さらに、影響を及ぼされる可能性のあるウィンドウの少なくとも一部を再描画することを備えてよい。
【００２３】
発明の別の態様では、ウィンドウ内の描画が監視され、信号が描画によって影響を及ぼされる可能性のある少なくとも１つのその他のウィンドウに送信される複数ウィンドウ制御システムで描画する方法が提供され、該方法は、さらに、少なくとも１つのそれ以外のウィンドウに対する信号が、少なくとも１つの描画動作の間抑制されるモードを選択することを備える。
前記方法は、さらに、信号が、前記少なくとも１つの描画動作の後に、前記少なくとも１つの他のウィンドウに送信されるモードを選択することを備えてよい。信号は、そのウィンドウの少なくとも一部を再描画するために描画によって影響を及ぼされてよいウィンドウのクライアントに指示を出す信号であってよい。
【００２４】
本発明は、ウィンドウのディスプレイを管理するウィンドウマネージャを提供すること、及びウィンドウマネージャにウィンドウの透過性に関係する情報を渡すことを備える、ウィンドウを表示する方法も提供する。
好ましくは、ウィンドウマネージャは、バーチャルマシンの一部を形成する。
【００２５】
発明は、さらに、好ましくはウェブブラウザ用にナビゲータディスプレイを表示する方法を提供し、そこではナビゲータディスプレイが透過的な背景を有する少なくとも１つのウィンドウを備える。
透過的な背景は、概して前景の外側に位置してよい。方法は、受信機／デコーダによって実施されてよく、該受信機／デコーダは、好ましくはテレビセットともに使用するためである。
【００２６】
発明は、例えばコンピュータとともに使用するための任意の複数ウィンドウ制御システムに適用できる。しかしながら、発明は、受信機／デコーダと特定の用途を有し、このようにして方法は受信機／デコーダによって実施されてよい。受信機／デコーダは、典型的には、パーソナルコンピュータと比較して処理電力を削減し、従って関係する処理を削減する発明の実施形態は、特に受信機／デコーダとの使用に適している。
【００２７】
発明の別の態様では、
第１ウィンドウ及び第２ウィンドウを表示し、少なくとも第１ウィンドウが、下にあるオブジェクトが可視である背景を有することと、
第１ウィンドウが第２ウィンドウと重複するかどうかを判断することと、
第２ウィンドウ内で描画することと、
第１ウィンドウが第２ウィンドウと重複する場合に、第１ウィンドウの少なくとも一部を再描画することと、
を備える、画面上にウィンドウを表示する方法が提供される。
方法は、さらに、第２ウィンドウを重複する第１ウィンドウの一部を判断することを備えてよく、再描画するステップは、第１ウィンドウのその部分を再描画することを備えてよい。
【００２８】
発明の別の態様では、
画面の領域が別のウィンドウの部分、及び該部分に対応するその他のウィンドウの別のコンテンツを表示するために少なくとも部分的に使用されるかどうかを判断することと、
他のウィンドウの少なくとも部分及び対応する他のコンテンツを描画することと、
他のウィンドウの部分に重複する決定されたコンテンツの少なくとも一部を描画することと、
を備える、画面のある領域の上に、透過ウィンドウ及びこの透過ウィンドウの決められたコンテンツを表示する方法が提供される。
【００２９】
発明の関係する態様によって、画面上にウィンドウを表示するための（典型的にはプロセッサの形を取る）手段を備える受信機／デコーダが提供され、そこでは、ウィンドウは、下にあるオブジェクトが可視である背景を有し、該受信機／デコーダはテレビセットと使用するためである。
受信機／デコーダは、さらに、ウィンドウの枠を描画するための（典型的にはプロセッサの形を取る）手段を備えてよい。表示手段は、好ましくは、ウィンドウディスプレイを備える画面の部分を形成するウィンドウを表示するように適応され、受信機／デコーダは、さらに、ウィンドウディスプレイをビデオ画像と結合するための手段を備える。表示手段は、好ましくはテレビ画面上にウィンドウを表示するように適応される。
【００３０】
受信機／デコーダは、さらに、
ウィンドウのサイズを定めるための（典型的にはプロセッサの形を取る）手段と、
ウィンドウに前景オブジェクトを描画するための（典型的にはプロセッサの形を取る）手段と、
ウィンドウの背景を配列するための（典型的にはプロセッサの形を取る）手段と、
を備えてよい。
【００３１】
発明は、
ウィンドウを表示するための（典型的にはプロセッサの形を取る）手段と、
ウィンドウのサイズを定めるための（典型的にはプロセッサの形を取る）手段と、
ウィンドウに前景オブジェクトを描画するための（典型的にはプロセッサの形を取る）手段と、
背景の下にあるオブジェクトが可視であるように、ウィンドウの背景を配列するための（典型的にはプロセッサの形を取る）手段と、
を備える、受信機／デコーダに拡張する。
【００３２】
前景オブジェクトを描画するための手段は、所望される値に前景ピクセルを設定するように適応されてよい。背景オブジェクトは、直線、曲線、ボックス、円、三角形、及び活字印刷用の文字のいずれかまたはすえてを備えてよく、好ましくは少なくとも２つの描画動作で描画されるように適応される。前景オブジェクトは、対話型制御機構を備えてよい。
【００３３】
配列手段は、好ましくは、背景を画定する領域で少なくとも１つのピクセル値を未改変のままにするように適応される。背景を画定する領域内で、少なくとも１つのピクセル値を下にある画像のピクセル値と融合することが適応されてよい。それは、少なくとも１つの前景ピクセルを未改変のままにしておくように適応されてよい。
背景の下にあるオブジェクトの少なくとも１つは、ウェブページの要素を備えてよい。
【００３４】
受信機／デコーダは、さらに、下にあるオブジェクトが可視である背景を有する追加ウィンドウを表示するための（典型的にはプロセッサの形を取る）手段を備えてよい。第１ウィンドウの少なくとも一部は、追加ウィンドウの下にあってよい。
受信機／デコーダは、さらに、前記ウィンドウに影響を及ぼす追加ウィンドウでの描画が補正できるように、追加ウィンドウでの描画を監視するための（典型的にはプロセッサの形を取る）手段を備えてよい。
【００３５】
発明は、
ウィンドウに描画するための手段と、
上にあるウィンドウに影響を及ぼす描画が補正できるように、描画を監視するための手段と、
を備える受信機／デコーダに拡張する。
受信機／デコーダは、さらに、描画によって影響を及ぼされる可能性のあるウィンドウを決定するため、及びそのウィンドウの少なくとも一部を再描画するために影響を及ぼされる可能性のあるウィンドウのクライアントに指示する信号を送信するための手段を備えてよい。信号は、Ｊａｖａイベントであってよい。それは、各描画動作の後に送信されてよい。
受信機／デコーダは、さらに、少なくとも１つの描画動作の間信号を抑制するための手段を備えてよい。
【００３６】
発明は、第１モード及び第２モードで、ウィンドウに描画するための手段を備える受信機／デコーダまで拡張し、第１モードでは、描画によって影響を及ぼされる可能性のあるウィンドウのクライアントにそのウィンドウの少なくとも部分を再描画するように命令する信号が、各描画動作の後に送信され、第２モードでは、信号の送信が抑制される。
信号はウィンドウマネージャから送信されてよい。信号はウィンドウのクライアントから送信されてよく、好ましくは描画を実施したクライアントによって送信され、好ましくはウィンドウマネージャに送信される。
【００３７】
受信機／デコーダは、さらに、ウィンドウの透過性に関係する情報をウィンドウマネージャが使用できるようにするための手段を備える。それは、さらに、ウィンドウの属性として情報を記憶するための手段を備えてよい。それは、さらに、好ましくはメッセージの中で、または関数呼び出しによってウィンドウマネージャに情報を送信するための手段を備えてよい。
信号の送信は、情報に依存して抑制されてよい。信号の送信は、ウィンドウの関係性に依存して抑制されてよい。
【００３８】
受信機／デコーダは、さらに、数多くの描画動作の後に信号を送信するための手段を備えてよく、数は、好ましくは少なくとも１つの描画動作の前に決定され、好ましくは１、３、５、１０、３０、５０または１００より大きい。
受信機／デコーダは、さらに、影響を及ぼされてよいウィンドウの少なくとも一部を再描画するための手段を備えてよい。
【００３９】
発明の装置態様においては、ウィンドウのサイズを定めるための手段、ウィンドウに前景オブジェクトを描画するための手段、及び背景の下にあるオブジェクトが可視であるように、ウィンドウの背景を配列するための手段を備えるウィンドウを表示するための装置が提供される。
装置は、さらに、ウィンドウのフレームを描画するための手段を備えてよい。
前景オブジェクトを描画するための手段は、前景ピクセルを所望の値に設定するための手段を備えてよく、背景を配列するための手段は、少なくとも１つのピクセル値を未改変のままとする、あるいは背景を定める領域で、少なくとも１つのピクセル値を下にある画像のピクセル値と融合するように適用されてよい。
装置は、さらに、前記ウィンドウに影響を及ぼす追加ウィンドウでの描画が補正できるように、追加ウィンドウ内での描画を監視するための手段を備えてよい。
【００４０】
別の装置態様では、ウィンドウで、好ましくは、上にあるオブジェクトが可視である背景を有する上にあるウィンドウの少なくとも部分的に下にあってよいウィンドウで描画するための装置が提供され、ウィンドウで描画するための手段、及び上にあるウィンドウに影響を及ぼす描画が訂正できるように描画を監視するための手段を備える。
装置は、さらに、描画によって影響を及ぼされる可能性のあるウィンドウを決定するための手段と、影響を及ぼされる可能性のあるウィンドウのクライアントにそのウィンドウの少なくとも部分を再描画するように命令する信号を送信するための手段とを備えてよい。
装置は、各描画動作の後に信号を送信するように適応されてよいか、あるいは装置は少なくとも１つの描画動作のために信号の送信を抑制するように適応されてよい。
【００４１】
別の装置態様では、ウィンドウに、好ましくは、下にあるオブジェクトが可視である背景を有するウィンドウの下に少なくとも部分的にあってよいウィンドウに描画するための装置が提供され、該装置は、各描画動作の後に、描画によって影響を及ぼされる可能性のあるウィンドウのクライアントにそのウィンドウの少なくとも一部を再描画するように命令する信号が送信される第１モード、及び信号の送信が抑制される第２モードを有する。
装置は、ウィンドウの関係性に依存して信号の送信を抑制するように適応されてよい。装置は、数多くの描画動作の後に信号を送信するように適応されてよい。
装置は、さらに、影響を及ぼされる可能性のあるウィンドウの少なくとも部分を再描画するための手段を備えてよい。
【００４２】
別の装置態様では、ウィンドウ内での描画が監視され、信号が、描画によって影響を及ぼされる可能性のある少なくとも１つのその他のウィンドウに送信される複数ウィンドウ制御システムで描画するための装置が提供され、装置は、少なくとも１つのその他のウィンドウに対する信号が少なくとも１つの描画動作の間に抑制されるモードを選択するための手段を備える。
装置は、さらに、前記少なくとも１つの描画動作の後に、前記少なくとも１つのその他のウィンドウに信号が送信されるモードを選択するための手段を備えてよい。信号は、描画によって影響を及ぼされる可能性のあるウィンドウのクライアントに、そのウィンドウの少なくとも一部を再描画するように命令する信号であってよい。
【００４３】
関係する態様では、本発明は、
ウィンドウに描画するための（典型的にはプロセッサの形を取る）手段と、
ウィンドウ内の描画を監視するための、及び描画によって影響を及ぼされる可能性のある少なくとも１つのその他のウィンドウに信号を送信するための（典型的にはプロセッサの形を取る）手段と、
少なくとも１つのその他のウィンドウへの信号が少なくとも１つの描画動作の間抑制されるモードを選択するための（典型的にはプロセッサの形を取る）手段と、
を備える、複数ウィンドウ制御システムで描画するための装置を提供する。
装置は、好ましくは、前記少なくとも１つの描画動作の後に、信号が前記少なくとも１つのその他のウィンドウに送信されるモードを選択するための手段を備える。信号は、描画によって影響を及ぼされる可能性のあるウィンドウのクライアントに、そのウィンドウの少なくとも部分を再描画するように命令する信号であってよい。
【００４４】
発明は、さらに、
ウィンドウを表示するための（典型的にはプロセッサの形を取る）手段と、
ウィンドウのディスプレイを管理するためのウィンドウマネージャと、
ウィンドウの透過性に関係する情報をウィンドウマネージャに渡すための（典型的にはプロセッサの形を取る）手段と、
を備える、ウィンドウを表示するための装置まで拡張する。
好ましくは、ウィンドウマネージャは、バーチャルマシンの部分を形成する。
【００４５】
発明は、また、
ナビゲータディスプレイが、透過的な背景を有する少なくとも１つのウィンドウを備えるように、ナビゲータディスプレイを表示するための（典型的にはプロセッサの形を取る）手段を備える、ナビゲータディスプレイを表示するための装置まで拡張する。
【００４６】
前記装置のいずれかは、受信機／デコーダであってよく、従って発明はさらに前述されたように装置を備える受信機／デコーダまで拡張する。
発明は、前述されたような受信機／デコーダと、該受信機／デコーダに接続可能なテレビセットを備えるテレビシステムまで拡張する。それは、また、前述されたような受信機／デコーダ及び該受信機／デコーダに接続されているテレビセットを備えるテレビシステムまで拡張する。
【００４７】
本発明によって、
第１ウィンドウ及び第２ウィンドウを表示するための（典型的にはプロセッサの形を取る）手段であって、少なくとも第１ウィンドウが下にあるオブジェクトが可視である背景を有する手段と、
第１ウィンドウが第２ウィンドウに重複するかどうかを判断するための（典型的にはプロセッサの形を取る）手段と、
第２ウィンドウに描画するための（典型的にはプロセッサの形を取る）手段と、
第１ウィンドウが第２ウィンドウに重複する場合に、第１ウィンドウの少なくとも部分を再描画するための（典型的にはプロセッサの形を取る）手段と、
を備える、画面上にウィンドウを表示するための受信機／デコーダが追加態様で提供される。
【００４８】
本発明によって、受信機／デコーダと使用するためのコンピュータプログラム製品が追加態様で提供され、（プログラムの制御下にある）前記コンピュータプログラム製品は、画面上にウィンドウを表示するための符号を備え、そこではウィンドウが下にあるオブジェクトが可視である背景を有し、該受信機／デコーダが好ましくはテレビセットと使用するためである。
コンピュータプログラム製品は、例えば、ハードディスクまたは揮発性メモリまたは不揮発性メモリなどの記憶装置媒体上に記憶されるソフトウェアとして、あるいは信号として有形に実現されてよい。
【００４９】
コンピュータプログラム製品は、さらに、ウィンドウのフレームを描画するための符号を備えてよい。
好ましくは、表示符号は、ウィンドウディスプレイを備える画面の部分を形成するウィンドウを表示するように適応され、製品は、さらに、ビデオ画像とウィンドウディスプレイを結合するための符号を備える。表示符号は、テレビ画面にウィンドウを表示するように適応される。
コンピュータプログラム製品は、さらに、
ウィンドウのサイズを定めるための符号と、
ウィンドウに前景オブジェクトを描画するための符号と、
ウィンドウの背景を配列するための符号と、
を備えてよい。
【００５０】
発明は、
ウィンドウを表示するための符号と、
ウィンドウのサイズを定めるための符号と、
ウィンドウに前景オブジェクトを描画するための符号と、
背景の下にあるオブジェクトが可視であるように、ウィンドウの背景を配列するための符号と、
を備えるコンピュータプログラム製品まで拡張する。
【００５１】
好ましくは、前景オブジェクトを描画するための符号は、前景ピクセルを所望される値に設定するように適応される。好ましくは、前景オブジェクトは、直線、曲線、ボックス、円、三角形及び活字印刷用の文字のいずれかまたは全てを備え、好ましくは、少なくとも２つの描画動作で描画するように適応される。好ましくは、前景オブジェクトは、対話型制御機構を備える。
配列する符号は、背景を確定する領域内で少なくとも１つのピクセル値を未改変のままにするように適応されてよい。配列する符号は、背景を画定する領域内で、少なくとも１つのピクセル値を下にある画像のピクセル値に融合するように適応されてよい。配列する符号は、少なくとも１つの前景ピクセルを未改変にしておくように適応されてよい。
【００５２】
背景の下にあるオブジェクトの内の少なくとも１つが、ウェブページの要素を備えてよい。
好ましくは、コンピュータプログラム製品は、さらに、下にあるオブジェクトが可視である背景を有する追加ウィンドウを表示するための符号を備える。
第１ウィンドウの少なくとも一部は追加ウィンドウの下にある。
コンピュータプログラム製品は、さらに、前記ウィンドウに影響を及ぼす追加ウィンドウ内での描画が補正できるように、追加ウィンドウでの描画を監視するための符号を備えてよい。
【００５３】
発明は、
ウィンドウに描画するための符号と、
上にあるウィンドウに影響を及ぼす描画が補正できるように、描画を監視するための符号と、
を備える、コンピュータプログラム製品まで拡張する。
コンピュータプログラム製品は、図面によって影響を及ぼされる可能性があるウィンドウを決定するため、及び影響を及ぼされる可能性のあるウィンドウのクライアントに、そのウィンドウの少なくとも一部を再描画するように命令する信号を送信するための符号を備えてよい。信号は、Ｊａｖａイベントであってよい。信号は、各描画動作の後に送信されてよい。
好ましくは、コンピュータプログラム製品は、さらに、少なくとも１つの描画動作について信号を抑制するための符号を備える。
【００５４】
発明は、第１モードと第２モードで、ウィンドウに描画するための符号を備えるコンピュータプログラム製品まで拡張し、第１モードでは、描画によって影響を及ぼされる可能性のあるウィンドウのクライアントにそのウィンドウの少なくとも部分を再描画するように命令する信号が各描画動作の後に送信され、第２モードでは、信号の送信が抑制される。
信号は、ウィンドウマネージャから送信されてよい。信号は、ウィンドウのクライアントから送信されてよく、好ましくは、図面を実施したクライアントによって送信され、好ましくはウィンドウマネージャに送信される。
【００５５】
好ましくは、コンピュータプログラム製品は、さらに、ウィンドウの透過性に関係する情報をウィンドウマネージャが入手できるようにするための符号を備える。
好ましくは、コンピュータプログラム製品は、ウィンドウの属性として情報を記憶するための符号を備える。
好ましくは、コンピュータプログラム製品は、さらに、ウィンドウマネージャに、好ましくはメッセージで、あるいは機能呼び出しを介して情報を送信するための符号を備える。
【００５６】
信号の送信は、情報に依存して抑制されてよい。信号の送信は、ウィンドウの関係性に依存して抑制されてよい。
コンピュータプログラム製品は、さらに数多くの描画動作の後に信号を送信するための符号を備えてよく、数は好ましくは少なくとも１つの描画動作の前に決定され、好ましくは１、３、５、１０、３０、５０または１００より大きい。
コンピュータプログラム製品は、影響が及ぼされる可能性のあるウィンドウの少なくとも一部を再描画するための符号を備えてよい。
【００５７】
発明は、
ウィンドウに描画するための符号と、
ウィンドウの描画を監視するための、及び描画によって影響を及ぼされる可能性のある少なくとも１つのその他のウィンドウに信号を送信するための符号と、少なくとも１つのその他のウィンドウへの信号が、少なくとも１つの描画動作のために抑制されるモードを選択するための符号と、
を備える、複数ウィンドウ制御システム内での描画のための装置まで拡張する。
装置は、さらに、前記少なくとも１つの描画動作の後に、信号が前記少なくとも１つのその他のウィンドウに送信されるモードを選択するための符号を備えてよい。信号は、描画によって影響を及ぼされてよいウィンドウのクライアントに、そのウィンドウの少なくとも部分を再描画するように命令する信号であってよい。
【００５８】
発明は、
ウィンドウを表示するための符号と、
ウィンドウの表示を管理するためのウィンドウマネージャと、
ウィンドウの透過性に関する情報をウィンドウマネージャに渡すための符号と、
を備える、ウィンドウを表示するための装置まで拡張する。
ウィンドウマネージャは、バーチャルマシンの一部を形成してよい。
発明は、さらに、ナビゲータディスプレイが、透過的な背景を有する少なくとも１つのウィンドウを備えるように、ナビゲータディスプレイを表示するための符号を備える、ナビゲータディスプレイを表示するための装置まで拡張する。
【００５９】
また、発明は、
少なくとも第１ウィンドウが下にあるオブジェクトが可視である背景を有する、第１ウィンドウ及び第２ウィンドウを表示するための符号と、
第１ウィンドウが第２ウィンドウと重複するかどうかを判断するための符号と、
第２ウィンドウに描画するための符号と、
第１ウィンドウが第２ウィンドウに重複する場合に、第１ウィンドウの少なくとも一部を再描画するための符号と、
を備える、画面上にウィンドウを表示するためのコンピュータプログラム製品まで拡張する。
【００６０】
また、発明は、前述された方法のいずれかを実施するためのプログラムをその上に記憶したコンピュータ読み取り可能媒体、及び前述された方法のいずれかを実施するためのプログラムを備えるコンピュータプログラム製品も提供する。
発明は、さらに、メモリ及びプロセッサを備えるコンピュータプログラム製品まで拡張し、メモリはその中にアプリケーションを記憶し、（アプリケーションの制御下にある）プロセッサは、前述されたように方法を実施するように適応される。
【００６１】
また、発明は、前述されたように方法を実施するためのプログラムを備えるコンピュータプログラム製品まで拡張する。
発明は、まだ、前述されたように方法を実施するためのプログラムをその上に記憶したコンピュータ読み取り可能媒体まで拡張する。
発明は、前述されたようにコンピュータプログラム製品をその上に記憶したコンピュータ読み取り可能媒体まで拡張する。
発明は、前述されたようにコンピュータプログラム製品を有形に実現する信号まで拡張する。
【００６２】
発明は、実質的には、添付の図面を参照して説明されるように、及び添付の図面の描かれるように方法及び装置も提供する。
ある態様の特徴は、その他の態様に適用されてよく、方法の特徴は、装置、受信機／デコーダ、コンピュータプログラム製品、またはコンピュータ読み取り可能媒体のいずれかに、及びその逆に関係する特徴に任意の組み合わせで結合されてよい。例えば、ウィンドウの透過性に関係する情報をウィンドウマネージャ等に渡す方法を実行するナビゲータディスプレイを表示するための装置が提供されてよい。
【００６３】
（デジタルテレビシステム）
デジタルテレビシステム１の概要は、図１に示される。発明は、圧縮されたデジタル信号を伝送するために既知のＭＰＥＧ−２圧縮システムを使用するほとんど従来のデジタルテレビシステム２を含む。さらに詳細には、放送センタ内のＭＥＰＧ−２圧縮機３は、デジタル信号ストリーム（典型的にはビデオ信号のストリーム）を受信する。圧縮機３は、リンケージ５によって、マルチプレクサ及びスクランブラ４に接続される。
【００６４】
マルチプレクサ４は、複数の追加入力信号を受信し、トランスポートストリームをアセンブルし、言うまでもなく、電気通信リンクを含む多岐に渡る形を取ることのあるリンケージ７を介して圧縮されたデジタル信号を放送センタの送信機に伝送する。送信機６は、衛星トランスポンダ９に向かってアップリンク８を介して電磁信号を伝送し、そこでは、それらは電気的に処理され、従来、エンドユーザによって所有される、または賃貸される放物面反射器の形で、概念上のダウンリンク１０を介して接地受信機１２に一斉送信される。地上放送、ケーブル伝送、組み合わされた衛星／ケーブルリンク電話網等の、データの伝送用のそれ以外のトランスポートチャネルは、言うまでもなく可能である。
【００６５】
受信機１２によって受信される信号は、エンドユーザによって所有または賃貸され、エンドユーザのテレビセット１４に接続される統合型受信機／デコーダ１３に伝送される。受信機／デコーダ１３は、テレビセット１４のために圧縮済みのＭＰＥＧ−２信号をテレビ信号に復号する。別個の受信機／デコーダが図１に示されるが、該受信機／デコーダは、統合型デジタルテレビの一部であってもよい。ここで使用されるように、用語「受信機／デコーダ」は、セットトップボックス、及びそこと統合される受信機／デコーダを有するテレビなどの別個の受信機／デコーダを含む。
【００６６】
マルチチャネルシステムにおいては、マルチプレクサ４は、数多くの並列ソースから受信される音声情報及びビデオ情報を取り扱い、対応する数のチャネルに沿って情報を一斉送信するために送信機６と対話する。視聴覚情報に加えて、メッセージまたはアプリケーションあるいはそれ以外の種類のデジタルデータは、伝送されたデジタル音声及びビデオ情報とインタレースされるこれらのチャネルのいくつかまたは全てで導入されてよい。
【００６７】
条件的なアクセスシステム１５は、マルチプレクサ４及び受信機／デコーダ１３と接続され、部分的に放送センタ内、及び部分的に受信機／デコーダ内に位置する。それにより、エンドユーザは、１つまたは複数の放送供給業者からのデジタルテレビ放送にアクセスすることができる。商業的なオファーに関係するメッセージを復号することができるスマートカード（すなわち、放送供給業者によって販売される１つまたは複数のテレビ番組）は、受信機／デコーダ１３に挿入できる。受信機／デコーダ１３及びスマートカードを使用すると、エンドユーザは、加入モードまたは有料視聴モードのどちらかで商業的なオファーを購入してよい。
【００６８】
前述されたように、システムによって伝送される番組はマルチプレクサ４でスクランブルされ、指定される伝送に適用される条件及び暗号化キーはアクセス制御システム１５によって決定される。このようにしてスクランブルされたデータの伝送は、有料テレビシステムの分野では周知である。典型的には、スクランブルされたデータは、データの逆スクランブルのための制御ワードとともに伝送され、該制御ワード自体が、いわゆる活用キーによって暗号化され、暗号化された形式で伝送される。
【００６９】
その後、スクランブルされたデータ及び暗号化された制御ワードは、暗号化された制御ワードを復号し、その後伝送されたデータを逆スクランブルするために受信機／デコーダに挿入されるスマートカード上に記憶される活用キーの同等物にアクセスを有する受信機／デコーダ１３によって受信される。会費を納付し終わった加入者は、例えば、放送月次ＥＭＭ（資格管理メッセージ）の中で、伝送の表示を可能とするために暗号化された制御ワードを復号するために必要な活用キーを受信するだろう。
やはりマルチプレクサ４及び受信機／デコーダ１３に接続され、再び、部分的に放送センタ内に、部分的に受信機／デコーダ内に位置する対話型システムにより、エンドユーザは、モデム化されたバックチャネル１７を介して多様なアプリケーションと対話することができる。
【００７０】
（受信機／デコーダ）
図２を参照すると、受信機／デコーダ１３またはセットトップボックスの要素が、ここで説明されるだろう。この図に図示される要素は、機能ブロックという点で説明されるだろう。
受信機／デコーダ１３は、関連付けられるメモリ要素を含み、直列インタフェース２１、並列インタフェース２２、（図１のモデムバックチャネルに接続される）モデム２３、及びデコーダの前面のスイッチ接点２４から入力データを受信するように適応される中央プロセッサ２０を備える。
【００７１】
受信機／デコーダは、さらに、制御装置２６を介して、赤外線遠隔制御装置２５から入力を受信するように適応され、それぞれバンクまたは加入スマートカード２９、３０を読み取るように適応される２台のスマートカード読取装置２７、２８も所有する。加入スマートカード読取装置２８は、必要な制御ワードをデマルチプレクサ／デスクランブラ３０に供給し、暗号化された放送信号を逆スクランブルできるようにするために、挿入された加入カード３０と、及び条件アクセス装置２９と係合する。デコーダは、装置３０によって濾波され、多重分離される前に、衛星伝送を受信し、復調するために従来のチューナ３１及び復調器３２も含む。
【００７２】
本説明で使用されるように、アプリケーションは、好ましくは、受信機／デコーダ１３の高水準機能を制御するための１つのコンピュータ符号である。例えば、エンドユーザが遠隔制御装置２５の焦点をテレビセット１４の画面で見られるボタンオブジェクト上に配置し、妥当性検査キーを押すと、ボタンに関連付けられる命令シーケンスが実行される。
【００７３】
対話型アプリケーションは、エンドユーザの要求でメニューを提案し、コマンドを実行し、アプリケーションの目的に関係するデータを提供する。アプリケーションは、常駐アプリケーションである、つまり受信機／デコーダ１３のＲＯＭ（またはＦＬＡＳＨまたはその他の不揮発性メモリ）に記憶されるか、あるいは一斉送信され、受信機／デコーダ１３のＲＡＭまたはＦＬＡＳＨメモリの中にダウンロードされるかのどちらかである。
【００７４】
アプリケーションは、受信機／デコーダ１３内のメモリ場所に記憶され、リソースファイルとして表される。該リソースファイルは、グラフィックオブジェクト記述単位ファイル、可変ブロック単位ファイル、命令シーケンスファイル、アプリケーションファイル、及びデータファイルを備える。
【００７５】
受信機／デコーダは、ＲＡＭボリューム、ＦＬＡＳＨボリューム及びＲＯＭボリュームに分割されるメモリを含むが、この物理的な編成は、論理的な編成とは別個である。メモリは、さらに、多様なインタフェースに関連つけられるメモリボリュームに分割されてよい。ある観点からは、メモリはハードウェアの一部として見なすことができる。別の観点からは、メモリは、ハードウェアから離れて図示されるシステムの全体をサポートする、または含むとして見なすこともできる。
【００７６】
受信機／デコーダは、ソフトウェアが任意の受信機／デコーダ内で、及び任意のオペレーティングシステムで実現できる５つのソフトウェア層を含む。図３を参照すると、多様なソフトウェア層は、アプリケーション層５０、アプリケーションプログラミングインタフェース（ＡＰＩ）層５２、バーチャルマシン層５４、デバイス層インタフェース５６、及びシステムソフトウェア／ハードウェア層５８である。多様は層は、後述される。
【００７７】
（アプリケーション層）
アプリケーション層５０は、受信機／デコーダ内に常駐するか、あるいは受信機／デコーダにダウンロードされるかのどちらかであるアプリケーションを包含する。それらは、例えばＪａｖａ、ＨＴＭＬ、ＭＨＥＧ−５またはその他の言語で作成される、カスタマによって使用される対話型アプリケーションであってよいか、あるいはそれらは、このようなアプリケーションを実行するために受信機／デコーダによって使用されるアプリケーションであってよい。この層は、バーチャルマシン層によって提供される開放アプリケーションプログラミングインタフェース（ＡＰＩ）のセットに基づく。このシステムは、アプリケーションを、実行中にまたはオンデマンドで受信機／デコーダ内のフラッシュメモリまたはＲＡＭメモリにダウンロードできるようにする。アプリケーション符号は、データ記憶装置媒体コマンド及び制御（ＤＳＣＭＣＣ）、ネットワークファイルサーバ（ＮＦＳ）などのプロトコル、またはその他のプロトコルを使用して圧縮済みのまたは未圧縮のフォーマットで伝送することができる。
【００７８】
対話型アプリケーションとは、ユーザが、例えば、電子番組表、テレバンキングアプリケーション及びゲームなどの製品及びサービスを得るために対話するアプリケーションである。これらのダウンロードアプリケーション及びデータのために、以下のような多様なセキュリティ機能が提供される。
・最初に意図されたネットワークについて認証されていないと、受信機／デコーダに何もダウンロードすることはできず、これが未登録のソフトウェアが受信機／デコーダで実行されるのを防ぐ。つまり、受信機／デコーダで実行中のソフトウェアは認識され、完全に試験済みである。
・セキュリティマネージャは、多様なメモリゾーンへのアプリケーションのアクセスを制限し、このようにしてデータの整合性を保証する。
・システムは、安全なプロセッサ（例えば、受信機／デコーダに挿入されるスマートカード）を利用する条件アクセスシステムと接続することができる。
【００７９】
以下の常駐アプリケーションは、対話型アプリケーションを管理するために使用される。
・ブート。ブートアプリケーションは、受信機／デコーダの電源投入時に起動される最初のアプリケーションである。ブートアプリケーションは、バーチャルマシンの中で別の「マネージャ」を起動し、第１がアプリケーションマネージャである。
・アプリケーションマネージャ．アプリケーションマネージャは、受信機／デコーダで実行される対話型アプリケーションを管理する。すなわち、それはイベントを開始、停止、中断、再開、処理し、アプリケーション間の通信に対処する。それは、複数のアプリケーションが同時に実行できるようにし、このようにしてそれらの間でのリソースの割り当てに関与する。このアプリケーションは、ユーザにとって完全にトランスペアレントである。
・ＳｅｔＵｐ。ＳｅｔＵｐの目的とは、おもに初めてそれが使用されるときに受信機／デコーダを構成することである。それは、ＴＶチャネルの走査、日付け及び時刻の設定、ユーザ優先順位の確立等を実行する。しかしながら、ＳｅｔＵｐアプリケーションは、受信機／デコーダ構成を変更するためにユーザによって任意の時点で使用することができる。
・ザッピング。ザッピングアプリケーションは、プログラムアップキー、プログラムダウンキー、及び数値キーを使用してチャネルを変更するために使用される。例えばバナー（パイロット）アプリケーションを通して、別の形のザッピングが使用されるとき、ザッピングアプリケーションは停止される。
【００８０】
（ＡＰＩ層）
ＡＰＩ層５２は、対話型アプリケーション開発に高水準ユーティリティを提供する。それは、この高水準ＡＰＩを構成する複数のパッケージを含む。パッケージは、対話型アプリケーションを実行するために必要な全ての機能性を提供する。パッケージはアプリケーションによってアクセス可能である。
好ましい実施形態では、ＡＰＩは、Ｊａｖａプログラミング言語で作成されたアプリケーションを実行するように適応される。さらに、それはＨＴＭＬフォーマット及びＭＰＥＧ−５などのその他のフォーマットを解釈できる。これらのインタプリタのほかに、それは、要件に応じて切り離し自在及び拡張自在である、その他のパッケージ及びサービスモジュールも含む。
【００８１】
（バーチャルマシン層）
バーチャルマシン層５４は、言語インタプリタ及び多様なモジュールとシステムから構成される。それは、以下を含む、受信機／デコーダ内で対話型アプリケーションを受信、実行するために必要な全てから成り立つ。
・言語インタプリタ。さまざまなインタプリタは、読み取られる型のアプリケーションに準じるようにインストールすることができる。これらは、Ｊａｖａ、ＨＴＭＬ、ＨＭＥＧ−５及びその他を含む。
・サービス情報（ＳＩ）エンジン。ＳＩエンジンは、共通のデジタルビデオ放送（ＤＶＢ）または番組システム情報プロトコル（ＰＳＩＰ）テーブルをロード、監視し、それらをキャッシュの中に入れる。それは、その中に含まれるデータを必要とするアプリケーションによるこれらのテーブルへのアクセスを可能にする。
・スケジューラ。このモジュールは、専用のイベント待ち行列を有する各スレッドとのプリエンプティブマルチスレッドスケジューリングに対処する。
・メモリマネージャ。このモジュールは、メモリへのアクセスを管理する。それは、必要なときにメモリ内でデータを自動的に圧縮し、自動ごみ収集を実行する。
・イベントマネージャ。このモジュールは、優先順位に従ってイベントをトリガできるようにする。それは、タイマ及びイベントのグラブを管理し、アプリケーションがイベントを互いに送信できるようにする。
・ダイナミックリンカ。このモジュールは、ネイティブＪａｖａ関数から生じるアドレスの解決を可能とし、ＲＡＭの中にダウンロードされるＪａｖａクラスからネイティブメソッドをロードし、ＲＯＭに向かうダウンロードされたネイティブ符号からの呼び出しを解決する。
・ダウンローダ。このモジュールは、遠隔ＤＳＭＣＣ円形コンベヤから、またはＮＦＳプロトコルを通しての自動データロードを使用し、ダウンロードされたファイルは常駐ファイルと同じようにアクセスされる。メモリクリアアップ、圧縮及び認証も提供される。
・クラスマネージャ。このモジュールはクラスをロードし、問題を参照する任意のクラスを解決する。
・ファイルシステム。このモジュールはコンパクトであり、複数のＲＯＭボリューム、フラッシュボリューム、ＲＡＭボリューム及びＤＳＭＣＣボリュームを含む階層ファイルシステムを管理するために最適化される。フラッシュ整合性は、あらゆる事件に対して保証される。
・セキュリティマネージャ。このモジュールはアプリケーションを認証し、アプリケーションの機密メモリへ及びセットトップボックスのその他のゾーンへのアクセスを制御する。
・グラフィックシステム。このシステムはオブジェクト指向型であり、最適化されている。それは、多言語サポート付きベクタフォントエンジンだけではなくグラフィックウィンドウ及びオブジェクト管理も含む。
さらに、クライアントリソースが効率的に管理されるように、ＤＡＶＩＣリソース通知モデルがサポートされる。
【００８２】
（デバイス層）
デバイス層５６は、デバイスマネージャ及びデバイスを含む。デバイスは、外部イベント及び物理インタフェースの管理に必要な論理リソースから成り立つソフトウェアモジュールである。デバイス層は、デバイスとアプリケーションの間の通信チャネルを管理し、機能拡張されたエラー例外チェックを提供する。管理されるデバイスのいくつかの例は、以下のとおりである。つまり、カード読取装置、モデム、ネットワーク、ＰＣＭＣＩＡ（ＰＣメモリカード国際協会）、ＬＥＤディスプレイ等である。
ＡＰＩ層が上からデバイスを制御するため、プログラマはこの層に直接的に対処する必要はない。
【００８３】
（システムソフトウェア／ハードウェア層）
システムソフトウェア／ハードウェア層５８は、受信機／デコーダの製造メーカによって提供される。システムのモジュラリティのため、及び（イベントスケジューリング及びメモリ管理などの）ＯＳによって供給されるサービスがバーチャルマシンの一部であるため、高水準層は、ある特定のリアルタイムオペレーティングシステム（ＲＴＯＳ）またはある特定のプロセッサに結び付けられない。
【００８４】
（グラフィックシステム）
バーチャルマシン５４の一部であるグラフィックシステム６０が、ここで記述されるだろう。図４を参照すると、グラフィックシステムは、描画されるボタンなどのグラフィックオブジェクト、複数ウィンドウ制御システム６４及びグラフィックライブラリ６８を可能にするウィジェットツールキット６２を備える。複数ウィンドウ制御システム６４は、アプリケーションがウィンドウを描画し、サイズ変更してよいマルチウィンドウシステムを管理する。ウィンドウを描画するアプリケーションは、そのウィンドウのクライアントと呼ばれる。
【００８５】
一例として、アプリケーションは、画面のある領域内に選択肢のメニューを有するウィンドウを作成してよいが、ビデオ画像はウィンドウの後ろの画面全体を横切って示される。この例では、図２を参照すると、メニューはＣＰＵ２０によって作成されるが、ビデオはビデオデコーダ３４から出現する。該２つが、ＣＰＵ２０の制御下でグラフィックプロセッサ２６の中で混合される。さらに複雑な装置も考えられ、複数のウィンドウのそれぞれが、それらの中で静止画像または移動画像を有する。
【００８６】
複数ウィンドウ制御システムは、ウィンドウの間の関係性を定義するウィンドウツリーを維持する。ウィンドウツリーの例は図５に示される。図５を参照すると、ある特定のウィンドウ７０がそこから開かれたウィンドウ７２は、母と呼ばれ、ウィンドウ７０から開かれたウィンドウ７４、７６は娘と呼ばれ、同じ母ウィンドウ７２から開かれたウィンドウ７８、８０は姉妹と呼ばれる。
【００８７】
（透過ウィンドウ）
好ましい実施形態では、複数制御システムは、透過ウィンドウとして知られているウィンドウを管理する。透過ウィンドウは、背景を有さない、すなわちそれを通して下にある画像が少なくとも部分的に見ることができるウィンドウである。透過ウィンドウの原則は、図６に関してここで説明されるだろう。
【００８８】
図６ａは、重なっていない２つのウィンドウ１００、１０２を示す。ウィンドウ１００は、オブジェクト１０４及び不透明な背景１０６を備える。ウィンドウ１０２は２つのオブジェクト１０８，１１０及び不透明な背景１１２を備える。図６ｂは、図６ａの２つのウィンドウが重なるときの状況を示す。このケースでは、上にあるウィンドウは、完全に、２つのウィンドウに共通である領域内の下にあるウィンドウを隠す。図６ｃは、図６ａと同じ状況であるが、上にあるウィンドウが透過ウィンドウと宣言されるケースについて示す。このケースでは、２つのオブジェクト１０８、１１０は、依然として可視であるが、背景１１２は、ウィンドウ１００がそれを通して見えるように、現在、透過的である。図６ｃに図示される例では、背景１１２は単に描画されていない。
【００８９】
透過ウィンドウを使用すると、下にあるウィンドウ内の画像を上にあるウィンドウを通して見ることができるようにする一方で、異なるウィンドウ内で独立した設計を作成できるようにする。また、本発明は、それは透過ウィンドウと非透過ウィンドウの組み合わせから成り立ってよい、複数のウィンドウを表示できるようにする。
【００９０】
透過ウィンドウは、完全に透過的である背景を有してよい、あるいはそれは一定の透過性係数のある背景を有してよく、そのケースでは背景は、該透過性係数に従って下にあるオブジェクトと融合されることが注意されなければならない。透過ウィンドウを管理するには、特定の機構が提供される。これらの機構は、描画が透過ウィンドウの下で占める状況を取り扱う。説明されるように、これを防ぐために特定の処置が講じられない限り、このような描画は、透過ウィンドウ内の画像の破壊という結果にとなることがある。
【００９１】
図７ａは、線が半透明の背景のあるウィンドウの下に描画されるときの状況を示す。このケースでは、線１１４が描画されると、ウィンドウ１０２内で変化は発生しない。図７ｂは、ウィンドウ１０２が透過ウィンドウと宣言されるときの状況を示す。このケースでは、線１１４が描画されると、それはウィンドウ１０２にも表示され、その結果、それがウィンドウ１０２内のオブジェクト１０８と１１０を上書きする。
透過ウィンドウ内でのオブジェクトの上書きを回避する１つの方法とは、描画がウィンドウの下で発生するのを防ぐことである。しかしながら、好ましい実施形態では、透過ウィンドウでのオブジェクトの上書きは、後述されるように補正される。
【００９２】
最初に、描画によって影響を及ぼされる領域が決定される。これは、描画が起こっている間に、描画の最大座標と最小座標を監視することにより行われる。それから、ウィンドウシステムがウィンドウツリーを通して検索し、影響を及ぼされた領域の上にあるあらゆる透過ウィンドウを特定する。それから、いわゆるイベント露呈（Ｅｘｐｏｓｅ  Ｅｖｅｎｔ）が、全てのこのようなウィンドウのクライアントに送信される。イベント露呈は、クライアントに、影響を及ぼされた領域が再描画されなければならないことを知らせる。ウィンドウのクライアントはそのウィンドウのコンテンツに責任を負うため、該クライアントは上書きされたウィンドウで再描画することができる。クライアントは、影響を受けた領域と一致するウィンドウのその部分を再描画する。
【００９３】
イベントの前記シーケンスは、図８に描かれる。図８ａを参照すると、矩形１１６デ囲まれる領域が、線１１４の描画によって影響を及ぼされる領域である。それから、ウィンドウシステムは、ウィンドウ１０２を、影響を及ぼされる領域１１６の上にある透過運リンドウとして特定し、イベント露呈がそのウィンドウに送信される。図８ｂを参照すると、描画により影響を及ぼされるウィンドウ１０２の部分は、矩形１１８によって示されている。それから、矩形１１８内の領域は、クライアントによって再描画される。図８ｃに図示されるように、線１１４の描画によって破壊されたウィンドウ１０２の部分がそれによって再描画され、その結果オブジェクト１０８と１１０はもはや線１１４によって上書きされない。
【００９４】
前記機構は、アプリケーションが、ウィンドウ内に、それが透過ウィンドウによって重ねられていても、上にあるウィンドウ内の画像を破壊せずに画像を描画できるようにする。
（上にあるウィンドウが再描画される回数である）上にあるウィンドウに送信されるイベント露呈の数は、生成される描画コマンドの数に比例する。描画コマンドは、単一の描画動作が起こるたびに生成される。複雑な画像を作成するためには、多数の描画動作が必要とされてよく、それぞれが、例えば、直線または曲線、ボックス、円、またはなんらかのその他のオブジェクトの描画から成り立つ。これは、再描画ウィンドウ専用である大量の処理を生じさせることになり、それがシステムの性能を削減することがある。複数のウィンドウ、特にそのそれぞれがイベント露呈を必要とすることがある、複数の上にある透過ウィンドウが開いている場合、状況はさらに悪化する。
【００９５】
本発明の好ましい実施形態では、生成されるイベント露呈の数、従って上にあるウィンドウが再描画される回数は、一定の状況でのイベント露呈の生成を抑制することによって削減される。ここではｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅと呼ばれる、イベント露呈の生成が抑制されるだろう状況を指定するパラメータが提供される。該パラメータｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅは、クライアントアプリケーションが、イベント露呈がどのウィンドウに送信されるのかを決定するときにどのウィンドウを考慮に入れるのかを定めることができるようにする。
【００９６】
好ましい実施形態では、ｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅパラメータは、イベント露呈に関して以下の状況を定義してよい。
−全てをクリップ：全てのウィンドウが考慮に入れられる通常の関数
−下位者を無視：娘及びその娘が無視される。
―他者を無視：妹でもなく、娘でもない全てのウィンドウは無視される。
−背景を無視：全ての透過ウィンドウが無視される。
−全てを無視：全てのウィンドウが無視される。
クリップ計算から除外されるウィンドウは、イベント露呈を受信せず、従って再描画されない。例えば、妹ウィンドウが、絶対に描画が起こるウィンドウの上にこないことは既知である場合がある。代わりに、描画が完了するまで全ての透過ウィンドウの再描画を延期することが決定される可能性がある。
【００９７】
いったん描画が完了すると、あらゆる影響を及ぼされるウィンドウは再描画されてよい。これは、描画の最大座標及び最小座標を監視することによって行われる。描画完了すると、ｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅパラメータは全てをクリップするように設定される。その後、仮想矩形が、描画の最大座標と最小座標を使用して、全ての影響を及ぼされる領域の回りに描画される。仮想ウィンドウを描画することによって、ウィンドウツリー内の全ての影響を及ぼされるウィンドウに送信されるイベント露呈が生成される。それから、影響を及ぼされる領域と一致する領域を有するウィンドウが、前述されたように再描画される。
【００９８】
要約すると、アプリケーションによって実行される描画動作により影響を及ぼされる透過ウィンドウの再描画を延期することによりさらに大きな効率を得ることができる。
しかしながら、複数ウィンドウ制御システム自体が、例えば、ユーザがウィンドウを移動するまたはサイズ変更する、あるいは重複するウィンドウを移動するまたはサイズ変更する結果としてなど、ウィンドウの部分を再描画することを決定してよいという事実の結果、１つの問題が残る。このケースでは、追加情報なしに、ウィンドウシステムはつねに正しい結果を確実にするためにＥｘｐｏｓｅ  Ｅｖｅｎｔｓを適切なウィンドウに送信する。その結果、より多くのイベント露呈が送信され、従って、クライアントがプロセスを制御していた場合より多くの時間がウィンドウを再描画するのに費やされる。
【００９９】
図９を参照すると、前述された問題及びその解決策が描かれている。図９ａは、２つのウィンドウ、つまり透過ウィンドウＡ１５０と、それが部分的に重複する不透明なウィンドウＢ１５２の典型的な構成を示す。
好ましい実施形態の変形に相当する図９ｂでは、ウィンドウマネージャのウィンドウＢの部分を再描画するという決定の後の、イベント露呈の典型的なシーケンスが描かれている。イベント露呈１６０と１６２を受信するウィンドウＢは再描画され、それによって、ウィンドウＡに送信される追加イベント露呈１６４を生成する。従って、２つのイベント露呈を受信するウィンドウＡが２度再描画される。
【０１００】
好ましい実施形態を描く図９ｃでは、イベント露呈の最適化に関する情報は、ウィンドウＡ１５０のウィンドウ属性によってウィンドウマネージャが入手できるようにされる。この情報を考慮に入れ、追加イベント露呈１７０は、当初ウィンドウＢ１５２だけに送信される。それから、ウィンドウＢのそれ以降の再描画は、それが一度だけ再描画されるように、ウィンドウＡ１５０に送信される必要とされるイベント露呈１７２を作成する。
【０１０１】
好ましい実施形態でイベント露呈の最適化を定めるウィンドウ属性は、（背景ウィンドウ管理なしの代わりの）ｎｏ＿ｂｇ＿ｗｉｎ＿ｍａｎａｇｅｍｅｎｔという名前を有し、以下の値を取る。
−自動：ウィンドウ内の各描画動作により、イベントが透過ウィンドウに送信される。
−ＬｅｔＭｅＤｏＩｔ：いったん多様な再描画が終了すると、クライアントは関数（ＳｅｎｄＥｖｅｎｔＴｏＮｏＢｇＷｉｎｄｏｗ）を呼び出し、再描画の範囲を指定する（典型的には、境界をつける矩形の角を指定する４つの座標を指定する）。この関数が、それがそれに向かってイベント露呈を送信しなければならない透過ウィンドウのゾーンを決定し、このようにして代わりにその再描画を誘発する。イベント露呈の最適化に関する情報は、言うまでもなく、関数呼び出し等のその他の手段を介してウィンドウマネージャが入手できるようにされてよい。
【０１０２】
全体的な効率、使いやすさ、（複数のアプリケーション内で数回の代わりに、ウィンドウマネージャ内に一度だけ存在する透過ウィンドウ管理符号のため）効果的な符号再利用、集中制御、速度等の多くの優位点が、透過ウィンドウの管理をウィンドウマネージャに統合することによって与えられることが、前記から理解できる。
【０１０３】
図１０に関して、ウィンドウマネージャとウィンドウのクライアント（アプリケーション）間の関係性が、ここにさらに詳細に説明される。
画面２０００上の各ウィンドウ２０１０、２０１２、２０１４は、それぞれ対応するウィンドウ定義データブロック２０２０、２０２２、２０２４を有する。各ウィンドウは、ある特定のクライアント（アプリケーション）とも関連付けられる。このケースでは、ウィンドウ２０１０及びその対応するウィンドウ定義データブロック２０２０は、第１アプリケーション２０３０と関連付けられ、ウィンドウ２０１２、２０１４及びその対応するウィンドウ定義データブロック２０２２，２０２４は、アプリケーション２０３２と関連付けられる。ウィンドウマネージャ２０５０は、システム全体を管理し、ウィンドウ定義データブロック２０２０、２０２２、２０２４の全てへのアクセスを有し、イベント、メッセージ及び／または関数呼び出しの使用によって各アプリケーション２０３０、２０３２と通信することができる。
【０１０４】
ウィンドウ定義データブロックは、サイズ、位置、境界様式及び動作のモードなどの対応するウィンドウの状態に関する多様な属性を含み、例えば、前述されたｎｏ＿ｂｇ＿ｗｉｎ＿ｍａｎａｇｅｍｅｎｔ属性を含む。ウィンドウの透過性に関する情報は、ウィンドウ定義データブロックにも記憶できる。
【０１０５】
好ましい実施形態では、ウィンドウ２０１０の透過性に関する情報は、ウィンドウマネージャ２０５０に対する関数呼び出し２０４２によってウィンドウ定義データブロック２０２０内に記憶される。しかしながら、好ましい実施形態に変形では、情報がその他の手段を介してウィンドウマネージャに送信されるか、リンク２０４０によって概略して示されるウィンドウ定義データブロック２０２０に直接的に記憶される。ウィンドウマネージャ２０５０と通信できることに加え、アプリケーションは、リンク２０４４によって概略して示される、互いの間で直接的に通信できる。
【０１０６】
図１１に関して、２つの重複するウィンドウが再描画される例が、ここで説明され、上にある透過ウィンドウの延期された再描画、及び透過ウィンドウの管理のウィンドウマネージャの中への統合という前記特徴を描く。この例では、類似するパーツが類似する番号によって示される。
２つのウィンドウＣ２１００とＤ２１０２のコンテンツが図１１ａに示される。ウィンドウＣ２１００は透過的であり、三角形２１１０と矩形２１１２を備える。ウィンドウＤ２１０２は不透明であり、３本の垂直線２１１４，２１１６、２１１８を備える。
【０１０７】
画面に表示されるとき、図１１ｂに関して、２つのウィンドウは図示されるように重複し、ウィンドウＣ２１００がウィンドウＤ２１０２の上にあり、ウィンドウＤのコンテンツを部分的に隠す。
図１１ｃに関して、リフレッシュイベントがウィンドウＤに関して発生し、ウィンドウ２１０２の不透明な背景２１２０及び境界２１２２を再描画させ、上にある透過ウィンドウＣ２１００を上書きする。加えて、クライアント（アプリケーション）によって実行される第１描画動作では、３本の垂直線２１２４の内の第１が描画される。本例では、ウィンドウマネージャが、ウィンドウの「システム」領域（例えば、境界及び背景）を描画した後に上にあるウィンドウを再描画しないが、好ましい実施形態の変形では、このような再描画は、クライアント（アプリケーション）が「ユーザ」領域を再描画するように要求される前に、実際に発生することが注意される。
【０１０８】
上にあるウィンドウが、それぞれのそれ以降の描画動作の後に再描画される最も簡略なケースが、図１１ｄと図１１ｅに描かれる。図１１ｄでは、上にあるウィンドウＣ２１００が、そのウィンドウへのＥｘｐｏｓｅイベントの送信の後に再描画される。図１１ｅに関して、それから、垂直線２１２６の描画とともに次の描画動作が起こる。前述されたように、このケースでは、上にあるウィンドウは、最終的には、必要とされるより２回多く、合計で３回再描画されるだろう。
【０１０９】
前述されたように、及び図１１ｆに関して、上にあるウィンドウの再描画が延期されるケースでは、全ての３本の垂直線２１２４，２１２６，２１２８が、上にあるウィンドウＣ２１００が再描画される前にウィンドウＤ２１０２内に描画され、その後、ウィンドウは図１１ｂに描かれるようにその正しい外観を有する。
【０１１０】
描画されるオブジェクトが１０個の描画コマンドを必要とする追加例がここで説明され、上にある透過ウィンドウの延期された再描画の特徴を再度浮き彫りにするだろう。前述されたように、オブジェクトは、透過ウィンドウを含む環境で描画されなければならない。
【０１１１】
前述された方法に従って、２つの手順の内の１つが選ばれてよい。第１手順は、以下のとおりである。
１．ｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅパラメータを背景を無視しないに設定する。
２．１０回の描画動作を実行する。全ての透過ウィンドウが無視されるため、イベント露呈は生成されない。
３．ｗｉｎ＿ｏｖｅｒ＿ｍｏｄｅパラメータを全てをクリップに設定する。
４．中に描画されている全ての領域を包含する仮想矩形を描画する。この動作は、影響を及ぼされるウィンドウに送信されるイベント露呈を生成する。
【０１１２】
選ばれてよい第２のより短い手順は、以下のとおりである。
１．ｎｏ＿ｂｇ＿ｗｉｎ＿ｍａｎａｇｅｍｅｎｔ属性をＬｅｔＭｅＤｏＩｔに設定する。
２．１０回の描画動作を実行する。全ての透過ウィンドウは無視されるため、イベント露呈は生成されない。
３．描画動作の物理的な範囲をパラメータとして渡すＳｅｎｔＥｖｅｎｔＴｏＮｏＢｇＷｉｎｄｏｗ（）を呼び出す。それから、イベント露呈が影響を及ぼされるウィンドウに送信される。
両方の手順は同じ結果を達成することが注意される。
【０１１３】
前記例では、ケースでのように、１０回再描画される影響を及ぼされるウィンドウよりむしろ、当てはまるように、イベント露呈が描画コマンドごとに生成された場合、ウィンドウは一度再描画されるにすぎない。このようにして、処理におけるかなりの節約が行われてよい。
【０１１４】
好ましい実施形態の変形では、ウィンドウを再描画する追加の方法が利用される。この方法は、指定数の描画動作の後に、上にあるウィンドウを再描画するために信号を送信することを備え、この場合、番号は、通常、描画動作の前に決定される。合計１０回の描画動作が必要とされた前記例に関して、選ばれた番号が５であった場合、あらゆる上にあるウィンドウが、５回めの及び１０回めの描画動作の後に再描画されるだろう。
【０１１５】
この再描画する方法は、各再描画動作の後に再描画が発生した場合より少ない頻度で再描画する優位点を提供するが、多数の連続描画動作が実行されている場合にも画面を相対的に頻繁にリフレッシュされた状態に保つという追加優位点を提供する。リフレッシュを待機するための描画動作の数は、例えば、現在のプロセッサ負荷に応じて、１から上方へのほぼ任意の数であってよい（が、典型的には１と１０００の間だろう）。カウント及び再描画の取り扱いは、クライアントによって、またはウィンドウマネージャによってのどちらかによって処理されてよい。
【０１１６】
透過ウィンドウの描画の延期に関して前述された最適化の使用は、アプリケーションが透過ウィンドウを使用し、関係する処理の量を大幅に削減できるようにする。これは、処理電力が限られる可能性がある受信機／デコーダなどの環境で特に有利である。
【０１１７】
特に、受信機／デコーダに対する追加優位点も与えられる。ウィンドウは、互いの上にさらに効果的に積み重ねることができるため、例えば、透過ウィンドウの使用は、典型的には、さらに小さな複数ウィンドウ制御ディスプレイを提供できるようにする。典型的に使用中の複数ウィンドウ制御ディスプレイが（ビデオデコーダから及び複数ウィンドウ制御システムからの両方から入力を採取する、前述されたグラフィックプロセッサによって）ビデオ画像の上に置かれ、ビデオ画像の少ない方が隠されるだろうため、より小さい複数ウィンドウ制御はきわめて優先的である。
【０１１８】
さらに、（融合方法と対照的に）典型的に利用される透過ウィンドウを表示する方法は、（通常、例えばコンピュータモニタほど高い解像度をサポートできない）テレビに表示されるときにさらに高いコントラストの画像を生じさせる結果となる。
【０１１９】
図１２から図１５に関して、前述された透過複数ウィンドウ制御システムの特定のアプリケーション、すなわち、受信機／デコーダ用のインターネットブラウザアプリケーションに関する追加例が説明されるだろう。
図１２は、インターネットブラウザのメイン画面ナビゲータディスプレイの画面ショットを示す。メイン画面は、リンク済みリストとして多様なボタンを含むメインメニューを含む垂直チェーン１１００を示す。ボタンは、チェーンのリンク要素によってリンクされる。図１２のチェーン１１００に示されるボタンは、ＲＥＬＯＡＤ／ＳＴＯＰ（再ロード／停止）ボタン１１００、ＰＲＥＶＩＯＵＳ（前）ボタン１１２０、ＮＥＸＴ（次）ボタン１１３０、ＨＩＳＴＯＲＹ（履歴）ボタン１１４０、ＢＯＯＫＭＡＲＫ（ブックマーク）ボタン１１５０、ＳＥＴＴＩＮＧＳ（設定値）ボタン１６０及びＱＵＩＴ（終了）ボタンを含む。
【０１２０】
メインメニューチェーン１１００は、画面１１０１に表示されるハイパテキストマーク付け言語（ＨＴＭＬ）文書の上に重ねられるように配列される。図１２では、ＨＴＭＬ文書は表示されず、画面１１０１はメインメニューチェーン１１００から離れた空白である。
ユーザは、彼が、それを用いて画面１１０１上のオブジェクト間で探査し、オブジェクトを強調表示し、オブジェクトを選択することができる制御装置を有する。本例では、使用される制御装置はテレビ遠隔制御装置である。ＨＴＭＬページが表示されると、遠隔制御装置の任意のボタンがチェーン１１００（ツールバー）を呼び出す。チェーン１１００は、ユーザによってオン及びオフにすることもできる。
【０１２１】
図１３は、ＨＴＭＬ文書が開いている図１２の画面を示す。図１３では、ＰＲＥＶＩＯＵＳボタン１１２０が、いま強調表示される。
図１４は、強調表示がＰＲＥＶＩＯＵＳボタン１１２０の上にあるときに、どのようにしてテキストボックス１１２２を備える「ツールチップ」が画面上に表示されるのかを示す。本例では、ツールチップは、関連するアイコンが強調表示されるとすぐに表示される。優先順位は、ツールチップが、ボタンが強調表示されるときに遅延後に表示されるように設定できるだろう。テキストボックス１１２２は、ＰＲＥＶＩＯＵＳボタン１１２０の機能を示すために、ワード「前」を示す。ＰＲＥＶＩＯＵＳボタンを活性化することによって、ＳＥＬＥＣＴ（選択）キー１１８６を押すことによって、ブラウザは、表示されていた前のページに移動する。
【０１２２】
図１２から図１４の説明に戻る前に、（とりわけ）前記ナビゲーションチェーンを描画するために使用される「ウィジェットセット」が、ここで説明されるだろう。このようなウィジェットセットの１つの特定のアプリケーションは、デジタルテレビ用受信機／デコーダのＧＵＩディスプレイにウィジェットを提供することである。とりわけ、ウィジェットセットは、とりわけウィンドウ及びダイアログボックスフレーム、スライダ制御、プッシュボタン、チェックボックス、テキストフィールド及びテキスト編集ボックスを含むプリミティブなウィジェットクラスの集合を含む。
【０１２３】
ウィジェットクラスのそれぞれが、メソッド及びイベントハンドラを実現し、ウィジェットの動作を制御する。ウィジェットクラスは、ウィジェットのいくつかの部分を描画するための方法も含んでよい。しかしながら、ある特定の外観、またはウィジェットのある特定の外観つまり「型」を提供するために、ウィジェットクラスは、ウィジェットクラスが関連付けられる外観オブジェクトクラスのメソッドの描画を呼び出す。
【０１２４】
外観は、とりわけ、色の定義を含み、その結果、ある特定の外観インスタンスと関連付けられる任意のウィジェットインスタンスがその外観インスタンス内で定められる色を使用するだろう。１つの実施形態では、外観が、黒、暗い灰色、真ん中の灰色、非常に明るい灰色、白、及び強調表示色などの複数の色を定義する。重要なことに、及び加えて、それは透過的色も定める。
【０１２５】
図１５は、ウェブページが下（１４１１）で可視である、前述されたナビゲータ関数ボタン（１４１０）のトップレベルチェーンをさらに詳しく示す。
前述されたように、メイン画面は、一連のボタンから構成される垂直バー（メインメニュー）（１４１０）を表示する。ボタンは、実質的には矩形または正方形のゾーンである（例えば、３２ｘ３２ピクセル）。グラフィックスカーソルがあるゾーンに進入すると、そのゾーン（ウィンドウ）は、焦点を受信する。
【０１２６】
前記を鑑みて、人は、各ゾーンがウィンドウであり、図１５から観察されるように、これらのウィンドウのそれぞれの背景は透過的にとなるように配列され、その結果、ツールバーの各ボタンが、インターネットブラウザの上に置かれるとき、明らかに非矩形の形状を有することを可能にすると要約することができる。インターネットブラウザの設計者にさらに多くの柔軟性を与えることとは別に、これは、その結果生じる優位点とのボタンのさらにコンパクトな配列を可能にすることができる。
前記インターネットブラウザ及びナビゲーションツールバーの構造及び機能は、Ｃａｎａｌ＋  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｓｏｃｉｅｔｅ  Ａｎｏｎｙｍｅの名前で欧州特許出願番号第００３０００８３２．３号にさらに詳細に説明される。
【０１２７】
本発明は、純粋に例として前述されており、詳細の修正は、本発明の範囲内で行うことができることが理解されるだろう。
説明中に開示されるそれぞれの特徴、及び（適切な場合には）クレームと図面は、独立して、または任意の適切な組み合わせで提供されてよい。
クレームの中に表示される参照番号は、例によってのみであり、クレームの範囲に制限的な影響を及ぼさないものとする。
本発明の好ましい特徴は、ここで添付図面に関して純粋に例によって記述されるだろう。
【図面の簡単な説明】
【図１】  図１は典型的なデジタルテレビシステムのアーキテクチャを示す。
【図２】  図２は受信機／デコーダのブロック図である。
【図３】  図３は受信機／デコーダのアーキテクチャを示す。
【図４】  図４はグラフィックシステムの構造を示す。
【図５】  図５は多様なウィンドウの相互関係性を示す。
【図６】  図６は透過ウィンドウの原則を描く。
【図７】  図７はウィンドウの下にあるオブジェクトの描画を描く。
【図８】  図８は透過ウィンドウシステムでの再描画の管理を描く。
【図９】  図９は２つの重複するウィンドウを再描画する、異なるモードを描く。
【図１０】  図１０はアプリケーションとウィンドウマネージャの間の関係性を示す。
【図１１】  図１１は２つのウィンドウの再描画中の描画動作の典型的なシーケンスを描く。
【図１２】  図１２はウェブブラウザの画面ディスプレイを描く。
【図１３】  図１３はウェブブラウザの追加画面ディスプレイを描く。
【図１４】  図１４はウェブブラウザの追加画面ディスプレイを描く。
【図１５】  図１５はウェブブラウザの追加画面ディスプレイを描く。
【図１】
0004785312.tif 000002
【図２】
0004785312.tif 000003
【図３】
0004785312.tif 000004
【図４】
0004785312.tif 000005
【図５】
0004785312.tif 000006
【図６（ａ）】
0004785312.tif 000007
【図６（ｂ）】
0004785312.tif 000008
【図６（ｃ）】
0004785312.tif 000009
【図７（ａ）】
0004785312.tif 000010
【図７（ｂ）】
0004785312.tif 000011
【図８（ａ）】
0004785312.tif 000012
【図８（ｂ）】
0004785312.tif 000013
【図８（ｃ）】
0004785312.tif 000014
【図９（ａ）】
0004785312.tif 000015
【図９（ｂ）】
0004785312.tif 000016
【図９（ｃ）】
0004785312.tif 000017
【図１０】
0004785312.tif 000018
【図１１（ａ）】
0004785312.tif 000019
【図１１（ｂ）】
0004785312.tif 000020
【図１１（ｃ）】
0004785312.tif 000021
【図１１（ｄ）】
0004785312.tif 000022
【図１１（ｅ）】
0004785312.tif 000023
【図１１（ｆ）】
0004785312.tif 000024
【図１２】
0004785312.tif 000025
【図１３】
0004785312.tif 000026
【図１４】
0004785312.tif 000027
【図１５】
0004785312.tif 000028