【文献】
マルチ端末・マルチネットワーク環境における協調型シームレス通信サービス,電子情報通信学会論文誌,日本,一般社団法人電子情報通信学会,2012年 4月 1日,第J95-B巻 第4号,p.502〜509
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0020】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【0021】
図面において、同一の構成要素に対してはできるだけ同一の参照符号及び参照番号を付して説明する。下記の説明で、本発明に関連した公知の機能又は構成に関する具体的な説明が本発明の要旨を不明にすると判断された場合に、その詳細な説明を省略する。また、後述する用語は、本発明の機能を考慮して定義されたものであって、ユーザー、運用者の意図、又は慣例によって変わることができる。したがって、上記用語は、本明細書の全体内容に基づいて定義されなければならない。
【0022】
本発明は、多様な変更が可能であり、様々な実施形態を有することができるので、特定の実施形態を図面に例示して詳細に説明する。しかしながら、これは、本発明を特定の実施形態に対して限定するものではなく、本発明の思想及び技術範囲に含まれるすべての変更、均等物乃至代替物を含むことが理解されなければならない。
【0023】
本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、“コンポーネント表面(a component surface)"との記載は、1つ又は複数の表面を含む。
【0024】
‘第1’、‘第2’のように序数を含む用語は多様な構成要素を説明するために使用されるが、構成要素は、上記用語により限定されない。これらの用語は、一つの構成要素を他の構成要素から区別する目的のみで使われる。例えば、本発明の権利範囲を外れることなく、第1の構成要素は第2の構成要素と称され、同様に第2の構成要素も第1の構成要素と称され得る。‘及び/又は’という用語は、複数の関連した記載項目の組合せ又は複数の関連した記載項目のうち何れかの項目を含む。
【0025】
また、本願明細書で使用される用語は、単に特定の実施形態を説明するために使用されるものであって、本発明を限定するものではない。単数形が、コンテキスト中に特記して明示されない限り、複数形を含むことは、当業者には容易に分かることであろう。また、‘含む’又は‘有する’などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品又はこれらの組合せが存在することを指定しようとするものであって、一つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品、若しくはこれらの組合せが、存在する或いは付加される可能性を予め排除しないことが理解されなければならない。
【0026】
別に定義されない限り、ここで使用される技術的又は科学的な用語を含むすべての用語は、本発明が属する技術分野で通常の知識を持った者には一般的に理解される意味と同一の意味を有する。一般的に使用される辞典で定義されるような用語は、関連技術の文脈上有する意味と一致する意味を有すると解析されなければならなく、ここで明白に定義されない限り、理想的又は過度に形式的な意味で解析されない。
【0027】
本発明の多様な実施形態によると、デバイスは、通信機能を含むことができる。例えば、デバイスは、スマートフォン、パーソナルコンピュータ(PC)、携帯電話、テレビ電話、電子書籍リーダ、デスクトップPC、ラップトップPC、ネットブックPC、PDA(Personal Digital Assistant)、PMP(Portable Multimedia Player)、mp3プレーヤー、モバイル医療デバイス、カメラ、ウェアラブルデバイス(例えば、HMD(Head-Mounted Device)、電気衣類、電子ブレース(electronic brace)、電子ネックレス、電子アプセサリ(appcessory)、電子タトゥー、又はスマート時計)であってもよい。
【0028】
本発明の実施形態によると、デバイスは、通信機能を有するスマート家電であってもよい。スマート家電は、例えばテレビジョン、DVD(Digital Video Disk)プレーヤー、オーディオ、冷蔵庫、エアコン、電気掃除機、オーブン、電子レンジ、洗濯機、ドライヤー、空気清浄器、セットトップボックス、TVボックス(例えば、Samsung HomeSync(登録商標)、Apple TV(登録商標)、又はGoogle TV(登録商標))、ゲーム機、電子辞書、電子キー、カムコーダ、電子ピクチャーフレームであってもよい。
【0029】
本発明の実施形態によると、デバイスは、医療機器(例えば、MRA(Magnetic Resonance Antiography)装置、MRI(Magnetic Resonance Imaging)装置、CT(Computed Tomography)機器、映像機器、又は超音波装置)、ナビゲーション機器、GPS(Global Positioning System)受信器、イベントデータレコーダ(Event Data Recorder:EDR)、フライトデータレコーダ(Flight Data Recorder:FDR)、自動車用インフォテインメント装置、船舶用電子装置(例えば、船舶用ナビゲーション装置、ジャイロスコープ、又はコンパス)、航空電子機器、セキュリティ機器、産業又は個人用ロボットであってもよい。
【0030】
本発明の実施形態によると、デバイスは、通信機能を有する家具、ビル/構造の一部、電子ボード、電子署名受信器、プロジェクタ、多様な測定装置(例えば、水、電気、ガス、又は電磁波測定装置)であってもよい。
【0031】
本発明の実施形態によると、デバイスは、上記した装置の組み合わせであってもよい。また、本発明の実施形態による電子デバイスは、上記装置に制限されるものではないことは、当該技術分野における通常の知識を持つ者には明らかである。
【0032】
本発明の実施形態によると、デバイスは、電子デバイスであってもよい。
【0033】
本発明の一実施形態では、無線通信システムにおけるアプリケーション実行方法及び装置を提供することにある。無線通信システムは、複数の機器が接続されているネットワーク環境(例えば、ホームネットワーク環境など)での無線通信システムであり得る。無線通信システムにおいて、第1のデバイスと第2のデバイスが連動されて第2のデバイスのアプリケーションに関連した第1のデバイスのアプリケーションに関する情報を第2のデバイスが第1のデバイスに提供できる。具体的には、Web技術に基づいて第2のデバイスが自身と連動される第1のデバイスを発見し、第2のデバイスのアプリケーションに関連した第1のデバイスのアプリケーションに関する情報を第1のデバイスに送信することにより、第1のデバイスのアプリケーションを実行できる。
【0034】
本発明の一実施形態では、同一のネットワーク内で複数の機器間の連動に必要なシステム構成方法とともに、第2のデバイスと第1のデバイスとの間の連動のために必要な具体的なプロトコルが提供される。また、本発明の実施形態では、複数の機器間のアプリケーション連動のための共有フレームワークを提供することにより、今後共有フレームワークは、遠隔ユーザーインターフェース(Remote User Interface:RUI)サービスに使用されるか、あるいは多様な放送標準環境で使用され得る。
【0035】
一方、本発明の一実施形態において、アプリケーションは、HTML5(Hypertext Markup Language 5)で作成されるWebアプリケーションと該当デバイスのオペレーティングシステム(OS)に依存する内蔵型(native)アプリケーションを全部含むことができる。以下、説明の便宜のために、アプリケーションを“App”と称する。
【0036】
以下、本発明の一実施形態について具体的に説明する。本発明の一実施形態では、次のような方法を提供する。
【0037】
−第2のデバイスと第1のデバイスとの間の連動のための無線通信システムを構成
−第2のデバイスで第1のデバイスを発見する方法
−第1のデバイスで第2のデバイスを発見する方法
−第2のデバイスにより第1のデバイスの特定Appを実行する方法
−第2のデバイスにより第1のデバイスの性能に適したAppを選択する方法
−第1のデバイスによりサービスを提供するためのサービスエンドポイント情報を提供する方法
<第1の実施形態>
図1は、本発明の第1の実施形態による無線通信システムの概略的な構成を示す。
【0038】
図1を参照すると、無線通信システムは、Webサーバ130と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を実行し、例えば、ホームネットワーク内の無線通信が可能なデバイスであり得る。
図1では、複数のデバイスのうち、相互に連動できる第1のデバイス100と第2のデバイス110について説明する。
【0039】
Webサーバ130は、第1のデバイス100と第2のデバイス110で使用されるWeb App104,114を提供する。Web App104,114は、HTML、CSS(Cascading Style Sheet)、ジャバスクリプト(javascript(登録商標))、動画像、及びイメージなどで構成できる。一方、Webサーバ130は、ローカルネットワーク内に存在してもよく、あるいは外部ネットワーク(クラウド)に存在してもよい。
【0040】
第1のデバイス100は、Appが実行されるメインデバイスを示す。例えば、第1のデバイス100は、デジタルTV(DTV)又はセットトップボックス(STB)のような共有デバイスである。このとき、Appは、放送に関連したAppであり得る。
【0041】
第2のデバイス110は、第1のデバイス100と連動してAppを実行する補助機器を示す。第2のデバイス110は、移動端末又はタブレットのような個人端末であり得る。
【0042】
第1のデバイス100と第2のデバイス110は、各々Webブラウザ102,112を含む。Webブラウザ102,112は、HTML5及び関連Web技術で構成されるWeb App104,114を実行するために使用される。
【0043】
第2のデバイス110は、内蔵型App116を含むことができる。内蔵型App116は、第2のデバイス110のプラットフォーム(OS)(例えば、アンドロイド(登録商標)、iOS(登録商標)、Windows(登録商標)、及びTiZen(登録商標))で実行されるAppを表す。内蔵型App116は、バイナリコードにコンパイルされて実行されることができる。
【0044】
第1のデバイス100に含まれるマルチスクリーン(MS)管理部106は、第2のデバイス110との連動に必要な動作を遂行する。すなわち、MS管理部106は、ネットワークで第2のデバイス110を発見し、App起動(launch)情報を第2のデバイス110のMSランチャ(launcher)118に送信する。MS管理部106は、第2のデバイス110にApp情報を伝送する機能、第2のデバイス110にApp起動を要請する機能、及び第1のデバイス100と第2のデバイス110のApp間通信を可能にする機能を遂行できる。
【0045】
第2のデバイス110に含まれるMSランチャ118は、第1のデバイス100との連動に必要な動作を実行する。すなわち、MSランチャ118は、MS管理部106と通信を遂行して第2のデバイス110のAppを実行する。MSランチャ118は、ネットワークで第1のデバイス100を発見する機能、第1のデバイス100にApp実行を要請する機能、及び第2のデバイス110と第1のデバイス100との間のApp間通信を可能にする機能を遂行する。
【0046】
図2は、本発明の第1の実施形態による第1のデバイスにより第2のデバイスを発見してペアリングするプロセスを示す信号フロー図である。
【0047】
図2を参照すると、第1のデバイス100は、ステップ214において、Webブラウザ102を通じてWebサーバ130にURL(Uniform Resource Locator)要請を送信することによって、Webページ伝送を要請する。第1のデバイス100は、ステップ216において、Webサーバ130からWebページを受信する。ここで、Webブラウザ102は、受信されたWebページを基本(primary)App105として処理して表示する。
【0048】
Webブラウザ
102により実行される基本App105は、ステップ218において、第2のデバイス110を発見するために、所定のアプリケーションプログラムインターフェース(API)(例えば、getAvailableCSDevice())を用いてMS管理部106に利用可能な第2のデバイス110に対するリスト(第2のデバイスIDリスト)を要請する。
【0049】
すると、MS管理部106は、ステップ220において、ネットワーク内に存在する第2のデバイス110を発見するために、第2のデバイス110のMSランチャ118に信号を送信し、ステップ222において、MSランチャ118から応答信号を受信する。ここで、第2のデバイス110を発見するために使用されるプロトコルは、後述する第2の実施形態で定義されるプロトコルとなり得るが、これに関しては第2の実施形態でより具体的に説明する。MS管理部106は、応答信号が受信される場合、第2のデバイス110を利用可能な機器として判定し、ステップ224において、第2のデバイス110に関する情報を基本App105に送信できる。
【0050】
図2では、第2のデバイス110が1個である場合を例示したが、第2のデバイス110は、ネットワーク内に複数個が存在してもよい。この場合、MS管理部106で第2のデバイス110に対するリストが生成されて基本App105に送信できる。
【0051】
基本App105は、ステップ226において、第2のデバイス110に関する情報を画面に表示することで、第2のデバイス110を使用するか否かに対するユーザーの選択を受信する。ここで、第2のデバイス110に関する情報を画面に表示する方法、ユーザーから選択される方法、及び第1のデバイス100が自動で第2のデバイス110を選択する方法に関しては具体的に定義されない。しかしながら、基本App105がWeb Appとして定義されるため、第2のデバイス110に関する情報は、JAVA(登録商標)スクリプトで処理されてWebページに表示されることにより、ユーザーから選択され得る。
【0052】
基本App105は、第2のデバイス110が選択されると、ステップ228において、第2のデバイス110の識別子(ID)及び第2のデバイスのAppであるCS App115を実行するURL情報を格納する。格納した情報は、以後第1のデバイス100で第2のデバイス110のCS App115を実行させるために使用される。
【0053】
図3は、本発明の第1の実施形態による第1のデバイスにより第2のデバイスのAppを実行するプロセスを示す信号フロー図である。
【0054】
図3を参照すると、ステップ314において、上記した
図2のステップ214乃至ステップ228を通じて第2のデバイス110の発見及びペアリング過程を完了する場合、ステップ316において、基本App104は、特定API(例えば、sendCSURI())を用いて第2のデバイス110で実行されるCS App115に関する情報をMS管理部106に送信する。
【0055】
すると、MS管理部106は、ステップ318において、第2のデバイス110のMSランチャ118に実行しなければならないCS App115に関する情報を送信する。MSランチャ118は、ステップ320において、実行すべきCS App115に関する情報に含まれたURI(Uniform Resource Identifier)情報(URL情報及びURN(Uniform Resource Name)情報を包含)をWebブラウザ112に送信する。
【0056】
Webブラウザ112は、URI情報に基づいて実行すべきCS App115が内蔵型Appであるか、あるいはWeb Appであるかを判定する。実行すべきCS App115が内蔵型Appである場合、Webブラウザ112は、ステップ322において、内蔵型Appを実行する。
【0057】
実行すべきCS App115がWeb Appである場合、ステップ324において、Webブラウザ112は、URIが含まれるURL要請をWebサーバ130に送信することにより、Webページの送信を要請する。Webサーバ130からWebページが受信される場合、Webブラウザ112は、該当WebページをCS App115として表示する。
【0058】
このように、CS App115は、第1のデバイス100の基本App105により実行されるため、基本App105とCS App115は、相互に関連して動作できる。
【0059】
<表1>は、
図2のステップ218及び
図3のステップ316のように、第1のデバイス100で使用できるAPIを簡略に示す。
【0061】
<表1>を参照すると、getAvailableCSDevice()は、入力要素(factor)を有しなく、ネットワークで利用可能な第2のデバイスのリストを獲得するために使われる。sendCSURI()は、App実行ターゲットである第2のデバイスのIDを示す
unit target_deviceと、実行される第2のデバイスのAppのURI情報の2個の入力要素を有し、第2のデバイスのAppを実行するために使用され得る。
【0062】
図4は、本発明の第1の実施形態による第2のデバイスにより第1のデバイスのAppを実行するプロセスを示す信号フロー図である。
【0063】
図4を参照すると、CS App
115が内蔵型Appである場合、ステップ414において、CS App115は、ユーザーにより実行され得る。あるいは、CS App115がWeb Appである場合、ステップ416で、Webブラウザ102によりWebサーバ130にURL要請を送信することにより、Webページの送信を要請する。Webサーバ130からWebページが受信される場合、Webブラウザ112は、ステップ418で受信されたWebページをCS App115として表示する。
【0064】
CS App115は、ステップ420において、特定API(例えば、getAvailablePrimaryDevice())を用いてMSランチャ118に利用可能な第1のデバイス100に対するリストを要請する。
【0065】
すると、MSランチャ118は、ステップ422において、ネットワーク内に存在する第1のデバイス100を発見するために、第1のデバイス100のMS管理部106に信号を送信し、ステップ423でMS管理部106から応答信号を受信する。ここで、第1のデバイス100を発見するために使用されるプロトコルは、後述する第3の実施形態で定義されるプロトコルであり得る。MSランチャ118は、応答信号が受信される場合、第1のデバイス100が利用可能な機器であると判定し、ステップ424で、第
1のデバイス
100に関する情報をCS App115に送信できる。
【0066】
一方、
図4では、第1のデバイス100が一つである場合を例示するが、第1のデバイス100は、ネットワーク内に複数個が存在でき、この場合、MSランチャ118で第1のデバイス100に対するリストが生成されてCS App115に送信され得る。
【0067】
CS App115は、第1のデバイス100に関する情報を画面に表示することによって、ユーザーから第1のデバイス100を使用するか否かが選択される。ここで、第1のデバイス100に関する情報を画面にどのように表示するか、あるいはユーザーからどのように選択されるか、又は第2のデバイス110から自動で第1のデバイス100を選択するかに対しては具体的に定義されない。但し、第1のデバイス110に関する情報は、CS App115に伝送されるので、CS App115によりユーザーから選択される。
【0068】
CS App115は、第1のデバイス110が選択される場合、ステップ426において、特定API(launchPrimaryAppURI())を用いて基本App実行のための情報をMSランチャ118に送信する。すなわち、CS App115は、MSランチャ118に第1のデバイス100の情報と基本App105に関する情報、例えばURI情報を伝送する。すると、MSランチャ118は、ステップ428で、伝送される情報に基づいて第1のデバイス100で実行される基本App105に関する情報を第1のデバイス100のMS管理部106に送信する。
【0069】
MS管理部106は、ステップ430において、URI情報をWebブラウザ102に送信する。すると、Webブラウザ102は、URI情報に基づいて実行しなければならない基本App105が内蔵型Appであるか、あるいはWeb Appであるかを判定する。実行すべき基本App105が内蔵型Appである場合、Webブラウザ102は、ステップ432において、基本App105として内蔵型Appを実行する。
【0070】
実行する基本App105がWeb Appである場合、ステップ434において、Webブラウザ102は、URIが含まれたURL要請をWebサーバ130に送信することによって、Webページの送信を要請する。ステップ436において、Webサーバ130からWebページが受信される場合、Webブラウザ102は、該当Webページを基本App105として表示する。
【0071】
このように、基本App105は、第2のデバイス110のCS App115により実行されるため、基本App105とCS App115は、相互に関連されるように動作できる。
【0072】
以下、<表2>は、
図4のステップ420及びステップ426のように、第2のデバイス110で使用されるAPIを簡略に示す。
【0074】
<表2>を参照すると、getAvailablePrimaryDevice()は、入力要素を有しなく、ネットワークで利用可能な第1のデバイスのリストを獲得するために使用される。sendPrimaryAppURI()は、App実行対象である第1のデバイスのIDを表す
unit target_deviceと実行する第1のデバイスのAppのURI情報を2個の入力要素として有し、第1のデバイスのAppを実行するために使用され得る。
<第2の実施形態>
図5は、本発明の第2の実施形態による無線通信システムの概略的な構成を示す。
【0075】
図5を参照すると、無線通信システムは、Webサーバ530と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を遂行し、例えば、ホームネットワーク内の無線通信が可能な機器であり得る。
図5では、複数のデバイスのうち相互に連動される第1のデバイス500と第2のデバイス520について説明する。
【0076】
第1のデバイス500は、Webブラウザ504、内蔵型App502、Web App506、及び第2のデバイス520との連動のためのMS管理部508を含む。第2のデバイス520は、Webブラウザ522、Web App524、内蔵型App526、及びMSランチャ528を含む。
【0077】
図5において、Webブラウザ504,522だけでなくWeb App506,524、内蔵型App502,526、MS管理部508、及びMSランチャ528は、各々
図1のWebブラウザ102,112、Web App104,114、内蔵型App116、MS管理部106、及びMSランチャ118に対応する動作を遂行できる。
【0078】
但し、
図5のMS管理部508及びMSランチャ528は、次のような細部的な構成を含むことができる。すなわち、MS管理部508は、UPnP(Universal Plug and Play)部512、HTTPサーバ514、及びWebソケットサーバ510を含み、MSランチャ528は、UPnP部
534及びHTTPサーバ532を含む。
【0079】
UPnP部512,
534は、第1のデバイス500と第2のデバイス520両方ともに含まれ、デバイス発見動作を実行する。具体的に、UPnP部512,
534は、簡単なサービス発見プロトコル(Simple Service Discovery Protocol:SSDP)を用いてネットワークで他のデバイスを発見し、ネットワークに自身の存在を知らせる役割を遂行する。
【0080】
HTTPサーバ514,532は、第1のデバイス500と第2のデバイス520の両方ともに含まれ、HTTPプロトコルを介して要請を受信し、受信した要請による動作を実行する。本発明の第2の実施形態において、HTTPサーバ514,532は、App実行のために他の機器からHTTP GET及びHTTP POST要請を受信して該当要請による動作を実行する。本発明の第2の実施形態では、HTTPサーバ514,532は、上記した動作以外にWebページを配布する一般的なWebサーバの動作は実行しない。
【0081】
Webソケットサーバ510は、第1のデバイス500に含まれ、Webソケットプロトコルを処理する動作を実行する。本発明の第2の実施形態において、Webソケットサーバ510は、第2のデバイス520からWebソケット要請を受信し、これを処理して第1のデバイス500と第2のデバイス520のApp間通信を可能にする動作を実行する。
【0082】
以下、
図6を参照して、第1のデバイス500と第2のデバイス520間の発見動作について説明する。
【0083】
図6は、本発明の第2の実施形態による第1のデバイスと第2のデバイスとの間の発見プロセスを示す信号フロー図である。
図6で説明されるプロセスは、上記した<表1>のgetAvailableCSDevice()の詳細プロトコルの具体的な動作に該当する。
【0084】
まず、第1のデバイス500が第2のデバイス520を発見する例から説明する。
図6を参照すると、第1のデバイス500のUPnP部
512は、ステップ622において、デバイス発見のための信号を送信する。例えば、UPnP部
512は、ネットワークで利用可能な第2のデバイス520を検索するためにSSDPのM-SEARCHメソッド(method)を使用して次の<表3>に示すような信号を送信できる。
【0086】
第2のデバイス520のUPnP部
534は、上記のような信号が受信されると、ステップ624において、URL情報が含まれた応答信号を第1のデバイス500に送信することにより、自身の存在を第1のデバイス500に通知する。例えば、UPnP部
534は、<表4>に示すような応答信号を送信し、この応答信号は、LOCATIONヘッダーに第2のデバイス520に関する情報に関連したURL情報を含むことができる。
【0088】
第1のデバイス500のUPnP部512は、応答信号を受信すると、ステップ626において、応答信号のLOCATIONヘッダーに含まれるURL情報を用いて第2のデバイス520に関する情報を要請する。このとき、上記要請は、HTTP GETメソッドに基づいて遂行できる。
【0089】
第2のデバイス520のHTTPサーバ532は、ステップ628において、要請に対応して第2のデバイス520のApp、すなわちCS App527を実行させるために使用されるURL情報が含まれる応答信号を第1のデバイス500に送信する。応答信号は、その一例として、HTTP Response形態で<表5>に示すようなCS App527を実行させるために使用されるURL情報が含まれたヘッダー(x−Application−URL)を含むことができる。
【0091】
次に、第2のデバイス520が第1のデバイス500を発見する一例を説明する。
【0092】
第2のデバイス520のUPnP部
534は、ステップ630において、機器発見のための信号を送信する。例えば、UPnP部
534は、ネットワークで利用可能な第1のデバイス500を検索するためにSSDPのM-SEARCHメソッドを使用して下記の<表6>に示すような信号を送信できる。
【0094】
第1のデバイス500のUPnP部512は、上記の信号を受信すると、ステップ632において、URL情報が含まれた応答信号を第2のデバイス520に送信することによって、自身の存在を第2のデバイス520に通知する。例えば、UPnP部512は、下記の<表7>に示すような応答信号を送信し、この応答信号は、LOCATIONヘッダーに第1のデバイス500に関する情報に関連したURL情報を含むことができる。
【0096】
第2のデバイス520のHTTPサーバ532は、応答信号を受信すると、ステップ634において、応答信号のLOCATIONヘッダーに含まれたURL情報を用いて第1のデバイス500に関する情報を要請する。このとき、要請は、HTTP GETメソッドに基づいて実行できる。
【0097】
第1のデバイス520のUPnP部512は、ステップ636において、要請に対応して第1のデバイス500のApp、すなわち基本App507を実行させるために使用されるURL情報が含まれた応答信号を第2のデバイス520に送信する。応答信号は、一例としてHTTP Response形態で、<表8>に示すような基本App507を実行させるために使用されるURL情報が含まれたヘッダー(x-Application-URL)を含むことができる。
【0098】
また、第1のデバイス500は、第2のデバイス520のAppとAppとの間の通信を実行するWebソケットサーバ510を有するので、ステップ638において、Webソケットサーバ510に接続できるURL情報が含まれるヘッダー(x-WebSocket)を応答信号に含めて第2のデバイス520に送信する。
【0100】
図7は、本発明の第2の実施形態による第1のデバイスと第2のデバイスとの間のAppを実行するプロセスを示す信号フロー図である。
図7で説明するプロセスは、上記した<表1>のsendCSURI()の詳細プロトコルの具体的な動作に該当する。
【0101】
まず、第1のデバイス500が第2のデバイス520のAppを実行するプロセスを説明する。
図7を参照すると、第1のデバイス500のMS管理部508は、ステップ722において、第1のデバイス500のブラウザ506からsendCSURI()を通じて2個の要素が伝送される。2個の要素のうちいずれか一つである
unit target_deviceは、App実行対象である第2のデバイス520のIDを示すが、MS管理部508は、第2のデバイス情報テーブルに基づいて第2のデバイス520のAppを実行させるためのURL情報(x-Application-URL)を獲得できる。第2のデバイス情報テーブルは、MS管理部508に格納されて管理でき、例えば<表9>に示すようである。
【0103】
<表9>に示すように、第2のデバイス情報テーブルは、第2のデバイスID、デバイス種類を示す機器説明情報及び第2のデバイスApp URL情報を含むことができる。
【0104】
第1のデバイス500のMS管理部508は、獲得した
URL情報に基づき、ステップ724において、第2のデバイス520のHTTPサーバ532に<表10>に示すようなHTTP Post要請を送信する。
【0106】
このとき、第2のデバイス520で実行されるAppは、CSAppPathにURI情報で指示され、これは、sendCSURI()の他の一つの要素であるchar*URI値である。また、第2のデバイス520のAppを実行させるとき、必要な要素は、HTTPのボディー部に<表10>に示すような形式に基づいて送信され得る。
【0107】
第2のデバイス520のHTTPサーバ532は、ステップ726において、受信されたHTTP POSTをパーシング(parsing)してボディー部の要素とともにCSAppPath情報をMSランチャ528に伝送する。すると、MSランチャ528は、ステップ728において、CSAppPathに含まれたURI情報に基づいて第2のデバイス520のAppであるCS App527を実行する。
【0108】
MSランチャ528は、ステップ730において、CS App527の実行結果(例えば、CS App527の実行に成功)が受信される場合、ステップ732において、CS App527の実行結果を第2のデバイス520のHTTPサーバ532に送信する。すると、HTTPサーバ532は、CS App527の実行結果に従ってステップ734において、第1のデバイス500のMS管理部508に下記の<表11>に示すような応答コードのうち一つ(例えば、201 CREATED)を送信する。
【0110】
<表11>において、応答コード201 CREATEDは、CS App527の実行に成功したことを表し、応答コード404 NOT FOUNDは、CS App527が存在しないことを表し、応答コード503 SERVICE UNAVAILASBLEは、第2のデバイス520が他のAppを実行することにより、CS App527が暫く実行できないことを示す。
【0111】
次に、第2のデバイス520が第1のデバイス500のAppを実行するプロセスを説明する。
【0112】
第2のデバイス520のMSランチャ528は、ステップ736において、第2のデバイス520のブラウザ
522からsendPrimaryAppURI()を通じて2個の要素を受信する。2個の要素のうちいずれか一つである
unit target_deviceはApp実行対象である第1のデバイス520のIDを表す。MSランチャ528は、第1のデバイス情報テーブルに基づいて第1のデバイス500のAppを実行させるためのURL情報(x-Application-URL)を獲得できる。第1のデバイス情報テーブルは、MSランチャ528に格納されて管理され、その一例として<表12>に示すようである。
【0114】
<表12>に示すように、第1のデバイス情報テーブルは、第1のデバイスID、機器種類を示すデバイスディスクリプタ情報、第1のデバイスApp URL情報、及びWebソケット情報を含むことができる。
【0115】
第2のデバイス520のMSランチャ528は、獲得したURL情報に基づき、ステップ738において、第1のデバイス500のHTTPサーバ514に下記の<表13>に示すようなHTTP Post要請を送信する。
【0117】
このとき、第1のデバイス500で実行されるAppは、PrimaryPathにURI情報で指示され、sendPrimaryAppURI()の他の一つの要素であるchar*URI値である。また、第1のデバイス500のAppを実行させるとき、必要な要素は、HTTPのボディー部に<表13>のような形式に基づいて送信され得る。
【0118】
第1のデバイス500のHTTPサーバ514は、ステップ740において、受信されたHTTP POSTをパーシングしてボディー部の要素とともにPrimaryAppPath情報をMS管理部508に伝送する。すると、MS管理部508は、ステップ742において、PrimaryAppPathに含まれたURI情報に基づいて第1のデバイス500のAppである基本App
506を実行する。
【0119】
MS管理部508は、ステップ744において、基本App
506の実行結果(例えば、基本App
506の実行に成功)が受信される場合、ステップ746において、基本App
506の実行結果を第1のデバイス500のHTTPサーバ514に送信する。すると、HTTPサーバ514は、基本App
506の実行結果により、ステップ748において、第2のデバイス520ののMSランチャ528に下記の<表14>に示すような応答コードのうちいずれか一つ(例えば、201CREATED)を送信する。
【0121】
<表14>において、応答コード201CREATEDは、基本App
506の実行に成功したことを示し、応答コード404NOT FOUNDは、基本App
506が存在しないことを示し、応答コード503SERVICE UNAVAILABLEは、第1のデバイス500が異なる動作(例えば、TVチャンネルスキャン動作など)を遂行するに従って、基本App
506が少しの間実行されないことを示す。
【0122】
図8は、本発明の第2の実施形態による方法が適用される例を示す。
【0123】
図8では、Webサーバ530が放送社のWebサーバであり、第1のデバイス500はデジタルTV(DTV)であり、第2のデバイス520は移動端末である場合を一例として示す。
【0124】
ユーザーは、第1のデバイス500を用いてWebサーバ530からストリーミングされる映画800を視聴できる。このとき、ユーザーは、映画の視聴中に該当映画に対する付加情報を第2のデバイス530を通じて受信しようとする。
【0125】
この場合、第1のデバイス500は、第2のデバイス520のAppのURL情報820に基づいて付加情報を提供する第2のデバイス520のAppを実行させることができる。第2のデバイス520のAppが実行される場合、Webサーバ530から付加情報810を受信して第2のデバイス520は、受信された付加情報810をユーザーに提供する。付加情報は、例えばキャスティング情報、映画のシノプシス、及びオンラインショッピングを含むことができる。
<第3の実施形態>
図9は、本発明の第3の実施形態による無線通信システムの概略的な構成を示す。
【0126】
図9を参照すると、無線通信システムは、Webサーバ900と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を実行でき、例えば、ホームネットワーク内の無線通信が可能な機器であり得る。
図9では、複数のデバイスのうち、相互に連動できる第1のデバイス910と第2のデバイス920について説明する。
【0127】
Webサーバ900は、第1のデバイス910と第2のデバイス920で利用可能なWeb App914、924を提供する。Web App914,924は、HTML、CSS、ジャバスクリプト、動画像、及びイメージを含むことができる。一方、Webサーバ900は、ローカルネットワーク内に存在してもよく、あるいは外部ネットワーク(クラウド)に存在してもよい。Webサーバ900は、第1のデバイス910のAppを実行するためのApp情報、すなわちXML(Extensible Markup Language)に基づいて生成されたApp情報(以下、‘XML AIT’と称する)を提供できる。ここで、XML AITを提供するWebサーバとWeb Appを提供するWebサーバは、同一のデバイスでもよく、異なるデバイスでもよい。
【0128】
第1のデバイス910は、Appが実行されるメインデバイスを表す。例えば、第1のデバイス910は、DTV又はSTBのような共有機器であり得る。このとき、Appは、放送に関連したAppであり得る。
【0129】
第2のデバイス920は、第1のデバイス910と連動してAppを実行する補助デバイスを示す。第2のデバイス920は、移動端末又はタブレットのような個人端末であり得る。
【0130】
第1のデバイス910と第2のデバイス920は、各々Webブラウザ912,922を含む。Webブラウザ912,922は、Web App914,924を実行するために使用される。
【0131】
第2のデバイス920は、内蔵型App926を含むことができる。内蔵型App926は、第2のデバイス920のプラットフォーム(OS)(例えば、アンドロイド(登録商標)、iOS(登録商標)、Windows(登録商標)、及びTiZen(登録商標))で実行されるAppを示す。内蔵型App926は、バイナリコードにコンパイルされて実行できる。
【0132】
本発明の第3の実施形態において、第1のデバイス910は、CS(Companion Screen)管理部916とアプリケーション情報テーブル(Application Information Table:AIT)管理部918をさらに含むことができる。CS管理部916は、第2のデバイス920との連動のために必要な動作を実行する。例えば、CS管理部916は、該当ネットワークで第2のデバイス920を検索又は発見する動作、第2のデバイス920から第1のデバイス910で実行されるApp情報を受信する動作、及び第1のデバイス910と第2のデバイス920とのApp間の通信のための動作を実行できる。
【0133】
AIT管理部918は、第1のデバイス910に含まれ、XML AITを受信してパーシングする。XML AITは、第2のデバイス920から送信された情報であって、CS管理部916により受信されてAIT管理部918に伝送される。AIT管理部918は、XML AITをパーシングして該当Appに関する情報を抽出し、抽出した情報に基づいて該当Appを実行させる。
【0134】
第2のデバイス920は、CSランチャ928をさらに含む。CSランチャ928は、第1のデバイス910との連動に必要な動作を実行する。例えば、CSランチャ928は、該当ネットワークで第1のデバイス910を検索又は発見する動作、Appの要請により第1のデバイス910にAppの実行を要請する動作、Appに関する情報を伝送する動作、及び第1のデバイス910と第2のデバイス920とのApp間の通信のための動作を実行できる。
【0135】
以下、
図9に示すような無線通信システムにおいて、第2のデバイス920により第1のデバイス910のAppを実行する方法について説明する。
【0136】
図10は、本発明の第3の実施形態による無線通信システムにおいて、第2のデバイスにより第1のデバイスのAppを実行させるプロセスを示す信号フロー図である。
【0137】
図10を参照すると、ステップ1000において、第2のデバイス920は、CS App930を実行させる。CS App930は、第1のデバイス910のAppを実行するために使用される第2のデバイス920のAppであり得る。CS App930は、Web App924及び内蔵型App926のうちいずれか一つであり、CS App930がWeb App924である場合には、ステップ1002及びステップ1004でCS App930が実行される。
【0138】
すなわち、CS App930がWeb App924である場合、ステップ1002で、第2のデバイス920は、URL情報に基づいてWebサーバ900にCS App930を提供することを要請し、ステップ1004で、Webサーバ900からCS App930に関連したWebページ(HTML、CSS、ジャバスクリプト、及びイメージを包含)を受信する。第2のデバイス920は、受信されたWebページをCS App930として実行する。ステップ1002及びステップ1004の動作は、Webブラウザ922を用いて実行し、CS App930が内蔵型App926である場合には省略することができる。
【0139】
CS App930が実行される場合、CS App930は、ステップ1006において、該当ネットワークで利用可能な他のデバイスが存在するかに対する機器検索要請をCSランチャ928に送信する。すると、CSランチャ928は、ステップ1008で機器検索を実行し、ステップ1010で検索される機器に関する情報をCS App930に送信する。
【0140】
機器検索要請と機器検索動作は、CS App930の所定のAPIに基づいて実行され得る。すなわち、CS App130によりAPIが実行される場合、CSランチャ928による実際の機器検索動作が実行される。APIは、例えばdiscoverHbbTVdevices()と同一であり、その実現に従って変わり得る。
【0141】
一方、複数のデバイスが検索される場合、複数のデバイスに関する情報は、CS App930に送信される。ステップ1012において、CS App930で複数のデバイスのうちいずれか一つ、すなわち第1のデバイス910が選択され得る。第1のデバイス910は、CS App930により任意に選択され、あるいはCS App930により複数のデバイスのうちいずれか一つを選択可能にするユーザーインターフェース(UI)を提供し、このUIを通じてユーザーの入力を受信する方法により選択され得る。
【0142】
一つのデバイスが検索されても、該当デバイスに関する情報は、UIを通じてユーザーに提供し、それにより該当デバイスに接続されるか否かに対するユーザーの入力を受信することもある。UIを通じて情報を示す方法及びユーザーの入力を処理する方法は、実現に従って多様に変わることができる。
【0143】
第1のデバイス910が選択されると、CS App930は、ステップ1014において、第1のデバイス910でAppを実行することをCSランチャ928に指示する。このために、CS App930は、所定のAPIを呼び出すことができる。APIは、例えば、launchHbbTVApp()であり得る。これは、実現により変わることができる。
【0144】
第1のデバイス910のApp実行は、HTTPリクエストにより遂行され、第1のデバイス910に関する情報を獲得するプロセスと、これを通じてAppを実行するプロセスを含む2つのプロセスを含む。このようなプロセスで使用される詳細なプロトコルについては、以後、
図12を参照して詳細に説明する。
【0145】
CSランチャ928は、ステップ1016で、App実行要請を第1のデバイス910のCS管理部916に送信する。App実行要請は、HTTP POSTメソッドに基づき、HTTPリクエストのボディ部は、第1のデバイス910のApp情報を含むXML(すなわち、XML AIT)を含む。したがって、CS管理部916は、App実行要請を処理できるWebサーバ機能を有する。
【0146】
CS管理部916は、App実行の要請を処理し、ステップ1018で、XMLAITをAIT管理部918に送信する。AIT管理部918は、XML AIT に基づき、第2のデバイス920のCS App930と連動して使用される第1のデバイス910のAppである基本App940を実行させる。ここで、基本App940が内蔵型Appである場合、すべてのプロセスは、終了される。基本App940がWeb Appである場合に、ステップ1022及びステップ1024が遂行される。
【0147】
ステップ1022で、第1のデバイス910は、URL情報に基づいてWebサーバ900にWeb Appを要請し、ステップ1024で、Webサーバ900から基本App940に関連したWebページ(HTML、CSS、ジャバスクリプト、及びイメージを包含)を受信する。第1のデバイス910は、受信されたWebページに基づいて基本App940を実行する。ステップ1022及びステップ1024の動作は、Webブラウザ912を通じて遂行できる。
【0148】
下記の<表15>は、
図10で使用されるAPIを簡略に示す。
【0150】
<表15>を参照すると、discoverHbbTVdevices()は、入力要素を持たなく、ネットワークで利用可能な第1のデバイスのリストを獲得するために使用される。launchHbbTVApp()は、App実行ターゲットである第1のデバイスのIDを表す
unit target_deviceとXMLフォーマットで実行される第1のデバイスのApp情報を2個の入力要素として有し、第1のデバイスのAppを実行するために使用できる。
【0151】
次に、
図11を参照して、
図10のステップ1008について詳細に説明する。
【0152】
図11は、本発明の第3の実施形態による第2のデバイスが第1のデバイスを検索するプロセスを示す信号フロー図である。
【0153】
図11を参照すると、ステップ1100において、第2のデバイス920のCSランチャ928は、CS App930から機器検索要請が受信されると、ステップ1102で、第1のデバイス910が存在するかを検索する。例えば、CSランチャ928は、SSDPのM-SEARCHメッソード(M-SERACH要請及び応答)を使用し、CS App930に関連して連動が必要な第1のデバイス910を検索する。このとき、CSランチャ928は、次の<表16>に示すように、STヘッダーに検索しようとする機器に関する情報を含めて該当デバイスを特定できる。
【0155】
一方、第1のデバイス910のCS管理部916は、<表16>に示すような信号を受信すると、ステップ1104において、それに対する応答信号を第2のデバイス920に送信する。応答信号は、次の<表17>に示すように、UPnPデバイス情報を含むXMLファイルのURL情報を含み、URL情報は、LOCATIONヘッダーに含まれ得る。
【0157】
CSランチャ928は、応答信号を受信すると、ステップ1106で、応答信号に含まれたURL情報に基づいて第1のデバイス910に関する情報を要請する。すなわち、CSランチャ928は、次の<表18>のように、LOCATIONヘッダーに含まれるURL情報に基づいてHTTP GETメソッドを用いて第1のデバイス910に対するUPnPデバイス情報を要請する。
【0159】
すると、CS管理部916は、ステップ1108で、情報要請に応答して第1のデバイス910に関する情報とCS App930と連動して使用される第1のデバイス910のApp、すなわち基本App940のURL情報を第2のデバイス920に送信する。すなわち、CS管理部916は、UPnPデバイス情報を含むXMLファイルとともに基本App940を実行させるURL情報を次の<表19>に示すように“Application-URL”ヘッダーに含めて第2のデバイス920に送信する。
【0161】
<表19>において、“Application-URL”ヘッダーは、本発明の実施形態で基本App940を実行できるURL情報を含めるために任意に定められたものであって、実現に従って異なる名称に変更して使用できる。
【0162】
CSランチャ928は、上記のようなステップにより、第1のデバイス910に関する情報が獲得される場合、ステップ1110で、獲得した情報をCS App930に送信して機器検索動作を終了する。
【0163】
次に、
図10のステップ1016で示すように、第1のデバイス910のAppを実行する方法について、
図12を参照して説明する。
【0164】
図12は、本発明の第3の実施形態による無線通信システムにおいて、第1のデバイスのAppを実行するプロセスを示す信号フロー図である。
【0165】
図12を参照すると、第2のデバイス
920のCSランチャ928は、ステップ1200において、第1のデバイス910に関する情報、例えばApp情報を要請する。この要請は、HTTP GETメソッドを通じて実行され、次の<表20>のように示すことができる。
【0167】
<表20>において、<App Launch URL>は、
図11のステップ1108において、第1のデバイス910から受信されるApplication-URLヘッダーのURL情報を示し、AppNameは、第1のデバイス910のAppの名称を示す。本発明の第3の実施形態では、Appとの名称は、本発明の第3の実施形態で提供する特定サービスを制限する方法のために使用する。本発明の第3の実施形態では、このサービスは、HbbTVに限定されるが、その実現に従って変更可能である。
【0168】
第1のデバイス910のCS管理部916は、ステップ1202において、要請に対する応答で、第1のデバイス910に関する情報としてApp情報を送信する。App情報は、サービス終端点情報(付加サービス情報)及びUA(User Agent)情報を含むXMLファイルが含まれ得る。UA情報は、第2のデバイス920で、第1のデバイス910の性能を判断するために使用される。
【0169】
一方、App情報は、その一例として<表21>のように示すことができる。
【0171】
<表21>を参照すると、<x#HbbTV#terminal#UAString>は、UAストリング(string)情報を表し、<x#HbbTV#App2AppURL>は、App間通信のための情報を表し、<x#HbbTV#InterDevSyncURL>は、デバイス間同期サービスを提供するための情報を表す。App情報は、<表21>に示す情報以外にサービス別に必要な情報が存在する場合に追加されることもある。
【0172】
CSランチャ928は、App情報を受信し、受信した情報に基づいてステップ1204において、CS管理部916にApp実行を要請する。このような動作は、HTTPのPOSTメソッドに基づいて実行され、App実行のための要請は、一例として次の<表22>に示す。
【0174】
<表22>を参照すると、<App Launch URL>/AppNameは、<表20>の<AppLaunchURL>/AppNameと同一であり、実際に実行するAppの情報がXML形態(XML AIT)でボディ部に含まれて伝送できる。伝送されるXML AITは、次の<表23>のような情報を含むことができる。
【0176】
CS管理部916は、XML AITに基づいて第1のデバイス910のAppを実行させる。CS管理部916は、ステップ1206において、その実行結果を次の<表24>に示すように、HTTP応答コードを用いて第2のデバイス920に送信する。
【0178】
<表24>で、“201CREATED”は、HTTP応答コードを示し、HTTP応答コードは、一例として次の<表25>に示すようである。
【0180】
<表25>を参照すると、“201 CREATED”は、第1のデバイス910のAppの実行に成功したことを示し(<表25>では、例えばHbbTVAppの実行に成功したことを示し)、“401 Unauthorized”は、第1のデバイス910のApp実行がユーザーにより拒否されることを示し、“403 Forbidden”は、第1のデバイス910のApp実行が第1のデバイス910により拒否されることを示し、“404 NOT FOUND”は、第1のデバイス910のAppが存在しないことを示し、“503 SERVICE UNAVAILABLE”は、第1のデバイス910の特定動作により第1のデバイス910のAppを一時的に実行できないことを示す。
【0181】
次に、第2のデバイス920で第1のデバイス910のAppを終了させるプロセスについて説明する。Appの終了のための要請は、HTTPのDELETEメソッドにより実行できる。しかしながら、DELETEメソッドの場合、BODYメッセージを含めないため、終了させるAppを識別する方法が必要である。したがって、<表26>に示すように、XML AITに含まれたorgIDとappIDに基づいて終了させるAppを識別可能にする。次の<表26>は、App終了要請の一例を示す。
【0183】
以下、
図13を参照して、第1のデバイス910のApp実行及び終了動作について説明する。
【0184】
図13は、本発明の第3の実施形態による第1のデバイスがApp実行及び終了動作を実行するプロセスを示すフローチャートである。
【0185】
図13を参照すると、第1のデバイス
910は、ステップ1300において、第2のデバイス920からHTTPリクエストを受信する。第1のデバイス910は、ステップ1302において、HTTPリクエストに含まれているURL情報を分析して該当Appを確認する。第1のデバイス910は、確認したAppがシステムで所定の特定Appである場合、次のような動作を実行する。
【0186】
第1のデバイス910は、ステップ1304において、HTTPリクエストのメッソドを確認する。第1のデバイス910は、確認したメッソドがGETメッソドである場合、第2のデバイス920が第1のデバイス910のApp情報を要請すると判定し、ステップ1306において、サービス終端点及びUA情報を含むXMLファイルを生成する。第1のデバイス910は、ステップ1308において、ボディ部に生成されたXMLファイルを含めて第2のデバイス920に伝送する。上記のような送信動作は、ステップ1316の処理結果の応答と同一の動作と見なされる。
【0187】
一方、第1のデバイス910は、確認されたメソッドがPOSTメソッドである場合、第2のデバイス920が第1のデバイス910のAppの実行を指示すると判定し、ステップ1310に進む。第1のデバイス910は、ステップ1310において、HTTPリクエストのボディ部に含まれているXML AITを受信する。第1のデバイス910は、ステップ1312において、orgID及びappIDに基づいて該当Appの実行が可能であるか否かを判定する。このとき、第1のデバイス910は、第1のデバイス910に予め格納されている実行可能なAppリスト(white list)又は実行不可能なAppリスト(black list)に基づいて該当Appの実行が可能であるか否かを判定するか、あるいはユーザーの入力を受信して該当Appが実行可能であるか否かを判定できる。第1のデバイス910は、該当Appの実行が可能である場合、ステップ1314で該当Appを実行し、ステップ1316で処理結果を第2のデバイス920に送信する。ここで、第1のデバイス910は、実行している
Appに対応するappIDとorgIDを管理しなければならない。
【0188】
第1のデバイス910は、確認されたメソッドがDELETEメソッドである場合、第2のデバイス920がAppの終了を指示すると判定し、ステップ1318において、HTTPリクエストに含まれたorgID及びappIDを判定する。第1のデバイス910は、ステップ1320において、判定されたorgID及びappIDに対応するAppが実行中であると判定する。第1のデバイス910は、判定されたorgID及びappIDに対応するAppが実行中である場合、ステップ1322に進んで実行中であるAppを終了する権限があるか否かを判定する。第1のデバイス910は、Appを終了する権限がある場合、ステップ1324において、実行中であるAppを終了し、その結果をステップ1316で第2のデバイス920に送信する。
【0189】
次に、
図14を参照して、第2のデバイス920のApp実行に関連した全体的な動作を説明する。
【0190】
図14は、本発明の第3の実施形態による第2のデバイスのApp実行に関連した動作を示すフローチャートである。
【0191】
図14を参照すると、第2のデバイス920は、ステップ1400において、HTMLページを受信し、第2のデバイス920のApp(以下、‘第2のApp’と称する)を実行する。このとき、第2のAppが内蔵型Appである場合、HTMLページを受信する手順なしに第2のAppが実行できる。
【0192】
第2のデバイス920は、ステップ1402において、第1のデバイス910のApp(以下、‘第1のApp’と称する)の実行のために必要な情報を含んでいるXML AITをWebサーバ900から受信する。第2のデバイス920は、ステップ1404において、実行される第2のAppを通じて利用可能なデバイス(例えば、第1のデバイス910が存在するか否かを検索する。
【0193】
第2のデバイス920は、ステップ1406において、第1のデバイス
910が検索されない場合にステップ1418に進み、第2のAppの実行を終了する。第2のデバイス920は、第1のデバイス910が検索される場合、ステップ1408において、HTTP GETメソッドを使用して第1のデバイス910の情報を要請する。第2のデバイス920は、要請に対する応答でApp間通信のためのサービス終端点情報及び第1のデバイス910の性能に関する情報を含むUA情報を第1のデバイス910から受信する。UA情報は、第1のデバイス910のハードウェア特性(スクリーンサイズ、CPU速度、PVRサポートなど)、第1のデバイス910がサポートする特性(マルチスクリーン機能、DRMサポートなど)が含まれ得る。
【0194】
その後、第2のデバイス920は、ステップ1410において、UA情報に基づいて第1のデバイス910で第1のAppの実行が可能であるか否かを判定する。例えば、第1のデバイス910がHD程度の解像度をサポートする小さいスクリーンを有する。第1のAppが最小FHD程度の解像度を必要とする場合、第2のデバイス920は、第1のデバイス910で第1のAppの実行が不可能であると判定できる。したがって、この場合、第2のデバイス920は、第1のAppの実行を第1のデバイス910に要請することなく、ステップ1418に進む。
【0195】
一方、第2のデバイス920は、第1のAppの実行が第1のデバイス110で可能であると判定する場合、ステップ
1412に進行して第1のデバイス910で第1のAppの実行することを要請する。第1のAppを実行するための要請のためにHTTP POSTメソッドが使用され得る。
【0196】
第2のデバイス920は、ステップ1414において、サービス終端点情報に基づいて第1のデバイス910と第2のデバイス920との間の通信チャンネルを生成してApp間通信を実行する。第2のデバイス920は、第1のAppの実行を終了する必要がある場合、ステップ1416において、HTTP DELETEメソッドを使用して第1のデバイス910に第1のAppの実行を終了することを要請し、ステップ1418で記第2のAppの実行を終了する。
【0197】
図15は、本発明の第3の実施形態による方法が適用される一例を示す。
【0198】
図15において、Webサーバ900が放送社Webサーバであり、第1のデバイス910がDTVであり、第2のデバイス920が移動端末である場合を一例として示す。
【0199】
ユーザーは、第2のデバイス920を用いてWebサーバ910から電子プログラムガイド(EPG)を受信する。ユーザーは、EPGに基づいて所望する放送番組を選択し、選択した放送番組を第1のデバイス910で見ようとする。
【0200】
上記のような場合、第2のデバイス920は、ユーザーが所望する放送番組を選択する場合、ホームネットワーク内に利用可能な第1のデバイス910を検索する。第2のデバイス920は、第1のデバイス910が検索される場合、Webサーバ900から受信されたXML ALT情報を第1のデバイス910に送信する。すると、第1のデバイス910は、XML AIT情報に基づいて該当Appを実行させて第2のデバイス920で選択された放送番組をユーザーに見せられる。
【0201】
一方、上記では、本発明で提案した実施形態を3つに区分して説明したが、これら実施形態は、3つの実施形態のうち少なくとも2つが組み合わせて使用されるなど多様に変形して使用できる。
【0202】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体に対するコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ROM(Read-Only Memory)、RAM(Random-Access Memory)、CD-ROM、磁気テープ、フロッピー(登録商標)ディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体は、ネットワーク接続されたコンピュータシステムにわたって分散されることによって、コンピュータ読み取り可能なコードは分散形態で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における熟練されたプログラマにとっては容易に理解できることである。
【0203】
本発明の実施形態によるトポロジ処理方法は、ハードウェア、ソフトウェア、又はそれらの組み合わせの形態で実現可能であることがわかる。このようなソフトウェアは、例えば、揮発性又は非揮発性格納装置(例えば、削除可能/再書き込み可能なROM(Read Only Memory)、メモリ(例えば、RAM(Random Access Memory)、メモリチップ、及び集積回路(IC)チップ)、又は光学的に又は磁気的に記録可能な機械(例えば、コンピュータ)-読み取り可能な格納媒体(例えば、CD(Compact Disc)、DVD(Digital Versatile Disc)、磁気ディスク、及び磁気テープ)に格納することができる。トポロジ処理方法は、制御部及びメモリを含むコンピュータ又は移動端末により実現され得る。このメモリは、本発明の実施形態を実現するための命令を含むプログラムを格納するのに適合した機械読み取り可能な格納媒体であり得る。
【0204】
したがって、本発明は、本請求項により定められた装置及び方法を実現するための符号を含むプログラム、及びこのようなプログラムを格納する機械(例えば、コンピュータ)読み取り可能な格納媒体を含む。このプログラムは、有線/無線接続を通じて伝送される通信信号のような媒体を介して電気的に伝送でき、これに均等なものと共に本発明に含まれる。
【0205】
また、本発明の実施形態による装置は、有線又は無線で接続されるプログラム提供装置からプログラムを受信して格納できる。プログラム提供装置は、プログラム処理装置が設定されたコンテンツ保護方法を実行させる指示を含むプログラム、コンテンツ保護方法に必要な情報を格納するためのメモリ、グラフィック処理装置との有線又は無線通信を実行するための通信部、及びグラフィック処理装置の要請又は自動で該当プログラムを送受信装置に送信する制御部を含むことができる。
【0206】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。