JP2009503602A

JP2009503602A - 多重スクリーン提供装置及び方法

Info

Publication number: JP2009503602A
Application number: JP2008524901A
Authority: JP
Inventors: リー，ジョン−ホ; リー，グァン−キ; ジョン，ウン−ギョー; エイアダムズ，グレン
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2005-08-05
Filing date: 2006-08-04
Publication date: 2009-01-29
Also published as: EP1911281A4; CA2615879A1; EP1911281A1; MX2008001484A; WO2007018380A1

Abstract

多重スクリーン提供装置及び方法に係り、該多重スクリーン提供装置は、ＰｉＰサービス動作に関するモードを入力されるユーザー／アプリケーションインターフェースモジュール、及び前記入力されたモードが第１モードである場合に、メインスクリーン内でサービスのビデオコンポーネントが表現され、前記入力されたモードが第２モードである場合に、ＰｉＰスクリーン内でサービスのバックグラウンドビデオまたはビデオコンポーネントが表現される出力モジュールを備える。

Description

本発明は、多重スクリーン構成に係り、より詳細には、物理的なディスプレイ画面で動的に構成される複数のスクリーンを通じて複数のサービスを提供することに関する。

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

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

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

一方、ＭＨＰ（マルチメディアホームプラットホーム）、ＡＣＡＰ（アドバンストコモンアプリケーションプラットホーム）、ＯＣＡＰ（オープンケーブルアプリケーションプラットホーム）のようなインタラクティブＴＶに対するアプリケーションプログラム環境では、一般的に物理的なディスプレイ画面を通じて出力されるスクリーンは一つであると仮定する。

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

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

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

本発明は、物理的なディスプレイ画面で動的に構成されるスクリーンを通じてサービスを提供する装置及び方法を提供することを目的とする。

前記目的を達成するために、本発明の実施形態による多重スクリーン提供装置は、ＰｉＰ（ピクチャー−イン−ピクチャー）サービス動作に関するモードを入力されるユーザー／アプリケーションインターフェースモジュールと、前記入力されたモードが第１モードである場合に、メインスクリーン内でサービスのビデオコンポーネントが表現され、前記入力されたモードが第２モードである場合に、ＰｉＰスクリーン内でサービスのバックグラウンドビデオまたはビデオコンポーネントが表現される出力モジュールとを備える。

前記目的を達成するために、本発明の実施形態による多重スクリーン提供方法は、ＰｉＰサービス動作に関するモードを入力される（ａ）ステップと、前記入力されたモードが第１モードである場合に、メインスクリーン内でサービスのビデオコンポーネントが表現される（ｂ）ステップと、前記入力されたモードが第２モードである場合に、ＰｉＰスクリーン内でサービスのバックグラウンドビデオまたはビデオコンポーネントが表現される（ｃ）ステップと、を含む。

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

以下、本発明の実施形態による多重スクリーン提供装置及び方法を説明するためのブロック図または処理フローチャートについての図面を参考して本発明について説明する。この時、処理フローチャートの各ブロックとフローチャートの組み合わせとはコンピュータプログラムインストラクションにより行われうるということが理解できるであろう。これらコンピュータプログラムインストラクションは、汎用コンピュータ、特殊用コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサーに搭載されうるので、コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサーを通じて行われるそのインストラクションが、フローチャートのブロックで説明された機能を行う手段を生成する。

これらコンピュータプログラムインストラクションは、特定方式で機能を具現するためにコンピュータまたはその他のプログラム可能なデータプロセシング装備を指向できるコンピュータ利用可能またはコンピュータ判読可能メモリに保存されることも可能であるので、そのコンピュータ利用可能またはコンピュータ判読可能メモリに保存されたインストラクションは、フローチャートのブロックで説明された機能を行うインストラクション手段を備える製造品目を生産することもできる。

コンピュータプログラムインストラクションは、コンピュータまたはその他のプログラム可能なデータプロセシング装備上に搭載されることも可能であるので、コンピュータまたはその他のプログラム可能なデータプロセシング装備上で一連の動作ステップらが行われてコンピュータで行われるプロセスを生成して、コンピュータまたはその他のプログラム可能なデータプロセシング装備を行うインストラクションは、フローチャートのブロックで説明された機能を行うためのステップを提供することもできる。

