JP5916822B2

JP5916822B2 - リモートユーザインターフェースサーバとリモートユーザインターフェースクライアントとの間のインターフェースのための装置及び方法

Info

Publication number: JP5916822B2
Application number: JP2014186107A
Authority: JP
Inventors: ヨン−ワン・ソ; ヨン−スン・リュ; ジェ−ヨン・ソン
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2009-10-09
Filing date: 2014-09-12
Publication date: 2016-05-11
Anticipated expiration: 2030-10-07
Also published as: US8769415B2; US20110060999A1; CN102549968B; EP2486695A2; CN102549968A; EP2486695A4; WO2011043606A3; KR101612553B1; WO2011043606A2; KR20110039148A; JP2013506929A; JP2015018568A

Description

本発明は、インターネットプロトコル(Internet Protocol：ＩＰ)基盤のホームネットワーキング(Home Networking)に関し、特に、遠隔ユーザインターフェースサーバ(Remote User Interface Server:ＲＵＩＳ)からサービスを直接受信することができないユーザインターフェースクライアント(Remote User Interface Client:ＲＵＩＣ)に遠隔ユーザインターフェース(Remote User Interface)を提供するための方法及び装置に関する。

一般的に、ホームネットワークは、ＩＰ基盤の私設網(Private network)でなされるもので、家庭内で使用される全ての形態のデバイス、例えば、個人コンピュータ(ＰＣ)と知能型製品、無線装置などの多様なデバイスを、ミドルウェアー(middleware)と呼ばれる共通の仮想コンピュータ環境を通じて一つのネットワークで接続して制御するものである。

ミドルウェアーとは、多様なデジタル機器をピアツーピア(peer-to-peer)方式で接続して機器ら間の通信が可能であるようにすることで、ＤＬＮＡ(Digital Living Network Alliance)、ＨＡＶＩ(Home AV Interoperability)、ＵＰｎＰ(Universal Plug and Play)、Ｊｉｎｉ(Java（登録商標） Intelligent Network Infrastructure)、ＨＷＷ(Home Wide Web)などのような多くの産業標準団体により、ホームネットワーク技術の向上のために現在まで活発に研究されている。

ホームネットワークにおいて、遠隔ＵＩ(Remote UI:ＲＵＩ)技術は、一つのデバイスが他のデバイスの機能又は性能を制御するために使用されることができる。簡単に説明すると、ＲＵＩ技術は、クライアント−サーバアーキテクチャに基づくもので、ＲＵＩＣがＲＵＩＳからＵＩを獲得して、ユーザがＲＵＩＣでＵＩを通してＲＵＩＳを制御できる技術である。

このようなＲＵＩ技術は、アプリケーションを制御するためのユーザインターフェースを、このアプリケーションを駆動するデバイスでない他のデバイス上で、レンダリング及び制御するようにするメカニズムであり、ＣＥＡ−２０１４、ＸＨＴ(eXpandable Home Theater)、ＷｉＤｅＸ(Widget Description Exchange Service)、ＲＰＤ(Remote Desktop Protocol)などの多様なＲＵＩ技術が研究されている。

以下で、物理的に離れている装置を制御するためのＲＵＩ技術のうち、代表的な米国家電協会(Consumer Electronics Association:ＣＥＡ)−２０１４に対して説明する。ＣＥＡ−２０１４技術を構成している遠隔制御システムは、遠隔制御のためのユーザインターフェース(ＵＩ)を提供する遠隔ユーザインターフェースサーバ(ＲＵＩＳ)、遠隔で受信されたユーザインターフェースをディスプレーするための遠隔ユーザインターフェースクライアント(ＲＵＩＣ)を含む。

遠隔制御のためのＵＩを提供するＲＵＩＳは、その内部にウェブサーバを有している。このウェブサーバを通してＲＵＩＳはＲＵＩＣが要求するウェブページ(Webpage)を伝送し、ＲＵＩＣはＸＨＴＭＬブラウザーを通して該当ＵＩのウェブページをユーザにディスプレーする。

このようなＲＵＩ技術を用いると、ＲＵＩＣはＲＵＩＳとセッションをセットアップし、ＲＵＩＳからＵＩコンポーネント(component)を受信してＲＵＩＳを制御できるようになる。ここで、ＵＩコンポーネントはＵＩを構成する要素を示し、アイコン、プルダウンメニュー、ボタン、スクロールバー、ウィンドウズ（登録商標）、テキスト、Ａ／Ｖデータ(オーディオ／ビデオ、写真など)など、ＲＵＩＳからＲＵＩＣにＲＵＩセッション上で提供される全ての形式のデータを総称する概念である。

図１は、ＲＵＩＳ１００が提供するリモートＵＩページとコントロール情報を利用して、二つのクライアントデバイス(ＲＵＩＣ１、ＲＵＩＣ２)がコンテンツにアクセスする一般的な例を示す。ＲＵＩＣ(Remote User Interface Client)１１０１は、ＲＵＩＳ１００からリモートＵＩ(ＲＵＩ)ページとコンテンツを直接受信することができるが、もう一つのＲＵＩＣ２１０２は、参照番号１０３に示したようにＲＵＩＳ１００からサービスを直接受信することができない。

このような場合は、ＲＵＩＣ２１０２が物理的にＲＵＩＳ１００との直接接続が不可能な位置にあるか、接続が可能であっても、リモートＵＩページ及びコンテンツをＲＵＩＳ１００から直接受信することができる権限がない場合など、多様な理由によって起こり得る。このような環境では、リモートＵＩの使用が非常に制限的であるが、ＲＵＩＳ１００と接続可能な周辺の他の３Ｇ端末機やデバイスなどを活用すれば、ＲＵＩＣ２１０２にもリモートＵＩサービスを提供することができる。

また、移動通信端末機だけでなく、デジタルＴＶ(ＤＴＶ)、ＰＭＰ（Portable Media Player)、コンピュータなど、多様な能力を有したデバイスが混在され、ユーザにサービスを提供するコンバージェンス(Convergence)環境では、リモートＵＩをサポートする機器であっても、デバイス別に相異なる種類の物理チャンネルインターフェースを有する問題がある。例えば、ＴＶにはＷｉＦｉ(Wireless Fidelity)無線ランインターフェースが装着されているが、宅内の他の全てのデバイスはブルートゥースインターフェースだけを有しており、これを通じてリモートＵＩをサポートする場合、現在としてはＴＶにリモートＵＩサービスを提供できる方法はない。この時、ブルートゥースとＷｉＦｉインターフェースを同時に有した多重インターフェース(Multiple Interface)デバイスが、上記デバイスの代わりにリモートＵＩサービスを提供できれば、コンバージェンス環境でより有利であり得る。

