JP5937005B2

JP5937005B2 - 近距離ネットワークにおける遠隔制御のための装置及び方法とこれをサポートするシステム

Info

Publication number: JP5937005B2
Application number: JP2012524663A
Authority: JP
Inventors: ホ−ヨン・パク; スン−オ・ファン; ボ−スン・ジュン; ジュン−ヒュン・キム; ジ−ユン・ケウム
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2009-09-01
Filing date: 2010-09-01
Publication date: 2016-06-22
Anticipated expiration: 2030-09-01
Also published as: CN104683451B; EP2474198A4; JP2013502146A; WO2011028022A3; AU2010290258A1; CN102484895A; WO2011028022A2; EP2474198A2; CN102484895B; US9607504B2; CN104683451A; US20110050449A1; AU2010290258B2; EP2474198B1; KR20110025012A

Description

本発明は、近距離ネットワークで遠隔制御のためのユーザインターフェース（User Interface：以下、“ＵＩ”と称する）にマッチングするための装置及び方法に関し、特に、近距離ネットワーク内で装置の性能にマッチングする制御ユーザインターフェース（ＣＵＩ）の動作を可能にするための装置及び方法に関する。

近年、近距離ネットワークに基づくホームネットワーク技術は、多くの産業標準団体によりその性能向上のための研究が活発に進んでいる。このようなホームネットワーク技術の性能向上のための研究を進行している代表的な産業標準団体では、ＤＬＮＡ（Digital Living Network Alliance）、ＨＡＶｉ（Home Audio-Video Interoperability）、ＵＰｎＰ（Universal Plug and Play）などが存在する。

一方、ホームネットワークにおいて、１つの装置は、遠隔ユーザインターフェース（Remote User Interface：以下、“ＲＵＩ”と称する）技術により他の装置を制御することができる。クライアント−サーバアーキテクチャー（client-server architecture）に基づくＲＵＩ技術によると、ＲＵＩクライアント（RUI Client：ＲＵＩＣ）は、ＲＵＩサーバ（RUI Server：ＲＵＩＳ）からＵＩを取ってきて、ユーザがＲＵＩＣでＵＩを通してＲＵＩＳを制御することができるようにする。

したがって、ＲＵＩＣでＲＵＩＳを制御するためには、ＵＩをＲＵＩＳから受信するための方法を開発する必要性が高まっている。

本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、ＲＵＩを通してＲＵＩＳ又はＲＵＩＣを制御することができるＲＵＩを提供するための装置及び方法を提供することにある。

本発明の他の目的は、ＲＵＩＳが遠隔装置の性能にマッチングするＲＵＩを提供することができるようにする装置及び方法を提供することにある。

本発明のまた他の目的は、第３の遠隔装置が遠隔ＵＩ装置をＣＵＩを通して制御することができるように第３の遠隔装置の性能にマッチングするＣＵＩをＲＵＩＳから受信することができるようにする装置及び方法を提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、近距離ネットワークシステムにおけるアプリケーション実行装置の遠隔制御方法を提供する。上記方法は、所定の制御ユーザインターフェース（ＣＵＩ）を用いて上記アプリケーション実行装置を遠隔制御する遠隔装置から上記遠隔装置の性能に関する情報を収集するステップと、現在実行中であるアプリケーション及び上記遠隔装置の性能に関する情報を遠隔制御するために使用されるＣＵＩを要請するＣＵＩ要請をアプリケーションサーバに送信するステップと、上記ＣＵＩ要請に応じて上記遠隔装置の性能にマッチングするＣＵＩを上記アプリケーションサーバから受信するステップと、上記受信されたＣＵＩを上記遠隔装置に送信するステップとを有することを特徴とする。

本発明の他の態様によれば、近距離ネットワークシステムにおける遠隔制御を実行するアプリケーション実行装置を提供する。上記装置は、所定の制御ユーザインターフェース（ＣＵＩ）を用いて上記遠隔装置の性能に関する情報を上記アプリケーション実行装置を遠隔制御する遠隔装置から収集する第１のエンティティーと、現在実行中であるアプリケーション及び上記遠隔装置の性能に関する情報を遠隔制御するために使用されるＣＵＩを要請するＣＵＩ要請を上記アプリケーションサーバに送信し、上記ＣＵＩ要請に応じて上記アプリケーションサーバから上記遠隔装置の性能にマッチングするＣＵＩを受信する第２のエンティティーとを有し、上記第１のエンティティーは、上記第２のエンティティーから受信されるＣＵＩを上記遠隔装置に送信することを特徴とする。

本発明のさらに他の態様によれば、近距離ネットワークシステムにおける遠隔装置で所定の制御ユーザインターフェース（ＣＵＩ）を用いてアプリケーション実行装置を遠隔制御する方法を提供する。上記方法は、上記遠隔装置の性能に関する情報を上記アプリケーション実行装置に送信するステップと、上記遠隔装置の性能にマッチングするＣＵＩを上記アプリケーション実行装置から受信するステップと、上記受信されたＣＵＩを用いて上記アプリケーション実行装置で実行されているアプリケーションを遠隔制御するステップとを有することを特徴とする。

本発明のさらなる他の態様によれば、遠隔制御を通して宣言型のアプリケーション環境（ＤＡＥ）アプリケーションを提供するシステムを提供する。上記システムは、ＤＡＥアプリケーション及び制御ユーザインターフェース（ＣＵＩ）を提供するアプリケーションサーバと、遠隔装置がアプリケーション実行装置に接続された後に自身の性能に関する情報を上記アプリケーション実行装置に送信し、上記遠隔装置の性能にマッチングするＣＵＩを上記アプリケーション実行装置から受信する遠隔装置と、上記遠隔装置から上記遠隔装置の性能に関する情報を収集し、現在実行されているアプリケーション及び上記遠隔装置の性能に関する情報を遠隔制御するために使用されるＣＵＩを要請するＣＵＩ要請を上記アプリケーションサーバに送信し、上記ＣＵＩ要請に応じて上記遠隔装置の性能にマッチングするＣＵＩを上記アプリケーションサーバから受信する上記アプリケーション実行装置とを有することを特徴とする。

本発明は、第３の遠隔装置が自身の性能にマッチングするＣＵＩをＲＵＩＳから受信することができるので、近距離ネットワークの性能を最大化することができる。