また、各ブロックは、特定された論理的機能を行うための一つ以上の実行可能なインストラクションを含むモジュール、セグメントまたはコードの一部を表すことができる。また、いくつかの代替実行例では、ブロックで言及された機能が順序を外れて発生することもあるということに注目せねばならない。例えば、続けて図示されている二つのブロックは、実質的に同時に行われることもあり、またはそのブロックが時々該当する機能によって逆順に行われることもある。

一方、本発明についての説明を容易にするために、本発明と関連した基本的な概念を定義する。

‘サービス’は、一つのまとまりで表現されるマルチメディアコンテンツであり、複数のサービスコンポーネントが一つのサービスをなすようになる。

‘サービスコンポーネント’は、サービスを構成する一部分てあり、ビデオコンポーネント、オーディオコンポーネント、データコンポーネントなどを含む。この時、データコンポーネントは、サービス内に存在するアプリケーションプログラムを示す。

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

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

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

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

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

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

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

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

図２は、本発明の一実施形態による論理スクリーンと出力スクリーンとの関係を示す例示図である。

図２を参照するに、サービスは、論理スクリーン２１０、２１２、２１４を通じて表現され、このような論理スクリーンは、所定のマッピングブロック２３０により出力スクリーン２２０、２２２、２２４にマッピングされて表現されうる。

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

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

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

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

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

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

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

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

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

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

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

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

次いで、既定の方式、ユーザーまたはアプリケーションにより設定された方式によって、任意のサービスが出力スクリーンに直接設定されてディスプレイ画面を通じて表現されるか、出力スクリーンの一定の領域にマッピングされた少なくとも一つ以上の論理スクリーンがディスプレイ画面３５０を通じて出力される。

図４では、地上波放送３２０、ケーブル放送３３０、そしてＰＶＲ３４０により提供されるサービスがディスプレイ画面３５０を通じて表現されることを示している。図４では、サービスを提供するソースの例として、地上波放送３２０、ケーブル放送３３０、ＰＶＲ３４０を図示しているが、サービスを提供するソースはこれに限定されず、一つのまとまりで表現されるマルチメディアコンテンツを提供するならば本発明でのソースに含まれうる。

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

抽象サービスは、放送信号からリアルタイムで伝えられるサービスではない放送チャンネルに対して独立したサービスであり、サービスコンポーネントのうち、ビデオコンポーネント、オーディオコンポーネントなしにデータコンポーネント、すなわち、アプリケーションプログラムのみで形成されたサービスが抽象サービスに該当する。例えば、ＯＣＡＰ（オープンケーブルアプリケーションプラットホーム）規格でアンバウンドアプリケーションからなるサービスがこれに属する。

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

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

一方、本発明での論理スクリーンと出力スクリーンとは、それぞれ別途の客体として定義されてもよいが、‘スクリーン’という一つの客体が持つ属性情報によって、‘スクリーン’が論理スクリーンとして機能するか、出力スクリーンとして機能する。すなわち、スクリーン客体に関する属性情報のうち、タイプ情報を通じてスクリーンが論理スクリーンであるか出力スクリーンであるかが分かる。

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

図６は、スクリーン客体の属性情報とこのような属性情報を処理するインターフェースの種類とを示している。
‘Ｔｙｐｅ’属性５１０は、スクリーンが論理スクリーンなのか出力スクリーンなのかを表す属性情報である。
‘ｚ−Ｏｒｄｅｒ’属性５２０は、論理スクリーンが出力スクリーン上で表現される時、ｚ軸上での順序を決定するためのものであり、図７では、論理スクリーンが出力スクリーン上でｚ−ｏｒｄｅｒ属性によってどのように見られるかを例示している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１０は、本発明の一実施形態による多重スクリーン提供装置の構成を示すブロック図である。図１０を参照するに、本発明による多重スクリーン提供装置９００は、デジタル信号処理モジュール９４０、サービス処理モジュール９５０、出力モジュール９６０そしてユーザー／アプリケーションインターフェースモジュール９６５を備える。
この時、サービスを供給するソースとして、放送信号受信モジュール９１０、記録媒体９２０または外部入力モジュール９３０を含むことができて、サービスが出力される媒体としてディスプレイ画面９７０、記録媒体９８０または外部出力モジュール９９０を備えることができる。

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

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

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

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

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

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

サービス処理モジュール９５０は、デジタル信号処理モジュール９４０により復元されたサービスを表現するための複数の論理スクリーン及び出力スクリーンを生成する。

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

また、デジタル信号処理モジュール９４０により復元されたサービスは、サービス処理モジュール９５０で論理スクリーンと連結されず、出力スクリーンと直接連結されて出力モジュール９６０により出力されうる。

出力モジュール９６０により、出力スクリーンは、物理的なディスプレイ画面９７０を通じて出力されるか、記録媒体９８０に記録されうる。ここで記録媒体９８０は、コンピュータにより判読でき、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＢＤ及び半導体メモリを含む。

また、外部出力モジュール９９０を通じてネットワークに連結された他の機器に伝えられることも可能である。

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

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

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

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

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

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

次いで、前記復元されたサービスを本発明による論理スクリーンで表現されるように設定し（Ｓ１０２０）、前記論理スクリーンを本発明による出力スクリーンにマッピングした後（Ｓ１０３０）、ディスプレイ画面、記録媒体またはネットワークを通じて前記出力スクリーンが提供される（Ｓ１０４０）。

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

図１１では、説明の便宜上、一つのサービスが出力スクリーンにマッピングされる過程を説明しているが、スクリーン属性情報を利用して複数のサービスが、複数の論理スクリーンを通じて、または直接的に一つの出力スクリーン内の任意の領域にマッピングされうる。したがって、出力スクリーンがディスプレイ画面を通じて提供される場合には、ユーザーまたはアプリケーションは、複数のサービスを実行できる。

一方、ユーザーまたはアプリケーションがＰｉＰサービスを選択する場合に、多重スクリーン提供装置９００は、２つのモードとしてＰｉＰサービスを表現できるが、図１２Ａでは第１モードを、図１２Ｂでは第２モードを示している。

図１２Ａを参照するに、第１モードでは、ＰｉＰサービスのための別途の論理スクリーン、例えば、ＰｉＰスクリーンが生成されず、メインスクリーンで選択されたＰｉＰサービスのビデオコンポーネントのみ表現される。この時、第１モードでは、ＰｉＰサービスと関連したアプリケーションは実行されないか、その動作が非活性化される。

図１２Ｂを参照するに、第２モードでは、ＰｉＰサービスのための別途の論理スクリーンが生成されて、生成されたＰｉＰスクリーン内で選択されたＰｉＰサービスが表現される。第２モードで提供されるＰｉＰスクリーンには、壁紙の役割を行うバックグラウンドビデオを備えるか、ビデオコンポーネントを備えることができる。また、第２モードでは、第１モードとは異なってＰｉＰサービスと関連したアプリケーションは実行されうる。この時、アプリケーションの実行如何は前述したシグナル情報により決定されうる。

前記第１モードと前記第２モードとは、同時に行わないことが望ましい。

また、前記のようなモードは、ユーザー／アプリケーションインターフェースモジュール９６５を通じたユーザーの入力またはアプリケーションにより選択されうるが、もし、ユーザーまたはアプリケーションが第１モードを選択した場合、デジタル信号処理モジュール９４０は、選択されたＰｉＰサービスのビデオコンポーネントのみを復元し、復元されたビデオコンポーネントは、サービス処理モジュール９５０により生成されたメインスクリーンにマッピングされる。次いで、出力モジュール９６０により生成された出力スクリーンを通じてディスプレイされる。もし、ユーザーまたはアプリケーションが第２モードを選択した場合、デジタル信号処理モジュール９４０は選択されたＰｉＰサービスを復元して、復元されたサービスはサービス処理モジュール９５０により生成されたＰｉＰスクリーンにマッピングされる。次いで、出力モジュール９６０により生成された出力スクリーンを通じてディスプレイされる。

