(57)【要約】  多重スクリーンを提供する装置及びその多重スクリーンの動的構成方法が提案される。多重スクリーンを提供する装置は、物理的なディスプレイ画面に複数個のサービスを表現する複数のスクリーンを動的に構成するために装置に存在するスクリーンの形態及び連結関係を検索する。多重スクリーンを提供する装置は、受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成する動作モジュールと、スクリーンのうち、サービスに含まれたアプリケーションが実行されるスクリーンを検索する検索モジュールと、を備える。
2009503605.tif 000002
【特許請求の範囲】
【請求項１】
受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成する動作モジュールと、
前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項２】
前記スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項３】
前記スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項４】
前記検索モジュールは、前記実行されたスクリーンの設定形態を検索することを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項５】
前記設定形態は、前記アプリケーションが実行されたスクリーンが出力スクリーンに対応する単一スクリーン形態と、
前記単一スクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた論理スクリーンに対応し、出力スクリーンにマッピングされた少なくとも一つ以上のオーバーレイされていない論理スクリーンに対応し、オーバーレイスクリーンに対応しないＰｉＰスクリーン形態と、
前記ＰｉＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｉＰスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた少なくとも二つ以上の非重複論理スクリーンの組み合わせに対応し、オーバーレイスクリーンに対応しないＰｏＰスクリーン形態と、
前記ＰｏＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｏＰスクリーン形態と、
一般形態のうち少なくとも一つを含むことを特徴とする請求項４に記載の多重スクリーンを提供する装置。
【請求項６】
前記動作モジュールは、前記アプリケーションが実行される論理スクリーンを出力スクリーンに配置することを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項７】
前記動作モジュールは、前記アプリケーションを出力スクリーン上で動作させることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項８】
受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記生成されたあらゆる論理スクリーン及び出力スクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項９】
前記検索モジュールは、前記サービスに含まれた所定のアプリケーションの権限範囲に含まれた論理スクリーン及び出力スクリーンに対してのみ検索することを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１０】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１１】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１２】
受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記論理スクリーン及び前記出力スクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項１３】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１２に記載の多重スクリーンを提供する装置。
【請求項１４】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１２に記載の多重スクリーンを提供する装置。
【請求項１５】
サービスを受信する放送信号受信モジュールと、
論理スクリーン及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項１６】
前記検索モジュールは、前記サービスを表現するスクリーンが前記論理スクリーンである場合、前記出力スクリーン上での前記論理スクリーンの位置、サイズ及び前記出力スクリーン上に存在する他の論理スクリーンと前記論理スクリーンとの重複関係を検索することを特徴とする請求項１５に記載の多重スクリーンを提供する装置。
【請求項１７】
前記検索モジュールは、前記サービスを表現するスクリーンのサービスコンテキストを検索することを特徴とする請求項１５に記載の多重スクリーンを提供する装置。
【請求項１８】
受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成するステップと、
前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項１９】
前記スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２０】
前記スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２１】
前記検索するステップは、前記実行されたスクリーンの設定形態を検索するステップを含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２２】
前記設定形態は、前記アプリケーションが実行されたスクリーンが出力スクリーンに対応する単一スクリーン形態と、
前記単一スクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた論理スクリーンに対応し、出力スクリーンにマッピングされた少なくとも一つ以上のオーバーレイされていない論理スクリーンに対応し、オーバーレイスクリーンに対応しないＰｉＰスクリーン形態と、
前記ＰｉＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｉＰスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた少なくとも二つ以上の非重複論理スクリーンの組み合わせに対応し、オーバーレイスクリーンに対応しないＰｏＰスクリーン形態と、
前記ＰｏＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｏＰスクリーン形態と、
一般形態のうち少なくとも一つを含むことを特徴とする請求項２１に記載の多重スクリーンの動的構成方法。
【請求項２３】
前記アプリケーションが実行される論理スクリーンを出力スクリーンに配置するステップをさらに含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２４】
前記アプリケーションを出力スクリーン上で動作させるステップをさらに含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２５】
受信されたサービスを表現するための論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記あらゆる論理スクリーン及び出力スクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項２６】
前記検索するステップは、前記サービスに含まれたアプリケーションの権限範囲に含まれた論理スクリーン及び出力スクリーンに対してのみ検索するステップを含むことを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２７】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２８】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２９】
受信されたサービスを表現するための論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記論理スクリーン及び前記出力スクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項３０】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項２９に記載の多重スクリーンの動的構成方法。
【請求項３１】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項２９に記載の多重スクリーンの動的構成方法。
【請求項３２】
サービスを受信するステップと、
論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項３３】
前記検索するステップは、前記サービスを表現するスクリーンが前記論理スクリーンである場合、前記出力スクリーン上での前記論理スクリーンの位置、サイズ及び前記出力スクリーン上に存在する他の論理スクリーンと前記論理スクリーンとの重複関係を検索するステップを含むことを特徴とする請求項３２に記載の多重スクリーンの動的構成方法。
【請求項３４】
前記検索するステップは、前記サービスを表現するスクリーンのサービスコンテキストを検索するステップを含むことを特徴とする請求項３２に記載の多重スクリーンの動的構成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明による装置及び方法は、多重スクリーンの提供及び前記多重スクリーンの動的構成に係り、特に物理的なディスプレイ画面に複数個のサービスを表現する複数のスクリーンを動的に構成するために装置に存在するスクリーンの形態及び連結関係の検索に関する。
【背景技術】
【０００２】
従来のデジタルＴＶまたはデジタルセットトップボックスのような放送受信装置では、一つの物理的なディスプレイ画面に一つのコンテンツのみを表すか、または一つの物理的なディスプレイ画面に主画面と副画面との二つの画面を同時に表す場合が一般的である。
【０００３】
このとき、主画面と副画面とを同時に表す場合であっても、放送受信装置で既定の数個の方式でのみ二つの画面を配置できるだけである。そして、主画面に表れるコンテンツの場合にのみコンテンツを構成するあらゆる要素（ビデオ、オーディオ、データまたはそれらの組み合わせ）が再生され、副画面を通じてはコンテンツを構成する一部要素のみが制限的に再生される。
【０００４】
また、コンテンツを提供するソースとして、衛星放送、地上波放送、ケーブル放送のような放送サービス以外にも、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）のような記録媒体または外部入力端子と連結された外部機器などがあるが、このように多様なソースで提供されるコンテンツをどのようにディスプレイ画面に表すかに対しても制限的に固定されている。
【０００５】
一方、ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ  Ｃｏｍｍｏｎ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｌａｔｆｏｒｍ）、ＯＣＡＰ（Ｏｐｅｎ  Ｃａｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｌａｔｆｏｒｍ）のようなインタラクティブＴＶに対するアプリケーションプログラム環境では、一般的に物理的なディスプレイ画面を通じて出力されるスクリーンは一つと仮定する。
【０００６】
例えば、インタラクティブＴＶに対するアプリケーションプログラム環境では、ＨＡＶｉ（Ｈｏｍｅ  Ａｕｄｉｏ／Ｖｉｄｅｏ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）規格によるユーザーインターフェース（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ：ＵＩ）の構造を採用しているが、ＨＡＶｉ  ＵＩ標準でスクリーンの個数を制限していないが、実際の使用では、ディスプレイ画面を通じて出力されるスクリーンは一つと仮定することが通常である。
【０００７】
かかる環境では、複数のコンテンツを複数の独立的なスクリーンを通じて表すと共に、それぞれのスクリーンに表現されたコンテンツに対してデコーディング、デジタル信号処理、ユーザーインタラクション処理などを行うか、または動的にアプリケーションプログラムのライフサイクルとリソースの使用とをそれぞれのスクリーン別に制御し難い。
【０００８】
したがって、多様なコンテンツを多様な方式でディスプレイ画面に構成して提供できる方法が必要になった。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、物理的なディスプレイ画面に複数個のサービスを表現する複数のスクリーンを動的に構成するために、システムに存在するスクリーンの形態及び連結関係を検索する多重スクリーンを提供する装置及び方法を提案するところにある。
【課題を解決するための手段】
【００１０】
前記目的を達成するために、本発明の実施形態による多重スクリーンを提供する装置は、受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成する動作モジュールと、前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索する検索モジュールと、を備える。
【００１１】
本発明の実施形態による多重スクリーンを提供する装置は、受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、前記生成されたあらゆる論理スクリーン及び出力スクリーンを検索する検索モジュールと、を備える。
【００１２】
本発明の実施形態による多重スクリーンを提供する装置は、受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、前記論理スクリーン及び前記出力スクリーンを検索する検索モジュールと、を備える。
【００１３】
本発明の実施形態による多重スクリーンを提供する装置は、サービスを受信する放送信号受信モジュールと、論理スクリーン及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索する検索モジュールと、を備える。
【００１４】
本発明の実施形態による多重スクリーンの動的構成方法は、受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成するステップと、前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索するステップと、を含む。
【００１５】
本発明の実施形態による多重スクリーンの動的構成方法は、受信されたサービスを表現するための論理スクリーンを生成するステップと、前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、前記生成されたあらゆる論理スクリーン及び出力スクリーンを検索するステップと、を含む。
【００１６】
本発明の実施形態による多重スクリーンの動的構成方法は、受信されたサービスを表現するための論理スクリーンを生成するステップと、前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、前記論理スクリーン及び前記出力スクリーンを検索するステップと、を含む。
【００１７】
本発明の実施形態による多重スクリーンの動的構成方法は、サービスを受信するステップと、論理スクリーンを生成するステップと、前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索するステップと、を含む。
【００１８】
その他の実施形態の具体的な事項は、詳細な説明及び図面に含まれている。
【発明を実施するための最良の形態】
【００１９】
本発明の利点及び特徴、それらを達成する方法は、添付される図面と共に詳細に後述されている実施形態を参照すれば明確になる。しかし、本発明は、後述する実施形態に限定されるものではなく、異なる多様な形態で具現され、単に本実施形態は、本発明の開示を完全にし、当業者に発明の範疇を完全に知らせるために提供されるものであり、本発明は、特許請求の範囲により定義されるだけである。明細書の全体にわたって、同じ参照符号は同じ構成要素を指す。
【００２０】
以下、本発明の実施形態による多重スクリーンを提供する装置、及び前記多重スクリーンを動的に構成する方法を説明するためのブロック図または処理フローチャートに対する図面を参考にして、本発明について説明する。このとき、処理フローチャートの各ブロック及びフローチャートの組み合わせは、コンピュータプログラムインストラクションにより行われるということを理解できるであろう。それらのコンピュータプログラムインストラクションは、汎用コンピュータ、特殊用コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサに搭載されるので、コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサを通じて行われるそのインストラクションが、フローチャートのブロックで説明された機能を行う手段を生成する。
【００２１】
それらのコンピュータプログラムインストラクションは、特定の方式で機能を具現するために、コンピュータまたはその他のプログラム可能なデータプロセシング装備を指向できるコンピュータで利用可能またはコンピュータで読み取り可能なメモリに保存されることも可能であるので、そのコンピュータで利用可能な、またはコンピュータで読み取り可能なメモリに保存されたインストラクションは、フローチャートブロックで説明された機能を行うインストラクション手段を備える製造品目を生産することも可能である。
【００２２】
コンピュータプログラムインストラクションは、コンピュータまたはその他のプログラム可能なデータプロセシング装備上に搭載されることも可能であるので、コンピュータまたはその他のプログラム可能なデータプロセシング装備上で一連の動作ステップが行われてコンピュータで実行されるプロセスを生成して、コンピュータまたはその他のプログラム可能なデータプロセシング装備を行うインストラクションは、フローチャートブロックで説明された機能を実行するためのステップを提供することも可能である。
【００２３】
また、各ブロックは、特定の論理的機能を実行するための一つ以上の実行可能なインストラクションを含むモジュール、セグメントまたはコードの一部を表す。また、幾つかの代替実行例では、ブロックで言及された機能が順序を逸脱して発生することも可能であるということを注目せねばならない。例えば、続いて図示されている二つのブロックは、実質的に同時に行われてもよく、そのブロックが時々該当する機能によって逆順で行われてもよい。
【００２４】
一方、本発明についての説明を容易にするために、本発明と関連した基本的な概念を定義する。
【００２５】
‘サービス’は、一つになって表現されるマルチメディアコンテンツであって、複数のサービスコンポーネントが一つのサービスをなす。
【００２６】
‘サービスコンポーネント’は、サービスを構成する一部分であって、ビデオコンポーネント、オーディオコンポーネント、データコンポーネントなどを含む。このとき、データコンポーネントは、サービス内に存在するアプリケーションを指す。
【００２７】
また、アプリケーションは、アンバウンドアプリケーションとサービスバウンドアプリケーションとに区別されるが、アンバウンドアプリケーションは、特定のチャンネルと関連しないので、アプリケーションの実行がチャンネル転換に影響を受けない。また、一般的に高い優先順位を有しているので、実行のための資源が円滑に割り当てられる。モニタアプリケーションは、最も高い優先順位を有する特殊なアンバウンドアプリケーションに該当する。
【００２８】
一方、サービスバウンドアプリケーションは、伝送ストリームと関連したものであって、アンバウンドアプリケーションに比べて一般的に低い優先順位が付与される。サービスバウンドアプリケーションは、決定的なシステム機能は行わず、資源に対する競争が発生する場合、アンバウンドアプリケーションより資源の割り当てをあきらめる可能性がさらに高い。サービスバウンドアプリケーションは、現在伝送中のストリームと連動して動作する連動型と、伝送中のストリームに関係なく動作する非連動型とがある。
【００２９】
‘サービスコンテキスト’は、サービスの実行に係る各種のリソース情報、デバイス情報、実行状態情報などを含んでおり、サービスの実行を制御できる客体を表す。
【００３０】
‘ディスプレイ画面’は、サービスの内容が実際に表現される物理的な装置、サービスの内容が出力される外部出力ポートまたはサービスが保存される保存装置を意味する。
【００３１】
‘出力スクリーン’は、ディスプレイ画面に実際に出力されるスクリーンであって、任意のサービスが出力スクリーンに直接設定されてディスプレイ画面を通じて表現されるか、または出力スクリーンの一定な領域にマッピングされた少なくとも一つ以上の論理スクリーンがディスプレイ画面を通じて出力される。
【００３２】
‘論理スクリーン’は、任意のサービスが表現される空間であって、出力スクリーンにマッピングされる前には、メモリ上に仮想的にのみ存在し、実際のディスプレイ画面には表現されない。
【００３３】
また、論理スクリーンと出力スクリーンとは、バックグラウンドスチールイメージ、ビデオラスター及びグラフィックラスターの組み合わせで構成されるが、ここで、グラフィックラスターは、テキスト、線、カラー及びイメージが合成されるか、またはビデオフレームが混合されて提供される。
【００３４】
‘メインサービス’は、ユーザーがディスプレイ画面に表れるメニュまたはリモコンを通じて、またはアプリケーションがＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を通じて主サービスとして選択したサービスを意味し、メインサービスが表現されるスクリーンを‘メインスクリーン’という。
【００３５】
‘ＰｉＰ（Ｐｉｃｔｕｒｅ−ｉｎ−Ｐｉｃｔｕｒｅ）サービス’は、ユーザーがディスプレイ画面に表れるメニュまたはリモコンを通じて、またはアプリケーションがＡＰＩを通じて主サービス内の副サービスとして選択したサービスを意味し、ＰｉＰサービスは、‘ＰｉＰスクリーン’またはメインスクリーン上に表現される。
【００３６】
‘ＰｉＰスクリーン’は、図１Ａないし図１Ｄに示したように他のスクリーン内の一部領域を占めるスクリーンと、図１Ｅ及び図１Ｆに示したように他のスクリーンと重ならない領域に同時に表れるスクリーンと、を備え、また、図１Ｇ及び図１Ｈに示したようにディスプレイ画面内で任意の位置及び領域に表れるか、または他のスクリーンと重なって表現されるスクリーンを含む概念と理解される。
【００３７】
図２は、本発明の一実施形態による論理スクリーンと出力スクリーンとの関係を示す例示図である。図２に示すように、サービスは、論理スクリーン２１０，２１２，２１４を通じて表現され、かかる論理スクリーンは、所定のマッピングブロック２３０により出力スクリーン２２０，２２２，２２４にマッピングされて表現される。
【００３８】
このとき、出力スクリーン２２０は、論理スクリーン２１０，２１２がマッピングされて表現されており、出力スクリーン２２２は、論理スクリーン２１２，２１４がマッピングされて表現されており、出力スクリーン２２４は、論理スクリーン２１０，２１２，２１４がマッピングされて表現されている。
【００３９】
このように、サービスが表現される少なくとも一つ以上の論理スクリーンは、マッピングブロック２３０により出力スクリーンの任意の領域にマッピングされる。
【００４０】
一方、マッピングブロック２３０は、論理スクリーンと出力スクリーンとをマッピングする多様な情報の集合体として理解される。かかる情報の例として、論理スクリーンが出力スクリーンにマッピングされる領域の座標情報、論理スクリーン及び出力スクリーンを区別する識別情報、出力スクリーンに複数の論理スクリーンが表現される順序についての情報などを含む。
【００４１】
マッピングブロック２３０は、論理スクリーンのサイズを変更して出力スクリーンの一定な領域に割り当てる。すなわち、マッピングブロック２３０は、論理スクリーンに対するスケーリング機能及び位置割り当て機能を行え、図３Ａないし図３Ｅでは、かかるマッピングブロック、すなわちマッパを備えるスクリーンの構成を示している。
【００４２】
図３Ａに示すように、バックグラウンドスチールイメージＢ、ビデオラスターＶ及びグラフィックラスターＧの組み合わせからなるメインスクリーンは、マッパによりサイズはそのまま維持しつつ、出力スクリーンの全体にマッピングされる。そして、ビデオ成分のみを有するＰｉＰスクリーンは、マッパによりそのサイズが小さくなりつつ、出力スクリーンの一定な領域にマッピングされる。このとき、マッピングされたＰｉＰスクリーンは、メインスクリーン上に置かれ、これは、Ｚ値により決定される。Ｚは、ｚ−ｏｒｄｅｒ値を表すものであって、ｚ−ｏｒｄｅｒについては後述する。また、オーバーレイスクリーンが前記出力スクリーンと合成されるが、オーバーレイスクリーンは、最外側に置かれる特別なスクリーンであって、例えば字幕を提供する必要がある場合に利用される。ＰｉＰスクリーンは、図３Ａのようにビデオ成分のみを有することもできるが、図３Ｂに示したように、バックグラウンドスチールイメージＢ、ビデオラスターＶ及びグラフィックラスターＧの組み合わせからなることもできる。
【００４３】
図３Ｃに示すように、バックグラウンドスチールイメージＢ、ビデオラスターＶ及びグラフィックラスターＧの組み合わせからなるメインスクリーンは、マッパによりサイズはそのまま維持しつつ、出力スクリーンの全体にマッピングされる。そして、ビデオ成分のみを有する二つのＰｉＰスクリーン＃１，＃２が、それぞれマッパによりそのサイズが小さくなりつつ、出力スクリーンの一定な領域にマッピングされる。このとき、マッピングされたＰｉＰスクリーンは、メインスクリーン上に位置し、このとき、Ｚ値は同一に維持される。また、オーバーレイスクリーンが前記出力スクリーンと合成される。スクリーンの構成は、図３Ｃのようにビデオ成分のみを有する複数のＰｉＰスクリーンを備えることもできるが、図３Ｄに示したように、バックグラウンドスチールイメージＢ、ビデオラスターＶ及びグラフィックラスターＧの組み合わせからなる複数のＰｉＰスクリーンで構成されることもある。
【００４４】
図３Ｅでは、ＰＯＰ（Ｐｉｃｔｕｒｅ−Ｏｎ−Ｐｉｃｔｕｒｅ）スクリーンが示されているが、従来のＰｉＰスクリーンがメインスクリーンの内部で表現されるスクリーンといえば、ＰＯＰスクリーンは、メインスクリーンの外部で表現されるスクリーンと理解される。図３Ｅに示すように、バックグラウンドスチールイメージＢ、ビデオラスターＶ及びグラフィックラスターＧの組み合わせからなる複数のＰＯＰスクリーン＃１，＃２が、それぞれマッパによりそのサイズが小さくなりつつ、出力スクリーンの一定な領域にマッピングされる。このとき、マッピングされたＰＯＰスクリーン＃１，＃２のＺ値は同一に維持される。そして、オーバーレイスクリーンが前記出力スクリーンと合成されて表現される。
【００４５】
また、マッピングブロック２３０は、各種のコンピュータプログラム言語で作成されて実行されるインターフェース、関数などで具現され、前記のような情報をパラメータとして論理スクリーンと出力スクリーンとの関係を生成または変更する。
【００４６】
また、マッピングブロック２３０は、論理スクリーンと出力スクリーンとの間にマッピング機能を行うようにハードウェアで具現されることもある。
【００４７】
出力スクリーンには、多様なソースから提供されるサービスが表現されてディスプレイ画面を通じて出力されるが、図４にそれを示している。
【００４８】
一般的に、サービスを提供するソースとして、地上波放送３２０、ケーブル放送３３０のような放送サービスを提供するソースがあり、ＰＶＲ（パーソナル  ビデオ  レコーダ）３４０のように所定の記録媒体に保存されたサービスを提供するソースもある。また、図４には示されていないが、有線または無線ネットワークを通じてサービスを提供するソースもこれに含まれる。
【００４９】
このとき、放送受信装置３１０は、かかるソースからサービスを受信し、それぞれのサービスを表現する論理スクリーンを生成する。
【００５０】
次いで、既定の方式、ユーザーまたはアプリケーションにより設定された方式によって、任意のサービスが出力スクリーンに直接設定されてディスプレイ画面３５０を通じて表現されるか、または出力スクリーンの一定な領域にマッピングされた少なくとも一つ以上の論理スクリーンがディスプレイ画面３５０を通じて出力される。図４では、地上波放送３２０、ケーブル放送３３０及びＰＶＲ  ３４０により提供されるサービスがディスプレイ画面３５０を通じて表現されることを示している。
【００５１】
図４では、サービスを提供するソースの例として、地上波放送３２０、ケーブル放送３３０、ＰＶＲ  ３４０を示しているが、サービスを提供するソースは、これに限定されず、一つになって表現されるマルチメディアコンテンツを提供すれば、本発明でのソースに含まれる。
【００５２】
一方、本発明でのサービスには、抽象サービス及び非抽象サービスがあるが、それを図５Ａ及び図５Ｂにそれぞれ示している。
【００５３】
抽象サービスは、放送信号からリアルタイムで伝達されるサービスではない放送チャンネルに対して独立したサービスであって、サービスコンポーネントのうちビデオコンポーネント、オーディオコンポーネントなしに、データコンポーネント、すなわちアプリケーションのみからなるサービスが抽象サービスに該当する。例えば、規格でアンバウンドアプリケーションからなるサービスがこれに属する。
【００５４】
非抽象サービスは、抽象サービスを除いた残りのサービスと理解される。
【００５５】
本発明では、抽象サービス及び非抽象サービスそれぞれに対して独立性を付与できる。例えば、抽象サービスは、論理スクリーンを経ずに直接出力スクリーンに設定され、非抽象サービスは、論理スクリーンに表現されて抽象サービスが設定された出力スクリーンにマッピングされる。次いで、前記出力スクリーンがディスプレイ画面を通じて出力されるが、これにより、一つの出力スクリーンで抽象サービスと非抽象サービスとが独立的に表現される。また、抽象サービス及び非抽象サービスがいずれもそれぞれ別途の論理スクリーンにマッピングされた後、それぞれの論理スクリーンが一つの出力スクリーンにマッピングされることもある。すなわち、抽象サービスと非抽象サービスとは、それぞれ独立した形態として出力スクリーンに表現される。
【００５６】
一方、本発明での論理スクリーン及び出力スクリーンは、それぞれ別途の客体として定義されることもあるが、‘スクリーン’という一つの客体が有する属性情報によって、‘スクリーン’が論理スクリーンとして機能するか、または出力スクリーンとして機能することもできる。
【００５７】
すなわち、スクリーン客体に関する属性情報のうちタイプ情報を通じて、スクリーンが論理スクリーンであるか出力スクリーンであるかが分かる。
【００５８】
かかるスクリーン客体の属性情報として、‘Ｔｙｐｅ’、‘ｚ−Ｏｒｄｅｒ’、‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’、‘Ｖｉｓｉｂｉｌｉｔｙ’、‘Ａｓｓｏｃｉａｔｅｄ＿Ｄｉｓｐｌａｙ＿Ｓｃｒｅｅｎ’、‘Ａｓｓｏｃｉａｔｅｄ＿Ｓｅｒｖｉｃｅ＿Ｃｏｎｔｅｘｔｓ’、‘ＯｕｔｐｕｔＰｏｒｔ’のような属性情報がある。
【００５９】
図６は、スクリーン客体の属性情報及びかかる属性情報を処理するインターフェースの種類を示している。
【００６０】
‘Ｔｙｐｅ’属性５１０は、スクリーンが論理スクリーンであるか出力スクリーンであるかを表す属性情報である。
【００６１】
‘ｚ−Ｏｒｄｅｒ’属性５２０は、論理スクリーンが出力スクリーン上で表現されるとき、ｚ軸上での順序を決定するためのものであって、図７では、論理スクリーンが出力スクリーン上でｚ−ｏｒｄｅｒ属性によってどのように表れるかを示している。
【００６２】
図７では、出力スクリーン６１０上には、第１論理スクリーン６２０及び第２論理スクリーン６３０が一定な領域にマッピングされて表現されている。このとき、第１論理スクリーン６２０が出力スクリーン上で表現され、その上に第２論理スクリーン６３０が表現されている。すなわち、ｚ軸方向に出力スクリーン６１０、第１論理スクリーン６２０及び第２論理スクリーン６３０の順序で表現されているが、かかる場合に、第１論理スクリーン６２０のｚ−ｏｒｄｅｒ属性値が１に、第２論理スクリーン６２０のｚ−ｏｒｄｅｒ属性値が２に設定されることである。このとき、ｚ−ｏｒｄｅｒ属性値は、出力スクリーンのｚ軸上で論理スクリーンが表現される順序を指す情報であれば、いかなる数字または文字の形態も可能である。
【００６３】
‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性５３０は、論理スクリーンが出力スクリーンにマッピングされて出力される出力スクリーンの領域についての情報を意味するが、図８Ａ及び図８Ｂにそれを示している。
【００６４】
図８Ａは、論理スクリーン７１０が出力スクリーン７２０の全体領域にマッピングされて出力されることを示しており、図８Ｂは、論理スクリーン７３０が出力スクリーン７４０の一部領域にマッピングされて出力されることを示している。
【００６５】
このとき、‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性５３０を表す情報は、出力スクリーン上の２次元座標情報であるか、または出力スクリーン上での特定の位置及び前記特定の位置からのオフセット値で表現される。
【００６６】
‘Ｖｉｓｉｂｉｌｉｔｙ’属性５４０は、論理スクリーンが出力スクリーン上に表れるか否かを決定する属性であって、この属性値を変更することによって、論理スクリーンを物理的なディスプレイ画面に表すか、または見えなくすることができる。
【００６７】
‘Ａｓｓｏｃｉａｔｅｄ＿Ｄｉｓｐｌａｙ＿Ｓｃｒｅｅｎ’属性５５０は、該論理スクリーンと連結された出力スクリーンの識別情報を表す。出力スクリーンに連結されていない論理スクリーンは、ディスプレイ画面に表れないか、または他の外部出力へ伝送されない。
【００６８】
‘Ａｓｓｏｃｉａｔｅｄ＿Ｓｅｒｖｉｃｅ＿Ｃｏｎｔｅｘｔｓ’属性５６０は、論理スクリーンまたは出力スクリーン自身に連結されたサービスコンテキストについての情報を表すが、サービスコンテキストに設定されたサービスが論理スクリーンまたは出力スクリーンに表現される。
【００６９】
‘ＯｕｔｐｕｔＰｏｒｔ’属性５７０は、出力スクリーンが出力される対象についての情報を表すが、出力スクリーンが出力される対象としてディスプレイ画面、有／無線通信媒体、各種の記録媒体などを含む。
【００７０】
一方、図６に示した属性情報についての値を識別または変更するためのインターフェースが提供されるが、ここには、図６に示したように、属性情報の値を設定するか、または論理スクリーンを出力スクリーンと連結するための‘ｓｅｔ’インターフェース、属性情報の値を追加するか、または論理スクリーンをサービスと連結するための‘ａｄｄ’インターフェース、属性情報の値を得るための‘ｇｅｔ’インターフェース、属性情報の値を削除するための‘ｒｅｍｏｖｅ’インターフェースなどがある。かかるインターフェースは、それぞれの機能を行うプロセス、関数、プロシジャー、メソッドなどと理解される。
【００７１】
例えば、‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ｖｏｉｄ）’メソッドは、現在のスクリーンと関連した出力スクリーンを返還する機能を行う。例えば、現在のスクリーンが論理スクリーンである場合には、関連した出力スクリーンが返還され、現在のスクリーンが出力スクリーンである場合には、現在のスクリーンについての参照情報が返還され、現在のスクリーンが論理スクリーンであるが、関連した出力スクリーンが存在しない場合には、‘ＮＵＬＬ’が返還される。
【００７２】
さらに他の例として、‘ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＤｉｓｐｌａｙＡｒｅａ（ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ  ｒｅｃｔ）ｔｈｒｏｗｓ  ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ，ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’メソッドは、現在の論理スクリーンを関連した出力スクリーンの所定の領域にマッピングさせる機能を提供する。パラメータとして提供されるインスタンスは、‘ｏｒｇ．ｈａｖｉ．ｕｉ’パッケージの‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’クラスタイプであって、２次元位置情報を有する。そして、前記‘ｓｅｔＯｕｔｐｕｔＳｃｒｅｅｎ（ＨＳｃｒｅｅｎ  ｓｃｒｅｅｎ）’メソッドに対する例外処理として、‘ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’例外及び‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外が行われる。‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外は、現在のスクリーンが論理スクリーンでないか、またはハードウェアまたはソフトウェアプラットホームの特性上、現在の論理スクリーンと関連した出力スクリーンの領域が変更されない場合に行われる。
【００７３】
さらに他の例として、‘ｇｅｔＯｕｔｐｕｔＡｒｅａ（ｖｏｉｄ）’メソッドは、現在のスクリーンの領域についての情報を‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’クラスの形態に返還する。現在のスクリーンが出力スクリーンである場合には、‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ（０，０，１，１）’と同じ値を有する‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’情報を返還し、現在のスクリーンが論理スクリーンである場合には、関連した出力スクリーンで前記論理スクリーンが占める領域についての情報が返還される。そして、現在のスクリーンが論理スクリーンであるが、関連した出力スクリーンが存在しない場合には、‘ＮＵＬＬ’値が返還される。
【００７４】
前述したそれぞれのインターフェース名称は、それぞれの機能を表すための名称に過ぎないので、その名称に限定されるものではなく、その機能として理解されねばならない。
【００７５】
図９は、二つのサービスが二つの論理スクリーンにそれぞれ設定され、一つの出力スクリーンにマッピングされて出力される過程を示す例示図である。図９に示すように、第１サービスは、ビデオ／オーディオ／データの三つのサービスコンポーネントがいずれも存在するサービスであり、第２サービスは、ビデオコンポーネント及びオーディオコンポーネントのみが存在するサービスである場合を例として挙げた。もちろん、本発明では、サービスコンポーネントに対する制約事項を置かず、図９の場合は、一つの可能な例を表したものである。
【００７６】
図９に示すように、第１サービスと第２サービスとが従来の方式と類似した形態でディスプレイ画面に表れるが、本発明による場合、マッピングを通じてディスプレイ画面上に個数の制限なしに複数個のサービスを多様な位置に独立的に表現できる。
【００７７】
図１０は、本発明の一実施形態による多重スクリーンを提供する装置の構成を示すブロック図である。図１０に示すように、本発明による多重スクリーン提供装置９００は、デジタル信号処理モジュール９４０、動作モジュール９７０、ユーザー／アプリケーションインターフェースモジュール９５０及び検索モジュール９６０を備える。
【００７８】
このとき、サービスを提供するソースとして、放送信号受信モジュール９１０、記録媒体９２０ａまたは外部入力モジュール９３０を備え、サービスが出力される媒体として、ディスプレイ画面９８０、記録媒体９２０ｂまたは外部出力モジュール９９０を備える。
【００７９】
このとき、本実施形態で使われる‘モジュール’という用語は、ソフトウェアまたはＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）のようなハードウェア構成要素を意味し、モジュールは、所定の役割を行う。しかし、モジュールは、ソフトウェアまたはハードウェアに限定される意味ではない。モジュールは、アドレシングする記録媒体にあるように構成されてもよく、一つまたはそれ以上のプロセッサを再生させるように構成されてもよい。したがって、一例として、モジュールは、ソフトウェア構成要素、客体指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素、プロセス、関数、属性、プロシジャー、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ及び変数を含む。構成要素及びモジュール内で提供される機能は、さらに小さい数の構成要素及びモジュールで結合されるか、または追加的な構成要素及びモジュールにさらに分離される。また、構成要素及びモジュールは、デバイスまたは保安マルチメディアカード内の一つまたはそれ以上のＣＰＵを再生させるように具現されることもある。
【００８０】
デジタル信号処理モジュール９４０は、放送信号受信モジュール９１０、記録媒体９２０ａまたは外部入力モジュール９３０から、マルチメディアコンテンツのようなサービスを構成する多様な構成情報、例えばビデオ情報、オーディオ情報またはデータ情報などを受信する。
【００８１】
このとき、放送信号受信モジュール９１０は、衛星、地上波またはケーブル放送信号を受信して伝達するモジュールであり、記録媒体９２０ａは、サービスを構成するビデオ情報、オーディオ情報またはデータ情報などが保存された機器を表し、外部入力モジュール９３０は、ネットワークインターフェースモジュールのようにネットワークに連結された他の機器から、サービスを構成するビデオ情報、オーディオ情報またはデータ情報などを受信して伝達するモジュールとして理解される。
【００８２】
デジタル信号処理モジュール９４０は、受信されたサービスコンポーネントを利用してサービスを復元するが、このとき、複数のサービスを復元できる。このとき、前記復元されたサービスは、抽象サービスまたは非抽象サービスを含む。
【００８３】
また、ここで、‘複数のサービス’とは、例えば放送信号受信モジュール９１０から伝達される二つ以上のサービスを意味することもあり、放送信号受信モジュール９１０及び記録媒体９２０ａそれぞれから伝達される二つ以上のサービスを意味することもある。
【００８４】
デジタル信号処理モジュール９４０で復元されるサービスは、ユーザー／アプリケーションインターフェースモジュール９６５を通じたユーザーまたはアプリケーションの選択によって復元されることもある。このとき、ユーザーまたはアプリケーションは、どのサービスをいかなるスクリーンに連結するかを選択できる。
【００８５】
動作モジュール９７０は、デジタル信号処理モジュール９４０により復元されたサービスを論理スクリーンで表現した後、論理スクリーンを出力スクリーンにマッピングするか、またはサービスを直接出力スクリーンに表現する役割を行う。このために、動作モジュール９７０は、サービス処理モジュール９７２及び出力モジュール９７４を備えて構成される。
【００８６】
サービス処理モジュール９７２は、デジタル信号処理モジュール９４０により復元されたサービスを表現するための複数の論理スクリーン及び出力スクリーンを生成する。
【００８７】
出力モジュール９７４は、出力スクリーン上の所定の領域に、サービス処理モジュール９７２により生成された論理スクリーンをマッピングして出力する。このとき、出力スクリーン上へのマッピングは、既定されるか、またはユーザー／アプリケーションインターフェースモジュール９５０を通じてユーザーまたはアプリケーションにより設定される。
【００８８】
また、サービス処理モジュール９７２は、複数の出力スクリーンを生成できるが、かかる場合には、ユーザー／アプリケーションインターフェースモジュール９５０を通じて選択された出力スクリーンのみが出力モジュール９７４を通じて提供される。
【００８９】
また、デジタル信号処理モジュール９４０により復元されたサービスは、サービス処理モジュール９７２で論理スクリーンと連結されず、出力スクリーンと直接連結されて出力モジュール９７４により出力される。
【００９０】
出力モジュール９７４により、出力スクリーンは、物理的なディスプレイ画面９８０を通じて出力されるか、または記録媒体９２０ｂに保存される。ここで、記録媒体９２０ｂは、コンピュータにより読み取り可能であり、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＢＤ（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ）及び半導体メモリを含む。
【００９１】
また、外部出力モジュール９９０を通じて、ネットワークに連結された他の機器に伝達されることもある。
【００９２】
このために、出力モジュール９７４は、出力スクリーンが提供される複数の出力ポートを備えるが、かかる場合に、既定の基本の出力ポートまたはユーザー／アプリケーションインターフェースモジュール９５０を通じて指定された出力ポートを通じて出力スクリーンが提供される。
【００９３】
検索モジュール９６０は、システムに存在するスクリーンの形態及び連結関係を検索する役割を行う。かかる検索は、四つに分類されるが、検索モジュール９６０は、少なくとも一つ以上のスクリーンのうち、受信されたサービスに含まれたアプリケーションが実行されるスクリーンを検索でき（以下、第１検索という）、装置に生成されたあらゆる論理スクリーンと出力スクリーンとを検索でき（以下、第２検索という）、受信されたサービスを表現するための論理スクリーンと、その論理スクリーンがマッピングされた出力スクリーンとを検索でき（以下、第３検索という）、受信されたサービスを表現するスクリーンが論理スクリーンであるか出力スクリーンであるかを検索できる（以下、第４検索という）。
【００９４】
ここで、第１検索ないし第４検索過程を通じて検索されるスクリーンは、論理スクリーンまたは出力スクリーンでありうる。
【００９５】
第１検索の実行において、検索モジュール９６０は、アプリケーションが実行されるスクリーンの設定形態を検索できるが、ここで、設定形態としては、単一スクリーン形態、オーバーレイスクリーン形態、ＰｉＰスクリーン形態、ＰｏＰスクリーン形態、オーバーレイされたＰｉＰスクリーン形態、オーバーレイされたＰｏＰスクリーン形態、及び前記形態のうちいずれか一つにも属しない一般形態のうち少なくとも一つを含む。単一スクリーン形態のスクリーンは、アプリケーションが実行されたスクリーンが出力スクリーンに対応する。オーバーレイスクリーン形態のスクリーンは、少なくとも一つ以上のオーバーレイスクリーンと共存する単一スクリーンである。ＰｉＰスクリーン形態のスクリーンは、アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた論理スクリーンに対応し、出力スクリーンにマッピングされた少なくとも一つ以上のオーバーレイされていない論理スクリーンに対応する。オーバーレイされたＰｉＰスクリーン形態のスクリーンは、少なくとも一つ以上のオーバーレイスクリーンと共存するＰｉＰスクリーンである。ＰｏＰスクリーンは、アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた少なくとも二つ以上の非重複論理スクリーンの組み合わせに対応し、オーバーレイスクリーンに対応しないスクリーン形態である。オーバーレイされたＰｏＰスクリーン形態のスクリーンは、ＰｏＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存する形態である。
【００９６】
第２検索の実行において、検索モジュール９６０は、アプリケーションの権限範囲を参照して、権限が付与された場合にのみ論理スクリーン及び出力スクリーンに対して検索することもできる。ここで、アプリケーションの権限範囲は、サービス提供者により付与されるが、検索モジュール９６０は、動作モジュール９７０により生成されたスクリーンのうち、アプリケーションの権限範囲に含まれた一部のスクリーンに対してのみ検索できることである。一方、サービス提供者からいかなる権限範囲も付与されない場合、検索モジュール９６０は、あらゆる論理スクリーン及び出力スクリーンを検索することもできることはいうまでもない。
【００９７】
第４検索の実行において、検索モジュール９６０は、アプリケーションが実行されるスクリーンが論理スクリーン（以下、実行論理スクリーンという）である場合、出力スクリーン上での実行論理スクリーンの位置、サイズ及び出力スクリーン上に存在する他の論理スクリーンと実行論理スクリーンとの重複関係を検索できる。ここで、実行論理スクリーンの位置は、出力スクリーン上での平面座標だけでなく、ｚ軸上の順序であるｚ−ｏｒｄｅｒを含む。
【００９８】
また、第４検索の実行において、検索モジュール９６０は、検索されたスクリーンのサービスコンテキストを検索することもできる。
【００９９】
一方、検索モジュール９６０は、ユーザーから入力された制御命令、またはサービス提供者から提供されたアプリケーションの制御命令により検索を行う。アプリケーションの制御命令による検索は、現在伝送されたアプリケーションまたは既に保存されたアプリケーションの制御命令によって検索モジュール９６０が検索を行うことを意味する。
【０１００】
ユーザーまたはアプリケーションは、ユーザー／アプリケーションインターフェースモジュール９５０を通じて所望のサービスを選択または復元させる。また、ユーザーまたはアプリケーションは、ユーザー／アプリケーションインターフェースモジュール９５０を通じて、複数の出力スクリーンのうち任意の出力スクリーンを選択することもできるが、かかる作業を行うために、ユーザー／アプリケーションインターフェースモジュール９５０は、検索モジュール９６０により検索された結果を利用できる。
【０１０１】
図１０に示した各モジュールは、それぞれの機能によって分離されて示されているので、実際の具現においては、それぞれ他のモジュールとの結合も可能である。
【０１０２】
図１１は、本発明の一実施形態によって多重スクリーンを動的に構成する方法を示すフローチャートである。
【０１０３】
一般的に、マルチメディアコンテンツを構成するビデオ情報、オーディオ情報、データ情報などは、例えばＭＰＥＧストリームのような所定のフォーマットによって伝達される。したがって、マルチメディアコンテンツのようなサービスを実行する装置は、前記のような情報を受信して該当するサービスを復元する（ステップＳ１０１０）。このとき、復元されるサービスは、ユーザーまたはアプリケーションにより選択されるか、または既定される。ユーザーがディスプレイ画面で表れるメニュやリモコンを利用するか、またはアプリケーションがＡＰＩを利用して、どのサービスをいかなるスクリーンに連結するかを選択できる。
【０１０４】
一方、データ情報は、サービス内に存在するアプリケーションに関するアプリケーション情報を含み、かかるアプリケーション情報は、アプリケーションがＰｉＰスクリーンで実行されるか否かを表すシグナル情報を含む。アプリケーション情報の例として、ＭＨＰ規格によるＡＩＴ（アプリケーション  インフォメーション  テーブル）及びＯＣＡＰ規格によるＸＡＩＴ（ｅＸｔｅｎｄｅｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）などがあり、かかるアプリケーション情報に前記シグナル情報を追加できる。
【０１０５】
次いで、前記復元されたサービスを本発明による論理スクリーンで表現されるように設定し（ステップＳ１０２０）、前記論理スクリーンを本発明による出力スクリーンにマッピングした後（ステップＳ１０３０）、ディスプレイ画面９８０、記録媒体９２０ｂまたはネットワークを通じて前記出力スクリーンが提供される（ステップＳ１０４０）。
【０１０６】
このように、論理スクリーン及び出力スクリーンが生成された後、検索モジュール９６０は、生成されたスクリーンに対する検索を行う（Ｓ１０５０）。検索モジュール９６０により行われる検索は、前述した第１検索ないし第４検索を含み、これは、ユーザー／アプリケーションインターフェースモジュール９５０を通じて入力されたユーザーまたはアプリケーションの制御命令によって行われる。検索についての詳細な説明は、図１０を通じて前述したので省略する。
【０１０７】
一方、図１１では、復元されたサービスが論理スクリーンを経て出力スクリーンを通じて提供されると表現されているが、論理スクリーンを経ずに直接出力スクリーンを通じて提供されることもある。
【０１０８】
また、ユーザーがＰｉＰサービスを選択する場合には、二つのモードとしてＰｉＰサービスが表現されるが、第１モードでは、ＰｉＰサービスのための別途の論理スクリーン、例えばＰｉＰスクリーンが生成されず、メインスクリーンで選択されたＰｉＰサービスのビデオコンポーネントのみが表現され、第２モードでは、ＰｉＰサービスのための別途の論理スクリーンが生成されて、生成されたＰｉＰスクリーン内で選択されたＰｉＰサービスが表現される。
【０１０９】
一方、図１１では、説明の便宜上、一つのサービスが出力スクリーンにマッピングされる過程を説明しているが、スクリーン属性情報を利用して複数のサービスが複数の論理スクリーンを通じて、または直接的に一つの出力スクリーン内の任意の領域にマッピングされる。
【０１１０】
したがって、出力スクリーンがディスプレイ画面を通じて提供される場合には、ユーザーまたはアプリケーションは、複数のサービスを実行できる。
【０１１１】
図１２は、本発明の一実施形態によって多重スクリーンを提供するためのソフトウェアアーキテクチャーを示す例示図である。図１２に示すように、本発明によるソフトウェアアーキテクチャー１１００は、デバイスドライバレイヤー１１１０、ＡＰＩレイヤー１１２０及びアプリケーションレイヤー１１３０を備える。
【０１１２】
デバイスドライバレイヤー１１１０は、マルチメディアコンテンツを提供する多様なソースから、サービスを構成するサービスコンポーネントを受信してデコーディングする。このとき、サービスコンポーネントの例として、ビデオ情報、オーディオ情報またはデータ情報などを含む。
【０１１３】
ＡＰＩレイヤー１１２０は、論理スクリーン及び出力スクリーンを生成し、サービス、論理スクリーン、出力スクリーン間のマッピングを行う。
【０１１４】
アプリケーションレイヤー１１３０は、サービスが表現される論理スクリーンをユーザーが動的に構成可能にするユーザーインターフェースを提供するか、またはユーザーの命令をＡＰＩレイヤー１１２０に伝達して該命令による動作を行わせる。
【０１１５】
かかる作業を行うために、アプリケーションレイヤー１１３０は、現在伝送されたアプリケーションまたは既に保存されたアプリケーションを通じて作業を行え、スクリーン検索などの作業もアプリケーションレイヤー１１３０を通じて行われる。
【０１１６】
一方、ユーザーは、アプリケーションレイヤー１１３０を通じてデバイスドライバレイヤー１１１０により出力スクリーンを、物理的なディスプレイ画面を通じて出力するか、または記録媒体に保存する。また、デバイスドライバーレイヤー１１１０により出力スクリーンを、ネットワークを通じて他の機器へ伝送することもできる。
【０１１７】
このために、デバイスドライバレイヤー１１１０は、前記出力スクリーンを提供する複数の出力ポートを備えるが、複数の出力ポートは、ＡＰＩレイヤー１１２０に存在することもできる。
【０１１８】
一方、複数の論理スクリーンを出力スクリーン上に動的に構成するために、ＡＰＩレイヤー１１２０は、複数のソフトウェアモジュールを備えるが、ここでは、‘ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒ’モジュール、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール及び‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュールを例として説明し、かかるモジュールの関係を図１３に示している。
【０１１９】
‘ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒ’モジュール１２１０は、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュールを管理しつつ、所望のスクリーンを探すか、またはスクリーン間のデバイス共有情報を知らせるか、または‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール１２５０の登録または解除を担当する役割を行う。
【０１２０】
‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０は、スクリーン客体１２２０と関連したインターフェース客体であって、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０のインターフェース動作によって、スクリーン客体の類型が論理スクリーンと出力スクリーンとに決定され、図６に示されている多様な属性情報が設定される。前述した‘ｓｅｔ’、‘ａｄｄ’、‘ｇｅｔ’、‘ｒｅｍｏｖｅ’インターフェースは、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０により提供される。
【０１２１】
‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュール１２４０は、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’インターフェース客体１２３０によりスクリーン客体１２２０の属性情報が変わった場合、それを知らせるためのイベントクラスであり、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール１２５０は、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュール１２４０によるイベントを受信しようとする所定のアプリケーションクラスに具現されるリスナーインターフェース客体である。
【０１２２】
一方、アプリケーション１２６０は、アプリケーションレイヤー１１３０で動作するモジュールであって、ユーザーが所望のサービスを選択し、出力スクリーンに複数の論理スクリーンを所望の形態によって自由に配置する。
【０１２３】
したがって、アプリケーション１２６０は、ユーザーが論理スクリーンを動的に配置し、それを管理することに関する命令をＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０に伝達すれば、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０を通じて前記命令に対応する動作を行わせる。
【０１２４】
一方、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０は、スクリーン客体１２２０と関連して、図６に示したスクリーン客体１２２０の属性情報を管理でき、かかる管理のために多様な関数またはメソッドを含む。
【０１２５】
一方、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、デバイスドライバレイヤー１１１０から、多様なソースから提供されたサービスコンポーネントを受信して、論理スクリーンまたは出力スクリーンで表現されるように動作することもできる。もちろん、かかる機能は、別途のモジュール（図示せず）を通じて行われることもある。
【０１２６】
また、アプリケーションは、検索モジュール９６０を利用してスクリーン検索作業を行えるが、これについての詳細な説明は、図１５を通じて後述する。
【０１２７】
図１４は、図１３に示した各モジュールにより複数個のサービスを、論理スクリーンを通じて出力スクリーンに表す過程を示すフローチャートである。
【０１２８】
まず、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、一つの出力スクリーンと、実行されるサービスの個数ほどの論理スクリーンとを生成する（ステップＳ１３１０）。
【０１２９】
次いで、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、それぞれの論理スクリーンをデバイスドライバレイヤー１１１０から受信したサービスと連結させる（ステップＳ１３２０）。このとき、それぞれの論理スクリーンに対して、連結するサービスに対するサービスコンテキスト客体をパラメータとして、論理スクリーン客体の‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドを呼び出す。ここで、‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドは、論理スクリーンとサービスとを連結する機能を行うメソッドと理解され、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０により提供される。
【０１３０】
論理スクリーンとサービスとが連結されれば、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、それぞれの論理スクリーンを出力スクリーンと連結する（ステップＳ１３３０）。このとき、それぞれの論理スクリーンに対して、連結する出力スクリーン客体をパラメータとして、論理スクリーン客体の‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドを呼び出す。ここで、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、論理スクリーンと出力スクリーンとを連結する機能を行うメソッドと理解され、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０により提供される。
【０１３１】
例えば、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、‘ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎ  ｓｃｒｅｅｎ）  ｔｈｒｏｗｓ  ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ，ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’の形態で表現され、このメソッドは、パラメータとして提供される‘ＨＳｃｒｅｅｎ’インスタンスを現在の論理スクリーンとマッピングさせる機能を提供する。このとき、前記‘ＨＳｃｒｅｅｎ’インスタンスは、出力スクリーンであることが望ましい。
【０１３２】
そして、前記‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎ  ｓｃｒｅｅｎ）’メソッドのパラメータは、‘ＮＵＬＬ’を含むが、この場合、例外処理なしに‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎ  ｓｃｒｅｅｎ）’メソッドが実行されれば、現在の論理スクリーンは、それ以上出力スクリーンと関連しない。
【０１３３】
そして、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎ  ｓｃｒｅｅｎ）’メソッドに対する例外処理として、‘ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’例外及び‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外が行われる。
【０１３４】
‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外は、現在のスクリーンが論理スクリーンでないか、またはハードウェアまたはソフトウェアプラットホームの特性上、パラメータとして提供される出力スクリーンが特定の論理スクリーンと関連して、現在の論理スクリーンを前記パラメータに該当する出力スクリーンと関連させない場合に行われる。
【０１３５】
サービスと論理スクリーン、複数の論理スクリーンと一つの出力スクリーンとが連結されれば、それぞれの論理スクリーンが表現される出力スクリーンの領域が設定される（ステップＳ１３４０）。このとき、それぞれの論理スクリーンに対して、出力スクリーンに表れる領域を設定するために、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０により提供されるメソッドを呼び出す。
【０１３６】
図１５は、本発明の実施形態による検索モジュール９６０の動作を示す例示図であって、検索モジュール９６０は、前述した第１検索ないし第４検索１５１０，１５２０，１５３０，１５４０を行える。
【０１３７】
第１検索１５１０を行うために、検索モジュール９６０は、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ’メソッドを呼び出す。‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ’メソッドは、現在活性化されたスクリーンの設定形態に対するインスタンスを返還するメソッドであって、これは、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎクラスにより提供される。
【０１３８】
例えば、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ’メソッドは、‘ｐｕｂｌｉｃ  ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ  ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ（）  ｔｈｒｏｗｓ  ｊａｖａ．ｌａｎｇ．ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’の形態で表現され、このメソッドは、現在活性化されたスクリーンの設定形態に対するインスタンスであるＭｕｌｔｉＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎを返還する。
【０１３９】
そして、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎ’メソッドの呼び出しが許容されない場合、‘ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’例外が行われる。
【０１４０】
また、該スクリーンの具体的な設定形態を確認するために、検索モジュール９６０は、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎＴｙｐｅ’メソッドを呼び出す。ここで、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎＴｙｐｅ’メソッドは、現在活性化されたスクリーンの設定形態を返還するメソッドであって、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎインターフェースにより提供される。
【０１４１】
例えば、‘ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎＴｙｐｅ’メソッドは、
‘ｉｎｔ  ｇｅｔＳｃｒｅｅｎＣｏｎｆｉｇｕｒａｔｉｏｎＴｙｐｅ（）
｛ｒｅｔｕｒｎ  ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＮＯＮ＿ＰＩＰ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＮＯＮ＿ＰＩＰ＿ＷＩＴＨ＿ＯＶＥＲＬＡＹ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＩＰ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＩＰ＿ＷＩＴＨ＿ＯＶＥＲＬＡＹ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＯＰ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＯＰ＿ＷＩＴＨ＿ＯＶＥＲＬＡＹ，
ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＧＥＮＥＲＡＬ｝’の形態で表現され、このメソッドは、現在活性化されたスクリーンの設定形態を自身のデータ型である整数型に返還する。ここで、前記に羅列した設定形態は、それぞれ前述した単一スクリーン形態、オーバーレイスクリーン形態、ＰｉＰスクリーン形態、オーバーレイされたＰｉＰスクリーン形態、ＰｏＰスクリーン形態、オーバーレイされたＰｏＰスクリーン形態及び一般形態に該当する。
【０１４２】
図１６Ａは、スクリーンの設定形態を検索するためのコードの例示図であって、現在活性化されたスクリーンの設定形態がＰｉＰであるかＰｏＰであるかを検索するコードである。すなわち、検索モジュール９６０は、設定形態がＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＩＰであり、ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＩＰ＿ＷＩＴＨ＿ＯＶＥＲＬＡＹである場合をＰｉＰと見なし、設定形態がＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＯＰであり、ＳＣＲＥＥＮ＿ＣＯＮＦＩＧＵＲＡＴＩＯＮ＿ＰＯＰ＿ＷＩＴＨ＿ＯＶＥＲＬＡＹである場合をＰｏＰと見なし、その他のあらゆる場合をＰｉＰまたはＰｏＰではないと見なす。
【０１４３】
第２検索１５２０を行うために、検索モジュール９６０は、‘ｇｅｔＳｃｒｅｅｎｓ’メソッドを呼び出す。ここで、‘ｇｅｔＳｃｒｅｅｎｓ’メソッドは、装置に生成されたあらゆるスクリーンの集合を返還するメソッドであって、そのデータ型は、‘ｏｒｇ．ｈａｖｉ．ｕｉ’パッケージの‘ＨＳｃｒｅｅｎ’クラスタイプである。すなわち、‘ｇｅｔＳｃｒｅｅｎｓ’メソッドは、装置に生成されたあらゆる‘ＨＳｃｒｅｅｎ’インスタンスの集合を返還することである。
【０１４４】
図１６Ｂは、装置に生成されたあらゆるスクリーンのインスタンスを検索するためのコードの例示図であって、検索されたインスタンスを利用してスクリーンの設定形態を検索するコードである。すなわち、‘ｇｅｔＳｃｒｅｅｎｓ’メソッドを通じて返還された接近可能なスクリーンのインスタンスである‘ｓｃｒｅｅｎｓ’が抽出され、それを通じて各スクリーンの設定形態が順次に検索されることである。
【０１４５】
第３検索１５３０を行うために、検索モジュール９６０は、‘ｏｒｇ．ｈａｖｉ．ｕｉ．ＨＳｃｒｅｅｎ．ｇｅｔＤｅｆａｕｌｔＨＳｃｒｅｅｎ’メソッドを呼び出す。ここで、‘ｇｅｔＤｅｆａｕｌｔＨＳｃｒｅｅｎ’メソッドは、単一スクリーンを検索するためのものである。アプリケーションのデフォルトスクリーンは、そのアプリケーションが属しているスクリーンと定義すれば、アプリケーションは、‘ｇｅｔＤｅｆａｕｌｔＨＳｃｒｅｅｎ’ＡＰＩを利用して自身が属したスクリーンを確認できる。
【０１４６】
一方、論理スクリーンとマッピングされた出力スクリーンを検索するために、検索モジュール９６０は、‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドを呼び出す。ここで、‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、論理スクリーンと連結された出力スクリーンを返還するメソッドであって、そのデータ型は、‘ＨＳｃｒｅｅｎ’クラスタイプであり、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’インターフェースにより提供される。
【０１４７】
‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、呼び出された‘ＨＳｃｒｅｅｎ’の形態が出力スクリーンである場合、これについての参照アドレスを返還し、呼び出された‘ＨＳｃｒｅｅｎ’の形態が論理スクリーンであり、この論理スクリーンが出力スクリーンと連結された場合、出力スクリーンの参照アドレスを返還する。一方、‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、呼び出された‘ＨＳｃｒｅｅｎ’の形態が論理スクリーンであり、この論理スクリーンが出力スクリーンと連結されていない場合、ＮＵＬＬを返還する。
【０１４８】
図１６Ｃは、アプリケーションが属したスクリーンを検索するためのコードの例示図であって、アプリケーションが属したスクリーンが論理スクリーンであるか出力スクリーンであるかを判断した後、出力スクリーンを検索するコードである。
【０１４９】
すなわち、‘ｇｅｔＤｅｆａｕｌｔＨＳｃｒｅｅｎ’メソッドが利用されてデフォルトスクリーンである‘ｓｃｒｅｅｎ’が抽出され、これが‘ｇｅｔＳｃｒｅｅｎＴｙｐｅ’メソッドに適用されて、該スクリーンが論理スクリーンであるか出力スクリーンであるかが確認され、その結果によって‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドが出力スクリーンを返還することである。
【０１５０】
第４検索１５４０を行うために、検索モジュール９６０は、‘ｇｅｔＳｃｒｅｅｎＴｙｐｅ’メソッド、‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッド、‘ｇｅｔＺＯｒｄｅｒ’メソッド、‘ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔｓ’メソッドを呼び出す。ここで、‘ｇｅｔＳｃｒｅｅｎＴｙｐｅ’メソッドは、該スクリーンが論理スクリーンであるか出力スクリーンであるかを検索するためのものであって、そのデータ型は、整数型であり、‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＤＩＳＰＬＡＹ’または‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＬＯＧＩＣＡＬ’を返還する。
【０１５１】
‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＤＩＳＰＬＡＹ’は、出力スクリーンを表す値であって、‘ＨＳｃｒｅｅｎ’が‘ＶｉｄｅｏＯｕｔｐｕｔＰｏｒｔ’に連結されており、‘ＶｉｄｅｏＯｕｔｐｕｔＰｏｒｔ’から生成されたビデオラスターにマッピングされた場合、‘ＨＳｃｒｅｅｎ’の形態は、‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＤＩＳＰＬＡＹ’となるが、このときの‘ＨＳｃｒｅｅｎ’を出力‘ＨＳｃｒｅｅｎ’という。
【０１５２】
一方、‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＬＯＧＩＣＡＬ’は、論理スクリーンを表す値であって、‘ＨＳｃｒｅｅｎ’が‘ＶｉｄｅｏＯｕｔｐｕｔＰｏｒｔ’に連結されず、‘ＶｉｄｅｏＯｕｔｐｕｔＰｏｒｔ’から生成されたビデオラスターのサブ領域にマッピングされた場合、‘ＨＳｃｒｅｅｎ’の形態は、‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＬＯＧＩＣＡＬ’となるが、このときの‘ＨＳｃｒｅｅｎ’を論理‘ＨＳｃｒｅｅｎ’という。
【０１５３】
論理‘ＨＳｃｒｅｅｎ’は、出力‘ＨＳｃｒｅｅｎ’に連結されることもあるが、論理‘ＨＳｃｒｅｅｎ’が出力‘ＨＳｃｒｅｅｎ’に連結されていない場合、視覚的かつ聴覚的なサービスは、論理‘ＨＳｃｒｅｅｎ’に連結された‘ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’により生成されない。
【０１５４】
図１６Ｄは、アプリケーションが属したスクリーンの形態を検索するためのコードの例示図であって、‘ｇｅｔＳｃｒｅｅｎＴｙｐｅ’メソッドを利用して、該スクリーンが論理スクリーンであるか出力スクリーンであるかを検索するコードである。
【０１５５】
出力スクリーン上に位置したアプリケーションの座標及びｚ−ｏｒｄｅｒを検索するために、‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッド及び‘ｇｅｔＺＯｒｄｅｒ’メソッドが呼び出される。
【０１５６】
‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッドは、出力スクリーンにマッピングされた論理スクリーンの座標を返還するが、そのデータ型は、‘ｏｒｇ．ｈａｖｉ．ｕｉ．ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’クラスタイプである。‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッドは、‘ＨＳｃｒｅｅｎ’の範囲を返還するが、‘ＨＳｃｒｅｅｎ’の形態が‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＤＩＳＰＬＡＹ’である場合、‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ（０，０，１，１）’を返還し、‘ＨＳｃｒｅｅｎ’の形態が‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＬＯＧＩＣＡＬ’であり、‘ＨＳｃｒｅｅｎ’が出力‘ＨＳｃｒｅｅｎ’に連結された場合、該論理‘ＨＳｃｒｅｅｎ’に割り当てられた領域を返還する。また、‘ＨＳｃｒｅｅｎ’の形態が‘ＳＣＲＥＥＮ＿ＴＹＰＥ＿ＬＯＧＩＣＡＬ’であり、‘ＨＳｃｒｅｅｎ’が出力‘ＨＳｃｒｅｅｎ’に連結されていない場合、‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッドは、ＮＵＬＬを返還する。
【０１５７】
図１６Ｅは、アプリケーションが属した論理スクリーンの出力スクリーン上での位置及びサイズを検索するためのコードの例示図であって、‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ’メソッドを利用して該スクリーンの位置及びサイズを検索するコードである。
【０１５８】
‘ｇｅｔＺＯｒｄｅｒ’メソッドは、出力スクリーンにマッピングされた論理スクリーンのｚ−ｏｒｄｅｒを返還するが、そのデータ型は、整数型である。‘ｇｅｔＺＯｒｄｅｒ’メソッドは、該‘ＨＳｃｒｅｅｎ’が出力‘ＨＳｃｒｅｅｎ’である場合、０であるｚ−ｏｒｄｅｒを返還し、該‘ＨＳｃｒｅｅｎ’が論理‘ＨＳｃｒｅｅｎ’である場合、１またはそれ以上の値を有するｚ−ｏｒｄｅｒを返還する。
該スクリーンと関連したサービスコンテキストを検索するために、‘ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔｓ’メソッドが呼び出される。
【０１５９】
‘ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔｓ’メソッドは、‘ＨＳｃｒｅｅｎ’に連結されたサービスコンテキストの集合を返還するが、そのデータ型は、‘ｊａｖａｘ．ｔｖ．ｓｅｒｖｉｃｅ．ｓｅｌｅｃｔｉｏｎ．ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’クラスタイプである。
【０１６０】
図１６Ｆは、アプリケーションが属したスクリーンのサービスコンテキストを検索するためのコードの例示図であって、‘ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔｓ’メソッドを利用して該スクリーンのサービスコンテキストを検索するコードである。
【０１６１】
図１７は、図１３に示した各モジュールにより論理スクリーンに表現されるサービスが交換される過程を示すフローチャートである。
【０１６２】
まず、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、サービスが互いに交換される二つの論理スクリーンに存在するサービスを一時中止させる（ステップＳ１４１０）。
【０１６３】
次いで、二つの論理スクリーンに連結されたサービスの情報を交換する（ステップＳ１４２０）。このとき、二つの論理スクリーン客体それぞれに対して‘ｒｅｍｏｖｅＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッド及び‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドを呼び出すことによって、論理スクリーンに設定されたサービスコンテキストを交換できる。ここで、‘ｒｅｍｏｖｅＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドは、論理スクリーンに連結されていたサービスコンテキストを除去する機能を行うメソッドと理解され、‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドは、論理スクリーンに新たなサービスコンテキストを追加する機能を行うメソッドと理解され、‘ｒｅｍｏｖｅＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッド及び‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’メソッドは、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０により提供される。すなわち、本発明では、論理スクリーンに連結されたサービスについての情報を交換することによって、従来の主画面と副画面とを互いに交換する効果だけでなく、例えばディスプレイ画面９８０に三つ以上のサービスが実演される途中でも、任意の個数の論理スクリーン間にサービスの交換が可能になる。
【０１６４】
二つの論理スクリーンに連結されたサービスの情報が交換されれば、サービスと論理スクリーンとの連結が変わったというイベントが発生し（ステップＳ１４３０）、次いで、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュール１２４０は、発生したイベントを‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール１２５０に伝達し、二つの論理スクリーンに新たに連結されたサービスに対する実行が再開される（ステップＳ１４４０）。
【０１６５】
以上、添付された図面を参照して本発明の実施形態を説明したが、当業者ならば、本発明がその技術的思想や必須的な特徴を変更せずに他の具体的な形態で実施されるということが分かるであろう。したがって、前述した実施形態は、あらゆる面で例示的なものであり、限定的でないと理解せねばならない。
【産業上の利用可能性】
【０１６６】
本発明の多重スクリーンを提供する装置及び前記多重スクリーンの動的構成方法によれば、システムに存在するスクリーンの形態及び連結関係を検索することによって、物理的なディスプレイ画面に複数個のコンテンツを提供する複数のスクリーンをユーザーまたはアプリケーションにより容易に動的に構成可能にする。
【図面の簡単な説明】
【０１６７】
【図１Ａ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｂ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｃ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｄ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｅ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｆ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｇ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図１Ｈ】本発明の一実施形態によってＰｉＰスクリーンが配置される形態を示す例示図である。
【図２】本発明の一実施形態による論理スクリーンと出力スクリーンとの関係を示す例示図である。
【図３Ａ】本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。
【図３Ｂ】本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。
【図３Ｃ】本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。
【図３Ｄ】本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。
【図３Ｅ】本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。
【図４】本発明の一実施形態によってサービスを提供するソースの例を示す例示図である。
【図５Ａ】本発明の一実施形態によって抽象サービスと非抽象サービスとの例を示す例示図である。
【図５Ｂ】本発明の一実施形態によって抽象サービスと非抽象サービスとの例を示す例示図である。
【図６】論理スクリーン及び出力スクリーンでの属性情報及びインターフェース種類を示す例示図である。
【図７】論理スクリーンの‘ｚ−ｏｒｄｅｒ’属性を示す例示図である。
【図８Ａ】論理スクリーンの‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性を示す例示図である。
【図８Ｂ】論理スクリーンの‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性を示す例示図である。
【図９】二つのサービスが一つの出力スクリーンにマッピングされて出力される過程を示す例示図である。
【図１０】本発明の一実施形態による多重スクリーンを提供する装置の構成を示すブロック図である。
【図１１】本発明の一実施形態によって多重スクリーンを動的に構成する方法を示すフローチャートである。
【図１２】本発明の一実施形態によって多重スクリーンを提供するためのソフトウェアアーキテクチャーを示す例示図である。
【図１３】本発明の一実施形態によってＡＰＩレイヤーを構成するモジュールの関係を示す例示図である。
【図１４】本発明の一実施形態によって、図１３に示した各モジュールにより複数個のサービスを論理スクリーンを通じて出力スクリーンに表す過程を示すフローチャートである。
【図１５】本発明の実施形態による検索モジュールの動作を示す例示図である。
【図１６Ａ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１６Ｂ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１６Ｃ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１６Ｄ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１６Ｅ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１６Ｆ】本発明の実施形態によるスクリーン検索のためのコードの例示図である。
【図１７】本発明の実施形態によって、図１３に示した各モジュールにより論理スクリーンに表現されるサービスが交換される過程を示すフローチャートである。
【図１Ａ】
2009503605.tif 000003
【図１Ｂ】
2009503605.tif 000004
【図１Ｃ】
2009503605.tif 000005
【図１Ｄ】
2009503605.tif 000006
【図１Ｅ】
2009503605.tif 000007
【図１Ｆ】
2009503605.tif 000008
【図１Ｇ】
2009503605.tif 000009
【図１Ｈ】
2009503605.tif 000010
【図３Ａ】
2009503605.tif 000011
【図３Ｂ】
2009503605.tif 000012
【図３Ｃ】
2009503605.tif 000013
【図３Ｄ】
2009503605.tif 000014
【図３Ｅ】
2009503605.tif 000015
【図４】
2009503605.tif 000016
【図５Ａ】
2009503605.tif 000017
【図５Ｂ】
2009503605.tif 000018
【図６】
2009503605.tif 000019
【図７】
2009503605.tif 000020
【図８Ａ】
2009503605.tif 000021
【図８Ｂ】
2009503605.tif 000022
【図９】
2009503605.tif 000023
【図１０】
2009503605.tif 000024
【図１１】
2009503605.tif 000025
【図１２】
2009503605.tif 000026
【図１３】
2009503605.tif 000027
【図１４】
2009503605.tif 000028
【図１５】
2009503605.tif 000029
【図１６Ａ】
2009503605.tif 000030
【図１６Ｂ】
2009503605.tif 000031
【図１６Ｃ】
2009503605.tif 000032
【図１６Ｄ】
2009503605.tif 000033
【図１６Ｅ】
2009503605.tif 000034
【図１６Ｆ】
2009503605.tif 000035
【図１７】
2009503605.tif 000036
【図２】
2009503605.tif 000037
【手続補正書】
【提出日】平成19年7月31日(2007.7.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成する動作モジュールと、
前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項２】
前記スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項３】
前記スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項４】
前記検索モジュールは、前記実行されたスクリーンの設定形態を検索することを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項５】
前記設定形態は、前記アプリケーションが実行されたスクリーンが出力スクリーンに対応する単一スクリーン形態と、
前記単一スクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた論理スクリーンに対応し、出力スクリーンにマッピングされた少なくとも一つ以上のオーバーレイされていない論理スクリーンに対応し、オーバーレイスクリーンに対応しないＰｉＰスクリーン形態と、
前記ＰｉＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｉＰスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた少なくとも二つ以上の非重複論理スクリーンの組み合わせに対応し、オーバーレイスクリーンに対応しないＰｏＰスクリーン形態と、
前記ＰｏＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｏＰスクリーン形態と、
一般形態のうち少なくとも一つを含むことを特徴とする請求項４に記載の多重スクリーンを提供する装置。
【請求項６】
前記動作モジュールは、前記アプリケーションが実行される論理スクリーンを出力スクリーンに配置することを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項７】
前記動作モジュールは、前記アプリケーションを出力スクリーン上で動作させることを特徴とする請求項１に記載の多重スクリーンを提供する装置。
【請求項８】
受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記生成されたあらゆる論理スクリーン及び出力スクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項９】
前記検索モジュールは、前記サービスに含まれた所定のアプリケーションの権限範囲に含まれた論理スクリーン及び出力スクリーンに対してのみ検索することを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１０】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１１】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項８に記載の多重スクリーンを提供する装置。
【請求項１２】
受信されたサービスを表現するための論理スクリーン、及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記論理スクリーン及び前記出力スクリーンを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項１３】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１２に記載の多重スクリーンを提供する装置。
【請求項１４】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１２に記載の多重スクリーンを提供する装置。
【請求項１５】
サービスを受信する放送信号受信モジュールと、
論理スクリーン及び前記論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索する検索モジュールと、を備えることを特徴とする多重スクリーンを提供する装置。
【請求項１６】
前記検索モジュールは、前記サービスを表現するスクリーンが前記論理スクリーンである場合、前記出力スクリーン上での前記論理スクリーンの位置、サイズ及び前記出力スクリーン上に存在する他の論理スクリーンと前記論理スクリーンとの重複関係を検索することを特徴とする請求項１５に記載の多重スクリーンを提供する装置。
【請求項１７】
前記検索モジュールは、前記サービスを表現するスクリーンのサービスコンテキストを検索することを特徴とする請求項１５に記載の多重スクリーンを提供する装置。
【請求項１８】
受信されたサービスを表現するための少なくとも一つ以上のスクリーンを生成するステップと、
前記スクリーンのうち、前記サービスに含まれた所定のアプリケーションが実行されるスクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項１９】
前記スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２０】
前記スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２１】
前記検索するステップは、前記実行されたスクリーンの設定形態を検索するステップを含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２２】
前記設定形態は、前記アプリケーションが実行されたスクリーンが出力スクリーンに対応する単一スクリーン形態と、
前記単一スクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた論理スクリーンに対応し、出力スクリーンにマッピングされた少なくとも一つ以上のオーバーレイされていない論理スクリーンに対応し、オーバーレイスクリーンに対応しないＰｉＰスクリーン形態と、
前記ＰｉＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｉＰスクリーン形態と、
前記アプリケーションが実行されたスクリーンが出力スクリーンの全体領域にマッピングされた少なくとも二つ以上の非重複論理スクリーンの組み合わせに対応し、オーバーレイスクリーンに対応しないＰｏＰスクリーン形態と、
前記ＰｏＰスクリーンが少なくとも一つ以上のオーバーレイスクリーンと共存するオーバーレイされたＰｏＰスクリーン形態と、
一般形態のうち少なくとも一つを含むことを特徴とする請求項２１に記載の多重スクリーンの動的構成方法。
【請求項２３】
前記アプリケーションが実行される論理スクリーンを出力スクリーンに配置するステップをさらに含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２４】
前記アプリケーションを出力スクリーン上で動作させるステップをさらに含むことを特徴とする請求項１８に記載の多重スクリーンの動的構成方法。
【請求項２５】
受信されたサービスを表現するための論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記あらゆる論理スクリーン及び出力スクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項２６】
前記検索するステップは、前記サービスに含まれたアプリケーションの権限範囲に含まれた論理スクリーン及び出力スクリーンに対してのみ検索するステップを含むことを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２７】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２８】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項２５に記載の多重スクリーンの動的構成方法。
【請求項２９】
受信されたサービスを表現するための論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記論理スクリーン及び前記出力スクリーンを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項３０】
前記論理スクリーンは、ＰｉＰスクリーンを備えることを特徴とする請求項２９に記載の多重スクリーンの動的構成方法。
【請求項３１】
前記論理スクリーンは、ＰｏＰスクリーンを備えることを特徴とする請求項２９に記載の多重スクリーンの動的構成方法。
【請求項３２】
サービスを受信するステップと、
論理スクリーンを生成するステップと、
前記論理スクリーンがマッピングされる出力スクリーンを生成するステップと、
前記サービスを表現するスクリーンが前記論理スクリーンであるか、前記出力スクリーンであるかを検索するステップと、を含むことを特徴とする多重スクリーンの動的構成方法。
【請求項３３】
前記検索するステップは、前記サービスを表現するスクリーンが前記論理スクリーンである場合、前記出力スクリーン上での前記論理スクリーンの位置、サイズ及び前記出力スクリーン上に存在する他の論理スクリーンと前記論理スクリーンとの重複関係を検索するステップを含むことを特徴とする請求項３２に記載の多重スクリーンの動的構成方法。
【請求項３４】
前記検索するステップは、前記サービスを表現するスクリーンのサービスコンテキストを検索するステップを含むことを特徴とする請求項３２に記載の多重スクリーンの動的構成方法。
【請求項３５】
要請された複数個のサービスを表現するための複数個の論理スクリーン、及び前記複数個の論理スクリーンがマッピングされる出力スクリーンを生成する動作モジュールと、
前記動作モジュールにより生成されたスクリーンを検索するためのスクリーン検索ステップを行う検索モジュールと、を備えるが、
前記スクリーン検索ステップは、
（ａ）単一スクリーン形態、オーバーレイスクリーン形態、ＰｉＰスクリーン形態、オーバーレイされたＰｉＰスクリーン形態、ＰｏＰスクリーン形態、オーバーレイされたＰｏＰスクリーン形態及び一般スクリーン形態のうち少なくとも一つを含むスクリーンの設定形態のうち、前記要請されたサービスに含まれたアプリケーションが実行中のスクリーンの設定形態を検索するステップと、
（ｂ）受信されたアプリケーションの権限範囲に含まれた論理スクリーン及び出力スクリーンを検索するステップと、
（ｃ）あらゆる論理スクリーン及びマッピングされた出力スクリーンを検索するステップと、
（ｄ）アプリケーションが実行中のスクリーンが論理スクリーンである場合、前記出力スクリーン上で実行中の論理スクリーンの位置及びサイズ、他の論理スクリーンに対する前記実行中の論理スクリーンの前記出力スクリーン上でのｚ−ｏｒｄｅｒ、及び検索されたスクリーンのサービスコンテキストを検索するステップのうち少なくとも一つのステップと、を含む物理的なディスプレイ装置上に複数個のスクリーンを構成できるシステム。
【国際調査報告】
2009503605.tif 000038
2009503605.tif 000039
2009503605.tif 000040