JP4456095B2

JP4456095B2 - ホームネットワークで第３の装置のイベントを処理する方法及び装置

Info

Publication number: JP4456095B2
Application number: JP2006248034A
Authority: JP
Inventors: 永九高; 允洙金; 相善崔; 正子金
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2005-09-28
Filing date: 2006-09-13
Publication date: 2010-04-28
Anticipated expiration: 2026-09-13
Also published as: EP1770934B1; KR100736090B1; EP1770934A2; CN1941729A; JP2007095051A; US7958272B2; US20070089055A1; KR20070035948A; EP1770934A3

Description

本発明は、ホームネットワークでのイベンティング処理技術に係り、より詳細には、ホームネットワークでのＵＩセッションに属しない第３の装置のイベントを他の装置で処理できるようにするホームネットワークで第３の装置のイベントを処理する方法及び装置に関する。

一般的に、ホームネットワークは、インターネットプロトコル（以下、ＩＰと称する）基盤の私設網（プライベートネットワーク）からなるものであって、家庭内で使われるすべての形態の個人コンピュータ（ＰＣ）と知能型製品、無線装置などの多様な機器をミドルウェア（ｍｉｄｄｌｅｗａｒｅ）と呼ばれる共通の仮想コンピューティング環境を通じて一つのネットワークに連結して統制するものである。

ミドルウェアとは、多様なデジタル機器をピアツーピア（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）方式で連結して機器間の通信を可能にするものであって、ＨＡＶＩ（ＨｏｍｅＡＶＩｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）、ＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）、Ｊｉｎｉ（Ｊａｖａ（登録商標）ＩｎｔｅｌｌｉｇｅｎｔＮｅｔｗｏｒｋＩｎｆｒａ−ｓｔｒｕｃｔｕｒｅ）、ＨＷＷ（ＨｏｍｅＷｉｄｅＷｅｂ）などが現在まで提案されている。

この中、ＵＰｎＰミドルウェアを通じて構築されるコンピューティング環境で各機器は、動的ホスト構成規約（ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ；ＤＨＣＰ）によってサーバーから割り当てられるか、自動ＩＰ指定機能（ＡｕｔｏＩＰ）によって選択されるアドレスを割り当てられ、これを通じて各機器間の通信及びネットワーク上での検索／照会を実行する。

ＵＰｎＰネットワークは、近い未来にもっとも多く活用される可能性が高いホームネットワーク技術であって、ＵＰｎＰデバイスとＵＰｎＰサービス（ｓｅｒｖｉｃｅ）を定義して、これらの間のプロトコルによって定義している。ＵＰｎＰネットワークは、ＩＰ基盤のホームネットワークに連結されて制御されるホームネットワーク機器である被制御装置（ＣｏｎｔｒｏｌｌｅｄＤｅｖｉｃｅ：ＣＤ）と、これら被制御装置を制御するための機器である制御ポイント（ＣｏｎｔｒｏｌＰｏｉｎｔ：ＣＰ）として構成される。前記制御ポイントは、被制御装置に対する制御を実行する装置であって、イベントを要請してイベントを受信する構成要素である。前記被制御装置は、前記制御ポイントの要請によって決まった機能を実行する装置であって、被制御装置の状態（ｓｔａｔｅ）が変更されれば、イベントを要請した制御ポイントに前記イベントを送る構成要素である。

従来のＵＰｎＰネットワークの機器間の各段階別動作過程を見ると、ディスカバリーアドバタイズメント（ｄｉｓｃｏｖｅｒｙ−ａｄｖｅｒｔｉｓｅｍｅｎｔ）過程、デスクリプション（Ｄｅｓｃｒｉｐｔｉｏｎ）過程、制御（Ｃｏｎｔｒｏｌ）過程、及びイベンティング（ｅｖｅｎｔｉｎｇ）過程からなりうる。

ディスカバリーアドバタイズメント過程は、新しい被制御装置がホームネットワークに連結されてホームネットワーク上の他のデバイスに自身を知らせるアドバタイズメント過程と、新しい制御ポイントがホームネットワークに連結されてホームネットワーク上で動作する被制御装置を検索（サーチ）するディスカバリー過程を含む。