図１３は、本発明の実施によって多重スクリーンを提供するためのソフトウェアアーキテクチャーを示す例示図である。

このために、デバイスドライバレイヤー１１１０は、前記出力スクリーンを提供する複数の出力ポートを備えてもよいが、複数の出力ポートは、ＡＰＩレイヤー１１２０に存在することもある。

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

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

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

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

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

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

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

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

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

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

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

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

例えば、‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ’メソッドは、‘ｐｕｂｌｉｃｖｏｉｄｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）ｔｈｒｏｗｓＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ，ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ’の形態で表現され、このメソッドは、パラメータとして提供される‘ＨＳｃｒｅｅｎ’インスタンスを現在の論理スクリーンと関連させる機能を提供する。この時、前記‘ＨＳｃｒｅｅｎ’インスタンスは、出力スクリーンであることが望ましい。

そして、前記‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）’メソッドのパラメータは‘ＮＵＬＬ’を含むことができるが、この場合、例外処理なしに‘ｓｅｔＤｉｓｐｌａｙＳｃｒｅｅｎ（ＨＳｃｒｅｅｎｓｃｒｅｅｎ）’メソッドが実行されれば、現在の論理スクリーンは、それ以上出力スクリーンと関連しない。

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

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

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

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

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

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

Claims

ＰｉＰサービス動作に関するモードを入力されるインターフェースモジュールと、
前記入力されたモードが第１モードである場合に、メインスクリーン内でサービスのビデオコンポーネントが表現され、前記入力されたモードが第２モードである場合に、ＰｉＰスクリーン内でサービスのバックグラウンドビデオまたはビデオコンポーネントが表現される出力モジュールと、を備える多重スクリーン提供装置。
前記入力されたモードが第１モードである場合に前記サービスのビデオコンポーネントのみ復元し、前記サービスのバックグラウンドビデオまたはビデオコンポーネントを復元するデジタル信号処理モジュールをさらに備えることを特徴とする請求項１に記載の多重スクリーン提供装置
前記入力されたモードが第１モードである場合に、前記サービスと関連したアプリケーションは行われないことを特徴とする請求項１に記載の多重スクリーン提供装置。
前記入力されたモードが第２モードである場合に、前記サービスと関連したアプリケーションが行われることを特徴とする請求項３に記載の多重スクリーン提供装置。
前記アプリケーションの実行如何は、シグナル情報により決定されることを特徴とする請求項４に記載の多重スクリーン提供装置。
前記第１モードと前記第２モードとは同時に行われないことを特徴とする請求項１に記載の多重スクリーン提供装置。
前記インターフェースモジュールは、ユーザーまたはアプリケーションにより前記ＰｉＰサービス動作に関するモードを入力されることを特徴とする請求項１に記載の多重スクリーン提供装置。
ＰｉＰサービス動作に関するモードを入力される（ａ）ステップと、
前記入力されたモードが第１モードである場合に、メインスクリーン内でサービスのビデオコンポーネントが表現される（ｂ）ステップと、
前記入力されたモードが第２モードである場合に、ＰｉＰスクリーン内でサービスのバックグラウンドビデオまたはビデオコンポーネントが表現される（ｃ）ステップと、を含む多重スクリーン提供方法。
前記（ｂ）ステップは、前記サービスと関連したアプリケーションは行われないステップをさらに含むことを特徴とする請求項８に記載の多重スクリーン提供方法。
前記（ｃ）ステップは、前記サービスと関連したアプリケーションが行われるステップをさらに含むことを特徴とする請求項８に記載の多重スクリーン提供方法。
前記アプリケーションの実行如何は、シグナル情報により決定されることを特徴とする請求項１０に記載の多重スクリーン提供方法。
前記第１モードと前記第２モードとは同時に行われないことを特徴とする請求項８に記載の多重スクリーン提供方法。
前記インターフェースモジュールは、ユーザーまたはアプリケーションにより前記ＰｉＰサービス動作に関するモードを入力されることを特徴とする請求項８に記載の多重スクリーン提供方法。