(57)【特許請求の範囲】
【請求項１】
遠隔プロトコルを用いてＵＩセッションが形成されているサーバーとクライアント、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、
（ａ）前記制御ポイントが、前記サーバーとクライアントとの前記ＵＩセッションが形成されていない第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを伝送される段階と、
（ｂ）前記伝送された制御ポイントが前記ＵＩイベントを処理する目的クライアントを選択する段階と、
（ｃ）前記制御ポイントが、前記選択された目的クライアントに、前記第３の装置との連結を設定要請する連結メッセージを送る段階と、
（ｄ）前記目的クライアントが前記連結メッセージに対する受諾メッセージを前記制御ポイントに伝送するとともに、前記目的クライアントが前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理する段階と、を含むことを特徴とするホームネットワークで第３の装置のイベントを処理する方法。
【請求項２】
前記（ａ）段階は、
（ａ１）前記制御ポイントが前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請して、これに対する応答メッセージと初期イベントメッセージとを受信する段階と、
（ａ２）前記受信した制御ポイントが前記ホームネットワーク内部で発見されたクライアントについての情報を収集する段階と、
（ａ３）前記収集した制御ポイントが前記第３の装置の状態変更を表わす前記ＵＩイベントメッセージを伝送されて、これに対する応答メッセージを伝送する段階と、を含むことを特徴とする請求項１に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項３】
前記（ａ２）段階でのクライアントについての情報は、
前記クライアントが支援する遠隔プロトコル情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報を含むことを特徴とする請求項２に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項４】
前記ＵＩイベントメッセージは、
前記第３の装置の固有識別子（ＵＤＮ）情報及び前記第３の装置が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報を含み、
前記イベントシーケンス情報は、前記第３の装置の状態が変更されてＵＩイベントが発生する度に一つずつ増加することを特徴とする請求項２に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項５】
前記（ｂ）段階は、
前記（ａ２）段階で収集されたクライアントについての情報のうち遠隔プロトコル情報と前記第３の装置が支援する遠隔プロトコル情報とを比べることによって、前記目的クライアントを選択する段階を含むことを特徴とする請求項３に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項６】
前記ＵＩイベントを処理できるか否かを表わす情報は、
前記ＵＩイベントをいつも処理できるという情報、前記クライアントの遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことを特徴とする請求項３に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項７】
前記（ｃ）段階は、
（ｃ１）前記制御ポイントが前記選択された目的クライアントに前記第３の装置の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記連結メッセージに載せて送る段階と、
（ｃ２）前記目的クライアントが前記固有識別子情報及び前記イベントシーケンス情報を貯蔵する段階と、を含むことを特徴とする請求項４に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項８】
前記（ｄ）段階は，
前記目的クライアントが前記ＵＩイベントメッセージを伝送される第２の制御ポイントから第２の連結メッセージを受信する場合、
（ｄ１）前記第２の連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報を前記（ｃ２）段階で貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析する段階と、
（ｄ２）前記比較分析の結果、前記固有識別子情報及びイベントシーケンス情報が同一である場合には、すでに処理されたというメッセージを前記第２の制御ポイントに伝送し、同一ではない場合には、前記受諾メッセージを前記第２の制御ポイントに伝送することによって、前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理する段階と、を含むことを特徴とする請求項７に記載のホームネットワークで第３の装置のイベントを処理する方法。
【請求項９】
遠隔プロトコルを用いてＵＩセッションが形成されているサーバーとクライアント、前記ＵＩセッションに参与しない第３の装置、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、
前記サーバーとクライアントとの前記ＵＩセッションが形成されていない前記第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを受信する制御ポイントと、
前記受信した制御ポイントによって選択されるクライアントとして、前記ＵＩイベントを処理する目的クライアントを含むが、
前記制御ポイントが、前記選択された目的クライアントに、前記第３の装置との連結を設定要請する連結メッセージを送れば、前記目的クライアントが前記連結メッセージに対する受諾メッセージを前記制御ポイントに伝送するとともに、前記目的クライアントが前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理することを特徴とするホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１０】
前記制御ポイントは、
前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請して、これに対する応答メッセージと初期イベントメッセージとを受信し、前記クライアントについての情報を収集することを特徴とする請求項９に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１１】
前記クライアントについての情報は、
前記クライアントが支援する遠隔プロトコル情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報を含むことを特徴とする請求項１０に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１２】
前記ＵＩイベントメッセージは、
前記第３の装置の固有識別子（ＵＤＮ）情報及び前記第３の装置が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報を含み、
前記イベントシーケンス情報は、前記第３の装置の状態が変更されてＵＩイベントが発生する度に一つずつ増加することを特徴とする請求項１０に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１３】
前記制御ポイントは、
前記収集されたクライアントについての情報のうち遠隔プロトコル情報と前記第３の装置が支援する遠隔プロトコル情報とを比べることによって、前記目的クライアントを選択することを特徴とする請求項１１に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１４】
前記ＵＩイベントを処理できるか否かを表わす情報は、
前記ＵＩイベントをいつも処理できるという情報、前記クライアントが遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことを特徴とする請求項１１に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１５】
前記制御ポイントは、
前記選択された目的クライアントに前記第３の装置の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記連結メッセージに載せて送り、
前記目的クライアントは、前記固有識別子情報及び前記イベントシーケンス情報を貯蔵することを特徴とする請求項１２に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１６】
前記目的クライアントは、
前記目的クライアントが前記ＵＩイベントメッセージを伝送される第２の制御ポイントから第２の連結メッセージを受信する場合、
前記第２の連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報を前記貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析して、前記比較分析の結果、同一である場合には、すでに処理されたというメッセージを前記第２の制御ポイントに伝送し、同一ではない場合には、前記受諾メッセージを前記第２の制御ポイントに伝送することによって、前記第３の装置とＵＩセッションを形成して連結を設定し、前記ＵＩイベントを処理することを特徴とする請求項１５に記載のホームネットワークで第３の装置のイベントを処理する制御ポイント及び目的クライアントからなるシステム。
【請求項１７】
請求項１ないし請求項８のうち、何れか一項の方法をコンピュータで実行するためのプログラムコードを記録したコンピュータで読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホームネットワークでのイベンティング処理技術に係り、より詳細には、ホームネットワークでのＵＩセッションに属しない第３の装置のイベントを他の装置で処理できるようにするホームネットワークで第３の装置のイベントを処理する方法及び装置に関する。
【背景技術】
【０００２】
一般的に、ホームネットワークは、インターネットプロトコル（以下、ＩＰと称する）基盤の私設網（プライベートネットワーク）からなるものであって、家庭内で使われるすべての形態の個人コンピュータ（ＰＣ）と知能型製品、無線装置などの多様な機器をミドルウェア（ｍｉｄｄｌｅｗａｒｅ）と呼ばれる共通の仮想コンピューティング環境を通じて一つのネットワークに連結して統制するものである。
【０００３】
ミドルウェアとは、多様なデジタル機器をピアツーピア（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）方式で連結して機器間の通信を可能にするものであって、ＨＡＶＩ（Ｈｏｍｅ  ＡＶ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）、Ｊｉｎｉ（Ｊａｖａ（登録商標）Ｉｎｔｅｌｌｉｇｅｎｔ  Ｎｅｔｗｏｒｋ  Ｉｎｆｒａ−ｓｔｒｕｃｔｕｒｅ）、ＨＷＷ（Ｈｏｍｅ  Ｗｉｄｅ  Ｗｅｂ）などが現在まで提案されている。
【０００４】
この中、ＵＰｎＰミドルウェアを通じて構築されるコンピューティング環境で各機器は、動的ホスト構成規約（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ；ＤＨＣＰ）によってサーバーから割り当てられるか、自動ＩＰ指定機能（Ａｕｔｏ  ＩＰ）によって選択されるアドレスを割り当てられ、これを通じて各機器間の通信及びネットワーク上での検索／照会を実行する。
【０００５】
ＵＰｎＰネットワークは、近い未来にもっとも多く活用される可能性が高いホームネットワーク技術であって、ＵＰｎＰデバイスとＵＰｎＰサービス（ｓｅｒｖｉｃｅ）を定義して、これらの間のプロトコルによって定義している。ＵＰｎＰネットワークは、ＩＰ基盤のホームネットワークに連結されて制御されるホームネットワーク機器である被制御装置（Ｃｏｎｔｒｏｌｌｅｄ  Ｄｅｖｉｃｅ：ＣＤ）と、これら被制御装置を制御するための機器である制御ポイント（Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ：ＣＰ）として構成される。前記制御ポイントは、被制御装置に対する制御を実行する装置であって、イベントを要請してイベントを受信する構成要素である。前記被制御装置は、前記制御ポイントの要請によって決まった機能を実行する装置であって、被制御装置の状態（ｓｔａｔｅ）が変更されれば、イベントを要請した制御ポイントに前記イベントを送る構成要素である。
【０００６】
従来のＵＰｎＰネットワークの機器間の各段階別動作過程を見ると、ディスカバリーアドバタイズメント（ｄｉｓｃｏｖｅｒｙ−ａｄｖｅｒｔｉｓｅｍｅｎｔ）過程、デスクリプション（Ｄｅｓｃｒｉｐｔｉｏｎ）過程、制御（Ｃｏｎｔｒｏｌ）過程、及びイベンティング（ｅｖｅｎｔｉｎｇ）過程からなりうる。
【０００７】
ディスカバリーアドバタイズメント過程は、新しい被制御装置がホームネットワークに連結されてホームネットワーク上の他のデバイスに自身を知らせるアドバタイズメント過程と、新しい制御ポイントがホームネットワークに連結されてホームネットワーク上で動作する被制御装置を検索（サーチ）するディスカバリー過程を含む。
【０００８】
デスクリプション過程は、制御ポイントが被制御装置を制御するためにディスカバリーアドバタイズメント過程で得られた被制御装置のＩＰアドレスを通じてサービスデスクリプションＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ファイルまたはデバイスデスクリプションＸＭＬファイルをパーシング（Ｐａｒｓｉｎｇ）して新たに追加されたデバイスの機能をより詳しく把握する過程である。
【０００９】
制御過程は、制御ポイントが被制御装置を通じて特定サービスを提供しようとする場合、ＵＰｎＰデバイスアーキテクチャーによってＳＯＡＰを利用して所定のサービスを要請する制御メッセージ（アクションリクエスト）を該当被制御装置に伝送して、これに対する応答メッセージ（ｒｅｓｕｌｔ、ｖａｒｉａｂｌｅ  ｖａｌｕｅ）を受信する過程である。
【００１０】
イベンティング過程は、制御ポイントから伝送される制御命令によって所定のサービスを提供した被制御装置の情報変更状態を確認する過程であって、図１を参照してイベンティング過程を説明する。
【００１１】
前記図１を参照すれば、制御ポイントと被制御装置が１：１の関係を成しながらイベンティング過程を実行することが分かる。まず、制御ポイントが被制御装置の情報変更状態を確認するためにサブスクリプションを要請するメッセージ（サブスクリプションリクエスト）を被制御装置のサービスに伝送すれば、被制御装置のサービスでは変更された情報を知らせるためにＧＥＮＡ（Ｇｅｎｅｒｉｃ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）を通じてフォーマットされたＸＭＬ形態のイベントメッセージを前記制御ポイントに送信する。制御ポイントでは、被制御装置から伝送されたイベントメッセージを受信して、被制御装置に対するデスクリプションアップデート項目として処理する。もし、ｓｕｂｓｃｒｉｂｅ期間が満了したが、制御ポイントがさらにイベントの受信を希望する時は、また、被制御装置のサービスに更新要請（リニューアルリクエスト）メッセージを送ってサブスクリプション期間の延長を要請する。これにより、前記サービスは、新しいサブスクリプション期間を明示してサブスクリプションを許容する。制御ポイントがこれ以上イベントの受信を願わない時は、被制御装置のサービスにアンサブスクライブメッセージを送ってサブスクリプションを取り消し（キャンセル）できる。
【００１２】
一方、図２は、従来のＵＰｎＰ  Ｒｅｍｏｔｅ  ＵＩで提案するイベンティング過程を示す図面である。まず、制御ポイント１０が被制御装置に該当するＲＵＩサーバー２０とＲＵＩクライアント３０にプロトコル情報を獲得する（Ｓ１１）。また、制御ポイント１０は、ＲＵＩサーバー２０がＲＵＩクライアント３０を通じて提供できるすべての有用なＵＩ情報を獲得した後（Ｓ１２）、ＲＵＩクライアント３０を通じて出力しようとする適切なＵＩを選択する（Ｓ１３）。そして、ＲＵＩクライアント３０と連結して前記選択したＵＩの出力を要請して（Ｓ１４）、前記要請を受けたＲＵＩクライアント３０は、ＲＵＩサーバー２０とＯｕｔ  ｏｆ  Ｂａｎｄプロトコルを形成して前記ＵＩ情報を出力する（Ｓ１５）。
【００１３】
一般的に、被制御装置の状態が変更されれば、制御ポイントにイベントメッセージを伝送して状態が変更されることを知らせる。しかし、前記のようなＵＰｎＰ  Ｒｅｍｏｔｅ  ＵＩでは、ＵＰｎＰプロトコルで定義されたイベント以外にＲＵＩサーバー２０のＵＩ状態が変更されれば、これを反映するＲＵＩクライアント３０に知らせる手段は、二つの装置２０、３０の間のリモートプロトコルによってのみ可能である。これは二つの装置２０、３０の間に結ばれたリモートプロトコルセッションが進行中である場合にのみ可能である。
【００１４】
ところが、もし、第３の装置が存在して或る自身の状態を知らせようとする場合には、既存のリモートＵＩ方法ではカバーしにくい。実際に、ＵＰｎＰ  Ｒｅｍｏｔｅ  ＵＩスペックでは、このような短所を克服するためにディスプレイメッセージアクションを提供するが、前記アクションは、ＣＰ機能を実行する装置がＲＵＩサーバー２０に含まれなければならない短所がある。すなわち、ＲＵＩサーバー２０は、ＵＰｎＰの被制御装置の機能を実行するが、単にディスプレイメッセージアクションを呼び出すためにＵＰｎＰ  ＣＰの機能を含まなければならないというものである。この場合は、リソースが不足な装置で非效率的であり、ＣＰ機能の追加によって不要なネットワークトラフィックが発生できるという問題が発生する。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明は、前記のような問題点を解決するために考案されたものであって、本発明が果そうとする技術的課題は、ＲｅｍｏｔｅＵＩセッションに参与しない第３の装置が自身の状態を他の装置に效果的に知らせて自身のＵＩを表示できるホームネットワークで第３の装置のイベントを処理する方法及び装置を提供することである。
【００１６】
本発明は、前述した目的に制限されず、言及されなかったさらなる目的は、下記の記載から当業者に明確に理解されるであろう。
【課題を解決するための手段】
【００１７】
前述した目的を果たすための本発明によるホームネットワークで第３の装置のイベントを処理する方法は、遠隔プロトコルを用いてＵＩセッションに参与するサーバーとクライアント、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、（ａ）前記制御ポイントが前記ＵＩセッションに参与しない第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを伝送される段階と、（ｂ）前記伝送された制御ポイントが前記ＵＩイベントを処理する目的クライアントを選択する段階と、（ｃ）前記制御ポイントが前記選択された目的クライアントに前記第３の装置との連結を設定させる非セッション連結メッセージ（ＯＯＳＣｏｎｎｅｃｔ  Ａｃｔｉｏｎ）を送る段階と、（ｄ）前記目的クライアントが前記非セッション連結メッセージに対する受諾メッセージを前記制御ポイントに伝送することによって、前記第３の装置と非セッション連結を設定して前記ＵＩイベントを処理する段階と、を含む。
【００１８】
また、前述した目的を果たすための本発明によるホームネットワークで第３の装置のイベントを処理する装置は、遠隔プロトコルを用いてＵＩセッションに参与するサーバーとクライアント、前記ＵＩセッションに参与しない第３の装置、及び前記サーバーとクライアントを制御する制御ポイントを含むホームネットワークにおいて、前記第３の装置から前記第３の装置の状態変更を表わすＵＩイベントメッセージを受信する制御ポイントと、前記受信した制御ポイントによって選択されるクライアントとして、前記ＵＩイベントを処理する目的クライアントを含むが、前記制御ポイントが前記選択された目的クライアントに前記第３の装置との連結を設定させる非セッション連結メッセージを送れば、前記目的クライアントが前記非セッション連結メッセージに対する受諾メッセージを前記制御ポイントに伝送することによって、前記第３の装置と非セッション連結を設定して前記ＵＩイベントと、を処理する。
【００１９】
その他の実施形態の具体的な事項は、詳細な説明及び図面に含まれている。
【発明の効果】
【００２０】
本発明によれば、ＲｅｍｏｔｅＵＩセッションに参与しない第３の装置が自身の状態を他の装置に效果的に知らせて自身のＵＩを表示できるので、知能型家電製品に対して多様で效率的な使用できる。
【００２１】
本発明の效果は、以上で言及した效果に制限されず、言及されなかったさらなる效果は特許請求の範囲の記載から当業者に明確に理解されるであろう。
【発明を実施するための最良の形態】
【００２２】
本発明の利点及び特徴、そしてそれらの達成方法は、添付図面と共に詳細に後述されている実施形態を参照すれば、明確になる。しかし、本発明は、以下で開示される実施形態に限定されず、相異なる多様な形態で具現でき、単に本実施形態は本発明の開示を完全にし、当業者に発明の範ちゅうを完全に知らせるために提供され、本発明は請求項の範ちゅうにより定義されるだけである。明細書全体に亙って同じ参照符号は、同じ構成要素を指称する。
【００２３】
以下、本発明の望ましい実施形態によってあらかじめ定義されたホームネットワークで第３の装置のイベントを処理する方法及び装置を説明するためのブロック図またはフローチャートを参照してより詳しく説明する。
【００２４】
本発明の実施形態では、説明の便宜上、主にＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）の応用と言えるＵＰｎＰ  Ｒｅｍｏｔｅ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ（Ｒｅｍｏｔｅ  ＵＩ；以下、ＲＵＩで表現する）システムを基盤として敍述するものであり、本発明を具現するための装置も前記ＵＰｎＰ  ＲＵＩスペックに規定された装置の名称を利用するものである。したがって、制御ポイントはＲＵＩ−ＣＰに、被制御装置のうちサーバーはＲＵＩ  Ｓｅｒｖｅｒ（ＲＵＩＳ）に、被制御装置のうちクライアントはＲＵＩ  Ｃｌｉｅｎｔ（ＲＵＩＣ）に、そして、第３の装置は３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ  に表現して説明する。しかし、本発明の権利範囲は、前記のホームネットワークシステムと前記装置の名称に影響を受けないことは当業者に自明であろう。
【００２５】
図３は、本発明の一実施形態による第３の装置のイベントを処理する装置の全体構成を示す図面である。
【００２６】
前記図３を参照すれば、遠隔プロトコルを用いてＵＩセッションに参与しているＲＵＩＳ１（２００＿１）−ＲＵＩＣ１（４００＿１）セットとＲＵＩＳ２（２００＿２）−ＲＵＩＣ２（４００＿２）セットがＵＰｎＰ  ＲＵＩシステムに存在しており、制御ポイントに該当するＲＵＩ−ＣＰ１（１００＿１）とＲＵＩ−ＣＰ２（１００＿２）が前記セットを各々制御している。また、前記ＵＩセッションに参与していないが、前記ＲＵＩ−ＣＰ１（１００＿１）とＲＵＩ−ＣＰ２（１００＿２）との制御を受けながらＵＩ  イベントを発生させうる“第３の装置”である３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ（３００＿１）と３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ（３００＿２）とが存在することによって、ホームネットワークを形成していることが分かる。
【００２７】
前記図３で、被制御装置であるサーバーに該当するＲＵＩＳ１（２００＿１）やＲＵＩＳ２（２００＿２）は、デスクトップＰＣや電話機のようにＵＩイベントを発生させる装置になることができる。また、一つの被制御装置であるクライアントに該当するＲＵＩＣ１（４００＿１）やＲＵＩＣ２（４００＿２）は、前記デスクトップＰＣによって遠隔調整される他の場所のＰＣになるか、前記電話機のベルが鳴っているというイベントをディスプレイできるデジタルＴＶになることができる。そして、前記遠隔プロトコルとは、前記ＲＵＩＳのＵＩイベントを前記ＲＵＩＣが表示できるようにするために前記ＲＵＩＳと前記ＲＵＩＣとをセッションに参与させる規約と言える。その例としては、ＲＤＰ（Ｒｅｍｏｔｅ  Ｄｅｓｋｔｏｐ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ、ＸＨＴなどのプロトコルになることができる。
【００２８】
さて、図４ないし図８を参照して、本発明によるホームネットワークで第３の装置のイベントを処理する方法について説明する。
【００２９】
図４は、本発明の一実施形態による第３の装置のイベント処理方法を示すフローチャートである。
【００３０】
まず、ＲＵＩ−ＣＰ１００が前記ホームネットワーク内部で発見されたサーバーに対してＵＩイベントサブスクリプションを要請する過程である（Ｓ１１０）。前記過程については、図５を参照して詳しく説明する。前記図５は、制御ポイントがサーバー装置にイベントサブスクリプションを要請する過程を示す図面である。
【００３１】
前記図５を参照すれば、ＲＵＩ−ＣＰ１００がＲＵＩＳ１（２００＿１）にＵＩイベントサブスクリプションを要請して（Ｓ１１１）、前記ＲＵＩＳ１（２００＿１）は、これに対する応答メッセージと初期イベントメッセージとを伝送する（Ｓ１１２、Ｓ１１３）。また、ＲＵＩ−ＣＰ（１００）は、また他のクライアント装置であるＲＵＩＣ２（４００＿２）にも前記と同一な過程を反復する（Ｓ１１４、Ｓ１１５、Ｓ１１６）。
【００３２】
次いで、前記メッセージを受信したＲＵＩ−ＣＰ（１００）は、前記ホームネットワーク内部で発見されたクライアント装置についても情報を収集する（Ｓ１２０）。これについては、図６を参照して詳しく説明する。前記図６は、本発明の一実施形態による制御ポイントがクライアント装置についての情報を収集する過程を示す図面である。
【００３３】
前記図６を参照すれば、先にＲＵＩ−ＣＰ（１００）がＲＵＩＣ１（４００＿１）にＲＵＩＣ１（４００＿１）についての情報を要請して（Ｓ１２１）、前記要請されたＲＵＩＣ１（４００＿１）は、これに対する自身の情報を提供する（Ｓ１２２）。前記情報を提供されたＲＵＩ−ＣＰ（１００）は、前記情報を貯蔵する（Ｓ１２３）。そして、前記ＲＵＩ−ＣＰ（１００）は、また他のクライアント装置であるＲＵＩＣ２（４００＿２）に対しても前記と同一な過程を反復するので説明を省略する（Ｓ１２４、Ｓ１２５、Ｓ１２６）。前記図６の過程でのクライアント装置についての情報は、前記クライアント装置が支援する遠隔プロトコル（Ｒｅｍｏｔｅ  Ｐｒｏｔｏｃｏｌ）情報及び前記第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報（Ｏｕｔ  Ｏｆ  Ｓｅｓｓｉｏｎ  Ｃａｐａ  Ｉｎｆｏ；以下、ＯＯＳＣａｐａＩｎｆｏと言う）を含む。
【００３４】
前記ＲＵＩ−ＣＰ（１００）が被制御装置であるクライアント装置についての情報を有している状態で、前記セッションに参与していない第３の装置が自身の状態変更を表わすＵＩイベントメッセージを発生させる。それにより、前記ＲＵＩ−ＣＰ（１００）が前記第３の装置が発生させるＵＩイベントメッセージを伝送されて、これに対する応答メッセージを送る（Ｓ１３０）。これについての詳細な説明は図７を参照する。
【００３５】
図７は、制御ポイントが第３の装置からＵＩイベントメッセージを受信して、ＵＩイベントを処理する目的クライアントを選択する過程を示す図面である。
【００３６】
前記ＲＵＩＳ（２００）とＲＵＩＣ（４００）の間のＵＩセッションに参与していないまた他のサーバー装置に該当する３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が或る時点で自身の状態を変更するようになる場合（Ｓ１３１）、前記状態変更の事実を知らせるイベントメッセージを発生させて前記ＲＵＩ−ＣＰ１（１００＿１）に伝送する（Ｓ１３２）。前記伝送されたＲＵＩ−ＣＰ１（１００＿１）は、前記３ｒｄ  ｐａｒｔｙ    ＲＵＩＳ１（３００＿１）に応答メッセージを伝送する（Ｓ１３３）。例えば、ガスを利用した電気装置が前記第３の装置である３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）である場合を考えて見る。前記ガスを利用した電気装置のガスバルブが開かれるイベントが発生した場合、これをユーザーに緊急に知らせるためにＲＵＩ−ＣＰ１（１００＿１）に前記ガスバルブが開かれたというイベントメッセージを伝送する。
【００３７】
ＲＵＩ−ＣＰ１（１００＿１）は、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が支援する遠隔プロトコルの情報を得るためにＧｅｔＣｏｍｐａｔｉｂｌｅＵＩｓ  Ａｃｔｉｏｎを要請して（Ｓ１３４）、前記要請を受けた３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）は、前記ＣｏｍｐａｔｉｂｌｅＵＩｓ  Ａｃｔｉｏｎを提供することによって、自身が支援する遠隔プロトコルの情報をＲＵＩ−ＣＰ１（１００＿１）に提供する（Ｓ１３５）。ＲＵＩ−ＣＰ１（１００＿１）は、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が支援する遠隔プロトコルの情報を貯蔵しておいて、Ｓ１４０過程で前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）のＵＩイベントを処理することができるクライアントを選択する過程に利用されるところ、これについての説明はＳ１４０過程で後述する。
【００３８】
また、また他の制御ポイント装置であるＲＵＩ−ＣＰ２（１００＿２）が前記第３の装置である３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）の状態変更に対してＵＩイベントメッセージを伝送されることもできる。この場合は、前記Ｓ１３２ないしＳ１３５過程と同一な過程がＲＵＩ−ＣＰ２（１００＿２）と３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）の間で発生する（Ｓ１３６、Ｓ１３７、Ｓ１３８、Ｓ１３９）。ところが、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が発生させるＵＩイベントメッセージは、前記Ｓ１１０段階でのＵＩイベントサブスクリプションを要請した制御ポイントにのみ伝送されなければならない。前記ＵＩイベントサブスクリプションを要請しない制御ポイントにまで前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が自身の状態変更を敢えて知らせる必要がないためである。
【００３９】
前記ＵＩイベントメッセージには、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）の固有識別子（ＵＤＮ）情報及び前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が発生させる多数のＵＩイベントの順序を表わすイベントシーケンス情報（ＵＩ  Ｅｖｅｎｔ  Ｓｅｑｕｅｎｃｅ）を含むが、前記イベントシーケンス情報は、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）の状態が変更されてＵＩイベントが発生する度に一つずつ増加する。前記固有識別子情報は、ＵＩイベントメッセージを伝送する第３の装置が二つ以上である場合に、これを区分するために使われるものである。また、前記イベントシーケンス情報は、一つの同一な第３の装置が連続的にＵＩイベントを発生させて制御ポイントに伝送する場合、これを受信したいくつかのＲＵＩ−ＣＰ（１００）装置が一つのＲＵＩＣ（４００）装置に前記ＵＩイベントを処理することができるか否かを要請すれば、前記ＲＵＩＣ（４００）装置は、同一なＵＩイベントを重複して処理する可能性が生ずるので、このような可能性を防止するためである。
【００４０】
前記のような図７の過程を経た制御ポイントは、前記Ｓ１２０過程で収集して貯蔵した前記ＯＯＳＣａｐａＩｎｆｏ（第３の装置によって発生したＵＩイベントを処理できるか否かを表わす情報）を用いて前記ＵＩイベントを処理することができる与件を有するクライアントを一つ以上選択する。ここで、前記ＯＯＳＣａｐａＩｎｆｏは、三つの状況についての情報を含みうるが、前記ＵＩイベントをいつも処理できるという情報、前記クライアントが遠隔ＵＩセッションへの参与時のみに処理可能であるという情報、及びいつも処理不可であるという情報を含むことができる。しかし、このような三つの情報に分類することは一つの実施形態に過ぎないだけであり、もっと多い場合の状況についての情報を含みうる。
【００４１】
制御ポイント装置であるＲＵＩ−ＣＰ（１００）は、前記選択された一つ以上のクライアントの中で前記ＵＩイベントを処理することができるクライアント（Ｔａｒｇｅｔ  Ｃｌｉｅｎｔ；以下、目的クライアントと称する）を選択する（Ｓ１４０）。この際、前記Ｓ１２０過程で収集されたクライアントについての情報のうち遠隔プロトコル情報と前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が支援する遠隔プロトコル情報とを比べて、マッチングされるクライアントを最終の目的クライアントに選択する。
【００４２】
制御ポイントは、前記のような過程を経て選択された目的クライアントに前記第３の装置が発生させたＵＩイベントを処理するために前記第３の装置との連結を設定するように要請するメッセージ（Ｏｕｔ  Ｏｆ  Ｓｅｓｓｉｏｎ  Ｃｏｎｎｅｃｔ  Ａｃｔｉｏｎ；ＯＯＳＣｏｎｎｅｃｔ  Ａｃｔｉｏｎ、以下、非セッション連結メッセージと称する）を伝送する（Ｓ１５０）。これについての詳細な過程は、図８を参照して説明する。前記図８は、本発明の一実施形態による制御ポイントが目的クライアントにＯＯＳＣｏｎｎｅｃｔ  Ａｃｔｉｏｎを要請する過程を示す図面である。
【００４３】
前記図８を参照すれば、目的クライアントに該当するＴａｒｇｅｔ  ＲＵＩＣ（４００）は、  ＲＵＩＳ２（２００＿２）とすでに遠隔プロトコル（Ｏｕｔ  Ｏｆ  Ｂａｎｄプロトコル）を用いてＲＵＩセッションに参与している状態であることが分かる。前記選択されたＴａｒｇｅｔ  ＲＵＩＣ（４００）は、すでに他のサーバーであるＲＵＩＳ２（２００＿２）とＲｅｍｏｔｅＵＩセッションとを進行しているとしても新しい非セッション連結を設定できるところ、これについて説明する。
【００４４】
前記ＲＵＩ−ＣＰ１（１００＿１）が前記選択されたＴａｒｇｅｔ  ＲＵＩＣ（４００）に前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）の固有識別子（ＵＤＮ）情報及び前記イベントシーケンス情報を前記非セッション連結メッセージに載せて送る（Ｓ１５１）。前記Ｔａｒｇｅｔ  ＲＵＩＣ（４００）は、前記非セッション連結メッセージを受信して、前記固有識別子情報及び前記イベントシーケンス情報を貯蔵する（Ｓ１５２）。前記情報を貯蔵する理由は、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）から同一なＵＩイベントを受信した他の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）が同一なＲＵＩＣ（４００）に前記ＵＩイベントの処理のための非セッション連結を要請することによって、重複された処理を防止するためである。
【００４５】
したがって、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）が伝送した一つのＵＩイベントメッセージに対して最初に非セッション連結を実行したＴａｒｇｅｔ  ＲＵＩＣ（４００）は、また他の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）が同一な非セッション連結要請をしたか否かを確認するために、前記貯蔵された固有識別子情報と前記イベントシーケンス情報とを比べる。比較結果、前記値が一致していない場合には、前記Ｔａｒｇｅｔ  ＲＵＩＣ（４００）は、ＲＵＩ−ＣＰ１（１００＿１）に受諾する応答メッセージを送り（Ｓ１５３）、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）とＲＵＩセッションを新しく形成する（Ｓ１５４）。
【００４６】
もし、前記Ｔａｒｇｅｔ  ＲＵＩＣ（４００）が、また他の第２の制御ポイントであるＲＵＩ−ＣＰ２（１００＿２）から同一な内容の第２の非セッション連結要請を受信した場合（Ｓ１５５）、前記第２の非セッション連結メッセージに含まれた固有識別子情報及びイベントシーケンス情報とを前記Ｓ１５２過程で貯蔵された固有識別子情報及びイベントシーケンス情報と比較分析する（Ｓ１５６）。
【００４７】
前記比較分析の結果、前記固有識別子情報及びイベントシーケンス情報が同一である場合には、すでに処理されたというメッセージをＲＵＩ−ＣＰ２（１００＿２）に伝送する。すでに同一なＵＩイベントに対する非セッション連結要請を受信して、前記３ｒｄ  ｐａｒｔｙ  ＲＵＩＳ１（３００＿１）のＵＩイベントを処理した状態なので、前記識別子情報及び前記イベントシーケンス情報が同一であるためである。したがって、前記Ｔａｒｇｅｔ  ＲＵＩＣ（４００）は、拒否のメッセージをＲＵＩ−ＣＰ２（１００＿２）に送りながらすでに前記ＵＩイベントが処理されたというメッセージを伝達する（Ｓ１５７）。
【００４８】
一方、本発明の実施形態によるホームネットワークで第３の装置のイベントを処理する装置の権利範囲は、前記のような方法をコンピュータで実行するためのプログラムコードを記録したコンピュータで読取り可能な記録媒体にも及ぶということは当業者に自明である。
【００４９】
以上、添付された図面を参照して、本発明の実施形態を説明したが、当業者ならば本発明の技術的思想や必須な特徴を外れない範囲内でいろいろに置き換え、変形及び変更が可能なので、他の具体的な形態に実施されるということを理解できるであろう。したがって、前述した実施形態は、あらゆる面で例示的なものであり、限定的ではないということを理解せねばならない。本発明の範囲は、前記詳細な説明よりは後述する特許請求の範囲によって表され、特許請求の範囲の意味及び範囲、そして、その均等概念から導出されるすべての変更または変形された形態が本発明の範囲に含まれると解釈されなければならない。
【産業上の利用可能性】
【００５０】
本発明は、ホームネットワークでのイベンティング処理技術分野に適用されうる。
【図面の簡単な説明】
【００５１】
【図１】従来技術によるＵＰｎＰでのイベンティング過程を示す図面である。
【図２】従来技術によるＵＰｎＰ  Ｒｅｍｏｔｅ  ＵＩシステムの構成を示す図である。
【図３】本発明の一実施形態による第３の装置のイベントを処理する装置の全体構成を示す図である。
【図４】本発明の一実施形態による第３の装置のイベント処理方法を示すフローチャートである。
【図５】本発明の一実施形態による制御ポイントがサーバー装置にイベントサブスクリプションを要請する過程を示す図である。
【図６】本発明の一実施形態による制御ポイントがクライアント装置についての情報を収集する過程を示す図である。
【図７】本発明の一実施形態による制御ポイントが第３の装置からＵＩイベントメッセージを受信してＵＩイベントを処理する目的クライアントを選択する過程を示す図である。
【図８】本発明の一実施形態による制御ポイントが目的クライアントにＯＯＳＣｏｎｎｅｃｔ  Ａｃｔｉｏｎを要請する過程を示す図である。
【符号の説明】
【００５２】
１００      ＲＵＩ制御ポイント
２００      ＲＵＩサーバー
３００      第３の装置
４００      ＲＵＩクライアント
【図１】
0004456095.tif 000002
【図２】
0004456095.tif 000003
【図３】
0004456095.tif 000004
【図４】
0004456095.tif 000005
【図５】
0004456095.tif 000006
【図６】
0004456095.tif 000007
【図７】
0004456095.tif 000008
【図８】
0004456095.tif 000009