デスクリプション過程は、制御ポイントが被制御装置を制御するためにディスカバリーアドバタイズメント過程で得られた被制御装置のＩＰアドレスを通じてサービスデスクリプションＸＭＬ（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）ファイルまたはデバイスデスクリプションＸＭＬファイルをパーシング（Ｐａｒｓｉｎｇ）して新たに追加されたデバイスの機能をより詳しく把握する過程である。

制御過程は、制御ポイントが被制御装置を通じて特定サービスを提供しようとする場合、ＵＰｎＰデバイスアーキテクチャーによってＳＯＡＰを利用して所定のサービスを要請する制御メッセージ（アクションリクエスト）を該当被制御装置に伝送して、これに対する応答メッセージ（ｒｅｓｕｌｔ、ｖａｒｉａｂｌｅｖａｌｕｅ）を受信する過程である。

イベンティング過程は、制御ポイントから伝送される制御命令によって所定のサービスを提供した被制御装置の情報変更状態を確認する過程であって、図１を参照してイベンティング過程を説明する。

前記図１を参照すれば、制御ポイントと被制御装置が１：１の関係を成しながらイベンティング過程を実行することが分かる。まず、制御ポイントが被制御装置の情報変更状態を確認するためにサブスクリプションを要請するメッセージ（サブスクリプションリクエスト）を被制御装置のサービスに伝送すれば、被制御装置のサービスでは変更された情報を知らせるためにＧＥＮＡ（ＧｅｎｅｒｉｃＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＡｒｃｈｉｔｅｃｔｕｒｅ）を通じてフォーマットされたＸＭＬ形態のイベントメッセージを前記制御ポイントに送信する。制御ポイントでは、被制御装置から伝送されたイベントメッセージを受信して、被制御装置に対するデスクリプションアップデート項目として処理する。もし、ｓｕｂｓｃｒｉｂｅ期間が満了したが、制御ポイントがさらにイベントの受信を希望する時は、また、被制御装置のサービスに更新要請（リニューアルリクエスト）メッセージを送ってサブスクリプション期間の延長を要請する。これにより、前記サービスは、新しいサブスクリプション期間を明示してサブスクリプションを許容する。制御ポイントがこれ以上イベントの受信を願わない時は、被制御装置のサービスにアンサブスクライブメッセージを送ってサブスクリプションを取り消し（キャンセル）できる。

一方、図２は、従来のＵＰｎＰＲｅｍｏｔｅＵＩで提案するイベンティング過程を示す図面である。まず、制御ポイント１０が被制御装置に該当するＲＵＩサーバー２０とＲＵＩクライアント３０にプロトコル情報を獲得する（Ｓ１１）。また、制御ポイント１０は、ＲＵＩサーバー２０がＲＵＩクライアント３０を通じて提供できるすべての有用なＵＩ情報を獲得した後（Ｓ１２）、ＲＵＩクライアント３０を通じて出力しようとする適切なＵＩを選択する（Ｓ１３）。そして、ＲＵＩクライアント３０と連結して前記選択したＵＩの出力を要請して（Ｓ１４）、前記要請を受けたＲＵＩクライアント３０は、ＲＵＩサーバー２０とＯｕｔｏｆＢａｎｄプロトコルを形成して前記ＵＩ情報を出力する（Ｓ１５）。

一般的に、被制御装置の状態が変更されれば、制御ポイントにイベントメッセージを伝送して状態が変更されることを知らせる。しかし、前記のようなＵＰｎＰＲｅｍｏｔｅＵＩでは、ＵＰｎＰプロトコルで定義されたイベント以外にＲＵＩサーバー２０のＵＩ状態が変更されれば、これを反映するＲＵＩクライアント３０に知らせる手段は、二つの装置２０、３０の間のリモートプロトコルによってのみ可能である。これは二つの装置２０、３０の間に結ばれたリモートプロトコルセッションが進行中である場合にのみ可能である。

ところが、もし、第３の装置が存在して或る自身の状態を知らせようとする場合には、既存のリモートＵＩ方法ではカバーしにくい。実際に、ＵＰｎＰＲｅｍｏｔｅＵＩスペックでは、このような短所を克服するためにディスプレイメッセージアクションを提供するが、前記アクションは、ＣＰ機能を実行する装置がＲＵＩサーバー２０に含まれなければならない短所がある。すなわち、ＲＵＩサーバー２０は、ＵＰｎＰの被制御装置の機能を実行するが、単にディスプレイメッセージアクションを呼び出すためにＵＰｎＰＣＰの機能を含まなければならないというものである。この場合は、リソースが不足な装置で非效率的であり、ＣＰ機能の追加によって不要なネットワークトラフィックが発生できるという問題が発生する。

