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

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5916822

(24)【登録日】2016年4月15日

(45)【発行日】2016年5月11日

(54)【発明の名称】リモートユーザインターフェースサーバとリモートユーザインターフェースクライアントとの間のインターフェースのための装置及び方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20160422BHJP

【ＦＩ】

   G06F13/00 358C

【請求項の数】7

【全頁数】22

(21)【出願番号】特願2014-186107(P2014-186107)

(22)【出願日】2014年9月12日

(62)【分割の表示】特願2012-533080(P2012-533080)の分割

【原出願日】2010年10月7日

(65)【公開番号】特開2015-18568(P2015-18568A)

(43)【公開日】2015年1月29日

【審査請求日】2014年9月12日

(31)【優先権主張番号】10-2009-0096469

(32)【優先日】2009年10月9日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ヨン−ワン・ソ

(72)【発明者】

【氏名】ヨン−スン・リュ

(72)【発明者】

【氏名】ジェ−ヨン・ソン

【審査官】 佐々木 洋

(56)【参考文献】

【文献】 国際公開第２００９／１０４９０８（ＷＯ，Ａ２）

【文献】 特開２０００−２５３０６９（ＪＰ，Ａ）

【文献】 国際公開第２００８／１２０８９０（ＷＯ，Ａ１）

【文献】 特開２００８−１３００８２（ＪＰ，Ａ）

【文献】 特開２００８−２８３６７０（ＪＰ，Ａ）

【文献】 特開２００７−１９５１８７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

被制御機器(controlled device)にユーザインターフェース(ＵＩ:user interface)コンポーネントを提供する制御機器(controlling device)であって、
前記被制御機器により発見された前記制御機器が、前記被制御機器から前記被制御機器のデバイス能力情報を受信し、前記被制御機器から受信された前記被制御機器のデバイス能力情報と、前記制御機器のデバイス能力情報のうち少なくとも一つに基づいてサーバとのデバイス能力マッチング手順を遂行し、前記デバイス能力マッチング手順の遂行が完了すると、前記サーバから受信された前記ＵＩコンポーネントのうち前記被制御機器に提供されるＵＩコンポーネントがリモートＵＩページである場合、前記リモートＵＩページを前記被制御機器のために加工する制御部(controller)と、
前記サーバから前記ＵＩコンポーネントを直接受信することができない前記被制御機器に、前記制御機器がプロキシ(proxy)として動作できることを示す所定の情報を伝送し、前記加工されたＵＩコンポーネントを前記被制御機器に提供し、前記被制御機器から受信される前記ＵＩコンポーネントに対する制御情報を前記サーバに伝達する送受信部(transceiver)とを含む
ことを特徴とする制御機器。

【請求項2】

前記制御部は、前記被制御機器から受信されたデバイスデスクリプションを通して前記被制御機器のプロファイル情報を獲得し、前記送受信部は、前記被制御機器のプロファイル情報と前記制御機器のプロファイル情報を前記サーバに伝送する
ことを特徴とする請求項１に記載の制御機器。

【請求項3】

前記ＵＩコンポーネントは、リモートＵＩページ及びコンテンツのうち少なくとも一つを含む
ことを特徴とする請求項２に記載の制御機器。

【請求項4】

前記送受信部は、前記被制御機器が前記リモートＵＩページ及びコンテンツのうち少なくとも一つを提供することができる能力を有しているか否かによって、前記リモートＵＩページ及びコンテンツのうち少なくとも一つを前記被制御機器に提供する
ことを特徴とする請求項３に記載の制御機器。

【請求項5】

前記被制御機器が前記リモートＵＩページを提供することができる能力を有していると、前記加工されたＵＩコンポーネントは前記被制御機器のプロファイル情報を有するリモートＵＩページを含み、前記被制御機器が前記コンテンツを提供することができる能力を有していると、前記加工されたＵＩコンポーネントは前記被制御機器のプロファイル情報を有するコンテンツを含む
ことを特徴とする請求項４に記載の制御機器。

【請求項6】

前記加工されたＵＩコンポーネントは、前記被制御機器のデバイス能力に適合するように加工が完了したＵＩコンポーネントである
ことを特徴とする請求項１に記載の制御機器。

【請求項7】

請求項１乃至６のうちいずれか一項の制御機器を動作させることを特徴とする方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

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

【0006】

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

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【先行技術文献】

【特許文献】

【0013】

【特許文献1】国際公開第２００９／１０４９０８号

【発明の概要】

【発明が解決しようとする課題】

【0014】

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

【課題を解決するための手段】

【0015】

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

【0016】

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

【発明の効果】

【0017】

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

【0018】

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

【図面の簡単な説明】

【0019】

【図1】ＲＵＩＳ(Remote User Interface Server)がＲＵＩＣ１と第３のＲＵＩＣにリモートＵＩページ及びコンテンツを伝送する一般的な例を示す図である。

【図2】本発明の実施形態によって、プロキシＲＵＩデバイスを介して第３のＲＵＩＣデバイスがレンダリングするようにリモートＵＩページ及びコンテンツを伝送することを示す図である。

【図3】本発明の実施形態によって、第３のＲＵＩＣデバイスにリモートＵＩページ及びコンテンツを伝達するために必要なプロトコルと手順を定義する図である。

【図4】本発明の実施形態によって、プロキシＲＵＩＣと第３のＲＵＩＣデバイスがお互いを発見する方法を示す図である。

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

【図6】本発明の実施形態によるリモートＵＩページ管理部のブロック構成図である。

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

【図8】本発明の実施形態によってＲＵＩＣ１ではリモートＵＩページのみにアクセスされ、ＲＵＩＣ２ではコンテンツのみにアクセスされる場合を示す図である。

【図9】本発明の実施形態によってＲＵＩＣ２でリモートＵＩページ及びコンテンツが共にアクセスされる場合の実施形態を示す図である。

【発明を実施するための形態】

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

【表1】

【0032】

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

【0033】

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

【0034】

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

【0035】

【表2】

【0036】

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

【0037】

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

【0038】

【表3】

【0039】

【表4】

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

【表5】

【0045】

【表6】

【0046】

【表7】

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【符号の説明】

【0082】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】