JP2016533550A - 機器別応用プログラムの間の通信のための装置及び方法 - Google Patents

Abstract

本発明は同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供する方法であって、第１の機器内のウェブソケットサーバを通じて上記第１の機器で駆動される第１の応用プログラムと、第２の機器で駆動される第２の応用プログラムを接続するステップと、上記ウェブソケットサーバを通じて上記第１の応用プログラムと第２の応用プログラムの間のデータを送受信するステップとを含む。

Description

本発明は、同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信方法及び装置に関する。

無線通信の増大につれ、リアルタイム双方向データの通信と複数の同時接続者を受容可能なウェブソケット（web socket）通信が導入された。このようなウェブソケット通信は、サーバとクライアント間の通信に基づいて行われる。

図１は、一般的なウェブソケット通信の動作方式の一例を示す図である。

図１を参照すれば、サーバ１０２は、ウェブソケット通信をサポートするサーバであり、クライアント１乃至４（１０４〜１１０）の各々は、ウェブソケットプロトコルを使用して、所望するサーバ１０２と接続されてデータをやり取りする場合を仮定する。ここでは、説明の便宜上、ウェブソケット通信をサポートするサーバが一つの場合を例示するが、一つ以上のウェブソケットサーバが存在することがある。

このようなウェブソケット通信は、既存の通信方法のうち一つであるHyper Text Transfer Protocol（以下、‘ＨＴＴＰ’と称する）が有する短所、すなわち、単方向通信を克服してサーバとクライアント間に途切れない双方向通信を提供できる。また、ウェブソケット通信は、サーバ側で複雑なプログラミング無しに単純なHyper text Markup Language５（以下、‘ＨＴＭＬ５’と称する）との連動が容易になったため、基本的な双方向通信が必要な環境で多様に活用できると期待される。

したがって、このようなウェブソケット通信を相異なる機器で駆動される応用プログラム間の通信に適用する方案が研究されている。したがって、サーバとクライアント間の双方向通信のために設計されたウェブソケット通信を応用プログラムの間の通信に活用するための具体的手順がリクエストされる。

本発明は、同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供できる装置及び方法を提案する。

本発明は、第１の機器で一つの応用プログラムが駆動され、第２の機器で上記応用プログラムと連動された補助応用プログラムが駆動される場合、ウェブソケットプロトコルを使用して上記応用プログラム及び補助プログラムの間の通信を提供するための装置及び方法を提案する。

本発明の実施形態による方法は、同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供する方法であって、
第１の機器内のウェブソケットサーバを通して、上記第１の機器で駆動される第１の応用プログラムと第２の機器で駆動される第２の応用プログラムとを接続するステップと、
上記ウェブソケットサーバを通して、上記第１の応用プログラムと第２の応用プログラムの間のデータを送受信するステップとを含む。

本発明の実施形態による他の方法は、同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供する装置であって、
上記装置で駆動される第１の応用プログラムと第２の機器で駆動される第２の応用プログラムの接続を提供し、上記接続を通して上記第１の応用プログラムと第２の応用プログラムの間のデータを送受信するように制御するウェブソケットサーバを含む。

本発明は、相異なる機器で駆動される応用プログラム間の通信手段を提供することで、例えば、第１の機器の応用プログラムと連動された第２の機器の応用プログラムを作成することができる。これを通じて、第２の機器で第１の機器を制御できるリモートコントロール応用プログラムを作成するか、または、第１の機器を利用して第２の機器の入力応用プログラムを操作するようなユーザ経験などを提供できる効果がある。

一般的なウェブソケットの動作方式の一例を図示する図である。 本発明の実施形態による応用プログラム間の通信を説明するための基本的な構成図の一例である。 本発明の実施形態によって、第１の機器でウェブソケットサーバを駆動及び停止する動作フローチャートの一例である。 本発明の実施形態によって、第２の機器の応用プログラムが第１の機器の応用プログラムと通信する動作フローチャートの一例である。 本発明の実施形態による第１の機器の動作フローチャートの一例である。 本発明の実施形態による第２の機器の動作フローチャートの一例である。 本発明が実際適用された実施形態を示す図である。

以下添付された図面を参照して本発明の望ましい実施形態に対する動作原理を詳細に説明する。図面上に表示された同一構成要素に対しては、他の図面上に表示されても可能なかぎり同一参照番号で表し、次で本発明を説明するに当たって関連した公知機能または構成に対する具体的な説明が本発明の要旨を不必要にすると判定される場合にはその詳細な説明を省略する。また、後述する用語は本発明における機能を考慮して定義された用語であって、これはユーザ、運用者の意図または慣例などによって変更されることができる。したがって、その定義は、本明細書の全般にかける内容に基づいて定められるべきである。

本発明の実施形態では、同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供できる装置及び方法を提案する。具体的な実施形態によって、本発明は、同一ネットワーク、例えば、ホームネットワークに複数の機器が接続されている環境で、第１の機器で駆動される応用プログラムと、第２の機器で駆動される上記応用プログラムと連動された補助応用プログラムとの間の通信をウェブソケットプロトコルを使用して提供するための装置及び方法を提案する。

図２は、本発明の実施形態による機器別応用プログラムの間の通信を説明するための基本的な構成図の一例である。説明の便宜上、図２の機器構成は、本発明の実施形態による構成だけを含む概略的な構成図である。したがって、事業者の意図や状況により該当構成は一つのユニットに統合されるか、または、機能によってサブユニットに分割されて構成されることができる。

図２を参照すれば、説明の便宜上、第１の機器２００と第２の機器２１０は、同一ネットワークの一例として、ホームネットワークに接続された機器のうち一つであると仮定する。図面に図示しないが、上記ホームネットワークに接続された機器は、第１の機器２００及び第２の機器２１０以外の機器が存在できる。

第１の機器２００は、任意の応用プログラムが駆動される主機器で定義にされ、例えば、デジタルＴＶ（以下、‘ＤＴＶ’と称する）またはセットボックス（以下、‘ＳＴＢ’と称する）などの共用端末を含むことができる。本発明の実施形態による第１の機器２００は、一例で、ウェブブラウザ２０４とウェブソケットサーバ２０６を含むことができる。ここで、ウェブブラウザ２０４は、ウェブ応用プログラムを駆動できる構成要素に該当し、ウェブソケットサーバ２０６は、本発明の実施形態によって、他の機器の応用プログラムと、第１の機器２００の応用プログラムとの間の通信のために追加された構成要素である。具体的な例で、ウェブソケットサーバ２０６は、第１の機器２００で駆動される応用プログラムと、第２の機器２１０で駆動される応用プログラムとの間の接続及び通信を提供できる。

また、第２の機器２１０は、図面に図示しないが、上記ホームネットワークに接続された機器のうちの一つと連動して応用プログラムを実行するスレーブ（slave）機器で定義され、例えば、移動通信端末、タブレット及びスマートフォンなどのような個人端末であり得る。本発明の実施形態による第２の機器２１０は、例えば、第１の機器２００と同様にウェブ応用プログラムを駆動できるウェブブラウザ２１２を含む。以下、明細書ではウェブ応用プログラムに対して応用プログラムの間の通信を例として説明している。しかし、本発明で説明する手順とApplication Program Interface（以下、‘ＡＰＩ’と称する）をサポートする応用プログラムの場合、いずれかの応用プログラムも適用されることができる。例えば、アンドロイド（登録商標）オペレーティングシステム（以下、‘ＯＳ’と称する）やアイフォンのＯＳ（ｉＯＳ（登録商標））で動作するネイティブ応用プログラムなどを含むことができる。

