JP2009504067A - 多重スクリーンの提供装置及び該多重スクリーンの動的構成方法 - Google Patents

Abstract

多重スクリーンの提供装置及び該多重スクリーンの動的構成方法を提供する。サービスが表現される少なくとも一つ以上の論理スクリーンと出力スクリーンとを生成するサービス処理モジュール、及び出力スクリーン内の所定領域に論理スクリーンをマッピングし、出力スクリーンを複数のディスプレイ画面に提供する出力モジュールを備える多重スクリーンの提供装置である。

Description

本発明による装置及び方法は、多重スクリーンの構成に係り、さらに詳細には、物理的なディスプレイ画面に複数のコンテンツを提供する多数のスクリーンの動的構成に関する。

関連技術のデジタルＴＶまたはデジタルセットトップボックスのような放送受信装置では、一つの物理的なディスプレイ画面に一つのコンテンツのみを示すか、または一つの物理的なディスプレイ画面に主画面と副画面との２つの画面を同時に示す場合が一般的である。

このとき、主画面と副画面とを同時に示す場合としても、放送受信装置で既定のいくつかの方式のみで二つの画面を配置しうる。そして、主画面に示されるコンテンツの場合にのみコンテンツを構成する全ての要素（ビデオ、オーディオ、データまたはこれらの組合わせ）が再生され、副画面を通じてはコンテンツを構成する一部要素のみが制限的に再生される。

また、コンテンツを提供するソースであって、衛星放送、地上波放送、ケーブル放送のような放送サービス以外にも、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）のような記録媒体または外部入力端子と連結された外部機器があるが、このように多様なソースから提供されるコンテンツをどのようにディスプレイ画面に表すかについても制限的に固定されている。

一方、ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ Ｃｏｍｍｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）、ＯＣＡＰ（Ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）のようなインタラクティブＴＶに対するアプリケーションプログラム環境では、一般的に、物理的なディスプレイ画面を通じて出力されるスクリーンは、一つであると仮定する。

例えば、インタラクティブＴＶに対するアプリケーションプログラム環境では、ＨＡＶｉ（Ｈｏｍｅ Ａｕｄｉｏ／Ｖｉｄｅｏ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）規格によるユーザインターフェース（ＵＩ：Ｕｓｅｒｉｎｔｅｒｆａｃｅ）の構造を採用しているが、ＨＡＶｉ ＵＩ標準でスクリーンの数に制限をおかないが、実際使用では、ディスプレイ画面を通じて出力されるスクリーンは、一つであると仮定することが一般的である。

このような環境では、複数のコンテンツを多数の独立的なスクリーンを通じて示すと同時に、それぞれのスクリーンに表現されたコンテンツに対してデコーディング、デジタル信号処理、ユーザインタラクション処理を行うか、動的にアプリケーションプログラムのライフサイクル及びリソースの使用をそれぞれのスクリーン別に制御し難い。

したがって、多様なコンテンツを多様な方式でディスプレイ画面に構成して提供する方法が必要になった。

本発明は、物理的なディスプレイ画面に複数のコンテンツを提供する多数のスクリーンを動的に構成することを目的とする。

前記目的を達成するために、本発明の実施形態によって多重スクリーンの提供装置は、サービスが表現される少なくとも一つ以上の論理スクリーンと出力スクリーンとを生成するサービス処理モジュール、及び前記出力スクリーン内の所定領域に前記論理スクリーンをマッピングし、前記出力スクリーンを複数のディスプレイ画面に提供する出力モジュールを備える。

前記目的を達成するために、本発明の実施形態によって多重スクリーンの動的構成方法は、サービスが表現される少なくとも一つ以上の論理スクリーンと出力スクリーンとを生成するステップ、前記出力スクリーン内の所定領域に前記論理スクリーンをマッピングするステップ、及び前記出力スクリーンを複数のディスプレイ画面に提供するステップを含む。

本発明の利点及び特徴、そして、それらを達成する方法は、添付される図面と共に詳細に後述されている実施形態を参照すれば、明確になるであろう。しかし、本発明は、後述する実施形態に限定されず、異なる多様な形態で具現され、但し、本実施形態は、本発明の開示を完全にし、当業者に発明の範囲を完全に知らせるために提供されるものであり、本発明は、請求項の範囲によって定義されるだけである。

まず、本発明で使われる用語について概略的に説明する。用語の説明は、本発明の理解を助けるためである。したがって、本発明の詳細な説明において、明示的に限定しない限り、以下で説明される用語は、本発明の技術的思想を限定する意味として使われない。

‘サービス’は、一つの束で表現されるマルチメディアコンテンツであって、少なくとも一つ以上のサービスコンポーネントが一つのサービスを成す。

‘サービスコンポーネント’は、サービスを構成する一部分であって、サービスコンポーネントの種類としては、ビデオコンポーネント、オーディオコンポーネント、データコンポーネントが挙げられる。ここで、ビデオコンポーネントとオーディオコンポーネントとは、それぞれビデオ情報とオーディオ情報とを含む。また、データコンポーネントは、サービス内に存在するアプリケーションを指すが、天気についての情報を提供するアプリケーション、証券情報を提供するアプリケーション、字幕やＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）を提供するアプリケーションを一例として挙げられる。

‘サービスコンテキスト’は、サービスの実行に関連される各種リソース、デバイス、サービスの実行状態に関する情報を含んでおり、サービスの実行を制御できる客体を表す。

‘ディスプレイ画面’は、サービスの内容が実際に表現される物理的な装置、サービスの内容が出力される外部出力ポートまたはサービスが保存される保存装置を意味する。

