JP6301464B2 - 電子装置及び電子装置の制御方法 - Google Patents

Description

本明細書は、電子装置及び電子装置の制御方法に関する。

放送及び通信技術の発展に伴い、多様な放送装置及び放送サービスに対する技術が開発されている。最近、スマートフォンとスマートＴＶの大衆化と共に、多様なアプリケーションがスマートフォンとスマートＴＶ上で実行可能である。一つのアプリケーションがスマートフォンで実行されているとき、ユーザは、スマートＴＶでもスマートフォンで実行中のアプリケーションを実行しようとする場合がある。この場合、一般に、ユーザは、定められた経路に沿ってスマートＴＶを操作し、スマートフォンで実行中のアプリケーションを実行させることができる。最近の通信環境において、自分が使用中のアプリケーションと他の機器で実行中のアプリケーションとの間の通信を行おうとするユーザの要求が増加している。しかし、上述したように、別途にスマートＴＶを操作してアプリケーションを実行させることは不便であった。

このような不便さを解決するために、一つの機器のアプリケーションと他の機器のアプリケーションとの間の通信を行える技術に対する必要性がある。

本発明の目的は、一つの電子装置のアプリケーションと他の電子装置のアプリケーションとの間の通信を行える電子装置及び電子装置の制御方法を提供することにある。

本明細書の一実施例によると、電子装置は、アプリケーションプロセッサ及びネットワークプロセッサを含み、コンパニオン装置と連結する制御部と、前記コンパニオン装置との間でデータを送受信する通信部とを含み、前記アプリケーションプロセッサは、前記ネットワークプロセッサにコンパニオン装置との連結を要求し、前記ネットワークプロセッサは、前記コンパニオン装置から連結要求を受けると、前記連結要求したアプリケーションプロセッサと前記コンパニオン装置とを連結することができる。

そして、前記ネットワークプロセッサは、ウェブソケットサーバであり得る。

また、前記アプリケーションプロセッサは、前記ネットワークプロセッサで動作する電子装置及びコンパニオン装置のうち少なくとも一つの情報を示すホスト要求ヘッダ情報を前記ネットワークプロセッサに伝送することができる。

また、前記ネットワークプロセッサは、前記アプリケーションプロセッサの連結要求があるとき、前記アプリケーションプロセッサのストリームヘッドを生成してストリームヘッドグループに含ませ、前記コンパニオン装置から連結要求を受けると、前記コンパニオン装置のストリームヘッドを生成し、このストリームヘッドを前記ストリームヘッドグループに含まれたマッチする前記アプリケーションプロセッサのストリームヘッドと連結することができる。

そして、前記ネットワークプロセッサは、マッチする前記アプリケーションプロセッサのストリームヘッド及び前記コンパニオン装置のストリームヘッドのうち少なくとも一つを前記ストリームヘッドグループから除去することができる。

そして、前記アプリケーションプロセッサは、連結しようとするコンパニオン装置のＩＰアドレスを前記ネットワークプロセッサに伝送することができる。

また、前記ネットワークプロセッサは、前記アプリケーションプロセッサと前記コンパニオン装置とを同一のポートを用いて連結することができる。

本明細書の一実施例によると、電子装置の制御方法は、電子装置をコンパニオン装置と連結する段階、及び前記コンパニオン装置との間でデータを送受信する段階を含み、前記連結する段階は、前記アプリケーションプロセッサがネットワークプロセッサにコンパニオン装置との連結を要求し、前記ネットワークプロセッサは、前記コンパニオン装置から連結要求を受けると、前記連結要求したアプリケーションプロセッサと前記コンパニオン装置とを連結することができる。

そして、前記ネットワークプロセッサは、ウェブソケットサーバであり得る。

そして、電子装置の制御方法は、前記ネットワークプロセッサで動作する電子装置及びコンパニオン装置のうち少なくとも一つの情報を示すホスト要求ヘッダ情報を前記アプリケーションプロセッサが前記ネットワークプロセッサに伝送する段階をさらに含むことができる。

また、電子装置の制御方法は、前記アプリケーションプロセッサの連結要求があるとき、前記ネットワークプロセッサが前記アプリケーションプロセッサのストリームヘッドを生成してストリームヘッドグループに含ませる段階、及び前記コンパニオン装置から連結要求を受けると、前記ネットワークプロセッサが前記コンパニオン装置のストリームヘッドを生成し、このストリームヘッドを前記ストリームヘッドグループに含まれたマッチする前記アプリケーションプロセッサのストリームヘッドと連結する段階をさらに含むことができる。

また、電子装置の制御方法は、前記ネットワークプロセッサが、マッチする前記アプリケーションプロセッサのストリームヘッド及び前記コンパニオン装置のストリームヘッドのうち少なくとも一つを前記ストリームヘッドグループから除去する段階をさらに含むことができる。

また、電子装置の制御方法は、前記アプリケーションプロセッサが連結しようとするコンパニオン装置のＩＰアドレスを前記ネットワークプロセッサに伝送する段階をさらに含むことができる。

一方、前記連結する段階は、前記アプリケーションプロセッサと前記コンパニオン装置とを同一のポートを用いて連結することができる。

本明細書の多様な実施例によると、電子装置及び制御方法は、一つの電子装置で実行中のアプリケーションと他の電子装置で実行中のアプリケーションとの間の通信を行うことができる。

そして、電子装置及び制御方法は、一つの電子装置と他の電子装置との間の通信のためにウェブソケットサーバを使用してインタフェースすることができる。

また、電子装置及び制御方法は、一つの電子装置と他の電子装置とを１対１に連結させることができる。

一実施例に係る電子装置のブロック図である。 一実施例に係る第１のクライアントの連結を説明する図である。 一実施例に係る第２のクライアントの連結を説明する図である。 一実施例に係る第１及び第２のクライアント間の連結を説明する図である。 一実施例に係る追加連結要求を説明する図である。 一実施例に係るＩＰアドレスがない場合におけるクライアント間の連結を説 一実施例に係るアプリケーション間の連結のための待機連結を説明する図である。 一実施例に係る第２のクライアントとの連結のための新たな連結要求を説明する図である。 一実施例に係るＩＰアドレスを含む場合における第１のクライアントの設定を説明する図である。 一実施例に係るＩＰアドレスを含む場合における第１及び第２のクライアントの設定を説明する図である。 ＩＰアドレスを含む場合における複数の第２のクライアントに連結する一実施例を説明する図である。 一実施例に係る電子装置の制御方法のフローチャートである。

以下、上述した目的を具体的に実現可能な本明細書の好適な実施例を添付の図面を参照して説明する。このとき、図面に図示され、また、これによって説明される本明細書の構成と作用は、少なくとも一つの実施例として説明されるものであって、これによって本明細書の技術的思想とその核心構成及び作用が制限されることはない。

本明細書で使用される用語としては、本明細書での機能を考慮しながら可能な限り現在広く使用される一般的な用語を選択したが、これは、当該技術分野に携わる技術者の意図、慣例又は新たな技術の出現などによって変わり得る。また、特定の場合は、出願人が任意に選定した用語もあり、この場合、該当する明細書の説明部分でその意味を詳細に記載する。したがって、本明細書で使用される用語は、単純な用語の名称ではなく、その用語が有する意味と本明細書の全般にわたった内容に基づいて定義すべきであることを明らかにしておく。