ここで、第１の機器２００で駆動される応用プログラムと第２の機器２１０で駆動される応用プログラム（ウェブ応用プログラム）は直接通信することができない。したがって、本発明の実施形態では、第１の機器２００に存在するウェブソケットサーバ２０６をプロキシのように使用して機器別応用プログラムの間の接続及び通信が実行できる。すなわち、ウェブソケットサーバ２０６は、機器別応用プログラムの間の接続及び通信のためのリレーとして動作できる。具体的に、本発明の実施形態では、第１の機器２００のウェブソケットサーバ２０６とウェブブラウザ２０４との間にウェブソケット（以下、‘ＷＳ’と称する）プロトコルを使用して通信し、同様に、ウェブソケットサーバ２０６と第２の機器２１０のウェブブラウザ（２１２またはネイティブ応用プログラム、以下省略）間に上記ＷＳプロトコルを使用して通信する。

以下、説明の便宜上、本発明の実施形態による機器別応用プログラムの間の通信をサポートする装置及び動作は図２の構成例に基づいて説明する。

図３は、本発明の実施形態によって第１の機器でウェブソケットサーバを駆動及び停止する動作フローチャートの一例である。説明の便宜上、上記第１の機器は、ホームネットワークに接続されたＤＴＶであり、第２の機器は、上記ホームネットワークに接続されたモバイル機器である場合を仮定して説明する。しかし、本発明の実施形態が適用される第１の機器と第２の機器は、該当技術をサポートするいずれかのデバイスであり得る。

まず、第１の機器３１０でウェブソケットサーバ３０４の駆動（WS starting）動作を説明する。図３を参照すれば、ステップ３２２で、第１の機器３１０のウェブ応用プログラム（以下、‘プライマリＡｐｐ’と称する、３０２）は、ＡＰＩを通して第１の機器３１０のウェブソケットサーバ３０４に伝達され、ウェブソケットサーバ３０４を駆動させる。ここで、ＡＰＩは、下記＜表１＞に表すように、start ＷＳを使用することができる。

この時、上記start ＷＳは、プライマリＡｐｐ３０２との連動のために上記応用プログラムのＩＤ（Identifier）であるＡｐｐＩＤを共に提供する。ここで、応用プログラムのＩＤは、実際の具現時、該当応用プログラムを識別することができるＩＤやUniform Resource Locator(以下、‘ＵＲＬ’と称する)などであり得る。ウェブソケットサーバ３０４は、上記ＡｐｐＩＤに対応するプライマリＡｐｐ３０２と通信するために自分を駆動させ、上記駆動の完了をＡＣＫ信号としてプライマリＡｐｐ３０２に伝送する。

次に、第１の機器３００でウェブソケットサーバ３０４を停止(WS shutdown)する動作を説明する。

ステップ３２６で、プライマリＡｐｐ３０２は、ＡＰＩを第１の機器３１０のウェブソケットサーバ３０４に伝達して、駆動中のウェブソケットサーバ３０４を停止させる。この時、プライマリＡｐｐ３０２で呼び出しするＡＰＩは、上記＜表１＞のようにshutdownWSを使用することができる。同様に、上記shutdownWSも上記ＡｐｐＩＤを共に提供する。ウェブソケットサーバ３１０は、上記ＡｐｐＩＤに対応する上記プライマリＡｐｐとも通信を中断し、上記中断の完了をＡＣＫ信号として第１の機器３００のＡｐｐＩＤ３０２に伝送する。

図３の実施形態では、第１の機器内の特定応用プログラムのためのウェブソケットサーバを第１の機器が直接駆動及び中断させる方法に対して説明した。他の実施形態では、共用で使用できるウェブソケットサーバを駆動させた後、次の手順で説明するＡＰＩを用いて第２の機器の応用プログラムが上記第１の機器のウェブソケットサーバと連動されることができる。

図４は、本発明の実施形態により第２の機器の応用プログラムが第１の機器の応用プログラムと通信する動作フローチャートの一例である。参考として、下記＜表２＞は、機器別応用プログラムの間の通信のためのＡＰＩの例を示す表の一例である。