本発明は、前記のような問題点を解決するために考案されたものであって、本発明が果そうとする技術的課題は、ＲｅｍｏｔｅＵＩセッションに参与しない第３の装置が自身の状態を他の装置に效果的に知らせて自身のＵＩを表示できるホームネットワークで第３の装置のイベントを処理する方法及び装置を提供することである。

本発明は、前述した目的に制限されず、言及されなかったさらなる目的は、下記の記載から当業者に明確に理解されるであろう。

前述した目的を果たすための本発明によるホームネットワークで第３の装置のイベントを処理する方法は、遠隔プロトコルを用いてＵＩセッションに参与するサーバーとクライアント、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、（ａ）前記制御ポイントが前記ＵＩセッションに参与しない第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを伝送される段階と、（ｂ）前記伝送された制御ポイントが前記ＵＩイベントを処理する目的クライアントを選択する段階と、（ｃ）前記制御ポイントが前記選択された目的クライアントに前記第３の装置との連結を設定させる非セッション連結メッセージ（ＯＯＳＣｏｎｎｅｃｔＡｃｔｉｏｎ）を送る段階と、（ｄ）前記目的クライアントが前記非セッション連結メッセージに対する受諾メッセージを前記制御ポイントに伝送することによって、前記第３の装置と非セッション連結を設定して前記ＵＩイベントを処理する段階と、を含む。

また、前述した目的を果たすための本発明によるホームネットワークで第３の装置のイベントを処理する装置は、遠隔プロトコルを用いてＵＩセッションに参与するサーバーとクライアント、前記ＵＩセッションに参与しない第３の装置、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、前記第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを受信する制御ポイントと、前記受信した制御ポイントによって選択されるクライアントとして、前記ＵＩイベントを処理する目的クライアントを含むが、前記制御ポイントが前記選択された目的クライアントに前記第３の装置との連結を設定させる非セッション連結メッセージを送れば、前記目的クライアントが前記非セッション連結メッセージに対する受諾メッセージを前記制御ポイントに伝送することによって、前記第３の装置と非セッション連結を設定して前記ＵＩイベントと、を処理する。

その他の実施形態の具体的な事項は、詳細な説明及び図面に含まれている。

本発明によれば、ＲｅｍｏｔｅＵＩセッションに参与しない第３の装置が自身の状態を他の装置に效果的に知らせて自身のＵＩを表示できるので、知能型家電製品に対して多様で效率的な使用できる。

本発明の效果は、以上で言及した效果に制限されず、言及されなかったさらなる效果は特許請求の範囲の記載から当業者に明確に理解されるであろう。

本発明の利点及び特徴、そしてそれらの達成方法は、添付図面と共に詳細に後述されている実施形態を参照すれば、明確になる。しかし、本発明は、以下で開示される実施形態に限定されず、相異なる多様な形態で具現でき、単に本実施形態は本発明の開示を完全にし、当業者に発明の範ちゅうを完全に知らせるために提供され、本発明は請求項の範ちゅうにより定義されるだけである。明細書全体に亙って同じ参照符号は、同じ構成要素を指称する。

以下、本発明の望ましい実施形態によってあらかじめ定義されたホームネットワークで第３の装置のイベントを処理する方法及び装置を説明するためのブロック図またはフローチャートを参照してより詳しく説明する。

本発明の実施形態では、説明の便宜上、主にＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）の応用と言えるＵＰｎＰＲｅｍｏｔｅＵｓｅｒＩｎｔｅｒｆａｃｅ（ＲｅｍｏｔｅＵＩ；以下、ＲＵＩで表現する）システムを基盤として敍述するものであり、本発明を具現するための装置も前記ＵＰｎＰＲＵＩスペックに規定された装置の名称を利用するものである。したがって、制御ポイントはＲＵＩ−ＣＰに、被制御装置のうちサーバーはＲＵＩＳｅｒｖｅｒ（ＲＵＩＳ）に、被制御装置のうちクライアントはＲＵＩＣｌｉｅｎｔ（ＲＵＩＣ）に、そして、第３の装置は３^ｒｄｐａｒｔｙＲＵＩＳに表現して説明する。しかし、本発明の権利範囲は、前記のホームネットワークシステムと前記装置の名称に影響を受けないことは当業者に自明であろう。

