(57)【特許請求の範囲】
【請求項１】
マルチメディアシステムにおけるデバイス間の通信方法であって、
第１のデバイスが、第２のデバイスのウェブサーバの終端点情報を獲得するステップと、ここで、前記第１のデバイスは、前記第２のデバイスと通信するための補助デバイス（companion device）であり、前記第２のデバイスは、ネットワークを通して放送サービス又はコンテンツのうちの少なくとも一つを受信するためのプライマリデバイス（primary device）であり、
前記第１のデバイスが、前記ウェブサーバの終端点情報に基づいて、前記第２のデバイスのウェブソケットサーバの終端点情報を獲得するステップと、
前記第１のデバイスが、前記ウェブソケットサーバの終端点情報に基づいて、前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報の変更に対する通知を受信するためのリクエストを前記第２のデバイスに伝送するステップと、
前記第１のデバイスが、前記通知を前記第２のデバイスから受信するステップと、
前記第１のデバイスが、前記通知に基づいて、変更された第１の情報を獲得するステップと、
を含むことを特徴とする通信方法。
【請求項２】
前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報は、通信プロトコルを利用して受信され、
前記通信プロトコルは、ＨＴＴＰ（Hypertext Transfer Protocol）プロトコル及びウェブソケットプロトコルのうちの少なくとも一つを含むことを特徴とする請求項１に記載の通信方法。
【請求項３】
前記第１のデバイスは、前記第１のデバイスと前記第２のデバイスとの間のアプリケーション間（app-to-app）の通信を利用することなく、前記第２のデバイスから前記ウェブソケットサーバの終端点情報を受信することを特徴とする請求項１に記載の通信方法。
【請求項４】
前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報は、前記放送サービス又は前記コンテンツの接続のためのアドレス情報をさらに含むことを特徴とする請求項１に記載の通信方法。
【請求項５】
前記第１のデバイスが前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報の変更に対する通知を受信するためのリクエストに対する結果を示すコード情報を前記第２のデバイスから受信するステップをさらに含むことを特徴とする請求項１に記載の通信方法。
【請求項６】
マルチメディアシステムにおけるデバイス間の通信を実行する第１のデバイスであって、
送受信器と、
前記送受信器に接続された（coupled with）制御部と、を含み、
前記制御部は、
第１のデバイスが、第２のデバイスのウェブサーバの終端点情報を獲得し、ここで、前記第１のデバイスは、前記第２のデバイスと通信するための補助デバイス（companion device）であり、前記第２のデバイスは、ネットワークを通して放送サービス又はコンテンツのうちの少なくとも一つを受信するためのプライマリデバイス（primary device）であり、
前記第１のデバイスが、前記ウェブサーバの終端点情報に基づいて、前記第２のデバイスのウェブソケットサーバの終端点情報を獲得し、
前記第１のデバイスが、ウェブソケットサーバの終端点情報に基づいて、前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報の変更に対する通知を受信するためのリクエストを前記第２のデバイスに伝送し、
前記第１のデバイスが、前記通知を前記第２のデバイスから受信し、
前記第１のデバイスが、前記通知に基づいて、変更された第１の情報を獲得することを特徴とする第１のデバイス。
【請求項７】
前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報は、通信プロトコルを利用して受信され、
前記通信プロトコルは、ＨＴＴＰ（Hypertext Transfer Protocol）プロトコル及びウェブソケットプロトコルのうちの少なくとも一つを含むことを特徴とする請求項６に記載の第１のデバイス。
【請求項８】
前記第１のデバイスは、前記第１のデバイスと前記第２のデバイスとの間のアプリケーション間（app-to-app）の通信を利用することなく、前記第２のデバイスから前記ウェブソケットサーバの終端点情報を受信することを制御することを特徴とする請求項６に記載の第１のデバイス。
【請求項９】
前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報は、前記放送サービス又は前記コンテンツの接続のためのアドレス情報をさらに含むことを特徴とする請求項６に記載の第１のデバイス。
【請求項１０】
前記第１のデバイスが前記放送サービス又は前記コンテンツのうちの少なくとも一つの使用のための第１の情報の変更に対する通知を受信するためのリクエストに対する結果を示すコード情報を前記第２のデバイスから受信することをさらに制御することを特徴とする請求項６に記載の第１のデバイス。
【請求項１１】
前記第２のデバイスのウェブソケットサーバの終端点情報は、アプリケーション関連ＵＲＬ情報であることを特徴とする請求項１に記載の通信方法。
【請求項１２】
前記第２のデバイスのウェブソケットサーバの終端点情報はアプリケーション関連ＵＲＬ情報であることを特徴とする請求項６に記載の第１のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアシステムにおけるデバイス間において、放送サービス、コンテンツ関連情報など各種情報を送受信する方法及び装置に関する。
【背景技術】
【０００２】
マルチメディアサービスを提供する放送システムの発展によって、有線又は無線放送システムにおいて、複数のデバイスが相互に通信して放送サービスを利用できる技術が開発されている。一例として、宅内に設置されたデジタルＴＶと、スマートフォン、タブレットなどの携帯端末とが相互に通信することにより、ユーザがデジタルＴＶで視聴していたコンテンツを携帯端末で継続して視聴するか、又は、携帯端末でユーザが視聴していたコンテンツをＴＶで継続して視聴できるマルチスクリーンサービスなどが提供されている。
【０００３】
以下、本明細書では、上記のデジタルＴＶ又はデジタルＴＶと接続したセットトップボックス(ＳＴＢ)などを、放送サービス又はコンテンツの利用のためのプライマリデバイス(Primary Device:ＰＤ)と称し、上記の携帯端末などを、放送サービス又はコンデンツの利用のための補助デバイス(Companion Device:ＣＤ)と称する。
【０００４】
図１は、マルチスクリーンサービスをサポートする一般的なマルチメディアシステムの例を簡略に示す図である。
【０００５】
図１を参照すれば、ＰＤ １１０は、地上波放送、ケーブル放送などの各種放送サービスを有線又は無線で受信することができる。ＰＤ １１０には、放送サービスの利用に関連する各種アプリケーション１１１がインストールされてもよく、マルチスクリーンサービスなどのためにＣＤ １３０と通信するためのＣＳ(Companion Screen)マネージャ１１３が含まれていてもよい。また、ＣＤ １３０にも、放送サービスの利用に関連する各種アプリケーション１３１がインストールされてもよい。図１において、ＰＤ １１０とＣＤ １３０は、説明の便宜上一つだけ図示したが、一つ又は複数のＰＤ、ＣＤが存在してもよい。ＰＤ １１０とＣＤ １３０は、ＷｉＦｉなどの各種無線又は有線通信方式を通して相互に通信できる。
【０００６】
図１において、（参照符号１０１にて示されるように、）ＣＤ １３０は、アプリケーション１３１の実行によって、マルチスクリーンサービスの利用のために使用可能なＰＤ １１０が存在するか否かを探索する。使用可能なＰＤ １１０が発見された場合、（参照符号１０３にて示されるように、）ＣＤ １３０のアプリケーション１３１は、ＰＤ １１０のアプリケーション１１１を起動するために、ＣＳマネージャ１１３と通信する。ＣＳマネージャ１１３は、（参照符号１０５にて示すように、）ＰＤ １１０のアプリケーション１１１を起動させる。上記した動作において述べたように、ＰＤ １１０とＣＤ １３０は、アプリケーション１１１、１３１を通して、マルチスクリーンサービスの利用のために必要なデータをやり取りする。図１のマルチメディアシステムは、ＰＤ １１０とＣＤ １３０において各々アプリケーション１１１、１３１が起動され、アプリケーション間の通信を通して必要な情報をやり取りするアプリケーション中心のモデルに適している。
【０００７】
しかし、図１のシステムで、ＰＤ １１０のアプリケーション１１１がマルチメディアシステムを通して提供されないか、又は、アプリケーション１１１を起動できない場合、ＣＤ １３０のアプリケーション１３１だけが起動されるので、ＰＤ １１０とＣＤ １３０でアプリケーション間の通信が行われない。この場合、ＰＤ １１０では、アプリケーション間の通信のための関連アプリケーションを起動できなくなる可能性があるので、ＰＤ １１０とＣＤ １３０を利用したマルチスクリーンサービスなどを安定的に提供することができなくなる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、マルチメディアシステム内のデバイス間において効率的に情報を送受信するための通信方法及び装置を提供する。
【０００９】
また、本発明は、マルチメディアシステムのＰＤがアプリケーションを起動することなく、ＰＤとＣＤと間で放送関連情報を送受信する方法及び装置を提供する。
【課題を解決するための手段】
【００１０】
本発明の実施形態によるマルチメディアシステム内のデバイス間の通信方法は、第１のデバイスが放送サービス又はコンテンツの利用のための第２のデバイスを探索するステップと、第１のデバイスが第２のデバイスから放送サービス又はコンテンツに関連する第１の情報を受信するための少なくとも一つのサービス終端点に対する第２の情報を取得するステップと、第１のデバイスが第２の情報を利用して、放送サービス又はコンテンツに関連する第１の情報の伝送をリクエストするステップと、リクエストに応じて、第１のデバイスが第２のデバイスから第１の情報を受信するステップと、を含む。
【００１１】
また、本発明の実施形態によるマルチメディアシステム内のデバイス間の通信を実行する第１のデバイスは、放送サービス又はコンテンツの利用のための第２のデバイスと通信するための通信インターフェースと、通信インターフェースを通して第２のデバイスを探索し、第２のデバイスから放送サービス又はコンテンツに関連する第１の情報を受信するための少なくとも一つのサービス終端点に対する第２の情報を取得し、第２の情報を利用して、放送サービス又はコンテンツに関連する第１の情報の伝送をリクエストし、リクエストに応じて、第２のデバイスから第１の情報を受信することを制御する制御部と、を含む。
【図面の簡単な説明】
【００１２】
【図１】マルチスクリーンサービスをサポートする一般的なマルチメディアシステムの例を簡略に示す図である。
【図２】相互に通信するデバイスを含む本発明の実施形態に係るマルチメディアシステムの構成を示す図である。
【図３】本発明の実施形態に係るマルチメディアシステムにおいて、デバイス間の通信を通してＰＤ状態情報を送受信する方法を示す図である。
【図４】本発明の実施形態においてＰＤ状態情報をリクエストする方法を選択する手順を説明する図である。
【図５】本発明の実施形態においてウェブソケットプロトコルを利用してリクエストに対するＰＤの応答を処理する手順を説明する図である。
【図６】本発明の実施形態においてデバイス間の通信を通してＰＤ状態情報を送受信する動作を示す図である。
【発明を実施するための形態】
【００１３】
本発明の実施形態の以下の説明において、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にすると判定される場合には、その詳細な説明を省略する。
【００１４】
以下に説明される本発明の実施形態は、複数のデバイスが接続されているマルチメディアシステムにおけるマルチスクリーンサービスを提供する場合、放送を受信して再生しているプライマリデバイス(例えば、ＰＤ)が、再生中の放送関連情報を補助デバイス(例えば、ＣＤ)に提供する方法を提案する。上記ＰＤ、ＣＤは、デバイス間の通信を通して、放送サービス、放送コンテンツの受信のために必要な情報、公共情報、又は、放送プログラム情報など(以下、上記放送関連情報)を送受信できるプライマリデバイスと補助デバイスを通称する意味として理解される。上記ＰＤとＣＤは、各々一つ又は複数個存在できる。
【００１５】
一例として、上記ＰＤは前述したようにデジタルＴＶ、ＳＴＢであってもよく、上記ＣＤはスマートフォン、タブレットなどの携帯端末であってもよい。他の例において、複数のデジタルＴＶがＰＤ又はＣＤとして動作し、複数の携帯端末がＰＤ又はＣＤとして動作できる。本発明の実施形態において、ＣＤとの通信のためのアプリケーションが起動しない（又は、提供されない）ＰＤで再生中の放送サービス又は放送コンテンツなどに対する上記放送関連情報をＣＤがＰＤに直接リクエストし、そのリクエストに応じて、ＰＤがＣＤに上記放送関連情報を提供する具体的な方法を提供する。本発明の実施形態では、ＰＤのアプリケーションの起動がなくても、ＣＤのアプリケーションは、ＰＤから上記放送関連情報を受信してユーザにＰＤから提供される放送サービスなどをユーザに提供できる。本発明の実施形態において、上記放送関連情報は、ＰＤで再生中の放送サービス又は放送コンテンツなどに対する識別子、データ、再生情報、アラーム情報などの各種状態情報であるので、上記放送関連情報を以下ＰＤ状態情報（又は「ＰＤのサービス及び／又はコンテンツに関連する情報」）と称する。上記ＰＤ状態情報は、例えば、放送サービス又はコンテンツの識別情報（コンテンツＩＤ（ＣＩＤ））、ＥＳＧ(Electronic Service Guide)情報、メディアデータ、メディアタイムライン(time line)情報、メディア再生情報(play back)、また緊急アラーム(Emergency Alert)情報(emergency alert message:eam)のうちの少なくとも一つを含んでもよい。
【００１６】
図２は、相互に通信するデバイスを含む本発明の実施形態に係るマルチメディアシステムの構成を示す図である。
【００１７】
図２を参照すれば、ＰＤ ２１０は、アプリケーション２１１、ＣＳマネージャ２１３、ＷＳ(Web Socket)サーバ/Ｗｅｂサーバ２１５、ＥＳＧハンドラ/メディア再生部２１７を含み、ＣＤ ２３０は、ＰＤ ２１０に上記ＰＤ状態情報をリクエストして受信するためのアプリケーション２３１を含む。ＣＤ ２３０は、上記ＰＤ状態情報を利用してＰＤ ２１０で再生中の放送サービス又は放送コンテンツなどをユーザに提供できる。
【００１８】
ＰＤ ２１０の構成を示す図２において、アプリケーション２１１は、放送サービス又は放送コンテンツに関連する各種アプリケーションとできる。また、アプリケーション２１１は、図１で説明したアプリケーション１１１と同様の方法にて、ＣＤ ２３０とアプリケーション間の通信を実行できる。したがって、アプリケーション２１１は、本発明の実施形態においては必須構成ではなく、選択的にＰＤ ２１０に含まれてもよい。ＣＳマネージャ２１３は、ＰＤ ２１０とＣＤ ２３０との間の連動のための動作を実行する。上記動作は、ＣＤ ２３０から受信した使用可能なＰＤの探索リクエスト２０１に対する応答と、ＣＤ ２３０からアプリケーション２１１の起動リクエストに対する処理、また、本発明の実施形態によってＣＤ ２３０からＷＳ(ウェブソケット)サーバ/Ｗｅｂサーバ２１５を通して上記ＰＤ状態情報のリクエスト２０３を受信した場合にＥＳＧハンドラ/メディア再生部２１７から上記ＰＤ状態情報(すなわち、ＰＤのサービス及び/又はコンテンツに関連する情報)の伝達を受けてＣＤ ２３０に提供する動作とのうちの少なくとも一つを含む。
【００１９】
図２の実施形態で、ＷＳサーバ／Ｗｅｂサーバ２１５は、ＣＤ ２３０との通信のための通信インターフェースとして利用され、ＣＳマネージャ２１３と分離された構成要素で図示されているが、他の実現例で、ＣＳマネージャ２１３がＷＳサーバ／Ｗｅｂサーバ２１５を含むことも可能である。ＷＳサーバ／Ｗｅｂサーバ２１５は、ＣＤ ２３０との双方向通信のためにウェブソケットプロトコルを利用できる。この場合、ウェブソケットプロトコルを利用して、ＣＤ ２３０に上記ＰＤ状態情報(すなわち、ＰＤのサービス及び／又はコンテンツに関連する情報)を伝送する。上記ウェブソケットプロトコルは、ＷＳサーバで処理される。また、ＷＳサーバ／Ｗｅｂサーバ２１５は、ＨＴＴＰプロトコルを利用して、ＣＤ ２３０に上記ＰＤ状態情報(すなわち、ＰＤのサービス及び/又はコンテンツに関連する情報)を伝送する。上記ＨＴＴＰプロトコルは、Ｗｅｂサーバで処理される。図２のＥＳＧハンドラ/メディア再生部２１７において、ＥＳＧハンドラは、放送プログラムに載せられて伝送されたＥＳＧを処理し、上記ＰＤ状態情報の提供２０５のために、ＣＳマネージャ２１３からリクエストされた少なくとも一つの情報をＣＳマネージャ２１３又はＷＳサーバ／Ｗｅｂサーバ２１５に送信する。ＥＳＧハンドラ/メディア再生部２１７において、メディア再生部は、放送プログラムを再生し、上記ＰＤ状態情報の提供２０５のために、ＣＳマネージャ２１３からリクエストされた少なくとも一つの情報をＣＳマネージャ２１３又はＷＳサーバ／Ｗｅｂサーバ２１５に送信する。
【００２０】
図２で例示されたＰＤ ２１０とＣＤ ２３０の構成は、機能ブロックの形態にて示された一実現例に対応する。ＰＤ ２１０は、ＣＳマネージャ２１３とＥＳＧハンドラ/メディア再生部２１７の機能を担当する少なくとも一つのプロセッサ(すなわち、制御部)と、ＷＳサーバ／Ｗｅｂサーバ２１５の機能を担当する通信インターフェースと、アプリケーション２１１がインストールされる記憶部と、を含んでもよい。ＰＤ ２１０のアプリケーション２１１は、前述したように選択的な構成要素であるので、省略されてもよい。また、ＣＤ ２３０は、アプリケーション２３１がインストールされる記憶部と、ＰＤ ２１０との通信のための通信インターフェースと、アプリケーション２３１の起動と上記ＰＤ状態情報のリクエスト及び受信のための全般的な動作を制御する制御部と、を含んでいてもよい。
【００２１】
一方、図２の例においては、ＷＳサーバ／Ｗｅｂサーバ２１５をＷＳサーバとＷｅｂサーバとを含む１つのブロックとして表し、ＥＳＧハンドラ/メディア再生部２１７をＥＳＧハンドラとメディア再生部とを含む１つのブロックとして表した。しかし、これは、説明の便宜のために関連構成要素を一つのブロックとして図示したものである。上記ＷＳサーバとＷｅｂサーバは、分割されたブロックで実現されてもよく、上記ＳＧハンドラとメディア再生部も、分割されたブロックで実現されてもよい。
【００２２】
図３は、本発明の実施形態に係るマルチメディアシステムにおいて、デバイス間の通信を通してＰＤ状態情報を送受信する方法を示す図である。
【００２３】
図３を参照すれば、ステップ３０１において、ユーザのキー操作などによりＣＤ ２３０のアプリケーション２３１が起動されると、ステップ３０３において、ＣＤ ２３０は、ネットワークで使用可能なＰＤが存在しているか否かを探索する。この探索過程は、ＳＳＤＰ(Simple Service Discovery Protocol)やＤＩＡＬ(Discovery and Launch Protocol）を典型的に使用してもよく、実装の方式によっては他のプロトコルが使用されてもよい。ＰＤ ２１０とＣＤ ２３０は、ＷｉＦｉ、ブルートゥース（登録商標）、ＮＦＣ(Near Field Communication)などの各種無線通信又は有線通信ネットワークにより通信を実行できる。ステップ３０５において、ＰＤ ２１０のＣＳマネージャ２１３は、ＣＤ ２３０の探索リクエストに応答する。この場合、その応答としてＰＤ ２１０がＣＤ ２３０に伝送する情報は、ＰＤ ２１０に関する情報、ＣＤ ２３０がＰＤ ２１０にＰＤ状態情報をリクエストできるサービス終端点(service  endpoint）の情報(例えば、ＰＤ状態情報を受信するのに利用されるＵＲＬ情報など)のうちの少なくとも一つを含む。上記サービス終端点の情報提供方法は後述する。上記サービス終端点は、例えば、Ｗｅｂサーバのサービス終端点とＷＳサーバのサービス終端点のうちの少なくとも一つを含む。
【００２４】
ステップ３０７において、ＣＤ ２３０は、上記サービス終端点の情報を利用して、ＰＤ ２１０にＰＤ状態情報(すなわち、ＰＤのサービス及び／又はコンテンツに関連する情報)をリクエストする。上記ＰＤ状態情報のリクエストは、HTTP GET Method又はウェブソケットを通して実行してもよく、上記ＰＤ状態情報は、上記したように、例えば、放送サービス又はコンテンツの識別情報（ＣＩＤ）、ＥＳＧ情報、メディアデータ、メディアタイムライン(time line)情報、メディア再生情報(play back)、緊急アラーム(Emergency Alert)情報(eam)のうちの少なくとも一つを含むことができる。ステップ３０９において、上記ＰＤ状態情報のリクエストは、ＷＳサーバ／Ｗｅｂサーバ２１５により受信され、該当情報を処理する機能ブロックであるＥＳＧハンドラ/メディア再生部２１７に送信される。上記該当情報が緊急アラーム情報である場合、上記機能ブロックは、緊急アラーム情報を処理する緊急アラームマネジャーとできる。ステップ３１１において、ＥＳＧハンドラ/メディア再生部２１７又は緊急アラームマネジャーで処理された情報は、ＷＳサーバ／Ｗｅｂサーバ２１５に送信され、ステップ３１３において、ＷＳサーバ／Ｗｅｂサーバ２１５は、送信された情報を含むＰＤ状態情報をＣＤ ２３０に伝送する。また、上記ＰＤ状態情報のリクエスト受信、また上記ＰＤ状態情報の送信のための制御は、ＣＳマネージャ２１３にて実行できる。また、上記ＰＤ状態情報は、予め定められた状態コードと共に伝送できる。上記状態コードは、上記ＰＤ状態情報に含まれた各情報に対応するように設定できる。
【００２５】
以下、本発明の実施形態で実行される使用可能なＰＤの探索及びサービス終端点情報の提供方法について具体的に説明する。
【００２６】
１．まず、ＣＤ ２３０のアプリケーション２３１(以下、ＣＤアプリケーション）は、次の＜表１＞のような特定ＳＴ(Search Target)ヘッダ情報を含むＳＳＤＰプロトコルを使用して、ネットワーク内において使用可能なＰＤの検索をリクエストする。
【００２７】
【表１】
0006728218.tif 000002
２．ＳＳＤＰリクエストを受信したＰＤ ２１０は、以下の＜表２＞のようなロケーションヘッダを含むＨＴＴＰ／１．１応答を伝送する。この場合、ロケーションヘッダには、ＰＤ ２１０のデバイスディスクリプションファイルをリクエストできる情報が含まれてもよい。
【００２８】
【表２】
0006728218.tif 000003
３．使用可能なＰＤ ２１０から応答を受信したＣＤアプリケーションは、上記２番目のステップで受信したロケーション情報を用いて、下記＜表３＞のようなＰＤのデバイスディスクリプションファイルをリクエストするリクエストを送信する。
【００２９】
【表３】
0006728218.tif 000004
４．ＰＤ ２１０は、デバイスディスクリプションファイルと共に以下の＜表４＞のようなApplication-URLヘッダを応答として送信する。
【００３０】
【表４】
0006728218.tif 000005
５．ＣＤアプリケーションは、上記４番のステップで受信したApplication-URL情報を用いて、サービス終端点情報を、以下の＜表５＞のようにリクエストする。ここで、Application-URLの最後についた‘Hbb TV(Hybrid broadcast broadband ＴＶ)'は、一つの実施形態において、本発明の実装によって変形されてもよい。
【００３１】
【表５】
0006728218.tif 000006
６．ＰＤ ２１０は、以下の＜表６＞に示す情報をＨＴＴＰ/1．1 ＯＫヘッダを共に含むボディとして用いて、上記リクエストに対して応答する。本発明では、ＸＭＬ(Extensible Markup Language）を用いる構成の例を提示したが、実装によって、ＪＳＯＮ(Java Script（登録商標） Object Notation)などのＨＴＴＰ応答のボディに載せて送られるテキストベースのいかなるフォーマットも使用可能である。下記＜表６＞の例において＜X_HbbＴＶ_App2AppURL＞は、ウェブソケット（ＷＳ）サーバのサービス終端点を提供するために使用され、残りの＜X_HbbＴＶ_InterDevSyncURL＞と＜X_HbbＴＶ_UserAgent＞情報は、実装によっては使用されないこともある。本発明の実施形態では、２個の情報(すなわち、＜X_HbbＴＶ_InterDevSyncURL＞、＜X_HbbＴＶ_UserAgent＞）は使用しない。同様に、実装の方式によって追加的な情報提供が必要な場合には、フィールドを新しく定義して使用できる。
【００３２】
【表６】
0006728218.tif 000007
上記した実施形態において説明したＰＤの探索及びサービス終端点情報の提供方法により、ＨＴＴＰ ＧＥＴリクエストを送信できるウェブサーバの終端点情報を４番のステップにおいて取得し、ウェブソケットサーバの終端点情報を６番のステップにおいて取得してもよい。
【００３３】
一方、図３のステップ３０７におけるＰＤ状態情報のリクエストについて詳細に説明する。上記ＰＤ状態情報(すなわち、ＰＤのサービス及び/又はコンテンツに関連する情報）には、下記＜表７＞に例示された情報のうちの少なくとも一つを含めることができる。
【００３４】
【表７】
0006728218.tif 000008
上記ＰＤ状態情報に含めることができるそれぞれの情報は、情報がリクエストされる頻度及び通信方式(例えば、双方向性が必要か不要か)に基づいて、ＨＴＴＰ ＧＥＴやウェブソケットプロトコルを使用した２種の方式に従ってリクエストできる。＜表７＞ではこの２種の方式を例示したが、他の方式を利用することも可能である。
【００３５】
まず、ＨＴＴＰ ＧＥＴによるＰＤ状態情報のリクエスト方法を説明する。
【００３６】
ＨＴＴＰリクエストを送信すべきサービス終端点は、上記＜表４＞で取得したApplication-URLを使用できる。この場合、所望のＰＤの状態情報と他の状態情報とを区別するために、Application-URLに上記＜表７＞で例示した状態情報ＩＤを付して送信できる。例えば、サービス及びコンテンツＩＤ情報をリクエストするためのＨＴＴＰ ＧＥＴリクエストの一例を、以下の＜表８＞に示す。
【００３７】
【表８】
0006728218.tif 000009
ＨＴＴＰ  ＧＥＴに対するＰＤの応答は、ＨＴＴＰ状態コードとボディに含まれた状態で送信されてもよい。
【００３８】
当該応答の一例を下記の＜表９＞乃至＜表１２＞に示す。当該表に示された応答の一例は、ＨＴＴＰリクエストに対するＰＤ状態情報の応答の一実装例を示す。＜表９＞乃至＜表１２＞の例は、ＸＭＬにより構成する例を示すが、これも実装によってＪＳＯＮなどＨＴＴＰ応答のボディに載せて送信できるテキストベースのいかなるフォーマットも使用できる。また、含まれるそれぞれのフィールドも実装によって変更してもよい。
【００３９】
【表９】
0006728218.tif 000010
【００４０】
【表１０】
0006728218.tif 000011
【００４１】
【表１１】
0006728218.tif 000012
【００４２】
【表１２】
0006728218.tif 000013
上記＜表１０＞は、上記＜表９＞の“service”フィールドに含まれる情報の一構成例を示し、上記＜表１1＞は、上記＜表９＞の“playbackState”フィールドに含まれる情報の一構成例を示す。また、上記＜表１２＞は、上記＜表９＞の“ＥＡＭ”フィールドに含まれる情報の一構成例を示す。
【００４３】
上記＜表９＞のそれぞれのフィールドは、以下の意味を有する。
【００４４】
＜deviceID＞:ＰＤ状態情報を伝送したＰＤのdeviceＩＤを記述する。
【００４５】
＜seviceType＞:ＰＤ状態情報の種類を表す。ＰＤ状態情報に含まれ得る値としては、contentID、esg、timeLine、playbackState、ＥＡＭなどがある。
【００４６】
＜service＞:現在のＰＤにて提供中の(起動中の)サービスの情報を含む。＜service＞の下位フィールドの構成は＜表１０＞と同一である。
【００４７】
＜esg＞:ＥＳＧ情報を表す。
【００４８】
＜timeline＞:現在提供中のサービスのメディアタイムライン情報を含む。上記タイムライン情報は、ＵＴＣ  Ｔｉｍｅ(すなわち、国際標準時)として記述される。このタイムライン情報は、同一デバイス内の複数のサービスを同期させるため、又は、複数のデバイス間でサービスを同期させるために使用される。
【００４９】
＜playbackState＞:現在提供中のサービスの再生状態情報を含む。＜playbackState＞の下位フィールドの構成を＜表１１＞に示す。
【００５０】
＜ＥＡＭ＞:Emergency Alert Messageを含む。ＥＡＭは、＜表８＞又は＜表１０＞のＣＤアプリケーションによりＰＤにリクエストを送信する過程を経ることなく、ＰＤからＣＤアプリケーションへ伝送されてもよい。上記＜ＥＡＭ＞の下位フィールドの構成を＜表１２＞に示す。
【００５１】
上記＜表１０＞に含まれるフィールドは、以下の意味を有する。
【００５２】
＜serviceName＞:ＰＤで提供中のサービスの名(テキスト）を含む。
【００５３】
＜serviceID＞:ＰＤで提供中のサービスのＩＤを含む。
【００５４】
上記＜表１1＞に含まれるフィールドは、以下の意味を有する。
【００５５】
＜MPState＞:提供中のサービスの再生状態情報を表す。再生中（PLAYING）、一時停止（PAUSED）、中段（STOPPED）、早回し（FFOWARD）、巻き戻し（REWIND）、バッファリング（BUFFERING）、不明（UNKNOWN）との値をとりうる。
【００５６】
＜MPSpeed＞:提供中のサービスの再生速度を表す。正常な速度で再生中の時、<MSpeed>は、1で一定とでき、再生状態がＦＦＯＲＷＡＲＤ(fast-forward)及びＲＥＷＩＮＤなどの場合には、それぞれ、正の倍数及び負の倍数とできる。
【００５７】
＜MediaURL＞:提供中のサービス(又は、コンテンツ）の他のデバイスへの再伝送を許可する時、そのサービス(又は、コンテンツ)が再伝送されるＵＲＬを記述する。上記MediaURLは、例えば、ＰＤからＣＤに、又は、ＣＤからＰＤに再伝送されるサービス(又は、コンテンツ)に接続するためのネットワークアドレスとして理解される。
【００５８】
また、上記＜表１２＞に含まれるフィールドは、以下の意味を有する。
【００５９】
＜EAMID＞:Emergency Alert MesasgeのＩＤを表す。
【００６０】
＜SentTimeStamp＞:ＥＡＭが生成された時間情報を含む。
【００６１】
＜ExpiredTimeStamp＞:ＥＡＭが有効な時間情報を含む。
【００６２】
＜Urgency＞:ＥＡＭの緊急度を示す。
【００６３】
＜Geo-loc＞:特定地域情報が含まれている場合に、ＥＡＭが適用される特定地域情報を表す。
【００６４】
＜EAMContent＞:ＥＡＭ (テキスト)を含む。
【００６５】
＜RichEAMURL＞:テキスト以外の付加情報（例えば、イメージ、動画、音声など）が含まれる場合に、当該付加情報へのアクセスを許可するＵＲＬ情報を記述する。
【００６６】
次に、ウェブソケットプロトコルを利用したリクエスト方法を説明する。
【００６７】
ウェブソケットリクエストを送信するサービス終端点の情報として、上記＜表６＞にて取得した＜X_HbbＴＶ_App2AppURL＞を使用できる。上記ウェブソケットは、双方向通信をサポートし、ウェブソケットのペイロードフォーマットとして任意のフォーマットを許可する。従って、本発明の実施形態では、以下のＸＭＬペイロードフォーマットを提案する。しかしながら、上述したように、実装によって、ＸＭＬのみだけでなく、ＪＳＯＮといったウェブソケットプロトコルがサポートするいかなるフォーマットも使用可能であり、フィールドも必要によっていくらでも追加や削除可能である。下記＜表１３＞は、ウェブソケットによるサービス及びコンテンツＩＤ情報リクエストの一例を示す。
【００６８】
【表１３】
0006728218.tif 000014
上記＜表１３＞において、＜statusＩＤ＞フィールドは、特定の情報をリクエストする目的で使用され、上記例の場合は、特に、サービス及びコンテンツＩＤ情報をリクエストするための方法を記述している。関連するフィールドが省略された場合には、当該関連するフィールドの省略は、状態情報の全ての情報のアップデートをリクエストしたものとして処理され、ＰＤ状態情報が変化する毎に、ＰＤ状態情報の変更をＣＤに送信してもよい。
【００６９】
上記＜表１３＞において、コマンドフィールドは、該当情報のリクエスト及び/又はキャンセルを示す。ＣＤアプリケーションは、ＰＤ状態情報(すなわち、ＰＤのサービス及び/又はコンテンツに関連する情報)(例えば、＜statusＩＤ＞で記述された情報)にアップデートがある場合、そのアップデートされた情報の伝送をＰＤにリクエストできる。このようなリクエストは、コマンドフィールドにおいて、下記の＜表１４＞に示す「subscribe」と記述され、既存リクエストをアップデートしたい時は「renew」を、キャンセルしたい時は「cancel」を記述する。それぞれの意味は、下記の＜表１４＞に一例として示す。本実施形態では、アップデートされた情報に関するリクエストは、下記＜表１４＞に示す「subscribe」、「renew」、「cancel」コマンドを用いて記述される。しかし、この構成は一例を示すに過ぎず、サービス及び／又はコンテンツに関する情報の伝送リクエストの「subscribe」、「renew」、「cancel」は、当該情報がアップデートされた時だけでなく、当該情報がアップデートされていない時にも、類似の方法で適用されてもよい。上記コマンドフィールドは、上記サービス及び/又はコンテンツに関連する情報の伝送のリクエスト/アップデート/キャンセルに関連するサブスクリプション関連コマンド(又は、メッセージ）として理解されてもよい。
【００７０】
【表１４】
0006728218.tif 000015
上記＜表１３＞において、durationフィールドは、該当情報のリクエストが持続する時間を表す。ＰＤは、上記durationフィールドに記述されている期間にのみ該当情報のアップデートを送信する。キャンセルリクエストを送信するまでＣＤアプリケーションが情報を継続して受信することを希望する場合には、infinite(又は、−１）を送信すればよい。上記durationフィールドが記述されていない時もinfiniteとして判定できる。
【００７１】
また、ＰＤは、上記ウェブソケットプロトコルを利用したＣＤアプリケーションのＰＤ状態情報アップデートリクエストを受信すると、上記ＰＤ状態情報アップデートリクエストに対する処理結果を、ＣＤアプリケーションに通知できる。ここで、上記ＰＤ状態情報アップデートリクエストは、ＰＤにおいてアップデートされたＰＤ状態情報がある場合、アップデートされたＰＤ状態情報の伝送をＰＤにリクエストすることと理解される。
【００７２】
また、ＰＤがＣＤからＰＤ状態情報アップデートリクエストを受信した時点において、アップデートされたＰＤ状態情報がない場合、上記ＰＤ状態情報アップデートリクエストに対する上記処理結果は、ＰＤが上記ＰＤ状態情報アップデートリクエストを受信したことをＣＤに通知する一種の確認応答として理解される。
【００７３】
下記＜表１５＞は、ＰＤがウェブソケットによるサービス及びコンテンツＩＤ情報リクエストを受信した場合に、ＣＤアプリケーションに伝送する処理結果の一例を示す。上記処理結果は、上記＜表７＞で例示したＰＤ状態情報(すなわち、ＰＤのサービス及び/又は、コンテンツに関連する情報)のうちの少なくとも一つに対して伝送されてもよい。
【００７４】
【表１５】
0006728218.tif 000016
上記＜表１５＞において、＜statusＩＤ＞フィールドは、上記＜表１３＞においてウェブソケットを用いてサービス及びコンテンツＩＤ情報リクエストを処理した処理結果の一例を表す。
【００７５】
上記＜表１５＞において、＜responseCode＞は、上記＜表１３＞におけるサービス及びコンテンツＩＤ情報リクエストに対する結果を表す。上記＜responseCode＞は、一般的なＨＴＴＰのステータスコードと同じ意味にて使用することができ、上記＜表１５＞の例では、“２００”、すなわち、上記サービス及びコンテンツＩＤ情報リクエストの処理に成功したことを表す。何らかの理由により、上記サービス及びコンテンツＩＤ情報リクエストが拒否された場合には、例えば、４００番台のステータスコードを伝送できる。
【００７６】
上記＜表１５＞において、＜ａｃｋ＞は、上記＜表１３＞のどのリクエストに対するＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ（ＡＣＫ）であるかを表す。例では、＜ａｃｋ＞はsubscribeリクエストに対するＡＣＫであることを表す。＜ａｃｋ＞の値のそれぞれの意味は、下記の＜表１６＞に一例として示す。
【００７７】
上記＜表１５＞において、durationフィールドは、上記＜表１３＞のサービス及びコンテンツＩＤ情報リクエストに従ってＰＤが関連情報(又は、アップデートされた情報)を伝送できる期間(すなわち、サブスクリプション期間）を、ＣＤアプリケーションに通知する。すなわち、例では、ＣＤアプリケーションが、アップデートのための期間として、例えば、infiniteをリクエストしたが、ＰＤは、アップデートのための期間を、例えば、リクエストから１０００秒と決定し、当該決定した期間中に関連情報を伝送してもよい。一動作例として、上記アップデートのための期間中に上記サービス及びコンテンツＩＤ情報のアップデートがある場合、ＰＤは、ＣＤにアップデートされたサービス及びコンテンツＩＤ情報を伝送できる。
【００７８】
【表１６】
0006728218.tif 000017
上記＜表１６＞において、ａｃｋの値は、上記＜表１４＞に示すコマンド値と１対１にマッピングされる。したがって、場合によっては、別途の＜ａｃｋ＞フィールドを使用する代わりに、＜表１４＞に示すコマンドフィールドを共通に使用し、＜表１６＞にて定義された値が、共通に使用されたコマンドフィールドの値として用いられてもよい。
【００７９】
上記ウェブソケットプロトコルを利用したＰＤ状態情報リクエストに対するＰＤの状態情報アップデートも、上記した＜表９＞乃至＜表１６＞に記述したフォーマットにより記述できる。
【００８０】
図５は、本発明の実施形態においてウェブソケットプロトコルを利用してリクエストに対するＰＤの応答を処理する手順を説明する図であり、図５の手順は、ＰＤでイベント(例えば、ＰＤ状態情報のアップデート)が発生した時に実行される。
【００８１】
図５を参照すれば、ステップ５０１において、ＰＤは、まず、ウェブソケットプロトコルを通して、ＣＤアプリケーションからＰＤ状態情報のリクエストを受信する。この場合、受信する値は、上記＜表１３＞に一例として示した値と同じである。
【００８２】
次に、ステップ５０３において、ＰＤは、ウェブソケットプロトコルを用いて受信したリクエストの＜command＞フィールドを分析する。当該＜command＞フィールド値がsubscribeであると、ステップ５０５において、ＰＤでイベントが発生したら、ＰＤは加入（登録）して、イベントをこのウェブソケット接続に伝送できるようにする。また、上記ステップ５０３において、＜command＞フィールド値がキャンセルの場合、ＰＤは、該当イベントに対する加入をキャンセルするリクエストであると判定して、ステップ５０７において、上記加入をキャンセルして応答手順を終了する。
【００８３】
上記ステップ５０５において、ＰＤは、リクエストされたイベントを登録し、ステップ５０９において登録が成功すると(受容されると)、ステップ５１３において、登録に成功したとの処理結果をＣＤアプリケーションに伝送する。一方、上記ステップ５０９において何らかの理由で登録が失敗した場合にも同様に、ステップ５１１において、ＰＤは、登録に失敗したとの処理結果をＣＤアプリケーションに伝送して、応答手順を終了する。一方、上記ステップ５０５においてリクエストしたイベント登録が完了した後、ステップ５１５においてＰＤの状態情報のアップデート(イベント)が発生すると、ステップ５１７において、ＰＤは、上記ステップ５０１において受信したリクエストの＜statusＩＤ＞フィールドを分析して、該当ＰＤ状態情報のリクエストが受信されているかを判定する。該当ＰＤ状態情報のリクエストが受信されなかった場合には、ＣＤアプリケーションに該当イベントを伝送する必要がないので、ステップ５２３において、このイベントは無視されて応答手順は終了する。
【００８４】
一方、上記ステップ５１７において、上記＜statusＩＤ＞フィールドに関連ＰＤ状態情報のリクエストが含まれていると判定されると、ＰＤはステップ５１９に進み、＜duration＞フィールドに記述されたリクエスト期間が有効であるかを判定する。上記＜duration＞フィールドに記述されたリクエスト期間が過ぎており、ＰＤ状態情報のリクエストが有効でない場合には、同様に、ＰＤは関連イベントをＣＤアプリケーションに伝送する必要がない。従って、ＰＤは、関連イベントを無視して応答手順を終了するステップ５２３に進む。また、上記ステップ５１９において、＜duration＞フィールドに記述されたリクエスト期間が有効である場合、ＰＤはステップ５２１に進み、ウェブソケットを利用して関連イベントをＣＤアプリケーションに伝送する。
【００８５】
図４は、本発明の実施形態においてＰＤ状態情報をリクエストする方法を選択する手順を説明する図である。
【００８６】
図４を参照すれば、ステップ４０１において、まず、ＰＤ状態情報のリクエスト頻度が高いか否かが判定される。ＰＤ状態情報のリクエスト頻度が低い場合は、リクエストのコストを比較的低くできるＨＴＴＰを使用する方が好ましい。リクエストが頻繁に発生する場合は、一度接続ができると関連チャンネルを継続して維持でき、関連チャンネルを通してデータの伝送が可能であるウェブソケットを使用した方が、リクエストが発生する度にＨＴＴＰを用いてリクエストをするよりは、コストの面から有利である。したがって、リクエストが頻繁に発生する場合には、ウェブソケットを使用する方が好ましい。また、ウェブソケットは、非同期通信を容易に提供できる。
【００８７】
次に、ステップ４０３において双方向性が必要であるかを判定する。双方向性とは、ＣＤアプリケーションが一方的にＰＤに情報リクエストを送信し、ＰＤで状態の変化が発生した時に、ＣＤアプリケーションによるリクエストなしにＣＤアプリケーションに情報が伝送できることを意味する。ウェブソケットは双方向通信をサポートするので、双方向通信が必要な場合には、ウェブソケットを使用することが好ましい。
【００８８】
最後に、ステップ４０５において、バイナリデータの伝送が必要であるかを判定する。ＨＴＴＰもバイナリを伝送できるが、ウェブソケットは、双方向に伝送されるデータに制限がないために、バイナリ伝送により適している。
【００８９】
また、上記したステップ４０１乃至ステップ４０５の判定に従って、ステップ４０７においてＨＴＴＰを使用してＰＤ状態情報をリクエストするか、ステップ４０９においてウェブソケットを使用してＰＤ状態情報をリクエストすることができる。
【００９０】
上記した図４の方法を使用するＰＤ状態情報の伝送方法を判定すると次のようになる。
【００９１】
一般的に、ＣＤアプリケーションが最初に起動される時にサービス及びコンテンツＩＤ情報をリクエストすることで充分である。したがって、リクエスト頻度は低いと判定されてもよい。ＣＤアプリケーションが最初にサービス及びコンテンツＩＤ情報をリクエストする時にＣＤアプリケーションにサービス及びコンテンツＩＤ情報を伝送することで充分である。従って、双方向性は不要である。また、サービス情報は、一般的にＸＭＬやＪＳＯＮのようなテキスト情報で記述できるため、サービス情報を図４のフローチャートに適用する場合にはＨＴＴＰを使用することで充分である。
【００９２】
次に、メディアタイムライン情報は、ＰＤがメディアを再生する毎に頻繁にアップデートされるので、メディアタイムライン情報についてはウェブソケットを使用する方が好ましい。
【００９３】
メディア再生情報は、ＰＤが現在再生中のメディアの状態(再生中であるか、中断されているか、ＦＦ中であるか等)を表し、上記のメディアタイムライン情報よりもリクエスト頻度が低い。しかしながら、メディアの再生状態が変更された時(例えば、再生から中断に)には、変化した状態をＣＤアプリケーションに通知する必要があるため、双方向通信が必要である。したがって、この場合には、ウェブソケットを使用する方が好ましい。
【００９４】
一般的に、緊急アラーム情報は発生する可能性が低いが、ＰＤが関連情報を受信した場合には、ＰＤは、失敗することなく、受信した情報をＣＤアプリケーションに伝達する必要がある。したがって、双方向性が必須であり、この場合には、ウェブソケットの使用が推奨される。
【００９５】
本発明の実施形態によれば、図６の一例に示すように、サービスプロバイダー６０１、６０３から放送網又は広域ネットワーク６１、６３を通して複数のデバイス６１１、６１３で放送サービス又は放送コンテンツが提供される環境において、マルチスクリーンサービスを利用する場合、ＣＤアプリケーションがＰＤ状態情報を（参照番号６５に示すように）リクエストし、（参照番号６７に示すように）受信できる方法が提供され、これにより、ＣＤは、ＰＤアプリケーションがなくても、ＣＤアプリケーションを使用して、ＰＤと連動できる。また、既存のＣＳスクリーン構造とプロトコルを活用してＰＤの状態情報を受信できる方法を提供することによって追加的な構成と費用が発生しない。
【図１】
0006728218.tif 000018
【図２】
0006728218.tif 000019
【図３】
0006728218.tif 000020
【図４】
0006728218.tif 000021
【図５】
0006728218.tif 000022
【図６】
0006728218.tif 000023