図１は、一実施例に係る電子装置のブロック図である。

図１を参照すると、電子装置１００は、制御部１１０及び通信部１２０を含むことができる。制御部１１０は、コンパニオン装置との通信連結を行うことができる。そして、コンパニオン装置との通信連結が行われると、通信部１２０は、コンパニオン装置との間でデータを送受信することができる。

そして、制御部１１０は、ネットワークプロセッサ１１１及びアプリケーションプロセッサ１１２を含むことができる。アプリケーションプロセッサ１１２は、ネットワークプロセッサ１１１にコンパニオン装置との連結を要求することができる。

ネットワークプロセッサ１１１は、アプリケーションプロセッサ１１２から受けた連結要求を待機状態に置くことができる。これは、ネットワークプロセッサ１１１が未だにコンパニオン装置と連結されていないためである。その後、ネットワークプロセッサ１１１はコンパニオン装置から連結要求を受信することができる。ネットワークプロセッサ１１１は、コンパニオン装置から受信した情報に基づいてマッチするアプリケーションプロセッサ１１２の連結要求を検索することができる。ネットワークプロセッサ１１１は、マッチする連結要求を検索すると、コンパニオン装置とアプリケーションプロセッサ１１２とを連結することができる。

一実施例として、アプリケーションプロセッサ１１２は、アプリケーションモジュール及びアプリケーションブラウザであるか、又はＨｂｂＴＶアプリケーションであり得る。一実施例として、ネットワークプロセッサ１１１はネットワークモジュールとして具現することができる。又は、ネットワークプロセッサ１１１は、ウェブソケットサーバ（ＷｅｂＳｏｃｋｅｔ Ｓｅｒｖｅｒ）であり得る。ネットワークプロセッサ１１１は、アプリケーションプロセッサ１１２とコンパニオン装置とを連結することができる。一実施例として、ネットワークプロセッサ１１１がウェブソケットサーバとして具現される場合、アプリケーションプロセッサ１１２とコンパニオン装置はそれぞれ一つのクライアントと見なすことができる。言い換えれば、ウェブソケットサーバが第１のクライアントと第２のクライアントとを連結することができる。又は、第１のクライアントと第２のクライアントをそれぞれピア（ｐｅｅｒ）と呼ぶこともできる。場合に応じて、ウェブソケットサーバは、電子装置の外部に別途の装置として具現することもできる。

一方、アプリケーションプロセッサ１１２は、一つのアプリケーションを駆動させることができる。そして、コンパニオン装置も一つのアプリケーションを駆動させることができる。アプリケーションプロセッサ１１２は、ネットワークプロセッサ１１１を通じてコンパニオン装置と連結することができる。コンパニオン装置は、アプリケーションプロセッサ１１２からデータを受信し、アプリケーションプロセッサ１１２が駆動中のアプリケーションを受信して駆動させることができる。又は、アプリケーションプロセッサ１１２とコンパニオン装置はそれぞれアプリケーションを駆動させることができる。アプリケーションプロセッサ１１２は、コンパニオン装置と連結し、コンパニオン装置との間でデータを送受信することができる。この場合、電子装置１００とコンパニオン装置はアプリケーション間の通信を行うと言える。

ウェブソケットサーバは、中継器として用いられ、アプリケーション間の通信チャネルを生成することができる。生成された通信チャネルは、電子装置１００とコンパニオン装置との間の通信を可能にし得る。ウェブソケットサーバは、通信チャネルを生成するために通信しようとするアプリケーションネームアイディ（ａｐｐｌｉｃａｔｉｏｎ ｎａｍｅ ｉｄ）とアプリケーションオリジンアイディ（ａｐｐｌｉｃａｔｉｏｎ ｏｒｉｇｉｎ ｉｄ）を用いて同一の情報を要求する各アプリケーション間のチャネルを連結することができる。一実施例として、上述した方法は、ＨｂｂＴＶ ２．０でウェブソケットＡＰＩを修正することなく、アプリケーション（クライアント）とアプリケーション（クライアント）とを連結することができる。

本明細書では、各用語を混用して使用することにする。

図２は、一実施例に係る第１のクライアントの連結を説明する図である。

図２を参照すると、電子装置１００ａ及びコンパニオン装置２００ａが示されている。電子装置１００ａは、アプリケーションプロセッサ及びネットワークプロセッサを含むことができる。一実施例として、アプリケーションプロセッサはＨｂｂＴＶアプリケーション又は第１のクライアントであり、ネットワークプロセッサはＨｂｂＴＶウェブソケットサーバであり得る。コンパニオン装置２００ａはコンパニオン装置プロセッサを含むことができる。一実施例として、コンパニオン装置プロセッサは、コンパニオンアプリケーション又は第２のクライアントであり得る。各クライアント間の連結を行うために、ウェブソケットサーバの変更が必要であり得る。以下では、ウェブソケットサーバの変更と関連する動作を説明する。変更されたウェブソケットサーバはＨｂｂＴＶ ２．０ＴＶで駆動させることができる。

一般に、ウェブソケットクライアントは、連結しようとする遠隔ホスト、及びウェブソケット連結アップグレードヘッダと共に、初期ＧＥＴの要求時にそのホストで望むサービスのための相対的ＵＲＩを指定することができる。しかし、ＨｂｂＴＶの場合、通信連結のためのピア（例えば、コンパニオン装置）が未だにウェブソケットサーバとコンタクトされていないこともある。よって、各クライアント間の連結のための第１のクライアントからの連結要求は、対象ピアの連結要求があるまで活性を維持する必要がある。

このような必要性のために、アップグレードウェブソケットプロトコルＧＥＴ要求は、特定の使用を定義した二つのフィールドを含むことができる。ＵＲＩ要求（Ｒｅｑｕｅｓｔ―ＵＲＩ）は、一般の接頭辞ストリングの既に設定されたフォーマットを有することができる。このフィールドは、対応する各通信ピアをマッチするのに使用することができる。ホスト要求ヘッダ（Ｈｏｓｔ ｒｅｑｕｅｓｔ―ｈｅａｄｅｒ）フィールドは、ウェブソケットサーバで動作するＴＶセットを言及（マッチングＵＲＩ要求を有する任意のピアとの通信が設立される場合）したり、特定のコンパニオン装置を言及（指定された装置及びマッチングＵＲＩ要求との通信が設立される場合）することができる。すなわち、アプリケーションプロセッサは、ネットワークプロセッサで動作する電子装置情報又はコンパニオン装置情報を示すホスト要求ヘッダ情報をネットワークプロセッサに伝送することができる。

ＵＲＩ要求のためのフォーマットは、以下のＡＢＮＦ文法に従うことができる。

ＨｂｂＴＶ―Ｒｅｑｕｅｓｔ―ＵＲＩ＝"／ｈｂｂｔｖ／"ｏｒｇ―ｉｄ" ．"ａｐｐ―ｉｄ

ｏｒｇ―ｉｄ＝８ＨＥＸ

ａｐｐ―ｉｄ＝４ＨＥＸ