このように、ＲＵＩＳとＲＵＩＣとの間に直接接続が可能な場合のみにリモートＵＩサービスを提供する従来の方法は、上述したような多様な問題点を有している。このようなリモートＵＩ提供方法の限界を越えるためには、ＲＵＩＳ１００から直接サービス受信が可能なＲＵＩＣ１１０１を活用して、サービス受信が不可能なＲＵＩＣ２１０２、又は第３のＲＵＩＣにリモートＵＩページ及びコンテンツを提供するための方案が必要である。

国際公開第２００９／１０４９０８号

したがって、本発明の目的は、ＲＵＩＳからリモートＵＩページ及びコンテンツの直接受信が可能なＲＵＩＣデバイスを通して、前記ＲＵＩＳと直接接続が不可能なＲＵＩＣデバイスにリモートＵＩページ及びコンテンツを提供するための方法及び装置を提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、リモートユーザインターフェースサーバ(ＲＵＩＳ)からＵＩコンポーネントを直接受信することができる第１のリモートユーザインターフェースクライアント(第１のＲＵＩＣ)で、上記ＲＵＩＳから直接受信することができない第２のＲＵＩＣに上記ＵＩコンポーネントを提供する方法を提供する。上記方法において、第１のＲＵＩＣは、上記ＵＩコンポーネントを受信する第２のＲＵＩＣを発見する。第２のＲＵＩＣを発見すると、第１のＲＵＩＣは、上記ＲＵＩＳと上記第２のＲＵＩＣとの間のデバイス能力マッチング手順を遂行する。上記デバイス能力マッチング手順の遂行が完了すると、第１のＲＵＩＣは、上記ＲＵＩＳから受信された上記第２のＲＵＩＣ向けに加工されたＵＩコンポーネントを上記第２のＲＵＩＣに提供し、上記第２のＲＵＩＣから上記ＵＩコンポーネントに対する制御情報を上記ＲＵＩＳに伝達する。

本発明の他の一態様によれば、リモートユーザインターフェースサーバ(ＲＵＩＳ)からＵＩコンポーネントを直接受信することができない第２のリモートユーザインターフェースクライアント(第２のＲＵＩＣ)に、上記ＵＩコンポーネントを提供するための第１のリモートユーザインターフェースクライアント(第１のＲＵＩＣ)装置を提供する。上記装置において、ＵＩ制御モジュールは、ＵＩコンポーネントを受信する上記第２のＲＵＩＣを発見すると、上記ＲＵＩＳと上記第２のＲＵＩＣとの間のデバイス能力マッチング手順を遂行する。リモートＵＩページ管理部は上記ＲＵＩＳからＵＩコンポーネントを受信し、上記デバイス能力マッチング手順の遂行が完了すると、上記ＲＵＩＳから受信された上記第２のＲＵＩＣ向けに加工されたＵＩコンポーネントを上記第２のＲＵＩＣに伝達する。メッセージ中継部は上記第２のＲＵＩＣから上記ＵＩコンポーネントに対する制御メッセージを上記ＲＵＩＳに伝達する。

本発明によれば、ＲＵＩＳからサービスを直接受信することができない第３のＲＵＩＣに、第３のＲＵＩＣ周辺のプロキシＲＵＩＣを活用してサービスを提供することができる。このようにしてＲＵＩＣのユーザは、物理的な伝送チャンネル環境の限界や、相異なる物理階層インターフェースの使用によって第３のＲＵＩＣへのサービス提供が不可能な場合、また接続が可能であってもリモートＵＩページ及びコンテンツを第３のＲＵＩＣが上記ＲＵＩＳから直接受信することができる権限がない場合など、サービス提供環境の限界を克服し、いつでもどこでもリモートＵＩページ及びコンテンツにアクセスすることができる。

以下、本開示及びその利点についてのより完全な理解を助けるため、添付の図面を参照しながら、本発明の実施形態について詳細に説明する。

ＲＵＩＳ(Remote User Interface Server)がＲＵＩＣ１と第３のＲＵＩＣにリモートＵＩページ及びコンテンツを伝送する一般的な例を示す図である。本発明の実施形態によって、プロキシＲＵＩデバイスを介して第３のＲＵＩＣデバイスがレンダリングするようにリモートＵＩページ及びコンテンツを伝送することを示す図である。本発明の実施形態によって、第３のＲＵＩＣデバイスにリモートＵＩページ及びコンテンツを伝達するために必要なプロトコルと手順を定義する図である。本発明の実施形態によって、プロキシＲＵＩＣと第３のＲＵＩＣデバイスがお互いを発見する方法を示す図である。本発明の実施形態によって、ＲＵＩＳ５００とＲＵＩＣ２５０２との間でリモートＵＩ及びコンテンツを提供するＲＵＩＣ１５１０のブロック構成図である。本発明の実施形態によるリモートＵＩページ管理部のブロック構成図である。本発明の実施形態によるＲＵＩＣ１でＲＵＩＳとＲＵＩＣ２との間のインターフェーシングのための動作を示すフローチャートである。本発明の実施形態によってＲＵＩＣ１ではリモートＵＩページのみにアクセスされ、ＲＵＩＣ２ではコンテンツのみにアクセスされる場合を示す図である。本発明の実施形態によってＲＵＩＣ２でリモートＵＩページ及びコンテンツが共にアクセスされる場合の実施形態を示す図である。

以下、本発明の好適な実施形態を、添付の図面を参照しつつ詳細に説明する。なお、下記の説明における具体的な特定事項は、本発明のより全般的な理解を助けるために提供されたもので、これら特定事項によって本発明が限定されるものではないことは、当該技術分野における通常の知識を持つ者にとっては明らかであるだろう。

図２は、本発明の実施形態によって、ＲＵＩＳ２００で提供されるリモートＵＩページ及び／またはコンテンツをプロキシＲＵＩデバイスであるＲＵＩＣ１２０１を介して、第３のＲＵＩＣデバイスであるＲＵＩＣ２２０２に提供することを示す図である。ここで、プロキシＲＵＩデバイスは、ＲＵＩＣ１２０１がＲＵＩＣ２２０２の代わりにＲＵＩＳ２００と通信を遂行することにより、ＲＵＩＣ１２０１をプロキシＲＵＩデバイスとも称する。

図２に示されたように、ＲＵＩＣ２２０２がＲＵＩＳ２００に直接接続が不可能な場合、ＲＵＩＳ２００は、参照番号２０４に示したように、通信を遂行できないＲＵＩＣ２２０２に伝達されるべきリモートＵＩページ及び／またはコンテンツを、ＲＵＩＣ１２０１を介してＲＵＩＣ２２０２に遠隔で伝送する。このリモートＵＩページ及びコンテンツは、ＲＵＩＣ１２０１を介してさらに第３のデバイスであるＲＵＩＣ２２０２に伝送され、ＲＵＩＣ２２０２の画面にはＲＵＩＳ２００から受信された該当リモートＵＩページ及びコンテンツがディスプレーされる。このためにＲＵＩＣ１２０１を介してコンテンツを消費していたユーザは、まずコンテンツあるいはリモートＵＩを提供するＲＵＩＣ２２０２を検索して選択し、ＲＵＩＣ２２０２に提供するコンテンツあるいはＵＩページを選択すると、選択されたコンテンツまたはリモートＵＩがＲＵＩＣ２２０２に伝達される。

図３は、本発明の実施形態によってＲＵＩＣ１３０１を通してＲＵＩＳと通信を遂行できない第３のデバイスであるＲＵＩＣ２３０２に、リモートＵＩページ又はコンテンツを提供するために必要なプロトコル３０４及び手順３０５と、ＲＵＩＣ１でこれを担当する運営モジュール３０６を示す図である。ＲＵＩＣ１３０１はＣＥＡ−２０１４のような既存のプロトコル３０３を通して、ＲＵＩＳ３００からリモートＵＩページ及びコンテンツを受信する。しかしながら、プロキシＲＵＩＣ１３０１が第３のＲＵＩＣデバイスであるＲＵＩＣ２３０２にリモートＵＩページ及びコンテンツを提供するためには、ＲＵＩＣ３０１と３０２との間にリモートＵＩページ及びコンテンツを伝達できる新たなプロトコル３０４が定義されるべきであり、本発明によって、新たなプロトコル３０４に定義されるべき内容は次の通りである。

第１に、ＲＵＩＣ１３０１が第３のＲＵＩＣデバイスであるＲＵＩＣ２３０２を発見するデバイス発見過程(Device Discovery process)が必要である。第２に、ＲＵＩＣ２３０２が発見された後には、リモートＵＩページ及びコンテンツをＲＵＩＳ３００から獲得するために必要な情報をＲＵＩＣ２３０２から獲得して比較するデバイス能力マッチング過程(Device Capability Matching process)が必要である。第３に、ＲＵＩＣ２３０２がリモートＵＩページ及びコンテンツをレンダーすることができることまで認識されると、ＲＵＩＣ１３０１がＲＵＩＣ２３０２にリモートＵＩページ及びコンテンツを伝達するＲＵＩページ伝達過程(URI Page Transfer process)が必要である。第４に、ＲＵＩＣ２３０２がＲＵＩＣ１３０１からリモートＵＩを受信すると、ＲＵＩＣ２３０２がＲＵＩＣ１３０１から受信されたＲＵＩページをレンダリングした後、ＲＵＩＣ１３０１を通して制御メッセージを伝送する制御メッセージ伝達過程(Control Message Transfer process)が必要である。

以下では、ＲＵＩＣ１３０１でこのような過程を遂行するための手順に対して説明する。
図４は、本発明の実施形態によって、リモートＵＩページ及びコンテンツをＲＵＩＣ２４０２に提供するために、ＲＵＩＣ１４０１とＲＵＩＣ２４０２がお互いを発見(Discovery)する方法を示す図である。この時、ＲＵＩＣ１４０１とＲＵＩＣ２４０２がお互いを発見する方法は、本発明の実施形態ではプールモード(PULL mode)とプッシュモード(Push mode)の、二つの相異なる方法が存在する。

先ず、プッシュモード４０３は、ＲＵＩＣ１４０１がＲＵＩＣ２４０２を発見する方法である。プッシュモードとは、例えば、ＲＵＩＣ１４０１のユーザがＲＵＩＳ４００から受信された動映像コンテンツを見ているうちに、画面大きさがより大きい周辺の第３の機器であるＲＵＩＣ２４０２を利用してコンテンツを見ようとする場合がこれに該当する。

この時、ＵＩＣＰ１(User Interface Control Point１)４０５は、ＲＵＩＣ１４０１を制御するＵＩＣＰとして利用されるので、ＲＵＩＣ１４０１がＲＵＩＣ２４０２を発見する手順が遂行されるべきである。
ここでは、ＲＵＩＣ１４０１が周辺に存在する全ての第３のＲＵＩＣ２を発見し、発見されたＲＵＩＣ２４０２がメタデータ(Metadata)を通してコンテンツ受信が可能なデバイスであるか否かを判別する。このメタデータは、デバイスデスクリプション(Device Description)データあるいは能力デスクリプション(Capability Description)データを含むことができ、発見されたＲＵＩＣ２４０２がＲＵＩＳ４００から伝達されたコンテンツを受信することができるか否かをＲＵＩＣ１４０１が判別できる値を有している。

＜表１＞は、本発明の実施形態によってデバイスデスクリプションメタデータに所定フラグ(flag)を追加する例を示す。このフラグは、ＲＵＩＣ２４０２がコンテンツ受信が可能なデバイスであるか否かをＲＵＩＣ１４０１が把握するようにするために使用される。＜表１＞はデバイスデスクリプションメタデータをＸＭＬ文書で作成した例である。＜表１＞で、太い斜体で表示された部分が本発明の実施形態によって追加されたフラグに該当し、＜表１＞のデータは、図８のステップ８０６及び図９のステップ９０６でデバイスデスクリプションを通して伝達される。ＲＵＩＣ１４０１はリモートＵＩページ及びコンテンツを受信することを望むか、あるいは受信する能力があるＲＵＩＣ２４０２だけを選択して該当フラグを利用し、上記フラグはＲＵＩＣ２４０２を使用するユーザの選好度や決定などにより設定され得る。ＲＵＩＣ１４０１は、発見されたＲＵＩＣ２４０２のメタデータに基づいて、このＲＵＩＣ２４０２がコンテンツ消費が可能なデバイスであるか否かを把握した後、使用可能なデバイスであれば、リモートＵＩページ及びコンテンツを伝送できるかを確認するためのデバイス能力マッチング手順に入る。

デバイス能力マッチング(capability matching)手順は、ＲＵＩＣ１４０１のＵＩＣＰ１４０５が遂行する。しかしながら、説明の便宜上、ＲＵＩＣ１４０１が遂行することと説明する。ＲＵＩＣ１４０１のＵＩＣＰ１４０５がＲＵＩＳ４００とＲＵＩＣ２４０２のデバイスデスクリプションを全部受信した後、二つのデバイスデスクリプションを比較して、ＲＵＩＳ４００が提供する多様なＲＵＩページのうち、ＲＵＩＣ２４０２が受信し得るＲＵＩを判断する。以後、ＲＵＩＣ１４０１は、特定されない方式でＲＵＩＣ２４０２に伝達されるべきＲＵＩページを提供することをＲＵＩＳ４００に要請するようになる。この要請メッセージにＲＵＩＣ２のデバイス能力に関する情報がＲＵＩページ要請と共に伝送される。