本発明の実施形態を適用するための近距離ネットワークシステムの構成を示すブロック図である。本発明の実施形態に従ってＲＵＩＣの外部に存在するエンベデッドサーバを有する近距離ネットワークシステムの構成を示すブロック図である。本発明の実施形態に従ってＲＵＩＣの外部に存在するエンベデッドサーバを有する近距離ネットワークシステムの構成を示すブロック図である。図１のアーキテクチャー上でのインターフェースを示す図である。本発明の実施形態による近距離ネットワークシステムの構成を示すブロック図である。本発明の実施形態による近距離ネットワークシステムにおける性能に関する情報を送信するための動作を示す図である。本発明の実施形態による近距離ネットワークシステムにおける性能にマッチングされたＣＵＩを提供するための方法を示すフローチャートである。本発明の実施形態による近距離ネットワークシステムにおける性能にマッチングされたＣＵＩを提供するための方法を示すフローチャートである。本発明の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明の他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明の他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明の実施形態に従ってＲＵＩがＲＵＩＣで実行されない際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明のまた他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。本発明の一実施形態によるＡＰＩ及びインターフェースを説明する図である。本発明の実施形態によるＡＰＩを説明する図である。本発明の実施形態によるＡＰＩを説明する図である。本発明の実施形態による第３のＲＵＩＣがＯＩＴＦでＩＰＴＶサービスを実行させるためのインターフェース及びメッセージを説明する図である。本発明の実施形態による第３のＲＵＩＣがＯＩＴＦで現在実行されるＤＡＥアプリケーションを制御するためのＣＵＩを要請するためのインターフェース及びメッセージを説明する図である。

本発明の詳細な構成および要素のような本発明の詳細な説明で定義される特徴は、本発明の実施形態の包括的な理解を助けるために提供される。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。

本発明の実施形態に従って、遠隔ユーザインターフェースクライアント（Remote User Interface Client：以下、“ＲＵＩＣ”と称する）は、クライアント−サーバアーキテクチャーシステムで遠隔ＵＩ（Remote User Interface：以下、“ＲＵＩ”と称する）及び制御情報をクライアントに送信する装置を意味する。ここで、ＲＵＩＣは、インターネットプロトコルＴＶ（ＩＰＴＶ）などを制御するセットトップボックスであり得る。

ＲＵＩＣは、遠隔ＵＩサーバ（Remote User Interface Server：以下、“ＲＵＩＳ”と称する）からＲＵＩＣで表現されるＵＩ及びＲＵＩＣで表現されるＵＩを制御することができる制御ＵＩ（Control User Interface：ＣＵＩ）を受信する。ＲＵＩＣ及び／又はＲＵＩＣでレンダリングされるＲＵＩは、ＣＵＩを通して制御される。

一方、本発明の実施形態において、遠隔制御ＲＵＩＣ装置（remote control RUIC device）である第３の装置は、ＣＵＩを通してＲＵＩＣを制御する。この際に、ＣＵＩは、ＲＵＩＣ又はＲＵＩＳから受信され得る。第３の装置は、移動装置（例えば、携帯電話機など）、携帯装置（例えば、通信機能を有する小型表示装置）などであり得る。下記の説明は、‘遠隔制御ＲＵＩＣ装置’が第３の装置、‘第３のＲＵＩＣ’、又は‘第３のＲＵＩＣ装置’で混用されて使用されることができることに留意すべきである。

図１は、本発明の実施形態を適用するための一般的な近距離ネットワークシステムの構成を示すブロック図であって、第３のＲＵＩＣを通してＲＵＩＣの制御を可能にするアーキテクチャーを示す。

図１を参照すると、ＲＵＩＣ１００は、第１のインターフェース１０３（Ｉ／Ｆ１）を介して所定のプロトコルに従ってＲＵＩＳ１０１と通信する。ＲＵＩＣ１００は、Ｉ／Ｆ１上で使用するプロトコルに基づいてＲＵＩＳ１０１からＲＵＩ及び制御情報を受信する。ここで、制御情報は、ＲＵＩＣ１００で表現されるＲＵＩを制御するのに必要とされる制御情報だけではなくＣＵＩも含まれ得る。

ＲＵＩＣ１００のエンベデッドサーバ１０５は、ＲＵＩＳ１０１から受信された制御情報からＣＵＩを抽出し、該ＣＵＩをＲＵＩＣ１００の制御のために第３のＲＵＩＣ１０２に送信する。ＣＵＩは、第３のＲＵＩＣ１０２に表現されることにより第３のＲＵＩＣ１０２のユーザがＣＵＩを介してＲＵＩＣ１００を制御することができる。

エンベデッドサーバ１０５は、ＲＵＩＣ１００の内部又は外部に存在し得る論理的なエンティティーである。

図２及び図３は、エンベデッドサーバ１０５がＲＵＩＣ２０１の外部に存在し得る場合を示す。特に、エンベデッドサーバ１０５は、移動／携帯装置との通信のために、ＣＥＡ（Consumer Electronics Association）−２０１４ＲＵＩＳ２０２、ＤＬＮＡＲＵＩＳ３０３、又はオープンＩＰＴＶフォーラムのオープンＩＰＴＶフォーラム端末機能（ＯＩＴＦ）３００内に存在するエンベデッドサーバ機能エンティティー（Functional Entity）であり得る。また、エンベデッドサーバ１０５は、ＲＵＩＣ２０１内の遠隔制御（ＲＣ）プラグイン２０３の機能までさらに組み込むことができる。

ＲＵＩＣ１００又はＲＵＩＣ１００で表現されているＲＵＩは、第３のＲＵＩＣ１０２で表現されているＣＵＩを用いてＵＰｎＰ又はＨＴＴＰ（HyperText Transfer Protocol）に従ってＲＵＩＣ１００と第３のＲＵＩＣ１０２間の第２のインターフェース１０４（Ｉ／Ｆ２）を介して制御され得る。

図４は、図１のアーキテクチャー上でのインターフェースを示す図である。すなわち、図４では、第３のＲＵＩＣ１０２が第３のＲＵＩＣ１０２の性能をＲＵＩＳ１０１に通知するためのプロトコルの定義が必要であることを示している。

図４を参照すると、第３のＲＵＩＣ１０２は、ＲＵＩＣ１００のエンベデッドサーバ１０５と性能交換（Capability Exchange）を介して第３のＲＵＩＣ１０２にマッチングするＣＵＩをＲＵＩＣ１００から持ってくることができる。その理由は、第３のＲＵＩＣ１０２とＲＵＩＣ１００間のＩ／Ｆ２に対するプロトコルが定義されているためである。

しかしながら、第３のＲＵＩＣ１０２が第３のＲＵＩＣ１０２の性能に関する情報をＲＵＩＳ１０１に送信することができる方法がない。結果的に、第３のＲＵＩＣ１０２は、自身の性能にマッチングするＣＵＩをＲＵＩＳ１０１から持ってくることができない。

したがって、本発明の実施形態に従って、ＲＵＩＳ１０１が第３のＲＵＩＣ１０２の性能にマッチングするＣＵＩを第３のＲＵＩＣ１０２に提供することができるようにするためのＩ／Ｆ１及び第３のインターフェース（Ｉ／Ｆ３）に対するプロトコルを定義する。

本発明の実施形態に従って、第３のＲＵＩＣがＲＵＩＣで実行されている１つのＲＵＩを制御するためのＣＵＩをＲＵＩＳから受信するようにする際に、第３のＲＵＩＣがその性能にマッチングするＣＵＩを受信することができるようにする方法及び装置について具体的に説明する。