図３は、本発明の一実施形態による第３の装置のイベントを処理する装置の全体構成を示す図面である。

前記図３を参照すれば、遠隔プロトコルを用いてＵＩセッションに参与しているＲＵＩＳ１（２００＿１）−ＲＵＩＣ１（４００＿１）セットとＲＵＩＳ２（２００＿２）−ＲＵＩＣ２（４００＿２）セットがＵＰｎＰＲＵＩシステムに存在しており、制御ポイントに該当するＲＵＩ−ＣＰ１（１００＿１）とＲＵＩ−ＣＰ２（１００＿２）が前記セットを各々制御している。また、前記ＵＩセッションに参与していないが、前記ＲＵＩ−ＣＰ１（１００＿１）とＲＵＩ−ＣＰ２（１００＿２）との制御を受けながらＵＩイベントを発生させうる“第３の装置”である３^ｒｄｐａｒｔｙＲＵＩＳ（３００＿１）と３^ｒｄｐａｒｔｙＲＵＩＳ（３００＿２）とが存在することによって、ホームネットワークを形成していることが分かる。

前記図３で、被制御装置であるサーバーに該当するＲＵＩＳ１（２００＿１）やＲＵＩＳ２（２００＿２）は、デスクトップＰＣや電話機のようにＵＩイベントを発生させる装置になることができる。また、一つの被制御装置であるクライアントに該当するＲＵＩＣ１（４００＿１）やＲＵＩＣ２（４００＿２）は、前記デスクトップＰＣによって遠隔調整される他の場所のＰＣになるか、前記電話機のベルが鳴っているというイベントをディスプレイできるデジタルＴＶになることができる。そして、前記遠隔プロトコルとは、前記ＲＵＩＳのＵＩイベントを前記ＲＵＩＣが表示できるようにするために前記ＲＵＩＳと前記ＲＵＩＣとをセッションに参与させる規約と言える。その例としては、ＲＤＰ（ＲｅｍｏｔｅＤｅｓｋｔｏｐＰｒｏｔｏｃｏｌ）、ＨＴＴＰ、ＸＨＴなどのプロトコルになることができる。

さて、図４ないし図８を参照して、本発明によるホームネットワークで第３の装置のイベントを処理する方法について説明する。

図４は、本発明の一実施形態による第３の装置のイベント処理方法を示すフローチャートである。

まず、ＲＵＩ−ＣＰ１００が前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請する過程である（Ｓ１１０）。前記過程については、図５を参照して詳しく説明する。前記図５は、制御ポイントがサーバー装置にイベントサブスクリプションを要請する過程を示す図面である。

前記図５を参照すれば、ＲＵＩ−ＣＰ１００がＲＵＩＳ１（２００＿１）にＵＩイベントサブスクリプションを要請して（Ｓ１１１）、前記ＲＵＩＳ１（２００＿１）は、これに対する応答メッセージと初期イベントメッセージとを伝送する（Ｓ１１２、Ｓ１１３）。また、ＲＵＩ−ＣＰ（１００）は、また他のクライアント装置であるＲＵＩＣ２（４００＿２）にも前記と同一な過程を反復する（Ｓ１１４、Ｓ１１５、Ｓ１１６）。

次いで、前記メッセージを受信したＲＵＩ−ＣＰ（１００）は、前記ホームネットワーク内部で発見されたクライアント装置についても情報を収集する（Ｓ１２０）。これについては、図６を参照して詳しく説明する。前記図６は、本発明の一実施形態による制御ポイントがクライアント装置についての情報を収集する過程を示す図面である。

前記図６を参照すれば、先にＲＵＩ−ＣＰ（１００）がＲＵＩＣ１（４００＿１）にＲＵＩＣ１（４００＿１）についての情報を要請して（Ｓ１２１）、前記要請されたＲＵＩＣ１（４００＿１）は、これに対する自身の情報を提供する（Ｓ１２２）。前記情報を提供されたＲＵＩ−ＣＰ（１００）は、前記情報を貯蔵する（Ｓ１２３）。そして、前記ＲＵＩ−ＣＰ（１００）は、また他のクライアント装置であるＲＵＩＣ２（４００＿２）に対しても前記と同一な過程を反復するので説明を省略する（Ｓ１２４、Ｓ１２５、Ｓ１２６）。前記図６の過程でのクライアント装置についての情報は、前記クライアント装置が支援する遠隔プロトコル（ＲｅｍｏｔｅＰｒｏｔｏｃｏｌ）情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報（ＯｕｔＯｆＳｅｓｓｉｏｎＣａｐａＩｎｆｏ；以下、ＯＯＳＣａｐａＩｎｆｏと言う）を含む。