図４を参照すれば、ステップ４２０で第２の機器４１０の応用プログラム(以下、‘ＣＳ(Companion Screen)Ａｐｐ’と称する)４１２は、ウェブソケットオブジェトを生成し、第１の機器４００のウェブソケットサーバ４０４にｏｐｅｎ（）ＡＰＩを呼び出しして通信チャネルの生成をリクエストする。この時、ｏｐｅｎ（）ＡＰＩは、プライマリＡｐｐ４０２のＩＤ(ＡｐｐＩＤ)と、ＣＳ Ａｐｐ４１２のＩＤ(ＣＳＡｐｐＩＤ)を伝達することができる。また、ステップ４２２で、プライマリＡｐｐ４０２は、上記ＡｐｐＩＤと上記ＣＳＡｐｐＩＤを用いてウェブソケットオブジェトを生成し、ウェブソケットサーバ４０４にｏｐｅｎ（）ＡＰＩを呼び出しして通信チャネルの生成をリクエストする。同様に、プライマリＡｐｐ４０２のｏｐｅｎ（）ＡＰＩも上記ＡｐｐＩＤと上記ＣＳＡｐｐＩＤを伝達する。

ステップ４２４で、第１の機器４００のウェブソケットサーバ４０４は、ＡｐｐＩＤに対応するプライマリＡｐｐ４０２と上記ＣＳＡｐｐＩＤに対応するＣＳ Ａｐｐ４１２間に通信チャネルを生成する。上記したような過程で通信チャネルが生成されると、ＣＳ Ａｐｐ４１２は、上記通信チャネルを通じて、プライマリＡｐｐ４０２と通信することができる。同様に、プライマリＡｐｐ４０２も上記通信チャネルを通じてＣＳ Ａｐｐ４１２と通信することができる。具体的に、ステップ４２０乃至ステップ４２４を通じて、プライマリＡｐｐ４０２とＣＳ Ａｐｐ４１２の各々がウェブソケットサーバに接続する方法は一例で、下記＜表３＞を用いることができる。

上述したように、ウェブソケットサーバ４０４がプライマリＡｐｐ４０２のｏｐｅｎ（）ＡＰＩから取得した情報と、ＣＳ Ａｐｐ４１２から取得した情報が同一であることを確認する。図４の実施形態では、プライマリＡｐｐ４０２及びＣＳ Ａｐｐ４１２の各々がＡｐｐＩＤ及びＣＳＡｐｐＩＤを上記通信チャネルのための同一情報として伝送する場合を一例として説明した。ウェブソケットサーバ４０４は、プライマリＡｐｐ４０２との接続と、自分とＣＳ Ａｐｐ４１２との接続を中継(relay)して、プライマリＡｐｐ４０２及びＣＳ Ａｐｐ４１２間の通信チャネルを設定する。これによって、プライマリＡｐｐ４０２とウェブソケットサーバ４０４間の接続、及びＣＳ Ａｐｐ４１２とウェブソケットサーバ４０４間の接続の各々は、同一のチャネルＩＤが設定される。上記チャネルＩＤは、例えば、上記＜表３＞で示すようにウェブソケットサーバのアドレスと、プライマリＡｐｐ４０２のＡｐｐＩＤ及びＣＳ Ａｐｐ４１２のＣＳＡｐｐＩＤを利用して固有の値で生成されることができる。

以後、ＣＳ Ａｐｐ４１２で、プライマリＡｐｐ４０２に伝送するデータが発生する場合、ステップ４２６でＣＳ Ａｐｐ４１２は、ｓｅｎｄ（）ＡＰＩを呼び出しして上記発生するデータをウェブソケットサーバ４０４に伝送する。ステップ４２８で、ウェブソケットサーバ４０４は、Event(on massage)を呼び出しして上記プライマリＡｐｐ４０２に受信されたデータがあることを通知する。ステップ４３０で、プライマリＡｐｐ４０２は、上記受信されたデータを応用プログラムに反映する。一例で、プライマリＡｐｐ４０２がウェブ応用プログラムである場合、ステップ４３０の過程は、Document Object Model(ＤＯＭ) Updateを通じて行われる。

