(57)【特許請求の範囲】
【請求項１】
リッチメディアサービスのための端末のユーザインターフェース方法であって、
受信されたストリームのヘッダをチェックするステップと、
前記ヘッダ内の適応情報に従って、前記受信されたストリームの場面構成要素を用いて場面を適応的に構成するステップと、
前記適応的に構成された場面をディスプレーするステップとを有し、
前記適応情報に適応タイプ、及び適応タイプ値を追加し、
前記適応タイプは、前記受信されたストリームの適応基準を示し、前記適応タイプ値は前記受信されたストリームの適応基準値を示し、
前記適応基準は、ディスプレーサイズ、演算能力、電力消耗量、メモリ情報、及び前記受信されたストリームを処理するために要求される装置の入出力性能の中の少なくとも１つを含むことを特徴とするユーザインターフェース方法。
【請求項２】
前記適応情報は、適応制約の属性に含まれることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項３】
前記適応情報は、場面構成要素の挿入と関連した命令語単位で設定されることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項４】
前記適応情報は、場面ユニット単位で設定され、前記場面ユニットは、少なくとも１つのストリームであり、所定の時間内に場面を構成するために使用されることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項５】
前記適応情報は、アクセスユニット単位で設定され、前記アクセスユニットは、最小ストリーム単位であり、単位時間内で場面を構成するために使用されることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項６】
前記適応情報は、オーディオストリーム及びビデオストリームを統合した簡易統合フォーマット（ＳＡＦ）のアクセスユニット（ＡＵ）単位で設定されることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項７】
前記適応情報は、フラグメント単位で設定され、前記フラグメント単位は、アクセスユニットのフラグメントであり、単位時間内で場面を構成するために使用されることを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項８】
前記適応基準は、前記場面を適応的に構成するためにそれぞれ使用されるグラフィック要素のための情報、フォント要素のための情報、テキスト要素のための情報、及びイメージ又はビデオデータのための情報の中の少なくとも１つをさらに含むことを特徴とする請求項１に記載のユーザインターフェース方法。
【請求項９】
リッチメディアサービスのための端末のユーザインターフェース装置であって、
受信されたストリームのヘッダをチェックし前記受信されたストリームを復号する復号化部と、
前記復号化部によりチェックされた前記ヘッダに含まれた適応情報に従って、前記受信されたストリームの場面構成要素を用いて場面を適応的に構成するレンダラと、
前記適応的に構成された場面をディスプレーするディスプレー部とを有し、
前記適応情報に適応タイプ、及び適応タイプ値を追加し、
前記適応タイプは、前記受信されたストリームの適応基準を示し、前記適応タイプ値は前記受信されたストリームの適応基準値を示し、
前記適応基準は、ディスプレーサイズ、演算能力、電力消耗量、メモリ情報、及び前記  受信されたストリームを処理するために要求される装置の入出力性能の中の少なくとも１つを含むことを特徴とするユーザインターフェース装置。
【請求項１０】
前記適応情報は、適応制約の属性に含まれることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１１】
前記適応情報は、場面構成要素の挿入と関連した命令語単位で設定されることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１２】
前記適応情報は、場面ユニット単位で設定され、前記場面ユニットは、少なくとも１つのストリームであり、所定の時間内に場面を構成するために使用されることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１３】
前記適応情報は、アクセスユニット単位で設定され、前記アクセスユニットは、最小ストリーム単位であり、単位時間内で場面を構成するために使用されることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１４】
前記適応情報は、オーディオストリーム及びビデオストリームを統合した簡易統合フォーマット（ＳＡＦ）のアクセスユニット（ＡＵ）単位で設定されることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１５】
前記適応情報は、フラグメント単位で設定され、前記フラグメント単位は、アクセスユニットのフラグメントであり、所定の時間内に場面を構成するために使用されることを特徴とする請求項９に記載のユーザインターフェース装置。
【請求項１６】
前記適応基準は、前記場面を適応的に構成するためにそれぞれ使用されるグラフィック要素のための情報、フォント要素のための情報、テキスト要素のための情報、及びイメージ又はビデオデータのための情報の中の少なくとも１つをさらに含むことを特徴とする請求項９に記載のユーザインターフェース装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リッチメディアサービスをサポートする端末のコンテンツ構成技術に係り、より詳細には、端末の特定の条件及び性能を考慮して場面（ｓｃｅｎｅ）を構成する、リッチメディアサービスのための端末のユーザインターフェース装置及び方法に関する。
【背景技術】
【０００２】
通信市場は、既存の技術の再結合又は統合により新たなサービスの生産を求められている。これに関連して、近年、通信及びブロードキャスト技術の発達に伴い、ＴＶのようなブロードキャスト端末だけでなく携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）通信装置（以下、“端末”と称する。）を介してリッチメディア（Ｒｉｃｈ  Ｍｅｄｉａ）サービスを提供するように発展している。
【０００３】
軽量アプリケーション場面表現（Ｌｉｇｈｔｗｅｉｇｈｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｃｅｎｅ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、以下、“ＬＡＳｅＲ”と称する。）は、リッチメディアサービスを提供するための国際標準規格として採用されている。ＬＡＳｅＲは、場面記述、ビデオ、オーディオ、イメージ、フォント、及びメタデータのような様々な要素を用いて様々なマルチメディアの自由な表現及びユーザとの相互作用が可能なサービスを提供できる。また、ＬＡＳｅＲ技術は、簡易統合フォーマット（Ｓｉｍｐｌｅ  Ａｇｇｒｅｇａｔｉｏｎ  Ｆｏｒｍａｔ、以下、“ＳＡＦ”と称する。）を用いて様々なメディアのエレメンタリストリーム（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ、以下、“ＥＳ”と称する。）の多重化及び同期化を行い、その複雑度を最小化できる。
【０００４】
通信技術の最近の動向に従って、ＤＶＢ−ＣＢＭＳ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ  −  Ｃｏｎｖｅｒｇｅｎｃｅ  ｏｆ  Ｂｒｏａｄｃａｓｔｉｎｇ  ａｎｄ  Ｍｏｂｉｌｅ  Ｓｅｒｖｉｃｅ）やＩＰＴＶ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｔｅｌｅｖｉｓｉｏｎ）のように網（ｎｅｔｗｏｒｋ）の統合で様々なタイプの端末が１つの網を介して接続されるネットワークモデルが可能である。単一統合サービスプロバイダーが有線ＩＰＴＶの有線・無線統合により形成された網を運営するサービスモデルである場合、各端末のタイプに関係なく同一のサービスを提供できる。
【０００５】
このようなビジネスモデルにおいて、特に、ブロードキャストサービスモデルである場合に、単一のブロードキャストストリームは、様々なディスプレーサイズ、性能、及び特徴を有する端末に同時に送信される。したがって、異なる特性を有する複数の端末に同一のリッチメディアサービスが提供される。結果的に、ブロードキャストコンテンツを受信する場合に、スクリーンサイズが大きい端末（例えば、ＴＶ）からスクリーンサイズが小さい端末（例えば、携帯電話）まで１つの同一のＬＡＳｅＲコンテンツが提供される。
【０００６】
しかしながら、ＴＶのようなスクリーンサイズに最適化した場面を受信した端末は、ブロードキャストサービスコンテンツのための使用可能なリソースを確保することが難しいだけでなく、実際の端末のスクリーンサイズに比べて過度に複雑な場面を構成しなければならないという問題点があった。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで、本発明は上記従来の問題点に鑑みてなされたものであって、本発明の目的は、マルチメディアサービスのための場面を構成するための装置及び方法を提供することにある。
【０００８】
本発明のまた他の目的は、マルチメディアサービスコンテンツを用いて場面を適応的に構成する装置及び方法を提供することにある。
【０００９】
本発明のさらにまた他の目的は、単一のマルチメディアサービスコンテンツをフィルタリングすることにより場面を適応的に構成する装置及び方法を提供することにある。
【００１０】
本発明のさらなる他の目的は、リッチメディア（例えば、ＬＡＳｅＲ）コンテンツを用いて場面を適応的に構成する装置及び方法を提供することにある。
【００１１】
本発明のさらにその他の目的は、受信端末の特定の条件及び性能を考慮してＬＡＳｅＲ場面を構成する装置及び方法を提供することにある。
【課題を解決するための手段】
【００１２】
上記のような目的を達成するために、本発明の一態様によれば、リッチメディアサービスのための端末のユーザインターフェース方法であって、受信されたストリームのヘッダをチェックするステップと、前記ヘッダ内の適応情報に従って、前記受信されたストリームの場面構成要素を用いて場面を適応的に構成するステップと、前記適応的に構成された場面をディスプレーするステップとを有し、前記適応情報に適応タイプ、及び適応タイプ値を追加し、前記適応タイプは、前記受信されたストリームの適応基準を示し、前記適応タイプ値は前記受信されたストリームの適応基準値を示し、前記適応基準は、ディスプレーサイズ、演算能力、電力消耗量、メモリ情報、及び前記受信されたストリームを処理するために要求される装置の入出力性能の中の少なくとも１つを含むことを特徴とする。
【００１３】
本発明の他の態様によれば、リッチメディアサービスのための端末のユーザインターフェース装置であって、受信されたストリームのヘッダをチェックし前記受信されたストリームを復号する復号化部と、前記復号化部によりチェックされた前記ヘッダに含まれた適応情報に従って、前記受信されたストリームの場面構成要素を用いて場面を適応的に構成するレンダラと、前記適応的に構成された場面をディスプレーするディスプレー部とを有し、前記適応情報に適応タイプ、及び適応タイプ値を追加し、前記適応タイプは、前記受信されたストリームの適応基準を示し、前記適応タイプ値は前記受信されたストリームの適応基準値を示し、前記適応基準は、ディスプレーサイズ、演算能力、電力消耗量、メモリ情報、及び前記  受信されたストリームを処理するために要求される装置の入出力性能の中の少なくとも１つを含むことを特徴とする。
【発明の効果】
【００１４】
本発明は、ディスプレーサイズ、ＣＰＵ処理能力、メモリ、バッテリー状態、入出力装置などのような端末の性能と関連した特定の条件又は属性及び特定のイベントを考慮して、使用可能なリソースが不足した端末でのＬＡＳｅＲサービスをサポートする負担を減少させ、使用可能なリソースが十分な端末ではより豊富なＬＡＳｅＲサービスを提供できる。
【図面の簡単な説明】
【００１５】
【図１】ＬＡＳｅＲデータストリームを受信する端末の動作を示す図である。
【図２】本発明の実施形態によるＬＡＳｅＲデータストリームを受信する端末の動作を示す図である。
【図３】本発明の実施形態によるＬＡＳｅＲサービスでデータストリームを多重化することによりサービスする場合に、ＬＡＳｅＲデータストリームを受信する端末の動作を示す図である。
【図４】本発明の実施形態によるＬＡＳｅＲデータストリームを受信する端末の動作を示す図である。
【図５】本発明の実施形態によるＬＡＳｅＲコンテンツをサービスする動作を示す図である。
【図６】本発明の実施形態による送信器の構成を示すブロック図である。
【図７】本発明の実施形態による受信器の構成を示すブロック図である。
【発明を実施するための形態】
【００１６】
本発明の他の目的、利点、及び顕著な特徴は、添付の図面及び本発明の実施形態からなされた以下の詳細な説明から、この分野の当業者に明確になるはずである。
【００１７】
添付の図面を参照した下記の説明は、本発明の実施形態の包括的な理解を助けるために提供する。したがって、この理解を助けるための様々な特定の詳細を含む。しかしながら、これら詳細な説明は、単に例示的なものとみなされる。さらに、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかであろう。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００１８】
次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかであろう。
【００１９】
以降の説明において、リッチメディアエンジン（Ｒｉｃｈ  Ｍｅｄｉａ  Ｅｎｇｉｎｅ、以下、“ＲＭＥ”と称する。）のタイプであるＬＡＳｅＲエンジンに基づく端末を一例を挙げて説明する。一方、ＬＡＳｅＲエンジンに基づく端末の一例を他のＲＭＥエンジンに基づく端末に同様に適用できる。しかしながら、端末に適用されるＲＭＥエンジン又はシステムが変わる場合には、そのエンジン、システム、及びデータを構成する構成要素の名称は、他のＲＭＥエンジン又はシステムで固有に使用される異なる名称を使用することもある。
【００２０】
本発明の実施形態は、ＬＡＳｅＲサービスで各端末の特定の条件又は端末の性能に適合したＬＡＳｅＲコンテンツを送受信する方法及び装置を提供する。ここで使用する用語“端末”は、電話（携帯電話、無線電話、有線電話を含む）、ＰＤＡ、ラップトップ、ノート型パソコンなどを含む携帯型の通信装置及び有線・無線通信装置を含む。
【００２１】
特に、本発明の一実施形態は、ＬＡＳｅＲサービスを受信する端末の場面表現及び構成技術を提供し、適応型サービスの提供と関連して端末の特性と関連した特定の条件又は属性、特定のイベントの発生、及び端末の性能に従ってＬＡＳｅＲコンテンツを提供する方法及び装置をさらに提供する。
【００２２】
図１は、ＬＡＳｅＲコンテンツを受信する端末の動作を示す図である。
【００２３】
図１を参照すると、端末は、ステップ１００で、ＬＡＳｅＲサービスコンテンツを受信し、ステップ１１０で、該受信したＬＡＳｅＲコンテンツを復号化する。端末は、ステップ１２０で、ＬＡＳｅＲコンテンツからＬＡＳｅＲ命令語をチェックし、該ＬＡＳｅＲ命令語を実行する。その後に、端末は、ステップ１３０で、ＬＡＳｅＲコンテンツに基づくすべてのイベントを処理し、ステップ１４０で、この場面構成命令語を実行することにより場面をディスプレーする。
【００２４】
ここで、データストリームは、ＬＡＳｅＲサービスを提供するのに必要な基本的な要素に加えて複雑な場面構成要素を含んでもよく、高性能の端末（通信装置）に適合した場面構成要素又は基本場面に付加されるデータを含んでもよい。また、ここで説明したＬＡＳｅＲデータストリームは、各端末の特性に関する構成要素を含むデータストリームを含む。このような特性は、このデータストリームを受信する端末の特徴及び性能を含む。
【００２５】
図２は、本発明の実施形態によるＬＡＳｅＲコンテンツを受信する端末の動作を示す図である。より具体的に、図２は、ＬＡＳｅＲデータストリームが、使用可能なリソースが豊富な端末のための場面構成データを含むか又は端末の性能に適応可能な場面構成データを含む場合、すなわち、ＬＡＳｅＲデータストリームが‘適応場面構成要素（以下、“Adaptive_scene_component”と称する。）’を示す情報を含む場合に、場面を構成する端末の動作を示す。
【００２６】
図２を参照すると、端末は、ステップ２００で、ＬＡＳｅＲストリームを受信し、ステップ２１０で、該受信したＬＡＳｅＲストリームを復号化する。ステップ２２０で、端末は、該復号化したＬＡＳｅＲストリームがヘッダを含んでいるか否かを確認する。この際、ＬＡＳｅＲストリームがヘッダを含んでいる場合に、端末は、ステップ２３０で、ヘッダ情報をチェックする。ステップ２５０で、該検査したヘッダ情報で“Adaptive_scene_component”を示す情報、すなわち、“AdaptiveSceneIndicator”フィールドの値がＦＡＬＳＥである場合に、端末は、ステップ２８０で、該受信したデータストリームをその画面にディスプレーする。しかしながら、該検査した“AdaptiveSceneIndicator'フィールドの値がＴＲＵＥである場合に、端末は、ステップ２６０で、端末の性能をチェックする。
【００２７】
ステップ２６０で、その性能が“Adaptive_scene_component”をサービスするのに十分でない場合に、端末は、ステップ２６５で、該受信したＬＡＳｅＲストリームを廃棄するようにデータ廃棄（Data_Discard）に関する設定情報をオン（ＯＮ）に設定する。すなわち、復号化されるＬＡＳｅＲストリームを復号化なしに廃棄することにより、端末は、対応するデータストリームを画面上にディスプレーしないようにする。廃棄されるＬＡＳｅＲストリームがすでに復号化された場合でも、端末は、データをメモリから即座に削除することにより廃棄工程を実行できる。
【００２８】
しかしながら、ステップ２６０で、その性能が“Adaptive_scene_component”をサービスするのに十分である場合に、端末は、ステップ２９０で、ＬＡＳｅＲストリームを廃棄しないようにデータ廃棄に関する設定情報をオフ（ＯＦＦ）に設定する。その後に、ステップ２８０で、端末は、このデータストリームを画面上にディスプレーすることによりＬＡＳｅＲサービスを提供する。ステップ２８０の実際のディスプレー工程は、ここで詳細に説明しないけれども、廃棄されずサービスされるコンテンツのサービスを提供するための技術的なステップをさらに含んでもよい。
【００２９】
また、ステップ２２０で復号化されたＬＡＳｅＲストリームがヘッダを有していない場合に、端末は、ステップ２７０で、ＬＡＳｅＲストリームのデータ廃棄に関する設定情報をチェックする。該データ廃棄に関する設定情報がＯＮに設定される場合に、端末は、ステップ２７５で、端末のＬＡＳｅＲストリームをこれ以上処理せず、すなわち、これをメモリ内に構成するか又はレンダリングすることなく廃棄する。しかしながら、データ廃棄に関する設定情報がＯＦＦに設定される場合に、端末は、ステップ２８０で、ＬＡＳｅＲストリームを画面上にディスプレーする。
【００３０】
上述した実施形態において、端末が、ストリームを受信し（ステップ２００）、該受信したストリームを復号化し（ステップ２１０）、“AdaptiveSceneIndicator”フィールドの値を参照して（ステップ２５０）、該受信したストリームを画面上にディスプレーする（ステップ２８０）ステップと、“AdaptiveSceneIndicator”フィールドの値を参照することにより（ステップ２５０）“AdaptiveSceneIndicator”フィールドを有するデータを受信するまで、対応するストリームを処理しない一連の工程を除き、他のすべての工程は、端末のタイプ又は設計に従ってその順序が変更されてもよく又は省略されてもよい。
【００３１】
また、“AdaptiveSceneIndicator”又は本発明で新たに定義した他のフィールド及び属性を用いて本発明と同一のサービスを提供できる場合に、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。
【００３２】
ＬＡＳｅＲヘッダ内の該受信したＬＡＳｅＲストリームが“Adaptive_scene_component”であることを示す情報についてより詳細に説明する。
【００３３】
下記の説明において、例を挙げてＬＡＳｅＲが与えられ、“Adaptive_scene_component”を示すのに使用される新たなフィールド及び属性は、ヘッダタイプのデータだけでなく、命令、要素、フィールド、ユニット、及びペイロードなどを含むデータのフィールド及び属性としても使用できる。
【００３４】
“AdaptiveSceneIndicator”フィールドは、例えば、ブール代数で表現してもよく、１、２、３、及び４のような整数で表現してもよく、あるいは、‘基本（ｂａｓｉｃ）’及び‘増強（ｅｎｈａｎｃｅｄ）’のような象徴的なレベルの様々な方法で表現してもよい。しかしながら、“AdaptiveSceneIndicator”フィールドがブール代数でない値で表現される場合に、その属性の特定値は、“Adaptive_scene_component”を識別するように表現できなければならない。
【００３５】
例えば、“AdaptiveSceneIndicator”フィールドの属性値が整数値として表現される場合、０は、対応するデータが適応型サービスのためのデータであることを示す。すなわち、該受信したＬＡＳｅＲヘッダ内のフィールドの属性値が０である場合に、「AdaptiveSceneIndicator＝False」という意味を有するので、該受信したデータは、画面上にディスプレーしなければならない。
【００３６】
ここで説明するフィールド又は属性を含む適応型データは、string、Boolean、decimal、precisionDecimal、float、double、duration、dateTime、time、date、gYearMonth、gYear、gMonthDay、gDay、gMonth、hexBinary、base64Binary、anyURI、QName、NOTATION、normalizedString、token、language、NMTOKEN、NMTOKENS、Name、NCName、ID、IDREF、IDREFS、ENTITY、ENTITIES、integer、nonPositiveInteger、negativeInteger、long、int、short、byte、nonNegativeInteger、unsignedLong、unsignedInt、unsignedShort、unsignedByte、positiveInteger、yearMonthDuration、及びenumerationのような整数型、文字列型、小数型、固定小数型、不定小数型、リスト型などを含むリッチメディアコンテンツで使用可能な様々なデータタイプで表現してもよい。また、端末及びサービス内部・外部の情報を参照できる。これは、本発明のすべての実施形態に同様に適用可能である。
【００３７】
以下の表１は、端末の性能に適応可能なＬＡＳｅＲデータストリームの適応基準、すなわち、“AdaptationType”を示す。
【００３８】
“AdaptationType”として、データを処理するために端末に要求される解像度、画面サイズ、サービス場面での使用の頻度、データ処理性能のために消耗される端末リソースに関する占有率、メモリサイズ、電力消耗量、データ送信と関連して要求されるリソース情報、及びサービスの提供のために要求される入出力性能に関連した端末の性能及び構成などを含む特定の条件又は端末の状態や状況の変化に関連した様々な要素が使用できる。
【００３９】
例えば、端末の演算量と関連した情報及び端末のメモリ関連情報、例えば、グラフィックポイントの個数、フォントデータのサイズ又は個数、テキストの個数、ビデオ処理のために要求されるメモリ量、ビデオ・オーディオデータ処理のための端末処理能力などの様々な要素をさらに付加できる。
【００４０】
ここで、グラフィックポイントの個数は、グラフィック要素を生成するために必要なメモリ量などを示すための情報を表現する。該情報は、グラフィック要素を構成するドット、ライン、メッシュ、ポリゴン（polygon）などに関する情報を含んでもよい。各グラフィック要素の特性に関する必要な情報は、“AdaptationType”として使用できる。
【００４１】
フォントデータのサイズ又は個数は、対応するフォントを用いてデータを生成するためのメモリ量などに関する情報を示すための情報である。該情報は、フォントファイルのサイズ及びフォントファイルをローディングするための情報を含む、フォントファイルを用いてデータを生成するために必要なメモリ量をさらに含んでもよい。この情報は、“AdaptationType”として使用してもよい。
【００４２】
テキストの個数は、テキストデータを生成するために必要なメモリ量などを示すための情報を表現する。該情報は、テキストデータのサイズに関する情報を示してもよく、テキストデータを生成するために必要なメモリ量をさらに含んでもよい。また、該情報は、“AdaptionType”として使用してもよい。
【００４３】
ビデオ処理のために要求されるメモリ量又はビデオ処理のための端末の処理能力は、イメージ又はビデオのような映像データを生成するために必要とされるメモリ量を示すための情報を表現する。イメージ又はビデオのような映像データを生成するためにさらなるメモリ量が必要とされる場合に、さらなる属性は、対応する情報を示すための属性をさらに定義してもよく、各情報を含む値で表現してもよい。
【００４４】
例えば、イメージ乃至ビデオデータファイルを処理するにあたり、入力ビデオバッファ、復号化のためのパラメータ、及び出力ビデオバッファのためのメモリが要求される場合に、イメージファイルのサイズより大きい入力ビデオバッファのサイズ、及びカラーフォーマットに関する１ピクセルデータが表現される際に必要なバイトの個数に適合した出力ビデオバッファなどのためのメモリ及びイメージ又はビデオデータの復号化のためのパラメータのためのメモリが必要とされる。したがって、この適応基準は、入力ビデオバッファのサイズをチェックするために使用されるイメージファイルのサイズ、出力ビデオバッファのサイズをチェックするために使用されるイメージの横長さ及び縦長さ、カラーフォーマット情報、コーデック情報、及びイメージ又はビデオデータを復号化するためのパラメータのためのメモリ情報を含む。また、この情報は、“AdaptationType”として使用できる。
【００４５】
また、端末の適応基準として、コンテンツを構成する様々な要素、イメージ、フォント、ビデオ及びオーディオのようなメディアに関連した情報、入出力性能や装置、相互作用関連情報などを含む受信端末の性能及びサービス状況と関連する様々な要素が使用できる。また、メディア関連情報及びテキスト、グラフィック、及び相互作用関連情報は、各データのサイズ、再生時間、秒当たり処理されなければならないデータ量を示すフレーム率、カラーテーブル、及びアップデート比率などを含むデータ自体に関する情報を適応基準として使用してもよい。さらに、この適応基準は、外部で定義された情報に基づいて使用してもよい。
【表１】
0005512657.tif 000002
【００４６】
上記の表１は、本発明の実施形態による適応基準を示し、すなわち、各“AdaptationType”は、基準値を保有できる。
【００４７】
例えば、ディスプレーサイズが適応基準となると仮定すると、特定の場面データ又は場面セグメントが“DisplaySize”がＬＡＲＧＥとして分類される端末のための場面情報を含んでいる場合に、適応基準の値は、“AdaptationTypeValue”＝LARGEとして表現できる値である。
【００４８】
“AdaptationTypeValue”属性の値は、各適応基準に従って様々な方法で表現できる。すなわち、“AdaptationTypeVale”の記述方法が各“AdaptationType”に従って異なる場合に、各“AdaptationType”に関する各“AdaptationTypeValue”を定義して説明してもよい。
【００４９】
下記の表２Ａは、“adaptive_scene_component”を示す情報がスキーマのシンタックスを用いて説明される一例を示す。本発明の実施形態では、この属性及び要素を説明するためにスキーマを、例を挙げて使用する。
【００５０】
ここで使用する“スキーマ”は、データの構成をあらかじめ定義した一種のモデリング文書を示す。本発明の実施形態で使用したスキーマは、ＸＭＬスキーマ文法に従い、スキーマの要素を使用して定義できる。特に、属性及び要素の構成を定義する方法には、様々な方法があり得る。したがって、スキーマを使用する方法でなくても同一の意味を含んでいる場合には、本発明の範囲内に属していることをわかる。
【００５１】
また、本発明の実施形態において例を挙げて定義した要素及び属性の値は、属性値が１つの表現方法に限定されるように説明してもよく、又は既存のタイプを拡張することにより定義してもよい。
【表２Ａ】
0005512657.tif 000003
【００５２】
表２Ｂは、“AdaptationType”及び“AdaptationTypeValue”を１つのフィールドにともに表現する一例を示す。
【００５３】
“AdaptationType”及び“AdaptationTypeValue”を１つのフィールドにともに表現する場合に、例えば、<LASeRHeader.............AdaptationType_Value=“DisplaySize_LARGE”/>として表現できる。
【表２Ｂ】
0005512657.tif 000004
【００５４】
また、“Adaptive_scene_component”を示す情報は、“AdaptiveSceneIndicator”、“AdaptationType”、及び“AdaptationTypeValue”を使用して表３Ａ及び表３Ｂに示すように表現できる。
【表３Ａ】
0005512657.tif 000005
【００５５】
表３Ａは、ディスプレーサイズ（上述した表１を参照すると、‘０ｘ０１’は、AdaptationTypeの基準でディスプレーサイズ（ビューポートサイズ）を示す。）がＬＡＲＧＥとして分類される端末のためのデータを示す。
【００５６】
この際、ディスプレーサイズが‘ＬＡＲＧＥ’として分類されない端末は、表３ＡのＬＡＳｅＲヘッダをそのヘッダとして有するデータを受信する場合に、受信したデータの復号化又はレンダリングを行うことなくフィルタリングできる。
【００５７】
例えば、表３Ａにおいて、ディスプレーサイズがＳＭＡＬＬ及びＬＡＲＧＥのようなシンボリック値として設定されても、“AdaptationTypeValue”は、インチ（表９を参照）で物理的に与えられるサイズを含むディスプレーサイズ、相対的表記方法、及び画面の解像度を表現する任意の値として設定できる。
【表３Ｂ】
0005512657.tif 000006
【００５８】
表３Ｂは、上述した表３Ａと同一の意味を有し、同一の動作を実行する情報を異なる方法で示す。“AdaptationType”フィールドの属性値として使用できる値、例えば、DisplaySize、CPU_status、Memory_status、及びBattery_Sizeを“AdaptationType”に代える新たな属性フィールドとして定義し、“AdaptationTypeValue”の値を対応する属性フィールドの値として定義する。
【００５９】
本発明の一実施形態に従って、“AdaptiveSceneIndicator”、“AdaptationType”、及び“AdaptationTypeValue”は、それぞれ独立的に又は複合的に使用できる。
【００６０】
“AdaptiveSceneIndicator”の場合に、対応するフィールドを使用しなくても、本発明で説明する“Adaptive_scene_component”を示す情報を示すフィールドが使用される場合に、これは、“AdaptiveSceneIndicator”=Trueであることを意味する。
【００６１】
１つの場面データ又は場面セグメントが１つの適応基準をかならず有するのではないため、様々な適応基準を使用できる。例えば、端末の場面サイズ及び端末のメモリサイズのような様々な要素が対応する場面の適応基準として使用される場合に、フィルタリングされるデータは、様々な適応基準を保有できる。また、これらの適応基準を示す他の情報に基づいてデータを表示する方法も本発明の例と同一の意味を示すと考えられる。
【００６２】
新規属性が意味する適応基準を提示し参照できる新規要素及び属性を定義し、これを参照する方法を提示することもできる。例えば、ＬＡＳｅＲヘッダの内部又は特定の位置に基づいて適応基準を説明する適応基準リストを提供し、これを参照できる方法が提示される。該適応基準リストの参照は、新規属性の定義及びフィルタリングのための方法として使用できる。
【００６３】
表４は、適応基準のリストを提供するＬＡＳｅＲヘッダの一例を示す。上述したように、リスト内の少なくとも１つ以上の適応基準を参照できる。これらの属性及びフィールドの表現において変形又は修正があるとしても、これらが適応型データ表現のためのフィルタリングを実行するために使用される場合に、これは、本発明の範囲内に属することは自明なものと言える。
【表４】
0005512657.tif 000007
【００６４】
本発明の他の実施形態は、ＬＡＳｅＲ命令語の単位で適応基準が異なる場合、すなわち、命令語の単位で“Adaptive_scene_component”情報に基づいてフィルタリングを実行する方法を提供する。
【００６５】
下記の表５を参照すると、NewScene及びInsertのようなＬＡＳｅＲ命令語は、場面構成のために使用される。下記の表５は、４個の場面命令語を含むコンテンツを示す。
【表５】
0005512657.tif 000008
【００６６】
下記の表６Ａ及び表６Ｂは、命令語単位でフィルタリングするために“adaptive_scene_component”情報をＬＡＳｅＲ命令語の新たな属性として定義し、これを表現する方法を示す。
【表６Ａ】
0005512657.tif 000009
【００６７】
表６Ａを参照すると、“Dictionary”をＩＤ属性値として有する要素に新たな場面構成要素“polyline”を挿入するための“Insert”命令語の場面は、ディスプレーサイズが“MEDIUM”として分類される端末のためのデータを示す。
【００６８】
また、“Shape4”をＩＤ属性値として有する要素に新たな属性“points”を挿入するための“Insert”命令語の場面は、ディスプレーサイズが“LARGE”として分類される端末のためのデータを示す。
【００６９】
表６Ａに示すようなデータを受信した端末は、適応基準及びこれに対する値と関連した端末自身の特性及び条件に従って、特定の命令語を実行するか、次の場面を受信するまでのデータを復号化するか、場面を構成するか、又はレンダリングすることなく対応するデータを廃棄するフィルタリング工程を実行できる。
【００７０】
下記の表６Ｂは、ＬＡＳｅＲ命令語に新たなフィールドを付加し、命令語単位で適応情報に従ってフィルタリング又はスイッチングを実行するための方法の一例を示す。命令語単位のフィルタリング又はスイッチングのための新たなフィールドは、１つ又はそれ以上の命令語のグループとして使用してもよい。
【表６Ｂ】
0005512657.tif 000010
【００７１】
上述した例におけるように、端末の性能に適応可能なＬＡＳｅＲデータストリームの適応基準及びこれらに関連した値を示すためのフィールド及び属性は、適応関連データを提供するデータの単位、すなわち、フィルタリングの対象及び範囲に従ってその位置及び表現を変更できる。
【００７２】
例えば、適応情報がファイル単位で提供される場合に、ファイルヘッダに位置できる。適応情報が場面命令語単位で提供される場合に、ＬＡＳｅＲ命令語の属性で表現でき、新たなグループノード又はパレンタルノード及びこれらのヘッダとして機能できるフィールドを付加することにより表現することもでき、又は、場面構成要素内の新たな要素又は場面構成要素のための属性を表現することもできる。
【００７３】
したがって、ＬＡＳｅＲデータストリームの適応基準及びこれらに関連した値を示すためのフィールド及び属性を受信した端末は、自身が処理できないデータを受信した場合に、端末は、対応するフィールド及び属性に関連したデータを復号化せず廃棄するか、又はもしあればすでに復号化されたデータをレンダリングせずメモリから削除するなどの廃棄工程を含むフィルタリングを実行する。
【００７４】
次いで、本発明の他の実施形態として、フィルタリングの基準として定義された場面表現のためのデータの集合でフィルタリング又はスイッチング方法について説明する。場面表現のためのデータの集合は、場面セグメント又はアクセスユニット（Access_Unit、以下、“ＡＵ”と称する。）で表現してもよい。以下の説明において、場面表現のためのデータの集合又はこれらのヘッダが適応情報を有すると仮定して説明する。
【００７５】
まず、所定の時間の間の場面を表現するためのデータの集合が複数のストリームに分割された後に送信される場合、すなわち、同一の時間の間の場面を表現するためのデータの集合が複数のストリームに分割された後に送信される場合に、端末は、自身の性能及び状況に合うストリームだけを選択し、これらを場面を構成するデータとして使用する方法について説明する。
【００７６】
端末は、データを受信し、該受信したデータ内のヘッダ情報をチェックし、該ヘッダ情報から適応情報を確認し、これに従う端末の状態をチェックし、自身の性能及び状況に適合したデータの集合を含むストリームだけをフィルタリングすることによりサービスを提供できる。上述したように、サービスを提供する工程で実行されなければならない復号化工程又は場面構成工程なしにデータの廃棄のようなフィルタリング動作を実行できる。
【００７７】
所定の時間の間の場面を表現するためのデータの集合が順次的なデータで構成され、１つのストリームで伝達される場合に、他の方法は、ヘッダ情報をチェックすることにより適応情報を確認し、これに従う端末の状態をチェックし、自身の性能及び状況に適合したデータの集合だけをフィルタリングすることによりサービスを提供できる。このデータ集合が順次的なデータで構成される場合に、所定の時間の間の場面を示すための情報の場面構成時間情報は、同一の値を保有でき、この情報は、フィルタリング及びスイッチングのために使用することもできる。上述した方法に加えて、本発明で説明した適応関連情報を用いてフィルタリングのための基準として場面を表現するためのデータの集合を定義することによりフィルタリングを実行することもできる。
【表７】
0005512657.tif 000011
【００７８】
表７の“SceneUnit”は、１つのアクセスユニットに含まれるNewScene及びRefreshのような命令語を含有でき、“SceneUnit”は、本発明で定義した適応情報を属性として保有できる。他の使用法として、適応のための新たな命令語（例えば、Add,Delete...）は、他の命令語と同一のレベルでSceneUnitに定義できる。この新たな命令語は、１つの命令語であり、同一の適応基準を有する場面を含む。例えば、次のように使用できる。
【表８】
0005512657.tif 000012
【００７９】
表８において、‘adaptationConstraint’属性は、‘AdaptationType’及び‘AdaptationTypeValue'情報を含むか又は情報を参照する。‘AdaptationType’及び‘AdaptationTypeValue’は、リストタイプで様々な適応基準を提供できる。この際、端末は、データを受信し、対応する命令語グループの‘AdaptiveSceneIndicator’、‘AdaptationType’、及び‘AdaptationTypeValue'情報をチェックし、これに従う端末の状態をチェックし、自身の性能及び状況に適合したデータだけをフィルタリングすることにより、サービスを提供できる。
【００８０】
上述したように、サービスを提供する工程で実行しなければならない復号化工程又は場面構成工程を行わず、データの廃棄のようなフィルタリング及びスイッチング動作を実行できる。
【００８１】
上述した方法に加えて、本発明で定義した適応情報を用いて単位時間内に表現されなければならないデータを示す最小単位であるＡＵに基づくフィルタリングを実行することもできる。
【００８２】
図３は、本発明の実施形態による複数の論理的なストリームを１つの物理的なストリームに多重化することによりサービスされるＬＡＳｅＲストリームを受信する端末の動作を示す図である。
【００８３】
図３を参照すると、端末は、ステップ３００で、ＬＡＳｅＲストリームを受信し、ステップ３１０で、該受信したストリーム内の各ＡＵのヘッダをチェックする。ステップ３２０で、端末は、場面の構成に使用されるデータを復号化し、ステップ３３０で、該データを場面構成時間でディスプレーする。
【００８４】
図４は、本発明の実施形態による複数の論理的なストリームを１つの物理的なストリームに多重化することによりサービスされるＬＡＳｅＲストリームを受信する端末の動作を示す図である。ここで、ＬＡＳｅＲデータストリームは、各受信端末の特性と関連した構成要素を含むデータストリームを含有できる。複数の論理的なストリームを１つの物理的なストリームに多重化することによりサービスされるＬＡＳｅＲストリームの場合に、ヘッダ情報を含むＡＵ及び実際の場面を構成するデータを含むＡＵは、個別に構成される。
【００８５】
図４を参照すると、ステップ４００で、端末は、ＬＡＳｅＲストリームを受信し、ステップ４１０で、受信したＬＡＳｅＲストリーム内のＡＵヘッダをチェックする。ステップ４２５で、端末は、受信したＡＵがヘッダ情報を含むか否かを確認する。該受信したＡＵがヘッダ情報を含む場合に、端末は、ステップ４３０で、ＡＵの設定情報をチェックする。この設定情報は、ＬＡＳｅＲストリームのヘッダ情報を含む。
【００８６】
端末は、ステップ４４５で、“AdaptiveSceneIndicator”フィールドの値を確認する。“AdaptiveSceneIndicator”フィールドの値がＦＡＬＳＥである場合には、端末は、ステップ４４０で、ＬＡＳｅＲストリームを廃棄しないようにデータ廃棄に関する設定情報をＯＦＦに設定し、その後で、端末が受信したヘッダ情報の実際のデータ、すなわち、実際の場面の構成に使用されるデータ、を含むＡＵを復号化する。
【００８７】
“AdaptiveSceneIndicator”フィールドの値がＴＲＵＥである場合に、端末は、ステップ４５０で端末の性能をチェックする。端末の性能が“adaptive_scene_component”をサービスするのに十分でない場合に、端末は、ステップ４６０で、実際の場面を構成するために使用されるデータを含む受信したＡＵを追加で処理せず、すなわち、データを復号化し、メモリで場面を構成するか又はレンダリングすることなく、端末が後で受信したヘッダ情報の実際のデータを廃棄するようにデータ廃棄に関する設定情報をオンに設定する。しかしながら、端末の性能が“adaptive_scene_component”をサービスするのに十分である場合に、端末は、ステップ４４０で、ＬＡＳｅＲストリームを廃棄しない。
【００８８】
しかしながら、ステップ４２５で、この受信したＡＵがヘッダ情報を含んでいない場合に、端末は、ヘッダ情報を含む新たなＡＵが後で受信されるまで、ステップ４６５で、図４で説明したヘッダ情報を含むＡＵに関する実際の場面を構成するのに使用されるデータを含むＡＵを廃棄するか否かを確認する。
【００８９】
ステップ４６５で、端末がこの受信したＡＵを廃棄しないことを決定する場合に、端末は、設定情報をチェックする。該設定情報に基づいて、端末は、ステップ４８０で、該受信したデータを復号化し、ステップ４９０で復号化したデータを画面にディスプレーする。しかしながら、端末は、ステップ４６５で、この受信したデータを廃棄することを決定する場合に、ステップ４７０で、データを復号化し、メモリに構成するか又はレンダリングすることなく受信したＬＡＳｅＲストリームを廃棄する。
【００９０】
上述した実施形態において、端末のストリームを受信し（ステップ４００）、ＡＵのヘッダをチェックし（ステップ４１０）、設定情報をチェックし（ステップ４３０）、“AdaptiveSceneIndicator”フィールドの値に基づいて（ステップ４４５）端末が後で受信するヘッダ情報を含むＡＵに関する実際の場面を構成するのに使用されるデータを含むＡＵを復号化し（ステップ４８０）、該復号化したデータを画面にディスプレーするか（ステップ４９０）、又は復号化工程及びその後のすべての工程を行わずデータを廃棄する工程を除いて、任意の追加の工程は、この特定の端末のタイプ及び設計に従ってその順序が変わることもあり、又は省略されることもある。
【００９１】
また、“AdaptiveSceneIndicator”フィールド及び本発明で新たに定義するフィールド及び属性を用いて本発明と同一のサービスを提供できる場合に、ここで説明した実施形態の様々な変更及び変形が本発明の範囲及び趣旨を逸脱することなく可能であるということは、当該技術分野における通常の知識を有する者には明らかである。
【００９２】
第２の実施形態で説明したように、ＬＡＳｅＲデータが複数の論理的なストリームを１つの物理的なストリームに多重化することにより提供される場合に、ＬＡＳｅＲヘッダは、ヘッダタイプのデータを送信するために提供されるＳＡＦのＡＵに送信できる。この際、“AdaptiveSceneIndicator”フィールド、本発明で新たに定義したフィールド及び属性を表９に示すように表現でき、saf:sceneHeaderに付加することもできる。
【表９】
0005512657.tif 000013
【００９３】
以下の表１０は、本発明の他の１つの実施形態として、ＳＡＦのパケットヘッダ内のpresenceOfDTSフィールドは、現在０にあらかじめ設定されていて使用されないので、presenceOfDTSフィールドの１ビットをここで説明するAdaptiveSceneFlagに対して割り当てる方法を示す。本実施形態において、表１０の“AdaptiveSceneFlag”=Trueを有するＳＡＦパケットを受信した端末は、ＡＵをチェックする前にパケットヘッダをチェックすることにより、データストリームが各端末の特性に関連した構成要素を含む適応型データサービスのためのデータを含むことを認識できる。
【表１０】
0005512657.tif 000014
【００９４】
本発明のもう１つの実施形態として、“SAF_AdaptiveScene_Unit”は、端末の特性に適応可能なＬＡＳｅＲデータストリーム内の適応基準及びこれらの値を示すためのＳＡＦの新たなＡＵタイプとして定義される。“SAF_AdaptiveScene_Unit”は、後で受信されるＳＡＦ＿ＡＵの適応基準及びこれらの値を提示できる。
【００９５】
下記の表１１は、“SAF_AdaptiveScene_Unit”を新たなＳＡＦタイプで明示する。“Stop_AdaptiveScene_Unit”は、前に受信した“SAF_AdaptiveScene_Unit”の適応基準及びこれらの値と関連したデータを含むＳＡＦ＿ＡＵがこれ以上受信されないことを示す。
【表１１】
0005512657.tif 000015
【００９６】
“SAF_AdaptiveScene_Unit”は、上述した適応情報を各フィールドとして含有できる。この際、“AdaptiveSceneIndicatorFlag”を付加でき、これは、対応するフィールドで表現でき、且つ後で受信されるＳＡＦ＿ＡＵデータストリームが“Adaptive_scene_component”であることを示す。
【００９７】
“AdaptiveSceneIndicatorFlag”は、“SAF_AdaptiveScene_Unit”の存在自体が、対応するフィールドの値が“SAF_AdaptiveScene_Unit”=Trueであることを示す場合に使用しないことがある。“AdaptationType”フィールドは、データストリームの適応基準を示す。“AdaptationType”の属性値は、属性値のタイプに従って様々な方法で表現でき、これに従って割り当てられたビットの個数は、表現の方式に従って変わり得る。
【００９８】
また、“AdaptationType”を表現する様々な方法の中で参照することにより“AdaptationType”を表現する方法が使用される場合、“url”タイプのための新たなフィールド及び“urlLengh”などが新たに付加できる。
【００９９】
“AdaptationTypeValue”は、データストリームの適応基準値を示すフィールドである。データストリームに適用可能な適応基準が２つ以上である場合、“numOfAdaptationType”フィールドなどが付加できる。“AdaptationType”のためのデータノードの長さ情報を提供するフィールドは、情報表現方法に従って付加できる。
【０１００】
本発明のもう１つの実施形態として、端末の特性に適応可能なデータストリームを含有できる“SAF_AU”、“AdaptiveSceneAU”、“AdaptiveSceneCacheUnit”、“AdaptiveSceneFFU”、及び“AdaptiveSceneFU”は、新たなＳＡＦ＿ＡＵタイプで定義する。
【０１０１】
“AdaptiveSceneAU”は、端末の特性に適応可能なデータストリームを含有できるＡＵのタイプを示し、“AdaptiveSceneCacheUnit”は、端末の特性に適応可能なキャッシュデータを含有できるＡＵのタイプを示す。端末の特性に適応可能なデータストリームのサイズがＡＵのサイズより大きい場合、データを分割した後に提供できる。この際、この分割されたデータの１番目のＡＵは、“AdaptiveSceneFFU”に含有でき、残りのデータセグメントは、“AdaptiveSceneFU”に含有できる。
【０１０２】
下記の表１２は、“SAF_AdaptiveScene_Unit”を新たなＳＡＦタイプで明示する。
【表１２】
0005512657.tif 000016
【０１０３】
“AdaptiveSceneAU”だけではなく“AdaptiveSceneCacheUnit”、“AdaptiveSceneFFU”、“AdaptiveSceneFU”でも自身が含んでいるデータの適応基準及びこれらの値を示す方法は、上述した方法と同様である。
【０１０４】
また、新たなＳＡＦのユニットタイプを定義しなくても、ヘッダユニットタイプ（0x01，0x02，0x07）及びＳＡＦのＡＵユニットタイプ（0x04，0x06）を含む既存のＳＡＦの各ユニットにAdaptiveSceneIndicator、AdaptiveType、AdaptiveValueのような適応基準を示すフィールドを付加できる。さらに、適応基準の各フィールドを定義するにあたり割り当てられるデータのサイズに関する情報は、情報のデータタイプに従って異なって割り当てるか又は表現してもよい。
【０１０５】
図５は、本発明の実施形態によるＬＡＳｅＲコンテンツをサービスする一例を示す図である。
【０１０６】
図５を参照すると、ＡＵ５００は、ヘッダを含む。ＡＵ５００及び５３０は、本発明の実施形態に従って、ヘッダタイプだけでなく、“SAF_AdaptiveScene_Unit”も含むデータストリームの適応基準及びこれらの値を示すためのフィールド及びＡＵであることができる。ヘッダ５１０で“AdaptiveSceneIndicator”が“ＴＲＵＥ”に設定される場合、端末は、自身の現在の状態をチェックする。ここで、端末は、使用可能なリソースをチェックするか、又はＣＰＵ処理能力、メモリ状態、及びバッテリー状態のような条件及びイベント状況を考慮する。端末の現在の状態が適応場面構成を処理するのに十分である場合に、端末は、後で受信するデータ５２０を復号化しディスプレーする。
【０１０７】
本発明の実施形態に従って、一連の（ａ＿ｒａｎｇｅ＿ｏｆ）データ５２０は、端末がデータを受信するまで又は適応基準に対するフィールド及び次の適応データの値を有するヘッダを受信するまで使用できる。このデータと関連した適応基準及びこれらの値がこれ以上有効でないことをシグナリングする“stop_AdaptiveScene_Unit”を受信した場合、データ５２０が完全に受信されたことを示すこともできる。
【０１０８】
この後、ヘッダ５３０を含むＡＵを受信した端末は、ヘッダ５４０をチェックすることにより“AdaptiveSceneIndicator”がＴＲＵＥであるか否かを確認する。端末は、適応場面構成を処理するのに十分でない場合に、後で受信する場面構成の実際のデータを含んでいるＡＵ５５０のすべてを復号化せず廃棄する。
【０１０９】
本発明の実施形態に従って、すでに復号化工程がなされたデータであっても、端末は、本発明で説明する適応基準及びこれらの値に対応するフィルタリングメカニズムに従ってメモリからのデータの削除を含むデータ廃棄を実行する。
【０１１０】
本発明の実施形態で提供される方法に従ってＬＡＳｅＲコンテンツをサービスしている間、端末の性能が変化する場合にも、特定の条件又は端末の性能を考慮して場面をより柔軟に構成できる。本発明の実施形態で定義した要素や属性が同一の意味を有する場合、この要素及び属性又は属性値の異なる名称又はタイプを使用できる。また、本発明の実施形態で説明したフィールド又は属性は、独立的に又は複合的に使用してもよい。
【０１１１】
図６は、本発明の実施形態による送信器の構成を示すブロック図である。
【０１１２】
図６を参照すると、生成部６００は、本発明の実施形態で上述した特定の条件又は端末の特性及び性能を示すか又は識別できる場面構成要素及び属性を含む場面構成要素を生成できる。場面構成要素の作成にあたり、生成部６００は、イベントの使用又はイベントの発生に対応する動作の詳細な場面コンテンツを生成することもできる。生成部６００は、該生成したＬＡＳｅＲコンテンツを符号化部６１０に伝達する。符号化部６１０は、ＬＡＳｅＲコンテンツを符号化し、該符号化したＬＡＳｅＲコンテンツを多重化部（ＭＵＸ）６２０に伝達する。多重化部６２０は、該符号化したＬＡＳｅＲコンテンツを複数の論理的なストリームとともに１つの物理的なストリームに多重化する。送信部６３０は、該多重化されたストリームを受信器に送信する。
【０１１３】
この符号化されたＬＡＳｅＲコンテンツは、多重化工程を行わず送信できる。これは、本発明の上述した実施形態の中のいずれか１つのように省略できる。
【０１１４】
図７は、本発明の実施形態による受信器の構成を示すブロック図である。
【０１１５】
図７を参照すると、逆多重化部（ＤＥ−ＭＵＸ）７００は、受信されたストリームを論理ストリームに区分するか又は逆多重化する。ここで、多重化を実行しないストリームの場合、逆多重化工程は省略できる。
【０１１６】
復号化部７１０は、該逆多重化されたストリームを復号化し、該復号化したストリームをレンダラ７２０に伝達する。特に、本発明に従って、復号化部７１０は、該受信したストリームを復号化することにより該ストリームのヘッダをチェックする。
【０１１７】
レンダラ７２０は、この復号化されたデータを受信し、本発明の実施形態による特定の条件又は端末の特徴及び性能を示すか又は識別できる場面構成要素及び属性を含む場面構成要素に基づいて対応する場面をレンダリングする。すなわち、レンダラ７２０は、復号化部７１０によりチェックされたヘッダの適応情報に従ってこの受信したストリームの場面構成要素を用いて場面を適応的に構成するか否かを決定する。ディスプレー７３０は、端末の画面で各場面をディスプレーする。
【０１１８】
本発明で新たに定義した要素及び属性の位置に基づいて情報を定義する方法は、変わり得る。各データ定義フォーマットに従って、この新たに定義した要素及び属性情報は、ヘッダ情報で構成してもよい。該ヘッダ情報は、初期場面構成のための情報、場面更新、場面更新データグループ、場面セグメント、及びアクセスユニットのためのシグナリング情報を含む。シグナリングのための場面構成のための実際の場面情報とは個別のアクセスユニット又はヘッダ情報で構成してもよい。シグナリングのためのデータフォーマットで形成される場合に、この新たに定義した要素及び属性情報をこの情報を示すためのフィールドで構成することもできる。
【０１１９】
本発明で新たに定義した属性値として使用される情報は、ＬＡＳｅＲコンテンツの内部・外部の他のデータ、ファイル、アプリケーション、サービスなどを参照して使用してもよい。この際、属性をＬＡＳｅＲコンテンツに定義することにより属性値だけを参照し、他のデータ、ファイル、プログラム、サービスなどとして定義された属性も参照機能を有する要素及び属性を用いて参照できる。参照機能を有する要素及び属性を用いて属性及び属性値を参照する場合にも、本発明で説明する属性の機能と同一の目的のために使用される場合に、これは、本発明の範囲内に属するということは自明である。
【０１２０】
本発明の実施形態は、コンピュータ読み取り可能な記録媒体上でコンピュータ読み取り可能なコードとして実現できる。コンピュータ読み取り可能な記録媒体は、コンピュータシステムにより読み出しできるデータを記憶できる任意のデータ記憶装置である。コンピュータ読み取り可能な記録媒体の例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光学データ記憶装置、及び搬送波（有線又は無線送信経路上のインターネットを介したデータ送信のような）が含まれるが、これらに限定されるものではない。また、このコンピュータ読み取り可能な記録媒体は、コンピュータ読み取り可能なコードが配布される方式で記憶されて実行されるように、ネットワーク結合型コンピュータシステムを介して配布できる。更に、本発明を達成するための関数プログラム、コード及びコードセグメントは、本発明が属する技術分野で熟練したプログラマーにより本発明の範囲内で容易に解析できるであろう。
【０１２１】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【０１２２】
５００、５３０    ＡＵ（アクセスユニット）
５１０、５４０    ヘッダ
５２０、５５０    一連のデータ
６００    生成部
６１０    符号化部
６２０    ＭＵＸ
６３０    送信部
７００    逆多重化部（ＤＥ−ＭＵＸ）
７１０    復号化部
７２０    レンダラ
７３０    ディスプレー
【図１】
0005512657.tif 000017
【図２】
0005512657.tif 000018
【図３】
0005512657.tif 000019
【図４】
0005512657.tif 000020
【図５】
0005512657.tif 000021
【図６】
0005512657.tif 000022
【図７】
0005512657.tif 000023