要するに、本発明の実施形態で、デバイス能力マッチング手順は、ＲＵＩＣ１４０１がＲＵＩＳ４００とＲＵＩＣ２４０２それぞれに対するデバイスデスクリプションからデバイス能力に関する情報を獲得する段階と、獲得されたデバイスデスクリプション情報をお互い比較する段階と、ＲＵＩＣ２４０２がＲＵＩＳ４００が提供するサービスのうち受信し得るサービスを判断する段階と、ＲＵＩＣ１４０１がＵＩページ要請と共に、ＲＵＩＣ１４０１のプロファイルとＲＵＩＣ２４０２のプロファイルをＲＵＩＳ４００に伝達する段階と、を含む。

＜表１＞のように、ＲＵＩＣ２４０２は、<rui:ProxyAvailability>のフラグを“Ｔｒｕｅ”で設定してＲＵＩＣ１４０１に伝送すると、ＲＵＩＣ２４０２がＲＵＩＣ１４０１から伝達されたＵＩコンポーネントを受信できるデバイスであることをＲＵＩＣ１４０１が判断できるようになる。
もう一つの方法で、ＲＵＩＣ１４０１は、ＲＵＩＣ１４０１を用いてコンテンツにアクセスすることを望む第３のＲＵＩＣであるＲＵＩＣ２４０２だけを検索することを示す情報を含む発見メッセージをＲＵＩＣ２４０２に伝送する。例えば、ＵＰｎＰ発見メッセージでＳＴ(Search Target)フィールドにＲＵＩＣデバイスだけを検索することを示すターゲット情報(“ST:urn:schemas-upnp-org:device:RemoteUIClientDevice:1”)を挿入し、この検索されたＲＵＩＣうちでＲＵＩＣ１４０１を通して、コンテンツにアクセスできるＲＵＩＣ２４０２だけがＵＰｎＰ発見メッセージに応答するように状態情報を＜表２＞で太い斜体のように設定して伝送し得る。

すると、ＲＵＩＣ１４０１が伝達するコンテンツまたはリモートＵＩページを受信することを望むＲＵＩＣ２４０２のみが、この要請に対する応答メッセージをＲＵＩＣ１４０１に伝送する。この応答メッセージを受信したＲＵＩＣ１４０１は、該当応答メッセージを伝達したＲＵＩＣ２４０２に対するデバイスデスクリプションを分析した後、デバイス能力デスクリプションを分析するデバイス能力マッチング過程に入る。上述したように、上記デバイス能力マッチング過程は、ＲＵＩＣ１４０１により発見されたＲＵＩＣ２４０２がコンテンツまたはリモートＵＩページを正しく受信し、アクセスできるか否かを把握するための過程である。

＜表２＞は、本発明の実施形態によるリモートＵＩページまたはコンテンツを受信することができるＲＵＩＣ２４０２のみがＵＰｎＰ発見メッセージに応答するように、ＲＵＩＣ２４０２が有すべき状態情報を、太い斜体のようにＵＰｎＰ発見メッセージに追加した場合の実施形態である。＜表２＞のデータは、後述する図８のステップ８０５及び図９のステップ９０５を通じて伝達される。

ＰＵＬＬモード４０４は、ＲＵＩＣ２４０２がＲＵＩＣ１４０１を発見する方法である。例えば、ＲＵＩＣ２４０２を利用しているうちに、特定サービスを受信しようとするユーザが、ＲＵＩＳ４００から直接サービスを受信することができないことを認知した場合がこれに該当する。この時、ＵＩＣＰ２４０６はＲＵＩＣ２４０２を制御するＵＩＣＰとして使用され、周辺でプロキシＲＵＩＣとして使用できるＲＵＩＣ１４０１が存在するか否かを判断するための手順を遂行する。ここでは、ＲＵＩＣ１４０１がプロキシＲＵＩＣとして動作できるか否かをＲＵＩＣ２４０２に通知するための情報がデバイスデスクリプションに記述されなければならない。

＜表３＞及び＜表４＞は、本発明の実施形態によって、ＸＭＬ言語で具現されたデバイスデスクリプションに、ＲＵＩＣ１４０１がプロキシＲＵＩをサポートするか否かを示す所定情報を追加する実施形態である。本発明の実施形態によれば、ＲＵＩＣ１４０１は、＜表３＞及び＜表４＞の情報を生成してＲＵＩＣ２４０２に伝送する。＜表３＞では太い斜体で表示されたように新たなデバイスタイプである‘プロキシＲＵＩデバイス(ProxyRUIDevice)’を定義し、これを通じてＲＵＩＣ２４０２がプロキシＲＵＩとして動作するＲＵＩＣ１４０１を発見できるようにする。＜表４＞は、新たなデバイスタイプを定義したことでなく、太い斜体で表示されたように、デバイスデスクリプションで定義されたクライアント情報(Client Information)にＲＵＩＣ１４０１がプロキシＲＵＩをサポートするか否かを示す別途のタグが記述された場合の例である。＜表３＞または＜表４＞を用いて、ＲＵＩＣ１４０１は、ＲＵＩＣ２４０２に“ＲＵＩＣ１４０１がプロキシとして利用できるデバイスである”ことを知らせ、＜表３＞または＜表４＞のデータを受信したＲＵＩＣ２４０２は、自身がプロキシとして使用する他のデバイスが存在することが分かる。＜表３＞または＜表４＞を受信した以後、ＲＵＩＣ２４０２は自身が受信することができるサービスリストをＲＵＩＣ１４０１から受信する手順を遂行するようになるが、これに対する細部方法は後述する。

図５は、本発明の実施形態によって、ＲＵＩＳ５００とＲＵＩＣ２５０２との間でリモートＵＩ及びコンテンツを提供するＲＵＩＣ１５１０のブロック構成図である。

利用可能なサービスリスト(Available Service List、以下、ＡＳＬと称する。)伝送部５１６は、ＲＵＩＣ１５１０がＲＵＩＣ２５０２の代わりにプロキシＲＵＩとして動作するデバイスであることを知らせる所定情報をＲＵＩＣ２５０２に伝達し、また、現在提供可能なサービスリストに関する情報をＲＵＩＣ２５０２に伝達する。

＜表５＞、＜表６＞、そして＜表７＞は、ＲＵＩＣ１５１０を通して提供可能なサービスリスト(Available Service List)をＲＵＩＣ２５０２に伝達する二つの異なる例を示す。＜表５＞は、太い斜体のようにＲＵＩＣ１５１０のデバイスデスクリプションにサービスリストを受信することができるアドレスであるサービスリストＵＲＬ(serviceListURL)を記述する方法を示す。ＲＵＩＣ２５０２はこのサービスリストＵＲＬアドレスから下の＜表６＞のような別途のＸＭＬファイルに記述されたサービスリストを得ることができる。

＜表７＞は、太い斜体に示したように、ＲＵＩＣ１５１０がＲＵＩＣ１５１０のデバイスデスクリプションにサービスリストを直接記述した後、ＲＵＩＣ２５０２に伝達する方法を示す。

ＵＩ制御モジュール５１２は、ＣＥＡ−２０１４標準に記述されたＵＩＣＰ(User Interface Control Point)を意味し、ＲＵＩＣ１５１０の内部、または外部に含まれることができる。本発明の実施形態によって、ＵＩ制御モジュール５１２は、ＲＵＩＳ５００から伝達されるＵＩページまたはコンテンツを受信することができるＲＵＩＣ２５０２を発見し、発見されたＲＵＩＣ２５０２とＲＵＩＣ１５１０のデバイス能力を把握した後、デバイス能力マッチング手順を遂行する。本発明の実施形態によって、ＵＩ制御モジュール５１２は、ＲＵＩＣ２５０２からデバイスデスクリプションを受信すると、ＲＵＩＳ５００とＲＵＩＣ２５０２との間のデバイス能力を比較した後、デバイス能力マッチング手順を遂行する。デバイス能力マッチング手順が完了した後には、ＲＵＩＣ１５１０はＲＵＩＣ２５０２に対してプロキシとして動作できる。すなわち、ＵＩ制御モジュール５１２は、ＲＵＩＣ２５０２からデバイスデスクリプションを受信し、受信したデバイスデスクリプションに基づいてＲＵＩＳ５００とＲＵＩＣ２５０２との間のデバイス能力マッチング手順を遂行することによって、ＲＵＩＳ５００とＲＵＩＣ２５０２を接続させる過程を遂行する。

ＡＳＬ伝送部５１６は、ＲＵＩＣ１５１０が参照番号４０４に示したようなＰＵＬＬモードで動作する場合に必要な情報を提供する。すなわち、ＲＵＩＣ２５０２を利用していたユーザが、プロキシＲＵＩＣとして使用可能なデバイスが周辺にあるかを検索し、デバイスがある場合、使用可能なサービスの種類を知りたいとき、該当サービスのリストをＲＵＩＣ１５１０から受信することができる。ＲＵＩＳが宅外に存在するために、ＵＩＣＰがＲＵＩＳを発見できない場合、ＲＵＩＣがＲＵＩＳのアドレスをブックマークのように一つずつ保存するようになり、これをｉ-Ｂｏｘモデルと称する。また、ｉ-Ｂｏｘモデルで、ユーザがＲＵＩＣ２５０２自体にブックマーク(Bookmark)で指定されているサービスを受信することを望む場合、ＡＳＬ伝送部５１６は、該当サービスを要請する役割を遂行する。ＡＳＬ伝送部５１６は、サービス有効性フラグハンドラ５１６ａと有効なサービスハンドラ５１６ｂを含む。

サービス有効性フラグハンドラ５１６ａは、ＲＵＩＣ１５１０がＲＵＩＣ２５０２に対してプロキシＲＵＩＣとして動作するか否かを示すための所定情報を生成してデバイスデスクリプション生成部５２４に伝送する。デバイスデスクリプション生成部５２４は、デバイスデスクリプションメッセージに該当所定情報を挿入してＲＵＩＣ２５０２に伝送する。本発明ではＲＵＩＣ１５１０がプロキシとして動作できることを仮定したので、ＲＵＩＣ１５１０が動作すれば、サービス有効性フラグハンドラ５１６ａは、ＲＵＩＣ１５１０がプロキシとして動作できることを通知するフラグを生成してデバイスデスクリプション生成部５２４に伝送し得る。

図５は、参照番号５３０に示したようにＲＵＩＣ１５１０がＲＵＩＣ２５０２にプロキシサービスを提供できるか否かを示すフラグをデバイスデスクリプションメッセージを用いて伝送することを示している。すなわち、サービス有効性フラグハンドラ５１６ａは、生成されたフラグをデバイスデスクリプション生成部５２４に伝送し、デバイスデスクリプション生成部５２４は受信されたフラグをデバイスデスクリプションに挿入してＲＵＩＣ２５０２に伝送する。

したがって、ＲＵＩＣ１５１０がプロキシであることを示すフラグを受信する場合、ＲＵＩＣ２５０２は自身の周辺に存在するＲＵＩＣ１５１０がプロキシとして動作できることを判断し得る。

本発明のプールモード(PULL mode)の場合、ＲＵＩＣ２５０２のユーザがプロキシＲＵＩＣとして動作可能な周辺のデバイスを検索し、ＲＵＩＣ１５１０を選択した後、有効なサービスハンドラ５１６ｂは、ＲＵＩＣ１５１０が提供可能なサービスリストをＲＵＩＣ２５０２に提供する。ＲＵＩＣ２５０２が提供可能なサービスリストに対する要求をＲＵＩＣ１５１０に伝送する場合、有効なサービスハンドラ５１６ｂは、ＵＩ制御モジュール５１２からＲＵＩＳ５００が提供できるサービスリストを獲得してＲＵＩＣ２５０２に伝達する。

サービス有効性フラグハンドラ５１６ａがプロキシサービスの提供可能性を示すフラグとＲＵＩＣ２５０２に対して提供可能なサービスリストを提供する過程は、ＲＵＩＣ１５１０とＲＵＩＣ２５０２との間の発見過程で遂行し得る。

デバイス能力マッチング処理部５１４は、ＲＵＩＣ２５０２のデバイス能力に適合したリモートＵＩページあるいはコンテンツが伝達されることができるように、ＲＵＩＣ２５０２のデバイス能力(device capability)情報を受信及び管理する役割をする。このように受信されたデバイス能力情報に基づいて、ＲＵＩＳ５００からＲＵＩＣ２５０２に必要なコンテンツを受信するために、ＲＵＩＣ１５１０はデバイスプロファイル(device profile)情報を適切に結合してＲＵＩＳ５００とデバイス能力マッチングを遂行する。この時、ＲＵＩＣ１５１０及びＲＵＩＣ２５０２のデバイス能力に関する情報であるデバイスプロファイル情報は、デバイス能力情報保存部５２２に保存される。

例えば、ＲＵＩＣ２５０２にコンテンツとリモートＵＩページが共に伝達される場合、ｕｉ_ｐｒｏｆｉｌｅ及びvｉdｅｏ_ｐｒｏｆｉｌｅ、ａｕｄｉｏ_ｐｒｏｆｉｌｅの全部は、ＲＵＩＣ２５０２のデバイスプロファイル情報を用いてデバイス能力マッチングが遂行される。

例えば、ｕｉ_ｐｒｏｆｉｌｅは、ポインティングデバイス(pointing device)、キーボードタイプ、ＵＩページのサイズなどの有無に関する情報を示し、vｉdｅｏ_ｐｒｏｆｉｌｅは、解像度、ピクセルの数などに関する情報を示し、ａｕｄｉｏ_ｐｒｏｆｉｌｅは、オーディオファイルのチャンネル数（２チャンネル、５．１チャンネルなど）、ボイスコーデックなどに関する情報を示す。

ここで、デバイス能力とは、ＲＵＩＣが提供できる解像度、カラーの数、オーディオチャンネルの数などのようなリモートＵＩページまたはコンテンツを視覚／聴覚的に提供するためのデバイスに関連した情報を通称する。しかしながら、ＲＵＩＣ１５１０にはリモートＵＩページのみにアクセスされ、ＲＵＩＣ２５０２にはコンテンツのみにアクセスされる場合には、ｕｉ_ｐｒｏｆｉｌｅはＲＵＩＣ１５１０のプロファイル情報、vｉdｅｏ_ｐｒｏｆｉｌｅ、ａｕｄｉｏ_ｐｒｏｆｉｌｅはＲＵＩＣ２５０２のプロファイル情報を用いてデバイス能力マッチングを遂行するようになる。このような過程は図８及び図９でさらに詳細に説明する。

リモートＵＩページ管理部５１８は、ＲＵＩＣ２５０２に伝達されるべきリモートＵＩページを再構成して再伝送する。ＲＵＩＳ５００がＲＵＩＣ２５０２のためのリモートＵＩページをＲＵＩＣ２５０２の能力に適合するように提供したとしても、ＲＵＩＣ２５０２はＲＵＩＳ５００に直接接続が不可能であるために、このリモートＵＩページに対するＵＩページ制御(Control)メッセージをＲＵＩＳ５００に直接伝達することができない。したがって、ＲＵＩＣ１５１０のリモートＵＩページ管理部５１８は、ＲＵＩＳ５００から受信したリモートＵＩページをＲＵＩＣ２５０２に再伝送する前に、ＲＵＩＣ２５０２がＲＵＩＣ１５１０に制御メッセージを伝送できるようにリモートＵＩページを変更してＲＵＩＣ２５０２に伝送する。

リモートＵＩページ管理部５１８については、図６を参照して説明する。リモートＵＩページ管理部５１８は、ＲＵＩＣ１５１０またはＲＵＩＣ２５０２のデバイス能力に適合した形態で加工されたコンテンツをＲＵＩＳ５００から受信する。すなわち、デバイス能力マッチング手順以後にコンテンツが提供されるデバイスの能力に従ってコンテンツが加工され、ＲＵＩＳ５００からＲＵＩＣ１５１０に伝達される。ここで、“加工されたコンテンツ”とは、例えば、ＲＵＩＣ２５０２に伝送されるコンテンツであれば、ＲＵＩＣ２５０２が提供可能な解像度などのような、ＲＵＩＣ２５０２のデバイス能力に適合するようにＲＵＩＳ５００で変更されたコンテンツを意味する。そして、リモートＵＩページ管理部５１８は、ＲＵＩＳ５００から受信されたリモートＵＩページがＲＵＩＣ２５０２に伝達されるべきであれば、受信されたリモートＵＩページの制御情報が伝達されるＲＵＩＳ５００のＵＲＩアドレスを自身のＵＲＩアドレスに変換し、ＲＵＩＣ２５０２に適合するように加工された新たなリモートＵＩページをＲＵＩＣ２５０２に伝送する。

メッセージ中継部５２０は、ＲＵＩＣ２５０２が伝送する制御メッセージと他の多様な種類の要請(Request)メッセージを受信した後、これをさらに元来のターゲットサーバあるいはＲＵＩＳ５００に伝送する。このために、メッセージ中継部５２０は、ＲＵＩＣ２５０２から受信されたメッセージが元来どのＵＲＩ(Uniform Resource Identifier)に送られるべきであるかを示す情報をリモートＵＩページ管理部５１８から受信した後、該当メッセージを元来のターゲットＲＵＩＳ５００や図示しない別途のコンテンツサーバに伝送する。すなわち、メッセージ中継部５２０は、ＲＵＩＣ２５０２から受信された制御メッセージまたは要請メッセージが、ＲＵＩＳ５００または意図のサーバに伝送されるように、この制御メッセージまたは要請メッセージのＵＲＩの代わりをする。

このようなリモートＵＩページ管理部５１８が必要な理由は、ＲＵＩＳ５００とＲＵＩＣ２５０２がお互いに直接的に通信できない状態であるから、ＲＵＩＳ５００から受信されたリモートＵＩページまたはコンテンツのＵＲＩアドレスをＲＵＩＳ５００のアドレスで設定してＲＵＩＣ２５０２に伝達しても、ＲＵＩＣ２５０２からそれにこのする制御情報がＲＵＩＳ５００に直接送信されることができないためである。

したがって、ＲＵＩＳ５００から受信されＲＵＩＣ２５０２に伝送されるべきＵＩコンポーネントのＵＲＩアドレスを、プロキシサービスをサポートするＲＵＩＣ１５１０のアドレスに変換する過程が必要である。

図６は、本発明の実施形態によるリモートＵＩページ管理部５１８のブロック構成図である。
まず、コンテンツ受信部６００は、ＲＵＩＳ５００からコンテンツを受信した後、再伝送権限検査部６０２に伝達する。再伝送権限検査部６０２は、ＲＵＩＳ５００から受信されたコンテンツを再伝送できるかを判断した後、その結果を新たなＵＩページ及びコンテンツ再伝送処理部６０４に提供する。再伝送権限検査部６０２がＲＵＩＳ５００から受信されたコンテンツに対して再伝送が可能であるか否かを判断しなければならない理由は、該当コンテンツに対するデジタル著作権管理及びセキュリティーのためである。

ＵＩページ受信部６０６は、リモートＵＩページをＲＵＩＳ５００から受信してパッシング(Parsing)部６０８に提供する。パッシング部６０８は、このリモートＵＩページをパッシングし、このリモートＵＩページでパッシングされたリモートＵＩページの以前ＵＲＩ(old URI:ＲＵＩＳのＵＲＩ)を新たなＵＲＩ生成及び管理部６１２に伝送する。

新たなＵＲＩ生成及び管理部６１２は、ＲＵＩＣ２５０２が伝送する制御メッセージと他の多様な要請メッセージを受信する新たなＵＲＩアドレス(ＲＵＩＣ１のＵＲＩアドレス)を生成した後、これを新たなＵＲＩ代替部６１０に伝送する。新たなＵＲＩ代替部６１０は、このリモートＵＩページに生成された新たなＵＲＩアドレスを挿入して新たなＵＩページ及びコンテンツ再伝送処理部６０４を通してＲＵＩＣ２５０２に伝送する。この時、加工された新たなリモートＵＩページもＲＵＩＣ２５０２に共に伝送される。

新たなＵＲＩ生成及び管理部６１２は、以前のＵＲＩアドレス(old URI)と新たなＵＲＩとの間のマッピング情報を保存した後、ＲＵＩＣ２５０２から制御メッセージまたは要請メッセージが受信されると、このマッピング情報によってアドレスを変換し、変換されたアドレスを用いて受信されたメッセージをＲＵＩＳ５００または他のコンテンツサーバに伝送する。

図７は、本発明の実施形態によって、ＲＵＩＣ１５１０でＲＵＩＳ５００とＲＵＩＣ２５０２との間のインターフェーシングのための動作を示すフローチャートである。

ステップ７０５で、ＲＵＩＣ１５１０は、プッシュモード又はプールモードで、ＲＵＩＣ２５０２を発見する過程を遂行する。
ステップ７０５でＲＵＩＣ２５０２を発見すると、ＲＵＩＣ１５１０はステップ７１０でＲＵＩＳ５００とＲＵＩＣ２５０２間のデバイス能力マッチング手順を遂行する。ステップ７１０でデバイス能力マッチング手順は、ＲＵＩＣ１５１０自身のデバイス能力とＲＵＩＣ２５０２のデバイス能力をＲＵＩＳ５００に伝送する過程を含む。

そして、ステップ７１５で、このデバイスマッチングが完了すると、ステップ７２０で、ＲＵＩＣ１５１０はＲＵＩＳから受信されたＵＩコンポーネントをＲＵＩＣ２に伝達する。ステップ７２０で、このＵＩコンポーネントにはリモートＵＩページ及びコンテンツが含まれることができ、例えば、ステップ７１０のデバイス能力マッチング手順を通じて、ＲＵＩＣ２５０２がリモートＵＩページまたはコンテンツをユーザに提供することができると、ＲＵＩＳ５００は、ＲＵＩＣ２５０２のデバイスプロファイルに相当するリモートＵＩページまたはコンテンツをＲＵＩＳ５００から受信することができる。そして、ステップ７２０でＲＵＩＣ１５１０はＵＩコンポーネントのうちリモートＵＩページがＲＵＩＣ２に伝達されるべきであれば、このリモートＵＩページの制御情報が伝達されるＲＵＩＳ５００のＵＲＩアドレスを自身のＵＲＩアドレスに変換し、ＲＵＩＣ２５０２に適合するように加工された新たなリモートＵＩページをＲＵＩＣ２５０２に伝送する。

ステップ７２５で、ＲＵＩＣ１５１０はＲＵＩＣ２５０２からこの伝達されたＵＩコンポーネントに対する制御メッセージを受信し、受信された制御メッセージをＲＵＩＳ５００に伝送する。

一方、ステップ７１５でマッチングが完了していないと、ＲＵＩＣ１５１０は、ステップ７３０で他のＲＵＩＣ２を検索した後、さらにステップ７０５に進行してステップ７０５乃至ステップ７２５を反復して遂行する。

図８及び図９は、ＲＵＩＣ１とＲＵＩＣ２にＲＵＩＳから提供されたリモートＵＩページ及びコンテンツが各々分離され提供される場合と、ＲＵＩＣ２にリモートＵＩページ及びコンテンツが共に提供される場合を示す図である。

図８は、ＲＵＩＣ１８０１ではリモートＵＩページのみにアクセスされ、ＲＵＩＣ２８０２ではコンテンツのみにアクセスされる場合の実施形態である。例えば、ＲＵＩＣ１８０１を通してコンテンツを消費していたユーザが、制御動作はＲＵＩＣ１８０１を通して継続遂行し、ＲＵＩＣ１８０１に比べてより大きい画面を具備したデバイスであるＲＵＩＣ２８０２を通してはコンテンツのみにアクセスすることを望む場合がこれに該当する。この場合、デバイス能力マッチング過程で、ｕｉ_ｐｒｏｆｉｌｅは、ＲＵＩＣ１８０１の情報を利用し、ａｕｄｉｏ_ｐｒｏｆｉｌｅ及びvｉdｅｏ_ｐｒｏｆｉｌｅは、ＲＵＩＣ２８０２の情報を利用する。

ステップ８０３で、ＲＵＩＣ１８０１はＲＵＩＳ８００からリモートＵＩ(ＲＵＩ)ページを受信する。ステップ８０４で該当ＲＵＩページを消費しているうちに、ステップ８０５でＲＵＩＣ１８０１はＲＵＩＳ８００から受信したコンテンツを伝達する周辺の第３のデバイスＲＵＩＣ２８０２を検索する。以後、ステップ８０６でＲＵＩＣ２８０２は、ＲＵＩＣ１８０１に自身のデバイスデスクリプションをステップ８０５に対する応答として伝送する。ステップ８０５及びステップ８０６を含むステップ８１１は、発見過程で遂行し得る。

そして、ステップ８０７で、ＲＵＩＣ１８０１はデバイス能力マッチング手順を遂行するために、ＲＵＩＣ１８０１自身のｕｉ_ｐｒｏｆｉｌｅとＲＵＩＣ２８０２のａｕｄｉｏ／vｉdｅｏ_ｐｒｏｆｉｌｅを含むデバイス能力マッチング情報をＲＵＩＳ８００に伝送する。本発明で、ＲＵＩＣ１８０１がＲＵＩＳ８００にデバイス能力マッチング情報を伝送することは、デバイス能力マッチング手順に含まれ得る。そして、ステップ８０８で、ＲＵＩＣ１８０１は、ＲＵＩＣ１８０１のプロファイルに該当する値で設定されたｕｉプロファイルを有するリモートＵＩページと、ＲＵＩＣ２８０２のプロファイルに該当する値で設定されたコンテンツのａｕｄｉｏ／vｉdｅｏプロファイルを有するコンテンツをＲＵＩＳ８００から受信する。

そして、ＲＵＩＳ８００から受信されたリモートＵＩページ及びコンテンツから、ステップ８０９でＲＵＩＣ１８０１はＵＩページに設けられた表示部を用いてリモートＵＩページをＲＵＩＣ１のユーザに出力し、ステップ８１０でコンテンツをＲＵＩＣ２８０２に伝達する。

図９は、ＲＵＩＣ２でリモートＵＩページ及びコンテンツが共にアクセスされる場合の実施形態である。図９も図８と類似した実施形態であり、この時、ＲＵＩＣ１９０１がＲＵＩＣ２９０２にリモートＵＩページ及びコンテンツを提供するために、ステップ９０７のデバイス能力マッチング過程を遂行する時、ｕｉ_ｐｒｏｆｉｌｅ、ａｕｄｉｏ_ｐｒｏｆｉｌｅ及びvｉdｅｏ_ｐｒｏｆｉｌｅの全部は、ＲＵＩＣ２９０２の情報を利用して遂行される。図９は、ステップ９０８でＲＵＩＣ１９０１がＲＵＩＣ２９０２のプロファイルを有するリモートＵＩページ及びコンテンツをＲＵＩＳ９００から受信することが図８と異なる。また、図９は、制御メッセージがＲＵＩＣ２９０２からＲＵＩＣ１９０１を介してＲＵＩＳ９００に伝達されるべきであるので、ステップ９０９でＲＵＩＣ１９０１はＲＵＩＣ２９０２が制御メッセージを伝達するアドレスをリモートＵＩページに挿入し、ステップ９１０でリモートＵＩページ及びコンテンツをＲＵＩＣ２９０２に伝達する点が図８と異なる。

ステップ９０３で、ＲＵＩＣ１９０１はＲＵＩＳ９００からリモートＵＩページを受信する。ステップ９０４でこのリモートＵＩページを消費しているうちに、ステップ９０５でＲＵＩＣ１９０１はＲＵＩＳ９００から受信したコンテンツを伝達する周辺の第３のデバイス９０２を検索する。以後、ステップ９０６でＲＵＩＣ２９０２はＲＵＩＣ１９０１に自身のデバイスデスクリプションをステップ９０５に対する応答として伝送する。ステップ９０５及びステップ９０６を含むステップ９１１は、発見過程で遂行し得る。

そして、ステップ９０７でＲＵＩＣ１９０１はデバイス能力マッチング手順を遂行するために、ＲＵＩＣ２９０２のｕｉ_ｐｒｏｆｉｌｅ、ａｕｄｉｏ／vｉdｅｏ_ｐｒｏｆｉｌｅを含むデバイス能力マッチング情報をＲＵＩＳ９００に伝送する。そして、ステップ９０８でＲＵＩＣ１９０１はＲＵＩＳ９００からＲＵＩＣ２９０２のプロファイルに該当する値で設定されたｕｉプロファイルを有するリモートＵＩページ及びａｕｄｉｏ／vｉdｅｏプロファイルを有するコンテンツを受信する。

そして、ＲＵＩＳ９００から受信されたリモートＵＩページ及びコンテンツから、ステップ９０９でＲＵＩＣ１９０１はＲＵＩＳ９００から受信されたリモートＵＩページでＲＵＩＣ２９０２が制御メッセージを伝送できるＵＲＬを変更した後、ステップ９１０でリモートＵＩとコンテンツをＲＵＩＣ２９０２に伝達する。

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

５１２・・・ＵＩ制御モジュール
５１４・・・デバイス能力マッチング処理部
５１６・・・利用可能なサービスリスト伝送部
５１８・・・リモートＵＩページ管理部
５２０・・・メッセージ中継部
５２２・・・デバイス能力情報保存部
５２４・・・デバイスデスクリプション生成部
６００・・・コンテンツ受信部
６０２・・・再伝送権限検査部
６０４・・・新しいＵＩページ及びコンテンツ再伝送処理部
６０６・・・ＵＩページ受信部
６０８・・・パッシング部
６１０・・・新しいＵＲＩ代替部
６１２・・・新しいＵＲＩ生成及び管理部

Claims

被制御機器(controlled device)にユーザインターフェース(ＵＩ:user interface)コンポーネントを提供する制御機器(controlling device)であって、
前記被制御機器により発見された前記制御機器が、前記被制御機器から前記被制御機器のデバイス能力情報を受信し、前記被制御機器から受信された前記被制御機器のデバイス能力情報と、前記制御機器のデバイス能力情報のうち少なくとも一つに基づいてサーバとのデバイス能力マッチング手順を遂行し、前記デバイス能力マッチング手順の遂行が完了すると、前記サーバから受信された前記ＵＩコンポーネントのうち前記被制御機器に提供されるＵＩコンポーネントがリモートＵＩページである場合、前記リモートＵＩページを前記被制御機器のために加工する制御部(controller)と、
前記サーバから前記ＵＩコンポーネントを直接受信することができない前記被制御機器に、前記制御機器がプロキシ(proxy)として動作できることを示す所定の情報を伝送し、前記加工されたＵＩコンポーネントを前記被制御機器に提供し、前記被制御機器から受信される前記ＵＩコンポーネントに対する制御情報を前記サーバに伝達する送受信部(transceiver)とを含む
ことを特徴とする制御機器。
前記制御部は、前記被制御機器から受信されたデバイスデスクリプションを通して前記被制御機器のプロファイル情報を獲得し、前記送受信部は、前記被制御機器のプロファイル情報と前記制御機器のプロファイル情報を前記サーバに伝送する
ことを特徴とする請求項１に記載の制御機器。
前記ＵＩコンポーネントは、リモートＵＩページ及びコンテンツのうち少なくとも一つを含む
ことを特徴とする請求項２に記載の制御機器。
前記送受信部は、前記被制御機器が前記リモートＵＩページ及びコンテンツのうち少なくとも一つを提供することができる能力を有しているか否かによって、前記リモートＵＩページ及びコンテンツのうち少なくとも一つを前記被制御機器に提供する
ことを特徴とする請求項３に記載の制御機器。
前記被制御機器が前記リモートＵＩページを提供することができる能力を有していると、前記加工されたＵＩコンポーネントは前記被制御機器のプロファイル情報を有するリモートＵＩページを含み、前記被制御機器が前記コンテンツを提供することができる能力を有していると、前記加工されたＵＩコンポーネントは前記被制御機器のプロファイル情報を有するコンテンツを含む
ことを特徴とする請求項４に記載の制御機器。
前記加工されたＵＩコンポーネントは、前記被制御機器のデバイス能力に適合するように加工が完了したＵＩコンポーネントである
ことを特徴とする請求項１に記載の制御機器。
請求項１乃至６のうちいずれか一項の制御機器を動作させることを特徴とする方法。