JP6474835B2

JP6474835B2 - ハイブリッド放送サービスを処理する装置、及びハイブリッド放送サービスを処理する方法

Info

Publication number: JP6474835B2
Application number: JP2016569543A
Authority: JP
Inventors: チンウォンリ; ソンチュアン; セチンオ; キョンソムン; ウソクコ; ソンリョンホン; ソンリュルヤン
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-02-17
Filing date: 2015-02-17
Publication date: 2019-02-27
Anticipated expiration: 2035-02-17
Also published as: US20160352793A1; KR20160099096A; EP3108640A4; JP2017513414A; KR101829844B1; CN106105136B; CN106105136A; WO2015122747A1; EP3108640A1

Description

本発明は、ハイブリッド放送サービスを処理する装置、及びハイブリッド放送サービスを処理する方法に関する。

アナログ放送信号の送信が終了するに伴い、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてさらに多くの量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加え、様々なタイプの追加データをさらに含むことができる。

すなわち、デジタル放送システムは、高画質（ＨＤ；ｈｉｇｈｄｅｆｉｎｉｔｉｏｎ）映像、マルチチャネルオーディオ、及び様々な追加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ送信のためのデータ送信効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）及びモバイル受信装備を考慮したネットワーク柔軟性が改善される必要がある。

本発明の目的は、放送信号を送信して時間領域で２つ以上の異なる放送サービスを提供する放送送受信システムのデータをマルチプレクスし、同じＲＦ信号帯域幅を介してマルチプレクスされたデータを送信する装置及び方法、及びそれに対応する放送信号を受信する装置及び方法を提供することである。

本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して、コンポーネントによってサービスに対応するデータを分類し、各コンポーネントに対応するデータをデータパイプとして送信し、データを受信及び処理する方法を提供することである。

本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して、放送信号を提供するのに必要なシグナリング情報をシグナリングする方法を提供することである。

上記目的及び他の利点を達成するために、本発明は、ハイブリッド放送サービスを処理する方法を提供する。ハイブリッド放送サービスを処理する方法は、ハイブリッド放送サービスのための放送信号を受信するステップであって、前記放送信号は、シグナリング情報に関するアドレス情報を含む、ステップと、前記放送信号のシグナリング情報のためのリクエストを伝送するステップと、ユニキャスト方式、マルチキャスト方式及びｅＭＢＭＳ（ｅｖｏｌｖｅｄＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ）方式のいずれか１つを用いてモバイルブロードバンド又はブロードバンドチャネルを介してシグナリング情報を受信するステップとを含む。

本発明の他の態様に係るハイブリッド放送サービスを処理する方法は、ハイブリッド放送サービスのアプリケーションのシグナリング情報を受信するステップであって、前記シグナリング情報は、アプリケーション識別情報、アプリケーションバージョン情報及びアプリケーションアドレス情報を含む、ステップと、前記シグナリング情報を用いて前記アプリケーションを開始するステップと、前記アプリケーションのアップデート情報を受信するステップとを含む。

本発明は、各サービス又はサービスコンポーネントに対するＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅｓ）を制御するサービス特性に応じてデータを処理することによって、様々な放送サービスを提供することができる。

本発明は、同じＲＦ信号帯域幅を介して様々な放送サービスを送信することによって送信柔軟性を達成することができる。

本発明は、データ送信効率を改善し、ＭＩＭＯシステムを用いて放送信号の送受信のロバスト性を増加させることができる。

本発明によれば、モバイル受信装備又は室内環境においても誤りなしにデジタル放送信号を受信可能な放送信号送信及び受信方法及び装置を提供することができる。

本発明の追加の理解を提供するために含まれ、本出願の一部に含まれたり、その一部を構成する添付の図面は、本発明の実施例を示し、説明と共に本発明の原理を説明する。
本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。本発明の一実施例に係る入力フォーマッティングブロックを示す図である。本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。本発明の実施例に係るＢＩＣＭブロックを示す図である。本発明の他の実施例に係るＢＩＣＭブロックを示す図である。本発明の一実施例に係るフレームビルディングブロックを示す図である。本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。本発明の実施例によって未来の放送サービスのための放送信号を受信する装置の構造を示す図である。本発明の実施例に係るフレーム構造を示す図である。本発明の実施例に係るフレームのシグナリング階層構造を示す図である。本発明の実施例に係るプリアンブルシグナリングデータを示す図である。本発明の実施例に係るＰＬＳ１データを示す図である。本発明の実施例に係るＰＬＳ２データを示す図である。本発明の他の実施例に係るＰＬＳ２データを示す図である。本発明の実施例に係るフレームの論理構造を示す図である。本発明の実施例に係るＰＬＳマッピングを示す図である。本発明の実施例に係るＥＡＣマッピングを示す図である。本発明の実施例に係るＦＩＣマッピングを示す図である。本発明の実施例に係るＤＰのタイプを示す図である。本発明の実施例に係るＤＰマッピングを示す図である。本発明の実施例に係るＦＥＣ構造を示す図である。本発明の実施例に係るビットインターリービングを示す図である。本発明の実施例に係るセルワードデマルチプレクシングを示す図である。本発明の実施例に係る時間インターリービングを示す図である。本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。本発明の他の実施例に係るツイスト行−列ブロックインターリーバの動作を示す図である。本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向の読み取りパターンを示す図である。本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。実施例に係るネットワークトポロジ（ｎｅｔｗｏｒｋｔｏｐｏｌｏｇｙ）を示すブロック図である。実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。実施例に係るウォーターマークベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラム（ｌａｄｄｅｒｄｉａｇｒａｍ）である。実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す図である。実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。実施例に係るフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。実施例に係る質疑結果を含むＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキーマダイヤグラムを示す図である。実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。実施例に係る映像表示装置を示すブロック図である。実施例によってメインＡＶコンテンツの再生時間を付加サービスの再生時間と同期化する方法を示すフローチャートである。実施例によってメインＡＶコンテンツの再生時間を付加サービスの再生時間と同期化する方法を示す概念図である。他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。本発明の一実施例によってウォーターマーキング方式で伝達できるデータを示すダイヤグラムである。本発明の一実施例によってタイムスタンプタイプフィールドの値の意味を示すダイヤグラムである。本発明の一実施例によってＵＲＬプロトコルタイプフィールドの値の意味を示すダイヤグラムである。本発明の一実施例によってＵＲＬプロトコルタイプフィールドを処理するプロセスを示すフローチャートである。本発明の一実施例によってイベントフィールドの値の意味を示すダイヤグラムである。本発明の一実施例によって目的地タイプフィールドの値の意味を示す図である。本発明の実施例＃１によってＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃１によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。本発明の実施例＃２によってＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃２によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。本発明の実施例＃３によってＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃４によってＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃４によって第１ＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃４によって第２ＷＭに挿入されるデータの構造を示すダイヤグラムである。本発明の実施例＃４によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。フィンガープリンティング方式における本発明の一実施例に係るデータ構造を示す図である。フィンガープリンティング方式における本発明の一実施例に係るデータ構造を処理するプロセスを示すフローチャートである。本発明の一実施例に係る放送受信機を示す図である。本発明の一実施例に係るマルチキャスト環境でのＡＣＲ送受信システムを示す図である。本発明の一実施例に係るマルチキャスト環境でのＷＭを介したＡＣＲ送受信システムを示す図である。本発明の一実施例に係るマルチキャスト環境でのＦＰ方式を介したＡＣＲ送受信システムを示す図である。本発明の一実施例に係る受信機がマルチキャスト環境でＡＣＲスキーム（ＡＣＲｓｃｈｅｍｅ）を介して放送と関連するシグナリングを行うフローチャートを示す図である。本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す図である。本発明の他の実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す図である。本発明の一実施例に係るハイブリッド放送サービスを示す概念図である。本発明の他の実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す図である。本発明の実施例に係る次世代放送システム用プロトコルスタックを示す図である。本発明の実施例に係る伝送フレームを示す図である。本発明の他の実施例に係る伝送フレームを示す図である。本発明の実施例に係る伝送パケット（ＴＰ）及び放送システムのｎｅｔｗｏｒｋ_ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。本発明の実施例に係る放送サーバーと受信機を示す図である。本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ、及びサービスタイプ間の付加（ａｄｊｕｎｃｔ）サービス関係に加え、別個のサービスタイプを示す図である。本発明の実施例として、ＮＲＴコンテンツアイテムクラスとＮＲＴファイルクラスとの包含関係を示す図である。本発明の実施例に係るサービスタイプ及びコンポーネントタイプに基づいた属性を示すテーブルである。本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄＣｏｎｔｅｎｔに対する定義を示す図である。本発明の実施例として、ＣｏｍｐｌｅｘＡｕｄｉｏＣｏｍｐｏｎｅｎｔの例を示す図である。本発明の実施例に係るアプリケーションに関連した属性情報を示す図である。本発明の一実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。本発明の他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。本発明の更に他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。本発明の一実施例に係るハイブリッド放送サービスプロセッシングのフローチャートである。本発明の他の実施例に係るハイブリッド放送サービスプロセッシングのフローチャートである。

以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下に説明する詳細な説明は、本発明によって具現し得る実施例だけを示すよりは、本発明の例示的な実施例を説明するためのものである。次の詳細な説明は、本発明の完璧な理解を提供するために特定の詳細を含む。しかし、本発明は、このような特定の詳細なしに実行可能であるということは当業者にとって明白である。

本発明で使用されるほとんどの用語は、当該分野で広く使用されているものから選択されたが、一部の用語は出願人によって任意に選択されたものであり、その意味は、必要に応じて以下の説明で詳細に説明する。したがって、本発明は、単なる名称又は意味よりは、用語の意図された意味に基づいて理解されなければならない。

本発明は、未来の放送サービスのための放送信号を送受信する装置及び方法を提供する。本発明の実施例に係る未来の放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、ｎｏｎ−ＭＩＭＯ（ｍｕｌｔｉｐｌｅｉｎｐｕｔｍｕｌｔｉｐｌｅｏｕｔｐｕｔ）又はＭＩＭＯを介して未来の放送サービスのための放送信号を処理することができる。本発明の実施例に係るノンＭＩＭＯ方式は、ＭＩＳＯ（ｍｕｌｔｉｐｌｅｉｎｐｕｔｓｉｎｇｌｅｏｕｔｐｕｔ）方式、ＳＩＳＯ（ｓｉｎｇｌｅｉｎｐｕｔｓｉｎｇｌｅｏｕｔｐｕｔ）方式などを含むことができる。

ＭＩＳＯ又はＭＩＭＯが、説明の便宜上、以下で２つのアンテナを用いるが、本発明は、２つ以上のアンテナを用いるシステムにも適用可能である。

本発明は、特定の使用ケースのために要求される性能を取得しながら、受信機の複雑度を最小化するために、それぞれ最適化された３つの物理層（ＰＬ）プロファイル（ベース、ハンドヘルド及びアドバンスドプロファイル）を定義することができる。物理層（ＰＨＹ）プロファイルは、当該受信機が具現しなければならない全ての構成のサブセットである。

３つのＰＨＹプロファイルは、機能ブロックのほとんどを共有するが、特定のブロック及び／又はパラメータにおいて少し異なる。追加のＰＨＹプロファイルが未来に定義されてもよい。システムの進化のために、未来のプロファイルはまた、ＦＥＦ（ｆｕｔｕｒｅｅｘｔｅｎｓｉｏｎｆｒａｍｅ）を通じて単一のＲＦチャネル内の既存のプロファイルとマルチプレクスされてもよい。それぞれのＰＨＹプロファイルについての詳細は、以下で説明する。

１．ベースプロファイル
ベースプロファイルは、ループトップ（ｒｏｏｆ−ｔｏｐ）アンテナに通常接続される固定受信装置に対する主な使用ケースを示す。ベースプロファイルはまた、ある場所に運搬可能であるが、比較的停止された受信カテゴリーに属するポータブル装置を含む。ベースプロファイルの使用は、任意の改善された具現例によってハンドヘルド装置又は車両装置にまで拡張され得るが、これら使用ケースは、ベースプロファイル受信機動作に対しては期待されない。

受信のターゲットＳＮＲの範囲は、略１０〜２０ｄＢであり、これは、既存の放送システム（例えば、ＡＴＳＣＡ／５３）の１５ｄＢのＳＮＲの受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用するバッテリー動作ハンドヘルド装置の場合ほど重要ではない。ベースプロファイルに対する重要なシステムパラメータは、下記の表１に列挙される。

２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリーパワーで動作するハンドヘルド及び車両装置に使用されるように設計された。装置は、歩行者又は車両の速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現において非常に重要である。ハンドヘルドプロファイルのターゲットＳＮＲの範囲は、略０〜１０ｄＢであるが、さらに深い室内受信を対象とする場合、０ｄＢ未満に到達するように構成することができる。

低いＳＮＲ能力に加え、受信機の移動度によって誘発されたドップラー効果に対する弾力性は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なパラメータは、下記の表２に列挙される。

３．アドバンスドプロファイル
アドバンスドプロファイルは、より多くの具現複雑度を犠牲し、最も高いチャネル容量を提供する。このプロファイルはＭＩＭＯ送信及び受信の利用を要求し、ＵＨＤＴＶサービスは、このプロファイルが特別に設計されたターゲット使用ケースである。増加した容量はまた、与えられた帯域幅内で増加した数のサービス、例えば、ＳＤＴＶ又はＨＤＴＶサービスを許容するように使用され得る。

アドバンスドプロファイルのターゲットＳＮＲの範囲は、略２０〜３０ｄＢである。ＭＩＭＯ送信は、初期には既存の楕円偏波（ｅｌｌｉｐｔｉｃａｌｌｙ−ｐｏｌａｒｉｚｅｄ）送信装置を用いることができるが、未来にはフルパワー交差偏波送信（ｆｕｌｌ−ｐｏｗｅｒｃｒｏｓｓ−ｐｏｌａｒｉｚｅｄｔｒａｎｓｍｉｓｓｉｏｎ）へと拡張される。アドバンスドプロファイルに対する重要なシステムパラメータは、下記の表３に列挙される。

この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方のためのプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するのに用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルのためのアドバンスドプロファイルと、ＭＩＭＯを有するハンドヘルドプロファイルのためのアドバンスドプロファイルとに分離することができる。また、３つのプロファイルは、設計者の意図によって変更可能である。

次の用語及び定義が本発明に適用されてもよい。次の用語及び定義は、設計によって変更可能である。

補助ストリーム：まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンスであって、未来拡張のために又はブロードキャスターやネットワークオペレーターによる要求通りに使用されてもよい。

ベースデータパイプ：サービスシグナリングデータを伝達するデータパイプ

ベースバンドフレーム（又はＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディングプロセス（ＢＣＨ及びＬＤＰＣエンコーディング）への入力を形成するＫｂｃｈビットのセット

セル：ＯＦＤＭ送信の一つのキャリアによって伝達される変調値

コーディングブロック：ＰＬＳ１データのＬＤＰＣエンコーディングブロック又はＰＬＳ２データのＬＤＰＣエンコーディングブロックのうち１つ

データパイプ：サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は多数のサービス又はサービスコンポーネントを伝達することができる。

データパイプ単位：フレーム内のＤＰにデータセルを割り当てる基本単位

データシンボル：プリアンブルシンボルではないフレーム内のＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジシンボルはデータシンボルに含まれる。）

ＤＰ_ＩＤ：この８ビットフィールドは、ＳＹＳＴＥＭ_ＩＤによって識別されたシステム内のＤＰを固有に識別する。

ダミーセル：ＰＬＳシグナリング、ＤＰ又は補助ストリームに使用されずに残っている容量を満たすのに用いられる擬似ランダム値を伝達するセル

非常警戒チャネル（ｅｍｅｒｇｅｎｃｙａｌｅｒｔｃｈａｎｎｅｌ；ＥＡＳ）：ＥＡＳ情報データを伝達するフレームの一部

フレーム：プリアンブルで始まり、フレームエッジシンボルで終了する物理層時間スロット

フレーム受信ユニット：ＦＥＴを含む同一又は異なる物理層プロファイルに属するフレームセットであって、スーパーフレーム内で８回繰り返される。

高速情報チャネル：サービスと対応ベースＤＰとのマッピング情報を伝達するフレーム内の論理チャネル

ＦＥＣＢＬＯＣＫ：ＤＰデータのＬＤＰＣエンコーディングビットのセット

ＦＦＴサイズ：特定のモードに使用される公称ＦＦＴサイズであって、基本期間（ｅｌｅｍｅｎｔａｒｙｐｅｒｉｏｄ）（Ｔ）の周期で表現されるアクティブシンボル期間（Ｔｓ）と同一である。

フレームシグナリングシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄｉｎｔｅｒｖａｌ）及び分散型パイロットパターンの所定の組み合わせでフレームの開始時に使用されるさらに高いパイロット密度を有するＯＦＤＭシンボルであって、ＰＬＳデータの一部を伝達する。

フレームエッジシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄｉｎｔｅｒｖａｌ）及び分散型パイロットパターンの所定の組み合わせでフレームの終了時に使用されるさらに高いパイロット密度を有するＯＦＤＭシンボル

フレームグループ：スーパーフレーム内の同じＰＨＹプロファイルタイプを有する全てのフレームのセット

未来拡張フレーム：未来拡張のために使用できるスーパーフレーム内の物理層時間スロットであって、プリアンブルで始まる。

フューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ又は一般のストリームであり、出力がＲＦ信号である、提案された物理層放送システム

入力ストリーム：システムによってエンドユーザに伝達されるサービスのアンサンブルのためのデータのストリーム

正常データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除いたデータシンボル

ＰＨＹプロファイル：当該受信機が具現しなければならない全ての構成のサブセット

ＰＬＳ：ＰＳＬ１及びＰＬＳ２で構成された物理層シグナリングデータ

ＰＬＳ１：固定サイズ、コーディング及び変調を有するＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２をデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。

注（ｎｏｔｅ）：フレームグループのデュレーションのために、ＰＬＳ１データは一定に維持される。

ＰＬＳ２：ＦＳＳシンボルで送信されるＰＬＳデータの第２セットであって、システム及びＤＰに対するより細部的なＰＬＳデータを伝達する。

ＰＬＳ２動的データ：フレーム別に動的に変わり得るＰＬＳ２データ

ＰＬＳ２静的データ：フレームグループのデュレーションにおいて静的に維持されるＰＬＳ２データ

プリアンブルシグナリングデータ：プリアンブルシンボルによって伝達され、システムの基本モードを識別するのに使用されるシグナリングデータ

プリアンブルシンボル：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定長のパイロットシンボル

注：プリアンブルシンボルは、主に高速初期バンドスキャンのために使用され、システム信号、そのタイミング、周波数オフセット及びＦＦＴサイズを検出する。

未来使用のために予約：現在の文書では定義されないが、未来に定義され得る。

スーパーフレーム：８個のフレーム繰り返し単位のセット

時間インターリービングブロック（ＴＩブロック）：時間インターリーバメモリの一つの用途に対応する、時間インターリービングが行われるセルのセット

ＴＩグループ：特定のＤＰのための動的容量割り当てが行われる単位であって、整数、すなわち、動的に変化する数のＸＦＥＣＢＬＯＣＫで構成される。

注：ＴＩグループは、一つのフレームに直接マッピングされたり、多数のフレームにマッピングされてもよい。これは、一つ以上のＴＩブロックを含むことができる。

タイプ１のＤＰ：全てのＤＰがＴＤＭ方式でマッピングされるフレームのＤＰ

タイプ２のＤＰ：全てのＤＰがＦＤＭ方式でマッピングされるフレームのＤＰ

ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣＦＥＣＢＬＯＣＫの全てのビットを伝達するＮｃｅｌｌｓセルのセット

図１は、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。

本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、入力フォーマッティングブロック１０００、ＢＩＣＭ（ｂｉｔｉｎｔｅｒｌｅａｖｅｄｃｏｄｉｎｇ＆ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号を送信する装置の各モジュールの動作について、以下で説明する。

ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳはメイン入力フォーマットであり、他のストリームタイプは一般のストリームとして処理される。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する当該帯域幅のスケジューリング及び割り当てを制御する。一つ又は多数のＴＳストリーム、ＩＰストリーム及び／又は一般のストリームの入力が同時に許容される。

入力フォーマッティングブロック１０００は、各入力ストリームを一つ又は多数のデータパイプにデマルチプレクスし、独立したコーディング及び変調がデータパイプに適用される。データパイプ（ＤＰ）は、ロバスト性の制御のための基本単位であって、ＱｏＳに影響を与える。一つ又は多数のサービス又はサービスコンポーネントは、単一のＤＰによって伝達されてもよい。入力フォーマッティングブロック１０００の動作についての詳細は後述する。

データパイプは、サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は多数のサービス又はサービスコンポーネントを伝達することができる。

また、データパイプ単位は、フレーム内のＤＰにデータセルを割り当てる基本ユニットである。

ＢＩＣＭブロック１０１０において、パリティデータが誤り訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。シンボルは、当該ＤＰに使用される特定のインターリービング深さを横切ってインターリーブされる。アドバンスドプロファイルに対して、ＭＩＭＯエンコーディングがＢＩＣＭブロック１０１０で行われ、追加のデータ経路はＭＩＭＯ送信のための出力で加えられる。ＢＩＣＭブロック１０１０についての詳細は後述する。

フレームビルディングブロック１０２０は、入力ＤＰのデータセルをフレーム内のＯＦＤＭシンボルにマッピングすることができる。マッピングの後、周波数インターリービングは、周波数領域ダイバーシティに使用され、特に周波数選択フェージングチャネルを防止する。フレームビルディングブロック１０２０の動作についての詳細は後述する。

各フレームの先頭にプリアンブルを挿入した後、ＯＦＤＭ生成ブロック１０３０は、保護区間としてサイクリックプレフィックス（ｃｙｃｌｉｃｐｒｅｆｉｘ）を有する従来のＯＦＤＭ変調を適用することができる。アンテナ空間ダイバーシティのために、分散型ＭＩＳＯ方式が送信機に適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅｐｏｗｅｒｒｅｄｕｃｔｉｏｎ）方式が時間領域で行われる。柔軟なネットワークの計画のために、この提案は、様々なＦＦＴサイズ、保護区間の長さ及び当該パイロットパターンのセットを提供する。

シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層シグナリング情報を生成することができる。このシグナリング情報はまた、関心のあるサービスが受信側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の動作についての詳細は後述する。

図２、図３及び図４は、本発明の実施例に係る入力フォーマッティングブロック１０００を示す。各図面について説明する。

図２は、本発明の一実施例に係る入力フォーマッティングブロックを示す図である。図２は、入力信号が単一の入力ストリームであるときの入力フォーマッティングブロックを示す。

図２に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。

物理層への入力は、一つ又は多数のデータストリームで構成されてもよい。各データストリームは一つのＤＰによって伝達される。モード適応モジュールは、入力されるデータストリームをベースバンドフレーム（ＢＢＦ）のデータフィールドにスライスする。システムは、３つのタイプの入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、インターネットプロトコル（ＩＰ）及びＧＳ（ｇｅｎｅｒｉｃｓｔｒｅａｍ）をサポートする。ＭＰＥＧ２−ＴＳは、固定長（１８８バイト）のパケットに特性化され、第１バイトはシンク（ｓｙｎｃ）バイト（０ｘ４７）である。ＩＰストリームは、ＩＰパケットヘッダー内でシグナリングされる可変長のＩＰデータグラムパケットで構成される。システムは、ＩＰストリームのためのＩＰｖ４及びＩＰｖ６をサポートする。ＧＳは、カプセル化パケットヘッダー内でシグナリングされる可変長のパケット又は固定長のパケットで構成されてもよい。

（ａ）は、信号ＤＰのためのモード適応ブロック２０００及びストリーム適応ブロック２０１０を示し、（ｂ）は、ＰＬＳ信号を生成し、処理するＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。

入力ストリームスプリッタは、入力ＴＳ、ＩＰ、ＧＳストリームを多数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離する。モード適応モジュール２０００は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ及びＢＢフレームヘッダー挿入ブロックで構成される。

ＣＲＣエンコーダは、ユーザパケット（ＵＰ）レベル、すなわち、ＣＲＣ−８、ＣＲＣ−１６及びＣＲＣ−３２で誤り訂正のための３つのタイプのＣＲＣエンコーディングを提供する。計算されたＣＲＣバイトは、ＵＰの後に付加される。ＣＲＣ−８はＴＳストリームに使用され、ＣＲＣ−３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しない場合、提案されたＣＲＣエンコーディングが適用されなければならない。

ＢＢフレームスライサは、入力を内部論理ビットフォーマットにマッピングする。最初に受信されたビットはＭＢＳであるものと定義される。ＢＢフレームスライサは、利用可能なデータフィールドの容量と同じ多数の入力ビットを割り当てる。ＢＢＦペイロードと同じ多数の入力ビットを割り当てるために、ＵＰパケットストリームは、ＢＢＦのデータフィールドに合わせてスライスされる。

ＢＢフレームヘッダー挿入ブロックは、２バイトの固定長のＢＢＦヘッダーをＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）及びＲＦＵ（２ビット）で構成される。固定された２バイトのＢＢＦヘッダーに加え、ＢＢＦは、２バイトのＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。

ストリーム適応ブロック２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。

スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリーム適応への入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは“０”に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩが“１”に設定され、スタッフィングフィールドがＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。

ＢＢスクランブラは、エネルギー分散（ｅｎｅｒｇｙｄｉｓｐｅｒｓａｌ）のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同時に発生する。スクランブリングシーケンスは、フィードバックされたシフトレジスターによって生成される。

ＰＬＳ生成ブロック２０２０は、物理層シグナリング（ＰＬＳ）データを生成することができる。ＰＬＳは、受信機に物理層ＤＰをアクセスする手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。

ＰＬＳ１データは、固定サイズ、コーディング及び変調を有するフレーム内のＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２データをデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データは、フレームグループのデュレーションにおいて一定に維持される。

ＰＬＳ２データは、ＦＳＳシンボルで伝送されるＰＬＳデータの第２セットであって、システム及びＤＰに対するさらに詳細なＰＬＳデータを伝達する。ＰＬＳ２は、受信機に十分なデータを提供して所望のＤＰをデコードするパラメータを含む。ＰＬＳ２シグナリングはまた、２つのタイプのパラメータ、すなわち、ＰＬＳ２静的データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２動的データ（ＰＬＳ２−ＤＹＮデータ）で構成される。ＰＬＳ２静的データは、フレームグループのデュレーションで静的に残っているＰＬＳ２データであり、ＰＬＳ２動的データは、フレーム別に動的に変わり得るＰＬＳ２データである。

ＰＬＳデータについての詳細は後述する。

ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。

上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

図３は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。

図３に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。

図３は、入力信号が多数の入力ストリームに対応する場合、入力フォーマッティングブロックのモード適応ブロックを示す。

多数の入力ストリームを処理する入力フォーマッティングブロックのモード適応ブロックは、独立して多数の入力ストリームを処理することができる。

図３を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、入力ストリームスプリッタ３０００、入力ストリーム同期化器３０１０、補償遅延ブロック３０２０、ヌル（ｎｕｌｌ）パケット削除ブロック３０３０、ヘッダー圧縮ブロック３０４０、ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０及びＢＢフレームヘッダー挿入ブロック３０７０を含むことができる。モード適応ブロックの各ブロックについて、以下で説明する。

ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０及びＢＢフレームヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ及びＢＢヘッダー挿入ブロックに対応するので、その説明は省略する。

入力ストリームスプリッタ３０００は、入力ＴＳ、ＩＰ、ＧＳストリームを多数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離することができる。

入力ストリーム同期化器３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、任意の入力データフォーマットに対する一定のエンドツーエンド送信遅延及びＣＢＲ（ｃｏｎｓｔａｎｔｂｉｔｒａｔｅ）を保障する適切な手段を提供することができる。ＩＳＳＹは、常にＴＳを伝達する多数のＤＰの場合に使用され、選択的に、ＧＳストリームを伝達するＤＰに使用される。

補償遅延ブロック３０２０は、ＩＳＳＹ情報の挿入後に分離されたＴＳパケットストリームを遅延して、受信機内の追加のメモリを要求せずにＴＳパケット再結合メカニズムを許容することができる。

ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ使用される。任意のＴＳ入力ストリーム又は分離されたＴＳストリームは、ＣＢＲＴＳストリームにＶＢＲ（ｖａｒｉａｂｌｅｂｉｔ−ｒａｔｅ）サービスを収容するために存在する多数のヌルパケットを有することができる。この場合、不必要な送信オーバーヘッドを避けるために、ヌルパケットが識別され、送信されない。受信機において、除去されたヌルパケットは、送信時に挿入されたＤＮＰ（ｄｅｌｅｔｅｄｎｕｌｌ−ｐａｃｋｅｔ）カウンタを参照して元の正確な場所に再挿入されて、一定のビットレートを保障し、タイムスタンプ（ＰＣＲ）アップデートに対する必要性を避けることができる。

ヘッド圧縮ブロック３０４０は、パケットヘッダー圧縮を提供し、ＴＳ又はＩＰ入力ストリームに対する送信効率を増加させることができる。受信機が、ヘッダーの所定の部分に対する先験的な情報（ａｐｒｉｏｒｉｉｎｆｏｒｍａｔｉｏｎ）を有することができるため、この既知の情報は送信機で削除されてもよい。

伝送ストリームに対して、受信機は、シンク−バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有する。入力ＴＳストリームが一つのＰＩＤのみを有するコンテンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベース層、ＳＶＣエンハンスメント層、ＭＶＣベースビュー又はＭＶＣ従属ビュー）に対してのみ、ＴＳパケットヘッダー圧縮が（選択的に）伝送ストリームに適用されてもよい。入力ストリームがＩＰストリームである場合、ＩＰパケットヘッダー圧縮が選択的に使用される。

図４は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。

図４に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。

図４は、入力信号が多数の入力ストリームに対応する場合、入力フォーマッティングモジュールのストリーム適応ブロックを示す。

図４を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（ｉｎ−ｂａｎｄ）シグナリングブロック４０３０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラ４０６０を含むことができる。ストリーム適応ブロックのそれぞれのブロックについて、以下で説明する。

スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０及びＰＬＳスクランブラ４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラ、ＰＬＳ生成ブロック及びＰＬＳスクランブラに対応するので、その説明は省略する。

スケジューラ４０００は、それぞれのＤＰのＦＥＣＢＬＯＣＫの量から全体フレームにわたる全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含め、スケジューラは、ＰＬＳ２−ＤＹＮデータの値を生成し、これは、フレームのＦＳＳ内のインバンドシグナリング又はＰＬＳセルとして送信される。ＦＥＣＢＬＯＣＫ、ＥＡＣ及びＦＩＣについての詳細は後述する。

１フレーム遅延ブロック４０１０は、入力データを１送信フレームだけ遅延させ、次のフレームに関するスケジューリング情報が、ＤＰに挿入されるインバンドシグナリング情報に対する現フレームを介して送信されるようにすることができる。

インバンドシグナリングブロック４０３０は、ＰＬＳ２データの遅延されていない部分をフレームのＤＰに挿入することができる。

図５は、本発明の実施例に係るＢＩＣＭブロックを示す図である。

図５に示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。

上述したように、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。

ＱｏＳは、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置によって提供されるサービスの特性に依存するので、各サービスに対応するデータは、異なる方式で処理される必要がある。したがって、本発明の実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ及びＭＩＭＯ方式を、データ経路にそれぞれ対応するデータパイプに独立して適用することによって、それに入力されたＤＰを独立して処理することができる。結果的に、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、それぞれのＤＰを介して送信されるそれぞれのサービス又はサービスコンポーネントに対するＱｏＳを制御することができる。

（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。

ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロック及びアドバンスドプロファイルによって共有されたＢＩＣＭブロックは、各ＤＰを処理する複数の処理ブロックを含むことができる。

ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロック、及びアドバンスドプロファイルのためのＢＩＣＭブロックのそれぞれの処理ブロックについて、以下で説明する。

ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、ＳＳＤ（ｓｉｇｎａｌｓｐａｃｅｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、及び時間インターリーバ５０５０を含むことができる。

データＦＥＣエンコーダ５０１０は、入力ＢＢＦに対してＦＥＣエンコーディングを行ってアウターコーディング（ＢＣＨ）及びインナーコーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。アウターコーディングＢＣＨは、選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の動作についての詳細は後述する。

ビットインターリーバ５０２０は、データＦＥＣエンコーダ５０１０の出力をインターリーブし、効率的に実現可能な構造を提供しながら、ＬＤＰＣコード及び変調方式の組み合わせで最適化された性能を達成することができる。ビットインターリーバ５０２０の動作についての詳細は後述する。

コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイル内のビットインターリーバ５０２０からの各セルワード、及びアドバンスドプロファイル内のセルワードデマルチプレクサ５０１０−１からのセルワードを変調して、パワー正規化コンステレーションポイントを提供することができる。このコンステレーションマッピングは、ＤＰに対してのみ適用される。ＱＡＭ−１６及びＮＵＱが正方形（ｓｑｕａｒｅｓｈａｐｅｄ）であるが、ＮＵＣは任意の形状を有する。それぞれのコンステレーションが９０度の任意の倍数で回転すると、回転したコンステレーションは、正確に元のコンステレーションと重なる。この“回転−感覚（ｒｏｔａｔｉｏｎ−ｓｅｎｓｅ）”対称特性は、実数成分及び虚数成分の平均パワー及び容量が互いに同一になるようにする。ＮＵＱ及びＮＵＣは、各コードレートに対して特に定義され、使用される特定の一つが、ＰＬＳ２データで提出されたパラメータＤＰ_ＭＯＤによってシグナリングされる。

ＳＳＤエンコーディングブロック５０４０は、２（２Ｄ）、３（３Ｄ）及び４（４Ｄ）次元でセルをプリコーディングし、異なるフェージング条件下で受信ロバスト性を増加させることができる。

時間インターリーバ５０５０はＤＰレベルで動作することができる。時間インターリービング（ＴＩ）のパラメータは、各ＤＰに対して異なって設定されてもよい。時間インターリーバ５０５０の動作についての詳細は後述する。

アドバンスドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー及び時間インターリーバを含むことができる。しかし、処理ブロック５０００−１は、処理ブロック５０００と区別され、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含む。

また、処理ブロック５０００−１のデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー及び時間インターリーバの動作は、上述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０及び時間インターリーバ５０５０に対応するので、その説明は省略する。

セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのＤＰに使用され、単一のセルワードストリームをＭＩＭＯ処理のためのデュアルセルワードストリームに分離する。セルワードデマルチプレクサ５０１０−１の動作についての詳細は後述する。

ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化されている。ＭＩＭＯ技術は、容量を増加させる優れた方式であるが、チャネル特性に依存する。特に、ブロードキャスティングに対して、異なる信号伝搬特性により誘発された２つのアンテナ間の受信された信号パワーの差又はチャネルの強いＬＯＳ成分は、ＭＩＭＯから容量利得を得ることを困難にする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの１つの回転ベースのプリコーディング及び位相ランダム化を用いて、この問題を克服する。