ウェブソケットサーバは、ＵＲＩ要求に対応してストリームヘッドを生成しなければならないが、これは、クライアントによってアップグレードＧＥＴ要求でサポートされるＵＲＩ要求と関連するハーフ（ｈａｌｆ）オープン連結を意味し得る。ウェブソケットサーバは、ウェブソケットプロトコルハンドシェイク（ｈａｎｄｓｈａｋｅ）応答に直ぐ応答する代わりに、他のピアが表れることを待ちながら第１のクライアントの待機状態を維持させることができる。ウェブソケットサーバの終了を希望する場合、サーバは、５０４ゲートウェイタイムアウト応答（５０４ Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔ ｒｅｓｐｏｎｓｅ）に反応することができる。

各クライアント間の連結を要求するとき、クライアントはＳｅｃ―ウェブソケットプロトコルヘッダを使用しないこともある。サーバは、各クライアント間の連結のための要求内のＳｅｃ―ウェブソケットプロトコルヘッダを無視することもある。各クライアント間の連結要求内のホストヘッダフィールドが、サーバがアタッチ（ａｔｔａｃｈｅｄ）されるローカルサブネットワーク上の何らの装置も指定していないと、サーバは４０３禁止応答（４０３ Ｆｏｒｂｉｄｄｅｎ ｒｅｓｐｏｎｓｅ）に反応することができる。すべてのＨｂｂＴＶ ２．０ウェブソケットクライアントは、ＨｂｂＴＶ ２．０ウェブソケットサーバから各クライアント間の連結を要求するメソッドを使用することができる。

言い換えれば、通常、ウェブソケットクライアントは、連結が設立されることを望む遠隔ホスト、及びウェブソケット連結アップグレードヘッダと共に、初期ＧＥＴの要求時にそのホストで望むサービスのための相対的ＵＲＩを指定することができる。しかし、ＨｂｂＴＶの場合、通信が設立されるピアが未だにウェブソケットサーバとコンタクトされていると仮定され得ない。よって、特定のクライアント対クライアントモードでのクライアントからの連結要求は、他の適切なピアが到着するまで活性を維持する必要がある。

これを達成するために、ウェブソケットプロトコルアップグレードＧＥＴ要求の二つのフィールドのための特定の使用を定義する。

要求―ライン（Ｒｅｑｕｅｓｔ―Ｌｉｎｅ）の部分であるＵＲＩ要求（Ｒｅｑｕｅｓｔ―ＵＲＩ）は、一般の接頭辞ストリングで事前に定義されたフォーマットを取得する。このフィールドは、対応する各通信ピアをマッチするのに使用される。

ホスト要求ヘッダ（Ｈｏｓｔ ｒｅｑｕｅｓｔ―ｈｅａｄｅｒ）フィールドは、ウェブソケットサーバで動作するＴＶセットを言及（マッチングＵＲＩ要求を有する任意のピアとの通信が設立される場合）したり、特定のコンパニオン装置を言及（指定された装置及びマッチングＵＲＩ要求とのみ通信が設立される場合）することができる。

ＵＲＩ要求フィールドのためのフォーマットは、以下のＡＢＮＦ文法に従うことができる。

ＨｂｂＴＶ―Ｒｅｑｕｅｓｔ―ＵＲＩ＝"／ｈｂｂｔｖ／"ｏｒｇ―ｉｄ" ．"ａｐｐ―ｉｄ

ｏｒｇ―ｉｄ＝８ＨＥＸ

ａｐｐ―ｉｄ＝４ＨＥＸ

これら規則は図２に示されている。このような要求に応答して、ＨｂｂＴＶウェブソケットサーバはストリームヘッドを生成することができ、これは、クライアントによってアップグレードＧＥＴ要求で供給されるＵＲＩ要求と関連するハーフオープン連結である。サーバは、ウェブソケットプロトコルハンドシェイク応答に直ぐ応答せず、その代わりに、他のピアが表れることを待ち、その結果、第１のクライアントの待機を維持させる。サーバがタイムアウトを実行することを希望する場合、サーバは、５０４ゲートウェイタイムアウト応答（５０４ Ｇａｔｅｗａｙ Ｔｉｍｅｏｕｔ ｒｅｓｐｏｎｓｅ）に反応することができる。

クライアント対クライアント連結を要求するとき、クライアントはＳｅｃ―ウェブソケット―プロトコルヘッダを使用しないこともある。サーバは、クライアント対クライアント連結のための要求内のＳｅｃ―ウェブソケット―プロトコルヘッダを無視することもある。クライアント対クライアント連結要求内のホストヘッダフィールドは、サーバがアタッチされるローカルサブネットワーク上のいずれにおいても装置を指定していないと、サーバは４０３禁止応答（４０３ Ｆｏｒｂｉｄｄｅｎ ｒｅｓｐｏｎｓｅ）に反応することができる。すべてのＨｂｂＴＶ ２．０ウェブソケットクライアントは、ＨｂｂＴＶ ２．０ウェブソケットサーバからクライアント対クライアント連結を要求するためにこのセクションで説明されたメソッドを使用することができる。

図３は、一実施例に係る第２のクライアントの連結を説明する図である。

図３を参照すると、電子装置１００ａ及びコンパニオン装置２００ａが示されている。電子装置１００ａは、アプリケーションプロセッサ及びネットワークプロセッサを含むことができる。ネットワークプロセッサ（例えば、ウェブソケットサーバ）は、ＨｂｂＴＶアプリケーション及びコンパニオンアプリケーションから連結要求を受信することができる。

他のクライアントが上述のメソッドを用いて各クライアント間の連結を要求するとき、サーバは、図３に示すように、新たな要求のためのストリームヘッドを生成することができる。新たなストリームヘッドが生成された後、サーバは、ＵＲＩ要求及び新たに生成されたストリームヘッドとマッチするホストヘッダフィールド値のために現在連結待機中のストリームヘッドの集合を検索することができる。何らのマッチングも発見されない場合、サーバは、新たに生成されたストリームヘッドを連結のために待機中のストリームヘッドの集合に追加し、追加的な各クライアント間の連結要求を待つことができる。

言い換えれば、他のクライアントが上述のメソッドを用いてクライアント対クライアント連結を要求するとき、サーバは、図３に示すように、新たな要求のためのストリームヘッドを生成することもできる。新たなストリームヘッドが生成された後、サーバは、ＵＲＩ要求及び新たに生成されたストリームヘッドとマッチするホストヘッダフィールド値のために現在連結待機中のストリームヘッドの集合を検索することができる。何らマッチも発見されない場合、サーバは、新たに生成されたストリームヘッドを連結のために現在待機中のストリームヘッドの集合に追加し、追加的なクライアント対クライアント連結要求のための待機を維持することができる。

図４は、一実施例に係る第１及び第２のクライアント間の連結を説明する図である。

図４を参照すると、電子装置１００ａ及びコンパニオン装置２００ａが示されている。電子装置１００ａは、アプリケーションプロセッサ及びネットワークプロセッサを含むことができる。ネットワークプロセッサ（例えば、ウェブソケットサーバ）は、ＨｂｂＴＶアプリケーションとコンパニオンアプリケーションとを連結することができる。

