(57)【要約】【課題】信号送信方法、信号送信装置及び信号送受信システムが開示される。【解決手段】信号送信方法は、マルチキャスト方式を用いてコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）を検索（ｄｉｓｃｏｖｅｒｙ）するステップと、検索されたコンパニオン装置から装置タイプ情報を受信して格納するステップと、アプリケーションＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を受信し、装置タイプ情報に対応させて格納するステップと、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、装置タイプ情報に対応するアプリケーションＵＲＩを選択されたコンパニオン装置に伝送するステップとを含む。【選択図】図２
2016513438.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャスト方式を用いてコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）を検索（ｄｉｓｃｏｖｅｒｙ）するステップと、
検索されたコンパニオン装置から装置タイプ情報を受信して格納するステップと、
アプリケーションＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を受信し、前記装置タイプ情報に対応させて格納するステップと、
ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送するステップとを含む、信号送信方法。
【請求項２】
前記格納するステップは、
前記アプリケーションＵＲＩを含むＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信し、前記受信されたＡＩＴをパージング（ｐａｒｓｉｎｇ）して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを検出して格納する、請求項１に記載の信号送信方法。
【請求項３】
前記格納するステップは、
据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、前記受信されたＡＩＴをパージングして前記据え置きＵＲＩを検出し、前記据え置きＵＲＩに対応するサーバーに接続し、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを受信して格納する、請求項１に記載の信号送信方法。
【請求項４】
前記格納するステップは、
ＨｂｂＴＶアプリケーションを介してサーバーと通信を行って、コンパニオン装置アプリケーション（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ）を利用可能であるか否かを確認し、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応する前記アプリケーションＵＲＩをサーバーから受信して格納する、請求項１に記載の信号送信方法。
【請求項５】
前記アプリケーションＵＲＩは、それぞれのコンパニオン装置毎に互いに異なるＵＲＩ値が割り当てられる特定ＵＲＩ、または同一のＵＲＩ値が割り当てられる一般ＵＲＩである、請求項１に記載の信号送信方法。
【請求項６】
マルチキャスト方式を用いてコンパニオン装置を検索（ｄｉｓｃｏｖｅｒｙ）し、検索されたコンパニオン装置から装置タイプ情報を受信するＵＰｎＰ部と、
アプリケーションＵＲＩを受信する通信部と、
前記装置タイプ情報と前記アプリケーションＵＲＩを対応させて格納し、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認する装置管理部とを含み、
前記ＵＰｎＰ部は、
前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送する、信号送信装置。
【請求項７】
前記通信部は放送受信モジュールを含み、
前記放送受信モジュールは、
前記アプリケーションＵＲＩを含むＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信し、
前記装置管理部は、
前記受信されたＡＩＴをパージング（ｐａｒｓｉｎｇ）して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを検出して格納する、請求項６に記載の信号送信装置。
【請求項８】
前記通信部は放送受信モジュール及びブラウザモジュールを含み、
前記放送受信モジュールは、
据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、
前記装置管理部は、
前記受信されたＡＩＴをパージングして前記据え置きＵＲＩを検出し、
前記ブラウザモジュールは、
前記ＨｂｂＴＶアプリケーションを介して据え置きＵＲＩに対応するサーバーに接続して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを受信する、請求項６に記載の信号送信装置。
【請求項９】
前記通信部はブラウザモジュールを含み、
前記ブラウザモジュールは、
ＨｂｂＴＶアプリケーションを介してサーバーと通信を行って、前記コンパニオン装置アプリケーション（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ）を利用可能であるか否かを確認し、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応する前記アプリケーションＵＲＩをサーバーから受信して格納する、請求項６に記載の信号送信装置。
【請求項１０】
前記アプリケーションＵＲＩは、それぞれのコンパニオン装置毎に互いに異なるＵＲＩ値が割り当てられる特定ＵＲＩ、または同一のＵＲＩ値が割り当てられる一般ＵＲＩである、請求項６に記載の信号送信装置。
【請求項１１】
マルチキャスト方式を用いてコンパニオン装置を検索（ｄｉｓｃｏｖｅｒｙ）し、検索されたコンパニオン装置に、装置タイプ情報を要求する制御信号を伝送する信号送信装置と、
前記信号送信装置に装置タイプ情報を伝送するコンパニオン装置とを含み、
前記信号送信装置は、
アプリケーションＵＲＩを受信して前記装置タイプ情報と前記アプリケーションＵＲＩとを対応させて格納し、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送し、
前記コンパニオン装置は、
前記信号送信装置から伝送された前記アプリケーションＵＲＩを受信し、前記アプリケーションＵＲＩに対応するサーバーからＵＲＩページを受信してディスプレイする、信号送受信システム。
【請求項１２】
前記信号送信装置は、
前記アプリケーションＵＲＩを含むＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信し、パージング（ｐａｒｓｉｎｇ）して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを検出して格納する、請求項１１に記載の信号送受信システム。
【請求項１３】
前記信号送信装置は、
据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、パージングして、前記据え置きＵＲＩを検出し、ＨｂｂＴＶアプリケーションを介して前記据え置きＵＲＩに対応するサーバーに接続して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを受信する、請求項１１に記載の信号送受信システム。
【請求項１４】
前記信号送信装置は、
ＨｂｂＴＶアプリケーションを介してサーバーと通信を行って、コンパニオン装置アプリケーション（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ）を利用可能であるか否か（ａｖａｉｌａｂｌｅ）を確認し、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応する前記アプリケーションＵＲＩをサーバーから受信して格納する、請求項１１に記載の信号送受信システム。
【請求項１５】
前記アプリケーションＵＲＩは、それぞれのコンパニオン装置毎に互いに異なるＵＲＩ値が割り当てられる特定ＵＲＩ、または同一のＵＲＩ値が割り当てられる一般ＵＲＩである、請求項１１に記載の信号送受信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、信号送信装置、信号送信方法及び信号送受信システムに関する。
【背景技術】
【０００２】
放送及び通信技術の発展に伴い、様々な放送装置及び放送サービスに対する研究が行われている。現在は、インターネット網に接続されてインターネット網を介して新たなコンテンツの提供を受けることができる放送装置及び放送サービスが具現されている。このような放送装置は、放送局から提供される放送プログラムに適した付加サービスをインターネット網を介して受信して画面に出力する。
【０００３】
しかし、放送コンテンツの出力中に付加サービスコンテンツが画面に出力される場合、付加サービスコンテンツは放送コンテンツの出力画面を妨げる。一般に、複数の人が一つの放送装置を通じて放送コンテンツを視聴することができる。しかし、そのうちの一部の人のみが付加サービスに対して関心を有し得る。
【０００４】
したがって、付加サービスが周辺装置を通じて出力されることによって、放送コンテンツは妨げずに放送装置を通じて出力し得る技術が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、放送コンテンツを視聴しながら付加サービスを周辺機器に出力する信号送信装置、信号送信方法及び信号送受信システムを提供するものである。
【０００６】
本発明の他の目的は、付加サービスの提供を受けることができる周辺機器を確認し、付加サービスの提供を受けることができることを示す情報を周辺機器に伝送する信号送信装置、信号送信方法及び信号送受信システムを提供するものである。
【０００７】
本発明の更に他の目的は、周辺機器で提供される付加サービスを出力する信号送信装置、信号送信方法及び信号送受信システムを提供するものである。
【課題を解決するための手段】
【０００８】
本発明の一実施例によれば、信号送信方法は、マルチキャスト方式を用いてコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）を検索（ｄｉｓｃｏｖｅｒｙ）するステップと、検索されたコンパニオン装置から装置タイプ情報を受信して格納するステップと、アプリケーションＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を受信し、前記装置タイプ情報に対応させて格納するステップと、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送するステップとを含む。
【０００９】
そして、前記格納するステップは、前記アプリケーションＵＲＩを含むＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信し、前記受信されたＡＩＴをパージング（ｐａｒｓｉｎｇ）して、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを検出して格納することができる。
【００１０】
また、前記格納するステップは、据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、前記受信されたＡＩＴをパージングして前記据え置きＵＲＩを検出し、前記据え置きＵＲＩに対応するサーバーに接続し、前記装置タイプ情報に対応する前記アプリケーションＵＲＩを受信して格納することができる。
【００１１】
そして、前記格納するステップは、ＨｂｂＴＶアプリケーションがサーバーと通信を行って、前記コンパニオン装置アプリケーション（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ）を利用可能であるか否か（ａｖａｉｌａｂｌｅ）を確認し、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応する前記アプリケーションＵＲＩをサーバーから受信して格納することができる。
【００１２】
一方、前記アプリケーションＵＲＩは、それぞれのコンパニオン装置毎に互いに異なるＵＲＩ値が割り当てられる特定（ｓｐｅｃｉｆｉｃ）ＵＲＩ、または同一のＵＲＩ値が割り当てられる一般（ｇｅｎｅｒｉｃ）ＵＲＩであってもよい。
【００１３】
本発明の一実施例によれば、信号送信装置は、マルチキャスト方式を用いてコンパニオン装置を検索（ｄｉｓｃｏｖｅｒｙ）し、検索されたコンパニオン装置から装置タイプ情報を受信するＵＰｎＰ部と、アプリケーションＵＲＩを受信する通信部と、前記装置タイプ情報と前記アプリケーションＵＲＩとを対応させて格納し、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認する装置管理部と、を含み、前記ＵＰｎＰ部は、前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送する。
【００１４】
本発明の一実施例によれば、信号送受信システムは、マルチキャスト方式を用いてコンパニオン装置を検索（ｄｉｓｃｏｖｅｒｙ）し、検索されたコンパニオン装置に、装置タイプ情報を要請する制御信号を伝送する信号送信装置、及び前記信号送信装置に装置タイプ情報を伝送するコンパニオン装置を含み、前記信号送信装置は、アプリケーションＵＲＩを受信して前記装置タイプ情報と前記アプリケーションＵＲＩとを対応させて格納し、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、前記装置タイプ情報に対応するアプリケーションＵＲＩを前記選択されたコンパニオン装置に伝送し、前記コンパニオン装置は、前記信号送信装置から伝送された前記アプリケーションＵＲＩを受信し、前記アプリケーションＵＲＩに対応するサーバーからＵＲＩページを受信してディスプレイする。
【発明の効果】
【００１５】
本発明の実施例によれば、放送コンテンツと関連する付加サービスを周辺機器で受信して出力することができる。
【００１６】
そして、付加サービスの提供を受けることができる周辺機器を確認し、付加サービスの提供を受けることができることを示す情報を周辺機器に伝送することができる。
【００１７】
また、本発明の実施例によれば、周辺機器で提供される付加サービスを信号送信装置で出力することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施例に係る信号送信方法のフローチャートである。
【図２】本発明の一実施例に係る信号送受信システムを説明する図である。
【図３】本発明の様々な実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明する図である。
【図４】本発明の様々な実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明する図である。
【図５】本発明の様々な実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明する図である。
【図６】本発明の様々な実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明する図である。
【図７】本発明の様々な実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明する図である。
【図８】本発明の第１実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図９】本発明の第２実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図１０】本発明の第３実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図１１】本発明の第４実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図１２】本発明の第５実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図１３】本発明の第６実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【図１４】本発明の一実施例に係るＵＲＩディスクリプタを説明する図である。
【図１５】本発明の他の実施例に係るＵＲＩディスクリプタを説明する図である。
【図１６】装置タイプ情報をシグナリングする実施例を説明する図である。
【図１７】コンパニオン装置情報をシグナリングする実施例を説明する図である。
【図１８】ＵＲＩタイプ情報をシグナリングする実施例を説明する図である。
【図１９】コンパニオンアプリケーション（ｃｏｍｐａｎｉｏｎ  ａｐｐｌｉｃａｔｉｏｎ）を実行する方式に関する情報をシグナリングする実施例を説明する図である。
【図２０】本発明の一実施例に係る据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）のＧＥＴ要請ヘッダー情報を説明する図である。
【図２１】本発明の一実施例に係るＧＥＴ応答情報を説明する図である。
【図２２】本発明の一実施例に係るコンパニオンアプリケーションＵＲＩをエンコーディングするためのＪＳＯＮ ｓｃｈｅｍａを説明する図である。
【図２３】コンパニオン装置に応じたＵＲＩをエンコーディングする実施例を説明する図である。
【図２４】本発明の一実施例に係るコンパニオン装置において付加サービスを実行するための信号送信装置のＵＩを説明する図である。
【図２５】本発明の様々な実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明する図である。
【図２６】本発明の様々な実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明する図である。
【図２７】本発明の第１実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明するタイミング図である。
【図２８】本発明の第２実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明するタイミング図である。
【図２９】本発明の一実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行するための信号送信装置のＵＩを説明する図である。
【図３０】本発明の一実施例に係る信号送信装置のブロック図である。
【図３１】本発明の一実施例に係るコンパニオン装置のブロック図である。
【発明を実施するための形態】
【００１９】
以下、上記目的を具体的に実現できる本発明の好適な実施例を添付の図面を参照して説明する。このとき、図面に図示され、またこれによって説明される本発明の構成と作用は、少なくとも一つの実施例として説明されるものであり、これによって本発明の技術的思想とその核心構成及び作用が制限されるものではない。
【００２０】
本発明で使用される用語は、本発明における機能を考慮した上、できるだけ現在広く使用されている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変わり得る。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分で詳細にその意味を記載する。したがって、本発明で使用される用語は、単純な用語の名称ではなく、その用語が持つ意味と本発明の全般にわたる内容に基づいて定義されなければならないということは明らかである。
【００２１】
図１は、本発明の一実施例に係る信号送信方法のフローチャートである。
【００２２】
図１を参照すると、信号送信装置は、マルチキャスト方式を用いてコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）（またはセカンド装置）を検索（ｄｉｓｃｏｖｅｒｙ）する（Ｓ１１０）。例えば、信号送信装置はＴＶなどであってもよい。そして、コンパニオン装置は、スマートフォン、スマートパッド、ラップトップコンピュータなどのように個人用携帯装置であってもよい。
【００２３】
信号送信装置は、検索されたコンパニオン装置から装置タイプ情報を受信して格納する（Ｓ１２０）。装置タイプ情報は、コンパニオン装置がどの種類の携帯装置であるかを確認できる情報であってもよい。信号送信装置は、装置タイプ情報を受信して装置テーブルに格納して管理することができる。
【００２４】
信号送信装置は、アプリケーションＵＲＩを受信し、装置タイプ情報に対応させて格納する（Ｓ１３０）。ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）は、インターネットにある資源を示すアドレスであって、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）及びＵＲＮ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｎａｍｅ）を含むことができる。アプリケーションＵＲＩは、コンパニオン装置が付加サービスを行うために必要な資源がある場所であり得る。
【００２５】
一実施例として、信号送信装置は、アプリケーションＵＲＩを含むＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信し、受信されたＡＩＴをパージング（ｐａｒｓｉｎｇ）して、装置タイプ情報に対応するアプリケーションＵＲＩを検出して格納することができる。
【００２６】
または、信号送信装置は、据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、受信されたＡＩＴをパージングして、前記据え置きＵＲＩを検出することができる。信号送信装置は、据え置きＵＲＩに対応するサーバーに接続し、装置タイプ情報に対応するアプリケーションＵＲＩを受信して格納することができる。
【００２７】
または、信号送信装置は、ＨｂｂＴＶアプリケーションを介してサーバーと通信を行って、コンパニオン装置アプリケーション（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ  ａｐｐｌｉｃａｔｉｏｎ）を利用可能であるか否か（ａｖａｉｌａｂｌｅ）を確認できる。そして、信号送信装置は、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応するアプリケーションＵＲＩをサーバーから受信して格納し得る。
【００２８】
信号送信装置は、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認し、装置タイプ情報に対応するアプリケーションＵＲＩを選択されたコンパニオン装置に伝送する（Ｓ１４０）。
【００２９】
図２は、本発明の一実施例に係る信号送受信システムを説明する図である。
【００３０】
信号送受信システムは、信号送信装置１００、コンパニオン装置（Ｃｏｍｐａｎｉｏｎ  Ｄｅｖｉｃｅ）２００、及び放送サーバー（Ｂｒｏａｄｃａｓｔ  Ｓｅｒｖｅｒ）３００を含むことができる。
【００３１】
信号送信装置１００は、放送受信部（Ｂｒｏａｄｃａｓｔ  Ｒｅｃｉｖｅｒ）１１０、装置管理部（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）１２０、ＵＰｎＰ部１３０及びブラウザ部（Ｂｒｏｗｓｅｒ）１４０を含むことができる。例えば、信号送信装置１００はＴＶであってもよい。
【００３２】
コンパニオン装置２００は、ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）２１０及びシステムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）２２０を含むことができる。ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）２１０は、ＵＰｎＰ ２１１及びウェブビュー（Ｗｅｂ  Ｖｉｅｗ）２１２を含むことができる。
【００３３】
信号送信装置１００は、現在の放送プログラムと関連するコンパニオン装置アプリケーション（Ｃｏｍｐａｎｉｏｎ  Ｄｅｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ）サービスがあるという内容を含んだＡＩＴを、放送受信部１１０を介して受信することができる。または、信号送信装置１００は、放送サーバーからＨｂｂＴＶアプリケーションを介してコンパニオン装置アプリケーションの存在を認識し得る。
【００３４】
すなわち、信号送信装置１００は、放送信号から現在プログラムと関連するコンパニオン装置アプリケーションが存在するか否かの情報を含むＡＩＴを受信しながら、このような過程を行うことができる。信号送信装置１００は、現在プログラムと関連するアプリケーションを利用できることをユーザに知らせることができる。コンパニオン装置アプリケーションを設置するためのＵＲＩを発見する過程は、ＡＩＴに含まれたＵＲＩを用いて直接、またはコンパニオン装置アプリケーションを利用できる遠隔放送サーバー３００を通じて行われてもよい。
【００３５】
放送受信部（Ｂｒｏａｄｃａｓｔ  Ｒｅｃｉｖｅｒ）１１０は、放送コンテンツを含む放送信号を受信することができる。
【００３６】
放送受信部１１０は、プラットフォームのＴＶミドルウェアを示すことができる。放送受信部１１０は、コンパニオン装置との接続のための放送ＡＩＴをフィルタリングすることができ、接続が発見されると、装置管理部１２０に知らせることができる。
【００３７】
装置管理部（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）１２０は、ＵＰｎＰ部１３０から利用可能な装置に関する情報を収集し、ジャバスクリプトＡＰＩを介してＨｂｂＴＶアプリケーションに収集された情報を知らせることができる。装置管理部（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）１２０は、ＡＩＴから提供されるコンパニオンアプリケーションリンクに関する情報を放送受信部１１０から収集し、ＤＯＭイベントによって利用可能性をＨｂｂＴＶに知らせることができる。
【００３８】
ＵＰｎＰ部１３０は、ＴＶプラットフォームのＵＰｎＰを具現し得る。ＵＰｎＰ部１３０は、コンパニオン装置２００が存在するか否かを検索し、信号送信装置１００とコンパニオン装置２００間のコンパニオンアプリケーションＵＲＩを伝達することができる。
【００３９】
ブラウザ部（Ｂｒｏｗｅｒ）１４０は、ＨｂｂＴＶアプリケーションを含むことができる。ブラウザ部（Ｂｒｏｗｅｒ）１４０は、ＨｂｂＴＶアプリケーションを用いて特定ＵＲＩの放送サーバー３００に接続することができる。ブラウザ部１４０は、放送サーバー３００から、装置タイプによるアプリケーションＵＲＩを受信することができる。または、ブラウザ部１４０は、コンパニオン装置アプリケーションを利用可能であるか否かを確認することができる。
【００４０】
ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）２１０は、コンパニオン装置２００上で駆動され、ＵＰｎＰ動作を提供することができる。そして、コンパニオンアプリケーションをローディングし、駆動し得るウェブビューを提供することができる。
【００４１】
システムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）２２０は、コンパニオン装置２００上で駆動され、コンパニオン装置２００で設定される標準ウェブブラウザであり得る。ネイティブアプリケーション部２１０によって選択的に提供され得るウェブビュー２１２とは異なり、システムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）２２０は、一般的なウェブ用途に適した一般のウェブブラウザであり得る。
【００４２】
ＵＰｎＰ２１１は、信号送信装置１００のＵＰｎＰ部１３０と接続されて通信を行うことができ、ウェブビュー（Ｗｅｂ  Ｖｉｅｗ）２１２は、接続されたＵＲＩのサーバーで提供する付加サービスを表示することができる。
【００４３】
コンパニオンアプリケーションのために獲得されるＵＲＩのタイプは、下記のように考慮し得る。
【００４４】
（１）ＡＩＴは、コンパニオン装置のそれぞれのクラス（例、スマートフォン、タブレットなど）のための特定ＵＲＩを含むことができる。
【００４５】
（２）ＡＩＴは、コンパニオン装置の全てのクラスで利用可能な一般ＵＲＩを含むことができる。
【００４６】
（３）ＡＩＴは、アプリケーションＵＲＩを受信できる放送サーバーを指す据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むことができる。
【００４７】
図３は、本発明の一実施例に係る、ＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）が信号送信装置にある場合に、コンパニオン装置において付加サービスを実行する方法を説明する図である。
【００４８】
ＵＰｎＰ装置構造は、ＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）のみが装置に命令を伝送したり（ｃｏｎｔｒｏｌ）、装置の状態変更を聞くもの（Ｅｖｅｎｔｉｎｇ）として定義することができる。
【００４９】
図３を参照すると、信号送信装置１００（例、ＴＶ）のみがＣＰを有する。コンパニオン装置２００は、２つの状態変数に対するアクセスを提供する。−コンパニオン装置クラス、開始のためのＵＲＩ。ＡＩＴに含まれたコンパニオンアプリケーションＵＲＩを受信すると、信号送信装置１００は、コンパニオン装置２００によって提供されるサービスを介して直接アプリケーションＵＲＩをセットすることができる。
【００５０】
図４は、本発明の一実施例に係る、ＣＰがコンパニオン装置にある場合に、コンパニオン装置において付加サービスを実行する方法を説明する図である。
【００５１】
図４を参照すると、コンパニオン装置２００のみがＣＰを有する。信号送信装置１００は、２つの状態変数のためのアクセスを提供する。コンパニオン装置クラス、開始のためのＵＲＩ。ＣＰのない装置は、いかなるサービスも提供できないので、コンパニオン装置２００は、能動的に自身の装置クラスを信号送信装置１００にセットし、アプリケーションＵＲＩサービスを照会（ｐｏｌｌ）することが必要である。
【００５２】
図４で説明する方法は２つの点を考慮し得る。
【００５３】
まず、信号送信装置１００における装置クラス状態変数の使用は、ＵＰｎＰの独創的使用である。ＵＰｎＰは、状態変数を、周辺装置を記述（ＧＥＴ）したり制御（ＳＥＴ）したりするパラメータとして思うことができる。しかし、この場合、信号送信装置１００の状態変数は、コンパニオン装置２００を記述するために使用され得る。このように装置クラス変数がｓｅｔを得るとき、特別なハンドリングは、それぞれのコンパニオン装置２００のための別個の値を格納するために行われることが必要であり得る。
【００５４】
次に、ＣＰのない信号送信装置１００は、いかなる動作も能動的にトリガーすることができないため、コンパニオン装置２００は、アプリケーションＵＲＩ状態変数を照会することが必要であり得る。ＵＰｎＰ装置構造は、適用サービスがほぼ３０秒後にリターンされなければならず、もし動作がさらに長くかかるのが明確であれば、それより早くリターンされなければならないものとして定義することができる。これは、サービスの適用からいつリターンするか、いつＡＩＴにトリガーが存在しないかに対することは、信号送信装置１００の裁量であるということを意味する。このようなケースにおいて、信号送信装置１００が速やかにリターンする場合、不当なプロセシング負担及びシステム負荷がコンパニオン装置２００に発生することがある。
【００５５】
図５は、本発明の他の実施例に係る、ＣＰがコンパニオン装置にある場合に、コンパニオン装置において付加サービスを実行する方法を説明する図である。
【００５６】
図５を参照すると、アプリケーションＵＲＩは、信号送信装置１００からイベント型状態変数を介して獲得することができる。図５の方法は、アプリケーションＵＲＩ状態変数のための照会の欠点を克服することができる。
【００５７】
図５の方法は、Ｓｅｔを使用してコンパニオン装置２００が信号送信装置１００に情報を与えるものであり、図４の方法は、Ｇｅｔを使用して信号送信装置１００がコンパニオン装置２００から情報を持って来るものである。
【００５８】
図６は、本発明の一実施例に係る、ＣＰが信号送信装置及びコンパニオン装置の両方にある場合に、コンパニオン装置において付加サービスを実行する方法を説明する図である。
【００５９】
ＣＰが両装置ともにあるので、相互間に自由な通信が可能である。
【００６０】
コンパニオン装置２００は、ｇｅｔ−ａｂｌｅ状態変数を介して自身の装置クラスに対する接近を提供し得、信号送信装置１００は、イベント型状態変数を介してアプリケーションＵＲＩに対する接近を提供し得る。信号送信装置１００がＡＩＴ内のコンパニオンＵＲＩを感知する度に、信号送信装置１００は、アプリケーションＵＲＩ状態変数のためのイベントを生成することができる。
【００６１】
アプリケーションＵＲＩは、コンパニオン装置２００毎に別個の値を有することが必要であるので、アプリケーションＵＲＩ状態変数はイベントの独創的使用である一方、ＵＰｎＰは、全てのメッセージを全ての加入者に送るものとして定義できる。
【００６２】
図７は、本発明の一実施例に係る、ＣＰが第３の装置にある場合に、コンパニオン装置において付加サービスを実行する方法を説明する図である。
【００６３】
図７を参照すると、信号送信装置１００及びコンパニオン装置２００はＣＰを有していない。したがって、信号送信装置１００とコンパニオン装置２００は相互間に通信を行うことができず、第３の装置４００は、プロキシ（ｐｒｏｘｙ）として動作することを期待することができない。しかし、ＣＰが信号送信装置１００及びコンパニオン装置２００のうちの少なくとも１つに含まれる場合、上述した図３乃至図６のうちの一つの方法で信号送受信システムは動作することができる。
【００６４】
図８は、本発明の第１実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【００６５】
図８には、全てのコンパニオン装置（またはセカンド装置）に対するアプリケーションＵＲＩがＡＩＴに含まれており、ＣＰが信号送信装置（例、ＴＶ）に位置した実施例が示されている。
【００６６】
図８を参照すると、ＡＩＴを用いて特定ＵＲＩまたは一般ＵＲＩが伝送される場合のイベントの流れが示されている。したがって、追加的なＵＲＩ解像度（または分解能（ｒｅｓｏｌｕｔｉｏｎ））は不要であり、開始ＵＲＩ（ｌａｕｎｃｈｉｎｇ  ＵＲＩ）は直接コンパニオン装置に伝送され得る。
【００６７】
ＣＰであるＴＶは、ＵＰｎＰ１７を介してコンパニオン装置１９にマルチキャストサーチを伝送して検索（ｄｉｓｃｏｖｅｒｙ）作業を進行する（Ｓ１１１０）。コンパニオン装置１９に対するディスカバリーが完了すると、ＵＰｎＰ１７は、コンパニオン装置１９に、装置タイプ情報をＧｅｔせよという制御信号を伝送する（Ｓ１１１５）。コンパニオン装置１９は、制御信号に対する応答として装置情報をＴＶのＵＰｎＰ１７に伝送する（Ｓ１１２０）。伝送された装置情報は装置管理部１５に伝達される（Ｓ１１２５）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１１３０）。
【００６８】
ＴＶ１１はＡＩＴを受信する（Ｓ１１３５）。ＡＩＴは、コンパニオン装置において開始されるアプリケーションＵＲＩを含むことができる。ＴＶ１１は、受信したＡＩＴをパージングして、装置タイプによるアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１１４０）。装置管理部１５は、装置テーブルのコンパニオン装置に該当するＵＲＩをアップデートする。装置管理部１５は、コンパニオンスクリーンアプリケーションの存在をＨｂｂＴＶアプリケーション１３に知らせる（Ｓ１１４５）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１１５０）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１１５５）。
【００６９】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、付加サービス及び付加サービスを実行するコンパニオン装置のタイプを選択することができる。
【００７０】
ＨｂｂＴＶアプリケーション１３は、選択されたコンパニオン装置と関連する情報を装置管理部１５に伝達する（Ｓ１１６０）。装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１１６５）。ＴＶのＵＰｎＰ１７は、Ｓｅｔ ＵＲＩという制御信号を、選択されたコンパニオン装置１９に伝送する（Ｓ１１７０）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１１７５）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１１８０）。
【００７１】
言い換えると、ＣＰであるＴＶのＵＰｎＰを介してコンパニオン装置にマルチキャストサーチを送ってディスカバリー作業を進行する。コンパニオン装置に対するディスカバリーが完了すると、ＴＶは、コンパニオン装置に、装置タイプをＧｅｔせよというコントロールを伝送する。コンパニオン装置は、コントロールに対する応答として装置情報を伝達する。伝達された装置情報は装置管理部の装置テーブルに伝達されて装置ＩＤと装置タイプを管理する。
【００７２】
ＡＩＴは、コンパニオン装置において開始されるアプリケーションＵＲＩを含み、ＴＶはＡＩＴを受信する。受信したＡＩＴはパージングされ、装置管理部に伝達されて、装置テーブルにあるコンパニオン装置に対応するＵＲＩをアップデートする。装置テーブルは、コンパニオン装置と対応するアプリケーションＵＲＩを含むようになる。もし、ＡＩＴで装置タイプを指定していない場合（例、一般ＵＲＩ）、共通するＵＲＩがコンパニオン装置に伝達される。コンパニオン装置アプリケーションが存在する場合、ＡＩＴを介して利用可能であることを、ＴＶを介して知らせる。ユーザは、これを確認し、接続しようとするコンパニオン装置を選択する。選択された装置は装置管理部に伝達され、コンパニオン装置に伝達される準備が完了する。
【００７３】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩは、ＴＶ（ＣＰ）からコンパニオン装置に、“Ｓｅｔ ＵＲＩ”というコントロールを介して、ユーザが選択したコンパニオン装置に伝達される。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【００７４】
装置テーブル（Ｄｅｖｉｃｅ  Ｔａｂｌｅ）は、ＴＶがＡＩＴを介して検出したそれぞれのコンパニオン装置に応じたＵＲＩまたはサーバー（例、放送局サーバー）のアドレスを格納することができる。そして、装置テーブルは、ＴＶがコンパニオン装置と接続しながら得た装置情報を格納することができる。また、装置テーブルは、サーバーを通じて検出したコンパニオン装置別ＵＲＩを格納することができる。したがって、装置テーブルは、ＨｂｂＴＶ（ｂｒｏｗｓｅｒレベル）とＵＰｎＰ（ｐｈｙｓｉｃａｌレベル）で収集された、コンパニオン装置を動作させるのに必要な情報を統合的に管理する格納空間である。
【００７５】
一方、装置情報は、コンパニオン装置の機器の種類などに関する情報を含むことができる。ＴＶは、ＵＰｎＰのＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）である。一実施例として、ＨｂｂＴＶ ２．０受信機は、ｕｒｎ：ｈｂｂｔｖ−ｏｒｇ：ｄｅｖｉｃｅ：ｈｂｂｔｖ２．０ｒｃｖｒのＵＰｎＰ装置タイプを有する論理的ＵＰｎＰ装置を履行しなければならない。そして、ＨｂｂＴＶ ２．０コンパニオン装置は、ｕｒｎ：ｈｂｂｔｖ−ｏｒｇ：ｄｅｖｉｃｅ：ｈｂｂｔｖ２．０ｒｃｖｒのＵＰｎＰ装置タイプを有する論理的ＵＰｎＰ装置を履行しなければならない。上記のＵＲＮのＮａｍｅｓｐａｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＮＩＤ） ｐｒｅｆｉｘを形成するために、ｈｂｂｔｖ．ｏｒｇのＤＮＳ名は、ＲＦＣ２１４１で要求する通りにｈｂｂｔｖ−ｏｒｇに転換される。ｈｂｂｔｖ−ｏｒｇの後の残余部分は、Ｎａｍｅｓｐａｃｅ Ｓｐｅｃｉｆｉｃ Ｓｔｒｉｎｇ（ＮＳＳ）である。
【００７６】
ＨｂｂＴＶ ２．０受信機は、以下のようなＤｅｖｉｎｆｏサービス及びサービスタイプ及びサービスＩＤを有するＡｐｐＵＲＩサービスを支援する。
【００７７】
【表１】
2016513438.tif 000003
【００７８】
ＤｅｖＩｎｆｏサービスを用いて、ＴＶは、コンパニオン装置から装置情報を持って来ることができる。ＴＶは、ＵＰｎＰのＧＥＴ制御を通じてコンパニオン装置情報を受信することができる。ＤｅｖＩｎｆｏサービスのためのプロトコルは、以下で定義されたパラメータを使用する。
【００７９】
【表２】
2016513438.tif 000004
【００８０】
表２は、Ｄｅｖｉｎｆｏ Ｓｅｒｖｉｃｅ ｓｔａｔｅ  ｖａｒｉａｂｌｅである。
【００８１】
【表３】
2016513438.tif 000005
【００８２】
表３は、ＤｅｖＣｌａｓｓ Ｓｅｒｖｉｃｅ ａｃｔｉｏｎである。
【００８３】
【表４】
2016513438.tif 000006
【００８４】
表４は、ＧｅｔＤｅｖＣｌａｓｓ ａｃｔｉｏｎ ａｒｇｕｍｅｎｔｓである。
【００８５】
ＤｅｖＣｌａｓｓ ｓｔａｔｅ ｖａｒｉａｂｌｅを使用するために、次の規則が適用される。
【００８６】
ａ）コンパニオン装置は、“Ｐｈｏｎｅ”、“Ｔａｂｌｅｔ”または“ＰＣ”クラスとして自身を識別する。
【００８７】
ｂ）ＴＶは、“ＴＶ”クラスとして自身を識別する。
【００８８】
ＡｐｐＵＲＩサービスは、ＴＶからコンパニオン装置にアプリケーションのための開始ＵＲＩを送るために使用できる。複数のコンパニオン装置が利用可能なとき、ＨｂｂＴＶアプリケーションは、一つを選択するようにユーザを誘導し、選択された装置のためのＵＲＩは、ＵＰｎＰのＳＥＴ制御を通じて伝送され得る。ＡｐｐＵＲＩサービスのためのプロトコルは、以下で定義されたパラメータを使用する。
【００８９】
【表５】
2016513438.tif 000007
【００９０】
表５は、ＡｐｐＵＲＩ Ｓｅｒｖｉｃｅ ｓｔａｔｅ ｖａｒｉａｂｌｅである。
【００９１】
【表６】
2016513438.tif 000008
【００９２】
表６は、ＡｐｐＵＲＩ Ｓｅｒｖｉｃｅ ａｃｔｉｏｎである。
【００９３】
【表７】
2016513438.tif 000009
【００９４】
表７は、ＳｅｔＡｐｐＵＲＩ ａｃｔｉｏｎ ａｒｇｕｍｅｎｔｓである。
【００９５】
ＤｉｓｐｌａｙＩｎｔｎｅｔ ｓｔａｔｅ ｖａｒｉａｂｌｅ及びａｃｔｉｏｎ ａｒｇｕｍｅｎｔを使用するために、次の規則が適用される。
【００９６】
ａ）ＷｅｂＶｉｅｗまたはＳｙｓｔｅｍＢｒｏｗｅｒのうちの１つがセットされる。
【００９７】
ｂ）ＷｅｂＶｉｅｗが伝送されると、関連するＵＲＩは、コンパニオンアプリケーション内に埋め込まれたＷｅｂＶｉｅｗで開始され得る。他の場合には、ＵＲＩは、コンパニオン装置の基本Ｗｅｂ ｂｒｏｗｓｅｒで開始され得る。
【００９８】
ｃ）埋め込まれたＷｅｂＶｉｅｗが提供されないコンパニオン装置は、全てのＵＲＩを基本Ｗｅｂ ｂｒｏｗｓｅｒで開始する。
【００９９】
図９は、本発明の第２実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【０１００】
図９には、全てのコンパニオン装置に対するアプリケーションＵＲＩがＡＩＴに含まれ、ＣＰがコンパニオン装置に位置した実施例が示されている。
【０１０１】
図９を参照すると、ＣＰであるコンパニオン装置１９は、ＴＶにマルチキャスト方式を用いて検索（ｄｉｓｃｏｖｅｒｙ）作業を行う（Ｓ１２１０）。検索作業が完了すると、コンパニオン装置１９からＴＶに、コンパニオン装置の装置情報をＳｅｔせよという制御信号を伝送する（Ｓ１２１５）。ＴＶのＵＰｎＰ１７は、コンパニオン装置情報を装置管理部１５に伝達する（Ｓ１２２０）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１２２５）。
【０１０２】
ＴＶ１１はＡＩＴを受信する（Ｓ１２３０）。ＡＩＴは、コンパニオン装置において開始されるアプリケーションＵＲＩを含むことができる。ＴＶ１１は、受信したＡＩＴをパージングして、装置タイプによるアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１２３５）。装置管理部１５は、装置テーブルのコンパニオン装置に該当するＵＲＩをアップデートする。装置管理部１５は、コンパニオンスクリーンアプリケーションの存在をＨｂｂＴＶアプリケーション１３に知らせる（Ｓ１２４０）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１２４５）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１２５０）。
【０１０３】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、付加サービス及び付加サービスを実行するコンパニオン装置のタイプを選択することができる。
【０１０４】
ＨｂｂＴＶアプリケーション１３は、選択されたコンパニオン装置と関連する情報を装置管理部１５に伝達する（Ｓ１２５５）。装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１２６０）。伝達されたＵＲＩがある場合、ＴＶのＵＰｎＰ１７は、コンパニオン装置に、伝達されたＵＲＩを知らせる（Ｓ１２６５）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１２７０）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１２７５）。
【０１０５】
言い換えると、ＣＰであるコンパニオン装置のＵＰｎＰを介してＴＶにマルチキャストサーチを送ってディスカバリー作業を進行する。ＴＶに対するディスカバリーが完了すると、コンパニオン装置は、ＴＶに、コンパニオン装置の装置タイプをＳｅｔせよというコントロールを送る。ＴＶは、コンパニオン装置でＳｅｔした情報を装置管理部に伝達する。装置テーブルは、全てのコンパニオン装置の装置ＩＤと装置タイプを管理する。
【０１０６】
ＡＩＴは、コンパニオン装置において開始されるアプリケーションＵＲＩを含み、ＴＶはＡＩＴを受信する。受信したＡＩＴはパージングされ、装置管理部に伝達されて、装置テーブルにあるコンパニオン装置に対応するＵＲＩをアップデートする。装置テーブルは、コンパニオン装置と対応するアプリケーションＵＲＩを含むようになる。もし、ＡＩＴで装置タイプを指定していない場合（例、一般ＵＲＩ）、共通するＵＲＩがコンパニオン装置に伝達される。コンパニオン装置アプリケーションが存在する場合、ＡＩＴを介して利用可能であることを、ＴＶを介して知らせる。ユーザは、これを確認し、接続しようとするコンパニオン装置を選択する。選択された装置は装置管理部に伝達され、コンパニオン装置に伝達される準備が完了する。
【０１０７】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩがある場合、ユーザが選択したコンパニオン装置（ＣＰ）は、ＴＶで変更された（伝達された）ＵＲＩの通知（ｎｏｔｉｆｙ）を受けるようになり、アプリケーションＵＲＩの伝達を受ける。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【０１０８】
一方、装置情報は、コンパニオン装置の機器の種類などに関する情報を含むことができる。コンパニオン装置は、ＵＰｎＰのＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）である。一実施例として、ＨｂｂＴＶ ２．０受信機のＵＰｎＰ装置タイプは、ｕｒｎ：ｈｂｂｔｖ．ｏｒｇ：ｄｅｖｉｃｅ：ｈｂｂｔｖ２．０ｒｃｖｒである。場合によって、Ｎａｍｅｓｐａｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＮＩＤ） ｐｒｅｆｉｘを形成するために、ｈｂｂｔｖ．ｏｒｇのＤＮＳ名は、ＲＦＣ２１４１で要求する通りにｈｂｂｔｖ−ｏｒｇに転換され得る。ｈｂｂｔｖ−ｏｒｇの後の残余部分は、Ｎａｍｅｓｐａｃｅ Ｓｐｅｃｉｆｉｃ Ｓｔｒｉｎｇ（ＮＳＳ）である。ＨｂｂＴＶ ２．０受信機は、以下のようなＤｅｖｉｎｆｏサービス及びサービスタイプ及びサービスＩＤを有するＡｐｐＵＲＩサービスを支援する。
【０１０９】
【表８】
2016513438.tif 000010
【０１１０】
表８は、Ｓｅｒｖｉｃｅ ｔｙｐｅ及びＳｅｒｖｉｃｅ ＩＤを示す。
【０１１１】
ＤｅｖＩｎｆｏサービスを用いて、ＴＶは、ＣＰであるコンパニオン装置から装置情報を受信することができる。コンパニオン装置がＣＰであるので、ＵＰｎＰの特性上、Ｓｅｔ Ｃｏｎｔｒｏｌを通じてＴＶに情報を伝達する。
【０１１２】
ＡｐｐＵＲＩサービスは、ＴＶからコンパニオン装置（ＣＰ）に、アプリケーションを開始するＵＲＩを伝達するためのサービスである。ユーザが選択したコンパニオン装置に該当するＵＲＩをＨｂｂＴＶアプリケーションを介して得て、当該コンパニオン装置にｎｏｔｉｆｙしてＵＰｎＰを介して伝達する。
【０１１３】
【表９】
2016513438.tif 000011
【０１１４】
表９は、ＤｅｖＩｎｆｏ ｅｒｖｉｃｅ ｓｔａｔｅ ｖａｒｉａｂｌｅである。
【０１１５】
【表１０】
2016513438.tif 000012
【０１１６】
表１０は、ＤｅｖＩｎｆｏ Ｓｅｒｖｉｃｅ ａｃｔｉｏｎである。
【０１１７】
【表１１】
2016513438.tif 000013
【０１１８】
表１１は、Ａｒｇｕｍｅｎｔ ｏｆ ＧｅｔＤｅｖＩｎｆｏ ａｃｔｉｏｎである。
【０１１９】
【表１２】
2016513438.tif 000014
【０１２０】
表１２は、ＡｐｐＵＲＩ Ｓｅｒｖｉｃｅ ｓｔａｔｅ ｖａｒｉａｂｌｅである。
【０１２１】
【表１３】
2016513438.tif 000015
【０１２２】
表１３は、ＡｐｐＵＲＩ Ｓｅｒｖｉｃｅ Ａｃｔｉｏｎｓである。
【０１２３】
【表１４】
2016513438.tif 000016
【０１２４】
表１４は、Ａｒｇｕｍｅｎｔ ｏｆ ＳｅｔＡｐｐＵＲＩ ａｃｔｉｏｎである。
【０１２５】
図１０は、本発明の第３実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【０１２６】
図１０には、ＡＩＴを用いて据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）が伝送される場合のイベントの流れが示されている。したがって、アプリケーションＵＲＩが、コンパニオン装置に伝送される前に、遠隔サーバーから検索される過程を必要とする。
【０１２７】
ＣＰであるＴＶは、ＵＰｎＰ１７を介してコンパニオン装置１９にマルチキャストサーチを送って検索（ｄｉｓｃｏｖｅｒｙ）作業を進行する（Ｓ１３１０）。コンパニオン装置１９に対するディスカバリーが完了すると、ＵＰｎＰ１７は、コンパニオン装置１９に、装置タイプ情報をＧｅｔせよという制御信号を伝送する（Ｓ１３１５）。コンパニオン装置１９は、制御信号に対する応答として装置情報をＴＶのＵＰｎＰ１７に伝送する（Ｓ１３２０）。伝送された装置情報は、装置管理部１５に伝達される（Ｓ１３２５）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１３３０）。
【０１２８】
ＴＶ１１はＡＩＴを受信する（Ｓ１３３５）。ＡＩＴは、サーバーに接続可能な据え置きＵＲＩを含むことができる。ＴＶ１１は、受信したＡＩＴをパージングして、サーバーに接続できる据え置きＵＲＩを装置管理部１５に伝達する（Ｓ１３４０）。装置管理部１５は、コンパニオンスクリーンアプリケーションの存在をＨｂｂＴＶアプリケーション１３に知らせる（Ｓ１３４５）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１３５０）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１３５５）。ＨｂｂＴＶアプリケーション１３は、据え置きＵＲＩを通じて、コンパニオン装置の装置タイプに対応するアプリケーションＵＲＩを要求する（Ｓ１３６０）。サーバー３１は、要求に対する応答として装置タイプ別アプリケーションＵＲＩをＴＶに伝送する（Ｓ１３６５）。ＨｂｂＴＶアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１３７０）。装置管理部１５は、伝達されたアプリケーションＵＲＩを装置テーブルに格納する（Ｓ１３７５）。
【０１２９】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、付加サービス及び付加サービスを実行するコンパニオン装置のタイプを選択することができる。
【０１３０】
装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１３８０）。ＴＶのＵＰｎＰ１７は、Ｓｅｔ ＵＲＩという制御信号を、選択されたコンパニオン装置１９に伝送する（Ｓ１３８５）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１３９０）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１３９５）。
【０１３１】
言い換えると、ＣＰであるＴＶのＵＰｎＰを介してコンパニオン装置にマルチキャストサーチを送ってディスカバリー作業を進行する。コンパニオン装置に対するディスカバリーが完了すると、ＴＶは、コンパニオン装置に、装置タイプをＧｅｔせよというコントロールを送る。コンパニオン装置は、コントロールに対する応答として装置情報を伝達する。伝達された装置情報は、装置管理部の装置テーブルに伝達されて装置ＩＤと装置タイプを管理する。
【０１３２】
ＡＩＴは、サーバーに接続可能な据え置きＵＲＩを含み、ＴＶは、ＡＩＴを受信する。受信したＡＩＴはパージングされ、装置管理部に伝達される。装置管理部は、全てのコンパニオン装置のためにＵＲＩをアップデートする。据え置きＵＲＩは、装置クラスに応じて識別されないため、装置クラス別に識別され得るＵＲＩが必要である。装置管理部は、据え置きＵＲＩが利用可能であるということをＤＯＭイベントを介してＨｂｂＴＶアプリケーションに知らせる。このとき、ＨｂｂＴＶアプリケーションは、据え置きＵＲＩを解釈し、装置テーブルに最終のＵＲＩを格納する。その後、ＨｂｂＴＶアプリケーションは、ＵＲＩがアップデートされたことを装置管理部に知らせ、装置管理部は、２番目のＤＯＭイベントを生成する。コンパニオン装置アプリケーションが存在する場合、ＡＩＴを介して利用可能であることを、ＴＶを介して知らせる。ユーザは、これを確認し、接続しようとするコンパニオン装置を選択する。選択された装置は装置管理部に伝達され、コンパニオン装置に伝達される準備が完了する。
【０１３３】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩは、ＴＶ（ＣＰ）からコンパニオン装置に、“Ｓｅｔ ＵＲＩ”というコントロールを介して、ユーザが選択したコンパニオン装置に伝達される。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【０１３４】
図１１は、本発明の第４実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【０１３５】
図１１を参照すると、ＣＰであるコンパニオン装置１９は、ＴＶにマルチキャスト方式を用いて検索（ｄｉｓｃｏｖｅｒｙ）作業を行う（Ｓ１４１０）。検索作業が完了すると、コンパニオン装置１９からＴＶに、コンパニオン装置の装置情報をＳｅｔせよという制御信号を伝送する（Ｓ１４１５）。ＴＶのＵＰｎＰ１７は、コンパニオン装置情報を装置管理部１５に伝達する（Ｓ１４２０）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１４２５）。
【０１３６】
ＴＶ１１はＡＩＴを受信する（Ｓ１４３０）。ＡＩＴは、サーバーに接続可能な据え置きＵＲＩを含むことができる。ＴＶ１１は、受信したＡＩＴをパージングして、サーバーに接続できる据え置きＵＲＩを装置管理部１５に伝達する（Ｓ１４３５）。装置管理部１５は、コンパニオンスクリーンアプリケーションの存在をＨｂｂＴＶアプリケーション１３に知らせる（Ｓ１４４０）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１４４５）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１４５０）。ＨｂｂＴＶアプリケーション１３は、据え置きＵＲＩを介して、コンパニオン装置の装置タイプに対応するアプリケーションＵＲＩを要求する（Ｓ１４５５）。サーバー３１は、要求に対する応答として装置タイプ別アプリケーションＵＲＩをＴＶに伝送する（Ｓ１４６０）。ＨｂｂＴＶアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１４６５）。装置管理部１５は、伝達されたアプリケーションＵＲＩを装置テーブルに格納する（Ｓ１４７０）。
【０１３７】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、付加サービス及び付加サービスを実行するコンパニオン装置のタイプを選択することができる。
【０１３８】
装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１４７５）。伝達されたＵＲＩがある場合、ＴＶのＵＰｎＰ１７は、コンパニオン装置に、伝達されたＵＲＩを知らせる（Ｓ１４８０）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１４８５）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１４９０）。
【０１３９】
言い換えると、ＣＰであるコンパニオン装置のＵＰｎＰを介してＴＶにマルチキャストサーチを送ってディスカバリー作業を進行する。ＴＶに対するディスカバリーが完了すると、コンパニオン装置は、ＴＶに、コンパニオン装置の装置タイプをＳｅｔせよというコントロールを送る。ＴＶは、コンパニオン装置でＳｅｔした情報を装置管理部に伝達する。装置テーブルは、全てのコンパニオン装置の装置ＩＤと装置タイプを管理する。
【０１４０】
ＡＩＴは、サーバーに接続可能な据え置きＵＲＩを含み、ＴＶは、ＡＩＴを受信する。受信したＡＩＴはパージングされ、装置管理部に伝達される。装置管理部は、全てのコンパニオン装置のためにＵＲＩをアップデートする。据え置きＵＲＩは、装置クラスに応じて識別されないため、装置クラス別に識別され得るＵＲＩが必要である。装置管理部は、据え置きＵＲＩが利用可能であるということをＤＯＭイベントを介してＨｂｂＴＶアプリケーションに知らせる。このとき、ＨｂｂＴＶアプリケーションは、据え置きＵＲＩを解釈し、装置テーブルに最終のＵＲＩを格納する。その後、ＨｂｂＴＶアプリケーションは、ＵＲＩがアップデートされたことを装置管理部に知らせ、装置管理部は、２番目のＤＯＭイベントを生成する。コンパニオン装置アプリケーションが存在する場合、ＡＩＴを介して利用可能であることを、ＴＶを介して知らせる。ユーザは、これを確認し、接続しようとするコンパニオン装置を選択する。選択された装置は装置管理部に伝達され、コンパニオン装置に伝達される準備が完了する。
【０１４１】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩがある場合、ユーザが選択したコンパニオン装置（ＣＰ）は、ＴＶで変更された（伝達された）ＵＲＩのｎｏｔｉｆｙを受けるようになり、アプリケーションＵＲＩの伝達を受ける。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【０１４２】
図１２は、本発明の第５実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【０１４３】
図１２には、コンパニオンアプリケーションのためのトリガーが、ＡＩＴではなく放送サーバーから伝送される場合のイベントの流れが示されている。この方法は、放送信号の受信なしにコンパニオンアプリケーションを開始することができる。ＴＶのＨｂｂＴＶアプリケーションは、能動的に放送サーバーをクエリーすることが必要である。ＡＩＴのような自動トリガリングは支援されない。
【０１４４】
ＣＰであるＴＶは、ＵＰｎＰ１７を介してコンパニオン装置１９にマルチキャストサーチを送って検索（ｄｉｓｃｏｖｅｒｙ）作業を進行する（Ｓ１５１０）。コンパニオン装置１９に対するディスカバリーが完了すると、ＵＰｎＰ１７は、コンパニオン装置１９に、装置タイプ情報をＧｅｔせよという制御信号を伝送する（Ｓ１５１５）。コンパニオン装置１９は、制御信号に対する応答として装置情報をＴＶのＵＰｎＰ１７に伝送する（Ｓ１５２０）。伝送された装置情報は装置管理部１５に伝達される（Ｓ１５２５）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１５３０）。
【０１４５】
ＴＶのＨｂｂＴＶアプリケーション１３は、放送サーバー３１に、コンパニオン装置アプリケーションを利用可能であるか否かを決定することを要求する（Ｓ１５３５）。利用可能なコンパニオン装置アプリケーションが存在する場合、放送サーバー３１は、ＨｂｂＴＶアプリケーション１３に応答を送る（Ｓ１５４０）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１５４５）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１５５０）。
【０１４６】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、インスタンス（ｉｎｓｔａｎｃｅ）または装置タイプを選択することができる。ＨｂｂＴＶアプリケーション１３は、コンパニオン装置タイプに対応するＵＲＩを放送サーバー３１に要求する（Ｓ１５５５）。放送サーバー３１は、ＨｂｂＴＶアプリケーションに、要求されたＵＲＩを伝送する（Ｓ１５６０）。
【０１４７】
ＨｂｂＴＶアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１５６５）。装置管理部１５は、伝達されたアプリケーションＵＲＩを装置テーブルに格納する（Ｓ１５７０）。装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１５７５）。ＴＶのＵＰｎＰ１７は、Ｓｅｔ ＵＲＩという制御信号を、選択されたコンパニオン装置１９に伝送する（Ｓ１５８０）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１５８５）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１５９０）。
【０１４８】
言い換えると、ＣＰであるＴＶのＵＰｎＰを介してコンパニオン装置にマルチキャストサーチを送ってディスカバリー作業を進行する。コンパニオン装置に対するディスカバリーが完了すると、ＴＶは、コンパニオン装置に、装置タイプをＧｅｔせよというコントロールを送る。コンパニオン装置は、コントロールに対する応答として装置情報を伝達する。伝達された装置情報は、装置管理部の装置テーブルに伝達されて装置ＩＤと装置タイプを管理する。
【０１４９】
ＡＩＴに含まれたコンパニオンアプリケーションＵＲＩを感知するために装置管理部を待つ代わりに、ＨｂｂＴＶアプリケーションは、コンパニオン装置アプリケーションが現在有用なコンパニオン装置のために利用可能であるか否かに対して放送サーバーをクエリーする。もし、コンパニオン装置があれば、ＴＶは、開始ＵＲＩの提供を受ける。そのとき、ユーザは、アプリケーションＵＲＩを送るための接続された装置を選択することができる。装置管理部の装置テーブルに登録されたコンパニオン装置は、放送サーバーから受信された装置タイプに対応するアプリケーションＵＲＩをアップデートすることができる。ＴＶは、選択されたコンパニオン装置に開始ＵＲＩを伝送する準備を完了する。
【０１５０】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩは、ＴＶ（ＣＰ）からコンパニオン装置に、“Ｓｅｔ ＵＲＩ”というコントロールを介して、ユーザが選択したコンパニオン装置に伝達される。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【０１５１】
ＴＶは、チューナーを介して、放送局から受信される放送信号を受信する場合もあるが、ＩＰのみで接続される場合もある。ＩＰのみで接続される場合、ＴＶは、ＨｂｂＴＶアプリケーションと放送サーバー間の通信を介して、チューナーなしにもコンパニオン装置アプリケーションの存在を知らせることができる。
【０１５２】
図１３は、本発明の第６実施例に係るコンパニオン装置（ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）において付加サービスを実行する方法を説明するタイミング図である。
【０１５３】
図１３を参照すると、ＣＰであるコンパニオン装置１９は、ＴＶにマルチキャスト方式を用いて検索（ｄｉｓｃｏｖｅｒｙ）作業を行う（Ｓ１６１０）。検索作業が完了すると、コンパニオン装置１９からＴＶに、コンパニオン装置の装置情報をＳｅｔせよという制御信号を伝送する（Ｓ１６１５）。ＴＶのＵＰｎＰ１７は、コンパニオン装置情報を装置管理部１５に伝達する（Ｓ１６２０）。装置管理部１５は、装置テーブルを作成し、装置ＩＤ、装置タイプ及びＵＲＩを管理する（Ｓ１６２５）。
【０１５４】
ＴＶのＨｂｂＴＶアプリケーション１３は、放送サーバー３１に、コンパニオン装置アプリケーションを利用可能であるか否かを決定することを要求する（Ｓ１６３０）。利用可能なコンパニオン装置アプリケーションが存在する場合、放送サーバー３１は、ＨｂｂＴＶアプリケーション１３に応答を送る（Ｓ１６３５）。ＨｂｂＴＶアプリケーション１３は、全てのコンパニオン装置情報を要求する（Ｓ１６４０）。装置管理部１５は、要求に対する応答としてコンパニオン装置情報を伝達する（Ｓ１６４５）。
【０１５５】
ＴＶ１１は、放送中のプログラムと関連する付加サービスが存在すれば、ユーザに付加サービスの存在を知らせ、ユーザは、インスタンス（ｉｎｓｔａｎｃｅ）または装置タイプを選択することができる。ＨｂｂＴＶアプリケーション１３は、コンパニオン装置タイプに対応するＵＲＩを放送サーバー３１に要求する（Ｓ１６５０）。放送サーバー３１は、ＨｂｂＴＶアプリケーションに、要求されたＵＲＩを伝送する（Ｓ１６５５）。
【０１５６】
ＨｂｂＴＶアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ１６６０）。装置管理部１５は、伝達されたアプリケーションＵＲＩを装置テーブルに格納する（Ｓ１６６５）。装置管理部１５は、選択されたコンパニオン装置と対応するアプリケーションＵＲＩをＴＶのＵＰｎＰ１７に伝達する（Ｓ１６７０）。伝達されたＵＲＩがある場合、ＴＶのＵＰｎＰ１７は、コンパニオン装置に、伝達されたＵＲＩを知らせる（Ｓ１６７５）。コンパニオン装置１９は、伝送されたＵＲＩをウェブビュー２１に伝達する（Ｓ１６８０）。ウェブビュー２１は、インターネット網を用いてＵＲＩページを表示する（Ｓ１６８５）。
【０１５７】
言い換えると、ＣＰであるコンパニオン装置のＵＰｎＰを介してＴＶにマルチキャストサーチを送ってディスカバリー作業を進行する。ＴＶに対するディスカバリーが完了すると、コンパニオン装置は、ＴＶに、コンパニオン装置の装置タイプをＳｅｔせよというコントロールを送る。ＴＶは、コンパニオン装置でＳｅｔした情報を装置管理部に伝達する。装置テーブルは、全てのコンパニオン装置の装置ＩＤと装置タイプを管理する。
【０１５８】
ＡＩＴに含まれたコンパニオンアプリケーションＵＲＩを感知するために装置管理部を待つ代わりに、ＨｂｂＴＶアプリケーションは、コンパニオン装置アプリケーションが現在有用なコンパニオン装置のために利用可能であるか否かに対して放送サーバーをクエリーする。もし、コンパニオン装置があれば、ＴＶは、開始ＵＲＩの提供を受ける。そのとき、ユーザは、アプリケーションＵＲＩを送るための接続された装置を選択することができる。装置管理部の装置テーブルに登録されたコンパニオン装置は、放送サーバーから受信された装置タイプに対応するアプリケーションＵＲＩをアップデートすることができる。ＴＶは、選択されたコンパニオン装置に開始ＵＲＩを伝送する準備を完了する。
【０１５９】
装置管理部は、ユーザから選択されたコンパニオン装置と対応するアプリケーションＵＲＩを、ＴＶのＵＰｎＰに伝達する。伝達されたＵＲＩがある場合、ユーザが選択したコンパニオン装置（ＣＰ）は、ＴＶで変更された（伝達された）ＵＲＩの通知（ｎｏｔｉｆｙ）を受けるようになり、アプリケーションＵＲＩの伝達を受ける。受信されたＵＲＩは、コンパニオン装置においてウェブビューを介してユーザに表示される。
【０１６０】
図１４は、本発明の一実施例に係るＵＲＩディスクリプタを説明する図である。
【０１６１】
上述した図８乃至図１１では、ＵＲＩをＡＩＴを介して受信する実施例を説明した。図１４は、ＡＩＴが一つのＵＲＩを含んでいる場合に、ＵＲＩを伝達するディスクリプタを説明する。例えば、一つのＵＲＩは、一般ＵＲＩ（ｇｅｎｅｒｉｃ  ＵＲＩ）、据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）などであり得る。ｓｉｎｇｌｅ ＵＲＩ ｄｅｓｃｒｉｐｔｏｒに含まれる具体的な情報は、以下の通りである。
【０１６２】
ｄｅｓｃｒｉｐｔｏｒ_ｔａｇは、当該ディスクリプタを識別する８ビット識別子であって、ｓｉｎｇｌｅ ＵＲＩ ｄｅｓｃｒｉｐｔｏｒでは０ｘ６Ｆ値を有する。
【０１６３】
ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈは、８ビットであって、次に位置するディスクリプタフィールドのバイト数を示す。
【０１６４】
ＵＲＩ_ｌｅｎｇｔｈは、１６ビットであって、次に位置するＵＲＩフィールドのバイト数を示す。
【０１６５】
ＵＲＩ_ｃｈａｒは、ＵＲＩの特性を示す。
【０１６６】
図１５は、本発明の他の実施例に係るＵＲＩディスクリプタを説明する図である。
【０１６７】
図１５は、ＡＩＴが複数個のＵＲＩを含んでいる場合に、ＵＲＩを伝達するディスクリプタを説明する。例えば、複数個のＵＲＩは特定ＵＲＩ（ｓｐｅｃｉｆｉｃ  ＵＲＩ）などであり得る。ｍｕｌｔｉ ＵＲＩ ｄｅｓｃｒｉｐｔｏｒに含まれる具体的な情報は、以下の通りである。
【０１６８】
ｄｅｓｃｒｉｐｔｏｒ_ｔａｇは、当該ディスクリプタを識別する８ビット識別子であって、ｓｉｎｇｌｅ ＵＲＩ ｄｅｓｃｒｉｐｔｏｒでは０ｘ６Ｆ値を有する。
【０１６９】
ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈは、８ビットであって、次に位置するディスクリプタフィールドのバイト数を示す。
【０１７０】
ｄｅｖｉｃｅ_ｎｕｍｂｅｒは、１６ビットであって、当該ディスクリップにおいて可能なコンパニオン装置の数を示す。
【０１７１】
ｄｅｖｉｃｅ_ｔｙｐｅは、コンパニオン装置のタイプを示す。ｄｅｖｉｃｅ_ｔｙｐｅについては、図１６で具体的に説明する。
【０１７２】
ＵＲＩ_ｌｅｎｇｔｈは、１６ビットであって、次に位置するＵＲＩフィールドのバイト数を示す。
【０１７３】
ＵＲＩ_ｃｈａｒは、ＵＲＩの特性を示す。
【０１７４】
図１６は、装置タイプ情報をシグナリングする実施例を説明する図である。
【０１７５】
ｄｅｖｉｃｅ_ｔｙｐｅの具体的な情報は、以下の通りである。
【０１７６】
ｄｅｖｉｃｅ_ｔｙｐｅが０である場合、コンパニオン装置はＰＣクラスを示す。
【０１７７】
ｄｅｖｉｃｅ_ｔｙｐｅが１である場合、コンパニオン装置はタブレットクラスを示す。
【０１７８】
ｄｅｖｉｃｅ_ｔｙｐｅが２である場合、コンパニオン装置はスマートフォンクラスを示す。
【０１７９】
図１７は、コンパニオン装置情報をシグナリングする実施例を説明する図である。
【０１８０】
ＡＩＴは、コンパニオン装置の利用可能性をシグナリングするためにＵＲＩ ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒを含むことができる。
【０１８１】
ＵＲＩ ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒのＵＲＩ ｌｉｎｋａｇｅ ｔｙｐｅフィールドは、コンパニオンアプリケーションＵＲＩが伝送されることを示すために０ｘ８０にセットされ得る。そして、ＵＲＩが示す受信装置のタイプを知らせるために、ｐｒｉｖａｔｅ ｄａｔａフィールドは、図１７のようなｃｏｍｐａｎｉｏｎ ｌｉｎｋ ｉｎｆｏ構造をエンコーディングすることができる。
【０１８２】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅは、ＵＲＩの目的を示す８ビットフィールドである。具体的な情報は、図１８で説明する。
【０１８３】
ｄｉｓｐｌａｙ_ｉｎｔｅｎｔは、ＵＲＩを介して開始されるアプリケーションをディスプレイする方法を示す。具体的な情報は、図１９で説明する。
【０１８４】
ｒｅｓｅｒｖｅｄは、後で使用できるように残しておいた６ビットフィールドであって、０にセットされ得る。
【０１８５】
ＡＩＴに含まれたＵＲＩ ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒの伝送のために、次の規則が適用される。ＵＲＩ ｌｉｎｋａｇｅ ｔｙｐｅフィールド値が０ｘ８０であるＵＲＩ ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒの伝送は選択的である。このようなディスクリプタは、ディスクリプタループの各インスタンスで一回以上許容される。ディスクリプタループの与えられたインスタンス内の同じｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅを有するディスクリプタのマルチプルインスタンスはない。
【０１８６】
図１８は、ＵＲＩタイプ情報をシグナリングする実施例を説明する図である。
【０１８７】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅの具体的な情報は、次の通りである。
【０１８８】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅ値が０ｘ０１であれば、ＡＩＴに含まれたＵＲＩは、据え置きＵＲＩを示す。
【０１８９】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅ値が０ｘ０２であれば、ＡＩＴに含まれたＵＲＩは、全ての装置クラスを対象とする一般ＵＲＩを示す。
【０１９０】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅ値が０ｘ０３であれば、ＡＩＴに含まれたＵＲＩは、タブレット装置クラスを対象とする特定ＵＲＩを示す。
【０１９１】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅ値が０ｘ０４であれば、ＡＩＴに含まれたＵＲＩは、ＴＶ装置クラスを対象とする特定ＵＲＩを示す。
【０１９２】
ｌｉｎｋ_ｔａｒｇｅｔ_ｔｙｐｅ値が０ｘ０５であれば、ＡＩＴに含まれたＵＲＩは、ＰＣ装置クラスを対象とする特定ＵＲＩを示す。
【０１９３】
図１９は、コンパニオンアプリケーション（ｃｏｍｐａｎｉｏｎ  ａｐｐｌｉｃａｔｉｏｎ）を実行する方式に関する情報をシグナリングする実施例を説明する図である。
【０１９４】
ｄｉｓｐｌａｙ_ｉｎｔｅｎｔの具体的な情報は、次の通りである。
【０１９５】
ｄｉｓｐｌａｙ_ｉｎｔｅｎｔ値が０であれば、コンパニオンアプリケーションは、システムウェブブラウザでディスプレイされる。
【０１９６】
ｄｉｓｐｌａｙ_ｉｎｔｅｎｔ値が１であれば、コンパニオンアプリケーションは、埋め込まれたウェブビューでディスプレイされる。
【０１９７】
図２０は、本発明の一実施例に係る据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）のＧＥＴ要求ヘッダー情報を説明する図である。
【０１９８】
ｃｏｍｐａｎｉｏｎ_ｌｉｎｋ_ｉｎｆｏ構造で据え置きＵＲＩが伝送される場合、信号送信装置は、コンパニオンアプリケーションと直接接続されるように提供されない。その代わりに、ＵＲＩ_ｌｉｎｋａｇｅ_ｄｅｓｃｒｉｐｔｏｒを介して伝送されるＵＲＩが、コンパニオン装置アプリケーションに関する情報をダウンロードできる遠隔サーバーのリソースを識別することができる。この場合、ＴＶは、位置別にＵＲＩを区別し、区別された位置からリソースを得なければならない。据え置きＵＲＩの解像度は装置管理部ＡＰＩを用いて履行される。ｈｔｔｐまたはｈｔｔｐｓ ＵＲＩ書式に従うＵＲＩが、ＵＲＩ_ｌｉｎｋａｇｅ_ｄｅｓｃｒｉｐｔｏｒ内の据え置きＵＲＩとして使用される。
【０１９９】
ＴＶは、ヘッダーフィールドを伝送するＨＴＴＰ ＧＥＴ要求を発行する。クライアントは、追加的なヘッダーフィールドをエンコーディングし得る。そして、サーバーは、このような追加的なヘッダーフィールドを無視し得る。サーバーは、要求に対して応答し得る。再伝送状態コードのうちの１つがサーバーによってリターンされるとき、ＴＶは、このような再伝送に従うための一般的な政策を従わなければならない。
【０２００】
据え置きＵＲＩを区別するためのＧＥＴ要求ヘッダー情報は、図２０に示した通りである。
【０２０１】
図２１は、本発明の一実施例に係るＧＥＴ応答情報を説明する図である。
【０２０２】
サーバーが、図２０に定義されたような据え置きＵＲＩのための要求を受信すると、サーバーは、図２０で説明するような応答のうち１つを送る。
【０２０３】
サーバーで送る可能なＧＥＴ応答状態コードは、図２１に示した通りである。
【０２０４】
図２２は、本発明の一実施例に係るコンパニオンアプリケーションＵＲＩをエンコーディングするためのＪＳＯＮ ｓｃｈｅｍａを説明する図である。
【０２０５】
サーバーが２００ ＯＫ状態コードで応答する場合、サーバーは、図２２に示されたＪＳＯＮ書式に従ってＪＳＯＮ個体（ｅｎｔｉｔｙ）を伝達する。
【０２０６】
ＪＳＯＮ書式は、サーバー応答は１つ以上の客体を含むアレイで構成されるものと定義できる。このような客体は、ターゲット（ｔａｒｇｅｔ）とＵＲＩとの２つのメンバー要素を含むことができる。ＵＲＩメンバーは、ＵＲＩタイプであり、アプリケーションリソースを得ることができる位置を示す。ターゲットメンバーは列挙タイプであり、ＵＲＩによってターゲットとされる装置クラスを示す。
【０２０７】
図２３は、コンパニオン装置に応じたＵＲＩをエンコーディングする実施例を説明する図である。
【０２０８】
一実施例として、一つのターゲットはスマートフォン、他の一つのターゲットはテーブル型装置の２つのＵＲＩをエンコーディングするために、図２３のようなＪＳＯＮ客体がリターンされ得る。
【０２０９】
一方、装置管理部（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）は装置テーブル（Ｄｅｖｉｃｅ  Ｔａｂｌｅ）を管理することができる。装置管理部を用いて、現在接続されたコンパニオン装置の情報が収集され得る。以下に定義された少なくとも１つの情報は装置テーブルに格納される。
【０２１０】
装置管理部が装置テーブルを用いてコンパニオン装置情報を管理する場合、後でコンパニオン装置の状態（ｓｔａｔｕｓ）などを追加及び拡張することができる。
【０２１１】
【表１５】
2016513438.tif 000017
【０２１２】
装置テーブルの管理のために、次の規則が適用される。
【０２１３】
１）新しいコンパニオン装置が利用可能になるとき、テーブル上のエントリーで表現され、ＡｐｐＵＲＩは、最初に、初期化されていない値にセットされる。（例、ｎｕｌｌ  ｖａｌｕｅ、ｅｍｐｔｙ  ｓｔｒｉｎｇ）
【０２１４】
２）コンパニオン装置の利用可能が中止されると、装置を記述したエントリーは無効となる。
【０２１５】
３）コンパニオンアプリケーションが放送ＡＩＴでシグナリングされるとき、装置管理部は、マッチングクラスの装置のためのテーブルを検索する。それぞれのマッチングエントリーに対して対応するＡｐｐＵＲＩを格納し、据え置きＵＲＩであるか否かを確認する。
【０２１６】
４）放送ＡＩＴでシグナリングされるコンパニオンアプリケーションが中止されると、装置管理部は、コンパニオンアプリケーションを参照するエントリーのために装置テーブルを検索し、初期化されていない値にＡｐｐＵＲＩをセットする。
【０２１７】
ＴＶが、放送プログラムと関連するＨｂｂＴＶコンパニオン装置アプリケーションを駆動するためには、プラグインインターフェースが必要である。一実施例として、ＴＶが放送サーバーからＵＲＩを受信する場合について説明する。
【０２１８】
プラグインＡＰＩは、次のようなＭＩＭＥタイプとして認識されるＨｂｂＴＶ客体（ｏｂｊｅｃｔ）で提供され得る。
【０２１９】
MIME Type: appication/hbbtv2.0CompanionScreen
【０２２０】
ＴＶで実行されるＨｂｂＴＶアプリケーションは、リアルタイム放送プログラムと関連するコンパニオン装置アプリケーションが存在する場合、コンパニオン装置アプリケーションをＨｂｂＴＶアプリケーションに知らせることができる（ｎｏｔｉｆｙ）ＡＰＩを必要とする。そして、ＨｂｂＴＶアプリケーションは、ＴＶとペアリング（ｐａｉｒｉｎｇ）されたコンパニオン装置目録を取得し得るＡＰＩも必要とする。また、ＨｂｂＴＶアプリケーションで選定されたコンパニオン装置にＵＲＩを設定するＡＰＩも必要である。
【０２２１】
ＨｂｂＴＶコンパニオンスクリーンプラグイン客体は、次のように定義できる。
【０２２２】
【表１６】
2016513438.tif 000018
【０２２３】
ＴＶで実行されているＨｂｂＴＶアプリケーションは、放送プログラムに応じてコンパニオンスクリーンアプリケーション（またはコンパニオン装置アプリケーション）を含むこともあり、含まないこともある。コンパニオンスクリーンアプリケーションがある場合、ＨｂｂＴＶアプリケーションがｎｏｔｉｆｙを受けることができるプラグイン客体の属性（ｐｒｏｐｅｒｔｙ）の実施例は、次の通りである。
【０２２４】
Function onCompanionScreenAppPresent(CompanionParamList params)
【０２２５】
ＨｂｂＴＶコンパニオンスクリーンプラグイン客体が初期化されるとき、上記の属性を通じて関数が設定され得、コンパニオンスクリーンアプリケーションがある場合、登録された関数がブラウザのプラグインＩ／Ｆによって呼び出され、コンパニオンスクリーンのタイプに合うＡｐｐＵＲＩリストがＣｏｍｐａｎｉｏｎＰａｒａｍＬｉｓｔパラメータとして伝達される。ＣｏｍｐａｎｉｏｎＰａｒａｍＬｉｓｔは、ＡＩＴを介して受け取ることができる。
【０２２６】
【表１７】
2016513438.tif 000019
【０２２７】
表１７は、ｔｙｐｅｄｅｆ  ｃｏｌｌｅｃｔｉｏｎ＜ＣｏｍｐａｎｉｏｎＰａｒａｍ＞ＣｏｍｐａｎｉｏｎＰａｒａｍＬｉｓｔである。
【０２２８】
【表１８】
2016513438.tif 000020
【０２２９】
表１８は、ＣｏｍｐａｉｎｏｎＰａｒａｍ ｃｌａｓｓである。
【０２３０】
本実施例では、装置名、装置タイプ、装置解像度を取得することができる。ＴＶで実行されているアプリケーションは、以下の関数を呼び出してｐａｉｒｅｄ Ｄｅｖｉｃｅ ｌｉｓｔを取得することができ、これをユーザに出力し、ユーザが特定の装置を選択するようにすることができる。
【０２３１】
DeviceList getPairedDeviceList()
【０２３２】
この関数は、ＴＶとペアリングされた装置のリストを取得する。
【０２３３】
【表１９】
2016513438.tif 000021
【０２３４】
表１９は、ｔｙｐｅｄｅｆ ｃｏｌｌｅｃｔｉｏｎ＜Ｄｅｖｉｃｅ＞ＤｅｖｉｃｅＬｉｓｔである。
【０２３５】
【表２０】
2016513438.tif 000022
【０２３６】
表２０は、ペアリングされたコンパニオン装置の個別インスタンスである。
【０２３７】
次は、ＴＶで実行されているアプリケーションが特定の装置にＡｐｐ ＵＲＩを伝達するためのＡＰＩの実施例を示す。ユーザは、１つまたは複数個の装置を同時に指定することができる。
【０２３８】
Boolean setCompanionUrl(DeviceParamList deviceList)
【０２３９】
この関数は、ｄｅｖｉｃｅＩＤで指定されたコンパニオン装置にアプリケーションまたはＵＲＩを伝達する。
【０２４０】
【表２１】
2016513438.tif 000023
【０２４１】
表２１は、ｔｙｐｅｄｅｆ ｃｏｌｌｅｃｔｉｏｎ＜ＤｅｖｉｃｅＰａｒａｍ＞ ＤｅｖｉｃｅＰａｒａｍＬｉｓｔである。
【０２４２】
【表２２】
2016513438.tif 000024
【０２４３】
表２２は、ＤｅｖｉｃｅＰａｒａｍ ｃｌａｓｓである。
【０２４４】
他の実施例として、ＴＶがインターネット上のサーバーからＵＲＩを受信する場合について説明する。すなわち、本実施例は、コンパニオン装置においてＴＶアプリケーションを駆動するためにＴＶブラウザ環境で提供されるプラグインインターフェースに関する。
【０２４５】
プラグインＡＰＩは、次のようなＭＩＭＥタイプとして認識されるＨｂｂＴＶ客体（ｏｂｊｅｃｔ）で提供され得る。
【０２４６】
MIME Type:appication/hbbtv2.0CompanionScreen
【０２４７】
現在接続されたコンパニオン装置情報を通じて、ＨｂｂＴＶアプリケーションは、各コンパニオン装置に該当するＵＲＩを検索できるＡＰＩを必要とする。そして、ＴＶで実行されるＨｂｂＴＶアプリケーションは、リアルタイム放送プログラムと関連するコンパニオン装置アプリケーションが存在する場合、コンパニオン装置アプリケーションをＨｂｂＴＶアプリケーションに知らせることができる（ｎｏｔｉｆｙ）ＡＰＩを必要とする。そして、ＨｂｂＴＶアプリケーションは、ＴＶとペアリング（ｐａｉｒｉｎｇ）されたコンパニオン装置目録を取得し得るＡＰＩも必要とする。また、ＨｂｂＴＶアプリケーションで選定されたコンパニオン装置にＵＲＩを設定するＡＰＩも必要である。
【０２４８】
ＨｂｂＴＶコンパニオンスクリーンプラグイン客体は、次のように定義できる。
【０２４９】
【表２３】
2016513438.tif 000025
【０２５０】
ＴＶで実行されているＨｂｂＴＶアプリケーションは、放送プログラムに応じてコンパニオンスクリーンアプリケーション（またはコンパニオン装置アプリケーション）を含むこともあり、含まないこともある。コンパニオンスクリーンアプリケーションがある場合、ＨｂｂＴＶアプリケーションが通知（ｎｏｔｉｆｙ）を受けることができるプラグイン客体の属性（ｐｒｏｐｅｒｔｙ）の実施例は、次の通りである。
【０２５１】
Function onCompanionScreenAppPresent()
【０２５２】
ＨｂｂＴＶコンパニオンスクリーンプラグイン客体が初期化されるとき、上記の属性を通じて関数が設定され得、コンパニオンスクリーンアプリケーションがある場合、登録された関数がブラウザのプラグインＩ／Ｆによって呼び出される。本実施例では、装置名、装置タイプ、装置解像度を取得することができる。ＴＶで実行されているアプリケーションは、以下の関数を呼び出してｐａｉｒｅｄ Ｄｅｖｉｃｅ ｌｉｓｔを取得することができ、これをユーザに出力し、ユーザが特定の装置を選択するようにすることができる。
【０２５３】
DeviceList getPairedDeviceList()
【０２５４】
この関数は、ＴＶとペアリングされた装置のリストを取得する。ＨｂｂＴＶアプリケーションは、ペアリングされた装置タイプに合うコンパニオンスクリーンアプリケーションＵＲＩをインターネット上のサーバーから取得することができる。
【０２５５】
【表２４】
2016513438.tif 000026
【０２５６】
表２４は、ｔｙｐｅｄｅｆ ｃｏｌｌｅｃｔｉｏｎ＜Ｄｅｖｉｃｅ＞ ＤｅｖｉｃｅＬｉｓｔである。
【０２５７】
【表２５】
2016513438.tif 000027
【０２５８】
表２５は、ペアリングされたコンパニオン装置の個別インスタンスである。
【０２５９】
次は、ＴＶで実行されているアプリケーションが特定の装置にＡｐｐ ＵＲＩを伝達するためのＡＰＩの実施例を示す。ユーザは、１つまたは複数個の装置を同時に指定することができる。
【０２６０】
Boolean setCompanionUrl(DeviceParamList deviceList)
【０２６１】
この関数は、ｄｅｖｉｃｅＩＤで指定されたコンパニオン装置にアプリケーションまたはＵＲＩを伝達する。
【０２６２】
【表２６】
2016513438.tif 000028
【０２６３】
表２６は、ｔｙｐｅｄｅｆ ｃｏｌｌｅｃｔｉｏｎ＜ＤｅｖｉｃｅＰａｒａｍ＞ ＤｅｖｉｃｅＰａｒａｍＬｉｓｔである。
【０２６４】
ＡＩＴを介して伝送されるコンパニオンアプリケーションＵＲＩの最新情報を維持するために、装置管理部は、ＴＶプラットフォームのネイティブ放送受信機ソフトウェアモジュールを登録する。
【０２６５】
装置管理部は、ディスクリプタの新しいコンパニオンアプリケーションＵＲＩを感知するとき、次に従う。
【０２６６】
１）装置管理部は、装置テーブルの全ての有効なエントリー及びディスクリプタによって指摘された同一の装置クラスを有するエントリーを検査し、ディスクリプタで提供される情報に基づいてＡｐｐＵＲＩ及びＩｓＤｅｆｅｒｒｅｄＵＲＩカラムをアップデートする。
【０２６７】
２）装置テーブルとインタラクトするためのＡＰＩ ｃａｌｌを受け入れる準備ができる。
【０２６８】
３）装置管理部は、ＨｂｂＴＶアプリケーションにＤＯＭイベントを伝達する。
【０２６９】
装置管理部は、コンパニオンアプリケーションを利用できる装置に対するＨｂｂＴＶアプリケーションを知らせるために、以下のようなＤＯＭ ３イベントを生成する。ＨｂｂＴＶアプリケーションがこのような情報を利用する方法は、以下で具体的に説明する。
【０２７０】
【表２７】
2016513438.tif 000029
【０２７１】
表２７は、ＷｅｂＩＤＬ ｄｅｆｉｎｔｉｏｎ ｏｆ ｔｈｅ ＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅ ｅｖｅｎｔである。
【０２７２】
このようなイベントのＤＯＭ ３イベントの属性は、次のようにセットされる。
【０２７３】
【表２８】
2016513438.tif 000030
【０２７４】
表２８は、ＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅ ｅｖｅｎｔのためのＤＯＭ ３ ｅｖｅｎｔ ｐｒｏｐｅｒｔｙ ｓｅｔｔｉｎｇｓである。
【０２７５】
ＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅイベントを生成するために、次の規則が適用される。
【０２７６】
１）コンパニオンアプリケーションがＡＩＴを介してシグナリングされ始めるとき、装置管理部は、装置クラスとマッチングされる装置のための装置テーブルを参考する。
【０２７７】
２）マッチングクラスの１つ以上の装置が発見されると、装置管理部は、装置テーブルにそれぞれのＵＲＩを格納し、マッチング装置の名及びクラスを伝送するＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅイベントを生成する。
【０２７８】
３）ＡＩＴを介したコンパニオンアプリケーションのシグナリングが中止されると、装置管理部は、ｎｕｍＤｅｖｉｃｅｓを、コンパニオンアプリケーションがこれ以上動作しないということを示す０にセットするＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅイベントを生成する。
【０２７９】
４）コンパニオンアプリケーションがＡＩＴを介してシグナリングされる間、適当なコンパニオン装置は利用可能となるか、または中止され、装置管理部は、適当なコンパニオン装置のアップデートされたリストを伝送するＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅイベントを生成する。
【０２８０】
コンパニオン装置アプリケーションを利用するためのＨｂｂＴＶアプリケーションは、ＨｂｂｔｖＣｏｍｐａｎｉｏｎＡｐｐＡｖａｉｌａｂｌｅイベントのためのイベントハンドラーを登録する。イベントが生成されると、ＨｂｂＴＶアプリケーションは、コンパニオンアプリケーションを開始できる装置の数、装置のクラス、名に関する情報を受信する。この情報は、コンパニオンアプリケーションを開始したい装置を選択するようにユーザに表示するのに使用され得る。ＨｂｂＴＶアプリケーションは、コンパニオンアプリケーションを開始するか否かを決定した後に特定の装置でアプリケーションを開始するように装置管理部に指示するＡＰＩを使用する。
【０２８１】
【表２９】
2016513438.tif 000031
【０２８２】
表２９は、Ｄｅｖｉｃｅ ｍａｎａｇｅｒ ＡＰＩである。
【０２８３】
装置管理部ＡＰＩを使用する実施例は、以下の通りである。
【０２８４】
【表３０】
2016513438.tif 000032
【０２８５】
launchDefaultUriOnDeviceNamed Method
【０２８６】
【表３１】
2016513438.tif 000033
【０２８７】
この方法が適用される場合、装置管理部は、装置テーブルのＤｅｖＮａｍｅカラムにある装置名を検索する。エントリーが発見されると、ＡｐｐＵＲＩカラムがセットされているか、ＩｓＤｅｆｅｒｒｅｄＵＲＩフラグが空いているかをチェックする。全ての条件が満足されると、装置管理部は、命名されたコンパニオン装置のＡｐｐＵＲＩ状態変数をセットするためにＵＰｎＰメッセージを使用する。
【０２８８】
getDeferredUriForDeviceNamed Method
【０２８９】
【表３２】
2016513438.tif 000034
【０２９０】
この方法が適用される場合、装置管理部は、装置テーブルのＤｅｖＮａｍｅカラムにある装置名を検索する。エントリーが発見されると、ＩｓＤｅｆｅｒｒｅｄＵＲＩフラグがセットされているかをチェックする。全ての条件が満足されると、装置管理部は、ＡｐｐＵＲＩカラムのコンテンツをリターンする。そうでなければ、初期化されていない値をリターンする。
【０２９１】
setDefaultUriForDeviceNamed Method
【０２９２】
【表３３】
2016513438.tif 000035
【０２９３】
この方法が適用される場合、装置管理部は、装置テーブルのＤｅｖＮａｍｅカラムにある装置名を検索する。エントリーが発見されると、装置管理部は、ＡｐｐＵＲＩカラムに与えられたＵＲＩを格納し、以前のコンテンツをリターンする。提供されたあるＵＲＩは据え置きＵＲＩではない。したがって、この方法はＩｓＤｅｆｅｒｒｅｄＵＲＩフラグをクリアする。
【０２９４】
setDisplayIntentForDeviceNamed Method
【０２９５】
【表３４】
2016513438.tif 000036
【０２９６】
この方法が適用される場合、装置管理部は、装置テーブルのＤｅｖＮａｍｅカラムにある装置名を検索する。エントリーが発見されると、装置管理部は、ＤｉｓｐｌａｙＩｎｔｅｎｔカラムの与えられたｉｎｔｅｎｔを格納し、以前のコンテンツをリターンする。提供されるｉｎｔｅｎｔは、ＷｅｂＶｉｅｗ又はＳｙｓｔｅｍＢｒｏｗｅｒのいずれか１つである。もし、Ｗｅｂｖｉｅｗが特定される場合、コンパニオン装置は、コンパニオンアプリケーションに埋め込まれたＷｅｂｖｉｅｗでＵＲＩを開始することができる。他の場合には、コンパニオン装置は、システムの基本Ｗｅｂ ｂｒｏｗｓｅｒでＵＲＩを開始する。
【０２９７】
deviceTableUpdateCompleted Method
【０２９８】
【表３５】
2016513438.tif 000037
【０２９９】
この方法は、ＨｂｂＴＶアプリケーションが装置テーブルのアップデートを完了したことを装置管理部に知らせる。装置管理部は、アップデートされた情報と共に新たなイベントを生成する前に現在のイベントを取り消すために、アプリケーションイベントハンドラーのために短いディレイを許容する。イベントハンドラーは、この方法を呼び出した後、直ちにリターンを呼び出す。新たなイベントは、装置テーブルで非据え置きコンパニオンアプリケーションＵＲＩが有用な全ての装置に対する情報を、ＡＩＴで供給されたように伝達する。
【０３００】
getDeviceCollection Method
【０３０１】
【表３６】
2016513438.tif 000038
【０３０２】
この方法は、ブラウジングのための現在の装置テーブルのｒｅａｄ−ｏｎｌｙ ｃｏｐｙのリターンを知らせる。これは、２つのメンバーを有する−名とクラス。２つともｓｔｒｉｎｇである。名は装置の名を含み、クラスはＨｂｂｔｖＣｏｍｐａｎｉｏｎＣｌａｓｓ ｅｎｕｍタイプの装置クラスを含む。
【０３０３】
ブラウザ（ｂｒｏｗｓｅｒ）とＵＰｎＰとの間には直接的な通信が難しいことがある。したがって、装置管理部（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）は、ブラウザとＵＰｎＰとの間のインタフェーシングの役割を果たすことができる。装置管理部は、ブラウザのＡＰＩを介してＵＰｎＰとブラウザ間の通信中にＤａｅｍｏｎとしてその役割を果たすことができる。Ｄａｅｍｏｎは、ブラウザに含まれてもよいが、ＴＶの内部の一つのモジュールとして独自のｄａｅｍｏｎで具現されてもよい。
【０３０４】
図２４は、本発明の一実施例に係るコンパニオン装置において付加サービスを実行するための信号送信装置のＵＩを説明する図である。
【０３０５】
信号送信装置は、上述したようにコンパニオン装置と接続され、ＡＩＴまたはサーバーからタイプに応じたＵＲＩを受信して装置テーブルを生成することができる。信号送信装置は、放送プログラム内のコンパニオン装置で利用可能な付加サービス（またはコンパニオン装置アプリケーション）があれば、画面に表示することができる。一実施例として、信号送信装置は、利用可能なＨｂｂＴＶアプリケーションがあれば、レッドボタンを表示できる。Ｈｂｂアプリケーションとは、ＴＶで実行されるアプリケーションを意味する。信号送信装置は、利用可能なＨｂｂＴＶコンパニオン装置アプリケーションがあれば、イエローボタンを表示したり、画面の一領域にコンパニオン装置が利用可能であることを表示したりすることができる。ＨｂｂＴＶコンパニオン装置アプリケーションは、コンパニオン装置で実行されるアプリケーションを意味する。
【０３０６】
ユーザがコンパニオン装置アプリケーションの実行を選択すると、信号送信装置は、ディスカバリーされた利用可能なコンパニオン装置リストを表示できる。ユーザが装置Ａを選択すると、信号送信装置は、付加サービスのためにリソースが位置するサーバーのＵＲＩを装置Ａに伝送し、装置Ａが接続されたというメッセージを出力できる。
【０３０７】
装置Ａは、信号送信装置から受信したＵＲＩを用いてサーバーに接続し、付加サービスを実行することができる。
【０３０８】
図２５は、本発明の一実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明する図である。
【０３０９】
信号送信装置（例、ＴＶ）１００上に放送独立的なＨｂｂＴＶアプリケーションをラウンチングするコンパニオン装置２００を承認するために、信号送信装置１００は、図８で説明したＵＰｎＰ状態変数サービスを履行できる。
【０３１０】
図２５には、ＴＶによって提供され得るＵＰｎＰサービスが示されている。コンパニオン装置はＡＩＴを受信できないため、それらは他のメカニズムを使用することができる。
【０３１１】
図２５の構造は、図４で説明した方法とほぼ同一に具現することができる。
【０３１２】
図２６は、本発明の他の実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明する図である。
【０３１３】
図２６は、ＣＰが信号送信装置（例、ＴＶ）１００及びコンパニオン装置２００の両方に存在する場合についての実施例である。
【０３１４】
ＴＶ１００に伝達されるＡｐｐＵＲＩは、ＸＭＬ ＡＩＴまたはＨＴＭＬページを指すことができる。ＴＶ１００は、放送独立的なＨｂｂＴＶアプリケーションのためのラウンチング要求をコンパニオン装置から受信する場合、優先順位及び動作を決定するために一定の規則に従うことができる。
【０３１５】
図２７は、本発明の第１実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明するタイミング図である。
【０３１６】
図２７を参照すると、ＣＰであるＴＶは、ＵＰｎＰ１７を介してコンパニオン装置にマルチキャスト方式を用いて検索（ｄｉｓｃｏｖｅｒｙ）を行ってコンパニオン装置と接続する（Ｓ２１１０）。ＴＶのＵＰｎＰ１７は、コンパニオン装置から装置情報を受信し、装置管理部１５に伝達する（Ｓ２１１５）。装置管理部１５は、装置テーブルでコンパニオン装置情報を管理し、ＨｂｂＴＶアプリケーション１３に、収集されたコンパニオン装置情報を伝達する。ＨｂｂＴＶアプリケーション１３は、収集された各コンパニオン装置のための全てのアプリケーションＵＲＩをサーバー３１から受信する（Ｓ２１２０）。Ｈｂｂアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ２１２５）。
【０３１７】
コンパニオン装置とＴＶはＵＰｎＰを介して接続される。そして、コンパニオン装置とＴＶ間に相互作用のための準備が完了する。
【０３１８】
ユーザが、コンパニオン装置アプリケーションをＴＶに伝達することを選択すると、コンパニオン装置１９は、ＵＰｎＰを介して現在のアプリケーションＵＲＩをＴＶにｎｏｔｉｆｙする（Ｓ２１３０）。ＴＶのＵＰｎＰ１７は、コンパニオン装置の現在のアプリケーションＵＲＩをアプリケーション管理部２３に伝達する（Ｓ２１３５）。アプリケーション管理部２３は、コンパニオン装置の現在のアプリケーションＵＲＩをＨｂｂＴＶアプリケーション１３に伝達する（Ｓ２１４０）。ＨｂｂＴＶアプリケーション１３は、ＴＶでコンパニオン装置の現在のＵＲＩをディスプレイする（Ｓ２１４５）。
【０３１９】
すなわち、ＵＰｎＰを介して、ＣＰであるＴＶは、コンパニオン装置にマルチキャストサーチを送ってディスカバリー作業を進行する。コンパニオン装置に対するディスカバリーが完了すると、ＴＶは、コンパニオン装置に、コンパニオン装置の装置タイプをＧｅｔせよというコントロールを送る。コンパニオン装置は、コントロールに対する応答として装置情報を伝送する。伝送された装置情報は装置管理部の装置テーブルに伝達され、装置管理部は装置ＩＤと装置タイプを管理する。ＴＶとコンパニオン装置との間の接続が完了し、通信準備状態となる。
【０３２０】
ユーザが、コンパニオン装置アプリケーションをＴＶに伝達することを選択すると、コンパニオン装置は、現在のＵＲＩをＵＰｎＰを介してＴＶにｎｏｔｉｆｙする。ＴＶのＵＰｎＰはＵＲＩを受信し、アプリケーション管理部に伝達する。このとき、次の２つの場合が発生し得る。
【０３２１】
まず、ＴＶのＨｂｂＴＶアプリケーションが実行されていない場合、アプリケーション管理部がＨｂｂＴＶアプリケーションをランチさせ、伝達されたＵＲＩをＨｂｂＴＶアプリケーション上で実行させる。
【０３２２】
次に、ＴＶのＨｂｂＴＶアプリケーションが実行されている場合、アプリケーション管理部がＨｂｂＴＶアプリケーションに当該ＵＲＩを伝達し、ユーザに、コンパニオン装置から伝達されたＵＲＩを実行させても良いか否かをポップアップウィンドウなどを用いて確認する。
【０３２３】
一方、装置情報は、コンパニオン装置の機器の種類などに関する情報を含むことができる。ＴＶは、ＵＰｎＰのＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）である。一実施例として、ＨｂｂＴＶ ２．０受信機のＵＰｎＰ装置タイプは、ｕｒｎ：ｈｂｂｔｖ．ｏｒｇ：ｄｅｖｉｃｅ：ｈｂｂｔｖ２．０ｒｃｖｒである。場合によって、Ｎａｍｅｓｐａｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＮＩＤ） ｐｒｅｆｉｘを形成するために、ｈｂｂｔｖ．ｏｒｇのＤＮＳ名は、ＲＦＣ２１４１で要求する通りにｈｂｂｔｖ−ｏｒｇに転換され得る。ｈｂｂｔｖ−ｏｒｇの後の残余部分は、Ｎａｍｅｓｐａｃｅ Ｓｐｅｃｉｆｉｃ Ｓｔｒｉｎｇ（ＮＳＳ）である。ＨｂｂＴＶ ２．０受信機は、以下のようなサービスタイプ及びサービスＩＤを有するＣｕｒｒｅｎｔＵＲＩを支援する。
【０３２４】
【表３７】
2016513438.tif 000039
【０３２５】
ＣｕｒｒｅｎｔＵＲＩサービスは、コンパニオン装置からＣＰであるＴＶに、現在のコンパニオン装置で実行されるアプリケーションのＵＲＩをｎｏｔｉｆｙするためのサービスである。ユーザが選択したコンパニオン装置に該当するＵＲＩをＨｂｂＴＶアプリケーションを介して得て、これを当該コンパニオン装置にＳｅｔ Ｃｏｎｔｒｏｌを介して伝達する。
【０３２６】
【表３８】
2016513438.tif 000040
【０３２７】
表３８は、ＣｕｒｒｅｎｔＵＲＩ ｓｅｒｖｉｃｅ ｓｔａｔｅ ｖａｒｉａｂｌｅである。
【０３２８】
【表３９】
2016513438.tif 000041
【０３２９】
表３９は、ＣｕｒｒｅｎｔＵＲＩ ｓｅｒｖｉｃｅ ａｃｔｉｏｎｓである。
【０３３０】
【表４０】
2016513438.tif 000042
【０３３１】
表４０は、ＳｅｔＣｕｒｒｅｎｔＵＲＩ ａｃｔｉｏｎのＡｒｇｕｍｅｎｔである。
【０３３２】
図２８は、本発明の第２実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行する方法を説明するタイミング図である。
【０３３３】
図２８を参照すると、ＣＰであるコンパニオン装置は、ＵＰｎＰ１７を介してＴＶにマルチキャスト方式を用いて検索（ｄｉｓｃｏｖｅｒｙ）を行って、ＴＶと接続する（Ｓ２２１０）。ＴＶのＵＰｎＰ１７は、コンパニオン装置から装置情報を受信し、装置管理部１５に伝達する（Ｓ２２１５）。装置管理部１５は、装置テーブルでコンパニオン装置情報を管理し、ＨｂｂＴＶアプリケーション１３に、収集されたコンパニオン装置情報を伝達する。ＨｂｂＴＶアプリケーション１３は、収集された各コンパニオン装置のための全てのアプリケーションＵＲＩをサーバー３１から受信する（Ｓ２２２０）。Ｈｂｂアプリケーション１３は、受信したアプリケーションＵＲＩを装置管理部１５に伝達する（Ｓ２２２５）。
【０３３４】
コンパニオン装置とＴＶはＵＰｎＰを介して接続される。そして、コンパニオン装置とＴＶ間に相互作用のための準備が完了する。
【０３３５】
ユーザが、コンパニオン装置アプリケーションをＴＶに伝達することを選択すると、コンパニオン装置１９は、ＵＰｎＰを介して現在のアプリケーションＵＲＩをコンパニオン装置からＴＶに、ＳｅｔアプリケーションＵＲＩという制御信号をＴＶに伝送する（Ｓ２２３０）。ＴＶのＵＰｎＰ１７は、コンパニオン装置の現在のアプリケーションＵＲＩをアプリケーション管理部２３に伝達する（Ｓ２２３５）。アプリケーション管理部２３は、コンパニオン装置の現在のアプリケーションＵＲＩをＨｂｂＴＶアプリケーション１３に伝達する（Ｓ２２４０）。ＨｂｂＴＶアプリケーション１３は、ＴＶでコンパニオン装置の現在のＵＲＩをディスプレイする（Ｓ２２４５）。
【０３３６】
すなわち、ＵＰｎＰを介して、ＣＰであるコンパニオン装置は、ＴＶにマルチキャストサーチを送ってディスカバリー作業を進行する。ＴＶに対するディスカバリーが完了すると、コンパニオン装置は、ＴＶに、コンパニオン装置の装置タイプをＳｅｔせよというコントロールを送る。ＴＶは、Ｓｅｔした装置情報を装置管理部の装置テーブルに伝達し、装置管理部は装置ＩＤと装置タイプを管理する。ＴＶとコンパニオン装置との間の接続が完了し、通信準備状態となる。
【０３３７】
ユーザが、コンパニオン装置アプリケーションをＴＶに伝達することを選択すると、コンパニオン装置は、現在のＵＲＩをＵＰｎＰを介してＴＶにＳｅｔせよというコントロール信号を伝送する。ＴＶのＵＰｎＰはＵＲＩを受信し、アプリケーション管理部に伝達する。このとき、次の２つの場合が発生し得る。
【０３３８】
まず、ＴＶのＨｂｂＴＶアプリケーションが実行されていない場合、アプリケーション管理部がＨｂｂＴＶアプリケーションをランチさせ、伝達されたＵＲＩをＨｂｂＴＶアプリケーション上で実行させる。
【０３３９】
次に、ＴＶのＨｂｂＴＶアプリケーションが実行されている場合、アプリケーション管理部がＨｂｂＴＶアプリケーションに当該ＵＲＩを伝達し、ユーザに、コンパニオン装置から伝達されたＵＲＩを実行させても良いか否かをポップアップウィンドウなどを用いて確認する。
【０３４０】
一方、装置情報は、コンパニオン装置の機器の種類などに関する情報を含むことができる。コンパニオン装置は、ＵＰｎＰのＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）である。一実施例として、ＨｂｂＴＶ ２．０受信機のＵＰｎＰ装置タイプは、ｕｒｎ：ｈｂｂｔｖ．ｏｒｇ：ｄｅｖｉｃｅ：ｈｂｂｔｖ２．０ｒｃｖｒである。場合によって、Ｎａｍｅｓｐａｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＮＩＤ） ｐｒｅｆｉｘを形成するために、ｈｂｂｔｖ．ｏｒｇのＤＮＳ名は、ＲＦＣ２１４１で要求する通りにｈｂｂｔｖ−ｏｒｇに転換され得る。ｈｂｂｔｖ−ｏｒｇの後の残余部分は、Ｎａｍｅｓｐａｃｅ Ｓｐｅｃｉｆｉｃ Ｓｔｒｉｎｇ（ＮＳＳ）である。ＨｂｂＴＶ ２．０受信機は、以下のようなＤｅｖｉｎｆｏサービス及びサービスタイプ及びサービスＩＤを有するＡｐｐＵＲＩサービスを支援する。
【０３４１】
【表４１】
2016513438.tif 000043
【０３４２】
ＣｕｒｒｅｎｔＵＲＩサービスは、ＴＶからＣＰであるコンパニオン装置に、アプリケーションを開始するＵＲＩを伝達するためのサービスである。ユーザが選択したコンパニオン装置に該当するＵＲＩをＨｂｂＴＶアプリケーションを介して受信し、受信したＵＲＩを当該コンパニオン装置にｎｏｔｉｆｙしてＵＰｎＰを介して伝達する。
【０３４３】
【表４２】
2016513438.tif 000044
【０３４４】
表４２は、ＣｕｒｒｅｎｔＵＲＬ Ｓｅｒｖｉｃｅ ｓｔａｔｅ ｖａｒｉａｂｌｅである。
【０３４５】
【表４３】
2016513438.tif 000045
【０３４６】
表４３は、ＣｕｒｒｅｎｔＵＲＬ Ｓｅｒｖｉｃｅ Ａｃｔｉｏｎｓである。
【０３４７】
【表４４】
2016513438.tif 000046
【０３４８】
表４４は、ＮｏｔｉｆｙＣｕｒｒｅｎｔＵＲＬ ａｃｔｉｏｎのＡｒｇｕｍｅｎｔである。
【０３４９】
図２９は、本発明の一実施例に係るコンパニオン装置の付加サービスを信号送信装置で実行するための信号送信装置のＵＩを説明する図である。
【０３５０】
ＴＶとコンパニオン装置はディスカバリー過程を通じて接続を完了し、ＴＶは、コンパニオン装置と関連するアプリケーションＵＲＩを受信して管理することができる。具体的な内容は、図２７及び図２８で説明したので省略する。
【０３５１】
ユーザが、コンパニオン装置アプリケーションをＴＶで実行するように選択する。このとき、ＴＶがＨｂｂＴＶアプリケーションを実行している場合、ユーザに、伝達されたＵＲＩを実行するか否かを確認することができる。ユーザの意思を確認する方法はポップアップウィンドウを利用できる。
【０３５２】
図３０は、本発明の一実施例に係る信号送信装置のブロック図である。
【０３５３】
図３０を参照すると、信号送信装置は、通信部６１０、装置管理部６２０、ＵＰｎＰ部６３０を含む。
【０３５４】
通信部６１０はアプリケーションＵＲＩを受信することができる。アプリケーションＵＲＩは、コンパニオン装置において付加サービス（またはコンパニオン装置アプリケーション）を実行できる接続サーバーの位置情報を意味できる。一方、通信部６１０は放送受信モジュールを含み、放送受信モジュールは、アプリケーションＵＲＩを含むＡＩＴを受信することができる。上述した実施例は、ＣＰがＴＶにある場合であって、図８、図１４乃至図２３で具体的に説明した。そして、ＣＰがコンパニオン装置にある実施例は、図９、図１４乃至図２３で具体的に説明した。
【０３５５】
そして、通信部６１０は、放送受信モジュール及びブラウザモジュールを含むことができる。この場合、放送受信モジュールは、据え置きＵＲＩ（ｄｅｆｅｒｒｅｄ  ＵＲＩ）を含むＡＩＴを受信し、ブラウザモジュールは、ＨｂｂＴＶアプリケーションを介して据え置きＵＲＩに対応するサーバーに接続し、装置タイプ情報に対応するアプリケーションＵＲＩを受信することができる。上述した実施例は、ＣＰがＴＶにある場合であって、図１０、図１５乃至図２３で具体的に説明した。そして、ＣＰと関連するサービスについては図８で説明した。そして、ＣＰがコンパニオン装置にある実施例は、図１１、図１５乃至図２３で具体的に説明した。そして、ＣＰと関連するサービスについては図９で説明した。
【０３５６】
また、通信部６１０はブラウザモジュールを含むことができ、ブラウザモジュールは、ＨｂｂＴＶアプリケーションを介してサーバーと通信を行ってコンパニオン装置アプリケーションを利用可能であるか否かを確認し、ユーザによって選択されたコンパニオン装置の装置タイプ情報に対応するアプリケーションＵＲＩをサーバーから受信して格納することができる。上述した実施例は、ＣＰがＴＶにある場合であって、図１２で具体的に説明した。そして、ＣＰがコンパニオン装置にある実施例は、図１３で具体的に説明した。
【０３５７】
装置管理部６２０は、装置タイプ情報とアプリケーションＵＲＩを対応させて格納し、ユーザによって選択されたコンパニオン装置の装置タイプ情報を確認することができる。装置管理部６２０は、ＡＩＴを介してアプリケーションＵＲＩを受信する場合、受信されたＡＩＴをパージングし、装置タイプ情報に対応するアプリケーションＵＲＩを検出して格納することができる。
【０３５８】
装置管理部６２０を呼び出したり、ＨｂｂＴＶアプリケーションのためのイベントと関連するＡＰＩは、図２３で説明した。
【０３５９】
ＵＰｎＰ部６３０は、マルチキャスト方式を用いてコンパニオン装置をディスカバリーし、ディスカバリーされたコンパニオン装置から装置タイプ情報を受信することができる。この場合は、ＴＶのＵＰｎＰ部６３０がＣＰ（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）として動作する場合である。ＵＰｎＰ部６３０は、装置タイプ情報に対応するアプリケーションＵＲＩを、選択されたコンパニオン装置に伝送することができる。
【０３６０】
コンパニオン装置は、基本ブラウザまたはウェブビューを用いて、受信したアプリケーションＵＲＩページを出力することができる。
【０３６１】
図３１は、本発明の一実施例に係るコンパニオン装置のブロック図である。
【０３６２】
図３１を参照すると、コンパニオン装置は、ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）７１０及びシステムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）７２０を含むことができる。ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）７１０は、ウェブビュー（Ｗｅｂ  Ｖｉｅｗ）７１１及びＵＰｎＰ７１２を含むことができる。
【０３６３】
ネイティブアプリケーション部（Ｎａｔｉｖｅ  Ａｐｐ）７１０は、コンパニオン装置上で駆動され、ＵＰｎＰ動作を提供することができる。そして、コンパニオンアプリケーションをローディングし、駆動し得るウェブビューを提供することができる。
【０３６４】
システムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）７２０は、コンパニオン装置上で駆動され、コンパニオン装置で設定される標準ウェブブラウザであり得る。ネイティブアプリケーション部７１０によって選択的に提供され得るウェブビュー７１１とは異なり、システムウェブブラウザ部（Ｓｙｓｔｅｍ  Ｗｅｂ  Ｂｒｏｗｓｅｒ）７２０は、一般的なウェブ用途に適した一般のウェブブラウザであり得る。
【０３６５】
ＵＰｎＰ７１２は、信号送信装置のＵＰｎＰ部と接続されて通信を行うことができ、ウェブビュー（Ｗｅｂ  Ｖｉｅｗ）７１１は、接続されたＵＲＩのサーバーで提供する付加サービスを表示することができる。
【０３６６】
一方、上述した様々な実施例から特性を結合するとき、ＵＰｎＰ ＣＰの位置に応じて、そして、アクセス状態変数のためのサービスの位置に応じていくつかの結合が可能であり得る。相互運用の最小レベル及びユーザ経験を保障するために、全てのＴＶと全てのコンパニオン装置は、以下に定義されたプロファイルのいずれか１つを履行する。
【０３６７】
【表４５】
2016513438.tif 000047
【０３６８】
このようなプロファイルを有し、以下のような機能が可能であり得る。
【０３６９】
【表４６】
2016513438.tif 000048
【０３７０】
基本的に、ＵＰｎＰプロトコルはいかなる認証も履行されないので、ＵＰｎＰ装置の実施は、自体認証メカニズムを履行したり、装置保護サービスを履行したりすることができる。多くのＵＰｎＰ装置の実施は認証メカニズムが不足し、基本的にローカルシステムとユーザは完全に信頼できると仮定する。ＵＰｎＰの特定の保安プロファイル権限は、厳しく相互運用を制限する。
【０３７１】
本発明に係る信号送信装置及び方法は、上記したように説明された実施例の構成と方法が限定されて適用されるものではなく、上記実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
【０３７２】
また、以上では、本発明の好ましい実施例について図示し、説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者によって、様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
【産業上の利用可能性】
【０３７３】
本発明は、放送及びビデオ信号処理の分野で使用可能であり、反復可能性のある産業上の利用可能性がある。
【図１】
2016513438.tif 000049
【図２】
2016513438.tif 000050
【図３】
2016513438.tif 000051
【図４】
2016513438.tif 000052
【図５】
2016513438.tif 000053
【図６】
2016513438.tif 000054
【図７】
2016513438.tif 000055
【図８】
2016513438.tif 000056
【図９】
2016513438.tif 000057
【図１０】
2016513438.tif 000058
【図１１】
2016513438.tif 000059
【図１２】
2016513438.tif 000060
【図１３】
2016513438.tif 000061
【図１４】
2016513438.tif 000062
【図１５】
2016513438.tif 000063
【図１６】
2016513438.tif 000064
【図１７】
2016513438.tif 000065
【図１８】
2016513438.tif 000066
【図１９】
2016513438.tif 000067
【図２０】
2016513438.tif 000068
【図２１】
2016513438.tif 000069
【図２２】
2016513438.tif 000070
【図２３】
2016513438.tif 000071
【図２５】
2016513438.tif 000072
【図２６】
2016513438.tif 000073
【図２７】
2016513438.tif 000074
【図２８】
2016513438.tif 000075
【図３０】
2016513438.tif 000076
【図３１】
2016513438.tif 000077
【図２４】
2016513438.tif 000078
【図２９】
2016513438.tif 000079
【国際調査報告】
2016513438.tif 000080
2016513438.tif 000081
2016513438.tif 000082
2016513438.tif 000083