前記ＲＵＩ−ＣＰ（１００）が被制御装置であるクライアント装置についての情報を有している状態で、前記セッションに参与していない第３の装置が自身の状態変更を表わすＵＩイベントメッセージを発生させる。それにより、前記ＲＵＩ−ＣＰ（１００）が前記第３の装置が発生させるＵＩイベントメッセージを伝送されて、これに対する応答メッセージを送る（Ｓ１３０）。これについての詳細な説明は図７を参照する。

図７は、制御ポイントが第３の装置からＵＩイベントメッセージを受信して、ＵＩイベントを処理する目的クライアントを選択する過程を示す図面である。

前記ＲＵＩＳ（２００）とＲＵＩＣ（４００）の間のＵＩセッションに参与していないまた他のサーバー装置に該当する３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が或る時点で自身の状態を変更するようになる場合（Ｓ１３１）、前記状態変更の事実を知らせるイベントメッセージを発生させて前記ＲＵＩ−ＣＰ１（１００＿１）に伝送する（Ｓ１３２）。前記伝送されたＲＵＩ−ＣＰ１（１００＿１）は、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）に応答メッセージを伝送する（Ｓ１３３）。例えば、ガスを利用した電気装置が前記第３の装置である３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）である場合を考えて見る。前記ガスを利用した電気装置のガスバルブが開かれるイベントが発生した場合、これをユーザーに緊急に知らせるためにＲＵＩ−ＣＰ１（１００＿１）に前記ガスバルブが開かれたというイベントメッセージを伝送する。

ＲＵＩ−ＣＰ１（１００＿１）は、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が支援する遠隔プロトコルの情報を得るためにＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓＡｃｔｉｏｎを要請して（Ｓ１３４）、前記要請を受けた３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）は、前記ＣｏｍｐａｔｉｂｌｅＵＩｓＡｃｔｉｏｎを提供することによって、自身が支援する遠隔プロトコルの情報をＲＵＩ−ＣＰ１（１００＿１）に提供する（Ｓ１３５）。ＲＵＩ−ＣＰ１（１００＿１）は、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が支援する遠隔プロトコルの情報を貯蔵しておいて、Ｓ１４０過程で前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）のＵＩイベントを処理することができるクライアントを選択する過程に利用されるところ、これについての説明はＳ１４０過程で後述する。

また、また他の制御ポイント装置であるＲＵＩ−ＣＰ２（１００＿２）が前記第３の装置である３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）の状態変更に対してＵＩイベントメッセージを伝送されることもできる。この場合は、前記Ｓ１３２ないしＳ１３５過程と同一な過程がＲＵＩ−ＣＰ２（１００＿２）と３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）の間で発生する（Ｓ１３６、Ｓ１３７、Ｓ１３８、Ｓ１３９）。ところが、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が発生させるＵＩイベントメッセージは、前記Ｓ１１０段階でのＵＩイベントサブスクリプションを要請した制御ポイントにのみ伝送されなければならない。前記ＵＩイベントサブスクリプションを要請しない制御ポイントにまで前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が自身の状態変更を敢えて知らせる必要がないためである。

前記ＵＩイベントメッセージには、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）の固有識別子（ＵＤＮ）情報及び前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報（ＵＩＥｖｅｎｔＳｅｑｕｅｎｃｅ）を含むが、前記イベントシーケンス情報は、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）の状態が変更されてＵＩイベントが発生する度に一つずつ増加する。前記固有識別子情報は、ＵＩイベントメッセージを伝送する第３の装置が二つ以上である場合に、これを区分するために使われるものである。また、前記イベントシーケンス情報は、一つの同一な第３の装置が連続的にＵＩイベントを発生させて制御ポイントに伝送する場合、これを受信したいくつかのＲＵＩ−ＣＰ（１００）装置が一つのＲＵＩＣ（４００）装置に前記ＵＩイベントを処理することができるか否かを要請すれば、前記ＲＵＩＣ（４００）装置は、同一なＵＩイベントを重複して処理する可能性が生ずるので、このような可能性を防止するためである。

前記のような図７の過程を経た制御ポイントは、前記Ｓ１２０過程で収集して貯蔵した前記ＯＯＳＣａｐａＩｎｆｏ（第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報）を用いて前記ＵＩイベントを処理することができる与件を有するクライアントを一つ以上選択する。ここで、前記ＯＯＳＣａｐａＩｎｆｏは、三つの状況についての情報を含みうるが、前記ＵＩイベントをいつも処理できるという情報、前記クライアントが遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことができる。しかし、このような三つの情報に分類することは一つの実施形態に過ぎないだけであり、もっと多い場合の状況についての情報を含みうる。

制御ポイント装置であるＲＵＩ−ＣＰ（１００）は、前記選択された一つ以上のクライアントの中で前記ＵＩイベントを処理することができるクライアント（ＴａｒｇｅｔＣｌｉｅｎｔ；以下、目的クライアントと称する）を選択する（Ｓ１４０）。この際、前記Ｓ１２０過程で収集されたクライアントについての情報のうち遠隔プロトコル情報と前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が支援する遠隔プロトコル情報とを比べて、マッチングされるクライアントを最終の目的クライアントに選択する。

制御ポイントは、前記のような過程を経て選択された目的クライアントに前記第３の装置が発生させたＵＩイベントを処理するために前記第３の装置との連結を設定するように要請するメッセージ（ＯｕｔＯｆＳｅｓｓｉｏｎＣｏｎｎｅｃｔＡｃｔｉｏｎ；ＯＯＳＣｏｎｎｅｃｔＡｃｔｉｏｎ、以下、非セッション連結メッセージと称する）を伝送する（Ｓ１５０）。これについての詳細な過程は、図８を参照して説明する。前記図８は、本発明の一実施形態による制御ポイントが目的クライアントにＯＯＳＣｏｎｎｅｃｔＡｃｔｉｏｎを要請する過程を示す図面である。

前記図８を参照すれば、目的クライアントに該当するＴａｒｇｅｔＲＵＩＣ（４００）は、ＲＵＩＳ２（２００＿２）とすでに遠隔プロトコル（ＯｕｔＯｆＢａｎｄプロトコル）を用いてＲＵＩセッションに参与している状態であることが分かる。前記選択されたＴａｒｇｅｔＲＵＩＣ（４００）は、すでに他のサーバーであるＲＵＩＳ２（２００＿２）とＲｅｍｏｔｅＵＩセッションとを進行しているとしても新しい非セッション連結を設定できるところ、これについて説明する。

前記ＲＵＩ−ＣＰ１（１００＿１）が前記選択されたＴａｒｇｅｔＲＵＩＣ（４００）に前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記非セッション連結メッセージに載せて送る（Ｓ１５１）。前記ＴａｒｇｅｔＲＵＩＣ（４００）は、前記非セッション連結メッセージを受信して、前記固有識別子情報及び前記イベントシーケンス情報を貯蔵する（Ｓ１５２）。前記情報を貯蔵する理由は、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）から同一なＵＩイベントを受信した他の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）が同一なＲＵＩＣ（４００）に前記ＵＩイベントの処理のための非セッション連結を要請することによって、重複された処理を防止するためである。

したがって、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）が伝送した一つのＵＩイベントメッセージに対して最初に非セッション連結を実行したＴａｒｇｅｔＲＵＩＣ（４００）は、また他の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）が同一な非セッション連結要請をしたか否かを確認するために、前記貯蔵された固有識別子情報と前記イベントシーケンス情報とを比べる。比較結果、前記値が一致していない場合には、前記ＴａｒｇｅｔＲＵＩＣ（４００）は、ＲＵＩ−ＣＰ１（１００＿１）に受諾する応答メッセージを送り（Ｓ１５３）、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）とＲＵＩセッションを新しく形成する（Ｓ１５４）。

もし、前記ＴａｒｇｅｔＲＵＩＣ（４００）が、また他の第２の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）から同一な内容の第２の非セッション連結要請を受信した場合（Ｓ１５５）、前記第２の非セッション連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報とを前記Ｓ１５２過程で貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析する（Ｓ１５６）。