ＭＩＭＯエンコーディングは、送信機及び受信機で少なくとも２つのアンテナを必要とする２Ｘ２ＭＩＭＯシステムを目的とすることができる。この提案で２つのＭＩＭＯエンコーディングモード、すなわち、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅｓｐａｔｉａｌｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅｆｕｌｌ−ｄｉｖｅｒｓｉｔｙｓｐａｔｉａｌｍｕｌｔｉｐｌｅｘｉｎｇ）が定義される。ＦＲ−ＳＭエンコーディングは、受信機側で比較的小さい複雑度の増加と共に容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側で大きい複雑度の増加と共に、容量増加及び追加のダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性構成に対する制限を有しない。

ＭＩＭＯ処理は、アドバンスドプロファイルフレームのために要求され得、これは、アドバンスドプロファイルフレーム内の全てのＤＰがＭＩＭＯエンコーダによって処理されることを意味する。ＭＩＭＯ処理はＤＰレベルで適用されてもよい。コンステレーションマッパー出力（ｃｏｎｓｔｅｌｌａｔｉｏｎｍａｐｐｅｒｏｕｔｐｕｔ）（ＮＵＱ）のペア（ｅ_1,i及びｅ_2,i）は、ＭＩＭＯエンコーダの入力に供給され得る。ＭＩＭＯエンコーダ出力のペア（ｇ_1,i及びｇ_2,i）は、それぞれのＴＸアンテナのＯＦＤＭシンボル（ｌ）及び同一のキャリア（ｋ）によって送信され得る。

図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す図である。

図６に示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。

図６は、物理層シグナリング（ＰＬＳ）、非常警戒チャネル（ＥＡＣ）及び高速情報チャネル（ＦＩＣ）の保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報を伝達するフレームの一部であり、ＦＩＣは、サービスと当該ベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャネルである。ＥＡＣ及びＦＩＣについての詳細は後述する。

図６を参照すると、ＰＬＳ、ＥＡＣ及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳＦＥＣエンコーダ６０００、ビットインターリーバ６０１０及びコンステレーションマッパー６０２０を含むことができる。

また、ＰＬＳＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック及びＬＤＰＣパリティパンクチャリングブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて、以下で説明する。

ＰＬＳＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。

スクランブラは、ＢＣＨエンコーディング及び短縮及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。

ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のために短縮されたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに対してアウターエンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ＬＤＰＣエンコーディングの前にゼロ挿入の出力ビットがパーミュート（ｐｅｒｍｕｔｅ）され得る。

ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロック（Ｃ_ldpc）を生成するために、パリティビット（Ｐ_ldpc）が、それぞれのゼロ挿入ＰＬＳ情報ブロック（Ｉ_ldpc）から組織的にエンコードされ、その後に付加される。

ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４の通りである。

ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。

ＰＬＳ１データの保護に短縮が適用されると、任意のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データの保護のために、ＰＬＳ２のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。これらのパンクチャされたビットは送信されない。

ビットインターリーバ６０１０は、それぞれ短縮及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブする。

コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。

図７は、本発明の一実施例に係るフレームビルディングブロックを示す図である。

図７に示されたフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の実施例に該当する。

図７を参照すると、フレームビルディングブロックは、遅延補償ブロック７０００、セルマッパー７０１０及び周波数インターリーバ７０２０を含むことができる。フレームビルディングブロックのそれぞれのブロックについて、以下で説明する。

遅延補償ブロック７０００は、データパイプと対応ＰＬＳデータとの間のタイミングを調節し、送信端で時間が共に合わせられるように保障することができる。ＰＬＳデータは、入力フォーマッティングブロック及びＢＩＣＭブロックによって誘発されたデータパイプの遅延を処理することによって、データパイプと同じ量だけ遅延する。ＢＩＣＭブロックの遅延は、主に時間インターリーバ５０５０に起因する。インバンドシグナリングデータが、次のＴＩグループの情報を伝達して、シグナリングされるＤＰよりも１フレームだけ先に伝達される。したがって、遅延補償ブロックはインバンドシグナリングデータを遅延させる。

セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルを、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、もしあれば、ＤＰ、ＰＬＳセル及びＥＡＣ／ＦＩＣセルのそれぞれに対してＴＩによって生成されたデータセルを、フレーム内のＯＦＤＭシンボルのそれぞれに対応するアクティブＯＦＤＭセルのアレイにマッピングすることである。サービスシグナリングデータ（ＰＳＩ（ｐｒｏｇｒａｍｓｐｅｃｉｆｉｃｉｎｆｏｒｍａｔｉｏｎ）／ＳＩ））は、データパイプによって個別的に収集されて伝送されてもよい。セルマッパーは、スケジューラによって生成された動的情報及びフレーム構造の構成によって動作する。フレームについての詳細は後述する。

周波数インターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシティを提供することができる。また、周波数インターリーバ７０２０は、異なるインターリービングシード（ｉｎｔｅｒｌｅａｖｉｎｇ−ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されるＯＦＤＭシンボルペアに対して動作し、単一のフレーム内の最大のインターリービング利得を得ることができる。周波数インターリーバ７０２０の動作についての詳細は後述する。

図８は、本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。

図８に示されたＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の実施例に該当する。

ＯＦＤＭ生成ブロックは、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、送信される時間領域信号を生成する。また、このブロックは、順次に保護区間を挿入し、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅｐｏｗｅｒｒａｔｉｏ）減少処理を適用して最終ＲＦ信号を生成する。

図８を参照すると、フレームビルディングブロックは、パイロット及び予約トーン挿入ブロック８０００、２Ｄ−ｅＳＦＮエンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅｆａｓｔＦｏｕｒｉｅｒｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、他のシステム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。フレームビルディングブロックのそれぞれのブロックについて、以下で説明する。

パイロット及び予約トーン挿入ブロック８０００は、パイロット及び予約トーンを挿入することができる。

ＯＦＤＭシンボル内の様々なセルは、パイロットとして知られた基準情報に変調され、パイロットは、受信機で先験的に知られた送信値を有する。パイロットセルの情報は、分散されたパイロット、繰り返しパイロット（ｃｏｎｔｉｎｕａｌｐｉｌｏｔ）、エッジパイロット、ＦＳＳ（ｆｒａｍｅｓｉｇｎａｌｉｎｇｓｙｍｂｏｌ）パイロット及びＦＥＳ（ｆｒａｍｅｅｄｇｅｓｙｍｂｏｌ）パイロットで構成される。それぞれのパイロットは、パイロットタイプ及びパイロットパターンに応じて特定のブーストパワーレベルで送信される。パイロット情報の値は、任意の与えられたシンボル上のそれぞれの送信されたキャリアに対して一連の値である基準シーケンスから導出される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定及び送信モード識別に使用することができ、また、位相雑音をフォロウする（ｆｏｌｌｏｗｉｎｇ）のに使用することができる。

基準シーケンスから取られた基準情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除いた全てのシンボルにおいて分散されたパイロットセルで送信される。繰り返しパイロットは、フレームの全てのシンボルに挿入される。繰り返しパイロットの数及び位置は、ＦＦＴサイズ及び分散されたパイロットパターンに依存する。エッジキャリアは、プリアンブルシンボルを除いた全てのシンボル内のエッジパイロットである。これらは、スペクトルのエッジまで周波数補間を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。これらは、フレームのエッジまで時間補間を許容するために挿入される。

本発明の実施例に係るシステムは、ＳＦＮネットワークをサポートし、分散型ＭＩＳＯ方式は、選択的に非常に堅固な送信モードをサポートするために使用される。２Ｄ−ｅＳＦＮは、多数のＴＸアンテナを用いる分散型ＭＩＳＯ方式であり、それぞれのＴＸアンテナは、ＳＦＮネットワーク内の異なる送信側に配置される。

２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために、２Ｄ−ｅＳＦＮ処理を行い、多数の送信機から送信された信号の位相を歪ませることができる。したがって、長時間の低いフラットフェージング又は深いフェージングによるバースト誤りを緩和することができる。

ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロットとして（又は予約トーンとして）指定されていないデータシンボル内の任意のセルは、周波数インターリーバからのデータセルのうち１つを伝達する。セルは、ＯＦＤＭキャリアにマッピングされる。

ＰＡＰＲ減少ブロック８０３０は、時間領域内の様々なＰＡＰＲ減少アルゴリズムを用いて、入力信号に対するＰＡＰＲ減少を行うことができる。

保護区間挿入ブロック８０４０は、保護区間を挿入することができ、プリアンブル挿入ブロック８０５０は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造についての詳細は後述する。他のシステム挿入ブロック８０６０は、時間領域で複数の放送送受信システムの信号をマルチプレクスして、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域幅で同時に送信され得る。この場合、２つ以上の異なる放送送受信システムは、異なる放送サービスを提供するシステムのことをいう。異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味し得る。それぞれの放送サービスと関連するデータは、異なるフレームを介して送信されてもよい。

ＤＡＣブロック８０７０は、入力デジタル信号をアナログ信号に変換し、アナログ信号を出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって多数の出力アンテナを介して送信されてもよい。本発明の実施例に係るＴＸアンテナは、垂直又は水平の極性（ｐｏｌａｒｉｔｙ）を有することができる。

図９は、本発明の実施例によって未来の放送サービスのための放送信号を受信する装置の構造を示す図である。

本発明の実施例によって未来の放送サービスのための放送信号を受信する装置は、図１を参照して説明した未来の放送サービスのために放送信号を送信する装置に対応し得る。

本発明の実施例によって未来の放送サービスのための放送信号を受信する装置は、同期化及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０及びシグナリングデコーディングモジュール９０４０を含むことができる。放送信号を受信する装置の各モジュールの動作について、以下で説明する。

同期化及び復調モジュール９０００は、ｍ個のＲｘアンテナを介して入力信号を受信し、放送信号を受信する装置に対応するシステムに対して信号検出及び同期化を行い、放送信号を送信する装置によって行われる手順の逆の手順に対応する復調を行うことができる。

フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが送信されるデータを抽出することができる。放送信号を送信する装置がインターリービングを行うと、フレームパーシングモジュール９０１０は、インターリービングの逆の手順に対応するデインターリービングを行うことができる。この場合、抽出される必要がある信号及びデータの位置は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードして、放送信号を送信する装置によって生成されたシグナリング情報を復元することによって得られる。

デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、送信効率のために適用されたマッピングに対してデマッピングを行い、デコーディングを通じて送信チャネルに対して生成された誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングに必要な送信パラメータを得ることができる。

出力プロセッサ９０３０は、放送信号を送信して送信効率を改善する装置によって適用される様々な圧縮／信号処理手順の逆の手順を行うことができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を得ることができる。出力プロセッサ９０３０の出力は、放送信号を送信する装置に入力される信号に対応し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及び一般のストリームであってもよい。

シグナリングデコーディングモジュール９０４０は、同期化及び復調モジュール９０００によって復調された信号からＰＬＳ情報を得ることができる。上述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０及び出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。

図１０は、本発明の実施例に係るフレーム構造を示す図である。

図１０は、スーパーフレーム内のフレームタイプ及びＦＲＵの例示的な構成を示す。（ａ）は、本発明の実施例に係るスーパーフレームを示し、（ｂ）は、本発明の実施例に係るＦＲＵ（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ）を示し、（ｃ）は、ＦＲＵ内の可変ＰＨＹプロファイルのフレームを示し、（ｄ）は、フレームの構造を示す。

スーパーフレームは、８個のＦＲＵで構成されてもよい。ＦＲＵは、フレームのＴＤＭのための基本マルチプレクシング単位であり、スーパーフレーム内で８回繰り返される。

ＦＲＵ内の各フレームは、ＰＨＹプロファイル（ベース、ハンドヘルド、アドバンスド）又はＦＥＴのうちの１つに属する。ＦＲＵ内のフレームの最大許容数は４であり、与えられたＰＨＹプロファイルは、ＦＲＵ（例えば、ベース、ベース、ハンドヘルド、アドバンスド）において０倍〜４倍までの任意の回数だけ現れることができる。ＰＨＹプロファイルの定義は、必要であれば、プリアンブル内のＰＨＹ_ＰＲＯＦＩＬＥの予約値を用いて拡張可能である。

ＦＥＴ部分は、含まれる場合、ＦＲＵの終わりに挿入される。ＦＥＴがＦＲＵに含まれる場合、スーパーフレームにおいてＦＥＴの最小数は８である。ＦＥＴ部分が互いに隣接することは推奨されない。

一つのフレームはまた、多数のＯＦＤＭシンボルとプリアンブルに分離される。（ｄ）に示されたように、フレームは、プリアンブル、一つ以上のフレームシグナリングシンボル（ＦＳＳ）、正常データシンボル及びフレームエッジシンボル（ＦＥＳ）を含む。

プリアンブルは、高速フューチャーキャストＵＴＢシステム信号検出が可能であり、信号の効率的な送受信のための基本送信パラメータのセットを提供する特殊シンボルである。プリアンブルについての詳細は後述する。

ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化、チャネル推定及びＰＬＳデータの高速デコーディングのために、ＦＳＳは、正常データシンボルよりもさらに密集したパイロットパターンを有する。ＦＥＳは、正確にＦＳＳと同じパイロットを有し、これは、ＦＥＳ直前のシンボルに対して外挿せずに、ＦＥＳ内の周波数専用補間及び時間補間を可能にする。

図１１は、本発明の実施例に係るフレームのシグナリング階層構造を示す図である。

図１１は、３つの主要部分、すなわち、プリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０及びＰＬＳ２データ１１０２０に分離されたシグナリング階層構造を示す。全てのフレームにおいてプリアンブルシンボルによって伝達されるプリアンブルの目的は、そのフレームの送信タイプ及び基本送信パラメータを指示することである。ＰＬＳ１は、受信機がＰＬＳ２データをアクセス及びデコードするようにし、これは、関心のあるＤＰをアクセスするパラメータを含む。ＰＬＳ２は、全てのフレームにおいて伝達され、２つの主要部分、すなわち、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータに分離される。ＰＬＳ２データの静的及び動的部分は、必要であれば、パディングが後続する。

図１２は、本発明の実施例に係るプリアンブルシグナリングデータを示す図である。

プリアンブルシグナリングデータは、フレーム構造内で受信機がＰＬＳデータをアクセスし、ＤＰをトレースするようにするために必要な情報の２１ビットを伝達する。プリアンブルシグナリングについての詳細は、次の通りである。

ＰＨＹ_ＰＲＯＦＩＬＥ：この３ビットフィールドは、現フレームのＰＨＹプロファイルタイプを示す。異なるＰＨＹプロファイルタイプのマッピングは、下記の表５に与えられる。

ＦＦＴ_ＳＩＺＥ：この２ビットフィールドは、下記の表６に記載されたように、フレームグループ内の現フレームのＦＦＴサイズを示す。

ＧＩ_ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、下記の表７に記載されたように、現スーパーフレーム内の保護区間分数（ｆｒａｃｔｉｏｎ）値を示す。

ＥＡＣ_ＦＬＡＧ：この１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。このフィールドが“１”に設定されると、ＥＡＳ（ｅｍｅｒｇｅｎｃｙａｌｅｒｔｓｅｒｖｉｃｅ）が現フレームで提供される。このフィールドが“０”に設定されると、ＥＡＳが現フレームで伝達されない。このフィールドは、スーパーフレーム内で動的にスイッチングされ得る。

ＰＩＬＯＴ_ＭＯＤＥ：この１ビットフィールドは、プロファイルモードが現フレームグループ内の現フレームに対してモバイルモードであるか、又は固定モードであるかを示す。このフィールドが“０”に設定されると、モバイルパイロットモードが使用される。このフィールドが“１”に設定されると、固定パイロットモードが使用される。

ＰＡＰＲ_ＦＬＡＧ：この１ビットフィールドは、ＰＡＰＲ減少が現フレームグループ内の現フレームに使用されるか否かを示す。このフィールドが“１”に設定されると、ＰＡＰＲ減少にトーン予約（ｔｏｎｅｒｅｓｅｒｖａｔｉｏｎ）が使用される。このフィールドが“０”に設定されると、ＰＡＰＲ減少が使用されない。

ＦＲＵ_ＣＯＮＦＩＧＵＲＥ：この３ビットフィールドは、現スーパーフレーム内に存在するＦＲＵ（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ）のＰＨＹプロファイルタイプ構成を示す。現スーパーフレームで伝達される全てのプロファイルタイプは、現スーパーフレーム内の全てのフレーム内のこのフィールドで識別される。３ビットフィールドは、下記の表８に示されたように、各プロファイルに対する異なる定義を有する。

ＲＥＳＥＲＶＥＤ：この７ビットフィールドが、未来の使用のために予約される。

図１３は、本発明の実施例に係るＰＬＳ１データを示す図である。

ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするのに必要なパラメータを含む基本送信パラメータを提供する。上述したように、ＰＬＳ１データは、一つのフレームグループの全デュレーションにおいて変更されない。ＰＬＳ１データのシグナリングフィールドの詳細な定義は、次の通りである。

ＰＲＥＡＭＢＬＥ_ＤＡＴＡ：この２０ビットフィールドは、ＥＡＣ_ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。

ＮＵＭ_ＦＲＡＭＥ_ＦＲＵ：この２ビットフィールドは、ＦＲＵ当たりのフレームの数を示す。

ＰＡＹＬＯＡＤ_ＴＹＰＥ：この３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ_ＴＹＰＥは、表９に示されたようにシグナリングされる。

ＮＵＭ_ＦＳＳ：この２ビットフィールドは、現フレーム内のＦＳＳシンボルの数を示す。

ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮ：この８ビットフィールドは、送信された信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮは、２つの４ビットフィールド、すなわちメジャーバージョンとマイナーバージョンに分離される。

メジャーバージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮフィールドのＭＳＢ４ビットは、メジャーバージョン情報を示す。メジャーバージョンフィールドの変化は、非−下位−互換（ｎｏｎ−ｂａｃｋｗａｒｄ−ｃｏｍｐａｔｉｂｌｅ）変化を示す。デフォルト値は“００００”である。この標準に記載されたバージョンにおいて、値は“００００”に設定される。

マイナーバージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮのＬＳＢ４ビットは、マイナーバージョン情報を示す。マイナーバージョンフィールドの変化は下位互換性である。

ＣＥＬＬ_ＩＤ：これは、ＡＴＳＣネットワークで地理的なセルを固有に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジ領域は、フューチャーキャストＵＴＢシステムに使用される周波数の数に依存し、一つ以上の周波数で構成されてもよい。ＣＥＬＬ_ＩＤの値が知られていないか、又は特定されない場合、このフィールドは“０”に設定される。

ＮＥＴＷＯＲＫ_ＩＤ：これは、現在のＡＴＳＣネットワークを固有に識別する１６ビットフィールドである。

ＳＹＳＴＥＭ_ＩＤ：この１６ビットフィールドは、ＡＴＳＣネットワーク内のフューチャーキャストＵＴＢシステムを固有に識別する。フューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である、地上波放送システムである。フューチャーキャストＵＴＢシステムは、もしあれば、一つ以上のＰＨＹプロファイル及びＦＥＴを伝達する。同じフューチャーキャストＵＴＢシステムは、異なる入力ストリームを伝達することができ、異なる地理的領域で異なるＲＦ周波数を使用してローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての送信に対して同一である。一つ以上のフューチャーキャストＵＴＢシステムは、いずれも同一の物理層構造及び構成を有するということを意味する同一のＳＹＳＴＥＭ_ＩＤを有することができる。

次のループは、各フレームタイプのＦＲＵ構成及び長さを示すのに使用されるＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ、ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ、ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ及びＲＥＳＥＲＶＥＤで構成される。ループサイズは固定され、４個のＰＨＹプロファイル（ＦＥＴを含む）がＦＲＵ内でシグナリングされる。ＮＵＭ_ＦＲＡＭＥ_ＦＲＵが４よりも小さいと、使用されていないフィールドはゼロで埋められる。

ＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ：この３ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目（ｉはループインデックスである）のフレームのＰＨＹプロファイルタイプを示す。このフィールドは、表８に示されたように、同じシグナリングフォーマットを使用する。

ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ：この２ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮと共にＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨを用いて、フレームデュレーションの正確な値を得ることができる。

ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目のフレームの保護区間分数値を示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮは、表７に従ってシグナリングされる。

ＲＥＳＥＲＶＥＤ：この４ビットフィールドは、未来の使用のために予約される。

次のフィールドは、ＰＬＳ２データをデコードするパラメータを提供する。

ＰＬＳ２_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、ＰＬＳ２保護によって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナリングされる。ＬＤＰＣコードについての詳細は後述する。

ＰＬＳ２_ＭＯＤ：この３ビットフィールドは、ＰＬＳ２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。

ＰＬＳ２_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌｃｏｄｅｄｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃ_{total_partial_block}）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。

ＰＬＳ２_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのビットサイズを示す。この値は、現フレームグループの全デュレーションにおいて一定である。

ＰＬＳ２_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのビットサイズを示す。この値は、現フレームグループの全デュレーションにおいて一定である。

ＰＬＳ２_ＲＥＰ_ＦＬＡＧ：この１ビットフラグは、現フレームグループでＰＬＳ２繰り返しモードが使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＰＬＳ２繰り返しモードが活性化される。このフィールドの値が“０”に設定されると、ＰＬＳ２繰り返しモードが非活性化される。

ＰＬＳ２_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２繰り返しが使用されるとき、現フレームグループの全てのフレームで伝達されるＰＬＳ２に対する部分コーディングブロック（ｐａｒｔｉａｌｃｏｄｅｄｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃｔｏｔａｌ_ｐａｒｔｉａｌ_ｂｌｏｃｋ）を示す。繰り返しが使用されないと、このフィールドの値は０と同一である。この値は、現フレームグループの全デュレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナリングされる。

ＰＬＳ２_ＮＥＸＴ_ＭＯＤ：この３ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＦＬＡＧ：この１ビットフィールドは、次のフレームグループでＰＬＳ２繰り返しモードが使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＰＬＳ２繰り返しモードが活性化される。このフィールドの値が“０”に設定されると、ＰＬＳ２繰り返しモードが非活性化される。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２繰り返しが使用されるとき、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌｃｏｄｅｄｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃ_{total_partial_block}）を示す。次のフレームグループで繰り返しが使用されないと、このフィールドの値は０と同一である。この値は、現フレームグループの全デューレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのビットサイズを示す。この値は、現フレームグループにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのビットサイズを示す。この値は、現フレームグループにおいて一定である。

ＰＬＳ２_ＡＰ_ＭＯＤＥ：この２ビットフィールドは、現フレームグループ内のＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デュレーションにおいて一定である。下記の表１２は、このフィールドの値を示す。このフィールドが“００”に設定されると、現フレームでＰＬＳ２に対して追加のパリティが使用されない。

ＰＬＳ２_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。

ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＭＯＤＥ：この２ビットフィールドは、次のフレームグループでＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デュレーションにおいて一定である。表１２は、このフィールドの値を定義する。

ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、次のフレームグループの全てのフレームでＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。

ＲＥＳＥＲＶＥＤ：この３２ビットフィールドは、未来の使用のために予約される。

ＣＲＣ_３２：全ＰＬＳ１シグナリングに適用される３２ビットの誤り検出コード

図１４は、本発明の実施例に係るＰＬＳ２データを示す図である。

図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは、現フレームに特定された情報を提供する。

ＰＬＳ２−ＳＴＡＴデータのフィールドについての詳細は、次の通りである。

ＦＩＣ_ＦＬＡＧ：この１ビットフィールドは、ＦＩＣが現フレームグループに使用されるか否かを示す。このフィールドが“１”に設定されると、ＦＩＣが現フレームで提供される。このフィールドが“０”に設定されると、ＦＩＣが現フレームで伝達されない。この値は、現フレームグループの全デュレーションにおいて一定である。

ＡＵＸ_ＦＬＡＧ：この１ビットフィールドは、現フレームグループで補助ストリームが使用されるか否かを示す。このフィールドが“１”に設定されると、補助ストリームが現フレームで提供される。このフィールドが“０”に設定されると、補助ストリームが現フレームで伝達されない。この値は、現フレームグループの全デュレーションにおいて一定である。

ＮＵＭ_ＤＰ：この６ビットフィールドは、現フレームで伝達されるＤＰの数を示す。このフィールドの値は１〜６４の範囲内にあり、ＤＰの数は、ＮＵＭ_ＤＰ＋１である。

ＤＰ_ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内でＤＰを固有に識別する。

ＤＰ_ＴＹＰＥ：この３ビットフィールドはＤＰのタイプを示す。これは、下記の表１３に従ってシグナリングされる。

ＤＰ_ＧＲＯＵＰ_ＩＤ：この８ビットフィールドは、現ＤＰが関連しているＤＰグループを識別する。これは、受信機が特定のサービスと関連するサービスコンポーネントのＤＰをアクセスするのに使用することができ、これらＤＰは、同じＤＰ_ＧＲＯＵＰ_ＩＤを有する。

ＢＡＳＥ_ＤＰ_ＩＤ：この６ビットフィールドは、管理層で使用されるサービスシグナリングデータ（ＰＳＩ／ＳＩ）を伝達するＤＰを示す。ＢＡＳＥ_ＤＰ_ＩＤで指示されたＤＰは、サービスシグナリングデータのみを伝達する専用ＤＰ、又はサービスデータと共にサービスシグナリングデータを伝達する正常ＤＰであってもよい。

ＤＰ_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、関連するＤＰによって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナリングされる。

ＤＰ_ＣＯＤ：この４ビットフィールドは、関連するＤＰによって使用されるコードレートを示す。コードレートは、下記の表１５に従ってシグナリングされる。

ＤＰ_ＭＯＤ：この４ビットフィールドは、関連するＤＰによって使用される変調を示す。変調は、下記の表１６に従ってシグナリングされる。

ＤＰ_ＳＳＤ_ＦＬＡＧ：この１ビットフィールドは、ＳＳＤモードが関連するＤＰで使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＳＳＤが使用される。このフィールドの値が“０”に設定されると、ＳＳＤが使用されない。

ＰＨＹ_ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す“０１０”と同一である場合にのみ、次のフィールドが現れる。

ＤＰ_ＭＩＭＯ：この３ビットフィールドは、関連するＤＰにどのタイプのＭＩＭＯエンコーディングプロセスが適用されるかを示す。ＭＩＭＯエンコーディングプロセスのタイプは、表１７に従ってシグナリングされる。

ＤＰ_ＴＩ_ＴＹＰＥ：この１ビットフィールドは、時間インターリービングのタイプを示す。“０”の値は、一つのＴＩグループが一つのフレームに対応し、一つ以上のＴＩブロックを含むことを示す。“１”の値は、一つのＴＩグループが１よりも多いフレームで伝達され、一つのＴＩブロックのみを含むことを示す。

ＤＰ_ＴＩ_ＬＥＮＧＴＨ：２ビットフィールドの使用（許容される値が、単に１、２、４、８である）は、次のように、ＤＰ_ＴＩ_ＴＹＰＥフィールド内に設定された値によって決定される。

ＤＰ_ＴＩ_ＬＥＮＧＴＨの値が“１”に設定されると、このフィールドは、Ｐ_I、すなわち、各ＴＩグループがマッピングされるフレームの数を示し、ＴＩグループ当たり一つのＴＩブロックがある（Ｎ_TI＝１）。２ビットフィールドを有する許容されたＰ_Iの値は、下記の表１８で定義される。

ＤＰ_ＴＩ_ＴＹＰＥの値が“０”に設定されると、このフィールドは、ＴＩグループ当たりのＴＩブロックの数（Ｎ_TI）を示し、フレーム当たり一つのＴＩグループがある（Ｐ_I＝１）。２ビットフィールドを有する許容されたＰ_Iの値は、下記の表１８で定義される。

ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ：この２ビットフィールドは、関連するＤＰに対するフレームグループ内のフレーム区間（Ｉ_JUMP）を示し、許容される値は、１，２，４，８である（対応する２ビットフィールドは、それぞれ“００”，“０１”，“１０”，“１１”である）。フレームグループの全てのフレームで現れないＤＰに対して、このフィールドの値は、連続的なフレーム間の間隔と同一である。例えば、ＤＰがフレーム１，５，９，１３などで現れると、このフィールドは“４”に設定される。全てのフレームで現れるＤＰに対して、このフィールドは“１”に設定される。

ＤＰ_ＴＩ_ＢＹＰＡＳＳ：この１ビットフィールドは、時間インターリーバ５０５０の利用可能性を決定する。ＤＰに対して時間インターリービングが使用されないと、これは“１”に設定される。時間インターリービングが使用されると、これは“０”に設定される。

ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸ：この５ビットフィールドは、現ＤＰが発生するスーパーフレームの第１フレームのインデックスを示す。ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸの値は、０〜３１の範囲内にある。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸ：この１０ビットフィールドは、このＤＰに対してＤＰ_ＮＵＭ_ＢＬＯＣＫＳの最大値を示す。このフィールドの値は、ＤＰ_ＮＵＭ_ＢＬＯＣＫＳと同一の範囲を有する。

ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードデータのタイプを示す。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥは、下記の表１９に従ってシグナリングされる。

ＤＰ_ＩＮＢＡＮＤ_ＭＯＤＥ：この２ビットフィールドは、現ＤＰがインバンドシグナリング情報を伝達するか否かを示す。インバンドシグナリングタイプは、下記の表２０に従ってシグナリングされる。

ＤＰ_ＰＲＯＴＯＣＯＬ_ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードのプロトコルタイプを示す。入力ペイロードタイプが選択されると、下記の表２１に従ってシグナリングされる。

ＤＰ_ＣＲＣ_ＭＯＤＥ：この２ビットフィールドは、入力フォーマッティングブロックでＣＲＣエンコーディングが使用されるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナリングされる。

ＤＮＰ_ＭＯＤＥ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるヌルパケット削除モードを示す。ＤＮＰ_ＭＯＤＥは、下記の表２３に従ってシグナリングされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）でなければ、ＤＮＰ_ＭＯＤＥの値は“００”に設定される。

ＩＳＳＹ_ＭＯＤＥ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるＩＳＳＹモードを示す。ＩＳＳＹ_ＭＯＤＥは、下記の表２４に従ってシグナリングされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）でなければ、ＩＳＳＹ_ＭＯＤＥの値は“００”に設定される。

ＨＣ_ＭＯＤＥ_ＴＳ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるＴＳヘッダー圧縮モードを示す。ＨＣ_ＭＯＤ_ＴＳは、下記の表２５に従ってシグナリングされる。

ＨＣ_ＭＯＤＥ_ＩＰ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＩＰ（“０１”）に設定されるときのＩＰヘッダー圧縮モードを示す。ＨＣ_ＭＯＤ_ＩＰは、下記の表２６に従ってシグナリングされる。

ＰＩＤ：この１３ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定され、ＨＣ_ＭＯＤＥ_ＴＳが“０１”又は“１０”に設定されるときのＴＳヘッダー圧縮のためのＰＩＤ番号を示す。

ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために予約される。

ＦＩＣ_ＦＬＡＧが“１”と同一である場合にのみ、次のフィールドが現れる。

ＦＩＣ_ＶＥＲＳＩＯＮ：この８ビットフィールドは、ＦＩＣのバージョン番号を示す。

ＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：この１３ビットフィールドは、ＦＩＣのバイト長を示す。

ＡＵＸ_ＦＬＡＧが“１”と同一である場合にのみ、次のフィールドが現れる。

ＮＵＭ_ＡＵＸ：この４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを意味する。

ＡＵＸ_ＣＯＮＦＩＧ_ＲＦＵ：この８ビットフィールドは、未来の使用のために予約される。

ＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥ：この４ビットフィールドは、現在の補助ストリームのタイプを示すための未来の使用のために予約される。

ＡＵＸ_ＰＲＩＶＡＴＥ_ＣＯＮＦＩＧ：この２８ビットフィールドは、補助ストリームをシグナリングするための未来の使用のために予約される。

図１５は、本発明の他の実施例に係るＰＬＳ２データを示す図である。

図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮデータを示す。ＰＬＳ２−ＤＹＮデータの値は、一つのフレームグループのデュレーションで変わり得、フィールドのサイズは一定に維持される。

ＰＬＳ２−ＤＹＮデータのフィールドについての詳細は、次の通りである。

ＦＲＡＭＥ_ＩＮＤＥＸ：この５ビットフィールドは、スーパーフレーム内の現フレームのフレームインデックスを示す。スーパーフレームの第１フレームのインデックスは“０”に設定される。

ＰＬＳ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナリングされる値によって指示される。このフィールドの値が“００００”に設定されると、スケジューリングされた変化が予想されていないことを意味し、値“１”は、次のスーパーフレームで変化があることを意味する。

ＦＩＣ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成（すなわち、ＦＩＣの内容）が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナリングされる値によって指示される。このフィールドの値が“００００”に設定されると、スケジューリングされた変化が予想されていないことを意味し、値“０００１”は、次のスーパーフレームで変化があることを意味する。

ＲＥＳＥＲＶＥＤ：この１６ビットフィールドは、未来の使用のために予約される。

ＮＵＭ_ＤＰを通じてループで次のフィールドが現れ、これは、現フレームで伝達されるＤＰと関連するパラメータを示す。

ＤＰ_ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内のＤＰを固有に示す。

ＤＰ_ＳＴＡＲＴ：この１５ビット（又は１３ビット）フィールドは、ＤＰＵアドレッシング方式を用いて第１ＤＰの開始位置を示す。ＤＰ_ＳＴＡＲＴフィールドは、下記の表２７に示されたように、ＰＨＹプロファイル及びＦＦＴサイズに応じて異なる長さを有する。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ：この１０ビットフィールドは、現ＤＰに対する現ＴＩグループ内のＦＥＣブロックの数を示す。ＤＰ_ＮＵＭ_ＢＬＯＣＫの値は、０〜１０２３の範囲内にある。

次のフィールドは、ＥＡＣと関連するＦＩＣパラメータを示す。

ＥＡＣ_ＦＬＡＧ：この１ビットフィールドは、現フレーム内のＥＡＣの存在を示す。このビットは、プリアンブル内のＥＡＣ_ＦＬＡＧと同じ値である。

ＥＡＳ_ＷＡＫＥ_ＵＰ_ＶＥＲＳＩＯＮ_ＮＵＭ：この８ビットフィールドは、ウェークアップ指示のバージョン番号を示す。

ＥＡＣ_ＦＬＡＧフィールドが“１”と同一である場合、次の１２ビットは、ＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥフィールドに対して割り当てられる。ＥＡＣ_ＦＬＡＧフィールドが“０”と同一である場合、次の１２ビットはＥＡＣ_ＣＯＵＮＴＥＲに割り当てられる。

ＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：この１２ビットフィールドは、ＥＡＣのバイト長を示す。

ＥＡＣ_ＣＯＵＮＴＥＲ：この１２ビットフィールドは、ＥＡＣが到達するフレーム以前のフレームの数を示す。

ＡＵＸ_ＦＬＡＧフィールドが“１”と同一である場合にのみ、次のフィールドが現れる。

ＡＵＸ_ＰＲＩＶＡＴＥ_ＤＹＮ：この４８ビットフィールドは、補助ストリームをシグナリングするための未来使用のために予約される。このフィールドの意味は、構成可能なＰＬＳ２−ＳＴＡＴ内のＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥの値に依存する。

ＣＲＣ_３２：全ＰＬＳ２に適用される３２ビットの誤り検出コード。

図１６は、本発明の実施例に係るフレームの論理構造を示す図である。

上述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルは、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、まず、一つ以上のＦＳＳにマッピングされる。その後、もしあれば、ＥＡＣセルがＰＬＳフィールドの直後にマッピングされ、その後、もしあれば、ＦＩＣセルがマッピングされる。もしあれば、ＤＰは、ＰＬＳ又はＥＡＣ、ＦＩＣの後にマッピングされる。タイプ１ＤＰが先に後続し、その後、タイプ２ＤＰが後続する。ＤＰのタイプについての詳細は後述する。任意の場合、ＤＰは、ＥＡＳのための任意の特殊データ又はサービスシグナリングデータを伝達することができる。もしあれば、補助ストリーム又はストリームがＤＰに後続し、その後、ダミーセルが後続する。これらの全てを上述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーデータセルの順にマッピングすることは、フレーム内のセル容量を正確に満たす。

図１７は、本発明の実施例に係るＰＬＳマッピングを示す図である。

ＰＬＳセルは、ＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳによって占有されたセルの数に依存して、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数（Ｎ_FSS）は、ＰＬＳ１内のＮＵＭ_ＦＳＳによってシグナリングされる。ＦＳＳは、ＰＬＳセルを伝達する特殊シンボルである。ロバスト性及びレイテンシ（ｌａｔｅｎｃｙ）は、ＰＬＳの重要な問題であるため、ＦＳＳは、ＦＳＳ内の周波数専用補間及び高速同期化を許容する、さらに高い密度のパイロットを有する。

ＰＬＳセルは、図１７の例に示したように、トップ−ダウン（ｔｏｐ−ｄｏｗｎ）方式でＮ_FSS個のＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳ１セルは、セルインデックスの増加順に第１ＦＳＳの第１セルからまずマッピングされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後にマッピングされ、第１ＦＳＳの最後のセルインデックスまでマッピングが下向きに続けて行われる。要求されるＰＬＳセルの総数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは、次のＦＳＳに進行し、第１ＦＳＳと正確に同じ方式で続けて行われる。

ＰＬＳマッピングが完了した後、ＤＰが次に伝達される。ＥＡＣ、ＦＩＣ、又はＥＡＣ及びＦＩＣが現フレームに存在すると、これらはＰＬＳと“正常”ＤＰとの間に配置される。

図１８は、本発明の実施例に係るＥＡＣマッピングを示す図である。

ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するＤＰにリンクされる。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。存在するなら、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＥＡＣが、ＰＬＳセル以外に、ＦＩＣ、ＤＰ、補助ストリーム又はダミーセルのいずれかの後に位置しない。ＥＡＣセルをマッピングする手順は、ＰＬＳと正確に同一である。

ＥＡＣセルは、図１８に示されたように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＥＡＳメッセージのサイズに応じて、ＥＡＣセルは、図１８に示されたようにいくつかのシンボルを占有する。

ＥＡＣセルは、ＰＬＳ２の最後のセルの直後にマッピングされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＥＡＣの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは、次のシンボルに進行し、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは、正常データシンボルであり、これは、ＦＳＳよりもさらに多いアクティブキャリアを有する。

ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。（ＰＬＳ２フィールドでシグナリングされることによって）ＦＩＣが送信されないと、ＤＰは、ＥＡＣの最後のセルの直後にマッピングされる。

図１９は、本発明の実施例に係るＦＩＣマッピングを示す図である。

（ａ）は、ＥＡＣがないＦＩＣの例示的なマッピングを示し、（ｂ）は、ＥＡＣがあるＦＩＣの例示的なマッピングを示す。

ＦＩＣは、高速サービス取得及びチャネルスキャニングを可能にする階層間（ｃｒｏｓｓ−ｌａｙｅｒ）情報に対する専用チャネルである。この情報は、主に、各ブロードキャスターのＤＰとサービスとの間の情報を結合するチャネルを含む。高速スキャンのために、受信機は、ＦＩＣをデコードし、ブロードキャスターＩＤ、サービスの数及びＢＡＳＥ_ＤＰ_ＩＤなどの情報を得ることができる。高速サービス取得のために、ＦＩＣに加え、ベースＤＰがＢＡＳＥ_ＤＰ_ＩＤを用いてデコードされ得る。伝達される内容以外に、ベースＤＰは、正常ＤＰと正確に同じ方式でエンコードされ、フレームにマッピングされる。したがって、ベースＤＰについてさらなる説明が要求されない。ＦＩＣデータが生成されて管理層で消費される。ＦＩＣデータの内容は、管理層の説明書に記載された通りである。

ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２の静的部分内のＦＩＣ_ＦＬＡＧパラメータによってシグナリングされる。ＦＩＣが使用されると、ＦＩＣ_ＦＬＡＧが“１”に設定され、ＦＩＣのためのシグナリングフィールドはＰＬＳ２の静的部分に定義される。このフィールドでは、ＦＩＣ_ＶＥＲＳＩＯＮ及びＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥがシグナリングされる。ＦＩＣは、ＰＬＳ２と同じ変調、コーディング及び時間インターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２_ＭＯＤＥ及びＰＬＳ２_ＦＥＣなどの同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２、又は存在するなら、ＥＡＣの直後にマッピングされる。ＦＩＣは、任意の正常ＤＰ、補助ストリーム又はダミーセルの後にマッピングされない。ＦＩＣセルをマッピングする方法は、ＥＡＣと正確に同一であり、これはＰＬＳと同一である。

ＰＬＳ後にＥＡＣがない場合、ＦＩＣセルは、（ａ）の例に示したように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＦＩＣデータサイズに応じて、ＦＩＣセルは、（ｂ）に示したように、いくつかのシンボルにわたってマッピングされてもよい。

ＦＩＣセルは、ＰＬＳ２の最後のセルの直後にマッピングされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＦＩＣセルの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは、次のシンボルに進行し、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは、ＦＳＳよりさらに多いアクティブキャリアを有する正常データシンボルである。

ＥＡＳメッセージが現フレームで送信されると、ＥＡＣはＦＩＣに先行し、ＦＩＣセルは、（ｂ）に示したように、セルインデックスの増加順にＥＡＣの次のセルからマッピングされる。

ＦＩＣマッピングが完了した後、一つ以上のＤＰがマッピングされ、その後、存在するなら、補助ストリーム及びダミーセルがマッピングされる。

図２０は、本発明の実施例に係るＤＰのタイプを示す図である。

図２０の（ａ）はタイプ１ＤＰを示し、（ｂ）はタイプ２ＤＰを示す。

先行チャネル、すなわち、ＰＬＳ、ＥＡＣ及びＦＩＣがマッピングされた後、ＤＰのセルがマッピングされる。ＤＰは、マッピング方法によって２つのタイプのいずれかに分類される。

タイプ１ＤＰ：ＤＰは、ＴＤＭによってマッピングされる。

タイプ２ＤＰ：ＤＰは、ＦＤＭによってマッピングされる。

ＤＰのタイプは、ＰＬＳ２の静的部分でＤＰ_ＴＹＰＥフィールドによって指示される。図２０は、タイプ１ＤＰ及びタイプ２ＤＰのマッピング順序を示す。タイプ１ＤＰは、まず、セルインデックスの増加順にマッピングされ、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、ＤＰは、ｐ＝０からセルインデックスの増加順に続けてマッピングされる。一つのフレームで共にマッピングされる多数のＤＰで、タイプ１ＤＰのそれぞれは、ＤＰのＴＤＭマルチプレクシングと類似に、時間でグループ化される。

タイプ２ＤＰは、まず、シンボルインデックスの増加順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１の利用可能なシンボルに戻され、そのシンボルインデックスから増加する。一つのフレームで多数のＤＰを共にマッピングした後、タイプ２ＤＰのそれぞれは、ＤＰのＦＤＭマルチプレクシングと類似に、周波数でグループ化される。

一つの制限が必要であれば、すなわち、タイプ１ＤＰが常にタイプ２ＤＰに先行すると、タイプ１ＤＰ及びタイプ２ＤＰはフレーム内で共存することができる。タイプ１及びタイプ２ＤＰを伝達するＯＦＤＭセルの総数は、ＤＰの送信のために利用可能なＯＦＤＭセルの総数を超えてはならない。

ここで、Ｄ_DP1は、タイプ１ＤＰによって占有されるＯＦＤＭセルの数であり、Ｄ_DP2は、タイプ２ＤＰによって占有されるＯＦＤＭセルの数である。ＰＬＳ、ＥＡＣ、ＦＩＣは、いずれも、タイプ１ＤＰと同じ方式でマッピングされるため、これらはいずれも“タイプ１のマッピングルール”に従う。したがって、タイプ１のマッピングは、常にタイプ２のマッピングに先行する。

図２１は、本発明の実施例に係るＤＰマッピングを示す図である。

（ａ）は、タイプ１ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）は、タイプ２ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示す。

タイプ１ＤＰ（０，Ｄ_DP1−１）をマッピングするためのＯＦＤＭセルのアドレッシングは、タイプ１ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ１ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。

ＥＡＣ及びＦＩＣなしに、アドレス０は、最後のＦＳＳ内のＰＬＳを伝達する最後のセルの直後のセルのことを指す。ＥＡＣが送信され、ＦＩＣが当該フレームにないと、アドレス０は、ＥＡＣを伝達する最後のセルの直後のセルのことを指す。ＦＩＣが当該フレームで送信されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後のセルのことを指す。タイプ１ＤＰに対するアドレス０は、（ａ）に示されたように、２つの異なるケースを考慮して算出することができる。（ａ）に示された例において、ＰＬＳ、ＥＡＣ及びＦＩＣは全て送信されると仮定する。ＥＡＣ及びＦＩＣのいずれか１つ又は両方とも省略される場合への拡張は容易である。（ａ）の左側に示されたように、ＦＩＣまでの全てのセルをマッピングした後にＦＳＳ内に残っているセルがある場合。

タイプ２ＤＰ（０，…，Ｄ_DP2−１）をマッピングするＯＦＤＭセルのアドレッシングは、タイプ２ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ２ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。

（ｂ）に示されたように、３つの少し異なるケースが可能である。（ｂ）の左側上に示された第１のケースでは、最後のＦＳＳ内のセルは、タイプ２ＤＰマッピングに用いられる。中間に示された第２のケースでは、ＦＩＣが正常シンボルのセルを占めるが、そのシンボル上のＦＩＣセルの数はＣ_FSSよりも小さい。（ｂ）の右側に示された第３のケースは、そのシンボル上にマッピングされたＦＩＣセルの数がＣ_FSSを超えるということを除いて、第２のケースと同一である。

ＰＬＳ、ＥＡＣ及びＦＩＣは、タイプ１ＤＰと同じ“タイプ１のマッピング規則”に従うため、タイプ１ＤＰがタイプ２ＤＰに先行する場合への拡張は簡単である。

データパイプ単位（ＤＰＵ）は、データセルをフレーム内のＤＰに割り当てる基本単位である。

ＤＰＵは、フレーム内にＤＰを位置させるシグナリング単位として定義される。セルマッパー７０１０は、ＤＰのそれぞれに対するＴＩによって生成されたセルをマッピングすることができる。時間インターリーバ５０５０は、一連のＴＩブロックを出力し、それぞれのＴＩブロックは、セルのセットで構成される可変数（ｖａｒｉａｂｌｅｎｕｍｂｅｒ）のＸＦＥＣＢＬＯＣＫを含む。ＸＦＥＣＢＬＯＣＫ内のセルの数（Ｎ_cells）は、ＦＥＣＢＬＯＣＫサイズ（Ｎ_ldpc）及びコンステレーションシンボル当たりの送信ビット数に依存する。ＤＰＵは、与えられたＰＨＹプロファイルでサポートされるＸＦＥＣＢＬＯＣＫ内のセルの数の全ての可能な値の最大公約数（ｇｒｅａｔｅｓｔｃｏｍｍｏｎｄｉｖｉｓｏｒ）（Ｎ_cells）として定義される。セル内のＤＰＵの長さは、Ｌ_DPUと定義される。各ＰＨＹプロファイルがＦＥＣＢＬＯＣＫサイズ及びコンステレーションシンボル当たり異なる数の異なる組み合わせをサポートするため、Ｌ_DPUは、ＰＨＹプロファイルに基づいて定義される。

図２２は、本発明の実施例に係るＦＥＣ構造を示す図である。

図２２は、ビットインターリービングの前の本発明の実施例に係るＦＥＣ構造を示す。上述したように、データＦＥＣエンコーダは、入力ＢＢＦに対してＦＥＣエンコーディングを行ってアウターコーディング（ＢＣＨ）及びインナーコーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに対応する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに対応する同一の値を有する。

図２２に示されたように、ＢＣＨエンコーディングはそれぞれのＢＢＦ（Ｋ_bchビット）に適用され、ＬＤＰＣエンコーディングはＢＣＨエンコーディングＢＢＦ（Ｋ_ldpcビット＝Ｎ_bchビット）に適用される。

Ｎ_ldpcの値は、６４８００ビット（長いＦＥＣＢＬＯＣＫ）又は１６２００ビット（短いＦＥＣＢＬＯＣＫ）である。

下記の表２８及び表２９は、それぞれ長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するＦＥＣエンコーディングパラメータを示す。

ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの動作についての詳細は、次の通りである。

１２誤り訂正ＢＣＨコードは、ＢＢＦのアウターエンコーディングに使用される。短いＦＥＣＢＬＯＣＫ及び長いＦＥＣＢＬＯＣＫに対するＢＣＨ生成器多項式は、全ての多項式を共に乗算することによって得られる。

ＬＤＰＣコードは、アウターＢＣＨエンコーディングの出力をエンコードするのに使用される。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐ_ldpc（パリティビット）は、各Ｉ_ldpc（ＢＣＨエンコーディングＢＢＦ）から体系的にエンコードされ、Ｉ_ldpcに付加される。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）は、次の数式で表現される。

長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するパラメータは、それぞれ前記表２８及び表２９に与えられる。

長いＦＥＣＢＬＯＣＫに対するＮ_ldpc−Ｋ_ldpcを算出する細部手順は、次の通りである。

１）パリティビット初期化

２）パリティチェックマトリクスのアドレスの第１行に特定されたパリティビットアドレスで第１情報ビット（ｉ₀）を累算する。パリティチェックマトリクスのアドレスの細部事項は後述する。例えば、レート１３／１５に対して、

３）次の３５９個の情報ビット（ｉ_s）（ｓ＝１，２，…，３５９）が、次の式を用いてパリティビットで累算される。

ここで、ｘは、第１ビット（ｉ₀）に対応するパリティビット累算器のアドレスを示し、Ｑ_ldpcは、パリティチェックマトリクスのアドレスで特定されたコードレート従属定数である。継続して、例えば、レート１３／１５に対して、Ｑ_ldpc＝２４であり、したがって、情報ビット（ｉ₁）に対して、次の動作が行われる。

４）３６１番目の情報ビット（ｉ₃₆₀）に対して、パリティビット累算器のアドレスは、パリティチェックマトリクスのアドレスの第２行に与えられる。類似の方式で、次の３５８個の情報ビット（ｉ_s）（ｓ＝３６１，３６２，…，７１９）に対するパリティビット累算器のアドレスは、式６を用いて得られ、ここで、ｘは、情報ビット（ｉ₃₆₀）に対応するパリティビット累算器のアドレス、パリティチェックマトリクスのアドレスの第２行内のエントリを示す。

５）類似の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスのアドレスからの新しい行が、パリティビット累算器のアドレスを見つけるのに使用される。

全ての情報ビットが使い尽くされた後、最終パリティが次のように得られる。

６）ｉ＝１から始まる次の動作を順次行う。

ここで、ｐ_i（ｉ＝０，１，…，Ｎ_dpc−Ｋ_ldpc−１）の最終内容は、パリティビット（ｐ_i）と同一である。

短いＦＥＣＢＬＯＣＫに対するこのＬＤＰＣエンコーディング手順は、表３０及び表３１を代替し、長いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスを短いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスに代える以外は、長いＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順に従う。

図２３は、本発明の実施例に係るビットインターリービングを示す図である。

ＬＤＰＣエンコーダの出力はビットインターリーブされ、これは、パリティインターリービング及びその後のＱＣＢ（ｑｕａｓｉ−ｃｙｃｌｉｃｂｌｏｃｋ）インターリービング及び内部グループインターリービングで構成される。

（ａ）は、ＱＣＢインターリービングを示し、（ｂ）は、内部グループインターリービングを示す。

ＦＥＣＢＬＯＣＫは、パリティインターリーブされてもよい。パリティインターリービングの出力において、ＬＤＰＣコードワードは、長いＦＥＣＢＬＯＣＫ内の１８０個の隣接するＱＣブロック、及び短いＦＥＣＢＬＯＣＫ内の１８０個の隣接するＱＣブロックで構成される。長い又は短いＦＥＣＢＬＯＣＫ内のそれぞれのＱＣブロックは、３６０ビットで構成される。パリティインターリーブされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリーブされる。ＱＣＢインターリービングの単位はＱＣブロックである。パリティインターリービングの出力でのＱＣブロックは、図２３に示されたように、ＱＣＢインターリービングによってパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）され、ここで、ＦＥＣＢＬＯＣＫの長さに応じてＮ_cells＝６４８００／ηｍｏｄ又は１６２００／ηｍｏｄである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレートの各組み合わせに固有である。

ＱＣＢインターリービング後、内部グループインターリービングは、下記の表３２に定義された変調タイプ及び順序（ηｍｏｄ）によって行われる。一つの内部グループに対するＱＣブロックの数（Ｎ_{QCB_IG}）もまた定義される。

内部グループインターリービングプロセスは、ＱＣＢインターリービング出力のＮ_QCB-IG個のＱＣブロックで行われる。内部グループインターリービングは、３６０個の列とＮ_{QCB_IG}個の行を用いて内部グループのビットを書き込み及び読み取りするプロセスを有する。書き込み動作において、ＱＣＢインターリービング出力からのビットが行方向に書き込まれる。読み取り動作は列方向に行われて、各行からｍ個のビットを読み取り、ここで、ｍは、ＮＵＣに対して１と同一であり、ＮＣＱに対して２と同一である。

図２４は、本発明の実施例に係るセルワードデマルチプレクシングを示す図である。

（ａ）は、８及び１２ｂｐｃｕＭＩＭＯに対するセルワードデマルチプレクシングを示し、（ｂ）は、１０ｂｐｃｕＭＩＭＯに対するセルワードデマルチプレクシングを示す。

（ａ）に示されたように、ビットインターリービング出力の各セルワード（ｃ_0,l，ｃ_1,l，…，ｃ_ηmod-1,l）は、（ｄ_1,0,m，ｄ_1,1,m…，ｄ_1,ηmod-1,m）及び（ｄ_2,0,m，ｄ_2,1,m…，ｄ_2,ηmod-1,m）にデマルチプレクスされ、これは、一つのＸＦＥＣＢＬＯＣＫに対するセルワードデマルチプレクシングプロセスを示す。

ＭＩＭＯエンコーディングのための異なるタイプのＮＵＱを用いた１０ｂｐｃｕＭＩＭＯのケースに対して、ＮＵＱ−１０２４に対するビットインターリーバが再利用される。（ｂ）に示されたように、ビットインターリーバ出力の各セルワード（ｃ_0,l，ｃ_1,l，…，ｃ_9,l）は、（ｄ_1,0,m，ｄ_1,1,m…，ｄ_1,3,m）及び（ｄ_2,0,m，ｄ_2,1,m…，ｄ_2,5,m）にデマルチプレクスされる。

図２５は、本発明の実施例に係る時間インターリービングを示す図である。

（ａ）〜（ｃ）は、ＴＩモードの例を示す。

時間インターリーバは、ＤＰレベルで動作する。時間インターリービング（ＴＩ）のパラメータは、各ＤＰに対して異なって設定されてもよい。

ＰｌＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは、ＴＩを構成する。

ＤＰ_ＴＩ_ＴＹＰＥ（許容値：０又は１）：ＴＩモードを示す；“０”は、ＴＩグループ当たり多数のＴＩブロック（１より多いＴＩブロック）を有するモードを示す。この場合、一つのＴＩグループは、一つのフレームに直接マッピングされる（フレーム間インターリービングではない）。“１”は、ＴＩグループ当たり一つのＴＩブロックのみを有するモードを示す。この場合、ＴＩブロックは、１より多いフレームに拡散され得る（フレーム間インターリービング）。

ＤＰ_ＴＩ_ＬＥＮＧＴＨ：ＤＩ_ＴＩ_ＴＹＰＥ＝“０”であれば、このパラメータは、ＴＩグループ当たりのＴＩブロックの数（ＮＴＩ）である。ＤＰ_ＴＩ_ＴＹＰＥ＝“１”に対して、このパラメータは、一つのＴＩグループから拡散されたフレームの数（ＰＩ）である。

ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸ（許容値：０〜１０２３）：ＴＩグループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。

ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ（許容値：１，２，４，８）：与えられたＰＨＹプロファイルの同一のＤＰを伝達する２つの連続的なフレーム間のフレームの数（Ｉ_JUMP）を示す。

ＤＰ_ＴＩ_ＢＹＰＡＳＳ（許容値：０又は１）：時間インターリービングがＤＰに使用されないと、このパラメータは“１”に設定される。時間インターリービングが使用されると、“０”に設定される。

追加的に、ＰＬＳ２−ＤＹＮデータからのパラメータ（ＤＰ_ＮＵＭ_ＢＬＯＣＫ）は、ＤＰの一つのＴＩグループによって伝達されたＸＦＥＣＢＬＯＣＫの数を示すのに使用される。

時間インターリービングがＤＰに使用されないと、次のＴＩグループ、時間インターリービング動作及びＴＩモードは考慮されない。しかし、スケジューラからの動的構成情報に対する補償ブロックは、依然として必要である。各ＤＰにおいて、ＳＳＤ／ＭＩＭＯエンコーディングから受信されたＸＦＥＣＢＬＯＣＫは、ＴＩグループにグルーピングされる。すなわち、それぞれのＴＩグループは、整数の（ａｎｉｎｔｅｇｅｒｎｕｍｂｅｒｏｆ）ＸＦＥＣＢＬＯＣＫのセットであり、動的に可変する数のＸＦＥＣＢＬＯＣＫを含む。インデックスのＴＩグループ内のＸＦＥＣＢＬＯＣＫの数（ｎ）は、Ｎ_{xBLOCK_Group_}（ｎ）で表し、ＰＬＳ２−ＤＹＮデータのＤＰ_ＮＵＭ_ＢＬＯＣＫとしてシグナリングされる。Ｎ_{xBLOCK_Group_}（ｎ）は、０の最小値から最も大きい値が１０２３である最大値（Ｎ_{xBLOCK_Group_}ＭＡＸ）（ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸに対応）まで変化し得る。

各ＴＩグループは、一つのフレームに直接マッピングされたり、Ｐ_Iフレームにわたって拡散される。それぞれのＴＩグループはまた、１より多いＴＩブロック（Ｎ_TI）に分離され、それぞれのＴＩブロックは、時間インターリーバメモリの一つの用途に対応する。ＴＩグループ内のＴＩブロックは、少し異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。ＴＩグループが多数のＴＩブロックに分離されると、一つのフレームにのみ直接マッピングされる。下記の表３３に示すように（時間インターリービングをスキップする追加のオプションを除いて）時間インターリービングのための３つのオプションが存在する。

各ＤＰにおいて、ＴＩメモリは、入力ＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックからの出力ＸＦＥＣＢＬＯＣＫ）を格納する。入力ＸＦＥＣＢＬＯＣＫは、

として定義され、
ここで、ｄ_n,s,r,qは、ｎ番目のＴＩグループのｓ番目のＴＩブロック内のｒ番目のＸＦＥＣＢＬＯＣＫのｑ番目のセルであり、次のようにＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。

また、時間インターリーバからの出力ＸＦＥＣＢＬＯＣＫは、次のように定義されると仮定する。

一般に、時間インターリーバは、フレームビルディングプロセスの前にＤＰデータのためのバッファとして動作する。これは、それぞれのＤＰに対する２つのメモリバンクによって達成される。第１ＴＩブロックは第１バンクに書き込まれる。第１バンクが読み取られる間、第２ＴＩブロックが第２バンクに書き込まれる。

ＴＩは、ツイスト行−列ブロックインターリーバである。ｎ番目のＴＩグループのｓ番目のＴＩブロックに対して、ＴＩメモリの行（Ｎ_r）の数は、セルの数（Ｎ_cell）と同一である、すなわち、Ｎ_r＝Ｎ_cellであるが、列の数（Ｎ_c）は、数（Ｎ_{xBLOCK_TI}（ｎ，ｓ））と同一である。

図２６は、本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。

（ａ）は、時間インターリーバでの書き込み動作を示し、（ｂ）は、時間インターリーバでの読み取り動作を示す。（ａ）に示されたように、第１ＸＦＥＣＢＬＯＣＫは、ＴＩメモリの第１列に列方向に書き込まれ、第２ＸＦＥＣＢＬＯＣＫは、次の列に書き込まれる。その後、インターリービングアレイにおいて、セルは、対角線方向に読み取られる。第１行から（最左側列から始まって行に沿って右に）最後の行まで対角線方向の読み取りが行われる間、（ｂ）に示されたように、セルが読み取られる。具体的に、順次読み取られるＴＩメモリセルの位置として、Ｚ_n,s,i（ｉ＝０，...，Ｎ_r，Ｎ_c）を想定し、このようなインターリービングアレイでの読み取りプロセスは、次の式のように、行インデックス（Ｒ_n,s,i）、列インデックス（Ｃ_n,s,i）及び関連するツイストパラメータ（Ｔ_n,s,i）を算出することによって行われる。

ここで、Ｓ_shiftは、Ｎ_{xBLOCK_TI}（ｎ，ｓ）と関係なく対角線方向読み取りプロセスに対する共通シフト値であり、次の式のように、ＰＬＳ−ＳＴＡＴで与えられたＮ_{xBLOCK_TI_MAX}によって決定される。

結果的に、読み取られるセルの位置は、Ｚ_n,s,i＝Ｎ_rＣ_n,s,i＋Ｒ_n,s,iとして座標によって算出される。

図２７は、本発明の他の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。

特に、図２７は、Ｎ_{xBLOCK_TI}（０，０）＝３、Ｎ_{xBLOCK_TI}（１，０）＝６、Ｎ_{xBLOCK_TI}（２，０）＝５であるとき、仮想ＸＦＥＣＢＬＯＣＫを含め、各ＴＩグループに対するＴＩメモリ内のインターリービングアレイを示す。

可変数（Ｎ_{xBLOCK_TI}（ｎ，ｓ）＝Ｎ_r）は、Ｎ_{xBLOCK_TI_MAX}よりも小さいか、又は同一である。したがって、受信側で単一のメモリデインターリービングを達成するために、Ｎ_{xBLOCK_TI}（ｎ，ｓ）と関係なく、ツイスト行−列ブロックインターリーバに使用されるインターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをＴＩメモリに挿入することによってＮ_r×Ｎ_c＝Ｎ_cells×Ｎ_{xBLOCK_TI_MAX}のサイズに設定され、読み取りプロセスは、次の式で達成される。

ＴＩグループの数は３に設定される。時間インターリーバのオプションは、ＤＰ_ＴＩ_ＴＹＰＥ＝“０”、ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ＝“１”及びＤＰ_ＴＩ_ＬＥＮＧＴＨ＝“１”、すなわち、Ｎ_TI＝１、Ｉ_JUMP＝１及びＰ₁＝１によってＰＬＳ２−ＳＴＡＴデータでシグナリングされる。ＴＩグループ当たりのそれぞれがＮ_cells＝３０を有するＸＦＥＣＢＬＯＣＫの数は、それぞれＮ_{xBLOCK_TI}（０，０）＝３、Ｎ_{xBLOCK_TI}（１，０）＝６、Ｎ_{xBLOCK_TI}（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、Ｎ_{xBLOCK_Group_MAX}によってＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは、次のことを誘導する。

図２８は、本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。

特に、図２８は、Ｎ_{xBLOCK_TI_MAX}＝７及びＳ_shift＝（７−１）／２＝３のパラメータを有する各インターリービングアレイからの対角線方向読み取りパターンを示す。前記擬似コードとして示された読み取りプロセスにおいて、Ｖ_i×Ｎ_cellsＮ_{xBLOCK_TI}（ｎ，ｓ）であれば、Ｖ_iの値はスキップされ、Ｖ_iの次の算出値が使用される。

図２９は、本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。

図２９は、Ｎ_{xBLOCK_TI_MAX}＝７及びＳ_shift＝３のパラメータを有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。

以下、本発明に関連する移動端末機について、図面を参照してより詳細に説明する。以下の説明で使用される構成要素に対する接尾辞「エンジン」、「モジュール」及び「部」は、明細書作成の容易さのみが考慮されて付与又は混用されるものであって、それ自体で互いに区別される意味又は役割を有するものではない。

次は、図３０乃至図３８を参照して、本発明の一実施例に係るネットワークトポロジを説明する。

図３０は、本発明の一実施例に係るネットワークトポロジを示すブロック図である。

図３０に示したように、本発明の一実施例に係るネットワークトポロジは、コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、複数の付加サービス提供サーバー５０、放送受信装置６０、ネットワーク７０、映像表示装置１００を含む。

コンテンツ提供サーバー１０は、放送局などに該当し得、メイン視聴覚コンテンツ（ｍａｉｎａｕｄｉｏ−ｖｉｓｕａｌｃｏｎｔｅｎｔ）を含む放送信号を放送する。放送信号は、付加サービスをさらに含むことができる。付加サービスは、メイン視聴覚コンテンツと関連があってもよく、関連がなくてもよい。付加サービスは、サービス情報（ｓｅｒｖｉｃｅｉｎｆｏｒｍａｔｉｏｎ）、メタデータ（ｍｅｔａｄａｔａ）、付加データ、コンパイルされた実行ファイル、ウェブアプリケーション、ＨＴＭＬ（ＨｙｐｅｒｔｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）文書、ＸＭＬ文書、ＣＳＳ（ｃａｓｃａｄｉｎｇｓｔｙｌｅｓｈｅｅｔ）文書、オーディオファイル、ビデオファイル、ＡＴＳＣ２．０コンテンツ、ＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）のようなアドレスなどの形態を有することができる。一つ以上のコンテンツ提供サーバーが存在してもよい。

コンテンツ認識サービス提供サーバー２０は、映像表示装置１００がメイン視聴覚コンテンツに基づいてコンテンツを認識できるようにするコンテンツ認識サービスを提供する。コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに修正を加えてもよく、修正を加えなくてもよい。一つ以上のコンテンツ認識サービス提供サーバーが存在してもよい。

コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）を挿入するウォーターマークサーバーであってもよい。このウォーターマークサーバーは、メイン視聴覚コンテンツの各フレームの左側上端又は右側上端にコンテンツ提供者のロゴをウォーターマークすることができる。

また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにコンテンツ情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）として挿入するウォーターマークサーバーであってもよい。

また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツの一部のフレーム又は一部のオーディオサンプルから特徴情報を抽出して格納するフィンガープリントサーバーであってもよい。この特徴情報は、シグネチャーとも呼ばれる。

マルチチャネルビデオ分配サーバー３０は、複数の放送局から放送信号を受信し、多重化して、多重化された信号を放送受信装置６０に提供する。特に、マルチチャネルビデオ分配サーバー３０は、受信した放送信号に対して復調及びチャネル復号化を行ってメイン視聴覚コンテンツ及び付加サービスを抽出した後、抽出されたメイン視聴覚コンテンツ及び抽出した付加サービスに対してチャネル符号化を行い、分配のための多重化信号を生成することができる。このとき、マルチチャネルビデオ分配サーバー３０は、抽出した付加サービスを除外することもでき、他の付加サービスを追加することもできるため、放送局は、放送局主導のサービスを提供することができない。一つ以上のマルチチャネルビデオ分配サーバーが存在してもよい。

放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信した信号に対して復調及びチャネル復号を行ってメイン視聴覚コンテンツを抽出する。そして、放送受信装置６０は、抽出したメイン視聴覚コンテンツをＨ．２６４／ＭＰＥＧ−４ＡＶＣ（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ−４ａｄｖａｎｃｅｄｖｉｄｅｏｃｏｄｉｎｇ）、ＤｏｌｂｙＡＣ−３、ＭＰＥＧ−２ＡＡＣ（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ−２ＡｄｖａｎｃｅｄＡｕｄｉｏＣｏｄｉｎｇ）アルゴリズムなどを用いて復号して、非圧縮メイン視聴覚コンテンツ（ｕｎｃｏｍｐｒｅｓｓｅｄｍａｉｎＡＶｃｏｎｔｅｎｔ）を生成する。放送受信装置６０は、生成した非圧縮メイン視聴覚コンテンツを映像表示装置１００の外部入力ポートなどを介して映像表示装置１００に提供する。

付加サービス情報提供サーバー４０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツと関連する１つ以上の利用可能な付加サービスのための付加サービス情報を提供する。１つ以上の付加サービスアドレス提供サーバーが存在してもよい。付加サービス情報提供サーバー４０は、複数の利用可能な付加サービスのうち最も優先順位が高い付加サービスのための付加サービス情報を提供することもできる。

付加サービス提供サーバー５０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスを提供する。１つ以上の付加サービス提供サーバーが存在してもよい。

映像表示装置１００は、テレビ、ノートパソコン、携帯電話、スマートフォンなどのようにディスプレイ部を含む装置であってもよい。映像表示装置１００は、放送受信装置６０から非圧縮メイン視聴覚コンテンツを受信することもでき、コンテンツ提供サーバー１０又はマルチチャネルビデオ分配サーバー３０から符号化されたメイン視聴覚コンテンツを含む放送信号を受信することもできる。映像表示装置１００は、ネットワーク７０を介してコンテンツ認識サービス提供サーバー２０からコンテンツ認識サービスを受信することができ、ネットワーク７０を介して付加サービス情報提供サーバー４０からメイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスのアドレスを受信することができ、付加サービス提供サーバー５０からメイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスを受信することができる。

コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、及び複数の付加サービス提供サーバー５０のうち２つ以上は、一つのサーバーの形態で結合されてもよく、一つの事業者によって運営されてもよい。

図３１は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。

図３１に示したように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１をさらに含む。

図３１に示されたようなウォーターマークサーバー２１は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにコンテンツ情報を挿入する。マルチチャネルビデオ分配サーバー３０は、変形されたメイン視聴覚コンテンツを含む放送信号を受信して分配する。特に、ウォーターマークサーバーは、後述するようなデジタルウォーターマーキング技術を用いることができる。

デジタルウォーターマークは、削除しにくい方法でデジタル信号に情報を挿入するプロセスである。例えば、デジタル信号は、オーディオ、写真、又はビデオであってもよい。このデジタル信号がコピーされると、挿入された情報もまたコピーに含まれる。一つのデジタル信号が、同時に異なる複数個のウォーターマークを運搬することができる。

可視ウォーターマーキング（ｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋｉｎｇ）において、挿入される情報は、写真又はビデオで目で識別可能である。典型的に、挿入された情報は、メディアの所有者を識別するテキスト又はロゴである。テレビ放送局が自身のロゴを伝送されるビデオのコーナーに追加すると、これが、目で識別可能なウォーターマークである。

不可視ウォーターマーキング（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋｉｎｇ）において、情報は、デジタルデータとしてオーディオ、写真、又はビデオに追加されるが、一定量の情報が隠されているという事実は感知できるとしても、そのような情報は認知することができない。このような目で識別不可能なウォーターマーキングを介して秘密メッセージが伝達されることもできる。

ウォーターマーキングの一つの応用は、デジタルメディアの不法コピーを防止するための著作権保護システムにある。例えば、コピー装置は、デジタルメディアのコピーの前にデジタルメディアからウォーターマークを得、ウォーターマークの内容に基づいてコピーをするか否かを決定することができる。

ウォーターマーキングの他の応用は、デジタルメディアの出処追跡にある。配布経路上の各地点でウォーターマークがデジタルメディアに埋め込まれる。後でこのようなデジタルメディアが発見される場合、このデジタルメディアからウォーターマークが抽出され、ウォーターマークの内容から配布の出処を把握することができる。

デジタルメディアに対する説明が、不可視ウォーターマーキングの更に他の応用である。

デジタルメディアのためのファイルフォーマットがメタデータと呼ばれる追加的な情報を含むことができ、デジタルウォーターマークは、デジタルメディアの視聴覚信号自体で伝達されるという点からメタデータとは区別される。

ウォーターマーキング方法としては、スプレッドスペクトル、量子化、アンプリチュード変調がある。

マーキングされる信号が追加的な修正によって得られる場合、ウォーターマーキング方法はスプレッドスペクトルに該当する。スプレッドスペクトルウォーターマークは、非常に強靭であると知られているが、ウォーターマークが埋め込まれるホスト信号に干渉を与えるため、多くの情報を含めることはできない。

マーキングされる信号が量子化によって得られる場合、ウォーターマーキング方法は量子化タイプに該当する。量子化ウォーターマークは、強靭性は低いが、かなり多くの情報を含めることができる。

マーキングされる信号が空間領域でスプレッドスペクトルと類似の追加修正方法で得られる場合、ウォーターマーキング方法はアンプリチュード変調に該当する。

図３２は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。

まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ１０１）。

ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）を挿入したり、又はメイン視聴覚コンテンツにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）として挿入し、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスをＭＶＰＤ３０に提供する（Ｓ１０３）。

不可視ウォーターマークを介して挿入されるウォーターマーク情報は、ウォーターマークの用途、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。ウォーターマークの用途は、無断コピーの防止、視聴率の調査、付加サービスの取得のうち１つを示すことができる。

コンテンツ情報は、メイン視聴覚コンテンツを提供するコンテンツ提供者の識別情報、メイン視聴覚コンテンツ識別情報、メイン視聴覚コンテンツ等級情報、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報、メイン視聴覚コンテンツが放送されるチャネルの名、メイン視聴覚コンテンツが放送されるチャネルのロゴ、メイン視聴覚コンテンツが放送されるチャネルの説明、利用情報報告アドレス、利用情報報告周期、利用情報取得のための最小利用時間、メイン視聴覚コンテンツと関連して利用可能な付加サービス情報のうち１つ以上を含むことができる。

映像表示装置１００がコンテンツ情報の取得のためにウォーターマークを用いた場合、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、用いられたウォーターマークが内挿（ｅｍｂｅｄｄｉｎｇ）されたコンテンツ区間の時間情報であってもよい。映像表示装置１００がコンテンツ情報の取得のためにフィンガープリントを用いた場合、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、特徴情報が抽出されたコンテンツ区間の時間情報であってもよい。コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、コンテンツ情報の取得に使用されたコンテンツ区間の開始時間、コンテンツ情報の取得に使用されたコンテンツ区間の持続時間（ｄｕｒａｔｉｏｎ）、コンテンツ情報の取得に使用されたコンテンツ区間の終了時間のうち１つ以上を含むことができる。

利用情報報告アドレスは、メイン視聴覚コンテンツ視聴情報報告アドレス及び付加サービス利用情報報告アドレスのうち１つ以上を含むことができる。利用情報報告周期は、メイン視聴覚コンテンツ視聴情報報告周期及び付加サービス利用情報報告周期のうち１つ以上を含むことができる。利用情報の取得のための最小利用時間は、メイン視聴覚コンテンツ視聴情報の取得のための最小視聴時間及び付加サービス利用情報の抽出のための最小使用時間のうち１つ以上を含むことができる。

メイン視聴覚コンテンツが最小視聴時間以上視聴された場合に基づいて、映像表示装置１００はメイン視聴覚コンテンツの視聴情報を取得し、メイン視聴覚コンテンツ視聴情報報告周期でメイン視聴覚コンテンツ視聴情報報告アドレスに抽出した視聴情報を報告することができる。

付加サービスが最小使用時間以上使用された場合に基づいて、映像表示装置１００は付加サービス利用情報を取得し、付加サービス利用情報報告周期で付加サービス利用情報報告アドレスに抽出した利用情報を報告することができる。

付加サービス情報は、付加サービスが存在するか否かに関する情報、付加サービスアドレス提供サーバーのアドレス、それぞれの利用可能な付加サービスの取得経路、それぞれの利用可能な付加サービスのためのアドレス、それぞれの利用可能な付加サービスの開始時間、それぞれの利用可能な付加サービスの終了時間、それぞれの利用可能な付加サービスの寿命（ｌｉｆｅｔｉｍｅ）、それぞれの利用可能な付加サービスの取得モード、それぞれの利用可能な付加サービスのための要求周期、それぞれの利用可能な付加サービスの優先順位情報、それぞれの利用可能な付加サービスの説明、それぞれの利用可能な付加サービスの項目（ｃａｔｅｇｏｒｙ）、利用情報報告アドレス、利用情報報告周期、利用情報取得のための最小利用時間のうち１つ以上を含むことができる。

利用可能な付加サービスの取得経路は、ＩＰ又はＡＴＳＣＭ／Ｈ（ＡｄｖａｎｃｅｄＴｅｌｅｖｉｓｉｏｎＳｙｓｔｅｍｓＣｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）を示すことができる。利用可能な付加サービスの取得経路がＡＴＳＣＭ／Ｈである場合に、付加サービス情報は、周波数情報、チャネル情報をさらに含むことができる。それぞれの利用可能な付加サービスの取得モードは、Ｐｕｓｈ又はＰｕｌｌを示すことができる。

一方、ウォーターマークサーバー２１は、メイン視聴覚コンテンツのロゴにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）として挿入することができる。

例えば、ウォーターマークサーバー２１は、ロゴの一定の位置にバーコードを挿入することができる。このとき、ロゴの一定の位置は、ロゴがディスプレイされる区域の下端の１ラインに該当し得る。映像表示装置１００は、このようにバーコードが挿入されたロゴを含むメイン視聴覚コンテンツを受信する場合、バーコードをディスプレイしないこともできる。

また、ウォーターマークサーバー２１は、ロゴのメタデータの形態でウォーターマーク情報を挿入することができる。このとき、ロゴの形状は維持され得る。

また、ウォーターマークサーバー２１は、Ｍ個のフレームのロゴのそれぞれにＮビットのウォーターマーク情報を挿入することができる。すなわち、ウォーターマークサーバー２１は、Ｍ個のフレームを介してＭ＊Ｎ個のウォーターマーク情報を挿入することができる。

ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ１０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。

放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ１０６）。

一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ１０７）。

また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む放送信号を伝送することもできる（Ｓ１０８）。

映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当すると、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーのアドレスとの対応関係から抽出したロゴに該当するウォーターマークサーバーのアドレスを確認する。ウォーターマーク情報がロゴに該当する場合に、映像表示装置１００は、ロゴのみではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも、映像表示装置１００はメイン視聴覚コンテンツを識別することができないが、ウォーターマーク情報がコンテンツ提供者識別情報やウォーターマークサーバーのアドレスを含むことができる。ウォーターマーク情報がコンテンツ提供者識別情報を含む場合に、映像表示装置１００は、複数のコンテンツ提供者識別情報と複数のウォーターマークサーバーのアドレスとの対応関係から抽出したコンテンツ提供者識別情報に該当するウォーターマークサーバーのアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報のみでメイン視聴覚コンテンツを識別することができない場合、取得したウォーターマークサーバーのアドレスに該当するウォーターマークサーバー２１に接続して第１質疑を伝送する（Ｓ１０９）。

ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ１１１）。この第１応答は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。

ウォーターマーク情報と第１応答が付加サービスアドレスを含んでいない場合、映像表示装置１００は付加サービスを取得することができない。しかし、ウォーターマーク情報と第１応答が付加サービスアドレス提供サーバーのアドレスを含むことができる。このように、映像表示装置１００は、ウォーターマーク情報と第１応答を介して付加サービスアドレスや付加サービスを取得することができず、付加サービスアドレス提供サーバーのアドレスを取得した場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ１１９）。

付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ１２１）。

映像表示装置１００は、ウォーターマーク情報、第１応答又は第２応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ１２３）、付加サービスを取得する（Ｓ１２５）。

図３３は、本発明の一実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す。

図３３に示したように、放送受信装置６０がターンオンされ、チャネルをチューニングし、映像表示装置１００が、外部入力ポート１１１を介して放送受信装置６０からチューニングされたチャネルのメイン視聴覚コンテンツを受信すると、映像表示装置１００は、メイン視聴覚コンテンツのウォーターマークからコンテンツ提供者識別子（又は放送局識別子）を感知することができる。その後、映像表示装置１００は、感知したコンテンツ提供者識別子に基づいてメイン視聴覚コンテンツのウォーターマークからコンテンツ情報を感知することができる。

このとき、図３３に示したように、コンテンツ提供者識別子の感知可能周期とコンテンツ情報の感知可能周期は異なり得る。特に、コンテンツ提供者識別子の感知可能周期は、コンテンツ情報の感知可能周期よりも短くてもよい。これによって、映像表示装置１００は、必要な情報のみを感知するための効率的な構成を有することができる。

図３４は、本発明の一実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。

図３４に示したように、本発明の一実施例に係るネットワークトポロジは、フィンガープリントサーバー２２をさらに含む。

図３４に示されたようなフィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して格納する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子及び時間情報を提供する。

図３５は、本発明の一実施例に係るフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。

まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ２０１）。

フィンガープリントサーバー２２は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツの複数のフレーム区間又は複数のオーディオ区間から複数の特徴情報を抽出し、複数の特徴情報にそれぞれ対応する複数の質疑結果のためのデータベースを構築する（Ｓ２０３）。質疑の結果は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。

ＭＶＰＤ３０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ２０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。

放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ２０６）。

一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ２０７）。

また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む信号を伝送することもできる。

映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ２１３）。

映像表示装置１００は、予め設定されたフィンガープリントサーバーのアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送する（Ｓ２１５）。

フィンガープリントサーバー２２は、第１質疑に対する第１応答として質疑結果を提供する（Ｓ２１７）。もし、第１応答が失敗に該当すれば、映像表示装置１００は、他のフィンガープリントサーバーのアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送することができる。

フィンガープリントサーバー２２は、質疑結果としてＸＭＬ（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）文書を提供することができる。以下、質疑結果を含むＸＭＬ文書の例を説明する。

図３６は、本発明の一実施例に係る質疑結果を含むＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキーマダイヤグラム（ｓｃｈｅｍａｄｉａｇｒａｍ）を示す。

図３６に示したように、質疑結果を含むＡＣＲ−Ｒｅｓｕｌｔｔｙｐｅは、ＲｅｓｕｌｔＣｏｄｅ属性とＣｏｎｔｅｎｔＩＤ、ＮＴＰＴｉｍｅｓｔａｍｐ、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎ、ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントを有する。

例えば、ＲｅｓｕｌｔＣｏｄｅ属性が２００の値を有する場合、これは、質疑結果が成功であることを意味し得る。ＲｅｓｕｌｔＣｏｄｅ属性が４０４の値を有する場合、これは、質疑結果が失敗であることを意味し得る。

ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎエレメントはＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントを有し、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントはＵｐｄａｔｅＭｏｄｅ及びＰｏｌｌｉｎｇＣｙｃｌｅ属性を有する。ＵｐｄａｔｅＭｏｄｅ属性はＰｕｌｌ値又はＰｕｓｈ値を有することができる。

ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントは、ＳｅｒｖｉｃｅＮａｍｅ、ＳｅｒｖｉｃｅＬｏｇｏ、及びＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有する。

次は、このような質疑結果を含むＡＣＲ−ＲｅｓｕｌｔＴｙｐｅのＸＭＬスキーマを示す。

ＣｏｎｔｅｎｔＩＤエレメントとして、下記の表に示すようなＡＴＳＣコンテンツ識別子（ＡＴＳＣｃｏｎｔｅｎｔｉｄｅｎｔｉｆｉｅｒ）を用いることができる。

前記表に示されたように、ＡＴＳＣｃｏｎｔｅｎｔｉｄｅｎｔｉｆｉｅｒは、ＴＳＩＤとハウス番号で構成された構造を有する。

１６ビット符号なし整数ＴＳＩＤは、トランスポートストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍｉｄｅｎｔｉｆｉｅｒ）を含む（ｃａｒｒｙ）。

５ビット符号なし整数ｅｎｄ_ｏｆ_ｄａｙは、放送が終了して、ｃｏｎｔｅｎｔ_ｉｄ値を再利用できる日の時（ｈｏｕｒ）にセットされる。

９ビット符号なし整数ｕｎｉｑｕｅ_ｆｏｒは、ｃｏｎｔｅｎｔ_ｉｄ値を再利用できない日の数（ｔｈｅｎｕｍｂｅｒｏｆｄａｙ）に設定される。

ｃｏｎｔｅｎｔ_ｉｄはコンテンツ識別子を示す。映像表示装置１００は、毎日ｅｎｄ_ｏｆ_ｄａｙに該当する時間でｕｎｉｑｕｅ_ｆｏｒを１ずつ減少させ、ｕｎｉｑｕｅ_ｆｏｒが０になっていないと、ｃｏｎｔｅｎｔ_ｉｄが唯一であるものと見なすことができる。

一方、ＣｏｎｔｅｎｔＩＤエレメントとして、後述するようなＡＴＳＣ−Ｍ／Ｈｓｅｒｖｉｃｅのためのグローバルサービス識別子（ＧｌｏｂａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｅｒ）が用いられてもよい。

グローバルサービス識別子は、次のようなフォームを有する。

−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄ＞：＜ｓｅｒｖｉｃｅｉｄ＞

ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２によって規定されるような２桁の文字からなる国際国コードである。ローカルサービス（ｌｏｃａｌｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの１０進数であり、地域サービス（ｒｅｇｉｏｎａｌｓｅｒｖｉｃｅ）（ｍａｊｏｒ＞６９）のための＜ｘｓｉｄ＞は“０”である。＜ｓｅｒｖｉｃｅｉｄ＞は、＜ｍａｊｏｒ＞や＜ｍｉｎｏｒ＞で定義される。＜ｍａｊｏｒ＞はメジャーチャネル番号（ＭａｊｏｒＣｈａｎｎｅｌｎｕｍｂｅｒ）を示し、＜ｍｉｎｏｒ＞はマイナーチャネル番号（ＭｉｎｏｒＣｈａｎｎｅｌＮｕｍｂｅｒ）を示す。

グローバルサービス識別子の例は、以下の通りである。

−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：１２３４：５．１

−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：０：１００．２００

一方、ＣｏｎｔｅｎｔＩＤエレメントとして、後述するようなＡＴＳＣコンテンツ識別子を用いることができる。

ＡＴＳＣコンテンツ識別子は、次のようなフォームを有する。

ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｃｏｎｔｅｎｔ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄｚ＞：＜ｃｏｎｔｅｎｔｉｄ＞：＜ｕｎｉｑｕｅ_ｆｏｒ＞：＜ｅｎｄ_ｏｆ_ｄａｙ＞

ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２によって規定されるような２桁の文字からなる国際国コードである。ローカルサービス（ｌｏｃａｌｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの１０進数であり、”．”＜ｓｅｒｖｉｃｅｉｄ＞が後続し得る。地域サービス（ｒｅｇｉｏｎａｌｓｅｒｖｉｃｅ）（ｍａｊｏｒ＞６９）のための＜ｘｓｉｄ＞は＜ｓｅｒｖｉｃｅｉｄ＞である。＜ｃｏｎｔｅｎｔ_ｉｄ＞は、前記表に定義されているｃｏｎｔｅｎｔ_ｉｄｆｉｅｌｄのｂａｓｅ６４符号であり、＜ｕｎｉｑｕｅ_ｆｏｒ＞は、前記表に定義されているｕｎｉｑｕｅ_ｆｏｒｆｉｅｌｄの１０進数符号であり、＜ｅｎｄ_ｏｆ_ｄａｙ＞は、前記表に定義されているｅｎｄ_ｏｆ_ｄａｙｆｉｅｌｄの１０進数符号である。

以下では、再び図３５を説明する。

質疑結果が、付加サービスアドレスや付加サービスを含んでおらず、付加サービスアドレス提供サーバーのアドレスを含む場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ２１９）。

付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ２２１）。

映像表示装置１００は、第１応答又は第２応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ２２３）、付加サービスを取得する（Ｓ２２５）。

ＵｐｄａｔｅＭｏｄｅ属性がプル（Ｐｕｌｌ）値を有する場合、映像表示装置１００は、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬを介してＨＴＴＰ要求を付加サービス提供サーバー５０に伝送し、これに対する応答として、ＰＳＩＰバイナリストリームを含むＨＴＴＰ応答を付加サービス提供サーバー５０から受信する。この場合、映像表示装置１００は、ＰｏｌｌｉｎｇＣｙｃｌｅ属性として指定されるポーリング（Ｐｏｌｌｉｎｇ）周期に応じてＨＴＴＰ要求を伝送することができる。また、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントは、アップデート時間属性を有することもできる。この場合、映像表示装置１００は、アップデート時間属性として指定されるアップデート時間でＨＴＴＰ要求を伝送することができる。

ＵｐｄａｔｅＭｏｄｅ属性がプッシュ（Ｐｕｓｈ）値を有する場合、映像表示装置１００は、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔＡＰＩを活用して非同期的にサーバーからアップデートを受信することができる。映像表示装置１００がサーバーにＸＭＬＨＴＴＰＲｅｑｕｅｓｔオブジェクトを介して非同期的な要求をした後、サーバーが、シグナリング情報に変更がある場合に、このチャネルを介して応答としてシグナリング情報を提供する方案である。セッションの待機時間に制限がある場合には、セッションタイムアウト応答（ｓｅｓｓｉｏｎｔｉｍｅｏｕｔｒｅｓｐｏｎｄ）を発生させ、受信機は直ちにこれを認知して再要求することで、受信機とサーバーとの間のシグナリングチャネルを常に維持することができる。

図３７は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。

図３７に示したように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１とフィンガープリントサーバー２２をさらに含む。

図３７に示されたようなウォーターマークサーバー２１は、メイン視聴覚コンテンツにコンテンツ提供者識別情報を挿入する。ウォーターマークサーバー２１は、ロゴのような可視ウォーターマークとしてコンテンツ提供者識別情報をメイン視聴覚コンテンツに挿入することもでき、不可視ウォーターマークとしてコンテンツ提供者識別情報をメイン視聴覚コンテンツに挿入することもできる。

フィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して格納する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子と時間情報を提供する。

図３８は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。

まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ３０１）。

ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）を挿入したり、メイン視聴覚コンテンツにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）として挿入したりし、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスをＭＶＰＤ３０に提供する（Ｓ３０３）。不可視ウォーターマークを介して挿入されるウォーターマーク情報は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、上述した通りである。

ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ３０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。

放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ３０６）。

一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ３０７）。

また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む信号を伝送することもできる（Ｓ３０８）。

映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当する場合、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーのアドレスとの対応関係から抽出したロゴに該当するウォーターマークサーバーのアドレスを確認する。ウォーターマーク情報がロゴに該当する場合、映像表示装置１００は、ロゴのみではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも、映像表示装置１００はメイン視聴覚コンテンツを識別することができないが、ウォーターマーク情報がコンテンツ提供者識別情報やウォーターマークサーバーのアドレスを含むことができる。ウォーターマーク情報がコンテンツ提供者識別情報を含む場合、映像表示装置１００は、複数のコンテンツ提供者識別情報と複数のウォーターマークサーバーのアドレスとの対応関係から抽出したコンテンツ提供者識別情報に該当するウォーターマークサーバーのアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報のみでメイン視聴覚コンテンツを識別することができない場合、取得したウォーターマークサーバーのアドレスに該当するウォーターマークサーバー２１に接続して第１質疑を伝送する（Ｓ３０９）。

ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ３１１）。この第１応答は、フィンガープリントサーバーのアドレス、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、上述した通りである。

ウォーターマーク情報及び第１応答がフィンガープリントサーバーアドレスを含んでいる場合、映像表示装置１００は、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ３１３）。

映像表示装置１００は、第１応答内のフィンガープリントサーバーアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第２質疑を伝送する（Ｓ３１５）。

フィンガープリントサーバー２２は、第２質疑に対する第２応答として質疑結果を提供する（Ｓ３１７）。

質疑結果が、付加サービスアドレスや付加サービスを含んでおらず、付加サービスアドレス提供サーバーのアドレスを含む場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第３質疑を伝送する（Ｓ３１９）。

付加サービス情報提供サーバー４０は、第３質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第３質疑に対する第３応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ３２１）。

映像表示装置１００は、第１応答、第２応答、又は第３応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ３２３）、付加サービスを取得する（Ｓ３２５）。

次は、図３９を参照して、本発明の実施例に係る映像表示装置１００を説明する。

図３９は、本発明の実施例に係る映像表示装置のブロック図である。

図３９に示されたように、本発明の実施例に係る映像表示装置１００は、放送信号受信部１０１、復調部１０３、チャネル復号部１０５、逆多重化部１０７、視聴覚復号部１０９、外部入力ポート１１１、再生制御部１１３、再生装置１２０、付加サービス管理部１３０、データ送受信部１４１、メモリ１５０を含む。

放送信号受信部１０１は、コンテンツ提供サーバー１０又はＭＶＰＤ３０から放送信号を受信する。

復調部１０３は、受信した放送信号を復調し、復調された信号を生成する。

チャネル復号部１０５は、復調された信号をチャネル復号し、チャネル復号されたデータを生成する。

逆多重化部１０７は、チャネル復号されたデータからメイン視聴覚コンテンツと付加サービスを分離する。分離された付加サービスは付加サービス格納部１５２に格納される。

視聴覚復号部１０９は、分離されたメイン視聴覚コンテンツを視聴覚復号（ＡＶｄｅｃｏｄｉｎｇ）して非圧縮メイン視聴覚コンテンツを生成する。

一方、外部入力ポート１１１は、放送受信装置６０、ＤＶＤ（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋ）プレーヤー、ブルーレイディスク（Ｂｌｕ−ｒａｙｄｉｓｃ）プレーヤーなどから非圧縮メイン視聴覚コンテンツを受信する。外部入力ポート１１１は、ＤＳＵＢポート、ＨＤＭＩ（ＨｉｇｈＤｅｆｉｎｉｔｉｏｎＭｕｌｔｉｍｅｄｉａＩｎｔｅｒｆａｃｅ）ポート、ＤＶＩ（ＤｉｇｉｔａｌＶｉｓｕａｌＩｎｔｅｒｆａｃｅ）ポート、コンポジット（ｃｏｍｐｏｓｉｔｅ）ポート、コンポーネント（ｃｏｍｐｏｎｅｎｔ）ポート、Ｓ−Ｖｉｄｅｏポートのうち１つ以上を含むことができる。

再生制御部１１３は、視聴覚復号部１０９が生成する非圧縮メイン視聴覚コンテンツ、又は外部入力ポート１１１から受信した非圧縮メイン視聴覚コンテンツのうちの少なくとも１つをユーザ選択によって再生装置１２０に再生する。

再生装置１２０はディスプレイ部１２１及びスピーカー１２３を含む。ディスプレイ部１２１は、液晶ディスプレイ（ｌｉｑｕｉｄｃｒｙｓｔａｌｄｉｓｐｌａｙ、ＬＣＤ）、薄膜トランジスタ液晶ディスプレイ（ｔｈｉｎｆｉｌｍｔｒａｎｓｉｓｔｏｒ−ｌｉｑｕｉｄｃｒｙｓｔａｌｄｉｓｐｌａｙ、ＴＦＴＬＣＤ）、有機発光ダイオード（ｏｒｇａｎｉｃｌｉｇｈｔ−ｅｍｉｔｔｉｎｇｄｉｏｄｅ、ＯＬＥＤ）、フレキシブルディスプレイ（ｆｌｅｘｉｂｌｅｄｉｓｐｌａｙ）、３次元ディスプレイ（３Ｄｄｉｓｐｌａｙ）のうち少なくとも１つを含むことができる。

付加サービス管理部１３０は、メイン視聴覚コンテンツのコンテンツ情報を取得し、取得されたコンテンツ情報に基づいて利用可能な付加サービスを取得する。特に、上述したように、付加サービス管理部１３０は、非圧縮メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルに基づいてメイン視聴覚コンテンツの識別情報を取得することができ、本明細書では、これを自動コンテンツ認識（ａｕｔｏｍａｔｉｃｃｏｎｔｅｎｔｓｒｅｃｏｇｎｉｔｉｏｎ、ＡＣＲ）と呼ぶこともある。

データ送受信部１４１は、ＡＴＳＣ−Ｍ／Ｈ（ＡｄｖａｎｃｅｄＴｅｌｅｖｉｓｉｏｎＳｙｓｔｅｍｓＣｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）チャネル送受信部１４１ａ及びＩＰ送受信部１４１ｂを含むことができる。

メモリ１５０は、フラッシュメモリタイプ（ｆｌａｓｈｍｅｍｏｒｙｔｙｐｅ）、ハードディスクタイプ（ｈａｒｄｄｉｓｋｔｙｐｅ）、マルチメディアカードマイクロタイプ（ｍｕｌｔｉｍｅｄｉａｃａｒｄｍｉｃｒｏｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、ＳＲＡＭ（ＳｔａｔｉｃＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ−ＯｎｌｙＭｅｍｏｒｙ）、ＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄ−ＯｎｌｙＭｅｍｏｒｙ）、ＰＲＯＭ（ＰｒｏｇｒａｍｍａｂｌｅＲｅａｄ−ＯｎｌｙＭｅｍｏｒｙ）、磁気メモリ、磁気ディスク、光ディスクのうち少なくとも１つのタイプの格納媒体を含むことができる。映像表示装置１００は、インターネット（ｉｎｔｅｒｎｅｔ）上で前記メモリ１５０の格納機能を行うウェブストレージ（ｗｅｂｓｔｏｒａｇｅ）と関連して動作することもできる。

メモリ１５０は、コンテンツ情報格納部１５１、付加サービス格納部１５２、ロゴ格納部１５３、設定情報格納部１５４、ブックマーク格納部１５５、ユーザ情報格納部１５６、利用情報格納部１５７を含むことができる。

コンテンツ情報格納部１５１は、複数の特徴情報に対応する複数のコンテンツ情報を格納する。

付加サービス格納部１５２は、複数の特徴情報に対応する複数の付加サービスを格納することもでき、複数のコンテンツ情報に対応する複数の付加サービスを格納することもできる。

ロゴ格納部１５３は複数のロゴを格納する。また、ロゴ格納部は、この複数のロゴに対応するコンテンツ提供者識別子、又は複数のロゴに対応するウォーターマークサーバーのアドレスをさらに格納することもできる。

設定情報格納部１５４はＡＣＲのための設定情報を格納する。

ブックマーク格納部１５５はブックマークを格納する。

ユーザ情報格納部１５６はユーザ情報を格納する。ユーザ情報は、１つ以上のサービスのための１つ以上のアカウント情報、地域情報、家族構成員情報、好みのジャンルの情報、映像表示装置情報、利用情報提供範囲のうち１つ以上を含むことができる。１つ以上のアカウント情報は、利用情報測定サーバーのためのアカウント情報、ツイッター（ｔｗｉｔｔｅｒ）、フェイスブック（ｆａｃｅｂｏｏｋ）のようなソーシャルネットワークサービス（ｓｏｃｉａｌｎｅｔｗｏｒｋｓｅｒｖｉｃｅ）のアカウント情報を含むことができる。地域情報は、アドレス情報及び郵便番号を含むことができる。家族構成員情報は、家族構成員の数、各構成員の年齢、各構成員の性別、各構成員の宗教、各構成員の職業などを含むことができる。好みのジャンルの情報は、スポーツ、映画、ドラマ、教育、ニュース、エンターテインメント、その他のジャンルのうち１つ以上に設定されてもよい。映像表示装置情報は、映像表示装置の種類、製造会社、ファームウェアのバージョン、解像度、モデル名、ＯＳ、ブラウザ、格納装置の有無、格納装置の容量、ネットワークの速度に関する情報を含むことができる。利用情報提供範囲が設定されると、映像表示装置１００は、設定された範囲内でメイン視聴覚コンテンツ視聴情報と付加サービス利用情報を収集し、報告することができる。利用情報提供範囲は、仮想チャネルのそれぞれに対して設定されてもよい。また、利用情報測定許容範囲は、物理チャネル全体に対して設定されてもよい。

利用情報格納部１５７は、映像表示装置１００によって収集されるメイン視聴覚コンテンツ視聴情報及び付加サービス使用情報を格納する。また、映像表示装置１００は、収集したメイン視聴覚コンテンツ視聴情報及び収集した付加サービス使用情報に基づいてサービス利用パターンを分析し、分析されたサービス利用パターンを利用情報格納部１５７に格納することができる。

付加サービス管理部１３０は、フィンガープリントサーバー２２又はコンテンツ情報格納部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。コンテンツ情報格納部１５１に、抽出した特徴情報に該当するコンテンツ情報がないか、又は十分なコンテンツ情報がない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加のコンテンツ情報を受信することができる。また、付加サービス管理部１３０は、持続的にコンテンツ情報をアップデートすることができる。

付加サービス管理部１３０は、付加サービス提供サーバー５０又は付加サービス格納部１５２から利用可能な付加サービスを取得することができる。付加サービス格納部１５２に付加サービスがないか、又は十分な付加サービスがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して付加サービスをアップデートすることができる。また、付加サービス管理部１３０は、持続的に付加サービスをアップデートすることができる。

付加サービス管理部１３０は、メイン視聴覚コンテンツからロゴを抽出し、ロゴ格納部１５３に問い合わせて抽出したロゴに対応するコンテンツ提供者識別子、又はウォーターマークサーバーのアドレスを取得することができる。ロゴ格納部１５３に、抽出したロゴと一致するロゴがないか、又は十分なロゴがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加のロゴを受信することができる。また、付加サービス管理部１３０は、持続的にロゴをアップデートすることができる。

付加サービス管理部１３０は、メイン視聴覚コンテンツから抽出したロゴとロゴ格納部１５３内の複数のロゴとの比較を行っており、演算の負担を低減するための様々な方法で行うことができる。

例えば、付加サービス管理部１３０は、色相特性に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴの色相特性と、ロゴ格納部１５３内のロゴの色相特性とを比較し、一致するか否かを判断することができる。

また、付加サービス管理部１３０は、文字認識に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴから認識される文字と、ロゴ格納部１５３内のロゴから認識される文字とを比較し、一致するか否かを判断することができる。

それだけでなく、付加サービス管理部１３０は、ロゴの輪郭に対する形状に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴの輪郭形状と、ロゴ格納部１５３内のロゴの輪郭形状とを比較し、一致するか否かを判断することができる。

次は、図４０及び図４１を参照して、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を説明する。

図４０は、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示すフローチャートである。

付加サービス情報は、付加サービスの開始時間を含むことができる。このとき、映像表示装置１００は、この開始時間に付加サービスを開始する必要がある。しかし、映像表示装置１００は、タイムスタンプを有しない非圧縮メイン視聴覚コンテンツを伝送する信号を受信するため、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とは異なる。映像表示装置１００が時間情報を有するメイン視聴覚コンテンツを受信しても、再放送などのように、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とは異なり得る。したがって、映像表示装置１００は、メイン視聴覚コンテンツの基準時間と付加サービスの基準時間とを同期化する必要がある。特に、映像表示装置１００は、メイン視聴覚コンテンツの再生時間と付加サービスの開始時間とを同期化する必要がある。

まず、付加サービス管理部１３０は、メイン視聴覚コンテンツの一部の区間を抽出する（Ｓ８０１）。メイン視聴覚コンテンツの一部の区間は、メイン視聴覚コンテンツの一部のビデオフレーム及び一部のオーディオ区間のうち１つ以上を含むことができる。付加サービス管理部１３０がメイン視聴覚コンテンツの一部の区間を抽出した時間をＴｎという。

付加サービス管理部１３０は、抽出された区間に基づいてメイン視聴覚コンテンツのコンテンツ情報を取得する（Ｓ８０３）。具体的には、付加サービス管理部１３０は、抽出された区間に不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅｗａｔｅｒｍａｒｋ）として符号化された情報を復号し、コンテンツ情報を取得することができる。また、付加サービス管理部１３０は、抽出された区間の特徴情報を抽出し、抽出された特徴情報に基づいてフィンガープリントサーバー２２又はコンテンツ情報格納部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。付加サービス管理部１３０がコンテンツ情報を取得した時間をＴｍという。

一方、コンテンツ情報は、抽出された区間の開始時間（Ｔｓ）を含む。付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）以降からは、時間（Ｔｓ）、時間（Ｔｍ）、時間（Ｔｎ）に基づいてメイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化する（Ｓ８０５）。具体的には、付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）を、新たに計算される時間（Ｔｐ）と見なす。ここで、Ｔｐ＝Ｔｓ＋（Ｔｍ−Ｔｎ）とすることができる。

そして、付加サービス管理部１３０は、コンテンツ情報取得時間から時間（Ｔｘ）が経過した時間を、Ｔｐ＋Ｔｘと見なすことができる。

その後、付加サービス管理部１３０は、取得したコンテンツ情報に基づいて付加サービス及び付加サービスの開始時間（Ｔａ）を取得する（Ｓ８０７）。

メイン視聴覚コンテンツの同期化された再生時間が付加サービスの開始時間（Ｔａ）と一致すると、付加サービス管理部１３０は、取得した付加サービスを開始する（Ｓ８０９）。具体的には、付加サービス管理部１３０は、Ｔｐ＋Ｔｘ＝Ｔａを満足する場合に付加サービスを開始することができる。

図４１は、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示す概念図である。

図４１に示されたように、映像表示装置１００は、システム時間（Ｔｎ）で視聴覚サンプルを抽出する。

映像表示装置１００は、抽出した視聴覚サンプルから特徴情報を抽出し、フィンガープリントサーバー２２に、抽出した特徴情報を含む質疑を伝送し、質疑結果を受信する。映像表示装置１００は、質疑結果をパースし、抽出した視聴覚サンプルの開始時間（Ｔｓ）が１１０００ｍｓに該当することを時間（Ｔｍ）で確認する。

したがって、映像表示装置は、抽出した視聴覚サンプルの開始時間を確認した時点をＴｓ＋（Ｔｍ−Ｔｎ）と見なし、以降から、メイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化することができる。

次は、図４２及び図４３を参照して、本発明の様々な実施例に係る映像表示装置の構造について説明する。

図４２は、本発明の更に他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。

図４２において、チューナ５０１は、エアチャネルを介して伝送される８−ＶＳＢＲＦ信号からシンボルを抽出する。

８−ＶＳＢ復調器５０３は、チューナ５０１が抽出した８−ＶＳＢシンボルを復調し、意味のあるデジタルデータを復元する。

ＶＳＢデコーダ５０５は、８−ＶＳＢ復調器５０３が復元したデジタルデータを復号し、ＡＴＳＣメインサービスとＡＴＳＣＭ／Ｈサービスを復元する。

ＭＰＥＧ−２ＴＰ逆多重化部５０７は、８−ＶＳＢ信号を介して伝送されるＭＰＥＧ−２トランスポートパケット又はＰＶＲ格納装置に格納されたＭＰＥＧ−２トランスポートパケットのうち映像表示装置１００が処理しようとするトランスポートパケットをフィルタリングし、適切な処理モジュールに中継する。

ＰＥＳデコーダ５３９は、ＭＰＥＧ−２トランスポートストリームを介して伝送されたパケット化されたエレメンタリストリーム（ＰａｃｋｅｔｉｚｅｄＥｌｅｍｅｎｔａｒｙＳｔｒｅａｍ）をバッファリングし、復元する。

ＰＳＩ／ＰＳＩＰデコーダ５４１は、ＭＰＥＧ−２トランスポートストリームを介して伝送されるＰＳＩ／ＰＳＩＰセクションデータをバッファリングし、分析する。分析されたＰＳＩ／ＰＳＩＰデータはサービスマネジャー（図示せず）によって収集され、サービスマップ及びガイドデータの形態でＤＢに格納される。

ＤＳＭＣＣセクションバッファ／ハンドラ５１１は、ＭＰＥＧ−２ＴＰを介して伝送されるファイル伝送及びＩＰデータグラムカプセル化などのためのＤＳＭＣＣセクションデータをバッファリング（Ｂｕｆｆｅｒｉｎｇ）し、処理する。

ＩＰ／ＵＤＰデータグラムバッファ／ヘッダーパーサー５１３は、ＤＳＭＣＣアドレッサブルセクションを介してカプセル化されてＭＰＥＧ−２ＴＰを介して伝送されるＩＰデータグラムをバッファリングし、復元して、各データグラムのヘッダーを分析する。また、ＩＰ／ＵＤＰデータグラムバッファ／ヘッダーパーサー５１３は、ＩＰデータグラムを介して伝送されるＵＤＰデータグラムをバッファリング及び復元し、復元されたＵＤＰヘッダーを分析及び処理する。

ストリームコンポーネントハンドラ５５７は、ＥＳバッファ／ハンドラ、ＰＣＲハンドラ、ＳＴＣモジュール、デスクランブラ、ＣＡストリームバッファ／ハンドラ、サービスシグナリングセクションバッファ／ハンドラを含むことができる。

ＥＳバッファ／ハンドラは、ＰＥＳ形態で伝送されたビデオ、オーディオデータなどのエレメンタリストリームをバッファリング及び復元し、適切なＡ／Ｖデコーダに伝達する。

ＰＣＲハンドラは、オーディオ及びビデオストリームの時間同期化などのために使用されるＰＣＲ（ＰｒｏｇｒａｍＣｌｏｃｋＲｅｆｅｒｅｎｃｅ）データを処理する。

ＳＴＣモジュールは、ＰＣＲハンドラを介して伝達された基準クロック値を用いて、Ａ／Ｖデコーダのクロック値を補正して時間同期化を行う。

受信されたＩＰデータグラムのペイロードにスクランブリングが適用された場合、デスクランブラは、ＣＡストリームハンドラから伝達された暗号化キーなどを用いて、ペイロードのデータを復元する。

ＣＡストリームバッファ／ハンドラは、ＭＰＥＧ−２ＴＳ又はＩＰストリームを介して伝送される制限受信（ＣｏｎｄｉｔｉｏｎａｌＡｃｃｅｓｓ）機能のために伝送されるＥＭＭ、ＥＣＭなどのデスクランブリングのためのキー値などのデータをバッファリング及び処理する。ＣＡストリームバッファ／ハンドラの出力はデスクランブラに伝達され、デスクランブラは、Ａ／Ｖデータ及びファイルデータなどを伝送するＭＰＥＧ−２ＴＰ又はＩＰデータグラムの暗号化解除作業を行う。

サービスシグナリングセクションバッファ／ハンドラは、ＩＰデータグラムの形態で伝送されるＮＲＴサービスシグナリングチャネルセクションデータをバッファリングし、復元し、分析する。サービスマネジャー（図示せず）は、分析されたＮＲＴサービスシグナリングチャネルセクションデータを収集し、サービスマップ及びガイドデータの形態でＤＢに格納する。

Ａ／Ｖデコーダ５６１は、ＥＳハンドラを介して伝達されたオーディオ／ビデオデータの圧縮を復号化し、ユーザに提示する。

ＭＰＥＧ−２サービス逆多重化部（図示せず）は、ＭＰＥＧ−２ＴＰバッファ／パーサー、デスクランブラ、ＰＶＲ格納モジュールを含むことができる。

ＭＰＥＧ−２ＴＰバッファ／パーサー（図示せず）は、８−ＶＳＢ信号を介して伝送されるＭＰＥＧ−２トランスポートパケットをバッファリング及び復元し、トランスポートパケットヘッダーを検出及び処理する。

デスクランブラは、ＭＰＥＧ−２ＴＰのうち、スクランブルが適用されたパケットペイロードに対して、ＣＡストリームハンドラから伝達された暗号化キーなどを用いて、ペイロードのデータを復元する。

ＰＶＲ格納モジュールは、ユーザの要求などに応じて、８−ＶＳＢ信号を用いて受信されたＭＰＥＧ−２ＴＰを格納し、また、ユーザの要求によってＭＰＥＧ−２ＴＰを出力する。ＰＶＲ格納モジュールはＰＶＲマネジャー（図示せず）によって制御されてもよい。

ファイルハンドラ５５１は、ＡＬＣ／ＬＣＴバッファ／パーサー、ＦＤＴハンドラ、ＸＭＬパーサー、ファイル再構成バッファ、圧縮解除器、ファイルデコーダ、ファイル格納部を含むことができる。

ＡＬＣ／ＬＣＴバッファ／パーサーは、ＵＤＰ／ＩＰストリームで伝送されるＡＬＣ／ＬＣＴデータをバッファリング及び復元し、ＡＬＣ／ＬＣＴのヘッダー及びヘッダー拡張部を分析する。ＡＬＣ／ＬＣＴバッファ／パーサーはＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。

ＦＤＴハンドラは、ＡＬＣ／ＬＣＴセッションを介して伝送されるＦＬＵＴＥプロトコルのファイル記述テーブル（ＦｉｌｅＤｅｓｃｒｉｐｔｉｏｎＴａｂｌｅ）を分析及び処理する。ＦＤＴハンドラはＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。

ＸＭＬパーサーは、ＡＬＣ／ＬＣＴセッションを介して伝送されるＸＭＬ文書を分析し、ＦＤＴハンドラ、ＳＧハンドラなどの適切なモジュールに分析されたデータを伝達する。

ファイル再構成バッファは、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを介して伝送されるファイルを復元する。

圧縮解除器は、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを介して伝送されるファイルが圧縮されている場合、その圧縮を解除するプロセスを行う。

ファイルデコーダは、ファイル再構成バッファで復元されたファイル、圧縮解除器で圧縮解除されたファイル、又はファイル格納部で抽出されたファイルをデコードする。

ファイル格納部は、復元されたファイルを、必要に応じて格納又は抽出する。

Ｍ／Ｗエンジン（図示せず）は、ＤＳＭＣＣセクション、ＩＰデータグラムなどを介して伝送されるＡ／Ｖストリームではないファイルなどのデータを処理する。Ｍ／Ｗエンジンは、処理されたデータをプレゼンテーションマネジャーモジュールに伝達する。

ＳＧハンドラ（図示せず）は、ＸＭＬ文書の形態で伝送されるサービスガイドデータを収集し、分析してＥＰＧマネジャーに伝達するプロセスを行う。

サービスマネジャー（図示せず）は、ＭＰＥＧ−２トランスポートストリームを介して伝送されるＰＳＩ／ＰＳＩＰデータ、ＩＰストリームで伝送されるサービスシグナリングセクションデータを収集し、分析してサービスマップを作製する。サービスマネジャー（図示せず）は、作製したサービスマップをサービスマップ＆ガイドデータベースに格納し、ユーザが望むサービスに対するアクセスを制御する。動作制御器（図示せず）によって制御され、チューナ５０１、ＭＰＥＧ−２ＴＰ逆多重化部５０７、ＩＰデータグラムバッファ／ハンドラ５１３などに対する制御を行う。

ＮＲＴサービスマネジャー（図示せず）は、ＩＰ層上でＦＬＵＴＥセッションを介してオブジェクト／ファイルの形態で伝送されるＮＲＴサービスに関する全般的な管理を行う。ＮＲＴサービスマネジャー（図示せず）は、ＦＤＴハンドラ、ファイル格納部などを制御することができる。

アプリケーションマネジャー（図示せず）は、オブジェクト、ファイルなどの形態で伝送されるアプリケーションデータの処理に関する全般的な管理を行う。

ＵＩマネジャー（図示せず）は、ユーザインターフェースを介してユーザの入力を動作制御器に伝達し、ユーザが要求するサービスのためのプロセスの動作を開始する。

動作制御器（図示せず）は、ＵＩマネジャーを介して伝達されたユーザの命令を処理し、必要とするモジュールのマネジャーが当該アクションを行うようにする。

フィンガープリント抽出器５６５は、オーディオ／ビデオストリームからフィンガープリント特徴情報を抽出する。

フィンガープリント比較器５６７は、フィンガープリント抽出器が抽出した特徴情報と基準フィンガープリントとを比較し、一致するコンテンツを見つける。フィンガープリント比較器５６７は、ローカルに格納された基準フィンガープリントＤＢを用いることもでき、インターネット上のフィンガープリント質疑サーバーに問い合わせて結果を受信することもできる。比較結果で得られるマッチングされた結果データはアプリケーションに伝達されて用いられてもよい。

アプリケーション５６９は、ＡＣＲ機能を管理するモジュールあるいはＡＣＲに基づいて付加サービスを提供するアプリケーションモジュールであって、視聴中の放送コンテンツを識別し、これと関連付けられた拡張されたサービスを提供する。

図４３は、本発明の更に他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。

図４３に示されたウォーターマークベースの映像表示装置は、図４２に示されたフィンガープリントベースの映像表示装置と類似しているが、フィンガープリントベースの映像表示装置のフィンガープリント抽出器５６５とフィンガープリント比較器５６７を含まず、その代わりにウォーターマーク抽出器５６６をさらに含む。

ウォーターマーク抽出器５６６は、オーディオ／ビデオストリームから、ウォーターマークの形態で挿入されたデータを抽出する。このように抽出されたデータはアプリケーションに伝達されて利用されてもよい。

図４４は、本発明の一実施例によってウォーターマーキング方式を介して伝達され得るデータを示すダイヤグラムである。

上述したように、ＷＭを介したＡＣＲの目的は、圧縮不可能なオーディオ／ビデオのみをアクセスできる環境（すなわち、オーディオ／ビデオがケーブル／衛星／ＩＰＴＶなどから受信された環境）で圧縮不可能なオーディオ／ビデオからコンテンツの付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）サービス関連情報を得ることである。このような環境はＡＣＲ環境と呼ぶことができる。ＡＣＲ環境において、受信機が圧縮不可能なオーディオ／ビデオデータのみを受信するため、受信機は、どのコンテンツが現在ディスプレイされているかを確認することができない。したがって、受信機は、コンテンツソースＩＤ、放送プログラムの現在の時点、及びＷＭによって伝達される関連するアプリケーションのＵＲＬ情報を用いて、ディスプレイされるコンテンツを確認し、インタラクティブサービスを提供する。

オーディオ／ビデオウォーターマーク（ＷＭ）を用いて放送プログラムと関連する付加サービスを伝達するにおいて、全ての付加情報は、最も簡単な方法として、ＷＭによって伝達されてもよい。この場合、全ての付加情報は、ＷＭ検出器によって検出され、受信機によって検出された情報を同時に処理することができる。

しかし、この場合、オーディオ／ビデオデータに挿入されたＷＭの量が増加すると、オーディオ／ビデオの全体の品質が劣化することがある。このような理由から、最小の必要データのみをＷＭに挿入することができる。受信機がＷＭとして最小のデータを挿入しながら、さらに多くの量の情報を受信し、処理するようにするＷＭデータの構造が定義される必要がある。ＷＭに使用されるデータの構造は、データの量による影響が比較的少ないフィンガープリンティング方式でも同一に使用することができる。

図示のように、本発明の一実施例によってウォーターマーキング方式で伝達されたデータは、コンテンツソースのＩＤ、タイムスタンプ、インタラクティブアプリケーションＵＲＬ、タイムスタンプタイプ、ＵＲＬプロトコルタイプ、アプリケーションイベント、目的地タイプなどを含むことができる。また、様々なタイプのデータは、本発明によってＷＭ方式により伝達されてもよい。

本発明は、ＡＣＲがＷＭ方式によって行われる場合、ＷＭに含まれるデータの構造を提案する。図示されたデータタイプに対して、最も効率的な構造が本発明によって提案される。

本発明の一実施例によってウォーターマーキング方式を介して伝達可能なデータは、コンテンツソースのＩＤを含む。セットトップボックスを用いる環境において、ＭＶＰＤ（ｍｕｌｔｉｃｈａｎｎｅｌｖｉｄｅｏｐｒｏｇｒａｍｍｉｎｇｄｉｓｔｒｉｂｕｔｏｒ）がセットトップボックスを介してプログラム関連情報を伝達しない場合、受信機（端末又はＴＶ）は、プログラム名、チャネル情報などをチェックすることができない。したがって、特定のコンテンツソースを識別する固有のＩＤが必要であり得る。本発明において、コンテンツソースのＩＤのタイプは制限されない。コンテンツソースのＩＤの例は、次の通りである。

まず、グローバルチャネルＩＤは、それぞれの放送プログラムを識別するグローバル識別子であってもよい。このＩＤは、コンテンツ提供者によって直接生成されたり、権威のある団体によって特定されたフォーマットで生成されてもよい。ＩＤの例は、北アメリカの“ＴＭＳメタデータ”のＴＭＳＩｄ、映画／放送プログラム識別子であるＥＩＤＲＩＤなどを含むことができる。

グローバルチャネルＩＤは、全てのチャネルを識別するチャネル識別子であってもよい。チャネル番号は、セットトップボックスによって提供されるＭＶＰＤ毎に異なる。また、同一のＭＶＰＤにおいても、チャネル番号は、ユーザによって指定されたサービスに応じて異なり得る。グローバルチャネルＩＤは、ＭＶＰＤなどによって影響を受けないグローバル識別子として使用されてもよい。実施例によれば、地上波を介して送信されるチャネルは、メジャーチャネル番号及びマイナーチャネル番号によって識別されてもよい。プログラムＩＤのみが使用される場合、複数個の放送局が同じプログラムを放送するときに問題が発生し得るため、グローバルチャネルＩＤは、特定の放送チャネルを特定するのに使用することができる。

ＷＭに挿入されるコンテンツソースのＩＤの例は、プログラムＩＤ及びチャネルＩＤを含むことができる。プログラムＩＤ及びチャネルＩＤのうち１つ、又は両方とも、又は２つのＩＤを結合することによって得られた新しいＩＤがＷＭに挿入されてもよい。実施例によって、それぞれのＩＤ又は結合されたＩＤがハッシュ（ｈａｓｈ）されてデータの量を減少させることができる。それぞれのコンテンツソースのＩＤは、ストリングタイプ又は整数タイプであってもよい。整数タイプの場合、送信されたデータの量がさらに減少し得る。

また、本発明の一実施例によってウォーターマーキングを介して伝達可能なデータは、タイムスタンプを含むことができる。受信機は、現在視聴しているコンテンツの時点を知らなければならない。この時間関連情報はタイムスタンプと呼ぶことができ、ＷＭに挿入され得る。この時間関連情報は、絶対時間（ＵＴＣ、ＧＰＳなど）又はメディア時間の形態を取ることができる。時間関連情報は、正確性のためにミリ秒の単位まで伝達されてもよく、実施例によってさらに小さい単位まで伝達されてもよい。タイムスタンプは、タイムスタンプのタイプ情報によって可変長を有することができる。

一実施例によってウォーターマーキング方式を介して伝達可能なデータは、インタラクティブアプリケーションのＵＲＬを含むことができる。現在視聴している放送プログラムに関連するインタラクティブアプリケーションが存在すると、アプリケーションのＵＲＬがＷＭに挿入され得る。受信機が、ＷＭを検出し、ＵＲＬを得、ブラウザを介してアプリケーションを実行することができる。

図４５は、本発明の一実施例によってタイムスタンプタイプフィールドの値の意味を示すダイヤグラムである。

本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、タイムスタンプタイプフィールドを提案する。また、本発明は、タイムスタンプタイプフィールドの効率的なデータ構造を提案する。

タイムスタンプタイプフィールドには５ビットが割り当てられてもよい。タイムスタンプの最初の２つのビットは、タイムスタンプのサイズを意味し、次の３ビットは、タイムスタンプによって指示された時間情報の単位を意味し得る。ここで、最初の２ビットはタイムスタンプサイズフィールドと呼び、次の３ビットはタイムスタンプ単位フィールドと呼ぶことができる。

図示のように、タイムスタンプのサイズ及びタイムスタンプの単位値に応じて、可変的な量の実際のタイムスタンプ情報がＷＭに挿入されてもよい。このような可変性を用いて、設計者は、タイムスタンプの正確度に応じて、タイムスタンプに割り当てられたサイズ及びその単位を選択することができる。タイムスタンプの正確度が増加すると、正確な時間にインタラクティブサービスを提供することができる。しかし、タイムスタンプの正確度が増加するに伴い、システムの複雑度が増加する。このようなトレードオフ（ｔｒａｄｅｏｆｆ）を考慮して、タイムスタンプに割り当てられたサイズ及びその単位が選択され得る。

タイムスタンプタイプフィールドの最初の２つのビットが００であると、タイムスタンプは１バイトのサイズを有することができる。タイムスタンプタイプフィールドの最初の２つのビットが０１，１０，１１であると、タイムスタンプのサイズは、それぞれ２，４，８バイトであってもよい。

タイムスタンプタイプフィールドの最後の３ビットが０００であると、タイムスタンプはミリ秒の単位を有することができる。タイムスタンプタイプフィールドの最後の３ビットが００１，０１０，０１１であると、タイムスタンプは、秒、分及び時単位であってもよい。１０１〜１１１のタイムスタンプタイプフィールドの最後の３ビットは、未来のために予備として残してもよい。

ここで、タイムスタンプタイプフィールドの最後の３ビットが１００であると、ミリ秒又は秒などの特定の時間単位の代わりに別途のタイムコードが単位として使用されてもよい。例えば、タイムコードは、ＳＭＰＴＥのタイムコードであるＨＨ：ＭＭ：ＳＳ：ＦＦの形態でＷＭに挿入されてもよい。ここで、ＨＨは時間単位であり、ＭＭは分単位であり、ＳＳは秒単位であってもよい。ＦＦはフレーム情報であってもよい。時間単位ではないフレーム情報は、同時に伝達されてフレーム正確サービス（ｆｒａｍｅ−ａｃｃｕｒａｔｅｓｅｒｖｉｃｅ）を提供することができる。実際のタイムスタンプは、ＷＭに挿入されるために、コロンを排除したＨＨＭＭＳＳＦＦの形態を有することができる。この場合、タイムスタンプサイズ値は１１（８バイト）を有することができ、タイムスタンプ単位値は１００であってもよい。可変単位の場合、タイムスタンプが挿入される方法は、本発明によって制限されない。

例えば、タイムスタンプタイプ情報が１０の値を有し、タイムスタンプ単位情報が０００の値を有する場合、タイムスタンプのサイズは４ビットであり、タイムスタンプの単位はミリ秒であってもよい。このとき、タイムスタンプがＴｓ＝３２６５０８７であると、タイムスタンプの後に位置する３つの数字０８７はミリ秒の単位を意味し得、残りの数字３２６５は秒単位を意味し得る。したがって、このタイムスタンプが解釈されるとき、現在の時間は、ＷＭが挿入されたプログラムを開始した後、５４分２５．０８７秒が経過したことを意味し得る。これは、例示に過ぎないものであり、タイムスタンプは、壁時間（ｗａｌｌｔｉｍｅ）として機能することができ、コンテンツに関係なく、セグメント又は受信機の時間を示すことができる。

図４６は、本発明の一実施例によってＵＲＬプロトコルタイプフィールドの値の意味を示すダイヤグラムである。

本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、ＵＲＬプロトコルタイプフィールドを提案する。また、本発明は、ＵＲＬプロトコルタイプフィールドの効率的なデータ構造を提案する。

上述した情報のうち、ＵＲＬの長さは一般的に長いため、挿入されるデータの量は比較的大きい。上述したように、ＷＭに挿入されるデータの量が減少するに伴い、効率が増加する。したがって、ＵＲＬの固定部分が受信機によって処理され得る。したがって、本発明は、ＵＲＬプロトコルタイプフィールドを提案する。

ＵＲＬプロトコルタイプフィールドは３ビットのサイズを有することができる。サービス提供者は、ＵＲＬプロトコルタイプフィールドを用いてＷＭ内のＵＲＬプロトコルを設定することができる。この場合、インタラクティブアプリケーションのＵＲＬは、ドメインから挿入され、ＷＭに送信され得る。

受信機のＷＭ検出器は、まず、ＵＲＬプロトコルタイプフィールドをパースし、ＵＲＬプロトコル情報を得、その後、送信されたＵＲＬ値にプロトコルをプレフィックス（ｐｒｅｆｉｘ）して、全体のＵＲＬを生成することができる。受信機は、ブラウザを介して完了したＵＲＬをアクセスし、インタラクティブアプリケーションを実行することができる。

ここで、ＵＲＬプロトコルタイプフィールドの値が０００であると、ＵＲＬプロトコルは、直接指定されてＷＭのＵＲＬフィールドに挿入されてもよい。ＵＲＬプロトコルタイプフィールドの値が００１，０１０，０１１であると、ＵＲＬプロトコルは、それぞれｈｔｔｐ：／／、ｈｔｔｐｓ：／／、ｗｓ：／／であってもよい。１００〜１１１のＵＲＬプロトコルタイプフィールドの値は、未来使用のために予備として残してもよい。

アプリケーションＵＲＬは、（ウェブアプリケーションの形態で）ブラウザを介してアプリケーションの実行を可能にすることができる。また、実施例によって、コンテンツソースＩＤ及びタイムスタンプ情報が参照されなければならない。後者の場合、コンテンツソースＩＤ情報及びタイムスタンプ情報を遠隔サーバーに伝達するために、最終ＵＲＬは、次の形態で表すことができる。

ＲｅｑｕｅｓｔＵＲＬ：

この実施例において、コンテンツソースＩＤは１２３４５６であり、タイムスタンプは５００５であってもよい。ｃｉｄは、遠隔サーバーに報告されるコンテンツソースＩＤの質疑識別子を意味し得る。ｔは、遠隔サーバーに報告される現在の時間の質疑識別子を意味し得る。

図４７は、本発明の一実施例によってＵＲＬプロトコルタイプフィールドを処理するプロセスを示すフローチャートである。

まず、サービス提供者４７０１０は、ＷＭ挿入器４７０２０にコンテンツを伝達することができる（ｓ４７０１０）。ここで、サービス提供者４７０１０は、上述したコンテンツ提供サーバーと類似の機能を行うことができる。ＷＭ挿入器４７０２０は、伝達されたコンテンツをＷＭに挿入することができる（ｓ４７０２０）。ここで、ＷＭ挿入器４７０２０は、上述したウォーターマークサーバーと類似の機能を行うことができる。ＷＭ挿入器４７０２０は、ＷＭアルゴリズムによって、上述したＷＭをオーディオ又はビデオに挿入することができる。ここで、挿入されたＷＭは、上述したアプリケーションＵＲＬ情報、コンテンツソースＩＤ情報などを含むことができる。例えば、挿入されたＷＭは、上述したタイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤなどを含むことができる。上述したプロトコルタイプフィールドは００１の値を有し、ＵＲＬ情報はａｔｓｃ．ｏｒｇの値を有することができる。ＷＭに挿入されたフィールドの値は例示的なものに過ぎず、本発明はこの実施例に制限されない。

ＷＭ挿入器４７０２０は、ＷＭが挿入されたコンテンツを送信することができる（ｓ４７０３０）。ＷＭが挿入されたコンテンツの送信は、サービス提供者４７０１０によって行われる。

ＳＴＢ４７０３０は、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータ（又はロー（ｒａｗ）Ａ／Ｖデータ）を出力することができる（ｓ４７０４０）。ここで、ＳＴＢ４７０３０は、上述した放送受信装置又はセットトップボックスを意味し得る。ＳＴＢ４７０３０は、受信機の内部又は外部に装着されてもよい。

ＷＭ検出器４７０４０は、受信された圧縮不可能なＡ／Ｖデータから、挿入されたＷＭを検出することができる。ＷＭ検出器４７０４０は、ＷＭ挿入器４７０２０によって挿入されたＷＭを検出し、検出されたＷＭをＷＭマネジャーに伝達することができる。

ＷＭマネジャー４７０５０は、検出されたＷＭをパースすることができる（ｓ４７０６０）。上述した実施例において、ＷＭは、００１のＵＲＬプロトコルタイプフィールドの値及びａｔｓｃ．ｏｒｇのＵＲＬ値を有することができる。ＵＲＬプロトコルタイプフィールドの値が００１であると、これは、ｈｔｔｐ：／／プロトコルが使用されることを意味し得る。ＷＭマネジャー４７０５０は、この情報を用いてｈｔｔｐ：／／及びａｔｓｃ．ｏｒｇを結合し、全体のＵＲＬを生成することができる（ｓ４７０７０）。

ＷＭマネジャー４７０５０は、完了したＵＲＬをブラウザ４７０６０に伝送してアプリケーションを開始する(launch)ことができる（ｓ４７０８０）。場合によって、コンテンツソースＩＤ情報及びタイムスタンプ情報もまた伝達されなければならない場合、アプリケーションは、ｈｔｔｐ：／／ａｔｓｃ．ｏｒｇ？ｃｉｄ＝ＸＸＸ＆ｔ＝ＹＹＹの形態で開始されてもよい。

端末のＷＭ検出器４７０４０及びＷＭマネジャー４７０５０が結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ４５０５０、ｓ４７０６０、ｓ４７０７０が一つのモジュールで処理されてもよい。

図４８は、本発明の一実施例によってイベントフィールドの値の意味を示すダイヤグラムである。

本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、イベントフィールドを提案する。また、本発明は、イベントフィールドの効率的なデータ構造を提案する。

アプリケーションは、ＷＭから抽出されたＵＲＬを介して開始されてもよい。アプリケーションは、さらに細部的なイベントを介して制御されてもよい。アプリケーションを制御できるイベントは、イベントフィールドによって指示され、伝達されてもよい。すなわち、現在視聴している放送プログラムに関連するインタラクティブアプリケーションが存在すると、アプリケーションのＵＲＬが送信され、アプリケーションがイベントを介して制御され得る。

イベントフィールドは３ビットのサイズを有することができる。イベントフィールドの値が０００であると、これは、“準備（Ｐｒｅｐａｒｅ）”命令を示すことができる。準備は、アプリケーションを実行する前の準備段階である。この命令を受信した受信機は、事前にアプリケーションに関連するコンテンツ項目をダウンロードすることができる。また、受信機は、アプリケーションを実行するために必要なリソースを解除（ｒｅｌｅａｓｅ）することができる。ここで、必要なリソースを解除することは、メモリを整理したり、他の終了していないアプリケーションを終了することを意味し得る。

イベントフィールドの値が００１であると、これは、“実行（Ｅｘｅｃｕｔｅ）”命令を示すことができる。実行は、アプリケーションを実行する命令であってもよい。イベントフィールドの値が０１０であると、これは、“中断（Ｓｕｓｐｅｎｄ）”命令を示すことができる。中断は、実行されたアプリケーションを中断することを意味する。イベントフィールドの値が０１１であると、これは、“キル（Ｋｉｌｌ）”命令を示すことができる。キルは、既に実行されたアプリケーションを終了する命令であってもよい。１００〜１１１のイベントフィールドの値は、未来使用のために予備として残してもよい。

図４９は、本発明の一実施例によって目的地タイプフィールドの値の意味を示す図である。

本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、目的地タイプフィールドを提案する。また、本発明は、目的地タイプフィールドの効率的なデータ構造を提案する。

ＤＴＶ関連技術の発展により、放送コンテンツに関連する付加サービスが、ＴＶ受信機のスクリーンだけでなくコンパニオン装置によって提供され得る。しかし、コンパニオン装置は、放送プログラムを受信することができないか、または放送プログラムを受信するが、ＷＭを検出することができない。したがって、現在放送されているコンテンツに関連する付加サービスを提供するアプリケーションのうち、コンパニオン装置によって実行されるアプリケーションが存在すると、その関連情報がコンパニオン装置に伝達されなければならない。

このとき、受信機及びコンパニオン装置が連動する環境でも、ＷＭから検出されたアプリケーション又はデータがどの装置によって消費されるかを知る必要がある。すなわち、アプリケーション又はデータが受信機又はコンパニオン装置によって消費されるか否かに関する情報が必要である。ＷＭのような情報を伝達するために、本発明は、目的地タイプフィールドを提案する。

目的地タイプフィールドは３ビットのサイズを有することができる。目的地タイプフィールドの値が０ｘ００であると、これは、ＷＭによって検出されたアプリケーション又はデータが全ての装置をターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０１であると、これは、ＷＭによって検出されたアプリケーション又はデータがＴＶ受信機をターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０２であると、これは、ＷＭによって検出されたアプリケーション又はデータがスマートフォンをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０３であると、これは、ＷＭによって検出されたアプリケーション又はデータがタブレットをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０４であると、これは、ＷＭによって検出されたアプリケーション又はデータがパーソナルコンピュータをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０５であると、これは、ＷＭによって検出されたアプリケーション又はデータが遠隔サーバーをターゲットとすることを意味する。０ｘ０６〜０ｘＦＦの目的地タイプフィールドの値は、未来使用のために予備として残してもよい。

ここで、遠隔サーバーは、放送プログラムに関連する全ての付加情報を有するサーバーを意味し得る。この遠隔サーバーは端末の外に位置し得る。遠隔サーバーが用いられる場合、ＷＭに挿入されたＵＲＬは、特定のアプリケーションのＵＲＬを示すものではなく、遠隔サーバーのＵＲＬを示すことができる。受信機は、遠隔サーバーのＵＲＬを介して遠隔サーバーと通信し、放送プログラムと関連する付加情報を受信することができる。このとき、受信された付加情報は、関連するアプリケーションのＵＲＬだけでなく、現在放送されているプログラムのジャンル、俳優情報、シノプシスなどの様々な情報であってもよい。受信された情報は、システムに応じて異なり得る。

他の実施例によれば、目的地タイプフィールドのそれぞれのビットは、それぞれの装置に割り当てられてアプリケーションの目的地を示すことができる。この場合、複数個の目的地がビットワイズ（ｂｉｔｗｉｓｅ）ＯＲを介して同時に指定されてもよい。

例えば、０ｘ０１がＴＶ受信機を示し、０ｘ０２がスマートフォンを示し、０ｘ０４がタブレットを示し、０ｘ０８がＰＣを示し、０ｘ１０が遠隔サーバーを示すとき、目的地タイプフィールドが０ｘ６の値を有すると、アプリケーション又はデータはスマートフォンとタブレットをターゲットとすることができる。

上述したＷＭマネジャーによってパースされたＷＭの目的地タイプフィールドの値によれば、ＷＭマネジャーは、それぞれのアプリケーション又はデータをコンパニオン装置に伝達することができる。この場合、ＷＭマネジャーは、受信機内のコンパニオン装置との連動を処理するモジュールであり、それぞれのアプリケーション又はデータと関連する情報を伝達することができる。

図５０は、本発明の実施例＃１によってＷＭに挿入されるデータの構造を示すダイヤグラムである。

本実施例において、ＷＭに挿入されるデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、目的地タイプフィールド、ＵＲＬプロトコルタイプフィールド及びＵＲＬなどの情報を有することができる。ここで、実施例によって、データの順序は変更されてもよく、それぞれのデータが省略されてもよい。

本実施例において、タイムスタンプタイプフィールドのタイムスタンプサイズフィールドは０１の値を有し、タイムスタンプ単位フィールドは０００の値を有することができる。これは、タイムスタンプに２ビットが割り当てられ、タイムスタンプがミリ秒の単位を有することを意味する。

また、イベントフィールドは００１の値を有し、これは、アプリケーションが直ちに実行されなければならないことを意味する。目的地タイプフィールドは０ｘ０２の値を有し、これは、ＷＭによって伝達されたデータがスマートフォンに伝達されなければならないことを意味する。ＵＲＬプロトコルタイプフィールドが００１の値を有し、ＵＲＬがａｔｓｃ．ｏｒｇの値を有するため、これは、付加情報又はアプリケーションのＵＲＬがｈｔｔｐ：／／ａｔｓｃ．ｏｒｇであることを意味し得る。

図５１は、本発明の実施例＃１によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。

サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５１０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭに挿入するステップ（ｓ５１０２０）、ＷＭ挿入器が、ＷＭが挿入されたコンテンツを送信するステップ（ｓ５１０３０）、ＳＴＢが、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５１０４０）、ＷＭ検出器がＷＭを検出するステップ（ｓ５１０５０）、ＷＭマネジャーが、検出されたＷＭをパースするステップ（ｓ５１０６０）、及び／又はＷＭマネジャーが全体のＵＲＬを生成するステップ（ｓ５１０７０）は、上述したステップと同一であってもよい。

ＷＭマネジャーは、パースされたＷＭの目的地タイプフィールドに従って受信機内のコンパニオン装置プロトコルモジュールであり、関連するデータを伝達することができる（ｓ５１０８０）。コンパニオン装置プロトコルモジュールは、受信機内のコンパニオン装置の連動及び通信を管理することができる。コンパニオン装置プロトコルモジュールはコンパニオン装置とペアリングされてもよい。実施例によって、コンパニオン装置プロトコルモジュールはＵＰｎＰ装置であってもよい。実施例によって、コンパニオン装置プロトコルモジュールは端末の外に位置してもよい。

コンパニオン装置プロトコルモジュールは、目的地タイプフィールドに従って関連するデータをコンパニオン装置に伝達することができる（ｓ５１０９０）。実施例＃１において、目的地タイプフィールドの値は０ｘ０２であり、ＷＭに挿入されたデータはスマートフォンに対するデータであり得る。したがって、コンパニオン装置プロトコルモジュールは、パースされたデータをスマートフォンに伝送することができる。すなわち、この実施例において、コンパニオン装置はスマートフォンであってもよい。

実施例によって、ＷＭマネジャー又は装置プロトコルモジュールは、コンパニオン装置にデータを伝達する前にデータ処理手順を行うことができる。コンパニオン装置は携帯性を有することができるが、その代わりに、劣悪な処理／コンピューティング能力及び小さい量のメモリを有し得る。したがって、受信機は、コンパニオン装置の代わりにデータを処理し、処理されたデータをコンパニオン装置に伝達することができる。

このような処理は、様々な実施例として実現されてもよい。まず、ＷＭマネジャー又はコンパニオン装置プロトコルモジュールは、コンパニオン装置によって要求されたデータのみを選択することができる。また、実施例によって、イベントフィールドが、アプリケーションが完了したことを示す情報を含む場合、アプリケーション関連情報が伝達されなくてもよい。また、データが複数個のＷＭを介して分けられて伝送される場合、データは格納され、結合され得、その後、最終情報がコンパニオン装置に伝達されてもよい。

受信機は、コンパニオン装置の代わりに、タイムスタンプを用いて同期化を行い、同期化されたアプリケーションと関連する命令を伝達するか、または既に同期化されたインタラクティブサービスをコンパニオン装置に伝達し、コンパニオン装置はディスプレイのみを行うことができる。タイムスタンプ関連情報が伝達されず、タイムベース（ｔｉｍｅｂａｓｅ）がただ受信機に維持され得、所定のイベントが活性化されると、関連情報がコンパニオン装置に伝達され得る。この場合、コンパニオン装置は、タイムベースを維持せず、関連情報が受信される時間に応じてイベントを活性化することができる。

前記説明と同様に、端末のＷＭ検出器及びＷＭマネジャーが結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ５１０５０、ｓ５１０６０、ｓ５１０７０、ｓ５１０８０が一つのモジュールで行われてもよい。

また、実施例によって、コンパニオン装置はまたＷＭ検出器を有することができる。それぞれのコンパニオン装置が、ＷＭが挿入された放送プログラムを受信すると、それぞれのコンパニオン装置は、ＷＭを直接検出した後、ＷＭを他のコンパニオン装置に伝達することができる。例えば、スマートフォンがＷＭを検出及びパースし、関連情報をＴＶに伝達することができる。この場合、目的地タイプフィールドは０ｘ０１の値を有することができる。

図５２は、本発明の実施例＃２によってＷＭに挿入されるデータの構造を示すダイヤグラムである。

本実施例において、ＷＭに挿入されたデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、目的地タイプフィールド、ＵＲＬプロトコルタイプフィールド及びＵＲＬなどの情報を有することができる。ここで、実施例によって、データの順序は変更されてもよく、それぞれのデータが省略されてもよい。

本実施例において、タイムスタンプタイプフィールドのタイムスタンプサイズフィールドは０１の値を有することができ、タイムスタンプ単位フィールドは０００の値を有することができる。これは、タイムスタンプに２ビットが割り当てられ、タイムスタンプがミリ秒の単位を有することを意味する。コンテンツＩＤは１２３４５６の値を有することができる。

また、イベントフィールドは００１の値を有し、これは、アプリケーションが直ちに実行されなければならないことを意味する。目的地タイプフィールドは０ｘ０５の値を有し、これは、ＷＭによって伝達されたデータが遠隔サーバーに伝達されなければならないことを意味する。ＵＲＬプロトコルタイプフィールドが００１の値を有し、ＵＲＬがｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍの値を有するため、これは、付加情報又はアプリケーションのＵＲＬがｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍであることを意味し得る。

上述したように、遠隔サーバーが用いられる場合、放送プログラムの付加情報は遠隔サーバーから受信され得る。このとき、コンテンツＩＤ及びタイムスタンプがパラメータとして遠隔サーバーのＵＲＬに挿入されて、遠隔サーバーに要求され得る。実施例によって、遠隔サーバーは、ＡＰＩのサポートを通じて、現在放送されているプログラムに関する情報を得ることができる。このとき、ＡＰＩは、遠隔サーバーが受信機に格納されたコンテンツＩＤ及びタイムスタンプを取得するようにしたり、関連する付加情報を伝達するようにすることができる。

本実施例において、コンテンツＩＤ及びスタンプがパラメータとして遠隔サーバーのＵＲＬに挿入される場合、全体のＵＲＬは、ｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍ？ｃｉｄ＝１２３４５６＆ｔ＝５００５であり得る。ここで、ｃｉｄは、遠隔サーバーに報告されるコンテンツソースＩＤの質疑識別子を意味し得る。ｔは、遠隔サーバーに報告される現在の時間の質疑識別子を意味し得る。

図５３は、本発明の実施例＃２によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。

サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５３０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭに挿入するステップ（ｓ５３０２０）、ＷＭ挿入器が、ＷＭが挿入されたコンテンツを送信するステップ（ｓ５３０３０）、ＳＴＢが、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５３０４０）、ＷＭ検出器がＷＭを検出するステップ（ｓ５３０５０）、及びＷＭマネジャーが検出されたＷＭをパースするステップ（ｓ５３０６０）は、上述したステップと同一であってもよい。

ＷＭマネジャーは、パースされた目的地タイプフィールド０ｘ０５を介して遠隔サーバーと通信することができる。ＷＭマネジャーは、ＵＲＬプロトコルタイプフィールドの値及びＵＲＬ値を用いてＵＲＬを生成することができる。また、コンテンツＩＤ及びタイムスタンプ値を用いてＵＲＬが最終的に生成され得る。ＷＭマネジャーは、最終ＵＲＬを用いて要求することができる（ｓ５３０７０）。

遠隔サーバーは、要求を受信し、放送プログラムに適した関連アプリケーションのＵＲＬをＷＭマネジャーに送信することができる（ｓ５３０８０）。ＷＭマネジャーは、受信されたアプリケーションのＵＲＬをブラウザに伝送し、アプリケーションを開始する(launch)ことができる（ｓ５３０９０）。

前記説明と同様に、端末のＷＭ検出器及びＷＭマネジャーが結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ５３０５０、ｓ５３０６０、ｓ５３０７０、ｓ５３０９０が、一つのモジュールで行われてもよい。

図５４は、本発明の実施例＃３によってＷＭに挿入されるデータの構造を示すダイヤグラムである。

本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、伝達タイプフィールドを提案する。また、本発明は、伝達タイプフィールドの効率的なデータ構造を提案する。

ＷＭに挿入されたデータの量の増加によるオーディオ／ビデオコンテンツの品質の劣化を減少させるために、ＷＭが分離されて挿入されてもよい。ＷＭが分離されて挿入されるかを示すために、伝達タイプフィールドが使用されてもよい。伝達タイプフィールドを介して、放送関連情報を得るために１つのＷＭ、あるいは複数個のＷＭが検出されるかを決定することができる。

伝達タイプフィールドが０の値を有すると、これは、全てのデータが一つのＷＭに挿入されて送信されることを意味し得る。伝達タイプフィールドが１の値を有すると、これは、データが分けられて複数個のＷＭに挿入されて送信されることを意味し得る。

本実施例において、伝達タイプフィールドの値は０である。この場合、ＷＭのデータ構造は、伝達タイプフィールドを上述したデータ構造に付着する形態で構成されてもよい。本発明では、伝達タイプフィールドが最前部に位置するが、伝達タイプフィールドが他の位置に配置されてもよい。

ＷＭマネジャー又はＷＭ検出器は、伝達タイプフィールドが０の値を有する場合、ＷＭの長さを参照してＷＭをパースすることができる。このとき、ＷＭの長さは、所定のフィールドのビット数を考慮して計算することができる。例えば、上述したように、イベントフィールドの長さは３ビットであってもよい。実施例によって、コンテンツＩＤ及びＵＲＬのサイズは変更可能であるが、ビットの数は制限され得る。

図５５は、本発明の実施例＃４によってＷＭに挿入されるデータの構造を示すダイヤグラムである。

本実施例において、伝達タイプフィールドの値は１であってもよい。この場合、複数個のフィールドがＷＭのデータ構造に付加されてもよい。

ＷＭＩｄフィールドは、ＷＭを識別する識別子として機能することができる。データが複数個のＷＭに分けられて送信される場合、ＷＭ検出器は、分離されたデータを有するそれぞれのＷＭを識別する必要がある。このとき、分離されたデータをそれぞれ有するＷＭは、同一のＷＭＩｄフィールド値を有することができる。ＷＭＩｄフィールドは８ビットのサイズを有することができる。

ブロック番号フィールドは、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭの識別番号を示すことができる。分離されたデータをそれぞれ有するＷＭの値は、その送信順序によって１ずつ増加することができる。例えば、分離されたデータをそれぞれ有するＷＭのうち第１ＷＭの場合、ブロック番号フィールドの値は０ｘ００であってもよい。第２ＷＭ、第３ＷＭ及びその後続のＷＭは０ｘ０１，０ｘ０２，…の値を有することができる。ブロック番号フィールドは８ビットのサイズを有することができる。

最後のブロック番号フィールドは、分離されたデータをそれぞれ有するＷＭのうち最後のＷＭの識別番号を示すことができる。ＷＭ検出器又はＷＭマネジャーは、上述したブロック番号フィールドの値が最後のブロック番号フィールドと同一になるまで検出されたＷＭを集めてパースすることができる。最後のブロック番号フィールドは８ビットのサイズを有することができる。

ブロック長フィールドは、ＷＭの全長を示すことができる。ここで、ＷＭは、分離されたデータをそれぞれ有するＷＭのうち１つを意味し得る。ブロック長フィールドは７ビットのサイズを有することができる。

コンテンツＩＤフラグフィールドは、コンテンツＩＤが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。コンテンツＩＤが含まれる場合、コンテンツＩＤフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。コンテンツＩＤフラグフィールドは１ビットのサイズを有することができる。

イベントフラグフィールドは、イベントフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。イベントフィールドが含まれる場合、イベントフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。イベントフラグフィールドは１ビットのサイズを有することができる。

目的地フラグフィールドは、目的地タイプフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。目的地タイプフィールドが含まれる場合、目的地フラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。目的地フラグフィールドは１ビットのサイズを有することができる。

ＵＲＬプロトコルフラグフィールドは、ＵＲＬプロトコルタイプフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。ＵＲＬプロトコルタイプフィールドが含まれる場合、ＵＲＬプロトコルフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。ＵＲＬプロトコルフラグフィールドは１ビットのサイズを有することができる。

ＵＲＬフラグフィールドは、ＵＲＬ情報が、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。ＵＲＬ情報が含まれる場合、ＵＲＬフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。ＵＲＬフラグフィールドは１ビットのサイズを有することができる。

ペイロードは、上述したフィールドに加え、実際のデータを含むことができる。

データが複数個のＷＭに分離されて送信される場合、それぞれのＷＭがいつ挿入されるかに関する情報を知る必要がある。この場合、実施例によって、タイムスタンプがそれぞれのＷＭに挿入されてもよい。このとき、ＷＭがいつ挿入されるかを知るために、タイムスタンプタイプフィールドもまたタイムスタンプが挿入されたＷＭに挿入されてもよい。代案として、実施例によって、受信機は、ＷＭタイムスタンプタイプ情報を格納して使用することができる。受信機は、第１タイムスタンプ、最後のタイムスタンプ又はそれぞれのタイムスタンプに基づいて時間同期化を行うことができる。

データが複数個のＷＭに分けられて送信される場合、それぞれのＷＭのサイズがフラグフィールドを用いて調整されてもよい。上述したように、ＷＭによって送信されたデータの量が増加すると、オーディオ／ビデオコンテンツの品質が影響を受けることがある。したがって、フレームに挿入されたＷＭのサイズは、送信されたオーディオ／ビデオフレームに応じて調整され得る。このとき、ＷＭのサイズは、上述したフラグフィールドによって調整されてもよい。

例えば、コンテンツのビデオフレームのうちの任意の１つは、ブラックスクリーンのみを有すると仮定する。場面がコンテンツに応じてスイッチングされると、ブラックスクリーンのみを有する１つのビデオフレームのみが挿入され得る。このビデオフレームにおいて、さらに多くの量のＷＭが挿入される場合でも、コンテンツの品質は劣化しない。すなわち、ユーザがコンテンツ品質の劣化を感知しない。この場合、多量のデータを有するＷＭが、このビデオフレームに挿入され得る。このとき、ビデオフレームに挿入されたＷＭのフラグフィールドの値のほとんどが１であってもよい。これは、ＷＭがフィールドのほとんどを有するためである。特に、多量のデータを有するＵＲＬフィールドは、そのＷＭ内に含まれ得る。したがって、比較的少量のデータは、他のビデオフレームに挿入され得る。ＷＭに挿入されたデータの量は、設計者の意図によって変更可能である。

図５６は、本発明の実施例＃４によって第１ＷＭに挿入されるデータの構造を示すダイヤグラムである。

本実施例において、伝達タイプフィールドの値が１であると、すなわち、データが複数個のＷＭに分離されて送信される場合、第１ＷＭの構造が、図５６に示されたものと同一であってもよい。

分離されたデータをそれぞれ有するＷＭのうち、第１ＷＭは０ｘ００のブロック番号フィールド値を有することができる。実施例によって、ブロック番号フィールドの値が異なって使用される場合、図示されたＷＭは第１ＷＭではなくてもよい。

受信機は第１ＷＭを検出することができる。検出されたＷＭは、ＷＭマネジャーによってパースされてもよい。このとき、ＷＭの伝達タイプフィールドの値は１であり、ブロック番号フィールドの値が最後のブロック番号フィールドの値と異なることがわかる。したがって、ＷＭマネジャーは、０ｘ００のＷＭＩＤを有する残りのＷＭが受信されるまで、パースされた情報を格納することができる。特に、ＵＲＬ情報であるａｔｓｃ．ｏｒｇもまた格納され得る。最後のブロック番号フィールドの値が０ｘ０１であるため、一つのＷＭが未来にさらに受信されると、０ｘ００のＷＭＩＤを有する全てのＷＭが受信され得る。

本実施例において、フラグフィールドの全ての値は１である。したがって、イベントフィールドなどの情報がこのＷＭのペイロードに含まれることがわかる。また、タイムスタンプの値が５００５であるため、このＷＭが挿入された部分に対応する時間は５．００５秒であり得る。

図５７は、本発明の実施例＃４によって第２ＷＭに挿入されるデータの構造を示すダイヤグラムである。

本実施例において、伝達タイプフィールドの値が１であると、すなわち、データが複数個のＷＭに分けられて送信される場合、第２ＷＭの構造は、図５７に示されたものと同一であってもよい。

分離されたデータをそれぞれ有するＷＭのうち、第２ＷＭは０ｘ０１のブロック番号フィールド値を有することができる。実施例によって、ブロック番号フィールドの値が異なって使用される場合、図示されたＷＭは第２ＷＭではなくてもよい。

受信機は第２ＷＭを検出することができる。ＷＭマネジャーは、検出された第２ＷＭをパースすることができる。このとき、ブロック番号フィールドの値が最後のブロック番号フィールドの値と同一であるため、このＷＭが、０ｘ００のＷＭＩｄ値を有するＷＭのうち最後のＷＭであることがわかる。

フラグフィールドのうち、ＵＲＬフラグの値のみが１であるため、ＵＲＬ情報が含まれることがわかる。ブロック番号フィールドの値が０ｘ０１であるため、この情報は、既に格納された情報と結合され得る。特に、既に格納されたａｔｓｃ．ｏｒｇ部分及び第２ＷＭに含まれる／ａｐｐｓ／ａｐｐ１．ｈｔｍｌ部分が結合され得る。また、既に格納された情報において、ＵＲＬプロトコルタイプフィールドの値が００１であるため、最終的に結合されたＵＲＬは、ｈｔｔｐ：／／ａｔｓｃ．ｏｒｇ／ａｐｐｓ／ａｐｐ１．ｈｔｍｌであり得る。このＵＲＬは、このブラウザを介して開始されてもよい。

第２ＷＭによって、第２ＷＭが挿入された部分に対応する時間は１０．００５秒であり得る。受信機は、第１ＷＭの５．００５秒に基づいて時間同期化を行うか、または最後のＷＭの１０．００５秒に基づいて時間同期化を行うことができる。本実施例において、ＷＭは、５秒の間隔をおいて２回送信される。ＷＭが伝達されない５秒間、オーディオ／ビデオのみが送信されるため、コンテンツ品質の劣化を防止することができる。これは、データが複数個のＷＭに分離されて送信される場合にも、品質の劣化を減少させることができる。ＷＭが分離されて挿入される時間は、実施例によって変更されてもよい。

図５８は、本発明の実施例＃４によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。

サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５８０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭ＃１に挿入するステップ（ｓ５８０２０）、ＷＭ挿入器が、ＷＭ＃１が挿入されたコンテンツを送信するステップ（ｓ５８０３０）、ＳＴＢが、ＷＭ＃１が挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５８０４０）、及びＷＭ検出器がＷＭ＃１を検出するステップ（ｓ５８０５０）は、上述したステップと同一であってもよい。

ＷＭ＃１は、分離されたデータが挿入されたＷＭのうちの１つであることを意味し、本発明の実施例＃４における第１ＷＭであってもよい。上述したように、このＷＭのブロック番号フィールドは０ｘ００であり、ＵＲＬ情報はａｔｓｃ．ｏｒｇであってもよい。

ＷＭマネジャーは、検出されたＷＭ＃１をパースし、格納することができる（ｓ５８０６０）。このとき、ＷＭマネジャーは、各フィールドのビット数及びＷＭの全長を参照してパーシングを行うことができる。ブロック番号フィールドの値が最後のブロックフィールドの値と異なり、伝達タイプフィールドの値が１であるため、ＷＭマネジャーは、ＷＭをパースし、格納した後、次のＷＭを待つ。

ここで、サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５８０７０）、ＷＭ挿入器が、受信されたコンテンツをＷＭ＃２に挿入するステップ（ｓ５８０８０）、ＷＭ挿入器が、ＷＭ＃２が挿入されたコンテンツを送信するステップ（ｓ５８０９０）、ＳＴＢが、ＷＭ＃２が挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５８１００）、及びＷＭ検出器がＷＭ＃２を検出するステップ（ｓ５８１１０）は、上述したステップと同一であってもよい。

ＷＭ＃２は、分離されたデータが挿入されたＷＭのうちの１つを意味し、本実施例の実施例＃４における第２ＷＭであってもよい。上述したように、このＷＭのブロック番号フィールドは０ｘ０１であり、ＵＲＬ情報は／ａｐｐｓ／ａｐｐ１．ｈｔｍｌであってもよい。

ＷＭマネジャーは、検出されたＷＭ＃２をパースし、格納することができる（ｓ５８１２０）。ＷＭ＃２をパースして得た情報と、既に格納されたＷＭ＃１をパースして得た情報とが結合されて全体のＵＲＬを生成することができる（ｓ５８１３０）。この場合、全体のＵＲＬは、上述した通りである。

ＷＭマネジャーが、関連するデータを目的地タイプフィールドによる受信機のコンパニオン装置プロトコルモジュールに伝達するステップ（ｓ５８１４０）、及びコンパニオン装置プロトコルモジュールが、関連するデータを目的地タイプフィールドによるコンパニオン装置に伝達するステップ（ｓ５８１５０）は、上述したステップと同一であってもよい。

目的地タイプフィールドは、上述したように、ＷＭ＃１によって伝達されてもよい。これは、本発明の実施例＃４の第１ＷＭの目的地フラグフィールドの値が１であるためである。上述したように、この目的地タイプフィールドの値がパースされ、格納されてもよい。目的地タイプフィールドの値が０ｘ０２であるため、これは、スマートフォンに対するデータを示すことができる。

コンパニオン装置プロトコルモジュールは、上述したように、コンパニオン装置と通信して関連情報を処理することができる。上述したように、ＷＭ検出器とＷＭマネジャーが結合されてもよい。結合されたモジュールは、ＷＭ検出器及びＷＭマネジャーの機能を行うことができる。

図５９は、本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。

この実施例は、ＷＭマネジャーｔ５９０１０及びコンパニオン装置プロトコルモジュールｔ５９０２０がウォーターマーク抽出器ｔ５９０３０の下に付加されることを除いては、上述したウォーターマークベースの映像表示装置の構造と類似している。残りのモジュールは、上述したモジュールと同一であってもよい。

ウォーターマーク抽出器ｔ５９０３０は、上述したＷＭ検出器に対応し得る。ウォーターマーク抽出器ｔ５９０３０は、上述したウォーターマークベースの映像表示装置の構造と同じ名を有するモジュールと同一であってもよい。ＷＭマネジャーｔ５９０１０は上述したＷＭマネジャーに対応し、コンパニオン装置プロトコルモジュールｔ５９０２０は上述したコンパニオン装置プロトコルモジュールに対応し得る。モジュールの動作は上述した。

図６０は、フィンガープリンティング方式における本発明の一実施例に係るデータ構造を示す図である。

フィンガープリンティング（ＦＰ）ＡＣＲシステムの場合、オーディオ／ビデオコンテンツの品質劣化が、ＷＭを用いる場合と比較して減少することができる。フィンガープリンティングＡＣＲシステムの場合、付加情報がＡＣＲサーバーから受信されるので、品質劣化は、コンテンツに直接挿入されたＷＭの品質劣化よりも小さい。

ＡＣＲサーバーから情報が受信される場合、品質劣化が上述したように減少するので、ＷＭに使用されるデータ構造がそのまま使用されてもよい。すなわち、本発明によって提案されたデータ構造はＦＰ方式でも使用することができる。代案として、実施例によって、ＷＭのデータ構造の一部のみが使用されてもよい。

ＷＭの上述したデータ構造が使用されると、０ｘ０５の目的地タイプフィールド値の意味が変更され得る。上述したように、目的地タイプフィールドの値が０ｘ０５であると、受信機が遠隔サーバーにデータを要求することができる。ＦＰ方式において、遠隔サーバーの機能はＡＣＲサーバーによって行われるので、目的地タイプフィールドの値０ｘ０５が削除されたり、再定義されてもよい。

残りのフィールドは、上述したフィールドと同一であってもよい。

図６１は、フィンガープリンティング方式における本発明の一実施例に係るデータ構造を処理するプロセスを示すフローチャートである。

サービス提供者は、送信される放送プログラムからフィンガープリント（ＦＰ）を抽出することができる（ｓ６１０１０）。ここで、サービス提供者は、上述したサービス提供者と同一であってもよい。サービス提供者は、ＡＣＲ会社によって提供されたツール又は自身のツールを用いて、コンテンツ毎にフィンガープリントを抽出することができる。サービス提供者は、オーディオ／ビデオフィンガープリントを抽出することができる。

サービス提供者は、抽出されたフィンガープリントをＡＣＲサーバーに伝達することができる（ｓ６１０２０）。事前に生成されたプログラムの場合、放送プログラムが送信される前、又はライブプログラムの場合、ＦＰがリアルタイムで抽出されたらすぐに、フィンガープリントがＡＣＲサーバーに伝達されてもよい。ＦＰがリアルタイムで抽出されてＡＣＲサーバーに伝達されると、サービス提供者は、コンテンツＩＤをコンテンツに割り当てて、送信タイプ、目的地タイプ又はＵＲＬプロトコルタイプなどの情報を割り当てることができる。割り当てられた情報は、リアルタイムで抽出されたＦＰにマッピングされ、ＡＣＲサーバーに伝達されてもよい。

ＡＣＲサーバーは、受信されたＦＰ及びその関連情報をＡＣＲＤＢに格納することができる（ｓ６１０３０）。受信機は、外部から受信されたオーディオ／ビデオ信号からＦＰを抽出することができる。ここで、オーディオ／ビデオ信号は圧縮不可能な信号であってもよい。このＦＰは、シグネチャー（ｓｉｇｎａｔｕｒｅ）と呼ぶことができる。受信機は、ＦＰを用いて、要求をサーバーに伝送することができる（ｓ６１０４０）。

ＡＣＲサーバーは、受信されたＦＰとＡＣＲＤＢを比較することができる。受信されたＦＰにマッチングするＦＰがＡＣＲＤＢに存在する場合、受信機によって放送されるコンテンツが認識され得る。コンテンツが認識されると、伝達タイプ情報、タイムスタンプ、コンテンツＩＤ、イベントタイプ情報、目的地タイプ情報、ＵＲＬプロトコルタイプ情報、ＵＲＬ情報などが受信機に伝送され得る（ｓ６１０５０）。

ここで、それぞれの情報は、上述したフィールドに含まれた状態で送信されてもよい。例えば、目的地タイプ情報は、目的地タイプフィールドに含まれた状態で送信されてもよい。受信機に応答するとき、上述したＷＭに使用されるデータ構造は、伝達されたデータの構造として使用されてもよい。

受信機は、ＡＣＲサーバーから受信された情報をパースすることができる。本実施例において、目的地タイプフィールドの値が０ｘ０１であるため、ＵＲＬのアプリケーションがＴＶによって実行されることがわかる。最終ＵＲＬがＵＲＬプロトコルタイプフィールドの値及びＵＲＬ情報を用いて生成されてもよい。ＵＲＬを生成するプロセスは、上述したプロセスと同一であってもよい。

受信機は、ＵＲＬを用いて、ブラウザを介して放送関連アプリケーションを実行することができる（ｓ６１０６０）。ここで、ブラウザは、上述したブラウザと同一であってもよい。ステップｓ６１０４０、ｓ６１０５０、ｓ６１０６０は繰り返されてもよい。

図６２は、本発明の一実施例に係る、放送受信機を示す図である。

本発明の一実施例に係る放送受信機は、サービスコンテンツ取得制御器（Ｓｅｒｖｉｃｅ／ＣｏｎｔｅｎｔＡｃｑｕｉｓｉｔｉｏｎＣｏｎｔｒｏｌｌｅｒ）Ｊ２０１０、インターネットインターフェース（Ｉｎｔｅｒｎｅｔｉｎｔｅｒｆａｃｅ）Ｊ２０２０、放送網インターフェース（Ｂｒｏａｄｃａｓｔｉｎｔｅｒｆａｃｅ）Ｊ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理ユニット（Ｍａｎａｇｉｎｇｕｎｉｔ）Ｊ２０９０及び／又は再分配モジュール（ｒｅｄｉｓｔｒｉｂｕｔｉｏｎｍｏｄｕｌｅ）Ｊ２１００を含む。図面では、放送受信機の外部及び／又は内部に存在し得る外部管理装置（ＥｘｔｅｒｎａｌＭａｎａｇｅｍｅｎｔ）Ｊ２１１０が示されている。

サービスコンテンツ取得制御器Ｊ２０１０は、ブロードキャスト／ブロードバンドチャネルを介してサービス及び／又はコンテンツ、これと関連したシグナリングデータを受信する。又は、サービスコンテンツ取得制御器Ｊ２０１０は、サービス及び／又はコンテンツ、これと関連したシグナリングデータを受信するための制御を行うことができる。

インターネットインターフェースＪ２０２０は、インターネットアクセスコントロールモジュール（ＩｎｔｅｒｎｅｔＡｃｃｅｓｓＣｏｎｔｒｏｌＭｏｄｕｌｅ）を含むことができる。インターネットアクセスコントロールモジュールは、ブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。又は、インターネットアクセスコントロールモジュールは、サービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御することができる。

放送網インターフェースＪ２０３０は、物理層モジュール（ＰｈｙｓｉｃａｌＬａｙｅｒＭｏｄｕｌｅ）及び／又は物理層インターフェースモジュール（ＰｈｙｓｉｃａｌＬａｙｅｒＩ／ＦＭｏｄｕｌｅ）を含むことができる。物理層モジュールは、放送チャネルを介して放送関連信号を受信する。物理層モジュールは、放送チャネルを介して受信した放送関連信号を処理（復調、復号など）する。物理層インターフェースモジュールは、物理層モジュールから取得した情報から、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）データグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、放送フレーム、ＲＳフレーム、又はＧＳＥなど）に変換する。

シグナリングデコーダＪ２０４０は、ブロードキャストチャネルなどを解して取得したシグナリングデータ又はシグナリング情報（以下、‘シグナリングデータ’という。）をデコードする。

サービスマップデータベースＪ２０５０は、デコードされたシグナリングデータを保存したり、受信機の他の装置（例えば、シグナリングパーサーなど）で処理されたシグナリングデータを保存する。

デコーダＪ２０６０は、受信機で受信した放送信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールドストリーミングデコーダ（ＳｃｈｅｄｕｌｅｄＳｔｒｅａｍｉｎｇＤｅｃｏｄｅｒ）、ファイルデコーダ（ＦｉｌｅＤｅｃｏｄｅｒ）、ファイルデータベース（ＦｉｌｅＤＢ）、オンデマンドストリーミングデコーダ（Ｏｎ−ＤｅｍａｎｄＳｔｒｅａｍｉｎｇＤｅｃｏｄｅｒ）、コンポーネント同期化器（ＣｏｍｐｏｎｅｎｔＳｙｎｃｈｒｏｎｉｚｅｒ）、警報シグナリングパーサー（ＡｌｅｒｔＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）、ターゲッティングシグナリングパーサー（ＴａｒｇｅｔｉｎｇＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）、サービスシグナリングパーサー（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）及び／又はアプリケーションシグナリングパーサー（ＡｐｐｌｉｃａｔｉｏｎＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）を含むことができる。

スケジュールドストリーミングデコーダ（ＳｃｈｅｄｕｌｅｄＳｔｒｅａｍｉｎｇＤｅｃｏｄｅｒ）は、ＩＰデータグラムなどから実時間Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリーミングのためのオーディオ／ビデオデータ抽出し、これをデコードする。

ファイルデコーダ（ＦｉｌｅＤｅｃｏｄｅｒ）は、ＩＰデータグラムから、ＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態データを抽出し、これをデコードする。

ファイルデータベース（ＦｉｌｅＤＢ）は、ファイルデコーダから抽出したデータを保存する。

オンデマンドストリーミングデコーダ（Ｏｎ−ＤｅｍａｎｄＳｔｒｅａｍｉｎｇＤｅｃｏｄｅｒ）は、ＩＰデータグラムなどでからユーザ要求（ｏｎ−ｄｅｍａｎｄ）ストリーミングのためのオーディオ／ビデオデータを抽出し、これをデコードする。

コンポーネント同期化器（ＣｏｍｐｏｎｅｎｔＳｙｎｃｈｒｏｎｉｚｅｒ）は、スケジュールドストリーミングデコーダ、ファイルデコーダ及び／又はオンデマンドストリーミングデコーダでデコードされたデータに基づいて、コンテンツを構成する要素間の同期化を行ったり、サービスを構成する要素間の同期化を行い、コンテンツ又はサービスを構成する。

警報シグナリングパーサー（ＡｌｅｒｔＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）は、ＩＰデータグラムなどから警報（ａｌｅｒｔｉｎｇ）と関連したシグナリング情報を抽出し、これをパースする。

ターゲッティングシグナリングパーサー（ＴａｒｇｅｔｉｎｇＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツ個人化、又はターゲッティング関連したシグナリング情報を抽出し、これをパースする。ここで、ターゲッティングとは、特定視聴者の条件に合うコンテンツ又はサービスを提供することであり、当該視聴者の条件に合うコンテンツ又はサービスを識別してそれを提供する行為を指す。

サービスシグナリングパーサー（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）は、ＩＰデータグラムなどからサービススキャン及び／又はサービス／コンテンツなどに関連したシグナリング情報を抽出し、これをパースする。サービス／コンテンツなどに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。

アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからアプリケーションの取得に関連したシグナリング情報を抽出し、これをパースする。アプリケーションの取得に関連したシグナリング情報は、トリガー、ＴＰＴ（ＴＤＯｐａｒａｍｅｔｅｒｔａｂｌｅ）及び／又はＴＤＯパラメータエレメントを含むことができる。

ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーでパースされたサービス／コンテンツターゲッティング関連情報を処理する。

プロセッサＪ２０８０は、受信したデータをディスプレイするための一連の処理を行う。プロセッサＪ２０８０は、警報プロセッサ（ＡｌｅｒｔＰｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓｏｒ）及び／又はオーディオ／ビデオプロセッサ（Ａ／ＶＰｒｏｃｅｓｓｏｒ）を含むことができる。

警報プロセッサは、警報と関連したシグナリング情報を用いて、警報データを取得するように受信機を制御し、警報データをディスプレイするための処理を行う。

アプリケーションプロセッサは、アプリケーション関連情報を処理し、ダウンロードされたアプリケーションの状態及びアプリケーションに関連したディスプレイパラメータを処理する。

オーディオ／ビデオプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリング関連動作を行う。

管理ユニットＪ２０９０は、装置マネジャー（ｄｅｖｉｃｅｍａｎａｇｅｒ）及び／又はデータ通信及びシェアリングユニット（ＤａｔａＳｈａｒｉｎｇ＆ＣｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｔ）を含む。

装置マネジャーは、連結及びデータ交換などの連動可能な外部装置の追加／削除／更新などの外部装置に対する管理を行う。

データ通信及びシェアリングユニットは、受信機と外部装置（例えば、コンパニオン装置（ｃｏｍｐａｎｉｏｎｄｅｖｉｃｅ））間のデータ伝送及び交換関連情報を処理し、これと関連した動作を行う。伝送及び交換可能なデータは、シグナリングデータ、ＰＤＩｔａｂｌｅ、ＰＤＩｕｓｅｒｄａｔａ、ＰＤＩＱ＆Ａ及び／又はＡ／Ｖデータであってもよい。