図５は、本発明の実施形態による近距離ネットワークシステムの構成を示すブロック図である。すなわち、図５は、第３のＲＵＩＣ５０２が第３のＲＵＩＣ５０２の性能に関する情報をＲＵＩＣ５００を通してＲＵＩＳ５０９に送信するためのインターフェースを示す。

図５を参照すると、第３のＲＵＩＣ５０２は、Ｉ／Ｆ２を通して自身の性能に関する情報をＲＵＩＣ５００のエンベデッドサーバ５０６に送信する。エンベデッドサーバ５０６は、受信された性能情報を第４のインターフェース５１０（Ｉ／Ｆ４）を通してＲＣプラグイン５０８に送信する。

ＲＣプラグイン５０８は、性能情報を記憶する。第１のブラウザー５０５（ブラウザー１）は、インターフェース５１１（Ｉ／Ｆ５）を通してＲＣプラグイン５０８にＣＵＩダウンロード命令を送信することにより自身により表現されるＲＵＩとの通信を用いてＣＵＩをダウンロードするように命令する。

ブラウザー１からＣＵＩダウンロード命令を受信する際に、ＲＣプラグイン５０８は、記憶された性能情報を第６のインターフェース（Ｉ／Ｆ６）を通して送信可能なフォーマットに変換する。必要であれば、この記憶された性能情報のフォーマットを変換しないこともある。Ｉ／Ｆ６は、ＲＵＩＣ５００とＲＵＩＳ５０９間のインターフェースを意味する。

ＲＣプラグイン５０８は、ＣＵＩダウンロードを要請するＨＴＴＰメッセージをＩ／Ｆ６を介してＲＵＩＳ５０９に送信する。ＨＴＴＰメッセージのヘッダーは、ユーザエージェント値に変換された性能に関する情報を含む。上述したように、この性能に関する情報は、必要の場合には変換されない情報であり得る。

図６は、本発明の実施形態による近距離ネットワークシステムにおける性能情報を送信するための動作を示す図である。すなわち、図６において、第３のＲＵＩＣ５０２に関する性能情報は、ＲＵＩＣ５００を通してＲＵＩＳ５０９に送信される。

図６を参照すると、第３のＲＵＩＣ５０２は、自身の性能に関する情報をＲＵＩＣ５００に送信する。下記表１は、ＨＴＴＰヘッダー内に性能情報が含まれた構造の一例を示す。

上記の<表１>に示すユーザエージェント値として表現される性能情報を受信する際に、ＲＵＩＣ５００は、この受信された性能情報をＲＣプラグイン５０８に提供する。ＲＣプラグイン５０８は、この性能情報をＲＵＩＳ５０９に送信可能なフォーマットに変換する（例えば、User-Agent A-）。

例えば、この性能情報がＯＩＰＦにより定義されたフォーマットで送信される場合に、ＯＩＰＦにより定義されたヘッダー構造は、下記の表２に示すように、この変換された性能情報をＨＴＴＰヘッダー内に含むように変更され得る。

上記の表１に示す性能情報は、上記の表２に示す構成を有する性能情報に含まれる。例えば、この性能情報は、上記の表２に示す<reserved>フィールドに含まれ得る。

第３のＲＵＩＣ５０２からＲＵＩＣ５００に送信されたUser-Agent Aの形態を取る性能情報６００がＲＵＩＣ５００からＲＵＩＳ５０９に送信されたUser-Agent A-の形態を取る性能情報６０１と同一のフォーマットで構成される場合に、性能情報６００は、フォーマット及び内容の変更なしにＲＵＩＣ５００からＲＵＩＳ５０９に送信され得る。

図７及び図８は、本発明の実施形態による近距離ネットワークシステムにおける性能にマッチングされたＣＵＩを提供するための方法を示すフローチャートである。すなわち、図７及び図８は、ＲＵＩＳからＲＵＩＣを通して第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための動作を示す。

具体的に、図７は、第３のＲＵＩＣがＲＵＩＣに現在接続されている場合におけるＣＵＩ提供動作を示すフローチャートであり、図８は、第３のＲＵＩＣがＲＵＩＣに現在接続されておらず、第３のＲＵＩＣが後でＲＵＩＣに接続される際にＣＵＩを要請する場合におけるＣＵＩ提供動作を示すフローチャートである。

図７を参照すると、ＲＵＩＣは、ステップ７００でＲＵＩをＲＵＩＳに要請する。ＲＵＩＳは、この要請されたＲＵＩをＲＵＩＣに送信する。ステップ７０１で、ＲＵＩＣは、ＲＵＩＳから提供されたＲＵＩを実行する。

ステップ７０２で、ＲＵＩは、ＲＵＩＣに現在接続された第３のＲＵＩＣが存在するか否かをモニタリングする。現在接続された第３のＲＵＩＣが存在しないと、ステップ７０３に進み、ＲＵＩに関連したＣＵＩ要請過程をこれ以上進行しない。第３のＲＵＩＣが後でＲＵＩＣに接続されＣＵＩを要請する場合に、図８に示す動作が実行される。

一方、ステップ７０２で、ＲＵＩＣに現在接続された第３のＲＵＩＣが存在すると、ＲＵＩＣは、ステップ７０４で、性能情報を第３のＲＵＩＣに要請し、この性能情報を第３のＲＵＩＣから受信する。

ステップ７０５で、ＲＵＩＣは、第３のＲＵＩＣの性能にマッチングするＣＵＩをＲＵＩＳに要請する。その後に、ＲＵＩＳは、ＣＵＩをＲＵＩＣに送信する。

ＲＵＩＣは、ステップ７０６で、ＣＵＩを第３のＲＵＩＣに送信する。
図８を参照すると、図７の動作でＲＵＩが実行される際に、第３のＲＵＩＣがＲＵＩＣに現在接続されていないが、後で第３のＲＵＩＣがＲＵＩＣに接続され、ＣＵＩをＲＵＩＣに要請する場合に、ＲＵＩＣは、ステップ７１０でＲＵＩが実行されている途中に第３のＲＵＩＣからＣＵＩ要請を受信する。ステップ７１１で、第３のＲＵＩＣは、第３のＲＵＩＣの性能情報をＲＵＩＣに送信する。

ステップ７１２で、ＲＵＩＣは、ＣＵＩ要請を性能情報とともにＲＵＩＳに送信する。その後に、ＲＵＩＳは、この性能情報で示された性能にマッチングするＣＵＩを抽出し、この抽出されたＣＵＩをＲＵＩＣに送信する。ＲＵＩＣは、ステップ７１３で、ＣＵＩを第３のＲＵＩＣに送信する。

図９は、本発明の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに送信するための信号フローを示す図である。

図９を参照すると、第３の端末又は伝統的な遠隔制御からの命令を実行するＲＵＩを受信すると、ＲＵＩＣ９０１は、ＲＵＩをＲＵＩＳ９０２に要請する。

その後に、ＲＵＩＣ９０１は、ＲＵＩＳ９０２からＲＵＩを受信し、この受信されたＲＵＩをＲＵＩＣ９０１内のブラウザー９０５で実行する。ＲＵＩは、実行される間に、isRCExist methodを通して現在ＲＵＩＣ９０１に接続された第３のＲＵＩＣが存在するか否かをＲＣプラグイン９０４に聞く。

ＲＣプラグイン９０４は、現在接続されている第３のＲＵＩＣが存在するか否かをエンベデッドサーバ９０３に聞く。その後に、エンベデッドサーバ９０３は、接続された第３のＲＵＩＣが存在するか否かをチェックする。

接続された第３のＲＵＩＣ９００が存在すると、エンベデッドサーバ９０３は、性能情報を要請するメッセージを第３のＲＵＩＣ９００に送信する。第３のＲＵＩＣ９００は、ＣＵＩ要請メッセージとともに自身の性能情報をエンベデッドサーバ９０３に送信する。

第３のＲＵＩＣ９００がエンベデッドサーバ９０３にアクセスし、ＨＴＴＰメッセージをエンベデッドサーバ９０３に送信する履歴を有している場合に、エンベデッドサーバ９０３は、その際にＨＴＴＰメッセージのＨＴＴＰヘッダーに設定されたUser-Agent値を内部に記憶する。第３のＲＵＩＣ９００とＲＵＩＣ９０１内に存在するエンベデッドサーバ９０３間の接続が切れる場合に、記憶されたUser-Agent値は削除される。

第３のＲＵＩＣ９００とエンベデッドサーバ９０３間の接続が切れるまで、第３のＲＵＩＣ９００は、エンベデッドサーバ９０３から通知を受信することができる状態にある。

このような状態で、遠隔制御プラグイン９０４から接続された第３のＲＵＩＣ９００が存在するか否かをモニタリングする命令を受信する際に、エンベデッドサーバ９０３は、User-Agent値を有するか否かをチェックする。User-Agent値の存在を感知する場合に、エンベデッドサーバ９０３は、User-Agent値を遠隔制御プラグイン９０４に送信する。

遠隔制御プラグイン９０４は、受信されたUser-Agent値を内部に記憶し、現在接続された第３のＲＵＩＣ９００の存在を示す‘true'値をＲＵＩ９０６に送信する。この‘true'値に対する送信及び第３のＲＵＩＣ９００の性能情報を記憶する順序が変わり得る。

‘true'値を受信する際に、ＲＵＩ９０６は、ＲＵＩ９０６を制御するのに使用するためのＣＵＩを要請するgetCUI命令語を遠隔制御プラグイン９０４に送信する。

遠隔制御プラグイン９０４は、この性能情報のフォーマットをＲＵＩＳ９０２に合うように変形させ、この変形された性能情報をＣＵＩ要請とともにＲＵＩＳ９０２に送信する。その後に、ＣＵＩは、第３のＲＵＩＣ９００への送信のために、エンベデッドサーバ９０３内の適切な位置にダウンロードされる。

一方、本発明の実施形態の実現を簡素にするために、isRCExist methodを呼び出す動作から‘true’値をＲＵＩ９０６に戻る動作までの過程は実行されないこともある。その代わりに、第３のＲＵＩＣ９００がＲＵＩＣ９０１にアクセスし、ＨＴＴＰメッセージを少なくとも１回にＲＵＩＣ９０１に送信する履歴を有する場合に、User-Agent値は、ＲＵＩＣ９０１内に記憶される。ＲＵＩ９０６が遠隔制御プラグイン９０４からgetCUI methodを呼び出す際に、遠隔制御プラグイン９０４は、User-Agent値をそのまま使用するか又はUser-Agent値のフォーマットを変形することによりＲＵＩ９０６に関連したＣＵＩをＲＵＩＳ９０２に要請する。

ＣＵＩダウンロードが完了する際に、遠隔制御プラグイン９０４は、ＣＵＩダウンロードが完了したことを示すonCompleteReceiveCUIイベントをＲＵＩ９０６に送信する。その後に、ＲＵＩ９０６は、遠隔制御プラグイン９０４がＣＵＩを第３のＲＵＩＣ９００に送信するように指示するsendCUI命令語を送信する。

この命令語を受信する際に、遠隔制御プラグイン９０４は、ＣＵＩ送信命令語をエンベデッドサーバ９０３に送信する。その後に、エンベデッドサーバ９０３は、ＣＵＩ又はＣＵＩのＵＲＬを第３のＲＵＩＣ９００に送信する。

ＣＵＩのＵＲＬを受信する場合に、第３のＲＵＩＣ９００は、受信されたＵＲＬ情報を用いて自身の性能にマッチングするＣＵＩを受信し、この受信されたＣＵＩを実行させる。

図１０は、本発明の他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。

図１０を参照すると、ＲＵＩがＲＵＩＣ９０１のブラウザー９０５で実行されつつ、現在接続されている第３のＲＵＩＣ９００が存在するか否かをチェックする。現在接続されている第３のＲＵＩＣ９００が存在しない場合に、ＣＵＩに関連した過程をこれ以上進行しない。

後で第３のＲＵＩＣ９００に関する性能情報を含むＣＵＩ要請メッセージを第３のＲＵＩＣ９００から受信する際に、エンベデッドサーバ９０３は、対応する性能情報を遠隔制御プラグイン９０４に送信する。

遠隔制御プラグイン９０４は、この受信された性能情報を記憶納した後に、ＣＵＩ要請の受信を示すonCUIRequestイベントを現在ブラウザー９０５で実行されているＲＵＩ９０６に送信する。その後に、ＲＵＩ９０６は、ＲＵＩ９０６を制御するためのＣＵＩを要請するgetCUI命令語を遠隔制御プラグイン９０４に送信する。

遠隔制御プラグイン９０４は、第３のＲＵＩＣ９００に関する性能情報のフォーマットをＲＵＩＳ９０２に送信可能なフォーマットに変形させ、この変形された性能情報をＣＵＩダウンロード要請とともにＲＵＩＳ９０２に送信する。その後に、遠隔制御プラグイン９０４は、ＲＵＩＳ９０２からＣＵＩをダウンロードし、内部の適切な位置にＣＵＩを格納する。その後の動作は、図８に示した同一の方法で実行される。

図１１は、本発明の他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。

図１１に示す本発明の実施形態に従って、ＲＵＩＣは、ダウンロード方式でない伝達方式でＣＵＩを第３のＲＵＩＣに送信する。

図１１を参照すると、ＲＵＩ９０６は、遠隔制御プラグイン９０４がＣＵＩをＲＵＩＳ９０２から受信することを要請する。その後に、遠隔制御プラグイン９０４は、ＣＵＩをＲＵＩＳ９０２に要請する。ＲＵＩＳ９０２は、要請されたＣＵＩの内容をＨＴＴＰメッセージのボディーに入れ、ＨＴＴＰメッセージを遠隔制御プラグイン９０４に送信する。