前記比較分析の結果、前記固有識別子情報及びイベントシーケンス情報が同一である場合には、すでに処理されたというメッセージをＲＵＩ−ＣＰ２（１００＿２）に伝送する。すでに同一なＵＩイベントに対する非セッション連結要請を受信して、前記３^ｒｄｐａｒｔｙＲＵＩＳ１（３００＿１）のＵＩイベントを処理した状態なので、前記識別子情報及び前記イベントシーケンス情報が同一であるためである。したがって、前記ＴａｒｇｅｔＲＵＩＣ（４００）は、拒否のメッセージをＲＵＩ−ＣＰ２（１００＿２）に送りながらすでに前記ＵＩイベントが処理されたというメッセージを伝達する（Ｓ１５７）。

一方、本発明の実施形態によるホームネットワークで第３の装置のイベントを処理する装置の権利範囲は、前記のような方法をコンピュータで実行するためのプログラムコードを記録したコンピュータで読取り可能な記録媒体にも及ぶということは当業者に自明である。

以上、添付された図面を参照して、本発明の実施形態を説明したが、当業者ならば本発明の技術的思想や必須な特徴を外れない範囲内でいろいろに置き換え、変形及び変更が可能なので、他の具体的な形態に実施されるということを理解できるであろう。したがって、前述した実施形態は、あらゆる面で例示的なものであり、限定的ではないということを理解せねばならない。本発明の範囲は、前記詳細な説明よりは後述する特許請求の範囲によって表され、特許請求の範囲の意味及び範囲、そして、その均等概念から導出されるすべての変更または変形された形態が本発明の範囲に含まれると解釈されなければならない。

本発明は、ホームネットワークでのイベンティング処理技術分野に適用されうる。

従来技術によるＵＰｎＰでのイベンティング過程を示す図面である。従来技術によるＵＰｎＰＲｅｍｏｔｅＵＩシステムの構成を示す図である。本発明の一実施形態による第３の装置のイベントを処理する装置の全体構成を示す図である。本発明の一実施形態による第３の装置のイベント処理方法を示すフローチャートである。本発明の一実施形態による制御ポイントがサーバー装置にイベントサブスクリプションを要請する過程を示す図である。本発明の一実施形態による制御ポイントがクライアント装置についての情報を収集する過程を示す図である。本発明の一実施形態による制御ポイントが第３の装置からＵＩイベントメッセージを受信してＵＩイベントを処理する目的クライアントを選択する過程を示す図である。本発明の一実施形態による制御ポイントが目的クライアントにＯＯＳＣｏｎｎｅｃｔＡｃｔｉｏｎを要請する過程を示す図である。

符号の説明

１００ＲＵＩ制御ポイント
２００ＲＵＩサーバー
３００第３の装置
４００ＲＵＩクライアント

Claims