再分配モジュールＪ２１００は、受信機が放送信号を直接受信できない場合、放送サービス／コンテンツ関連情報及び／又はサービス／コンテンツデータの取得を行う。

外部管理装置Ｊ２１１０は、放送サービス／コンテンツサーバーなど、放送サービス／コンテンツ提供のための放送受信機の外部のモジュールのことを指す。外部管理装置の役割を担うモジュールは、放送受信機の内部に設けられてもよい。

本発明の一実施例に係る放送信号受信機（又は受信機）は、図１乃至図２９で説明した放送信号を処理するＴＶ受信機（ＴＶｒｅｃｅｉｖｅｒ）又は受信機（ｒｅｃｅｉｖｅｒ）を含むことができる。本発明の一実施例に係る放送信号受信機は、ブロードキャストチャネル（ｂｒｏａｄｃａｓｔｃｈａｎｎｅｌ）を介して伝送される放送信号（ｂｒｏａｄｃａｓｔｓｉｇｎａｌｓ）だけでなく、ブロードバンドチャネル（ｂｒｏａｄｂａｎｄｃｈａｎｎｅｌ）を介して伝送されるコンテンツを受信することができる。本発明の一実施例に係る放送信号及びコンテンツが提供するサービスをハイブリッド放送サービス（ｈｙｂｒｉｄｂｒｏａｄｃａｓｔｓｅｒｖｉｃｅ）と呼ぶことができる。名称及び定義は、設計者の意図によって変更可能である。

以下では、本発明の一実施例に係るマルチキャスト（Ｍｕｌｔｉｃａｓｔ）環境でのＡＣＲを介したシグナリング（ｓｉｇｎａｌｉｎｇ）方法について説明する。

ＡＣＲ技法は、ブロードキャストチャネルを介したシグナリングを行うことができない、ＳＴＢ（ＳｅｔＴｏｐＢｏｘ；セットトップボックス）を用いる状況で使用され、主にＡＣＲ技法により、現在視聴しているチャネル（ｃｈａｎｎｅｌ）やプログラム（ｐｒｏｇｒａｍ）の情報を取得する。このように、現在視聴中の放送のチャネルやプログラムの認識結果に基づいて別途のシグナリングサーバーにブロードバンドチャネルを介してシグナリング情報を要求することができ、ユニキャスト（ｕｎｉｃａｓｔ）の形態の構造を有することができる。しかし、本発明で提示するハイブリッド放送サービスでは、ブロードキャスター（ｂｒｏａｄｃａｓｔｅｒ）が放送網ではなく、ブロードバンドチャネルを介してマルチキャストでシグナリング情報を送出することができ、受信機は、これを受信及びシグナリングすることができる。

図６３は、本発明の一実施例に係るマルチキャスト環境でのＡＣＲ送受信システムを示す。

上述したように、ＳＴＢを使用する環境の場合、受信機は、放送網を介して伝達されるシグナリング情報を受信することができない。しかし、ＡＣＲスキーム（ＡＣＲｓｃｈｅｍｅ）を介して現在視聴中のチャネル又はプログラムなどのようなシグナリングの取得のための最小限の情報を受信する場合、既存に使用されていた周期的な要求（ｒｅｑｕｅｓｔ）及び応答（ｒｅｓｐｏｎｓｅ）手順なしにも、マルチキャストを介してシグナリングを直接受信することができる。

図６３は、本発明の一実施例に係る受信機がマルチキャストを介してシグナリング情報を受信する過程を示す。図６３に示されたブロックの動作は、上述したものと同一であるので、以下では、マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作について説明する。

受信機は、ブロードバンドに接続できる場合（すなわち、インタネットを使用できる場合）、マルチキャストセッション（Ｍｕｌｔｉｃａｓｔｓｅｓｓｉｏｎ）にジョイン（接続）（Ｊｏｉｎ）することができる。

その後、受信機は、ＡＣＲスキームを介してＳＴＢに伝達されるＡ／Ｖに基づいて、現在受信中の放送信号又は放送情報を検出（ｄｅｔｅｃｔｉｏｎ）することができる。

その後、受信機は、認識した放送情報を用いて、マルチキャストを介して伝送されるシグナリング情報のうち必要なシグナリング情報をパース（ｐａｒｓｉｎｇ）し、関連サービスをユーザに提供することができる。

図６４は、本発明の一実施例に係るマルチキャスト環境でのＷＭを介したＡＣＲ送受信システムを示す。

図面の上端は、ＷＭにシグナリングサーバーのアドレスが挿入された場合のＡＣＲ送受信システムを示し、図面の下端は、ＷＭにＡＣＲサーバーのアドレスのみが挿入され、受信機が当該ＡＣＲサーバーに要求及び応答方式で現在視聴中の放送のチャネル、プログラム、シグナリングサーバーのアドレスなどを取得する場合のＡＣＲ送受信システムを示す。

図６４に示されたブロックの動作は、上述したものと同一であるので、以下では、マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作について説明する。

図面の上端に示された送受信システムの場合、ＷＭにシグナリングサーバー（ＳｉｇｎａｌｉｎｇＳｅｒｖｅｒ）のアドレスが挿入されているので、受信機は、ＷＭを抽出した後、当該シグナリングサーバーのアドレスを取得し、シグナリングサーバーセッション（ｓｉｇｎａｌｉｎｇｓｅｒｖｅｒｓｅｓｓｉｏｎ）にジョイン（ｊｏｉｎ）してシグナリング情報を受けることができる。

図面の下端に示された送受信システムの場合、ＷＭにはＡＣＲサーバーのアドレスのみが挿入されているので、受信機は、ＡＣＲサーバーからシグナリングサーバーのアドレスを取得することができる。

マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作は、図６３で説明したものと同一であるので、具体的な説明は省略する。

図６５は、本発明の一実施例に係るマルチキャスト環境でのＦＰ方式を介したＡＣＲ送受信システムを示す。

上述したように、受信機は、オーディオ／ビデオ信号からＦＰを抽出することができる。その後、受信機は、抽出したシグネチャー（又はＦＰ）をＦＰサーバー（ＦＰＳｅｒｖｅｒ）に伝送し、ＦＰサーバーから現在のチャネル、プログラムなどの情報以外に、シグナリングサーバーのアドレスを受信することができる。その後、受信機は、サーバーセッションにジョイン（接続）（ｊｏｉｎ）してシグナリング情報を受けることができる。

図６６は、本発明の一実施例に係る受信機がマルチキャスト環境でＡＣＲスキームを介して放送と関連するシグナリングを行うフローチャートを示す。

サービスプロバイダは、放送網だけでなくブロードバンドチャネル（ｂｒｏａｄｂａｎｄｃｈａｎｎｅｌ）を介しても、放送に関するシグナリング情報をマルチキャストで伝送することができる。これを受信した受信機は、当該シグナリング情報を取得するためにマルチキャストセッションにジョインして、当該シグナリングを受信するための通信（ｃｏｍｍｕｎｉｃａｔｉｏｎ）手順を行うことができる。

本発明の一実施例に係る受信機がシグナリングサーバー（又はマルチキャストサーバー）のアドレスを取得する方式は、次の通りである。

第１実施例：受信機は、ＡＣＲサーバーから現在視聴しているチャネルの認識結果を受信するとき、当該チャネルのマルチキャストサーバーのアドレス（例えば、ＵＲＬ、ＩＰアドレスなど）を共に受信することができる。

第２実施例：受信機は、受信機内に各チャネルに関するマルチキャストサーバーのアドレスを直接格納して、ＡＣＲサーバーからチャネル認識結果を受信すると、当該チャネルのマルチキャストサーバーに接近することができる。

上述した実施例は、設計者の意図によって変更可能である。

以下では、図示された受信機がマルチキャスト環境でＡＣＲスキームを介して放送と関連するシグナリングを行うフローチャートを説明する。図面のＡＣＲスキームは、上述したフィンガープリンティング方式の場合を示す。

サービスプロバイダＥ６６０００は、ＡＣＲ業者が提供するツール（Ｔｏｏｌ）を用いてプログラム（Ｃｏｎｔｅｎｔ）別にフィンガープリント（Ｆｉｎｇｅｒｐｒｉｎｔ）を抽出することができる。この場合、サービスプロバイダＥ６６０００は、オーディオ／ビデオフィンガープリントデータベース（Ａｕｄｉｏ／ＶｉｄｅｏｆｉｎｇｅｒｐｒｉｎｔＤＢ）を構築することができる。サービスプロバイダＥ６６０００は、必要であれば、２つのフィンガープリントを全て抽出して格納することができる。サービスプロバイダＥ６６０００は、ＡＣＲサーバーＥ６６１００に、コンテンツ（Ｃｏｎｔｅｎｔ）から抽出したフィンガープリントを伝達することができる。フィンガープリンタが伝達される時点は、プログラムの特性に応じて変わり得る。具体的には、事前に作製されたプログラムの場合、当該プログラムが放送で送出される前に当該フィンガープリントが伝達されてもよく、ライブプログラムの場合、リアルタイムでフィンガープリントが抽出されるとすぐに伝達されてもよい。この場合、サービスプロバイダＥ６６０００は、事前にプログラムに対してコンテンツを唯一に認識できる情報を付与し、リアルタイムで抽出されたフィンガープリントとマッピングして伝達することができる。

ＡＣＲサーバーＥ６６１００は、受信したＦＰ及び関連情報をＡＣＲＤＢに格納することができる。具体的な内容は、図６１で説明したものと同一であるので、省略する。

その後、受信機Ｅ６６２００は、外部入力で受信されたオーディオ／ビデオ信号からフィンガープリントを抽出し、ＡＣＲサーバーＥ６６１００にＡＣＲ質疑要求（ＡＣＲＱｕｅｒｙＲｅｑｕｅｓｔ）を伝送することができる。ＡＣＲサーバーＥ６６１００は、受信したＡＣＲ質疑要求に対応して受信機Ｅ６６２００にＡＣＲ質疑応答（ＡＣＲＱｕｅｒｙＲｅｓｐｏｎｓｅ）を伝送することができる。具体的には、ＡＣＲサーバーＥ６６１００は、ＡＣＲＤＢを検索して、受信したフィンガープリンタとマッチングされるコンテンツを探すことができる。その後、コンテンツが認識されると、ＡＣＲサーバーＥ６６１００は、ＡＣＲ質疑応答を伝送することができる。ＡＣＲ質疑応答は、当該コンテンツのチャネル情報（ｃｈａｎｎｅｌＩｎｆｏ）、シグナリングサーバーのアドレス（Ｍｕｌｔｉｃａｓｔｓｅｒｖｅｒａｄｄｒｅｓｓ）などを含むことができる。

その後、受信機Ｅ６６２００は、受信したＡＣＲ質疑応答に含まれたシグナリングサーバーのアドレスを用いて、当該シグナリングサーバーＥ６６３００にマルチキャストセッションジョイン要求（ｍｕｌｔｉｃａｓｔｓｅｓｓｉｏｎｊｏｉｎｒｅｑｕｅｓｔ）を送信することができる。

シグナリングサーバーのアドレスは、サービスプロバイダ毎に各代表アドレスとして設定してもよく、特定のチャネルを代表するアドレスとして設定してもよい。それぞれの場合によって、サービスプロバイダはサーバーマネジメント（ｓｅｒｖｅｒｍａｎａｇｅｍｅｎｔ）を行うことができる。

また、一つのサービスプロバイダが複数個のチャネルを所有しており、代表アドレスとしてシグナリングサーバーアドレスを設定する場合、受信機は、当該シグナリングサーバーにリクエストを伝送するとき、チャネルＩＤ（ｃｈａｎｎｅｌｉｄ）のようなチャネル識別情報を共に伝達して特定のチャネルに対するシグナリングを行うことができる。

シグナリングサーバーＥ６６３００は、受信したマルチキャストセッションジョイン要求（ｍｕｌｔｉｃａｓｔｓｅｓｓｉｏｎｊｏｉｎｒｅｑｕｅｓｔ）に対応して、受信機Ｅ６６２００に対して認証手順（ａｕｔｈｅｎｔｉｃａｔｉｏｎｐｒｏｃｅｓｓ）を行い、セッションを接続及び維持することができる。受信機Ｅ６６２００とシグナリングサーバーＥ６６３００との間のセッションが接続されると、シグナリングサーバーＥ６６３００は、特別な要求及び応答の伝送なしに、持続的にシグナリング情報を受信機Ｅ６６２００に送信することができる。

受信機Ｅ６６２００は、受信した情報をシグナルし、パースすることができる。当該動作は、シグナリングサーバーのアドレスが変更されるまで繰り返して行われてもよい。また、受信機Ｅ６６２００は、パーシングの結果に基づいて、当該チャネル或いはプログラムのサービスをユーザに提供することができる。

その後、シグナリングサーバーのアドレスが変更されたり、関連シグナリング情報をパースする必要がない場合、受信機Ｅ６６２００は、当該セッションの終了を要求するリクエストを送信し、当該セッションから離れることができる。

ウォーターマーキング（ＷａｔｅｒＭａｒｋｉｎｇ）を使用したＡＣＲスキームの場合、ＷＭの挿入時にシグナリングサーバーのアドレスを挿入することができ、上述したものと同一の過程を介してシグナリングを行うことができる。

図６７は、本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す。

本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムは、ＬＴＥ／ＬＴＥ−ＡサービスのｅＭＢＭＳ（ｅｖｏｌｖｅｄＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ）を結合したシステムである。ｅＭＢＭＳは、既存のＬＴＥ／ＬＴＥ−Ａサービスでモバイル放送サービスを同時に提供できる技術である。したがって、ｅＭＢＭＳを用いる場合、移動通信網を介した放送システムを構築することができる。今後の放送システムの場合、既存の放送網と移動通信網（モバイルブロードバンド）の両方を使用して伝送するハイブリッド放送サービスを提供することができる。ハイブリッド放送サービスの一実施例として、放送網を介しては当該サービスのベースレイヤコンポーネントを伝送し、モバイルブロードバンドを介してはＵＨＤサービスなどのためのエンハンスドレイヤコンポーネントを伝送する場合がある。また、ハイブリッド放送サービスの一実施例として、サービスプロバイダは、従来のｅＭＢＭＳで使用されるテーブルなどを用いて関連シグナリング情報を受信機に伝送する場合がある。

図６７は、本発明の一実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す。

図６７は、本発明の一実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報又は関連放送情報を受信する過程を示す。図６７に示されたブロックの動作は、上述した通りであるので、具体的な内容は省略する。また、図示された受信機に適用できるＡＣＲスキームは、ＷＭ又はＦＰ方式のうち少なくともいずれか１つの方式であってもよい。

図６８は、本発明の他の実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す。図６８は、受信機に適用されたＡＣＲスキームがＷＭ方式である場合を示す。具体的な動作などは、上述した通りであるので省略する。

図６９は、本発明の一実施例に係るハイブリッド放送サービスを示した概念図である。

図１乃至図２９及び図３０乃至図６２で説明した本発明の一実施例に係る放送サービスと上述したｅＭＢＭＳサービスの両方を含むハイブリッド放送サービスは、ユーザに提供される形態によって、図示された２つのサービスに分けられる。

図面の左側に示されたブロックは、それぞれのネットワークで提供する放送データのサービスプロバイダ又はコンテンツが異なる場合のハイブリッド放送サービスを示す。図面の右側に示されたブロックは、各サービスプロバイダが同じコンテンツを各ネットワークで同時に提供する場合のハイブリッド放送サービスを示す。

図面の左側に示されたハイブリッド放送サービスの場合、上述した放送網を介したサービスとｅＭＢＭＳを介して提供されるサービスが、異なるネットワークを介して提供されるため、受信機は、各ネットワーク毎に独立してサービスを取得することができる。また、ネットワーク間の受信機がサービスを取得する手順も異なり得る。

具体的には、本発明では、それぞれのネットワークで提供するコンテンツが異なる場合であって、放送会社（サービスプロバイダＡ）は、放送ネットワークを介してサービスを提供し、通信会社（サービスプロバイダＢ）は、移動通信ネットワークを介してサービスを提供する場合、又はそれぞれの放送コンテンツ業者が通信ネットワークに加入してサービスする場合を一実施例とすることができる。すなわち、放送ネットワークを用いてサービスする主体と、通信ネットワークを用いてサービスする主体とが異なるか、または放送データがユーザにまで伝達される前には別個のシステムを介して処理又は伝送される場合を意味する。この場合、放送サービスは、各ネットワーク別に分離されてユーザにまで処理、伝送されるので、受信機は、各ネットワークに対応するサービスを処理するためのモジュールを含むことができる。

この場合、受信機は、２つのネットワークを介してそれぞれ異なるチャネル／プログラム情報を受信してユーザに提供することができる。この場合、放送網に送出されるサービスは、ＳＴＢを経て受信機に受信され得、シグナリング情報は、ＡＣＲスキームを用いて伝送され得る。したがって、受信機は、上述した方式を用いて放送と関連するシグナリング情報を取得することができる。しかし、ｅＭＢＭＳを介して受信されるチャネル又はプログラム情報は、受信機で直接受信することができるので、ＡＣＲスキームと関係なく適用可能である。

図面の右側に示されたハイブリッド放送サービスの場合、各サービスプロバイダ（Ａ，Ｂ）が同じコンテンツを各ネットワークを介して同時に伝送するので、ハイブリッド放送サービスデータは、放送網とｅＭＢＭＳネットワークに伝達される前、ＩＰバックボーン（ＩＰｂａｃｋｂｏｎｅ）網で適切に分離されてもよい。

この場合、ハイブリッド放送サービスデータは、状況によって放送網及びｅＭＢＭＳネットワークを介して各受信機に伝送されてもよい。

図面の右側に示されたハイブリッド放送サービスの場合、ユーザが放送データを受信するとき、どのシステムから伝送されるデータであるかを確認する必要がなく、既存の放送環境に比べて様々な放送会社及びコンテンツ提供業者から放送データを受信できるという利点がある。また、受信機の設計において、放送関連ＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ、ユーザインターフェース）を単一化して具現することができるので、設計が容易であるという利点がある。

この場合、受信機は、互いに異なるネットワークを介して同じチャネル又はプログラムを受信することができ、ｅＭＢＭＳを介して当該チャネル又はプログラムに関するシグナリング情報を受信することができる。しかし、ｅＭＢＭＳネットワークを一時的又は永久的に使用できない場合、受信機は、ＳＴＢを介して入ってくるＡ／Ｖのみを受信することができ、ｅＭＢＭＳネットワークを利用できないことを確認することができる。このような場合、受信機は、上述したＡＣＲスキームを使用してシグナリング情報を受信することができる。シグナリングサーバーは、受信機にユニキャスト（ｕｎｉｃａｓｔ）又はマルチキャスト（ｍｕｌｔｉｃａｓｔ）方式を用いてシグナリング情報を伝送することができ、これは、上述した通りである。

または、ｅＭＢＭＳネットワークを使用することができるとしても、ユーザが現在視聴している放送のＡ／ＶはＳＴＢを介して伝達される状況である場合、受信機は、現在視聴中の放送コンテンツとｅＭＢＭＳを介して受信したシグナリング情報とをマッピングすることができない。この場合、受信機は、ＡＣＲスキームを用いて現在視聴中の放送のチャネル又はプログラム情報などを認識し、これを通じて、ｅＭＢＭＳで受信するシグナリング情報を受信してサービスを提供することができる。

また、モバイルブロードバンドを介してデータを受信する場合、受信機は、一般的なブロードバンドチャネルではなく、モバイルブロードバンドチャネル（Ｍｏｂｉｌｅｂｒｏａｄｂａｎｄｃｈａｎｎｅｌ）を介してシグナリング情報を送受信することもできる。これは、設計者意図によって変更可能な事項である。

図７０は、本発明の他の実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す。

図７０は、上述したハイブリッド放送サービスの他の実施例であって、ＳＴＢが２つのネットワークを介してデータを受信し、外部入力などを介して当該データが受信機に伝達される場合を示す。

図示のように、放送網を介して伝送される放送データは、ＳＴＢを介して最終的に受信機に伝達されてもよい。また、ＳＴＢは、ｅＭＢＭＳ−ｃａｐａｂｌｅな特性を有しているので、ｅＭＢＭＳを介して伝送される放送データを受信することができる。この場合、サービスプロバイダはＭＶＰＤの役割を行うことができる。

したがって、放送網とｅＭＢＭＳを介して伝送されるＡ／Ｖ及び関連シグナリング情報は、いずれもＳＴＢを経て受信機に伝送されるので、受信機は、Ａ／Ｖのみをユーザに提供することができる。この場合、基本的なＡＣＲ環境と同一であるので、受信機は、ＡＣＲスキームを介して現在視聴中のチャネル／プログラムを認識した後、シグナリングサーバーからシグナリング情報を受信してサービスを提供することができる。具体的な内容は上述した通りであるので、省略する。

本発明のＡＣＲスキームは、ＷＭ方式及びＦＰ方式の両方に適用可能である。また、ＷＭ方式の場合、サービスプロバイダによって伝送されるＡ／Ｖに挿入されたＷＭは、ＳＴＢを経て受信機に伝達されるとしてもフィルタリング（ｆｉｌｔｅｒｉｎｇ）されない。

図７１は、本発明の一実施例に係る、次世代放送システムのためのプロトコルスタック（ＰｒｏｔｏｃｏｌＳｔａｃｋ）を示す図である。

本発明に係る放送システムは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）中心ブロードキャストネットワーク（ＩＰｃｅｎｔｒｉｃｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋ）とブロードバンド（ｂｒｏａｄｂａｎｄ）とが結合されたハイブリッド放送システムに該当し得る。

本発明に係る放送システムは、既存のＭＰＥＧ−２ベースの放送システムとの互換性が維持されるように設計することができる。

本発明に係る放送システムは、ＩＰ中心ブロードキャストネットワーク（ＩＰｃｅｎｔｒｉｃｂｒｏａｄｃａｓｔｎｅｔｗｏｒｋ）、ブロードバンド（ｂｒｏａｄｂａｎｄ）ネットワーク、及び／又は移動通信ネットワーク（ｍｏｂｉｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｎｅｔｗｏｒｋ又はｃｅｌｌｕｌａｒｎｅｔｗｏｒｋ）の結合に基づくハイブリッド放送システムに該当してもよい。

同図を参照すると、物理層（Ｐｈｙｓｉｃａｌｌａｙｅｒ）は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。例えば、本発明に係る物理層では、送／受信機は地上波放送信号を送信／受信し、放送データを含む伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）を適切な形態に変換することができる。

暗号化（Ｅｎｃａｐｓｕｌａｔｉｏｎ）層では、物理層から取得した情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得したＩＰデータグラムを特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。例えば、暗号化層で送信機は、物理層で処理されたデータを伝送フレームに含めたり、受信機は、物理層から取得した伝送フレームからＭＰＥＧ−２ＴＳ、ＩＰデータグラムを抽出する。

ＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツに接近可能にさせるための情報（例、サービスＩＤとフレームとのマッピング情報など）を含む。ＦＩＣはＦＡＣ（ＦａｓｔＡｃｃｅｓｓＣｈａｎｎｅｌ）と命名されてもよい。

本発明の放送システムは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＡＬＣ／ＬＣＴ（ＡｓｙｎｃｈｒｏｎｏｕｓＬａｙｅｒｅｄＣｏｄｉｎｇ／ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（ＲａｔｅＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＲＴＰＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＦＬＵＴＥ（ＦｉｌｅＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタック（ｓｔａｃｋ）については同図に示す構造を参照すればよい。

本発明の放送システムにおいてデータは、ＩＳＯＢＭＦＦ（ＩＳＯｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ）の形態で伝送することができる。ＥＳＧ（ＥｌｅｃｔｒｉｃａｌＳｅｒｖｉｃｅＧｕｉｄｅ）、ＮＲＴ（ＮｏｎＲｅａｌＴｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。

ブロードキャストネットワークによるデータの伝送は、線形コンテンツ（ｌｉｎｅａｒｃｏｎｔｅｎｔ）の伝送及び／又は非線形コンテンツ（ｎｏｎ−ｌｉｎｅａｒｃｏｎｔｅｎｔ）の伝送を含むことができる。

ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ、データ（ｃｌｏｓｅｄｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙａｌｅｒｔｍｅｓｓａｇｅなど）の伝送は、線形コンテンツの伝送に該当し得る。

ＲＴＰペイロードは、ＮＡＬ（ＮｅｔｗｏｒｋＡｂｓｔｒａｃｔｉｏｎＬａｙｅｒ）が含まれたＲＴＰ／ＡＶストリーム形態及び／又はＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＲＴＰペイロードの伝送は線形コンテンツの伝送に該当し得る。ＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧＤＡＳＨｍｅｄｉａｓｅｇｍｅｎｔを含むことができる。

ＦＬＵＴＥベースのＥＳＧの伝送、ｎｏｎ−ｔｉｍｅｄｄａｔａの伝送、ＮＲＴｃｏｎｔｅｎｔの伝送は、非線形コンテンツの伝送に該当し得る。それらは、ＭＩＭＥｔｙｐｅのファイル形態及び／又はＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態で伝送されてもよい。ＩＳＯｂａｓｅｄｍｅｄｉａｆｉｌｅｆｏｒｍａｔで暗号化された形態の伝送はＡ／Ｖなどに対するＭＰＥＧＤＡＳＨｍｅｄｉａｓｅｇｍｅｎｔを含むことができる。

ブロードバンドネットワークによる伝送は、コンテンツに対する伝送とシグナリングデータに対する伝送とに区分して考えることができる。

コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ、データ（ｃｌｏｓｅｄｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙａｌｅｒｔｍｅｓｓａｇｅなど）の伝送と非線形コンテンツ（ＥＳＧ、ｎｏｎ−ｔｉｍｅｄｄａｔａなど）の伝送、ＭＰＥＧＤＡＳＨベースのＭｅｄｉａｓｅｇｍｅｎｔ（Ａ／Ｖ、ｄａｔａ）伝送を含む。

シグナリングデータの伝送は、放送網で伝送されるシグナリングテーブル（ｓｉｇｎａｌｉｎｇｔａｂｌｅ）（ＭＰＥＧＤＡＳＨのＭＰＤを含む）を含む伝送が可能である。

本発明の放送システムでは、放送網を介して送信された線形／非線形コンテンツ間の同期化、或いは放送網を介して伝送されるコンテンツとブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが放送網とブロードバンドで分離されて同時に伝送される場合、受信機は、伝送プロトコルに依存したタイムライン（ｔｉｍｅｌｉｎｅ）を調整し、放送網のコンテンツとブロードバンドのコンテンツとを同期化した後、一つのＵＤコンテンツとして再構成することができる。

本発明の放送システムのアプリケーション層は、両方向性（Ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン（ＳｅｃｏｎｄＳｃｒｅｅｎ）、ＡＣＲ（ａｕｔｏｍａｔｉｃｃｏｎｔｅｎｔｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特徴を具現することができる。このような特徴は、例えば、北米放送標準であるＡＴＳＣ２．０からＡＴＳＣ３．０への拡張において重要な特徴である。例えば、両方向性の特徴のために、ＨＴＭＬ５が用いられてもよい。

本発明の放送システムのプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）層では、コンポーネント間又は両方向アプリケーション間の空間的、時間的関係を識別するためにＨＴＭＬ及び／又はＨＴＭＬ５が用いられてもよい。

本発明でシグナリング（Ｓｉｇｎａｌｉｎｇ）は、コンテンツ及び／又はサービスの効果的な取得を支援するためのシグナリング情報を含む。シグナリングデータは、バイナリ或いはＸＭＬ形態などで表現することができ、地上波放送網或いはブロードバンドを介して伝達することができる。

実時間放送Ａ／Ｖコンテンツ及び／又はデータの場合、ＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔなどで表現することができる。この場合、放送Ａ／Ｖコンテンツ及び／又はデータは、地上波放送網を介して実時間で伝達されてもよく、ＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて非実時間で伝達されてもよい。又は、放送Ａ／Ｖコンテンツ及び／又はデータに対して、インターネット網を介してＤＡＳＨ（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）などを用いて実時間でコンテンツのストリーミングを受けたり、要求して受けることができる。本発明の一実施例に係る放送システムは、このようにして受けた放送Ａ／Ｖコンテンツ及び／又はデータを組み合わせ、両方向性サービス、第２スクリーンサービスなどの様々なエンハンスドサービスを視聴者に提供することができる。

図７２は、本発明の一実施例に係る、伝送フレーム（ＴｒａｎｓｐｏｒｔＦｒａｍｅ）を示す図である。

本発明の一実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）で伝達されるデータの集合を示す。

本発明の一実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、共通ＰＬＰ（ｃｏｍｍｏｎＰＬＰ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）を含むことができる。ここで、共通ＰＬＰを共通データユニットと命名してもよい。

Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機はＰ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。

Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）の構成に関する情報を含む。受信機はＬ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。

共通ＰＬＰは、ＰＬＰｎに共通に適用されるサービス情報を含む。受信機は、共通ＰＬＰを通じてＰＬＰ間の共有すべき情報を取得することができる。伝送フレーム（Ｔｒａｎｓｐｏｒｔｆｒａｍｅ）の構造によって共通ＰＬＰが存在しなくてもよい。Ｌ１データは、伝送フレームに共通ＰＬＰが含まれるか否かを識別する情報を含むことができる。

ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰで伝送されるかを識別する情報は、Ｌ１データ或いは共通ＰＬＰに含まれてもよい。

補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）は、次世代放送システムで追加される変調方式、コーディング方式及び／又はデータ処理方式のためのデータを含むことができる。例えば、補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）は、新しく定義されるデータ処理方式を識別する情報を含むことができる。補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）は、将来拡張されるシステムによる、伝送フレームの拡張に用いられてもよい。

図７３は、本発明の他の実施例に係る、伝送フレーム（ＴｒａｎｓｐｏｒｔＦｒａｍｅ）を示す図である。

本発明の他の実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）で伝達されるデータの集合を示す。

本発明の他の実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙｄａｔａ）を含むことができる。

Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機は、Ｐ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。

Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）の構成に関する情報を含む。受信機は、Ｌ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。

ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）は、受信機が特定周波数内の放送サービス及びコンテンツに対するスキャンを速かに行えるようにするために、別のチャネルで定義されてもよい。このチャネルは、物理チャネル又は論理チャネルと定義されてもよく、このようなチャネルで放送サービスに関連した情報を伝送／受信することができる。

本発明の他の実施例によれば、ＦＩＣを用いて、伝送フレームに含まれた放送サービス及び／又はコンテンツとこれに関連した情報を受信機が速かに取得することができる。これと加えて、当該伝送フレームに、一つ以上の放送局で生成したサービス／コンテンツが存在する場合、受信機はＦＩＣを用いて、放送局によるサービス／コンテンツを認知して処理することができる。

ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰに伝送されるかを識別する情報がＬ１データ或いは共通ＰＬＰに含まれてもよい。

図７４は、本発明の一実施例に係る、放送システムのＴＰ（ＴｒａｎｓｐｏｒｔＰａｃｋｅｔ）及びｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。

放送システムのＴＰは、Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報、Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報、Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報、Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報、Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報及び／又はペイロード（Ｐａｙｌｏａｄ）を含むことができる。

Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報は、図示のように、ＴＰのペイロードがどのネットワークプロトコルタイプを有するかを示す。

Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰに誤りが検出されたか否か表示する情報である。例えば、当該情報の値が０であれば、誤りが検出されていないことを示し、１であれば、誤りが検出されたことを示すことができる。

Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰにスタッフィングバイト（ｓｔｕｆｆｉｎｇｂｙｔｅ）が含まれているか否かを示す。例えば、当該情報の値が０であれば、スタッフィッグバイトを含んでいないことを示し、１である場合、ペイロードの前に長さフィールド（ｌｅｎｇｔｈｆｉｅｌｄ）とスタッフィッグバイトを含むことを示すことができる。

Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報は、当該ＴＰのペイロード部分に新しいネットワークプロトコルパケットの開始部分を表示する。例えば、当該情報は、Ｔｈｅｍａｘｉｍｕｍｖａｌｕｅ（０ｘ７ＦＦ）を有することによって、新しいネットワークプロトコルパケットの開始部分がないことを示すことができる。当該情報が他の値を有する場合、ヘッダーの最後の部分から新しいネットワークプロトコルパケットの開始部分までのオフセット値に該当し得る。

Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報は、ｓｔｕｆｆｉｎｇ＿ｉｎｄｉｃａｔｏｒ情報の値が１のとき、ヘッダー（ｈｅａｄｅｒ）とペイロードとの間を埋める値である。

ＴＰのペイロードはＩＰデータグラムを含むことができる。このような形態のＩＰデータグラムは、ＧＳＥ（ＧｅｎｅｒｉｃＳｔｒｅａｍＥｎｃａｐｓｕｌａｔｉｏｎ）などを用いて暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）され、伝送されてもよい。伝送される特定ＩＰデータグラムは、受信機がサービス／コンテンツをスキャンし、これを取得するために必要なシグナリング情報を含むことができる。

図７５は、本発明の一実施例に係る、放送サーバー及び受信機を示す図である。

本発明の一実施例に係る受信機は、シグナリングパーサー（ＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）Ｊ１０７０２０、アプリケーションマネジャー（ＡｐｐｌｉｃａｔｉｏｎＭａｎａｇｅｒ）Ｊ１０７０３０、ダウンロードマネジャー（ＤｏｗｎｌｏａｄＭａｎａｇｅｒ）Ｊ１０７０６０、装置保存所（ＤｅｖｉｃｅＳｔｏｒａｇｅ）Ｊ１０７０７０、及び／又はアプリケーションデコーダ（ＡｐｐｌｉｃａｔｉｏｎＤｅｃｏｄｅｒ）Ｊ１０７０８０を含む。放送サーバーは、コンテンツプロバイダ／放送会社（ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ／Ｂｒｏａｄｃａｓｔｅｒ）Ｊ１０７０１０及び／又はアプリケーションサービスサーバー（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅＳｅｒｖｅｒ）Ｊ１０７０５０を含む。

放送サーバー又は受信機に含まれるそれぞれの装置は、ハードウェア又はソフトウェアによって具現することができる。各装置がハードウェアによって具現される場合、‘マネジャー’のような表現は‘プロセッサ’に代替してもよい。

コンテンツプロバイダ／放送会社Ｊ１０７０１０は、コンテンツプロバイダ或いは放送会社を意味する。

シグナリングパーサーＪ１０７０２０は、コンテンツプロバイダ或いは放送会社で提供する放送信号をパースするモジュールである。放送信号は、シグナリングデータ／エレメント、放送コンテンツデータ、放送と関連した付加データ及び／又はアプリケーションデータを含むことができる。

アプリケーションマネジャーＪ１０７０３０は、放送信号にアプリケーションが含まれた場合、当該アプリケーションを管理するモジュールである。アプリケーションマネジャーＪ１０７０３０は、前述したシグナリング情報、シグナリングエレメント、ＴＰＴ及び／又はトリガーを用いて、アプリケーションの位置、動作、動作実行タイミングを制御する。ここで、アプリケーションの動作は、Ａｃｔｉｖａｔｅ（Ｌａｕｎｃｈ）、Ｓｕｓｐｅｎｄ、Ｒｅｓｕｍｅ、又はＴｅｒｍｉｎａｔｅ（Ｅｘｉｔ）であってもよい。

アプリケーションサービスサーバーＪ１０７０５０は、アプリケーションを提供するサーバーである。アプリケーションサービスサーバーＪ１０７０５０は、コンテンツプロバイダ或いは放送会社によって提供されてもよく、この場合、コンテンツプロバイダ／放送会社Ｊ１０７０１０に含まれてもよい。

ダウンロードマネジャーＪ１０７０６０は、コンテンツプロバイダ／放送会社Ｊ１０７０１０及び／又はアプリケーションサービスサーバーＪ１０７０５０で提供するＮＲＴコンテンツ又はアプリケーションに関連した情報を処理するモジュールである。ダウンロードマネジャーＪ１０７０６０は、放送信号に含まれたＮＲＴ関連シグナリング情報を取得し、シグナリング情報に基づいて、放送信号に含まれたＮＲＴコンテンツを抽出する。ダウンロードマネジャーＪ１０７０６０は、アプリケーションサービスサーバーＪ１０７０５０が提供するアプリケーションを受信処理することができる。

装置保存所Ｊ１０７０７０は、受信した放送信号、データ、コンテンツ及び／又はシグナリング情報（シグナリングエレメント）を保存することができる。

アプリケーションデコーダＪ１０７０８０は、受信したアプリケーションをデコードし、画面に表出する処理を行うことができる。

図７６は、本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ及びサービスタイプ間の付加サービス関係と共に、別個のサービスタイプを示す図である。

線形サービスは、一般的にＴＶに伝達し、また、ビデオデコーディング／ディスプレイキャパビリティ（オーディオのみ）を有しない受信装置に適したサービスに用いることができる。線形サービスは、単一タイムベースを有し、ゼロ以上の提示可能（ｐｒｅｓｅｎｔａｂｌｅ）ビデオコンポーネント、ゼロ以上の提示可能オーディオコンポーネント、及びゼロ以上の提示可能ＣＣコンポーネントを有することができる。線形サービスはまた、ゼロ以上のアプリケーションベースエンハンスメントを有することができる。

アプリケーションクラスは、ＡＴＳＣアプリケーションのためのコンテンツアイテム（又は、データアイテム）を示す。関係は、コンテンツアイテム（又は、データアイテム）クラスとのサブクラス関係を含む。

アプリケーションベースエンハンスメントクラスは、ＴＶサービス（又は、線形サービス）に対するアプリケーションベースエンハンスメントを示す。属性は、必須キャパビリティ［０．．１］、非必須キャパビリティ［０．．１］、ターゲット装置［０．．ｎ］を含み、可能な値は“プライマリ装置”、“コンパニオン装置”を含む。

関係は、アプリケーションクラスとの“包含（Ｃｏｎｔａｉｎｓ）”関係、コンテンツアイテム（又は、データアイテム）コンポーネントクラスとの“包含”関係、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）ストリームクラスとの“包含”関係及び／又はオンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの“包含”関係を含むことができる。

タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。タイムベースは以下の属性を含むことができる。

クロックレートは、このタイムベースのクロックレートを示す。

アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。関係は、アプリケーションベースエンハンスメントクラスとの“包含”関係及び／又はサービスクラスとの“サブクラス”関係を含むことができる。

アプリケーションベースエンハンスメントは、次のものを含むことができる。
取るアクションの通知を伝達する通知ストリーム
一つ以上のアプリケーション（アプリ）
アプリによって用いられるゼロ以上の他のコンテンツアイテム（又は、データアイテム、ＮＲＴコンテンツアイテム）
アプリによって管理されるゼロ以上のオンデマンドコンポーネント

アプリケーションベースエンハンスメント内のアプリのうちのゼロ又は一つがプライマリアプリとして指定されてもよい。指定されたプライマリアプリが存在すれば、それの属するサービスが選択されるやいなや活性化される。アプリはまた、通知ストリーム内の通知によって活性化されたり、一つのアプリが既に活性化された他のアプリによって活性化されてもよい。

アプリケーションベースのサービスは、一つ以上のアプリケーションベースエンハンスメントを含むサービスである。アプリケーションベースのサービス内の一つのアプリケーションベースエンハンスメントは、指定されたプライマリアプリを含むことができる。アプリケーションベースのサービスは選択的にタイムベースを含むことができる。

アプリは、コンテンツアイテム（又は、データアイテム）の特殊な場合、すなわち、共にアプリを構成するファイルの集合（ｃｏｌｌｅｃｔｉｏｎ）である。

図７７は、本発明の実施例として、ＮＲＴコンテンツアイテムクラス及びＮＲＴファイルクラス間の包含関係を示す。

ＮＲＴコンテンツアイテムは一つ以上のＮＲＴファイルを含み、ＮＲＴファイルは一つ以上のＮＲＴコンテンツアイテムに属することができる。

それらのクラスを検討する一方法は、ＮＲＴコンテンツアイテムが基本的に提示可能ＮＲＴファイルベースコンポーネント、すなわち、他のファイルと結合しないで消費されてもよいＮＲＴファイルセットであってもよく、ＮＲＴファイルが基本的にエレメンタリＮＲＴファイルベースコンポーネント、すなわち、原子単位のコンポーネントであってもよいということである。

ＮＲＴコンテンツアイテムは、連続したコンポーネント、不連続したコンポーネント、又はその組合せを含むことができる。

図７８は、本発明の一実施例に係る、サービスタイプ及びコンポーネントタイプによる属性を示すテーブルである。

アプリケーション（Ａｐｐ）は、両方向性を支援するＮＲＴコンテンツアイテムの一種である。アプリケーションの属性は、ＴＰＴなどのようなシグナリングデータによって提供されてもよい。アプリケーションは、ＮＲＴコンテンツアイテムクラスとはサブクラスの関係にある。例えば、ＮＲＴコンテンツアイテムには一つ以上のアプリケーションが含まれてもよい。

アプリケーションベースエンハンスメント（Ａｐｐ−ＢａｓｅｄＥｎｈａｎｃｅｍｅｎｔ）は、アプリケーションベースに向上したイベント／コンテンツのことをいう。

アプリケーションベースエンハンスメントの属性には、次の内容が含まれてもよい。

必須キャパビリティ［０．．１］−エンハンスメントの意味のあるレンディション（ｒｅｎｄｉｔｉｏｎ）に必要な受信機キャパビリティ。

非必須キャパビリティ［０．．１］−エンハンスメントの最上のレンディションに有用であるが、エンハンスメントの意味のあるレンディションに必須のものではない受信機キャパビリティ。

ターゲット装置［０．．ｎ］−単に付加（ａｄｊｕｎｃｔ）データサービスのために可能な値。

ターゲットデバイスは、プライマリデバイスとコンパニオン（ｃｏｍｐａｎｉｏｎ）デバイスとに区別することができる。プライマリデバイスとしてはＴＶ受信機のような装置を含むことができる。コンパニオンデバイスとしては、スマートフォン、タブレット、ノートパソコン及び／又は小型モニタを含むことができる。

アプリケーションベースエンハンスメントは、Ａｐｐクラスとの関係を含み、これはアプリケーションベースエンハンスメントに含まれるアプリケーションとの関係のためのものであろう。

アプリケーションベースエンハンスメントは、ＮＲＴコンテンツアイテムクラスとの関係を含み、これは、アプリケーションベースエンハンスメントに含まれるアプリケーションによって用いられるＮＲＴコンテンツアイテムとの関係のためのものである。

アプリケーションベースエンハンスメントは、通知ストリーム（ＮｏｔｉｆｉｃａｔｉｏｎＳｔｒｅａｍ）クラスとの関係を含み、これは、アプリケーションの動作と基本線形（Ｌｉｎｅａｒ）タイムベースとの同期化のための通知を送信する通知ストリームとの関係のためのものである。

アプリケーションベースエンハンスメントは、オンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの関係を含み、これは、アプリケーションによって管理される視聴者要求コンポーネントとの関係のためのものである。

図７９は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。

タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。

タイムベースの属性は、タイムベースＩＤ及び／又はクロックレートを含むことができる。

タイムベースＩＤは、タイムベースの識別子である。クロックレートはタイムベースのクロックレートに対応する。

図８０は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。

線形サービスは、線形サービスを示す。

線形サービスは、属性がビデオコンポーネントの役割である提示可能ビデオコンポーネントクラスとの関係を含む関係を有する。ビデオコンポーネントの役割は、プライマリ（デフォルト）ビデオ、代案カメラビュー（ａｌｔｅｒｎａｔｉｖｅｃａｍｅｒａｖｉｅｗ）、他の代案ビデオコンポーネント、手話（ｓｉｇｎｌａｎｇｕａｇｅ）（すなわち、ＡＳＬ）インセット（ｉｎｓｅｔ）、又はフォローサブジェクト特徴（ｆｏｌｌｏｗ−ｓｕｂｊｅｃｔｆｅａｔｕｒｅ）が個別ビデオコンポーネントによって支援される場合に、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示す可能な値を有することができる。

線形サービスの関係は、提示可能オーディオコンポーネントクラスとの関係、提示可能ＣＣコンポーネントクラスとの関係、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係、及び／又はサービスクラスとの“サブクラス”関係を含む。

アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。

アプリケーションベースのサービスは、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係及び／又はサービスクラスとの“サブクラス”関係を含む関係を有する。

図８１は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。

プログラムは、プログラムを示す。

プログラムの属性は、ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ、ＳｔａｒｔＴｉｍｅ、ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ、ＴｅｘｔｕａｌＴｉｔｌｅ、ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ、Ｇｅｎｒｅ、ＧｒａｐｈｉｃａｌＩｃｏｎ、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ、ターゲッティング／個人化特性、コンテンツ／サービス保護特性、及び／又は“ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）モデル”と定義された他の特性を含む。

ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ［１］は、プログラムの固有識別子に対応する。

ＳｔａｒｔＴｉｍｅ［１］は、プログラムが始まるようにスケジュールされた実測日時及び時間（ｗａｌｌｃｌｏｃｋｄａｔｅａｎｄｔｉｍｅ）に対応する。

ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ［１］は、プログラムの開始からプログラムの終了までのスケジュールされた実測時間（ｗａｌｌｃｌｏｃｋｔｉｍｅ）に対応する。

ＴｅｘｔｕａｌＴｉｔｌｅ［１．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能タイトル−存在しないなら、関連したショーのＴｅｘｔｕａｌＴｉｔｌｅに対するデフォルト−に対応する。

ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ［０．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能説明−存在しないなら、関連したショーのＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎに対するデフォルト−に対応する。

Ｇｅｎｒｅ［０．．ｎ］は、プログラムのジャンル-存在しないなら、関連したショーのジャンルに対するデフォルト−に対応する。

ＧｒａｐｈｉｃａｌＩｃｏｎ［０．．ｎ］は、複数のサイズからなる（例えば、ＥＳＧにおいて）プログラムを示すアイコン−存在しないなら、関連したショーのＧｒａｐｈｉｃａｌＩｃｏｎに対するデフォルト−に対応する。

ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ［０．．ｎ］は、複数の領域に対してプログラムに対するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティング−存在しないなら、関連したショーのＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇに対するデフォルト−に対応する。

ターゲッティング／個人化特性は、プログラムのターゲッティングなどを決定するために用いられる特性−存在しないなら、関連したショーのターゲッティング／個人化特性に対するデフォルト−に対応する。

コンテンツ／サービス保護特性は、プログラムのコンテンツ保護及び／又はサービス保護に用いられる特性−存在しないなら、関連したショーのコンテンツ／サービス保護に対するデフォルト−に対応する。

プログラムは、次のものを含む関係を有することができる。
線形サービスクラスとの“ＰｒｏｇｒａｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＣｏｎｔｅｎｔＩｔｅｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＯｎＤｅｍａｎｄＣｏｍｐｏｎｅｎｔＯｆ”関係、提示可能ビデオコンポーネントクラスとの“包含”関係、提示可能オーディオコンポーネントクラスとの“包含”関係、提示可能ＣＣコンポーネントクラスとの“包含”関係、アプリケーションベースエンハンスメントクラスとの“包含”関係、タイムベースクラスとの“包含”関係、ショークラスとの“Ｂａｓｅｄ−ｏｎ”関係、及び／又はセグメントクラスとの“包含”関係。

提示可能ビデオコンポーネントクラスとの“包含”関係は、可能な値がプライマリ（デフォルト）ビデオ、代案カメラビュー、他の代案ビデオコンポーネント、手話（例えば、ＡＳＬ）インセット及び／又はフォローサブジェクト特徴が個別ビデオコンポーネントによって支援される場合、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示すビデオコンポーネントの役割を含む属性を有することができる。

セグメントクラスとの“包含”関係の属性は、プログラムの開始に対してセグメントの開始時間を特定するＲｅｌａｔｉｖｅＳｅｇｍｅｎｔＳｔａｒｔＴｉｍｅを有することができる。

ＮＲＴコンテンツアイテムコンポーネントは、プログラムと同じ構造を有することができるが、ストリーミング形態よりはファイルの形態で伝達されればよい。このようなプログラムはそれと関連したインタラクティブサービスなどの付加（ａｄｊｕｎｃｔ）データサービスを有することができる。

図８２は、本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄコンテンツに対する定義を示す。

将来のハイブリッド放送システムは、サービスのタイプに対する線形サービス及び／又はアプリケーションベースのサービスを有することができる。線形サービスがスケジュールによって提示される連続したコンポーネント及び放送で定義されるタイムベースで構成されると、線形サービスは、トリガーされたアプリケーションエンハンスメントを有することができる。

指示されたように、現在定義された提示可能コンテンツコンポーネントと共に、次のタイプのサービスが定義される。他のサービスタイプ及びコンポーネントが定義されてもよい。

線形サービスは（様々なタイプのタイムシフト視聴メカニズムが消費者によって使われて消費時間をシフトできることを除けば）、プライマリコンテンツがスケジュールによって消費される連続コンポーネント及び放送によって定義されたタイムベースで構成されるサービスである。

ゼロ以上のビデオコンポーネント
ゼロ以上のオーディオコンポーネント
ゼロ以上のクローズドキャプションコンポーネント
コンポーネントを同期化するために用いられるタイムベース
ゼロ以上のトリガーされたアプリケーションベースエンハンスメント及び／又はゼロ以上の自動開始(launching)アプリケーションベースエンハンスメント。

ゼロ以上のトリガーされたアプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、開始されてサービスの一部として伝達された活性化通知によって同期化された方式でアクションを行うようにするアプリケーションで構成される。エンハンスメントコンポーネントは、次のものを含むことができる。
活性化通知のストリーム
通知のターゲットである一つ以上のアプリケーション
ゼロ以上のコンテンツアイテム、及び／又は
ゼロ以上のオンデマンドコンポーネント

選択的に、アプリの一つは、“プライマリアプリ”として指定されてもよい。指定されたプライマリアプリが存在すると、根源的なサービスが選択されるやいなや活性化されてもよい。他のアプリは、通知ストリーム内の通知によって活性化されたり、アプリが既に活性化された他のアプリによって活性化されてもよい。

ゼロ以上の自動開始アプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、サービスが選択される度に自動で開始されるアプリで構成される。エンハンスメントコンポーネントは次のものを含むことができる。
自動開始されたアプリケーション
ゼロ以上の活性化通知のストリーム、及び／又は
ゼロ以上のコンテンツアイテム。

ここで、線形サービスは、自動開始されたアプリケーションベースエンハンスメント及びトリガーされたアプリケーションベースエンハンスメント、例えば、自動開始されたアプリケーションベースエンハンスメントを有し、対象となるアド（広告）挿入及びトリガーされたアプリケーションベースエンハンスメントを行って、インタラクティブ視聴経験を提供することができる。

アプリケーションベースのサービスは、サービスが選択される度に指定されたアプリケーションが開始されるサービスである。これは、アプリケーションベースのサービス内のアプリケーションベースエンハンスメントが指定されたプライマリアプリを含むという制限を有する一つのアプリケーションベースエンハンスメントで構成されてもよい。

アプリは、コンテンツアイテムの特殊な場合であってもよく、すなわち、アプリサービスコンポーネントを共に構成するファイルの集合が複数のサービス間で共有されてもよい。

アプリケーションベースのサービス内のアプリケーションは、オンデマンドコンテンツの提示を開始することができる。

パッケージングされたアプリケーションを有する自動開始アプリケーションベースのサービスの概念の併合に関するいくつかのアプローチが存在する。これは、任意の形態でサービスガイドに現れてもよい。将来ＴＶセットは、次の特徴を有することができる。

ユーザは、サービスガイド内の自動開始アプリケーションベースのサービスを選択して“選好”サービスとして指定したり、そのサービス又はそのようなものを“取得”することができる。これは、サービスの基礎を形成するアプリがダウンロードされ、ＴＶセットに設置されるようにすることができる。すると、ユーザは、“選好”又は“取得された”アプリを見ることを要求することができ、ダウンロードされて設置されたアプリを全て示しながら、スマートフォン上にあるものと類似のディスプレイを得ることができる。すると、ユーザは、その中から実行されるものを選択できる。この効果は、サービスガイドがアプリストアと類似に動作することである。

及び／又は、任意のアプリが“選好”／“取得された”サービスとして自動開始アプリケーションベースのサービスを識別するようにするＡＰＩが存在してもよい。（このようなＡＰＩの具現は、ユーザへの“確実ですか”というクエリーを含み、不良アプリ（ｒｏｇｕｅａｐｐ）がユーザの知らないうちに（ｂｅｈｉｎｄｕｓｅｒ’ｓｂａｃｋ）それを行うことを防ぐことができる。これは、“パッケージされたアプリ”を設置することに当たる効果を有することができる。

それぞれのサービスは、（コンテンツに対応する）コンテンツアイテムを含むことができる。コンテンツアイテムは、統合された全体として消費されるように意図される一つ以上のファイルの集合である。オンデマンドコンテンツは、視聴者によって選択された時間に（一般に、アプリケーションによって提供されるユーザインターフェースを介して）提示されるコンテンツであり、このようなコンテンツは、連続したコンテンツ（例えば、オーディオ／ビデオ）又は非周期的コンテンツ（例えば、ＨＴＭＬページ又はイメージ）で構成されてもよい。

図８３は、本発明の実施例として、ＣｏｍｐｌｅｘＡｕｄｉｏＣｏｍｐｏｎｅｎｔの例を示す。

提示可能オーディオコンポーネントは、完璧なメインコンポーネントを含むＰｉｃｋＯｎｅコンポーネント及び音楽、ダイアログ及び混合されるエフェクトトラックを含むコンポーネントであってもよい。完璧なメインオーディオコンポーネント及び音楽コンポーネントは、別個のビットレートでエンコーディングによって構成されるエレメンタリコンポーネントを含むＰｉｃｋＯｎｅコンポーネントであるが、ダイアログ及びエフェクトコンポーネントはエレメンタリコンポーネントであってもよい。

このアプローチは、サービスが直接サービスの提示可能コンポーネントだけを列挙した後、任意のコンプレックスコンポーネントのメンバーコンポーネントを階層的に列挙しようとするものより一層明瞭なピクチャを提供する。

コンポーネントモデルの可能な無限反復（ｒｅｃｕｒｓｉｏｎ）を制限するために、次の制限が与えられてもよい。任意の連続したコンポーネントは、上位レベルがＰｉｃｋＯｎｅで構成され、中間レベルがコンポジットコンポーネントで構成され、下位レベルがＰｉｃｋＯｎｅコンポーネントで構成される３レベル階層に適合し得る。任意の特定連続コンポーネントは連続したコンポーネントが単純にエレメンタリコンポーネントであるヌルサブセットを含み、３個のレベル又はその任意のサブセットを含むことができる。

図８４は、本発明の一実施例に係る、アプリケーションと関連した属性情報を示す図である。

アプリケーションと関連した属性情報は、ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙ情報を含むことができる。

本発明の一実施例によって追加され得るアプリケーションと関連した属性情報は、ＡｐｐｌｉｃａｔｉｏｎＩＤ情報、Ａｐｐｌｉｃａｔｉｏｎｖｅｒｓｉｏｎ情報、Ａｐｐｌｉｃａｔｉｏｎｔｙｐｅ情報、Ａｐｐｌｉｃａｔｉｏｎｌｏｃａｔｉｏｎ情報、Ｃａｐａｂｉｌｉｔｉｅｓ情報、Ｒｅｑｕｉｒｅｄｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｌｅｖｅｌ情報、Ｆｒｅｑｕｅｎｃｙｏｆｕｓｅ情報、Ｅｘｐｉｒａｔｉｏｎｄａｔｅ情報、Ｄａｔａｉｔｅｍｎｅｅｄｅｄｂｙａｐｐｌｉｃａｔｉｏｎ情報、Ｓｅｃｕｒｉｔｙｐｒｏｐｅｒｔｉｅｓ情報、Ｔａｒｇｅｔｄｅｖｉｃｅｓ情報、及び／又はＣｏｎｔｅｎｔａｄｖｉｓｏｒｙ情報を含むことができる。

ＡｐｐｌｉｃａｔｉｏｎＩＤ情報は、アプリケーションを識別できる固有のＩＤを示す。

Ａｐｐｌｉｃａｔｉｏｎｖｅｒｓｉｏｎ情報は、アプリケーションのバージョンを示す。

Ａｐｐｌｉｃａｔｉｏｎｔｙｐｅ情報は、アプリケーションのタイプを示す。

Ａｐｐｌｉｃａｔｉｏｎｌｏｃａｔｉｏｎ情報は、アプリケーションの位置を示す。例えば、Ａｐｐｌｉｃａｔｉｏｎｌｏｃａｔｉｏｎ情報は、アプリケーションを受信できるＵＲＬを含むことができる。

Ｃａｐａｂｉｌｉｔｉｅｓ情報は、アプリケーションをレンダラ（ｒｅｎｄｅｒ）できるようにするキャパビリティ（ｃａｐａｂｉｌｉｔｙ）属性を示す。

Ｒｅｑｕｉｒｅｄｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｌｅｖｅｌ情報は、放送ストリーミングとアプリケーション間の同期化（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）レベル情報を示す。例えば、Ｒｅｑｕｉｒｅｄｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｌｅｖｅｌ情報は、プログラム或いはイベント単位、時間単位（例えば、２秒以内）、ｌｉｐｓｙｎｃ、及び／又はフレームレベル同期などの内容を示すことができる。

Ｆｒｅｑｕｅｎｃｙｏｆｕｓｅ情報は、アプリケーションの使用頻度を示す。

Ｅｘｐｉｒａｔｉｏｎｄａｔｅ情報は、アプリケーションの使用満了日／満了時刻を示す。

Ｄａｔａｉｔｅｍｎｅｅｄｅｄｂｙａｐｐｌｉｃａｉｏｎ情報は、アプリケーションで用いるデータ情報を示す。

Ｓｅｃｕｒｉｔｙｐｒｏｐｅｒｔｉｅｓ情報は、アプリケーションの保安関連情報を示す。

Ｔａｒｇｅｔｄｅｖｉｃｅｓ情報は、アプリケーションが用いられるターゲット装置情報を示す。例えば、ターゲット装置情報は、当該アプリケーションの実行されるターゲット機器がＴＶ及び／又はモバイル機器であることを示すことができる。

Ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙ情報は、アプリケーションの使用可能な等級を示す。例えば、Ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙ情報は、アプリケーションを利用できる年齢制限情報を含むことができる。

上述したアプリケーションベースのエンハンスメント（Ａｐｐ−ｂａｓｅｄｅｎｈａｎｃｅｍｅｎｔ）或いはアプリケーションベースのサービス（Ａｐｐ−ｂａｓｅｓｅｒｖｉｃｅ）で使用或いは実行できるアプリケーションは、サービスプロバイダ（放送局）が提供した放送関連アプリケーションに制限され得る。以下では、アプリケーションの属性及び動作性の制約事項について説明する。

図８５は、本発明の一実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。

本発明の一実施例に係るサービスプロバイダのアプリケーションは、アプリケーションタイプ（ｔｙｐｅ）などのような属性（ａｔｔｒｉｂｕｔｅ）の変更によってサードパーティーアプリケーション（３ｒｄＰａｒｔｙａｐｐ）と同一の属性を有する放送と関連のないアプリケーションに移行（ｔｒａｎｓｉｔｉｏｎ）することができない。

したがって、この場合、受信機は、アプリケーションの属性が変更されたか否かを確認し、変更された属性によってアプリケーションを実行するか否かを判断することができる。以下、図８５のフローチャートを説明する。

サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８５０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８５１００に伝送することができる。

受信機Ｅ８５１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎｍａｎａｇｅｒ）が行うこともできる。

その後、サービスプロバイダＥ８５０００は、アプリケーションの属性に対する変更事項をアップデートすることができる。受信機Ｅ８５１００又はアプリケーションマネジャーは、アプリケーションの属性の変更事項を確認することができる。

もし、アプリケーション属性のうちアプリケーションタイプ属性がハイブリッド放送サービスと関連のないサードパーティーアプリケーションタイプに変更された場合、受信機Ｅ８５１００又はアプリケーションマネジャーは、実行中の放送関連アプリケーションを終了することができる。

もし、アプリケーションタイプ以外の他の属性が変更された場合、受信機Ｅ８５１００又はアプリケーションマネジャーは、実行中の放送関連アプリケーションに変更された属性を適用し、続けて実行することができる。

図８６は、本発明の他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。

図８６は、実行中のサービスプロバイダの放送関連アプリケーションでチャネル情報がない（Ｎｕｌｌチャネル）チャネルに変更を試みる場合、誤りをリターンする受信機の動作を示す。以下、図８６のフローチャートを説明する。

サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８６０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８６１００に伝送することができる。

受信機Ｅ８６１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎｍａｎａｇｅｒ）が行うこともできる。

その後、現在実行中のアプリケーションで、ｓｅｔＣｈａｎｎｅｌ（‘ｎｕｌｌ’）のようなＡＰＩを用いてサードパーティーアプリケーションのような放送と関連するアプリケーションに転換を試みる場合、受信機Ｅ８８１００又はアプリケーションマネジャーは、ｓｅｔＣｈａｎｎｅｌ（‘ｎｕｌｌ’）要求に対して誤りをリターンし、以降の動作に対してアプリケーションが処理するようにしたり、実行中の放送関連アプリケーションを終了させることができる。

図８７は、本発明の更に他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。

図８７は、サービスプロバイダの放送関連アプリケーションの実行中、アプリケーション内でサードパーティーアプリケーションのような放送と関連のないアプリケーションを実行する場合、受信機の動作を示す。この場合、受信機は、サービスプロバイダのアプリケーションのみを実行させたり、または政策によって放送と関連のないサードパーティーアプリケーションを実行させるようにすることができる。以下、図８７のフローチャートを説明する。

サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８７０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８７１００に伝送することができる。

受信機Ｅ８７１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎｍａｎａｇｅｒ）が行うこともできる。

その後、実行中の放送関連アプリケーションで、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ（）などのようなＡＰＩを用いて受信機で実行可能なアプリケーションリストを要求することができる。

もし、ユーザ設定又は受信機政策によって、放送と関連のないサードパーティーアプリケーション（３ｒｄｐａｒｔｙａｐｐ）が許容される場合、受信機Ｅ８７１００又はアプリケーションマネジャーは、サードパーティーアプリケーションを含む全てのアプリケーションのリスト（ｌｉｓｔ）をリターンすることができる。この場合、実行中の放送関連アプリケーションは、放送と関連のないサードパーティーアプリケーションを実行させることができる。

もし、ユーザ設定又は受信機政策によって、放送と関連のないサードパーティーアプリケーションが許容されない場合、受信機Ｅ８７１００又はアプリケーションマネジャーは、サードパーティーアプリケーションを除いたアプリケーションのリストをリターンすることができる。この場合、実行中の放送関連アプリケーションは、放送と関連のないサードパーティーアプリケーションのようなアプリケーションを実行させることができない。

図８８は、本発明の一実施例に係るハイブリッド放送サービス処理のフローチャートである。

図８８は、上述したマルチキャスト環境でのＡＣＲ受信装置がハイブリッド放送サービス）を処理する過程を示したフローチャートである。

図示していないが、本発明の一実施例に係る受信機は、ハイブリッド放送サービスのための放送信号及びシグナリング情報を受信するための受信機（ｒｅｃｅｉｖｅｒ）、及びシグナリング情報と関連する要求（ｒｅｑｕｅｓｔ）を伝送するための送信機（ｔｒａｎｓｍｉｔｔｅｒ）を含むことができる。

本発明の一実施例に係る受信機は、ハイブリッド放送サービスのための放送信号を受信することができる（ＥＳ８８０００）。上述したように、本発明の一実施例に係る放送信号受信機は、図１乃至図２９で説明した放送信号を受信、処理することができる。放送信号は、シグナリング情報に関するアドレス情報（ａｄｄｒｅｓｓｉｎｆｏｒｍａｔｉｏｎ）を含む。シグナリング情報に関するアドレス情報は、ウォーターマーキングスキーム又はフィンガープリントスキームによって放送信号に挿入されてもよい。そして、シグナリング情報に関するアドレス情報は、ＡＣＲサーバーのアドレス（ＡＣＲｓｅｒｖｅｒａｄｄｒｅｓｓ）を指示することができる。詳細な内容は、図３０乃至図７０で説明した。

本発明の一実施例に係る送信機は、シグナリング情報のためのリクエスト（ｒｅｑｕｅｓｔ）を伝送することができる（ＥＳ８８１００）。詳細な内容は、図３０乃至図７０で説明した。

本発明の一実施例に係る受信機は、ユニキャスト方式、マルチキャスト方式及びｅＭＢＭＳ（ｅｖｏｌｖｅｄＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ）方式のいずれか１つによるモバイルブロードバンド又はブロードバンドチャネルを介してシグナリング情報を受信することができる（ＥＳ８８２００）。詳細な内容は、図３０乃至図７０で説明した。

図８９は、本発明の他の実施例に係るハイブリッド放送サービス処理のフローチャートである。

図８９は、図８８で説明したハイブリッド放送サービスの処理において、アプリケーションを受信して処理する場合のアプリケーション属性の変更による受信機の動作を示す。

本発明の一実施例に係るシグナリングパーサー又は受信装置は、ハイブリッド放送サービスのアプリケーションのシグナリング情報を受信することができる（ＥＳ８９０００）。シグナリング情報は、アプリケーション識別情報、アプリケーションバージョン情報及びアプリケーションアドレス情報を含むことができる。詳細な内容は、図７１乃至図８７で説明した。

本発明の一実施例に係るアプリケーションマネジャー又は受信装置は、シグナリング情報を用いてアプリケーションを開始することができる（ＥＳ８９１００）。詳細な内容は、図７１乃至図８７で説明した。

本発明の一実施例に係るシグナリングパーサー又は受信装置は、アプリケーションのアップデート情報を受信することができる（ＥＳ８９２００）。アップデート情報は、アプリケーションのタイプが変更されたか否かを示すアプリケーション属性情報を含むことができる。

アプリケーション属性情報が、アプリケーションのタイプがハイブリッド放送サービスと関係のないアプリケーションタイプに変更されたことを示す場合、アプリケーションマネジャーは、開始されたアプリケーションを中断させることができる。

または、ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を使用することによってアプリケーション属性情報がハイブリッド放送サービスと関係のないアプリケーションタイプに変更される場合、アプリケーションマネジャーは、誤り応答を伝送したり、開始されたアプリケーションを中断させることができる。さらに、アプリケーションマネジャーは、使用可能なアプリケーションを示すリストに対するリクエストを受信することができ、リクエストによるリストを伝送することができる。詳細な内容は、図７１乃至図８７で説明した。

本発明の思想や範囲から逸脱することなく本発明で様々な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付の特許請求の範囲及びその同等範囲内で提供される本発明の変更及び変形を含むものと意図される。

本明細書で装置及び方法発明がいずれも言及されており、装置及び方法発明の両方の説明は互いに補完して適用されてもよい。

実施の形態

様々な実施例が、本発明を実施するための形態において説明された。

本発明は、一連の放送信号提供分野で利用される。

本発明の思想や範囲から逸脱することなく本発明で様々な変更及び変形が可能であるということは当業者にとって自明である。したがって、本発明は、添付の特許請求の範囲及びその同等範囲内で提供される本発明の変更及び変形を含むものと意図される。

Claims

放送サービスのための放送コンテンツを外部入力ソースから受信するステップであって、前記放送コンテンツは複数のウォーターマークを含む、ステップと、
前記放送コンテンツから前記複数のウォーターマークを抽出するステップと、を含み、
前記複数のウォーターマークは、それら自身の識別子により識別される第１のウォーターマークブロック及び第２のウォーターマークブロックを含み、
前記第１のウォーターマークブロックはコンテンツ識別子とチャネル識別子の少なくとも一つを含み、
前記コンテンツ識別子は前記外部入力ソースから前記放送コンテンツを識別し、
前記チャネル識別子は前記放送コンテンツと関連した放送チャネルを識別し、
前記第２のウォーターマークブロックは前記放送サービスのためのシグナリングサーバーに対するＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）情報を含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの一つは少なくとも一つのフラグメントを含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの前記一つはフラグメント番号フィールドとラストフラグメントフィールドを含み、
前記フラグメント番号フィールドはフラグメントのフラグメント番号を特定するために利用され、
前記ラストフラグメントフィールドはラストフラグメントのフラグメント番号を特定するために利用され、
前記ＵＲＬ情報に直接基づいて前記シグナリングサーバーにアクセスするステップを含む、放送サービスを処理する方法。
外部入力ソースから放送サービスのための放送コンテンツを受信するように構成されたチューナであって、前記放送コンテンツは複数のウォーターマークを含む、チューナと、
前記放送コンテンツから前記複数のウォーターマークを抽出するように構成されたウォーターマークモジュールを含み、
前記複数のウォーターマークは、それら自身の識別子により識別される第１のウォーターマークブロック及び第２のウォーターマークブロックを含み、
前記第１のウォーターマークブロックはコンテンツ識別子とチャネル識別子の少なくとも一つを含み、
前記コンテンツ識別子は前記外部入力ソースからの前記放送コンテンツを識別し、
前記チャネル識別子は前記放送コンテンツと関連した放送チャネルを識別し、
前記第２のウォーターマークブロックは前記放送サービスのためのシグナリングサーバーに対するＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）情報を含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの一つは少なくとも一つのフラグメントを含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの前記一つはフラグメント番号フィールドとラストフラグメントフィールドを含み、
前記フラグメント番号フィールドはフラグメントのフラグメント番号を特定するために利用され、
前記ラストフラグメントフィールドはラストフラグメントのフラグメント番号を特定するために利用され、
前記シグナリングサーバーは前記ＵＲＬ情報に直接基づいてアクセスされる、放送サービスを処理する装置。