一方、プライマリＡｐｐ４０２で変更された事項がある場合、ステップ４３２でｓｅｎｄ（）ＡＰＩを呼び出しして、変更された事項に対する情報をウェブソケットサーバ４０４に伝達する。ステップ４３４で、第１の機器４００のウェブソケットサーバ４０４は、上述したような過程を通じて生成されたプライマリＡｐｐ４０２とＣＳ Ａｐｐ４１２間の上記通信チャネルを通じて上記情報をＣＳ Ａｐｐ４１２に伝送する。この時、上記情報は、Event(on message)を通じて伝達される。ステップ４３６で、ＣＳ Ａｐｐ４１２は上記情報を受信して、ステップ４３０と同様に自分の応用プログラムに反映される。

以後、全ての通信が完了される場合、ステップ４３７で、ＣＳ Ａｐｐ４１２は、ｃｌｏｓｅ（）ＡＰＩを呼び出ししてプライマリＡｐｐ４０２との通信チャネルの終了リクエストをウェブソケットサーバ４０４に伝送する。同様に、ステップ４４０で、プライマリＡｐｐ４１０もｃｌｏｓｅ（）ＡＰＩを呼び出しして第１の機器の応用プログラムとの通信チャネルの終了リクエストをウェブソケットサーバ４０４に伝送する。ウェブソケットサーバ４０４は、プライマリＡｐｐ４０２とＣＳ Ａｐｐ４１２間の接続を終了する。これによって、ステップ４４２で、プライマリＡｐｐ４０２とＣＳ Ａｐｐ４１２間の接続が終了される。

図５は、本発明の実施形態による第１の機器の動作フローチャートの一例である。

図５を参照すれば、ステップ５００で第１の機器は、ＨＴＭＬページを受信する。上記ＨＴＭＬページは、上記第１の機器のプライマリＡｐｐを示すＡｐｐＩＤを含む。ステップ５０２で、上記第１の機器は、上記ＨＴＭＬページのＡＰＩ呼び出しにより上記ＡｐｐＩＤを利用して上記ウェブソケットサーバを駆動させる。

また、ステップ５０４で、上記プライマリＡｐｐは、上記第１の機器と接続されたネットワークと接続された機器のうちの使用可能な第２の機器を検索する。また、ステップ５０６で、上記プライマリＡｐｐは、上記検索された第２の機器に、上記第２の機器のＣＳ Ａｐｐの駆動情報を送信した後、上記第１の機器は、ステップ５０８でユーザ入力をリクエストするＨＴＭＬページを上記第１の機器のディスプレイ画面に表示する。ステップ５１０で、上記第１の機器は、ユーザの入力を受信すると、ステップ５１２で上記ユーザの入力を通じて上記ＣＳ Ａｐｐに伝送するデータが発生されるか否かを確認する。上記確認の結果、データか発生されない場合、ステップ５１６に進む。

上記確認の結果、上記データが発生される場合、ステップ５１４で、上記第１の機器は、ステップ５０２で駆動させたウェブソケットサーバに上記データを送信する。また、ステップ５１６で上記第１の機器は、上記ウェブソケットサーバを通じて受信するデータがあるか否かを確認する。上記確認の結果、受信するデータが存在しない場合、ステップ５０８に進み、他のユーザ入力を待機することができる。

上記確認の結果、受信するデータが発生される場合、ステップ５１８で、上記第１の機器は、上記ウェブソケットサーバを通じてデータを受信する。また、ステップ５２０で、上記第１の機器は、上記受信されたデータから取得した応用プログラムのＩＤが上記第１の機器のＡｐｐＩＤであるか否かを判定する。上記判定の結果、上記データから取得した応用プログラムＩＤが上記ＡｐｐＩＤである場合、ステップ５２２で、上記第１の機器は、ＤＯＭをアップデートして上記受信されたデータを反映したＨＴＭＬをステップ５０８で自分のディスプレイ画面を通じて表示する。

図６は、本発明の実施形態による第２の機器の動作フローチャートの一例である。