新たに生成されたストリームヘッドが現在連結のために待機するストリームヘッドの集合内のストリームヘッドとして同一のホストヘッダフィールド値及び同一のＵＲＩ要求（Ｒｅｑｕｅｓｔ―ＵＲＩ）と連関している場合、ウェブソケットサーバは、その集合からマッチするストリームヘッドを除去し、二つのストリームヘッド間の双方向通信チャネルを設立することができる。

二つのストリームヘッドが連結されると、サーバは、直ぐ一つのストリームヘッドから受信したすべてのデータを出力し、それぞれ他のストリームヘッドに変更しない。このようにすると、二つのクライアント間の透明な通信チャネル（ａ ｔｒａｎｓｐａｒｅｎｔ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｃｈａｎｎｅｌ）を設立することができる。

二つのクライアントのうち一つがクローズフレーム（Ｃｌｏｓｅ ｆｒａｍｅ）を伝送すると、サーバは、他のクライアントに対応するクローズフレームを伝送することができる。二つのクライアントのうち一つがクローズフレームを伝送しない状態で連結を解除すると、サーバは、クローズフレームを生成して他のクライアントに伝送することができる。

すなわち、ネットワークプロセッサは、アプリケーションプロセッサの連結要求があるとき、アプリケーションプロセッサのストリームヘッドを生成してストリームヘッドグループに含ませることができる。そして、ネットワークプロセッサは、コンパニオン装置から連結要求を受けると、コンパニオン装置のストリームヘッドを生成し、マッチするストリームヘッドの存在有無を検索することができる。マッチするストリームヘッドが存在すると、ネットワークプロセッサは、ストリームヘッドグループに含まれるマッチするアプリケーションプロセッサのストリームヘッドとコンパニオン装置のストリームヘッドとを連結することができる。このとき、ネットワークプロセッサは、マッチするアプリケーションプロセッサのストリームヘッド又はコンパニオン装置のストリームヘッドをストリームヘッドグループから除去することができる。

言い換えれば、新たに生成されたストリームヘッドが、現在連結待機中のストリームヘッドの集合内のストリームヘッドとして同一のＵＲＩ要求（Ｒｅｑｕｅｓｔ―ＵＲＩ）及びホストヘッダフィールド値と連関している場合、サーバは、その集合からマッチするストリームヘッドを除去することができ、図４に示したように、二つのストリームヘッド間の全二重通信チャネルを設立することができる。二つのストリームヘッドが連結されると、サーバは、直ぐ一つのストリームヘッドから受信したすべてのデータを出力し、それぞれ他のストリームヘッドに変更しない。その結果、二つのクライアント間に透明な通信チャネル（ａ ｔｒａｎｓｐａｒｅｎｔ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｃｈａｎｎｅｌ）が設立される。二つのクライアントのうち一つがクローズフレーム（Ｃｌｏｓｅ ｆｒａｍｅ）を伝送すると、サーバは、他のクライアントに対応するクローズフレームを伝送することができる。二つのクライアントのうち一つがクローズフレームを伝送しない状態で連結を切ると、サーバは、クローズフレームを生成することができ、これを他のクライアントに伝送することができる。

図５は、一実施例に係る追加連結要求を説明する図である。

図５を参照すると、ＨｂｂＴＶアプリケーション（クライアント）は、コンパニオン装置２００ａのコンパニオンアプリケーション（クライアント）と連結されている。そして、ＨｂｂＴＶアプリケーションは、他のクライアントのための他のストリームヘッドを生成することができる。ＨｂｂＴＶアプリケーションは他のアプリケーションとさらに連結することができる。ストリームヘッドは、各クライアント間の連結を設立する前に連結可能なストリームヘッド集合から除去されるので、各クライアント間の連結は１対１になり得る。クライアントが一つ以上の他のクライアントとの通信を望む場合、クライアントは、処理可能な各クライアント間の連結最大数に至るまで追加連結要求をサーバに伝送することができる。

ウェブソケットサーバは、連結のために待機するストリームヘッド集合上で同一のＵＲＩ要求とホストを有する同一のクライアントのための一つ以上のストリームヘッドを承諾しない。クライアントが一つの成功的な連結やタイムアウト前に同一のＵＲＩ要求及びホストを有する他のクライアントとの連結要求を発行すると、サーバは４０３禁止応答（４０３ Ｆｏｒｂｉｄｄｅｎ ｒｅｓｐｏｎｓｅ）に反応することができる。

クライアントは、連結される待機状態でいくつかの別個のＵＲＩ要求／ホスト組み合わせの各クライアント間の連結要求を有することができる。クライアントは、一つが成功的に連結されたりタイムアウトされる前に同一のＵＲＩ要求／ホスト組み合わせを有して他のクライアントとの連結を要求する試みをすることができない。

言い換えれば、任意のストリームヘッドは、クライアント対クライアント連結を設立する前に連結に使用可能なストリームヘッド集合から除去され、このようなクライアント対クライアント連結は１対１のみである。クライアントが一つ以上の他のクライアントとの通信を望む場合、クライアントは、処理可能なクライアント対クライアント連結の最大数に至るまで追加連結要求をサーバに発行することができる。サーバは、現在連結待機中のストリームヘッド集合上で同一のＵＲＩ要求とホストを有する同一のクライアントのための一つ以上のストリームヘッドを承諾しない。クライアントが一つの成功的な連結又はタイムアウト前に同一のＵＲＩ要求及びホストを有する他のクライアント対クライアント連結要求を発行すると、サーバは４０３禁止応答（４０３ Ｆｏｒｂｉｄｄｅｎ ｒｅｓｐｏｎｓｅ）に反応することができる。クライアントは、連結される待機状態で異なるＵＲＩ要求／ホスト組み合わせのいくつかのクライアント対クライアント連結要求を有することができる。クライアントは、一つが成功的に連結されたりタイムアウトされる前に同一のＵＲＩ要求／ホスト組み合わせを有して他のクライアント対クライアント連結を要求する試みをしない。

他のものと共に行われ、標準ウェブソケットサーバ機能を使用し、それらの間の干渉をなくすために、特定の装置間の動作としてＵＲＩ要求のための／ｈｂｂｔｖ／ｏｒｇｉｄ．ａｐｐｉｄスキーム（ｓｃｈｅｍｅ）を使用することができる。ＵＲＩ要求及びホストヘッダフィールドのマッチングは、二つの接近方法を許容することができる。第一に、特定の装置（クライアント）がホストヘッダによってターゲットにされると、クライアントは、そのターゲットにされた特定のクライアントとの対話を希望することができる。他の手段（例えば、ＵＰｎＰのパートとしてＳＳＤＰ）を通じてその存在に対して認識することができる。第二に、ホストヘッダフィールドがサーバをターゲットにすると、同一のサーバをターゲットにするすべてのクライアントにおいて同一であり得る。これは、ＵＲＩ要求のみが適切な通信ピアを選択するための差別的な要素であることを示す。このようにホストヘッダフィールドで効果的にサーバをターゲットにすることは、同一のＵＲＩ要求を使用してサーバをターゲットにする他のクライアントとマッチするワイルドカードを提供することができる。専用的且つ機会的な連結設立戦略が可能である。

