(57)【特許請求の範囲】
【請求項１】
遠隔ユーザインターフェース（ＵＩ）システムにおけるメッセージを提供する方法であって、
遠隔サーバ又は前記遠隔サーバと通信する第１の端末において、前記第１の端末に接続された第２の端末に送信される通知メッセージが生成される場合に、前記第１の端末が、前記通知メッセージに対するアクセス情報を生成し、前記通知メッセージの発生を示す通知メッセージイベントに前記アクセス情報を加え、前記通知メッセージイベントをマルチキャスト方式で複数の第２の端末に送信するステップと、
前記複数の第２の端末から前記アクセス情報を含む前記通知メッセージに対する要請を受信するステップと、
前記通知メッセージに対する要請に含まれたデバイスハンドル値が、前記通知メッセージに対する要求を行った前記第２の端末の端末識別子（ＩＤ）と同一である場合に、ＩＤが前記デバイスハンドル値と同一である前記第２の端末に前記通知メッセージを送信するステップとを有することを特徴とする方法。
【請求項２】
前記アクセス情報は、前記第１の端末の遠隔サーバアプリケーション識別子、及び前記通知メッセージを動的に取得するためのダイナミックメッセージ要請を識別する識別子をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記通知メッセージイベントを前記複数の第２の端末に送信するステップは、前記生成された通知メッセージをハイパーテキストマークアップ言語（ＨＴＭＬ）の形式で格納するステップか、又は前記生成された通知メッセージを格納せず、前記通知メッセージを動的に取得するためのダイナミックメッセージ要請を識別する識別子を含む前記アクセス情報を生成するステップを有することを特徴とする請求項１に記載の方法。
【請求項４】
前記アクセス情報が前記ダイナミックメッセージ要請を識別する識別子を含む場合に、前記第１の端末は、前記第２の端末から前記通知メッセージに対する要請を受信すると、前記要請された通知メッセージを動的に取得し、前記取得した通知メッセージを前記第２の端末に送信することを特徴とする請求項３に記載の方法。
【請求項５】
前記複数の第２の端末のうちで前記通知メッセージに対する要請に含まれたデバイスハンドル値と同一ではないＩＤを有する第２の端末にヌル応答又はエラーメッセージを送信するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項６】
前記アクセス情報は、ユニフォームリソースロケータ（ＵＲＬ）情報であり、前記第２の端末は、前記通知メッセージのための要請を前記ＵＲＬ情報とともに前記第１の端末に送信することを特徴とする請求項１に記載の方法。
【請求項７】
遠隔ユーザインターフェース（ＵＩ）システムにおけるメッセージを提供する端末装置であって、
遠隔サーバと通信し、前記遠隔サーバから通知メッセージを受信するか又は通知メッセージを生成し、前記受信されるか又は生成された通知メッセージを前記端末装置に現在接続された第３の端末に送信するアプリケーションと、
前記通知メッセージに対するアクセス情報を生成し、前記通知メッセージの発生を示す通知メッセージイベントに前記アクセス情報を加え、マルチキャスト方式で前記通知メッセージイベントを複数の第３の端末に送信するハンドラーと、
前記通知メッセージを前記アプリケーションから受信し、前記複数の第３の端末から前記アクセス情報を含む前記通知メッセージに対する要請を受信し、前記通知メッセージに対する要請に含まれたデバイスハンドル値が、前記通知メッセージに対する要求を行った前記第３の端末の端末識別子（ＩＤ）と同一である場合に、ＩＤが前記デバイスハンドル値と同一である前記第３の端末に前記通知メッセージを送信するエンベデッドサーバとを有することを特徴とする端末装置。
【請求項８】
前記アクセス情報は、前記アプリケーションの識別子、及び前記通知メッセージを動的に取得するためのダイナミックメッセージ要請を識別する識別子をさらに含むことを特徴とする請求項７に記載の端末装置。
【請求項９】
前記エンベデッドサーバは、前記アプリケーションから受信した通知メッセージをハイパーテキストマークアップ言語（ＨＴＭＬ）形式で格納するか、又は前記受信した通知メッセージを格納せずに前記通知メッセージを動的に取得するためのダイナミックメッセージ要請を識別する識別子を前記ハンドラーに伝達し、
前記ハンドラーは、前記ダイナミックメッセージ要請を識別する識別子を含む前記アクセス情報を生成することを特徴とする請求項７に記載の端末装置。
【請求項１０】
前記エンベデッドサーバは、前記アクセス情報が前記ダイナミックメッセージ要請を識別する識別子を含む場合に、前記第３の端末から前記通知メッセージに対する要請を受信すると、前記要請された通知メッセージを動的に取得し、前記取得した通知メッセージを前記第３の端末に送信することを特徴とする請求項９に記載の端末装置。
【請求項１１】
前記アクセス情報は、ユニフォームリソースロケータ（ＵＲＬ）情報であり、前記第３の端末は、前記通知メッセージのための要請を前記ＵＲＬ情報とともに前記エンベデッドサーバに送信することを特徴とする請求項７に記載の端末装置。
【請求項１２】
前記エンベデッドサーバは、前記複数の第３の端末のうちで、前記通知メッセージに対する要請に含まれたデバイスハンドル値と同一ではないＩＤを有する第３の端末にヌル応答又はエラーメッセージを送信することを特徴とする請求項７に記載の端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージを提供する方法及びそのための端末装置に関し、特に、遠隔ユーザインターフェース（User Interface：以下、“ＵＩ”と称する）を使用する遠隔ＵＩ（Remote User Interface：以下、“ＲＵＩ”と称する）システムにおける第３の端末にメッセージを提供する方法及びそのための端末装置に関する。
【背景技術】
【０００２】
ホームネットワーク技術を向上させるための研究が、ディジタルリビングネットワークアライアンス（Digital Living Network Alliance：ＤＬＮＡ）、ホームオーディオビデオインターオペラビリティ（Home Audio-Video Interoperability：ＨＡＶｉ）、及びユニバーサルプラグアンドプレイ（Universal Plug and Play：ＵＰｎＰ）などのような多くの産業標準団体により活発に進んでいる。
【０００３】
ホームネットワーク技術において、ＲＵＩ技術は、１つの装置が他の装置を制御するために使用する技術である。一般的に、クライアントサーバアーキテクチャに基づくＲＵＩ技術は、ＲＵＩクライアント（RUI Client）がＲＵＩサーバ（RUI Server）からＵＩを取得し、これにより、ＲＵＩクライアントでのユーザがＵＩを用いてＲＵＩサーバを制御することができるようにする。以下、ＲＵＩを遠隔ＵＩと呼び、ＲＵＩサーバを遠隔サーバと呼ぶ。
【０００４】
図１は、従来技術によるネットワークにおける通知（Notification）メッセージを提供する過程を示すシグナリング図である。
【０００５】
図１を参照すると、第３の端末１０は、通知メッセージを第２の端末１１から受信する。第３の端末１０は、ＲＵＩクライアントに対応し、第２の端末１１は、第３の端末１０を要請する時に遠隔ＵＩを提供することができるエンベデッドサーバ（embedded server）を有する他の端末に対応する。第３の端末１０は、ステップ１０１において第２の端末１１を発見し、ステップ１０２において第２の端末１１が提供するＵＩページを受信する。
【０００６】
この後に、ステップ１０３において、第２の端末１１が通知メッセージの発生を示すメッセージをマルチキャスト方式で第３の端末１０に送信する場合に、ステップ１０４において、第３の端末１０は、第２の端末１１がユーザに見られる通知メッセージを送信するように要請する。その後に、第２の端末１１は、ステップ１０５において、この要請された通知メッセージを第３の端末１０に送信し、第３の端末１０は、ステップ１０６において、通知メッセージをレンダリングし、これを画面上に表示する。
【０００７】
上記のような従来方式において、ステップ１０３で、第２の端末１１が通知イベント情報を宅内のすべての第３の端末１０にマルチキャスト方式で送信するために、第２の端末１１は、関連するメッセージのみを特定の第３の端末に送信することが不可能である。したがって、メッセージを特定の第３の端末に送信するためには、まず、第２の端末１１は、ＵＩページを提供しなければならず、ＵＩページ内に含まれている第２の端末１１のアドレス及び関連情報を用いて、第３の端末１０は、第２の端末１１が通知メッセージを送信するように要請することができる。
【０００８】
しかしながら、第２の端末が遠隔サーバ（図示せず）に接続され、ＵＩページが遠隔サーバ（図示せず）から第２の端末を通して第３の端末に提供される遠隔制御環境では、第２の端末が特定の第３の端末に通知メッセージを直接伝達することができる方法がない。これは、遠隔サーバから提供されるＵＩページ内に通知メッセージを受信することができる第２の端末のアドレスが含まれていないためである。この場合に、送信制御プロトコル（Transmission Control Protocol：ＴＣＰ）ソケット及びポーリングのような既存のメッセージ配信方式の使用が不可能であり、拡張型マークアップ言語（eXtensible Markup Language：ＸＭＬ）ハイパーテキストトランスファープロトコル（HyperText Transfer Protocol：ＨＴＴＰ）要請（ＸＨＲ）の使用も不便である。
【０００９】
したがって、少なくとも３個のエンティティー及び端末を含む遠隔制御環境において、通知メッセージを特定の端末に送信することができるメッセージを提供する方法が必要である。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、少なくとも３つのエンティティーを含む遠隔制御環境において通知メッセージを特定の端末に送信することができるメッセージを提供する方法及びそのための端末装置を提供することにある。
【００１１】
本発明の他の目的は、少なくとも３つのエンティティーを含む遠隔制御環境において通知メッセージを効率的に提供するメッセージを提供する方法及びそのための端末装置を提供することにある。
【００１２】
本発明のまた他の目的は、ネットワークにおいて端末と遠隔サーバとの間の通信を通して通知メッセージを効率的に提供するメッセージを提供する方法及びそのための端末装置を提供することにある。
【００１３】
本発明のさらにまた他の目的は、ネットワークにおいて通知メッセージイベントをマルチキャスト方式で複数の端末に送信し、複数の端末のうちの特定の端末のみに通知メッセージを提供するメッセージを提供する方法及びそのための端末装置を提供することにある。
【課題を解決するための手段】
【００１４】
上記のような目的を達成するために、本発明の一態様によれば、遠隔ユーザインターフェース（ＵＩ）システムにおけるメッセージを提供する方法を提供する。上記方法は、遠隔サーバ又は上記遠隔サーバと通信する第１の端末において上記第１の端末に接続された第２の端末に送信される通知メッセージが生成される場合に、上記第１の端末が、上記通知メッセージに対するアクセス情報を生成し、上記通知メッセージの発生を示す通知メッセージイベントに上記アクセス情報を加え、上記通知メッセージイベントをマルチキャスト方式で複数の第２の端末に送信するステップと、上記複数の第２の端末から上記通知メッセージに対する要請を受信すると、上記第１の端末が上記複数の第２の端末のうちで上記アクセス情報に含まれた端末識別子（ＩＤ）に一致する識別子を有する上記第２の端末に上記通知メッセージを送信するステップとを有することを特徴とする。
【００１５】
本発明の他の態様によれば、 遠隔ユーザインターフェース（ＵＩ）システムにおけるメッセージを提供する端末装置を提供する。上記端末装置は、遠隔サーバと通信し、上記遠隔サーバから通知メッセージを受信するか又は通知メッセージを生成し、上記受信されるか又は生成された通知メッセージを上記端末に現在接続された第３の端末に送信するアプリケーションと、上記通知メッセージに対するアクセス情報を生成し、上記通知メッセージの発生を示す通知メッセージイベントに上記アクセス情報を加え、マルチキャスト方式で上記通知メッセージイベントを複数の第３の端末に送信するハンドラーと、上記通知メッセージを上記アプリケーションから受信し、上記複数の第３の端末から上記通知メッセージに対する要請を受信すると、上記複数の第３の端末のうちで上記アクセス情報に含まれた端末識別子（ＩＤ）に一致する識別子を有する上記第３の端末に上記通知メッセージを送信するエンベデッドサーバとを有することを特徴とする。
【発明の効果】
【００１６】
本発明の実施形態のメッセージ配信システム及び方法において、ネットワークで端末間の通信を通して１つの端末が他の端末に接続された遠隔サーバで生成されたメッセージ又は他の端末自体で生成されたメッセージを他の端末を通して受信することができるという長所がある。
【００１７】
また、遠隔サーバで生成されたメッセージ又は他の端末自体で生成されたメッセージを特定の端末のみに送信することができるという長所がある。
【００１８】
本発明の他の目的、効果、及び顕著な特徴は、添付図面が併用される本発明の実施形態を開示する後述の詳細な説明から、当業者にとって一層明らかになる。
【図面の簡単な説明】
【００１９】
【図１】従来技術によるネットワークにおける通知メッセージを提供する過程を示すシグナリング図である。
【図２】本発明の実施形態によるメッセージ配信システムの構成を示す図である。
【図３】本発明の実施形態によるネットワークにおける通知メッセージを提供する過程を示すシグナリング図である。
【図４】本発明の実施形態による第３の端末に通知メッセージを動的に提供する過程を示すシグナリング図である。
【図５Ａ】本発明の実施形態によるオープンインターネットプロトコルテレビジョン（Internet Protocol TeleVision：ＩＰＴＶ）フォーラム標準に適用することができる通知メッセージを示す図である。
【図５Ｂ】本発明の実施形態によるＩＰＴＶフォーラム標準に適用することができる通知メッセージを示す図である。
【図６】本発明の実施形態によるＩＰＴＶフォーラム標準に適用することができる通知メッセージを示す図である。
【図７】本発明の実施形態によるＩＰＴＶフォーラム標準に適用することができる通知メッセージを示す図である。
【発明を実施するための形態】
【００２０】
図面中、同一の図面参照符号は、同一の構成要素、特性、及び構造を意味することに留意する。
【００２１】
添付図面を参照した以下の説明は、特許請求の範囲及びそれらの均等物によって規定される本発明の実施形態の包括的な理解を助けるために提供されるものであり、多様で詳細な説明を含む。しかしながら、これら詳細な説明は、単に例示的なものとみなされる。したがって、本発明の範囲及び精神を逸脱することなく、以下に説明される実施形態の様々な変形及び変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。また、公知の機能や構成に関する具体的な説明は、明瞭性と簡潔性のために省略される。ここで使用される用語は、本発明の機能を考慮して定義されたものであって、ユーザ又は運用者の意図又は慣例によって変わり得る。したがって、上記用語は、本明細書の全体内容に基づいて定義されなければならない。
【００２２】
次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。
【００２３】
英文明細書に記載の“ａ”、“ａｎ”、及び“ｔｈｅ”、すなわち単数形は、文中に特記で明示されない限り、複数形を含むことは、当業者にはわかることである。したがって、例えば、“コンポーネント表面（a  component  surface）”との記載は、一つ又は複数の表面を含む。
【００２４】
“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者によって実験なしに得られる要素を含む偏差又は変化が、これら特性が提供しようとする効果を排除しない範囲内で発生することを意味する。
【００２５】
下記の説明において、ユーザインターフェース（User Interface：以下、“ＵＩ”と称する）ページを要請する端末を第３の端末と呼び、ＵＩページ及び通知メッセージを遠隔サーバを通して第３の端末に提供する端末を第２の端末と呼ぶ。
【００２６】
本発明の実施形態は、第２の端末が第２の端末自体で生成した通知メッセージを第３の端末に提供し、第２の端末が遠隔サーバに接続されている時に、第２の端末は、遠隔サーバで生成された通知メッセージを第３の端末に提供する新たな方式を提案する。
【００２７】
また、本発明の実施形態は、第２の端末で生成された通知メッセージイベント及び遠隔サーバで生成された通知メッセージイベントをマルチキャスト方式で複数の第３の端末に提供し、複数の第３の端末から通知メッセージの要請を受信する時に、この通知メッセージを、対象の第３の端末のみに提供する新たな方式を提案する。
【００２８】
ここで論議される図２から図７及び本特許文書で開示された内容の原理を記述するために使用される様々な例示的な実施形態はただ例示のためのものであり、上記開示された内容の範囲を限定するいかなる方式でも解釈されてはいけない。当業者は、上記開示された内容の原理が適合に配列された通信システムでも実現されることができることを理解するのであろう。様々な実施形態を記述するために使用された用語は例示的である。それは、単純に詳細な説明の理解を助けるために提供されるものであることを留意しなければならない。これら(用語）の使用及び定義はいかなる方式でも本発明の範囲を提案しない。用語第１、第２などは同一の定義を有する対象を区分するために使用され、明示的な説明がない限り順序を示すために意図するいかなる方式で使用されるものではない。セット(set）は、少なくとも１つのエレメントを含む空いていないセットで定義される。
【００２９】
図２は、本発明の実施形態によるメッセージ配信システムの構成を示す図である。
【００３０】
図２を参照すると、メッセージ配信システムは、第３の端末１００、第２の端末１０１、及び遠隔サーバ１０２を含む。
【００３１】
遠隔ユーザインターフェース（Remote User Interface：ＲＵＩ）クライアントに対応する第３の端末１００は、第２の端末１０１を発見（discovery）し、第２の端末１０１のディスクリプション（Description）情報を受信し、第２の端末１０１がＵＩページを提供するように要請し、この要請に応じて受信したＵＩページをレンダリングし表示する。
【００３２】
第３の端末１００は、第２の端末１０１を通してマルチキャスト方式で第２の端末１０１自体で生成されたか又は遠隔サーバ１０２で生成された通知メッセージの発生を示す通知メッセージイベントを受信し、受信された通知メッセージイベントを通して第２の端末１０１からユーザに見られる通知メッセージを受信する。
【００３３】
また、第３の端末１００は、第２の端末１０１から受信された通知メッセージイベントから通知メッセージアクセス情報であるユニフォームリソースロケータ（Uniform Resource Locator：ＵＲＬ）情報を抽出し、第２の端末１０１が抽出されたＵＲＬ情報を用いて通知メッセージを提供するように要請する。
【００３４】
第２の端末１０１は、遠隔サーバ１０２で提供するＵＩページを第３の端末１００に提供し、第２の端末１０１自体で生成された通知メッセージ又は遠隔サーバ１０２で生成された通知メッセージを第３の端末１００に送信する。
【００３５】
第２の端末１０１は、遠隔サーバアプリケーション１０５、エンベデッドサーバ（embedded Server）１０６、及び通知ハンドラー（Notification Handler）１０７を含む。第３の端末１００は、ブラウザー１０９及び通知ハンドラー１０８を含む。
【００３６】
遠隔サーバアプリケーション１０５は、遠隔サーバ１０２で生成された通知メッセージ又は第２の端末１０１自体で生成された通知メッセージを受信し、受信された通知メッセージをエンベデッドサーバ１０６に送信する。
【００３７】
本発明の実施形態に従って、第２の端末１０１は、複数の遠隔サーバアプリケーションを含むことができ、複数の遠隔サーバアプリケーションは、生成された通知メッセージの種類に従って独立してエンベデッドサーバ１０６に格納することができる。
【００３８】
ダイナミックメッセージ要請に応じて、遠隔サーバアプリケーション１０５は、遠隔サーバ１０２が通知メッセージを提供するように要請し、該要請に応答して受信された通知メッセージをエンベデッドサーバ１０６に送信する。
【００３９】
ここで使用される‘ダイナミックメッセージ要請’ということは、遠隔サーバ１０２から受信された通知メッセージがＴＥＸＴ又はハイパーテキストマークアップ言語（Hypertext Markup Language：ＨＴＭＬ）形式でなく、例えば、ＵＲＬ形式であるか、又は通知メッセージを動的に持ってくることを指示する情報を含む時に、遠隔サーバアプリケーション１０５は、遠隔サーバ１０２がＴＥＸＴ又はＨＴＭＬ形式で通知メッセージを提供するように再要請する動作を意味する。
【００４０】
エンベデッドサーバ１０６は、第３の端末１００が第２の端末１０１を発見し、第２の端末１０１がＵＩページを提供するように要請することができる第２の端末１０１に関するディスクリプション情報を提供することができる。
【００４１】
エンベデッドサーバ１０６は、第３の端末１００が第２の端末１０１を通して遠隔サーバ１０２からＵＩページを受信するたびに第３の端末１００に関する情報を格納する。
【００４２】
また、エンベデッドサーバ１０６は、遠隔サーバアプリケーション１０５から通知メッセージを受信すると、受信された通知メッセージ及び通知メッセージを送信した遠隔サーバアプリケーションを格納する。この時に、受信された通知メッセージがＴＥＸＴ形式である場合に、エンベデッドサーバ１０６は、この通知メッセージを第３の端末１００にディスプレー可能なＨＴＭＬ形式に変換した後に格納する。この受信された通知メッセージがＨＴＭＬ形式である場合に、エンベデッドサーバ１０６は、変換なしにこの通知メッセージを格納する。
【００４３】
遠隔サーバアプリケーション１０５から受信された通知メッセージがＴＥＸＴ又はＨＴＭＬ形式でなく、例えばＵＲＬの形式であるか又はダイナミックメッセージ要請情報を含む場合は、エンベデッドサーバ１０６は、この通知メッセージを格納しない。
【００４４】
また、エンベデッドサーバ１０６は、通知ハンドラー１０７が通知メッセージのアクセス情報であるＵＲＬ情報を生成することができるように遠隔サーバアプリケーションＩＤ（関連する遠隔サーバアプリケーションに関する情報）、端末ＩＤ（第３の端末に関する情報）、及びダイナミックメッセージ情報を含むパラメータ値を通知ハンドラー１０７に送信する。
【００４５】
複数の第３の端末から通知メッセージの要請を受信する時に、エンベデッドサーバ１０６は、この通知メッセージをハイパーテキスト転送プロトコル（ＨＴＴＰ）応答メッセージを用いて、対象の特定の第３の端末１００のみに送信する。複数の第３の端末が同一のＵＲＬ情報を用いて通知メッセージを要請するので、エンベデッドサーバ１０６は、複数の第３の端末のうちで、ＵＲＬ情報が含むことができる第３の端末に関する情報（端末ＩＤ）に一致する対象の特定の第３の端末１００を判定（すなわち、選択）することができる。
【００４６】
ＵＲＬ情報は、通知ハンドラー１０７が通知メッセージの発生を複数の第３の端末に通知するためにマルチキャスト方式で送信した通知メッセージイベントから抽出した情報である。
【００４７】
エンベデッドサーバ１０６は、複数の第３の端末のうちで、ＵＲＬ情報に含まれた第３の端末に関する情報（端末ＩＤ）に一致しない端末ＩＤを有する第３の端末に適切なヌル（Null）応答又はエラーメッセージを送信する。エンベデッドサーバ１０６は、ＨＴＴＰ応答メッセージに挿入された個別の新たなＨＴＴＰ応答コード又は特定のパラメータ値を有するＨＴＴＰ応答メッセージを一致しない端末ＩＤを有する第３の端末に送信する。この個別の新たなＨＴＴＰ応答コードは、いずれのエラーメッセージ又はウィンドーが生成されユーザに見られることを防止するために定義され、この特定のパラメータ値は、一致しない端末ＩＤを有する第３の端末のそれぞれにある通知ハンドラーが要請に応答しないように提供される。
【００４８】
また、エンベデッドサーバ１０６は、複数の第３の端末から受信されたＵＲＬ情報を分析することによりダイナミックメッセージに対する要請があるか否かを判定する。この要請があると判定される場合に、エンベデッドサーバ１０６は、ダイナミックメッセージ要請を示すイベントメッセージを遠隔サーバアプリケーション１０５に送信し、遠隔サーバアプリケーション１０５から受信された通知メッセージをＴＥＸＴ形式又はＨＴＭＬ形式で対象の特定の第３の端末１００に送信する。この時に、エンベデッドサーバ１０６は、ＴＥＸＴ形式の通知メッセージをＨＴＭＬ形式の通知メッセージに変換し、これを対象の特定の第３の端末１００に送信する。
【００４９】
遠隔サーバアプリケーション情報（遠隔サーバアプリケーションＩＤ）、第３の端末情報（端末ＩＤ）、及びダイナミックメッセージ情報を含むパラメータ値をエンベデッドサーバ１０６から受信する時に、通知ハンドラー１０７は、パラメータ値を用いて通知メッセージのアクセス情報であるＵＲＬ情報を生成し、ＵＲＬ情報を含む通知メッセージイベントを複数の第３の端末にマルチキャスト方式で送信する。
【００５０】
遠隔サーバ１０２は、第３の端末１００で表現されることができるＵＩを示すＵＩページ１１１を有しており、ＵＩページ１１１及び通知メッセージを遠隔サーバ１０２に接続された第２の端末１０１を通して第３の端末１００に提供する。
【００５１】
図２に示すメッセージ配信システムを通してメッセージを提供する過程を図３及び図４を参照して詳細に説明する。
【００５２】
図３は、本発明の実施形態によるネットワークにおける通知メッセージを提供する過程を示すシグナリング図である。
【００５３】
図３を参照すると、ステップ３０１において、第３の端末Ａ  １００が第２の端末１０１を発見し、第２の端末１０１のディスクリプション情報を受信し、第２の端末１０１がＵＩページを提供するように要請する場合に、第２の端末１０１は、遠隔サーバ１０２で提供するＵＩページを第３の端末Ａ  １００に送信する。ステップ３０２において、第３の端末Ａ  １００は、受信されたＵＩページをレンダリングし、ウェブブラウザーを通して表示する。
【００５４】
ステップ３０３において、第２の端末１０１内のエンベデッドサーバ１０６は、第３の端末Ａ  １００がＵＩページを遠隔サーバ１０２から受信するたびに第３の端末Ａ  １００に関する情報を格納する。
【００５５】
通知メッセージが第２の端末１０１で生成されるか又は遠隔サーバ１０２が制御する機器でイベントが発生し、関連する通知メッセージが生成される場合に、ステップ３０４において、生成された通知メッセージは、第２の端末１０１の遠隔サーバアプリケーション１０５に転送される。
【００５６】
ステップ３０５において、遠隔サーバアプリケーション１０５は、通知メッセージをエンベデッドサーバ１０６に送信する。ステップ３５０において、エンベデッドサーバ１０６は、通知メッセージを送信した遠隔サーバアプリケーション１０５に関する情報（遠隔サーバアプリケーションＩＤ）を格納する。
【００５７】
受信された通知メッセージがＴＥＸＴ形式である場合に、ステップ３５１において、エンベデッドサーバ１０６は、これを第３の端末Ａ  １００上にディスプレー可能なＨＴＭＬ形式に変換した後に、この通知メッセージを格納する。この受信された通知メッセージがＨＴＭＬ形式である場合に、ステップ３５１において、エンベデッドサーバ１０６は、変換なしにこの通知メッセージを格納する。しかしながら、遠隔サーバアプリケーション１０５から受信された通知メッセージがＴＥＸＴ形式又はＨＴＭＬ形式でなく、例えば、ＵＲＬ形式であるか又はダイナミックメッセージ要請に関する情報を含む場合に、エンベデッドサーバ１０６は、この通知メッセージを格納しない。
【００５８】
その後に、ステップ３０６において、エンベデッドサーバ１０６は、この通知メッセージのアクセス情報であるＵＲＬ情報を生成することができるパラメータ値を通知ハンドラー１０７に送信する。
【００５９】
通知メッセージのアクセス情報であるＵＲＬ情報を生成することができるパラメータ値は、遠隔サーバアプリケーションに関する情報（遠隔サーバアプリケーションＩＤ）、第３の端末に関する情報（端末ＩＤ）、及びダイナミックメッセージ情報を含む。ここで使用される‘ダイナミックメッセージ要請’ということは、遠隔サーバ１０２から受信された通知メッセージがＴＥＸＴ又はＨＴＭＬ形式でなく、例えば、ＵＲＬ形式であるか、又は通知メッセージを動的に持ってくることを指示する情報を含む時に、遠隔サーバアプリケーション１０５は、遠隔サーバ１０２がＴＥＸＴ又はＨＴＭＬ形式で通知メッセージを提供するように再要請する動作を意味する。
【００６０】
エンベデッドサーバ１０６からパラメータ値を受信した通知ハンドラー１０７は、ステップ３０８において、パラメータ値を用いて通知メッセージのアクセス情報であるＵＲＬ情報を生成し、ＵＲＬ情報を含む通知メッセージイベントを生成する。
【００６１】
ステップ３０９において、通知ハンドラー１０７は、生成された通知メッセージイベントをマルチキャスト方式で宅内にある複数の第３の端末Ａ  １００及び端末Ｂ  ３００に送信する。
【００６２】
以下に記載する表１は、通知メッセージのアクセス情報であるＵＲＬ情報を含む通知メッセージイベントを示す。
【００６３】
【表１】
0005590753.tif 000002
【００６４】
上記した表１の通知メッセージイベントにおいて、ＵＲＬ情報は、要素<ruiEventURL>に含むことができ、ＵＲＬ情報の例は、以下に記載する表２に示す。
【００６５】
【表２】
0005590753.tif 000003
【００６６】
上述した表２において、識別子“appid”は、第２の端末１０１で駆動している複数の遠隔サーバアプリケーションのうちで対応する通知メッセージを配信した遠隔サーバアプリケーションを示す識別子である。
【００６７】
識別子“userdevice”は、複数の第３の端末のうちで、通知メッセージが配信されなければならない対象の第３の端末１００を示す識別子である。
【００６８】
識別子“dynamic”は、ダイナミックメッセージ要請を識別する識別子である。ステップ３５１において、エンベデッドサーバ１０６に格納されたユーザデータがＨＴＭＬ形式である場合に、識別子“dynamic”の値は“Ｎ”として設定され、エンベデッドサーバ１０６に格納されたユーザデータがＨＴＭＬ形式でない場合に、識別子“dynamic”の値は“Ｙ”として設定される。
【００６９】
上記のような通知メッセージイベントをマルチキャスト方式で受信した複数の第３の端末Ａ  １００及び端末Ｂ  ３００は、ステップ３２０において、通知メッセージイベントから表２で定義したＵＲＬ情報だけを抽出し、ＵＲＬ情報を用いて第２の端末１０１が通知メッセージを提供するように要請する。
【００７０】
ＵＲＬ情報に基づいて複数の第３の端末Ａ  １００及び端末Ｂ  ３００から通知メッセージの要請を受信する時に、第２の端末１０１内のエンベデッドサーバ１０６は、ステップ３２１において、複数の第３の端末Ａ  １００及び端末Ｂ  ３００のうちで、ＵＲＬ情報に含まれた識別子“userdevice”の値に一致する情報（ＩＤ）を有する第３の端末をステップ３０１で接続された対象の特定の第３の端末Ａ  １００として判定する。
【００７１】
ステップ３５２において、エンベデッドサーバ１０６は、ＵＲＬ情報に含まれた識別子“dynamic”の値を確認する。その値が“Ｎ”である場合に、ステップ３２２において、エンベデッドサーバ１０６は、ステップ３５１で格納されたＨＴＭＬ形式の通知メッセージをＨＴＴＰ応答メッセージを用いて対象の特定の第３の端末１００のみに送信する。また、ステップ３２３において、エンベデッドサーバ１０６は、ＨＴＴＰ応答メッセージに挿入された個別の新たなＨＴＴＰ応答コード又は特定のパラメータ値を有するＨＴＴＰ応答メッセージを送信することができる。この個別の新たなＨＴＴＰ応答コードは、いずれのエラーメッセージ又はウィンドーが生成されユーザに見られることを防止するために定義され、この特定のパラメータ値は、一致しない端末ＩＤを有する第３の端末Ｂ  ３００内の通知ハンドラーがこの要請に応答しないように提供される。
【００７２】
しかしながら、ステップ３５２において、この確認の結果、複数の第３の端末Ａ  １００及び端末Ｂ  ３００から受信されたＵＲＬ情報に含まれた識別子“dynamic”の値が“Ｙ”である場合に、エンベデッドサーバ１０６は、以下に述べられる図４に示すメッセージ送信手順を実行する。
【００７３】
図４は、本発明の実施形態による第３の端末に通知メッセージを動的に提供する過程を示すシグナリング図である。
【００７４】
図４を参照すると、識別子“dynamic”の値が“Ｙ”であるということは、ステップ３０４において、遠隔サーバ１０２から受信された通知メッセージがＴＥＸＴ形式又はＨＴＭＬ形式でなく、例えばＵＲＬ形式であるか、又は通知メッセージを動的に持ってくることを指示する情報を含むことができることを示す。したがって、ステップ４０１において、エンベデッドサーバ１０６は、ダイナミックメッセージ要請があるか否かを確認し、ステップ４０２において、ダイナミックメッセージ要請の発生を示すイベントメッセージをこの通知メッセージを送信した遠隔サーバアプリケーション１０５に送信する。
【００７５】
このイベントメッセージを受信した遠隔サーバアプリケーション１０５は、ステップ４０３において、遠隔サーバ１０２がＴＥＸＴ形式又はＨＴＭＬ形式を有する通知メッセージを提供するように要請する。この要請に応じてＴＥＸＴ形式又はＨＴＭＬ形式を有する通知メッセージを受信する時に、ステップ４０４において、遠隔サーバアプリケーション１０５は、この受信された通知メッセージをエンベデッドサーバ１０６に送信する。
【００７６】
この受信された通知メッセージがＴＥＸＴ形式である場合に、ステップ３２２において、エンベデッドサーバ１０６は、この通知メッセージをＨＴＭＬ形式に変換し、ＨＴＭＬ形式を有する通知メッセージを対象の特定の第３の端末Ａ  １００に送信する。
【００７７】
上述したように、メッセージ配信がダイナミックメッセージに対する要請なしに実行される場合に、通知メッセージの処理速度は速いが、ステップ３５１におけるように通知メッセージを格納しなければならないので使用可能なメモリを減少させる。他方、メッセージ配信がダイナミックメッセージの要請に応じて実行される場合にメモリが使用されないので、この使用可能なメモリが減少しないが、処理速度は、このメッセージ配信がダイナミックメッセージの要請なしに実行される場合に比べてさらに減少する。
【００７８】
図５Ａから図７は、本発明の実施形態によるオープンインターネットプロトコルテレビジョン（Internet Protocol TeleVision：ＩＰＴＶ）フォーラム標準に適用することができる通知メッセージを示す図である。
【００７９】
図５Ａ及び図５Ｂを参照すると、sendMulticastNotifメソッドは、特定の端末又はすべての第３の端末に通知メッセージを送信するために遠隔サーバアプリケーションが使用することができるメソッドである。第２の端末で特定のイベントが発生し、対応するイベントが通知メッセージを現在第２の端末に接続されている特定の第３の端末のみに配信する必要がある場合には、まず、遠隔サーバアプリケーションは、遠隔サーバから通知メッセージを取ってきた後に、sendMulticastNotifメソッドのnotifCEHTMLパラメータから取ってきた値を設定する。
【００８０】
第２の端末は、通知メッセージの送信を希望する特定の第３の端末のＩＤ値をremoteDeviceHandleに挿入し、宅内のすべての第３の端末が受信する通知イベントを構成するためのeventLevel、friendlyName、profilelistパラメータを設定する。すべてのパラメータ値が設定された後にsendMulticastNotifメソッドが実行される場合に、第２の端末は、sendMulticastNotifメソッドを実行した遠隔サーバアプリケーションのＩＤ値を生成し、この生成された遠隔サーバアプリケーションのＩＤ値をremoteDeviceHandleパラメータ値とともにエンベデッドサーバに格納する。また、sendMulticastNotifメソッドに設定されたnotifiCEHTMLパラメータの値は、第３の端末が後で持ってくることができるようにエンベデッドサーバに格納され、第２の端末は、図６を参照して説明するようにＵＲＬ情報を生成する。
【００８１】
第２の端末は、通知ハンドラーにより通知メッセージイベントを生成し、これをマルチキャスト方式で宅内のすべての第３の端末に送信する。
【００８２】
第３の端末は、第２の端末から受信した通知メッセージイベントを分析し、<ruiEventURL>を抽出し、抽出されたＵＲＬ情報を用いて第２の端末が通知メッセージを提供するように要請するＨＴＴＰ要請を行う。
【００８３】
ＨＴＴＰ要請を受信すると、第２の端末は、ＨＴＴＰ要請メッセージでパラメータ値を分析する。ＨＴＴＰ要請を行った第３の端末のＩＤがＨＴＴＰ要請メッセージに含まれている‘devicehandle’値に一致する場合に、第２の端末は、エンベデッドサーバに格納された通知メッセージをＨＴＴＰ応答メッセージを用いて第３の端末に送信する。
【００８４】
第２の端末内のエンベデッドサーバがＨＴＴＰ要請メッセージ内のパラメータ値のうちで、この格納された通知メッセージが図７の場合のようなイベントの発生を通して送信されたことをパラメータ‘daeid’にマッチングされた遠隔サーバアプリケーションに通知する場合に、遠隔サーバアプリケーションは、このイベントが第３の端末に送信されたことを示すＵＩを第２の端末の画面上に表示することができる。遠隔サーバアプリケーションは、図７のイベントを受信することにより他の適切な措置を行うことができる。
【００８５】
ＨＴＴＰ要請を行った第３の端末のＩＤがＨＴＴＰ要請に含まれた‘devicehandle’の値に一致しない場合に、第２の端末は、ＨＴＴＰ５００エラーコードをＩＤが‘devicehandle’の値に一致しない第３の端末に送信する。
【００８６】
また、sendMulticastNotifメソッドがＨＴＭＬ又はＴＥＸＴ形式の値でなく、ヌル（Null）値がnotifCEHTMLパラメータ値に設定された状態で実行される場合に、通知メッセージは、第２の端末のエンベデッドサーバに格納されず、第３の端末からの通知メッセージ要請が第２の端末で受信される時に、第２の端末内のエンベデッドサーバは、通知メッセージを遠隔サーバから持ってくることを指示するイベントを遠隔サーバアプリケーションに送信する。このイベントを受信した遠隔サーバアプリケーションは、遠隔サーバから通知メッセージを持ってき、係属中の第３の端末からの要請に応じて対応する通知メッセージを送信する。
【００８７】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００８８】
１０  第３の端末
１１  第２の端末
１００  第３の端末
１０１  第２の端末
１０２  遠隔サーバ
１０５  遠隔サーバアプリケーション
１０６  エンベデッドサーバ（ｅｍｂｅｄｄｅｄ  Ｓｅｒｖｅｒ）
１０７  通知ハンドラー（Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｈａｎｄｌｅｒ）
１０８  通知ハンドラー
１０９  ブラウザー
１１１  ＵＩページ
【図１】
0005590753.tif 000004
【図２】
0005590753.tif 000005
【図３】
0005590753.tif 000006
【図４】
0005590753.tif 000007
【図５Ａ】
0005590753.tif 000008
【図５Ｂ】
0005590753.tif 000009
【図６】
0005590753.tif 000010
【図７】
0005590753.tif 000011