図６を参照すれば、例えば、上記第２の機器は、ステップ６００で、図５のステップ５０６により上記第１の機器が送信した情報としてＨＴＭＬページを受信した場合を仮定する。ここでは、説明の便宜上、上記第２の機器のＣＳ Ａｐｐをウェブ応用プログラムと仮定してＨＴＭＬページを受信すると説明した。しかし、他の例で、ステップ６００で、上記第１の機器を通じて受信された情報が第２の機器のネイティブ(native)応用プログラムを示す場合、上記第２の機器が該当ネイティブ応用プログラムを駆動する。

また、ステップ６０２で、上記第２の機器のＣＳ Ａｐｐは、上記ＨＴＭＬメッセージから取得した第１の機器のＡｐｐＩＤと第２の機器のＣＳＡｐｐＩＤを利用して上記第１の機器のウェブソケットサーバとの接続を呼び出しする。

ステップ６０４で、上記第２の機器は、上記第１の機器のプライマリＡｐｐと連動するユーザ入力をリクエストするＨＴＭＬページを上記第２の機器のディスプレイ画面に表示する。ステップ６０６で、上記第２の機器は、ユーザの入力の受信を検知すると、ステップ６０８で、上記ユーザの入力により、第１の機器のプライマリＡｐｐに伝送するデータが存在するか否かを確認する。上記確認の結果、伝送するデータが存在しない場合、上記第２の機器はステップ８１２に進む。

上記確認の結果、上記ユーザの入力により上記第１の機器に伝送するデータが存在する場合、ステップ６１０で、上記第２の機器は、ステップ６０２で接続した上記第１の機器のウェブソケットサーバを通じて上記プライマリＡｐｐに伝送するデータを送信する。

一方、ステップ６１２で、上記第２の機器は、上記ウェブソケットサーバを通じて受信するデータが存在する場合、ステップ６１４で該当データを受信する。また、ステップ６１６で、上記第２の機器は上記受信されたデータを反映してＤＯＭをアップデートする。以後、ステップ６０４に復帰してアップデート結果に基づいてＨＴＭＬを再構成して自分のディスプレイ画面に表示する。

一方、ステップ６１２における確認の結果、上記ウェブソケットサーバを通じて受信するデータが存在しない場合、上記第２の機器はステップ６０４に復帰して他のユーザ入力を待機する。

図７は、本発明が実際に適用された実施形態を示す図である。

図７を参照すれば、例えば、ホームネットワークに第１の機器７００と第２の機器７０５が接続された場合を仮定する。また、ユーザが第１の機器７００で放送コンテンツを受信しつつ、第２の機器７０５を通じて上記第１の機器を制御する場合を仮定する。具体的な例で、上記ユーザは、ユーザ入力のための操作が便利な第２の機器７０５を利用して第１の機器７００にリモートコントロール、文字入力などのためのユーザ入力を実行することができる。また、第１の機器７００の放送コンテンツにより表示される画面を選択するかまたは放送コンテンツ別に提供する該当応用プログラムを実行させるか、投票などを第２の機器７０５を用いて実施するなどの多様な例が可能になる。この時、第１の機器７００は、上述したようにウェブソケットサーバを有し、上記ウェブソケットサーバを通じて第１の機器７００で駆動される応用プログラムと第２の機器７０５で第１の機器７００の操作のための応用プログラムの間の接続及び通信を提供することができる。

一方、本発明の詳細な説明では具体的な実施形態に対して説明したが、本発明の範囲を逸脱しない範囲で多様な変形が可能であることは明らかである。したがって、本発明の範囲は説明された実施形態に限定されず後述する特許請求の範囲及びこれと均等なものの範囲内で定められるべきである。

まず、第１の機器３００でウェブソケットサーバ３０４の駆動（WS starting）動作を説明する。図３を参照すれば、ステップ３２２で、第１の機器３００のウェブ応用プログラム（以下、‘プライマリＡｐｐ’と称する、３０２）は、ＡＰＩを通して第１の機器３００のウェブソケットサーバ３０４に伝達され、ウェブソケットサーバ３０４を駆動させる。ここで、ＡＰＩは、下記＜表１＞に表すように、start ＷＳを使用することができる。