遠隔制御プラグイン９０４は、受信されたＨＴＴＰメッセージからＣＵＩの内容を抽出し、この抽出されたＣＵＩの内容をＲＵＩ９０６に送信する。ＲＵＩ９０６は、遠隔制御プラグイン９０４がＣＵＩの内容をエンベデッドウェブサーバ９０３を通して第３のＲＵＩＣ９００に送信することを命令する。ＣＵＩの内容は、必要に応じてＲＵＩ９０６、遠隔制御プラグイン９０４、又はエンベデッドウェブサーバ９０３により修正され得る。

一方、onCompleteReceivingCUI及びsendCUIのシグナリング１０００は、状況に従って実行される必要がない。例えば、遠隔制御プラグイン９０４がＣＵＩをＲＵＩＳ９０２に要請し、ＲＵＩＳ９０２からの応答を受信する際に、応答内容をＲＵＩ９０６に通知する必要がない場合に、シグナリング１０００は実行されない。この場合に、遠隔制御プラグイン９０４は、ＲＵＩＳ９０２から受信されたＨＴＴＰメッセージから抽出されたＣＵＩの内容をエンベデッドウェブサーバ９０３に送信する。その後に、エンベデッドウェブサーバ９０３は、この受信されたＣＵＩの内容を第３のＲＵＩＣ９００に送信する。

図１２は、本発明の他の実施形態に従ってＲＵＩがＲＵＩＣで既に実行されている際に第３のＲＵＩＣの性能にマッチングするＣＵＩを第３のＲＵＩＣに提供するための信号フローを示す図である。

図１１に示した本発明の実施形態に従って、ＲＵＩＣは、ダウンロード方式でない伝達方式でＣＵＩを第３のＲＵＩＣに送信する。

図１２を参照すると、ＲＵＩがＲＵＩＣ９０１のブラウザー９０５で実行されつつ、現在接続されている第３のＲＵＩＣ９００が存在するか否かをチェックする。現在接続されている第３のＲＵＩＣ９００が存在しない場合に、ＣＵＩに関連した過程をこれ以上進行しない。

遠隔制御プラグイン９０４は、この受信された性能情報を記憶した後に、ＣＵＩ要請の受信を示すonCUIRequestイベントを現在ブラウザー９０５で実行されているＲＵＩ９０６に送信する。その後に、ＲＵＩ９０６は、ＲＵＩ９０６を制御するためのＣＵＩを要請するgetCUI命令語を遠隔制御プラグイン９０４に送信する。

その後に、遠隔制御プラグイン９０４は、ＣＵＩをＲＵＩＳ９０２に要請する。ＲＵＩＳ９０２は、要請されたＣＵＩの内容をＨＴＴＰメッセージのボディーに入れ、ＨＴＴＰメッセージを遠隔制御プラグイン９０４に送信する。

図１３は、本発明の実施形態によるＤＬＮＡ装置で要請されたサービスにマッチングするＣＵＩを送信するための動作に対する信号フローを示す図である。ここで、要請されたサービスは、ＩＰＴＶサービスである。ＩＰＴＶサービスは、オープンＩＰＴＶフォーラム標準に従ってＤＬＮＡ装置（＋ＲＵＩＰＬ＋）を介してＯＩＴＦに要請され得る。

図１３を参照すると、ＤＬＮＡ装置（＋ＲＵＩＰＬ＋）１２００は、予め定義されたユニバーサルリソース識別子（ＵＲＩ）を通してＯＩＴＦ１２０１にＩＰＴＶサービスを要請する。また、ＤＬＮＡ装置（＋ＲＵＩＰＬ＋）１２００は、ＩＰＴＶサービスを要請する際に、サービス要請メッセージとともに自身の性能情報を送信する。

ＤＬＮＡ機能（＋ＲＵＩＳＲＣ＋）１２０３は、性能情報を記憶し、ＤＡＥ（Declarative Application Environment）ブラウザー１２０５が対応するＩＰＴＶサービスにマッチングするＤＡＥアプリケーションをＩＰＴＶアプリケーションサーバ１２０２から受信し、ＤＡＥアプリケーションを実行することを命令する。

この命令に応じて対応するＩＰＴＶサービスにマッチングするＤＡＥアプリケーション１２０６がＤＡＥブラウザー１２０５で実行される際に、ＤＡＥアプリケーション１２０６は、ＣＵＩのＵＲＩとともにgetCUI methodを遠隔制御プラグイン１２０４に提供する。その後に、遠隔制御プラグイン１２０４は、ＤＬＮＡ機能（＋ＲＵＩＳＲＣ＋）１２０３からこの記憶された性能情報を持ってき、ＩＰＴＶアプリケーションサーバ１２０２に送信されることができるように性能情報を処理する。必要であれば、この性能情報は、処理されないこともある。

一方、遠隔制御プラグイン１２０４は、処理された（又は処理されない）性能情報をgetCUI methodで設定されたＵＲＩパラメータを用いてＩＰＴＶアプリケーションサーバ１２０２に送信し、ＩＰＴＶアプリケーションサーバ１２０２からＣＵＩを受信する。ＣＵＩは、２つの方式で受信され得る。

まず、ＣＵＩがダウンロード方式で受信される場合に、遠隔制御プラグイン１２０４は、ＣＵＩを含む圧縮ファイルをＩＰＴＶアプリケーションサーバ１２０２からＤＬＮＡ機能１２０３にダウンロードした後に、このダウンロードされた圧縮ファイルを解除し、onCompleteReceivingCUIイベント関数を用いてこの解除されたディレクトリに対応するＵＲＬの形態でアクセス可能な位置をＤＡＥアプリケーション１２０６に示す。

ＤＡＥアプリケーション１２０６は、この受信されたプレフィックスＵＲＩを内部に記憶されているＣＵＩリストに含まれたＣＵＩの名称に取り付けることにより新たなＵＲＩを生成する。ＤＬＮＡ装置１２００は、この新たなＵＲＩを用いてＯＩＴＦ１２０１のＣＵＩにアクセスすることができる。

新たなＵＲＩは、sendCUI methodを通してＤＬＮＡ装置１２００に送信される。ＤＬＮＡ装置１２００は、対応するＵＲＩを呼び出し、ＯＩＴＦ１２０１内のＤＬＮＡ機能１２０３からＣＵＩを受信する。

一方、ダウンロード方式でない伝達方式でＣＵＩがＩＰＴＶアプリケーションサーバ１２０２から受信される場合に、ＤＡＥアプリケーション１２０６は、ＣＵＩのＨＴＭＬ内容をgetCUI methodを通してＩＰＴＶアプリケーションサーバ１２０２から受信する。ＤＡＥアプリケーション１２０６は、必要に応じて、ＨＴＭＬ内容を修正した後にこの修正されたＨＴＭＬ内容をsendCUI methodを通してＤＬＮＡ装置１２００に送信する。ＨＴＭＬ内容に対する修正が必要でない場合に、ＤＡＥアプリケーション１２０６は、ＨＴＭＬ内容をsendCUI methodを通してＤＬＮＡ装置１２００に送信し得る。

ＤＬＮＡ装置１２００は、ＤＡＥアプリケーション１２０６から受信されたＨＴＭＬ内容を自身の画面上にレンダリングする。

上述したように、ＨＴＭＬ内容は、伝達方式でsendCUIに含まれる一方、ＵＲＩ値は、ダウンロード方式でsendCUIに含まれる。

図１４は、本発明のまた他の実施形態によるオープンＩＰＴＶフォーラム標準に適用可能なＤＬＮＡ装置（＋ＲＵＩＰＬ＋）を通してＯＩＴＦで現在実行されているＩＰＴＶサービスにマッチングするＣＵＩを受信するための信号フローを示す図である。

図１４を参照すると、ＯＩＴＦ１２０１でＩＰＴＶサービスがＤＡＥアプリケーション１２０６により実行されていることを仮定する。このような状態で、ユーザは、現在実行されているＩＰＴＶサービスを制御することができるＣＵＩをＤＬＮＡ装置１２００のＩＴＦ遠隔制御機能（ITF Remote Control Function：ＩＲＣＦ）を用いて予め定義されたＵＲＩを通してＯＩＴＦ１２０１に要請する。この際に、ＤＬＮＡ装置１２００は、ＣＵＩ要請メッセージとともに自身の性能情報をＤＬＮＡ機能１２０３に送信する。この性能情報は、ＤＬＮＡ機能１２０３に記憶される。

ＤＬＮＡ機能１２０３は、ＤＬＮＡ装置１２００からＣＵＩ要請が受信されたことを遠隔制御プラグイン１２０４に通知する。遠隔制御プラグイン１２０４は、onCUIRequestイベント関数を通してＣＵＩ要請が受信されたことをＤＡＥアプリケーション１２０６に通知する。ＤＡＥアプリケーション１２０６は、遠隔制御プラグイン１２０４がgetCUI methodを通してＩＰＴＶアプリケーションサーバ１２０２からＣＵＩを受信することを命令する。ＤＬＮＡ機能１２０３は、ＩＰＴＶアプリケーションサーバ１２０２からＣＵＩを受信するために格納された性能情報を使用する。以後の過程は、図１２に示したものと同一の方式で実行され、具体的な説明は省略する。

図１５は、本発明の実施形態によるオープンＩＰＴＶフォーラム標準のＤＡＥＳＰＥＣに適用可能なアプリケーションプログラミングインターフェース（ＡＰＩ）及びインターフェースを説明する図である。

まず、Property（Event）に関連して、第３のＲＵＩＣが現在ＯＩＴＦで実行されているＤＡＥアプリケーションに対するＣＵＩを要請する場合に、遠隔制御プラグインは、ＤＡＥアプリケーションにonCUIRequestコールバックイベント関数を発生させる。この際に、現在接続されている第３のＲＵＩＣに対する装置調整（Device Handle）値は、ＤＡＥアプリケーションに対するパラメータとして送信される。onCUIRequestコールバックイベント関数がＤＡＥアプリケーションに発生する前に、ＯＩＴＦは、第３のＲＵＩＣからＣＵＩ要請とともに受信された第３のＲＵＩＣに関する性能情報を記憶する。この性能情報は、ＩＰＴＶアプリケーションサーバから第３のＲＵＩＣに表現されることができる適切なＣＵＩを受信するためのgetCUI methodが呼び出される時に使用される。

onCompleteReceivingCUIコールバックイベント関数は、ＤＡＥアプリケーションにより遠隔制御プラグインに発生する。onCompleteReceivingCUIコールバックイベント関数は、getCUI methodによりＣＵＩダウンロードを要請する。ＣＵＩがＩＰＴＶアプリケーションサーバからＯＩＴＦに完全にダウンロードされ、第３のＲＵＩＣへの送信準備が完了する場合に、遠隔制御プラグインは、このダウンロードされたＣＵＩにアクセス可能なＵＲＩのプレフィックス（prefix）値をＤＡＥアプリケーションに送信する。

一方、onCompleteReceivingCUIコールバックイベント関数とともに送信されたパラメータcuiPrefixURIは、第３のＲＵＩＣがこのダウンロードされたＣＵＩを有するディレクトリの位置をＯＩＴＦにアクセスすることができるＵＲＩ（例えば、/cui/playercontroller/001/）として表現される。

ＤＡＥアプリケーションが有しているＣＵＩの名称がfriends_cod_controller.htmlである場合に、cuiPrefixURIの組合せ及びＣＵＩの名称は、第３のＲＵＩＣに送信され得る（例えば、/cui/playercontroller/001/friends_cod_controller.html）。

方法について、第３のＲＵＩＣに関する性能情報が存在する場合に、第３のＲＵＩＣに関する性能情報を遠隔制御プラグインに送信するためのブール（boolean）isRCExist methodがある。この際に、リターン（Return）される値が成功（true）である場合には、第３のＲＵＩＣが現在ＯＩＴＦに接続されており、第３のＲＵＩＣの性能情報がＯＩＴＦの遠隔制御プラグインに成功裡に記憶されることを意味する。

それ以外の場合には、失敗（false）値がＤＡＥアプリケーション（ＲＵＩ）にリターンされる。

isRCExist methodと類似した機能を行うgetConnectedRemoteDeivceHandle方法の場合に、ＤＡＥアプリケーションがこれを呼び出す際に、接続された第３のＲＵＩＣを調整することができる装置調整値を整数（Integer）値として伝達する。接続された第３のＲＵＩＣが存在しない場合には、未定義（undefined）値又はヌル（null）値がリターンされる。

ＤＡＥアプリケーションは、遠隔制御プラグインがgetCUI methodを通してＩＰＴＶアプリケーションサーバからＣＵＩをダウンロードするように命令する。また、ＤＡＥアプリケーションは、ダウンロードするためのＵＲＬをパラメータとして遠隔制御プラグインに送信する。その後に、遠隔制御プラグインは、ＯＩＴＦに記憶された第３のＲＵＩＣに関する性能情報とともにダウンロード要請メッセージをＩＰＴＶアプリケーションサーバに送信する。

getCUI methodは、非同期方式である。ＤＡＥアプリケーションがgetCUI methodを呼び出す場合に、getCUI method実行の成功又は失敗を示す値‘true’又は‘false’が即座にＤＡＥアプリケーションにリターンされる。すなわち、ダウンロードが遠隔制御プラグインとＩＰＴＶアプリケーションサーバ間で実行されているが、ＤＡＥアプリケーションは、getCUI methodを呼び出した直後の過程を実行することができる。一方、遠隔制御プラグインとＩＰＴＶアプリケーションサーバ間のダウンロードが完了すると、上述したonCompleteReceivingCUIイベントは、ＤＡＥアプリケーションに送信される。

ＤＡＥアプリケーションがsendCUI methodを呼び出すことによりアクセスすることができるＣＵＩによるＵＲＩ情報とともに現在ＯＩＴＦに接続されている第３のＲＵＩＣに対する固有の装置調整値を送信する場合に、遠隔制御プラグインは、第１のパラメータとして送信された装置調整値を用いて識別された第３のＲＵＩＣに第２のパラメータであるＣＵＩにアクセスすることができるＵＲＩ情報を送信する。したがって、第３のＲＵＩＣは、ＵＲＩ情報を用いてＯＩＴＦからＣＵＩを持ってくることができる。

ＨＴＴＰは、遠隔制御プラグインとＲＵＩＳ間のインターフェースとしてＯＩＴＦＤＡＥＳＰＥＣに定義されたインターフェースを使用し、性能情報を記録するために指定された位置に第３のＲＵＩＣに関する性能情報を記録する。また、基本的に、第３のＲＵＩＣに関する性能情報以外の情報、すなわち、vendorName、modelName、SoftwareVersion、hardwareVersion、applicationName、及びapplicationVersionをともに記録する。

このような情報（すなわち、第３のＲＵＩＣに関するvendorName、modelName、SoftwareVersion、hardwareVersion、applicationName、及びapplicationversionに関する情報）が第３のＲＵＩＣに関する性能情報とともに送信されることができない場合、例えば、第３のＲＵＩＣがvendorName、modelName、SoftwareVersion、hardwareVersion、applicationName、及びapplicationversion に関する情報を送信しない場合に、この情報は、ＯＩＴＦに関する情報に置き換えられ得る。第３のＲＵＩＣのvendorName、modelName、SoftwareVersion、hardwareVersion、applicationName、及びapplicationversion に関する情報がoptional情報であるので、性能情報に対して指定されたフィールド及び第３のＲＵＩＣに関する他の情報は、この性能情報だけを運搬し得る。一方、図１０の遠隔制御プラグインとＩＰＴＶアプリケーションサーバ間のインターフェースの説明において、［］で表示される第３のＲＵＩＣに関する他の情報は、Optional情報を意味する。

図１６及び図１７は、本発明の実施形態による図１５で説明したＡＰＩに対する属性及び方法を示すもので、これは、オープンＩＰＴＶフォーラム標準のスペックに適用可能である。

図１８は、本発明の実施形態によるオープンＩＰＴＶフォーラム標準のＰＲＯＴＯＣＯＬスペックに適用可能な第３のＲＵＩＣがＯＩＴＦでＩＰＴＶサービスを実現するためのインターフェース及びメッセージを説明する図である。

図９乃至図１２のフローチャートにおいて、第３のＲＵＩＣを通してＩＰＴＶアプリケーションサーバからＯＩＴＦにＲＵＩ（ＩＰＴＶサービス）を送信し、これをＯＩＴＦで実行するためにはプロトコルを必要とする。

図１８は、３つのステップを説明する。まず、ＨＴＴＰ要請メッセージは、第３のＲＵＩＣで表現されるＣＵＩを通してＯＩＴＦに送信される。具体的に、ステップ１において、ＨＴＴＰ要請メッセージは、ＧＥＴ又はＰＯＳＴ方法で設定されたＵＲＩを通して送信され得る。ステップ２において、ＣＵＩは、ＨＴＴＰ要請メッセージに対する応答を受信するまで待機する。ステップ３において、ＯＩＴＦは、新たなＣＵＩのＵＲＩに関する情報を第３のＲＵＩＣに送信する。ＨＴＴＰ応答メッセージのフォーマットは、図１６のステップ３に示す。ＣＵＩに関するＵＲＩ情報は、ＨＴＴＰ応答ボディーに含まれる。

図１９は、本発明の実施形態による第３のＲＵＩＣがＯＩＴＦで現在実行されているＤＡＥアプリケーションを制御するようにＣＵＩに要請するためのインターフェース及びメッセージを説明するもので、これは、オープンＩＰＴＶフォーラム標準のＰＲＯＴＯＣＯＬスペックに適用可能である。

図１９は、３つのステップを説明する。まず、第３のＲＵＩＣは、第３のＲＵＩＣで表現されるＣＵＩを通して現在ＯＩＴＦで実行されているＤＡＥアプリケーションを制御するためのＣＵＩを要請するＨＴＴＰ要請メッセージを送信する。具体的に、ステップ１において、ＨＴＴＰ要請メッセージは、ＧＥＴ方法で設定されたＵＲＩを通して送信され得る。ステップ２において、ＣＵＩは、ＨＴＴＰ要請メッセージに対する応答を受信するまで待機する。ステップ３において、ＯＩＴＦは、要請されたＣＵＩのＵＲＩに関する情報を第３のＲＵＩＣに送信する。ＨＴＴＰ応答メッセージのフォーマットは、図１７のステップ３に示す。ＣＵＩに関するＵＲＩ情報は、ＨＴＴＰ応答ボディーに含まれる。

本発明の実施形態は、コンピュータ読み取り可能な記録媒体上でコンピュータ読み取り可能なコードとして実現することもできる。コンピュータ読み取り可能な記録媒体は、コンピュータシステムにより読み出すことができるデータを記憶することができる任意のデータ記憶装置である。コンピュータ読み取り可能な記録媒体の例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光学データ記憶装置、及び搬送波（有線又は無線送信経路上のインターネットを介したデータ送信のような）が含まれるが、これらに限定されるものではない。また、上記コンピュータ読み取り可能な記録媒体は、コンピュータ読み取り可能なコードが配布される方式で記憶されて実行されるように、ネットワーク結合型コンピュータシステムを介して配布することができる。更に、本発明を遂行するための関数プログラム、コード及びコードセグメントは、本発明が属する技術分野で熟練したプログラマーにより本発明の範囲内で容易に解析することができるであろう。

以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。

１２００ＤＬＮＡ装置（＋ＲＵＩＰＬ＋）
１２０１ＯＩＴＦ１２０１
１２０２ＩＰＴＶアプリケーションサーバ
１２０３ＤＬＮＡ機能（＋ＲＵＩＳＲＣ＋）
１２０４遠隔制御プラグイン
１２０５ＤＡＥ（Declarative Application Environment）ブラウザー
１２０６ＤＡＥアプリケーション

Claims