‘出力スクリーン’は、ディスプレイ画面に実際に出力されるスクリーンであって、任意のサービスが出力スクリーンに直接設定されてディスプレイ画面を通じて表現されるか、または出力スクリーンの一定の領域にマッピングされた少なくとも一つ以上の論理スクリーンがディスプレイ画面を通じて出力される。

‘論理スクリーン’は、任意のサービスが表現される空間であって、出力スクリーンにマッピングされる前には、メモリ上に仮想的にのみ存在し、実際ディスプレイ画面には表現されない。したがって、論理スクリーンは、出力スクリーンにマッピングされることによってディスプレイ画面に出力される。

論理スクリーンと出力スクリーンとは、バックグラウンドスチールイメージ、ビデオラスター、及びグラフィックラスターの組合わせで構成されるが、ここで、グラフィックラスターは、テキスト、線、カラー、及びイメージが合成されるか、またはビデオフレームが混合されて提供される。

‘メインサービス’は、ユーザがディスプレイ画面に現れるメニューまたはリモコンを通じるか、またはアプリケーションがＡＰＩを通じて主サービスとして選択したサービスを意味し、メインサービスが表現されるスクリーンを‘メインスクリーン’という。

‘ＰｉＰ（Ｐｉｃｔｕｒｅ−ｉｎ−Ｐｉｃｔｕｒｅ）サービス’は、ユーザがディスプレイ画面に現れるメニューまたはリモコンを通じるか、またはアプリケーションがＡＰＩを通じてメインスクリーン内で副サービスとして選択したサービスを意味し、ＰｉＰサービスは、‘ＰｉＰスクリーン’またはメインスクリーンを通じて表現される。

‘ＰｉＰスクリーン’は、図１Ａないし図１Ｄに示しているように、他のスクリーン内の一部領域を占めるスクリーンと、図１Ｅ及び図１Ｆに示しているように、他のスクリーンと重畳されない領域に同時に示されるスクリーンとを含み、また、図１Ｇ及び図１Ｈに示しているように、ディスプレイ画面内で任意の位置及び領域に示されるか、または他のスクリーンと重畳されて表現されるスクリーンを含む概念として理解される。

以上で説明されていない用語は、以下、必要な部分で別途に説明する。以下、添付された図面を参照して、本発明の望ましい実施形態を詳細に説明する。

図２は、本発明の一実施形態による論理スクリーンと出力スクリーンとの関係を示す例示図である。図２を参照するに、サービスは、論理スクリーン２１０，２１２，２１４を通じて表現され、このような論理スクリーンは、所定のマッピングブロック２３０によって出力スクリーン２２０，２２２，２２４にマッピングされて表現される。

このとき、２２０で参照される出力スクリーンには、２１０及び２１２で参照される論理スクリーンがマッピングされて表現されており、２２２で参照される出力スクリーンには、２１２及び２１４で参照される論理スクリーンがマッピングされて表現されており、２２４で参照される出力スクリーンには、２１０、２１２及び２１４で参照される論理スクリーンがマッピングされて表現されている。

このように、サービスが表現される少なくとも１以上の論理スクリーンは、マッピングブロック２３０によって出力スクリーンの任意の領域にマッピングされる。

一方、マッピングブロック２３０は、論理スクリーンと出力スクリーンとをマッピングさせる多様な情報の集合体として理解される。このような情報の例として、論理スクリーンが出力スクリーンにマッピングされる領域の座標情報、論理スクリーン及び出力スクリーンを区別する識別情報、出力スクリーンに多数の論理スクリーンが表現される順序についての情報を含みうる。

マッピングブロック２３０は、論理スクリーンのサイズを変更して出力スクリーンの一定の領域に割り当てうる。すなわち、マッピングブロック２３０は、論理スクリーンに対するスケーリング機能及び位置割当機能を行え、図３Ａないし図３Ｅでは、このようなマッピングブロック、すなわち、マッパを含むスクリーンの構成を示している。

図３Ａを参照するに、バックグラウンドスチールイメージＢ、ビデオラスターＶ、及びグラフィックラスターＧの組合わせからなるメインスクリーンは、マッパによって、サイズはそのまま維持しつつ、出力スクリーンの全体にマッピングされる。そして、ビデオ成分のみを有するＰｉＰスクリーンは、マッパによってそのサイズが小さくなりつつ、出力スクリーンの一定領域にマッピングされる。このとき、マッピングされたＰｉＰスクリーンは、メインスクリーン上に置かれ、これは、Ｚ値によって決定される。Ｚは、ｚ−ｏｒｄｅｒ値を表すものであって、ｚ−ｏｒｄｅｒについては後述する。また、オーバーレイスクリーンが前記出力スクリーンと合成されるが、オーバーレイスクリーンは、最外側に置かれる特別のスクリーンであって、例えば、字幕を提供する必要がある場合に利用される。ＰｉＰスクリーンは、図３Ａのように、ビデオ成分のみを有することもあるが、図３Ｂに示したように、バックグラウンドスチールイメージＢ、ビデオラスターＶ、及びグラフィックラスターＧの組合わせで構成されることもある。

図３Ｃを参照するに、バックグラウンドスチールイメージＢ、ビデオラスターＶ、及びグラフィックラスターＧの組合わせからなるメインスクリーンは、マッパによって、サイズはそのまま維持しつつ、出力スクリーンの全体にマッピングされる。そして、ビデオ成分のみを有する２個のＰｉＰスクリーン＃１，＃２がそれぞれマッパによってそのサイズが小さくなりつつ、出力スクリーンの一定領域にマッピングされる。このとき、マッピングされたＰｉＰスクリーンは、メインスクリーン上に置かれ、このとき、Ｚ値は、同一に維持される。また、オーバーレイスクリーンが前記出力スクリーンと合成される。スクリーン構成は、図３Ｃのように、ビデオ成分のみを有する複数のＰｉＰスクリーンを含みうるが、図３Ｄに示したように、バックグラウンドスチールイメージＢ、ビデオラスターＶ、及びグラフィックラスターＧの組合わせからなる複数のＰｉＰスクリーンで構成されることもある。

図３Ｅでは、ＰＯＰ（Ｐｉｃｔｕｒｅ−Ｏｕｔｓｉｄｅ−Ｐｉｃｔｕｒｅ）スクリーンが示されているが、ＰｉＰスクリーンがメインスクリーンの内部で表現されるスクリーンとすれば、ＰＯＰスクリーンは、メインスクリーンの外部で表現されるスクリーンと理解される。図３Ｅを参照するに、バックグラウンドスチールイメージＢ、ビデオラスターＶ、及びグラフィックラスターＧの組合わせからなる複数のＰＯＰスクリーン＃１，＃２が、それぞれマッパによってそのサイズが小さくなりつつ、出力スクリーンの一定領域にマッピングされる。このとき、マッピングされたＰＯＰスクリーン＃１，＃２のＺ値は、同一に維持される。そして、オーバーレイスクリーンが前記出力スクリーンと合成されて表現される。

また、マッピングブロック２３０は、各種のコンピュータプログラム言語で作成されて実行されるインターフェース、関数として具現され、前記のような情報をパラメータとして論理スクリーンと出力スクリーンとの関係を生成または変更することもできる。

また、マッピングブロック２３０は、論理スクリーンと出力スクリーンとの間にマッピング機能を行うようにハードウェアとして具現されることもある。

出力スクリーンには、多様なソースから提供されるサービスが表現されてディスプレイ画面を通じて出力されるが、図４でこれを表している。

一般的に、サービスを提供するソースとして、地上波放送３２０、ケーブル放送３３０のような放送サービスを提供するソースがあり、ＰＶＲ（パーソナルビデオレコーダ）３４０のように、所定の記録媒体に保存されたサービスを提供するソースもある。また、図４では示されていないが、有線または無線ネットワークを通じてサービスを提供するソースもここに含まれる。

このとき、放送受信装置３１０は、このようなソースからサービスを受信し、それぞれのサービスを表現する論理スクリーンを生成する。

次いで、既設定の方式やユーザまたはアプリケーションにより設定された方式によって任意のサービスが出力スクリーンに直接設定されて、ディスプレイ画面を通じて表現されるか、または出力スクリーンの一定の領域にマッピングされた少なくとも一つ以上の論理スクリーンがディスプレイ画面３５０を通じて出力される。図４では、地上波放送３２０、ケーブル放送３３０及びＰＶＲ ３４０によって提供されるサービスがディスプレイ画面３５０を通じて表現されると示している。

図４では、サービスを提供するソースの例であって、地上波放送３２０、ケーブル放送３３０、ＰＶＲ ３４０を示しているが、サービスを提供するソースは、これに限定されず、一つの束で表現されるマルチメディアコンテンツを提供すれば、本発明におけるソースに含まれる。

一方、本発明におけるサービスには、抽象サービスと非抽象サービスとがあるが、これを図５Ａ及び図５Ｂでそれぞれ示している。

抽象サービスは、放送信号からリアルタイムで伝えられるサービスではない、放送チャンネルに対して独立したサービスであって、サービスコンポーネントのうちからビデオコンポーネント、オーディオコンポーネントなしに、データコンポーネント、すなわち、アプリケーションのみからなるサービスが抽象サービスに該当する。例えば、ＯＣＡＰ（Ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）規格でアンバウンドアプリケーションからなるサービスがここに属している。

非抽象サービスは、抽象サービスを除外した残りのサービスと理解される。

本発明では、抽象サービスと非抽象サービスとにそれぞれ独立性を付与しうる。例えば、抽象サービスは、論理スクリーンを経ずに直接出力スクリーンに設定され、非抽象サービスは、論理スクリーンに表現されて抽象サービスが設定された出力スクリーンにマッピングされる。次いで、前記出力スクリーンがディスプレイ画面を通じて出力されるが、これにより、一つの出力スクリーンで抽象サービスと非抽象サービスとが独立的に表現される。また、抽象サービスと非抽象サービスとがそれぞれ別途の論理スクリーンにマッピングされた後、それぞれの論理スクリーンが一つの出力スクリーンにマッピングされることもある。すなわち、抽象サービスと非抽象サービスとは、それぞれ独立した形態として出力スクリーンに表現される。

一方、本発明における論理スクリーンと出力スクリーンとは、それぞれ別途の客体として定義されるが、‘スクリーン’という一つの客体が有する属性情報によって、‘スクリーン’が論理スクリーンとして機能してもよく、出力スクリーンとして機能してもよい。

すなわち、スクリーン客体に関する属性情報のうちからタイプ情報を通じてスクリーンが論理スクリーンであるか出力スクリーンであるかが分かる。

このようなスクリーン客体の属性情報として、‘Ｔｙｐｅ’、‘ｚ−Ｏｒｄｅｒ’、‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’、‘Ｖｉｓｉｂｉｌｉｔｙ’、‘Ａｓｓｏｃｉａｔｅｄ＿Ｄｉｓｐｌａｙ＿Ｓｃｒｅｅｎ’、‘Ａｓｓｏｃｉａｔｅｄ＿Ｓｅｒｖｉｃｅ＿Ｃｏｎｔｅｘｔｓ’、‘ＯｕｔｐｕｔＰｏｒｔ’のような属性情報がある。

図６は、スクリーン客体の属性情報及びこのような属性情報を処理するインターフェースの種類を示している。

‘Ｔｙｐｅ’属性５０５は、スクリーンが論理スクリーンであるか出力スクリーンであるかを表す属性情報である。