ステップ３２６で、プライマリＡｐｐ３０２は、ＡＰＩを第１の機器３００のウェブソケットサーバ３０４に伝達して、駆動中のウェブソケットサーバ３０４を停止させる。この時、プライマリＡｐｐ３０２で呼び出しするＡＰＩは、上記＜表１＞のようにshutdownWSを使用することができる。同様に、上記shutdownWSも上記ＡｐｐＩＤを共に提供する。ウェブソケットサーバ３１０は、上記ＡｐｐＩＤに対応する上記プライマリＡｐｐとも通信を中断し、上記中断の完了をＡＣＫ信号として第１の機器３００のＡｐｐＩＤ３０２に伝送する。

Claims (12)

1. 同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供する方法であって、
   第１の機器内のウェブソケットサーバを通じて、前記第１の機器で駆動される第１の応用プログラムと第２の機器で駆動される第２の応用プログラムとを接続するステップと、
   前記ウェブソケットサーバを通じて、前記第１の応用プログラムと第２の応用プログラムの間のデータを送受信するステップとを含むことを特徴とする方法。
2. 前記接続するステップは、前記第１の応用プログラムと前記第２の応用プログラムの各々から接続リクエストを受信するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記接続するステップは、
   前記ウェブソケットサーバのプロトコルを使用して、前記ウェブソケットサーバと前記第１の応用プログラムの間の第１の接続を提供するステップと、
   前記プロトコルを使用して、前記ウェブソケットサーバと前記第２の応用プログラムの間の第２の接続を提供するステップとを含むことを特徴とする請求項１に記載の方法。
4. 前記ウェブソケットサーバを通じて前記第１の接続と前記第２の接続を中継して、前記第１の応用プログラムと第２の応用プログラムの間の通信チャネルを構成するステップを含むことを特徴とする請求項１に記載の方法。
5. 前記第１の接続及び第２の接続の各々は、同一のチャネル識別子が設定されることを特徴とする請求項４に記載の方法。
6. 前記第１の応用プログラムと前記第２の応用プログラムの各々から接続解除リクエストを受信するステップと、
   前記第１の応用プログラムと第２の応用プログラムの間の接続を解除するステップをさらに含むことを特徴とする請求項１に記載の方法。
7. 同一のネットワークに接続された機器を通じて駆動される応用プログラム間の通信を提供する装置であって、
   前記装置で駆動される第１の応用プログラムと第２の機器で駆動される第２の応用プログラムとの接続を提供し、前記接続を通じて前記第１の応用プログラムと第２の応用プログラムの間のデータを送受信するように制御するウェブソケットサーバを含むことを特徴とする装置。
8. 前記ウェブソケットサーバは、前記第１の応用プログラムと前記第２の応用プログラムの各々から接続リクエストを受信すると、前記接続を提供することを特徴とする請求項７に記載の装置。
9. 前記ウェブソケットサーバは、前記ウェブソケットサーバのプロトコルを使用して前記ウェブソケットサーバと前記第１の応用プログラムの間の第１の接続を提供し、前記プロトコルを使用して前記ウェブソケットサーバと前記第２の応用プログラムの間の第２の接続を提供することを特徴とする請求項７に記載の装置。
10. 前記ウェブソケットサーバは、前記第１の接続と前記第２の接続を中継して前記第１の応用プログラムと第２の応用プログラムの間の通信チャネルを構成することを特徴とする請求項７に記載の装置。
11. 前記第１の接続及び第２の接続の各々は、同一のチャネル識別子が設定されることを特徴とする請求項１０に記載の装置。
12. 前記ウェブソケットサーバは、前記第１の応用プログラムと前記第２の応用プログラムの各々から接続解除リクエストを受信すると、前記第１の応用プログラムと第２の応用プログラムの間の接続を解除することを特徴とする請求項７に記載の装置。

Images