近距離ネットワークシステムにおけるアプリケーション実行装置による遠隔制御方法であって、
所定の制御ユーザインターフェース（ＣＵＩ）を用いて前記アプリケーション実行装置を遠隔制御する遠隔装置から前記遠隔装置の性能に関する情報を収集するステップと、
実行中であるアプリケーションを遠隔制御するために使用されるＣＵＩを要請するＣＵＩ要請を前記遠隔装置の性能に関する情報とともにアプリケーションサーバに送信するステップと、
前記ＣＵＩ要請に応じて前記遠隔装置の性能にマッチングするＣＵＩを前記アプリケーションサーバから受信するステップと、
前記受信されたＣＵＩを前記遠隔装置に送信するステップとを有し、
前記実行中であるアプリケーションは、前記アプリケーション実行装置が前記遠隔装置を発見する前または前記遠隔装置を発見した後に実行され、
前記実行中であるアプリケーションが、前記アプリケーション実行装置が前記遠隔装置を発見した後に実行された場合、前記アプリケーションサーバから前記実行中であるアプリケーションに対応するアプリケーションを要請して獲得し、前記獲得したアプリケーションを実行させた後、前記ＣＵＩ要請を送信する
ことを特徴とする遠隔制御方法。
前記アプリケーションが前記遠隔装置を発見する前に実行された場合、前記収集するステップは、前記遠隔装置からのＣＵＩ要請とともに前記遠隔装置の性能に関する情報を受信するステップを具備する
ことを特徴とする請求項１に記載の遠隔制御方法。
前記アプリケーションが前記遠隔装置を発見した後に実行された場合、前記収集するステップは、前記遠隔装置からの所定のアプリケーションサービス要請とともに前記遠隔装置の性能に関する情報を受信するステップを具備する
ことを特徴とする請求項１に記載の遠隔制御方法。
近距離ネットワークシステムにおける遠隔制御を実行するアプリケーション実行装置であって、
所定の制御ユーザインターフェース（ＣＵＩ）を用いて前記アプリケーション実行装置を遠隔制御する遠隔装置から、前記遠隔装置の性能に関する情報を収集する第１のエンティティーと、
実行中であるアプリケーションを遠隔制御するために使用されるＣＵＩを要請するＣＵＩ要請を前記遠隔装置の性能に関する情報とともにアプリケーションサーバに送信し、前記ＣＵＩ要請に応じて前記アプリケーションサーバから前記遠隔装置の性能にマッチングするＣＵＩを受信する第２のエンティティーと、を有し、
前記第１のエンティティーは、ＣＵＩを前記遠隔装置に送信するように前記第２のエンティティーを制御し、
前記実行中であるアプリケーションは、前記アプリケーション実行装置が前記遠隔装置を発見する前または前記遠隔装置を発見した後に実行され、
前記実行中であるアプリケーションが、前記アプリケーション実行装置が前記遠隔装置を発見した後に実行された場合、前記第１のエンティティー及び前記第２のエンティティーを通じて前記アプリケーションサーバから前記実行中であるアプリケーションに対応するアプリケーションを要請して獲得し、前記獲得したアプリケーションを実行させた後、前記第１のエンティティーは、前記ＣＵＩ要請を送信するように前記第２のエンティティーを制御する
ことを特徴とするアプリケーション実行装置。
前記第１のエンティティーは、前記アプリケーションが前記遠隔装置を発見する前に実行された場合、前記遠隔装置の性能に関する情報を前記遠隔装置からのＣＵＩ要請とともに受信する
ことを特徴とする請求項４に記載のアプリケーション実行装置。
前記第１のエンティティーは、前記アプリケーションが前記遠隔装置を発見した後に実行された場合、前記遠隔装置の性能に関する情報を前記遠隔装置からの所定のアプリケーションサービス要請とともに受信する
ことを特徴とする請求項４に記載のアプリケーション実行装置。
近距離ネットワークシステムにおける遠隔装置によりアプリケーション実行装置を遠隔制御する方法であって、
前記遠隔装置の性能に関する情報を前記アプリケーション実行装置に送信するステップと、
前記遠隔装置の性能にマッチングする制御ユーザインターフェース（ＣＵＩ）を前記アプリケーション実行装置から受信するステップと、
前記受信されたＣＵＩを用いて前記アプリケーション実行装置で実行中であるアプリケーションを遠隔制御するステップとを有し、
前記ＣＵＩは前記アプリケーション実行装置で前記実行中であるアプリケーションを遠隔制御するために用いられ、前記実行中であるアプリケーションは、前記アプリケーション実行装置が前記遠隔装置を発見する前または前記遠隔装置を発見した後に実行され、
前記実行中であるアプリケーションが、前記アプリケーション実行装置が前記遠隔装置を発見した後に実行された場合、前記ＣＵＩは、前記アプリケーション実行装置がアプリケーションサーバから前記実行中であるアプリケーションに対応するアプリケーションを要請して獲得し、前記獲得したアプリケーションを実行させた後、前記ＣＵＩ要請を前記アプリケーションサーバに送信して獲得したものである
ことを特徴とする遠隔制御方法。
前記送信するステップは、前記アプリケーション実行装置が前記アプリケーションを実行する前に前記遠隔装置の性能に関する情報をＣＵＩ要請とともに前記アプリケーション実行装置に送信するステップを有する
ことを特徴とする請求項７に記載の遠隔制御方法。
前記送信するステップは、前記アプリケーション実行装置が前記アプリケーションを実行した後に前記遠隔装置の性能に関する情報を所定のアプリケーションサービス要請とともに前記アプリケーション実行装置に送信するステップを有する
ことを特徴とする請求項７に記載の遠隔制御方法。
近距離ネットワークシステムにおけるアプリケーション実行装置を遠隔制御する遠隔装置であって、
前記遠隔装置の性能に関する情報を前記アプリケーション実行装置に送信し、前記遠隔装置の性能にマッチングする制御ユーザインターフェース（ＣＵＩ）を前記アプリケーション実行装置から受信する送受信部と、
前記受信されたＣＵＩを用いて前記アプリケーション実行装置で実行されているアプリケーションを遠隔制御する制御部と、を有し、
前記ＣＵＩは、前記アプリケーション実行装置で前記実行中であるアプリケーションを遠隔制御するために用いられ、前記実行中であるアプリケーションは、前記アプリケーション実行装置が前記遠隔装置を発見する前または前記遠隔装置を発見した後に実行され、
前記実行中であるアプリケーションが、前記アプリケーション実行装置が前記遠隔装置を発見した後に実行された場合、前記ＣＵＩは、前記アプリケーション実行装置がアプリケーションサーバから前記実行中であるアプリケーションに対応するアプリケーションを要請して獲得し、前記獲得したアプリケーションを実行させた後、前記ＣＵＩ要請を前記アプリケーションサーバに送信して獲得したものである
ことを特徴とするアプリケーション実行装置と遠隔装置とアプリケーションサーバからなるシステム。
前記送受信部は、前記アプリケーション実行装置が前記アプリケーションを実行する前に前記遠隔装置の性能に関する情報を制御ユーザインターフェース（ＣＵＩ）要請と共に前記アプリケーション実行装置に送信する
ことを特徴とする請求項１０に記載のアプリケーション実行装置と遠隔装置とアプリケーションサーバからなるシステム。
前記送受信部は、前記アプリケーション実行装置が前記アプリケーションを実行した後に前記遠隔装置の性能に関する情報を所定のアプリケーションサービス要請とともに前記アプリケーション実行装置に送信する
ことを特徴とする請求項１０に記載のアプリケーション実行装置と遠隔装置とアプリケーションサーバからなるシステム。