‘ｚ−Ｏｒｄｅｒ’属性５１０は、論理スクリーンが出力スクリーン上で表現されるとき、ｚ軸上での順序を決定するためのものであって、図７では、論理スクリーンが出力スクリーン上でｚ−ｏｒｄｅｒ属性によってどのように示されるかを例示している。

図７で、出力スクリーン６１０上には、第１論理スクリーン６２０と第２論理スクリーン６３０とが一定の領域にマッピングされて表現されている。このとき、第１論理スクリーン６２０が出力スクリーン上で表現され、その上に第２論理スクリーン６３０が表現されている。すなわち、ｚ軸方向に出力スクリーン６１０、第１論理スクリーン６２０及び第２論理スクリーン６３０の順序で表現されているが、このような場合に、第１論理スクリーン６２０のｚ−ｏｒｄｅｒ属性値が１に設定され、第２論理スクリーン６２０のｚ−ｏｒｄｅｒ属性値が２に設定される。このとき、ｚ−ｏｒｄｅｒ属性値は、出力スクリーンのｚ軸上で論理スクリーンが表現される順序を示す情報ならば、いかなる数字または文字形態も可能である。

‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性５２０は、論理スクリーンが出力スクリーンにマッピングされて出力される出力スクリーンの領域についての情報を意味するが、図８Ａ及び図８Ｂでこれを例示している。

図８Ａは、論理スクリーン７１０が出力スクリーン７２０の全体領域にマッピングされて出力されることを示しており、図８Ｂは、論理スクリーン７３０が出力スクリーン７４０の一部領域にマッピングされて出力されることを示している。

このとき、‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性を表す情報は、出力スクリーン上の２次元座標情報であるか、または出力スクリーン上での特定位置及び前記特定位置からのオフセット値で表現される。

‘Ｖｉｓｉｂｉｌｉｔｙ’属性５３０は、論理スクリーンが出力スクリーン上に示されるか否かを決定する属性であって、この属性値を変更することによって、論理スクリーンを物理的なディスプレイ画面に見られるようにするか、または消えるようにすることができる。

‘Ａｓｓｏｃｉａｔｅｄ＿Ｄｉｓｐｌａｙ＿Ｓｃｒｅｅｎ’属性５４０は、該当論理スクリーンと連結された出力スクリーンの識別情報を表す。出力スクリーンに連結されていない論理スクリーンは、ディスプレイ画面に見られないか、または他の外部出力に伝送されない。

‘Ａｓｓｏｃｉａｔｅｄ＿Ｓｅｒｖｉｃｅ＿Ｃｏｎｔｅｘｔｓ’属性５５０は、論理スクリーンまたは出力スクリーン自体に連結されたサービスコンテキストについての情報を表すが、サービスコンテキストに設定されたサービスが論理スクリーンまたは出力スクリーンに表現される。

‘ＯｕｔｐｕｔＰｏｒｔ’属性５６０は、出力スクリーンが出力される対象についての情報を表すが、出力スクリーンが出力される対象として、ディスプレイ画面、有／無線通信媒体、各種の記録媒体を含みうる。

一方、図６に示された属性情報に対する値を検索するか、または変更するためのインターフェースが提供されるが、ここには、図６に示したように、属性情報の値を設定するか、または論理スクリーンを出力スクリーンと連結するための‘ｓｅｔ’インターフェース、属性情報の値を追加するかまたは論理スクリーンをサービスと連結するための‘ａｄｄ’インターフェース、属性情報の値を検索するための‘ｇｅｔ’インターフェース、属性情報の値を削除するための‘ｒｅｍｏｖｅ’インターフェースがある。このようなインターフェースは、それぞれの機能を行うプロセス、関数、プリシージャ、方法と理解される。

例えば、‘ｇｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ｖｏｉｄ）’方法は、現在スクリーンと関連された出力スクリーンを返還する機能を行う。例えば、現在スクリーンが論理スクリーンである場合には、関連された出力スクリーンが返還され、現在スクリーンが出力スクリーンである場合には、現在スクリーンについての参照情報が返還され、現在スクリーンが論理スクリーンであるが、関連された出力スクリーンが存在していない場合には、‘ＮＵＬＬ’が返還される。

さらに他の例として、‘ｐｕｂｌｉｃ ｖｏｉｄ ｓｅｔＤｉｓｐｌａｙＡｒｅａ（ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ ｒｅｃｔ）ｔｈｒｏｗｓ Ｓｅｃｕｒｉｔｙ Ｅｘｃｅｐｔｉｏｎ、ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’方法は、現在の論理スクリーンを関連された出力スクリーンの所定の領域にマッピングさせる機能を提供する。パラメータに提供されるインスタンスは、‘ｏｒｇ.ｈａｖｉ.ｕｉ’パッケージの‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’クラスタイプであって、２次元位置情報を有する。そして、前記‘ｓｅｔＤｉｓｐｌａｙＡｒｅａ（ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ
ｒｅｃｔ）’方法に対する例外処理として、‘ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’例外と‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外とが行われる。‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外は、現在のスクリーンが論理スクリーンではないか、またはハードウェアまたはソフトウェアプラットホームの特性上現在の論理スクリーンと関連された出力スクリーンの領域が変更されない場合に行われる。

さらに他の例として、‘ｇｅｔＤｉｓｐｌａｙＡｒｅａ（ｖｏｉｄ）’方法は、現在スクリーンの領域についての情報を‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’クラスの形態で返還する。もし、現在のスクリーンが出力スクリーンである場合には、‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ（０,０,１,１）’と同じ値を有する‘ＨＳｃｒｅｅｎＲｅｃｔａｎｇｌｅ’情報を返還し、現在のスクリーンが論理スクリーンである場合には、関連された出力スクリーンで前記論理スクリーンの占める領域についての情報が返還される。そして、現在のスクリーンが論理スクリーンであるが、関連された出力スクリーンが存在していない場合には、‘ＮＵＬＬ’値が返還される。

前述されたそれぞれのインターフェース名は、それぞれの機能を表すための名称に過ぎないので、その名称に限定されず、その機能として理解されねばならない。

図９は、二つのサービスが二つの論理スクリーンにそれぞれ設定され、一つの出力スクリーンにマッピングされて出力される過程を示す例示図である。図９を参照するに、第１サービスは、ビデオ／オーディオ／データの３つのサービスコンポーネントが何れも存在するサービスであり、第２サービスは、ビデオコンポーネント及びオーディオコンポーネントのみが存在する場合を例として挙げたものである。もちろん、本発明では、サービスコンポーネントに対する制約事項をおかず、図９の場合は、一つの可能な例を示すものである。

図９に示したように、第１サービスと第２サービスとが従来の方式と類似した形態でディスプレイ画面に現れるが、本発明による場合、マッピングを通じてディスプレイ画面上に数の制限なしに複数のサービスを多様な位置に独立的に表現しうる。

図１０は、本発明の一実施形態による多重スクリーンの提供装置の構成を示すブロック図である。図１０を参照するに、本発明による多重スクリーンの提供装置９００は、デジタル信号処理モジュール９４０、サービス処理モジュール９５０、出力モジュール９６０及びユーザ／アプリケーションインターフェースモジュール９６５を備える。

このとき、サービスを提供するソースとして、放送信号受信モジュール９１０、記録媒体９２０または外部入力モジュール９３０を備え、サービスが出力される媒体として、ディスプレイ画面９７０、記録媒体９８０または外部出力モジュール９９０を備えうる。

本実施形態で使われる‘モジュール’という用語は、ソフトウェアまたはＦＰＧＡまたはＡＳＩＣのようなハードウェア構成要素を意味し、モジュールは、ある役割を行う。しかしながら、モジュールは、ソフトウェアまたはハードウェアに限定される意味ではない。モジュールは、アドレッシングしうる記録媒体にあるように構成されることもあり、一つまたはそれ以上のプロセッサーを再生させるように構成されることもある。したがって、一例として、モジュールは、ソフトウェア構成要素、客体指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プリシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素及びモジュール内で提供される機能は、さらに小さい数の構成要素及びモジュールで結合されるか、または追加的な構成要素及びモジュールにさらに分離される。それだけでなく、構成要素及びモジュールは、デバイスまたは保安マルチメディアカード内の一つまたはそれ以上のＣＰＵを再生させるように具現されることもある。

デジタル信号処理モジュール９４０は、放送信号受信モジュール９１０、記録媒体９２０または外部入力モジュール９３０からマルチメディアコンテンツのようなサービスを構成する多様な構成情報、例えば、ビデオ情報、オーディオ情報またはデータ情報を受信する。

このとき、放送信号受信モジュール９１０は、衛星、地上波またはケーブル放送信号を受信して伝達するモジュールであり、記録媒体９２０は、サービスを構成するビデオ情報、オーディオ情報またはデータ情報が保存された機器を表し、外部入力モジュール９３０は、ネットワークインターフェースモジュールのようにネットワークに連結された他の機器からサービスを構成するビデオ情報、オーディオ情報またはデータ情報を受信して伝達するモジュールとして理解される。

デジタル信号処理モジュール９４０は、受信されたサービスコンポーネントを利用してサービスを復元するが、このとき、複数のサービスを復元しうる。このとき、前記復元されたサービスは、抽象サービスまたは非抽象サービスを含む。

また、ここで、‘複数のサービス’とは、例えば、放送信号受信モジュール９１０から伝えられる２個以上のサービスを意味することもでき、放送信号受信モジュール９１０及び記録媒体９２０のそれぞれから伝えられる２個以上のサービスを意味することもできる。

デジタル信号処理モジュール９４０で復元されるサービスは、ユーザ／アプリケーションインターフェースモジュール９６５を通じたユーザまたはアプリケーションの選択によって復元されることもある。このとき、ユーザまたはアプリケーションは、どのサービスをどんなスクリーンに連結するかを選択しうる。

サービス処理モジュール９５０は、デジタル信号処理モジュール９４０によって復元されたサービスを表現するための論理スクリーン及び出力スクリーンを生成する。すなわち、サービス処理モジュール９５０は、サービスを論理スクリーンに連結させる機能を行える。また、デジタル信号処理モジュール９４０によって復元されたサービスは、サービス処理モジュール９５０で論理スクリーンと連結されずに出力スクリーンと直接連結されることもある。

出力モジュール９６０は、出力スクリーン上の所定の領域にサービス処理モジュール９５０によって生成された論理スクリーンをマッピングして出力する。このとき、出力スクリーンへのマッピングは、既設定されたかまたはユーザ／アプリケーションインターフェースモジュール９６５を通じてユーザによって設定される。

出力モジュール９６０によって出力スクリーンは、物理的なディスプレイ画面９７０を通じて出力されるか、または記録媒体９８０に保存される。ここで、記録媒体９８０は、コンピュータによって判読可能であり、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＢＤ（Ｂｌｕｅ−ｒａｙ Ｄｉｓｃ）及び半導体メモリを含む。
また、外部出力モジュール９９０を通じてネットワークに連結された他の機器に伝えられることもある。

このために、出力モジュール９６０は、出力スクリーンが提供される多数の出力ポートを備えうるが、このような場合に、既設定の基本出力ポートまたはユーザ／アプリケーションインターフェースモジュール９６５を通じて指定された出力ポートを通じて出力スクリーンが提供される。

一方、多重スクリーンの提供装置９００は、複数のディスプレイ画面を通じて同時に一つ以上のサービスを表現させうる。このために、出力モジュール９６０は、図１１に示したように、複数のディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎに出力スクリーンを提供し、出力スクリーンとディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎとの連結関係を管理しうる。

出力モジュール９６０は、複数のディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎに同じ出力スクリーンを提供することもでき、各ディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎごとに異なる出力スクリーンを提供することもできる。どんなディスプレイ画面にどんな出力スクリーンを提供するかは、ユーザ／アプリケーションインターフェースモジュール９６５を通じて、ユーザまたはアプリケーションが決定しうる。また、出力モジュール９６０は、ユーザまたはアプリケーションの要請によって各ディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎにいかなる出力スクリーンが提供されるかについての情報、すなわちディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎと出力スクリーンとの連結関係に関する情報を提供するか、またはディスプレイ画面９７０−１,９７０−２,…,９７０−Ｎと出力スクリーンとの連結関係を変更することもある。

ユーザまたはアプリケーションは、ユーザ／アプリケーションインターフェースモジュール９６５を通じて所望のサービスを選択または復元させうる。また、ユーザまたはアプリケーションは、ユーザ／アプリケーションインターフェースモジュール９６５を通じて多数の出力スクリーンのうち、任意の出力スクリーンを選択することもできる。

図１１に示された各モジュールは、それぞれの機能によって分離されて示されているので、実際具現においては、それぞれ他のモジュールとの結合も可能である。

図１２は、本発明の一実施形態によって多重スクリーンの動的構成方法を示すフローチャートである。

一般的に、マルチメディアコンテンツを構成するビデオ情報、オーディオ情報、データ情報は、例えば、ＭＰＥＧストリームのような所定のフォーマットによって伝えられる。したがって、デジタル信号処理モジュール９４０は、前記のような情報を受信して該当サービスを復元する（Ｓ１０１０）。このとき、復元されるサービスは、ユーザまたはアプリケーションによって選択されるか、または予め設定される。ユーザがディスプレイ画面で現れるメニューまたはリモコンを利用するか、またはアプリケーションがＡＰＩを利用してどのサービスをどんなスクリーンに連結するかを選択しうる。

一方、データ情報は、サービス内に存在するアプリケーションに関するアプリケーション情報を含み、このようなアプリケーション情報は、アプリケーションがＰｉＰスクリーンで実行されるか否かを表すシグナル情報を含む。アプリケーション情報の例として、ＭＨＰ規格によるＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）とＯＣＡＰ規格によるＸＡＩＴ（ｅＸｔｅｎｄｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）があり、このようなアプリケーション情報に前記シグナル情報を追加しうる。

次いで、サービス処理モジュール９５０は、前記復元されたサービスが表現されるスクリーンを生成し（Ｓ１０２０）、生成したスクリーンに復元されたサービスを連結させる（Ｓ１０３０）。Ｓ１０２０で生成されたスクリーンは、論理スクリーンと出力スクリーンとを備える。

出力モジュール９６０は、論理スクリーンを出力スクリーンにマッピングした後（Ｓ１０４０）、少なくとも一つ以上のディスプレイ画面に前記出力スクリーンを提供する（Ｓ１０５０）。もちろん、出力モジュール９６０は、論理スクリーンをマッピングせずとも、サービス処理モジュール９５０によってサービスが連結されている出力スクリーンを提供しうる。

また、前述したように、出力スクリーンと複数のディスプレイ画面との連結関係を管理する作業が出力モジュール９６０によって行われる。

一方、図１２では、復元されたサービスが論理スクリーンを経て出力スクリーンを通じて提供されると表現されているが、論理スクリーンを経ずに直接出力スクリーンを通じて提供されることもある。

また、ユーザがＰｉＰサービスを選択する場合には、２つのモードとしてＰｉＰサービスが表現されるが、第１モードでは、ＰｉＰサービスのための別途の論理スクリーン、例えば、ＰｉＰスクリーンが生成されず、メインスクリーンで選択されたＰｉＰサービスのビデオコンポーネントのみが表現され、第２モードでは、ＰｉＰサービスのための別途の論理スクリーンが生成され、生成されたＰｉＰスクリーン内で選択されたＰｉＰサービスが表現される。

一方、図１２では、説明の便宜上一つのサービスが出力スクリーンにマッピングされる過程を説明しているが、スクリーン属性情報を利用して、多数のサービスが多数の論理スクリーンを通じてまたは直接的に一つの出力スクリーン内の任意の領域にマッピングされる。

したがって、出力スクリーンがディスプレイ画面を通じて提供される場合には、ユーザまたはアプリケーションは、多数のサービスを実行しうる。

図１３は、本発明の実施によって多重スクリーンを提供するためのソフトウェアアーキテクチャーを示す例示図である。図１３を参照するに、本発明によるソフトウェアアーキテクチャー１１００は、デバイスドライバレイヤ１１１０、ＡＰＩレイヤ１１２０及びアプリケーションレイヤ１１３０を備える。

デバイスドライバレイヤ１１１０は、マルチメディアコンテンツを提供する多様なソースからサービスを構成するサービスコンポーネントを受信してデコーディングする。このとき、サービスコンポーネントの例として、ビデオ情報、オーディオ情報またはデータ情報を含む。

ＡＰＩレイヤ１１２０は、論理スクリーン及び出力スクリーンを生成し、サービス、論理スクリーン、出力スクリーン間のマッピングを行う。

アプリケーションレイヤ１１３０は、サービスが表現される論理スクリーンをユーザが動的に構成できるユーザインターフェースを提供するか、またはユーザの命令をＡＰＩレイヤ１１２０に伝達して該当命令による動作を行うようにできる。

