JP6294503B2 - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 - Google Patents

放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Info

Publication number
JP6294503B2
JP6294503B2 JP2016555355A JP2016555355A JP6294503B2 JP 6294503 B2 JP6294503 B2 JP 6294503B2 JP 2016555355 A JP2016555355 A JP 2016555355A JP 2016555355 A JP2016555355 A JP 2016555355A JP 6294503 B2 JP6294503 B2 JP 6294503B2
Authority
JP
Japan
Prior art keywords
information
service
content
watermark
server
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
JP2016555355A
Other languages
English (en)
Other versions
JP2017522742A (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 JP2017522742A publication Critical patent/JP2017522742A/ja
Application granted granted Critical
Publication of JP6294503B2 publication Critical patent/JP6294503B2/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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H04N19/467—Embedding additional information in the video signal during the compression process characterised by the embedded information being invisible, e.g. watermarking
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/233—Processing of audio elementary streams
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/233—Processing of audio elementary streams
    • H04N21/2335—Processing of audio elementary streams involving reformatting operations of audio signals, e.g. by converting from one coding standard to another
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2665—Gathering content from different sources, e.g. Internet and satellite
    • 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/439—Processing of audio elementary streams
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • 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/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • H04N21/4725—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content using interactive regions of the image, e.g. hot spots
    • 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/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • 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/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Description

本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
アナログ放送信号送信が終了することにより、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べて、より多量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータの他、種々の付加データも含むことができる。
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ ｃｈａｎｎｅｌ：多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）が向上する必要がある。
本発明の目的によって、ここに含まれ、概略的に記載されるように、本発明は、地上波放送網及びインターネット網を使用する次世代ハイブリッド放送を支援する環境で、次世代放送サービスを効果的に支援することができるシステム及び関連したシグナリング方案を提案する。
本発明は、地上波放送網及びインターネット網を使用する次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。また、本発明は、ビデオＷＭ、オーディオＷＭを効率的に活用するための構造及び方案を提案する。
本発明の更なる理解を提供するために含まれ、本出願に含まれてその一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に、本発明の実施例を示す。
本発明の一実施例に係るプロトコルスタックを示す図である。 本発明の一実施例に係るサービスディスカバリ手続を示す図である。 本発明の一実施例に係るＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）を示す図である。 本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。 本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。 本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）動作を示す図である。 本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）を示す図である。 本発明の一実施例に係るネットワークトポロジを示すブロック図である。 本発明の一実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。 本発明の一実施例に係るウォーターマークベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。 本発明の一実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す図である。 本発明の一実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。 本発明の一実施例に係るフィンガープリントベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。 本発明の一実施例に係る質疑結果が含まれるＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキマーダイヤグラム（ｓｃｈｅｍａ ｄｉａｇｒａｍ）を示す図である。 本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。 本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。 本発明の実施例に係る映像表示装置のブロック図である。 本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示すフローチャートである。 本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示す概念図である。 本発明の他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。 本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。 本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータを例示する図である。 本発明の一実施例に係るタイムスタンプタイプフィールドの各値の意味を示す図である。 本発明の一実施例に係るＵＲＬプロトコルタイプフィールドの各値の意味を示す図である。 本発明の一実施例に係るＵＲＬプロトコルタイプフィールドの処理手続を示すフロ−チャ−トである。 本発明の一実施例に係るイベントフィールドの各値の意味を示す図である。 本発明の一実施例に係るデスティネーションタイプフィールドの各値の意味を示す図である。 本発明の実施例＃１によるＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃１によるＷＭに挿入されるデータ構造を処理する順序図である。 本発明の実施例＃２によるＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃２によるＷＭに挿入されるデータ構造を処理する順序図である。 本発明の実施例＃３によるＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃４によるＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃４において、１番目のＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃４において、２番目のＷＭに挿入されるデータ構造を示す図である。 本発明の実施例＃４によるＷＭに挿入されるデータ構造を処理する順序図である。 本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。 フィンガープリンティング方式において、本発明の一実施例に係るデータ構造を示す図である。 フィンガープリンティング方式において、本発明の一実施例に係るデータ構造を処理する順序図である。 本発明の他の実施例に係るウォーターマークペイロードの構造を示す図である。 本発明の一実施例に係る、サービス／コンテンツ情報を用いたウォーターマークペイロード構造の変形を示す図である。 本発明の一実施例に係る、ＮＳＣフィールドを用いたウォーターマークペイロード構造の変形を示す図である。 本発明の一実施例に係る、ビデオ−オーディオウォーターマーク間のリンキング（ｌｉｎｋｉｎｇ）のためのウォーターマークペイロード構造を示す図である。 本発明の一実施例に係る、リンクされたビデオ−オーディオウォーターマークを用いた動作を示す図である。 本発明の一実施例に係る放送コンテンツ処理方法を示す図である。 本発明の一実施例に係る放送コンテンツ処理装置を示す図である。
本発明の好適な実施例について具体的に説明し、その例を添付の図面に示す。添付の図面を参照した下記の詳細な説明は、本発明の具現可能な実施例を限定するものではなく、本発明の好適な実施例を説明するためのものである。下記の詳細な説明は、本発明に関する徹底した理解を提供するために細部事項を含む。しかし、当業者にとってはこれらの細部事項無しにも本発明の実行が可能であるということは明らかである。
本発明で使われる大部分の用語は、当該分野で広く使われる一般的なものから選択されるが、一部の用語は出願人によって任意に選択されてもよく、その意味は、必要時に次の説明で詳しく説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語の意図された意味に基づいて理解しなければならない。
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置並びに方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）又はＭＩＭＯ方式によって次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式などを含むことができる。
図１は、本発明の一実施例に係るプロトコルスタックを示す図である。
サービスを複数個のレイヤを経て受信機に伝達することができる。まず、送信側ではサービスデータを生成することができる。送信側のデリバリレイヤでは、サービスデータに、伝送のための処理を行い、フィジカルレイヤでは、これを放送信号にエンコードして、放送網又はブロードバンドを介して伝送することができる。
ここで、サービスデータは、ＩＳＯ ＢＭＦＦ（ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔ）によるフォーマットで生成することができる。ＩＳＯ ＢＭＦＦメディアファイルは、放送網／ブロードバンドデリバリ、メディアエンカプセレーション（ｍｅｄｉａ ｅｎｃａｐｓｕｌａｔｉｏｎ）及び／又は同期化フォーマット（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｆｏｒｍａｔ）で用いることができる。ここで、サービスデータは、サービスに関連した全てのデータであり、リニアサービスを構成するサービスコンポーネント、それに対するシグナリング情報、ＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）データ、その他のファイルなどを含む概念であってもよい。
デリバリレイヤについて説明する。デリバリレイヤはサービスデータに対する伝送機能を提供することができる。サービスデータは、放送網及び／又はブロードバンドを介して伝達することができる。
放送網を介したサービスデリバリ（ｂｒｏａｄｃａｓｔ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）において、２つの方法を挙げることができる。
第一の方法は、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）に基づいて、サービスデータをＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ）として処理し、これをＭＭＴＰ（ＭＭＴ ｐｒｏｔｏｃｏｌ）を用いて伝送することができる。この場合、ＭＭＴＰによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント及び／又はそれに関するサービスシグナリング情報などを含むことができる。
第二の方法は、ＭＰＥＧ ＤＡＳＨに基づいて、サービスデータをＤＡＳＨセグメントとして処理し、これをＲＯＵＴＥ（Ｒｅａｌ ｔｉｍｅ Ｏｂｊｅｃｔ ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を用いて伝送することができる。この場合、ＲＯＵＴＥプロトコルによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。すなわち、ＮＲＴデータ及びファイルなどのノンタイムド（ｎｏｎ ｔｉｍｅｄ）データは、ＲＯＵＴＥを用いて伝達することができる。
ＭＭＴＰ又はＲＯＵＴＥプロトコルによって処理されたデータは、ＵＤＰ／ＩＰレイヤを経てＩＰパケットとして処理することができる。放送網を介したサービスデータ伝達において、ＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）もＵＤＰ／ＩＰレイヤを経て放送網を介して伝達することができる。ＳＬＴは、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブルに含めて伝達することができる。ＳＬＴ、ＬＬＳテーブルについては後述する。
ＩＰパケットはリンクレイヤでリンクレイヤパケットとして処理されてもよい。リンクレイヤは、上位レイヤから伝達される様々なフォーマットのデータを、リンクレイヤパケットとしてエンカプセレーションした後、フィジカルレイヤに伝達することができる。リンクレイヤについては後述する。
ハイブリッドサービスデリバリ（ｈｙｂｒｉｄ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）においては、少なくとも１つのサービスエレメントをブロードバンドパス（ｐａｔｈ）を通じて伝達することができる。ハイブリッドサービスデリバリの場合、ブロードバンドで伝達されるデータは、ＤＡＳＨフォーマットのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。これらのデータはＨＴＴＰ／ＴＣＰ／ＩＰを経て処理され、ブロードバンド伝送のためのリンクレイヤを経て、ブロードバンド伝送のためのフィジカルレイヤに伝達されてもよい。
フィジカルレイヤは、デリバリレイヤ（上位レイヤ及び／又はリンクレイヤ）から伝達されたデータを処理して、放送網又はブロードバンドを介して伝送することができる。フィジカルレイヤに関する詳細な事項は後述する。
サービスについて説明する。サービスは、全体的にユーザに示すサービスコンポーネントのコレクションであり、コンポーネントは、様々なメディアタイプのものであり、サービスは、連続的又は間欠的であり、サービスは、実時間又は非実時間であってもよく、実時間サービスは、ＴＶ番組のシーケンスで構成することができる。
サービスは種々のタイプを有することができる。第一に、サービスはアプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオサービス又はオーディオだけのサービスであってもよい。第二に、サービスは、ダウンロードされたアプリケーションによってその再生／構成などが制御されるアプリベースのサービスであってもよい。第三に、サービスは、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を提供するＥＳＧサービスであってもよい。第四に、緊急警報情報を提供するＥＡ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ）サービスであってもよい。
アプリベースのエンハンスメントを有しないリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、又は（２）１つ以上のＭＭＴＰセッションで伝達することができる。
アプリベースのエンハンスメントを有するリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、及び（２）０個以上のＭＭＴＰセッションで伝達してもよい。この場合、アプリベースのエンハンスメントに用いられるデータは、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達してもよい。本発明の一実施例において、１つのサービスのリニアサービスコンポーネント（ストリーミングメディアコンポーネント）が２つのプロトコルによって同時に伝達されることを許容しなくてもよい。
アプリベースのサービスを放送網を介して伝達する場合、サービスコンポーネントを、１つ以上のＲＯＵＴＥセッションで伝達することができる。この場合、アプリベースのサービスに用いられるサービスデータを、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達することができる。
また、このようなサービスの一部のサービスコンポーネント又は一部のＮＲＴデータ、ファイルなどをブロードバンドを介して伝達してもよい（ハイブリッドサービスデリバリ）。
すなわち、本発明の一実施例で、一つのサービスのリニアサービスコンポーネントをＭＭＴプロトコルによって伝達することができる。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネント及びＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＭＭＴプロトコルによって伝達し、ＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。これらの実施例において、サービスの一部のサービスコンポーネント又は一部のＮＲＴデータは、ブロードバンドを介して伝達してもよい。ここで、アプリベースのサービス又はアプリベースのエンハンスメントに関するデータはＮＲＴデータ形態で、ＲＯＵＴＥによる放送網を介して伝達したり、ブロードバンドを介して伝達してもよい。ＮＲＴデータは、ローカリキャッシュドデータ（Ｌｏｃａｌｌｙ ｃａｓｈｅｄ ｄａｔａ）などと呼ぶこともできる。
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的に又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリにおいて、ＬＣＴセッションはオーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアはＤＡＳＨセグメントとしてフォーマットされる。
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全体又は一部のコンテンツコンポーネントを伝達する１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
ＮＲＴユーザサービス又はシステムメタデータのデリバリのために、ＬＣＴセッションはファイルベースのコンテンツアイテムを伝達する。これらのコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、サービスシグナリング、又はＥＳＧフラグメントのようなメタデータで構成することができる。サービスシグナリング又はＥＳＧフラグメントのようなシステムメタデータのデリバリも、ＭＭＴＰのシグナリングメッセージモードで行うことができる。
受信機では、チューナが周波数をスキャニングするが、特定周波数で放送シグナルを感知することができる。受信機は、ＳＬＴを抽出してその処理モジュールに送ることができる。ＳＬＴパーサーは、ＳＬＴをパースし、データを取得してチャネルマップに保存することができる。受信機は、ＳＬＴのブートストラップ情報を取得してＲＯＵＴＥ又はＭＭＴクライアントに伝達することができる。これによって受信機はＳＬＳを取得して保存することができる。ＵＳＢＤなどを取得することができ、これはシグナリングパーサーによってパースされてもよい。
図２は、本発明の一実施例に係るサービスディスカバリ手続を示す図である。
フィジカルレイヤの放送信号フレームが伝達するブロードキャストストリームは、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）を運搬することができる。ＬＬＳデータは、フェルノウン（ｗｅｌｌ ｋｎｏｗｎ）ＩＰアドレス／ポートに伝達されるＩＰパケットのペイロードで運搬することができる。このＬＬＳはそのタイプによってＳＬＴを含むことができる。ＬＬＳデータは、ＬＬＳテーブルの形態にフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの始めであってもよい。図示の実施例とは違い、ＬＬＳデータを伝達するＩＰストリームは、他のサービスデータと共に同一のＰＬＰを介して伝達してもよい。
ＳＬＴは、高速のチャネルスキャンによって受信機がサービスリストを生成できるようにし、ＳＬＳをロケーティング（ｌｏｃａｔｉｎｇ）するためのアクセス情報を提供する。ＳＬＴは、ブートストラップ情報を含むが、このブートストラップ情報は、受信機がそれぞれのサービスに対するＳＬＳ（Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）を取得できるようにする。ＳＬＳ、すなわち、サービスシグナリング情報がＲＯＵＴＥで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＬＣＴチャネル又はそのＬＣＴチャネルを含むＲＯＵＴＥセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。ＳＬＳがＭＭＴで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。
図示された実施例で、ＳＬＴが記述するサービス＃１のＳＬＳはＲＯＵＴＥで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＬＣＴチャネルを含むＲＯＵＴＥセッションに対するブートストラップ情報（ｓＩＰ１，ｄＩＰ１，ｄＰｏｒｔ１）を含むことができる。ＳＬＴが記述するサービス＃２のＳＬＳはＭＭＴで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＭＭＴＰパケットフローを含むＭＭＴＰセッションに対するブートストラップ情報（ｓＩＰ２，ｄＩＰ２，ｄＰｏｒｔ２）を含むことができる。
ＳＬＳは、当該サービスに対する特性を記述するシグナリング情報であり、当該サービス及び当該サービスのサービスコンポーネントを取得するための情報を提供したり、当該サービスを有意に再生するための受信機キャパビリティ情報などを含むことができる。各サービスに対して別個のサービスシグナリングを有すると、受信機は、ブロードキャストストリーム内で伝達される全てのＳＬＳをパースしないで、所望のサービスに対する適切なＳＬＳを取得すればよい。
ＳＬＳをＲＯＵＴＥプロトコルによって伝達する場合、ＳＬＳを、ＳＬＴが示すＲＯＵＴＥセッションの特定（ｄｅｄｉｃａｔｅｄ）のＬＣＴチャネルを介して伝達することができる。実施例によって、このＬＣＴチャネルはｔｓｉ＝０と識別されるＬＣＴチャネルであってもよい。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）及び／又はＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を含むことができる。
ここで、ＵＳＢＤ又はＵＳＤは、ＳＬＳフラグメントの一つであり、サービスの具体的な技術的情報を記述するシグナリングハブの役割を担うことができる。ＵＳＢＤは、サービス識別情報、デバイスキャパビリティ情報などを含むことができる。ＵＳＢＤは、他のＳＬＳフラグメント（Ｓ−ＴＳＩＤ、ＭＰＤなど）へのリファレンス情報（ＵＲＩリファレンス）を含むことができる。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれリファレンシングすることができる。また、ＵＳＢＤは、受信機が伝送モード（放送網／ブロードバンド）を決定できるようにするメタデータ情報をさらに含むことができる。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
Ｓ−ＴＳＩＤは、ＳＬＳフラグメントの一つであり、当該サービスのサービスコンポーネントを運搬する伝送セッションに対する全体的なセッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッション及び／又はそのＲＯＵＴＥセッションのＬＣＴチャネルに対する伝送セッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、一つのサービスと関連したサービスコンポーネントのコンポーネント取得（ａｃｑｕｉｓｉｔｉｏｎ）情報を提供することができる。Ｓ−ＴＳＩＤは、ＭＰＤのＤＡＳＨリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と当該サービスコンポーネントのｔｓｉ間のマッピングを提供することができる。Ｓ−ＴＳＩＤのコンポーネント取得情報は、ｔｓｉ、関連ＤＡＳＨリプレゼンテーションの識別子の形態で提供することができ、実施例によってＰＬＰ ＩＤを含んでも含まなくてもよい。コンポーネント取得情報を用いて、受信機は一つのサービスのオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディアセグメントのバッファリング、デコーディングなどを行うことができる。Ｓ−ＴＳＩＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。Ｓ−ＴＳＩＤの具体的な内容については後述する。
ＭＰＤは、ＳＬＳフラグメントの一つであり、当該サービスのＤＡＳＨメディアプレゼンテーションに関するデスクリプションを提供することができる。ＭＰＤは、メディアセグメントに対するリソース識別子（ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）を提供し、識別されたリソースに対するメディアプレゼンテーション内におけるコンテクスト情報を提供することができる。ＭＰＤは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（サービスコンポーネント）を記述し、またブロードバンドを介して伝達される追加的なＤＡＳＨリプレゼンテーションを記述することができる（ハイブリッドデリバリ）。ＭＰＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
ＳＬＳをＭＭＴプロトコルによって伝達する場合、ＳＬＳは、ＳＬＴが示すＭＭＴＰセッションの特定（ｄｅｄｉｃａｔｅｄ）ＭＭＴＰパケットフローで伝達することができる。実施例によって、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄは００の値を有することができる。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ及び／又はＭＭＴ Ｐａｃｋａｇｅ（ＭＰ）テーブルを含むことができる。
ここで、ＵＳＢＤは、ＳＬＳフラグメントの一つであり、ＲＯＵＴＥにおけるそれと同様にサービスの具体的な技術的情報を記述することができる。ここでのＵＳＢＤも、他のＳＬＳフラグメントへのリファレンス情報（ＵＲＩリファレンス）を含むことができる。ＭＭＴのＵＳＢＤは、ＭＭＴシグナリングのＭＰテーブルをリファレンシングすることができる。実施例によって、ＭＭＴのＵＳＢＤは、Ｓ−ＴＳＩＤ及び／又はＭＰＤへのリファレンス情報も含むことができる。ここで、Ｓ−ＴＳＩＤは、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのためのものであってもよい。ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される場合にも、ＮＲＴデータはＲＯＵＴＥプロトコルによって伝達され得るからである。ＭＰＤは、ハイブリッドサービスデリバリにおいて、ブロードバンドで伝達されるサービスコンポーネントのためのものであってもよい。ＭＭＴのＵＳＢＤの具体的な内容については後述する。
ＭＰテーブルは、ＭＰＵコンポーネントのためのＭＭＴのシグナリングメッセージであり、当該サービスのサービスコンポーネントを運搬するＭＭＴＰセッションに対する全体的なセッションデスクリプション情報を提供することができる。また、ＭＰテーブルは、このＭＭＴＰセッションを通じて伝達されるアセット（Ａｓｓｅｔ）に対するデスクリプションを含むことができる。ＭＰテーブルは、ＭＰＵコンポーネントのためのストリーミングシグナリング情報であり、一つのサービスに該当するアセットのリストとこれらのコンポーネントのロケーション情報（コンポーネント取得情報）を提供することができる。ＭＰテーブルの具体的な内容は、ＭＭＴで定義された形態であってもよく、変形された形態であってもよい。ここでいうアセットは、マルチメディアデータエンティティであり、１つのユニークＩＤで連合し、１つのマルチメディアプレゼンテーションを生成するために用いられるデータエンティティを意味することができる。アセットは、一つのサービスを構成するサービスコンポーネントに該当してもよい。ＭＰテーブルを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。ＭＰテーブルは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
その他のＭＭＴシグナリングメッセージを定義することもできる。このようなＭＭＴシグナリングメッセージによってＭＭＴＰセッション又はサービスに関連した追加の情報を記述することができる。
ＲＯＵＴＥセッションはソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッションはペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＭＭＴＰセッションはデスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフローはペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ＿ｉｄによって識別される。
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャネルと呼ぶことができる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャネルと呼ぶことができる。
図示した実施例とは違い、１つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰで伝達されてもよい。すなわち、１つのサービスは１つ以上のＰＬＰを介して伝達されてもよい。図示とは違い、実施例によって、１つのサービスを構成するコンポーネントが別個のＲＯＵＴＥセッションで伝達されてもよい。また、実施例によって、１つのサービスを構成するコンポーネントが別個のＭＭＴＰセッションで伝達されてもよい。実施例によって、１つのサービスを構成するコンポーネントがＲＯＵＴＥセッションとＭＭＴＰセッションとに分けて伝達されてもよい。図示してはいないが、１つのサービスを構成するコンポーネントがブロードバンドを介して伝達（ハイブリッドデリバリ）されてもよい。
図３は、本発明の一実施例に係るＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）を示す図である。
図示のＬＬＳテーブルの一実施例（ｔ３０１０）は、ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールド、ｐｒｏｖｉｄｅｒ＿ｉｄフィールド、ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールド及び／又はＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドによる情報を含むことができる。
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドは、当該ＬＬＳテーブルのタイプを識別し、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ＬＬＳテーブルによってシグナルされるサービスに関連したサービスプロバイダを識別することができる。ここで、サービスプロバイダは、当該ブロードキャストストリームの全部又は一部を用いるブロードキャスタであり、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ブロードキャストストリームを用いている複数のブロードキャスタのうち１つを識別することができる。ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールドは、当該ＬＬＳテーブルのバージョン情報を提供することができる。
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドの値によって、当該ＬＬＳテーブルは、前述したＳＬＴ、コンテンツアドバイザリレーティング（Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ ｒａｔｉｎｇ）に関連した情報を含むＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）、システムタイムに関連した情報を提供するＳｙｓｔｅｍＴｉｍｅ情報、緊急警報に関連した情報を提供するＣＡＰ（Ｃｏｍｍｏｎ Ａｌｅｒｔ Ｐｒｏｔｏｃｏｌ）メッセージのうち１つを含むことができる。実施例によって、その他の情報がＬＬＳテーブルに含まれてもよい。
図示のＳＬＴの一実施例（ｔ３０２０）は、＠ｂｓｉｄ属性、＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性、ｓｌｔＩｎｅｔＵｒｌエレメント及び／又はＳｅｒｖｉｃｅエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｂｓｉｄ属性は、ブロードキャストストリームの識別子であってもよい。＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性は、当該ＳＬＴが記述する全てのサービスをデコードして有意に再生するために必要なキャパビリティ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、当該ＳＬＴのサービスのためのＥＳＧ又はサービスシグナリング情報をブロードバンドを介して得るために用いられるベースＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
Ｓｅｒｖｉｃｅエレメントは、当該ＳＬＴが記述するサービスに関する情報を含むエレメントであり、それぞれのサービスに対してＳｅｒｖｉｃｅエレメントが存在してもよい。Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性、＠ｐｒｏｔｅｃｔｅｄ属性、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性、＠ｈｉｄｄｅｎ属性、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性、＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性、ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメント及び／又はｓｖｃＩｎｅｔＵｒｌエレメントを含むことができる。
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性は、当該サービスに対するＳＬＴ情報のシーケンスナンバーを示すことができる。＠ｐｒｏｔｅｃｔｅｄ属性は、当該サービスの有意な再生のために必要な少なくとも１つのサービスコンポーネントが保護（ｐｒｏｔｅｃｔｅｄ）されているか否かを示すことができる。＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性と＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性はそれぞれ、当該サービスのメジャーチャネルナンバーとマイナーチャネルナンバーを示すことができる。
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性は、当該サービスのカテゴリーを示すことができる。サービスのカテゴリーとしては、リニアＡ／Ｖサービス、リニアオーディオサービス、アプリベースのサービス、ＥＳＧサービス、ＥＡＳサービスなどを挙げることができる。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性は、当該サービスの短い名（Ｓｈｏｒｔ ｎａｍｅ）を提供することができる。＠ｈｉｄｄｅｎ属性は、当該サービスがテスティング又は独占的（ｐｒｏｐｒｉｅｔａｒｙ）な使用のためのサービスであるか否かを示すことができる。＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性は、当該サービスの有意な再生のためにブロードバンドアクセスが必要であるか否かを示すことができる。＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性は、当該サービスのデコーディング及び有意な再生のために必要なキャパビリティ情報を提供することができる。
ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、当該サービスのブロードキャストシグナリングに関連した情報を提供することができる。このエレメントは、当該サービスの放送網を介したシグナリングに対して、ロケーション、プロトコル、アドレスなどの情報を提供することができる。詳細な事項は後述する。
ｓｖｃＩｎｅｔＵｒｌエレメントは、当該サービスのためのシグナリング情報をブロードバンドを介してアクセスするためのＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
前述したＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、＠ｓｌｓＰｒｏｔｏｃｏｌ属性、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＰｌｐＩｄ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、及び／又は＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性を含むことができる。
＠ｓｌｓＰｒｏｔｏｃｏｌ属性は、当該サービスのＳＬＳを伝達するために用いられるプロトコルを示すことができる（ＲＯＵＴＥ、ＭＭＴなど）。＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性はそれぞれ、当該サービスのＳＬＳを伝達するために用いられるプロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
＠ｓｌｓＰｌｐＩｄ属性は、当該サービスのＳＬＳを伝達するＰＬＰを識別するＰＬＰ識別子を提供することができる。実施例によって、このフィールドは省略されてもよく、ＳＬＳが伝達されるＰＬＰ情報は、後述するＬＭＴ内の情報とＳＬＴのブートストラップ情報とを組み合わせて確認してもよい。
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、当該サービスのＳＬＳを伝達する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート及びソースＩＰアドレスを示すことができる。これらは、ＳＬＳが伝達される伝送セッション（ＲＯＵＴＥセッション又はＭＭＴＰセッション）を識別することができる。これらはブートストラップ情報に含まれてもよい。
図４は、本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。
図示されたＵＳＢＤの一実施例（ｔ４０１０）は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性、＠ｆｕｌｌＭＰＤＵｒｉ属性、＠ｓＴＳＩＤＵｒｉ属性、ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメント及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性は、当該サービスのグローバルにユニークな（ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ）識別子であり、ＥＳＧデータとリンクされる上で用いられてもよい（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）。＠ｓｅｒｖｉｃｅＩｄ属性は、ＳＬＴの該当のサービスエントリーに対応するリファレンスであり、ＳＬＴのサービスＩＤ情報と同一であってもよい。＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性は、当該サービスの状態を示すことができる。このフィールドは、当該サービスがアクティブ状態かインアクティブ（ｉｎａｃｔｉｖｅ）状態かを示すことができる。
＠ｆｕｌｌＭＰＤＵｒｉ属性は、当該サービスのＭＰＤフラグメントをリファレンシングすることができる。ＭＰＤは、前述したように、放送網又はブロードバンドを介して伝達されるサービスコンポーネントに対する再生デスクリプションを提供することができる。＠ｓＴＳＩＤＵｒｉ属性は、当該サービスのＳ−ＴＳＩＤフラグメントをリファレンシングすることができる。Ｓ−ＴＳＩＤは、前述したように、当該サービスを運搬する伝送セッションへのアクセスに関連したパラメータを提供することができる。
ｎａｍｅエレメントは、当該サービスの名を提供することができる。このエレメントは、＠ｌａｎｇ属性をさらに含むことができるが、このフィールドは、ｎａｍｅエレメントが提供する名の言語を示すことができる。ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、当該サービスの利用可能な（ａｖａｉｌａｂｌｅ）言語を示すことができる。すなわち、このエレメントは、当該サービスを提供できる言語を羅列することができる。
ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメントは、当該サービスを有意に再生する上で必要な受信機側のキャパビリティ又はキャパビリティグループ情報を示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるキャパビリティ情報フォーマットと互換されてもよい。
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、当該サービスの放送網又はブロードバンドを介してアクセスされるコンテンツに対して、伝送関連情報を提供することができる。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及び／又はｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。このエレメントはそれぞれ、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは放送網を介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、当該サービスメディアプレゼンテーションの全てのピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、該当のメディアセグメントが放送網を介して伝達されるということを暗示することができる。
ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、該当のサービスメディアプレゼンテーションの全ピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、当該メディアセグメントがブロードバンドを介して伝達されるということを暗示することができる。
図示のＳ−ＴＳＩＤの一実施例（ｔ４０２０）は、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性及び／又はＲＳエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、ＵＳＢＤ／ＵＳＤの当該サービスをリファレンシングすることができる。ＲＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッションに関する情報を記述することができる。このようなＲＯＵＴＥセッションの個数によって、このエレメントは複数個存在してもよい。ＲＳエレメントは、＠ｂｓｉｄ属性、＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性、＠ｄｐｏｒｔ属性、＠ＰＬＰＩＤ属性及び／又はＬＳエレメントをさらに含むことができる。
＠ｂｓｉｄ属性は、当該サービスのサービスコンポーネントが伝達されるブロードキャストストリームの識別子であってもよい。このフィールドが省略された場合、デフォルトブロードキャストストリームは、当該サービスのＳＬＳを伝達するＰＬＰを含むブロードキャストストリームであってもよい。このフィールドの値は、ＳＬＴの＠ｂｓｉｄ属性と同じ値であってもよい。
＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性及び＠ｄｐｏｒｔ属性はそれぞれ、該当のＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポートを示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳＬＳを伝達する、すなわち、該当のＳ−ＴＳＩＤを伝達している現在の、ＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポート値であってもよい。現在ＲＯＵＴＥセッションでない、当該のサービスのサービスコンポーネントを伝達する他のＲＯＵＴＥセッションに対しては、本フィールドが省略されなくてもよい。
＠ＰＬＰＩＤ属性は、該当のＲＯＵＴＥセッションのＰＬＰ ＩＤ情報を示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳ−ＴＳＩＤが伝達されている現在ＰＬＰのＰＬＰ ＩＤ値であってもよい。実施例によって、このフィールドは省略され、該当のＲＯＵＴＥセッションのＰＬＰ ＩＤ情報は、後述するＬＭＴ内の情報と、ＲＳエレメントのＩＰアドレス／ＵＤＰポート情報とを組み合わせて確認してもよい。
ＬＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルに関する情報を記述することができる。このようなＬＣＴチャネルの個数によって、このエレメントは複数個存在してもよい。ＬＳエレメントは、＠ｔｓｉ属性、＠ＰＬＰＩＤ属性、＠ｂｗ属性、＠ｓｔａｒｔＴｉｍｅ属性、＠ｅｎｄＴｉｍｅ属性、ＳｒｃＦｌｏｗエレメント及び／又はＲｅｐａｉｒＦｌｏｗエレメントを含むことができる。
＠ｔｓｉ属性は、該当のＬＣＴチャネルのｔｓｉ情報を示すことができる。これによって、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルを識別することができる。＠ＰＬＰＩＤ属性は、該当のＬＣＴチャネルのＰＬＰ ＩＤ情報を示すことができる。実施例によって、このフィールドは省略されてもよい。＠ｂｗ属性は、該当のＬＣＴチャネルの最大の帯域幅を示すことができる。＠ｓｔａｒｔＴｉｍｅ属性は、該当のＬＣＴセッションのスタートタイムを示し、＠ｅｎｄＴｉｍｅ属性は、該当のＬＣＴチャネルのエンドタイムを示すことができる。
ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローについて記述することができる。ＲＯＵＴＥのソースプロトコルは、デリバリオブジェクトを伝送するために用いられ、１つのＲＯＵＴＥセッション内で少なくとも１つのソースフローを設定（ｅｓｔａｂｌｉｓｈ）することができる。これらのソースフローは、関連したオブジェクトをオブジェクトフローとして伝達することができる。
ＲｅｐａｉｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローについて記述することができる。ソースプロトコルによって伝達されるデリバリオブジェクトは、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）によって保護されてもよいが、リペアプロトコルは、このようなＦＥＣプロテクションを可能にするＦＥＣフレームワーク（ｆｒａｍｅｗｏｒｋ）を定義することができる。
図５は、本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。
図示されたＵＳＢＤの一実施例は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメント、Ｃｈａｎｎｅｌエレメント、ｍｐｕＣｏｍｐｏｎｅｎｔエレメント、ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメント、ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメント及び／又はＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント及び／又はｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントは、当該サービスのコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティングを示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるコンテンツアドバイザリレーティング情報フォーマットと互換されてもよい。Ｃｈａｎｎｅｌエレメントは、当該サービスに関連した情報を含むことができる。このエレメントの詳細な内容については後述する。
ｍｐｕＣｏｍｐｏｎｅｎｔエレメントは、当該サービスのＭＰＵとして伝達されるサービスコンポーネントに関するデスクリプションを提供することができる。このエレメントは、＠ｍｍｔＰａｃｋａｇｅＩｄ属性及び／又は＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性をさらに含むことができる。＠ｍｍｔＰａｃｋａｇｅＩｄ属性は、当該サービスのＭＰＵとして伝達されるサービスコンポーネントのＭＭＴパッケージ（Ｐａｃｋａｇｅ）をリファレンシングすることができる。＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性は、時間上、＠ｍｍｔＰａｃｋａｇｅＩｄ属性がリファレンシングするＭＭＴパッケージの次に用いられるＭＭＴパッケージをリファレンシングすることができる。このエレメントの情報を用いてＭＰテーブルをリファレンシングすることができる。
ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、ＲＯＵＴＥで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。リニアサービスコンポーネントがＭＭＴプロトコルで伝達される場合であっても、ＮＲＴデータは、前述したように、ＲＯＵＴＥプロトコルによって伝達されてもよい。このエレメントはこのようなＮＲＴデータに関する情報を記述することができる。このエレメントの詳細な内容については後述する。
ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメントは、ブロードバンドで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。ハイブリッドサービスデリバリにおいて、一つのサービスの一部のサービスコンポーネント又はその他のファイルは、ブロードバンドを介して伝達されてもよい。このエレメントは、このようなデータに関する情報を記述することができる。このエレメントは、＠ｆｕｌｌＭＰＤＵｒｉ属性をさらに含むことができる。この属性は、ブロードバンドで伝達されるサービスコンポーネントについて記述するＭＰＤをリファレンシングすることができる。ハイブリッドサービスデリバリの他にも、トンネル内の走行などによって放送信号が弱くなる場合において、放送網−ブロードバンド間のハンドオフ（ｈａｎｄｏｆｆ）を支援するためにこのエレメントが用いられてもよい。放送信号が弱くなる場合、ブロードバンドを介してサービスコンポーネントを取得するが、再び放送信号が強くなると、放送網を介してサービスコンポーネントを取得し、サービスの連続性を保障することができる。
ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、当該サービスのサービスコンポーネントに関する情報を含むことができる。サービスのサービスコンポーネントの個数によって、このエレメントは複数個存在してもよい。このエレメントは、各サービスコンポーネントのタイプ、ロール（ｒｏｌｅ）、名、識別子、プロテクションの有無などの情報を記述することができる。このエレメントの詳細な情報については後述する。
前述したＣｈａｎｎｅｌエレメントは、＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性、＠ｓｅｒｖｉｃｅＩｃｏｎ属性及び／又はＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントをさらに含むことができる。＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性は、当該サービスのジャンルを示し、＠ｓｅｒｖｉｃｅＩｃｏｎ属性は、当該サービスを代表するアイコン（ｉｃｏｎ）のＵＲＬ情報を含むことができる。ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、当該サービスのサービスデスクリプションを提供するが、このエレメントは、＠ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性及び／又は＠ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇ属性をさらに含むことができる。これらの属性はそれぞれ、当該サービスデスクリプションのテキスト及びそのテキストに用いられる言語を示すことができる。
前述したｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、＠ｓＴＳＩＤＵｒｉ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性をさらに含むことができる。
＠ｓＴＳＩＤＵｒｉ属性は、Ｓ−ＴＳＩＤフラグメントをリファレンシングすることができる。このフィールドは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。このＳ−ＴＳＩＤは、ＲＯＵＴＥで伝達されるサービスコンポーネントに対するアクセス関連情報を提供することができる。このＳ−ＴＳＩＤは、ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される状況で、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのために存在してもよい。
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、前述したＳ−ＴＳＩＤを運搬する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート、ソースＩＰアドレスを示すことができる。すなわち、これらのフィールドは、前述したＳ−ＴＳＩＤを運搬する伝送セッション（ＭＭＴＰセッション又はＲＯＵＴＥセッション）を識別することができる。
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性は、前述したＳ−ＴＳＩＤを伝達するために用いられる伝送プロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
前述したＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性、＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性、＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性、＠ｃｏｍｐｏｎｅｎｔＩｄ属性及び／又は＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性をさらに含むことができる。
＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性は、当該コンポーネントのタイプを示すことができる。例えば、この属性は、当該コンポーネントがオーディオ、ビデオ、クローズドキャプションコンポーネントのいずれであるかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性は、当該コンポーネントのロール（役割）を示すことができる。例えば、この属性は、当該コンポーネントがオーディオコンポーネントである場合、メインオーディオ、ミュージック、コメンタリなどのいずれであるかを示すことができる。該当のコンポーネントがビデオコンポーネントである場合、プライマリビデオであるかなどを示すことができる。当該コンポーネントがクローズドキャプションコンポーネントである場合、ノーマルキャプションてあるか又はイージーリーダー（ｅａｓｙ ｒｅａｄｅｒ）タイプであるかなどを示すことができる。
＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性は、当該サービスコンポーネントが保護されたか、例えば暗号化されたかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＩｄ属性は、当該サービスコンポーネントの識別子を示すことができる。この属性の値は、このサービスコンポーネントに該当するＭＰテーブルのａｓｓｅｔ＿ｉｄ（アセットＩＤ）と同じ値であってもよい。＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性は、当該サービスコンポーネントの名を示すことができる。
図６は、本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）動作を示す図である。
リンクレイヤは、フィジカルレイヤとネットワークレイヤとの間のレイヤであり得る。送信側では、ネットワークレイヤからフィジカルレイヤにデータを伝送し、受信側では、フィジカルレイヤからネットワークレイヤにデータを伝送することができる（ｔ６０１０）。リンクレイヤの目的は、フィジカルレイヤによる処理のために全入力パケットタイプを１つのフォーマットに圧縮（ａｂｓｔｒａｃｔｉｎｇ）すること、及びまだ定義されていない入力パケットタイプに対する柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）及び将来の拡張可能性を保障することにあり得る。また、リンクレイヤは、入力パケットのヘッダーの不要な情報を圧縮するオプションを提供することによって、入力データが効率的に伝送されるようにすることができる。リンクレイヤのオーバーヘッドリダクション、エンカプセレーションなどの動作は、リンクレイヤプロトコルと呼ばれ、当該プロトコルによって生成されたパケットは、リンクレイヤパケットと呼ぶことができる。リンクレイヤは、パケットエンカプセレーション（ｐａｃｋｅｔ ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を有することができる。
送信側基準で、リンクレイヤ（ＡＬＰ）は、入力パケットに対してオーバーヘッドリダクション過程を行った後、それらをリンクレイヤパケットにエンカプセレーションすることができる。また、実施例によって、リンクレイヤは、オーバーヘッドリダクション過程を行わないで、リンクレイヤパケットにエンカプセレーションしてもよい。リンクレイヤプロトコルの使用によって、フィジカルレイヤ上でデータの伝送に対するオーバーヘッドを大きく減少させることができ、本発明に係るリンクレイヤプロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ＴＳオーバーヘッドリダクションを提供することができる。
図示の、ＩＰパケットが入力パケットとして入力される場合において（ｔ６０１０）、リンクレイヤは、ＩＰヘッダー圧縮、アダプテーション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。まず、ＲｏＨＣモジュールでＩＰパケットヘッダー圧縮を行って不要なオーバーヘッドを減らし、アダプテーション過程によってコンテクスト情報を抽出し、これを帯域外で伝送することができる。ＩＰヘッダー圧縮及びアダプテーション過程を総称して、ＩＰヘッダー圧縮ということもできる。その後、エンカプセレーション過程を経てＩＰパケットをリンクレイヤパケットにエンカプセレーションすることができる。
ＭＰＥＧ２ＴＳパケットが入力パケットとして入力される場合において、リンクレイヤは、ＴＳパケットに対するオーバーヘッドリダクション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。オーバーヘッドリダクションにおいて、リンクレイヤは、シンクバイトの除去、ヌルパケットの削除及び／又は共通（ｃｏｍｍｏｎ）ヘッダー除去（圧縮）を提供することができる。シンクバイト除去によってＴＳパケット当たりに１バイトのオーバーヘッドリダクションを提供することができる。受信側で再挿入可能な方式でヌルパケットの削除を行ってもよい。また、連続したヘッダー間の共通した情報を、受信側で復旧可能な方式で削除（圧縮）してもよい。各オーバーヘッドリダクション過程の一部は省略されてもよい。その後、エンカプセレーション過程を経てＴＳパケットをリンクレイヤパケッにエンカプセレーションすることができる。ＴＳパケットのエンカプセレーションに対するリンクレイヤパケット構造は、他のタイプのパケットとは異なってもよい。
まず、ＩＰヘッダー圧縮（ＩＰ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
ＩＰパケットは、固定されたヘッダーフォーマットを有するが、通信環境で必要な一部の情報がブロードキャスト環境では不要な場合がある。リンクレイヤプロトコルは、ＩＰパケットのヘッダーを圧縮することによって、ブロードキャストオーバーヘッドを減らすメカニズムを提供することができる。
ＩＰヘッダー圧縮は、ヘッダーコンプレッサ／デコンプレッサ及び／又はアダプテーションモジュールを含むことができる。ＩＰヘッダーコンプレッサ（ＲｏＨＣコンプレッサ）は、ＲｏＨＣ方式に基づいて各ＩＰパケットヘッダーのサイズを減少させることができる。その後、アダプテーションモジュールは、コンテクスト情報を抽出し、各パケットストリームからシグナリング情報を生成することができる。受信機は、該当のパケットストリームに関連したシグナリング情報をパースし、コンテクスト情報をそのパケットストリームに付加（ａｔｔａｃｈ）することができる。ＲｏＨＣデコンプレッサは、パケットヘッダーを復旧して元来のＩＰパケットを再構成することができる。
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
単方向リンク上の伝送において、受信機がコンテクストの情報を有していないと、デコンプレッサは完全なコンテクストを受信するまでは、受信したパケットヘッダーを復旧することができない。これは、チャネル変更遅延及びターンオンディレー（ｔｕｒｎ−ｏｎ ｄｅｌａｙ）を招きうる。そこで、アダプテーション機能を用いて、コンプレッサ／デコンプレッサ間のコンフィギュレーションパラメータとコンテクスト情報を帯域外で伝送することができる。
圧縮されたＩＰパケットからコンテクスト情報を抽出するが、アダプテーションモードによって様々な方法を用いることができる。
モード＃１は、圧縮されたパケットストリームに対していかなる動作も行わないモードであり、アダプテーションモジュールがバッファとして動作するモードであるといえる。
モード＃２は、圧縮されたパケットストリームのうち、ＩＲパケットを検出してコンテクスト情報（スタティックチェーン）を抽出するモードであってもよい。抽出の後、ＩＲパケットはＩＲ−ＤＹＮパケットに変換され、ＩＲ−ＤＹＮパケットを元来のＩＲパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
モード＃３（ｔ６０２０）は、圧縮されたパケットストリームのうち、ＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテクスト情報を抽出するモードであってもよい。ＩＲパケットからスタティックチェーン及びダイナミックチェーンを、ＩＲ−ＤＹＮパケットからダイナミックチェーンを抽出することができる。抽出の後、ＩＲ及びＩＲ−ＤＹＮパケットを一般圧縮パケットに変換することができる。変換されたパケットを、元来のＩＲ及びＩＲ−ＤＹＮパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
各モードで、コンテクスト情報を抽出して残ったパケットは、圧縮されたＩＰパケットのためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。コンテクスト情報は、リンクレイヤシグナリングであり、シグナリング情報のためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。
抽出されたコンテクスト情報は、ＲＤＴ（ＲｏＨＣ−Ｕ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）に含めてＲｏＨＣパケットフローとは別に伝送することができる。コンテクスト情報は、他のシグナリング情報と共に特定（ｓｐｅｃｉｆｉｃ）フィジカルデータ経路で伝送することができる。特定フィジカルデータ経路とは、実施例によって、一般ＰＬＰのうちの一つを意味することもでき、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）が伝達されるＰＬＰを意味することもでき、指定された（ｄｅｄｉｃａｔｅｄ）ＰＬＰであってもよく、Ｌ１シグナリングパス（ｐａｔｈ）を意味することもできる。ここで、ＲＤＴは、コンテクスト情報（スタティックチェーン及び／又はダイナミックチェーン）及び／又はヘッダーコンプレッションに関連した情報を含むシグナリング情報であってもよい。
受信機はパケットストリームを取得する前に、最初のＰＬＰを選択してＳＬＴ、ＲＤＴなどのシグナリング情報をまず取得することができる。シグナリング情報を取得すると、該当のパケットストリームを運搬するＰＬＰを選択することができる。アダプテーションモジュールは、コンテクスト情報をパースし、これを圧縮されたパケットと組み合わせることができる。これによってパケットストリームを復旧することができ、これをＲｏＨＣデコンプレッサに伝達することができる。その後、デコンプレッションを始まることができる。
以下、パケットエンカプセレーションについて説明する。
リンクレイヤプロトコルは、ＩＰパケット、ＴＳパケットなどの全てのタイプのインプットパケットをリンクレイヤパケットにエンカプセレーションすることができる。これによって、フィジカルレイヤは、ネットワークレイヤのプロトコルタイプとは独立して１つのパケットフォーマットだけを処理すればいい（ここでは、ネットワークレイヤパケットの一種としてＭＰＥＧ−２ＴＳパケットを考慮）。各ネットワークレイヤパケット又は入力パケットは、ゼネリックリンクレイヤパケットのペイロードに変形される。
パケットエンカプセレーション過程では分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤパケットが大きすぎてフィジカルレイヤで処理できない場合、ネットワークレイヤパケットを２つ以上のセグメントに分割することができる。リンクレイヤパケットヘッダーは、送信側で分割を実行し、受信側で再結合を実行するためのフィールドを含むことができる。各セグメントを、元来の位置と同じ順序でリンクレイヤパケットにエンカプセレーションすることができる。
パケットエンカプセレーション過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）を活用することもできる。リンクレイヤパケットのペイロードが複数のネットワークレイヤパケットを含む程度にネットワークレイヤパケットが十分に小さい場合、連鎖を行ってもよい。リンクレイヤパケットヘッダーは、連鎖を実行するためのフィールドを含むことができる。連鎖の場合、各入力パケットを、元来の入力順序と同じ順序でリンクレイヤパケットのペイロードにエンカプセレーションすることができる。
リンクレイヤパケットは、ヘッダー及びペイロードを含むことができ、ヘッダーは、ベースヘッダー、追加（ａｄｄｉｔｉｏｎａｌ）ヘッダー及び／又はオプショナルヘッダーを含むことができる。追加ヘッダーは、連鎖又は分割などの状況によってさらに追加することができるが、追加ヘッダーには状況に応じて、必要なフィールドを含めることができる。また、追加的な情報の伝達のためにオプショナルヘッダーをさらに追加することもできる。それぞれのヘッダー構造は既に定義されていてもよい。前述したように、入力パケットがＴＳパケットである場合には、他のパケットとは異なるリンクレイヤヘッダー構造を用いることができる。
以下、リンクレイヤシグナリングについて説明する。
リンクレイヤシグナリングは、ＩＰレイヤよりも下位レベルで動作することができる。受信側では、ＬＬＳ、ＳＬＴ、ＳＬＳなどのＩＰレベルシグナリングよりもリンクレイヤシグナリングを先に取得することができる。このため、リンクレイヤシグナリングをセッション設定（ｅｓｔａｂｌｉｓｈｍｅｎｔ）の前に取得することができる。
リンクレイヤシグナリングには、インターナルリンクレイヤシグナリングとエクスターナルリンクレイヤシグナリングがあり得る。インターナルリンクレイヤシグナリングは、リンクレイヤで生成されたシグナリング情報を意味することができる。前述したＲＤＴ又は後述するＬＭＴなどがこれに当たる。エクスターナルリンクレイヤシグナリングは、外部のモジュール又は外部のプロトコル、上位レイヤから伝達されたシグナリング情報であってもよい。リンクレイヤは、リンクレイヤシグナリングをリンクレイヤパケットにエンカプセレーションして伝達することができる。リンクレイヤシグナリングのためのリンクレイヤパケット構造（ヘッダー構造）を定義することができ、この構造によって、リンクレイヤシグナリング情報をエンカプセレーションすることができる。
図７は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）を示す図である。
ＬＭＴは、ＰＬＰで運搬される上位レイヤセッションのリストを提供することができる。また、ＬＭＴは、上位レイヤセッションを伝達するリンクレイヤパケットをプロセシングするための追加的な情報を提供することができる。
ＬＭＴから、あるＰＬＰを介していかなるＩＰストリーム、いかなる伝送セッションが伝送されているかに関する情報を取得することができる。逆に、特定の伝送セッションがどのＰＬＰで伝達されるかに関する情報も取得することができる。
実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報を用いて、ＳＬＴ、ＳＬＳが示す特定伝送セッションがどのＰＬＰで伝送されているかに関する情報を確認することができる。
他の実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報は省略され、ＳＬＴ、ＳＬＳが示す特定伝送セッションに対するＰＬＰ情報は、ＬＭＴ内の情報を参照することによって確認することもできる。この場合、受信機は、ＬＭＴと他のＩＰレベルシグナリング情報とを組み合わせて、所望のＰＬＰを識別することができる。この実施例においても、ＳＬＴ、ＳＬＳ等におけるＰＬＰ情報は省略されず、ＳＬＴ、ＳＬＳ等に残っていてもよい。
同図の実施例に係るＬＭＴは、ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールド、ＰＬＰ＿ＩＤフィールド、ｎｕｍ＿ｓｅｓｓｉｏｎフィールド及び／又はそれぞれのセッションに関する情報を含むことができる。同図の実施例のＬＭＴは、１つのＰＬＰに対して、そのＰＬＰで伝送されるＩＰストリームを記述しているが、実施例によって、ＬＭＴにＰＬＰループを追加し、複数個のＰＬＰに関する情報を記述してもよい。
ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドは、当該テーブルによって伝達されるシグナリング情報のタイプを示すことができる。ＬＭＴに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は、０ｘ０１に設定することができる。ＰＬＰ＿ＩＤフィールドは、当該ＬＭＴに該当するＰＬＰを識別することができる。ｎｕｍ＿ｓｅｓｓｉｏｎフィールドは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションの個数を示すことができる。
ｎｕｍ＿ｓｅｓｓｉｏｎフィールドが示す個数によって、各セッションに関する情報が含まれてもよい。この情報は、ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド、ｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＩＤ＿ｆｌａｇフィールド、ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールド、ＳＩＤフィールド及び／又はｃｏｎｔｅｘｔ＿ｉｄフィールドを含むことができる。
ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド及びｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションのうち、当該伝送セッションに対するソースＩＰアドレス、デスティネーションＩＰアドレス、ソースＵＤＰポート、デスティネーションＵＤＰポートを示すことができる。
ＳＩＤ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示すことができる。上位レイヤセッションを伝達するリンクレイヤパケットは、そのオプショナルヘッダーにＳＩＤフィールドを有することができ、そのＳＩＤフィールド値は後述するＬＭＴ内のＳＩＤフィールドと同一であってもよい。
ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットのデータにヘッダーコンプレッションが適用されたか否かを示すことができる。また、本フィールドの値によって、後述するｃｏｎｔｅｘｔ＿ｉｄフィールドの存否が決定されてもよい。ＳＩＤフィールドは、当該伝送セッションを伝達するリンクレイヤパケットに対するＳＩＤ（ｓｕｂ ｓｔｒｅａｍ ＩＤ）を示すことができる。
ｃｏｎｔｅｘｔ＿ｉｄフィールドは、ＲＤＴ内のＣＩＤ（ｃｏｎｔｅｘｔ ｉｄ）に対するリファレンスを提供することができる。ＲＤＴのＣＩＤ情報は、該当する圧縮ＩＰパケットストリームに対するコンテクストＩＤを示すことができる。ＲＤＴは、該当する圧縮ＩＰパケットストリームに対するコンテクスト情報を提供することができる。本フィールドによってＲＤＴとＬＭＴとが関連付けられてもよい。
前述した、本発明のシグナリング情報／テーブルの実施例において、それぞれのフィールド、エレメント、属性を省略したり他のフィールドに置き換えてもよく、実施例によって、更なるフィールド、エレメント、属性を追加してもよい。
本発明の一実施例で、一つのサービスのサービスコンポーネントを複数個のＲＯＵＴＥセッションで伝達することができる。この場合、ＳＬＴのブートストラップ情報を用いてＳＬＳを取得することができる。このＳＬＳのＵＳＢＤを用いてＳ−ＴＳＩＤとＭＰＤをリファレンシングすることができる。Ｓ−ＴＳＩＤは、ＳＬＳを伝達しているＲＯＵＴＥセッションだけでなく、サービスコンポーネントを伝達している他のＲＯＵＴＥセッションに対する伝送セッションデスクリプション情報も記述することができる。これによって、複数個のＲＯＵＴＥセッションで伝達されるサービスコンポーネントを全て収集することができる。このような事項は、一つのサービスのサービスコンポーネントが複数個のＭＭＴＰセッションで伝達される場合にも同様に適用することができる。参考として、１つのサービスコンポーネントが複数個のサービスによって同時に用いられてもよい。
本発明の他の実施例で、ＥＳＧサービスに対するブートストラピングは放送網又はブロードバンドで行われてもよい。ブロードバンドを介してＥＳＧを取得し、ＳＬＴのＵＲＬ情報を活用することができる。このＵＲＬにＥＳＧ情報などを要求することができる。
本発明の他の実施例で、一つのサービスのいずれか一つのサービスコンポーネントは放送網で、いずれか他のサービスコンポーネントはブロードバンドで伝達することができる（ハイブリッド）。Ｓ−ＴＳＩＤは、放送網で伝達されるコンポーネントについて記述して、ＲＯＵＴＥクライアントが所望のサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、ベースパターン情報を有しており、どのセグメントが（どのコンポーネントが）どの経路で伝達されるかを記述することができる。したがって、受信機は、これを用いて、ブロードバンドサーバーに要求すべきセグメント、及び放送ストリームから見つけるべきセグメントを識別することができる。
本発明の他の実施例で、サービスに対するスケーラブル（ｓｃａｌａｂｌｅ）コーディングを行うこともできる。ＵＳＢＤは、当該サービスをレンダリングするために必要な全てのキャパビリティ情報を有することができる。例えば、一つのサービスがＨＤ又はＵＨＤで提供される場合、ＵＳＢＤのキャパビリティ情報は、“ＨＤ又はＵＨＤ”値を有することができる。受信機は、ＭＰＤから、ＵＨＤ又はＨＤサービスをレンダリングするためにはどのコンポーネントを再生しなければならないかが分かる。
本発明の他の実施例で、ＳＬＳを伝達するＬＣＴチャネルで伝達されるＬＣＴパケットのＴＯＩフィールドから、当該ＬＣＴパケットがどのＳＬＳフラグメントを伝達しているか（ＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなど）を識別することができる。
本発明の他の実施例で、アプリベースのエンハンスメント／アプリベースのサービスに用いられるアプリコンポーネントを、ＮＲＴコンポーネントとして放送網で伝達されたり、又はブロードバンドで伝達してもよい。また、アプリベースのエンハンスメントに対するアプリシグナリングは、ＳＬＳと共に伝達されるＡＳＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ）によって行われてもよい。また、アプリが行う動作に対するシグナリングであるイベントは、ＳＬＳと共にＥＭＴ（Ｅｖｅｎｔ Ｍｅｓｓａｇｅ Ｔａｂｌｅ）の形態で伝達されたり、ＭＰＤ内にシグナルされたり、ＤＡＳＨリプレゼンテーション内にｂｏｘ形態でインバンド（ｉｎ−ｂａｎｄ）シグナルされてもよい。ＡＳＴ、ＥＭＴなどはブロードバンドを介して伝達されてもよい。収集されたアプリコンポーネントとこのようなシグナリング情報を用いてアプリベースのエンハンスメントなどを提供することができる。
本発明の他の実施例で、緊急警報のためにＣＡＰメッセージを前述のＬＳテーブルに含めて提供することができる。緊急警報のためのリーチメディア（Ｒｉｃｈ Ｍｅｄｉａ）コンテンツも提供することができる。リーチメディアは、ＣＡＰメッセージによってシグナルすることができ、リーチメディアが存在する場合、これは、ＳＬＴによってシグナルされるＥＡＳサービスとして提供することができる。
本発明の他の実施例で、ＭＭＴプロトコルによってリニアサービスコンポーネントを放送網を介して伝達することができる。この場合、当該サービスに対するＮＲＴデータ（例えば、アプリコンポーネント）をＲＯＵＴＥプロトコルによって放送網で伝達することができる。また、当該サービスに対するデータをブロードバンドで伝達することができる。受信機は、ＳＬＴのブートストラップ情報を用いてＳＬＳを伝達するＭＭＴＰセッションに接近することができる。ＭＭＴによるＳＬＳのＵＳＢＤは、ＭＰテーブルをリファレンシングして、受信機がＭＭＴプロトコルによって伝達されるＭＰＵにフォーマットされたリニアサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、Ｓ−ＴＳＩＤをさらにリファレンシングして、受信機がＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータを取得するようにしてもよい。また、ＵＳＢＤは、ＭＰＤをさらにリファレンシングして、ブロードバンドを介して伝達されるデータに対する再生デスクリプションを提供することができる。
本発明の他の実施例で、受信機はそのコンパニオンデバイスに、ストリーミングコンポーネント及び／又はファイルコンテンツアイテム（ファイルなど）を取得できるロケーションＵＲＬ情報を、ウェブソケットなどの方法で伝達することができる。コンパニオンデバイスのアプリケーションはこのＵＲＬにＨＴＴＰ ＧＥＴなどを用いて要求して該当のコンポーネント、データなどを取得することができる。その他にも、受信機はシステムタイム情報、緊急警報情報などの情報をコンパニオンデバイス側に伝達することができる。
図８は、本発明の一実施例に係るネットワークトポロジを示すブロック図である。
図８に示すように、本発明の一実施例に係るネットワークトポロジは、コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、複数の付加サービス提供サーバー５０、放送受信装置６０、ネットワーク７０、映像表示装置１００を含む。
コンテンツ提供サーバー１０は放送局などであってもよく、メイン視聴覚コンテンツ（ｍａｉｎ ａｕｄｉｏ−ｖｉｓｕａｌ ｃｏｎｔｅｎｔ）を含む放送信号を放送する。放送信号は付加サービスをさらに含むことができる。付加サービスはメイン視聴覚コンテンツと関連があってもよく、関連がなくてもよい。付加サービスは、サービス情報（ｓｅｒｖｉｃｅ ｉｎｆｏｒｍａｔｉｏｎ）、メタデータ（ｍｅｔａｄａｔａ）、付加データ、コンパイルされた実行ファイル、ウェブアプリケーション、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書、ＸＭＬ文書、ＣＳＳ（ｃａｓｃａｄｉｎｇ ｓｔｙｌｅ ｓｈｅｅｔ）文書、オーディオファイル、ビデオファイル、ＡＴＳＣ２．０コンテンツ、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）のようなアドレスなどの形態を有することができる。１つ以上のコンテンツ提供サーバーが存在してもよい。
コンテンツ認識サービス提供サーバー２０は、映像表示装置１００がメイン視聴覚コンテンツに基づいてコンテンツを認識できるようにするコンテンツ認識サービスを提供する。コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに修正を加えてもよく、修正を加えなくてもよい。１つ以上のコンテンツ認識サービス提供サーバーが存在してもよい。
コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにロゴのような見えるウォーターマーク（ｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）を挿入するウォーターマークサーバーであってもよい。このウォーターマークサーバーは、メイン視聴覚コンテンツの各フレームの左上端又は右上端にコンテンツプロバイダのロゴをウォーターマークすることができる。
また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツに、コンテンツ情報を見えないウォーターマーク（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）として挿入するウォーターマークサーバーであってもよい。
また、コンテンツ認識サービス提供サーバー２０は、メイン視聴覚コンテンツの一部のフレーム又は一部のオーディオサンプルから特徴情報を抽出して保存するフィンガープリントサーバーであってもよい。この特徴情報は、シグネチャーとも呼ばれる。
マルチチャネルビデオ分配サーバー３０は、複数の放送局から放送信号を受信して多重化し、多重化された信号を放送受信装置６０に提供する。特に、マルチチャネルビデオ分配サーバー３０は、受信した放送信号に対して復調及びチャネル復号化を行ってメイン視聴覚コンテンツ及び付加サービスを抽出した後、抽出されたメイン視聴覚コンテンツ及び抽出した付加サービスに対してチャネル符号化を行って、分配のための多重化信号を生成することができる。このとき、マルチチャネルビデオ分配サーバー３０は、抽出した付加サービスを除外することも、別の付加サービスを追加することも可能であるため、放送局は放送局主導のサービスを提供することができない。１つ以上のマルチチャネルビデオ分配サーバーが存在してもよい。
放送受信装置６０は、ユーザの選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信した信号に対して復調及びチャネル復号を行ってメイン視聴覚コンテンツを抽出する。そして、放送受信装置６０は、抽出したメイン視聴覚コンテンツを、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−４ ａｄｖａｎｃｅｄ ｖｉｄｅｏ ｃｏｄｉｎｇ）、Ｄｏｌｂｙ ＡＣ−３、ＭＰＥＧ−２ ＡＡＣ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２ Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）アルゴリズムなどを用いて復号して非圧縮メイン視聴覚コンテンツ（ｕｎｃｏｍｐｒｅｓｓｅｄ ｍａｉｎ ＡＶ ｃｏｎｔｅｎｔ）を生成する。放送受信装置６０は、生成した非圧縮メイン視聴覚コンテンツを、映像表示装置１００の外部入力ポートなどを介して映像表示装置１００に提供する。
付加サービス情報提供サーバー４０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツに関連した１つ以上の利用可能な付加サービスのための付加サービス情報を提供する。１つ以上の付加サービスアドレス提供サーバーが存在してもよい。付加サービス情報提供サーバー４０は、複数の利用可能な付加サービスのうち、最も優先順位の高い付加サービスのための付加サービス情報を提供することもできる。
付加サービス提供サーバー５０は、映像表示装置の要求に応答して、メイン視聴覚コンテンツと関連して利用可能な１つ以上の付加サービスを提供する。１つ以上の付加サービス提供サーバーが存在してもよい。
映像表示装置１００は、テレビ、ノートパソコン、携帯電話、スマートフォンなどのようにディスプレイ部を有する装置であってもよい。映像表示装置１００は、放送受信装置６０から非圧縮のメイン視聴覚コンテンツを受信することもでき、コンテンツ提供サーバー１０又はマルチチャネルビデオ分配サーバー３０から、符号化されたメイン視聴覚コンテンツを含む放送信号を受信することもできる。映像表示装置１００は、ネットワーク７０を介してコンテンツ認識サービス提供サーバー２０からコンテンツ認識サービス提供を受けることができ、ネットワーク７０を介して付加サービス情報提供サーバー４０から、メイン視聴覚コンテンツと関連して利用可能な１つ以上の付加サービスのアドレスを受けることができ、付加サービス提供サーバー５０から、メイン視聴覚コンテンツと関連して利用可能な１つ以上の付加サービスの提供を受けることができる。
コンテンツ提供サーバー１０、コンテンツ認識サービス提供サーバー２０、マルチチャネルビデオ分配サーバー３０、付加サービス情報提供サーバー４０、複数の付加サービス提供サーバー５０のうち２つ以上を１つのサーバーの形態で結合してもよく、一つの事業者によって運営されてもよい。
図９は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジを示すブロック図である。
図９に示すように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１をさらに含む。
図９に示すようなウォーターマークサーバー２１は、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにコンテンツ情報を挿入する。マルチチャネルビデオ分配サーバー３０は、変形されたメイン視聴覚コンテンツを含む放送信号を受信して分配する。特に、ウォーターマークサーバーは、以下に説明するようなデジタルウォーターマーキング技術を用いることができる。
デジタルウォーターマークは、削除し難い方法でデジタル信号に情報を挿入するプロセスである。例えば、デジタル信号は、オーディオ、写真、又はビデオであってもよい。このデジタル信号が複写されると、挿入された情報も複写本に含まれる。一つのデジタル信号が同時に別個の複数のウォーターマークを運搬することができる。
見えるウォーターマーキング（ｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋｉｎｇ）において、挿入される情報は、写真又はビデオにおいて目で識別可能である。典型的に、挿入された情報は、メディアの所有者を識別するテキスト又はロゴである。テレビ放送局が自身のロゴを、伝送されるビデオのコーナーに追加すれば、これが目で識別可能なウォーターマークである。
目で識別不可能なウォーターマーキング（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋｉｎｇ）において、情報は、デジタルデータとしてオーディオ、写真、又はビデオに追加されるが、一定量の情報が隠れているという事実は感知できても、そのような情報を認知することはできない。このような目で識別不可能なウォーターマーキングを用いて秘密メッセージを伝達することもできる。
ウォーターマーキングの一つの応用は、デジタルメディアの不正複製を防止のための著作権保護システムにある。例えば、複製装置は、デジタルメディアの複製前にデジタルメディアからウォーターマークを得て、ウォーターマークの内容に基づいて複製をするか否かを決定することができる。
ウォーターマーキングの他の応用は、デジタルメディアの出処の追跡にある。配布経路上の各地点でウォーターマークがデジタルメディアに埋め込まれる。後でこのようなデジタルメディアが発見されると、このデジタルメディアからウォーターマークを抽出し、ウォーターマークの内容から配布の出処を把握することができる。
デジタルメディアに関する説明が、目で識別不可能なウォーターマーキングの他の一応用である。
デジタルメディアのためのファイルフォーマットが、メタデータと呼ばれる追加的な情報を含むことができるが、デジタルウォーターマークは、デジタルメディアの視聴覚信号自体で伝達されるという点でメタデータとは区別される。
ウォーターマーキング方法には、スプレッドスペクトル、量子化、アンプリチュード変調がある。
マーキングされる信号が追加的な修正によって得られる場合、ウォーターマーキング方法はスプレッドスペクトルに該当する。スプレッドスペクトルウォーターマークはかなり強じんなものと知られているが、ウォーターマークの埋め込まれるホスト信号に干渉を与えることから、多くの情報が載せられることはない。
マーキングされる信号が量子化によって得られる場合、ウォーターマーキング方法は量子化タイプに該当する。量子化ウォーターマークは、強じん性は低いが、かなり多い情報を載せることができる。
マーキングされる信号が空間ドメインでスプレッドスペクトルに類似の追加修正方法によって得られる場合、ウォーターマーキング方法はアンプリチュード変調に該当する。
図１０は、本発明の一実施例に係るウォーターマークベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ１０１）。
ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにロゴのような見えるウォーターマーク（ｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）を挿入したり、メイン視聴覚コンテンツにウォーターマーク情報を見えないウォーターマーク（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）として挿入し、ウォーターマーキングされたメイン視聴覚コンテンツと付加サービスをＭＶＰＤ３０に提供する（Ｓ１０３）。
見えないウォーターマークによって挿入されるウォーターマーク情報は、ウォーターマーク用途、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。ウォーターマーク用途は、無断複製防止、視聴率調査、付加サービス取得のうち１つを示すことができる。
コンテンツ情報は、メイン視聴覚コンテンツを提供するコンテンツプロバイダの識別情報、メイン視聴覚コンテンツ識別情報、メイン視聴覚コンテンツ等級情報、コンテンツ情報の取得に用いられたコンテンツ区間の時間情報、メイン視聴覚コンテンツが放送されるチャネルの名、メイン視聴覚コンテンツが放送されるチャネルのロゴ、メイン視聴覚コンテンツが放送されるチャネルの説明、利用情報報告アドレス、利用情報報告周期、利用情報の取得のための最小利用時間、メイン視聴覚コンテンツに関連して利用可能な付加サービス情報のうち１つ以上を含むことができる。
映像表示装置１００がコンテンツ情報の取得のためにウォーターマークを用いた場合には、コンテンツ情報の取得に用いられたコンテンツ区間の時間情報は、利用されたウォーターマークが埋め込まれた（ｅｍｂｅｄｅｄ）コンテンツ区間の時間情報であってもよい。映像表示装置１００がコンテンツ情報の取得のためにフィンガープリントを用いた場合には、コンテンツ情報の取得に用いられたコンテンツ区間の時間情報は、特徴情報が抽出されたコンテンツ区間の時間情報であってもよい。コンテンツ情報の取得に用いられたコンテンツ区間の時間情報は、コンテンツ情報の取得に用いられたコンテンツ区間の開始時間、コンテンツ情報の取得に用いられたコンテンツ区間の持続時間（ｄｕｒａｔｉｏｎ）、コンテンツ情報の取得に用いられたコンテンツ区間の終了時間のうち１つ以上を含むことができる。
利用情報報告アドレスは、メイン視聴覚コンテンツ視聴情報報告アドレス、付加サービス利用情報報告アドレスのうち１つ以上を含むことができる。利用情報報告周期は、メイン視聴覚コンテンツ視聴情報報告周期、付加サービス利用情報報告周期のうち１つ以上を含むことができる。利用情報取得のための最小利用時間は、メイン視聴覚コンテンツ視聴情報取得のための最小視聴時間、付加サービス利用情報抽出のための最小使用時間のうち１つ以上を含むことができる。
メイン視聴覚コンテンツが最小視聴時間以上視聴された場合に基づいて、映像表示装置１００はメイン視聴覚コンテンツの視聴情報を取得し、メイン視聴覚コンテンツ視聴情報報告周期でメイン視聴覚コンテンツ視聴情報報告アドレスに、抽出した視聴情報を報告することができる。
付加サービスが最小使用時間以上用いられた場合に基づいて、映像表示装置１００は付加サービス利用情報を取得し、付加サービス利用情報報告周期で付加サービス利用情報報告アドレスに、抽出した利用情報を報告することができる。
付加サービス情報は、付加サービスが存在するか否かに関する情報、付加サービスアドレス提供サーバーアドレス、それぞれの利用可能な付加サービスの取得経路、それぞれの利用可能な付加サービスのためのアドレス、それぞれの利用可能な付加サービスの開始時間、それぞれの利用可能な付加サービスの終了時間、それぞれの利用可能な付加サービスの寿命周期（ｌｉｆｅｔｉｍｅ）、それぞれの利用可能な付加サービスの取得モード、それぞれの利用可能な付加サービスのための要求周期、それぞれの利用可能な付加サービスの優先順位情報、それぞれの利用可能な付加サービスの説明、それぞれの利用可能な付加サービスの項目（ｃａｔｅｇｏｒｙ）、利用情報報告アドレス、利用情報報告周期、利用情報取得のための最小利用時間のうち１つ以上を含むことができる。
利用可能な付加サービスの取得経路は、ＩＰ又はＡＴＳＣ Ｍ／Ｈ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）を示すことができる。利用可能な付加サービスの取得経路がＡＴＳＣ Ｍ／Ｈである場合、付加サービス情報は周波数情報、チャネル情報をさらに含むことができる。それぞれの利用可能な付加サービスの取得モードは、Ｐｕｓｈ又はＰｕｌｌを示すことができる。
一方、ウォーターマークサーバー２１は、メイン視聴覚コンテンツのロゴにウォーターマーク情報を、見えないウォーターマーク（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）として挿入することができる。
例えば、ウォーターマークサーバー２１は、ロゴの一定位置にバーコードを挿入することができる。このとき、ロゴの一定位置は、ロゴがディスプレイされる区域における下端の１ラインに該当してもよい。映像表示装置１００は、このようにバーコードが挿入されたロゴを含むメイン視聴覚コンテンツを受信する場合に、バーコードをディスプレイしなくてもよい。
また、ウォーターマークサーバー２１は、ロゴのメタデータ形態でウォーターマーク情報を挿入することができる。このとき、ロゴの形状は維持されてもよい。
また、ウォーターマークサーバー２１は、Ｍ個のフレームのロゴのそれぞれにＮビットのウォーターマーク情報を挿入することができる。すなわち、ウォーターマークサーバー２１は、Ｍ個のフレームでＭ＊Ｎ個のウォーターマーク情報を挿入することができる。
ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ１０５）。このとき、多重化信号は、受信した付加サービスを排除したり、新しい付加サービスを含んでもよい。
放送受信装置６０は、ユーザの選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調してチャネル復号化（ｃｈａｎｎｅｌ ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ ｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ１０６）。
一方、コンテンツ提供サーバー１０も、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどで放送する（Ｓ１０７）。
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに、映像表示装置１００にメイン視聴覚コンテンツを含む放送信号を直接伝送することもできる（Ｓ１０８）。
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。又は、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを得ることもできる。又は、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当すると、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーアドレスの対応関係から、抽出したロゴに該当するウォーターマークサーバーアドレスを確認する。ウォーターマーク情報がロゴに該当する場合、映像表示装置１００は、ロゴだけではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも映像表示装置１００はメイン視聴覚コンテンツを識別できないが、ウォーターマーク情報がコンテンツプロバイダ識別情報又はウォーターマークサーバーアドレスを含むことはできる。ウォーターマーク情報がコンテンツプロバイダ識別情報を含む場合に、映像表示装置１００は、複数のコンテンツプロバイダ識別情報と複数のウォーターマークサーバーアドレスとの対応関係から、抽出したコンテンツプロバイダ識別情報に該当するウォーターマークサーバーアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報だけではメイン視聴覚コンテンツを識別できない場合、取得したウォーターマークサーバーアドレスに該当するウォーターマークサーバー２１に接続し、第１質疑を伝送する（Ｓ１０９）。
ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ１１１）。この第１応答は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。
ウォーターマーク情報と第１応答が付加サービスアドレスを含んでいないと、映像表示装置１００は付加サービスを取得することができない。しかし、ウォーターマーク情報と第１応答が付加サービスアドレス提供サーバーアドレスを含むことができる。このように、映像表示装置１００は、ウォーターマーク情報と第１応答を介して付加サービスアドレス又は付加サービスを取得することはできず、付加サービスアドレス提供サーバーアドレスを取得した場合には、映像表示装置１００は、取得した付加サービスアドレス提供サーバーアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ１１９）。
付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報に関連した１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ１２１）。
映像表示装置１００は、ウォーターマーク情報、第１応答又は第２応答によって１つ以上の利用可能な付加サービスアドレスを取得した場合には、この１つ以上の利用可能な付加サービスアドレスに接続して付加サービスを要求し（Ｓ１２３）、付加サービスを取得する（Ｓ１２５）。
図１１は、本発明の一実施例に係るウォーターマークベースのコンテンツ認識タイミングを示す図である。
図１１に示すように、放送受信装置６０がターンオンされ、チャネルをチューニングし、映像表示装置１００が外部入力ポート１１１を介して放送受信装置６０からチューニングされたチャネルのメイン視聴覚コンテンツを受信すると、映像表示装置１００は、メイン視聴覚コンテンツのウォーターマークからコンテンツプロバイダ識別子（又は放送局識別子）を感知することができる。その後、映像表示装置１００は、感知したコンテンツプロバイダ識別子に基づいてメイン視聴覚コンテンツのウォーターマークからコンテンツ情報を感知することができる。
このとき、図１１に示すように、コンテンツプロバイダ識別子の感知可能周期とコンテンツ情報の感知可能周期とが異なってもよい。特に、コンテンツプロバイダ識別子の感知可能周期はコンテンツ情報の感知可能周期よりも短くてもよい。これによって、映像表示装置１００は、必要な情報だけを感知するための効率的な構成を有することができる。
図１２は、本発明の一実施例に係るフィンガープリントベースのネットワークトポロジを示すブロック図である。
図１２に示すように、本発明の一実施例に係るネットワークトポロジは、フィンガープリントサーバー２２をさらに含む。
図１２に示すようなフィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して保存する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子及び時間情報を提供する。
図１３は本発明の一実施例に係るフィンガープリントベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ２０１）。
フィンガープリントサーバー２２は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツの複数のフレーム区間又は複数のオーディオ区間から複数の特徴情報を抽出し、複数の特徴情報にそれぞれ対応する複数の質疑結果のためのデータベースを構築する（Ｓ２０３）。質疑結果は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。
ＭＶＰＤ３０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ２０５）。このとき、多重化信号は、受信した付加サービスを排除してもよく、新しい付加サービスを含んでもよい。
放送受信装置６０は、ユーザの選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調してチャネル復号化（ｃｈａｎｎｅｌ ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ ｄｅｃｏｄｉｎｇ）を行って非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ２０６）。
一方、コンテンツ提供サーバー１０も、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどで放送する（Ｓ２０７）。
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに、映像表示装置１００にメイン視聴覚コンテンツを含む信号を直接伝送することができる（Ｓ２０８）。
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。又は、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを得ることができる。又は、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを受信することができる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ２１３）。
映像表示装置１００は、あらかじめ設定されたフィンガープリントサーバーアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送する（Ｓ２１５）。
フィンガープリントサーバー２２は、第１質疑に対する第１応答として質疑結果を提供する（Ｓ２１７）。仮に第１応答が失敗に該当すると、映像表示装置１００は、他のフィンガープリントサーバーアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第１質疑を伝送することができる。
フィンガープリントサーバー２２は、質疑結果としてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書を提供することができる。以下、質疑結果が含まれるＸＭＬ文書の例を説明する。
図１４は、本発明の一実施例に係る質疑結果が含まれるＡＣＲ−ＲｅｓｕｌｔｔｙｐｅのＸＭＬスキマーダイヤグラム（ｓｃｈｅｍａ ｄｉａｇｒａｍ）を示す図である。
図１４に示すように、質疑結果が含まれるＡＣＲ−Ｒｅｓｕｌｔｔｙｐｅは、ＲｅｓｕｌｔＣｏｄｅ属性と、ＣｏｎｔｅｎｔＩＤ、ＮＴＰＴｉｍｅｓｔａｍｐ、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎ、ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントを有する。
例えば、ＲｅｓｕｌｔＣｏｄｅ属性が２００の値を有すると、これは質疑結果が成功であることを意味することができる。ＲｅｓｕｌｔＣｏｄｅ属性が４０４の値を有すると、これは質疑結果が失敗であることを意味することができる。
ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＩｎｆｏｒｍａｔｉｏｎエレメントは、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントを有し、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントは、ＵｐｄａｔｅＭｏｄｅ、ＰｏｌｌｉｎｇＣｙｃｌｅ属性を有する。ＵｐｄａｔｅＭｏｄｅ属性は、Ｐｕｌｌ値又はＰｕｓｈ値を有することができる。
ＳｅｒｖｉｃｅＩｎｆｏｒｍａｔｉｏｎエレメントは、ＳｅｒｖｉｃｅＮａｍｅ、ＳｅｒｖｉｃｅＬｏｇｏ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有する。
次表に、このような質疑結果が含まれるＡＣＲ−ＲｅｓｕｌｔＴｙｐｅのＸＭＬ Ｓｃｈｅｍａを示す。
Figure 0006294503
ＣｏｎｔｅｎｔＩＤエレメントとして、下記の表に示すようなＡＴＳＣコンテンツ識別子（ＡＴＳＣ ｃｏｎｔｅｎｔ ｉｄｅｎｔｉｆｉｅｒ）を用いることができる。
Figure 0006294503
上記の表に示したように、ＡＴＳＣコンテンツ識別子は、ＴＳＩＤとハウス番号で構成された構造を有する。
１６ビット符号無し整数ＴＳＩＤは、トランスポートストリーム識別子（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ ｉｄｅｎｔｉｆｉｅｒ）を含む（ｃａｒｒｙ）。
５ビット符号無し整数ｅｎｄ＿ｏｆ＿ｄａｙは、放送が終わってｃｏｎｔｅｎｔ＿ｉｄ値を再使用できる日付の時刻（ｈｏｕｒ）に設定される。
９ビット符号無し整数ｕｎｉｑｕｅ＿ｆｏｒは、ｃｏｎｔｅｎｔ＿ｉｄ値を再使用できない日数（ｔｈｅ ｎｕｍｂｅｒ ｏｆ ｄａｙ）に設定される。
ｃｏｎｔｅｎｔ＿ｉｄは、コンテンツ識別子を示す。映像表示装置１００は、毎日ｅｎｄ＿ｏｆ＿ｄａｙに該当する時刻でｕｎｉｑｕｅ＿ｆｏｒを１ずつ減少させ、ｕｎｉｑｕｅ＿ｆｏｒが０になっていないと、ｃｏｎｔｅｎｔ＿ｉｄが唯一のものであると見なすことができる。
一方、ＣｏｎｔｅｎｔＩＤエレメントとして、下記に説明するようなＡＴＳＣ−Ｍ／Ｈ ｓｅｒｖｉｃｅのためのグローバルサービス識別子（Ｇｌｏｂａｌ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を用いることができる。
グローバルサービス識別子は、次のようなフォームを有する。
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄ＞：＜ｓｅｒｖｉｃｅｉｄ＞
ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２によって規定されるような２個の文字からなる国際国家コードである。ローカルサービス（ｌｏｃａｌ ｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの十進数であり、地域サービス（ｒｅｇｉｏｎａｌ ｓｅｒｖｉｃｅ）（ｍａｊｏｒ ＞６９）のための＜ｘｓｉｄ＞は、“０”である。＜ｓｅｒｖｉｃｅｉｄ＞は、＜ｍａｊｏｒ＞又は＜ｍｉｎｏｒ＞と定義される。＜ｍａｊｏｒ＞は、メジャーチャネル番号（Ｍａｊｏｒ Ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）を示し、＜ｍｉｎｏｒ＞は、マイナーチャネル番号（Ｍｉｎｏｒ Ｃｈａｎｎｅｌ Ｎｕｍｂｅｒ）を示す。
グローバルサービス識別子の例は、下記のとおりである。
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：１２３４：５．１
−ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｓｅｒｖｉｃｅ：ｕｓ：０：１００．２００
一方、ＣｏｎｔｅｎｔＩＤエレメントとして、下記に説明するようなＡＴＳＣコンテンツ識別子を用いることができる。
ＡＴＳＣコンテンツ識別子は、次のようなフォームを有する。
ｕｒｎ：ｏｍａ：ｂｃａｓｔ：ｉａｕｔｈ：ａｔｓｃ：ｃｏｎｔｅｎｔ：＜ｒｅｇｉｏｎ＞：＜ｘｓｉｄｚ＞：＜ｃｏｎｔｅｎｔｉｄ＞：＜ｕｎｉｑｕｅ＿ｆｏｒ＞：＜ｅｎｄ＿ｏｆ＿ｄａｙ＞
ここで、＜ｒｅｇｉｏｎ＞は、ＩＳＯ６３９−２によって規定されるような２個の文字からなる国際国家コードである。ローカルサービス（ｌｏｃａｌ ｓｅｒｖｉｃｅ）のための＜ｘｓｉｄ＞は、＜ｒｅｇｉｏｎ＞で定義するようなＴＳＩＤの十進数であり、“．”＜ｓｅｒｖｉｃｅｉｄ＞が続いてもよい。地域サービス（ｒｅｇｉｏｎａｌ ｓｅｒｖｉｃｅ）（ｍａｊｏｒ＞６９）のための＜ｘｓｉｄ＞は、＜ｓｅｒｖｉｃｅｉｄ＞である。＜ｃｏｎｔｅｎｔ＿ｉｄ＞は、上記の表に定義されているｃｏｎｔｅｎｔ＿ｉｄ ｆｉｅｌｄのｂａｓｅ６４符号であり、＜ｕｎｉｑｕｅ＿ｆｏｒ＞は、上記の表に定義されているｕｎｉｑｕｅ＿ｆｏｒ ｆｉｅｌｄの十進数符号であり、＜ｅｎｄ＿ｏｆ＿ｄａｙ＞は、上記の表に定義されているｅｎｄ＿ｏｆ＿ｄａｙ ｆｉｅｌｄの十進数符号である。
続いて、再び図１３を説明する。
質疑結果が付加サービスアドレス又は付加サービスを含んでおらず、付加サービスアドレス提供サーバーアドレスを含んでいると、映像表示装置１００は、取得した付加サービスアドレス提供サーバーアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第２質疑を伝送する（Ｓ２１９）。
付加サービス情報提供サーバー４０は、第２質疑のコンテンツ情報に関連した１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第２質疑に対する第２応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を映像表示装置１００に提供する（Ｓ２２１）。
映像表示装置１００は、第１応答又は第２応答から１つ以上の利用可能な付加サービスアドレスを取得すると、この１つ以上の利用可能な付加サービスアドレスに接続し、付加サービスを要求して（Ｓ２２３）、付加サービスを取得する（Ｓ２２５）。
ＵｐｄａｔｅＭｏｄｅ属性がＰｕｌｌ値を有する場合、映像表示装置１００は、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬを介してＨＴＴＰ要求を付加サービス提供サーバー５０に伝送し、これに対する応答として、ＰＳＩＰバイナリストリームを含むＨＴＴＰ応答を付加サービス提供サーバー５０から受信する。この場合、映像表示装置１００は、ＰｏｌｌｉｎｇＣｙｃｌｅ属性で指定されるＰｏｌｌｉｎｇ周期によってＨＴＴＰ要求を伝送することができる。また、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬエレメントは、アップデート時間属性を有することができる。この場合、映像表示装置１００は、アップデート時間属性で指定されるアップデート時間でＨＴＴＰ要求を伝送することができる。
ＵｐｄａｔｅＭｏｄｅ属性がＰｕｓｈ値を有する場合、映像表示装置１００は、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔ ＡＰＩを活用して非同期的にサーバーからアップデートを受信することができる。映像表示装置１００がサーバーに、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔ ｏｂｊｅｃｔを介して非同期的な要求をした後、サーバーが、シグナリング情報に変更がある場合に、このチャネルを介して応答として、シグナリング情報を提供する方案である。セッションの待機時間に制限がある場合には、ｓｅｓｓｉｏｎ ｔｉｍｅｏｕｔ ｒｅｓｐｏｎｄを発生させ、直ちに受信機はこれを認知し、再要求をして、受信機とサーバー間のシグナリングチャネルを常時維持することができる。
図１５は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジを示すブロック図である。
図１５に示すように、本発明の一実施例に係るネットワークトポロジは、ウォーターマークサーバー２１及びフィンガープリントサーバー２２をさらに含む。
図１５に示すようなウォーターマークサーバー２１は、メイン視聴覚コンテンツにコンテンツプロバイダ識別情報を挿入する。ウォーターマークサーバー２１は、ロゴのような見えるウォーターマークとしてコンテンツプロバイダ識別情報をメイン視聴覚コンテンツに挿入してもよく、見えないウォーターマークとしてコンテンツプロバイダ識別情報をメイン視聴覚コンテンツに挿入してもよい。
フィンガープリントサーバー２２は、メイン視聴覚コンテンツに変形を加えず、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出して保存する。その後、フィンガープリントサーバー２２は、映像表示装置１００からの特徴情報を受信すると、受信した特徴情報に該当する視聴覚コンテンツの識別子及び時間情報を提供する。
図１６は、本発明の一実施例に係るウォーターマーク及びフィンガープリントベースのネットワークトポロジ内のデータ流れを示すラダーダイヤグラムである。
まず、コンテンツ提供サーバー１０は、メイン視聴覚コンテンツ及び付加サービスを含む放送信号を伝送する（Ｓ３０１）。
ウォーターマークサーバー２１は、コンテンツ提供サーバー１０が提供する放送信号を受信し、メイン視聴覚コンテンツに変形を加えて、メイン視聴覚コンテンツにロゴのような見えるウォーターマーク（ｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）を挿入したり、又はメイン視聴覚コンテンツにウォーターマーク情報を見えないウォーターマーク（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）として挿入し、ウォーターマーキングされたメイン視聴覚コンテンツと付加サービスをＭＶＰＤ３０に提供する（Ｓ３０３）。見えないウォーターマークを介して挿入されるウォーターマーク情報は、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、前述したとおりである。
ＭＶＰＤ３０は、ウォーターマーキングされたメイン視聴覚コンテンツ及び付加サービスを含む放送信号を受信し、多重化信号を生成して放送受信装置６０に提供する（Ｓ３０５）。このとき、多重化信号は、受信した付加サービスを排除してもよく、新しい付加サービスを含んでもよい。
放送受信装置６０は、ユーザの選択したチャネルをチューニングし、チューニングしたチャネルの信号を受信し、受信された放送信号を復調し、チャネル復号化（ｃｈａｎｎｅｌ ｄｅｃｏｄｉｎｇ）し、視聴覚復号（ＡＶ ｄｅｃｏｄｉｎｇ）を行って、非圧縮メイン視聴覚コンテンツを生成した後、生成された非圧縮メイン視聴覚コンテンツを映像表示装置１００に提供する（Ｓ３０６）。
一方、コンテンツ提供サーバー１０も、メイン視聴覚コンテンツを含む放送信号を無線チャネルなどで放送する（Ｓ３０７）。
また、ＭＶＰＤ３０は、放送受信装置６０を介さずに映像表示装置１００にメイン視聴覚コンテンツを含む信号を直接伝送することができる（Ｓ３０８）。
映像表示装置１００は、セットトップボックス６０を介して非圧縮メイン視聴覚コンテンツを受信することができる。又は、映像表示装置１００は、無線チャネルを介して放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを得ることもできる。又は、映像表示装置１００は、ＭＶＰＤ３０から放送信号を受信し、受信した放送信号を復調及び復号してメイン視聴覚コンテンツを受信することもできる。映像表示装置１００は、取得したメイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルからウォーターマーク情報を抽出する。ウォーターマーク情報がロゴに該当すると、映像表示装置１００は、複数のロゴと複数のウォーターマークサーバーアドレスとの対応関係から、抽出したロゴに該当するウォーターマークサーバーアドレスを確認する。ウォーターマーク情報がロゴに該当する場合に、映像表示装置１００は、ロゴだけではメイン視聴覚コンテンツを識別することができない。また、ウォーターマーク情報がコンテンツ情報を含んでいない場合にも映像表示装置１００はメイン視聴覚コンテンツを識別できないが、ウォーターマーク情報がコンテンツプロバイダ識別情報又はウォーターマークサーバーアドレスを含むことはできる。ウォーターマーク情報がコンテンツプロバイダ識別情報を含む場合に、映像表示装置１００は、複数のコンテンツプロバイダ識別情報と複数のウォーターマークサーバーアドレスとの対応関係から、抽出したコンテンツプロバイダ識別情報に該当するウォーターマークサーバーアドレスを確認することができる。このように、映像表示装置１００は、ウォーターマーク情報だけではメイン視聴覚コンテンツを識別できない場合、取得したウォーターマークサーバーアドレスに該当するウォーターマークサーバー２１に接続し、第１質疑を伝送する（Ｓ３０９）。
ウォーターマークサーバー２１は、第１質疑に対する第１応答を提供する（Ｓ３１１）。この第１応答は、フィンガープリントサーバーアドレス、コンテンツ情報、付加サービス情報、利用可能な付加サービスのうち１つ以上を含むことができる。コンテンツ情報と付加サービス情報は、前述したとおりである。
ウォーターマーク情報と第１応答がフィンガープリントサーバーアドレスを含んでいると、映像表示装置１００は、メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルから特徴情報を抽出する（Ｓ３１３）。
映像表示装置１００は、第１応答内のフィンガープリントサーバーアドレスに該当するフィンガープリントサーバー２２に接続し、抽出した特徴情報を含む第２質疑を伝送する（Ｓ３１５）。
フィンガープリントサーバー２２は、第２質疑に対する第２応答として質疑結果を提供する（Ｓ３１７）。
質疑結果が付加サービスアドレス又は付加サービスを含んでおらず、付加サービスアドレス提供サーバーアドレスを含んでいると、映像表示装置１００は、取得した付加サービスアドレス提供サーバーアドレスに該当する付加サービス情報提供サーバー４０に接続し、コンテンツ情報を含む第３質疑を伝送する（Ｓ３１９）。
付加サービス情報提供サーバー４０は、第３質疑のコンテンツ情報に関連した１つ以上の利用可能な付加サービスを検索する。その後、付加サービス情報提供サーバー４０は、第３質疑に対する第３応答として、１つ以上の利用可能な付加サービスのための付加サービス情報を、映像表示装置１００に提供する（Ｓ３２１）。
映像表示装置１００は、第１応答、第２応答、又は第３応答から、１つ以上の利用可能な付加サービスアドレスを取得すると、この１つ以上の利用可能な付加サービスアドレスに接続し、付加サービスを要求して（Ｓ３２３）、付加サービスを取得する（Ｓ３２５）。
次に、図１７を参照して、本発明の実施例に係る映像表示装置１００を説明する。
図１７は、本発明の実施例に係る映像表示装置のブロック図である。
図１７に示すように、本発明の実施例に係る映像表示装置１００は、放送信号受信部１０１、復調部１０３、チャネル復号部１０５、逆多重化部１０７、視聴覚復号部１０９、外部入力ポート１１１、再生制御部１１３、再生装置１２０、付加サービス管理部１３０、データ送受信部１４１、メモリ１５０を含む。
放送信号受信部１０１は、コンテンツ提供サーバー１０又はＭＶＰＤ３０から放送信号を受信する。
復調部１０３は、受信した放送信号を復調し、復調された信号を生成する。
チャネル復号部１０５は、復調された信号をチャネル復号し、チャネル復号されたデータを生成する。
逆多重化部１０７は、チャネル復号されたデータからメイン視聴覚コンテンツと付加サービスを分離する。分離された付加サービスは付加サービス保存部１５２に保存される。
視聴覚復号部１０９は、分離されたメイン視聴覚コンテンツを視聴覚復号（ＡＶ ｄｅｃｏｄｉｎｇ）して非圧縮メイン視聴覚コンテンツを生成する。
一方、外部入力ポート１１１は、放送受信装置６０、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）プレーヤー、ブルーレイディスク（Ｂｌｕ−ｒａｙ（登録商標） ｄｉｓｃ）プレーヤーなどから非圧縮メイン視聴覚コンテンツを受信する。外部入力ポート１１１は、ＤＳＵＢポート、ＨＤＭＩ（登録商標）（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ポート、ＤＶＩ（Ｄｉｇｉｔａｌ Ｖｉｓｕａｌ Ｉｎｔｅｒｆａｃｅ）ポート、コンポジット（ｃｏｍｐｏｓｉｔｅ）ポート、コンポーネント（ｃｏｍｐｏｎｅｎｔ）ポート、Ｓ−Ｖｉｄｅｏポートのうち１つ以上を含むことができる。
再生制御部１１３は、視聴覚復号部１０９が生成する非圧縮メイン視聴覚コンテンツ又は外部入力ポート１１１から受信した非圧縮メイン視聴覚コンテンツの少なくとも１つをユーザ選択によって再生装置１２０に再生する。
再生装置１２０は、ディスプレイ部１２１及びスピーカ１２３を含む。ディスプレイ部１２１は、液晶ディスプレイ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：ＬＣＤ）、薄膜トランジスタ液晶ディスプレイ（ｔｈｉｎ ｆｉｌｍ ｔｒａｎｓｉｓｔｏｒ−ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：ＴＦＴ ＬＣＤ）、有機発光ダイオード（ｏｒｇａｎｉｃ ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ：ＯＬＥＤ）、フレキシブルディスプレイ（ｆｌｅｘｉｂｌｅ ｄｉｓｐｌａｙ）、３次元ディスプレイ（３Ｄ ｄｉｓｐｌａｙ）の少なくとも１つを含むことができる。
付加サービス管理部１３０は、メイン視聴覚コンテンツのコンテンツ情報を取得し、取得されたコンテンツ情報に基づいて利用可能な付加サービスを取得する。特に、前述したように、付加サービス管理部１３０は、非圧縮メイン視聴覚コンテンツの一部のフレーム又は一部の区間のオーディオサンプルに基づいてメイン視聴覚コンテンツの識別情報を取得することができ、本明細書では、これを自動コンテンツ認識（ａｕｔｏｍａｔｉｃ ｃｏｎｔｅｎｔｓ ｒｅｃｏｇｎｉｔｉｏｎ：ＡＣＲ）とも称する。
データ送受信部１４１は、ＡＴＳＣ−Ｍ／Ｈ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）チャネル送受信部１４１ａ及びＩＰ送受信部１４１ｂを含むことができる。
メモリ１５０は、フラッシュメモリタイプ（ｆｌａｓｈ ｍｅｍｏｒｙ ｔｙｐｅ）、ハードディスクタイプ（ｈａｒｄ ｄｉｓｋ ｔｙｐｅ）、マルチメディアカードマイクロタイプ（ｍｕｌｔｉｍｅｄｉａ ｃａｒｄ ｍｉｃｒｏ ｔｙｐｅ）、カードタイプのメモリ（例えば、ＳＤ又はＸＤメモリなど）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気メモリ、磁気ディスク、光ディスクのうち少なくとも１つのタイプの記憶媒体を含むことができる。映像表示装置１００は、インターネット（ｉｎｔｅｒｎｅｔ）上で上記メモリ１５０の保存機能を行うウェブストレージ（ｗｅｂ ｓｔｏｒａｇｅ）と関連付いて動作することもできる。
メモリ１５０は、コンテンツ情報保存部１５１、付加サービス保存部１５２、ロゴ保存部１５３、設定情報保存部１５４、ブックマーク保存部１５５、ユーザ情報保存部１５６、利用情報保存部１５７を含むことができる。
コンテンツ情報保存部１５１は、複数の特徴情報に対応する複数のコンテンツ情報を保存する。
付加サービス保存部１５２は、複数の特徴情報に対応する複数の付加サービスを保存することもでき、複数のコンテンツ情報に対応する複数の付加サービスを保存することもできる。
ロゴ保存部１５３は、複数のロゴを保存する。また、ロゴ保存部は、この複数のロゴに対応するコンテンツプロバイダ識別子又は複数のロゴに対応するウォーターマークサーバーアドレスをさらに保存することもできる。
設定情報保存部１５４は、ＡＣＲのための設定情報を保存する。
ブックマーク保存部１５５は、ブックマークを保存する。
ユーザ情報保存部１５６は、ユーザ情報を保存する。ユーザ情報は、１つ以上のサービスのための１つ以上のアカウント情報、地域情報、家族構成員情報、選好ジャンル情報、映像表示装置情報、利用情報提供範囲のうち１つ以上を含むことができる。１つ以上のアカウント情報は、利用情報測定サーバーのためのアカウント情報、ツイッター（登録商標）（ｔｗｉｔｔｅｒ）、フェイスブック（ｆａｃｅｂｏｏｋ）のようなソーシャルネットワークサービス（ｓｏｃｉａｌ ｎｅｔｗｏｒｋ ｓｅｒｖｉｃｅ）のアカウント情報を含むことができる。地域情報は、アドレス情報、郵便番号を含むことができる。家族構成員情報は、家族構成員の数、各構成員の年齢、各構成員の性別、各構成員の宗教、各構成員の職業などを含むことができる。選好ジャンル情報は、スポーツ、映画、ドラマ、教育、ニュース、娯楽、その他ジャンルのうち１つ以上に設定されてもよい。映像表示装置情報は、映像表示装置の種類、メーカー、ファームウェアバージョン、解像度、モデル名、ＯＳ、ブラウザ、保存装置の有無、保存装置の容量、ネットワーク速度に関する情報を含むことができる。利用情報提供範囲が設定されると、映像表示装置１００は、設定された範囲内でメイン視聴覚コンテンツ視聴情報と付加サービス利用情報を収集し、報告することができる。利用情報提供範囲は、仮想チャネルのそれぞれに対して設定されてもよい。また、利用情報測定許容範囲は、全物理チャネルに対して設定されてもよい。
利用情報保存部１５７は、映像表示装置１００によって収集されるメイン視聴覚コンテンツ視聴情報と付加サービス利用情報を保存する。また、映像表示装置１００は、収集したメイン視聴覚コンテンツ視聴情報と収集した付加サービス利用情報に基づいてサービス利用パターンを分析し、分析されたサービス利用パターンを利用情報保存部１５７に保存することができる。
付加サービス管理部１３０は、フィンガープリントサーバー２２又はコンテンツ情報保存部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。コンテンツ情報保存部１５１に、抽出した特徴情報に該当するコンテンツ情報がないか又は十分のコンテンツ情報がない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加コンテンツ情報を受信することができる。また、付加サービス管理部１３０は持続的にコンテンツ情報をアップデートすることができる。
付加サービス管理部１３０は、付加サービス提供サーバー５０又は付加サービス保存部１５３から利用可能な付加サービスを取得することができる。付加サービス保存部１５３に付加サービスがないか又は十分の付加サービスがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して付加サービスをアップデートすることができる。また、付加サービス管理部１３０は持続的に付加サービスをアップデートすることができる。
付加サービス管理部１３０は、メイン視聴覚コンテンツからロゴを抽出し、ロゴ保存部１５５に質疑して、抽出したロゴに対応するコンテンツプロバイダ識別子又はウォーターマークサーバーアドレスを取得することができる。ロゴ保存部１５５に、抽出したロゴと一致するロゴがないか又は十分のロゴがない場合、付加サービス管理部１３０は、データ送受信部１４１を介して追加ロゴを受信することができる。また、付加サービス管理部１３０は持続的にロゴをアップデートすることができる。
付加サービス管理部１３０は、メイン視聴覚コンテンツから抽出したロゴとロゴ保存部１５５内の複数のロゴとの比較を行うが、演算の負担を軽減するための様々な方法を行うこともできる。
例えば、付加サービス管理部１３０は、色特性に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴの色特性とロゴ保存部１５５内のロゴの色特性とを比較し、一致するか否かを判断できる。
また、付加サービス管理部１３０は、文字認識に基づいて比較を行うことができる。すなわち、付加サービス管理部１３０は、抽出したロゴから認識される文字とロゴ保存部１５５内のロゴから認識される文字とを比較し、一致するか否かを判断できる。
また、付加サービス管理部１３０は、ロゴの輪郭に対する形状に基づいて比較を行うこともできる。すなわち、付加サービス管理部１３０は、抽出したロゴの輪郭形状とロゴ保存部１５５内のロゴの輪郭形状とを比較し、一致するか否かを判断できる。
次に、図１８及び図１９を参照して、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を説明する。
図１８は、本発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示すフローチャートである。
付加サービス情報は、付加サービスの開始時間を含むことができる。このとき、映像表示装置１００は、この開始時間で付加サービスを始める必要がある。しかし、映像表示装置１００は、タイムスタンプを有しない非圧縮メイン視聴覚コンテンツを伝送する信号を受信するので、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とが異なる。映像表示装置１００が時間情報を有するメイン視聴覚コンテンツを受信しても、再放送などのように、メイン視聴覚コンテンツの再生時間の基準と付加サービスの開始時間の基準とが異なることがある。したがって、映像表示装置１００は、メイン視聴覚コンテンツの基準時間と付加サービスの基準時間とを同期化する必要がある。特に、映像表示装置１００は、メイン視聴覚コンテンツの再生時間と付加サービスの開始時間とを同期化する必要がある。
まず、付加サービス管理部１３０は、メイン視聴覚コンテンツの一部の区間を抽出する（Ｓ８０１）。メイン視聴覚コンテンツの一部の区間は、メイン視聴覚コンテンツの一部のビデオフレームと一部のオーディオ区間のうち１つ以上を含むことができる。付加サービス管理部１３０がメイン視聴覚コンテンツの一部の区間を抽出した時間をＴｎという。
付加サービス管理部１３０は、抽出された区間に基づいてメイン視聴覚コンテンツのコンテンツ情報を取得する（Ｓ８０３）。具体的に、付加サービス管理部１３０は、抽出された区間に見えないウォーターマーク（ｉｎｖｉｓｉｂｌｅ ｗａｔｅｒｍａｒｋ）で符号化された情報を復号してコンテンツ情報を取得することができる。また、付加サービス管理部１３０は、抽出された区間の特徴情報を抽出し、抽出された特徴情報に基づいてフィンガープリントサーバー２２又はコンテンツ情報保存部１５１からメイン視聴覚コンテンツのコンテンツ情報を取得することができる。付加サービス管理部１３０がコンテンツ情報を取得した時間をＴｍという。
一方、コンテンツ情報は、抽出された区間の開始時間（Ｔｓ）を含む。付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）以降では、時間（Ｔｓ）、時間（Ｔｍ）、時間（Ｔｎ）に基づいて、メイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化する（Ｓ８０５）。具体的に、付加サービス管理部１３０は、コンテンツ情報取得時間（Ｔｍ）を新しく計算される時間（Ｔｐ）と見なす。ここで、Ｔｐ＝Ｔｓ＋（Ｔｍ−Ｔｎ）といえる。
そして、付加サービス管理部１３０は、コンテンツ情報取得時間から時間（Ｔｘ）が経過した時間を、Ｔｐ＋Ｔｘと見なすことができる。
その後、付加サービス管理部１３０は、取得したコンテンツ情報に基づいて付加サービスと付加サービスの開始時間（Ｔａ）を取得する（Ｓ８０７）。
メイン視聴覚コンテンツの同期化された再生時間が付加サービスの開始時間（Ｔａ）と一致れば、付加サービス管理部１３０は、取得した付加サービスを始める（Ｓ８０９）。具体的に、付加サービス管理部１３０は、Ｔｐ＋Ｔｘ＝Ｔａを満たす場合に付加サービスを始めることができる。
図１９は、発明の実施例によってメイン視聴覚コンテンツの再生時間と付加サービスの再生時間とを同期化する方法を示す概念図である。
図１９に示すように、映像表示装置１００は、システム時間Ｔｎで視聴覚サンプルを抽出する。
映像表示装置１００は、抽出した視聴覚サンプルから特徴情報を抽出し、抽出した特徴情報を含む質疑をフィンガープリントサーバー２２に伝送して、質疑結果を受信する。映像表示装置１００は質疑結果をパースし、抽出した視聴覚サンプルの開始時間Ｔｓが１１０００ｍｓに該当することを時間Ｔｍで確認する。
したがって、映像表示装置は、抽出した視聴覚サンプルの開始時間を確認した時点をＴｓ＋（Ｔｍ−Ｔｎ）と見なして、その後からメイン視聴覚コンテンツの再生時間を付加サービスの開始時間と同期化すことができる。
図２０は、本発明の他の実施例に係るフィンガープリントベースの映像表示装置の構造を示すブロック図である。
図２０で、チューナ５０１は、無線チャネルで伝送される８−ＶＳＢ ＲＦ信号からシンボルを抽出する。
８−ＶＳＢ復調器５０３は、チュ−ナ−５０１で抽出された８−ＶＳＢシンボルを復調して、有意なデジタルデータを復元する。
ＶＳＢデコーダ５０５は、８−ＶＳＢ復調器５０３で復元されたデジタルデータを復号して、ＡＴＳＣメインサービス及びＡＴＳＣＭ／Ｈサービスを復元する。
ＭＰＥＧ−２ＴＰ逆多重化器５０７は、８−ＶＳＢ信号を通じて伝送されるＭＰＥＧ−２伝送パケット又はＰＶＲストレージに保存されたＭＰＥＧ−２伝送パケットのうち、映像表示装置１００が処理しようとする伝送パケットをフィルタリングして適切な処理モジュールに中継する。
ＰＥＳデコーダ５３９は、ＭＰＥＧ−２伝送ストリームを通じて伝送されたパケット化エレメンタリストリームをバッファして復元する。
ＰＳＩ／ＰＳＩＰデコーダ５４１は、ＭＰＥＧ−２伝送ストリームを通じて伝送されるＰＳＩ／ＰＳＩＰセクションデータをバッファして分析する。分析されたＰＳＩ／ＰＳＩＰデータはサービスマネジャー（図示せず）によって収集され、サービスマップ及びガイドデータの形態でＤＢに保存される。
ＤＳＭＣＣセクションバッファ／ハンドラ５１１は、ＭＰＥＧ−２ＴＰを通じて伝送されるファイル伝送及びＩＰデータグラムカプセル化などのためのＤＳＭＣＣセクションデータをバッファして（Ｂｕｆｆｅｒｉｎｇ）処理する。
ＩＰ／ＵＤＰデータグラムバッファ/ヘッダーパーサー５１３は、ＤＳＭＣＣアドレサブルセクションでカプセル化され、ＭＰＥＧ−２ＴＰを通じて伝送されるＩＰデータグラムをバッファして復元し、各データグラムのヘッダーを分析する。また、ＩＰ／ＵＤＰデータグラムバッファ/ヘッダーパーサー５１３は、ＩＰデータグラムを通じて伝送されるＵＤＰデータグラムをバッファリング及び復元して、復元されたＵＤＰヘッダーを分析及び処理する。
ストリームコンポーネントハンドラ５５７は、ＥＳバッファ／ハンドラ、ＰＣＲハンドラ、ＳＴＣモジュール、デスクランブラ、ＣＡストリームバッファ／ハンドラ、サービスシグナリングセクションバッファ／ハンドラを含むことができる。
ＥＳバッファ／ハンドラは、ＰＥＳ形態で伝送されたビデオ、オーディオデータなどのエレメンタリストリームをバッファリング及び復元し、適切なＡ／Ｖデコーダに伝達する。
ＰＣＲハンドラは、オーディオ及びビデオストリームの時間同期化などのために用いられるＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）データを処理する。
ＳＴＣモジュールは、ＰＣＲハンドラを介して伝達された参照クロック値を用いて、Ａ／Ｖデコーダのクロック値を補正して時間同期化を行う。
受信されたＩＰデータグラムのペイロードにスクランブリングが適用された場合、デスクランブラはＣＡストリームハンドラから伝達された暗号化キーなどを用いてペイロードのデータを復元する。
ＣＡストリームバッファ／ハンドラは、ＭＰＥＧ−２ＴＳ又はＩＰストリームを通じて伝送される限定受信（Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ）機能のために伝送されるＥＭＭ、ＥＣＭなどのデスクランブリングのためキー値などのデータをバッファリング及び処理する。ＣＡストリームバッファ／ハンドラの出力はデスクランブラに伝達され、デスクランブラは、Ａ／Ｖデータ及びファイルデータなどを伝送するＭＰＥＧ−２ＴＰ又はＩＰデータグラムの暗号化解除作業を行う。
サービスシグナリングセクションバッファ／ハンドラは、ＩＰデータグラムの形態で伝送されるＮＲＴサービスシグナリングチャネルセクションデータをバッファリング及び復元して分析する。サービスマネジャー（図示せず）は、分析されたＮＲＴサービスシグナリングチャネルセクションデータを収集して、サービスマップ及びガイドデータの形態でＤＢに保存する。
Ａ／Ｖデコーダ５６１は、ＥＳハンドラを介して伝達されたオーディオ／ビデオデータの圧縮を復号化して、ユーザに示す（Ｐｒｅｓｅｎｔａｔｉｏｎ）。
ＭＰＥＧ−２サービス逆多重化器（図示せず）は、ＭＰＥＧ−２ＴＰバッファ／パーサー、デスクランブラ、ＰＶＲストレージモジュールを含むことができる。
ＭＰＥＧ−２ＴＰバッファ／パーサー（図示せず）は、８−ＶＳＢ信号を通じて伝送されるＭＰＥＧ−２伝送パケットをバッファリング及び復元して、伝送パケットヘッダーを検出及び処理する。
デスクランブラは、ＭＰＥＧ−２ＴＰのうち、スクランブルが適用されたパケットペイロードに対して、ＣＡストリームハンドラから伝達された暗号化キーなどを用いて、ペイロードのデータを復元する。
ＰＶＲストレージモジュールは、ユーザの要求などに応じて、８−ＶＳＢ信号を用いて受信されたＭＰＥＧ−２ＴＰを保存し、また、ユーザの要求に応じてＭＰＥＧ−２ＴＰを出力する。ＰＶＲストレージモジュールは、マネジャー（図示せず）によって制御されてもよい。
ファイルハンドラ５５１は、ＡＬＣ／ＬＣＴバッファ／パーサー、ＦＤＴハンドラ、ＸＭＬパーサー、ファイル復元（Ｆｉｌｅ Ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ）バッファ、デコンプレッサ、ファイルデコーダ、ファイルストレージを含むことができる。
ＡＬＣ／ＬＣＴバッファ／パーサーは、ＵＤＰ／ＩＰストリームに伝送されるＡＬＣ／ＬＣＴデータをバッファリング及び復元して、ＡＬＣ／ＬＣＴのヘッダー及びヘッダー拡張を分析する。ＡＬＣ／ＬＣＴバッファ／パーサーは、ＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。
ＦＤＴハンドラは、ＡＬＣ／ＬＣＴセッションで伝送されるＦＬＵＴＥプロトコルのファイルデスクリプションテーブル（Ｆｉｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）を分析及び処理する。ＦＤＴハンドラは、ＮＲＴサービスマネジャー（図示せず）によって制御されてもよい。
ＸＭＬパーサーは、ＡＬＣ／ＬＣＴセッションで伝送されるＸＭＬドキャメントを分析し、分析されたデータを、ＦＤＴハンドラ、ＳＧハンドラなどの適切なモジュールに伝達する。
ファイル復元バッファは、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションで伝送されるファイルを復元する。
デコンプレッサは、ＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションで伝送されるファイルが圧縮されている場合、その圧縮を解除するプロセスを行う。
ファイルデコーダは、ファイル復元バッファで復元されたファイル又はデコンプレッサで圧縮解除されたファイル、又はファイルストレージで抽出されたファイルを復号する。
ファイルストレージは、復元されたファイルを必要によって保存したり抽出する。
Ｍ／Ｗエンジン（図示せず）は、ＤＳＭＣＣセクション、ＩＰデータグラムなどを通じて伝送されるＡ／Ｖストリームではなくファイルなどのデータを処理する。Ｍ／Ｗエンジンは、処理されたデータをプレゼンテーションマネジャーモジュールに伝達する。
ＳＧハンドラ（図示せず）は、ＸＭＬドキャメント形態で伝送されるサービスガイドデータを収集及び分析してＥＰＧマネジャーに伝達するプロセスを行う。
サービスマネジャー（図示せず）は、ＭＰＥＧ−２伝送ストリームで伝送されるＰＳＩ／ＰＳＩＰデータ、ＩＰストリームで伝送されるサービスシグナリングセクションデータを収集及び分析してサービスマップを製作する。サービスマネジャー（図示せず）は、製作したサービスマップをサービスマップ及びガイドデータベースに保存し、ユーザーの所望するサービスに対するアクセスを制御する。オペレーションコントローラ（図示せず）によって制御され、チュ−ナ−５０１、ＭＰＥＧ−２ＴＰ逆多重化器５０７、ＩＰデータグラムバッファ／ハンドラ５１３などに対する制御を行う。
ＮＲＴサービスマネジャー（図示せず）は、ＩＰ層上でＦＬＵＴＥセッションを介してオブジェクト／ファイルの形態で伝送されるＮＲＴサービスに対する全般的な管理を行う。ＮＲＴサービスマネジャー（図示せず）は、ＦＤＴハンドラ、ファイルストレージなどを制御することができる。
アプリケーションマネジャー（図示せず）は、オブジェクト、ファイルなどの形態で伝送されるアプリケーションデータの処理に関する全般的な管理を行う。
ＵＩマネジャー（図示せず）は、ユーザインタフェースを介してユーザの入力をオペレーションコントローラに伝達し、ユーザが要求するサービスのためのプロセスの動作を始める。
オペレーションコントローラ（図示せず）は、ＵＩマネジャーを介して伝達されたユーザの命令（Ｃｏｍｍａｎｄ）を処理し、必要なモジュールのマネジャーが該当のアクションを行うようにする。
フィンガープリント抽出器５６５は、オーディオ／ビデオストリームからフィンガープリント特徴情報を抽出する。
フィンガープリント比較器５６７は、フィンガープリント抽出器が抽出した特徴情報と参照フィンガープリントとを比較して、一致するコンテンツを探す。フィンガープリント比較器５６７は、ローカルに保存された参照フィンガープリントＤＢを利用してもよく、インターネット上のフィンガープリント質疑サーバーに質疑して結果を受信してもよい。比較の結果、マッチングされた結果データは、アプリケーションに伝達されて用いられてもよい。
アプリケーション５６９は、ＡＣＲ機能を管掌するモジュール或いはＡＣＲに基づいて付加サービスを提供するアプリケーションモジュールであり、視聴中の放送コンテンツを識別し、それに関連付いた拡張されたサービスを提供する。
図２１は、本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示すブロック図である。
図２１に示すウォーターマークベースの映像表示装置は、図２０に示すフィンガープリントベースの映像表示装置とほぼ同様であり、ただし、フィンガープリントベースの映像表示装置におけるフィンガープリント抽出器５６５及びフィンガープリント比較器５６７を含まず、その代わりに、ウォーターマーク抽出器５６６をさらに含む。
ウォーターマーク抽出器５６６は、オーディオ／ビデオストリームからウォーターマーク形態で挿入されたデータを抽出する。このように抽出されたデータはアプリケーションに伝達されて利用されてもよい。
図２２は、本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータを例示する図である。
前述したように、ＷＭを用いたＡＣＲは、非圧縮的オーディオ／ビデオのみに接近可能な環境（すなわち、ケーブル／衛星／ＩＰＴＶなどから受信する環境）で、その非圧縮的オーディオ／ビデオからコンテンツに対する付加サービス関連情報を得ることができるということに目的がある。このような環境をＡＣＲ環境と呼ぶことができる。ＡＣＲ環境で、受信機には非圧縮的オーディオ／ビデオデータだけが伝達されるため、受信機は、現在ディスプレイされているコンテンツがいかなるコンテンツであるか分からない。したがって、受信機は、ＷＭによって伝達されるコンテンツソースＩＤ、放送の現在時点、関連アプリケーションのＵＲＬ情報を用いて、ディスプレイされているコンテンツを識別し、インタラクティブサービスを提供してもよい。
オーディオ／ビデオウォーターマーク（ＷａｔｅｒＭａｒｋ：ＷＭ）を用いて放送に関連した付加サービスを伝達するとき、最も簡単な状況としては、全ての付加情報がＷＭによって伝達される場合を挙げることができる。この場合、全ての付加情報がＷＭ検出器によって検出され、受信機は検出された情報を一度で処理することができる。
しかしながら、この場合、オーディオ／ビデオデータにＷＭを挿入する量が増加すると、オーディオ／ビデオの全体クォリティーが低下しうる。この理由から、ＷＭには可能なかぎり最小限の必要データだけを挿入することを一目標とすることができる。最小限のデータをＷＭに挿入しながらも、多い情報を効率的に受信機が受信して処理できるようにする、ＷＭデータの構造を定義する必要がある。ＷＭに用いられるデータ構造は、伝達されるデータの量によって相対的に影響を少なく受けるフィンガープリンティング方式においても同様に用いることができる。
同図に示すように、本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータとしては、コンテンツソースのＩＤ、タイムスタンプ、インタラクティブアプリケーションのＵＲＬ、タイムスタンプの種類、ＵＲＬプロトコルの種類、アプリケーションイベント、デスティネーションの種類などを挙げることができる。その他にも、種々のデータが本発明によるＷＭ技法によって伝達されてもよい。
本発明は、ＷＭ技法によってＡＣＲが行われる場合において、ＷＭに含まれるデータの構造を提案する。図示するそれぞれのデータ種類に対して、最も効率的なデータ構造を本発明によって提案することができる。
本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータには、コンテンツソースのＩＤが含まれてもよい。セットトップボックスス（ｓｅｔ−ｔｏｐ ｂｏｘ）を用いた環境で、受信機（端末、ＴＶ）は、ＭＶＰＤがセットトップボックススを介してプログラム関連情報を共に伝達しないと、プログラム名、チャネル情報などの情報が読み取れない。したがって、特定コンテンツソースを区別するためのユニークＩＤを用いてもよい。本発明では、コンテンツソースのＩＤ種類が限定されない。コンテンツソースのＩＤとして次のような実施例を挙げることができる。
まず、グローバルプログラムＩＤ（Ｇｌｏｂａｌ Ｐｒｏｇｒａｍ ＩＤ）は、各放送プログラムを区別できるグローバルな識別子であってもよい。当該ＩＤは、コンテンツプロバイダが直接生成してもよく、権威のある団体で指定した形式に従ってもよい。例えば、北−米“ＴＭＳ ｍｅｔａｄａｔａ”のＴＭＳＩｄ、又は映画／放送プログラム区別子のＥＩＤＲ ＩＤなどがある。
グローバルチャネルＩＤ（Ｇｌｏｂａｌ Ｃｈａｎｎｅｌ ＩＤ）は、ＭＶＰＤと関係ない、全てのチャネルを区別できるチャネル識別子であってもよい。セットトップボックススで提供するＭＶＰＤごとにチャネル番号が異なってもよい。また、同じＭＶＰＤであっても、ユーザの指定するサービスによってチャネル番号が異なってもよい。グローバルチャネルＩＤは、ＭＶＰＤなどに影響を受けないグローバルな識別子として用いられてもよい。実施例によって、地上波で伝送されるチャネルは、メジャーチャネルナンバー＆マイナーチャネルナンバーで識別することができる。プログラムＩＤだけを使用する場合、複数の放送局で同一プログラムを放映する場合に問題が発生しうるので、特定の放送局を指定するためにグローバルチャネルＩＤを用いることができる。
ＷＭに挿入するコンテンツソースのＩＤは、プログラムＩＤとチャネルＩＤを含むことができる。ＷＭには、プログラムＩＤとチャネルＩＤが両方とも挿入されてもよく、両ＩＤを組み合わせた新しい形態のＩＤが挿入されてもよく、又はそれぞれのＩＤが挿入されてもよい。実施例によって、各ＩＤ又は統合されたＩＤをハッシュ（ｈａｓｈ）化してデータの量を減してもよい。
また、本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータとしては、タイムスタンプを挙げることができる。受信機は、現在視聴中の内容がコンテンツのどの時点であるかを知る必要がある。この時間関連情報は、タイムスタンプと呼ぶことができ、ＷＭに挿入することができる。時間関連情報は、絶対時間（ＵＴＣ、ＧＰＳなど）又はメディアタイムの形態を有することができる。時間関連情報は、正確度のためにミリセカンド単位まで伝達してもよく、実施例によって、より細かい単位まで伝達されてもよい。タイムスタンプは、後述するタイムスタンプの種類情報によって可変の長さを有してもよい。
また、本発明の一実施例に係るウォーターマーキング技法によって伝達可能なデータとしては、インタラクティブアプリケーションのＵＲＬを挙げることもできる。現在視聴中の放送プログラムに関連したインターアクティブアプリケーションがある場合、当該アプリケーションに対するＵＲＬがＷＭに挿入されてもよい。受信機は、ＷＭを検出して該当のＵＲＬを得、ブラウザを用いてアプリケーションを実行することができる。
図２３は、本発明の一実施例に係るタイムスタンプタイプフィールドの各値の意味を示す図である。
本発明は、ウォーターマーキング技法によって伝達可能なデータの一つとして、タイムスタンプタイプフィールドを提案する。また、本発明は、タイムスタンプタイプフィールドの効果的なデータ構造を提案する。
タイムスタンプタイプフィールドには５ビットを割り当てることができる。タイムスタンプの先頭の２ビットはタイムスタンプのサイズを意味でき、残りの続く３ビットは、タイムスタンプが示す時間情報の単位を意味することができる。ここで、先頭の２ビットは、タイムスタンプサイズフィールドと、残りの３ビットは、タイムスタンプユニットフィールドと呼ぶことができる。
同図に示すように、タイムスタンプのサイズ（ｓｉｚｅ）とタイムスタンプの単位値によって、実際タイムスタンプ情報を可変的な量でＷＭに挿入することができる。この可変性を用いて、設計者は、タイムスタンプの正確度のレベルによってタイムスタンプに割り当てられるサイズ及びその単位を選択することができる。タイムスタンプの正確度が高くなると、正確な時刻にインタラクティブサービスを提供することが可能になるが、その分システムの複雑度が増加する。このトレードオフを考慮して、タイムスタンプに割り当てられるサイズ及びその単位を選択すればよい。
タイムスタンプタイプフィールドの先頭の２ビットが００である場合、タイムスタンプは１バイトのサイズを有することができる。タイムスタンプタイプフィールドの先頭の２ビットが０１、１０、１１である場合、タイムスタンプのサイズはそれぞれ２、４、８バイトのサイズを有することができる。
タイムスタンプタイプフィールドの最後の３ビットが０００である場合、タイムスタンプはミリセカンドの単位を有することができる。タイムスタンプタイプフィールドの最後の３ビットが００１、０１０、０１１である場合、タイムスタンプはそれぞれ、秒、分、時間の単位を有することができる。タイムスタンプタイプフィールドの最後の３ビットが１０１〜１１１の値である場合は、将来の使用のために残すことができる。
ここで、タイムスタンプタイプフィールドの最後の３ビットが１００である場合には、ミリセカンド、セカンドなどの特定時間単位ではなく別のタイムコードを単位として用いてもよい。例えば、ＳＭＰＴＥのタイムコード形態であるＨＨ：ＭＭ：ＳＳ：ＦＦ形態のタイムコードをＷＭに挿入することもできる。ここで、ＨＨは時間単位、ＭＭは分単位、ＳＳは秒単位であってもよい。そして、ＦＦはフレーム情報であり、時間単位ではなくフレーム情報まで同時に伝達し、より正確な（Ｆｒａｍｅ−ａｃｃｕｒａｔｅ）サービスを提供することができる。ＷＭに挿入されるように、実際タイムスタンプはコロンを除外したＨＨＭＭＳＳＦＦの形態を有してもよい。この場合、タイムスタンプサイズ値は１１（８バイト）を有し、タイムスタンプユニット値は１００を有することができる。可変ユニットの場合に、いかなる方式でタイムスタンプが挿入されるかは、本発明によって限定されない。
例えば、タイムスタンプ種類情報が１０の値を有し、タイムスタンプの単位情報が０００の値を有する場合、タイムスタンプのサイズは４バイトであり、タイムスタンプの単位がミリセカンドであってもよい。このとき、タイムスタンプがＴｓ＝３２６５０８７である場合、最後の３桁の０８７は、ミリセカンドを意味でき、残り３２６５は秒単位であってもよい。したがって、このタイムスタンプを解釈すれば、現在時間は、ＷＭが挿入された該当のプログラムの開始から５４分２５．０８７秒が経過した時点であってもよい。これは一実施例に過ぎず、タイムスタンプはウォ−ルタイム（Ｗａｌｌ ｔｉｍｅ）の役割として、コンテンツにかかわらず、セグメント或いは受信機自体の時間を示すこともできる。
図２４は、本発明の一実施例に係るＵＲＬプロトコルタイプフィールドの各値の意味を示す図である。
本発明は、ウォーターマーキング技法によって伝達可能なデータの一つとして、ＵＲＬプロトコルタイプフィールドを提案する。また、本発明は、ＵＲＬプロトコルタイプフィールドの効果的なデータ構造を提案する。
前述した情報のうち、ＵＲＬは、その長さが長いため、挿入されるデータ量が相対的に多いのが一般的である。前述したように、ＷＭに挿入されるデータは少ないほど効率的であるので、ＵＲＬにおいて固定的な部分は受信機で処理することができる。そのために、本発明は、ＵＲＬプロトコルタイプのためのフィールドを提案することができる。
ＵＲＬプロトコルタイプフィールドは、３ビットのサイズを有することができる。サービスプロバイダは、ＵＲＬプロトコルタイプフィールドを用いてＷＭにＵＲＬプロトコルを設定することができる。この場合、インタラクティブアプリケーションのＵＲＬは、ドメインから挿入されてＷＭで伝送されてもよい。
受信機のＷＭ検出器は、まず、ＵＲＬプロトコルタイプフィールドをパースしてＵＲＬプロトコル情報を得、その後、伝送されたＵＲＬ値の前に該当のプロトコルを付けて全体ＵＲＬを作ることができる。受信機は、ブラウザを用いて完成されたＵＲＬに接近し、該当のインタラクティブアプリケーションを実行することができる。
ここで、ＵＲＬプロトコルタイプフィールドの値が０００である場合には、ＵＲＬプロトコルがＷＭのＵＲＬフィールドに直接明示されて挿入されてもよい。ＵＲＬプロトコルタイプフィールドの値が００１、０１０、０１１である場合、ＵＲＬプロトコルはそれぞれｈｔｔｐ：／／、ｈｔｔｐｓ：／／、ｗｓ：／／であってもよい。ＵＲＬプロトコルタイプフィールドの値が１００〜１１１の値を有する場合は、将来の使用のために残すことができる。
アプリケーションＵＲＬは、その自体でブラウザを用いてアプリケーションの実行が可能であってもよい（Ｗｅｂ Ａｐｐ．の形態）。また、実施例によって、コンテンツソースＩＤとタイムスタンプ情報を参照してもよい。後者の場合、コンテンツソースＩＤ情報とタイムスタンプ情報をアプリケーションサーバーに伝達するために最終的なＵＲＬが次のような形態を有してもよい。ここで、アプリケーションサーバーは、実施例によって、後述するリモートサーバーに該当してもよい。
要求（Ｒｅｑｕｅｓｔ）ＵＲＬ：
この実施例は、コンテンツソースＩＤは１２３４５６であり、タイムスタンプは５００５である場合であってもよい。ｃｉｄは、アプリケーションサーバーに知らせるコンテンツソースＩＤの要求（ｑｕｅｒｙ）識別子を意味することができる。ｔは、アプリケーションサーバーに知らせる現在時点の要求識別子を意味することができる。
図２５は、本発明の一実施例に係るＵＲＬプロトコルタイプフィールドの処理手続を示すフロ−チャ−トである。
まず、サービスプロバイダ４７０１０はＷＭ挿入器４７０２０にコンテンツを伝達することができる（ｓ４７０１０）。ここで、サービスプロバイダ４７０１０は、前述したコンテンツ提供サーバーと類似の機能を有することができる。
ＷＭ挿入器４７０２０は、受信したコンテンツにＷＭを挿入することができる（ｓ４７０２０）。ここで、ＷＭ挿入器４７０２０は、前述したウォーターマークサーバーと類似の機能を有することができる。ＷＭ挿入器４７０２０は、前述したようなＷＭをＷＭアルゴリズムによってオーディオ又はビデオに挿入することができる。ここで、挿入されるＷＭには、前述したアプリケーションＵＲＬ情報、コンテンツソースＩＤ情報などが含まれてもよい。例えば、挿入されるＷＭには、前述したタイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤなどの情報が含まれてもよい。前述したＵＲＬプロトコルタイプフィールドは００１の値を有することができ、ＵＲＬ情報はａｔｓｃ．ｏｒｇの値を有することができる。ＷＭに挿入されるフィールドの値は一実施例に過ぎず、本発明はこの実施例に限定されない。
ＷＭ挿入器４７０２０は、ＷＭの挿入されたコンテンツを送出することができる（ｓ４７０３０）。ＷＭの挿入されたコンテンツの送出は、サービスプロバイダ４７０１０によって行われてもよい。
ＳＴＢ４７０３０は、ＷＭの挿入されたコンテンツを受け取り、非圧縮的Ａ／Ｖデータ（又は、ロー（ｒａｗ）Ａ／Ｖデータ）を出力することができる（ｓ４７０４０）。ここで、ＳＴＢ４７０３０は、前述した放送受信装置、又はセットトップボックスを意味することができる。ＳＴＢ４７０３０は、受信機の外部又は内部に設置することができる。
ＷＭディテクタ４７０４０は、受信した非圧縮的Ａ／Ｖデータから、挿入されているＷＭを検出することができる（ｓ４７０５０）。ＷＭディテクタ４７０４０は、ＷＭ挿入器４７０２０の挿入したＷＭを検出した後、この検出されたＷＭをＷＭマネジャーに伝達することができる。
ＷＭマネジャー４７０５０は、検出されたＷＭをパースすることができる（ｓ４７０６０）。前述した実施例で、ＷＭは、ＵＲＬプロトコルタイプフィールド値が００１であり、ＵＲＬ値がａｔｓｃ．ｏｒｇである情報を有することができる。ＵＲＬプロトコルタイプフィールド値が００１であるので、ｈｔｔｐ：／／プロトコルが用いられることを意味することができる。ＷＭマネジャー４７０５０はこの情報を用いて、ｈｔｔｐ：／／とａｔｓｃ．ｏｒｇを結合して全体ＵＲＬを生成することができる（ｓ４７０７０）。
ＷＭマネジャー４７０５０は、この完成されたＵＲＬをブラウザ４７０６０に送り、アプリケーションをローンチすることができる（ｓ４７０８０）。場合によって、コンテンツソースＩＤ情報及びタイムスタンプ情報まで伝達する必要がある場合、http://atsc.org?cid=xxx&t=YYYの形態でアプリケーションをローンチすることもできる。
端末内のＷＭ検出器４７０４０とＷＭマネジャー４７０５０は統合されて、単一のモジュールでその機能が行われてもよい。この場合、前述したｓ４７０５０、ｓ４７０６０、ｓ４７０７０の過程が単一のモジュールで処理されてもよい。
図２６は、本発明の一実施例に係るイベントフィールドの各値の意味を示す図である。
本発明は、ウォーターマーキング技法によって伝達可能なデータの一つとしてイベントフィールドを提案する。また、本発明は、イベントフィールドの効果的なデータ構造を提案する。
ＷＭから抽出したＵＲＬを介してアプリケーションをローンチすることができる。より細部的なイベントを用いてアプリケーションを制御してもよい。アプリケーションを制御できるイベントをイベントフィールドで表示して伝達することができる。すなわち、現在視聴中の放送プログラムに関連したインタラクティブアプリケーションがある場合、当該アプリケーションに対するＵＲＬが伝送されてもよく、イベントを用いてそのアプリケーションを制御することができる。
イベントフィールドは、３ビットのサイズを有することができる。イベントフィールドの値が０００である場合、‘Ｐｒｅｐａｒｅ’命令を意味することができる。Ｐｒｅｐａｒｅとは、アプリケーションを実行する前の準備段階であり、この命令を受けた受信機は、あらかじめアプリケーションに関連したコンテンツアイテムをダウンロードしておくことができる。また、受信機は、当該アプリケーションを実行するために必要なリソースを解除しておくこともできる。ここで、必要なリソースを解除するということは、メモリを整理するか、又はまだ終了していない他のアプリケーションを終了させておくことを意味することができる。
イベントフィールド値が００１である場合、‘Ｅｘｅｃｕｔｅ’命令を意味することができる。Ｅｘｅｃｕｔｅとは、当該アプリケーションを実行するようとの命令であってもよい。イベントフィールド値が０１０である場合、‘Ｓｕｓｐｅｎｄ’命令を意味することができる。Ｓｕｓｐｅｎｄとは、既に実行されている当該アプリケーションをしばらくの間動作しないようにすることを意味することができる。イベントフィールド値が０１１である場合、‘Ｋｉｌｌ’命令を意味することができる。Ｋｉｌｌとは、既に実行されている当該アプリケーションを終了させる命令であってもよい。イベントフィールド値が１００〜１１１の値である場合、将来の使用のために残すことができる。
図２７は、本発明の一実施例に係るデスティネーションタイプフィールドの各値の意味を示す図である。
本発明は、ウォーターマーキング技法によって伝達可能なデータの一つとしてデスティネーションタイプフィールドを提案する。また、本発明は、デスティネーションタイプフィールドの効果的なデータ構造を提案する。
ＤＴＶ関連技術の発展により、放送コンテンツに関連した付加サービスは、ＴＶ受信機のスクリーンの他、コンパニオン（ｃｏｍｐａｎｉｏｎ）デバイスでも提供されてもよい。しかし、コンパニオンデバイスは、放送受信が不可能であるか、可能であるとしてＷＭ検出は不可能である。このため、現在放映中の放送コンテンツに関連した付加サービスを提供するアプリケーションのうち、コンパニオンデバイスで実行されるべきアプリケーションがあると、その関連情報はコンパニオンデバイスに伝達されなければならない。
このとき、受信機とコンパニオンデバイスとが連動して動作できる環境であっても、ＷＭから検出されたアプリケーション又はデータがどの機器で消費されるべきかを知る必要がある。すなわち、各データ又はアプリケーションが受信機で消費されるべきか、それともコンパニオンデバイスで消費されるべきかに関する情報が必要であってもよい。このような情報をＷＭとして伝達するために、本発明はデスティネーションタイプフィールドを提案する。
デスティネーションタイプフィールドは、３ビットのサイズを有することができる。デスティネーションタイプフィールドの値が０ｘ００である場合、ＷＭによって検出されたアプリケーション又はデータが全ての機器をターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０１である場合、ＷＭによって検出されたアプリケーション又はデータがＴＶ受信機をターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０２である場合、ＷＭによって検出されたアプリケーション又はデータがスマートフォンをターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０３である場合、ＷＭによって検出されたアプリケーション又はデータがタブレット機器をターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０４である場合、ＷＭによって検出されたアプリケーション又はデータがパーソナルコンピュータをターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０５である場合、ＷＭによって検出されたアプリケーション又はデータがリモートサーバーをターゲッティングすることを意味することができる。デスティネーションタイプフィールドの値が０ｘ０６〜０ｘＦＦの値を有する場合は、将来の使用のために残すことができる。
ここで、リモートサーバーとは、放送に関連した全ての付加情報を持っているサーバーを意味することができる。このリモートサーバーは端末の外部に設けられてもよい。リモートサーバーが用いられる場合、ＷＭに挿入されるＵＲＬは、特定アプリケーションのＵＲＬではなく、リモートサーバーのＵＲＬを示すことができる。受信機は、リモートサーバーのＵＲＬを通じてリモートサーバーと疎通して、放送プログラムに関連した付加情報を受け取ることができる。このとき、受け取った付加情報は、関連したアプリケーションのＵＲＬだけでなく、現在放送プログラムのジャンル、俳優情報、あらすじなどの様々な情報であってもよい。受け取り可能な情報はシステムによって異なってもよい。ここで、リモートサーバーは、前述したアプリケーションサーバーの一実施例であってもよい。
他の実施例によれば、デスティネーションタイプフィールドの各ビットを各デバイス別に割り当て、アプリケーションの宛先（ｄｅｓｔｉｎａｔｉｏｎ）を示すこともできる。この場合、ビットワイズＯＲを用いて複数のデスティネーションを同時に指定してもよい。
例えば、０ｘ０１をＴＶ受信機、０ｘ０２をスマートフォン、０ｘ０４をタブレット、０ｘ０８をＰＣ、０ｘ１０をリモートサーバーとしたとき、デスティネーションタイプフィールドが０ｘ６の値を有すると、当該アプリケーション又はデータはスマートフォン及びタブレットをターゲットとすることができる。
前述したＷＭマネジャーによってパースされたＷＭのデスティネーションタイプフィールドの値によって、ＷＭマネジャーは各アプリケーション又はデータをコンパニオンデバイスに伝達することができる。この場合、ＷＭマネジャーは、受信機内のコンパニオンデバイスとの連動を処理するモジュールに、各アプリケーション又はデータに関連した情報を伝達することができる。
図２８は、本発明の実施例＃１によるＷＭに挿入されるデータ構造を示す図である。
本実施例で、ＷＭに挿入されるデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、デスティネーションタイプフィールド、ＵＲＬプロトコルタイプフィールド、ＵＲＬなどの情報を有することができる。ここで、各データの順序を変更してもよく、それぞれのデータは実施例によって省略されてもよい。
本実施例で、タイムスタンプタイプフィールドにおけるタイムスタンプサイズフィールドは０１、タイムスタンプユニットフィールドは０００の値を有することができる。これはそれぞれ、タイムスタンプに２ビットが割り当てられ、タイムスタンプはミリセカンドの単位を有することを意味することができる。
また、イベントフィールドは００１の値を有するが、これは、該当するアプリケーションが直ちに実行されなければならないことを意味することができる。デスティネーションタイプフィールドは０ｘ０２の値を有するが、これは、ＷＭによって伝達されたデータがスマートフォンに伝達されなければならないことを意味することができる。ＵＲＬプロトコルタイプフィールドは００１、ＵＲＬはａｔｓｃ．ｏｒｇの値を有するので、付加情報又はアプリケーションのＵＲＬはhttp://atsc.org.であることを意味することができる。
図２９は、本発明の実施例＃１によるＷＭに挿入されるデータ構造を処理する順序図である。
ここで、サービスプロバイダがＷＭ挿入器にコンテンツを伝達する段階（ｓ５１０１０）、ＷＭ挿入器が受信したコンテンツにＷＭを挿入する段階（ｓ５１０２０）、ＷＭ挿入器がＷＭの挿入されたコンテンツを送出する段階（ｓ５１０３０）、ＳＴＢがＷＭの挿入されたコンテンツを受け取り、非圧縮的Ａ／Ｖデータを出力する段階（ｓ５１０４０）、ＷＭディテクタがＷＭを検出する段階（ｓ５１０５０）、ＷＭマネジャーが検出されたＷＭをパースする段階（ｓ５１０６０）、及び／又はＷＭマネジャーが全体ＵＲＬを生成する段階（ｓ５１０７０）は、前述した各段階と同一であってもよい。
ＷＭマネジャーは、パースされたＷＭのデスティネーションタイプフィールドによって、受信機内のコンパニオンデバイスプロトコルモジュールに、関連データを伝達することができる（ｓ５１０８０）。ここで、コンパニオンデバイスプロトコルモジュールは、受信機内でコンパニオンデバイスとの連動及び通信などを管掌するモジュールであってもよい。コンパニオンデバイスプロトコルモジュールは、コンパニオンデバイスとペアリング（ｐａｉｒｉｎｇ）されていてもよい。実施例によって、コンパニオンデバイスプロトコルモジュールは、ＵＰｎＰデバイスであってもよい。実施例によって、コンパニオンデバイスプロトコルモジュールは端末の外部に位置してもよい。
コンパニオンデバイスプロトコルモジュールは、デスティネーションタイプフィールドによるコンパニオンデバイスに関連データを伝達することができる（ｓ５１０９０）。本実施例＃１で、デスティネーションタイプフィールドの値は０ｘ０２であり、ＷＭに挿入されたデータなどはスマートフォンのためのデータであってもよい。したがって、コンパニオンデバイスプロトコルモジュールは、パースされたデータをスマートフォン機器に送ることができる。すなわち、この実施例でコンパニオンデバイスはスマートフォンであってもよい。
実施例によって、ＷＭマネジャー又はコンパニオンデバイスプロトコルモジュールは、コンパニオンデバイスにデータを伝達する前にデータ処理手続を行うことができる。コンパニオンデバイスの場合、一般に、携帯性が強調されるため、プロセシング／コンピューティング能力が相対的に劣ったり、メモリ量が少ないことがある。したがって、受信機は、コンパニオンデバイスが行うデータプロセシングを代行した後、プロセシングされたデータをコンパニオンデバイスに伝達することができる。
このようなプロセシングには様々な実施例があり得る。まず、ＷＭマネジャー又はコンパニオンデバイスプロトコルモジュールは、コンパニオンデバイスが必要とするデータだけを選別する作業を行うことができる。また、実施例によって、イベントフィールドがアプリケーションを終了する旨の内容を含んでいる場合、アプリケーション関連情報を伝達しなくてもよい。また、データが複数のＷＭに分けて伝送された場合、それらのデータを保存し、これらを合わせた最終情報をコンパニオンデバイスに伝達することもできる。タイムスタンプを用いた同期化を代わりに行って、既に同期化されたアプリケーション関連命令を伝達するか、既に同期化されたインタラクティブサービスを伝達して、コンパニオンデバイスは単にディスプレイだけを行うようにしてもよい。また、タイムスタンプ関連情報を伝達せず、タイムベースを受信機内でのみ維持し、あるイベントが活性化されるべき時間に合わせて関連情報をコンパニオンデバイスに伝達することもできる。この場合、コンパニオンデバイスはタイムベースを維持する必要がなく、関連情報を受信した瞬間に合わせて該当のイベントを活性化するなどの動作を行うことができる。
前述と同様に、端末内のＷＭ検出器とＷＭマネジャーとが統合されて、単一のモジュールでそれらの機能が行われてもよい。この場合、前述したｓ５１０５０、ｓ５１０６０、ｓ５１０７０、ｓ５１０８０の過程が単一のモジュールで処理されてもよい。
また、実施例によって、コンパニオンデバイスもＷＭ検出器を有することができる。各コンパニオンデバイスがＷＭの挿入された放送を受信可能な場合、各コンパニオンデバイスは、ＷＭを直接検出した後に、他のコンパニオンデバイスに伝達することができる。例えば、スマートフォンがＷＭを検出及びパースして、関連情報をＴＶに伝達することもできる。この場合、デスティネーションタイプフィールドは０ｘ０１の値を有することができる。
図３０は、本発明の実施例＃２によるＷＭに挿入されるデータ構造を示す図である。
本実施例で、ＷＭに挿入されるデータは、タイムスタンプタイプフィールド、タイムスタンプ、コンテンツＩＤ、イベントフィールド、デスティネーションタイプフィールド、ＵＲＬプロトコルタイプフィールド、ＵＲＬなどの情報を有することができる。ここで、各データの順序を変更してもよく、それぞれのデータは実施例によって省略されてもよい。
本実施例で、タイムスタンプタイプフィールドのタイムスタンプサイズフィールドは０１、タイムスタンプユニットフィールドは０００の値を有することができる。これはそれぞれ、タイムスタンプに２ビットが割り当てられ、タイムスタンプはミリセカンドの単位を有することを意味することができる。コンテンツＩＤは、１２３４５６の値を有することができる。
また、イベントフィールドは００１の値を有するが、これは、該当するアプリケーションが直ちに実行されなければならないことを意味することができる。デスティネーションタイプフィールドは０ｘ０５の値を有するが、これは、ＷＭによって伝達されたデータがリモートサーバーに伝達されなければならないことを意味することができる。ＵＲＬプロトコルタイプフィールドは００１、ＵＲＬはｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍの値を有するので、付加情報又はアプリケーションのＵＲＬは、http://remoteserver.com.であることを意味することができる。
前述したように、リモートサーバーが用いられる場合、リモートサーバーから放送プログラムに対する付加情報を取り込むことができる。このとき、リモートサーバーのＵＲＬにコンテンツＩＤ及びタイムスタンプをパラメータとして挿入してリモートサーバーに要求することができる。また、実施例によって、リモートサーバーがＡＰＩの支援によって現在放送プログラムに関する情報を得ることもできる。このとき、ＡＰＩは、受信機内に保存されたコンテンツＩＤ、タイムスタンプをリモートサーバーが取得できるようにするするか、又は関連した付加情報を伝達できるようにする。
本実施例で、リモートサーバーのＵＲＬにコンテンツＩＤ及びタイムスタンプをパラメータとして挿入する場合、全体ＵＲＬはhttp://remoteserver.com?cid=1233456&t=5005のようになり得る。ここで、ｃｉｄは、リモートサーバーに知らせるコンテンツＩＤの要求識別子であってもよい。ここで、ｔは、リモートサーバーに知らせる現在時点の要求識別子であってもよい。
図３１は、本発明の実施例＃２によるＷＭに挿入されるデータ構造を処理する順序図である。
ここで、サービスプロバイダがＷＭ挿入器にコンテンツを伝達する段階（ｓ５３０１０）、ＷＭ挿入器が、受信したコンテンツにＷＭを挿入する段階（ｓ５３０２０）、ＷＭ挿入器がＷＭの挿入されたコンテンツを送出する段階（ｓ５３０３０）、ＳＴＢがＷＭの挿入されたコンテンツを受け取り、非圧縮的Ａ／Ｖデータを出力する段階（ｓ５３０４０）、ＷＭディテクタがＷＭを検出する段階（ｓ５３０５０）、及び／又はＷＭマネジャーが検出されたＷＭをパースする段階（ｓ５３０６０）は、前述した各段階と同一であってもよい。
ＷＭマネジャーは、パースしたデスティネーションタイプフィールド（０ｘ０５）から、リモートサーバーと疎通しなければならない場合であることが分かる。ＷＭマネジャーは、ＵＲＬプロトコルタイプフィールドの値及びＵＲＬ値を用いて、http://remoteserver.comというＵＲＬを生成することができる。また、コンテンツＩＤ及びタイムスタンプの値を用いて、最終的にhttp://remoteserver.com?cid=123456&t=5005のＵＲＬを生成することができる。ＷＭマネジャーは、この最終ＵＲＬで要求を行うことができる（ｓ５３０７０）。
リモートサーバーは要求を受けて、放送プログラムに合う関連アプリケーションのＵＲＬをＷＭマネジャーに伝送することができる（ｓ５３０８０）。ＷＭマネジャーは、受信したアプリケーションのＵＲＬをブラウザに送り、当該アプリケーションをローンチすることができる（ｓ５３０９０）。
前述と同様に、端末内のＷＭ検出器とＷＭマネジャーは統合されて、単一のモジュールでその機能が行われてもよい。この場合、前述したｓ５３０５０、ｓ５３０６０、ｓ５３０７０、ｓ５３０９０の過程が単一のモジュールで処理されてもよい。
図３２は、本発明の実施例＃３によるＷＭに挿入されるデータ構造を示す図である。
本発明は、ウォーターマーキング技法によって伝達可能なデータの一つとして伝達タイプ（ｄｅｌｉｖｅｒｙ ｔｙｐｅ）フィールドを提案する。また、本発明は、伝達タイプフィールドの効果的なデータ構造を提案する。
ＷＭに挿入されるデータ量の増加によるオーディオ／ビデオコンテンツのクォリティー低下を減らすために、ＷＭが分けて挿入されてもよい。ＷＭが分けて挿入されるか否かを示すために、伝達タイプフィールドを用いることができる。伝達タイプフィールドから、一度のＷＭ検出によって放送関連情報習得が可能か、或いは複数のＷＭが検出されなければならないかを区別することができる。
伝達タイプフィールドが０の値を有する場合、１つのＷＭに全てのデータが挿入されて伝送されることを意味することができる。伝達タイプフィールドが１の値を有する場合、複数のＷＭにデータが分けて挿入されて伝送されることを意味することができる。
本実施例は、伝達タイプフィールドの値が０である場合であってもよい。この場合のＷＭのデータ構造は、前述したデータ構造に伝達タイプフィールドが付加された形態であってもよい。本実施例は、伝達タイプフィールドが先頭に位置するが、実施例によって他の箇所に位置してもよい。
ＷＭマネジャー又はＷＭ検出器は、伝達タイプフィールドが０の値を有する場合、ＷＭの長さを参照してＷＭをパースすることができる。このとき、ＷＭの長さは、既に定められたフィールドのビット数を考慮して計算することができる。例えば、前述したように、イベントフィールドの長さは３ビットであってもよい。コンテンツＩＤ、ＵＲＬのサイズは可変であるが、実施例によってそのビット数が制限されてもよい。
図３３は、本発明の実施例＃４によるＷＭに挿入されるデータ構造を示す図である。
本実施例は、伝達タイプフィールドの値が１である場合であってもよい。この場合、ＷＭのデータ構造にいくつかのフィールドが追加されてもよい。
ＷＭＩｄフィールドは、ＷＭを区別する識別子の役割を担うことができる。データが複数のＭに分けて伝送される場合、ＷＭ検出器は、分けられたデータを有する各ＷＭを識別する必要がある。このとき、分けられたデータを持つ各ＷＭは、同じＷＭＩｄフィールド値を有することができる。ＷＭＩｄフィールドは８ビットのサイズを有することができる。
ブロックナンバー（Ｂｌｏｃｋ ｎｕｍｂｅｒ）フィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭの識別番号を示すフィールドであってもよい。分けられたデータを持つＷＭが伝送される順序によって１ずつ値が増加してもよい。例えば、分けられたデータを持つ各ＷＭのうち、１番目のＷＭの場合、ブロックナンバーフィールドの値が０ｘ００であってもよい。その後、伝送される２番目、３番目のＷＭはそれぞれ、０ｘ０１、０ｘ０２、．．．の値を有することができる。ブロックナンバーフィールドは、８ビットのサイズを有することができる。
最後のブロックナンバー（Ｌａｓｔ ｂｌｏｃｋ ｎｕｍｂｅｒ）フィールドは、分けられたデータを持つ各ＷＭのうち、最後のＷＭの識別番号を示すフィールドであってもよい。前述したブロックナンバーフィールドと最後のブロックナンバーフィールドの値が同一になるまで、ＷＭ検出器又はＷＭマネジャーは検出したＷＭを集め、パースすることができる。最後のブロックナンバーフィールドは８ビットのサイズを有することができる。
ブロック長（Ｂｌｏｃｋ ｌｅｎｇｔｈ）フィールドは、該当のＷＭの全長を示すことができる。ここで、該当のＷＭとは、分けられたデータを持つ各ＷＭのうちの１つを意味することができる。ブロック長フィールドは７ビットのサイズを有することができる。
コンテンツＩＤフラグ（Ｃｏｎｔｅｎｔ Ｉｄｅｎｔｉｆｉｅｒ Ｆｌａｇ）フィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭのペイロードにコンテンツＩＤが含まれているかを示すことができる。コンテンツＩＤが含まれている場合、コンテンツＩＤフラグフィールドは１に設定され、逆の場合、０に設定されてもよい。コンテンツＩＤフラグフィールドは１ビットのサイズを有することができる。
イベントフラグフィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭのペイロードにイベントフィールドが含まれているかを示すことができる。イベントフィールドが含まれている場合、イベントフラグフィールドは１に設定され、逆の場合、０に設定されてもよい。イベントフラグフィールドは１ビットのサイズを有することができる。
デスティネーションフラグフィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭのペイロードにデスティネーションタイプフィールドが含まれているかを示すことができる。デスティネーションタイプフィールドが含まれている場合、デスティネーションフラグフィールドは１に設定され、逆の場合、０に設定されてもよい。デスティネーションフラグフィールドは１ビットのサイズを有することができる。
ＵＲＬプロトコルフラグフィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭのペイロードにＵＲＬプロトコルタイプフィールドが含まれているかを示すことができる。ＵＲＬプロトコルタイプフィールドが含まれている場合、ＵＲＬプロトコルフラグフィールドは１に設定され、逆の場合、０に設定されてもよい。ＵＲＬプロトコルフラグフィールドは１ビットのサイズを有することができる。
ＵＲＬフラグフィールドは、分けられたデータを持つ各ＷＭのうち、現在ＷＭのペイロードにＵＲＬ情報が含まれているかを示すことができる。ＵＲＬ情報が含まれている場合、ＵＲＬフラグフィールドは１に設定され、逆の場合、０に設定されてもよい。ＵＲＬフラグフィールドは１ビットのサイズを有することができる。
ペイロードには、前述したフィールド以外の実際データを含めることができる。
複数のＷＭに分けて伝送する場合、それぞれのＷＭが挿入された時点の時点情報を知る必要がある。この場合、実施例によって、それぞれのＷＭにタイムスタンプが挿入されてもよい。このとき、タイムスタンプタイプフィールドも、タイムスタンプの挿入されたＷＭに共に挿入されてもよい。ＷＭが挿入された時点を知るうえで必要なためである。又は、実施例によって、受信機がＷＭタイムスタンプタイプ情報を保存して活用することができる。受信機は、最初のタイムスタンプ、最後のタイムスタンプ、又はそれぞれのタイムスタンプを基準にしてタイムシンクを取ることができる。
データを複数のＷＭに分けて伝送する場合、それぞれのＷＭのサイズは、上記フラグフィールドを用いて調節することができる。前述したように、ＷＭによって伝送されるデータ量が大きくなる場合、オーディオ／ビデオコンテンツの質に影響を及ぼしうる。このため、伝送される各オーディオ／ビデオフレーム別の状況によって、該当のフレームに挿入されるＷＭのサイズを調節すればよい。このとき、ＷＭのサイズは、前述したフラグフィールドによって調節することができる。
例えば、コンテンツのビデオフレームのいずれか一ビデオフレームが黒い画面のみからなっているとしよう。コンテンツの内容上、場面が切り換わったりする場合に、黒い画面のみからなるビデオフレームが１つ挿入されてもよい。このようなビデオフレームの場合、多量のＷＭが挿入されても、コンテンツの質が低下したりすることがない。すなわち、ユーザーがコンテンツの質の低下を感じなくてすむ。この場合、当該ビデオフレームには、多量のデータを有するＷＭを挿入することができる。このとき、当該ビデオフレームに挿入されるＷＭのフラグフィールドは殆ど１の値を有することができる。このＷＭは大部分のフィールドを実際に有するためである。特に、多いデータ量を占めるＵＲＬフィールドが、そのＷＭに含まれてもよい。これによって、他のビデオフレームに挿入されるＷＭには、相対的に少ない量のデータが挿入されてもよい。ＷＭに挿入されるデータ量は設計者の意図によって変更されてもよい。
図３４は、本発明の実施例＃４において、１番目のＷＭに挿入されるデータ構造を示す図である。
本実施例は、伝達タイプフィールドの値が１である場合、すなわち、データがいくつかのＷＭに分けて伝送される場合において、１番目のＷＭの構造を図示のようにすることができる。
分けられたデータを持つ各ＷＭのうち、１番目のＷＭであるため、ブロックナンバーフィールドの値が０ｘ００であってもよい。もちろん、実施例によって、別のブロックナンバーフィールドの値が使用されると、図示のＷＭは１番目のＷＭでなくてもよい。
受信機は、１番目のＷＭを検出することができる。検出されたＷＭは、ＷＭマネジャーによってパースすることができる。このとき、ＷＭの伝達タイプフィールド値が１であり、ブロックナンバーフィールドの値と最後のブロックナンバーフィールドの値とが異なることが分かる。したがって、ＷＭマネジャーは、ＷＭＩｄが０ｘ００である、残りのＷＭが来るまで、パースした情報を保存しておくことができる。特に、ＵＲＬ情報であるａｔｓｃ．ｏｒｇも保存してもよい。ここで、最後のブロックナンバーフィールドの値が０ｘ０１であるため、残り１つのＷＭだけを受信すると、ＷＭＩｄが０ｘ００であるＷＭに対しては全て受信するようになることが分かる。
本実施例で、各フラグフィールドの値がいすれも１である。したがって、このＷＭのペイロードにはイベントフィールドなどの各情報が含まれていることが分かる。また、タイムスタンプ値が５００５であるため、このＷＭが挿入された部分の時点は５．００５秒であることが分かる。
図３５は、本発明の実施例＃４において、２番目のＷＭに挿入されるデータ構造を示す図である。
本実施例は、伝達タイプフィールドの値が１である場合、すなわち、データが複数のＷＭに分けて伝送される場合において、２番目のＷＭの構造を図示のようにすることができる。
分けられたデータを持つ各ＷＭのうち、２番目のＷＭであるため、ブロックナンバーフィールドの値が０ｘ０１であってもよい。実施例によって、別のブロックナンバーフィールドの値を使用する場合、図示のＷＭは２番目のＷＭでなくてもよい。
受信機は、２番目のＷＭを検出することができる。ＷＭマネジャーは、検出された２番目のＷＭをパースすることができる。ブロックナンバーフィールドと最後のブロックナンバーフィールドの値が同一であるため、このＷＭが、ＷＭＩｄ値が０ｘ００である、ＷＭのうちの最後のＷＭであることが分かる。
フラグフィールドうち、ＵＲＬフラグの値だけが１であるため、ペイロードにはＵＲＬ情報が含まれていることが分かる。現在ブロックナンバーフィールドの値が０ｘ０１であるため、既に保存されていた情報と結合されてもよい。特に、既に保存されていたａｔｓｃ．ｏｒｇ部分と、２番目のＷＭに含まれた／ａｐｐｓ／ａｐｐ１．ｈｔｍｌ部分とが結合されてもよい。また、既に保存されていた情報のうち、ＵＲＬプロトコルタイプフィールドの値が００１であるため、最終結合されたＵＲＬは、http://atsc.org/apps/app1.html.であってもよい。このＵＲＬがブラウザを介してローンチされてもよい。
２番目のＷＭによれば、２番目のＷＭが挿入された部分の時点は１０．００５秒である。受信機は１番目のＷＭの５．００５秒を基準にタイムシンクを取ることができ、最後のＷＭの１０．００５秒を基準にタイムシンクを取ることもできる。本実施例は、５秒の間隔でＷＭを２回にわたって伝送した例示であり、ＷＭが挿入されていない５秒の間は、完全にオーディオ／ビデオだけを伝送できる長所があるため、コンテンツのクォリティー低下を防止することができる。すなわち、複数のＷＭに分けてデータが伝達されても、クォリティーの低下を減らすことができる。ＷＭを分けて挿入する時期は、実施例によって異なってもよい。
図３６は、本発明の実施例＃４によるＷＭに挿入されるデータ構造を処理する順序図である。
ここで、サービスプロバイダがＷＭ挿入器にコンテンツを伝達する段階（ｓ５８０１０）、ＷＭ挿入器が受信したコンテンツにＷＭ＃１を挿入する段階（ｓ５８０２０）、ＷＭ挿入器がＷＭ＃１の挿入されたコンテンツを送出する段階（ｓ５８０３０）、ＳＴＢがＷＭ＃１の挿入されたコンテンツを受け取り、非圧縮的Ａ／Ｖデータを出力する段階（ｓ５８０４０）、及び／又はＷＭディテクタがＷＭ＃１を検出する段階（ｓ５８０５０）は、前述した各段階と同一であってもよい。
ここで、ＷＭ＃１は、分けられたデータが挿入されたＷＭのうちの１つを意味し、前述した本発明の実施例＃４における１番目のＷＭであってもよい。前述したように、このＷＭのブロックナンバーフィールドは０ｘ００であり、ＵＲＬ情報はａｔｓｃ．ｏｒｇであってもよい。
ＷＭマネジャーは、検出されたＷＭ＃１をパースした後、これを保存しておくことができる（ｓ５８０６０）。このとき、ＷＭマネジャーは、既に定められた各フィールドのビット数と全ＷＭの長さを参照してパーシングを行うことができる。ブロックナンバーフィールドと最後のブロックナンバーフィールドの値が異なるため、且つ伝達タイプフィールド値が１であるため、ＷＭマネジャーはＷＭをパースして保存しておき、次のＷＭを待つことができる。
ここで、サービスプロバイダがＷＭ挿入器にコンテンツを伝達する段階（ｓ５８０７０）、ＷＭ挿入器が受信したコンテンツにＷＭ＃２を挿入する段階（ｓ５８０８０）、ＷＭ挿入器がＷＭ＃２の挿入されたコンテンツを送出する段階（ｓ５８０９０）、ＳＴＢがＷＭ＃２の挿入されたコンテンツを受け取り、非圧縮的Ａ／Ｖデータを出力する段階（ｓ５８１００）、及び／又はＷＭディテクタがＷＭ＃２を検出する段階（ｓ５８１１０）は、前述した各段階と同一であってもよい。
ここで、ＷＭ＃２は、分けられたデータが挿入されたＷＭのうちの１つを意味し、前述した本発明の実施例＃４における２番目のＷＭであってもよい。前述したように、このＷＭのブロックナンバーフィールドは０ｘ０１であり、ＵＲＬ情報は／ａｐｐｓ／ａｐｐ１．ｈｔｍｌであってもよい。
ＷＭマネジャーは、ＷＭ＃２をパースすることができる（ｓ５８１２０）。ＷＭ＃２をパースして得た情報と、既に保存されていたＷＭ＃１をパースして得た情報とを合わせて全体ＵＲＬを生成することができる（ｓ５８１３０）。この場合、全体ＵＲＬは前述と同一であってもよい。
ここで、ＷＭマネジャーがデスティネーションタイプフィールドによって、受信機内のコンパニオンデバイスプロトコルモジュールに、関連データを伝達する段階（ｓ５８１４０）、コンパニオンデバイスプロトコルモジュールがデスティネーションタイプフィールドによるコンパニオンデバイスに関連データを伝達する段階（ｓ５８１５０）は、前述した各段階と同一であってもよい。
ただし、ここで、デスティネーションタイプフィールドは、前述したように、ＷＭ＃１によって伝達されていてもよい。本発明の実施例＃４の１番目のＷＭのデスティネーションフラグフィールド値が１であるためである。前述したように、このデスティネーションタイプフィールド値はパースされて保存されていてもよい。デスティネーションタイプフィールド値が０ｘ０２であるので、スマートフォンのためのデータであることが分かる。
コンパニオンデバイスプロトコルモジュールは、コンパニオンデバイスと疎通し、関連情報を処理することができる。これは、前述したとおりである。また、前述したように、ＷＭ検出器とＷＭマネジャーは統合されて単一のモジュールに含まれてもよく、その統合モジュールが、ＷＭ検出器とＷＭマネジャーの役割をすべて行うことができる。
図３７は、本発明の他の実施例に係るウォーターマークベースの映像表示装置の構造を示す図である。
本実施例は、前述したウォーターマークベースの映像表示装置の構造と略同一であるが、ウォーターマーク抽出器ｔ５９０３０の下に、ＷＭマネジャーｔ５９０１０、コンパニオンデバイスプロトコルモジュールｔ５９０２０が追加されている。その他のモジュールは、前述と同一であってもよい。
ここで、ウォーターマーク抽出器ｔ５９０３０は、前述したＷＭ検出器に対応してもよい。ウォーターマーク抽出器ｔ５９０３０は、前述したウォーターマークベースの映像表示装置の構造の同名モジュールと同一であってもよい。また、ＷＭマネジャーｔ５９０１０は前述のＷＭマネジャーに、コンパニオンデバイスプロトコルモジュールｔ５９０２０は前述のコンパニオンデバイスプロトコルモジュールに対応する構成であってもよい。各モジュールの動作は、前述したとおりである。
図３８は、フィンガープリンティング方式において、本発明の一実施例に係るデータ構造を示す図である。
フィンガープリンティング（ＦｉｎｇｅｒＰｒｉｎｔｉｎｇ）方式のＡＣＲシステムの場合、ＷＭを使用する場合に比べて、オーディオ／ビデオコンテンツのクォリティー低下が少なくてすむ。フィンガープリンティング方式のＡＣＲシステムの場合、付加的な情報をＡＣＲサーバーから取り込むため、コンテンツに直接挿入されているＷＭに比べて、相対的にクォリティーの低下が少なくてすむ。
ＡＣＲサーバーから情報を取り込む際、前述したようにクォリティー低下による制約が少ないため、ＷＭで用いられたデータ構造をそのまま用いてもよい。すなわち、本発明が提案するデータ構造をＦＰ方式においてもそのまま用いることができる。又は、実施例によって、ＷＭデータ構造の一部の構造だけを用いてもよい。
前述したＷＭのデータ構造が用いられる場合、デスティネーションタイプフィールドの値のうち０ｘ０５が示す意味は変更されてもよい。前述したように、デスティネーションタイプフィールドの値が０ｘ０５である場合、受信機がリモートサーバーにデータを要求するようになる。ＦＰ方式において、リモートサーバーの役割はＡＣＲサーバーで担うことができるため、デスティネーションタイプフィールドが０ｘ０５である場合は削除されたり再定義されてもよい。
その他のフィールドは、前述と同一であってもよい。
図３９は、フィンガープリンティング方式において、本発明の一実施例に係るデータ構造を処理する順序図である。
サービスプロバイダは、送出する放送プログラムからフィンガープリント（ＦＰ）を抽出することができる（ｓ６１０１０）。ここで、サービスプロバイダは、前述したサービスプロバイダと同一であってもよい。サービスプロバイダは、ＡＣＲメーカーが提供するツールを用いてコンテンツ別にフィンガープリントを抽出したり、自身のツールを用いてフィンガープリントを抽出することができる。サービスプロバイダは、オーディオ／ビデオフィンガープリントを抽出することができる。
サービスプロバイダはＡＣＲサーバーに、抽出したフィンガープリントを伝達することができる（ｓ６１０２０）。このとき、伝達される時点は、事前製作プログラムの場合には、放送として送出される前であってもよく、ライブプログラムの場合には、実時間でＦＰが抽出されるやいなやＡＣＲサーバーに伝達されてもよい。実時間でＦＰが抽出されてＡＣＲサーバーに伝達される場合、サービスプロバイダは、コンテンツに対するコンテンツＩＤを付与し、伝送タイプ、デスティネーションタイプ、ＵＲＬプロトコルタイプなどの情報を付与することができる。このとき、与えられた情報は、実時間で抽出されたＦＰにマップされて併せてＡＣＲサーバーに伝達されてもよい。
ＡＣＲサーバーは、受信したＦＰ及び関連情報をＡＣＲ ＤＢに保存することができる（ｓ６１０３０）。受信機は、外部入力から入力されるオーディオ／ビデオ信号からＦＰを抽出することができる。ここで、オーディオ／ビデオ信号は非圧縮的信号であってもよい。このＦＰは、シグネチャと呼ぶことができる。受信機は、ＦＰを用いてＡＣＲサーバーに要求を送ることができる（ｓ６１０４０）。
ＡＣＲサーバーは、受信したＦＰとＡＣＲ ＤＢとを比較することができる。受信したＦＰとマッチされるＦＰがＡＣＲ ＤＢにある場合、受信機で放映中のコンテンツを認識することができる。コンテンツを認識すると、伝達タイプ情報、タイムスタンプ、コンテンツＩＤ、イベントタイプ情報、デスティネーションタイプ情報、ＵＲＬプロトコルタイプ情報、ＵＲＬ情報などを受信機に送ることができる（ｓ６１０５０）。
ここで、各情報は、前述した各フィールドに含めて伝送することができる。例えば、デスティネーションタイプ情報は、デスティネーションタイプフィールドに含まれて伝送されてもよい。受信機に応答する際、伝達されるデータの構造は、前述したＷＭで用いられるデータ構造を用いることができる。
受信機は、ＡＣＲサーバーから受信した情報をパースすることができる。本実施例では、デスティネーションタイプフィールドの値が０ｘ０１であるため、アプリケーションのＵＲＬがＴＶで実行されなければならないことが分かる。ＵＲＬプロトコルタイプフィールドの値とＵＲＬ情報を用いて、最終ＵＲＬであるhttp://atsc.orgを生成することができる。ＵＲＬ生成手続きは、前述したとおりである。
受信機は、当該ＵＲＬを用いてブラウザで放送関連アプリケーションを実行することができる（ｓ６１０６０）。ここで、ブラウザは、前述したブラウザと同一であってもよい。ｓ６１０４０、ｓ６１０５０、ｓ６１０６０の過程が反復されてもよい。
図４０は、本発明の他の実施例に係るウォーターマークペイロードの構造を示す図である。
同図に示す実施例のウォーターマークペイロードは、ドメインタイプ情報、サーバーＵＲＬ情報、タイムスタンプ情報及び／又はトリガータイプ情報を含むことができる。実施例によって、同図のウォーターマークペイロードはオーディオ又はビデオウォーターマクとして活用されてもよい。ここで、ウォーターマークはＷＭ（Ｗａｔｅｒｍａｒｋ）と呼ぶこともできる。実施例によって、ＷＭペイロードは５０ビットのサイズを有することができ、ＷＭシステムは、この５０ビットを１．５秒ごとに伝達することができる。
ドメインタイプ情報は、当該ＷＭペイロードのタイプを示すことができる。ドメインタイプ情報は、当該ペイロードのサーバーＵＲＬ情報及びタイムスタンプ情報のサイズがどのように割り当てられているかを示すことができる。ドメインタイプ情報によって、サーバーＵＲＬフィールドが有するサーバーコードとタイムスタンプフィールドのインターバルコード間のユニークさの範囲（ｓｃｏｐｅ ｏｆ ｕｎｉｑｕｎｅｓｓ）が互いにトレードオフ（ｔｒａｄｅ ｏｆｆ）されてもよい。ドメインタイプ情報は、フィールドのサイズの割り当てによって、当該ペイロードがスモール（ｓｍａｌｌ）ドメイン、ミディアム（ｍｅｄｉｕｍ）ドメイン、ラージ（ｌａｒｇｅ）ドメイン構造のうちいずれの構造を有するかを示すことができる。実施例によって、ドメインタイプ情報は１ビットのサイズを有することもでき、この場合、当該ペイロードがスモールドメイン、又はラージドメインのうちいずれの構造を有するかを示すことができる。
サーバーＵＲＬ情報は、サーバーコードを含むことができる。このサーバーコードは、付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）コンテンツの取得のための開始ポイント（ｓｔａｒｔｉｎｇ ｐｏｉｎｔ）として動作するサーバーを識別するための値であってもよい。サーバーＵＲＬ情報又はサーバーコードは、付加コンテンツを取得できるインターネットアドレスやＩＰアドレス形式、又はこのようなアドレスとマップされる特定コードの形態であってもよい。サーバーＵＲＬ情報が示すＵＲＬに接近して様々な付加コンテンツを取得することができる。
付加コンテンツは、現在ＭＶＰＤから受信機に伝送されているサービス／コンテンツを超えて視聴者に提供可能なコンテンツを意味することができる。付加コンテンツは、サービス、コンテンツ、タイムライン、アプリケーションデータ、代替コンポーネント又はアプリケーション関連情報を含むことができる。付加コンテンツは、インタラクティブサービス情報と呼ぶこともできる。また、付加コンテンツには放送サービス／コンテンツに対するインタラクティブサービス提供のための、アプリケーション特性（ｐｒｏｐｅｒｔｙ）情報が含まれてもよい。また、付加コンテンツには特定（ｓｐｅｃｉｆｉｃ）アプリケーションに対するイベント情報が含まれてもよい。ここで、イベント情報は、アプリケーションによって行われる動作（ａｃｔｉｏｎ）を開始させる（ｉｎｉｔｉａｔｅｓ）報知（ｎｏｔｉｆｉｃａｔｉｏｎ）又はシグナリング情報であってもよい。
タイムスタンプ情報は、インターバルコードを含むことができる。このインターバルコードは、当該ペイロードが挿入された（ｅｍｂｅｄｄｅｄ）、コンテンツのインターバルを識別するための値であってもよい。タイムスタンプ情報又はインターバルコードは、当該ペイロードが挿入されたインターバルを識別したり、当該ＷＭパケット又はＷＭペイロードが挿入される伝送時点情報又は当該ＷＭパケット又はＷＭペイロードが何番目のものであるかを識別することができる。何番目のものであるかを識別する場合には、ＷＭ間の時間間隔があらかじめ定められてもよい。実施例によってタイムスタンプ情報をインターバル情報と呼ぶこともできる。
トリガータイプ情報は、イベントがいつ利用可能であるかをシグナルすることができる。連続したＷＭペイロード内で当該トリガータイプ情報の値が変わるということは、イベントをイベントサーバーから利用可能／取得可能であるということを示すことができる。ここで、イベントは、前述したイベント情報であってもよい。ここで、イベントはダイナミックイベントであってもよい。ダイナミックイベントは、当該イベントの開始時間を、イベント開始時間にほぼ近接して（ａｔ ｔｈｅ ｌａｓｔ ｍｉｎｕｔｅ）認知可能になる場合のイベントを意味することができる。例えば、ライブ放送サービスに対するイベント情報はダイナミックイベントであってもよい。ここで、イベントサーバーは、ダイナミックイベントサーバーであってＨＴＴＰサーバーであってもよい。実施例によって、トリガータイプ情報をクエリ情報、クエリフラグなどと呼ぶこともできる。
すなわち、トリガータイプ情報は、サーバーＵＲＬ情報によるＵＲＬにアクセスする必要があるかを示すことができる。実施例によって、トリガータイプ情報は、ＵＲＬにアクセスする場合、アプリケーション特性情報が得られるか、又はイベント情報が得られるかを示すことができる。イベント情報は、タイムセンシティブ（ｔｉｍｅ ｓｅｎｓｉｔｉｖｅ）な情報であるから、アプリケーション特性情報などと区別する必要がある。タイムセンシティブでない情報を得るためにリソースを浪費し、必要なタイムセンシティブな情報を得られなくなることを防止するためである。また、実施例によって、トリガータイプ情報は、取得するアプリケーション特性情報に変更があるか否かも示すことができる。詳細な事項は後述する。
実施例によって、サーバーＵＲＬ情報及びタイムスタンプ情報はそれぞれ、３０ビット、１７ビットのサイズを有するか（スモールドメインタイプ）、２２ビット、２５ビットのサイズを有するか（ミディアムドメインタイプ）、１８ビット、２９ビットのサイズを有することができる（ラージドメインタイプ）。実施例によってこの数値は変更されてもよい。ここで、スモールドメインの場合、約１０億個のサーバーコードと約５４．６時間のインターバルコードを有することができ、ミディアムドメインの場合、約４２０万個のサーバーコードと約１．５９年のインターバルコードを有することができ、ラージドメインの場合、約２６２，１４４個のサーバーコードと約２５．５年のインターバルコードを有することができる。
実施例によって、サーバーＵＲＬ情報及びタイムスタンプ情報はそれぞれ、３１ビット、１７ビットのサイズを有するか（スモールドメインタイプ）、２３ビット、２５ビットのサイズを有することができる（ラージドメインタイプ）。ここで、ドメインタイプ情報は１ビット、トリガータイプ情報は１ビットのサイズを有することができる。実施例によってこの数値は変更されてもよい。
実施例によって、図示のＷＭペイロードのトリガータイプ情報は２ビットのサイズを有することもできる。トリガータイプ情報が００である場合、これは、サーバーＵＲＬに接近することによってアプリケーション特性情報を取得することができ、この特性情報は、前のＷＭのサーバーＵＲＬから得られる特性情報に比べて変更されていないことを意味することができる。トリガータイプ情報が０１である場合、これは、サーバーＵＲＬに接近することによってアプリケーション特性情報を取得することができ、この特性情報は、前のＷＭのサーバーＵＲＬから得られる特性情報に比べて変更されていることを意味することができる。トリガータイプ情報が１０である場合、これは、サーバーＵＲＬに接近することによってイベント情報を取得できることを意味することができる。トリガータイプ情報が１１である場合は、将来の使用のために残すことができる。
実施例によって、トリガータイプ情報が２ビットと割り当てられる場合において、トリガータイプ情報の値が示す意味は変更されてもよい。例えば、トリガータイプ情報が００である場合、これは、このインターバルでサーバーに要求をすることによって取得できる追加的なアプリ、コンポーネント又は他の情報がないことを意味することができる。この場合、要求（クエリ）がサーバーに送られなくてもよい。トリガータイプ情報が０１である場合、これは、このインターバルでサーバーに要求をすることによって取得できる追加的なアプリ、コンポーネント又は他の情報があり得ることを意味することができる。この場合、要求（クエリ）がサーバーに送られてもよい。トリガータイプ情報が１０である場合、これは、サーバーＵＲＬに接近することによってイベント情報が取得できることを意味することができる。したがって、この場合、最近に要求したことがあっても、再び要求が行われる必要がある。トリガータイプ情報が１１である場合は、将来の使用のために残すことができる。
実施例によって、前述したＷＭペイロードの構造を互いに組み合わせてもよい。また、実施例によって、前述したＷＭペイロードの各情報の割り当てられたサイズを互いに組み合わせてもよい。例えば、それぞれのスモール、ミディアム、ラージドメインによるサーバーＵＲＬ情報及びタイムスタンプ情報のサイズに対して、１ビットであるトリガータイプ情報を組み合わせたり、２ビットであるトリガータイプ情報を組み合わせてもよい。また、それぞれの場合に対して、１ビットであるドメインタイプ情報を組み合わせたり、２ビットであるドメインタイプ情報を組み合わせてもよい。
図４１は、本発明の一実施例に係る、サービス／コンテンツ情報を用いたウォーターマークペイロード構造の変形を示す図である。
前述したそれぞれのＷＭペイロード構造又は組み合わせ可能なそれぞれのＷＭペイロード構造ごとに、サービス情報及び／又はコンテンツ情報を追加して伝達することができる。ここで、サービス情報は、当該ＷＭが挿入されたサービスに関連した情報であってもよい。このサービス情報は、サービスＩＤ又はチャネルＩＤの形態であってもよい。サービス情報がＷＭペイロードに含まれて伝達される場合、サーバーは、特定サービス／チャネルに対する付加コンテンツ（インタラクティブサービス）だけを選択的に提供することができる。また、視聴中のサービス／チャネルが変更される場合、前のサービス／チャネルのインタラクティブサービスが早速終了してもよい。ここで、コンテンツ情報は、当該ＷＭが挿入されたコンテンツに関連した情報であってもよい。コンテンツ情報は、コンテンツＩＤの形態であってもよい。コンテンツ情報がＷＭペイロードに含まれて共に伝達される場合、サーバーは、特定コンテンツに対する付加コンテンツ（インタラクティブサービス）だけを選択的に提供することができる。
同図の実施例ｔ５０２０１０では、前述したＷＭペイロード構造の１つに、サービス情報及び／又はコンテンツ情報が追加されている。同図の実施例ｔ５０２０２０は、前述したＷＭペイロード構造を最小化した後に、サービス情報及び／又はコンテンツ情報を追加した場合である。この場合、ドメインタイプ情報は省略され、サーバーＵＲＬ情報、タイムスタンプ情報及びトリガータイプ情報はそれぞれ１８ビット、１７ビット、２ビットのサイズを有するものとして縮小している。両実施例において、それぞれのサービス情報及びコンテンツ情報は関連放送システムによって任意のサイズ（ｘ、ｙビット）を有することができる。実施例によって、両情報のうち１つだけを追加してもよい。
図４２は、本発明の一実施例に係る、ＮＳＣフィールドを用いたウォーターマークペイロード構造の変形を示す図である。
前述したそれぞれのＷＭペイロード構造に変形を加えて、ＮＳＣ（Ｎｏ Ｓｕｐｐｌｅｍｅｎｔａｌ Ｃｏｎｔｅｎｔ）フィールドを追加してもよい。ＮＳＣフィールドは、付加コンテンツが利用可能か否かを示すことができる。ＮＳＣフィールドは１ビットであり、フラグとして動作することができる。付加コンテンツについては前述した。
ＮＳＣフィールドのための１ビットは、前述したドメインタイプ情報のサイズを減らすことによって取得することができる。実施例によって、ドメインタイプ情報のサイズは１ビットに減らすことができる。前述したように、ドメインタイプ情報はＷＭペイロードのタイプを示すが、この場合、ドメインタイプ情報は、ＷＭペイロードがスモールドメインであるか、ラージドメインであるかの２つの場合を示すことができる。すなわち、２タイプのドメインで十分であれば、ドメインタイプ情報の１ビットをＮＳＣフィールドとして割り当てて、付加コンテンツを使用できるか否かを示すことができる。実施例によってドメインタイプ情報のサイズを減らすことなく、単純に、前述したＷＭペイロード構造にＮＳＣフィールドを追加してもよい。
この実施例で、スモールドメインの場合、サーバーＵＲＬフィールドは２２ビット、タイムスタンプフィールドは２５ビットであってもよい。ラージドメインの場合、サーバーＵＲＬフィールドは１８ビット、タイムスタンプフィールドは２９ビットであってもよい。これは、スモールドメインの場合、約４２０万個のサーバーコードと約１．５９年のインターバルコードを有することができ、ラージドメインの場合、約２６２，１４４個のサーバーコードと約２５．５年のインターバルコードを有することができる。ここで、トリガータイプ情報は１ビット又は２ビットのサイズを有することができる。
ＷＭペイロードの情報によって、受信機はサーバーに要求（ｑｕｅｒｙ）を送ることができる。この要求を送る場合は、（１）受信機が初めてウォーターマーキングされたセグメントを受信（ｔｕｎｅｄ）して要求する場合、（２）付加コンテンツの要求情報によって追加に要求を送る場合、（３）前述したトリガータイプ情報による対応として要求する場合、であってもよい。
ＮＳＣフィールドの追加によって、付加コンテンツがない場合には要求が行われなくてすむ。例えば、受信機が初めてウォーターマークを受信した場合に送る要求は行われなくてもよい。したがって、チャネルサーフィン（ｃｈａｎｎｅｌ ｓｕｒｆｉｎｇ）する場合において、ＮＳＣフィールドの追加は効率的である。また、サービス／コンテンツは、付加コンテンツがない場合にも、サービス使用（ｕｓａｇｅ）報告のためにマーキング（ウォーターマーキング）されてもよいが、この場合にもＮＳＣフィールド追加は効率的である。特に、保存＆使用報告を伝達するメカニズムの場合にいっそう効率的であろう。すなわち、一般に、多量のコンテンツがマーキング（ウォーターマーキング）されているが、付加コンテンツはない場合などにおいて効率的であろう。また、ＳＭＰＴＥオープンＩＤの場合、継続してウォーターマーキングされたコンテンツが好ましいだろう。この場合、継続してマーキングされたコンテンツは、２つのＳＤＯが共通ＷＭソリューションを決定することに役立てることができる。
図４３は、本発明の一実施例に係る、ビデオ−オーディオウォーターマーク間のリンキング（ｌｉｎｋｉｎｇ）のためのウォーターマークペイロード構造を示す図である。
本発明は一実施例として、ビデオＷＭとオーディオＷＭを同時に（ｓｉｍｕｌｔａｎｅｏｕｓｌｙ）挿入する方法を提案する。そのために、ビデオＷＭペイロードの一部をオーディオＷＭペイロードのために割り当てることができる。ビデオＷＭペイロード（例えば、３０〜６０バイト）の一部（例えば、５０ビット）は、オーディオＷＭペイロードと重複する情報（ｄｕｐｌｉｃａｔｅ）を搬送することができる。この重複する情報は、オーディオＷＭペイロードの情報と同じ情報であり、複写本であってもよい。
また、このビデオＷＭとオーディオＷＭとがシンクして伝送されてもよい。ビデオＷＭは、少なくとも１つのメッセージブロックを含むことができ、このメッセージブロックの一つは、該当の構造のＷＭペイロードを有することができる。この場合、そのサービス／コンテンツのオーディオに挿入されたオーディオＷＭは、ビデオＷＭと同じＷＭペイロードを有することができる。このとき、ビデオＷＭペイロードを伝達するメッセージブロックの最初のビデオフレームは、該当するオーディオＷＭの最初の部分とタイムアライン（ｔｉｍｅ ａｌｉｇｎｅｄ）されてもよい。実施例によって、一定の誤差内で両者がタイムアラインされてもよい。実施例によって、メッセージブロックは、複数個のビデオフレームを含むことができ、このそれぞれのビデオフレームは、同じビデオＷＭペイロードを繰り返して（ｒｅｐｅａｔｅｄ）有することができる。実施例によって、逆に、オーディオＷＭペイロードの一部を割り当てて、ビデオＷＭペイロードの複写本を搬送するようにしてもよい。
例えば、ユーザがＭＶＰＤ ＳＴＢ（Ｓｅｔ ｔｏｐ ｂｏｘ）からＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を持ってきてディスプレイさせる場合に問題が発生しうる。まず、オーディオＷＭだけが用いられる場合において、ＥＳＧがディスプレイされても、オーディオは継続して再生されうる。しかし、オーディオＷＭクライアントは、ＥＳＧがディスプレイされるという点に気付けないことがある。したがって、アプリケーションは継続して実行され、これによるグラフィックなどはＥＳＧに重なって妨害を与えうる。
また、ビデオＷＭだけが用いられる場合において、ＥＳＧがディスプレイされると、ビデオＷＭクライアントはＷＭが消えたと認知し、視聴者によってチャネルを変更されたと判断したり、インタラクティブイベントが終わったと判断しうる。このため、視聴者がチャネル変更すことなく、ＥＳＧを消して再びインタラクティブサービスを以前時点で再開しようとしても、関連アプリケーションはビデオＷＭクライアントによって終了している場合がありうる。
したがって、オーディオＷＭとビデオＷＭを直列的に（ｉｎ ｔａｎｄｅｍ）使用することが効率的である。オーディオＷＭと違い、ビデオＷＭは受信機に、メインビデオが現在スクリーンにフォーカスされていない（ＥＳＧが用いられる場合など）と知らせることができる。また、ビデオＷＭと違い、オーディオＷＭは、ＥＳＧが用いられる間にも続けてＷＭ情報を提供することができる。これによって、受信機は、ＥＳＧ作動中にも、ＷＭ又は関連付加コンテンツに変更があるかをトラッキングすることができる。
したがって、ビデオＷＭによって、ＥＳＧがスクリーンに表示されていることが認知でき、オーディオＷＭによって、適切な受信機動作が継続してシームレスに行われることが可能である。例えば、アプリケーションがグラフィックを提供しない場合（例えばバックグラウンドアプリ）、ＥＳＧに関係なく継続して実行されてもよい。例えば、アプリケーションがグラフィックを提供する場合、ＥＳＧが消えるまで抑制（ｓｕｐｐｒｅｓｓｅｄ）されてもよい。例えば、アプリケーションがイベントを受けると、受信機は、それをＥＳＧが消えるまでバックグラウンドで処理することができる。すなわち、オーディオＷＭとビデオＷＭとをリンキングすることによって、この問題を解決することができる。
図４４は、本発明の一実施例に係る、リンクされたビデオ−オーディオウォーターマークを用いた動作を示す図である。
まず、ユーザによってＥＳＧがスクリーンに表示される場合の動作を説明する。まず、オリジナルサービス／コンテンツが放送局からＳＴＢなどのＭＶＰＤに受信されてもよい（ｔ５０５０１０）。ＳＴＢ、ケーブルなどの外部入力ソースはそれを受信機に伝達することができる（ｔ５０５０２０）。ここで、伝達されるＡＶコンテンツは非圧縮された（ｕｎｃｏｍｐｒｅｓｓｅｄ）状態であり、リンクされたオーディオＷＭとビデオＷＭを有することができる。受信機は、オーディオＷＭとビデオＷＭを感知し、それによる動作を行うことができる。
ここで、ユーザがＳＴＢのリモートコントローラでＥＳＧを要求することができる（ｔ５０５０３０）。ＳＴＢは、それに応じてＴＶスクリーンにＥＳＧを表示させることができる（ｔ５０５０４０）。ＥＳＧは、再生中のＡＶコンテンツに重なってもよい。すると、ＴＶ受信機は、オーディオＷＭは感知するが、ビデオＷＭは感知できなくなる（ｔ５０５０５０）。受信機は、メインビデオコンテンツがＥＳＧなどのその他のグラフィックによって覆われたことを認知し、リンクされたオーディオＷＭにアクセスして必要な動作をシームレスに行うことができる。
次に、ユーザがコンテンツを音消去（ｍｕｔｅ）させた場合の動作を説明する。ＡＶコンテンツをＳＴＢを介してＴＶ受信機が受信する内容（ｔ５０５０１０〜ｔ５０５０２０）は、前述したとおりである。ここで、ユーザは、ＳＴＢのリモートコントローラで音消去（ｍｕｔｅ）を要求することができる（ｔ５０５０３０）。ＳＴＢはそれに応じてＡＶコンテンツを音消去させることができる（ｔ５０５０４０）。すると、ＴＶ受信機は、ビデオＷＭは感知するが、オーディオＷＭは感知できなくなる（ｔ５０５０５０）。受信機は、メインオーディオコンテンツが音消去されたことを認知し、該当のオーディオＷＭペイロードデータを、リンクされたビデオＷＭペイロードから取得することができる。これによって、受信機は必要な動作をシームレスに行うことができる。
図４５は、本発明の一実施例に係る放送コンテンツ処理方法を示す図である。
本発明の一実施例に係る放送コンテンツ処理方法は、外部入力ソースから放送コンテンツを受信する段階、放送コンテンツからオーディオ又はビデオウォーターマークを抽出する段階、ウォーターマークから生成されたＵＲＬで放送コンテンツの付加コンテンツを要求する段階、及び／又はサーバーから付加コンテンツを取得する段階を含むことができる。
まず、受信機の受信ユニットは、外部入力ソースから放送コンテンツを受信することができる。ここで、外部入力ソースは、ＳＴＢ、ケーブル、衛星などのＭＶＰＤを意味することができる。放送コンテンツは放送ストリームから誘導されたものであり、非圧縮された（ｕｎｃｏｍｐｒｅｓｓｅｄ）ＡＶコンテンツであってもよい。この放送コンテンツは、オーディオ及び／又はビデオコンポーネントを含み、このコンポーネントはそれぞれ、オーディオＷＭ、ビデオＷＭが挿入されていてもよい。
受信機の抽出器は、放送コンテンツからオーディオＷＭ、ビデオＷＭの少なくとも１つを抽出することができる。受信機のネットワークインタフェースは、オーディオ／ビデオＷＭから生成されたＵＲＬで特定されるサーバーに、付加コンテンツを要求することができる。付加コンテンツは、放送コンテンツに関連したものであり、その詳細な事項は前述した。ＵＲＬは、ＷＭペイロードのサーバーコード又はサーバーＵＲＬ情報から誘導されたものであってもよい。ネットワークインタフェースは、サーバーから付加コンテンツを取得することができる。オーディオ／ビデオＷＭは、放送コンテンツに関連した補充（ａｕｘｉｌｉａｒｙ）データの伝達に用いられてもよい。
本発明の他の実施例に係る放送コンテンツ処理方法において、オーディオＷＭのうち少なくとも１つのオーディオＷＭは、オーディオＷＭペイロードを含み、そのオーディオＷＭペイロードは、ドメインタイプ情報、サーバー情報、インターバル情報及び／又はクエリ（ｑｕｅｒｙ）情報を含むことができる。これらの情報は順に、前述したドメインタイプ情報、サーバーＵＲＬ情報、タイムスタンプ情報及び／又はトリガータイプ情報であってもよい。
本発明の他の実施例に係る放送コンテンツ処理方法において、ドメインタイプ情報は、オーディオＷＭペイロードのタイプを特定し、サーバー情報は、付加コンテンツの取得のためのサーバーを識別し、インターバル情報は、オーディオＷＭペイロードが挿入されたオーディオコンポーネントのインターバルを識別し、クエリ情報は、サーバーからイベントシグナリングが使用可能か否かをシグナルすることができる。これらの情報については詳細に前述した。イベントシグナリングは、アプリケーションの動作を開始する、前述したイベント情報に該当してもよい。
本発明の他の実施例に係る放送コンテンツ処理方法において、ビデオＷＭのうち少なくとも１つのビデオＷＭは、ビデオＷＭペイロードを含み、そのビデオＷＭペイロードは、オーディオＷＭペイロードと同じ情報を含む少なくとも１つのメッセージブロックを含むことができる。前述したように、ビデオＷＭペイロードはオーディオＷＭペイロードのための空間を割り当てて、これを含むことができる。
本発明の他の実施例に係る放送コンテンツ処理方法において、オーディオＷＭペイロードと同じ情報を含むビデオＷＭは、オーディオＷＭペイロードを運搬するオーディオＷＭとタイムアライン（ｔｉｍｅ−ａｌｉｇｎｅｄ）されてもよい。オーディオ／ビデオＷＭ間のリンクは詳細に前述した。
本発明の他の実施例に係る放送コンテンツ処理方法において、付加コンテンツにはディスコンポーネント（ｔｈｉｓＣｏｍｐｏｎｅｎｔ）情報及び／又はアザーコンポーネント（ｏｔｈｅｒＣｏｍｐｏｎｅｎｔ）情報を含むことができる。ディスコンポーネント情報は、該当の付加コンテンツを要求するために用いられた該当のＷＭペイロードが感知されたサービスコンポーネントに関する情報を記述することができる。該当のＷＭペイロードのサーバー情報／インターバル情報によって該当の付加コンテンツが要求されたものであってもよい。アザーコンポーネント情報は、ディスコンポーネント情報が記述するコンポーネント以外のコンポーネントのうち、該当のＷＭペイロードと一致するＷＭペイロードを有するコンポーネントについて記述することができる。このＷＭペイロードはビデオ又はオーディオＷＭであってもよい。
本発明の他の実施例に係る放送コンテンツ処理方法は、受信機の抽出器が、オーディオ又はビデオＷＭのいずれか一つが消えたことを認知する段階と、消えていない他のＷＭを該当のコンポーネントから抽出する段階とをさらに含むことができる。これは、前述した動作のように、ＥＳＧがスクリーンに表示されたり音消去される場合において、ビデオ又はオーディオＷＭが消えたことを認知し、同じペイロードを有するＷＭにアクセスしてシームレスに正常動作を行うためであってもよい。
本発明の一実施例に係る放送コンテンツ処理方法（伝送側）を説明する。この方法は図面に図示されていない。
本発明の一実施例に係る放送コンテンツ処理方法（伝送側）は、サービスデータ生成モジュールがビデオ／オーディオコンポーネントを有する放送サービスを生成する段階、ＷＭ挿入モジュールがビデオ／オーディオコンポーネントにビデオ／オーディオＷＭを挿入する段階、サービスデータ生成モジュールが放送サービスに関連したシグナリング情報を生成する段階、及び／又は伝送ユニットが放送サービスデータ及びシグナリング情報をＭＶＰＤに伝送する段階を含むことができる。実施例によって、サービスデータ生成モジュールが、放送サービスに対する付加コンテンツを生成し、これを付加コンテンツサーバーに伝達し、ＷＭ挿入モジュールがこのサーバー及び付加コンテンツに関連した情報をＷＭに含める段階をさらに含むことができる。
本発明の実施例による放送コンテンツ処理方法（伝送側）は、前述した本発明の実施例による放送コンテンツ処理方法に対応してもよい。放送コンテンツ処理方法（伝送側）は、前述した放送コンテンツ処理方法の実施例に対応する実施例を有することができる。
前述した段階は、実施例によって省略してもよく、類似／同一の動作を行う他の段階に置き換えてもよい。
図４６は、本発明の一実施例に係る放送コンテンツ処理装置を示す図である。
本発明の一実施例に係る放送コンテンツ処理装置は、前述した受信ユニット、抽出器及び／又はネットワークインタフェースを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。本発明の一実施例に係る放送コンテンツ処理装置及びその内部モジュール／ブロックは、前述した本発明の放送コンテンツ処理方法の実施例を実行することができる。
本発明の一実施例に係る放送コンテンツ処理装置（伝送側）を説明する。この装置は図示を省略した。本発明の一実施例に係る放送コンテンツ処理装置（伝送側）は、前述したサービスデータ生成モジュール、ＷＭ挿入モジュール及び／又は伝送ユニットを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。本発明の一実施例に係る放送コンテンツ処理装置（伝送側）及びその内部モジュール／ブロックは、前述した本発明の放送コンテンツ処理方法（伝送側）の実施例を実行することができる。
前述した装置の内部のブロック／モジュールなどは、メモリに保存された連続した手続を実行するプロセッサであり、実施例によって装置の内／外部に設けられるハードウェアエレメントであってもよい。前述したモジュールは、実施例によって省略してもよく、類似／同一の動作を行う他のモジュールに置き換えてもよい。
モジュール又はユニットは、メモリ（又は記憶ユニット）に格納された連続した手続を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって行われてもよい。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実行されてもよい。このコードは、プロセッサが読み取り可能な記憶媒体に書き込まれてもよく、よって、装置（ａｐｐａｒａｔｕｓ）の提供するプロセッサによって読み取られてもよい。
説明の便宜のために各図に分けて説明したが、各図に示した実施例を併合して新しい実施例を具現するように設計してもよい。そして、通常の技術者の必要によって、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも、本発明の権利範囲に属する。
本発明に係る装置及び方法は、上述したように、説明された実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例の様々な変形が可能なように、各実施例の全て又は一部を選択的に組み合わせて構成することもできる。
一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することもできる。プロセッサが読み取り可能な記録媒体は、プロセッサで読み出し可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークに接続されたコンピュータシステムに分散され、分散方式によって、プロセッサが読み取り可能なコードを記憶して実行してもよい。
また、以上では本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨から逸脱しない限度内で、当該発明の属する技術の分野における通常の知識を有する者にとって様々な変形実施が可能であることは勿論であり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
そして、当該明細書では、物の発明と方法の発明が説明されており、必要によって両発明の説明を補充的に適用してもよい。
本発明の思想や範囲から逸脱することなく、当業者にとって本発明の様々な変更及び変形が可能であることは明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。
本明細書では装置の発明及び方法の発明を両方とも言及しており、装置の発明及び方法の発明の説明を互いに補完して適用することもできる。
様々な実施例を、本発明を実施するための形態で説明した。
本発明は一連の放送信号提供分野で利用される。
本発明の思想や範囲から逸脱することなく、本発明で様々な変更及び変形が可能であることは当業者には自明である。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。

Claims (6)

  1. 外部入力ソースから放送コンテンツを受信するステップであって、前記放送コンテンツは、ビデオウォーターマークが挿入された（ｅｍｂｅｄｄｅｄ）ビデオコンポーネント、及びオーディオウォーターマークが挿入されたオーディオコンポーネントを含む、ステップと、
    前記放送コンテンツから前記オーディオウォーターマーク又は前記ビデオウォーターマークの少なくとも１つを抽出するステップと、
    前記オーディオウォーターマーク又は前記ビデオウォーターマークのペイロードから生成されたＵＲＬによって特定されるサーバーに前記放送コンテンツの付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）コンテンツを要求するステップと、
    前記サーバーから前記付加コンテンツを取得するステップと、
    を有し、
    前記オーディオウォーターマークは、ドメインタイプフィールド、サーバーフィールド、インターバルフィールド及びクエリフィールドを有する前記ペイロードを含み、前記ドメインタイプフィールドは、前記サーバーフィールド及び前記インターバルフィールドのビット割当てを特定し、前記サーバーフィールドは、前記付加コンテンツの取得のための前記サーバーを識別し、前記インターバルフィールドは、前記ペイロードを有する前記オーディオウォーターマークが挿入された前記放送コンテンツのインターバルを識別し、前記クエリフィールドは、前記サーバーからイベントシグナリングが使用可能なときにシグナルし、前記イベントシグナリングは、アプリケーションにより行われる動作を開始し、
    前記ビデオウォーターマークは、前記オーディオウォーターマーク内の前記ペイロードと同じ情報を有するペイロードを含み、前記ビデオウォーターマークは、前記ペイロードを有する前記オーディオウォーターマークとタイムアラインされる、放送コンテンツ処理方法。
  2. 前記ペイロードは、５０ビットのサイズを有し、前記サーバーフィールド及び前記インターバルフィールドは、前記５０ビット内のサイズで変動する、請求項１に記載の放送コンテンツ処理方法。
  3. 前記放送コンテンツ処理方法は、
    前記オーディオウォーターマーク又は前記ビデオウォーターマークの一方が消えたことを認知するステップと、
    前記オーディオウォーターマーク又は前記ビデオウォーターマークの他方を前記放送コンテンツから抽出するステップと、
    をさらに有する、請求項１に記載の放送コンテンツ処理方法。
  4. 外部入力ソースから放送コンテンツを受信する受信ユニットであって、前記放送コンテンツは、ビデオウォーターマークが挿入された（ｅｍｂｅｄｄｅｄ）ビデオコンポーネント、及びオーディオウォーターマークが挿入されたオーディオコンポーネントを含む、受信ユニットと、
    前記放送コンテンツから前記オーディオウォーターマーク又は前記ビデオウォーターマークの少なくとも１つを抽出する抽出器と、
    前記オーディオウォーターマーク又は前記ビデオウォーターマークのペイロードから生成されたＵＲＬによって特定されるサーバーに前記放送コンテンツの付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）コンテンツを要求するネットワークインタフェースと、
    を備え、
    前記ネットワークインタフェースは、前記サーバーから前記付加コンテンツを取得し、
    前記オーディオウォーターマークは、ドメインタイプフィールド、サーバーフィールド、インターバルフィールド及びクエリフィールドを有する前記ペイロードを含み、前記ドメインタイプフィールドは、前記サーバーフィールド及び前記インターバルフィールドのビット割当てを特定し、前記サーバーフィールドは、前記付加コンテンツの取得のための前記サーバーを識別し、前記インターバルフィールドは、前記ペイロードを有する前記オーディオウォーターマークが挿入された前記放送コンテンツのインターバルを識別し、前記クエリフィールドは、前記サーバーからイベントシグナリングが使用可能なときにシグナルし、前記イベントシグナリングは、アプリケーションにより行われる動作を開始し、
    前記ビデオウォーターマークは、前記オーディオウォーターマーク内の前記ペイロードと同じ情報を有するペイロードを含み、前記ビデオウォーターマークは、前記ペイロードを有する前記オーディオウォーターマークとタイムアラインされる、放送コンテンツ処理装置。
  5. 前記ペイロードは、５０ビットのサイズを有し、前記サーバーフィールド及び前記インターバルフィールドは、前記５０ビット内のサイズで変動する、請求項４に記載の放送コンテンツ処理装置。
  6. 前記抽出器は、前記オーディオウォーターマーク又は前記ビデオウォーターマークの一方が消えたことを認知し、前記オーディオウォーターマーク又は前記ビデオウォーターマークの他方を前記放送コンテンツから抽出する、請求項４に記載の放送コンテンツ処理装置。
JP2016555355A 2015-04-23 2016-04-21 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Expired - Fee Related JP6294503B2 (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201562151447P 2015-04-23 2015-04-23
US62/151,447 2015-04-23
US201562152037P 2015-04-24 2015-04-24
US62/152,037 2015-04-24
US201562154733P 2015-04-30 2015-04-30
US201562155445P 2015-04-30 2015-04-30
US62/155,445 2015-04-30
US62/154,733 2015-04-30
PCT/KR2016/004174 WO2016171496A1 (ko) 2015-04-23 2016-04-21 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Publications (2)

Publication Number Publication Date
JP2017522742A JP2017522742A (ja) 2017-08-10
JP6294503B2 true JP6294503B2 (ja) 2018-03-14

Family

ID=57143334

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016555355A Expired - Fee Related JP6294503B2 (ja) 2015-04-23 2016-04-21 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Country Status (6)

Country Link
US (1) US20170078765A1 (ja)
EP (1) EP3288277A4 (ja)
JP (1) JP6294503B2 (ja)
KR (2) KR101838084B1 (ja)
CN (1) CN106304851A (ja)
WO (1) WO2016171496A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107852530B (zh) * 2015-07-06 2021-07-09 Lg电子株式会社 广播信号发送设备、广播信号接收设备、广播信号发送方法和广播信号接收方法
US20190253739A1 (en) * 2016-11-04 2019-08-15 Sharp Kabushiki Kaisha Dynamic event signaling
KR102514752B1 (ko) * 2017-03-14 2023-03-28 소니 세미컨덕터 솔루션즈 가부시키가이샤 송신 장치, 수신 장치 및 데이터 처리 방법
JP2019106592A (ja) * 2017-12-11 2019-06-27 トヨタ自動車株式会社 情報提供装置及び情報提供方法
KR20200021280A (ko) * 2018-08-20 2020-02-28 (주)스마일게이트스토브 게임 아이템의 구매를 위한 서버, 컨텐츠 제공자 단말 및 시청자 단말
US11356747B2 (en) * 2018-12-21 2022-06-07 The Nielsen Company (Us), Llc Apparatus and methods to associate different watermarks detected in media
WO2020259604A1 (zh) * 2019-06-28 2020-12-30 海信视像科技股份有限公司 数字内容发送装置、发送方法、数字内容接收装置、接收方法
CN110267062B (zh) * 2019-07-26 2022-07-08 深圳Tcl新技术有限公司 拼装视频帧的优化方法、装置及可读存储介质
KR102457065B1 (ko) 2021-02-18 2022-10-20 주식회사 엘지유플러스 컨텐츠 제공 서버 및 그 제어 방법, 컨텐츠 제공 방법 및 시스템

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6411725B1 (en) * 1995-07-27 2002-06-25 Digimarc Corporation Watermark enabled video objects
US7644282B2 (en) * 1998-05-28 2010-01-05 Verance Corporation Pre-processed information embedding system
JP2001292427A (ja) * 2000-04-06 2001-10-19 Nippon Television Network Corp コンテンツの連動方法、及びそのシステム
US7133534B2 (en) * 2002-09-03 2006-11-07 Koninklijke Philips Electronics N.V. Copy protection via redundant watermark encoding
US7970899B2 (en) 2006-03-03 2011-06-28 Barracuda Networks Inc Integrated data flow packet admission and traffic management apparatus
WO2008141169A1 (en) 2007-05-09 2008-11-20 Entropic Communications, Inc. Aggregating network packets for transmission to a destination node
KR100902887B1 (ko) * 2008-10-17 2009-06-16 주식회사 씨케이앤비 디지털 영상 장치의 영상 왜곡 판단 테스트 자동화 시스템
EP2257067A1 (en) * 2009-05-29 2010-12-01 Thomson Licensing Method for inserting watermark assistance data in a bitstream, method of watermarking said bitstream, device implementing the method of watermarking and bitstream comprising the watermark assistance data
GB2508451B (en) * 2010-12-26 2017-05-03 Lg Electronics Inc Broadcast service transmitting method, broadcast service receiving method and broadcast service receiving apparatus
KR101695514B1 (ko) * 2011-05-24 2017-01-11 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법
KR101995425B1 (ko) * 2011-08-21 2019-07-02 엘지전자 주식회사 영상 표시 장치, 단말 장치 및 그 동작 방법
CA2851607C (en) * 2011-10-20 2018-02-06 Lg Electronics Inc. Broadcast service receiving method and broadcast service receiving apparatus
WO2014007571A1 (en) * 2012-07-05 2014-01-09 Lg Electronics Inc. Method and apparatus for processing digital service signals
JP6193993B2 (ja) * 2012-07-16 2017-09-06 エルジー エレクトロニクス インコーポレイティド デジタルサービス信号処理方法及び装置
US9286912B2 (en) * 2012-09-26 2016-03-15 The Nielsen Company (Us), Llc Methods and apparatus for identifying media
KR102113503B1 (ko) * 2013-08-26 2020-06-05 삼성전자주식회사 전자 장치 및 전자 장치에서 컨텐츠 제공 방법
WO2015138798A1 (en) * 2014-03-13 2015-09-17 Verance Corporation Interactive content acquisition using embedded codes

Also Published As

Publication number Publication date
JP2017522742A (ja) 2017-08-10
KR101838084B1 (ko) 2018-03-13
WO2016171496A1 (ko) 2016-10-27
KR20160137954A (ko) 2016-12-02
EP3288277A1 (en) 2018-02-28
US20170078765A1 (en) 2017-03-16
KR101805538B1 (ko) 2017-12-07
CN106304851A (zh) 2017-01-04
EP3288277A4 (en) 2018-09-12
KR20170136006A (ko) 2017-12-08

Similar Documents

Publication Publication Date Title
JP6294503B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
US10939145B2 (en) Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method
JP6193993B2 (ja) デジタルサービス信号処理方法及び装置
US9912971B2 (en) Apparatus and method for processing an interactive service
JP6290935B2 (ja) 映像表示装置及びその動作方法
US9398341B2 (en) Apparatus and method for processing an interactive service
CA2851888C (en) Method of processing non-real time service and broadcast receiver
KR20140125766A (ko) 영상 표시 장치 및 그 동작 방법
US20170164071A1 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
US10171852B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
KR101666246B1 (ko) 메타데이터 우선제공 증강방송 장치 및 방법
KR102263146B1 (ko) 영상 표시 장치 및 그 동작 방법
US20180359495A1 (en) Apparatus for broadcast signal transmission, apparatus for broadcast signal reception, method for broadcast signal transmission, and method for broadcast signal reception

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170919

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171215

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: 20180116

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180215

R150 Certificate of patent or registration of utility model

Ref document number: 6294503

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees