(57)【特許請求の範囲】
【請求項１】
遠隔ユーザーインターフェースクライアント(ＲＵＩＣ)における遠隔ユーザーインターフェースサーバ(ＲＵＩＳ)を制御する方法であって、
複数のＲＵＩＳを制御するためのＲＵＩページをレンダリングするステップと、
前記ＲＵＩページを通じてユーザーから前記複数のＲＵＩＳを各々制御するための相異なる制御命令を含む制御命令のセットの入力を受信するステップと、
前記制御命令のセットをマルチキャスト方式で伝送するためのマルチキャスト制御メッセージを生成するステップと、
前記マルチキャスト制御メッセージを前記複数のＲＵＩＳに伝送するステップと、
を有することを特徴とする方法。
【請求項２】
前記入力を受信するステップは、
前記複数のＲＵＩＳの中で該当するＲＵＩＳに対する一つ以上の制御命令の入力を受信するステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のＲＵＩＳから前記ＲＵＩページを生成するための情報を獲得するステップと、
前記複数のＲＵＩＳから獲得した情報を用いて前記ＲＵＩページを生成するステップと、
をさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
前記制御命令に該当する動作を遂行するＲＵＩＳから遂行結果応答を受信するステップ
をさらに有することを特徴とする請求項１に記載の方法。
【請求項５】
遠隔ユーザーインターフェースサーバ(ＲＵＩＳ)を制御する遠隔ユーザーインターフェースクライアント(ＲＵＩＣ)装置であって、
複数のＲＵＩＳを制御するためのＲＵＩページをレンダリングし、前記ＲＵＩページを通じてユーザーから前記複数のＲＵＩＳを各々制御するための相異なる制御命令を含む制御命令のセットの入力を受信するブラウザと、
前記制御命令のセットを前記複数のＲＵＩＳにマルチキャスト方式で伝送するためのマルチキャスト制御メッセージを生成する制御命令プロセッサと、
前記マルチキャスト制御メッセージを前記複数のＲＵＩＳに伝送するマルチキャストメッセージハンドラと、
を含むことを特徴とするＲＵＩＣ装置。
【請求項６】
前記マルチキャスト制御メッセージは、前記マルチキャスト制御メッセージが前記制御命令を含むことを示すフラグ情報を含むことを特徴とする請求項１に記載の方法又は請求
項５に記載のＲＵＩＣ装置。
【請求項７】
前記ブラウザは、前記複数のＲＵＩＳの中で該当するＲＵＩＳに対して一つ以上の入力を受信することを特徴とする請求項５に記載のＲＵＩＣ装置。
【請求項８】
前記制御命令プロセッサは、前記複数のＲＵＩＳから前記ＲＵＩページの生成のための情報を獲得し、前記複数のＲＵＩＳから獲得した情報を用いて前記ＲＵＩページを生成することを特徴とする請求項５に記載のＲＵＩＣ装置。
【請求項９】
前記制御命令プロセッサは、前記制御命令に該当する動作を遂行したＲＵＩＳから遂行結果応答を受信することを特徴とする請求項５に記載のＲＵＩＣ装置。
【請求項１０】
前記遂行結果応答は、ＨＴＴＰ  ＧＥＴ命令又はＨＴＴＰ  ＰＯＳＴ命令を用いて前記ＲＵＩＳから受信されることを特徴とする請求項４に記載の方法又は請求項９に記載のＲＵＩＣ装置。
【請求項１１】
遠隔ユーザーインターフェースサーバ(ＲＵＩＳ)により遠隔ユーザーインターフェースクライアント(ＲＵＩＣ)から制御命令を受信する方法であって、
ＲＵＩＣからマルチキャストメッセージを受信するステップと、
前記マルチキャストメッセージがマルチキャスト制御メッセージであるか否かを確認するステップと、
前記マルチキャストメッセージが前記マルチキャスト制御メッセージである場合、前記マルチキャスト制御メッセージに含まれる制御命令に従って制御されるサービスがあるか
否かを確認するステップと、
前記制御命令に従って制御されるサービスがある場合、前記サービスに対するリソースが制御可能であるか否かを確認するステップと、
前記リソースが制御可能である場合、前記制御命令に該当する動作を遂行するステップと、
を有し、
前記マルチキャストメッセージは、前記ＲＵＩＣが複数のＲＵＩＳを各々制御するための相異なる制御命令を含む制御命令のセットを含むことを特徴とする方法。
【請求項１２】
前記マルチキャスト制御メッセージに応答して前記ＲＵＩＣに前記制御命令の遂行結果を伝送するステップをさらに有することを特徴とする請求項１１に記載の方法。
【請求項１３】
遠隔ユーザーインターフェースクライアント(ＲＵＩＣ)から制御命令を受信する遠隔ユーザーインターフェースサーバ(ＲＵＩＳ)装置であって、
ＲＵＩＣからマルチキャストメッセージを受信するマルチキャストメッセージハンドラと、
前記マルチキャストメッセージがマルチキャスト制御メッセージであるか否かを確認し、前記マルチキャストメッセージが前記マルチキャスト制御メッセージである場合、前記マルチキャスト制御メッセージに含まれた制御命令により制御されるサービスがあるか否かを確認し、前記制御命令により制御されるサービスがある場合、前記サービスに対するリソースが制御可能であるか否かを確認し、前記リソースが制御可能である場合、前記制御命令の遂行を制御する制御命令受信プロセッサと、
を含み、
前記マルチキャストメッセージは、前記ＲＵＩＣが複数のＲＵＩＳを各々制御するための相異なる制御命令を含む制御命令のセットを含むことを特徴とするＲＵＩＳ装置。
【請求項１４】
前記マルチキャスト制御メッセージは、
前記マルチキャスト制御メッセージが前記制御命令を含むことを示すフラッグ情報、前記制御命令を受信するＲＵＩＳのリスト、及び前記制御命令を遂行したＲＵＩＳが応答するユニフォームリソースロケーション(ＵＲＬ)のうち少なくとも一つを含むことを特徴とする請求項１に記載の方法、請求項５に記載のＲＵＩＣ装置、請求項１１に記載の方法、又は請求項１３に記載のＲＵＩＳ装置。
【請求項１５】
前記制御命令受信プロセッサは、前記マルチキャスト制御メッセージに対応して前記ＲＵＩＣに前記制御命令の遂行結果を伝送する請求項１３に記載のＲＵＩＳ装置。
【請求項１６】
前記遂行結果は、ＨＴＴＰ  ＰＯＳＴ命令を用いて前記ＲＵＩＣに伝送することを特徴とする請求項１１に記載の方法又は請求項１３に記載のＲＵＩＳ装置。
【請求項１７】
前記遂行結果は、前記ＲＵＩＣによりＨＴＴＰ  ＧＥＴ命令を用いて前記ＲＵＩＳから受信することを特徴とする請求項１１に記載の方法又は請求項１３に記載のＲＵＩＳ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的にＩＰ(Internet  Protocol)ベースのホームネットワーキング(Home  Networking)に関するもので、特に遠隔ユーザーインターフェースクライアント(Remote User Interface Client：ＲＵＩＣ)が複数のＲＵＩサーバ(ＲＵＩＳ)を制御する方法及び装置に関する。
【背景技術】
【０００２】
一般的に、ホームネットワークは、ＩＰベースの私設網(private  network)によりなされるもので、異なるデバイス、例えば家庭内で使われるすべての形態の個人コンピュータ(ＰＣ)と知能型製品、無線装置のような多様な他のデバイスを“ミドルウェア(middleware)”と共通に呼ばれる共通の仮想コンピュータ環境を通じて一つのネットワークに接続してそのデバイスを制御する。
【０００３】
ミドルウェアは、多様なデバイスがピアツーピア(peer-to-peer)方式で接続されてデバイス間の通信を可能にする。ミドルウェアは、ＤＬＮＡ(Digital  Living  Network  Alliance)、ＨＡＶＩ(Home  Audio Video Interoperability)、ＵＰｎＰ(Universal  Plug  and  Play)、Ｊｉｎｉ(Java(登録商標)  Intelligent  Network  Infrastructure)、及びＨＷＷ(Home  Wide  Web)のような多くの産業標準団体によりホームネットワーク技術を向上させるために現在まで活発に研究され、提案されている。
【０００４】
ホームネットワークにおいて、ＲＵＩ技術は、他のデバイスの機能を制御するために一つのデバイスにより使用することができる。ＲＵＩ技術は、クライアント-サーバアーキテクチャに基づき、ＲＵＩＣがＲＵＩＳからＵＩを獲得した後、ユーザーによりＲＵＩＣでＵＩを通じてＲＵＩＳを制御することにより使用される。
【０００５】
このようなＲＵＩ技術は、アプリケーションを制御するためのユーザーインタフェースを、該当アプリケーションを駆動するデバイスの代わりに他のデバイスでレンダリング及び制御するメカニズムである。現在、ＣＥＡ(Consumer  Electronics  Association)-２０１４、ＸＨＴ(eXpandable  Home  Theater)、ＷｉＤｅＸ(Widget  Description  Exchange  Service)、及びＲＰＤ(Remote  Desktop  Protocol)のような多数の多様なＲＵＩ技術が研究されている。
【０００６】
ＣＥＡ-２０１４技術に含まれる遠隔制御システムは、遠隔制御のためのＵＩを提供するＲＵＩＳと、このＲＵＩＳから送信されたＵＩを指示するＲＵＩＣを含む。
【０００７】
遠隔制御のためのＵＩを提供するＲＵＩＳは、ＲＵＩＳ内にウェブサーバを有する。このＲＵＩＳは、ウェブサーバを通じてＲＵＩＣが要求するウェブページ(web  page)を伝送し、ＲＵＩＣは、ＸＨＴＭＬ(eXtensible  Hyper  Text  Markup  Language)ブラウザを通じて該当ＵＩのウェブページをユーザーにディスプレイする。
【０００８】
このようなＲＵＩ技術を使用すると、ＲＵＩＣは、ＲＵＩＳとセッションをセットアップし、ＲＵＩＳからＵＩコンポーネント(component)を受信してＲＵＩＳを制御できる。ここで、ＵＩコンポーネントは、ＵＩに含まれる要素を表し、アイコン、プルダウン(pull-down)メニュー、ボタン、スクロールバー、ウィンドウ、テキスト、Ａ/Ｖデータ(オーディオ/ビデオ、写真など)のようなＲＵＩＳからＲＵＩＣにＲＵＩセッションで提供されるすべてのタイプのデータを総称する概念を有する。
【０００９】
図１は、従来のＲＵＩＳにより提供される遠隔ＵＩページと制御情報を用いて複数のＲＵＩＳを制御する従来のＲＵＩＣデバイスを示す。
【００１０】
図１を参照すると、ＲＵＩＣ１００デバイスが複数のＲＵＩＳ１０１〜１０３を制御しなければならない場合、ＲＵＩＣ１００デバイスは、ＲＵＩＳ１０１〜１０３デバイスを一つずつ順次選択する。また、一つのデバイスに送信される制御命令が数個である場合、各制御メッセージは、制御されるデバイスに順次送信される。
【００１１】
例えば、ＲＵＩＣ１００のユーザーがＲＵＩＳ１０１〜１０３を制御するためには、ＲＵＩＣ１００は、各ＲＵＩＳデバイス１０１〜１０３の各々に制御命令１０４〜１０８を順次伝送する。ＲＵＩＣ１００のユーザーがＲＵＩＳ１  １０１、ＲＵＩＳ２  １０２、及びＲＵＩＳ３  １０３のボリュームダウンを希望する場合、ＲＵＩＣ１００のユーザーは、ボリュームダウン制御命令１０４，１０６，１０７を各々伝送する。その後、ＲＵＩＣ１００のユーザーがスリープモードに入るときにＲＵＩＳ１  １０１の電力オフを希望する場合、ＲＵＩＣ１００のユーザーは、制御命令１０５をＲＵＩＳ１  １０１に伝送する。ＲＵＩＣ１００のユーザーがＲＵＩＳ３  １０３のライトオフを希望する場合、ＲＵＩＣ１００のユーザーは、制御命令１０８をＲＵＩＳ３  １０３に伝送する。
【００１２】
図１において、ユーザーは、ＲＵＩＳデバイスを制御する度に、デバイスを一々選択し、制御するＲＵＩＳからＵＩページをロードするプロセスを反復する。また、制御する動作が数個である場合、制御命令を含むメッセージは、ＲＵＩＳに数回順次伝送しなければならない。しかしながら、このような場合、ユーザーは、面倒な手順と選択を繰り返して遂行することによって、制御効率が低下するという問題があった。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、ＲＵＩＣのユーザーがマルチキャストメッセージを用いて複数のＲＵＩＳを效率的に制御する方法及び装置を提供することにある。
【００１４】
本発明の他の目的は、ＲＵＩＣが隣接するＲＵＩＳを制御するための制御命令をマルチキャスト方式で伝送する方法及び装置を提供することにある。
【課題を解決するための手段】
【００１５】
上記のような目的を達成するために、本発明の一態様によれば、遠隔ユーザーインターフェースクライアント(ＲＵＩＣ)における遠隔ユーザーインターフェースサーバ(ＲＵＩＳ)を制御する方法が提供される。その方法は、ＲＵＩＳを制御するためのＲＵＩページをレンダリングするステップと、ＲＵＩページを通じてユーザーからＲＵＩＳを制御するための制御命令の入力を受信するステップと、制御命令をマルチキャスト方式で伝送するためのマルチキャスト制御メッセージを生成するステップと、マルチキャスト制御メッセージをＲＵＩＳに伝送するステップとを有する。
【００１６】
本発明の他の態様によれば、ＲＵＩＳを制御するＲＵＩＣ装置が提供される。そのＲＵＩＣ装置は、ＲＵＩＳを制御するためのＲＵＩページをレンダリングし、ＲＵＩページを通じてユーザーからＲＵＩＳを制御するための制御命令の入力を受信するブラウザと、制御命令をＲＵＩＳにマルチキャスト方式で伝送するためのマルチキャスト制御メッセージを生成する制御命令プロセッサと、マルチキャスト制御メッセージをＲＵＩＳに伝送するマルチキャストメッセージハンドラとを含む。
【００１７】
また、本発明の他の態様によれば、ＲＵＩＳによりＲＵＩＣから制御命令を受信する方法が提供される。その方法は、ＲＵＩＣからマルチキャストメッセージを受信するステップと、マルチキャストメッセージがマルチキャスト制御メッセージであるか否かを確認するステップと、マルチキャストメッセージがマルチキャスト制御メッセージである場合、マルチキャスト制御メッセージに含まれる制御命令に従って制御されるサービスがあるか否かを確認するステップと、制御命令に従って制御されるサービスがある場合、サービスに対するリソースが制御可能であるか否かを確認するステップと、リソースが制御可能である場合、制御命令に該当する動作を遂行するステップとを有する。
【００１８】
さらに、本発明の他の態様によれば、ＲＵＩＣから制御命令を受信するＲＵＩＳ装置が提供される。そのＲＵＩＳ装置は、ＲＵＩＣからマルチキャストメッセージを受信するマルチキャストメッセージハンドラと、マルチキャストメッセージがマルチキャスト制御メッセージであるか否かを確認し、マルチキャストメッセージがマルチキャスト制御メッセージである場合、マルチキャスト制御メッセージに含まれた制御命令により制御されるサービスがあるか否かを確認し、制御命令により制御されるサービスがある場合、サービスに対するリソースが制御可能であるか否かを確認し、リソースが制御可能である場合、制御命令の遂行を制御する制御命令受信プロセッサとを含む。
【００１９】
本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。
【図面の簡単な説明】
【００２０】
【図１】従来のＲＵＩＳにより提供される遠隔ＵＩページと制御情報を用いて複数のＲＵＩＳを制御する従来のＲＵＩＣデバイスを示す図である。
【図２】本発明の実施形態により、隣接するＲＵＩＳに制御命令を含むマルチキャスト制御メッセージを送信するＲＵＩＣ制御装置を示す図である。
【図３】本発明の実施形態により、ホームネットワーク環境でＲＵＩＣにより複数のＲＵＩＳを制御する制御メッセージを含むマルチキャスト制御メッセージを送信する手順を示す図である。
【図４】本発明の実施形態によるＲＵＩＣとＲＵＩＳを示すブロック構成図である。
【図５Ａ】本発明の実施形態によるＲＵＩＣと隣接するＲＵＩＳとの間の通信を示す信号フロー図である。
【図５Ｂ】本発明の実施形態によるＲＵＩＣと隣接するＲＵＩＳとの間の通信を示す信号フロー図である。
【図６】本発明の実施形態により、ＲＵＩＣがマルチキャスト制御メッセージを生成する方法を示すフローチャートである。
【図７】本発明の実施形態により、ＲＵＩＳの制御命令受信プロセッサにより受信されるマルチキャスト制御メッセージをパーシングする方法を示すフローチャートである。
【発明を実施するための形態】
【００２１】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【００２２】
本発明の実施形態の説明が単に実例を提供するためのことで、本発明の目的を限定するものでないことは、本発明の技術分野で通常の知識を持つ者には明らかである。図面において、同一の構成要素に対してはできるだけ同一の参照符号及び参照番号を付して説明する。
【００２３】
図２は、本発明の実施形態により、隣接するＲＵＩＳに制御命令を含むマルチキャスト制御メッセージを送信するＲＵＩＣ制御装置を示す。
【００２４】
図２を参照すると、ＲＵＩＳ２０１，２０２，２０３は、多様な種類の被制御装置(controlled  device)(例えば、ＤＶＤプレーヤ(ＤＶＤＰ)、オーディオシステム、ＬＣＤ(Liquid  Crystal Display)ＴＶ）であり、各々のＲＵＩＣ２０１，２０２，２０３は、ＲＵＩＣ２０５のユーザー２００により指定された制御命令を含むマルチキャスト制御メッセージ２０４をＲＵＩＣ２０５から受信する。
【００２５】
ユーザー２００により指定された制御命令は、例えば、ボリュームを下げるための制御命令を含む。上記したように、従来の技術では、ＲＵＩＣ２０５のユーザー２００は、オン状態にある隣接するＤＶＤＰ２０１、オーディオ装置２０２、及びＬＣＤ  ＴＶ２０３を一度に一つずつ選択した後、ボリュームダウン(volume  down)命令を各装置に伝送する。しかしながら、本発明の実施形態により、ＲＵＩＣ２０５は、マルチキャストメッセージを用いて、ＲＵＩＳ２０１〜２０３の全部に制御命令を一つずつ伝送する。
【００２６】
より具体的に説明すると、図２は、本発明の実施形態により、ＲＵＩＣのユーザー２００がＲＵＩＳ２０１〜２０３のボリュームを共通に減少させるように制御する制御命令２１０を含むマルチキャスト制御メッセージ２０４を伝送することを示す。さらに、マルチキャスト制御メッセージ２０４は、ＲＵＩＳ１  ２０１に対してスリープモードで電源をオフ(off)するように制御する制御命令２１２、ＲＵＩＳ２  ２０２に追加に制御する制御命令がないことを知らせるための制御命令２１４、及びＲＵＩＳ３  ２０３にライトをオフさせるように制御するための制御命令２１６を含む。
【００２７】
したがって、ＲＵＩＳ１〜３  ２０１〜２０３は、ＲＵＩＣ２０５からマルチキャスト制御メッセージ２０４を受信し、各々制御命令２１０によってそれらボリュームを下げる。また、ＲＵＩＳ１  ２０１は、制御命令２１２によってスリープモードに入る場合に電力をオフさせ、ＲＵＩＳ３  ２０３は制御命令２１６によってライトをオフさせ、ＲＵＩＳ２  ２０２は、受信したマルチキャスト制御メッセージ２０４内にＲＵＩＳ２  ２０２に該当する制御命令が“ＮＵＬＬ”２１４に設定されているため、このＲＵＩＳ２  ２０２に追加される制御命令がないことを確認する。
【００２８】
図３は、本発明の実施形態により、ホームネットワーク環境でＲＵＩＣにより複数のＲＵＩＳを制御する制御命令を含むマルチキャスト制御メッセージを伝送する手順を示す。
【００２９】
図３を参照すると、ステップ３０４において、ＲＵＩＣ３００デバイスは、隣接するＲＵＩＳデバイス３０１〜３０３を制御する制御命令のセットを設定するためのＲＵＩページを提供する。ＲＵＩページは、ＲＵＩＣ３００により複数の被制御デバイスであるＲＵＩＳ３０１〜３０３に関する情報及びこのＲＵＩＳ３０１〜３０３を制御するための制御命令に関する情報から提供され得る。
【００３０】
ユーザー３０９は、提供されたＲＵＩページを通じて隣接するＲＵＩＳ３０１〜３０３に伝送される制御命令のセットを選択し、ステップ３０５で、ＲＵＩＣ３００デバイスは、選択された制御命令をマルチキャスト制御メッセージで構成する。ステップ３０６において、マルチキャスト制御メッセージに含まれた制御命令のセットは、ＲＵＩＳ３０１〜３０３に伝送される。
【００３１】
ステップ３０６においてマルチキャスト制御メッセージを受信した後、ＲＵＩＳ３０１，３０２，３０３は、受信されたマルチキャスト制御メッセージをパーシング及び分析してマルチキャスト制御メッセージが制御のためのメッセージであるか否か、マルチキャスト制御メッセージがＲＵＩＳ３０１，３０２，３０３に有効であるか否か、及びマルチキャスト制御メッセージが制御可能であるか否かを判定した後、その判定結果を適用する。ステップ３０８において、マルチキャスト制御メッセージに含まれる制御命令による制御結果は、ＲＵＩＣ３００に伝送される。
【００３２】
図４は、本発明の実施形態によるＲＵＩＣとＲＵＩＳの論理的エンティティを示すブロック構成図である。
【００３３】
図４を参照すると、ＲＵＩＣ４００は、ブラウザ４０５、制御命令プロセッサ４０４、ユーザーインターフェース制御ポイント(ＵＩＣＰ)４０３、及びマルチキャストメッセージハンドラ４０６を含む。ＲＵＩＳ４０１は、アプリケーション４０９、制御命令受信プロセッサ４０８、ウェブサーバ４０２、及びマルチキャストメッセージハンドラ４０７を含む。
【００３４】
ＲＵＩＳ４０１のウェブサーバ４０２は、ＵＩＣＰ４０３にＲＵＩＳ４０１に関する情報及び被制御デバイスを制御するための制御命令に関する情報である制御命令情報を提供する。
【００３５】
ウェブサーバ４０２から制御命令情報を受信した後、ＵＩＣＰ４０３は、周辺に位置した隣接デバイスであるＲＵＩＳ４０１の存在を認識し、ＲＵＩＳ４０１からＲＵＩＳを制御するための情報を収集し、収集された情報を制御命令プロセッサ４０４に伝送する。ＵＩＣＰ４０３は、ＲＵＩＣ４００とＲＵＩＳ４０１との間のデバイスを接続する。
【００３６】
制御命令プロセッサ４０４は、ＵＩＣＰ４０３から獲得されたＲＵＩＳ４０１の情報及び制御命令の情報を用いてＲＵＩＳ４０１を制御するためにマルチキャスト制御メッセージを生成する。したがって、制御命令プロセッサ４０４は、ＵＩＣＰ４０３により収集されたＲＵＩＳ４０１を制御するための制御命令に対する情報を用いてＲＵＩＳ４０１を制御するためのＲＵＩページを新たに作成し、この新たに作成したＲＵＩページをブラウザ４０５に提供し、あるいは予め格納されたＲＵＩページをブラウザ４０５に提供する。
【００３７】
本発明の実施形態により、制御命令プロセッサ４０４がＲＵＩＳ４０１を制御するためにＲＵＩページを提供する２つの方法がある。
【００３８】
第１の方法では、ＵＩＣＰ４０３がウェブサーバ４０２からＲＵＩＳ４０１に対する制御情報を獲得する場合、制御命令プロセッサ４０４は、獲得した制御情報に従って新たなＲＵＩページを提供する。
【００３９】
第２の方法では、ＲＵＩＣ４００とＲＵＩＳ４０１との間の標準プロトコルが同一であるため、制御命令プロセッサ４０４は、生産プロセスで格納されたＲＵＩページを提供する。
【００４０】
さらに、制御命令プロセッサ４０４は、制御命令受信プロセッサ４０８から伝送された制御結果報告情報を受信して処理する。ブラウザ４０５は、ユーザーから入力を受信してＲＵＩＳ４０１を制御するための制御命令を生成するためにユーザーインターフェースをユーザーに提供し、ユーザーにより入力される制御命令のセットを制御命令プロセッサ４０４に伝送する。
【００４１】
制御命令プロセッサ４０４は、ブラウザ４０５から伝送された制御命令のセットによりＲＵＩＳ４０１で提供されるサービスの中で制御するサービス、制御命令のセットと順序、ＲＵＩＳ４０１が制御の結果に対する応答を送信しなければならないＵＲＬ(Uniform  Resource  Location)アドレス、必要な場合に制御命令が伝送されるＲＵＩＳを報告するための情報、一般的なマルチキャスト通知メッセージから本発明の実施形態によるマルチキャスト制御メッセージを区分するためのフラグを含むマルチキャスト制御メッセージを生成してマルチキャストメッセージハンドラ４０６に伝送する。
【００４２】
制御命令が伝送されるＲＵＩＳを報告する情報は、制御命令のセットの一部がＲＵＩＳ１に伝送され、制御命令のセットの他の一部がＲＵＩＳ２に伝送される場合、各制御命令が伝送されなければならない特定のＲＵＩＳを指示するために包含可能な情報である。
【００４３】
ＲＵＩＣ４００のマルチキャストメッセージハンドラ４０６は、制御命令プロセッサ４０４から受信されたマルチキャスト制御メッセージを隣接するＲＵＩＳ４０１にマルチキャストする。従来の一般的な技術では、マルチキャスト通知メッセージは、ＲＵＩＳ４０１からＲＵＩＣ４００に送信されるが、本発明の実施形態ではマルチキャスト制御メッセージが反対方向に送信される。すなわち、マルチキャスト通知メッセージは、ＲＵＩＣ４００からＲＵＩＳ４０１に伝送される。したがって、マルチキャストメッセージハンドラ４０６とマルチキャストメッセージハンドラ４０７は、本発明の実施形態によりマルチキャスト制御メッセージを送受信することができる。
【００４４】
マルチキャストメッセージハンドラ４０７がＲＵＩＣ４００からマルチキャスト制御メッセージを受信する場合、マルチキャストメッセージハンドラ４０７は、受信されたマルチキャスト制御メッセージを制御命令受信プロセッサ４０８に伝送する。制御命令受信プロセッサ４０８は、受信されたマルチキャスト制御メッセージをパーシングし、ＲＵＩＳ４０１を制御する権利を有する制御デバイスであるＲＵＩＣ４００から送信される命令がマルチキャスト制御メッセージであるか否かを判定する。その判定の結果、マルチキャスト制御メッセージがＲＵＩＣ４００から伝送された命令である場合、制御命令受信プロセッサ４０８は、自身により提供されるサービスの中でどのサービスを制御する命令であるかを判定し、その命令が制御されるサービスのリソースを制御できるか否かを判定する。さらに、制御命令受信プロセッサ４０８は、必要な場合、上記命令が自身を制御するために意図的な制御命令であるか否かを判定する。
【００４５】
マルチキャスト制御メッセージを受信した後、制御命令受信プロセッサ４０８は、受信されたマルチキャスト制御メッセージに含まれた制御命令がＲＵＩＳ４０１を制御するために伝送されるか否か、上記制御命令がＲＵＩＳ４０１を制御するために受信されても、ＲＵＩＳ４０１の能力(capability)で制御命令が遂行できるか否かを判定することによって、制御命令受信プロセッサ４０８は、自身を制御するための意図的制御命令であるか否かを判定することができる。
【００４６】
その判定結果、受信されたマルチキャスト制御メッセージが自身を制御するための制御命令を含む場合、制御命令受信プロセッサ４０８は、マルチキャスト制御メッセージに含まれた制御命令をアプリケーション４０９に伝送し、アプリケーション４０９は、制御命令に従って制御を実行する。さらに、アプリケーション４０９は、制御の結果を制御命令受信プロセッサ４０８にまた報告し、制御命令受信プロセッサ４０８は、制御命令に対する処理結果を制御命令プロセッサ４０４に報告することによってマルチキャスト制御動作を終了する。したがって、制御命令プロセッサ４０４は、小さい組み込み(embedded)ウェブサーバの機能を有し、あるいはＲＵＩＣ４００及びＲＵＩＳ４０１各々の内部のウェブサーバ機能を用いてサーバ-クライアント機能を遂行することができる。
【００４７】
＜表１＞は、本発明の実施形態によるマルチキャスト制御メッセージの構成図であり、ＸＭＬ(eXtensible  Markup  Language)で作成されている。＜表１＞において、“Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｔｙｐｅ”は、一般的なマルチキャストメッセージと区分するためにマルチキャストメッセージが制御命令を含むマルチキャスト制御メッセージであることを表すフラグである。
【００４８】
また、＜表１＞において、＜ａｒｇｕｍｅｎｔＮａｍｅＸ＞タグは、各ＲＵＩＳデバイスに適用される制御命令のセットを意味する。すなわち、＜表１＞において、“Ａ”はＲＵＩＳ１に該当するコンテンツであり、＜Ｔａｒｇｅｔ  ｖａｌｕｅ＝“１２３.１５６.２１３.１”はＲＵＩＣ１のＩＰアドレスを表し、＜ａｒｇｕｍｅｎｔＮａｍｅ１＞ｉｎ  ａｒｇ  ｖａｌｕｅ＜/ａｒｇｕｍｅｎｔＮａｍｅ１＞は、ＲＵＩＳ１に該当する制御命令が１個であることを示し、この制御命令は“ｉｎ  ａｒｇ  ｖａｌｕｅ”に挿入される。
【００４９】
同様に、“Ｂ”はＲＵＩＳ２に該当するコンテンツであり、＜Ｔａｒｇｅｔ  ｖａｌｕｅ＝“１２３.１５６.２１３.２”はＲＵＩＣ２のＩＰアドレスを表し、＜ａｒｇｕｍｅｎｔＮａｍｅ１＞ｉｎ  ａｒｇ  ｖａｌｕｅ＜/ａｒｇｕｍｅｎｔＮａｍｅ１＞〜＜ａｒｇｕｍｅｎｔＮａｍｅ３＞ｉｎ  ａｒｇ  ｖａｌｕｅ＜/ａｒｇｕｍｅｎｔＮａｍｅ３＞は、ＲＵＩＳ２に該当する制御命令が３個であることを示し、この制御命令は“ｉｎ  ａｒｇ  ｖａｌｕｅ”に挿入される。“Ｃ”はＲＵＩＳ３に該当するコンテンツであり、＜Ｔａｒｇｅｔ  ｖａｌｕｅ＝“１２３.１５６.２１３.３”はＲＵＩＣ３のＩＰアドレスを表し、＜ａｒｇｕｍｅｎｔＮａｍｅ１＞ｉｎ  ａｒｇ  ｖａｌｕｅ＜/ａｒｇｕｍｅｎｔＮａｍｅ１＞〜＜ａｒｇｕｍｅｎｔＮａｍｅ２＞ｉｎ  ａｒｇ  ｖａｌｕｅ＜/ａｒｇｕｍｅｎｔＮａｍｅ２＞は、ＲＵＩＳ３に該当する制御命令が２個であることを示し、この制御命令は“ｉｎ  ａｒｇ  ｖａｌｕｅ”に挿入される。“Ｄ”は、ＲＵＩＣにより制御されるＲＵＩＳが応答メッセージを伝送するＵＲＬアドレスを表す。
【００５０】
【表１】
0005495462.tif 000002
【００５１】
図５Ａ及び図５Ｂは、本発明の実施形態により、ＲＵＩＣと隣接ＲＵＩＳとの間の通信示す信号フロー図である。
【００５２】
図５Ａを参照すると、本発明の実施形態によって、ＲＵＩＣ５００は、２つのプロセス５９０，５９２のうちいずれか一つを使用してＲＵＩページを提供する。第１のプロセス５９０、すなわちオプション１は、ＲＵＩＣ５００がＲＵＩＳ５０１，５０２のＲＵＩページを予め格納するケースに該当する。プロセス５９０において、ＲＵＩＣ５００とＲＵＩＳ５０１，５０２の製造会社が相互に異なっても、ＲＵＩＣ５００及びＲＵＩＳ５０１，５０２は、特定標準に従って生産されるので、共通の制御命令により制御することができる。
【００５３】
第２のプロセス５９２、すなわちオプション２は、ＲＵＩＣ５００が隣接するＲＵＩＳ５０１，５０２を検索し、各ＲＵＩＳごとに制御できる制御命令に関連した情報を獲得して該当ＲＵＩＳを制御するＲＵＩページを制御するケースに該当する。ＲＵＩＣ５００とＲＵＩＳ５０１，５０２が共通規格を持たず、各製造会社(ベンダー:vendor)に従って特定される場合、オプション２は、ＲＵＩＣ５００により各ＲＵＩＳ５０１，５０２を制御するＲＵＩページを提供するために使用される。
【００５４】
特に、プロセス５９０において、ＲＵＩＣ５００のブラウザ５７３は、ステップ５０３で、予め格納されているＲＵＩページをレンダリングしてユーザーに見せ、ステップ５０４で、ユーザーから制御命令の入力を受信する。ステップ５０５において、ブラウザ５７３は、入力された制御命令を制御命令プロセッサ５７０に伝送する。
【００５５】
プロセス５９２において、隣接するＲＵＩＳであるＲＵＩＳ１  ５０１、ＲＵＩＳ２  ５０２のウェブサーバ５７５，５７６から各ＲＵＩＳに提供可能なサービスリストと、ＲＵＩＳを制御するための制御情報とを獲得した後、ＲＵＩＣ５００の制御命令プロセッサ５７０は、ステップ５０７で、獲得した情報を用いてＲＵＩページを生成する。
【００５６】
制御命令プロセッサ５７０は、ステップ５０８で生成されたＲＵＩページをブラウザ５７３に伝送し、ブラウザ５７３は、ステップ５０９で伝送されたＲＵＩページをレンダリングしてユーザーに見せる。
【００５７】
ブラウザ５７３は、ステップ５１０で制御命令の入力を受信し、ステップ５１１で、制御命令プロセッサ５７０に入力された制御命令を伝送する。
【００５８】
プロセス５９０又はプロセス５９２を通じてＲＵＩページが提供され、提供されたＲＵＩページを通じてＲＵＩＳを制御するための制御命令が入力される場合、制御命令プロセッサ５７０は、ステップ５２０で、入力された制御命令と制御するＲＵＩＳリストを決定した後にマルチキャスト制御メッセージを生成する。その後、図５Ｂに示すように、制御命令プロセッサ５７０は、ステップ５３０において、生成されたマルチキャスト制御メッセージをＲＵＩＳ１  ５０１及びＲＵＩＳ２  ５０２に伝送する。
【００５９】
図５Ｂを参照すると、ＲＵＩＳ５０１，５０２の制御命令受信プロセッサ５７１，５７２は、ステップ５４２で、受信されたマルチキャスト制御メッセージをパッシング及び分析する。ステップ５４２において、制御命令受信プロセッサ５７１，５７２は、分析されたマルチキャスト制御メッセージに含まれた制御命令に従って動作を遂行する。
【００６０】
ステップ５４２で制御命令に従って動作を遂行した後、制御命令受信プロセッサ５７１，５７２は、ステップ５５２又はステップ５６２で、その結果をＲＵＩＣ５００に報告する。つまり、２個の異なる方式、すなわち、ステップ５５２及びステップ５６２があり、制御命令受信プロセッサ５７１，５７２はＲＵＩＣ５００に制御命令による動作を報告できる。
【００６１】
ステップ５５２は、受信されたマルチキャスト制御メッセージに含まれたＵＲＬ(制御命令による動作を報告するためのＲＵＩＣに存在するアドレス)にＨＴＴＰ  ＰＯＳＴ命令を用いてその内容を伝送する方法である。ステップ５６２は、ステップ５０６で獲得したＲＵＩＳ５０１，５０２の状態を認知できる情報が格納されたＲＵＩＳ５０１，５０２の各々に含まれたＵＲＬアドレスにＨＴＴＰ  ＧＥＴ命令を用いて、制御命令プロセッサ５７０が制御結果の現在状態をポーリング(polling)方式で要請するプロセスである。
【００６２】
より具体的に説明すれば、ステップ５５０において、制御命令受信プロセッサ５７１，５７２は、ステップ５３０で受信されたマルチキャスト制御メッセージに含まれたＲＵＩＣ５００に存在するＵＲＬに制御命令に対する応答をＨＴＴＰ  ＰＯＳＴ命令を用いて伝送する。ステップ５５１において、制御命令プロセッサ５７０は、ステップ５５０に応答してＨＴＴＰ応答メッセージを制御命令受信プロセッサ５７１，５７２に各々伝送する。したがって、制御命令プロセッサ５７０は、ＨＴＴＰ要請を受信及び処理できる小さな、一種の組み込みウェブサーバの機能を必要とする。
【００６３】
あるいは、ステップ５６０において、制御命令プロセッサ５７０は、ステップ５０６で獲得したＲＵＩＳ５０１，５０２の状態情報に含まれたＵＲＬアドレスにＨＴＴＰ  ＧＥＴ命令を用いて制御命令に対する処理結果を持ってくる。ステップ５６１において、制御命令受信プロセッサ５７１，５７２は、ステップ５６０に応答してＨＴＴＰ応答メッセージを制御命令プロセッサ５７０に伝送する。ステップ５６１での報告を通じて、制御命令プロセッサ５７０は、ＲＵＩＳ１  ５０１とＲＵＩＳ２  ５０２の制御動作が成功的に遂行されるか否かを認知することができる。しかしながら、この制御動作が失敗した場合、制御命令プロセッサ５７０は、失敗した理由を識別するための動作を遂行する。
【００６４】
図５Ａ及び図５Ｂを参照すると、上記した方法は、大きくＲＵＩページを提供するためのステップ５８０、マルチキャスト制御メッセージを生成するためのステップ５８２、マルチキャスト制御メッセージ受信を処理するためのステップ５８４、及び上記のような制御結果に応答するためのステップ５８６に分けられる。
【００６５】
加えて、図５Ａ及び図５Ｂの説明において、ＵＩＣＰは、説明の便宜上、ＲＵＩＣ５００に位置すると仮定する。しかしながら、ＵＩＣＰは、ＲＵＩＳ５０１又は５０２、あるいは別途のデバイスに位置することができる。基本的に、このＵＩＣＰは、位置する場所に関係なく同一の動作を遂行することができる。
【００６６】
図６は、本発明の実施形態によるＲＵＩＣによりマルチキャスト制御メッセージを生成する方法を示すフローチャートである。
【００６７】
図６を参照すると、ステップ６００において、ＲＵＩＣの制御命令プロセッサ５７０は、マルチキャスト制御メッセージを生成するか否かを判定する。その結果、マルチキャスト制御メッセージを生成すると判定した場合、制御命令プロセッサ５７０は、マルチキャスト制御メッセージがマルチキャスト制御メッセージ内に制御用であることを表すフラグを設定する。
【００６８】
ステップ６０４において、ＲＵＩＣの制御命令プロセッサ５７０は、制御命令リストを生成し、制御するＲＵＩＳを設定する。ステップ６０４において、制御命令プロセッサ５７０は、制御されるいくつかの命令語がある場合、制御命令プロセッサ５７０は、制御する命令に対するリストを生成し、生成したリストに含まれる制御命令語の処理順序を決定して最初に制御される制御命令を優先的に設定できる。また、ステップ６０４で、ホームネットワーク上に存在するＲＵＩＳの中で制御されるＲＵＩＳを選択する必要がある場合、制御命令プロセッサ５７０は、制御されるＲＵＩＳを設定し、制御されるＲＵＩＳのリストを生成する。
【００６９】
制御命令プロセッサ５７０は、ステップ６０６でＲＵＩＳが応答するＵＲＬを生成し、ステップ６０８で、ステップ６０２〜６０６で生成した情報を含むマルチキャスト制御メッセージを生成する。
【００７０】
図７は、本発明の実施形態により、ＲＵＩＳの制御命令受信プロセッサにより受信されるマルチキャスト制御メッセージをパーシングする方法を示すフローチャートである。
【００７１】
図７を参照すると、ステップ７００において、制御命令受信プロセッサ５７１，５７２がＲＵＩＣからマルチキャスト制御メッセージを受信する場合、制御命令受信プロセッサ５７１，５７２は、ステップ７０２で、受信されたマルチキャスト制御メッセージが認証されたＲＵＩＣから受信したマルチキャスト制御メッセージであるか否かを確認する。ここで、公知の多様な認証方法が認証方法として使用可能である。
【００７２】
マルチキャスト制御メッセージが認証されたＲＵＩＣから受信されたマルチキャスト制御メッセージである場合、制御命令受信プロセッサ５７１，５７２は、ステップ７０４で、受信されたマルチキャスト制御メッセージが自身に該当する制御命令を含むか否かを判定する。ステップ７０６で、制御命令が制御命令受信プロセッサ５７１，５７２に該当すると確認される場合、制御命令受信プロセッサ５７１，５７２は、ステップ７０８で制御命令に従って制御されるサービスを確認した後、ステップ７１０で、制御されるサービスリソースが制御可能であるか否かを確認する。
【００７３】
例えば、制御命令がボリュームダウンのための命令である場合、誰かが既にボリュームを制御すると、ステップ７１０で、ボリュームダウンのための制御命令が可能でないと判断する。
【００７４】
ステップ７１２において、制御命令受信プロセッサ５７１，５７２は、制御命令に対する動作を遂行する。
【００７５】
上記した本発明の実施形態によると、遠隔ＵＩ環境で複数のＲＵＩＳデバイスに複数の制御命令を效果的に伝送することによって、複数のＲＵＩＳデバイスを効率的に制御することができる。したがって、本発明の実現を通じて、一つのＲＵＩＣが同一の動作を制御するための同一のコンテキスト(context)の制御命令を不特定多数のいろいろなデバイスに反復的に送信する必要はない。さらに、ＲＵＩＣが制御する隣接するＲＵＩＳデバイスの種類と個数を正確に認知できず、あるい認知しても煩わしい場合でも、ＲＵＩＣは、ＲＵＩＳデバイスを容易に制御できる。
【００７６】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び精神を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【００７７】
１００  ＲＵＩＣ
１０１  ＲＵＩＳ、ＤＶＤＰ
１０２  ＲＵＩＳ、オーディオ
１０３  ＲＵＩＳ、ワイドＬＣＤ  ＴＶ
１０４、１０５、１０６、１０７、１０８  制御命令
２００  ユーザー
２０１  ＲＵＩＳ、ＤＶＤＰ
２０２  ＲＵＩＳ、オーディオ装置
２０３  ＲＵＩＳ、ワイドＬＣＤ  ＴＶ
２０４  ＲＵＩＳ、マルチキャスト制御メッセージ
２０５  ＲＵＩＣ
２１０、２１２、２１４、２１６  制御命令
３００  ＲＵＩＣ
３０１  ＲＵＩＳ、ＤＶＤＰ
３０２  ＲＵＩＳ、オーディオ
３０３  ＲＵＩＳ、ワイドＬＣＤ  ＴＶ
３０９  ユーザー
４００  ＲＵＩＣ
４０１  ＲＵＩＳ
４０２  ウェブサーバ
４０３  ユーザーインターフェース制御ポイント（ＵＩＣＰ）
４０４  制御命令プロセッサ
４０５  ブラウザ
４０６、４０７  マルチキャストメッセージハンドラ
４０８  制御命令受信プロセッサ
４０９  アプリケーション
５００  ＲＵＩＣ
５０１、５０２  ＲＵＩＳ
５７０  制御命令プロセッサ
５７１，５７２  制御命令受信プロセッサ
５７３  ブラウザ
５７５，５７６  ウェブサーバ
【図１】
0005495462.tif 000003
【図２】
0005495462.tif 000004
【図３】
0005495462.tif 000005
【図４】
0005495462.tif 000006
【図５Ａ】
0005495462.tif 000007
【図５Ｂ】
0005495462.tif 000008
【図６】
0005495462.tif 000009
【図７】
0005495462.tif 000010