一方、ユーザは、アプリケーションレイヤ１１３０を通じてデバイスドライバレイヤ１１１０にとって、出力スクリーンを物理的なディスプレイ画面を通じて出力させるか、または記録媒体に保存させうる。また、デバイスドライバレイヤ１１１０によって出力スクリーンをネットワークを通じて他の機器に伝送することもできる。

このために、デバイスドライバレイヤ１１１０は、前記出力スクリーンを提供する多数の出力ポートを備えうるが、多数の出力ポートは、ＡＰＩレイヤ１１２０に存在することもできる。
一方、多数の論理スクリーンを出力スクリーン上に動的に構成するために、ＡＰＩレイヤ１１２０は、多数のソフトウェアモジュールを備えうるが、ここでは、‘ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒ’モジュール、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール、及び‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュールを例として説明し、このようなモジュールの関係を図１４で示している。

‘ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒ’モジュール１２１０は。‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュールを管理しつつ、所望のスクリーンを探すか、またはスクリーン間のデバイス共有情報を知らせるか、または‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール１２５０の登録または解除を担当する役割を行う。

‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０は、スクリーン客体１２２０と関連されてスクリーン客体に対するインターフェース客体であって、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０のインターフェース動作によって、スクリーン客体が論理スクリーンと出力スクリーンとにスクリーンの類型が決定され、図６に示されている多様な属性情報が設定される。前述した‘ｓｅｔ’、‘ａｄｄ’、‘ｇｅｔ’、‘ｒｅｍｏｖｅ’インターフェースは。‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’モジュール１２３０によって提供される。

‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュール１２４０は、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔ’インターフェース客体１２３０によってスクリーン客体１２２０の属性情報が変わった場合、これを知らせるためのイベントクラスであり、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＬｉｓｔｅｎｅｒ’モジュール１２５０は、‘ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔＥｖｅｎｔ’モジュール１２４０によるイベントを受信しようとする所定のアプリケーションクラスに具現されるリスナーインターフェース客体である。

一方、アプリケーション１２６０は、アプリケーションレイヤ１１３０で動作するモジュールであって、ユーザにとって所望のサービスを選択せしめ、出力スクリーンに多数の論理スクリーンを所望の形態によって自由に配する。

したがって、アプリケーション１２６０は、ユーザが論理スクリーンを動的に配し、この管理に関する命令をＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０に伝達すれば、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０を通じて前記命令に対応する動作を行う。

一方、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０は、スクリーン客体１２２０と関連されて、図６で示されたスクリーン客体１２２０の属性情報を管理でき、このような管理のために多様な関数または方法を含みうる。

一方、本発明の一実施形態によれば、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、デバイスドライバレイヤ１１１０から多様なソースから提供されたサービスコンポーネントを受信して、論理スクリーンまたは出力スクリーンで表現されるように動作することもできる。もちろん、このような機能は、別途のモジュール（図示せず）を通じて行われることもある。

図１５は、図１４に示された各モジュールによって複数のサービスを論理スクリーンを通じて出力スクリーンに表す過程を示すフローチャートである。

まず、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、一つの出力スクリーンと実行されるサービス数ほどの論理スクリーンとを生成する（Ｓ１３１０）。

次いで、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、それぞれの論理スクリーンをデバイスドライバレイヤ１１１０から受信したサービスと連結させる（Ｓ１３２０）。このとき、それぞれの論理スクリーンに対して、連結するサービスに対するサービスコンテキスト客体をパラメータとして、論理スクリーン客体の‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’方法を呼び出せる。ここで、‘ａｄｄＳｅｒｖｉｃｅＣｏｎｔｅｘｔ’方法は、論理スクリーンとサービスとを連結する機能を行う方法として理解され、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０によって提供される。

論理スクリーンとサービスとが連結されれば、ＭｕｌｔｉＳｃｒｅｅｎＭａｎａｇｅｒモジュール１２１０は、それぞれの論理スクリーンを出力スクリーンと連結する（Ｓ１３３０）。このとき、それぞれの論理スクリーンに対して、連結する出力スクリーン客体をパラメータとして、論理スクリーン客体の‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’方法を呼び出せる。ここで、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’方法は、論理スクリーンと出力スクリーンとを連結する機能を行う方法として理解され、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０によって提供される。

例えば、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’方法は、‘ｐｕｂｌｉｃｖｏｉｄｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）ｔｈｒｏｗｓ Ｓｅｃｕｒｉｔｙ Ｅｘｃｅｐｔｉｏｎ、ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’の形態で表現され、この方法は、パラメータとして提供される‘ＨＳｃｒｅｅｎ’インスタンスを現在の論理スクリーンと関連させる機能を提供する。このとき、前記‘ＨＳｃｒｅｅｎ’インスタンスは、出力スクリーンであることが望ましい。
そして、前記‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）’方法のパラメータは、‘ＮＵＬＬ’を含みうるが、この場合、例外処理なしに‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）’方法が実行されれば、現在の論理スクリーンは、それ以上出力スクリーンと関連されない。

そして、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）’方法に対する例外処理として、‘ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ’例外と‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外とが行われる。

‘ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’例外は、現在のスクリーンが論理スクリーンではないか、またはハードウェアまたはソフトウェアプラットホームの特性上パラメータとして提供される出力スクリーンが特定の論理スクリーンと関連されて現在の論理スクリーンを前記パラメータに該当する出力スクリーンと関連させれない場合に行われる。

サービスと論理スクリーン、及び多数の論理スクリーンと一つの出力スクリーンとが連結されれば、それぞれの論理スクリーンが表現される出力スクリーンの領域が設定される（Ｓ１３４０）。このとき、それぞれの論理スクリーンに対して、出力スクリーンに見られる領域を設定するために、ＭｕｌｔｉＳｃｒｅｅｎＣｏｎｔｅｘｔモジュール１２３０によって提供される方法を呼び出せる。

本発明によれば、ケーブル、衛星、地上波放送、各種の記録媒体、外部入力から得られた複数のサービスを物理的なディスプレイ画面を通じて多様な形態で表現しうる。

以上、添付された図面を参照して本発明の実施形態を説明したが、当業者は、本発明がその技術的思想や必須な特徴を変更せずに他の具体的な形態で実施されるということが分かるであろう。したがって、前述した実施形態は、全ての面で例示的なものであり、限定的ではないと理解されねばならない。

本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態によってＰｉＰスクリーンが配される形態を示す例示図である。 本発明の一実施形態による論理スクリーンと出力スクリーンとの関係を示す例示図である。 本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。 本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。 本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。 本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。 本発明の一実施形態によるマッパを備えるスクリーンの構成を示す図である。 本発明の一実施形態によってサービスを提供するソースの例を示す例示図である。 本発明の一実施形態によって抽象サービスの例を示す例示図である。 本発明の一実施形態によって非抽象サービスの例を示す例示図である。 論理スクリーン及び出力スクリーンにおける属性情報及びインターフェースの種類を示す例示図である。 論理スクリーンの‘ｚ−ｏｒｄｅｒ’属性を示す例示図である。 論理スクリーンの‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性を示す例示図である。 論理スクリーンの‘Ｄｉｓｐｌａｙ＿Ａｒｅａ’属性を示す例示図である。 二つのサービスが一つの出力スクリーンにマッピングされて出力される過程を示す例示図である。 本発明の一実施形態による多重スクリーンの提供装置の構成を示すブロック図である。 本発明の一実施形態による出力モジュールが出力スクリーンを複数のディスプレイ画面に連結させる状態を示す図である。 本発明の一実施形態によって多重スクリーンの動的構成方法を示すフローチャートである。 本発明の実施によって多重スクリーンを提供するためのソフトウェアアーキテクチャーを示す例示図である。 本発明の実施によってＡＰＩレイヤを構成するモジュールの関係を示す例示図である。 本発明の一実施形態によって、図１４で示された各モジュールによって複数のサービスを論理スクリーンを通じて出力スクリーンに表す過程を示すフローチャートである。

Claims (15)

1. サービスが表現される少なくとも一つ以上の論理スクリーンと出力スクリーンとを生成するサービス処理モジュールと、
   前記出力スクリーン内の所定領域に前記論理スクリーンをマッピングし、前記出力スクリーンを複数のディスプレイ画面に提供する出力モジュールと、を備える多重スクリーンの提供装置。
2. 前記出力モジュールは、ユーザまたはアプリケーションの要請によって前記出力スクリーンと前記複数のディスプレイ画面との連結関係を変更することを特徴とする請求項１に記載の多重スクリーンの提供装置。
3. 前記出力モジュールは、ユーザまたはアプリケーションの要請によって前記出力スクリーンと前記複数のディスプレイ画面との連結関係に関する情報を提供することを特徴とする請求項１に記載の多重スクリーンの提供装置。
4. 前記出力モジュールは、前記ディスプレイ画面に異なる出力スクリーンを提供することを特徴とする請求項１に記載の多重スクリーンの提供装置。
5. 前記出力モジュールは、前記ディスプレイ画面に同じ出力スクリーンを提供することを特徴とする請求項１に記載の多重スクリーンの提供装置。
6. 前記出力スクリーンと前記複数のディスプレイ画面との連結要請をユーザまたはアプリケーションから入力されるインターフェースモジュールをさらに備えることを特徴とする請求項１に記載の多重スクリーンの提供装置。
7. 前記サービスは、ビデオ情報、オーディオ情報、及びデータ情報のうちから少なくとも一つを含むことを特徴とする請求項１に記載の多重スクリーンの提供装置。
8. 前記ビデオ情報、前記オーディオ情報または前記データ情報は、放送信号、記録媒体またはネットワークによって提供されることを特徴とする請求項７に記載の多重スクリーンの提供装置。
9. サービスが表現される少なくとも一つ以上の論理スクリーンと出力スクリーンとを生成するステップと、
   前記出力スクリーン内の所定領域に前記論理スクリーンをマッピングするステップと、
   前記出力スクリーンを複数のディスプレイ画面に提供するステップと、を含む多重スクリーンの提供方法。
10. ユーザまたはアプリケーションの要請によって、前記出力スクリーンと前記複数のディスプレイ画面との連結関係を変更するステップをさらに含むことを特徴とする請求項９に記載の多重スクリーンの提供方法。
11. ユーザまたはアプリケーションの要請によって、前記出力スクリーンと前記複数のディスプレイ画面との連結関係に関する情報を提供するステップをさらに含むことを特徴とする請求項９に記載の多重スクリーンの提供方法。
12. 前記提供するステップは、前記ディスプレイ画面に異なる出力スクリーンを提供するステップを含むことを特徴とする請求項９に記載の多重スクリーンの提供方法。
13. 前記提供するステップは、前記ディスプレイ画面に同じ出力スクリーンを提供するステップを含むことを特徴とする請求項９に記載の多重スクリーンの提供方法。
14. 前記サービスは、ビデオ情報、オーディオ情報、及びデータ情報のうちから少なくとも一つを含むことを特徴とする請求項９に記載の多重スクリーンの提供方法。
15. 前記ビデオ情報、前記オーディオ情報または前記データ情報は、放送信号、記録媒体またはネットワークによって提供されることを特徴とする請求項１４に記載の多重スクリーンの提供方法。