言い換えれば、他の標準ウェブソケットサーバ機能と共に実行され、それらの間の干渉をなくすために、特定のサーバクライアント対クライアント動作への流出としてＵＲＩ要求のための／ｈｂｂｔｖ／ｏｒｇｉｄ．ａｐｐｉｄスキームを使用する。ＵＲＩ要求及びホストヘッダフィールドのマッチングの選択は、二つの接近方法を許容することができる。第一に、特定の装置がホストヘッダによってターゲットにされると、クライアントは、その特定の他のクライアントとの対話のみを希望することができる。他の手段（例えば、ＵＰｎＰのパートとしてＳＳＤＰ）を通じてその存在に対して認識することができる。第二に、ホストヘッダフィールドがサーバをターゲットにすると、同一のサーバをターゲットにするすべてのクライアントにおいて同一であり得る。これは、ＵＲＩ要求のみが適切な通信ピアを選択するための差別的な要素であるという結果になり得る。このようにホストヘッダフィールドで効果的にサーバをターゲットにすることは、同一のＵＲＩ要求を使用してサーバをターゲットにする他のクライアントとマッチするワイルドカードを提供する。そのため、専用的且つ機会的な連結設立戦略が可能である。

ＨｂｂＴＶ ２．０ウェブソケットサーバは、何ら認証、許可又は確認過程も行わないので、各クライアント間の連結やクライアントとウェブソケットサーバとの間の信頼性がない場合がある。個人情報又はウェブソケットサーバを介した敏感な情報を交換しようとするクライアントは、通信プライバシーを保証する終端間暗号を行うことができる。クライアントは、ウェブソケットサーバを介して通信を行うピアの身元や真偽を設立する暗号化方式を行うことができる。ＨｂｂＴＶ ２．０ウェブソケットサーバは、連結されたインターネットを介して表示されたクライアントとの連結を設立するので、ＨｂｂＴＶウェブソケットサーバを介して他のクライアントに対する成功的なサービス拒否攻撃（ｄｅｎｉａｌ―ｏｆ―ｓｅｒｖｉｃｅ ａｔｔａｃｋ）を受けない場合もある。攻撃を受けるクライアントは、サーバに他のクライアントへの連結を要求することを中止することができる。

サーバは、未だに連結されていないＵＲＩ連結／ホスト組み合わせへの同時連結試みを拒絶することに定義したので、サービス拒否攻撃は、サーバ自体に対して試みられる場合もある。これは、エラー応答が生成されるように同一の連結要求を繰り返して伝送したり、多くのオープンストリームヘッドを生成し、サーバのリソースを消費するための一つの試みとしてランダム連結要求を伝送することによって行うことができる。二つの技術は、ＨＴＴＰサーバに対する一般的な戦略であって、ウェブソケットやＨｂｂＴＶ使用の特定なものではない。いずれかのウェブソケットサーバ実行は適切な軽減構造を有することができる（例えば、応答伝送やストリームヘッドの生成を中止させることによって）。

言い換えれば、ＨｂｂＴＶ ２．０ウェブソケットサーバは、何ら認証、許可又は他の確認も行わないので、クライアント対クライアント連結やクライアントとウェブソケットサーバとの間の信頼性がない場合がある。個人情報又はウェブソケットサーバを介した敏感な情報を交換しようとするクライアントは、通信プライバシーを保証する終端間暗号を用いることができる。同様に、このようなクライアントは、ウェブソケットサーバを介して通信を行うことを望む任意の通信ピアの身元及び真偽を設立する暗号化方式を用いることができる。ＨｂｂＴＶ ２．０ウェブソケットサーバは、連結された意図を示したクライアントのみとの連結を設立するので、ＨｂｂＴＶウェブソケットサーバを介して他のクライアントに対する成功的なサービス拒否攻撃（ｄｅｎｉａｌ―ｏｆ―ｓｅｒｖｉｃｅ ａｔｔａｃｋ）が行われない場合もある。攻撃を受けるクライアントは、サーバに他のクライアントへの連結を要求することを簡単に中止することができる。

サーバは、未だに連結されていないＵＲＩ連結／ホスト組み合わせへの同時連結試みを拒絶することに定義したので、サービス拒否攻撃は、サーバ自体に対して試みられる場合もある。これは、エラー応答が生成されるように同一の連結要求を繰り返して伝送したり、又は多くのオープンストリームヘッドを生成し、サーバのリソースを消費するための一つの試みとしてランダム連結要求を伝送することによって行うことができる。二つの技術は、ＨＴＴＰサーバに対する一般的な戦略であって、ウェブソケットやＨｂｂＴＶ使用の特定なものではない。そのため、任意のウェブソケットサーバ実行は適切な軽減構造を有することができる（例えば、応答伝送やストリームヘッドの生成を中止させることによって）。

図６は、一実施例に係るＩＰアドレスがない場合における各クライアント間の連結を説明する図である。

図６を参照すると、各クライアント間の通信連結を行う方法が示されている。上述したウェブソケット基盤の各アプリケーション間の通信方法は、ウェブソケットサーバが、ＵＲＩの経路（ホストネームを除いた残りの経路（ｐａｔｈ）が同一であるアプリケーション同士を連結させ、各アプリケーション間の通信を可能にし得る。クライアント間の通信は、電子装置で駆動されるアプリケーション（例えば、ＴＶアプリケーション）とコンパニオン装置で駆動されるアプリケーション（ＣＳアプリケーション）とを区分し、選択的に各アプリケーション間の通信を行うことができる。

一実施例として、ＨｂｂＴＶにおいて、ＵＲＩ要求（Ｒｅｑｕｅｓｔ―ＵＲＩ）は、ＩＰアドレスを含まない状態で構成することができる。ＵＲＩの経路は、ルート（"／"）の後のＨｂｂＴＶを知らせる予約語（"ｈｂｂｔｖ"）から始め、その後に機関又は会社区分子（ｏｒｇ―ｉｄ）及びアプリケーション区分子（ａｐｐ―ｉｄ）を含んで構成することができる。ウェブソケットサーバ（ネットワークプロセッサ）は、ウェブソケットＡＰＩコールのＵＲＩ経路が同一であるアプリケーション同士を連結させることができる。

シンタックス）ＧＥＴ"／ｈｂｂｔｖ／"ｏｒｇ―ｉｄ"．"ａｐｐ―ｉｄ

実施例）ＧＥＴ／ｈｂｂｔｖ／ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐ

一方、連結を要求する各クライアントは、同一又は異なるポートを使用することができる。各クライアントが同一のポートを使用する場合、ウェブソケットＡＰＩを呼び出すアプリケーションのＩＰが同一であると、ウェブソケットサーバは、呼び出すアプリケーションがＨｂｂＴＶアプリケーションであることが分かり、ＩＰが異なる場合、コンパニオン装置アプリケーションであることが分かる。同一のポートを使用する場合、ウェブソケットサーバはサーバ実行とテストを簡素化することができ、ディスカバリが不要であるという長所がある（ほとんどのウェブソケットライブラリでは、ポート当たりに異なるインスタンスを開始する必要がある。ａｐｐ―２―ａｐｐサーバがＴＶの明確に定義されたポート上で聞く場合、ディスカバリが必要でない。）

