JP6247309B2 - 双方向サービスを処理する装置及び方法 - Google Patents

双方向サービスを処理する装置及び方法 Download PDF

Info

Publication number
JP6247309B2
JP6247309B2 JP2015543996A JP2015543996A JP6247309B2 JP 6247309 B2 JP6247309 B2 JP 6247309B2 JP 2015543996 A JP2015543996 A JP 2015543996A JP 2015543996 A JP2015543996 A JP 2015543996A JP 6247309 B2 JP6247309 B2 JP 6247309B2
Authority
JP
Japan
Prior art keywords
trigger
application
receiver
event
activation
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
JP2015543996A
Other languages
English (en)
Other versions
JP2016506114A (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 JP2016506114A publication Critical patent/JP2016506114A/ja
Application granted granted Critical
Publication of JP6247309B2 publication Critical patent/JP6247309B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/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/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4122—Peripherals receiving signals from specially adapted client devices additional display device, e.g. video projector
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • 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/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、放送サービスを提供、受信及び処理する方法及び装置に関し、特に、放送コンテンツに関連する付加サービスを提供する方法及び装置に関する。
ＴＶは、１９世紀末に初めて登場して以来、画面表示方法やデザインなどにおいて発展を遂げ続き、２０世紀後半からは最も大衆的な情報伝達機器として確立された。ただし、ＴＶは、放送局から提供する単方向の情報を視聴者たちが一方的に受容するという根本的な形態をしていた。このようなＴＶの限界は、１９９０年代からＰＣ（個人用コンピュータ）及びインターネットが大衆化するにつれてより明らかになり始めた。そこで、ＴＶは双方向サービスが可能な方向に進化を続けてきている。
しかしながら、現在、コンテンツプロバイダと視聴者との間には、上記のような双方向サービスを本格的に実行するシステムがない実情である。特に、上記のような双方向サービスの提供のために、放映中の放送コンテンツに関連するアプリケーションを特定時点に駆動し、情報の特定処理を通じて、視聴者に関連情報を提供する方法及びフォーマットに関する技術的支援が必要な状況である。
本発明が遂げようとする技術的課題は、前述した問題点を解決するためのもので、放送コンテンツが再生される期間中に、適切な時期に放送コンテンツに関連する付加情報を提供することにある。
本発明の目的は、デジタルサービス信号を処理する方法であり、前記デジタルサービス信号に対するプライマリアプリケーションを実行するステップであって、前記プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされていないアプリケーションである、ステップと、前記プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブ（双方向）サービスのメッセージを送信するステップであって、前記インタラクティブサービスは、前記トリガーされたアプリケーションに関連した第１モード及び前記トリガーされていないアプリケーションに関連した第２モードを含む、ステップと、前記インタラクティブサービスを識別する記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を受信するステップと、前記インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及び前記インタラクティブサービスのそれぞれのタイプを示すサービスタイプ情報を有する記述を送信するステップと、前記インタラクティブサービスに対する情報を送信することによって前記インタラクティブサービスを提供するステップを含む方法によって達成される。
好適には、前記インタラクティブサービスに対する情報は、前記インタラクティブサービスのそれぞれによって定義され、前記インタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つである。
好適には、前記インタラクティブサービスに対する情報がトリガーであれば、前記トリガーの少なくとも一つは、前記デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含む。
好適には、前記インタラクティブサービスに対する情報がトリガーであれば、前記方法は、ＴＰＴ内の情報と結合することによって前記トリガーを増加（ａｕｇｍｅｎｔ）させるステップであって、前記ＴＰＴは、前記トリガーされたアプリケーションに対するメタデータを含む、ステップと、前記トリガー内で識別されたイベントを示すイベント指示子を有する増加したトリガーを送信するステップをさらに含む。
好適には、前記インタラクティブサービスに対する情報がバイトであれば、前記インタラクティブサービスは、前記アプリケーションが実行されて前記セカンダリアプリケーションとの通信に参加する準備ができているかを示すステータス（ｓｔａｔｕｓ）状態変数を含み、前記方法は、前記ｓａｔｕｓ状態変数を設定するステップをさらに含む。
好適には、前記プライマリアプリケーションは、ＡＰＩを用いてインタラクティブサービスを提供する。
好適には、前記ＡＰＩは、バイト及びバイト引数（ａｒｇｕｍｅｎｔ）に対するアドレス及びポートに関する情報を有するアドレス引数を含む。
好適には、前記方法は、前記メッセージを送信する前に、前記プライマリアプリケーションに関連した前記セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信するステップをさらに含む。
本発明の他の形態において、デジタルサービス信号を処理する方法であって、前記デジタルサービス信号に対するアプリケーションを実行するステップと、前記実行されたアプリケーションに対するインタラクティブサービスのメッセージを受信するステップと、前記インタラクティブサービスを識別する記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を送信するステップと、前記インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及び前記インタラクティブサービスのそれぞれのタイプを示すサービスタイプ情報を有する記述を受信するステップと、前記記述を用いて少なくとも一つのインタラクティブサービスをアクセスするステップと、前記アクセスされたインタラクティブサービスに対するファイルをダウンロードするステップを含み、前記アクセスするステップは、前記少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入するステップと、前記通知を受信するステップと、前記受信された通知を用いて前記少なくとも一つのインタラクティブサービスに対する情報を受信するステップとを含む、方法が提供される。
好適には、前記少なくとも一つのインタラクティブサービスに対する情報は、前記インタラクティブサービスによって定義され、前記少なくとも一つのインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つである。
好適には、前記探索されたインタラクティブサービスに対する情報がトリガーであれば、前記トリガーの少なくとも一つは、前記デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含む。
好適には、前記アクセスされたインタラクティブサービスに対する情報がバイトであれば、前記方法は、前記受信された通知を用いて前記インタラクティブサービスが始まる準備ができているかを決定するステップと、前記受信された通知を用いてバイトを送信するための接続に対する要求を送信するステップをさらに含む。
好適には、前記方法は、前記メッセージを受信する前に、前記実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を送信するステップをさらに含む。
本発明の他の形態において、デジタルサービス信号を処理する装置であって、前記デジタルサービス信号に対するプライマリアプリケーションを実行するように構成された実行モジュールであって、前記プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされていないアプリケーションである、モジュールと、前記プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージ及び前記インタラクティブサービスを識別する記述（ｄｅｓｃｒｉｐｔｉｏｎ）を送信するように構成された送信モジュールであって、前記インタラクティブサービスモジュールは、前記トリガーされたアプリケーションに関連した第１モード又は前記トリガーされていないアプリケーションに関連した第２モードを含み、前記記述は要求によって送信される、送信モジュールと、前記インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及び前記インタラクティブサービスのそれぞれのタイプを示すサービスタイプ情報を有する記述に対する要求を受信するように構成された受信モジュールと、前記インタラクティブサービスに対する情報を送信することによって前記インタラクティブサービスを提供するように構成された提供モジュールを備える装置が提供される。
好適には、前記インタラクティブサービスに対する情報は、前記インタラクティブサービスによって定義され、前記インタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つである。
好適には、前記インタラクティブサービスに対する情報がトリガーであれば、前記トリガーの少なくとも一つは、前記デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含む。
好適には、前記インタラクティブサービスに対する情報がトリガーであれば、前記装置は、ＴＰＴ内の情報と結合することによって前記トリガーを増加（ａｕｇｍｅｎｔ）させるように構成された増加モジュールをさらに備え、前記ＴＰＴは、前記トリガーされたアプリケーションに対するメタデータを含み、前記送信モジュールはさらに、前記トリガー内で識別されたイベントを示すイベント指示子を有する増加したトリガーを送信する。
好適には、前記インタラクティブサービスに対する情報がバイトであれば、前記インタラクティブサービスは、前記アプリケーションが実行されて前記セカンダリアプリケーションとの通信に参加する準備ができているかを示すｓｔａｔｕｓ状態変数を含み、前記装置はさらに、前記ｓａｔｕｓ状態変数を設定することを含む。
好適には、前記プライマリＡＰＩを用いてインタラクティブサービスを提供する。
好適には、前記ＡＰＩは、バイト及びバイト引数（ａｒｇｕｍｅｎｔ）に対するアドレス及びポートに関する情報を有するアドレス引数を含む。
好適には、前記受信モジュールはさらに、前記送信モジュールが前記メッセージを送信する前に、前記プライマリアプリケーションに関連した前記セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信するように構成される。
本発明の他の形態において、デジタルサービス信号を処理する装置であって、前記デジタルサービス信号に対するアプリケーションを実行するように構成された実行モジュールと、前記実行されたアプリケーションに対するインタラクティブサービスのメッセージ及び記述（ｄｅｓｃｒｉｐｔｉｏｎ）を受信するように構成された受信モジュールと、前記インタラクティブサービスを識別する記述に対する要求を伝送するように構成された伝送モジュールであって、前記記述は、前記インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及び前記インタラクティブサービスのそれぞれのタイプを示すサービスタイプ情報を有する、伝送モジュールと、前記記述を用いて少なくとも一つのインタラクティブサービスをアクセスするように構成されたアクセスモジュールと、前記アクセスされたインタラクティブサービスに対するファイルをダウンロードするように構成されたダウンロードモジュールを備え、前記アクセスモジュールは、前記少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入し、前記通知を受信し、前記受信された通知を用いて前記少なくとも一つのインタラクティブサービスに対する情報を受信する、装置が提供される。
好適には、前記少なくとも一つのインタラクティブサービスに対する情報は、前記インタラクティブサービスによって定義され、前記少なくとも一つのインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つである。
好適には、前記探索されたインタラクティブサービスに対する情報がトリガーであれば、前記トリガーの少なくとも一つは、前記デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含む。
好適には、前記アクセスされたインタラクティブサービスに対する情報がバイトであれば、前記アクセスモジュールはさらに、前記受信された通知を用いて前記インタラクティブサービスが始まる準備ができているかを決定し、前記受信された通知を用いてバイトを送信するための接続に対する要求を送信する。
好適には、前記伝送モジュールは、前記受信モジュールが前記メッセージを受信する前に、前記実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を伝送するように構成される。
上述した一般的な説明と次の本発明の詳細な説明は、例示的で且つ説明的なものに過ぎず、請求された本発明の追加説明を提供するためのものである。
本発明によれば、既存の放送システムを用いて放送コンテンツと関連した付加情報を提供することができる。
本発明によれば、放送コンテンツと関連した付加情報が表示されなければならない時期を検出し、適切な時期に付加情報を使用者に提供することができる。
本発明によれば、第２スクリーンデバイスに、放送コンテンツと関連した付加情報を提供することができる。
添付の図面は次の通りである。
一般的な放送ストリームの一実施例を示す図である。 予め生成された（Ｐｒｅ−ｐｒｏｄｕｃｅｄ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。 ライブ（Ｌｉｖｅ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。 トリガーシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの一実施例を示す図である。 ＴＤＯパラメータテーブルの一実施例を示す図である。 ‘Ｆｒｅｑｕｅｎｃｙ ｏｆ Ｕｓｅ’属性値の意味の一実施例を示す図である。 ‘ｄｅｓｔｉｎａｔｉｏｎ’属性値の意味の一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 活性化メッセージテーブル構造の一実施例を示す図である。 ＵＲＬリスト構造の一実施例を示す図である。 ＴＰＴを含むプライベートセクション（ｐｒｉｖａｔｅ ｓｅｃｔｉｏｎ）の２進フォーマットの一実施例を示す図である。 ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。 ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。 ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。 ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。 ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。 ＷＭ技法のためのアーキテクチャの一実施例を示す図である。 ＦＰ技法のアーキテクチャの一実施例を示す図である。 要求／応答ＡＣＲ場合における静的活性化の一実施例を示す図である。 要求／応答ＡＣＲ場合における静的活性化の一実施例を示す図である。 要求／応答ＡＣＲ場合における動的活性化の一実施例を示す図である。 要求／応答ＡＣＲ場合における動的活性化の一実施例を示す図である。 ＡＣＲサーバー活性化のためのアーキテクチャの一実施例を示す図である。 ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。 ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。 ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。 ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。 場合（ｃ）に対する活性化トリガーの一実施例を示す図である。 場合（ｃ）に対する活性化トリガーの一実施例を示す図である。 最後に伝達される動的活性化トリガーの一実施例を示す図である。 最後に伝達される動的活性化トリガーの一実施例を示す図である。 要求／応答の場合においてＡＣＲクライアントと他のサーバー間の順序図である。 イベント主導型ＡＣＲ場合におけるＡＣＲクライアントと他のサーバー間の順序図である。 ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスのアクションリストの一実施例である。 ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例である。 Ｔｒｉｇｇｅｒ ｉｎ ＤＴＶＣＣ Ｓｅｒｖｉｃｅ Ｎｕｍｂｅｒ６の一実施例である。 第２スクリーンシナリオ用システムアーキテクチャの一実施例である。 ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例である。 ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例である。 中央集中型実行モデル（Ｃｅｎｔｅｒａｌｉｚｅｄ Ｅｘｅｃｕｔｉｏｎ ｍｏｄｅｌ）の動作概念図の一実施例である。 中央集中型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。 分散型実行モデル（Ｄｉｓｔｒｉｂｕｔｅｄ Ｅｘｅｃｕｔｉｏｎ ｍｏｄｅｌ）の動作概念図の一実施例である。 分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。 分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。 第２スクリーンサービスアプリケーションのソフトウェア層の一実施例である。 第２スクリーンサービスアプリケーションのソフトウェア層の一実施例である。 第２スクリーンアプリケーションライフサイクル管理による送信順序と送信データの違いを示すテーブルの一実施例である。 受信機が第２スクリーンデバイスにＵＩ情報を知らせる方法の一実施例である。 受信機が第２スクリーンデバイスにＵＩ情報を知らせる方法の一実施例である。 受信機が第２スクリーンデバイスにＴＤＯ及びイベント情報を知らせる方法の一実施例である。 第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーション接近方法の一実施例である。 第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーション接近方法の一実施例である。 ＲｅｍｏｔｅＵＩサーバーサービスのための放送シグナリングの一実施例である。 ＲｅｍｏｔｅＵＩサーバーサービスのための放送シグナリングの他の実施例である。 第２スクリーンサービスのための装置ディスカバリ及び装置能力交換の一実施例である。 ＵＰｎＰフォーラムのＤｅｖｉｃｅＰｒｏｆｉｌｅ ＸＭＬスキマーの一実施例である。 第２スクリーンデバイスのデバイスプロファイルの一実施例である。 第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの説明の一実施例である。 第２スクリーンデバイスでＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｔｅＵＩＬｉｓｔｉｎｇが実行される間のＵＩＬｉｓｔｉｎｇの一実施例である。 ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。 ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。 ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。 ＰｒｏｃｅｓｓＩｎｐｕｔアクションで第２スクリーンデバイスに伝達になる“ＥｖｅｎｔＩｎｆｏ”情報の一実施例である。 受信機及び第２スクリーンデバイス間の構成の一実施例である。 サービスのサービスタイプ及びサービスＩＤの一実施例である。 トリガー伝達サービスの動作概念図の一実施例である。 拡張された活性化トリガー（ｅｘｐａｎｄｅｄ ａｃｔｉｖａｔｉｏｎ ｔｒｉｇｇｅｒ）生成過程の一実施例である。 増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。 ＵＲＩ＿ｄａｔａ（）のシンタックスの一実施例である。 ＵＲＩ＿ｔｙｐｅの意味の一実施例である。 増加していないトリガーに対するＸＭＬスキマー記述の一実施例である。 増加した活性化トリガーのフォーマットの一実施例である。 増加した活性化トリガーのフォーマットの一実施例である。 増加した活性化トリガーのフォーマットの一実施例である。 増加した活性化トリガーのフォーマットの一実施例である。 ＨＴＴＰロングポーリング基盤アプローチ（ｌｏｎｇ ｐｏｌｌｉｎｇ ｂａｓｅｄ ａｐｐｒｏａｃｈ）によるトリガーサービス状態変数の一実施例である。 ＨＴＴＰロングポーリング基盤アプローチによるトリガーサービスアクションの一実施例である。 ＨＴＴＰロングポーリング基盤アプローチによるＧｅｔＴｒｉｇＳｅｒｖｅｒＵＲＬアクションの引数（Ａｒｇｕｍｅｎｔｓ）の一実施例である。 トリガーサービス状態変数の実施例を示す図である。 トリガーサービスアクションの実施例を示す図である。 ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の実施例を示す図である。 ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の実施例を示す図である。 ＵＰｎＰイベンティングメカニズム基盤アプローチの実施例である。 トリガーサービス状態変数の実施例を示す図である。 トリガーサービスアクションの実施例を示す図である。 トリガー伝達サービスを通じてトリガーを取得する時、第２スクリーン上の動作の実施例を示す図である。 トリガー伝達サービスの動作概念を示す図である。 第１アプローチによる双方向（インタラクティブ）通信サービス状態変数の一実施例である。 第１アプローチによるＣｌｉｅｎｔＬｉｓｔ状態変数のＸＭＬスキマーテーブルの一実施例である。 第１アプローチによるトリガーサービスアクションの一実施例である。 第１アプローチによるＳｉｇｎＵｐアクションの引数の一実施例である。 第１アプローチによるＳｉｇｎＯｆｆアクションの引数の一実施例である。 第２アプローチによる双方向通信サービス状態変数の一実施例である。 第２アプローチによるｏｎＢｙｔｅｓＲｅｃｅｉｖｅｄ関数の一実施例である。 第２アプローチによるｓｅｔＳｔａｔｕｓＹｅｓ（）の一実施例である。 第２アプローチによるｓｅｔＳｔａｔｕｓＮｏ（）の一実施例である。 第２アプローチによるｓｅｔＳｔａｔｕｓ（）の一実施例である。 第２アプローチによるｓｅｎｄＢｙｔｅｓ（）の一実施例である。 ＡｐｐＵＲＬサービス状態変数の一実施例である。 ＡｐｐＵＲＬサービスアクションの一実施例である。 ＧｅｔＡｐｐＵＲＬアクションの引数の一実施例である。 プロキシＨＴＴＰサーバーサービス（Ｐｒｏｘｙ ＨＴＴＰ Ｓｅｒｖｅｒ ｓｅｒｖｉｃｅ）の動作概念図の一実施例である。 プロキシサーバーサービス状態変数（Ｐｒｏｘｙ Ｓｅｒｖｅｒ Ｓｅｒｖｉｃｅ Ｓｔａｔｅ Ｖａｒｉａｂｌｅ）の一実施例である。 プロキシサーバーサービスアクション（Ｐｒｏｘｙ Ｓｅｒｖｅｒ Ｓｅｒｖｉｃｅ Ａｃｔｉｏｎ）の一実施例である。 ＧｅｔＰｒｏｘｙＵＲＬアクションの引数の一実施例である。 ＲｅｑｕｅｓｔＦｉｌｅｓ（）の一実施例である。 第２スクリーンデバイスアーキテクチャの一実施例である。 受信機の簡略化された構造図の一実施例である。 第２スクリーンデバイスの構造図の一実施例である。 第２スクリーンデバイスシナリオの一実施例である。 第１デバイスでインタラクティブサービスを処理する方法の一実施例である。 第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法の一実施例である。 第１デバイスとしてインタラクティブサービスを処理する装置の一実施例である。 第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置の一実施例である。
発明のより容易な理解を助け、発明の実施例を示す添付の図面が、下記の記載と共に本発明の原理を説明するために提供される。
本明細書で使われる用語としては、本発明においての機能を考慮したうえ、できるだけ現在広く使われている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分においてその意味を記載するものとする。したがって、本明細書で使われる用語は、単純な用語の名称ではなく、その用語が持つ実質的な意味と本明細書の全般にわたる内容に基づいて解釈されなければならいということは明らかである。
本明細書において、メディア時間は、オーディオ／ビデオ又はオーディオコンテンツアイテムの再生（ｐｌａｙｏｕｔ）においていずれかの地点を参照するパラメータを表す。ＡＣＲは、自動コンテンツ認識（Ａｕｔｏｍａｔｉｃ Ｃｏｎｔｅｎｔ Ｒｅｃｏｇｎｉｔｉｏｎ）を表す。ＡＭＴは、活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ）を表す。ＡＰＩは、アプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を表す。ＤＡＥは、宣言的応用環境（Ｄｅｃｌａｒａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）を表す。ＤＯは、宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＦＬＵＴＥは、単方向送信を通したファイル伝達（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を表す。ＧＰＳは、位置確認システム（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を表す。ＨＴＴＰは、ハイパーテキスト送信プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を表す。ＩＰは、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を表す。ＩＰＴＶは、インターネットプロトコルテレビ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）を表す。ｉＴＶは、双方向テレビ（Ｉｎｔｅｒａｃｔｉｖｅ Ｔｅｌｅｖｉｓｉｏｎ）を表す。ＭＩＭＥは、インターネットメディアタイプ（Ｉｎｔｅｒｎｅｔ Ｍｅｄｉａ Ｔｙｐｅ）を表す。ＮＤＯは、ＮＲＴ宣言的客体（ＮＲＴ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＮＲＴは、非実時間（Ｎｏｎ−Ｒｅａｌ Ｔｉｍｅ）を表す。ＳＭＴは、サービスマップテーブル（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ）を表す。ＳＳＣは、サービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）を表す。ＴＤＯは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＴＰＴは、ＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒｓ Ｔａｂｌｅ）を表す。ＵＤＯは、非結合宣言的客体（Ｕｎｂｏｕｎｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＵＰｎＰは、ユーザープラグアンドプレイ（Ｕｓｅｒ Ｐｌｕｇａｎｄ Ｐｌａｙ）を表す。ＵＲＩは、統合リソース識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を表す。ＵＲＬは、リソース位置表示子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を表す。ＸＭＬは、拡張性生成言語（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を表す。ＴＦＴは、テキストフラグメントテーブル（Ｔｅｘｔ Ｆｒａｇｍｅｎｔ Ｔａｂｌｅ）を表す。詳細な内容は後述する。
この明細書で、ＤＯ、ＴＤＯ、ＮＤＯ、ＵＤＯは次のような意味を有することができる。
ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、双方向アプリケーション（例えば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、ＣＳＳ、ＸＭＬ及びマルチメディアファイル）を構成するコレクション（ｃｏｌｌｅｃｔｉｏｎ）であってもよい。
トリガーされた双方向付加データサービスによって開始された宣言的客体又はトリガーによって開始されたＤＯによって実行されたＤＯなどを指定するために“トリガーされた宣言的客体（ＴＤＯ）”を使用する。
トリガーされた双方向データサービスではなくＮＲＴサービスの一部として実行された宣言的客体を表すために、“ＮＲＴ宣言的客体”（ＮＤＯ）という用語を使用する。
パッケージ型アップ（Ｐａｃｋａｇｅｄ Ａｐｐ）のようにサービスに結合されない宣言的客体、リンクによって実行されたＤＯ、又はそのようなＤＯによって実行されたＤＯなどを表すために“非結合宣言的客体（ＵＤＯ）”という用語を使用する。
“リンク”は、現在のＴＶプログラム又はＮＲＴサービスに関連するオンライン情報又は機能を提供するウェブサイトを示す放送局提供ＵＲＬである。
“パッケージ型アップ”は、放送局が視聴者に提供しようとする情報又は機能を提供し、視聴者がダウンロードして設置できる一つのファイルとしてまとめられた放送局提供宣言的客体（ＤＯ）である。
その詳細は後述する。
この明細書で、時間ベースメッセージ（ｔｉｍｅ ｂａｓｅ ｍｅｓｓａｇｅ）は、時間ベーストリガー及びその等価物を含む。したがって、“時間ベースメッセージ”と“時間ベーストリガー”と同じ意味で使われてもよい。
この明細書で、活性化メッセージは、活性化トリガー及び／又はＡＭＴ内の活性化エレメントのような、活性化を引き起こす全ての情報伝達を含む。
図１は、一般的な放送ストリームの一実施例を示す図である。
一般的な放送ストリームはＴＶプログラムのシーケンスで構成されている。各ＴＶプログラムは、基本となるショー（ｓｈｏｗ）で構成され、ショーは一般的に広告及び／又は他の介在物（ｉｎｔｅｒｓｔｉｔｉａｌ ｍａｔｅｒｉａｌ）によって分離されたブロックに分けられる。
同図では、放送ストリームに、ショーＡ（Ｓｈｏｗ Ａ）セグメント、広告１（Ａｄ１）、広告２（Ａｄ２）、ショーＢ（Ｓｈｏｗ Ｂ）セグメントなどが順次に含まれている。各ショーをなすセグメントをショー材料、広告を介在物と呼ぶことができる。
各ショー又は介在物は、それと関連している双方向付加データサービスを有しても有さなくてもよい。
本明細書では、統合ユニットとして放送局によって扱われる双方向付加サービスの一部を表すために“双方向サービスセグメント”、又は単純に“セグメント”という用語を使用する。双方向サービスセグメントは一般的に単一ショー又は１個の介在物と関連するが、必ずしもそうでない。
このような双方向付加データサービスを実行するための２つのモデルがあり得る。直接実行モデルとトリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＴＤＯ）モデルがそれである。
直接実行モデルでは、仮想チャネルが選択されると直ちに宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＤＯ）は自動で開始され得る。宣言的客体は、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのように、オーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を得るために、インターネットを介してバックエンド（ｂａｃｋｅｎｄ）サーバーと通信することができる。
ＴＤＯモデルでは、ＴＤＯの開始、ＴＯＤの終了、又はＴＤＯによる一部作業の誘発のようにＴＤＯイベントを開始するために信号を放送ストリームで伝達したり又はインターネットを介して伝達することができる。これらのイベントは、特定時間に開始され、一般的にオーディオ−ビデオプログラムと同期化される。ＴＤＯが開始されると、プログラムされた双方向特徴を提供することができる。
ＴＤＯモデルの基本概念は、ＴＤＯを構成するファイル及びある動作を取るためにＴＤＯによって用いられるデータファイルはいずれも、その大きさによって受信機に伝達されるには一定量の時間がかかるということである。双方向エレメントに対するユーザ経験は、コンテンツの放送前に作成（ａｕｔｈｏｒ）されてもよいが、ある振舞いは、プログラム内のイベント、例えば、商業広告セグメントの発生と同時に起きるように注意して時間を決めなければならない。
ＴＤＯモデルでは、宣言的客体、関連しているデータ、スクリプト、テキスト及びグラフィックの伝達を、双方向イベントの再生に対する特定タイミングのシグナリングと区別する。
双方向イベントのタイミングを設定するエレメントはトリガー（Ｔｒｉｇｇｅｒ）である。
一つのセグメント内で用いられるＴＤＯとトリガーによって開始される関連ＴＤＯイベントに関する情報は、“ＴＤＯパラメータテーブル”（ＴＰＴ）と呼ばれるデータ構造によって提供される。
図２は、既に生成されたコンテンツの場合に、トリガータイミングの一実施例を示す図である。
トリガーは、シグナリングを識別し、双方向イベントの再生タイミングを設定する機能を担うシグナリングエレメントである。
トリガーには、双方向サービスに関連するセグメントに対するメディア時間を示す役割を担う時間ベーストリガーと、双方向サービスに関連するアプリケーションのイベント発生時間を示す役割を担う活性化トリガーの２種類があり得る。
トリガーは、双方向サービスの支援のために、タイミングに関連する様々な機能を果たすことができる。トリガーはその機能によって多機能的であってもよく、特定トリガーインスタンス（ｉｎｓｔａｎｃｅ）は、次の機能のうち一つ以上を行うことができる。
１．ＴＰＴ（放出ストリーム内のＦＬＵＴＥセッション、インターネットサーバー、又はこれら両者を介して接近可能なＴＰＴ）の位置をシグナリングする。
２．次のプログラムセグメントに対する双方向コンテンツがプリロード（ｐｒｅ−ｌｏａｄ）されることを示す。
３．関連しているオーディオ／ビデオコンテンツ又はオーディオコンテンツの現在メディア時間を示す。
４．ＴＰＴ内特定双方向イベントを参照し、当該イベントが現在又は特定の未来のメディア時間に実行されなければならないということを知らせる。
５．需要が最大となることを避けるために、インターネットサーバーに対する接続が特定の時間区間上でランダムに分散されることを示す。
図２は、２つのプログラミングセグメントと関連して伝達されるトリガーを示す。この例では、２つのセグメントとも“予め生成”されるが、これは、コンテンツがライブコンテンツではなく、双方向エレメントはポストプロダクション（ｐｏｓｔ−ｐｒｏｄｕｃｔｉｏｎ）で追加されたことを意味する。
図示のように、プログラミングセグメント１の発生前の短い時間に“プリロード（ｐｒｅ−ｌｏａｄ）”トリガーが伝達されて、受信機と関連しているＴＰＴ及びー方向コンテンツを取得できる機会を受信機に許容することができる。万一、プリロードトリガーが送信されないと、受信機は、コンテンツを取得するために該当のセグメント内で会う最初のトリガーを用いると考えることができる。
図示のように、トリガーはＳｅｇｍｅｎｔ１を通して送信されて、当該セグメントに関する現在メディア時間（図では“ｍ”と表記）を示すことができる。当該チャネルに会うトリガーが双方向コンテンツを同期化して取得できるようにするためにメディア時間トリガーの周期的な伝達が必要なことがある。
Ｓｅｇｍｅｎｔ２の開始直前に当該セグメントに対するプリロードトリガーが送信される。
予め生成されたコンテンツ（非ライブ（ｎｏｎ−ｌｉｖｅ）コンテンツ）の場合、受信機が最初のトリガーを処理した後に取得できるＴＰＴは、当該セグメントに対する双方向経験の全てのエレメントのタイミングを定義することができる。当該受信機とＴＤＯが双方向エレメントを再生するようにするために必要なものは、メディアタイミングの知識であってもよい。このＴＰＴはメディア時間に関して双方向イベントを記述することができる。
図３は、ライブコンテンツの場合に、トリガータイミングの一実施例を示す図である。
ライブコンテンツの場合にも、ＴＰＴは、互いに異なる双方向イベントに関連するデータ及び情報を含むが、放送中にプログラム内の動作が展開するまでは、そのようなイベントの再生タイミングは知られないことがある。このようなライブの場合、トリガーの“イベント−タイミング（ｅｖｅｎｔ−ｔｉｍｉｎｇ）”機能が活用される。このモードでトリガーは、特定の双方向イベントが新しい特定メディア時間値に再設定（ｒｅ−ｔｉｍｅｄ）されることを知らせることができる。又は、トリガーは、あるイベントが直ちに実行されることを示すこともできる。
図３で、Ｓｅｇｍｅｎｔ ３に対する各トリガーの機能は次の通りである。
１番トリガーは、プリロードトリガーであって、セグメント３に関するファイルを得ることができるディレクトリを参照する。
２番トリガーは、メディア時間トリガーであって、Ｓｅｇｍｅｎｔ ３に対する再生タイミングを示すために用いられる。
３番トリガーは、イベントリタイミング（ｒｅ−ｔｉｍｉｎｇ）トリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝２のイベントがメディア時間２４０に発生するように時間が再設定されることを示す。ハッチングされた領域は、３番トリガーが受信機に伝達され得る２４０以前の時間区間を示す。
４番トリガーは、メディア時間トリガーである。
５番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝５のイベントがメディア時間４４４に発生するように時間が再設定されることを示す。
６番、７番トリガーは、メディア時間トリガーである。
８番トリガーは、イベントトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝１２のイベントが直ちに実行されることを示す。
９番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝８９のイベントがメディア時間９００に発生するように時間が再設定されることを示す。
以下、ＴＤＯのライフサイクル（ｌｉｆｅ ｃｙｃｌｅ）と状態、及び状態変化イベントについて説明する。
ＴＤＯは、解除（Ｒｅｌｅａｓｅｄ）、準備（Ｒｅａｄｙ）、活動（Ａｃｔｉｖｅ）、及び中止（Ｓｕｓｐｅｎｄｅｄ）の異なった４つの状態で存在することができる。多数の異なる要素（トリガー、ユーザ動作、変更されるチャネルなど）が一つの状態から他の状態への変動を引き起こしうる。
ＴＤＯは、次の４つの状態を有することができる。４つの状態は、準備（Ｒｅａｄｙ）、活動（Ａｃｔｉｖｅ）、中止（Ｓｕｓｐｅｎｄｅｄ）及び解除（Ｒｅｌｅａｓｅｄ）である。準備状態は、ＴＤＯがダウンロードされて実行準備となっているが、まだ実行されてはいないことを意味する。活動状態は、ＴＤＯが実行中であることを意味する。中止状態は、その状態の保存と併せて、ＴＤＯの実行が一時的に中止することを意味する。解除状態は、ＴＤＯが準備、活動又は中止状態でないことを意味する。
ＴＤＯの状態変化を起こし得るイベントの例には次のものがある。
１．“ｐｒｅｐａｒｅ”をトリガーする − 装置は、ＴＤＯが実行（リソース割当、主メモリへのローディングなど）をするように準備されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。
２．“ｅｘｅｃｕｔｅ”をトリガーする − 装置は、ＴＤＯが活性化されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。
３．“ｓｕｓｐｅｎｄ”をトリガーする − 装置は、ＴＤＯの中止を示すトリガーを（現在選択された１次仮想チャネルで）受信する。
４．“ｋｉｌｌ”をトリガーする − 装置は、ＴＤＯの終了を示すトリガーを（現在選択された１次仮想チャネルで）受信する。
図４は、トリガーシンタックスの一実施例を示す図である。
活性化メッセージと時間ベースメッセージは両方とも、ある送信環境で次のような一般的な“トリガー”フォーマットを有することができる。
ここで、シンタックス上の定義は、アルタネイティブ（ａｌｔｅｒｎａｔｉｖｅ）を指定するために垂直バーシンボル”｜”が使われる場合以外は、ＡＢＮＦ（Ａｕｇｍｅｎｔｅｄ Ｂａｃｋｕｓ−Ｎａｕｒ Ｆｏｒｍ）文法を用いて記述する。ルール（ｒｕｌｅ）は等号”＝”によって定義と分離され、１行を超えてルール定義を続けるときは字下げ（ｉｎｄｅｎｔａｔｉｏｎ）を用い、リテラル（ｌｉｔｅｒａｌ）は””で引用し、エレメントのグループ化には括弧”（”と”）”を用い、選択的なエレメントは”［”と”］”との間に入れる。そして、エレメントの前に＜ｎ＞*がつくと、その次のエレメントのｎ回以上の反復を指定でき、ｎは基本値として０に設定される。そして、エレメントの前に＜ｎ＞*＜ｍ＞がつくと、その次にくるエレメントのｎ回以上ｍ回以下の反復を指定することができる。
このようなトリガーシンタックスは、＜ｓｃｈｅｍｅ＞と“：／／”部分を除いて、付加的な制限事項と共にＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）：ジェネリックシンタックス（Ｇｅｎｅｒｉｃ Ｓｙｎｔａｘ）に基づく。
トリガーは、ｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓで構成することができる。ｔｅｒｍｓは、省略可能な構成である。ｔｅｒｍｓが存在するとｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓとを‘？’で連結することができる。
ｌｏｃａｔｏｒ＿ｐａｒｔは、ｈｏｓｔｎａｍｅ部分とｐａｔｈ＿ｓｅｇｍｅｎｔｓ部分とで構成することができ、その間は‘／’で連結することができる。
ｈｏｓｔｎａｍｅは、ｄｏｍａｉｎｌａｂｅｌとｔｏｐｌａｂｅｌとで構成することができ、ｄｏｍａｉｎｌａｂｅｌはその次に‘．’と共に０回以上反復され得る。すなわち、ｈｏｓｔｎａｍｅは、反復されたｄｏｍａｉｎｌａｂｅｌがｔｏｐｌａｂｅｌと連結した形態であってもよく、又は、ｔｏｐｌａｂｅｌのみで構成された形態であってもよい。
ｄｏｍａｉｎｌａｂｅｌは、一つのａｌｐｈａｎｕｍからなる形態であってもよい。又は、２つのａｌｐｈａｎｕｍの間にａｌｐｈａｎｕｍ又は‘−’が０回以上反復されたものが挿入された形態であってもよい。
ここで、ａｌｐｈａｎｕｍは、ａｌｐｈａ又はｄｉｇｉｔを意味することができる。
ここで、ａｌｐｈａは、ｌｏｗａｌｐｈａ又はｕｐａｌｐｈａのいずれかであってもよい。
ここで、ｌｏｗａｌｐｈａは、ａ、ｂ、ｃ、ｄ、ｅ、ｆ、ｇ、ｈ、ｉ、ｊ、ｋ、ｌ、ｍ、ｎ、ｏ、ｐ、ｑ、ｒ、ｓ、ｔ、ｕ、ｖ、ｗ、ｘ、ｙ、ｚのいずれか一つであってもよい。
ここで、ｕｐａｌｐｈａは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌ、Ｍ、Ｎ、Ｏ、Ｐ、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖ、Ｗ、Ｘ、Ｙ、Ｚのいずれか一つであってもよい。
ここで、ｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９のいずれか一つであってもよい。
ｔｏｐｌａｂｅｌは、一つのａｌｐｈａからなる形態であってもよい。又は、ａｌｐｈａとａｌｋｐｈａｎｕｍとの間にａｌｐｈａｎｕｍ又は‘−’が０回以上反復されたものが挿入された形態であってもよい。
ｐａｔｈ＿ｓｅｇｍｅｎｔｓは、セグメントが一つがあり、その次にセグメントが０回以上反復されたものが続く形態であってもよい。このとき、セグメントの間は‘／’で連結することができる。
ここで、セグメントは、ａｌｐｈａｎｕｍが１回以上反復された形態であってもよい。
ｔｅｒｍｓは、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅのいずれかからなる形態であってもよい。続いてｓｐｒｅａｄ又はｏｔｈｅｒｓが来てもよい。ｓｐｒｅａｄとｏｔｈｅｒｓは省略可能な構成であってもよい。ｓｐｒｅａｄとｏｔｈｅｒｓが存在すると、これは‘＆’を前に置いている形態であって、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅの次に位置することができる。
ここで、ｓｐｒｅａｄは、‘ｓ＝’の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。
ｅｖｅｎｔ＿ｔｉｍｅは、‘ｅ＝’の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。又は、その後、‘＆ｔ＝’の次にｈｅｘｄｉｇｉｔが１回以上７回以下反復されたものが続く形態であってもよい。‘＆ｔ＝’とその次の部分は省略可能な構成であってもよい。
ここで、ｈｅｘｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９、ａ、ｂ、ｃ、ｄ、ｅ、ｆのいずれか一つであってもよい。
ｍｅｄｉａ＿ｔｉｍｅは、‘ｍ＝’の次にｈｅｘｄｉｇｉｔが１回以上７回未満反復されたものが続く形態であってもよい。
ｏｔｈｅｒｓは、一つのｏｔｈｅｒからなる形態であってもよい。又は、その次に‘＆’とｏｔｈｅｒが追加された形態であってもよい。
ここで、ｏｔｈｅｒは、ｒｅｓｖ＿ｃｍｄとａｌｐｈａｎｕｍが１回以上反復されたものとが‘＝’によって連結された形態であってもよい。
ここで、ｒｅｓｖ＿ｃｍｄは、‘ｃ’、‘ｅ’、‘Ｅ’、‘ｍ’、‘Ｍ’、‘ｓ’、‘Ｓ’、‘ｔ’、‘Ｔ’を除くａｌｐｈａｎｕｍであってもよい。
トリガーの長さは５２バイトを超えなくてもよい。そして、トリガーのｈｏｓｔｎａｍｅ部分は、登録されたインターネットドメイン名であってもよい。
トリガーは、３つの部分からなることがわかる。
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞［？＜ｐａｒａｍｅｔｅｒｓ＞］
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたドメイン名であり、＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、ドメイン名がＵＲＩにおいて登場するようになる経路であってもよい。
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたインターネットドメイン名を参照することができる。＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、識別されたドメイン名に対する権限を持つエンティティ（ｅｎｔｉｔｙ）の制御及び管理下でディレクトリ経路を識別する任意の文字列であってもよい。
ＴＤＯモデルで、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、関連しているコンテンツに双方向性を追加するために受信機によって処理され得るＴＰＴを固有に識別することができる。
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、現在セグメントに対するＴＰＴが得られるインターネット位置のＵＲＬであってもよい。
すなわち、トリガーは、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞を用いてＴＰＴを識別することができ、これによってトリガーの適用されるＴＰＴがわかる。当該ｔｒｉｇｇｅｒがＴＰＴに適用されてどのような役割を果たすかは、＜ｐａｒａｍｅｔｅｒｓ＞部分による。
以下、＜ｐａｒａｍｅｔｅｒｓ＞部分について説明する。
＜ｐａｒａｍｅｔｅｒｓ＞は、“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、又は“ｓｐｒｅａｄ”の一つ以上で構成することができる。
次は、図４に示したシンタックスにおいて“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、“ｓｐｒｅａｄ”に関する部分である。
event_time =”e=”1*digit[”&t=”1*7hexdigit]
media_time =”m=”1*7hexdigit
spread =”s=”1*digit
“ｅｖｅｎｔ＿ｔｉｍｅ”項は、ターゲットとされたイベント（“ｅ＝”項）と当該イベントが活性化されるべき時間（“ｔ＝”項）を識別するために活性化トリガーにおいて用いることができる。“ｔ＝”項がないと、これは、トリガーが到達する時間にイベントが活性化されなければならないことを意味する。
すなわち、双方向イベントＩＤ項である“ｅ＝”は、当該イベントのターゲットであるＴＤＯの関連しているＴＰＴ内のａｐｐＩＤ、当該特定イベントのｅｖｅｎｔｉｄｅ、及びこのイベント活性化のために用いられるデータエレメントのｄａｔａＩＤを参照することができる。
選択的なタイミング値項である“ｔ＝”は、指定されたイベントのための新しいメディアタイミングを示すことができる。“ｔ＝”部分が存在しないと、これは、指定されたイベントのためのタイミングがトリガーの到達時間であることを意味することができる。
“ｍｅｄｉａ＿ｔｉｍｅ”項（“ｍ＝”項）は、時間ベーストリガーによって示される時間ベースに対する現在時間を識別するために時間ベーストリガーにおいて用いることができる。そして、現在表れているコンテンツを識別できるコンテンツ識別子情報（“ｃ＝”項）がｍｅｄｉａ＿ｔｉｍｅにさらに含まれてもよい。“ｃ＝”項については、直接実行モデルに関する説明で後述する。
すなわち、“ｍ＝”は、その次に１６進数を表示する１乃至８文字長の文字列が続くメディアタイムスタンプ（ｔｉｍｅｓｔａｍｐ）項であって、現在のメディア時間を示すことができる。
“ｓｐｒｅａｄ”項は、サーバー上で作業負荷が分散するように、時間ベーストリガーに応答してなされる動作（サーバーからのＴＰＴの検索のような動作）又は活性化トリガーに応答してなされる動作（ＴＤＯをサーバーに接続させるような動作）がランダムな時間の間に遅延されなければならないということを示すために用いることができる。
“ｓ＝”項は、全ての受信機がトリガーで識別されたインターネットサーバーに接続を試みるべき秒単位の時間数を示すことができる。それぞれの個別受信機が、指定された区間内でランダムな時間を導出して、該当する量だけ接続要求を遅延させることによって、受信機でトリガーが初めて現れる時に発生しう需要の最大値を時間上で分散させると考えることができる。
＜ｍｅｄｉａ ｔｉｍｅ＞パラメータを含むトリガーは、イベント時間に対する時間ベースを設定するために用いられることから、時間ベーストリガーと呼ぶこともできる。
＜ｅｖｅｎｔ ｔｉｍｅ＞パラメータを含むトリガーは、イベントに対する活性化時間を設定することから、活性化トリガーと呼ぶこともできる。
図５及び図６は、ＴＤＯパラメータテーブルの一実施例を示す図である。
ＴＤＯパラメータテーブル（ＴＰＴ）は、一つのセグメントのＴＤＯ及びこれらのターゲットであるイベントに関するメタデータを含む。
以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は設計者の意図によって追加又は変更されてもよい。
ＴＰＴ構造内のフィールドの具体的なセマンティックス（ｓｅｍａｎｔｉｃｓ）は次の通りである。
ＴＤＯパラメータテーブル（ＴＰＴ）は、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｉｄ、＠ｔｐｔＶｅｒｓｉｏｎ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｕｐｄａｔｉｎｇＴｉｍｅ、＠ｓｅｒｖｉｃｅＩＤ、＠ｂａｓｅＵＲＬ属性、Ｃａｐａｂｉｌｉｔｉｅｓ、ライブトリガー（ＬｉｖｅＴｒｉｇｇｅｒ）、及び／又はＴＤＯエレメントを含むことができる。
ＴＰＴは、当該ＴＰＴのルートエレメントである。一つのＴＰＴエレメントは、一つのプログラミングセグメントの（時間上での）全体又は一部分を記述する。
４ビット属性であってもよい＠ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、テーブル定義の主バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機はそれらが支援しない主バージョン値を示すＴＰＴのインスタンスを捨てると考えることができる。
４ビット属性であってもよい＠ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎが存在する場合、テーブル定義の副バージョン番号を示すことができる。存在しない場合、その値は０にデフォルトすることができる。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン番号値を示すＴＰＴのインスタンスを捨てないと予想される。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想される。
ＵＲＩである＠ｉｄは、このＴＰＴエレメントに関連している双方向プログラミングセグメントを固有に識別することができる。＠ｉｄは、セグメントの識別子の役割を持つ。したがって、受信機がＴＰＴをパーシングした後、＠ｉｄ情報を用いて、一つのセグメントに関連しているトリガー、ＡＭＴなどを該セグメントを識別するための＠ｉｄを有するＴＰＴとマッチングさせることができる。したがって、該トリガーとＡＭＴが適用されるセグメントを探すことが可能になる。ＡＭＴに関する詳細な内容は後述する。
８ビット整数であってもよい＠ｔｐｔＶｅｒｓｉｏｎは、ｉｄ属性によって識別されるＴＰＴエレメントのバージョン番号を示すことができる。ｔｐｔＶｅｒｓｉｏｎは、ＴＰＴが変更される度に増分（ｉｎｃｒｅｍｅｎｔ）されてもよい。
ＴＰＴエレメントの＠ｅｘｐｉｒｅＤａｔｅ属性は、存在する場合、当該ＴＰＴインスタンスに含まれた情報の満了日及び時間を示すことができる。万一、受信機がＴＰＴをキャッシュに保存すると、満了日まで再使用することができる。
１６ビットエレメントであってもよい＠ｕｐｄａｔｉｎｇＴｉｍｅは、存在する場合、ＴＰＴが修正されることを示すことができ、ＴＰＴを再びダウンロードするための秒単位の推薦区間を提供する。
１６ビットエレメントであってもよい＠ｓｅｒｖｉｃｅＩＤは、存在する場合、このＴＰＴインスタンスで記述された双方向サービスと関連しているＮＲＴｓｅｒｖｉｃｅ＿ｉｄを示すことができる。これは、この双方向サービスのためのファイルが放送ストリームで伝達されるとき、受信機がサービスマップテーブルからＦＬＵＴＥパラメータを得るために必要である。
＠ｂａｓｅＵＲＬ属性は、存在する場合、当該ＴＰＴで登場する任意の相対ＵＲＬの前につくと、ベースＵＲＬを提供することができる。この属性は、ファイルの絶対ＵＲＬを提供することができる。
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、存在する場合、当該ＴＰＴと関連している双方向サービスの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機はサービスの表出を試みないと予想される。
ＬｉｖｅＴｒｉｇｇｅｒは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。ＬｉｖｅＴｒｉｇｇｅｒのチャイルド（ｃｈｉｌｄ）エレメントと属性については後述する。
ＴＰＴエレメントのチャイルドエレメントであるＴＤＯは、当該ＴＰＴインスタンスによって記述されたセグメントの間に双方向サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）を示すことができる。ＴＤＯのチャイルドエレメントと属性については後述する。
ＬｉｖｅＴｒｉｇｇｅｒエレメントは、＠ＵＲＬと＠ｐｏｌｌＰｅｒｉｏｄ属性を含むことができる。
上述した通り、ＬｉｖｅＴｒｉｇｇｅｒエレメントは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。
ＬｉｖｅＴｒｉｇｇｅｒエレメントの属性である＠ＵＲＬは、インターネットを介して活性化トリガーを伝達し得るサーバーのＵＲＬを示すことができる。活性化トリガーは、双方向サービスプロバイダの選択によって、ＨＴＴＰショートポーリング（ｓｈｏｒｔ ｐｏｌｌｉｎｇ）、ＨＴＴＰロングポーリング（ｌｏｎｇ ｐｏｌｌｉｎｇ）、又はＨＴＴＰストリーミングを用いてインターネットを介して伝達することができる。
ＬｉｖｅＴｒｉｇｇｅｒエレメントの属性である＠ｐｏｌｌＰｅｒｉｏｄは、存在する場合、活性化トリガーの伝達のためにショートポーリングが使用中であることを示すことができ、ｐｏｌｌＰｅｒｉｏｄ属性値は、受信機がポーリング周期として用いる秒単位の推薦時間を示すことができる。
ＬｉｖｅＴｒｉｇｇｅｒエレメントが存在する場合、受信機は、当該ＴＰＴをパーシングして、活性化トリガーをインターネットを用いて伝達するための情報を得ることができる。＠ＵＲＬ情報から、活性化トリガーを伝達してもらえるサーバーのＵＲＬを得ることができる。＠ｐｏｌｌＰｅｒｉｏｄ情報から、或いは＠ｐｏｌｌＰｅｒｉｏｄ属性が存在しないという情報から、活性化トリガーがインターネットを介して伝達される方式とポーリング周期に関する情報を得ることができる。＠ｐｏｌｌＰｅｒｉｏｄの詳細な説明は後述する。
ＴＤＯエレメントは、＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩＤ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｃｏｏｋｉｅＳｐａｃｅ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性と、ＵＲＬ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｃｏｎｔｅｎｔｉｔｅｍ、及び／又はＥｖｅｎｔエレメントを含むことができる。
上述した通り、ＴＰＴエレメントのチャイルドエレメントであるＴＤＯは、当該ＴＰＴインスタンスによって記述されたセグメントの間に双方向サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）を示すことができる。
１６ビット整数であってもよい＠ａｐｐＩＤは、ＴＰＴ範囲内でアプリケーションを固有に識別することができる。活性化トリガーはａｐｐＩＤを参照してトリガーに対するターゲットアプリケーションを識別することができる。＠ａｐｐＩＤの場合、アプリケーションの識別子である。一つのＴＰＴには複数のアプリケーション（ＴＤＯのようなアプリケーション）があってもよい。したがって、ＴＰＴをパーシングした後に＠ａｐｐＩＤ情報を用いてアプリケーションを識別することができる。あるアプリケーションに適用されるトリガー又はＡＭＴなどを、そのアプリケーションを識別する＠ａｐｐＩＤを有するアプリケーションとマッチングさせることができる。したがって、トリガーとＡＭＴの適用されるアプリケーションを探すことが可能になる。ＡＭＴに関する詳細な内容は後述する。
８ビット整数であってもよい＠ａｐｐＴｙｐｅは、アプリケーションフォーマット類型を示すことができる。基本値は１に設定することができ、この値はＴＤＯを示すことができる。他の値は他のフォーマットを示すことができる。
ＴＤＯエレメントの属性である＠ａｐｐＮａｍｅは、アプリケーションを開始するために視聴者の許可を求めるとき、視聴者に表示し得る人間にとって読み取り可能な名前であってもよい。
ＴＤＯエレメントの属性である＠ｇｌｏｂａｌＩＤは、アプリケーションの全域的に固有な識別子であってもよい。多くの場合に、受信機は近いうちに再び用いるアップをキャッシュに保存する。このことが有用となるには、受信機は当該アップが将来に登場するとそれを認識できなければならない。当該アップが新しいセグメントで再び登場すると、受信機がそれを認識できるようにするためにｇｌｏｂａｌＩＤが必要である。
ＴＤＯエレメントの属性である＠ａｐｐＶｅｒｓｉｏｎは、アプリケーションのバージョン番号であってもよい。ａｐｐＶｅｒｓｉｏｎ値は、当該アプリケーション（ｇｌｏｂａｌＩＤによって識別されたアプリケーション）が変更される度に増分されてもよい。ａｐｐＶｅｒｓｉｏｎ属性は、ｇｌｏｂａｌＩＤ属性が存在しない限り存在することができない。
８ビット整数であってもよい＠ｃｏｏｋｉｅＳｐａｃｅは、各呼出し（ｉｎｖｏｃａｔｉｏｎ）間に持続性データ（ｐｅｒｓｉｓｔｅｎｔ ｄａｔａ）を保存するためにアプリケーションがどれくらい多くの空間を必要とするかを示すことができる。
４ビット整数であってもよい＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅは、受信機にそのアプリケーションコードキャッシュ空間の管理に関する案内を提供するために概略的にどれくらい頻繁に当該アプリケーションが放送で使われるかを示すことができる。‘＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ’の詳細な説明は後述する。
ＴＤＯエレメントの属性である＠ｅｘｐｉｒｅＤａｔｅは、受信機が当該アプリケーション及び関連するリソースを安全に削除できる日付及び時間を示すことができる。
ブールの（Ｂｏｏｌｅａｎ）属性である＠ｔｅｓｔＴＤＯは、その値が“ｔｒｕｅ”として存在する場合、当該アプリケーションがテスト用であり、一般受信機では無視されてもよいことを示すことができる。
＠ａｖａｉｌＩｎｔｅｒｎｅｔ属性に対する“ｔｒｕｅ”値は、当該アプリケーションがインターネットを介したダウンロード用に利用可能であることを示すことができる。その値が“ｆａｌｓｅ”であれば、当該アプリケーションがインターネットを介したダウンロード用に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“ｔｒｕｅ”であってもよい。
＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性に対する“ｔｒｕｅ”値は、当該アプリケーションが放送からの抽出に利用可能であることを示すことができる。“ｆａｌｓｅ”値は、当該アプリケーションが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“ｔｒｕｅ”であってもよい。
ＴＤＯエレメントのチャイルドエレメントであるＵＲＬの各インスタンスは、当該アプリケーションの一部であるファイルを識別することができる。インスタンスＵＲＬエレメントは＠ｅｎｔｒｙ属性を含むことができる。ＵＲＬエレメントの属性である＠ｅｎｔｒｙは“ｔｒｕｅ”値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイント（ｅｎｔｒｙ ｐｏｉｎｔ）、すなわち、当該アプリケーションを開始するために開始され得るファイルであることを示すことができる。“ｆａｌｓｅ”値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイントでないことを示すことができる。当該属性が登場しないとき、基本値は“ｆａｌｓｅ”であってもよい。ＴＤＯエレメントのチャイルドエレメントであるＵＲＬエレメントは、上述した通り、当該アプリケーションをなすファイルを識別する。受信端ではＴＰＴをパーシングして当該ＵＲＬ情報を得た後、それを用いてサーバーに接続して、当該ＵＲＬ情報が示すアプリケーションをダウンロードすることとなる。
ＴＤＯエレメントのチャイルドエレメントであるＣａｐａｂｉｌｉｔｉｅｓは、存在する場合、当該アプリケーションの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機は当該アプリケーションの開始を試みないと予想される。
ＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍは、当該アプリケーションで必要とする一つ以上のデータファイルで構成されたコンテンツコンテンツアイテムを示すことができる。ＣｏｎｔｅｎｔＩｔｅｍエレメントは、このエレメントの属しているＴＤＯエレメントが示すアプリケーションが必要とするデータファイルに関する情報を有する。受信端ではパーシングを行った後、ＣｏｎｔｅｎｔＩｔｅｍエレメントが存在する場合、ＣｏｎｔｅｎｔＩｔｅｍ内のＵＲＬ情報などを用いて、当該アプリケーションが必要とするデータファイルをダウンロードしたりできる。ＣｏｎｔｅｎｔＩｔｅｍのチャイルドエレメントと属性については後述する。
ＴＤＯエレメントのチャイルドエレメントであるＥｖｅｎｔは、当該アプリケーションのためのイベントを示すことができる。Ｅｖｅｎｔエレメントは、このエレメントの属しているアプリケーションのイベントを示す。いかなるイベントを有しているか、該当データにはどのようなものがあるか、該当動作にはどのようなものがあるか等に関する情報を含んでいる。これをパーシングして受信端ではアプリケーションのイベントに関する情報を得ることができる。Ｅｖｅｎｔのチャイルドエレメントと属性については後述する。
受信端でＴＰＴを受けてパーシングすると、ＴＤＯ及び上述したＴＤＯのチャイルドエレメントと属性の情報を得ることができる。
ＴＤＯエレメントのチャイルドエレメントの一つである、ｃｏｎｔｅｎｔＩｔｅｍエレメントは、＠ｕｐｄａｔｅＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔａｔｔｒｉｂｕｔｅ及び／又はＵＲＬエレメントを含むことができる。
ここで、ＵＲＬエレメントは、＠ｅｎｔｒｙ属性を含むことができる。ＣｏｎｔｅｎｔＩｔｅｍエレメントのチャイルドエレメントであるＵＲＬの各インスタンスは、コンテンツアイテムの一部であるファイルを識別することができる。ＵＲＬエレメントは、＠ｅｎｔｒｙ属性を含むことができる。ＵＲＬエレメントの属性である＠ｅｎｔｒｙは、“ｔｒｕｅ”値を有すると、当該ＵＲＬが当該コンテンツアイテムのエントリポイント、すなわち、当該コンテンツアイテムを開始するために開始されうるファイルであることを示すことができる。この属性が“ｆａｌｓｅ”値を有すると、当該ＵＲＬが当該コンテンツアイテムのエントリポイントでないことを示すことができる。この属性が登場しないとき、基本値は“ｆａｌｓｅ”であってもよい。受信機は、パーシング後にＣｏｎｔｅｎｔＩｔｅｍのＵＲＬ情報を用いて当該アプリケーションの要求されるデータファイルをダウンロードすることができる。この過程で、上述した他の属性のような情報を用いることができる。
ＣｏｎｔｅｎｔＩｔｅｍエレメントのブールの属性である＠ｕｐｄａｔｅｓＡｖａｉｌは、当該コンテンツアイテムがたまにアップデートされるか否か、すなわち、コンテンツアイテムが固定ファイル（ｓｔａｔｉｃ ｆｉｌｅ）で構成されるか、それとも、当該アイテムが実時間データフィード（ｆｅｅｄ）であるかを示すことができる。その値が“ｔｒｕｅ”であれば、当該コンテンツアイテムはたまにアップデートされ、その値が“ｆａｌｓｅ”であれば、当該コンテンツアイテムはアップデートされない。この属性が登場しないと、基本値は“ｆａｌｓｅ”であってもよい。
ＣｏｎｔｅｎｔＩｔｅｍエレメントの属性である＠ｐｏｌｌＰｅｒｉｏｄは、ｕｐｄａｔｅｓＡｖａｉｌ属性の値が“ｔｒｕｅ”の場合にのみ存在することができる。＠ｐｏｌｌＰｅｒｉｏｄが存在する場合、活性化トリガーを伝達するためにショートポーリングが用いられていることを示すことができ、＠ｐｏｌｌＰｅｒｉｏｄ属性の値は、受信機がポーリング周期として使用するための秒単位の推薦時間を示すことができる。
ＣｏｎｔｅｎｔＩｔｅｍエレメントの属性である＠Ｓｉｚｅは、当該コンテンツアイテムの大きさを示すことができる。
＠ａｖａｉｌＩｎｔｅｒｎｅｔ属性は、その値が“ｔｒｕｅ”であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能であることを示すことができる。その値が“ｆａｌｓｅ”であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能でないことを示すことができる。この属性が存在しない場合、基本値は“ｔｒｕｅ”であってもよい。”
＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性は、その値が“ｔｒｕｅ”であれば、当該コンテンツアイテムが放送からの抽出に利用可能であることを示すことができる。“ｆａｌｓｅ”値は、当該コンテンツアイテムが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“ｔｒｕｅ”であってもよい。
Ｅｖｅｎｔエレメントは、このＥｖｅｎｔエレメントの属するＴＤＯエレメントによって示されたアプリケーションのイベントに関する情報を含む。受信機は、当該イベントに関する情報を得るためにこのＥｖｅｎｔエレメントをパーシングすることができる。
ＴＤＯエレメントのチャイルドエレメントであるＥｖｅｎｔエレメントは、＠ｅｖｅｎｔＩＤ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ属性及び／又はＤａｔａエレメントを含むことができる。ここで、Ｄａｔａエレメントは、＠ｄａｔａＩＤ属性を含むことができる。
上記Ｅｖｅｎｔエレメントの１６ビット整数属性であってもよい＠ｅｖｅｎｔＩＤは、これを含むＴＤＯエレメントの範囲内で当該イベントを固有に識別することができる。活性化トリガー（又は、ＡＭＴ内の活性化エレメント）は、ａｐｐＩＤとｅｖｅｎｔＩＤの組合せによって当該トリガーに対するターゲットアプリケーション及びイベントを識別することができる。イベントが活性化されると、受信機は、このイベントを当該アプリケーションに渡す。＠ｅｖｅｎｔＩＤは、イベントの識別子の役割を持つ。＠ｅｖｅｎｔＩＤ情報を用いて、当該イベントを活性化させるためのトリガー、ＡＭＴなどを、このイベントを識別するための＠ｅｖｅｎｔＩＤを有するアプリケーションとマッチングさせることができる。すなわち、活性化トリガー（又は、ＡＭＴ内の活性化エレメント）は、ａｐｐＩＤとｅｖｅｎｔＩＤの組合せによって当該トリガーに対するターゲットアプリケーション及びイベントを識別することができる。イベントが活性化されると、受信機は、このイベントを当該アプリケーションに渡す。ＡＭＴの詳細は後述する。
Ｅｖｅｎｔエレメントの属性である＠ａｃｔｉｏｎは、当該イベントが活性化されるときに適用される動作の類型を示すことができる。許容される値は、“ｐｒｅｐ”、“ｅｘｅｃ”、“ｓｕｓｐ”及び“ｋｉｌｌ”であってもよい。
“ｐｒｅｐ”は、“Ｔｒｉｇ ｐｒｅｐ”動作に対応できる。ターゲットとなったアプリケーションの状態が“Ｒｅｌｅａｓｅｄ”であれば、この動作は“Ｒｅａｄｙ”への状態変更を起こすことができる。
“ｅｘｅｃ”は、“Ｔｒｉｇ ｅｘｅｃ”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は“Ａｃｔｉｖｅ”になり得る。
“ｓｕｓｐ”は、“Ｔｒｉｇ ｓｕｓｐ”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態が“Ａｃｔｉｖｅ”である場合、“Ｓｕｓｐｅｎｄｅｄ”に変更可能であり、そうでない場合は変更されない。
“ｋｉｌｌ”は、“Ｔｒｉｇ ｋｉｌｌ”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は“Ｒｅｌｅａｓｅｄ”になり得る。
＠ａｃｔｉｏｎは、当該イベントが活性化される時に適用される動作の類型を示すことができる。
Ｅｖｅｎｔエレメントの属性である＠ｄｅｓｔｉｎａｔｉｏｎは、当該イベントのためのターゲット装置を示すことができる。＠ｄｅｓｔｉｎａｔｉｏｎに関する詳細な内容は後述する。
Ｅｖｅｎｔエレメントの８ビット整数属性であってもよい＠ｄｉｆｆｕｓｉｏｎは、存在する場合、秒単位の時間周期Ｔを示すことができる。この拡散パラメータの目的は、サーバーローディングの最大値を均一にすることである。受信機は０〜Ｔの範囲で１０ミリセカンド単位でランダム時間を算出し、ＴＰＴでＵＲＬによって参照されたコンテンツを検索するためにインターネットサーバーに接続する前にこの時間量だけ遅延されると予想できる。
ＥｖｅｎｔエレメントのチャイルドエレメントであるＤａｔａは、存在する場合、当該イベントに関連するデータを提供することができる。Ｅｖｅｎｔの互いに異なる活性化は、これらの活性化と関連している互いに異なるＤａｔａエレメントを有することができる。ここで、Ｄａｔａエレメントは、＠ｄａｔａＩＤ属性を含むことができる。１６ビット整数属性である＠ｄａｔａＩＤは、これを含むＥｖｅｎｔエレメントの範囲内でＤａｔａエレメントを固有に識別することができる。イベントの活性化がこれと関連するデータを有する場合、活性化トリガーは、ＡｐｐＩＤ、ＥｖｅｎｔＩＤ及びＤａｔａＩＤの組合せによって当該Ｄａｔａエレメントを識別することができる。Ｄａｔａエレメントは、当該イベントに用いられるデータを示す。一つのイベントエレメントは複数のデータエレメントを有することができる。データエレメントの＠ｄａｔａＩＤ属性を用いてデータが識別される。受信端では該当データに関連するイベントが活性化された場合、活性化トリガー（又は、ＡＭＴ内活性化エレメント）は、ＡｐｐＩＤ、ＥｖｅｎｔＩＤ、及びＤａｔａＩＤの組合せによってＤａｔａエレメントを識別することができる。ＡＭＴに関する詳細な内容は後述する。
図７は、‘Ｆｒｅｑｕｅｎｃｙ ｏｆ Ｕｓｅ’属性値の意味の一実施例を示す図である。
“意味”列は、当該アプリケーションを含むセグメントの発生頻度を示す。（もちろん、一つのセグメント内で一つの属性が複数回登場可能である。）ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ属性は、ｇｌｏｂａｌＩＤが存在しなければ存在することができない。万一、アップがキャッシュに保存されて後で用いられるとすれば、受信機は、該当アップが後で再び登場すると、同一のアップとして認識しなければならない。そのためにｇｌｏｂａｌＩｄ属性が必要である。
図８は、‘ｄｅｓｔｉｎａｔｉｏｎ’属性値の意味の一実施例を示す図である。
図８に示すように、目的地属性の値が０のときに予約され、１のときに主装置のみを意味し、２のときに一つ以上の補助装置のみを意味し、３のときに主装置及び／又は一つ以上の補助装置を意味することができる。
図９、図１０、図１１、図１２、図１３は、ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
これは、上述したＴＰＴ構造の２進フォーマットである。この構造は、ＮＲＴでＴＰＴを送信する場合に必要なフォーマットであって、ＴＰＴのＸＭＬ構造をＮＲＴで送信するのに適するように作成しておいたものである。
ＴＰＴのＸＭＬバージョンに含まれた次のエレメント及び／又は属性、すなわち、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ（ｍａｊｏｒ／ｍｉｎｏｒ）、＠ｓｅｒｖｉｃｅＩＤ及び＠ｔｐｔＶｅｒｓｉｏｎは、２進テーブルを伝達するためのカプセル化ヘッダー（ｅｎｃａｐｓｕｌａｔｉｏｎ ｈｅａｄｅｒ）によって放送ストリームで提供できるため、２進バージョンから省略することができる。
フィールドのセマンティックスは、次の通りである。図９、図１０、図１１、図１２、図１３の順に続くＴＤＯパラメータテーブルの２進フォーマットにおいて、上から下に登場する順に記述した。
１ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅ＿ｉｎｃｌｕｄｅｄは、ｅｘｐｉｒｅ＿ｄａｔｅｆｉｅｌｄが含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味でき、その値が‘０’であれば、含まれないことを意味できる。
５ビットフィールドであってもよいｓｅｇｍｅｎｔ＿ｉｄ＿ｌｅｎｇｔｈは、ｓｅｇｍｅｎｔ＿ｉｄのバイト長を示すことができる。
可変長フィールドであるｓｅｇｍｅｎｔ＿ｉｄは、セグメントＩＤのバイトを含むことができるが、これは、ＴＰＴＸＭＬフォーマットの“ｉｄ”属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｂａｓｅ＿ＵＲＬ＿ｌｅｎｇｔｈは、ｂａｓｅ＿ＵＲＬフィールドのバイト長を示すことができる。
可変長フィールドであるｂａｓｅ＿ＵＲＬはベースＵＲＬのバイトを含むことができるが、これは、ＴＰＴＸＭＬフォーマットのｂａｓｅＵＲＬ属性と同じセマンティックスを有することができる。
３２ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅは、当該ＴＰＴインスタンスに含まれた情報の満了日及び時間を示すことができる。受信機がＴＰＴをキャッシュに保存すると、満了日まで再使用することができる。符号無し整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）は、１９８０年１月６日００：００：００ ＵＴＣ以後、ＧＰＳ秒（ｓｅｃｏｎｄ）の数からＧＰＳ−ＵＴＣ＿ｏｆｆｓｅｔを引いたものと解釈することができる。ＧＰＳ ＵＴＣオフセットはＧＰＳとＵＴＣ時刻標準間現在の全体秒単位オフセットを定義する８ビット符号無し整数であってもよい。
８ビットフィールドであってもよいｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬ＿ｌｅｎｇｔｈは、ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬフィールドのバイト長を示すことができる。このフィールドの値が０であれば、個々の活性化トリガーのインターネット伝達が利用可能でないことを示すことができる。
ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが０でなければ、ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬは、Ｔｒｉｇｇｅｒ Ｓｅｒｖｅｒ ＵＲＬのバイトを含むことができ、これはＴＰＴＸＭＬフォーマットのＬｉｖｅＴｒｉｇｇｅｒエレメントのＵＲＬ属性と同じセマンティックスを有することができる。
１ビットフィールドであってもよいｔｒｉｇｇｅｒ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅは、インターネットを介した個別活性化トリガーの伝達モードを示すことができる、‘０’値を有すると、ＨＴＴＰショートポーリングが使用中であることを示すことができ、‘１’値を有すると、ＨＴＴＰロングポーリング又はＨＴＴＰストリーミングが使用中であることを示すことができる。
８ビット整数であってもよいｐｏｌｌ＿ｐｅｒｉｏｄは、ＨＴＴＰショートポーリングが使用中であるとき、ポール間の推奨される秒の数を示すことができる。
８ビットフィールドであってもよいｎｕｍ＿ａｐｐｓ＿ｉｎ＿ｔａｂｌｅは、当該ＴＰＴインスタンスで記述されたアプリケーション（ＴＤＯ）の数を示すことができる。
１６ビットフィールドであってもよいａｐｐ＿ｉｄは、当該アプリケーション（ｎｕｍ＿ａｐｐｓ＿ｉｎ＿ｔａｂｌｅループ（ｌｏｏｐ）の反復で記述されるアプリケーション）に対する識別子を含むことができる。これは、当該ＴＰＴインスタンス内で固有であってもよい。
１ビットフィールドであってもよいａｐｐ＿ｔｙｐｅ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｔｙｐｅフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいａｐｐ＿ｎａｍｅ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｎａｍｅフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいｇｌｏｂａｌ＿ｉｄ＿ｉｎｃｌｕｄｅｄは、ｇｌｏｂａｌ＿ｉｄフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいａｐｐ＿ｖｅｒｓｉｏｎ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｖｅｒｓｉｏｎフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいｃｏｏｋｉｅ＿ｓｐａｃｅ＿ｉｎｃｌｕｄｅｄは、ｃｏｏｋｉｅ＿ｓｐａｃｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅ＿ｉｎｃｌｕｄｅｄは、ｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
１ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅ＿ｉｎｃｌｕｄｅｄは、ｅｘｐｉｒｅ＿ｄａｔｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。
８ビットフィールドであってもよいａｐｐ＿ｔｙｐｅは、存在する場合、このアプリケーションのフォーマット類型を示すことができる。その値が０であれば、そのアプリケーションがＴＤＯであることを示すことができる。万一、このフィールドが存在しない場合、その値は０にデフォルトされる。他の値は他のフォーマットを示すことができる。
８ビットフィールドであってもよいａｐｐ＿ｎａｍｅ＿ｌｅｎｇｔｈは、存在する場合、その直後にくるａｐｐ＿ｎａｍｅフィールドのバイト長を示すことができる。このフィールドの値が０であれば、該当アプリケーションのためのａｐｐ＿ｎａｍｅフィールドが存在しないことを示すことができる。
可変長フィールドであるａｐｐ＿ｎａｍｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのａｐｐＮａｍｅ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｇｌｏｂａｌ＿ｉｄ＿ｌｅｎｇｔｈは、その直後にくるｇｌｏｂａｌ＿ｉｄフィールドのバイト長を示すことができる。このフィールド値が０であれば、当該アプリケーションのためのｇｌｏｂａｌ＿ｉｄフィールドが存在しないことを示すことができる。
可変長フィールドであるｇｌｏｂａｌ＿ｉｄは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｇｌｏｂａｌＩｄ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいａｐｐ＿ｖｅｒｓｉｏｎは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのａｐｐＶｅｒｓｉｏｎ属性と同じセマンティックスを有する。
８ビットフィールドであってもよいｃｏｏｋｉｅ＿ｓｐａｃｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｃｏｏｋｉｅＳｐａｃｅ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅは、存在する場合、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｆｒｅｑｕｅｎｃｙＯｆＵｓｅ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｅｘｐｉｒｅＤａｔｅ属性と同じセマンティックスを有することができる。
１ビットフィールドであってもよいｔｅｓｔ＿ａｐｐは、当該アプリケーションが一般受信機に無視されるようになっているテストアプリケーションであるか否かを示すことができる。その値が‘１’であれば、テストアプリケーションであることを意味でき、その値が‘０’であれば、テストアプリケーションでないことを意味できる。
１ビットフィールドであってもよいａｖａｉｌａｂｌｅ＿ｏｎ＿ｉｎｔｅｒｎｅｔは、当該アプリケーションがインターネットを介して利用可能か否かを示すことができる。その値が‘１’であれば、インターネットを介して利用可能であることを意味でき、その値が‘０’であれば、インターネットを介して利用可能でないことを意味できる。
１ビットフィールドであってもよいａｖａｉｌａｂｌｅ＿ｉｎ＿ｂｒｏａｄｃａｓｔは、当該アプリケーションが放送を介して利用可能か否かを示すことができる。その値が‘１’であれば、放送を介して利用可能であることを意味でき、その値が‘０’であれば、放送を介して利用可能でないことを意味できる。４ビットフィールドであってもよいｎｕｍｂｅｒ＿ＵＲＬｓは、当該アプリケーションを含むファイルの数を示すことができる。
８ビットフィールドであってもよいＵＲＬ＿ｌｅｎｇｔｈは、それに続くＵＲＬフィールドの長さを示すことができる。
可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＵＲＬ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｎｕｍｂｅｒ＿ｃｏｎｔｅｎｔ＿ｉｔｅｍｓは、このアプリケーションによる使用のためにダウンロードしなければならないコンテンツアイテムの数を示すことができる。
１ビットフィールドであってもよいｕｐｄａｔｅｓ＿ａｖａｉｌは、このコンテンツアイテムがたまにアップデートされる否か、すなわち、コンテンツアイテムが固定ファイルの集合であるか、それとも、実時間データフィードであるかを示すことができる。その値が‘１’であれば、アップデートされることを示すことができ、その値が‘０’であれば、アップデートされないことを示すことができる。
１ビットフィールドであってもよいａｖａｉｌ＿ｉｎｔｅｒｎｅｔは、このコンテンツアイテムを含むファイルをインターネットを介してダウンロードできるか否かを示すことができる。その値が‘１’であれば、インターネットを介したダウンロードに利用可能であることを意味でき、その値が‘０’であれば、インターネットを介したダウンロードに利用可能でないことを意味できる。
１ビットフィールドであってもよいａｖａｉｌ＿ｂｒｏａｄｃａｓｔは、このコンテンツアイテムを含むファイルを放送を介してダウンロードできるか否かを示すことができる。その値が‘１’であれば、放送を介したダウンロードに利用可能であることを意味でき、その値が‘０’であれば、放送を介したダウンロードに利用可能でないことを意味できる。
１ビットフィールドであってもよいｃｏｎｔｅｎｔ＿ｓｉｚｅ＿ｉｎｃｌｕｄｅｄは、このアプリケーションのためにｃｏｎｔｅｎｔ＿ｓｉｚｅフィールドが含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味でき、その値が‘０’であれば、含まれないことを意味できる。
４ビットフィールドであってもよいｎｕｍｂｅｒ＿ＵＲＬｓは、このコンテンツアイテムを含むファイルの数を示すことができる。
８ビットフィールドであってもよいＵＲＬ＿ｌｅｎｇｔｈは、それに続くＵＲＬフィールドの長さを示すことができる。
可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍのＵＲＬ属性と同じセマンティックスを有することができる。
２４ビットフィールドであってもよいｃｏｎｔｅｎｔ＿ｓｉｚｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍのｃｏｎｔｅｎｔＳｉｚｅ属性と同じセマンティックスを有することができる。
８ビットフィールドであってもよいｎｕｍ＿ｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のコンテンツデスクリプタの数を示すことができる。
可変長フィールドであるｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該コンテンツアイテムに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このコンテンツアイテムの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。
８ビットフィールドであってもよいｎｕｍｂｅｒ＿ｅｖｅｎｔｓは、このＴＤＯに対して定義されたイベントの数を示すことができる。
１６ビットフィールドであってもよいｅｖｅｎｔ＿ｉｄは、当該イベント（ｎｕｍｂｅｒ＿ｅｖｅｎｔｓループの反復で記述されたイベント）のための識別子を含むことができる。このフィールドは、当該アプリケーションの範囲内で唯一であってもよい。当該イベントはａｐｐ＿ｉｄとｅｖｅｎｔ＿ｉｄの組合せによって活性化トリガーら内で参照されてもよい。
５ビットフィールドであってもよいａｃｔｉｏｎは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのａｃｔｉｏｎ属性と同じセマンティックスを有することができる。
１ビットフィールドであってもよいｄｅｓｔｉｎａｔｉｏｎ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄｅｓｔｉｎａｔｉｏｎフィールドが含まれるか否かを示すことができる。その値が‘１’であれば、このフィールドが含まれることを示すことができ、その値が‘０’であれば、含まれないことを示すことができる。
１ビットフィールドであってもよいｄｉｆｆｕｓｉｏｎ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄｉｆｆｕｓｉｏｎフィールドが含まれるか否かを示すことができる。その値が‘１’であれば、このフィールドが含まれることを示すことができ、その値が‘０’であれば、含まれないことを示すことができる。
１ビットフィールドであってもよいｄａｔａ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄａｔａ＿ｓｉｚｅとｄａｔａ＿ｂｙｔｅｓフィールドが含まれるか否かを示すことができる。その値が‘１’であれば、このフィールドらが含まれることを示すことができ、その値が‘０’であれば、含まれないことを示すことができる。
ｄｅｓｔｉｎａｔｉｏｎフィールドのセマンティックスは、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのｄｅｓｔｉｎａｔｉｏｎ属性のセマンティックスと同一であってもよい。
ｄｉｆｆｕｓｉｏｎフィールドのセマンティックスは、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのｄｉｆｆｕｓｉｏｎ属性のセマンティックスと同一であってもよい。
ｄａｔａ＿ｓｉｚｅフィールドは、存在する場合、その直後にくるｄａｔａ＿ｂｙｔｅｓフィールドの大きさを示すことができる。
ｄａｔａ＿ｂｙｔｅｓフィールドは、存在する場合、当該イベントに関連するデータを提供することができる。当該イベントが活性化される度にターゲットアプリケーションはそのデータを読み取り、それを用いて所望の動作の実行を助けることができる。このフィールドは、原始（ｒａｗ）の２進値を含み得るということを除けば、その内容がＴＰＴ ＸＭＬフォーマットである該当のＴＤＯエレメントの該当のＥｖｅｎｔチャイルドエレメントの該当のＤａｔａチャイルドエレメントの内容と同一なあってもよく、ＴＰＴ ＸＭＬフォーマットであるこのＤａｔａエレメントはその２進値のベース６４エンコーディングを含むことができる。
８ビットフィールドであってもよいｎｕｍ＿ａｐｐ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。
可変長フィールドであるａｐｐ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該アプリケーション（ＴＤＯ）に関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このアプリケーションの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。
８ビットフィールドであってもよいｎｕｍ＿ＴＰＴ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。
可変長フィールドであるＴＰＴ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該ＴＰＴに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このＴＰＴによって示される双方向サービスの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。
図１４は、活性化メッセージテーブル構造の一実施例を示す図である。以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は、設計者の意図によって追加又は変更されてもよい。
活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ：ＡＭＴ）は、セグメントのための活性化トリガーに相応するものを含むことができる。ある環境では活性化トリガーに代えてこのＡＭＴが受信機に伝達されてもよい。トリガーは、“ｌｉｖｅｔｒｉｇｇｅｒ”サーバーによって、ＡＣＲサーバーによってＡＭＴを介してクローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）ストリームで伝達されてもよい。
ＡＭＴ構造内のフィールドの具体的なセマンティックスは、次の通りである。
活性化メッセージテーブル（ＡＭＴ）は、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｇｍｅｎｔＩｄ、＠ｂｅｇｉｎＭＴ属性、及び／又はＡｃｔｉｖａｔｉｏｎエレメントを含むことができる。
ＡＭＴエレメントの４ビット属性であってもよい＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、ＡＭＴ定義の主バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すＡＭＴのインスタンスを捨てると予想できる。
ＡＭＴエレメントの４ビット属性であってもよい＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、存在する場合、ＡＭＴ定義の副バージョン番号を示すことができる。存在しない場合、その値は０にデフォルトすることができる。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すＡＭＴのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想されてもよい。
ＡＭＴの識別子である＠ｓｅｇｍｅｎｔＩＤは、ＡＭＴ内Ａｃｔｉｖａｔｉｏｎが適用されるアプリケーション及びイベントを含むＴＰＴの識別子とマッチングされる。＠ｓｅｇｍｅｎｔＩｄは、ＡＭＴの識別子の役割を担うことができる。したがって、受信端でＡＭＴを受信した後にこれをパーシングし、＠ｓｅｇｍｅｎｔＩｄ情報を用いてＡＭＴを識別することができる。＠ｓｅｇｍｅｎｔＩｄは、ＡＭＴがどのセグメントに適用されるべきかに関する情報を含んでおり、そのセグメントに関連するＴＰＴが有している＠ｉｄとマッチングされてＡＭＴとＴＰＴとを連結する役割を担うことができる。さらに、まず当該ｓｅｇｍｅｎｔを識別することによって、ＡＭＴ内のそれぞれのＡｃｔｉｖａｔｉｏｎエレメントがターゲットとするＴＤＯ、イベントを識別するために必要な基本的な情報を提供することができる。
ＡＭＴエレメントの属性である＠ｂｅｇｉｎＭＴは、存在する場合、ＡＭＴインスタンスが活性化時間を提供するセグメントのメディア時間の開始を示すことができる。＠ｂｅｇｉｎＭＴは、属しているＡＭＴが適用されるセグメントに対してメディア時間の開始を示すことができる。これによって、Ａｃｔｉｖａｔｉｏｎエレメントが示す活性化が発生する時間の基準を定めることができる。したがって、＠ｂｅｇｉｎＭＴがある場合、Ａｃｔｉｖａｔｉｏｎエレメント内の＠ｓｔａｒｔＴｉｍｅ属性は、＠ｂｅｇｉｎＭＴが示すメディア時間の開始に影響を受けることができる。
ＡＭＴのＡｃｔｉｖａｔｉｏｎエレメントの各インスタンスは、あるイベントをこのイベントと関連しているあるデータと共にある時間に活性化する命令を示すことができる。Ａｃｔｉｖａｔｉｏｎエレメントは、ＡＭＴ内に複数個が存在してもよい。各Ａｃｔｉｖａｔｉｏｎエレメントは、活性化トリガーと同様の役割を担うことができる。Ａｃｔｉｖａｔｉｏｎエレメントはいずれも、ＡＭＴ内の＠ｓｅｇｍｅｎｔＩｄが示すセグメントに適用することができる。Ａｃｔｉｖａｔｉｏｎエレメント内の属性に、該当活性化がどのアプリケーションの、どのイベントに、いつ起きるかに関する情報などを含めることができる。Ａｃｔｉｖａｔｉｏｎエレメント内の属性に関する詳細な説明を次に説明する。
Ａｃｔｉｖａｔｉｏｎエレメントは、＠ｔａｒｇｅｔＴＤＯ、＠ｔａｒｇｅｔＥｖｅｎｔ、＠ｔａｒｇｅｔＤａｔａ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅの属性を含むことができる。
Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＴＤＯは、ＡＭＴに関連しているＴＰＴ内のＴＤＯエレメントのａｐｐＩＤ属性とマッチングされることによって、活性化命令に対するターゲットアプリケーションを識別することができる。＠ｔａｒｇｅｔＴＤＯは、ＡＭＴ内のＡｃｔｉｖａｔｉｏｎエレメントがどのアプリケーションに適用されるかに関する情報を含むことができる。受信端ではＡＭＴを受信してパーシングして＠ｔａｒｇｅｔＴＤＯを得、マッチングされるＴＰＴ内のＴＤＯエレメント内の＠ａｐｐＩＤを探して、Ａｃｔｉｖａｔｉｏｎエレメントの適用されるアプリケーションを識別することができる。
Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＥｖｅｎｔは、ｔａｒｇｅｔＴＤＯ属性によって識別されるＴＤＯエレメントに含まれたＥｖｅｎｔエレメントのｅｖｅｎｔＩＤ属性とマッチングされることによって、当該活性化命令に対するターゲットイベントを識別することができる。＠ｔａｒｇｅｔＥｖｅｎｔは、ＡＭＴ内のＡｃｔｉｖａｔｉｏｎエレメントがどのアプリケーションのどのイベントに適用されるかに関する情報を含むことができる。受信端ではＡＭＴを受信しパーシングして＠ｔａｒｇｅｔＥｖｅｎｔを得、マッチングされるＴＰＴ内のＴＤＯエレメント内の＠ｅｖｅｎｔＩＤを探して、Ａｃｔｉｖａｔｉｏｎエレメントの適用されるイベントを識別することができる。
Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＤａｔａは、ｔａｒｇｅｔＴＤＯとｔａｒｇｅｔＥｖｅｎｔ属性によって識別されるＥｖｅｎｔエレメントに含まれたＤａｔａエレメントのｄａｔａＩＤとマッチングされることによって、活性化命令が適用される時にターゲットイベントと関連しているデータを識別することができる。＠ｔａｒｇｅｔＤａｔａは、活性化命令が適用されるとき、ターゲットとなったイベントに関連するデータを識別することができる。受信端ではＡＭＴを受信しパーシングして＠ｔａｒｇｅｔＤａｔａを得、ＴＰＴ内の該当Ｅｖｅｎｔエレメント内の＠ｄａｔａＩＤを探すことができる。
イベントエレメントの属性である＠ｓｔａｒｔＴｉｍｅは、メディア時間に対するイベントの有効期間の開始を示すことができる。受信機は、メディア時間がｓｔａｒｔＴｉｍｅ内の値に到達する時又はその後のできるだけ近いうちに当該命令を実行すると予想され得る。＠ｓｔａｒｔＴｉｍｅは、当該イベントが起きる開始時間を示すことができる。この開始時間はメディア時間を基準とする。受信端ではＡＭＴをパーシングして＠ｓｔａｒｔＴｉｍｅ情報を得、これを用いてイベントの起きる時間が把握できる。受信端では、＠ｓｅｇｍｅｎｔＩｄによって識別されたセグメントのメディア時間を基準にメディア時間が開始時間（ｓｔａｒｔ Ｔｉｍｅ）に達すると、イベントを活性化させることができる。万一、既に開始時間が過ぎた場合は、できるだけ早くイベントを活性化させることができる。
イベントエレメントの属性である＠ｅｎｄＴｉｍｅは、メディア時間に対する当該イベントのための有効期間の終わりを示すことができる。受信機は、メディア時間がｅｎｄＴｉｍｅの値を経過すると当該命令を実行しないと予想され得る。＠ｅｎｄＴｉｍｅは、当該イベントが終わる時間を示すことができる。メディア時間が終わる時間に達すると、受信端ではイベントを実行させなくてもよい。
ＡＭＴ内Ａｃｔｉｖａｔｉｏｎエレメントは、ｓｔａｒｔＴｉｍｅ値の昇順で登場できる。
受信機がＡＭＴ内Ａｃｔｉｖａｔｉｏｎによってイベントを活性化させるとき、受信機は、各活性化をその開始時間に適用したり、又はその後にできるだけ近いうちに適用（例えば、受信機がサービスに加入して、開始時間以降と終了時間以前との間におけるある時間にＡＭＴを受信する場合）すると予想され得る。ＴＰＴ内イベントエレメントの“ａｃｔｉｏｎ”属性が“ｅｘｅｃ”であれば、受信機はＴｒｉｇｇｅｒＥｖｅｎｔをターゲットアプリケーションに渡すと予想できる。ＴｒｉｇｇｅｒＥｖｅｎｔについては、ＡＰＩに関する部分で後述する。
図１５は、ＵＲＬリスト構造の一実施例を示す図である。
ＵＲＬリストは、受信機に対して使用潜在性のあるＵＲＬを含むことができる。次のようなＵＲＬなどを含むことができる。
１．一つ又はそれ以上の未来セグメントに対するＴＰＴのためのＵＲＬ。受信機がファイルを予めダウンロードできるようにする。
２．放送ストリーム内の独立型ＮＲＴサービスに関する情報が検索され得るＮＲＴシグナリングサーバーのＵＲＬ。受信機に放送ストリーム内のＮＲＴサービスシグナリングの伝達に対する接近権限がなくてもこれらのサービスに接近可能になる。
３．仮想チャネルに対する使用報告が送信される使用報告サーバーのＵＲＬ。受信機に放送ストリーム内のこのＵＲＬの伝達に対する接近権限がなくてもこのような報告を送信可能にする。
４．仮想チャネルに対するＰＤＩ−ＱテーブルのＵＲＬ。受信機に放送ストリームで伝達されたＰＤＩ−Ｑテーブルに対する接近権限がなくても視聴経験を個人化可能にする。（ＰＤＩ−Ｑテーブルは双方向サービスを提供するにあたり、ユーザにカスタマイズサービスを提供するための個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）に関連するテーブルである。ＰＤＩ−Ｑテーブルを介してユーザに個人化のための質問ができる。）。
そのうち、ＵｓｒＵｒｌエレメントに関して、ＵＲＬリストを作ってさらに使用報告のためのサーバーのＵＲＬを知らせる必要があり得る。これは、現在、受信機が視聴し消耗しているコンテンツの種類と好むデータを活用してビジネスに活用するためであってもよい。ＵＲＬリストにあるＵｓｒＵｒｌエレメントは、次のように様々に解釈可能である。
第一は、使用報告サーバーである場合は、受信機はこの使用報告サーバーのＵＲＬをもって、予め定められたプロトコル（例、データ構造、ＸＭＬファイルなど）によって受信機の使用報告機能を果たすことができる。
第二は、受信機のウェブブラウザで実行されるＴＤＯであってもよい。ここでは、使用報告ＴＤＯの位置を知らせ、この場合、ＴＤＯが直接、受信機のウェブブラウザのＡＰＩ（例、ファイルＡＰＩ、使用報告ＡＰＩ）を用いて受信機に保存された或いは現在消耗しているコンテンツの情報を収集して報告することができる。ＴＤＯは、独自でＸＭＬＨｔｔｐＲｅｑｕｅｓｔというジャバスクリプトＡＰＩを活用して収集されたデータを送信することができる。
ＵＲＬｌｉｓｔは、ＵｒｌＬｉｓｔ、ＴｐｔＵｒｌ、ＵｒｓＵｒｌ、及び／又はＰｄｉＵｒｌなどを含むことができる。これらのエレメントのセマンティックスは次の通りである。
ＵｒｌＬｉｓｔエレメントのエレメントであるＴｐｔＵｒｌは、現在の双方向付加サービス内の未来セグメントに対するＴＰＴのＵＲＬを含むことができる。複数のＴｐｔＵｒｌエレメントが含まれた場合、放送内のセグメントの登場順に配列することができる。
ＵｒｌＬｉｓｔエレメントのエレメントであるＮｒｔＳｉｇｎａｌｉｎｇＵｒｌは、受信機が現在のトランスポートストリーム内の全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得し得るサーバーのＵＲＬを含むことができる。
ＵｒｌＬｉｓｔエレメントのエレメントであるＵｒｓＵｒｌは、受信機が現在の仮想チャネルに対する使用（視聴率調査）報告を送信し得るサーバーのＵＲＬを含むことができる。
ＵｒｌＬｉｓｔエレメントのエレメントであるＰｄｉＵｒｌは、現在の仮想チャネルに対するＰＤＩ−ＱテーブルのＵＲＬを含むことができる。
図１６は、ＴＰＴを含むプライベートセクションの二進フォーマットの一実施例を示す図である。図１６は、後述する伝達メカニズムにおいて放送ストリームでＴＰＴが伝達される場合を示す。詳細な内容は後述する。
トリガー、ＴＰＴなどを伝達する伝達メカニズムについて説明する。双方向サービス生成からの結果、放送ストリームでのトリガーの伝達、インターネットを介した時間ベーストリガーの伝達、インターネットを介した活性化トリガーの伝達（ＡＣＲシナリオ）、放送ストリームでのＴＰＴの伝達、インターネットを介したＴＰＴの伝達、ＴＤＯ及びコンテンツアイテムの移動、複数セグメントの一つのセグメントへの結合（ｃｏｍｂｉｎｉｎｇ）などを順に説明する。
以下、双方向サービス生成からの結果について説明する。
一つのセグメントに対するサービス生成過程は、全てのＴＤＯ及び他のコンテンツアイテムを含むフォルダ、ＸＭＬ ｆｏｒｍａｔのＴＰＴファイル、及びＸＭＬ ｆｏｒｍａｔのＡＭＴファイルを生成することができる。その他の結果物も生成することができる。
次に、放送ストリーム内でのトリガーの伝達について説明する。
放送ストリームで伝達される場合、トリガーはＵＲＬＳｔｒｉｎｇ命令内でサービス＃６でＤＴＶクローズドキャプションチャネルで伝達することができる。
万一、トリガーの長さが２６文字以下であれば、トリガーはセグメント化せずに送信することができる（Ｔｙｐｅ＝１１）。万一、トリガーの長さが２７乃至５２文字であれば、２つのセグメント（ｔｈｅ ｆｉｒｓｔ ｓｅｇｍｅｎｔ ｉｎ ａ Ｔｙｐｅ＝００セグメントである一番目のセグメントと、Ｔｙｐｅ＝１０セグメントである２番目のセグメント）で送信されてもよい。
当該命令の与えられた任意のインスタンスで伝達されたＵＲＩの類型は、インスタンス８ビットパラメータによって与えることができる。
ＴＤＯモデルを使用する双方向サービスの場合、ＵＲＩデータ構造のＵＲＩ類型は、０（ＴＤＯモデルのための双方向Ｉｎｔｅｒａｃｔｉｖｅ ＴＶトリガー）に設定することができる。この伝達メカニズムは、時間ベーストリガーも活性化トリガーも含む。
時間ベーストリガーが（クローズドキャプションサービス＃６で）放送ストリームで伝達される場合に、“ｍ＝”項が不在であれば、時間ベーストリガーは単純にシグナリングサーバーのＵＲＬを伝達することができる。そして、“ｍ＝”項が不在であれば、“ｔ＝”項は活性化トリガーに不在でなければならない。
活性化トリガーが（クローズドキャプションサービス＃６で）放送ストリームで伝達される場合に、すなわち、“Ｔｒｉｇｇｅｒ”フォーマットが“ｅ＝”項を有しており、“ｔ＝”項は有しているかいない場合に、“ｔ＝”項が存在すれば、活性化時間は時間ベースに対するタイムスタンプであってもよい。そして、“ｔ＝”項が不在であれば、活性化時間はメッセージの到達時間になってもよい。
時間ベーストリガーと活性化トリガーがＣＣサービス＃６を介して伝達される場合、放送局で時間ベーストリガーと活性化トリガーを扱う方法には３つの可能な方法がある。この３つの方法は、‘明示的な時間ベースがないセグメントモード’、‘明示的な時間ベースがあるセグメントモード’、そして‘明示的な時間ベースがないサービスモード’である。
これらは放送内でセグメント単位で混合されてもよい。
明示的な時間ベースがないセグメントモードでは、活性化メッセージがタイムスタンプを含まないため、各メッセージの活性化時間はそのメッセージの伝達時間となり、また、時間ベースメッセージがタイムスタンプを含まないため、その唯一の目的はＴＰＴファイルを伝達し得るシグナリングサーバーのＵＲＬを提供することであり得る。このモードでは、シグナリングサーバーのＵＲＬを提供するための活性化メッセージ内のＵＲＬによって時間ベースメッセージが完全に省略されてもよいが、この場合受信機は、最初の活性化メッセージが登場するまでＴＰＴを検索したり、ＴＤＯのダウンロードを開始できなくなり、活性化メッセージに対する応答をだいぶ遅延することになる。
このような場合、ＣＣサービス＃６に登場し得る時間ベースメッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ＿ｐａｒｔ”を含むことができ、“ｓｐｒｅａｄ”項も含むことができるが、“ｍｅｄｉａ＿ｔｉｍｅ”項は含まなくてもよい。そして、ＣＣサービス＃６で登場し得る活性化メッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ＿ｐａｒｔ”と“ｅｖｅｎｔ＿ｔｉｍｅ”項を含むことができ、“ｓｐｒｅａｄ”項も含むことができるが、“イベント＿ｔｉｍｅ”項には“ｔ＝”部分がなくてもよい。時間ベース及び活性化メッセージの“ｌｏｃａｔｏｒ＿ｐａｒｔ”は現在のｓｅｇｍｅｎｔＩｄであってもよい。このＵＲＬは、インターネットを介してセグメントのためのＴＰＴを検索するために用いられてもよい。
明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含む。活性化メッセージは、時間ベースに対する活性化時間を定義するために時間スタンプを含む。又は、これらのメッセージはタイムスタンプを含まなくてもよく、この場合、活性化時間はメッセージの到達時間である。
この場合、ＣＣサービス＃６で登場し得る時間ベースメッセージは、Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ＿ｐａｒｔ”と“ｍｅｄｉａ＿ｔｉｍｅ”項を含むことができ、“ｓｐｒｅａｄ”項も含んでもよく、ＣＣサービス＃６で登場し得る活性化メッセージは“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ＿ｐａｒｔ”と“ｅｖｅｎｔ＿ｔｉｍｅ”項を含むことができ、“ｓｐｒｅａｄ”項も含んでもよく、このとき、“ｅｖｅｎｔ＿ｔｉｍｅ”項内の“ｔ＝”部分は存在してもしなくてもよい。時間ベース及び活性化メッセージの“ｌｏｃａｔｏｒ＿ｐａｒｔ”は現在のｓｅｇｍｅｎｔＩｄであってもよく、該当時間ベースは該当セグメントに特定である。このＵＲＬは、インターネットを介してセグメントのためのＴＰＴを検索するために用いられてもよい。
明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含み、活性化メッセージは時間スタンプを含んでも含まなくてもよい。時間ベースは特定の一セグメントに特定されるよりは、複数のセグメントにわたって延長することができる。時間ベースメッセージの“ｌｏｃａｔｏｒ＿ｐａｒｔ”は、時間ベースの識別子であってもよく、インターネットを介してサービスのためのＴＰＴを検索するために使用可能なＵＲＬであってもよい。
いずれの場合であれ、ＣＣサービス＃６にトリガーを挿入するトリガー挿入サーバーは、ＡＭＴから作業をして、活性化メッセージをＡＭＴ内のＸＭＳフォーマットからＣＣサービス＃６での伝達に特定されたトリガーフォーマットに変えなければならない。ｅｎｄＴｉｍｅ属性がないＡｃｔｉｖａｔｉｏｎエレメントの場合は、活性化時間がｓｔａｒｔＴｉｍｅ属性と同一であり、単一トリガーが挿入されてもよい。ｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅエレメントの両方を有するＡｃｔｉｖａｔｉｏｎエレメントの場合は、同一のターゲットをもってトリガーシーケンスが挿入されてもよい。シーケンス内の最初のトリガーは、ｓｔａｒｔＴｉｍｅ属性と同じ活性化時間を有することができ、当該シーケンス内の最後のトリガーは、ｅｎｄＴｉｍｅ属性と同じ活性化時間を有することができ、シーケンス内のトリガーの活性化時間の間には固定した時間区間が存在できる（例外として、シーケンス内の最後のトリガーとその直前のトリガーとの間の区間はより短くてもよい。）。この固定した時間区間の長さは設定可能である。
時間ベース及び活性化メッセージがセグメントモードであるとき、時間ベースは、セグメントに対して特定することができる。このベースは、当該セグメントの開始時に“ｂｅｇｉｎＭＴ”値で始まって、セグメントを通じて行うことができる。個々の活性化の“ｓｔａｒｔＴｉｍｅ”と“ｅｎｄＴｉｍｅ”値は、“ｂｅｇｉｎＭＴ”値に対して相対的であってもよい。時間ベース及び活性化メッセージがサービスモードにあるとき、時間ベースはセグメントにわたっていてもよく、各セグメントに対する“ｂｅｇｉｎＭＴ”値は、サービス時間ベースと放送スケジュールを考慮して調整することができる。
次に、インターネットを介した時間ベーストリガーの伝達について説明する。
時間ベーストリガーインターネット伝達は、いわゆる自動コンテンツ認識（Ａｕｔｏｍａｔｉｃ Ｃｏｎｔｅｎｔ Ｒｅｃｏｇｎｉｔｉｏｎ、ＡＣＲ）状況で有用であり得るが、このような状況で、時間ベーストリガーの受信側はクローズドキャプションサービス＃６に対する接近権限がない。このような状況で受信機はビデオフレームを認識し、時間ベースをこれらのフレームと同期化させるためにＡＣＲを使用しなければならない。ＡＣＲ状況で時間ベースメッセージはウォーターマーク又はＡＣＲサーバーから得ることができる。ＡＣＲサーバーから受ける場合、時間ベースメッセージはＡＣＲサーバーから応答として伝達されてもよい。
次に、インターネットを介した活性化トリガーの伝達（ＡＣＲシナリオ）について説明する。
活性化メッセージは、ショートポーリング、ロングポーリング又はストリーミングを通じて伝達することができるが、これらのメッセージはいずれも受信機とサーバーに相当のオーバーロードを発生させ得る。活性化メッセージは、ＡＭＴの形態で伝達されてもよいが、セグメントの長さに関する多い量の情報を提供し、広告サイト遮断器（ａｄ ｋｉｌｌｅｒ）を可能にすることができる。他の方法も可能である。
活性化メッセージが活性化トリガーの形態で伝達される場合に、すなわち、“Ｔｒｉｇｇｅｒ”ｆｏｒｍａｔにおいて“ｅ＝”項はあり、“ｔ＝”項はあるかない場合に、これは、ＨＴＴＰショートポーリング、ロングポーリング又はストリーミングを通じて伝達され得る。
インターネットを介して伝達される場合、活性化メッセージは、個別的活性化トリガー伝達メカニズムや一括的活性化トリガー伝達メカニズムのいずれか一方又は両方を用いて伝達することができる。
次に、個別的活性化トリガー伝達について説明する。
前述したように、個別活性化トリガーは、インターネットを介して伝達されるとき、ＨＴＴＰショートポーリング、ロングポーリング又はストリーミングを用いて伝達すことができる。活性化トリガーのフォーマットはＤＴＶＣＣサービス＃６を通じて伝達されるときと同一であってもよい。
ショートポーリングの場合は、そのポーリング周期を指定しなければならない。この周期は、次の説明のように、ＴＰＴにあるｐｏｌｌＰｅｒｉｏｄを用いてショートポーリング動作を設定することができる。
活性化トリガーのインターネット伝達が利用可能な場合、ＴＰＴ内ＬｉｖｅＴｒｉｇｇｅｒエレメントのＵＲＬ属性は、活性化トリガーを伝達し得る活性化トリガーサーバーを示すことができる。ＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性がＴＰＴに存在する場合、これはＨＴＴＰショートポーリングが使用中であることを示すことができ、この属性は、受信機が用いるべきポーリング周期を示すことができる。ＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性がＴＰＴに存在しない場合、これは、ＨＴＴＰロングポーリングとＨＴＴＰストリーミングのいずれか一方が使用中であることを示すことができる。
いずれのプロトコルが用いられるかにかかわらず、受信機は質疑形式で活性化トリガーサーバーにＨＴＴＰ要求をすると予想できる。
?mt=<media_time>
ここで、＜ｍｅｄｉａ＿ｔｉｍｅ＞は、視聴されているコンテンツの現在メディア時間であってもよい。
ショートポーリングが使用中である場合、活性化トリガーサーバーからの応答は、＜ｍｅｄｉａ＿ｔｉｍｅ＞で終わるｐｏｌｌＰｅｒｉｏｄ長の時間区間内で発生した全てのトリガーを含むことができる。一つ以上の活性化トリガーがリターンされる場合、これらは一つ以上の空白（ｗｈｉｔｅｓｐａｃｅ）文字によって分離することができる。万一、リターンされる活性化トリガーがないと、当該応答は空いていてもよい。
ＨＴＴＰロングポーリング又はＨＴＴＰストリーミングが使用中である場合は、活性化トリガーサーバーは、活性化トリガーが放送ストリームで伝達されるメディア時間まで応答のリターンを待機することができる。このとき、活性化トリガーをリターンすることができる。
ＨＴＴＰロングポーリングが使用中である場合、活性化トリガーサーバーは、活性化トリガーをリターン後にセッションを閉じることができる。受信機はアップデートされたメディア時間を用いて直ちに他の要求をすると予想できる。
ＨＴＴＰストリーミングが使用中である場合、活性化トリガーサーバーは、各活性化トリガーをリターンした後に当該セッションを開いた状態に維持し、追加の活性化トリガーを伝達する時間が到達すると、当該セッションでそれらのトリガーを伝達することができる。
いずれの場合においても、ＨＴＴＰ応答は、伝達モードを知らせるために、次の形態のいずれかの形態からなるＨＴＴＰ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒフィールドを含むことができる。
ATSC-Delivery-Mode:ShortPolling[<poll-period>]
ATSC-Delivery-Mode:LongPolling
ATSC-Delivery-Mode:Streaming
＜ｐｏｌｌ−ｐｅｒｉｏｄ＞パラメータは、連続するポールに対してポール間の推奨間隔を示すことができる。＜ｐｏｌｌ−ｐｅｒｉｏｄ＞は省略されてもよい。
次に、活性化トリガー一括伝達について説明する。
活性化トリガーがインターネットを介して一括的に伝達される場合、一つのセグメントに対する活性化トリガーを、当該セグメントに対するＴＰＴをメッセージの一番目の部分とし、ＡＭＴをメッセージの二番目の部分とする多重部分ＭＩＭＥメッセージの形態としてＨＴＴＰを通じて当該セグメントに対するＴＰＴと共に伝達することができる。
以下、放送ストリームでのＴＰＴ伝達について説明する。
放送ストリームで伝達時に、ＴＰＴを、それらのＸＭＬフォーマットから相応する２進ＮＲＴ−スタイルシグナリングフォーマットに変換して、テーブルインスタンス当たり一つずつＮＲＴ−スタイルプライベートセクションにカプセル化することができる。現在セグメントに対するＴＰＴは常に存在する。一つ以上の未来セグメントにに対するＴＰＴも存在することができる。ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄフィールドの値によって定義される。参考として、ＴＤＯパラメータテーブルの２進フォーマットは、上述した通りである。ここで、ＮＲＴ−スタイルプライベートセクションは、図１６のｔｐｔ＿ｓｅｃｔｉｏｎ（）に該当してもよい。
要するに、ＴＰＴの２進構造をＮＲＴで送信するために、ＮＲＴ送信に合うようにセクション構造を有することができる。以下、この過程について詳しく説明する。
各ＴＰＴをブロックに分割し、それらのブロックをｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎとｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの共通値を持つセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドに挿入することによって、各ＴＰＴをＮＲＴ−スタイルプライベートセクション内にカプセル化することができる。これらのブロックは、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値の昇順でセクションに挿入することができる。プライベートセクションは、ＴＰＴに関連する仮想チャネルのＩＰサブネットのサービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ；ＳＳＣ）で送信することができる。ここで、“Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ”は、ＡＴＳＣ−ＮＲＴ標準に定義されており、特定ＩＰアドレスとポートナンバーを持つチャネルを意味する。セクション内のｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同一ＳＳＣで送信される互いに異なるＴＰＴインスタンスを区別するために用いることができる。
以下、図１６のフィールドについて説明する。
プライベートセクション（ｔｐｔ＿ｓｅｃｔｉｏｎ（））は、ｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、及び／又はｓｅｒｖｉｃｅ＿ｉｄ、ｔｐｔ＿ｂｙｔｅｓ（）情報を含むことができる。
８ビットフィールドであってもよいｔａｂｌｅ＿ｉｄは、当該テーブルセクションをＴＤＯパラメータテーブルインスタンスに属するものとして識別することができる。
ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは２つの部分に分けることができる。８ビット符号無し整数フィールドのうち上位４ビットは、当該テーブルの定義の主バージョン番号と、ここに含まれて送信されるＴＰＴインスタンスを示すことができ、下位４ビットは、副バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すＡＭＴのインスタンスを捨てると予想され得る。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すＡＭＴのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが認識できないデスクリプタと、それらが支援しないフィールドを無視すると予想できる。
ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、８ビットフィールドであってもよい。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、当該ＴＰＴインスタンスの他の全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと同一であり、当該サービスシグナリングチャネル内の他のＴＰＴインスタンスの全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒとは異なってよい。したがって、他のＴＰＴインスタンスと区別する役割を担うことができる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、このセクションが現れるサービスシグナリングチャネルに関連しているＩＰサブネットを示すことができる。互いに異なるＴＰＴインスタンスのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値は、放送ストリームでセグメントが登場する順序を反映することができる。
ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、５ビットフィールドであってもよく、当該ＴＰＴインスタンスのバージョン番号を示すことができるが、ここで、ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄによって定義することができる。ＴＰＴバージョンをあらかじめ知ってこそ受信されたＴＰＴセクションデータが最新バージョンのＴＰＴであるか否かがわかるため、セクションテーブルにＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドがあってもよい。バージョン番号は、ＴＰＴインスタンス内の任意のフィールドに変更がある場合、１ ｍｏｄｕｌｏ ３２分ずつ増分できる。
ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒは１ビット指示子であってもよく、ＴＰＴセクションに対して常に‘１’に設定されて送信されるＴＰＴがｓｅｇｍｅｎｔ＿ｉｄによって識別されるセグメントに対して常に現在ＴＰＴであることを示すことができる。
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、当該ＴＰＴインスタンスセクションのセクション番号を提供することができるが、ＴＰＴインスタンスはｓｅｇｍｅｎｔ＿ｉｄによって識別可能である。ＴＰＴインスタンス内の最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは０ｘ００であってもよい。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、ＴＰＴインスタンス内の各追加セクションと共に１ずつ増分可能である。
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、最後のセクション（すなわち、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒが最も高いセクション）が、その一部であるＴＰＴインスタンスの最後のセクション番号を提供することができる。
ｓｅｒｖｉｃｅ＿ｉｄは、当該テーブルインスタンスに記述されたコンテンツアイテムを提供する双方向サービスと関連しているｓｅｒｖｉｃｅ＿ｉｄを特定することができる。
ｔｐｔ＿ｂｙｔｅｓ（）は、可変長フィールドであって、当該セクションによって部分的に送信されるＴＰＴインスタンスブロックで構成することができる。当該テーブルインスタンスの全てのセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドがｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドの順に連結されると、その結果として一つの完全なＴＰＴインスタンスが作成できる。
すなわち、ＴＰＴの２進フォーマットを用いたり、ＸＭＬフォーマットを２進フォーマットに変えた後、ＮＲＴ送信に合うようにそれを分けて、プライベートセクションのうちｔｐｔ＿ｂｙｔｅｓ（）フィールドに入れてＮＲＴ方式で送信することができる。このとき、一つのＴＰＴが複数のプライベートセクションに分けられると、それぞれのプライベートセクションは、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を有することができる。分けられたＴＰＴブロックをｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値に従う順に挿入することができる。
受信端では、受信したプライベートセクションに対してパーシングできる。一つのＴＰＴに再びまとめるために、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つプライベートセクションを用いることができる。このとき、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ情報から得られる順序情報を用いることができる。同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つ全てのプライベートセクションのｔｐｔ＿ｂｙｔｅｓ（）がｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒの順に連結されると、その結果として一つの完全なＴＰＴを作成できる。
インターネットを介したＴＰＴの伝達について図１７を参照して詳しく説明する。
次に、ＴＤＯ及びコンテンツアイテムの移動について説明する。
ネットワークと基地局は、ＴＤＯ及びこれらのＴＤＯによって用いられるコンテンツアイテム（ファイル）の伝達のために、自体ＨＴＴＰサーバーを頻繁に提供しなければならない。提供がなされると、ＴＰＴ内のｂａｓｅＵＲＬはサーバーの位置を反映して調整されてもよい。
次に、複数のセグメントを一つのセグメントへの結合について説明する。
セグメント間の境界を徹底的に曖昧にさせるために、複数のセグメントに対するＴＰＴとＡＭＴを一つのＴＰＴ及びＡＭＴに結合することができる。その段階は、次の通りである。
１．結合されるセグメントの集合を識別する。
２．新しいｓｅｇｍｅｎｔＩｄを有する新しいＴＰＴを生成する。
３．結合されるセグメントの中でライブ活性化を有するものがあれば、それらの活性化の全てに対して接近権限を付与するリレーサーバーを提供し、このサーバーに対するパラメータを“ＬｉｖｅＴｒｉｇｇｅｒ”エレメントに入れる。
４．必要によって各セグメントに対してｂａｓｅＵＲＬを適用して全体ＴＤＯとＣｏｎｔｅｎｔＩｔｅｍ ＵＲＬを得る（結合される全てのセグメントに共通するより短いｂａｓｅＵＲＬを識別し、それを、結合されたセグメントに対するｂａｓｅＵＲＬとして維持する）。
５．必要によって値を修正して衝突を除去する。
６．結合される全てのセグメントに対する全ての修正されたＴＤＯエレメントを新しいＴＰＴに挿入する。
７．結合されたＴＰＴの新しいｓｅｇｍｅｎｔＩｄに相応するｓｅｇｍｅｎｔＩｄを有する新しいＡＭＴを生成する。
８．新しいＡＭＴに対して適切な新しい“ｂｅｇｉｎＭＴ”値を選択する。
９．ａｐｐＩｄ値における変更を反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎ要素のｔａｒｇｅｔＩｄ値を調整する。
１０．新しい“ｂｅｇｉｎＭＴ”値と結合されるセグメントに対する放送スケジュールを反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎエレメントのｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ値を調整する。
１１．修正された全てのＡｃｔｉｖａｔｉｏｎエレメントを新しいＡＭＴに挿入する。
図１７は、ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。
以下、インターネットを介したＴＰＴの伝達について説明する。
インターネットで伝達される場合、ＴＰＴはＨＴＴＰを通じて伝達することができる。時間ベースメッセージで現在セグメントに対するＴＰＴのＵＲＬは“＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞”であってもよい。ＴＰＴに対する要求に対する応答は、単純にＴＰＴで構成されてもよく、要求されたＴＰＴは第１部分にあり、ＵＲＬリストは第２部分にあってＸＭＬ文書としてエンコードされる２−部分ＭＩＭＥメッセージとして構成されてもよい（要求に対する応答は常に現在セグメントに対するＴＰＴを含む。一つ以上の未来セグメントらに対するＴＰＴも含むことができる）。
上述した応答の第２部分としてのＵＲＬは、図１７のような形態であってもよい。
図１７のエレメントのセマンティックスについて説明する。
“ＵｒｌＬｉｓｔ”は、受信機に有用なＵＲＬリストを含むことができる。
“ＴｐｔＵｒｌ”は、未来セグメントに対するＴＰＴのＵＲＬを含むことができる。複数のＴｐｔＵｒｌエレメントが含まれる場合、それらは、放送でセグメントの登場順に配列することができる。
“ＮｒｔＳｉｇｎａｌｉｎｇＵｒｌ”は、受信機が現在の放送ストリームで全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得し得るサーバーのＵＲＬを含むことができる。
図１８は、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
以下、ＤＯを実行するための環境のための、ＡＴＳＣＪａｖａＳｃｒｉｐｔＡＰＩについて説明する。
放送プログラムに対する宣言的客体動作の同期化を支援するために、ビデオ／放送客体に対して追加の方法が支援されてもよい。
ＤＴＶＣＣ或いはインターネットでＴＰＴが受信されると、ＴＰＴ内にはＴＤＯを実行するための複数のイベントがあってもよく、これらのイベントは活性化トリガーによって活性化されてもよい。
このイベントを処理するようにするために、リスナー（Ｌｉｓｔｅｎｅｒ）という関数をｅｖｅｎｔＩＤ別に登録しておくことができる。これによって、上述の‘追加の方案’として、リスナー関数を登録できる次の２つの関数があり得る。
図１８には、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒについての説明とフォーマット、アーギュメント（ａｒｇｕｍｅｎｔ）などが示されている。
”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ｅｖｅｎｔＩｄごとに生成されたイベントを処理するコールバック（ｃａｌｌｂａｃｋ）関数（リスナー関数）を登録することができる。”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒ及びＮｕｍｂｅｒタイプのｅｖｅｎｔＩｄをアーギュメントとして受け取ることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについて後述する。”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は返還値を有しなくともよい（ｖｏｉｄ）。ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメントにおいてイベントＩＤであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、イベントに対するリスナーであってもよい。
受信機のトリガー処理モジュールでは活性化メッセージを受信するすと直ちに“ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数を用いてｅｖｅｎｔＩｄごとにリスナー関数を登録することができる。後で当該イベントに活性化が起きると、登録されたリスナー関数を呼び出すことができる。このとき、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの客体をリスナー関数として伝達することができる。ＴｒｉｇｇｅｒＥｖｅｎｔタイプについては後述する。
図１９は、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
図１９には、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒに対する説明とフォーマット、アーギュメントなどが示されている。
”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ｅｖｅｎｔＩｄごとに生成されたイベントを処理するコールバック関数（リスナー関数）の登録を取消すことができる。”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒ及びＮｕｍｂｅｒタイプのｅｖｅｎｔＩｄをアーギュメントとして受け取ることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについて後述する。”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は返還値を有しなくてもよい（ｖｏｉｄ）。ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメントでイベントＩＤであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、イベントに対するリスナーであってもよい。
ジャバスクリプトプログラムでは、当該ｅｖｅｎｔＩｄ別に発生し得るイベントをそれ以上受信しないことを希望したり、“ＤｅｓｔｒｏｙＷｉｎｄｏｗ”のようなプログラム終了時には、“ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”を用いて、登録されたリスナー関数を取り消すことができる。
図２０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。
ここで、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義は、Ｗｅｂ ＩＤＬ（Ｗｅｂ ｉｎｔｅｒｆａｃｅ ｄｅｆｉｎｉｔｉｏｎ ｌａｎｇｕａｇｅ）（インターフェース定義言語）に従う。Ｗｅｂ ＩＤＬは、ウェブブラウザーで実行されるように意図的インターフェースを記述するために用いることができる。Ｗｅｂ ＩＤＬは、ウェブプラットフォームにおける共用スクリプトオブジェクトの動作をより読みやすく明細化するための多数の機能を有するＩＤＬの変種である。
ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプは、ＴｒｉｇｇｅｒＥｖｅｎｔタイプを持つイベントをアーギュメントとすることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒはインターフェースであってもよい。
図２１は、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。
ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、イベントに関する情報を含むことができる。
ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、ｅｖｅｎｔＩｄ、ｄａｔａ、ｓｔａｔｕｓを属性として有することができる。ここで、ｅｖｅｎｔＩｄは、ＴＰＴのイベントエレメント中のｅｖｅｎｔＩｄであってもよい。ここで、ｄａｔａは、イベントの活性化のためのものであってもよい。ここで、ｄａｔａは、１６進法となっていてもよい。ここで、ｓｔａｔｕｓは、イベントの状態を意味することができる。ここで、ｓｔａｔｕｓ値が“ｔｒｉｇｇｅｒ”の場合は、イベントが活性化トリガーによって活性化された状態を意味できる。ここで、ｓｔａｔｕｓ値が“ｅｒｒｏｒ”の場合は、エラーが発生した状態を意味できる。
ＴＤＯモデルについて説明してきた。以下、直接実行モデルについて説明する。
直接実行モデルでは、仮想チャネルが選択されると、宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ；ＤＯ）が自動で開始され得る。ＤＯは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのようにオーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を得るために、バックエンド（ｂａｃｋｅｎｄ）サーバーとインターネットを介して通信することができる。
以下直接実行モデルにおけるトリガー動作について説明する。
トリガーの役割、機能、シンタックスは、直接実行モデルにおいても大きく変わらない。
トリガーの性能については、上述した通りである。
トリガーシンタックスについては、上述した通りである。
トリガーは、３つの部分で構成されたと見なすことができる。
＜ドメインネーム部分＞／＜ディレクトリ経路＞［？＜パラメータ＞］
直接実行モデルにおいて、＜ドメインネーム部分＞と＜ディレクトリ経路＞の組合せは、開始されるＤＯを固有に識別することができる。
＜パラメータ＞は、“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、又は“ｓｐｒｅａｄ”のうち一つ以上からなることができる。
直接実行モデルにおいて、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは、“同期化されたコンテンツプロトコル”を介してバックエンドサーバーとインターネットで通信することができる。このサーバーは、オーディオ−ビデオプログラムと全て同期化された双方向特徴の提供のための具体的な指示事項を提供することができる。
直接実行モデルの場合、直ちにアプリケーションが実行されるために、時間ベーストリガーが伝達されるやいなや、現在実行中のアプリケーションに情報を伝達することができる。このモデルにおいて、アプリケーションは、サーバーに、同期化のために、現在放映中のコンテンツに関する情報を続けて伝達する必要がある。そのために、時間ベーストリガーには、ＴＤＯモデルとは異なる特別な情報がさらに含まれてもよい。この特別な情報は、現在放映中のコンテンツに対する識別子であってもよい。
同様に、上記コンテンツ識別子は、トリガーのパラメータ部分にパラメータの形態で存在できる。
同様に、上記コンテンツ識別子は、トリガーのｍｅｄｉａ＿ｔｉｍｅに一つの項の形態で存在してもよい。コンテンツ識別子項は、文字列を伴う“ｃ＝”によって指定されうるｃｏｎｔｅｎｔ＿ｉｄと呼ぶことができ、現在見られているコンテンツに対する識別子を示すことができる。
ｃｏｎｔｅｎｔ＿ｉｄ項は、双方向サービス実行に対する直接実行モデルを支援するためのものであってもよい。
上述した通り、このモデルにおいて、ｃｏｎｔｅｎｔ＿ｉｄ項を有する時間ベーストリガーは、アプリケーションの開始後にこのアプリケーションに伝達されてもよく、このアプリケーションは、双方向作用のためのコンテクスト（ｃｏｎｔｅｘｔ）の識別のために、ｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。詳細な動作については後述する。
直接実行モデルにおけるトリガーの伝達メカニズムについては、上述した通りである。
ただし、放送ストリームによるトリガーの伝達の場合において、トリガーは、ＵＲＬＳｔｒｉｎｇ命令でサービス＃６でＤＴＶクローズドキャプションチャネルに伝達されてもよい。そして、直接実行モデルを用いる双方向サービスは、ＵＲＩ＿ｔｙｐｅフィールドが２（直接実行モデルのための双方向ＴＶトリガー）に設定されてもよい。
以下、直接実行モデルの全体動作について説明する。
双方向サービスを実行する一つのモデルとして、直接実行モデルでは、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは“同期化されたコンテンツプロトコル”を介してインターネットでバックエンドサーバーと通信することができる。このサーバーは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのようにオーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を提供することができる。
上記の動作を次のように行うことができる。
まず、アプリケーションが開始されうる。その後、時間ベーストリガーが受信される。時間ベーストリガーは、アプリケーションが実行された後にアプリケーションに伝達される。時間ベーストリガーのｃｏｎｔｅｎｔ＿ｉｄ項には、現在見られているコンテンツに関するコンテンツ識別情報が含まれていてもよい。アプリケーションは、相互作用のためのコンテクストを識別し、現在見られているコンテンツを識別するためにｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。
直接実行モデルについて説明してきた。
図２２は、ＷＭ技法のためのアーキテクチャの一実施例を示す図である。
他のインターフェースを介した伝達について説明する。
非圧縮されたオーディオ及びビデオにのみ接近可能な（例えば、ケーブル又は衛星セットトップボックスから受信される）環境で双方向サービスの取得を可能にするプロトコル及びアーキテクチャが定義される。アーキテクチャ及びプロトコルは、インターネット接続を有し、放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる受信機による使用のために設計することができる。勿論、アーキテクチャ及びプロトコルは、双方向サービスプロバイダがそれの支援を選択する場合は、成功的に用いることができる。
このアーキテクチャは、視聴されているコンテンツの識別のための２つの基本技法を支援するように設計され、関連双方向サービスデータ改善事項がインターネットを介して伝達されうるようにすることができる。２つの基本技法は、ウォーターマーキング（Ｗａｔｅｒ ｍａｒｋｉｎｇ）とフィンガープリンティング（Ｆｉｎｇｅｒ ｐｒｉｎｔｉｎｇ）であってもよい。
ウォーターマーキング、フィンガープリンティング技法両方とも、その目的は、どのプログラムが現在視聴されているかを受信機が探して、当該プログラムのための双方向サービスに関する付加情報を得る出発点として用いられうるＵＲＬを取得できるようにすることである。
図２２は、ＷＭ技法のためのアーキテクチャの一実施例を示す図である。
ＷＭ技法のためのアーキテクチャにおいて、アーキテクチャは、放送局２２０１０、ウォーターマーク挿入部２２０１１、ＭＶＰＤ ２２０２０、ＳＴＢ ２２０３０、受信機２２０４０、ＷＭクライアント２２０５０、ＴＰＴサーバー２２０６０及びコンテンツサーバー２２０７０で構成することができる。
放送局２２０１０は、オーディオ／ビデオストリーム及びこれと関連する双方向サービスを送出するソースであってもよい。ＴＶ放送局などをその例に挙げることができる。 放送局２２０１０は、放送コンテンツの生産者又は流通業者であってもよい。放送局２２０１０は、放送ストリーム、オーディオ／ビデオコンテンツ、双方向データ、放送スケジュール又はＡＭＴなどを伝達することができる。
ウォーターマーク挿入部２２０１１は、放送されるオーディオ／ビデオフレームにウォーターマークを入れることができる。ウォーターマーク挿入部２２０１１は、放送局２２０１０と統合されてもよく、別個のモジュールであってもよい。ウォーターマークとは、受信機に必要な一種の情報であってもよい。ウォーターマークは、ＵＲＬのような情報であってもよい。ウォーターマークについての詳細は後述する。
ＭＶＰＤ ２２０２０は、多重チャネルビデオプログラム流通業者（Ｍｕｌｔｉｐｒｏｇｒａｍ Ｖｉｄｅｏ Ｐｒｏｇｒａｍ Ｄｉｓｔｒｉｂｕｔｏｒ）の略語である。ＭＶＰＤ ２２０２０は、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者であってもよい。ＭＶＰＤ ２２０２０は、放送局／ウォーターマーク挿入部から放送ストリームを受信することができ、ウォーターマーキングＡＣＲシステムの場合、ウォーターマーク挿入部２２０１１によってウォーターマークが挿入される。ＭＶＰＤ ２２０２０は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス（ＳＴＢ）に送る。
ＳＴＢ ２２０３０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを、視聴者が視聴するＴＶ受像機に送る。ＳＴＢは、非圧縮されたオーディオ／ビデオコンテンツを受信機２２０４０に送ることができる。ＳＴＢは、本発明の一実施例に係る外部のデコーティング部であってもよい。
受信機２２０４０は、ＷＭクライアント２２０５０を含むことができる。ＷＭクライアント２２０５０は、受信機２２０４０の外部に位置してもよい。ここで、受信機は、ウォーターマーキングができる受信機である。受信機２２０４０の構造については後述する。
ＷＭクライアント２２０５０は、該当用途のＡＰＩを用いてＡＣＲサーバー（図示せず）から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、ＷＭクライアント２２０５０は、受信機内に構成されるが、他の構成も可能である。ＷＭクライアント２２０５０は、非圧縮されたオーディオ／ビデオコンテンツから、挿入されたウォーターマークを抽出することができる。ウォーターマークはＵＲＬなどの情報であってもよい。
ＴＰＴサーバー２２０６０は、ＴＰＴのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機２２０４０は、抽出されたウォーターマークをＡＣＲサーバーに伝送する。ウォーターマークがデータベース（図示せず）に保存されたウォーターマークとマッチングされると、受信機２２０４０は、一トリガー又は複数トリガーを応答として受信することができる。受信された一トリガー又は複数トリガーが、上述した新しいｌｏｃａｔｏｒ＿ｐａｒｔを有したり、又は新しいバージョンのＴＰＴ又はアプリケーションパラメータテーブルが発見されると、受信機２２０４０はＴＰＴサーバー２２０６０に新しいＴＰＴ又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
コンテンツサーバー２２０７０は、双方向サービスを提供するために必要なアプリケーション及びＴＤＯを提供することができる。新しいアプリケーション又はＴＤＯが必要な場合、新しいアプリケーションは、ＴＰＴ又はアプリケーションパラメータテーブルにあるＵＲＬを用いてダウンロードすることができる。
ウォーターマーキング（ＷＭ）技法において、放送局／ウォーターマーク挿入部は、放送されるオーディオ／ビデオフレームにウォーターマークを入れることができる。これらのウォーターマークは、視聴者に感知されないか、又はできるだけ邪魔とならないような量の情報を受信機に送信するように設計することができる。このようなウォーターマークは、受信機が必要とする情報を直接提供してもよく、又は受信機が必要とする情報を得るために、遠く離れたサーバーにインターネット接続を通して送ることができるコード値のみを提供してもよい。
図２３に、ＦＰ技法のアーキテクチャの一実施例が示されている。
ＦＰ技法のアーキテクチャにおいて、アーキテクチャは、放送局２３０１０、ＭＶＰＤ ２３０２０、ＳＴＢ ２３０３０、受信機２３０４０、ＦＰクライアント２３０５０、ＴＰＴサーバー２３０６０、コンテンツサーバー２３０７０、シグネチャー（ｓｉｇｎａｔｕｒｅ）抽出機２３０８０及びＦＰサーバー２３０９０で構成することができる。
放送局２３０１０は、オーディオ／ビデオストリーム及びオーディオ／ビデオストリームと関連した双方向サービスを出力するソースであってもよい。放送局２３０１０の一例としてＴＶ放送局が挙げられる。放送局２３０１０は、放送コンテンツ生産者や配給者であってもよい。放送局２３０１０は、放送ストリーム、オーディオ／ビデオコンテンツ、双方向データ、放送スケジュール、又はＡＭＴを伝達することもできる。
ＭＶＰＤ ２３０２０は、多重チャネルビデオプログラム流通業者（Ｍｕｌｔｉｐｒｏｇｒａｍ Ｖｉｄｅｏ Ｐｒｏｇｒａｍ Ｄｉｓｔｒｉｂｕｔｏｒ）の略語である。ＭＶＰＤ ２３０２０は、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者であってもよい。ＭＶＰＤ ２３０２０は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス（ＳＴＢ）に送る。
ＳＴＢ ２３０３０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを視聴者に視聴されるＴＶ受像機に送る。ＳＴＢは、非圧縮されたオーディオ／ビデオコンテンツを受信機２３０４０に送ることができる。ＳＴＢ ２３０３０は、本発明の一実施例に係る外部のデコーティング部であってもよい。
受信機２３０４０は、ＦＰクライアント２３０５０を含むことができる。ＦＰクライアント２３０５０は、受信機２２０４０の外部に位置してもよい。ここで、受信機２３０４０は、フィンガープリンティングができる受信機である。受信機２３０４０の構造については後述する。
ＦＰクライアント２３０５０は、当該用途のＡＰＩを用いて、ＦＰサーバー２３０９０から活性化トリガーを受けてそれらをメイン受信機コードに送ることができる。一般に、ＦＰクライアント２３０５０は受信機内に構成されるが、他の構成も可能である。ＦＰクライアント２３０５０は、非圧縮されたオーディオ／ビデオコンテンツから、フィンガープリントを抽出することができる。フィンガープリントについては後述する。
ＴＰＴサーバー２３０６０は、ＴＰＴのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機２３０４０は、抽出されたフィンガープリントをＦＰサーバー２３０９０に伝送する。フィンガープリントがシグネチャー抽出機２３０８０のシグネチャーとマッチングされると、受信機２３０４０は、一トリガー又は複数トリガーを応答として受信することができる。受信された一トリガー又は複数トリガーが上述の新しいｌｏｃａｔｏｒ＿ｐａｒｔを有したり、又は新しいバージョンのＴＰＴ又はアプリケーションパラメータテーブルが発見されると、受信機２３０４０はＴＰＴサーバー２３０６０に新しいＴＰＴ又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
コンテンツサーバー２３０７０は、双方向サービスを提供するために必要なアプリケーション及びＴＤＯを提供することができる。新しいアプリケーション又はＴＤＯが必要な場合、新しいアプリケーションは、ＴＰＴ又はアプリケーションパラメータテーブルにあるＵＲＬを用いてダウンロードすることができる。
シグネチャー抽出機２３０８０は、放送局２３０１０からメタデータを受信することができる。シグネチャー抽出機２３０８０は、受信されたメタデータからフレームのシグネチャーを抽出することができる。ＦＰサーバー２３０９０に伝送されたフィンガープリントがシグネチャー抽出機２３０８０のシグネチャーとマッチングされると、シグネチャー抽出機２３０８０は、シグネチャーと関連したメタデータをＦＰサーバー２３０９０に伝達することができる。
ＦＰサーバー２３０９０は、シグネチャー抽出機２３０８０とシグネチャーマッチング動作を行うことができる。ＦＰサーバー２３０９０は、シグネチャーを受信機２３０４０から受信されたフィンガープリントとマッチングさせることができる。シグネチャーがフィンガープリントとマッチングされると、ＦＰサーバー２３０９０は、シグネチャー抽出機２３０８０からシグネチャーと関連したメタデータを受信することができる。ＦＰサーバー２３０９０はメタデータを受信機２３０４０に伝送することができる。
フィンガープリンティング（ＦＰ）技法において、ＦＰクライアント２３０５０は、オーディオ又はビデオフレームからフィンガープリント（シグネチャーと呼ぶこともできる。）を抽出し、多重の放送局からの放送フレームに対するフィンガープリントデータベースに対してこのフィンガープリントを検査し、受信機２３０４０が必要とする情報を探すことができる。このような検査は、遠く離れたサーバーに対するシグネチャーによってなされてもよく、所望の情報を有する記録を受けることができ、一部の場合は、受信機２３０４０にダウンロードされたシグネチャーのデータベースに対して検査することによって検査がなされてもよい。ここで、遠く離れたサーバーは、ＦＰサーバー２３０９０であってもよい。
ウォーターマーキングとフィンガープリンティングは互いに区別される技術であるが、必ずしも互いに排他的なものではない。これらの両技術の組合せを用いることも考えることができる。自動コンテンツ認知（ａｕｔｏｍａｔｉｃ ｃｏｎｔｅｎｔ ｒｅｃｏｇｎｉｔｉｏｎ；ＡＣＲ）は、これらの両技術のいずれか一方を別途に指したり、又はこれらの両技術の組合せを指すために用いることができる。
受信機が放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる環境を“ＡＣＲ環境”と呼ぶ。
ＷＭの場合もＦＰの場合も、受信機は、トリガーを含む双方向サービスコンテンツを得るための出発点としてＵＲＬを用いることができる。
ＷＭ、ＦＰの両方の場合とも、インターネットを介して伝達されたトリガーの活性化タイムスタンプなどのように、当該チャネルに対して時間臨界的（ｔｉｍｅ ｃｒｉｔｉｃａｌ）イベントの放送側クロック（ｂｒｏａｄｃａｓｔ ｓｉｄｅ ｃｌｏｃｋ）に対するタイムスタンプの形態であってもよい。
放送局は、一般にアンテナからＴＶ信号を受ける受信機のために放送ストリームでの双方向サービスの直接伝達を支援でき、非圧縮されたオーディオ及びビデオを受ける受信機のために、前述した通り、インターネットを通した双方向サービスの伝達を支援するものの、インターネット接続を有することができると仮定する。しかし、放送局は、この２つの伝達メカニズムのいずれか一方のみ支援できる。
ウォーターマークがコード値のみを提供する場合、ウォーターマーキング技法のための代表的なアーキテクチャは、図２２及び図２３の２つのアーキテクチャの組合せのように見える。図２２のようにウォーターマーク挿入部が存在するようになるが、この挿入部は、受信機が必要とする情報ではなくコードを挿入する。また、図２３のＦＰサーバーと同じ役割を担うＷＭサーバーが存在する。受信機は、このサーバーにシグネチャーではなくコードを送り、これら受信機が必要とする情報を受ける。
双方向サービス接近について説明する。
双方向サービス接近についての説明は、直接実行モデル、ＡＣＲサーバーに独立的な活性化を有するＴＤＯモデル、ＡＣＲサーバーから受信された活性化を有するＴＤＯモデルについての説明を含む。モデルを示してはいないが、モデルは、説明に限定されず、設計者の意図によって変更されてもよい。
放送局選択とＡＣＲシステムの特性によってＡＣＲ環境にある受信機が双方向サービスに接近できる方法には、様々なものがある。双方向サービスモデルは、直接実行モデル又はＴＤＯモデルであり、ＴＤＯモデルの場合、活性化とトリガーは、ＡＣＲサーバーに独立して又はＡＣＲサーバーによって伝達することができる。
直接実行モデルについて説明する。
直接実行モデルを有する双方向サービスを含む仮想チャネルのためのＡＣＲ過程は、このチャネルを見ている受信機に、ｍｅｄｉａ＿ｔｉｍｅ（“ｍ＝”）項とｃｏｎｔｅｎｔ＿ｉｄ（“ｃ＝”）項を含む時間ベーストリガーに相応するものを提供することができる。これらのトリガーは、直接実行モデルを有する双方向サービスのためのトリガーと確認できる。
まず、受信機が新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するこのようなトリガーを受信すると、そのブラウザーに、トリガーのｌｏｃａｔｏｒ＿ｐａｒｔが指す宣言的客体（ＤＯ）をローディングすると考えることができる。一般に、ＤＯは、あらかじめ設置されていたり、あらかじめダウンロードされてキャッシュに格納されたりする。そうでなければ、受信機がＨＴＴＰ ＧＥＴ要求を用いてＤＯをダウンロードすると考えることもできる。
その後、ＤＯは、適宜のバックエンドサーバーと連絡して、バックエンドサーバーが指示する双方向サービスを提供することができる。
受信機は、ＡＣＲサーバーから新しいｌｏｃａｔｏｒ＿ｐａｒｔを有する及び／又はＴＤＯモデルを有する双方向サービスのためのトリガーとして確認されるトリガーを得るまで（これらのいずれか一つの場合は、一般的にチャネルの変更を指示する）取得された初期トリガーと続くトリガーをＤＯが利用できるようにするものと考えることができる。
以下、ＡＣＲサーバーに独立した活性化を有するＴＤＯモデルについて説明する。
ＴＤＯモデルを有する双方向サービスを含むことができ、ＡＣＲサーバーと独立してイベント活性化を提供する仮想チャネルのためのＡＣＲ過程は、ｍｅｄｉａ＿ｔｉｍｅ（“ｍ＝”）項を含み得る時間ベーストリガーに相応するものを、このチャネルを見ている受信機に提供することができる。これらのトリガーは、ＴＤＯモデルを有する双方向サービスのためのトリガーと確認できる。
まず、受信機が新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するこのようなトリガーを受信すると、当該トリガーのｌｏｃａｔｏｒ＿ｐａｒｔが指し得るＴＰＴサーバーで現在のＴＤＯパラメータテーブル（ＴＰＴ）を検索し、このトリガー及び続くトリガー内のメディア時間を用いて、ＡＣＲ過程によって識別されうるオーディオ又はビデオフレームに対してイベント活性化のための基準時間ベースを設定すると考えることができる。
ＡＭＴ（活性化メッセージテーブル）がＴＰＴと併せて伝達される場合、受信機は、トリガー内のメディア時間によって設定された時間ベースを基準に正確な時間にイベントを活性化させるためにこのテーブル内のそれぞれの活性化エレメントを使用すると考えることができる。（これらのイベントは、ＴＤＯＤＭＬローディング及び実行、ＴＤＯが同期化される特定動作を行うようにすること、ＴＤＯを中止させること、などを含むことができる。）。
ＴＰＴにＬｉｖｅＴｒｉｇｇｅｒエレメントが含まれた場合、受信機はＬｉｖｅＴｒｉｇｇｅｒエレメントでシグナリングされたポーリング方法を用いてＬｉｖｅＴｒｉｇｇｅｒエレメント内のＵＲＬによって識別されたライブトリガーサーバーから活性化トリガーを検索し、この活性化トリガーを用いて、このトリガー内のメディア時間項によって設定された時間ベースを基準に、正確な時間にイベントを活性化させることができる。
ＡＭＴとライブトリガーサーバーの両方とも同一のサービスのために用いることができるが、前者は静的活性化を提供し、後者は動的活性化を提供する。これと違い、セグメントの全ての活性化が静的活性化である場合は、ＡＭＴのみを用いてもよく、ライブトリガーサーバーのみを用いて静的活性化及び動的活性化の両方を伝達してもよい。
ＡＣＲサーバーから受信された活性化を有するＴＤＯモデルについて説明する。
ＴＤＯ双方向サービスモデルのための活性化トリガーが、ＡＣＲ環境において、別途のトリガーサーバー無しでどのように伝達されるかについて記述する。
フィンガープリンティングＡＣＲシステムは、ＡＣＲサーバーを含むことができる。受信機は、ＡＣＲサーバーにフレームシグネチャーを送ることができ、ＡＣＲサーバーは、当該シグネチャーが示すフレームを識別して、再び受信機で必要とする情報を送ることができる。ウォーターマークが、受信機で必要とする情報を得るためにＡＣＲサーバーに伝達され得るコードのみで構成された場合、ウォーターマーキングＡＣＲシステムはＡＣＲサーバーを含むことができる。ウォーターマーク自体が受信機で必要とする情報を含む場合、ウォーターマーキングＡＣＲシステムはＡＣＲサーバーを含まなくてもよい。ＡＣＲサーバーを含むＡＣＲシステムでは、サーバーと受信機間の通信に互いに異なる２のモデル、すなわち、要求／応答モデルとイベント主導型モデルを用いることができる。
放送局でＴＤＯ双方向モデル（ＴＤＯ ｉｎｔｅｒａｃｔｉｏｎ ｍｏｄｅｌ）を支援していると仮定する。
要求／応答モデルを用いるＡＣＲサーバー、イベント主導型モデルを用いるＡＣＲサーバー、情報を直接挿入するウォーターマーキングＡＣＲシステムのような３つの場合を想定することができる。
ＡＣＲサーバーがある場合、ＡＣＲ方式は、フィンガープリンティングであってもよく、この場合、受信機は一種のオーディオ又はビデオフレームのシグネチャー（又は、フィンガープリント）を算出し、識別のためにそれらをＡＣＲサーバーに提出する。又は、ＡＣＲ方式がウォーターマーキングであってもよく、この場合、受信機はオーディオ又はビデオフレームからウォーターマーク形態のコードを抽出し、これらのコードを識別のためにＡＣＲサーバーに提出する。
便宜のためにフィンガープリンティングシグネチャーの用語を説明する。ただし、システムはウォーターマーキングコードの場合と同一の方式で動作し、本発明はフィンガープリンティングに限定されない。
図２４は要求／応答ＡＣＲ場合の静的活性化の一実施例を示す図である。
ＡＣＲサーバーが要求／応答モデルを使用する場合について説明する。
要求／応答ＡＣＲモデルで、受信機は周期的に（例えば、５秒ごとに（これは、例示に過ぎず、設計者によって変更されてもよい））コンテンツのシグネチャーを生成し、シグネチャーを含む要求をＡＣＲサーバーに送ると考えることができる。ＡＣＲサーバーは、受信機から要求を受けると応答を送ることができる。要求／応答インスタンス間には通信セッションが開放状態に維持されない。このモデルでは、ＡＣＲサーバーが受信機にメッセージを開始することが不可能であってもよい。
この要求／応答モデルを用い、受信機に活性化トリガーを伝達するＡＣＲサーバーの場合、ＡＣＲサーバーからの各応答は、ヌル（Ｎｕｌｌ）、時間ベーストリガー又は活性化トリガーのうち一つであってもよい。
ヌル応答は、シグネチャーが認識されないことを示したり、又は、（ＡＣＲインジェストモジュール（ＡＣＲ Ｉｎｇｅｓｔ Ｍｏｄｕｌｅ）がフレームに対するシグネチャーを双方向サービスのないプログラムセグメントに含める場合に）シグネチャーは関連している双方向サービスのないセグメントに属するフレームを意味することを示すことができる。ＡＣＲインジェストモジュールについては後述する。
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用いてメディア時間クロック（ｍｅｄｉａ−ｔｉｍｅ ｃｌｏｃｋ）を維持すると考えることができる。
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間は、トリガー内の“ｔ＝”項によって示される。
受信機は、新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するトリガーを受ける度に、以前のＴＰＴと共に伝達されたＵＲＬＬｉｓｔを用いて新しいＴＰＴが検索されていないと、それを直ちにダウンロードすると考えることができる。
受信機は、活性化トリガーを受ける度に、メディア時間クロックに対して当該トリガー内の“ｔ＝”項によって示された時間に、当該イベントを活性化させると考えることができる。
図２４は、静的活性化に対して（ＡＣＲシステムが予定よりも十分に早く動的活性化について知っている場合は動的活性化に対して）、この方式がどのように作用するかを示している。
図２４で、受信機は、ＡＣＲサーバーでメディア時間ＭＴ１、ＭＴ２及びＭＴ３を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間ＭＴ１を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。メディア時間ＭＴ２を有するフレームの場合、静的活性化がメディア時間Ｍｔａに予定され、受信機は“ｔ＝ＭＴａ”項を有する活性化トリガーを含む応答を受ける。メディア時間ＭＴ３を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。
受信機が同一のイベント活性化に対して一つ以上の活性化トリガーを受信する場合が発生しうる。しかし、これらのそれぞれに対するメディア時間は同一であるため、受信機はそれらの活性化トリガーが重複していると把握し、これらのうち一つのみを適用することができる。
図２５は、要求／応答ＡＣＲケースにおける静的活性化の一実施例を示す図である。
ＡＣＲサーバーが要求／応答モデルを使用する場合について説明する。
図２５で、受信機は、ローカルクロック（ｌｏｃａｌ ｃｌｏｃｋ）時間ＬＣ１、ＬＣ２、ＬＣ３で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間ＬＣ１に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ１であると判断でき、受信機は、ｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。ローカルクロック時間ＬＣ２に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ２であると判断でき、ＡＣＲサーバーは、メディア時間Ｍｔａに静的活性化が予定されていることを知っているため、ＡＣＲサーバーは、この活性化のための活性化時間ＭｔａがＭＴ２以降の＜オフセット＞時間であることを意味する“ｄ＝＜ｏｆｆｓｅｔ＞”項を有する活性化トリガーを含む応答を伝達する。すると、受信機は＜オフセット＞を時間ＬＣ２に追加し、当該イベントを活性化させるべきローカル時間であるＬｃａを得る。
図２６は、要求／応答ＡＣＲケースにおける動的活性化の一実施例を示す図である。
以下、要求／応答ＡＣＲ場合において動的活性化が起きる場合について説明する。
あらかじめ受信機にトリガーを送るには手遅れになるまでずっと、ＡＣＲシステムでイベント活性化について知っていない状況での動的活性化の場合には、ＡＣＲサーバーが次の要求があるまで待ってから活性化トリガーを送らなければならない。 このような場合を図２６に示す。そのため、一つの要求区間だけ動的活性化が遅延されうる。
図２６で、受信機は、ＡＣＲサーバーでメディア時間ＭＴ１、ＭＴ２及びＭＴ３を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間ＭＴ１及びＭＴ２を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。活性化時間Ｍｔａを有する動的活性化がメディア時間ＭＴａで又は直前に登場する場合、ＡＣＲサーバーは、メディア時間ＭＴ３を有するフレームに対して発生する受信機からの次の要求があるまで、受信機にそれを通知することができない。このとき、ＡＣＲサーバー応答は、活性化時間ＭＴａ（やや去の時間）を有する活性化トリガーを含む。このような状況で、受信機は、その応答が到達すると直ちに当該活性化トリガーを適用すると考えることができる。
ここで、受信機は、同一のイベント活性化に対して一つ以上の活性化トリガーを受信することが可能である。しかし、それらのそれぞれのメディア時間は同一であるため、受信機はそれらが重複したと把握し、それらのうち一つのみを適用できる。
図２７は、要求／応答ＡＣＲケースにおける動的活性化の一実施例を示す図である。
要求／応答ＡＣＲケースにおいて動的活性化が起きる場合について説明する。
図２７で、受信機は、ローカルクロック時間ＬＣ１、ＬＣ２、ＬＣ３で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間ＬＣ１に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ１であると判断でき、受信機はｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。ローカルクロック時間ＬＣ２に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ２であると判断でき、ＡＣＲサーバーは、メディア時間Ｍｔａに動的活性化が登場する予定であることを知っておらず、受信機は、ｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。動的活性化がメディア時間Ｍｔａに登場すると、ＡＣＲサーバーは、ローカル時間ＬＣ３に発生する受信機からの次の要求があるまで、受信機にそれに対して通知することができない。このとき、ＡＣＲサーバー応答は、負の＜オフセット＞値を有する活性化トリガー又は“今施行”の活性化トリガーを含むことができる。
イベント主導型モデルを使用するＡＣＲサーバーについて説明する。
イベント主導型ＡＣＲモデルで、受信機はＡＣＲサーバーに対する永久的な接続を開始し、周期的に（例えば、５秒ごとに）コンテンツのシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ＡＣＲサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ＡＣＲサーバーはいつでもクライアントに対するメッセージを開始することができる。
該イベント主導型モデルを使用し、活性化を受信機に伝達するＡＣＲサーバーに対して、次の規則はＡＣＲサーバーからのメッセージを申し込むことができる。
第一に、ＡＣＲサーバーは、新しいセグメントに対応する受信機からシグネチャーを受信すると、単に受信機が関連のＴＰＴを取得できるようにするために、直ちに時間ベーストリガーを受信機に送ることができる。
第二に、イベントが活性化される予定である度に、ＡＣＲサーバーは活性化トリガーを受信機に送ることができる。可能ならば、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる（これは、要求／応答モデルにおける動作と略同様である）。ＡＣＲサーバーは、活性化をあまりにも遅く知って活性化トリガーを事前に早く送ることができなくても（これは、動的イベント活性化の場合に発生しうる）、活性化トリガーを可能な限り早く送ることができる。後者の場合に、メッセージ遅延によってクライアントは活性化時期よりもやや遅れてメッセージを受けることができ、この場合、受信機はメッセージを受け次第イベントを活性化すると考えることができる。
受信機は、新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するトリガーを受信する度に、以前のＴＰＴと一緒に伝達されるＵＲＬＬｉｓｔを用いて既に検索していない限り、新しいＴＰＴを直ちにダウンロードすると考えることができる。
情報を直接挿入するウォーターマーキングＡＣＲシステムについて説明する。ウォーターマーキングＡＣＲシステムを示してはいないが、ウォーターマーキングＡＣＲシステムは、次の説明に限定されず、設計者によって変更されてもよい。
受信機が必要とする情報を直接挿入するウォーターマーキングシステムの場合、フレームと関連しているウォーターマークは、このフレームに対して要求／応答ＡＣＲサーバーがリターンすることについて、前述したのと同じ規則を、次のように従うことができる。要求／応答ＡＣＲサーバーは、ヌル、時間ベーストリガー、活性化トリガーのうち一つをリターンすることができる。
ヌル応答は、シグネチャーが認識されないことを示したり、又は（ＡＣＲインジェストモジュールがフレームに対するシグネチャーを双方向サービスのないプログラムセグメントに含める場合）シグネチャーは関連した双方向サービスのないセグメントに属するフレームを意味することを示すことができる。
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用い、メディア時間クロックを維持すると考えることができる。
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間はトリガー内の“ｔ＝”項によって示される。
ＡＣＲサーバーが必要とされないように、受信機が必要とする情報をウォーターマークに直接含めて伝達するウォーターマーキングＡＣＲシステムの場合、インジェストモジュールは、各フレームと関連付けるトリガーを決定し、このトリガーをデータベース内の該当フレームと関連付けずに当該フレームのためのウォーターマークに含める要求／応答サーバーモデルについて、前述したのと同じ規則に従うことができる。インジェストモジュールとデータベースについては後述する。
独立型ＮＲＴサービスの支援について説明する。これを示してはいないが、本発明は、次の説明に限定されず、設計者によって変更されてもよい。
ＡＣＲ環境にある受信機が独立型ＮＲＴサービスを受けるために、放送局は、ＮＲＴサービスへのインターネット接続を支援する必要があり、受信機は、それらのサービスに対するＳＭＴとＮＲＴ−ＩＴインスタンスを得る必要がありうる。
インターネットを介してＰＳＩＰテーブルとＮＲＴテーブルを得るための質疑（ｑｕｅｒｙ）プロトコルについて説明する。
放送局は、特定放送ストリームに対してこのプロトコルを支援し、このとき、この放送ストリームに対する放送局のシグナリングサーバーのＵＲＬを知っている受信機は、次の段階を行う。
第一に、受信機は、指定された未来時間区間（例：次の時間）に当該放送ストリームのためのテーブルの“基本ＮＲＴ集合”に対して質疑を発生させることができる。
第二に、上記の段階で各独立型ＮＲＴ仮想チャネルに対するＳＭＴ及びＩＬＴ、並びに指定された時間区間を含むＮＲＴ−ＩＴ及びＴＦＴインスタンスを生成する。
受信機が放送ストリームに対するシグナリングサーバーのＵＲＬを発見できる一つの方法は、この放送ストリーム内の双方向サービスセグメントのプロバイダが、ＴＰＴと併せて伝達されたＵＲＬＬｉｓｔエレメント内でシグナリングサーバーＵＲＬを提供するように選択することができる。
受信機が放送ストリームに対するシグナリングサーバーのＵＲＬを発見できるもう一つの方法は、事前設定によるものであってもよい。ＤＴＶ受信機メーカーが、特定放送領域に到達するＡＣＲサーバーをどのように探すかを知るようにＤＴＶ受信機をあらかじめ設定するのと同じ方式で、ＤＴＶ受信機メーカーが、特定放送領域に到達する“ＮＲＴ発見サーバー”をどのように探すかを知るようにＤＴＶ受信機をあらかじめ設定することができる。このようなＮＲＴ発見サーバーは、各放送ストリームに対するシグナリングサーバーＵＲＬと共に、独立型ＮＲＴサービスを含む放送ストリーム目録を受信機に提供することができる。
図２８は、ＡＣＲサーバー活性化のためのアーキテクチャの一実施例を示す図である。
あるＡＣＲシステムはＡＣＲサーバーを含み、あるＡＣＲシステムは含まない。フィンガープリンティングＡＣＲシステムでは、受信機はフレームシグネチャーを算出してＡＣＲサーバーに送ることができ、ＡＣＲサーバーは、受信機で必要とする情報を送る。したがって、フィンガープリンティングＡＣＲシステムは、ＡＣＲサーバーを含む。ウォーターマーキングＡＣＲシステムでは、ウォーターマークにフレームを固有に識別するコードのみが含まれてもよく、又は受信機が必要とする全体情報が含まれてもよい。ウォーターマークがコードのみを含む場合は、受信機がコードを抽出し、それらをＡＣＲサーバーに送ることができ、ＡＣＲサーバーは、受信機で必要とする情報を送る。ウォーターマークが全体情報を含む場合は、受信機が自分に必要な情報をウォーターマークから直接抽出でき、ＡＣＲサーバーが必要でない。
ＡＣＲサーバーを含むＡＣＲシステムでは、ＡＣＲサーバーと受信機間の通信のために２種類の互いに異なるモデル、すなわち、要求／応答モデルとイベント主導型モデルを共通に使用することができる。
要求／応答ＡＣＲサーバーモデルにおいて、受信機は周期的に（例えば、５秒ごとに）コンテンツのシグネチャーを算出したりコンテンツからコードを抽出し、このシグネチャーやコードが含まれた要求をＡＣＲサーバーに送ると考えることができる。ＡＣＲサーバーは受信機から要求を受信すると、応答をリターンすることができる。要求／応答インスタンス間には通信セッションが開いた状態で維持されない。このモデルでは、ＡＣＲサーバーが受信機にメッセージを開始することが実行可能でなくてもよい。
処理しているチャネルの放送局がＴＤＯ双方向モデルを支援すると仮定する。
２種類の一般的な類型のイベント活性化、すなわち、セグメントの放送が開始される前に活性化時間が知らされる静的活性化と、セグメントの放送中に活性化時間が動的に決定される動的活性化がありうる。あらかじめ記録されたセグメントでは、全てのイベント活性化が静的であってもよい。ライブショーを放送するセグメントでは、イベント活性化の一部又は全てが動的であってもよい。静的活性化は活性化トリガーの形態で受信機に伝達されてもよいが、一般的に活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ、ＡＭＴ）に記載される。動的活性化は、これらのタイミングがＡＭＴの発生時点に知らされないため、活性化トリガーの形態で伝達されてもよい。
図２８は、ＡＣＲサーバーを使用するＡＣＲシステムを支援するアーキテクチャを示している。これは論理構成図であって、実行アーキテクチャではない。例えば、ＡＣＲインジェストモジュールは、放送ソースと同じ位置にあってもよく、別途の位置にあってもよい。
ＡＣＲサーバーを使用するＡＣＲシステムを支援するアーキテクチャにおいて、アーキテクチャは、放送ソース２８０１０、ＡＣＲインジェストモジュール２８０２０、ＭＶＰＤ ２８０３０、ＳＴＢ ２８０４０、受信機２８０５０、ＡＣＲクライアント２８０６０、ＡＣＲ設定サーバー２８０７０、ＡＣＲサーバー２８０８０及びデータベース２８０９０で構成することができる。
放送ソース２８０１０は、Ａ／Ｖストリーム及び関連した双方向サービスが送出される地点であって、例えば、ネットワーク分配地点又はＴＶ放送局であってもよい。
ＡＣＲインジェストモジュール２８０２０は、フィンガープリンティングＡＣＲシステムの場合、フレームのシグネチャー（フィンガープリント）を算出したり、コードに基づくウォーターマーキングＡＣＲシステムの場合、コードからなるウォーターマークをフレームに挿入することができる。このモジュールは、他のメタデータと併せてシグネチャー又はコードに関連している各フレームのｍｅｄｉａ＿ｔｉｍｅをデータベース２８０９０に保存することができる。ＡＣＲインジェストモジュール２８０２０は、一つの放送ストリーム、全体放送ストリーム、又は複数の放送ストリーム又はこれらの組合せにおいて単一チャネルを扱うことができる。そのために、ＡＣＲインジェストモジュール２８０２０は、双方向サービスを含むプログラムセグメントのためのフレームを処理すると仮定する。しかし、全てのフレームが処理されるが、双方向サービスを有するセグメントの一部でないものは、これらが双方向サービスを有するセグメントの一部でないことを示す指示子がデータベース２８０９０エントリにあるＡＣＲシステムも可能である。
ＭＶＰＤ ２８０３０は一般に、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者である。ＭＶＰＤ ２８０３０は、ウォーターマーキングＡＣＲシステムの場合、ＡＣＲインジェストモジュール２８０２０によって挿入されたウォーターマークと共に放送ストリームをいずれかの方式で放送ソースから受信することができる。このようなシステムはたびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のＳＴＢ ２８０４０に送る。
ＳＴＢ ２８０４０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを、視聴者に視聴されるＴＶ受像機に送る。双方向サービストリガーを含むＤＴＶクローズドキャプションサービス＃６は、ＴＶ受像機が利用できないと仮定する。
受信機２８０５０は、ＡＣＲクライアント２８０６０を含むことができる。ＡＣＲクライアント２８０６０は、受信機２８０５０の外部に位置してもよい。受信機２８０５０の構造については後述する。
受信機２８０５０内のＡＣＲクライアント２８０６０は、当該用途のＡＰＩを用いてＡＣＲサーバー２８０８０から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、ＡＣＲクライアント２８０６０は受信機２８０５０内に構成されるが、他の構成図可能である。
ＡＣＲ設定サーバー２８０７０は、ＡＣＲクライアント２８０６０が適切なＡＣＲサーバー２８０８０の位置を決定する方式を提供することができる。この発見過程は他の方式で得ることもできる。
ＡＣＲサーバー２８０８０は、受信機からシグネチャー又はコードを受け、適切な時点に活性化トリガーをリターンすることができる。
データベース２８０９０は、ＡＣＲサーバー２８０８０の使用のためにオーディオ又はビデオフレームのいずれか一方（又は、両方）に関する情報が格納される一種のデータ格納所であって、厳密にはデータベースでなくてもよい。
ウォーターマーク内の情報の直接伝達を用いるＡＣＲシステムのアーキテクチャは、データベースとＡＣＲサーバーを有しなくてもよい。ＡＣＲインジェストモジュールは、情報をフレームの識別子及びこれらと関連している情報を含むデータベース記録に挿入する代わりに、ウォーターマークの形態で放送ストリーム内のフレームに直接挿入してもよい。その後、受信機はその情報をＡＣＲサーバーから取得せず、放送内のフレームから抽出することができる。
以下、要求／応答ＡＣＲサーバーを介した活性化トリガーの伝達について段階別に説明する。
このＡＣＲサーバーの挙動を具現する効果的な方法は、以下に説明する過程に従うものであるが、この過程の動作の数は、上記のアーキテクチャダイヤグラムである図２８内の数字に対応する。
１）双方向サービスセグメントとＡＭＴ又は各セグメントに相当するものに対する放送スケジュールを、セグメントが放送される前にあらかじめＡＣＲインジェストモジュールに伝達することができる。放送スケジュールは、セグメントＩＤ、関連する双方向サービスを含み得る各セグメントのＧＰＳ開始時点及びＧＰＳ終了時点を含むことができる。放送スケジュールに最後の瞬間の変化がある場合、ＡＣＲインジェストモジュールにそれらの変化が直ちに通知されてもよい。放送スケジュールは、各セグメントに対するＴＰＴのバージョンナンバーも含むことができ、ＴＰＴバージョンのスケジュールされていない変更は、実時間でＡＣＲインジェストモジュールに通知され、必要時に“ｖｅｒｓｉｏｎ”（“ｖ＝”）項をトリガーに挿入することができる。インジェストモジュールは、各セグメントの開始時に特定区間（多数の受信機が新しいＴＰＴを同時に要求する可能性がある時）のように適切な時間に“ｓｐｒｅａｄ”（“ｓ＝”）項をトリガーに挿入するように構成されてもよい。
２）動的活性化が存在する場合、動的活性化のソースからＡＣＲインジェストモジュールにリンクが設定されてもよい。
３）放送ストリームはＡＣＲインジェストモジュールに送信されてもよい。
４）ＡＣＲインジェストモジュールは、フレームからシグネチャーを抽出したり（フィンガープリントＡＣＲシステムの場合）、関連している双方向サービスを持つセグメントに含まれた全てのフレームに対してコードをフレームに挿入（ウォーターマークＡＣＲシステムの場合）することができる。（ＡＣＲインジェストモジュールは、ＧＰＳクロックと放送スケジュール内のセグメントの開始時間及び終了時間を用いてフレームがそのようなセグメントにあるかを判断できる。）そのような各フレームに対してＡＣＲインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連しているコードを含み得るデータベースに記録を挿入することができる。トリガーが挿入されることに関する規則は、過程上、このような動作リストの終端に記述される。
５）放送ストリームは、ＭＶＰＤに続いてもよい。
６）ＭＶＰＤ加入者の位置にあるＳＴＢに放送ストリームを送信できる。（一般に、双方向コンテンツはまず除く。）
７）ＳＴＢは、Ａ／Ｖをデコーティングして非圧縮されたＡ／ＶをＤＴＶ受信機に送ることができる。
８）まず、受信機がＯＮになると、受信機は自身の位置をＡＣＲ設定サーバーに送ることができる。（ＡＣＲ設定サーバーのＵＲＬは、この受信機内に構成されてもよい。）
９）ＡＣＲ設定サーバーは、受信機が使用するＡＣＲサーバーのＵＲＬを送ることができる。
１０）受信機内のＡＣＲクライアントは、フィンガープリントシグネチャー又はウォーターマークコードを抽出し、それらをＡＣＲサーバーに送ることができる。
１１）シグネチャー又はコードを受信したＡＣＲサーバーは、データベース内でシグネチャー又はコードのマッチングを試みることができる。
１２）シグネチャー又はコードがデータベースのいずれのシグネチャー又はコードともマッチングされないと、ＡＣＲサーバーは“ｎｏ ｍａｔｃｈ”指示子を受けることができる。シグネチャー又はコードがデータベース内のシグネチャー又はコードとマッチングされると、ＡＣＲサーバーは、マッチングされるシグネチャー又はコードを有するフレームに対する記録を受けることができる。後者の場合、データベース内の記録は時間ベーストリガーを含むことができ、及び／又はＡＣＲインジェストモジュールによってフレームの記録に何が挿入されたかによって一つ以上の活性化トリガーを含むことができる。
１３）ＡＣＲサーバーがデータベースから“ｎｏ ｍａｔｃｈ”指示子を受けると、ＡＣＲクライアントにヌル応答をリターンすることができる。そうでない場合、ＡＣＲサーバーは、得られたたトリガー又はトリガーをＡＣＲクライアントにリターンすることができる。
下記の規則を用いて、ＡＣＲインジェストモジュールがどの一つ又は複数のトリガーをデータベース内の各フレーム記録に挿入するかを判断できる。
図２９は、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
受信機内の個別ＡＣＲクライアントによって使われた要求区間の長さ上に、ある上限（ｕｐｐｅｒ ｂｏｕｎｄ）Ｌ１が存在すると仮定できる。（ＡＣＲクライアントが実際にこの上限内で動作する限り、この境界を知っているかは重要でない。）Ｌ２をフレームが受信機に到達した時点から計算して、一般のＡＣＲクライアントがシグネチャーを算出したり、このフレームと関連しているウォーターマークを抽出するためにかかる時間の長さとしよう。メッセージがＡＣＲクライアントからＡＣＲサーバーに送られてから帰ってくるためにかかる一般的な往復移動時間をＬ３としよう。Ｍ＝Ｌ１＋Ｌ２＋Ｌ３とする。（ややより大きいＭの値が用いられもよい。−ややより大きい値の長所は、活性化トリガーに反応する上で若干の余分の時間を得るということである。短所は、受信機が同一のイベント活性化に対して複数の活性化トリガーを受ける可能性がややより高いということである。受信機は、後述するように、これらが重複することを感知し、活性化を１回のみ適用できるため、この短所は大きく問題にならない。）
ＡＣＲインジェストモジュールは、次の３つの条件のうち少なくとも一つが成立しないと、時間ベーストリガーのみをフレームと関連している記録に挿入することができる。
（ａ）活性化エレメントは、フレームのｍｅｄｉａ＿ｔｉｍｅが活性化エレメントのｓｔａｒｔＴｉｍｅ前の時間長さＭから始まって活性化エレメントのｅｎｄＴｉｍｅで終わる時間区間にあるようにＡＭＴに存在する。（活性化がｅｎｄＴｉｍｅを有しないと、ｅｎｄＴｉｍｅはｓｔａｒｔＴｉｍｅと同一のものと見なされる。）
（ｂ）トリガーの活性化時間（“ｔ＝＜ｅｖｅｎｔ＿ｔｉｍｅ＞”）直前の時間長さＭの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。
（ｃ）トリガーの活性化時間直前の時間長さＭの区間の開始よりも遅れて動的活性化トリガーがインジェストモジュールによって受信されており、フレームのｍｅｄｉａ＿ｔｉｍｅはトリガーの受信の直後の時間長さＬ１の区間に存在する。
これらの条件（ａ）、（ｂ）及び（ｃ）のいずれか一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する“ｅ＝”項とＡＭＴ内の活性化エレメントのｓｔａｒｔＴｉｍｅを指示したり（条件（ａ）の場合）、動的トリガーのｅｖｅｎｔ＿ｔｉｍｅを指示する（条件（ｂ））“ｔ＝”項と共に記録に含まれうる。トリガーはバージョン（“ｖ＝”）項も含むことができる。
もちろん、（ａ）の場合、ｓｔａｒｔＴｉｍｅからｅｎｄＴｉｍｅまでの区間を通じて続けて活性化トリガーをフレームと関連付ける理由は、この区間を通じてチャネルに参加する受信機をある程度受容するためである。
この接近法は、ＡＣＲサーバー側に追加的な知能を要求しないという点に留意されたい。このサーバーは、単純にデータベースで発見する情報をＡＣＲクライアントにリターンする。全ての知能はＡＣＲインジェストモジュールに存在できる。しかも、ＡＣＲインジェストモジュールが行うべき演算が非常に簡単でありうる。
この方式を用いると、受信機で同一のイベント活性化に対して一つ以上の活性化トリガー（互いに異なるフレームと関連しているトリガー）を受信することが可能である。しかし、受信機は、“ｔ＝”値から、それらのトリガーがいずれも同一の活性化時間を有することがわかるため、受信機はそれらが重複すると判断し、イベントを１回のみ活性化させることができる。
上記の場合のうち二つの場合に、活性化トリガー内の“ｔ＝”項は、関連しているフレームのｍｅｄｉａ＿ｔｉｍｅより早いｅｖｅｎｔ＿ｔｉｍｅを有することができる。（ａ）の状況で、活性化エレメントのｅｎｄＴｉｍｅがｓｔａｒｔＴｉｍｅよりも非常に遅いと、受信機は一般的にｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅの間の区間を通じて複数の活性化トリガーを受けることができ、これらはいずれも活性化時間としてｓｔａｒｔＴｉｍｅを有することができる。（ｃ）の状況では、活性化のための活性化トリガーがあまりにも遅くフレーム記録に挿入され、受信機が受ける活性化トリガーが要求に対する応答として、活性化時間以降のｍｅｄｉａ＿ｔｉｍｅを有するフレームに対するシグネチャーと共にくることがある。受信機が、関連しているフレームのｍｅｄｉａ＿ｔｉｍｅよりも早いｅｖｅｎｔ＿ｔｉｍｅを有する活性化トリガーを受けると、このトリガーが既に確認して当該イベントの活性化のために使用した活性化トリガーと同じものと認識しない場合、当該イベントを直ちに活性化すると考えることができる。
フレームのｍｅｄｉａ＿ｔｉｍｅがｅｖｅｎｔ＿ａｃｔｉｖａｔｉｏｎ ｔｉｍｅよりも遅い場合に“今施行”トリガーではなく過去のｅｖｅｎｔ＿ｔｉｍｅ値を用いる目的は、受信機がこのような“ａｆｔｅｒ ｔｈｅ ｆａｃｔ”活性化トリガーを一つ以上受けることができるためである。“ｔ＝”値は、受信機でこれらのトリガーがいずれも同一の活性化時間を有すると判断し、当該イベントを１回のみ活性化させ得るようにする。
図２９は、ＡＭＴ内の活性化エレメントにｅｎｄＴｉｍｅ属性がない状況（ａ）と状況（ｂ）を説明する。
図２９は、ＡＭＴ内の活性化エレメントがｅｎｄＴｉｍｅを有しないとき、上記の動作（４）での状況（ａ）の一例を示している。これは、ＡＣＲインジェストモジュールに活性化時間よりも少なくてもＭ時間単位以前に動的活性化トリガーが送られる上記の段階（４）での状況（ｂ）の例であってもよい。
図２９は、タイムライン（ｔｉｍｅｌｉｎｅ）上にイベント活性化時間とこれよりも先行する長さＬ１、Ｌ２及びＬ３の区間を含む長さＭの区間を示している。タイムラインの下の垂直矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したり、イベント活性化時間後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さＭの区間内の各フレームは、データベースにおいて同図の下における２つの例（ｆ１、ｆ２）のような活性化トリガーと関連している。各フレームに対する“ｔ＝”項は、ｍｅｄｉａ＿ｔｉｍｅに対するイベント活性化時間を示すことができる。（丸囲みのｆ１、ｆ２で表示されている。）
丸囲みの４つの垂直矢印は、一般の受信機が要求を送る時の例示である。この例で、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるようになるが、これらのトリガーは同一のイベント活性化時間を有するため、受信機はこれらを同一のものと認識し、最初のトリガーのみを適用する。受信機の要求間の間隔がＬ１未満であるため、受信機は図示のＬ１区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してＡＣＲサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例で、受信機が受ける一番目の活性化トリガーはあらかじめ伝達されるが、受信機が受ける二番目の活性化トリガーは、かろうじて間に合って到達する（このトリガーは重複トリガーである）。
図３０は、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
以下、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーを説明する。これは、上記の図２９に関する説明に似ている。
図３０は、ＡＭＴ内の活性化エレメントがｅｎｄＴｉｍｅを有しない場合に、上の動作（４）で状況（ａ）の例を示している。これは、ＡＣＲインジェストモジュールに活性化時間よりも少なくてもＭ時間単位以前に動的活性化トリガーが送られる上の段階（４）で状況（ｂ）の例である。
図３０は、タイムライン（ｔｉｍｅｌｉｎｅ）上にイベント活性化時間とこれよりも先行する長さＬ１、Ｌ２及びＬ３の区間を含む長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーと関連している。長さＭの区間内の各フレームは、データベースで同図の下における２つの例と同一の活性化トリガーと関連している。各フレームに対する”ｄ＝”項は、このフレームとイベント活性化時間との時間の長さを示すことができる。（丸囲みのｆ１、ｆ２で表示されている）。
丸囲みの４つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この例で、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるが、＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えて算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。受信機要求間の間隔がＬ１未満であるため、受信機は図示のＬ１区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してＡＣＲサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例で、受信機で受信された二番目の活性化トリガーは、活性化時間以降に到達する。
図３１は、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
図３１は、ＡＭＴ内の活性化エレメントがｓｔａｒｔＴｉｍｅの他、ｅｎｄＴｉｍｅも持つ場合に、上の動作（４）で状況（ａ）の例を示している。
同図は、タイムライン上にイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ、及びｓｔａｒｔＴｉｍｅよりも先行する長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化のｅｎｄＴｉｍｅ後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さＭの区間内又はイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ間の各フレームは、データベースで同図の下における３つの例で示す形態で関連している活性化トリガーを有する。各フレームに対する“ｔ＝”項は、ｍｅｄｉａ＿ｔｉｍｅに対するイベント活性化時間を示すことができる。（丸囲みのｆ１、ｆ２、ｆ３で表示されている。）
丸囲みの３つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して３つの活性化トリガーを受けるが、活性化時間が同一であるため、受信機はそれらを同一のものと認識し、最初のトリガーのみを適用する。
もちろん、同図における最初の２つの活性化トリガーは、ｓｔａｒｔＴｉｍｅ以降にチャネルに参加して最初の要求と併せてフレームｆ３のシグネチャーを送る受信機にとっては認知できない。
図３２は、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
以下、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーを説明する。
図３２は、ＡＭＴ内の活性化エレメントがｓｔａｒｔＴｉｍｅの他、ｅｎｄＴｉｍｅも有する場合に上の動作（４）での状況（ａ）の例を示している。
同図は、タイムライン上にイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ、及びｓｔａｒｔＴｉｍｅよりも先行する長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーと関連している。長さＭの区間内の各フレームは、データベースで同図の下における２例で示す形態の活性化トリガーを有する。各フレームに対する“ｄ＝”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。（丸囲みの垂直矢印で示されている）。
丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して３つの活性化トリガーを受けるが、＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えたり、（負の）＜ｄ３＞値をフレームｆ３に対する受信機のローカル時間に加えたりして算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。
もちろん、図示の最初における２つの活性化トリガーは、ｓｔａｒｔＴｉｍｅ以降にチャネルに参加して最初の要求と併せてフレームｆ３のシグネチャーを送る受信機にとっては認知できない。
図３３は、場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
図３３は、活性化時間以前にＭ時間単位よりも遅くＡＣＲインジェストモジュールに動的活性化トリガーが送られる上記の動作（４）での状況（ｃ）を示している。
図３３は、タイムライン上に、動的イベント活性化時間と、ＡＣＲインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図で、ＡＣＲインジェストモジュールでイベントの活性化を知る時間後に長さＬ１の区間が続く。タイムラインの下における垂直矢印は、個別フレームの時間を表す。長さＬ１の区間の開始よりも先行したり、長さＬ１の区間の終わりに続く各フレームは、データベースでこのフレームと関連している時間ベーストリガーを有する。長さＬ１の区間内の各フレームは、データベースで同図の下における例のような活性化トリガーを有する。各フレームに対する“ｔ＝”項は、メディア時間ラインに対するイベント活性化時間を示す。（丸囲みの垂直矢印で表示されている。）丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機はイベント活性化に対して一つの活性化トリガーを有する。活性化トリガーの活性化時間は、このトリガーを受信した時間前であるから、受信機はトリガーを受信すると直ちに適用する。
図３４は、場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
以下、場合（ｃ）に対する活性化トリガーを説明する。これは、上記の図３３に関する説明に似ている。
図３４は、活性化時間以前にＭ時間単位よりも遅くＡＣＲインジェストモジュールに動的活性化トリガーが送られる上記の動作（４）での状況（ｃ）を示している。
図３４は、タイムライン上に、動的イベント活性化時間と、ＡＣＲインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図であり、ＡＣＲインジェストモジュールでイベントの活性化を知る時間後に長さＭの区間が続く。タイムラインの下における矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したり、長さＭの区間の終わりに続く各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーを有する。長さＭの区間内の各フレームは、データベースで同図の下における２つの例のような活性化トリガーを有する。各フレームに対する“ｄ＝”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。（丸囲みの垂直矢印で表示されている。）丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるが、（負の）＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、（負の）＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えたりして算出した活性化時間はいずれも同一の結果を有するため、受信機はそれらを重複したものと認識し、受信した最初のトリガーのみを適用する。最初のトリガーの活性化時間は、それを受信した時間以前であるから、受信機はこのトリガーを受信すると直ちに適用する。
図３５は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
イベント主導型ＡＣＲモデルで、受信機は、ＡＣＲサーバーに対する持続的な接続を開始し、一定の間隔をおいて（例えば、５秒ごとに）フレームと関連したシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ＡＣＲサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ＡＣＲサーバーはいつでも持続的な接続を通してクライアントに対するメッセージを開始することができる。
また、受信機からの最も最近の提出に対応するセグメントＩＤ（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞）及び受信機に送られる最近活性化トリガーのような各受信機に関する一定量の情報を維持することはサーバーにとって簡単である。
当該イベント主導型モデルを使用し、活性化を受信機に伝達するＡＣＲサーバーに対して、次の規則はＡＣＲサーバーからのメッセージを申し込むことができる。
第一に、ＡＣＲサーバーは、新しいセグメントでのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のＴＰＴを取得できるようにするために、直ちに時間ベーストリガーと共にメッセージを受信機に送ることができる。
第二に、ＡＣＲサーバーは（受信機が見た最も最近のバージョンとは異なる）ＴＰＴに対する新しいバージョンナンバーを有するセグメントの一部でのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のＴＰＴの新しいバージョンを取得できるようにするために、直ちに”ｖ＝”項を有する時間ベーストリガーと共にメッセージを受信機に送ることができる。
第三に、イベントが活性化される予定である場合、ＡＣＲサーバーは活性化トリガーを受信機に送ることができる。可能ならば、メディア時間ラインと関連した活性化時間を示すために活性化トリガーでの”ｔ＝”項と共に、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる（これは、要求／応答モデルでの動作と略同様である）。ＡＣＲサーバーは、活性化をあまりにも遅く知って活性化トリガーを平素より遥かに早く送ることはできなくても、活性化を知るとできるだけ早く活性化トリガーを送ることができる。（後者の場合に、受信機は、活性化時期後に活性化トリガーを受けることができ、この場合、受信機は活性化トリガーを受け次第イベントを活性化すると考えることができる。）
図２８に示した要求／応答ケースに対するアーキテクチャも、一つの差異点以外は、当該イベント主導型ケースに適している。その差異点は、イベント主導型ケースにおいて新しいアクション（２ａ）がありうるということである。動的活性化トリガーが存在すると、ＡＣＲインジェストモジュールが選択された動的活性化トリガーをＡＣＲサーバーに送ることができるように、ＡＣＲインジェストモジュールとＡＣＲインジェストモジュールによって実装されたデータベースを使用する全てのＡＣＲサーバーとの間に接続が設定されてもよい。
イベント主導型ケースに対する番号付きアクションは、要求／応答ケースと類似可能である。新しいアクション（２ａ）の他に、アクション（４）がすこし異なり、アクション（１３）がすこし異なり、新しいアクション（１４）が追加される。
アクション（４）で、ＡＣＲインジェストモジュールはフレームからシグネチャーを抽出したり（フィンガープリントＡＣＲシステムの場合）、又は関連した双方向サービスを有するセグメントに含まれた全てのフレームに対してコードをフレームに挿入（ウォーターマークＡＣＲシステムの場合）することができる。（ＡＣＲインジェストモジュールは、ＧＰＳクロックと放送スケジュール内セグメントの開始時間及び終了時間を用いて、フレームがそのようなセグメントにあるか否かを判断できる。）そのような各フレームに対してＡＣＲインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連したコードを含み得るデータベースに記録を挿入することができる。次の２つの条件の少なくとも一つを満たさないと、ＡＣＲインジェストモジュールによって記録に含まれたトリガーは、時間ベーストリガーであってもよい。
（ａ）活性化エレメントは、フレームのｍｅｄｉａ＿ｔｉｍｅが活性化エレメントのｓｔａｒｔＴｉｍｅ前の時間長Ｍから始まって活性化エレメントのｅｎｄＴｉｍｅで終わる時間区間にあるようにＡＭＴに存在する。（活性化がｅｎｄＴｉｍｅを有しないと、ｅｎｄＴｉｍｅはｓｔａｒｔＴｉｍｅと同一であると見なす。）（要求／応答ＡＣＲモデルに対して条件（ａ）と同一）
（ｂ）トリガーの活性化時間（”ｔ＝＜ｅｖｅｎｔ＿ｔｉｍｅ＞”）直前の時間長Ｍの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。（要求／応答ＡＣＲモデルに対して条件（ｂ）と同一）
これらの条件（ａ）及び（ｂ）のうち一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する”ｅ＝”項とＡＭＴ内活性化エレメントのｓｔａｒｔＴｉｍｅを示したり（条件（ａ）が場合）、動的トリガーのｅｖｅｎｔ＿ｔｉｍｅを示す（条件（ｂ））”ｔ＝”項と共に記録に含まれうる。
動的活性化トリガーがトリガーの活性化時間直前の時間長Ｍの区間でインジェストモジュールによって受信されると（このとき、Ｍは要求／応答サーバーにおけると同じ意味を有する）、インジェストモジュールは、動的活性化トリガーと関連してデータベースに如何なるものも置かず、インジェストモジュールが記録を挿入できるデータベースを使用する全てのＡＣＲサーバーに活性化トリガーを伝達することができる。（このアーキテクチャに対して次のような変形があってもよい。インジェストモデルを経由せずに動的活性化トリガーが動的活性化トリガーソースからＡＣＲサーバーに直接伝達されるが、関連した受信機に直ちにメッセージを伝送できるように、ＡＣＲサーバーは活性化時間以前のＭ時間単位よりも遅く到着する動的活性化トリガーを得る。次の受信機提出まで待つと遅すぎるはずである。）
アクション（１３）で、ＡＣＲサーバーは直前の提出に対して受信しなかった後にデータベースから”ｎｏ ｍａｔｃｈ”指示子を返してもうと、受信機にＮＵＬＬメッセージを送ることができる。直前の提出に対して返してもらった＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と異なる＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と共にトリガーを返してもらうと、受信機にトリガーを送ることができる。両方の場合において、受信機に視聴中のチャネルが変更されたり視聴中のセグメントが終わったことを知らせ、受信機が現在実行しているＴＤＯを終了し、必要なら、新しいＴＰＴをダウンロードするようにすることができる。ＡＣＲサーバーは、一つ以上の活性化トリガーを返してもらうと、既に受信機に送られた活性化トリガーと重複するものは捨てて受信機に送ることができる。それとも、ＡＣＲサーバーは何にもしなくてもよい。
新しいアクション（１４）で、ＡＣＲサーバーは動的活性化トリガーを受信すると、動的活性化トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と各ＡＣＲクライアントに対する現＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞とを比較することができる。（ここでクライアントに対する現＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞は、ＡＣＲサーバーがＡＣＲクライアントからの最も最近の提出に対してデータベースから受けたトリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞である。＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞がマッチングされる各クライアントに対して、ＡＣＲサーバーは動的トリガーをクライアントに送ることができる。）
図２９及び図３１は、活性化時間よりも少なくともＭ時間単位以前にＡＣＲインジェストモジュールに伝達される静的活性化及び動的活性化に対するトリガーの処理を示す。差異点は、ＡＣＲサーバーが重複する活性化トリガーを受信機に送らずに捨てることができるという点である。
図３５は、急に（活性化時間よりもＭ時間単位以前に）受信された動的活性化トリガーの処理の一実施例を示す。
図３５は、時間ライン上の動的イベント活性化時間及びＡＣＲインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ＡＣＲサーバーは、ＡＣＲインジェストモジュールから活性化トリガーを受信し次第、（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞から確認されるように）現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。
図３６は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
最後に伝達される動的活性化トリガーについて説明する。
図３６は、急に（活性化時間よりもＭ時間単位以前に）受信された動的活性化トリガーの処理の一実施例を示す。
最後に伝達される動的活性化トリガーを示す同図は、時間ライン上の動的イベント活性化時間及びＡＣＲインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ＡＣＲサーバーは、ＡＣＲインジェストモジュールから活性化トリガーを受信し次第、（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞から確認されるように）現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。各受信機に対して、トリガーのｅｖｅｎｔ＿ｔｉｍｅを、受信機から最も最近に提出されたシグネチャーに対応するフレームと関連した＜ｄｅｌａｙ＿ｔｉｍｅ＞に調節する。
図３７は、要求／応答ＡＣＲケースにおけるＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
図３７は、要求／応答モデルにおいてＡＣＲサーバーと受信機（ＡＣＲクライアント）の動作プロトコルによってトリガー及びＴＰＴを效果的に送信する実施例を示すシーケンスダイヤグラムである。
以下、要求／応答の順で要求／応答モデルの動作の一例を説明する。
要求／応答ＡＣＲケースにおいて、ＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムは、ＡＣＲ要求１（Ｓ３７０１０）、ＡＣＲ応答１（Ｓ３７０２０）、ＡＣＲ要求２（Ｓ３７０３０）、ＡＣＲ応答２（Ｓ３７０４０）、ＨＴＴＰ要求１（Ｓ３７０５０）、ＨＴＴＰ応答１（Ｓ３７０６０）、ＨＴＴＰ要求２（Ｓ３７０７０）、ＨＴＴＰ応答２（Ｓ３７０８０）、ＡＣＲ要求３（Ｓ３７０９０）、ＡＣＲ応答３（Ｓ３７１００）、ＡＣＲ要求４（Ｓ３７１１０）、及び／又はＡＣＲ応答４（Ｓ３７１２０）を含むことができる。
ＡＣＲ要求１（Ｓ３７０１０）は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、前述したＡＣＲサーバーであってもよい。シグネチャーはフィンガープリントシグネチャー又はウォーターマーキングコードであってもよい。
ＡＣＲ応答１（Ｓ３７０２０）は、シグネチャーが認識されなかったり、又は関連した双方向サービスが存在しないとき、ＡＣＲサーバーがヌルをリターンする段階である。これは、ヌル応答がリターンされる上述したケースに該当する場合であってもよい。
ＡＣＲ要求２（Ｓ３７０３０）は、チャネル又はプログラムが変更されるとき、受信機が変更されたプログラムのシグネチャーをＡＣＲサーバーに伝送する段階である。
ＡＣＲ応答２（Ｓ３７０４０）は、ＡＣＲサーバーが該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この段階は、ＡＣＲ応答１（Ｓ３７０２０）と違い、シグネチャーが認識され、関連した双方向サービスが存在するケースに該当できる。すなわち、トリガーを利用可能である場合であってもよい。この場合、リターンされるトリガーは、ｍｅｄｉａ＿ｔｉｍｅに関する情報がない時間ベーストリガーであってもよい。
ＨＴＴＰ要求１（Ｓ３７０５０）は、受信機がＴＰＴサーバー（例えば、ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）にｈｔｔｐプロトコルを通してＡＣＲ応答２（Ｓ３７０４０）で受信したアドレスを用いて該当するＴＰＴを提供することを要求する段階である。
ＨＴＴＰ応答１（Ｓ３７０６０）は、ＴＰＴサーバーが受信機の要求に応じてＸＭＬに表したＴＰＴを伝送する段階である。
ＨＴＴＰ要求２（Ｓ３７０７０）は、受信機がコンテンツサーバーにｈｔｔｐプロトコルを用いてＴＤＯのようなアプリケーションを提供することを要求する段階である。受信機は、ＴＰＴ内に含まれたＴＤＯ関連情報をパーシングすることができる。ＴＤＯ関連情報は、ＴＤＯをダウンロードできるコンテンツサーバーのアドレスであってもよい。コンテンツサーバーのアドレスを用いて要求を送ることができる。
ＨＴＴＰ応答２（Ｓ３７０８０）は、コンテンツサーバーが受信機の要求に応じて該当するＴＤＯを伝送する段階である。
ＡＣＲ要求３（Ｓ３７０９０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
ＡＣＲ応答３（Ｓ３７１００）は、ＡＣＲサーバーが該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この場合、ＡＣＲ応答１（Ｓ３７０２０）と違い、シグネチャーが認識され、関連した双方向サービスが存在する。すなわち、この段階でトリガーは使用可能である。
ＡＣＲ要求４（Ｓ３７１１０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに伝送する段階である。
ＡＣＲ応答４（Ｓ３７１２０）は、ＡＣＲサーバーが、受信機から伝送されたシグネチャーと関連した双方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
図３８は、イベント主導型ＡＣＲケースにおけるＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
図３８は、イベント主導型モデルにおいてＡＣＲサーバーと受信機（ＡＣＲクライアント）の動作プロトコルによってトリガー及びＴＰＴを效果的に伝送する実施例に係るシーケンスダイヤグラムを示す。
要求、要求に対する応答、イベントの順にイベント主導型モデルの動作についての一例を説明する。
イベント主導型ＡＣＲケースにおいて、ＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムは、ＡＣＲ要求１（Ｓ３８０１０）、ＡＣＲ要求２（Ｓ３８０２０）、ＡＣＲイベント１（Ｓ３８０３０）、ＨＴＴＰ要求１（Ｓ３８０４０）、ＨＴＴＰ応答１（Ｓ３８０５０）、ＨＴＴＰ要求２（Ｓ３８０６０）、ＨＴＴＰ応答２（Ｓ３８０７０）、ＡＣＲ要求３（Ｓ３８０８０）、ＡＣＲイベント２（Ｓ３８０９０）、及び／又はＡＣＲ応答４（Ｓ３８１００）を含むことができる。
ＡＣＲ要求１（Ｓ３８０１０）は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、上述したＡＣＲサーバーであってもよい。シグネチャーは、フィンガープリントシグネチャー又はウォーターマークであってもよい。ここで、シグネチャーが認識されなかったり、又は関連した双方向サービスが存在しないとき、図３７のシーケンスとは違い、ＡＣＲサーバーはヌルをリターンせずにＡＣＲ要求１に何ら応答も送らなくてもよい。
ＡＣＲ要求２（Ｓ３８０２０）は、チャネル又はプログラムが変更されるとき、受信機が、変更されたプログラムのシグネチャーをＡＣＲサーバーに伝送する段階である。
ＡＣＲイベント１（Ｓ３８０３０）は、ＡＣＲサーバーが、該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この段階は、シグネチャーが認識され、関連した双方向サービスが存在するケースに該当できる。すなわち、この段階でトリガーは使用可能である。この場合、リターンするトリガーは、ｍｅｄｉａ＿ｔｉｍｅと関連した如何なる情報も有しない時間ベーストリガーであってもよい。
ＨＴＴＰ要求１（Ｓ３８０４０）は、受信機がＴＰＴサーバー（例えば、ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）にｈｔｔｐプロトコルを通してＡＣＲイベント１（Ｓ３８０３０）で受信したアドレスを用いて該当するＴＰＴを提供することを要求する段階である。
ＨＴＴＰ応答１（Ｓ３８０５０）は、ＴＰＴサーバーが受信機の要求に応じてＸＭＬに表したＴＰＴを伝送する段階である。
ＨＴＴＰ要求２（Ｓ３８０６０）は、受信機がコンテンツサーバーにｈｔｔｐプロトコルを用いてＴＤＯのようなアプリケーションを提供することを要求する段階である。受信機は、ＴＰＴ内に含まれたＴＤＯ関連情報をパーシングすることができる。ＴＤＯ関連情報は、ＴＤＯをダウンロードできるコンテンツサーバーのＵＲＬであってもよい。コンテンツサーバーのＵＲＬを用いて要求を送ることができる。
ＨＴＴＰ応答２（Ｓ３８０７０）は、コンテンツサーバーが受信機の要求に応じて該当するＴＤＯを伝送する段階である。
ＡＣＲ要求３（Ｓ３８０８０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
ＡＣＲイベント２（Ｓ３８０９０）は、ＡＣＲサーバーが受信機から伝送されたシグネチャーと関連した双方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
ＡＣＲ応答４（Ｓ３８１００）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
図３９は、ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスのアクションリストの一実施例である。
第２スクリーン支援は、受信機で、放送社のサービス或いは放送社で提供し、プログラムに適した付加的なサービスを、第２スクリーンデバイスに提供するための方法に関するものである。付加的なコンテンツは、アプリケーションを用いて提供することができ、アプリケーションは、ＴＶ画面に表示されてユーザがリモコン操作で付加コンテンツを使用するようにすることができる。しかし、最近では、個人化情報化機器（スマートホン、スマートパッド及び小型化しつつあるラップトップ）などによってＴＶ画面で再生されているコンテンツはそのまま表示させながら、付加的なサービスを第２スクリーンデバイスに表示させることができる。これによって、既存の放送コンテンツを妨害なく個人的に利用できるようにすることができる。このように付加的なデータや情報を第２スクリーンデバイスに表示して処理をすると、ＴＶ画面を複数の人が一緒に見る状況で、付加サービスに関心のある人だけが他の人のＴＶ視聴を妨害することなく付加コンテンツを得ることができる効果がある。第２スクリーン支援は、前述した効果の他にも様々な用途に活用することができる。
一つの装置を他の装置に接続させて制御するためには、まず、ホームネットワークにどのような装置があるかを知らなければならない。このため、一つ以上の装置が自身の存在を周期的にホームネットワークにメッセージを送信して広く知らせることができる。一方では、一つの装置が新しくホームネットワークに接続しながら自身を紹介する前に、自身以外にどのような装置があるかを要求することができる。これら２つの接近方式は、互いに装置を容易に且つ迅速に認識できるように手伝うことができる。これを、ＵＰｎＰデバイスディスカバリ（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）と呼ぶ。装置を発見すると、発見された装置に関心のある他の装置は、その装置にどのようなサービスを提供できるかに関する情報が必要でありうる。ＵＰｎＰフレームワーク（Ｆｒａｍｅｗｏｒｋ）が内蔵されている家電機器は、互いにどんな機能を有しているか、そしてそれらの機能がどの範囲まで支援するかが把握できる。この情報をＵＰｎＰデバイスプロファイル（Ｄｅｖｉｃｅ Ｐｒｏｆｉｌｅ）と定義しておき、互いに提供できるサービスの属性を把握することができる。特定サービスを提供する装置を常に待っていてもよいが、その特定サービスを提供する装置が発見される場合、発見された装置内にどのようなサービスがあるかを問うことができる。発見された装置内に適合なサービスがあると、すぐに接続して互いに通信することができる。また、ＵＰｎＰサービス記述語（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒ）に定義されたとおりにサービスを定義して交換することができる。
一つの装置には、単数又は複数個のサービスがあり、このサービスを互いに異なる機器で制御して使用するようになっている。装置に一つ以上の機能があると、その機能別に定義された複数個のサービスが含まれ、他の機器で制御することができる。装置の定義は、装置固有の情報を有することができる。例えば、モデル名（Ｍｏｄｅｌ Ｎａｍｅ）、一連番号（Ｓｅｒｉａｌ Ｎｕｍｂｅｒ）、モデル番号（Ｍｏｄｅｌ Ｎｕｍｂｅｒ）、ＣＥメーカー名（Ｍａｎｕｆａｃｔｕｒｅｒ Ｎａｍｅ）及びウェブサイト（Ｗｅｂ Ｓｉｔｅ）などの情報が装置固有の情報であってもよい。これらの情報は装置別に固有の値を有し、一般的には変更されない。サービスは、装置が行える動作であり、各動作はアクション（Ａｃｔｉｏｎ）と呼び、一つ以上のアクションを有することができる。アクションは、関数のようにそれぞれパラメータ値を有し、一つ以上のパラメータ値を有することができる。アクションは、装置内のサービスで行われ、アクションが行われた後には、必要によって、定義されたリターン値を返還することができる。
アクションに対する例示として、図３９は、例示されたサービスであるＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスに対して、そのサービスのアクションの種類及び記述（Ｄｅｓｃｒｉｐｔｉｏｎ）を示している。Ｃｏｎｎｅｃｔｉｏｎ／ｄｉｓｃｏｎｎｅｃｔｉｏｎは、現在接続状態を返還するアクションであってもよい。ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎは、現在接続目録を返還するアクションであってもよい。ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅは、デバイスプロファイルをＸＭＬの形態として返還するアクションであってもよい。ＧｅｔＵＩＬｉｓｔｉｎｇは、互換可能な（ｃｏｍｐａｔｉｂｌｅ）ＵＩの目録をＸＭＬの形態として返還するアクションであってもよい。ＡｄｄＵＩＬｉｓｔｉｎｇ／ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇは、ｒｅｍｏｔｅ ＵＩのＵＲＬをＵＩ目録に追加したり除去する動作であってもよい。ＰｒｏｃｅｓｓＩｎｐｕｔは、ＲｅｍｏｔｅＵＩクライアントサービスにデータを送るアクションであってもよい。ＤｉｓｐｌａｙＭｅｓｓａｇｅは、ＲｅｍｏｔｅＵＩクライアントサービスを含む装置にメッセージをディスプレイするアクションであってもよい。
図４０は、ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例である。
ＵＰｎＰでは、前述したアクションと必要なパラメータ値を送信するために、ＳＯＡＰというＸＭＬメッセージ形式を使用し、ＳＯＡＰは、遠隔手順（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ）を遠隔で行うために用いることができる。これらのメッセージは、ＨＴＴＰプロトコルを用いて伝送することができる。
前述したＲｅｍｏｔｅＵＩクライアントのアクションは、図４０のように動作することができる。図４０に示す動作は、前述したアクションの一実施例にすぎない。
ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例は、ＵＰｎＰ探索プロセスとＲｅｍｏｔｅＵＩクライアントアクションとに分けることができる。
ＵＰｎＰ探索プロセスは、第２スクリーンサービスのためのＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）、ＵＰｎＰデバイスを探す段階（ｓ４００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）、デバイス記述（Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）を要求する段階（ｓ４００３０）、デバイス記述を受信する段階（ｓ４００４０）、サービス制御記述を要求する段階（ｓ４００５０）及び／又はサービス制御記述を受信する段階（ｓ４００６０）を含むことができる。
ＲｅｍｏｔｅＵＩクライアントアクションは、デバイスプロファイルを要求する段階（ｓ４００７０）、デバイスプロファイルを受信する段階（ｓ４００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ４００９０）、応答１を送信する段階（ｓ４０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）、応答２を送信する段階（ｓ４０１２０）、及び／又はユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）を含むことができる。
ＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）は、第２スクリーンデバイス（ＲｅｍｏｔｅＵＩクライアント）でａｎ ＵＰｎＰアプリケーションを実行させる段階であってもよい。
ＵＰｎＰデバイスを探す段階（ｓ４００１０）は、プライマリデバイスが第２スクリーンデバイスで実行中のアプリケーションにディスカバリメッセージ（ｄｉｓｃｏｖｅｒｙ ｍｅｓｓａｇｅ）をマルチキャストする段階であってもよい。これによってネットワーク内の第２スクリーンデバイスを探すことができる。プライマリデバイスは、ディスカバリメッセージを用いて、自身が提供する第２スクリーン支援サービスを知らせることができる。
ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）は、第２スクリーンデバイスがディスカバリメッセージを受け、プライマリデバイスに通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ ｍｅｓｓａｇｅ）を送る段階であってもよい。
デバイス記述を要求する段階（ｓ４００３０）は、プライマリデバイスが第２スクリーンデバイスに第２スクリーンデバイスに対するデバイス記述を要求する段階であってもよい。
デバイス記述を受信する段階（ｓ４００４０）は、第２スクリーンデバイスがデバイス記述を要求する段階（ｓ４００３０）に対する応答として第２スクリーンデバイスのデバイスプロファイルを送ると、プライマリデバイスがこれを受信する段階であってもよい。
サービス制御記述を要求する段階（ｓ４００５０）は、プライマリデバイスが第２スクリーンデバイスにサービス制御記述を要求する段階であってもよい。
サービス制御記述を受信する段階（ｓ４００６０）は、プライマリデバイスが第２スクリーンデバイスから、要求したサービス制御記述を受信する段階であってもよい。
ＵＰｎＰ探索プロセスによって、ネットワーク上に存在するプライマリデバイスと第２スクリーンデバイスはお互い探索して認識することができる。また、これによってプライマリデバイスと第２スクリーンデバイスは互いに接続することができる。
デバイスプロファイルを要求する段階（ｓ４００７０）は、第２スクリーンデバイスのデバイスプロファイルを要求する段階であってもよい。前述したＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅアクションを用いることができる。
デバイスプロファイルを受信する段階（ｓ４００８０）は、プライマリデバイスが要求した第２スクリーンデバイスのデバイスプロファイルを受信する段階であってもよい。“ＲｅｍｏｔｅＵＩクライアントサービス”を有する装置（第２スクリーンデバイス、ＲｅｍｏｔｅＵＩクライアント）は、遠隔の装置（プライマリデバイス）でＵＩのＵＲＬアドレスを知らせると、このアドレスを探して画面に表示する役割を果たすことができる。また“ＲｅｍｏｔｅＵＩサーバーサービス”を有する装置は、ＵＩのＵＲＬアドレスをマルチキャストし、それに関心のある装置に知らせるサービスであってもよい。しかし、この場合には、Ｒｅｍｏｔｅ ＵＩが特定装置のために作られるため、特定装置に合う遠隔ＵＩを提供しなければならない。このため、デバイスプロファイル情報を共に送信する必要があり、デバイスプロファイルを要求する段階（ｓ４００７０）及びデバイスプロファイルを受信する段階（ｓ４００８０）が必要でありうる。
遠隔ＵＩのＵＲＬを送る段階（ｓ４００９０）は、遠隔ＵＩのＵＲＬアドレスを第２スクリーンデバイスに知らせる段階であってもよい。前述したＡｄｄＵＩＬｉｓｔｉｎｇアクションを用いることができる。第２スクリーンデバイスは、これをＵＩＬｉｓｔｉｎｇに追加することができる。
応答１を送信する段階（ｓ４０１００）は、遠隔ＵＩのＵＲＬを送る段階（ｓ４００９０）に対する結果を送る段階であってもよい。状況によって、ＨＴＴＰ／１．１ ２００ ＯＫ（要求が成功裏に処理される）、ＨＴＴＰ／１．１ ５０１ Ｍｅｔｈｏｄ Ｎｏｔ Ｉｍｐｌｅｍｅｎｔｅｄ（要求を処理するために必要な機能が具現されていない）、ＨＴＴＰ／１．１ ４００ Ｎｏｔ Ｆｏｕｎｄ（要求したファイル／リソースが存在しない）などの応答を送ることができる。
ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）は、プライマリデバイスが第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したＤｉｓｐａｌｙＭｅｓｓａｇｅアクションを用いることができる。第２スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第２スクリーンにディスプレイすることができる。
応答２を送信する段階（ｓ４０１２０）は、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況に応じて、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）は、第２スクリーンにディスプレイされたメッセージなどによって、ユーザが選択をする段階であってもよい。
ＲｅｍｏｔｅＵＩクライアントアクションは、前述したアクションなどによってＲｅｍｏｔｅＵＩクライアントサービスが動作する過程を記述したものであってもよい。
遠隔ユーザインターフェースに関する記述は、画面に表示されるＨＴＭＬ記述ベースのアプリケーションを家電機器で使用できるように機能を追加したり制限された家電機器のリソースを勘案して、既存のＰＣシステムで使用可能な機能を簡素化した。この記述には、大きく、２つの観点が含まれている。すなわち、画面に表示するＨＴＭＬを家電製品で使用できるようにしたことと、各家電製品で使用できるブラウザＡＰＩを定義することである。ブラウザＡＰＩは、多く使われているスクリプト言語であるジャバスクリプト（ＪａｖａＳｃｒｉｐｔ）で呼び出しして使用することができる。ジャバスクリプトで呼び出されたＡＰＩは、結局として受信機の関数を呼び出すようになる。
この中、前述したＵＰｎＰデバイスとサービスは、ブラウザで動作するジャバスクリプトによっても動作できるはずである。そのためには、ブラウザで各ＵＰｎＰデバイス別に異なるパラメータを伝達する新しいＡＰＩが必要であろう。
図４１は、ＤＴＶＣＣ Ｓｅｒｖｉｃｅ Ｎｕｍｂｅｒ６におけるトリガーの一実施例である。
前述したとおり、ＤＴＶＣＣ（Ｄｉｇｉｔａｌ ＴＶ Ｃｌｏｓｅｄ Ｃａｐｔｉｏｎ Ｓｅｒｖｉｃｅ）サービスを用いて前述のリガーを送信することができる。トリガーは、一つのＵＲＬストリング（Ｓｔｒｉｎｇ）値を有することができ、ＤＴＶＣＣサービスのうちの６番目のサービスとして受信することができる。ＭＰＥＧ−２送信プロセッサ４１０１０はトリガーをＤＴＶＣＣサービスシリーズ＃６として受信し、送信プロセッサドライバ４１０２０を通してＤＴＶ−ＣＣモジュール４１０４０に伝達できる。このとき、Ｕｓｅｒｄａｔａは、バッファー４１０３０を経由することができる。ＤＴＶ−ＣＣモジュール４１０４０は、ＤＴＶＣＣデコーダの役割を果たすことができる。ＤＴＶ−ＣＣモジュール４１０４０は、ＵＲＩストリング値を有するトリガーを付加サービスモジュール（Ａｄｊｕｎｃｔ Ｓｅｒｖｉｃｅ ｍｏｄｕｌｅ）４１０５０に伝達することができる。付加サービスモジュール４１０５０はトリガーモジュールであり、ＵＲＩストリング値を把握し、前述したＴＰＴ（ＴＤＯ Ｐａｒａｍｅｔｅｒｓ Ｔａｂｌｅ）を取得することができる。これによって、前述したとおり、トリガー、ＴＰＴ及びＴＤＯを用いて付加サービスを提供することができる。
図４２は、第２スクリーンシナリオのためのシステムアーキテクチャの一実施例である。
第２スクリーンの支援のためにいくつかの要求事項がありうる。１）受信機は、一つ或いはそれ以上の第２スクリーンデバイスと接続することができる。２）第２スクリーンデバイスは、ラップトップ、タブレット、スマートホン、ＰＤＡなどの携帯機器を対象とすることができる。３）第２スクリーンの主要コンテンツは、ＨＴＭＬ、テキスト、ビデオ、オーディオなどとすることができる。４）第２スクリーンで再生されるコンテンツは、プライマリデバイス（受信機）の放送プログラムに邪魔とならない設計とすることができる。５）第２スクリーンは直接的にＡＴＳＣ２．０受信機に接続することができ、間接的には３ＧＰＰ網のように迂回して接続することもできる。６）プロバイダが、特定コンテンツが第２スクリーンでのみ表示されるようにシグナリングすることもできる。７）場合によって、受信機で再生可能なコンテンツも、第２スクリーンで再生可能に設計することができる。８）認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及び許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）された第２スクリーンで第２スクリーンサービスを用いることができる。９）第２スクリーンコンテンツの聴衆使用量（ａｕｄｉｅｎｃｅ ｕｓａｇｅ）を測定するようにすることができる。（この場合、このような情報を得るためにユーザから同意を得、その情報を報告できる機能が存在してもよい。）１０）第２言語又はコンテンツエンハンスメント（Ｃｏｎｔｅｎｔ Ｅｎｈａｎｃｅｍｅｎｔ）可能な装置を用いて提供することもできる。
本明細書は、放送されるプログラムと同期したコンテンツを有する第２スクリーンデバイス（スマートホン、タブレット、ラップトップなど）上で実行されるアプリケーションによるＡ／Ｖ放送に関連したコンテンツのディスプレイを支援するために受信機によって提供されうるサービスを記述することができる。サービスに関する説明はＵＰｎＰデバイスアーキテクチャに基づいて記述された。
この明細書で、ＡＴＳＣ２．０受信機とは、ＴＶ受信機又は一般的な受信機を意味することができる。また、ＤＶＢ、ＡＴＳＣなどにおける受信機を意味することができる。
ＵＰｎＰデバイスアーキテクチャは、サービスを提供する“被制御デバイス”及びそのサービスを利用する“制御ポイント”間のＩＰネットワークにおける通信のためのプロトコルを定義する。“第２スクリーン”シナリオで、ＴＶ受信機は“被制御デバイス”の役割を担い、第２スクリーンデバイスは“制御ポイント”の役割を担うことができ、その逆であってもよい。
ＵＰｎＰデバイスアーキテクチャは、関心のある被制御デバイスを探す制御ポイントのための“探索”プロトコル、被制御デバイス及びサービスに対する細部事項を学習する制御ポイントのための“記述（ｄｅｓｃｒｉｐｔｉｏｎ）”プロトコル、被制御デバイス上の“アクション”（方法）を実行（ｉｎｖｏｋｅ）する制御ポイントのための“制御”プロトコル、及び制御ポイントに非同期通知を伝達する被制御デバイスのための“イベンティング（ｅｖｅｎｔｉｎｇ）”プロトコルを特定する。アクション及びイベントは、デバイスサービスによって提供することができる。
ＵＰｎＰ被制御デバイスがネットワークにジョイン（ｊｏｉｎ）すると、“よく知らされた”ＩＰマルチキャストアドレス及びポートにディスカバリメッセージをマルチキャストすることができる。それらのメッセージは、デバイスによって提供されるデバイスタイプ及びサービスタイプを識別することができ、デバイス及びサービスの記述を取得できるＵＲＬを提供することができる。
ＵＰｎＰ制御ポイントがネットワークにジョインすると、被制御デバイスに自身を知らせるかを問う序歯（ｓｅａｒｃｈ）メッセージをマルチキャストすることができる。サーチメッセージは、関心のあるデバイスタイプ及び／又はサービスタイプを特定することができる。関連デバイスは、制御ポイントにユニキャストディスカバリメッセージを送ることによって応答することができる。
制御ポイントが関心のあるデバイス及びサービスに対するディスカバリメッセージを得ると、メッセージ内のＵＲＬを用いてデバイス及びサービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）を要求することができる。それらの記述は、アクションを実行（ｉｎｖｏｋｅ）し、サービスに対するイベントを申し込むために用い得るＵＲＬを含むことができる。
一般的な第２スクリーン探索シナリオは、シナリオＡとシナリオＢとに大別できる。シナリオＡの場合、ユーザは、ＴＶ受信機が（ＴＶ受信機がオンになる時又はそのネットワークインターフェースがイネーブルされる時に発生しうる）ネットワークにジョインする時、自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有する。シナリオＢの場合、ユーザは、ＴＶ受信機がネットワークにジョインする時、自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有しない。
シナリオＡは、次の通りでありうる。１）第２スクリーン支援を提供するＴＶ受信機はネットワークにジョインする。２）ＴＶ受信機は、その第２スクリーン支援サービスを広告するディスカバリメッセージをマルチキャストする。３）第２スクリーンデバイスで実行される第２スクリーンアプリケーションは、マルチキャストされたディスカバリメッセージを受信し、ＴＶ受信機にそのサービスの記述に対する要求を送信する。４）ＴＶ受信機は、そのサービスの記述で応答する。５）第２スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスして、ＴＶプログラミングと同期したインタラクティブ経験を提供する。
シナリオＢは、次の通りでありうる。１）ＴＶ受信機上で見ているＴＶ番組は、第２スクリーン支援を提供するプログラムセグメントに入る。（これは、ＴＶ受像機がオンになるやいなや又はチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時、又は視聴しているチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時でありうる。）２）これは、ＴＶ受信機が第２スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。３）視聴者は、第２スクリーン支援を用いて自身の第２スクリーンデバイス上で第２スクリーンアプリケーションを活性化する。すると、第２スクリーンアプリケーションは、第２スクリーン支援を提供する装置を探すメッセージをマルチキャストする。ＴＶ受信機は、自身のディスカバリメッセージでこのメッセージに応答する。４）第２スクリーンアプリケーションがディスカバリメッセージを探すと、ＴＶ受信機にそのサービスの記述に対する要求を送信する。５）ＴＶ受信機は、そのサービスの記述で応答する。６）第２スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスし、ＴＶ番組と同期したインタラクティブ経験を提供する。
シナリオＡを書き換えると、次の通りでありうる。１）第２スクリーン支援を提供するＴＶ受像機はネットワークにジョインする。（これは、ＴＶセットがオンになる時又はそのネットワークインターフェースがイネーブルされる時であってもよい。）２）これは、ＴＶ受信機が自身及びその第２スクリーン支援サービスを広告する自身のディスカバリメッセージをマルチキャストするようにする。３）この時、ユーザが自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有すると、アプリケーションは、マルチキャストされたディスカバリメッセージを受信し、段階（７）に進行する。４）ＴＶ受信機上で見ているＴＶ番組が第２スクリーン支援を提供するプログラムセグメントに入る。（これは、ＴＶ受像機がオンになるやいなや又はチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時又は視聴しているチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時であってもよい。）５）これは、ＴＶ受信機が、第２スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。６）視聴者が自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有していない場合、視聴者は、第２スクリーン支援を用いて自身の第２スクリーンデバイス上で第２スクリーンアプリケーションを活性化する。すると、第２スクリーンアプリケーションは、第２スクリーン支援を提供する装置を探すメッセージをマルチキャストする。ＴＶ受信機は、自身のディスカバリメッセージでこのメッセージに応答する。７）第２スクリーンアプリケーションがディスカバリメッセージを探すと、ＴＶ受信機にそのサービスの記述に対する要求を送信する。８）ＴＶ受信機は、そのサービスの記述で応答する。これらは、トリガーサービス及び選択的にＨＴＴＰプロキシサーバーサービスであろう。９）第２スクリーンアプリケーションは、トリガーサービスの“イベンティング”特徴を申し込むはずである。提供されるインタラクティブデータサービスの相互作用モデルが直接実行モデルであれば、全てのトリガーがＴＶ受信機によって受信される時、トリガーサービスは全てのトリガーを第２スクリーンデバイスに送信するはずである。インタラクティブデータサービスの相互作用モデルがＴＤＯモデルであれば、新しい活性化トリガーの活性化時間に到達する度に、トリガーサービスは活性化トリガーを第２スクリーンアプリケーションに送信するはずである。１０）第２スクリーンアプリケーションは、必要によってＴＤＯ及び他のファイルを、インターネットリンク又はＴＶ受信機によって提供されたＨＴＴＰプロキシサーバーサービスからダウンロードし、インタラクティブサービスを第２スクリーン装置ユーザに提供しながらトリガーに対して動作するはずである。１１）ＴＶ受信機上のＴＶ番組が、第２スクリーン支援を有するインタラクティブデータサービスを提供しないセグメントに進行すると、トリガーサービスは、“ヌルトリガー（ｎｕｌｌ Ｔｒｉｇｇｅｒ）”を第２スクリーンアプリケーションに送信し、第２スクリーンデバイスに対するインタラクティブデータサービスがそれ以上利用可能でないということを知らせる。１２）その後、第２スクリーンデバイスのユーザが、第２スクリーンアプリケーションを閉じたり、そのまま第２スクリーンアプリケーションが実行されるようにし、ＴＶ受信機上の番組が第２スクリーン支援を提供する他のセグメントに入る度に相互作用を再開するようにすることができる。
これらの両シナリオで、仮定は、ホームネットワーク上に１よりも多いＴＶ受信機を有することができる。この場合、第２スクリーンアプリケーションは、多数の異なった受信機からディスカバリメッセージを受信することができる。この場合、第２スクリーンアプリケーションは（ユーザの決定を助けるために記述メッセージからの情報をディスプレイしながら）どれをもって相互作用をするかをユーザに問うことができる。
第２スクリーン支援を提供するＴＶ受信機は、第２スクリーンアプリケーションの使用のためのいくつかのＵＰｎＰサービスを提供することができる。ＵＰｎＰサービスは、受信機から第２スクリーンアプリケーションへの“トリガー伝達サービス”、受信機で実行されるＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔｓ）及び第２スクリーンアプリケーション間の“双方向通信サービス”及び“ＨＴＴＰプロキシサーバーサービス”であってもよい。それらのサービスは、構成によって選択的であってもよい。
それらのサービスは、様々な異なったソースから得られ、様々な異なったタイプの第２スクリーンデバイスで様々な互いに異なる動作環境下に実行される様々な異なったタイプの第２スクリーンアプリケーションを支援するように設計されてもよい。
一般的な第２スクリーンパッケージアプリケーションシナリオは、次の通りである。１）第２スクリーンデバイス上の制御ポイントは、第１スクリーン装置上のパッケージアプリケーションサービスを申し込む。２）消費者は、第１スクリーン装置上のパッケージアプリケーションを始める。３）パッケージアプリケーションは、第２スクリーンアプリケーションのネーム及び第２スクリーンアプリケーションのＵＲＬをパッケージアプリケーションサービスに利用可能にする。４）第２スクリーンデバイス上の制御ポイントは、同伴者（ｃｏｍｐａｎｉｏｎ）アプリケーションのネーム及びＵＲＬを受信する。５）制御ポイントは、必要な消費者アクションを指示する第２スクリーン上のマーカーを設定する。６）消費者は、第２スクリーンアプリケーションのネームを検討し選択する。７）制御ポイントは、指示された第２スクリーンアプリケーションを開始する。
第２スクリーン支援を提供する第１スクリーンは、第２スクリーンアプリケーションの利用のためにいくつかのＵＰｎＰサービスを提供することができる。ＵＰｎＰサービスの一つは、第２スクリーンデバイス上で実行される同伴者第２スクリーンアプリケーションのネーム及びＵＲＬを提供している“アプリケーションＵＲＬサービス”である。
第２スクリーンシナリオに対するシステムアーキテクチャを説明する。
第２スクリーンシナリオに対するシステムアーキテクチャは、放送システム４２０１０、ＡＣＲサーバー４２０２０、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０、ＡＴＳＣ２．０受信機４２０４０及び／又は第２スクリーンデバイス４２０５０を含むことができる。
放送システム４２０１０は、一般的な放送システムであってもよい。放送ネットワークを介してトリガー、Ａ／Ｖ、ＴＰＴ及び／又はその他データファイルなどを伝達することができる。トリガーの場合、前述したとおり、ＤＴＶＣＣを用いて伝達することができる。
ＡＣＲサーバー４２０２０は、放送コンテンツに対するＡＣＲ関連データを管理するサーバーであり、要求或いは必要な場合、ＡＴＳＣ２．０受信機４２０４０がインタラクティブサービスを取得できるように、これと関連したトリガーをＡＴＳＣ２．０受信機４２０４０に送信することができる。前述したＡＣＲサーバーと同一であってもよい。
放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０は、インタラクティブサービスを生成及び管理するサーバーであり、これと関連したＴＤＯ／ファイルを管理し、それに関する情報を含むＴＰＴ（ＴＤＯ Ｐａｒａｍｅｔｅｒ Ｔａｂｌｅ）を生成及び管理することができる。
ＡＴＳＣ２．０受信機４２０４０は、放送Ａ／Ｖ及びインタラクティブサービスと関連したトリガーなどを受信し、それを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。
第２スクリーンデバイス４２０５０は、第２スクリーンデバイスであるモバイルホン、タブレット、ラップトップなどを含むことができる。前述した第２スクリーンデバイスと同一であってもよい。
トリガーは、ＤＴＶＣＣチャネル又はＡＣＲプロセスを通してＡＴＳＣ２．０受信機４２０４０に伝達されてもよく、放送インタラクティブＴＶ（ｉＴＶ）サーバー４２０３０から伝達されてもよい。いずれの場合も、適切な時間にトリガーはＡＴＳＣ２．０受信機４２０４０から第２スクリーンデバイス４２０５０に伝達される。本明細書は、第２スクリーンデバイス４２０５０に伝達されるトリガーに対するメカニズムを説明する。また、ＡＴＳＣ２．０受信機４２０４０上で実行されて第２スクリーンデバイス４２０５０と双方向通信を確立するＤＯに対するメカニズムを説明する。
インターネットを介して利用可能なアプリケーション及び他のファイルは、そのサービスを提供する場合には、ホームネットワークを通じて、別途の３ＧＰＰネットワークを通じて、又はＡＴＳＣ２．０受信機４２０４０上のＨＴＴＰプロキシサーバー（図示せず）を通じて第２スクリーンデバイス４２０５０によって検索されうる。第１スクリーンデバイス上で実行されるアプリケーションは、放送によって送信されるアプリケーション又はインターネットからダウンロードしたパッケージアプリケーションであってもよい。
放送でＦＬＵＴＥセッションを通じてのみ利用可能なアプリケーション及び他のファイルは、ＡＴＳＣ２．０受信機４２０４０が要求時にＦＬＵＴＥファイルを伝達するＨＴＴＰプロキシサーバーを提供する時にのみ（第２スクリーンデバイス４２０５０はＴＶ受信機を含まないと仮定）、第２スクリーンデバイス４２０５０によって検索されうる。
本明細書はまた、第２スクリーンデバイス４２０５０上でのアプリケーションの開始を支援するためにＡＴＳＣ２．０受信機４２０４０上で実行されるパッケージアプリケーションに対するメカニズムを説明する。
図４３は、ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例である。
図４３は、ＡＴＳＣ２．０受信機と第２スクリーンデバイス間の直接接続を説明する。
ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例は、放送システム４３０１０、放送社ＡＴＳＣ２．０サーバー４３０２０、ＡＴＳＣ２．０受信機４３０３０及び／又は第２スクリーンデバイス４３０４０を含むことができる。
放送システム４３０１０は、放送システム４２０１０と同一であってもよい。
放送社ＡＴＳＣ２．０サーバー４３０２０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
ＡＴＳＣ２．０受信機４３０３０は、ＡＴＳＣ２．０受信機４２０４０と同一であってもよい。
第２スクリーンデバイス４３０４０は、第２スクリーンデバイス４２０５０と同一であってもよい。
ＡＴＳＣ２．０受信機４３０３０は、放送網に接続していて直接的に地上波放送受信が可能であってもよい。したがって、ＡＴＳＣ２．０受信機４３０３０では、ＤＴＶＣＣを通じて送信されるｉＴＶメッセージのＵＲＬストリングをＤＴＶＣＣサービス番号６で抽出可能であってもよい。また、ホームゲートウェイに接続していていつでも必要によってインターネットに接続可能であってもよい。そして、ホームネットワーク記述（ＵＰｎＰ）を用いて、他のホームネットワーク内に接続した装置と通信することができる。
第２スクリーンデバイス４３０４０はいずれもホームゲートウェイと接続していてそれぞれの装置間の通信が可能であり、自由にインターネット接近が可能であってもよい。ホームゲートウェイは、イーサネット（Ｅｔｈｅｒｎｅｔ）及びＷｉ−Ｆｉを支援する機能を全て備えていてもよい。
放送社は、インタラクティブサービスのためにインターネットにサーバーをおいて付加サービスを提供することができる。ＡＴＳＣ２．０受信機４３０３０や第２スクリーンデバイス４３０４０が接続して、ＴＤＯやモバイル用に作られたウェブページをダウンロードすることができる。ＡＴＳＣ２．０受信機４３０３０である場合には、ＴＶの解像度に合わせて作られたウェブページであり、第２スクリーンデバイス４３０４０である場合には、ＴＶと違い、解像度及び支援するＡＰＩｓが異なってもよいため、それに適合するように製作されうる。
図４４は、ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例である。
図４４は、ＡＴＳＣ２．０受信機及び第２スクリーンデバイス間の間接接続を説明する。
ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例は、放送システム４４０１０、放送社ＡＴＳＣ２．０サーバー４４０２０、放送社セッション管理４４０３０、ＡＴＳＣ２．０受信機４４０４０及び／又は第２スクリーンデバイス４４０５０を含むことができる。
放送システム４４０１０は、放送システム４２０１０と同一であってもよい。
放送社ＡＴＳＣ２．０サーバー４４０２０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
放送社セッション管理４４０３０は、間接接続において、第２スクリーンデバイス４４０５０とＡＴＳＣ２．０受信機４４０４０間の間接接続を管理する役割を担うことができる。
ＡＴＳＣ２．０受信機４４０４０は、ＡＴＳＣ２．０受信機４２０４０と同一であってもよい。
第２スクリーンデバイス４４０５０は、第２スクリーンデバイス４２０５０と同一であってもよい。
図４４の間接接続は、第２スクリーンデバイス４４０５０がホームゲートウェイを通じてＡＴＳＣ２．０受信機４４０４０に接続される場合ではなく、３ＧＰＰ網に直接接続してホームネットワークにあるＡＴＳＣ２．０受信機４４０４０と接続される場合であってもよい。この場合には、第２スクリーンデバイス４４０５０がホームネットワークに接続し難い場合或いはホームネットワークを支援するネットワークインターフェースがない場合に該当する。
この場合には、第２スクリーンデバイス４４０５０は、外部のインターネットサーバーが有しているＡＴＳＣ２．０受信機４４０４０の情報が必要でありうる。また、ＡＴＳＣ２．０受信機４４０４０は、動作時に、接続アドレスを外部にあるインターネットサーバーに報告して知らせなければならないことがある。
第２スクリーンデバイス上にインタラクティブサービスを效果的に伝達するための方案として、中央集中型（ｃｅｎｔｒａｌｉｚｅｄ）実行モデル及び分散型（ｄｉｓｔｒｉｂｕｔｅｄ）実行モデルがある。
図４５は、第２スクリーンサービスアプリケーションのソフトウェア層の一実施例を示す図である。
第２スクリーンデバイスは、一般的に、ＯＳを用いてアプリケーションを実行する。一般に、モバイル装置用ＯＳの一部の機能は、軽量化の目的から含まれなくてもよい。したがって、ＯＳによって支援されない機能がアプリケーションに含まれる必要がある。
図４５のソフトウェア層は、第２スクリーンサービスに必要な第２スクリーンサービスアプリケーションのソフトウェア構造を示す。図４５は、受信機が第２スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
第２スクリーンデバイスがインターネットコンテンツを再生するので、ＯＳはプラットホームＳＤＫを用いてウェブアプリケーションが実行され得る環境をプログラマーに提供することができる。環境は、ＯＳによって実行されるアプリケーションがインターネットコンテンツをディスプレイするようにＳＤＫの形態で提供することができる。
図４５で、第２スクリーンサービスアプリケーションは、第２スクリーンデバイス上で実行されうる。このアプリケーションは、アップストア（ＡｐｐＳｔｏｒｅ）（又は、任意の種類のアプリケーションマーケット）からダウンロードされうる。第２スクリーンサービスアプリケーションは、ＡＣＲクライアントを含むことができ、マイクロホン及びカメラを用いてＴＶ受像機からビデオ及びオーディオデータをキャプチャーすることができる。また、ＡＣＲクライアントは、ビデオ及びオーディオデータをサンプリングし、メディアシグネチャーをＡＣＲサーバーに送信することができる。第２スクリーンサービスアプリケーションは、ＯＳ上で実行可能であり、ＵＰｎＰフレームワークが何を動作させ得るかによって、ＨＴＴＰ、ＳＳＤＰ又はマルチキャストイベントなどのプロトコルを含み、ブラウザモジュールは、ウェブアプリケーションを実行及びディスプレイするために含まれうる。
ブラウザモジュールは、インターネットウェブページをレンダリングするモジュールであってもよい。ブラウザモジュールは、ウェブアプリケーション（例えば、ＥＣＭＡＳｃｒｉｐｔ、ＨＴＭＬ及びＸＨＴＭＬ）をレンダリングするウェブブラウザエンジンの核心部分である。また、ブラウザモジュールは、ＯＳによって提供されるブラウザと同一又は類似の機能を提供するソフトウェアモジュールを意味できる。ブラウザ及び制御可能な機能を利用する方法は、ＯＳ別に異なる。
第２スクリーンアプリケーションは、第２スクリーンデバイス用に設計されたウェブアプリケーションであってもよい。第２スクリーンアプリケーションは、ＥＣＭＡＳｃｒｉｐｔ又はウェブアプリケーションによって機能を呼び出すウェブアプリケーションであってもよく、そのサイズは、モバイルＯＳによって提供されるブラウザモジュールで実行されるように制御されうる。このウェブアプリケーションは、第２スクリーンサービスアプリケーションで実行されうる。
モバイル装置用オペレーティングシステムは、ハードウェアを支援するドライバで構成され、カーネル特定（ｋｅｒｎｅｌ−ｓｐｅｃｉｆｉｃ）サービス用ドライバを含むことができる。基本的に、ＩＰ、ＴＣＰ及びＵＤＰプロトコルを支援することができる。ネットワークプロトコルスタックは、ＯＳ上に存在する。ＵＰｎＰの場合、ＨＴＴＰは、ＵＤＰを用いて送信することができる。
ＵＰｎＰ ＤＣＰフレームワークは、ＵＰｎＰフォーラムに定義されたデバイス制御ポイントを意味することができる。
ＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）は、ホームネットワークでネックワークに接続されたデバイスによって一つ以上のサービスを探すことができる。
図４６は、第２スクリーンサービスアプリケーションのソフトウェア層を示す図である。
図４６のソフトウェア層は、第２スクリーンサービスに必要な第２スクリーンサービスアプリケーションのソフトウェア構造を示す。図４６は、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
図４６のそれぞれのエンティティの説明は、その役割及び機能において図４５と同一である。
ＡＴＳＣ２．０トリガークライアントは、上述したトリガー、ＴＰＴ、ＡＭＴなどを受信し処理するモジュールを意味できる。このモジュールは、状況によって第２スクリーンデバイスに含まれてもよい。このモジュールが第２スクリーンデバイスに含まれると、このモジュールはＴＰＴ及びＡＭＴを直接処理し、アプリケーションのライフサイクルを直接チェックすることができる。
図４７は、第２スクリーンアプリケーションライフサイクル管理による送信順序及び送信されたデータ間の違いを示すテーブルである。
受信機は、放送ネットワークを通じてＤＴＶＣＣを用いてＴＰＴ及びＡＭＴを直接受信したり、インターネットネットワークを通じてＴＰＴ及びＡＭＴをダウンロードし、ＴＰＴ及びＡＭＴを処理する。上述した通り、ＴＰＴはイベント情報を含み、イベント情報は、ＥｖｅｎｔＩｄ、Ａｃｔｉｏｎ、Ｄｅｓｔｉｎａｔｉｏｎ及びＤａｔａ情報を含むことができる。“Ｅｖｅｎｔ＠Ｄｅｓｔｉｎａｔｉｏｎ”は、このイベント情報が発生する装置を示すことができる。例えば、あて先は、受信機又は第２スクリーンデバイスであってもよい。あて先が第２スクリーンデバイスに設定されると、受信機は、第２スクリーンデバイスにイベント情報を伝達しなければならない。
このため、この情報を第２スクリーンデバイスに伝達する方法が必要である。第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションで管理することができる。
図４７のテーブルは、どのエンティティが第２スクリーンアプリケーションのライフサイクルを支援するかによる情報伝達方法の概要を示す。
第１行は、図５１の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
第２行は、受信機が第２スクリーンアプリケーションのライフサイクルを管理する場合の説明の概要であってもよく、その詳細な説明は後述する。
第３行は、受信機が第２スクリーンデバイスに必要なトリガー情報をフィルタリング（増加）し伝達する場合の説明の概要であってもよく、その詳細な説明は後述する。
第４行は、図５８の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
第５行は、図５７の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
図４８は、中央集中型実行モデルの動作概念を示す図である。
インタラクティブサービスを第２スクリーンデバイスに效率的に伝達する方法は、中央集中型実行モデル及び分散型実行モデルを含むことができる。
中央集中型実行モデルの動作概念を示す図に示すように、ＴＶ受像機は、ＵＰｎＰのＲＵＩメカニズムを用いて、各第２スクリーンデバイス上にディスプレイされるＲＵＩを生成及びアップデートし、ネットワークを通じてＲＵＩを送信することができる。それぞれの第２スクリーンデバイスは、ＲＵＩクライアントを通じて実時間でＲＵＩを受信し、スクリーン上にＲＵＩをディスプレイすることができる。分散型実行モデルと違い、ＤＡＥは、プライマリデバイスに存在しうる。
図４９は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。
図４９のフローは、中央集中型実行モデルの動作概念の実施例で受信機が放送ネットワークを通じてインタラクティブサービスを得ることができ、第２スクリーンデバイスと連動する環境で中央集中型実行モデルメカニズムが適用される時の動作であってもよい。
中央集中型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ４９０１０）、ＴＰＴを要求する段階（ｓ４９０２０）、応答としてＴＰＴを送信する段階（ｓ４９０３０）、ＴＰＴをパーシング（ｐａｒｓｅ）する段階（ｓ４９０４０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ４９０６０）、ＲＵＩを生成する段階（ｓ４９０７０）、ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９０８０）、スクリーン上にＵＩをディスプレイする段階（ｓ４９０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ４９１００）、入力データを送信する段階（ｓ４９１１０）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ４９１２０）、ＲＵＩをアップデートする段階（ｓ４９１３０）、ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９１４０）、及び／又はスクリーン上にＵＩをディスプレイする段階（ｓ４９１５０）を含むことができる。
時間ベーストリガーを送信する段階（ｓ４９０１０）は、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて時間ベーストリガーを受信する段階を含むことができる。時間ベーストリガーは上述した通りである。
ＴＰＴを要求する段階（ｓ４９０２０）は、受信機が、受信されたトリガーを解釈する段階、ＴＰＴを取得できるサーバーのＵＲＬを取得する段階、及びＴＰＴを要求できる段階を含むことができる。
応答としてＴＰＴを送信する段階（ｓ４９０３０）は、ＴＰＴを要求する段階（Ｓ４９０２０）における要求に応答してＴＰＴを送信する段階を含むことができる。
ＴＰＴをパーシングする段階（ｓ４９０４０）は、受信機が、要求されたＴＰＴをパーシングする段階を含むことができる。
第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）は、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて第２スクリーンに対する実行トリガーを受信する段階を含むことができる。実行トリガーは、上述した活性化トリガーと同一であってもよい。
ＴＤＯ／ファイルをダウンロードする段階（ｓ４９０６０）は、受信機が、受信したＴＰＴから実行トリガー又は時間ベーストリガーと関連したＴＤＯ及びファイルに関する情報を取得する段階、及びコンテンツサーバーからトリガーで指示されたＴＤＯ及びファイルをダウンロードする段階を含むことができる。
ＲＵＩを生成する段階（ｓ４９０７０）は、ダウンロードされたＴＤＯ及びファイルに対するＲＵＩを生成する段階を含むことができる。
ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９０８０）は、受信機がＲＵＩプロトコルを用いて、第２スクリーン上に生成されたＲＵＩを送信する段階を含むことができる。
スクリーン上にＵＩをディスプレイする段階（ｓ４９０９０）は、第２スクリーン上に、受信されたＲＵＩをディスプレイする段階を含むことができる。
ユーザが新しいページに対するリンクをクリックする段階（ｓ４９１００）は、第２スクリーン上でユーザの選択によってＲＵＩ上の特定リンクをクリックする段階を含むことができる。
入力データを送信する段階（ｓ４９１１０）は、クリックされた特定リンクが他のページに接続されると、受信機にユーザの入力情報を伝達する段階を含むことができる。
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ４９１２０）は、受信機がユーザ入力と関連したＴＤＯ及びファイルをダウンロードする段階を含むことができる。
ＲＵＩをアップデートする段階（ｓ４９１３０）は、ダウンロードされたＴＤＯ及びファイルによってＲＵＩをアップデートする段階を含むことができる。
ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９１４０）は、受信機がＲＵＩプロトコルを用いて、アップデートされたＲＵＩを第２スクリーンに送信する段階を含むことができる。
スクリーン上にＵＩをディスプレイする段階（ｓ４９１５０）は、第２スクリーン上にアップデートされたＲＵＩをディスプレイする段階を含むことができる。
図５０は、受信機で第２スクリーンデバイスにＵＩ情報を知らせる方法の実施例を示す図である。
図５０は、受信機が放送社からトリガーを受信してトリガーを第２スクリーンデバイスに伝達する論理的順序を示す。
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５００１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５００３０）、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）、応答として互換可能なＵＩ情報を送信する段階（ｓ５００５０）、及び受信機に対する他のトリガーを受信する段階（ｓ５００６０）を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５００１０）は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）は、プライマリデバイスが放送ストリームを通じて放送社から第２スクリーンサービスに対するトリガーを受信する段階を含むことができる。
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５００３０）は、アップデートされたＵＩに対して通知する段階を含むことができる。上述した通り、放送プログラムを見る間にトリガーが受信されると、受信機は、トリガーが第２スクリーンデバイス又はプライマリデバイスに対するものか否かをチェックすることができる。この時、トリガーが第２スクリーンデバイスに対するものであれば、全てのＵＰｎＰデバイス又は特定ＵＰｎＰデバイスにのみ新しいＵＩ情報アップデートを通知することができる。これは、第２スクリーンデバイスがＵＰｎＰプロトコルを用いて加入した場合に該当しうる。
アップデートされたＵＩ情報を要求する段階（ｓ５００４０）は、第２スクリーンデバイスがプライマリデバイスに、アップデートされたＵＩ情報を要求する段階を含むことができる。
応答として互換可能なＵＩ情報を送信する段階（ｓ５００５０）は、プライマリデバイスが第２スクリーンデバイスに互換可能なＵＩ情報を送信する段階を含むことができる。
受信機に対する他のトリガーを受信する段階（ｓ５００６０）は、受信機に対するトリガーを受信する段階と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
受信機がトリガーモジュールを含んでもよいため、受信機は、放送ネットワーク又はインターネットネットワークを通じてＴＰＴ及びＡＭＴなどのＸＭＬファイルを受信し、ＸＭＬファイルをパーシングし、適切な動作を行うことができる。第２スクリーンデバイスを探すと、第２スクリーンデバイスに伝達されるアクション、ＴＤＯ ＵＲＬ及びデータは、Ｅｖｅｎｔ＠Ｄｅｓｔｉｎａｔｉｏｎフィールドを用いて認識することができる。第２スクリーンデバイスは、ＴＰＴ及びＡＭＴなどのＸＭＬファイルを直接受信しなくてもよく、よって、トリガーモジュールを含まなくてもよい。ＲｅｍｏｔｅＵＩクライアントサービスが含まれると、受信機は、全ての第２スクリーンアプリケーションのライフサイクルを管理することができる。逆に、いくつかの第２スクリーンデバイスが接続されると、第２スクリーンアプリケーションを制御するデータが数回送信されなければならない。
図５１は、受信機で第２スクリーンデバイスにＵＩ情報を通知する方法の実施例を示す図である。
図５０と違い、図５１は、第２スクリーンデバイスに適切に用いられると決定された第２スクリーンデバイスに対する全てのＵＩ情報が直接伝達される場合を示す。すなわち、第２スクリーンデバイスに対するＴＤＯ ＵＲＬを送信することができる。
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５１０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０２０）、ＵＩ情報に対して通知する段階（ｓ５１０３０）、応答“ｏｋ”を送信する段階（ｓ５１０４０）、受信機に対するトリガーを受信する段階（ｓ５１０５０）、受信機に対するトリガーを受信する段階（ｓ５１０６０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０７０）、ＵＩ情報に対して通知する段階（ｓ５１０８０）、及び／又は応答“ｏｋ”を送信する段階（ｓ５１０９０）を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５１０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
ＵＩ情報に対して通知する段階（ｓ５１０３０）は、ＵＩ情報アップデートに対して通知する段階を含むことができる。
応答“ｏｋ”を送信する段階（ｓ５１０４０）は、ＵＩ通知が受信されたことを示すメッセージを送信する段階を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５１０５０）、及び受信機に対するトリガーを受信する段階（ｓ５１０６０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０７０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
ＵＩ情報に対して通知する段階（ｓ５１０８０）は、ＵＩ情報に対して通知する段階（ｓ５１０３０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
応答“ｏｋ”を送信する段階（ｓ５１０９０）は、応答“ｏｋ”を送信する段階（ｓ５１０４０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
図５１の方法で、受信機は、どのＵＰｎＰデバイスが第２スクリーンデバイスであるか、及びいかなるデバイスプロファイルが含まれるかを知っていなければならない。特に、受信機は、第２スクリーンデバイスが第２スクリーンサービスを支援するかを知っていなければならない。
トリガーが第２スクリーンデバイス又はプライマリデバイスに関するものかを決定した後に、ＵＩ情報に対して通知する方法、及び第２スクリーンデバイスに適切に用いられると決定された第２スクリーンデバイスに対する全てのＵＩ情報を伝達する方法（図５１の場合）は、受信機がＴＰＴ及びトリガーを処理し、ＴＤＯ ＵＲＬのみを第２スクリーンデバイスに伝達するという点で同一でありうる。これら２つの方法は、受信機がＴＤＯを第２スクリーンデバイスに間接的に伝達したり、受信機が各デバイスのデバイスプロファイルを直接記録し、第２スクリーンデバイスにのみ第２スクリーンアプリケーションの位置を通知するという点で異なりうる。
図５２は、ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの実施例を示す図である。
ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの一実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５２０１０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０２０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５２０３０）、イベントを申し込む段階（ｓ５２０４０）、ＨＴＴＰメッセージを返還する段階（ｓ５２０５０）、ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）及び／又はＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）を含むことができる。
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５２０１０）は、受信機及び第２スクリーンデバイスを探す段階を含むことができる。ホームネットワークに新しく接続されたデバイス又はホームネットワークに既に接続されたデバイス（受信機又は第２スクリーンデバイス）は、ディスカバリのためのメッセージをマルチキャストすることができる。このとき、所望のサービスをマルチキャスティングを用いて探索することができ、複数の不特定ＵＰｎＰデバイスに対して全てのサービスを探索することができる。これは、デバイスによってどのサービスが提供されるかによって変更されてもよい。この段階で、第２スクリーンデバイスは、プライマリデバイスのデバイスプロファイルを知っていてもよい。プライマリデバイスは、デバイスプロファイルを処理し、適切なＵＩＬｉｓｔｉｎｇを生成することができる。ＲｅｍｏｔｅＵＩサーバーは、ＣｏｍｐａｔｉｂｌｅＵＩｓ ＸＳＤスキマー（ｓｃｈｅｍａ）を第２スクリーンデバイスに提供することができる。このスキマーは、アプリケーションのＵＲＬ、ＵＩに対する固有ｉｄ（“ｕｉＩＤ”）、ネーム、ｐｒｏｔｏｃｏｌＩｎｆｏなどを含むことができる。
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０２０）は、第２スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びＵＩＬｉｓｔｉｎｇを要求する段階を含むことができる。互換可能なＵＩが得られるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる（ＵＩＦｉｌｔｅｒは選択的であってもよい）。その詳細な説明は後述する。
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５２０３０）は、プライマリデバイスが、要求によって、適切なＵＩリスティングを第２スクリーンデバイスに送信する段階を含むことができる。その詳細な説明は後述する。
イベントを申し込む段階（ｓ５２０４０）は、プライマリデバイスの適切な露出されたイベントを申し込む段階を含むことができる。イベントを申し込む段階（ｓ５２０４０）は、ＲｅｍｏｔｅＵＩサーバーサービスによって提供されたイベント情報である“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”を受信するために選択的に行うことができる。Ｉｎ ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）で、第２スクリーンデバイスは、ＲｅｍｏｔｅＵＩのアドレスが変更されたり又はＵＩが変更されたという通知を受けることができる。すなわち、第２スクリーンデバイスがＵＩが変更された通知のみを受けるから、詳細な位置又は追加の情報が要求されると、“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションが受信機に送信され、“ＵＩＬｉｓｔｉｎｇ”値を得ることができる。
ＨＴＴＰメッセージを返還する段階（ｓ５２０５０）は、イベントを申し込む段階（ｓ５２０４０）の結果を送信する段階を含むことができる。応答１を送信する段階（ｓ４０１００）と同様に、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答が状況によって伝送されうる。
ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）は、加入者に“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを送信する段階を含むことができる。
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）は、第２スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びＵＩＬｉｓｔｉｎｇを要求する段階を含むことができる。互換可能なＵＩが得られるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる。ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）及びＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）は、第２スクリーンアプリケーションが変更されず、サーバーによって支援される時にのみ選択的に可能なように時間設定を行う段階を含むことができる。この段階は選択的だ。この方法は、受信機でＵＰｎＰイベントを用いて、第２スクリーンサービスが存在することを全ての第２スクリーンデバイスに通知する方法であってもよい。すなわち、ホームネットワーク内の全ての第２スクリーンデバイスは第２スクリーンサービスと関連してＵＩが変更されたとの通知を受けることができる。全ての第２スクリーンデバイスにＵＰｎＰイベントにて“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数が通知されると、第２スクリーンデバイスは、ＵＩが新しくアップデートされたということを確認することができる。その後、第２スクリーンデバイスは、“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを行い、ハードウェア装置に適したＵＩを選択し、デバイスプロファイルを参考にすることによってＵＩを実行することができる。
ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）は、プライマリデバイスが要求によって適切なＵＩリスティングを第２スクリーンデバイスに送信する段階を含むことができる。上述した通り、ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）は、ＲｅｍｏｔｅＵＩのアドレスが変更されたりＵＩが変更されたことを申請した第２スクリーンデバイスに通知する段階を含むことができる。すなわち、第２スクリーンデバイスは、ＵＩが変更されたことのみが通知されるため、詳細な位置又は追加の情報が要求されると、“ＵＩＬｉｓｔｉｎｇ”を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを受信機に送信しなければならない。
ＲｅｍｏｔｅＵＩサーバーサービスが動作すると、受信機は、要求する装置のデバイスプロファイルによって遠隔ＵＩ情報を提供しなければならない。逆互換性の観点から、デバイスプロファイル“ＤｅｖｉｃｅＩｎｆｏ”が交換され、後で受信機に“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求する時、ＲｅｍｏｔｅＵＩサーバーサービスによって送信されたＵＲＬが、要求するクライアントのプロファイルによって変更されうる。レガシーＵＰｎＰデバイスがＲｅｍｏｔｅＵＩサーバーに“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求すると、レガシーＵＰｎＰデバイスのＤｅｖｉｃｅＩｎｆｏに適したＵＩが提供されなければならない。しかし、第２スクリーンサービスを支援するデバイスが“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求すると、ＲｅｍｏｔｅＵＩサーバーサービス装置はさらにＵＲＬ情報を送信しなければならない。
受信機は、ＤＴＶＣＣを通じてトリガー情報を得、トリガー情報からメディア時間及びイベント時間情報を得ることができる。このとき、“ａｐｐＩＤ”、“ＵＲＬ”（ＴＤＯ＿ＵＲＬ）、“ｅｖｅｎｔＩＤ”、“ａｃｔｉｏｎ”、及び、選択的に、ＴＤＯ又は実行時間に対する“Ｄａｔａ”は、“ｔ＝ｍｅｄｉａ＿ｔｉｍｅ”シンタックスを用いて確認できる。受信機が第２スクリーンアプリケーションのライフサイクルを管理すると、第２スクリーンサービスアプリケーションによって処理される情報の量が減少しうる。逆に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを直接管理すると、必要な情報が増加しうる。
図５３は、分散型実行モデルの動作概念を示す図である。
第２スクリーンデバイスにインタラクティブサービスを効率的に伝達する方法として、分散型実行モデルを説明する。
分散型実行モデルの動作概念を示す図に示すように、ＴＶ受像機は、ＵＰｎＰなどを用いて第２スクリーンデバイスにトリガーなどの情報を伝達することができる。それぞれの第２スクリーンデバイスはトリガーハンドラーを有し、トリガーハンドラーを通じて受信されたトリガーなどの情報を実時間で処理することができる。ブラウザは、それと関連したインタラクティブサービスを実行することができる。
中央集中型実行モデルと違い、各第２スクリーンデバイスにＤＡＥが存在してもよい。
分散型実行モデルに基づいて第２スクリーンデバイスにインタラクティブサービスを伝達するプロセスは、次の順序で行うことができる。１．受信機は、第２スクリーン支援を有するセグメントを提示している。２．受信機は、第２スクリーン支援が利用可能な任意の指示をディスプレイする。３．ユーザは、第２スクリーンデバイス上で第２スクリーンアプリケーションを開始する。４．受信機及び第２スクリーンデバイスは、（受信機上のネイティブコード及びデバイス上の第２スクリーンアプリケーションによって行われる）ＵＰｎＰメカニズムを通じてお互い発見する。５．ＴＶ受像機は、（ＤＴＶＣＣストリーム又はＡＣＲから）トリガーを得、第２スクリーンデバイス上でＴＤＯを開始する。６．ＴＶ受像機は、トリガーをＴＰＴからの情報と結合し、活性化時間に第２スクリーンデバイスに送信する。７．第２スクリーンデバイスは、ＴＤＯ（一つ以上のファイル）をダウンロードしてブラウザで実行する。８．ユーザはＴＤＯと相互作用してＴＤＯが追加のファイルをダウンロードてきるようにする。９．受信機は、トリガーを得、第２スクリーンデバイス上でＴＤＯに対するイベントを生成する。１０．受信機はトリガーとＴＰＴからの情報とを結合し、活性化時間に第２スクリーンデバイスに送信する。１１．第２スクリーンデバイスは、ブラウザでＴＤＯに対する（ＤＶＢ ＳｔｒｅａｍＥｖｅｎｔのような）ＴｒｉｇｇｅｒＥｖｅｎｔを生成する。１２．ＴＤＯは、ＴｒｉｇｇｅｒＥｖｅｎｔによって要求されたアクションを行ってデータファイルをダウンロードすることができる。
図５４は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローを示す図である。
分散型実行モデルのフローは、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて受信された情報をそのまま第２スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ５４０１０）、時間ベーストリガーを送信する段階（ｓ５４０２０）、ＴＰＴを要求する段階（ｓ５４０３０）、ＴＰＴを応答として送信する段階（ｓ５４０４０）、ＴＰＴをパーシングする段階（ｓ５４０５０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）、実行トリガーを送信する段階（ｓ５４０７０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）、ブラウザでＴＤＯを実行する段階（ｓ５４０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）、及びブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）を含むことができる。
時間ベーストリガーを送信する段階（ｓ５４０１０）は、時間ベーストリガーを送信する段階（ｓ４９０１０）と同一であってもよい。
時間ベーストリガーを送信する段階（ｓ５４０２０）は、受信機が受信されたトリガーをそのまま第２スクリーンに送信する段階を含むことができる。
ＴＰＴを要求する段階（ｓ５４０３０）は、第２スクリーンが受信されたトリガーを解釈する段階、ＴＰＴが得られるサービスのＵＲＬを取得する段階、及びＴＰＴを要求できる段階を含むことができる。
応答としてＴＰＴを送信する段階（ｓ５４０４０）は、ＴＰＴを要求する段階（ｓ５４０３０）における要求に応答してＴＰＴを送信する段階を含むことができる。
ＴＰＴをパーシングする段階（ｓ５４０５０）は、要求されたＴＰＴをパーシングする段階を含むことができる。
第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）は、第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）と同一であってもよい。
実行トリガーを送信する段階（ｓ５４０７０）は、受信機が受信されたトリガーをそのまま第２スクリーンに送信する段階を含むことができる。
ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）は、ＴＰＴからのトリガーと関連したＴＤＯ／ファイルを得る段階、及びコンテンツサーバーからＴＤＯ／ファイルをダウンロードする段階を含むことができる。
ブラウザでＴＤＯを実行する段階（ｓ５４０９０）は、ダウンロードされたＴＤＯ及びファイルをブラウザ上で実行する段階を含むことができる。
ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）は、ユーザが、実行されたＴＤＯ上で特定リンクをクリックする段階を含むことができる。
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）は、他のＴＤＯへの特定リンクが確立されると、関連したＴＤＯ／ファイルをダウンロードする段階を含むことができる。
ブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）は、ブラウザ上で関連したＴＤＯ及びファイルを実行する段階を含むことができる。
図５５は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローを示す図である。
分散型実行モデルのフローは、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて受信された情報をそのまま第２スクリーンに送信せず、第２スクリーンに適したトリガーによって必要な情報を挿入し、その情報を拡張されたトリガーに変更し、その情報を第２スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ５５０１０）、ＴＰＴを要求する段階（ｓ５５０２０）、応答としてＴＰＴを送信する段階（ｓ５５０３０）、ＴＰＴをパーシングする段階（ｓ５５０４０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ５５０５０）、拡張されたトリガーを生成する段階（ｓ５５０６０）、拡張されたトリガーを送信する段階（ｓ５５０７０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ５５０８０）、ブラウザでＴＤＯを実行する段階（ｓ５５０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ５５１００）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５５１１０）、及び／又はブラウザで新しいＴＤＯを実行する段階（ｓ５５１２０）を含むことができる。
時間ベーストリガーを送信する段階（ｓ５５０１０）は、時間ベーストリガーを送信する段階（ｓ５４０１０）と同一であってもよい。
ＴＰＴを要求する段階（ｓ５５０２０）は、ＴＰＴを要求する段階（ｓ５４０３０）と同一であってもよい。
応答としてＴＰＴを送信する段階（ｓ５５０３０）は、応答としてＴＰＴを送信する段階（ｓ５４０４０）と同一であってもよい。
ＴＰＴをパーシングする段階（ｓ５５０４０）は、ＴＰＴをパーシングする段階（ｓ５４０５０）と同一であってもよい。
第２スクリーンに対する実行トリガーを送信する段階（ｓ５５０５０）は、第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）と同一であってもよい。
拡張されたトリガーを生成する段階（ｓ５５０６０）は、受信機がＴＰＴからのトリガーと関連したＴＤＯ及びファイルに関する情報を取得する段階、及びそれを含む拡張されたトリガーを生成する段階を含むことができる。
拡張されたトリガーを送信する段階（ｓ５５０７０）は、受信機が拡張されたトリガーを第２スクリーンに送信する段階を含むことができる。
ＴＤＯ／ファイルをダウンロードする段階（ｓ５５０８０）は、ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）と同一であってもよい。
ブラウザでＴＤＯを実行する段階（ｓ５５０９０）は、ブラウザでＴＤＯを実行する段階（ｓ５４０９０）と同一であってもよい。
ユーザが新しいページに対するリンクをクリックする段階（ｓ５５１００）は、ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）と同一であってもよい。
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５５１１０）は、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）と同一であってもよい。
ブラウザで新しいＴＤＯを実行する段階（ｓ５５１２０）は、ブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）と同一であってもよい。
図５６は、受信機が第２スクリーンデバイスにＴＤＯ及びイベント情報を通知する方法の一実施例を示す図である。
図５６は、受信機がトリガー及びＴＰＴを受信し、トリガーによって処理を行い、第２スクリーンデバイスに対するトリガーが到達すると、トリガーをＴＰＴと比較して、第２スクリーンデバイスに認識される必要がある情報を抽出してＸＭＬファイルの形態で構成し、その情報を第２スクリーンデバイスに送信する方法を示す。この方法は、第２スクリーンデバイスが活発に動作して予測を行えるという点で有利である。
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５６０１０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０２０）、ＴＰＴ及びトリガーを変換（ｔｒａｎｓｌａｔｅ）し、イベント情報を生成する段階（ｓ５６０３０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６０４０）、応答“ｏｋ”を送信する段階（ｓ５６０５０）、受信機に対するトリガーを受信する段階（ｓ５６０６０）、受信機に対するトリガーを受信する段階（ｓ５６０７０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）、及び応答“ｏｋ”を送信する段階（ｓ５６１１０）を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５６０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０２０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０３０）は、ＴＰＴ及びトリガーを解釈する段階、及びイベントを生成する段階を含むことができる。生成された情報は、新しいデータ構造を生成するために、ＴＰＴに含まれた情報及びトリガーを結合するのに用いられ、どのようなＴＤＯが生成されたか、又はいつＴＤＯが生成されたかに関する情報を含むことができる。このデータ構造は後述する。新しいデータ構造が決定されると、ＴＤＯ ＵＲＬに加えて、様々な必要な情報が送信されうる。
ＴＤＯ及びイベントを送信する段階（ｓ５６０４０）は、生成されたイベント情報及びＴＤＯを第２スクリーンデバイスに送信する段階を含むことができる。
応答“ｏｋ”を送信する段階（ｓ５６０５０）は、受信されたＴＤＯ及びイベント情報が受信されたことを示すメッセージを送信する段階を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５６０６０）、及び受信機に対するトリガーを受信する段階（ｓ５６０７０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）は、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０３０）と同一であってもよい。
ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）は、ＴＤＯ及びイベント情報を送信する段階（ｓ５６０４０）と同一であってもよい。
応答“ｏｋ”を送信する段階（ｓ５６１１０）は、応答“ｏｋ”を送信する段階（ｓ５６０５０）と同一であってもよい。
受信機に対するトリガーを受信する段階（ｓ５６０６０）、受信機に対するトリガーを受信する段階（ｓ５６０７０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）、及び応答“ｏｋ”を送信する段階（ｓ５６１１０）は、上述した動作と同一であってもよい。
図５７は、第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーションにアクセスする方法の実施例を示す図である。
第２スクリーンデバイスは、受信機がＴＰＴ及びＡＭＴなどのＸＭＬファイルを受信したり、インターネットを通じてＴＰＴ及びＡＭＴサーバーアドレスを知ると、第２スクリーンアプリケーションを直接実行できる独立装置である。この場合、トリガーモジュールが第２スクリーンデバイスに含まれる。第２スクリーンデバイスは、受信機によって受信されたｉＴＶメッセージに対するＵＲＩストリングを受信することができる。このメッセージは、１）ＲｅｍｏｔｅＵＩサーバーサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法、及び２）ＲｅｍｏｔｅＵＩクライアントサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法の両方に適用することができる。
まず、ＲｅｍｏｔｅＵＩサーバーサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法を説明する。
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５７０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０２０）、アップデートされたＵＩ情報に関する通知を送信する段階（ｓ５７０３０）、アップデートされたＵＩ情報を要求する段階（ｓ５７０４０）、応答としてＵＩ情報を送信する段階（ｓ５７０５０）、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０８０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７０９０）、アップデートされたＵＩ情報を要求する段階（ｓ５７１００）、応答としてＵＩ情報を送信する段階（ｓ５７１１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７１２０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７１３０）、アップデートされたＵＩ情報を要求する段階（ｓ５７１４０）、応答としてＵＩ情報を送信する段階（ｓ５７１５０）、第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）、及び／又は第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５７０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。第１トリガーは、第２スクリーンデバイスに対するものでないから、受信機はトリガーを第２スクリーンデバイスに伝達しない。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。トリガーは、第２スクリーンサービスに対するメディア時間に関する情報を有することができる。第２トリガーは、上述したプリロード（ｐｒｅ−ｌｏａｄ）トリガーとして機能し得る。
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７０３０）は、アップデートされたＵＩ情報を通知する段階を含むことができる。第２トリガーは、第２スクリーンデバイスに対するものであるから、受信機は受信されたＵＲＩＳｔｒｉｎｇを第２スクリーンデバイスに送信することができる。このとき、第２スクリーンデバイスは、新しい情報が存在するという通知を受けることができ、この情報を直接読み取ることができる。
アップデートされたＵＩ情報を要求する段階（ｓ５７０４０）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
応答としてＵＩ情報を送信する段階（ｓ５７０５０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。この時、第２トリガーが送信されてもよい。
ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）は、第２スクリーンデバイスがプライマリデバイスから受信された情報（第２トリガー）をパーシングする段階、及びＴＰＴサーバーにＴＰＴ ＸＭＬファイルを要求する段階を含むことができる。
ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）は、第２スクリーンデバイスがＴＰＴサーバーから要求されたＴＰＴ ＸＭＬファイルをダウンロードする段階を含むことができる。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０８０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第３トリガーは、第２スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第３トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
アップデートされたＵＩ情報に関する通知を送信する段階（ｓ５７０９０）は、アップデートされたＵＩ情報を通知する段階を含むことができる。第３トリガーが第２スクリーンデバイスと関連したものとと決定されるため、受信機は、第３トリガーを第２スクリーンデバイスに通知することができる。
アップデートされたＵＩ情報を要求する段階（ｓ５７１００）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
応答としてＵＩ情報を送信する段階（ｓ５７１１０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。このとき、第３トリガーが送信されてもよい。しかし、第３トリガーは、メディア時間トリガーであるから、第２スクリーンデバイスのメディア時間のみを制御することができる。このため、第２スクリーンデバイス及び受信機間のメディア時間同期化を行うことができる。
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５７１２０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第４トリガーは、第２スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第４トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７１３０）は、アップデートされたＵＩを通知する段階を含むことができる。第４トリガーは、第２スクリーンデバイスと関連したものと決定されるため、受信機は第２スクリーンデバイスに第４トリガーを通知することができる。
アップデートされたＵＩ情報を要求する段階（ｓ５７１４０）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
応答としてＵＩ情報を送信する段階（ｓ５７１５０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。このとき、第４トリガーが送信されてもよい。
第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）は、第２スクリーンデバイスが第４トリガーに関する情報をチェックする段階、及びＴＤＯ ＵＲＬの位置の第２スクリーンアプリケーションをダウンロードするためにアプリケーションサーバーに第２スクリーンアプリケーションを要求する段階を含むことができる。
第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）は、要求によって第２スクリーンアプリケーションをダウンロードする段階を含むことができる。第２スクリーンアプリケーションがダウンロードされ、Ｅｖｅｎｔ＠Ａｃｔｉｏｎを行うことができる。このとき、アプリケーションサーバーに第２スクリーンデバイスのブラウザに関する情報を通知するので、アプリケーションサーバーは、どの第２スクリーンデバイスが接続されるかを容易にチェックすることができる。したがって、アプリケーションは自動で選択され、サーバーからダウンロードされることが可能である。
要約すると、ｉＴＶメッセージに対するＵＲＩストリングがＤＴＶＣＣを通じて受信されると、受信機は、新しいＵＩがアップデートされたということを示すイベントを、発見された第２スクリーンデバイスに送信することができる。第２スクリーンデバイスは、イベント情報をチェックし、新しいＵＩ情報を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを送信することができる。受信機は、ＴＰＴサーバーの受信されたＵＲＩ情報を送信することができる。この方法によって、第２スクリーンデバイスはＵＲＩ情報を受信し、ＴＰＴ及びＡＭＴ情報を直接処理し、第２スクリーンアプリケーションを直接制御することができる。
このプロセスは、ＡＴＳＣ２．０トリガークライアントが第２スクリーンサービスアプリケーションに含まれる場合に可能である。
図５８は、第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーションをアクセスする方法の実施例を示す図である。
上述した２つの方法のうち、ＲｅｍｏｔｅＵＩクライアントサービスの場合にｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法を説明する。
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５８０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０２０）、トリガーを通知する段階（ｓ５８０３０）、応答“ｏｋ”を送信する段階（ｓ５８０４０）、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５８０５０）、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５８０６０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５８０７０）、トリガーを通知する段階（ｓ５８０８０）、応答“ｏｋ”を送信する段階（ｓ５８０９０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８１００）、トリガーを通知する段階（ｓ５８１１０）、応答“ｏｋ”を送信する段階（ｓ５８１２０）、第２スクリーンアプリケーションを要求する段階（ｓ５８１３０）及び／又は第２スクリーンアプリケーションを返還する段階（ｓ５８１４０）を含むことができる。
受信機に対するトリガーを受信する段階（ｓ５８０１０）は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。第１トリガーが受信機に対するものであるから、第１トリガーは第２スクリーンデバイスに伝達されない。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第２トリガーは、第２スクリーンサービスに対するトリガーであり、メディア時間に関する情報を有することができる。第２トリガーは、上述したプリロードトリガーとして機能し得る。
トリガーを通知する段階（ｓ５８０３０）は、図５７と違い、第２スクリーンデバイスに直ちにトリガーを送信する段階を含むことができる。ｉＴＶメッセージに対するＵＲＩストリングがＤＴＶＣＣを通じて受信されると、受信機は、“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションを用いて、受信機によって受信されたＵＲＩ値を第２スクリーンデバイスに伝達することができる。
応答“ｏｋ”を送信する段階（ｓ５８０４０）は、トリガーが受信されたことを示すメッセージを送信する段階を含むことができる。
ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５８０５０）は、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）と同一であってもよい。第２スクリーンデバイスに含まれるトリガーモジュールは、受信されたＵＲＩ値を用いてＴＰＴサーバーにアクセスし、ＴＰＴ及びＡＭＴファイルをダウンロードし、第２スクリーンアプリケーションを直接制御することができる。
ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５８０６０）は、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）と同一であってもよい。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０７０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第３トリガーは、第２スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第３トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
トリガーを通知する段階（ｓ５８０８０）は、トリガーを通知する段階（ｓ５８０３０）と同様に、トリガーを伝達する段階を含むことができる。
応答“ｏｋ”を送信する段階（ｓ５８０９０）は、応答“ｏｋ”を送信する段階（ｓ５８０４０）と同一であってもよい。
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８１００）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第４トリガーは、第２スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第４トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
トリガーを通知する段階（ｓ５８１１０）は、トリガーを通知する段階（ｓ５８０３０）と同様に、トリガーを伝達する段階を含むことができる。
応答“ｏｋ”を送信する段階（ｓ５８１２０）は、応答“ｏｋ”を送信する段階（ｓ５８０４０）と同一であってもよい。
第２スクリーンアプリケーションを要求する段階（ｓ５８１３０）は、第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）と同一であってもよい。
第２スクリーンアプリケーションを返還する段階（ｓ５８１４０）は、第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）と同一であってもよい。
すなわち、受信機は、常に、第２スクリーンサービスと関連したイベント情報を有するトリガーを第２スクリーンデバイスに伝達することができ、第２スクリーンデバイスは、ダウンロードされたＴＰＴ情報を用いて直ちに動作することができる。メディア時間トリガーがＤＴＶＣＣを用いて周期的に伝達されるため、受信機は、この情報を連続して伝達しなければならない。
プライマリデバイス又は第２スクリーンデバイスがＴＰＴ ＸＭＬを有するので、イベントトリガーがライブトリガーサーバーから実時間で伝送される時にＡＭＴも受信されうる。
上述した２つの方法は、いかなるＵＲＬ値が適用されるかによって異なるように行われ、受信機の動作又は第２スクリーンサービスアプリケーションの構造及び動作は変更されてもよい。
第２スクリーンサービスのシグナリングメカニズムを説明する。
第２スクリーンサービスは、２つの方法、すなわち、受信機が、第２スクリーンサービスが存在するということを通知する第１方法、及び第２スクリーンデバイスがホームネットワークに接続されると、第２スクリーンサービスを提供する電子装置を検出するために装置及びサービスを探す第２方法を用いてシグナルすることができる。代案として、受信機は、新しい電子装置のデバイス記述語を確認し、サービス記述語を要求することができる。
以下、放送シグナリング及びユニキャストシグナリングを説明する。
放送シグナリングの場合、第２スクリーンデバイスは、ＲｅｍｏｔｅＵＩサーバーサービスを検出し、デバイス記述語を確認し、第２スクリーンデバイスと互換可能なＤｅｖｉｃｅＩｎｆｏプロファイルを要求する。イベントを受信でき、受信機に見られるプログラムによって変更されるＴＤＯ（インタラクティブアプリケーション）のＵＲＬを受信することができる。
逆に、ユニキャストシグナリングの場合、受信機は、第２スクリーンデバイスのＤｅｖｉｃｅＩｎｆｏが互換可能か否かを確認し、互換可能なＴＤＯ ＵＲＬを送信することができる。ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションは、現在実行される第２スクリーンアプリケーションを終了してディスプレイメッセージなどのアクションを支援し、現在実行されるＵＩを終了するように送信されうる。受信機でパーシングされ処理される追加のＥｖｅｎｔ＠ｄａｔａが、ＰｒｏｃｅｓｓＩｎｐｕｔアクションによって第２スクリーンサービスアプリケーションに伝達されうる。
以下、放送シグナリング及びユニキャストシグナリングを説明する。
図５９は、ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの他の実施例である。
放送シグナリングで、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの他の実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５９０１０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５９０４０）、及び／又はＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５９０５０）を含むことができる。
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５９０１０）は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５８０１０）と同一の段階であってもよい。
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）は、“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを全てのＵＰｎＰデバイスに送信する段階であってもよい。プライマリデバイスは、ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅのアナウンスメント（ａｎｎｏｕｎｃｅｍｅｎｔ）を、固有“ｕｉＩＤ”リストを有するＵＰｎＰデバイスに送信することができる。第２スクリーンデバイスは、このメッセージを受けた後、ｕｉＩＤをチェックすることができる。しかし、特定ｕｉＩＤとマッチングされず、この第２ストリーム装置ではＵＩアップデートが行われなくてもよい。
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）は、“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを全てのＵＰｎＰデバイスに送信する段階であってもよい。この時は、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）の場合とは違い、マッチングされるｕｉＩＤが存在し得る。
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５９０４０）は、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）でｕｉＩＤがマッチングされるため、第２スクリーンデバイスが自身のデバイスプロファイルを送信し、ＵＩＬｉｓｔｉｎｇを要求することができる。互換可能なＵＩを取得できるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる。
ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５９０５０）は、プライマリデバイスが第２スクリーンデバイスに、要求に応じた適切なＵＩ Ｌｉｓｔｉｎｇを送信する段階であってもよい。
図６０は、第２スクリーンサービスのための装置ディスカバリ及び装置能力交換の一実施例である。
前述したとおり、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
受信機のデバイス記述語とサービス記述語を受信した、全てのホームネットワークに接続したＵＰｎＰデバイスは、自身のデバイス記述語の位置をＨＴＴＰの“ＬＯＣＡＴＩＯＮ”ヘッダーで送ることができる。すなわち、ＵＰｎＰデバイス記述語の位置を送信して自身を知らせることができる。“ＬＯＣＡＴＩＯＮ”にＨＴＴＰ ＧＥＴ要求をすると、当該装置に関する情報がわかるＸＭＬファイルを受信することができる。
ＵＰｎＰデバイス及びサービスディスカバリ過程で、プライマリデバイスが、第２スクリーンサービスが可能な第２スクリーンデバイスを探す方法を紹介する。この方法は、２つに大別することができる。その第一は、第２スクリーンデバイスが２種類のデバイスプロファイルを準備しておき、このデバイスプロファイルのＸＭＬファイルをＨＴＴＰヘッダーで知らせる方法である。このとき、互換されないプライマリデバイスは、理解できないＨＴＴＰヘッダーはそのまま無視すると仮定することができる。その第二は、デバイスプロファイルのうち、第２スクリーンサービスを提供する第２スクリーンデバイスという情報を“Ｐｒｏｔｏｃｏｌ Ｉｎｆｏ”に含む方法である。
図６０は、第一の方式を例示するものである。
第２スクリーンサービスに対する装置ディスカバリ及び装置能力交換の一実施例は、第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ６０００１）、ＵＰｎＰデバイスを探す段階（ｓ６００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ６００２０）、デバイス記述を要求する段階（ｓ６００３０）、デバイス記述を受信する段階（ｓ６００４０）、サービス制御記述（ｄｅｓｃｒｉｐｔｉｏｎ）を要求する段階（ｓ６００５０）、サービス制御記述を受信する段階（ｓ６００６０）、デバイスプロファイルを要求する段階（ｓ６００７０）、デバイスプロファイルを受信する段階（ｓ６００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ６００９０）、応答１を送信する段階（ｓ６０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ６０１１０）、応答２を送信する段階（ｓ６０１２０）、及び／又はユーザがスクリーン上のボタンをクリックする段階（ｓ６０１３０）を含むことができる。
第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ６０００１）、ＵＰｎＰデバイスを探す段階（ｓ６００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ６００２０）、デバイス記述を要求する段階（ｓ６００３０）、デバイス記述を受信する段階（ｓ６００４０）、サービス制御記述を要求する段階（ｓ６００５０）、サービス制御記述を受信する段階（ｓ６００６０）、デバイスプロファイルを要求する段階（ｓ６００７０）、デバイスプロファイルを受信する段階（ｓ６００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ６００９０）、応答１を送信する段階（ｓ６０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ６０１１０）、応答２を送信する段階（ｓ６０１２０）、及びユーザがスクリーン上のボタンをクリックする段階（ｓ６０１３０）は、それぞれ順に、第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）、ＵＰｎＰデバイスを探す段階（ｓ４００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）、デバイス記述を要求する段階（ｓ４００３０）、デバイス記述を受信する段階（ｓ４００４０）、サービス制御記述を要求する段階（ｓ４００５０）、サービス制御記述を受信する段階（ｓ４００６０）、デバイスプロファイルを要求する段階（ｓ４００７０）、デバイスプロファイルを受信する段階（ｓ４００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ４００９０）、応答１を送信する段階（ｓ４０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）、応答２を送信する段階（ｓ４０１２０）、及びユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）と同一の段階であってもよい。
第一の方式は、図６０に示すように、ＵＰｎＰデバイスを探す段階（ｓ６００１０）段階後にＨＴＴＰヘッダーから得る“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーで第２スクリーンサービスを支援するデバイスプロファイルの位置を知らせることができる。Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ：ｈｔｔｐ：／／１０．１７７．５６．３６：３７９００／ＡＴＳＣ２ｎｄＳｃｒｅｅｎＲｅｍｏｔｅＵＩＣｌｉｅｎｔ１．ｘｍｌ\ｒ\ｎと表示された部分が“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーである。受信機は、“ＬＯＣＡＴＩＯＮ”ヘッダーは無視し、その代わりに“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーから、受信機の所望する情報である第２スクリーンデバイスのデバイスプロファイルを得ることができる。
プライマリデバイスが、第２スクリーンサービスが可能な第２スクリーンデバイスを探す方法のうち、前述した第二の方式は、“ＬＯＣＡＴＩＯＮ”ヘッダーの位置でデバイスプロファイルを得、デバイスプロファイル内で第２スクリーンデバイスの“Ｐｒｏｔｏｃｏｌ Ｉｎｆｏ”エレメントの値をパーシングして処理することができる。これは、前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階で行うことができる。
特定ＵＰｎＰデバイスのデバイス記述語には提供可能なサービスのリストがあり、一つ或いは複数個のサービスを提供するという事実がわかる。ＵＰｎＰデバイスが有しているそれぞれのサービスは、遠隔の他のＵＰｎＰデバイスで制御可能であり、イベントを受信することができる。ただし、イベント受信は、提供するサービスがイベントで知らせ得る機能がある場合にのみ可能である。ＵＰｎＰデバイスが提供するサービスは、“制御”，“コントロール”そして“イベント”ができるようにＵＲＬを知らせることができる。
図６１は、ＵＰｎＰフォーラムのＤｅｖｉｃｅＰｒｏｆｉｌｅ ＸＭＬスキマーの一実施例である。
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階についてさらに説明する。この段階は、第２スクリーンデバイスからＲｅｍｏｔｅＵＩサーバーサービスのある受信機に、第２スクリーンデバイスに合う条件のＵＩがあるか問うことであり、“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”には、図６１のようなＸＳＤファイルのような形式を有しなければならない。
したがって、第２スクリーンデバイスは受信機に、図６１のような形式で自身のデバイスプロファイルと合う情報を入れて送信しなければならない。
図６２は、第２スクリーンデバイスのデバイスプロファイルの一実施例である。
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階についてさらに説明する。この段階で、図６２は、デバイスプロファイルの一例を示している。ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階で、図示のデバイスプロファイルのような情報を受信機に送ることができる。
第２スクリーンデバイスが探そうとするデバイスプロファイルの第２スクリーンサービスが、受信機にあるか否かを検索することであり、図示の情報を“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”変数に格納して送信することができる。受信機では“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報を確認し提供すべきサービスタイプ、バージョン、第２スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式等を定義することができる。
図６３は、第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの説明の一実施例である。
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）及びＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）についてさらに説明する。
前述したとおり、受信機では“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報を確認し提供すべきサービスタイプ、バージョン、第２スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式などを定義することができる。“第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの記述の一実施例”は、“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報の一実施例であってもよい。
図示のような情報を用いて受信機に伝達した時（ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０））、ＸＭＬ形態となっているＵＩＬｉｓｉｎｇ情報を第２スクリーンデバイスに送信する（ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０））。
もし、ＲｅｍｏｔｅＵＩサーバーサービスで所望する第２スクリーンデバイスを支援しない他の装置であると、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）でエラー情報をリターンして、第２スクリーンサービスを支援できないＲｅｍｏｔｅＵＩサーバーサービスであることを知らせることができる。
図６４は、第２スクリーンデバイスでＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｔｅＵＩＬｉｓｔｉｎｇが実行される間のＵＩＬｉｓｔｉｎｇの一実施例である。
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）及びＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）についてさらに説明する。
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）後に、受信機は、互換されるＲｅｍｏｔｅＵＩ情報を探し、要求した第２スクリーンデバイスに伝達することができる（ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０））。ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）で受信された情報は、図６４に示す。
この受信された情報は、受信機が第２スクリーンに送信する時、ＴＰＴ及びＡＭＴを処理してＴＤＯ ＵＲＬを入れるものであってもよい。したがって、第２スクリーンデバイスは、Ｒｅｍｏｔｅ ＵＩの情報のみを受信機から得、第２スクリーンアプリケーションは、ホームネットワーク外のインターネットアプリケーションサーバーからダウンロードして実行することができる。このとき、実行することは、第２スクリーンサービスアプリケーションが担当することができる。
一方では、放送社からあらかじめ放送網や受信機に第２スクリーンデバイスのための第２スクリーンアプリケーションを送信してもよい。この場合には、受信機が第２スクリーンサービスのためのアプリケーションを保存しておき、直接サービスすることができる。この場合、ウェブサーバーが受信機で動作しなければならず、関連したイメージ及びデータは、受信機或いはホームネットワーク以外の外部アプリケーションサーバーからダウンロードすることができる。ＤＯがＮＤＯである場合に、ＡＴＳＣ−ＮＲＴでＮＤＯ及び関連リソースファイルを放送網に送信しておき、第２スクリーンサービスを提供することができる。
放送シグナリングの場合、第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションが管理することができる。
まず、受信機が第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
受信機は、ＤＴＶＣＣで伝送されるメディア時間トリガーの情報を処理後に、第２スクリーンと関連したイベントがＴＰＴに存在し、このイベントが実行されなければならない時、すぐに“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数を、全てのホームネットワークにある機器に知らせることができる。このようなイベントに関連していて申請した機器は、ＵＩ情報がアップデートされたことを認知し、必要な情報を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを行うことができる。この時、受信機のＲｅｍｏｔｅＵＩサーバーでは、すぐに実行しなければならないＴＤＯアドレスを渡すことができる。
次に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
この場合には、受信機が受信した情報を第２スクリーンデバイスに伝達し、第２スクリーンサービスアプリケーションが自ら動作できるようにすることができる。放送の場合、第２スクリーンサービスとなるクライアントが“ＧｅｔＣｏｍａｐｔｉｂｌｅＵＩｓ”アクションを要求すると、受信機がＤＴＶＣＣで直接受信したｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇをリターンすることができ、第２スクリーンデバイスが、受信したＵＲＩＳｔｒｉｎｇを用いてＴＰＴファイルをダウンロードし、受信機と同様にＴＰＴを解釈して動作することができる。受信機はＤＴＶＣＣでメディア時間トリガーやイベント時間トリガーを受信する度にすぐに“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数を変更して全ての機器に送信することができ、新しいｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇを受信できるように、機器が“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションをするように誘導することができる。
図６５は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
前述したユニキャストシグナリングについて説明する。
この方法は、第２スクリーンデバイスがＲｅｍｏｔｅＵＩＣｌｉｅｎｔサービスを装置内に内蔵している場合といえる。ＵＰｎＰデバイスが、最初にホームネットワークに接続すると、自身の情報を自分で通知し、他の装置にも新しい装置がホームネットワークに接続したという事実を知らせることができる。もう一つの方法は、周期的に新しい装置があったら知らせるように要求するメッセージを、全てのホームネットワークに接続した装置に伝達すると、全てのホームネットワークに接続した装置はこの情報に応答して通知（ＮＯＴＩＦＹ）メッセージをさらに全ての装置に知らせる方法である。まず、第２スクリーンデバイスが第２スクリーンサービスを支援するか否かについて調べなければならない。
ＲｅｍｏｔｅＵＩクライアントサービスに対するユニキャストシグナリングの一実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ６５０１０）、デバイスプロファイルを要求する段階（ｓ６５０２０）、デバイスプロファイルを返還する段階（ｓ６５０３０）、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）、ＨＴＴＰメッセージを返還する段階（ｓ６５０５０）、ディスプレイメッセージを送信する段階（ｓ６５０６０）、及び／又はＨＴＴＰメッセージを送信する段階（ｓ６５０７０）を含むことができる。
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ６５０１０）は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５８０１０）と同一の段階であってもよい。
デバイスプロファイルを要求する段階（ｓ６５０２０）は、受信機が新しく発見された第２スクリーンデバイスに第２スクリーンサービスを支援できるかを確認するために“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”情報を送信する段階であってもよい。
デバイスプロファイルを返還する段階（ｓ６５０３０）は、デバイスプロファイルを要求する段階（ｓ６５０２０）に対する応答として、第２スクリーンデバイスのデバイスプロファイルを得る段階であってもよい。もし、新しく発見された第２スクリーンデバイスが送ったデバイスプロファイルが“Ｓｔａｔｉｃ ＤｅｖｉｃｅＩｎｆｏ”と一致しないか、又は第２スクリーンデバイスを支援しない装置と判断されると、第２スクリーンサービスを開始しなくてもよい。“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”は、上記で定義した“ＤｅｖｉｃｅＩｎｆｏ”と同一であってもよい。“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”とＤｅｖｉｃｅＩｎｆｏ情報が一致するかは受信機で判断しなければならない。もし、ホームネットワークに新しく発見された第２スクリーンデバイスが一つ以上である場合、このような過程は繰り返される。一度発見された第２スクリーンデバイスで第２スクリーンサービスを支援しないからといって、このような過程を経ないというわけにはいかない。第２スクリーンデバイスには一つ以上の複数のソフトウェアが設置及び削除されてもよく、ユーザが実行するか否かによってこの過程に対する結果値が変わってもよいからである。第２スクリーンサービスアプリケーションを行った状態になると、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）に移行することができる。
ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）は、受信機がＴＰＴ及びＡＭＴをパーシングした結果であるＴＤＯ ＵＲＬ情報を送信する段階であってもよい。ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスで定義された“ＡｄｄＵＩＳｔｒｉｎｇ”を用いることができる。“ＡｄｄＵＩＳｔｒｉｎｇ”は、第２スクリーンデバイスで第２スクリーンサービスのＤｅｖｉｃｅＩｎｆｏ情報を満たす場合に実行されるアクションであってもよい。ＴＤＯ ＵＲＬは、一つ或いは一つ以上のＵＲＬになってもよい。一つ以上のＵＲＬである場合、すぐに実行するためのＵＲＬを送信することができる。このとき、選択的にディスプレイメッセージを送信する段階（ｓ６５０６０）を行うことができる。
ＨＴＴＰを返還する段階（ｓ６５０５０）は、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ディスプレイメッセージを送信する段階（ｓ６５０６０）は、第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ＲｅｍｏｔｅＵＩクライアントサービスは、第２スクリーンデバイス画面にメッセージを表示できるＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを有しうるため、第２スクリーンデバイスにＴＤＯ ＵＲＬを送信し、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて、画面に現在視聴中の放送プログラムと関連付けられた第２スクリーンアプリケーションがあるというメッセージを表示することができる。ユーザがこのメッセージを確認するとすぐに第２スクリーンアプリケーション実行となり得る。
ＨＴＴＰメッセージを返還する段階（ｓ６５０７０）は、ディスプレイメッセージを送信する段階（ｓ６５０６０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
図６６は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
新しいＵＩのＵＲＬが第２スクリーンデバイスのＵＩＬｉｓｔｉｎｇに追加される度に、第２スクリーンサービスアプリケーションは新しい第２スクリーンアプリケーションを実行する環境を提供することができる。
図６６のＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、実行中の第２スクリーンアプリケーションの実行を中断し、新しい第２スクリーンアプリケーションを実行するための順序を示している。
ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０２０）、ディスプレイメッセージを送信する段階（ｓ６６０３０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０４０）、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０６０）、ディスプレイメッセージを送信する段階（ｓ６６０７０）、及び／又はＨＴＴＰメッセージを返還する段階（ｓ６６０８０）を含むことができる。
ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）は、ＲｅｍｏｔｅＵＩクライアントサービスに定義されている“ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ”アクションを用いて、第２スクリーンサービスアプリケーションで実行中の第２スクリーンアプリケーションを中止させることができる。第２スクリーンサービスアプリケーションは、受信機で現在実行中であるＵＩのアプリケーション使用中止をする時、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送るということを知っていてもよい。したがって、第２スクリーンサービスアプリケーションは、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ ａｃｔｉｏｎが第２スクリーンデバイスに受信されるとすぐに現在動作中の第２スクリーンアプリケーションの動作を中止しなければならない。
ＨＴＴＰメッセージを返還する段階（ｓ６６０２０）は、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ディスプレイメッセージを送信する段階（ｓ６６０３０）は、第２スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）の後に、場合によっては、実行が中止されるというメッセージを第２スクリーンデバイス画面に表示する必要がありうる。この場合には、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて適切なメッセージを画面に表示することができる。
ＨＴＴＰメッセージを返還する段階（ｓ６６０４０）は、ディスプレイメッセージを送信する段階（ｓ６６０３０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）は、受信機が、新しく行われるＵＩのＴＤＯ ＵＲＬを送信するためにＡｄｄＵＩＬｉｓｔｉｎｇアクションを行う段階であってもよい。新しい第２スクリーンアプリケーションが行われる時は、ＵＩＬｉｓｔｉｎｇにＴＤＯ ＵＲＬが追加されるやいなや第２スクリーンサービスアプリケーションを実行させることができる。参考として、ＴＤＯ ＵＲＬは、受信機で直接ダウンロードして実行し得る第２スクリーンアプリケーションに関するものであっもよく、部分的なリソースデータだけをインターネットサーバーからダウンロードして行うものであってもよい。また、ＴＤＯ ＵＲＬそのものが外部インターネットサーバーアドレスを指してもよい。外部インターネットサーバーアドレスを指す場合には、第２スクリーンアプリケーション及び実行に必要な全てのデータは、インターネットサーバーからダウンロードして実行することができる。
ＨＴＴＰメッセージを返還する段階（ｓ６６０６０）は、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ディスプレイメッセージを送信する段階（ｓ６６０７０）は、第２スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）後に、新しい第２スクリーンサービスが実行されるとのメッセージを第２スクリーンデバイス画面に表示することができる。ディスプレイメッセージを送信する段階（ｓ６６０３０）と同様に、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて適切なメッセージは、画面に表示することができる。
ＨＴＴＰメッセージを返還する段階（ｓ６６０８０）は、ディスプレイメッセージを送信する段階（ｓ６６０７０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
ユニキャストシグナリングの場合も同様、第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションが管理することができる。
まず、受信機が第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
第２スクリーンサービスアプリケーションでは“ＵＲＬ”（ＴＤＯ＿ＵＲＬ）情報だけを知っていればよい。したがって、受信機で第２スクリーンデバイスにあるＲｅｍｏｔｅＵＩクライアントサービスに“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションを行い、第２スクリーンデバイスで動作する第２スクリーンアプリケーションを、定められた時間に実行することができる。逆に、第２スクリーンアプリケーションを中断させなければならない場合には、“ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ”アクションを行い、定められた時間内に第２スクリーンアプリケーションを中断させることができる。
さらに、細部的な時間まで合わせるためには、ＵＲＬの他に、ＴＤＯを行うメディア時間情報まで与えると、第２スクリーンサービスアプリケーションを指定された時間に実行することができる。しかし、メディア時間は、現在受信機で再生されているメディアに対する相対的な時間であるから、この時間は各機器が理解し得る絶対時間に変更する必要がある。ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）或いは他の時間情報を有することができ、この時間に、未来の時間情報を有するメディア時間を加えると、アクションを行う時間となる。第２スクリーンデバイスにおいてアクションは実行と中止しかないため、これは、ＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ ａｃｔｉｏｎの具現によって異なり得る。
次に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
第２スクリーンサービスアプリケーションが第２スクリーンデバイスで動作する第２スクリーンアプリケーションを実行し中断する時間やイベントに関する情報を知っていなければならない。したがって、前述したように、第２スクリーンサービスアプリケーションがトリガークライアントを含んでおり、受信機がＤＴＶＣＣで受信されたｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇ情報を受信機のＤｅｖｉｃｅＩｎｆｏ（Ｄｅｖｉｃｅ Ｐｒｏｆｉｌｅ）に合わせて送信することができる。
送信方法は、２種類に大別できる。その第一の方法は、ＤＴＶＣＣで送信されて受信機で処理したトリガーメッセージをそのまま送信する方法であり、第二の方法は、受信機で第２スクリーンデバイスに必要な情報のみをさらに整理し、必要な情報とデータのみをＸＭＬ形態で伝達する方法である。
まず、受信機がトリガーを第２スクリーンにそのまま伝達する方法について説明する。
この方法は、受信されたトリガーをそのまま“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションすることによって処理を終えることができる。ＲｅｍｏｔｅＵＩクライアントサービスでは、この情報をもってすぐにトリガークライアントが処理できるように渡し、トリガークライアントは、受信機と同様に、ＴＰＴをダウンロードして処理することができる。ただし、受信機は、ＤＴＶＣＣでメディア時間トリガーが受信される度に、第２スクリーンデバイスにこのように伝達しなければならない。受信機が“ａｐｐＩＤ”、“ｅｖｅｎｔＩＤ”及び“ｅｖｅｎｔ＠ｄｅｓｔｉｎａｔｉｏｎ”を確認し、第２スクリーンデバイスで受信しなくてもよいトリガーである場合には、自分で消費し、第２スクリーンデバイスには伝達しなくてもよい。
次に、受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法について説明する。
この方法は、受信機でＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達することができる。この方法は、第２スクリーンサービスアプリケーションで、トリガークライアントが動作しなくてもよく、“ＰｒｏｇｒｅｓｓＩｎｐｕｔ”アクションを通じてＸＭＬファイルを受け取って処理することができる。すなわち、第２スクリーンサービスアプリケーションが全体ＴＰＴを直接処理するのではなく、現在或いは将来に処理しなければならない必要なデータのみを受信機がフィルタリングして伝達すると、これを受けて処理することができる。この方法の長所は、“Ｅｖｅｎｔ＠Ｄａｔａ”フィールドがあるが、このフィールドまで伝達できるという点である。
図６７は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
図６７は、前述した第二の方法である、“受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”を示している。
ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、イベント１情報を送信する段階（ｓ６７０１０）、ＨＴＴＰメッセージを返還する段階（ｓ６７０２０）、イベント２情報を送信する段階（ｓ６７０３０）、ＨＴＴＰメッセージを返還する段階（ｓ６７０４０）、イベント３情報を送信する段階（ｓ６７０５０）、及び／又はＨＴＴＰメッセージを返還する段階（ｓ６７０６０）を含むことができる。
イベント１情報を送信する段階（ｓ６７０１０）は、受信機が第２スクリーンデバイスに、受信したイベント情報を伝達する段階であってもよい。前述した通り、受信機でＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達することができる。第２スクリーンサービスアプリケーションでは、トリガークライアントが動作しなくてもよく、“ＰｒｏｇｒｅｓｓＩｎｐｕｔ”アクションを通じてＸＭＬファイルを受信して処理することができる。
ＨＴＴＰメッセージを返還する段階（ｓ６７０２０）は、イベント１情報を送信する段階（ｓ６７０１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
イベント２情報を送信する段階（ｓ６７０３０）は、イベント１情報を送信する段階（ｓ６７０１０）と同様に、イベントに関する情報を伝達する段階であってもよい。ＴＰＴ ＸＭＬにおけると同様に、各イベント別にデータをＴＤＯに伝達することができるが、この段階は、イベント２に関する情報を伝達する段階であってもよい。
ＨＴＴＰメッセージを返還する段階（ｓ６７０４０）は、イベント２情報を送信する段階（ｓ６７０３０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
イベント３情報を送信する段階（ｓ６７０５０）は、同様に、イベント３に関する情報を伝達する段階であってもよい。
ＨＴＴＰメッセージを返還する段階（ｓ６７０６０）は、イベント３情報を送信する段階（ｓ６７０５０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
前述した第二の方法では、受信機が第２スクリーンアプリケーションのライフサイクルを管理することができる。第２スクリーンアプリケーションのライフサイクルは、第２スクリーンデバイスで動作するＴＰＴ及びＡＭＴ情報をパーシングし、処理する過程を意味することができる。
図６８は、ＰｒｏｃｅｓｓＩｎｐｕｔアクションで第２スクリーンデバイスに伝達される“ＥｖｅｎｔＩｎｆｏ”情報の一実施例である。
図６８は、前述した“受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”において、受信機がＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達する時、イベント情報のＸＭＬデータ構造の一例示を示している。
すなわち、受信機で第２スクリーンアプリケーションのライフサイクルを管理する場合には、ＰｒｏｃｅｓｓＩｎｐｕｔアクションでは、イベント情報を、図６８のデータ構造を有するＸＭＬファイルとしてＲｅｍｏｔｅＵＩクライアントに伝達することができる。受信機がライブトリガー（Ｌｉｖｅ Ｔｒｉｇｇｅｒ）を受ける場合にも同様に、ライブトリガーを処理し、実行する時間とＴＤＯ ＵＲＬなどの情報のみを第２スクリーンデバイスに伝達することもできる。
図６８のテーブルで、＠ａｐｐＩＤ、ＵＲＬ、Ｅｖｅｎｔ、＠ｅｖｅｎｔＩＤ、＠ａｃｔｉｏｎ及びＤａｔａは、受信機が受信したトリガー又はＡＭＴの情報と同一であってもよい。しかし、“＠ｍｅｄｉａＴｉｍｅ”、“＠ｓｔａｒｔＴｉｍｅ”及び“＠ｅｎｄＴｉｍｅ”は、受信機で特別に処理することができる。“＠ｍｅｄｉａＴｉｍｅ”に合わせて、ＤＴＶＣＣで送信されたトリガーの“ｔｉｍｅ＝”シンタックスの情報（或いは、ＡＭＴの“＠ｂｅｇｉｎＭＴ”情報）を処理し、再び“＠ｓｔａｒｔＴｉｍｅ”と“＠ｅｎｄＴｉｍｅ”を決定することができる。受信機と第２スクリーンデバイスが、同一の絶対時間情報（ｗａｌｌ ｃｌｏｃｋ ｔｉｍｅ）を使用するとはいえないことから、コンテンツのメディア時間に合わせて第２スクリーンデバイスを動作させるためである。すなわち、受信機と第２スクリーンデバイス間にアクションに対する実行開始時間及び終了時間に関する時間情報が実際ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に合わせられているとすれば、送信する前に受信機が変換する作業を行わなければならない。
送信遅延及びメディア時間推定について説明する。
前述した通り、＠ｓｔａｒｔＴｉｍｅと＠ｅｎｄＴｉｍｅは、受信機で第２スクリーンに送る時、現在のｍｅｄｉａＴｉｍｅ値を基準に相対的に作られて送信されるため、送信時に発生する時間損失は、送信プロトコルであるＨＴＴＰのヘッダーの“Ｄａｔｅ”値とＨＴＴＰ応答であってもよい到着した時間値との差を用いて、第２スクリーンデバイスで調整してより正確な時間値を探すことができる。現在メディア時間と＠ｍｅｄｉａＴｉｍｅ値との差は送信遅延時間となるため、次のような数式によって現在メディア時間を得ることができる。
現在メディア時間＝送信遅延時間（受信時の時間値−ＨＴＴＰヘッダー“Ｄａｔｅ”値）＋＠ｍｅｄｉａＴｉｍｅ
これによって、現在受信機の現在メディア時間値と略同一に類推することができる。
図６９は、受信機及び第２スクリーンデバイス間の構成の一実施例である。
受信機及び第２スクリーンデバイス間の構成が示されている。受信機が被制御デバイス（サーバー）であり、第２スクリーンデバイスが制御ポイント（クライアント）であってもよい。
ディスカバリ段階で、受信機は、サービスリストをマルチキャストしてネットワークにジョインし、第２スクリーンアプリケーションはサービスリストに対する要求をマルチキャストして開始することができる。
記述（Ｄｅｓｃｒｉｐｔｉｏｎ）段階で、第２スクリーンアプリケーションは、受信機のサービス記述を要求することができる。
本発明では、ＵＰｎＰに基づいてＴＶ受像機、すなわち、受信機を通じて受信されるＡ／Ｖ放送コンテンツと関連したインタラクティブサービスを第２スクリーンデバイスを通じて取得できるようにするために、新しいＵＰｎＰデバイス及びサービスを定義することができる。
図７０は、サービスのサービスタイプ及びサービスＩＤの一実施例である。
受信機は、トリガーサービス、双方向通信サービス及びＡｐｐＵＲＬサービスを支援することができる。また、ＨＴＴＰプロキシサーバーサービスを支援することができる。サービスタイプ及びサービスＩＤは、図７０に示している。
双方向通信サービスは、第２スクリーンデバイス内のアプリケーションと双方向通信に参加するように準備されたプライマリデバイスで実行されるＤＯが存在するかを、第２スクリーンデバイスで決定するようにすることができる。
トリガーサービス、ＡｐｐＵＲＬサービス及びＨＴＴＰプロキシサーバーサービスについては後述する。
図７１は、トリガー伝達サービスの動作概念図の一実施例である。
トリガー伝達サービスは、ＵＰｎＰに基づいてＴＶ受信機に受信されるＡ／Ｖ放送コンテンツと関連したインタラクティブサービスを第２スクリーンを通じて取得できるようにするためのサービスを意味できる。
図７１は、受信機がＤＴＶＣＣ或いはＡＣＲサーバーなどからトリガーを取得し、当該トリガーをそのまま或いは第２スクリーンデバイスに適した形態に変形（拡張されたトリガー）して第２スクリーンデバイスに送信する過程を示している。
トリガーが変化する度に、受信機から第２スクリーンデバイスに当該トリガー或いは変形された拡張トリガーを実時間で送信することができる。
図７２は、拡張された活性化トリガー（ｅｘｐａｎｄｅｄ ａｃｔｉｖａｔｉｏｎ ｔｒｉｇｇｅｒ）生成過程の一実施例である。
拡張されたトリガー（拡張された活性化トリガー）は、ＤＴＶＣＣストリーム或いはＡＣＲサーバーなどから取得したトリガーとＴＰＴ内の情報とを組み合わせて生成することができる。トリガーに含まれたＴＤＯ ＩＤとイベントＩＤ、データＩＤ及び活性化時間と、ＴＰＴ内のＴＤＯ ＵＲＬ、ＴＤＯ属性、イベント、アクション、ディフュージョン（Ｄｉｆｆｕｓｉｏｎ）及びデータなどの情報を組み合わせて生成することができる。ＴＤＯ内の情報は、トリガー内の情報と関連したＴＤＯ及びイベントに関する情報であってもよい。
ここで、拡張されたトリガーは、増加したトリガー（ａｕｇｍｅｎｔｅｄ ｔｒｉｇｇｅｒ）と呼ぶこともできる。
図７３は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。
トリガーサービスの説明書（Ｓｐｅｃｉｆｉｃａｔｉｏｎ）について説明する。
トリガーサービスは、トリガーを伝達することができる。トリガーは、（ａ）ＡＣＲプロセス、（ｂ）現在見ているチャネルのＤＴＶ ＣＣサービス＃６、（ｃ）遠隔“ライブトリガー”サーバー、又は（ｄ）活性化メッセージテーブル（ＡＭＴ）からＴＶ受像機によって取得することができる。これは状況による。
トリガーサービスはまた、チャネルが変更される度に特殊“チャネル変更”トリガーを伝達することができる。チャネル変更トリガーについては後述する。伝達される４つのタイプのトリガーが基本的に存在し得る。すなわち、１）ＴＤＯインタラクティブサービスモデルのための時間ベーストリガー、２）ＴＤＯインタラクティブサービスモデルのための活性化トリガー、３）直接実行インタラクティブサービスモデルのためのトリガー、及び４）特殊“チャネル変更”トリガーである。
最大の柔軟性のために、第２スクリーンデバイスに全てのタイプのトリガーを伝達するオプションを有し、受信機でトリガーが到達するやいなや伝達することが好ましい。
しかし、受信機が相互作用を提供するのと同じ方式で相互作用を提供するように設計された第２スクリーンアプリケーションに対して、ＴＤＯ相互作用モデルのための時間ベーストリガーを省略し、その活性化時間にＴＤＯ相互作用モデルのための各活性化トリガーを伝達することが好ましい。これは、時間ベースを維持し、活性化時間を算出する必要性から、それらの第２スクリーンアプリケーションを求めることができる。これはまた、トリガーからの情報をトリガーで参照されたＴＤＯエレメント及びそのイベントチャイルド（ｃｈｉｌｄ）エレメントに関するＴＰＴからの情報と結合することによってそれぞれの活性化トリガーを増加させ、これらの第２スクリーンアプリケーションがＴＰＴを扱う必要性から求めることが好ましい。
したがって、トリガーサービスは、トリガー伝達のための２つのオプションを提供することができる。その一つは、受信機が（増加していない）全てのトリガーを伝達する“フィルタリングされていないストリーム（Ｕｎｆｉｌｔｅｒｅｄ ｓｔｒｅａｍ）”オプションでよい。もう一つは、ＴＤＯ相互作用モデルのための増加した活性化トリガー、ＴＤＯ相互作用モデル以外の相互作用モデルのための全てのトリガー及び特殊チャネル変更トリガーのみを伝達する“フィルタリングされたストリーム（Ｆｉｌｔｅｒｅｄ ｓｔｒｅａｍ）”オプションでよい。
ＴＤＯ相互作用モデルのためのそれぞれの増加した活性化トリガーのためのターゲット伝達時間は、その活性化時間であってもよい。（フィルタリングされていないストリームオプションで増加無しで伝達された活性化トリガーを含む）全ての他のトリガーに対するターゲット伝達時間は、受信機によって受信される時間であってもよい。それぞれの特殊チャネル変更トリガーのターゲットトリガー時間は、チャネル変更の時間であってもよい。
トリガーサービスのトリガー伝達フォーマットは、増加した活性化トリガーに対する伝達フォーマット及び他の全てのトリガーに対する伝達フォーマットとに区別できる。
図７３は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）に対する伝達フォーマットを示す。他の全てのトリガーに対する伝達フォーマットは後述する。
増加した活性化トリガーに対する伝達フォーマットは、＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ、＠ａｐｐＵＲＬ、及び／又は＠ｃｏｏｋｉｅＳｐａｃｅ属性と能力及び／又はイベントエレメントを含むことができる。
イベントエレメントは、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び／又は＠ｄａｔａ ａｔｔｒｉｂｕｔｅｓを含むことができる。
各フィールドのセマンティックス（ｓｅｍａｎｔｉｃｓ）は、次のと通りである。
＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性の値は、トリガーを伝達するために用いられるＤＴＶＣＣチャネルのサービス＃６内のＳＤＯＰｒｉｖａｔｅＤａｔａ命令内のｃｍｄＩＤフィールドに対して同一のコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。 本発明の一実施例で、数値コードは、トリガーを伝達するために用いられるＤＴＶ ＣＣチャネルのサービス６内のＵＲＬＳｔｒｉｎｇ命令内のＵＲＩ＿ｄａｔａ（）構造内のＵＲＩ＿ｔｙｐｅに対するものと同一のコーディングを用いることができる。
＠ａｐｐＵＲＬ属性の値は、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントの第１ＵＲＬチャイルドエレメントの値であってもよい。
＠ｃｏｏｋｉｅＳｐａｃｅ属性は、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントが＠ｃｏｏｋｉｅＳｐａｃｅ属性を含む度に存在でき、その属性と同じ値を有することができる。
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントがＣａｐａｂｉｌｉｔｉｅｓエレメントを含む度に存在でき、そのエレメントと同一であってもよい。
Ｅｖｅｎｔエレメントは、トリガー内のイベント（“ｅ＝”）用語によって識別されるＥｖｅｎｔエレメントを示すことができる。（厳密にいえば、トリガー内のイベント用語は、ＴＰＴ内のＴＤＯエレメント及びそのＴＤＯエレメントのイベントチャイルドエレメントを識別する。これは、ここでトリガー内のイベント用語によって識別されたＥｖｅｎｔエレメントという。）
＠ａｃｔｉｏｎ属性の値は、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントのアクション属性の値と同一であってもよい。
＠ｄｅｓｔｉｎａｔｉｏｎは、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントがあて先属性を含む度に存在でき、その属性と同じ値を有することができる。 本発明の一実施例で、＠ｄｅｓｔｉｎａｔｉｏｎ属性は、トリガー内の“ｅ＝”用語によって識別されたＴＤＯエレメントがあて先属性を含む度に存在することができる。
＠ｄｉｆｆｕｓｉｏｎ属性は、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントがディフュージョン属性を含む度に存在でき、その属性と同じ値を有することができる。 本発明の一実施例で、＠ｄｉｆｆｕｓｉｏｎ属性は、トリガー内の“ｅ＝”用語によってＴＤＯエレメントがディフュージョン属性を含む度に存在することができる。
＠ｄａｔａ属性は、イベントエレメントのデータチャイルドエレメントがトリガー内のイベント（“ｅ＝”）用語によって識別される度に存在でき、そのエレメントと同じ値を有することができる。
前述した通り、増加したトリガーは、ＤＴＶＣＣストリーム或いはＡＣＲサーバーなどから取得したトリガーとＴＰＴ内の情報とを組み合わせて生成することができる。
前述した通り、拡張されたトリガーは、増加したトリガーと呼ぶこともできる。
図７４は、ＵＲＩ＿ｄａｔａ（）のシンタックスの一実施例である。
図７４は、前述したＡｕｇｍｅｎｔｅｄＴｒｉｇｇｅｒの＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性に関する説明のうち、ＵＲＩ＿ｄａｔａ（）に関するものであってもよい。
ＵＲＩ＿ｄａｔａ（）構造は、ＵＲＩ＿ｔｙｐｅ及び／又は複数個のＵＲＩ＿ｃｈａｒａｔｅｒを含むことができる。また、ＵＲＩ＿ｄａｔａ（）構造は予約ビットを含むことができる。
４ビット符号無し整数であってもよいＵＲＩ＿ｔｙｐｅは、命令内で伝送されるＵＲＩのタイプを示すことができる。ＵＲＩ＿ｔｙｐｅの意味は、図７５に示すとおりにすることができる。受信機は、認識されないタイプを示すＵＲＩＳｔｒｉｎｇ命令のインスタンスを無視すると期待することができる。ＵＲＩが２個のセグメントで伝送されると、ＵＲＩ＿ｔｙｐｅフィールドは両セグメントにおいて同一であってもよい。
ＵＲＩ＿ｃｈａｒａｃｔｅｒは、ＵＲＩに対して許容されるものに制限される値を有する８ビットＡＳＣＩＩ文字であってもよい。ＵＲＩが２個のセグメントで伝送される場合の再組立て（ｒｅａｓｓｅｍｂｌｙ）後に、ＵＲＩ＿ｃｈａｒａｃｔｅｒ値のシーケンスによって形成された文字ストリングが有効ＵＲＩであってもよい。
図７５は、ＵＲＩ＿ｔｙｐｅの意味の一実施例である。
図７５は、ＵＲＩ＿ｄａｔａ（）のシンタックスの一実施例で前述したＵＲＩ＿ｄａｔａ（）のＵＲＩ＿ｔｙｐｅの意味に関するものであってもよい。
ＵＲＩ＿ｔｙｐｅが０である場合、ＵＲＩ＿ｄａｔａ（）がインタラクティブＴＶトリガーに関するものであることを意味することができる。
ＵＲＩ＿ｔｙｐｅが１である場合、ＵＲＩ＿ｄａｔａ（）がサービス使用報告サーバー（ＳＵＲＳ）ロケーター（ｌｏｃａｔｏｒ）に関するものであることを意味できる。
ＵＲＩ＿ｔｙｐｅが２−１５である場合、ＵＲＩ＿ｄａｔａ（）がどのｔｙｐｅを有するかはまだ定められておらず、将来の使用のために予約されていることを意味できる。
図７6は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。
増加していないトリガーのＸＭＬフォーマットであってもよい。前述した特殊“チャネル変更”トリガーもこのフォーマットに従うことができる。
増加した活性化トリガーに対するＸＭＬスキマー記述の一実施例は、＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性及び／又は＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性を含むことができる。
各フィールドのセマンティックスは、次の通りである。
＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性は、特殊“チャネル変更”トリガーのために存在することができない。他のトリガーのために、ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌが存在でき、その値は、ＤＴＶＣＣチャネル内のＳＤＯＰｒｉｖａｔｅＤａｔａコマンド内のｃｍｄＩＤフィールドに対するものと同じコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。ライブトリガーサーバーから取得されたりＡＭＴから導出されたトリガーのための＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌは、ＴＤＯモデルと見なすことができる。本発明の一実施例において、数値コードは、ＤＴＶ ＣＣチャネルのサービス６のＵＲＬＳｔｒｉｎｇ命令内のＵＲＩ＿ｄａｔａ（）構造内のＵＲＩ＿ｔｙｐｅフィールドに対するものと同一のコーディングを用いることができる。
＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性の値は、トリガーのストリング表示であってもよい。トリガーのストリング表示は、前述したトリガーシンタックスで説明したものと同一であってもよい。ただし、特殊“チャネル変更”トリガーの場合には異なってもよい。特殊“チャネル変更”トリガーのための＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性は、値“＊＊＜ｍａｊｏｒ＿ｎｕｍ＞．＜ｍｉｎｏｒ＿ｎｕｍ＞”を有することができ、ここで、＜ｍａｊｏｒ＿ｎｕｍ＞は、（ＴＶステーションによって放送されたため）新しいチャネルの本来の主要チャネル番号であり、＜ｍｉｎｏｒ＿ｎｕｍ＞は、（ＴＶステーションによって放送されたため）新しいチャネルの本来のマイナーチャネル番号であってもよい。チャネル番号を知っていないと、＜ｍａｊｏｒ＿ｎｕｍ＞及び＜ｍｉｎｏｒ＿ｎｕｍ＞値は“０”であってもよい。
図７7は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの他の実施例であってもよい。
＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅは、メディア時間スケール上の活性化時間であってもよい。
＠ｔｄｏＵＲＬは、前述した＠ａｐｐＵＲＬと同一であってもよい。
図７8は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅ、＠ｔｄｏＵＲＬ、＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
＠ａｖａｉｌＩｎｔｅｒｎｅｔ及び＠ａｖａｉｌＢｒｏａｄｃａｓｔはＴＰＴからなってもよい。＠ａｖａｉｌＩｎｔｅｒｎｅｔ及び＠ａｖａｉｌＢｒｏａｄｃａｓｔも、前述したものと同一であってもよい。
図７9は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅ、＠ｔｄｏＵＲＬ、＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
ＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ及び、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性は、増加したトリガーを生成する時、ＴＰＴにおける同名のｅｌｅｍｅｎｔ及びａｔｔｒｉｂｕｔｅｓから由来ものであってもよい。ＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ及び、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔも、前述したものと同一であってもよい。
図80は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
＠ｃｏｏｋｉｅＳｐａｃｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ Ｃａｐａｂｉｌｉｔｉｅｓ、ＣｏｎｔｅｎｔＩｔｅｍ、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩｄ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、ＴＤＯエレメント内のＵＲＬ及びＣｏｎｔｅｎｔＩｔｅｍエレメント内のＵＲＬは、増加したトリガーを生成する時、ＴＰＴにおける同名のエレメント及び属性から由来するものであってもよい。＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩｄ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、ＴＤＯ ｅｌｅｍｅｎｔ内のＵＲＬ及びＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ内のＵＲＬも、前述したものと同一であってもよい。
図８１は、ＨＴＴＰロングポーリング基盤アプローチによるトリガーサービス状態変数の一実施例である。
ここで、トリガーサービスを支援するいくつかのアプローチが存在できる。いくつかのアプローチとしては、ＨＴＴＰロングポーリング基盤アプローチとＵＰｎＰイベンティングメカニズム基盤アプローチを挙げることができる。
以下、ＨＴＴＰロングポーリング基盤アプローチについて説明する。
ＨＴＴＰロングポーリング基盤アプローチにおいて、トリガーサービスは一つの状態変数を有することができる。
ＴｒｉｇＳｅｒｖｅｒＵＲＬ状態変数の値は、プロトコル用語無しでクライアントによってトリガーを検索するために用いられるＵＲＬであってもよい。
トリガーを検索するとの要求は、ＨＴＴＰ要求又はＷｅｂＳｏｃｋｅｔ要求を用いてなされてもよい。ＨＴＴＰ要求が（先頭に付け加えられたプロトコル用語ｈｔｔｐ：／／を有するＴｒｉｇＳｅｒｖｅｒＵＲＬを用いて）なされると、サーバーはＨＴＴＰロングポーリング伝達モードで応答することができる。ＷｅｂＳｏｃｋｅｔ要求が（先頭に付け加えられたプロトコル用語“ｗｓ：／／”を有するＴｒｉｇＳｅｒｖｅｒＵＲＬを用いて）なされると、サーバーは、ＷｅｂＳｏｃｋｅｔ伝達モードで応答することができる。
要求ＵＲＬがクエリー用語を含まないか、又はクエリー用語“？ｌｅｖｅｌ＝ｕｎｆｉｌｔｅｒ”を含むと、サーバーは、フィルタリングされていないストリームオプションで応答することができる。要求ＵＲＬがクエリー用語“？ｌｅｖｅｌ＝ｆｉｌｔｅｒ”を含むと、サーバーは、フィルタリングされたストリームオプションで応答することができる。
トリガーがフィルタリングされていないストリームオプションで伝達され、トリガーがＴＤＯモデル以外の相互作用モデルに対して伝達されると、応答のボディーは、図７６で表示されたＸＭＬスキマーに従うＸＭＬ文書の形態を有することができる。
活性化トリガーがフィルタリングされたストリームオプションで伝達されると、応答のボディーが、図７３に表示されたＸＭＬスキマーに従うＸＭＬ文書の形態を有することができる。
図８２は、ＨＴＴＰロングポーリング基盤アプローチによるトリガーサービスアクションの一実施例である。
ＨＴＴＰロングポーリング基盤アプローチにおいて、トリガーサービスは、単一アクション、即ちＧｅｔＴｒｉｇＳｅｒｖｅｒＵＲＬアクションを有することができる。ＧｅｔＴｒｉｇＳｅｒｖｅｒＵＲＬアクションは、クライアントがＴｒｉｇＳｅｒｖｅｒＵＲＬの値を得るために用いることができる。
図８３は、ＨＴＴＰロングポーリング基盤アプローチによるＧｅｔＴｒｉｇＳｅｒｖｅｒＵＲＬアクションの引数（Ａｒｇｕｍｅｎｔｓ）の一実施例である。
ＴｒｉｇＳｅｒｖｅｒＵＲＬ出力引数は、ＴｒｉｇＳｅｒｖｅｒＵＲＬ状態変数の現在値であってもよい。
この実施例で、第２スクリーンアプリケーションは、ＧｅｔＴｒｉｇＳｅｒｖｅｒＵＲＬアクションを用いてクライアントによってトリガーを検索するために用いられるＵＲＬを得ることができる。
図８４は、トリガーサービス状態変数の実施例を示す図である。
図８４の実施例は、ＵＰｎＰイベンティングメカニズム基盤アプローチによるものである。
以下、ＵＰｎＰイベンティングメカニズム基盤アプローチについて説明する。
トリガーサービス状態変数の一実施例は、図示のトリガーサービス状態変数を定義することができる。トリガーサービスは、図８４に列挙された状態変数を有することができる。
ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーを示すことができる。この状態変数のフォーマットは、図７６に記載されたスキマーに従うＸＭＬ文書であってもよい。
ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーを示すことができる。活性化トリガーであれば、ＴＰＴ内の情報を有する活性化トリガー内の情報を結合して、図７３に記載されたテーブルで表示されたＸＭＬスキマーに従うＸＭＬ文書を生成することによって増加させることができる。ＴＤＯ以外の相互作用モデルを有するトリガーであれば、図７６に記載されたスキマーに従うＸＭＬ文書の形態を有することができる。特殊チャネル変更トリガーであれば、フォーマットは、上述したように“＊＊＜ｍａｊｏｒ＿ｎｕｍ＞．＜ｍｉｎｏｒ＿ｎｕｍ＞”であってもよい。
ＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーの伝達時間であってもよい。“ｄａｔｅＴｉｍｅ”データタイプは、１９７０年１月１日００：００：００以降ミリ秒の数を示す数であってもよい。
ＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーの伝達時間であってもよい。
図８５は、トリガーサービスアクションの実施例を示す図である。
図８５の実施例は、ＵＰｎＰイベンティングメカニズム基盤アプローチによるものであってもよい。
アクションは、第２スクリーンデバイス又は受信機がトリガーサービス状態変数の値を任意に判読するように定義することができる。
ＵＰｎＰイベンティングメカニズム基盤アプローチにおいて、トリガーサービスアクションは、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ及びＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを定義することができる。
図８６は、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の実施例を示す図である。
図８６の実施例は、ＵＰｎＰイベンティングメカニズム基盤アプローチによるものであってもよい。
ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ出力引数の値は、ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値であってもよい。
第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いてＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーを得ることができる。
図８７は、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の実施例を示す図である。
図８７の実施例は、ＵＰｎＰイベンティングメカニズム基盤アプローチによるものであってもよい。
ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ出力引数の値は、ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値であってもよい。
第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いてＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーを得ることができる。
図８８は、ＵＰｎＰイベンティングメカニズム基盤アプローチの実施例である。
ＵＰｎＰイベンティングメカニズム基盤アプローチの実施例は、トリガーを受信する段階（ｓ８８０１０）、ＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅを変更する段階（ｓ８８０２０）、非同期通知を伝達する段階（ｓ８８０３０）、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階（ｓ８８０４０）、増加していないトリガーで応答する段階（ｓ８８０５０）、活性化トリガーを受信する段階（ｓ８８０６０）、ＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅを変更する段階（ｓ８８０７０）、非同期通知を伝達する段階（ｓ８８０８０）、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階（ｓ８８０９０）及び／又は増加した活性化トリガーで応答する段階（ｓ８８１００）を含むことができる。
図面で、受信機は、前述した受信機であってもよい。第２スクリーンデバイス＃１は、“ｕｎｆｉｌｔｅｒｅｄ ｓｔｒｅａｍ ｏｐｔｉｏｎ”を支援する第２スクリーンデバイスであってもよい。第２スクリーンデバイス＃２は、“フィルタリングされたストリームオプション”を支援する第２スクリーンデバイスであってもよい。
トリガーを受信する段階（ｓ８８０１０）は、前述したとおり、受信機がＤＴＶＣＣチャネル、ＡＣＲプロセス又は放送社インタラクティブＴＶ（ｉＴＶ）サーバーなどを介してトリガーを受信する段階であってもよい。このとき、受信したトリガーは、増加していない全てのタイプのトリガーであってもよい。
ＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅを変更する段階（ｓ８８０２０）は、前述したＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値が変更される段階であってもよい。
非同期通知を伝達する段階（ｓ８８０３０）は、前述した“イベンティング”プロトコルによるものであってもよい。第２スクリーンアプリケーションは、トリガーサービスの“イベンティング”特徴に加入することができる。
ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階（ｓ８８０４０）は、第２スクリーンアプリケーションがトリガーを得るために、前述したＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階であってもよい。
増加していないトリガーで応答する段階（ｓ８８０５０）は、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションに対する応答として、増加していないトリガーを送信する段階であってもよい。第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いて適切なトリガーを適切な時間に得ることができる。
活性化トリガーを受信する段階（ｓ８８０６０）は、前述したとおり、受信機がＤＴＶＣＣチャネル、ＡＣＲプロセス又は放送社インタラクティブＴＶ（ｉＴＶ）サーバーなどを介して活性化トリガーを受信する段階であってもよい。
ＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅを変更する段階（ｓ８８０７０）は、前述したＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値が変更される段階であってもよい。
非同期通知を伝達する段階（ｓ８８０８０）は、前述した非同期通知を伝達する段階（ｓ８８０３０）と同一であってもよい。
ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階（ｓ８８０９０）は、第２スクリーンアプリケーションがトリガーを得るために、前述したＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いる段階であってもよい。
増加した活性化トリガーで応答する段階（ｓ８８１００）は、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションに対する応答として、増加した活性化トリガーを送信する段階であってもよい。第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いて適切なトリガーを適切な時間に得ることができる。
図８９は、トリガーサービス状態変数の実施例を示す図である。
前述したトリガーサービスを支援するためのいくつかのアプローチには、ＨＴＴＰロングポーリング基盤アプローチ及びＵＰｎＰイベンティングメカニズム基盤アプローチだけでなく、他の実施例もある。以下、その実施例を、図８９及び図９０を参照して説明する。
この実施例において、トリガーサービス状態変数は、図８９のとおりであってもよい。
ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、次の３つの状況のいずれかが施行されるかに依存することができる。１）プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加（ａｄｊｕｎｃｔ）データサービスがない。２）プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加データサービスが存在し、直接実行相互作用モデルを有する。３）プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加データサービスが存在し、ＴＤＯ相互作用モデルを有する。
（１）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、ヌルストリング（ｎｕｌｌ ｓｔｒｉｎｇ）であってもよい。
（２）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、プライマリスクリーンで現在視聴している番組に対してＴＶ受像機によって受信された最も最近のトリガーであってもよい。
（３）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、プライマリスクリーンで現在視聴している番組に対してＴＶ受像機によって受信された活性化トリガーのうち最も最近に活性化された活性化トリガーの増加した形態であってもよい。（すなわち、活性化トリガーは、活性化時間に到達する時にＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数に対する基礎となり、他の活性化トリガーがその活性化時間に到達する時まで基礎として残っていることができる。）活性化トリガーの増加した形態は、活性化トリガー内の情報をＴＰＴ内の情報と結合することによって得ることができる。増加した形態は、上述した増加したトリガーフォーマットの一つと同一であってもよい。
ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の定義は、ＴＤＯ相互作用モデルに対して活性化トリガーがトリガー活性化時間にＵＰｎＰクライアントに伝達されることを意味することができる。
トリガーサービス状態変数の他の実施例において、トリガーが変更される度に、受信機から第２スクリーンデバイスにトリガー又は拡張されたトリガーを実時間に伝送するために、ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒが状態変数として定義されてもよい。
ＡＴＳＣＴｒｉｇｇｅｒ状態変数は、ＤＴＶＣＣストリーム又はＡＣＲサーバーから受信されたトリガーに対する参照をＵＲＩの形態で含むことができる。この変数は、ＴＰＴ（ＴＤＯ ｐａｒａｍｅｔｅｒｓ ｔａｂｌｅ）に対するＵＲＬ、ＴＤＯ ＩＤ、Ｅｖｅｎｔ ＩＤ、Ｄａｔａ ＩＤ、メディア時間、コンテンツＩＤ、ターゲットイベントに対する活性化時間などを含むことができる。
ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ状態変数は、第２スクリーンデバイスに対するＴＤＯと関連したメタデータを、ＸＭＬフラグメントの形態で含むことができる。このメタデータは、ＤＴＶＣＣストリーム又はＡＣＲサーバーから受信されたＴＰＴ及びトリガーから抽出することができる。この変数は、図８０の実施例と同様のＸＭＬスキマーを有することができる。
上記で定義したＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの変更された値は、受信機がＵＰｎＰのイベンティングメカニズムに基づいて状態変数を変更する時に実時間に取得することができる。
図９０は、トリガーサービスアクションの実施例を示す図である。
ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒが状態変数として定義された上述のトリガーサービス状態変数の他の実施例において、トリガーサービスアクションを説明する。
このイベントにおいても、アクションは、第２スクリーンデバイス又は受信機が任意にＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値を記録又は判読するように定義することができる。
ＳｅｔＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＴｒｉｇｇｅｒの使用を可能にすることができる。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒは、引数であってもよい。
ＳｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値の利用を可能にすることができる。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒは増加してもよい。
ＧｅｔＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＴｒｉｇｇｅｒの値の判読を可能にすることができる。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒは引数であってもよい。
ＧｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ（）は、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値の判読を可能にすることができる。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒは引数であってもよい。
図９１は、トリガー伝達サービスを用いてトリガーを取得する時に第２スクリーン上の動作の実施例を示す図である。
第２スクリーンデバイスがトリガー伝達サービスを通じて第２スクリーンデバイスから受信されたトリガー又は拡張された活性化トリガーに含まれるアクション情報によって動作する方法を示すことができる。
実行／終了アクションのトリガーは、トリガー伝達サービスを通じて取得することができる。
第２スクリーンデバイスは、トリガー伝達サービスを通じて実行／終了アクションのトリガーを取得し、取得したトリガーからの関連した情報及びターゲットＴＤＯのＵＲＬをＤＡＥ／ブラウザに伝達することができる。ブラウザは、実行又は終了などのトリガーに含まれるアクションを行うことができる。
図９２は、トリガー伝達サービスの動作概念を示す図である。
トリガー伝達サービスを通じて第２スクリーンデバイスから受信されたトリガー又は拡張された活性化トリガー内に含まれるアクション情報によって動作する方法を示すことができる。
第２スクリーンデバイスは、トリガー伝達サービスを通じてトリガーイベントアクションのトリガーを取得し、取得されたトリガーからＤａｔａ ＩＤなどの情報を抽出することができる。その後、データは、ＡＪＡＸを用いて現在実行されるＴＤＯに伝達することができる。ＴＤＯは、受信したデータによって適切な動作を行うことができる。
ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒが状態変数として定義される上述したトリガーサービス状態変数の他の実施例において、トリガー伝達サービスの動作概念を説明する。
この実施例において、直接実行モデルの場合、コンテンツｉｄ、すなわち、“ｃ＝”がＤＴＶＣＣストリーム又はＡＣＲサーバーを介して受信されたトリガーに含まれると、受信機は、受信された時間ベーストリガー値をＡＴＳＣＴｒｉｇｇｅｒ状態変数の値に設定することができる。時間ベーストリガーが受信機に到達すると、状態変数の値が直ちに変更されたり、ＳｅｔＴｒｉｇｇｅｒアクションによって第２スクリーンデバイスに伝達されうる。
本実施例で、ＴＤＯモデルの場合、コンテンツｉｄ、すなわち、“ｃ＝”がＤＴＶＣＣストリーム又はＡＣＲサーバーを介して受信されたトリガー内に含まれないと、受信機は、活性化トリガーを受信し、ＴＰＴからの関連した情報及びトリガー情報を抽出及び結合して拡張されたトリガーを生成する。その後、拡張されたトリガーの活性化時間に（又は、その前に）、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ状態変数の値が設定されたり、ＳｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒアクションによって第２スクリーンデバイスに伝達されうる。
図９３は、第１アプローチによる双方向通信サービス状態変数の一実施例である。
双方向通信サービスは、第２スクリーンデバイス内のアプリケーションとの双方向通信に参加するように準備されたプライマリデバイスで実行されるＤＯがあるかを、クライアントデバイスが決定するようにすることができる。
双方向通信サービスは、クライアントデバイスが受信機で実行されるＤＯから双方向通信を受信するようにすることができる。これを支援するために、２個の互いに異なるアプローチが存在しうる。
以下、双方向通信サービスを実現する第１アプローチを説明する。
まず、クライアントデバイスが登録すると、（一般に、クライアントデバイス上で）ＷｅｂＳｏｃｋｅｔサーバーのＩＰアドレス及びＴＣＰポートを提供することができる。ＤＯがクライアントデバイスと通信することを希望すると、登録時に提供されたアドレス及びポートを用いてクライアントデバイスへのＷｅｂＳｏｃｋｅｔ接続を確立することができる。
第１アプローチにおいて、双方向通信サービスは、図９３に示す状態変数を有することができる。
ＣｌｉｅｎｔＬｉｓｔ状態変数は、双方向通信のために登録されたクライアントのリストであってもよい。また、Ｎａｍｅ、ＩＰＡｄｄｒｅｓｓ及びＰｏｒｔは、各クライアントに対するネーム、ＩＰアドレス及びＴＣＰポートを意味することができる。
図９４は、第１アプローチによるＣｌｉｅｎｔＬｉｓｔ状態変数のＸＭＬスキマーテーブルの一実施例である。
ＣｌｉｅｎｔＬｉｓｔは、図９４のテーブルによって記載されたＸＭＬスキマーに従うＸＭＬ文書の形態であってもよい。
Ｎａｍｅ状態変数は、双方向通信のために登録されたクライアントのネームであってもよい。
ＩＰＡｄｄｒｅｓｓ状態変数は、双方向通信のために登録されたクライアントに対するＷｅｂＳｏｃｋｅｔサーバーのＩＰアドレスであってもよい。
ＴＣＰＰｏｒｔ状態変数は、双方向通信のために登録されたクライアントに対するＷｅｂＳｏｃｋｅｔサーバーのＴＣＰポートであってもよい。
図９５は、第１アプローチによるトリガーサービスアクションの一実施例である。
第１アプローチにおいて、双方向通信サービスは、図９５のテーブルによって記載されたように、２個のアクションを有することができる。
ＳｉｇｎＵｐアクションは、クライアントが双方向通信に参加することに関心があることを示し、用いられるネーム及びＩＰアドレス及びポートを提供して接続を確立するために用いることができる。
ＳｉｇｎＯｆｆアクションは、クライアントが双方向通信に参加することにもう関心がないことを示すために用いることができる。
図９６は、第１アプローチによるＳｉｇｎＵｐアクションの引数の一実施例である。
Ｎａｍｅ入力引数は、登録されたクライアントと関連したネームであってもよい。これは、装置のホストネームであってもよい。これは、既に登録された任意の他のクライアントのネームと別個であってもよい。
ＩＰＡｄｄｒｅｓｓ入力引数は、接続を確立する時にＤＯによって用いられるＷｅｂＳｏｃｋｅｔサーバーのＩＰアドレスであってもよい。
ＴＣＰＰｏｒｔ入力引数は、接続を確立する時にＤＯによって用いられるＷｅｂＳｏｃｋｅｔサーバーのＴＣＰポートであってもよい。
図９７は、第１アプローチによるＳｉｇｎＯｆｆアクションの引数の一実施例である。
Ｎａｍｅ入力引数は、双方向通信サービスのために登録される時にクライアントが提供したネームであってもよい。その目的は、現在送信終了（ｓｉｇｎｉｎｇ ｏｆｆ）するクライアントを識別することである。
図９８は。第２アプローチによる双方向通信サービス状態変数の一実施例である。
以下、双方向通信サービスを実現する第２アプローチを説明する。
プライマリデバイスで実行されるこのようなＤＯが存在すると、第２スクリーンデバイス内のアプリケーションは、第２スクリーンデバイス内のアプリケーションが双方向通信に参加する準備ができていることを示しながら、ＴＣＰ／ＩＰ接続を要求することができる。接続の第２スクリーンデバイス側上のＴＣＰ／ＩＰアドレス及びポートが第２スクリーンデバイスの固有識別子としての機能を持つことができる。バイトは、ＴＣＰ／ＩＰ接続を通じて第２スクリーンデバイス及びプライマリデバイス内のＤＯ間で自由に伝送されうる。
双方向通信サービスは、図９８に示す２個の状態変数を有することができる。
ＣｏｎｎｅｃｔｉｏｎＡｄｄｒｅｓｓ状態変数は、＜ａｄｄｒｅｓｓ＞：＜ｐｏｒｔ＞のフォーマットで、第２スクリーンデバイスからの接続要求が向くＩＰアドレス及びＴＣＰポートを含むことができる。
Ｓｔａｔｕｓ状態変数は、第２スクリーンデバイスとの双方向通信に参加するように準備された実行ＤＯが存在するかを示し、ここで、“真”は、実行されるこのようなＤＯが存在するということを意味し、“偽”は、このようなＤＯが実行されないということを意味する。
本発明の一実施例において、Ｓｔａｔｕｓ状態変数のデータタイプは、“ストリング”であってもよい。この実施例で、Ｓｔａｔｕｓ状態変数の可能な値は“はい”及び“いいえ”であってもよい。
第２アプローチにおいて、双方向通信サービスは任意のアクションを有しなくてもよい。
図９９は第２アプローチによるｏｎＢｙｔｅｓＲｅｃｅｉｖｅｄ関数の一実施例である。
以下、メッセージを伝送及び受信するためにプライマリデバイス内のＤＯによって用いられるＡＰＩを説明する。
次のＡＰＩは、双方向通信サービスを用いてプライマリデバイスで実行されるＤＯが第２スクリーンデバイスで実行されるアプリケーションとの双方向通信に参加するようにすることができる。
ＴＶ受信機は、ＤＯが終了する度に双方向通信サービスのためにＵＰｎＰ“Ｓｔａｔｕｓ”状態変数を“偽”に設定し、通信する前に新しいＤＯが事前にその状態変数を“真”に設定することができる。
前述した“Ｓｔａｔｕｓ”状態変数のデータタイプがストリングである実施例の場合、ＴＶ受信機は、ＤＯが実行を始める度にＵＰｎＰ状態変数“Ｓｔａｔｕｓ”を“いいえ”に設定し、通信前にＤＯが事前にその状態変数を“はい”に設定しなければならない。
新しい特性であるｏｎＢｙｔｅｓＲｅｃｅｉｖｅｄ関数は、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスに付加することができる。
コールバック関数であるｏｎＢｙｔｅｓＲｅｃｅｉｖｅｄ関数は、双方向通信サービスを通じてＤＯに対するバイトが受信される時に呼び出すことができる。２個の引数、すなわち、“ａｄｄｒｅｓｓ”及び“ｂｙｔｅｓ”を定義することができる。
“ａｄｄｒｅｓｓ”は、＜ａｄｄｒｅｓｓ＞：＜ｐｏｒｔ＞のフォーマットで受信されたバイトの送信者のＩＰアドレス及びＵＤＰポートを含むストリングであってもよい。
“ｂｙｔｅｓ”は、受信されたバイトを示すストリングであってもよい。実施例によって、ＵＤＰ及び／又はＩＰヘッダーを除くものであってもよい。
図１００は、第２アプローチによるｓｅｔＳｔａｔｕｓＹｅｓ（）の一実施例である。
新しい方法、すなわち、ｓｅｔＳｔａｔｕｓＹｅｓ（）をＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスに追加することができる。
ｓｅｔＳｔａｔｕｓＹｅｓ（）は、双方向通信サービスのＵｐｎＰブール（Ｂｏｏｌｅａｎ）状態変数“Ｓｔａｔｕｓ”の値を“真”に設定し、ＤＯが通信に参加する準備ができていないことを示すことができる。
ｓｅｔＳｔａｔｕｓＹｅｓ（）は、任意の引数を有しなくてもよい。
図１０１は、第２アプローチによるｓｅｔＳｔａｔｕｓＮｏ（）の一実施例である。
新しい方法、すなわち、ｓｅｔＳｔａｔｕｓＮｏ（）をＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスに追加することができる。
ｓｅｔＳｔａｔｕｓＮｏ（）は、双方向通信サービスのＵｐｎＰブール状態変数“Ｓｔａｔｕｓ”の値を“偽”に設定し、ＤＯが通信に参加する準備ができていないということを示すことができる。
ｓｅｔＳｔａｔｕｓＮｏ（）は、任意の引数を有しなくてもよい。
図１０２は、第２アプローチによるｓｅｔＳｔａｔｕｓ（）の一実施例である。
前述した“Ｓｔａｔｕｓ”状態変数のデータタイプがストリングである実施例の場合、ｓｅｔＳｔａｔｕｓ（）はＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスに追加されてもよい。
ｓｅｔＳｔａｔｕｓ（）は、双方向通信サービスのＵｐｎＰ状態変数“Ｓｔａｔｕｓ”の値を設定することができる。
ｓｅｔＳｔａｔｕｓ（）は状態引数を有することができる。
状態引数は、ＤＯが第２スクリーンデバイスとの双方向通信に参加できると“はい”に設定し、そうでないと“いいえ”に設定することができる。
図１０３は、第２アプローチによるｓｅｎｄＢｙｔｅｓ（）の一実施例である。
新しい方法、すなわち、ｓｅｎｄＢｙｔｅｓ（）をＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスに追加することができる。
ｓｅｎｄＢｙｔｅｓ（）は双方向通信サービスを用いてバイトを伝送することができる。
ｓｅｎｄＢｙｔｅｓ（）は、２個の引数、すなわち、アドレス及びバイトを有することができる。
“ａｄｄｒｅｓｓ”引数は、＜ａｄｄｒｅｓｓ＞：＜ｐｏｒｔ＞のフォーマットでバイトに対するあて先ＴＣＰ／ＩＰアドレス及びポートを意味することができる。
“ｂｙｔｅｓ”引数は、伝送されるバイトを意味することができる。
図104は、ＡｐｐＵＲＬサービス状態変数の一実施例である。
ＡｐｐＵＲＬサービスは、第２スクリーンデバイスが現在実行中のＤＯと関連した第２スクリーンアプリケーションのネーム及びベースＵＲＬを決定するようにすることができる。
ＵＰｎＰ ＡｐｐＵＲＬサービスは、２個の状態変数、すなわち、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅを有することができる。
ＡｐｐＵＲＬ状態変数の値は、現在実行中のＤＯと関連した第２スクリーンアプリケーションのベースＵＲＬであってもよい。第１スクリーンデバイス上に実行される関連した第２スクリーンアプリケーションを有するＤＯがないと、ＡｐｐＵＲＬ状態変数の値はヌルストリングであってもよい。
ＡｐｐＮａｍｅ状態変数の値は、現在実行中のＤＯと関連した第２スクリーンアプリケーションのネームであってもよい。第１スクリーンデバイス上で実行される関連した第２スクリーンアプリケーションを有するＤＯがないと、ＡｐｐＮａｍｅ状態変数の値はヌルストリングであってもよい。
図105は、ＡｐｐＵＲＬサービスアクションの一実施例である。
ＡｐｐＵＲＬサービスは、一つのアクション、すなわち、ＧｅｔＡｐｐＵＲＬを有することができる。
図106は、ＧｅｔＡｐｐＵＲＬアクションの引数の一実施例である。
ＧｅｔＡｐｐＵＲＬアクションは、２個の引数、すなわち、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅを有することができる。
ＡｐｐＵＲＬ出力引数は、ＡｐｐＵＲＬ状態変数の現在値であってもよい。ＡｐｐＮａｍｅ出力引数は、ＡｐｐＮａｍｅ状態変数の現在値であってもよい。
したがって、ＧｅｔＡｐｐＵＲＬアクションを通じて、ＡｐｐＵＲＬ状態変数の現在値及びＡｐｐＮａｍｅ状態変数の現在値を得ることができる。
図107は、プロキシＨＴＴＰサーバーサービス（Ｐｒｏｘｙ ＨＴＴＰ Ｓｅｒｖｅｒ ｓｅｒｖｉｃｅ）の動作概念図の一実施例である。
受信機は、プロキシＨＴＴＰサーバーサービスを支援することができる。プロキシＨＴＴＰサーバーサービスは、第２スクリーンデバイスで必要とするＴＤＯ／ファイルが放送網を通じて伝送される場合、これをＴＶ受信機を通じて取得できるようにするサービスを意味することができる。
プロキシＨＴＴＰサーバーサービスの動作概念図は、放送システム107010、ＡＣＲサーバ（107020）、放送社ＡＴＳＣ２．０ ｉＴＶサーバ（107030）、ＡＴＳＣ２．０受信（107040）、及び／又は第２スクリーンデバイス107050を含むことができる。
放送システム107０１０は、放送システム４２０１０と同一であってもよい。
ＡＣＲサーバー107０２０は、ＡＣＲサーバー４２０２０と同一であってもよい。
放送社ＡＴＳＣ２．０ ｉＴＶサーバー107０３０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
ＡＴＳＣ２．０受信機107０４０は、放送Ａ／Ｖ及びインタラクティブサービスと関連したトリガーなどを受信し、これを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。プロキシＨＴＴＰサーバーサービスは、ＡＴＳＣ２．０受信機107０４０がプロキシサーバーと同様の役割を持つようにするサービスであってもよい。第２スクリーンデバイスで要求したファイルを第２スクリーンデバイスに效率的に提供できるようにするためのものであってもよい。
第２スクリーンデバイス107０５０は、第２スクリーンデバイス４２０５０と同一であってもよい。
プロキシＨＴＴＰサーバーサービスは、受信機が放送ストリーム或いはインターネットに存在するファイルに第２スクリーンデバイスを通じて接近できるようにすることによって、第２スクリーンデバイスが放送ストリームを通じて伝送されるコンテンツにも接近できるようにする。そして、複数の第２スクリーンデバイスがインターネットに存在する同一ファイルを接近する場合、各第２スクリーンデバイスが個別的に同じファイルに接近する重複性を最小化することができる。
図108は、プロキシサーバーサービス状態変数（Ｐｒｏｘｙ Ｓｅｒｖｅｒ Ｓｅｒｖｉｃｅ Ｓｔａｔｅ Ｖａｒｉａｂｌｅ）の一実施例である。
ＵＰｎＰプロキシサーバーサービスは、ＨＴＴＰプロキシサーバーを提供し、第２スクリーンデバイスがＦＬＵＴＥセッションを通じて放送でＴＶ受信機に伝達されるファイルにアクセスするようにすることができ、家庭内の複数の第２スクリーンデバイスが同時に同一ファイルを検索するとき、第２スクリーンデバイスによってインターネットサーバーからより效率的にファイルを検索できるようにする。
これを可能にさせるために、状態変数及びアクションを定義することができる。
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービスは、単一状態変数、すなわち、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬを有することができる。
ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の値は、ＨＴＴＰプロキシサーバーのＵＲＬ、すなわち、プロキシサーバーを通じて要求をルーティング（ｒｏｕｔｅ）するためにＨＴＴＰ要求が向かうＵＲＬであってもよい。
図109は、プロキシサーバーサービスアクション（Ｐｒｏｘｙ Ｓｅｒｖｅｒ Ｓｅｒｖｉｃｅ Ａｃｔｉｏｎ）の一実施例である。
ＵＰｎＰプロキシサーバーサービスは、単一アクション、すなわち、ＧｅｔＰｒｏｘｙＵＲＬを有することができる。
図110は、ＧｅｔＰｒｏｘｙＵＲＬアクションの引数の一実施例である。
ＧｅｔＰｒｏｘｙＵＲＬアクションは、単一引数、すなわち、ＰｒｏｘｙＵＲＬを有することができる。
ＰｒｏｘｙＵＲＬ出力引数は、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の現在値であってもよい。
したがって、ＧｅｔＰｒｏｘｙＵＲＬアクションによって、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の現在値を得ることができる。
図111は、ＲｅｑｕｅｓｔＦｉｌｅｓ（）の一実施例である。
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数の他の実施例は、ＡＴＳＣＰｒｏｘｙＳｅｖｅｒＵＲＬというＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、ＧｅｔＰｒｏｘｙＳｅｒｖｅｒＵＲＬ（）というアクションを定義することができる。
ＡＴＳＣＰｒｏｘｙＳｅｖｅｒＵＲＬ状態変数は、ＵＲＩの形態で受信機内のプロキシサーバーに対する参照を含むことができる。プロキシサーバーは、第２スクリーンデバイスからファイルに対するＨＴＴＰ要求を受け、インターネット又は放送ストリーム内のＦＬＵＴＥセッションからファイルを検索する。その後、プロキシサーバーは、ＨＴＴＰ応答として検索されたファイルを第２スクリーンデバイスに送信する。
ＧｅｔＰｒｏｘｙＳｅｒｖｅｒＵＲＬ（）は、ＰｒｏｘｙＳｅｖｅｒＵＲＬの値を読み込むようにするアクションであってもよい。ＰｒｏｘｙＳｅｖｅｒＵＲＬを引数として有することができる。
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数の更に他の実施例は、さらに、ＡＴＳＣＦｉｌｅＬｉｓｔというＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、ＲｅｑｕｅｓｔＦｉｌｅｓ（）というアクションを定義することができる。
放送ストリームに存在するファイルは、放送コンテンツの受信が可能な受信機でのみ取得することができる。したがって、放送コンテンツを受信できない第２スクリーンデバイス上で放送コンテンツに含まれたファイルに接近可能にするために必要なＵＰｎＰ状態変数及びアクションを定義することができる。すなわち、ＦＬＵＴＥセッションを通じてダウンロードしたいファイルリストであるＡＴＳＣＦｉｌｅＬｉｓｔをＵＰｎＰ状態変数として定めたり、第２スクリーンデバイスが受信機に該当のファイルを要求するＲｅｑｕｅｓｔＦｉｌｅｓ（）アクションを通じて特定ファイル或いは複数のファイルを取得できるようにすることができる。
ＡＴＳＣＦｉｌｅＬｉｓｔ状態変数は、受信機内にプロキシサーバーへの要求されたファイルのＣＳＶリストを含むことができる。
ＲｅｑｕｅｓｔＦｉｌｅｓ（）は、放送ストリーム或いはインターネット上に存在する特定ファイルをダウンロードするように要求するアクションであってもよい。特に、放送ストリームに存在するファイルの場合、要求したファイルをＦＬＵＴＥセッションを通じてダウンロードするようにすることができる。
図112は、第２スクリーンデバイスアーキテクチャの一実施例である。
動作の理論について説明する。
２つのモードの動作が存在することができ、その一つの動作モードでは、トリガされたアプリケーション（ＴＤＯ）がＴＶ受信機上で実行され、他の動作モードでは、ノン−トリガされたアプリケーション（パッケージアプリケーション）がＴＶ受信機上で実行される。
ＴＶ受信機上で実行されるトリガされたアプリケーションの場合、ＴＶ受信機上に現在表示されている番組が、第２スクリーン支援を有する関連したインタラクティブデータサービスを有すると、第２スクリーンデバイスのユーザは、デバイス上の適切なアプリケーションを活性化させることができる。このアプリケーションは、ＵＰｎＰディスカバリ及び記述プロセスを経てＴＶ受信機上のトリガーサービス、双方向通信サービス及びプロキシサーバーサービスを発見することができる。
すると、第２スクリーンアプリケーションは、トリガーサービスに対するＵＰｎＰ“イベンティング”を申し込み、伝達のために準備されたトリガーの通知を得、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ又はＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いて使用するように設計されたトリガーを取得することができる。この結果、第２スクリーンアプリケーションが適切な時間に適切なトリガーを得ることができる。すると、アプリケーションは、いずれの方式で用いられるように設計されても、それらのトリガーに対して動作することができる。
第２スクリーンアプリケーションはまた、双方向通信サービスに対するＵＰｎＰ“イベンティング”を申し込み、双方向通信のための接続を要求するために用いられるＴＣＰ／ＩＰアドレス及びポートの通知、及び通信する準備がされるプライマリデバイスで実行されるＤＯが存在する時の通知を得ることができる。すると、アプリケーションは、このような通信を支援する任意のＤＯとの双方向通信に参加することができる。
トリガー及び／又は双方向通信によるアクションはたまたま、第２スクリーンアプリケーションがファイルをダウンロードするように要求することができる。それらのファイルは、インターネット上のＨＴＴＰサーバーから利用可能であるか、又はＴＶ放送内のセッションから利用可能でありうる（又は、両者から利用可能であってもよい）。
所望の全てのファイルがインターネットを介して利用可能であり、第２スクリーンデバイスがネットワークへの良好な接続性を有すると、アプリケーションは簡単にファイルを直接検索することができる。
所望のファイルの一部又は全てが、ＴＶ放送のみを通じて利用可能であり、受信機がＨＴＴＰプロキシサーバーサービスを提供すると、アプリケーションは、ＧｅｔＰｒｏｘｙＵＲＬアクションでプロキシサーバーＵＲＬを得、プロキシサーバーを通じて所望のファイルを検索することができる。アプリケーションはまた、直接的な方式よりは、かえってそのようにファイルを検索することがより便利な他の状況ではプロキシサーバーを用いるように選択してもよい。
ＴＶ受信機上で実行されるノン−トリガーアプリケーションの場合、現在表示されている番組と関係なく、ユーザは、その中でも、ＡｐｐＵＲＬサービスを通じて第２スクリーンデバイス上で開始される同伴者アプリケーションのネーム及び位置を利用可能にするＴＶ受信機上のＤＯを活性化させることができる。
第２スクリーンデバイス上の制御ポイントは、ＡｐｐＵＲＬサービスと関連したＵＰｎＰ“イベンティング”を申し込み、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅ属性に対する変更の通知を得ることができる。すると、制御ポイントは、利用可能なサービスが係留（ｐｅｎｄｉｎｇ）中であるということを第２スクリーンデバイスのユーザに知らせる。次に、ユーザは、ＡｐｐＮａｍｅを見てサービスを選択し、第２スクリーンデバイス上で同伴者第２スクリーンアプリケーションを開始させる。
第２スクリーンアプリケーションは、そのＤＯが受信機に以前にダウンロードされた放送社提供パッケージアプリケーションである時にも、ＡＴＳＣ２．０受信機上で実行されるＤＯと関連付けられてもよく、ここで、放送社提供パッケージアプリケーションのライフサイクルは、放送社の代わりに消費者によって制御される。同伴者第２スクリーンアプリケーションを識別するトリガーの不在時に、受信機は、第２スクリーンデバイス上の制御ポイントがＧｅｔＡｐｐＵＲＬアクションを用いて、公開された第２スクリーンアプリケーションＵＲＬにアクセスして第２スクリーンデバイス上で開始するようにするＡｐｐＵＲＬサービスを提供する。
第２スクリーンデバイスアーキテクチャの一実施例は、受信機と相互作用する第２スクリーンアプリケーションと第２スクリーンデバイスを示している。
第２スクリーンデバイスアーキテクチャの一実施例は、遠隔コンテンツサーバー112０１０、ＴＶ受信機112０２０及び／又は第２スクリーンデバイス112０３０を含むことができる。
遠隔コンテンツサーバー112０１０は、コンテンツを提供できるサーバーであってもよい。受信機112０２０又は第２スクリーンデバイス112０３０にコンテンツを提供することができる。
ＴＶ受信機112０２０は、ＵＰｎＰトリガーサービス及びＵＰｎＰプロキシサーバーサービスを提供することができる。前述した受信機と同一であってもよい。
第２スクリーンデバイス112０３０は、第２スクリーンアプリケーション（ＡＴＳＣ２．０ Ａｐｐ）を有することができ、第２スクリーンアプリケーションは、トリガーハンドラー内にＵＰｎＰ制御ポイント（ＣＰ）モジュールを有することができる。ＵＰｎＰ制御ポイント（ＣＰ）モジュールは、第２スクリーンアプリケーション（ＡＴＳＣ２．０ Ａｐｐ）及びＴＶ受信機112０２０上のトリガーサービス及びプロキシサーバーサービス間の全てのＵＰｎＰ通信をハンドリングする。ＵＰｎＰ制御ポイント（ＣＰ）モジュールは、探索プロセスを管理し、プロキシサーバーＵＲＬを得、トリガーサービスイベンティングを申し込むことができる。
ＵＰｎＰトリガーサービスからのトリガーはトリガーハンドラーに伝達されうる。新しいＤＯがＤＡＥ（すなわち、ブラウザ）でダウンロードされて実行されるということをトリガーが示すと、トリガーハンドラーはそれを処理する。ブラウザで既に実行されたＤＯが任意のアクションを取らなければならないとトリガーが指示すると、トリガーハンドラーはトリガーをＤＯに伝達することができる。第２スクリーンデバイスのユーザは、ＤＯと相互作用ですることがきる。トリガーハンドラーはユーザに見えなくてもよい。
第２スクリーンアプリケーションは、必要によって次の機能を有することができる。１）ＵＰｎＰディスカバリ及び記述プロトコルを用いて、ＴＶ受信機上でトリガーサービス、及び、利用可能であれば、プロキシサーバーサービスを探す。２）ＵＰｎＰ ＳＵＢＳＣＲＩＢＥプロトコルを用いてトリガーサービスイベンティングを申し込む。３）プロキシサーバーサービスのＧｅｔＰｒｏｘｙＵＲＬアクションを実行（ｉｎｖｏｋｅ）して（利用可能であれば）ＨＴＴＰプロキシサーバーのＵＲＬを得る。４）トリガーサービスイベントを通じて伝達されたトリガーを受信する。５）直接実行トリガーが受信され、トリガー内で識別されたＤＯがまだＤＡＥで実行されていないと、（必要なら、まずダウンロードし）ＤＡＥで実行し始める。６）（必要なら、ＤＯをダウンロードして開始した後）各受信された直接実行トリガーを、トリガーで識別されたＤＯに伝達する。７）ＴＤＯトリガーが受信され、トリガーのアクション属性が“ＴｒｉｇｇｅｒＥｖｅｎｔ”以外の任意のものであれば、アクションを実行する（例えば、ＴＤＯ実行を準備、ＴＤＯ実行、ＴＤＯ終了など）。８）ＴＤＯトリガーが受信され、トリガーのアクション属性が“ＴｒｉｇｇｅｒＥｖｅｎｔ”であれば、リガーを、トリガーのターゲットとして識別されたＴＤＯに伝達する。ＴＤＯがＤＡＥでまだ実行されていないと、トリガーを廃棄する。９）必要によって、インターネットに直接接続してＴＶ受信機上のプロキシサーバーサービスを通じて（ＴＤＯを含む）ファイルをダウンロードする。
直接実行トリガー及びＴＤＯトリガーは、“スプレッド”又は“ディフュージョン”属性を含まないと、受信するとすぐに動作することができる。トリガーが“スプレッド”又は“ディフュージョン”属性を含むと、アクションはランダム間隔だけ遅延されうる。
図113は、受信機の簡略化した構造図の一実施例である。
受信機の簡略化した構造図は、アンテナ（ｒｃｖｒ２０１０）、チューナー（ｒｃｖｒ２０２０）、ＥＰＧ（ｒｃｖｒ２０３０）、ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）、チャネルマネジャー（ｒｃｖｒ２０５０）、ＳＩモジュール（ｒｃｖｒ２０５１）、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）、キャプションモジュール（ｒｃｖｒ２０７０）、トリガーモジュール（ｒｃｖｒ２０８０）、ウェブブラウザ（ｒｃｖｒ２０９０）、ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）、ネットワークプロトコルスタック（ｒｃｖｒ２１００）、ネットワークインターフェース（ｒｃｖｒ２１１０）、ＵＩモジュール（ｒｃｖｒ２１２０）、オーディオデコーダ（ｒｃｖｒ２１４０）、ビデオデコーダ（ｒｃｖｒ２１５０）、スピーカー（ｒｃｖｒ２１６０）、ディスプレイモジュール（ｒｃｖｒ２１７０）、グラフィックプロセッサ（ｒｃｖｒ２１８０）、遠隔制御器受信器（ｒｃｖｒ２１９０）及び／又は遠隔制御器（ｒｃｖｒ２２００）を含むことができる。
アンテナ（ｒｃｖｒ２０１０）は、放送ストリームによって放送信号を受信することができる。ここで、アンテナ（ｒｃｖｒ２０１０）は、技術の分野で一般に用いられるものであってもよい。
チューナー（ｒｃｖｒ２０２０）は、受信機のチャネルを探したり同調することができ、無線周波数増幅器、ローカルオシレータ、周波数変換及び入力回路、探知器（ｓｅｅｋｅｒ）などを含むことができる。チューナー（ｒｃｖｒ２０２０）は、技術の分野で一般に用いられるものであってもよい。
ＥＰＧ（ｒｃｖｒ２０３０）は、ＴＶ放送の空いている周波数帯や付加チャネルを用いてＴＶ番組の放送時間と内容、出演者情報などを送る放送プログラム案内サービスであってもよい（Ｅｌｅｃｔｒｏｎｉｃ ｐｒｏｇｒａｍ ｇｕｉｄｅ）。受信されたＥＰＧデータは記憶しておき、視聴者がリモコンでこのＥＰＧを操作してプログラムを選択して予約し、ペア・バー・ビュー方式（ｐａｙ ｐｅｒ ｖｉｅｗ）プログラム注文、主題又は種別プログラム検索、ビデオ録画などを可能にする。受信したＥＰＧは、ＵＩモジュールにも伝達されてもよい。
ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）は、ＶＳＢ信号又はＤＶＢ信号を復調することができる。ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）は、変調されたＶＳＢ又はＤＶＢ（ｅ．ｇ．，ＯＦＤＭ−変調信号）を本来の信号に回復することができる。ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）の復調プロセスは、技術の分野で一般に用いられるものであってもよい。
チャネルマネジャー（ｒｃｖｒ２０５０）は、受信されたＥＰＧを用いて、チャネル管理を行うことができる。ＳＩモジュールで処理されたＥＰＧを伝達することができる。一般のチャネルマネジャー役割を担うことができる。
ＳＩモジュール（ｒｃｖｒ２０５１）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）を通じて放送ストリームが入ってくると、プログラム構成情報（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）を把握することができる。このように把握された情報から、この放送プログラムにいくつのキャプションがあり、トリガーがサービス＃６にあるか否かなどがわかる。
ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、復調された信号の送信ストリーム（ＴＳ）をデコードすることができる。ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、送信ストリームからキャプションストリームを得てキャプションモジュール（ｒｃｖｒ２０７）に伝達することができる。ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、デコードされたオーディオ及びビデオ信号をオーディオ／ビデオデコーダに送信することができる。
キャプションモジュール（ｒｃｖｒ２０７０）は、キャプションストリームを受信することができる。キャプションモジュール（ｒｃｖｒ２０７０）は、サービス＃６又は他のサービスをモニタし、サービス＃６又はトリガーを送信するトリガーが選択されてトリガーモジュール（ｒｃｖｒ２０８０）に伝送されるか、又はキャプションテキストが処理されてスクリーン上にディスプレイされるかを決定することができる。トリガーデータは、トリガーモジュール（ｒｃｖｒ２０８０）に伝達することができる。他のキャプションサービスは、キャプションテキスト処理してグラフィックプロセッサ（ｒｃｖｒ２１８０）に伝送することができる。キャプションモジュール（ｒｃｖｒ２０７０）は、前述したＳＩモジュール（ｒｃｖｒ２０５１）が把握した情報に基づいて、現在受信されているデジタルキャプション中にトリガーがある場合にはトリガーモジュール（ｒｃｖｒ２０８０）に伝達する。
トリガーモジュール（ｒｃｖｒ２０８０）は、トリガー、ＴＰＴ及び／又はＡＭＴ情報をパーシングし、パーシングされたデータを処理することができる。トリガーモジュール（ｒｃｖｒ２０８０）は、トリガーのＵＲＩ情報値を用いて、ネットワークプロトコルスタック（ｒｃｖｒ２１００）を通じてネットワークにアクセスすることができる。ＵＲＩ情報値は、ＨＴＴＰサーバーのアドレスであってもよい。トリガーモジュール（ｒｃｖｒ２０８０）は、ＴＰＴファイルコンテンツを分析してＴＤＯ ＵＲＬを得ることができる。また、トリガーモジュール（ｒｃｖｒ２０８０）は、ＡＭＴをパーシングしてデータを処理することができる。他の情報は、パーシングを通じて得ることができる。ＡＭＴメッセージが受信された後、ウェブブラウザに対応するＴＤＯ ＵＲＬは、所定の時間及び動作によって伝達されたり、現在動作中のＴＤＯが所定の時間に停止することができる。これは、ＴＤＯアクションに対応し、トリガーモジュール（ｒｃｖｒ２０８０）は動作するウェブブラウザにコマンドを送信することができる。本発明に係るトリガーモジュール（ｒｃｖｒ２０８０）の動作は、以下に詳述する。トリガーモジュール（ｒｃｖｒ２０８０）は、直間接的にネットワークプロトコルスタック（ｒｃｖｒ２１００）を通じてインターネットにおけるサーバーに接続することができる。トリガーモジュール（ｒｃｖｒ２０８０）は直ちに、ＤＴＶＣＣで受信されたトリガーを分析し、必要な場合、ネットワークインターフェース（ｒｃｖｒ２１１０）を介して、ＴＰＴファイルをインターネットからダウンロードして処理することができる。ＴＰＴファイルをダウンロードするとすぐに処理して必要な動作を取ることができる。このとき、もし、第２スクリーンに関連したトリガーであり、関連したイベントがあると、前述したように、様々な方式で第２スクリーンデバイスと通信することができる。このような通信は、後述するＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）で行うことができる。
ウェブブラウザ（ｒｃｖｒ２０９０）は、トリガーモジュール（ｒｃｖｒ２０８０）からコマンドを受信し、ＵＩモジュール（ｒｃｖｒ２１２０）からブラウザキーコードを受信し、遠隔制御器受信器（ｒｃｖｒ２１９０）からブラウザキーコードを受信し、ネットワークプロトコルスタック（ｒｃｖｒ２１００）と通信することができる。
ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）は、第２スクリーンデバイスを発見してトリガーを送信したり、或いは第２スクリーンデバイスに必要な情報を再生成して送信することができる。前述したように、ネットワークインターフェース（ｒｃｖｒ２１１０）を通じてトリガーを受けたとき、第２スクリーンに関連したトリガーであり、関連したイベントがあると、ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）は、第２スクリーンデバイスと通信することができる。
ネットワークプロトコルスタック（ｒｃｖｒ２１００）は、トリガーモジュール（ｒｃｖｒ２０８０）及びウェブブラウザと通信し、ネットワークインターフェース（ｒｃｖｒ２１１０）を介してサーバーにアクセスすることができる。
ネットワークインターフェース（ｒｃｖｒ２１１０）は、いくつかの他の装置の共同接続又はネットワークコンピュータ及び外部ネットワークの接続を行う。ネットワークインターフェースはサーバーに接続してＴＤＯ、ＴＰＴ、ＡＭＴなどをダウンロードすることができる。ここで、ネットワークインターフェース（ｒｃｖｒ２１１０）の動作は、技術の分野で一般に用いられるネットワークインターフェース（ｒｃｖｒ２１１０）の動作であってもよい。本発明に係るネットワークインターフェース（ｒｃｖｒ１０９０）の動作は、以下に詳述する。
ＵＩモジュール（ｒｃｖｒ２１２０）は遠隔制御器受信器（ｒｃｖｒ２１９０）から、遠隔制御器（ｒｃｖｒ２２００）を用いて視聴者によって入力された情報を受信することができる。受信された情報がネットワークを用いたサービスと関連するものであれば、ブラウザキーコードをウェブブラウザに伝達することができる。受信された情報が現在ディスプレイされるビデオと関連するものであれば、信号を、グラフィックプロセッサ（ｒｃｖｒ２１８０）を通じてディスプレイモジュール（ｒｃｖｒ２１７０）に伝達することができる。
オーディオデコーダ（ｒｃｖｒ２１４０）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）から受信されたオーディオ信号をデコードすることができる。その後、デコードされたオーディオ信号は、スピーカーに伝送し、視聴者に出力することができる。ここで、オーディオデコーダ（ｒｃｖｒ２１４０）は、技術の分野で一般に用いられるものであってもよい。
ビデオデコーダ（ｒｃｖｒ２１５０）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）から受信されたビデオ信号をデコードすることができる。その後、デコードされたビデオ信号は、ディスプレイモジュール（ｒｃｖｒ２１７０）に伝送し、視聴者に出力することができる。ここで、ビデオデコーダ（ｒｃｖｒ２１５０）は、技術の分野で一般に用いられるものであってもよい。
スピーカー（ｒｃｖｒ２１６０）は、オーディオ信号を視聴者に出力することができる。スピーカーは、技術の分野で一般に用いられるものであってもよい。
ディスプレイモジュール（ｒｃｖｒ２１７０）は、ビデオ信号を視聴者に出力することができる。ディスプレイモジュール（ｒｃｖｒ２１７０）は、技術の分野で一般に用いられるものであってもよい。
グラフィックプロセッサ（ｒｃｖｒ２１８０）は、キャプションモジュール（ｒｃｖｒ２０７０）から受信されたキャプションテキスト、及びＵＩモジュール（ｒｃｖｒ２１２０）から受信された視聴者入力情報に対してグラフィック処理を行うことができる。処理された情報は、ディスプレイモジュール（ｒｃｖｒ２１７０）に伝達することができる。グラフィックプロセッサ（ｒｃｖｒ２１８０）は、技術の分野で一般に用いられるものであってもよい。
遠隔制御器受信器（ｒｃｖｒ２１９０）は、遠隔制御器（ｒｃｖｒ２２００）から情報を受信することができる。この時、キーコードはＵＩモジュール（ｒｃｖｒ２１２０）に伝達し、ブラウザキーコードはウェブブラウザに伝達することができる。
遠隔制御器（ｒｃｖｒ２２００）は、視聴者によって入力された信号を遠隔制御器受信器（ｒｃｖｒ２１９０）に伝達する。遠隔制御器（ｒｃｖｒ２２００）は、仮想チャネルを変更する視聴者入力を受信することができる。また、遠隔制御器は、アプリケーションに対して視聴者によって選択された情報を受信することができる。遠隔制御器（ｒｃｖｒ２２００）は、受信された情報を遠隔制御器受信器（ｒｃｖｒ２１９０）に伝達することができる。このとき、情報は、所定範囲外の距離で赤外線（ＩＲ）光を用いて遠隔で伝達することができる。
図114は、第２スクリーンデバイスの構造図の一実施例である。
第２スクリーンデバイスの構造図の一実施例は、ＩＯサブシステム114０１０、ファイルシステ（114０２）、ネットワークプロトコルサブシステム114０３０、及び／又は基本モジュール114０４０を含むことができる。
ＩＯサブシステム114０１０は、第２スクリーンデバイスに装着可能な、外部接続される全ての装置が接続されていてもよい。ＩＯサブシステム114０１０には、キーパッド、ディスプレイ、マイクロホン、スピーカー、ステレオジャッキ、動きセンサー、光センサー、ＧＰＳ及び／又はカメラなどを接続することができる。各入出力装置は、それぞれ、キーモジュール、ディスプレイ制御、オーディオ制御、センサー制御及び／又はカメラ制御によって制御されうる。各入出力装置は、デバイスドライバでコントロールされ、それぞれのセンサーやカメラなどは、ＩＯサブシステム114０１０によってＳＤＫ形態で関数を呼び出すと、いずれのプログラムであっても接近可能である。場合によっては、機能に制限をおき、ネイティブアプリケーションでのみ接近可能にしてもよい。
ファイルシステム114０２０は、外部ＳＤカードに対するファイルを読み書き可能になっており、ＵＳＢに接続してデータ通信可能である。ＳＤカード、フラッシュメモリー、ＵＳＢなどの装置が接続可能である。それぞれＳＤインターフェース、フラッシュメモリー制御、ＵＳＢバス制御によって制御されうる。
ネットワークプロトコルサブシステム（114０３０）では、３ＧＰＰ、Ｗｉ−Ｆｉ及び／又はブルートゥースなどを介して通信可能である。
基本モジュール（114０４０）は、その他、第２デバイスで基本的なモジュールなどがありうる。バッテリーマネジャーは、第２スクリーンデバイスのバッテリー量などを管理し、通知は、通信社或いはメーカーで第２スクリーンデバイスに通知する場合に用いられるモジュールであってもよい。また、ストアモジュールは、第２スクリーンデバイスで提供するオープンＳＤＫを用いて作られた第２スクリーン用アプリケーションを購買するモジュールであってもよい。アプリケーションマネジャーは、ストアモジュールを用いて設置されたアプリケーションを管理し、設置されたアプリケーションがアップグレードされた場合にもそれを知らせることができる。また、第２スクリーンデバイスでインターネット接続できるようにウェブモジュールが内蔵されていてもよい。個人の好みによって第２スクリーンの様々な機能に対する便宜設定をしてもよいが、ユーザ好みのプログラムを用いることができる。
基本モジュール114０４０は、その他、様々な機能を有し、基本的に、第２スクリーンデバイスに内蔵されていなければならないプログラムである。しかし、点線で表示されたモジュールは、選択的にユーザが設置すると動作するソフトウェアモジュールであってもよい。
例えば、ＵＰｎＰフレームワークモジュールは、基本的に第２スクリーンデバイスで支援しない場合にも、内蔵されていてもよい。内蔵される場合には、ネイティブアプリケーションも併せて内蔵され、ＵＰｎＰ動作を円滑にしなければならない。本受信機の構造図では、ＵＰｎＰフレームワークは、選択的にユーザが第２スクリーンサービスアプリケーション或いはＵＰｎＰフレームワークを支援するアプリケーションを設置することができる。ＵＰｎＰフレームワークモジュールを介して、地上波を受信し得る受信機を探すことができる。
図115は、第２スクリーンデバイスシナリオの一実施例である。
第２スクリーンデバイスシナリオの一実施例について説明する。
第２スクリーンデバイスシナリオの一実施例は、トリガーを受信する段階（ｓ115０１０）、ＴＰＴを要求する段階（ｓ115０２０）、応答としてＴＰＴを送信する段階（ｓ115０３０）、ＴＤＯを要求する段階（ｓ115０４０）、応答としてＴＤＯを送信する段階（ｓ115０５０）、ＴＤＯを実行する段階（ｓ115０６０）、ｓｃａｎＤｅｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ115０７０）、ディスカバリ機能を呼び出す段階（ｓ115０８０）、ＵＰｎＰアプリケーションを実行する段階（ｓ115０９０）、サーチメッセージをマルチキャストする段階（ｓ115１００）、ＵＰｎＰフレームワークを通知する段階（ｓ115１１０）、装置リストを返還する段階（ｓ115１２０）、装置ハンドルを返還する段階（ｓ115１３０）、ｓｃａｎＳｅｒｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ115１４０）、サービスリスト機能を呼び出す段階（ｓ115１５０）、ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ115１６０）、ＨＴＴＰメッセージを送信する段階（ｓ115１７０）、サービスリストを返還する段階（ｓ115１８０）、サービスハンドルのリストを返還する段階（ｓ115１９０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115２００）、サービスリスト機能を呼び出す段階（ｓ115２１０）、ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ115２２０）、ＨＴＴＰメッセージを送信する段階（ｓ115２３０）、ｓｏａｐ応答を返還する段階（ｓ115２４０）、ｓｏａｐ応答ＸＭＬを返還する段階（ｓ115２５０）、ｓｏａｐ応答をパーシングする段階（ｓ115２６０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115２７０）、サービスリスト機能を呼び出す段階（ｓ115２８０）、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ115２９０）、ＨＴＴＰメッセージを送信する段階（ｓ115３００）、ｓｏａｐ応答を返還する段階（ｓ115３１０）、ＴｉｍｅＴｏＬｉｖｅを返還する段階（ｓ115３２０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115３３０）、サービスリスト機能を呼び出す段階（ｓ115３４０）、ＤｉｓｐｌａｙＭｅｓｓａｇｅ送信する段階（ｓ115３５０）、ＨＴＴＰ ｍｅｓｓａｇｅを送信する段階（ｓ115３６０）、ヌル（ｎｕｌｌ）を返還する段階（ｓ115３７０）、ヌルを返還する段階（ｓ115３８０）、及び／又は第２スクリーンアプリケーションを実行する段階（ｓ115３９０）を含むことができる。
トリガーを受信する段階（ｓ115０１０）は、放送社から放送ストリームを通じてＤＴＶＣＣ ｉＴＶメッセージでトリガーを受信する段階であってもよい。
ＴＰＴを要求する段階（ｓ115０２０）は、受信したトリガーをパーシングし解釈して、放送社インターネットサーバーに関連したＴＰＴを要求する段階であってもよい。
応答としてＴＰＴを送信する段階（ｓ115０３０）は、要求されたＴＰＴを送る段階であってもよい。
ＴＤＯを要求する段階（ｓ115０４０）は、関連したＴＤＯをダウンロードする必要がある場合、放送社インターネットサーバーに関連ＴＤＯを要求する段階であってもよい。
応答としてＴＤＯを送信する段階（ｓ115０５０）は、要求されたＴＤＯを送る段階であってもよい。
ＴＤＯを実行する段階（ｓ115０６０）は、トリガーモジュールがＴＤＯを実行させる段階であってもよい。
ｓｃａｎＤｅｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ115０７０）は、実行されたＤＯ（又はＴＤＯ）がデバイススキャンのためにデバイスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
ディスカバリ機能を呼び出す段階（ｓ115０８０）は、デバイスディスカバリのためにＵＰｎＰフレームワークのディスカバリ機能を呼び出す段階であってもよい。
ＵＰｎＰアプリケーション（ｓ115０９０）は、第２スクリーンデバイスで第２スクリーンサービスランチャ用ＵＰｎＰアプリケーションを実行する段階であってもよい。この段階は、プライマリデバイスと独立した段階であり、ＵＰｎＰアプリケーションを実行する段階（ｓ115０９０）前に実行されてもよい。
サーチメッセージをマルチキャストする段階（ｓ115１００）は、ＵＰｎＰフレームワークが第２スクリーンデバイスを探すサーチメッセージをホームネットワーク内にマルチキャストする段階であってもよい。
ＵＰｎＰフレームワークを通知する段階（ｓ115１１０）は、サーチメッセージを受けた第２スクリーンデバイスが通知メッセージをプライマリデバイスに送信する段階であってもよい。これで、第２スクリーンデバイスの存在を知らせることができる。
デバイスリストを返還する段階（ｓ115１２０）は、ＵＰｎＰフレームワークがデバイスディスカバリ後に、デバイスリストを返還する段階であってもよい。
デバイスハンドルを返還する段階（ｓ115１３０）は、受信したデバイスリストをＤＯに伝達する段階であってもよい。
ｓｃａｎＳｅｒｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ115１４０）は、実行されたＤＯ（又は、ＴＤＯ）がサービススキャンのためにサービスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階（ｓ115１５０）は、サービスディスカバリのために、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ115１６０）は、第２スクリーンデバイスのサービス記述を得るために第２スクリーンデバイスに要求する段階であってもよい。
ＨＴＴＰメッセージを送信する段階（ｓ115１７０）は、ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ115１６０）における要求に対する結果を送る段階であり、前述したように、ＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。サービス記述をＸＭＬ形態で受信することもできる。
サービスリストを返還する段階（ｓ115１８０）は、ＵＰｎＰフレームワークがサービス記述を受けた後、サービスリストを返還する段階であってもよい。
サービスハンドルのリストを返還する段階（ｓ115１９０）は、受信したサービスリストをリターンする段階であってもよい。
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115２００）は、デバイスプロファイルを得るためにメッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階（ｓ115２１０）は、サービスディスカバリのために、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ115２２０）は、第２スクリーンデバイスのサービス記述を得るために第２スクリーンデバイスに要求する段階であってもよい。前述したＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅアクションを用いることができる。ＨＴＴＰメッセージを送信する段階（ｓ115２３０）は、ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ115２２０）における要求に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。デバイスプロファイルを受信することもできる。
ｓｏａｐ応答を返還する段階（ｓ115２４０）は、受信したデバイスプロファイルを返還する段階であってもよい。
ｓｏａｐ応答ＸＭＬを返還する段階（ｓ115２５０）は、受信したデバイスプロファイルをＸＭＬ形態で返還する段階であってもよい。
ｓｏａｐ応答をパーシングする段階（ｓ115２６０）は、ＤＯが受信したＳＯＡＰ ｍｅｓｓａｇｅをパーシングする段階であってもよい。
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115２７０）は、第２スクリーンサービスのＵＲＬアドレスを第２スクリーンデバイスに知らせるためにメッセージを送る段階であってもよい。
サービス呼び出しリスト機能を呼び出す段階（115２８０）は、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ115２９０）は、第２スクリーンサービスのＵＲＬアドレスを第２スクリーンデバイスに知らせる段階であってもよい。前述したＡｄｄＵＩＬｉｓｔｉｎｇアクションを用いることができる。第２スクリーンデバイスは、取得したＵＲＬをＵＩＬｉｓｔｉｎｇに追加することができる。
ＨＴＴＰメッセージを送信する段階（ｓ115３００）は、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ115２９０）における要求に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。
ｓｏａｐ応答を返還する段階（ｓ115３１０）は、ＵＲＬの送信がなされたことを知らせるためのメッセージを返還する段階であってもよい。
ＴｉｍｅＴｏＬｉｖｅを返還する段階（ｓ115３２０）は、ＨＴＴＰ ｍｅｓｓａｇｅを送信する段階（ｓ115３００）と同様に、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ115２９０）における要求に対する結果を送る段階であってもよい。
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ115３３０）は、ディスプレイメッセージを第２スクリーンデバイスに伝達するために、メッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階（ｓ115３４０）は、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
ＤｉｓｐｌａｙＭｅｓｓａｇｅを送信する段階（ｓ115３５０）は、第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したＤｉｓｐａｌｙＭｅｓｓａｇｅアクションを用いることができる。第２スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第２スクリーンにディスプレイすることができる。
ＨＴＴＰメッセージを送信する段階（ｓ115３６０）は、ＤｉｓｐｌａｙＭｅｓｓａｇｅを送信する段階（ｓ115３５０）に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。
ヌルを返還する段階（ｓ115３７０）は、ＨＴＴＰ／１．１ ２００ ＯＫを受けた場合、ヌルを返還する段階であってもよい。
ヌルを返還する段階（ｓ115３８０）は同様に、ヌルを応答として受けた場合、ＤＯにヌルを返還する段階であってもよい。
第２スクリーンアプリケーションを実行する段階（ｓ115３９０）は、第２スクリーンデバイスで第２スクリーンアプリケーションを実行する段階であってもよい。
図１１６は、プライマリデバイスでデジタルサービス信号を処理する方法の実施例を示す図である。
プライマリデバイスでデジタルサービス信号を処理する方法の実施例は、プライマリアプリケーションを実行する段階（ｓ１１６０１０）、インタラクティブサービスのメッセージを送信する段階（ｓ１１６０２０）、記述に対する要求を受信する段階（ｓ１１６０３０）、記述を送信する段階（ｓ１１６０４０）、及び／又はインタラクティブサービスを提供する段階（ｓ１１６０５０）を含むことができる。
プライマリアプリケーションを実行する段階（ｓ１１６０１０）は、プライマリデバイスがデジタルサービス信号に対するプライマリアプリケーションを実行する段階であってもよい。ここで、プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされないアプリケーションであってもよい。ここで、プライマリデバイスは、上述したＴＶ受信機であってもよい。ここで、プライマリアプリケーションは、ＴＶ受信機によって実行されうるＤＯを意味することができる。ここで、プライマリアプリケーションは、ＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯであってもよい。
インタラクティブサービスのメッセージを送信する段階（ｓ１１６０２０）において、メッセージは、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージを意味することができる。ここで、上述したメッセージは、プライマリデバイスから第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）に送信することができる。ここで、インタラクティブサービスは、トリガーされたアプリケーションに関連した第１モード又はトリガーされていないアプリケーションに関連した第２モードを含むことができる。ここで、セカンダリアプリケーションは、上述したプライマリアプリケーション及び第２スクリーンデバイスによって実行されるアプリケーションと関連することができる。アプリケーションは、ＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯであってもよい。ここで、トリガーされたアプリケーションはＴＤＯを意味し、トリガーされていないアプリケーションはＮＤＯを意味することができる。
記述に対する要求を受信する段階（ｓ１１６０３０）は、プライマリデバイスが第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）から記述を受信する段階であってもよい。ここで、記述は、上述したインタラクティブサービスを識別する記述を意味することができる。
記述を送信する段階（ｓ１１６０４０）は、プライマリデバイスが第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）に、要求された記述を送信する段階であってもよい。ここで、記述は、記述に記述されたインタラクティブサービスのそれぞれのサービスタイプ情報又はサービスｉｄ情報を含むことができる。ここで、サービスｉｄ情報は、インタラクティブサービスのそれぞれを識別することができる。ここで、サービスタイプ情報は、インタラクティブサービスのそれぞれのタイプを示すことができる。
インタラクティブサービスを提供する段階（ｓ１１６０５０）は、プライマリデバイスが第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）にインタラクティブサービスを提供する段階であってもよい。インタラクティブサービスは、インタラクティブサービスに対する情報を提供することによって提供することができる。
本発明の一実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスは、トリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がＵＲＬ情報であれば、プライマリデバイスはＡｐｐＵＲＬサービスを提供することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報はトリガーであってもよい。また、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がトリガーであれば、方法は、ＴＰＴ内の情報と結合することによってトリガーを増加（ａｕｇｍｅｎｔ）させる段階であって、ＴＰＴは、トリガーされたアプリケーションに対するメタデータを含む、段階と、トリガー内の識別されたイベントを示すイベント指示子を有する増加したトリガーを送信する段階をさらに含むことができる。ここで、“インタラクティブサービスに対する情報がトリガーであれば”は、プライマリデバイスがトリガーサービスを提供する場合を意味することができる。本実施例は、上述した増加したトリガーが生成及び送信される場合に対応できる。“ＴＰＴ内の情報と結合することによってトリガーを増加させる段階”は、ＴＰＴ内に含まれる情報及びトリガーを結合する段階であってもよい。ここで、イベント指示子は、上述したＡｕｇｍｅｎｔｅｄＴｒｉｇｇｅｒ内のイベントエレメントを意味することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がバイトであってもよい。また、インタラクティブサービスは、アプリケーションが実行されてセカンダリアプリケーションとの通信に参加する準備ができているかを示すｓｔａｔｕｓ状態変数を含むことができる。また、方法は、ｓｔａｔｕｓ状態変数を設定する段階をさらに含むことができる。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、ｓｔａｔｕｓ状態変数は、上述した双方向通信サービスの第２アプローチにおけるＳｔａｔｕｓ状態変数を意味することができる。ここで、“ｓｔａｔｕｓ状態変数を設定する段階”は、上述したｓｅｔＳｔａｔｕｓＹｅｓ（）、ｓｅｔＳｔａｔｕｓＮｏ（）ｏｒ ｓｅｔＳｔａｔｕｓ（）ＡＰＩを用いる場合を意味することができる。
本発明の他の実施例において、プライマリアプリケーションは、ＡＰＩを用いてインタラクティブサービスを提供する。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、ＡＰＩは、上述した双方向通信サービスのＡＰＩのうち、ｓｅｎｄＢｙｔｅｓ ＡＰＩを意味することができる。
本発明の他の実施例において、ＡＰＩは、バイト及びバイト引数に対するアドレス及びポートに関する情報を有するアドレス引数を含むことができる。ここで、アドレス引数は、ｓｅｎｄＢｙｔｅｓ ＡＰＩのアドレス引数を意味することができる。ここで、バイト引数は、ｓｅｎｄＢｙｔｅｓ ＡＰＩのバイト引数を意味することができる。
本発明の他の実施例において、方法は、メッセージを送信する前にプライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信する段階をさらに含むことができる。第２スクリーンデバイスは要求をプライマリデバイスに伝送することができる。要求は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスはメッセージを第２スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図１１７は、セカンダリアプリケーションでデジタルサービス信号を処理する方法の実施例を示す図である。
セカンダリアプリケーションでデジタルサービス信号を処理する方法の実施例は、アプリケーションを実行する段階（ｓ１１７０１０）、インタラクティブサービスのメッセージを受信する段階（ｓ１１７０２０）、記述に対する要求を送信する段階（ｓ１１７０３０）、記述を受信する段階（ｓ１１７０４０）、通知のためのプロトコルに加入する段階（ｓ１１７０５０）、通知を受信する段階（ｓ１１７０６０）、受信された通知を用いて情報を受信する段階（ｓ１１７０７０）、及び／又はファイルをダウンロードする段階（ｓ１１７０８０）を含むことができる。
アプリケーションを実行する段階（ｓ１１７０１０）は、第２スクリーンデバイスがデジタルサービス信号に対するアプリケーションを実行する段階であってもよい。ここで、アプリケーションは、第２スクリーンデバイスによって実行されうるＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯを意味することができる。
インタラクティブサービスのメッセージを受信する段階（ｓ１１７０２０）において、メッセージは、実行されたアプリケーションに対するインタラクティブサービスのメッセージを意味することができる。ここで、メッセージは、プライマリデバイスから第２スクリーンデバイスに送信することができる。
記述に対する要求を送信する段階（ｓ１１７０３０）は、第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行される第２スクリーンアプリケーション）がプライマリデバイスに記述を要求する段階であってもよい。ここで、記述はインタラクティブサービスを識別することができる。
記述を受信する段階（ｓ１１７０４０）は、第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行される第２スクリーンアプリケーション）がプライマリデバイスによって要求された記述を受信する段階であってもよい。ここで、記述は、インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及びインタラクティブサービスのそれぞれに対するタイプを示すサービスタイプ情報を有することができる。
通知のためのプロトコルに加入する段階（ｓ１１７０５０）、通知を受信する段階（ｓ１１７０６０）、及び受信された通知を用いて情報を受信する段階（ｓ１１７０７０）は、第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行される第２スクリーンアプリケーション）が上述の記述を用いて少なくとも一つのインタラクティブサービスに接近する段階に含まれてもよい。
通知のためのプロトコルに加入する段階（ｓ１１７０５０）は、第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行される第２スクリーンアプリケーション）がプライマリデバイスによって提供された少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入する段階であってもよく、これは、“イベンティング”プロトコル”に加入する上述した段階であってもよい。
通知を受信する段階（ｓ１１７０６０）は、プライマリデバイスからインタラクティブサービスに対する通知を受信する上述した段階であってもよい。通知は、上述した非同期通知であってもよい。
受信された通知を用いて情報を受信する段階（ｓ１１７０７０）は、受信された通知を用いてインタラクティブサービスに対する情報を受信する段階であってもよい。
ファイルをダウンロードする段階（ｓ１１７０８０）は、アプローチインタラクティブサービスに対するファイルをダウンロードする段階であってもよい。ファイルは、上述したアプリケーションであってもよい。
本発明の一実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がＵＲＬ情報であれば、プライマリデバイスはＡｐｐＵＲＬサービスを提供することができる。
本発明の他の実施例において、探索されたインタラクティブサービスに対する情報がトリガーであれば、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したアクセスされたインタラクティブサービスに対する情報がバイトであれば、方法は、受信された通知を用いてインタラクティブサービスが始まる準備ができているかを決定する段階、及び受信された通知を用いてバイトを送信するための接続に対する要求を送信する段階をさらに含む。本実施例は、上述した双方向通信サービスが提供される場合に対応できる。本実施例で、通知は、プライマリデバイスによって実行されるＤＯが通信する準備ができているかを示すためのものである。本実施例で、バイトを送信するための接続は、ＴＣＰ／ＩＰ接続であってもよい。また、本実施例は、プライマリデバイスへのＴＣＰ／ＩＰ接続を要求する動作に対応できる。
本発明の他の実施例において、方法は、メッセージを受信する前に実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を送信する段階をさらに含む。第２スクリーンデバイスは、要求をプライマリデバイスに伝送することができる。要求は、セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスは、メッセージを第２スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図１１８は、プライマリデバイスとしてデジタルサービス信号を処理する装置の実施例を示す図である。
プライマリデバイスとしてデジタルサービス信号を処理する装置の実施例は、実行モジュール１１８０１０、送信モジュール１１８０２０、受信モジュール１１８０３０、及び／又は提供モジュール１１８０４０を備えることができる。
実行モジュール１１８０１０は、デジタルサービス信号に対するプライマリアプリケーションを実行するように構成することができる。ここで、プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされていないアプリケーションであってもよい。ここで、プライマリデバイスは、上述したＴＶ受信機であってもよい。ここで、プライマリアプリケーションは、ＴＶ受信機によって実行されうるＤＯを意味することができる。ここで、プライマリアプリケーションは、ＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯであってもよい。
送信モジュール１１８０２０は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージを送信するように構成することができる。また、送信モジュール１１８０２０は、インタラクティブサービスを識別する記述を送信するように構成することができる。ここで、インタラクティブサービスは、トリガーされたアプリケーションに関連した第１モード又はトリガーされていないアプリケーションに関連した第２モードを含むことができる。ここで、記述は、要求によって送信することができる。上述したメッセージは、第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）に送信することができる。ここで、セカンダリアプリケーションは、上述したプライマリアプリケーションに関連したアプリケーション及び第２スクリーンデバイスによって実行されたアプリケーションであってもよい。アプリケーションは、ＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯであってもよい。ここで、トリガーされたアプリケーションはＴＤＯを意味し、トリガーされていないアプリケーションはＮＤＯを意味することができる。
受信モジュール１１８０３０は、インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及びインタラクティブサービスのそれぞれのタイプを識別するサービスタイプ情報を有する記述に対する要求を受信するように構成することができる。ここで、記述は、記述に記述されたインタラクティブサービスのそれぞれのサービスタイプ情報及びサービスｉｄ情報を含むことができる。
ここで、送信モジュール１１８０２０及び受信モジュール１１８０３０は、設計者の意図によって一つのモジュールに具備することができる。
提供モジュール１１８０４０は、インタラクティブサービスに対する情報を送信することによってインタラクティブサービスを提供するように構成することができる。提供モジュール１１８０４０は、インタラクティブサービスを第２スクリーンデバイス（又は、第２スクリーンデバイスによって実行されるアプリケーション）に提供することができる。
本発明の実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がＵＲＬ情報であれば、プライマリデバイスはＡｐｐＵＲＬサービスを提供することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報はトリガーであってもよい。また、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がトリガーであれば、装置は、増加モジュールをさらに備えることができる。増加モジュールは、ＴＰＴ内の情報と結合することによってトリガーを増加させるように構成することができる。ＴＰＴは、トリガーされたアプリケーションに対するメタデータを含むことができる。上述した送信モジュールはさらに、トリガー内の識別されたイベントを示すイベント指示子を有する増加したトリガーを送信することができる。ここで、“インタラクティブサービスに対する情報がトリガーであれば”は、プライマリデバイスがトリガーサービスを提供する場合を意味することができる。本実施例は、上述の増加したトリガーが生成及び送信される場合に対応できる。増加モジュールは、ＴＰＴ内に含まれる情報及びトリガーを結合することができる。ここで、イベント指示子は、上述したＡｕｇｍｅｎｔｅｄＴｒｉｇｇｅｒ内のイベントエレメントを意味することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がバイトであってもよい。また、インタラクティブサービスは、アプリケーションが実行されてセカンダリアプリケーションとの通信に参加する準備ができているかを示すｓｔａｔｕｓ状態変数を含むことができる。また、装置は、ｓｔａｔｕｓ状態変数を設定する段階をさらに含むことができる。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、ｓｔａｔｕｓ状態変数は、上述した双方向通信サービスの第２アプローチにおけるＳｔａｔｕｓ状態変数を意味することができる。ここで、“ｓｔａｔｕｓ状態変数を設定する段階”は、上述したｓｅｔＳｔａｔｕｓＹｅｓ（）、ｓｅｔＳｔａｔｕｓＮｏ（）ｏｒ ｓｅｔＳｔａｔｕｓ（）ＡＰＩを用いる場合を意味することができる。
本発明の他の実施例において、プライマリアプリケーションは、ＡＰＩを用いてインタラクティブサービスを提供する。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、ＡＰＩは、上述した双方向通信サービスのＡＰＩのうちのｓｅｎｄＢｙｔｅｓ ＡＰＩを意味することができる。
本発明の他の実施例において、ＡＰＩは、バイト及びバイト引数に対するアドレス及びポートに関する情報を有するアドレス引数を含むことができる。ここで、アドレス引数は、ｓｅｎｄＢｙｔｅｓ ＡＰＩのアドレス引数を意味することができる。ここで、バイト引数は、ｓｅｎｄＢｙｔｅｓ ＡＰＩのバイト引数を意味することができる。本発明の他の実施例において、受信モジュールはさらに、送信モジュールがメッセージを送信する前にプライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信するように構成することができる。第２スクリーンデバイスは要求をプライマリデバイスに伝送することができる。要求は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスはメッセージを第２スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図１１９は、セカンダリアプリケーションとしてデジタルサービス信号を処理する装置の実施例を示す図である。
セカンダリアプリケーションとしてデジタルサービス信号を処理する装置の実施例は、実行モジュール１１９０１０、受信モジュール１１９０２０、伝送モジュール１１９０３０、アクセスモジュール１１９０４０、及び／又はダウンロードモジュール１１９０５０を備えることができる。
実行モジュール１１９０１０は、デジタルサービス信号に対するアプリケーションを実行するように構成することができる。ここで、アプリケーションは、第２スクリーンデバイスによって実行されうるＤＯ、ＴＤＯ、ＮＤＯ、又はＵＤＯを意味することができる。
受信モジュール１１９０２０は、実行されたアプリケーション及び記述に対するインタラクティブサービスのメッセージを受信するように構成することができる。ここで、メッセージはプライマリデバイスから送信されてもよい。ここで、記述はプライマリデバイスによって要求されてもよい。ここで、記述はインタラクティブサービスを識別することができる。
伝送モジュール１１９０３０は、インタラクティブサービスを識別する記述に対する要求を伝送するように構成することができる。ここで、記述は、インタラクティブサービスのそれぞれを識別するサービスｉｄ情報及びインタラクティブサービスのそれぞれに対するタイプを示すサービスタイプ情報を有することができる。
アクセスモジュール１１９０４０は、記述を用いて少なくとも一つのインタラクティブサービスをアクセスするように構成することができる。アクセスモジュール１１９０４０はまた、少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入することができ、これは、“イベンティング”プロトコルに加入する上述した動作に対応する。アクセスモジュール１１９０４０はまた、通知を受信することができる。通知は、上述した非同期通知であってもよい。アクセスモジュール１１９０４０はまた、受信された通知を用いて少なくとも一つのインタラクティブサービスに対する情報を受信することができる。
ダウンロードモジュール１１９０５０は、アクセスされたインタラクティブサービスに対するファイルをダウンロードするように構成することができる。ここで、ファイルは、上述したアプリケーションであってもよい。
本発明の一実施例で、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びＵＲＬ情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がＵＲＬ情報であれば、プライマリデバイスはＡｐｐＵＲＬサービスを提供することができる。
本発明の他の実施例において、探索されたインタラクティブサービスに対する情報がトリガーであれば、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したアクセスされたインタラクティブサービスに対する情報がバイトであれば、アクセスモジュール１１９０４０はまた、受信された通知を用いてインタラクティブサービスが始まる準備ができているかを決定することができる。また、アクセスモジュール１１９０４０は受信された通知を用いてバイトを送信するための接続に対する要求を送信することができる。本実施例は、上述した双方向通信サービスが提供される場合に対応できる。本実施例で、通知は、プライマリデバイスによって実行されるＤＯが通信する準備ができているかを示すためのものであってもよい。本実施例において、バイトを送信するための接続は、ＴＣＰ／ＩＰ接続であってもよい。また、本実施例は、プライマリデバイスへのＴＣＰ／ＩＰ接続を要求する動作に対応できる。
本発明の他の実施例において、伝送モジュールはまた、受信モジュールがメッセージを受信する前に実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を伝送するように構成することができる。第２スクリーンデバイス（又は、伝送モジュール）は要求をプライマリデバイスに伝送することができる。要求は、セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものであってもよい。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスが上述したディスカバリメッセージを受信すると、プライマリデバイスはメッセージを第２スクリーンデバイスに送信することができる。本実施例はデバイスディスカバリ又はサービスディスカバリに対応できる。
ＵＰｎＰフレームワークは、電子装置をホームネットワークに接続し、電子装置によって機能を提供することによって提供することができる。本発明は、既存のＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービス及びＵＰｎＰ ＲｅｍｏｔｅＵＩサーバークライアントの拡張に関するものである。したがって、既存のＵＰｎＰ装置と互換可能であるとともに、第２スクリーンサービスを受信することができる。
添付の図面を参照して本発明を明瞭に説明してきたが、添付の図面に示す実施例を組み合わせて新しい実施例を設計することもできる。上述した実施例を実行するプログラムが記録されたコンピュータ読み取り可能な記録媒体が当業者の必要によって設計されると、これは添付した特許請求の範囲及びその同等物に属することができる。
本発明の装置及び方法は、上述した実施例の構成及び方法に制限されるものではない。また、上述した実施例は、一部又は全部が選択的に結合されて様々な変更が可能な方式で構成されてもよい。
また、本発明に係る方法は、ネットワークデバイスに提供されるプロセッサ読み取り可能記録媒体においてプロセッサ読み取り可能コードとして具現することもできる。プロセッサ読み取り可能媒体は、プロセッサによって読み取り可能なデータを記憶できるあらゆる種類の記録装置を含む。プロセッサ読み取り可能記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送どのようなキャリアウェーブの形態として具現されてもよい。また、プロセッサ読み取り可能記録媒体は、ネットワークを通じて接続されたコンピュータシステムに分散され、分散方式でプロセッサ読み取り可能コードが記憶されて実行されてもよい。
当業者にとって本発明の思想又は範囲から逸脱することなく本発明の様々な変形及び変更が可能であるということは明らかである。したがって、本発明は、添付した特許請求の範囲及びその同等物の範囲内で提供される本発明の変形及び変更をカバーする。
そして、当該明細書では物の発明と方法の発明の両方とも説明されており、必要によって両発明の説明は相互補充的に適用されてもよい。
〔実施例〕
発明の実施例は、前述した通り、発明を実施するための形態で詳述された。
本発明は、放送サービス提供に関連した一連の産業分野で利用可能である。
本発明の思想及び範囲から逸脱することなく、本発明の様々な変形及び変更が可能であるということが当業者にとっては明らかである。したがって、本発明は、添付の特許請求の範囲及び同等物の範囲内で提供される本発明の変形及び変更も含む。

Claims (4)

  1. プライマリデバイスで放送信号を処理する方法であって、
    前記プライマリデバイスが提供するＵＰｎＰサービスを広告するディスカバリメッセージをマルチキャストするステップであって、前記ＵＰｎＰサービスはトリガサービスと双方向通信サービスを含む、ステップと、
    コンパニオンデバイスでのセコンダリアプリケーションから前記ＵＰｎＰサービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を受信するステップと、
    前記ＵＰｎＰサービスを記述するために前記セコンダリアプリケーションのために利用される前記記述を前記セコンダリアプリケーションに送信するステップと、
    放送ストリーム又はインターネットサーバーから活性化トリガを受信するステップであって、前記活性化トリガは、第１のタームと第２のタームを含む、ステップと、
    前記第１のタームは、アプリケーションテーブルの中のアプリケーションＩＤ、イベントＩＤ及びデータＩＤを参照して、前記アプリケーションテーブルからターゲットイベントに関連するターゲット情報を示し、
    前記第２のタームは、前記ターゲットイベントのための活性化時間を示し、
    前記アプリケーションテーブルは、アプリケーションエレメントを含み、前記アプリケーションエレメントのそれぞれは、アプリケーションＩＤ及びアプリケーションのメタデータを含み、
    前記アプリケーションテーブルは、イベントエレメントを含み、前記イベントエレメントのそれぞれは、イベントＩＤとイベントのメタデータを含み、
    前記アプリケーションテーブルは、データエレメントを含み、前記データエレメントのそれぞれは、データＩＤとイベントに利用されるデータセットを含み、
    前記活性化トリガ及び前記アプリケーションテーブルを利用して増加したトリガを生成するステップであって、前記増加したトリガは、前記第１のタームにより前記アプリケーションテーブルに基づいて示される前記ターゲットイベントに関連したターゲット情報を含む、ステップと、
    前記ターゲット情報は、前記第１のタームに参照されるアプリケーションエレメントのアプリケーションＩＤに基づく、前記ターゲットイベントによりターゲットとされるアプリケーションのメタデータをさらに含み、
    前記ターゲット情報は、前記第１のタームに参照されるイベントエレメントのイベントＩＤに基づく、前記ターゲットイベントのメタデータを更に含み、
    前記ターゲット情報は、前記ターゲットイベントにより利用され、前記第１のタームに参照されるデータエレメントのデータＩＤに基づく、データセットを更に含み、
    前記トリガサービスを利用して前記セコンダリアプリケーションに前記増加したトリガを伝達するステップであって、前記増加したトリガは前記活性化トリガの前記第２のタームにより示された前記活性化時間で伝達される、ステップと、を含む、方法。
  2. 前記双方向通信サービスを利用して前記セコンダリアプリケーションに状態情報を伝達するステップであって、前記状態情報は前記セコンダリアプリケーションとの通信に参加するように用意された前記プライマリデバイスで実行するプライマリアプリケーションがあるか否かを示す、ステップと、
    前記セコンダリアプリケーションから前記通信のための要求を受信するステップと、
    前記プライマリアプリケーションと前記セコンダリアプリケーションの間に伝達されるデータを介する通信を確立するステップとをさらに含む、請求項１に記載の方法。
  3. プライマリデバイスとして放送サービスを処理する装置であって、
    前記プライマリデバイスが提供するＵＰｎＰサービスを広告するディスカバリメッセージをマルチキャストするように構成されたネットワークインターフェースであって、前記ＵＰｎＰサービスはトリガサービスと双方向通信サービスを含む、ネットワークインターフェースと、
    前記ネットワークインターフェースは、コンパニオンデバイスにおいてセコンダリアプリケーションから前記ＵＰｎＰサービスの記述のための要求を受信するようにさらに構成され、
    前記ネットワークインターフェースは、前記ＵＰｎＰサービスを記述するために前記セコンダリアプリケーションで利用される記述を、前記セコンダリアプリケーションに送るようにさらに構成され、
    放送ストリーム又はインターネットサーバーから活性化トリガを受信するように構成されたチューナであって、前記活性化トリガは、第１のタームと第２のタームを含む、チューナと、
    前記第１のタームは、アプリケーションテーブルの中のアプリケーションＩＤ、イベントＩＤ及びデータＩＤを参照して前記アプリケーションテーブルからターゲットイベントに関連するターゲット情報を示し、
    前記第２のタームは、前記ターゲットイベントのための活性化時間を示し、
    前記アプリケーションテーブルは、アプリケーションエレメントを含み、前記アプリケーションエレメントのそれぞれは、アプリケーションＩＤとアプリケーションのメタデータを含み、
    前記アプリケーションテーブルは、イベントエレメントを含み、前記イベントエレメントのそれぞれは、イベントＩＤとイベントのメタデータを含み、
    前記アプリケーションテーブルは、データエレメントを含み、前記データエレメントのそれぞれは、データＩＤとイベントに利用されるデータセットを含み、
    前記活性化トリガ及び前記アプリケーションテーブルを利用して増加したトリガを生成するように構成されたトリガモジュールであって、前記増加したトリガは、前記第１のタームにより前記アプリケーションテーブルに基づいて示される前記ターゲットイベントに関連したターゲット情報を含む、トリガモジュールとを含み、
    前記ターゲット情報は、前記第１のタームに参照されるアプリケーションエレメントのアプリケーションＩＤに基づく、前記ターゲットイベントのターゲットとされる前記アプリケーションのメタデータをさらに含み、
    前記ターゲット情報は、前記第１のタームに参照されるイベントエレメントのイベントＩＤに基づく、前記ターゲットイベントのメタデータをさらに含み、
    前記ターゲット情報は、前記ターゲットイベントに利用され、前記第１のタームに参照されるデータエレメントのデータＩＤに基づく、データセットを更に含み、
    前記ネットワークインターフェースは、前記トリガサービスを利用して前記増加したトリガを前記セコンダリアプリケーションに伝送するようにさらに構成され、前記増加したトリガは前記活性化トリガの前記第２のタームに示された前記活性化時間で伝送される、装置。
  4. 前記ネットワークインターフェースは、前記双方向通信サービスを利用して前記セコンダリアプリケーションに状態情報を配信するようにさらに構成され、前記状態情報は前記セコンダリアプリケーションとの通信に参加するように用意された前記プライマリデバイスで実行するプライマリアプリケーションがあるか否かを示し、
    前記ネットワークインターフェースは、前記セコンダリアプリケーションから前記通信のための要求を受信し、前記プライマリアプリケーションと前記セコンダリアプリケーションの間に配信されるデータを介する通信を確立するように構成された、請求項３に記載の装置。
JP2015543996A 2012-11-28 2013-11-26 双方向サービスを処理する装置及び方法 Expired - Fee Related JP6247309B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261730937P 2012-11-28 2012-11-28
US61/730,937 2012-11-28
US201261736529P 2012-12-12 2012-12-12
US61/736,529 2012-12-12
PCT/KR2013/010788 WO2014084570A1 (en) 2012-11-28 2013-11-26 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
JP2016506114A JP2016506114A (ja) 2016-02-25
JP6247309B2 true JP6247309B2 (ja) 2017-12-13

Family

ID=50774515

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015543996A Expired - Fee Related JP6247309B2 (ja) 2012-11-28 2013-11-26 双方向サービスを処理する装置及び方法

Country Status (8)

Country Link
US (1) US9516384B2 (ja)
EP (1) EP2926568A4 (ja)
JP (1) JP6247309B2 (ja)
KR (1) KR102040623B1 (ja)
CN (1) CN104871552B (ja)
CA (1) CA2889868C (ja)
MX (1) MX345034B (ja)
WO (1) WO2014084570A1 (ja)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8042132B2 (en) 2002-03-15 2011-10-18 Tvworks, Llc System and method for construction, delivery and display of iTV content
US11388451B2 (en) 2001-11-27 2022-07-12 Comcast Cable Communications Management, Llc Method and system for enabling data-rich interactive television using broadcast database
US8413205B2 (en) 2001-09-19 2013-04-02 Tvworks, Llc System and method for construction, delivery and display of iTV content
WO2003026275A2 (en) 2001-09-19 2003-03-27 Meta Tv, Inc. Interactive user interface for television applications
US7703116B1 (en) 2003-07-11 2010-04-20 Tvworks, Llc System and method for construction, delivery and display of iTV applications that blend programming information of on-demand and broadcast service offerings
US8352983B1 (en) 2002-07-11 2013-01-08 Tvworks, Llc Programming contextual interactive user interface for television
US11070890B2 (en) 2002-08-06 2021-07-20 Comcast Cable Communications Management, Llc User customization of user interfaces for interactive television
US8220018B2 (en) 2002-09-19 2012-07-10 Tvworks, Llc System and method for preferred placement programming of iTV content
US11381875B2 (en) 2003-03-14 2022-07-05 Comcast Cable Communications Management, Llc Causing display of user-selectable content types
US10664138B2 (en) * 2003-03-14 2020-05-26 Comcast Cable Communications, Llc Providing supplemental content for a second screen experience
US8578411B1 (en) 2003-03-14 2013-11-05 Tvworks, Llc System and method for controlling iTV application behaviors through the use of application profile filters
US8819734B2 (en) 2003-09-16 2014-08-26 Tvworks, Llc Contextual navigational control for digital television
US7818667B2 (en) 2005-05-03 2010-10-19 Tv Works Llc Verification of semantic constraints in multimedia data and in its announcement, signaling and interchange
US11832024B2 (en) 2008-11-20 2023-11-28 Comcast Cable Communications, Llc Method and apparatus for delivering video and video-related content at sub-asset level
US8832723B2 (en) 2012-02-07 2014-09-09 Turner Broadcasting System, Inc. Method and system for a synchronous event manager for automatic content recognition
US11115722B2 (en) 2012-11-08 2021-09-07 Comcast Cable Communications, Llc Crowdsourcing supplemental content
US9288509B2 (en) * 2012-12-28 2016-03-15 Turner Broadcasting System, Inc. Method and system for providing synchronized advertisements and services
US9253262B2 (en) * 2013-01-24 2016-02-02 Rovi Guides, Inc. Systems and methods for connecting media devices through web sockets
US9553927B2 (en) 2013-03-13 2017-01-24 Comcast Cable Communications, Llc Synchronizing multiple transmissions of content
US10880609B2 (en) 2013-03-14 2020-12-29 Comcast Cable Communications, Llc Content event messaging
JP6168839B2 (ja) * 2013-05-15 2017-07-26 キヤノン株式会社 情報処理装置、その制御方法、プログラム
JP2015012561A (ja) * 2013-07-02 2015-01-19 ソニー株式会社 表示装置、情報取得方法及び情報提供方法
CN105579995B (zh) * 2013-09-23 2022-07-08 三星电子株式会社 在无线通信系统中执行应用的方法和装置
EP2854317A1 (en) * 2013-09-26 2015-04-01 Alcatel Lucent Method for providing a client device with a media asset
EP3131304A4 (en) * 2014-04-11 2018-01-24 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
EP3163892A4 (en) 2014-06-30 2017-11-08 LG Electronics Inc. Broadcast receiving device, method of operating broadcast receiving device, linking device for linking to broadcast receiving device, and method of operating linking device
CN106537928A (zh) * 2014-06-30 2017-03-22 Lg 电子株式会社 广播发送装置、广播接收装置、用于广播发送装置的操作方法以及用于广播接收装置的操作方法
KR102440142B1 (ko) 2014-09-05 2022-09-05 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
WO2016035348A1 (en) * 2014-09-05 2016-03-10 Sharp Kabushiki Kaisha Syntax and semantics for device capabilities
US9979993B2 (en) * 2014-09-15 2018-05-22 Verizon Patent And Licensing Inc. Network for personalized content aggregation platform
US11783382B2 (en) 2014-10-22 2023-10-10 Comcast Cable Communications, Llc Systems and methods for curating content metadata
EP3214844A4 (en) * 2014-10-28 2018-05-30 Sony Corporation Reception device, transmission device, and data processing method
CN105830459B (zh) 2014-11-20 2019-06-18 Lg电子株式会社 发送广播信号的设备、接收广播信号的设备、发送广播信号的方法和接收广播信号的方法
CN104599163A (zh) * 2015-02-23 2015-05-06 佛山市恒南微科技有限公司 一种可溯源的农产品配送券
WO2016178319A1 (en) * 2015-05-06 2016-11-10 Sharp Kabushiki Kaisha Carrying multiple event times within a trigger
KR20180001559A (ko) * 2015-05-26 2018-01-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10779057B2 (en) * 2015-06-08 2020-09-15 Qualcomm Incorporated Broadcast content redistribution and ad insertion
US10917186B2 (en) 2015-07-21 2021-02-09 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
US10681147B2 (en) * 2016-08-15 2020-06-09 Saturn Licensing Llc URLs for acquiring or transmitting data
US10893011B2 (en) * 2016-09-13 2021-01-12 Gluru Limited Semantic interface definition language for action discovery in cloud services and smart devices
TWI640195B (zh) 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US10701438B2 (en) 2016-12-31 2020-06-30 Turner Broadcasting System, Inc. Automatic content recognition and verification in a broadcast chain
CN108139952B (zh) * 2017-06-14 2022-08-05 北京小米移动软件有限公司 应用交互方法、交互方法及装置
WO2018227899A1 (zh) 2017-06-14 2018-12-20 北京小米移动软件有限公司 应用交互方法、交互方法及装置
EP3750350B1 (en) * 2018-02-06 2022-11-16 Telefonaktiebolaget LM Ericsson (publ) Unique service identifier for a message proxy in a service based architecture
CN108614978B (zh) * 2018-04-19 2022-04-15 中国平安人寿保险股份有限公司 压缩包的校验方法、装置、存储介质以及终端
US10740079B2 (en) * 2018-05-15 2020-08-11 Microsoft Technology Licensing, Llc Maintaining tight coupling between driver and application versions
CN111372135A (zh) * 2018-12-25 2020-07-03 中国移动通信集团浙江有限公司 一种机顶盒应用自动适配方法及系统
US11095927B2 (en) 2019-02-22 2021-08-17 The Nielsen Company (Us), Llc Dynamic watermarking of media based on transport-stream metadata, to facilitate action by downstream entity
WO2020231927A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
WO2020231813A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
TWI802797B (zh) 2019-05-10 2023-05-21 美商六科股份有限公司 用於檢測和回應於在先前檢測到的指紋匹配之後檢測到的指紋不匹配的方法、非暫時性電腦可讀儲存介質及計算系統
US11234050B2 (en) 2019-06-18 2022-01-25 Roku, Inc. Use of steganographically-encoded data as basis to control dynamic content modification as to at least one modifiable-content segment identified based on fingerprint analysis
US11704390B2 (en) * 2019-10-10 2023-07-18 Baidu Usa Llc Method and system for signing an artificial intelligence watermark using a query
US11405674B2 (en) 2019-11-12 2022-08-02 The Nielsen Company (Us), Llc Methods and apparatus to identify media for ahead of time watermark encoding
US11012757B1 (en) 2020-03-03 2021-05-18 The Nielsen Company (Us), Llc Timely addition of human-perceptible audio to mask an audio watermark
KR102504102B1 (ko) 2022-10-19 2023-02-28 주식회사 와이드테크 인터넷 텔레비전을 이용한 라이브 방송 송출 서비스 제공 방법을 제공하는 텔레비전
CN116302076B (zh) * 2023-05-18 2023-08-15 云账户技术(天津)有限公司 一种基于解析配置项表结构进行配置项配置的方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003096669A2 (en) * 2002-05-10 2003-11-20 Reisman Richard R Method and apparatus for browsing using multiple coordinated device
KR100717060B1 (ko) * 2005-12-05 2007-05-10 삼성전자주식회사 홈 네트워크를 통해 ｄｖｄ 컨텐츠를 이용하는 방법 및장치
CN101227418B (zh) * 2007-01-19 2012-04-04 华为技术有限公司 一种实现融合ip消息的方法、装置及系统
US8775647B2 (en) * 2007-12-10 2014-07-08 Deluxe Media Inc. Method and system for use in coordinating multimedia devices
US8521078B2 (en) * 2008-03-21 2013-08-27 Qualcomm Incorporated Common interface protocol for sending FR-RDS messages in wireless communication systems
GB2466289A (en) * 2008-12-18 2010-06-23 Veda Technology Ltd Executing a service application on a cluster by registering a class and storing subscription information of generated objects at an interconnect
US8621520B2 (en) * 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
EP2343881B1 (en) * 2010-01-07 2019-11-20 LG Electronics Inc. Method of processing application in digital broadcast receiver connected with interactive network, and digital broadcast receiver
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
US8516528B2 (en) * 2010-06-30 2013-08-20 Cable Television Laboratories, Inc. Synchronization of 2nd screen applications
EP2472855A1 (en) * 2010-12-29 2012-07-04 Advanced Digital Broadcast S.A. Television user interface
WO2012112011A2 (ko) * 2011-02-20 2012-08-23 엘지전자 주식회사 심리스 콘텐트 재생 방법 및 장치

Also Published As

Publication number Publication date
KR20150090049A (ko) 2015-08-05
CN104871552B (zh) 2018-05-01
CA2889868A1 (en) 2014-06-05
CN104871552A (zh) 2015-08-26
EP2926568A1 (en) 2015-10-07
MX2015005930A (es) 2015-09-08
US20140150022A1 (en) 2014-05-29
EP2926568A4 (en) 2016-06-08
KR102040623B1 (ko) 2019-11-27
WO2014084570A1 (en) 2014-06-05
MX345034B (es) 2017-01-16
CA2889868C (en) 2018-01-02
US9516384B2 (en) 2016-12-06
JP2016506114A (ja) 2016-02-25

Similar Documents

Publication Publication Date Title
JP6247309B2 (ja) 双方向サービスを処理する装置及び方法
JP6133997B2 (ja) 両方向サービスを処理する装置及び方法
KR102024599B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR102068567B1 (ko) 양방향 서비스를 처리하는 장치 및 방법
KR101939296B1 (ko) 양방향 서비스를 처리하는 장치 및 방법

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160802

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161031

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170110

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170210

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170613

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170908

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20170925

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171116

R150 Certificate of patent or registration of utility model

Ref document number: 6247309

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees