JP6189546B2 - 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置 - Google Patents

放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置 Download PDF

Info

Publication number
JP6189546B2
JP6189546B2 JP2016537968A JP2016537968A JP6189546B2 JP 6189546 B2 JP6189546 B2 JP 6189546B2 JP 2016537968 A JP2016537968 A JP 2016537968A JP 2016537968 A JP2016537968 A JP 2016537968A JP 6189546 B2 JP6189546 B2 JP 6189546B2
Authority
JP
Japan
Prior art keywords
data
application
content
pdi
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016537968A
Other languages
English (en)
Other versions
JP2017505564A (ja
Inventor
チンウォン リ
チンウォン リ
キョンソ ムン
キョンソ ムン
ウソク コ
ウソク コ
スンリュル ヤン
スンリュル ヤン
セチン オ
セチン オ
スンチュ アン
スンチュ アン
スンリョン ホン
スンリョン ホン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2017505564A publication Critical patent/JP2017505564A/ja
Application granted granted Critical
Publication of JP6189546B2 publication Critical patent/JP6189546B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/33—Arrangements for monitoring the users' behaviour or opinions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4755—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user preferences, e.g. favourite actors or genre
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4758—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for providing answers, e.g. voting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software

Description

本発明は、デジタル放送システムでアプリケーションを処理する方法及び装置に関する。特に、本発明は、デジタル放送システムにおいて、放送受信機のユーザにしたがって、アプリケーションを使用するか否かを設定することができる、デジタル放送信号の送信／受信処理方法及び処理装置に関する。
デジタル放送システムが導入されて以来、デジタル放送は、既存の放送局中心の放送から、視聴者中心の放送へと、そのサービスの方向が変わっている。
近年、標準化が行われているＡＴＳＣ２．０（次世代北米デジタル放送標準）では、放送プログラム／コンテンツに関連した追加のデータをユーザに提供できる方案を模索している。一方、放送プログラム／コンテンツに関連した追加のデータは、アプリケーション及び／又はＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）の形態で提供されてもよい。
しかしながら、アプリケーション又はＤＯは放送局から一方的に提供し、受信機のユーザは放送プログラム／コンテンツを視聴する場合、当該アプリケーション又はＤＯを常に消費すべき状況が発生するという問題点があった。
その上、アプリケーション又はＤＯを強制的に視聴する過程で、ユーザの個人情報が放送局又はコンテンツプロバイダに気付かずに伝達される場合が発生するという問題点もあった。
本発明が遂げようとする技術的課題は、前述した問題点を解決するためのものであり、デジタル放送システムの既存環境において、受信機でアプリケーションの使用を制御できるようにすることにある。
また、本発明が遂げようとする技術的課題は、デジタル放送システムの既存環境において、受信機でユーザの性向にしたがって、特定アプリケーションに対する使用を制御できるようにすることにある。
本発明は、放送コンテンツ及び前記放送コンテンツに関連したアプリケーションを含む放送信号を処理する受信機を提供する。受信機は、前記受信機によって回答可能な個別質問を示す質問表をカプセル化するデータ構造を受信する受信装置であって、前記データ構造が前記アプリケーションを一意に識別する第１アプリケーション識別子を含む、受信装置と、前記データ構造から前記質問表を取得し、前記アプリケーション識別子によって識別された前記アプリケーションに対するユーザの設定オプションを受信し、前記データ構造と関連して前記設定オプションを保存するＰＤＩエンジンと、前記アプリケーションの再生（ｐｌａｙｏｕｔ）のタイミングを確立するためのシグナリングエレメントであるトリガーをパースするアプリケーションシグナリングパーサーと、前記トリガーから第２アプリケーション識別子をパースし、前記第１アプリケーション識別子の値が前記第２アプリケーション識別子の値にマッチする前記データ構造と関連して前記保存された設定オプションを取得し、前記設定オプションに基づいて前記アプリケーションを起動する処理か否かを決定するプロセッサと、を含む。
好適には、前記トリガーは、前記アプリケーションを対象とするアプリケーション及び放送イベントに関するメタデータを含むＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）パラメータエレメントの位置を特定する位置情報を含む。
好適には、受信機は、前記位置情報によって識別された前記位置から前記ＴＤＯパラメータエレメントをパースするアプリケーションシグナリングパーサーをさらに含み、前記ＴＤＯパラメータエレメントは、前記アプリケーションに対する通知の上部マージンを特定する上部マージン情報、前記通知の右側マージンを特定する右側マージン情報、及び前記通知に対する持続時間を特定する持続情報を含む。
好適には、プロセッサはさらに、前記上部マージン情報、右側マージン情報及び持続情報に基づいて、前記ユーザから前記設定オプションを受信するユーザインターフェースをディスプレイする。
好適には、プロセッサはさらに、前記アプリケーションが活性化されるか否かに関する第１選択に対する質問を示すために前記ユーザインターフェースを処理する。
好適には、プロセッサはさらに、前記第１選択が現在の放送コンテンツ、現在のチャネル内の全放送コンテンツ又は全チャネル内の全放送コンテンツに適用されるかに関する第２選択に対する質問を示すために前記ユーザインターフェースを処理する。
好適には、ＴＤＯパラメータエレメントは、前記アプリケーションに対するレーティング（ｒａｔｉｎｇ）を特定するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）情報を含む。
また、本発明は、放送コンテンツ及び前記放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法を提供する。方法は、受信機によって回答可能な個別質問を示す質問表をカプセル化するデータ構造を受信するステップであって、前記データ構造が前記アプリケーションを一意に識別する第１アプリケーション識別子を含む、ステップと、前記データ構造から前記質問表を取得し、前記アプリケーション識別子によって識別された前記アプリケーションに対するユーザの設定オプションを受信し、前記データ構造と関連して前記設定オプションを保存するステップと、前記アプリケーションの再生のタイミングを確立するためのシグナリングエレメントであるトリガーをパースするステップと、前記トリガーから第２アプリケーション識別子をパースし、前記第１アプリケーション識別子の値が前記第２アプリケーション識別子の値にマッチする前記データ構造と関連して前記保存された設定オプションを取得し、前記設定オプションに基づいて前記アプリケーションを起動する処理か否かを決定するステップと、を含む。
好適には、前記トリガーは、前記アプリケーションを対象とするアプリケーション及び放送イベントに関するメタデータを含むＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）パラメータエレメントの位置を特定する位置情報を含む。
好適には、方法は、前記位置情報によって識別された前記位置から前記ＴＤＯパラメータエレメントをパースするステップをさらに含み、前記ＴＤＯパラメータエレメントは、前記アプリケーションに対する通知の上部マージンを特定する上部マージン情報、前記通知の右側マージンを特定する右側マージン情報、及び前記通知に対する持続時間を特定する持続情報を含む。
好適には、方法は、前記上部マージン情報、右側マージン情報及び持続情報に基づいて、前記ユーザから前記設定オプションを受信するユーザインターフェースをディスプレイするステップをさらに含む。
好適には、方法は、前記アプリケーションが活性化されるか否かに関する第１選択に対する質問を示すために前記ユーザインターフェースを処理するステップをさらに含む。
好適には、方法は、前記第１選択が現在の放送コンテンツ、現在のチャネル内の全放送コンテンツ又は全チャネル内の全放送コンテンツに適用されるかに関する第２選択に対する質問を示すために前記ユーザインターフェースを処理するステップをさらに含む。
好適には、ＴＤＯパラメータエレメントは、前記アプリケーションに対するレーティング（ｒａｔｉｎｇ）を特定するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）情報を含む。
本発明によれば、既存の放送システム環境で、受信機又はユーザが放送プログラム／コンテンツに関連したアプリケーション又はＤＯに対する使用を制御することができる。
本発明によれば、既存の放送システム環境で、受信機はユーザにしたがって、アプリケーション又はＤＯの使用を制御し、ユーザ便宜を向上させる効果がある。
本発明によれば、既存の放送システム環境で、アプリケーション又はＤＯによって不要なユーザの情報が収集されることを防止することができる。
本発明に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。 本発明の一実施例に係る入力フォーマッティングブロックを示す図である。 本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。 本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。 本発明の実施例に係るＢＩＣＭブロックを示す図である。 本発明の他の実施例に係るＢＩＣＭブロックを示す図である。 本発明の一実施例に係るフレーム生成ブロックを示す図である。 本発明の実施例に係るＯＦＭＤ生成ブロックを示す図である。 本発明の実施例によって将来の放送サービスのための放送信号を受信する装置の構造を示す図である。 本発明の実施例に係るフレーム構造を示す図である。 本発明の実施例に係るフレームのシグナリング階層構造を示す図である。 本発明の実施例に係るプリアンブルシグナリングデータを示す図である。 本発明の実施例に係るＰＬＳ１データを示す図である。 本発明の実施例に係るＰＬＳ２データを示す図である。 本発明の他の実施例に係るＰＬＳ２データを示す図である。 本発明の実施例に係るフレームの論理構造を示す図である。 本発明の実施例に係るＰＬＳマッピングを示す図である。 本発明の実施例に係るＥＡＣマッピングを示す図である。 本発明の実施例に係るＦＩＣマッピングを示す図である。 本発明の実施例に係るＤＰのタイプを示す図である。 本発明の実施例に係るＤＰマッピングを示す図である。 本発明の実施例に係るＦＥＣ構造を示す図である。 本発明の実施例に係るビットインターリービングを示す図である。 本発明の実施例に係るセル−ワードデマルチプレクシングを示す図である。 本発明の実施例に係る時間インターリービングを示す図である。 本発明の実施例に係るツイスト行−列ブロックインターリーバの基本動作を示す図である。 本発明の他の実施例に係るツイスト行−列ブロックインターリーバの動作を示す図である。 本発明の実施例に係るツイスト行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。 本発明の実施例に係る各インターリービングアレイからのインターリーブされたＸＦＥＣＢＬＯＣＫを示す図である。 本発明の実施例に係る次世代放送システム用プロトコルスタックを示す図である。 本発明の実施例に係る放送受信機を示す図である。 本発明の実施例に係る伝送フレームを示す図である。 本発明の他の実施例に係る伝送フレームを示す図である。 本発明の実施例に係る伝送パケット（ＴＰ）及び放送システムのｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。 本発明の実施例に係る放送サーバーと受信機を示す図である。 本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ、及びサービスタイプ間の付加（ａｄｊｕｎｃｔ）サービス関係に加え、別個のサービスタイプを示す図である。 本発明の実施例として、ＮＲＴコンテンツアイテムクラスとＮＲＴファイルクラスとの包含関係を示す図である。 本発明の実施例に係るサービスタイプ及びコンポーネントタイプに基づく属性を示すテーブルである。 本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。 本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。 本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す図である。 本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄ Ｃｏｎｔｅｎｔに対する定義を示す図である。 本発明の実施例として、Ｃｏｍｐｌｅｘ Ａｕｄｉｏ Ｃｏｍｐｏｎｅｎｔの例を示す図である。 本発明の実施例に係るアプリケーションに関連した属性情報を示す図である。 本発明の実施例に係る放送個人化手続きを示す図である。 本発明の実施例に係るアプリケーション別ユーザ設定のためのシグナリング構造を示す図である。 本発明の他の実施例に係るアプリケーション別ユーザ設定のためのシグナリング構造を示す図である。 本発明の実施例に係るＰＤＩテーブルを用いてアプリケーションのｏｐｔ−ｉｎ／ｏｕｔ設定手続きを示す図である。 本発明の実施例に係るアプリケーションのｏｐｔ−ｉｎ／ｏｕｔ設定のためのユーザインターフェース（ＵＩ）を示す図である。 本発明の実施例によって、受信機（ＴＶ）がＰＤＩテーブルを用いてアプリケーションのｏｐｔ−ｉｎ／ｏｕｔ設定を完了した後、サービスプロバイダから同一のアプリケーションＩＤを有するアプリケーションのトリガーを受信する場合の処理手続きを示す図である。 本発明の実施例によってユーザ別アプリケーションのオプションを設定するＵＩ及びそれに対する質問を示す図である。 自動コンテンツ認識ベースのＥＴＶ（ｅｎｈａｎｃｅｄ ｔｅｌｅｖｉｓｉｏｎ）サービスシステムを示す図である。 本発明の一実施例に係るデジタルウォーターマーキング技術の流れを示す図である。 本発明の一実施例に係る自動コンテンツ認識クエリー結果フォーマットを示す図である。 本発明の一実施例に係るコンテンツ識別子（ＩＤ）の構文を示す図である。 本発明の一実施例に係る受信機の構造を示す図である。 本発明の更に他の実施例に係る受信機の構造を示す図である。 本発明の一実施例に係るデジタル放送システムを示す図である。 本発明の一実施例に係るデジタル放送システムを示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の一実施例に係るＰＤＩテーブルを示す図である。 本発明の他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。 本発明の一実施例に係るフィルタリング基準テーブルを示す図である。 本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。 本発明の更に他の実施例に係るフィルタリング基準テーブルを示す図である。 本発明の更に他の実施例に係るフィルタリング基準テーブルを示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の一実施例に係るＰＤＩテーブルセクションを示す図である。 本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。 本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。 本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。 本発明の他の実施例に係るＦＤＴ場合のＸＭＬスキーマを示す図である。 本発明の一実施例に係るケイパビリティ記述子構文を示す図である。 本発明の一実施例に係る消費モデルを示す図である。 本発明の一実施例に係るフィルタリング基準記述子構文を示す図である。 本発明の他の実施例に係るフィルタリング基準記述子構文を示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の一実施例に係るＨＴＴＰ要求テーブルを示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の一実施例に係るＵＲＬリストテーブルを示す図である。 本発明の一実施例に係るＴＰＴを示す図である。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の更に他の実施例に係るデジタル放送システムのフローチャートである。 本発明の一実施例に係る受信機ターゲット基準テーブルを示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。 本発明の一実施例に係るアプリケーションプログラミングインターフェース（ＰＤＩ ＡＰＩ）を示す図である。 本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。 本発明の更に他の実施例に係るＰＤＩ ＡＰＩを示す図である。 本発明の一実施例に係る、ユーザーデータ（Ｕｓｅｒ Ｄａｔａ）を交換する際に受信機とコンパニオン装置（Ｃｏｍｐａｎｉｏｎ Ｄｅｖｉｃｅ）との関係を示す図である。 本発明の他の実施例に係る、ＰＤＩユーザーデータのＸＭＬの一部を示す図である。 本発明の他の実施例に係る、ＰＤＩユーザーデータのＸＭＬの他の一部を示す図である。 本発明の一実施例に係る、放送受信機とコンパニオン装置との間にＰＤＩユーザーデータを交換するために定義されるサービスタイプ及びサービスＩＤを示す図である。 本発明の一実施例に係る、ＵＰｎＰによってＰＤＩユーザーデータを交換するために定義される情報を示す図である。 本発明の一実施例に係る、ＰＤＩユーザデータを交換する方法を示すシーケンスダイヤグラムである。 本発明の一実施例に係るＳｅｔＵｓｅｒＤａｔａアクション（ａｃｔｉｏｎ）のための引数（ａｒｇｕｍｅｎｔ）に関連した状態変数（ｓｔａｔｅ ｖａｒｉａｂｌｅ）を示す図である。 本発明の一実施例に係る、コンパニオン装置でＰＤＩユーザデータを設定し、設定されたＰＤＩユーザデータを受信機に伝達し、ＰＤＩユーザデータを受信機に保存する方法を示すシーケンスダイヤグラムである。 本発明の一実施例に係る、ＰＤＩユーザデータに変化が発生する場合、これを伝達するための状態変数を示す図である。 本発明の一実施例に係る、ＰＤＩユーザデータに変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンスダイヤグラムである。 本発明の他の実施例に係る、ＰＤＩユーザデータに変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンスダイヤグラムである。 本発明の他の実施例に係る、ＰＤＩユーザデータに変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンスダイヤグラムである。 本発明の一実施例に係る、質問及び回答のペア単位でＰＤＩユーザデータを持ってくるための状態変数を示す図である。 本発明の一実施例に係る、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション及びＧｅｔＵｓｅｒＤａｔａＱＡアクションのための引数に関連した状態変数を示す図である。 本発明の一実施例に係る、質問／回答のペアを交換する方法を示すシーケンスダイヤグラムである。 本発明の一実施例に係る、ＳｅｔＵｓｅｒＤａｔａＱＡアクションのための引数に関連した状態変数を示す図である。 本発明の一実施例に係る、コンパニオン装置でＱ＆Ａを設定し、設定されたＱ＆Ａを受信機に伝達し、Ｑ＆Ａを受信機に保存する方法を示すシーケンスダイヤグラムである。 本発明の一実施例に係る、Ｑ＆Ａがアップデートされるなどの変化がある場合、これを伝達するための状態変数を示す図である。 本発明の他の実施例に係る、受信機を示す図である。 本発明の一実施例に係る、同期化されたアプリケーション（ｓｙｎｃｈｒｏｎｉｚｅｄ ａｐｐｌｉｃａｔｉｏｎ）への進入（ｅｎｔｒｙ）のための通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を示す図である。 本発明の一実施例に係る、同期化されたアプリケーションの通知とユーザ同意インターフェースを連動するためのユーザインターフェースを示す図である。 本発明の他の実施例に係る、アプリケーションの使用に対する同意のためのユーザインターフェースを示す図である。 本発明の一実施例に係る、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ；ＴＤＯ ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔ）の一部を示す図である。 本発明の他の実施例に係る、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ；ＴＤＯ ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔ）の一部を示す図である。 本発明の一実施例に係る、ＮｏｔｉｆｉｃａｔｉｏｎＩｎｆｏエレメントの情報を用いて同期化されたアプリケーションの通知が表示された（ｅｘｐｒｅｓｓｅｄ）画面を示す図である。 本発明の一実施例に係る、放送サーバー及び受信機を示す図である。 本発明の一実施例に係る、アプリケーションに関連した属性情報を示す図である。 本発明の一実施例に係る、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメント内のＲａｔｅｄ＿ｄｉｍｅｎｓｉｏｎエレメントを示す図である。 本発明の一実施例に係る、コンテンツアドバイザリ情報（ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメント）を含むＴＰＴを示す図である。 本発明の一実施例に係る、レーティング（ｒａｔｉｎｇ）値を取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を示す図である。
以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下に説明する詳細な説明は、本発明によって実現し得る実施例だけを示すよりは、本発明の例示的な実施例を説明するためのものである。
本発明で使われる大部分の用語は、本明細書でその機能を考慮し、当該分野で広く使われているものから選択されたが、一部の用語は出願人によって任意に選択されたものもあり、その意味は、必要によって次の説明で詳細に説明する。したがって、本発明は、単なる名称又は意味よりは、用語の意図した意味に基づいて理解されなければならない。
本発明でいう“シグナリング”とは、サービス情報（ＳＩ）が、放送システム、インターネットシステム、及び／又は放送／インターネットコンバージェンス（ｃｏｎｖｅｒｇｅｎｃｅ）システムから送受信されることを意味することができる。サービス情報（ＳＩ）は、既存の放送システムから受信された放送サービス情報（例えば、ＡＴＳＣ−ＳＩ及び／又はＤＶＢ−ＳＩ）を含むことができる。
“放送信号”という用語は、地上波放送、ケーブル放送、衛星放送及び／又はモバイル放送から受信された信号及び／又はデータだけでなくインターネット放送、ブロードバンド放送、通信放送、データ放送及び／又はＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）などの双方向放送システムから受信された信号及び／又はデータを概念的に含むことができる。
“ＰＬＰ”という用語は、物理層に含まれるデータを送信する所定の単位を示すことができる。したがって、“ＰＬＰ”という用語は、必要によって、“データユニット”又は“データパイプ”という用語に代えてもよい。
放送ネットワーク及び／又はインターネットネットワークと連動するように構成されるハイブリッド放送サービスは、デジタルテレビ（ＤＴＶ）サービスで使われる代表アプリケーションとして用いられてもよい。ハイブリッド放送サービスは、インターネットで地上波放送ネットワークを介して送信される放送Ａ／Ｖ（オーディオ／ビデオ）コンテンツに関連したエンハンスメントデータを実時間で送信し、インターネットで放送Ａ／Ｖコンテンツの一部を実時間で送信し、ユーザが様々なコンテンツを経験できるようにすることができる。
本発明は、ＩＰパケット、ＭＰＥＧ−２ＴＳパケット及び次世代デジタル放送システムで他の放送システムに適用可能なパケットをカプセル化し、ＩＰパケット、ＭＰＥＧ−２ＴＳパケット及びパケットが物理層に送信されるようにする方法を提供することを目標とする。また、本発明は、同じヘッダーフォーマットを用いてレイヤ２シグナリングを送信する方法を提案する。
次に説明するコンテンツは、装置によって実現することができる。例えば、次のプロセスを、シグナリングプロセッサ、プロトコルプロセッサ、プロセッサ及び／又はパケット生成器で行うことができる。
本発明で使用する用語のうち、実時間サービス（ｒｅａｌ ｔｉｍｅ（ＲＴ）ｓｅｒｖｉｃｅ）は、言葉のとおり、実時間サービスを意味する。すなわち、時間に拘束されるサービスである。これに対し、非実時間サービス（ｎｏｎ−ｒｅａｌ ｔｉｍｅ（ＮＲＴ） ｓｅｒｖｉｃｅ）は、ＲＴサービス以外の非実時間サービスを意味する。すなわち、非実時間サービスは、時間に拘束されないサービスである。そして、ＮＲＴサービスのためのデータをＮＲＴサービスデータと呼ぶものとする。
本発明に係る放送受信機は、地上波、ケーブル、インターネットなどのような媒体を介して非実時間（ＮＲＴ）サービスを受信することができる。ＮＲＴサービスは、放送受信機の保存媒体に保存された後、既に設定された時間又はユーザーの要求によってディスプレイ装置に表示される。ＮＲＴサービスは、ファイル形態で受信されて保存媒体に保存されることを一実施例とする。保存媒体は、放送受信機の内部に装着された内蔵ＨＤＤであることを一実施例とする。他の例として、保存媒体は、放送受信システムの外部に連結されたＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、外付けＨＤＤなどとしてもよい。ＮＲＴサービスを構成するファイルを受信して保存媒体に保存し、ユーザーにサービスするためには、シグナリング情報が必要である。本発明は、これをＮＲＴサービスシグナリング情報又はＮＲＴサービスシグナリングデータと呼ぶものとする。本発明に係るＮＲＴサービスは、ＩＰデータグラムを得る方式によって、Ｆｉｘｅｄ ＮＲＴサービスとＭｏｂｉｌｅ ＮＲＴサービスとに区別することができる。特にＦｉｘｅｄ ＮＲＴサービスは、固定型放送受信機に提供され、Ｍｏｂｉｌｅ ＮＲＴサービスは、移動型放送受信機に提供される。本発明は、Ｆｉｘｅｄ ＮＲＴサービスを一実施例として説明するものとする。しかし、本発明がＭｏｂｉｌｅ ＮＲＴサービスに適用されてもよいことは当然である。
本発明で使う用語のうち、アプリケーション（又は、同期化されたアプリケーション）は、視聴経験（ｖｉｅｗｉｎｇ ｅｘｐｅｒｉｅｎｃｅ）の向上のために、視聴者に双方向経験を提供するデータサービスである。アプリケーションは、ＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）、ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）、又はＮＤＯ（ＮＲＴ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）と命名することができる。
本発明で使う用語のうち、トリガー（Ｔｒｉｇｇｅｒ）は、シグナリングを識別し、アプリケーション又はアプリケーション内のイベントの提供時点を設定するシグナリングエレメント（ｓｉｇｎａｌｉｎｇ ｅｌｅｍｅｎｔ）である。トリガーは、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ）（又は、ＴＤＯ ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔとも呼ぶ。）の位置情報を含むことができる。ＴＰＴは、特定範囲内で、アプリケーションの動作のためのメタデータを含むシグナリングエレメントである。
トリガーは、タイムベーストリガー（ｔｉｍｅ ｂａｓｅ ｔｒｉｇｇｅｒ）及び／又はアクチベーショントリガー（ａｃｔｉｖａｔｉｏｎ ｔｒｉｇｇｅｒ）の役割を担うことができる。タイムベーストリガーは、イベントの再生時刻の基準を提示するタイムベースを設定するために用いられる。アクチベーショントリガーは、アプリケーション又はアプリケーション内に含まれたイベントの動作時刻を設定するために用いられる。ここで、動作は、アプリケーション又はアプリケーション内のイベントの開始、終了、一時停止（ｐａｕｓｅ）、ｋｉｌｌ及び／又はｒｅｓｕｍｅに該当し得る。タイムベースメッセージ（ｔｉｍｅ ｂａｓｅ ｍｅｓｓａｇｅｓ）がタイムベーストリガーとして用いられてもよく、タイムベーストリガーがタイムベースメッセージとして用いられてもよい。後述されるアクチベーションメッセージ（ａｃｔｉｖａｔｉｏｎ ｍｅｓｓａｇｅｓ）がアクチベーショントリガーとして用いられてもよく、アクチベーショントリガーがアクチベーションメッセージとして用いられてもよい。
メディアタイム（Ｍｅｄｉａ Ｔｉｍｅ）は、コンテンツ再生時に、特定の時点を参照するためのパラメータ（ｐａｒａｍｅｔｅｒ）である。
ＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、放送コンテンツ内の付加情報を示すものである。ＴＤＯは、付加情報を放送コンテンツ内でタイミングに合わせてトリガーする概念である。例えば、オーディションプログラムが放送される場合、視聴者が好むオーディション参加者の現在順位などを当該放送コンテンツと共に示すことができ、このオーディション参加者の現在順位などに関する付加情報がＴＤＯに当たる。このようなＴＤＯは、視聴者との双方向通信によって変更されてもよく、視聴者の意図を反映して提供されてもよい。
本発明は、次世代放送サービスに対する放送信号送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。
本発明の一実施例に係る送信装置及び方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイル、及びＵＨＤＴＶサービスのためのアドバンスドプロファイルに分類される。この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方のためのプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。これは設計者の意図によって変更されてもよい。
本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式などを含むことができる。
以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯ方式が２つのアンテナを用いるとしたが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。
本発明は、特定の用途に要求される性能を達成しながら、受信機の複雑度を最小化するために、最適化された３つのフィジカルプロファイル（ＰＨＹ ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が実装しなければならない全ての構造のサブセットである。
３つのフィジカルプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。後でフィジカルプロファイルがさらに定義されてもよい。システムの発展のために、フューチャープロファイルは、ＦＥＦ（ｆｕｔｕｒｅ ｅｘｔｅｎｓｉｏｎ ｆｒａｍｅ）を通じて単一ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。
１．ベースプロファイル
ベースプロファイルは主にループトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信範ちゅうに属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置又は車両用に拡張されてもよいが、このような使用用途はベースプロファイル受信機動作では期待されない。
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは、既存放送システム（例えば、ＡＴＳＣ Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリーで駆動するハンドヘルド装置よりは重要でない。ベースプロファイルに対する重要システムパラメータが、下記の表１に記載されている。
Figure 0006189546
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は歩行者又は車両の速度で移動することができる。受信機複雑度も消費電力も、共にハンドヘルドプロファイルの装置の実装のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ未満となるように設定されてもよい。
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが下記の表２に記載されている。
Figure 0006189546
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルはＭＩＭＯ送信及び受信を用いることを要求し、ＵＨＤＴＶサービスはターゲット用途であり、そのために、当該プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するために用いることができる。
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には既存の楕円分極伝送装備を使用し、将来には全出力交差分極伝送へと拡張されてもよい。アドバンスドプロファイルに対する重要システムパラメータが下記の表３に記載されている。
Figure 0006189546
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いられてもよい。すなわち、ベースプロファイルを、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別することができる。そして、該当の３つのプロファイルは設計者の意図によって変更されてもよい。
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
補助ストリーム：フューチャーエクステンション（ｆｕｔｕｒｅ ｅｘｔｅｎｓｉｏｎ、将来拡張）のために又は放送局やネットワーク運営者による要求によって用いられ得る、まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
ベースデータパイプ（ｂａｓｅ ｄａｔａ ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
コーディングブロック（ｃｏｄｅｄ ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックの一つ
データパイプ（ｄａｔａ ｐｉｐｅ）：一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）における論理チャネル
データパイプユニット（ＤＰＵ，ｄａｔａ ｐｉｐｅ ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
データシンボル（ｄａｔａ ｓｙｍｂｏｌ）：プリアンブルシンボル以外のフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを一意に識別する。
ダミーセル（ｄｕｍｍｙ ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために用いられないで残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
ＦＡＣ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
フレーム（ｆｒａｍｅ）：プリアンブルによって始まってフレームエッジシンボルによって終了される物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）タイムスロット
フレームレピティションユニット（ｆｒａｍｅ ｒｅｐｅｔｉｔｉｏｎ ｕｎｉｔ；フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む同一の又は異なるフィジカルプロファイルに属するフレームの集合
ＦＩＣ（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ；高速情報チャネル）：サービスと該当のベースデータパイプとのマッピング情報を伝達するフレーム内の論理チャネル
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコードされたビットの集合
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一である特定モードに用いられる名目上のＦＦＴサイズ
フレームシグナリングシンボル（ｆｒａｍｅ ｓｉｇｎａｌｉｎｇ ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、保護区間（ｇｕａｒｄ ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの開始で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
フレームエッジシンボル（ｆｒａｍｅ ｅｄｇｅ ｓｙｍｂｏｌ）：ＦＦＴサイズ、保護区間、及びスキャッタパイロットパターンの特定組合せにおいてフレームの終わりで用いられるより高いパイロット密度を有するＯＦＤＭシンボル
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームで同じフィジカルプロファイルタイプを有する全フレームの集合
フューチャーエクステンションフレーム（ｆｕｔｕｒｅ ｅｘｔｅｎｔｉｏｎ ｆｒａｍｅ；将来拡張フレーム）：プリアンブルによって始まる、将来拡張に用いられ得るスーパーフレームにおける物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）タイムスロット
フューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである、提案された物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）放送システム
インプットストリーム（ｉｎｐｕｔ ｓｔｒｅａｍ；入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボル以外のデータシンボル
フィジカルプロファイル（ＰＨＹ ｐｒｏｆｉｌｅ）：該当する受信機が実装しなければならない全構造のサブセット
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ ｓｉｇｎａｌｌｉｎｇ ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
ＮＯＴＥ：ＰＬＳ１データがフレームグループのデュレーション（ｄｕｒａｔｉｏｎ）で一定である。
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ；動的）データ：フレームごとにダイナミック（動的）に変化するＰＬＳ２データ
ＰＬＳ２スタティック（ｓｔａｔｉｃ；静的）データ：フレームグループのデュレーションでスタティック（ 静的）であるＰＬＳ２データ
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ ｓｉｇｎａｌｉｎｇ ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
プリアンブルシンボル（ｐｒｅａｍｂｌｅ ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの開始に位置する固定された長さのパイロットシンボル
ＮＯＴＥ：プリアンブルシンボルがシステム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
将来使用（ｆｕｔｕｒｅ ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書で定義されないが、将来に定義されてもよい。
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
タイムインターリービングブロック（ｔｉｍｅ ｉｎｔｅｒｌｅａｖｉｎｇ ｂｌｏｃｋ；ＴＩ ｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に該当する、タイムインターリービングが実行されるセルの集合
タイムインターリービンググループ（ｔｉｍｅ ｉｎｔｅｒｌｅａｖｉｎｇ ｇｒｏｕｐ；ＴＩ ｇｒｏｕｐ）：整数、ダイナミック（動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（動的）容量割り当てが実行される単位
ＮＯＴＥ：タイムインターリービンググループが一つのフレームに直接マップされたり、複数のフレームにマップされてもよい。これは一つ以上のタイムインターリービングブロックを含むことができる。
タイプ１データパイプ（Ｔｙｐｅ１ＤＰ）：全データパイプがフレームにＴＤＭ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ
タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全データパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全ビットを伝達するＮｃｅｌｌｓセルの集合
図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、入力フォーマットブロック１０００、ＢＩＣＭ（ｂｉｔ ｉｎｔｅｒｌｅａｖｅｄ ｃｏｄｉｎｇ ＆ ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレーム生成ブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各モジュールの動作について説明する。
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは、主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。それらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当の帯域幅のスケジューリング及び割り当てを制御する。一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
入力フォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマルチプレクスすることができる。データパイプは、堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。入力フォーマットブロック１０００の詳細な動作は後述する。
データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層における論理チャネルである。
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
入力フォーマットブロック１０００で、パリティ（ｐａｒｉｔｙ）データはエラー訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマップされる。当該シンボルは該当のデータパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。
フレーム生成ブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップすることができる。マッピング後、周波数領域ダイバーシチのために、特に、周波数選択的フェージングチャネルを防止するために周波数インターリービングが用いられる。フレーム生成ブロック１０２０の詳細な動作は後述する。
プリアンブルを各フレームの開始に挿入した後、ＯＦＤＭ生成ブロック１０３０は、サイクリックプレフィクス（ｃｙｃｌｉｃ ｐｒｅｆｉｘ）を保護区間として有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシチのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ ｐｏｗｅｒ ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は様々なＦＦＴサイズ、保護区間の長さ、該当のパイロットパターンの集合を提供する。ＯＦＤＭ生成ブロック１０３０の詳細な動作は後述する。
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。
図２、図３、図４は、本発明の実施例に係る入力フォーマットブロック１０００を示す。各図について説明する。
図２は、本発明の一実施例に係る入力フォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（ｓｉｎｇｌｅ ｉｎｐｕｔ ｓｔｒｅａｍ）であるときの入力フォーマットモジュールを示す。
図２に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。
物理層への入力は、一つ又は複数のデータストリームで構成される。それぞれのデータストリームは一つのデータパイプによって伝達される。モードアダプテーション（ｍｏｄｅ ａｄａｐｔａｉｏｎ；モード適応）モジュールは、入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ ｆｒａｍｅ）のデータフィールドにスライスする。当該システムは３種類の入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（ｇｅｎｅｒｉｃ ｓｔｒｅａｍ）をサポートする。ＭＰＥＧ２−ＴＳは、最初のバイトが同期バイト（０ｘ４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。当該システムは、ＩＰストリームに対してＩＰｖ４、ＩＰｖ６の両方をサポートする。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長のパケット又は一定の長さのパケットで構成されてもよい。
（ａ）は、信号データパイプに対するモードアダプテーション（モード適応）ブロック２０００、及びストリームアダプテーション（ｓｔｒｅａｍ ａｄａｐｔａｔｉｏｎ；ストリーム適応）２０１０を示し、（ｂ）は、ＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０、及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。
入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。
ＣＲＣエンコーダは、ユーザパケットレベルでのエラー検出のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトは、ユーザパケット後に添付される。ＣＲＣ−８はＴＳストリームに用いられ、ＣＲＣ−３２はＩＰストリームに用いられる。ＧＳストリームがＣＲＣエンコーディングを提供しない場合には、提案されたＣＲＣエンコーディングが適用されなければならない。
ＢＢフレームスライサは、入力を内部論理ビットフォーマットにマップする。最初の受信ビットはＭＳＢと定義する。ＢＢフレームスライサは、利用可能なデータフィールド容量と同じ数の入力ビットを割り当てる。ＢＢＦペイロードと同じ数の入力ビットを割り当てるために、ユーザパケットストリームがＢＢＦのデータフィールドに見合うようにスライスされる。
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダーだけでなく、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。
ストリームアダプテーション（ストリーム適応）２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。
スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（ストリーム適応）に対する入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同期化される。スクランブリングシーケンスはフィードバックシフトレジスターによって生成される。
ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機に物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
ＰＬＳ１データは、ＰＬＳ２データをデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでＦＳＳで伝達されるＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデュレーションで一定である。
ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードする上で十分な情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（静的）データは、フレームグループのデュレーションでスタティック（静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（動的）データは、フレームごとにダイナミック（動的）に変化するＰＬＳ２データである。
ＰＬＳデータに関する詳細な内容は後述する。
ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図３は、本発明の他の実施例に係る入力フォーマットブロックを示す。
図３に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。
図３は、入力信号がマルチインプットストリーム（ｍｕｌｔｉ ｉｎｐｕｔ ｓｔｒｅａｍ；複数の入力ストリーム）に該当する場合、入力フォーマットブロックのモードアダプテーション（モード適応）ブロックを示す。
マルチインプットストリーム（複数の入力ストリーム）を処理するための入力フォーマットブロックのモードアダプテーション（モード適応）ブロックは、複数の入力ストリームを独立して処理することができる。
図３を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、入力ストリームスプリッタ３０００、入力ストリームシンクロナイザ３０１０、コンペンセーティングディレイ（ｃｏｍｐｅｎｓａｔｉｎｇ ｄｅｌａｙ；補償遅延）ブロック３０２０、ヌルパケット削除ブロック３０３０、ヘッダー圧縮ブロック３０４０、ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０を含むことができる。モードアダプテーション（モード適応）ブロックの各ブロックについて説明する。
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックの動作に該当するので、その説明は省略する。
入力ストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。
入力ストリームシンクロナイザ３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、いかなる入力データフォーマットに対しても、ＣＢＲ（ｃｏｎｓｔａｎｔ ｂｉｔ ｒａｔｅ）及び一定の終端間伝送（ｅｎｄ−ｔｏ−ｅｎｄ ｔｒａｎｓｍｉｓｓｉｏｎ）遅延を保証する適合な手段を提供することができる。ＩＳＳＹは、ＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。
コンペンセーティングディレイ（補償遅延）ブロック３０２０は、受信機でさらにメモリを必要とせずにＴＳパケット再結合メカニズムを許容するために、ＩＳＳＹ情報の挿入に続く分割されたＴＳパケットストリームを遅延させることができる。
ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ用いられる。一部のＴＳ入力ストリーム又は分割されたＴＳストリームは、ＶＢＲ（ｖａｒｉａｂｌｅ ｂｉｔ−ｒａｔｅ）サービスをＣＢＲ ＴＳストリームに収容するために、存在する多数のヌルパケットを有することができる。この場合、不要な伝送オーバーヘッドを避けるために、ヌルパケットは確認されて伝送されなくてもよい。受信機で、除去されたヌルパケットは、伝送に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ ｎｕｌｌ−ｐａｃｋｅｔ；削除されたヌルパケット）カウンタを参照して元の正確な場所に再挿入可能であるため、ＣＢＲが保証され、タイムスタンプ（ＰＣＲ）更新が不要になる。
ヘッダー圧縮ブロック３０４０は、ＴＳ又はＩＰ入力ストリームに対する伝送効率を増加させるために、パケットヘッダー圧縮を提供することができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ ｐｒｉｏｒｉ）情報を有することができるため、この知られた情報は送信機で削除されてもよい。
ＴＳに対して、受信機は同期バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが一つのＰＩＤだけを有するコンテンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣエンハンスメントレイヤ、ＭＶＣベースビュー、又はＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダー圧縮がＴＳに（選択的に）適用されてもよい。ＴＳパケットヘッダー圧縮は、入力ストリームがＩＰストリームである場合に選択的に用いられる。
上記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図４は本発明の他の実施例に係る入力フォーマットブロックを示す。
図４に示す入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。
図４は、入力信号がマルチインプットストリーム（複数の入力ストリーム）に該当する場合、入力フォーマットモジュールのストリームアダプテーション（ストリーム適応）ブロックを示す。
図４を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、スケジューラ４０００、１−フレームディレイ（ｄｅｌａｙ）ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（Ｉｎ−ｂａｎｄ）シグナリングブロック４０３０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラ４０６０を含むことができる。ストリームアダプテーション（ストリーム適応）ブロックの各ブロックについて説明する。
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラ４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラ４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラ、ＰＬＳ生成ブロック、ＰＬＳスクランブラ４０６０の動作に該当するので、その説明は省略する。
スケジューラ４０００は、各データパイプのＦＥＣＢＬＯＣＫの量から全体フレームにわたって全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含めて、スケジューラは、フレームのＦＳＳのＰＬＳセル又はインバンド（Ｉｎ−ｂａｎｄ）シグナリングで伝送されるＰＬＳ２−ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ、ＦＩＣに関する詳細な内容は後述する。
１−フレームディレイブロック４０１０は、次のフレームに関するスケジューリング情報が、データパイプに挿入されるインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報に関する現フレームを通じて伝送され得るように、入力データを一つの伝送フレームだけ遅延させることができる。
インバンド（Ｉｎ−ｂａｎｄ）シグナリングブロック４０３０は、ＰＬＳ２データの遅延されない部分をフレームのデータパイプに挿入することができる。
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図５は、本発明の一実施例に係るＢＩＣＭブロックを示す。
図５に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
前述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
ＱｏＳが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは別個の方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、そこに入力されるデータパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを通じて伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスドプロファイルに対するＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ ｓｐａｃｅ ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリーブし、ＬＤＰＣコード及び変調方式の組合せによって最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調し、パワーの正規化されたコンステレーションポイントｅlを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有するのに対し、ＱＡＭ−１６及びＮＵＱは正方形を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転されると、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが互いに同一となる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ ｒａｔｅ）に対して特別に定義され、用いられる特定の一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナルされる。
ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをプリコードし、劣悪なフェージング条件で受信堅固性（ｒｏｂｕｓｔｎｅｓｓ）を増加させることができる。
タイムインターリーバ５０５０はデータパイプレベルで動作することができる。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
アドバンスドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化されている。ＭＩＭＯ技術は容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に放送に対して、別個の信号電波特性による両アンテナ間の受信信号パワー差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを困難にさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースプリコーディングを用いてこの問題を克服する。
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２ｘ２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは、本提案であるＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ ｓｐａｔｉａｌ ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅ ｆｕｌｌ−ｄｉｖｅｒｓｉｔｙ ｓｐａｔｉａｌ ｍｕｌｔｉｐｌｅｘｉｎｇ）で定義される。ＦＲ−ＳＭエンコーディングは、受信機側での比較的小さい複雑度増加から容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側での大きい複雑度増加から容量増加及び追加的なダイバーシチ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
ＭＩＭＯ処理はアドバンスドプロファイルフレームに要求されるが、これは、アドバンスドプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ；組）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力のペア（組）（ｇ1,i及びｇ2,i）は、それぞれの送信アンテナの同一キャリアｋ及びＯＦＤＭシンボルｌによって送信される。
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
図６に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
図６は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおける論理チャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
スクランブラは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディング前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコードされ、その後に添付される。
Figure 0006189546
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。
Figure 0006189546
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。それらのパンクチャされたビットは伝送されない。
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。
コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマップすることができる。
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図７は、本発明の一実施例に係るフレーム生成ブロックを示す。
図７に示すフレーム生成ブロックは、図１を参照して説明したフレーム生成ブロック１０２０の一実施例に該当する。
図７を参照すると、フレーム生成ブロックは、ディレイコンペンセーション（ｄｅｌａｙ ｃｏｍｐｅｎｓａｔｉｏｎ；遅延補償）ブロック７０００、セルマッパー７０１０、及び周波数インターリーバ７０２０を含むことができる。フレーム生成ブロックの各ブロックに関し説明する。
ディレイコンペンセーション（遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節し、送信機側でそれらの同時性を保証することができる。入力フォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによって、ＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０に起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先に伝達されるようにすることができる。ディレイコンペンセーション（遅延補償）ブロックは、それに応じてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパー７０１０の基本機能は、それぞれのデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍ ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集され、データパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ ｉｎｆｏｒｍａｔｉｏｎ；動的情報）によって動作する。フレームに関する詳細な内容は後述する。
周波数インターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシチを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（組）で動作することができる。
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図８は、本発明の一実施例に係るＯＦＤＭ生成ブロックを示す。
図８に示すＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の一実施例に該当する。
ＯＦＤＭ生成ブロックは、フレーム生成ブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次に保護区間を挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
図８を参照すると、フレーム生成ブロックは、パイロット及びリザーブドトーン（ｒｅｓｅｒｖｅｄ ｔｏｎｅ）挿入ブロック８０００、２Ｄ−ｅＳＦＮ（ｓｉｎｇｌｅ ｆｒｅｑｕｅｎｃｙ ｎｅｔｗｏｒｋ）エンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ ｆａｓｔ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。フレーム生成ブロックの各ブロックについて説明する。
パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。
ＯＦＤＭシンボル内の様々なセルは、受信機で先験的に知られた送信された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（ｆｒａｍｅ ｓｉｇｎａｌｌｉｎｇ ｓｙｍｂｏｌ）パイロット、及びＦＥＳ（ｆｒａｍｅ ｅｄｇｅ ｓｙｍｂｏｌ）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンによって特定の増加パワーレベルで送信される。パイロット情報の値は、与えられたシンボルで一つがそれぞれの伝送キャリアに対するものである一連の値に該当する参照シーケンスから誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定、伝送モード識別のために用いられてもよく、さらに、位相雑音を追跡するために用いられてもよい。
参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳ以外の全シンボルにおいて分散パイロットセルで送信される。連続パイロットは、フレームの全シンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンにいずれも依存する。エッジキャリアは、プリアンブルシンボル以外の全シンボルでエッジパイロットである。これらは、スペクトルのエッジまで周波数インターポレーション（ｉｎｔｅｒｐｏｌａｔｉｏｎ；補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。それらはフレームのエッジまで時間インターポレーション（補間）を許容するために挿入される。
本発明の一実施例に係るシステムは、非常に堅固な伝送モードをサポートするために、分散ＭＩＳＯ方式が選択的に用いられるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは、それぞれがＳＦＮで他の送信機位置にある複数の送信アンテナを用いる分散ＭＩＳＯ方式である。
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシチを生成するために２Ｄ−ｅＳＦＮ処理をし、複数の送信機から送信された信号の位相を歪ませることができる。したがって、長時間の低い平面フェージング又は深いフェージングによるバースト誤りが軽減する。
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（又は、リザーブドトーン）として指定されていないデータシンボルにおける全セルは、周波数インターリーバからのデータセルのうち一つを伝達する。これらのセルはＯＦＤＭキャリアにマップされる。
ＰＡＰＲ減少ブロック８０３０は、時間領域で様々なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。
保護区間挿入ブロック８０４０は保護区間を挿入することができ、プリアンブル挿入ブロック８０５０は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造に関する詳細な内容は後述する。その他、システム挿入ブロック８０６０は、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。ここで、２つ以上の別個の放送送信／受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。それぞれの放送サービスに関連したデータは別個のフレームで伝送されてもよい。
ＤＡＣブロック８０７０は、入力されたデジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって複数の出力アンテナから伝送されてもよい。本発明の一実施例に係る送信アンテナは、垂直又は水平の極性を有することができる。
前述したブロックは、設計によって省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応し得る。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０、及びシグナリングデコーディングモジュール９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
同期及び復調モジュール９０００は、ｍ個の受信アンテナを通じて入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆手順に該当する復調を実行することができる。
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって取得され、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、それをデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆手順を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータで必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
図１０は、本発明の一実施例に係るフレーム構造を示す。
図１０は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（ｆｒａｍｅ ｒｅｐｅｔｉｔｉｏｎ ｕｎｉｔ；フレーム反復単位）を示す。（ａ）は、本発明の一実施例に係るスーパーフレームを示し、（ｂ）は、本発明の一実施例に係るＦＲＵを示し、（ｃ）は、ＦＲＵにおける様々なフィジカルプロファイル（ＰＨＹ ｐｒｏｆｉｌｅ）のフレームを示し、（ｄ）は、フレームの構造を示す。
スーパーフレームは８個のＦＲＵを含むことができる。ＦＲＵは、フレームのＴＤＭに対する基本マルチプレクシング単位であり、スーパーフレームで８回反復される。
ＦＲＵにおいて各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスドプロファイル）のいずれか一つ又はＦＥＦに属する。ＦＲＵにおいてフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、ＦＲＵにおいて０回乃至４回の回数を有することができる（例えば、ベース、ベース、ハンドヘルド、アドバンスド）。フィジカルプロファイル定義は、必要時には、プリアンブルにおけるＰＨＹ＿ＰＲＯＦＩＬＥのリザーブド値を用いて拡張されてもよい。
ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームにおいて８である。ＦＥＦ部分が互いに隣接することが推奨されない。
一つのフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。
プリアンブルは、高速フューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、これによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルに比べてより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳ直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しで、ＦＥＳ内における周波数だけのインターポレーション（補間）及び時間的補間（ｔｅｍｐｏｒａｌ ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
図１１は、本発明の一実施例に係るフレームのシグナリング階層構造を示す。
図１１は、シグナリング階層構造を示すが、これは、３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーティング可能にさせる。ＰＬＳ２は毎フレームごとに伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（静的）及びダイナミック（動的）部分には必要時にパディングが続く。
図１２は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、現フレームのフィジカルプロファイルタイプを示す。各フィジカルプロファイルタイプのマッピングは下記の表５のように与えられる。
Figure 0006189546
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表６で説明したとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
Figure 0006189546
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表７で説明したとおり、現スーパーフレームにおける保護区間一部（ｆｒａｃｔｉｏｎ）値を示す。
Figure 0006189546
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームで提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームで提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドはスーパーフレーム内でダイナミック（動的）に転換されてもよい。
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードなのか又は固定モードなのかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：当該３ビットフィールドは、現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全プリアンブルにおける当該フィールドにおいて、現スーパーフレームで伝達される全プロファイルタイプが識別される。当該３ビットフィールドは、下記の表８に示すように、それぞれのプロファイルに対して別々に定義される。
Figure 0006189546
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
図１３は、本発明の一実施例に係るＰＬＳ１データを示す。
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全デュレーションで変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は次のとおりである。
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧ以外のプリアンブルシグナリングデータのコピーである。
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表９に示すようにシグナルされる。
Figure 0006189546
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換が不可能な変化を示す。デフォルト値は００００である。当該標準で述べているバージョンに対して、値が００００に設定される。
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は互換が可能である。
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを一意に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、フューチャーキャストＵＴＢシステム当たりに用いられる周波数数によって一つ以上の周波数で構成されてもよい。ＣＥＬＬ＿ＩＤの値が知られないか又は特定されないと、当該フィールドは０に設定される。
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを一意に識別する１６ビットフィールドである。
ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドは、ＡＴＳＣネットワーク内でフューチャーキャストＵＴＢシステムを一意に識別する。フューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。フューチャーキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じフューチャーキャストＵＴＢシステムは、別個の入力ストリームを伝達し、別個の地理的領域で別個のＲＦを用いることができ、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のフューチャーキャストＵＴＢシステムはいずれも同一のフィジカル構造及び構成を有するという同一のＳＹＳＴＥＭ＿ＩＤ意味を有することができる。
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、用いられないフィールドはゼロで埋められる。
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは表８に示すものと同じシグナリングフォーマットを用いる。
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを用いると、フレームデュレーションの正確な値が得られる。
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの保護区間一部値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７に従ってシグナルされる。
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。
Figure 0006189546
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
Figure 0006189546
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。反復が用いられない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０に従ってシグナルされる。
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_full_blockを示す。次のフレームグループで反復が用いられない場合、当該フィールドの値は０と同一である。当該値は現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループで一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループで一定である。
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デュレーションで一定である。下記の表１２は当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して用いられない。
Figure 0006189546
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デュレーションで一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デュレーションで一定である。表１２は、当該フィールドの値を定義する。
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デュレーションで一定である。
ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
ＣＲＣ＿３２：全ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
図１４は、本発明の一実施例に係るＰＬＳ２データを示す。
図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
ＰＬＳ２−ＳＴＡＴデータのフィールドに対して次に具体的に説明する。
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全デュレーションで一定である。
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームで提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全デュレーションで一定である。
ＮＵＭ＿ＤＰ：該当６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でＤＰを一意に識別する。
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドはデータパイプのタイプを示す。これは下記の表１３に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有する特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いられてもよい。
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤで示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであってもよく、サービスシグナリングデータだけを伝達する専用データパイプであってもよい。
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは下記の表１４に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ ｒａｔｅ）を示す。コードレート（ｃｏｄｅ ｒａｔｅ）は下記の表１５に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は下記の表１６に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤが用いられる。当該フィールドの値が０に設定されると、ＳＳＤは用いられない。
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ表される。
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、どのタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは下記の表１７に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームで伝達され、一つのタイムインターリービングブロックのみを含むことを示す。
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである。）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマップされるフレームの数であるＰIを示し、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１８に定義される。
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１８に定義される。
Figure 0006189546
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩJUMP）を示し、許容された値は１，２，４，８（該当する２ビットフィールドはそれぞれ００，０１，１０，１１）である。フレームグループの全フレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１，５，９，１３などのフレームで現れると、当該フィールドの値は４に設定される。全フレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の利用可能性を決定する。データパイプに対してタイムインターリービングが用いられないと、それは１に設定される。一方、タイムインターリービングが用いられると、それは０に設定される。
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは下記の表１９に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは下記の表２０に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。それは、入力ペイロードタイプが選択されると、下記の表２１に従ってシグナルされる。
Figure 0006189546
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングが入力フォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナルされる。
Figure 0006189546
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表２３に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
Figure 0006189546
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表２４に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
Figure 0006189546
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表２５に従ってシグナルされる。
Figure 0006189546
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）に設定される場合に、ＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは下記の表２６に従ってシグナルされる。
Figure 0006189546
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合に、ＴＳヘッダー圧縮のためのＰＩＤ数を示す。
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが用いられないことを示す。
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
図１５は、本発明の他の実施例に係るＰＬＳ２データを示す。
図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は一つのフレームグループのデュレーションで変化してもよいが、フィールドのサイズは一定である。
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次のとおりである。
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化がるということを示す。
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを一意に示す。
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２７に示すように、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。
Figure 0006189546
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルでＥＡＣ＿ＦＬＡＧと同じ値である。
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
ＥＡＣ＿ＦＬＡＧフィールドが１に等しいと、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０に等しいと、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム前のフレームの数を示す。
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブされる（ｒｅｓｅｒｖｅｄ）。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴ内のＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
ＣＲＣ＿３２：全ＰＬＳ２に適用される３２ビットエラー検出コード。
図１６は、本発明の一実施例に係るフレームの論理（ｌｏｇｉｃａｌ）構造を示す。
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームでＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１及びＰＬＳ２は、初めには一つ以上のＦＳＳにマップされる。その後、存在するなら、ＥＡＣセルは直後のＰＬＳフィールドにマップされ、次に存在すると、ＦＩＣセルが続く。データパイプは、存在すると、ＰＬＳ又はＥＡＣ、ＦＩＣ後にマップされる。タイプ１データパイプが初めて続き、その次にタイプ２データパイプが続く。データパイプのタイプの具体的な内容は後述する。一部の場合に、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプに続き、ここには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順でそれらを全て共にマップすると、フレームでセル容量を正確に満たす。
図１７は、本発明の一実施例に係るＰＬＳマッピングを示す。
ＰＬＳセルは、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳが占めるセルの数によって、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳでシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳで重大な問題（ｉｓｓｕｅ）であるため、ＦＳＳは高いパイロット密度を有し、高速同期化及びＦＳＳ内における周波数のみのインターポレーション（補間）を可能にする。
ＰＬＳセルは、図１７の例に示すように、下向き方式でＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルははじめには、最初のＦＳＳの最初のセルからセルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、マッピングは、最初のＦＳＳの最後のセルインデックスまで下向き方式で続く。必要なＰＬＳセルの総数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進行され、最初のＦＳＳと全く同じ方式で続けて行われる。
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、これらはＰＬＳとノーマルデータパイプとの間に配置される。
図１８は、本発明の一実施例に係るＥＡＣマッピングを示す。
ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。存在するなら、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＰＬＳセルを除けば、ＦＩＣ、データパイプ、補助ストリーム又はダミーセルのいずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手順はＰＬＳと全く同一である。
ＥＡＣセルは、図１８の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは少ないシンボルを占めることができる。
ＥＡＣセルは、ＰＬＳ２の最後のセル直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＥＡＣセルの総数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われれる。この場合のマッピングに対する次のシンボルはノーマルデータシンボルであり、これは、ＦＳＳに比べてより多いアクティブキャリアを有する。
ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。ＦＩＣが伝送されないと（ＰＬＳ２フィールドでシグナリングによって）、データパイプがＥＡＣの最後のセルの直後に続く。
図１９は、本発明の一実施例に係るＦＩＣマッピングを示す。
（ａ）は、ＥＡＣ無しのＦＩＣセルのマッピングの例を示し、（ｂ）は、ＥＡＣを伴うＦＩＣセルのマッピングの例を示す。
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために階層間情報を伝達する専用チャネルである。当該情報は主に、データパイプ間のチャネルバインディング情報及び各放送局のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコードし、放送局ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービスの取得のために、ＦＩＣだけでなくベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコードすることができる。それが伝達するコンテンツを除いて、ベースデータパイプは、ノーマルデータパイプと全く同じ方式でエンコードされてフレームにマップされる。したがって、ベースデータパイプに関する追加説明が必要でない。ＦＩＣデータが生成されて管理層で消費される。ＦＩＣデータのコンテンツは、管理層仕様に説明されたとおりである。
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（静的）である部分でＦＩＣ＿ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが用いられると、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドは、ＰＬＳ２のスタティック（静的）である部分で定義される。当該フィールドでシグナルされるものはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ．ＦＩＣは、ＰＬＳ２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２又はＥＡＣの直後にマップされる。ノーマルデータパイプ、補助ストリーム、又はダミーセルのいずれもＦＩＣの前に位置しない。ＦＩＣセルをマップする方法は、ＥＡＣと全く同一であり、これはさらにＰＬＳと同一である。
ＰＬＳ後のＥＡＣ無しで、ＦＩＣセルは、（ａ）の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＦＩＣデータサイズによって、（ｂ）に示すように、ＦＩＣセルは数個のシンボルに対してマップされる。
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＦＩＣセルの総数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合のマッピングに対する次のシンボルはノーマルデータシンボルであり、これはＦＳＳに比べてより多いアクティブキャリアを有する。
ＥＡＳメッセージが現フレームで伝送されると、ＥＡＣがＦＩＣに先行し、ＦＩＣセルが（ｂ）に示すように、ＥＡＣの次のセルからセルインデックスの昇順でマップされる。
ＦＩＣマッピングが完了した後、一つ以上のデータパイプがマップされ、ここには、存在するなら、補助ストリーム、ダミーセルが続く。
図２０は、本発明の一実施例に係るデータパイプのタイプを示す。
（ａ）はタイプ１データパイプを示し、（ｂ）はタイプ２データパイプを示す。
先行するチャネル、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣがマップされた後、データパイプのセルがマップされる。データパイプは、マッピング方法によって２タイプのいずれかに分類される。
タイプ１データパイプ：データパイプがＴＤＭによってマップされる。
タイプ２データパイプ：データパイプがＦＤＭによってマップされる。
データパイプのタイプは、ＰＬＳ２のスタティック（静的）である部分でＤＰ＿ＴＹＰＥフィールドで示す。図２０は、タイプ１データパイプ及びタイプ２データパイプのマッピング順序を示す。タイプ１データパイプはまずセルインデックスの昇順でマップされた後、最後のセルインデックスに到達すると、シンボルインデックスが１ずつ増加する。次のシンボル内で、データパイプはｐ＝０から始まって、セルインデックスの昇順で続けてマップされる。一つのフレームで共にマップされる複数のデータパイプと共に、それぞれのタイプ１データパイプは、データパイプのＴＤＭと類似に、時間でグルーピングされる。
タイプ２データパイプはまずシンボルインデックスの昇順でマップされ、フレームの最後のＯＦＤＭシンボルに到達すると、セルインデックスは１ずつ増加し、シンボルインデックスは最初の利用可能シンボルに戻った後、そのシンボルインデックスから始まって増加する。一つのフレームで複数のデータパイプをマップした後、それぞれのタイプ２データパイプはデータパイプのＦＤＭと類似に、周波数でグルーピングされる。
タイプ１データパイプ及びタイプ２データパイプは必要時にはフレームで共存してもよいが、タイプ１データパイプが常にタイプ２データパイプに先行するという制限がある。タイプ１及びタイプ２データパイプを伝達するＯＦＤＭセルの総数は、データパイプの伝送に利用可能なＯＦＤＭセルの総数を超えてはならない。
Figure 0006189546
ここで、ＤDP1は、タイプ１データパイプが占めるＯＦＤＭセルの数に該当し、ＤDP2は、タイプ２データパイプが占めるセルの数に該当する。ＰＬＳ、ＥＡＣ、ＦＩＣがいずれもタイプ１データパイプと同じ方式でマップされるため、これらはいずれも、“タイプ１マッピング規則”にしたがう。したがって、一般に、タイプ１マッピングがタイプ２マッピングに先行する。
図２１は、本発明の一実施例に係るデータパイプマッピングを示す。
（ａ）は、タイプ１データパイプをマップするためのＯＦＤＭセルのアドレシングを示し、（ｂ）は、タイプ２データパイプをマップするためのＯＦＤＭセルのアドレシングを示す。
タイプ１データパイプ（０，…，ＤＤＰ１−１）をマップするためのＯＦＤＭセルのアドレシングは、タイプ１データパイプのアクティブデータセルに対して定義される。アドレシング方式は、それぞれのタイプ１データパイプに対するタイムインターリービングからのセルがアクティブデータセルに割り当てられる順序を定義する。それはまた、ＰＬＳ２のダイナミック（動的）部分でデータパイプの位置をシグナルするために用いられる。
ＥＡＣ及びＦＩＣ無しで、アドレス０は、最後のＦＳＳでＰＬＳを伝達する最後のセルの直後にくるセルのことをいう。ＥＡＣが伝送され、ＦＩＣが該当のフレームにないと、アドレス０は、ＥＡＣを伝達する最後のセルの直後にくるセルのことをいう。ＦＩＣが該当のフレームで伝送されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後にくるセルのことをいう。タイプ１データパイプに対するアドレス０は、（ａ）に示すような２種類の異なる場合を考慮して算出することができる。（ａ）の例で、ＰＬＳ、ＥＡＣ、ＦＩＣは全て送信されると仮定する。ＥＡＣとＦＩＣのいずれか一つ又は両方が省略される場合への拡張は自明である。（ａ）の左図に示すように、ＦＩＣまで全てのセルをマップした後にＦＳＳに残っているセルがあると。
タイプ２データパイプ（０，…，ＤＤＰ２−１）をマップするためのＯＦＤＭセルのアドレシングは、タイプ２データパイプのアクティブデータセルに対して定義される。アドレシング方式は、それぞれのタイプ２データパイプに対するタイムインターリービングからのセルがアクティブデータセルに割り当てられる順序を定義する。それはまた、ＰＬＳ２のダイナミック（動的）部分でデータパイプの位置をシグナルするために用いられる。
（ｂ）に示すように、３種類のやや異なる場合が可能である。（ｂ）の最も左図に示す一番目の場合に、最後のＦＳＳにあるセルは、タイプ２データパイプマッピングに用いられてもよい。中央の図に示す二番目の場合に、ＦＩＣはノーマルシンボルのセルを占めるが、当該シンボルにおけるＦＩＣセルの数はＣFSSよりも大きくない。（ｂ）の右図に示す三番目の場合は、当該シンボルにマップされたＦＩＣセルの数がＣＦＳＳを超えるという点を除けば、二番目の場合と同一である。
ＰＬＳ、ＥＡＣ、ＦＩＣがタイプ１データパイプと同じ“タイプ１マッピング規則”にしたがうので、タイプ１データパイプがタイプ２データパイプに先行する場合への拡張は自明である。
データパイプユニット（ＤＰＵ）は、フレームでデータセルをデータパイプに割り当てる基本単位である。
ＤＰＵは、フレームでデータパイプの位置を発見するためのシグナリング単位と定義される。セルマッパー７０１０は、それぞれのデータパイプに対してタイムインターリービングによって生成されたセルをマップすることができる。タイムインターリーバ５０５０は、一連のタイムインターリービングブロックを出力し、それぞれのタイムインターリービングブロックはＸＦＥＣＢＬＯＣＫの可変数を含み、これは結局、セルの集合で構成される。ＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎcellsは、ＦＥＣＢＬＯＣＫサイズ、Ｎldpc、コンステレーションシンボル当たりに伝送されるビット数に依存する。ＤＰＵは、与えられたフィジカルプロファイルでサポートされるＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎcellsの全ての可能な値の最大公約数と定義される。セルにおけるＤＰＵの長さは、ＬDPUと定義される。それぞれのフィジカルプロファイルは、ＦＥＣＢＬＯＣＫサイズの別個の組合せ及びコンステレーションシンボル当たりに異なるビット数をサポートするので、ＬDPUは、フィジカルプロファイルに基づいて定義される。
図２２は、本発明の一実施例に係るＦＥＣ構造を示す。
図２２は、ビットインターリービング前の本発明の一実施例に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造は、ＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一の値を有する。
図２２に示すように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコードされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
Ｎldpcの値は、６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
下記の表２８及び表２９は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
Figure 0006189546
Figure 0006189546
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式を乗算することによって得られる。
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉｌdpcに添付される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
Figure 0006189546
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２８及び表２９にそれぞれ与えられる。
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は次のとおりである。
１）パリティビット初期化
Figure 0006189546
２）パリティチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスで一番目の情報ビットｉ0を累算する（ａｃｃｕｍｕｌａｔｅ）。パリティチェックマトリクスのアドレスの詳細な内容は後述する。例えば、比率１３／１５に対して、
Figure 0006189546
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉsを累算する。
Figure 0006189546
ここで、ｘは、最初のビットｉ0に該当するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅ ｒａｔｅ）依存定数である。上記の例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
Figure 0006189546
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器のアドレスは、パリティチェックマトリクスのアドレスの２番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６を用いて得られる。ここで、ｘは情報ビットｉ360に該当するパリティビット累算器のアドレス、すなわち、パリティチェックマトリクスの２番目の行のエントリを示す。
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるために用いられる。
全情報ビットが利用された後、最終パリティビットが次のように得られる。
６）ｉ＝１から始まって次の動作を順次に実行する
Figure 0006189546
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンテンツは、パリティビットｐiと同一である。
Figure 0006189546
表３０を表３１に代え、ロングＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスのアドレスに代えることを除けば、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔ ＬＤＰＣエンコーディング手順にしたがう。
Figure 0006189546
図２３は、本発明の一実施例に係るビットインターリービングを示す。
ＬＤＰＣエンコーダの出力はビットインターリーブされるが、これは、ＱＣＢ（ｑｕａｓｉ−ｃｙｃｌｉｃ ｂｌｏｃｋ）インターリービング及び内部グループインターリービングが続くパリティインターリービングで構成される。
（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。
ＦＥＣＢＬＯＣＫは、パリティインターリーブすることができる。パリティインターリービングの出力において、ＬＤＰＣコードワードは、ロングＦＥＣＢＬＯＣＫで１８０個の隣接するＱＣＢで構成され、ショートＦＥＣＢＬＯＣＫで４５個の隣接するＱＣＢで構成される。ロング又はショートＦＥＣＢＬＯＣＫにおけるそれぞれのＱＣＢは、３６０ビットで構成される。パリティインターリービングされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリーブされる。ＱＣＢインターリービングの単位はＱＣＢである。パリティインターリービングの出力におけるＱＣＢは、図２３に示すように、ＱＣＢインターリービングによってパーミュテーションされるが、ここでＦＥＣＢＬＯＣＫの長さによってＮcells＝６４８００／ηｍｏｄ又は１６２００／ηｍｏｄである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレート（ｃｏｄｅ ｒａｔｅ）の各組合せに固有である。
ＱＣＢインターリービング後に、内部グループインターリービングが、下記の表３２に定義された変調タイプ及び次数（ηｍｏｄ）によって実行される。一つの内部グループに対するＱＣＢの数ＮQCB_IGも定義される。
Figure 0006189546
内部グループインターリービング過程は、ＱＣＢインターリービング出力のＮ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）にマルチプレクスされる。
図２５は、本発明の一実施例に係るタイムインターリービングを示す。
（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは、タイムインターリービングを構成する。
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マップされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックだけを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、当該パラメータは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数ＰIである。
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同一のデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに用いられないと、当該パラメータは１に設定される。タイムインターリービングが用いられると、０に設定される。
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
タイムインターリービングがデータフレームに用いられないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（動的）構成情報のためのディレイコンペンセーション（遅延補償）ブロックは依然として必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数は、ＮxBLOCK_Group（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫとしてシグナルされる。このとき、ＮxBLOCK_Group（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化してもよい。
それぞれのタイムインターリービンググループは、一つのフレームに直接マップされたり、ＰI個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（ＮTI個）のタイムインターリービングブロックに分離される。ここでそれぞれのタイムインターリービングブロックは、タイムインターリーバメモリの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、やや異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービンググループに分離されると、それは一つのフレームにのみ直接マップされる。下記の表３３に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションを除く）。
Figure 0006189546
Figure 0006189546
また、タイムインターリーバ５０５０から出力されたＸＦＥＣＢＬＯＣＫは、
Figure 0006189546
 と定義されると仮定する。
Figure 0006189546
一般に、タイムインターリーバは、フレーム生成手順の前にデータパイプデータに対するバッファーとしても働くはずである。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。最初のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み取られる間に、２番目のタイムインターリービングブロックが２番目のバンクに書き込まれる。
Figure 0006189546
図２６は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
Figure 0006189546
Figure 0006189546
Figure 0006189546
Figure 0006189546
結果的に、読み取られるセル位置は、座標
Figure 0006189546
 によって算出される。
図２７は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。
より具体的に、図２７は、
Figure 0006189546
 のとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターリービングアレイを示す。
Figure 0006189546
Figure 0006189546
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮTI＝１、ＩJUMP＝１、ＰI＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮcells＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、これは
Figure 0006189546
 につながる。
図２８は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す。
Figure 0006189546
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
図２９は、パラメータ
Figure 0006189546
 及びＳshift＝３を有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
図３０は、本発明の一実施例に係る、次世代放送システムのためのプロトコルスタック（Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）を示す図である。
本発明に係る放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）中心ブロードキャストネットワーク（ＩＰ ｃｅｎｔｒｉｃ ｂｒｏａｄｃａｓｔ ｎｅｔｗｏｒｋ）とブロードバンド（ｂｒｏａｄｂａｎｄ）とが結合されたハイブリッド放送システムに該当し得る。
本発明に係る放送システムは、既存のＭＰＥＧ−２ベースの放送システムとの互換性が維持されるように設計することができる。
本発明に係る放送システムは、ＩＰ中心ブロードキャストネットワーク（ＩＰ ｃｅｎｔｒｉｃ ｂｒｏａｄｃａｓｔ ｎｅｔｗｏｒｋ）、ブロードバンド（ｂｒｏａｄｂａｎｄ）ネットワーク、及び／又は移動通信ネットワーク（ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｎｅｔｗｏｒｋ又はｃｅｌｌｕｌａｒ ｎｅｔｗｏｒｋ）の結合に基づくハイブリッド放送システムに該当してもよい。
同図を参照すると、物理層（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ）は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。例えば、本発明に係る物理層では、送／受信機は地上波放送信号を送信／受信し、放送データを含む伝送フレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を適切な形態に変換することができる。
カプセル化（Ｅｎｃａｐｓｕｌａｔｉｏｎ）層では、物理層から取得した情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得したＩＰデータグラムを特定フレーム（例えば、ＲＳフレーム、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。例えば、カプセル化層で送信機は、物理層で処理されたデータを伝送フレームに含めたり、受信機は、物理層から取得した伝送フレームからＭＰＥＧ−２ＴＳ、ＩＰデータグラムを抽出する。
ＦＩＣ（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツにアクセス可能にさせるための情報（例、サービスＩＤとフレームとのマッピング情報など）を含む。ＦＩＣはＦＡＣ（Ｆａｓｔ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）と命名されてもよい。
本発明の放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＡＬＣ／ＬＣＴ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ ／ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（Ｒａｔｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ／ ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタック（ｓｔａｃｋ）については同図に示す構造を参照すればよい。
本発明の放送システムにおいてデータは、ＩＳＯＢＭＦＦ（ＩＳＯ ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔ）の形態で伝送することができる。ＥＳＧ（Ｅｌｅｃｔｒｉｃａｌ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）、ＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ ／ Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。
ブロードキャストネットワークによるデータの伝送は、線形コンテンツ（ｌｉｎｅａｒ ｃｏｎｔｅｎｔ）の伝送及び／又は非線形コンテンツ（ｎｏｎ−ｌｉｎｅａｒ ｃｏｎｔｅｎｔ）の伝送を含むことができる。
ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ、データ（クローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）、緊急警報メッセージ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｍｅｓｓａｇｅ）など）の伝送は、線形コンテンツの伝送に該当し得る。
ＲＴＰペイロードは、ＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）が含まれたＲＴＰ／ＡＶストリーム形態及び／又はＩＳＯ ｂａｓｅｄ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔでカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＲＴＰペイロードの伝送は線形コンテンツの伝送に該当し得る。ＩＳＯ ｂａｓｅｄ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔでカプセル化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧ ＤＡＳＨ ｍｅｄｉａ ｓｅｇｍｅｎｔを含むことができる。
ＦＬＵＴＥベースＥＳＧの伝送、ｎｏｎ−ｔｉｍｅｄ ｄａｔａの伝送、ＮＲＴ ｃｏｎｔｅｎｔの伝送は、非線形コンテンツの伝送に該当し得る。それらは、ＭＩＭＥ ｔｙｐｅのファイル形態及び／又はＩＳＯ ｂａｓｅｄ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔでカプセル化された形態で伝送されてもよい。ＩＳＯ ｂａｓｅｄ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔでカプセル化された形態の伝送はＡ／Ｖなどに対するＭＰＥＧ ＤＡＳＨ ｍｅｄｉａ ｓｅｇｍｅｎｔを含むことができる。
ブロードバンドネットワークによる伝送は、コンテンツに対する伝送とシグナリングデータに対する伝送とに区分して考えることができる。
コンテンツの伝送は、線形コンテンツ（Ａ／Ｖ、データ（クローズドキャプション、緊急警報メッセージなど）の伝送と非線形コンテンツ（ＥＳＧ、ｎｏｎ−ｔｉｍｅｄ ｄａｔａなど）の伝送、ＭＰＥＧ ＤＡＳＨベースのＭｅｄｉａ ｓｅｇｍｅｎｔ（Ａ／Ｖ、ｄａｔａ）伝送を含む。
シグナリングデータの伝送は、放送網で伝送されるシグナリングテーブル（ｓｉｇｎａｌｉｎｇ ｔａｂｌｅ）（ＭＰＥＧ ＤＡＳＨのＭＰＤを含む）を含む伝送が可能である。
本発明の放送システムでは、放送網を介して送信された線形／非線形コンテンツ間の同期化、或いは放送網を介して伝送されるコンテンツとブロードバンドで送信されたコンテンツ間の同期化をサポートすることができる。例えば、一つのＵＤコンテンツが放送網とブロードバンドで分離されて同時に伝送される場合、受信機は、伝送プロトコルに依存したタイムライン（ｔｉｍｅｌｉｎｅ）を調整し、放送網のコンテンツとブロードバンドのコンテンツとを同期化した後、一つのＵＤコンテンツとして再構成することができる。
本発明の放送システムのアプリケーション層は、双方向性（Ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、第２スクリーン（Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ）、ＡＣＲ（ａｕｔｏｍａｔｉｃ ｃｏｎｔｅｎｔ ｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特徴を実現することができる。このような特徴は、例えば、ＡＴＳＣ２．０からＡＴＳＣ３．０への拡張において重要な特徴である。例えば、双方向性の特徴のために、ＨＴＭＬ５が用いられてもよい。
本発明の放送システムのプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）層では、コンポーネント間又は双方向アプリケーション間の空間的、時間的関係を識別するためにＨＴＭＬ及び／又はＨＴＭＬ５が用いられてもよい。
本発明でシグナリング（Ｓｉｇｎａｌｉｎｇ）は、コンテンツ及び／又はサービスの効果的な取得をサポートするためのシグナリング情報を含む。シグナリングデータは、バイナリ或いはＸＭＬ形態などで表現することができ、地上波放送網或いはブロードバンドを介して伝達することができる。
実時間放送Ａ／Ｖコンテンツ及び／又はデータの場合、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔなどで表現することができる。この場合、放送Ａ／Ｖコンテンツ及び／又はデータは、地上波放送網を介して実時間で伝達されてもよく、ＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて非実時間で伝達されてもよい。又は、放送Ａ／Ｖコンテンツ及び／又はデータに対して、インターネット網を介してＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）などを用いて実時間でコンテンツのストリーミングを受けたり、要求して受けることができる。本発明の一実施例に係る放送システムは、このようにして受けた放送Ａ／Ｖコンテンツ及び／又はデータを組み合わせ、双方向性サービス、第２スクリーンサービスなどの様々なエンハンスドサービスを視聴者に提供することができる。
図３１は、本発明の一実施例に係る、放送受信機を示す図である。
本発明の一実施例に係る放送受信機は、サービスコンテンツ取得制御器（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ Ａｃｑｕｉｓｉｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）Ｊ２０１０、インターネットインターフェース（Ｉｎｔｅｒｎｅｔ ｉｎｔｅｒｆａｃｅ）Ｊ２０２０、放送網インターフェース（Ｂｒｏａｄｃａｓｔ ｉｎｔｅｒｆａｃｅ）Ｊ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理ユニット（Ｍａｎａｇｉｎｇ ｕｎｉｔ）Ｊ２０９０及び／又は再分配モジュール（ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ ｍｏｄｕｌｅ）Ｊ２１００を含む。図面では、放送受信機の外部及び／又は内部に存在し得る外部管理装置（Ｅｘｔｅｒｎａｌ Ｍａｎａｇｅｍｅｎｔ）Ｊ２１１０が示されている。
サービスコンテンツ取得制御器Ｊ２０１０は、ブロードキャスト／ブロードバンドチャネルを介してサービス及び／又はコンテンツ、これと関連したシグナリングデータを受信する。又は、サービスコンテンツ取得制御器Ｊ２０１０は、サービス及び／又はコンテンツ、これと関連したシグナリングデータを受信するための制御を行うことができる。
インターネットインターフェースＪ２０２０は、インターネットアクセスコントロールモジュール（Ｉｎｔｅｒｎｅｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ）を含むことができる。インターネットアクセスコントロールモジュールは、ブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。又は、インターネットアクセスコントロールモジュールは、サービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御することができる。
放送網インターフェースＪ２０３０は、物理層モジュール（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｍｏｄｕｌｅ）及び／又は物理層インターフェースモジュール（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｉ／Ｆ Ｍｏｄｕｌｅ）を含むことができる。物理層モジュールは、放送チャネルを介して放送関連信号を受信する。物理層モジュールは、放送チャネルを介して受信した放送関連信号を処理（復調、デコードなど）する。物理層インターフェースモジュールは、物理層モジュールから取得した情報から、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）データグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、放送フレーム、ＲＳフレーム、又はＧＳＥなど）に変換する。
シグナリングデコーダＪ２０４０は、ブロードキャストチャネルなどを介して取得したシグナリングデータ又はシグナリング情報（以下、‘シグナリングデータ’という。）をデコードする。
サービスマップデータベースＪ２０５０は、デコードされたシグナリングデータを保存したり、受信機の他の装置（例えば、シグナリングパーサーなど）で処理されたシグナリングデータを保存する。
デコーダＪ２０６０は、受信機で受信した放送信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールドストリーミングデコーダ（Ｓｃｈｅｄｕｌｅｄ Ｓｔｒｅａｍｉｎｇ Ｄｅｃｏｄｅｒ）、ファイルデコーダ（Ｆｉｌｅ Ｄｅｃｏｄｅｒ）、ファイルデータベース（Ｆｉｌｅ ＤＢ）、オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ Ｓｔｒｅａｍｉｎｇ Ｄｅｃｏｄｅｒ）、コンポーネント同期化器（Ｃｏｍｐｏｎｅｎｔ Ｓｙｎｃｈｒｏｎｉｚｅｒ）、警報シグナリングパーサー（Ａｌｅｒｔ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）、ターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）、サービスシグナリングパーサー（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）及び／又はアプリケーションシグナリングパーサー（Ａｐｐｌｉｃａｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）を含むことができる。
スケジュールドストリーミングデコーダ（Ｓｃｈｅｄｕｌｅｄ Ｓｔｒｅａｍｉｎｇ Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムなどから実時間Ａ／Ｖ（Ａｕｄｉｏ ／ Ｖｉｄｅｏ）ストリーミングのためのオーディオ／ビデオデータ抽出し、これをデコードする。
ファイルデコーダ（Ｆｉｌｅ Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムから、ＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態データを抽出し、これをデコードする。
ファイルデータベース（Ｆｉｌｅ ＤＢ）は、ファイルデコーダから抽出したデータを保存する。
オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ Ｓｔｒｅａｍｉｎｇ Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムからオンデマンド（ｏｎ−ｄｅｍａｎｄ）ストリーミングのためのオーディオ／ビデオデータを抽出し、これをデコードする。
コンポーネント同期化器（Ｃｏｍｐｏｎｅｎｔ Ｓｙｎｃｈｒｏｎｉｚｅｒ）は、スケジュールドストリーミングデコーダ、ファイルデコーダ及び／又はオンデマンドストリーミングデコーダでデコードされたデータに基づいて、コンテンツを構成する要素間の同期化を行ったり、サービスを構成する要素間の同期化を行い、コンテンツ又はサービスを構成する。
警報シグナリングパーサー（Ａｌｅｒｔ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ＩＰデータグラムなどから警報（ａｌｅｒｔｉｎｇ）と関連したシグナリング情報を抽出し、これをパースする。
ターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツ個人化、又はターゲッティング関連したシグナリング情報を抽出し、これをパースする。ここで、ターゲッティングとは、特定視聴者の条件に合うコンテンツ又はサービスを提供することであり、当該視聴者の条件に合うコンテンツ又はサービスを識別してそれを提供する行為を指す。
サービスシグナリングパーサー（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービススキャン及び／又はサービス／コンテンツなどに関連したシグナリング情報を抽出し、これをパースする。サービス／コンテンツなどに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。
アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからアプリケーションの取得に関連したシグナリング情報を抽出し、これをパースする。アプリケーションの取得に関連したシグナリング情報は、トリガー、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ）及び／又はＴＤＯパラメータエレメントを含むことができる。
ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーでパースされたサービス／コンテンツターゲッティング関連情報を処理する。
プロセッサＪ２０８０は、受信したデータをディスプレイするための一連の処理を行う。プロセッサＪ２０８０は、警報プロセッサ（Ａｌｅｒｔ Ｐｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）及び／又はオーディオ／ビデオプロセッサ（Ａ／Ｖ Ｐｒｏｃｅｓｓｏｒ）を含むことができる。
警報プロセッサは、警報と関連したシグナリング情報を用いて、警報データを取得するように受信機を制御し、警報データをディスプレイするための処理を行う。
アプリケーションプロセッサは、アプリケーション関連情報を処理し、ダウンロードされたアプリケーションの状態及びアプリケーションに関連したディスプレイパラメータを処理する。
オーディオ／ビデオプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリング関連動作を行う。
管理ユニットＪ２０９０は、装置マネジャー（ｄｅｖｉｃｅ ｍａｎａｇｅｒ）及び／又はデータシェアリング及び通信ユニット（Ｄａｔａ Ｓｈａｒｉｎｇ ＆ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｔ）を含む。
装置マネジャーは、連結及びデータ交換などの連動可能な外部装置の追加／削除／更新などの外部装置に対する管理を行う。
データシェアリング及び通信ユニットは、受信機と外部装置（例えば、コンパニオン装置（ｃｏｍｐａｎｉｏｎ ｄｅｖｉｃｅ））間のデータ伝送及び交換関連情報を処理し、これと関連した動作を行う。伝送及び交換可能なデータは、シグナリングデータ、ＰＤＩ ｔａｂｌｅ、ＰＤＩ ｕｓｅｒ ｄａｔａ、ＰＤＩ Ｑ＆Ａ及び／又はＡ／Ｖデータであってもよい。
再分配モジュールＪ２１００は、受信機が放送信号を直接受信できない場合、放送サービス／コンテンツ関連情報及び／又はサービス／コンテンツデータの取得を行う。
外部管理装置Ｊ２１１０は、放送サービス／コンテンツサーバーなど、放送サービス／コンテンツ提供のための放送受信機の外部のモジュールのことを指す。外部管理装置の役割を担うモジュールは、放送受信機の内部に設けられてもよい。
図３２は、本発明の一実施例に係る、伝送フレーム（Ｔｒａｎｓｐｏｒｔ Ｆｒａｍｅ）を示す図である。
本発明の一実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）で伝達されるデータの集合を示す。
本発明の一実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、共通ＰＬＰ（ｃｏｍｍｏｎ ＰＬＰ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）を含むことができる。ここで、共通ＰＬＰを共通データユニットと命名してもよい。
Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機はＰ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。
Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）の構成に関する情報を含む。受信機はＬ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。
共通ＰＬＰは、ＰＬＰｎに共通に適用されるサービス情報を含む。受信機は、共通ＰＬＰを通じてＰＬＰ間の共有すべき情報を取得することができる。伝送フレーム（Ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）の構造によって共通ＰＬＰが存在しなくてもよい。Ｌ１データは、伝送フレームに共通ＰＬＰが含まれるか否かを識別する情報を含むことができる。
ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰで伝送されるかを識別する情報は、Ｌ１データ或いは共通ＰＬＰに含まれてもよい。
補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、次世代放送システムで追加される変調方式、コーディング方式及び／又はデータ処理方式のためのデータを含むことができる。例えば、補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、新しく定義されるデータ処理方式を識別する情報を含むことができる。補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、将来拡張されるシステムによる、伝送フレームの拡張に用いられてもよい。
図３３は、本発明の他の実施例に係る、伝送フレーム（Ｔｒａｎｓｐｏｒｔ Ｆｒａｍｅ）を示す図である。
本発明の他の実施例に係る伝送フレームは、物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）で伝達されるデータの集合を示す。
本発明の他の実施例に係る伝送フレームは、Ｐ１データ、Ｌ１データ、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＰＬＰｎデータ、及び／又は補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）を含むことができる。
Ｐ１データは、伝送信号を探知するために用いられる情報に該当し、チャネルチューニングのための情報が含まれる。Ｐ１データは、Ｌ１データをデコードするために必要な情報を含むことができる。受信機は、Ｐ１データに含まれるパラメータに基づいて、Ｌ１データをデコードすることができる。
Ｌ１データは、ＰＬＰの構造及び伝送フレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）の構成に関する情報を含む。受信機は、Ｌ１データを用いて、ＰＬＰｎ（ｎは自然数）を取得したり、伝送フレームの構成を把握して、必要なデータを抽出することができる。
ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）は、受信機が特定周波数内の放送サービス及びコンテンツに対するスキャンを速やかに行えるようにするために、別のチャネルで定義されてもよい。このチャネルは、物理チャネル又は論理チャネルと定義されてもよく、このようなチャネルで放送サービス関連した情報を伝送／受信することができる。
本発明の他の実施例によれば、ＦＩＣを用いて、伝送フレームに含まれた放送サービス及び／又はコンテンツとこれに関連した情報を受信機が速やかに取得することができる。これと加えて、当該伝送フレームに、一つ以上の放送局で生成したサービス／コンテンツが存在する場合、受信機はＦＩＣを用いて、放送局によるサービス／コンテンツを認知して処理することができる。
ＰＬＰｎは、コンテンツのためのデータを含む。オーディオ、ビデオ及び／又はデータなどのコンポーネントは、ＰＬＰ１〜ｎで構成されたインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰ領域に伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネント（ｃｏｍｐｏｎｅｎｔ）がそれぞれどのＰＬＰに伝送されるかを識別する情報がＬ１データ或いは共通ＰＬＰに含まれてもよい。
補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、次世代放送システムで追加される変調方式、コーディング方式及び／又はデータ処理方式のためのデータを含むことができる。例えば、補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、新しく定義されるデータ処理方式を識別する情報を含むことができる。補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）は、将来拡張されるシステムによる、伝送フレームの拡張に用いられてもよい。
図３４は、本発明の一実施例に係る、放送システムのＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐａｃｋｅｔ）及びｎｅｔｗｏｒｋ＿ｐｒｏｔｏｃｏｌフィールドの意味を示す図である。
放送システムのＴＰは、Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報、Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報、Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報、Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報、Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報及び／又はペイロード（Ｐａｙｌｏａｄ）を含むことができる。
Ｎｅｔｗｏｒｋ＿Ｐｒｏｔｏｃｏｌ情報は、図示するように、ＴＰのペイロードがどのネットワークプロトコルタイプを有するかを示す。
Ｅｒｒｏｒ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰにエラーが検出されたか否か表示する情報である。例えば、当該情報の値が０であれば、エラーが検出されていないことを示し、１であれば、エラーが検出されたことを示すことができる。
Ｓｔｕｆｆｉｎｇ＿Ｉｎｄｉｃａｔｏｒ情報は、当該ＴＰにスタッフィングバイト（ｓｔｕｆｆｉｎｇ ｂｙｔｅ）が含まれているか否かを示す。例えば、当該情報の値が０であれば、スタッフィングバイトを含んでいないことを示し、１である場合、ペイロードの前に長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）とスタッフィングバイトを含むことを示すことができる。
Ｐｏｉｎｔｅｒ＿Ｆｉｅｌｄ情報は、当該ＴＰのペイロード部分に新しいネットワークプロトコルパケットの開始部分を表示する。例えば、当該情報は、Ｔｈｅ ｍａｘｉｍｕｍ ｖａｌｕｅ（０ｘ７ＦＦ）を有することによって、新しいネットワークプロトコルパケットの開始部分がないことを示すことができる。当該情報が他の値を有する場合、ヘッダーの最後の部分から新しいネットワークプロトコルパケットの開始部分までのオフセット値に該当し得る。
Ｓｔｕｆｆｉｎｇ＿Ｂｙｔｅｓ情報は、ｓｔｕｆｆｉｎｇ＿ｉｎｄｉｃａｔｏｒ情報の値が１のとき、ヘッダー（ｈｅａｄｅｒ）とペイロードとの間を埋める値である。
ＴＰのペイロードはＩＰデータグラムを含むことができる。このような形態のＩＰデータグラムは、ＧＳＥ（Ｇｅｎｅｒｉｃ Ｓｔｒｅａｍ Ｅｎｃａｐｓｕｌａｔｉｏｎ）などを用いてカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）され、伝送されてもよい。伝送される特定ＩＰデータグラムは、受信機がサービス／コンテンツをスキャンし、これを取得するために必要なシグナリング情報を含むことができる。
図３５は、本発明の一実施例に係る、放送サーバー及び受信機を示す図である。
本発明の一実施例に係る受信機は、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）Ｊ１０７０２０、アプリケーションマネジャー（Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｒ）Ｊ１０７０３０、ダウンロードマネジャー（Ｄｏｗｎｌｏａｄ Ｍａｎａｇｅｒ） Ｊ１０７０６０、装置保存所（Ｄｅｖｉｃｅ Ｓｔｏｒａｇｅ）Ｊ１０７０７０、及び／又はアプリケーションデコーダ（Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｃｏｄｅｒ）Ｊ１０７０８０を含む。放送サーバーは、コンテンツプロバイダ／放送局（Ｃｏｎｔｅｎｔ Ｐｒｏｖｉｄｅｒ ／ Ｂｒｏａｄｃａｓｔｅｒ）Ｊ１０７０１０及び／又はアプリケーションサービスサーバー（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｒｖｅｒ）Ｊ１０７０５０を含む。
放送サーバー又は受信機に含まれるそれぞれの装置は、ハードウェア又はソフトウェアによって実装することができる。各装置がハードウェアによって実装される場合、‘マネジャー’のような表現は‘プロセッサ’に代替してもよい。
コンテンツプロバイダ／放送局Ｊ１０７０１０は、コンテンツプロバイダ或いは放送局を意味する。
シグナリングパーサーＪ１０７０２０は、コンテンツプロバイダ或いは放送局で提供する放送信号をパースするモジュールである。放送信号は、シグナリングデータ／エレメント、放送コンテンツデータ、放送と関連した付加データ及び／又はアプリケーションデータを含むことができる。
アプリケーションマネジャーＪ１０７０３０は、放送信号にアプリケーションが含まれた場合、当該アプリケーションを管理するモジュールである。アプリケーションマネジャーＪ１０７０３０は、前述したシグナリング情報、シグナリングエレメント、ＴＰＴ及び／又はトリガーを用いて、アプリケーションの位置、動作、動作実行タイミングを制御する。ここで、アプリケーションの動作は、Ａｃｔｉｖａｔｅ（Ｌａｕｎｃｈ）、Ｓｕｓｐｅｎｄ、Ｒｅｓｕｍｅ、又はＴｅｒｍｉｎａｔｅ（Ｅｘｉｔ）であってもよい。
アプリケーションサービスサーバーＪ１０７０５０は、アプリケーションを提供するサーバーである。アプリケーションサービスサーバーＪ１０７０５０は、コンテンツプロバイダ或いは放送局によって提供されてもよく、この場合、コンテンツプロバイダ／放送局Ｊ１０７０１０に含まれてもよい。
ダウンロードマネジャーＪ１０７０６０は、コンテンツプロバイダ／放送局Ｊ１０７０１０及び／又はアプリケーションサービスサーバーＪ１０７０５０で提供するＮＲＴコンテンツ又はアプリケーションに関連した情報を処理するモジュールである。ダウンロードマネジャーＪ１０７０６０は、放送信号に含まれたＮＲＴ関連シグナリング情報を取得し、シグナリング情報に基づいて、放送信号に含まれたＮＲＴコンテンツを抽出する。ダウンロードマネジャーＪ１０７０６０は、アプリケーションサービスサーバーＪ１０７０５０が提供するアプリケーションを受信処理することができる。
装置保存所Ｊ１０７０７０は、受信した放送信号、データ、コンテンツ及び／又はシグナリング情報（シグナリングエレメント）を保存することができる。
アプリケーションデコーダＪ１０７０８０は、受信したアプリケーションをデコードし、画面に表示する処理を行うことができる。
図３６は、本発明の実施例として、サービスの各タイプに含まれるコンポーネントのタイプ及びサービスタイプ間の付加サービス関係と共に、別個のサービスタイプを示す図である。
線形サービスは、一般的にＴＶに伝達し、また、ビデオデコーディング／ディスプレイケイパビリティ（オーディオのみ）を有しない受信装置に適したサービスに用いることができる。線形サービスは、単一タイムベースを有し、ゼロ以上の提示可能（ｐｒｅｓｅｎｔａｂｌｅ）ビデオコンポーネント、ゼロ以上の提示可能オーディオコンポーネント、及びゼロ以上の提示可能ＣＣコンポーネントを有することができる。線形サービスはまた、ゼロ以上のアプリケーションベースエンハンスメントを有することができる。
アプリケーションクラスは、ＡＴＳＣアプリケーションのためのコンテンツアイテム（又は、データアイテム）を示す。関係は、コンテンツアイテム（又は、データアイテム）クラスとのサブクラス関係を含む。
アプリケーションベースエンハンスメントクラスは、ＴＶサービス（又は、線形サービス）に対するアプリケーションベースエンハンスメントを示す。属性は、必須ケイパビリティ［０．．１］、非必須ケイパビリティ［０．．１］、ターゲット装置［０．．ｎ］を含み、可能な値は“プライマリ装置”、“コンパニオン装置”を含む。
関係は、アプリケーションクラスとの“包含（Ｃｏｎｔａｉｎｓ）”関係、コンテンツアイテム（又は、データアイテム）コンポーネントクラスとの“包含”関係、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）ストリームクラスとの“包含”関係及び／又はオンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの“包含”関係を含むことができる。
タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。タイムベースは以下の属性を含むことができる。
クロックレートは、このタイムベースのクロックレートを示す。
アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。関係は、アプリケーションベースエンハンスメントクラスとの“包含”関係及び／又はサービスクラスとの“サブクラス”関係を含むことができる。
アプリケーションベースエンハンスメントは、次のものを含むことができる：
取るアクションの通知を伝達する通知ストリーム
一つ以上のアプリケーション（アプリ）
アプリによって用いられるゼロ以上の他のコンテンツアイテム（又は、データアイテム、ＮＲＴコンテンツアイテム）
アプリによって管理されるゼロ以上のオンデマンドコンポーネント
アプリケーションベースエンハンスメント内のアプリのうちのゼロ又は一つがプライマリアプリとして指定されてもよい。指定されたプライマリアプリが存在すれば、それの属するサービスが選択されるやいなや活性化される。アプリはまた、通知ストリーム内の通知によって活性化されたり、一つのアプリが既に活性化された他のアプリによって活性化されてもよい。
アプリケーションベースのサービスは、一つ以上のアプリケーションベースエンハンスメントを含むサービスである。アプリケーションベースのサービス内の一つのアプリケーションベースエンハンスメントは、指定されたプライマリアプリを含むことができる。アプリケーションベースのサービスは選択的にタイムベースを含むことができる。
アプリは、コンテンツアイテム（又は、データアイテム）の特殊な場合、すなわち、共にアプリを構成するファイルの集合（ｃｏｌｌｅｃｔｉｏｎ）である。
図３７は、本発明の実施例として、ＮＲＴコンテンツアイテムクラス及びＮＲＴファイルクラス間の包含関係を示す。
ＮＲＴコンテンツアイテムは一つ以上のＮＲＴファイルを含み、ＮＲＴファイルは一つ以上のＮＲＴコンテンツアイテムに属することができる。
それらのクラスを検討する一方法は、ＮＲＴコンテンツアイテムが基本的に提示可能ＮＲＴファイルベースコンポーネント、すなわち、他のファイルと結合しないで消費されてもよいＮＲＴファイルセットであってもよく、ＮＲＴファイルが基本的にエレメンタリＮＲＴファイルベースコンポーネント、すなわち、原子単位のコンポーネントであってもよいということである。
ＮＲＴコンテンツアイテムは、連続したコンポーネント、不連続したコンポーネント、又はその組合せを含むことができる。
図３８は、本発明の一実施例に係る、サービスタイプ及びコンポーネントタイプによる属性を示すテーブルである。
アプリケーション（Ａｐｐ）は、双方向性をサポートするＮＲＴコンテンツアイテムの一種である。アプリケーションの属性は、ＴＰＴなどのようなシグナリングデータによって提供されてもよい。アプリケーションは、ＮＲＴコンテンツアイテムクラスとはサブクラスの関係にある。例えば、ＮＲＴコンテンツアイテムには一つ以上のアプリケーションが含まれてもよい。
アプリケーションベースエンハンスメント（Ａｐｐ−Ｂａｓｅｄ Ｅｎｈａｎｃｅｍｅｎｔ）は、アプリケーションベースに向上したイベント／コンテンツのことをいう。
アプリケーションベースエンハンスメントの属性には、次の内容が含まれてもよい。
必須ケイパビリティ［０．．１］−エンハンスメントの意味のあるレンディション（ｒｅｎｄｉｔｉｏｎ）に必要な受信機ケイパビリティ。
非必須ケイパビリティ［０．．１］−エンハンスメントの最上のレンディションに有用であるが、エンハンスメントの意味のあるレンディションに必須のものではない受信機ケイパビリティ。
ターゲット装置［０．．ｎ］−単に付加（ａｄｊｕｎｃｔ）データサービスのために可能な値。
ターゲット装置は、プライマリ装置とコンパニオン（ｃｏｍｐａｎｉｏｎ）装置とに区別することができる。プライマリ装置としてはＴＶ受信機のような装置を含むことができる。コンパニオン装置としては、スマートフォン、タブレット、ノートパソコン及び／又は小型モニタを含むことができる。
アプリケーションベースエンハンスメントは、Ａｐｐクラスとの関係を含み、これはアプリケーションベースエンハンスメントに含まれるアプリケーションとの関係のためのものであろう。
アプリケーションベースエンハンスメントは、ＮＲＴコンテンツアイテムクラスとの関係を含み、これは、アプリケーションベースエンハンスメントに含まれるアプリケーションによって用いられるＮＲＴコンテンツアイテムとの関係のためのものである。
アプリケーションベースエンハンスメントは、通知ストリーム（Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｔｒｅａｍ）クラスとの関係を含み、これは、アプリケーションの動作と基本線形（Ｌｉｎｅａｒ）タイムベースとの同期化のための通知を送信する通知ストリームとの関係のためのものである。
アプリケーションベースエンハンスメントは、オンデマンド（ＯｎＤｅｍａｎｄ）コンポーネントクラスとの関係を含み、これは、アプリケーションによって管理される視聴者要求コンポーネントとの関係のためのものである。
図３９は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
タイムベースは、線形サービスのコンポーネントを同期化するタイムラインを確立するために用いられるメタデータを示す。
タイムベースの属性は、タイムベースＩＤ及び／又はクロックレートを含むことができる。
タイムベースＩＤは、タイムベースの識別子である。クロックレートはタイムベースのクロックレートに対応する。
図４０は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
線形サービスは、線形サービスを示す。
線形サービスは、属性がビデオコンポーネントの役割である提示可能ビデオコンポーネントクラスとの関係を含む関係を有する。ビデオコンポーネントの役割は、プライマリ（デフォルト）ビデオ、代替カメラビュー（ａｌｔｅｒｎａｔｉｖｅ ｃａｍｅｒａ ｖｉｅｗ）、他の代替ビデオコンポーネント、手話（ｓｉｇｎ ｌａｎｇｕａｇｅ）（すなわち、ＡＳＬ）インセット（ｉｎｓｅｔ）、又はフォローサブジェクト特徴（ｆｏｌｌｏｗ−ｓｕｂｊｅｃｔ ｆｅａｔｕｒｅ）が個別ビデオコンポーネントによってサポートされる場合に、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示す可能な値を有することができる。
線形サービスの関係は、提示可能オーディオコンポーネントクラスとの関係、提示可能ＣＣコンポーネントクラスとの関係、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係、及び／又はサービスクラスとの“サブクラス”関係を含む。
アプリケーションベースのサービスは、アプリケーションベースのサービスを示す。
アプリケーションベースのサービスは、タイムベースクラスとの関係、アプリケーションベースエンハンスメントクラスとの関係及び／又はサービスクラスとの“サブクラス”関係を含む関係を有する。
図４１は、本発明の実施例として、サービスタイプ及びコンポーネントタイプの属性を示す他のテーブルを示す。
プログラムは、プログラムを示す。
プログラムの属性は、ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ、ＳｔａｒｔＴｉｍｅ、ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ、ＴｅｘｔｕａｌＴｉｔｌｅ、ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ、Ｇｅｎｒｅ、ＧｒａｐｈｉｃａｌＩｃｏｎ、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ、ターゲッティング／個人化特性、コンテンツ／サービス保護特性、及び／又は“ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）モデル”と定義された他の特性を含む。
ＰｒｏｇｒａｍＩｄｅｎｔｉｆｉｅｒ［１］は、プログラムの固有識別子に対応する。
ＳｔａｒｔＴｉｍｅ［１］は、プログラムが始まるようにスケジュールされた実測日時及び時間（ｗａｌｌ ｃｌｏｃｋｄａｔｅ ａｎｄ ｔｉｍｅ）に対応する。
ＰｒｏｇｒａｍＤｕｒａｔｉｏｎ［１］は、プログラムの開始からプログラムの終了までのスケジュールされた実測時間（ｗａｌｌ ｃｌｏｃｋ ｔｉｍｅ）に対応する。
ＴｅｘｔｕａｌＴｉｔｌｅ［１．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能タイトル−存在しないなら、関連したショーのＴｅｘｔｕａｌＴｉｔｌｅに対するデフォルト−に対応する。
ＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎ［０．．ｎ］は、複数の言語からなるプログラムの人間読み取り可能説明−存在しないなら、関連したショーのＴｅｘｔｕａｌＤｅｓｃｒｉｐｔｉｏｎに対するデフォルト−に対応する。
Ｇｅｎｒｅ［０．．ｎ］は、プログラムのジャンル-存在しないなら、関連したショーのジャンルに対するデフォルト−に対応する。
ＧｒａｐｈｉｃａｌＩｃｏｎ［０．．ｎ］は、複数のサイズからなる（例えば、ＥＳＧにおいて）プログラムを示すアイコン−存在しないなら、関連したショーのＧｒａｐｈｉｃａｌＩｃｏｎに対するデフォルト−に対応する。
ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ［０．．ｎ］は、複数の領域に対してプログラムに対するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティング−存在しないなら、関連したショーのＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇに対するデフォルト−に対応する。
ターゲッティング／個人化特性は、プログラムのターゲッティングなどを決定するために用いられる特性−存在しないなら、関連したショーのターゲッティング／個人化特性に対するデフォルト−に対応する。
コンテンツ／サービス保護特性は、プログラムのコンテンツ保護及び／又はサービス保護に用いられる特性−存在しないなら、関連したショーのコンテンツ／サービス保護に対するデフォルト−に対応する。
プログラムは、次のものを含む関係を有することができる：
線形サービスクラスとの“ＰｒｏｇｒａｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＣｏｎｔｅｎｔＩｔｅｍＯｆ”関係、アプリケーションベースのサービスクラスとの“ＯｎＤｅｍａｎｄＣｏｍｐｏｎｅｎｔＯｆ”関係、提示可能ビデオコンポーネントクラスとの“包含”関係、提示可能オーディオコンポーネントクラスとの“包含”関係、提示可能ＣＣコンポーネントクラスとの“包含”関係、アプリケーションベースエンハンスメントクラスとの“包含”関係、タイムベースクラスとの“包含”関係、ショークラスとの“Ｂａｓｅｄ−ｏｎ”関係、及び／又はセグメントクラスとの“包含”関係。
提示可能ビデオコンポーネントクラスとの“包含”関係は、可能な値がプライマリ（デフォルト）ビデオ、代替カメラビュー、他の代替ビデオコンポーネント、手話（例えば、ＡＳＬ）インセット及び／又はフォローサブジェクト特徴が個別ビデオコンポーネントによってサポートされる場合、後続するサブジェクトの名と共にフォローサブジェクトビデオのうちいずれかを示すビデオコンポーネントの役割を含む属性を有することができる。
セグメントクラスとの“包含”関係の属性は、プログラムの開始に対してセグメントの開始時間を特定するＲｅｌａｔｉｖｅＳｅｇｍｅｎｔＳｔａｒｔＴｉｍｅを有することができる。
ＮＲＴコンテンツアイテムコンポーネントは、プログラムと同じ構造を有することができるが、ストリーミング形態よりはファイルの形態で伝達されればよい。このようなプログラムはそれと関連したインタラクティブサービスなどの付加（ａｄｊｕｎｃｔ）データサービスを有することができる。
図４２は、本発明の実施例として、ＣｏｎｔｅｎｔＩｔｅｍ及びＯｎＤｅｍａｎｄコンテンツに対する定義を示す。
将来のハイブリッド放送システムは、サービスのタイプに対する線形サービス及び／又はアプリケーションベースのサービスを有することができる。線形サービスがスケジュールによって提示される連続したコンポーネント及び放送で定義されるタイムベースで構成されると、線形サービスは、トリガーされたアプリケーションエンハンスメントを有することができる。
指示されたように、現在定義された提示可能コンテンツコンポーネントと共に、次のタイプのサービスが定義される。他のサービスタイプ及びコンポーネントが定義されてもよい。
線形サービスは（様々なタイプのタイムシフト視聴メカニズムが消費者によって使われて消費時間をシフトできることを除けば）、プライマリコンテンツがスケジュールによって消費される連続コンポーネント及び放送によって定義されたタイムベースで構成されるサービスである。
・ゼロ以上のビデオコンポーネント
・ゼロ以上のオーディオコンポーネント
・ゼロ以上のクローズドキャプションコンポーネント
・コンポーネントを同期化するために用いられるタイムベース
・ゼロ以上のトリガーされたアプリケーションベースエンハンスメント及び／又は
・ゼロ以上の自動起動（ｌａｕｎｃｈ）アプリケーションベースエンハンスメント。
ゼロ以上のトリガーされたアプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、起動されてサービスの一部として伝達された活性化通知によって同期化された方式でアクションを行うようにするアプリケーションで構成される。エンハンスメントコンポーネントは、次のものを含むことができる：
・活性化通知のストリーム
・通知のターゲットである一つ以上のアプリケーション
・ゼロ以上のコンテンツアイテム、及び／又は
・ゼロ以上のオンデマンドコンポーネント
選択的に、アプリの一つは、“プライマリアプリ”として指定されてもよい。指定されたプライマリアプリが存在すると、根源的なサービスが選択されるやいなや活性化されてもよい。他のアプリは、通知ストリーム内の通知によって活性化されたり、アプリが既に活性化された他のアプリによって活性化されてもよい。
ゼロ以上の自動起動アプリケーションベースエンハンスメントに対して、それぞれのエンハンスメントは、サービスが選択される度に自動で起動されるアプリで構成される。エンハンスメントコンポーネントは次のものを含むことができる：
・自動起動されたアプリケーション
・ゼロ以上の活性化通知のストリーム、及び／又は
・ゼロ以上のコンテンツアイテム。
ここで、線形サービスは、自動起動されたアプリケーションベースエンハンスメント及びトリガーされたアプリケーションベースエンハンスメント、例えば、自動起動されたアプリケーションベースエンハンスメントを有し、対象となるアド（広告）挿入及びトリガーされたアプリケーションベースエンハンスメントを行って、インタラクティブ視聴経験を提供することができる。
アプリケーションベースのサービスは、サービスが選択される度に指定されたアプリケーションが起動されるサービスである。これは、アプリケーションベースのサービス内のアプリケーションベースエンハンスメントが指定されたプライマリアプリを含むという制限を有する一つのアプリケーションベースエンハンスメントで構成されてもよい。
アプリは、コンテンツアイテムの特殊な場合であってもよく、すなわち、アプリサービスコンポーネントを共に構成するファイルの集合が複数のサービス間で共有されてもよい。
アプリケーションベースのサービス内のアプリケーションは、オンデマンドコンテンツの提示を開始することができる。
パッケージングされたアプリケーションを有する自動起動アプリケーションベースのサービスの概念の併合に関するいくつかのアプローチが存在する。これは、任意の形態でサービスガイドに現れてもよい。将来ＴＶセットは、次の特徴を有することができる。
ユーザは、サービスガイド内の自動起動アプリケーションベースのサービスを選択して“お気に入り（ｆａｖｏｒｉｔｅ）”サービスとして指定したり、そのサービス又はそのようなものを“取得”することができる。これは、サービスの基礎を形成するアプリがダウンロードされ、ＴＶセットにインストールされるようにすることができる。すると、ユーザは、“お気に入り”又は“取得された”アプリを見ることを要求することができ、ダウンロードされてインストールされたアプリを全て示しながら、スマートフォン上にあるものと類似のディスプレイを得ることができる。すると、ユーザは、その中から実行されるものを選択できる。この効果は、サービスガイドがアプリストアと類似に動作することである。
及び／又は、任意のアプリが“お気に入り”／“取得された”サービスとして自動起動アプリケーションベースのサービスを識別するようにするＡＰＩが存在してもよい。（このようなＡＰＩの実装は、ユーザへの“確実ですか”というクエリーを含み、不良アプリ（ｒｏｇｕｅ ａｐｐ）がユーザの知らないうちに（ｂｅｈｉｎｄ ｕｓｅｒ’ｓ ｂａｃｋ）それを行うことを防ぐことができる。これは、“パッケージされたアプリ”をインストールすることに当たる効果を有することができる。
それぞれのサービスは、（コンテンツに対応する）コンテンツアイテムを含むことができる。コンテンツアイテムは、統合された全体として消費されるように意図される一つ以上のファイルの集合である。オンデマンドコンテンツは、視聴者によって選択された時間に（一般に、アプリケーションによって提供されるユーザインターフェースを介して）提示されるコンテンツであり、このようなコンテンツは、連続したコンテンツ（例えば、オーディオ／ビデオ）又は非周期的コンテンツ（例えば、ＨＴＭＬページ又はイメージ）で構成されてもよい。
図４３は、本発明の実施例として、Ｃｏｍｐｌｅｘ Ａｕｄｉｏ Ｃｏｍｐｏｎｅｎｔの例を示す。
提示可能オーディオコンポーネントは、完壁なメインコンポーネントを含むＰｉｃｋＯｎｅコンポーネント及び音楽、ダイアログ及び混合されるエフェクトトラックを含むコンポーネントであってもよい。完壁なメインオーディオコンポーネント及び音楽コンポーネントは、別個のビットレートでエンコーディングによって構成されるエレメンタリコンポーネントを含むＰｉｃｋＯｎｅコンポーネントであるが、ダイアログ及びエフェクトコンポーネントはエレメンタリコンポーネントであってもよい。
このアプローチは、サービスが直接サービスの提示可能コンポーネントだけを列挙した後、任意のコンプレックスコンポーネントのメンバーコンポーネントを階層的に列挙しようとすることについて、より一層明瞭なピクチャを提供する。
コンポーネントモデルの可能な無限反復（ｒｅｃｕｒｓｉｏｎ）を制限するために、次の制限が与えられてもよい。任意の連続したコンポーネントは、上位レベルがＰｉｃｋＯｎｅで構成され、中間レベルがコンポジットコンポーネントで構成され、下位レベルがＰｉｃｋＯｎｅコンポーネントで構成される３レベル階層に適合し得る。任意の特定連続コンポーネントは連続したコンポーネントが単純にエレメンタリコンポーネントであるヌルサブセットを含み、３個のレベル又はその任意のサブセットを含むことができる。
図４４は、本発明の一実施例に係る、アプリケーションと関連した属性情報を示す図である。
アプリケーションと関連した属性情報は、ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を含むことができる。
本発明の一実施例によって追加され得るアプリケーションと関連した属性情報は、Ａｐｐｌｉｃａｔｉｏｎ ＩＤ情報、Ａｐｐｌｉｃａｔｉｏｎ ｖｅｒｓｉｏｎ情報、Ａｐｐｌｉｃａｔｉｏｎ ｔｙｐｅ情報、Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報、Ｃａｐａｂｉｌｉｔｉｅｓ情報、Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報、Ｆｒｅｑｕｅｎｃｙ ｏｆ ｕｓｅ情報、Ｅｘｐｉｒａｔｉｏｎ ｄａｔｅ情報、Ｄａｔａ ｉｔｅｍ ｎｅｅｄｅｄ ｂｙ ａｐｐｌｉｃａｔｉｏｎ情報、Ｓｅｃｕｒｉｔｙ ｐｒｏｐｅｒｔｉｅｓ情報、Ｔａｒｇｅｔ ｄｅｖｉｃｅｓ情報、及び／又はＣｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を含むことができる。
Ａｐｐｌｉｃａｔｉｏｎ ＩＤ情報は、アプリケーションを識別できる固有のＩＤを示す。
Ａｐｐｌｉｃａｔｉｏｎ ｖｅｒｓｉｏｎ情報は、アプリケーションのバージョンを示す。
Ａｐｐｌｉｃａｔｉｏｎ ｔｙｐｅ情報は、アプリケーションのタイプを示す。
Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報は、アプリケーションの位置を示す。例えば、Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報は、アプリケーションを受信できるＵＲＬを含むことができる。
Ｃａｐａｂｉｌｉｔｉｅｓ情報は、アプリケーションをレンダ（ｒｅｎｄｅｒ）できるようにするケイパビリティ（ｃａｐａｂｉｌｉｔｙ）属性を示す。
Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報は、放送ストリーミングとアプリケーション間の同期化（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）レベル情報を示す。例えば、Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報は、プログラム或いはイベント単位、時間単位（例えば、２秒以内）、ｌｉｐ ｓｙｎｃ、及び／又はフレームレベル同期などの内容を示すことができる。
Ｆｒｅｑｕｅｎｃｙ ｏｆ ｕｓｅ情報は、アプリケーションの使用頻度を示す。
Ｅｘｐｉｒａｔｉｏｎ ｄａｔｅ情報は、アプリケーションの使用満了日／満了時刻を示す。
Ｄａｔａ ｉｔｅｍ ｎｅｅｄｅｄ ｂｙ ａｐｐｌｉｃａｉｏｎ情報は、アプリケーションで用いるデータ情報を示す。
Ｓｅｃｕｒｉｔｙ ｐｒｏｐｅｒｔｉｅｓ情報は、アプリケーションのセキュリティ関連情報を示す。
Ｔａｒｇｅｔ ｄｅｖｉｃｅｓ情報は、アプリケーションが用いられるターゲット装置情報を示す。例えば、ターゲット装置情報は、当該アプリケーションの実行されるターゲット機器がＴＶ及び／又はモバイル機器であることを示すことができる。
Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、アプリケーションの使用可能な等級を示す。例えば、Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、アプリケーションを利用できる年齢制限情報を含むことができる。
図４５は、本発明の一実施例に係る、放送の個人化のための手順を示す図である。
前述したように、受信機は、アプリケーションの通知を制御することもできるが、受信機でアプリケーションの通知を制御しないか、制御できない場合を考慮することもできる。この場合には、各アプリケーション別に、ユーザがＯｐｔ−ｉｎ／ｏｕｔ設定を行うことができる。
この場合、ＰＤＩ（Ｐｒｏｆｉｌｅｓ，Ｄｅｍｏｇｒａｐｈｉｃｓ，ａｎｄ Ｉｎｔｅｒｅｓｔｓ）テーブルを用いることができる。本発明の一実施例に係る放送システムでは、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）設定のためのＰＤＩテーブルを用いて、ユーザにプロフィール別、地域別、及び／又は関心別に個人化された放送コンテンツ及びアプリケーションを示すことができる。このような個人化のためのＰＤＩテーブルを用いてアプリケーション別にＯｐｔ−ｉｎ／ｏｕｔ設定をすることができる。Ｏｐｔ−ｉｎは、ユーザが特定アプリケーションの通知を受けるように設定する場合にのみ、当該通知を受信機でディスプレイ処理する方式であり、Ｏｐｔ−ｏｕｔは、ユーザが特定アプリケーションの通知を受けることを拒否するように設定しない場合には、当該通知を受信して処理する方式である。
図面は、個人化サービスのためのデジタル放送受信機（又は、受信機）を含む個人化放送システムを示す。本実施例に係る個人化サービスは、ユーザ情報に基づいてユーザに適したコンテンツを選択して提供するサービスである。また、本実施例に係る個人化放送システムは、放送サービス又は個人化サービスを提供する次世代放送サービスを提供することができる。
本発明の実施例によれば、ユーザ情報の例として、ユーザＰＤＩ（ｐｒｏｆｉｌｅｓ，ｄｅｍｏｇｒａｐｈｉｃｓ ａｎｄ Ｉｎｔｅｒｅｓｔｓ）が定義される。以下、個人化放送システムのエレメントが記述される。
質問表に対する回答（ａｎｓｗｅｒｓ）は、併せてユーザＰＤＩ（ｐｒｏｆｉｌｅｓ，ｄｅｍｏｇｒａｐｈｉｃｓ ａｎｄ Ｉｎｔｅｒｅｓｔｓ）を示す。質問表及び特定ユーザによって与えられた回答をカプセル化するデータ構造を、ＰＤＩ質問表又はＰＤＩテーブルという。データ構造は、回答が利用可能な時には回答を収容するが、ネットワーク、放送局又はコンテンツプロバイダによって提供されるＰＤＩテーブルは、回答データを含まない。ＰＤＩテーブル内のエントリの質問部分は非公式的に“ＰＤＩ質問”又は“ＰＤＩ−Ｑ”という。与えられたＰＤＩ質問に対する回答は、非公式的に“ＰＤＩ−Ａ”という。フィルタ基準のセットは非公式的に“ＰＤＩ−ＦＣ”という。
ＡＴＳＣ−２．０可能受信機などのクライアント装置は、質問表内の質問に対する回答の生成を許容する機能を含む（ＰＤＩ−Ａインスタンス）。このＰＤＩ生成機能は、入力としてＰＤＩ−Ｑインスタンスを使用し、出力としてＰＤＩ−Ａインスタンスを生成する。ＰＤＩ−Ｑ及びＰＤＩ−Ａは、受信機内の不揮発性保存装置に保存される。クライアントはまた、ＰＤＩ−ＦＣインスタンスに対してＰＤＩ−Ａインスタンスを比較し、どのアイテムがダウンロード及び使用に適合するかを決定するフィルタリング機能を提供する。
図示されたサービスプロバイダ側で、ＰＤＩテーブルを維持及び分配する機能が実装される。コンテンツと共にコンテンツメタデータが生成される。メタデータは、ＰＤＩテーブル内の質問に基づいたＰＤＩ−ＦＣインスタンスである。
個人化放送システムは、コンテンツプロバイダ（又は、放送局）Ｊ１６０７０及び／又は受信機Ｊ１６０１０を含むことができる。本実施例に係る受信機Ｊ１６０１０は、ＰＤＩエンジン（図示せず）、フィルタリングエンジンＪ１６０２０、ＰＤＩストアＪ１６０３０、コンテンツストアＪ１６０４０、宣言コンテンツモジュールＪ１６０５０及び／又はＰＤＩ操作アプリケーションＪ１６０６０を含むことができる。本実施例に係る受信機Ｊ１６０１０は、コンテンツプロバイダＪ１６０７０からコンテンツなどを受信することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。
本実施例に係るコンテンツプロバイダＪ１６０７０は、コンテンツ、ＰＤＩ質問表及び／又はフィルタリング基準を受信機Ｊ１６０１０に送信することができる。質問表及び特定ユーザによって与えられた回答をカプセル化するデータ構造は、ＰＤＩ質問表という。本発明の実施例によって、ＰＤＩ質問表は、ユーザのＰＤＩなどに関連した質問（又は、ＰＤＩ質問）を含むことができる。
受信機Ｊ１６０１０は、コンテンツプロバイダＪ１６０７０から受信したコンテンツ、ＰＤＩ質問表及び／又はフィルタリング基準を処理することができる。以下、デジタル放送システムの受信機Ｊ１６０１０に含まれたモジュールの動作について説明する。
本実施例に係るＰＤＩエンジンは、コンテンツプロバイダＪ１６０７０によって提供されるＰＤＩ質問表を受信することができる。ＰＤＩエンジンは、ＰＤＩ質問表に含まれるＰＤＩ質問をＰＤＩ操作アプリケーションＪ１６０６０に送信することができる。当該ＰＤＩ質問に対応するユーザ入力が存在すると、ＰＤＩエンジンは、ユーザ回答及びＰＤＩ操作アプリケーションＪ１６０６０からの該当のＰＤＩ質問に関連した他の情報（以下、ＰＤＩ回答という）を受信することができる。その後、ＰＤＩエンジンは、個人化サービスを提供してＰＤＩデータを生成するためにＰＤＩ質問及びＰＤＩ回答を処理することができる。すなわち、本発明の実施例によって、ＰＤＩデータは、上述したＰＤＩ質問及び／又はＰＤＩ回答を含むことができる。したがって、ＰＤＩ質問表に対するＰＤＩ回答は、併せてユーザＰＤＩ（ｐｒｏｆｉｌｅ，ｄｅｍｏｇｒａｐｈｉｃｓ，ａｎｄ ｉｎｔｅｒｅｓｔｓ）を示す。
また、本実施例に係るＰＤＩエンジンは、受信されたＰＤＩ回答を用いてＰＤＩデータをアップデートすることができる。具体的に、ＰＤＩエンジンは、ＰＤＩ回答のＩＤを用いてＰＤＩデータを削除、追加及び／又は訂正することができる。本発明の実施例のＰＤＩ回答のＩＤを以下に詳しく説明する。また、他のモジュールがＰＤＩエンジンにＰＤＩデータを送信するように要求すると、ＰＤＩエンジンは、該当のモジュールに該当の要求に適切なＰＤＩデータを送信することができる。
本実施例に係るフィルタリングエンジンＪ１６０２０は、ＰＤＩデータ及びフィルタリング基準によってコンテンツをフィルタすることができる。フィルタリング基準は、ＰＤＩデータを用いてユーザに適したコンテンツだけをフィルタするフィルタリング基準セットのことをいう。具体的に、フィルタリングエンジンＪ１６０２０は、ＰＤＩエンジンからＰＤＩデータを受信し、コンテンツプロバイダＪ１６０７０からコンテンツ及び／又はフィルタリング基準を受信することができる。また、コンテンツプロバイダＪ１６０７０が宣言コンテンツに関連したパラメータを送信すると、コンテンツプロバイダＪ１６０７０は、宣言コンテンツに関連したフィルタリング基準テーブルを共に送信することができる。その後、フィルタリングエンジンＪ１６０２０は、フィルタリング基準及びＰＤＩデータをマッチング及び比較し、比較結果を用いてコンテンツをダウンロードすることができる。ダウンロードされたコンテンツをコンテンツストアＪ１６０４０に保存することができる。
本発明の実施例によれば、ＰＤＩ操作アプリケーションＪ１６０６０は、ＰＤＩエンジンから受信されたＰＤＩをディスプレイし、該当のＰＤＩ質問に対するＰＤＩ回答をユーザから受信することができる。ユーザは、遠隔制御器を用いて、ディスプレイされたＰＤＩ質問に対するＰＤＩ回答を受信機Ｊ１６０１０に送信することができる。ＰＤＩ操作アプリケーションＪ１６０６０は、受信されたＰＤＩ回答をＰＤＩエンジン７０１に送信することができる。
本実施例に係る宣言コンテンツモジュールＪ１６０５０は、ＰＤＩエンジンをアクセスしてＰＤＩデータを取得することができる。また、宣言コンテンツモジュールＪ１６０５０は、コンテンツプロバイダＪ１６０７０によって提供された宣言コンテンツを受信することができる。本発明の実施例によれば、宣言コンテンツは、受信機Ｊ１６０１０によって実行されたアプリケーションに関連したコンテンツであってもよく、トリガーされた宣言オブジェクト（ＴＤＯ；ｔｒｉｇｇｅｒｅｄ ｄｅｃｌａｒａｔｉｖｅ ｏｂｊｅｃｔ）などの宣言オブジェクト（ＤＯ）を含むことができる。
本実施例に係る宣言コンテンツモジュールＪ１６０５０は、ＰＤＩストアＪ１６０３０をアクセスしてＰＤＩ質問及び／又はＰＤＩ回答を得ることができる。この場合、宣言コンテンツモジュールＪ１６０５０は、アプリケーションプログラミングインターフェース（ＡＰＩ）を用いることができる。具体的に、宣言コンテンツモジュールＪ１６０５０は、ＡＰＩを用いてＰＤＩストアＪ１６０３０を検索して少なくとも一つのＰＤＩ質問を取得することができる。その後、宣言コンテンツモジュールＪ１６０５０は、ＰＤＩ質問を送信し、ＰＤＩ回答を受信し、受信されたＰＤＩ回答をＰＤＩ操作アプリケーションＪ１６０６０を介してＰＤＩストアＪ１６０３０に送信することができる。
本実施例に係るＰＤＩストアＪ１６０３０は、ＰＤＩ質問及び／又はＰＤＩ回答を保存することができる。
本実施例に係るコンテンツストアＪ１６０４０は、フィルタされたコンテンツを保存することができる。
ＰＤＩエンジンは、コンテンツプロバイダＪ１６０７０からＰＤＩ質問表を受信することができる。受信機Ｊ１６０１０は、ＰＤＩ操作アプリケーションＪ１６０６０を介して受信されたＰＤＩ質問表のＰＤＩ質問をディスプレイし、ユーザから該当のＰＤＩ質問に対するＰＤＩ回答を受信することができる。ＰＤＩエンジンは、ＰＤＩ質問及び／又はＰＤＩ回答を含むＰＤＩデータをフィルタリングエンジンＪ１６０２０に送信することができる。フィルタリングエンジンＪ１６０２０は、ＰＤＩデータ及びフィルタリング基準を通じてコンテンツをフィルタすることができる。したがって、受信機Ｊ１６０１０は、ユーザにフィルタされたコンテンツを提供して個人化サービスを実現することができる。
図４６は、本発明の一実施例に係る、アプリケーション別にユーザ設定をするためのシグナリング構造を示す図である。
アプリケーション別にＯｐｔ−ｉｎ／ｏｕｔ（例えば、アプリケーションの通知のｏｎ／ｏｆｆに対するユーザの設定など）設定のために、アプリケーションを実行させるためのトリガーに用いられるグローバルに一意の（ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ）ａｐｐｌｉｃａｔｉｏｎ ＩＤをＰＤＩテーブル ＩＤとして用いることができる。アプリケーショントリガーテーブル（Ａｐｐｌｉｃａｔｉｏｎ Ｔｒｉｇｇｅｒ Ｔａｂｌｅ）の内容は、前述したアプリシグナリングパーサー（Ａｐｐ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）から抽出することができ、ＰＤＩテーブルの内容は、前述したトリガーシグナリングパーサー (Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ)から抽出することができる。ここで、アプリケーショントリガーテーブルは、前述したＴＰＴ又はＴＤＯパラメータエレメントに該当し得る。
受信機は、アプリケーショントリガーテーブルで説明されるアプリケーションを実行する前に、アプリケーショントリガーテーブルから該当のアプリケーションのグローバルＩＤを識別する。ここで、グローバルＩＤは、放送システムで提供する全アプリケーションにおいて、特定アプリケーションのための一意の値であり、特定アプリケーションを識別する情報である。
受信機は、該当のアプリケーションのグローバルＩＤと同じ情報を有する、ＰＤＩテーブルＩＤを識別し、該当のＰＤＩテーブル内の各ユーザによる情報を用いて、ユーザによるアプリケーションの通知を設定する。
アプリケーショントリガーテーブルに含まれる他の情報に関する説明は、前述したＴＰＴに関する説明又は図面に現れた説明で代える。また、ＰＤＩテーブルに含まれる他の情報に関する説明は、前述したＰＤＩテーブルに関する説明又は図面に現れた説明で代える。
図４７は、本発明の他の実施例に係る、アプリケーション別にユーザ設定をするためのシグナリング構造を示す図である。
図面を参照すると、ＰＤＩテーブルにａｐｐＩＤ又はｇｌｏｂａｌＩＤを追加し、該当のＰＤＩテーブルの情報が適用されるアプリケーションを指定してもよい。
受信機はアプリケーションの通知をディスプレイ処理する前に、ＰＤＩテーブルに含まれるａｐｐＩＤを用いて、該当のアプリケーションに適用されるＰＤＩ関連情報があるか識別する。受信機は、ＰＤＩ関連情報に基づいて、該当のアプリケーションに対する通知をディスプレイ処理するか否かを決定することができる。
図４８は、本発明の一実施例に係る、ＰＤＩテーブルを用いたアプリケーションのＯｐｔ−ｉｎ／ｏｕｔ設定に対する手順を示す図である。
サービスプロバイダ（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）は、アプリケーションのＯｐｔ−ｉｎ／ｏｕｔ設定に関連したＰＤＩ Ｑｕｅｓｔｉｏｎを含んでいるＰＤＩテーブルを有することができる。このようなＰＤＩテーブルに含まれた情報は、ユーザの提供した情報又はサービスプロバイダの収集した情報に基づいて生成されてもよい。（ｓｔｅｐ１）
アプリケーションに対する同意／非同意の設定に関連したＰＤＩテーブルは、受信機（ＴＶ）に伝達されてもよい。この時、ＰＤＩテーブルのＩＤは、アプリケーションのＩＤ（ａｐｐＩＤ又はｇｌｏｂａｌＩＤ）と同じ値を有することができる。（ｓｔｅｐ２）
サービスプロバイダは、該当のアプリケーションに対するトリガー及び／又はＴＰＴを受信機（ＴＶ）に送ることができる。（ｓｔｅｐ３）
ユーザがアプリケーションに対するＯｐｔ−ｉｎ／ｏｕｔ設定をするために“Ｓｅｔｔｉｎｇ”を選択することができ、アプリケーションに対するＰＤＩ ｓｅｔｔｉｎｇ ａｐｐが実行されてもよい。（ｓｔｅｐ４）
ＰＤＩ ｓｅｔｔｉｎｇ ａｐｐによってアプリケーションのＯｐｔ−ｉｎ／ｏｕｔに対するユーザの設定をＰＤＩストア（ＰＤＩ ｓｔｏｒｅ）に保存することができる。（ｓｔｅｐ５）
図４９は、本発明の一実施例に係る、アプリケーションのＯｐｔ−ｉｎ／ｏｕｔを設定するためのＵＩを示す図である。
受信機がトリガーを受信すると、（ａ）のようなＵＩ（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）をディスプレイすることがきる。ユーザは該当のアプリケーションを直接実行したり（ｅｎｔｅｒ）、該当のアプリケーションに対する設定（ｓｅｔｔｉｎｇ）を行うことができる。
ユーザが‘ｓｅｔｔｉｎｇ’を選択した場合、ＰＤＩ ｓｅｔｔｉｎｇ ａｐｐ又は受信機自体のＵＩがさらに実行されてもよく、これによって、ユーザが該当のアプリケーションに対する使用同意をするか否か設定することができる。このような情報はＰＤＩテーブルと共に保存されてもよい。
図５０は、本発明の一実施例に係る、ＰＤＩテーブルを用いたアプリケーションのＯｐｔ−ｉｎ／ｏｕｔ設定の完了後、受信機（ＴＶ）がサービスプロバイダから同一ａｐｐｌｉｃａｔｉｏｎ ＩＤを有するアプリケーションのトリガーを受信した場合、これに対する処理手順を示す図である。
サービスプロバイダが、Ｏｐｔ−ｉｎ／ｏｕｔ設定が完了したアプリケーションに対するトリガーを受信機に伝達する。（ｓｔｅｐ１）
受信機（ＴＶ）のアプリケーションマネジャーは、該当のトリガーをパースし、ａｐｐｌｉｃａｔｉｏｎ ＩＤを取得することができる。（ｓｔｅｐ２）
受信機は、取得したＡｐｐｌｉｃａｔｉｏｎ ＩＤを用いてＰＤＩストアから関連ＰＤＩテーブルを探し、アプリケーションのＯｐｔ−ｉｎ／ｏｕｔに対する回答（ａｎｓｗｅｒ）、すなわち、ユーザの設定を見つけることができる。
受信機は、アプリケーションに対するＯｐｔ−ｉｎ／ｏｕｔ設定によってアプリケーションを実行させてもよく、実行させなくてもよい。
図５１は、本発明の一実施例に係る、アプリケーションのユーザによるオプションを設定するＵＩ及びこれに対する質問（Ｑｕｅｓｔｉｏｎ）を示す図である。
図面の（ａ）を参照すると、Ａｐｐｌｉｃａｔｉｏｎ ＩＤで区分されるアプリケーション別に、該当のアプリケーションをユーザに露出するか否かに対する設定をするためのＵＩ及び質問が示されている。この場合、ユーザはアプリケーションごとに、使用するか否かを設定することができ、使用するか否かが設定された情報は受信機に保存されてもよい。詳細な受信機の動作は、前述した説明を参照されたい。
図面の（ｂ）を参照すると、Ａｐｐｌｉｃａｔｉｏｎ ＩＤで区分されるアプリケーションをユーザに露出するか否かを区分する拡張された設定ＵＩ及びそのための質問が示されている。基本的に、ユーザは、アプリケーションに対する使用の有無を設定することができ、この設定が現在放送プログラム内でのみ有効か、現在チャネルの全放送プログラムで有効か、又は全チャネルの全放送プログラムで有効かを設定することができる。
図５２は、自動コンテンツ認識ベースのＥＴＶ（ｅｎｈａｎｃｅｄ ｔｅｌｅｖｉｓｉｏｎ）サービスシステムを示す図である。
図５２に示す自動コンテンツ認識ベースのＥＴＶサービスシステムは、放送局又はコンテンツプロバイダ１００、多チャネル放送事業者１０１、セットトップボックス１０２、デジタルＴＶ受信機などの受信機１０３、自動コンテンツ認識サーバー（又は、自動コンテンツ認識ソリューションプロバイダ）１０４を含むことができる。受信機１０３は、ＡＴＳＣ（ａｄｖａｎｃｅｄ ｔｅｌｅｖｉｓｉｏｎ ｓｙｓｔｅｍ ｃｏｍｍｉｔｔｅｅ）の定義によって動作でき、自動コンテンツ認識機能をサポートすることができる。実時間放送サービス１１０はオーディオ／ビデオコンテンツを含むことができる。
デジタル放送サービスは、放送局１００によって提供される地上波放送サービスと、多チャネル放送事業者１０１によって提供されるケーブル放送又は衛星放送などの多チャネル放送サービスとに大別することができる。放送局１００は、実時間放送サービス１１０及びエンハンスメントデータ（又は、付加データ）１２０を共に伝送することができる。この場合、図５２に示すように、受信機１０３は、多チャネル放送事業者１０１及びセットトップボックス１０２を介して実時間放送サービス１１０だけを受信でき、エンハンスメントデータ１２０は受信できない場合もある。
したがって、エンハンスメントデータ１２０を受信するために、受信機１０３は、オーディオ／ビデオコンテンツ出力を実時間放送サービス１１０で分析及び処理し、放送プログラム情報及び／又は放送プログラム関連メタデータを確認する。確認された放送プログラム情報及び／又は放送プログラム関連メタデータを用いて、受信機１０３は、放送局１００又は自動コンテンツ認識サーバー１０４からエンハンスメントデータを受信することができる（１４０）。この場合、エンハンスメントデータは、インターネットプロトコルネットワーク１５０を介して伝送されてもよい。
エンハンスメントデータが別途の自動コンテンツ認識サーバー１０４から受信されると（１４０）、自動コンテンツ認識サーバー１０４と受信機１０３間のメカニズムにおいて、ＡＴＳＣ２．０標準で定義したＴＤＯ（ｔｒｉｇｇｅｒｅｄ ｄｅｃｌａｒａｔｉｖｅ ｏｂｊｅｃｔ）モデルのうち、要求／応答モデルを自動コンテンツ認識サーバー１０４に適用することができる。ＴＤＯ及び要求／応答モデルは後述する。
ＴＤＯは、放送コンテンツに含まれた付加情報を示す。ＴＤＯは、放送コンテンツ内で付加情報を適時にトリガーする役割を担う。例えば、オーディオプログラムが放送されると、視聴者の好むオーディション参加者の現在順位が放送コンテンツと共に表示される。この時、オーディション参加者の現在順位の付加情報がＴＤＯに該当し得る。このようなＴＤＯは、視聴者との相互作用によって変更されてもよく、視聴者の意図によって提供されてもよい。
標準ＡＴＳＣ２．０の要求／応答自動コンテンツ認識モデルにおいて、デジタル放送受信機１０３は周期的に（例えば５秒ごとに）コンテンツのシグネチャ（ｓｉｇｎａｔｕｒｅ）を生成し、該シグネチャを含む要求を自動コンテンツ認識サーバー１０４に伝送するようになっている。自動コンテンツ認識サーバー１０４は、デジタル放送受信機１０３から要求を受けると、応答を返す。通信セッションは要求と応答との間で開放されない。このモデルで、自動コンテンツ認識サーバー１０４はクライアントに対するメッセージを始めることができない。
デジタル衛星放送の導入によって、デジタルデータ放送が新しい付加サービスとして現れた。代表的な双方向サービスである双方向データ放送は、様々な付加サービスを提供するために、データ信号だけでなく既存放送信号を加入者に伝送することができる。
デジタルデータ放送は、仮想チャネルを用いた独立型サービスと、ＥＴＶを用いた放送関連サービスとに大別することができる。独立型サービスは、放送イメージ信号無しでテキストとグラフィックだけを含み、既存インターネットウェブページと類似のフォーマットで提供される。独立型サービスの代表的な例として、天気及び株式情報提供サービス、ＴＶ金融サービス、商取引サービスなどを挙げることができる。放送関連サービスは、放送イメージ信号の他、付加的なテキスト及びグラフィック情報も伝送する。視聴者は、放送関連サービスから、視聴した放送プログラムに関連した情報を得ることができる。例えば、視聴者がドラマを視聴する間に、以前のストーリー又は撮影場所を見ることを可能にさせるサービスがある。
デジタルデータ放送の放送関連サービスでは、ＥＴＶサービスが自動コンテンツ認識技術に基づいて提供されてもよい。自動コンテンツ認識とは、装置がオーディオ／ビデオコンテンツを再生するとき、コンテンツに隠された情報から、自動でコンテンツを認識する技術のことをいう。
自動コンテンツ認識技術を実装する際、コンテンツに関する情報を得るために、ウォーターマーキング（ｗａｔｅｒｍａｒｋｉｎｇ）やフィンガープリンティング（ｆｉｎｇｅｒ ｐｒｉｎｔｉｎｇ）方式を用いることができる。ウォーターマーキングは、デジタルコンテンツプロバイダを示す情報をデジタルコンテンツに挿入する技術のことをいう。フィンガープリンティングは、特定情報がデジタルコンテンツに挿入される点がウォーターマーキングと同一であるが、コンテンツプロバイダに関する情報ではなくコンテンツ購買者に関する情報が挿入される点でウォーターマーキングと異なる。
図５３は、本発明の一実施例に係るデジタルウォーターマーキング技術の流れを示す図である。
デジタル衛星放送の導入によって、デジタルデータ放送が新しい付加サービスとして現れた。代表的な双方向サービスである双方向データ放送は、様々な付加サービスを提供するために、データ信号だけでなく既存の放送信号を加入者に伝送することができる。
デジタルデータ放送は、仮想チャネルを用いた独立型サービスと、ＥＴＶを用いた放送関連サービスとに大別することができる。独立型サービスは、放送イメージ信号無しでテキストとグラフィックだけを含み、既存インターネットウェブページと類似のフォーマットで提供される。独立型サービスの代表的な例として、天気及び株式情報提供サービス、ＴＶ金融サービス、商取引サービスなどを挙げることができる。放送関連サービスは、放送イメージ信号の他、付加的なテキスト及びグラフィック情報も伝送する。視聴者は、放送関連サービスから、視聴した放送プログラムに関連した情報を得ることができる。例えば、視聴者がドラマを視聴する間に、以前のストーリー又は撮影場所を見ることを可能にさせるサービスがある。
デジタルデータ放送の放送関連サービスでは、ＥＴＶサービスが自動コンテンツ認識技術に基づいて提供されてもよい。自動コンテンツ認識とは、装置がオーディオ／ビデオコンテンツを再生するとき、コンテンツに隠された情報から、自動でコンテンツを認識する技術のことをいう。
自動コンテンツ認識技術を実装するとき、コンテンツに関する情報を得るために、ウォーターマーキングやフィンガープリンティング方式を用いることができる。ウォーターマーキングは、デジタルコンテンツプロバイダを示す情報をデジタルコンテンツに挿入する技術のことをいう。フィンガープリンティングは、特定情報がデジタルコンテンツに挿入される点がウォーターマーキングと同一であるが、コンテンツプロバイダに関する情報ではなくコンテンツ購買者に関する情報が挿入される点でウォーターマーキングと異なる。
以下、図５３と関連してウォーターマーキング技術について具体的に説明する。
デジタルウォーターマーキングは、除去し難い方式でデジタル信号に情報を埋め込む過程である。例えば、信号は、音声、画面、又は映像でありうる。信号が複製されると、情報も複製された信号に乗せられる。一つの信号は同時に複数の異なったウォーターマークを乗せることができる。
視覚的ウォーターマーキングで、情報は画面又は映像において可視的である。一般に、情報は、メディアの所有者を識別するテキストやロゴである。ＴＶ放送局が、送信される映像のコーナーにロゴを追加すると、これもまた視覚的ウォーターマークである。
非視覚的ウォーターマーキングで、情報はデジタルデータとして音声、画面、又は映像に追加されるが、若干の情報が隠されているということを感知できても、その自体は認知されない。ウォーターマークは広く使われるためのものであるから、検索しやすくなっていてもよく、ある団体がデジタル信号に埋め込まれた秘密メッセージをやりとりするステガノグラフィの形態であってもよい。いずれの場合であれ、視覚的ウォーターマーキングと同様に、目的は、所有主や他の記述情報を除去し難い方式で信号に付けることである。隠された埋め込まれた情報を個人間の通信を切り替えるための手段として使用することもできる。
ウォーターマーキングの一つの応用としては、デジタルメディアの非承認複製を防止又は阻止するための著作権保護システムがある。この用途では、複製装置が複製前に信号からウォーターマークを検索し、ウォーターマークのコンテンツによって複製をするか否かを決定する。他の応用としては、ソース追跡がある。
ウォーターマークは配布の度にデジタル信号に埋め込まれる。著作物の複製物が後で発見されると、ウォーターマークが複製物から検索され、配布のソースが知らされる。報道によれば、この技術は、不正に複製された映画のソースを見つけるために用いられてきた。
記述情報を持つデジタル写真のアノテーションは、非視覚的ウォーターマーキングの更に他の応用である。
デジタルメディアに対するファイル形式の一部がメタデータと呼ばれる付加情報を含むことができるのに対し、デジタルウォーターマーキングは、データが信号自体で伝達されるという点で異なる。
一部の文脈でデジタルウォーターマークという語句がウォーターマーキングされた信号とカバー信号間の差異を意味することもあるが、埋め込まれる情報は、デジタルウォーターマークと呼ばれる。ウォーターマークが埋め込まれる信号は、ホスト信号と呼ばれる。
ウォーターマーキングシステムは、主に、埋め込み２０１、攻撃２０２、検出又は抽出２０３の３つの別個の段階に区別される。
埋め込み２０１で、アルゴリズムは、ホスト及び埋め込まれるデータを取り込み、ウォーターマーキングされた信号を生成する。
ウォーターマーキングされた信号は送信又は記憶されるが、主に他の人に送信される。この人が変更を加えると、これは攻撃２０２と呼ばれる。変更が悪意的でないこともあるが、攻撃というものは、著作権侵害者が変更によってデジタルウォーターマークを除去しようとする著作権保護アプリケーションから発生する。色々な変更がありうる。例えば、データの非可逆圧縮、イメージ又は映像のクロッピング、又は意図的に加える雑音などがありうる。
検出２０３は、攻撃された信号からウォーターマークを抽出するために、攻撃された信号に適用されるアルゴリズムである。信号が送信中に変更されなかった場合は、ウォーターマークは依然として存在し、抽出されることが可能である。堅固なウォーターマーキングアプリケーションでは、変更が強力であっても抽出アルゴリズムはウォーターマークを正しく生成できるはずである。脆弱なウォーターマーキングでは、信号にいかなる変更が加えられても抽出アルゴリズムは失敗するだろう。
埋め込まれた情報が数回の変形によって低下してもマーキングされた信号から確実に検出されることが可能であれば、デジタルウォーターマークは変形に対して堅固であるという。典型的なイメージ低下は、ＪＰＥＧ圧縮、回転（ｒｏｔａｔｉｏｎ）、クロッピング、付加的な雑音及び量子化である。ビデオコンテンツにおいて、一時的変更及びＭＰＥＧ圧縮が主としてここに含まれる。ウォーターマーキングされたコンテンツが本来のウォーターマーキングされていないコンテンツと知覚的に同等であると、ウォーターマークは感知できないという。一般に、堅固なウォーターマークや感知できないウォーターマークは生成しやすいが、堅固で且つ感知できないウォーターマークは生成し難いと知られている。堅固で且つ感知できないウォーターマークは、デジタルコンテンツの保護のための道具、例えば、専門的なビデオコンテンツにおいて埋め込まれた“複製不許可”フラグとして提案された。
デジタルウォーターマーキング技術は、いくつかの方式に分類できる。
第一に、ウォーターマークは、若干の変形後に検出されないと脆弱であるという（堅固性）。脆弱なウォーターマークは通常、タンパー検出完全性立証のために使われる。明らかに明確な原著作物に加えた変形は、普通、ウォーターマークと呼ばれず、一般化したバーコードと呼ばれる。良性変形には抵抗力があるが、悪性変形後には検出に失敗するウォーターマークは、やや脆弱であるという。やや脆弱なウォーターマークは、通常、悪性変形を検出するために使われる。指定された部類の変形に抵抗力があるウォーターマークは堅固であるという。堅固なウォーターマークは、複製物を伝達し、制御情報に接続するために、複製防止アプリケーションで用いることができる。
第二に、元来のカバー信号とマーキングされた信号とが知覚的に区別されないと（区別され難いと）、ウォーターマークは感知できないという（知覚性）。マーキングされた信号での存在が明らかであるが、非侵害的であると、ウォーターマークは感知できるという。
第三に、容量に関して、埋め込まれたメッセージの長さは、２種類の異なる主部類のウォーターマーキング方式を決定する。
メッセージは概念上０ビットの長さを有し、システムは、マーキングされたオブジェクトからウォーターマークの存在有無を検出するために設計される。この種のウォーターマーキング方式は、主に、イタリック０ビット又はイタリック存在ウォーターマーキング方式と呼ばれる。しばしばこの種のウォーターマーキング方式は、１がウォーターマークの存在を示すため（０は不在）、１ビットウォーターマークと呼ばれる。
メッセージはｎビット長のストリーム（ｎ＝｜ｍ｜又はＭ＝｛０，１｝ｎ）であり、ウォーターマークで変調される。この種の方式は主に、多重ビットウォーターマーキング又は非零ビットウォーターマーキング方式と呼ばれる。
第四に、埋め込み段階にはいくつかの方式がある。マーキングされた信号が付加的な変形によって得られると、ウォーターマーキング方法は帯域拡散と呼ばれる。帯域拡散ウォーターマークは適当に堅固であると知られているが、ホスト干渉によって低い情報容量を有すると知られている。マーキングされた信号が量子化によって得られると、ウォーターマーキング方法は、量子化タイプのものという。量子化ウォーターマークは低い堅固性を有するが、ホスト干渉の排除によって高い情報容量を有する。マーキングされた信号が帯域拡散法と類似の付加的な変形によって埋め込まれるが、特別に空間領域で埋め込まれると、ウォーターマーキング方法は振幅変調と呼ばれる。
図５４は、本発明の一実施例に係る自動コンテンツ認識クエリー結果フォーマットを示す図である。
既存の自動コンテンツ認識サービス処理システムによれば、放送局が実時間サービスのためのコンテンツとＥＴＶサービスのためのエンハンスメントデータを共に送信し、ＴＶ受信機がコンテンツとＥＴＶサービスを受信する場合、実時間サービスのためのコンテンツは受信できるが、エンハンスメントデータは受信できない。
この場合、本発明の一実施例によれば、インターネットプロトコルネットワークを用いた独立したインターネットプロトコルシグナリングチャネルを用いて既存の自動コンテンツ認識処理システムの問題を解決することができる。すなわち、ＴＶ受信機は、多チャネル放送事業者を通して実時間サービスのためのコンテンツを受信することができ、独立したインターネットプロトコルシグナリングチャネルを通してエンハンスメントデータを受信することができる。
この場合、本発明の一実施例によれば、インターネットプロトコルシグナリングチャネルは、ＰＳＩＰストリームがバイナリストリームの形態で伝達及び処理されるように構成される。このとき、インターネットプロトコルシグナリングチャネルは、プル（ｐｕｌｌ）方法やプッシュ（ｐｕｓｈ）方法を利用するように構成される。
プル方法のインターネットプロトコルシグナリングチャネルは、ＨＴＴＰ要求／応答方法によって構成されうる。ＨＴＴＰ要求／応答方法によれば、ＰＳＩＰバイナリストリームは、ＨＴＴＰ要求信号に対するＨＴＴＰ応答信号に含まれ、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬを通して送信されうる。この場合、ポーリングサイクルは、自動コンテンツ認識クエリー結果として伝達されたメタデータでＰｏｌｌｉｎｇ＿ｃｙｃｌｅによって周期的に要求されうる。また、更新される時間及び／又は周期に関する情報は、シグナリングチャネルに含まれて送信されうる。この場合、受信機は、インターネットプロトコルシグナリングチャネルから受信した更新時間及び／又は周期情報に基づいてサーバーにシグナリング情報を要求することができる。
プッシュ方法のインターネットプロトコルシグナリングチャネルは、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔアプリケーションプログラミングインターフェースを用いて構成されうる。ＸＭＬＨＴＴＰＲｅｑｕｅｓｔアプリケーションプログラミングインターフェースが用いられると、サーバーから非同期で最新情報を受信することができる。これは、受信機にとっては、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔオブジェクトを通してサーバーに非周期的にシグナリング情報を要求する方法であり、サーバーにとっては、シグナリング情報が変更された場合は、要求に応答してこのチャネルを通してシグナリング情報を提供する方法である。セッションの待ち時間に制限があると、セッションタイムアウト応答が生成され、受信機はセッションタイムアウト応答を認識し、シグナリング情報を再び要求し、受信機とサーバー間でシグナリングチャネルを維持することができる。
インターネットプロトコルシグナリングチャネルを通してエンハンスメントデータを受信するために、受信機はウォーターマーキングとフィンガープリンティングを用いて動作することができる。フィンガープリンティングは、コンテンツ購買者に関する情報をコンテンツプロバイダの代わりにコンテンツに挿入する技術のことを指す。フィンガープリンティングが用いられると、受信機は、コンテンツを確認するために参照データベースを検索することができる。コンテンツを確認した結果は、自動コンテンツ認識クエリー結果と呼ばれる。自動コンテンツ認識クエリー結果は、ＴＶ視聴者に提供されたクエリーを含み、自動コンテンツ認識機能を実行するためにクエリーの情報に対して対応することができる。受信機は、自動コンテンツ認識クエリー結果に基づいてＥＴＶサービスを提供することができる。
自動コンテンツ認識クエリー結果に関する情報は、ウォーターマーク基盤自動コンテンツ認識システム上でオーディオ／ビデオコンテンツに挿入／埋め込みされて送信されうる。受信機は、ウォーターマーク抽出器を通して自動コンテンツ認識クエリー結果情報を抽出及び取得した後、ＥＴＶサービスを提供することができる。この場合、ＥＴＶサービスを別途の自動コンテンツ認識サーバー無しで提供することができ、インターネットプロトコルネットワークを通したクエリーは省略することができる。
図５４は、本発明の一実施例に係る自動コンテンツ認識クエリー結果を示すＸＭＬスキーマの図である。図５４に示すように、自動コンテンツ認識クエリー結果のＸＭＬフォーマットは結果コード部３１０を含むことができ、自動コンテンツ認識クエリー結果タイプ３００は、コンテンツ識別子部３０１、ＮＴＰ（ｎｅｔｗｏｒｋ ｔｉｍｅ ｐｒｏｔｏｃｏｌ）タイムスタンプ部３０２、シグナリングチャネル情報部３０３、サービス情報部３０４、その他識別子部３０５を含むことができる。シグナリングチャネル情報部３０３は、シグナリングチャネルＵＲＬ部３１３、更新モード部３２３、ポーリングサイクル部３３３を含むことができ、サービス情報部３０４は、サービスネーム部３１４、サービスロゴ部３２４、サービス記述部３３４を含むことができる。
次に、図５４に示す自動コンテンツ認識クエリー結果のＸＭＬスキーマの図面を詳細に説明し、ＸＭＬスキーマの例を説明する。
結果コード部３１０は、自動コンテンツ認識クエリーの結果値を示すことができる。これは、クエリー成功又は失敗、クエリーが失敗すると失敗理由をコード値の形態で示すことができる。例えば、結果コード部３１０の値が２００であれば、これは、クエリーに成功し、それに該当するコンテンツ情報が返されたことを示す。結果コード部３１０の値が４０４であれば、これは、コンテンツが発見されなかったことを示す。
コンテンツ識別子部３０１は、グローバルに一意にコンテンツを識別するための識別子を示し、サービスを識別するための識別子であるグローバルサービス識別子部を含むことができる。
ＮＴＰタイムスタンプ部３０２は、自動コンテンツ認識クエリーに用いられるサンプルフレーム間隔の特定時点がＮＴＰタイムスタンプの形態で提供されるということを示すことができる。ここで、特定時点は、サンプルフレームの始点又は終点であってもよい。ＮＴＰとは、インターネットを介してコンピュータの時間をレファレンスクロックに合わせるためのプロトコルのことをいい、タイムサーバーとコンピュータネットワーク上に分配されたクライアント間の時間同期化のために用いられてもよい。ＮＴＰがＵＴＣ（ｕｎｉｖｅｒｓａｌ ｔｉｍｅ ｃｏｏｒｄｉｎａｔｅｄ）時間を使用し、１０ｍｓの正確度を保証するので、受信機はフレーム同期化動作を正確に処理することができる。
シグナリングチャネル情報部３０３は、ＥＴＶサービスのためのインターネットプロトコルネットワーク上の独立したシグナリングチャネルのアクセス情報を示すことができる。
より具体的に、シグナリングチャネル情報部３０３の下位部であるシグナリングチャネルＵＲＬ部３１３は、シグナリングチャネルのＵＲＬ情報を示すことができる。シグナリングチャネルＵＲＬ部３１３は、更新モード部３２３及びポーリングサイクル部３３３を下位部として含むことができる。更新モード部３２３は、インターネットプロトコルシグナリングチャネルを介して情報を取得する方法を示す。例えば、プルモードで受信機は情報を取得するためにプル方法によって周期的にポーリングを行うことができ、プッシュモードでサーバーは、プッシュ方法によって受信機に情報を送信することができる。ポーリングサイクル部３３３は、更新モード部３２３がプルモードであれば、プル方法によって受信機の基本ポーリングサイクル値を示すことができる。そして、受信機は、基本ポーリングサイクル値を特定し、任意時間間隔で要求信号をサーバーに伝送し、サーバーが要求によって過負荷となることを防止することができる。
サービス情報部３０４は、放送チャネルに関する情報を示すことができる。コンテンツ識別子部３０１は、視聴者によって現在視聴されているサービスの識別子を示すことができ、サービス情報部３０４は、放送チャネルに関する具体的な情報を示すことができる。例えば、サービス情報部３０４が示す具体的な情報は、チャネル名、ロゴ、又はテキスト説明であってもよい。
より具体的に、サービス情報部３０４の下位部であるサービスネーム部３１４は、チャネル名を示すことができ、サービスロゴ部３２４は、チャネルロゴを示すことができ、サービス記述部３３４は、チャネルテキスト説明を示すことができる。
次に、本発明の一実施例に係る、図５４に示した自動コンテンツ認識クエリー結果のエレメント（ｅｌｅｍｅｎｔ）のＸＭＬスキーマを示す。
<xs:complexType name="ACR-ResultType">
<xs:sequence>
<xs:element name="ContentID" type="xs:anyURI"/>
<xs:element name="NTPTimestamp" type="xs:unsignedLong"/>
<xs:element name="SignalingChannelInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="SignalingChannelURL" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="UpdateMode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Pull"/>
<xs:enumeration value="Push"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="PollingCycle" type="xs:unsignedInt"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServiceInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="ServiceName" type="xs:string"/>
<xs:element name="ServiceLogo" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ServiceDescription" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ResultCode" type="xs:string" use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
図５５は、本発明の一実施例に係るコンテンツ識別子の構文を示す図である。
図５５は、本発明の一実施例に係るＡＴＳＣ標準に従うコンテンツ識別子の構文を示す。ＡＴＳＣコンテンツ識別子は、受信機によって受信したコンテンツを識別するための識別子として用いることができる。
また、図５５に示すコンテンツ識別子の構文は、図５４で説明した自動コンテンツ認識質問結果フォーマットのコンテンツ識別子部の構文である。
ＡＴＳＣコンテンツ識別子は、唯一の周期を有し、ＴＳＩＤ（Ｔｒａｎｓｍｉｔｔｉｎｇ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）及びハウスナンバーで構成された構文である。ハウスナンバーは、ここに制約されたように、ＴＳＩＤの保有者が所望するあるナンバーである。ナンバーは、ＴＳＩＤのそれぞれの値に対して唯一である。ＡＴＳＣコンテンツ識別子構造の構文は、図６２に定義されるとおりである。
１６ビットの符号なし整数フィールドであるＴＳＩＤは、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄの値を含むことができる。米国でこの値の割り当て権限はＦＣＣにある。メキシコ、カナダ、米国に対する範囲は、それらの国家間の公式協約によって設定されている。他の地域の値は任意の権限によって設定される。
５ビットの符号なし整数であるｅｎｄ＿ｏｆ＿ｄａｙフィールドは、放送日が終了するＵＴＣでその日の時間に設定され、暫くしてｃｏｎｔｅｎｔ＿ｉｄ値がｕｎｉｑｕｅ＿ｆｏｒによって再使用されるようになっている。このフィールドの値は０乃至２３の範囲にあっている。このとき、このフィールドの値は放送局ごとに固定されると予想される。
９ビットの符号なし整数であるｕｎｉｑｕｅ＿ｆｏｒフィールドは、日数に設定され、端数が切り上げられ、ｃｏｎｔｅｎｔ＿ｉｄ値が他のコンテンツに再割り当てされないｅｎｄ＿ｏｆ＿ｄａｙが示す時間に関して測定される。その値は、１乃至５１１の範囲にあるだろう。０は禁止されるだろう。５１１は、“無期限”の特別な意味がある。このとき、このフィールドの値はハウスナンバリング方法が変更される時にのみ変更され、放送局ごとに本質的に固定されると予想される。また、デコーダは、ｕｎｉｑｕｅ＿ｆｏｒフィールドが満了するまで保存されたｃｏｎｔｅｎｔ＿ｖａｌｕｅｓを唯一のものと取扱うことができ、これは、保存された全てのｕｎｉｑｕｅ＿ｆｏｒフィールドが０になるまでｅｎｄ＿ｏｆ＿ｄａｙに毎日１ずつ減少させることによって実行させることができる。
可変長フィールドであるｃｏｎｔｅｎｔ＿ｉｄフィールドは、ハウスナンバーシステムやＴＳＩＤの値のためのシステムによって識別子の値に設定されてもよい。このような各値は、ｅｎｄ＿ｏｆ＿ｄａｙ及びｕｎｉｑｕｅ＿ｆｏｒフィールドの値によって設定された唯一の期間内で他のコンテンツに割り当てることができない。該当識別子は、人にとって読み取り可能であり、及び／又は２進値のいかなる組合せになってもよく、２４２バイトを超えないようにハウスナンバーの形態と完全に一致する必要はない。
また、本発明の一実施例に係る受信機が、図５５に示すコンテンツ識別子の構文から、サービスをグローバルに一意に識別できない場合、本発明の一実施例に係る受信機は、グローバルサービス識別子を用いてサービスを識別することができる。本発明の一実施例に係るグローバルサービス識別子は、図５５で説明した自動コンテンツ認識質問結果フォーマットのコンテンツ識別子部に含まれてもよい。
以下、［例示１］は、本発明の一実施例に係るＵＲＩフォーマットのグローバルサービス識別子を示す。［例示１］のグローバルサービス識別子を、ＡＴＳＣ−Ｍ／Ｈサービスのために用いることができる。
［例示１］ ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄ＞：＜ｓｅｒｖｉｃｅｉｄ＞
＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２によって特定されたような２文字の国際国家コードである。
＜ｘｓｉｄ＞は、該当の地域で定義されたとおり、ローカルサービスに対してはＴＳＩＤの１０進エンコーディングと定義される。＜ｘｓｉｄ＞は、地域サービスに対しては（ｍａｊｏｒ＞６９）、“０”と定義される。
＜ｓｅｒｖｉｃｅｉｄ＞は、＜ｍａｊｏｒ＞．＜ｍｉｎｏｒ＞と定義される。ここで、＜ｍａｊｏｒ＞は、主チャネルナンバーを示すことができ、＜ｍｉｎｏｒ＞は、副チャネルナンバーを示すことができる。
上述したグローバルサービス識別子は、次のようなＵＲＩフォーマットで表現されてもよい。
［例示２］ ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：１２３４：５．１
［例示３］ ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：０：１００．２００
また、本発明の一実施例に係る受信機は、上述したグローバルサービス識別子に基づいて、グローバルコンテンツ識別子を用いてコンテンツを識別することができる。
以下、［例示４］は、本発明の一実施例に係るＵＲＩフォーマットのグローバルコンテンツ識別子を示す。［例示４］のグローバルサービス識別子は、ＡＴＳＣサービスのために用いることができる。具体的に、［例示４］は、本発明の一実施例に係るグローバルコンテンツ識別子としてＡＴＳＣコンテンツ識別子が用いられた場合を示す。
［例示４］
ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｃｏｎｔｅｎｔ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄｚ＞：＜ｃｏｎｔｅｎｔｉｄ＞：＜ｕｎｉｑｕｅ＿ｆｏｒ＞：＜ｅｎｄ＿ｏｆ＿ｄａｙ＞
＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２［４］によって特定されたような２文字の国際国家コードである。
＜ｘｓｉｄｚ＞は、該当の地域で定義されたとおり、ローカルサービスに対してはＴＳＩＤの１０進エンコーディングと定義される。ここには、放出する放送局が＜ｓｅｒｖｉｃｅｉｄ＞を使用せず、グローバルコンテンツ識別子の唯一性を保証できない限り、“．”＜ｓｅｒｖｉｃｅｉｄ＞が続く。＜ｘｓｉｄｚ＞は、地域サービスに対しては（ｍａｊｏｒ＞６９）、＜ｓｅｒｖｉｃｅｉｄ＞と定義される。
両方の場合において、＜ｓｅｒｖｉｃｅｉｄ＞は、セクションＡ１でコンテンツを伝達するサービスに対して定義されたとおりである。＜ｃｏｎｔｅｎｔ＿ｉｄ＞は、ｃｏｎｔｅｎｔ＿ｉｄフィールドを２進ストリングとして考慮した、図５５で定義したｃｏｎｔｅｎｔ＿ｉｄフィールドのｂａｓｅ６４［５］エンコーディングである。＜ｕｎｉｑｕｅ＿ｆｏｒ＞は、図５５で定義したｕｎｉｑｕｅ＿ｆｏｒフィールドの１０進エンコーディングである。＜ｅｎｄ＿ｏｆ＿ｄａｙ＞は、図５５で定義したｅｎｄ＿ｏｆ＿ｄａｙフィールドの１０進エンコーディングである。
上述した例示によって定義されたフォーマットを有するＡＴＳＣコンテンツ識別子を、自動コンテンツ認識処理システム上でコンテンツを識別するために用いることができる。
以下、本発明の一実施例に係る図５６及び図５７と関連してウォーターマーキング及びフィンガープリンティング技術を実現し得るように設計された受信機について説明する。図５６及び図５７は、設計者の意図によって異なる方法で構成されてもよい。
図５６は、本発明の一実施例に係る受信機の構造を示す図である。
具体的に、図５６は、ウォーターマーキングを用いて自動コンテンツ認識ベースのＥＴＶサービスをサポートする受信機の構成の一例を示す。
図５６に示すように、本発明の一実施例に係る自動コンテンツ認識ベースのＥＴＶサービスをサポートする受信機は、入力データプロセッサ、ＡＴＳＣメインサービスプロセッサ、ＡＴＳＣ ＭＨ（ｍｏｂｉｌｅ ｈａｎｄｈｅｌｄ）サービスプロセッサ、及び／又は自動コンテンツ認識サービスプロセッサを含むことができる。入力データプロセッサは、チューナ／復調器４００、及び／又は残留側波帯デコーダ４０１を含むことができる。ＡＴＳＣメインサービスプロセッサは、トランスポートプロトコル（ＴＰ）デマルチプレクサ４０２、非実時間ガイド情報プロセッサ４０３、ＤＳＭ−ＣＣ（ｄｉｇｉｔａｌ ｓｔｏｒａｇｅ ｍｅｄｉａ ｃｏｍｍａｎｄ ａｎｄ ｃｏｎｔｒｏｌ）アドレス指定可能セクションパーサー４０４、ＩＰ／ＵＤＰ（ｉｎｆｏｒｍａｔｉｏｎ ｐｒｏｖｉｄｅｒ／ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）パーサー４０５、ＦＬＵＴＥ（ｆｉｌｅ ｄｅｌｉｖｅｒｙ ｏｖｅｒ ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｔｒａｎｓｐｏｒｔ）パーサー４０６、メタデータモジュール４０７、ファイルモジュール４０８、ＥＳＧ（ｅｌｅｃｔｒｏｎｉｃ ｓｅｒｖｉｃｅ ｇｕｉｄｅ）／ＤＣＤ（ｄａｔａ ｃａｒｒｉｅｒ ｄｅｔｅｃｔ）ハンドラ４０９、保存制御モジュール４１０、ファイル／トランスポートプロトコルスイッチ４１１、再生制御モジュール４１２、第１保存装置４１３、インターネットプロトコルパケット保存制御モジュール４１４、インターネット接続制御モジュール４１５、インターネットプロトコルインターフェース４１６、ライブレコーディングスイッチ４１７、ファイル（オブジェクト）デコーダ４１８、トランスポートプロトコル／ＰＥＳ（ｐａｃｋｅｔｉｚｅｄ ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）デコーダ４２０、ＰＳＩ（ｐｒｏｇｒａｍ ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）／ＰＳＩＰ（ｐｒｏｇｒａｍ ａｎｄ ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｐｒｏｔｏｃｏｌ）デコーダ４２１、及び／又はＥＰＧ（ｅｌｅｃｔｒｏｎｉｃ ｐｒｏｇｒａｍ ｇｕｉｄｅ）ハンドラ４２２を含むことができる。ＡＴＳＣ ＭＨサービスプロセッサは、メイン／ＭＨ／非実時間スイッチ４１９、ＭＨベースバンドプロセッサ４２３、ＭＨ物理的適応プロセッサ４２４、インターネットプロトコルスタック４２５、ファイルハンドラ４２６、ＥＳＧハンドラ４２７、第２保存装置４２８、及び／又はストリーミングハンドラ４２９を含むことができる。自動コンテンツ認識サービスプロセッサは、メイン／ＭＨ／非実時間スイッチ４１９、オーディオ／ビデオデコーダ４３０、オーディオ／ビデオ処理モジュール４３１、外部入力ハンドラ４３２、ウォーターマーク抽出器４３３、及び／又はアプリケーション４３４を含むことができる。
次に、各プロセッサの各モジュールの動作を説明する。
入力データプロセッサにおいて、チューナ／復調器４００は、アンテナから受信した放送信号をチューニング及び復調することができる。この過程を通じて、残留側波帯シンボルを抽出することができる。残留側波帯デコーダ４０１は、チューナ／復調器４００によって抽出された残留側波帯シンボルをデコードすることができる。
残留側波帯デコーダ４０１は、デコーディングによるＡＴＳＣメインサービスデータ及びＭＨサービスデータを出力することができる。ＡＴＳＣメインサービスデータはＡＴＳＣメインサービスプロセッサに伝達されて処理され、ＭＨサービスデータはＡＴＳＣ ＭＨサービスプロセッサに伝達されて処理されてもよい。
ＡＴＳＣメインサービスプロセッサは、ＭＨ信号を除くメインサービスデータを自動コンテンツ認識サービスプロセッサに伝達するためにメインサービス信号を処理することができる。トランスポートプロトコルデマルチプレクサ４０２は、残留側波帯信号を通じて送信されたＡＴＳＣメインサービスデータの伝送パケットを逆多重化して他の処理モジュールに伝達することができる。すなわち、トランスポートプロトコルデマルチプレクサ４０２は、放送信号のエレメントがそれぞれ放送受信機のモジュールによって処理されるように、伝送パケットに含まれた様々な情報を逆多重化して伝達することができる。逆多重化されたデータは、実時間ストリーム、ＤＳＭ−ＣＣアドレス指定可能セクション、及び／又は非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを含むことができる。より具体的に、図５６に示すように、トランスポートプロトコルデマルチプレクサ４０２は、実時間ストリームをライブレコーディングスイッチ４１７に出力することができ、ＤＳＭ−ＣＣアドレス指定可能セクションをＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４に出力することができ、非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを非実時間ガイド情報プロセッサ４０３に出力することができる。
非実時間ガイド情報プロセッサ４０３は、トランスポートプロトコルデマルチプレクサ４０２から非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを受信し、ＦＬＵＴセッション情報を抽出してＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４に伝達することができる。ＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４は、トランスポートプロトコルデマルチプレクサ４０２からＤＳＭ−ＣＣアドレス指定可能セクションを受信し、非実時間ガイド情報プロセッサ４０３からＦＬＵＴセッション情報を受信し、ＤＳＭ−ＣＣアドレス指定可能セクションを処理することができる。ＩＰ／ＵＤＰパーサー４０５は、ＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４からデータ出力を受信し、ＩＰ／ＵＤＰによって送信されたＩＰデータグラムをパースすることができる。ＦＬＵＴＥパーサー４０６は、ＩＰ／ＵＤＰパーサー４０５から出力されたデータを受信し、ＡＬＣ（ａｓｙｎｃｈｒｏｎｏｕｓ ｌａｙｅｒｅｄ ｃｏｄｉｎｇ）オブジェクトの形態で送信されたデータサービスを伝送するためのＦＬＵＴＥデータを処理することができる。メタデータモジュール４０７及びファイルモジュール４０８は、ＦＬＵＴＥパーサー４０６から出力されたデータを受信し、メタデータ及び復元されたファイルを処理することができる。ＥＳＧ／ＤＣＤハンドラ４０９は、メタデータモジュール４０７から出力されたデータを受信し、放送プログラムに関連した電子サービスガイド及び／又は下りリンクチャネル記述子を処理することができる。復旧されたファイルは、基準フィンガープリント及びＡＴＳＣ２．０コンテンツのようなファイルオブジェクトの形態で保存制御モジュール４１０に伝達されてもよい。ファイルオブジェクトは、保存制御モジュール４１０によって処理され、正常ファイルとトランスポートプロトコルファイルとに分離され、第１保存装置４１３に保存されてもよい。再生制御モジュール４１２は、保存されたファイルオブジェクトを更新し、ファイルオブジェクトをファイル／トランスポートプロトコルスイッチ４１１に伝達して正常ファイル及びトランスポートプロトコルファイルをデコードすることができる。ファイル／トランスポートプロトコルスイッチ４１１は、正常ファイル及びトランスポートプロトコルファイルが別個の経路を通じてデコードされるように、正常ファイルはファイルデコーダ４１８に伝達し、トランスポートプロトコルファイルはライブレコーディングスイッチ４１７に伝達する。
ファイルデコーダ４１８は、正常ファイルをデコードして自動コンテンツ認識サービスプロセッサに伝達することができる。デコードされた正常ファイルは、自動コンテンツ認識サービスプロセッサのメイン／ＭＨ／非実時間スイッチ４１９に伝達されてもよい。トランスポートプロトコルファイルは、ライブレコーディングスイッチ４１７の制御下で、トランスポートプロトコル／ＰＥＳデコーダ４２０に伝達されてもよい。トランスポートプロトコル／ＰＥＳデコーダ４２０は、トランスポートプロトコルファイルをデコードし、ＰＳＩ／ＰＳＩＰデコーダ４２１は、デコードされたトランスポートプロトコルファイルを再びデコードする。ＥＰＧハンドラ４２２は、デコードされたトランスポートプロトコルファイルを処理し、ＡＴＳＣによってＥＰＧサービスを処理することができる。
ＡＴＳＣ ＭＨサービスプロセッサは、ＡＴＳＣ ＭＨサービスデータを自動コンテンツ認識サービスプロセッサに伝送するためにＭＨ信号を処理することができる。より具体的に、ＭＨベースバンドプロセッサ４２３は、ＡＴＳＣ ＭＨサービスデータを伝送に適したパルス波形に変換することができる。ＭＨ物理的適応プロセッサ４２４は、ＡＴＳＣ ＭＨサービスデータをＭＨ物理層に適した形態で処理することができる。
インターネットプロトコルスタック４２５は、ＭＨ物理的適応プロセッサ４２４から出力されたデータを受信して、インターネット伝送／受信のための通信プロトコルによって処理することができる。ファイルハンドラ４２６は、インターネットプロトコルスタック４２５から出力されたデータを受信して応用層のファイルを処理することができる。ＥＳＧハンドラ４２７は、ファイルハンドラ４２６から出力されたデータを受信してモバイルＥＳＧを処理することができる。また、第２保存装置４２８は、ファイルハンドラ４２６から出力されたデータを受信し、ファイルオブジェクトを保存することができる。また、インターネットプロトコルスタックモジュール４２５から出力されたデータの一部は、ＡＴＳＣによるモバイルＥＳＧサービスではなく、受信機の自動コンテンツ認識サービスのためのデータであってもよい。この場合、ストリーミングハンドラ４２９は、ＲＴＰ（ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）を通じて受信されたリアルストリーミングを処理し、これを自動コンテンツ認識サービスプロセッサに伝達することができる。
自動コンテンツ認識サービスプロセッサのメイン／ＭＨ／非実時間スイッチ４１９は、ＡＴＳＣメインサービスプロセッサ及び／又はＡＴＳＣ ＭＨサービスプロセッサから出力された信号を受信することができる。オーディオ／ビデオデコーダ４３０は、メイン／ＭＨ／非実時間スイッチ４１９から受信された圧縮オーディオ／ビデオデータをデコードすることができる。デコードされたオーディオ／ビデオデータをオーディオ／ビデオ処理モジュール４３１に伝達することができる。
外部入力ハンドラ４３２は、外部入力を通じて受信されたオーディオ／ビデオコンテンツを処理してオーディオ／ビデオ処理モジュール４３１に伝送することができる。
オーディオ／ビデオ処理モジュール４３１は、オーディオ／ビデオデコーダ４３０及び／又は外部入力ハンドラ４３２から受信されたオーディオ／ビデオデータを処理してスクリーンに表示することができる。この場合、ウォーターマーク抽出器４３３は、オーディオ／ビデオデータから、ウォーターマークの形態で挿入されたデータを抽出することができる。抽出されたウォーターマークデータは、アプリケーション４３４に伝達することができる。アプリケーション４３４は、自動コンテンツ認識機能に基づくエンハンスメントサービスを提供し、放送コンテンツを確認し、そこに関連したエンハンスメントデータを提供することができる。アプリケーション４３４がエンハンスメントデータをオーディオ／ビデオ処理モジュール４３１に伝達すると、オーディオ／ビデオ処理モジュール４３１は、受信したオーディオ／ビデオデータを処理して画面に表示することができる。
具体的に、図５６に示すウォーターマーク抽出器４３３は、外部入力で受信されたオーディオ／ビデオデータから、ウォーターマークの形態で挿入されたデータ（又は、ウォーターマーク）を抽出することができる。ウォーターマーク抽出器４３３は、オーディオデータからウォーターマークを抽出したり、ビデオデータからウォーターマークを抽出したり、又はオーディオデータ及びビデオデータからウォーターマークを抽出することができる。ウォーターマーク抽出器４３３は、抽出されたウォーターマークから、チャネル情報及び／又はコンテンツ情報を取得することができる。
本発明の一実施例に係る受信機は、ウォーターマーク抽出器４３３が取得したチャネル情報及び／又はコンテンツ情報を用いて、ＡＴＳＣ ＭＨチャネルをチューニングし、該当のコンテンツ及び／又はメタデータを受信することができる。また、本発明の一実施例に係る受信機は、インターネット網を介して該当のコンテンツ及び／又はメタデータを受信することもできる。その後、受信機はトリガーなどを用いて、受信されたコンテンツ及び／又はメタデータをディスプレイすることがきる。
図５７は、本発明の他の実施例に係る受信機の構造を示す図である。
より具体的に、図５７は、ウォーターマーキングを用いて自動コンテンツ認識ベースのＥＴＶサービスをサポートする受信機の構成の一例を示す。
図５７に示す本発明の一実施例に係る受信機の基本構造は、図５に示す受信機に基本構造と同一である。ただし、図５７に示す受信機は、本発明の一実施例によってフィンガープリント抽出器５３５及び／又はフィンガープリント比較器５３６をさらに含むことができる。また、図５７に示す受信機では、図５６に示す構成エレメントのうちウォーターマーク抽出器４３３が省かれてもよい。
図５７の基本的な構成は、図５６に示す受信機の基本的な構成と同一であり、その説明を省略する。以下、フィンガープリント抽出器５３５及び／又はフィンガープリント比較器５３６を中心に受信機の動作を説明する。
フィンガープリント抽出器５３５は、外部入力で受信されたＡ／Ｖコンテンツに挿入されたデータ（又は、シグネチャ（ｓｉｇｎａｔｕｒｅ））を抽出することができる。本発明の一実施例に係るフィンガープリント抽出器５３５は、オーディオコンテンツからシグネチャを抽出したり、ビデオコンテンツからシグネチャを抽出したり、又はオーディオコンテンツ及びビデオコンテンツからシグネチャを抽出することができる。
フィンガープリント比較器５３６は、Ａ／Ｖコンテンツから抽出されたシグネチャを用いて、チャネル情報及び／又はコンテンツ情報を取得することができる。本発明の一実施例に係るフィンガープリント比較器５３６は、ローカルサーチ（ｌｏｃａｌ ｓｅａｒｃｈ）及び／又は遠隔サーチ（ｒｅｍｏｔｅ ｓｅａｒｃｈ）によってチャネル情報及び／又はコンテンツ情報を取得することができる。
具体的に、図５７に示すように、フィンガープリント比較器５３６が保存装置５３７にアクセスして動作するルートをローカルサーチという。また、図５７に示すように、フィンガープリント比較器５３６がインターネット接続制御モジュール５３８にアクセスして動作するルートを遠隔サーチという。以下、ローカルサーチ及び遠隔サーチについて説明する。
本発明の一実施例に係るローカルサーチによれば、フィンガープリント比較器５３５は、抽出されたシグネチャと保存装置５３７に保存されていた基準フィンガープリントとを比較することができる。基準フィンガープリントは、フィンガープリント比較器５３６が抽出されたシグネチャを処理するために追加的に受信するデータである。
具体的に、フィンガープリント比較器５３６は、抽出されたシグネチャと基準フィンガープリントとをマッチし、両者が同一であるか否かを比較してチャネル情報及び／又はコンテンツ情報を取得することができる。
比較の結果、抽出されたシグネチャと基準フィンガープリントとが同一であれば、フィンガープリント比較器５３６は、比較結果をアプリケーションに伝達することができる。アプリケーションは、比較結果を用いて、抽出されたシグネチャと関連したチャネル情報及び／又はコンテンツ情報を受信機に伝達することができる。
比較の結果、抽出されたシグネチャと基準フィンガープリントとがマッチされないか、又は基準フィンガープリントが足りないと、フィンガープリント比較器５３６は、ＡＴＳＣ ＭＨチャネルを介して新しい基準フィンガープリントを受信することができる。その後、フィンガープリント比較器５３６は、抽出されたシグネチャと基準フィンガープリントとを再び比較することができる。
また、本発明の一実施例に係る遠隔サーチによれば、フィンガープリント比較器５３６は、インターネット上のシグネチャデータベースサーバーからチャネル情報及び／又はコンテンツ情報を受信することができる。
具体的に、フィンガープリント比較器５３６は、インターネット接続制御モジュール５３８を介してインターネット網に接続し、シグネチャデータベースサーバーにアクセスすることができる。その後、フィンガープリント比較器５３６は、抽出されたシグネチャをクエリーパラメータとしてシグネチャデータベースサーバーに伝達することができる。
全放送局が一つの統合されたシグネチャデータベースサーバーを利用する場合、フィンガープリント比較器５３６は、該当のシグネチャデータベースサーバーにクエリーパラメータを伝達することができる。放送局が個別的にシグネチャデータベースサーバーを運営する場合、フィンガープリント比較器５３６は、それぞれのシグネチャデータベースにクエリーパラメータを伝達することができる。又は、フィンガープリント比較器５３６は、２つ以上のシグネチャデータベースサーバーに同時にクエリーパラメータを伝達することもできる。
本発明の一実施例に係る受信機は、フィンガープリント比較器５３６が取得したチャネル情報及び／又はコンテンツ情報を用いて、ＡＴＳＣ Ｍ／Ｈチャネルをチューニングし、該当のコンテンツ及び／又はメタデータを受信することができる。その後、受信機は、トリガーなどを用いて、受信されたコンテンツ及び／又はメタデータをディスプレイですることがきる。
図５８は、本発明の一実施例に係るデジタル放送システムを示す図である。
具体的に、図５８は、個人化サービス（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ ｓｅｒｖｉｃｅ）のためのデジタル放送受信機（又は、受信機）を含む個人化放送システムを示す。本発明の一実施例に係る個人化サービスは、ユーザ情報に基づいてユーザに適したコンテンツを選別して提供するサービスである。また、本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０或いは個人化されたサービスを提供する次世代放送サービスを提供することができる。
本発明では、ユーザ情報の一実施例として、ユーザのプロファイル、人口統計及び興味情報（又は、ＰＤＩデータ）を定義する。以下では、個人化放送システムの構成エレメントについて説明する。
質問表に対する回答（ａｎｓｗｅｒ）はまとめると、ユーザのプロファイル、人口統計、興味（ＰＤＩ；ｐｒｏｆｉｌｅｓ，ｄｅｍｏｇｒａｐｈｉｃｓ， ａｎｄ ｉｎｔｅｒｅｓｔｓ）を示す。質問表及び特定ユーザによって与えられた回答を要約したデータ構造は、ＰＤＩ質問表又はＰＤＩテーブルと呼ばれる。データ構造は、使用可能な場合、回答を含むことができるが、ＰＤＩテーブルは、ネットワーク、放送局、又はコンテンツプロバイダによって提供されるので、回答データを含まない。ＰＤＩテーブルでエントリの質問（ｑｕｅｓｔｉｏｎ）部分は非公式的に“ＰＤＩ−質問”又は“ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する回答は非公式的に“ＰＤＩ−Ａ”と呼ばれる。フィルタ基準の集合は非公式的に“ＰＤＩ−ＦＣ”と呼ばれる。
ＡＴＳＣ２．０可能受信機のようなクライアント装置は、質問表で質問に対する回答の生成を可能にする機能を含む（ＰＤＩ−Ａインスタンス）。このＰＤＩ生成機能は、ＰＤＩ−Ｑの場合を入力として使用し、ＰＤＩ−Ａインスタンスを出力として生成する。ＰＤＩ−ＱインスタンスもＰＤＩ−Ａインスタンスも受信機の不揮発性記憶装置に保存される。クライアントは、ＰＤＩ−ＡインスタンスとＰＤＩ−ＦＣインスタンスとを比較し、どのコンテンツアイテムがダウンロード及び使用に適合するかを決定するフィルタリング機能を提供する。
図示するように、サービスプロバイダ側では、ＰＤＩテーブルを維持及び分配するための機能が実行される。コンテンツと共にコンテンツメタデータが生成される。メタデータの一部が、ＰＤＩテーブルで質問に基づくＰＤＩ−ＦＣインスタンスである。
図５８に示すように、個人化放送システムは、コンテンツプロバイダ（又は、放送局）７０７及び／又は受信機７００を含むことができる。本発明の一実施例に係る受信機７００は、ＰＤＩエンジン７０１、フィルタリングエンジン７０２、ＰＤＩストア７０３、コンテンツストア７０４、宣言コンテンツモジュール７０５及び／又はＵＩモジュール（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ ｍｏｄｕｌｅ）７０６を含むことができる。また、図５８に示すように、本発明の一実施例に係る受信機７００は、コンテンツプロバイダ７０７からコンテンツなどを受信することができる。上述した個人化放送システムの構造は設計者の意図によって変更されてもよい。
本発明の一実施例に係るコンテンツプロバイダ７０７は、コンテンツ、ＰＤＩ質問表及び／又はフィルタリング基準を受信機７００に伝送することができる。質問表及び特定ユーザによって与えられた回答を要約したデータ構造は、ＰＤＩ質問表と呼ばれる。本発明の一実施例に係るＰＤＩ質問表は、ユーザのプロファイル、人口統計、興味などに関する質問（又は、ＰＤＩ質問）を含むことができる。
受信機７００は、コンテンツプロバイダ７０７から受信したコンテンツ、ＰＤＩ質問表及び／又はフィルタリング基準を処理することができる。以下、図５８に示す受信機７００に含まれたモジュールの動作を中心に説明する。
本発明の一実施例に係るＰＤＩエンジン７０１は、まず、コンテンツプロバイダ７０７が提供するＰＤＩ質問表を受信することができる。ＰＤＩエンジン７０１は、受信したＰＤＩ質問表に含まれたＰＤＩ質問をＵＩ７０６に伝達することができる。当該のＰＤＩ質問に関するユーザの入力がある場合、ＰＤＩエンジン７０１は、該当のＰＤＩ質問に対するユーザの回答とその他の情報（以下、ＰＤＩ回答）をＵＩ７０６から受信することができる。その後、ＰＤＩエンジン７０１は、個人化サービスを提供するために、ＰＤＩ質問及びＰＤＩ回答を処理してＰＤＩデータを生成することができる。すなわち、本発明の一実施例に係るＰＤＩデータは、上述したＰＤＩ質問及び／又はＰＤＩ回答を含むことができる。したがって、ＰＤＩ質問表に対するＰＤＩ回答はまとめると、ユーザのプロファイル、人口統計、興味（又は、ＰＤＩ）を示す。
また、本発明の一実施例に係るＰＤＩエンジン７０１は、受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。具体的に、ＰＤＩエンジン７０１は、ＰＤＩ回答のＩＤを用いてＰＤＩデータを削除、追加及び／又は修正することができる。本発明の一実施例に係るＰＤＩ回答のＩＤの具体的な内容は後述する。また、他のモジュールでＰＤＩデータの受信を要求する場合、ＰＤＩエンジン７０１は、該当の要求に適したＰＤＩデータを該当のモジュールに伝達することができる。
本発明の一実施例に係るフィルタリングエンジン７０２は、ＰＤＩデータとフィルタリング基準によってコンテンツをフィルタすることができる。フィルタリング基準は、ＰＤＩデータを用いてユーザに適したコンテンツだけをフィルタするための基準（フィルタリング基準）の集合を意味する。具体的に、フィルタリングエンジン７０２は、ＰＤＩエンジン７０１からＰＤＩデータを受信することができ、コンテンツプロバイダ７０７からコンテンツ及び／又はフィルタリング基準を受信することができる。また、コンテンツプロバイダ７０７は、宣言コンテンツに関するパラメータを伝送する時、該当の宣言コンテンツに関連したフィルタリング基準テーブルを共に伝送することができる。その後、フィルタリングエンジン７０２は、フィルタリング基準とＰＤＩデータとをマッチングさせて比較し、比較結果によってコンテンツをフィルタしてダウンロードすることができる。ダウンロードしたコンテンツはコンテンツストア７０４に保存されてもよい。フィルタリング方法及びフィルタリング基準に関する具体的な内容は、図８４及び図８５と関連付けて後述する。
本発明の一実施例に係るＵＩモジュール７０６は、ＰＤＩエンジン７０１から受信したＰＤＩ質問をディスプレイし、該当のＰＤＩ質問に対してユーザからＰＤＩ回答を受信することができる。ユーザは、ディスプレイされたＰＤＩ質問に対して、リモコンを用いてＰＤＩ回答を受信機７００側に伝達することができる。ＵＩモジュール７０６は、受信したＰＤＩ回答をＰＤＩエンジン７０１に伝達することができる。
本発明の一実施例に係る宣言コンテンツモジュール７０５は、ＰＤＩエンジン７０１にアクセスしてＰＤＩデータを取得することができる。また、図５８に示すように、宣言コンテンツモジュール７０５は、コンテンツプロバイダ７０７が提供する宣言コンテンツを受信することができる。本発明の一実施例に係る宣言コンテンツは、受信機７００で実行されるアプリケーションに関するコンテンツであり、ＴＤＯのようなＤＯを含むことができる。
また、図５８には示していないが、本発明の一実施例に係る宣言コンテンツモジュール７０５は、ＰＤＩストア７０３にアクセスしてＰＤＩ質問及び／又はＰＤＩ回答を取得することができる。この場合、宣言コンテンツモジュール７０５は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用いることができる。具体的に、宣言コンテンツモジュール７０５は、ＡＰＩを用いてＰＤＩストア７０３を検索（ｒｅｔｒｉｅｖｅ）することによって、少なくとも一つ以上のＰＤＩ質問を取得することができる。その後、宣言コンテンツモジュール７０５は、ＵＩモジュール７０６を介してＰＤＩ質問を伝達したりＰＤＩ回答を受信し、受信したＰＤＩ回答をＰＤＩストア７０３に伝達することができる。
本発明の一実施例に係るＰＤＩストア７０３は、ＰＤＩ質問及び／又はＰＤＩ回答を保存することができる。
本発明の一実施例に係るコンテンツストア７０４は、フィルタされたコンテンツを保存することができる。
上述したように、図５８に示すＰＤＩエンジン７０１は、コンテンツプロバイダ７０７からＰＤＩ質問表（Ｑｕｅｓｔｉｏｎｎａｉｒｅ）を受信することができる。受信機７００は、ＵＩモジュール７０６を介して受信したＰＤＩ質問表のＰＤＩ質問をディスプレイし、該当のＰＤＩ質問に対するＰＤＩ回答をユーザから受信することができる。ＰＤＩエンジン７０１は、ＰＤＩ質問及び／又はＰＤＩ回答を含むＰＤＩデータをフィルタリングエンジン７０２に伝達することができる。フィルタリングエンジン７０２は、ＰＤＩデータとフィルタリング基準によってコンテンツをフィルタすることができる。したがって、受信機７００は、フィルタされたコンテンツをユーザに提供することによって個人化サービスを実現することができる。
図５９は、本発明の一実施例に係るデジタル放送システムを示す図である。
具体的に、図５９は、個人化サービスのための受信機を含む個人化放送システムの構造を示している。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０サービスを提供することができる。以下、個人化放送システムの構成エレメントについて説明する。
図５９に示すように、個人化放送システムは、コンテンツプロバイダ（又は、放送局）８０７及び／又は受信機８００を含むことができる。本発明の一実施例に係る受信機８００は、ＰＤＩエンジン８０１、フィルタリングエンジン８０２、ＰＤＩストア８０３、コンテンツストア８０４、宣言コンテンツモジュール８０５、ＵＩモジュール８０６、使用モニタリングエンジン８０８、及び／又は使用ログモジュール８０９を含むことができる。また、図５８に示すように、本発明の一実施例に係る受信機は、コンテンツプロバイダ８０７からコンテンツなどを受信することができる。図５９の基本的なモジュールは、図５８のモジュールと同一であり、ただし、図５８の放送システムとは違い、図５９の放送システムは、使用モニタリングエンジン８０８及び／又は使用ログモジュール８０９をさらに含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、使用モニタリングエンジン８０８及び使用ログモジュール８０９を中心に説明する。
本発明の一実施例に係る使用ログモジュール８０９は、ユーザの放送サービス使用内訳に関する情報（又は、ヒストリ情報）を保存することができる。ヒストリ情報は、２つ以上の使用データを含むことができる。本発明の一実施例に係る使用データは、一定時間にユーザがどのような放送サービスを利用したかに関する情報を意味する。具体的に、使用データは、午後９時にニュースを４０分間視聴したという情報、午後１１時に恐怖映画をダウンロードしたという情報などを含むことができる。
本発明の一実施例に係る使用モニタリングエンジン８０８は、ユーザの放送サービス使用現況を持続してモニタすることができる。その後、使用モニタリングエンジン８０８は、モニタリング結果を用いて、使用ログモジュール８０９に保存された使用データを削除、追加及び／又は修正することができる。また、本発明の一実施例に係る使用モニタリングエンジン８０８は、使用データをＰＤＩエンジン８０１に伝達することができ、ＰＤＩエンジン８０１は、伝達された使用データを用いてＰＤＩデータを更新することができる。
図６０は、本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図６０は、図５８及び図５９で説明した個人化放送システムのフィルタリングエンジン及びＰＤＩエンジンの動作を示すフローチャートである。
図６０に示すように、本発明の一実施例に係る受信機９００は、フィルタリングエンジン９０１及び／又はＰＤＩエンジン９０２を含むことができる。以下、本発明の一実施例に係るフィルタリングエンジン９０１及びＰＤＩエンジン９０２の動作を説明する。上述した受信機の構造は設計者の意図によって変更されてもよい。
図５８で説明したように、コンテンツをフィルタするために、本発明の一実施例に係る受信機９００は、フィルタリング基準とＰＤＩデータとをマッチングさせて比較することができる。
具体的に、本発明の一実施例に係るフィルタリングエンジン９０１は、コンテンツプロバイダからフィルタリング基準を受信し、ＰＤＩエンジン９０２にＰＤＩデータを要求するために信号（又は、ＰＤＩデータ要求信号）を伝達することができる。本発明の一実施例に係るＰＤＩエンジン９０２は、伝達されたＰＤＩデータ要求信号に応じて、該当のＰＤＩデータ要求信号に対応するＰＤＩデータを検索することができる。
図６０に示すフィルタリングエンジン９０１は、基準ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を含むＰＤＩデータ要求信号を、ＰＤＩエンジン９０２に伝達することができる。上述したように、フィルタリング基準は、フィルタリング基準の集合であり、それぞれのフィルタリング基準は、フィルタリング基準を識別するための基準ＩＤを含むことができる。また、本発明の一実施例に係る基準ＩＤは、ＰＤＩ質問及び／又はＰＤＩ回答を識別するために用いられてもよい。
ＰＤＩデータ要求信号を受信したＰＤＩエンジン９０２は、ＰＤＩストアにアクセスしてＰＤＩデータを検索することができる。本発明の一実施例に係るＰＤＩデータは、ＰＤＩ質問及び／又はＰＤＩ回答を識別するためのＰＤＩデータＩＤを含むことができる。図６０に示すＰＤＩエンジン９０２は、基準ＩＤとＰＤＩデータＩＤとをマッチングさせ、基準ＩＤとＰＤＩデータＩＤとが同一であるかを比較することができる。
マッチングの結果、基準ＩＤとＰＤＩデータＩＤとが一致し、これに対する値が同一であれば、受信機９００は、該当のコンテンツをダウンロードすることができる。具体的に、本発明の一実施例に係るフィルタリングエンジン９０１は、コンテンツをダウンロードするためのダウンロード要求信号をコンテンツプロバイダに伝達することができる。
マッチングの結果、基準ＩＤとＰＤＩデータＩＤが一致しないと、図６０に示すように、ＰＤＩエンジン９０２は、フィルタリングエンジン９０１にヌル（ｎｕｌｌ）ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を伝達することができる。ヌルＩＤを受信したフィルタリングエンジン９０１は、新しいＰＤＩデータ要求信号をＰＤＩエンジン９０２に伝達することができる。この場合、新しいＰＤＩデータ要求信号は、新しい基準ＩＤを含むことができる。
本発明の一実施例に係る受信機９００は、上述した方法によって、フィルタリング基準に含まれた全てのフィルタリング基準とＰＤＩデータとをマッチさせることができる。マッチングの結果、全てのフィルタリング基準がＰＤＩデータとマッチされると、フィルタリングエンジン９０１は、コンテンツをダウンロードするためのダウンロード要求信号を、コンテンツプロバイダに伝達することができる。
図６１は、本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図６１は、図５８及び図５９で説明した個人化放送システムのフィルタリングエンジン及びＰＤＩエンジンの動作を示すフローチャートである。
図６１に示すように、本発明の一実施例に係る受信機１０００は、フィルタリングエンジン１００１及び／又はＰＤＩエンジン１００２を含むことができる。上述した受信機の構造は設計者の意図によって変更されてもよい。図６１に示すフィルタリングエンジン１００１及びＰＤＩエンジン１００２の基本的な動作は、図６０で説明したとおりである。
ただし、フィルタリング基準とＰＤＩデータのマッチングの結果、基準ＩＤとＰＤＩデータＩＤが一致しないと、図６１に示す受信機１０００は、該当のコンテンツをダウンロードしないことを一実施例としてもよい。
具体的に、本発明のフィルタリングエンジン１００１は、ヌルＩＤを受信する場合、新しいＰＤＩデータ要求信号をＰＤＩエンジン１００２に伝達しないことを一実施例とすることができる。また、フィルタリング基準に含まれた全てのフィルタリング基準がＰＤＩデータとマッチされない場合、本発明のフィルタリングエンジン１００１はダウンロード要求信号をコンテンツプロバイダに伝達しないことを一実施例とすることができる。
図６２は、本発明の一実施例に係るＰＤＩテーブルを示す図である。
上述した図５８の個人化放送システムは、個人化サービスを提供するためにＰＤＩデータを使用する。ここで、ＰＤＩデータはＰＤＩテーブル形式で処理されてもよい。質問表及び特定ユーザによって与えられた回答を要約したデータ構造は、ＰＤＩ質問表又はＰＤＩテーブルと呼ばれる。データ構造は、使用可能な回答を含むことができるが、ＰＤＩテーブルはネットワーク、放送局、又はコンテンツプロバイダによって提供されるので、回答データを含まない。ＰＤＩテーブルでエントリの質問部分は非公式的に、“ＰＤＩ−質問”又は“ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する回答は非公式的に、“ＰＤＩ−Ａ”と呼ばれる。フィルタ基準の集合は非公式的に、“ＰＤＩ−ＦＣ”と呼ばれる。本発明のＰＤＩテーブルはＸＭＬスキーマで表現されることを一実施例とする。本発明の一実施例に係るＰＤＩテーブルのフォーマットは設計者の意図によって変更されてもよい。
図６２に示すように、本発明の一実施例に係るＰＤＩテーブルは、属性（ａｔｔｒｉｂｕｔｅｓ）１１１０及び／又はＰＤＩタイプエレメントを含むことができる。本発明の一実施例に係る属性１１１０は、ｔｒａｎｓａｃｔｉｏｎａｌ（取引）属性１１００、ｔｉｍｅ（時間）属性１１０１を含むことができる。本発明の一実施例に係るＰＤＩタイプエレメントは、ＱＩＡ（Ｑｕｅｓｔｉｏｎ ｗｉｔｈ Ｉｎｔｅｇｅｒ Ａｎｓｗｅｒ）エレメント１１０２、ＱＢＡ（Ｑｕｅｓｔｉｏｎ ｗｉｔｈ Ｂｏｏｌｅａｎ Ａｎｓｗｅｒ）エレメント１１０２、ＱＳＡ（Ｑｕｅｓｔｉｏｎ ｗｉｔｈ Ｓｅｌｅｃｔｉｏｎ Ａｎｓｗｅｒ）エレメント１１０４、ＱＴＡ（Ｑｕｅｓｔｉｏｎ ｗｉｔｈ Ｔｅｘｔ Ａｎｓｗｅｒ）エレメント１１０５、及び／又はＱＡＡ（Ｑｕｅｓｔｉｏｎ ｗｉｔｈ Ａｎｙ−ｆｏｒｍａｔ Ａｎｓｗｅｒ）エレメント１１０６を含むことができる。以下、図６２に示すＰＤＩテーブルの構成エレメントについて説明する。
具体的に、図６２に示す属性１１１０は、本発明の一実施例に係るＰＤＩテーブル自体の属性情報を示すことができる。したがって、ＰＤＩテーブルが含むＰＤＩタイプエレメントが変わっても、属性１１１０は、本発明の一実施例に係るＰＤＩテーブルに同一に表現されてもよい。例えば、本発明の一実施例に係るｔｒａｎｓａｃｔｉｏｎａｌ属性１１００は、ＰＤＩ質問の目的に関する情報を示すことができる。本発明の一実施例に係るｔｉｍｅ属性１１０１は、ＰＤＩテーブルが生成されたりアップデートされた時間に関する情報を示すことができる。この場合、別個のＰＤＩタイプエレメントを含むＰＤＩテーブルは、ＰＤＩタイプエレメントが変わっても、ｔｒａｎｓａｃｔｉｏｎａｌ属性１１００及び／又はｔｉｍｅ属性１１０１を含むことができる。
また、本発明の一実施例に係るＰＤＩテーブルは、ルートエレメント（ｒｏｏｔ ｅｌｅｍｅｎｔ）として１つ又は２以上のＰＤＩタイプエレメント１１０２を含むことができる。この場合、ＰＤＩタイプエレメント１１０２はリスト形式で表現されてもよい。
本発明の一実施例に係るＰＤＩタイプエレメントは、ＰＤＩ回答のタイプによって区別することができる。例えば、本発明の一実施例に係るＰＤＩタイプエレメントは、“ＱｘＡ”エレメントと呼ぶことができ、この場合、“ｘ”はＰＤＩ回答のタイプによって決定されてもよい。本発明の一実施例に係るＰＤＩ回答のタイプは、整数タイプ、ブール（Ｂｏｏｌｅａｎ）タイプ、選択タイプ、テキストタイプの他、いずれのタイプの回答をも含むことができる。
本発明の一実施例に係るＱＩＡエレメント１１０３は、一つのＰＤＩ質問及び／又は該当のＰＤＩ質問に対する整数タイプのＰＤＩ回答を含むことができる。
本発明の一実施例に係るＱＢＡエレメント１１０４は、一つのＰＤＩ質問及び／又は該当のＰＤＩ質問に対するブールタイプのＰＤＩ回答を含むことができる。
本発明の一実施例に係るＱＳＡエレメント１１０５は、一つのＰＤＩ質問及び／又は該当のＰＤＩ質問に対する多重選択（ｓｅｌｅｃｔｉｏｎ）タイプのＰＤＩ回答を含むことができる。
本発明の一実施例に係るＱＴＡエレメント１１０６は、一つのＰＤＩ質問及び／又は該当のＰＤＩ質問に対する文字列（ｔｅｘｔ）タイプのＰＤＩ回答を含むことができる。
本発明の一実施例に係るＱＡＡエレメント１１０７は、一つのＰＤＩ質問及び／又は該当のＰＤＩ質問に対する整数、ブール、多重選択及び文字列形態の他、いかなる形態のＰＤＩ回答をも含むことができる。
図６３は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６３は、図６２で説明したＰＤＩタイプエレメントのうち、ＱＩＡエレメントのＸＭＬスキーマを示す図である。
図６３に示すように、ＱＩＡエレメントは、ＰＤＩ質問タイプと関連した特徴に関する情報を示す属性１２１０、ｉｄ属性１２２０、質問エレメント１２３０及び／又は回答エレメント１２４０を含むことができる。
具体的に、本発明の一実施例に係る属性１２１０は、ＰＤＩ質問の言語を示すｌａｎｇ属性を含むことができる。また、本発明の一実施例に係るＱＩＡエレメントの属性１２１０は、ＰＤＩ回答が有し得る最小の整数値を示すｍｉｎＩｎｃｌｕｓｉｖｅ属性１２３０、及び／又はＰＤＩ回答が有し得る最大の整数値を示すｍａｘＩｎｃｌｕｓｉｖｅ属性１２４０を含むことができる。
また、本発明の一実施例に係るｉｄ属性１２２０は、ＰＤＩ質問及び／又はＰＤＩ回答を識別するために用いることができる。
また、本発明の一実施例に係る質問エレメント１２３０は、ＰＤＩ質問自体を含むことができる。図６３に示すように、質問エレメント１２３０は、ＰＤＩ質問に関する情報を示す属性を含むことができる。例えば、質問エレメント１２３０は、ＰＤＩ質問が生成された時間又はＰＤＩ質問が送信された時間を示すｔｉｍｅ属性１２３１、及び／又はＰＤＩ質問の有効時間を示すｅｘｐｉｒａｔｉｏｎ（満了）属性１２３２を含むことができる。
また、本発明の一実施例に係る回答エレメント１２４０は、ＰＤＩ回答自体を含む。図６３に示すように、回答エレメント１２４０は、ＰＤＩ回答に関する情報を示す属性を含むことができる。例えば、図１２に示すように、回答エレメント１２４０は、それぞれのＰＤＩ回答を認識するために使用可能なｉｄ属性１２４１、及び／又はそれぞれのＰＤＩ回答が生成されたり修正された時間を示すｔｉｍｅ属性１２４２を含むことができる。
図６４は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６４は、図６２で説明したＰＤＩタイプエレメントのうち、ＱＢＡエレメントのＸＭＬスキーマを示す図である。
図６４に示すように、ＱＢＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは、図６３で説明したとおりであり、具体的な説明は省略する。
図６５は、本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６５は、図６２で説明したＰＤＩタイプエレメントのうち、ＱＳＡエレメントのＸＭＬスキーマを示す図である。
図６５に示すＱＳＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは、図６３で説明したとおりであり、具体的な説明は省略する。
ただし、多重選択質問の特性によって、本発明の一実施例に係るＱＳＡエレメントの属性は、ｍｉｎＣｈｏｉｃｅ属性１４１１及び／又はｍａｘＣｈｏｉｃｅ属性１４１２をさらに含むことができる。本発明の一実施例に係るｍｉｎＣｈｏｉｃｅ属性１４１１は、ユーザが選択できるＰＤＩ回答の最小の個数を示すことができる。本発明の一実施例に係るｍａｘＣｈｏｉｃｅ属性１４１２は、ユーザが選択できるＰＤＩ回答の最大の個数を示すことができる。
図６６は、本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６６は、図６２で説明したＰＤＩタイプエレメントのうち、ＱＡＡエレメントのＸＭＬスキーマを示す図である。
図６６に示すように、ＱＡＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは、図６３で説明したとおりであり、具体的な説明は省略する。
図６７は、本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６７は、図６２乃至図６６で説明したＰＤＩテーブルと同様に、ＰＤＩテーブルの拡張されたフォーマットをＸＭＬスキーマで示している。
上述したように、本発明では個人化サービスを提供するためにＰＤＩテーブルを用いることを一実施例とする。ただし、同じユーザであっても、ユーザの属した状況によって好むコンテンツが変更されうる。
したがって、本発明では、上述した問題点を解決するために、ＰＤＩテーブルにユーザの状況情報を示す構成エレメントをさらに含むことを一実施例とすることができる。
図６７に示すＰＤＩテーブルは、ユーザの状況情報を示す構成エレメントとして状況エレメント１６００をさらに含むことができる。図６７に示すＰＤＩテーブルの基本的なＸＭＬスキーマは、図６２乃至図６６で説明したとおりであり、具体的な説明は省略する。以下、状況エレメント１６００を説明する。
本発明の一実施例に係る状況エレメント１６００は、ユーザの状況情報として時間帯及び／又は位置に関する情報を示すことができる。図６７に示すように、状況エレメント１６００は、時間エレメント１６１０、位置エレメント１６２０、及び／又はユーザの状況情報を示すその他のエレメントをさらに含むことができる。以下、各エレメントを説明する。
本発明の一実施例に係る時間エレメント１６１０は、ユーザの属した地域の時間に関連した情報を含むことができる。例えば、本発明の一実施例に係る時間エレメント１６１０は、“ｙｙｙｙ−ｍｍ−ｄｄ”形式の時間情報を示すｔｉｍｅ属性１６１１、及び／又はユーザの属した地域の時間帯を示すｔｉｍｅｚｏｎｅ属性１６１２を含むことができる。
本発明の一実施例に係る位置エレメント１６２０は、ユーザの属している地域の位置情報を含むことができる。例えば、図６７に示すように、位置エレメント１６２０は、該当の位置の情報を示すｌｏｃａｔｉｏｎ−ｄｅｓｃ属性１６２１、該当の位置の緯度情報を示すｌａｔｉｔｕｄｅ属性１６２２、及び／又は該当の位置の経度情報を示すｌｏｎｇｉｔｕｄｅ属性１６２３を含むことができる。
図６８及び図６９は、本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図６８及び図６９は、図６２乃至図６７で説明したＸＭＬスキーマによるＰＤＩテーブルの一実施例を示す図である。
図６８及び図６９は、ＰＤＩテーブルインスタンス文書の構造を定義するＰＤＩテーブルと呼ばれるルートエレメントに対するＸＭＬスキーマ定義を示す。本発明の一実施例に係るＰＤＩテーブルインスタンス文書は、ＰＤＩテーブルをＸＭＬスキーマによって実装して得られた実際の文書を意味する。
図６８及び図６９はまた、ＰＤＩ ＡＰＩを用いてＤＯと内在された受信機との間でやり取りできる個別質問を示すルートエレメントＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡに対するＸＭＬスキーマ定義も示す。本発明の一実施例に係るＰＤＩ ＡＰＩに関する具体的な内容は後述する。図６８及び図６９に示すエレメントは、名称空間が“ｈｔｔｐ：／／ｗｗｗ．ａｔｓｃ．ｏｒｇ／ＸＭＬＳｃｈｅｍａｓ／ｉｓｓ／ｐｄｉ／１”であるＸＭＬスキーマにおける定義に従うことができる。
ＰＤＩ質問（又は、ＰＤＩ−Ｑ）とＰＤＩ回答（又は、ＰＤＩ−Ａ）との差異は、スキーマ自体よりは使用規則に明示されている。ＰＤＩテーブルで、エントリの質問部分は非公式的に、“ＰＤＩ質問”又は“ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する回答は非公式的に、“ＰＤＩ−Ａ”と呼ばれる。例えば、スキーマが様々な種類の質問の“ｑ”エレメントに対するｍｉｎＯｃｃｕｒｓ＝“０”を示すが、スキーマがＰＤＩ−Ｑに用いられると、その場合“ｑ”エレメントの使用は必須である。スキーマがＰＤＩ−Ａに用いられると、“ｑ”エレメントは選択的に含まれればよい。
ＰＤＩ−Ｑインスタンス文書は、名称空間と共に、ＡＴＳＣ２．０標準の一部である“ＰＤＩテーブル”ＸＭＬスキーマに従うことができ、その定義は、差異がある場合、ここに提供された説明に優先してもよい。本発明の一実施例に係るＰＤＩ−Ｑインスタンス文書は、ＰＤＩ−Ｑを含むＰＤＩテーブルをＸＭＬスキーマによって実装した実際文書を意味する。
ＰＤＩ−Ｑインスタンス文書は、ＱＩＡ（ｉｎｔｅｇｅｒ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、ＱＢＡ（Ｂｏｏｌｅａｎ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、ＱＳＡ（ｓｅｌｅｃｔｉｏｎ−ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、及び／又はＱＴＡ（ｔｅｘｔｕａｌ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）タイプの一つ以上のエレメントで構成される。
これらの最上位エレメントの“Ａ”（回答）下位エレメントでないエレメントが、ＰＤＩ−Ｑインスタンスに存在してもよい。
それら各エレメントの識別子属性（“ｉｄ”）は、ＰＤＩ−Ａインスタンス文書で該当のエレメントに対する連結又は基準の役割を担うことができる。本発明の一実施例に係るＰＤＩ−Ａインスタンス文書は、ＰＤＩ−Ａを含むＰＤＩテーブルをＸＭＬスキーマによって実装した実際文書を意味する。
ＰＤＩ−Ａインスタンス文書は、名称空間と共に、ＡＴＳＣ２．０標準の一部である“ＰＤＩテーブル”ＸＭＬスキーマに従うことができ、その定義は、差異が発生する場合、ここに提供された説明に優先してもよい。
ＰＤＩ−Ａインスタンス文書は、ＱＩＡ（ｉｎｔｅｇｅｒ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、ＱＢＡ（Ｂｏｏｌｅａｎ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、ＱＳＡ（ｓｅｌｅｃｔｉｏｎ−ｔｙｐｅ ａｎｓｗｅｒ ｑｕｅｓｔｉｏｎ）、ＱＴＡ（ｔｅｘｔｕａｌ−ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）、及び／又はＱＡＡ（ａｎｙ−ｆｏｒｍａｔ ａｎｓｗｅｒ ｔｙｐｅ ｑｕｅｓｔｉｏｎ）タイプの一つ以上のエレメントで構成される。
それら各エレメントは、少なくとも一つの“Ａ”（回答）下位エレメントを有する。これらは“Ｑ”（質問ストリング）下位エレメントを含んでもよく、含まなくてもよい。
それら各エレメントの識別子属性（“ｉｄ”）は、ＰＤＩ−Ｑインスタンス文書で該当のエレメントに対する連結又は基準の役割を担うことができる。
以下、図６８及び図６９に示すＰＤＩテーブルに含まれたエレメント及び属性のセマンティクス（ｓｅｍａｎｔｉｃｓ）について説明する。
図６８及び図６９に示すように、本発明の一実施例に係るＰＤＩテーブルでは、属性名の前に“＠”を表示することによって、属性とエレメントとを区別することができる。
また、本発明の一実施例に係るＰＤＩテーブルは、ＰＤＩタイプエレメントを含むことができる。具体的に、ＰＤＩタイプエレメントは、図６２で説明したとおり、ＱＩＡエレメント、ＱＢＡエレメント、ＱＳＡエレメント、ＱＴＡエレメント及び／又はＱＡＡエレメントを含むことができる。
また、図６８及び図６９に示すように、本発明の一実施例に係るＰＤＩテーブルは、質問タイプエレメントと関係なくｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、ｐｄｉＴａｂｌｅＩｄ属性、ｐｄｉＴａｂｌｅＶｅｒｓｉｏｎ属性及び／又はｔｉｍｅ属性を含むことができる。
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、及びＱＡＡエレメントのｉｄ属性は、これらの各エレメントのｅｘｐｉｒａｔｉｏｎ属性と同様に、いずれも同一のセマンティクスを有する。同様に、各Ａエレメントのｔｉｍｅ属性と同様に、各Ｑエレメントのｌａｎｇ属性はそれぞれ同一のセマンティクスを有する。また、ｉｄ属性は、図６０で上述したＰＤＩデータ識別子を意味することができる。
ＰＤＩＴａｂｌｅエレメントは、一つ以上の質問エレメントのリストを含む。それぞれは、ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡのフォーマットを有する。基数（ｃａｒｄｉｎａｌｉｔｙ）０．．Ｎで構成された＜ｃｈｏｉｃｅ＞の使用は、ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、及びＱＡＡエレメントのいずれかの個数がいずれかの順序で表れ得るということを意味する。
ＰＤＩＴａｂｌｅエレメントのｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性は、２個の１６進数で構成される。上位４ビットは、テーブル定義のメジャー（ｍａｊｏｒ）バージョン数を示す。下位４ビットは、テーブル定義のマイナー（ｍｉｎｏｒ）バージョン数を示す。当該標準の当該バージョンに対するメジャーバージョン数は、１に設定される。受信機は、サポートするように準備されていないメジャーバージョン数を示すＰＤＩのインスタンスを捨てるようになっている。当該標準の当該バージョンに対するマイナーバージョン数は、０に設定される。受信機は、サポートするように準備されていないマイナーバージョン数を示すＰＤＩのインスタンスを捨てないようになっている。この場合、受信機は、サポートしない個別エレメント又は属性を無視するようになっている。
ＰＤＩＴａｂｌｅエレメントのｐｄｉＴａｂｌｅＩｄ属性は、該ＰＤＩテーブルエレメントのグローバルに一意な識別子であってもよい。
ＰＤＩＴａｂｌｅエレメントの８ビットのｐｄｉＴａｂｌｅＶｅｒｓｉｏｎ属性は、当該ＰＤＩテーブルエレメントのバージョンを示す。初期値は０であってもよい。当該値は、当該ＰＤＩテーブルのエレメントが変化する度に１ずつ増加し、２５５後に０にロールオーバー（ｒｏｌｌｏｖｅｒ）されてもよい。
ＰＤＩＴａｂｌｅエレメントのｔｉｍｅ属性は、当該ＰＤＩテーブルにおいてある質問への最後の変化の日及び時間を示す。
ＱＩＡエレメントは、質問の整数回答タイプを示す。これは、回答の最大及び最小の許容値を明示する選択的許容値を含む。
ＱＩＡのＱＩＡ．ｌｏＥｎｄ属性は、当該ＱＩＡエレメントの“Ａ”下位エレメントの最小可能値を示す。すなわち、“Ａ”エレメントの値は、ｌｏＥｎｄよりも小さくない。ｌｏＥｎｄ属性が存在しなければ、これは最小値がないことを示す。
ＱＩＡのＱＩＡ．ｈｉＥｎｄ属性は、当該ＱＩＡエレメントの“Ａ”下位エレメントの最大可能値を示す。すなわち、回答の値はｈｉＥｎｄよりも大きくない。ｈｉＥｎｄ属性が存在しなければ、これは最大値がないことを示す。
ＱＩＡ．Ｑエレメントは、ＱＩＡエレメントの下位エレメントである。ＱＩＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、整数タイプ回答を有するように表現されなければならない。当該エレメントには、互いに異なる言語の様々なインスタンスがある。
ＱＩＡエレメントの下位エレメントとしてＱＩＡ．Ａエレメントは整数値を有することができる。ＱＩＡ．Ａエレメントは、ＱＩＡ．Ｑにおいて質問に対する回答を示すことができる。
ＱＢＡエレメントは、質問のブール回答タイプを示すことができる。
ＱＢＡ．Ｑエレメントは、ＱＢＡエレメントの下位エレメントである。ＱＢＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、はい／いいえ又は真／偽の形態の回答を有するように表現されなければならない。当該エレメントには、互いに異なる言語の様々なインスタンスがある。
ＱＢＡエレメントの下位エレメントとしてＱＢＡ．Ａエレメントはブール値を有することができる。ＱＢＡ．Ａエレメントは、ＱＢＡ．Ｑで質問に対する回答を示すことができる。
ＱＳＡエレメントは、質問の選択回答タイプを示すことができる。
ＱＳＡエレメントのＱＳＡ．ｍｉｎＣｈｏｉｃｅｓ属性は、ユーザによって生成可能な選択の最小個数を明示することができる。
ＱＳＡエレメントのＱＳＡ．ｍａｘＣｈｏｉｃｅｓ属性は、ユーザによって生成可能な選択の最大個数を明示することができる。
ＱＳＡ．Ｑエレメントは、ＱＳＡエレメントの下位エレメントである。ＱＳＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、一つ以上の与えられた選択に該当する回答を有するように表現されなければならない。
ＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎエレメントは、ＱＳＡ．Ｑエレメントの下位エレメントである。ＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎエレメントの値は、ユーザに提示される可能性のある選択を示すことができる。同一ＱＳＡエレメントに（異なる言語で）複数のＱＳＡ．Ｑ下位エレメントが存在すると、それぞれは同一意味を有する同一の数のＳｅｌｅｃｔｉｏｎ下位エレメントを有する。
ＱＳＡ．Ｑ．ＳｅｌｅｃｔｉｏｎのＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎ．ｉｄ属性は、ＱＳＡ．Ｑの範囲内で唯一のＳｅｌｅｃｔｉｏｎエレメントに対する識別子であってもよい。同一ＱＳＡエレメントに（異なる言語で）複数のＱＳＡ．Ｑ下位エレメントが存在すると、それらの同一意味を有するＳｅｌｅｃｔｉｏｎエレメントのｉｄ属性間には一対一対応があってもよい。
ＱＳＡ．Ａは、ＱＳＡエレメントの下位エレメントである。当該ＱＳＡエレメントの下位エレメントの各インスタンスは、Ｓｅｌｅｃｔｉｏｎエレメントのうち、一つのｉｄ値の形態で当該ｓｅｌｅｃｔｉｏｎタイプ質問に許容された一つの回答を明示することができる。
ＱＴＡエレメントは質問のテキスト回答（叙述型エントリ）タイプを示す。
ＱＴＡ．Ｑエレメントは、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、叙述型回答を有するように表現されなければならない。
ＱＴＡ．Ａエレメントは、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ａエレメントエレメントの値は、ＱＴＡ，Ｑで質問に対する回答を示すことができる。
ＱＡＡエレメントは、データベースにおけるエントリのように、様々なタイプの情報を保有するように用いられてもよい。
ＱＡＡ．Ａエレメントは、ＱＡＡエレメントの下位エレメントである。ＱＡＡ．Ａエレメントの値はいくつかのタイプの情報を含む。
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、ＱＡＡエレメントのｉｄ属性は、それが示すエレメントに対してグローバルに一意の識別子であるＵＲＩであってもよい。
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、ＱＡＡエレメントのｅｘｐｉｒｅエレメントは、それが現れるエレメントがそれ以上関連しておらず、テーブルから削除される日付及び時間を示すことができる。
ＱＩＡ．Ｑ、ＱＢＡ．Ｑ、ＱＳＡ．Ｑ、ＱＴＡ．Ｑ、ＱＴＡ．Ａエレメントのｌａｎｇ属性は、質問又は回答ストリングの言語を示すことができる。ＱＳＡ．Ｑの場合、ｌａｎｇ属性は、ＱＳＡ．ＱのＳｅｌｅｃｔｉｏｎ下位エレメントの言語も示すことができる。ｌａｎｇ属性が存在しなければ、これは、当該言語が英語であることを示すことができる。
ＱＩＡ．Ａ、ＱＢＡ．Ａ、ＱＳＡ．Ａ、ＱＴＡ．Ａ、ＱＡＡ．Ａエレメントのｔｉｍｅ属性は、回答がテーブルに入力された日付及び時間を示すことができる。
また、図６８及び図６９に示してはいないが、本発明の一実施例に係るＰＤＩテーブルは、ＱＩＡＤエレメント、ＱＢＡＤエレメント、ＱＳＡＤエレメント、ＱＴＡＤエレメント、及び／又はＱＡＡＤエレメントをさらに含むことができる。上述したエレメントは総称してＱｘＡＤエレメントと呼ぶ。以下、ＱｘＡＤエレメントについて説明する。
ルートエレメントとしてのＱＩＡＤエレメントは、ＱＩＡ下位エレメントで整数回答タイプの質問を含むことができる。ＱＩＡは、回答の最大及び最小の許容値を明示する選択的許容値を含むことができる。
ルートエレメントとしてのＱＢＡＤエレメントは、質問のブール回答タイプを示すだろう。
ルートエレメントとしてのＱＳＡＤエレメントは、質問の選択回答タイプを示すだろう。
ルートエレメントとしてのＱＴＡＤエレメントは、質問のテキスト回答（叙述型エントリ）タイプを示すだろう。
ルートエレメントとしてのＱＡＡＤエレメントは、データベースにおけるエントリのように、様々なタイプの情報を保有するように用いられるはずである。
また、図６８及び図６９に示してはいないが、本発明の一実施例に係るそれぞれのＰＤＩタイプエレメントは、ＱＴｅｘｔエレメント及び／又はｔｉｍｅ属性をさらに含むことができる。
ＱＩＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＩＡ．Ｑエレメントの下位エレメントである。ＱＩＡ．Ｑ．ＱＴｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示すだろう。質問は、整数タイプ回答を有するように表現されなければならない。
ＱＩＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＩＡ．Ａエレメントの整数値属性である。ＱＩＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＩＡ．Ｑ．ＱＴｅｘｔエレメントで質問に対する回答を示すだろう。
ＱＢＡ．Ｑ．Ｑｔｅｘｔエレメントは、ＱＢＡ．Ｑエレメントの下位エレメントである。ＱＢＡ．Ｑ．Ｑｔｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示すだろう。質問は、はい／いいえ又は真／偽の形態の回答を有するように表現されなければならない。当該エレメントには、異なる言語の様々なインスタンスがあってもよい。
ＱＢＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＢＡ．Ａエレメントのブール値属性である。ＱＢＡ．Ａ＠ａｎｓｗｅｒ属性は、ＱＢＡ．Ｑ．ＱＴｅｘｔエレメントで質問に対する回答を示すだろう。
ＱＳＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＳＡ．Ｑエレメントの下位エレメントである。ＱＳＡ．Ｑ．ＱＴｅｘｔエレメントは、ユーザに提示される質問ストリングを示すだろう。質問は、一つ以上の与えられた選択に対応する回答を有するように表現されなければならない。当該エレメントには、異なる言語の様々なインスタンスがあってもよい。
ＱＳＡ．Ａ下位エレメントのＱＳＡ．Ａ．ａｎｓｗｅｒ属性は、Ｓｅｌｅｃｔｉｏｎエレメントのうち、一つのｉｄ値の形態で、当該選択タイプ質問に対して許容された一つの回答を明示するだろう。
ＱＴＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ｑ．ＱＴｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示すだろう。質問は、叙述型回答を有するように表現されなければならない。
ＱＴＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ａ．ａｎｓｗｅｒエレメントの値は、ＱＴＡ．Ｑ．ＱＴｅｘｔエレメントで質問に対する回答を示す。
図７０及び図７１は、本発明の更に他の実施例に係るＰＤＩテーブルを示す図である。
具体的に、図７０及び７１は、図６２乃至図６７で説明したＸＭＬスキーマによるＰＤＩテーブルの構造を示す図である。
図７０及び７１に示すＰＤＩテーブルの基本的な構造とＰＤＩテーブルに含まれた基本的なエレメント及び属性のセマンティクスは、図６８及び図６９で説明したとおりである。ただし、図６８及び図６９に示すＰＤＩテーブルとは違い、図７０及び７１に示すＰＤＩテーブルは、ｘａｃｔｉｏｎＳｅｔＩｄ属性及び／又はｔｅｘｔ属性をさらに含むことができる。以下、ｘａｃｔｉｏｎＳｅｔＩｄ属性及び／又はｔｅｘｔ属性を中心に説明する。
ＱｘＡエレメントのｘａｃｔｉｏｎＳｅｔＩｄ属性は、質問に対する回答を目的とするユニットとして取り扱われる集合である質問のｔｒａｎｓａｃｔｉｏｎａｌ集合に質問が属することを示す。又は、これは、質問の属するｔｒａｎｓａｃｔｉｏｎａｌ集合に対する識別子を提供する。したがって、同じｘａｃｔｉｏｎＳｅｔＩｄ属性の値を有するＰＤＩテーブルにおける全質問の集合は、全てか無かに基づいて（ｏｎ ａｌｌ ｏｒ ｎｏｔｈｉｎｇ ｂａｓｉｓ）回答される。
ＱｘＡエレメントのｔｅｘｔ属性は、ＱｘＡ．Ｑエレメントの下位エレメントである。ｔｅｘｔ属性の値は、ユーザに提示される質問ストリングを示すだろう。
図７２は、本発明の一実施例に係るフィルタリング基準テーブルを示す図である。上述した図５８の個人化放送システムは、個人化サービスを提供するためにフィルタリング基準を用いることができる。図５８、図６０及び図６１で説明したフィルタリング基準は、フィルタリング基準テーブル形式で処理されてもよい。本発明のフィルタリング基準テーブルはＸＭＬスキーマで表現されることを一実施例とする。
また、本発明のフィルタリング基準テーブルは、ＰＤＩデータとフィルタリング基準を効率的に比較するために、ＰＤＩテーブルのフォーマットと類似するフォーマットを有することを一実施例とすることができる。本発明の一実施例に係るフィルタリング基準テーブルのフォーマットは、設計者の意図によって変更可能である。
図７２に示すように、本発明の一実施例に係るフィルタリング基準テーブルは、ｆｉｌｔｅｒｉｎｇ ｃｒｉｔｅｒｉｏｎエレメント１９００を含むことができ、ｆｉｌｔｅｒｉｎｇ ｃｒｉｔｅｒｉｏｎエレメント１９００は、ｉｄｅｎｔｉｆｉｅｒ属性１９０１、ｃｒｉｔｅｒｉｏｎ ｔｙｐｅ属性１９０２、及び／又はｃｒｉｔｅｒｉｏｎ ｖａｌｕｅエレメント１９０３を含むことができる。本発明のフィルタリング基準は、上述したＰＤＩ質問に対応する概念として用いられてもよい。以下、図７２に示すフィルタリング基準テーブルの構成エレメントについて説明する。
本発明の一実施例に係るｆｉｌｔｅｒｉｎｇ ｃｒｉｔｅｒｉｏｎエレメント１９００は、ＰＤＩ質問に対応するフィルタリング基準を示すことができる。
本発明の一実施例に係るｉｄｅｎｔｉｆｉｅｒ属性１９０１は、フィルタリング基準に対応するＰＤＩ質問を識別することができる。
本発明の一実施例に係るｃｒｉｔｅｒｉｏｎ ｔｙｐｅ属性１９０２は、フィルタリング基準のタイプを示すことができる。フィルタリング基準のタイプに関する具体的な内容は後述する。
本発明の一実施例に係るｃｒｉｔｅｒｉｏｎ ｖａｌｕｅエレメント１９０３は、フィルタリング基準が有する値を示すことができる。各基準値は、ＰＤＩ質問に対する可能な回答である。
具体的に、本発明に係るフィルタリング基準のタイプは、整数タイプ、ブールタイプ、選択タイプ、テキストタイプ、及び／又は任意タイプのいずかれ一タイプを一実施例とすることができる。
整数タイプのフィルタリング基準（又は、整数タイプ基準）は、整数タイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
ブールタイプのフィルタリング基準（又は、ブールタイプ基準）は、ブールタイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
選択タイプのフィルタリング基準（又は、選択タイプ基準）は、選択タイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
テキストタイプのフィルタリング基準（又は、テキストタイプ基準）は、テキストタイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
任意タイプのフィルタリング基準（又は、任意タイプ基準）は、上述した４つのタイプ以外の全ての形態のＰＤＩ回答に対応するフィルタリング基準を意味する。
以下、［例示５］は、図７２に示すフィルタリング基準テーブルのＸＭＬスキーマを示す本発明の一実施例である。
［例示５］
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="FilterCriterion" type="FilterCriterionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FilterCriterionType">
<xs:sequence>
<xs:element name="CriterionValue" type="xs:base64Binary" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:anyURI" use="required"/>
<xs:attribute name="CriterionType" type="xs:unsignedByte" use="required"/>
</xs:complexType>
</xs:schema>
図７３は、本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
具体的に、図７３は、図７２で説明したフィルタリング基準テーブルの拡張されたフォーマットをＸＭＬスキーマで表現した図である。図７２に示すフィルタリング基準のＸＭＬスキーマによってフィルタリング基準テーブルを構成する場合、本発明の一実施例に係るフィルタリング基準のタイプと各タイプ別細部属性を設定できないという問題点がある。したがって、図７３では、フィルタリング基準のタイプを表現し、各タイプ別属性を設定したＸＭＬスキーマを提示しようとする。本発明の一実施例に係る個人化放送システムは、図７３によるＸＭＬスキーマによって構成されたフィルタリング基準テーブルを用いて、より精密にコンテンツをフィルタすることができる。
図７３に示すように、フィルタリング基準テーブルは、属性２０００及び／又はフィルタリング基準タイプエレメントを含むことができる。本発明の一実施例に係る属性２０００は、ｔｉｍｅ属性２００１を含むことができる。本発明の一実施例に係るフィルタリング基準タイプエレメントは、整数タイプ基準エレメント（Ｉｎｔｅｇｅｒ Ｔｙｐｅ Ｃｒｉｔｅｒｉｏｎエレメント）（又は、ＱＩＡ基準エレメント）２０１０、ブールタイプ基準エレメント（Ｂｏｏｌｅａｎ Ｔｙｐｅ Ｃｒｉｔｅｒｉｏｎエレメント）（又は、ＱＢＡ基準エレメント）２０２０、選択タイプ基準エレメント（Ｓｅｌｅｃｔｉｏｎ Ｔｙｐｅ Ｃｒｉｔｅｒｉｏｎ ｅｌｅｍｅｎｔ）（又は、ＱＳＡ基準エレメント）２０３０、テキストタイプ基準エレメント（Ｔｅｘｔ Ｔｙｐｅ Ｃｒｉｔｅｒｉｏｎ ｅｌｅｍｅｎｔ）（又は、ＱＴＡ基準エレメント）２０４０、及び／又は任意タイプ基準エレメント（Ａｎｙ Ｔｙｐｅ Ｃｒｉｔｅｒｉｏｎ ｅｌｅｍｅｎｔ）（又は、ＱＡＡ基準エレメント）２０５０を含むことができる。以下、図７３に示すフィルタリング基準テーブルの構成エレメントについて説明する。
具体的に、図７３に示す属性２０００は、本発明の一実施例に係るフィルタリング基準テーブル自体の属性情報を示すことができる。したがって、フィルタリング基準テーブルが含むフィルタリング基準タイプエレメントが変わっても同一に表現することができる。例えば、本発明の実施例に係るｔｉｍｅ属性２００１は、フィルタリング基準が生成された時間又は更新された時間を示すことができる。この場合、互いに異なるフィルタリング基準タイプエレメントを含むフィルタリング基準テーブルは、フィルタリング基準タイプエレメントが変わってもｔｉｍｅ属性２００１を含むことができる。
また、本発明の一実施例に係るフィルタリング基準テーブルは、１つ又は２つ以上のフィルタリング基準タイプエレメントを含むことができる。本発明の一実施例に係るフィルタリング基準タイプエレメントは、フィルタリング基準のタイプを示すことができる。フィルタリング基準のタイプは、図７２で説明したとおりである。この場合、フィルタリング基準タイプエレメントはリスト形式で表現されてもよい。
本発明の一実施例に係るフィルタリング基準タイプエレメントを“ＱｘＡ”基準と呼ぶこともでき、この場合、“ｘ”はフィルタリング基準のタイプによって決定されてもよい。
図７３に示すように、それぞれのフィルタリング基準タイプエレメントは、識別子属性及び／又は基準値エレメントを含むことができる。図７３に示す識別子属性（ｉｄｅｎｔｉｆｉｅｒ属性）及び基準値エレメントの具体的な内容は、図７２で説明したとおりである。
ただし、図７３に示すように、整数タイプ基準エレメント２０１０は、ｍｉｎ ｉｎｔｅｇｅｒ属性２０１１、及び／又はｍａｘ ｉｎｔｅｇｅｒ属性２０１２をさらに含むことができる。本発明の一実施例に係るｍｉｎ ｉｎｔｅｇｅｒ属性２０１１は、整数タイプの回答で表現されたフィルタリング基準の最小値を示すことができる。本発明の一実施例に係るｍａｘ ｉｎｔｅｇｅｒ属性２０１２は、整数タイプの回答で表現されたフィルタリング基準の最大値を示すことができる。
また、図７３に示すように、ｓｅｌｅｃｔｉｏｎ ｔｙｐｅ ｃｒｉｔｅｒｉｏｎエレメント２０３０及び／又はｔｅｘｔ ｔｙｐｅ ｃｒｉｔｅｒｉｏｎエレメント２０４０は、ｌａｎｇ属性２０３１を含むことができる。本発明の一実施例に係るｌａｎｇ属性２０３１は、文字列の形態で表現されたフィルタリング基準の値を示すことができる。
次の［例示６］は、図７３に示すフィルタリング基準テーブルのＸＭＬスキーマを示す本発明の一実施例である。
［例示６］
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:choice maxOccurs="unbounded">
<xs:element name="IntegerTypeCriterion" type="IntegerCriterionOption"/>
<xs:element name="BooleanTypeCriterion" type="BooleanCriterionOpntion"/>
<xs:element name="SelectionTypeCriterion" type="StringCriterionOption"/>
<xs:element name="TextTypeCriterion" type="StringCriterionOption"/>
<xs:element name="AnyTypeCriterion" type="AnyTypeCriterionOption"/>
</xs:choice>
<xs:attribute name="time" type="xs:dateTime"/>
</xs:complexType>
<xs:complexType name="IntegerCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="minInteger" type="xs:integer"/
<xs:attribute name="maxInteger" type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BooleanCriterionOpntion">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" type="xs:boolean"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StringCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" default="EN-US"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnyTypeCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded"/>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="any" type="xs:anySimpleType"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:sequence>
</xs:sequence>
</xs:complexType></xs:schema>
図７４は、本発明の更に他の実施例に係るフィルタリング基準テーブルを示す図である。
具体的に、図７４は図７２及び図７３で説明したＸＭＬスキーマによるフィルタリング基準テーブルの一実施例を示す図である。図７４に示すフィルタリング基準テーブルの基本的な構成エレメントは、図７２及び図７３で上述したとおりである。以下、図７４に示すフィルタリング基準テーブルに含まれたエレメント及び属性のセマンティクスについて説明する。
図７４に示すように、本発明の一実施例に係るフィルタリング基準テーブルでは、属性の名称の前に“＠”を表示することによって、属性とエレメントとを区別することができる。
テーブルで＠ｉｄ属性が現れる各位置で、ＰＤＩテーブルで質問の＠ｉｄ属性があることにより、＠ｉｄ属性が現れるフィルタリング基準に該当する質問を識別する。
ＱＩＡ Ｃｒｉｔｅｒｉｏｎエレメントは、整数値を有する質問に該当するフィルタリング基準を示すだろう。
ＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントが＠ｅｘｔｅｎｔエレメントを含まないと、これは、フィルタリング基準に該当する質問に対する整数回答を示すだろう。ＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントが＠ｅｘｔｅｎｔ属性を含むと、これは、質問に対する回答の数値の範囲の下端を示すはずであり、＠ｅｘｔｅｎｔ属性はその範囲で整数の個数を示すだろう。
ＱＢＡ Ｃｒｉｔｅｒｉｏｎエレメントは、ブール値を有する質問に該当するフィルタリング基準を示すだろう。
ＱＢＡＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対するブール回答を示すだろう。
ＱＳＡ Ｃｒｉｔｅｒｉｏｎエレメントは、選択値を有する質問に該当するフィルタリング基準を示すだろう。
ＱＳＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対する選択回答の識別子を示すだろう。
ＱＴＡ Ｃｒｉｔｅｒｉｏｎエレメントは、ストリング値を有する質問に該当するフィルタリング基準を示すだろう。
ＱＴＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対するテキスト回答を示すだろう。
ＱＡＡ Ｃｒｉｔｅｒｉｏｎエレメントは、質問無しでテキスト“回答”だけを有する“質問”に該当するフィルタリング基準を示すだろう。
ＱＡＡＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する“質問”に対するテキスト“回答”を示すだろう。
Ｆｉｌｔｅｒｉｎｇ Ｃｒｉｔｅｒｉａエレメントに一つのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントのみがあれば、Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値が（質問がＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントを含むエレメントのｉｄ属性によって示される）Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントを含むエレメントに該当する質問に対するＰＤＩ−Ａにおける質問のうちの値と一致する場合、サービスやコンテンツアイテムがフィルタを通過するかに対するフィルタリング決定は、“真”（はい）となり、そうでない場合、“偽”（いいえ）となるだろう。
“ｅｘｔｅｎｔ”属性が存在するＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位要素の場合、質問の値がＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ及びｅｘｔｅｎｔ属性によって定義される区間にあると、Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値は、該当するＰＤＩ−Ａにおける回答のうちの値と一致すると見なされるだろう。
Ｆｉｌｔｅｒｉｎｇ ＣｒｉｔｅｒｉａエレメントでＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの総数が１よりも大きいと、各Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値は、（ｉｄ値で示したように）Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅがフィルタリング基準に該当する質問に対するＰＤＩ−Ａにおける回答のうちの値と一致する場合、“真”を返す中間用語として評価されるはずであり、そうでない場合、“偽”を返す中間用語として評価されるはずである。このような中間用語のうち、上位エレメント識別子（ＱＩＡ．ｉｄ、ＱＢＡ．ｉｄなど）の同一値を有する用語は、各ターゲット基準に対する中間結果を得るために論理和され、それらの中間結果は、最終結果を決定するために論理積されるはずである。最終結果が受信機に対して“真”と評価されると、これは、関連コンテンツアイテムがフィルタを通過したことを意味する。
図７５は、本発明の更に他の実施例に係るフィルタリング基準テーブルを示す図である。
具体的に、図７５に示すフィルタリング基準テーブルは、図７４に示すフィルタリング基準テーブルの拡張された構造を示す。図７５に示すフィルタリング基準テーブルの基本的な構成エレメントは、図７４で説明したとおりである。以下、図７４で説明したフィルタリング基準テーブルとの差異点を中心に、図７５に示すフィルタリング基準テーブルを説明する。
図７５に示すフィルタリング基準テーブルは、フィルタリング基準の集合の複数のインスタンスを許容する。それぞれの集合は、フィルタリング基準の複数のインスタンスを含む。それぞれのフィルタリング基準は、一部フィルタリング基準に対して提供される複数の値を許容する。フィルタリング論理は、フィルタリング基準の集合の複数インスタンスのうち“ＯＲ”論理である。フィルタリング基準の各集合内で、フィルタリング論理は、同一のフィルタリング基準に対する複数の値のうち“ＯＲ”論理であり、別個のフィルタリング基準の中では“ＡＮＤ”論理である。
例えば、フィルタリング基準が（（年齢（ａｇｅ）＝２０）及び（ジャンル（ｇｅｎｒｅ）＝“スポーツ（ｓｐｏｒｔ）”））であるか、（（年齢（ａｇｅ）＝１０）及び（ジャンル（ｇｅｎｒｅ）＝“アニメーション（ａｎｉｍａｔｉｏｎ）”））であれば、フィルタリング基準テーブルを次の［例示７］のように示すことができる。
［例示７］
<FilterCriteriaTable time="2012-09-03T09:30:47.0Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FilterCriterionSet>
<IntegerTypeCriterion id="abc.tv/age/">
<CriterionValue>20</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre/">
<CriterionValue>sport</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
<FilterCriterionSet>
<IntegerTypeCriterion id= "abc.tv/age/">
<CriterionValue>10</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre//">
<CriterionValue>animation</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
</FilterCriteriaTable>
図７６は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図７６は、本発明の一実施例に係る受信機が放送網を介してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
本発明の一実施例に係る個人化放送システムの基本的な構造は、図５８乃至図６１で説明したとおりである。本発明の一実施例に係るＰＤＩテーブルは、図６０乃至図７１で説明したとおりである。本発明の一実施例に係るフィルタリング基準テーブルは、図７２乃至図７５で説明したとおりである。
図７６に示すように、本発明の一実施例に係る個人化放送システムは、ＳＳＣ（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）２３００、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）セッション２３１０、フィルタリングエンジン２３２０、ＰＤＩエンジン２３３０、及び／又はＵＩ２３４０を含むことができる。本発明の一実施例に係る受信機は、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）セクションを通じてＰＤＩテーブルを受信することができる。この場合、本発明の一実施例に係る受信機は、ＦＬＵＴＥセッション２３１０を介してＰＤＩテーブルを受信することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図７６に示す各構成エレメントの動作について説明する。
本発明の一実施例に係る受信機は、まず、ＳＳＣ２３００を介してＰＤＩテーブルセクションを受信することができる。具体的に、本発明の一実施例に係る受信機は、ＤＳＭ−ＣＣセクションを通じて受信されるＩＰデータグラムのうち、ＳＳＣ２３００に該当するＩＰデータグラムをパースしてＰＤＩテーブルセクションを受信することができる。この場合、本発明の一実施例に係る受信機は、ＳＳＣ２３００が有する周知のＩＰアドレス及び／又はＵＤＰポートナンバーを用いてＰＤＩテーブルセクションを受信することができる。本発明の一実施例に係るＰＤＩテーブルセクションは、ＰＤＩテーブルを放送網を介して伝達するために、本発明の一実施例に係るＰＤＩテーブルを圧縮したテーブルを意味する。ＰＤＩテーブルセクションに関する具体的な内容は後述する。
本発明の一実施例に係る受信機は、ＳＳＣ２３００を介して受信したＰＤＩテーブルセクションをパースしてＰＤＩテーブルを取得することができる。その後、本発明の一実施例に係る受信機は、ＰＤＩエンジン２３３０にＰＤＩテーブルを伝達することができる。
本発明の一実施例に係るＰＤＩエンジン２３３０は、受信したＰＤＩテーブルを処理し、該当のＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン２３３０は、抽出されたＰＤＩ質問をＵＩ２３４０に伝達することができる。
本発明の一実施例に係るＵＩ２３４０は、受信したＰＤＩ質問をディスプレイし、該当のＰＤＩ質問に対するＰＤＩ回答を受信することができる。この場合、本発明の一実施例に係るＵＩ２３４０は、リモコンを介してＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン２３３０は、ＵＩ２３４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。具体的な内容は、図５８及び図５９で説明したとおりである。
また、本発明の一実施例に係る受信機は、ＳＳＣ２３００を介してＳＭＴ（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ）及び／又はＮＲＴ−ＩＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）を受信することができる。本発明の一実施例に係るＳＭＴは、個人化サービスのためのシグナリング情報を含むことができる。本発明の一実施例に係るＮＲＴ−ＩＴは、個人化サービスのためのアナウンス（ａｎｎｏｕｎｃｅｍｅｎｔ）情報を含むことができる。
その後、本発明の一実施例に係る受信機は、受信したＳＭＴ及び／又はＮＲＴ−ＩＴをパースしてフィルタリング基準記述子を取得することができる。受信機は、フィルタリング基準記述子を用いて、フィルタリングエンジン２３２０にフィルタリング基準を伝達することができる。この場合、本発明のフィルタリング基準は、ｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図７４及び図７５で具体的に説明した。
その後、本発明の一実施例に係るフィルタリングエンジン２３２０は、ＰＤＩエンジン２３３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン２３３０は、ＰＤＩデータ要求信号を受信すると、該当のＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン２３２０に伝達することができる。結果的に、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。本発明の一実施例に係るフィルタリングの以降の過程については図６０及び図６１で具体的に説明した。
図７７は、本発明の一実施例に係るＰＤＩテーブルセクションを示す図である。
具体的に、図７７は、図７６で説明したＰＤＩテーブルセクションの構文である。
ＰＤＩテーブルが放送ストリームで伝達されると、図７６に定義されたテーブルのＸＭＬ形式は、ＤＥＦＬＡＴＥ圧縮アルゴリズムを用いて圧縮される。得られた圧縮されたテーブルは、図７７のテーブルに示すように、ブロックに区分されてセクションに挿入されることによって、ＮＲＴスタイルの専用セクションに要約される。
結論的に、本発明の一実施例に係る受信機は、同一のシーケンスナンバーを有するセクション番号順にＰＤＩ−Ｑインスタンス文書のブロックを組み合わせて圧縮を解除することができる。本発明の一実施例に係る受信機は、圧縮を解除した結果としてＰＤＩ−Ｑインスタンス文書を生成することができる。その後、受信機は、ＰＤＩ−Ｑインスタンス文書を、本発明の一実施例に係るＰＤＩエンジンに伝達することができる。具体的な方法は、図７６で上述したとおりである。
以下、図７７に示すＰＤＩテーブルセクションの構文について説明する。
ブロックは、昇順のｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値のセクションに挿入されるだろう。“ＳＳＣ”及び“ＩＰサブネット”という用語は、ＡＴＳＣ ＮＲＴ標準で定義されるので、専用セクションは、ＰＤＩテーブルが関連した仮想チャネルのＩＰサブネットのＳＳＣで搬送される。当該セクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同一のＳＳＣで搬送される別個のＰＤＩテーブルインスタンスを区別するために用いられる。
８ビットのｔａｂｌｅ＿ｉｄフィールドは、当該テーブルセクションがＰＤＩテーブルインスタンスに属することを識別するために設定されるはずである。８ビットのｔａｂｌｅ＿ｉｄフィールドは、当該テーブルセクションがＰＤＩテーブルインスタンスに属することを識別するために設定されるだろう。ｔａｂｌｅ＿ｉｄフィールドは、図７７に示すＰＤＩテーブルセクションが本発明の一実施例に係るＰＤＩテーブルに関する情報を含んでいることを示すことができる。
本実施例に係るｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＰＤＩテーブルセクションのフォーマットを示すことができる。
本実施例に係るｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは、ユーザに対するビット情報を示すことができる。
本実施例に係るｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、ＰＤＩテーブルセクションでバイトの数を示すことができる。
本実施例に係るｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、ＰＤＩテーブルセクションを識別することができる。
本実施例に係るｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＰＤＩテーブル構文のプロトコルバージョンを含むことができる。
８ビットのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの値は、ＰＤＩ−Ｑインスタンスの他の全セクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと同一であり、ＳＳＣで搬送される他のＰＤＩ−Ｑインスタンスの全セクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと異なる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同時にＳＳＣで搬送されるＰＤＩ−Ｑの別個のインスタンスに属するセクションを区別するために用いられる。
５ビットのＰＤＩＱ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ｐｄｉＴａｂｌｅＩｄ値によって定義されるＰＤＩ−Ｑインスタンスのバージョンナンバーを示す。ＰＤＩ−Ｑインスタンスのあるエレメント又は属性が変化すると、バージョンナンバーは１ ｍｏｄｕｌｏ ３２ずつ増加する。
１ビットのｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、ＰＤＩ−Ｑセクションに対しては常に１に設定され、ＰＤＩ−Ｑが常にｓｅｇｍｅｎｔ＿ｉｄによって識別されるセグメントに対して現在ＰＤＩ−Ｑであることを示す。
８ビットのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、ＰＤＩ−Ｑインスタンスの当該セクションのセクションナンバーを提供する。ＰＤＩ−Ｑインスタンスの最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、０ｘ００に設定される。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、ＰＤＩ−Ｑインスタンスのそれぞれの追加セクションによって１ずつ増加する。
８ビットのｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該セクションが一部であるＰＤＩ−Ｑインスタンスの最後のセクション（すなわち、最高のｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのセクション）のナンバーを提供する。
１６ビットのｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該ＰＤＩ−Ｑインスタンスがある特定サービスではなくそれが現れる仮想チャネルにおける全データサービスに適用されるということを示すために、０ｘ００００に設定される。
可変長を有するｐｄｉｑ＿ｂｙｔｅｓ（）フィールドは、当該セクションによって部分的に伝達されるＰＤＩ−Ｑインスタンスのブロックで構成される。当該テーブルインスタンスの全セクションのｐｄｉｑ＿ｂｙｔｅｓ（）フィールドがそれらのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドの順で連結されると、結果は完全なＰＤＩ−Ｑインスタンスである。
図７８は、本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
具体的に、図７８は、図７６で説明したＰＤＩテーブルセクションの構文であり、基本的な内容は図７７で説明したとおりである。ただし、図７７に示すＰＤＩテーブルセクションとは違い、図７８に示すＰＤＩテーブルセクションは、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドを含んでいない。以下、図７８に示すＰＤＩテーブルセクションの構文について説明する。
本発明の一実施例に係るｎｕｍ＿ｑｕｅｓｔｉｏｎｓフィールドは、ＰＤＩテーブルに含まれたＰＤＩ質問の数を示すことができる。
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、一つのＰＤＩ質問のＩＤの長さを示すことができる。
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｉｄ＿ｖａｌｕｅフィールドは、一つのＰＤＩ質問のＩＤが有する値を示すことができる。
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｔｅｘｔ＿ｌｅｎｇｔｈフィールドは、ｑｕｅｓｔｉｏｎ＿ｔｅｘｔの長さを示すことができる。
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｔｅｘｔフィールドは、一つのＰＤＩ質問の実際内容を含むことができる。
本発明の一実施例に係るａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、ＰＤＩ質問に対するＰＤＩ回答のタイプを示すことができる。具体的に、本発明の一実施例に係るａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、下記の表３４に表現された回答タイプコードを含むことができる。下記の表３４に示すそれぞれの回答タイプコードは、図６２で説明したＰＤＩ回答のタイプを示すことができる。
Figure 0006189546
本発明の一実施例に係るｎｕｍ＿ａｎｓｗｅｒフィールドはＰＤＩ質問に対するＰＤＩ回答の数を示すことができる。
本発明の一実施例に係るａｎｓｗｅｒ＿ｖａｌｕｅ＿ｌｅｎｇｔｈフィールドは、ａｎｓｗｅｒ＿ｖａｌｕｅの実際の長さを示すことができる。
本発明の一実施例に係るａｎｓｗｅｒ＿ｖａｌｕｅフィールドは、ａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅで表現されるＰＤＩ回答の実際内容を含むことができる。
図７９は、本発明の更に他の実施例に係るＰＤＩテーブルセクションを示す図である。
具体的に、図７９は、図７６で説明したＰＤＩテーブルセクションの構文であり、基本的な内容は、図７７及び図７８で説明したとおりである。図７９の構文を構成するフィールドは、図７８の構文を構成するフィールドと同一なので、その具体的な説明は省略する。
図８０は、本発明の更に他の実施例に係るＰＤＩテーブルセクションを示す図である。
具体的に、図８０は、図７６で説明したＰＤＩテーブルセクションの構文であり、基本的な内容は、図７７及び図７８で説明したとおりである。図８０の構文を構成する基本的なフィールドは、図７８のシンタックス（ｓｙｎｔａｘ）を構成するフィールドと同一なので、その具体的な説明は省略する。
ただし、図７８の構文とは違い、図８０の構文は、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドをさらに含むことができる。本発明の一実施例に係るｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドに関する説明は、図７７で上述したとおりである。
図８１は、本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図７６で説明した個人化放送システム上のＦＬＵＴＥセッション、フィルタリングエンジン、及び／又はＰＤＩエンジンの動作に関する本発明の一実施例を示す図である。
図８１に示すように、本発明の一実施例に係る個人化放送システムは、ＦＬＵＴＥセッション２８００、フィルタリングエンジン２８１０、及び／又はＰＤＩエンジン２８２０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０サービス及び次世代放送サービスなどを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。
図７６で上述したように、本発明の一実施例に係る受信機は、ＦＬＵＴＥセッションを通じてＰＤＩテーブルを受信することができる。以下、図８１では、本発明の一実施例に係る受信機がＦＬＵＴＥセッションを通じてＰＤＩテーブルを受信する方法を説明する。
本発明の一実施例に係る受信機は、ＦＬＵＴＥセッション２８００を介してＦＤＴインスタンスを受信することができる。ＦＤＴ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ）インスタンスは、同じＦＬＵＴＥセッション２８００を介して伝送されるコンテンツの伝送単位を意味する。本発明の一実施例に係るＦＤＴインスタンスは、コンテンツのタイプを示すコンテンツタイプ属性を含むことができる。具体的に、本発明の一実施例に係るコンテンツタイプ属性は、ＦＬＵＴＥセッション２８００を介して伝送されるファイルがＰＤＩ−Ｑインスタンス文書（又は、ＰＤＩテーブル）であることを示す内容を含むことができる。本発明の一実施例に係るコンテンツタイプ属性に関する具体的な内容は後述する。
本発明の一実施例に係る受信機は、ＦＤＴインスタンスを用いて、ＦＬＵＴＥセッション２８００を介して伝送されるファイルがＰＤＩ−Ｑインスタンス文書であることを認知することができる。その後、本発明の一実施例に係る受信機は、ＰＤＩ−Ｑインスタンス文書をＰＤＩエンジン２８２０に伝達することができる。具体的な内容は、図２３で説明したとおりである。
図８２は、本発明の他の実施例に係るＦＤＴインスタンスのＸＭＬスキーマを示す図である。
具体的に、図２９は、図２８で説明したＦＤＴインスタンスのＸＭＬスキーマを示す図であり、以下、上述したコンテンツタイプ属性２９００について説明する。
図８２に示すように、本発明の一実施例に係るＦＤＴインスタンスは、ＦＤＴインスタンス自体の属性情報を示す属性２９００、及び／又はＦＬＵＴＥセッションを通じて伝送されるファイルを示すｆｉｌｅエレメント２９１０を含むことができる。図２９に示すｆｉｌｅエレメント２９１０は、ファイルに対する属性情報を示す属性を含むことができる。図２９に示すように、ｆｉｌｅエレメント２９１０は、本発明の実施例に係るｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０を含むことができる。
図８１で説明したように、本発明の実施例に係る受信機は、ｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０に含まれた値を用いてＰＤＩ−Ｑインスタンス文書を識別することができる。例えば、図８２に示すｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０は、“ａｐｐｌｉｃａｔｉｏｎ／ａｔｓｃ−ｐｄｉｑ”又は“ｔｅｘｔ／ａｔｓｃ−ｐｄｉｑ＋ｘｍｌ”で表現されるＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）プロトコル形態の値などを有することができる。
図８３は、本発明の一実施例に係るケイパビリティ記述子構文を示す図である。
具体的に、図８３は、図７６で説明した個人化放送システムにおいて、本発明の一実施例に係る受信機がＰＤＩテーブルを識別するための構文を示す。
本発明の一実施例に係るケイパビリティ記述子は、ＳＭＴサービスレベルにおけるサービス又はＮＲＴ−ＩＴコンテンツレベルにおけるコンテンツがＰＤＩテーブルであるか否かを示すために用いることができる。本発明の一実施例に係る受信機は、当該情報を用いてサービス／コンテンツがＰＤＩテーブルであるか否かを認知し、当該サービス／コンテンツがダウンロードされなければならないかを、ＰＤＩエンジンをサポートするなどのケイパビリティによって判断する。
下記の表３５に表現されたコードは、ＰＤＩテーブルシグナリングに対するケイパビリティ記述子でｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅに追加されてもよい。本発明の一実施例に係るｃａｐａｂｌｉｌｔｙ＿ｃｏｄｅ値は他の値に割り当てられてはならない。下記の表２に表示されたｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ値は、設計者の意図によって異なる値に設定されてもよい。
Figure 0006189546
図８４は、本発明の一実施例に係る消費モデルを示す図である。
具体的に、図８４は、図７６で説明した個人化放送システムにおいて、本発明の一実施例に係る受信機がＰＤＩテーブルを識別するために、ＳＭＴ上に追加されたフィールドを示す。
ＮＲＴサービス記述子は、ＮＲＴ ＳＭＴのサービスレベルに位置し、そのＮＲＴ＿ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙは、サービスがＰＤＩテーブルを提供すると、０ｘ０４（ＰＤＩ）になる。したがって、受信機は、フィールド値が０ｘ０４であれば、ＰＤＩテーブルが提供されることが分かる。
図８４に示す消費モデルの値は、設計者の意図によって異なる値に設定されてもよい。
図８５は、本発明の一実施例に係るフィルタリング基準記述子構文を示す図である。
具体的に、図８５は、図７６で説明した個人化放送システム上で、本発明の一実施例に係る受信機がフィルタリング基準テーブルを受信するためのフィルタリング基準記述子のビットストリーム構文を示す。
本発明の一実施例に係るフィルタリング基準は、本発明の一実施例に係る受信機がコンテンツをダウンロードするか否かを判断するようにダウンロード可能なコンテンツと関連する。ＡＴＳＣ２．０環境にはダウンロード可能なコンテンツに２つのカテゴリーがある。独立型のＮＲＴサービスにおけるＮＲＴコンテンツ及び付属双方向データサービスでＴＤＯによって用いられるＮＲＴコンテンツアイテムがそれに当たる。
以下、図８５では、独立型のＮＲＴサービスにおけるＮＲＴコンテンツをフィルタするためのフィルタリング基準について説明する。
本発明の一実施例に係るＮＲＴサービス及びコンテンツアイテムに対するフィルタリング基準において、以下に定義されたフィルタリング基準記述子の一つ以上のインスタンスは、受信機がユーザにＮＲＴサービスを提供するか否かを決定するようにするために、ＳＭＴでサービスレベル記述子ループに含まれてもよく、受信機が当該特定コンテンツアイテムをダウンロードしてユーザにとって使用可能にするか否かを決定するように、ＮＲＴ−ＩＴでコンテンツアイテムレベル記述子ループに含まれてもよい。
フィルタリング基準記述子の一つ以上のインスタンスは、複数の値が同一又は別個のターゲット基準に対して提供されるようにする。意図するターゲット論理は、同じターゲット基準に対して複数値の間で論理和であり、別個のターゲット基準の間で論理積である。
以下、図８５に示すフィルタリング基準記述子のビットストリーム構文の各フィールドのセマンティクス定義について説明する。
８ビットフィールドであるｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、記述子が本発明の一実施例に係るフィルタリング基準記述子であるということを示すために０ｘＴＢＤに設定されてもよい。
８ビット符号なし整数フィールドであるｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド自身に続くバイト数を示すことができる。
８ビットフィールドであるｎｕｍ＿ ｆｉｌｔｅｒ＿ｃｒｉｔｅｒｉａフィールドは、図８５に示した当該記述子に含まれたフィルタリング基準の数を示すことができる。
８ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、ｃｒｉｔｅｒｉｏｎ＿ｉｄフィールドの長さを示すことができる。
可変長フィールドであるｃｒｉｔｅｒｉｏｎ＿ｉｄフィールドは、当該記述子が現れる仮想チャネルのＰＤＩテーブルで質問（ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡエレメント）のｉｄ属性にマッチされるＵＲＩの形態で当該フィルタリング基準の識別子を提供することができる。
３ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、下記の表３６によって当該基準（質問）のタイプを提供することができる。
Figure 0006189546
５ビットフィールドであるｎｕｍ＿ｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅｓフィールドは、各値がｃｒｉｔｅｒｉｏｎ＿ｉｄによって識別される質問（ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡ）に対する可能な回答である当該フィルタリング基準に対するループでターゲット基準値の数を提供する。
８ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅ＿ｌｅｎｇｔｈフィールドは、当該ターゲット基準値を示す必要があるバイトの数を提供する。
可変長フィールドであるｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅフィールドは、当該ターゲット基準値を提供する。
本発明の一実施例に係るフィルタリング基準記述子は、サービスやコンテンツアイテムと関連した特定ターゲット基準に対する値を示す。ＡＴＳＣ２．０送出において、上記定義されたｆｉｌｔｅｒｉｎｇ＿ｃｒｉｔｅｒｉａ＿ｄｅｓｃｒｉｐｔｏｒ（）の一つ以上のインスタンスは、ＳＭＴでＮＲＴサービスの記述子ループ又はＮＲＴ−ＩＴでコンテンツアイテムの記述子ループに含まれてもよい。前者の場合、それらをサービス自体（全てのコンテンツアイテム）に適用することができる。後者の場合、それらを個別コンテンツアイテムに適用することができる。
記述子ループに一つのフィルタリング基準記述子だけがあり、それが一つの基準値だけを有すると、サービス又はコンテンツアイテムがフィルタを通過するか否かに対する決定は、当該基準値が（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって示したように）フィルタリング基準に該当する質問に対するＰＤＩ−Ａで質問のうちの値と一致する場合“真”（はい）になり、そうでない場合、“偽”（いいえ）になるはずである。
単一記述子ループの全フィルタリング基準記述子で、全基準値の数が１よりも大きいと、各基準値の結果は、基準値が（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって示したように）フィルタリング基準に該当する質問に対するＰＤＩ−Ａで回答のうちの値と一致すると“真”を返す中間用語として評価されるはずであり、そうでない場合、“偽”を返す中間用語として評価されるはずである。このような中間用語のうち、（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって決定されるように）フィルタリング基準の同一値を有するものは、各ターゲット基準に対する中間結果を得るために論理和され、それらの中間結果は、最終結果を決定するために論理積されるはずである。最終結果が受信機に対して“真”と評価されると、これは、関連したＮＲＴサービス又はコンテンツアイテムがフィルタを通過し、受信機にダウンロードされ得るということを意味する。
図８６は、本発明の他の実施例に係るフィルタリング基準記述子構文を示す図である。
具体的に、図８６は、図７６で説明した個人化放送システム上で、本発明の一実施例に係る受信機がフィルタリング基準テーブルを受信するためのフィルタリング基準記述子のビットストリーム構文を示す。
図８６に示すフィルタリング基準記述子構文の基本的な内容は、図８５で説明したとおりである。
しかし、ｃｒｉｔｅｒｉｏｎ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、下記の表３７によって当該基準（質問）のタイプを提供することができる。
Figure 0006189546
図８７は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図８７は、本発明の一実施例に係る受信機が放送網を介してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
本発明の一実施例に係る個人化放送システムの基本的な構造は、図５８乃至図６１で説明したとおりである。本発明の一実施例に係るＰＤＩテーブルは、図６０乃至図６９で説明したとおりである。本発明の一実施例に係るフィルタリング基準テーブルは、図７２乃至図７５で説明したとおりである。
図８７に示すように、本発明の一実施例に係る個人化放送システムは、シグナリングサーバー３４１０、フィルタリングエンジン３４２０、ＰＤＩエンジン３４３０、及び／又はＵＩ３４４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。
本発明の一実施例に係るＰＤＩテーブル及びフィルタリング基準を処理するためのフィルタリングエンジン３４２０、ＰＤＩエンジン３４３０、及び／又はＵＩ３４４０の動作は、図７６で説明したとおりである。以下、図８７に示すシグナリングサーバー３４１０の動作を中心に説明する。
本発明の一実施例に係る受信機は、まず、ＰＤＩテーブルセクションを受信するための要求信号をシグナリングサーバー３４１０に伝送することができる。この場合、本発明の一実施例に係る受信機は、クエリー用語を用いて要求信号を伝送することができる。クエリーに関する具体的な内容は後述する。
本発明の一実施例に係るシグナリングサーバー３４１０は、該当のクエリーによるＰＤＩテーブルセクションを受信機に伝送することができる。ＰＤＩテーブルセクションに関する具体的な内容は、図７７乃至図８０で説明したとおりである。
図８８は、本発明の一実施例に係るＨＴＴＰ要求テーブルを示す図である。
具体的に、図８８は、本発明の一実施例に係る受信機が図８７で説明したシグナリングサーバーにクエリーを伝送するためのＨＴＴＰプロトコルを示す。
放送局によってサポートされると、図８８に示したプロトコルは、２つのケイパビリティを提供することができる。第一に、圧縮されないオーディオ又はビデオだけを伝達する経路を通じてＤＴＶ放送信号を受ける装置に対して、当該プロトコルは一般的に放送局の独立型ＮＲＴサービスに接続する唯一の方法である。第二に、完全な放送ストリームに接続できる装置に対しても、当該プロトコルは、ローカル放送領域で使用可能な全ての放送ストリームを循環して、所望のテーブルが現れることを待たないでプログラム／サービスガイドを付加するデータを検索する方法を提供する。これはまた、別のチューナを必要とせず、視聴者がＴＶを視聴している間にもいつでもこのようなデータの検索を可能にする。
図８８に示すＨＴＴＰ要求テーブルは、受信しようとするテーブルの種類及び当該テーブルを受信するためのベースＵＲＬを示すクエリー用語を含むことができる。
本発明の一実施例に係る受信機は、図８８に示すＨＴＴＰ要求テーブルのクエリー用語を用いて特定テーブルを受信することができる。具体的に、本発明の一実施例に係る受信機は、“？ｔａｂｌｅ＝ＰＤＩＴ［＆ｃｈａｎ＝＜ｃｈａｎ＿ｉｄ＞］”というクエリー用語を用いてシグナリングサーバーに要求信号を送ることができる。具体的な内容は図８７で説明したとおりである。
図８９は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図８９は、本発明の一実施例に係る受信機がインターネット網を介してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
本発明の一実施例に係る個人化放送システムの基本的な構造は、図５８乃至図６１で説明したとおりである。本発明の一実施例に係るＰＤＩテーブルは、図６０乃至図７１で説明したとおりである。本発明の一実施例に係るフィルタリング基準テーブルは、図７２乃至図７５で説明したとおりである。
インターネットを介して伝達される時、ＰＤＩテーブルインスタンスはＨＴＴＰ又はＨＴＴＰＳを介して伝達されるはずである。ＨＴＴＰ応答ヘッダーでＰＤＩテーブルのコンテンツタイプは“ｔｅｘｔ／ｘｍｌ”になるだろう。
インターネットを介してＰＤＩテーブルを検索するために用いられるＵＲＬは、ＤＴＶ字幕放送チャネルで標準字幕サービス＃６で移動するＳＤＯＰｒｉｖａｔｅＤａｔａＵＲＩＳｔｒｉｎｇ命令語を通じて伝達されてもよく、ＴＰＴと共に伝達されるＵｒｌＬｉｓｔ ＸＭＬエレメントで伝達されてもよい。
ＴＰＴ（ＴＤＯパラメータテーブル）は、セグメントのＴＤＯに関するメタデータ及びそれらをターゲットとするイベントを含む。ＴＤＯという用語は、トリガリングされた双方向付加データサービスでトリガーによって開始されたＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）又はトリガーによって開始されたＤＯによって開始されたＤＯなどを反復して指定するために用いられる。トリガーは、シグナリングを識別し、双方向イベントの再生のタイミングを設定する機能を有するシグナリングエレメントである。
図８９に示すように、本発明の一実施例に係る個人化放送システムは、ＰＤＩサーバー３６００、コンテンツサーバー３６５０、及び／又は受信機を含むことができる。本発明の一実施例に係る受信機は、ＴＰＴ（ＴＤＯ Ｐａｒａｍｅｔｅｒｓ Ｔａｂｌｅ）クライアント３６１０、フィルタリングエンジン３６２０、ＰＤＩエンジン３６３０、及び／又はＵＩ３６４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図８９に示す各構成エレメントの動作について説明する。
本発明の一実施例に係るＴＰＴクライアント３６１０は、ＴＰＴ及び／又はＵＲＬリストテーブルを受信することができる。本発明の一実施例に係るＴＰＴは、セグメントのＴＤＯに関するメタデータ及びそれらをターゲットとするイベントを含む。本発明の一実施例に係るＴＰＴは、ＰＤＩテーブル及びフィルタリング基準テーブルに関する情報を含むことができる。本発明の一実施例に係るＵＲＬリストテーブルは、ＰＤＩサーバー３６００のＵＲＬ情報を含むことができる。ＴＰＴ及びＵＲＬリストテーブルに関する具体的な内容は後述する。
また、本発明の一実施例に係るＴＰＴクライアント３６１０は、ＵＲＬリストテーブルからＰＤＩサーバー３６００のＵＲＬ情報を取得することができる。ＴＰＴクライアント３６１０は、取得したＵＲＬ情報を用いてＰＤＩサーバー３６００にアクセスし、本発明の一実施例に係るＰＤＩテーブルの伝送を要求することができる。本発明の一実施例に係るＰＤＩサーバー３６００は、ＴＰＴクライアント３６１０の要求に応じて該当のＰＤＩテーブルをＴＰＴクライアント３６１０に伝送することができる。
図８９に示すように、本発明の一実施例に係るＴＰＴクライアント３６１０は、受信したＰＤＩテーブルをＰＤＩエンジン３６３０に伝達することができる。本発明の一実施例に係るＰＤＩエンジン３６３０は、受信したＰＤＩテーブルを処理し、該当のＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン３６３０は、抽出されたＰＤＩ質問をＵＩ３６４０に伝達することができる。
本発明の一実施例に係るＵＩ３６４０は、受信したＰＤＩ質問をディスプレイし、該当のＰＤＩ質問に対するＰＤＩ回答を受信することができる。本発明の一実施例に係るＵＩ３６４０は、リモコンを介してＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン３６３０は、ＵＩ３６４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。具体的な内容は、図５８及び図５９で説明したとおりである。
また、本発明の一実施例に係るＴＰＴクライアント３６１０は、ＴＰＴをパースしてフィルタリング基準を取得することができる。図８９に示すように、ＴＰＴクライアント３６１０は、フィルタリング基準をフィルタリングエンジン３６２０に伝達することができる。この場合、本発明のフィルタリング基準は、ｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図７４及び図７５で具体的に説明した。
その後、本発明の一実施例に係るフィルタリングエンジン３６２０は、ＰＤＩエンジン３６３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン３６３０は、ＰＤＩデータ要求信号を受信すると、該当のＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン３６２０に伝達することができる。本発明の一実施例に係るフィルタリング以降の過程については、図６０及び図６１で具体的に説明した。
結果的に、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。さらにいうと、ＴＰＴクライアント３６１０は、フィルタリング結果をフィルタリングエンジン３６２０から受信し、ＴＤＯ及び／又はコンテンツダウンロード要求信号をコンテンツサーバー３６５０に伝達することができる。コンテンツサーバー３６５０は、ＴＤＯ及び／又はコンテンツダウンロード要求信号によってＴＤＯ及び／又はコンテンツをＴＰＴクライアント３６１０に伝送することができる。
図９０は、本発明の一実施例に係るＵＲＬリストテーブルを示す図である。
具体的に、図９０は、本発明の一実施例に係る受信機がインターネット網を介してＰＤＩテーブル及び／又はフィルタリング基準を受信するためのＵＲＬ情報を含むテーブルである。本発明の一実施例に係るＵＲＬリストテーブルの送受信過程は、図３６で具体的に説明した。
ＵＲＬリストテーブルがインターネットを介して伝達されるとき、ＵＲＬリストテーブルを、マルチパート（ｍｕｌｔｉｐａｒｔ）ＭＩＭＥメッセージの形態でＴＰＴと共にＨＴＴＰを通じて伝達することができる。
インターネットを介して伝達されるとき、ＴＰＴは、ＨＴＴＰを通じて伝達されてもよい。現セグメントのＴＰＴに対するＵＲＬ情報は、ＤＴＶ字幕サービス＃６又は自動コンテンツ認識サーバーを介して伝達され、トリガーに現れてもよい。ＴＰＴに対する要求に対する応答は、現セグメントに対するＴＰＴだけで構成されてもよく、要求されたＴＰＴが１番目のパート、セグメントに対するＡＭＴが選択的に２番目のパート、ＵｒｌＬｉｓｔ ＸＭＬ文書が選択的にその次のパートである、マルチパートＭＩＭＥメッセージで構成されてもよい。
以下、本発明の一実施例に係るＵＲＬリストテーブルに含まれた各エレメントのセマンティクスについて説明する。
図９０に示したＵｒｌＬｉｓｔエレメントは、本発明の一実施例に係る受信機に有用なＵＲＬのリストを含む。
図９０に示したＵｒｌＬｉｓｔエレメントのＴｐｔＵｒｌエレメントは、現双方向付加サービスで将来セグメントに対するＴＰＴのＵＲＬ情報を含むことができる。複数のＴｐｔＵｒｌエレメントが含まれると、それらは放送においてセグメントの出現順で整列されるはずである。
図９０に示したＵｒｌＬｉｓｔエレメントのＮｒｔＳｉｇｎａｌｉｎｇＵｒｌエレメントは、受信機が当該標準のセクション１８に定義された要求プロトコルを用いて現伝送ストリームで全仮想チャネルに対するＮＲＴシグナリングテーブルを取得できるサーバーのＵＲＬ情報を含むことができる。
図９０に示したＵｒｌＬｉｓｔエレメントのＵｒｓＵｒｌエレメントは、受信機が当該標準のセクション１０に定義されたプロトコルを用いて使用（視聴率調査）レポートを伝送できるサーバーのＵＲＬ情報を含むことができる。
図９０に示したＵｒｌＬｉｓｔエレメントのＰｄｉＵｒｌエレメントは、ＰＤＩＴａｂｌｅのＵＲＬ情報を含むことができる。すなわち、本発明の一実施例に係るＰｄｉＵｒｌエレメントは、ＰＤＩテーブル及び／又はフィルタリング基準を伝送できるサーバーのＵＲＬ情報を示すことができる。
上述した図９０のＵＲＬリストテーブルは、下記の表３８のようなフォーマットで構成することができる。
Figure 0006189546
図９１は、本発明の一実施例に係るＴＰＴを示す図である。
具体的に、図９１に示すＴＰＴは、ＰＤＩテーブル及び／又はフィルタリング基準のＵＲＬ情報を含むことができる。本発明の一実施例に係るＴＰＴの送受信過程は、図８９で具体的に説明した。以下、ＴＰＴに含まれたフィルタリング基準に関するエレメントを説明する。
具体的に、図９１に示すＦｉｌｔｅｒ Ｃｒｉｔｅｒｉｏｎエレメントは、フィルタリング基準に関する情報を含むことができる。
本発明の一実施例に係るｉｄ属性は、当該のフィルタリング基準に関するＰＤＩ質問を示すことができる。
本発明の一実施例に係るｃｒｉｔｅｒｉｏｎ ｔｙｐｅ属性は、フィルタリング基準タイプ（又は、フィルタリング基準タイプエレメント）を示すことができる。本発明の一実施例に係るフィルタリング基準のタイプに関しては図７３で具体的に説明した。
本発明の一実施例に係るｃｒｉｔｅｒｉｏｎ ｖａｌｕｅ属性は、上述した基準タイプ属性によるフィルタリング基準の値を示すことができる。
図９２は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図９２は、本発明の一実施例に係る受信機が自動コンテンツ認識システム上でＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムを示す図である。
本発明の一実施例に係る自動コンテンツ認識システムは、図５２で説明したとおりである。本発明の一実施例に係る個人化放送システムの基本的な構造は、図５８乃至図６１で説明したとおりである。本発明の一実施例に係るＰＤＩテーブルは、図６１乃至図７１で説明したとおりである。本発明の一実施例に係るフィルタリング基準テーブルは、図７２乃至図７５で説明したとおりである。
図９２に示すように、本発明の一実施例に係る個人化放送システムは、自動コンテンツ認識サーバー３９００、ＴＰＴサーバー３９５０、ＰＤＩサーバー３９６０、コンテンツサーバー３９７０、自動コンテンツ認識クライアント３９１０、フィルタリングエンジン３９２０、ＰＤＩエンジン３９３０、及び／又はＵＩ３９４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図９２に示す各構成エレメントの動作について説明する。
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、フィンガープリントからシグネチャを抽出し、シグネチャと共に要求を自動コンテンツ認識サーバー３９００伝送することができる。本発明の一実施例に係る自動コンテンツ認識サーバー３９００は、シグネチャを受信し、当該シグネチャと関連したトリガーなどと共に応答を自動コンテンツ認識クライアント３９１０に伝送することができる。上述した内容は、図５２乃至図５７で具体的に説明した。
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、受信したトリガーなどを用いて、ＴＰＴサーバー３９５０にＴＰＴ及び／又はＵＲＬリストテーブルを要求することができる。本発明の一実施例に係るＴＰＴサーバー３９５０は、自動コンテンツ認識クライアント３９１０の要求に応じて、自動コンテンツ認識クライアント３９１０にＴＰＴ及び／又はＵＲＬリストテーブルを伝送することができる。ＴＰＴ及び／又はＵＲＬリストテーブルに関する具体的な内容は、上述したとおりである。その後、本発明の一実施例に係るＴＰＴサーバー３９５０は、受信したＴＰＴ及び／又はＵＲＬリストテーブルを自動コンテンツ認識クライアント３９１０に伝達することができる。
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、ＵＲＬリストテーブルからＰＤＩサーバー３９６０のＵＲＬ情報を取得することができる。自動コンテンツ認識クライアント３９１０は、取得したＵＲＬ情報を用いてＰＤＩサーバー３９６０にアクセスし、本発明の一実施例に係るＰＤＩテーブルの伝送を要求することができる。本発明の一実施例に係るＰＤＩサーバー３９６０は、自動コンテンツ認識クライアント３９１０の要求に応じて、該当のＰＤＩテーブルを自動コンテンツ認識クライアント３９１０に伝送することができる。
図９２に示すように、本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は受信したＰＤＩテーブルをＰＤＩエンジン３９３０に伝達することができる。本発明の一実施例に係るＰＤＩエンジン３９３０は、受信したＰＤＩテーブルを処理し、該当のＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン３９３０は、抽出されたＰＤＩ質問をＵＩ３９４０に伝達することができる。
本発明の一実施例に係るＵＩ３９４０は、受信したＰＤＩ質問をディスプレイし、該当のＰＤＩ質問に対するＰＤＩ回答を受信することができる。本発明の一実施例に係るＵＩ３９４０は、リモコンを介してＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン３９３０は、ＵＩ３９４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。具体的な内容は、図５８及び図５９で説明したとおりである。
また、本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、ＴＰＴをパースしてフィルタリング基準を取得することができる。図９２に示すように、自動コンテンツ認識クライアント３９１０は、フィルタリング基準をフィルタリングエンジン３９２０に伝達することができる。この場合、本発明のフィルタリング基準はｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図７４及び図７５で具体的に説明した。
その後、本発明の一実施例に係るフィルタリングエンジン３９２０は、ＰＤＩエンジン３９３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン３９３０は、ＰＤＩデータ要求信号を受信すると、該当のＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン３９２０に伝達することができる。本発明の一実施例に係るフィルタリング以降の過程については、図６０及び図６１で具体的に説明した。
結果的に、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。具体的に、自動コンテンツ認識クライアント３９１０は、フィルタリング結果をフィルタリングエンジン３９２０から受信し、ＴＤＯ及び／又はコンテンツダウンロード要求信号をコンテンツサーバー３９７０に伝達することができる。コンテンツサーバー３９７０は、ＴＤＯ及び／又はコンテンツダウンロード要求信号によって、ＴＤＯ及び／又はコンテンツを自動コンテンツ認識クライアント３９１０に伝送することができる。
図９３は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図９３は、ＰＤＩ回答の重複防止のための個人化放送システムの一実施例を示す図である。
より詳細に、図９３は、本発明の一実施例に係る受信機が複数の放送局及びコンテンツプロバイダから同一のＰＤＩ質問を受信する場合、既に保存されたＰＤＩ回答を用いてＰＤＩデータを更新できる個人化放送システムを示す。図９３に示す個人化放送システムによれば、ユーザは同一のＰＤＩ質問に対して重複してＰＤＩ回答を入力するという面倒さを減らすことができる。
図９３に示すように、本発明の一実施例に係る個人化放送システムは、２つ以上の放送局（又は、コンテンツプロバイダ）及び／又は受信機を含むことができる。本発明の一実施例に係る２つ以上の放送局は、放送局Ａ４０１０及び／又は放送局Ｂ４０２０を含むことができる。本発明の一実施例に係る受信機は、ＰＤＩエンジン４０３０及び／又はＵＩ４０４０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０サービスを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図９３に示す各構成エレメントの動作を説明する。
まず、本発明の一実施例に係る受信機は、放送局Ａ４０１０から第１ＰＤＩテーブル４０１１を受信することができる。第１ＰＤＩテーブル４０１１を受信した受信機は、ＰＤＩエンジン４０３０に第１ＰＤＩテーブル４０１１を伝達することができる。本発明の一実施例に係る第１ＰＤＩテーブル４０１１は、第１ＰＤＩタイプエレメント４０１２を含むことができる。本発明の一実施例に係る第１ＰＤＩタイプエレメント４０１２のそれぞれは、図６８乃至図７１で上述したように、第１識別子エレメント（又は、第１ＩＤ）及び／又は第１ＰＤＩ質問を含むことができる。また、図９３に示すように、第１ＰＤＩテーブル４０１１は、別個の第１ＩＤを有する２つ以上の第１ＰＤＩタイプエレメント４０１２を含むことができる。
本発明の一実施例に係るＰＤＩエンジン４０３０は、第１ＰＤＩタイプエレメント４０１２から第１ＰＤＩ質問を抽出し、抽出した第１ＰＤＩ質問をＵＩ４０４０に伝達することができる。その後、本発明の一実施例に係るＵＩ４０４０は、ユーザから第１ＰＤＩ質問に対する第１ＰＤＩ回答を受信することができる。ＰＤＩエンジン４０３０は、第１ＰＤＩ回答を第１ＰＤＩタイプエレメント４０１２に追加及び／又は修正することができる。本発明の一実施例に係るＰＤＩエンジン４０３０及びＵＩ４０４０の具体的な動作は、図７６で説明したとおりである。
また、本発明の一実施例に係るＰＤＩエンジン４０３０は、放送局Ｂ４０２０から第２ＰＤＩテーブル４０２１を受信することができる。本発明の一実施例に係る第２ＰＤＩテーブル４０２１は、第２ＰＤＩタイプエレメント４０２２を含むことができる。図６８乃至図７１で上述したように、第２ＰＤＩタイプエレメント４０２２は、第２識別子エレメント（又は、第２ＩＤ）及び／又は第２ＰＤＩ質問を含むことができる。
第２ＰＤＩテーブルを受信したＰＤＩエンジン４０３０はＰＤＩストアにアクセスし、既に保存された第１ＰＤＩテーブルを探索することができる。その後、本発明の一実施例に係るＰＤＩエンジン４０３０は、第２ＩＤと第１ＩＤとを比較することができる。比較の結果、第２ＩＤと第１ＩＤとが一致すると、第１ＰＤＩ回答を第２ＰＤＩタイプエレメント４０２２に追加及び／又は修正することができる。
結論的に、本発明の一実施例に係る受信機は、既に保存されたＰＤＩ質問と同じＰＤＩ質問を受信する場合、ＰＤＩ質問を重複してディスプレイしないで、既に保存されたＰＤＩ回答を用いて処理することができる。したがって、本発明の一実施例に係る個人化放送システム上で、ユーザは、同じＰＤＩ質問に対して同じ内容のＰＤＩ回答を重複して入力する必要がなく、よって、ユーザはより便利に個人化サービスの提供を受けることができる。
図９４は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図９４は、ＰＤＩ回答の重複防止のための個人化放送システムの一実施例を示す図である。図９４で説明した個人化放送システムは、ＰＤＩ回答の重複防止のために、本発明の一実施例に係る受信機に既に保存されているＰＤＩテーブルを用いることができる。ＰＤＩ回答の重複防止のための実施例として、図９４ではＰＤＩ質問登録を用いた個人化放送システムを提示する。
消費者が本質的に同じ質問に対して反復して答えることを引き起こさないように別個の放送局で質問を再使用することをサポートするために、質問を、ＡＴＳＣによって指定されるレジストラ（ｒｅｇｉｓｔｒａｒ）に登録することができる。各登録記録は、図６８乃至７１に明示されたように、グローバルに一意の質問ＩＤに関する情報、質問タイプ（ＱＩＡ、ＱＢＡ、ＱＳＡ、又はＱＴＡ）、一つ以上の言語からなる質問テキスト、登録日、及び／又は登録のために質問を提出した団体に対する連絡先の情報を含むことができる。また、ＱＳＡの場合、各登録記録（又は、先登録ＰＤＩ質問）は、各選択の識別子のような許容される選択、及び一つ以上の言語からなる各選択のテキストを含むことができる。
ＰＤＩテーブルは、登録された質問及び登録されていない質問の混合を含むことができる。
登録された質問及び登録されていない質問はいずれも複数のＰＤＩテーブルに現れてもよい。ユーザが複数のＰＤＩテーブルに現れた質問に答える度に、受信機が提供する機能によるか、又はアプリケーションが提供する機能によるかにかかわらず、回答はそれが現れる全質問表にある質問の全ての場合に伝搬されると予想される。したがって、ユーザは、それが異なる質問表に何回現れるかにかかわらず、与えられた質問に一度だけ回答すればいい。
ユーザに質問が殺到することを防止するために、質問表生成者は可能な限り、登録された質問を使用し、登録された質問が得られない特別なターゲット要求がある時にのみ、登録されていない質問を使用するように推奨される。
本発明の一実施例に係る受信機は、受信機ターゲット基準を用いて先登録ＰＤＩ質問を抽出することができる。本発明の一実施例に係る受信機ターゲット基準は、ＡＴＳＣ ＮＲＴ標準であるＡ／１０３に従う。
図９４に示すように、本発明の一実施例に係る個人化放送システムは、ＳＳＣ４１００、ＦＬＵＴＥセッション４１１０、フィルタリングエンジン４１２０、ＰＤＩエンジン４１３０及び／又はＵＩ４１４０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０サービスを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図９４に示す個人化放送システムについて説明する。
本発明の一実施例に係る受信機は、ＳＳＣ４１００を介してＳＭＴ及び／又はＮＲＴ−ＩＴを受信し、ＳＭＴ及び／又はＮＲＴ−ＩＴに含まれた受信機ターゲット基準を取得することができる。本発明の受信機ターゲット基準は、受信機ターゲット記述子又は受信機ターゲット基準テーブルを一実施例とすることができる。
その後、本発明の一実施例に係るＰＤＩエンジン４１３０は、取得した受信機ターゲット基準を変換してＰＤＩ質問を生成することができる。本発明の一実施例に係るＵＩ４１４０は、ＰＤＩエンジン４１３０から上述したＰＤＩ質問を受け取ってディスプレイし、ユーザのＰＤＩ回答を受信することができる。本発明の一実施例に係るＰＤＩエンジン４１３０及びＵＩ４１４０の具体的な動作は、図７６で説明したとおりである。
図９５は、本発明の更に他の実施例に係るデジタル放送システムのフローチャートを示す図である。
具体的に、図９５は、ＰＤＩ質問登録を用いた個人化放送システムを示す。
図９５に示すように、本発明の一実施例に係る個人化放送システムは、シグナリングサーバー４２００、受信機４２１０、フィルタリングエンジン４２２０、ＰＤＩエンジン４２３０、及びＵＩ４２４０を含むことができる。受信機４２１０は、フィルタリングエンジン４２２０、ＰＤＩエンジン４２３０、及び／又はＵＩ４２４０を含む概念として用いることができ、これは、設計者の意図によって変更可能である。また、本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ２．０サービスを提供することができる。以下、図９４に示す個人化放送システムについて説明する。
基本的な構成エレメントの動作は、図９４で説明したとおりである。ただし、図９５に示す受信機４２１０は、シグナリングサーバー４２００にＳＭＴ及び／又はＮＲＴ−ＩＴを要求することができる。本発明の一実施例に係る受信機４２１０の要求に応じて、シグナリングサーバー４２００は、該当のＳＭＴ及び／又はＮＲＴ−ＩＴを受信機４２１０に伝送することができる。
本発明の一実施例に係る受信機がＳＭＴ及び／又はＮＲＴ−ＩＴを受信した後の、受信機４２１０、ＰＤＩエンジン４２３０、及び／又はＵＩ４２４０の具体的な動作は、図９４で説明したとおりである。
図９６は、本発明の一実施例に係る受信機ターゲット基準テーブルを示す図である。
具体的に、図９６は、図９４及び図９５で説明した受信機ターゲット基準をテーブル形式で表現した図である。
図９６に示すように、受信機ターゲット基準テーブルは、ターゲット基準タイプコード（ｔａｒｇｅｔｉｎｇ ｃｒｉｔｅｒｉｏｎ ｔｙｐｅ ｃｏｄｅ）、ターゲット値の長さ（ｔａｒｇｅｔｉｎｇ ｖａｌｕｅ ｌｅｎｇｔｈ）及び／又はターゲット値（ｔａｒｇｅｔｉｎｇ ｖａｌｕｅ）に関する情報を含むことができる。図９６に示すターゲット基準タイプコードは、それぞれのターゲット基準を識別するためのコードを意味する。図９６に示すターゲット値の長さは、ターゲット基準値を示すためのバイト数を意味する。図９６に示すターゲット値は、ターゲット基準が示す情報を意味する。
本発明の一実施例に係る受信機は、ターゲット基準タイプコードによってターゲット基準を変換して先登録ＰＤＩ質問を取得することができる。
具体的に、本発明の一実施例に係るターゲット基準タイプコードが０ｘ００である場合、ターゲット値はリザーブされ、ターゲット値の長さは決定されない。
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０１である場合、ターゲット値は、下位３バイトだけを用いるＡ／６５の表６．２１に定義された地理的位置であり、ターゲット値の長さは、３バイトである。上述したＡ／６５は、ＰＳＩＰ（Ｐｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に関するＡＴＳＣ標準である。その詳細な内容は後述する。
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０２である場合、ターゲット値は、当該領域に適切なバイト数（８まで）を用いるＡ／６５のセクション６．７．２に定義されたような文字及び数字で書いた郵便番号であり、ターゲット値の長さは、可変的である。その詳細な内容は後述する。
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０３である場合、ターゲット値は、下位２バイトだけを用いるＡ／６５の表６．１８に定義されたような人口統計学的カテゴリーであり、ターゲット値の長さは、２バイトである。その詳細な内容は後述する。
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０４−０ｘ０Ｆである場合、ターゲット値は、将来ＡＴＳＣ使用のためにリザーブされ、ターゲット値の長さは定められない。
本発明の一実施例に係るターゲット基準タイプコードが０ｘ１０−０ｘ１Ｆである場合、ターゲット値は私的使用が可能であり、ターゲット値の長さは定められない。
図９７乃至図１００は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
具体的に、図９７乃至図１００は、図９６で上述したターゲット基準タイプコードが０ｘ０１である場合であり、本発明の一実施例に係る先登録ＰＤＩ質問を示すテーブルである。
図９７乃至図１００に示すように、ターゲット基準タイプコードが０ｘ０１である場合、本発明の一実施例に係るターゲット基準テーブルは、地理的位置に関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、下位３バイトだけを用いてターゲット基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。
図９７は、ターゲット基準タイプコードが０ｘ０１である場合であり、位置コード（ｌｏｃａｔｉｏｎ ｃｏｄｅ）に関する先登録ＰＤＩ質問を示すテーブルである。図９７に示す先登録ＰＤＩ質問テーブルに含まれた先登録ＰＤＩ質問情報は、図９４で説明したとおりである。
具体的に、図９７に示すように、ターゲット基準タイプコードが０ｘ０１である場合、本発明の一実施例に係る質問ＩＤは、位置コードに関する情報を含むことができる。また、図９７に示す先登録ＰＤＩ質問はＱＴＡタイプであり、位置コードに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示８］は、図９７に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示８］
<a20:QTA id="atsc.org/PDIQ/location-code">
<a20:Q xml:lang="en-us">
<a20:Text>What is your location code?</a20:Text>
</a20:Q>
</a20:QTA>
図９８は、ターゲット基準タイプコードが０ｘ０１である場合であり、ＦＩＰＳ（Ｆｅｄｅｒａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｓｔａｎｄａｒｄｓ Ｐｕｂｌｉｃａｔｉｏｎ） ｓｔａｔｅに関する先登録ＰＤＩ質問を示すテーブルである。図９８に示す先登録ＰＤＩ質問が含む基本的な内容は、図９４で説明したとおりである。ただし、図９５に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
具体的に、図９８に示すように、ターゲット基準タイプコードが０ｘ０１である場合、本発明の一実施例に係る質問ＩＤは、ＦＩＰＳ ｓｔａｔｅに関する情報を含むことができる。また、図９８に示す先登録ＰＤＩ質問はＱＴＡタイプであり、ＦＩＰＳ ｓｔａｔｅに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示９］は、図９８に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示９］
<a20:QTA id="atsc.org/PDIQ/state" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What state are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
図９９は、ターゲット基準タイプコードが０ｘ０１である場合であり、ＦＩＰＳ ｃｏｕｎｔｒｙに関する先登録ＰＤＩ質問を示すテーブルである。図９９に示す先登録ＰＤＩ質問が含む基本的な内容は、図９４で説明したとおりである。ただし、図９９に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
具体的に、図９９に示すように、ターゲット基準タイプコードが０ｘ０１である場合、本発明の一実施例に係る質問ＩＤは、ＦＩＰＳ ｃｏｕｎｔｒｙに関する情報を含むことができる。また、図９９に示す先登録ＰＤＩ質問は、ＱＴＡタイプとして、ＦＩＰＳ ｃｏｕｎｔｒｙに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示１０］は、図９９に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１０］
<a20:QTA id="atsc.org/PDIQ/county" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What county are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
図１００は、ターゲット基準タイプコードが０ｘ０１である場合であり、自治州細分（ｃｏｕｎｔｙ ｓｕｂｄｉｖｉｓｉｏｎ）に関する先登録ＰＤＩ質問を示すテーブルである。図１００に示す先登録ＰＤＩ質問が含む基本的な内容は、図９４で説明したとおりである。ただし、図１００に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
具体的に、図１００に示すように、ターゲット基準タイプコードが０ｘ０１である場合、本発明の一実施例に係る質問ＩＤは、自治州細分に関するセクター情報を含むことができる。また、図１００に示す先登録ＰＤＩ質問はＱＳＡタイプであり、自治州細分に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
また、本発明の一実施例に係るＱＳＡタイプの先登録ＰＤＩ質問は、ＰＤＩ回答に対する選択肢（ｓｅｌｅｃｔｉｏｎ）情報を含むことができる。例えば、図１００に示す自治州細分に関する先登録ＰＤＩ質問は、北西、北中、北東、西中、中央、東中、南西、南中、及び南東に関する９つの選択情報を含むことができる。
次の［例示１１］は、テーブルをＸＭＬスキーマで示した一実施例である。
［例示１１］
<a20:QSA id="atsc.org/PDIQ/sector" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What part of your county are you located in?
</a20:Text>
<a20:Selection id="1">NW</a20:Selection>
<a20:Selection id="2">NC</a20:Selection>
<a20:Selection id="3">NE</a20:Selection>
<a20:Selection id="4">WC</a20:Selection>
<a20:Selection id="5">C</a20:Selection>
<a20:Selection id="6">EC</a20:Selection>
<a20:Selection id="7">SW</a20:Selection>
<a20:Selection id="8">SC</a20:Selection>
<a20:Selection id="9">SE</a20:Selection>
</a20:Q>
</a20:QTA>
上述した、図９８乃至図１００に示すｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄは、類似の内容を含むＰＤＩ質問の集合を示すことができる。本発明の一実施例に係る受信機は、同一のｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄを含む先登録ＰＤＩ質問を組み合わせて個人化放送サービスに用いることができる。
例えば、図９７に示す受信機ターゲット基準は、同一のｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄを有する図９８乃至図１００の受信機ターゲット基準と表現されてもよい。本発明の一実施例に係る受信機は、図９７に示す受信機ターゲット基準及び／又は図９８乃至図１００の受信機ターゲット基準を組み合わせた結果を用いて個人化放送サービスを提供することができる。
図１０１及び図１０２は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
具体的に、図１０１及び図１０２は、図９６で上述したターゲット基準タイプコードが０ｘ０２である場合、先登録ＰＤＩ質問を示すテーブルである。
図１０１及び図１０２に示すように、ターゲット基準タイプコードが０ｘ０２である場合、本発明の一実施例に係るターゲット基準テーブルは、文字及び数字で書いた郵便番号に関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、領域による適切な数のバイトを用いて目標基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。本発明の一実施例に係る受信機は、目標基準テーブル変換のために最大８バイトを用いることができる。
図１０１は、ターゲット基準タイプコードが０ｘ０２である場合であり、五桁の郵便番号に関する先登録ＰＤＩ質問を示すテーブルである。五桁の郵便番号とは、米国で使用する文字及び数字で書いた郵便番号を意味する。図１０１に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。
具体的に、図１０１に示すように、ターゲット基準タイプコードが０ｘ０２である場合、本発明の一実施例に係る質問ＩＤは、郵便番号に関する情報を含むことができる。また、図１０１に示す先登録ＰＤＩ質問はＱＴＡタイプであり、郵便番号に対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示１２］は、図１０１に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１２］
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
図１０２は、ターゲット基準タイプコードが０ｘ０２である場合であり、数字で表した郵便番号に関する先登録ＰＤＩ質問を示すテーブルである。数字で表した郵便番号は、米国以外の地域で使用する文字及び数字で書いた郵便番号を意味する。図１０２に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。
具体的に、図１０２に示すように、ターゲット基準タイプコードが０ｘ０２である場合、本発明の一実施例に係る質問ＩＤは、郵便番号に関する情報を含むことができる。また、図１０２に示す先登録ＰＤＩ質問はＱＴＡタイプであり、郵便番号に対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示１３］は、図１０２に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１３］
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
図１０３乃至図１０６は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
具体的に、図１０３乃至図１０６は、図９６で上述したターゲット基準タイプコードが０ｘ０３である場合であり、本発明の一実施例に係る先登録ＰＤＩ質問を示すテーブルである。
図１０３乃至図１０６に示すように、ターゲット基準タイプコードが０ｘ０３である場合、本発明の一実施例に係るターゲット基準テーブルは、ユーザの人口統計カテゴリーに関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、下位２バイトだけを用いてターゲット基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。
図１０３は、ターゲット基準タイプコードが０ｘ０３である場合であり、ユーザの性別に関する先登録ＰＤＩ質問を示すテーブルである。図１０３に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。
具体的に、図１０３に示すように、ターゲット基準タイプコードが０ｘ０３である場合、本発明の一実施例に係る質問ＩＤは、性別に関する情報を含むことができる。また、図１０３に示す先登録ＰＤＩ質問はＱＳＡタイプであり、ユーザの性別に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
また、図１０３に示す先登録ＰＤＩ質問はＱＳＡタイプであり、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図１０３に示す性別に関する先登録ＰＤＩ質問は、男性及び女性に関する２つの選択情報を含むことができる。
次の［例示１４］は、図１０３に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１４］
<a20:QSA id="atsc.org/PDIQ/gender" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>What is your gender?</a20:Text>
<a20:Selection id="1">Male</a20:Selection>
<a20:Selection id="2">Female</a20:Selection>
</a20:Q>
</a20:QSA>
図１０４は、ターゲット基準タイプコードが０ｘ０３である場合であり、ユーザの年齢帯（ａｇｅ ｂｒａｃｋｅｔ）に関する先登録ＰＤＩ質問を示すテーブルである。
図１０４に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。具体的に、図１０４に示すように、ターゲット基準タイプコードが０ｘ０３である場合、本発明の一実施例に係る質問ＩＤは、年齢帯に関する情報を含むことができる。また、図１０４に示す先登録ＰＤＩ質問はＱＳＡタイプであり、年齢帯に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
また、図１０４に示す先登録ＰＤＩ質問はＱＳＡタイプであるので、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図１０４に示す年齢帯に関する先登録ＰＤＩ質問は、２−５歳、６−１１歳、１２−１７歳、１８−３４歳、３５−４９歳、５０−５４歳、５５−６４歳、６５歳以上に関する８つの選択情報を含むことができる。
次の［例示１５］は、図１０４に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１５］
<a20:QSA id="atsc.org/PDIQ/age-bracket" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text> What age bracket are you in</a20:Text>
<a20:Selection id="1">Ages 2-5</a20:Selection>
<a20:Selection id="2">Ages 6-11</a20:Selection>
<a20:Selection id="3">Ages 12-17</a20:Selection>
<a20:Selection id="4">Ages 18-34</a20:Selection>
<a20:Selection id="5">Ages 35-49</a20:Selection>
<a20:Selection id="6">Ages 50-54</a20:Selection>
<a20:Selection id="7">Ages 55-64</a20:Selection>
<a20:Selection id="8">Ages 65+</a20:Selection>
</a20:Q>
</a20:QSA>
図１０５は、ターゲット基準タイプコードが０ｘ０３である場合であり、ユーザの勤労有無に関する先登録ＰＤＩ質問を示すテーブルである。図１０５に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。
具体的に、図１０５に示すように、ターゲット基準タイプコードが０ｘ０３である場合、本発明の一実施例に係る質問ＩＤは、勤労に関する情報を含むことができる。また、図１０５に示す先登録ＰＤＩ質問はＱＳＡタイプであり、ユーザの勤労有無に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
また、図１０５に示す先登録ＰＤＩ質問はＱＳＡタイプであるので、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図１０３に示す勤労に関する先登録ＰＤＩ質問は、はい及びいいえに関する２つの選択情報を含むことができる。
次の［例示１６］は、図１０５に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１６］
<a20:QSA id="atsc.org/PDIQ/working" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Text>
<a20:Selection id="1">Yes</a20:Selection>
<a20:Selection id="2">No</a20:Selection>
</a20:Q>
</a20:QSA>
図１０６は、ターゲット基準タイプコードが０ｘ０３である場合であり、ユーザの性別に関する先登録ＰＤＩ質問を示すテーブルである。図１０６に示す先登録ＰＤＩ質問が含む内容は、図９４で説明したとおりである。
具体的に、図１０６に示すように、ターゲット基準タイプコードが０ｘ０３である場合、本発明の一実施例に係る質問ＩＤは、勤労に関する情報を含むことができる。また、図１０６に示す先登録ＰＤＩ質問はＱＢＡタイプであり、ユーザの勤労有無に関するブールタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
次の［例示１７］は、図１０６に示したテーブルをＸＭＬスキーマで示す一実施例である。
［例示１７］
<a20:QBA id="atsc.org/PDIQ/working" >
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Q>
</a20:QBA>
図１０７は、本発明の一実施例に係るＰＤＩ ＡＰＩを示す図である。
具体的に、図１０７は、上述した宣言コンテンツオブジェクト（ＤＯ）などのアプリケーションがＰＤＩデータを利用するための関数を示す図である。本発明の一実施例に係るＰＤＩ ＡＰＩは、本発明の一実施例に係る受信機がＰＤＩストアにアクセスするためのインターフェースを意味する。
ＡＴＳＣ２．０クライアント装置は、ＰＤＩ質問に対するアクセス（例えば、検索及び更新）を可能にするためにＰＤＩ ＡＰＩをサポートする。
ＡＴＳＣ２．０ＤＡＥの一環として提供されるＡＰＩは、保存装置からその質問のテキストを取ってきて、（可能ならば）当該質問に対して既に提供された回答を取ってきて、当該質問に対する回答を保存するために、与えられた質問のＩＤを考慮してＤＯを許容する。
ＴＤＯがある特定質問又は回答に対してアクセスしたり記録することを防止するある規則を定義したり実施しようと試みない。複数のエンティティ（ｅｎｔｉｔｉｅｓ）が与えられたチャネルで使用可能な質問表を提供できることが構想される。このようなエンティティは、国家の伝送網事業者、ローカル放送局系列社、様々なプログラム生産者／供給者を含むことができるが、これに制限されない。
ＡＴＳＣ２．０クライアント装置は、ＰＤＩデータ保存及び検索のためのＡＰＩを実現する。ＰＤＩ機能を実行するために、装置は、ネイティブアプリケーション、ファイルシステム／データベースを用いたり遠隔サービスを用いて、ＰＤＩデータベースを提供することができる。ＰＤＩストアは、ＡＴＳＣクライアントに拘束されている。一つのＰＤＩストアインスタンスだけがクライアントのために存在する。ＰＤＩストアは、ＤＯがクライアントのＰＤＩデータに接続できるようにし、また、ユーザがネイティブアプリケーションを介して別個のサービスプロバイダにわたって持続してＰＤＩ質問を管理（例えば、更新、追加、又は削除）できるようにする。
図１０７は、本発明の一実施例に係るＰＤＩ ＡＰＩを示すテーブルである。本発明の一実施例に係る受信機は、図１０７に示すＰＤＩ ＡＰＩを用いてＰＤＩテーブルリストを取得することができる。
以下、図１０７に示すＡＰＩについて説明する。
図１０７に示すＡＰＩの名称は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）であり、これは、設計者の意図によって変更可能な事項である。図１０７に示す説明は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数の詳細内容を示す。図１０７に示す引数（ａｒｇｕｍｅｎｔｓ）は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数のパラメータを示す。
より具体的に、図１０７に示す説明は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数がそれぞれに対してｐｄｉＴａｂｌｅＩｄを提供し、ＰＤＩテーブルのリストを有するＸＭＬ構造を返すということを示す。ＸＭＬ構造は、次のＸＭＬスキーマと同一である。一つのｐｄｉＴａｂｌｅＩｄ下位エレメントを有するｐｄｉＴａｂｌｅＬｉｓｔエレメントは、基数０から無限である。ｐｄｉＴａｂｌｅＩｄインスタンスが０の場合は、放送局がＰＤＩテーブルを提供しなかったということを示す。
図１０７に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルのグローバルに一意の識別子であるということを、ＵＲＩの形態で示す。
したがって、本発明の一実施例に係る受信機は、ＸＭＬスキーマによるテーブルフォーマットのＰＤＩテーブルリストを受信することができる。図１０７に示すように、ＰＤＩテーブルリストは、ｐｄｉＴａｂｌｅＩｄエレメントを含むことができる。図１０７に示すｐｄｉＴａｂｌｅＩｄエレメントの基数が０を示す場合、本発明の一実施例に係る受信機が放送局からＰＤＩテーブルを受信していないことを意味できる。
図１０８は、本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。
具体的に、図１０８は、本発明の一実施例に係る受信機がＰＤＩテーブルを取得するためのＰＤＩ ＡＰＩを示す図である。
以下、図１０８に示すＡＰＩについて説明する。
図１０８に示すＡＰＩの名称はｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）であり、これは、設計者の意図によって変更可能な事項である。図１０８に示す説明は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の詳細内容を示す。図１０８に示す引数は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数のパラメータを示す。
より具体的に、図１０８に示す説明は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数が受信機に対してＰＤＩテーブルＸＭＬ文書を返すためのものであることを示す。各ｐｄｉＴａｂｌｅは、当該方法に対する入力として提供されたグローバルに一意のｐｄｉＴａｂｌｅＩｄ識別子によって識別されることと関連している。返された値は、連載された（ｓｅｒｉａｌｉｚｅｄ）ＰＤＩテーブルＸＭＬインスタンスを含み、選択的にＰＤＩ−Ｑ又はＰＤＩ−Ａ ＸＭＬインスタンスを含むストリングである。
図１０８に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルのグローバルに一意の識別子であることを、ＵＲＩの形態で示す。
したがって、本発明の一実施例に係る受信機は、図１０７で説明したＰＤＩテーブルリストを受信した後に、ＰＤＩテーブルを受信することができる。具体的に、ＰＤＩテーブルリストを受信した受信機は、図１０７に示すｐｄｉＴａｂｌｅＩｄに関連したＰＤＩテーブルＸＭＬ文書を受信することができる。
具体的に、図１０８に示すＰＤＩ ＡＰＩによる受信機の動作は、図５８乃至図６１、図７６、図８７、図８９及び図９２乃至図９５で説明したとおりである。また、図１０８に示すＰＤＩ ＡＰＩによる受信機は、図６２乃至図７２で説明したＰＤＩテーブルフォーマットによるＰＤＩテーブルリストを受信することができる。
図１０９は、本発明の更に他の実施例に係るＰＤＩ ＡＰＩを示す図である。
具体的に、図１０９は、本発明の一実施例に係る受信機がＰＤＩ回答を取得するためのＰＤＩ ＡＰＩを示す図である。
以下、図１０９に示すＡＰＩについて説明する。
図１０９に示すＡＰＩの名称はｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）であり、これは、設計者の意図によって変更可能な事項である。図１０９に示す説明は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の詳細内容を示す。図１０９に示す引数は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数のパラメータを示す。
より具体的に、図１０９に示す説明は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数が受信機に対してＰＤＩ−Ａ ＸＭＬ文書を返すためのものであることを示す。各ｐｄｉＴａｂｌｅは、当該方法に対する入力として提供されたグローバルに一意のｐｄｉＴａｂｌｅＩｄ識別子によって識別されることと関連している。返された値は、連載されたＰＤＩ−Ａ ＸＭＬインスタンスを含むストリングである。
図１０９に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルのグローバルに一意の識別子であることを、ＵＲＩの形態で示す。
したがって、図１０７で説明したＰＤＩテーブルリストを受信した受信機は、図１０７に示すｐｄｉＴａｂｌｅＩｄに関連したＰＤＩ−ＡテーブルのＸＭＬ文書（又は、ＰＤＩ−Ａインスタンス文書）を受信することができる。本発明の一実施例に係るＰＤＩ−Ａインスタンス文書は、図６８及び図６９で説明したとおりである。
具体的に、図１０９に示すＰＤＩ ＡＰＩによる受信機の動作は、前述した図面で説明したとおりである。
図１０７乃至図１０９に示してはいないが、本実施例に係るＰＤＩ ＡＰＩは、下記の表３９及び／又は表４０のように記述することができる。
Figure 0006189546
Figure 0006189546
図１１０は、本発明の一実施例に係る、受信機とコンパニオン装置（Ｃｏｍｐａｎｉｏｎ Ｄｅｖｉｃｅ）との間でユーザーデータ（Ｕｓｅｒ Ｄａｔａ）を交換する関係を示す図である。
本発明では、ＰＤＩ（Ｐｒｏｆｉｌｅ，Ｄｅｍｏｇｒａｐｈｉｃｓ，ａｎｄ Ｉｎｔｅｒｅｓｔｓ）Ｕｓｅｒ Ｄａｔａ（ｅ．ｇ；Ｖｉｅｗｉｎｇ Ｐｒｅｆｅｒｅｎｃｅ，ｇｅｏ−ｌｏｃａｔｉｏｎ ｄａｔａ，ｅｔｃ．．）を、放送受信機を含む他の形態のコンパニオン装置間に交換することができる。
コンテンツプロバイダ（Ｃｏｎｔｅｎｔ Ｐｒｏｖｉｄｅｒ）又は放送局（Ｂｒｏａｄｃａｓｔｅｒ）が生成したＰＤＩユーザーデータ質問（ＰＤＩ Ｕｓｅｒ Ｄａｔａ Ｑｕｅｓｔｉｏｎａｒｉｅｓ）を受信機に伝達すると、受信機はユーザに当該質問（Ｑｕｅｓｔｉｏｎａｒｉｅｓ）を提供し、この質問に対する回答（Ａｎｓｗｅｒ）を受けてユーザーデータ保存所（Ｕｓｅｒ Ｄａｔａ Ｓｔｏｒｅ）に保存することができる。この保存所は、受信機内に設けられていてもよく、受信機の外部に（例えば、Ｃｌｏｕｄ）位置してもよい。このように基本的に保存されたユーザーデータをコンパニオン装置に伝達することができ、逆に、コンパニオン装置で設定した回答を受信機が受け取って保存してもよい。受信機のコンパニオン装置との通信のためのプロトコル（Ｐｒｏｔｏｃｏｌ）は特定プロトコルに限定されないが、本発明では、ＵＰｎＰに基づいて実施例を作成する。本発明ではＰＤＩユーザーデータの形態も限定されないが、ＸＭＬの形態で構成されることを実施例として説明する。
図１１１は、本発明の他の実施例に係る、ＰＤＩユーザーデータのＸＭＬの一部を示す図である。
ＰＤＩユーザーデータに含まれる各エレメントに関する説明は、図面に開示した説明及び／又は前述したＰＤＩテーブルのＸＭＬ形態に含まれる類似の名称を有するエレメントに関する説明で代える。
図１１２は、本発明の他の実施例に係る、ＰＤＩユーザーデータのＸＭＬの他の一部を示す図である。
ＰＤＩユーザーデータに含まれる各エレメントに関する説明は、図面に開示した説明及び／又は前述したＰＤＩテーブルのＸＭＬ形態に含まれる類似の名称を有するエレメントに関する説明で代える。
図１１３は、本発明の一実施例に係る、放送受信機とコンパニオン装置との間にＰＤＩユーザーデータを交換するために定義されるＳｅｒｖｉｃｅ Ｔｙｐｅ及びＳｅｒｖｉｃｅ ＩＤを示す図である。
ＰＤＩユーザーデータの交換のために、受信機とコンパニオン装置（Ｃｏｍｐａｎｉｏｎ Ｄｅｖｉｃｅ）との互換性のためのｄｅｖｉｃｅ ｔｙｐｅを定義することができる。
ＰＤＩユーザーデータを機器の間で交換するために、次のようなｄｅｖｉｃｅ ｔｙｐｅを定義することができる。
UPnP Device Type - urn:atsc.org:device:atsc3.0rcvr
一実施例で、ｄｅｖｉｃｅ ｔｙｐｅと合わない装置（ｄｅｖｉｃｅ）の間では、本発明で説明するサービスが用いられないようにすることができる。定義されたｄｅｖｉｃｅ ｔｙｐｅをサポートする放送受信機（例えば、ＡＴＳＣ３．０受信機）とコンパニオン装置とがＰＤＩユーザーデータを交換するために、Ｓｅｒｖｉｃｅ Ｔｙｐｅ及びＳｅｒｖｉｃｅ ＩＤを指定することができる。
図１１４は、本発明の一実施例に係る、ＵＰｎＰによってＰＤＩユーザーデータを交換するために定義される情報を示す図である。
図面の（ａ）を参照すると、ＵＰｎＰ ＵｓｅｒＤａｔａ ｓｅｒｖｉｃｅは、ＰＤＩ Ｕｓｅｒ Ｄａｔａを交換するために次のような状態変数を定義することができる。状態変数は、ＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔ及び／又はＵｓｅｒＤａｔａを含むことができる。
ＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、ＰＤＩユーザデータプロトコルバージョンを示す。
ＵｓｅｒＤａｔａＩｄｓＬｉｓｔは、ＰＤＩストアに保存されているＰＤＩユーザデータのＩｄのリストを示す。
ＵｓｅｒＤａｔａは、複数個の質問表及び回答で構成されたＰＤＩユーザデータを示す。
図面の（ｂ）を参照すると、ＵＰｎＰ ＵｓｅｒＤａｔａサービスのアクションが定義されている。ＵＰｎＰ ＵｓｅｒＤａｔａサービスのアクションは、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション、ＧｅｔＵｓｅｒＤａｔａアクション、及び／又はＳｅｔＵｓｅｒＤａｔａアクションを含むことができる。
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションは、ＰＤＩストアに保存されているＰＤＩユーザデータのＩｄを取り込むａｃｔｉｏｎであり、アクションのための引数（ａｒｇｕｍｅｎｔ）と関連した状態変数は、図面の（ｃ）のようである。ＰＤＩユーザデータのＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを参照して、当該プロトコルをサポートするＰＤＩユーザデータのＩＤだけを取り込むことができる。
ＧｅｔＵｓｅｒＤａｔａアクションは、ＰＤＩストアに保存されているＰＤＩユーザデータを取り込むアクションであり、アクションのための引数に関連した状態変数は、図面の（ｄ）のようである。
ＳｅｔＵｓｅｒＤａｔａアクションは、コンパニオン装置でＰＤＩユーザデータを設定して受信機に伝達するために用いることができる。ＳｅｔＵｓｅｒＤａｔａアクションのための引数に関連した状態変数は後述する。
図１１５は、本発明の一実施例に係る、ＰＤＩユーザデータを交換する方法を示すシーケンス図である。
コンパニオン装置が放送受信機からＰＤＩユーザデータを取り込むことができる。コンパニオン装置と受信機は互いにペアリング（Ｐａｒｉｎｇ）されており、この過程は、同図では省略する。
コンテンツプロバイダ（Ｃｏｎｔｅｎｔ Ｐｒｏｖｉｄｅｒ）又は放送局（Ｂｒｏａｄｃａｓｔｅｒ）は、ユーザに個人化されたサービスを提供するために、ＰＤＩユーザデータを受信機に伝達することができる。ＰＤＩユーザデータは、ユーザに提供される複数の質問表及び／又は回答可能な項目である回答を含むことができる。
受信機は、ＰＤＩエンジンにＰＤＩユーザデータを伝達する。（段階１）
ＰＤＩエンジンはユーザに質問表をディスプレイするように制御することができる。（段階２）
ユーザは各質問に該当する回答を設定することができる。（段階３）
回答の完了したＱ＆Ａは、ＰＤＩユーザデータストアに保存される。（段階４）
コンパニオン装置でＰＤＩユーザデータを得るためにＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションを用いて受信機のＰＤＩユーザデータのＩｄを要求する。（段階５）
コンパニオン装置モジュールは、ＰＤＩエンジンにＰＤＩユーザデータのＩｄを要求する。（段階６）
ＰＤＩエンジンは、ＰＤＩユーザデータストアで保存されているＰＤＩユーザデータのＩｄを検索する。（段階７）
ＰＤＩエンジンは、ＰＤＩユーザデータＩｄをコンパニオン装置モジュールに伝達する。（段階８）コンパニオン装置モジュールは、放送受信機内に設けられてもよく、コンパニオン装置とのインターフェースを担当する。
コンパニオン装置モジュールは、ＰＤＩユーザデータＩｄをコンパニオン装置に伝達する。（段階９）
コンパニオン装置は、受信したＰＤＩユーザデータＩｄに基づいてＧｅｔＵｓｅｒＤａｔａアクションを用いてＰＤＩユーザデータを要求することができる。（段階１０）
コンパニオン装置モジュールは、ＰＤＩエンジンにＰＤＩユーザデータを要求する。（段階１１）
ＰＤＩエンジンは、ＰＤＩストアで保存されているＰＤＩユーザデータを検索する。（段階１２）
ＰＤＩエンジンは、コンパニオン装置モジュールにＰＤＩユーザデータを伝達する。（段階１３）
コンパニオン装置モジュールは、ＰＤＩユーザデータをコンパニオン装置に伝達し、コンパニオン装置は受信したデータを保存する。（段階１４）
交換の完了したＰＤＩユーザデータは、コンパニオン装置内に別途のユーザデータ保存所がある場合には半永久的に保存されてもよく、保存所がない場合には、メモリなどの空間に一時的に保存されてもよい。
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション及び／又はＧｅｔＵｓｅｒＤａｔａアクションを行う時点は、前述した順序に限定されない。例えば、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション及び／又はＧｅｔＵｓｅｒＤａｔａアクションは、コンパニオン装置と放送受信機とがペアリングされた直後に又はコンパニオン装置から周期的にポーリングしながら要求する場合に発生してもよい。
図１１６は、本発明の一実施例に係るＳｅｔＵｓｅｒＤａｔａアクションのための引数に関連した状態変数を示す図である。
前述したように、ＳｅｔＵｓｅｒＤａｔａアクションは、コンパニオン装置でＰＤＩユーザデータを設定して受信機に伝達する時に用いることができる。すなわち、ＳｅｔＵｓｅｒＤａｔａアクションは、コンパニオン装置のユーザが、ＰＤＩユーザデータに含まれた質問に対する回答を選択し、この情報を受信機に伝達しようとする場合に用いられる動作である。
図１１７は、本発明の一実施例に係る、コンパニオン装置でＰＤＩユーザデータを設定し、これを受信機に伝達してユーザデータストアに保存する方法を示すシーケンス図である。
コンパニオン装置と受信機は互いにペアリングされていると仮定する。
コンテンツプロバイダ又は放送局は、ユーザに個人化されたサービスを提供するために、ＰＤＩユーザデータをコンパニオン装置に伝達することができる。ＰＤＩリストは、ユーザの回答を必要とする複数の質問表であってもよい。（段階１）
コンパニオン装置は、受信したＰＤＩユーザデータのうちの質問表をユーザに見せ、ユーザは、質問表に該当する回答を設定することができる。（段階２）
コンパニオン装置はＳｅｔＵｓｅｒＤａｔａアクションを用いてＰＤＩユーザデータを受信機内コンパニオン装置モジュールに伝達する。（段階３）
コンパニオン装置モジュールは、受信したユーザデータをＰＤＩエンジンに伝達する。（段階４）
ＰＤＩエンジンは、ＰＤＩユーザデータストアに既に保存されていたＰＤＩユーザデータがあるか検索する。（段階５）この時、受信機は、ＰＤＩテーブルに含まれているＰＤＩテーブル識別情報又はアプリケーション識別情報を用いて、特定アプリケーションと関連して受信したＰＤＩテーブルが既に存在するかを判断することができる。
ＰＤＩエンジンは、検索の結果、既に保存されていたＰＤＩユーザデータがないと、新しく保存し、検索された結果があると、当該ＰＤＩユーザデータをアップデートすることができる。（段階６）
図１１８は、本発明の一実施例に係る、ＰＤＩユーザデータに変化が発生する場合、これを伝達するための状態変数を示す図である。
ＵＰｎＰ ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータをコンパニオン装置に伝達するとき、ＰＤＩユーザデータがアップデートされるなどの変化がある場合にのみ伝達するために、追加の状態変数を設定することができる。例えば、ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅを用いて、ＰＤＩユーザデータが最後に修正された時間を示し、Ｅｖｅｎｔ ｔｙｐｅにＰＤＩユーザデータが修正されると、該当の状態変数を伝達することができる。
図１１９は、本発明の一実施例に係る、ＰＤＩユーザデータの変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンス図である。
本発明の一実施例は、新しいＰＤＩユーザデータが伝達されて変化が起きるとき、コンパニオン装置が受信機からＰＤＩユーザデータを取り込む方法を示す。コンパニオン装置と受信機とは互いにペアリングされており、この過程はシーケンス図で省略する。
コンパニオン装置はコンパニオン装置モジュールに、状態変数であるＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅの値が変化する場合に受信するためにｓｕｂｃｒｉｂｅする。（段階１）
コンテンツプロバイダ又は放送局は、新しい質問表を受信機に伝達することができる。（段階２）
受信機は、ＰＤＩエンジンに質問表を伝達する。（段階３）
ＰＤＩユーザデータエンジンはユーザに質問表を見せ、ユーザは各質問に該当する回答を設定することができる。（段階４）
回答の完了したＱ＆Ａは、ＰＤＩユーザデータストアに保存される。（段階５）
ＰＤＩエンジンは、状態変数であるＵｓｅｒＤａｔａＩｄｘＣｏｕｎｔをアップデートする。（段階６）
ＵｓｅｒＤａｔａＩｄｘＣｏｕｎｔがアップデートされると、ｅｖｅｎｔを用いてコンパニオン装置に質問表の変化があることを通知することができる。（段階７）
その後、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション及び／又はＧｅｔＵｓｅｒＤａｔａアクションを用いてＰＤＩユーザデータをコンパニオン装置に取り込むことができる。この過程は、前述した過程を参考にすればよい。新しいＰＤＩユーザデータが伝達されず、既に保存されていたＰＤＩユーザデータの回答が変更される場合には、段階１及び段階２を除いて、段階３から行われてもよい。
図１２０は、本発明の他の実施例に係る、ＰＤＩユーザデータの変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンス図である。
ＵＰｎＰ ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータをコンパニオン装置に伝達する時、ＰＤＩユーザデータがアップデートされるなどの変化がある場合にのみ伝達するために、追加の状態変数を設定することができる。そのために、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔが設定されてもよく、これは、ＣＳＶリスト形態であって、ユーザデータＩｄとそれに該当するユーザデータバージョンのペア形態のリストである。例えば、（ＵｓｅｒＤａｔａＩｄ＃１，１．０）のような形態で表現されてもよい。ＰＤＩユーザデータＩＤの変化があったり、ＰＤＩユーザデータバージョンの変化がある場合に、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔもアップデートされてもよく、ｅｖｅｎｔ ｔｙｐｅへの変化をコンパニオン装置に通知することができる。ＰＤＩユーザデータＩＤの場合は追加或いは削除されてもよく、ＰＤＩユーザデータバージョンの場合には、修正の都度、その値が１ずつ増加してもよい。
図１２１は、本発明の他の実施例に係る、ＰＤＩユーザデータの変化がある場合、ＰＤＩユーザデータを伝達する方法を示すシーケンス図である。
本発明の一実施例は、既に保存されていたＰＤＩユーザデータの回答が変更される場合、コンパニオン装置が受信機からＰＤＩユーザデータを取り込む方法を示す。コンパニオン装置と受信機は互いにペアリングされており、この過程はシーケンス図で省略する。
コンパニオン装置は、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔ状態変数にｓｕｂｓｃｒｉｂｅし、ユーザデータがアップデートされた場合（ユーザデータＩｄ或いはユーザデータバージョンが変更された場合）に通知を受け得るようにする。（段階１）
既存の受信機に保存されていた質問表の回答を変更する。既存のＰＤＩユーザデータが変更されたので、ＰＤＩユーザデータバージョンをアップデートする。（段階２）
回答の完了したＱ＆Ａは、ＰＤＩユーザデータストアに保存される。（段階３）
変更されたＰＤＩユーザデータバージョンによって状態変数であるＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔの値をアップデートする。（段階４）
コンパニオン装置モジュールは、ｅｖｅｎｔ ｔｙｐｅと宣言されたＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔの値が変更されたので、コンパニオン装置に変更されたことを通知する。（段階５）
コンパニオン装置は、変更された状態変数であるＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔを参照して、既に保存されていたＰＤＩユーザデータのバージョンと比較する。（段階６）
コンパニオン装置は、ＰＤＩユーザデータバージョンが変更されたＰＤＩユーザデータに対してＰＤＩユーザデータを取り込むようにアクションを行うことができる。変更されたＰＤＩユーザデータだけを取り込んでもよく、全ＰＤＩユーザデータを再び取り込んでもよい。（段階７）
その後、コンパニオン装置は、ＧｅｔＵｓｅｒＤａｔａアクションを通じてＰＤＩユーザデータを取り込むことができる。この過程はシーケンス図で省略する。新しくＰＤＩユーザデータが追加される場合には、コンテンツプロバイダ／放送局からＰＤＩユーザデータを受信機に伝達する過程が追加されてもよいが、このシーケンス図では省略する。
図１２２は、本発明の一実施例に係る、ＱｕｅｓｔｉｏｎとＡｎｓｗｅｒのペア単位でＰＤＩユーザデータを取り込むための状態変数を示す図である。
ＰＤＩユーザデータを受信機とコンパニオン装置との間で交換する時、その量によってオーバーロードが発生しうる。このため、質問と回答のペア単位でＰＤＩユーザデータを伝達してもよい。
図面の（ａ）を参照すると、Ｑ＆Ａペアを交換するために状態変数を定義することができる。そのために、状態変数はＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ及び／又はＵｓｅｒＤａｔａＱＡを含むことができる。
ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔは、ＰＤＩストアに保存されている質問とそれに関連した回答とのペアＩｄのリストを示す。
ＵｓｅｒＤａｔａＱＡは、質問と回答のペアセットを示す。
図面の（ｂ）を参照すると、ＵＰｎＰ ＵｓｅｒＤａｔａサービスは、次のような３つのアクションを有することができる。
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションは、ＰＤＩストアに保存されている質問／回答のペアのＩｄを取り込むアクションである。
ＧｅｔＵｓｅｒＤａｔａＱＡアクションは、ＰＤＩストアに保存されている質問／回答のペアを取り込むアクションである。
ＳｅｔＵｓｅｒＤａｔａＱＡアクションは、コンパニオン装置でＱ＆Ａを設定して受信機に伝達する時に用いることができる。
図１２３は、本発明の一実施例に係る、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクション及びＧｅｔＵｓｅｒＤａｔａＱＡアクションのための引数と関連した状態変数を示す図である。
図面の（ａ）を参照すると、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションのための引数と関連した状態変数が開示されている。前述したＰＤＩユーザデータのＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを参照して、当該プロトコルをサポートするＰＤＩユーザデータのＱ＆Ａ ＩＤだけを取り込むことができる。
図面の（ｂ）を参照すると、ＧｅｔＵｓｅｒＤａｔａＱＡアクションのための引数と関連した状態変数が開示されている。
図１２４は、本発明の一実施例に係る、質問／回答のペアを交換する方法に関するシーケンス図を示す図である。
コンパニオン装置は受信機からＰＤＩユーザデータを取り込むことができる。コンパニオン装置と受信機は互いにペアリングされており、この過程はシーケンス図で省略する。
コンテンツプロバイダ又は放送局は、ユーザに個人化されたサービスを提供するために、ＰＤＩユーザデータを受信機に伝達することができる。（段階１）ＰＤＩユーザデータは、ユーザの複数の質問と回答の組合せであってもよい。
受信機は、ＰＤＩエンジンにＰＤＩユーザデータを伝達する。（段階２）
ＰＤＩエンジンは、ユーザに質問表を見せ、ユーザは各質問に該当する回答を設定することができる。（段階３）
回答の完了したＱ＆Ａは、ＰＤＩユーザデータストアに保存される。（段階４）
コンパニオン装置は、質問とそれに関する回答のペアデータを得るためにＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションを通じて、受信機の質問＆回答のペアＩｄを要求する。（段階５）
コンパニオン装置モジュールは、ＰＤＩエンジンにＱ＆Ａ Ｉｄを要求する。（段階６）
ＰＤＩエンジンは、ＰＤＩユーザデータストアで保存されているＱ＆Ａ Ｉｄを検索する。（段階７）
ＰＤＩエンジンは、Ｑ＆ＡＩｄをコンパニオン装置モジュールに伝達する。（段階８）
コンパニオン装置モジュールは、Ｑ＆Ａ Ｉｄをコンパニオン装置に伝達する。（段階９）
コンパニオン装置は、受信したＱ＆Ａ Ｉｄを用いて、ＧｅｔＵｓｅｒＤａｔａＱＡアクションを通じてＱ＆Ａペアデータを要求することができる。（段階１０）
コンパニオン装置モジュールは、ＰＤＩエンジンにＱ＆Ａペアを要求する。（段階１１）
ＰＤＩエンジンは、ＰＤＩストアで保存されているＱ＆Ａペアを検索する。（段階１２）
ＰＤＩエンジンは、コンパニオン装置モジュールにＱ＆Ａペアを伝達する。（段階１３）
Ｃｏｍｐａｎｉｏｎモジュールは、Ｑ＆Ａペアをコンパニオン装置に伝達し、コンパニオン装置は、受信したデータを保存する。（段階１４）
交換の完了したＱ＆Ａペアデータは、コンパニオン装置内に別のユーザデータ保存所がある場合には半永久的に保存してもよく、保存所がない場合にはメモリなどの空間に一時的に保存してもよい。
ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクション及び／又はＧｅｔＵｓｅｒＤａｔａＱＡアクションを行う時点は、コンパニオン装置と受信機がペアリングされた直後であってもよく、コンパニオン装置で周期的にポーリングしながら上記のアクションを要求してもよい。
図１２５は、本発明の一実施例に係る、ＳｅｔＵｓｅｒＤａｔａＱＡアクションのための引数に関連した状態変数を示す図である。
ＳｅｔＵｓｅｒＤａｔａＱＡ（又は、ＵｓｅｒＤａｔａＱＡ）アクションは、コンパニオン装置でＱ＆Ａを設定して受信機に伝達する時に用いることができる。ＳｅｔＵｓｅｒＤａｔａＱＡアクションのための引数に関連した状態変数は、次のとおりである。
図１２６は、本発明の一実施例に係る、コンパニオン装置でＱ＆Ａを設定し、これを受信機に伝達してユーザデータストアに保存する方法を示すシーケンス図である。
コンパニオン装置と受信機は互いにペアリングされており、この過程はシーケンス図で省略する。
コンテンツプロバイダ又は放送局は、ユーザに個人化されたサービスを提供するために、ＰＤＩユーザデータをコンパニオン装置に伝達することができる。（段階１）ＰＤＩリストは、ユーザの回答が必要な複数の質問表であってもよい。
コンパニオン装置は、受信したＰＤＩユーザデータのうち質問表をユーザに見せ、ユーザは、質問表に該当する回答を設定することができる。（段階２）
コンパニオン装置は、ＳｅｔＵｓｅｒＤａｔａＱＡアクションを通じてＱ＆Ａを受信機内のコンパニオン装置モジュールに伝達する。（段階３）
コンパニオン装置モジュールは、受信したＱ＆ＡをＰＤＩエンジンに伝達する。（段階４）
ＰＤＩエンジンは、ＰＤＩユーザデータストアに、既に保存されていたＱ＆Ａがあるか検索する。（段階５）
ＰＤＩエンジンは、検索の結果、既に保存されているＱ＆Ａがないと、新しく保存をし、検索された結果があると、当該Ｑ＆Ａをアップデートすることができる。（段階６）
図１２７は、本発明の一実施例に係る、Ｑ＆Ａがアップデートされるなどの変化がある場合、これを伝達するための状態変数を示す図である。
図面の（ａ）を参照すると、ＵＰｎＰ ＵｓｅｒＤａｔａサービスは、Ｑ＆Ａをコンパニオン装置に伝達する時、Ｑ＆Ａがアップデートされるなどの変化がある場合にのみ伝達するために、追加の状態変数を設定することができる。この場合、ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅが設定されてもよく、これは、Ｑ＆Ａが最後に修正された時間を示し、Ｅｖｅｎｔ ｔｙｐｅにＰＤＩユーザデータが修正されると、当該状態変数を伝達することができる。
Ｑ＆Ａをコンパニオン装置に伝達する動作は、ＰＤＩユーザデータの全部を伝達する時の動作と同一なので、これに関するシーケンス図の実施例は、前述したＰＤＩユーザデータに関する説明で代えるものとする。
図面の（ｂ）を参照すると、ＵＰｎＰ ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータをコンパニオン装置に伝達する時、ＰＤＩユーザデータがアップデートされるなどの変化がある場合にのみ伝達するために追加の状態変数を設定することができる。この場合、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔが設定されてもよく、これは、ＣＳＶリスト形態であって、ユーザデータＩｄとそれに該当するユーザデータバージョンのペア形態のリストである。例えば、（ＵｓｅｒＤａｔａＩｄ＃１，１．０）のような形態で表現されてもよい。ＰＤＩユーザデータＩＤの変化があったり、ＰＤＩユーザデータバージョンの変化がある場合、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔもアップデートされてもよく、ｅｖｅｎｔ ｔｙｐｅへの変化をコンパニオン装置に通知することができる。ＰＤＩユーザデータＩＤの場合は追加或いは削除されてもよい。ＰＤＩユーザデータバージョンの値は、修正がある都度、１ずつ増加してもよい。
ＰＤＩユーザデータをコンパニオン装置に伝達する動作は、ＰＤＩユーザデータの全部を伝達する時の動作と同一なので、これに関するシーケンス図の実施例は、前述したＰＤＩユーザデータに関する説明で代える。
図１２８は、本発明の他の実施例に係る受信機を示す図である。
図示する受信機は、前述した受信機及び受信機に含まれる装置に類似しているので、同一の名称を有する装置に関する説明は、前述した説明で代える。
前述したターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ユーザーデータシェアリング及びターゲッティングシグナリングパーサー（Ｕｓｅｒ Ｄａｔａ Ｓｈａｒｉｎｇ ＆ Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）と命名でき、前述したユーザデータ（例えば、ＰＤＩユーザデータ又はＱ＆Ａ）をパースする役割をさらに担うことができる。
前述したターゲッティングプロセッサ（Ｔａｒｇｅｔｉｎｇ Ｐｒｏｃｅｓｓｏｒ）は、ユーザーデータシェアリング及びターゲッティングプロセッサ（ Ｕｓｅｒ Ｄａｔａ Ｓｈａｒｉｎｇ ＆ Ｔａｒｇｅｔｉｎｇ Ｐｒｏｃｅｓｓｏｒ）と命名でき、前述したユーザデータ（例えば、ＰＤＩユーザデータ又はＱ＆Ａ）を処理する役割をさらに担うことができる。
本発明の他の実施例に係る受信機は、ユーザーデータデータベース（ Ｕｓｅｒ Ｄａｔａ ＤＢ）をさらに含むことができる。ユーザーデータデータベースは、処理されたユーザーデータを保存する。
図１２９は、本発明の一実施例に係る、同期化されたアプリケーション（ｓｙｎｃｈｒｏｎｉｚｅｄ ａｐｐｌｉｃａｔｉｏｎ）への進入のための通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を示す図である。
同期化されたアプリケーションは、非実時間放送及び／又は実時間放送のコンテンツと連動して表示されるアプリケーションである。同期化されたアプリケーションは、放送コンテンツにおいて当該アプリケーションが必要な適切な時期に実行されたり表示され得るように設定されたアプリケーションである。
ここで、アプリケーションは、一般的なアプリケーションの意味で使われてもよい。又は、アプリケーションは、放送コンテンツ上に、コンテンツと関連してディスプレイされるオブジェクトを示す意味で使われてもよい。例えば、アプリケーションは、スポーツが放送されている中、特定選手に対するプロファイルが画面にディスプレイされる場合において、当該プロファイルをディスプレイできるようにする主体と定義することができる。
非実時間放送は、実時間放送のための放送信号又はデータが伝送されない、放送信号内の遊休帯域を通じて、放送コンテンツのためのデータを送／受信する放送の形態である。ここで、遊休帯域は、実時間放送がサービスされない時間領域と定義されてもよく、或いは、実時間放送を送信する過程でも放送信号の帯域幅が残っている場合、この帯域幅と定義することができる。遊休帯域で放送コンテンツを伝送するとき、放送コンテンツは一つ以上のファイル（又は、オブジェクト）に分離され、不連続的に伝送されてもよい。受信機は、このようなファイルを受信して保存しており、放送コンテンツに含まれる全てのファイルを受信すると、ユーザの要求などに応じて、該当の放送コンテンツを再生することができる。
本発明の一実施例によれば、同期化されたアプリケーションの通知のためのユーザインターフェース（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）及び／又はフォーマット（ｆｏｒｍａｔ）は受信機で制御することができる。
図１２９の（ａ）を参照すると、既存データ放送と関連したアプリケーションの場合、アプリケーションに進入経路を知らせる通知（ｎｏｔｉｆｉｃａｔｉｏｎ）は、放送局が提供する赤い点（Ｒｅｄ ｄｏｔ）形態の単純な通知で構成された。
しかし、本発明では、このようなアプリケーションに対する通知を受信機で調節又は実現できるようにする方法及び／又は装置を提示する。受信機でアプリケーションに対する通知を調節する場合、この通知の調節のための情報は、コンテンツプロバイダ或いは放送局から提供される情報に基づいて構成することができる。
本発明によれば、チャネル別及び／又はアプリケーション別に、通知を固有の形態と内容で表示することができる。このとき、各チャネル別或いはプログラム別に、コンテンツプロバイダ或いは放送局から、各チャネル別或いはプログラム別の特性に合うように、同期化されたアプリケーションの通知（ｓｙｎｃｈｒｏｎｉｚｅｄ ａｐｐｌｉｃａｔｉｏｎ ｎｏｔｉｆｉｃａｔｉｏｎ）の形態及び／又は動作属性に関するデータを受けることができる。この方式は、同期化されたアプリケーションの通知を、受信機でコンテンツプロバイダ或いは放送局から提供される情報によって再構成できるという点で、既存データ放送のアプリケーションと異なる。また、受信機で内部的にコンテンツプロバイダ或いは放送局によってアプリケーションの実際使用情報以外の視聴情報（例：ユーザが放送を視聴開始した後、アプリケーションの通知を押してアプリケーションに進入した時間などの情報）に対する収集を遮断して、ユーザ個人の情報保護を設定することができる。これと逆に、受信機で内部的に許容した、アプリケーションの実際使用情報以外の視聴情報を、コンテンツプロバイダ又は放送局に提供できるように設定することができる。このような方式でユーザはアプリケーションに対してより能動的に制御することができる。同期化されたアプリケーションの通知の形態のために受信できる情報は、通知の画面上の位置情報、通知のディスプレイの大きさ情報、メッセージ内容、アプリケーションを示すイメージ及び／又は放送局（又は、コンテンツプロバイダ）ロゴなどを含むことができ、動作属性のために受信できる情報は、通知が最初に活性化される時間情報、通知の持続時間情報及び／又は通知の周期情報などを含むことができる。
図１２９の（ｂ）は、各チャネル別に放送局から提供された通知のディスプレイの大きさ情報、通知の画面上の位置情報、メッセージ内容及び放送局ロゴ情報を用いて、同期化されたアプリケーションに進入するための通知を生成し、ディスプレイした一実施例である。
図１３０は、本発明の一実施例に係る、同期化されたアプリケーションの通知とユーザ同意インターフェースを連動するためのユーザインターフェースを示す図である。
同期化されたアプリケーション又はそのための通知は、ユーザの同意を得た後、実行又は表示され得るように設定されてもよい。例えば、各アプリケーション、プログラム、チャネル別にユーザの同意の有無を設定することができる。
ユーザの同意が設定されていない場合、当該同期化されたアプリケーションは遮断されてもよく、この場合、受信機で当該アプリケーションはユーザに提供しない。又は、ユーザの同意に対するいかなる設定もしていない場合、全てのアプリケーションを遮断したり、全てのアプリケーションを遮断しないで提供することができる。
同期化されたアプリケーションに対するユーザ同意のためのインターフェースは、受信機で構成することができ、ユーザ同意の条件と方式は、色々な形態で提供されてもよい。
ユーザ同意に対するインターフェースとアプリケーション間の円滑な連動を可能にするために、受信機はアプリケーションに対してより能動的な制御を行うことができる。
例えば、既存のデータ放送の場合、ユーザが所望しないことからアプリケーションを終了させた場合にも、受信機でアプリケーションに対する制御ができず、アプリケーションに対する通知が再び露出される問題があった。
本発明の一実施例として、図示するように、ユーザの同意と関連して、各放送プログラムはできるだけユーザの放送視聴を妨害してはならないという仮定の下に、ユーザが一度同意した又は同意しなかったアプリケーションに対しては、現在プログラム／現在チャネル／全てのチャネル内では当該同意事項を維持し続けるように設定する方式が用いられてもよい。
本発明の一実施例によれば、同期化されたアプリケーションの使用同意のためのユーザインターフェースは、同期化されたアプリケーション（アプリケーション）を使用（又は、アプリケーションに対する通知表示）に対する同意を設定する項目を含むことができる。
ユーザインターフェースは、アプリケーションの使用に対する同意又は拒否の範囲を定める項目をさらに含むことができる。
例えば、現在プログラムの範囲内でアプリケーションの使用に対する同意／非同意を適用することができる。ユーザが同意した場合、該当の放送プログラムに対してのみユーザの同意が有効であり、該当の放送プログラムが終了すると、該当のアプリケーションに対するユーザ同意インターフェースは初期化されてもよい。ユーザが同意しなかった場合には、該当の放送プログラムに対してのみユーザ非同意が有効であり、該当の放送プログラムが終了すると、該当のアプリケーション使用に対する同意のためのユーザインターフェースは初期化されてもよい。
例えば、現在チャネルの範囲内でアプリケーションの使用に対する同意／非同意を適用することができる。ユーザが同意した場合、該当のチャネルの全ての放送プログラムに対してユーザ同意が有効であり、ユーザがチャネルを変更した場合、該当のアプリケーションに対するユーザ同意インターフェース設定値は初期化されてもよい。ユーザが同意しなかった場合には、該当の放送チャネルに対してのみユーザ非同意が有効であり、放送チャネルが変更されると、該当のアプリケーション使用に対する同意のためのユーザインターフェースは初期化されてもよい。
例えば、全てのアプリケーションの使用に対する同意／非同意を適用することができる。ユーザが同意した場合、全てのチャネルの全ての放送プログラムに対してユーザ同意が有効であり、ユーザが該当のアプリケーションに対するユーザ同意インターフェースメニューで設定値を変更するまで適用されてもよい。ユーザが同意しなかった場合には、ユーザの他の設定があるまでは、全てのアプリケーションがユーザに提供されない。
提示された例示によって、特定設定が選択されたしても、別のユーザ同意インターフェースメニューを提供して、後にユーザがアプリケーションの設定を変えてもよい。
図１３１は、本発明の他の実施例に係る、アプリケーションの使用に対する同意のためのユーザインターフェースを示す図である。
前述したユーザインターフェースに、追加又は変更によって、図示されたようなユーザインターフェースを提供することができる。
図１３１の（ａ）を参照すると、アプリケーションに対する通知が露出された後、受信機はユーザに、一定期間で、アプリケーション通知を遮断するように設定するユーザインターフェース（アプリケーション通知遮断タイマー）を提供することができる。例えば、受信機が提供するアプリケーション通知遮断タイマーは、時間単位（例えば、１５分、３０分）又はプログラム単位（すなわち、現在プログラム終了時までと期間を設定）でアプリケーションに対する通知が遮断されるように設定する項目を含むことができる。
同様に、アプリケーションの使用（又は、アプリケーションに対する通知）に対してユーザが同意しなかったとしても、設定した時間或いは条件を満たす場合、アプリケーションに対する通知を再び露出させることができる。
図１３１の（ｂ）を参照すると、アプリケーションに対する使用（又は、アプリケーションに対する通知）に対するユーザ同意設定の前に、アプリケーションの紹介、アプリケーションの双方向タイムライン（ｉｎｔｅｒａｃｔｉｏｎ ｔｉｍｅｌｉｎｅ）情報、及び／又はアプリケーションの実時間ユーザ統計などのようなアプリケーションの細部情報を見ることのできるリンク（Ｌｉｎｋ）を提供することができる。ユーザは、このリンクから、該当のアプリケーションを使用するか否かを決定するための情報を取得することができる。
図１３２は、本発明の一実施例に係る、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ；ＴＤＯ ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔ）の一部を示す図である。
本発明の一実施例に係るＴＤＯパラメータテーブル（又は、ＴＤＯパラメータエレメント）は、セグメント及び／又はイベントに関連したアプリケーション（又は、ＴＤＯ）に関するメタデータを含んでいる。
ＴＤＯパラメータテーブルは、ＴＰＴエレメント、ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ｉｄエレメント、ｔｐｔＶｅｒｓｉｏｎエレメント、ｅｘｐｉｒｅＤａｔｅエレメント、ｓｅｒｖｉｃｅＩＤエレメント、ｂａｓｅＵＲＬエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＬｉｖｅＴｒｉｇｇｅｒエレメント、ＵＲＬエレメント、ｐｏｌｌＰｅｒｉｏｄエレメント、ＴＤＯエレメント、ａｐｐＩＤエレメント、ａｐｐＴｙｐｅエレメント、ａｐｐＮａｍｅエレメント、ｇｌｏｂａｌＩＤエレメント、ａｐｐＶｅｒｓｉｏｎエレメント、ｃｏｏｋｉｅＳｐａｃｅエレメント、ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメント、ｅｘｐｉｒｅＤａｔｅエレメント、ｔｅｓｔＴＤＯエレメント、ａｖａｉｌＩｎｔｅｒｎｅｔエレメント、ａｖａｉｌＢｒｏａｄｃａｓｔエレメント、ＵＲＬエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＣｏｎｔｅｎｔＩｔｅｍエレメント、ＵＲＬエレメント、ｕｐｄａｔｅｓＡｖａｉｌエレメント、ｐｏｌｌＰｅｒｉｏｄエレメント、Ｓｉｚｅエレメント、ａｖａｉｌＩｎｔｅｒｎｅｔエレメント、ａｖａｉｌＢｒｏａｄｃａｓｔエレメント、Ｅｖｅｎｔエレメント、ｅｖｅｎｔＩＤエレメント、ａｃｔｉｏｎエレメント、ｄｅｓｔｉｎａｔｉｏｎエレメント、ｄｉｆｆｕｓｉｏｎエレメント、及び／又はＤａｔａエレメントを含む。
ＴＰＴエレメントは、ＴＰＴのルートエレメントである。
ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、テーブル定義のメジャーバージョンナンバーを示す。受信機は自分がサポートしないメジャーバージョンナンバーを有するＴＰＴを廃棄することができる。
ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、テーブル定義のマイナーバージョンナンバーを示す。受信機は自分がサポートしないマイナーバージョンナンバーを有するＴＰＴを廃棄しない。この場合、受信機は自分がサポートしない情報又はエレメントを無視してＴＰＴを処理する。
ｉｄエレメントは、ＵＲＩ形態を有することができ、このＴＰＴと関連した双方向プログラミングセグメント（又は、双方向サービスセグメント）を識別する。このｉｄエレメントは、相応するトリガーの‘ｌｏｃａｔｏｒ＿ｐａｒｔ’になってもよい。
ｔｐｔＶｅｒｓｉｏｎエレメントは、ｉｄエレメントによって識別されるＴＰＴのバージョン情報を示す。
ｅｘｐｉｒｅＤａｔｅエレメントは、ＴＰＴインスタンスに含まれた情報の満了日及び時間を示す。受信機がＴＰＴを保存している場合、ｅｘｐｉｒｅＤａｔｅエレメントによる日付及び時間までは当該ＴＰＴを再使用することができる。
ｓｅｒｖｉｃｅＩＤエレメントは、ＴＰＴインスタンスで説明される双方向サービスと関連したＮＲＴサービスの識別子を示す。
ｂａｓｅＵＲＬエレメントは、ＴＰＴに現れる関連ＵＲＬの前端に結合して用いられてもよいベースＵＲＬを示す。ｂａｓｅＵＲＬエレメントは、ファイルの絶対ＵＲＬを示す。
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、ＴＰＴに関連した双方向サービスを表示するために必須な能力を示す。
ＬｉｖｅＴｒｉｇｇｅｒエレメントは、アクチベーショントリガー（Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）がインターネットを介して提供される場合に用いられる情報を含む。ＬｉｖｅＴｒｉｇｇｅｒエレメントは、受信機がアクチベーショントリガーを得るために必要な情報を提供する。
ＵＲＬエレメントは、インターネットでアクチベーショントリガーを送信するサーバーのＵＲＬを示す。アクチベーショントリガーは、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇ、ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇ又はＨＴＴＰ ｓｔｒｅａｍｉｎｇを用いてインターネットで伝送されてもよい。
ｐｏｌｌＰｅｒｉｏｄエレメントが存在すると、アクチベーショントリガーを伝送するためにｓｈｏｒｔ ｐｏｌｌｉｎｇが用いられることを示す。ｐｏｌｌＰｅｒｉｏｄエレメントはｐｏｌｌｉｎｇ周期を示す。
ＴＤＯエレメントは、ＴＰＴインスタンスによって説明されるセグメントの間に、双方向サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）に関する情報を含む。
ａｐｐＩＤエレメントは、ＴＰＴの範囲内でアプリケーション（例えば、ＴＤＯ）を識別する。アクチベーショントリガーは、ａｐｐＩＤエレメントは用いてトリガーを適用するためのターゲットアプリケーションを識別する。
ａｐｐＴｙｐｅエレメントは、アプリケーションのフォーマットタイプを識別する。例えば、ａｐｐＴｙｐｅエレメントの値が‘１’に設定される場合、アプリケーションがＴＤＯであることを示すことができる。
ａｐｐＮａｍｅエレメントは、視聴者のためにディスプレイされる人にとって読み取り可能なアプリケーションの名を示す。
ｇｌｏｂａｌＩＤエレメントは、アプリケーションのグローバル識別子を示す。ｇｌｏｂａｌＩＤエレメントが存在する場合、受信機はアプリケーションコードを保存し、同一又は異なる放送局の将来セグメント内の同じアプリケーションの将来表示のために、当該アプリケーションコードを再使用することができる。
ａｐｐＶｅｒｓｉｏｎエレメントは、アプリケーション（ＴＤＯ）のバージョンナンバーを示す。
ｃｏｏｋｉｅＳｐａｃｅエレメントは、アプリケーション呼び出し（ｉｎｖｏｃａｔｉｏｎｓ）の間で持続してアプリケーションが必要とするデータを保存するために必要な空間の大きさを示す。
ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメントは、放送でどれくらい頻繁にアプリケーションが用いられるかに対する概略的な頻度を示す。例えば、ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメントは、アプリケーションが時間単位、日単位、週単位、月単位で反復的に使われたり、ただ一度だけ用いられるということを示すことができる。
ｅｘｐｉｒｅＤａｔｅエレメントは、受信機がアプリケーション及び／又は関連リソースを安全に削除できる時間及び日付を示す。
ｔｅｓｔＴＤＯエレメントは、アプリケーションがテスト目的で用いられるかを示す。アプリケーションがテスト目的で用いられる場合、一般受信機は、このアプリケーションを無視できる。
ａｖａｉｌＩｎｔｅｒｎｅｔエレメントは、アプリケーションをインターネットでダウンロードできるか否かを示す。
ａｖａｉｌＢｒｏａｄｃａｓｔエレメントは、アプリケーションが放送信号から抽出されるか否かを示す。
ＵＲＬエレメントは、このエレメントのそれぞれのインスタンスがアプリケーションの一部であるファイルを識別する。一つ以上のインスタンスが存在する場合、最初のインスタンスは、エントリポイント（ｅｎｔｒｙ ｐｏｉｎｔ）であるファイルを指定する。エントリポイントであるファイルは、アプリケーションを実行するために実行されなければならないファイルであってもよい。
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、アプリケーションの意味のある表示のために必要な受信機の能力を示す。
ＣｏｎｔｅｎｔＩｔｅｍエレメントは、アプリケーションが必要とする一つ以上のファイルで構成されたコンテンツアイテムに関する情報を含む。ＵＲＬエレメントは、コンテンツアイテムの一部であるファイルを識別する。ＵＲＬエレメントは、コンテンツアイテムが提供されるＵＲＬ情報を識別することができる。一つ以上のインスタンスが存在する場合、最初のインスタンスがエントリポイントであるファイルを指定する。
ｕｐｄａｔｅｓＡｖａｉｌエレメントは、コンテンツアイテムが時々アップデートされるか否かを示す。ｕｐｄａｔｅｓＡｖａｉｌエレメントは、コンテンツアイテムが固定の（ｓｔａｔｉｃ）ファイルで構成されるか否か、実時間データフィード（ＲＴ ｄａｔａ ｆｅｅｄ）であるか否かを示すことができる。
ｐｏｌｌＰｅｒｉｏｄエレメントが存在すると、アクチベーショントリガーを伝送するためにショートポーリングが用いられることを示す。ｐｏｌｌＰｅｒｉｏｄエレメントは、受信機がポーリング周期として用いる時間を示す。
Ｓｉｚｅエレメントは、コンテンツアイテムの大きさを示す。
ａｖａｉｌＩｎｔｅｒｎｅｔエレメントは、コンテンツアイテムがインターネットでダウンロード可能か否かを示す。
ａｖａｉｌＢｒｏａｄｃａｓｔエレメントは、コンテンツアイテムが放送信号から抽出可能か否かを示す。
Ｅｖｅｎｔエレメントは、ＴＤＯのためのイベントに関する情報を含む。
ｅｖｅｎｔＩＤエレメントは、ＴＤＯの範囲内でイベントを識別する役割を担う。アクチベーショントリガーは、トリガーが適用されるターゲットアプリケーション及び／又はイベントを、ａｐｐＩＤエレメントとｅｖｅｎｔＩＤエレメントとの組合せで識別する。
ａｃｔｉｏｎエレメントは、イベントが動作するとき、適用されるべきＴＤＯアクションの種類を示す。アクション値は次のような意味を含むことができる。
“ｒｅｇｉｓｔｅｒ”は、可能な場合、アプリケーションのリソースを取得し、事前保存（ｐｒｅ−ｃａｃｈｅ）することを意味する。
“ｓｕｓｐｅｎｄ−ｅｘｅｃｕｔｅ”は、現在実行されている他のアプリケーションを中断（又は、中止）させ、現在アプリケーションを実行することを意味する。ターゲットアプリケーションが中断された場合、受信機は、以前状態で当該アプリケーションを再開する。
“ｔｅｒｍｉｎａｔｅ−ｅｘｅｃｕｔｅ”は、現在実行されている他のアプリケーションを終了させ、現在アプリケーションを実行することを意味する。ターゲットアプリケーションが中断された場合、受信機は以前状態で当該アプリケーションを再開する。
“ｔｅｒｍｉｎａｔｅ”は、アプリケーションを終了することを意味する。
“ｓｕｓｐｅｎｄ”は、アプリケーション実行を中断することを意味する。ＵＩ及び／又はアプリケーションエンジン状態は、再び実行されるまでに保存されることが要求される。
“ｓｔｒｅａｍ−ｅｖｅｎｔ”は、アプリケーションによって定義される特定行動を適切に行うようにすることを意味する。ｄｅｓｔｉｎａｔｉｏｎエレメントは、イベントのためのターゲット装置タイプを示す。例えば、ｄｅｓｔｉｎａｔｉｏｎエレメントの値によって、メインスクリーン及び／又はセカンダリスクリーンで当該イベントが実行されなければならないことを示すことができる。ｄｅｓｔｉｎａｔｉｏｎエレメントは、プレースホルダー（ｐｌａｃｅ ｈｏｌｄｅｒ）として用いられてもよい。
ｄｉｆｆｕｓｉｏｎエレメントは、サーバーローディングのピークをスムージングするためのパラメータを示す。ｄｉｆｆｕｓｉｏｎエレメントは、周期Ｔを秒単位で示すことができ、受信機は、０秒からＴ秒までの範囲でランダムタイムを計算し、ＴＰＴのＵＲＬによって参照されるコンテンツを得るためにインターネットサーバーにアクセスする前に、計算された時間だけディスプレイを行うことができる。
Ｄａｔａエレメントは、イベントと関連したデータに関する情報を含む。イベントが動作する場合、ターゲットアプリケーションは、このデータを読み、所望の動作を行うために当該データを用いることができる。
本発明の一実施例によれば、前述したアプリケーションの細部情報に対するリンクは、ＴＰＴ（ＴＤＯ Ｐａｒａｍｅｔｅｒｓ Ｔａｂｌｅ）の実施例のように、ＴＤＯに含まれるＣｏｎｔｅｎｔＩｔｅｍエレメントのＵＲＬエレメントに伝達することができる。
アプリケーションの細部情報をアプリケーション内に含まれる一つのコンテンツとして取扱い、該当のコンテンツのリンク情報を提供することができる。
図１３３は、本発明の他の実施例に係る、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒ ｔａｂｌｅ；ＴＤＯ ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔ）の一部を示す図である。
前述した同期化されたアプリケーションの通知の形態及び動作属性を受信機で調節するために、放送局又はコンテンツプロバイダから提供されるアプリケーションの通知と関連した情報は、前述したＴＤＯパラメータエレメントに含まれて伝送されてもよい。すなわち、放送局から提供される同期化されたアプリケーションの通知の形態と動作属性のための情報は、次世代ハイブリッド放送で利用可能なアプリケーションのトリガーのためのパラメータを定義しておいたシグナリングエレメント（例えば、ＴＰＴ）を拡張して受け取ることができる。
これによって、前述したＴＤＯパラメータエレメントにＮｏｔｉｆｉｃａｔｉｏｎＩｎｆｏというエレメントと、それに属する属性（ａｔｔｒｉｂｕｔｅ）をさらに含めることができる。
ＮｏｆｉｃｉａｔｉｏｎＩｎｆｏエレメントの下に追加された属性としては、通知（ｎｏｔｉｆｉｃａｔｉｏｎ）の位置を決定できるｔｏｐＭａｒｇｉｎエレメント及び／又はｒｉｇｈｔＭａｒｇｉｎエレメント、通知のメッセージを示すｍｅｓｓａｇｅエレメント、チャネル別ロゴを示し得るｌｏｇｏエレメント、最初に通知が現れる時間を示し得るｓｈｏｗエレメント、通知の持続時間を示し得るｌａｓｔｉｎｇエレメント、及び／又は通知が現れる周期を設定できるｉｎｔｅｒｖａｌエレメントが含まれてもよい。
すなわち、図示するＴＤＯパラメータエレメントに追加されるエレメントは、次のようなシグナリング情報を含む。
ＮｏｔｉｆｉｃａｔｉｏｎＩｎｆｏエレメントは、同期化されたアプリケーション（例えば、アプリケーション又はＴＤＯ）の通知に対する形態と動作属性に関する情報である。
ｔｏｐＭａｒｇｉｎエレメントは、通知の位置情報を示す属性の一つであり、ｔｏｐ ｍａｒｇｉｎ値を示す。
ｒｉｇｈｔＭａｒｇｉｎエレメントは、通知の位置情報を示す属性の一つであり、ｒｉｇｈｔ ｍａｒｇｉｎ値を示す。
Ｍｅｓｓａｇｅエレメントは、通知に含まれるＷｅｌｃｏｍｅメッセージなどのような情報を含む。
Ｌｏｇｏエレメントは、通知に含まれる各コンテンツプロバイダ或いは放送局別ｌｏｇｏ或いはイメージ情報を含む。ｌｏｇｏイメージの場合、Ｃｏｎｔｅｎｔ ＩｔｅｍのＵＲＬで伝達されてもよい。
Ｓｈｏｗエレメントは、放送プログラム開始後から通知が初めてユーザに見える時間を示す。
Ｌａｓｔｉｎｇエレメントは、通知がユーザに見える持続時間を示す。
Ｉｎｔｅｒｖａｌエレメントは、通知間のｉｎｔｅｒｖａｌ時間であり、ユーザに周期的に通知を表し得る情報を含む。
受信機は、ｔｏｐＭａｒｇｉｎエレメントとｒｉｇｈｔＭａｒｇｉｎエレメントを用いて通知の画面上の位置を設定することができる。受信機は、ｓｈｏｗエレメント、ｌａｓｔｉｎｇエレメント及びｉｎｔｅｒｖａｌエレメントを用いて、各放送プログラムの特性に合わせて、通知がユーザに最初に見える時間とタイミングなどを調節することができる。
同期化されたアプリケーションの通知を実現する主体は受信機となり、不要な視聴情報の流出を防止することができ、受信機がアプリケーションを能動的に制御することが可能である。一方、アプリケーション又はアプリケーションの通知の形態及び／又は動作属性は、コンテンツプロバイダ或いは放送局によって柔軟に運用されてもよい。
一方、前述したエレメントは、受信機で該当の項目の情報を修正することもできる。この場合、放送局又はコンテンツプロバイダから提供された情報を参考用に使用し、受信機でユーザが設定したり、受信機の既に設定された値によって、受信機は該当のエレメントで該当の情報を変更することができる。この場合、アプリケーションの通知の状態を受信機で制御することが可能である。このような情報変更は、ＴＰＴ（又は、ＴＤＯ ｐａｒａｍｅｔｅｒエレメント）があらかじめ受信機に伝送されて保存されており、受信機が保存された情報を変更することから可能である。
図１３４は、本発明の一実施例に係る、ＮｏｔｉｆｉｃａｔｉｏｎＩｎｆｏエレメントの情報を用いて同期化されたアプリケーションの通知が表示された画面を示す図である。
図面を参照すると、通知の位置は、画面上、上（ｔｏｐ）から５００ピクセル、右（ｒｉｇｈｔ）から４０ピクセル離れて位置することができる。通知に含まれるメッセージは、“Ｅｎｊｏｙ ＭＢＣ Ｑｕｉｚ！”となっている。Ｓｈｏｗエレメントとｌａｓｔｉｎｇエレメントの設定値によって、通知は、ユーザにアプリケーションに対する通知が実行されて１２０秒後に最初に露出されてもよく、露出された通知に対してユーザが何ら動作を取らない場合、ｌａｓｔｉｎｇエレメントの設定値である１５秒後に通知が消えてもよい。そして、ｉｎｔｅｒｖａｌエレメントの設定値によって、通知が消えて３００秒後に再びユーザに通知が露出されてもよい。通知露出時間に関連した設定値は、最初に同期化されたアプリケーションが実行された時点を基準にした相対的な時間値である。
図１３５は、本発明の一実施例に係る、放送サーバー及び受信機を示す図である。
本発明の一実施例に係る受信機は、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）Ｊ１０７０２０、アプリケーションマネジャー（Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｒ）Ｊ１０７０３０、ダウンロードマネジャー（Ｄｏｗｎｌｏａｄ Ｍａｎａｇｅｒ）Ｊ１０７０６０、装置保存所（Ｄｅｖｉｃｅ Ｓｔｏｒａｇｅ）Ｊ１０７０７０、及び／又はアプリケーションデコーダ（Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｃｏｄｅｒ）Ｊ１０７０８０を含む。放送サーバーは、コンテンツプロバイダ／放送局１０７０１０及び／又はアプリケーションサービスサーバーＪ１０７０５０を含む。
放送サーバー又は受信機に含まれるそれぞれの装置は、ハードウェア又はソフトウェアによって実装することができる。各装置がハードウェアによって実装される場合、‘マネジャー’のような表現は‘プロセッサ’に代替してもよい。
コンテンツプロバイダ／放送局Ｊ１０７０１０は、コンテンツプロバイダ或いは放送局を示す。
シグナリングパーサー １０７０２０は、コンテンツプロバイダ或いは放送局で提供する放送信号をパースするモジュールである。放送信号は、シグナリングデータ／エレメント、放送コンテンツデータ、放送と関連した付加データ、及び／又はアプリケーションデータを含むことができる。
アプリケーションマネジャーＪ１０７０３０は、放送信号にアプリケーションが含まれた場合、当該アプリケーションを管理するモジュールである。アプリケーションマネジャーＪ１０７０３０は、前述したシグナリング情報、シグナリングエレメント、ＴＰＴ及び／又はトリガーを用いて、アプリケーションの位置、動作、動作実行タイミングを制御する。ここで、アプリケーションの動作は、Ａｃｔｉｖａｔｅ（Ｌａｕｎｃｈ）、Ｓｕｓｐｅｎｄ、Ｒｅｓｕｍｅ、又はＴｅｒｍｉｎａｔｅ（Ｅｘｉｔ）であってもよい。
アプリケーションサービスサーバーＪ１０７０５０は、アプリケーションを提供するサーバーである。アプリケーションサービスサーバーＪ１０７０５０は、コンテンツプロバイダ或いは放送局で提供されてもよく、この場合、コンテンツプロバイダ／放送局Ｊ１０７０１０に含まれればよい。
ダウンロードマネジャーＪ１０７０６０は、コンテンツプロバイダ／放送局Ｊ１０７０１０、及び／又はアプリケーションサービスサーバーＪ１０７０５０で提供するＮＲＴコンテンツ又はアプリケーションと関連した情報を処理するモジュールである。ダウンロードマネジャーＪ１０７０６０は、放送信号に含まれたＮＲＴ関連シグナリング情報を取得し、シグナリング情報に基づいて、放送信号に含まれたＮＲＴコンテンツを抽出する。ダウンロードマネジャーＪ１０７０６０は、アプリケーションサービスサーバーＪ１０７０５０が提供するアプリケーションを受信処理することができる。
装置保存所Ｊ１０７０７０は、受信した放送信号、データ、コンテンツ及び／又はシグナリング情報（シグナリングエレメント）を保存することができる。
アプリケーションデコーダＪ１０７０８０は、受信したアプリケーションをデコードし、画面に表示する処理を行うことができる。
図１３６は、本発明の一実施例に係る、アプリケーションに関連した属性情報を示す図である。
アプリケーションに関連した属性情報は、ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を含むことができる。
本発明の一実施例によって追加可能なアプリケーションと関連した属性情報は、Ａｐｐｌｉｃａｔｉｏｎ ＩＤ情報、Ａｐｐｌｉｃａｔｉｏｎバージョン情報、Ａｐｐｌｉｃａｔｉｏｎ ｔｙｐｅ情報、Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報、Ｃａｐａｂｉｌｉｔｉｅｓ情報、Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報、Ｆｒｅｑｕｅｎｃｙ ｏｆ ｕｓｅ情報、Ｅｘｐｉｒａｔｉｏｎ ｄａｔｅ情報、Ｄａｔａ ｉｔｅｍ ｎｅｅｄｅｄ ｂｙ ａｐｐｌｉｃａｉｏｎ情報、Ｓｅｃｕｒｉｔｙ ｐｒｏｐｅｒｔｉｅｓ情報、Ｔａｒｇｅｔ ｄｅｖｉｃｅｓ情報、及び／又はＣｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を含むことができる。
Ａｐｐｌｉｃａｔｉｏｎ ＩＤ情報は、アプリケーションを識別できる固有のＩＤを示す。
Ａｐｐｌｉｃａｔｉｏｎバージョン情報は、アプリケーションのバージョンを示す。
Ａｐｐｌｉｃａｔｉｏｎ ｔｙｐｅ情報は、アプリケーションのタイプを示す。
Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報は、アプリケーションの位置を示す。例えば、Ａｐｐｌｉｃａｔｉｏｎ ｌｏｃａｔｉｏｎ情報は、アプリケーションを受信できるＵＲＬを含むことができる。
Ｃａｐａｂｉｌｉｔｉｅｓ情報は、アプリケーションをレンダ（ｒｅｎｄｅｒ）可能にするｃａｐａｂｉｌｉｔｙ属性を示す。
Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報は、放送ストリーミングとアプリケーション間の同期化レベル情報を示す。例えば、Ｒｅｑｕｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌｅｖｅｌ情報は、プログラム或いはイベント単位、時間単位（例えば、２秒以内）、リップシンク（ｌｉｐ ｓｙｎｃ）、及び／又はフレームレベル同期化などの内容を示すことができる。
Ｆｒｅｑｕｅｎｃｙ ｏｆ ｕｓｅ情報は、アプリケーションの使用頻度を示す。
Ｅｘｐｉｒａｔｉｏｎ ｄａｔｅ情報は、アプリケーションの使用満了日／満了時刻を示す。
Ｄａｔａ ｉｔｅｍ ｎｅｅｄｅｄ ｂｙ ａｐｐｌｉｃａｉｏｎ情報は、アプリケーションで用いるｄａｔａ情報を示す。
Ｓｅｃｕｒｉｔｙ ｐｒｏｐｅｒｔｉｅｓ情報は、アプリケーションのセキュリティ関連情報を示す。
Ｔａｒｇｅｔ ｄｅｖｉｃｅｓ情報は、アプリケーションが用いられるターゲット装置情報を示す。例えば、Ｔａｒｇｅｔ ｄｅｖｉｃｅｓ情報は、当該アプリケーションの実行されるターゲット機器がＴＶ及び／又はモバイル機器であることを示すことができる。
Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、アプリケーションを使用できる等級を示す。例えば、Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、アプリケーションを利用可能な年齢制限情報を含むことができる。
図１３７は、本発明の一実施例に係る、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメント内のＲａｔｅｄ＿ｄｉｍｅｎｓｉｏｎエレメントを示す図である。
Ｒａｔｅｄ＿ｄｉｍｅｎｓｉｏｎエレメントは、各国家別にあらかじめ定義された、ｒａｔｉｎｇ領域の個数を示すことができる。図示するように、ｒａｔｉｎｇ＿ｒｅｇｉｏｎによって定義された米国の場合は８個、ｒａｔｉｎｇ＿ｒｅｇｉｏｎによって定義されたカナダの場合は２個のｒａｔｉｎｇ領域を有する。
図１３８は、本発明の一実施例に係る、ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報（ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメント）を含むＴＰＴを示す図である。
受信機は、ユーザがＴＶに設定したｒａｔｉｎｇ情報に基づいて、放送局から提供された同期化されたアプリケーションが受信機で利用可能なものか否かを決定することができる。
次世代ハイブリッド放送で使用可能なアプリケーション（例えば、ＴＤＯなど）は、設定されたｒａｔｉｎｇ情報によって、コンテンツを構成した後にアプリサービスとして提供されてもよい。
ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、放送信号に含まれてシグナリング情報として伝送されてもよい。又はｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報は、前述したＴＰＴに含まれてもよい。
ＴＰＴにｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を含めるために、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメントをＴＰＴで追加的にシグナルしてもよい。
ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメントは、与えられたＣｏｎｔｅｎｔＩｔｅｍ又はイベントのｒａｔｉｎｇ情報を含んでおり、この値は、ＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）に宣言された各領域（ｒｅｇｉｏｎ）別ｒａｔｉｎｇ情報と同じ値を有することができる。
ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報をＴＰＴに含めるために、後述されるエレメントのいずれか一つ以上のエレメントがＴＰＴでシグナルされてもよい。
ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｄエレメントは、ＴＤＯ ｅｌｅｍｅｎｔのｓｃｏｐｅで一意にＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏを認識できる識別子を示す。
ｒａｔｉｎｇ＿ｒｅｇｉｏｎエレメントは、レーティング領域（ｒａｔｉｎｇ ｒｅｇｉｏｎ）を示す、例えば、ｒａｔｉｎｇ＿ｒｅｇｉｏｎエレメントの値が１であれば、米国、２であればカナダ、を示すことができる。
ｒａｔｉｎｇ＿ｄｅｓｃｒｉｐｔｉｏｎエレメントは、ｒａｔｉｎｇ値を短縮した（ａｂｂｒｅｖｉａｔｅｄ）形態で表現したテキストを含む。
Ｒａｔｅｄ＿ｄｉｍｅｎｓｉｏｎエレメントは、各国家別にあらかじめ定義された、ｒａｔｉｎｇ領域の個数を示すことができる。
ｒａｔｉｎｇ＿ｄｉｍｅｎｓｉｏｎエレメントは、ＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）情報に存在するディメンションインデックス（ｄｉｍｅｎｓｉｏｎ ｉｎｄｅｘ）を示す。
ｒａｔｉｎｇ＿ｖａｌｕｅエレメントは、ｒａｔｉｎｇ＿ｄｉｍｅｎｓｉｏｎエレメントで示すディメンションのｒａｔｉｎｇ値を示す。例えば、ディメンションによってＴＶ−Ｇ、ＴＶ−ＰＧなどの値を有することができる。
ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｄエレメントは、ＴＤＯエレメント、ＣｏｎｔｅｎｔＩｔｅｍエレメント又はＥｖｅｎｔエレメントに追加されてもよい。したがって、ｒａｔｉｎｇ情報はＴＤＯ全体に適用されてもよく、ＣｏｎｔｅｎｔＩｔｅｍごとに適用されてもよく、又は個別イベントごとに適用されてもよい。該当のエレメントにｒａｔｉｎｇ情報がない場合は、デフォルトとして０を有し、ｒａｔｉｎｇ情報と関連する場合には、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメントの下位にｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｄエレメントの値を有する。
図１３９は、本発明の一実施例に係る、ｒａｔｉｎｇ値を取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を示す図である。
ＴＶに設定されたｒａｔｉｎｇ値をアプリケーション（又は、ＴＤＯ）から取得するためにはアプリケーションのためのＡＰＩが必要である。
図示されるように、ｒａｔｉｎｇ値を取得する関数を、既存の放送システムのためのＡＰＩに追加することができる。
アプリケーションは、ＡＰＩにｒａｔｉｎｇ＿ｒｅｇｉｏｎの情報を提供することによって、ユーザが設定したｒａｔｉｎｇ情報値を得る。受信機に保存されたｒａｔｉｎｇ情報値は、前述したＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＩｎｆｏエレメントに伝達されてもよい。
本発明の説明は、明瞭化のために、添付の図面のそれぞれを参照して説明するが、添付の図面に示す実施例を併合することによって新しい実施例を設計することもできる。以上の説明で言及した実施例を実行するプログラムが記録されたコンピュータ読み取り可能記録媒体が当業者の必要によって設計されると、これも、添付した請求範囲及びその均等物の範囲に属することができる。
本発明に係る装置及び方法は、以上の説明で言及された実施例の構成及び方法によって制限されない。以上の説明で言及された実施例は、全体的に又は部分的に互いに選択的に結合される方式で構成され、様々な変形が可能である。
また、本発明に係る方法は、ネットワーク装置に提供されるプロセッサ読み取り可能記録媒体でプロセッサ読み取り可能コードとして実装することができる。プロセッサ読み取り可能媒体は、プロセッサによって読み取り可能なデータを記憶できるいかなる種類の記録装置も含むことができる。プロセッサ読み取り可能記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で実装されるものも含む。また、プロセッサ読み取り可能記録媒体は、ネットワークを介して接続されたコンピュータシステムに分散され、分散方式でプロセッサ読み取り可能コードが記憶されて実行されてもよい。
当業者は、本発明の思想及び範囲から逸脱することなく本発明の様々な変形及び変更が可能であることが理解できる。したがって、本発明は、添付した特許請求の範囲及びその均等物の範囲内で提供される本発明の変形及び変更をカバーする。
装置及び方法発明が本明細書に言及されており、それらの装置及び方法発明の説明は相互補完的に適用されてもよい。
様々な実施例が、本発明を実施するための形態において記載された。
本発明は、放送信号提供フィールドで有用である。本発明の思想又は範囲から逸脱することく本発明の様々な変形及び変更が可能であるということは当業者にとって自明である。したがって、本発明は、添付した特許請求の範囲及びその均等物の範囲内で提供される本発明の変形及び変更をいずれもカバーするように意図される。

Claims (14)

  1. 放送コンテンツ及び前記放送コンテンツに関連したアプリケーションを含む放送信号を処理する受信機であって、
    前記受信機によって回答可能な個別質問を示す質問表をカプセル化するデータ構造を受信する受信装置であって、前記データ構造が前記アプリケーションを一意に識別する第１アプリケーション識別子を含む、受信装置と、
    前記データ構造から前記質問表を取得し、前記アプリケーション識別子によって識別された前記アプリケーションに対するユーザの設定オプションを受信し、前記データ構造に関連して前記設定オプションを保存するＰＤＩエンジンと、
    前記アプリケーションの再生（ｐｌａｙｏｕｔ）のタイミングを確立するためのシグナリングエレメントであるトリガーをパースするアプリケーションシグナリングパーサーと、
    前記トリガーから第２アプリケーション識別子をパースし、前記第１アプリケーション識別子の値が前記第２アプリケーション識別子の値にマッチする前記データ構造と関連して前記保存された設定オプションを取得し、前記設定オプションに基づいて前記アプリケーションを起動（ｌａｕｎｃｈ）する処理か否かを決定するプロセッサと、
    を含む、受信機。
  2. 前記トリガーは、前記アプリケーションを対象にするアプリケーション及び放送イベントに関するメタデータを含むＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）パラメータエレメントの位置を特定する位置情報を含む、請求項１に記載の受信機。
  3. 前記位置情報によって識別された前記位置から前記ＴＤＯパラメータエレメントをパースするアプリケーションシグナリングパーサーをさらに含み、
    前記ＴＤＯパラメータエレメントは、前記アプリケーションに対する通知の上部マージンを特定する上部マージン情報、前記通知の右側マージンを特定する右側マージン情報、及び前記通知に対する持続時間を特定する持続情報を含む、請求項２に記載の受信機。
  4. 前記プロセッサはさらに、前記上部マージン情報、右側マージン情報及び持続情報に基づいて、前記ユーザから前記設定オプションを受信するユーザインターフェースをディスプレイする、請求項３に記載の受信機。
  5. 前記プロセッサはさらに、前記アプリケーションが活性化されるか否かに関する第１選択に対する質問を示すために前記ユーザインターフェースを処理する、請求項４に記載の受信機。
  6. 前記プロセッサはさらに、前記第１選択が現在の放送コンテンツ、現在のチャネル内の全放送コンテンツ又は全チャネル内の全放送コンテンツに適用されるかに関する第２選択に対する質問を示すために前記ユーザインターフェースを処理する、請求項５に記載の受信機。
  7. 前記ＴＤＯパラメータエレメントは、前記アプリケーションに対するレーティング（ｒａｔｉｎｇ）を特定するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）情報を含む、請求項２に記載の受信機。
  8. 放送コンテンツ及び前記放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法であって、
    受信機によって回答可能な個別質問を示す質問表をカプセル化するデータ構造を受信するステップであって、前記データ構造が前記アプリケーションを一意に識別する第１アプリケーション識別子を含む、ステップと、
    前記データ構造から前記質問表を取得し、前記アプリケーション識別子によって識別された前記アプリケーションに対するユーザの設定オプションを受信し、前記データ構造と関連して前記設定オプションを保存するステップと、
    前記アプリケーションの再生のタイミングを確立するためのシグナリングエレメントであるトリガーをパースするステップと、
    前記トリガーから第２アプリケーション識別子をパースし、前記第１アプリケーション識別子の値が前記第２アプリケーション識別子の値にマッチする前記データ構造と関連して前記保存された設定オプションを取得し、前記設定オプションに基づいて前記アプリケーションを起動する処理か否かを決定するステップと、
    を含む、方法。
  9. 前記トリガーは、前記アプリケーションを対象にするアプリケーション及び放送イベントに関するメタデータを含むＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）パラメータエレメントの位置を特定する位置情報を含む、請求項８に記載の方法。
  10. 前記位置情報によって識別された前記位置から前記ＴＤＯパラメータエレメントをパースするステップをさらに含み、
    前記ＴＤＯパラメータエレメントは、前記アプリケーションに対する通知の上部マージンを特定する上部マージン情報、前記通知の右側マージンを特定する右側マージン情報、及び前記通知に対する持続時間を特定する持続情報を含む、請求項９に記載の方法。
  11. 前記上部マージン情報、右側マージン情報及び持続情報に基づいて、前記ユーザから前記設定オプションを受信するユーザインターフェースをディスプレイするステップをさらに含む、請求項１０に記載の方法。
  12. 前記アプリケーションが活性化されるか否かに関する第１選択に対する質問を示すために前記ユーザインターフェースを処理するステップをさらに含む、請求項１１に記載の方法。
  13. 前記第１選択が現在の放送コンテンツ、現在のチャネル内の全放送コンテンツ又は全チャネル内の全放送コンテンツに適用されるかに関する第２選択に対する質問を示すために前記ユーザインターフェースを処理するステップをさらに含む、請求項１２に記載の方法。
  14. 前記ＴＤＯパラメータエレメントは、前記アプリケーションに対するレーティング（ｒａｔｉｎｇ）を特定するコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）情報を含む、請求項９に記載の方法。
JP2016537968A 2013-12-09 2014-12-09 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置 Expired - Fee Related JP6189546B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361913877P 2013-12-09 2013-12-09
US61/913,877 2013-12-09
US201461940498P 2014-02-17 2014-02-17
US61/940,498 2014-02-17
PCT/KR2014/012051 WO2015088217A1 (en) 2013-12-09 2014-12-09 A receiver and a method for processing a broadcast signal including a broadcast content and an application related to the broadcast content

Publications (2)

Publication Number Publication Date
JP2017505564A JP2017505564A (ja) 2017-02-16
JP6189546B2 true JP6189546B2 (ja) 2017-08-30

Family

ID=53371453

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016537968A Expired - Fee Related JP6189546B2 (ja) 2013-12-09 2014-12-09 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置

Country Status (6)

Country Link
US (1) US20160269786A1 (ja)
EP (1) EP3080994A4 (ja)
JP (1) JP6189546B2 (ja)
KR (1) KR20160083107A (ja)
CN (1) CN105814897A (ja)
WO (1) WO2015088217A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2944773A1 (en) * 2014-04-11 2015-10-15 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
EP3160153B1 (en) 2014-06-20 2020-10-28 Sony Corporation Reception device, reception method, transmission device, and transmission method
KR101995197B1 (ko) 2015-03-02 2019-09-30 닛본 덴끼 가부시끼가이샤 디코딩 장치, 수신기기, 송신기기, 송수신 시스템, 디코딩 방법, 및 디코딩 프로그램이 저장된 저장매체
MX371468B (es) 2015-03-02 2020-01-29 Nec Corp Dispositivo de descodificación, dispositivo de recepción, dispositivo de transmisión, sistema de transmisión/recepción, método de descodificación y medio de almacenamiento que tiene programa de descodificación almacenado en el mismo.
JP6390518B2 (ja) * 2015-05-29 2018-09-19 京セラドキュメントソリューションズ株式会社 情報処理装置
CA3028354C (en) * 2016-07-05 2021-02-16 Sharp Kabushiki Kaisha Systems and methods for communicating user settings in conjunction with execution of an application
US10111063B1 (en) * 2017-03-31 2018-10-23 Verizon Patent And Licensing Inc. System and method for EUICC personalization and network provisioning
BE1024798B1 (nl) * 2017-04-27 2018-07-02 Televic Healthcare Nv Een waarschuwingssysteem en werkwijze voor berichtgeving met betrekking tot een alarm
CN108966259B (zh) * 2018-07-18 2021-07-16 中国电子科技集团公司第二十八研究所 一种基于网络编码的抗干扰传输方法

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060282319A1 (en) * 2000-10-12 2006-12-14 Maggio Frank S Method and system for substituting media content
US20030009769A1 (en) * 2001-06-25 2003-01-09 Debra Hensgen Trusted application level resource advisor
US20030182371A1 (en) * 2001-10-15 2003-09-25 Worthen William C. Asynchronous, leader-facilitated, collaborative networked communication system
US7634795B2 (en) * 2002-01-11 2009-12-15 Opentv, Inc. Next generation television receiver
US7055169B2 (en) * 2002-04-19 2006-05-30 Opentv, Inc. Supporting common interactive television functionality through presentation engine syntax
US8424034B2 (en) * 2002-05-03 2013-04-16 Disney Enterprises, Inc. System and method for displaying commercials in connection with an interactive television application
US8082563B2 (en) * 2003-07-25 2011-12-20 Home Box Office, Inc. System and method for content access control through default profiles and metadata pointers
JP2005338959A (ja) * 2004-05-24 2005-12-08 Sony Corp 情報処理装置，実行判定方法，およびコンピュータプログラム
JP4777725B2 (ja) * 2005-08-31 2011-09-21 フェリカネットワークス株式会社 携帯端末装置，サーバ装置，アプリケーション提供方法およびコンピュータプログラム
JP2009141520A (ja) * 2007-12-04 2009-06-25 Softbank Mobile Corp 通信端末におけるアプリケーション起動方法、通信端末及びサーバ
JP5116492B2 (ja) * 2008-01-15 2013-01-09 三菱電機株式会社 アプリケーション実行端末
WO2009151267A2 (ko) * 2008-06-09 2009-12-17 엘지전자(주) 서비스 제공 방법 및 방송 수신기
WO2009151266A2 (ko) * 2008-06-09 2009-12-17 엘지전자(주) 서비스 제공 방법 및 모바일 방송 수신기
CA2798427C (en) * 2009-05-08 2018-01-23 Obdedge, Llc Systems, methods, and devices for policy-based control and monitoring of use of mobile devices by vehicle operators
US9723360B2 (en) * 2010-04-01 2017-08-01 Saturn Licensing Llc Interests and demographics profile for advanced broadcast services
US8583149B2 (en) * 2010-04-07 2013-11-12 Apple Inc. Registering email addresses for online communication sessions
US8704863B2 (en) * 2010-04-07 2014-04-22 Apple Inc. Transitioning between circuit switched calls and video calls
US20110298981A1 (en) * 2010-06-07 2011-12-08 Mark Kenneth Eyer Scripted Access to Hidden Multimedia Assets
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
JP5765558B2 (ja) * 2010-08-27 2015-08-19 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、プログラム、および放送システム
US9179188B2 (en) * 2010-08-30 2015-11-03 Sony Corporation Transmission apparatus and method, reception apparatus and method, and transmission and reception system
US8892636B2 (en) * 2010-08-30 2014-11-18 Sony Corporation Transmission apparatus and method, reception apparatus and method, and transmission and reception system
CA2823037C (en) * 2010-12-26 2016-05-24 Lg Electronics Inc. Method for transmitting a broadcast service, and method and apparatus for receiving same
US20120185888A1 (en) * 2011-01-19 2012-07-19 Sony Corporation Schema for interests and demographics profile for advanced broadcast services
US9554175B2 (en) * 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction
US10491966B2 (en) * 2011-08-04 2019-11-26 Saturn Licensing Llc Reception apparatus, method, computer program, and information providing apparatus for providing an alert service
WO2013022309A1 (ko) * 2011-08-10 2013-02-14 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
KR101767301B1 (ko) * 2011-09-09 2017-08-10 라쿠텐 인코포레이티드 대화형 텔레비전 노출에 대한 소비자 제어를 위한 시스템들 및 방법들
US9936231B2 (en) * 2012-03-21 2018-04-03 Saturn Licensing Llc Trigger compaction
KR101832781B1 (ko) * 2014-06-03 2018-02-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Also Published As

Publication number Publication date
KR20160083107A (ko) 2016-07-11
US20160269786A1 (en) 2016-09-15
EP3080994A1 (en) 2016-10-19
WO2015088217A1 (en) 2015-06-18
JP2017505564A (ja) 2017-02-16
EP3080994A4 (en) 2017-07-26
CN105814897A (zh) 2016-07-27

Similar Documents

Publication Publication Date Title
US11265619B2 (en) Method for transmitting broadcast signals and method for receiving broadcast signals
JP6474835B2 (ja) ハイブリッド放送サービスを処理する装置、及びハイブリッド放送サービスを処理する方法
JP6189546B2 (ja) 放送コンテンツ及び放送コンテンツに関連したアプリケーションを含む放送信号を処理する方法及び装置
JP6348184B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
KR101832781B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US9866908B2 (en) Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
KR101923459B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR20160091421A (ko) 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법
KR101902409B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP2017508326A (ja) 放送伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170622

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170725

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170802

R150 Certificate of patent or registration of utility model

Ref document number: 6189546

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees