JP2018520546A - オーディオビデオ・コンテンツをレンダリングする方法、この方法を実施するためのデコーダ、及びこのオーディオビデオ・コンテンツをレンダリングするためのレンダリング装置 - Google Patents

Abstract

デコーダ（２０）は、圧縮形態のオーディオビデオ・コンテンツ（１）を受信するための入力インタフェース（２１）と、圧縮オーディオビデオ・コンテンツ（１）、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム（４）、及び制御データ（７）を出力するための出力インターフェース（２２）とを備える。制御データ（７）は、識別データ（３）及び実施データ（５）を備え、識別データ（３）は、オーディオビデオ・コンテンツ（１）の少なくとも一部及び／又は少なくとも一つのアプリケーションフレーム（４）の一部を識別するために使われ、かつ実施データ（５）は、オーディオビデオ・コンテンツ（１）及び少なくとも一つのアプリケーションフレーム（４）の少なくとも一つのレンダリングを定めることを特徴とする。【選択図】図１

Description

一般にセットトップボックスと呼ばれている、デコーダは、圧縮オーディオビデオ・コンテンツを受信する顧客端末である。コンテンツは、レンダリング装置に理解できる形で送られる前にデコーダによって伝統的に圧縮解除される。必要であれば、コンテンツは、圧縮解除される前にデコーダにより解読される。レンダリング装置は、ビデオ表示画面及び／又はオーディオスピーカーであり得る。本説明において、高解像度ビデオ画像をレンダリングすることができるテレビは、レンダリング装置の非限定的な実施例とみなされる。

デコーダの機能が、それをテレビに配信する前に放送装置（又はその他のソース）から受信したコンテンツを処理することであるので、デコーダはテレビの上流に置かれる。デコーダは、有線ケーブルを通じて通常は高解像度マルチメディアインタフェース（ＨＤＭＩ（登録商標））を通じてテレビに接続できる。この種のインタフェースは、非圧縮オーディオビデオ・ストリームをオーディオビデオ・ソースから対応受像機の方へ送信するために最初に設計された。

フルハイビジョン映像フォーマット形式を有する高解像度テレビは、それぞれ１９２０ピクセルの１０８０本の線を含む画像を表示することが可能である。この画像は、１６：９のアスペクト比の１９２０×１０８０ピクセルに等しい解像度を有する。フルハイビジョンフォーマットの各画像は、２メガピクセルからなる。今日では、超高解像度（ＵＨＤ ４Ｋ、ＵＨＤ−１とも呼ばれている）フォーマットの出現によって、対応するテレビは、1画像につき８百万ピクセルを提供することが可能であり、そしてＵＨＤ ８Ｋ（ＵＨＤ−２）は、更に改良されたカラーレンダリングを備えた３千３百万ピクセル以上を有する画像を提供する。テレビの解像度を上昇させることは、より微細な画像を提供して、主に表示画面のサイズの増大を可能にする。更に、テレビ画面のサイズを増大させることは、視野を広げることによって、そして没入効果が実現されるのを可能にすることによって視聴経験を改善する。

また、高い画像リフレッシュ速度を提供することによって、画像の鮮明度を改善することが可能になる。これは、特に、スポーツシーン又は移動シーケンスに有効である。新規なデジタルカメラのおかげで、映画製作者及びディレクターは、より高いフレーム率で映画を撮影するように促される。ＨＦＲ（高いフレーム率）技術を用いて、映画産業において一般的に用いられる２４ｆｐｓの代わりに、４８ｆｐｓ（毎秒当たりのフレーム数）、６０ｆｐｓ、又は１２０ｆｐｓのフレーム率さえ達成できる。しかしながら、これらの映画の著作物のデリバリーチェーンをエンドユーザの自宅まで延長したい場合、これらのより高いフレーム率で受信されるオーディオ／ビデオをレンダリングするのに適しているテレビを製作することも必要である。更に、ジター及びストロボ効果を回避するために、及び／又は迅速な動きがあるシーンの間に画像の鮮明度の不足を緩和するために、ＵＨＤビデオストリーム（ＵＨＤ ８Ｋ）の次世代は、１２０ｆｐｓで提供される。

米国特許出願公開第２０１１／０１０３４７２号明細書 米国特許出願公開第２００９／０３１７０５９号明細書 米国特許出願公開第２０１１／３２１１０２号明細書 米国特許出願公開第２０１４／３６９６６２号明細書

しかしながら、オーディオビデオ・ストリームを送信するためにデコーダにおいて、そしてテレビにおいて実施される、インタフェース、例えばＨＤＭＩ（登録商標）は、この種の高いビットレートでこの種の大量のデータを送信するために設計されなかった。ＨＤＭＩ（登録商標）標準の最後のバージョン（ＨＤＭＩ（登録商標）２．０）は、最高１８ＧＢ／ｓをサポートする。従って、ＨＤＭＩ（登録商標）２．０は、６０ｆｐｓで提供されるＵＨＤ ４Ｋのオーディオビデオ・ストリームの伝送をほぼ可能にする。これは、ＨＤＭＩ（登録商標）インタフェースが同じ高いビットレート、例えば６０ｆｐｓ以上のＵＨＤ ８Ｋのビデオでより高い解像度を有する画像の伝送を確実にするには不十分になることを意味する。

近い将来、デコーダとレンダリング装置間のデータ・ビット・レートは、特に、画像のビット深度を８ビットから１０又は１２ビットまで増加させることによって、更に増大する。実際、画像の色深度を増加させることによって、色諧調を滑らかにすること、従ってバンディング現象を回避することが可能になる。現在、ＨＤＭＩ（登録商標）２．０インタフェースは、１０又は１２ビットの色深度を有する６０ｆｐｓでＵＨＤビデオを伝送することができない。

次世代のテレビの８ビットの色深度の中断は、ハイ・ダイナミック・レンジ（ＨＤＲ）と呼ばれている新特徴の開発の一因ともなる。この特徴は、少なくとも１０ビットの色深度を必要とする。ＨＤＲ標準は、非常に明るい画像を表示するために画像のコントラスト比を増幅することを目的にする。ＨＤＲ技術の目的は、画像が部屋を暗くすることがもはや必要でないほどに明るいことを可能にすることである。しかしながら、現在のインタフェース、例えばＨＤＭＩ（登録商標）は、ＨＤＲ標準に対応するのに十分な順応性がない。これは、ＨＤＭＩ（登録商標）が新規なＨＤＲ技術に簡単に対応しないことを意味する。

コンテンツプロバイダの各々が、視聴経験を強化するためにこの装置を通じて魅力的な特定機能を提供できるので、デコーダは、コンテンツプロバイダにとって重要な装置であるとも考えられる。実際、それがレンダリング装置に関して放送チェーンの中で上流に置かれるので、デコーダは、コンテンツプロバイダから受信した入力オーディオビデオ・コンテンツを圧縮解除した後に詳しい情報をコンテンツに加えることが可能である。或いは、デコーダは、表示画面上のオーディオビデオ・コンテンツの提示を変更できる。一般的に言って、デコーダは、多数のアプリケーションをエンドユーザに提供するように詳しい情報を加え、及び／又はオーディオビデオ・コンテンツのプレゼンテーションを変更できる。

これらのアプリケーションの中で、プロバイダは、例えば、ＥＰＧ（電子番組ガイド）、ＶｏＤ（ビデオ・オン・デマンド）プラットフォーム、ＰｉＰ（ピクチャー・イン・ピクチャー）表示機能、直観的ナビゲーションツール、効率的な検索及びプログラムツール、インターネットページへのアクセス、ヘルプ機能、ペアレンタルコントロール機能、インスタントメッセージング及びファイル共有、個人音楽／写真ライブラリへのアクセス、ビデオ呼び出し、注文サービスなどを提供できる。これらのアプリケーションは、コンピュータによるサービスであると考えることができる。従って、それらは、「アプリケーションサービス」とも呼ばれる。広範囲にわたる効果的な、実際的な、かつ強力なアプリケーションサービスを提供することによって、人は、セットトップボックスにこの種の機能を提供することに対する本当の関心を直ちに理解できる。この関心は、エンドユーザ及びプロバイダの両方にとって有益である。

従って、デコーダ又はマルチメディアシステムが少なくともレンダリング装置に接続しているデコーダを備えることを含む、ＵＨＤ装置の次世代に組み込まれる新技術により提供されるすべての機能を利用するために関心がある。

特許文献１は、伝送チャネルを通じた伝送のためにＨＤビデオ・コンテンツを含むメディアストリームを作成する方法を開示している。より詳しくは、この文書の方法は、そこに含まれるＨＤビデオ・コンテンツを圧縮しないＨＤ符号化フォーマットのメディアストリームを受信し、メディアストリームを復号化し、復号化メディアストリームを圧縮し、非圧縮ビデオ・コンテンツ・フォーマットの中に圧縮メディアストリームをカプセル化し、そしてＨＤＭＩ（登録商標）ケーブル又は無線リンクを通じて伝送できるデータストリームを生成するように、ＨＤフォーマットを使用してカプセル化されたメディアストリームを符号化することを提案する。ある場合には、メディアストリームを暗号化することもできる。

特許文献２は、付加的なＶＢＩ（垂直帰線消去区間）データを含む、補助情報を伝送するためにＨＭＤＩ（登録商標）標準を使用する解決策を開示している。このために、この文書は、変換されたマルチメディア及び補助データセットをＨＤＭＩ（登録商標）送信機に連結するＨＤＭＩ（登録商標）ケーブルを通してＨＤＭＩ（登録商標）受信機に送信するように、入って来るオーディオ、ビデオ、及び補助データセットのデータフォーマットをＨＤＭＩ（登録商標）仕様に準拠するフォーマットに変換するためのデータ変換回路を備えるＨＤＭＩ（登録商標）送信機を開示している。ＨＤＭＩ（登録商標）受信機は、逆作動を実行するデータ変換回路を備える。

特許文献３は、ＨＤＭＩ（登録商標）インタフェースを備えたソース装置とターゲット装置の間でオーディオ／ビデオ・コンテンツを局所的に放送する方法を開示している。この方法は、ソース装置においてオーディオ／ビデオ・コンテンツを圧縮するステップと、ソース装置と関連した送信機から、無線リンクを通じて圧縮オーディオ／ビデオ・コンテンツを送信するステップであって、送信機は、ソース装置のＨＤＭＩ（登録商標）インタフェースからオーディオ／ビデオ・コンテンツを受信するステップと、受信装置を使用して圧縮オーディオ／ビデオ・コンテンツを受信するステップとを含む。

特許文献４は、そのブランキング期間に挿入されるコンテンツ識別情報を有する、画像信号が複数のチャネルを通して差分信号の形で送られる通信システムを開示している。受信側で、受信機は、コンテンツ識別情報に基づいてコンテンツのタイプによって画像信号に最適のプロセスを実行できる。送信されるコンテンツのタイプを識別するためにソースにより挿入される識別情報は、ブランキング期間に配置された、パックされた情報フレームに置かれる。コンテンツ識別情報は、画像信号の圧縮方法の情報を含む。受信装置は、受信部が入力端子に入力される圧縮画像信号を受信するように構成されることができる。受信部により受信された画像信号がＪＰＥＧファイルと識別されるときに、スチール写真プロセスは画像信号のために実行される。

本説明の内容は、添付図のおかげでよりよく理解される。

本説明の基本的な方法による、マルチメディアシステムを通過するデータストリームの概要を図式的に表す。 図１に示されるデコーダのより詳細な概略図である。

本説明は、ほとんどすべての最新のレンダリング装置により提供される能力に基づいて解決策を提案する。この能力は、デコーダ或いはデコーダとレンダリング装置からなるマルチメディアシステムによってまだ利用されていない。

第１の態様によれば、本説明は、（ｉ）オーディオビデオ・コンテンツからのオーディオビデオ・データ及び(ii)少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレームをレンダリングする方法に関する。この方法は、
− デコーダによって、圧縮形態の前記オーディオビデオ・コンテンツを受信するステップと、
− デコーダから、前記圧縮形態のオーディオビデオ・コンテンツ、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム、及び制御データを出力するステップと、を含む。制御データは、オーディオビデオ・データをオーディオビデオ・コンテンツ及び少なくとも一つのアプリケーションフレームから形成する方法を記述することを目的にする。

本説明の一つの特定の特徴によれば、識別データ及び実施データは前記制御データに含まれる。識別データは、前記オーディオビデオ・コンテンツの少なくとも一部及び／又は前記少なくとも一つのアプリケーションフレームの一部を識別するために使われる。実施データは、前記オーディオビデオ・コンテンツ及び前記少なくとも一つのアプリケーションフレームの少なくとも一つのレンダリングを定める。

この特徴のため、実施データは、デコーダの管理下のままであり、例えば、デコーダにオーディオビデオ・コンテンツだけでなく、多数のアプリケーションサービスも提供できる有料テレビオペレータによって、いかなる時間にも容易に更新可能なままである。

有利なことに、有料テレビオペレータは、エンドユーザのレンダリング装置で最善の結果を得るように、デコーダを通して、ペイロード（即ち、オーディオビデオ・コンテンツ及びアプリケーションフレーム）及びこのペイロードを示す方法を定める実施データを制御できる。

オーディオビデオ・コンテンツは、オーディオビデオ・コンテンツを伝えるために使用する少なくとも一つのオーディオビデオ・メイン・ストリームによって、ビデオソース、例えばコンテンツプロバイダ又はヘッドエンドから受信できる。デコーダによって受信するときに、オーディオビデオ・コンテンツはデコーダによって圧縮解除されない。実際、このオーディオビデオ・コンテンツは、それがデコーダの入力で受信されたときに圧縮形態で、好ましくは同じ圧縮形態でレンダリング装置に達するようにデコーダを簡単に通過する。

第１に、この方法は、デコーダとレンダリング装置の間で高いビット速度でＵＨＤオーディオビデオ・ストリームの伝送を可能にする。その結果、この種の受信機がセットトップボックスに接続するときに、ＵＨＤ−ＴＶ（４Ｋ、８Ｋ）の次世代の全能力を使用できる。第２に、この方法はまた、特にデコーダからレンダリング装置へのオーディオビデオ・コンテンツの供給と同時に、デコーダが提供するアプリケーションサービスを利用する。これは、本説明が、高いビット速度で、ＵＨＤビデオストリームの処理から生じる膨大な量のデータだけでなく、アプリケーションデータも送信するための解決策も提供することを意味する。ＵＨＤオーディオビデオ・コンテンツとともに伝送されるこのアプリケーションデータの量は、非常に重要であり得る。

更にまた、本説明はまた、デコーダ及びレンダリング装置の両方からなるシステムの特定の機能の最適化を提供する。実際、ほとんどすべてのレンダリング装置は、圧縮解除手段、しばしばデコーダにおいて行うそれらより効率的で強力な技術を既に備えている。これは、テレビ市場がデコーダのそれより非常に急速に発展するという事実から主に生じる。従って、これまでに行われたように、このタスクをデコーダに任せる代わりに、レンダリング装置内のコンテンツの圧縮解除を処理するために消費者及び製造業者の両方にとって興味がある。

他の利点及び実施形態は、以下の説明に示される。

図１は、デコーダ２０及びデータリンク３０によってデコーダに接続するレンダリング装置４０からなるマルチメディアシステム１０の概要を図式的に示す。例えば、データリンク３０は、有線のＨＤＭＩ（登録商標）接続であり得る。レンダリング装置４０は、概して、テレビ、ビーマー、プレイステーション、コンピュータ、又は画面に表示可能な理解できるオーディオビデオ・データ１８を出力するのに適しているその他の装置であり得る。添付図に示されないけれども、画面は、レンダリング装置に組み込まれる（例えばテレビ表示画面）か又は後者から切り離される（例えばホームシネマのビーマーで用いられる画面）ことができる。

デコーダ２０は、例えば少なくとも一つのオーディオビデオ・メイン・ストリームを通して、圧縮形態のオーディオビデオ・コンテンツ１を受信するように構成される。この種のオーディオビデオ・コンテンツ１は、デコーダが受信できるいかなる種類のコンテンツでもあると当業者により理解される。特に、このコンテンツ１は、単一のチャネルに、又は複数のチャネルに関連できる。例えば、２つのチャネルのオーディオビデオ・ストリームが、例えば、ＰｉＰ機能を提供するのに適しているシステムにより受信されるとき、このコンテンツ１はそれらを含むことができる。オーディオビデオ・データ１８は、画面に表示可能なあらゆるデータであると理解される。この種のデータは、コンテンツ１又はこのコンテンツの一部を含むことができて、他の表示可能なデータ、例えばビデオデータ、テキストデータ、及び／又はグラフィックデータを更に含むことができる。オーディオビデオ・データ１８は、画面に最後に表示されるビデオ・コンテンツに、即ち、レンダリング装置４０から出力されるビデオ・コンテンツに特に関連する。図２によりよく示すように、オーディオビデオ・メイン・ストリームは、コンテンツプロバイダ５０から受信できる。コンテンツプロバイダは、例えば、あらゆるネットワークを通して、例えば衛星ネットワーク、地球的ネットワーク、ケーブルネットワーク、インターネットネットワーク、又は携帯端末／モバイル・ネットワークを通して、オーディオビデオ・ストリームを放送するための放送事業者又はヘッドエンドであり得る。オーディオビデオ・メイン・ストリームは、移送ストリームの一部、即ち、同時にいくつかのオーディオビデオ・メイン・ストリーム、データストリーム、及びデータ・テーブル・ストリームを含む一組のストリームであり得る。

本説明において提案される方法は、オーディオビデオ・コンテンツ１から、そして少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム４からオーディオビデオ・データ１８をレンダリングするためである。アプリケーションフレーム４は、そのコンテンツが特定のアプリケーションサービスに関する表示可能な画像であると考えることができる。例えば、アプリケーションフレームは、電子番組ガイドのページ、イベント（映画、テレビ番組など）を検索するためのページ、或いはあらゆる種類のメッセージを含む情報又はバナーをスクロールすることによって外部ビデオソース及び／又はイベントを表示するためのページであり得る。従って、アプリケーションフレームは、例えばビデオデータ、テキストデータ、及び／又はグラフィックデータのような、画面に表示できるあらゆるデータを含むことができる。

方法の基本形は、次のステップ；
− デコーダ２０によって、圧縮形態のオーディオビデオ・コンテンツ１を受信するステップ、
− デコーダ２０から、
− 上述した圧縮形態のオーディオビデオ・コンテンツ１、
− 少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム４、及び
− 制御データ７
を出力するステップ、を含む。

この方法は、それが識別データ３及び実施データ５を上述した制御データ７に含むためのステップを含むという事実によって特徴づけられる。図２によりよく示すように、制御データ７は、識別データ３及び実施データ５からなることができる。

識別データ３は、以下の説明及び図１と図２の両方において、画面に表示されるデータの少なくとも一部、即ち、オーディオビデオ・コンテンツの少なくとも一部及び／又は表示可能なデータ１５として参照する上述したアプリケーションフレーム４の一部を識別するために使うことができる。概して、識別データは、ストリーム識別子及び／又はパケット識別子という形をとることができる。

実施データ５は、オーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４のレンダリングを定める。このために、実施データは、レンダリング装置４０に送らなければならない上述した表示可能なデータ１５の少なくとも一部をレンダリングするために実施ルールを定めることができる。従って、実施データ５は、前記表示可能なデータ１５の少なくとも一部がどのように画面に示されるか又はレンダリングされなければならないかについて定める。

この種のプレゼンテーションは、例えば、画面のサイズ、同時に表示しなければならないオーディオビデオ・メイン・ストリームの数、或いはなにかのテキスト及び／又はグラフィックデータがビデオ・コンテンツとともに同時に表示されなければならないどうかに依存することがあり得る。プレゼンテーションは、関連したアプリケーションサービスに依存して、例えば、あらゆる種類の表示可能なデータ１５をリサイズするか又はオーバーレイすることが必要であり得る。表示可能なデータをオーバーレイすることは、透明度の有無にかかわらず達成できる。

従って、実施データ５は、表示可能なデータ１５を表示するためのターゲット領域の寸法、サイズ、及び位置、並びに前記データ又は前記データを表示するときに適用される透明度のような特定の効果を表示するための優先規則に関することができる。一実施形態において、実施データは、少なくとも表示領域を定めるデータ又はパラメータ及び表示可能領域の中の関連した位置に関する。この表示可能領域は、例えば、表示画面のサイズに関して表すことができる。

換言すれば、実施データは、オーディオビデオ・コンテンツ１及び少なくとも一つのアプリケーションフレーム４の少なくとも一つのレンダリングを定める。このレンダリングは、レンダリング装置（例えば、エンドユーザ装置の表示画面）におけるオーディオビデオ・コンテンツ及び／又はアプリケーションフレームのプレゼンテーションである。換言すれば、レンダリングは、レンダリング装置におけるオーディオビデオ・コンテンツ及び／又はアプリケーションフレームの出現である。この出現は、レンダリング装置におけるオーディオビデオ・コンテンツの位置及び／又はアプリケーションフレームの位置に関することがあり得る。この位置は表示画面上の絶対位置であり得るか、又はそれは相対的な位置、例えばオーディオ／ビデオ・コンテンツと少なくとも一つのアプリケーションフレーム間の相対的な位置であり得る。この出現は、オーディオビデオ・コンテンツ及び／又はアプリケーションフレームがレンダリング装置において表示されるウインドウのサイズに関することがあり得る。これらのウインドウのいずれも、他のデータ又は他のウインドウ上にオーバーレイにより表示することができて、このオーバーレイは透過性効果の有無に拘わらずあり得る。これらのパラメータ（位置、サイズ、オーバーレイ、透明度など）は、出現目的のためにいかなる方法でも組み込むことができる。他のパラメータ（例えば、色、ウインドウ・フレーム・ライン、或いはその他の視聴効果又は選択）を考慮することもできる。

有利なことに、本方法は、特に圧縮オーディオビデオ・コンテンツ１を圧縮解除するために、いかなる圧縮解除動作も実行しない。これは、オーディオビデオ・コンテンツ１が、デコーダ２０からレンダリング装置４０の方へ出力される前に、デコーダによって圧縮解除され続いて再圧縮もされないことを意味する。一実施形態によれば、このオーディオビデオ・コンテンツ１は、処理せずにデコーダ２０を単に通過する。

本方法のため、高いビットレートを提供するいかなる周知の送信手段も、高いビットレートでＵＨＤストリームを送信するために用いることができるように、デコーダ２０とレンダリング装置４０間の帯域幅を狭くすることができる。

この第１の実施形態の説明がデコーダに関連するけれども、このデコーダを、ＵＨＤビデオ・コンテンツをレンダリング装置の方へ供給するのに適しているいかなるコンテンツソースにも置き換えることもできる。このコンテンツソースは、あらゆる装置、例えば、超高密度ブルーレイを読み込むための光学式文字読取装置であり得る。

有料テレビ分野において、オーディオビデオ・メイン・ストリームは、暗号化形式でしばしば受信される。暗号化は、暗号化ステップに従ってプロバイダ又はヘッドエンドにより実行される。一実施形態によれば、デコーダ２０により受信されるオーディオビデオ・コンテンツの少なくとも一部は、暗号化形式である。この場合、オーディオビデオ・メイン・ストリームは、少なくとも前記オーディオビデオ・コンテンツ１を暗号化された圧縮形態で伝える。好ましくは、この種のオーディオビデオ・コンテンツは、暗号化される前に最初に圧縮された。この実施形態によれば、方法は、デコーダ２０によって、前記オーディオビデオ・コンテンツを前記圧縮形態で出力する前に受信したオーディオビデオ・コンテンツを解読するためのステップを更に含むことができる。

制御データ７は、例えば、移送ストリームを通して、別々のデータストリームとして、又はオーディオ・ビデオ・メイン・ストリームとともに、デコーダ２０の外部のソースから受信できる。或いは、制御データ７は、内部ソース、即ちデコーダ内に設置されたソースにより提供されることもあり得る。従って、制御データ７は、デコーダ２０によって、例えば図２に示すアプリケーションエンジン２４によって生成できる。

別の実施形態によれば、前述の少なくとも一つのアプリケーションフレーム４は、このデコーダの外部のソースからデコーダ２０により受信される。この種の外部ソースは、制御データ７をデコーダに提供するそれと同一か、異なるか、又は類似であり得る。或いは、前述の少なくとも一つのアプリケーションフレーム４は、デコーダ自体によって生成できる。従って、デコーダ２０は、アプリケーションフレーム４を生成するためにアプリケーションエンジン２４を更に備えることができる。

図１に示すように、レンダリング装置４０は、例えば規則を実施することによって、上述した実施データ５に従って表示可能なデータ１５の全部又は一部のプレゼンテーションを可能にするアプリケーションサービスを展開するように構成される制御ユニット４４を更に備えることができる。従って、デコーダのアプリケーションエンジン２４が、レンダリング装置に送られる表示可能なデータ１５の少なくとも一部に関する制御データ７を提供することによって、アプリケーションサービスを生成し、その結果、制御ユニット４４は、レンダリング装置内でアプリケーションサービスを展開するために前記制御データ７及び表示可能なデータの少なくとも一部の両方を使用できることを理解すべきである。換言すれば、これは、制御ユニット４４が前記制御データ７及び表示可能なデータの少なくとも一部の両方に基づいて得られる特定のアプリケーションサービスに対応する理解できるオーディオビデオ・データ１８を生成することを意味する。従って、理解できるオーディオビデオ・データ１８は、前記表示可能なデータ１５の少なくとも一部の特定のプレゼンテーションを含み、そしてこのプレゼンテーションの特定の性質は、実施規則を実施するのに適していることができる制御データ７によって定められる。このために、制御ユニット４４は、このユニットのメモリに格納されるシステムソフトを使用できる。

更なる実施形態によれば、アプリケーションフレーム４のうちの少なくとも一つは、デコーダ２０から、及び／又はデコーダの外部の少なくとも一つのソースから来るアプリケーションデータ２に基づいている。アプリケーションデータ２は、アプリケーションフレーム４を生成するために使うことができるあらゆるソースデータであると考えることができる。従って、アプリケーションデータ２は、例えば移送ストリームを通して、又はオーディオビデオ・メイン・ストリームとともに、外部ソースからデコーダに提供することができる生データに関する。或いは、生データは、内部ソース、即ち、内部データベース又は記憶装置のようなデコーダ内にあるソースにより提供されることもできる。内部ソースは、アプリケーションデータ２によってプレロードされることができて、例えばデコーダの入力で受信されるデータストリームを介して、付加的又は新しいアプリケーションデータ２によって更新できる。従って、アプリケーションデータは、内部及び／又は外部のデータであり得る。

また、デコーダ２０からオーディオビデオ・コンテンツ１、アプリケーションフレーム４、及び制御データ７のレンダリング装置４０への伝送が、データリンク３０を通して行われる点に留意する必要がある。図１及び図２に示すように、データリンク３０は、これらの２つの構成要素２０、４０間の一つ或いは複数の接続手段の概略図である。従って、これらのストリーム、フレーム、及びデータは、一つ或いは複数の送信手段によって、いろいろな方法で送信できる。好ましくは、データリンク３０、又はこれらの送信手段の一つは、ＨＤＭＩ（登録商標）接続手段である。

一旦関連したアプリケーションサービスが制御ユニット４４により作成されると、レンダリング装置４０は、このアプリケーションサービスをその出力インタフェースの方へ、例えば適切な画面に表示されなければならないオーディオビデオ・データ１８であるとして送る。

図１及び図２に示すように、デコーダ２０の外部にあるか、又はマルチメディアシステム１０の外部にあるあらゆるソースから来るアプリケーションデータは、外部のアプリケーションデータ１２として参照される。アプリケーションデータの少なくとも一部が外部のアプリケーションデータ１２であるとみなされる場合には、方法は、
− デコーダ２０で、外部のアプリケーションデータ１２を受信するステップと、
− アプリケーションフレーム４を生成するためにアプリケーションデータ２として前記外部のアプリケーションデータ１２を使用するステップと、
を更に含む。

これは、外部アプリケーションデータ１２及び内部アプリケーションデータが、即ちアプリケーションデータ２であるとして、同様にアプリケーションエンジン２４により処理されることを意味する。

一実施形態によれば、アプリケーションフレーム４は、圧縮オーディオビデオ・コンテンツが出力されるストリームとは別であるアプリケーションサブストリーム１４を通してデコーダ２０から出力される。この場合、アプリケーションサブストリーム１４は、オーディオビデオ・メイン・ストリームに含まれるオーディオビデオ・コンテンツと並行して送ることができるスタンドアロンストリームであると考えることができる。例えば、サブストリーム１４は、オーディオビデオ・コンテンツをデコーダ２０から出力するために用いるそれと同じ通信手段内で送ることができる。或いは、サブストリーム１４は、別々の通信手段内で送ることができる。

加えて、アプリケーションサブストリーム１４が圧縮オーディオビデオ・メイン・ストリームとは完全に別であるとき、従って、それは、メインストリーム内のオーディオビデオ・コンテンツの形とは関係なく、圧縮形態で、又は圧縮解除形態で有利に送ることができる。一実施形態によれば、アプリケーションサブストリーム１４のアプリケーションフレーム４は、デコーダ２０とレンダリング装置４０の間のデータリンク３０の必要な帯域幅を更に減らすために圧縮形態で送られる。このために、方法は、
− アプリケーションサブストリーム１４がデコーダ２０から出力される前にそれをデコーダ２０で圧縮するステップを、更に含む。

圧縮オーディオビデオ・コンテンツの場合と同一方法で、圧縮アプリケーションフレームは、アプリケーションサービスを展開する前にレンダリング装置４０で圧縮解除できる。この最後の段階は、制御ユニット４４で、デコーダ２０から出力される表示可能なデータ１５（即ち、オーディオビデオ・コンテンツ及び／又はアプリケーションフレーム）の少なくとも一部を含むオーディオビデオ・データ１８を生成する前にレンダリング装置４０でアプリケーションサブストリーム１４のデータを圧縮解除することを目的とする。この表示可能なデータは、上述した制御データ７によって、特に制御データ７に含まれる実施データ５により定められる特定のプレゼンテーションに従って提示される。

レンダリング装置内で、アプリケーションサブストリーム１４によって伝えられる圧縮データの圧縮解除は、オーディオビデオ・メイン・ストリームによって伝えられる圧縮オーディオビデオ・コンテンツ１を圧縮解除するために使用するそれらと同じ手段によって有利に実行できる。

別の実施形態によれば、アプリケーションサブストリーム１４は、それらをデコーダから出力する前に、即ち、これらのストリーム及びサブストリームをレンダリング装置４０へ伝送する前に、デコーダ２０であらゆるオーディオビデオ・メイン・ストリームによって更に多重送信できる。この場合、レンダリング装置４０は、アプリケーションサービスを展開するために、特にこのアプリケーションサービスに対応するオーディオビデオ・データ１８を生成するためにそれらを処理する前に、デコーダから受信されるストリーム／サブストリームを非多重化することが可能でなければならない。従って、方法は、
− それらがデコーダから出力される前に、デコーダ２０で、前述の少なくとも一つの圧縮オーディオビデオ・メイン・ストリームとともにアプリケーションサブストリーム１４を多重送信するステップを更に含むことができる。

一実施形態において、制御データ７はアプリケーションサブストリーム１４の中に挿入され、その結果、アプリケーションサブストリーム１４は、アプリケーションフレーム４及び制御データ７の両方を伝える。この種のサブストリームの中で、制御データ７は、例えば、特定のデータパケットを用いて、又は特定のデータ・パケット・ヘッダーを通して識別できる。従って、それらが同じサブストリーム１４にインターリーブされる場合であっても、制御データ７及びアプリケーションフレーム４は、互いに識別可能なままである。

例示の実施形態において、制御データ７は、アプリケーションサブストリーム１４を通して、少なくとも一つのヘッダーに送信される。この種のヘッダーは、パケットヘッダー、特にフレーム（４）データを伝えるパケットのヘッダーであり得る。それは、ストリームヘッダー、特にそのペイロードの前にアプリケーションサブストリーム１４の初めに配置されるヘッダーでもあり得る。実際、制御データ７が、関連した表示可能なデータ１５がどのように提示されなければならないか定めるために使用する識別子及び設定パラメータに主に関するので、この種の識別子及び設定パラメータは大量の情報を表さない。従って、制御データは、パケットヘッダー及び／又はストリームヘッダーの代わりをすることができる。

更なる実施形態において、制御データ７は、スタンドアロンストリーム、即ち、その他のストリームと別であるストリームであると考えることができる制御データストリーム１７を通して送信される。好ましくは、制御データストリーム１７は、同じ通信手段の中で、又は特定の通信手段を通して、表示可能なデータ１５と並行して送信される。

一般的に言って、制御データ７は、制御データストリーム１７を通して、又はアプリケーションサブストリーム１４を通して送信することができる。

加えて、デコーダ２０により実行される上述した出力ステップの少なくとも一つは、好ましくは、例えばＨＤＭＩ（登録商標）ケーブルのような、ＨＤＭＩ（登録商標）手段を通して実行される。ＨＤＭＩ（登録商標）通信がデータ交換のフレームを定めるＨＤＣＰプロトコルによって通常保護される点に留意する必要がある。ＨＤＣＰは、暗号化層を保護されていないＨＤＭＩ（登録商標）ストリームに加える。ＨＤＣＰは、証明書確認及びデータ暗号化に基づいている。データがソース装置により出力される前に、ソース証明書及びシンクが交換されるハンドシェイクは開始される。受信された証明書（例えばＸ５０９）は、それから、照査されて、共通の暗号化キーを確立するために用いる。検証は、白いか黒いリストを使用できる。

図２をより詳しく参照して、上記の方法を実施するために使用するデコーダ２０は、次により詳細に説明される。

図２に示すように、デコーダ２０は、例えば、少なくとも一つのオーディオビデオ・メイン・ストリームの中で、少なくともオーディオビデオ・コンテンツ１を圧縮形態で受信するために入力インタフェース２１を備える。好ましくは、この入力インタフェースは、あらゆる適切なネットワーク（衛星、地球上の生物、インターネットなど）を通してコンテンツプロバイダ５０から送信される移送ストリームを受信するのに適している。入力インタフェース２１を通して以前受信された少なくとも一つのオーディオビデオ・コンテンツを出力するために、デコーダは出力インタフェース２２も備える。概して、この出力インタフェース２２は、データリンク３０により用いられて、デコーダ２０をレンダリング装置４０に接続する。

本説明の内容によれば、出力インタフェース２２は、圧縮コンテンツを出力するのに適していて、デコーダ２０は、特にそれが入力インタフェース２１で受信されたとき、あらゆる圧縮コンテンツを出力するように構成される。基本的に、そして一実施形態に従って、これは、入力インタフェース２１で受信されるオーディオビデオ・コンテンツ１が、デコーダ２０内で圧縮解除されずに出力インタフェース２２に向けられることを意味する。出力インタフェース２２が、圧縮コンテンツだけを出力することに限られなくて、非圧縮データを出力するのにも適することがあり得ることを理解すべきである。より詳しくは、出力インタフェース２２は、前記圧縮オーディオビデオ・コンテンツ１、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム４、及び制御データ７を出力するように構成される。この制御データ７は、識別データ３及び実施データ５を含む。識別データ３は、オーディオビデオ・コンテンツ１の少なくとも一部及び／又は少なくとも一つのアプリケーションフレーム４の一部を識別するために使われる。実施データ５は、オーディオビデオ・コンテンツ１及び／又は前述の少なくとも一つのアプリケーションフレーム４のレンダリングを定める。

入力インタフェース２１は、デコーダ２０の外部のソースから制御データ７及び／又は少なくとも一つのアプリケーションフレーム４を受信するように更に構成されることができる。この入力インタフェースは、外部のアプリケーションデータ１２を受信するように更に構成されることができる。これらのデータ７、１２のいずれも、及びこれらのアプリケーションフレーム４のいずれも、圧縮又は非圧縮形態で入力インタフェース２１を通して受信できる。

一実施形態によれば、デコーダ２０は、少なくとも制御データ７を生成するためにアプリケーションエンジン２４を更に備える。前記制御データ７は、オーディオビデオ・データ１８を前記オーディオビデオ・コンテンツ及び前記少なくとも一つのアプリケーションフレーム４から形成する方法を記述している。或いは、このアプリケーションエンジン２４は、少なくとも一つのアプリケーションフレーム４を生成するように構成されることができる。好ましくは、アプリケーションエンジン２４は、制御データ７及び少なくとも一つのアプリケーションフレーム４を生成するように構成される。デコーダ２０はまた、これらのアプリケーションフレーム４及び制御データ７を出力インタフェース２２の方へ送るように構成される送信ユニット２３を備える。概して、送信ユニット２３は、送らなければならないデータを作成するためにも用いる。従って、送信ユニット２３のタスクは、この種のデータをコード化すること、アプリケーションフレーム及び制御データのパケット化を実行すること、並びに／或いはパケットヘッダー及び／又はストリームヘッダーを作成することであり得る。

加えて、デコーダ２０は、アプリケーションフレーム４を生成するためにアプリケーションエンジン２４により用いることができるアプリケーションデータ２を格納するためにデータベース又は記憶装置２５を備えることができる。従って、記憶装置は、アプリケーションフレームを生成するためにアプリケーションエンジンによって使用可能な所定のデータを格納するためのライブラリであると考えることができる。記憶装置のコンテンツは、例えば、外部ソース、例えばコンテンツプロバイダ５０から付加的であるか又は更新されたアプリケーションデータを受信することによって進化することもできる。

別の実施形態によれば、デコーダ２０は、外部のアプリケーションデータ１２をアプリケーションエンジン２４に受信するために入力データリンク２６を備えることができる。この種の外部のアプリケーションデータ１２は、記憶装置２５により提供される内部アプリケーションデータとともに処理できるか、又はそれは、内部アプリケーションデータの代わりに処理できる。外部のアプリケーションデータ１２は、デコーダ２０の外部又はマルチメディアシステム１０の外部のいかなるソース６０からも受信できる。外部ソース６０は、例えば、社会的ネットワーク（フェイスブック、ツィッター、リンクドインなど）から、インスタントメッセージング（スカイプ、メッセンジャー、グーグルトークなど）から、共有ウェブサイト（ユーチューブ、フリッカー、インスタグラムなど）又はその他のソーシャルメディアからデータを受信するために、インターネットに接続しているサーバであり得る。他のソース、例えば、電話プロバイダ、コンテンツプロバイダ５０、又は私用ビデオ監視ソースは、外部ソース６０であると考えることができる。

一般的に言って、アプリケーションエンジン２４は、少なくとも一つのアプリケーションフレーム４を生成するために使われるアプリケーションデータ２、１２を受信するために、記憶装置２５に、及び／又はデコーダ２０の外部の少なくとも一つのソースに接続可能である。

更なる実施形態によれば、送信ユニット２３は、いかなる圧縮オーディオビデオ・コンテンツとも別であるアプリケーションサブストリーム１４を通してアプリケーションフレーム４を送るように構成される。

変形によれば、デコーダ２０は、前述の少なくとも一つのアプリケーションフレーム４を圧縮するように、より詳しくは、出力インタフェース２２を通してアプリケーションフレーム４を送る前にアプリケーションサブストリーム１４を圧縮するように構成される圧縮ユニット２８を更に備える。図２に示すように、圧縮ユニット２８は、例えば、送信ユニット２３でそれらの引渡しを準備する前にアプリケーションフレーム４を形成するデータを圧縮するために、送信ユニット２３の内部に、又はこのユニットの外部に置くことができる。

別の変形によれば、デコーダは、出力インタフェース２２を通してメインストリームを出力する前に、前述の少なくとも一つのオーディオビデオ・メイン・ストリームとともにアプリケーションサブストリーム１４を多重送信するように構成されるマルチプレクサ２９を備える。マルチプレクサ２９から伸びる点線によって図２に示すように、制御データストリーム１７は、例えば、単一のストリームを出力インタフェース２２から出力するために、その他のストリームと、即ち、アプリケーションサブストリーム１４と、オーディオビデオ・メイン・ストリームと、又はメインストリーム及びアプリケーションサブストリーム１４の両方と多重送信することもできる。

一実施形態において、アプリケーションエンジン２４又は送信ユニット２３は、アプリケーションサブストリーム１４の中に制御データ７を挿入するように更に構成され、その結果、このアプリケーションサブストリーム１４は、アプリケーションフレーム４及び制御データ７の両方を伝える。本説明に開示される方法に関して既に述べたように、この種の挿入は、各種の方法により行うことができる。例えば、挿入は、制御データ７をフレーム４に関するデータでインターリーブすることによって、又はアプリケーションサブストリーム１４内で少なくとも一つのヘッダー（パケットヘッダー及び／又はストリームヘッダー）に制御データ７を配置することによって得ることができる。この種の動作は、制御データストリーム１７から来てアプリケーション・データ・ストリーム１４に加わる点線によって図式的に示すように、送信ユニット２３によって実行できる。

変形によれば、アプリケーションエンジン２４又は送信ユニット２３は、制御データストリーム１７を通して、即ち、その他のストリームとは別であるスタンドアロン又は独立ストリームを通して制御データ７を送るように構成されることができる。

更にまた、デコーダ２０は、他の構成要素、例えば、少なくとも一つのチューナー及び／又はバッファを備えることができる。チューナーは、デコーダにより受信される移送ストリームに含まれるすべてのオーディオビデオ・メイン・ストリームの中でテレビチャンネルを選択するために用いることができる。バッファは、外部ソースから受信されるオーディオビデオ・データ、例えば外部のアプリケーションデータ１２を緩衝するために用いることができる。デコーダは、例えば、オペレーティングシステム及びミドルウェアのホストをつとめるために、コンピュータ構成要素を更に備えることができる。これらの構成要素は、アプリケーションデータを処理するために用いることができる。

対応する方法に関して既に述べたように、実施データ５は、オーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４を表示するためにターゲット領域に関するデータを含むことができる。

実施データ５は、表示可能なデータをオーバーレイする場合に適用できる優先権を定めることができる。この種の優先権は、オーディオビデオ・コンテンツ１及び／又は前述の少なくとも一つのアプリケーションフレーム４をレンダリングするために適用される施行規則という形をとることができる。この種の優先権パラメータによれば、どの表示可能なデータが、オーバーレイの場合に前に持ってこなければならないか、又は後ろに送らなければならないか定めることが可能になる。

実施データ５は、オーバーレイの場合にオーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４に作用する透過性効果を定めることができる。

実施データ５によって、オーディオビデオ・コンテンツ及び／又は少なくとも一つのアプリケーションフレーム４の大きさを変更できることもあり得る。この種の大きさを変更する効果は、オーディオビデオ・コンテンツ１及び／又は前述の少なくとも一つのアプリケーションフレーム４をレンダリングするために適用される規則によって定めることができる。

別の実施形態によれば、デコーダ２０は、特にオーディオビデオ・コンテンツが暗号化された形で受信される場合に、オーディオビデオ・コンテンツ１を解読するように構成されることができる。

本説明はまた、以前に開示された方法を実施するためにマルチメディアシステム１０をカバーすることを目的にする。特に、このマルチメディアシステム１０は、この方法の実施形態のいずれでも実施するのに適していることができる。このために、このシステム１０のデコーダ２０は、このデコーダに関する実施形態のどれに従っても構成されることができる。

従って、マルチメディアシステム１０は、少なくともデコーダ２０及びデコーダ２０に接続しているレンダリング装置４０を備える。デコーダ２０は、圧縮形態のオーディオビデオ・コンテンツ１を受信するための入力インタフェース２１、及びオーディオビデオ・コンテンツ１を出力するための出力インタフェース２２を備える。レンダリング装置４０は、少なくとも上述したオーディオビデオ・コンテンツ１、少なくとも一つのアプリケーションフレーム４、及びデコーダ２０から出力された制御データ７からオーディオビデオ・データ１８を出力するために用いる。

従って、このマルチメディアシステム１０のデコーダ２０は、入力インタフェース２１により受信される少なくとも一つの圧縮オーディオビデオ・コンテンツ１をレンダリング装置４０に、そして前記出力インタフェース２２を通して送信するように構成される。デコーダ２０は、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム４、及び制御データ７を同一方法によって、又は類似の方法によって送信するように更に構成される。加えて、レンダリング装置４０は、デコーダ２０から受信したオーディオビデオ・コンテンツを圧縮解除して、上述したオーディオビデオ・データ１８の全部又は一部を形成するために、制御データ７に従ってアプリケーションフレーム４を処理するように構成される。アプリケーションフレーム４を処理する代わりに、受信装置４０は、制御データ７に従って圧縮解除されたオーディオビデオ・コンテンツ１を処理できる。或いは、受信装置４０は、実施データ７に従ってオーディオビデオ・コンテンツ１及び前述の少なくとも一つのアプリケーションフレーム４を処理できる。前記方法と同様に、制御データ７は、識別データ３及び実施データ５からなる。識別データ３は、オーディオビデオ・コンテンツ１の少なくとも一部及び／又は少なくとも一つのアプリケーションフレーム４の一部を識別するために使われる。実施データ５は、オーディオビデオ・コンテンツ１及び前述の少なくとも一つのアプリケーションフレーム４の少なくとも一つのレンダリングを定める。

このマルチメディアシステムのデコーダ２０がマルチプレクサ２９を備える場合、このシステムのレンダリング装置４０は、デコーダから受信した多重化ストリームを非多重化するためにデマルチプレクサ４９（図１）を更に備える。同様に、マルチメディアシステム１０のデコーダ２０が圧縮ユニット２８を備える場合、マルチメディアシステム１０のレンダリング装置４０は、少なくともアプリケーションサブストリーム１４を圧縮解除するために圧縮解除ユニット４８を更に備える。更にまた、マルチメディアシステム１０、特にデコーダ２０が、暗号化されたオーディオビデオ・コンテンツを受信するために設計される場合には、レンダリング装置４０は、暗号化されたコンテンツを解読するためにセキュリティ手段４７を更に備えることができる。

また、ストリーム１、１４、及び１７の全部又は一部が一緒に多重送信される場合、レンダリング装置４０のデマルチプレクサ４９は、いかなるストリームをも圧縮解除する前に、又はそれが暗号化される場合はオーディオビデオ・コンテンツを解読する前でさえ、入力ストリームを最初に処理する。いずれにせよ、圧縮解除は、解読及び非多重化動作の後に起こる。

本説明の内容がどうであれ、オーディオビデオ・メイン・ストリームが暗号化される場合には、レンダリング装置４０において解読される代わりに、それがデコーダ２０において好ましくは解読される点に留意する必要がある。従って、セキュリティ手段４７は、図１に示すようにレンダリング装置４０に置かれる代わりに、デコーダ２０の中に置くことができる。

好ましくは、セキュリティ手段４７は、解読プロセスを行うことに限定されなくて、それは、他のタスク、例えば、デジタル著作権管理（ＤＲＭ）を処理するための条件付きアクセスに関するいくつかのタスクを実行することが可能である。従って、セキュリティ手段は、いかなる解読も実行する前に加入者の権利（資格）に関してアクセス条件を点検するために用いることができる条件付きアクセスモジュール（ＣＡＭ）を含むことができる。通常、解読は制御ワード（ＣＷ）により実行される。ＣＷは解読キーとして使われて、資格制御メッセージ（ＥＣＭ）によって伝えられる。

セキュリティ手段は、セキュリティモジュール、例えば、共通インタフェースに挿入できるスマートカード（例えば、ＤＶＢ−ＣＩ、ＣＩ＋）であり得る。この共通インタフェースは、デコーダ又はレンダリング装置に設置できる。セキュリティ手段４７は、特にセキュリティモジュールが着脱可能モジュール、例えばスマートカードである場合には、セキュリティモジュールを受信するためのインタフェース（例えば、ＤＶＢ−ＣＩ、ＣＩ＋）であると考えることもできる。より詳しくは、セキュリティモジュールは、４つの異なった形式に従って設計できる。

形式の一つは、マイクロプロセッサカード、スマートカード、又は更に一般的にいえば、例えばキー又はタグの形を有することができる電気モジュールである。この種のモジュールは、通常、レシーバに着脱可能である。電気的コンタクトを有する形が最も多く用いられるが、例えばタイプＩＳＯ １４４４３の、コンタクトのない結合を排除しない。

第２の周知の設計は、一般に限定的なかつ移動できない方法で、受信機の印刷基板に配置される集積回路チップのそれである。変形例は、ベース又はコネクタ、例えばＳＩＭモジュールのコネクタに載置する回路により構成される。

第３の設計において、セキュリティモジュールは、例えば、デコーダの暗号解読モジュール又はデコーダのマイクロプロセッサで、別の機能も有する集積回路チップに集積化される。

第４の実施形態において、セキュリティモジュールは、ハードウェアの形で実現されないが、その機能はソフトウェアの形だけで実施される。このソフトウェアは、受信機の主要なソフトウェアの中でわかりにくくすることができる。

４つの場合において機能が同一であると想定すれば、セキュリティレベルが異なるけれども、我々は、その機能又はこのモジュールをとることができる形を実現するのに適切ないずれかの方法でセキュリティモジュールを参照する。上記の４つの設計において、セキュリティモジュールは、そのメモリに格納されるプログラム（ＣＰＵ）を実行するための手段を備えている。このプログラムは、権利を確認すること、解読を遂行すること、又は解読モジュールなどを起動させることなどのセキュリティ動作の実行を可能にする。

本説明はまた、上記のマルチメディアシステム１０のレンダリング装置４０をカバーすることを目的とする。このために、本説明の更なる目的は、圧縮オーディオビデオ・コンテンツ１及び少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム４をレンダリングするためのレンダリング装置４０である。より詳しくは、レンダリング装置４０は、前記オーディオビデオ・コンテンツ１の少なくとも一部及び／又は前述の少なくとも一つのアプリケーションフレーム４の一部を識別するために、圧縮オーディオビデオ・コンテンツ１、前述の少なくとも一つのアプリケーションフレーム４、及び識別データ３からオーディオビデオ・データ１８をレンダリングするように構成される。

このために、レンダリング装置４０は、圧縮オーディオビデオ・コンテンツ１、少なくとも一つのアプリケーションフレーム４、及び識別データ３を受信するための手段、例えば、入力インタフェース又はデータ入力を備える。このレンダリング装置は、少なくとも圧縮オーディオビデオ・コンテンツ１を圧縮解除するための圧縮解除ユニット４８を更に備える。レンダリング装置４０は、オーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４を処理するように構成される制御ユニット４４も備える。レンダリング装置４０は、入力インタフェースが、オーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４からオーディオビデオ・データ１８を得る方法を定める実施データ５を受信するように更に構成されるという点を特徴とする。更に、制御ユニット４４は、識別データ３及び実施データ５に従ってオーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４を処理するように更に構成される。より詳しくは、制御ユニット４４は、実施データ５に従って、識別データ３により識別される、オーディオビデオ・コンテンツ１及び／又は少なくとも一つのアプリケーションフレーム４を処理するように構成される。好ましくは、識別データ３及び実施データ５は、対応する方法に関して前に述べたように、制御データ７に含まれる。制御データ７は、オーディオビデオ・データ１８をオーディオビデオ・コンテンツ１及び前述の少なくとも一つのアプリケーションフレーム４から形成する方法を記述する。既に説明されたように、識別データ３は、オーディオビデオ・コンテンツ１の少なくとも一部及び／又は少なくとも一つのアプリケーションフレーム４の一部を識別するために使われる。実施データ５は、オーディオビデオ・コンテンツ１及び前述の少なくとも一つのアプリケーションフレーム４の少なくとも一つのレンダリングを定める。「レンダリング」概念は、対応する方法に関して説明されたそれと同じである。アプリケーションフレーム４及びオーディオビデオ・コンテンツ１（一度は圧縮解除された）が表示可能なデータ１５であると想定すれば、レンダリング装置は、この種の表示可能なデータを読み込むことが十分に可能である。加えて、制御ユニット４４が、制御データ７を実行するためにシステムソフトを使用できるので、レンダリング装置は、実施データ５をこれらの表示可能なデータ１５の少なくとも一部に適用することによって、特定のプレゼンテーションを表示可能なデータ１５に提供することが可能である。このように、レンダリング装置１０は、個人化された単一ストリームと考えることができる理解できるオーディオビデオ・データ１８を生成することが可能である。一旦生成すると、オーディオビデオ・データ１８は、いかなる画面にも表示可能な単一共通ストリームとしてレンダリング装置４０から出力されることができる。

有利なことに、オーディオビデオ・コンテンツ１及びアプリケーションフレーム４が配置されて、制御データ７に従って、特に実施データ５に従って一緒に結合されたと想定すれば、レンダリング装置４０は、前記オーディオビデオ・データ１８を介して強化されたオーディオビデオ・コンテンツをレンダリングすることが可能である。

マルチメディアシステム１０に関して前に述べたように、レンダリング装置４０は、いかなる暗号化されたコンテンツも解読するためのセキュリティ手段４７を更に備えることができる。既に述べたように、アプリケーションフレーム４４は、アプリケーションサブストリーム１４を通して受信できる。この種のサブストリーム１４が、レンダリング装置４０により受信される前にいかなるオーディオビデオ・メイン・ストリームとも多重送信できると想定すれば、従って、レンダリング装置４０は、いかなる多重化ストリームも非多重化するためのデマルチプレクサ４９を更に備えることができる。

本説明の内容がどうであれ、実施形態がいかなる方法でも互いに組み合わせることができる点に留意する必要がある。

本発明の内容の概要が、特定の例示の実施形態を参照して説明されたけれども、種々の変更態様及び改変は、本発明の実施形態のより広い精神及び範囲を逸脱せずにこれらの実施形態になすことができる。例えば、種々の実施形態又はその特徴は、当業者により混合されて、適合されるか、又は選択されることができる。本発明の内容のこの種の実施形態は、便宜のために、そして一つ以上が、実際に、開示される場合、この明細書の範囲をいかなる単一発明又は発明の概念にも自発的に限定する意図なしに、単に「発明」という用語だけによって、本明細書において、個々に又は集合的に参照できる。

本願明細書に例示される実施形態は、当業者が開示される教示を行うことを可能にするために充分詳細に説明されていると考えられる。他の実施形態は使われて、そこから引き出されることができる。そうすると、構造的及び論理的置換及び変更は、この開示の範囲を逸脱せずになされることができる。詳細な説明は、従って、限定的にとられてはならず、そして種々の実施形態の範囲は、この種の請求項が受けるあらゆる等価物とともに、添付の請求の範囲だけにより規定される。

Claims (16)

1. 圧縮形態のオーディオビデオ・コンテンツ（１）を受信するための入力インタフェース（２１）と、
   前記圧縮オーディオビデオ・コンテンツ（１）、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム（４）、及び制御データ（７）を出力するための出力インタフェース（２２）と、
   を備えるデコーダ（２０）であって、
   前記制御データ（７）は、識別データ（３）及び実施データ（５）を備え、
   前記識別データ（３）は、前記オーディオビデオ・コンテンツ（１）の少なくとも一部及び／又は前記少なくとも一つのアプリケーションフレーム（４）の一部を識別するために使われ、かつ
   前記実施データ（５）は、前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つのレンダリングを定める
   ことを特徴とするデコーダ（２０）。
2. 少なくとも前記制御データ（７）を生成するためのアプリケーションエンジン（２４）を更に備える請求項１に記載のデコーダ（２０）。
3. 前記入力インタフェース（２１）は、前記デコーダ（２０）の外部のソースから前記少なくとも一つのアプリケーションフレーム（４）を受信するように更に構成される請求項１又は２に記載のデコーダ（２０）。
4. 前記アプリケーションエンジン（２４）は、前記少なくとも一つのアプリケーションフレーム（４）を生成するように更に構成される請求項２に記載のデコーダ（２０）。
5. 前記少なくとも一つのアプリケーションフレーム（４）を圧縮するように構成される圧縮ユニット（２８）を更に備える請求項１〜４のいずれか一項に記載のデコーダ（２０）。
6. 前記実施データ（５）は、前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つを表示するためのターゲット領域に関するデータを含む請求項１〜５のいずれか一項に記載のデコーダ（２０）。
7. 前記実施データ（５）は、表示可能なデータをオーバーラップする場合に適用できる優先権を定める請求項１〜６のいずれか一項に記載のデコーダ（２０）。
8. 前記実施データ（５）は、オーバーレイの場合には前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つに適用される透過性効果を定める請求項７に記載のデコーダ（２０）。
9. 前記実施データ（５）によって、前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つの大きさを変更できる請求項１〜８のいずれか一項に記載のデコーダ（２０）。
10. 前記オーディオビデオ・コンテンツ（１）が暗号化の形式で受信される場合には、前記オーディオビデオ・コンテンツ（１）を解読するように構成される請求項１〜９のいずれか一項に記載のデコーダ（２０）。
11. オーディオビデオ・コンテンツ（１）及び少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム（４）からオーディオビデオ・データ（１８）をレンダリングするための方法であって、
    デコーダ（２０）によって、圧縮形態の前記オーディオビデオ・コンテンツ（１）を受信するステップと、
    前記デコーダ（２０）から、前記圧縮形態の前記オーディオビデオ・コンテンツ（１）、少なくとも一つのアプリケーションサービスに関する少なくとも一つのアプリケーションフレーム（４）、及び制御データ（７）を出力するステップと、
    を含む方法において、
    それは、識別データ（３）及び実施データ（５）を前記制御データ（７）に含むことを更に備え、
    前記識別データ（３）は、前記オーディオビデオ・コンテンツ（１）の少なくとも一部及び／又は前記少なくとも一つのアプリケーションフレーム（４）の一部を識別するために使われ、かつ
    前記実施データ（５）は、前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つのレンダリングを定める
    ことを特徴とする方法。
12. 前記制御データ（７）は、前記デコーダ（２０）により生成される請求項１１に記載の方法。
13. 前記少なくとも一つのアプリケーションフレーム（４）は、前記デコーダ（２０）の外部のソースから前記デコーダ（２０）により受信される.請求項１１又は１２に記載の方法。
14. 前記少なくとも一つのアプリケーションフレーム（４）は、前記デコーダ（２０）により生成される請求項１１又は１２に記載の方法。
15. 前記少なくとも一つのアプリケーシフレーム（４）は、前記デコーダ（２０）から出力される前に前記デコーダ（２０）により圧縮される請求項１１〜１４のいずれか一項に記載の方法。
16. オーディオビデオ・コンテンツ（１）の少なくとも一部及び／又は少なくとも一つのアプリケーションフレーム（４）の一部を識別するために、圧縮オーディオビデオ・コンテンツ（１）、少なくとも一つのアプリケーションサービスに関する前記少なくとも一つのアプリケーションフレーム（４）、及び識別データ（３）からオーディオビデオ・データ（１８）をレンダリングするためのレンダリング装置（４０）であって、
    前記圧縮オーディオビデオ・コンテンツ（１）、前記少なくとも一つのアプリケーションフレーム（４）、及び前記識別データ（３）を受信するように構成される入力インタフェースと、
    少なくとも前記圧縮オーディオビデオ・コンテンツ（１）を圧縮解除するように構成される圧縮解除ユニット（４８）と、
    前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つを処理するように構成される制御ユニット（４４）と、
    を備えるレンダリング装置（４０）において、
    前記入力インタフェースは、前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つから前記オーディオビデオ・データ（１８）を得る方法を定める実施データ（５）を受信するように更に構成され、かつ
    前記制御ユニット（４４）は、前記識別データ（３）及び前記実施データ（５）に従って前記オーディオビデオ・コンテンツ（１）及び前記少なくとも一つのアプリケーションフレーム（４）の少なくとも一つを処理するように更に構成される
    ことを特徴とするレンダリング装置（４０）。

Images