遠隔プロトコルを用いてＵＩセッションが形成されているサーバーとクライアント、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、
（ａ）前記制御ポイントが、前記サーバーとクライアントとの前記ＵＩセッションが形成されていない第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを伝送される段階と、
（ｂ）前記伝送された制御ポイントが前記ＵＩイベントを処理する目的クライアントを選択する段階と、
（ｃ）前記制御ポイントが、前記選択された目的クライアントに、前記第３の装置との連結を設定要請する連結メッセージを送る段階と、
（ｄ）前記目的クライアントが前記連結メッセージに対する受諾メッセージを前記制御ポイントに伝送するとともに、前記目的クライアントが前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理する段階と、を含むことを特徴とするホームネットワークで第３の装置のイベントを処理する方法。
前記（ａ）段階は、
（ａ１）前記制御ポイントが前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請して、これに対する応答メッセージと初期イベントメッセージとを受信する段階と、
（ａ２）前記受信した制御ポイントが前記ホームネットワーク内部で発見されたクライアントについての情報を収集する段階と、
（ａ３）前記収集した制御ポイントが前記第３の装置の状態変更を表わす前記ＵＩイベントメッセージを伝送されて、これに対する応答メッセージを伝送する段階と、を含むことを特徴とする請求項１に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記（ａ２）段階でのクライアントについての情報は、
前記クライアントが支援する遠隔プロトコル情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報を含むことを特徴とする請求項２に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記ＵＩイベントメッセージは、
前記第３の装置の固有識別子（ＵＤＮ）情報及び前記第３の装置が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報を含み、
前記イベントシーケンス情報は、前記第３の装置の状態が変更されてＵＩイベントが発生する度に一つずつ増加することを特徴とする請求項２に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記（ｂ）段階は、
前記（ａ２）段階で収集されたクライアントについての情報のうち遠隔プロトコル情報と前記第３の装置が支援する遠隔プロトコル情報とを比べることによって、前記目的クライアントを選択する段階を含むことを特徴とする請求項３に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記ＵＩイベントを処理できるか否かを表わす情報は、
前記ＵＩイベントをいつも処理できるという情報、前記クライアントの遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことを特徴とする請求項３に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記（ｃ）段階は、
（ｃ１）前記制御ポイントが前記選択された目的クライアントに前記第３の装置の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記連結メッセージに載せて送る段階と、
（ｃ２）前記目的クライアントが前記固有識別子情報及び前記イベントシーケンス情報を貯蔵する段階と、を含むことを特徴とする請求項４に記載のホームネットワークで第３の装置のイベントを処理する方法。
前記（ｄ）段階は，
前記目的クライアントが前記ＵＩイベントメッセージを伝送される第２の制御ポイントから第２の連結メッセージを受信する場合、
（ｄ１）前記第２の連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報を前記（ｃ２）段階で貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析する段階と、
（ｄ２）前記比較分析の結果、前記固有識別子情報及びイベントシーケンス情報が同一である場合には、すでに処理されたというメッセージを前記第２の制御ポイントに伝送し、同一ではない場合には、前記受諾メッセージを前記第２の制御ポイントに伝送することによって、前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理する段階と、を含むことを特徴とする請求項７に記載のホームネットワークで第３の装置のイベントを処理する方法。
遠隔プロトコルを用いてＵＩセッションが形成されているサーバーとクライアント、前記ＵＩセッションに参与しない第３の装置、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、
前記サーバーとクライアントとの前記ＵＩセッションが形成されていない前記第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを受信する制御ポイントと、
前記受信した制御ポイントによって選択されるクライアントとして、前記ＵＩイベントを処理する目的クライアントを含むが、
前記制御ポイントが、前記選択された目的クライアントに、前記第３の装置との連結を設定要請する連結メッセージを送れば、前記目的クライアントが前記連結メッセージに対する受諾メッセージを前記制御ポイントに伝送するとともに、前記目的クライアントが前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理することを特徴とするホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記制御ポイントは、
前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請して、これに対する応答メッセージと初期イベントメッセージとを受信し、前記クライアントについての情報を収集することを特徴とする請求項９に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記クライアントについての情報は、
前記クライアントが支援する遠隔プロトコル情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報を含むことを特徴とする請求項１０に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記ＵＩイベントメッセージは、
前記第３の装置の固有識別子（ＵＤＮ）情報及び前記第３の装置が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報を含み、
前記イベントシーケンス情報は、前記第３の装置の状態が変更されてＵＩイベントが発生する度に一つずつ増加することを特徴とする請求項１０に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記制御ポイントは、
前記収集されたクライアントについての情報のうち遠隔プロトコル情報と前記第３の装置が支援する遠隔プロトコル情報とを比べることによって、前記目的クライアントを選択することを特徴とする請求項１１に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記ＵＩイベントを処理できるか否かを表わす情報は、
前記ＵＩイベントをいつも処理できるという情報、前記クライアントが遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことを特徴とする請求項１１に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記制御ポイントは、
前記選択された目的クライアントに前記第３の装置の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記連結メッセージに載せて送り、
前記目的クライアントは、前記固有識別子情報及び前記イベントシーケンス情報を貯蔵することを特徴とする請求項１２に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
前記目的クライアントは、
前記目的クライアントが前記ＵＩイベントメッセージを伝送される第２の制御ポイントから第２の連結メッセージを受信する場合、
前記第２の連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報を前記貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析して、前記比較分析の結果、同一である場合には、すでに処理されたというメッセージを前記第２の制御ポイントに伝送し、同一ではない場合には、前記受諾メッセージを前記第２の制御ポイントに伝送することによって、前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理することを特徴とする請求項１５に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
請求項１ないし請求項８のうち、何れか一項の方法をコンピュータで実行するためのプログラムコードを記録したコンピュータで読取り可能な記録媒体。