(57)【特許請求の範囲】
【請求項１】
無線通信システムにおける第１のデバイスの第１のアプリケーションが第２のデバイスと通信する方法であって、
前記第１のデバイスで実行された前記第１のアプリケーションが前記第２のデバイスを発見するステップと、
前記第２のデバイスにサービス情報に対する要請を送信するステップと、
前記第２のデバイスから前記サービス情報を受信するステップと、
前記サービス情報から前記第２のデバイスの性能情報を含むＵＡ（user agent）情報を獲得するステップと、
前記ＵＡ情報に基づいて、前記第２のデバイスで実行される第２のアプリケーションのために必要な少なくとも一つの性能を前記第２のデバイスが提供するか否かを判断するステップと、  
前記判断結果に基づいて、前記第２のアプリケーションを実行するか否かを決定するステップと、を含むことを特徴とする方法。
【請求項２】
前記第２のデバイスを発見するステップは、
デバイス発見要請を送信するステップと、
前記第２のデバイスからユニフォームリソースロケータ(ＵＲＬ)情報を含むデバイス発見応答を受信するステップと、
前記ＵＲＬ情報に基づいて、前記第２のデバイスに関する情報を要請するデバイス情報要請を前記第２のデバイスに送信するステップと、
前記第２のデバイスに対する情報を含むデバイス情報応答を前記第２のデバイスから受信するステップと、
を有することを特徴とする請求項１に記載の方法。
【請求項３】
前記ＵＲＬ情報は、前記デバイス発見応答の位置ヘッダーから獲得されることを特徴とする請求項２に記載の方法。
【請求項４】
前記サービス情報は、前記第１のデバイスと前記第２のデバイスとの間の同期化のための第１のＵＲＬ情報、及び前記第１のアプリケーションと前記第２のアプリケーションとの間の通信のための第２のＵＲＬ情報をさらに含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第２のＵＲＬ情報は、前記第２のデバイスに含まれたサービスエンドポイントのＵＲＬ情報であることを特徴とする請求項４に記載の方法。
【請求項６】
無線通信システムにおける第１のデバイスであって、
送受信部と、  
前記第１のデバイスで第１のアプリケーションを実行して第２のデバイスを発見し、
前記第２のデバイスにサービス情報に対する要請を送信し、前記第２のデバイスから前記サービス情報を受信するように前記送受信部を制御し、
前記サービス情報から前記第２のデバイスの性能情報を含むＵＡ(user agent:ＵＡ)情報を獲得し、
前記ＵＡ情報に基づいて、前記第２のデバイスで実行される第２のアプリケーションのために必要な少なくとも一つの性能を前記第２のデバイスが提供するか否かを判断し、
前記判断結果に基づいて、前記第２のアプリケーションを実行するか否かを決定する制御部と、を含むことを特徴とする第１のデバイス。
【請求項７】
前記制御部は、デバイス発見要請を送信し、前記第２のデバイスからユニフォームリソースロケータ(ＵＲＬ)情報を含むデバイス発見応答を受信し、前記ＵＲＬ情報に基づいて、前記第２のデバイスに対する情報を要請するデバイス情報要請を前記第２のデバイスに要請し、前記第２のデバイスに対する情報を含むデバイス情報応答を前記第２のデバイスから受信するように前記送受信部を制御することを特徴とする請求項６に記載の第１のデバイス。
【請求項８】
前記ＵＲＬ情報は、前記デバイス発見応答の位置ヘッダーから獲得されることを特徴とする請求項７に記載の第１のデバイス。
【請求項９】
前記サービス情報は、前記第１のデバイスと前記第２のデバイスとの間の同期化のための第１のＵＲＬ情報、及び前記第１のアプリケーションと前記第２のアプリケーションとの間の通信のための第２のＵＲＬ情報をさらに含むことを特徴とする請求項７に記載の第１のデバイス。
【請求項１０】
前記第２のＵＲＬ情報は、前記第２のデバイスに含まれたサービスエンドポイントのＵＲＬ情報であることを特徴とする請求項９に記載の第１のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおけるアプリケーション実行方法及び装置に関するものである。
【背景技術】
【０００２】
最近、ネットワーク技術とマルチメディア技術の急速な進化に従って多様なタイプの機器が開発され、このような機器間のコンバージェンス(収束化)が加速化されている。それによって、デジタルＴＶ、ホームシアター、コンピュータ装置、移動端末のような各種デバイスがネットワーク環境を通じてデータを送受信し、収束化したサービスを提供することが頻繁に発生する。さらに、収束化したサービスの提供のために、機器間に相互動作を制御する方法又は機器間の関連した動作を遂行する方案の必要性が高まっている。
【０００３】
上記した情報は、本発明の理解を助けるための背景情報として表示されるだけである。上記のいずれかが本発明に関する従来技術として適用されるか否かに関しては、何の決定も判定も下されていない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、上記した従来技術の問題点を解決するための本発明の目的は、無線通信システムにおけるアプリケーション実行方法及び装置を提供することにある。
【０００５】
本発明の他の実施形態は、無線通信システムにおいて機器間にアプリケーション情報を送受信可能にする方法及び装置を提供することにある。
【０００６】
また、本発明の目的は、複数の機器に基づいてマルチスクリーンを使用可能にする方法及び装置を提供することにある。
【０００７】
さらに、本発明の目的は、複数の機器が接続されているネットワーク環境で機器間のアプリケーションを連動させて使用する方法及び装置を提供することにある。
【０００８】
本発明の他の目的は、アプリケーション連動動作を通じて機器間の制御動作を遂行する方法及び装置を提供することにある。
【課題を解決するための手段】
【０００９】
上記のような目的を達成するために、本発明の一態様によれば、無線通信システムにおける第１のデバイスによりアプリケーションを実行する方法が提供される。その方法は、第１のアプリケーションを用いて第２のデバイスを発見するステップと、第２のデバイスにより第２のアプリケーションを実行することを要請する情報を第２のデバイスに送信するステップとを有する。
【００１０】
本発明の他の態様によれば、無線通信システムにおける第１のデバイスによりアプリケーションを実行する方法が提供される。その方法は、第２のデバイスから第１のデバイスが第１のアプリケーションを実行することを要請する情報を受信するステップと、受信した情報に基づいて第１のアプリケーションを実行するステップとを有する。
【００１１】
また、本発明の他の態様によれば、無線通信システムにおける第１のデバイスが提供される。その第１のデバイスは、第１のアプリケーションを用いて第２のデバイスを発見し、第２のデバイスにより第２のアプリケーションを実行することを要請する情報を第２のデバイスに送信するアプリケーション部を含む。
【００１２】
さらに、本発明の他の態様によれば、無線通信システムにおける第１のデバイスが提供される。その第１のデバイスは、第２のデバイスから第１のデバイスが第１のアプリケーションを実行することを要請する情報を受信する管理部と、受信される情報に基づいて第１のアプリケーションを実行するアプリケーション部とを含む。
【００１３】
本発明の他の様態、長所、及び顕著な特徴は、添付された図面との結合を考慮すれば、後述する詳細な説明を参照してより容易に理解できることは、当該技術分野における通常の知識を持つ者には明らかである。
【００１４】
本発明を詳細に説明するのに先立って、本明細書の全般にわたって使用される特定の単語及び語句の定義を開示することが望ましい。“含む（include）”及び “備える（comprise）”という語句だけではなく、その派生語（derivatives thereof）は、限定ではなく、含みを意味する。“又は（or）”という用語は、“及び／又は（and/or）”の意味を包括する。“関連した（associated with）”及び“それと関連した（associated therewith）”という語句だけではなく、その派生語句は、“含む（include）”、“含まれる（be included within）”、“相互に連結する（interconnect with）”、“包含する（contain）”、“包含される（be contained within）”、“連結する（connect to or with）”、“結合する（couple to or with）”、“疎通する（be communicable with）”、“協力する（cooperate with）”、“相互配置する（interleave）”、“並置する（juxtapose）”、“近接する（be proximate to）”、“接する（be bound to or with）”、“有する（have）”、及び“特性を有する（have a property of）”などを意味することができる。制御部は、少なくとも１つの動作を制御する装置、システム又はその部分を意味するもので、ハードウェア、ファームウェア、ソフトウェア、又は、それらのうちの２つ以上の組合せで実現することができる。特定の制御部に関連する機能は、集中しているか、あるいは近距離、又は遠距離に分散されることもあることに留意すべきである。特定の単語及び語句に関するこのような定義は、本明細書の全般にわたって規定されるもので、当業者には、大部分の場合ではなくても、多くの場合において、このような定義がそのように定義された単語及び語句の先行使用にはもちろん、将来の使用にも適用されるものであることが自明である。
【発明の効果】
【００１５】
本発明は、複数の機器が接続されているネットワーク環境でＷｅｂ技術に基づいて機器間の発見動作及びアプリケーション情報の送受信動作を通じて第１のデバイスのアプリケーションを第２のデバイスが実行させるか、あるいは第２のデバイスのアプリケーションを第１のデバイスが実行させることを可能にする。例えば、第１のデバイスがデジタルＴＶであり、第２のデバイスが移動端末である場合、第２のデバイスは、第２のデバイスのアプリケーション(電子番組ガイド(Electronic  Program  Guide：ＥＰＧ)など)により第１のデバイスのブロードキャスティングに関連したアプリケーションを実行することができる。
【００１６】
さらに、本発明は、第１のデバイスが主要情報(放送番組又は放送情報)を表示し、第２のデバイスは付加情報(放送付加情報など)を表示することによってマルチスクリーンの使用をサポートすることができる。
【００１７】
また、本発明は、第２のデバイスが第２のデバイスのアプリケーション(リモートコントローラ)により第１のデバイスに対する制御動作(ボリューム設定及びチャンネル変更）を遂行することができる。その上、既存のハイブリッド放送環境では放送に関連したアプリケーションの情報が第１のデバイスで放送ネットワークを介して獲得しなければならなかったが、本発明では、第２のデバイスで第１のデバイスのアプリケーション情報を獲得することができる。
【００１８】
本発明のより完全な理解及びそれに従う利点は、添付された図面とともに考慮すれば、後述する詳細な説明を参照してより容易に理解できる。また、図面中、同一の参照符号は、同一であるか又は類似した構成要素を示す。
【図面の簡単な説明】
【００１９】
【図１】本発明の第１の実施形態による無線通信システムの概略的な構成を示す図である。
【図２】本発明の第１の実施形態による第１のデバイスにより第２のデバイスを発見してペアリングするプロセスを示す信号フロー図である。
【図３】本発明の第１の実施形態による第１のデバイスにより第２のデバイスのアプリケーションを実行するプロセスを示す信号フロー図である。
【図４】本発明の第１の実施形態による第２のデバイスにより第１のデバイスのアプリケーションを実行するプロセスを示す信号フロー図である。
【図５】本発明の第２の実施形態による無線通信システムの概略的な構成を示す図である。
【図６】本発明の第２の実施形態による第１のデバイスと第２のデバイスとの間の発見プロセスを示す信号フロー図である。
【図７】本発明の第２の実施形態による第１のデバイスと第２のデバイスとの間のアプリケーションを実行するプロセスを示す信号フロー図である。
【図８】本発明の第２の実施形態による方法が適用される一例を示す図である。
【図９】本発明の第３の実施形態による無線通信システムの概略的な構成を示す図である。
【図１０】本発明の第３の実施形態による無線通信システムにおいて、第２のデバイスにより第１のデバイスのアプリケーションを実行するプロセスを示す信号フロー図である。
【図１１】本発明の第３の実施形態による第２のデバイスにより第１のデバイスを検索するプロセスを示す信号フロー図である。
【図１２】本発明の第３の実施形態による無線通信システムにおける第１のデバイスのアプリケーションを実行するプロセスを示す信号フロー図である。
【図１３】本発明の第３の実施形態による第１のデバイスによりアプリケーション実行及び終了(termination)動作を遂行するプロセスを示すフローチャートである。
【図１４】本発明の第３の実施形態による第２のデバイスによりアプリケーションの実行に関連した動作を示すフローチャートである。
【図１５】本発明の第３の実施形態による方法が適用される一例を示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【００２１】
図面において、同一の構成要素に対してはできるだけ同一の参照符号及び参照番号を付して説明する。下記の説明で、本発明に関連した公知の機能又は構成に関する具体的な説明が本発明の要旨を不明にすると判断された場合に、その詳細な説明を省略する。また、後述する用語は、本発明の機能を考慮して定義されたものであって、ユーザー、運用者の意図、又は慣例によって変わることができる。したがって、上記用語は、本明細書の全体内容に基づいて定義されなければならない。
【００２２】
本発明は、多様な変更が可能であり、様々な実施形態を有することができるので、特定の実施形態を図面に例示して詳細に説明する。しかしながら、これは、本発明を特定の実施形態に対して限定するものではなく、本発明の思想及び技術範囲に含まれるすべての変更、均等物乃至代替物を含むことが理解されなければならない。
【００２３】
本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、“コンポーネント表面（a component surface）"との記載は、１つ又は複数の表面を含む。
【００２４】
‘第１’、‘第２’のように序数を含む用語は多様な構成要素を説明するために使用されるが、構成要素は、上記用語により限定されない。これらの用語は、一つの構成要素を他の構成要素から区別する目的のみで使われる。例えば、本発明の権利範囲を外れることなく、第１の構成要素は第２の構成要素と称され、同様に第２の構成要素も第１の構成要素と称され得る。‘及び／又は’という用語は、複数の関連した記載項目の組合せ又は複数の関連した記載項目のうち何れかの項目を含む。
【００２５】
また、本願明細書で使用される用語は、単に特定の実施形態を説明するために使用されるものであって、本発明を限定するものではない。単数形が、コンテキスト中に特記して明示されない限り、複数形を含むことは、当業者には容易に分かることであろう。また、‘含む’又は‘有する’などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品又はこれらの組合せが存在することを指定しようとするものであって、一つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品、若しくはこれらの組合せが、存在する或いは付加される可能性を予め排除しないことが理解されなければならない。
【００２６】
別に定義されない限り、ここで使用される技術的又は科学的な用語を含むすべての用語は、本発明が属する技術分野で通常の知識を持った者には一般的に理解される意味と同一の意味を有する。一般的に使用される辞典で定義されるような用語は、関連技術の文脈上有する意味と一致する意味を有すると解析されなければならなく、ここで明白に定義されない限り、理想的又は過度に形式的な意味で解析されない。
【００２７】
本発明の多様な実施形態によると、デバイスは、通信機能を含むことができる。例えば、デバイスは、スマートフォン、パーソナルコンピュータ(ＰＣ)、携帯電話、テレビ電話、電子書籍リーダ、デスクトップＰＣ、ラップトップＰＣ、ネットブックＰＣ、ＰＤＡ(Personal Digital Assistant)、ＰＭＰ(Portable Multimedia Player)、ｍｐ３プレーヤー、モバイル医療デバイス、カメラ、ウェアラブルデバイス(例えば、ＨＭＤ(Head-Mounted  Device)、電気衣類、電子ブレース(electronic brace)、電子ネックレス、電子アプセサリ(appcessory)、電子タトゥー、又はスマート時計)であってもよい。
【００２８】
本発明の実施形態によると、デバイスは、通信機能を有するスマート家電であってもよい。スマート家電は、例えばテレビジョン、ＤＶＤ(Digital Video Disk)プレーヤー、オーディオ、冷蔵庫、エアコン、電気掃除機、オーブン、電子レンジ、洗濯機、ドライヤー、空気清浄器、セットトップボックス、ＴＶボックス(例えば、Ｓａｍｓｕｎｇ  ＨｏｍｅＳｙｎｃ（登録商標）、Ａｐｐｌｅ  ＴＶ（登録商標）、又はＧｏｏｇｌｅ  ＴＶ（登録商標）)、ゲーム機、電子辞書、電子キー、カムコーダ、電子ピクチャーフレームであってもよい。
【００２９】
本発明の実施形態によると、デバイスは、医療機器(例えば、ＭＲＡ(Magnetic Resonance Antiography)装置、ＭＲＩ(Magnetic Resonance Imaging)装置、ＣＴ(Computed Tomography)機器、映像機器、又は超音波装置)、ナビゲーション機器、ＧＰＳ(Global Positioning System)受信器、イベントデータレコーダ(Event Data Recorder：ＥＤＲ)、フライトデータレコーダ(Flight Data Recorder：ＦＤＲ)、自動車用インフォテインメント装置、船舶用電子装置(例えば、船舶用ナビゲーション装置、ジャイロスコープ、又はコンパス)、航空電子機器、セキュリティ機器、産業又は個人用ロボットであってもよい。
【００３０】
本発明の実施形態によると、デバイスは、通信機能を有する家具、ビル/構造の一部、電子ボード、電子署名受信器、プロジェクタ、多様な測定装置(例えば、水、電気、ガス、又は電磁波測定装置)であってもよい。
【００３１】
本発明の実施形態によると、デバイスは、上記した装置の組み合わせであってもよい。また、本発明の実施形態による電子デバイスは、上記装置に制限されるものではないことは、当該技術分野における通常の知識を持つ者には明らかである。
【００３２】
本発明の実施形態によると、デバイスは、電子デバイスであってもよい。
【００３３】
本発明の一実施形態では、無線通信システムにおけるアプリケーション実行方法及び装置を提供することにある。無線通信システムは、複数の機器が接続されているネットワーク環境(例えば、ホームネットワーク環境など)での無線通信システムであり得る。無線通信システムにおいて、第１のデバイスと第２のデバイスが連動されて第２のデバイスのアプリケーションに関連した第１のデバイスのアプリケーションに関する情報を第２のデバイスが第１のデバイスに提供できる。具体的には、Ｗｅｂ技術に基づいて第２のデバイスが自身と連動される第１のデバイスを発見し、第２のデバイスのアプリケーションに関連した第１のデバイスのアプリケーションに関する情報を第１のデバイスに送信することにより、第１のデバイスのアプリケーションを実行できる。
【００３４】
本発明の一実施形態では、同一のネットワーク内で複数の機器間の連動に必要なシステム構成方法とともに、第２のデバイスと第１のデバイスとの間の連動のために必要な具体的なプロトコルが提供される。また、本発明の実施形態では、複数の機器間のアプリケーション連動のための共有フレームワークを提供することにより、今後共有フレームワークは、遠隔ユーザーインターフェース(Remote  User  Interface：ＲＵＩ)サービスに使用されるか、あるいは多様な放送標準環境で使用され得る。
【００３５】
一方、本発明の一実施形態において、アプリケーションは、ＨＴＭＬ５(Hypertext  Markup  Language  5）で作成されるＷｅｂアプリケーションと該当デバイスのオペレーティングシステム(ＯＳ)に依存する内蔵型(native)アプリケーションを全部含むことができる。以下、説明の便宜のために、アプリケーションを“Ａｐｐ”と称する。
【００３６】
以下、本発明の一実施形態について具体的に説明する。本発明の一実施形態では、次のような方法を提供する。
【００３７】
−第２のデバイスと第１のデバイスとの間の連動のための無線通信システムを構成
−第２のデバイスで第１のデバイスを発見する方法
−第１のデバイスで第２のデバイスを発見する方法
−第２のデバイスにより第１のデバイスの特定Ａｐｐを実行する方法
−第２のデバイスにより第１のデバイスの性能に適したＡｐｐを選択する方法
−第１のデバイスによりサービスを提供するためのサービスエンドポイント情報を提供する方法
＜第１の実施形態＞
図１は、本発明の第１の実施形態による無線通信システムの概略的な構成を示す。
【００３８】
図１を参照すると、無線通信システムは、Ｗｅｂサーバ１３０と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を実行し、例えば、ホームネットワーク内の無線通信が可能なデバイスであり得る。図１では、複数のデバイスのうち、相互に連動できる第１のデバイス１００と第２のデバイス１１０について説明する。
【００３９】
Ｗｅｂサーバ１３０は、第１のデバイス１００と第２のデバイス１１０で使用されるＷｅｂ  Ａｐｐ１０４，１１４を提供する。Ｗｅｂ  Ａｐｐ１０４，１１４は、ＨＴＭＬ、ＣＳＳ(Cascading  Style  Sheet)、ジャバスクリプト(javascript（登録商標）)、動画像、及びイメージなどで構成できる。一方、Ｗｅｂサーバ１３０は、ローカルネットワーク内に存在してもよく、あるいは外部ネットワーク(クラウド)に存在してもよい。
【００４０】
第１のデバイス１００は、Ａｐｐが実行されるメインデバイスを示す。例えば、第１のデバイス１００は、デジタルＴＶ(ＤＴＶ)又はセットトップボックス(ＳＴＢ）のような共有デバイスである。このとき、Ａｐｐは、放送に関連したＡｐｐであり得る。
【００４１】
第２のデバイス１１０は、第１のデバイス１００と連動してＡｐｐを実行する補助機器を示す。第２のデバイス１１０は、移動端末又はタブレットのような個人端末であり得る。
【００４２】
第１のデバイス１００と第２のデバイス１１０は、各々Ｗｅｂブラウザ１０２，１１２を含む。Ｗｅｂブラウザ１０２，１１２は、ＨＴＭＬ５及び関連Ｗｅｂ技術で構成されるＷｅｂ  Ａｐｐ１０４，１１４を実行するために使用される。
【００４３】
第２のデバイス１１０は、内蔵型Ａｐｐ１１６を含むことができる。内蔵型Ａｐｐ１１６は、第２のデバイス１１０のプラットフォーム(ＯＳ)(例えば、アンドロイド（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、及びＴｉＺｅｎ（登録商標）)で実行されるＡｐｐを表す。内蔵型Ａｐｐ１１６は、バイナリコードにコンパイルされて実行されることができる。
【００４４】
第１のデバイス１００に含まれるマルチスクリーン(ＭＳ）管理部１０６は、第２のデバイス１１０との連動に必要な動作を遂行する。すなわち、ＭＳ管理部１０６は、ネットワークで第２のデバイス１１０を発見し、Ａｐｐ起動(launch)情報を第２のデバイス１１０のＭＳランチャ(launcher)１１８に送信する。ＭＳ管理部１０６は、第２のデバイス１１０にＡｐｐ情報を伝送する機能、第２のデバイス１１０にＡｐｐ起動を要請する機能、及び第１のデバイス１００と第２のデバイス１１０のＡｐｐ間通信を可能にする機能を遂行できる。
【００４５】
第２のデバイス１１０に含まれるＭＳランチャ１１８は、第１のデバイス１００との連動に必要な動作を実行する。すなわち、ＭＳランチャ１１８は、ＭＳ管理部１０６と通信を遂行して第２のデバイス１１０のＡｐｐを実行する。ＭＳランチャ１１８は、ネットワークで第１のデバイス１００を発見する機能、第１のデバイス１００にＡｐｐ実行を要請する機能、及び第２のデバイス１１０と第１のデバイス１００との間のＡｐｐ間通信を可能にする機能を遂行する。
【００４６】
図２は、本発明の第１の実施形態による第１のデバイスにより第２のデバイスを発見してペアリングするプロセスを示す信号フロー図である。
【００４７】
図２を参照すると、第１のデバイス１００は、ステップ２１４において、Ｗｅｂブラウザ１０２を通じてＷｅｂサーバ１３０にＵＲＬ(Uniform  Resource  Locator)要請を送信することによって、Ｗｅｂページ伝送を要請する。第１のデバイス１００は、ステップ２１６において、Ｗｅｂサーバ１３０からＷｅｂページを受信する。ここで、Ｗｅｂブラウザ１０２は、受信されたＷｅｂページを基本(primary)Ａｐｐ１０５として処理して表示する。
【００４８】
Ｗｅｂブラウザ１０２により実行される基本Ａｐｐ１０５は、ステップ２１８において、第２のデバイス１１０を発見するために、所定のアプリケーションプログラムインターフェース(ＡＰＩ)(例えば、ｇｅｔＡｖａｉｌａｂｌｅＣＳＤｅｖｉｃｅ())を用いてＭＳ管理部１０６に利用可能な第２のデバイス１１０に対するリスト(第２のデバイスＩＤリスト)を要請する。
【００４９】
すると、ＭＳ管理部１０６は、ステップ２２０において、ネットワーク内に存在する第２のデバイス１１０を発見するために、第２のデバイス１１０のＭＳランチャ１１８に信号を送信し、ステップ２２２において、ＭＳランチャ１１８から応答信号を受信する。ここで、第２のデバイス１１０を発見するために使用されるプロトコルは、後述する第２の実施形態で定義されるプロトコルとなり得るが、これに関しては第２の実施形態でより具体的に説明する。ＭＳ管理部１０６は、応答信号が受信される場合、第２のデバイス１１０を利用可能な機器として判定し、ステップ２２４において、第２のデバイス１１０に関する情報を基本Ａｐｐ１０５に送信できる。
【００５０】
図２では、第２のデバイス１１０が１個である場合を例示したが、第２のデバイス１１０は、ネットワーク内に複数個が存在してもよい。この場合、ＭＳ管理部１０６で第２のデバイス１１０に対するリストが生成されて基本Ａｐｐ１０５に送信できる。
【００５１】
基本Ａｐｐ１０５は、ステップ２２６において、第２のデバイス１１０に関する情報を画面に表示することで、第２のデバイス１１０を使用するか否かに対するユーザーの選択を受信する。ここで、第２のデバイス１１０に関する情報を画面に表示する方法、ユーザーから選択される方法、及び第１のデバイス１００が自動で第２のデバイス１１０を選択する方法に関しては具体的に定義されない。しかしながら、基本Ａｐｐ１０５がＷｅｂ  Ａｐｐとして定義されるため、第２のデバイス１１０に関する情報は、ＪＡＶＡ（登録商標）スクリプトで処理されてＷｅｂページに表示されることにより、ユーザーから選択され得る。
【００５２】
基本Ａｐｐ１０５は、第２のデバイス１１０が選択されると、ステップ２２８において、第２のデバイス１１０の識別子(ＩＤ)及び第２のデバイスのＡｐｐであるＣＳ  Ａｐｐ１１５を実行するＵＲＬ情報を格納する。格納した情報は、以後第１のデバイス１００で第２のデバイス１１０のＣＳ  Ａｐｐ１１５を実行させるために使用される。
【００５３】
図３は、本発明の第１の実施形態による第１のデバイスにより第２のデバイスのＡｐｐを実行するプロセスを示す信号フロー図である。
【００５４】
図３を参照すると、ステップ３１４において、上記した図２のステップ２１４乃至ステップ２２８を通じて第２のデバイス１１０の発見及びペアリング過程を完了する場合、ステップ３１６において、基本Ａｐｐ１０４は、特定ＡＰＩ(例えば、ｓｅｎｄＣＳＵＲＩ())を用いて第２のデバイス１１０で実行されるＣＳ  Ａｐｐ１１５に関する情報をＭＳ管理部１０６に送信する。
【００５５】
すると、ＭＳ管理部１０６は、ステップ３１８において、第２のデバイス１１０のＭＳランチャ１１８に実行しなければならないＣＳ  Ａｐｐ１１５に関する情報を送信する。ＭＳランチャ１１８は、ステップ３２０において、実行すべきＣＳ  Ａｐｐ１１５に関する情報に含まれたＵＲＩ(Uniform  Resource  Identifier)情報(ＵＲＬ情報及びＵＲＮ(Uniform  Resource  Name)情報を包含)をＷｅｂブラウザ１１２に送信する。
【００５６】
Ｗｅｂブラウザ１１２は、ＵＲＩ情報に基づいて実行すべきＣＳ  Ａｐｐ１１５が内蔵型Ａｐｐであるか、あるいはＷｅｂ  Ａｐｐであるかを判定する。実行すべきＣＳ  Ａｐｐ１１５が内蔵型Ａｐｐである場合、Ｗｅｂブラウザ１１２は、ステップ３２２において、内蔵型Ａｐｐを実行する。
【００５７】
実行すべきＣＳ  Ａｐｐ１１５がＷｅｂ  Ａｐｐである場合、ステップ３２４において、Ｗｅｂブラウザ１１２は、ＵＲＩが含まれるＵＲＬ要請をＷｅｂサーバ１３０に送信することにより、Ｗｅｂページの送信を要請する。Ｗｅｂサーバ１３０からＷｅｂページが受信される場合、Ｗｅｂブラウザ１１２は、該当ＷｅｂページをＣＳ  Ａｐｐ１１５として表示する。
【００５８】
このように、ＣＳ  Ａｐｐ１１５は、第１のデバイス１００の基本Ａｐｐ１０５により実行されるため、基本Ａｐｐ１０５とＣＳ  Ａｐｐ１１５は、相互に関連して動作できる。
【００５９】
＜表１＞は、図２のステップ２１８及び図３のステップ３１６のように、第１のデバイス１００で使用できるＡＰＩを簡略に示す。
【００６０】
【表１】
0006543617.tif 000002
【００６１】
＜表１＞を参照すると、ｇｅｔＡｖａｉｌａｂｌｅＣＳＤｅｖｉｃｅ()は、入力要素(factor)を有しなく、ネットワークで利用可能な第２のデバイスのリストを獲得するために使われる。ｓｅｎｄＣＳＵＲＩ()は、Ａｐｐ実行ターゲットである第２のデバイスのＩＤを示すｕｎｉｔ  ｔａｒｇｅｔ_ｄｅｖｉｃｅと、実行される第２のデバイスのＡｐｐのＵＲＩ情報の２個の入力要素を有し、第２のデバイスのＡｐｐを実行するために使用され得る。
【００６２】
図４は、本発明の第１の実施形態による第２のデバイスにより第１のデバイスのＡｐｐを実行するプロセスを示す信号フロー図である。
【００６３】
図４を参照すると、ＣＳ  Ａｐｐ１１５が内蔵型Ａｐｐである場合、ステップ４１４において、ＣＳ  Ａｐｐ１１５は、ユーザーにより実行され得る。あるいは、ＣＳ  Ａｐｐ１１５がＷｅｂ  Ａｐｐである場合、ステップ４１６で、Ｗｅｂブラウザ１０２によりＷｅｂサーバ１３０にＵＲＬ要請を送信することにより、Ｗｅｂページの送信を要請する。Ｗｅｂサーバ１３０からＷｅｂページが受信される場合、Ｗｅｂブラウザ１１２は、ステップ４１８で受信されたＷｅｂページをＣＳ  Ａｐｐ１１５として表示する。
【００６４】
ＣＳ  Ａｐｐ１１５は、ステップ４２０において、特定ＡＰＩ(例えば、ｇｅｔＡｖａｉｌａｂｌｅＰｒｉｍａｒｙＤｅｖｉｃｅ())を用いてＭＳランチャ１１８に利用可能な第１のデバイス１００に対するリストを要請する。
【００６５】
すると、ＭＳランチャ１１８は、ステップ４２２において、ネットワーク内に存在する第１のデバイス１００を発見するために、第１のデバイス１００のＭＳ管理部１０６に信号を送信し、ステップ４２３でＭＳ管理部１０６から応答信号を受信する。ここで、第１のデバイス１００を発見するために使用されるプロトコルは、後述する第３の実施形態で定義されるプロトコルであり得る。ＭＳランチャ１１８は、応答信号が受信される場合、第１のデバイス１００が利用可能な機器であると判定し、ステップ４２４で、第１のデバイス１００に関する情報をＣＳ  Ａｐｐ１１５に送信できる。
【００６６】
一方、図４では、第１のデバイス１００が一つである場合を例示するが、第１のデバイス１００は、ネットワーク内に複数個が存在でき、この場合、ＭＳランチャ１１８で第１のデバイス１００に対するリストが生成されてＣＳ  Ａｐｐ１１５に送信され得る。
【００６７】
ＣＳ  Ａｐｐ１１５は、第１のデバイス１００に関する情報を画面に表示することによって、ユーザーから第１のデバイス１００を使用するか否かが選択される。ここで、第１のデバイス１００に関する情報を画面にどのように表示するか、あるいはユーザーからどのように選択されるか、又は第２のデバイス１１０から自動で第１のデバイス１００を選択するかに対しては具体的に定義されない。但し、第１のデバイス１１０に関する情報は、ＣＳ  Ａｐｐ１１５に伝送されるので、ＣＳ  Ａｐｐ１１５によりユーザーから選択される。
【００６８】
ＣＳ  Ａｐｐ１１５は、第１のデバイス１１０が選択される場合、ステップ４２６において、特定ＡＰＩ(ｌａｕｎｃｈＰｒｉｍａｒｙＡｐｐＵＲＩ())を用いて基本Ａｐｐ実行のための情報をＭＳランチャ１１８に送信する。すなわち、ＣＳ  Ａｐｐ１１５は、ＭＳランチャ１１８に第１のデバイス１００の情報と基本Ａｐｐ１０５に関する情報、例えばＵＲＩ情報を伝送する。すると、ＭＳランチャ１１８は、ステップ４２８で、伝送される情報に基づいて第１のデバイス１００で実行される基本Ａｐｐ１０５に関する情報を第１のデバイス１００のＭＳ管理部１０６に送信する。
【００６９】
ＭＳ管理部１０６は、ステップ４３０において、ＵＲＩ情報をＷｅｂブラウザ１０２に送信する。すると、Ｗｅｂブラウザ１０２は、ＵＲＩ情報に基づいて実行しなければならない基本Ａｐｐ１０５が内蔵型Ａｐｐであるか、あるいはＷｅｂ  Ａｐｐであるかを判定する。実行すべき基本Ａｐｐ１０５が内蔵型Ａｐｐである場合、Ｗｅｂブラウザ１０２は、ステップ４３２において、基本Ａｐｐ１０５として内蔵型Ａｐｐを実行する。
【００７０】
実行する基本Ａｐｐ１０５がＷｅｂ  Ａｐｐである場合、ステップ４３４において、Ｗｅｂブラウザ１０２は、ＵＲＩが含まれたＵＲＬ要請をＷｅｂサーバ１３０に送信することによって、Ｗｅｂページの送信を要請する。ステップ４３６において、Ｗｅｂサーバ１３０からＷｅｂページが受信される場合、Ｗｅｂブラウザ１０２は、該当Ｗｅｂページを基本Ａｐｐ１０５として表示する。
【００７１】
このように、基本Ａｐｐ１０５は、第２のデバイス１１０のＣＳ  Ａｐｐ１１５により実行されるため、基本Ａｐｐ１０５とＣＳ  Ａｐｐ１１５は、相互に関連されるように動作できる。
【００７２】
以下、＜表２＞は、図４のステップ４２０及びステップ４２６のように、第２のデバイス１１０で使用されるＡＰＩを簡略に示す。
【００７３】
【表２】
0006543617.tif 000003
【００７４】
＜表２＞を参照すると、ｇｅｔＡｖａｉｌａｂｌｅＰｒｉｍａｒｙＤｅｖｉｃｅ()は、入力要素を有しなく、ネットワークで利用可能な第１のデバイスのリストを獲得するために使用される。ｓｅｎｄＰｒｉｍａｒｙＡｐｐＵＲＩ()は、Ａｐｐ実行対象である第１のデバイスのＩＤを表すｕｎｉｔ  ｔａｒｇｅｔ_ｄｅｖｉｃｅと実行する第１のデバイスのＡｐｐのＵＲＩ情報を２個の入力要素として有し、第１のデバイスのＡｐｐを実行するために使用され得る。
＜第２の実施形態＞
図５は、本発明の第２の実施形態による無線通信システムの概略的な構成を示す。
【００７５】
図５を参照すると、無線通信システムは、Ｗｅｂサーバ５３０と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を遂行し、例えば、ホームネットワーク内の無線通信が可能な機器であり得る。図５では、複数のデバイスのうち相互に連動される第１のデバイス５００と第２のデバイス５２０について説明する。
【００７６】
第１のデバイス５００は、Ｗｅｂブラウザ５０４、内蔵型Ａｐｐ５０２、Ｗｅｂ  Ａｐｐ５０６、及び第２のデバイス５２０との連動のためのＭＳ管理部５０８を含む。第２のデバイス５２０は、Ｗｅｂブラウザ５２２、Ｗｅｂ  Ａｐｐ５２４、内蔵型Ａｐｐ５２６、及びＭＳランチャ５２８を含む。
【００７７】
図５において、Ｗｅｂブラウザ５０４，５２２だけでなくＷｅｂ  Ａｐｐ５０６，５２４、内蔵型Ａｐｐ５０２，５２６、ＭＳ管理部５０８、及びＭＳランチャ５２８は、各々図１のＷｅｂブラウザ１０２，１１２、Ｗｅｂ  Ａｐｐ１０４，１１４、内蔵型Ａｐｐ１１６、ＭＳ管理部１０６、及びＭＳランチャ１１８に対応する動作を遂行できる。
【００７８】
但し、図５のＭＳ管理部５０８及びＭＳランチャ５２８は、次のような細部的な構成を含むことができる。すなわち、ＭＳ管理部５０８は、ＵＰｎＰ(Universal  Plug  and  Play)部５１２、ＨＴＴＰサーバ５１４、及びＷｅｂソケットサーバ５１０を含み、ＭＳランチャ５２８は、ＵＰｎＰ部５３４及びＨＴＴＰサーバ５３２を含む。
【００７９】
ＵＰｎＰ部５１２，５３４は、第１のデバイス５００と第２のデバイス５２０両方ともに含まれ、デバイス発見動作を実行する。具体的に、ＵＰｎＰ部５１２，５３４は、簡単なサービス発見プロトコル(Simple  Service  Discovery  Protocol：ＳＳＤＰ)を用いてネットワークで他のデバイスを発見し、ネットワークに自身の存在を知らせる役割を遂行する。
【００８０】
ＨＴＴＰサーバ５１４，５３２は、第１のデバイス５００と第２のデバイス５２０の両方ともに含まれ、ＨＴＴＰプロトコルを介して要請を受信し、受信した要請による動作を実行する。本発明の第２の実施形態において、ＨＴＴＰサーバ５１４，５３２は、Ａｐｐ実行のために他の機器からＨＴＴＰ  ＧＥＴ及びＨＴＴＰ  ＰＯＳＴ要請を受信して該当要請による動作を実行する。本発明の第２の実施形態では、ＨＴＴＰサーバ５１４，５３２は、上記した動作以外にＷｅｂページを配布する一般的なＷｅｂサーバの動作は実行しない。
【００８１】
Ｗｅｂソケットサーバ５１０は、第１のデバイス５００に含まれ、Ｗｅｂソケットプロトコルを処理する動作を実行する。本発明の第２の実施形態において、Ｗｅｂソケットサーバ５１０は、第２のデバイス５２０からＷｅｂソケット要請を受信し、これを処理して第１のデバイス５００と第２のデバイス５２０のＡｐｐ間通信を可能にする動作を実行する。
【００８２】
以下、図６を参照して、第１のデバイス５００と第２のデバイス５２０間の発見動作について説明する。
【００８３】
図６は、本発明の第２の実施形態による第１のデバイスと第２のデバイスとの間の発見プロセスを示す信号フロー図である。図６で説明されるプロセスは、上記した＜表１＞のｇｅｔＡｖａｉｌａｂｌｅＣＳＤｅｖｉｃｅ(）の詳細プロトコルの具体的な動作に該当する。
【００８４】
まず、第１のデバイス５００が第２のデバイス５２０を発見する例から説明する。図６を参照すると、第１のデバイス５００のＵＰｎＰ部５１２は、ステップ６２２において、デバイス発見のための信号を送信する。例えば、ＵＰｎＰ部５１２は、ネットワークで利用可能な第２のデバイス５２０を検索するためにＳＳＤＰのＭ-ＳＥＡＲＣＨメソッド(method)を使用して次の＜表３＞に示すような信号を送信できる。
【００８５】
【表３】
0006543617.tif 000004
【００８６】
第２のデバイス５２０のＵＰｎＰ部５３４は、上記のような信号が受信されると、ステップ６２４において、ＵＲＬ情報が含まれた応答信号を第１のデバイス５００に送信することにより、自身の存在を第１のデバイス５００に通知する。例えば、ＵＰｎＰ部５３４は、＜表４＞に示すような応答信号を送信し、この応答信号は、ＬＯＣＡＴＩＯＮヘッダーに第２のデバイス５２０に関する情報に関連したＵＲＬ情報を含むことができる。
【００８７】
【表４】
0006543617.tif 000005
【００８８】
第１のデバイス５００のＵＰｎＰ部５１２は、応答信号を受信すると、ステップ６２６において、応答信号のＬＯＣＡＴＩＯＮヘッダーに含まれるＵＲＬ情報を用いて第２のデバイス５２０に関する情報を要請する。このとき、上記要請は、ＨＴＴＰ  ＧＥＴメソッドに基づいて遂行できる。
【００８９】
第２のデバイス５２０のＨＴＴＰサーバ５３２は、ステップ６２８において、要請に対応して第２のデバイス５２０のＡｐｐ、すなわちＣＳ  Ａｐｐ５２７を実行させるために使用されるＵＲＬ情報が含まれる応答信号を第１のデバイス５００に送信する。応答信号は、その一例として、ＨＴＴＰ  Ｒｅｓｐｏｎｓｅ形態で＜表５＞に示すようなＣＳ  Ａｐｐ５２７を実行させるために使用されるＵＲＬ情報が含まれたヘッダー(ｘ−Ａｐｐｌｉｃａｔｉｏｎ−ＵＲＬ)を含むことができる。
【００９０】
【表５】
0006543617.tif 000006
【００９１】
次に、第２のデバイス５２０が第１のデバイス５００を発見する一例を説明する。
【００９２】
第２のデバイス５２０のＵＰｎＰ部５３４は、ステップ６３０において、機器発見のための信号を送信する。例えば、ＵＰｎＰ部５３４は、ネットワークで利用可能な第１のデバイス５００を検索するためにＳＳＤＰのＭ-ＳＥＡＲＣＨメソッドを使用して下記の＜表６＞に示すような信号を送信できる。
【００９３】
【表６】
0006543617.tif 000007
【００９４】
第１のデバイス５００のＵＰｎＰ部５１２は、上記の信号を受信すると、ステップ６３２において、ＵＲＬ情報が含まれた応答信号を第２のデバイス５２０に送信することによって、自身の存在を第２のデバイス５２０に通知する。例えば、ＵＰｎＰ部５１２は、下記の＜表７＞に示すような応答信号を送信し、この応答信号は、ＬＯＣＡＴＩＯＮヘッダーに第１のデバイス５００に関する情報に関連したＵＲＬ情報を含むことができる。
【００９５】
【表７】
0006543617.tif 000008
【００９６】
第２のデバイス５２０のＨＴＴＰサーバ５３２は、応答信号を受信すると、ステップ６３４において、応答信号のＬＯＣＡＴＩＯＮヘッダーに含まれたＵＲＬ情報を用いて第１のデバイス５００に関する情報を要請する。このとき、要請は、ＨＴＴＰ  ＧＥＴメソッドに基づいて実行できる。
【００９７】
第１のデバイス５２０のＵＰｎＰ部５１２は、ステップ６３６において、要請に対応して第１のデバイス５００のＡｐｐ、すなわち基本Ａｐｐ５０７を実行させるために使用されるＵＲＬ情報が含まれた応答信号を第２のデバイス５２０に送信する。応答信号は、一例としてＨＴＴＰ  Ｒｅｓｐｏｎｓｅ形態で、＜表８＞に示すような基本Ａｐｐ５０７を実行させるために使用されるＵＲＬ情報が含まれたヘッダー(ｘ-Ａｐｐｌｉｃａｔｉｏｎ-ＵＲＬ)を含むことができる。
【００９８】
また、第１のデバイス５００は、第２のデバイス５２０のＡｐｐとＡｐｐとの間の通信を実行するＷｅｂソケットサーバ５１０を有するので、ステップ６３８において、Ｗｅｂソケットサーバ５１０に接続できるＵＲＬ情報が含まれるヘッダー(ｘ-ＷｅｂＳｏｃｋｅｔ)を応答信号に含めて第２のデバイス５２０に送信する。
【００９９】
【表８】
0006543617.tif 000009
【０１００】
図７は、本発明の第２の実施形態による第１のデバイスと第２のデバイスとの間のＡｐｐを実行するプロセスを示す信号フロー図である。図７で説明するプロセスは、上記した＜表１＞のｓｅｎｄＣＳＵＲＩ(）の詳細プロトコルの具体的な動作に該当する。
【０１０１】
まず、第１のデバイス５００が第２のデバイス５２０のＡｐｐを実行するプロセスを説明する。図７を参照すると、第１のデバイス５００のＭＳ管理部５０８は、ステップ７２２において、第１のデバイス５００のブラウザ５０６からｓｅｎｄＣＳＵＲＩ()を通じて２個の要素が伝送される。２個の要素のうちいずれか一つであるｕｎｉｔ  ｔａｒｇｅｔ_ｄｅｖｉｃｅは、Ａｐｐ実行対象である第２のデバイス５２０のＩＤを示すが、ＭＳ管理部５０８は、第２のデバイス情報テーブルに基づいて第２のデバイス５２０のＡｐｐを実行させるためのＵＲＬ情報(ｘ-Ａｐｐｌｉｃａｔｉｏｎ-ＵＲＬ)を獲得できる。第２のデバイス情報テーブルは、ＭＳ管理部５０８に格納されて管理でき、例えば＜表９＞に示すようである。
【０１０２】
【表９】
0006543617.tif 000010
【０１０３】
＜表９＞に示すように、第２のデバイス情報テーブルは、第２のデバイスＩＤ、デバイス種類を示す機器説明情報及び第２のデバイスＡｐｐ  ＵＲＬ情報を含むことができる。
【０１０４】
第１のデバイス５００のＭＳ管理部５０８は、獲得したＵＲＬ情報に基づき、ステップ７２４において、第２のデバイス５２０のＨＴＴＰサーバ５３２に＜表１０＞に示すようなＨＴＴＰ  Ｐｏｓｔ要請を送信する。
【０１０５】
【表１０】
0006543617.tif 000011
【０１０６】
このとき、第２のデバイス５２０で実行されるＡｐｐは、ＣＳＡｐｐＰａｔｈにＵＲＩ情報で指示され、これは、ｓｅｎｄＣＳＵＲＩ(）の他の一つの要素であるｃｈａｒ＊ＵＲＩ値である。また、第２のデバイス５２０のＡｐｐを実行させるとき、必要な要素は、ＨＴＴＰのボディー部に＜表１０＞に示すような形式に基づいて送信され得る。
【０１０７】
第２のデバイス５２０のＨＴＴＰサーバ５３２は、ステップ７２６において、受信されたＨＴＴＰ  ＰＯＳＴをパーシング(parsing)してボディー部の要素とともにＣＳＡｐｐＰａｔｈ情報をＭＳランチャ５２８に伝送する。すると、ＭＳランチャ５２８は、ステップ７２８において、ＣＳＡｐｐＰａｔｈに含まれたＵＲＩ情報に基づいて第２のデバイス５２０のＡｐｐであるＣＳ  Ａｐｐ５２７を実行する。
【０１０８】
ＭＳランチャ５２８は、ステップ７３０において、ＣＳ  Ａｐｐ５２７の実行結果(例えば、ＣＳ  Ａｐｐ５２７の実行に成功)が受信される場合、ステップ７３２において、ＣＳ  Ａｐｐ５２７の実行結果を第２のデバイス５２０のＨＴＴＰサーバ５３２に送信する。すると、ＨＴＴＰサーバ５３２は、ＣＳ  Ａｐｐ５２７の実行結果に従ってステップ７３４において、第１のデバイス５００のＭＳ管理部５０８に下記の＜表１１＞に示すような応答コードのうち一つ(例えば、２０１  ＣＲＥＡＴＥＤ)を送信する。
【０１０９】
【表１１】
0006543617.tif 000012
【０１１０】
＜表１１＞において、応答コード２０１  ＣＲＥＡＴＥＤは、ＣＳ  Ａｐｐ５２７の実行に成功したことを表し、応答コード４０４  ＮＯＴ  ＦＯＵＮＤは、ＣＳ  Ａｐｐ５２７が存在しないことを表し、応答コード５０３  ＳＥＲＶＩＣＥ  ＵＮＡＶＡＩＬＡＳＢＬＥは、第２のデバイス５２０が他のＡｐｐを実行することにより、ＣＳ  Ａｐｐ５２７が暫く実行できないことを示す。
【０１１１】
次に、第２のデバイス５２０が第１のデバイス５００のＡｐｐを実行するプロセスを説明する。
【０１１２】
第２のデバイス５２０のＭＳランチャ５２８は、ステップ７３６において、第２のデバイス５２０のブラウザ５２２からｓｅｎｄＰｒｉｍａｒｙＡｐｐＵＲＩ()を通じて２個の要素を受信する。２個の要素のうちいずれか一つであるｕｎｉｔ target_deviceはＡｐｐ実行対象である第１のデバイス５２０のＩＤを表す。ＭＳランチャ５２８は、第１のデバイス情報テーブルに基づいて第１のデバイス５００のＡｐｐを実行させるためのＵＲＬ情報(x-Ａｐｐｌｉｃａｔｉｏｎ-ＵＲＬ)を獲得できる。第１のデバイス情報テーブルは、ＭＳランチャ５２８に格納されて管理され、その一例として＜表１２＞に示すようである。
【０１１３】
【表１２】
0006543617.tif 000013
【０１１４】
＜表１２＞に示すように、第１のデバイス情報テーブルは、第１のデバイスＩＤ、機器種類を示すデバイスディスクリプタ情報、第１のデバイスＡｐｐ  ＵＲＬ情報、及びＷｅｂソケット情報を含むことができる。
【０１１５】
第２のデバイス５２０のＭＳランチャ５２８は、獲得したＵＲＬ情報に基づき、ステップ７３８において、第１のデバイス５００のＨＴＴＰサーバ５１４に下記の＜表１３＞に示すようなＨＴＴＰ  Ｐｏｓｔ要請を送信する。
【０１１６】
【表１３】
0006543617.tif 000014
【０１１７】
このとき、第１のデバイス５００で実行されるＡｐｐは、ＰｒｉｍａｒｙＰａｔｈにＵＲＩ情報で指示され、ｓｅｎｄＰｒｉｍａｒｙＡｐｐＵＲＩ(）の他の一つの要素であるｃｈａｒ＊ＵＲＩ値である。また、第１のデバイス５００のＡｐｐを実行させるとき、必要な要素は、ＨＴＴＰのボディー部に＜表１３＞のような形式に基づいて送信され得る。
【０１１８】
第１のデバイス５００のＨＴＴＰサーバ５１４は、ステップ７４０において、受信されたＨＴＴＰ  ＰＯＳＴをパーシングしてボディー部の要素とともにＰｒｉｍａｒｙＡｐｐＰａｔｈ情報をＭＳ管理部５０８に伝送する。すると、ＭＳ管理部５０８は、ステップ７４２において、ＰｒｉｍａｒｙＡｐｐＰａｔｈに含まれたＵＲＩ情報に基づいて第１のデバイス５００のＡｐｐである基本Ａｐｐ５０６を実行する。
【０１１９】
ＭＳ管理部５０８は、ステップ７４４において、基本Ａｐｐ５０６の実行結果(例えば、基本Ａｐｐ５０６の実行に成功)が受信される場合、ステップ７４６において、基本Ａｐｐ５０６の実行結果を第１のデバイス５００のＨＴＴＰサーバ５１４に送信する。すると、ＨＴＴＰサーバ５１４は、基本Ａｐｐ５０６の実行結果により、ステップ７４８において、第２のデバイス５２０ののＭＳランチャ５２８に下記の＜表１４＞に示すような応答コードのうちいずれか一つ(例えば、２０１ＣＲＥＡＴＥＤ)を送信する。
【０１２０】
【表１４】
0006543617.tif 000015
【０１２１】
＜表１４＞において、応答コード２０１ＣＲＥＡＴＥＤは、基本Ａｐｐ５０６の実行に成功したことを示し、応答コード４０４ＮＯＴ  ＦＯＵＮＤは、基本Ａｐｐ５０６が存在しないことを示し、応答コード５０３ＳＥＲＶＩＣＥ  ＵＮＡＶＡＩＬＡＢＬＥは、第１のデバイス５００が異なる動作(例えば、ＴＶチャンネルスキャン動作など）を遂行するに従って、基本Ａｐｐ５０６が少しの間実行されないことを示す。
【０１２２】
図８は、本発明の第２の実施形態による方法が適用される例を示す。
【０１２３】
図８では、Ｗｅｂサーバ５３０が放送社のＷｅｂサーバであり、第１のデバイス５００はデジタルＴＶ(ＤＴＶ)であり、第２のデバイス５２０は移動端末である場合を一例として示す。
【０１２４】
ユーザーは、第１のデバイス５００を用いてＷｅｂサーバ５３０からストリーミングされる映画８００を視聴できる。このとき、ユーザーは、映画の視聴中に該当映画に対する付加情報を第２のデバイス５３０を通じて受信しようとする。
【０１２５】
この場合、第１のデバイス５００は、第２のデバイス５２０のＡｐｐのＵＲＬ情報８２０に基づいて付加情報を提供する第２のデバイス５２０のＡｐｐを実行させることができる。第２のデバイス５２０のＡｐｐが実行される場合、Ｗｅｂサーバ５３０から付加情報８１０を受信して第２のデバイス５２０は、受信された付加情報８１０をユーザーに提供する。付加情報は、例えばキャスティング情報、映画のシノプシス、及びオンラインショッピングを含むことができる。
＜第３の実施形態＞
図９は、本発明の第３の実施形態による無線通信システムの概略的な構成を示す。
【０１２６】
図９を参照すると、無線通信システムは、Ｗｅｂサーバ９００と複数のデバイスを含む。複数のデバイスは、同一のネットワークで通信を実行でき、例えば、ホームネットワーク内の無線通信が可能な機器であり得る。図９では、複数のデバイスのうち、相互に連動できる第１のデバイス９１０と第２のデバイス９２０について説明する。
【０１２７】
Ｗｅｂサーバ９００は、第１のデバイス９１０と第２のデバイス９２０で利用可能なＷｅｂ  Ａｐｐ９１４、９２４を提供する。Ｗｅｂ  Ａｐｐ９１４，９２４は、ＨＴＭＬ、ＣＳＳ、ジャバスクリプト、動画像、及びイメージを含むことができる。一方、Ｗｅｂサーバ９００は、ローカルネットワーク内に存在してもよく、あるいは外部ネットワーク(クラウド)に存在してもよい。Ｗｅｂサーバ９００は、第１のデバイス９１０のＡｐｐを実行するためのＡｐｐ情報、すなわちＸＭＬ(Extensible  Markup  Language）に基づいて生成されたＡｐｐ情報(以下、‘ＸＭＬ  ＡＩＴ’と称する)を提供できる。ここで、ＸＭＬ  ＡＩＴを提供するＷｅｂサーバとＷｅｂ  Ａｐｐを提供するＷｅｂサーバは、同一のデバイスでもよく、異なるデバイスでもよい。
【０１２８】
第１のデバイス９１０は、Ａｐｐが実行されるメインデバイスを表す。例えば、第１のデバイス９１０は、ＤＴＶ又はＳＴＢのような共有機器であり得る。このとき、Ａｐｐは、放送に関連したＡｐｐであり得る。
【０１２９】
第２のデバイス９２０は、第１のデバイス９１０と連動してＡｐｐを実行する補助デバイスを示す。第２のデバイス９２０は、移動端末又はタブレットのような個人端末であり得る。
【０１３０】
第１のデバイス９１０と第２のデバイス９２０は、各々Ｗｅｂブラウザ９１２，９２２を含む。Ｗｅｂブラウザ９１２，９２２は、Ｗｅｂ  Ａｐｐ９１４，９２４を実行するために使用される。
【０１３１】
第２のデバイス９２０は、内蔵型Ａｐｐ９２６を含むことができる。内蔵型Ａｐｐ９２６は、第２のデバイス９２０のプラットフォーム(ＯＳ)(例えば、アンドロイド（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、及びＴｉＺｅｎ（登録商標）)で実行されるＡｐｐを示す。内蔵型Ａｐｐ９２６は、バイナリコードにコンパイルされて実行できる。
【０１３２】
本発明の第３の実施形態において、第１のデバイス９１０は、ＣＳ(Companion  Screen)管理部９１６とアプリケーション情報テーブル(Application  Information  Table：ＡＩＴ)管理部９１８をさらに含むことができる。ＣＳ管理部９１６は、第２のデバイス９２０との連動のために必要な動作を実行する。例えば、ＣＳ管理部９１６は、該当ネットワークで第２のデバイス９２０を検索又は発見する動作、第２のデバイス９２０から第１のデバイス９１０で実行されるＡｐｐ情報を受信する動作、及び第１のデバイス９１０と第２のデバイス９２０とのＡｐｐ間の通信のための動作を実行できる。
【０１３３】
ＡＩＴ管理部９１８は、第１のデバイス９１０に含まれ、ＸＭＬ  ＡＩＴを受信してパーシングする。ＸＭＬ  ＡＩＴは、第２のデバイス９２０から送信された情報であって、ＣＳ管理部９１６により受信されてＡＩＴ管理部９１８に伝送される。ＡＩＴ管理部９１８は、ＸＭＬ  ＡＩＴをパーシングして該当Ａｐｐに関する情報を抽出し、抽出した情報に基づいて該当Ａｐｐを実行させる。
【０１３４】
第２のデバイス９２０は、ＣＳランチャ９２８をさらに含む。ＣＳランチャ９２８は、第１のデバイス９１０との連動に必要な動作を実行する。例えば、ＣＳランチャ９２８は、該当ネットワークで第１のデバイス９１０を検索又は発見する動作、Ａｐｐの要請により第１のデバイス９１０にＡｐｐの実行を要請する動作、Ａｐｐに関する情報を伝送する動作、及び第１のデバイス９１０と第２のデバイス９２０とのＡｐｐ間の通信のための動作を実行できる。
【０１３５】
以下、図９に示すような無線通信システムにおいて、第２のデバイス９２０により第１のデバイス９１０のＡｐｐを実行する方法について説明する。
【０１３６】
図１０は、本発明の第３の実施形態による無線通信システムにおいて、第２のデバイスにより第１のデバイスのＡｐｐを実行させるプロセスを示す信号フロー図である。
【０１３７】
図１０を参照すると、ステップ１０００において、第２のデバイス９２０は、ＣＳ  Ａｐｐ９３０を実行させる。ＣＳ  Ａｐｐ９３０は、第１のデバイス９１０のＡｐｐを実行するために使用される第２のデバイス９２０のＡｐｐであり得る。ＣＳ  Ａｐｐ９３０は、Ｗｅｂ  Ａｐｐ９２４及び内蔵型Ａｐｐ９２６のうちいずれか一つであり、ＣＳ  Ａｐｐ９３０がＷｅｂ  Ａｐｐ９２４である場合には、ステップ１００２及びステップ１００４でＣＳ  Ａｐｐ９３０が実行される。
【０１３８】
すなわち、ＣＳ  Ａｐｐ９３０がＷｅｂ  Ａｐｐ９２４である場合、ステップ１００２で、第２のデバイス９２０は、ＵＲＬ情報に基づいてＷｅｂサーバ９００にＣＳ  Ａｐｐ９３０を提供することを要請し、ステップ１００４で、Ｗｅｂサーバ９００からＣＳ  Ａｐｐ９３０に関連したＷｅｂページ(ＨＴＭＬ、ＣＳＳ、ジャバスクリプト、及びイメージを包含)を受信する。第２のデバイス９２０は、受信されたＷｅｂページをＣＳ  Ａｐｐ９３０として実行する。ステップ１００２及びステップ１００４の動作は、Ｗｅｂブラウザ９２２を用いて実行し、ＣＳ  Ａｐｐ９３０が内蔵型Ａｐｐ９２６である場合には省略することができる。
【０１３９】
ＣＳ  Ａｐｐ９３０が実行される場合、ＣＳ  Ａｐｐ９３０は、ステップ１００６において、該当ネットワークで利用可能な他のデバイスが存在するかに対する機器検索要請をＣＳランチャ９２８に送信する。すると、ＣＳランチャ９２８は、ステップ１００８で機器検索を実行し、ステップ１０１０で検索される機器に関する情報をＣＳ  Ａｐｐ９３０に送信する。
【０１４０】
機器検索要請と機器検索動作は、ＣＳ  Ａｐｐ９３０の所定のＡＰＩに基づいて実行され得る。すなわち、ＣＳ  Ａｐｐ１３０によりＡＰＩが実行される場合、ＣＳランチャ９２８による実際の機器検索動作が実行される。ＡＰＩは、例えばｄｉｓｃｏｖｅｒＨｂｂＴＶｄｅｖｉｃｅｓ()と同一であり、その実現に従って変わり得る。
【０１４１】
一方、複数のデバイスが検索される場合、複数のデバイスに関する情報は、ＣＳ  Ａｐｐ９３０に送信される。ステップ１０１２において、ＣＳ  Ａｐｐ９３０で複数のデバイスのうちいずれか一つ、すなわち第１のデバイス９１０が選択され得る。第１のデバイス９１０は、ＣＳ  Ａｐｐ９３０により任意に選択され、あるいはＣＳ  Ａｐｐ９３０により複数のデバイスのうちいずれか一つを選択可能にするユーザーインターフェース(ＵＩ)を提供し、このＵＩを通じてユーザーの入力を受信する方法により選択され得る。
【０１４２】
一つのデバイスが検索されても、該当デバイスに関する情報は、ＵＩを通じてユーザーに提供し、それにより該当デバイスに接続されるか否かに対するユーザーの入力を受信することもある。ＵＩを通じて情報を示す方法及びユーザーの入力を処理する方法は、実現に従って多様に変わることができる。
【０１４３】
第１のデバイス９１０が選択されると、ＣＳ  Ａｐｐ９３０は、ステップ１０１４において、第１のデバイス９１０でＡｐｐを実行することをＣＳランチャ９２８に指示する。このために、ＣＳ  Ａｐｐ９３０は、所定のＡＰＩを呼び出すことができる。ＡＰＩは、例えば、ｌａｕｎｃｈＨｂｂＴＶＡｐｐ()であり得る。これは、実現により変わることができる。
【０１４４】
第１のデバイス９１０のＡｐｐ実行は、ＨＴＴＰリクエストにより遂行され、第１のデバイス９１０に関する情報を獲得するプロセスと、これを通じてＡｐｐを実行するプロセスを含む２つのプロセスを含む。このようなプロセスで使用される詳細なプロトコルについては、以後、図１２を参照して詳細に説明する。
【０１４５】
ＣＳランチャ９２８は、ステップ１０１６で、Ａｐｐ実行要請を第１のデバイス９１０のＣＳ管理部９１６に送信する。Ａｐｐ実行要請は、ＨＴＴＰ  ＰＯＳＴメソッドに基づき、ＨＴＴＰリクエストのボディ部は、第１のデバイス９１０のＡｐｐ情報を含むＸＭＬ(すなわち、ＸＭＬ  ＡＩＴ)を含む。したがって、ＣＳ管理部９１６は、Ａｐｐ実行要請を処理できるＷｅｂサーバ機能を有する。
【０１４６】
ＣＳ管理部９１６は、Ａｐｐ実行の要請を処理し、ステップ１０１８で、ＸＭＬＡＩＴをＡＩＴ管理部９１８に送信する。ＡＩＴ管理部９１８は、ＸＭＬ  ＡＩＴ  に基づき、第２のデバイス９２０のＣＳ  Ａｐｐ９３０と連動して使用される第１のデバイス９１０のＡｐｐである基本Ａｐｐ９４０を実行させる。ここで、基本Ａｐｐ９４０が内蔵型Ａｐｐである場合、すべてのプロセスは、終了される。基本Ａｐｐ９４０がＷｅｂ  Ａｐｐである場合に、ステップ１０２２及びステップ１０２４が遂行される。
【０１４７】
ステップ１０２２で、第１のデバイス９１０は、ＵＲＬ情報に基づいてＷｅｂサーバ９００にＷｅｂ  Ａｐｐを要請し、ステップ１０２４で、Ｗｅｂサーバ９００から基本Ａｐｐ９４０に関連したＷｅｂページ(ＨＴＭＬ、ＣＳＳ、ジャバスクリプト、及びイメージを包含)を受信する。第１のデバイス９１０は、受信されたＷｅｂページに基づいて基本Ａｐｐ９４０を実行する。ステップ１０２２及びステップ１０２４の動作は、Ｗｅｂブラウザ９１２を通じて遂行できる。
【０１４８】
下記の＜表１５＞は、図１０で使用されるＡＰＩを簡略に示す。
【０１４９】
【表１５】
0006543617.tif 000016
【０１５０】
＜表１５＞を参照すると、ｄｉｓｃｏｖｅｒＨｂｂＴＶｄｅｖｉｃｅｓ()は、入力要素を持たなく、ネットワークで利用可能な第１のデバイスのリストを獲得するために使用される。ｌａｕｎｃｈＨｂｂＴＶＡｐｐ()は、Ａｐｐ実行ターゲットである第１のデバイスのＩＤを表す ｕｎｉｔ  ｔａｒｇｅｔ_ｄｅｖｉｃｅとＸＭＬフォーマットで実行される第１のデバイスのＡｐｐ情報を２個の入力要素として有し、第１のデバイスのＡｐｐを実行するために使用できる。
【０１５１】
次に、図１１を参照して、図１０のステップ１００８について詳細に説明する。
【０１５２】
図１１は、本発明の第３の実施形態による第２のデバイスが第１のデバイスを検索するプロセスを示す信号フロー図である。
【０１５３】
図１１を参照すると、ステップ１１００において、第２のデバイス９２０のＣＳランチャ９２８は、ＣＳ  Ａｐｐ９３０から機器検索要請が受信されると、ステップ１１０２で、第１のデバイス９１０が存在するかを検索する。例えば、ＣＳランチャ９２８は、ＳＳＤＰのＭ-ＳＥＡＲＣＨメッソード(Ｍ-ＳＥＲＡＣＨ要請及び応答)を使用し、ＣＳ  Ａｐｐ９３０に関連して連動が必要な第１のデバイス９１０を検索する。このとき、ＣＳランチャ９２８は、次の＜表１６＞に示すように、ＳＴヘッダーに検索しようとする機器に関する情報を含めて該当デバイスを特定できる。
【０１５４】
【表１６】
0006543617.tif 000017
【０１５５】
一方、第１のデバイス９１０のＣＳ管理部９１６は、＜表１６＞に示すような信号を受信すると、ステップ１１０４において、それに対する応答信号を第２のデバイス９２０に送信する。応答信号は、次の＜表１７＞に示すように、ＵＰｎＰデバイス情報を含むＸＭＬファイルのＵＲＬ情報を含み、ＵＲＬ情報は、ＬＯＣＡＴＩＯＮヘッダーに含まれ得る。
【０１５６】
【表１７】
0006543617.tif 000018
【０１５７】
ＣＳランチャ９２８は、応答信号を受信すると、ステップ１１０６で、応答信号に含まれたＵＲＬ情報に基づいて第１のデバイス９１０に関する情報を要請する。すなわち、ＣＳランチャ９２８は、次の＜表１８＞のように、ＬＯＣＡＴＩＯＮヘッダーに含まれるＵＲＬ情報に基づいてＨＴＴＰ  ＧＥＴメソッドを用いて第１のデバイス９１０に対するＵＰｎＰデバイス情報を要請する。
【０１５８】
【表１８】
0006543617.tif 000019
【０１５９】
すると、ＣＳ管理部９１６は、ステップ１１０８で、情報要請に応答して第１のデバイス９１０に関する情報とＣＳ  Ａｐｐ９３０と連動して使用される第１のデバイス９１０のＡｐｐ、すなわち基本Ａｐｐ９４０のＵＲＬ情報を第２のデバイス９２０に送信する。すなわち、ＣＳ管理部９１６は、ＵＰｎＰデバイス情報を含むＸＭＬファイルとともに基本Ａｐｐ９４０を実行させるＵＲＬ情報を次の＜表１９＞に示すように“Ａｐｐｌｉｃａｔｉｏｎ-ＵＲＬ”ヘッダーに含めて第２のデバイス９２０に送信する。
【０１６０】
【表１９】
0006543617.tif 000020
【０１６１】
＜表１９＞において、“Ａｐｐｌｉｃａｔｉｏｎ-ＵＲＬ”ヘッダーは、本発明の実施形態で基本Ａｐｐ９４０を実行できるＵＲＬ情報を含めるために任意に定められたものであって、実現に従って異なる名称に変更して使用できる。
【０１６２】
ＣＳランチャ９２８は、上記のようなステップにより、第１のデバイス９１０に関する情報が獲得される場合、ステップ１１１０で、獲得した情報をＣＳ  Ａｐｐ９３０に送信して機器検索動作を終了する。
【０１６３】
次に、図１０のステップ１０１６で示すように、第１のデバイス９１０のＡｐｐを実行する方法について、図１２を参照して説明する。
【０１６４】
図１２は、本発明の第３の実施形態による無線通信システムにおいて、第１のデバイスのＡｐｐを実行するプロセスを示す信号フロー図である。
【０１６５】
図１２を参照すると、第２のデバイス９２０のＣＳランチャ９２８は、ステップ１２００において、第１のデバイス９１０に関する情報、例えばＡｐｐ情報を要請する。この要請は、ＨＴＴＰ  ＧＥＴメソッドを通じて実行され、次の＜表２０＞のように示すことができる。
【０１６６】
【表２０】
0006543617.tif 000021
【０１６７】
＜表２０＞において、＜Ａｐｐ  Ｌａｕｎｃｈ  ＵＲＬ＞は、図１１のステップ１１０８において、第１のデバイス９１０から受信されるＡｐｐｌｉｃａｔｉｏｎ-ＵＲＬヘッダーのＵＲＬ情報を示し、ＡｐｐＮａｍｅは、第１のデバイス９１０のＡｐｐの名称を示す。本発明の第３の実施形態では、Ａｐｐとの名称は、本発明の第３の実施形態で提供する特定サービスを制限する方法のために使用する。本発明の第３の実施形態では、このサービスは、ＨｂｂＴＶに限定されるが、その実現に従って変更可能である。
【０１６８】
第１のデバイス９１０のＣＳ管理部９１６は、ステップ１２０２において、要請に対する応答で、第１のデバイス９１０に関する情報としてＡｐｐ情報を送信する。Ａｐｐ情報は、サービス終端点情報(付加サービス情報)及びＵＡ(User  Agent)情報を含むＸＭＬファイルが含まれ得る。ＵＡ情報は、第２のデバイス９２０で、第１のデバイス９１０の性能を判断するために使用される。
【０１６９】
一方、Ａｐｐ情報は、その一例として＜表２１＞のように示すことができる。
【０１７０】
【表２１】
0006543617.tif 000022
【０１７１】
＜表２１＞を参照すると、＜ｘ#ＨｂｂＴＶ#ｔｅｒｍｉｎａｌ#ＵＡＳｔｒｉｎｇ＞は、ＵＡストリング(string)情報を表し、＜ｘ#ＨｂｂＴＶ#Ａｐｐ２ＡｐｐＵＲＬ＞は、Ａｐｐ間通信のための情報を表し、＜ｘ#ＨｂｂＴＶ#ＩｎｔｅｒＤｅｖＳｙｎｃＵＲＬ＞は、デバイス間同期サービスを提供するための情報を表す。Ａｐｐ情報は、＜表２１＞に示す情報以外にサービス別に必要な情報が存在する場合に追加されることもある。
【０１７２】
ＣＳランチャ９２８は、Ａｐｐ情報を受信し、受信した情報に基づいてステップ１２０４において、ＣＳ管理部９１６にＡｐｐ実行を要請する。このような動作は、ＨＴＴＰのＰＯＳＴメソッドに基づいて実行され、Ａｐｐ実行のための要請は、一例として次の＜表２２＞に示す。
【０１７３】
【表２２】
0006543617.tif 000023
【０１７４】
＜表２２＞を参照すると、＜Ａｐｐ  Ｌａｕｎｃｈ  ＵＲＬ＞/ＡｐｐＮａｍｅは、＜表２０＞の＜ＡｐｐＬａｕｎｃｈＵＲＬ＞/ＡｐｐＮａｍｅと同一であり、実際に実行するＡｐｐの情報がＸＭＬ形態(ＸＭＬ  ＡＩＴ）でボディ部に含まれて伝送できる。伝送されるＸＭＬ  ＡＩＴは、次の＜表２３＞のような情報を含むことができる。
【０１７５】
【表２３】
0006543617.tif 000024
【０１７６】
ＣＳ管理部９１６は、ＸＭＬ  ＡＩＴに基づいて第１のデバイス９１０のＡｐｐを実行させる。ＣＳ管理部９１６は、ステップ１２０６において、その実行結果を次の＜表２４＞に示すように、ＨＴＴＰ応答コードを用いて第２のデバイス９２０に送信する。
【０１７７】
【表２４】
0006543617.tif 000025
【０１７８】
＜表２４＞で、“２０１ＣＲＥＡＴＥＤ”は、ＨＴＴＰ応答コードを示し、ＨＴＴＰ応答コードは、一例として次の＜表２５＞に示すようである。
【０１７９】
【表２５】
0006543617.tif 000026
【０１８０】
＜表２５＞を参照すると、“２０１ ＣＲＥＡＴＥＤ”は、第１のデバイス９１０のＡｐｐの実行に成功したことを示し(＜表２５＞では、例えばＨｂｂＴＶＡｐｐの実行に成功したことを示し)、“４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ”は、第１のデバイス９１０のＡｐｐ実行がユーザーにより拒否されることを示し、“４０３ Ｆｏｒｂｉｄｄｅｎ”は、第１のデバイス９１０のＡｐｐ実行が第１のデバイス９１０により拒否されることを示し、“４０４ ＮＯＴ ＦＯＵＮＤ”は、第１のデバイス９１０のＡｐｐが存在しないことを示し、“５０３ ＳＥＲＶＩＣＥ ＵＮＡＶＡＩＬＡＢＬＥ”は、第１のデバイス９１０の特定動作により第１のデバイス９１０のＡｐｐを一時的に実行できないことを示す。
【０１８１】
次に、第２のデバイス９２０で第１のデバイス９１０のＡｐｐを終了させるプロセスについて説明する。Ａｐｐの終了のための要請は、ＨＴＴＰのＤＥＬＥＴＥメソッドにより実行できる。しかしながら、ＤＥＬＥＴＥメソッドの場合、ＢＯＤＹメッセージを含めないため、終了させるＡｐｐを識別する方法が必要である。したがって、＜表２６＞に示すように、ＸＭＬ  ＡＩＴに含まれたｏｒｇＩＤとａｐｐＩＤに基づいて終了させるＡｐｐを識別可能にする。次の＜表２６＞は、Ａｐｐ終了要請の一例を示す。
【０１８２】
【表２６】
0006543617.tif 000027
【０１８３】
以下、図１３を参照して、第１のデバイス９１０のＡｐｐ実行及び終了動作について説明する。
【０１８４】
図１３は、本発明の第３の実施形態による第１のデバイスがＡｐｐ実行及び終了動作を実行するプロセスを示すフローチャートである。
【０１８５】
図１３を参照すると、第１のデバイス９１０は、ステップ１３００において、第２のデバイス９２０からＨＴＴＰリクエストを受信する。第１のデバイス９１０は、ステップ１３０２において、ＨＴＴＰリクエストに含まれているＵＲＬ情報を分析して該当Ａｐｐを確認する。第１のデバイス９１０は、確認したＡｐｐがシステムで所定の特定Ａｐｐである場合、次のような動作を実行する。
【０１８６】
第１のデバイス９１０は、ステップ１３０４において、ＨＴＴＰリクエストのメッソドを確認する。第１のデバイス９１０は、確認したメッソドがＧＥＴメッソドである場合、第２のデバイス９２０が第１のデバイス９１０のＡｐｐ情報を要請すると判定し、ステップ１３０６において、サービス終端点及びＵＡ情報を含むＸＭＬファイルを生成する。第１のデバイス９１０は、ステップ１３０８において、ボディ部に生成されたＸＭＬファイルを含めて第２のデバイス９２０に伝送する。上記のような送信動作は、ステップ１３１６の処理結果の応答と同一の動作と見なされる。
【０１８７】
一方、第１のデバイス９１０は、確認されたメソッドがＰＯＳＴメソッドである場合、第２のデバイス９２０が第１のデバイス９１０のＡｐｐの実行を指示すると判定し、ステップ１３１０に進む。第１のデバイス９１０は、ステップ１３１０において、ＨＴＴＰリクエストのボディ部に含まれているＸＭＬ  ＡＩＴを受信する。第１のデバイス９１０は、ステップ１３１２において、ｏｒｇＩＤ及びａｐｐＩＤに基づいて該当Ａｐｐの実行が可能であるか否かを判定する。このとき、第１のデバイス９１０は、第１のデバイス９１０に予め格納されている実行可能なＡｐｐリスト(white  list)又は実行不可能なＡｐｐリスト(black  list)に基づいて該当Ａｐｐの実行が可能であるか否かを判定するか、あるいはユーザーの入力を受信して該当Ａｐｐが実行可能であるか否かを判定できる。第１のデバイス９１０は、該当Ａｐｐの実行が可能である場合、ステップ１３１４で該当Ａｐｐを実行し、ステップ１３１６で処理結果を第２のデバイス９２０に送信する。ここで、第１のデバイス９１０は、実行しているＡｐｐに対応するａｐｐＩＤとｏｒｇＩＤを管理しなければならない。
【０１８８】
第１のデバイス９１０は、確認されたメソッドがＤＥＬＥＴＥメソッドである場合、第２のデバイス９２０がＡｐｐの終了を指示すると判定し、ステップ１３１８において、ＨＴＴＰリクエストに含まれたｏｒｇＩＤ及びａｐｐＩＤを判定する。第１のデバイス９１０は、ステップ１３２０において、判定されたｏｒｇＩＤ及びａｐｐＩＤに対応するＡｐｐが実行中であると判定する。第１のデバイス９１０は、判定されたｏｒｇＩＤ及びａｐｐＩＤに対応するＡｐｐが実行中である場合、ステップ１３２２に進んで実行中であるＡｐｐを終了する権限があるか否かを判定する。第１のデバイス９１０は、Ａｐｐを終了する権限がある場合、ステップ１３２４において、実行中であるＡｐｐを終了し、その結果をステップ１３１６で第２のデバイス９２０に送信する。
【０１８９】
次に、図１４を参照して、第２のデバイス９２０のＡｐｐ実行に関連した全体的な動作を説明する。
【０１９０】
図１４は、本発明の第３の実施形態による第２のデバイスのＡｐｐ実行に関連した動作を示すフローチャートである。
【０１９１】
図１４を参照すると、第２のデバイス９２０は、ステップ１４００において、ＨＴＭＬページを受信し、第２のデバイス９２０のＡｐｐ(以下、‘第２のＡｐｐ’と称する）を実行する。このとき、第２のＡｐｐが内蔵型Ａｐｐである場合、ＨＴＭＬページを受信する手順なしに第２のＡｐｐが実行できる。
【０１９２】
第２のデバイス９２０は、ステップ１４０２において、第１のデバイス９１０のＡｐｐ(以下、‘第１のＡｐｐ’と称する）の実行のために必要な情報を含んでいるＸＭＬ  ＡＩＴをＷｅｂサーバ９００から受信する。第２のデバイス９２０は、ステップ１４０４において、実行される第２のＡｐｐを通じて利用可能なデバイス(例えば、第１のデバイス９１０が存在するか否かを検索する。
【０１９３】
第２のデバイス９２０は、ステップ１４０６において、第１のデバイス９１０が検索されない場合にステップ１４１８に進み、第２のＡｐｐの実行を終了する。第２のデバイス９２０は、第１のデバイス９１０が検索される場合、ステップ１４０８において、ＨＴＴＰ  ＧＥＴメソッドを使用して第１のデバイス９１０の情報を要請する。第２のデバイス９２０は、要請に対する応答でＡｐｐ間通信のためのサービス終端点情報及び第１のデバイス９１０の性能に関する情報を含むＵＡ情報を第１のデバイス９１０から受信する。ＵＡ情報は、第１のデバイス９１０のハードウェア特性(スクリーンサイズ、ＣＰＵ速度、ＰＶＲサポートなど)、第１のデバイス９１０がサポートする特性(マルチスクリーン機能、ＤＲＭサポートなど）が含まれ得る。
【０１９４】
その後、第２のデバイス９２０は、ステップ１４１０において、ＵＡ情報に基づいて第１のデバイス９１０で第１のＡｐｐの実行が可能であるか否かを判定する。例えば、第１のデバイス９１０がＨＤ程度の解像度をサポートする小さいスクリーンを有する。第１のＡｐｐが最小ＦＨＤ程度の解像度を必要とする場合、第２のデバイス９２０は、第１のデバイス９１０で第１のＡｐｐの実行が不可能であると判定できる。したがって、この場合、第２のデバイス９２０は、第１のＡｐｐの実行を第１のデバイス９１０に要請することなく、ステップ１４１８に進む。
【０１９５】
一方、第２のデバイス９２０は、第１のＡｐｐの実行が第１のデバイス１１０で可能であると判定する場合、ステップ１４１２に進行して第１のデバイス９１０で第１のＡｐｐの実行することを要請する。第１のＡｐｐを実行するための要請のためにＨＴＴＰ  ＰＯＳＴメソッドが使用され得る。
【０１９６】
第２のデバイス９２０は、ステップ１４１４において、サービス終端点情報に基づいて第１のデバイス９１０と第２のデバイス９２０との間の通信チャンネルを生成してＡｐｐ間通信を実行する。第２のデバイス９２０は、第１のＡｐｐの実行を終了する必要がある場合、ステップ１４１６において、ＨＴＴＰ  ＤＥＬＥＴＥメソッドを使用して第１のデバイス９１０に第１のＡｐｐの実行を終了することを要請し、ステップ１４１８で記第２のＡｐｐの実行を終了する。
【０１９７】
図１５は、本発明の第３の実施形態による方法が適用される一例を示す。
【０１９８】
図１５において、Ｗｅｂサーバ９００が放送社Ｗｅｂサーバであり、第１のデバイス９１０がＤＴＶであり、第２のデバイス９２０が移動端末である場合を一例として示す。
【０１９９】
ユーザーは、第２のデバイス９２０を用いてＷｅｂサーバ９１０から電子プログラムガイド(ＥＰＧ)を受信する。ユーザーは、ＥＰＧに基づいて所望する放送番組を選択し、選択した放送番組を第１のデバイス９１０で見ようとする。
【０２００】
上記のような場合、第２のデバイス９２０は、ユーザーが所望する放送番組を選択する場合、ホームネットワーク内に利用可能な第１のデバイス９１０を検索する。第２のデバイス９２０は、第１のデバイス９１０が検索される場合、Ｗｅｂサーバ９００から受信されたＸＭＬ  ＡＬＴ情報を第１のデバイス９１０に送信する。すると、第１のデバイス９１０は、ＸＭＬ  ＡＩＴ情報に基づいて該当Ａｐｐを実行させて第２のデバイス９２０で選択された放送番組をユーザーに見せられる。
【０２０１】
一方、上記では、本発明で提案した実施形態を３つに区分して説明したが、これら実施形態は、３つの実施形態のうち少なくとも２つが組み合わせて使用されるなど多様に変形して使用できる。
【０２０２】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体に対するコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ＲＯＭ(Read-Only Memory)、ＲＡＭ(Random-Access Memory)、ＣＤ-ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体は、ネットワーク接続されたコンピュータシステムにわたって分散されることによって、コンピュータ読み取り可能なコードは分散形態で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における熟練されたプログラマにとっては容易に理解できることである。
【０２０３】
本発明の実施形態によるトポロジ処理方法は、ハードウェア、ソフトウェア、又はそれらの組み合わせの形態で実現可能であることがわかる。このようなソフトウェアは、例えば、揮発性又は非揮発性格納装置(例えば、削除可能/再書き込み可能なＲＯＭ(Read Only Memory)、メモリ(例えば、ＲＡＭ(Random Access Memory)、メモリチップ、及び集積回路(ＩＣ)チップ)、又は光学的に又は磁気的に記録可能な機械(例えば、コンピュータ)-読み取り可能な格納媒体(例えば、ＣＤ(Compact Disc)、ＤＶＤ(Digital Versatile Disc)、磁気ディスク、及び磁気テープ)に格納することができる。トポロジ処理方法は、制御部及びメモリを含むコンピュータ又は移動端末により実現され得る。このメモリは、本発明の実施形態を実現するための命令を含むプログラムを格納するのに適合した機械読み取り可能な格納媒体であり得る。
【０２０４】
したがって、本発明は、本請求項により定められた装置及び方法を実現するための符号を含むプログラム、及びこのようなプログラムを格納する機械(例えば、コンピュータ)読み取り可能な格納媒体を含む。このプログラムは、有線/無線接続を通じて伝送される通信信号のような媒体を介して電気的に伝送でき、これに均等なものと共に本発明に含まれる。
【０２０５】
また、本発明の実施形態による装置は、有線又は無線で接続されるプログラム提供装置からプログラムを受信して格納できる。プログラム提供装置は、プログラム処理装置が設定されたコンテンツ保護方法を実行させる指示を含むプログラム、コンテンツ保護方法に必要な情報を格納するためのメモリ、グラフィック処理装置との有線又は無線通信を実行するための通信部、及びグラフィック処理装置の要請又は自動で該当プログラムを送受信装置に送信する制御部を含むことができる。
【０２０６】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
【図１】
0006543617.tif 000028
【図２】
0006543617.tif 000029
【図３】
0006543617.tif 000030
【図４】
0006543617.tif 000031
【図５】
0006543617.tif 000032
【図６】
0006543617.tif 000033
【図７】
0006543617.tif 000034
【図８】
0006543617.tif 000035
【図９】
0006543617.tif 000036
【図１０】
0006543617.tif 000037
【図１１】
0006543617.tif 000038
【図１２】
0006543617.tif 000039
【図１３】
0006543617.tif 000040
【図１４】
0006543617.tif 000041
【図１５】
0006543617.tif 000042