(57)【特許請求の範囲】
【請求項１】
放送サービスのための放送コンテンツを外部入力ソースから受信するステップであって、前記放送コンテンツは複数のウォーターマークを含む、ステップと、
前記放送コンテンツから前記複数のウォーターマークを抽出するステップと、を含み、
前記複数のウォーターマークは、それら自身の識別子により識別される第１のウォーターマークブロック及び第２のウォーターマークブロックを含み、 
前記第１のウォーターマークブロックはコンテンツ識別子とチャネル識別子の少なくとも一つを含み、
前記コンテンツ識別子は前記外部入力ソースから前記放送コンテンツを識別し、
前記チャネル識別子は前記放送コンテンツと関連した放送チャネルを識別し、
前記第２のウォーターマークブロックは前記放送サービスのためのシグナリングサーバーに対するＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）情報を含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの一つは少なくとも一つのフラグメントを含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの前記一つはフラグメント番号フィールドとラストフラグメントフィールドを含み、
前記フラグメント番号フィールドはフラグメントのフラグメント番号を特定するために利用され、
前記ラストフラグメントフィールドはラストフラグメントのフラグメント番号を特定するために利用され、
前記ＵＲＬ情報に直接基づいて前記シグナリングサーバーにアクセスするステップを含む、放送サービスを処理する方法。
【請求項２】
外部入力ソースから放送サービスのための放送コンテンツを受信するように構成されたチューナであって、前記放送コンテンツは複数のウォーターマークを含む、チューナと、
前記放送コンテンツから前記複数のウォーターマークを抽出するように構成されたウォーターマークモジュールを含み、 
前記複数のウォーターマークは、それら自身の識別子により識別される第１のウォーターマークブロック及び第２のウォーターマークブロックを含み、 
前記第１のウォーターマークブロックはコンテンツ識別子とチャネル識別子の少なくとも一つを含み、
前記コンテンツ識別子は前記外部入力ソースからの前記放送コンテンツを識別し、
前記チャネル識別子は前記放送コンテンツと関連した放送チャネルを識別し、
前記第２のウォーターマークブロックは前記放送サービスのためのシグナリングサーバーに対するＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）情報を含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの一つは少なくとも一つのフラグメントを含み、
前記第１のウォーターマークブロック又は前記第２のウォーターマークブロックの前記一つはフラグメント番号フィールドとラストフラグメントフィールドを含み、
前記フラグメント番号フィールドはフラグメントのフラグメント番号を特定するために利用され、
前記ラストフラグメントフィールドはラストフラグメントのフラグメント番号を特定するために利用され、
前記シグナリングサーバーは前記ＵＲＬ情報に直接基づいてアクセスされる、放送サービスを処理する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハイブリッド放送サービスを処理する装置、及びハイブリッド放送サービスを処理する方法に関する。
【背景技術】
【０００２】
アナログ放送信号の送信が終了するに伴い、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてさらに多くの量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加え、様々なタイプの追加データをさらに含むことができる。
【０００３】
すなわち、デジタル放送システムは、高画質（ＨＤ；ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ）映像、マルチチャネルオーディオ、及び様々な追加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ送信のためのデータ送信効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）及びモバイル受信装備を考慮したネットワーク柔軟性が改善される必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、放送信号を送信して時間領域で２つ以上の異なる放送サービスを提供する放送送受信システムのデータをマルチプレクスし、同じＲＦ信号帯域幅を介してマルチプレクスされたデータを送信する装置及び方法、及びそれに対応する放送信号を受信する装置及び方法を提供することである。
【０００５】
本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して、コンポーネントによってサービスに対応するデータを分類し、各コンポーネントに対応するデータをデータパイプとして送信し、データを受信及び処理する方法を提供することである。
【０００６】
本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して、放送信号を提供するのに必要なシグナリング情報をシグナリングする方法を提供することである。
【課題を解決するための手段】
【０００７】
上記目的及び他の利点を達成するために、本発明は、ハイブリッド放送サービスを処理する方法を提供する。ハイブリッド放送サービスを処理する方法は、ハイブリッド放送サービスのための放送信号を受信するステップであって、前記放送信号は、シグナリング情報に関するアドレス情報を含む、ステップと、前記放送信号のシグナリング情報のためのリクエストを伝送するステップと、ユニキャスト方式、マルチキャスト方式及びｅＭＢＭＳ（ｅｖｏｌｖｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）方式のいずれか１つを用いてモバイルブロードバンド又はブロードバンドチャネルを介してシグナリング情報を受信するステップとを含む。
【０００８】
本発明の他の態様に係るハイブリッド放送サービスを処理する方法は、ハイブリッド放送サービスのアプリケーションのシグナリング情報を受信するステップであって、前記シグナリング情報は、アプリケーション識別情報、アプリケーションバージョン情報及びアプリケーションアドレス情報を含む、ステップと、前記シグナリング情報を用いて前記アプリケーションを開始するステップと、前記アプリケーションのアップデート情報を受信するステップとを含む。
【発明の効果】
【０００９】
本発明は、各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅｓ）を制御するサービス特性に応じてデータを処理することによって、様々な放送サービスを提供することができる。
【００１０】
本発明は、同じＲＦ信号帯域幅を介して様々な放送サービスを送信することによって送信柔軟性を達成することができる。
【００１１】
本発明は、データ送信効率を改善し、ＭＩＭＯシステムを用いて放送信号の送受信のロバスト性を増加させることができる。
【００１２】
本発明によれば、モバイル受信装備又は室内環境においても誤りなしにデジタル放送信号を受信可能な放送信号送信及び受信方法及び装置を提供することができる。
【図面の簡単な説明】
【００１３】
本発明の追加の理解を提供するために含まれ、本出願の一部に含まれたり、その一部を構成する添付の図面は、本発明の実施例を示し、説明と共に本発明の原理を説明する。
【図１】本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。
【図２】本発明の一実施例に係る入力フォーマッティングブロックを示す図である。
【図３】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図４】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図５】本発明の実施例に係るＢＩＣＭブロックを示す図である。
【図６】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図７】本発明の一実施例に係るフレームビルディングブロックを示す図である。
【図８】本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。
【図９】本発明の実施例によって未来の放送サービスのための放送信号を受信する装置の構造を示す図である。
【図１０】本発明の実施例に係るフレーム構造を示す図である。
【図１１】本発明の実施例に係るフレームのシグナリング階層構造を示す図である。
【図１２】本発明の実施例に係るプリアンブルシグナリングデータを示す図である。
【図１３】本発明の実施例に係るＰＬＳ１データを示す図である。
【図１４】本発明の実施例に係るＰＬＳ２データを示す図である。
【図１５】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図１６】本発明の実施例に係るフレームの論理構造を示す図である。
【図１７】本発明の実施例に係るＰＬＳマッピングを示す図である。
【図１８】本発明の実施例に係るＥＡＣマッピングを示す図である。
【図１９】本発明の実施例に係るＦＩＣマッピングを示す図である。
【図２０】本発明の実施例に係るＤＰのタイプを示す図である。
【図２１】本発明の実施例に係るＤＰマッピングを示す図である。
【図２２】本発明の実施例に係るＦＥＣ構造を示す図である。
【図２３】本発明の実施例に係るビットインターリービングを示す図である。
【図２４】本発明の実施例に係るセルワードデマルチプレクシングを示す図である。
【図２５】本発明の実施例に係る時間インターリービングを示す図である。
【図２６】本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。
【図２７】本発明の他の実施例に係るツイスト行−列ブロックインターリーバの動作を示す図である。
【図２８】本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向の読み取りパターンを示す図である。
【図２９】本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。
【図３０】実施例に係るネットワークトポロジ（ｎｅｔｗｏｒｋ  ｔｏｐｏｌｏｇｙ）を示すブロック図である。
【図３１】実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。
【図３２】実施例に係るウォーターマークベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラム（ｌａｄｄｅｒ  ｄｉａｇｒａｍ）である。
【図３３】実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す図である。
【図３４】実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。
【図３５】実施例に係るフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。
【図３６】実施例に係る質疑結果を含むＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキーマダイヤグラムを示す図である。
【図３７】実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。
【図３８】実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。
【図３９】実施例に係る映像表示装置を示すブロック図である。
【図４０】実施例によってメインＡＶコンテンツの再生時間を付加サービスの再生時間と同期化する方法を示すフローチャートである。
【図４１】実施例によってメインＡＶコンテンツの再生時間を付加サービスの再生時間と同期化する方法を示す概念図である。
【図４２】他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。
【図４３】他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。
【図４４】本発明の一実施例によってウォーターマーキング方式で伝達できるデータを示すダイヤグラムである。
【図４５】本発明の一実施例によってタイムスタンプタイプフィールドの値の意味を示すダイヤグラムである。
【図４６】本発明の一実施例によってＵＲＬプロトコルタイプフィールドの値の意味を示すダイヤグラムである。
【図４７】本発明の一実施例によってＵＲＬプロトコルタイプフィールドを処理するプロセスを示すフローチャートである。
【図４８】本発明の一実施例によってイベントフィールドの値の意味を示すダイヤグラムである。
【図４９】本発明の一実施例によって目的地タイプフィールドの値の意味を示す図である。
【図５０】本発明の実施例＃１によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５１】本発明の実施例＃１によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【図５２】本発明の実施例＃２によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５３】本発明の実施例＃２によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【図５４】本発明の実施例＃３によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５５】本発明の実施例＃４によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５６】本発明の実施例＃４によって第１ＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５７】本発明の実施例＃４によって第２ＷＭに挿入されるデータの構造を示すダイヤグラムである。
【図５８】本発明の実施例＃４によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【図５９】本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。
【図６０】フィンガープリンティング方式における本発明の一実施例に係るデータ構造を示す図である。
【図６１】フィンガープリンティング方式における本発明の一実施例に係るデータ構造を処理するプロセスを示すフローチャートである。
【図６２】本発明の一実施例に係る放送受信機を示す図である。
【図６３】本発明の一実施例に係るマルチキャスト環境でのＡＣＲ送受信システムを示す図である。
【図６４】本発明の一実施例に係るマルチキャスト環境でのＷＭを介したＡＣＲ送受信システムを示す図である。
【図６５】本発明の一実施例に係るマルチキャスト環境でのＦＰ方式を介したＡＣＲ送受信システムを示す図である。
【図６６】本発明の一実施例に係る受信機がマルチキャスト環境でＡＣＲスキーム（ＡＣＲ  ｓｃｈｅｍｅ）を介して放送と関連するシグナリングを行うフローチャートを示す図である。
【図６７】本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す図である。
【図６８】本発明の他の実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す図である。
【図６９】本発明の一実施例に係るハイブリッド放送サービスを示す概念図である。
【図７０】本発明の他の実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す図である。
【図７１】本発明の実施例に係る次世代放送システム用プロトコルスタックを示す図である。
【図７２】本発明の実施例に係る伝送フレームを示す図である。
【図７３】本発明の他の実施例に係る伝送フレームを示す図である。
【図７４】本発明の実施例に係る伝送パケット（ＴＰ）及び放送システムのｎｅｔｗｏｒｋ_ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。
【図７５】本発明の実施例に係る放送サーバーと受信機を示す図である。
【図７６】本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ、及びサービスタイプ間の付加（ａｄｊｕｎｃｔ）サービス関係に加え、別個のサービスタイプを示す図である。
【図７７】本発明の実施例として、ＮＲＴコンテンツアイテムクラスとＮＲＴファイルクラスとの包含関係を示す図である。
【図７８】本発明の実施例に係るサービスタイプ及びコンポーネントタイプに基づいた属性を示すテーブルである。
【図７９】本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。
【図８０】本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。
【図８１】本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。
【図８２】本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄ  Ｃｏｎｔｅｎｔに対する定義を示す図である。
【図８３】本発明の実施例として、Ｃｏｍｐｌｅｘ  Ａｕｄｉｏ  Ｃｏｍｐｏｎｅｎｔの例を示す図である。
【図８４】本発明の実施例に係るアプリケーションに関連した属性情報を示す図である。
【図８５】本発明の一実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。
【図８６】本発明の他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。
【図８７】本発明の更に他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示すフローチャートである。
【図８８】本発明の一実施例に係るハイブリッド放送サービスプロセッシングのフローチャートである。
【図８９】本発明の他の実施例に係るハイブリッド放送サービスプロセッシングのフローチャートである。
【発明を実施するための形態】
【００１４】
以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下に説明する詳細な説明は、本発明によって具現し得る実施例だけを示すよりは、本発明の例示的な実施例を説明するためのものである。次の詳細な説明は、本発明の完璧な理解を提供するために特定の詳細を含む。しかし、本発明は、このような特定の詳細なしに実行可能であるということは当業者にとって明白である。
【００１５】
本発明で使用されるほとんどの用語は、当該分野で広く使用されているものから選択されたが、一部の用語は出願人によって任意に選択されたものであり、その意味は、必要に応じて以下の説明で詳細に説明する。したがって、本発明は、単なる名称又は意味よりは、用語の意図された意味に基づいて理解されなければならない。
【００１６】
本発明は、未来の放送サービスのための放送信号を送受信する装置及び方法を提供する。本発明の実施例に係る未来の放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、ｎｏｎ−ＭＩＭＯ（ｍｕｌｔｉｐｌｅ  ｉｎｐｕｔ  ｍｕｌｔｉｐｌｅ  ｏｕｔｐｕｔ）又はＭＩＭＯを介して未来の放送サービスのための放送信号を処理することができる。本発明の実施例に係るノンＭＩＭＯ方式は、ＭＩＳＯ（ｍｕｌｔｉｐｌｅ  ｉｎｐｕｔ  ｓｉｎｇｌｅ  ｏｕｔｐｕｔ）方式、ＳＩＳＯ（ｓｉｎｇｌｅ  ｉｎｐｕｔ  ｓｉｎｇｌｅ  ｏｕｔｐｕｔ）方式などを含むことができる。
【００１７】
ＭＩＳＯ又はＭＩＭＯが、説明の便宜上、以下で２つのアンテナを用いるが、本発明は、２つ以上のアンテナを用いるシステムにも適用可能である。
【００１８】
本発明は、特定の使用ケースのために要求される性能を取得しながら、受信機の複雑度を最小化するために、それぞれ最適化された３つの物理層（ＰＬ）プロファイル（ベース、ハンドヘルド及びアドバンスドプロファイル）を定義することができる。物理層（ＰＨＹ）プロファイルは、当該受信機が具現しなければならない全ての構成のサブセットである。
【００１９】
３つのＰＨＹプロファイルは、機能ブロックのほとんどを共有するが、特定のブロック及び／又はパラメータにおいて少し異なる。追加のＰＨＹプロファイルが未来に定義されてもよい。システムの進化のために、未来のプロファイルはまた、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を通じて単一のＲＦチャネル内の既存のプロファイルとマルチプレクスされてもよい。それぞれのＰＨＹプロファイルについての詳細は、以下で説明する。
【００２０】
１．ベースプロファイル
ベースプロファイルは、ループトップ（ｒｏｏｆ−ｔｏｐ）アンテナに通常接続される固定受信装置に対する主な使用ケースを示す。ベースプロファイルはまた、ある場所に運搬可能であるが、比較的停止された受信カテゴリーに属するポータブル装置を含む。ベースプロファイルの使用は、任意の改善された具現例によってハンドヘルド装置又は車両装置にまで拡張され得るが、これら使用ケースは、ベースプロファイル受信機動作に対しては期待されない。
【００２１】
受信のターゲットＳＮＲの範囲は、略１０〜２０ｄＢであり、これは、既存の放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢのＳＮＲの受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用するバッテリー動作ハンドヘルド装置の場合ほど重要ではない。ベースプロファイルに対する重要なシステムパラメータは、下記の表１に列挙される。
【００２２】
【表１】
0006474835.tif 000002
【００２３】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリーパワーで動作するハンドヘルド及び車両装置に使用されるように設計された。装置は、歩行者又は車両の速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現において非常に重要である。ハンドヘルドプロファイルのターゲットＳＮＲの範囲は、略０〜１０ｄＢであるが、さらに深い室内受信を対象とする場合、０ｄＢ未満に到達するように構成することができる。
【００２４】
低いＳＮＲ能力に加え、受信機の移動度によって誘発されたドップラー効果に対する弾力性は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なパラメータは、下記の表２に列挙される。
【００２５】
【表２】
0006474835.tif 000003
【００２６】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より多くの具現複雑度を犠牲し、最も高いチャネル容量を提供する。このプロファイルはＭＩＭＯ送信及び受信の利用を要求し、ＵＨＤＴＶサービスは、このプロファイルが特別に設計されたターゲット使用ケースである。増加した容量はまた、与えられた帯域幅内で増加した数のサービス、例えば、ＳＤＴＶ又はＨＤＴＶサービスを許容するように使用され得る。
【００２７】
アドバンスドプロファイルのターゲットＳＮＲの範囲は、略２０〜３０ｄＢである。ＭＩＭＯ送信は、初期には既存の楕円偏波（ｅｌｌｉｐｔｉｃａｌｌｙ−ｐｏｌａｒｉｚｅｄ）送信装置を用いることができるが、未来にはフルパワー交差偏波送信（ｆｕｌｌ−ｐｏｗｅｒ  ｃｒｏｓｓ−ｐｏｌａｒｉｚｅｄ  ｔｒａｎｓｍｉｓｓｉｏｎ）へと拡張される。アドバンスドプロファイルに対する重要なシステムパラメータは、下記の表３に列挙される。
【００２８】
【表３】
0006474835.tif 000004
【００２９】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方のためのプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するのに用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルのためのアドバンスドプロファイルと、ＭＩＭＯを有するハンドヘルドプロファイルのためのアドバンスドプロファイルとに分離することができる。また、３つのプロファイルは、設計者の意図によって変更可能である。
【００３０】
次の用語及び定義が本発明に適用されてもよい。次の用語及び定義は、設計によって変更可能である。
【００３１】
補助ストリーム：まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンスであって、未来拡張のために又はブロードキャスターやネットワークオペレーターによる要求通りに使用されてもよい。
【００３２】
ベースデータパイプ：サービスシグナリングデータを伝達するデータパイプ
【００３３】
ベースバンドフレーム（又はＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディングプロセス（ＢＣＨ及びＬＤＰＣエンコーディング）への入力を形成するＫｂｃｈビットのセット
【００３４】
セル：ＯＦＤＭ送信の一つのキャリアによって伝達される変調値
【００３５】
コーディングブロック：ＰＬＳ１データのＬＤＰＣエンコーディングブロック又はＰＬＳ２データのＬＤＰＣエンコーディングブロックのうち１つ
【００３６】
データパイプ：サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は多数のサービス又はサービスコンポーネントを伝達することができる。
【００３７】
データパイプ単位：フレーム内のＤＰにデータセルを割り当てる基本単位
【００３８】
データシンボル：プリアンブルシンボルではないフレーム内のＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジシンボルはデータシンボルに含まれる。）
【００３９】
ＤＰ_ＩＤ：この８ビットフィールドは、ＳＹＳＴＥＭ_ＩＤによって識別されたシステム内のＤＰを固有に識別する。
【００４０】
ダミーセル：ＰＬＳシグナリング、ＤＰ又は補助ストリームに使用されずに残っている容量を満たすのに用いられる擬似ランダム値を伝達するセル
【００４１】
非常警戒チャネル（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ；ＥＡＳ）：ＥＡＳ情報データを伝達するフレームの一部
【００４２】
フレーム：プリアンブルで始まり、フレームエッジシンボルで終了する物理層時間スロット
【００４３】
フレーム受信ユニット：ＦＥＴを含む同一又は異なる物理層プロファイルに属するフレームセットであって、スーパーフレーム内で８回繰り返される。
【００４４】
高速情報チャネル：サービスと対応ベースＤＰとのマッピング情報を伝達するフレーム内の論理チャネル
【００４５】
ＦＥＣＢＬＯＣＫ：ＤＰデータのＬＤＰＣエンコーディングビットのセット
【００４６】
ＦＦＴサイズ：特定のモードに使用される公称ＦＦＴサイズであって、基本期間（ｅｌｅｍｅｎｔａｒｙ  ｐｅｒｉｏｄ）（Ｔ）の周期で表現されるアクティブシンボル期間（Ｔｓ）と同一である。
【００４７】
フレームシグナリングシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）及び分散型パイロットパターンの所定の組み合わせでフレームの開始時に使用されるさらに高いパイロット密度を有するＯＦＤＭシンボルであって、ＰＬＳデータの一部を伝達する。
【００４８】
フレームエッジシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）及び分散型パイロットパターンの所定の組み合わせでフレームの終了時に使用されるさらに高いパイロット密度を有するＯＦＤＭシンボル
【００４９】
フレームグループ：スーパーフレーム内の同じＰＨＹプロファイルタイプを有する全てのフレームのセット
【００５０】
未来拡張フレーム：未来拡張のために使用できるスーパーフレーム内の物理層時間スロットであって、プリアンブルで始まる。
【００５１】
フューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ又は一般のストリームであり、出力がＲＦ信号である、提案された物理層放送システム
【００５２】
入力ストリーム：システムによってエンドユーザに伝達されるサービスのアンサンブルのためのデータのストリーム
【００５３】
正常データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除いたデータシンボル
【００５４】
ＰＨＹプロファイル：当該受信機が具現しなければならない全ての構成のサブセット
【００５５】
ＰＬＳ：ＰＳＬ１及びＰＬＳ２で構成された物理層シグナリングデータ
【００５６】
ＰＬＳ１：固定サイズ、コーディング及び変調を有するＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２をデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。
【００５７】
注（ｎｏｔｅ）：フレームグループのデュレーションのために、ＰＬＳ１データは一定に維持される。
【００５８】
ＰＬＳ２：ＦＳＳシンボルで送信されるＰＬＳデータの第２セットであって、システム及びＤＰに対するより細部的なＰＬＳデータを伝達する。
【００５９】
ＰＬＳ２動的データ：フレーム別に動的に変わり得るＰＬＳ２データ
【００６０】
ＰＬＳ２静的データ：フレームグループのデュレーションにおいて静的に維持されるＰＬＳ２データ
【００６１】
プリアンブルシグナリングデータ：プリアンブルシンボルによって伝達され、システムの基本モードを識別するのに使用されるシグナリングデータ
【００６２】
プリアンブルシンボル：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定長のパイロットシンボル
【００６３】
注：プリアンブルシンボルは、主に高速初期バンドスキャンのために使用され、システム信号、そのタイミング、周波数オフセット及びＦＦＴサイズを検出する。
【００６４】
未来使用のために予約：現在の文書では定義されないが、未来に定義され得る。
【００６５】
スーパーフレーム：８個のフレーム繰り返し単位のセット
【００６６】
時間インターリービングブロック（ＴＩブロック）：時間インターリーバメモリの一つの用途に対応する、時間インターリービングが行われるセルのセット
【００６７】
ＴＩグループ：特定のＤＰのための動的容量割り当てが行われる単位であって、整数、すなわち、動的に変化する数のＸＦＥＣＢＬＯＣＫで構成される。
【００６８】
注：ＴＩグループは、一つのフレームに直接マッピングされたり、多数のフレームにマッピングされてもよい。これは、一つ以上のＴＩブロックを含むことができる。
【００６９】
タイプ１のＤＰ：全てのＤＰがＴＤＭ方式でマッピングされるフレームのＤＰ
【００７０】
タイプ２のＤＰ：全てのＤＰがＦＤＭ方式でマッピングされるフレームのＤＰ
【００７１】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮｃｅｌｌｓセルのセット
【００７２】
図１は、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。
【００７３】
本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、入力フォーマッティングブロック１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号を送信する装置の各モジュールの動作について、以下で説明する。
【００７４】
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳはメイン入力フォーマットであり、他のストリームタイプは一般のストリームとして処理される。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する当該帯域幅のスケジューリング及び割り当てを制御する。一つ又は多数のＴＳストリーム、ＩＰストリーム及び／又は一般のストリームの入力が同時に許容される。
【００７５】
入力フォーマッティングブロック１０００は、各入力ストリームを一つ又は多数のデータパイプにデマルチプレクスし、独立したコーディング及び変調がデータパイプに適用される。データパイプ（ＤＰ）は、ロバスト性の制御のための基本単位であって、ＱｏＳに影響を与える。一つ又は多数のサービス又はサービスコンポーネントは、単一のＤＰによって伝達されてもよい。入力フォーマッティングブロック１０００の動作についての詳細は後述する。
【００７６】
データパイプは、サービスデータ又は関連メタデータを伝達する物理層内の論理チャネルであって、一つ又は多数のサービス又はサービスコンポーネントを伝達することができる。
【００７７】
また、データパイプ単位は、フレーム内のＤＰにデータセルを割り当てる基本ユニットである。
【００７８】
ＢＩＣＭブロック１０１０において、パリティデータが誤り訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。シンボルは、当該ＤＰに使用される特定のインターリービング深さを横切ってインターリーブされる。アドバンスドプロファイルに対して、ＭＩＭＯエンコーディングがＢＩＣＭブロック１０１０で行われ、追加のデータ経路はＭＩＭＯ送信のための出力で加えられる。ＢＩＣＭブロック１０１０についての詳細は後述する。
【００７９】
フレームビルディングブロック１０２０は、入力ＤＰのデータセルをフレーム内のＯＦＤＭシンボルにマッピングすることができる。マッピングの後、周波数インターリービングは、周波数領域ダイバーシティに使用され、特に周波数選択フェージングチャネルを防止する。フレームビルディングブロック１０２０の動作についての詳細は後述する。
【００８０】
各フレームの先頭にプリアンブルを挿入した後、ＯＦＤＭ生成ブロック１０３０は、保護区間としてサイクリックプレフィックス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）を有する従来のＯＦＤＭ変調を適用することができる。アンテナ空間ダイバーシティのために、分散型ＭＩＳＯ方式が送信機に適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒｅｄｕｃｔｉｏｎ）方式が時間領域で行われる。柔軟なネットワークの計画のために、この提案は、様々なＦＦＴサイズ、保護区間の長さ及び当該パイロットパターンのセットを提供する。
【００８１】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層シグナリング情報を生成することができる。このシグナリング情報はまた、関心のあるサービスが受信側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の動作についての詳細は後述する。
【００８２】
図２、図３及び図４は、本発明の実施例に係る入力フォーマッティングブロック１０００を示す。各図面について説明する。
【００８３】
図２は、本発明の一実施例に係る入力フォーマッティングブロックを示す図である。図２は、入力信号が単一の入力ストリームであるときの入力フォーマッティングブロックを示す。
【００８４】
図２に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【００８５】
物理層への入力は、一つ又は多数のデータストリームで構成されてもよい。各データストリームは一つのＤＰによって伝達される。モード適応モジュールは、入力されるデータストリームをベースバンドフレーム（ＢＢＦ）のデータフィールドにスライスする。システムは、３つのタイプの入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、インターネットプロトコル（ＩＰ）及びＧＳ（ｇｅｎｅｒｉｃ  ｓｔｒｅａｍ）をサポートする。ＭＰＥＧ２−ＴＳは、固定長（１８８バイト）のパケットに特性化され、第１バイトはシンク（ｓｙｎｃ）バイト（０ｘ４７）である。ＩＰストリームは、ＩＰパケットヘッダー内でシグナリングされる可変長のＩＰデータグラムパケットで構成される。システムは、ＩＰストリームのためのＩＰｖ４及びＩＰｖ６をサポートする。ＧＳは、カプセル化パケットヘッダー内でシグナリングされる可変長のパケット又は固定長のパケットで構成されてもよい。
【００８６】
（ａ）は、信号ＤＰのためのモード適応ブロック２０００及びストリーム適応ブロック２０１０を示し、（ｂ）は、ＰＬＳ信号を生成し、処理するＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。
【００８７】
入力ストリームスプリッタは、入力ＴＳ、ＩＰ、ＧＳストリームを多数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離する。モード適応モジュール２０００は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ及びＢＢフレームヘッダー挿入ブロックで構成される。
【００８８】
ＣＲＣエンコーダは、ユーザパケット（ＵＰ）レベル、すなわち、ＣＲＣ−８、ＣＲＣ−１６及びＣＲＣ−３２で誤り訂正のための３つのタイプのＣＲＣエンコーディングを提供する。計算されたＣＲＣバイトは、ＵＰの後に付加される。ＣＲＣ−８はＴＳストリームに使用され、ＣＲＣ−３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しない場合、提案されたＣＲＣエンコーディングが適用されなければならない。
【００８９】
ＢＢフレームスライサは、入力を内部論理ビットフォーマットにマッピングする。最初に受信されたビットはＭＢＳであるものと定義される。ＢＢフレームスライサは、利用可能なデータフィールドの容量と同じ多数の入力ビットを割り当てる。ＢＢＦペイロードと同じ多数の入力ビットを割り当てるために、ＵＰパケットストリームは、ＢＢＦのデータフィールドに合わせてスライスされる。
【００９０】
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定長のＢＢＦヘッダーをＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）及びＲＦＵ（２ビット）で構成される。固定された２バイトのＢＢＦヘッダーに加え、ＢＢＦは、２バイトのＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。
【００９１】
ストリーム適応ブロック２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。
【００９２】
スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリーム適応への入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは“０”に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩが“１”に設定され、スタッフィングフィールドがＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
【００９３】
ＢＢスクランブラは、エネルギー分散（ｅｎｅｒｇｙ  ｄｉｓｐｅｒｓａｌ）のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同時に発生する。スクランブリングシーケンスは、フィードバックされたシフトレジスターによって生成される。
【００９４】
ＰＬＳ生成ブロック２０２０は、物理層シグナリング（ＰＬＳ）データを生成することができる。ＰＬＳは、受信機に物理層ＤＰをアクセスする手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
【００９５】
ＰＬＳ１データは、固定サイズ、コーディング及び変調を有するフレーム内のＦＳＳシンボルで伝達されるＰＬＳデータの第１セットであって、ＰＬＳ２データをデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データは、フレームグループのデュレーションにおいて一定に維持される。
【００９６】
ＰＬＳ２データは、ＦＳＳシンボルで伝送されるＰＬＳデータの第２セットであって、システム及びＤＰに対するさらに詳細なＰＬＳデータを伝達する。ＰＬＳ２は、受信機に十分なデータを提供して所望のＤＰをデコードするパラメータを含む。ＰＬＳ２シグナリングはまた、２つのタイプのパラメータ、すなわち、ＰＬＳ２静的データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２動的データ（ＰＬＳ２−ＤＹＮデータ）で構成される。ＰＬＳ２静的データは、フレームグループのデュレーションで静的に残っているＰＬＳ２データであり、ＰＬＳ２動的データは、フレーム別に動的に変わり得るＰＬＳ２データである。
【００９７】
ＰＬＳデータについての詳細は後述する。
【００９８】
ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。
【００９９】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１００】
図３は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【０１０１】
図３に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【０１０２】
図３は、入力信号が多数の入力ストリームに対応する場合、入力フォーマッティングブロックのモード適応ブロックを示す。
【０１０３】
多数の入力ストリームを処理する入力フォーマッティングブロックのモード適応ブロックは、独立して多数の入力ストリームを処理することができる。
【０１０４】
図３を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、入力ストリームスプリッタ３０００、入力ストリーム同期化器３０１０、補償遅延ブロック３０２０、ヌル（ｎｕｌｌ）パケット削除ブロック３０３０、ヘッダー圧縮ブロック３０４０、ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０及びＢＢフレームヘッダー挿入ブロック３０７０を含むことができる。モード適応ブロックの各ブロックについて、以下で説明する。
【０１０５】
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０及びＢＢフレームヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ及びＢＢヘッダー挿入ブロックに対応するので、その説明は省略する。
【０１０６】
入力ストリームスプリッタ３０００は、入力ＴＳ、ＩＰ、ＧＳストリームを多数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離することができる。
【０１０７】
入力ストリーム同期化器３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、任意の入力データフォーマットに対する一定のエンドツーエンド送信遅延及びＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）を保障する適切な手段を提供することができる。ＩＳＳＹは、常にＴＳを伝達する多数のＤＰの場合に使用され、選択的に、ＧＳストリームを伝達するＤＰに使用される。
【０１０８】
補償遅延ブロック３０２０は、ＩＳＳＹ情報の挿入後に分離されたＴＳパケットストリームを遅延して、受信機内の追加のメモリを要求せずにＴＳパケット再結合メカニズムを許容することができる。
【０１０９】
ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ使用される。任意のＴＳ入力ストリーム又は分離されたＴＳストリームは、ＣＢＲ  ＴＳストリームにＶＢＲ（ｖａｒｉａｂｌｅ  ｂｉｔ−ｒａｔｅ）サービスを収容するために存在する多数のヌルパケットを有することができる。この場合、不必要な送信オーバーヘッドを避けるために、ヌルパケットが識別され、送信されない。受信機において、除去されたヌルパケットは、送信時に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ−ｐａｃｋｅｔ）カウンタを参照して元の正確な場所に再挿入されて、一定のビットレートを保障し、タイムスタンプ（ＰＣＲ）アップデートに対する必要性を避けることができる。
【０１１０】
ヘッド圧縮ブロック３０４０は、パケットヘッダー圧縮を提供し、ＴＳ又はＩＰ入力ストリームに対する送信効率を増加させることができる。受信機が、ヘッダーの所定の部分に対する先験的な情報（ａ  ｐｒｉｏｒｉ  ｉｎｆｏｒｍａｔｉｏｎ）を有することができるため、この既知の情報は送信機で削除されてもよい。
【０１１１】
伝送ストリームに対して、受信機は、シンク−バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有する。入力ＴＳストリームが一つのＰＩＤのみを有するコンテンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベース層、ＳＶＣエンハンスメント層、ＭＶＣベースビュー又はＭＶＣ従属ビュー）に対してのみ、ＴＳパケットヘッダー圧縮が（選択的に）伝送ストリームに適用されてもよい。入力ストリームがＩＰストリームである場合、ＩＰパケットヘッダー圧縮が選択的に使用される。
【０１１２】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１１３】
図４は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【０１１４】
図４に示された入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【０１１５】
図４は、入力信号が多数の入力ストリームに対応する場合、入力フォーマッティングモジュールのストリーム適応ブロックを示す。
【０１１６】
図４を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（ｉｎ−ｂａｎｄ）シグナリングブロック４０３０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラ４０６０を含むことができる。ストリーム適応ブロックのそれぞれのブロックについて、以下で説明する。
【０１１７】
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０及びＰＬＳスクランブラ４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラ、ＰＬＳ生成ブロック及びＰＬＳスクランブラに対応するので、その説明は省略する。
【０１１８】
スケジューラ４０００は、それぞれのＤＰのＦＥＣＢＬＯＣＫの量から全体フレームにわたる全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含め、スケジューラは、ＰＬＳ２−ＤＹＮデータの値を生成し、これは、フレームのＦＳＳ内のインバンドシグナリング又はＰＬＳセルとして送信される。ＦＥＣＢＬＯＣＫ、ＥＡＣ及びＦＩＣについての詳細は後述する。
【０１１９】
１フレーム遅延ブロック４０１０は、入力データを１送信フレームだけ遅延させ、次のフレームに関するスケジューリング情報が、ＤＰに挿入されるインバンドシグナリング情報に対する現フレームを介して送信されるようにすることができる。
【０１２０】
インバンドシグナリングブロック４０３０は、ＰＬＳ２データの遅延されていない部分をフレームのＤＰに挿入することができる。
【０１２１】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１２２】
図５は、本発明の実施例に係るＢＩＣＭブロックを示す図である。
【０１２３】
図５に示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。
【０１２４】
上述したように、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１２５】
ＱｏＳは、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置によって提供されるサービスの特性に依存するので、各サービスに対応するデータは、異なる方式で処理される必要がある。したがって、本発明の実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ及びＭＩＭＯ方式を、データ経路にそれぞれ対応するデータパイプに独立して適用することによって、それに入力されたＤＰを独立して処理することができる。結果的に、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、それぞれのＤＰを介して送信されるそれぞれのサービス又はサービスコンポーネントに対するＱｏＳを制御することができる。
【０１２６】
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
【０１２７】
ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロック及びアドバンスドプロファイルによって共有されたＢＩＣＭブロックは、各ＤＰを処理する複数の処理ブロックを含むことができる。
【０１２８】
ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロック、及びアドバンスドプロファイルのためのＢＩＣＭブロックのそれぞれの処理ブロックについて、以下で説明する。
【０１２９】
ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、及び時間インターリーバ５０５０を含むことができる。
【０１３０】
データＦＥＣエンコーダ５０１０は、入力ＢＢＦに対してＦＥＣエンコーディングを行ってアウターコーディング（ＢＣＨ）及びインナーコーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。アウターコーディングＢＣＨは、選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の動作についての詳細は後述する。
【０１３１】
ビットインターリーバ５０２０は、データＦＥＣエンコーダ５０１０の出力をインターリーブし、効率的に実現可能な構造を提供しながら、ＬＤＰＣコード及び変調方式の組み合わせで最適化された性能を達成することができる。ビットインターリーバ５０２０の動作についての詳細は後述する。
【０１３２】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイル内のビットインターリーバ５０２０からの各セルワード、及びアドバンスドプロファイル内のセルワードデマルチプレクサ５０１０−１からのセルワードを変調して、パワー正規化コンステレーションポイントを提供することができる。このコンステレーションマッピングは、ＤＰに対してのみ適用される。ＱＡＭ−１６及びＮＵＱが正方形（ｓｑｕａｒｅ  ｓｈａｐｅｄ）であるが、ＮＵＣは任意の形状を有する。それぞれのコンステレーションが９０度の任意の倍数で回転すると、回転したコンステレーションは、正確に元のコンステレーションと重なる。この“回転−感覚（ｒｏｔａｔｉｏｎ−ｓｅｎｓｅ）”対称特性は、実数成分及び虚数成分の平均パワー及び容量が互いに同一になるようにする。ＮＵＱ及びＮＵＣは、各コードレートに対して特に定義され、使用される特定の一つが、ＰＬＳ２データで提出されたパラメータＤＰ_ＭＯＤによってシグナリングされる。
【０１３３】
ＳＳＤエンコーディングブロック５０４０は、２（２Ｄ）、３（３Ｄ）及び４（４Ｄ）次元でセルをプリコーディングし、異なるフェージング条件下で受信ロバスト性を増加させることができる。
【０１３４】
時間インターリーバ５０５０はＤＰレベルで動作することができる。時間インターリービング（ＴＩ）のパラメータは、各ＤＰに対して異なって設定されてもよい。時間インターリーバ５０５０の動作についての詳細は後述する。
【０１３５】
アドバンスドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー及び時間インターリーバを含むことができる。しかし、処理ブロック５０００−１は、処理ブロック５０００と区別され、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含む。
【０１３６】
また、処理ブロック５０００−１のデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー及び時間インターリーバの動作は、上述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０及び時間インターリーバ５０５０に対応するので、その説明は省略する。
【０１３７】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのＤＰに使用され、単一のセルワードストリームをＭＩＭＯ処理のためのデュアルセルワードストリームに分離する。セルワードデマルチプレクサ５０１０−１の動作についての詳細は後述する。
【０１３８】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化されている。ＭＩＭＯ技術は、容量を増加させる優れた方式であるが、チャネル特性に依存する。特に、ブロードキャスティングに対して、異なる信号伝搬特性により誘発された２つのアンテナ間の受信された信号パワーの差又はチャネルの強いＬＯＳ成分は、ＭＩＭＯから容量利得を得ることを困難にする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの１つの回転ベースのプリコーディング及び位相ランダム化を用いて、この問題を克服する。
【０１３９】
ＭＩＭＯエンコーディングは、送信機及び受信機で少なくとも２つのアンテナを必要とする２Ｘ２  ＭＩＭＯシステムを目的とすることができる。この提案で２つのＭＩＭＯエンコーディングモード、すなわち、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｆｕｌｌ−ｄｉｖｅｒｓｉｔｙ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）が定義される。ＦＲ−ＳＭエンコーディングは、受信機側で比較的小さい複雑度の増加と共に容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側で大きい複雑度の増加と共に、容量増加及び追加のダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性構成に対する制限を有しない。
【０１４０】
ＭＩＭＯ処理は、アドバンスドプロファイルフレームのために要求され得、これは、アドバンスドプロファイルフレーム内の全てのＤＰがＭＩＭＯエンコーダによって処理されることを意味する。ＭＩＭＯ処理はＤＰレベルで適用されてもよい。コンステレーションマッパー出力（ｃｏｎｓｔｅｌｌａｔｉｏｎ  ｍａｐｐｅｒ  ｏｕｔｐｕｔ）（ＮＵＱ）のペア（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力に供給され得る。ＭＩＭＯエンコーダ出力のペア（ｇ1,i及びｇ2,i）は、それぞれのＴＸアンテナのＯＦＤＭシンボル（ｌ）及び同一のキャリア（ｋ）によって送信され得る。
【０１４１】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１４２】
図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【０１４３】
図６に示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に該当する。
【０１４４】
図６は、物理層シグナリング（ＰＬＳ）、非常警戒チャネル（ＥＡＣ）及び高速情報チャネル（ＦＩＣ）の保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報を伝達するフレームの一部であり、ＦＩＣは、サービスと当該ベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャネルである。ＥＡＣ及びＦＩＣについての詳細は後述する。
【０１４５】
図６を参照すると、ＰＬＳ、ＥＡＣ及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０及びコンステレーションマッパー６０２０を含むことができる。
【０１４６】
また、ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック及びＬＤＰＣパリティパンクチャリングブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて、以下で説明する。
【０１４７】
ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ  １／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
【０１４８】
スクランブラは、ＢＣＨエンコーディング及び短縮及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
【０１４９】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のために短縮されたＢＣＨコードを用いて、スクランブルされたＰＬＳ  １／２データに対してアウターエンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ＬＤＰＣエンコーディングの前にゼロ挿入の出力ビットがパーミュート（ｐｅｒｍｕｔｅ）され得る。
【０１５０】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロック（Ｃldpc）を生成するために、パリティビット（Ｐldpc）が、それぞれのゼロ挿入ＰＬＳ情報ブロック（Ｉldpc）から組織的にエンコードされ、その後に付加される。
【０１５１】
【数１】
0006474835.tif 000005
【０１５２】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４の通りである。
【０１５３】
【表４】
0006474835.tif 000006
【０１５４】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０１５５】
ＰＬＳ１データの保護に短縮が適用されると、任意のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データの保護のために、ＰＬＳ２のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。これらのパンクチャされたビットは送信されない。
【０１５６】
ビットインターリーバ６０１０は、それぞれ短縮及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブする。
【０１５７】
コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
【０１５８】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１５９】
図７は、本発明の一実施例に係るフレームビルディングブロックを示す図である。
【０１６０】
図７に示されたフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の実施例に該当する。
【０１６１】
図７を参照すると、フレームビルディングブロックは、遅延補償ブロック７０００、セルマッパー７０１０及び周波数インターリーバ７０２０を含むことができる。フレームビルディングブロックのそれぞれのブロックについて、以下で説明する。
【０１６２】
遅延補償ブロック７０００は、データパイプと対応ＰＬＳデータとの間のタイミングを調節し、送信端で時間が共に合わせられるように保障することができる。ＰＬＳデータは、入力フォーマッティングブロック及びＢＩＣＭブロックによって誘発されたデータパイプの遅延を処理することによって、データパイプと同じ量だけ遅延する。ＢＩＣＭブロックの遅延は、主に時間インターリーバ５０５０に起因する。インバンドシグナリングデータが、次のＴＩグループの情報を伝達して、シグナリングされるＤＰよりも１フレームだけ先に伝達される。したがって、遅延補償ブロックはインバンドシグナリングデータを遅延させる。
【０１６３】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルを、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、もしあれば、ＤＰ、ＰＬＳセル及びＥＡＣ／ＦＩＣセルのそれぞれに対してＴＩによって生成されたデータセルを、フレーム内のＯＦＤＭシンボルのそれぞれに対応するアクティブＯＦＤＭセルのアレイにマッピングすることである。サービスシグナリングデータ（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩ））は、データパイプによって個別的に収集されて伝送されてもよい。セルマッパーは、スケジューラによって生成された動的情報及びフレーム構造の構成によって動作する。フレームについての詳細は後述する。
【０１６４】
周波数インターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシティを提供することができる。また、周波数インターリーバ７０２０は、異なるインターリービングシード（ｉｎｔｅｒｌｅａｖｉｎｇ−ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されるＯＦＤＭシンボルペアに対して動作し、単一のフレーム内の最大のインターリービング利得を得ることができる。周波数インターリーバ７０２０の動作についての詳細は後述する。
【０１６５】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１６６】
図８は、本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。
【０１６７】
図８に示されたＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の実施例に該当する。
【０１６８】
ＯＦＤＭ生成ブロックは、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、送信される時間領域信号を生成する。また、このブロックは、順次に保護区間を挿入し、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）減少処理を適用して最終ＲＦ信号を生成する。
【０１６９】
図８を参照すると、フレームビルディングブロックは、パイロット及び予約トーン挿入ブロック８０００、２Ｄ−ｅＳＦＮエンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ  ｆａｓｔ  Ｆｏｕｒｉｅｒ  ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、他のシステム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。フレームビルディングブロックのそれぞれのブロックについて、以下で説明する。
【０１７０】
パイロット及び予約トーン挿入ブロック８０００は、パイロット及び予約トーンを挿入することができる。
【０１７１】
ＯＦＤＭシンボル内の様々なセルは、パイロットとして知られた基準情報に変調され、パイロットは、受信機で先験的に知られた送信値を有する。パイロットセルの情報は、分散されたパイロット、繰り返しパイロット（ｃｏｎｔｉｎｕａｌ  ｐｉｌｏｔ）、エッジパイロット、ＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）パイロット及びＦＥＳ（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）パイロットで構成される。それぞれのパイロットは、パイロットタイプ及びパイロットパターンに応じて特定のブーストパワーレベルで送信される。パイロット情報の値は、任意の与えられたシンボル上のそれぞれの送信されたキャリアに対して一連の値である基準シーケンスから導出される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定及び送信モード識別に使用することができ、また、位相雑音をフォロウする（ｆｏｌｌｏｗｉｎｇ）のに使用することができる。
【０１７２】
基準シーケンスから取られた基準情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除いた全てのシンボルにおいて分散されたパイロットセルで送信される。繰り返しパイロットは、フレームの全てのシンボルに挿入される。繰り返しパイロットの数及び位置は、ＦＦＴサイズ及び分散されたパイロットパターンに依存する。エッジキャリアは、プリアンブルシンボルを除いた全てのシンボル内のエッジパイロットである。これらは、スペクトルのエッジまで周波数補間を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。これらは、フレームのエッジまで時間補間を許容するために挿入される。
【０１７３】
本発明の実施例に係るシステムは、ＳＦＮネットワークをサポートし、分散型ＭＩＳＯ方式は、選択的に非常に堅固な送信モードをサポートするために使用される。２Ｄ−ｅＳＦＮは、多数のＴＸアンテナを用いる分散型ＭＩＳＯ方式であり、それぞれのＴＸアンテナは、ＳＦＮネットワーク内の異なる送信側に配置される。
【０１７４】
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために、２Ｄ−ｅＳＦＮ処理を行い、多数の送信機から送信された信号の位相を歪ませることができる。したがって、長時間の低いフラットフェージング又は深いフェージングによるバースト誤りを緩和することができる。
【０１７５】
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロットとして（又は予約トーンとして）指定されていないデータシンボル内の任意のセルは、周波数インターリーバからのデータセルのうち１つを伝達する。セルは、ＯＦＤＭキャリアにマッピングされる。
【０１７６】
ＰＡＰＲ減少ブロック８０３０は、時間領域内の様々なＰＡＰＲ減少アルゴリズムを用いて、入力信号に対するＰＡＰＲ減少を行うことができる。
【０１７７】
保護区間挿入ブロック８０４０は、保護区間を挿入することができ、プリアンブル挿入ブロック８０５０は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造についての詳細は後述する。他のシステム挿入ブロック８０６０は、時間領域で複数の放送送受信システムの信号をマルチプレクスして、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域幅で同時に送信され得る。この場合、２つ以上の異なる放送送受信システムは、異なる放送サービスを提供するシステムのことをいう。異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味し得る。それぞれの放送サービスと関連するデータは、異なるフレームを介して送信されてもよい。
【０１７８】
ＤＡＣブロック８０７０は、入力デジタル信号をアナログ信号に変換し、アナログ信号を出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって多数の出力アンテナを介して送信されてもよい。本発明の実施例に係るＴＸアンテナは、垂直又は水平の極性（ｐｏｌａｒｉｔｙ）を有することができる。
【０１７９】
上述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１８０】
図９は、本発明の実施例によって未来の放送サービスのための放送信号を受信する装置の構造を示す図である。
【０１８１】
本発明の実施例によって未来の放送サービスのための放送信号を受信する装置は、図１を参照して説明した未来の放送サービスのために放送信号を送信する装置に対応し得る。
【０１８２】
本発明の実施例によって未来の放送サービスのための放送信号を受信する装置は、同期化及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０及びシグナリングデコーディングモジュール９０４０を含むことができる。放送信号を受信する装置の各モジュールの動作について、以下で説明する。
【０１８３】
同期化及び復調モジュール９０００は、ｍ個のＲｘアンテナを介して入力信号を受信し、放送信号を受信する装置に対応するシステムに対して信号検出及び同期化を行い、放送信号を送信する装置によって行われる手順の逆の手順に対応する復調を行うことができる。
【０１８４】
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが送信されるデータを抽出することができる。放送信号を送信する装置がインターリービングを行うと、フレームパーシングモジュール９０１０は、インターリービングの逆の手順に対応するデインターリービングを行うことができる。この場合、抽出される必要がある信号及びデータの位置は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードして、放送信号を送信する装置によって生成されたシグナリング情報を復元することによって得られる。
【０１８５】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、送信効率のために適用されたマッピングに対してデマッピングを行い、デコーディングを通じて送信チャネルに対して生成された誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングに必要な送信パラメータを得ることができる。
【０１８６】
出力プロセッサ９０３０は、放送信号を送信して送信効率を改善する装置によって適用される様々な圧縮／信号処理手順の逆の手順を行うことができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を得ることができる。出力プロセッサ９０３０の出力は、放送信号を送信する装置に入力される信号に対応し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及び一般のストリームであってもよい。
【０１８７】
シグナリングデコーディングモジュール９０４０は、同期化及び復調モジュール９０００によって復調された信号からＰＬＳ情報を得ることができる。上述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０及び出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０１８８】
図１０は、本発明の実施例に係るフレーム構造を示す図である。
【０１８９】
図１０は、スーパーフレーム内のフレームタイプ及びＦＲＵの例示的な構成を示す。（ａ）は、本発明の実施例に係るスーパーフレームを示し、（ｂ）は、本発明の実施例に係るＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）を示し、（ｃ）は、ＦＲＵ内の可変ＰＨＹプロファイルのフレームを示し、（ｄ）は、フレームの構造を示す。
【０１９０】
スーパーフレームは、８個のＦＲＵで構成されてもよい。ＦＲＵは、フレームのＴＤＭのための基本マルチプレクシング単位であり、スーパーフレーム内で８回繰り返される。
【０１９１】
ＦＲＵ内の各フレームは、ＰＨＹプロファイル（ベース、ハンドヘルド、アドバンスド）又はＦＥＴのうちの１つに属する。ＦＲＵ内のフレームの最大許容数は４であり、与えられたＰＨＹプロファイルは、ＦＲＵ（例えば、ベース、ベース、ハンドヘルド、アドバンスド）において０倍〜４倍までの任意の回数だけ現れることができる。ＰＨＹプロファイルの定義は、必要であれば、プリアンブル内のＰＨＹ_ＰＲＯＦＩＬＥの予約値を用いて拡張可能である。
【０１９２】
ＦＥＴ部分は、含まれる場合、ＦＲＵの終わりに挿入される。ＦＥＴがＦＲＵに含まれる場合、スーパーフレームにおいてＦＥＴの最小数は８である。ＦＥＴ部分が互いに隣接することは推奨されない。
【０１９３】
一つのフレームはまた、多数のＯＦＤＭシンボルとプリアンブルに分離される。（ｄ）に示されたように、フレームは、プリアンブル、一つ以上のフレームシグナリングシンボル（ＦＳＳ）、正常データシンボル及びフレームエッジシンボル（ＦＥＳ）を含む。
【０１９４】
プリアンブルは、高速フューチャーキャストＵＴＢシステム信号検出が可能であり、信号の効率的な送受信のための基本送信パラメータのセットを提供する特殊シンボルである。プリアンブルについての詳細は後述する。
【０１９５】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化、チャネル推定及びＰＬＳデータの高速デコーディングのために、ＦＳＳは、正常データシンボルよりもさらに密集したパイロットパターンを有する。ＦＥＳは、正確にＦＳＳと同じパイロットを有し、これは、ＦＥＳ直前のシンボルに対して外挿せずに、ＦＥＳ内の周波数専用補間及び時間補間を可能にする。
【０１９６】
図１１は、本発明の実施例に係るフレームのシグナリング階層構造を示す図である。
【０１９７】
図１１は、３つの主要部分、すなわち、プリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０及びＰＬＳ２データ１１０２０に分離されたシグナリング階層構造を示す。全てのフレームにおいてプリアンブルシンボルによって伝達されるプリアンブルの目的は、そのフレームの送信タイプ及び基本送信パラメータを指示することである。ＰＬＳ１は、受信機がＰＬＳ２データをアクセス及びデコードするようにし、これは、関心のあるＤＰをアクセスするパラメータを含む。ＰＬＳ２は、全てのフレームにおいて伝達され、２つの主要部分、すなわち、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータに分離される。ＰＬＳ２データの静的及び動的部分は、必要であれば、パディングが後続する。
【０１９８】
図１２は、本発明の実施例に係るプリアンブルシグナリングデータを示す図である。
【０１９９】
プリアンブルシグナリングデータは、フレーム構造内で受信機がＰＬＳデータをアクセスし、ＤＰをトレースするようにするために必要な情報の２１ビットを伝達する。プリアンブルシグナリングについての詳細は、次の通りである。
【０２００】
ＰＨＹ_ＰＲＯＦＩＬＥ：この３ビットフィールドは、現フレームのＰＨＹプロファイルタイプを示す。異なるＰＨＹプロファイルタイプのマッピングは、下記の表５に与えられる。
【０２０１】
【表５】
0006474835.tif 000007
【０２０２】
ＦＦＴ_ＳＩＺＥ：この２ビットフィールドは、下記の表６に記載されたように、フレームグループ内の現フレームのＦＦＴサイズを示す。
【０２０３】
【表６】
0006474835.tif 000008
【０２０４】
ＧＩ_ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、下記の表７に記載されたように、現スーパーフレーム内の保護区間分数（ｆｒａｃｔｉｏｎ）値を示す。
【０２０５】
【表７】
0006474835.tif 000009
【０２０６】
ＥＡＣ_ＦＬＡＧ：この１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。このフィールドが“１”に設定されると、ＥＡＳ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｓｅｒｖｉｃｅ）が現フレームで提供される。このフィールドが“０”に設定されると、ＥＡＳが現フレームで伝達されない。このフィールドは、スーパーフレーム内で動的にスイッチングされ得る。
【０２０７】
ＰＩＬＯＴ_ＭＯＤＥ：この１ビットフィールドは、プロファイルモードが現フレームグループ内の現フレームに対してモバイルモードであるか、又は固定モードであるかを示す。このフィールドが“０”に設定されると、モバイルパイロットモードが使用される。このフィールドが“１”に設定されると、固定パイロットモードが使用される。
【０２０８】
ＰＡＰＲ_ＦＬＡＧ：この１ビットフィールドは、ＰＡＰＲ減少が現フレームグループ内の現フレームに使用されるか否かを示す。このフィールドが“１”に設定されると、ＰＡＰＲ減少にトーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）が使用される。このフィールドが“０”に設定されると、ＰＡＰＲ減少が使用されない。
【０２０９】
ＦＲＵ_ＣＯＮＦＩＧＵＲＥ：この３ビットフィールドは、現スーパーフレーム内に存在するＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）のＰＨＹプロファイルタイプ構成を示す。現スーパーフレームで伝達される全てのプロファイルタイプは、現スーパーフレーム内の全てのフレーム内のこのフィールドで識別される。３ビットフィールドは、下記の表８に示されたように、各プロファイルに対する異なる定義を有する。
【０２１０】
【表８】
0006474835.tif 000010
【０２１１】
ＲＥＳＥＲＶＥＤ：この７ビットフィールドが、未来の使用のために予約される。
【０２１２】
図１３は、本発明の実施例に係るＰＬＳ１データを示す図である。
【０２１３】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするのに必要なパラメータを含む基本送信パラメータを提供する。上述したように、ＰＬＳ１データは、一つのフレームグループの全デュレーションにおいて変更されない。ＰＬＳ１データのシグナリングフィールドの詳細な定義は、次の通りである。
【０２１４】
ＰＲＥＡＭＢＬＥ_ＤＡＴＡ：この２０ビットフィールドは、ＥＡＣ_ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。
【０２１５】
ＮＵＭ_ＦＲＡＭＥ_ＦＲＵ：この２ビットフィールドは、ＦＲＵ当たりのフレームの数を示す。
【０２１６】
ＰＡＹＬＯＡＤ_ＴＹＰＥ：この３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ_ＴＹＰＥは、表９に示されたようにシグナリングされる。
【０２１７】
【表９】
0006474835.tif 000011
【０２１８】
ＮＵＭ_ＦＳＳ：この２ビットフィールドは、現フレーム内のＦＳＳシンボルの数を示す。
【０２１９】
ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮ：この８ビットフィールドは、送信された信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮは、２つの４ビットフィールド、すなわちメジャーバージョンとマイナーバージョンに分離される。
【０２２０】
メジャーバージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮフィールドのＭＳＢ  ４ビットは、メジャーバージョン情報を示す。メジャーバージョンフィールドの変化は、非−下位−互換（ｎｏｎ−ｂａｃｋｗａｒｄ−ｃｏｍｐａｔｉｂｌｅ）変化を示す。デフォルト値は“００００”である。この標準に記載されたバージョンにおいて、値は“００００”に設定される。
【０２２１】
マイナーバージョン：ＳＹＳＴＥＭ_ＶＥＲＳＩＯＮのＬＳＢ  ４ビットは、マイナーバージョン情報を示す。マイナーバージョンフィールドの変化は下位互換性である。
【０２２２】
ＣＥＬＬ_ＩＤ：これは、ＡＴＳＣネットワークで地理的なセルを固有に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジ領域は、フューチャーキャストＵＴＢシステムに使用される周波数の数に依存し、一つ以上の周波数で構成されてもよい。ＣＥＬＬ_ＩＤの値が知られていないか、又は特定されない場合、このフィールドは“０”に設定される。
【０２２３】
ＮＥＴＷＯＲＫ_ＩＤ：これは、現在のＡＴＳＣネットワークを固有に識別する１６ビットフィールドである。
【０２２４】
ＳＹＳＴＥＭ_ＩＤ：この１６ビットフィールドは、ＡＴＳＣネットワーク内のフューチャーキャストＵＴＢシステムを固有に識別する。フューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である、地上波放送システムである。フューチャーキャストＵＴＢシステムは、もしあれば、一つ以上のＰＨＹプロファイル及びＦＥＴを伝達する。同じフューチャーキャストＵＴＢシステムは、異なる入力ストリームを伝達することができ、異なる地理的領域で異なるＲＦ周波数を使用してローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての送信に対して同一である。一つ以上のフューチャーキャストＵＴＢシステムは、いずれも同一の物理層構造及び構成を有するということを意味する同一のＳＹＳＴＥＭ_ＩＤを有することができる。
【０２２５】
次のループは、各フレームタイプのＦＲＵ構成及び長さを示すのに使用されるＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ、ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ、ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ及びＲＥＳＥＲＶＥＤで構成される。ループサイズは固定され、４個のＰＨＹプロファイル（ＦＥＴを含む）がＦＲＵ内でシグナリングされる。ＮＵＭ_ＦＲＡＭＥ_ＦＲＵが４よりも小さいと、使用されていないフィールドはゼロで埋められる。
【０２２６】
ＦＲＵ_ＰＨＹ_ＰＲＯＦＩＬＥ：この３ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目（ｉはループインデックスである）のフレームのＰＨＹプロファイルタイプを示す。このフィールドは、表８に示されたように、同じシグナリングフォーマットを使用する。
【０２２７】
ＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨ：この２ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮと共にＦＲＵ_ＦＲＡＭＥ_ＬＥＮＧＴＨを用いて、フレームデュレーションの正確な値を得ることができる。
【０２２８】
ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、関連するＦＲＵの（ｉ＋１）番目のフレームの保護区間分数値を示す。ＦＲＵ_ＧＩ_ＦＲＡＣＴＩＯＮは、表７に従ってシグナリングされる。
【０２２９】
ＲＥＳＥＲＶＥＤ：この４ビットフィールドは、未来の使用のために予約される。
【０２３０】
次のフィールドは、ＰＬＳ２データをデコードするパラメータを提供する。
【０２３１】
ＰＬＳ２_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、ＰＬＳ２保護によって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナリングされる。ＬＤＰＣコードについての詳細は後述する。
【０２３２】
【表１０】
0006474835.tif 000012
【０２３３】
ＰＬＳ２_ＭＯＤ：この３ビットフィールドは、ＰＬＳ２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２３４】
【表１１】
0006474835.tif 000013
【０２３５】
ＰＬＳ２_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃtotal_partial_block）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２３６】
ＰＬＳ２_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのビットサイズを示す。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２３７】
ＰＬＳ２_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのビットサイズを示す。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２３８】
ＰＬＳ２_ＲＥＰ_ＦＬＡＧ：この１ビットフラグは、現フレームグループでＰＬＳ２繰り返しモードが使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＰＬＳ２繰り返しモードが活性化される。このフィールドの値が“０”に設定されると、ＰＬＳ２繰り返しモードが非活性化される。
【０２３９】
ＰＬＳ２_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２繰り返しが使用されるとき、現フレームグループの全てのフレームで伝達されるＰＬＳ２に対する部分コーディングブロック（ｐａｒｔｉａｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃｔｏｔａｌ_ｐａｒｔｉａｌ_ｂｌｏｃｋ）を示す。繰り返しが使用されないと、このフィールドの値は０と同一である。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２４０】
ＰＬＳ２_ＮＥＸＴ_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナリングされる。
【０２４１】
ＰＬＳ２_ＮＥＸＴ_ＭＯＤ：この３ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２４２】
ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＦＬＡＧ：この１ビットフィールドは、次のフレームグループでＰＬＳ２繰り返しモードが使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＰＬＳ２繰り返しモードが活性化される。このフィールドの値が“０”に設定されると、ＰＬＳ２繰り返しモードが非活性化される。
【０２４３】
ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２繰り返しが使用されるとき、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に対するフルコーディングブロック（ｆｕｌｌ  ｃｏｄｅｄ  ｂｌｏｃｋｓ）の集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）（Ｃtotal_partial_block）を示す。次のフレームグループで繰り返しが使用されないと、このフィールドの値は０と同一である。この値は、現フレームグループの全デューレーションにおいて一定である。
【０２４４】
ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＳＴＡＴ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのビットサイズを示す。この値は、現フレームグループにおいて一定である。
【０２４５】
ＰＬＳ２_ＮＥＸＴ_ＲＥＰ_ＤＹＮ_ＳＩＺＥ_ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのビットサイズを示す。この値は、現フレームグループにおいて一定である。
【０２４６】
ＰＬＳ２_ＡＰ_ＭＯＤＥ：この２ビットフィールドは、現フレームグループ内のＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デュレーションにおいて一定である。下記の表１２は、このフィールドの値を示す。このフィールドが“００”に設定されると、現フレームでＰＬＳ２に対して追加のパリティが使用されない。
【０２４７】
【表１２】
0006474835.tif 000014
【０２４８】
ＰＬＳ２_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２４９】
ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＭＯＤＥ：この２ビットフィールドは、次のフレームグループでＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現フレームグループの全デュレーションにおいて一定である。表１２は、このフィールドの値を定義する。
【０２５０】
ＰＬＳ２_ＮＥＸＴ_ＡＰ_ＳＩＺＥ_ＣＥＬＬ：この１５ビットフィールドは、次のフレームグループの全てのフレームでＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２５１】
ＲＥＳＥＲＶＥＤ：この３２ビットフィールドは、未来の使用のために予約される。
【０２５２】
ＣＲＣ_３２：全ＰＬＳ１シグナリングに適用される３２ビットの誤り検出コード
【０２５３】
図１４は、本発明の実施例に係るＰＬＳ２データを示す図である。
【０２５４】
図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは、現フレームに特定された情報を提供する。
【０２５５】
ＰＬＳ２−ＳＴＡＴデータのフィールドについての詳細は、次の通りである。
【０２５６】
ＦＩＣ_ＦＬＡＧ：この１ビットフィールドは、ＦＩＣが現フレームグループに使用されるか否かを示す。このフィールドが“１”に設定されると、ＦＩＣが現フレームで提供される。このフィールドが“０”に設定されると、ＦＩＣが現フレームで伝達されない。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２５７】
ＡＵＸ_ＦＬＡＧ：この１ビットフィールドは、現フレームグループで補助ストリームが使用されるか否かを示す。このフィールドが“１”に設定されると、補助ストリームが現フレームで提供される。このフィールドが“０”に設定されると、補助ストリームが現フレームで伝達されない。この値は、現フレームグループの全デュレーションにおいて一定である。
【０２５８】
ＮＵＭ_ＤＰ：この６ビットフィールドは、現フレームで伝達されるＤＰの数を示す。このフィールドの値は１〜６４の範囲内にあり、ＤＰの数は、ＮＵＭ_ＤＰ＋１である。
【０２５９】
ＤＰ_ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内でＤＰを固有に識別する。
【０２６０】
ＤＰ_ＴＹＰＥ：この３ビットフィールドはＤＰのタイプを示す。これは、下記の表１３に従ってシグナリングされる。
【０２６１】
【表１３】
0006474835.tif 000015
【０２６２】
ＤＰ_ＧＲＯＵＰ_ＩＤ：この８ビットフィールドは、現ＤＰが関連しているＤＰグループを識別する。これは、受信機が特定のサービスと関連するサービスコンポーネントのＤＰをアクセスするのに使用することができ、これらＤＰは、同じＤＰ_ＧＲＯＵＰ_ＩＤを有する。
【０２６３】
ＢＡＳＥ_ＤＰ_ＩＤ：この６ビットフィールドは、管理層で使用されるサービスシグナリングデータ（ＰＳＩ／ＳＩ）を伝達するＤＰを示す。ＢＡＳＥ_ＤＰ_ＩＤで指示されたＤＰは、サービスシグナリングデータのみを伝達する専用ＤＰ、又はサービスデータと共にサービスシグナリングデータを伝達する正常ＤＰであってもよい。
【０２６４】
ＤＰ_ＦＥＣ_ＴＹＰＥ：この２ビットフィールドは、関連するＤＰによって使用されるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナリングされる。
【０２６５】
【表１４】
0006474835.tif 000016
【０２６６】
ＤＰ_ＣＯＤ：この４ビットフィールドは、関連するＤＰによって使用されるコードレートを示す。コードレートは、下記の表１５に従ってシグナリングされる。
【０２６７】
【表１５】
0006474835.tif 000017
【０２６８】
ＤＰ_ＭＯＤ：この４ビットフィールドは、関連するＤＰによって使用される変調を示す。変調は、下記の表１６に従ってシグナリングされる。
【０２６９】
【表１６】
0006474835.tif 000018
【０２７０】
ＤＰ_ＳＳＤ_ＦＬＡＧ：この１ビットフィールドは、ＳＳＤモードが関連するＤＰで使用されるか否かを示す。このフィールドの値が“１”に設定されると、ＳＳＤが使用される。このフィールドの値が“０”に設定されると、ＳＳＤが使用されない。
【０２７１】
ＰＨＹ_ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す“０１０”と同一である場合にのみ、次のフィールドが現れる。
【０２７２】
ＤＰ_ＭＩＭＯ：この３ビットフィールドは、関連するＤＰにどのタイプのＭＩＭＯエンコーディングプロセスが適用されるかを示す。ＭＩＭＯエンコーディングプロセスのタイプは、表１７に従ってシグナリングされる。
【０２７３】
【表１７】
0006474835.tif 000019
【０２７４】
ＤＰ_ＴＩ_ＴＹＰＥ：この１ビットフィールドは、時間インターリービングのタイプを示す。“０”の値は、一つのＴＩグループが一つのフレームに対応し、一つ以上のＴＩブロックを含むことを示す。“１”の値は、一つのＴＩグループが１よりも多いフレームで伝達され、一つのＴＩブロックのみを含むことを示す。
【０２７５】
ＤＰ_ＴＩ_ＬＥＮＧＴＨ：２ビットフィールドの使用（許容される値が、単に１、２、４、８である）は、次のように、ＤＰ_ＴＩ_ＴＹＰＥフィールド内に設定された値によって決定される。
【０２７６】
ＤＰ_ＴＩ_ＬＥＮＧＴＨの値が“１”に設定されると、このフィールドは、ＰI、すなわち、各ＴＩグループがマッピングされるフレームの数を示し、ＴＩグループ当たり一つのＴＩブロックがある（ＮTI＝１）。２ビットフィールドを有する許容されたＰIの値は、下記の表１８で定義される。
【０２７７】
ＤＰ_ＴＩ_ＴＹＰＥの値が“０”に設定されると、このフィールドは、ＴＩグループ当たりのＴＩブロックの数（ＮTI）を示し、フレーム当たり一つのＴＩグループがある（ＰI＝１）。２ビットフィールドを有する許容されたＰIの値は、下記の表１８で定義される。
【０２７８】
【表１８】
0006474835.tif 000020
【０２７９】
ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ：この２ビットフィールドは、関連するＤＰに対するフレームグループ内のフレーム区間（ＩJUMP）を示し、許容される値は、１，２，４，８である（対応する２ビットフィールドは、それぞれ“００”，“０１”，“１０”，“１１”である）。フレームグループの全てのフレームで現れないＤＰに対して、このフィールドの値は、連続的なフレーム間の間隔と同一である。例えば、ＤＰがフレーム１，５，９，１３などで現れると、このフィールドは“４”に設定される。全てのフレームで現れるＤＰに対して、このフィールドは“１”に設定される。
【０２８０】
ＤＰ_ＴＩ_ＢＹＰＡＳＳ：この１ビットフィールドは、時間インターリーバ５０５０の利用可能性を決定する。ＤＰに対して時間インターリービングが使用されないと、これは“１”に設定される。時間インターリービングが使用されると、これは“０”に設定される。
【０２８１】
ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸ：この５ビットフィールドは、現ＤＰが発生するスーパーフレームの第１フレームのインデックスを示す。ＤＰ_ＦＩＲＳＴ_ＦＲＡＭＥ_ＩＤＸの値は、０〜３１の範囲内にある。
【０２８２】
ＤＰ_ＮＵＭ_ＢＬＯＣＫ_ＭＡＸ：この１０ビットフィールドは、このＤＰに対してＤＰ_ＮＵＭ_ＢＬＯＣＫＳの最大値を示す。このフィールドの値は、ＤＰ_ＮＵＭ_ＢＬＯＣＫＳと同一の範囲を有する。
【０２８３】
ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードデータのタイプを示す。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥは、下記の表１９に従ってシグナリングされる。
【０２８４】
【表１９】
0006474835.tif 000021
【０２８５】
ＤＰ_ＩＮＢＡＮＤ_ＭＯＤＥ：この２ビットフィールドは、現ＤＰがインバンドシグナリング情報を伝達するか否かを示す。インバンドシグナリングタイプは、下記の表２０に従ってシグナリングされる。
【０２８６】
【表２０】
0006474835.tif 000022
【０２８７】
ＤＰ_ＰＲＯＴＯＣＯＬ_ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードのプロトコルタイプを示す。入力ペイロードタイプが選択されると、下記の表２１に従ってシグナリングされる。
【０２８８】
【表２１】
0006474835.tif 000023
【０２８９】
ＤＰ_ＣＲＣ_ＭＯＤＥ：この２ビットフィールドは、入力フォーマッティングブロックでＣＲＣエンコーディングが使用されるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナリングされる。
【０２９０】
【表２２】
0006474835.tif 000024
【０２９１】
ＤＮＰ_ＭＯＤＥ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるヌルパケット削除モードを示す。ＤＮＰ_ＭＯＤＥは、下記の表２３に従ってシグナリングされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）でなければ、ＤＮＰ_ＭＯＤＥの値は“００”に設定される。
【０２９２】
【表２３】
0006474835.tif 000025
【０２９３】
ＩＳＳＹ_ＭＯＤＥ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるＩＳＳＹモードを示す。ＩＳＳＹ_ＭＯＤＥは、下記の表２４に従ってシグナリングされる。ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）でなければ、ＩＳＳＹ_ＭＯＤＥの値は“００”に設定される。
【０２９４】
【表２４】
0006474835.tif 000026
【０２９５】
ＨＣ_ＭＯＤＥ_ＴＳ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定されるとき、関連するＤＰによって使用されるＴＳヘッダー圧縮モードを示す。ＨＣ_ＭＯＤ_ＴＳは、下記の表２５に従ってシグナリングされる。
【０２９６】
【表２５】
0006474835.tif 000027
【０２９７】
ＨＣ_ＭＯＤＥ_ＩＰ：この２ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＩＰ（“０１”）に設定されるときのＩＰヘッダー圧縮モードを示す。ＨＣ_ＭＯＤ_ＩＰは、下記の表２６に従ってシグナリングされる。
【０２９８】
【表２６】
0006474835.tif 000028
【０２９９】
ＰＩＤ：この１３ビットフィールドは、ＤＰ_ＰＡＹＬＯＡＤ_ＴＹＰＥがＴＳ（“００”）に設定され、ＨＣ_ＭＯＤＥ_ＴＳが“０１”又は“１０”に設定されるときのＴＳヘッダー圧縮のためのＰＩＤ番号を示す。
【０３００】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために予約される。
【０３０１】
ＦＩＣ_ＦＬＡＧが“１”と同一である場合にのみ、次のフィールドが現れる。
【０３０２】
ＦＩＣ_ＶＥＲＳＩＯＮ：この８ビットフィールドは、ＦＩＣのバージョン番号を示す。
【０３０３】
ＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：この１３ビットフィールドは、ＦＩＣのバイト長を示す。
【０３０４】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために予約される。
【０３０５】
ＡＵＸ_ＦＬＡＧが“１”と同一である場合にのみ、次のフィールドが現れる。
【０３０６】
ＮＵＭ_ＡＵＸ：この４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを意味する。
【０３０７】
ＡＵＸ_ＣＯＮＦＩＧ_ＲＦＵ：この８ビットフィールドは、未来の使用のために予約される。
【０３０８】
ＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥ：この４ビットフィールドは、現在の補助ストリームのタイプを示すための未来の使用のために予約される。
【０３０９】
ＡＵＸ_ＰＲＩＶＡＴＥ_ＣＯＮＦＩＧ：この２８ビットフィールドは、補助ストリームをシグナリングするための未来の使用のために予約される。
【０３１０】
図１５は、本発明の他の実施例に係るＰＬＳ２データを示す図である。
【０３１１】
図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮデータを示す。ＰＬＳ２−ＤＹＮデータの値は、一つのフレームグループのデュレーションで変わり得、フィールドのサイズは一定に維持される。
【０３１２】
ＰＬＳ２−ＤＹＮデータのフィールドについての詳細は、次の通りである。
【０３１３】
ＦＲＡＭＥ_ＩＮＤＥＸ：この５ビットフィールドは、スーパーフレーム内の現フレームのフレームインデックスを示す。スーパーフレームの第１フレームのインデックスは“０”に設定される。
【０３１４】
ＰＬＳ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナリングされる値によって指示される。このフィールドの値が“００００”に設定されると、スケジューリングされた変化が予想されていないことを意味し、値“１”は、次のスーパーフレームで変化があることを意味する。
【０３１５】
ＦＩＣ_ＣＨＡＮＧＥ_ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成（すなわち、ＦＩＣの内容）が変更される前のスーパーフレームの数を示す。構成において変更された次のスーパーフレームは、このフィールド内でシグナリングされる値によって指示される。このフィールドの値が“００００”に設定されると、スケジューリングされた変化が予想されていないことを意味し、値“０００１”は、次のスーパーフレームで変化があることを意味する。
【０３１６】
ＲＥＳＥＲＶＥＤ：この１６ビットフィールドは、未来の使用のために予約される。
【０３１７】
ＮＵＭ_ＤＰを通じてループで次のフィールドが現れ、これは、現フレームで伝達されるＤＰと関連するパラメータを示す。
【０３１８】
ＤＰ_ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内のＤＰを固有に示す。
【０３１９】
ＤＰ_ＳＴＡＲＴ：この１５ビット（又は１３ビット）フィールドは、ＤＰＵアドレッシング方式を用いて第１ＤＰの開始位置を示す。ＤＰ_ＳＴＡＲＴフィールドは、下記の表２７に示されたように、ＰＨＹプロファイル及びＦＦＴサイズに応じて異なる長さを有する。
【０３２０】
【表２７】
0006474835.tif 000029
【０３２１】
ＤＰ_ＮＵＭ_ＢＬＯＣＫ：この１０ビットフィールドは、現ＤＰに対する現ＴＩグループ内のＦＥＣブロックの数を示す。ＤＰ_ＮＵＭ_ＢＬＯＣＫの値は、０〜１０２３の範囲内にある。
【０３２２】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために予約される。
【０３２３】
次のフィールドは、ＥＡＣと関連するＦＩＣパラメータを示す。
【０３２４】
ＥＡＣ_ＦＬＡＧ：この１ビットフィールドは、現フレーム内のＥＡＣの存在を示す。このビットは、プリアンブル内のＥＡＣ_ＦＬＡＧと同じ値である。
【０３２５】
ＥＡＳ_ＷＡＫＥ_ＵＰ_ＶＥＲＳＩＯＮ_ＮＵＭ：この８ビットフィールドは、ウェークアップ指示のバージョン番号を示す。
【０３２６】
ＥＡＣ_ＦＬＡＧフィールドが“１”と同一である場合、次の１２ビットは、ＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥフィールドに対して割り当てられる。ＥＡＣ_ＦＬＡＧフィールドが“０”と同一である場合、次の１２ビットはＥＡＣ_ＣＯＵＮＴＥＲに割り当てられる。
【０３２７】
ＥＡＣ_ＬＥＮＧＴＨ_ＢＹＴＥ：この１２ビットフィールドは、ＥＡＣのバイト長を示す。
【０３２８】
ＥＡＣ_ＣＯＵＮＴＥＲ：この１２ビットフィールドは、ＥＡＣが到達するフレーム以前のフレームの数を示す。
【０３２９】
ＡＵＸ_ＦＬＡＧフィールドが“１”と同一である場合にのみ、次のフィールドが現れる。
【０３３０】
ＡＵＸ_ＰＲＩＶＡＴＥ_ＤＹＮ：この４８ビットフィールドは、補助ストリームをシグナリングするための未来使用のために予約される。このフィールドの意味は、構成可能なＰＬＳ２−ＳＴＡＴ内のＡＵＸ_ＳＴＲＥＡＭ_ＴＹＰＥの値に依存する。
【０３３１】
ＣＲＣ_３２：全ＰＬＳ２に適用される３２ビットの誤り検出コード。
【０３３２】
図１６は、本発明の実施例に係るフレームの論理構造を示す図である。
【０３３３】
上述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルは、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、まず、一つ以上のＦＳＳにマッピングされる。その後、もしあれば、ＥＡＣセルがＰＬＳフィールドの直後にマッピングされ、その後、もしあれば、ＦＩＣセルがマッピングされる。もしあれば、ＤＰは、ＰＬＳ又はＥＡＣ、ＦＩＣの後にマッピングされる。タイプ１  ＤＰが先に後続し、その後、タイプ２  ＤＰが後続する。ＤＰのタイプについての詳細は後述する。任意の場合、ＤＰは、ＥＡＳのための任意の特殊データ又はサービスシグナリングデータを伝達することができる。もしあれば、補助ストリーム又はストリームがＤＰに後続し、その後、ダミーセルが後続する。これらの全てを上述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーデータセルの順にマッピングすることは、フレーム内のセル容量を正確に満たす。
【０３３４】
図１７は、本発明の実施例に係るＰＬＳマッピングを示す図である。
【０３３５】
ＰＬＳセルは、ＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳによって占有されたセルの数に依存して、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数（ＮFSS）は、ＰＬＳ１内のＮＵＭ_ＦＳＳによってシグナリングされる。ＦＳＳは、ＰＬＳセルを伝達する特殊シンボルである。ロバスト性及びレイテンシ（ｌａｔｅｎｃｙ）は、ＰＬＳの重要な問題であるため、ＦＳＳは、ＦＳＳ内の周波数専用補間及び高速同期化を許容する、さらに高い密度のパイロットを有する。
【０３３６】
ＰＬＳセルは、図１７の例に示したように、トップ−ダウン（ｔｏｐ−ｄｏｗｎ）方式でＮFSS個のＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳ１セルは、セルインデックスの増加順に第１ＦＳＳの第１セルからまずマッピングされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後にマッピングされ、第１ＦＳＳの最後のセルインデックスまでマッピングが下向きに続けて行われる。要求されるＰＬＳセルの総数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは、次のＦＳＳに進行し、第１ＦＳＳと正確に同じ方式で続けて行われる。
【０３３７】
ＰＬＳマッピングが完了した後、ＤＰが次に伝達される。ＥＡＣ、ＦＩＣ、又はＥＡＣ及びＦＩＣが現フレームに存在すると、これらはＰＬＳと“正常”ＤＰとの間に配置される。
【０３３８】
図１８は、本発明の実施例に係るＥＡＣマッピングを示す図である。
【０３３９】
ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するＤＰにリンクされる。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。存在するなら、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＥＡＣが、ＰＬＳセル以外に、ＦＩＣ、ＤＰ、補助ストリーム又はダミーセルのいずれかの後に位置しない。ＥＡＣセルをマッピングする手順は、ＰＬＳと正確に同一である。
【０３４０】
ＥＡＣセルは、図１８に示されたように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＥＡＳメッセージのサイズに応じて、ＥＡＣセルは、図１８に示されたようにいくつかのシンボルを占有する。
【０３４１】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後にマッピングされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＥＡＣの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは、次のシンボルに進行し、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは、正常データシンボルであり、これは、ＦＳＳよりもさらに多いアクティブキャリアを有する。
【０３４２】
ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。（ＰＬＳ２フィールドでシグナリングされることによって）ＦＩＣが送信されないと、ＤＰは、ＥＡＣの最後のセルの直後にマッピングされる。
【０３４３】
図１９は、本発明の実施例に係るＦＩＣマッピングを示す図である。
【０３４４】
（ａ）は、ＥＡＣがないＦＩＣの例示的なマッピングを示し、（ｂ）は、ＥＡＣがあるＦＩＣの例示的なマッピングを示す。
【０３４５】
ＦＩＣは、高速サービス取得及びチャネルスキャニングを可能にする階層間（ｃｒｏｓｓ−ｌａｙｅｒ）情報に対する専用チャネルである。この情報は、主に、各ブロードキャスターのＤＰとサービスとの間の情報を結合するチャネルを含む。高速スキャンのために、受信機は、ＦＩＣをデコードし、ブロードキャスターＩＤ、サービスの数及びＢＡＳＥ_ＤＰ_ＩＤなどの情報を得ることができる。高速サービス取得のために、ＦＩＣに加え、ベースＤＰがＢＡＳＥ_ＤＰ_ＩＤを用いてデコードされ得る。伝達される内容以外に、ベースＤＰは、正常ＤＰと正確に同じ方式でエンコードされ、フレームにマッピングされる。したがって、ベースＤＰについてさらなる説明が要求されない。ＦＩＣデータが生成されて管理層で消費される。ＦＩＣデータの内容は、管理層の説明書に記載された通りである。
【０３４６】
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２の静的部分内のＦＩＣ_ＦＬＡＧパラメータによってシグナリングされる。ＦＩＣが使用されると、ＦＩＣ_ＦＬＡＧが“１”に設定され、ＦＩＣのためのシグナリングフィールドはＰＬＳ２の静的部分に定義される。このフィールドでは、ＦＩＣ_ＶＥＲＳＩＯＮ及びＦＩＣ_ＬＥＮＧＴＨ_ＢＹＴＥがシグナリングされる。ＦＩＣは、ＰＬＳ２と同じ変調、コーディング及び時間インターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２_ＭＯＤＥ及びＰＬＳ２_ＦＥＣなどの同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２、又は存在するなら、ＥＡＣの直後にマッピングされる。ＦＩＣは、任意の正常ＤＰ、補助ストリーム又はダミーセルの後にマッピングされない。ＦＩＣセルをマッピングする方法は、ＥＡＣと正確に同一であり、これはＰＬＳと同一である。
【０３４７】
ＰＬＳ後にＥＡＣがない場合、ＦＩＣセルは、（ａ）の例に示したように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＦＩＣデータサイズに応じて、ＦＩＣセルは、（ｂ）に示したように、いくつかのシンボルにわたってマッピングされてもよい。
【０３４８】
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後にマッピングされ、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに続けて行われる。要求されるＦＩＣセルの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは、次のシンボルに進行し、ＦＳＳと正確に同じ方式で続けて行われる。この場合のマッピングのための次のシンボルは、ＦＳＳよりさらに多いアクティブキャリアを有する正常データシンボルである。
【０３４９】
ＥＡＳメッセージが現フレームで送信されると、ＥＡＣはＦＩＣに先行し、ＦＩＣセルは、（ｂ）に示したように、セルインデックスの増加順にＥＡＣの次のセルからマッピングされる。
【０３５０】
ＦＩＣマッピングが完了した後、一つ以上のＤＰがマッピングされ、その後、存在するなら、補助ストリーム及びダミーセルがマッピングされる。
【０３５１】
図２０は、本発明の実施例に係るＤＰのタイプを示す図である。
【０３５２】
図２０の（ａ）はタイプ１  ＤＰを示し、（ｂ）はタイプ２  ＤＰを示す。
【０３５３】
先行チャネル、すなわち、ＰＬＳ、ＥＡＣ及びＦＩＣがマッピングされた後、ＤＰのセルがマッピングされる。ＤＰは、マッピング方法によって２つのタイプのいずれかに分類される。
【０３５４】
タイプ１  ＤＰ：ＤＰは、ＴＤＭによってマッピングされる。
【０３５５】
タイプ２  ＤＰ：ＤＰは、ＦＤＭによってマッピングされる。
【０３５６】
ＤＰのタイプは、ＰＬＳ２の静的部分でＤＰ_ＴＹＰＥフィールドによって指示される。図２０は、タイプ１  ＤＰ及びタイプ２  ＤＰのマッピング順序を示す。タイプ１  ＤＰは、まず、セルインデックスの増加順にマッピングされ、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、ＤＰは、ｐ＝０からセルインデックスの増加順に続けてマッピングされる。一つのフレームで共にマッピングされる多数のＤＰで、タイプ１  ＤＰのそれぞれは、ＤＰのＴＤＭマルチプレクシングと類似に、時間でグループ化される。
【０３５７】
タイプ２  ＤＰは、まず、シンボルインデックスの増加順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１の利用可能なシンボルに戻され、そのシンボルインデックスから増加する。一つのフレームで多数のＤＰを共にマッピングした後、タイプ２  ＤＰのそれぞれは、ＤＰのＦＤＭマルチプレクシングと類似に、周波数でグループ化される。
【０３５８】
一つの制限が必要であれば、すなわち、タイプ１  ＤＰが常にタイプ２  ＤＰに先行すると、タイプ１  ＤＰ及びタイプ２  ＤＰはフレーム内で共存することができる。タイプ１及びタイプ２  ＤＰを伝達するＯＦＤＭセルの総数は、ＤＰの送信のために利用可能なＯＦＤＭセルの総数を超えてはならない。
【０３５９】
【数２】
0006474835.tif 000030
【０３６０】
ここで、ＤDP1は、タイプ１  ＤＰによって占有されるＯＦＤＭセルの数であり、ＤDP2は、タイプ２  ＤＰによって占有されるＯＦＤＭセルの数である。ＰＬＳ、ＥＡＣ、ＦＩＣは、いずれも、タイプ１  ＤＰと同じ方式でマッピングされるため、これらはいずれも“タイプ１のマッピングルール”に従う。したがって、タイプ１のマッピングは、常にタイプ２のマッピングに先行する。
【０３６１】
図２１は、本発明の実施例に係るＤＰマッピングを示す図である。
【０３６２】
（ａ）は、タイプ１  ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）は、タイプ２  ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示す。
【０３６３】
タイプ１  ＤＰ（０，ＤDP1−１）をマッピングするためのＯＦＤＭセルのアドレッシングは、タイプ１  ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ１  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。
【０３６４】
ＥＡＣ及びＦＩＣなしに、アドレス０は、最後のＦＳＳ内のＰＬＳを伝達する最後のセルの直後のセルのことを指す。ＥＡＣが送信され、ＦＩＣが当該フレームにないと、アドレス０は、ＥＡＣを伝達する最後のセルの直後のセルのことを指す。ＦＩＣが当該フレームで送信されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後のセルのことを指す。タイプ１  ＤＰに対するアドレス０は、（ａ）に示されたように、２つの異なるケースを考慮して算出することができる。（ａ）に示された例において、ＰＬＳ、ＥＡＣ及びＦＩＣは全て送信されると仮定する。ＥＡＣ及びＦＩＣのいずれか１つ又は両方とも省略される場合への拡張は容易である。（ａ）の左側に示されたように、ＦＩＣまでの全てのセルをマッピングした後にＦＳＳ内に残っているセルがある場合。
【０３６５】
タイプ２  ＤＰ（０，…，ＤDP2−１）をマッピングするＯＦＤＭセルのアドレッシングは、タイプ２  ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ２  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。これはまた、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。
【０３６６】
（ｂ）に示されたように、３つの少し異なるケースが可能である。（ｂ）の左側上に示された第１のケースでは、最後のＦＳＳ内のセルは、タイプ２  ＤＰマッピングに用いられる。中間に示された第２のケースでは、ＦＩＣが正常シンボルのセルを占めるが、そのシンボル上のＦＩＣセルの数はＣFSSよりも小さい。（ｂ）の右側に示された第３のケースは、そのシンボル上にマッピングされたＦＩＣセルの数がＣFSSを超えるということを除いて、第２のケースと同一である。
【０３６７】
ＰＬＳ、ＥＡＣ及びＦＩＣは、タイプ１  ＤＰと同じ“タイプ１のマッピング規則”に従うため、タイプ１  ＤＰがタイプ２  ＤＰに先行する場合への拡張は簡単である。
【０３６８】
データパイプ単位（ＤＰＵ）は、データセルをフレーム内のＤＰに割り当てる基本単位である。
【０３６９】
ＤＰＵは、フレーム内にＤＰを位置させるシグナリング単位として定義される。セルマッパー７０１０は、ＤＰのそれぞれに対するＴＩによって生成されたセルをマッピングすることができる。時間インターリーバ５０５０は、一連のＴＩブロックを出力し、それぞれのＴＩブロックは、セルのセットで構成される可変数（ｖａｒｉａｂｌｅ  ｎｕｍｂｅｒ）のＸＦＥＣＢＬＯＣＫを含む。ＸＦＥＣＢＬＯＣＫ内のセルの数（Ｎcells）は、ＦＥＣＢＬＯＣＫサイズ（Ｎldpc）及びコンステレーションシンボル当たりの送信ビット数に依存する。ＤＰＵは、与えられたＰＨＹプロファイルでサポートされるＸＦＥＣＢＬＯＣＫ内のセルの数の全ての可能な値の最大公約数（ｇｒｅａｔｅｓｔ  ｃｏｍｍｏｎ  ｄｉｖｉｓｏｒ）（Ｎcells）として定義される。セル内のＤＰＵの長さは、ＬDPUと定義される。各ＰＨＹプロファイルがＦＥＣＢＬＯＣＫサイズ及びコンステレーションシンボル当たり異なる数の異なる組み合わせをサポートするため、ＬDPUは、ＰＨＹプロファイルに基づいて定義される。
【０３７０】
図２２は、本発明の実施例に係るＦＥＣ構造を示す図である。
【０３７１】
図２２は、ビットインターリービングの前の本発明の実施例に係るＦＥＣ構造を示す。上述したように、データＦＥＣエンコーダは、入力ＢＢＦに対してＦＥＣエンコーディングを行ってアウターコーディング（ＢＣＨ）及びインナーコーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに対応する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに対応する同一の値を有する。
【０３７２】
図２２に示されたように、ＢＣＨエンコーディングはそれぞれのＢＢＦ（Ｋbchビット）に適用され、ＬＤＰＣエンコーディングはＢＣＨエンコーディングＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０３７３】
Ｎldpcの値は、６４８００ビット（長いＦＥＣＢＬＯＣＫ）又は１６２００ビット（短いＦＥＣＢＬＯＣＫ）である。
【０３７４】
下記の表２８及び表２９は、それぞれ長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するＦＥＣエンコーディングパラメータを示す。
【０３７５】
【表２８】
0006474835.tif 000031
【０３７６】
【表２９】
0006474835.tif 000032
【０３７７】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの動作についての詳細は、次の通りである。
【０３７８】
１２誤り訂正ＢＣＨコードは、ＢＢＦのアウターエンコーディングに使用される。短いＦＥＣＢＬＯＣＫ及び長いＦＥＣＢＬＯＣＫに対するＢＣＨ生成器多項式は、全ての多項式を共に乗算することによって得られる。
【０３７９】
ＬＤＰＣコードは、アウターＢＣＨエンコーディングの出力をエンコードするのに使用される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）は、各Ｉldpc（ＢＣＨエンコーディングＢＢＦ）から体系的にエンコードされ、Ｉldpcに付加される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の数式で表現される。
【０３８０】
【数３】
0006474835.tif 000033
【０３８１】
長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するパラメータは、それぞれ前記表２８及び表２９に与えられる。
【０３８２】
長いＦＥＣＢＬＯＣＫに対するＮldpc−Ｋldpcを算出する細部手順は、次の通りである。
【０３８３】
１）パリティビット初期化
【０３８４】
【数４】
0006474835.tif 000034
【０３８５】
２）パリティチェックマトリクスのアドレスの第１行に特定されたパリティビットアドレスで第１情報ビット（ｉ0）を累算する。パリティチェックマトリクスのアドレスの細部事項は後述する。例えば、レート１３／１５に対して、
【０３８６】
【数５】
0006474835.tif 000035
【０３８７】
３）次の３５９個の情報ビット（ｉs）（ｓ＝１，２，…，３５９）が、次の式を用いてパリティビットで累算される。
【０３８８】
【数６】
0006474835.tif 000036
【０３８９】
ここで、ｘは、第１ビット（ｉ0）に対応するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティチェックマトリクスのアドレスで特定されたコードレート従属定数である。継続して、例えば、レート１３／１５に対して、Ｑldpc＝２４であり、したがって、情報ビット（ｉ1）に対して、次の動作が行われる。
【０３９０】
【数７】
0006474835.tif 000037
【０３９１】
４）３６１番目の情報ビット（ｉ360）に対して、パリティビット累算器のアドレスは、パリティチェックマトリクスのアドレスの第２行に与えられる。類似の方式で、次の３５８個の情報ビット（ｉs）（ｓ＝３６１，３６２，…，７１９）に対するパリティビット累算器のアドレスは、式６を用いて得られ、ここで、ｘは、情報ビット（ｉ360）に対応するパリティビット累算器のアドレス、パリティチェックマトリクスのアドレスの第２行内のエントリを示す。
【０３９２】
５）類似の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスのアドレスからの新しい行が、パリティビット累算器のアドレスを見つけるのに使用される。
【０３９３】
全ての情報ビットが使い尽くされた後、最終パリティが次のように得られる。
【０３９４】
６）ｉ＝１から始まる次の動作を順次行う。
【０３９５】
【数８】
0006474835.tif 000038
【０３９６】
ここで、ｐi（ｉ＝０，１，…，Ｎdpc−Ｋldpc−１）の最終内容は、パリティビット（ｐi）と同一である。
【０３９７】
【表３０】
0006474835.tif 000039
【０３９８】
短いＦＥＣＢＬＯＣＫに対するこのＬＤＰＣエンコーディング手順は、表３０及び表３１を代替し、長いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスを短いＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスに代える以外は、長いＦＥＣＢＬＯＣＫに対するｔ  ＬＤＰＣエンコーディング手順に従う。
【０３９９】
【表３１】
0006474835.tif 000040
【０４００】
図２３は、本発明の実施例に係るビットインターリービングを示す図である。
【０４０１】
ＬＤＰＣエンコーダの出力はビットインターリーブされ、これは、パリティインターリービング及びその後のＱＣＢ（ｑｕａｓｉ−ｃｙｃｌｉｃ  ｂｌｏｃｋ）インターリービング及び内部グループインターリービングで構成される。
【０４０２】
（ａ）は、ＱＣＢインターリービングを示し、（ｂ）は、内部グループインターリービングを示す。
【０４０３】
ＦＥＣＢＬＯＣＫは、パリティインターリーブされてもよい。パリティインターリービングの出力において、ＬＤＰＣコードワードは、長いＦＥＣＢＬＯＣＫ内の１８０個の隣接するＱＣブロック、及び短いＦＥＣＢＬＯＣＫ内の１８０個の隣接するＱＣブロックで構成される。長い又は短いＦＥＣＢＬＯＣＫ内のそれぞれのＱＣブロックは、３６０ビットで構成される。パリティインターリーブされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリーブされる。ＱＣＢインターリービングの単位はＱＣブロックである。パリティインターリービングの出力でのＱＣブロックは、図２３に示されたように、ＱＣＢインターリービングによってパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）され、ここで、ＦＥＣＢＬＯＣＫの長さに応じてＮcells＝６４８００／ηｍｏｄ又は１６２００／ηｍｏｄである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレートの各組み合わせに固有である。
【０４０４】
ＱＣＢインターリービング後、内部グループインターリービングは、下記の表３２に定義された変調タイプ及び順序（ηｍｏｄ）によって行われる。一つの内部グループに対するＱＣブロックの数（ＮQCB_IG）もまた定義される。
【０４０５】
【表３２】
0006474835.tif 000041
【０４０６】
内部グループインターリービングプロセスは、ＱＣＢインターリービング出力のＮ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）に分離され、それぞれのＴＩブロックは、時間インターリーバメモリの一つの用途に対応する。ＴＩグループ内のＴＩブロックは、少し異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。ＴＩグループが多数のＴＩブロックに分離されると、一つのフレームにのみ直接マッピングされる。下記の表３３に示すように（時間インターリービングをスキップする追加のオプションを除いて）時間インターリービングのための３つのオプションが存在する。
【０４２３】
【表３３】
0006474835.tif 000042
【０４２４】
各ＤＰにおいて、ＴＩメモリは、入力ＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックからの出力ＸＦＥＣＢＬＯＣＫ）を格納する。入力ＸＦＥＣＢＬＯＣＫは、
【数９】
0006474835.tif 000043
として定義され、
ここで、ｄn,s,r,qは、ｎ番目のＴＩグループのｓ番目のＴＩブロック内のｒ番目のＸＦＥＣＢＬＯＣＫのｑ番目のセルであり、次のようにＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
【０４２５】
【数１０】
0006474835.tif 000044
【０４２６】
また、時間インターリーバからの出力ＸＦＥＣＢＬＯＣＫは、次のように定義されると仮定する。
【０４２７】
【数１１】
0006474835.tif 000045
【０４２８】
一般に、時間インターリーバは、フレームビルディングプロセスの前にＤＰデータのためのバッファとして動作する。これは、それぞれのＤＰに対する２つのメモリバンクによって達成される。第１ＴＩブロックは第１バンクに書き込まれる。第１バンクが読み取られる間、第２ＴＩブロックが第２バンクに書き込まれる。
【０４２９】
ＴＩは、ツイスト行−列ブロックインターリーバである。ｎ番目のＴＩグループのｓ番目のＴＩブロックに対して、ＴＩメモリの行（Ｎr）の数は、セルの数（Ｎcell）と同一である、すなわち、Ｎr＝Ｎcellであるが、列の数（Ｎc）は、数（ＮxBLOCK_TI（ｎ，ｓ））と同一である。
【０４３０】
図２６は、本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。
【０４３１】
（ａ）は、時間インターリーバでの書き込み動作を示し、（ｂ）は、時間インターリーバでの読み取り動作を示す。（ａ）に示されたように、第１ＸＦＥＣＢＬＯＣＫは、ＴＩメモリの第１列に列方向に書き込まれ、第２ＸＦＥＣＢＬＯＣＫは、次の列に書き込まれる。その後、インターリービングアレイにおいて、セルは、対角線方向に読み取られる。第１行から（最左側列から始まって行に沿って右に）最後の行まで対角線方向の読み取りが行われる間、（ｂ）に示されたように、セルが読み取られる。具体的に、順次読み取られるＴＩメモリセルの位置として、Ｚn,s,i（ｉ＝０，...，Ｎr，Ｎc）を想定し、このようなインターリービングアレイでの読み取りプロセスは、次の式のように、行インデックス（Ｒn,s,i）、列インデックス（Ｃn,s,i）及び関連するツイストパラメータ（Ｔn,s,i）を算出することによって行われる。
【０４３２】
【数１２】
0006474835.tif 000046
【０４３３】
ここで、Ｓshiftは、ＮxBLOCK_TI（ｎ，ｓ）と関係なく対角線方向読み取りプロセスに対する共通シフト値であり、次の式のように、ＰＬＳ−ＳＴＡＴで与えられたＮxBLOCK_TI_MAXによって決定される。
【０４３４】
【数１３】
0006474835.tif 000047
【０４３５】
結果的に、読み取られるセルの位置は、Ｚ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のサイズに設定され、読み取りプロセスは、次の式で達成される。
【０４３９】
【数１４】
0006474835.tif 000048
【０４４０】
ＴＩグループの数は３に設定される。時間インターリーバのオプションは、ＤＰ_ＴＩ_ＴＹＰＥ＝“０”、ＤＰ_ＦＲＡＭＥ_ＩＮＴＥＲＶＡＬ＝“１”及びＤＰ_ＴＩ_ＬＥＮＧＴＨ＝“１”、すなわち、ＮTI＝１、ＩJUMP＝１及びＰ1＝１によってＰＬＳ２−ＳＴＡＴデータでシグナリングされる。ＴＩグループ当たりのそれぞれがＮcells＝３０を有するＸＦＥＣＢＬＯＣＫの数は、それぞれＮxBLOCK_TI（０，０）＝３、ＮxBLOCK_TI（１，０）＝６、ＮxBLOCK_TI（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮxBLOCK_Group_MAXによってＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは、次のことを誘導する。
【数１５】
0006474835.tif 000049
【０４４１】
図２８は、本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。
【０４４２】
特に、図２８は、ＮxBLOCK_TI_MAX＝７及びＳshift＝（７−１）／２＝３のパラメータを有する各インターリービングアレイからの対角線方向読み取りパターンを示す。前記擬似コードとして示された読み取りプロセスにおいて、Ｖi×ＮcellsＮxBLOCK_TI（ｎ，ｓ）であれば、Ｖiの値はスキップされ、Ｖiの次の算出値が使用される。
【０４４３】
図２９は、本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。
【０４４４】
図２９は、ＮxBLOCK_TI_MAX＝７及びＳshift＝３のパラメータを有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
【０４４５】
以下、本発明に関連する移動端末機について、図面を参照してより詳細に説明する。以下の説明で使用される構成要素に対する接尾辞「エンジン」、「モジュール」及び「部」は、明細書作成の容易さのみが考慮されて付与又は混用されるものであって、それ自体で互いに区別される意味又は役割を有するものではない。
【０４４６】
次は、図３０乃至図３８を参照して、本発明の一実施例に係るネットワークトポロジを説明する。
【０４４７】
図３０は、本発明の一実施例に係るネットワークトポロジを示すブロック図である。
【０４４８】
図３０に示したように、本発明の一実施例に係るネットワークトポロジは、コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、複数の付加サービス提供サーバー５０、放送受信装置６０、ネットワーク７０、映像表示装置１００を含む。
【０４４９】
コンテンツ提供サーバー１０は、放送局などに該当し得、メイン視聴覚コンテンツ（ｍａｉｎ  ａｕｄｉｏ−ｖｉｓｕａｌ  ｃｏｎｔｅｎｔ）を含む放送信号を放送する。放送信号は、付加サービスをさらに含むことができる。付加サービスは、メイン視聴覚コンテンツと関連があってもよく、関連がなくてもよい。付加サービスは、サービス情報（ｓｅｒｖｉｃｅ  ｉｎｆｏｒｍａｔｉｏｎ）、メタデータ（ｍｅｔａｄａｔａ）、付加データ、コンパイルされた実行ファイル、ウェブアプリケーション、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書、ＸＭＬ文書、ＣＳＳ（ｃａｓｃａｄｉｎｇ  ｓｔｙｌｅ  ｓｈｅｅｔ）文書、オーディオファイル、ビデオファイル、ＡＴＳＣ  ２．０コンテンツ、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）のようなアドレスなどの形態を有することができる。一つ以上のコンテンツ提供サーバーが存在してもよい。
【０４５０】
コンテンツ認識サービス提供サーバー２０は、映像表示装置１００がメイン視聴覚コンテンツに基づいてコンテンツを認識できるようにするコンテンツ認識サービスを提供する。コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに修正を加えてもよく、修正を加えなくてもよい。一つ以上のコンテンツ認識サービス提供サーバーが存在してもよい。
【０４５１】
コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）を挿入するウォーターマークサーバーであってもよい。このウォーターマークサーバーは、メイン視聴覚コンテンツの各フレームの左側上端又は右側上端にコンテンツ提供者のロゴをウォーターマークすることができる。
【０４５２】
また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにコンテンツ情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）として挿入するウォーターマークサーバーであってもよい。
【０４５３】
また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツの一部のフレーム又は一部のオーディオサンプルから特徴情報を抽出して格納するフィンガープリントサーバーであってもよい。この特徴情報は、シグネチャーとも呼ばれる。
【０４５４】
マルチチャネルビデオ分配サーバー３０は、複数の放送局から放送信号を受信し、多重化して、多重化された信号を放送受信装置６０に提供する。特に、マルチチャネルビデオ分配サーバー３０は、受信した放送信号に対して復調及びチャネル復号化を行ってメイン視聴覚コンテンツ及び付加サービスを抽出した後、抽出されたメイン視聴覚コンテンツ及び抽出した付加サービスに対してチャネル符号化を行い、分配のための多重化信号を生成することができる。このとき、マルチチャネルビデオ分配サーバー３０は、抽出した付加サービスを除外することもでき、他の付加サービスを追加することもできるため、放送局は、放送局主導のサービスを提供することができない。一つ以上のマルチチャネルビデオ分配サーバーが存在してもよい。
【０４５５】
放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信した信号に対して復調及びチャネル復号を行ってメイン視聴覚コンテンツを抽出する。そして、放送受信装置６０は、抽出したメイン視聴覚コンテンツをＨ．２６４／ＭＰＥＧ−４  ＡＶＣ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ−４  ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  ｃｏｄｉｎｇ）、Ｄｏｌｂｙ  ＡＣ−３、ＭＰＥＧ−２  ＡＡＣ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ−２  Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）アルゴリズムなどを用いて復号して、非圧縮メイン視聴覚コンテンツ（ｕｎｃｏｍｐｒｅｓｓｅｄ  ｍａｉｎ  ＡＶ  ｃｏｎｔｅｎｔ）を生成する。放送受信装置６０は、生成した非圧縮メイン視聴覚コンテンツを映像表示装置１００の外部入力ポートなどを介して映像表示装置１００に提供する。
【０４５６】
付加サービス情報提供サーバー４０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツと関連する１つ以上の利用可能な付加サービスのための付加サービス情報を提供する。１つ以上の付加サービスアドレス提供サーバーが存在してもよい。付加サービス情報提供サーバー４０は、複数の利用可能な付加サービスのうち最も優先順位が高い付加サービスのための付加サービス情報を提供することもできる。
【０４５７】
付加サービス提供サーバー５０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスを提供する。１つ以上の付加サービス提供サーバーが存在してもよい。
【０４５８】
映像表示装置１００は、テレビ、ノートパソコン、携帯電話、スマートフォンなどのようにディスプレイ部を含む装置であってもよい。映像表示装置１００は、放送受信装置６０から非圧縮メイン視聴覚コンテンツを受信することもでき、コンテンツ提供サーバー１０又はマルチチャネルビデオ分配サーバー３０から符号化されたメイン視聴覚コンテンツを含む放送信号を受信することもできる。映像表示装置１００は、ネットワーク７０を介してコンテンツ認識サービス提供サーバー２０からコンテンツ認識サービスを受信することができ、ネットワーク７０を介して付加サービス情報提供サーバー４０からメイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスのアドレスを受信することができ、付加サービス提供サーバー５０からメイン視聴覚コンテンツと関連して利用できる１つ以上の付加サービスを受信することができる。
【０４５９】
コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、及び複数の付加サービス提供サーバー５０のうち２つ以上は、一つのサーバーの形態で結合されてもよく、一つの事業者によって運営されてもよい。
【０４６０】
図３１は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。
【０４６１】
図３１に示したように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１をさらに含む。
【０４６２】
図３１に示されたようなウォーターマークサーバー２１は、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにコンテンツ情報を挿入する。マルチチャネルビデオ分配サーバー３０は、変形されたメイン視聴覚コンテンツを含む放送信号を受信して分配する。特に、ウォーターマークサーバーは、後述するようなデジタルウォーターマーキング技術を用いることができる。
【０４６３】
デジタルウォーターマークは、削除しにくい方法でデジタル信号に情報を挿入するプロセスである。例えば、デジタル信号は、オーディオ、写真、又はビデオであってもよい。このデジタル信号がコピーされると、挿入された情報もまたコピーに含まれる。一つのデジタル信号が、同時に異なる複数個のウォーターマークを運搬することができる。
【０４６４】
可視ウォーターマーキング（ｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋｉｎｇ）において、挿入される情報は、写真又はビデオで目で識別可能である。典型的に、挿入された情報は、メディアの所有者を識別するテキスト又はロゴである。テレビ放送局が自身のロゴを伝送されるビデオのコーナーに追加すると、これが、目で識別可能なウォーターマークである。
【０４６５】
不可視ウォーターマーキング（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋｉｎｇ）において、情報は、デジタルデータとしてオーディオ、写真、又はビデオに追加されるが、一定量の情報が隠されているという事実は感知できるとしても、そのような情報は認知することができない。このような目で識別不可能なウォーターマーキングを介して秘密メッセージが伝達されることもできる。
【０４６６】
ウォーターマーキングの一つの応用は、デジタルメディアの不法コピーを防止するための著作権保護システムにある。例えば、コピー装置は、デジタルメディアのコピーの前にデジタルメディアからウォーターマークを得、ウォーターマークの内容に基づいてコピーをするか否かを決定することができる。
【０４６７】
ウォーターマーキングの他の応用は、デジタルメディアの出処追跡にある。配布経路上の各地点でウォーターマークがデジタルメディアに埋め込まれる。後でこのようなデジタルメディアが発見される場合、このデジタルメディアからウォーターマークが抽出され、ウォーターマークの内容から配布の出処を把握することができる。
【０４６８】
デジタルメディアに対する説明が、不可視ウォーターマーキングの更に他の応用である。
【０４６９】
デジタルメディアのためのファイルフォーマットがメタデータと呼ばれる追加的な情報を含むことができ、デジタルウォーターマークは、デジタルメディアの視聴覚信号自体で伝達されるという点からメタデータとは区別される。
【０４７０】
ウォーターマーキング方法としては、スプレッドスペクトル、量子化、アンプリチュード変調がある。
【０４７１】
マーキングされる信号が追加的な修正によって得られる場合、ウォーターマーキング方法はスプレッドスペクトルに該当する。スプレッドスペクトルウォーターマークは、非常に強靭であると知られているが、ウォーターマークが埋め込まれるホスト信号に干渉を与えるため、多くの情報を含めることはできない。
【０４７２】
マーキングされる信号が量子化によって得られる場合、ウォーターマーキング方法は量子化タイプに該当する。量子化ウォーターマークは、強靭性は低いが、かなり多くの情報を含めることができる。
【０４７３】
マーキングされる信号が空間領域でスプレッドスペクトルと類似の追加修正方法で得られる場合、ウォーターマーキング方法はアンプリチュード変調に該当する。
【０４７４】
図３２は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。
【０４７５】
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ１０１）。
【０４７６】
ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加え、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）を挿入したり、又はメイン視聴覚コンテンツにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）として挿入し、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスをＭＶＰＤ３０に提供する（Ｓ１０３）。
【０４７７】
不可視ウォーターマークを介して挿入されるウォーターマーク情報は、ウォーターマークの用途、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。ウォーターマークの用途は、無断コピーの防止、視聴率の調査、付加サービスの取得のうち１つを示すことができる。
【０４７８】
コンテンツ情報は、メイン視聴覚コンテンツを提供するコンテンツ提供者の識別情報、メイン視聴覚コンテンツ識別情報、メイン視聴覚コンテンツ等級情報、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報、メイン視聴覚コンテンツが放送されるチャネルの名、メイン視聴覚コンテンツが放送されるチャネルのロゴ、メイン視聴覚コンテンツが放送されるチャネルの説明、利用情報報告アドレス、利用情報報告周期、利用情報取得のための最小利用時間、メイン視聴覚コンテンツと関連して利用可能な付加サービス情報のうち１つ以上を含むことができる。
【０４７９】
映像表示装置１００がコンテンツ情報の取得のためにウォーターマークを用いた場合、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、用いられたウォーターマークが内挿（ｅｍｂｅｄｄｉｎｇ）されたコンテンツ区間の時間情報であってもよい。映像表示装置１００がコンテンツ情報の取得のためにフィンガープリントを用いた場合、コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、特徴情報が抽出されたコンテンツ区間の時間情報であってもよい。コンテンツ情報の取得に使用されたコンテンツ区間の時間情報は、コンテンツ情報の取得に使用されたコンテンツ区間の開始時間、コンテンツ情報の取得に使用されたコンテンツ区間の持続時間（ｄｕｒａｔｉｏｎ）、コンテンツ情報の取得に使用されたコンテンツ区間の終了時間のうち１つ以上を含むことができる。
【０４８０】
利用情報報告アドレスは、メイン視聴覚コンテンツ視聴情報報告アドレス及び付加サービス利用情報報告アドレスのうち１つ以上を含むことができる。利用情報報告周期は、メイン視聴覚コンテンツ視聴情報報告周期及び付加サービス利用情報報告周期のうち１つ以上を含むことができる。利用情報の取得のための最小利用時間は、メイン視聴覚コンテンツ視聴情報の取得のための最小視聴時間及び付加サービス利用情報の抽出のための最小使用時間のうち１つ以上を含むことができる。
【０４８１】
メイン視聴覚コンテンツが最小視聴時間以上視聴された場合に基づいて、映像表示装置１００はメイン視聴覚コンテンツの視聴情報を取得し、メイン視聴覚コンテンツ視聴情報報告周期でメイン視聴覚コンテンツ視聴情報報告アドレスに抽出した視聴情報を報告することができる。
【０４８２】
付加サービスが最小使用時間以上使用された場合に基づいて、映像表示装置１００は付加サービス利用情報を取得し、付加サービス利用情報報告周期で付加サービス利用情報報告アドレスに抽出した利用情報を報告することができる。
【０４８３】
付加サービス情報は、付加サービスが存在するか否かに関する情報、付加サービスアドレス提供サーバーのアドレス、それぞれの利用可能な付加サービスの取得経路、それぞれの利用可能な付加サービスのためのアドレス、それぞれの利用可能な付加サービスの開始時間、それぞれの利用可能な付加サービスの終了時間、それぞれの利用可能な付加サービスの寿命（ｌｉｆｅｔｉｍｅ）、それぞれの利用可能な付加サービスの取得モード、それぞれの利用可能な付加サービスのための要求周期、それぞれの利用可能な付加サービスの優先順位情報、それぞれの利用可能な付加サービスの説明、それぞれの利用可能な付加サービスの項目（ｃａｔｅｇｏｒｙ）、利用情報報告アドレス、利用情報報告周期、利用情報取得のための最小利用時間のうち１つ以上を含むことができる。
【０４８４】
利用可能な付加サービスの取得経路は、ＩＰ又はＡＴＳＣ  Ｍ／Ｈ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）を示すことができる。利用可能な付加サービスの取得経路がＡＴＳＣ  Ｍ／Ｈである場合に、付加サービス情報は、周波数情報、チャネル情報をさらに含むことができる。それぞれの利用可能な付加サービスの取得モードは、Ｐｕｓｈ又はＰｕｌｌを示すことができる。
【０４８５】
一方、ウォーターマークサーバー２１は、メイン視聴覚コンテンツのロゴにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）として挿入することができる。
【０４８６】
例えば、ウォーターマークサーバー２１は、ロゴの一定の位置にバーコードを挿入することができる。このとき、ロゴの一定の位置は、ロゴがディスプレイされる区域の下端の１ラインに該当し得る。映像表示装置１００は、このようにバーコードが挿入されたロゴを含むメイン視聴覚コンテンツを受信する場合、バーコードをディスプレイしないこともできる。
【０４８７】
また、ウォーターマークサーバー２１は、ロゴのメタデータの形態でウォーターマーク情報を挿入することができる。このとき、ロゴの形状は維持され得る。
【０４８８】
また、ウォーターマークサーバー２１は、Ｍ個のフレームのロゴのそれぞれにＮビットのウォーターマーク情報を挿入することができる。すなわち、ウォーターマークサーバー２１は、Ｍ個のフレームを介してＭ＊Ｎ個のウォーターマーク情報を挿入することができる。
【０４８９】
ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ１０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。
【０４９０】
放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌ  ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ  ｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ１０６）。
【０４９１】
一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ１０７）。
【０４９２】
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む放送信号を伝送することもできる（Ｓ１０８）。
【０４９３】
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当すると、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーのアドレスとの対応関係から抽出したロゴに該当するウォーターマークサーバーのアドレスを確認する。ウォーターマーク情報がロゴに該当する場合に、映像表示装置１００は、ロゴのみではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも、映像表示装置１００はメイン視聴覚コンテンツを識別することができないが、ウォーターマーク情報がコンテンツ提供者識別情報やウォーターマークサーバーのアドレスを含むことができる。ウォーターマーク情報がコンテンツ提供者識別情報を含む場合に、映像表示装置１００は、複数のコンテンツ提供者識別情報と複数のウォーターマークサーバーのアドレスとの対応関係から抽出したコンテンツ提供者識別情報に該当するウォーターマークサーバーのアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報のみでメイン視聴覚コンテンツを識別することができない場合、取得したウォーターマークサーバーのアドレスに該当するウォーターマークサーバー２１に接続して第１質疑を伝送する（Ｓ１０９）。
【０４９４】
ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ１１１）。この第１応答は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。
【０４９５】
ウォーターマーク情報と第１応答が付加サービスアドレスを含んでいない場合、映像表示装置１００は付加サービスを取得することができない。しかし、ウォーターマーク情報と第１応答が付加サービスアドレス提供サーバーのアドレスを含むことができる。このように、映像表示装置１００は、ウォーターマーク情報と第１応答を介して付加サービスアドレスや付加サービスを取得することができず、付加サービスアドレス提供サーバーのアドレスを取得した場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ１１９）。
【０４９６】
付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ１２１）。
【０４９７】
映像表示装置１００は、ウォーターマーク情報、第１応答又は第２応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ１２３）、付加サービスを取得する（Ｓ１２５）。
【０４９８】
図３３は、本発明の一実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す。
【０４９９】
図３３に示したように、放送受信装置６０がターンオンされ、チャネルをチューニングし、映像表示装置１００が、外部入力ポート１１１を介して放送受信装置６０からチューニングされたチャネルのメイン視聴覚コンテンツを受信すると、映像表示装置１００は、メイン視聴覚コンテンツのウォーターマークからコンテンツ提供者識別子（又は放送局識別子）を感知することができる。その後、映像表示装置１００は、感知したコンテンツ提供者識別子に基づいてメイン視聴覚コンテンツのウォーターマークからコンテンツ情報を感知することができる。
【０５００】
このとき、図３３に示したように、コンテンツ提供者識別子の感知可能周期とコンテンツ情報の感知可能周期は異なり得る。特に、コンテンツ提供者識別子の感知可能周期は、コンテンツ情報の感知可能周期よりも短くてもよい。これによって、映像表示装置１００は、必要な情報のみを感知するための効率的な構成を有することができる。
【０５０１】
図３４は、本発明の一実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。
【０５０２】
図３４に示したように、本発明の一実施例に係るネットワークトポロジは、フィンガープリントサーバー２２をさらに含む。
【０５０３】
図３４に示されたようなフィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して格納する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子及び時間情報を提供する。
【０５０４】
図３５は、本発明の一実施例に係るフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。
【０５０５】
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ２０１）。
【０５０６】
フィンガープリントサーバー２２は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツの複数のフレーム区間又は複数のオーディオ区間から複数の特徴情報を抽出し、複数の特徴情報にそれぞれ対応する複数の質疑結果のためのデータベースを構築する（Ｓ２０３）。質疑の結果は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。
【０５０７】
ＭＶＰＤ３０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ２０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。
【０５０８】
放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌ  ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ  ｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ２０６）。
【０５０９】
一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ２０７）。
【０５１０】
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む信号を伝送することもできる。
【０５１１】
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ２１３）。
【０５１２】
映像表示装置１００は、予め設定されたフィンガープリントサーバーのアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送する（Ｓ２１５）。
【０５１３】
フィンガープリントサーバー２２は、第１質疑に対する第１応答として質疑結果を提供する（Ｓ２１７）。もし、第１応答が失敗に該当すれば、映像表示装置１００は、他のフィンガープリントサーバーのアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送することができる。
【０５１４】
フィンガープリントサーバー２２は、質疑結果としてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書を提供することができる。以下、質疑結果を含むＸＭＬ文書の例を説明する。
【０５１５】
図３６は、本発明の一実施例に係る質疑結果を含むＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキーマダイヤグラム（ｓｃｈｅｍａ  ｄｉａｇｒａｍ）を示す。
【０５１６】
図３６に示したように、質疑結果を含むＡＣＲ−Ｒｅｓｕｌｔｔｙｐｅは、ＲｅｓｕｌｔＣｏｄｅ属性とＣｏｎｔｅｎｔＩＤ、ＮＴＰＴｉｍｅｓｔａｍｐ、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎ、ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントを有する。
【０５１７】
例えば、ＲｅｓｕｌｔＣｏｄｅ属性が２００の値を有する場合、これは、質疑結果が成功であることを意味し得る。ＲｅｓｕｌｔＣｏｄｅ属性が４０４の値を有する場合、これは、質疑結果が失敗であることを意味し得る。
【０５１８】
ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎエレメントはＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントを有し、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントはＵｐｄａｔｅＭｏｄｅ及びＰｏｌｌｉｎｇＣｙｃｌｅ属性を有する。ＵｐｄａｔｅＭｏｄｅ属性はＰｕｌｌ値又はＰｕｓｈ値を有することができる。
【０５１９】
ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントは、ＳｅｒｖｉｃｅＮａｍｅ、ＳｅｒｖｉｃｅＬｏｇｏ、及びＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有する。
【０５２０】
次は、このような質疑結果を含むＡＣＲ−ＲｅｓｕｌｔＴｙｐｅのＸＭＬスキーマを示す。
【０５２１】
【表３４】
0006474835.tif 000050
【０５２２】
ＣｏｎｔｅｎｔＩＤエレメントとして、下記の表に示すようなＡＴＳＣコンテンツ識別子（ＡＴＳＣ  ｃｏｎｔｅｎｔ  ｉｄｅｎｔｉｆｉｅｒ）を用いることができる。
【０５２３】
【表３５】
0006474835.tif 000051
【０５２４】
前記表に示されたように、ＡＴＳＣ  ｃｏｎｔｅｎｔ  ｉｄｅｎｔｉｆｉｅｒは、ＴＳＩＤとハウス番号で構成された構造を有する。
【０５２５】
１６ビット符号なし整数ＴＳＩＤは、トランスポートストリーム識別子（ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ  ｉｄｅｎｔｉｆｉｅｒ）を含む（ｃａｒｒｙ）。
【０５２６】
５ビット符号なし整数ｅｎｄ_ｏｆ_ｄａｙは、放送が終了して、ｃｏｎｔｅｎｔ_ｉｄ値を再利用できる日の時（ｈｏｕｒ）にセットされる。
【０５２７】
９ビット符号なし整数ｕｎｉｑｕｅ_ｆｏｒは、ｃｏｎｔｅｎｔ_ｉｄ値を再利用できない日の数（ｔｈｅ  ｎｕｍｂｅｒ  ｏｆ  ｄａｙ）に設定される。
【０５２８】
ｃｏｎｔｅｎｔ_ｉｄはコンテンツ識別子を示す。映像表示装置１００は、毎日ｅｎｄ_ｏｆ_ｄａｙに該当する時間でｕｎｉｑｕｅ_ｆｏｒを１ずつ減少させ、ｕｎｉｑｕｅ_ｆｏｒが０になっていないと、ｃｏｎｔｅｎｔ_ｉｄが唯一であるものと見なすことができる。
【０５２９】
一方、ＣｏｎｔｅｎｔＩＤエレメントとして、後述するようなＡＴＳＣ−Ｍ／Ｈ  ｓｅｒｖｉｃｅのためのグローバルサービス識別子（Ｇｌｏｂａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）が用いられてもよい。
【０５３０】
グローバルサービス識別子は、次のようなフォームを有する。
【０５３１】
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄ＞：＜ｓｅｒｖｉｃｅｉｄ＞
【０５３２】
ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ  ６３９−２によって規定されるような２桁の文字からなる国際国コードである。ローカルサービス（ｌｏｃａｌ  ｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの１０進数であり、地域サービス（ｒｅｇｉｏｎａｌ  ｓｅｒｖｉｃｅ）（ｍａｊｏｒ＞６９）のための＜ｘｓｉｄ＞は“０”である。＜ｓｅｒｖｉｃｅｉｄ＞は、＜ｍａｊｏｒ＞や＜ｍｉｎｏｒ＞で定義される。＜ｍａｊｏｒ＞はメジャーチャネル番号（Ｍａｊｏｒ  Ｃｈａｎｎｅｌ  ｎｕｍｂｅｒ）を示し、＜ｍｉｎｏｒ＞はマイナーチャネル番号（Ｍｉｎｏｒ  Ｃｈａｎｎｅｌ  Ｎｕｍｂｅｒ）を示す。
【０５３３】
グローバルサービス識別子の例は、以下の通りである。
【０５３４】
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：１２３４：５．１
【０５３５】
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：０：１００．２００
【０５３６】
一方、ＣｏｎｔｅｎｔＩＤエレメントとして、後述するようなＡＴＳＣコンテンツ識別子を用いることができる。
【０５３７】
ＡＴＳＣコンテンツ識別子は、次のようなフォームを有する。
【０５３８】
ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｃｏｎｔｅｎｔ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄｚ＞：＜ｃｏｎｔｅｎｔｉｄ＞：＜ｕｎｉｑｕｅ_ｆｏｒ＞：＜ｅｎｄ_ｏｆ_ｄａｙ＞
【０５３９】
ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ  ６３９−２によって規定されるような２桁の文字からなる国際国コードである。ローカルサービス（ｌｏｃａｌ  ｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの１０進数であり、”．”＜ｓｅｒｖｉｃｅｉｄ＞が後続し得る。地域サービス（ｒｅｇｉｏｎａｌ  ｓｅｒｖｉｃｅ）（ｍａｊｏｒ＞６９）のための＜ｘｓｉｄ＞は＜ｓｅｒｖｉｃｅｉｄ＞である。＜ｃｏｎｔｅｎｔ_ｉｄ＞は、前記表に定義されているｃｏｎｔｅｎｔ_ｉｄ  ｆｉｅｌｄのｂａｓｅ６４符号であり、＜ｕｎｉｑｕｅ_ｆｏｒ＞は、前記表に定義されているｕｎｉｑｕｅ_ｆｏｒ  ｆｉｅｌｄの１０進数符号であり、＜ｅｎｄ_ｏｆ_ｄａｙ＞は、前記表に定義されているｅｎｄ_ｏｆ_ｄａｙ  ｆｉｅｌｄの１０進数符号である。
【０５４０】
以下では、再び図３５を説明する。
【０５４１】
質疑結果が、付加サービスアドレスや付加サービスを含んでおらず、付加サービスアドレス提供サーバーのアドレスを含む場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ２１９）。
【０５４２】
付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ２２１）。
【０５４３】
映像表示装置１００は、第１応答又は第２応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ２２３）、付加サービスを取得する（Ｓ２２５）。
【０５４４】
ＵｐｄａｔｅＭｏｄｅ属性がプル（Ｐｕｌｌ）値を有する場合、映像表示装置１００は、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬを介してＨＴＴＰ要求を付加サービス提供サーバー５０に伝送し、これに対する応答として、ＰＳＩＰバイナリストリームを含むＨＴＴＰ応答を付加サービス提供サーバー５０から受信する。この場合、映像表示装置１００は、ＰｏｌｌｉｎｇＣｙｃｌｅ属性として指定されるポーリング（Ｐｏｌｌｉｎｇ）周期に応じてＨＴＴＰ要求を伝送することができる。また、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントは、アップデート時間属性を有することもできる。この場合、映像表示装置１００は、アップデート時間属性として指定されるアップデート時間でＨＴＴＰ要求を伝送することができる。
【０５４５】
ＵｐｄａｔｅＭｏｄｅ属性がプッシュ（Ｐｕｓｈ）値を有する場合、映像表示装置１００は、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔ  ＡＰＩを活用して非同期的にサーバーからアップデートを受信することができる。映像表示装置１００がサーバーにＸＭＬＨＴＴＰＲｅｑｕｅｓｔオブジェクトを介して非同期的な要求をした後、サーバーが、シグナリング情報に変更がある場合に、このチャネルを介して応答としてシグナリング情報を提供する方案である。セッションの待機時間に制限がある場合には、セッションタイムアウト応答（ｓｅｓｓｉｏｎ  ｔｉｍｅｏｕｔ  ｒｅｓｐｏｎｄ）を発生させ、受信機は直ちにこれを認知して再要求することで、受信機とサーバーとの間のシグナリングチャネルを常に維持することができる。
【０５４６】
図３７は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。
【０５４７】
図３７に示したように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１とフィンガープリントサーバー２２をさらに含む。
【０５４８】
図３７に示されたようなウォーターマークサーバー２１は、メイン視聴覚コンテンツにコンテンツ提供者識別情報を挿入する。ウォーターマークサーバー２１は、ロゴのような可視ウォーターマークとしてコンテンツ提供者識別情報をメイン視聴覚コンテンツに挿入することもでき、不可視ウォーターマークとしてコンテンツ提供者識別情報をメイン視聴覚コンテンツに挿入することもできる。
【０５４９】
フィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して格納する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子と時間情報を提供する。
【０５５０】
図３８は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータの流れを示すラダーダイヤグラムである。
【０５５１】
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ３０１）。
【０５５２】
ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにロゴのような可視ウォーターマーク（ｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）を挿入したり、メイン視聴覚コンテンツにウォーターマーク情報を不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）として挿入したりし、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスをＭＶＰＤ３０に提供する（Ｓ３０３）。不可視ウォーターマークを介して挿入されるウォーターマーク情報は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、上述した通りである。
【０５５３】
ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ３０５）。このとき、多重化信号は、受信した付加サービスを排除するか、又は新しい付加サービスを含むことができる。
【０５５４】
放送受信装置６０は、ユーザが選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌ  ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ  ｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ３０６）。
【０５５５】
一方、コンテンツ提供サーバー１０もまた、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどを介して放送する（Ｓ３０７）。
【０５５６】
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに直接映像表示装置１００にメイン視聴覚コンテンツを含む信号を伝送することもできる（Ｓ３０８）。
【０５５７】
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。または、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを得ることができる。または、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調し、復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当する場合、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーのアドレスとの対応関係から抽出したロゴに該当するウォーターマークサーバーのアドレスを確認する。ウォーターマーク情報がロゴに該当する場合、映像表示装置１００は、ロゴのみではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも、映像表示装置１００はメイン視聴覚コンテンツを識別することができないが、ウォーターマーク情報がコンテンツ提供者識別情報やウォーターマークサーバーのアドレスを含むことができる。ウォーターマーク情報がコンテンツ提供者識別情報を含む場合、映像表示装置１００は、複数のコンテンツ提供者識別情報と複数のウォーターマークサーバーのアドレスとの対応関係から抽出したコンテンツ提供者識別情報に該当するウォーターマークサーバーのアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報のみでメイン視聴覚コンテンツを識別することができない場合、取得したウォーターマークサーバーのアドレスに該当するウォーターマークサーバー２１に接続して第１質疑を伝送する（Ｓ３０９）。
【０５５８】
ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ３１１）。この第１応答は、フィンガープリントサーバーのアドレス、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、上述した通りである。
【０５５９】
ウォーターマーク情報及び第１応答がフィンガープリントサーバーアドレスを含んでいる場合、映像表示装置１００は、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ３１３）。
【０５６０】
映像表示装置１００は、第１応答内のフィンガープリントサーバーアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第２質疑を伝送する（Ｓ３１５）。
【０５６１】
フィンガープリントサーバー２２は、第２質疑に対する第２応答として質疑結果を提供する（Ｓ３１７）。
【０５６２】
質疑結果が、付加サービスアドレスや付加サービスを含んでおらず、付加サービスアドレス提供サーバーのアドレスを含む場合、映像表示装置１００は、取得した付加サービスアドレス提供サーバーのアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第３質疑を伝送する（Ｓ３１９）。
【０５６３】
付加サービス情報提供サーバー４０は、第３質疑のコンテンツ情報と関連する１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第３質疑に対する第３応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ３２１）。
【０５６４】
映像表示装置１００は、第１応答、第２応答、又は第３応答を介して１つ以上の利用可能な付加サービスアドレスを取得した場合、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ３２３）、付加サービスを取得する（Ｓ３２５）。
【０５６５】
次は、図３９を参照して、本発明の実施例に係る映像表示装置１００を説明する。
【０５６６】
図３９は、本発明の実施例に係る映像表示装置のブロック図である。
【０５６７】
図３９に示されたように、本発明の実施例に係る映像表示装置１００は、放送信号受信部１０１、復調部１０３、チャネル復号部１０５、逆多重化部１０７、視聴覚復号部１０９、外部入力ポート１１１、再生制御部１１３、再生装置１２０、付加サービス管理部１３０、データ送受信部１４１、メモリ１５０を含む。
【０５６８】
放送信号受信部１０１は、コンテンツ提供サーバー１０又はＭＶＰＤ３０から放送信号を受信する。
【０５６９】
復調部１０３は、受信した放送信号を復調し、復調された信号を生成する。
【０５７０】
チャネル復号部１０５は、復調された信号をチャネル復号し、チャネル復号されたデータを生成する。
【０５７１】
逆多重化部１０７は、チャネル復号されたデータからメイン視聴覚コンテンツと付加サービスを分離する。分離された付加サービスは付加サービス格納部１５２に格納される。
【０５７２】
視聴覚復号部１０９は、分離されたメイン視聴覚コンテンツを視聴覚復号（ＡＶ  ｄｅｃｏｄｉｎｇ）して非圧縮メイン視聴覚コンテンツを生成する。
【０５７３】
一方、外部入力ポート１１１は、放送受信装置６０、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）プレーヤー、ブルーレイディスク（Ｂｌｕ−ｒａｙ  ｄｉｓｃ）プレーヤーなどから非圧縮メイン視聴覚コンテンツを受信する。外部入力ポート１１１は、ＤＳＵＢポート、ＨＤＭＩ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）ポート、ＤＶＩ（Ｄｉｇｉｔａｌ  Ｖｉｓｕａｌ  Ｉｎｔｅｒｆａｃｅ）ポート、コンポジット（ｃｏｍｐｏｓｉｔｅ）ポート、コンポーネント（ｃｏｍｐｏｎｅｎｔ）ポート、Ｓ−Ｖｉｄｅｏポートのうち１つ以上を含むことができる。
【０５７４】
再生制御部１１３は、視聴覚復号部１０９が生成する非圧縮メイン視聴覚コンテンツ、又は外部入力ポート１１１から受信した非圧縮メイン視聴覚コンテンツのうちの少なくとも１つをユーザ選択によって再生装置１２０に再生する。
【０５７５】
再生装置１２０はディスプレイ部１２１及びスピーカー１２３を含む。ディスプレイ部１２１は、液晶ディスプレイ（ｌｉｑｕｉｄ  ｃｒｙｓｔａｌ  ｄｉｓｐｌａｙ、ＬＣＤ）、薄膜トランジスタ液晶ディスプレイ（ｔｈｉｎ  ｆｉｌｍ  ｔｒａｎｓｉｓｔｏｒ−ｌｉｑｕｉｄ  ｃｒｙｓｔａｌ  ｄｉｓｐｌａｙ、ＴＦＴ  ＬＣＤ）、有機発光ダイオード（ｏｒｇａｎｉｃ  ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ  ｄｉｏｄｅ、ＯＬＥＤ）、フレキシブルディスプレイ（ｆｌｅｘｉｂｌｅ  ｄｉｓｐｌａｙ）、３次元ディスプレイ（３Ｄ  ｄｉｓｐｌａｙ）のうち少なくとも１つを含むことができる。
【０５７６】
付加サービス管理部１３０は、メイン視聴覚コンテンツのコンテンツ情報を取得し、取得されたコンテンツ情報に基づいて利用可能な付加サービスを取得する。特に、上述したように、付加サービス管理部１３０は、非圧縮メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルに基づいてメイン視聴覚コンテンツの識別情報を取得することができ、本明細書では、これを自動コンテンツ認識（ａｕｔｏｍａｔｉｃ  ｃｏｎｔｅｎｔｓ  ｒｅｃｏｇｎｉｔｉｏｎ、ＡＣＲ）と呼ぶこともある。
【０５７７】
データ送受信部１４１は、ＡＴＳＣ−Ｍ／Ｈ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）チャネル送受信部１４１ａ及びＩＰ送受信部１４１ｂを含むことができる。
【０５７８】
メモリ１５０は、フラッシュメモリタイプ（ｆｌａｓｈ  ｍｅｍｏｒｙ  ｔｙｐｅ）、ハードディスクタイプ（ｈａｒｄ  ｄｉｓｋ  ｔｙｐｅ）、マルチメディアカードマイクロタイプ（ｍｕｌｔｉｍｅｄｉａ  ｃａｒｄ  ｍｉｃｒｏ  ｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気メモリ、磁気ディスク、光ディスクのうち少なくとも１つのタイプの格納媒体を含むことができる。映像表示装置１００は、インターネット（ｉｎｔｅｒｎｅｔ）上で前記メモリ１５０の格納機能を行うウェブストレージ（ｗｅｂ  ｓｔｏｒａｇｅ）と関連して動作することもできる。
【０５７９】
メモリ１５０は、コンテンツ情報格納部１５１、付加サービス格納部１５２、ロゴ格納部１５３、設定情報格納部１５４、ブックマーク格納部１５５、ユーザ情報格納部１５６、利用情報格納部１５７を含むことができる。
【０５８０】
コンテンツ情報格納部１５１は、複数の特徴情報に対応する複数のコンテンツ情報を格納する。
【０５８１】
付加サービス格納部１５２は、複数の特徴情報に対応する複数の付加サービスを格納することもでき、複数のコンテンツ情報に対応する複数の付加サービスを格納することもできる。
【０５８２】
ロゴ格納部１５３は複数のロゴを格納する。また、ロゴ格納部は、この複数のロゴに対応するコンテンツ提供者識別子、又は複数のロゴに対応するウォーターマークサーバーのアドレスをさらに格納することもできる。
【０５８３】
設定情報格納部１５４はＡＣＲのための設定情報を格納する。
【０５８４】
ブックマーク格納部１５５はブックマークを格納する。
【０５８５】
ユーザ情報格納部１５６はユーザ情報を格納する。ユーザ情報は、１つ以上のサービスのための１つ以上のアカウント情報、地域情報、家族構成員情報、好みのジャンルの情報、映像表示装置情報、利用情報提供範囲のうち１つ以上を含むことができる。１つ以上のアカウント情報は、利用情報測定サーバーのためのアカウント情報、ツイッター（ｔｗｉｔｔｅｒ）、フェイスブック（ｆａｃｅｂｏｏｋ）のようなソーシャルネットワークサービス（ｓｏｃｉａｌ  ｎｅｔｗｏｒｋ  ｓｅｒｖｉｃｅ）のアカウント情報を含むことができる。地域情報は、アドレス情報及び郵便番号を含むことができる。家族構成員情報は、家族構成員の数、各構成員の年齢、各構成員の性別、各構成員の宗教、各構成員の職業などを含むことができる。好みのジャンルの情報は、スポーツ、映画、ドラマ、教育、ニュース、エンターテインメント、その他のジャンルのうち１つ以上に設定されてもよい。映像表示装置情報は、映像表示装置の種類、製造会社、ファームウェアのバージョン、解像度、モデル名、ＯＳ、ブラウザ、格納装置の有無、格納装置の容量、ネットワークの速度に関する情報を含むことができる。利用情報提供範囲が設定されると、映像表示装置１００は、設定された範囲内でメイン視聴覚コンテンツ視聴情報と付加サービス利用情報を収集し、報告することができる。利用情報提供範囲は、仮想チャネルのそれぞれに対して設定されてもよい。また、利用情報測定許容範囲は、物理チャネル全体に対して設定されてもよい。
【０５８６】
利用情報格納部１５７は、映像表示装置１００によって収集されるメイン視聴覚コンテンツ視聴情報及び付加サービス使用情報を格納する。また、映像表示装置１００は、収集したメイン視聴覚コンテンツ視聴情報及び収集した付加サービス使用情報に基づいてサービス利用パターンを分析し、分析されたサービス利用パターンを利用情報格納部１５７に格納することができる。
【０５８７】
付加サービス管理部１３０は、フィンガープリントサーバー２２又はコンテンツ情報格納部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。コンテンツ情報格納部１５１に、抽出した特徴情報に該当するコンテンツ情報がないか、又は十分なコンテンツ情報がない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加のコンテンツ情報を受信することができる。また、付加サービス管理部１３０は、持続的にコンテンツ情報をアップデートすることができる。
【０５８８】
付加サービス管理部１３０は、付加サービス提供サーバー５０又は付加サービス格納部１５２から利用可能な付加サービスを取得することができる。付加サービス格納部１５２に付加サービスがないか、又は十分な付加サービスがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して付加サービスをアップデートすることができる。また、付加サービス管理部１３０は、持続的に付加サービスをアップデートすることができる。
【０５８９】
付加サービス管理部１３０は、メイン視聴覚コンテンツからロゴを抽出し、ロゴ格納部１５３に問い合わせて抽出したロゴに対応するコンテンツ提供者識別子、又はウォーターマークサーバーのアドレスを取得することができる。ロゴ格納部１５３に、抽出したロゴと一致するロゴがないか、又は十分なロゴがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加のロゴを受信することができる。また、付加サービス管理部１３０は、持続的にロゴをアップデートすることができる。
【０５９０】
付加サービス管理部１３０は、メイン視聴覚コンテンツから抽出したロゴとロゴ格納部１５３内の複数のロゴとの比較を行っており、演算の負担を低減するための様々な方法で行うことができる。
【０５９１】
例えば、付加サービス管理部１３０は、色相特性に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴの色相特性と、ロゴ格納部１５３内のロゴの色相特性とを比較し、一致するか否かを判断することができる。
【０５９２】
また、付加サービス管理部１３０は、文字認識に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴから認識される文字と、ロゴ格納部１５３内のロゴから認識される文字とを比較し、一致するか否かを判断することができる。
【０５９３】
それだけでなく、付加サービス管理部１３０は、ロゴの輪郭に対する形状に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴの輪郭形状と、ロゴ格納部１５３内のロゴの輪郭形状とを比較し、一致するか否かを判断することができる。
【０５９４】
次は、図４０及び図４１を参照して、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を説明する。
【０５９５】
図４０は、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示すフローチャートである。
【０５９６】
付加サービス情報は、付加サービスの開始時間を含むことができる。このとき、映像表示装置１００は、この開始時間に付加サービスを開始する必要がある。しかし、映像表示装置１００は、タイムスタンプを有しない非圧縮メイン視聴覚コンテンツを伝送する信号を受信するため、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とは異なる。映像表示装置１００が時間情報を有するメイン視聴覚コンテンツを受信しても、再放送などのように、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とは異なり得る。したがって、映像表示装置１００は、メイン視聴覚コンテンツの基準時間と付加サービスの基準時間とを同期化する必要がある。特に、映像表示装置１００は、メイン視聴覚コンテンツの再生時間と付加サービスの開始時間とを同期化する必要がある。
【０５９７】
まず、付加サービス管理部１３０は、メイン視聴覚コンテンツの一部の区間を抽出する（Ｓ８０１）。メイン視聴覚コンテンツの一部の区間は、メイン視聴覚コンテンツの一部のビデオフレーム及び一部のオーディオ区間のうち１つ以上を含むことができる。付加サービス管理部１３０がメイン視聴覚コンテンツの一部の区間を抽出した時間をＴｎという。
【０５９８】
付加サービス管理部１３０は、抽出された区間に基づいてメイン視聴覚コンテンツのコンテンツ情報を取得する（Ｓ８０３）。具体的には、付加サービス管理部１３０は、抽出された区間に不可視ウォーターマーク（ｉｎｖｉｓｉｂｌｅ  ｗａｔｅｒｍａｒｋ）として符号化された情報を復号し、コンテンツ情報を取得することができる。また、付加サービス管理部１３０は、抽出された区間の特徴情報を抽出し、抽出された特徴情報に基づいてフィンガープリントサーバー２２又はコンテンツ情報格納部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。付加サービス管理部１３０がコンテンツ情報を取得した時間をＴｍという。
【０５９９】
一方、コンテンツ情報は、抽出された区間の開始時間（Ｔｓ）を含む。付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）以降からは、時間（Ｔｓ）、時間（Ｔｍ）、時間（Ｔｎ）に基づいてメイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化する（Ｓ８０５）。具体的には、付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）を、新たに計算される時間（Ｔｐ）と見なす。ここで、Ｔｐ＝Ｔｓ＋（Ｔｍ−Ｔｎ）とすることができる。
【０６００】
そして、付加サービス管理部１３０は、コンテンツ情報取得時間から時間（Ｔｘ）が経過した時間を、Ｔｐ＋Ｔｘと見なすことができる。
【０６０１】
その後、付加サービス管理部１３０は、取得したコンテンツ情報に基づいて付加サービス及び付加サービスの開始時間（Ｔａ）を取得する（Ｓ８０７）。
【０６０２】
メイン視聴覚コンテンツの同期化された再生時間が付加サービスの開始時間（Ｔａ）と一致すると、付加サービス管理部１３０は、取得した付加サービスを開始する（Ｓ８０９）。具体的には、付加サービス管理部１３０は、Ｔｐ＋Ｔｘ＝Ｔａを満足する場合に付加サービスを開始することができる。
【０６０３】
図４１は、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示す概念図である。
【０６０４】
図４１に示されたように、映像表示装置１００は、システム時間（Ｔｎ）で視聴覚サンプルを抽出する。
【０６０５】
映像表示装置１００は、抽出した視聴覚サンプルから特徴情報を抽出し、フィンガープリントサーバー２２に、抽出した特徴情報を含む質疑を伝送し、質疑結果を受信する。映像表示装置１００は、質疑結果をパースし、抽出した視聴覚サンプルの開始時間（Ｔｓ）が１１０００ｍｓに該当することを時間（Ｔｍ）で確認する。
【０６０６】
したがって、映像表示装置は、抽出した視聴覚サンプルの開始時間を確認した時点をＴｓ＋（Ｔｍ−Ｔｎ）と見なし、以降から、メイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化することができる。
【０６０７】
次は、図４２及び図４３を参照して、本発明の様々な実施例に係る映像表示装置の構造について説明する。
【０６０８】
図４２は、本発明の更に他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。
【０６０９】
図４２において、チューナ５０１は、エアチャネルを介して伝送される８−ＶＳＢ  ＲＦ信号からシンボルを抽出する。
【０６１０】
８−ＶＳＢ復調器５０３は、チューナ５０１が抽出した８−ＶＳＢシンボルを復調し、意味のあるデジタルデータを復元する。
【０６１１】
ＶＳＢデコーダ５０５は、８−ＶＳＢ復調器５０３が復元したデジタルデータを復号し、ＡＴＳＣメインサービスとＡＴＳＣ  Ｍ／Ｈサービスを復元する。
【０６１２】
ＭＰＥＧ−２  ＴＰ逆多重化部５０７は、８−ＶＳＢ信号を介して伝送されるＭＰＥＧ−２トランスポートパケット又はＰＶＲ格納装置に格納されたＭＰＥＧ−２トランスポートパケットのうち映像表示装置１００が処理しようとするトランスポートパケットをフィルタリングし、適切な処理モジュールに中継する。
【０６１３】
ＰＥＳデコーダ５３９は、ＭＰＥＧ−２トランスポートストリームを介して伝送されたパケット化されたエレメンタリストリーム（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）をバッファリングし、復元する。
【０６１４】
ＰＳＩ／ＰＳＩＰデコーダ５４１は、ＭＰＥＧ−２トランスポートストリームを介して伝送されるＰＳＩ／ＰＳＩＰセクションデータをバッファリングし、分析する。分析されたＰＳＩ／ＰＳＩＰデータはサービスマネジャー（図示せず）によって収集され、サービスマップ及びガイドデータの形態でＤＢに格納される。
【０６１５】
ＤＳＭＣＣセクションバッファ／ハンドラ５１１は、ＭＰＥＧ−２  ＴＰを介して伝送されるファイル伝送及びＩＰデータグラムカプセル化などのためのＤＳＭＣＣセクションデータをバッファリング（Ｂｕｆｆｅｒｉｎｇ）し、処理する。
【０６１６】
ＩＰ／ＵＤＰデータグラムバッファ／ヘッダーパーサー５１３は、ＤＳＭＣＣアドレッサブルセクションを介してカプセル化されてＭＰＥＧ−２  ＴＰを介して伝送されるＩＰデータグラムをバッファリングし、復元して、各データグラムのヘッダーを分析する。また、ＩＰ／ＵＤＰデータグラムバッファ／ヘッダーパーサー５１３は、ＩＰデータグラムを介して伝送されるＵＤＰデータグラムをバッファリング及び復元し、復元されたＵＤＰヘッダーを分析及び処理する。
【０６１７】
ストリームコンポーネントハンドラ５５７は、ＥＳバッファ／ハンドラ、ＰＣＲハンドラ、ＳＴＣモジュール、デスクランブラ、ＣＡストリームバッファ／ハンドラ、サービスシグナリングセクションバッファ／ハンドラを含むことができる。
【０６１８】
ＥＳバッファ／ハンドラは、ＰＥＳ形態で伝送されたビデオ、オーディオデータなどのエレメンタリストリームをバッファリング及び復元し、適切なＡ／Ｖデコーダに伝達する。
【０６１９】
ＰＣＲハンドラは、オーディオ及びビデオストリームの時間同期化などのために使用されるＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）データを処理する。
【０６２０】
ＳＴＣモジュールは、ＰＣＲハンドラを介して伝達された基準クロック値を用いて、Ａ／Ｖデコーダのクロック値を補正して時間同期化を行う。
【０６２１】
受信されたＩＰデータグラムのペイロードにスクランブリングが適用された場合、デスクランブラは、ＣＡストリームハンドラから伝達された暗号化キーなどを用いて、ペイロードのデータを復元する。
【０６２２】
ＣＡストリームバッファ／ハンドラは、ＭＰＥＧ−２  ＴＳ又はＩＰストリームを介して伝送される制限受信（Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ）機能のために伝送されるＥＭＭ、ＥＣＭなどのデスクランブリングのためのキー値などのデータをバッファリング及び処理する。ＣＡストリームバッファ／ハンドラの出力はデスクランブラに伝達され、デスクランブラは、Ａ／Ｖデータ及びファイルデータなどを伝送するＭＰＥＧ−２  ＴＰ又はＩＰデータグラムの暗号化解除作業を行う。
【０６２３】
サービスシグナリングセクションバッファ／ハンドラは、ＩＰデータグラムの形態で伝送されるＮＲＴサービスシグナリングチャネルセクションデータをバッファリングし、復元し、分析する。サービスマネジャー（図示せず）は、分析されたＮＲＴサービスシグナリングチャネルセクションデータを収集し、サービスマップ及びガイドデータの形態でＤＢに格納する。
【０６２４】
Ａ／Ｖデコーダ５６１は、ＥＳハンドラを介して伝達されたオーディオ／ビデオデータの圧縮を復号化し、ユーザに提示する。
【０６２５】
ＭＰＥＧ−２サービス逆多重化部（図示せず）は、ＭＰＥＧ−２  ＴＰバッファ／パーサー、デスクランブラ、ＰＶＲ格納モジュールを含むことができる。
【０６２６】
ＭＰＥＧ−２  ＴＰバッファ／パーサー（図示せず）は、８−ＶＳＢ信号を介して伝送されるＭＰＥＧ−２トランスポートパケットをバッファリング及び復元し、トランスポートパケットヘッダーを検出及び処理する。
【０６２７】
デスクランブラは、ＭＰＥＧ−２  ＴＰのうち、スクランブルが適用されたパケットペイロードに対して、ＣＡストリームハンドラから伝達された暗号化キーなどを用いて、ペイロードのデータを復元する。
【０６２８】
ＰＶＲ格納モジュールは、ユーザの要求などに応じて、８−ＶＳＢ信号を用いて受信されたＭＰＥＧ−２  ＴＰを格納し、また、ユーザの要求によってＭＰＥＧ−２  ＴＰを出力する。ＰＶＲ格納モジュールはＰＶＲマネジャー（図示せず）によって制御されてもよい。
【０６２９】
ファイルハンドラ５５１は、ＡＬＣ／ＬＣＴバッファ／パーサー、ＦＤＴハンドラ、ＸＭＬパーサー、ファイル再構成バッファ、圧縮解除器、ファイルデコーダ、ファイル格納部を含むことができる。
【０６３０】
ＡＬＣ／ＬＣＴバッファ／パーサーは、ＵＤＰ／ＩＰストリームで伝送されるＡＬＣ／ＬＣＴデータをバッファリング及び復元し、ＡＬＣ／ＬＣＴのヘッダー及びヘッダー拡張部を分析する。ＡＬＣ／ＬＣＴバッファ／パーサーはＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。
【０６３１】
ＦＤＴハンドラは、ＡＬＣ／ＬＣＴセッションを介して伝送されるＦＬＵＴＥプロトコルのファイル記述テーブル（Ｆｉｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｔａｂｌｅ）を分析及び処理する。ＦＤＴハンドラはＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。
【０６３２】
ＸＭＬパーサーは、ＡＬＣ／ＬＣＴセッションを介して伝送されるＸＭＬ文書を分析し、ＦＤＴハンドラ、ＳＧハンドラなどの適切なモジュールに分析されたデータを伝達する。
【０６３３】
ファイル再構成バッファは、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを介して伝送されるファイルを復元する。
【０６３４】
圧縮解除器は、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを介して伝送されるファイルが圧縮されている場合、その圧縮を解除するプロセスを行う。
【０６３５】
ファイルデコーダは、ファイル再構成バッファで復元されたファイル、圧縮解除器で圧縮解除されたファイル、又はファイル格納部で抽出されたファイルをデコードする。
【０６３６】
ファイル格納部は、復元されたファイルを、必要に応じて格納又は抽出する。
【０６３７】
Ｍ／Ｗエンジン（図示せず）は、ＤＳＭＣＣセクション、ＩＰデータグラムなどを介して伝送されるＡ／Ｖストリームではないファイルなどのデータを処理する。Ｍ／Ｗエンジンは、処理されたデータをプレゼンテーションマネジャーモジュールに伝達する。
【０６３８】
ＳＧハンドラ（図示せず）は、ＸＭＬ文書の形態で伝送されるサービスガイドデータを収集し、分析してＥＰＧマネジャーに伝達するプロセスを行う。
【０６３９】
サービスマネジャー（図示せず）は、ＭＰＥＧ−２トランスポートストリームを介して伝送されるＰＳＩ／ＰＳＩＰデータ、ＩＰストリームで伝送されるサービスシグナリングセクションデータを収集し、分析してサービスマップを作製する。サービスマネジャー（図示せず）は、作製したサービスマップをサービスマップ＆ガイドデータベースに格納し、ユーザが望むサービスに対するアクセスを制御する。動作制御器（図示せず）によって制御され、チューナ５０１、ＭＰＥＧ−２  ＴＰ逆多重化部５０７、ＩＰデータグラムバッファ／ハンドラ５１３などに対する制御を行う。
【０６４０】
ＮＲＴサービスマネジャー（図示せず）は、ＩＰ層上でＦＬＵＴＥセッションを介してオブジェクト／ファイルの形態で伝送されるＮＲＴサービスに関する全般的な管理を行う。ＮＲＴサービスマネジャー（図示せず）は、ＦＤＴハンドラ、ファイル格納部などを制御することができる。
【０６４１】
アプリケーションマネジャー（図示せず）は、オブジェクト、ファイルなどの形態で伝送されるアプリケーションデータの処理に関する全般的な管理を行う。
【０６４２】
ＵＩマネジャー（図示せず）は、ユーザインターフェースを介してユーザの入力を動作制御器に伝達し、ユーザが要求するサービスのためのプロセスの動作を開始する。
【０６４３】
動作制御器（図示せず）は、ＵＩマネジャーを介して伝達されたユーザの命令を処理し、必要とするモジュールのマネジャーが当該アクションを行うようにする。
【０６４４】
フィンガープリント抽出器５６５は、オーディオ／ビデオストリームからフィンガープリント特徴情報を抽出する。
【０６４５】
フィンガープリント比較器５６７は、フィンガープリント抽出器が抽出した特徴情報と基準フィンガープリントとを比較し、一致するコンテンツを見つける。フィンガープリント比較器５６７は、ローカルに格納された基準フィンガープリントＤＢを用いることもでき、インターネット上のフィンガープリント質疑サーバーに問い合わせて結果を受信することもできる。比較結果で得られるマッチングされた結果データはアプリケーションに伝達されて用いられてもよい。
【０６４６】
アプリケーション５６９は、ＡＣＲ機能を管理するモジュールあるいはＡＣＲに基づいて付加サービスを提供するアプリケーションモジュールであって、視聴中の放送コンテンツを識別し、これと関連付けられた拡張されたサービスを提供する。
【０６４７】
図４３は、本発明の更に他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。
【０６４８】
図４３に示されたウォーターマークベースの映像表示装置は、図４２に示されたフィンガープリントベースの映像表示装置と類似しているが、フィンガープリントベースの映像表示装置のフィンガープリント抽出器５６５とフィンガープリント比較器５６７を含まず、その代わりにウォーターマーク抽出器５６６をさらに含む。
【０６４９】
ウォーターマーク抽出器５６６は、オーディオ／ビデオストリームから、ウォーターマークの形態で挿入されたデータを抽出する。このように抽出されたデータはアプリケーションに伝達されて利用されてもよい。
【０６５０】
図４４は、本発明の一実施例によってウォーターマーキング方式を介して伝達され得るデータを示すダイヤグラムである。
【０６５１】
上述したように、ＷＭを介したＡＣＲの目的は、圧縮不可能なオーディオ／ビデオのみをアクセスできる環境（すなわち、オーディオ／ビデオがケーブル／衛星／ＩＰＴＶなどから受信された環境）で圧縮不可能なオーディオ／ビデオからコンテンツの付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）サービス関連情報を得ることである。このような環境はＡＣＲ環境と呼ぶことができる。ＡＣＲ環境において、受信機が圧縮不可能なオーディオ／ビデオデータのみを受信するため、受信機は、どのコンテンツが現在ディスプレイされているかを確認することができない。したがって、受信機は、コンテンツソースＩＤ、放送プログラムの現在の時点、及びＷＭによって伝達される関連するアプリケーションのＵＲＬ情報を用いて、ディスプレイされるコンテンツを確認し、インタラクティブサービスを提供する。
【０６５２】
オーディオ／ビデオウォーターマーク（ＷＭ）を用いて放送プログラムと関連する付加サービスを伝達するにおいて、全ての付加情報は、最も簡単な方法として、ＷＭによって伝達されてもよい。この場合、全ての付加情報は、ＷＭ検出器によって検出され、受信機によって検出された情報を同時に処理することができる。
【０６５３】
しかし、この場合、オーディオ／ビデオデータに挿入されたＷＭの量が増加すると、オーディオ／ビデオの全体の品質が劣化することがある。このような理由から、最小の必要データのみをＷＭに挿入することができる。受信機がＷＭとして最小のデータを挿入しながら、さらに多くの量の情報を受信し、処理するようにするＷＭデータの構造が定義される必要がある。ＷＭに使用されるデータの構造は、データの量による影響が比較的少ないフィンガープリンティング方式でも同一に使用することができる。
【０６５４】
図示のように、本発明の一実施例によってウォーターマーキング方式で伝達されたデータは、コンテンツソースのＩＤ、タイムスタンプ、インタラクティブアプリケーションＵＲＬ、タイムスタンプタイプ、ＵＲＬプロトコルタイプ、アプリケーションイベント、目的地タイプなどを含むことができる。また、様々なタイプのデータは、本発明によってＷＭ方式により伝達されてもよい。
【０６５５】
本発明は、ＡＣＲがＷＭ方式によって行われる場合、ＷＭに含まれるデータの構造を提案する。図示されたデータタイプに対して、最も効率的な構造が本発明によって提案される。
【０６５６】
本発明の一実施例によってウォーターマーキング方式を介して伝達可能なデータは、コンテンツソースのＩＤを含む。セットトップボックスを用いる環境において、ＭＶＰＤ（ｍｕｌｔｉｃｈａｎｎｅｌ  ｖｉｄｅｏ  ｐｒｏｇｒａｍｍｉｎｇ  ｄｉｓｔｒｉｂｕｔｏｒ）がセットトップボックスを介してプログラム関連情報を伝達しない場合、受信機（端末又はＴＶ）は、プログラム名、チャネル情報などをチェックすることができない。したがって、特定のコンテンツソースを識別する固有のＩＤが必要であり得る。本発明において、コンテンツソースのＩＤのタイプは制限されない。コンテンツソースのＩＤの例は、次の通りである。
【０６５７】
まず、グローバルチャネルＩＤは、それぞれの放送プログラムを識別するグローバル識別子であってもよい。このＩＤは、コンテンツ提供者によって直接生成されたり、権威のある団体によって特定されたフォーマットで生成されてもよい。ＩＤの例は、北アメリカの“ＴＭＳメタデータ”のＴＭＳＩｄ、映画／放送プログラム識別子であるＥＩＤＲ  ＩＤなどを含むことができる。
【０６５８】
グローバルチャネルＩＤは、全てのチャネルを識別するチャネル識別子であってもよい。チャネル番号は、セットトップボックスによって提供されるＭＶＰＤ毎に異なる。また、同一のＭＶＰＤにおいても、チャネル番号は、ユーザによって指定されたサービスに応じて異なり得る。グローバルチャネルＩＤは、ＭＶＰＤなどによって影響を受けないグローバル識別子として使用されてもよい。実施例によれば、地上波を介して送信されるチャネルは、メジャーチャネル番号及びマイナーチャネル番号によって識別されてもよい。プログラムＩＤのみが使用される場合、複数個の放送局が同じプログラムを放送するときに問題が発生し得るため、グローバルチャネルＩＤは、特定の放送チャネルを特定するのに使用することができる。
【０６５９】
ＷＭに挿入されるコンテンツソースのＩＤの例は、プログラムＩＤ及びチャネルＩＤを含むことができる。プログラムＩＤ及びチャネルＩＤのうち１つ、又は両方とも、又は２つのＩＤを結合することによって得られた新しいＩＤがＷＭに挿入されてもよい。実施例によって、それぞれのＩＤ又は結合されたＩＤがハッシュ（ｈａｓｈ）されてデータの量を減少させることができる。それぞれのコンテンツソースのＩＤは、ストリングタイプ又は整数タイプであってもよい。整数タイプの場合、送信されたデータの量がさらに減少し得る。
【０６６０】
また、本発明の一実施例によってウォーターマーキングを介して伝達可能なデータは、タイムスタンプを含むことができる。受信機は、現在視聴しているコンテンツの時点を知らなければならない。この時間関連情報はタイムスタンプと呼ぶことができ、ＷＭに挿入され得る。この時間関連情報は、絶対時間（ＵＴＣ、ＧＰＳなど）又はメディア時間の形態を取ることができる。時間関連情報は、正確性のためにミリ秒の単位まで伝達されてもよく、実施例によってさらに小さい単位まで伝達されてもよい。タイムスタンプは、タイムスタンプのタイプ情報によって可変長を有することができる。
【０６６１】
一実施例によってウォーターマーキング方式を介して伝達可能なデータは、インタラクティブアプリケーションのＵＲＬを含むことができる。現在視聴している放送プログラムに関連するインタラクティブアプリケーションが存在すると、アプリケーションのＵＲＬがＷＭに挿入され得る。受信機が、ＷＭを検出し、ＵＲＬを得、ブラウザを介してアプリケーションを実行することができる。
【０６６２】
図４５は、本発明の一実施例によってタイムスタンプタイプフィールドの値の意味を示すダイヤグラムである。
【０６６３】
本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、タイムスタンプタイプフィールドを提案する。また、本発明は、タイムスタンプタイプフィールドの効率的なデータ構造を提案する。
【０６６４】
タイムスタンプタイプフィールドには５ビットが割り当てられてもよい。タイムスタンプの最初の２つのビットは、タイムスタンプのサイズを意味し、次の３ビットは、タイムスタンプによって指示された時間情報の単位を意味し得る。ここで、最初の２ビットはタイムスタンプサイズフィールドと呼び、次の３ビットはタイムスタンプ単位フィールドと呼ぶことができる。
【０６６５】
図示のように、タイムスタンプのサイズ及びタイムスタンプの単位値に応じて、可変的な量の実際のタイムスタンプ情報がＷＭに挿入されてもよい。このような可変性を用いて、設計者は、タイムスタンプの正確度に応じて、タイムスタンプに割り当てられたサイズ及びその単位を選択することができる。タイムスタンプの正確度が増加すると、正確な時間にインタラクティブサービスを提供することができる。しかし、タイムスタンプの正確度が増加するに伴い、システムの複雑度が増加する。このようなトレードオフ（ｔｒａｄｅｏｆｆ）を考慮して、タイムスタンプに割り当てられたサイズ及びその単位が選択され得る。
【０６６６】
タイムスタンプタイプフィールドの最初の２つのビットが００であると、タイムスタンプは１バイトのサイズを有することができる。タイムスタンプタイプフィールドの最初の２つのビットが０１，１０，１１であると、タイムスタンプのサイズは、それぞれ２，４，８バイトであってもよい。
【０６６７】
タイムスタンプタイプフィールドの最後の３ビットが０００であると、タイムスタンプはミリ秒の単位を有することができる。タイムスタンプタイプフィールドの最後の３ビットが００１，０１０，０１１であると、タイムスタンプは、秒、分及び時単位であってもよい。１０１〜１１１のタイムスタンプタイプフィールドの最後の３ビットは、未来のために予備として残してもよい。
【０６６８】
ここで、タイムスタンプタイプフィールドの最後の３ビットが１００であると、ミリ秒又は秒などの特定の時間単位の代わりに別途のタイムコードが単位として使用されてもよい。例えば、タイムコードは、ＳＭＰＴＥのタイムコードであるＨＨ：ＭＭ：ＳＳ：ＦＦの形態でＷＭに挿入されてもよい。ここで、ＨＨは時間単位であり、ＭＭは分単位であり、ＳＳは秒単位であってもよい。ＦＦはフレーム情報であってもよい。時間単位ではないフレーム情報は、同時に伝達されてフレーム正確サービス（ｆｒａｍｅ−ａｃｃｕｒａｔｅ  ｓｅｒｖｉｃｅ）を提供することができる。実際のタイムスタンプは、ＷＭに挿入されるために、コロンを排除したＨＨＭＭＳＳＦＦの形態を有することができる。この場合、タイムスタンプサイズ値は１１（８バイト）を有することができ、タイムスタンプ単位値は１００であってもよい。可変単位の場合、タイムスタンプが挿入される方法は、本発明によって制限されない。
【０６６９】
例えば、タイムスタンプタイプ情報が１０の値を有し、タイムスタンプ単位情報が０００の値を有する場合、タイムスタンプのサイズは４ビットであり、タイムスタンプの単位はミリ秒であってもよい。このとき、タイムスタンプがＴｓ＝３２６５０８７であると、タイムスタンプの後に位置する３つの数字０８７はミリ秒の単位を意味し得、残りの数字３２６５は秒単位を意味し得る。したがって、このタイムスタンプが解釈されるとき、現在の時間は、ＷＭが挿入されたプログラムを開始した後、５４分２５．０８７秒が経過したことを意味し得る。これは、例示に過ぎないものであり、タイムスタンプは、壁時間（ｗａｌｌ  ｔｉｍｅ）として機能することができ、コンテンツに関係なく、セグメント又は受信機の時間を示すことができる。
【０６７０】
図４６は、本発明の一実施例によってＵＲＬプロトコルタイプフィールドの値の意味を示すダイヤグラムである。
【０６７１】
本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、ＵＲＬプロトコルタイプフィールドを提案する。また、本発明は、ＵＲＬプロトコルタイプフィールドの効率的なデータ構造を提案する。
【０６７２】
上述した情報のうち、ＵＲＬの長さは一般的に長いため、挿入されるデータの量は比較的大きい。上述したように、ＷＭに挿入されるデータの量が減少するに伴い、効率が増加する。したがって、ＵＲＬの固定部分が受信機によって処理され得る。したがって、本発明は、ＵＲＬプロトコルタイプフィールドを提案する。
【０６７３】
ＵＲＬプロトコルタイプフィールドは３ビットのサイズを有することができる。サービス提供者は、ＵＲＬプロトコルタイプフィールドを用いてＷＭ内のＵＲＬプロトコルを設定することができる。この場合、インタラクティブアプリケーションのＵＲＬは、ドメインから挿入され、ＷＭに送信され得る。
【０６７４】
受信機のＷＭ検出器は、まず、ＵＲＬプロトコルタイプフィールドをパースし、ＵＲＬプロトコル情報を得、その後、送信されたＵＲＬ値にプロトコルをプレフィックス（ｐｒｅｆｉｘ）して、全体のＵＲＬを生成することができる。受信機は、ブラウザを介して完了したＵＲＬをアクセスし、インタラクティブアプリケーションを実行することができる。
【０６７５】
ここで、ＵＲＬプロトコルタイプフィールドの値が０００であると、ＵＲＬプロトコルは、直接指定されてＷＭのＵＲＬフィールドに挿入されてもよい。ＵＲＬプロトコルタイプフィールドの値が００１，０１０，０１１であると、ＵＲＬプロトコルは、それぞれｈｔｔｐ：／／、ｈｔｔｐｓ：／／、ｗｓ：／／であってもよい。１００〜１１１のＵＲＬプロトコルタイプフィールドの値は、未来使用のために予備として残してもよい。
【０６７６】
アプリケーションＵＲＬは、（ウェブアプリケーションの形態で）ブラウザを介してアプリケーションの実行を可能にすることができる。また、実施例によって、コンテンツソースＩＤ及びタイムスタンプ情報が参照されなければならない。後者の場合、コンテンツソースＩＤ情報及びタイムスタンプ情報を遠隔サーバーに伝達するために、最終ＵＲＬは、次の形態で表すことができる。
【０６７７】
Ｒｅｑｕｅｓｔ  ＵＲＬ：
【０６７８】
この実施例において、コンテンツソースＩＤは１２３４５６であり、タイムスタンプは５００５であってもよい。ｃｉｄは、遠隔サーバーに報告されるコンテンツソースＩＤの質疑識別子を意味し得る。ｔは、遠隔サーバーに報告される現在の時間の質疑識別子を意味し得る。
【０６７９】
図４７は、本発明の一実施例によってＵＲＬプロトコルタイプフィールドを処理するプロセスを示すフローチャートである。
【０６８０】
まず、サービス提供者４７０１０は、ＷＭ挿入器４７０２０にコンテンツを伝達することができる（ｓ４７０１０）。ここで、サービス提供者４７０１０は、上述したコンテンツ提供サーバーと類似の機能を行うことができる。ＷＭ挿入器４７０２０は、伝達されたコンテンツをＷＭに挿入することができる（ｓ４７０２０）。ここで、ＷＭ挿入器４７０２０は、上述したウォーターマークサーバーと類似の機能を行うことができる。ＷＭ挿入器４７０２０は、ＷＭアルゴリズムによって、上述したＷＭをオーディオ又はビデオに挿入することができる。ここで、挿入されたＷＭは、上述したアプリケーションＵＲＬ情報、コンテンツソースＩＤ情報などを含むことができる。例えば、挿入されたＷＭは、上述したタイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤなどを含むことができる。上述したプロトコルタイプフィールドは００１の値を有し、ＵＲＬ情報はａｔｓｃ．ｏｒｇの値を有することができる。ＷＭに挿入されたフィールドの値は例示的なものに過ぎず、本発明はこの実施例に制限されない。
【０６８１】
ＷＭ挿入器４７０２０は、ＷＭが挿入されたコンテンツを送信することができる（ｓ４７０３０）。ＷＭが挿入されたコンテンツの送信は、サービス提供者４７０１０によって行われる。
【０６８２】
ＳＴＢ４７０３０は、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータ（又はロー（ｒａｗ）Ａ／Ｖデータ）を出力することができる（ｓ４７０４０）。ここで、ＳＴＢ４７０３０は、上述した放送受信装置又はセットトップボックスを意味し得る。ＳＴＢ４７０３０は、受信機の内部又は外部に装着されてもよい。
【０６８３】
ＷＭ検出器４７０４０は、受信された圧縮不可能なＡ／Ｖデータから、挿入されたＷＭを検出することができる。ＷＭ検出器４７０４０は、ＷＭ挿入器４７０２０によって挿入されたＷＭを検出し、検出されたＷＭをＷＭマネジャーに伝達することができる。
【０６８４】
ＷＭマネジャー４７０５０は、検出されたＷＭをパースすることができる（ｓ４７０６０）。上述した実施例において、ＷＭは、００１のＵＲＬプロトコルタイプフィールドの値及びａｔｓｃ．ｏｒｇのＵＲＬ値を有することができる。ＵＲＬプロトコルタイプフィールドの値が００１であると、これは、ｈｔｔｐ：／／プロトコルが使用されることを意味し得る。ＷＭマネジャー４７０５０は、この情報を用いてｈｔｔｐ：／／及びａｔｓｃ．ｏｒｇを結合し、全体のＵＲＬを生成することができる（ｓ４７０７０）。
【０６８５】
ＷＭマネジャー４７０５０は、完了したＵＲＬをブラウザ４７０６０に伝送してアプリケーションを開始する(launch)ことができる（ｓ４７０８０）。場合によって、コンテンツソースＩＤ情報及びタイムスタンプ情報もまた伝達されなければならない場合、アプリケーションは、ｈｔｔｐ：／／ａｔｓｃ．ｏｒｇ？ｃｉｄ＝ＸＸＸ＆ｔ＝ＹＹＹの形態で開始されてもよい。
【０６８６】
端末のＷＭ検出器４７０４０及びＷＭマネジャー４７０５０が結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ４５０５０、ｓ４７０６０、ｓ４７０７０が一つのモジュールで処理されてもよい。
【０６８７】
図４８は、本発明の一実施例によってイベントフィールドの値の意味を示すダイヤグラムである。
【０６８８】
本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、イベントフィールドを提案する。また、本発明は、イベントフィールドの効率的なデータ構造を提案する。
【０６８９】
アプリケーションは、ＷＭから抽出されたＵＲＬを介して開始されてもよい。アプリケーションは、さらに細部的なイベントを介して制御されてもよい。アプリケーションを制御できるイベントは、イベントフィールドによって指示され、伝達されてもよい。すなわち、現在視聴している放送プログラムに関連するインタラクティブアプリケーションが存在すると、アプリケーションのＵＲＬが送信され、アプリケーションがイベントを介して制御され得る。
【０６９０】
イベントフィールドは３ビットのサイズを有することができる。イベントフィールドの値が０００であると、これは、“準備（Ｐｒｅｐａｒｅ）”命令を示すことができる。準備は、アプリケーションを実行する前の準備段階である。この命令を受信した受信機は、事前にアプリケーションに関連するコンテンツ項目をダウンロードすることができる。また、受信機は、アプリケーションを実行するために必要なリソースを解除（ｒｅｌｅａｓｅ）することができる。ここで、必要なリソースを解除することは、メモリを整理したり、他の終了していないアプリケーションを終了することを意味し得る。
【０６９１】
イベントフィールドの値が００１であると、これは、“実行（Ｅｘｅｃｕｔｅ）”命令を示すことができる。実行は、アプリケーションを実行する命令であってもよい。イベントフィールドの値が０１０であると、これは、“中断（Ｓｕｓｐｅｎｄ）”命令を示すことができる。中断は、実行されたアプリケーションを中断することを意味する。イベントフィールドの値が０１１であると、これは、“キル（Ｋｉｌｌ）”命令を示すことができる。キルは、既に実行されたアプリケーションを終了する命令であってもよい。１００〜１１１のイベントフィールドの値は、未来使用のために予備として残してもよい。
【０６９２】
図４９は、本発明の一実施例によって目的地タイプフィールドの値の意味を示す図である。
【０６９３】
本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、目的地タイプフィールドを提案する。また、本発明は、目的地タイプフィールドの効率的なデータ構造を提案する。
【０６９４】
ＤＴＶ関連技術の発展により、放送コンテンツに関連する付加サービスが、ＴＶ受信機のスクリーンだけでなくコンパニオン装置によって提供され得る。しかし、コンパニオン装置は、放送プログラムを受信することができないか、または放送プログラムを受信するが、ＷＭを検出することができない。したがって、現在放送されているコンテンツに関連する付加サービスを提供するアプリケーションのうち、コンパニオン装置によって実行されるアプリケーションが存在すると、その関連情報がコンパニオン装置に伝達されなければならない。
【０６９５】
このとき、受信機及びコンパニオン装置が連動する環境でも、ＷＭから検出されたアプリケーション又はデータがどの装置によって消費されるかを知る必要がある。すなわち、アプリケーション又はデータが受信機又はコンパニオン装置によって消費されるか否かに関する情報が必要である。ＷＭのような情報を伝達するために、本発明は、目的地タイプフィールドを提案する。
【０６９６】
目的地タイプフィールドは３ビットのサイズを有することができる。目的地タイプフィールドの値が０ｘ００であると、これは、ＷＭによって検出されたアプリケーション又はデータが全ての装置をターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０１であると、これは、ＷＭによって検出されたアプリケーション又はデータがＴＶ受信機をターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０２であると、これは、ＷＭによって検出されたアプリケーション又はデータがスマートフォンをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０３であると、これは、ＷＭによって検出されたアプリケーション又はデータがタブレットをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０４であると、これは、ＷＭによって検出されたアプリケーション又はデータがパーソナルコンピュータをターゲットとすることを意味する。目的地タイプフィールドの値が０ｘ０５であると、これは、ＷＭによって検出されたアプリケーション又はデータが遠隔サーバーをターゲットとすることを意味する。０ｘ０６〜０ｘＦＦの目的地タイプフィールドの値は、未来使用のために予備として残してもよい。
【０６９７】
ここで、遠隔サーバーは、放送プログラムに関連する全ての付加情報を有するサーバーを意味し得る。この遠隔サーバーは端末の外に位置し得る。遠隔サーバーが用いられる場合、ＷＭに挿入されたＵＲＬは、特定のアプリケーションのＵＲＬを示すものではなく、遠隔サーバーのＵＲＬを示すことができる。受信機は、遠隔サーバーのＵＲＬを介して遠隔サーバーと通信し、放送プログラムと関連する付加情報を受信することができる。このとき、受信された付加情報は、関連するアプリケーションのＵＲＬだけでなく、現在放送されているプログラムのジャンル、俳優情報、シノプシスなどの様々な情報であってもよい。受信された情報は、システムに応じて異なり得る。
【０６９８】
他の実施例によれば、目的地タイプフィールドのそれぞれのビットは、それぞれの装置に割り当てられてアプリケーションの目的地を示すことができる。この場合、複数個の目的地がビットワイズ（ｂｉｔｗｉｓｅ）ＯＲを介して同時に指定されてもよい。
【０６９９】
例えば、０ｘ０１がＴＶ受信機を示し、０ｘ０２がスマートフォンを示し、０ｘ０４がタブレットを示し、０ｘ０８がＰＣを示し、０ｘ１０が遠隔サーバーを示すとき、目的地タイプフィールドが０ｘ６の値を有すると、アプリケーション又はデータはスマートフォンとタブレットをターゲットとすることができる。
【０７００】
上述したＷＭマネジャーによってパースされたＷＭの目的地タイプフィールドの値によれば、ＷＭマネジャーは、それぞれのアプリケーション又はデータをコンパニオン装置に伝達することができる。この場合、ＷＭマネジャーは、受信機内のコンパニオン装置との連動を処理するモジュールであり、それぞれのアプリケーション又はデータと関連する情報を伝達することができる。
【０７０１】
図５０は、本発明の実施例＃１によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７０２】
本実施例において、ＷＭに挿入されるデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、目的地タイプフィールド、ＵＲＬプロトコルタイプフィールド及びＵＲＬなどの情報を有することができる。ここで、実施例によって、データの順序は変更されてもよく、それぞれのデータが省略されてもよい。
【０７０３】
本実施例において、タイムスタンプタイプフィールドのタイムスタンプサイズフィールドは０１の値を有し、タイムスタンプ単位フィールドは０００の値を有することができる。これは、タイムスタンプに２ビットが割り当てられ、タイムスタンプがミリ秒の単位を有することを意味する。
【０７０４】
また、イベントフィールドは００１の値を有し、これは、アプリケーションが直ちに実行されなければならないことを意味する。目的地タイプフィールドは０ｘ０２の値を有し、これは、ＷＭによって伝達されたデータがスマートフォンに伝達されなければならないことを意味する。ＵＲＬプロトコルタイプフィールドが００１の値を有し、ＵＲＬがａｔｓｃ．ｏｒｇの値を有するため、これは、付加情報又はアプリケーションのＵＲＬがｈｔｔｐ：／／ａｔｓｃ．ｏｒｇであることを意味し得る。
【０７０５】
図５１は、本発明の実施例＃１によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【０７０６】
サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５１０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭに挿入するステップ（ｓ５１０２０）、ＷＭ挿入器が、ＷＭが挿入されたコンテンツを送信するステップ（ｓ５１０３０）、ＳＴＢが、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５１０４０）、ＷＭ検出器がＷＭを検出するステップ（ｓ５１０５０）、ＷＭマネジャーが、検出されたＷＭをパースするステップ（ｓ５１０６０）、及び／又はＷＭマネジャーが全体のＵＲＬを生成するステップ（ｓ５１０７０）は、上述したステップと同一であってもよい。
【０７０７】
ＷＭマネジャーは、パースされたＷＭの目的地タイプフィールドに従って受信機内のコンパニオン装置プロトコルモジュールであり、関連するデータを伝達することができる（ｓ５１０８０）。コンパニオン装置プロトコルモジュールは、受信機内のコンパニオン装置の連動及び通信を管理することができる。コンパニオン装置プロトコルモジュールはコンパニオン装置とペアリングされてもよい。実施例によって、コンパニオン装置プロトコルモジュールはＵＰｎＰ装置であってもよい。実施例によって、コンパニオン装置プロトコルモジュールは端末の外に位置してもよい。
【０７０８】
コンパニオン装置プロトコルモジュールは、目的地タイプフィールドに従って関連するデータをコンパニオン装置に伝達することができる（ｓ５１０９０）。実施例＃１において、目的地タイプフィールドの値は０ｘ０２であり、ＷＭに挿入されたデータはスマートフォンに対するデータであり得る。したがって、コンパニオン装置プロトコルモジュールは、パースされたデータをスマートフォンに伝送することができる。すなわち、この実施例において、コンパニオン装置はスマートフォンであってもよい。
【０７０９】
実施例によって、ＷＭマネジャー又は装置プロトコルモジュールは、コンパニオン装置にデータを伝達する前にデータ処理手順を行うことができる。コンパニオン装置は携帯性を有することができるが、その代わりに、劣悪な処理／コンピューティング能力及び小さい量のメモリを有し得る。したがって、受信機は、コンパニオン装置の代わりにデータを処理し、処理されたデータをコンパニオン装置に伝達することができる。
【０７１０】
このような処理は、様々な実施例として実現されてもよい。まず、ＷＭマネジャー又はコンパニオン装置プロトコルモジュールは、コンパニオン装置によって要求されたデータのみを選択することができる。また、実施例によって、イベントフィールドが、アプリケーションが完了したことを示す情報を含む場合、アプリケーション関連情報が伝達されなくてもよい。また、データが複数個のＷＭを介して分けられて伝送される場合、データは格納され、結合され得、その後、最終情報がコンパニオン装置に伝達されてもよい。
【０７１１】
受信機は、コンパニオン装置の代わりに、タイムスタンプを用いて同期化を行い、同期化されたアプリケーションと関連する命令を伝達するか、または既に同期化されたインタラクティブサービスをコンパニオン装置に伝達し、コンパニオン装置はディスプレイのみを行うことができる。タイムスタンプ関連情報が伝達されず、タイムベース（ｔｉｍｅ  ｂａｓｅ）がただ受信機に維持され得、所定のイベントが活性化されると、関連情報がコンパニオン装置に伝達され得る。この場合、コンパニオン装置は、タイムベースを維持せず、関連情報が受信される時間に応じてイベントを活性化することができる。
【０７１２】
前記説明と同様に、端末のＷＭ検出器及びＷＭマネジャーが結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ５１０５０、ｓ５１０６０、ｓ５１０７０、ｓ５１０８０が一つのモジュールで行われてもよい。
【０７１３】
また、実施例によって、コンパニオン装置はまたＷＭ検出器を有することができる。それぞれのコンパニオン装置が、ＷＭが挿入された放送プログラムを受信すると、それぞれのコンパニオン装置は、ＷＭを直接検出した後、ＷＭを他のコンパニオン装置に伝達することができる。例えば、スマートフォンがＷＭを検出及びパースし、関連情報をＴＶに伝達することができる。この場合、目的地タイプフィールドは０ｘ０１の値を有することができる。
【０７１４】
図５２は、本発明の実施例＃２によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７１５】
本実施例において、ＷＭに挿入されたデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、目的地タイプフィールド、ＵＲＬプロトコルタイプフィールド及びＵＲＬなどの情報を有することができる。ここで、実施例によって、データの順序は変更されてもよく、それぞれのデータが省略されてもよい。
【０７１６】
本実施例において、タイムスタンプタイプフィールドのタイムスタンプサイズフィールドは０１の値を有することができ、タイムスタンプ単位フィールドは０００の値を有することができる。これは、タイムスタンプに２ビットが割り当てられ、タイムスタンプがミリ秒の単位を有することを意味する。コンテンツＩＤは１２３４５６の値を有することができる。
【０７１７】
また、イベントフィールドは００１の値を有し、これは、アプリケーションが直ちに実行されなければならないことを意味する。目的地タイプフィールドは０ｘ０５の値を有し、これは、ＷＭによって伝達されたデータが遠隔サーバーに伝達されなければならないことを意味する。ＵＲＬプロトコルタイプフィールドが００１の値を有し、ＵＲＬがｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍの値を有するため、これは、付加情報又はアプリケーションのＵＲＬがｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍであることを意味し得る。
【０７１８】
上述したように、遠隔サーバーが用いられる場合、放送プログラムの付加情報は遠隔サーバーから受信され得る。このとき、コンテンツＩＤ及びタイムスタンプがパラメータとして遠隔サーバーのＵＲＬに挿入されて、遠隔サーバーに要求され得る。実施例によって、遠隔サーバーは、ＡＰＩのサポートを通じて、現在放送されているプログラムに関する情報を得ることができる。このとき、ＡＰＩは、遠隔サーバーが受信機に格納されたコンテンツＩＤ及びタイムスタンプを取得するようにしたり、関連する付加情報を伝達するようにすることができる。
【０７１９】
本実施例において、コンテンツＩＤ及びスタンプがパラメータとして遠隔サーバーのＵＲＬに挿入される場合、全体のＵＲＬは、ｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍ？ｃｉｄ＝１２３４５６＆ｔ＝５００５であり得る。ここで、ｃｉｄは、遠隔サーバーに報告されるコンテンツソースＩＤの質疑識別子を意味し得る。ｔは、遠隔サーバーに報告される現在の時間の質疑識別子を意味し得る。
【０７２０】
図５３は、本発明の実施例＃２によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【０７２１】
サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５３０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭに挿入するステップ（ｓ５３０２０）、ＷＭ挿入器が、ＷＭが挿入されたコンテンツを送信するステップ（ｓ５３０３０）、ＳＴＢが、ＷＭが挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５３０４０）、ＷＭ検出器がＷＭを検出するステップ（ｓ５３０５０）、及びＷＭマネジャーが検出されたＷＭをパースするステップ（ｓ５３０６０）は、上述したステップと同一であってもよい。
【０７２２】
ＷＭマネジャーは、パースされた目的地タイプフィールド０ｘ０５を介して遠隔サーバーと通信することができる。ＷＭマネジャーは、ＵＲＬプロトコルタイプフィールドの値及びＵＲＬ値を用いてＵＲＬを生成することができる。また、コンテンツＩＤ及びタイムスタンプ値を用いてＵＲＬが最終的に生成され得る。ＷＭマネジャーは、最終ＵＲＬを用いて要求することができる（ｓ５３０７０）。
【０７２３】
遠隔サーバーは、要求を受信し、放送プログラムに適した関連アプリケーションのＵＲＬをＷＭマネジャーに送信することができる（ｓ５３０８０）。ＷＭマネジャーは、受信されたアプリケーションのＵＲＬをブラウザに伝送し、アプリケーションを開始する(launch)ことができる（ｓ５３０９０）。
【０７２４】
前記説明と同様に、端末のＷＭ検出器及びＷＭマネジャーが結合され、一つのモジュールでその機能を行うことができる。この場合、ステップｓ５３０５０、ｓ５３０６０、ｓ５３０７０、ｓ５３０９０が、一つのモジュールで行われてもよい。
【０７２５】
図５４は、本発明の実施例＃３によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７２６】
本発明は、ウォーターマーキング方式を介して伝達可能なデータのうち一つとして、伝達タイプフィールドを提案する。また、本発明は、伝達タイプフィールドの効率的なデータ構造を提案する。
【０７２７】
ＷＭに挿入されたデータの量の増加によるオーディオ／ビデオコンテンツの品質の劣化を減少させるために、ＷＭが分離されて挿入されてもよい。ＷＭが分離されて挿入されるかを示すために、伝達タイプフィールドが使用されてもよい。伝達タイプフィールドを介して、放送関連情報を得るために１つのＷＭ、あるいは複数個のＷＭが検出されるかを決定することができる。
【０７２８】
伝達タイプフィールドが０の値を有すると、これは、全てのデータが一つのＷＭに挿入されて送信されることを意味し得る。伝達タイプフィールドが１の値を有すると、これは、データが分けられて複数個のＷＭに挿入されて送信されることを意味し得る。
【０７２９】
本実施例において、伝達タイプフィールドの値は０である。この場合、ＷＭのデータ構造は、伝達タイプフィールドを上述したデータ構造に付着する形態で構成されてもよい。本発明では、伝達タイプフィールドが最前部に位置するが、伝達タイプフィールドが他の位置に配置されてもよい。
【０７３０】
ＷＭマネジャー又はＷＭ検出器は、伝達タイプフィールドが０の値を有する場合、ＷＭの長さを参照してＷＭをパースすることができる。このとき、ＷＭの長さは、所定のフィールドのビット数を考慮して計算することができる。例えば、上述したように、イベントフィールドの長さは３ビットであってもよい。実施例によって、コンテンツＩＤ及びＵＲＬのサイズは変更可能であるが、ビットの数は制限され得る。
【０７３１】
図５５は、本発明の実施例＃４によってＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７３２】
本実施例において、伝達タイプフィールドの値は１であってもよい。この場合、複数個のフィールドがＷＭのデータ構造に付加されてもよい。
【０７３３】
ＷＭＩｄフィールドは、ＷＭを識別する識別子として機能することができる。データが複数個のＷＭに分けられて送信される場合、ＷＭ検出器は、分離されたデータを有するそれぞれのＷＭを識別する必要がある。このとき、分離されたデータをそれぞれ有するＷＭは、同一のＷＭＩｄフィールド値を有することができる。ＷＭＩｄフィールドは８ビットのサイズを有することができる。
【０７３４】
ブロック番号フィールドは、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭの識別番号を示すことができる。分離されたデータをそれぞれ有するＷＭの値は、その送信順序によって１ずつ増加することができる。例えば、分離されたデータをそれぞれ有するＷＭのうち第１ＷＭの場合、ブロック番号フィールドの値は０ｘ００であってもよい。第２ＷＭ、第３ＷＭ及びその後続のＷＭは０ｘ０１，０ｘ０２，…の値を有することができる。ブロック番号フィールドは８ビットのサイズを有することができる。
【０７３５】
最後のブロック番号フィールドは、分離されたデータをそれぞれ有するＷＭのうち最後のＷＭの識別番号を示すことができる。ＷＭ検出器又はＷＭマネジャーは、上述したブロック番号フィールドの値が最後のブロック番号フィールドと同一になるまで検出されたＷＭを集めてパースすることができる。最後のブロック番号フィールドは８ビットのサイズを有することができる。
【０７３６】
ブロック長フィールドは、ＷＭの全長を示すことができる。ここで、ＷＭは、分離されたデータをそれぞれ有するＷＭのうち１つを意味し得る。ブロック長フィールドは７ビットのサイズを有することができる。
【０７３７】
コンテンツＩＤフラグフィールドは、コンテンツＩＤが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。コンテンツＩＤが含まれる場合、コンテンツＩＤフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。コンテンツＩＤフラグフィールドは１ビットのサイズを有することができる。
【０７３８】
イベントフラグフィールドは、イベントフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。イベントフィールドが含まれる場合、イベントフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。イベントフラグフィールドは１ビットのサイズを有することができる。
【０７３９】
目的地フラグフィールドは、目的地タイプフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。目的地タイプフィールドが含まれる場合、目的地フラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。目的地フラグフィールドは１ビットのサイズを有することができる。
【０７４０】
ＵＲＬプロトコルフラグフィールドは、ＵＲＬプロトコルタイプフィールドが、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。ＵＲＬプロトコルタイプフィールドが含まれる場合、ＵＲＬプロトコルフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。ＵＲＬプロトコルフラグフィールドは１ビットのサイズを有することができる。
【０７４１】
ＵＲＬフラグフィールドは、ＵＲＬ情報が、分離されたデータをそれぞれ有するＷＭのうち現在のＷＭのペイロードに含まれるか否かを示すことができる。ＵＲＬ情報が含まれる場合、ＵＲＬフラグフィールドは１に設定されてもよく、そうでなければ、０に設定されてもよい。ＵＲＬフラグフィールドは１ビットのサイズを有することができる。
【０７４２】
ペイロードは、上述したフィールドに加え、実際のデータを含むことができる。
【０７４３】
データが複数個のＷＭに分離されて送信される場合、それぞれのＷＭがいつ挿入されるかに関する情報を知る必要がある。この場合、実施例によって、タイムスタンプがそれぞれのＷＭに挿入されてもよい。このとき、ＷＭがいつ挿入されるかを知るために、タイムスタンプタイプフィールドもまたタイムスタンプが挿入されたＷＭに挿入されてもよい。代案として、実施例によって、受信機は、ＷＭタイムスタンプタイプ情報を格納して使用することができる。受信機は、第１タイムスタンプ、最後のタイムスタンプ又はそれぞれのタイムスタンプに基づいて時間同期化を行うことができる。
【０７４４】
データが複数個のＷＭに分けられて送信される場合、それぞれのＷＭのサイズがフラグフィールドを用いて調整されてもよい。上述したように、ＷＭによって送信されたデータの量が増加すると、オーディオ／ビデオコンテンツの品質が影響を受けることがある。したがって、フレームに挿入されたＷＭのサイズは、送信されたオーディオ／ビデオフレームに応じて調整され得る。このとき、ＷＭのサイズは、上述したフラグフィールドによって調整されてもよい。
【０７４５】
例えば、コンテンツのビデオフレームのうちの任意の１つは、ブラックスクリーンのみを有すると仮定する。場面がコンテンツに応じてスイッチングされると、ブラックスクリーンのみを有する１つのビデオフレームのみが挿入され得る。このビデオフレームにおいて、さらに多くの量のＷＭが挿入される場合でも、コンテンツの品質は劣化しない。すなわち、ユーザがコンテンツ品質の劣化を感知しない。この場合、多量のデータを有するＷＭが、このビデオフレームに挿入され得る。このとき、ビデオフレームに挿入されたＷＭのフラグフィールドの値のほとんどが１であってもよい。これは、ＷＭがフィールドのほとんどを有するためである。特に、多量のデータを有するＵＲＬフィールドは、そのＷＭ内に含まれ得る。したがって、比較的少量のデータは、他のビデオフレームに挿入され得る。ＷＭに挿入されたデータの量は、設計者の意図によって変更可能である。
【０７４６】
図５６は、本発明の実施例＃４によって第１ＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７４７】
本実施例において、伝達タイプフィールドの値が１であると、すなわち、データが複数個のＷＭに分離されて送信される場合、第１ＷＭの構造が、図５６に示されたものと同一であってもよい。
【０７４８】
分離されたデータをそれぞれ有するＷＭのうち、第１ＷＭは０ｘ００のブロック番号フィールド値を有することができる。実施例によって、ブロック番号フィールドの値が異なって使用される場合、図示されたＷＭは第１ＷＭではなくてもよい。
【０７４９】
受信機は第１ＷＭを検出することができる。検出されたＷＭは、ＷＭマネジャーによってパースされてもよい。このとき、ＷＭの伝達タイプフィールドの値は１であり、ブロック番号フィールドの値が最後のブロック番号フィールドの値と異なることがわかる。したがって、ＷＭマネジャーは、０ｘ００のＷＭＩＤを有する残りのＷＭが受信されるまで、パースされた情報を格納することができる。特に、ＵＲＬ情報であるａｔｓｃ．ｏｒｇもまた格納され得る。最後のブロック番号フィールドの値が０ｘ０１であるため、一つのＷＭが未来にさらに受信されると、０ｘ００のＷＭＩＤを有する全てのＷＭが受信され得る。
【０７５０】
本実施例において、フラグフィールドの全ての値は１である。したがって、イベントフィールドなどの情報がこのＷＭのペイロードに含まれることがわかる。また、タイムスタンプの値が５００５であるため、このＷＭが挿入された部分に対応する時間は５．００５秒であり得る。
【０７５１】
図５７は、本発明の実施例＃４によって第２ＷＭに挿入されるデータの構造を示すダイヤグラムである。
【０７５２】
本実施例において、伝達タイプフィールドの値が１であると、すなわち、データが複数個のＷＭに分けられて送信される場合、第２ＷＭの構造は、図５７に示されたものと同一であってもよい。
【０７５３】
分離されたデータをそれぞれ有するＷＭのうち、第２ＷＭは０ｘ０１のブロック番号フィールド値を有することができる。実施例によって、ブロック番号フィールドの値が異なって使用される場合、図示されたＷＭは第２ＷＭではなくてもよい。
【０７５４】
受信機は第２ＷＭを検出することができる。ＷＭマネジャーは、検出された第２ＷＭをパースすることができる。このとき、ブロック番号フィールドの値が最後のブロック番号フィールドの値と同一であるため、このＷＭが、０ｘ００のＷＭＩｄ値を有するＷＭのうち最後のＷＭであることがわかる。
【０７５５】
フラグフィールドのうち、ＵＲＬフラグの値のみが１であるため、ＵＲＬ情報が含まれることがわかる。ブロック番号フィールドの値が０ｘ０１であるため、この情報は、既に格納された情報と結合され得る。特に、既に格納されたａｔｓｃ．ｏｒｇ部分及び第２ＷＭに含まれる／ａｐｐｓ／ａｐｐ１．ｈｔｍｌ部分が結合され得る。また、既に格納された情報において、ＵＲＬプロトコルタイプフィールドの値が００１であるため、最終的に結合されたＵＲＬは、ｈｔｔｐ：／／ａｔｓｃ．ｏｒｇ／ａｐｐｓ／ａｐｐ１．ｈｔｍｌであり得る。このＵＲＬは、このブラウザを介して開始されてもよい。
【０７５６】
第２ＷＭによって、第２ＷＭが挿入された部分に対応する時間は１０．００５秒であり得る。受信機は、第１ＷＭの５．００５秒に基づいて時間同期化を行うか、または最後のＷＭの１０．００５秒に基づいて時間同期化を行うことができる。本実施例において、ＷＭは、５秒の間隔をおいて２回送信される。ＷＭが伝達されない５秒間、オーディオ／ビデオのみが送信されるため、コンテンツ品質の劣化を防止することができる。これは、データが複数個のＷＭに分離されて送信される場合にも、品質の劣化を減少させることができる。ＷＭが分離されて挿入される時間は、実施例によって変更されてもよい。
【０７５７】
図５８は、本発明の実施例＃４によってＷＭに挿入されるデータ構造を処理するプロセスを示すフローチャートである。
【０７５８】
サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５８０１０）、ＷＭ挿入器が、受信されたコンテンツをＷＭ＃１に挿入するステップ（ｓ５８０２０）、ＷＭ挿入器が、ＷＭ＃１が挿入されたコンテンツを送信するステップ（ｓ５８０３０）、ＳＴＢが、ＷＭ＃１が挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５８０４０）、及びＷＭ検出器がＷＭ＃１を検出するステップ（ｓ５８０５０）は、上述したステップと同一であってもよい。
【０７５９】
ＷＭ＃１は、分離されたデータが挿入されたＷＭのうちの１つであることを意味し、本発明の実施例＃４における第１ＷＭであってもよい。上述したように、このＷＭのブロック番号フィールドは０ｘ００であり、ＵＲＬ情報はａｔｓｃ．ｏｒｇであってもよい。
【０７６０】
ＷＭマネジャーは、検出されたＷＭ＃１をパースし、格納することができる（ｓ５８０６０）。このとき、ＷＭマネジャーは、各フィールドのビット数及びＷＭの全長を参照してパーシングを行うことができる。ブロック番号フィールドの値が最後のブロックフィールドの値と異なり、伝達タイプフィールドの値が１であるため、ＷＭマネジャーは、ＷＭをパースし、格納した後、次のＷＭを待つ。
【０７６１】
ここで、サービス提供者がコンテンツをＷＭ挿入器に伝達するステップ（ｓ５８０７０）、ＷＭ挿入器が、受信されたコンテンツをＷＭ＃２に挿入するステップ（ｓ５８０８０）、ＷＭ挿入器が、ＷＭ＃２が挿入されたコンテンツを送信するステップ（ｓ５８０９０）、ＳＴＢが、ＷＭ＃２が挿入されたコンテンツを受信し、圧縮不可能なＡ／Ｖデータを出力するステップ（ｓ５８１００）、及びＷＭ検出器がＷＭ＃２を検出するステップ（ｓ５８１１０）は、上述したステップと同一であってもよい。
【０７６２】
ＷＭ＃２は、分離されたデータが挿入されたＷＭのうちの１つを意味し、本実施例の実施例＃４における第２ＷＭであってもよい。上述したように、このＷＭのブロック番号フィールドは０ｘ０１であり、ＵＲＬ情報は／ａｐｐｓ／ａｐｐ１．ｈｔｍｌであってもよい。
【０７６３】
ＷＭマネジャーは、検出されたＷＭ＃２をパースし、格納することができる（ｓ５８１２０）。ＷＭ＃２をパースして得た情報と、既に格納されたＷＭ＃１をパースして得た情報とが結合されて全体のＵＲＬを生成することができる（ｓ５８１３０）。この場合、全体のＵＲＬは、上述した通りである。
【０７６４】
ＷＭマネジャーが、関連するデータを目的地タイプフィールドによる受信機のコンパニオン装置プロトコルモジュールに伝達するステップ（ｓ５８１４０）、及びコンパニオン装置プロトコルモジュールが、関連するデータを目的地タイプフィールドによるコンパニオン装置に伝達するステップ（ｓ５８１５０）は、上述したステップと同一であってもよい。
【０７６５】
目的地タイプフィールドは、上述したように、ＷＭ＃１によって伝達されてもよい。これは、本発明の実施例＃４の第１ＷＭの目的地フラグフィールドの値が１であるためである。上述したように、この目的地タイプフィールドの値がパースされ、格納されてもよい。目的地タイプフィールドの値が０ｘ０２であるため、これは、スマートフォンに対するデータを示すことができる。
【０７６６】
コンパニオン装置プロトコルモジュールは、上述したように、コンパニオン装置と通信して関連情報を処理することができる。上述したように、ＷＭ検出器とＷＭマネジャーが結合されてもよい。結合されたモジュールは、ＷＭ検出器及びＷＭマネジャーの機能を行うことができる。
【０７６７】
図５９は、本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。
【０７６８】
この実施例は、ＷＭマネジャーｔ５９０１０及びコンパニオン装置プロトコルモジュールｔ５９０２０がウォーターマーク抽出器ｔ５９０３０の下に付加されることを除いては、上述したウォーターマークベースの映像表示装置の構造と類似している。残りのモジュールは、上述したモジュールと同一であってもよい。
【０７６９】
ウォーターマーク抽出器ｔ５９０３０は、上述したＷＭ検出器に対応し得る。ウォーターマーク抽出器ｔ５９０３０は、上述したウォーターマークベースの映像表示装置の構造と同じ名を有するモジュールと同一であってもよい。ＷＭマネジャーｔ５９０１０は上述したＷＭマネジャーに対応し、コンパニオン装置プロトコルモジュールｔ５９０２０は上述したコンパニオン装置プロトコルモジュールに対応し得る。モジュールの動作は上述した。
【０７７０】
図６０は、フィンガープリンティング方式における本発明の一実施例に係るデータ構造を示す図である。
【０７７１】
フィンガープリンティング（ＦＰ）ＡＣＲシステムの場合、オーディオ／ビデオコンテンツの品質劣化が、ＷＭを用いる場合と比較して減少することができる。フィンガープリンティングＡＣＲシステムの場合、付加情報がＡＣＲサーバーから受信されるので、品質劣化は、コンテンツに直接挿入されたＷＭの品質劣化よりも小さい。
【０７７２】
ＡＣＲサーバーから情報が受信される場合、品質劣化が上述したように減少するので、ＷＭに使用されるデータ構造がそのまま使用されてもよい。すなわち、本発明によって提案されたデータ構造はＦＰ方式でも使用することができる。代案として、実施例によって、ＷＭのデータ構造の一部のみが使用されてもよい。
【０７７３】
ＷＭの上述したデータ構造が使用されると、０ｘ０５の目的地タイプフィールド値の意味が変更され得る。上述したように、目的地タイプフィールドの値が０ｘ０５であると、受信機が遠隔サーバーにデータを要求することができる。ＦＰ方式において、遠隔サーバーの機能はＡＣＲサーバーによって行われるので、目的地タイプフィールドの値０ｘ０５が削除されたり、再定義されてもよい。
【０７７４】
残りのフィールドは、上述したフィールドと同一であってもよい。
【０７７５】
図６１は、フィンガープリンティング方式における本発明の一実施例に係るデータ構造を処理するプロセスを示すフローチャートである。
【０７７６】
サービス提供者は、送信される放送プログラムからフィンガープリント（ＦＰ）を抽出することができる（ｓ６１０１０）。ここで、サービス提供者は、上述したサービス提供者と同一であってもよい。サービス提供者は、ＡＣＲ会社によって提供されたツール又は自身のツールを用いて、コンテンツ毎にフィンガープリントを抽出することができる。サービス提供者は、オーディオ／ビデオフィンガープリントを抽出することができる。
【０７７７】
サービス提供者は、抽出されたフィンガープリントをＡＣＲサーバーに伝達することができる（ｓ６１０２０）。事前に生成されたプログラムの場合、放送プログラムが送信される前、又はライブプログラムの場合、ＦＰがリアルタイムで抽出されたらすぐに、フィンガープリントがＡＣＲサーバーに伝達されてもよい。ＦＰがリアルタイムで抽出されてＡＣＲサーバーに伝達されると、サービス提供者は、コンテンツＩＤをコンテンツに割り当てて、送信タイプ、目的地タイプ又はＵＲＬプロトコルタイプなどの情報を割り当てることができる。割り当てられた情報は、リアルタイムで抽出されたＦＰにマッピングされ、ＡＣＲサーバーに伝達されてもよい。
【０７７８】
ＡＣＲサーバーは、受信されたＦＰ及びその関連情報をＡＣＲ  ＤＢに格納することができる（ｓ６１０３０）。受信機は、外部から受信されたオーディオ／ビデオ信号からＦＰを抽出することができる。ここで、オーディオ／ビデオ信号は圧縮不可能な信号であってもよい。このＦＰは、シグネチャー（ｓｉｇｎａｔｕｒｅ）と呼ぶことができる。受信機は、ＦＰを用いて、要求をサーバーに伝送することができる（ｓ６１０４０）。
【０７７９】
ＡＣＲサーバーは、受信されたＦＰとＡＣＲ  ＤＢを比較することができる。受信されたＦＰにマッチングするＦＰがＡＣＲ  ＤＢに存在する場合、受信機によって放送されるコンテンツが認識され得る。コンテンツが認識されると、伝達タイプ情報、タイムスタンプ、コンテンツＩＤ、イベントタイプ情報、目的地タイプ情報、ＵＲＬプロトコルタイプ情報、ＵＲＬ情報などが受信機に伝送され得る（ｓ６１０５０）。
【０７８０】
ここで、それぞれの情報は、上述したフィールドに含まれた状態で送信されてもよい。例えば、目的地タイプ情報は、目的地タイプフィールドに含まれた状態で送信されてもよい。受信機に応答するとき、上述したＷＭに使用されるデータ構造は、伝達されたデータの構造として使用されてもよい。
【０７８１】
受信機は、ＡＣＲサーバーから受信された情報をパースすることができる。本実施例において、目的地タイプフィールドの値が０ｘ０１であるため、ＵＲＬのアプリケーションがＴＶによって実行されることがわかる。最終ＵＲＬがＵＲＬプロトコルタイプフィールドの値及びＵＲＬ情報を用いて生成されてもよい。ＵＲＬを生成するプロセスは、上述したプロセスと同一であってもよい。
【０７８２】
受信機は、ＵＲＬを用いて、ブラウザを介して放送関連アプリケーションを実行することができる（ｓ６１０６０）。ここで、ブラウザは、上述したブラウザと同一であってもよい。ステップｓ６１０４０、ｓ６１０５０、ｓ６１０６０は繰り返されてもよい。
【０７８３】
図６２は、本発明の一実施例に係る、放送受信機を示す図である。
【０７８４】
本発明の一実施例に係る放送受信機は、サービスコンテンツ取得制御器（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ  Ａｃｑｕｉｓｉｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）Ｊ２０１０、インターネットインターフェース（Ｉｎｔｅｒｎｅｔ  ｉｎｔｅｒｆａｃｅ）Ｊ２０２０、放送網インターフェース（Ｂｒｏａｄｃａｓｔ  ｉｎｔｅｒｆａｃｅ）Ｊ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理ユニット（Ｍａｎａｇｉｎｇ  ｕｎｉｔ）Ｊ２０９０及び／又は再分配モジュール（ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ  ｍｏｄｕｌｅ）Ｊ２１００を含む。図面では、放送受信機の外部及び／又は内部に存在し得る外部管理装置（Ｅｘｔｅｒｎａｌ  Ｍａｎａｇｅｍｅｎｔ）Ｊ２１１０が示されている。
【０７８５】
サービスコンテンツ取得制御器Ｊ２０１０は、ブロードキャスト／ブロードバンドチャネルを介してサービス及び／又はコンテンツ、これと関連したシグナリングデータを受信する。又は、サービスコンテンツ取得制御器Ｊ２０１０は、サービス及び／又はコンテンツ、これと関連したシグナリングデータを受信するための制御を行うことができる。
【０７８６】
インターネットインターフェースＪ２０２０は、インターネットアクセスコントロールモジュール（Ｉｎｔｅｒｎｅｔ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍｏｄｕｌｅ）を含むことができる。インターネットアクセスコントロールモジュールは、ブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。又は、インターネットアクセスコントロールモジュールは、サービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御することができる。
【０７８７】
放送網インターフェースＪ２０３０は、物理層モジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍｏｄｕｌｅ）及び／又は物理層インターフェースモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｉ／Ｆ  Ｍｏｄｕｌｅ）を含むことができる。物理層モジュールは、放送チャネルを介して放送関連信号を受信する。物理層モジュールは、放送チャネルを介して受信した放送関連信号を処理（復調、復号など）する。物理層インターフェースモジュールは、物理層モジュールから取得した情報から、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）データグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、放送フレーム、ＲＳフレーム、又はＧＳＥなど）に変換する。
【０７８８】
シグナリングデコーダＪ２０４０は、ブロードキャストチャネルなどを解して取得したシグナリングデータ又はシグナリング情報（以下、‘シグナリングデータ’という。）をデコードする。
【０７８９】
サービスマップデータベースＪ２０５０は、デコードされたシグナリングデータを保存したり、受信機の他の装置（例えば、シグナリングパーサーなど）で処理されたシグナリングデータを保存する。
【０７９０】
デコーダＪ２０６０は、受信機で受信した放送信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールドストリーミングデコーダ（Ｓｃｈｅｄｕｌｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）、ファイルデコーダ（Ｆｉｌｅ  Ｄｅｃｏｄｅｒ）、ファイルデータベース（Ｆｉｌｅ  ＤＢ）、オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）、コンポーネント同期化器（Ｃｏｍｐｏｎｅｎｔ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）、警報シグナリングパーサー（Ａｌｅｒｔ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）、ターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）、サービスシグナリングパーサー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）及び／又はアプリケーションシグナリングパーサー（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）を含むことができる。
【０７９１】
スケジュールドストリーミングデコーダ（Ｓｃｈｅｄｕｌｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムなどから実時間Ａ／Ｖ（Ａｕｄｉｏ  ／  Ｖｉｄｅｏ）ストリーミングのためのオーディオ／ビデオデータ抽出し、これをデコードする。
【０７９２】
ファイルデコーダ（Ｆｉｌｅ  Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムから、ＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態データを抽出し、これをデコードする。
【０７９３】
ファイルデータベース（Ｆｉｌｅ  ＤＢ）は、ファイルデコーダから抽出したデータを保存する。
【０７９４】
オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムなどでからユーザ要求（ｏｎ−ｄｅｍａｎｄ）ストリーミングのためのオーディオ／ビデオデータを抽出し、これをデコードする。
【０７９５】
コンポーネント同期化器（Ｃｏｍｐｏｎｅｎｔ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）は、スケジュールドストリーミングデコーダ、ファイルデコーダ及び／又はオンデマンドストリーミングデコーダでデコードされたデータに基づいて、コンテンツを構成する要素間の同期化を行ったり、サービスを構成する要素間の同期化を行い、コンテンツ又はサービスを構成する。
【０７９６】
警報シグナリングパーサー（Ａｌｅｒｔ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどから警報（ａｌｅｒｔｉｎｇ）と関連したシグナリング情報を抽出し、これをパースする。
【０７９７】
ターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツ個人化、又はターゲッティング関連したシグナリング情報を抽出し、これをパースする。ここで、ターゲッティングとは、特定視聴者の条件に合うコンテンツ又はサービスを提供することであり、当該視聴者の条件に合うコンテンツ又はサービスを識別してそれを提供する行為を指す。
【０７９８】
サービスシグナリングパーサー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービススキャン及び／又はサービス／コンテンツなどに関連したシグナリング情報を抽出し、これをパースする。サービス／コンテンツなどに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。
【０７９９】
アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからアプリケーションの取得に関連したシグナリング情報を抽出し、これをパースする。アプリケーションの取得に関連したシグナリング情報は、トリガー、ＴＰＴ（ＴＤＯ  ｐａｒａｍｅｔｅｒ  ｔａｂｌｅ）及び／又はＴＤＯパラメータエレメントを含むことができる。
【０８００】
ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーでパースされたサービス／コンテンツターゲッティング関連情報を処理する。
【０８０１】
プロセッサＪ２０８０は、受信したデータをディスプレイするための一連の処理を行う。プロセッサＪ２０８０は、警報プロセッサ（Ａｌｅｒｔ  Ｐｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｃｅｓｓｏｒ）及び／又はオーディオ／ビデオプロセッサ（Ａ／Ｖ  Ｐｒｏｃｅｓｓｏｒ）を含むことができる。
【０８０２】
警報プロセッサは、警報と関連したシグナリング情報を用いて、警報データを取得するように受信機を制御し、警報データをディスプレイするための処理を行う。
【０８０３】
アプリケーションプロセッサは、アプリケーション関連情報を処理し、ダウンロードされたアプリケーションの状態及びアプリケーションに関連したディスプレイパラメータを処理する。
【０８０４】
オーディオ／ビデオプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリング関連動作を行う。
【０８０５】
管理ユニットＪ２０９０は、装置マネジャー（ｄｅｖｉｃｅ  ｍａｎａｇｅｒ）及び／又はデータ通信及びシェアリングユニット（Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｔ）を含む。
【０８０６】
装置マネジャーは、連結及びデータ交換などの連動可能な外部装置の追加／削除／更新などの外部装置に対する管理を行う。
【０８０７】
データ通信及びシェアリングユニットは、受信機と外部装置（例えば、コンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ））間のデータ伝送及び交換関連情報を処理し、これと関連した動作を行う。伝送及び交換可能なデータは、シグナリングデータ、ＰＤＩ  ｔａｂｌｅ、ＰＤＩ  ｕｓｅｒ  ｄａｔａ、ＰＤＩ  Ｑ＆Ａ及び／又はＡ／Ｖデータであってもよい。
【０８０８】
再分配モジュールＪ２１００は、受信機が放送信号を直接受信できない場合、放送サービス／コンテンツ関連情報及び／又はサービス／コンテンツデータの取得を行う。
【０８０９】
外部管理装置Ｊ２１１０は、放送サービス／コンテンツサーバーなど、放送サービス／コンテンツ提供のための放送受信機の外部のモジュールのことを指す。外部管理装置の役割を担うモジュールは、放送受信機の内部に設けられてもよい。
【０８１０】
本発明の一実施例に係る放送信号受信機（又は受信機）は、図１乃至図２９で説明した放送信号を処理するＴＶ受信機（ＴＶ  ｒｅｃｅｉｖｅｒ）又は受信機（ｒｅｃｅｉｖｅｒ）を含むことができる。本発明の一実施例に係る放送信号受信機は、ブロードキャストチャネル（ｂｒｏａｄｃａｓｔ  ｃｈａｎｎｅｌ）を介して伝送される放送信号（ｂｒｏａｄｃａｓｔ  ｓｉｇｎａｌｓ）だけでなく、ブロードバンドチャネル（ｂｒｏａｄｂａｎｄ  ｃｈａｎｎｅｌ）を介して伝送されるコンテンツを受信することができる。本発明の一実施例に係る放送信号及びコンテンツが提供するサービスをハイブリッド放送サービス（ｈｙｂｒｉｄ  ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ）と呼ぶことができる。名称及び定義は、設計者の意図によって変更可能である。
【０８１１】
以下では、本発明の一実施例に係るマルチキャスト（Ｍｕｌｔｉｃａｓｔ）環境でのＡＣＲを介したシグナリング（ｓｉｇｎａｌｉｎｇ）方法について説明する。
【０８１２】
ＡＣＲ技法は、ブロードキャストチャネルを介したシグナリングを行うことができない、ＳＴＢ（ＳｅｔＴｏｐＢｏｘ；セットトップボックス）を用いる状況で使用され、主にＡＣＲ技法により、現在視聴しているチャネル（ｃｈａｎｎｅｌ）やプログラム（ｐｒｏｇｒａｍ）の情報を取得する。このように、現在視聴中の放送のチャネルやプログラムの認識結果に基づいて別途のシグナリングサーバーにブロードバンドチャネルを介してシグナリング情報を要求することができ、ユニキャスト（ｕｎｉｃａｓｔ）の形態の構造を有することができる。しかし、本発明で提示するハイブリッド放送サービスでは、ブロードキャスター（ｂｒｏａｄｃａｓｔｅｒ）が放送網ではなく、ブロードバンドチャネルを介してマルチキャストでシグナリング情報を送出することができ、受信機は、これを受信及びシグナリングすることができる。
【０８１３】
図６３は、本発明の一実施例に係るマルチキャスト環境でのＡＣＲ送受信システムを示す。
【０８１４】
上述したように、ＳＴＢを使用する環境の場合、受信機は、放送網を介して伝達されるシグナリング情報を受信することができない。しかし、ＡＣＲスキーム（ＡＣＲ  ｓｃｈｅｍｅ）を介して現在視聴中のチャネル又はプログラムなどのようなシグナリングの取得のための最小限の情報を受信する場合、既存に使用されていた周期的な要求（ｒｅｑｕｅｓｔ）及び応答（ｒｅｓｐｏｎｓｅ）手順なしにも、マルチキャストを介してシグナリングを直接受信することができる。
【０８１５】
図６３は、本発明の一実施例に係る受信機がマルチキャストを介してシグナリング情報を受信する過程を示す。図６３に示されたブロックの動作は、上述したものと同一であるので、以下では、マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作について説明する。
【０８１６】
受信機は、ブロードバンドに接続できる場合（すなわち、インタネットを使用できる場合）、マルチキャストセッション（Ｍｕｌｔｉｃａｓｔ  ｓｅｓｓｉｏｎ）にジョイン（接続）（Ｊｏｉｎ）することができる。
【０８１７】
その後、受信機は、ＡＣＲスキームを介してＳＴＢに伝達されるＡ／Ｖに基づいて、現在受信中の放送信号又は放送情報を検出（ｄｅｔｅｃｔｉｏｎ）することができる。
【０８１８】
その後、受信機は、認識した放送情報を用いて、マルチキャストを介して伝送されるシグナリング情報のうち必要なシグナリング情報をパース（ｐａｒｓｉｎｇ）し、関連サービスをユーザに提供することができる。
【０８１９】
図６４は、本発明の一実施例に係るマルチキャスト環境でのＷＭを介したＡＣＲ送受信システムを示す。
【０８２０】
図面の上端は、ＷＭにシグナリングサーバーのアドレスが挿入された場合のＡＣＲ送受信システムを示し、図面の下端は、ＷＭにＡＣＲサーバーのアドレスのみが挿入され、受信機が当該ＡＣＲサーバーに要求及び応答方式で現在視聴中の放送のチャネル、プログラム、シグナリングサーバーのアドレスなどを取得する場合のＡＣＲ送受信システムを示す。
【０８２１】
図６４に示されたブロックの動作は、上述したものと同一であるので、以下では、マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作について説明する。
【０８２２】
図面の上端に示された送受信システムの場合、ＷＭにシグナリングサーバー（Ｓｉｇｎａｌｉｎｇ  Ｓｅｒｖｅｒ）のアドレスが挿入されているので、受信機は、ＷＭを抽出した後、当該シグナリングサーバーのアドレスを取得し、シグナリングサーバーセッション（ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ  ｓｅｓｓｉｏｎ）にジョイン（ｊｏｉｎ）してシグナリング情報を受けることができる。
【０８２３】
図面の下端に示された送受信システムの場合、ＷＭにはＡＣＲサーバーのアドレスのみが挿入されているので、受信機は、ＡＣＲサーバーからシグナリングサーバーのアドレスを取得することができる。
【０８２４】
マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作は、図６３で説明したものと同一であるので、具体的な説明は省略する。
【０８２５】
図６５は、本発明の一実施例に係るマルチキャスト環境でのＦＰ方式を介したＡＣＲ送受信システムを示す。
【０８２６】
上述したように、受信機は、オーディオ／ビデオ信号からＦＰを抽出することができる。その後、受信機は、抽出したシグネチャー（又はＦＰ）をＦＰサーバー（ＦＰ  Ｓｅｒｖｅｒ）に伝送し、ＦＰサーバーから現在のチャネル、プログラムなどの情報以外に、シグナリングサーバーのアドレスを受信することができる。その後、受信機は、サーバーセッションにジョイン（接続）（ｊｏｉｎ）してシグナリング情報を受けることができる。
【０８２７】
マルチキャスト環境でＡＣＲを介した放送関連情報のシグナリング及びサービスの提供を受けるための受信機の動作は、図６３で説明したものと同一であるので、具体的な説明は省略する。
【０８２８】
図６６は、本発明の一実施例に係る受信機がマルチキャスト環境でＡＣＲスキームを介して放送と関連するシグナリングを行うフローチャートを示す。
【０８２９】
サービスプロバイダは、放送網だけでなくブロードバンドチャネル（ｂｒｏａｄｂａｎｄ  ｃｈａｎｎｅｌ）を介しても、放送に関するシグナリング情報をマルチキャストで伝送することができる。これを受信した受信機は、当該シグナリング情報を取得するためにマルチキャストセッションにジョインして、当該シグナリングを受信するための通信（ｃｏｍｍｕｎｉｃａｔｉｏｎ）手順を行うことができる。
【０８３０】
本発明の一実施例に係る受信機がシグナリングサーバー（又はマルチキャストサーバー）のアドレスを取得する方式は、次の通りである。
【０８３１】
第１実施例：受信機は、ＡＣＲサーバーから現在視聴しているチャネルの認識結果を受信するとき、当該チャネルのマルチキャストサーバーのアドレス（例えば、ＵＲＬ、ＩＰアドレスなど）を共に受信することができる。
【０８３２】
第２実施例：受信機は、受信機内に各チャネルに関するマルチキャストサーバーのアドレスを直接格納して、ＡＣＲサーバーからチャネル認識結果を受信すると、当該チャネルのマルチキャストサーバーに接近することができる。
【０８３３】
上述した実施例は、設計者の意図によって変更可能である。
【０８３４】
以下では、図示された受信機がマルチキャスト環境でＡＣＲスキームを介して放送と関連するシグナリングを行うフローチャートを説明する。図面のＡＣＲスキームは、上述したフィンガープリンティング方式の場合を示す。
【０８３５】
サービスプロバイダＥ６６０００は、ＡＣＲ業者が提供するツール（Ｔｏｏｌ）を用いてプログラム（Ｃｏｎｔｅｎｔ）別にフィンガープリント（Ｆｉｎｇｅｒｐｒｉｎｔ）を抽出することができる。この場合、サービスプロバイダＥ６６０００は、オーディオ／ビデオフィンガープリントデータベース（Ａｕｄｉｏ／Ｖｉｄｅｏ  ｆｉｎｇｅｒｐｒｉｎｔ  ＤＢ）を構築することができる。サービスプロバイダＥ６６０００は、必要であれば、２つのフィンガープリントを全て抽出して格納することができる。サービスプロバイダＥ６６０００は、ＡＣＲサーバーＥ６６１００に、コンテンツ（Ｃｏｎｔｅｎｔ）から抽出したフィンガープリントを伝達することができる。フィンガープリンタが伝達される時点は、プログラムの特性に応じて変わり得る。具体的には、事前に作製されたプログラムの場合、当該プログラムが放送で送出される前に当該フィンガープリントが伝達されてもよく、ライブプログラムの場合、リアルタイムでフィンガープリントが抽出されるとすぐに伝達されてもよい。この場合、サービスプロバイダＥ６６０００は、事前にプログラムに対してコンテンツを唯一に認識できる情報を付与し、リアルタイムで抽出されたフィンガープリントとマッピングして伝達することができる。
【０８３６】
ＡＣＲサーバーＥ６６１００は、受信したＦＰ及び関連情報をＡＣＲ  ＤＢに格納することができる。具体的な内容は、図６１で説明したものと同一であるので、省略する。
【０８３７】
その後、受信機Ｅ６６２００は、外部入力で受信されたオーディオ／ビデオ信号からフィンガープリントを抽出し、ＡＣＲサーバーＥ６６１００にＡＣＲ質疑要求（ＡＣＲ  Ｑｕｅｒｙ  Ｒｅｑｕｅｓｔ）を伝送することができる。ＡＣＲサーバーＥ６６１００は、受信したＡＣＲ質疑要求に対応して受信機Ｅ６６２００にＡＣＲ質疑応答（ＡＣＲ  Ｑｕｅｒｙ  Ｒｅｓｐｏｎｓｅ）を伝送することができる。具体的には、ＡＣＲサーバーＥ６６１００は、ＡＣＲ  ＤＢを検索して、受信したフィンガープリンタとマッチングされるコンテンツを探すことができる。その後、コンテンツが認識されると、ＡＣＲサーバーＥ６６１００は、ＡＣＲ質疑応答を伝送することができる。ＡＣＲ質疑応答は、当該コンテンツのチャネル情報（ｃｈａｎｎｅｌ  Ｉｎｆｏ）、シグナリングサーバーのアドレス（Ｍｕｌｔｉｃａｓｔ  ｓｅｒｖｅｒ  ａｄｄｒｅｓｓ）などを含むことができる。
【０８３８】
その後、受信機Ｅ６６２００は、受信したＡＣＲ質疑応答に含まれたシグナリングサーバーのアドレスを用いて、当該シグナリングサーバーＥ６６３００にマルチキャストセッションジョイン要求（ｍｕｌｔｉｃａｓｔ  ｓｅｓｓｉｏｎ  ｊｏｉｎ  ｒｅｑｕｅｓｔ）を送信することができる。
【０８３９】
シグナリングサーバーのアドレスは、サービスプロバイダ毎に各代表アドレスとして設定してもよく、特定のチャネルを代表するアドレスとして設定してもよい。それぞれの場合によって、サービスプロバイダはサーバーマネジメント（ｓｅｒｖｅｒ  ｍａｎａｇｅｍｅｎｔ）を行うことができる。
【０８４０】
また、一つのサービスプロバイダが複数個のチャネルを所有しており、代表アドレスとしてシグナリングサーバーアドレスを設定する場合、受信機は、当該シグナリングサーバーにリクエストを伝送するとき、チャネルＩＤ（ｃｈａｎｎｅｌ  ｉｄ）のようなチャネル識別情報を共に伝達して特定のチャネルに対するシグナリングを行うことができる。
【０８４１】
シグナリングサーバーＥ６６３００は、受信したマルチキャストセッションジョイン要求（ｍｕｌｔｉｃａｓｔ  ｓｅｓｓｉｏｎ  ｊｏｉｎ  ｒｅｑｕｅｓｔ）に対応して、受信機Ｅ６６２００に対して認証手順（ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｃｅｓｓ）を行い、セッションを接続及び維持することができる。受信機Ｅ６６２００とシグナリングサーバーＥ６６３００との間のセッションが接続されると、シグナリングサーバーＥ６６３００は、特別な要求及び応答の伝送なしに、持続的にシグナリング情報を受信機Ｅ６６２００に送信することができる。
【０８４２】
受信機Ｅ６６２００は、受信した情報をシグナルし、パースすることができる。当該動作は、シグナリングサーバーのアドレスが変更されるまで繰り返して行われてもよい。また、受信機Ｅ６６２００は、パーシングの結果に基づいて、当該チャネル或いはプログラムのサービスをユーザに提供することができる。
【０８４３】
その後、シグナリングサーバーのアドレスが変更されたり、関連シグナリング情報をパースする必要がない場合、受信機Ｅ６６２００は、当該セッションの終了を要求するリクエストを送信し、当該セッションから離れることができる。
【０８４４】
ウォーターマーキング（ＷａｔｅｒＭａｒｋｉｎｇ）を使用したＡＣＲスキームの場合、ＷＭの挿入時にシグナリングサーバーのアドレスを挿入することができ、上述したものと同一の過程を介してシグナリングを行うことができる。
【０８４５】
図６７は、本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す。
【０８４６】
本発明の一実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムは、ＬＴＥ／ＬＴＥ−ＡサービスのｅＭＢＭＳ（ｅｖｏｌｖｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）を結合したシステムである。ｅＭＢＭＳは、既存のＬＴＥ／ＬＴＥ−Ａサービスでモバイル放送サービスを同時に提供できる技術である。したがって、ｅＭＢＭＳを用いる場合、移動通信網を介した放送システムを構築することができる。今後の放送システムの場合、既存の放送網と移動通信網（モバイルブロードバンド）の両方を使用して伝送するハイブリッド放送サービスを提供することができる。ハイブリッド放送サービスの一実施例として、放送網を介しては当該サービスのベースレイヤコンポーネントを伝送し、モバイルブロードバンドを介してはＵＨＤサービスなどのためのエンハンスドレイヤコンポーネントを伝送する場合がある。また、ハイブリッド放送サービスの一実施例として、サービスプロバイダは、従来のｅＭＢＭＳで使用されるテーブルなどを用いて関連シグナリング情報を受信機に伝送する場合がある。
【０８４７】
図６７は、本発明の一実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す。
【０８４８】
図６７は、本発明の一実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報又は関連放送情報を受信する過程を示す。図６７に示されたブロックの動作は、上述した通りであるので、具体的な内容は省略する。また、図示された受信機に適用できるＡＣＲスキームは、ＷＭ又はＦＰ方式のうち少なくともいずれか１つの方式であってもよい。
【０８４９】
図６８は、本発明の他の実施例に係る受信機がモバイルブロードバンドを介してシグナリング情報を受信する過程を示す。図６８は、受信機に適用されたＡＣＲスキームがＷＭ方式である場合を示す。具体的な動作などは、上述した通りであるので省略する。
【０８５０】
図６９は、本発明の一実施例に係るハイブリッド放送サービスを示した概念図である。
【０８５１】
図１乃至図２９及び図３０乃至図６２で説明した本発明の一実施例に係る放送サービスと上述したｅＭＢＭＳサービスの両方を含むハイブリッド放送サービスは、ユーザに提供される形態によって、図示された２つのサービスに分けられる。
【０８５２】
図面の左側に示されたブロックは、それぞれのネットワークで提供する放送データのサービスプロバイダ又はコンテンツが異なる場合のハイブリッド放送サービスを示す。図面の右側に示されたブロックは、各サービスプロバイダが同じコンテンツを各ネットワークで同時に提供する場合のハイブリッド放送サービスを示す。
【０８５３】
図面の左側に示されたハイブリッド放送サービスの場合、上述した放送網を介したサービスとｅＭＢＭＳを介して提供されるサービスが、異なるネットワークを介して提供されるため、受信機は、各ネットワーク毎に独立してサービスを取得することができる。また、ネットワーク間の受信機がサービスを取得する手順も異なり得る。
【０８５４】
具体的には、本発明では、それぞれのネットワークで提供するコンテンツが異なる場合であって、放送会社（サービスプロバイダＡ）は、放送ネットワークを介してサービスを提供し、通信会社（サービスプロバイダＢ）は、移動通信ネットワークを介してサービスを提供する場合、又はそれぞれの放送コンテンツ業者が通信ネットワークに加入してサービスする場合を一実施例とすることができる。すなわち、放送ネットワークを用いてサービスする主体と、通信ネットワークを用いてサービスする主体とが異なるか、または放送データがユーザにまで伝達される前には別個のシステムを介して処理又は伝送される場合を意味する。この場合、放送サービスは、各ネットワーク別に分離されてユーザにまで処理、伝送されるので、受信機は、各ネットワークに対応するサービスを処理するためのモジュールを含むことができる。
【０８５５】
この場合、受信機は、２つのネットワークを介してそれぞれ異なるチャネル／プログラム情報を受信してユーザに提供することができる。この場合、放送網に送出されるサービスは、ＳＴＢを経て受信機に受信され得、シグナリング情報は、ＡＣＲスキームを用いて伝送され得る。したがって、受信機は、上述した方式を用いて放送と関連するシグナリング情報を取得することができる。しかし、ｅＭＢＭＳを介して受信されるチャネル又はプログラム情報は、受信機で直接受信することができるので、ＡＣＲスキームと関係なく適用可能である。
【０８５６】
図面の右側に示されたハイブリッド放送サービスの場合、各サービスプロバイダ（Ａ，Ｂ）が同じコンテンツを各ネットワークを介して同時に伝送するので、ハイブリッド放送サービスデータは、放送網とｅＭＢＭＳネットワークに伝達される前、ＩＰバックボーン（ＩＰ  ｂａｃｋｂｏｎｅ）網で適切に分離されてもよい。
【０８５７】
この場合、ハイブリッド放送サービスデータは、状況によって放送網及びｅＭＢＭＳネットワークを介して各受信機に伝送されてもよい。
【０８５８】
図面の右側に示されたハイブリッド放送サービスの場合、ユーザが放送データを受信するとき、どのシステムから伝送されるデータであるかを確認する必要がなく、既存の放送環境に比べて様々な放送会社及びコンテンツ提供業者から放送データを受信できるという利点がある。また、受信機の設計において、放送関連ＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ、ユーザインターフェース）を単一化して具現することができるので、設計が容易であるという利点がある。
【０８５９】
この場合、受信機は、互いに異なるネットワークを介して同じチャネル又はプログラムを受信することができ、ｅＭＢＭＳを介して当該チャネル又はプログラムに関するシグナリング情報を受信することができる。しかし、ｅＭＢＭＳネットワークを一時的又は永久的に使用できない場合、受信機は、ＳＴＢを介して入ってくるＡ／Ｖのみを受信することができ、ｅＭＢＭＳネットワークを利用できないことを確認することができる。このような場合、受信機は、上述したＡＣＲスキームを使用してシグナリング情報を受信することができる。シグナリングサーバーは、受信機にユニキャスト（ｕｎｉｃａｓｔ）又はマルチキャスト（ｍｕｌｔｉｃａｓｔ）方式を用いてシグナリング情報を伝送することができ、これは、上述した通りである。
【０８６０】
または、ｅＭＢＭＳネットワークを使用することができるとしても、ユーザが現在視聴している放送のＡ／ＶはＳＴＢを介して伝達される状況である場合、受信機は、現在視聴中の放送コンテンツとｅＭＢＭＳを介して受信したシグナリング情報とをマッピングすることができない。この場合、受信機は、ＡＣＲスキームを用いて現在視聴中の放送のチャネル又はプログラム情報などを認識し、これを通じて、ｅＭＢＭＳで受信するシグナリング情報を受信してサービスを提供することができる。
【０８６１】
また、モバイルブロードバンドを介してデータを受信する場合、受信機は、一般的なブロードバンドチャネルではなく、モバイルブロードバンドチャネル（Ｍｏｂｉｌｅ  ｂｒｏａｄｂａｎｄ  ｃｈａｎｎｅｌ）を介してシグナリング情報を送受信することもできる。これは、設計者意図によって変更可能な事項である。
【０８６２】
図７０は、本発明の他の実施例に係るモバイルネットワーク環境でのＡＣＲ送受信システムを示す。
【０８６３】
図７０は、上述したハイブリッド放送サービスの他の実施例であって、ＳＴＢが２つのネットワークを介してデータを受信し、外部入力などを介して当該データが受信機に伝達される場合を示す。
【０８６４】
図示のように、放送網を介して伝送される放送データは、ＳＴＢを介して最終的に受信機に伝達されてもよい。また、ＳＴＢは、ｅＭＢＭＳ−ｃａｐａｂｌｅな特性を有しているので、ｅＭＢＭＳを介して伝送される放送データを受信することができる。この場合、サービスプロバイダはＭＶＰＤの役割を行うことができる。
【０８６５】
したがって、放送網とｅＭＢＭＳを介して伝送されるＡ／Ｖ及び関連シグナリング情報は、いずれもＳＴＢを経て受信機に伝送されるので、受信機は、Ａ／Ｖのみをユーザに提供することができる。この場合、基本的なＡＣＲ環境と同一であるので、受信機は、ＡＣＲスキームを介して現在視聴中のチャネル／プログラムを認識した後、シグナリングサーバーからシグナリング情報を受信してサービスを提供することができる。具体的な内容は上述した通りであるので、省略する。
【０８６６】
本発明のＡＣＲスキームは、ＷＭ方式及びＦＰ方式の両方に適用可能である。また、ＷＭ方式の場合、サービスプロバイダによって伝送されるＡ／Ｖに挿入されたＷＭは、ＳＴＢを経て受信機に伝達されるとしてもフィルタリング（ｆｉｌｔｅｒｉｎｇ）されない。
【０８６７】
図７１は、本発明の一実施例に係る、次世代放送システムのためのプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）を示す図である。
【０８６８】
本発明に係る放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）中心ブロードキャストネットワーク（ＩＰ  ｃｅｎｔｒｉｃ  ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ）とブロードバンド（ｂｒｏａｄｂａｎｄ）とが結合されたハイブリッド放送システムに該当し得る。
【０８６９】
本発明に係る放送システムは、既存のＭＰＥＧ−２ベースの放送システムとの互換性が維持されるように設計することができる。
【０８７０】
本発明に係る放送システムは、ＩＰ中心ブロードキャストネットワーク（ＩＰ  ｃｅｎｔｒｉｃ  ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ）、ブロードバンド（ｂｒｏａｄｂａｎｄ）ネットワーク、及び／又は移動通信ネットワーク（ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｎｅｔｗｏｒｋ又はｃｅｌｌｕｌａｒ  ｎｅｔｗｏｒｋ）の結合に基づくハイブリッド放送システムに該当してもよい。
【０８７１】
同図を参照すると、物理層（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。例えば、本発明に係る物理層では、送／受信機は地上波放送信号を送信／受信し、放送データを含む伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）を適切な形態に変換することができる。
【０８７２】
暗号化（Ｅｎｃａｐｓｕｌａｔｉｏｎ）層では、物理層から取得した情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得したＩＰデータグラムを特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。例えば、暗号化層で送信機は、物理層で処理されたデータを伝送フレームに含めたり、受信機は、物理層から取得した伝送フレームからＭＰＥＧ−２  ＴＳ、ＩＰデータグラムを抽出する。
【０８７３】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツに接近可能にさせるための情報（例、サービスＩＤとフレームとのマッピング情報など）を含む。ＦＩＣはＦＡＣ（Ｆａｓｔ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）と命名されてもよい。
【０８７４】
本発明の放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＡＬＣ／ＬＣＴ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  ／  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（Ｒａｔｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  ／  ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタック（ｓｔａｃｋ）については同図に示す構造を参照すればよい。
【０８７５】
本発明の放送システムにおいてデータは、ＩＳＯＢＭＦＦ（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）の形態で伝送することができる。ＥＳＧ（Ｅｌｅｃｔｒｉｃａｌ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、ＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ  ／  Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。
【０８７６】
ブロードキャストネットワークによるデータの伝送は、線形コンテンツ（ｌｉｎｅａｒ  ｃｏｎｔｅｎｔ）の伝送及び／又は非線形コンテンツ（ｎｏｎ−ｌｉｎｅａｒ  ｃｏｎｔｅｎｔ）の伝送を含むことができる。
【０８７７】
ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ、データ（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｍｅｓｓａｇｅなど）の伝送は、線形コンテンツの伝送に該当し得る。
【０８７８】
ＲＴＰペイロードは、ＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ）が含まれたＲＴＰ／ＡＶストリーム形態及び／又はＩＳＯ  ｂａｓｅｄ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔで暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＲＴＰペイロードの伝送は線形コンテンツの伝送に該当し得る。ＩＳＯ  ｂａｓｅｄ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔで暗号化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧ  ＤＡＳＨ  ｍｅｄｉａ  ｓｅｇｍｅｎｔを含むことができる。
【０８７９】
ＦＬＵＴＥベースのＥＳＧの伝送、ｎｏｎ−ｔｉｍｅｄ  ｄａｔａの伝送、ＮＲＴ  ｃｏｎｔｅｎｔの伝送は、非線形コンテンツの伝送に該当し得る。それらは、ＭＩＭＥ  ｔｙｐｅのファイル形態及び／又はＩＳＯ  ｂａｓｅｄ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔで暗号化された形態で伝送されてもよい。ＩＳＯ  ｂａｓｅｄ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔで暗号化された形態の伝送はＡ／Ｖなどに対するＭＰＥＧ  ＤＡＳＨ  ｍｅｄｉａ  ｓｅｇｍｅｎｔを含むことができる。
【０８８０】
ブロードバンドネットワークによる伝送は、コンテンツに対する伝送とシグナリングデータに対する伝送とに区分して考えることができる。
【０８８１】
コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ、データ（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｍｅｓｓａｇｅなど）の伝送と非線形コンテンツ（ＥＳＧ、ｎｏｎ−ｔｉｍｅｄ  ｄａｔａなど）の伝送、ＭＰＥＧ  ＤＡＳＨベースのＭｅｄｉａ  ｓｅｇｍｅｎｔ（Ａ／Ｖ、ｄａｔａ）伝送を含む。
【０８８２】
シグナリングデータの伝送は、放送網で伝送されるシグナリングテーブル（ｓｉｇｎａｌｉｎｇ  ｔａｂｌｅ）（ＭＰＥＧ  ＤＡＳＨのＭＰＤを含む）を含む伝送が可能である。
【０８８３】
本発明の放送システムでは、放送網を介して送信された線形／非線形コンテンツ間の同期化、或いは放送網を介して伝送されるコンテンツとブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが放送網とブロードバンドで分離されて同時に伝送される場合、受信機は、伝送プロトコルに依存したタイムライン（ｔｉｍｅｌｉｎｅ）を調整し、放送網のコンテンツとブロードバンドのコンテンツとを同期化した後、一つのＵＤコンテンツとして再構成することができる。
【０８８４】
本発明の放送システムのアプリケーション層は、両方向性（Ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン（Ｓｅｃｏｎｄ  Ｓｃｒｅｅｎ）、ＡＣＲ（ａｕｔｏｍａｔｉｃ  ｃｏｎｔｅｎｔ  ｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特徴を具現することができる。このような特徴は、例えば、北米放送標準であるＡＴＳＣ２．０からＡＴＳＣ３．０への拡張において重要な特徴である。例えば、両方向性の特徴のために、ＨＴＭＬ５が用いられてもよい。
【０８８５】
本発明の放送システムのプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）層では、コンポーネント間又は両方向アプリケーション間の空間的、時間的関係を識別するためにＨＴＭＬ及び／又はＨＴＭＬ５が用いられてもよい。
【０８８６】
本発明でシグナリング（Ｓｉｇｎａｌｉｎｇ）は、コンテンツ及び／又はサービスの効果的な取得を支援するためのシグナリング情報を含む。シグナリングデータは、バイナリ或いはＸＭＬ形態などで表現することができ、地上波放送網或いはブロードバンドを介して伝達することができる。
【０８８７】
実時間放送Ａ／Ｖコンテンツ及び／又はデータの場合、ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔなどで表現することができる。この場合、放送Ａ／Ｖコンテンツ及び／又はデータは、地上波放送網を介して実時間で伝達されてもよく、ＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて非実時間で伝達されてもよい。又は、放送Ａ／Ｖコンテンツ及び／又はデータに対して、インターネット網を介してＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）などを用いて実時間でコンテンツのストリーミングを受けたり、要求して受けることができる。本発明の一実施例に係る放送システムは、このようにして受けた放送Ａ／Ｖコンテンツ及び／又はデータを組み合わせ、両方向性サービス、第２スクリーンサービスなどの様々なエンハンスドサービスを視聴者に提供することができる。
【０８８８】
図７２は、本発明の一実施例に係る、伝送フレーム（Ｔｒａｎｓｐｏｒｔ  Ｆｒａｍｅ）を示す図である。
【０８８９】
本発明の一実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）で伝達されるデータの集合を示す。
【０８９０】
本発明の一実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、共通ＰＬＰ（ｃｏｍｍｏｎ  ＰＬＰ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）を含むことができる。ここで、共通ＰＬＰを共通データユニットと命名してもよい。
【０８９１】
Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機はＰ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。
【０８９２】
Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）の構成に関する情報を含む。受信機はＬ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。
【０８９３】
共通ＰＬＰは、ＰＬＰｎに共通に適用されるサービス情報を含む。受信機は、共通ＰＬＰを通じてＰＬＰ間の共有すべき情報を取得することができる。伝送フレーム（Ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）の構造によって共通ＰＬＰが存在しなくてもよい。Ｌ１データは、伝送フレームに共通ＰＬＰが含まれるか否かを識別する情報を含むことができる。
【０８９４】
ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰで伝送されるかを識別する情報は、Ｌ１データ或いは共通ＰＬＰに含まれてもよい。
【０８９５】
補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、次世代放送システムで追加される変調方式、コーディング方式及び／又はデータ処理方式のためのデータを含むことができる。例えば、補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、新しく定義されるデータ処理方式を識別する情報を含むことができる。補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、将来拡張されるシステムによる、伝送フレームの拡張に用いられてもよい。
【０８９６】
図７３は、本発明の他の実施例に係る、伝送フレーム（Ｔｒａｎｓｐｏｒｔ  Ｆｒａｍｅ）を示す図である。
【０８９７】
本発明の他の実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）で伝達されるデータの集合を示す。
【０８９８】
本発明の他の実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）を含むことができる。
【０８９９】
Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機は、Ｐ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。
【０９００】
Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）の構成に関する情報を含む。受信機は、Ｌ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。
【０９０１】
ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）は、受信機が特定周波数内の放送サービス及びコンテンツに対するスキャンを速かに行えるようにするために、別のチャネルで定義されてもよい。このチャネルは、物理チャネル又は論理チャネルと定義されてもよく、このようなチャネルで放送サービスに関連した情報を伝送／受信することができる。
【０９０２】
本発明の他の実施例によれば、ＦＩＣを用いて、伝送フレームに含まれた放送サービス及び／又はコンテンツとこれに関連した情報を受信機が速かに取得することができる。これと加えて、当該伝送フレームに、一つ以上の放送局で生成したサービス／コンテンツが存在する場合、受信機はＦＩＣを用いて、放送局によるサービス／コンテンツを認知して処理することができる。
【０９０３】
ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰに伝送されるかを識別する情報がＬ１データ或いは共通ＰＬＰに含まれてもよい。
【０９０４】
補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、次世代放送システムで追加される変調方式、コーディング方式及び／又はデータ処理方式のためのデータを含むことができる。例えば、補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、新しく定義されるデータ処理方式を識別する情報を含むことができる。補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）は、将来拡張されるシステムによる、伝送フレームの拡張に用いられてもよい。
【０９０５】
図７４は、本発明の一実施例に係る、放送システムのＴＰ（Ｔｒａｎｓｐｏｒｔ  Ｐａｃｋｅｔ）及びｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。
【０９０６】
放送システムのＴＰは、Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報、Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報、Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報、Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報、Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報及び／又はペイロード（Ｐａｙｌｏａｄ）を含むことができる。
【０９０７】
Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報は、図示のように、ＴＰのペイロードがどのネットワークプロトコルタイプを有するかを示す。
【０９０８】
Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰに誤りが検出されたか否か表示する情報である。例えば、当該情報の値が０であれば、誤りが検出されていないことを示し、１であれば、誤りが検出されたことを示すことができる。
【０９０９】
Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰにスタッフィングバイト（ｓｔｕｆｆｉｎｇ  ｂｙｔｅ）が含まれているか否かを示す。例えば、当該情報の値が０であれば、スタッフィッグバイトを含んでいないことを示し、１である場合、ペイロードの前に長さフィールド（ｌｅｎｇｔｈ  ｆｉｅｌｄ）とスタッフィッグバイトを含むことを示すことができる。
【０９１０】
Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報は、当該ＴＰのペイロード部分に新しいネットワークプロトコルパケットの開始部分を表示する。例えば、当該情報は、Ｔｈｅ  ｍａｘｉｍｕｍ  ｖａｌｕｅ（０ｘ７ＦＦ）を有することによって、新しいネットワークプロトコルパケットの開始部分がないことを示すことができる。当該情報が他の値を有する場合、ヘッダーの最後の部分から新しいネットワークプロトコルパケットの開始部分までのオフセット値に該当し得る。
【０９１１】
Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報は、ｓｔｕｆｆｉｎｇ＿ｉｎｄｉｃａｔｏｒ情報の値が１のとき、ヘッダー（ｈｅａｄｅｒ）とペイロードとの間を埋める値である。
【０９１２】
ＴＰのペイロードはＩＰデータグラムを含むことができる。このような形態のＩＰデータグラムは、ＧＳＥ（Ｇｅｎｅｒｉｃ  Ｓｔｒｅａｍ  Ｅｎｃａｐｓｕｌａｔｉｏｎ）などを用いて暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）され、伝送されてもよい。伝送される特定ＩＰデータグラムは、受信機がサービス／コンテンツをスキャンし、これを取得するために必要なシグナリング情報を含むことができる。
【０９１３】
図７５は、本発明の一実施例に係る、放送サーバー及び受信機を示す図である。
【０９１４】
本発明の一実施例に係る受信機は、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）Ｊ１０７０２０、アプリケーションマネジャー（Ａｐｐｌｉｃａｔｉｏｎ  Ｍａｎａｇｅｒ）Ｊ１０７０３０、ダウンロードマネジャー（Ｄｏｗｎｌｏａｄ  Ｍａｎａｇｅｒ） Ｊ１０７０６０、装置保存所（Ｄｅｖｉｃｅ  Ｓｔｏｒａｇｅ）Ｊ１０７０７０、及び／又はアプリケーションデコーダ（Ａｐｐｌｉｃａｔｉｏｎ  Ｄｅｃｏｄｅｒ）Ｊ１０７０８０を含む。放送サーバーは、コンテンツプロバイダ／放送会社（Ｃｏｎｔｅｎｔ  Ｐｒｏｖｉｄｅｒ  ／  Ｂｒｏａｄｃａｓｔｅｒ）Ｊ１０７０１０及び／又はアプリケーションサービスサーバー（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｓｅｒｖｅｒ）Ｊ１０７０５０を含む。
【０９１５】
放送サーバー又は受信機に含まれるそれぞれの装置は、ハードウェア又はソフトウェアによって具現することができる。各装置がハードウェアによって具現される場合、‘マネジャー’のような表現は‘プロセッサ’に代替してもよい。
【０９１６】
コンテンツプロバイダ／放送会社Ｊ１０７０１０は、コンテンツプロバイダ或いは放送会社を意味する。
【０９１７】
シグナリングパーサーＪ１０７０２０は、コンテンツプロバイダ或いは放送会社で提供する放送信号をパースするモジュールである。放送信号は、シグナリングデータ／エレメント、放送コンテンツデータ、放送と関連した付加データ及び／又はアプリケーションデータを含むことができる。
【０９１８】
アプリケーションマネジャーＪ１０７０３０は、放送信号にアプリケーションが含まれた場合、当該アプリケーションを管理するモジュールである。アプリケーションマネジャーＪ１０７０３０は、前述したシグナリング情報、シグナリングエレメント、ＴＰＴ及び／又はトリガーを用いて、アプリケーションの位置、動作、動作実行タイミングを制御する。ここで、アプリケーションの動作は、Ａｃｔｉｖａｔｅ（Ｌａｕｎｃｈ）、Ｓｕｓｐｅｎｄ、Ｒｅｓｕｍｅ、又はＴｅｒｍｉｎａｔｅ（Ｅｘｉｔ）であってもよい。
【０９１９】
アプリケーションサービスサーバーＪ１０７０５０は、アプリケーションを提供するサーバーである。アプリケーションサービスサーバーＪ１０７０５０は、コンテンツプロバイダ或いは放送会社によって提供されてもよく、この場合、コンテンツプロバイダ／放送会社Ｊ１０７０１０に含まれてもよい。
【０９２０】
ダウンロードマネジャーＪ１０７０６０は、コンテンツプロバイダ／放送会社Ｊ１０７０１０及び／又はアプリケーションサービスサーバーＪ１０７０５０で提供するＮＲＴコンテンツ又はアプリケーションに関連した情報を処理するモジュールである。ダウンロードマネジャーＪ１０７０６０は、放送信号に含まれたＮＲＴ関連シグナリング情報を取得し、シグナリング情報に基づいて、放送信号に含まれたＮＲＴコンテンツを抽出する。ダウンロードマネジャーＪ１０７０６０は、アプリケーションサービスサーバーＪ１０７０５０が提供するアプリケーションを受信処理することができる。
【０９２１】
装置保存所Ｊ１０７０７０は、受信した放送信号、データ、コンテンツ及び／又はシグナリング情報（シグナリングエレメント）を保存することができる。
【０９２２】
アプリケーションデコーダＪ１０７０８０は、受信したアプリケーションをデコードし、画面に表出する処理を行うことができる。
【０９２３】
図７６は、本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ及びサービスタイプ間の付加サービス関係と共に、別個のサービスタイプを示す図である。
【０９２４】
線形サービスは、一般的にＴＶに伝達し、また、ビデオデコーディング／ディスプレイキャパビリティ（オーディオのみ）を有しない受信装置に適したサービスに用いることができる。線形サービスは、単一タイムベースを有し、ゼロ以上の提示可能（ｐｒｅｓｅｎｔａｂｌｅ）ビデオコンポーネント、ゼロ以上の提示可能オーディオコンポーネント、及びゼロ以上の提示可能ＣＣコンポーネントを有することができる。線形サービスはまた、ゼロ以上のアプリケーションベースエンハンスメントを有することができる。
【０９２５】
アプリケーションクラスは、ＡＴＳＣアプリケーションのためのコンテンツアイテム（又は、データアイテム）を示す。関係は、コンテンツアイテム（又は、データアイテム）クラスとのサブクラス関係を含む。
【０９２６】
アプリケーションベースエンハンスメントクラスは、ＴＶサービス（又は、線形サービス）に対するアプリケーションベースエンハンスメントを示す。属性は、必須キャパビリティ［０．．１］、非必須キャパビリティ［０．．１］、ターゲット装置［０．．ｎ］を含み、可能な値は“プライマリ装置”、“コンパニオン装置”を含む。
【０９２７】
関係は、アプリケーションクラスとの“包含（Ｃｏｎｔａｉｎｓ）”関係、コンテンツアイテム（又は、データアイテム）コンポーネントクラスとの“包含”関係、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）ストリームクラスとの“包含”関係及び／又はオンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの“包含”関係を含むことができる。
【０９２８】
タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。タイムベースは以下の属性を含むことができる。
【０９２９】
クロックレートは、このタイムベースのクロックレートを示す。
【０９３０】
アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。関係は、アプリケーションベースエンハンスメントクラスとの“包含”関係及び／又はサービスクラスとの“サブクラス”関係を含むことができる。
【０９３１】
アプリケーションベースエンハンスメントは、次のものを含むことができる。
取るアクションの通知を伝達する通知ストリーム
一つ以上のアプリケーション（アプリ）
アプリによって用いられるゼロ以上の他のコンテンツアイテム（又は、データアイテム、ＮＲＴコンテンツアイテム）
アプリによって管理されるゼロ以上のオンデマンドコンポーネント
【０９３２】
アプリケーションベースエンハンスメント内のアプリのうちのゼロ又は一つがプライマリアプリとして指定されてもよい。指定されたプライマリアプリが存在すれば、それの属するサービスが選択されるやいなや活性化される。アプリはまた、通知ストリーム内の通知によって活性化されたり、一つのアプリが既に活性化された他のアプリによって活性化されてもよい。
【０９３３】
アプリケーションベースのサービスは、一つ以上のアプリケーションベースエンハンスメントを含むサービスである。アプリケーションベースのサービス内の一つのアプリケーションベースエンハンスメントは、指定されたプライマリアプリを含むことができる。アプリケーションベースのサービスは選択的にタイムベースを含むことができる。
【０９３４】
アプリは、コンテンツアイテム（又は、データアイテム）の特殊な場合、すなわち、共にアプリを構成するファイルの集合（ｃｏｌｌｅｃｔｉｏｎ）である。
【０９３５】
図７７は、本発明の実施例として、ＮＲＴコンテンツアイテムクラス及びＮＲＴファイルクラス間の包含関係を示す。
【０９３６】
ＮＲＴコンテンツアイテムは一つ以上のＮＲＴファイルを含み、ＮＲＴファイルは一つ以上のＮＲＴコンテンツアイテムに属することができる。
【０９３７】
それらのクラスを検討する一方法は、ＮＲＴコンテンツアイテムが基本的に提示可能ＮＲＴファイルベースコンポーネント、すなわち、他のファイルと結合しないで消費されてもよいＮＲＴファイルセットであってもよく、ＮＲＴファイルが基本的にエレメンタリＮＲＴファイルベースコンポーネント、すなわち、原子単位のコンポーネントであってもよいということである。
【０９３８】
ＮＲＴコンテンツアイテムは、連続したコンポーネント、不連続したコンポーネント、又はその組合せを含むことができる。
【０９３９】
図７８は、本発明の一実施例に係る、サービスタイプ及びコンポーネントタイプによる属性を示すテーブルである。
【０９４０】
アプリケーション（Ａｐｐ）は、両方向性を支援するＮＲＴコンテンツアイテムの一種である。アプリケーションの属性は、ＴＰＴなどのようなシグナリングデータによって提供されてもよい。アプリケーションは、ＮＲＴコンテンツアイテムクラスとはサブクラスの関係にある。例えば、ＮＲＴコンテンツアイテムには一つ以上のアプリケーションが含まれてもよい。
【０９４１】
アプリケーションベースエンハンスメント（Ａｐｐ−Ｂａｓｅｄ  Ｅｎｈａｎｃｅｍｅｎｔ）は、アプリケーションベースに向上したイベント／コンテンツのことをいう。
【０９４２】
アプリケーションベースエンハンスメントの属性には、次の内容が含まれてもよい。
【０９４３】
必須キャパビリティ［０．．１］−エンハンスメントの意味のあるレンディション（ｒｅｎｄｉｔｉｏｎ）に必要な受信機キャパビリティ。
【０９４４】
非必須キャパビリティ［０．．１］−エンハンスメントの最上のレンディションに有用であるが、エンハンスメントの意味のあるレンディションに必須のものではない受信機キャパビリティ。
【０９４５】
ターゲット装置［０．．ｎ］−単に付加（ａｄｊｕｎｃｔ）データサービスのために可能な値。
【０９４６】
ターゲットデバイスは、プライマリデバイスとコンパニオン（ｃｏｍｐａｎｉｏｎ）デバイスとに区別することができる。プライマリデバイスとしてはＴＶ受信機のような装置を含むことができる。コンパニオンデバイスとしては、スマートフォン、タブレット、ノートパソコン及び／又は小型モニタを含むことができる。
【０９４７】
アプリケーションベースエンハンスメントは、Ａｐｐクラスとの関係を含み、これはアプリケーションベースエンハンスメントに含まれるアプリケーションとの関係のためのものであろう。
【０９４８】
アプリケーションベースエンハンスメントは、ＮＲＴコンテンツアイテムクラスとの関係を含み、これは、アプリケーションベースエンハンスメントに含まれるアプリケーションによって用いられるＮＲＴコンテンツアイテムとの関係のためのものである。
【０９４９】
アプリケーションベースエンハンスメントは、通知ストリーム（Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｔｒｅａｍ）クラスとの関係を含み、これは、アプリケーションの動作と基本線形（Ｌｉｎｅａｒ）タイムベースとの同期化のための通知を送信する通知ストリームとの関係のためのものである。
【０９５０】
アプリケーションベースエンハンスメントは、オンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの関係を含み、これは、アプリケーションによって管理される視聴者要求コンポーネントとの関係のためのものである。
【０９５１】
図７９は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
【０９５２】
タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。
【０９５３】
タイムベースの属性は、タイムベースＩＤ及び／又はクロックレートを含むことができる。
【０９５４】
タイムベースＩＤは、タイムベースの識別子である。クロックレートはタイムベースのクロックレートに対応する。
【０９５５】
図８０は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
【０９５６】
線形サービスは、線形サービスを示す。
【０９５７】
線形サービスは、属性がビデオコンポーネントの役割である提示可能ビデオコンポーネントクラスとの関係を含む関係を有する。ビデオコンポーネントの役割は、プライマリ（デフォルト）ビデオ、代案カメラビュー（ａｌｔｅｒｎａｔｉｖｅ  ｃａｍｅｒａ  ｖｉｅｗ）、他の代案ビデオコンポーネント、手話（ｓｉｇｎ  ｌａｎｇｕａｇｅ）（すなわち、ＡＳＬ）インセット（ｉｎｓｅｔ）、又はフォローサブジェクト特徴（ｆｏｌｌｏｗ−ｓｕｂｊｅｃｔ  ｆｅａｔｕｒｅ）が個別ビデオコンポーネントによって支援される場合に、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示す可能な値を有することができる。
【０９５８】
線形サービスの関係は、提示可能オーディオコンポーネントクラスとの関係、提示可能ＣＣコンポーネントクラスとの関係、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係、及び／又はサービスクラスとの“サブクラス”関係を含む。
【０９５９】
アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。
【０９６０】
アプリケーションベースのサービスは、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係及び／又はサービスクラスとの“サブクラス”関係を含む関係を有する。
【０９６１】
図８１は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
【０９６２】
プログラムは、プログラムを示す。
【０９６３】
プログラムの属性は、ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ、ＳｔａｒｔＴｉｍｅ、ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ、ＴｅｘｔｕａｌＴｉｔｌｅ、ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ、Ｇｅｎｒｅ、ＧｒａｐｈｉｃａｌＩｃｏｎ、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ、ターゲッティング／個人化特性、コンテンツ／サービス保護特性、及び／又は“ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）モデル”と定義された他の特性を含む。
【０９６４】
ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ［１］は、プログラムの固有識別子に対応する。
【０９６５】
ＳｔａｒｔＴｉｍｅ［１］は、プログラムが始まるようにスケジュールされた実測日時及び時間（ｗａｌｌ  ｃｌｏｃｋｄａｔｅ  ａｎｄ  ｔｉｍｅ）に対応する。
【０９６６】
ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ［１］は、プログラムの開始からプログラムの終了までのスケジュールされた実測時間（ｗａｌｌ  ｃｌｏｃｋ  ｔｉｍｅ）に対応する。
【０９６７】
ＴｅｘｔｕａｌＴｉｔｌｅ［１．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能タイトル−存在しないなら、関連したショーのＴｅｘｔｕａｌＴｉｔｌｅに対するデフォルト−に対応する。
【０９６８】
ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ［０．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能説明−存在しないなら、関連したショーのＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎに対するデフォルト−に対応する。
【０９６９】
Ｇｅｎｒｅ［０．．ｎ］は、プログラムのジャンル-存在しないなら、関連したショーのジャンルに対するデフォルト−に対応する。
【０９７０】
ＧｒａｐｈｉｃａｌＩｃｏｎ［０．．ｎ］は、複数のサイズからなる（例えば、ＥＳＧにおいて）プログラムを示すアイコン−存在しないなら、関連したショーのＧｒａｐｈｉｃａｌＩｃｏｎに対するデフォルト−に対応する。
【０９７１】
ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ［０．．ｎ］は、複数の領域に対してプログラムに対するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティング−存在しないなら、関連したショーのＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇに対するデフォルト−に対応する。
【０９７２】
ターゲッティング／個人化特性は、プログラムのターゲッティングなどを決定するために用いられる特性−存在しないなら、関連したショーのターゲッティング／個人化特性に対するデフォルト−に対応する。
【０９７３】
コンテンツ／サービス保護特性は、プログラムのコンテンツ保護及び／又はサービス保護に用いられる特性−存在しないなら、関連したショーのコンテンツ／サービス保護に対するデフォルト−に対応する。
【０９７４】
プログラムは、次のものを含む関係を有することができる。
線形サービスクラスとの“ＰｒｏｇｒａｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＣｏｎｔｅｎｔＩｔｅｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＯｎＤｅｍａｎｄＣｏｍｐｏｎｅｎｔＯｆ”関係、提示可能ビデオコンポーネントクラスとの“包含”関係、提示可能オーディオコンポーネントクラスとの“包含”関係、提示可能ＣＣコンポーネントクラスとの“包含”関係、アプリケーションベースエンハンスメントクラスとの“包含”関係、タイムベースクラスとの“包含”関係、ショークラスとの“Ｂａｓｅｄ−ｏｎ”関係、及び／又はセグメントクラスとの“包含”関係。
【０９７５】
提示可能ビデオコンポーネントクラスとの“包含”関係は、可能な値がプライマリ（デフォルト）ビデオ、代案カメラビュー、他の代案ビデオコンポーネント、手話（例えば、ＡＳＬ）インセット及び／又はフォローサブジェクト特徴が個別ビデオコンポーネントによって支援される場合、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示すビデオコンポーネントの役割を含む属性を有することができる。
【０９７６】
セグメントクラスとの“包含”関係の属性は、プログラムの開始に対してセグメントの開始時間を特定するＲｅｌａｔｉｖｅＳｅｇｍｅｎｔＳｔａｒｔＴｉｍｅを有することができる。
【０９７７】
ＮＲＴコンテンツアイテムコンポーネントは、プログラムと同じ構造を有することができるが、ストリーミング形態よりはファイルの形態で伝達されればよい。このようなプログラムはそれと関連したインタラクティブサービスなどの付加（ａｄｊｕｎｃｔ）データサービスを有することができる。
【０９７８】
図８２は、本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄコンテンツに対する定義を示す。
【０９７９】
将来のハイブリッド放送システムは、サービスのタイプに対する線形サービス及び／又はアプリケーションベースのサービスを有することができる。線形サービスがスケジュールによって提示される連続したコンポーネント及び放送で定義されるタイムベースで構成されると、線形サービスは、トリガーされたアプリケーションエンハンスメントを有することができる。
【０９８０】
指示されたように、現在定義された提示可能コンテンツコンポーネントと共に、次のタイプのサービスが定義される。他のサービスタイプ及びコンポーネントが定義されてもよい。
【０９８１】
線形サービスは（様々なタイプのタイムシフト視聴メカニズムが消費者によって使われて消費時間をシフトできることを除けば）、プライマリコンテンツがスケジュールによって消費される連続コンポーネント及び放送によって定義されたタイムベースで構成されるサービスである。
【０９８２】
ゼロ以上のビデオコンポーネント
ゼロ以上のオーディオコンポーネント
ゼロ以上のクローズドキャプションコンポーネント
コンポーネントを同期化するために用いられるタイムベース
ゼロ以上のトリガーされたアプリケーションベースエンハンスメント及び／又はゼロ以上の自動開始(launching)アプリケーションベースエンハンスメント。
【０９８３】
ゼロ以上のトリガーされたアプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、開始されてサービスの一部として伝達された活性化通知によって同期化された方式でアクションを行うようにするアプリケーションで構成される。エンハンスメントコンポーネントは、次のものを含むことができる。
活性化通知のストリーム
通知のターゲットである一つ以上のアプリケーション
ゼロ以上のコンテンツアイテム、及び／又は
ゼロ以上のオンデマンドコンポーネント
【０９８４】
選択的に、アプリの一つは、“プライマリアプリ”として指定されてもよい。指定されたプライマリアプリが存在すると、根源的なサービスが選択されるやいなや活性化されてもよい。他のアプリは、通知ストリーム内の通知によって活性化されたり、アプリが既に活性化された他のアプリによって活性化されてもよい。
【０９８５】
ゼロ以上の自動開始アプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、サービスが選択される度に自動で開始されるアプリで構成される。エンハンスメントコンポーネントは次のものを含むことができる。
自動開始されたアプリケーション
ゼロ以上の活性化通知のストリーム、及び／又は
ゼロ以上のコンテンツアイテム。
【０９８６】
ここで、線形サービスは、自動開始されたアプリケーションベースエンハンスメント及びトリガーされたアプリケーションベースエンハンスメント、例えば、自動開始されたアプリケーションベースエンハンスメントを有し、対象となるアド（広告）挿入及びトリガーされたアプリケーションベースエンハンスメントを行って、インタラクティブ視聴経験を提供することができる。
【０９８７】
アプリケーションベースのサービスは、サービスが選択される度に指定されたアプリケーションが開始されるサービスである。これは、アプリケーションベースのサービス内のアプリケーションベースエンハンスメントが指定されたプライマリアプリを含むという制限を有する一つのアプリケーションベースエンハンスメントで構成されてもよい。
【０９８８】
アプリは、コンテンツアイテムの特殊な場合であってもよく、すなわち、アプリサービスコンポーネントを共に構成するファイルの集合が複数のサービス間で共有されてもよい。
【０９８９】
アプリケーションベースのサービス内のアプリケーションは、オンデマンドコンテンツの提示を開始することができる。
【０９９０】
パッケージングされたアプリケーションを有する自動開始アプリケーションベースのサービスの概念の併合に関するいくつかのアプローチが存在する。これは、任意の形態でサービスガイドに現れてもよい。将来ＴＶセットは、次の特徴を有することができる。
【０９９１】
ユーザは、サービスガイド内の自動開始アプリケーションベースのサービスを選択して“選好”サービスとして指定したり、そのサービス又はそのようなものを“取得”することができる。これは、サービスの基礎を形成するアプリがダウンロードされ、ＴＶセットに設置されるようにすることができる。すると、ユーザは、“選好”又は“取得された”アプリを見ることを要求することができ、ダウンロードされて設置されたアプリを全て示しながら、スマートフォン上にあるものと類似のディスプレイを得ることができる。すると、ユーザは、その中から実行されるものを選択できる。この効果は、サービスガイドがアプリストアと類似に動作することである。
【０９９２】
及び／又は、任意のアプリが“選好”／“取得された”サービスとして自動開始アプリケーションベースのサービスを識別するようにするＡＰＩが存在してもよい。（このようなＡＰＩの具現は、ユーザへの“確実ですか”というクエリーを含み、不良アプリ（ｒｏｇｕｅ  ａｐｐ）がユーザの知らないうちに（ｂｅｈｉｎｄ  ｕｓｅｒ’ｓ  ｂａｃｋ）それを行うことを防ぐことができる。これは、“パッケージされたアプリ”を設置することに当たる効果を有することができる。
【０９９３】
それぞれのサービスは、（コンテンツに対応する）コンテンツアイテムを含むことができる。コンテンツアイテムは、統合された全体として消費されるように意図される一つ以上のファイルの集合である。オンデマンドコンテンツは、視聴者によって選択された時間に（一般に、アプリケーションによって提供されるユーザインターフェースを介して）提示されるコンテンツであり、このようなコンテンツは、連続したコンテンツ（例えば、オーディオ／ビデオ）又は非周期的コンテンツ（例えば、ＨＴＭＬページ又はイメージ）で構成されてもよい。
【０９９４】
図８３は、本発明の実施例として、Ｃｏｍｐｌｅｘ  Ａｕｄｉｏ  Ｃｏｍｐｏｎｅｎｔの例を示す。
【０９９５】
提示可能オーディオコンポーネントは、完璧なメインコンポーネントを含むＰｉｃｋＯｎｅコンポーネント及び音楽、ダイアログ及び混合されるエフェクトトラックを含むコンポーネントであってもよい。完璧なメインオーディオコンポーネント及び音楽コンポーネントは、別個のビットレートでエンコーディングによって構成されるエレメンタリコンポーネントを含むＰｉｃｋＯｎｅコンポーネントであるが、ダイアログ及びエフェクトコンポーネントはエレメンタリコンポーネントであってもよい。
【０９９６】
このアプローチは、サービスが直接サービスの提示可能コンポーネントだけを列挙した後、任意のコンプレックスコンポーネントのメンバーコンポーネントを階層的に列挙しようとするものより一層明瞭なピクチャを提供する。
【０９９７】
コンポーネントモデルの可能な無限反復（ｒｅｃｕｒｓｉｏｎ）を制限するために、次の制限が与えられてもよい。任意の連続したコンポーネントは、上位レベルがＰｉｃｋＯｎｅで構成され、中間レベルがコンポジットコンポーネントで構成され、下位レベルがＰｉｃｋＯｎｅコンポーネントで構成される３レベル階層に適合し得る。任意の特定連続コンポーネントは連続したコンポーネントが単純にエレメンタリコンポーネントであるヌルサブセットを含み、３個のレベル又はその任意のサブセットを含むことができる。
【０９９８】
図８４は、本発明の一実施例に係る、アプリケーションと関連した属性情報を示す図である。
【０９９９】
アプリケーションと関連した属性情報は、ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ情報を含むことができる。
【１０００】
本発明の一実施例によって追加され得るアプリケーションと関連した属性情報は、Ａｐｐｌｉｃａｔｉｏｎ  ＩＤ情報、Ａｐｐｌｉｃａｔｉｏｎ  ｖｅｒｓｉｏｎ情報、Ａｐｐｌｉｃａｔｉｏｎ  ｔｙｐｅ情報、Ａｐｐｌｉｃａｔｉｏｎ  ｌｏｃａｔｉｏｎ情報、Ｃａｐａｂｉｌｉｔｉｅｓ情報、Ｒｅｑｕｉｒｅｄ  ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｌｅｖｅｌ情報、Ｆｒｅｑｕｅｎｃｙ  ｏｆ  ｕｓｅ情報、Ｅｘｐｉｒａｔｉｏｎ  ｄａｔｅ情報、Ｄａｔａ  ｉｔｅｍ  ｎｅｅｄｅｄ  ｂｙ  ａｐｐｌｉｃａｔｉｏｎ情報、Ｓｅｃｕｒｉｔｙ  ｐｒｏｐｅｒｔｉｅｓ情報、Ｔａｒｇｅｔ  ｄｅｖｉｃｅｓ情報、及び／又はＣｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ情報を含むことができる。
【１００１】
Ａｐｐｌｉｃａｔｉｏｎ  ＩＤ情報は、アプリケーションを識別できる固有のＩＤを示す。
【１００２】
Ａｐｐｌｉｃａｔｉｏｎ  ｖｅｒｓｉｏｎ情報は、アプリケーションのバージョンを示す。
【１００３】
Ａｐｐｌｉｃａｔｉｏｎ  ｔｙｐｅ情報は、アプリケーションのタイプを示す。
【１００４】
Ａｐｐｌｉｃａｔｉｏｎ  ｌｏｃａｔｉｏｎ情報は、アプリケーションの位置を示す。例えば、Ａｐｐｌｉｃａｔｉｏｎ  ｌｏｃａｔｉｏｎ情報は、アプリケーションを受信できるＵＲＬを含むことができる。
【１００５】
Ｃａｐａｂｉｌｉｔｉｅｓ情報は、アプリケーションをレンダラ（ｒｅｎｄｅｒ）できるようにするキャパビリティ（ｃａｐａｂｉｌｉｔｙ）属性を示す。
【１００６】
Ｒｅｑｕｉｒｅｄ  ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｌｅｖｅｌ情報は、放送ストリーミングとアプリケーション間の同期化（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）レベル情報を示す。例えば、Ｒｅｑｕｉｒｅｄ  ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｌｅｖｅｌ情報は、プログラム或いはイベント単位、時間単位（例えば、２秒以内）、ｌｉｐ  ｓｙｎｃ、及び／又はフレームレベル同期などの内容を示すことができる。
【１００７】
Ｆｒｅｑｕｅｎｃｙ  ｏｆ  ｕｓｅ情報は、アプリケーションの使用頻度を示す。
【１００８】
Ｅｘｐｉｒａｔｉｏｎ  ｄａｔｅ情報は、アプリケーションの使用満了日／満了時刻を示す。
【１００９】
Ｄａｔａ  ｉｔｅｍ  ｎｅｅｄｅｄ  ｂｙ  ａｐｐｌｉｃａｉｏｎ情報は、アプリケーションで用いるデータ情報を示す。
【１０１０】
Ｓｅｃｕｒｉｔｙ  ｐｒｏｐｅｒｔｉｅｓ情報は、アプリケーションの保安関連情報を示す。
【１０１１】
Ｔａｒｇｅｔ  ｄｅｖｉｃｅｓ情報は、アプリケーションが用いられるターゲット装置情報を示す。例えば、ターゲット装置情報は、当該アプリケーションの実行されるターゲット機器がＴＶ及び／又はモバイル機器であることを示すことができる。
【１０１２】
Ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ情報は、アプリケーションの使用可能な等級を示す。例えば、Ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ情報は、アプリケーションを利用できる年齢制限情報を含むことができる。
【１０１３】
上述したアプリケーションベースのエンハンスメント（Ａｐｐ−ｂａｓｅｄ  ｅｎｈａｎｃｅｍｅｎｔ）或いはアプリケーションベースのサービス（Ａｐｐ−ｂａｓｅ  ｓｅｒｖｉｃｅ）で使用或いは実行できるアプリケーションは、サービスプロバイダ（放送局）が提供した放送関連アプリケーションに制限され得る。以下では、アプリケーションの属性及び動作性の制約事項について説明する。
【１０１４】
図８５は、本発明の一実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。
【１０１５】
本発明の一実施例に係るサービスプロバイダのアプリケーションは、アプリケーションタイプ（ｔｙｐｅ）などのような属性（ａｔｔｒｉｂｕｔｅ）の変更によってサードパーティーアプリケーション（３ｒｄ  Ｐａｒｔｙ  ａｐｐ）と同一の属性を有する放送と関連のないアプリケーションに移行（ｔｒａｎｓｉｔｉｏｎ）することができない。
【１０１６】
したがって、この場合、受信機は、アプリケーションの属性が変更されたか否かを確認し、変更された属性によってアプリケーションを実行するか否かを判断することができる。以下、図８５のフローチャートを説明する。
【１０１７】
サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８５０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８５１００に伝送することができる。
【１０１８】
受信機Ｅ８５１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎ  ｍａｎａｇｅｒ）が行うこともできる。
【１０１９】
その後、サービスプロバイダＥ８５０００は、アプリケーションの属性に対する変更事項をアップデートすることができる。受信機Ｅ８５１００又はアプリケーションマネジャーは、アプリケーションの属性の変更事項を確認することができる。
【１０２０】
もし、アプリケーション属性のうちアプリケーションタイプ属性がハイブリッド放送サービスと関連のないサードパーティーアプリケーションタイプに変更された場合、受信機Ｅ８５１００又はアプリケーションマネジャーは、実行中の放送関連アプリケーションを終了することができる。
【１０２１】
もし、アプリケーションタイプ以外の他の属性が変更された場合、受信機Ｅ８５１００又はアプリケーションマネジャーは、実行中の放送関連アプリケーションに変更された属性を適用し、続けて実行することができる。
【１０２２】
図８６は、本発明の他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。
【１０２３】
図８６は、実行中のサービスプロバイダの放送関連アプリケーションでチャネル情報がない（Ｎｕｌｌチャネル）チャネルに変更を試みる場合、誤りをリターンする受信機の動作を示す。以下、図８６のフローチャートを説明する。
【１０２４】
サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８６０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８６１００に伝送することができる。
【１０２５】
受信機Ｅ８６１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎ  ｍａｎａｇｅｒ）が行うこともできる。
【１０２６】
その後、現在実行中のアプリケーションで、ｓｅｔＣｈａｎｎｅｌ（‘ｎｕｌｌ’）のようなＡＰＩを用いてサードパーティーアプリケーションのような放送と関連するアプリケーションに転換を試みる場合、受信機Ｅ８８１００又はアプリケーションマネジャーは、ｓｅｔＣｈａｎｎｅｌ（‘ｎｕｌｌ’）要求に対して誤りをリターンし、以降の動作に対してアプリケーションが処理するようにしたり、実行中の放送関連アプリケーションを終了させることができる。
【１０２７】
図８７は、本発明の更に他の実施例に係るアプリケーション属性の変更がある場合の受信機の動作を示したフローチャートである。
【１０２８】
図８７は、サービスプロバイダの放送関連アプリケーションの実行中、アプリケーション内でサードパーティーアプリケーションのような放送と関連のないアプリケーションを実行する場合、受信機の動作を示す。この場合、受信機は、サービスプロバイダのアプリケーションのみを実行させたり、または政策によって放送と関連のないサードパーティーアプリケーションを実行させるようにすることができる。以下、図８７のフローチャートを説明する。
【１０２９】
サービスプロバイダ（放送会社又はコンテンツ提供者）Ｅ８７０００は、放送関連アプリケーションに対するシグナリング情報を受信機Ｅ８７１００に伝送することができる。
【１０３０】
受信機Ｅ８７１００は、シグナリング情報をパースし、当該アプリケーションを実行することができる。この場合、アプリケーションの実行は、受信機に含まれたアプリケーションマネジャー（ａｐｐｌｉｃａｔｉｏｎ  ｍａｎａｇｅｒ）が行うこともできる。
【１０３１】
その後、実行中の放送関連アプリケーションで、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ（）などのようなＡＰＩを用いて受信機で実行可能なアプリケーションリストを要求することができる。
【１０３２】
もし、ユーザ設定又は受信機政策によって、放送と関連のないサードパーティーアプリケーション（３ｒｄ  ｐａｒｔｙ  ａｐｐ）が許容される場合、受信機Ｅ８７１００又はアプリケーションマネジャーは、サードパーティーアプリケーションを含む全てのアプリケーションのリスト（ｌｉｓｔ）をリターンすることができる。この場合、実行中の放送関連アプリケーションは、放送と関連のないサードパーティーアプリケーションを実行させることができる。
【１０３３】
もし、ユーザ設定又は受信機政策によって、放送と関連のないサードパーティーアプリケーションが許容されない場合、受信機Ｅ８７１００又はアプリケーションマネジャーは、サードパーティーアプリケーションを除いたアプリケーションのリストをリターンすることができる。この場合、実行中の放送関連アプリケーションは、放送と関連のないサードパーティーアプリケーションのようなアプリケーションを実行させることができない。
【１０３４】
図８８は、本発明の一実施例に係るハイブリッド放送サービス処理のフローチャートである。
【１０３５】
図８８は、上述したマルチキャスト環境でのＡＣＲ受信装置がハイブリッド放送サービス）を処理する過程を示したフローチャートである。
【１０３６】
図示していないが、本発明の一実施例に係る受信機は、ハイブリッド放送サービスのための放送信号及びシグナリング情報を受信するための受信機（ｒｅｃｅｉｖｅｒ）、及びシグナリング情報と関連する要求（ｒｅｑｕｅｓｔ）を伝送するための送信機（ｔｒａｎｓｍｉｔｔｅｒ）を含むことができる。
【１０３７】
本発明の一実施例に係る受信機は、ハイブリッド放送サービスのための放送信号を受信することができる（ＥＳ８８０００）。上述したように、本発明の一実施例に係る放送信号受信機は、図１乃至図２９で説明した放送信号を受信、処理することができる。放送信号は、シグナリング情報に関するアドレス情報（ａｄｄｒｅｓｓ  ｉｎｆｏｒｍａｔｉｏｎ）を含む。シグナリング情報に関するアドレス情報は、ウォーターマーキングスキーム又はフィンガープリントスキームによって放送信号に挿入されてもよい。そして、シグナリング情報に関するアドレス情報は、ＡＣＲサーバーのアドレス（ＡＣＲ  ｓｅｒｖｅｒ  ａｄｄｒｅｓｓ）を指示することができる。詳細な内容は、図３０乃至図７０で説明した。
【１０３８】
本発明の一実施例に係る送信機は、シグナリング情報のためのリクエスト（ｒｅｑｕｅｓｔ）を伝送することができる（ＥＳ８８１００）。詳細な内容は、図３０乃至図７０で説明した。
【１０３９】
本発明の一実施例に係る受信機は、ユニキャスト方式、マルチキャスト方式及びｅＭＢＭＳ（ｅｖｏｌｖｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）方式のいずれか１つによるモバイルブロードバンド又はブロードバンドチャネルを介してシグナリング情報を受信することができる（ＥＳ８８２００）。詳細な内容は、図３０乃至図７０で説明した。
【１０４０】
図８９は、本発明の他の実施例に係るハイブリッド放送サービス処理のフローチャートである。
【１０４１】
図８９は、図８８で説明したハイブリッド放送サービスの処理において、アプリケーションを受信して処理する場合のアプリケーション属性の変更による受信機の動作を示す。
【１０４２】
本発明の一実施例に係るシグナリングパーサー又は受信装置は、ハイブリッド放送サービスのアプリケーションのシグナリング情報を受信することができる（ＥＳ８９０００）。シグナリング情報は、アプリケーション識別情報、アプリケーションバージョン情報及びアプリケーションアドレス情報を含むことができる。詳細な内容は、図７１乃至図８７で説明した。
【１０４３】
本発明の一実施例に係るアプリケーションマネジャー又は受信装置は、シグナリング情報を用いてアプリケーションを開始することができる（ＥＳ８９１００）。詳細な内容は、図７１乃至図８７で説明した。
【１０４４】
本発明の一実施例に係るシグナリングパーサー又は受信装置は、アプリケーションのアップデート情報を受信することができる（ＥＳ８９２００）。アップデート情報は、アプリケーションのタイプが変更されたか否かを示すアプリケーション属性情報を含むことができる。
【１０４５】
アプリケーション属性情報が、アプリケーションのタイプがハイブリッド放送サービスと関係のないアプリケーションタイプに変更されたことを示す場合、アプリケーションマネジャーは、開始されたアプリケーションを中断させることができる。
【１０４６】
または、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を使用することによってアプリケーション属性情報がハイブリッド放送サービスと関係のないアプリケーションタイプに変更される場合、アプリケーションマネジャーは、誤り応答を伝送したり、開始されたアプリケーションを中断させることができる。さらに、アプリケーションマネジャーは、使用可能なアプリケーションを示すリストに対するリクエストを受信することができ、リクエストによるリストを伝送することができる。詳細な内容は、図７１乃至図８７で説明した。
【１０４７】
本発明の思想や範囲から逸脱することなく本発明で様々な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付の特許請求の範囲及びその同等範囲内で提供される本発明の変更及び変形を含むものと意図される。
【１０４８】
本明細書で装置及び方法発明がいずれも言及されており、装置及び方法発明の両方の説明は互いに補完して適用されてもよい。
【実施の形態】
【１０４９】
様々な実施例が、本発明を実施するための形態において説明された。
【産業上の利用可能性】
【１０５０】
本発明は、一連の放送信号提供分野で利用される。
【１０５１】
本発明の思想や範囲から逸脱することなく本発明で様々な変更及び変形が可能であるということは当業者にとって自明である。したがって、本発明は、添付の特許請求の範囲及びその同等範囲内で提供される本発明の変更及び変形を含むものと意図される。
【図１】
0006474835.tif 000052
【図２】
0006474835.tif 000053
【図３】
0006474835.tif 000054
【図４】
0006474835.tif 000055
【図５】
0006474835.tif 000056
【図６】
0006474835.tif 000057
【図７】
0006474835.tif 000058
【図８】
0006474835.tif 000059
【図９】
0006474835.tif 000060
【図１０】
0006474835.tif 000061
【図１１】
0006474835.tif 000062
【図１２】
0006474835.tif 000063
【図１３】
0006474835.tif 000064
【図１４】
0006474835.tif 000065
【図１５】
0006474835.tif 000066
【図１６】
0006474835.tif 000067
【図１７】
0006474835.tif 000068
【図１８】
0006474835.tif 000069
【図１９】
0006474835.tif 000070
【図２０】
0006474835.tif 000071
【図２１】
0006474835.tif 000072
【図２２】
0006474835.tif 000073
【図２３】
0006474835.tif 000074
【図２４】
0006474835.tif 000075
【図２５】
0006474835.tif 000076
【図２６】
0006474835.tif 000077
【図２７】
0006474835.tif 000078
【図２８】
0006474835.tif 000079
【図２９】
0006474835.tif 000080
【図３０】
0006474835.tif 000081
【図３１】
0006474835.tif 000082
【図３２】
0006474835.tif 000083
【図３３】
0006474835.tif 000084
【図３４】
0006474835.tif 000085
【図３５】
0006474835.tif 000086
【図３６】
0006474835.tif 000087
【図３７】
0006474835.tif 000088
【図３８】
0006474835.tif 000089
【図３９】
0006474835.tif 000090
【図４０】
0006474835.tif 000091
【図４１】
0006474835.tif 000092
【図４２】
0006474835.tif 000093
【図４３】
0006474835.tif 000094
【図４４】
0006474835.tif 000095
【図４５】
0006474835.tif 000096
【図４６】
0006474835.tif 000097
【図４７】
0006474835.tif 000098
【図４８】
0006474835.tif 000099
【図４９】
0006474835.tif 000100
【図５０】
0006474835.tif 000101
【図５１】
0006474835.tif 000102
【図５２】
0006474835.tif 000103
【図５３】
0006474835.tif 000104
【図５４】
0006474835.tif 000105
【図５５】
0006474835.tif 000106
【図５６】
0006474835.tif 000107
【図５７】
0006474835.tif 000108
【図５８】
0006474835.tif 000109
【図５９】
0006474835.tif 000110
【図６０】
0006474835.tif 000111
【図６１】
0006474835.tif 000112
【図６２】
0006474835.tif 000113
【図６３】
0006474835.tif 000114
【図６４】
0006474835.tif 000115
【図６５】
0006474835.tif 000116
【図６６】
0006474835.tif 000117
【図６７】
0006474835.tif 000118
【図６８】
0006474835.tif 000119
【図６９】
0006474835.tif 000120
【図７０】
0006474835.tif 000121
【図７１】
0006474835.tif 000122
【図７２】
0006474835.tif 000123
【図７３】
0006474835.tif 000124
【図７４】
0006474835.tif 000125
【図７５】
0006474835.tif 000126
【図７６】
0006474835.tif 000127
【図７７】
0006474835.tif 000128
【図７８】
0006474835.tif 000129
【図７９】
0006474835.tif 000130
【図８０】
0006474835.tif 000131
【図８１】
0006474835.tif 000132
【図８２】
0006474835.tif 000133
【図８３】
0006474835.tif 000134
【図８４】
0006474835.tif 000135
【図８５】
0006474835.tif 000136
【図８６】
0006474835.tif 000137
【図８７】
0006474835.tif 000138
【図８８】
0006474835.tif 000139
【図８９】
0006474835.tif 000140