次に、各クライアントが異なるポートを使用する場合を説明する。この場合は、ＴＶで駆動するアプリケーションとコンパニオン装置で駆動するアプリケーションとが同一のＵＲＩ経路を使用するが、別個のポートを使用する場合を意味する。一実施例として、ＴＶで駆動するＨｂｂＴＶアプリケーションは８９００ポートを使用し、コンパニオン装置で駆動するアプリケーションは８９０１ポートを使用することができる。ウェブソケットサーバがＴＶアプリケーション／コンパニオンアプリケーションが使用するポートを知ると、ＴＶアプリケーション／コンパニオンアプリケーション間の通信とコンパニオンアプリケーション／コンパニオンアプリケーション間の通信とを区分することができる。異なるポートを使用するとき、互いに同一のホスト要求―ヘッダを使用して多数のコンパニオン装置がＴＶに連結される場合、これを区分して各クライアント間の連結を容易に行うことができる。ＴＶとコンパニオン装置はいずれも同一のホスト要求―ヘッダを有するが、ウェブソケットサーバに別個のポートを介して接続して通信するので、いずれの装置がコンパニオン装置で、いずれの装置がＴＶであるのかを知ることができる。これによって、保安側面で補完することができる。

図７は、一実施例に係る各アプリケーション間の連結のための待機連結を説明する図である。

図７を参照すると、電子装置１００ａ及びコンパニオン装置２００ａが示されている。電子装置１００ａのＴＶアプリケーションは、ウェブソケットサーバに連結要求を伝送することができる。ＴＶアプリケーションは電子装置内に含まれているので、ウェブソケットサーバはＴＶアプリケーションをローカルアプリケーションとして認識することができる。そして、コンパニオンアプリケーションは電子装置の外部に存在するので、ウェブソケットサーバはコンパニオンアプリケーションを遠隔アプリケーションとして認識することができる。一実施例として、アプリケーションは、連結要求をするとき、次のようなメソッドを使用することができる。

一実施例として、ネットワークプロセッサは、Ｗ３ＣウェブソケットＡＰＩを実行することができ、少なくとも２００個の同時ウェブソケット連結をサポートすることができる。

ネットワークプロセッサは、ウェブソケットプロトコル仕様のサーバ側で実行する二つのサービスエンドポイントを提供することができる。ローカルエンドポイントは、ＨｂｂＴＶアプリケーションによってネットワークプロセッサに連結するためのものである。遠隔エンドポイントは、他の装置のアプリケーションによってホームネットワークに連結することができ、他のＨｂｂＴＶ装置で駆動する遠隔コンパニオンアプリケーション又はＨｂｂＴＶアプリケーションを含むためのものである。ＨｂｂＴＶアプリケーションは、それらが動作するネットワークプロセッサのローカルサービスエンドポイントや同一のホームネットワーク上の他のハイブリッドターミナルの遠隔サービスエンドポイントに連結することができる。ネットワークプロセッサは、ホームネットワーク内の他の装置のローカルサービスエンドポイントに連結しない方がよい。例えば、これは、ネットワークプロセッサのローカルループバックインタフェースのローカルサービスエンドポイントを位置させることによって達成することができる。他のサービスエンドポイントがウェブソケットプロトコル仕様のサーバ側を実行し、ＨｂｂＴＶアプリケーションやコンパニオンアプリケーションがそのようなサービスエンドポイントを使用すると、ハイブリッドターミナルは、他のサービスエンドポイントとして同一のホスト及びポート組み合わせでサービスエンドポイントを位置させてはならない。

各アプリケーション間のサービスエンドポイントのための基本ＵＲＬは、ウェブソケットＵＲＬであり得る。ウェブソケットＵＲＬは、ホスト、ポート、保安及びサービスエンドポイントのリソースネームを定義することができる。クライアントは、サービスエンドポイントのウェブソケットＵＲＬによって明示されたホストとポートに連結しなければならない。クライアントによって最初のプロトコル要求で使用されるリソースネームはＡＢＮＦ文法に従う。

ｒｅｓｏｕｒｃｅ―ｎａｍｅ＝ｂａｓｅ―ｕｒｌ―ｒｅｓｏｕｒｃｅ―ｎａｍｅ ａｐｐ―ｅｎｄｐｏｉｎｔ

ｂａｓｅ―ｕｒｌ―ｒｅｓｏｕｒｃｅ―ｎａｍｅは、サービスエンドポイントのウェブソケットＵＲＬから導出されたリソースネームである。ａｐｐ―ｅｎｄｐｏｉｎｔはアプリケーション仕様である。これは、クライアントに対応するクライアントの連結マッチングプロセスに使用することができる。対応するクライアントのメッセージは、ウェブソケットプロトコルを通じて伝達することができる。ａｐｐ―ｅｎｄｐｏｉｎｔは、衝突を避けるためにアプリケーションデベロッパによって選択することができる。したがって、ａｐｐ―ｅｎｄｐｏｉｎｔは、ＨｂｂＴＶアプリケーション又はコンパニオンアプリケーション及びそのデベロッパと独特に連関したリバースＤＮＳ表記で形式化された識別子から始めることができる。ハイブリッドターミナルは、少なくとも１０００文字の長さとウェブソケットプロトコル仕様によってリソースネームで許容されたいずれかの文字を含むａｐｐ―ｅｎｄｐｏｉｎｔをサポートすることができる。

サービスエンドポイントは、クライアントから少なくとも１０個の同時ＴＣＰソケット連結をサポートすることができる。クライアントがサーバとＴＣＰソケットとの間の連結をオープンするために努力するとき、サーバは、サーバが同時連結を取り扱えないと要求を拒絶することができる。そうでない場合、サーバは、ＴＣＰソケット連結を承認し、ウェブソケットプロトコルハンドシェイクを始めることができる。サーバは、クライアント要求ハンドシェイクを受信するが、ハンドシェイク応答に直ぐ応答しない場合もある。その代わりに、サーバは、連結がペアになるまで又はクライアントの連結が解除されるまで待つことができる。この状態で、連結は待機連結を構成することができる。サーバがタイムアウトを実行しようとする場合、サーバは５０４ゲートウェイタイムアウト応答に反応することができる。

サーバは、クライアントによって伝送された要求ハンドシェイクのいずれかのオリジン（ｏｒｉｇｉｎ）ヘッダを無視することができる。クライアントは、各クライアント間の連結を要求するとき、Ｓｅｃ―ウェブソケット―プロトコルヘッダを使用しないこともある。サーバは、各クライアント間の連結のための要求においてＳｅｃ―ウェブソケット―プロトコルヘッダを無視することができる。サーバは、Ｓｅｃ―ウェブソケット―プロトコルヘッダを使用するプロトコル拡張のためのクライアント要求を承認しないこともある。クライアントがＳｅｃ―ウェブソケット拡張ヘッダを使用すると、サーバは、ウェブソケットプロトコル仕様で定義された方式で連結できないこともある。

図７に示したように、クライアントとして動作するＨｂｂＴＶアプリケーションが"ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐ"のａｐｐ―ｅｎｄｐｏｉｎｔと／ｈｂｂｔｖ／のｂａｓｅ―ｕｒｌ―ｒｅｓｏｕｒｃｅ―ｎａｍｅを有するローカルサービスエンドポイントとの連結を試みることができる。コンパニオン装置との連結は、コンパニオンアプリケーションが未だに同一のａｐｐ―ｅｎｄｐｏｉｎｔを使用する各アプリケーション間の通信に連結できなかったため待機状態を維持することができる。

図８は、一実施例に係る第２のクライアントとの連結のための新たな連結要求を説明する図である。

図８を参照すると、ＨｂｂＴＶアプリケーション（クライアント）は、コンパニオン装置２００ａのコンパニオンアプリケーション（クライアント）と連結されている。そして、ＨｂｂＴＶアプリケーションは、他のクライアントのための他のストリームヘッドを生成することができる。

サーバは、同一のａｐｐ―ｅｎｄｐｏｉｎｔを有する同一の本来のＩＰアドレスから一つ以上の同時待機連結を承諾することができない。成功的に連結されたり終了する前に該当するＩＰアドレスのクライアントが同一のａｐｐ―ｅｎｄｐｏｉｎｔを使用する他の連結要求を発行すると、サーバは４０３禁止応答に反応することができる。

クライアントは、他のリソース―ネーム組み合わせを使用する同一のサービスエンドポイントを通じてマルチプル同時クライアント間の連結を設立することを希望することができる。クライアントは、存在するサービスエンドポイントへの連結待機に成功したり、タイムアウトされたり、連結解除される前にサービスエンドポイントから他の連結の要求を試みることができない。このようなクライアントの動作は、ウェブソケットプロトコル仕様によって定義することができる。

図８によると、クライアントが一つ以上のクライアントと通信することを希望すると、クライアントは、存在する待機連結がペアになるまで待機することができる。このとき、処理可能な各クライアント間の連結最大数字に至るまで追加連結要求をサーバに発行することができる。すなわち、ＨｂｂＴＶアプリケーションは、各アプリケーション間の通信の設立を承諾するための新たな待機連結要求を生成することができる。

一方、クライアントは、ＵＲＩ経路にＩＰアドレスを含ませることもできる。

図９は、一実施例に係るＩＰアドレスを含む場合における第１のクライアントの設定を説明する図である。

一実施例として、上述したＵＲＩ経路は、ルート（"／"）の後のＨｂｂＴＶを知らせる予約語（"ｈｂｂｔｂ"）から始め、その後に機関／会社区分子（ｏｒｇ―ｉｄ）及びアプリケーション区分子（ａｐｐ―ｉｄ）を含んで構成することができる。各アプリケーション間の通信を行おうとするアプリケーションがターゲットアプリケーションを指定するために、ＵＲＩの経路にターゲットアプリケーションが駆動中の装置のＩＰアドレスを追加することができる。ウェブソケットサーバは、ウェブソケットＡＰＩコールのＵＲＩ経路が同一であるアプリケーションのうち互いに通信しようとするＩＰによって連結させることができる。

シンタックス）ＧＥＴ"／ｈｂｂｔｖ／"ｔａｒｇｅｔ ＩＰ"／"ｏｒｇ―ｉｄ"．"ａｐｐ―ｉｄ

実施例）ＧＥＴ／ｈｂｂｔｖ／１．１．１．１／ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐ

一実施例として、ＴＶアプリケーションＡがＩＰ １．１．１．１で駆動中で、コンパニオンアプリケーションＢがＩＰ １．１．１．２（第１のユーザ端末機）で駆動中で、コンパニオンアプリケーションＣがＩＰ １．１．１．３（第２のユーザ端末機）で駆動中であり得る。このとき、ＴＶアプリケーションＡがコンパニオンアプリケーションＣと互いに通信しようと試みることができる。ＴＶアプリケーションＡは、ウェブソケット要求に含まれるＵＲＩの経路にコンパニオンアプリケーションＣが駆動中であるＩＰ（１．１．１．３）を含ませることができる。そして、コンパニオンアプリケーションＣは、ウェブソケット要求に含まれるＵＲＩの経路にＴＶアプリケーションＡのＩＰ（１．１．１．１）を含ませることができる。

図９によると、ＵＲＩ経路は、ｈｂｂｔｖ／１９２．０．２．７／ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐ ＨＴＴＰ／１／１と同一であり得る。ここで、１９２．０．２．７は、ターゲットアプリケーションのＩＰアドレスであり得る。１９２．０．２．１１０は自分のＩＰアドレスであり得る。そして、ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐはアプリケーションＩＤであり得る。

図１０は、一実施例に係るＩＰアドレスを含む場合における第１及び第２のクライアントの設定を説明する図である。

ウェブソケットサーバは、それぞれのクライアントから図９を参照して説明したＵＲＩ要求を受信することができる。図１０を参照すると、１９２．０．２．１１０のＩＰアドレスを有する第１のクライアント、及び１９２．０．２．７のＩＰアドレスを有する第２のクライアントがある。第１のクライアントが第２のクライアントに連結を要求する場合、出発地（Ｆｒｏｍ Ｈｏｓｔ）は１９２．０．２．１１０で、到着地（Ｔｏ Ｈｏｓｔ）は１９２．０．２．７になる。そして、アプリケーションＩＤはｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐであり得る。第２のクライアントが第１のクライアントに連結を要求する場合、出発地（Ｆｒｏｍ Ｈｏｓｔ）は１９２．０．２．７で、到着地（Ｔｏ Ｈｏｓｔ）は１９２．０．２．１１０になる。そして、アプリケーションＩＤはｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐであり得る。すなわち、第１のクライアントと第２のクライアントの出発地と目的地の住所は互いに反対になり得る。しかし、アプリケーションＩＤは同一である。ウェブソケットサーバは、マッチするクライアントを互いに連結させることができる。

また、ホストＩＰアドレスを含むＵＲＩ経路を使用することもできる。

例えば、ＵＲＩ経路は、Ｓｙｎｔａｘ）ＧＥＴ"／"ｈｂｂｔｖ"／"ｈｏｓｔ＿ａｄｄｒｅｓｓ"／"ｏｒｇ―ｉｄ"．"ａｐｐ―ｉｄ、

実施例）ＧＥＴ／ｈｂｂｔｖ／１９２．０．２．７／ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐのように使用することができる。

図１１は、ＩＰアドレスを含む場合における複数の第２のクライアントに連結する一実施例を説明する図である。

図１１を参照すると、ＨｂｂＴＶは、一定のＩＰアドレスを有し、ｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐのアプリケーションＩＤを含んでいる。第１のコンパニオンアプリケーションＩＰアドレスは１９２．０．２．７で、第２のコンパニオンアプリケーションＩＰアドレスは１９２．０．２．１である。第１及び第２のコンパニオンアプリケーションのアプリケーションＩＤはｏｒｇ．ｍｙｃｈａｎｎｅｌ．ｍｙａｐｐである。図１０を参照して説明したように、ウェブソケットサーバは、マッチするクライアントを互いに連結させることができる。よって、各クライアントの要求に対応して、ウェブソケットサーバはマッチする各クライアントを互いに連結させることができる。

このように、ＵＲＩ経路にＩＰアドレスを使用する場合、両クライアントは連結対象を指定するので保安性が向上し、各クライアント間の連結が可能であり、別途の努力がなくてもすべての情報のマッチングが可能であるという長所がある。一方、ＵＲＩ経路にＩＰアドレスを使用する場合にも、各クライアントは同一又は別個のポートを使用することができる。

図１２は、一実施例に係る電子装置の制御方法のフローチャートである。

図１２によると、電子装置は、コンパニオン装置と連結することができる（Ｓ１２１０）。電子装置は、ネットワークプロセッサ及びアプリケーションプロセッサを含むことができる。電子装置においては、アプリケーションプロセッサがネットワークプロセッサにコンパニオン装置との連結を要求することができる。ネットワークプロセッサは、コンパニオン装置から連結要求を受けると、連結要求したアプリケーションプロセッサとコンパニオン装置とを連結することができる。

上述したように、アプリケーションプロセッサは、アプリケーションモジュール及びアプリケーションブラウザであるか、又はＨｂｂＴＶアプリケーションであり得る。ネットワークプロセッサはネットワークモジュールとして具現することができる。又は、ネットワークプロセッサは、ウェブソケットサーバであり得る。ネットワークプロセッサがウェブソケットサーバとして具現される場合、アプリケーションプロセッサとコンパニオン装置はそれぞれ一つのクライアントと見なすことができる。又は、第１のクライアントと第２のクライアントをそれぞれピアと呼ぶこともできる。

アプリケーションプロセッサは、ネットワークプロセッサで動作する電子装置情報又はコンパニオン装置情報を示すホスト要求ヘッダ情報をネットワークプロセッサに伝送することができる。そして、ネットワークプロセッサは、アプリケーションプロセッサの連結要求があるとき、アプリケーションプロセッサのストリームヘッドを生成してストリームヘッドグループに含ませることができる。ネットワークプロセッサは、コンパニオン装置から連結要求を受けると、コンパニオン装置のストリームヘッドを生成し、このストリームヘッドをストリームヘッドグループに含まれたマッチするアプリケーションプロセッサのストリームヘッドと連結することができる。このとき、ネットワークプロセッサは、マッチするアプリケーションプロセッサのストリームヘッド又はコンパニオン装置のストリームヘッドをストリームヘッドグループから除去することができる。一方、アプリケーションプロセッサは、連結しようとするコンパニオン装置のＩＰアドレスを伝送することができ、それぞれのアプリケーションは同一のポートを用いることができる。

電子装置は、コンパニオン装置との間でデータを送受信することができる（Ｓ１２２０）。このような過程を通じて、電子装置は、コンパニオン装置と連結して通信を行うことができる。

本明細書に係る電子装置及び制御方法は、上述した各実施例の構成と方法に限定して適用されるものではなく、各実施例の全部又は一部が選択的に組み合わされ、多様な変形が可能である。

一方、本明細書の電子装置の制御方法は、電子装置で備えられたプロセッサで読み取り可能な記録媒体にソフトウェアとして具現可能である。プロセッサで読み取り可能な記録媒体は、プロセッサによって読まれるデータが格納されるすべての種類の記録装置を含む。プロセッサで読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ―ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのキャリアウェーブの形態に具現されるものも含む。また、プロセッサで読み取り可能な記録媒体は、ネットワークで連結されたコンピューターシステムに分散され、分散方式でプロセッサで読み取り可能なコードが格納されて実行され得る。

また、以上では、本明細書の好ましい実施例に対して図示して説明したが、本明細書は、上述した特定の実施例に限定されるものではなく、特許請求の範囲で請求する要旨から逸脱することなく、当該発明の属する技術分野で通常の知識を有する者によって多様な変形実施が可能であることは当然であり、このような変形実施は、本明細書の技術的思想や展望から個別的に理解してはならない。

電子装置で使用可能であり、反復可能性があるという産業上の利用可能性を有する。

Claims (4)

1. 電子装置上でＴＶアプリケーションを実行するアプリケーションプロセッサと、ウェブソケット（WebSocket）プロトコルを用いて前記電子装置をコンパニオン装置と連結するウェブソケットサーバと、を有する制御部と、
   前記コンパニオン装置との間でデータを送受信する通信部と、を有し、
   前記ウェブソケットサーバは、前記通信部を用いて、ウェブソケット連結を介して前記コンパニオン装置上で実行されるコンパニオンアプリケーションと前記ＴＶアプリケーションとの間でデータを中継し、
   前記ウェブソケットサーバは、ローカルサービスエンドポイント及び遠隔サービスエンドポイントを提供し、
   前記ウェブソケットサーバは、第１アプリケーションエンドポイントデータを有し、前記コンパニオンアプリケーションから前記遠隔サービスエンドポイントに送られた第１要求を受信し、
   前記ウェブソケットサーバは、第２アプリケーションエンドポイントデータを有し、前記ＴＶアプリケーションから前記ローカルサービスエンドポイントに送られた第２要求を受信し、
   前記ウェブソケットサーバは、前記第１アプリケーションエンドポイントデータと前記第２アプリケーションエンドポイントデータとが同じであるか否かをマッチングして前記コンパニオンアプリケーションと前記ＴＶアプリケーションとの間の前記ウェブソケット連結を確立するか否かを決定し、前記第１アプリケーションエンドポイントデータ及び前記第２アプリケーションエンドポイントデータは、インターネットプロトコル（ＩＰ）アドレス情報を含まず、
   前記ウェブソケットサーバは、前記コンパニオンアプリケーションと前記ＴＶアプリケーションとの間の前記ウェブソケット連結を確立してデータを中継する、電子装置。
2. 前記アプリケーションプロセッサは、前記遠隔サービスエンドポイントに関するベースＩＰアドレスを前記コンパニオン装置に伝送する、請求項１に記載の電子装置。
3. 電子装置の制御方法であって、
   ウェブソケット（WebSocket）プロトコルを用いて前記電子装置をコンパニオン装置と連結する段階と、
   前記電子装置におけるウェブソケットサーバが、ウェブソケット連結を介して前記コンパニオン装置上で実行されるコンパニオンアプリケーションと前記電子装置上で実行されるＴＶアプリケーションとの間でデータを中継する段階と、を有し、
   前記連結する段階は、
   前記ウェブソケットサーバが、ローカルサービスエンドポイント及び遠隔サービスエンドポイントを提供する段階と、
   前記ウェブソケットサーバが、第１アプリケーションエンドポイントデータを有し、前記コンパニオンアプリケーションから前記遠隔サービスエンドポイントに送られた第１要求を受信する段階と、
   前記ウェブソケットサーバが、第２アプリケーションエンドポイントデータを有し、前記ＴＶアプリケーションから前記ローカルサービスエンドポイントに送られた第２要求を受信する段階と、
   前記第１アプリケーションエンドポイントデータと前記第２アプリケーションエンドポイントデータとが同じであるか否かをマッチングして前記コンパニオンアプリケーションと前記ＴＶアプリケーションとの間の前記ウェブソケット連結を確立するか否かを決定する段階であって、前記第１アプリケーションエンドポイントデータ及び前記第２アプリケーションエンドポイントデータは、インターネットプロトコル（ＩＰ）アドレス情報を含まない段階と、
   前記コンパニオンアプリケーションと前記ＴＶアプリケーションとの間の前記ウェブソケット連結を確立してデータを中継する段階と、を有する、電子装置の制御方法。
4. アプリケーションプロセッサは、前記遠隔サービスエンドポイントに関するベースＩＰアドレスを前記コンパニオン装置に伝送する段階をさらに有する、請求項３に記載の電子装置の制御方法。

Images