(57)【要約】【課題】インタラクティブサービスを処理する方法及びその装置を提供する。【解決手段】第２スクリーンアプリケーションにディスカバリメッセージを送信する段階、第２スクリーン支援サービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を受信する段階、記述を有する応答を送信する段階、トリガーを受信する段階、及びトリガーサービスを用いてトリガーを第２デバイスに送信する段階を含む。【選択図】図９９
2016503599.tif 000002
【特許請求の範囲】
【請求項１】
第１デバイスでインタラクティブサービスを処理する方法であって、
ディスカバリメッセージを、第２デバイスで実行される第２スクリーンアプリケーションに送信する段階であって、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告する、段階と、
前記第２スクリーンアプリケーションから前記第２スクリーン支援サービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を受信する段階と、
前記第２スクリーンアプリケーションに前記記述を有する応答を送信する段階と、
放送ストリーム又はインターネットサーバーからトリガーを受信する段階と、
トリガーサービスを用いて前記トリガーを前記第２デバイスに伝達する段階と、
を含み、
前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、
前記トリガーサービスは、前記トリガーを伝達するためのものであり、
前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、
前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、
前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、
前記活性化トリガーは、前記イベントに対する活性化時間を設定し、
前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、
前記チャネル変更トリガーは、チャネルが変更される度に伝達される、方法。
【請求項２】
前記ディスカバリメッセージを送信する前に、前記第２スクリーン支援サービスを提供する第１デバイスを含む装置をサーチするサーチメッセージを受信する段階をさらに含む、請求項１に記載の方法。
【請求項３】
前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、
前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである、請求項１に記載の方法。
【請求項４】
前記第１デバイスは、前記トリガーが前記第１デバイスによって受信されるとすぐに前記全てのタイプの前記トリガーを伝達する、請求項３に記載の方法。
【請求項５】
前記トリガーを伝達する段階は、
前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合して増加した活性化トリガーを生成する段階と、
前記生成された増加した活性化トリガーを、前記第２スクリーンアプリケーションに送信する段階と、を含む、請求項１に記載の方法。
【請求項６】
前記トリガーサービスはフィルタリングされたストリームオプションを提供し、
前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーのうちの一つであるトリガーを伝達するオプションである、請求項５に記載の方法。
【請求項７】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、
前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、
前記アプリケーションエレメントは、前記活性化トリガーによって識別される、請求項６に記載の方法。
【請求項８】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、
前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、
前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を有するアクション情報を有し、
前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す、請求項７に記載の方法。
【請求項９】
前記第１デバイスは、前記増加した活性化トリガーの活性化時間に前記増加した活性化トリガーを伝達し、
前記第１デバイスは、前記相互作用トリガーが前記第１デバイスによって受信される時に前記相互作用トリガーを伝達し、
前記第１デバイスは、前記チャネルが変更される時に前記チャネル変更トリガーを伝達する、請求項６に記載の方法。
【請求項１０】
第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法であって、
第１デバイスからディスカバリメッセージを受信する段階であって、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告する、段階と、
前記第２スクリーン支援サービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を前記第１デバイスに送信する段階と、
前記第１デバイスから前記記述を有する応答を受信する段階と、
前記記述内に含まれる情報を用いてトリガーサービスをアクセスする段階と、
前記トリガーサービスを用いて前記第１デバイスからトリガーを受信する段階と、
を含み、
前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、
前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、
前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、
前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、
前記活性化トリガーは、前記イベントに対する活性化時間を設定し、
前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、
前記チャネル変更トリガーは、チャネルが変更される度に伝達される、方法。
【請求項１１】
前記ディスカバリメッセージを受信する前に、前記第２スクリーン支援サービスを提供する第１装置を含む装置をサーチするサーチメッセージをマルチキャストする段階をさらに含む、請求項１０に記載の方法。
【請求項１２】
前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、
前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである、請求項１０に記載の方法。
【請求項１３】
前記全てのタイプのトリガーは、可能な限り早く伝達される、請求項１２に記載の方法。
【請求項１４】
前記トリガーを受信する段階は、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合することによって生成された増加した活性化トリガーを受信する段階を含む、請求項１０に記載の方法。
【請求項１５】
前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、
前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーのうちの一つであるトリガーを伝達するオプションである、請求項１４に記載の方法。
【請求項１６】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、
前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、
前記アプリケーションエレメントは、前記活性化トリガーによって識別される、請求項１５に記載の方法。
【請求項１７】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、
前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、
前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を有するアクション情報を有し、
前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す、請求項１６に記載の方法。
【請求項１８】
前記増加した活性化トリガーは、前記増加した活性化トリガーの活性化時間に伝達され、
前記相互作用トリガーは、可能な限り早く伝達され、
前記チャネル変更トリガーは、前記チャネルが変更される時に伝達される、請求項１５に記載の方法。
【請求項１９】
第１デバイスとしてインタラクティブサービスを処理する装置であって、
放送ストリーム又はインターネットサーバーからトリガーを受信するように構成される第１モジュールと、
ディスカバリメッセージを、第２デバイスで実行される第２スクリーンアプリケーションに送信し、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告するものであり、
前記第２スクリーンアプリケーションから前記第２スクリーン支援サービスの記述に対する要求を受信し、
前記第２スクリーンアプリケーションに前記記述を有する応答を送信し、
トリガーサービスを用いて前記トリガーを前記第２デバイスに伝達するように構成された第２モジュールと、
を備え、
前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、
前記トリガーサービスは、前記トリガーを伝達するためのものであり、
前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、
前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、
前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、
前記活性化トリガーは、前記イベントに対する活性化時間を設定し、
前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、
前記チャネル変更トリガーは、チャネルが変更される度に伝達される、装置。
【請求項２０】
前記第２モジュールはさらに、前記ディスカバリメッセージを送信する前に、前記第２スクリーン支援サービスを提供する第１デバイスを含む装置をサーチするサーチメッセージを受信するように構成される、請求項１９に記載の装置。
【請求項２１】
前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、
前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである、請求項１９に記載の装置。
【請求項２２】
前記第２モジュールは、前記トリガーが前記第１モジュールによって受信されるとすぐに前記全てのタイプのトリガーを伝達する、請求項２１に記載の装置。
【請求項２３】
前記第２モジュールはさらに、
前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合して増加した活性化トリガーを生成し、
前記生成された増加した活性化トリガーを前記第２スクリーンアプリケーションに送信するように構成される、請求項１９に記載の装置。
【請求項２４】
前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、
前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーのうちの一つであるトリガーを伝達するオプションである、請求項２３に記載の装置。
【請求項２５】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、
前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、
前記アプリケーションエレメントは、前記活性化トリガーによって識別される、請求項２４に記載の装置。
【請求項２６】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、
前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、
前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を有するアクション情報を有し、
前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す、請求項２５に記載の装置。
【請求項２７】
前記第２モジュールは、前記増加した活性化トリガーの活性化時間に前記増加した活性化トリガーを伝達し、
前記第２モジュールは、前記相互作用トリガーが前記第１デバイスによって受信される時に前記相互作用トリガーを伝達し、
前記第２モジュールは、前記チャネルが変更される時に前記チャネル変更トリガーを伝達する、請求項２４に記載の装置。
【請求項２８】
第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置であって、
第１デバイスからディスカバリメッセージを受信し、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告するものであり、
前記第２スクリーン支援サービスの記述に対する要求を前記第１デバイスに送信し、
前記第１デバイスから前記記述を有する応答を受信するように構成される第１モジュールと、
前記記述内に含まれる情報を用いてトリガーサービスにアクセスし、
前記トリガーサービスを用いて前記第１デバイスからトリガーを受信するように構成される第２モジュールと、
を備え、
前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、
前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、
前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、
前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、
前記活性化トリガーは、前記イベントに対する活性化時間を設定し、
前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、
前記チャネル変更トリガーは、チャネルが変更される度に伝達される、装置。
【請求項２９】
前記第１モジュールはさらに、前記ディスカバリメッセージを受信する前に、前記第２スクリーン支援サービスを提供する第１装置を含む装置をサーチするサーチメッセージをマルチキャストするように構成される、請求項２８に記載の装置。
【請求項３０】
前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、
前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである、請求項２８に記載の装置。
【請求項３１】
前記全てのタイプのトリガーは、可能な限り早く伝達される、請求項３０に記載の装置。
【請求項３２】
前記第２モジュールはさらに、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合することによって生成された増加した活性化トリガーを受信するように構成される、請求項２８に記載の装置。
【請求項３３】
前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、
前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーのうちの一つであるトリガーを伝達するオプションである、請求項３２に記載の装置。
【請求項３４】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、
前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、
前記アプリケーションエレメントは、前記活性化トリガーによって識別される、請求項３３に記載の装置。
【請求項３５】
前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、
前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、
前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を有するアクション情報を有し、
前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す、請求項３４に記載の装置。
【請求項３６】
前記増加した活性化トリガーは、前記増加した活性化トリガーの活性化時間に伝達され、
前記相互作用トリガーは、可能な限り早く伝達され、
前記チャネル変更トリガーは、前記チャネルが変更される時に伝達される、請求項３３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送サービスを提供、受信及び処理する方法及び装置に関し、特に、放送コンテンツに関連する付加サービスを提供する方法及び装置に関する。
【背景技術】
【０００２】
ＴＶは、１９世紀末に初めて登場して以来、画面表示方法やデザインなどにおいて発展を遂げ続き、２０世紀後半からは最も大衆的な情報伝達機器として確立された。ただし、ＴＶは、放送局から提供する単方向の情報を視聴者たちが一方的に受容するという根本的な形態をしていた。このようなＴＶの限界は、１９９０年代からＰＣ（個人用コンピュータ）及びインターネットが大衆化するにつれてより明らかになり始めた。そこで、ＴＶは両方向サービスが可能な方向に進化を続けてきている。
【０００３】
しかしながら、現在、コンテンツプロバイダと視聴者との間には、上記のような両方向サービスを本格的に実行するシステムがない実情である。特に、上記のような両方向サービスの提供のために、放映中の放送コンテンツに関連するアプリケーションを特定時点に駆動し、情報の特定処理を通じて、視聴者に関連情報を提供する方法及びフォーマットに関する技術的支援が必要な状況である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が遂げようとする技術的課題は、前述した問題点を解決するためのもので、放送コンテンツが再生される期間中に、適切な時期に放送コンテンツに関連する付加情報を提供することにある。
【課題を解決するための手段】
【０００５】
本発明の目的は、本発明によって第１デバイスでインタラクティブサービスを処理する方法によって達成することができ、前記方法は、ディスカバリメッセージを第２デバイスで実行される第２スクリーンアプリケーションに送信するステップであって、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告する、ステップと、前記第２スクリーンアプリケーションから前記第２スクリーン支援サービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を受信するステップと、前記第２スクリーンアプリケーションに前記記述を有する応答を送信するステップと、放送ストリーム又はインターネットサーバーからトリガーを受信するステップと、トリガーサービスを用いて前記トリガーを前記第２デバイスに伝達するステップを含み、前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、前記トリガーサービスは、前記トリガーを伝達するためのものであり、前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、前記活性化トリガーは、前記イベントに対する活性化時間を設定し、前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、前記チャネル変更トリガーは、チャネルが変更される度に伝達される。
【０００６】
好適には、前記方法は、前記ディスカバリメッセージを送信する前に、前記第２スクリーン支援サービスを提供する第１デバイスを含む装置をサーチするサーチメッセージを受信するステップをさらに含む。
【０００７】
好適には、前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである。
【０００８】
好適には、前記第１デバイスは、前記トリガーが前記第１デバイスによって受信されるとすぐに前記全てのタイプの前記トリガーを伝達する。
【０００９】
好適には、前記トリガーを伝達するステップは、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合して増加した活性化トリガーを生成するステップと、前記生成された増加した活性化トリガーを前記第２スクリーンアプリケーションに送信するステップと、を含む。
【００１０】
好適には、前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーの中の一つであるトリガーを伝達するオプションである。
【００１１】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、前記アプリケーションエレメントは、前記活性化トリガーによって識別される。
【００１２】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を持つアクション情報を有し、前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す。
【００１３】
好適には、前記第１デバイスは前記増加した活性化トリガーの活性化時間に、前記増加した活性化トリガーを伝達し、前記第１デバイスは前記相互作用トリガーが前記第１デバイスによって受信される時に前記相互作用トリガーを伝達し、前記第１デバイスは前記チャネルが変更される時前記チャネル変更トリガーを伝達する。
【００１４】
本発明の他の形態によれば、第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法であって、第１デバイスからディスカバリメッセージを受信するステップであって、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告する、ステップと、、前記第２スクリーン支援サービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）に対する要求を前記第１デバイスに送信するステップと、前記第１デバイスから前記記述を有する応答を受信するステップと、前記記述内に含まれる情報を用いてトリガーサービスをアクセスするステップと、前記トリガーサービスを用いて前記第１デバイスからトリガーを受信するステップと、を含み、前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、前記活性化トリガーは、前記イベントに対する活性化時間を設定し、前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、前記チャネル変更トリガーは、チャネルが変更される度に伝達される方法が提供される。
【００１５】
好適には、前記方法は、前記ディスカバリメッセージを受信する前に、前記第２スクリーン支援サービスを提供する第１装置を含む装置をサーチするサーチメッセージをマルチキャストするステップをさらに含む。
【００１６】
好適には、前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである。
【００１７】
好適には、前記全てのタイプのトリガーは可能な限り早く伝達される。
【００１８】
好適には、前記トリガーを受信するステップは、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報を結合することによって生成された増加した活性化トリガーを受信するステップを含む。
【００１９】
好適には、前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーの中の一つであるトリガーを伝達するオプションである。
【００２０】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、前記アプリケーションエレメントは、前記活性化トリガーによって識別される。
【００２１】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を持つアクション情報を有し、前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す。
【００２２】
好適には、前記増加した活性化トリガーは、前記増加した活性化トリガーの活性化時間に伝達され、前記相互作用トリガーは、可能な限り早く伝達され、前記チャネル変更トリガーは、前記チャネルが変更される時に伝達される。
【００２３】
本発明の他の形態によれば、第１デバイスとしてインタラクティブサービスを処理する装置であって、放送ストリーム又はインターネットサーバーからトリガーを受信するように構成される第１モジュールと、ディスカバリメッセージを第２デバイスで実行される第２スクリーンアプリケーションに送信し、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告するものであり、前記第２スクリーンアプリケーションから前記第２スクリーン支援サービスの記述に対する要求を受信し、前記第２スクリーンアプリケーションに前記記述を有する応答を送信し、トリガーサービスを用いて前記トリガーを前記第２デバイスに伝達するように構成された第２モジュールを備え、前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、前記トリガーサービスは前記トリガーを伝達するためのものであり、前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、前記活性化トリガーは、前記イベントに対する活性化時間を設定し、前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、前記チャネル変更トリガーは、チャネルが変更される度に伝達される装置を提供する。
【００２４】
好適には、前記第２モジュールはさらに、前記ディスカバリメッセージを送信する前に、前記第２スクリーン支援サービスを提供する第１デバイスを含む装置をサーチするサーチメッセージを受信するように構成される。
【００２５】
好適には、前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである。
【００２６】
好適には、前記第２モジュールは、前記トリガーが前記第１モジュールによって受信されるとすぐに前記全てのタイプのトリガーを伝達する。
【００２７】
好適には、前記第２モジュールはさらに、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報と結合して増加した活性化トリガーを生成し、前記生成された増加した活性化トリガーを前記第２スクリーンアプリケーションに送信するように構成される。
【００２８】
好適には、前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーの中の一つであるトリガーを伝達するオプションである。
【００２９】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、前記アプリケーションエレメントは、前記活性化トリガーによって識別される。
【００３０】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を持つアクション情報を有し、前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す。
【００３１】
好適には、前記第２モジュールは、前記増加した活性化トリガーの活性化時間に、前記増加した活性化トリガーを伝達し、前記第２モジュールは、前記相互作用トリガーが前記第１デバイスによって受信される時に前記相互作用トリガーを伝達し、前記第２モジュールは、前記チャネルが変更される時に前記チャネル変更トリガーを伝達する。
【００３２】
本発明の他の形態によれば、第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置であって、第１デバイスからディスカバリメッセージを受信し、前記ディスカバリメッセージは、前記第１デバイスが提供可能な第２スクリーン支援サービスを広告するものであり、前記第２スクリーン支援サービスの記述に対する要求を前記第１デバイスに送信し、前記第１デバイスから前記記述を有する応答を受信するように構成される第１モジュールと、前記記述内に含まれる情報を用いてトリガーサービスにアクセスし、前記トリガーサービスを用いて前記第１デバイスからトリガーを受信するように構成される第２モジュールを備え、前記トリガーサービスは、前記第２スクリーン支援サービスのうちの一つであり、前記トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントのためのアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することであり、前記トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー又はチャネル変更トリガーのうちの一つであり、前記時間ベーストリガーは、前記イベントに対する時間ベースを確立するために用いられ、前記活性化トリガーは、前記イベントに対する活性化時間を設定し、前記相互作用トリガーは、トリガされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）相互作用モデル以外の相互作用モデルに用いられ、前記チャネル変更トリガーは、チャネルが変更される度に伝達される装置を提供する。
【００３３】
好適には、前記第１モジュールはさらに、前記ディスカバリメッセージを受信する前に、前記第２スクリーン支援サービスを提供する第１装置を含む装置をサーチするサーチメッセージをマルチキャストするように構成される。
【００３４】
好適には、前記トリガーサービスは、フィルタリングされていないストリームオプションを提供し、前記フィルタリングされていないストリームオプションは、全てのタイプのトリガーを伝達するオプションである。
【００３５】
好適には、前記全てのタイプのトリガーは、可能な限り早く伝達される。
【００３６】
好適には、前記第２モジュールはさらに、前記活性化トリガーからの情報を前記アプリケーションパラメータテーブルからの情報を結合することによって生成された増加した活性化トリガーを受信するように構成される。
【００３７】
好適には、前記トリガーサービスは、フィルタリングされたストリームオプションを提供し、前記フィルタリングされたストリームオプションは、前記増加した活性化トリガー、前記相互作用トリガー又は前記チャネル変更トリガーの中の一つであるトリガーを伝達するオプションである。
【００３８】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含み、前記ＵＲＬエレメントは、前記アプリケーションの一部であるファイルを識別し、前記アプリケーションエレメントは、前記活性化トリガーによって識別される。
【００３９】
好適には、前記増加した活性化トリガーは、前記アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、前記活性化トリガーによって識別されたイベントエレメントは、前記アプリケーションに対するイベントを示し、前記イベント情報は、前記活性化トリガーによって識別されたイベント情報のアクション属性と同じ値を持つアクション情報を有し、前記アクション属性は、前記アクションが活性化される時に適用されるアクションのタイプを示す。
【００４０】
好適には、前記増加した活性化トリガーは、前記増加した活性化トリガーの活性化時間に伝達され、前記相互作用トリガーは、可能な限り早く伝達され、前記チャネル変更トリガーは、前記チャネルが変更される時に伝達される。
【００４１】
本発明について前述した一般的な説明と後述する詳細な説明はいずれも例示的なものであり、請求項に記載の発明についての更なる説明のためのものである。
【発明の効果】
【００４２】
本発明によれば、既存の放送システムを用いて放送コンテンツと関連した付加情報を提供することができる。
【００４３】
本発明によれば、放送コンテンツと関連した付加情報が表示されなければならない時期を検出し、適切な時期に付加情報を使用者に提供することができる。
【００４４】
本発明によれば、第２スクリーンデバイスに、放送コンテンツと関連した付加情報を提供することができる。
【図面の簡単な説明】
【００４５】
【図１】一般的な放送ストリームの一実施例を示す図である。
【図２】予め生成された（Ｐｒｅ−ｐｒｏｄｕｃｅｄ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。
【図３】ライブ（Ｌｉｖｅ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。
【図４】トリガーシンタックスの一実施例を示す図である。
【図５】ＴＤＯパラメータテーブルの一実施例を示す図である。
【図６】ＴＤＯパラメータテーブルの一実施例を示す図である。
【図７】‘Ｆｒｅｑｕｅｎｃｙ ｏｆ Ｕｓｅ’属性値の意味の一実施例を示す図である。
【図８】‘ｄｅｓｔｉｎａｔｉｏｎ’属性値の意味の一実施例を示す図である。
【図９】ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
【図１０】ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
【図１１】ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
【図１２】ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
【図１３】ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。
【図１４】活性化メッセージテーブル構造の一実施例を示す図である。
【図１５】ＵＲＬリスト構造の一実施例を示す図である。
【図１６】ＴＰＴを含むプライベートセクション（ｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎ）の２進フォーマットの一実施例を示す図である。
【図１７】ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。
【図１８】ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
【図１９】ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
【図２０】ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。
【図２１】ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。
【図２２】ＷＭ技法のためのアーキテクチャの一実施例を示す図である。
【図２３】ＦＰ技法のアーキテクチャの一実施例を示す図である。
【図２４】要求／応答ＡＣＲの場合における静的活性化の一実施例を示す図である。
【図２５】要求／応答ＡＣＲの場合における静的活性化の一実施例を示す図である。
【図２６】要求／応答ＡＣＲの場合における動的活性化の一実施例を示す図である。
【図２７】要求／応答ＡＣＲの場合における動的活性化の一実施例を示す図である。
【図２８】ＡＣＲサーバー活性化のためのアーキテクチャの一実施例を示す図である。
【図２９】ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
【図３０】ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
【図３１】ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
【図３２】ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
【図３３】場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
【図３４】場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
【図３５】最後に伝達される動的活性化トリガーの一実施例を示す図である。
【図３６】最後に伝達される動的活性化トリガーの一実施例を示す図である。
【図３７】要求／応答の場合においてＡＣＲクライアントと他のサーバー間の順序図である。
【図３８】イベント主導型ＡＣＲの場合におけるＡＣＲクライアントと他のサーバー間の順序図である。
【図３９】ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスのアクションリストの一実施例である。
【図４０】ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例である。
【図４１】Ｔｒｉｇｇｅｒ ｉｎ ＤＴＶＣＣ Ｓｅｒｖｉｃｅ Ｎｕｍｂｅｒ６の一実施例である。
【図４２】第２スクリーンシナリオ用システムアーキテクチャの一実施例である。
【図４３】ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例である。
【図４４】ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例である。
【図４５】中央集中型実行モデル（Ｃｅｎｔｅｒａｌｉｚｅｄ  Ｅｘｅｃｕｔｉｏｎ  ｍｏｄｅｌ）の動作概念図の一実施例である。
【図４６】中央集中型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。
【図４７】分散型実行モデル（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｅｘｅｃｕｔｉｏｎ  ｍｏｄｅｌ）の動作概念図の一実施例である。
【図４８】分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。
【図４９】分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。
【図５０】第２スクリーンサービスアプリケーションのソフトウェア層の一実施例である。
【図５１】第２スクリーンサービスアプリケーションのソフトウェア層の一実施例である。
【図５２】第２スクリーンアプリケーションライフサイクル管理による送信順序と送信データの違いを示すテーブルの一実施例である。
【図５３】受信機が第２スクリーンデバイスにＵＩ情報を知らせる方法の一実施例である。
【図５４】受信機が第２スクリーンデバイスにＵＩ情報を知らせる方法の一実施例である。
【図５５】受信機が第２スクリーンデバイスにＴＤＯ及びイベント情報を知らせる方法の一実施例である。
【図５６】第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーション接近方法の一実施例である。
【図５７】第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーション接近方法の一実施例である。
【図５８】ＲｅｍｏｔｅＵＩサーバーサービスのための放送シグナリングの一実施例である。
【図５９】ＲｅｍｏｔｅＵＩサーバーサービスのための放送シグナリングの他の実施例である。
【図６０】第２スクリーンサービスのための装置ディスカバリ及び装置能力交換の一実施例である。
【図６１】ＵＰｎＰフォーラムのＤｅｖｉｃｅＰｒｏｆｉｌｅ ＸＭＬスキマーの一実施例である。
【図６２】第２スクリーンデバイスのデバイスプロファイルの一実施例である。
【図６３】第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの説明の一実施例である。
【図６４】第２スクリーンデバイスでＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｔｅＵＩＬｉｓｔｉｎｇが実行される間のＵＩＬｉｓｔｉｎｇの一実施例である。
【図６５】ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【図６６】ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【図６７】ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【図６８】ＰｒｏｃｅｓｓＩｎｐｕｔアクションで第２スクリーンデバイスに伝達になる“ＥｖｅｎｔＩｎｆｏ”情報の一実施例である。
【図６９】受信機及び第２スクリーンデバイス間の構成の一実施例である。
【図７０】サービスのサービスタイプ及びサービスＩＤの一実施例である。
【図７１】トリガー伝達サービスの動作概念図の一実施例である。
【図７２】拡張された活性化トリガー（ｅｘｐａｎｄｅｄ  ａｃｔｉｖａｔｉｏｎ  ｔｒｉｇｇｅｒ）生成過程の一実施例である。
【図７３】増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ  Ａｃｔｉｖａｔｉｏｎ  Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ  Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。
【図７４】増加していないトリガーに対するＸＭＬスキマー記述の一実施例である。
【図７５】増加した活性化トリガーのフォーマットの一実施例である。
【図７６】増加した活性化トリガーのフォーマットの一実施例である。
【図７７】増加した活性化トリガーのフォーマットの一実施例である。
【図７８】増加した活性化トリガーのフォーマットの一実施例である。
【図７９】トリガーサービス状態変数（Ｔｒｉｇｇｅｒ  Ｓｅｒｖｉｃｅ  Ｓｔａｔｅ  Ｖａｒｉａｂｌｅｓ）の一実施例である。
【図８０】トリガーサービス状態変数の一実施例である。
【図８１】トリガーサービスアクションの一実施例である。
【図８２】ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数（Ａｒｇｕｍｅｎｔ）の一実施例である。
【図８３】ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の一実施例である。
【図８４】トリガーサービスアクションの一実施例である。
【図８５】トリガー伝達サービスを用いてトリガー獲得時に第２スクリーン上における動作の一実施例である。
【図８６】トリガー伝達サービスの動作概念図の一実施例である。
【図８７】ＡｐｐＵＲＬサービス状態変数の一実施例である。
【図８８】ＡｐｐＵＲＬサービスアクションの一実施例である。
【図８９】ＧｅｔＡｐｐＵＲＬアクションの引数の一実施例である。
【図９０】プロキシＨＴＴＰサーバーサービス（Ｐｒｏｘｙ  ＨＴＴＰ  Ｓｅｒｖｅｒ  ｓｅｒｖｉｃｅ）の動作概念図の一実施例である。
【図９１】プロキシサーバーサービス状態変数（Ｐｒｏｘｙ  Ｓｅｒｖｅｒ  Ｓｅｒｖｉｃｅ  Ｓｔａｔｅ  Ｖａｒｉａｂｌｅ）の一実施例である。
【図９２】プロキシサーバーサービスアクション（Ｐｒｏｘｙ  Ｓｅｒｖｅｒ  Ｓｅｒｖｉｃｅ  Ａｃｔｉｏｎ）の一実施例である。
【図９３】ＧｅｔＰｒｏｘｙＵＲＬアクションの引数の一実施例である。
【図９４】ＲｅｑｕｅｓｔＦｉｌｅｓ（）の一実施例である。
【図９５】第２スクリーンデバイスアーキテクチャの一実施例である。
【図９６】受信機の簡略化された構造図の一実施例である。
【図９７】第２スクリーンデバイスの構造図の一実施例である。
【図９８】第２スクリーンデバイスシナリオの一実施例である。
【図９９】第１デバイスでインタラクティブサービスを処理する方法の一実施例である。
【図１００】第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法の一実施例である。
【図１０１】第１デバイスとしてインタラクティブサービスを処理する装置の一実施例である。
【図１０２】第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置の一実施例である。
【発明を実施するための形態】
【００４６】
発明のより容易な理解を助け、発明の実施例を示す添付の図面が、下記の記載と共に本発明の原理を説明するために提供される。
【００４７】
添付の図面は上記の通りである。
本明細書で使われる用語としては、本発明においての機能を考慮したうえ、できるだけ現在広く使われている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分においてその意味を記載するものとする。したがって、本明細書で使われる用語は、単純な用語の名称ではなく、その用語が持つ実質的な意味と本明細書の全般にわたる内容に基づいて解釈されなければならいということは明らかである。
【００４８】
本明細書において、メディア時間は、オーディオ／ビデオ又はオーディオコンテンツアイテムの再生（ｐｌａｙｏｕｔ）においていずれかの地点を参照するパラメータを表す。ＡＣＲは、自動コンテンツ認識（Ａｕｔｏｍａｔｉｃ  Ｃｏｎｔｅｎｔ  Ｒｅｃｏｇｎｉｔｉｏｎ）を表す。ＡＭＴは、活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ  Ｍｅｓｓａｇｅｓ  Ｔａｂｌｅ）を表す。ＡＰＩは、アプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を表す。ＤＡＥは、宣言的応用環境（Ｄｅｃｌａｒａｔｉｖｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）を表す。ＤＯは、宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）を表す。ＦＬＵＴＥは、単方向送信を通したファイル伝達（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を表す。ＧＰＳは、位置確認システム（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）を表す。ＨＴＴＰは、ハイパーテキスト送信プロトコル（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を表す。ＩＰは、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を表す。ＩＰＴＶは、インターネットプロトコルテレビ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｔｅｌｅｖｉｓｉｏｎ）を表す。ｉＴＶは、両方向テレビ（Ｉｎｔｅｒａｃｔｉｖｅ  Ｔｅｌｅｖｉｓｉｏｎ）を表す。ＭＩＭＥは、インターネットメディアタイプ（Ｉｎｔｅｒｎｅｔ  Ｍｅｄｉａ  Ｔｙｐｅ）を表す。ＮＤＯは、ＮＲＴ宣言的客体（ＮＲＴ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）を表す。ＮＲＴは、非実時間（Ｎｏｎ−Ｒｅａｌ  Ｔｉｍｅ）を表す。ＳＭＴは、サービスマップテーブル（Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ）を表す。ＳＳＣは、サービスシグナリングチャネル（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ）を表す。ＴＤＯは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）を表す。ＴＰＴは、ＴＤＯパラメータテーブル（ＴＤＯ  Ｐａｒａｍｅｔｅｒｓ  Ｔａｂｌｅ）を表す。ＵＤＯは、非結合宣言的客体（Ｕｎｂｏｕｎｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）を表す。ＵＰｎＰは、ユーザープラグアンドプレイ（Ｕｓｅｒ  Ｐｌｕｇａｎｄ  Ｐｌａｙ）を表す。ＵＲＩは、統合リソース識別子（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を表す。ＵＲＬは、リソース位置表示子（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を表す。ＸＭＬは、拡張性生成言語（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を表す。ＴＦＴは、テキストフラグメントテーブル（Ｔｅｘｔ  Ｆｒａｇｍｅｎｔ  Ｔａｂｌｅ）を表す。詳細な内容は後述する。
【００４９】
この明細書で、ＤＯ、ＴＤＯ、ＮＤＯ、ＵＤＯは次のような意味を有することができる。
【００５０】
ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）は、両方向アプリケーション（例えば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、ＣＳＳ、ＸＭＬ及びマルチメディアファイル）を構成するコレクション（ｃｏｌｌｅｃｔｉｏｎ）であってもよい。
【００５１】
トリガーされた両方向付加データサービスによって開始された宣言的客体又はトリガーによって開始されたＤＯによって実行されたＤＯなどを指定するために“トリガーされた宣言的客体（ＴＤＯ）”を使用する。
【００５２】
トリガーされた両方向データサービスではなくＮＲＴサービスの一部として実行された宣言的客体を表すために、“ＮＲＴ宣言的客体”（ＮＤＯ）という用語を使用する。
【００５３】
パッケージ型アップ（Ｐａｃｋａｇｅｄ  Ａｐｐ）のようにサービスに結合されない宣言的客体、リンクによって実行されたＤＯ、又はそのようなＤＯによって実行されたＤＯなどを表すために“非結合宣言的客体（ＵＤＯ）”という用語を使用する。
【００５４】
“リンク”は、現在のＴＶプログラム又はＮＲＴサービスに関連するオンライン情報又は機能を提供するウェブサイトを示す放送局提供ＵＲＬである。
【００５５】
“パッケージ型アップ”は、放送局が視聴者に提供しようとする情報又は機能を提供し、視聴者がダウンロードして設置できる一つのファイルとしてまとめられた放送局提供宣言的客体（ＤＯ）である。
【００５６】
その詳細は後述する。
【００５７】
この明細書で、時間ベースメッセージ（ｔｉｍｅ  ｂａｓｅ  ｍｅｓｓａｇｅ）は、時間ベーストリガー及びその等価物を含む。したがって、“時間ベースメッセージ”と“時間ベーストリガー”と同じ意味で使われてもよい。
【００５８】
この明細書で、活性化メッセージは、活性化トリガー及び／又はＡＭＴ内の活性化エレメントのような、活性化を引き起こす全ての情報伝達を含む。
【００５９】
図１は、一般的な放送ストリームの一実施例を示す図である。
【００６０】
一般的な放送ストリームはＴＶプログラムのシーケンスで構成されている。各ＴＶプログラムは、基本となるショー（ｓｈｏｗ）で構成され、ショーは一般的に広告及び／又は他の介在物（ｉｎｔｅｒｓｔｉｔｉａｌ  ｍａｔｅｒｉａｌ）によって分離されたブロックに分けられる。
【００６１】
同図では、放送ストリームに、ショーＡ（Ｓｈｏｗ  Ａ）セグメント、広告１（Ａｄ１）、広告２（Ａｄ２）、ショーＢ（Ｓｈｏｗ  Ｂ）セグメントなどが順次に含まれている。各ショーをなすセグメントをショー材料、広告を介在物と呼ぶことができる。
【００６２】
各ショー又は介在物は、それと関連している両方向付加データサービスを有しても有さなくてもよい。
【００６３】
本明細書では、統合ユニットとして放送局によって扱われる両方向付加サービスの一部を表すために“両方向サービスセグメント”、又は単純に“セグメント”という用語を使用する。両方向サービスセグメントは一般的に単一ショー又は１個の介在物と関連するが、必ずしもそうでない。
【００６４】
このような両方向付加データサービスを実行するための２つのモデルがあり得る。直接実行モデルとトリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ  Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ、ＴＤＯ）モデルがそれである。
【００６５】
直接実行モデルでは、仮想チャネルが選択されると直ちに宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ、ＤＯ）は自動で開始され得る。宣言的客体は、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのように、オーディオ−ビデオプログラムと同期化される両方向特徴の提供のための具体的な指示事項を得るために、インターネットを介してバックエンド（ｂａｃｋｅｎｄ）サーバーと通信することができる。
【００６６】
ＴＤＯモデルでは、ＴＤＯの開始、ＴＯＤの終了、又はＴＤＯによる一部作業の誘発のようにＴＤＯイベントを開始するために信号を放送ストリームで伝達したり又はインターネットを介して伝達することができる。これらのイベントは、特定時間に開始され、一般的にオーディオ−ビデオプログラムと同期化される。ＴＤＯが開始されると、プログラムされた両方向特徴を提供することができる。
【００６７】
ＴＤＯモデルの基本概念は、ＴＤＯを構成するファイル及びある動作を取るためにＴＤＯによって用いられるデータファイルはいずれも、その大きさによって受信機に伝達されるには一定量の時間がかかるということである。両方向エレメントに対するユーザ経験は、コンテンツの放送前に作成（ａｕｔｈｏｒ）されてもよいが、ある振舞いは、プログラム内のイベント、例えば、商業広告セグメントの発生と同時に起きるように注意して時間を決めなければならない。
【００６８】
ＴＤＯモデルでは、宣言的客体、関連しているデータ、スクリプト、テキスト及びグラフィックの伝達を、両方向イベントの再生に対する特定タイミングのシグナリングと区別する。
【００６９】
両方向イベントのタイミングを設定するエレメントはトリガー（Ｔｒｉｇｇｅｒ）である。
【００７０】
一つのセグメント内で用いられるＴＤＯとトリガーによって開始される関連ＴＤＯイベントに関する情報は、“ＴＤＯパラメータテーブル”（ＴＰＴ）と呼ばれるデータ構造によって提供される。
【００７１】
図２は、既に生成されたコンテンツの場合に、トリガータイミングの一実施例を示す図である。
【００７２】
トリガーは、シグナリングを識別し、両方向イベントの再生タイミングを設定する機能を担うシグナリングエレメントである。
【００７３】
トリガーには、両方向サービスに関連するセグメントに対するメディア時間を示す役割を担う時間ベーストリガーと、両方向サービスに関連するアプリケーションのイベント発生時間を示す役割を担う活性化トリガーの２種類があり得る。
【００７４】
トリガーは、両方向サービスの支援のために、タイミングに関連する様々な機能を果たすことができる。トリガーはその機能によって多機能的であってもよく、特定トリガーインスタンス（ｉｎｓｔａｎｃｅ）は、次の機能のうち一つ以上を行うことができる。
【００７５】
１．ＴＰＴ（放出ストリーム内のＦＬＵＴＥセッション、インターネットサーバー、又はこれら両者を介して接近可能なＴＰＴ）の位置をシグナリングする。
【００７６】
２．次のプログラムセグメントに対する両方向コンテンツがプリロード（ｐｒｅ−ｌｏａｄ）されることを示す。
【００７７】
３．関連しているオーディオ／ビデオコンテンツ又はオーディオコンテンツの現在メディア時間を示す。
【００７８】
４．ＴＰＴ内特定両方向イベントを参照し、当該イベントが現在又は特定の未来のメディア時間に実行されなければならないということを知らせる。
【００７９】
５．需要が最大となることを避けるために、インターネットサーバーに対する接続が特定の時間区間上でランダムに分散されることを示す。
【００８０】
図２は、２つのプログラミングセグメントと関連して伝達されるトリガーを示す。この例では、２つのセグメントとも“予め生成”されるが、これは、コンテンツがライブコンテンツではなく、両方向エレメントはポストプロダクション（ｐｏｓｔ−ｐｒｏｄｕｃｔｉｏｎ）で追加されたことを意味する。
【００８１】
図示のように、プログラミングセグメント１の発生前の短い時間に“プリロード（ｐｒｅ−ｌｏａｄ）”トリガーが伝達されて、受信機と関連しているＴＰＴ及びー方向コンテンツを取得できる機会を受信機に許容することができる。万一、プリロードトリガーが送信されないと、受信機は、コンテンツを取得するために該当のセグメント内で会う最初のトリガーを用いると考えることができる。
【００８２】
図示のように、トリガーはＳｅｇｍｅｎｔ１を通して送信されて、当該セグメントに関する現在メディア時間（図では“ｍ”と表記）を示すことができる。当該チャネルに会うトリガーが両方向コンテンツを同期化して取得できるようにするためにメディア時間トリガーの周期的な伝達が必要なことがある。
【００８３】
Ｓｅｇｍｅｎｔ２の開始直前に当該セグメントに対するプリロードトリガーが送信される。
【００８４】
予め生成されたコンテンツ（非ライブ（ｎｏｎ−ｌｉｖｅ）コンテンツ）の場合、受信機が最初のトリガーを処理した後に取得できるＴＰＴは、当該セグメントに対する両方向経験の全てのエレメントのタイミングを定義することができる。当該受信機とＴＤＯが両方向エレメントを再生するようにするために必要なものは、メディアタイミングの知識であってもよい。このＴＰＴはメディア時間に関して両方向イベントを記述することができる。
【００８５】
図３は、ライブコンテンツの場合に、トリガータイミングの一実施例を示す図である。
【００８６】
ライブコンテンツの場合にも、ＴＰＴは、互いに異なる両方向イベントに関連するデータ及び情報を含むが、放送中にプログラム内の動作が展開するまでは、そのようなイベントの再生タイミングは知られないことがある。このようなライブの場合、トリガーの“イベント−タイミング（ｅｖｅｎｔ−ｔｉｍｉｎｇ）”機能が活用される。このモードでトリガーは、特定の両方向イベントが新しい特定メディア時間値に再設定（ｒｅ−ｔｉｍｅｄ）されることを知らせることができる。又は、トリガーは、あるイベントが直ちに実行されることを示すこともできる。
【００８７】
図３で、Ｓｅｇｍｅｎｔ ３に対する各トリガーの機能は次の通りである。
【００８８】
１番トリガーは、プリロードトリガーであって、セグメント３に関するファイルを得ることができるディレクトリを参照する。
【００８９】
２番トリガーは、メディア時間トリガーであって、Ｓｅｇｍｅｎｔ ３に対する再生タイミングを示すために用いられる。
【００９０】
３番トリガーは、イベントリタイミング（ｒｅ−ｔｉｍｉｎｇ）トリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝２のイベントがメディア時間２４０に発生するように時間が再設定されることを示す。ハッチングされた領域は、３番トリガーが受信機に伝達され得る２４０以前の時間区間を示す。
【００９１】
４番トリガーは、メディア時間トリガーである。
【００９２】
５番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝５のイベントがメディア時間４４４に発生するように時間が再設定されることを示す。
【００９３】
６番、７番トリガーは、メディア時間トリガーである。
【００９４】
８番トリガーは、イベントトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝１２のイベントが直ちに実行されることを示す。
【００９５】
９番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝８９のイベントがメディア時間９００に発生するように時間が再設定されることを示す。
【００９６】
以下、ＴＤＯのライフサイクル（ｌｉｆｅ  ｃｙｃｌｅ）と状態、及び状態変化イベントについて説明する。
【００９７】
ＴＤＯは、解除（Ｒｅｌｅａｓｅｄ）、準備（Ｒｅａｄｙ）、活動（Ａｃｔｉｖｅ）、及び中止（Ｓｕｓｐｅｎｄｅｄ）の異なった４つの状態で存在することができる。多数の異なる要素（トリガー、ユーザ動作、変更されるチャネルなど）が一つの状態から他の状態への変動を引き起こしうる。
【００９８】
ＴＤＯは、次の４つの状態を有することができる。４つの状態は、準備（Ｒｅａｄｙ）、活動（Ａｃｔｉｖｅ）、中止（Ｓｕｓｐｅｎｄｅｄ）及び解除（Ｒｅｌｅａｓｅｄ）である。準備状態は、ＴＤＯがダウンロードされて実行準備となっているが、まだ実行されてはいないことを意味する。活動状態は、ＴＤＯが実行中であることを意味する。中止状態は、その状態の保存と併せて、ＴＤＯの実行が一時的に中止することを意味する。解除状態は、ＴＤＯが準備、活動又は中止状態でないことを意味する。
【００９９】
ＴＤＯの状態変化を起こし得るイベントの例には次のものがある。
【０１００】
１．“ｐｒｅｐａｒｅ”をトリガーする  −  装置は、ＴＤＯが実行（リソース割当、主メモリへのローディングなど）をするように準備されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。
【０１０１】
２．“ｅｘｅｃｕｔｅ”をトリガーする  −  装置は、ＴＤＯが活性化されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。
【０１０２】
３．“ｓｕｓｐｅｎｄ”をトリガーする  −  装置は、ＴＤＯの中止を示すトリガーを（現在選択された１次仮想チャネルで）受信する。
【０１０３】
４．“ｋｉｌｌ”をトリガーする  −  装置は、ＴＤＯの終了を示すトリガーを（現在選択された１次仮想チャネルで）受信する。
【０１０４】
図４は、トリガーシンタックスの一実施例を示す図である。
【０１０５】
活性化メッセージと時間ベースメッセージは両方とも、ある送信環境で次のような一般的な“トリガー”フォーマットを有することができる。
【０１０６】
ここで、シンタックス上の定義は、アルタネイティブ（ａｌｔｅｒｎａｔｉｖｅ）を指定するために垂直バーシンボル”｜”が使われる場合以外は、ＡＢＮＦ（Ａｕｇｍｅｎｔｅｄ  Ｂａｃｋｕｓ−Ｎａｕｒ  Ｆｏｒｍ）文法を用いて記述する。ルール（ｒｕｌｅ）は等号”＝”によって定義と分離され、１行を超えてルール定義を続けるときは字下げ（ｉｎｄｅｎｔａｔｉｏｎ）を用い、リテラル（ｌｉｔｅｒａｌ）は””で引用し、エレメントのグループ化には括弧”（”と”）”を用い、選択的なエレメントは”［”と”］”との間に入れる。そして、エレメントの前に＜ｎ＞*がつくと、その次のエレメントのｎ回以上の反復を指定でき、ｎは基本値として０に設定される。そして、エレメントの前に＜ｎ＞*＜ｍ＞がつくと、その次にくるエレメントのｎ回以上ｍ回以下の反復を指定することができる。
【０１０７】
このようなトリガーシンタックスは、＜ｓｃｈｅｍｅ＞と“：／／”部分を除いて、付加的な制限事項と共にＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）：ジェネリックシンタックス（Ｇｅｎｅｒｉｃ  Ｓｙｎｔａｘ）に基づく。
【０１０８】
トリガーは、ｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓで構成することができる。ｔｅｒｍｓは、省略可能な構成である。ｔｅｒｍｓが存在するとｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓとを‘？’で連結することができる。
【０１０９】
ｌｏｃａｔｏｒ＿ｐａｒｔは、ｈｏｓｔｎａｍｅ部分とｐａｔｈ＿ｓｅｇｍｅｎｔｓ部分とで構成することができ、その間は‘／’で連結することができる。
【０１１０】
ｈｏｓｔｎａｍｅは、ｄｏｍａｉｎｌａｂｅｌとｔｏｐｌａｂｅｌとで構成することができ、ｄｏｍａｉｎｌａｂｅｌはその次に‘．’と共に０回以上反復され得る。すなわち、ｈｏｓｔｎａｍｅは、反復されたｄｏｍａｉｎｌａｂｅｌがｔｏｐｌａｂｅｌと連結した形態であってもよく、又は、ｔｏｐｌａｂｅｌのみで構成された形態であってもよい。
【０１１１】
ｄｏｍａｉｎｌａｂｅｌは、一つのａｌｐｈａｎｕｍからなる形態であってもよい。又は、２つのａｌｐｈａｎｕｍの間にａｌｐｈａｎｕｍ又は‘−’が０回以上反復されたものが挿入された形態であってもよい。
【０１１２】
ここで、ａｌｐｈａｎｕｍは、ａｌｐｈａ又はｄｉｇｉｔを意味することができる。
【０１１３】
ここで、ａｌｐｈａは、ｌｏｗａｌｐｈａ又はｕｐａｌｐｈａのいずれかであってもよい。
【０１１４】
ここで、ｌｏｗａｌｐｈａは、ａ、ｂ、ｃ、ｄ、ｅ、ｆ、ｇ、ｈ、ｉ、ｊ、ｋ、ｌ、ｍ、ｎ、ｏ、ｐ、ｑ、ｒ、ｓ、ｔ、ｕ、ｖ、ｗ、ｘ、ｙ、ｚのいずれか一つであってもよい。
【０１１５】
ここで、ｕｐａｌｐｈａは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌ、Ｍ、Ｎ、Ｏ、Ｐ、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖ、Ｗ、Ｘ、Ｙ、Ｚのいずれか一つであってもよい。
【０１１６】
ここで、ｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９のいずれか一つであってもよい。
【０１１７】
ｔｏｐｌａｂｅｌは、一つのａｌｐｈａからなる形態であってもよい。又は、ａｌｐｈａとａｌｐｈａｎｕｍとの間にａｌｐｈａｎｕｍ又は‘−’が０回以上反復されたものが挿入された形態であってもよい。
【０１１８】
ｐａｔｈ＿ｓｅｇｍｅｎｔｓは、セグメントが一つがあり、その次にセグメントが０回以上反復されたものが続く形態であってもよい。このとき、セグメントの間は‘／’で連結することができる。
【０１１９】
ここで、セグメントは、ａｌｐｈａｎｕｍが１回以上反復された形態であってもよい。
【０１２０】
ｔｅｒｍｓは、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅのいずれかからなる形態であってもよい。続いてｓｐｒｅａｄ又はｏｔｈｅｒｓが来てもよい。ｓｐｒｅａｄとｏｔｈｅｒｓは省略可能な構成であってもよい。ｓｐｒｅａｄとｏｔｈｅｒｓが存在すると、これは‘＆’を前に置いている形態であって、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅの次に位置することができる。
【０１２１】
ここで、ｓｐｒｅａｄは、‘ｓ＝’の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。
【０１２２】
ｅｖｅｎｔ＿ｔｉｍｅは、‘ｅ＝’の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。又は、その後、‘＆ｔ＝’の次にｈｅｘｄｉｇｉｔが１回以上７回以下反復されたものが続く形態であってもよい。‘＆ｔ＝’とその次の部分は省略可能な構成であってもよい。
【０１２３】
ここで、ｈｅｘｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９、ａ、ｂ、ｃ、ｄ、ｅ、ｆのいずれか一つであってもよい。
【０１２４】
ｍｅｄｉａ＿ｔｉｍｅは、‘ｍ＝’の次にｈｅｘｄｉｇｉｔが１回以上７回未満反復されたものが続く形態であってもよい。
【０１２５】
ｏｔｈｅｒｓは、一つのｏｔｈｅｒからなる形態であってもよい。又は、その次に‘＆’とｏｔｈｅｒが追加された形態であってもよい。
【０１２６】
ここで、ｏｔｈｅｒは、ｒｅｓｖ＿ｃｍｄとａｌｐｈａｎｕｍが１回以上反復されたものとが‘＝’によって連結された形態であってもよい。
【０１２７】
ここで、ｒｅｓｖ＿ｃｍｄは、‘ｃ’、‘ｅ’、‘Ｅ’、‘ｍ’、‘Ｍ’、‘ｓ’、‘Ｓ’、‘ｔ’、‘Ｔ’を除くａｌｐｈａｎｕｍであってもよい。
【０１２８】
トリガーの長さは５２バイトを超えなくてもよい。そして、トリガーのｈｏｓｔｎａｍｅ部分は、登録されたインターネットドメイン名であってもよい。
【０１２９】
トリガーは、３つの部分からなることがわかる。
【０１３０】
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞［？＜ｐａｒａｍｅｔｅｒｓ＞］
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたドメイン名であり、＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、ドメイン名がＵＲＩにおいて登場するようになる経路であってもよい。
【０１３１】
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたインターネットドメイン名を参照することができる。＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、識別されたドメイン名に対する権限を持つエンティティ（ｅｎｔｉｔｙ）の制御及び管理下でディレクトリ経路を識別する任意の文字列であってもよい。
【０１３２】
ＴＤＯモデルで、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、関連しているコンテンツに両方向性を追加するために受信機によって処理され得るＴＰＴを固有に識別することができる。
【０１３３】
＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、現在セグメントに対するＴＰＴが得られるインターネット位置のＵＲＬであってもよい。
【０１３４】
すなわち、トリガーは、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞を用いてＴＰＴを識別することができ、これによってトリガーの適用されるＴＰＴがわかる。当該ｔｒｉｇｇｅｒがＴＰＴに適用されてどのような役割を果たすかは、＜ｐａｒａｍｅｔｅｒｓ＞部分による。
【０１３５】
以下、＜ｐａｒａｍｅｔｅｒｓ＞部分について説明する。
【０１３６】
＜ｐａｒａｍｅｔｅｒｓ＞は、“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、又は“ｓｐｒｅａｄ”の一つ以上で構成することができる。
【０１３７】
次は、図４に示したシンタックスにおいて“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、“ｓｐｒｅａｄ”に関する部分である。
【０１３８】
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
＜ｐｏｌｌ−ｐｅｒｉｏｄ＞パラメータは、連続するポールに対してポール間の推奨間隔を示すことができる。＜ｐｏｌｌ−ｐｅｒｉｏｄ＞は省略されてもよい。
【０３４２】
次に、活性化トリガー一括伝達について説明する。
【０３４３】
活性化トリガーがインターネットを介して一括的に伝達される場合、一つのセグメントに対する活性化トリガーを、当該セグメントに対するＴＰＴをメッセージの一番目の部分とし、ＡＭＴをメッセージの二番目の部分とする多重部分ＭＩＭＥメッセージの形態としてＨＴＴＰを通じて当該セグメントに対するＴＰＴと共に伝達することができる。
【０３４４】
以下、放送ストリームでのＴＰＴ伝達について説明する。
【０３４５】
放送ストリームで伝達時に、ＴＰＴを、それらのＸＭＬフォーマットから相応する２進ＮＲＴ−スタイルシグナリングフォーマットに変換して、テーブルインスタンス当たり一つずつＮＲＴ−スタイルプライベートセクションにカプセル化することができる。現在セグメントに対するＴＰＴは常に存在する。一つ以上の未来セグメントにに対するＴＰＴも存在することができる。ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄフィールドの値によって定義される。参考として、ＴＤＯパラメータテーブルの２進フォーマットは、上述した通りである。ここで、ＮＲＴ−スタイルプライベートセクションは、図１６のｔｐｔ＿ｓｅｃｔｉｏｎ（）に該当してもよい。
【０３４６】
要するに、ＴＰＴの２進構造をＮＲＴで送信するために、ＮＲＴ送信に合うようにセクション構造を有することができる。以下、この過程について詳しく説明する。
【０３４７】
各ＴＰＴをブロックに分割し、それらのブロックをｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎとｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの共通値を持つセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドに挿入することによって、各ＴＰＴをＮＲＴ−スタイルプライベートセクション内にカプセル化することができる。これらのブロックは、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値の昇順でセクションに挿入することができる。プライベートセクションは、ＴＰＴに関連する仮想チャネルのＩＰサブネットのサービスシグナリングチャネル（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ；ＳＳＣ）で送信することができる。ここで、“Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ”は、ＡＴＳＣ−ＮＲＴ標準に定義されており、特定ＩＰアドレスとポートナンバーを持つチャネルを意味する。セクション内のｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同一ＳＳＣで送信される互いに異なるＴＰＴインスタンスを区別するために用いることができる。
【０３４８】
以下、図１６のフィールドについて説明する。
【０３４９】
プライベートセクション（ｔｐｔ＿ｓｅｃｔｉｏｎ（））は、ｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、及び／又はｓｅｒｖｉｃｅ＿ｉｄ、ｔｐｔ＿ｂｙｔｅｓ（）情報を含むことができる。
【０３５０】
８ビットフィールドであってもよいｔａｂｌｅ＿ｉｄは、当該テーブルセクションをＴＤＯパラメータテーブルインスタンスに属するものとして識別することができる。
【０３５１】
ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは２つの部分に分けることができる。８ビット符号無し整数フィールドのうち上位４ビットは、当該テーブルの定義の主バージョン番号と、ここに含まれて送信されるＴＰＴインスタンスを示すことができ、下位４ビットは、副バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すＡＭＴのインスタンスを捨てると予想され得る。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すＡＭＴのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが認識できないデスクリプタと、それらが支援しないフィールドを無視すると予想できる。
【０３５２】
ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、８ビットフィールドであってもよい。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、当該ＴＰＴインスタンスの他の全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと同一であり、当該サービスシグナリングチャネル内の他のＴＰＴインスタンスの全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒとは異なってよい。したがって、他のＴＰＴインスタンスと区別する役割を担うことができる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、このセクションが現れるサービスシグナリングチャネルに関連しているＩＰサブネットを示すことができる。互いに異なるＴＰＴインスタンスのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値は、放送ストリームでセグメントが登場する順序を反映することができる。
【０３５３】
ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、５ビットフィールドであってもよく、当該ＴＰＴインスタンスのバージョン番号を示すことができるが、ここで、ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄによって定義することができる。ＴＰＴバージョンをあらかじめ知ってこそ受信されたＴＰＴセクションデータが最新バージョンのＴＰＴであるか否かがわかるため、セクションテーブルにＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドがあってもよい。バージョン番号は、ＴＰＴインスタンス内の任意のフィールドに変更がある場合、１ ｍｏｄｕｌｏ ３２分ずつ増分できる。
【０３５４】
ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒは１ビット指示子であってもよく、ＴＰＴセクションに対して常に‘１’に設定されて送信されるＴＰＴがｓｅｇｍｅｎｔ＿ｉｄによって識別されるセグメントに対して常に現在ＴＰＴであることを示すことができる。
【０３５５】
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、当該ＴＰＴインスタンスセクションのセクション番号を提供することができるが、ＴＰＴインスタンスはｓｅｇｍｅｎｔ＿ｉｄによって識別可能である。ＴＰＴインスタンス内の最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは０ｘ００であってもよい。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、ＴＰＴインスタンス内の各追加セクションと共に１ずつ増分可能である。
【０３５６】
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、最後のセクション（すなわち、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒが最も高いセクション）が、その一部であるＴＰＴインスタンスの最後のセクション番号を提供することができる。
【０３５７】
ｓｅｒｖｉｃｅ＿ｉｄは、当該テーブルインスタンスに記述されたコンテンツアイテムを提供する両方向サービスと関連しているｓｅｒｖｉｃｅ＿ｉｄを特定することができる。
【０３５８】
ｔｐｔ＿ｂｙｔｅｓ（）は、可変長フィールドであって、当該セクションによって部分的に送信されるＴＰＴインスタンスブロックで構成することができる。当該テーブルインスタンスの全てのセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドがｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドの順に連結されると、その結果として一つの完全なＴＰＴインスタンスが作成できる。
【０３５９】
すなわち、ＴＰＴの２進フォーマットを用いたり、ＸＭＬフォーマットを２進フォーマットに変えた後、ＮＲＴ送信に合うようにそれを分けて、プライベートセクションのうちｔｐｔ＿ｂｙｔｅｓ（）フィールドに入れてＮＲＴ方式で送信することができる。このとき、一つのＴＰＴが複数のプライベートセクションに分けられると、それぞれのプライベートセクションは、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を有することができる。分けられたＴＰＴブロックをｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値に従う順に挿入することができる。
【０３６０】
受信端では、受信したプライベートセクションに対してパーシングできる。一つのＴＰＴに再びまとめるために、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つプライベートセクションを用いることができる。このとき、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ情報から得られる順序情報を用いることができる。同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つ全てのプライベートセクションのｔｐｔ＿ｂｙｔｅｓ（）がｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒの順に連結されると、その結果として一つの完全なＴＰＴを作成できる。
【０３６１】
インターネットを介したＴＰＴの伝達について図１７を参照して詳しく説明する。
【０３６２】
次に、ＴＤＯ及びコンテンツアイテムの移動について説明する。
【０３６３】
ネットワークと基地局は、ＴＤＯ及びこれらのＴＤＯによって用いられるコンテンツアイテム（ファイル）の伝達のために、自体ＨＴＴＰサーバーを頻繁に提供しなければならない。提供がなされると、ＴＰＴ内のｂａｓｅＵＲＬはサーバーの位置を反映して調整されてもよい。
【０３６４】
次に、複数のセグメントを一つのセグメントへの結合について説明する。
【０３６５】
セグメント間の境界を徹底的に曖昧にさせるために、複数のセグメントに対するＴＰＴとＡＭＴを一つのＴＰＴ及びＡＭＴに結合することができる。その段階は、次の通りである。
【０３６６】
１．結合されるセグメントの集合を識別する。
【０３６７】
２．新しいｓｅｇｍｅｎｔＩｄを有する新しいＴＰＴを生成する。
【０３６８】
３．結合されるセグメントの中でライブ活性化を有するものがあれば、それらの活性化の全てに対して接近権限を付与するリレーサーバーを提供し、このサーバーに対するパラメータを“ＬｉｖｅＴｒｉｇｇｅｒ”エレメントに入れる。
【０３６９】
４．必要によって各セグメントに対してｂａｓｅＵＲＬを適用して全体ＴＤＯとＣｏｎｔｅｎｔＩｔｅｍ ＵＲＬを得る（結合される全てのセグメントに共通するより短いｂａｓｅＵＲＬを識別し、それを、結合されたセグメントに対するｂａｓｅＵＲＬとして維持する）。
【０３７０】
５．必要によって値を修正して衝突を除去する。
【０３７１】
６．結合される全てのセグメントに対する全ての修正されたＴＤＯエレメントを新しいＴＰＴに挿入する。
【０３７２】
７．結合されたＴＰＴの新しいｓｅｇｍｅｎｔＩｄに相応するｓｅｇｍｅｎｔＩｄを有する新しいＡＭＴを生成する。
【０３７３】
８．新しいＡＭＴに対して適切な新しい“ｂｅｇｉｎＭＴ”値を選択する。
【０３７４】
９．ａｐｐＩｄ値における変更を反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎ要素のｔａｒｇｅｔＩｄ値を調整する。
【０３７５】
１０．新しい“ｂｅｇｉｎＭＴ”値と結合されるセグメントに対する放送スケジュールを反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎエレメントのｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ値を調整する。
【０３７６】
１１．修正された全てのＡｃｔｉｖａｔｉｏｎエレメントを新しいＡＭＴに挿入する。
【０３７７】
図１７は、ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。
【０３７８】
以下、インターネットを介したＴＰＴの伝達について説明する。
【０３７９】
インターネットで伝達される場合、ＴＰＴはＨＴＴＰを通じて伝達することができる。時間ベースメッセージで現在セグメントに対するＴＰＴのＵＲＬは“＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞”であってもよい。ＴＰＴに対する要求に対する応答は、単純にＴＰＴで構成されてもよく、要求されたＴＰＴは第１部分にあり、ＵＲＬリストは第２部分にあってＸＭＬ文書としてエンコードされる２−部分ＭＩＭＥメッセージとして構成されてもよい（要求に対する応答は常に現在セグメントに対するＴＰＴを含む。一つ以上の未来セグメントらに対するＴＰＴも含むことができる）。
【０３８０】
上述した応答の第２部分としてのＵＲＬは、図１７のような形態であってもよい。
【０３８１】
図１７のエレメントのセマンティックスについて説明する。
【０３８２】
“ＵｒｌＬｉｓｔ”は、受信機に有用なＵＲＬリストを含むことができる。
【０３８３】
“ＴｐｔＵｒｌ”は、未来セグメントに対するＴＰＴのＵＲＬを含むことができる。複数のＴｐｔＵｒｌエレメントが含まれる場合、それらは、放送でセグメントの登場順に配列することができる。
【０３８４】
“ＮｒｔＳｉｇｎａｌｉｎｇＵｒｌ”は、受信機が現在の放送ストリームで全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得し得るサーバーのＵＲＬを含むことができる。。
【０３８５】
図１８は、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
【０３８６】
以下、ＤＯを実行するための環境のための、ＡＴＳＣＪａｖａＳｃｒｉｐｔＡＰＩについて説明する。
【０３８７】
放送プログラムに対する宣言的客体動作の同期化を支援するために、ビデオ／放送客体に対して追加の方法が支援されてもよい。
【０３８８】
ＤＴＶＣＣ或いはインターネットでＴＰＴが受信されると、ＴＰＴ内にはＴＤＯを実行するための複数のイベントがあってもよく、これらのイベントは活性化トリガーによって活性化されてもよい。
【０３８９】
このイベントを処理するようにするために、リスナー（Ｌｉｓｔｅｎｅｒ）という関数をｅｖｅｎｔＩＤ別に登録しておくことができる。これによって、上述の‘追加の方案’として、リスナー関数を登録できる次の２つの関数があり得る。
【０３９０】
図１８には、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒについての説明とフォーマット、アーギュメント（ａｒｇｕｍｅｎｔ）などが示されている。
【０３９１】
”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ｅｖｅｎｔＩｄごとに生成されたイベントを処理するコールバック（ｃａｌｌｂａｃｋ）関数（リスナー関数）を登録することができる。”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒ及びＮｕｍｂｅｒタイプのｅｖｅｎｔＩｄをアーギュメントとして受け取ることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについて後述する。”ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は返還値を有さなくともよい（ｖｏｉｄ）。ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメントにおいてイベントＩＤであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、イベントに対するリスナーであってもよい。
【０３９２】
受信機のトリガー処理モジュールでは活性化メッセージを受信するすと直ちに“ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数を用いてｅｖｅｎｔＩｄごとにリスナー関数を登録することができる。後で当該イベントに活性化が起きると、登録されたリスナー関数を呼び出すことができる。このとき、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの客体をリスナー関数として伝達することができる。ＴｒｉｇｇｅｒＥｖｅｎｔタイプについては後述する。
【０３９３】
図１９は、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。
【０３９４】
図１９には、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒに対する説明とフォーマット、アーギュメントなどが示されている。
【０３９５】
”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ｅｖｅｎｔＩｄごとに生成されたイベントを処理するコールバック関数（リスナー関数）の登録を取消すことができる。”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒ及びＮｕｍｂｅｒタイプのｅｖｅｎｔＩｄをアーギュメントとして受け取ることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについて後述する。”ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”関数は返還値を有しなくてもよい（ｖｏｉｄ）。ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメントでイベントＩＤであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、イベントに対するリスナーであってもよい。
【０３９６】
ジャバスクリプトプログラムでは、当該ｅｖｅｎｔＩｄ別に発生し得るイベントをそれ以上受信しないことを希望したり、“ＤｅｓｔｒｏｙＷｉｎｄｏｗ”のようなプログラム終了時には、“ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ”を用いて、登録されたリスナー関数を取り消すことができる。
【０３９７】
図２０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。
【０３９８】
ここで、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義は、Ｗｅｂ ＩＤＬ（Ｗｅｂ  ｉｎｔｅｒｆａｃｅ  ｄｅｆｉｎｉｔｉｏｎ  ｌａｎｇｕａｇｅ）（インターフェース定義言語）に従う。Ｗｅｂ ＩＤＬは、ウェブブラウザーで実行されるように意図的インターフェースを記述するために用いることができる。Ｗｅｂ ＩＤＬは、ウェブプラットフォームにおける共用スクリプトオブジェクトの動作をより読みやすく明細化するための多数の機能を有するＩＤＬの変種である。
【０３９９】
ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプは、ＴｒｉｇｇｅｒＥｖｅｎｔタイプを持つイベントをアーギュメントとすることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒはインターフェースであってもよい。
【０４００】
図２１は、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。
【０４０１】
ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、イベントに関する情報を含むことができる。
【０４０２】
ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、ｅｖｅｎｔＩｄ、ｄａｔａ、ｓｔａｔｕｓを属性として有することができる。ここで、ｅｖｅｎｔＩｄは、ＴＰＴのイベントエレメント中のｅｖｅｎｔＩｄであってもよい。ここで、ｄａｔａは、イベントの活性化のためのものであってもよい。ここで、ｄａｔａは、１６進法となっていてもよい。ここで、ｓｔａｔｕｓは、イベントの状態を意味することができる。ここで、ｓｔａｔｕｓ値が“ｔｒｉｇｇｅｒ”の場合は、イベントが活性化トリガーによって活性化された状態を意味できる。ここで、ｓｔａｔｕｓ値が“ｅｒｒｏｒ”の場合は、エラーが発生した状態を意味できる。
【０４０３】
ＴＤＯモデルについて説明してきた。以下、直接実行モデルについて説明する。
【０４０４】
直接実行モデルでは、仮想チャネルが選択されると、宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ；ＤＯ）が自動で開始され得る。ＤＯは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのようにオーディオ−ビデオプログラムと同期化される両方向特徴の提供のための具体的な指示事項を得るために、バックエンド（ｂａｃｋｅｎｄ）サーバーとインターネットを介して通信することができる。
【０４０５】
以下直接実行モデルにおけるトリガー動作について説明する。
【０４０６】
トリガーの役割、機能、シンタックスは、直接実行モデルにおいても大きく変わらない。
【０４０７】
トリガーの性能については、上述した通りである。
【０４０８】
トリガーシンタックスについては、上述した通りである。
【０４０９】
トリガーは、３つの部分で構成されたと見なすことができる。
【０４１０】
＜ドメインネーム部分＞／＜ディレクトリ経路＞［？＜パラメータ＞］
直接実行モデルにおいて、＜ドメインネーム部分＞と＜ディレクトリ経路＞の組合せは、開始されるＤＯを固有に識別することができる。
【０４１１】
＜パラメータ＞は、“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、又は“ｓｐｒｅａｄ”のうち一つ以上からなることができる。
【０４１２】
直接実行モデルにおいて、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは、“同期化されたコンテンツプロトコル”を介してバックエンドサーバーとインターネットで通信することができる。このサーバーは、オーディオ−ビデオプログラムと全て同期化された両方向特徴の提供のための具体的な指示事項を提供することができる。
【０４１３】
直接実行モデルの場合、直ちにアプリケーションが実行されるために、時間ベーストリガーが伝達されるやいなや、現在実行中のアプリケーションに情報を伝達することができる。このモデルにおいて、アプリケーションは、サーバーに、同期化のために、現在放映中のコンテンツに関する情報を続けて伝達する必要がある。そのために、時間ベーストリガーには、ＴＤＯモデルとは異なる特別な情報がさらに含まれてもよい。この特別な情報は、現在放映中のコンテンツに対する識別子であってもよい。
【０４１４】
同様に、上記コンテンツ識別子は、トリガーのパラメータ部分にパラメータの形態で存在できる。
【０４１５】
同様に、上記コンテンツ識別子は、トリガーのｍｅｄｉａ＿ｔｉｍｅに一つの項の形態で存在してもよい。コンテンツ識別子項は、文字列を伴う“ｃ＝”によって指定されうるｃｏｎｔｅｎｔ＿ｉｄと呼ぶことができ、現在見られているコンテンツに対する識別子を示すことができる。
【０４１６】
ｃｏｎｔｅｎｔ＿ｉｄ項は、両方向サービス実行に対する直接実行モデルを支援するためのものであってもよい。
【０４１７】
上述した通り、このモデルにおいて、ｃｏｎｔｅｎｔ＿ｉｄ項を有する時間ベーストリガーは、アプリケーションの開始後にこのアプリケーションに伝達されてもよく、このアプリケーションは、両方向作用のためのコンテクスト（ｃｏｎｔｅｘｔ）の識別のために、ｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。詳細な動作については後述する。
【０４１８】
直接実行モデルにおけるトリガーの伝達メカニズムについては、上述した通りである。
【０４１９】
ただし、放送ストリームによるトリガーの伝達の場合において、トリガーは、ＵＲＬＳｔｒｉｎｇ命令でサービス＃６でＤＴＶクローズドキャプションチャネルに伝達されてもよい。そして、直接実行モデルを用いる両方向サービスは、ＵＲＩ＿ｔｙｐｅフィールドが２（直接実行モデルのための両方向ＴＶトリガー）に設定されてもよい。
【０４２０】
以下、直接実行モデルの全体動作について説明する。
【０４２１】
両方向サービスを実行する一つのモデルとして、直接実行モデルでは、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは“同期化されたコンテンツプロトコル”を介してインターネットでバックエンドサーバーと通信することができる。このサーバーは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのようにオーディオ−ビデオプログラムと同期化される両方向特徴の提供のための具体的な指示事項を提供することができる。
【０４２２】
上記の動作を次のように行うことができる。
【０４２３】
まず、アプリケーションが開始されうる。その後、時間ベーストリガーが受信される。時間ベーストリガーは、アプリケーションが実行された後にアプリケーションに伝達される。時間ベーストリガーのｃｏｎｔｅｎｔ＿ｉｄ項には、現在見られているコンテンツに関するコンテンツ識別情報が含まれていてもよい。アプリケーションは、相互作用のためのコンテクストを識別し、現在見られているコンテンツを識別するためにｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。
【０４２４】
直接実行モデルについて説明してきた。
【０４２５】
図２２は、ＷＭ技法のためのアーキテクチャの一実施例を示す図である。
【０４２６】
他のインターフェースを介した伝達について説明する。
【０４２７】
非圧縮されたオーディオ及びビデオにのみ接近可能な（例えば、ケーブル又は衛星セットトップボックスから受信される）環境で両方向サービスの取得を可能にするプロトコル及びアーキテクチャが定義される。アーキテクチャ及びプロトコルは、インターネット接続を有し、放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる受信機による使用のために設計することができる。勿論、アーキテクチャ及びプロトコルは、両方向サービスプロバイダがそれの支援を選択する場合は、成功的に用いることができる。
【０４２８】
このアーキテクチャは、視聴されているコンテンツの識別のための２つの基本技法を支援するように設計され、関連両方向サービスデータ改善事項がインターネットを介して伝達されうるようにすることができる。２つの基本技法は、ウォーターマーキング（Ｗａｔｅｒ  ｍａｒｋｉｎｇ）とフィンガープリンティング（Ｆｉｎｇｅｒ  ｐｒｉｎｔｉｎｇ）であってもよい。
【０４２９】
ウォーターマーキング、フィンガープリンティング技法両方とも、その目的は、どのプログラムが現在視聴されているかを受信機が探して、当該プログラムのための両方向サービスに関する付加情報を得る出発点として用いられうるＵＲＬを取得できるようにすることである。
【０４３０】
図２２は、ＷＭ技法のためのアーキテクチャの一実施例を示す図である。
【０４３１】
ＷＭ技法のためのアーキテクチャにおいて、アーキテクチャは、放送局２２０１０、ウォーターマーク挿入部２２０１１、ＭＶＰＤ ２２０２０、ＳＴＢ ２２０３０、受信機２２０４０、ＷＭクライアント２２０５０、ＴＰＴサーバー２２０６０及びコンテンツサーバー２２０７０で構成することができる。
【０４３２】
放送局２２０１０は、オーディオ／ビデオストリーム及びこれと関連する両方向サービスを送出するソースであってもよい。ＴＶ放送局などをその例に挙げることができる。 放送局２２０１０は、放送コンテンツの生産者又は流通業者であってもよい。放送局２２０１０は、放送ストリーム、オーディオ／ビデオコンテンツ、両方向データ、放送スケジュール又はＡＭＴなどを伝達することができる。
【０４３３】
ウォーターマーク挿入部２２０１１は、放送されるオーディオ／ビデオフレームにウォーターマークを入れることができる。ウォーターマーク挿入部２２０１１は、放送局２２０１０と統合されてもよく、別個のモジュールであってもよい。ウォーターマークとは、受信機に必要な一種の情報であってもよい。ウォーターマークは、ＵＲＬのような情報であってもよい。ウォーターマークについての詳細は後述する。
【０４３４】
ＭＶＰＤ ２２０２０は、多重チャネルビデオプログラム流通業者（Ｍｕｌｔｉｐｒｏｇｒａｍ  Ｖｉｄｅｏ  Ｐｒｏｇｒａｍ  Ｄｉｓｔｒｉｂｕｔｏｒ）の略語である。ＭＶＰＤ ２２０２０は、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者であってもよい。ＭＶＰＤ ２２０２０は、放送局／ウォーターマーク挿入部から放送ストリームを受信することができ、ウォーターマーキングＡＣＲシステムの場合、ウォーターマーク挿入部２２０１１によってウォーターマークが挿入される。ＭＶＰＤ ２２０２０は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス（ＳＴＢ）に送る。
【０４３５】
ＳＴＢ ２２０３０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを、視聴者が視聴するＴＶ受像機に送る。ＳＴＢは、非圧縮されたオーディオ／ビデオコンテンツを受信機２２０４０に送ることができる。ＳＴＢは、本発明の一実施例に係る外部のデコーティング部であってもよい。
【０４３６】
受信機２２０４０は、ＷＭクライアント２２０５０を含むことができる。ＷＭクライアント２２０５０は、受信機２２０４０の外部に位置してもよい。ここで、受信機は、ウォーターマーキングができる受信機である。受信機２２０４０の構造については後述する。
【０４３７】
ＷＭクライアント２２０５０は、該当用途のＡＰＩを用いてＡＣＲサーバー（図示せず）から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、ＷＭクライアント２２０５０は、受信機内に構成されるが、他の構成も可能である。ＷＭクライアント２２０５０は、非圧縮されたオーディオ／ビデオコンテンツから、挿入されたウォーターマークを抽出することができる。ウォーターマークはＵＲＬなどの情報であってもよい。
【０４３８】
ＴＰＴサーバー２２０６０は、ＴＰＴのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機２２０４０は、抽出されたウォーターマークをＡＣＲサーバーに伝送する。ウォーターマークがデータベース（図示せず）に保存されたウォーターマークとマッチングされると、受信機２２０４０は、一つのトリガー又は複数トリガーを応答として受信することができる。受信された一つのトリガー又は複数トリガーが、上述した新しいｌｏｃａｔｏｒ＿ｐａｒｔを有したり、又は新しいバージョンのＴＰＴ又はアプリケーションパラメータテーブルが発見されると、受信機２２０４０はＴＰＴサーバー２２０６０に新しいＴＰＴ又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
【０４３９】
コンテンツサーバー２２０７０は、両方向サービスを提供するために必要なアプリケーション及びＴＤＯを提供することができる。新しいアプリケーション又はＴＤＯが必要な場合、新しいアプリケーションは、ＴＰＴ又はアプリケーションパラメータテーブルにあるＵＲＬを用いてダウンロードすることができる。
【０４４０】
ウォーターマーキング（ＷＭ）技法において、放送局／ウォーターマーク挿入部は、放送されるオーディオ／ビデオフレームにウォーターマークを入れることができる。これらのウォーターマークは、視聴者に感知されないか、又はできるだけ邪魔とならないような量の情報を受信機に送信するように設計することができる。このようなウォーターマークは、受信機が必要とする情報を直接提供してもよく、又は受信機が必要とする情報を得るために、遠く離れたサーバーにインターネット接続を通して送ることができるコード値のみを提供してもよい。
【０４４１】
図２３に、ＦＰ技法のアーキテクチャの一実施例が示されている。
【０４４２】
ＦＰ技法のアーキテクチャにおいて、アーキテクチャは、放送局２３０１０、ＭＶＰＤ ２３０２０、ＳＴＢ ２３０３０、受信機２３０４０、ＦＰクライアント２３０５０、ＴＰＴサーバー２３０６０、コンテンツサーバー２３０７０、シグネチャー（ｓｉｇｎａｔｕｒｅ）抽出機２３０８０及びＦＰサーバー２３０９０で構成することができる。
【０４４３】
放送局２３０１０は、オーディオ／ビデオストリーム及びオーディオ／ビデオストリームと関連した両方向サービスを出力するソースであってもよい。放送局２３０１０の一例としてＴＶ放送局が挙げられる。放送局２３０１０は、放送コンテンツ生産者や配給者であってもよい。放送局２３０１０は、放送ストリーム、オーディオ／ビデオコンテンツ、両方向データ、放送スケジュール、又はＡＭＴを伝達することもできる。
【０４４４】
ＭＶＰＤ ２３０２０は、多重チャネルビデオプログラム流通業者（Ｍｕｌｔｉｐｒｏｇｒａｍ  Ｖｉｄｅｏ  Ｐｒｏｇｒａｍ  Ｄｉｓｔｒｉｂｕｔｏｒ）の略語である。ＭＶＰＤ ２３０２０は、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者であってもよい。ＭＶＰＤ ２３０２０は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス（ＳＴＢ）に送る。
【０４４５】
ＳＴＢ ２３０３０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを視聴者に視聴されるＴＶ受像機に送る。ＳＴＢは、非圧縮されたオーディオ／ビデオコンテンツを受信機２３０４０に送ることができる。ＳＴＢ ２３０３０は、本発明の一実施例に係る外部のデコーティング部であってもよい。
【０４４６】
受信機２３０４０は、ＦＰクライアント２３０５０を含むことができる。ＦＰクライアント２３０５０は、受信機２２０４０の外部に位置してもよい。ここで、受信機２３０４０は、フィンガープリンティングができる受信機である。受信機２３０４０の構造については後述する。
【０４４７】
ＦＰクライアント２３０５０は、当該用途のＡＰＩを用いて、ＦＰサーバー２３０９０から活性化トリガーを受けてそれらをメイン受信機コードに送ることができる。一般に、ＦＰクライアント２３０５０は受信機内に構成されるが、他の構成も可能である。ＦＰクライアント２３０５０は、非圧縮されたオーディオ／ビデオコンテンツから、フィンガープリントを抽出することができる。フィンガープリントについては後述する。
【０４４８】
ＴＰＴサーバー２３０６０は、ＴＰＴのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機２３０４０は、抽出されたフィンガープリントをＦＰサーバー２３０９０に伝送する。フィンガープリントがシグネチャー抽出機２３０８０のシグネチャーとマッチングされると、受信機２３０４０は、一つのトリガー又は複数トリガーを応答として受信することができる。受信された一つのトリガー又は複数トリガーが上述の新しいｌｏｃａｔｏｒ＿ｐａｒｔを有したり、又は新しいバージョンのＴＰＴ又はアプリケーションパラメータテーブルが発見されると、受信機２３０４０はＴＰＴサーバー２３０６０に新しいＴＰＴ又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
【０４４９】
コンテンツサーバー２３０７０は、両方向サービスを提供するために必要なアプリケーション及びＴＤＯを提供することができる。新しいアプリケーション又はＴＤＯが必要な場合、新しいアプリケーションは、ＴＰＴ又はアプリケーションパラメータテーブルにあるＵＲＬを用いてダウンロードすることができる。
【０４５０】
シグネチャー抽出機２３０８０は、放送局２３０１０からメタデータを受信することができる。シグネチャー抽出機２３０８０は、受信されたメタデータからフレームのシグネチャーを抽出することができる。ＦＰサーバー２３０９０に伝送されたフィンガープリントがシグネチャー抽出機２３０８０のシグネチャーとマッチングされると、シグネチャー抽出機２３０８０は、シグネチャーと関連したメタデータをＦＰサーバー２３０９０に伝達することができる。
【０４５１】
ＦＰサーバー２３０９０は、シグネチャー抽出機２３０８０とシグネチャーマッチング動作を行うことができる。ＦＰサーバー２３０９０は、シグネチャーを受信機２３０４０から受信されたフィンガープリントとマッチングさせることができる。シグネチャーがフィンガープリントとマッチングされると、ＦＰサーバー２３０９０は、シグネチャー抽出機２３０８０からシグネチャーと関連したメタデータを受信することができる。ＦＰサーバー２３０９０はメタデータを受信機２３０４０に伝送することができる。
【０４５２】
フィンガープリンティング（ＦＰ）技法において、ＦＰクライアント２３０５０は、オーディオ又はビデオフレームからフィンガープリント（シグネチャーと呼ぶこともできる。）を抽出し、多重の放送局からの放送フレームに対するフィンガープリントデータベースに対してこのフィンガープリントを検査し、受信機２３０４０が必要とする情報を探すことができる。このような検査は、遠く離れたサーバーに対するシグネチャーによってなされてもよく、所望の情報を有する記録を受けることができ、一部の場合は、受信機２３０４０にダウンロードされたシグネチャーのデータベースに対して検査することによって検査がなされてもよい。ここで、遠く離れたサーバーは、ＦＰサーバー２３０９０であってもよい。
【０４５３】
ウォーターマーキングとフィンガープリンティングは互いに区別される技術であるが、必ずしも互いに排他的なものではない。これらの両技術の組合せを用いることも考えることができる。自動コンテンツ認知（ａｕｔｏｍａｔｉｃ  ｃｏｎｔｅｎｔ  ｒｅｃｏｇｎｉｔｉｏｎ；ＡＣＲ）は、これらの両技術のいずれか一方を別途に指したり、又はこれらの両技術の組合せを指すために用いることができる。
【０４５４】
受信機が放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる環境を“ＡＣＲ環境”と呼ぶ。
【０４５５】
ＷＭの場合もＦＰの場合も、受信機は、トリガーを含む両方向サービスコンテンツを得るための出発点としてＵＲＬを用いることができる。
【０４５６】
ＷＭ、ＦＰの両方の場合とも、インターネットを介して伝達されたトリガーの活性化タイムスタンプなどのように、当該チャネルに対して時間臨界的（ｔｉｍｅ  ｃｒｉｔｉｃａｌ）イベントの放送側クロック（ｂｒｏａｄｃａｓｔ  ｓｉｄｅ  ｃｌｏｃｋ）に対するタイムスタンプの形態であってもよい。
【０４５７】
放送局は、一般にアンテナからＴＶ信号を受ける受信機のために放送ストリームでの両方向サービスの直接伝達を支援でき、非圧縮されたオーディオ及びビデオを受ける受信機のために、前述した通り、インターネットを通した両方向サービスの伝達を支援するものの、インターネット接続を有することができると仮定する。しかし、放送局は、この２つの伝達メカニズムのいずれか一方のみ支援できる。
【０４５８】
ウォーターマークがコード値のみを提供する場合、ウォーターマーキング技法のための代表的なアーキテクチャは、図２２及び図２３の２つのアーキテクチャの組合せのように見える。図２２のようにウォーターマーク挿入部が存在するようになるが、この挿入部は、受信機が必要とする情報ではなくコードを挿入する。また、図２３のＦＰサーバーと同じ役割を担うＷＭサーバーが存在する。受信機は、このサーバーにシグネチャーではなくコードを送り、これら受信機が必要とする情報を受ける。
【０４５９】
両方向サービス接近について説明する。
【０４６０】
両方向サービス接近についての説明は、直接実行モデル、ＡＣＲサーバーに独立的な活性化を有するＴＤＯモデル、ＡＣＲサーバーから受信された活性化を有するＴＤＯモデルについての説明を含む。モデルを示してはいないが、モデルは、説明に限定されず、設計者の意図によって変更されてもよい。
【０４６１】
放送局選択とＡＣＲシステムの特性によってＡＣＲ環境にある受信機が両方向サービスに接近できる方法には、様々なものがある。両方向サービスモデルは、直接実行モデル又はＴＤＯモデルであり、ＴＤＯモデルの場合、活性化とトリガーは、ＡＣＲサーバーに独立して又はＡＣＲサーバーによって伝達することができる。
【０４６２】
直接実行モデルについて説明する。
【０４６３】
直接実行モデルを有する両方向サービスを含む仮想チャネルのためのＡＣＲ過程は、このチャネルを見ている受信機に、ｍｅｄｉａ＿ｔｉｍｅ（“ｍ＝”）項とｃｏｎｔｅｎｔ＿ｉｄ（“ｃ＝”）項を含む時間ベーストリガーに相応するものを提供することができる。これらのトリガーは、直接実行モデルを有する両方向サービスのためのトリガーと確認できる。
【０４６４】
まず、受信機が新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するこのようなトリガーを受信すると、そのブラウザーに、トリガーのｌｏｃａｔｏｒ＿ｐａｒｔが指す宣言的客体（ＤＯ）をローディングすると考えることができる。一般に、ＤＯは、あらかじめ設置されていたり、あらかじめダウンロードされてキャッシュに格納されたりする。そうでなければ、受信機がＨＴＴＰ ＧＥＴ要求を用いてＤＯをダウンロードすると考えることもできる。
【０４６５】
その後、ＤＯは、適宜のバックエンドサーバーと連絡して、バックエンドサーバーが指示する両方向サービスを提供することができる。
【０４６６】
受信機は、ＡＣＲサーバーから新しいｌｏｃａｔｏｒ＿ｐａｒｔを有する及び／又はＴＤＯモデルを有する両方向サービスのためのトリガーとして確認されるトリガーを得るまで（これらのいずれか一つの場合は、一般的にチャネルの変更を指示する）取得された初期トリガーと続くトリガーをＤＯが利用できるようにするものと考えることができる。
【０４６７】
以下、ＡＣＲサーバーに独立した活性化を有するＴＤＯモデルについて説明する。
【０４６８】
ＴＤＯモデルを有する両方向サービスを含むことができ、ＡＣＲサーバーと独立してイベント活性化を提供する仮想チャネルのためのＡＣＲ過程は、ｍｅｄｉａ＿ｔｉｍｅ（“ｍ＝”）項を含み得る時間ベーストリガーに相応するものを、このチャネルを見ている受信機に提供することができる。これらのトリガーは、ＴＤＯモデルを有する両方向サービスのためのトリガーと確認できる。
【０４６９】
まず、受信機が新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するこのようなトリガーを受信すると、当該トリガーのｌｏｃａｔｏｒ＿ｐａｒｔが指し得るＴＰＴサーバーで現在のＴＤＯパラメータテーブル（ＴＰＴ）を検索し、このトリガー及び続くトリガー内のメディア時間を用いて、ＡＣＲ過程によって識別されうるオーディオ又はビデオフレームに対してイベント活性化のための基準時間ベースを設定すると考えることができる。
【０４７０】
ＡＭＴ（活性化メッセージテーブル）がＴＰＴと併せて伝達される場合、受信機は、トリガー内のメディア時間によって設定された時間ベースを基準に正確な時間にイベントを活性化させるためにこのテーブル内のそれぞれの活性化エレメントを使用すると考えることができる。（これらのイベントは、ＴＤＯＤＭＬローディング及び実行、ＴＤＯが同期化される特定動作を行うようにすること、ＴＤＯを中止させること、などを含むことができる。）
【０４７１】
ＴＰＴにＬｉｖｅＴｒｉｇｇｅｒエレメントが含まれた場合、受信機はＬｉｖｅＴｒｉｇｇｅｒエレメントでシグナリングされたポーリング方法を用いてＬｉｖｅＴｒｉｇｇｅｒエレメント内のＵＲＬによって識別されたライブトリガーサーバーから活性化トリガーを検索し、この活性化トリガーを用いて、このトリガー内のメディア時間項によって設定された時間ベースを基準に、正確な時間にイベントを活性化させることができる。
【０４７２】
ＡＭＴとライブトリガーサーバーの両方とも同一のサービスのために用いることができるが、前者は静的活性化を提供し、後者は動的活性化を提供する。これと違い、セグメントの全ての活性化が静的活性化である場合は、ＡＭＴのみを用いてもよく、ライブトリガーサーバーのみを用いて静的活性化及び動的活性化の両方を伝達してもよい。
【０４７３】
ＡＣＲサーバーから受信された活性化を有するＴＤＯモデルについて説明する。
【０４７４】
ＴＤＯ両方向サービスモデルのための活性化トリガーが、ＡＣＲ環境において、別途のトリガーサーバー無しでどのように伝達されるかについて記述する。
【０４７５】
フィンガープリンティングＡＣＲシステムは、ＡＣＲサーバーを含むことができる。受信機は、ＡＣＲサーバーにフレームシグネチャーを送ることができ、ＡＣＲサーバーは、当該シグネチャーが示すフレームを識別して、再び受信機で必要とする情報を送ることができる。ウォーターマークが、受信機で必要とする情報を得るためにＡＣＲサーバーに伝達され得るコードのみで構成された場合、ウォーターマーキングＡＣＲシステムはＡＣＲサーバーを含むことができる。ウォーターマーク自体が受信機で必要とする情報を含む場合、ウォーターマーキングＡＣＲシステムはＡＣＲサーバーを含まなくてもよい。ＡＣＲサーバーを含むＡＣＲシステムでは、サーバーと受信機間の通信に互いに異なる２つのモデル、すなわち、要求／応答モデルとイベント主導型モデルを用いることができる。
【０４７６】
放送局でＴＤＯ両方向モデル（ＴＤＯ  ｉｎｔｅｒａｃｔｉｏｎ  ｍｏｄｅｌ）を支援していると仮定する。
【０４７７】
要求／応答モデルを用いるＡＣＲサーバー、イベント主導型モデルを用いるＡＣＲサーバー、情報を直接挿入するウォーターマーキングＡＣＲシステムのような３つの場合を想定することができる。
【０４７８】
ＡＣＲサーバーがある場合、ＡＣＲ方式は、フィンガープリンティングであってもよく、この場合、受信機は一種のオーディオ又はビデオフレームのシグネチャー（又は、フィンガープリント）を算出し、識別のためにそれらをＡＣＲサーバーに提出する。又は、ＡＣＲ方式がウォーターマーキングであってもよく、この場合、受信機はオーディオ又はビデオフレームからウォーターマーク形態のコードを抽出し、これらのコードを識別のためにＡＣＲサーバーに提出する。
【０４７９】
便宜のためにフィンガープリンティングシグネチャーの用語を説明する。ただし、システムはウォーターマーキングコードの場合と同一の方式で動作し、本発明はフィンガープリンティングに限定されない。
【０４８０】
図２４は要求／応答ＡＣＲ場合の静的活性化の一実施例を示す図である。
【０４８１】
ＡＣＲサーバーが要求／応答モデルを使用する場合について説明する。
【０４８２】
要求／応答ＡＣＲモデルで、受信機は周期的に（例えば、５秒ごとに（これは、例示に過ぎず、設計者によって変更されてもよい））コンテンツのシグネチャーを生成し、シグネチャーを含む要求をＡＣＲサーバーに送ると考えることができる。ＡＣＲサーバーは、受信機から要求を受けると応答を送ることができる。要求／応答インスタンス間には通信セッションが開放状態に維持されない。このモデルでは、ＡＣＲサーバーが受信機にメッセージを開始することが不可能であってもよい。
【０４８３】
この要求／応答モデルを用い、受信機に活性化トリガーを伝達するＡＣＲサーバーの場合、ＡＣＲサーバーからの各応答は、ヌル（Ｎｕｌｌ）、時間ベーストリガー又は活性化トリガーのうち一つであってもよい。
【０４８４】
ヌル応答は、シグネチャーが認識されないことを示したり、又は、（ＡＣＲインジェストモジュール（ＡＣＲ  Ｉｎｇｅｓｔ  Ｍｏｄｕｌｅ）がフレームに対するシグネチャーを両方向サービスのないプログラムセグメントに含める場合に）シグネチャーは関連している両方向サービスのないセグメントに属するフレームを意味することを示すことができる。ＡＣＲインジェストモジュールについては後述する。
【０４８５】
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用いてメディア時間クロック（ｍｅｄｉａ−ｔｉｍｅ  ｃｌｏｃｋ）を維持すると考えることができる。
【０４８６】
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間は、トリガー内の“ｔ＝”項によって示される。
【０４８７】
受信機は、新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するトリガーを受ける度に、以前のＴＰＴと共に伝達されたＵＲＬＬｉｓｔを用いて新しいＴＰＴが検索されていないと、それを直ちにダウンロードすると考えることができる。
【０４８８】
受信機は、活性化トリガーを受ける度に、メディア時間クロックに対して当該トリガー内の“ｔ＝”項によって示された時間に、当該イベントを活性化させると考えることができる。
【０４８９】
図２４は、静的活性化に対して（ＡＣＲシステムが予定よりも十分に早く動的活性化について知っている場合は動的活性化に対して）、この方式がどのように作用するかを示している。
【０４９０】
図２４で、受信機は、ＡＣＲサーバーでメディア時間ＭＴ１、ＭＴ２及びＭＴ３を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間ＭＴ１を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。メディア時間ＭＴ２を有するフレームの場合、静的活性化がメディア時間Ｍｔａに予定され、受信機は“ｔ＝ＭＴａ”項を有する活性化トリガーを含む応答を受ける。メディア時間ＭＴ３を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。
【０４９１】
受信機が同一のイベント活性化に対して一つ以上の活性化トリガーを受信する場合が発生しうる。しかし、これらのそれぞれに対するメディア時間は同一であるため、受信機はそれらの活性化トリガーが重複していると把握し、これらのうち一つのみを適用することができる。
【０４９２】
図２５は、要求／応答ＡＣＲケースにおける静的活性化の一実施例を示す図である。
【０４９３】
ＡＣＲサーバーが要求／応答モデルを使用する場合について説明する。
【０４９４】
図２５で、受信機は、ローカルクロック（ｌｏｃａｌ  ｃｌｏｃｋ）時間ＬＣ１、ＬＣ２、ＬＣ３で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間ＬＣ１に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ１であると判断でき、受信機は、ｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。ローカルクロック時間ＬＣ２に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ２であると判断でき、ＡＣＲサーバーは、メディア時間Ｍｔａに静的活性化が予定されていることを知っているため、ＡＣＲサーバーは、この活性化のための活性化時間ＭｔａがＭＴ２以降の＜オフセット＞時間であることを意味する“ｄ＝＜ｏｆｆｓｅｔ＞”項を有する活性化トリガーを含む応答を伝達する。すると、受信機は＜オフセット＞を時間ＬＣ２に追加し、当該イベントを活性化させるべきローカル時間であるＬｃａを得る。
【０４９５】
図２６は、要求／応答ＡＣＲケースにおける動的活性化の一実施例を示す図である。
【０４９６】
以下、要求／応答ＡＣＲの場合において動的活性化が起きる場合について説明する。
【０４９７】
あらかじめ受信機にトリガーを送るには手遅れになるまでずっと、ＡＣＲシステムでイベント活性化について知っていない状況での動的活性化の場合には、ＡＣＲサーバーが次の要求があるまで待ってから活性化トリガーを送らなければならない。このような場合を図２６に示す。そのため、一つの要求区間だけ動的活性化が遅延されうる。
【０４９８】
図２６で、受信機は、ＡＣＲサーバーでメディア時間ＭＴ１、ＭＴ２及びＭＴ３を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間ＭＴ１及びＭＴ２を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。活性化時間Ｍｔａを有する動的活性化がメディア時間ＭＴａで又は直前に登場する場合、ＡＣＲサーバーは、メディア時間ＭＴ３を有するフレームに対して発生する受信機からの次の要求があるまで、受信機にそれを通知することができない。このとき、ＡＣＲサーバー応答は、活性化時間ＭＴａ（やや去の時間）を有する活性化トリガーを含む。このような状況で、受信機は、その応答が到達すると直ちに当該活性化トリガーを適用すると考えることができる。
【０４９９】
ここで、受信機は、同一のイベント活性化に対して一つ以上の活性化トリガーを受信することが可能である。しかし、それらのそれぞれのメディア時間は同一であるため、受信機はそれらが重複したと把握し、それらのうち一つのみを適用できる。
【０５００】
図２７は、要求／応答ＡＣＲケースにおける動的活性化の一実施例を示す図である。
【０５０１】
要求／応答ＡＣＲケースにおいて動的活性化が起きる場合について説明する。
【０５０２】
図２７で、受信機は、ローカルクロック時間ＬＣ１、ＬＣ２、ＬＣ３で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間ＬＣ１に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ１であると判断でき、受信機はｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。ローカルクロック時間ＬＣ２に見られたフレームに対するｍｅｄｉａ＿ｔｉｍｅはＡＣＲサーバーによってＭＴ２であると判断でき、ＡＣＲサーバーは、メディア時間Ｍｔａに動的活性化が登場する予定であることを知っておらず、受信機は、ｍｅｄｉａ＿ｔｉｍｅ又はｅｖｅｎｔ＿ｔｉｍｅのないトリガーを含む応答を受信する。動的活性化がメディア時間Ｍｔａに登場すると、ＡＣＲサーバーは、ローカル時間ＬＣ３に発生する受信機からの次の要求があるまで、受信機にそれに対して通知することができない。このとき、ＡＣＲサーバー応答は、負の＜オフセット＞値を有する活性化トリガー又は“今施行”の活性化トリガーを含むことができる。
【０５０３】
イベント主導型モデルを使用するＡＣＲサーバーについて説明する。
【０５０４】
イベント主導型ＡＣＲモデルで、受信機はＡＣＲサーバーに対する永久的な接続を開始し、周期的に（例えば、５秒ごとに）コンテンツのシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ＡＣＲサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ＡＣＲサーバーはいつでもクライアントに対するメッセージを開始することができる。
【０５０５】
該イベント主導型モデルを使用し、活性化を受信機に伝達するＡＣＲサーバーに対して、次の規則はＡＣＲサーバーからのメッセージを申し込むことができる。
【０５０６】
第一に、ＡＣＲサーバーは、新しいセグメントに対応する受信機からシグネチャーを受信すると、単に受信機が関連のＴＰＴを取得できるようにするために、直ちに時間ベーストリガーを受信機に送ることができる。
【０５０７】
第二に、イベントが活性化される予定である度に、ＡＣＲサーバーは活性化トリガーを受信機に送ることができる。可能ならば、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる（これは、要求／応答モデルにおける動作と略同様である）。ＡＣＲサーバーは、活性化をあまりにも遅く知って活性化トリガーを事前に早く送ることができなくても（これは、動的イベント活性化の場合に発生しうる）、活性化トリガーを可能な限り早く送ることができる。後者の場合に、メッセージ遅延によってクライアントは活性化時期よりもやや遅れてメッセージを受けることができ、この場合、受信機はメッセージを受け次第イベントを活性化すると考えることができる。
【０５０８】
受信機は、新しいｌｏｃａｔｏｒ＿ｐａｒｔを有するトリガーを受信する度に、以前のＴＰＴと一緒に伝達されるＵＲＬＬｉｓｔを用いて既に検索していない限り、新しいＴＰＴを直ちにダウンロードすると考えることができる。
【０５０９】
情報を直接挿入するウォーターマーキングＡＣＲシステムについて説明する。ウォーターマーキングＡＣＲシステムを示してはいないが、ウォーターマーキングＡＣＲシステムは、次の説明に限定されず、設計者によって変更されてもよい。
【０５１０】
受信機が必要とする情報を直接挿入するウォーターマーキングシステムの場合、フレームと関連しているウォーターマークは、このフレームに対して要求／応答ＡＣＲサーバーがリターンすることについて、前述したのと同じ規則を、次のように従うことができる。要求／応答ＡＣＲサーバーは、ヌル、時間ベーストリガー、活性化トリガーのうち一つをリターンすることができる。
【０５１１】
ヌル応答は、シグネチャーが認識されないことを示したり、又は（ＡＣＲインジェストモジュールがフレームに対するシグネチャーを両方向サービスのないプログラムセグメントに含める場合）シグネチャーは関連した両方向サービスのないセグメントに属するフレームを意味することを示すことができる。
【０５１２】
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用い、メディア時間クロックを維持すると考えることができる。
【０５１３】
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間はトリガー内の“ｔ＝”項によって示される。
【０５１４】
ＡＣＲサーバーが必要とされないように、受信機が必要とする情報をウォーターマークに直接含めて伝達するウォーターマーキングＡＣＲシステムの場合、インジェストモジュールは、各フレームと関連付けるトリガーを決定し、このトリガーをデータベース内の該当フレームと関連付けずに当該フレームのためのウォーターマークに含める要求／応答サーバーモデルについて、前述したのと同じ規則に従うことができる。インジェストモジュールとデータベースについては後述する。
【０５１５】
独立型ＮＲＴサービスの支援について説明する。これを示してはいないが、本発明は、次の説明に限定されず、設計者によって変更されてもよい。
【０５１６】
ＡＣＲ環境にある受信機が独立型ＮＲＴサービスを受けるために、放送局は、ＮＲＴサービスへのインターネット接続を支援する必要があり、受信機は、それらのサービスに対するＳＭＴとＮＲＴ−ＩＴインスタンスを得る必要がありうる。
【０５１７】
インターネットを介してＰＳＩＰテーブルとＮＲＴテーブルを得るための質疑（ｑｕｅｒｙ）プロトコルについて説明する。
【０５１８】
放送局は、特定放送ストリームに対してこのプロトコルを支援し、このとき、この放送ストリームに対する放送局のシグナリングサーバーのＵＲＬを知っている受信機は、次の段階を行う。
【０５１９】
第一に、受信機は、指定された未来時間区間（例：次の時間）に当該放送ストリームのためのテーブルの“基本ＮＲＴ集合”に対して質疑を発生させることができる。
【０５２０】
第二に、上記の段階で各独立型ＮＲＴ仮想チャネルに対するＳＭＴ及びＩＬＴ、並びに指定された時間区間を含むＮＲＴ−ＩＴ及びＴＦＴインスタンスを生成する。
【０５２１】
受信機が放送ストリームに対するシグナリングサーバーのＵＲＬを発見できる一つの方法は、この放送ストリーム内の両方向サービスセグメントのプロバイダが、ＴＰＴと併せて伝達されたＵＲＬＬｉｓｔエレメント内でシグナリングサーバーＵＲＬを提供するように選択することができる。
【０５２２】
受信機が放送ストリームに対するシグナリングサーバーのＵＲＬを発見できるもう一つの方法は、事前設定によるものであってもよい。ＤＴＶ受信機メーカーが、特定放送領域に到達するＡＣＲサーバーをどのように探すかを知るようにＤＴＶ受信機をあらかじめ設定するのと同じ方式で、ＤＴＶ受信機メーカーが、特定放送領域に到達する“ＮＲＴ発見サーバー”をどのように探すかを知るようにＤＴＶ受信機をあらかじめ設定することができる。このようなＮＲＴ発見サーバーは、各放送ストリームに対するシグナリングサーバーＵＲＬと共に、独立型ＮＲＴサービスを含む放送ストリーム目録を受信機に提供することができる。
【０５２３】
図２８は、ＡＣＲサーバー活性化のためのアーキテクチャの一実施例を示す図である。
【０５２４】
あるＡＣＲシステムはＡＣＲサーバーを含み、あるＡＣＲシステムは含まない。フィンガープリンティングＡＣＲシステムでは、受信機はフレームシグネチャーを算出してＡＣＲサーバーに送ることができ、ＡＣＲサーバーは、受信機で必要とする情報を送る。したがって、フィンガープリンティングＡＣＲシステムは、ＡＣＲサーバーを含む。ウォーターマーキングＡＣＲシステムでは、ウォーターマークにフレームを固有に識別するコードのみが含まれてもよく、又は受信機が必要とする全体情報が含まれてもよい。ウォーターマークがコードのみを含む場合は、受信機がコードを抽出し、それらをＡＣＲサーバーに送ることができ、ＡＣＲサーバーは、受信機で必要とする情報を送る。ウォーターマークが全体情報を含む場合は、受信機が自分に必要な情報をウォーターマークから直接抽出でき、ＡＣＲサーバーが必要でない。
【０５２５】
ＡＣＲサーバーを含むＡＣＲシステムでは、ＡＣＲサーバーと受信機間の通信のために２種類の互いに異なるモデル、すなわち、要求／応答モデルとイベント主導型モデルを共通に使用することができる。
【０５２６】
要求／応答ＡＣＲサーバーモデルにおいて、受信機は周期的に（例えば、５秒ごとに）コンテンツのシグネチャーを算出したりコンテンツからコードを抽出し、このシグネチャーやコードが含まれた要求をＡＣＲサーバーに送ると考えることができる。ＡＣＲサーバーは受信機から要求を受信すると、応答をリターンすることができる。要求／応答インスタンス間には通信セッションが開いた状態で維持されない。このモデルでは、ＡＣＲサーバーが受信機にメッセージを開始することが実行可能でなくてもよい。
【０５２７】
処理しているチャネルの放送局がＴＤＯ両方向モデルを支援すると仮定する。
【０５２８】
２種類の一般的な類型のイベント活性化、すなわち、セグメントの放送が開始される前に活性化時間が知らされる静的活性化と、セグメントの放送中に活性化時間が動的に決定される動的活性化がありうる。あらかじめ記録されたセグメントでは、全てのイベント活性化が静的であってもよい。ライブショーを放送するセグメントでは、イベント活性化の一部又は全てが動的であってもよい。静的活性化は活性化トリガーの形態で受信機に伝達されてもよいが、一般的に活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ  Ｍｅｓｓａｇｅｓ  Ｔａｂｌｅ、ＡＭＴ）に記載される。動的活性化は、これらのタイミングがＡＭＴの発生時点に知らされないため、活性化トリガーの形態で伝達されてもよい。
【０５２９】
図２８は、ＡＣＲサーバーを使用するＡＣＲシステムを支援するアーキテクチャを示している。これは論理構成図であって、実行アーキテクチャではない。例えば、ＡＣＲインジェストモジュールは、放送ソースと同じ位置にあってもよく、別途の位置にあってもよい。
【０５３０】
ＡＣＲサーバーを使用するＡＣＲシステムを支援するアーキテクチャにおいて、アーキテクチャは、放送ソース２８０１０、ＡＣＲインジェストモジュール２８０２０、ＭＶＰＤ ２８０３０、ＳＴＢ ２８０４０、受信機２８０５０、ＡＣＲクライアント２８０６０、ＡＣＲ設定サーバー２８０７０、ＡＣＲサーバー２８０８０及びデータベース２８０９０で構成することができる。
【０５３１】
放送ソース２８０１０は、Ａ／Ｖストリーム及び関連した両方向サービスが送出される地点であって、例えば、ネットワーク分配地点又はＴＶ放送局であってもよい。
【０５３２】
ＡＣＲインジェストモジュール２８０２０は、フィンガープリンティングＡＣＲシステムの場合、フレームのシグネチャー（フィンガープリント）を算出したり、コードに基づくウォーターマーキングＡＣＲシステムの場合、コードからなるウォーターマークをフレームに挿入することができる。このモジュールは、他のメタデータと併せてシグネチャー又はコードに関連している各フレームのｍｅｄｉａ＿ｔｉｍｅをデータベース２８０９０に保存することができる。ＡＣＲインジェストモジュール２８０２０は、一つの放送ストリーム、全体放送ストリーム、又は複数の放送ストリーム又はこれらの組合せにおいて単一チャネルを扱うことができる。そのために、ＡＣＲインジェストモジュール２８０２０は、両方向サービスを含むプログラムセグメントのためのフレームを処理すると仮定する。しかし、全てのフレームが処理されるが、両方向サービスを有するセグメントの一部でないものは、これらが両方向サービスを有するセグメントの一部でないことを示す指示子がデータベース２８０９０エントリにあるＡＣＲシステムも可能である。
【０５３３】
ＭＶＰＤ ２８０３０は一般に、ケーブル事業者、衛星事業者又はＩＰＴＶ事業者である。ＭＶＰＤ ２８０３０は、ウォーターマーキングＡＣＲシステムの場合、ＡＣＲインジェストモジュール２８０２０によって挿入されたウォーターマークと共に放送ストリームをいずれかの方式で放送ソースから受信することができる。このようなシステムはたびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のＳＴＢ ２８０４０に送る。
【０５３４】
ＳＴＢ ２８０４０は一般にオーディオ及びビデオをデコーティング（圧縮解除）し、これらを、視聴者に視聴されるＴＶ受像機に送る。両方向サービストリガーを含むＤＴＶクローズドキャプションサービス＃６は、ＴＶ受像機が利用できないと仮定する。
【０５３５】
受信機２８０５０は、ＡＣＲクライアント２８０６０を含むことができる。ＡＣＲクライアント２８０６０は、受信機２８０５０の外部に位置してもよい。受信機２８０５０の構造については後述する。
【０５３６】
受信機２８０５０内のＡＣＲクライアント２８０６０は、当該用途のＡＰＩを用いてＡＣＲサーバー２８０８０から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、ＡＣＲクライアント２８０６０は受信機２８０５０内に構成されるが、他の構成図可能である。
【０５３７】
ＡＣＲ設定サーバー２８０７０は、ＡＣＲクライアント２８０６０が適切なＡＣＲサーバー２８０８０の位置を決定する方式を提供することができる。この発見過程は他の方式で得ることもできる。
【０５３８】
ＡＣＲサーバー２８０８０は、受信機からシグネチャー又はコードを受け、適切な時点に活性化トリガーをリターンすることができる。
【０５３９】
データベース２８０９０は、ＡＣＲサーバー２８０８０の使用のためにオーディオ又はビデオフレームのいずれか一方（又は、両方）に関する情報が格納される一種のデータ格納所であって、厳密にはデータベースでなくてもよい。
【０５４０】
ウォーターマーク内の情報の直接伝達を用いるＡＣＲシステムのアーキテクチャは、データベースとＡＣＲサーバーを有しなくてもよい。ＡＣＲインジェストモジュールは、情報をフレームの識別子及びこれらと関連している情報を含むデータベース記録に挿入する代わりに、ウォーターマークの形態で放送ストリーム内のフレームに直接挿入してもよい。その後、受信機はその情報をＡＣＲサーバーから取得せず、放送内のフレームから抽出することができる。
【０５４１】
以下、要求／応答ＡＣＲサーバーを介した活性化トリガーの伝達について段階別に説明する。
【０５４２】
このＡＣＲサーバーの挙動を具現する効果的な方法は、以下に説明する過程に従うものであるが、この過程の動作の数は、上記のアーキテクチャダイヤグラムである図２８内の数字に対応する。
【０５４３】
１）両方向サービスセグメントとＡＭＴ又は各セグメントに相当するものに対する放送スケジュールを、セグメントが放送される前にあらかじめＡＣＲインジェストモジュールに伝達することができる。放送スケジュールは、セグメントＩＤ、関連する両方向サービスを含み得る各セグメントのＧＰＳ開始時点及びＧＰＳ終了時点を含むことができる。放送スケジュールに最後の瞬間の変化がある場合、ＡＣＲインジェストモジュールにそれらの変化が直ちに通知されてもよい。放送スケジュールは、各セグメントに対するＴＰＴのバージョンナンバーも含むことができ、ＴＰＴバージョンのスケジュールされていない変更は、実時間でＡＣＲインジェストモジュールに通知され、必要時に“ｖｅｒｓｉｏｎ”（“ｖ＝”）項をトリガーに挿入することができる。インジェストモジュールは、各セグメントの開始時に特定区間（多数の受信機が新しいＴＰＴを同時に要求する可能性がある時）のように適切な時間に“ｓｐｒｅａｄ”（“ｓ＝”）項をトリガーに挿入するように構成されてもよい。
【０５４４】
２）動的活性化が存在する場合、動的活性化のソースからＡＣＲインジェストモジュールにリンクが設定されてもよい。
【０５４５】
３）放送ストリームはＡＣＲインジェストモジュールに送信されてもよい。
【０５４６】
４）ＡＣＲインジェストモジュールは、フレームからシグネチャーを抽出したり（フィンガープリントＡＣＲシステムの場合）、関連している両方向サービスを持つセグメントに含まれた全てのフレームに対してコードをフレームに挿入（ウォーターマークＡＣＲシステムの場合）することができる。（ＡＣＲインジェストモジュールは、ＧＰＳクロックと放送スケジュール内のセグメントの開始時間及び終了時間を用いてフレームがそのようなセグメントにあるかを判断できる。）そのような各フレームに対してＡＣＲインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連しているコードを含み得るデータベースに記録を挿入することができる。トリガーが挿入されることに関する規則は、過程上、このような動作リストの終端に記述される。
【０５４７】
５）放送ストリームは、ＭＶＰＤに続いてもよい。
【０５４８】
６）ＭＶＰＤ加入者の位置にあるＳＴＢに放送ストリームを送信できる。（一般に、両方向コンテンツはまず除く。）
【０５４９】
７）ＳＴＢは、Ａ／Ｖをデコーティングして非圧縮されたＡ／ＶをＤＴＶ受信機に送ることができる。
【０５５０】
８）まず、受信機がＯＮになると、受信機は自身の位置をＡＣＲ設定サーバーに送ることができる。（ＡＣＲ設定サーバーのＵＲＬは、この受信機内に構成されてもよい。）
【０５５１】
９）ＡＣＲ設定サーバーは、受信機が使用するＡＣＲサーバーのＵＲＬを送ることができる。
【０５５２】
１０）受信機内のＡＣＲクライアントは、フィンガープリントシグネチャー又はウォーターマークコードを抽出し、それらをＡＣＲサーバーに送ることができる。
【０５５３】
１１）シグネチャー又はコードを受信したＡＣＲサーバーは、データベース内でシグネチャー又はコードのマッチングを試みることができる。
【０５５４】
１２）シグネチャー又はコードがデータベースのいずれのシグネチャー又はコードともマッチングされないと、ＡＣＲサーバーは“ｎｏ ｍａｔｃｈ”指示子を受けることができる。シグネチャー又はコードがデータベース内のシグネチャー又はコードとマッチングされると、ＡＣＲサーバーは、マッチングされるシグネチャー又はコードを有するフレームに対する記録を受けることができる。後者の場合、データベース内の記録は時間ベーストリガーを含むことができ、及び／又はＡＣＲインジェストモジュールによってフレームの記録に何が挿入されたかによって一つ以上の活性化トリガーを含むことができる。
【０５５５】
１３）ＡＣＲサーバーがデータベースから“ｎｏ ｍａｔｃｈ”指示子を受けると、ＡＣＲクライアントにヌル応答をリターンすることができる。そうでない場合、ＡＣＲサーバーは、得られたたトリガー又はトリガーをＡＣＲクライアントにリターンすることができる。
【０５５６】
下記の規則を用いて、ＡＣＲインジェストモジュールがどの一つ又は複数のトリガーをデータベース内の各フレーム記録に挿入するかを判断できる。
【０５５７】
図２９は、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
【０５５８】
受信機内の個別ＡＣＲクライアントによって使われた要求区間の長さ上に、ある上限（ｕｐｐｅｒ  ｂｏｕｎｄ）Ｌ１が存在すると仮定することができる。（ＡＣＲクライアントが実際にこの上限内で動作する限り、この境界を知っているかは重要でない。）Ｌ２をフレームが受信機に到達した時点から計算して、一般のＡＣＲクライアントがシグネチャーを算出したり、このフレームと関連しているウォーターマークを抽出するためにかかる時間の長さとしよう。メッセージがＡＣＲクライアントからＡＣＲサーバーに送られてから帰ってくるためにかかる一般的な往復移動時間をＬ３としよう。Ｍ＝Ｌ１＋Ｌ２＋Ｌ３とする。（ややより大きいＭの値が用いられもよい。−ややより大きい値の長所は、活性化トリガーに反応する上で若干の余分の時間を得るということである。短所は、受信機が同一のイベント活性化に対して複数の活性化トリガーを受ける可能性がややより高いということである。受信機は、後述するように、これらが重複することを感知し、活性化を１回のみ適用できるため、この短所は大きく問題にならない。）
【０５５９】
ＡＣＲインジェストモジュールは、次の３つの条件のうち少なくとも一つが成立しないと、時間ベーストリガーのみをフレームと関連している記録に挿入することができる。
【０５６０】
（ａ）活性化エレメントは、フレームのｍｅｄｉａ＿ｔｉｍｅが活性化エレメントのｓｔａｒｔＴｉｍｅ前の時間長さＭから始まって活性化エレメントのｅｎｄＴｉｍｅで終わる時間区間にあるようにＡＭＴに存在する。（活性化がｅｎｄＴｉｍｅを有しないと、ｅｎｄＴｉｍｅはｓｔａｒｔＴｉｍｅと同一のものと見なされる。）
【０５６１】
（ｂ）トリガーの活性化時間（“ｔ＝＜ｅｖｅｎｔ＿ｔｉｍｅ＞”）直前の時間長さＭの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。
【０５６２】
（ｃ）トリガーの活性化時間直前の時間長さＭの区間の開始よりも遅れて動的活性化トリガーがインジェストモジュールによって受信されており、フレームのｍｅｄｉａ＿ｔｉｍｅはトリガーの受信の直後の時間長さＬ１の区間に存在する。
【０５６３】
これらの条件（ａ）、（ｂ）及び（ｃ）のいずれか一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する“ｅ＝”項とＡＭＴ内の活性化エレメントのｓｔａｒｔＴｉｍｅを指示したり（条件（ａ）の場合）、動的トリガーのｅｖｅｎｔ＿ｔｉｍｅを指示する（条件（ｂ））“ｔ＝”項と共に記録に含まれうる。トリガーはバージョン（“ｖ＝”）項も含むことができる。
【０５６４】
もちろん、（ａ）の場合、ｓｔａｒｔＴｉｍｅからｅｎｄＴｉｍｅまでの区間を通じて続けて活性化トリガーをフレームと関連付ける理由は、この区間を通じてチャネルに参加する受信機をある程度受容するためである。
【０５６５】
この接近法は、ＡＣＲサーバー側に追加的な知能を要求しないという点に留意されたい。このサーバーは、単純にデータベースで発見する情報をＡＣＲクライアントにリターンする。全ての知能はＡＣＲインジェストモジュールに存在できる。しかも、ＡＣＲインジェストモジュールが行うべき演算が非常に簡単でありうる。
【０５６６】
この方式を用いると、受信機で同一のイベント活性化に対して一つ以上の活性化トリガー（互いに異なるフレームと関連しているトリガー）を受信することが可能である。しかし、受信機は、“ｔ＝”値から、それらのトリガーがいずれも同一の活性化時間を有することがわかるため、受信機はそれらが重複すると判断し、イベントを１回のみ活性化させることができる。
【０５６７】
上記の場合のうち二つの場合に、活性化トリガー内の“ｔ＝”項は、関連しているフレームのｍｅｄｉａ＿ｔｉｍｅより早いｅｖｅｎｔ＿ｔｉｍｅを有することができる。（ａ）状況で、活性化エレメントのｅｎｄＴｉｍｅがｓｔａｒｔＴｉｍｅよりも非常に遅いと、受信機は一般的にｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅの間の区間を通じて複数の活性化トリガーを受けることができ、これらはいずれも活性化時間としてｓｔａｒｔＴｉｍｅを有することができる。（ｃ）状況では、活性化のための活性化トリガーがあまりにも遅くフレーム記録に挿入され、受信機が受ける活性化トリガーが要求に対する応答として、活性化時間以降のｍｅｄｉａ＿ｔｉｍｅを有するフレームに対するシグネチャーと共にくることがある。受信機が、関連しているフレームのｍｅｄｉａ＿ｔｉｍｅよりも早いｅｖｅｎｔ＿ｔｉｍｅを有する活性化トリガーを受けると、このトリガーが既に確認して当該イベントの活性化のために使用した活性化トリガーと同じものと認識しない場合、当該イベントを直ちに活性化すると考えることができる。
【０５６８】
フレームのｍｅｄｉａ＿ｔｉｍｅがｅｖｅｎｔ＿ａｃｔｉｖａｔｉｏｎ ｔｉｍｅよりも遅い場合に“今施行”トリガーではなく過去のｅｖｅｎｔ＿ｔｉｍｅ値を用いる目的は、受信機がこのような“ａｆｔｅｒ ｔｈｅ ｆａｃｔ”活性化トリガーを一つ以上受けることができるためである。“ｔ＝”値は、受信機でこれらのトリガーがいずれも同一の活性化時間を有すると判断し、当該イベントを１回のみ活性化させ得るようにする。
【０５６９】
図２９は、ＡＭＴ内の活性化エレメントにｅｎｄＴｉｍｅ属性がない状況（ａ）と状況（ｂ）を説明する。
【０５７０】
図２９は、ＡＭＴ内の活性化エレメントがｅｎｄＴｉｍｅを有しないとき、上記の動作（４）での状況（ａ）の一例を示している。これは、ＡＣＲインジェストモジュールに活性化時間よりも少なくてもＭ時間単位以前に動的活性化トリガーが送られる上記の段階（４）での状況（ｂ）の例であってもよい。
【０５７１】
図２９は、タイムライン（ｔｉｍｅｌｉｎｅ）上にイベント活性化時間とこれよりも先行する長さＬ１、Ｌ２及びＬ３の区間を含む長さＭの区間を示している。タイムラインの下の垂直矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したり、イベント活性化時間後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さＭの区間内の各フレームは、データベースにおいて同図の下における２つの例（ｆ１、ｆ２）のような活性化トリガーと関連している。各フレームに対する“ｔ＝”項は、ｍｅｄｉａ＿ｔｉｍｅに対するイベント活性化時間を示すことができる。（丸囲みのｆ１、ｆ２で表示されている。）
【０５７２】
丸囲みの４つの垂直矢印は、一般の受信機が要求を送る時の例示である。この例で、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるようになるが、これらのトリガーは同一のイベント活性化時間を有するため、受信機はこれらを同一のものと認識し、最初のトリガーのみを適用する。受信機の要求間の間隔がＬ１未満であるため、受信機は図示のＬ１区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してＡＣＲサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例では、受信機が受ける一番目の活性化トリガーはあらかじめ伝達されるが、受信機が受ける二番目の活性化トリガーは、かろうじて間に合って到達する（このトリガーは重複トリガーである）。
【０５７３】
図３０は、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーの一実施例を示す図である。
【０５７４】
以下、ＥｎｄＴｉｍｅがない場合（ａ）と場合（ｂ）における活性化トリガーを説明する。これは、上記の図２９に関する説明に似ている。
【０５７５】
図３０は、ＡＭＴ内の活性化エレメントがｅｎｄＴｉｍｅを有しない場合に、上の動作（４）で状況（ａ）の例を示している。これは、ＡＣＲインジェストモジュールに活性化時間よりも少なくてもＭ時間単位以前に動的活性化トリガーが送られる上の段階（４）で状況（ｂ）の例である。
【０５７６】
図３０は、タイムライン（ｔｉｍｅｌｉｎｅ）上にイベント活性化時間とこれよりも先行する長さＬ１、Ｌ２及びＬ３の区間を含む長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーと関連している。長さＭの区間内の各フレームは、データベースで同図の下における２つの例と同一の活性化トリガーと関連している。各フレームに対する”ｄ＝”項は、このフレームとイベント活性化時間との時間の長さを示すことができる。（丸囲みのｆ１、ｆ２で表示されている）。
【０５７７】
丸囲みの４つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この例で、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるが、＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えて算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。受信機要求間の間隔がＬ１未満であるため、受信機は図示のＬ１区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してＡＣＲサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例で、受信機で受信された二番目の活性化トリガーは、活性化時間以降に到達する。
【０５７８】
図３１は、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
【０５７９】
図３１は、ＡＭＴ内の活性化エレメントがｓｔａｒｔＴｉｍｅの他、ｅｎｄＴｉｍｅも持つ場合に、上の動作（４）で状況（ａ）の例を示している。
【０５８０】
同図は、タイムライン上にイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ、及びｓｔａｒｔＴｉｍｅよりも先行する長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化のｅｎｄＴｉｍｅ後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さＭの区間内又はイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ間の各フレームは、データベースで同図の下における３つの例で示す形態で関連している活性化トリガーを有する。各フレームに対する“ｔ＝”項は、ｍｅｄｉａ＿ｔｉｍｅに対するイベント活性化時間を示ることができる。（丸囲みのｆ１、ｆ２、ｆ３で表示されている。）
【０５８１】
丸囲みの３つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して３つの活性化トリガーを受けるが、活性化時間が同一であるため、受信機はそれらを同一のものと認識し、最初のトリガーのみを適用する。
【０５８２】
もちろん、同図における最初の２つの活性化トリガーは、ｓｔａｒｔＴｉｍｅ以降にチャネルに参加して最初の要求と併せてフレームｆ３のシグネチャーを送る受信機にとっては認知できない。
【０５８３】
図３２は、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーの一実施例を示す図である。
【０５８４】
以下、ＥｎｄＴｉｍｅがある場合（ａ）における活性化トリガーを説明する。
【０５８５】
図３２は、ＡＭＴ内の活性化エレメントがｓｔａｒｔＴｉｍｅの他、ｅｎｄＴｉｍｅも有する場合に上の動作（４）での状況（ａ）の例を示している。
【０５８６】
同図は、タイムライン上にイベント活性化のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ、及びｓｔａｒｔＴｉｍｅよりも先行する長さＭの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーと関連している。長さＭの区間内の各フレームは、データベースで同図の下における２例で示す形態の活性化トリガーを有する。各フレームに対する“ｄ＝”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。（丸囲みの垂直矢印で示されている）。
【０５８７】
丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して３つの活性化トリガーを受けるが、＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えたり、（負の）＜ｄ３＞値をフレームｆ３に対する受信機のローカル時間に加えたりして算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。
【０５８８】
もちろん、図示の最初における２つの活性化トリガーは、ｓｔａｒｔＴｉｍｅ以降にチャネルに参加して最初の要求と併せてフレームｆ３のシグネチャーを送る受信機にとっては認知できない。
【０５８９】
図３３は、場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
【０５９０】
図３３は、活性化時間以前にＭ時間単位よりも遅くＡＣＲインジェストモジュールに動的活性化トリガーが送られる上記の動作（４）での状況（ｃ）を示している。
【０５９１】
図３３は、タイムライン上に、動的イベント活性化時間と、ＡＣＲインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図で、ＡＣＲインジェストモジュールでイベントの活性化を知る時間後に長さＬ１の区間が続く。タイムラインの下における垂直矢印は、個別フレームの時間を表す。長さＬ１の区間の開始よりも先行したり、長さＬ１の区間の終わりに続く各フレームは、データベースでこのフレームと関連している時間ベーストリガーを有する。長さＬ１の区間内の各フレームは、データベースで同図の下における例のような活性化トリガーを有する。各フレームに対する“ｔ＝”項は、メディア時間ラインに対するイベント活性化時間を示す。（丸囲みの垂直矢印で表示されている。）丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機はイベント活性化に対して一つの活性化トリガーを有する。活性化トリガーの活性化時間は、このトリガーを受信した時間前であるから、受信機はトリガーを受信すると直ちに適用する。
【０５９２】
図３４は、場合（ｃ）に対する活性化トリガーの一実施例を示す図である。
【０５９３】
以下、場合（ｃ）に対する活性化トリガーを説明する。これは、上記の図３３に関する説明に似ている。
【０５９４】
図３４は、活性化時間以前にＭ時間単位よりも遅くＡＣＲインジェストモジュールに動的活性化トリガーが送られる上記の動作（４）での状況（ｃ）を示している。
【０５９５】
図３４は、タイムライン上に、動的イベント活性化時間と、ＡＣＲインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図であり、ＡＣＲインジェストモジュールでイベントの活性化を知る時間後に長さＭの区間が続く。タイムラインの下における矢印は、個別フレームの時間を表す。長さＭの区間の開始よりも先行したり、長さＭの区間の終わりに続く各フレームは、データベースで＜ｍｅｄｉａ＿ｔｉｍｅ＞又は＜ｅｖｅｎｔ＿ｔｉｍｅ＞項のないトリガーを有する。長さＭの区間内の各フレームは、データベースで同図の下における２つの例のような活性化トリガーを有する。各フレームに対する“ｄ＝”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。（丸囲みの垂直矢印で表示されている。）丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は、同一のイベント活性化に対して２つの活性化トリガーを受けるが、（負の）＜ｄ１＞値をフレームｆ１に対する受信機のローカル時間に加えたり、（負の）＜ｄ２＞値をフレームｆ２に対する受信機のローカル時間に加えたりして算出した活性化時間はいずれも同一の結果を有するため、受信機はそれらを重複したものと認識し、受信した最初のトリガーのみを適用する。最初のトリガーの活性化時間は、それを受信した時間以前であるから、受信機はこのトリガーを受信すると直ちに適用する。
【０５９６】
図３５は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
【０５９７】
イベント主導型ＡＣＲモデルで、受信機は、ＡＣＲサーバーに対する持続的な接続を開始し、一定の間隔をおいて（例えば、５秒ごとに）フレームと関連したシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ＡＣＲサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ＡＣＲサーバーはいつでも持続的な接続を通してクライアントに対するメッセージを開始することができる。
【０５９８】
また、受信機からの最も最近の提出に対応するセグメントＩＤ（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞）及び受信機に送られる最近活性化トリガーのような各受信機に関する一定量の情報を維持することはサーバーにとって簡単である。
【０５９９】
当該イベント主導型モデルを使用し、活性化を受信機に伝達するＡＣＲサーバーに対して、次の規則はＡＣＲサーバーからのメッセージを申し込むことができる。
【０６００】
第一に、ＡＣＲサーバーは、新しいセグメントでのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のＴＰＴを取得できるようにするために、直ちに時間ベーストリガーと共にメッセージを受信機に送ることができる。
【０６０１】
第二に、ＡＣＲサーバーは（受信機が見た最も最近のバージョンとは異なる）ＴＰＴに対する新しいバージョンナンバーを有するセグメントの一部でのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のＴＰＴの新しいバージョンを取得できるようにするために、直ちに”ｖ＝”項を有する時間ベーストリガーと共にメッセージを受信機に送ることができる。
【０６０２】
第三に、イベントが活性化される予定である場合、ＡＣＲサーバーは活性化トリガーを受信機に送ることができる。可能ならば、メディア時間ラインと関連した活性化時間を示すために活性化トリガーでの”ｔ＝”項と共に、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる（これは、要求／応答モデルでの動作と略同様である）。ＡＣＲサーバーは、活性化をあまりにも遅く知って活性化トリガーを平素より遥かに早く送ることはできなくても、活性化を知るとできるだけ早く活性化トリガーを送ることができる。（後者の場合に、受信機は、活性化時期後に活性化トリガーを受けることができ、この場合、受信機は活性化トリガーを受け次第イベントを活性化すると考えることができる。）
【０６０３】
図２８に示した要求／応答ケースに対するアーキテクチャも、一つの差異点以外は、当該イベント主導型ケースに適している。その差異点は、イベント主導型ケースにおいて新しいアクション（２ａ）がありうるということである。動的活性化トリガーが存在すると、ＡＣＲインジェストモジュールが選択された動的活性化トリガーをＡＣＲサーバーに送ることができるように、ＡＣＲインジェストモジュールとＡＣＲインジェストモジュールによって実装されたデータベースを使用する全てのＡＣＲサーバーとの間に接続が設定されてもよい。
【０６０４】
イベント主導型ケースに対する番号付きアクションは、要求／応答ケースと類似可能である。新しいアクション（２ａ）の他に、アクション（４）がすこし異なり、アクション（１３）がすこし異なり、新しいアクション（１４）が追加される。
【０６０５】
アクション（４）で、ＡＣＲインジェストモジュールはフレームからシグネチャーを抽出したり（フィンガープリントＡＣＲシステムの場合）、又は関連した両方向サービスを有するセグメントに含まれた全てのフレームに対してコードをフレームに挿入（ウォーターマークＡＣＲシステムの場合）することができる。（ＡＣＲインジェストモジュールは、ＧＰＳクロックと放送スケジュール内セグメントの開始時間及び終了時間を用いて、フレームがそのようなセグメントにあるか否かを判断できる。）そのような各フレームに対してＡＣＲインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連したコードを含み得るデータベースに記録を挿入することができる。次の２つの条件の少なくとも一つを満たさないと、ＡＣＲインジェストモジュールによって記録に含まれたトリガーは、時間ベーストリガーであってもよい。
【０６０６】
（ａ）活性化エレメントは、フレームのｍｅｄｉａ＿ｔｉｍｅが活性化エレメントのｓｔａｒｔＴｉｍｅ前の時間長Ｍから始まって活性化エレメントのｅｎｄＴｉｍｅで終わる時間区間にあるようにＡＭＴに存在する。（活性化がｅｎｄＴｉｍｅを有しないと、ｅｎｄＴｉｍｅはｓｔａｒｔＴｉｍｅと同一であると見なす。）（要求／応答ＡＣＲモデルに対して条件（ａ）と同一）
【０６０７】
（ｂ）トリガーの活性化時間（”ｔ＝＜ｅｖｅｎｔ＿ｔｉｍｅ＞”）直前の時間長Ｍの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。（要求／応答ＡＣＲモデルに対して条件（ｂ）と同一）
【０６０８】
これらの条件（ａ）及び（ｂ）のうち一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する”ｅ＝”項とＡＭＴ内活性化エレメントのｓｔａｒｔＴｉｍｅを示したり（条件（ａ）が場合）、動的トリガーのｅｖｅｎｔ＿ｔｉｍｅを示す（条件（ｂ））”ｔ＝”項と共に記録に含まれうる。
【０６０９】
動的活性化トリガーがトリガーの活性化時間直前の時間長Ｍの区間でインジェストモジュールによって受信されると（このとき、Ｍは要求／応答サーバーにおけると同じ意味を有する）、インジェストモジュールは、動的活性化トリガーと関連してデータベースに如何なるものも置かず、インジェストモジュールが記録を挿入できるデータベースを使用する全てのＡＣＲサーバーに活性化トリガーを伝達することができる。（このアーキテクチャに対して次のような変形があってもよい。インジェストモデルを経由せずに動的活性化トリガーが動的活性化トリガーソースからＡＣＲサーバーに直接伝達されるが、関連した受信機に直ちにメッセージを伝送できるように、ＡＣＲサーバーは活性化時間以前のＭ時間単位よりも遅く到着する動的活性化トリガーを得る。次の受信機提出まで待つと遅すぎるはずである。）
【０６１０】
アクション（１３）で、ＡＣＲサーバーは直前の提出に対して受信しなかった後にデータベースから”ｎｏ ｍａｔｃｈ”指示子を返してもうと、受信機にＮＵＬＬメッセージを送ることができる。直前の提出に対して返してもらった＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と異なる＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と共にトリガーを返してもらうと、受信機にトリガーを送ることができる。両方の場合において、受信機に視聴中のチャネルが変更されたり視聴中のセグメントが終わったことを知らせ、受信機が現在実行しているＴＤＯを終了し、必要なら、新しいＴＰＴをダウンロードするようにすることができる。ＡＣＲサーバーは、一つ以上の活性化トリガーを返してもらうと、既に受信機に送られた活性化トリガーと重複するものは捨てて受信機に送ることができる。それとも、ＡＣＲサーバーは何にもしなくてもよい。
【０６１１】
新しいアクション（１４）で、ＡＣＲサーバーは動的活性化トリガーを受信すると、動的活性化トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞と各ＡＣＲクライアントに対する現＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞とを比較することができる。（ここでクライアントに対する現＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞は、ＡＣＲサーバーがＡＣＲクライアントからの最も最近の提出に対してデータベースから受けたトリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞である。＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞がマッチングされる各クライアントに対して、ＡＣＲサーバーは動的トリガーをクライアントに送ることができる。）
【０６１２】
図２９及び図３１は、活性化時間よりも少なくともＭ時間単位以前にＡＣＲインジェストモジュールに伝達される静的活性化及び動的活性化に対するトリガーの処理を示す。差異点は、ＡＣＲサーバーが重複する活性化トリガーを受信機に送らずに捨てることができるという点である。
【０６１３】
図３５は、急に（活性化時間よりもＭ時間単位以前に）受信された動的活性化トリガーの処理の一実施例を示す。
【０６１４】
図３５は、時間ライン上の動的イベント活性化時間及びＡＣＲインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ＡＣＲサーバーは、ＡＣＲインジェストモジュールから活性化トリガーを受信し次第、（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞から確認されるように）現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。
【０６１５】
図３６は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
【０６１６】
最後に伝達される動的活性化トリガーについて説明する。
【０６１７】
図３６は、急に（活性化時間よりもＭ時間単位以前に）受信された動的活性化トリガーの処理の一実施例を示す。
【０６１８】
最後に伝達される動的活性化トリガーを示す同図は、時間ライン上の動的イベント活性化時間及びＡＣＲインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ＡＣＲサーバーは、ＡＣＲインジェストモジュールから活性化トリガーを受信し次第、（トリガーの＜ｌｏｃａｔｏｒ＿ｐａｒｔ＞から確認されるように）現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。各受信機に対して、トリガーのｅｖｅｎｔ＿ｔｉｍｅを、受信機から最も最近に提出されたシグネチャーに対応するフレームと関連した＜ｄｅｌａｙ＿ｔｉｍｅ＞に調節する。
【０６１９】
図３７は、要求／応答ＡＣＲケースにおけるＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
【０６２０】
図３７は、要求／応答モデルにおいてＡＣＲサーバーと受信機（ＡＣＲクライアント）の動作プロトコルによってトリガー及びＴＰＴを効果的に送信する実施例を示すシーケンスダイヤグラムである。
【０６２１】
以下、要求／応答の順で要求／応答モデルの動作の一例を説明する。
【０６２２】
要求／応答ＡＣＲケースにおいて、ＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムは、ＡＣＲ要求１（Ｓ３７０１０）、ＡＣＲ応答１（Ｓ３７０２０）、ＡＣＲ要求２（Ｓ３７０３０）、ＡＣＲ応答２（Ｓ３７０４０）、ＨＴＴＰ要求１（Ｓ３７０５０）、ＨＴＴＰ応答１（Ｓ３７０６０）、ＨＴＴＰ要求２（Ｓ３７０７０）、ＨＴＴＰ応答２（Ｓ３７０８０）、ＡＣＲ要求３（Ｓ３７０９０）、ＡＣＲ応答３（Ｓ３７１００）、ＡＣＲ要求４（Ｓ３７１１０）、及び／又はＡＣＲ応答４（Ｓ３７１２０）を含むことができる。
【０６２３】
ＡＣＲ要求１（Ｓ３７０１０）は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、前述したＡＣＲサーバーであってもよい。シグネチャーはフィンガープリントシグネチャー又はウォーターマーキングコードであってもよい。
【０６２４】
ＡＣＲ応答１（Ｓ３７０２０）は、シグネチャーが認識されなかったり、又は関連した両方向サービスが存在しないとき、ＡＣＲサーバーがヌルをリターンする段階である。これは、ヌル応答がリターンされる上述したケースに該当する場合であってもよい。
【０６２５】
ＡＣＲ要求２（Ｓ３７０３０）は、チャネル又はプログラムが変更されるとき、受信機が変更されたプログラムのシグネチャーをＡＣＲサーバーに伝送する段階である。
【０６２６】
ＡＣＲ応答２（Ｓ３７０４０）は、ＡＣＲサーバーが該当のプログラムに関連した両方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この段階は、ＡＣＲ応答１（Ｓ３７０２０）と違い、シグネチャーが認識され、関連した両方向サービスが存在するケースに該当できる。すなわち、トリガーを利用可能である場合であってもよい。この場合、リターンされるトリガーは、ｍｅｄｉａ＿ｔｉｍｅに関する情報がない時間ベーストリガーであってもよい。
【０６２７】
ＨＴＴＰ要求１（Ｓ３７０５０）は、受信機がＴＰＴサーバー（例えば、ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）にｈｔｔｐプロトコルを通してＡＣＲ応答２（Ｓ３７０４０）で受信したアドレスを用いて該当するＴＰＴを提供することを要求する段階である。
【０６２８】
ＨＴＴＰ応答１（Ｓ３７０６０）は、ＴＰＴサーバーが受信機の要求に応じてＸＭＬに表したＴＰＴを伝送する段階である。
【０６２９】
ＨＴＴＰ要求２（Ｓ３７０７０）は、受信機がコンテンツサーバーにｈｔｔｐプロトコルを用いてＴＤＯのようなアプリケーションを提供することを要求する段階である。受信機は、ＴＰＴ内に含まれたＴＤＯ関連情報をパーシングすることができる。ＴＤＯ関連情報は、ＴＤＯをダウンロードできるコンテンツサーバーのアドレスであってもよい。コンテンツサーバーのアドレスを用いて要求を送ることができる。
【０６３０】
ＨＴＴＰ応答２（Ｓ３７０８０）は、コンテンツサーバーが受信機の要求に応じて該当するＴＤＯを伝送する段階である。
【０６３１】
ＡＣＲ要求３（Ｓ３７０９０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
【０６３２】
ＡＣＲ応答３（Ｓ３７１００）は、ＡＣＲサーバーが該当のプログラムに関連した両方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この場合、ＡＣＲ応答１（Ｓ３７０２０）と違い、シグネチャーが認識され、関連した両方向サービスが存在する。すなわち、この段階でトリガーは使用可能である。
【０６３３】
ＡＣＲ要求４（Ｓ３７１１０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに伝送する段階である。
【０６３４】
ＡＣＲ応答４（Ｓ３７１２０）は、ＡＣＲサーバーが、受信機から伝送されたシグネチャーと関連した両方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
【０６３５】
図３８は、イベント主導型ＡＣＲケースにおけるＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
【０６３６】
図３８は、イベント主導型モデルにおいてＡＣＲサーバーと受信機（ＡＣＲクライアント）の動作プロトコルによってトリガー及びＴＰＴを効果的に伝送する実施例に係るシーケンスダイヤグラムを示す。
【０６３７】
要求、要求に対する応答、イベントの順にイベント主導型モデルの動作についての一例を説明する。
【０６３８】
イベント主導型ＡＣＲケースにおいて、ＡＣＲクライアントと他のサーバー間のシーケンスダイヤグラムは、ＡＣＲ要求１（Ｓ３８０１０）、ＡＣＲ要求２（Ｓ３８０２０）、ＡＣＲイベント１（Ｓ３８０３０）、ＨＴＴＰ要求１（Ｓ３８０４０）、ＨＴＴＰ応答１（Ｓ３８０５０）、ＨＴＴＰ要求２（Ｓ３８０６０）、ＨＴＴＰ応答２（Ｓ３８０７０）、ＡＣＲ要求３（Ｓ３８０８０）、ＡＣＲイベント２（Ｓ３８０９０）、及び／又はＡＣＲ応答４（Ｓ３８１００）を含むことができる。
【０６３９】
ＡＣＲ要求１（Ｓ３８０１０）は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、上述したＡＣＲサーバーであってもよい。シグネチャーは、フィンガープリントシグネチャー又はウォーターマークであってもよい。ここで、シグネチャーが認識されなかったり、又は関連した両方向サービスが存在しないとき、図３７のシーケンスとは違い、ＡＣＲサーバーはヌルをリターンせずにＡＣＲ要求１に何ら応答も送らなくてもよい。
【０６４０】
ＡＣＲ要求２（Ｓ３８０２０）は、チャネル又はプログラムが変更されるとき、受信機が、変更されたプログラムのシグネチャーをＡＣＲサーバーに伝送する段階である。
【０６４１】
ＡＣＲイベント１（Ｓ３８０３０）は、ＡＣＲサーバーが、該当のプログラムに関連した両方向サービスを取得できるアドレスを含むトリガー（例えば、ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）をリターンする段階である。この段階は、シグネチャーが認識され、関連した両方向サービスが存在するケースに該当できる。すなわち、この段階でトリガーは使用可能である。この場合、リターンするトリガーは、ｍｅｄｉａ＿ｔｉｍｅと関連した如何なる情報も有しない時間ベーストリガーであってもよい。
【０６４２】
ＨＴＴＰ要求１（Ｓ３８０４０）は、受信機がＴＰＴサーバー（例えば、ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｔｐｔ５０４）にｈｔｔｐプロトコルを通してＡＣＲイベント１（Ｓ３８０３０）で受信したアドレスを用いて該当するＴＰＴを提供することを要求する段階である。
【０６４３】
ＨＴＴＰ応答１（Ｓ３８０５０）は、ＴＰＴサーバーが受信機の要求に応じてＸＭＬに表したＴＰＴを伝送する段階である。
【０６４４】
ＨＴＴＰ要求２（Ｓ３８０６０）は、受信機がコンテンツサーバーにｈｔｔｐプロトコルを用いてＴＤＯのようなアプリケーションを提供することを要求する段階である。受信機は、ＴＰＴ内に含まれたＴＤＯ関連情報をパーシングすることができる。ＴＤＯ関連情報は、ＴＤＯをダウンロードできるコンテンツサーバーのＵＲＬであってもよい。コンテンツサーバーのＵＲＬを用いて要求を送ることができる。
【０６４５】
ＨＴＴＰ応答２（Ｓ３８０７０）は、コンテンツサーバーが受信機の要求に応じて該当するＴＤＯを伝送する段階である。
【０６４６】
ＡＣＲ要求３（Ｓ３８０８０）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
【０６４７】
ＡＣＲイベント２（Ｓ３８０９０）は、ＡＣＲサーバーが受信機から伝送されたシグネチャーと関連した両方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
【０６４８】
ＡＣＲ応答４（Ｓ３８１００）は、受信機が現在視聴中のプログラムのフレームのシグネチャーをＡＣＲサーバーに送る段階である。
【０６４９】
図３９は、ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスのアクションリストの一実施例である。
【０６５０】
第２スクリーン支援は、受信機で、放送社のサービス或いは放送社で提供し、プログラムに適した付加的なサービスを、第２スクリーンデバイスに提供するための方法に関するものである。付加的なコンテンツは、アプリケーションを用いて提供することができ、アプリケーションは、ＴＶ画面に表示されてユーザがリモコン操作で付加コンテンツを使用するようにすることができる。しかし、最近では、個人化情報化機器（スマートホン、スマートパッド及び小型化しつつあるラップトップ）などによってＴＶ画面で再生されているコンテンツはそのまま表示させながら、付加的なサービスを第２スクリーンデバイスに表示させることができる。これによって、既存の放送コンテンツを妨害なく個人的に利用できるようにすることができる。このように付加的なデータや情報を第２スクリーンデバイスに表示して処理をすると、ＴＶ画面を複数の人が一緒に見る状況で、付加サービスに関心のある人だけが他の人のＴＶ視聴を妨害することなく付加コンテンツを得ることができる効果がある。第２スクリーン支援は、前述した効果の他にも様々な用途に活用することができる。
【０６５１】
一つの装置を他の装置に接続させて制御するためには、まず、ホームネットワークにどのような装置があるかを知らなければならない。このため、一つ以上の装置が自身の存在を周期的にホームネットワークにメッセージを送信して広く知らせることができる。一方では、一つの装置が新しくホームネットワークに接続しながら自身を紹介する前に、自身以外にどのような装置があるかを要求することができる。これら２つの接近方式は、互いに装置を容易に且つ迅速に認識できるように手伝うことができる。これを、ＵＰｎＰデバイスディスカバリ（Ｄｅｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ）と呼ぶ。装置を発見すると、発見された装置に関心のある他の装置は、その装置にどのようなサービスを提供できるかに関する情報が必要でありうる。ＵＰｎＰフレームワーク（Ｆｒａｍｅｗｏｒｋ）が内蔵されている家電機器は、互いにどんな機能を有しているか、そしてそれらの機能がどの範囲まで支援するかが把握できる。この情報をＵＰｎＰデバイスプロファイル（Ｄｅｖｉｃｅ  Ｐｒｏｆｉｌｅ）と定義しおき、互いに提供できるサービスの属性を把握することができる。特定サービスを提供する装置を常に待っていてもよいが、その特定サービスを提供する装置が発見される場合、発見された装置内にどのようなサービスがあるかを問うことができる。発見された装置内に適合なサービスがあると、すぐに接続して互いに通信することができる。また、ＵＰｎＰサービス記述語（Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｏｒ）に定義されたとおりにサービスを定義して交換することができる。
【０６５２】
一つの装置には、単数又は複数個のサービスがあり、このサービスを互いに異なる機器で制御して使用するようになっている。装置に一つ以上の機能があると、その機能別に定義された複数個のサービスが含まれ、他の機器で制御することができる。装置の定義は、装置固有の情報を有することができる。例えば、モデル名（Ｍｏｄｅｌ  Ｎａｍｅ）、一連番号（Ｓｅｒｉａｌ  Ｎｕｍｂｅｒ）、モデル番号（Ｍｏｄｅｌ  Ｎｕｍｂｅｒ）、ＣＥメーカー名（Ｍａｎｕｆａｃｔｕｒｅｒ  Ｎａｍｅ）及びウェブサイト（Ｗｅｂ  Ｓｉｔｅ）などの情報が装置固有の情報であってもよい。これらの情報は装置別に固有の値を有し、一般的には変更されない。サービスは、装置が行える動作であり、各動作はアクション（Ａｃｔｉｏｎ）と呼び、一つ以上のアクションを有することができる。アクションは、関数のようにそれぞれパラメータ値を有し、一つ以上のパラメータ値を有することができる。アクションは、装置内のサービスで行われ、アクションが行われた後には、必要によって、定義されたリターン値を返還することができる。
【０６５３】
アクションに対する例示として、図３９は、例示されたサービスであるＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスに対して、そのサービスのアクションの種類及び記述（Ｄｅｓｃｒｉｐｔｉｏｎ）を示している。Ｃｏｎｎｅｃｔｉｏｎ／ｄｉｓｃｏｎｎｅｃｔｉｏｎは、現在接続状態を返還するアクションであってもよい。ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎは、現在接続目録を返還するアクションであってもよい。ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅは、デバイスプロファイルをＸＭＬの形態として返還するアクションであってもよい。ＧｅｔＵＩＬｉｓｔｉｎｇは、互換可能な（ｃｏｍｐａｔｉｂｌｅ）ＵＩの目録をＸＭＬの形態として返還するアクションであってもよい。ＡｄｄＵＩＬｉｓｔｉｎｇ／ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇは、ｒｅｍｏｔｅ ＵＩのＵＲＬをＵＩ目録に追加したり除去する動作であってもよい。ＰｒｏｃｅｓｓＩｎｐｕｔは、ＲｅｍｏｔｅＵＩクライアントサービスにデータを送るアクションであってもよい。ＤｉｓｐｌａｙＭｅｓｓａｇｅは、ＲｅｍｏｔｅＵＩクライアントサービスを含む装置にメッセージをディスプレイするアクションであってもよい。
【０６５４】
図４０は、ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例である。
【０６５５】
ＵＰｎＰでは、前述したアクションと必要なパラメータ値を送信するために、ＳＯＡＰというＸＭＬメッセージ形式を使用し、ＳＯＡＰは、遠隔手順（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ）を遠隔で行うために用いることができる。これらのメッセージは、ＨＴＴＰプロトコルを用いて伝送することができる。
【０６５６】
前述したＲｅｍｏｔｅＵＩクライアントのアクションは、図４０のように動作することができる。図４０に示す動作は、前述したアクションの一実施例にすぎない。
【０６５７】
ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスの一実施例は、ＵＰｎＰ探索プロセスとＲｅｍｏｔｅＵＩクライアントアクションとに分けることができる。
【０６５８】
ＵＰｎＰ探索プロセスは、第２スクリーンサービスのためのＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）、ＵＰｎＰデバイスを探す段階（ｓ４００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）、デバイス記述（Ｄｅｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を要求する段階（ｓ４００３０）、デバイス記述を受信する段階（ｓ４００４０）、サービス制御記述を要求する段階（ｓ４００５０）及び／又はサービス制御記述を受信する段階（ｓ４００６０）を含むことができる。
【０６５９】
ＲｅｍｏｔｅＵＩクライアントアクションは、デバイスプロファイルを要求する段階（ｓ４００７０）、デバイスプロファイルを受信する段階（ｓ４００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ４００９０）、応答１を送信する段階（ｓ４０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）、応答２を送信する段階（ｓ４０１２０）、及び／又はユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）を含むことができる。
【０６６０】
ＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）は、第２スクリーンデバイス（ＲｅｍｏｔｅＵＩクライアント）でａｎ ＵＰｎＰアプリケーションを実行させる段階であってもよい。
【０６６１】
ＵＰｎＰデバイスを探す段階（ｓ４００１０）は、プライマリデバイスが第２スクリーンデバイスで実行中のアプリケーションにディスカバリメッセージ（ｄｉｓｃｏｖｅｒｙ  ｍｅｓｓａｇｅ）をマルチキャストする段階であってもよい。これによってネットワーク内の第２スクリーンデバイスを探すことができる。プライマリデバイスは、ディスカバリメッセージを用いて、自身が提供する第２スクリーン支援サービスを知らせることができる。
【０６６２】
ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）は、第２スクリーンデバイスがディスカバリメッセージを受け、プライマリデバイスに通知メッセージ（ｎｏｔｉｆｉｃａｔｉｏｎ  ｍｅｓｓａｇｅ）を送る段階であってもよい。
【０６６３】
デバイス記述を要求する段階（ｓ４００３０）は、プライマリデバイスが第２スクリーンデバイスに第２スクリーンデバイスに対するデバイス記述を要求する段階であってもよい。
【０６６４】
デバイス記述を受信する段階（ｓ４００４０）は、第２スクリーンデバイスがデバイス記述を要求する段階（ｓ４００３０）に対する応答として第２スクリーンデバイスのデバイスプロファイルを送ると、プライマリデバイスがこれを受信する段階であってもよい。
【０６６５】
サービス制御記述を要求する段階（ｓ４００５０）は、プライマリデバイスが第２スクリーンデバイスにサービス制御記述を要求する段階であってもよい。
【０６６６】
サービス制御記述を受信する段階（ｓ４００６０）は、プライマリデバイスが第２スクリーンデバイスから、要求したサービス制御記述を受信する段階であってもよい。
【０６６７】
ＵＰｎＰ探索プロセスによって、ネットワーク上に存在するプライマリデバイスと第２スクリーンデバイスはお互い探索して認識することができる。また、これによってプライマリデバイスと第２スクリーンデバイスは互いに接続することができる。
【０６６８】
デバイスプロファイルを要求する段階（ｓ４００７０）は、第２スクリーンデバイスのデバイスプロファイルを要求する段階であってもよい。前述したＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅアクションを用いることができる。
【０６６９】
デバイスプロファイルを受信する段階（ｓ４００８０）は、プライマリデバイスが要求した第２スクリーンデバイスのデバイスプロファイルを受信する段階であってもよい。“ＲｅｍｏｔｅＵＩクライアントサービス”を有する装置（第２スクリーンデバイス、ＲｅｍｏｔｅＵＩクライアント）は、遠隔の装置（プライマリデバイス）でＵＩのＵＲＬアドレスを知らせると、このアドレスを探して画面に表示する役割を果たすことができる。また“ＲｅｍｏｔｅＵＩサーバーサービス”を有する装置は、ＵＩのＵＲＬアドレスをマルチキャストし、それに関心のある装置に知らせるサービスであってもよい。しかし、この場合には、Ｒｅｍｏｔｅ ＵＩが特定装置のために作られるため、特定装置に合う遠隔ＵＩを提供しなければならない。このため、デバイスプロファイル情報を共に送信する必要があり、デバイスプロファイルを要求する段階（ｓ４００７０）及びデバイスプロファイルを受信する段階（ｓ４００８０）が必要でありうる。
【０６７０】
遠隔ＵＩのＵＲＬを送る段階（ｓ４００９０）は、遠隔ＵＩのＵＲＬアドレスを第２スクリーンデバイスに知らせる段階であってもよい。前述したＡｄｄＵＩＬｉｓｔｉｎｇアクションを用いることができる。第２スクリーンデバイスは、これをＵＩＬｉｓｔｉｎｇに追加することができる。
【０６７１】
応答１を送信する段階（ｓ４０１００）は、遠隔ＵＩのＵＲＬを送る段階（ｓ４００９０）に対する結果を送る段階であってもよい。状況によって、ＨＴＴＰ／１．１ ２００ ＯＫ（要求が成功裏に処理される）、ＨＴＴＰ／１．１ ５０１ Ｍｅｔｈｏｄ Ｎｏｔ Ｉｍｐｌｅｍｅｎｔｅｄ（要求を処理するために必要な機能が具現されていない）、ＨＴＴＰ／１．１ ４００ Ｎｏｔ Ｆｏｕｎｄ（要求したファイル／リソースが存在しない）などの応答を送ることができる。
【０６７２】
ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）は、プライマリデバイスが第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したＤｉｓｐａｌｙＭｅｓｓａｇｅアクションを用いることができる。第２スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第２スクリーンにディスプレイすることができる。
【０６７３】
応答２を送信する段階（ｓ４０１２０）は、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況に応じて、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０６７４】
ユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）は、第２スクリーンにディスプレイされたメッセージなどによって、ユーザが選択をする段階であってもよい。
【０６７５】
ＲｅｍｏｔｅＵＩクライアントアクションは、前述したアクションなどによってＲｅｍｏｔｅＵＩクライアントサービスが動作する過程を記述したものであってもよい。
【０６７６】
遠隔ユーザインターフェースに関する記述は、画面に表示されるＨＴＭＬ記述ベースのアプリケーションを家電機器で使用できるように機能を追加したり制限された家電機器のリソースを勘案して、既存のＰＣシステムで使用可能な機能を簡素化した。この記述には、大きく、２つの観点が含まれている。すなわち、画面に表示するＨＴＭＬを家電製品で使用できるようにしたことと、各家電製品で使用できるブラウザＡＰＩを定義することである。ブラウザＡＰＩは、多く使われているスクリプト言語であるジャバスクリプト（ＪａｖａＳｃｒｉｐｔ）で呼び出しして使用することができる。ジャバスクリプトで呼び出されたＡＰＩは、結局として受信機の関数を呼び出すようになる。
【０６７７】
この中、前述したＵＰｎＰデバイスとサービスは、ブラウザで動作するジャバスクリプトによっても動作できるはずである。そのためには、ブラウザで各ＵＰｎＰデバイス別に異なるパラメータを伝達する新しいＡＰＩが必要であろう。
【０６７８】
図４１は、ＤＴＶＣＣ Ｓｅｒｖｉｃｅ Ｎｕｍｂｅｒ６におけるトリガーの一実施例である。
【０６７９】
前述したとおり、ＤＴＶＣＣ（Ｄｉｇｉｔａｌ  ＴＶ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  Ｓｅｒｖｉｃｅ）サービスを用いて前述のリガーを送信することができる。トリガーは、一つのＵＲＬストリング（Ｓｔｒｉｎｇ）値を有することができ、ＤＴＶＣＣサービスのうちの６番目のサービスとして受信することができる。ＭＰＥＧ−２送信プロセッサ４１０１０はトリガーをＤＴＶＣＣサービスシリーズ＃６として受信し、送信プロセッサドライバ４１０２０を通してＤＴＶ−ＣＣモジュール４１０４０に伝達できる。このとき、Ｕｓｅｒｄａｔａは、バッファー４１０３０を経由することができる。ＤＴＶ−ＣＣモジュール４１０４０は、ＤＴＶＣＣデコーダの役割を果たすことができる。ＤＴＶ−ＣＣモジュール４１０４０は、ＵＲＩストリング値を有するトリガーを付加サービスモジュール（Ａｄｊｕｎｃｔ  Ｓｅｒｖｉｃｅ  ｍｏｄｕｌｅ）４１０５０に伝達することができる。付加サービスモジュール４１０５０はトリガーモジュールであり、ＵＲＩストリング値を把握し、前述したＴＰＴ（ＴＤＯ  Ｐａｒａｍｅｔｅｒｓ  Ｔａｂｌｅ）を取得することができる。これによって、前述したとおり、トリガー、ＴＰＴ及びＴＤＯを用いて付加サービスを提供することができる。
【０６８０】
図４２は、第２スクリーンシナリオのためのシステムアーキテクチャの一実施例である。
【０６８１】
第２スクリーンの支援のためにいくつかの要求事項がありうる。１）受信機は、一つ或いはそれ以上の第２スクリーンデバイスと接続することができる。２）第２スクリーンデバイスは、ラップトップ、タブレット、スマートホン、ＰＤＡなどの携帯機器を対象とすることができる。３）第２スクリーンの主要コンテンツは、ＨＴＭＬ、テキスト、ビデオ、オーディオなどとすることができる。４）第２スクリーンで再生されるコンテンツは、プライマリデバイス（受信機）の放送プログラムに邪魔とならない設計とすることができる。５）第２スクリーンは直接的にＡＴＳＣ２．０受信機に接続することができ、間接的には３ＧＰＰ網のように迂回して接続することもできる。６）プロバイダが、特定コンテンツが第２スクリーンでのみ表示されるようにシグナリングすることもできる。７）場合によって、受信機で再生可能なコンテンツも、第２スクリーンで再生可能に設計することができる。８）認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及び許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）された第２スクリーンで第２スクリーンサービスを用いることができる。９）第２スクリーンコンテンツの聴衆使用量（ａｕｄｉｅｎｃｅ  ｕｓａｇｅ）を測定するようにすることができる。（この場合、このような情報を得るためにユーザから同意を得、その情報を報告できる機能が存在してもよい。）１０）第２言語又はコンテンツエンハンスメント（Ｃｏｎｔｅｎｔ  Ｅｎｈａｎｃｅｍｅｎｔ）可能な装置を用いて提供することもできる。
【０６８２】
本明細書は、放送されるプログラムと同期したコンテンツを有する第２スクリーンデバイス（スマートホン、タブレット、ラップトップなど）上で実行されるアプリケーションによるＡ／Ｖ放送に関連したコンテンツのディスプレイを支援するために受信機によって提供されうるサービスを記述することができる。サービスに関する説明はＵＰｎＰデバイスアーキテクチャに基づいて記述された。
【０６８３】
この明細書で、ＡＴＳＣ２．０受信機とは、ＴＶ受信機又は一般的な受信機を意味することができる。また、ＤＶＢ、ＡＴＳＣなどにおける受信機を意味することができる。
【０６８４】
ＵＰｎＰデバイスアーキテクチャは、サービスを提供する“被制御デバイス”及びそのサービスを利用する“制御ポイント”間のＩＰネットワークにおける通信のためのプロトコルを定義する。“第２スクリーン”シナリオで、ＴＶ受信機は“被制御デバイス”の役割を担い、第２スクリーンデバイスは“制御ポイント”の役割を担うことができ、その逆であってもよい。
【０６８５】
ＵＰｎＰデバイスアーキテクチャは、関心のある被制御デバイスを探す制御ポイントのための“探索”プロトコル、被制御デバイス及びサービスに対する細部事項を学習する制御ポイントのための“記述（ｄｅｓｃｒｉｐｔｉｏｎ）”プロトコル、被制御デバイス上の“アクション”（方法）を実行（ｉｎｖｏｋｅ）する制御ポイントのための“制御”プロトコル、及び制御ポイントに非同期通知を伝達する被制御デバイスのための“イベンティング（ｅｖｅｎｔｉｎｇ）”プロトコルを特定する。アクション及びイベントは、デバイスサービスによって提供することができる。
【０６８６】
ＵＰｎＰ被制御デバイスがネットワークにジョイン（ｊｏｉｎ）すると、“よく知らされた”ＩＰマルチキャストアドレス及びポートにディスカバリメッセージをマルチキャストすることができる。それらのメッセージは、デバイスによって提供されるデバイスタイプ及びサービスタイプを識別することができ、デバイス及びサービスの記述を取得できるＵＲＬを提供することができる。
【０６８７】
ＵＰｎＰ制御ポイントがネットワークにジョインすると、被制御デバイスに自身を知らせるかを問う序歯（ｓｅａｒｃｈ）メッセージをマルチキャストすることができる。サーチメッセージは、関心のあるデバイスタイプ及び／又はサービスタイプを特定することができる。関連デバイスは、制御ポイントにユニキャストディスカバリメッセージを送ることによって応答することができる。
【０６８８】
制御ポイントが関心のあるデバイス及びサービスに対するディスカバリメッセージを得ると、メッセージ内のＵＲＬを用いてデバイス及びサービスの記述（ｄｅｓｃｒｉｐｔｉｏｎ）を要求することができる。それらの記述は、アクションを実行（ｉｎｖｏｋｅ）し、サービスに対するイベントを申し込むために用い得るＵＲＬを含むことができる。
【０６８９】
一般的な第２スクリーン探索シナリオは、シナリオＡとシナリオＢとに大別できる。シナリオＡの場合、ユーザは、ＴＶ受信機が（ＴＶ受信機がオンになる時又はそのネットワークインターフェースがイネーブルされる時に発生しうる）ネットワークにジョインする時、自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有する。シナリオＢの場合、ユーザは、ＴＶ受信機がネットワークにジョインする時、自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有しない。
【０６９０】
シナリオＡは、次の通りでありうる。１）第２スクリーン支援を提供するＴＶ受信機はネットワークにジョインする。２）ＴＶ受信機は、その第２スクリーン支援サービスを広告するディスカバリメッセージをマルチキャストする。３）第２スクリーンデバイスで実行される第２スクリーンアプリケーションは、マルチキャストされたディスカバリメッセージを受信し、ＴＶ受信機にそのサービスの記述に対する要求を送信する。４）ＴＶ受信機は、そのサービスの記述で応答する。５）第２スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスして、ＴＶプログラミングと同期したインタラクティブ経験を提供する。
【０６９１】
シナリオＢは、次の通りでありうる。１）ＴＶ受信機上で見ているＴＶ番組は、第２スクリーン支援を提供するプログラムセグメントに入る。（これは、ＴＶ受像機がオンになるやいなや又はチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時、又は視聴しているチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時でありうる。）２）これは、ＴＶ受信機が第２スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。３）視聴者は、第２スクリーン支援を用いて自身の第２スクリーンデバイス上で第２スクリーンアプリケーションを活性化する。すると、第２スクリーンアプリケーションは、第２スクリーン支援を提供する装置を探すメッセージをマルチキャストする。ＴＶ受信機は、自身のディスカバリメッセージでこのメッセージに応答する。４）第２スクリーンアプリケーションがディスカバリメッセージを探すと、ＴＶ受信機にそのサービスの記述に対する要求を送信する。５）ＴＶ受信機は、そのサービスの記述で応答する。６）第２スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスし、ＴＶ番組と同期したインタラクティブ経験を提供する。
【０６９２】
シナリオＡを書き換えると、次の通りでありうる。１）第２スクリーン支援を提供するＴＶ受像機はネットワークにジョインする。（これは、ＴＶセットがオンになる時又はそのネットワークインターフェースがイネーブルされる時であってもよい。）２）これは、ＴＶ受信機が自身及びその第２スクリーン支援サービスを広告する自身のディスカバリメッセージをマルチキャストするようにする。３）この時、ユーザが自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有すると、アプリケーションは、マルチキャストされたディスカバリメッセージを受信し、段階（７）に進行する。４）ＴＶ受信機上で見ているＴＶ番組が第２スクリーン支援を提供するプログラムセグメントに入る。（これは、ＴＶ受像機がオンになるやいなや又はチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時又は視聴しているチャネルが第２スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時であってもよい。）５）これは、ＴＶ受信機が、第２スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。６）視聴者が自身の第２スクリーンデバイスで実行される第２スクリーンアプリケーションを有していない場合、視聴者は、第２スクリーン支援を用いて自身の第２スクリーンデバイス上で第２スクリーンアプリケーションを活性化する。すると、第２スクリーンアプリケーションは、第２スクリーン支援を提供する装置を探すメッセージをマルチキャストする。ＴＶ受信機は、自身のディスカバリメッセージでこのメッセージに応答する。７）第２スクリーンアプリケーションがディスカバリメッセージを探すと、ＴＶ受信機にそのサービスの記述に対する要求を送信する。８）ＴＶ受信機は、そのサービスの記述で応答する。これらは、トリガーサービス及び選択的にＨＴＴＰプロキシサーバーサービスであろう。９）第２スクリーンアプリケーションは、トリガーサービスの“イベンティング”特徴を申し込むはずである。提供されるインタラクティブデータサービスの相互作用モデルが直接実行モデルであれば、全てのトリガーがＴＶ受信機によって受信される時、トリガーサービスは全てのトリガーを第２スクリーンデバイスに送信するはずである。インタラクティブデータサービスの相互作用モデルがＴＤＯモデルであれば、新しい活性化トリガーの活性化時間に到達する度に、トリガーサービスは活性化トリガーを第２スクリーンアプリケーションに送信するはずである。１０）第２スクリーンアプリケーションは、必要によってＴＤＯ及び他のファイルを、インターネットリンク又はＴＶ受信機によって提供されたＨＴＴＰプロキシサーバーサービスからダウンロードし、インタラクティブサービスを第２スクリーン装置ユーザに提供しながらトリガーに対して動作するはずである。１１）ＴＶ受信機上のＴＶ番組が、第２スクリーン支援を有するインタラクティブデータサービスを提供しないセグメントに進行すると、トリガーサービスは、“ヌルトリガー（ｎｕｌｌ  Ｔｒｉｇｇｅｒ）”を第２スクリーンアプリケーションに送信し、第２スクリーンデバイスに対するインタラクティブデータサービスがそれ以上利用可能でないということを知らせる。１２）その後、第２スクリーンデバイスのユーザが、第２スクリーンアプリケーションを閉じたり、そのまま第２スクリーンアプリケーションが実行されるようにし、ＴＶ受信機上の番組が第２スクリーン支援を提供する他のセグメントに入る度に相互作用を再開するようにすることができる。
【０６９３】
これらの両シナリオで、仮定は、ホームネットワーク上に１よりも多いＴＶ受信機を有することができる。この場合、第２スクリーンアプリケーションは、多数の異なった受信機からディスカバリメッセージを受信することができる。この場合、第２スクリーンアプリケーションは（ユーザの決定を助けるために記述メッセージからの情報をディスプレイしながら）どれをもって相互作用をするかをユーザに問うことができる。
【０６９４】
第２スクリーン支援を提供するＴＶ受信機は、第２スクリーンアプリケーションの使用のためのいくつかのＵＰｎＰサービスを提供することができる。ＵＰｎＰサービスは、受信機から第２スクリーンアプリケーションへの“トリガー伝達サービス”、受信機で実行されるＤＯ（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔｓ）及び第２スクリーンアプリケーション間の“両方向通信サービス”及び“ＨＴＴＰプロキシサーバーサービス”であってもよい。それらのサービスは、構成によって選択的であってもよい。
【０６９５】
それらのサービスは、様々な異なったソースから得られ、様々な異なったタイプの第２スクリーンデバイスで様々な互いに異なる動作環境下に実行される様々な異なったタイプの第２スクリーンアプリケーションを支援するように設計されてもよい。
【０６９６】
一般的な第２スクリーンパッケージアプリケーションシナリオは、次の通りである。１）第２スクリーンデバイス上の制御ポイントは、第１スクリーン装置上のパッケージアプリケーションサービスを申し込む。２）消費者は、第１スクリーン装置上のパッケージアプリケーションを始める。３）パッケージアプリケーションは、第２スクリーンアプリケーションのネーム及び第２スクリーンアプリケーションのＵＲＬをパッケージアプリケーションサービスに利用可能にする。４）第２スクリーンデバイス上の制御ポイントは、同伴者（ｃｏｍｐａｎｉｏｎ）アプリケーションのネーム及びＵＲＬを受信する。５）制御ポイントは、必要な消費者アクションを指示する第２スクリーン上のマーカーを設定する。６）消費者は、第２スクリーンアプリケーションのネームを検討し選択する。７）制御ポイントは、指示された第２スクリーンアプリケーションを開始する。
【０６９７】
第２スクリーン支援を提供する第１スクリーンは、第２スクリーンアプリケーションの利用のためにいくつかのＵＰｎＰサービスを提供することができる。ＵＰｎＰサービスの一つは、第２スクリーンデバイス上で実行される同伴者第２スクリーンアプリケーションのネーム及びＵＲＬを提供している“アプリケーションＵＲＬサービス”である。
【０６９８】
第２スクリーンシナリオに対するシステムアーキテクチャを説明する。
【０６９９】
第２スクリーンシナリオに対するシステムアーキテクチャは、放送システム４２０１０、ＡＣＲサーバー４２０２０、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０、ＡＴＳＣ２．０受信機４２０４０及び／又は第２スクリーンデバイス４２０５０を含むことができる。
【０７００】
放送システム４２０１０は、一般的な放送システムであってもよい。放送ネットワークを介してトリガー、Ａ／Ｖ、ＴＰＴ及び／又はその他データファイルなどを伝達することができる。トリガーの場合、前述したとおり、ＤＴＶＣＣを用いて伝達することができる。
【０７０１】
ＡＣＲサーバー４２０２０は、放送コンテンツに対するＡＣＲ関連データを管理するサーバーであり、要求或いは必要な場合、ＡＴＳＣ２．０受信機４２０４０がインタラクティブサービスを取得できるように、これと関連したトリガーをＡＴＳＣ２．０受信機４２０４０に送信することができる。前述したＡＣＲサーバーと同一であってもよい。
【０７０２】
放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０は、インタラクティブサービスを生成及び管理するサーバーであり、これと関連したＴＤＯ／ファイルを管理し、それに関する情報を含むＴＰＴ（ＴＤＯ  Ｐａｒａｍｅｔｅｒ  Ｔａｂｌｅ）を生成及び管理することができる。
【０７０３】
ＡＴＳＣ２．０受信機４２０４０は、放送Ａ／Ｖ及びインタラクティブサービスと関連したトリガーなどを受信し、それを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。
【０７０４】
第２スクリーンデバイス４２０５０は、第２スクリーンデバイスであるモバイルホン、タブレット、ラップトップなどを含むことができる。前述した第２スクリーンデバイスと同一であってもよい。
【０７０５】
トリガーは、ＤＴＶＣＣチャネル又はＡＣＲプロセスを通してＡＴＳＣ２．０受信機４２０４０に伝達されてもよく、放送インタラクティブＴＶ（ｉＴＶ）サーバー４２０３０から伝達されてもよい。いずれの場合も、適切な時間にトリガーはＡＴＳＣ２．０受信機４２０４０から第２スクリーンデバイス４２０５０に伝達される。本明細書は、第２スクリーンデバイス４２０５０に伝達されるトリガーに対するメカニズムを説明する。また、ＡＴＳＣ２．０受信機４２０４０上で実行されて第２スクリーンデバイス４２０５０と両方向通信を確立するＤＯに対するメカニズムを説明する。
【０７０６】
インターネットを介して利用可能なアプリケーション及び他のファイルは、そのサービスを提供する場合には、ホームネットワークを通じて、別途の３ＧＰＰネットワークを通じて、又はＡＴＳＣ２．０受信機４２０４０上のＨＴＴＰプロキシサーバー（図示せず）を通じて第２スクリーンデバイス４２０５０によって検索されうる。第１スクリーンデバイス上で実行されるアプリケーションは、放送によって送信されるアプリケーション又はインターネットからダウンロードしたパッケージアプリケーションであってもよい。
【０７０７】
放送でＦＬＵＴＥセッションを通じてのみ利用可能なアプリケーション及び他のファイルは、ＡＴＳＣ２．０受信機４２０４０が要求時にＦＬＵＴＥファイルを伝達するＨＴＴＰプロキシサーバーを提供する時にのみ（第２スクリーンデバイス４２０５０はＴＶ受信機を含まないと仮定）、第２スクリーンデバイス４２０５０によって検索されうる。
【０７０８】
本明細書はまた、第２スクリーンデバイス４２０５０上でのアプリケーションの開始を支援するためにＡＴＳＣ２．０受信機４２０４０上で実行されるパッケージアプリケーションに対するメカニズムを説明する。
【０７０９】
図４３は、ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例である。
【０７１０】
図４３は、ＡＴＳＣ２．０受信機と第２スクリーンデバイス間の直接接続を説明する。
【０７１１】
ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（直接接続）の一実施例は、放送システム４３０１０、放送社ＡＴＳＣ２．０サーバー４３０２０、ＡＴＳＣ２．０受信機４３０３０及び／又は第２スクリーンデバイス４３０４０を含むことができる。
【０７１２】
放送システム４３０１０は、放送システム４２０１０と同一であってもよい。
【０７１３】
放送社ＡＴＳＣ２．０サーバー４３０２０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
【０７１４】
ＡＴＳＣ２．０受信機４３０３０は、ＡＴＳＣ２．０受信機４２０４０と同一であってもよい。
【０７１５】
第２スクリーンデバイス４３０４０は、第２スクリーンデバイス４２０５０と同一であってもよい。
【０７１６】
ＡＴＳＣ２．０受信機４３０３０は、放送網に接続していて直接的に地上波放送受信が可能であってもよい。したがって、ＡＴＳＣ２．０受信機４３０３０では、ＤＴＶＣＣを通じて送信されるｉＴＶメッセージのＵＲＬストリングをＤＴＶＣＣサービス番号６で抽出可能であってもよい。また、ホームゲートウェイに接続していていつでも必要によってインターネットに接続可能であってもよい。そして、ホームネットワーク記述（ＵＰｎＰ）を用いて、他のホームネットワーク内に接続した装置と通信することができる。
【０７１７】
第２スクリーンデバイス４３０４０はいずれもホームゲートウェイと接続していてそれぞれの装置間の通信が可能であり、自由にインターネット接近が可能であってもよい。ホームゲートウェイは、イーサネット（Ｅｔｈｅｒｎｅｔ）及びＷｉ−Ｆｉを支援する機能を全て備えていてもよい。
【０７１８】
放送社は、インタラクティブサービスのためにインターネットにサーバーをおいて付加サービスを提供することができる。ＡＴＳＣ２．０受信機４３０３０や第２スクリーンデバイス４３０４０が接続して、ＴＤＯやモバイル用に作られたウェブページをダウンロードすることができる。ＡＴＳＣ２．０受信機４３０３０である場合には、ＴＶの解像度に合わせて作られたウェブページであり、第２スクリーンデバイス４３０４０である場合には、ＴＶと違い、解像度及び支援するＡＰＩｓが異なってもよいため、それに適合するように製作されうる。
【０７１９】
図４４は、ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例である。
【０７２０】
図４４は、ＡＴＳＣ２．０受信機及び第２スクリーンデバイス間の間接接続を説明する。
【０７２１】
ＡＴＳＣ２．０受信機及び第２スクリーン間のトポロジ（間接接続）の一実施例は、放送システム４４０１０、放送社ＡＴＳＣ２．０サーバー４４０２０、放送社セッション管理４４０３０、ＡＴＳＣ２．０受信機４４０４０及び／又は第２スクリーンデバイス４４０５０を含むことができる。
【０７２２】
放送システム４４０１０は、放送システム４２０１０と同一であってもよい。
【０７２３】
放送社ＡＴＳＣ２．０サーバー４４０２０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
【０７２４】
放送社セッション管理４４０３０は、間接接続において、第２スクリーンデバイス４４０５０とＡＴＳＣ２．０受信機４４０４０間の間接接続を管理する役割を担うことができる。
【０７２５】
ＡＴＳＣ２．０受信機４４０４０は、ＡＴＳＣ２．０受信機４２０４０と同一であってもよい。
【０７２６】
第２スクリーンデバイス４４０５０は、第２スクリーンデバイス４２０５０と同一であってもよい。
【０７２７】
図４４の間接接続は、第２スクリーンデバイス４４０５０がホームゲートウェイを通じてＡＴＳＣ２．０受信機４４０４０に接続される場合ではなく、３ＧＰＰ網に直接接続してホームネットワークにあるＡＴＳＣ２．０受信機４４０４０と接続される場合であってもよい。この場合には、第２スクリーンデバイス４４０５０がホームネットワークに接続し難い場合或いはホームネットワークを支援するネットワークインターフェースがない場合に該当する。
【０７２８】
この場合には、第２スクリーンデバイス４４０５０は、外部のインターネットサーバーが有しているＡＴＳＣ２．０受信機４４０４０の情報が必要でありうる。また、ＡＴＳＣ２．０受信機４４０４０は、動作時に、接続アドレスを外部にあるインターネットサーバーに報告して知らせなければならないことがある。
【０７２９】
第２スクリーンデバイス上にインタラクティブサービスを效果的に伝達するための方案として、中央集中型（ｃｅｎｔｒａｌｉｚｅｄ）実行モデル及び分散型（ｄｉｓｔｒｉｂｕｔｅｄ）実行モデルがある。
【０７３０】
図４５は、第２スクリーンサービスアプリケーションのソフトウェア層の一実施例を示す図である。
【０７３１】
第２スクリーンデバイスは、一般的に、ＯＳを用いてアプリケーションを実行する。一般に、モバイル装置用ＯＳの一部の機能は、軽量化の目的から含まれなくてもよい。したがって、ＯＳによって支援されない機能がアプリケーションに含まれる必要がある。
【０７３２】
図４５のソフトウェア層は、第２スクリーンサービスに必要な第２スクリーンサービスアプリケーションのソフトウェア構造を示す。図４５は、受信機が第２スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
【０７３３】
第２スクリーンデバイスがインターネットコンテンツを再生するので、ＯＳはプラットホームＳＤＫを用いてウェブアプリケーションが実行され得る環境をプログラマーに提供することができる。環境は、ＯＳによって実行されるアプリケーションがインターネットコンテンツをディスプレイするようにＳＤＫの形態で提供することができる。
【０７３４】
図４５で、第２スクリーンサービスアプリケーションは、第２スクリーンデバイス上で実行されうる。このアプリケーションは、アップストア（ＡｐｐＳｔｏｒｅ）（又は、任意の種類のアプリケーションマーケット）からダウンロードされうる。第２スクリーンサービスアプリケーションは、ＡＣＲクライアントを含むことができ、マイクロホン及びカメラを用いてＴＶ受像機からビデオ及びオーディオデータをキャプチャーすることができる。また、ＡＣＲクライアントは、ビデオ及びオーディオデータをサンプリングし、メディアシグネチャーをＡＣＲサーバーに送信することができる。第２スクリーンサービスアプリケーションは、ＯＳ上で実行可能であり、ＵＰｎＰフレームワークが何を動作させ得るかによって、ＨＴＴＰ、ＳＳＤＰ又はマルチキャストイベントなどのプロトコルを含み、ブラウザモジュールは、ウェブアプリケーションを実行及びディスプレイするために含まれうる。
【０７３５】
ブラウザモジュールは、インターネットウェブページをレンダリングするモジュールであってもよい。ブラウザモジュールは、ウェブアプリケーション（例えば、ＥＣＭＡＳｃｒｉｐｔ、ＨＴＭＬ及びＸＨＴＭＬ）をレンダリングするウェブブラウザエンジンの核心部分である。また、ブラウザモジュールは、ＯＳによって提供されるブラウザと同一又は類似の機能を提供するソフトウェアモジュールを意味できる。ブラウザ及び制御可能な機能を利用する方法は、ＯＳ別に異なる。
【０７３６】
第２スクリーンアプリケーションは、第２スクリーンデバイス用に設計されたウェブアプリケーションであってもよい。第２スクリーンアプリケーションは、ＥＣＭＡＳｃｒｉｐｔ又はウェブアプリケーションによって機能を呼び出すウェブアプリケーションであってもよく、そのサイズは、モバイルＯＳによって提供されるブラウザモジュールで実行されるように制御されうる。このウェブアプリケーションは、第２スクリーンサービスアプリケーションで実行されうる。
【０７３７】
モバイル装置用オペレーティングシステムは、ハードウェアを支援するドライバで構成され、カーネル特定（ｋｅｒｎｅｌ−ｓｐｅｃｉｆｉｃ）サービス用ドライバを含むことができる。基本的に、ＩＰ、ＴＣＰ及びＵＤＰプロトコルを支援することができる。ネットワークプロトコルスタックは、ＯＳ上に存在する。ＵＰｎＰの場合、ＨＴＴＰは、ＵＤＰを用いて送信することができる。
【０７３８】
ＵＰｎＰ ＤＣＰフレームワークは、ＵＰｎＰフォーラムに定義されたデバイス制御ポイントを意味することができる。
【０７３９】
ＳＳＤＰ（Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）は、ホームネットワークでネックワークに接続されたデバイスによって一つ以上のサービスを探すことができる。
【０７４０】
図４６は、第２スクリーンサービスアプリケーションのソフトウェア層を示す図である。
【０７４１】
図４６のソフトウェア層は、第２スクリーンサービスに必要な第２スクリーンサービスアプリケーションのソフトウェア構造を示す。図４６は、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
【０７４２】
図４６のそれぞれのエンティティの説明は、その役割及び機能において図４５と同一である。
【０７４３】
ＡＴＳＣ２．０トリガークライアントは、上述したトリガー、ＴＰＴ、ＡＭＴなどを受信し処理するモジュールを意味できる。このモジュールは、状況によって第２スクリーンデバイスに含まれてもよい。このモジュールが第２スクリーンデバイスに含まれると、このモジュールはＴＰＴ及びＡＭＴを直接処理し、アプリケーションのライフサイクルを直接チェックすることができる。
【０７４４】
図４７は、第２スクリーンアプリケーションライフサイクル管理による送信順序及び送信されたデータ間の違いを示すテーブルである。
【０７４５】
受信機は、放送ネットワークを通じてＤＴＶＣＣを用いてＴＰＴ及びＡＭＴを直接受信したり、インターネットネットワークを通じてＴＰＴ及びＡＭＴをダウンロードし、ＴＰＴ及びＡＭＴを処理する。上述した通り、ＴＰＴはイベント情報を含み、イベント情報は、ＥｖｅｎｔＩｄ、Ａｃｔｉｏｎ、Ｄｅｓｔｉｎａｔｉｏｎ及びＤａｔａ情報を含むことができる。“Ｅｖｅｎｔ＠Ｄｅｓｔｉｎａｔｉｏｎ”は、このイベント情報が発生する装置を示すことができる。例えば、あて先は、受信機又は第２スクリーンデバイスであってもよい。あて先が第２スクリーンデバイスに設定されると、受信機は、第２スクリーンデバイスにイベント情報を伝達しなければならない。
【０７４６】
このため、この情報を第２スクリーンデバイスに伝達する方法が必要である。第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションで管理することができる。
【０７４７】
図４７のテーブルは、どのエンティティが第２スクリーンアプリケーションのライフサイクルを支援するかによる情報伝達方法の概要を示す。
【０７４８】
第１行は、図５１の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
【０７４９】
第２行は、受信機が第２スクリーンアプリケーションのライフサイクルを管理する場合の説明の概要であってもよく、その詳細な説明は後述する。
【０７５０】
第３行は、受信機が第２スクリーンデバイスに必要なトリガー情報をフィルタリング（増加）し伝達する場合の説明の概要であってもよく、その詳細な説明は後述する。
【０７５１】
第４行は、図５８の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
【０７５２】
第５行は、図５７の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
【０７５３】
図４８は、中央集中型実行モデルの動作概念を示す図である。
【０７５４】
インタラクティブサービスを第２スクリーンデバイスに効率的に伝達する方法は、中央集中型実行モデル及び分散型実行モデルを含むことができる。
【０７５５】
中央集中型実行モデルの動作概念を示す図に示すように、ＴＶ受像機は、ＵＰｎＰのＲＵＩメカニズムを用いて、各第２スクリーンデバイス上にディスプレイされるＲＵＩを生成及びアップデートし、ネットワークを通じてＲＵＩを送信することができる。それぞれの第２スクリーンデバイスは、ＲＵＩクライアントを通じて実時間でＲＵＩを受信し、スクリーン上にＲＵＩをディスプレイすることができる。分散型実行モデルと違い、ＤＡＥは、プライマリデバイスに存在しうる。
【０７５６】
図４９は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの一実施例である。
【０７５７】
図４９のフローは、中央集中型実行モデルの動作概念の実施例で受信機が放送ネットワークを通じてインタラクティブサービスを得ることができ、第２スクリーンデバイスと連動する環境で中央集中型実行モデルメカニズムが適用される時の動作であってもよい。
【０７５８】
中央集中型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ４９０１０）、ＴＰＴを要求する段階（ｓ４９０２０）、応答としてＴＰＴを送信する段階（ｓ４９０３０）、ＴＰＴをパーシング（ｐａｒｓｅ）する段階（ｓ４９０４０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ４９０６０）、ＲＵＩを生成する段階（ｓ４９０７０）、ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９０８０）、スクリーン上にＵＩをディスプレイする段階（ｓ４９０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ４９１００）、入力データを送信する段階（ｓ４９１１０）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ４９１２０）、ＲＵＩをアップデートする段階（ｓ４９１３０）、ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９１４０）、及び／又はスクリーン上にＵＩをディスプレイする段階（ｓ４９１５０）を含むことができる。
【０７５９】
時間ベーストリガーを送信する段階（ｓ４９０１０）は、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて時間ベーストリガーを受信する段階を含むことができる。時間ベーストリガーは上述した通りである。
【０７６０】
ＴＰＴを要求する段階（ｓ４９０２０）は、受信機が、受信されたトリガーを解釈する段階、ＴＰＴを取得できるサーバーのＵＲＬを取得する段階、及びＴＰＴを要求できる段階を含むことができる。
【０７６１】
応答としてＴＰＴを送信する段階（ｓ４９０３０）は、ＴＰＴを要求する段階（Ｓ４９０２０）における要求に応答してＴＰＴを送信する段階を含むことができる。
【０７６２】
ＴＰＴをパーシングする段階（ｓ４９０４０）は、受信機が、要求されたＴＰＴをパーシングする段階を含むことができる。
【０７６３】
第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）は、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて第２スクリーンに対する実行トリガーを受信する段階を含むことができる。実行トリガーは、上述した活性化トリガーと同一であってもよい。
【０７６４】
ＴＤＯ／ファイルをダウンロードする段階（ｓ４９０６０）は、受信機が、受信されたＴＰＴから実行トリガー又は時間ベーストリガーと関連したＴＤＯ及びファイルに関する情報を取得する段階、及びコンテンツサーバーからトリガーで指示されたＴＤＯ及びファイルをダウンロードする段階を含むことができる。
【０７６５】
ＲＵＩを生成する段階（ｓ４９０７０）は、ダウンロードされたＴＤＯ及びファイルに対するＲＵＩを生成する段階を含むことができる。
【０７６６】
ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９０８０）は、受信機がＲＵＩプロトコルを用いて、第２スクリーン上に生成されたＲＵＩを送信する段階を含むことができる。
【０７６７】
スクリーン上にＵＩをディスプレイする段階（ｓ４９０９０）は、第２スクリーン上に、受信されたＲＵＩをディスプレイする段階を含むことができる。
【０７６８】
ユーザが新しいページに対するリンクをクリックする段階（ｓ４９１００）は、第２スクリーン上でユーザの選択によってＲＵＩ上の特定リンクをクリックする段階を含むことができる。
【０７６９】
入力データを送信する段階（ｓ４９１１０）は、クリックされた特定リンクが他のページに接続されると、受信機にユーザの入力情報を伝達する段階を含むことができる。
【０７７０】
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ４９１２０）は、受信機がユーザ入力と関連したＴＤＯ及びファイルをダウンロードする段階を含むことができる。
【０７７１】
ＲＵＩをアップデートする段階（ｓ４９１３０）は、ダウンロードされたＴＤＯ及びファイルによってＲＵＩをアップデートする段階を含むことができる。
【０７７２】
ＲＵＩプロトコルを通じてＲＵＩを送信する段階（ｓ４９１４０）は、受信機がＲＵＩプロトコルを用いて、アップデートされたＲＵＩを第２スクリーンに送信する段階を含むことができる。
【０７７３】
スクリーン上にＵＩをディスプレイする段階（ｓ４９１５０）は、第２スクリーン上にアップデートされたＲＵＩをディスプレイする段階を含むことができる。
【０７７４】
図５０は、受信機で第２スクリーンデバイスにＵＩ情報を知らせる方法の実施例を示す図である。
【０７７５】
図５０は、受信機が放送社からトリガーを受信してトリガーを第２スクリーンデバイスに伝達する論理的順序を示す。
【０７７６】
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５００１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５００３０）、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）、応答として互換可能なＵＩ情報を送信する段階（ｓ５００５０）、及び受信機に対する他のトリガーを受信する段階（ｓ５００６０）を含むことができる。
【０７７７】
受信機に対するトリガーを受信する段階（ｓ５００１０）は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。
【０７７８】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）は、プライマリデバイスが放送ストリームを通じて放送社から第２スクリーンサービスに対するトリガーを受信する段階を含むことができる。
【０７７９】
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５００３０）は、アップデートされたＵＩに対して通知する段階を含むことができる。上述した通り、放送プログラムを見る間にトリガーが受信されると、受信機は、トリガーが第２スクリーンデバイス又はプライマリデバイスに対するものかをチェックすることができる。この時、トリガーが第２スクリーンデバイスに対するものであれば、全てのＵＰｎＰデバイス又は特定ＵＰｎＰデバイスにのみ新しいＵＩ情報アップデートを通知することができる。これは、第２スクリーンデバイスがＵＰｎＰプロトコルを用いて加入した場合に該当しうる。
【０７８０】
アップデートされたＵＩ情報を要求する段階（ｓ５００４０）は、第２スクリーンデバイスがプライマリデバイスに、アップデートされたＵＩ情報を要求する段階を含むことができる。
【０７８１】
応答として互換可能なＵＩ情報を送信する段階（ｓ５００５０）は、プライマリデバイスが第２スクリーンデバイスに互換可能なＵＩ情報を送信する段階を含むことができる。
【０７８２】
受信機に対する他のトリガーを受信する段階（ｓ５００６０）は、受信機に対するトリガーを受信する段階と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
【０７８３】
受信機がトリガーモジュールを含んでもよいため、受信機は、放送ネットワーク又はインターネットネットワークを通じてＴＰＴ及びＡＭＴなどのＸＭＬファイルを受信し、ＸＭＬファイルをパーシングし、適切な動作を行うことができる。第２スクリーンデバイスを探すと、第２スクリーンデバイスに伝達されるアクション、ＴＤＯ ＵＲＬ及びデータは、Ｅｖｅｎｔ＠Ｄｅｓｔｉｎａｔｉｏｎフィールドを用いて認識することができる。第２スクリーンデバイスは、ＴＰＴ及びＡＭＴなどのＸＭＬファイルを直接受信しなくてもよく、よって、トリガーモジュールを含まなくてもよい。ＲｅｍｏｔｅＵＩクライアントサービスが含まれると、受信機は、全ての第２スクリーンアプリケーションのライフサイクルを管理することができる。逆に、いくつかの第２スクリーンデバイスが接続されると、第２スクリーンアプリケーションを制御するデータが数回送信されなければならない。
【０７８４】
図５１は、受信機で第２スクリーンデバイスにＵＩ情報を通知する方法の実施例を示す図である。
【０７８５】
図５０と違い、図５１は、第２スクリーンデバイスに適切に用いられると決定された第２スクリーンデバイスに対する全てのＵＩ情報が直接伝達される場合を示す。すなわち、第２スクリーンデバイスに対するＴＤＯ ＵＲＬを送信することができる。
【０７８６】
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５１０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０２０）、ＵＩ情報に対して通知する段階（ｓ５１０３０）、応答“ｏｋ”を送信する段階（ｓ５１０４０）、受信機に対するトリガーを受信する段階（ｓ５１０５０）、受信機に対するトリガーを受信する段階（ｓ５１０６０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０７０）、ＵＩ情報に対して通知する段階（ｓ５１０８０）、及び／又は応答“ｏｋ”を送信する段階（ｓ５１０９０）を含むことができる。
【０７８７】
受信機に対するトリガーを受信する段階（ｓ５１０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
【０７８８】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
【０７８９】
ＵＩ情報に対して通知する段階（ｓ５１０３０）は、ＵＩ情報アップデートに対して通知する段階を含むことができる。
【０７９０】
応答“ｏｋ”を送信する段階（ｓ５１０４０）は、ＵＩ通知が受信されたことを示すメッセージを送信する段階を含むことができる。
【０７９１】
受信機に対するトリガーを受信する段階（ｓ５１０５０）、及び受信機に対するトリガーを受信する段階（ｓ５１０６０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
【０７９２】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５１０７０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
【０７９３】
ＵＩ情報に対して通知する段階（ｓ５１０８０）は、ＵＩ情報に対して通知する段階（ｓ５１０３０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
【０７９４】
応答“ｏｋ”を送信する段階（ｓ５１０９０）は、応答“ｏｋ”を送信する段階（ｓ５１０４０）と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
【０７９５】
図５１の方法で、受信機は、どのＵＰｎＰデバイスが第２スクリーンデバイスであるか、及びいかなるデバイスプロファイルが含まれるかを知っていなければならない。特に、受信機は、第２スクリーンデバイスが第２スクリーンサービスを支援するかを知っていなければならない。
【０７９６】
トリガーが第２スクリーンデバイス又はプライマリデバイスに関するものかを決定した後に、ＵＩ情報に対して通知する方法、及び第２スクリーンデバイスに適切に用いられると決定された第２スクリーンデバイスに対する全てのＵＩ情報を伝達する方法（図５１の場合）は、受信機がＴＰＴ及びトリガーを処理し、ＴＤＯ ＵＲＬのみを第２スクリーンデバイスに伝達するという点で同一でありうる。これら２つの方法は、受信機がＴＤＯを第２スクリーンデバイスに間接的に伝達したり、受信機が各デバイスのデバイスプロファイルを直接記録し、第２スクリーンデバイスにのみ第２スクリーンアプリケーションの位置を通知するという点で異なりうる。
【０７９７】
図５２は、ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの実施例を示す図である。
【０７９８】
ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの一実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５２０１０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０２０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５２０３０）、イベントを申し込む段階（ｓ５２０４０）、ＨＴＴＰメッセージを返還する段階（ｓ５２０５０）、ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）及び／又はＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）を含むことができる。
【０７９９】
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５２０１０）は、受信機及び第２スクリーンデバイスを探す段階を含むことができる。ホームネットワークに新しく接続されたデバイス又はホームネットワークに既に接続されたデバイス（受信機又は第２スクリーンデバイス）は、ディスカバリのためのメッセージをマルチキャストすることができる。このとき、所望のサービスをマルチキャスティングを用いて探索することができ、複数の不特定ＵＰｎＰデバイスに対して全てのサービスを探索することができる。これは、デバイスによってどのサービスが提供されるかによって変更されてもよい。この段階で、第２スクリーンデバイスは、プライマリデバイスのデバイスプロファイルを知っていてもよい。プライマリデバイスは、デバイスプロファイルを処理し、適切なＵＩＬｉｓｔｉｎｇを生成することができる。ＲｅｍｏｔｅＵＩサーバーは、ＣｏｍｐａｔｉｂｌｅＵＩｓ ＸＳＤスキマー（ｓｃｈｅｍａ）を第２スクリーンデバイスに提供することができる。このスキマーは、アプリケーションのＵＲＬ、ＵＩに対する固有ｉｄ（“ｕｉＩＤ”）、ネーム、ｐｒｏｔｏｃｏｌＩｎｆｏなどを含むことができる。
【０８００】
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０２０）は、第２スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びＵＩＬｉｓｔｉｎｇを要求する段階を含むことができる。互換可能なＵＩが得られるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる（ＵＩＦｉｌｔｅｒは選択的であってもよい）。その詳細な説明は後述する。
【０８０１】
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５２０３０）は、プライマリデバイスが、要求によって、適切なＵＩリスティングを第２スクリーンデバイスに送信する段階を含むことができる。その詳細な説明は後述する。
【０８０２】
イベントを申し込む段階（ｓ５２０４０）は、プライマリデバイスの適切な露出されたイベントを申し込む段階を含むことができる。イベントを申し込む段階（ｓ５２０４０）は、ＲｅｍｏｔｅＵＩサーバーサービスによって提供されたイベント情報である“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”を受信するために選択的に行うことができる。Ｉｎ ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）で、第２スクリーンデバイスは、ＲｅｍｏｔｅＵＩのアドレスが変更されたり又はＵＩが変更されたという通知を受けることができる。すなわち、第２スクリーンデバイスがＵＩが変更された通知のみを受けるから、詳細な位置又は追加の情報が要求されると、“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションが受信機に送信され、“ＵＩＬｉｓｔｉｎｇ”値を得ることができる。
【０８０３】
ＨＴＴＰメッセージを返還する段階（ｓ５２０５０）は、イベントを申し込む段階（ｓ５２０４０）の結果を送信する段階を含むことができる。応答１を送信する段階（ｓ４０１００）と同様に、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答が状況によって伝送されうる。
【０８０４】
ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）は、加入者に“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを送信する段階を含むことができる。
【０８０５】
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）は、第２スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びＵＩＬｉｓｔｉｎｇを要求する段階を含むことができる。互換可能なＵＩが得られるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる。ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅメッセージを送信する段階（ｓ５２０６０）及びＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５２０７０）は、第２スクリーンアプリケーションが変更されず、サーバーによって支援される時にのみ選択的に可能なように時間設定を行う段階を含むことができる。この段階は選択的だ。この方法は、受信機でＵＰｎＰイベントを用いて、第２スクリーンサービスが存在することを全ての第２スクリーンデバイスに通知する方法であってもよい。すなわち、ホームネットワーク内の全ての第２スクリーンデバイスは第２スクリーンサービスと関連してＵＩが変更されたとの通知を受けることができる。全ての第２スクリーンデバイスにＵＰｎＰイベントにて“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数が通知されると、第２スクリーンデバイスは、ＵＩが新しくアップデートされたということを確認することができる。その後、第２スクリーンデバイスは、“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを行い、ハードウェア装置に適したＵＩを選択し、デバイスプロファイルを参考にすることによってＵＩを実行することができる。
【０８０６】
ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）は、プライマリデバイスが要求によって適切なＵＩリスティングを第２スクリーンデバイスに送信する段階を含むことができる。上述した通り、ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５２０８０）は、ＲｅｍｏｔｅＵＩのアドレスが変更されたりＵＩが変更されたことを申請した第２スクリーンデバイスに通知する段階を含むことができる。すなわち、第２スクリーンデバイスは、ＵＩが変更されたことのみが通知されるため、詳細な位置又は追加の情報が要求されると、“ＵＩＬｉｓｔｉｎｇ”を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを受信機に送信しなければならない。
【０８０７】
ＲｅｍｏｔｅＵＩサーバーサービスが動作すると、受信機は、要求する装置のデバイスプロファイルによって遠隔ＵＩ情報を提供しなければならない。逆互換性の観点から、デバイスプロファイル“ＤｅｖｉｃｅＩｎｆｏ”が交換され、後で受信機に“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求する時、ＲｅｍｏｔｅＵＩサーバーサービスによって送信されたＵＲＬが、要求するクライアントのプロファイルによって変更されうる。レガシーＵＰｎＰデバイスがＲｅｍｏｔｅＵＩサーバーに“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求すると、レガシーＵＰｎＰデバイスのＤｅｖｉｃｅＩｎｆｏに適したＵＩが提供されなければならない。しかし、第２スクリーンサービスを支援するデバイスが“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを要求すると、ＲｅｍｏｔｅＵＩサーバーサービス装置はさらにＵＲＬ情報を送信しなければならない。
【０８０８】
受信機は、ＤＴＶＣＣを通じてトリガー情報を得、トリガー情報からメディア時間及びイベント時間情報を得ることができる。このとき、“ａｐｐＩＤ”、“ＵＲＬ”（ＴＤＯ＿ＵＲＬ）、“ｅｖｅｎｔＩＤ”、“ａｃｔｉｏｎ”、及び、選択的に、ＴＤＯ又は実行時間に対する“Ｄａｔａ”は、“ｔ＝ｍｅｄｉａ＿ｔｉｍｅ”シンタックスを用いて確認できる。受信機が第２スクリーンアプリケーションのライフサイクルを管理すると、第２スクリーンサービスアプリケーションによって処理される情報の量が減少しうる。逆に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを直接管理すると、必要な情報が増加しうる。
【０８０９】
図５３は、分散型実行モデルの動作概念を示す図である。
【０８１０】
第２スクリーンデバイスにインタラクティブサービスを效率的に伝達する方法として、分散型実行モデルを説明する。
【０８１１】
分散型実行モデルの動作概念を示す図に示すように、ＴＶ受像機は、ＵＰｎＰなどを用いて第２スクリーンデバイスにトリガーなどの情報を伝達することができる。それぞれの第２スクリーンデバイスはトリガーハンドラーを有し、トリガーハンドラーを通じて受信されたトリガーなどの情報を実時間で処理することができる。ブラウザは、それと関連したインタラクティブサービスを実行することができる。
【０８１２】
中央集中型実行モデルと違い、各第２スクリーンデバイスにＤＡＥが存在してもよい。
【０８１３】
分散型実行モデルに基づいて第２スクリーンデバイスにインタラクティブサービスを伝達するプロセスは、次の順序で行うことができる。１．受信機は、第２スクリーン支援を有するセグメントを提示している。２．受信機は、第２スクリーン支援が利用可能な任意の指示をディスプレイする。３．ユーザは、第２スクリーンデバイス上で第２スクリーンアプリケーションを開始する。４．受信機及び第２スクリーンデバイスは、（受信機上のネイティブコード及びデバイス上の第２スクリーンアプリケーションによって行われる）ＵＰｎＰメカニズムを通じてお互い発見する。５．ＴＶ受像機は、（ＤＴＶＣＣストリーム又はＡＣＲから）トリガーを得、第２スクリーンデバイス上でＴＤＯを開始する。６．ＴＶ受像機は、トリガーをＴＰＴからの情報と結合し、活性化時間に第２スクリーンデバイスに送信する。７．第２スクリーンデバイスは、ＴＤＯ（一つ以上のファイル）をダウンロードしてブラウザで実行する。８．ユーザはＴＤＯと相互作用してＴＤＯが追加のファイルをダウンロードてきるようにする。９．受信機は、トリガーを得、第２スクリーンデバイス上でＴＤＯに対するイベントを生成する。１０．受信機はトリガーとＴＰＴからの情報とを結合し、活性化時間に第２スクリーンデバイスに送信する。１１．第２スクリーンデバイスは、ブラウザでＴＤＯに対する（ＤＶＢ ＳｔｒｅａｍＥｖｅｎｔのような）ＴｒｉｇｇｅｒＥｖｅｎｔを生成する。１２．ＴＤＯは、ＴｒｉｇｇｅｒＥｖｅｎｔによって要求されたアクションを行ってデータファイルをダウンロードすることができる。
【０８１４】
図５４は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローを示す図である。
【０８１５】
分散型実行モデルのフローは、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて受信された情報をそのまま第２スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
【０８１６】
分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ５４０１０）、時間ベーストリガーを送信する段階（ｓ５４０２０）、ＴＰＴを要求する段階（ｓ５４０３０）、ＴＰＴを応答として送信する段階（ｓ５４０４０）、ＴＰＴをパーシングする段階（ｓ５４０５０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）、実行トリガーを送信する段階（ｓ５４０７０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）、ブラウザでＴＤＯを実行する段階（ｓ５４０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）、及びブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）を含むことができる。
【０８１７】
時間ベーストリガーを送信する段階（ｓ５４０１０）は、時間ベーストリガーを送信する段階（ｓ４９０１０）と同一であってもよい。
【０８１８】
時間ベーストリガーを送信する段階（ｓ５４０２０）は、受信機が受信されたトリガーをそのまま第２スクリーンに送信する段階を含むことができる。
【０８１９】
ＴＰＴを要求する段階（ｓ５４０３０）は、第２スクリーンが受信されたトリガーを解釈する段階、ＴＰＴが得られるサービスのＵＲＬを取得する段階、及びＴＰＴを要求できる段階を含むことができる。
【０８２０】
応答としてＴＰＴを送信する段階（ｓ５４０４０）は、ＴＰＴを要求する段階（ｓ５４０３０）における要求に応答してＴＰＴを送信する段階を含むことができる。
【０８２１】
ＴＰＴをパーシングする段階（ｓ５４０５０）は、要求されたＴＰＴをパーシングする段階を含むことができる。
【０８２２】
第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）は、第２スクリーンに対する実行トリガーを送信する段階（ｓ４９０５０）と同一であってもよい。
【０８２３】
実行トリガーを送信する段階（ｓ５４０７０）は、受信機が受信されたトリガーをそのまま第２スクリーンに送信する段階を含むことができる。
【０８２４】
ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）は、ＴＰＴからのトリガーと関連したＴＤＯ／ファイルを得る段階、及びコンテンツサーバーからＴＤＯ／ファイルをダウンロードする段階を含むことができる。
【０８２５】
ブラウザでＴＤＯを実行する段階（ｓ５４０９０）は、ダウンロードされたＴＤＯ及びファイルをブラウザ上で実行する段階を含むことができる。
【０８２６】
ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）は、ユーザが、実行されたＴＤＯ上で特定リンクをクリックする段階を含むことができる。
【０８２７】
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）は、他のＴＤＯへの特定リンクが確立されると、関連したＴＤＯ／ファイルをダウンロードする段階を含むことができる。
【０８２８】
ブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）は、ブラウザ上で関連したＴＤＯ及びファイルを実行する段階を含むことができる。
【０８２９】
図５５は、分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローを示す図である。
【０８３０】
分散型実行モデルのフローは、受信機がＤＴＶＣＣ又はＡＣＲサーバーを通じて受信された情報をそのまま第２スクリーンに送信せず、第２スクリーンに適したトリガーによって必要な情報を挿入し、その情報を拡張されたトリガーに変更し、その情報を第２スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
【０８３１】
分散型実行モデルベース受信機及び第２スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階（ｓ５５０１０）、ＴＰＴを要求する段階（ｓ５５０２０）、応答としてＴＰＴを送信する段階（ｓ５５０３０）、ＴＰＴをパーシングする段階（ｓ５５０４０）、第２スクリーンに対する実行トリガーを送信する段階（ｓ５５０５０）、拡張されたトリガーを生成する段階（ｓ５５０６０）、拡張されたトリガーを送信する段階（ｓ５５０７０）、ＴＤＯ／ファイルをダウンロードする段階（ｓ５５０８０）、ブラウザでＴＤＯを実行する段階（ｓ５５０９０）、ユーザが新しいページに対するリンクをクリックする段階（ｓ５５１００）、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５５１１０）、及び／又はブラウザで新しいＴＤＯを実行する段階（ｓ５５１２０）を含むことができる。
【０８３２】
時間ベーストリガーを送信する段階（ｓ５５０１０）は、時間ベーストリガーを送信する段階（ｓ５４０１０）と同一であってもよい。
【０８３３】
ＴＰＴを要求する段階（ｓ５５０２０）は、ＴＰＴを要求する段階（ｓ５４０３０）と同一であってもよい。
【０８３４】
応答としてＴＰＴを送信する段階（ｓ５５０３０）は、応答としてＴＰＴを送信する段階（ｓ５４０４０）と同一であってもよい。
【０８３５】
ＴＰＴをパーシングする段階（ｓ５５０４０）は、ＴＰＴをパーシングする段階（ｓ５４０５０）と同一であってもよい。
【０８３６】
第２スクリーンに対する実行トリガーを送信する段階（ｓ５５０５０）は、第２スクリーンに対する実行トリガーを送信する段階（ｓ５４０６０）と同一であってもよい。
【０８３７】
拡張されたトリガーを生成する段階（ｓ５５０６０）は、受信機がＴＰＴからのトリガーと関連したＴＤＯ及びファイルに関する情報を取得する段階、及びそれを含む拡張されたトリガーを生成する段階を含むことができる。
【０８３８】
拡張されたトリガーを送信する段階（ｓ５５０７０）は、受信機が拡張されたトリガーを第２スクリーンに送信する段階を含むことができる。
【０８３９】
ＴＤＯ／ファイルをダウンロードする段階（ｓ５５０８０）は、ＴＤＯ／ファイルをダウンロードする段階（ｓ５４０８０）と同一であってもよい。
【０８４０】
ブラウザでＴＤＯを実行する段階（ｓ５５０９０）は、ブラウザでＴＤＯを実行する段階（ｓ５４０９０）と同一であってもよい。
【０８４１】
ユーザが新しいページに対するリンクをクリックする段階（ｓ５５１００）は、ユーザが新しいページに対するリンクをクリックする段階（ｓ５４１００）と同一であってもよい。
【０８４２】
新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５５１１０）は、新しいＴＤＯ／ファイルをダウンロードする段階（ｓ５４１１０）と同一であってもよい。
【０８４３】
ブラウザで新しいＴＤＯを実行する段階（ｓ５５１２０）は、ブラウザで新しいＴＤＯを実行する段階（ｓ５４１２０）と同一であってもよい。
【０８４４】
図５６は、受信機が第２スクリーンデバイスにＴＤＯ及びイベント情報を通知する方法の一実施例を示す図である。
【０８４５】
図５６は、受信機がトリガー及びＴＰＴを受信し、トリガーによって処理を行い、第２スクリーンデバイスに対するトリガーが到達すると、トリガーをＴＰＴと比較して、第２スクリーンデバイスに認識される必要がある情報を抽出してＸＭＬファイルの形態で構成し、その情報を第２スクリーンデバイスに送信する方法を示す。この方法は、第２スクリーンデバイスが活発に動作して予測を行えるという点で有利である。
【０８４６】
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５６０１０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０２０）、ＴＰＴ及びトリガーを変換（ｔｒａｎｓｌａｔｅ）し、イベント情報を生成する段階（ｓ５６０３０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６０４０）、応答“ｏｋ”を送信する段階（ｓ５６０５０）、受信機に対するトリガーを受信する段階（ｓ５６０６０）、受信機に対するトリガーを受信する段階（ｓ５６０７０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）、及び応答“ｏｋ”を送信する段階（ｓ５６１１０）を含むことができる。
【０８４７】
受信機に対するトリガーを受信する段階（ｓ５６０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
【０８４８】
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０２０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
【０８４９】
ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０３０）は、ＴＰＴ及びトリガーを解釈する段階、及びイベントを生成する段階を含むことができる。生成された情報は、新しいデータ構造を生成するために、ＴＰＴに含まれた情報及びトリガーを結合するのに用いられ、どのようなＴＤＯが生成されたか、又はいつＴＤＯが生成されたかに関する情報を含むことができる。このデータ構造は後述する。新しいデータ構造が決定されると、ＴＤＯ ＵＲＬに加えて、様々な必要な情報が送信されうる。
【０８５０】
ＴＤＯ及びイベントを送信する段階（ｓ５６０４０）は、生成されたイベント情報及びＴＤＯを第２スクリーンデバイスに送信する段階を含むことができる。
【０８５１】
応答“ｏｋ”を送信する段階（ｓ５６０５０）は、受信されたＴＤＯ及びイベント情報が受信されたことを示すメッセージを送信する段階を含むことができる。
【０８５２】
受信機に対するトリガーを受信する段階（ｓ５６０６０）、及び受信機に対するトリガーを受信する段階（ｓ５６０７０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。
【０８５３】
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。
【０８５４】
ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）は、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０３０）と同一であってもよい。
【０８５５】
ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）は、ＴＤＯ及びイベント情報を送信する段階（ｓ５６０４０）と同一であってもよい。
【０８５６】
応答“ｏｋ”を送信する段階（ｓ５６１１０）は、応答“ｏｋ”を送信する段階（ｓ５６０５０）と同一であってもよい。
【０８５７】
受信機に対するトリガーを受信する段階（ｓ５６０６０）、受信機に対するトリガーを受信する段階（ｓ５６０７０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５６０８０）、ＴＰＴ及びトリガーを変換してイベント情報を生成する段階（ｓ５６０９０）、ＴＤＯ及びイベント情報を送信する段階（ｓ５６１００）、及び応答“ｏｋ”を送信する段階（ｓ５６１１０）は、上述した動作と同一であってもよい。
【０８５８】
図５７は、第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーションにアクセスする方法の実施例を示す図である。
【０８５９】
第２スクリーンデバイスは、受信機がＴＰＴ及びＡＭＴなどのＸＭＬファイルを受信したり、インターネットを通じてＴＰＴ及びＡＭＴサーバーアドレスを知ると、第２スクリーンアプリケーションを直接実行できる独立装置である。この場合、トリガーモジュールが第２スクリーンデバイスに含まれる。第２スクリーンデバイスは、受信機によって受信されたｉＴＶメッセージに対するＵＲＩストリングを受信することができる。このメッセージは、１）ＲｅｍｏｔｅＵＩサーバーサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法、及び２）ＲｅｍｏｔｅＵＩクライアントサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法の両方に適用することができる。
【０８６０】
まず、ＲｅｍｏｔｅＵＩサーバーサービスの場合、ｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法を説明する。
【０８６１】
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５７０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０２０）、アップデートされたＵＩ情報に関する通知を送信する段階（ｓ５７０３０）、アップデートされたＵＩ情報を要求する段階（ｓ５７０４０）、応答としてＵＩ情報を送信する段階（ｓ５７０５０）、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０８０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７０９０）、アップデートされたＵＩ情報を要求する段階（ｓ５７１００）、応答としてＵＩ情報を送信する段階（ｓ５７１１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７１２０）、アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７１３０）、アップデートされたＵＩ情報を要求する段階（ｓ５７１４０）、応答としてＵＩ情報を送信する段階（ｓ５７１５０）、第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）、及び／又は第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）を含むことができる。
【０８６２】
受信機に対するトリガーを受信する段階（ｓ５７０１０）は、受信機に対するトリガーを受信する段階（ｓ５００１０）と同一であってもよい。第１トリガーは、第２スクリーンデバイスに対するものではないから、受信機はトリガーを第２スクリーンデバイスに伝達しない。
【０８６３】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。トリガーは、第２スクリーンサービスに対するメディア時間に関する情報を有することができる。第２トリガーは、上述したプリロード（ｐｒｅ−ｌｏａｄ）トリガーとして機能し得る。
【０８６４】
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７０３０）は、アップデートされたＵＩ情報を通知する段階を含むことができる。第２トリガーは、第２スクリーンデバイスに対するものであるから、受信機は受信されたＵＲＩＳｔｒｉｎｇを第２スクリーンデバイスに送信することができる。このとき、第２スクリーンデバイスは、新しい情報が存在するという通知を受けることができ、この情報を直接読み取ることができる。
【０８６５】
アップデートされたＵＩ情報を要求する段階（ｓ５７０４０）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
【０８６６】
応答としてＵＩ情報を送信する段階（ｓ５７０５０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。この時、第２トリガーが送信されてもよい。
【０８６７】
ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）は、第２スクリーンデバイスがプライマリデバイスから受信された情報（第２トリガー）をパーシングする段階、及びＴＰＴサーバーにＴＰＴ ＸＭＬファイルを要求する段階を含むことができる。
【０８６８】
ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）は、第２スクリーンデバイスがＴＰＴサーバーから要求されたＴＰＴ ＸＭＬファイルをダウンロードする段階を含むことができる。
【０８６９】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５７０８０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第３トリガーは、第２スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第３トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
【０８７０】
アップデートされたＵＩ情報に関する通知を送信する段階（ｓ５７０９０）は、アップデートされたＵＩ情報を通知する段階を含むことができる。第３トリガーが第２スクリーンデバイスと関連したものと決定されるため、受信機は、第３トリガーを第２スクリーンデバイスに通知することができる。
【０８７１】
アップデートされたＵＩ情報を要求する段階（ｓ５７１００）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
【０８７２】
応答としてＵＩ情報を送信する段階（ｓ５７１１０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。このとき、第３トリガーが送信されてもよい。しかし、第３トリガーは、メディア時間トリガーであるから、第２スクリーンデバイスのメディア時間のみを制御することができる。このため、第２スクリーンデバイス及び受信機間のメディア時間同期化を行うことができる。
【０８７３】
第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５７１２０）は、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第４トリガーは、第２スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第４トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
【０８７４】
アップデートされたＵＩ情報に対する通知を送信する段階（ｓ５７１３０）は、アップデートされたＵＩを通知する段階を含むことができる。第４トリガーは、第２スクリーンデバイスと関連したものと決定されるため、受信機は第２スクリーンデバイスに第４トリガーを通知することができる。
【０８７５】
アップデートされたＵＩ情報を要求する段階（ｓ５７１４０）は、アップデートされたＵＩ情報を要求する段階（ｓ５００４０）と同一であってもよい。
【０８７６】
応答としてＵＩ情報を送信する段階（ｓ５７１５０）は、プライマリデバイスがＵＩ情報を第２スクリーンデバイスに送信する段階を含むことができる。このとき、第４トリガーが送信されてもよい。
【０８７７】
第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）は、第２スクリーンデバイスが第４トリガーに関する情報をチェックする段階、及びＴＤＯ ＵＲＬの位置の第２スクリーンアプリケーションをダウンロードするためにアプリケーションサーバーに第２スクリーンアプリケーションを要求する段階を含むことができる。
【０８７８】
第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）は、要求によって第２スクリーンアプリケーションをダウンロードする段階を含むことができる。第２スクリーンアプリケーションがダウンロードされ、Ｅｖｅｎｔ＠Ａｃｔｉｏｎを行うことができる。このとき、アプリケーションサーバーに第２スクリーンデバイスのブラウザに関する情報を通知するので、アプリケーションサーバーは、どの第２スクリーンデバイスが接続されるかを容易にチェックすることができる。したがって、アプリケーションは自動で選択され、サーバーからダウンロードされることが可能である。
【０８７９】
要約すると、ｉＴＶメッセージに対するＵＲＩストリングがＤＴＶＣＣを通じて受信されると、受信機は、新しいＵＩがアップデートされたということを示すイベントを、発見された第２スクリーンデバイスに送信することができる。第２スクリーンデバイスは、イベント情報をチェックし、新しいＵＩ情報を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを送信することができる。受信機は、ＴＰＴサーバーの受信されたＵＲＩ情報を送信することができる。この方法によって、第２スクリーンデバイスはＵＲＩ情報を受信し、ＴＰＴ及びＡＭＴ情報を直接処理し、第２スクリーンアプリケーションを直接制御することができる。
【０８８０】
このプロセスは、ＡＴＳＣ２．０トリガークライアントが第２スクリーンサービスアプリケーションに含まれる場合に可能である。
【０８８１】
図５８は、第２スクリーンデバイスがＴＰＴ及び第２スクリーンアプリケーションをアクセスする方法の実施例を示す図である。
【０８８２】
上述した２つの方法のうち、ＲｅｍｏｔｅＵＩクライアントサービスの場合にｉＴＶメッセージ（トリガー）に対するＵＲＩストリングを送信する方法を説明する。
【０８８３】
このプロセスは、受信機に対するトリガーを受信する段階（ｓ５８０１０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０２０）、トリガーを通知する段階（ｓ５８０３０）、応答“ｏｋ”を送信する段階（ｓ５８０４０）、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５８０５０）、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５８０６０）、第２スクリーンデバイスに対するトリガーを受信する段階（ｓ５８０７０）、トリガーを通知する段階（ｓ５８０８０）、応答“ｏｋ”を送信する段階（ｓ５８０９０）、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８１００）、トリガーを通知する段階（ｓ５８１１０）、応答“ｏｋ”を送信する段階（ｓ５８１２０）、第２スクリーンアプリケーションを要求する段階（ｓ５８１３０）及び／又は第２スクリーンアプリケーションを返還する段階（ｓ５８１４０）を含むことができる。
【０８８４】
受信機に対するトリガーを受信する段階（ｓ５８０１０）は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。第１トリガーが受信機に対するものであるから、第１トリガーは第２スクリーンデバイスに伝達されない。
【０８８５】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０２０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第２トリガーは、第２スクリーンサービスに対するトリガーであり、メディア時間に関する情報を有することができる。第２トリガーは、上述したプリロードトリガーとして機能し得る。
【０８８６】
トリガーを通知する段階（ｓ５８０３０）は、図５７と違い、第２スクリーンデバイスに直ちにトリガーを送信する段階を含むことができる。ｉＴＶメッセージに対するＵＲＩストリングがＤＴＶＣＣを通じて受信されると、受信機は、“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションを用いて、受信機によって受信されたＵＲＩ値を第２スクリーンデバイスに伝達することができる。
【０８８７】
応答“ｏｋ”を送信する段階（ｓ５８０４０）は、トリガーが受信されたことを示すメッセージを送信する段階を含むことができる。
【０８８８】
ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５８０５０）は、ＴＰＴ ＸＭＬファイルを要求する段階（ｓ５７０６０）と同一であってもよい。第２スクリーンデバイスに含まれるトリガーモジュールは、受信されたＵＲＩ値を用いてＴＰＴサーバーにアクセスし、ＴＰＴ及びＡＭＴファイルをダウンロードし、第２スクリーンアプリケーションを直接制御することができる。
【０８８９】
ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５８０６０）は、ＴＰＴ ＸＭＬファイルを返還する段階（ｓ５７０７０）と同一であってもよい。
【０８９０】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８０７０）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第３トリガーは、第２スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第３トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
【０８９１】
トリガーを通知する段階（ｓ５８０８０）は、トリガーを通知する段階（ｓ５８０３０）と同様に、トリガーを伝達する段階を含むことができる。
【０８９２】
応答“ｏｋ”を送信する段階（ｓ５８０９０）は、応答“ｏｋ”を送信する段階（ｓ５８０４０）と同一であってもよい。
【０８９３】
第２スクリーンサービスに対するトリガーを受信する段階（ｓ５８１００）は、第２スクリーンサービスに対するトリガーを受信する段階（ｓ５００２０）と同一であってもよい。第４トリガーは、第２スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第４トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
【０８９４】
トリガーを通知する段階（ｓ５８１１０）は、トリガーを通知する段階（ｓ５８０３０）と同様に、トリガーを伝達する段階を含むことができる。
【０８９５】
応答“ｏｋ”を送信する段階（ｓ５８１２０）は、応答“ｏｋ”を送信する段階（ｓ５８０４０）と同一であってもよい。
【０８９６】
第２スクリーンアプリケーションを要求する段階（ｓ５８１３０）は、第２スクリーンアプリケーションを要求する段階（ｓ５７１６０）と同一であってもよい。
【０８９７】
第２スクリーンアプリケーションを返還する段階（ｓ５８１４０）は、第２スクリーンアプリケーションを返還する段階（ｓ５７１７０）と同一であってもよい。
【０８９８】
すなわち、受信機は、常に、第２スクリーンサービスと関連したイベント情報を有するトリガーを第２スクリーンデバイスに伝達することができ、第２スクリーンデバイスは、ダウンロードされたＴＰＴ情報を用いて直ちに動作することができる。メディア時間トリガーがＤＴＶＣＣを用いて周期的に伝達されるため、受信機は、この情報を連続して伝達しなければならない。
【０８９９】
プライマリデバイス又は第２スクリーンデバイスがＴＰＴ ＸＭＬを有するので、イベントトリガーがライブトリガーサーバーから実時間で伝送される時にＡＭＴも受信されうる。
【０９００】
上述した２つの方法は、いかなるＵＲＬ値が適用されるかによって異なるように行われ、受信機の動作又は第２スクリーンサービスアプリケーションの構造及び動作は変更されてもよい。
【０９０１】
第２スクリーンサービスのシグナリングメカニズムを説明する。
【０９０２】
第２スクリーンサービスは、２つの方法、すなわち、受信機が、第２スクリーンサービスが存在するということを通知する第１方法、及び第２スクリーンデバイスがホームネットワークに接続されると、第２スクリーンサービスを提供する電子装置を検出するために装置及びサービスを探す第２方法を用いてシグナルすることができる。代案として、受信機は、新しい電子装置のデバイス記述語を確認し、サービス記述語を要求することができる。
【０９０３】
以下、放送シグナリング及びユニキャストシグナリングを説明する。
【０９０４】
放送シグナリングの場合、第２スクリーンデバイスは、ＲｅｍｏｔｅＵＩサーバーサービスを検出し、デバイス記述語を確認し、第２スクリーンデバイスと互換可能なＤｅｖｉｃｅＩｎｆｏプロファイルを要求する。イベントを受信でき、受信機に見られるプログラムによって変更されるＴＤＯ（インタラクティブアプリケーション）のＵＲＬを受信することができる。
【０９０５】
逆に、ユニキャストシグナリングの場合、受信機は、第２スクリーンデバイスのＤｅｖｉｃｅＩｎｆｏが互換可能か否かを確認し、互換可能なＴＤＯ ＵＲＬを送信することができる。ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションは、現在実行される第２スクリーンアプリケーションを終了してディスプレイメッセージなどのアクションを支援し、現在実行されるＵＩを終了するように送信されうる。受信機でパーシングされ処理される追加のＥｖｅｎｔ＠ｄａｔａが、ＰｒｏｃｅｓｓＩｎｐｕｔアクションによって第２スクリーンサービスアプリケーションに伝達されうる。
【０９０６】
以下、放送シグナリング及びユニキャストシグナリングを説明する。
【０９０７】
図５９は、ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの他の実施例である。
【０９０８】
放送シグナリングで、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
【０９０９】
ＲｅｍｏｔｅＵＩサーバーサービスに対する放送シグナリングの他の実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５９０１０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５９０４０）、及び／又はＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５９０５０）を含むことができる。
【０９１０】
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５９０１０）は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５８０１０）と同一の段階であってもよい。
【０９１１】
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）は、“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを全てのＵＰｎＰデバイスに送信する段階であってもよい。プライマリデバイスは、ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅのアナウンスメント（ａｎｎｏｕｎｃｅｍｅｎｔ）を、固有“ｕｉＩＤ”リストを有するＵＰｎＰデバイスに送信することができる。第２スクリーンデバイスは、このメッセージを受けた後、ｕｉＩＤをチェックすることができる。しかし、特定ｕｉＩＤとマッチングされず、この第２ストリーム装置ではＵＩアップデートが行われなくてもよい。
【０９１２】
ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）は、“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”メッセージを全てのＵＰｎＰデバイスに送信する段階であってもよい。この時は、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０２０）の場合とは違い、マッチングされるｕｉＩＤが存在し得る。
【０９１３】
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５９０４０）は、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５９０３０）でｕｉＩＤがマッチングされるため、第２スクリーンデバイスが自身のデバイスプロファイルを送信し、ＵＩＬｉｓｔｉｎｇを要求することができる。互換可能なＵＩを取得できるＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓアクションを用いることができる。
【０９１４】
ＵＩＬｉｓｔｉｎｇを返還する段階（ｓ５９０５０）は、プライマリデバイスが第２スクリーンデバイスに、要求に応じた適切なＵＩ Ｌｉｓｔｉｎｇを送信する段階であってもよい。
【０９１５】
図６０は、第２スクリーンサービスのための装置ディスカバリ及び装置能力交換の一実施例である。
【０９１６】
前述したとおり、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
【０９１７】
受信機のデバイス記述語とサービス記述語を受信した、全てのホームネットワークに接続したＵＰｎＰデバイスは、自身のデバイス記述語の位置をＨＴＴＰの“ＬＯＣＡＴＩＯＮ”ヘッダーで送ることができる。すなわち、ＵＰｎＰデバイス記述語の位置を送信して自身を知らせることができる。“ＬＯＣＡＴＩＯＮ”にＨＴＴＰ ＧＥＴ要求をすると、当該装置に関する情報がわかるＸＭＬファイルを受信することができる。
【０９１８】
ＵＰｎＰデバイス及びサービスディスカバリ過程で、プライマリデバイスが、第２スクリーンサービスが可能な第２スクリーンデバイスを探す方法を紹介する。この方法は、２つに大別することができる。その第一は、第２スクリーンデバイスが２種類のデバイスプロファイルを準備しておき、このデバイスプロファイルのＸＭＬファイルをＨＴＴＰヘッダーで知らせる方法である。このとき、互換されないプライマリデバイスは、理解できないＨＴＴＰヘッダーはそのまま無視すると仮定することができる。その第二は、デバイスプロファイルのうち、第２スクリーンサービスを提供する第２スクリーンデバイスという情報を“Ｐｒｏｔｏｃｏｌ Ｉｎｆｏ”に含む方法である。
【０９１９】
図６０は、第一の方式を例示するものである。
【０９２０】
第２スクリーンサービスに対する装置ディスカバリ及び装置能力交換の一実施例は、第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ６０００１）、ＵＰｎＰデバイスを探す段階（ｓ６００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ６００２０）、デバイス記述を要求する段階（ｓ６００３０）、デバイス記述を受信する段階（ｓ６００４０）、サービス制御記述（ｄｅｓｃｒｉｐｔｉｏｎ）を要求する段階（ｓ６００５０）、サービス制御記述を受信する段階（ｓ６００６０）、デバイスプロファイルを要求する段階（ｓ６００７０）、デバイスプロファイルを受信する段階（ｓ６００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ６００９０）、応答１を送信する段階（ｓ６０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ６０１１０）、応答２を送信する段階（ｓ６０１２０）、及び／又はユーザがスクリーン上のボタンをクリックする段階（ｓ６０１３０）を含むことができる。
【０９２１】
第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ６０００１）、ＵＰｎＰデバイスを探す段階（ｓ６００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ６００２０）、デバイス記述を要求する段階（ｓ６００３０）、デバイス記述を受信する段階（ｓ６００４０）、サービス制御記述を要求する段階（ｓ６００５０）、サービス制御記述を受信する段階（ｓ６００６０）、デバイスプロファイルを要求する段階（ｓ６００７０）、デバイスプロファイルを受信する段階（ｓ６００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ６００９０）、応答１を送信する段階（ｓ６０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ６０１１０）、応答２を送信する段階（ｓ６０１２０）、及びユーザがスクリーン上のボタンをクリックする段階（ｓ６０１３０）は、それぞれ順に、第２スクリーンサービスに対するＵＰｎＰアプリケーションを実行する段階（ｓ４０００１）、ＵＰｎＰデバイスを探す段階（ｓ４００１０）、ＲｅｍｏｔｅＵＩＣｌｉｅｎｔを探す段階（ｓ４００２０）、デバイス記述を要求する段階（ｓ４００３０）、デバイス記述を受信する段階（ｓ４００４０）、サービス制御記述を要求する段階（ｓ４００５０）、サービス制御記述を受信する段階（ｓ４００６０）、デバイスプロファイルを要求する段階（ｓ４００７０）、デバイスプロファイルを受信する段階（ｓ４００８０）、遠隔ＵＩのＵＲＬを送る（ｐｕｔ）段階（ｓ４００９０）、応答１を送信する段階（ｓ４０１００）、ＲｅｍｏｔｅＵＩクライアントサービスにメッセージを送信する段階（ｓ４０１１０）、応答２を送信する段階（ｓ４０１２０）、及びユーザがスクリーン上のボタンをクリックする段階（ｓ４０１３０）と同一の段階であってもよい。
【０９２２】
第一の方式は、図６０に示すように、ＵＰｎＰデバイスを探す段階（ｓ６００１０）段階後にＨＴＴＰヘッダーから得る“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーで第２スクリーンサービスを支援するデバイスプロファイルの位置を知らせることができる。Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ：ｈｔｔｐ：／／１０．１７７．５６．３６：３７９００／ＡＴＳＣ２ｎｄＳｃｒｅｅｎＲｅｍｏｔｅＵＩＣｌｉｅｎｔ１．ｘｍｌ\ｒ\ｎと表示された部分が“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーである。受信機は、“ＬＯＣＡＴＩＯＮ”ヘッダーは無視し、その代わりに“Ｘ−ＡＴＳＣ−ＣＯＭＰＡＮＩＯＮ−ＬＯＣＡＴＩＯＮ”ヘッダーから、受信機の所望する情報である第２スクリーンデバイスのデバイスプロファイルを得ることができる。
【０９２３】
プライマリデバイスが、第２スクリーンサービスが可能な第２スクリーンデバイスを探す方法のうち、前述した第二の方式は、“ＬＯＣＡＴＩＯＮ”ヘッダーの位置でデバイスプロファイルを得、デバイスプロファイル内で第２スクリーンデバイスの“Ｐｒｏｔｏｃｏｌ Ｉｎｆｏ”エレメントの値をパーシングして処理することができる。これは、前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階で行うことができる。
【０９２４】
特定ＵＰｎＰデバイスのデバイス記述語には提供可能なサービスのリストがあり、一つ或いは複数個のサービスを提供するという事実がわかる。ＵＰｎＰデバイスが有しているそれぞれのサービスは、遠隔の他のＵＰｎＰデバイスで制御可能であり、イベントを受信することができる。ただし、イベント受信は、提供するサービスがイベントで知らせ得る機能がある場合にのみ可能である。ＵＰｎＰデバイスが提供するサービスは、“制御”，“コントロール”そして“イベント”ができるようにＵＲＬを知らせることができる。
【０９２５】
図６１は、ＵＰｎＰフォーラムのＤｅｖｉｃｅＰｒｏｆｉｌｅ ＸＭＬスキマーの一実施例である。
【０９２６】
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階についてさらに説明する。この段階は、第２スクリーンデバイスからＲｅｍｏｔｅＵＩサーバーサービスのある受信機に、第２スクリーンデバイスに合う条件のＵＩがあるか問うことであり、“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”には、図６１のようなＸＳＤファイルのような形式を有しなければならない。
【０９２７】
したがって、第２スクリーンデバイスは受信機に、図６１のような形式で自身のデバイスプロファイルと合う情報を入れて送信しなければならない。
【０９２８】
図６２は、第２スクリーンデバイスのデバイスプロファイルの一実施例である。
【０９２９】
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階についてさらに説明する。この段階で、図６２は、デバイスプロファイルの一例を示している。ＵＩＬｉｓｔｉｎｇ要求（ｓ５８０２０）段階で、図示のデバイスプロファイルのような情報を受信機に送ることができる。
【０９３０】
第２スクリーンデバイスが探そうとするデバイスプロファイルの第２スクリーンサービスが、受信機にあるか否か検索することであり、図示の情報を“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”変数に格納して送信することができる。受信機では“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報を確認し提供すべきサービスタイプ、バージョン、第２スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式等を定義することができる。
【０９３１】
図６３は、第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの説明の一実施例である。
【０９３２】
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）及びＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）についてさらに説明する。
【０９３３】
前述したとおり、受信機では“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報を確認し提供すべきサービスタイプ、バージョン、第２スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式などを定義することができる。“第２スクリーンサービスに対するＰｒｏｔｏｃｏｌｎｆｏの記述の一実施例”は、“ＩｎｐｕｔＤｅｖｉｃｅＰｒｏｆｉｌｅ”情報の一実施例であってもよい。
【０９３４】
図示のような情報を用いて受信機に伝達した時（ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０））、ＸＭＬ形態となっているＵＩＬｉｓｉｎｇ情報を第２スクリーンデバイスに送信する（ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０））。
【０９３５】
もし、ＲｅｍｏｔｅＵＩサーバーサービスで所望する第２スクリーンデバイスを支援しない他の装置であると、ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）でエラー情報をリターンして、第２スクリーンサービスを支援できないＲｅｍｏｔｅＵＩサーバーサービスであることを知らせることができる。
【０９３６】
図６４は、第２スクリーンデバイスでＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｔｅＵＩＬｉｓｔｉｎｇが実行される間のＵＩＬｉｓｔｉｎｇの一実施例である。
【０９３７】
前述したＲｅｍｏｔｅＵＩサーバーサービス＃１に対する放送シグナリングの一実施例のうち、ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）及びＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）についてさらに説明する。
【０９３８】
ＵＩＬｉｓｔｉｎｇを要求する段階（ｓ５８０２０）後に、受信機は、互換されるＲｅｍｏｔｅＵＩ情報を探し、要求した第２スクリーンデバイスに伝達することができる（ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０））。ＵＩＬｉｓｔｉｎｇを送信する段階（ｓ５８０３０）で受信された情報は、図６４に示す。
【０９３９】
この受信された情報は、受信機が第２スクリーンに送信する時、ＴＰＴ及びＡＭＴを処理してＴＤＯ ＵＲＬを入れるものであってもよい。したがって、第２スクリーンデバイスは、Ｒｅｍｏｔｅ ＵＩの情報のみを受信機から得、第２スクリーンアプリケーションは、ホームネットワーク外のインターネットアプリケーションサーバーからダウンロードして実行することができる。このとき、実行することは、第２スクリーンサービスアプリケーションが担当することができる。
【０９４０】
一方では、放送社からあらかじめ放送網や受信機に第２スクリーンデバイスのための第２スクリーンアプリケーションを送信してもよい。この場合には、受信機が第２スクリーンサービスのためのアプリケーションを保存しておき、直接サービスすることができる。この場合、ウェブサーバーが受信機で動作しなければならず、関連したイメージ及びデータは、受信機或いはホームネットワーク以外の外部アプリケーションサーバーからダウンロードすることができる。ＤＯがＮＤＯである場合に、ＡＴＳＣ−ＮＲＴでＮＤＯ及び関連リソースファイルを放送網に送信しておき、第２スクリーンサービスを提供することができる。
【０９４１】
放送シグナリングの場合、第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションが管理することができる。
【０９４２】
まず、受信機が第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
【０９４３】
受信機は、ＤＴＶＣＣで伝送されるメディア時間トリガーの情報を処理後に、第２スクリーンと関連したイベントがＴＰＴに存在し、このイベントが実行されなければならない時、すぐに“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数を、全てのホームネットワークにある機器に知らせることができる。このようなイベントに関連していて申請した機器は、ＵＩ情報がアップデートされたことを認知し、必要な情報を得るために“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションを行うことができる。この時、受信機のＲｅｍｏｔｅＵＩサーバーでは、すぐに実行しなければならないＴＤＯアドレスを渡すことができる。
【０９４４】
次に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
【０９４５】
この場合には、受信機が受信した情報を第２スクリーンデバイスに伝達し、第２スクリーンサービスアプリケーションが自ら動作できるようにすることができる。放送の場合、第２スクリーンサービスとなるクライアントが“ＧｅｔＣｏｍａｐｔｉｂｌｅＵＩｓ”アクションを要求すると、受信機がＤＴＶＣＣで直接受信したｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇをリターンすることができ、第２スクリーンデバイスが、受信したＵＲＩＳｔｒｉｎｇを用いてＴＰＴファイルをダウンロードし、受信機と同様にＴＰＴを解釈して動作することができる。受信機はＤＴＶＣＣでメディア時間トリガーやイベント時間トリガーを受信する度にすぐに“ＵＩＬｉｓｔｉｎｇＵｐｄａｔｅ”変数を変更して全ての機器に送信することができ、新しいｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇを受信できるように、機器が“ＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ”アクションをするように誘導することができる。
【０９４６】
図６５は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【０９４７】
前述したユニキャストシグナリングについて説明する。
【０９４８】
この方法は、第２スクリーンデバイスがＲｅｍｏｔｅＵＩＣｌｉｅｎｔサービスを装置内に内蔵している場合といえる。ＵＰｎＰデバイスが、最初にホームネットワークに接続すると、自身の情報を自分で通知し、他の装置にも新しい装置がホームネットワークに接続したという事実を知らせることができる。もう一つの方法は、周期的に新しい装置があったら知らせるように要求するメッセージを、全てのホームネットワークに接続した装置に伝達すると、全てのホームネットワークに接続した装置はこの情報に応答して通知（ＮＯＴＩＦＹ）メッセージをさらに全ての装置に知らせる方法である。まず、第２スクリーンデバイスが第２スクリーンサービスを支援するか否かについて調べなければならない。
【０９４９】
ＲｅｍｏｔｅＵＩクライアントサービスに対するユニキャストシグナリングの一実施例は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ６５０１０）、デバイスプロファイルを要求する段階（ｓ６５０２０）、デバイスプロファイルを返還する段階（ｓ６５０３０）、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）、ＨＴＴＰメッセージを返還する段階（ｓ６５０５０）、ディスプレイメッセージを送信する段階（ｓ６５０６０）、及び／又はＨＴＴＰメッセージを送信する段階（ｓ６５０７０）を含むことができる。
【０９５０】
ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ６５０１０）は、ＵＰｎＰデバイス及びサービスディスカバリ段階（ｓ５８０１０）と同一の段階であってもよい。
【０９５１】
デバイスプロファイルを要求する段階（ｓ６５０２０）は、受信機が新しく発見された第２スクリーンデバイスに第２スクリーンサービスを支援できるかを確認するために“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”情報を送信する段階であってもよい。
【０９５２】
デバイスプロファイルを返還する段階（ｓ６５０３０）は、デバイスプロファイルを要求する段階（ｓ６５０２０）に対する応答として、第２スクリーンデバイスのデバイスプロファイルを得る段階であってもよい。もし、新しく発見された第２スクリーンデバイスが送ったデバイスプロファイルが“Ｓｔａｔｉｃ ＤｅｖｉｃｅＩｎｆｏ”と一致しないか、又は第２スクリーンデバイスを支援しない装置と判断されると、第２スクリーンサービスを開始しなくてもよい。“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”は、上記で定義した“ＤｅｖｉｃｅＩｎｆｏ”と同一であってもよい。“ＳｔａｔｉｃＤｅｖｉｃｅＩｎｆｏ”とＤｅｖｉｃｅＩｎｆｏ情報が一致するかは受信機で判断しなければならない。もし、ホームネットワークに新しく発見された第２スクリーンデバイスが一つ以上である場合、このような過程は繰り返される。一度発見された第２スクリーンデバイスで第２スクリーンサービスを支援しないからといって、このような過程を経ないというわけにはいかない。第２スクリーンデバイスには一つ以上の複数のソフトウェアが設置及び削除されてもよく、ユーザが実行するか否かによってこの過程に対する結果値が変わってもよいからである。第２スクリーンサービスアプリケーションを行った状態になると、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）に移行することができる。
【０９５３】
ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）は、受信機がＴＰＴ及びＡＭＴをパーシングした結果であるＴＤＯ ＵＲＬ情報を送信する段階であってもよい。ＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスで定義された“ＡｄｄＵＩＳｔｒｉｎｇ”を用いることができる。“ＡｄｄＵＩＳｔｒｉｎｇ”は、第２スクリーンデバイスで第２スクリーンサービスのＤｅｖｉｃｅＩｎｆｏ情報を満たす場合に実行されるアクションであってもよい。ＴＤＯ ＵＲＬは、一つ或いは一つ以上のＵＲＬになってもよい。一つ以上のＵＲＬである場合、すぐに実行するためのＵＲＬを送信することができる。このとき、選択的にディスプレイメッセージを送信する段階（ｓ６５０６０）を行うことができる。
【０９５４】
ＨＴＴＰを返還する段階（ｓ６５０５０）は、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６５０４０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９５５】
ディスプレイメッセージを送信する段階（ｓ６５０６０）は、第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ＲｅｍｏｔｅＵＩクライアントサービスは、第２スクリーンデバイス画面にメッセージを表示できるＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを有しうるため、第２スクリーンデバイスにＴＤＯ ＵＲＬを送信し、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて、画面に現在視聴中の放送プログラムと関連付けられた第２スクリーンアプリケーションがあるというメッセージを表示することができる。ユーザがこのメッセージを確認するとすぐに第２スクリーンアプリケーション実行となり得る。
【０９５６】
ＨＴＴＰメッセージを返還する段階（ｓ６５０７０）は、ディスプレイメッセージを送信する段階（ｓ６５０６０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９５７】
図６６は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【０９５８】
新しいＵＩのＵＲＬが第２スクリーンデバイスのＵＩＬｉｓｔｉｎｇに追加される度に、第２スクリーンサービスアプリケーションは新しい第２スクリーンアプリケーションを実行する環境を提供することができる。
【０９５９】
図６６のＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、実行中の第２スクリーンアプリケーションの実行を中断し、新しい第２スクリーンアプリケーションを実行するための順序を示している。
【０９６０】
ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０２０）、ディスプレイメッセージを送信する段階（ｓ６６０３０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０４０）、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）、ＨＴＴＰメッセージを返還する段階（ｓ６６０６０）、ディスプレイメッセージを送信する段階（ｓ６６０７０）、及び／又はＨＴＴＰメッセージを返還する段階（ｓ６６０８０）を含むことができる。
【０９６１】
ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）は、ＲｅｍｏｔｅＵＩクライアントサービスに定義されている“ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ”アクションを用いて、第２スクリーンサービスアプリケーションで実行中の第２スクリーンアプリケーションを中止させることができる。第２スクリーンサービスアプリケーションは、受信機で現在実行中であるＵＩのアプリケーション使用中止をする時、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送るということを知っていてもよい。したがって、第２スクリーンサービスアプリケーションは、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ ａｃｔｉｏｎが第２スクリーンデバイスに受信されるとすぐに現在動作中の第２スクリーンアプリケーションの動作を中止しなければならない。
【０９６２】
ＨＴＴＰメッセージを返還する段階（ｓ６６０２０）は、ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９６３】
ディスプレイメッセージを送信する段階（ｓ６６０３０）は、第２スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇアクションを送信する段階（ｓ６６０１０）の後に、場合によっては、実行が中止されるというメッセージを第２スクリーンデバイス画面に表示する必要がありうる。この場合には、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて適切なメッセージを画面に表示することができる。
【０９６４】
ＨＴＴＰメッセージを返還する段階（ｓ６６０４０）は、ディスプレイメッセージを送信する段階（ｓ６６０３０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９６５】
ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）は、受信機が、新しく行われるＵＩのＴＤＯ ＵＲＬを送信するためにＡｄｄＵＩＬｉｓｔｉｎｇアクションを行う段階であってもよい。新しい第２スクリーンアプリケーションが行われる時は、ＵＩＬｉｓｔｉｎｇにＴＤＯ ＵＲＬが追加されるやいなや第２スクリーンサービスアプリケーションを実行させることができる。参考として、ＴＤＯ ＵＲＬは、受信機で直接ダウンロードして実行し得る第２スクリーンアプリケーションに関するものであっもよく、部分的なリソースデータだけをインターネットサーバーからダウンロードして行うものであってもよい。また、ＴＤＯ ＵＲＬそのものが外部インターネットサーバーアドレスを指してもよい。外部インターネットサーバーアドレスを指す場合には、第２スクリーンアプリケーション及び実行に必要な全てのデータは、インターネットサーバーからダウンロードして実行することができる。
【０９６６】
ＨＴＴＰメッセージを返還する段階（ｓ６６０６０）は、ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９６７】
ディスプレイメッセージを送信する段階（ｓ６６０７０）は、第２スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。ＴＤＯ ＵＲＬ情報を送信する段階（ｓ６６０５０）後に、新しい第２スクリーンサービスが実行されるとのメッセージを第２スクリーンデバイス画面に表示することができる。ディスプレイメッセージを送信する段階（ｓ６６０３０）と同様に、ＤｉｓｐｌａｙＭｅｓｓａｇｅアクションを用いて適切なメッセージは、画面に表示することができる。
【０９６８】
ＨＴＴＰメッセージを返還する段階（ｓ６６０８０）は、ディスプレイメッセージを送信する段階（ｓ６６０７０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９６９】
ユニキャストシグナリングの場合も同様、第２スクリーンアプリケーションのライフサイクルは、受信機又は第２スクリーンサービスアプリケーションが管理することができる。
【０９７０】
まず、受信機が第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
【０９７１】
第２スクリーンサービスアプリケーションでは“ＵＲＬ”（ＴＤＯ＿ＵＲＬ）情報だけを知っていればよい。したがって、受信機で第２スクリーンデバイスにあるＲｅｍｏｔｅＵＩクライアントサービスに“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションを行い、第２スクリーンデバイスで動作する第２スクリーンアプリケーションを、定められた時間に実行することができる。逆に、第２スクリーンアプリケーションを中断させなければならない場合には、“ＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ”アクションを行い、定められた時間内に第２スクリーンアプリケーションを中断させることができる。
【０９７２】
さらに、細部的な時間まで合わせるためには、ＵＲＬの他に、ＴＤＯを行うメディア時間情報まで与えると、第２スクリーンサービスアプリケーションを指定された時間に実行することができる。しかし、メディア時間は、現在受信機で再生されているメディアに対する相対的な時間であるから、この時間は各機器が理解し得る絶対時間に変更する必要がある。ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）或いは他の時間情報を有することができ、この時間に、未来の時間情報を有するメディア時間を加えると、アクションを行う時間となる。第２スクリーンデバイスにおいてアクションは実行と中止しかないため、これは、ＡｄｄＵＩＬｉｓｔｉｎｇ及びＲｅｍｏｖｅＵＩＬｉｓｔｉｎｇ ａｃｔｉｏｎの具現によって異なり得る。
【０９７３】
次に、第２スクリーンサービスアプリケーションが第２スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
【０９７４】
第２スクリーンサービスアプリケーションが第２スクリーンデバイスで動作する第２スクリーンアプリケーションを実行し中断する時間やイベントに関する情報を知っていなければならない。したがって、前述したように、第２スクリーンサービスアプリケーションがトリガークライアントを含んでおり、受信機がＤＴＶＣＣで受信されたｉＴＶメッセージ（トリガー）のＵＲＩＳｔｒｉｎｇ情報を受信機のＤｅｖｉｃｅＩｎｆｏ（Ｄｅｖｉｃｅ  Ｐｒｏｆｉｌｅ）に合わせて送信することができる。
【０９７５】
送信方法は、２種類に大別できる。その第一の方法は、ＤＴＶＣＣで送信されて受信機で処理したトリガーメッセージをそのまま送信する方法であり、第二の方法は、受信機で第２スクリーンデバイスに必要な情報のみをさらに整理し、必要な情報とデータのみをＸＭＬ形態で伝達する方法である。
【０９７６】
まず、受信機がトリガーを第２スクリーンにそのまま伝達する方法について説明する。
【０９７７】
この方法は、受信されたトリガーをそのまま“ＡｄｄＵＩＬｉｓｔｉｎｇ”アクションすることによって処理を終えることができる。ＲｅｍｏｔｅＵＩクライアントサービスでは、この情報をもってすぐにトリガークライアントが処理できるように渡し、トリガークライアントは、受信機と同様に、ＴＰＴをダウンロードして処理することができる。ただし、受信機は、ＤＴＶＣＣでメディア時間トリガーが受信される度に、第２スクリーンデバイスにこのように伝達しなければならない。受信機が“ａｐｐＩＤ”、“ｅｖｅｎｔＩＤ”及び“ｅｖｅｎｔ＠ｄｅｓｔｉｎａｔｉｏｎ”を確認し、第２スクリーンデバイスで受信しなくてもよいトリガーである場合には、自分で消費し、第２スクリーンデバイスには伝達しなくてもよい。
【０９７８】
次に、受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法について説明する。
【０９７９】
この方法は、受信機でＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達することができる。この方法は、第２スクリーンサービスアプリケーションで、トリガークライアントが動作しなくてもよく、“ＰｒｏｇｒｅｓｓＩｎｐｕｔ”アクションを通じてＸＭＬファイルを受け取って処理することができる。すなわち、第２スクリーンサービスアプリケーションが全体ＴＰＴを直接処理するのではなく、現在或いは将来に処理しなければならない必要なデータのみを受信機がフィルタリングして伝達すると、これを受けて処理することができる。この方法の長所は、“Ｅｖｅｎｔ＠Ｄａｔａ”フィールドがあるが、このフィールドまで伝達できるという点である。
【０９８０】
図６７は、ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例である。
【０９８１】
図６７は、前述した第二の方法である、“受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”を示している。
【０９８２】
ＲｅｍｏｔｅＵＩクライアントサービスのためのユニキャストシグナリングの一実施例は、イベント１情報を送信する段階（ｓ６７０１０）、ＨＴＴＰメッセージを返還する段階（ｓ６７０２０）、イベント２情報を送信する段階（ｓ６７０３０）、ＨＴＴＰメッセージを返還する段階（ｓ６７０４０）、イベント３情報を送信する段階（ｓ６７０５０）、及び／又はＨＴＴＰメッセージを返還する段階（ｓ６７０６０）を含むことができる。
【０９８３】
イベント１情報を送信する段階（ｓ６７０１０）は、受信機が第２スクリーンデバイスに、受信したイベント情報を伝達する段階であってもよい。前述した通り、受信機でＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達することができる。第２スクリーンサービスアプリケーションでは、トリガークライアントが動作しなくてもよく、“ＰｒｏｇｒｅｓｓＩｎｐｕｔ”アクションを通じてＸＭＬファイルを受信して処理することができる。
【０９８４】
ＨＴＴＰメッセージを返還する段階（ｓ６７０２０）は、イベント１情報を送信する段階（ｓ６７０１０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９８５】
イベント２情報を送信する段階（ｓ６７０３０）は、イベント１情報を送信する段階（ｓ６７０１０）と同様に、イベントに関する情報を伝達する段階であってもよい。ＴＰＴ ＸＭＬにおけると同様に、各イベント別にデータをＴＤＯに伝達することができるが、この段階は、イベント２に関する情報を伝達する段階であってもよい。
【０９８６】
ＨＴＴＰメッセージを返還する段階（ｓ６７０４０）は、イベント２情報を送信する段階（ｓ６７０３０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９８７】
イベント３情報を送信する段階（ｓ６７０５０）は、同様に、イベント３に関する情報を伝達する段階であってもよい。
【０９８８】
ＨＴＴＰメッセージを返還する段階（ｓ６７０６０）は、イベント３情報を送信する段階（ｓ６７０５０）に対する結果を送る段階であってもよい。前述した応答１を送信する段階（ｓ４０１００）と同様に、状況によって、ＨＴＴＰ／１．１ ２００ ＯＫなどの応答を送ることができる。
【０９８９】
前述した第二の方法では、受信機が第２スクリーンアプリケーションのライフサイクルを管理することができる。第２スクリーンアプリケーションのライフサイクルは、第２スクリーンデバイスで動作するＴＰＴ及びＡＭＴ情報をパーシングし、処理する過程を意味することができる。
【０９９０】
図６８は、ＰｒｏｃｅｓｓＩｎｐｕｔアクションで第２スクリーンデバイスに伝達される“ＥｖｅｎｔＩｎｆｏ”情報の一実施例である。
【０９９１】
図６８は、前述した“受信機で第２スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”において、受信機がＴＰＴファイルとトリガーを処理し、第２スクリーンデバイスが処理するデータにして伝達する時、イベント情報のＸＭＬデータ構造の一例を示している。
【０９９２】
すなわち、受信機で第２スクリーンアプリケーションのライフサイクルを管理する場合には、ＰｒｏｃｅｓｓＩｎｐｕｔアクションでは、イベント情報を、図６８のデータ構造を有するＸＭＬファイルとしてＲｅｍｏｔｅＵＩクライアントに伝達することができる。受信機がライブトリガー（Ｌｉｖｅ  Ｔｒｉｇｇｅｒ）を受ける場合にも同様に、ライブトリガーを処理し、実行する時間とＴＤＯ ＵＲＬなどの情報のみを第２スクリーンデバイスに伝達することもできる。
【０９９３】
図６８のテーブルで、＠ａｐｐＩＤ、ＵＲＬ、Ｅｖｅｎｔ、＠ｅｖｅｎｔＩＤ、＠ａｃｔｉｏｎ及びＤａｔａは、受信機が受信したトリガー又はＡＭＴの情報と同一であってもよい。しかし、“＠ｍｅｄｉａＴｉｍｅ”、“＠ｓｔａｒｔＴｉｍｅ”及び“＠ｅｎｄＴｉｍｅ”は、受信機で特別に処理することができる。“＠ｍｅｄｉａＴｉｍｅ”に合わせて、ＤＴＶＣＣで送信されたトリガーの“ｔｉｍｅ＝”シンタックスの情報（或いは、ＡＭＴの“＠ｂｅｇｉｎＭＴ”情報）を処理し、再び“＠ｓｔａｒｔＴｉｍｅ”と“＠ｅｎｄＴｉｍｅ”を決定することができる。受信機と第２スクリーンデバイスが、同一の絶対時間情報（ｗａｌｌ  ｃｌｏｃｋ  ｔｉｍｅ）を使用するとはいえないことから、コンテンツのメディア時間に合わせて第２スクリーンデバイスを動作させるためである。すなわち、受信機と第２スクリーンデバイス間にアクションに対する実行開始時間及び終了時間に関する時間情報が実際ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）に合わせられているとすれば、送信する前に受信機が変換する作業を行わなければならない。
【０９９４】
送信遅延及びメディア時間推定について説明する。
【０９９５】
前述した通り、＠ｓｔａｒｔＴｉｍｅと＠ｅｎｄＴｉｍｅは、受信機で第２スクリーンに送る時、現在のｍｅｄｉａＴｉｍｅ値を基準に相対的に作られて送信されるため、送信時に発生する時間損失は、送信プロトコルであるＨＴＴＰのヘッダーの“Ｄａｔｅ”値とＨＴＴＰ応答であってもよい到着した時間値との差を用いて、第２スクリーンデバイスで調整してより正確な時間値を探すことができる。現在メディア時間と＠ｍｅｄｉａＴｉｍｅ値との差は送信遅延時間となるため、次のような数式によって現在メディア時間を得ることができる。
【０９９６】
現在メディア時間＝送信遅延時間（受信時の時間値−ＨＴＴＰヘッダー“Ｄａｔｅ”値）＋＠ｍｅｄｉａＴｉｍｅ
これによって、現在受信機の現在メディア時間値と略同一に類推することができる。
【０９９７】
図６９は、受信機及び第２スクリーンデバイス間の構成の一実施例である。
【０９９８】
受信機及び第２スクリーンデバイス間の構成が示されている。受信機が被制御デバイス（サーバー）であり、第２スクリーンデバイスが制御ポイント（クライアント）であってもよい。
【０９９９】
ディスカバリ段階で、受信機は、サービスリストをマルチキャストしてネットワークにジョインし、第２スクリーンアプリケーションはサービスリストに対する要求をマルチキャストして開始することができる。
【１０００】
記述（Ｄｅｓｃｒｉｐｔｉｏｎ）段階で、第２スクリーンアプリケーションは、受信機のサービス記述を要求することができる。
【１００１】
本発明では、ＵＰｎＰに基づいてＴＶ受像機、すなわち、受信機を通じて受信されるＡ／Ｖ放送コンテンツと関連したインタラクティブサービスを第２スクリーンデバイスを通じて取得できるようにするために、新しいＵＰｎＰデバイス及びサービスを定義することができる。
【１００２】
図７０は、サービスのサービスタイプ及びサービスＩＤの一実施例である。
【１００３】
受信機は、トリガーサービス、両方向通信サービス及びＡｐｐＵＲＬサービスを支援することができる。また、ＨＴＴＰプロキシサーバーサービスを支援することができる。サービスタイプ及びサービスＩＤは、図７０に示している。
【１００４】
両方向通信サービスは、第２スクリーンデバイス内のアプリケーションと両方向通信に参加するように準備されたプライマリデバイスで実行されるＤＯが存在するかを、第２スクリーンデバイスで決定するようにすることができる。
【１００５】
トリガーサービス、ＡｐｐＵＲＬサービス及びＨＴＴＰプロキシサーバーサービスについては後述する。
【１００６】
図７１は、トリガー伝達サービスの動作概念図の一実施例である。
【１００７】
トリガー伝達サービスは、ＵＰｎＰに基づいてＴＶ受信機に受信されるＡ／Ｖ放送コンテンツと関連したインタラクティブサービスを第２スクリーンを通じて取得できるようにするためのサービスを意味できる。
【１００８】
図７１は、受信機がＤＴＶＣＣ或いはＡＣＲサーバーなどからトリガーを取得し、当該トリガーをそのまま或いは第２スクリーンデバイスに適した形態に変形（拡張されたトリガー）して第２スクリーンデバイスに送信する過程を示している。
【１００９】
トリガーが変化する度に、受信機から第２スクリーンデバイスに当該トリガー或いは変形された拡張トリガーを実時間で送信することができる。
【１０１０】
図７２は、拡張された活性化トリガー（ｅｘｐａｎｄｅｄ  ａｃｔｉｖａｔｉｏｎ  ｔｒｉｇｇｅｒ）生成過程の一実施例である。
【１０１１】
拡張されたトリガー（拡張された活性化トリガー）は、ＤＴＶＣＣストリーム或いはＡＣＲサーバーなどから取得したトリガーとＴＰＴ内の情報とを組み合わせて生成することができる。トリガーに含まれたＴＤＯ ＩＤとイベントＩＤ、データＩＤ及び活性化時間と、ＴＰＴ内のＴＤＯ ＵＲＬ、ＴＤＯ属性、イベント、アクション、ディフュージョン（Ｄｉｆｆｕｓｉｏｎ）及びデータなどの情報を組み合わせて生成することができる。ＴＤＯ内の情報は、トリガー内の情報と関連したＴＤＯ及びイベントに関する情報であってもよい。
【１０１２】
ここで、拡張されたトリガーは、増加したトリガー（ａｕｇｍｅｎｔｅｄ  ｔｒｉｇｇｅｒ）と呼ぶこともできる。
【１０１３】
図７３は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ  Ａｃｔｉｖａｔｉｏｎ  Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ  Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。
【１０１４】
トリガーサービスの説明書（Ｓｐｅｃｉｆｉｃａｔｉｏｎ）について説明する。
【１０１５】
トリガーサービスは、トリガーを伝達することができる。トリガーは、（ａ）ＡＣＲプロセス、（ｂ）現在見ているチャネルのＤＴＶ ＣＣサービス＃６、（ｃ）遠隔“ライブトリガー”サーバー、又は（ｄ）活性化メッセージテーブル（ＡＭＴ）からＴＶ受像機によって取得することができる。これは状況による。
【１０１６】
トリガーサービスはまた、チャネルが変更される度に特殊“チャネル変更”トリガーを伝達することができる。チャネル変更トリガーについては後述する。伝達される４つのタイプのトリガーが基本的に存在し得る。すなわち、１）ＴＤＯインタラクティブサービスモデルのための時間ベーストリガー、２）ＴＤＯインタラクティブサービスモデルのための活性化トリガー、３）直接実行インタラクティブサービスモデルのためのトリガー、及び４）特殊“チャネル変更”トリガーである。
【１０１７】
最大の柔軟性のために、第２スクリーンデバイスに全てのタイプのトリガーを伝達するオプションを有し、受信機でトリガーが到達するやいなや伝達することが好ましい。
【１０１８】
しかし、受信機が相互作用を提供するのと同じ方式で相互作用を提供するように設計された第２スクリーンアプリケーションに対して、ＴＤＯ相互作用モデルのための時間ベーストリガーを省略し、その活性化時間にＴＤＯ相互作用モデルのための各活性化トリガーを伝達することが好ましい。これは、時間ベースを維持し、活性化時間を算出する必要性から、それらの第２スクリーンアプリケーションを求めることができる。これはまた、トリガーからの情報をトリガーで参照されたＴＤＯエレメント及びそのイベントチャイルド（ｃｈｉｌｄ）エレメントに関するＴＰＴからの情報と結合することによってそれぞれの活性化トリガーを増加させ、これらの第２スクリーンアプリケーションがＴＰＴを扱う必要性から求めることが好ましい。
【１０１９】
したがって、トリガーサービスは、トリガー伝達のための２つのオプションを提供することができる。その一つは、受信機が（増加していない）全てのトリガーを伝達する“フィルタリングされていないストリーム（Ｕｎｆｉｌｔｅｒｅｄ  ｓｔｒｅａｍ）”オプションでよい。もう一つは、ＴＤＯ相互作用モデルのための増加した活性化トリガー、ＴＤＯ相互作用モデル以外の相互作用モデルのための全てのトリガー及び特殊チャネル変更トリガーのみを伝達する“フィルタリングされたストリーム（Ｆｉｌｔｅｒｅｄ  ｓｔｒｅａｍ）”オプションでよい。
【１０２０】
ＴＤＯ相互作用モデルのためのそれぞれの増加した活性化トリガーのためのターゲット伝達時間は、その活性化時間であってもよい。（フィルタリングされていないストリームオプションで増加無しで伝達された活性化トリガーを含む）全ての他のトリガーに対するターゲット伝達時間は、受信機によって受信される時間であってもよい。それぞれの特殊チャネル変更トリガーのターゲットトリガー時間は、チャネル変更の時間であってもよい。
【１０２１】
トリガーサービスのトリガー伝達フォーマットは、増加した活性化トリガーに対する伝達フォーマット及び他の全てのトリガーに対する伝達フォーマットとに区別できる。
【１０２２】
図７３は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ  Ａｃｔｉｖａｔｉｏｎ  Ｔｒｉｇｇｅｒ）に対する伝達フォーマットを示す。他の全てのトリガーに対する伝達フォーマットは後述する。
【１０２３】
増加した活性化トリガーに対する伝達フォーマットは、＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ、＠ａｐｐＵＲＬ、及び／又は＠ｃｏｏｋｉｅＳｐａｃｅ属性と能力及び／又はイベントエレメントを含むことができる。
【１０２４】
イベントエレメントは、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び／又は＠ｄａｔａ  ａｔｔｒｉｂｕｔｅｓを含むことができる。
【１０２５】
各フィールドのセマンティックス（ｓｅｍａｎｔｉｃｓ）は、次のと通りである。
【１０２６】
＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性の値は、トリガーを伝達するために用いられるＤＴＶＣＣチャネルのサービス＃６内のＳＤＯＰｒｉｖａｔｅＤａｔａ命令内のｃｍｄＩＤフィールドに対して同一のコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。
【１０２７】
＠ａｐｐＵＲＬ属性の値は、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントの第１ＵＲＬチャイルドエレメントの値であってもよい。
【１０２８】
＠ｃｏｏｋｉｅＳｐａｃｅ属性は、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントが＠ｃｏｏｋｉｅＳｐａｃｅ属性を含む度に存在でき、その属性と同じ値を有することができる。
【１０２９】
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、トリガー内のイベント（“ｅ＝”）用語によって識別されるＴＰＴ ＴＤＯエレメントがＣａｐａｂｉｌｉｔｉｅｓエレメントを含む度に存在でき、そのエレメントと同一であってもよい。
【１０３０】
Ｅｖｅｎｔエレメントは、トリガー内のイベント（“ｅ＝”）用語によって識別されるＥｖｅｎｔエレメントを示すことができる。（厳密にいえば、トリガー内のイベント用語は、ＴＰＴ内のＴＤＯエレメント及びそのＴＤＯエレメントのイベントチャイルドエレメントを識別する。これは、ここでトリガー内のイベント用語によって識別されたＥｖｅｎｔエレメントという。）
【１０３１】
＠ａｃｔｉｏｎ属性の値は、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントのアクション属性の値と同一であってもよい。
【１０３２】
＠ｄｅｓｔｉｎａｔｉｏｎは、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントがあて先属性を含む度に存在でき、その属性と同じ値を有することができる。
【１０３３】
＠ｄｉｆｆｕｓｉｏｎ属性は、トリガー内のイベント（“ｅ＝”）用語によって識別されるイベントエレメントがディフュージョン属性を含む度に存在でき、その属性と同じ値を有することができる。
【１０３４】
＠ｄａｔａ属性は、イベントエレメントのデータチャイルドエレメントがトリガー内のイベント（“ｅ＝”）用語によって識別される度に存在でき、そのエレメントと同じ値を有することができる。
【１０３５】
前述した通り、増加したトリガーは、ＤＴＶＣＣストリーム或いはＡＣＲサーバーなどから取得したトリガーとＴＰＴ内の情報とを組み合わせて生成することができる。
前述した通り、拡張されたトリガーは、増加したトリガーと呼ぶこともできる。
【１０３６】
図７４は、増加した活性化トリガー（Ａｕｇｍｅｎｔｅｄ  Ａｃｔｉｖａｔｉｏｎ  Ｔｒｉｇｇｅｒ）に対するＸＭＬスキマー記述（Ｓｃｈｅｍａ  Ｄｅｓｃｒｉｐｔｉｏｎ）の一実施例である。
【１０３７】
増加していないトリガーのＸＭＬフォーマットであってもよい。前述した特殊“チャネル変更”トリガーもこのフォーマットに従うことができる。
【１０３８】
増加した活性化トリガーに対するＸＭＬスキマー記述の一実施例は、＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性及び／又は＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性を含むことができる。
【１０３９】
各フィールドのセマンティックスは、次のと通りである。
【１０４０】
＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌ属性は、特殊“チャネル変更”トリガーのために存在することができない。他のトリガーのために、ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌが存在でき、その値は、ＤＴＶＣＣチャネル内のＳＤＯＰｒｉｖａｔｅＤａｔａコマンド内のｃｍｄＩＤフィールドに対するものと同じコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。ライブトリガーサーバーから取得されたりＡＭＴから導出されたトリガーのための＠ｉｎｔｅｒａｃｔｉｏｎＭｏｄｅｌは、ＴＤＯモデルと見なすことができる。
【１０４１】
＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性の値は、トリガーのストリング表示であってもよい。トリガーのストリング表示は、前述したトリガーシンタックスで説明したものと同一であってもよい。ただし、特殊“チャネル変更”トリガーの場合には異なってもよい。特殊“チャネル変更”トリガーのための＠ｔｒｉｇｇｅｒＳｔｒｉｎｇ属性は、値“＊＊＜ｍａｊｏｒ＿ｎｕｍ＞．＜ｍｉｎｏｒ＿ｎｕｍ＞”を有することができ、ここで、＜ｍａｊｏｒ＿ｎｕｍ＞は、（ＴＶステーションによって放送されたため）新しいチャネルの本来の主要チャネル番号であり、＜ｍｉｎｏｒ＿ｎｕｍ＞は、（ＴＶステーションによって放送されたため）新しいチャネルの本来のマイナーチャネル番号であってもよい。チャネル番号を知っていないと、＜ｍａｊｏｒ＿ｎｕｍ＞及び＜ｍｉｎｏｒ＿ｎｕｍ＞値は“０”であってもよい。
【１０４２】
図７５は、増加した活性化トリガーのフォーマットの一実施例である。
【１０４３】
前述の増加したトリガーのフォーマットの他の実施例であってもよい。
【１０４４】
＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
【１０４５】
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅは、メディア時間スケール上の活性化時間であってもよい。
【１０４６】
＠ｔｄｏＵＲＬは、前述した＠ａｐｐＵＲＬと同一であってもよい。
【１０４７】
図７６は、増加した活性化トリガーのフォーマットの一実施例である。
【１０４８】
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
【１０４９】
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅ、＠ｔｄｏＵＲＬ、＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
【１０５０】
＠ａｖａｉｌＩｎｔｅｒｎｅｔ及び＠ａｖａｉｌＢｒｏａｄｃａｓｔはＴＰＴからなってもよい。＠ａｖａｉｌＩｎｔｅｒｎｅｔ及び＠ａｖａｉｌＢｒｏａｄｃａｓｔも、前述したものと同一であってもよい。
【１０５１】
図７７は、増加した活性化トリガーのフォーマットの一実施例である。
【１０５２】
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
【１０５３】
＠ａｃｔｉｖａｔｉｏｎＴｉｍｅ、＠ｔｄｏＵＲＬ、＠ｃｏｏｋｉｅＳｐａｃｅ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
【１０５４】
ＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ及び、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性は、増加したトリガーを生成する時、ＴＰＴにおける同名のｅｌｅｍｅｎｔ及びａｔｔｒｉｂｕｔｅｓから由来ものであってもよい。ＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ及び、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔも、前述したものと同一であってもよい。
【１０５５】
図７８は、増加した活性化トリガーのフォーマットの一実施例である。
【１０５６】
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
【１０５７】
＠ｃｏｏｋｉｅＳｐａｃｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ Ｃａｐａｂｉｌｉｔｉｅｓ、ＣｏｎｔｅｎｔＩｔｅｍ、＠ｕｐｄａｔｅｓＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ、Ｅｖｅｎｔ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ及び＠ｄａｔａは、前述したものと同一であってもよい。
【１０５８】
＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩｄ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、ＴＤＯエレメント内のＵＲＬ及びＣｏｎｔｅｎｔＩｔｅｍエレメント内のＵＲＬは、増加したトリガーを生成する時、ＴＰＴにおける同名のエレメント及び属性から由来するものであってもよい。＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩｄ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、ＴＤＯ  ｅｌｅｍｅｎｔ内のＵＲＬ及びＣｏｎｔｅｎｔＩｔｅｍ ｅｌｅｍｅｎｔ内のＵＲＬも、前述したものと同一であってもよい。
【１０５９】
図７９は、トリガーサービス状態変数（Ｔｒｉｇｇｅｒ  Ｓｅｒｖｉｃｅ  Ｓｔａｔｅ  Ｖａｒｉａｂｌｅｓ）の一実施例である。
【１０６０】
トリガーサービス状態変数の一実施例は、図示のようなトリガーサービス状態変数を定義することができる。トリガーサービスは、図７９に列挙された状態変数を有することができる。
【１０６１】
ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値は、最も最近のターゲット伝達時間でフィルタリングされていないストリーム内のトリガーを表現することができる。この状態変数のフォーマットは、図７４に記載されたスキマーと一致するＸＭＬ文書であってもよい。
【１０６２】
ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値は、最も最近のターゲット伝達時間でフィルタリングされたストリーム内のトリガーを表現することができる。活性化トリガーである場合、活性化トリガー内の情報をＴＰＴ内の情報と結合して、図７３に記載されたテーブルで表示されるＸＭＬスキマーと一致するＸＭＬ文書を生成することによって増加することができる。ＴＤＯ以外の相互作用モデルを有するトリガーである場合、図７４に記載されたスキマーと一致するＸＭＬ文書の形態を有することができる。特殊チャネル変更トリガーの場合、フォーマットは、上述した通り、“＊＊＜ｍａｊｏｒ＿ｎｕｍ＞．＜ｍｉｎｏｒ＿ｎｕｍ＞”であってもよい。
【１０６３】
ＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値は最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーの伝達時間であってもよい。
【１０６４】
ＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒＤｅｌｉｖｅｒｙＴｉｍｅ状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーの伝達時間であってもよい。
【１０６５】
図８０は、トリガーサービス状態変数の一実施例である。
【１０６６】
トリガーサービス状態変数の他の実施例は、図８０のような状態変数を有することができる。
【１０６７】
ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、次の３つ状況のいずれの状況が行われているかによって異なりうる。１）プライマリスクリーン上に現在表示されている番組と関連したインタラクティブ付加（ａｄｊｕｎｃｔ）データサービスがない。２）プライマリスクリーン上に現在表示されている番組と関連したインタラクティブ付加データサービスが存在し、直接実行相互作用モデルを有する。３）プライマリスクリーン上に現在表示されている番組と関連したインタラクティブ付加データサービスが存在し、ＴＤＯ相互作用モデルを有する。
【１０６８】
（１）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値はヌルストリング（ｎｕｌｌ  ｓｔｒｉｎｇ）であってもよい。
【１０６９】
（２）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、プライマリスクリーン上に現在表示されている番組のためにＴＶ受像機によって受信された最も最近のトリガーであってもよい。
【１０７０】
（３）の場合、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の値は、プライマリスクリーン上に現在表示されている番組のためにＴＶ受像機によって受信された活性化トリガーのうち、最も最近に活性化された活性化トリガーの増加した形態であってもよい。（すなわち、活性化トリガーは、その活性化時間に到達するとき、ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数に対する基準となり、他の活性化トリガーがその活性化時間に到達するまで基準として残っていてもよい。）活性化トリガーの増加した形態は、活性化トリガー内の情報をＴＰＴ内の情報と結合することによって得ることができる。増加した形態は、前述の増加したトリガーフォーマットのうちの一つと同一であってもよい。
【１０７１】
ＣｕｒｒｅｎｔＴｒｉｇｇｅｒ状態変数の定義は、ＴＤＯ相互作用モデルに対して、活性化トリガーがトリガー活性化時間にＵＰｎＰクライアントに伝達されることを暗示することができる。
【１０７２】
トリガーサービス状態変数の更に他の実施例は、トリガーが変化する度に受信機から第２スクリーンデバイスに当該トリガー或いは拡張されたトリガーを実時間で送信するために、ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒを状態変数と定義することができる。
【１０７３】
ＡＴＳＣＴｒｉｇｇｅｒ状態変数は、ＵＲＩの形態でＤＴＶＣＣストリーム又はＡＣＲサーバーから受信されたトリガーに対する参照を含むことができる。この変数は、ＴＰＴに対するＵＲＬ（ＴＤＯパラメータテーブル）、ＴＤＯ ＩＤ、イベントＩＤ、データＩＤ、メディア時間、コンテンツＩＤ、ターゲットイベントに対する活性化時間などを含むことができる。
【１０７４】
ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ状態変数は、ＸＭＬフラグメント（Ｆｒａｇｍｅｎｔ）の形態で第２スクリーンデバイスに対するＴＤＯと関連したメタデータを含むことができる。このメタデータは、ＤＴＶＣＣストリーム又はＡＣＲサーバーから受信されたＴＰＴ及びトリガーから抽出すことができる。この変数は、図７８の実施例のようなＸＭＬスキマーを有することができる。
【１０７５】
上記で定義したＡＴＳＣＴｒｉｇｇｅｒ、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒは、ＵＰｎＰのイベンティング（ｅｖｅｎｔｉｎｇ）メカニズムに基づいて受信機で当該状態変数を変更する場合、第２スクリーンデバイスで変更された値を実時間で取得できるようにすることができる。
【１０７６】
図８１は、トリガーサービスアクションの一実施例である。
【１０７７】
第２スクリーンデバイス或いは受信機でトリガーサービス状態変数値を任意的に読んでいくようにするためにアクションを定義することができる。
【１０７８】
トリガーサービスアクションの一実施例は、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ及び／又はＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを定義することができる。
【１０７９】
図８２は、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数（Ａｒｇｕｍｅｎｔ）の一実施例である。
【１０８０】
ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ出力引数の値は、ＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値であってもよい。
【１０８１】
第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いてＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーを得ることができる。
【１０８２】
図８３は、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションの引数の一実施例である。
【１０８３】
ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ出力引数の値は、ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値であってもよい。
【１０８４】
第２スクリーンアプリケーションは、ＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いて、ＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒ状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーを得ることができる。
【１０８５】
図８４は、トリガーサービスアクションの一実施例である。
【１０８６】
ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒを状態変数と定義した、前述したトリガーサービス状態変数の更に他の実施例において、トリガーサービスアクションについて説明する。
【１０８７】
この実施例においても、第２スクリーンデバイス或いは受信機がＡＴＳＣＴｒｉｇｇｅｒ、ＡＴＳＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値を任意的に書いたり読んでいくようにするためにアクションを定義することができる。
【１０８８】
ＳｅｔＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＴｒｉｇｇｅｒの値を書くようにするアクションであってもよい。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒを引数とすることができる。
【１０８９】
ＳｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値を書くようにするアクションであってもよい。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒを引数とすることができる。
【１０９０】
ＧｅｔＴｒｉｇｇｅｒ（）アクションは、ＡＴＳＣＴｒｉｇｇｅｒの値を読み込むようにするアクションであってもよい。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒを引数とすることができる。
【１０９１】
ＧｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ（）は、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒの値を読み込むようにするアクションであってもよい。ＣｕｒｒｅｎｔＴｒｉｇｇｅｒを引数とすることができる。
【１０９２】
図８５は、トリガー伝達サービスを用いてトリガー取得時に第２スクリーン上における動作の一実施例である。
【１０９３】
トリガー伝達サービスを通じて第２スクリーンデバイスで受信したトリガー或いは拡張された活性化トリガーに含まれたアクション情報によって、第２スクリーンデバイス側でどのように動作するかを示している。
【１０９４】
トリガー伝達サービスを通じて実行／終了アクションに対するトリガーを取得することができる。
【１０９５】
第２スクリーンデバイスがトリガー伝達サービスを通じて実行／終了アクションに対するトリガーを取得した後、取得されたトリガーからターゲットＴＤＯのＵＲＬ及び関連情報をＤＡＥ／ブラウザに伝達することができる。そして、ブラウザはこれを実行或いは終了するなどのトリガーに含まれたアクションを行うことができる。
【１０９６】
図８６は、トリガー伝達サービスの動作概念図の一実施例である。
【１０９７】
トリガー伝達サービスを通じて第２スクリーンデバイスで受信したトリガー或いは拡張された活性化トリガーに含まれたアクション情報によって、第２スクリーンデバイス側でどのように動作するかを示している。
【１０９８】
第２スクリーンデバイスがトリガー伝達サービスを通じてトリガーイベントアクションに対するトリガーを取得した後、取得されたトリガーからデータＩＤなどの情報を抽出することができる。その後、ＡＪＡＸコードを用いて、現在実行中であるＴＤＯに該当のデータなどを伝達することができる。当該ＴＤＯは、受信したデータなどの情報によって適切な動作を行うことができる。
【１０９９】
ＡＴＳＣＴｒｉｇｇｅｒ及びＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒを状態変数と定義した、前述したトリガーサービス状態変数の更に他の実施例において、トリガー伝達サービスの動作概念図について説明する。
【１１００】
この実施例で、直接実行モデルの場合、受信機でＤＴＶ ＣＣストリーム或いはＡＣＲサーバーを通じて受信したトリガーにコンテンツｉｄ、すなわち、“ｃ＝”が含まれていると、受信した時間ベーストリガー値をＡＴＳＣＴｒｉｇｇｅｒ状態変数の値に設定することができる。受信機に時間ベーストリガーが到着するとすぐに状態変数値を変更したり、ＳｅｔＴｒｉｇｇｅｒアクションを通じて第２スクリーンデバイスに伝達することができる。
【１１０１】
この実施例で、ＴＤＯモデルの場合、受信機でＤＴＶ ＣＣストリーム或いはＡＣＲサーバーを通じて受信したトリガーにコンテンツｉｄ、すなわち、“ｃ＝”が含まれていないと、アクショントリガーが受信された後、ＴＰＴとトリガー情報のうち、関連した情報を抽出及び組み合わせて拡張されたトリガーを生成することができる。その後、当該拡張されたトリガーの活性化時間となる瞬間（或いは活性化時間の直前）に、ＡＴＳＣＥｘｐａｎｄｅｄＴｒｉｇｇｅｒ状態変数の値に設定したり、ＳｅｔＥｘｐａｎｄｅｄＴｒｉｇｇｅｒアクションを通じて第２スクリーンデバイスに伝達することができる。
【１１０２】
図８７は、ＡｐｐＵＲＬサービス状態変数の一実施例である。
【１１０３】
ＡｐｐＵＲＬサービスは、第２スクリーンデバイスが現在実行中のＤＯと関連した第２スクリーンアプリケーションのネーム及びベースＵＲＬを決定するようにすることができる。
【１１０４】
ＵＰｎＰ ＡｐｐＵＲＬサービスは、２個の状態変数、すなわち、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅを有することができる。
【１１０５】
ＡｐｐＵＲＬ状態変数の値は、現在実行中のＤＯと関連した第２スクリーンアプリケーションのベースＵＲＬであってもよい。第１スクリーンデバイス上に実行される関連した第２スクリーンアプリケーションを有するＤＯがないと、ＡｐｐＵＲＬ状態変数の値はヌルストリングであってもよい。
【１１０６】
ＡｐｐＮａｍｅ状態変数の値は、現在実行中のＤＯと関連した第２スクリーンアプリケーションのネームであってもよい。第１スクリーンデバイス上で実行される関連した第２スクリーンアプリケーションを有するＤＯがないと、ＡｐｐＮａｍｅ状態変数の値はヌルストリングであってもよい。
【１１０７】
図８８は、ＡｐｐＵＲＬサービスアクションの一実施例である。
【１１０８】
ＡｐｐＵＲＬサービスは、一つのアクション、すなわち、ＧｅｔＡｐｐＵＲＬを有することができる。
【１１０９】
図８９は、ＧｅｔＡｐｐＵＲＬアクションの引数の一実施例である。
【１１１０】
ＧｅｔＡｐｐＵＲＬアクションは、２個の引数、すなわち、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅを有することができる。
【１１１１】
ＡｐｐＵＲＬ出力引数は、ＡｐｐＵＲＬ状態変数の現在値であってもよい。ＡｐｐＮａｍｅ出力引数は、ＡｐｐＮａｍｅ状態変数の現在値であってもよい。
【１１１２】
したがって、ＧｅｔＡｐｐＵＲＬアクションを通じて、ＡｐｐＵＲＬ状態変数の現在値及びＡｐｐＮａｍｅ状態変数の現在値を得ることができる。
【１１１３】
図９０は、プロキシＨＴＴＰサーバーサービス（Ｐｒｏｘｙ  ＨＴＴＰ  Ｓｅｒｖｅｒ  ｓｅｒｖｉｃｅ）の動作概念図の一実施例である。
【１１１４】
受信機は、プロキシＨＴＴＰサーバーサービスを支援することができる。プロキシＨＴＴＰサーバーサービスは、第２スクリーンデバイスで必要とするＴＤＯ／ファイルが放送網を通じて伝送される場合、これをＴＶ受信機を通じて取得できるようにするサービスを意味することができる。
【１１１５】
プロキシＨＴＴＰサーバーサービスの動作概念図は、放送システム９００１０、ＡＣＲサーバ（９００２）、放送社ＡＴＳＣ２．０ ｉＴＶサーバ（９００３）、ＡＴＳＣ２．０受信（９００４０、及び／又は第２スクリーンデバイス９００５０を含むことができる。
【１１１６】
放送システム９００１０は、放送システム４２０１０と同一であってもよい。
【１１１７】
ＡＣＲサーバー９００２０は、ＡＣＲサーバー４２０２０と同一であってもよい。
【１１１８】
放送社ＡＴＳＣ２．０ ｉＴＶサーバー９００３０は、放送社ＡＴＳＣ２．０ ｉＴＶサーバー４２０３０と同一であってもよい。
【１１１９】
ＡＴＳＣ２．０受信機９００４０は、放送Ａ／Ｖ及びインタラクティブサービスと関連したトリガーなどを受信し、これを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。プロキシＨＴＴＰサーバーサービスは、ＡＴＳＣ２．０受信機９００４０がプロキシサーバーと同様の役割を持つようにするサービスであってもよい。第２スクリーンデバイスで要求したファイルを第２スクリーンデバイスに效率的に提供できるようにするためのものであってもよい。
【１１２０】
第２スクリーンデバイス９００５０は、第２スクリーンデバイス４２０５０と同一であってもよい。
【１１２１】
プロキシＨＴＴＰサーバーサービスは、受信機が放送ストリーム或いはインターネットに存在するファイルに第２スクリーンデバイスを通じて接近できるようにすることによって、第２スクリーンデバイスが放送ストリームを通じて伝送されるコンテンツにも接近できるようにする。そして、複数の第２スクリーンデバイスがインターネットに存在する同一ファイルを接近する場合、各第２スクリーンデバイスが個別的に同じファイルに接近する重複性を最小化することができる。
【１１２２】
図９１は、プロキシサーバーサービス状態変数（Ｐｒｏｘｙ  Ｓｅｒｖｅｒ  Ｓｅｒｖｉｃｅ  Ｓｔａｔｅ  Ｖａｒｉａｂｌｅ）の一実施例である。
【１１２３】
ＵＰｎＰプロキシサーバーサービスは、ＨＴＴＰプロキシサーバーを提供し、第２スクリーンデバイスがＦＬＵＴＥセッションを通じて放送でＴＶ受信機に伝達されるファイルにアクセスするようにすることができ、家庭内の複数の第２スクリーンデバイスが同時に同一ファイルを検索するとき、第２スクリーンデバイスによってインターネットサーバーからより效率的にファイルを検索できるようにする。
【１１２４】
これを可能にさせるために、状態変数及びアクションを定義することができる。
【１１２５】
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービスは、単一状態変数、すなわち、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬを有することができる。
【１１２６】
ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の値は、ＨＴＴＰプロキシサーバーのＵＲＬ、すなわち、プロキシサーバーを通じて要求をルーティング（ｒｏｕｔｅ）するためにＨＴＴＰ要求が向かうＵＲＬであってもよい。
【１１２７】
図９２は、プロキシサーバーサービスアクション（Ｐｒｏｘｙ  Ｓｅｒｖｅｒ  Ｓｅｒｖｉｃｅ  Ａｃｔｉｏｎ）の一実施例である。
【１１２８】
ＵＰｎＰプロキシサーバーサービスは、単一アクション、すなわち、ＧｅｔＰｒｏｘｙＵＲＬを有することができる。
【１１２９】
図９３は、ＧｅｔＰｒｏｘｙＵＲＬアクションの引数の一実施例である。
【１１３０】
ＧｅｔＰｒｏｘｙＵＲＬアクションは、単一引数、すなわち、ＰｒｏｘｙＵＲＬを有することができる。
【１１３１】
ＰｒｏｘｙＵＲＬ出力引数は、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の現在値であってもよい。
【１１３２】
したがって、ＧｅｔＰｒｏｘｙＵＲＬアクションによって、ＰｒｏｘｙＳｅｒｖｅｒＵＲＬ状態変数の現在値を得ることができる。
【１１３３】
図９４は、ＲｅｑｕｅｓｔＦｉｌｅｓ（）の一実施例である。
【１１３４】
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数の他の実施例は、ＡＴＳＣＰｒｏｘｙＳｅｖｅｒＵＲＬというＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、ＧｅｔＰｒｏｘｙＳｅｒｖｅｒＵＲＬ（）というアクションを定義することができる。
【１１３５】
ＡＴＳＣＰｒｏｘｙＳｅｖｅｒＵＲＬ状態変数は、ＵＲＩの形態で受信機内のプロキシサーバーに対する参照を含むことができる。プロキシサーバーは、第２スクリーンデバイスからファイルに対するＨＴＴＰ要求を受け、インターネット又は放送ストリーム内のＦＬＵＴＥセッションからファイルを検索する。その後、プロキシサーバーは、ＨＴＴＰ応答として検索されたファイルを第２スクリーンデバイスに送信する。
【１１３６】
ＧｅｔＰｒｏｘｙＳｅｒｖｅｒＵＲＬ（）は、ＰｒｏｘｙＳｅｖｅｒＵＲＬの値を読み込むようにするアクションであってもよい。ＰｒｏｘｙＳｅｖｅｒＵＲＬを引数として有することができる。
【１１３７】
ＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数の更に他の実施例は、さらに、ＡＴＳＣＦｉｌｅＬｉｓｔというＵＰｎＰ ＨＴＴＰプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、ＲｅｑｕｅｓｔＦｉｌｅｓ（）というアクションを定義することができる。
【１１３８】
放送ストリームに存在するファイルは、放送コンテンツの受信が可能な受信機でのみ取得することができる。したがって、放送コンテンツを受信できない第２スクリーンデバイス上で放送コンテンツに含まれたファイルに接近可能にするために必要なＵＰｎＰ状態変数及びアクションを定義することができる。すなわち、ＦＬＵＴＥセッションを通じてダウンロードしたいファイルリストであるＡＴＳＣＦｉｌｅＬｉｓｔをＵＰｎＰ状態変数として定めたり、第２スクリーンデバイスが受信機に該当のファイルを要求するＲｅｑｕｅｓｔＦｉｌｅｓ（）アクションを通じて特定ファイル或いは複数のファイルを取得できるようにすることができる。
【１１３９】
ＡＴＳＣＦｉｌｅＬｉｓｔ状態変数は、受信機内にプロキシサーバーへの要求されたファイルのＣＳＶリストを含むことができる。
【１１４０】
ＲｅｑｕｅｓｔＦｉｌｅｓ（）は、放送ストリーム或いはインターネット上に存在する特定ファイルをダウンロードするように要求するアクションであってもよい。特に、放送ストリームに存在するファイルの場合、要求したファイルをＦＬＵＴＥセッションを通じてダウンロードするようにすることができる。
【１１４１】
図９５は、第２スクリーンデバイスアーキテクチャの一実施例である。
【１１４２】
動作の理論について説明する。
【１１４３】
２つのモードの動作が存在することができ、その一つの動作モードでは、トリガされたアプリケーション（ＴＤＯ）がＴＶ受信機上で実行され、他の動作モードでは、ノン−トリガされたアプリケーション（パッケージアプリケーション）がＴＶ受信機上で実行される。
【１１４４】
ＴＶ受信機上で実行されるトリガされたアプリケーションの場合、ＴＶ受信機上に現在表示されている番組が、第２スクリーン支援を有する関連したインタラクティブデータサービスを有すると、第２スクリーンデバイスのユーザは、デバイス上の適切なアプリケーションを活性化させることができる。このアプリケーションは、ＵＰｎＰディスカバリ及び記述プロセスを経てＴＶ受信機上のトリガーサービス、両方向通信サービス及びプロキシサーバーサービスを発見することができる。
【１１４５】
すると、第２スクリーンアプリケーションは、トリガーサービスに対するＵＰｎＰ“イベンティング”を申し込み、伝達のために準備されたトリガーの通知を得、ＧｅｔＬａｔｅｓｔＵｎｆｉｌｔｅｒｅｄＴｒｉｇｇｅｒ又はＧｅｔＬａｔｅｓｔＦｉｌｔｅｒｅｄＴｒｉｇｇｅｒアクションを用いて使用するように設計されたトリガーを取得することができる。この結果、第２スクリーンアプリケーションが適切な時間に適切なトリガーを得ることができる。すると、アプリケーションは、いずれの方式で用いられるように設計されても、それらのトリガーに対して動作することができる。
【１１４６】
第２スクリーンアプリケーションはまた、両方向通信サービスに対するＵＰｎＰ“イベンティング”を申し込み、両方向通信のための接続を要求するために用いられるＴＣＰ／ＩＰアドレス及びポートの通知、及び通信する準備がされるプライマリデバイスで実行されるＤＯが存在する時の通知を得ることができる。すると、アプリケーションは、このような通信を支援する任意のＤＯとの両方向通信に参加することができる。
【１１４７】
トリガー及び／又は両方向通信によるアクションはたまたま、第２スクリーンアプリケーションがファイルをダウンロードするように要求することができる。それらのファイルは、インターネット上のＨＴＴＰサーバーから利用可能であるか、又はＴＶ放送内のセッションから利用可能でありうる（又は、両者から利用可能であってもよい）。
【１１４８】
所望の全てのファイルがインターネットを介して利用可能であり、第２スクリーンデバイスがネットワークへの良好な接続性を有すると、アプリケーションは簡単にファイルを直接検索することができる。
【１１４９】
所望のファイルの一部又は全てが、ＴＶ放送のみを通じて利用可能であり、受信機がＨＴＴＰプロキシサーバーサービスを提供すると、アプリケーションは、ＧｅｔＰｒｏｘｙＵＲＬアクションでプロキシサーバーＵＲＬを得、プロキシサーバーを通じて所望のファイルを検索することができる。アプリケーションはまた、直接的な方式よりは、かえってそのようにファイルを検索することがより便利な他の状況ではプロキシサーバーを用いるように選択してもよい。
【１１５０】
ＴＶ受信機上で実行されるノン−トリガーアプリケーションの場合、現在表示されている番組と関係なく、ユーザは、その中でも、ＡｐｐＵＲＬサービスを通じて第２スクリーンデバイス上で開始される同伴者アプリケーションのネーム及び位置を利用可能にするＴＶ受信機上のＤＯを活性化させることができる。
【１１５１】
第２スクリーンデバイス上の制御ポイントは、ＡｐｐＵＲＬサービスと関連したＵＰｎＰ“イベンティング”を申し込み、ＡｐｐＵＲＬ及びＡｐｐＮａｍｅ属性に対する変更の通知を得ることができる。すると、制御ポイントは、利用可能なサービスが係留（ｐｅｎｄｉｎｇ）中であるということを第２スクリーンデバイスのユーザに知らせる。次に、ユーザは、ＡｐｐＮａｍｅを見てサービスを選択し、第２スクリーンデバイス上で同伴者第２スクリーンアプリケーションを開始させる。
【１１５２】
第２スクリーンアプリケーションは、そのＤＯが受信機に以前にダウンロードされた放送社提供パッケージアプリケーションである時にも、ＡＴＳＣ２．０受信機上で実行されるＤＯと関連付けられてもよく、ここで、放送社提供パッケージアプリケーションのライフサイクルは、放送社の代わりに消費者によって制御される。同伴者第２スクリーンアプリケーションを識別するトリガーの不在時に、受信機は、第２スクリーンデバイス上の制御ポイントがＧｅｔＡｐｐＵＲＬアクションを用いて、公開された第２スクリーンアプリケーションＵＲＬにアクセスして第２スクリーンデバイス上で開始するようにするＡｐｐＵＲＬサービスを提供する。
【１１５３】
第２スクリーンデバイスアーキテクチャの一実施例は、受信機と相互作用する第２スクリーンアプリケーションと第２スクリーンデバイスを示している。
【１１５４】
第２スクリーンデバイスアーキテクチャの一実施例は、遠隔コンテンツサーバー９５０１０、ＴＶ受信機９５０２０及び／又は第２スクリーンデバイス９５０３０を含むことができる。
【１１５５】
遠隔コンテンツサーバー９５０１０は、コンテンツを提供できるサーバーであってもよい。受信機９５０２０又は第２スクリーンデバイス９５０３０にコンテンツを提供することができる。
【１１５６】
ＴＶ受信機９５０２０は、ＵＰｎＰトリガーサービス及びＵＰｎＰプロキシサーバーサービスを提供することができる。前述した受信機と同一であってもよい。
【１１５７】
第２スクリーンデバイス９５０３０は、第２スクリーンアプリケーション（ＡＴＳＣ２．０ Ａｐｐ）を有することができ、第２スクリーンアプリケーションは、トリガーハンドラー内にＵＰｎＰ制御ポイント（ＣＰ）モジュールを有することができる。ＵＰｎＰ制御ポイント（ＣＰ）モジュールは、第２スクリーンアプリケーション（ＡＴＳＣ２．０ Ａｐｐ）及びＴＶ受信機９５０２０上のトリガーサービス及びプロキシサーバーサービス間の全てのＵＰｎＰ通信をハンドリングする。ＵＰｎＰ制御ポイント（ＣＰ）モジュールは、探索プロセスを管理し、プロキシサーバーＵＲＬを得、トリガーサービスイベンティングを申し込むことができる。
【１１５８】
ＵＰｎＰトリガーサービスからのトリガーはトリガーハンドラーに伝達されうる。新しいＤＯがＤＡＥ（すなわち、ブラウザ）でダウンロードされて実行されるということをトリガーが示すと、トリガーハンドラーはそれを処理する。ブラウザで既に実行されたＤＯが任意のアクションを取らなければならないとトリガーが指示すると、トリガーハンドラーはトリガーをＤＯに伝達することができる。第２スクリーンデバイスのユーザは、ＤＯと相互作用ですることがきる。トリガーハンドラーはユーザに見えなくてもよい。
【１１５９】
第２スクリーンアプリケーションは、必要によって次の機能を有することができる。１）ＵＰｎＰディスカバリ及び記述プロトコルを用いて、ＴＶ受信機上でトリガーサービス、及び、利用可能であれば、プロキシサーバーサービスを探す。２）ＵＰｎＰ ＳＵＢＳＣＲＩＢＥプロトコルを用いてトリガーサービスイベンティングを申し込む。３）プロキシサーバーサービスのＧｅｔＰｒｏｘｙＵＲＬアクションを実行（ｉｎｖｏｋｅ）して（利用可能であれば）ＨＴＴＰプロキシサーバーのＵＲＬを得る。４）トリガーサービスイベントを通じて伝達されたトリガーを受信する。５）直接実行トリガーが受信され、トリガー内で識別されたＤＯがまだＤＡＥで実行されていないと、（必要なら、まずダウンロードし）ＤＡＥで実行し始める。６）（必要なら、ＤＯをダウンロードして開始した後）各受信された直接実行トリガーを、トリガーで識別されたＤＯに伝達する。７）ＴＤＯトリガーが受信され、トリガーのアクション属性が“ＴｒｉｇｇｅｒＥｖｅｎｔ”以外の任意のものであれば、アクションを実行する（例えば、ＴＤＯ実行を準備、ＴＤＯ実行、ＴＤＯ終了など）。８）ＴＤＯトリガーが受信され、トリガーのアクション属性が“ＴｒｉｇｇｅｒＥｖｅｎｔ”であれば、トリガーを、トリガーのターゲットとして識別されたＴＤＯに伝達する。ＴＤＯがＤＡＥでまだ実行されていないと、トリガーを廃棄する。９）必要によって、インターネットに直接接続してＴＶ受信機上のプロキシサーバーサービスを通じて（ＴＤＯを含む）ファイルをダウンロードする。
【１１６０】
直接実行トリガー及びＴＤＯトリガーは、“スプレッド”又は“ディフュージョン”属性を含まないと、受信するとすぐに動作することができる。トリガーが“スプレッド”又は“ディフュージョン”属性を含むと、アクションはランダム間隔だけ遅延されうる。
【１１６１】
図９６は、受信機の簡略化した構造図の一実施例である。
【１１６２】
受信機の簡略化した構造図は、アンテナ（ｒｃｖｒ２０１０）、チューナー（ｒｃｖｒ２０２０）、ＥＰＧ（ｒｃｖｒ２０３０）、ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）、チャネルマネジャー（ｒｃｖｒ２０５０）、ＳＩモジュール（ｒｃｖｒ２０５１）、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）、キャプションモジュール（ｒｃｖｒ２０７０）、トリガーモジュール（ｒｃｖｒ２０８０）、ウェブブラウザ（ｒｃｖｒ２０９０）、ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）、ネットワークプロトコルスタック（ｒｃｖｒ２１００）、ネットワークインターフェース（ｒｃｖｒ２１１０）、ＵＩモジュール（ｒｃｖｒ２１２０）、オーディオデコーダ（ｒｃｖｒ２１４０）、ビデオデコーダ（ｒｃｖｒ２１５０）、スピーカー（ｒｃｖｒ２１６０）、ディスプレイモジュール（ｒｃｖｒ２１７０）、グラフィックプロセッサ（ｒｃｖｒ２１８０）、遠隔制御器受信器（ｒｃｖｒ２１９０）及び／又は遠隔制御器（ｒｃｖｒ２２００）を含むことができる。
【１１６３】
アンテナ（ｒｃｖｒ２０１０）は、放送ストリームによって放送信号を受信することができる。ここで、アンテナ（ｒｃｖｒ２０１０）は、技術の分野で一般に用いられるものであってもよい。
【１１６４】
チューナー（ｒｃｖｒ２０２０）は、受信機のチャネルを探したり同調することができ、無線周波数増幅器、ローカルオシレータ、周波数変換及び入力回路、探知器（ｓｅｅｋｅｒ）などを含むことができる。チューナー（ｒｃｖｒ２０２０）は、技術の分野で一般に用いられるものであってもよい。
【１１６５】
ＥＰＧ（ｒｃｖｒ２０３０）は、ＴＶ放送の空いている周波数帯や付加チャネルを用いてＴＶ番組の放送時間と内容、出演者情報などを送る放送プログラム案内サービスであってもよい（Ｅｌｅｃｔｒｏｎｉｃ  ｐｒｏｇｒａｍ  ｇｕｉｄｅ）。受信されたＥＰＧデータは記憶しておき、視聴者がリモコンでこのＥＰＧを操作してプログラムを選択して予約し、ペア・バー・ビュー方式（ｐａｙ  ｐｅｒ  ｖｉｅｗ）プログラム注文、主題又は種別プログラム検索、ビデオ録画などを可能にする。受信したＥＰＧは、ＵＩモジュールにも伝達されてもよい。
【１１６６】
ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）は、ＶＳＢ信号又はＤＶＢ信号を復調することができる。ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）は、変調されたＶＳＢ又はＤＶＢ（ｅ．ｇ．，ＯＦＤＭ−変調信号）を本来の信号に回復することができる。ＶＳＢ又はＤＶＢ復調器（ｒｃｖｒ２０４０）の復調プロセスは、技術の分野で一般に用いられるものであってもよい。
【１１６７】
チャネルマネジャー（ｒｃｖｒ２０５０）は、受信されたＥＰＧを用いて、チャネル管理を行うことができる。ＳＩモジュールで処理されたＥＰＧを伝達することができる。一般のチャネルマネジャー役割を担うことができる。
【１１６８】
ＳＩモジュール（ｒｃｖｒ２０５１）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）を通じて放送ストリームが入ってくると、プログラム構成情報（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）を把握することができる。このように把握された情報から、この放送プログラムにいくつのキャプションがあり、トリガーがサービス＃６にあるか否かなどがわかる。
【１１６９】
ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、復調された信号の送信ストリーム（ＴＳ）をデコードすることができる。ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、送信ストリームからキャプションストリームを得てキャプションモジュール（ｒｃｖｒ２０７）に伝達することができる。ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）は、デコードされたオーディオ及びビデオ信号をオーディオ／ビデオデコーダに送信することができる。
【１１７０】
キャプションモジュール（ｒｃｖｒ２０７０）は、キャプションストリームを受信することができる。キャプションモジュール（ｒｃｖｒ２０７０）は、サービス＃６又は他のサービスをモニタし、サービス＃６又はトリガーを送信するトリガーが選択されてトリガーモジュール（ｒｃｖｒ２０８０）に伝送されるか、又はキャプションテキストが処理されてスクリーン上にディスプレイされるかを決定することができる。トリガーデータは、トリガーモジュール（ｒｃｖｒ２０８０）に伝達することができる。他のキャプションサービスは、キャプションテキスト処理してグラフィックプロセッサ（ｒｃｖｒ２１８０）に伝送することができる。キャプションモジュール（ｒｃｖｒ２０７０）は、前述したＳＩモジュール（ｒｃｖｒ２０５１）が把握した情報に基づいて、現在受信されているデジタルキャプション中にトリガーがある場合にはトリガーモジュール（ｒｃｖｒ２０８０）に伝達する。
【１１７１】
トリガーモジュール（ｒｃｖｒ２０８０）は、トリガー、ＴＰＴ及び／又はＡＭＴ情報をパーシングし、パーシングされたデータを処理することができる。トリガーモジュール（ｒｃｖｒ２０８０）は、トリガーのＵＲＩ情報値を用いて、ネットワークプロトコルスタック（ｒｃｖｒ２１００）を通じてネットワークにアクセスすることができる。ＵＲＩ情報値は、ＨＴＴＰサーバーのアドレスであってもよい。トリガーモジュール（ｒｃｖｒ２０８０）は、ＴＰＴファイルコンテンツを分析してＴＤＯ ＵＲＬを得ることができる。また、トリガーモジュール（ｒｃｖｒ２０８０）は、ＡＭＴをパーシングしてデータを処理することができる。他の情報は、パーシングを通じて得ることができる。ＡＭＴメッセージが受信された後、ウェブブラウザに対応するＴＤＯ ＵＲＬは、所定の時間及び動作によって伝達されたり、現在動作中のＴＤＯが所定の時間に停止することができる。これは、ＴＤＯアクションに対応し、トリガーモジュール（ｒｃｖｒ２０８０）は動作するウェブブラウザにコマンドを送信することができる。本発明に係るトリガーモジュール（ｒｃｖｒ２０８０）の動作は、以下に詳述する。トリガーモジュール（ｒｃｖｒ２０８０）は、直間接的にネットワークプロトコルスタック（ｒｃｖｒ２１００）を通じてインターネットにおけるサーバーに接続することができる。トリガーモジュール（ｒｃｖｒ２０８０）は直ちに、ＤＴＶＣＣで受信されたトリガーを分析し、必要な場合、ネットワークインターフェース（ｒｃｖｒ２１１０）を介して、ＴＰＴファイルをインターネットからダウンロードして処理することができる。ＴＰＴファイルをダウンロードするとすぐに処理して必要な動作を取ることができる。このとき、もし、第２スクリーンに関連したトリガーであり、関連したイベントがあると、前述したように、様々な方式で第２スクリーンデバイスと通信することができる。このような通信は、後述するＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）で行うことができる。
【１１７２】
ウェブブラウザ（ｒｃｖｒ２０９０）は、トリガーモジュール（ｒｃｖｒ２０８０）からコマンドを受信し、ＵＩモジュール（ｒｃｖｒ２１２０）からブラウザキーコードを受信し、遠隔制御器受信器（ｒｃｖｒ２１９０）からブラウザキーコードを受信し、ネットワークプロトコルスタック（ｒｃｖｒ２１００）と通信することができる。
【１１７３】
ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）は、第２スクリーンデバイスを発見してトリガーを送信したり、或いは第２スクリーンデバイスに必要な情報を再生成して送信することができる。前述したように、ネットワークインターフェース（ｒｃｖｒ２１１０）を通じてトリガーを受けたとき、第２スクリーンに関連したトリガーであり、関連したイベントがあると、ＵＰｎＰフレームワーク（ｒｃｖｒ２０９１）は、第２スクリーンデバイスと通信することができる。
【１１７４】
ネットワークプロトコルスタック（ｒｃｖｒ２１００）は、トリガーモジュール（ｒｃｖｒ２０８０）及びウェブブラウザと通信し、ネットワークインターフェース（ｒｃｖｒ２１１０）を介してサーバーにアクセスすることができる。
【１１７５】
ネットワークインターフェース（ｒｃｖｒ２１１０）は、いくつかの他の装置の共同接続又はネットワークコンピュータ及び外部ネットワークの接続を行う。ネットワークインターフェースはサーバーに接続してＴＤＯ、ＴＰＴ、ＡＭＴなどをダウンロードすることができる。ここで、ネットワークインターフェース（ｒｃｖｒ２１１０）の動作は、技術の分野で一般に用いられるネットワークインターフェース（ｒｃｖｒ２１１０）の動作であってもよい。本発明に係るネットワークインターフェース（ｒｃｖｒ１０９０）の動作は、以下に詳述する。
【１１７６】
ＵＩモジュール（ｒｃｖｒ２１２０）は遠隔制御器受信器（ｒｃｖｒ２１９０）から、遠隔制御器（ｒｃｖｒ２２００）を用いて視聴者によって入力された情報を受信することができる。受信された情報がネットワークを用いたサービスと関連するものであれば、ブラウザキーコードをウェブブラウザに伝達することができる。受信された情報が現在ディスプレイされるビデオと関連するものであれば、信号を、グラフィックプロセッサ（ｒｃｖｒ２１８０）を通じてディスプレイモジュール（ｒｃｖｒ２１７０）に伝達することができる。
【１１７７】
オーディオデコーダ（ｒｃｖｒ２１４０）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）から受信されたオーディオ信号をデコードすることができる。その後、デコードされたオーディオ信号は、スピーカーに伝送し、視聴者に出力することができる。ここで、オーディオデコーダ（ｒｃｖｒ２１４０）は、技術の分野で一般に用いられるものであってもよい。
【１１７８】
ビデオデコーダ（ｒｃｖｒ２１５０）は、ＭＰＥＧ−２ＴＳシステムデコーダ（ｒｃｖｒ２０６０）から受信されたビデオ信号をデコードすることができる。その後、デコードされたビデオ信号は、ディスプレイモジュール（ｒｃｖｒ２１７０）に伝送し、視聴者に出力することができる。ここで、ビデオデコーダ（ｒｃｖｒ２１５０）は、技術の分野で一般に用いられるものであってもよい。
【１１７９】
スピーカー（ｒｃｖｒ２１６０）は、オーディオ信号を視聴者に出力することができる。スピーカーは、技術の分野で一般に用いられるものであってもよい。
【１１８０】
ディスプレイモジュール（ｒｃｖｒ２１７０）は、ビデオ信号を視聴者に出力することができる。ディスプレイモジュール（ｒｃｖｒ２１７０）は、技術の分野で一般に用いられるものであってもよい。
【１１８１】
グラフィックプロセッサ（ｒｃｖｒ２１８０）は、キャプションモジュール（ｒｃｖｒ２０７０）から受信されたキャプションテキスト、及びＵＩモジュール（ｒｃｖｒ２１２０）から受信された視聴者入力情報に対してグラフィック処理を行うことができる。処理された情報は、ディスプレイモジュール（ｒｃｖｒ２１７０）に伝達することができる。グラフィックプロセッサ（ｒｃｖｒ２１８０）は、技術の分野で一般に用いられるものであってもよい。
【１１８２】
遠隔制御器受信器（ｒｃｖｒ２１９０）は、遠隔制御器（ｒｃｖｒ２２００）から情報を受信することができる。この時、キーコードはＵＩモジュール（ｒｃｖｒ２１２０）に伝達し、ブラウザキーコードはウェブブラウザに伝達することができる。
【１１８３】
遠隔制御器（ｒｃｖｒ２２００）は、視聴者によって入力された信号を遠隔制御器受信器（ｒｃｖｒ２１９０）に伝達する。遠隔制御器（ｒｃｖｒ２２００）は、仮想チャネルを変更する視聴者入力を受信することができる。また、遠隔制御器は、アプリケーションに対して視聴者によって選択された情報を受信することができる。遠隔制御器（ｒｃｖｒ２２００）は、受信された情報を遠隔制御器受信器（ｒｃｖｒ２１９０）に伝達することができる。このとき、情報は、所定範囲外の距離で赤外線（ＩＲ）光を用いて遠隔で伝達することができる。
【１１８４】
図９７は、第２スクリーンデバイスの構造図の一実施例である。
【１１８５】
第２スクリーンデバイスの構造図の一実施例は、ＩＯサブシステム９７０１０、ファイルシステ（９７０２）、ネットワークプロトコルサブシステム９７０３０、及び／又は基本モジュール９７０４０を含むことができる。
【１１８６】
ＩＯサブシステム９７０１０は、第２スクリーンデバイスに装着可能な、外部接続される全ての装置が接続されていてもよい。ＩＯサブシステム９７０１０には、キーパッド、ディスプレイ、マイクロホン、スピーカー、ステレオジャッキ、動きセンサー、光センサー、ＧＰＳ及び／又はカメラなどを接続することができる。各入出力装置は、それぞれ、キーモジュール、ディスプレイ制御、オーディオ制御、センサー制御及び／又はカメラ制御によって制御されうる。各入出力装置は、デバイスドライバでコントロールされ、それぞれのセンサーやカメラなどは、ＩＯサブシステム９７０１０によってＳＤＫ形態で関数を呼び出すと、いずれのプログラムであっても接近可能である。場合によっては、機能に制限をおき、ネイティブアプリケーションでのみ接近可能にしてもよい。
【１１８７】
ファイルシステム９７０２０は、外部ＳＤカードに対するファイルを読み書き可能になっており、ＵＳＢに接続してデータ通信可能である。ＳＤカード、フラッシュメモリー、ＵＳＢなどの装置が接続可能である。それぞれＳＤインターフェース、フラッシュメモリー制御、ＵＳＢバス制御によって制御されうる。
【１１８８】
ネットワークプロトコルサブシステム（９７０３０）では、３ＧＰＰ、Ｗｉ−Ｆｉ及び／又はブルートゥースなどを介して通信可能である。
【１１８９】
基本モジュール（９７０４０）は、その他、第２デバイスで基本的なモジュールなどがありうる。バッテリーマネジャーは、第２スクリーンデバイスのバッテリー量などを管理し、通知は、通信社或いはメーカーで第２スクリーンデバイスに通知する場合に用いられるモジュールであってもよい。また、ストアモジュールは、第２スクリーンデバイスで提供するオープンＳＤＫを用いて作られた第２スクリーン用アプリケーションを購買するモジュールであってもよい。アプリケーションマネジャーは、ストアモジュールを用いて設置されたアプリケーションを管理し、設置されたアプリケーションがアップグレードされた場合にもそれを知らせることができる。また、第２スクリーンデバイスでインターネット接続できるようにウェブモジュールが内蔵されていてもよい。個人の好みによって第２スクリーンの様々な機能に対する便宜設定をしてもよいが、ユーザ好みのプログラムを用いることができる。
【１１９０】
基本モジュール９７０４０は、その他、様々な機能を有し、基本的に、第２スクリーンデバイスに内蔵されていなければならないプログラムである。しかし、点線で表示されたモジュールは、選択的にユーザが設置すると動作するソフトウェアモジュールであってもよい。
【１１９１】
例えば、ＵＰｎＰフレームワークモジュールは、基本的に第２スクリーンデバイスで支援しない場合にも、内蔵されていてもよい。内蔵される場合には、ネイティブアプリケーションも併せて内蔵され、ＵＰｎＰ動作を円滑にしなければならない。本受信機の構造図では、ＵＰｎＰフレームワークは、選択的にユーザが第２スクリーンサービスアプリケーション或いはＵＰｎＰフレームワークを支援するアプリケーションを設置することができる。ＵＰｎＰフレームワークモジュールを介して、地上波を受信し得る受信機を探すことができる。
【１１９２】
図９８は、第２スクリーンデバイスシナリオの一実施例である。
【１１９３】
第２スクリーンデバイスシナリオの一実施例について説明する。
【１１９４】
第２スクリーンデバイスシナリオの一実施例は、トリガーを受信する段階（ｓ９８０１０）、ＴＰＴを要求する段階（ｓ９８０２０）、応答としてＴＰＴを送信する段階（ｓ９８０３０）、ＴＤＯを要求する段階（ｓ９８０４０）、応答としてＴＤＯを送信する段階（ｓ９８０５０）、ＴＤＯを実行する段階（ｓ９８０６０）、ｓｃａｎＤｅｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ９８０７０）、ディスカバリ機能を呼び出す段階（ｓ９８０８０）、ＵＰｎＰアプリケーションを実行する段階（ｓ９８０９０）、サーチメッセージをマルチキャストする段階（ｓ９８１００）、ＵＰｎＰフレームワークを通知する段階（ｓ９８１１０）、装置リストを返還する段階（ｓ９８１２０）、装置ハンドルを返還する段階（ｓ９８１３０）、ｓｃａｎＳｅｒｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ９８１４０）、サービスリスト機能を呼び出す段階（ｓ９８１５０）、ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ９８１６０）、ＨＴＴＰメッセージを送信する段階（ｓ９８１７０）、サービスリストを返還する段階（ｓ９８１８０）、サービスハンドルのリストを返還する段階（ｓ９８１９０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８２００）、サービスリスト機能を呼び出す段階（ｓ９８２１０）、ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ９８２２０）、ＨＴＴＰメッセージを送信する段階（ｓ９８２３０）、ｓｏａｐ応答を返還する段階（ｓ９８２４０）、ｓｏａｐ応答ＸＭＬを返還する段階（ｓ９８２５０）、ｓｏａｐ応答をパーシングする段階（ｓ９８２６０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８２７０）、サービスリスト機能を呼び出す段階（ｓ９８２８０）、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ９８２９０）、ＨＴＴＰメッセージを送信する段階（ｓ９８３００）、ｓｏａｐ応答を返還する段階（ｓ９８３１０）、ＴｉｍｅＴｏＬｉｖｅを返還する段階（ｓ９８３２０）、ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８３３０）、サービスリスト機能を呼び出す段階（ｓ９８３４０）、ＤｉｓｐｌａｙＭｅｓｓａｇｅ送信する段階（ｓ９８３５０）、ＨＴＴＰ ｍｅｓｓａｇｅを送信する段階（ｓ９８３６０）、ヌル（ｎｕｌｌ）を返還する段階（ｓ９８３７０）、ヌルを返還する段階（ｓ９８３８０）、及び／又は第２スクリーンアプリケーションを実行する段階（ｓ９８３９０）を含むことができる。
【１１９５】
トリガーを受信する段階（ｓ９８０１０）は、放送社から放送ストリームを通じてＤＴＶＣＣ ｉＴＶメッセージでトリガーを受信する段階であってもよい。
【１１９６】
ＴＰＴを要求する段階（ｓ９８０２０）は、受信したトリガーをパーシングし解釈して、放送社インターネットサーバーに関連したＴＰＴを要求する段階であってもよい。
【１１９７】
応答としてＴＰＴを送信する段階（ｓ９８０３０）は、要求されたＴＰＴを送る段階であってもよい。
【１１９８】
ＴＤＯを要求する段階（ｓ９８０４０）は、関連したＴＤＯをダウンロードする必要がある場合、放送社インターネットサーバーに関連ＴＤＯを要求する段階であってもよい。
【１１９９】
応答としてＴＤＯを送信する段階（ｓ９８０５０）は、要求されたＴＤＯを送る段階であってもよい。
【１２００】
ＴＤＯを実行する段階（ｓ９８０６０）は、トリガーモジュールがＴＤＯを実行させる段階であってもよい。
【１２０１】
ｓｃａｎＤｅｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ９８０７０）は、実行されたＤＯ（又はＴＤＯ）がデバイススキャンのためにデバイスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
【１２０２】
ディスカバリ機能を呼び出す段階（ｓ９８０８０）は、デバイスディスカバリのためにＵＰｎＰフレームワークのディスカバリ機能を呼び出す段階であってもよい。
【１２０３】
ＵＰｎＰアプリケーション（ｓ９８０９０）は、第２スクリーンデバイスで第２スクリーンサービスランチャ用ＵＰｎＰアプリケーションを実行する段階であってもよい。この段階は、プライマリデバイスと独立した段階であり、ＵＰｎＰアプリケーションを実行する段階（ｓ９８０９０）前に実行されてもよい。
【１２０４】
サーチメッセージをマルチキャストする段階（ｓ９８１００）は、ＵＰｎＰフレームワークが第２スクリーンデバイスを探すサーチメッセージをホームネットワーク内にマルチキャストする段階であってもよい。
【１２０５】
ＵＰｎＰフレームワークを通知する段階（ｓ９８１１０）は、サーチメッセージを受けた第２スクリーンデバイスが通知メッセージをプライマリデバイスに送信する段階であってもよい。これで、第２スクリーンデバイスの存在を知らせることができる。
【１２０６】
デバイスリストを返還する段階（ｓ９８１２０）は、ＵＰｎＰフレームワークがデバイスディスカバリ後に、デバイスリストを返還する段階であってもよい。
【１２０７】
デバイスハンドルを返還する段階（ｓ９８１３０）は、受信したデバイスリストをＤＯに伝達する段階であってもよい。
【１２０８】
ｓｃａｎＳｅｒｖｉｃｅＬｉｓｔメッセージを送信する段階（ｓ９８１４０）は、実行されたＤＯ（又は、ＴＤＯ）がサービススキャンのためにサービスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
【１２０９】
サービスリスト機能を呼び出す段階（ｓ９８１５０）は、サービスディスカバリのために、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
【１２１０】
ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ９８１６０）は、第２スクリーンデバイスのサービス記述を得るために第２スクリーンデバイスに要求する段階であってもよい。
【１２１１】
ＨＴＴＰメッセージを送信する段階（ｓ９８１７０）は、ＧｅｔＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎメッセージを送信する段階（ｓ９８１６０）における要求に対する結果を送る段階であり、前述したように、ＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。サービス記述をＸＭＬ形態で受信することもできる。
【１２１２】
サービスリストを返還する段階（ｓ９８１８０）は、ＵＰｎＰフレームワークがサービス記述を受けた後、サービスリストを返還する段階であってもよい。
【１２１３】
サービスハンドルのリストを返還する段階（ｓ９８１９０）は、受信したサービスリストをリターンする段階であってもよい。
【１２１４】
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８２００）は、デバイスプロファイルを得るためにメッセージを送る段階であってもよい。
【１２１５】
サービスリスト機能を呼び出す段階（ｓ９８２１０）は、サービスディスカバリのために、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
【１２１６】
ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ９８２２０）は、第２スクリーンデバイスのサービス記述を得るために第２スクリーンデバイスに要求する段階であってもよい。前述したＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅアクションを用いることができる。ＨＴＴＰメッセージを送信する段階（ｓ９８２３０）は、ＧｅｔＤｅｖｉｃｅＰｒｏｆｉｌｅメッセージを送信する段階（ｓ９８２２０）における要求に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。デバイスプロファイルを受信することもできる。
【１２１７】
ｓｏａｐ応答を返還する段階（ｓ９８２４０）は、受信したデバイスプロファイルを返還する段階であってもよい。
【１２１８】
ｓｏａｐ応答ＸＭＬを返還する段階（ｓ９８２５０）は、受信したデバイスプロファイルをＸＭＬ形態で返還する段階であってもよい。
【１２１９】
ｓｏａｐ応答をパーシングする段階（ｓ９８２６０）は、ＤＯが受信したＳＯＡＰ ｍｅｓｓａｇｅをパーシングする段階であってもよい。
【１２２０】
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８２７０）は、第２スクリーンサービスのＵＲＬアドレスを第２スクリーンデバイスに知らせるためにメッセージを送る段階であってもよい。
【１２２１】
サービス呼び出しリスト機能を呼び出す段階（９８２８０）は、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
【１２２２】
ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ９８２９０）は、第２スクリーンサービスのＵＲＬアドレスを第２スクリーンデバイスに知らせる段階であってもよい。前述したＡｄｄＵＩＬｉｓｔｉｎｇアクションを用いることができる。第２スクリーンデバイスは、取得したＵＲＬをＵＩＬｉｓｔｉｎｇに追加することができる。
【１２２３】
ＨＴＴＰメッセージを送信する段階（ｓ９８３００）は、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ９８２９０）における要求に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。
【１２２４】
ｓｏａｐ応答を返還する段階（ｓ９８３１０）は、ＵＲＬの送信がなされたことを知らせるためのメッセージを返還する段階であってもよい。
【１２２５】
ＴｉｍｅＴｏＬｉｖｅを返還する段階（ｓ９８３２０）は、ＨＴＴＰ ｍｅｓｓａｇｅを送信する段階（ｓ９８３００）と同様に、ＩｎｐｕｔＵＩＬｉｓｔｉｎｇメッセージを送信する段階（ｓ９８２９０）における要求に対する結果を送る段階であってもよい。
【１２２６】
ｈｎＨａｎｄｌｅメッセージを送信する段階（ｓ９８３３０）は、ディスプレイメッセージを第２スクリーンデバイスに伝達するために、メッセージを送る段階であってもよい。
【１２２７】
サービスリスト機能を呼び出す段階（ｓ９８３４０）は、ＵＰｎＰフレームワークのサービスリスト機能を呼び出す段階であってもよい。
【１２２８】
ＤｉｓｐｌａｙＭｅｓｓａｇｅを送信する段階（ｓ９８３５０）は、第２スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したＤｉｓｐａｌｙＭｅｓｓａｇｅアクションを用いることができる。第２スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第２スクリーンにディスプレイすることができる。
【１２２９】
ＨＴＴＰメッセージを送信する段階（ｓ９８３６０）は、ＤｉｓｐｌａｙＭｅｓｓａｇｅを送信する段階（ｓ９８３５０）に対する結果を送る段階であり、前述したようにＨＴＴＰ／１．１ ２００ ＯＫ（成功）のようなメッセージを送ることができる。
【１２３０】
ヌルを返還する段階（ｓ９８３７０）は、ＨＴＴＰ／１．１ ２００ ＯＫを受けた場合、ヌルを返還する段階であってもよい。
【１２３１】
ヌルを返還する段階（ｓ９８３８０）は同様に、ヌルを応答として受けた場合、ＤＯにヌルを返還する段階であってもよい。
【１２３２】
第２スクリーンアプリケーションを実行する段階（ｓ９８３９０）は、第２スクリーンデバイスで第２スクリーンアプリケーションを実行する段階であってもよい。
【１２３３】
図９９は、第１デバイスでインタラクティブサービスを処理する方法の一実施例である。
【１２３４】
第１デバイスでインタラクティブサービスを処理する方法の一実施例は、ディスカバリメッセージを送信する段階（ｓ９９０１０）、記述に対する要求を受信する段階（ｓ９９０２０）、記述を有する応答を送信する段階（ｓ９９０３０）、トリガーを受信する段階（ｓ９９０４０）、情報を結合して増加した活性化トリガーを生成する段階（ｓ９９０５０）、及び／又は生成された増加した活性化トリガーを送信する段階（ｓ９９０６０）を含むことができる。
【１２３５】
ディスカバリメッセージを送信する段階（ｓ９９０１０）は、ディスカバリメッセージを、第２デバイスで実行される第２スクリーンアプリケーションに送る段階であってもよい。ディスカバリメッセージは、第１デバイスが提供できる第２スクリーン支援サービスを知らせる役割を担うことができる。ここで、第１デバイスは、前述したプライマリデバイス、ＴＶ受信機であってもよい。ここで、ディスカバリメッセージは、一つの第２スクリーンデバイスではなく複数個の第２スクリーンデバイスにマルチキャストする方式であってもよい。ここで、第２スクリーン支援サービスは、前述した第２スクリーンサービスであってもよい。ディスカバリメッセージを送信する段階（ｓ９９０１０）は、前述したデバイスディスカバリ段階に含まれてもよい。
【１２３６】
記述に対する要求を受信する段階（ｓ９９０２０）は、第１デバイスが提供できる第２スクリーン支援サービスに対する記述に対する要求を受信する段階であってもよい。第２デバイスは、前述した第２スクリーンデバイスであってもよい。第２スクリーンデバイスで実行中の第２スクリーンアプリケーションは、第１デバイスが提供できる第２スクリーン支援サービスに対する記述を第１デバイスに要求することができる。記述に対する要求を受信する段階（ｓ９９０２０）は、その要求を第１デバイスにとって受信する段階であってもよい。この段階は、前述したデバイスディスカバリ段階に含まれてもよい。
【１２３７】
記述を有する応答を送信する段階（ｓ９９０３０）は、第１デバイスが記述に対する要求を受信する段階（ｓ９９０２０）における要求に対する応答で記述を第２スクリーンアプリケーションに送信する段階であってもよい。この応答には、記述に加えて、他の情報が含まれてもよい。この段階は、前述したデバイスディスカバリ段階に含まれてもよい。
【１２３８】
トリガーを受信する段階（ｓ９９０４０）は、第１デバイスが前述したトリガーを放送ストリーム又はインターネットサーバーを通じて受ける段階であってもよい。放送ストリームを受ける場合、前述した通り、ＤＴＶＣＣを通じて受けることができる。インターネットサーバーを通じて受ける場合、前述した通り、ｉＴＶメッセージの形態又はＡＣＲプロセスを通じて受けることができる。このトリガーは、その後、前述したトリガーサービスによって第２スクリーンアプリケーションに伝達されうる。前述した通り、トリガーサービスは、第２スクリーン支援サービスの一つであってもよい。前述した通り、トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントに対するアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立する。受信したトリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーのうちの一つであってもよい。相互作用トリガーは、ＴＤＯ相互作用モデル以外の相互作用モデルのためのトリガーであってもよい。例えば、直接実行モデルにおけるコンテンツｉｄ用語を有するトリガーであってもよい。チャネル変更トリガーは、前述した特殊チャネル変更トリガーであり、チャネルが変わる時に受信することができる。
【１２３９】
情報を結合して増加した活性化トリガーを生成する段階（ｓ９９０５０）は、受信したトリガーのうち、活性化トリガー内の情報とＴＰＴ内の情報を抽出し、結合する段階であってもよい。これは、前述の増加したトリガー、増加した活性化トリガー、拡張されたトリガーを生成する段階と同一の段階であってもよい。増加した活性化トリガーの生成過程及び生成後のフォーマットは、前述した通りである。
【１２４０】
生成された増加した活性化トリガーを送信する段階（ｓ９９０６０）は、生成された増加した活性化トリガーを第２スクリーンアプリケーションに送信する段階であってもよい。これは、トリガーサービスのうち、前述したフィルタリングされたストリームオプションによるものであってもよい。
【１２４１】
本発明の一実施例は、サーチメッセージを受信する段階を、ディスカバリメッセージを送る前に行うことができる。サーチメッセージは、第２スクリーン支援サービスを提供するデバイスを探すためのものであってもよい。サーチメッセージは、ユニキャスティング又はマルチキャストする方式で伝送することができる。この段階によって、第２スクリーンデバイスが第１デバイスを探すことができる。
【１２４２】
本発明の他の実施例は、トリガーサービスがフィルタリングされていないストリームオプションでトリガーを伝達することができる。フィルタリングされていないストリームオプションは、前述した通り、全てのタイプのトリガーを第２スクリーンデバイスに伝達することができる。
【１２４３】
本発明の更に他の実施例は、フィルタリングされていないストリームオプションにおいて、全てのトリガーを第１デバイスが受けるとすぐに第２スクリーンアプリケーションに伝達することができる。
【１２４４】
本発明の更に他の実施例は、トリガーサービスがフィルタリングされたストリームオプションを提供することができる。前述した通り、フィルタリングされたストリームオプションは、増加した活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーを伝達することができる。
【１２４５】
本発明の更に他の実施例では、増加した活性化トリガーが、アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含む。ＵＲＬエレメントは、アプリケーションの一部であるファイルを識別し、アプリケーションエレメントは、活性化トリガーによって識別される。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、アプリケーションＵＲＬ情報は、前述の増加した活性化トリガーの＠ａｐｐＵＲＬであってもよい。ここで、ＵＲＬエレメントは、ＴＰＴのＴＤＯエレメント内のＵＲＬエレメントであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のＵＲＬエレメント値を取ったものであり、アプリケーションＵＲＬ情報とＵＲＬエレメントは同一の値を有することができる。
【１２４６】
本発明の更に他の実施例では、増加した活性化トリガーは、アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、活性化トリガーによって識別されたイベントエレメントは、アプリケーションのためのイベントを示し、イベント情報は、活性化トリガーによって識別されたイベントエレメントのアクション属性と同じ値を有するアクション情報を含み、アクション属性は、イベントが活性化される時に適用されるアクションのタイプを示す。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、イベント情報は、前述の増加した活性化トリガーのイベントエレメントであってもよい。ここで、イベントエレメントは、ＴＰＴのＴＤＯエレメント内のイベントエレメントであってもよい。ここで、アクション情報は、前述の増加した活性化トリガーの＠ａｃｔｉｏｎであってもよい。ここで、アクション属性は、ＴＰＴのイベントエレメント内の＠ａｃｔｉｏｎであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のイベントエレメント値と＠ａｃｔｉｏｎ値を取ったものであり、アクション情報とアクション属性は同一の値を有することができる。
【１２４７】
本発明の更に他の実施例では、第１デバイスは増加した活性化トリガーの活性化時間で増加した活性化トリガーを伝達し、第１デバイスは、相互作用トリガーが第１デバイスによって受信される時に相互作用トリガーを伝達し、第１デバイスは、チャネルが変更される時にチャネル変更トリガーを伝達する。増加した活性化トリガーは、前述した通り、活性化時間又はそれよりもやや前に伝達することができ、相互作用トリガーは、第１デバイスが受信するとすぐに第２スクリーンアプリケーションに伝達することができ、チャネル変更トリガーは、チャネルが変更された場合に伝達することができる。
【１２４８】
図１００は、第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法の一実施例である。
【１２４９】
第２デバイスで実行される第２スクリーンアプリケーションでインタラクティブサービスを処理する方法の一実施例は、ディスカバリメッセージを受信する段階（ｓ１００１０）、記述に対する要求を送信する段階（ｓ１００２０）、記述を有する応答を受信する段階（ｓ１００３０）、トリガーサービスをアクセスする段階（ｓ１００４０）、及び／又は第１デバイスからトリガーを受信する段階（ｓ１００５０）を含むことができる。
【１２５０】
ディスカバリメッセージを受信する段階（ｓ１００１０）は、第１デバイスからディスカバリメッセージを受信する段階である。前述した通り、第１デバイスはプライマリデバイス、ＴＶ受信機であってもよい。第２デバイスは、前述した第２スクリーンデバイスであってもよい。ディスカバリメッセージは、第１デバイスが提供できる第２スクリーン支援サービスを知らせる役割を担うことができる。第１デバイスは、ディスカバリメッセージを第２デバイスにのみ送ってもよく、ホームネットワーク内の全ての機器にマルチキャストしてもよい。この段階は、前述したデバイスディスカバリ段階に含まれる段階であってもよい。第１デバイスが送ったディスカバリメッセージを受信した動作を第２デバイスの立場で記述した段階であってもよい。ディスカバリメッセージを送信する段階（ｓ９９０１０）を第２スクリーンアプリケーションの立場で記述した段階であってもよい。
【１２５１】
記述に対する要求を送信する段階（ｓ１００２０）は、第１デバイスに、第１デバイスが提供する第２スクリーン支援サービスの記述を要求する段階であってもよい。記述に対する要求を受信する段階（ｓ９９０２０）を第２スクリーンアプリケーションの立場で記述した段階であってもよい。前述したデバイスディスカバリ段階に含まれる段階であってもよい。
【１２５２】
記述を有する応答を受信する段階（ｓ１００３０）は、記述に対する要求を送信する段階（ｓ１００２０）で送った要求に対する応答として、サービスに対する記述を受信する段階である。第１デバイスは、第２スクリーンアプリケーションに自身のサービスの記述を送信することができる。前述した記述を有する応答を送信する段階（ｓ９９０３０）を第２スクリーンアプリケーションの立場で記述した段階であってもよい。前述したデバイスディスカバリ段階に含まれる段階であってもよい。
【１２５３】
トリガーサービスをアクセスする段階（ｓ１００４０）は、第２スクリーン支援サービスの一つであるトリガーサービスに接近する段階であってもよい。第１デバイスが放送ストリーム又はインターネットサーバーから受信したトリガーを受信するためのものであってもよい。トリガーサービスへの接近は、記述を有する応答を受信する段階（ｓ１００３０）で受信した記述に基づいて行われてもよい。記述を有する応答を受信する段階（ｓ１００３０）で受信した記述のうち、トリガーサービスに対する記述を用いることができる。
【１２５４】
第１デバイスからトリガーを受信する段階（ｓ１００５０）は、接近したトリガーサービスを用いて第１デバイスからトリガーを受信する段階であってもよい。ここで、トリガーサービスは、第２スクリーン支援サービスの一つであってもよい。トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントに対するアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することである。ここで、トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーの一つであってもよい。相互作用トリガーは、ＴＤＯ相互作用モデル以外の相互作用モデルのためのトリガーであってもよい。例えば、直接実行モデルにおけるコンテンツｉｄ用語を有するトリガーであってもよい。チャネル変更トリガーは、前述した特殊チャネル変更トリガーであり、チャネルが変わる時に受信することができる。
【１２５５】
本発明の一実施例は、サーチ（ｓｅａｒｃｈｉｎｇ）メッセージをマルチキャストする段階をさらに含むことができる。この段階は、ディスカバリメッセージを受信する前に行うことができる。サーチメッセージは、第２スクリーン支援サービスを提供するデバイスを探すためのものであってもよい。実施例によって、サーチメッセージはユニキャストされてもよい。この段階によって、第２デバイスが第１デバイスを探すことができる。
【１２５６】
本発明の他の実施例は、トリガーサービスが、フィルタリングされていないストリームオプションでトリガーを伝達することができる。フィルタリングされていないストリームオプションは、前述した通り、全てのタイプのトリガーを第２スクリーンアプリケーションに伝達することができる。
【１２５７】
本発明の更に他の実施例は、フィルタリングされていないストリームオプションにおいて、全てのトリガーを第１デバイスが受けるとすぐに第２スクリーンアプリケーションに伝達することができる。
【１２５８】
本発明の更に他の実施例は、第１デバイスから増加した活性化トリガーを受ける段階をさらに含むことができる。増加した活性化トリガーは、第１デバイスが活性化トリガー内の情報とＴＰＴ内の情報を抽出し結合して生成することができる。これは、前述の増加したトリガー、増加した活性化トリガー、拡張されたトリガーを生成する過程と同一の過程であってもよい。増加した活性化トリガーの生成過程及び生成後のフォーマットは、前述した通りである。
【１２５９】
本発明の更に他の実施例は、トリガーサービスがフィルタリングされたストリームオプションを提供することができる。前述した通り、フィルタリングされたストリームオプションは、増加した活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーを伝達することができる。
【１２６０】
本発明の更に他の実施例では、増加した活性化トリガーがアプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含む。ＵＲＬエレメントは、アプリケーションの一部であるファイルを識別し、アプリケーションエレメントは、活性化トリガーによって識別される。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、アプリケーションＵＲＬ情報は、前述の増加した活性化トリガーの＠ａｐｐＵＲＬであってもよい。ここで、ＵＲＬエレメントは、ＴＰＴのＴＤＯエレメント内のＵＲＬエレメントであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のＵＲＬ ｅｌｅｍｅｎｔエレメント値を取ったものであり、アプリケーションＵＲＬ情報とＵＲＬエレメントは同一の値を有することができる。
【１２６１】
本発明の更に他の実施例では、増加した活性化トリガーは、アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、活性化トリガーによって識別されたイベントエレメントは、アプリケーションのためのイベントを示し、イベント情報は、活性化トリガーによって識別されたイベントエレメントのアクション属性と同じ値を有するアクション情報を含み、アクション属性は、イベントが活性化される時に適用されるアクションのタイプを示す。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、イベント情報は、前述の増加した活性化トリガーのイベントエレメントであってもよい。ここで、イベントエレメントは、ＴＰＴのＴＤＯエレメント内のイベントエレメントであってもよい。ここで、アクション情報は、前述の増加した活性化トリガーの＠ａｃｔｉｏｎであってもよい。ここで、アクション属性は、ＴＰＴのイベントエレメント内の＠ａｃｔｉｏｎであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のイベントエレメント値と＠ａｃｔｉｏｎ値を取ったものであり、アクション情報とアクション属性は同一の値を有することができる。
【１２６２】
本発明の更に他の実施例は、増加した活性化トリガーが、増加した活性化トリガーの活性化時間に伝達され、相互作用トリガーは、可能な限り早く伝達され、チャネル変更トリガーは、チャネルが変更される時に伝達される。増加した活性化トリガーは、前述した通り、活性化時間又はそれよりもやや前に伝達することができ、相互作用トリガーは、第１デバイスが受信するとすぐに第２スクリーンアプリケーションに伝達し、チャネル変更トリガーは、チャネルが変更された場合に伝達することができる。
【１２６３】
図１０１は、第１デバイスとしてインタラクティブサービスを処理する装置の一実施例である。
【１２６４】
第１デバイスとしてインタラクティブサービスを処理する装置の一実施例は、第１モジュール１０１０１０及び／又は第２モジュール１０１０２０を含むことができる。
【１２６５】
ここで、第１デバイスは、前述したプライマリデバイス、ＴＶ受信機であってもよい。
【１２６６】
第１モジュール１０１０１０は、放送ストリーム又はインターネットサーバーからトリガーを受信するように構成することができる。ここで、第１モジュール１０１０１０は、第１デバイス内のトリガー受信モジュールであり、放送ストリームから受ける場合には前述のチューナー、インターネットサーバーから受ける場合には前述のネットワークインターフェースであってもよい。放送ストリームを通じて受ける場合には、前述した通り、ＤＴＶＣＣを通じて受けるものであり、インターネットサーバーを通じて受ける場合には、前述した通りｉＴＶメッセージの形態又はＡＣＲプロセスを通じて受けるものであってもよい。このトリガーは、その後、前述したトリガーサービスによって第２スクリーンアプリケーションに伝達されうる。前述した通り、トリガーサービスは、第２スクリーン支援サービスの一つであってもよい。前述した通り、トリガーは、シグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントに対するアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することである。受信したトリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーの一つであってもよい。相互作用トリガーは、ＴＤＯ相互作用モデル以外の相互作用モデルのためのトリガーであってもよい。例えば、直接実行モデルにおけるコンテンツｉｄ用語を有するトリガーであってもよい。チャネル変更トリガーは、前述した特殊チャネル変更トリガーであり、チャネルが変わる時に受信することができる。
【１２６７】
第２モジュール１０１０２０は、ディスカバリメッセージを送り、サービス記述の要求を受け、それに対する応答を送ることができる。また、第２デバイスにトリガーを送ることができる。第２モジュール１０１０２０は、前述したＵＰｎＰフレームワークモジュールであってもよい。
【１２６８】
第２モジュール１０１０２０は、ディスカバリメッセージを第２デバイスで実行される第２スクリーンアプリケーションに送信するように構成することができる。ディスカバリメッセージは、第１デバイスが提供できる第２スクリーン支援サービスを知らせる役割を担うことができる。ここで、ディスカバリメッセージは、一つの第２スクリーンデバイスではなく複数個の第２スクリーンデバイスにマルチキャストする方式であってもよい。ここで、第２スクリーン支援サービスは、前述した第２スクリーンサービスであってもよい。この動作は、前述したデバイスディスカバリのためのものであってもよい。
【１２６９】
第２モジュール１０１０２０は、第２スクリーンアプリケーションから第２スクリーン支援サービスの記述に対する要求を受信するように構成することができる。第１デバイスが提供できる第２スクリーン支援サービスに対する記述に対する要求を受信することができる。第２スクリーンデバイスで実行中の第２スクリーンアプリケーションは、第１デバイスが提供できる第２スクリーン支援サービスに対する記述を第１デバイスに要求することができる。この要求を受けることができる。この動作は、前述したデバイスディスカバリのためのものであってもよい。
【１２７０】
第２モジュール１０１０２０は、記述を有する応答を第２スクリーンアプリケーションに送信するように構成することができる。受信した要求に対する応答で記述を第２スクリーンアプリケーションに送信する動作であってもよい。この応答には、記述に加えて、他の情報が含まれてもよい。この動作は、前述したデバイスディスカバリのためのものであってもよい。
【１２７１】
第２モジュール１０１０２０は、トリガーサービスを用いてトリガーを第２デバイスに伝達するように構成することができる。トリガーサービスは、第２スクリーン支援サービスの一つであってもよい。
【１２７２】
本発明の一実施例では、第２モジュール１０１０２０がサーチメッセージを受信することができる。この動作は、ディスカバリメッセージを送る前に行うことができる。サーチメッセージは、第２スクリーン支援サービスを提供するデバイスを探すためのものであってもよい。サーチメッセージは、ユニキャスティング又はマルチキャストする方式で伝送されうる。これによって、第２スクリーンデバイスが第１デバイスを探すことができる。
【１２７３】
本発明の他の実施例では、トリガーサービスが、フィルタリングされていないストリームオプションでトリガーを伝達することができる。フィルタリングされていないストリームオプションは、前述した通り、全てのタイプのトリガーを第２スクリーンデバイスに伝達することができる。
【１２７４】
本発明の更に他の実施例は、第２モジュール１０１０２０は、フィルタリングされていないストリームオプションにおいて、全てのトリガーを第１モジュール１０１０１０が受けるとすぐに第２スクリーンアプリケーションに伝達することができる。
【１２７５】
本発明の更に他の実施例では、第２モジュール１０１０２０が、増加した活性化トリガーを生成し、これを第２スクリーンアプリケーションに伝達することができる。第２モジュール１０１０２０は、受信したトリガーのうちの活性化トリガー内の情報とＴＰＴ内の情報を抽出し、結合させることができる。これは、前述の増加したトリガー、増加した活性化トリガー、拡張されたトリガーを生成する動作と同一の動作であってもよい。増加した活性化トリガーの生成過程及び生成後のフォーマットは、前述した通りである。
【１２７６】
本発明の更に他の実施例では、トリガーサービスが、フィルタリングされたストリームオプションを提供することができる。前述した通り、フィルタリングされたストリームオプションは、増加した活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーを伝達することができる。
【１２７７】
本発明の更に他の実施例では、増加した活性化トリガーが、アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含む。ＵＲＬエレメントは、アプリケーションの一部であるファイルを識別し、アプリケーションエレメントは、活性化トリガーによって識別される。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、アプリケーションＵＲＬ情報は、前述の増加した活性化トリガーの＠ａｐｐＵＲＬであってもよい。ここで、ＵＲＬエレメントは、ＴＰＴのＴＤＯエレメント内のＵＲＬエレメントであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のＵＲＬエレメント値を取ったものであり、アプリケーションＵＲＬ情報とＵＲＬエレメントは同一の値を有することができる。
【１２７８】
本発明の更に他の実施例では、増加した活性化トリガーは、アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、活性化トリガーによって識別されたイベントエレメントは、アプリケーションに対するイベントを示し、イベント情報は、活性化トリガーによって識別されたイベントエレメントのアクション属性と同じ値を有するアクション情報を含み、アクション属性は、イベントが活性化される時に適用されるアクションのタイプを示す。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、イベント情報は、前述の増加した活性化トリガーのイベントエレメントであってもよい。ここでイベントエレメントは、ＴＰＴのＴＤＯエレメント内のイベントエレメントであってもよい。ここで、アクション情報は、前述の増加した活性化トリガーの＠ａｃｔｉｏｎであってもよい。ここで、アクション属性は、ＴＰＴのイベントエレメント内の＠ａｃｔｉｏｎであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のイベントエレメント値と＠ａｃｔｉｏｎ値を取ったものであり、、アクション情報とアクション属性は同一の値を有することができる。
【１２７９】
本発明の更に他の実施例では、第２モジュール１０１０２０は、増加した活性化トリガーの活性化時間で増加した活性化トリガーを伝達し、第２モジュール１０１０２０は、第１モジュールによって相互作用トリガーが受信される時に相互作用トリガーを伝達し、第２モジュール１０１０２０は、チャネルが変更される時にチャネル変更トリガーを伝達する。増加した活性化トリガーは、前述した通り、活性化時間又はそれよりもやや前に伝達することができ、相互作用トリガーは、第１モジュール１０１０１０が受信するとすぐに第２スクリーンアプリケーションに伝達し、チャネル変更トリガーは、チャネルが変更された場合に伝達することができる。
【１２８０】
図１０２は、第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置の一実施例である。
【１２８１】
ここで、第２デバイスは、前述した第２スクリーンデバイスであってもよい。
【１２８２】
第２デバイスで実行される第２スクリーンアプリケーションとしてインタラクティブサービスを処理する装置の一実施例は、第１モジュール１０２０１０及び／又は第２モジュール１０２０２０を含むことができる。
【１２８３】
第１モジュール１０２０１０は、ディスカバリメッセージを受け、サービス記述を要求し、それに対する応答を受信することができる。ここで、第１モジュール１０２０１０は、前述した第２スクリーンデバイス内のＵＰｎＰフレームワークモジュールであってもよい。
【１２８４】
第１モジュール１０２０１０は、第１デバイスからディスカバリメッセージを受信するように構成することができる。ディスカバリメッセージは、第１デバイスが提供できる第２スクリーン支援サービスを知らせる役割を担うことができる。第１デバイスは、ディスカバリメッセージを第２デバイスにのみ送ってもよく、ホームネットワーク内の全ての機器にマルチキャストしてもよい。前述したデバイスディスカバリのための動作であってもよい。
【１２８５】
第１モジュール１０２０１０は、第２スクリーン支援サービスの記述に対する要求を第１デバイスに送信するように構成することができる。第１モジュール１０２０１０が第１デバイスに、第１デバイスが提供する第２スクリーン支援サービスの記述を要求する動作であってもよい。前述したデバイスディスカバリのための動作であってもよい。
【１２８６】
第１モジュール１０２０１０は、第１デバイスから記述を有する応答を受信するように構成することができる。第１モジュール１０２０１０が送った要求に対する応答として、サービスに対する記述を受信する動作であってもよい。第１デバイスは、第２スクリーンアプリケーションに自身のサービスの記述を送信することができる。これを受信する動作であってもよい。前述したデバイスディスカバリのための動作であってもよい。
【１２８７】
第２モジュール１０２０２０は、トリガーサービスに接近し、トリガーを受信することができる。第２モジュール１０２０２０は、前述したネットワークプロトコルサブシステムであってもよい。
【１２８８】
第２モジュール１０２０２０は、記述内に含まれる情報を用いてトリガーをアクセスするように構成することができる。第２モジュール１０２０２０が第２スクリーン支援サービスの一つであるトリガーサービスに接近する動作であってもよい。第１デバイスが放送ストリーム又はインターネットサーバーから受信したトリガーを受信するためであってもよい。トリガーサービスへの接近は、第１デバイスから受信した記述に基づいて行われてもよい。受信した記述のうち、トリガーサービスに対する記述を用いることができる。
【１２８９】
第２モジュール１０２０２０は、トリガーサービスを用いて第１デバイスからトリガーを受信するように構成することができる。第２モジュール１０２０２０がトリガーサービスを用いて第１デバイスからトリガーを伝達を受ける動作であってもよい。ここで、トリガーサービスは、第２スクリーン支援サービスの一つであってもよい。トリガーはシグナリングエレメントであり、その機能は、シグナリングを確認し、アプリケーションパラメータテーブルによって記述されたセグメントに対するアプリケーションをターゲットとするインタラクティブイベントの再生タイミングを確立することである。ここで、トリガーは、時間ベーストリガー、活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーのうちの一つであってもよい。相互作用トリガーは、ＴＤＯ相互作用モデル以外の相互作用モデルのためのトリガーであってもよい。例えば、直接実行モデルにおけるコンテンツｉｄ用語を有するトリガーであってもよい。チャネル変更トリガーは、前述した特殊チャネル変更トリガーであり、チャネルが変わる時に受信することができる。
【１２９０】
本発明の一実施例では、第１モジュール１０２０１０がサーチメッセージをマルチキャストする動作をさらに含むことができる。これは、ディスカバリメッセージを受信する前に行うことができる。サーチメッセージは、第２スクリーン支援サービスを提供するデバイスを探すためのものであってもよい。実施例によって、サーチメッセージはユニキャストされてもよい。この段階によって、第２デバイスが第１デバイスを探すことができる。
【１２９１】
本発明の他の実施例では、トリガーサービスが、フィルタリングされていないストリームオプションでトリガーを伝達することができる。フィルタリングされていないストリームオプションは、前述した通り、全てのタイプのトリガーを第２スクリーンアプリケーションに伝達することができる。
【１２９２】
本発明の更に他の実施例では、フィルタリングされていないストリームオプションにおいて、全てのトリガーを第１デバイスが受けるとすぐに第２スクリーンアプリケーションに伝達することができる。
【１２９３】
本発明の更に他の実施例では、第１モジュール１０２０１０が第１デバイスから増加した活性化トリガーを受ける動作をさらに含むことができる。増加した活性化トリガーは、第１デバイスが活性化トリガー内の情報とＴＰＴ内の情報を抽出し、結合して生成することができる。これは、前述の増加したトリガー、増加した活性化トリガー、拡張されたトリガーを生成する過程と同一の過程であってもよい。増加した活性化トリガーの生成過程及び生成後のフォーマットは、前述した通りである。
【１２９４】
本発明の更に他の実施例では、トリガーサービスが、フィルタリングされたストリームオプションを提供することができる。前述した通り、フィルタリングされたストリームオプションは、増加した活性化トリガー、相互作用トリガー及び／又はチャネル変更トリガーを伝達することができる。
【１２９５】
本発明の更に他の実施例では、増加した活性化トリガーが、アプリケーションパラメータテーブルにおけるアプリケーションエレメントのＵＲＬエレメントと同じ値を有するアプリケーションＵＲＬ情報を含む。ＵＲＬエレメントはアプリケーションの一部であるファイルを識別し、アプリケーションエレメントは活性化トリガーによって識別される。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、アプリケーションＵＲＬ情報は、前述の増加した活性化トリガーの＠ａｐｐＵＲＬであってもよい。ここで、ＵＲＬエレメントは、ＴＰＴのＴＤＯエレメント内のＵＲＬエレメントであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のＵＲＬエレメント値を取ったものであり、アプリケーションＵＲＬ情報とＵＲＬエレメントは同一の値を有することができる。
【１２９６】
本発明の更に他の実施例では、増加した活性化トリガーは、アプリケーションパラメータテーブルにおけるイベントエレメントを示すイベント情報をさらに含み、活性化トリガーによって識別されたイベントエレメントは、アプリケーションのためのイベントを示し、イベント情報は、活性化トリガーによって識別されたイベントエレメントのアクション属性と同じ値を有するアクション情報を含み、アクション属性は、イベントが活性化される時に適用されるアクションのタイプを示す。アプリケーションパラメータテーブルは、前述したＴＰＴであってもよい。アプリケーションは、ＴＤＯであってもよい。ここで、イベント情報は、前述の増加した活性化トリガーのイベントエレメントであってもよい。ここで、イベントエレメントは、ＴＰＴのＴＤＯエレメント内のイベントエレメントであってもよい。ここで、アクション情報は、前述の増加した活性化トリガーの＠ａｃｔｉｏｎであってもよい。ここで、アクション属性は、ＴＰＴのイベントエレメント内の＠ａｃｔｉｏｎであってもよい。増加した活性化トリガーは、生成過程で活性化トリガーと関連したＴＰＴのＴＤＯエレメント内のイベントエレメント値と＠ａｃｔｉｏｎ値を取ったものであり、、アクション情報とアクション属性は同一の値を有することができる。
【１２９７】
本発明の更に他の実施例では、増加した活性化トリガーは、増加した活性化トリガーの活性化時間に伝達され、相互作用トリガーは、可能な限り早く伝達され、チャネル変更トリガーは、チャネルが変更される時に伝達される。増加した活性化トリガーは、前述した通り、活性化時間又はそれよりもやや前に伝達することができ、相互作用トリガーは、第１デバイスが受信するとすぐに第２スクリーンアプリケーションに伝達し、チャネル変更トリガーは、チャネルが変更された場合に伝達することができる。
【１２９８】
本発明は、放送サービスを受信しながら第２スクリーンデバイスと連動するための方法に関する。受信機はＵＰｎＰフレームワークを内蔵しており、第２スクリーンデバイスには、ＵＰｎＰフレームワークと互換されながら第２スクリーンサービスを提供できる追加モジュールを内蔵させると、簡単に放送社が第２スクリーンサービスを具現できるという長所がある。
【１２９９】
ＵＰｎＰフレームワークは、家庭内のホームネットワークにネットワークされる家電機器が接続しており、それぞれの家電機器別にその機能をサービス化して提供できるが、本発明は、既存のＵＰｎＰ ＲｅｍｏｔｅＵＩクライアントサービスとＵＰｎＰ ＲｅｍｏｔｅＵＩサーバークライアントに対する拡張を提示した。したがって、既存のＵＰｎＰ機器と互換されながら、さらに第２スクリーンサービスを受信できるという長所がある。
〔実施例〕
【１３００】
発明の実施例は、前述した通り、発明を実施するための形態で詳述された。
【産業上の利用可能性】
【１３０１】
本発明は、放送サービス提供に関連した一連の産業分野で利用可能である。
【１３０２】
本発明の思想及び範囲から逸脱することなく、本発明の様々な変形及び変更が可能であるということが当業者にとっては明らかである。したがって、本発明は、添付の特許請求の範囲及び同等物の範囲内で提供される本発明の変形及び変更も含む。
【図１】
2016503599.tif 000003
【図４】
2016503599.tif 000004
【図９】
2016503599.tif 000005
【図１０】
2016503599.tif 000006
【図１１】
2016503599.tif 000007
【図１２】
2016503599.tif 000008
【図１３】
2016503599.tif 000009
【図１６】
2016503599.tif 000010
【図１７】
2016503599.tif 000011
【図２０】
2016503599.tif 000012
【図６１】
2016503599.tif 000013
【図６２】
2016503599.tif 000014
【図６４】
2016503599.tif 000015
【図２】
2016503599.tif 000016
【図３】
2016503599.tif 000017
【図５】
2016503599.tif 000018
【図６】
2016503599.tif 000019
【図７】
2016503599.tif 000020
【図８】
2016503599.tif 000021
【図１４】
2016503599.tif 000022
【図１５】
2016503599.tif 000023
【図１８】
2016503599.tif 000024
【図１９】
2016503599.tif 000025
【図２１】
2016503599.tif 000026
【図２２】
2016503599.tif 000027
【図２３】
2016503599.tif 000028
【図２４】
2016503599.tif 000029
【図２５】
2016503599.tif 000030
【図２６】
2016503599.tif 000031
【図２７】
2016503599.tif 000032
【図２８】
2016503599.tif 000033
【図２９】
2016503599.tif 000034
【図３０】
2016503599.tif 000035
【図３１】
2016503599.tif 000036
【図３２】
2016503599.tif 000037
【図３３】
2016503599.tif 000038
【図３４】
2016503599.tif 000039
【図３５】
2016503599.tif 000040
【図３６】
2016503599.tif 000041
【図３７】
2016503599.tif 000042
【図３８】
2016503599.tif 000043
【図３９】
2016503599.tif 000044
【図４０】
2016503599.tif 000045
【図４１】
2016503599.tif 000046
【図４２】
2016503599.tif 000047
【図４３】
2016503599.tif 000048
【図４４】
2016503599.tif 000049
【図４５】
2016503599.tif 000050
【図４６】
2016503599.tif 000051
【図４７】
2016503599.tif 000052
【図４８】
2016503599.tif 000053
【図４９】
2016503599.tif 000054
【図５０】
2016503599.tif 000055
【図５１】
2016503599.tif 000056
【図５２】
2016503599.tif 000057
【図５３】
2016503599.tif 000058
【図５４】
2016503599.tif 000059
【図５５】
2016503599.tif 000060
【図５６】
2016503599.tif 000061
【図５７】
2016503599.tif 000062
【図５８】
2016503599.tif 000063
【図５９】
2016503599.tif 000064
【図６０】
2016503599.tif 000065
【図６３】
2016503599.tif 000066
【図６５】
2016503599.tif 000067
【図６６】
2016503599.tif 000068
【図６７】
2016503599.tif 000069
【図６８】
2016503599.tif 000070
【図６９】
2016503599.tif 000071
【図７０】
2016503599.tif 000072
【図７１】
2016503599.tif 000073
【図７２】
2016503599.tif 000074
【図７３】
2016503599.tif 000075
【図７４】
2016503599.tif 000076
【図７５】
2016503599.tif 000077
【図７６】
2016503599.tif 000078
【図７７】
2016503599.tif 000079
【図７８】
2016503599.tif 000080
【図７９】
2016503599.tif 000081
【図８０】
2016503599.tif 000082
【図８１】
2016503599.tif 000083
【図８２】
2016503599.tif 000084
【図８３】
2016503599.tif 000085
【図８４】
2016503599.tif 000086
【図８５】
2016503599.tif 000087
【図８６】
2016503599.tif 000088
【図８７】
2016503599.tif 000089
【図８８】
2016503599.tif 000090
【図８９】
2016503599.tif 000091
【図９０】
2016503599.tif 000092
【図９１】
2016503599.tif 000093
【図９２】
2016503599.tif 000094
【図９３】
2016503599.tif 000095
【図９４】
2016503599.tif 000096
【図９５】
2016503599.tif 000097
【図９６】
2016503599.tif 000098
【図９７】
2016503599.tif 000099
【図９８】
2016503599.tif 000100
【図９９】
2016503599.tif 000101
【図１００】
2016503599.tif 000102
【図１０１】
2016503599.tif 000103
【図１０２】
2016503599.tif 000104
【国際調査報告】
2016503599.tif 000105
2016503599.tif 000106