遠隔ユーザインターフェースリストを提供する方法及び装置
ネットワークにおけるユーザインターフェース（ＵＩ）リストを提供する方法は、遠隔サーバと通信するアプリケーションを有する特定の端末が任意の端末からＵＩリストの要請を受信するステップと、上記アプリケーションを用いて上記遠隔サーバから提供されるＵＩリスト及び上記特定の端末内のＵＩリストの中の少なくとも１つを上記任意の端末に提供するステップとを有する。上記特定の端末は、上記遠隔サーバから提供されるＵＩリストと上記特定の端末内のＵＩリストとを結合することにより、上記結合されたリストを上記任意の端末に提供することができ、上記任意の端末は、上記提供されたＵＩリストを通して所望の遠隔ＵＩを選択することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、遠隔ユーザインターフェース（Remote User Interface：以下、“ＲＵＩ”と称する）を使用する遠隔ユーザインターフェース（User Interface：以下、“ＵＩ”と称する）システムに関し、特に、遠隔ＵＩシステムにおける端末に遠隔ＵＩリストを提供する方法及び装置に関する。
【背景技術】
【０００２】
ホームネットワーク技術を向上させるための研究が、ディジタルリビングネットワークアライアンス（Digital Living Network Alliance：ＤＬＮＡ）、ホームオーディオビデオインターオペラビリティ（Home Audio-Video Interoperability：ＨＡＶｉ）、及びユニバーサルプラグアンドプレイ（Universal Plug and Play：ＵＰｎＰ）などのような多くの産業標準団体により活発に進んでいる。
【０００３】
ホームネットワーク技術において、ＲＵＩ技術は、１つの装置が他の装置を制御することができるように使用することができる。一般的に、ＲＵＩ技術は、クライアントサーバアーキテクチャに基づいて、ＲＵＩクライアント（RUI Client）がＲＵＩサーバ（RUI Server）からＵＩを取ってき、これにより、ＲＵＩＣでのユーザがＵＩを通してＲＵＩＳを制御することができるようにする。以下、ＲＵＩを遠隔ＵＩと呼び、ＲＵＩＳを遠隔サーバと呼ぶ。
【０００４】
図１は、従来の遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。図１は、第２の端末１１を発見（discovery）した後にＵＩリストを要請して取ってくる第３の端末１０を示す図である。図１において、第３の端末１０は、ＲＵＩクライアントに対応し、第２の端末１１は、第３の端末１１の要請の時に遠隔ＵＩを提供することができるエンベデッドサーバ（embedded server）を含む他の端末に対応する。
【０００５】
図１を参照すると、第３の端末１０は、第２の端末１１を発見した後に遠隔ＵＩリストを要請することにより第２の端末に含まれる遠隔ＵＩリストを取ってくる。その後に、第３の端末１０は、遠隔ＵＩリスト内の遠隔ＵＩの中の１つを選択し、この選択された遠隔ＵＩを第２の端末１１に要請する。第２の端末１１は、この要請された遠隔ＵＩを第３の端末１０に送信する。
【０００６】
従来の方法において、第３の端末がＵＩリストを第２の端末に要請する場合に、第２の端末は、第２の端末に含まれたＵＩリストのみを提供する。すなわち、第３の端末がＵＩリストを第２の端末に要請する時に、第３の端末が第２の端末と相互接続される他の遠隔サーバ（図示せず）に含まれた他のＵＩリストを取ってくることができない。また、第２の端末内の遠隔ＵＩリストを遠隔サーバ内の遠隔ＵＩリストと結合して使用することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、遠隔ＵＩシステムにおける遠隔ＵＩリストを効率的に提供する方法及び装置を提供することにある。
【０００８】
本発明の他の目的は、遠隔ＵＩシステムにおける端末と遠隔サーバ間の通信を通して遠隔ＵＩリストを効率的に提供する方法及び装置を提供することにある。
【０００９】
本発明のまた他の目的は、遠隔ＵＩシステムにおける通信を通して提供される複数の遠隔ＵＩリストの結合を提供する方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記のような目的を達成するために、本発明の一態様によれば、遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する方法が提供される。上記方法は、遠隔サーバと通信する第１の端末が上記遠隔サーバからダウンロードされたアプリケーションを駆動するステップと、上記第１の端末内のエンベデッドサーバが上記アプリケーションから受信されたメッセージに基づいて、現在上記エンベデッドサーバに含まれているユーザインターフェースリストと上記メッセージに含まれた上記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成するステップと、上記第１の端末内のエンベデッドサーバが第２の端末からユーザインターフェースリストの要請を受信するステップと、上記第１の端末内のエンベデッドサーバが上記生成された新たなユーザインターフェースリストを上記第２の端末に提供するステップとを有することを特徴とする。
【００１１】
本発明の他の態様によれば、遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する端末装置が提供される。上記端末装置は、遠隔サーバからダウンロードされたプリケーションを含むブラウザーと、上記アプリケーションから受信されたメッセージに基づいて、現在のユーザインターフェースリストと上記メッセージに含まれた上記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成し、他の端末からユーザインターフェースリストの要請を受信することに従って上記生成された新たなユーザインターフェースリストを上記他の端末に提供するエンベデッドサーバとを有することを特徴とする。
【発明の効果】
【００１２】
従来技術では、１つの端末が他の端末を通して遠隔サーバに含まれる遠隔ＵＩリストを取ってくることができなかった。さらに、他の端末内の遠隔ＵＩリストを遠隔サーバ内のＵＩリストと結合することができなかった。
【００１３】
本発明によると、ＵＩシステムにおいて、１つの端末が端末間の通信を通して遠隔ＵＩリストを他の端末に要請することができるだけではなく、遠隔サーバに含まれるＵＩリスト及び上記他の端末内のＵＩリストの中の少なくとも１つをＵＩリストを要請する端末に提供することができる。さらに、上記遠隔サーバに含まれるＵＩリストと上記他の端末に含まれるＵＩリストとを結合することにより得られるＵＩリストを遠隔ＵＩリストを要請する端末に提供することができる。
【００１４】
本発明によると、任意の端末がアプリケーションを含む特定の端末に遠隔ＵＩリストを要請することにより、遠隔サーバ内の遠隔ＵＩリスト又は特定の端末内の遠隔ＵＩリストを受信することができ、特定の端末内の遠隔ＵＩリストと遠隔サーバ内の遠隔ＵＩリストとを結合することにより得られた遠隔ＵＩリストを受信することができる。
【図面の簡単な説明】
【００１５】
【図１】従来の遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。
【図２】本発明の実施形態に従って複数の遠隔ＵＩリストを結合し端末に提供するネットワークの構成を示すブロック図である。
【図３】本発明の実施形態による遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。
【図４】本発明の実施形態によるＵＩリストを提供する方法における遠隔サーバがＵＩリストを含まない場合の手順を示すフローチャートである。
【図５】本発明の実施形態によるＵＩリストを提供する方法における第２の端末内の遠隔サーバアプリケーションが動作しない場合の手順を示すフローチャートである。
【図６】本発明の実施形態によるＵＩリストを提供する方法を示すフローチャートである。
【図７】本発明の実施形態によるＵＩリストを提供する他の方法を示すフローチャートである。
【発明を実施するための形態】
【００１６】
本発明の詳細な構成および要素のような本発明の詳細な説明で定義される特徴は、本発明の実施形態の包括的な理解を助けるために提供される。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００１７】
以下、ＵＩリストを要請する端末は、“第３の端末”と称し、遠隔サーバを通してＵＩリストを第３の端末に提供する他の端末は、“第２の端末”と称する。
【００１８】
本発明は、単純に第２の端末が第２の端末に含まれたＵＩリストを第３の端末に提供する方法に加えて、第２の端末が遠隔サーバに接続される場合に、第３の端末がＵＩリストを第２の端末に要請する時に、第２の端末が遠隔サーバ内のＵＩリストを受信することができるようにする方案と、第２の端末内の遠隔ＵＩリスト及び遠隔サーバ内の遠隔ＵＩリストの中の少なくとも１つを第３の端末に提供するか又は第２の端末内の遠隔ＵＩリストを遠隔サーバ内の遠隔ＵＩリストと結合することにより提供する方案とを提供する。
【００１９】
本発明は、一般的に、第２の端末が自身に含まれている遠隔ＵＩリストと遠隔サーバに含まれている遠隔ＵＩリストとを結合することにより、この結合された遠隔ＵＩリストを第３の端末に提供するようにし、第３の端末が第２の端末により提供される遠隔ＵＩリストを通して遠隔ＵＩリストを第２の端末に要請するようにする方案を提供する。
【００２０】
このために、本発明は、遠隔サーバが遠隔ＵＩリスト制御情報を第２の端末に提供するようにする方法及び第２の端末がこの提供された制御情報を分析して設定するようにする方法を定義する。また、本発明は、第２の端末が第３の端末から遠隔ＵＩリストの要請を受信する時に、第２の端末が遠隔ＵＩリストを第３の端末に提供するようにする方法を定義する。
【００２１】
本発明の実施形態によると、第３の端末が遠隔ＵＩリストを要請する前に確立された情報に基づいて、第３の端末から遠隔ＵＩリストの要請を受信する時に適切な遠隔ＵＩリストを提供することができる。
【００２２】
以下、本発明の実施形態を具体的に説明する。
本発明の実施形態において、第３の端末は、ＲＵＩクライアントに対応し、第２の端末は、遠隔ＵＩリストを第３の端末に提供することができるエンベデッドサーバを含む端末に対応する。また、第２の端末は、遠隔サーバと通信し、遠隔ＵＩリストを遠隔サーバから受信することができるハンドラー（Handler）を含むと仮定する。
【００２３】
図２は、本発明の実施形態に従って複数の遠隔ＵＩリストを結合し端末に提供するネットワークの構成を示すブロック図である。
【００２４】
図２を参照すると、第３の端末１００は、第２の端末１０１を通して第２の端末１０１内のＵＩリスト１１０と第２の端末１０１に接続された遠隔サーバ１０２内のＵＩリスト１１１とを結合することにより得られたＵＩリストを受信する。遠隔サーバ１０２は、第３の端末１００上に表示されることができるＵＩリストに関する情報を示すＵＩリスト１１１を有し、第２の端末１０１は、ＵＩリストを第３の端末１００に送信する方法及び情報を遠隔サーバ１０２から受信することができるハンドラー１０５を含み、ハンドラー１０５は、ＵＩリスト１１１を遠隔サーバ１０２から受信し、ＵＩリスト１１１をエンベデッドサーバ１０６に送信することができる。第２の端末１０１内のエンベデッドサーバ１０６は、第２の端末１０１に関する情報（ディスクリプション情報）を第３の端末１００に提供することができる。エンベデッドサーバ１０６から受信された第２の端末１０１に関する情報は、第３の端末１００がＵＩリストを第２の端末１０１に要請することができるようにする情報を含む。第３の端末１００は、第２の端末１０１を発見し、第２の端末１０１に関する情報を受信し、ＵＩリストを第２の端末１０１に要請する。第３の端末１００は、第２の端末１０１から受信されたＵＩリストを通してＵＩを受信することができる。
【００２５】
図３は、本発明の実施形態による遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートであって、遠隔サーバ１０２がＵＩリストを含む場合にＵＩリストを提供する。
【００２６】
図３を参照すると、まず、ステップ３０１で、遠隔サーバ１０２は、遠隔サーバアプリケーション２００を第２の端末１０１内のハンドラー１０５に送信する。遠隔サーバアプリケーション２００は、遠隔サーバがＵＩリストを有している情報と、対応する情報を確立する方法及び遠隔サーバアプリケーション２００がＵＩリストに対する要請を第３の端末１００又は第２の端末１０１から受信する場合にこれを処理する方法に関する内容とを含む。ステップ３０３で、送信された遠隔サーバアプリケーション２００は、第２の端末１０１内で動作するように駆動され、ステップ３０５で、遠隔サーバがＵＩリストを含むという情報がハンドラー１０５に送信され、ＵＩリストを処理する方法が確立される。ステップ３０７で、ハンドラー１０５は、この確立されたＵＩリストを処理する方法に関する情報をエンベデッドサーバ１０６に送信する。この時に、必要であれば、エンベデッドサーバ１０６は、ＵＩリストをどのように送信するかも第３の端末１００に通知することができる。この後に、ステップ３０９で、第３の端末１００は、第２の端末１０１を発見し、ステップ３１１で、第３の端末１００は、ＵＩリストを第２の端末１０１に要請した後に、ステップ３１３で、第２の端末１０１内のエンベデッドサーバ１０６は、遠隔サーバアプリケーション２００により確立されたＵＩリストを処理する方法に関する情報に基づいて、第２の端末１０１内のＵＩリストを送信するか又は遠隔サーバ内のＵＩリストを送信するかを判定する。
【００２７】
図３のフローチャートが、遠隔サーバアプリケーション２００が遠隔サーバＵＩリストの存在を通知する情報を含む状態を示すので、ステップ３１５で、エンベデッドサーバ１０６は、遠隔サーバＵＩリストをハンドラー１０５に要請する。ステップ３１７で、ハンドラー１０５は、遠隔サーバＵＩリストを取ってくることを遠隔サーバアプリケーション２００に要請し、ステップ３１９で、遠隔サーバアプリケーション２００は、遠隔サーバＵＩリストを遠隔サーバ１０２に要請する。遠隔サーバアプリケーション２００が遠隔サーバＵＩリストを遠隔サーバ１０２に要請することにより受信する過程は、遠隔サーバアプリケーション２００が駆動されたステップ３０３の後とエンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請するステップ３１５の前との間でいつでも実行される。言い換えれば、エンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請する前に、遠隔サーバアプリケーション２００が予め遠隔サーバＵＩリストを受信し、エンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請する場合に、その要請が遠隔サーバ１０２に送信される必要なしに予め受信された遠隔サーバＵＩリストをエンベデッドサーバ１０６に送信することもできる。
【００２８】
図３を参照すると、ステップ３２１で、遠隔サーバアプリケーション２００は、遠隔サーバＵＩリストをハンドラー１０５に送信し、ステップ３２３で、ハンドラー１０５は、遠隔サーバＵＩリストをエンベデッドサーバ１０６に送信する。ステップ３２５で、エンベデッドサーバ１０６は、ハンドラー１０５から受信された遠隔サーバＵＩリストを第３の端末１００に直接送信するか、またはエンベデッドサーバに含まれているＵＩリストと遠隔サーバから受信された遠隔サーバＵＩリストとを結合（または変形）した後に第３の端末１００に送信するかを判定する。もちろん、エンベデッドサーバ１０６は、上述したいずれかの判定なしにも、ハンドラー１０５から受信された遠隔サーバＵＩリストを第３の端末１００に直接送信する。ステップ３２７で、エンベデッドサーバ１０６は、ＵＩリストを第３の端末１００に送信し、ステップ３２９で、第３の端末１００は、エンベデッドサーバ１０６から受信されたＵＩリストを画面上に表示する。
【００２９】
図４は、本発明の実施形態によるＵＩリストを提供する方法における遠隔サーバがＵＩリストを含まない場合の手順を示すフローチャートである。言い換えれば、図４は、遠隔サーバ１０２が遠隔サーバアプリケーション２００を通してＵＩリストの要請を第３の端末１００から受信する時に遠隔サーバＵＩリストを含まない場合の動作を示す。
【００３０】
図４を参照すると、ステップ４０１で、遠隔サーバ１０２は、遠隔サーバアプリケーション２００を第２の端末１０１に送信する。対応する遠隔サーバアプリケーション２００は、現在遠隔サーバ１０２が提供できるＵＩリストを有していないという情報を含む。ステップ４０３で、遠隔サーバアプリケーション２００が駆動されて実行されると、ステップ４０５で、遠隔サーバアプリケーション２００は、遠隔サーバ１０２が提供できるＵＩリストを有していないという情報をハンドラー１０５に送信し、ステップ４０７で、対応する情報は、エンベデッドサーバ１０６に送信される。この後に、ステップ４０９で、第３の端末１００が第２の端末１０１を発見し、ステップ４１１で、第３の端末１００がＵＩリストを第２の端末１０１に要請すると、ステップ４１３で、第２の端末１０１は、遠隔サーバ１０２が提供できるＵＩリストを含まないという情報をすでに受信したので、ＵＩリストを遠隔サーバ１０２に要請せず第２の端末１０１に含まれているＵＩリストを第３の端末１００に提供する。ステップ４１５で、第３の端末１００は、第２の端末１０１から受信されたＵＩリストを表示する。
【００３１】
図５は、本発明の実施形態によるＵＩリストを提供する方法における第２の端末内の遠隔サーバアプリケーションが動作しない場合の手順を示すフローチャートである。この場合に、ステップ５０１で、第３の端末１００が第２の端末１０１を発見し、ステップ５０３で、第３の端末１００がＵＩリストを第２の端末１０１に要請すると、ステップ５０５で、第２の端末１０１は、第２の端末に含まれているＵＩリストを第３の端末１００に送信する。また、ステップ５０７で、第３の端末１００は、第２の端末１０１から受信されたＵＩリストを表示する。
【００３２】
図６は、本発明の実施形態によるＵＩリストを提供する方法を示すフローチャートであって、オープンＩＰＴＶフォーラム標準に適用される例を示す。以下、オープンＩＰＴＶ端末機能（Open IPTV Terminal Function：ＯＩＴＦ）、宣伝型アプリケーション環境（Declarative Application Environment：ＤＡＥ）、ＤＬＮＡなどのような略語の一般的な定義は、周知の分野でよく知られているオープンＩＰＴＶフォーラム標準を参照してもよいので、ここでは、その詳細な説明を省略する。
【００３３】
図６を参照すると、まず、ステップ６１１で、ＩＰＴＶアプリケーションサーバ６０２は、ＤＡＥアプリケーション６０３をＯＩＴＦ端末６０１に送信する。送信されたＤＡＥアプリケーション６０３は、ステップ６１３でＤＡＥブラウザー６０４で駆動される。この時に、ステップ６１５で、ＩＰＴＶアプリケーションサーバ６０２が遠隔ＵＩリストを含むことをサーバ側ＵＩリスト属性（setServerSideXmlUIListing Property）を用いて遠隔制御プラグイン（Remote Control Plugin）６０５で確立する。単純に、遠隔ＵＩリストの存在に関する情報をＴｒｕｅ／Ｆａｌｓｅで示す。別の方法では、数字又は文字を使用することができる。例えば、“Ｏ”は、ＯＩＴＦ内のＵＩリストの使用を示し、“１”は、ＩＰＴＶアプリケーションサーバ内のＵＩリストの使用を示し、“２”は、２つのＵＬリストの結合の使用を示す。
【００３４】
ステップ６１７で、遠隔制御プラグイン６０５は、このような情報をディジタルリビングネットワークアライアンス（Digital Living Network Alliance：ＤＬＮＡ）遠隔ユーザインターフェースサーバ（Remote User Interface Server：ＲＵＩＳ）６０６に送信する。ステップ６１９で、ＤＬＮＡ遠隔ユーザインターフェースクライアント（ＲＵＩＣ）６００は、ＯＩＴＦ端末６０１を発見し、ステップ６２１で、ＤＬＮＡ ＲＵＩＣ６００は、ＵＩリストの要請をＯＩＴＦ端末６０１に送信する。ステップ６２３で、ＯＩＴＦ端末６０１内のＤＬＮＡ ＲＵＩＳ６０６は、ＩＰＴＶアプリケーションサーバ６０２内のＵＩリストを遠隔制御プラグイン６０５に要請し、ステップ６２５で、遠隔制御プラグイン６０５は、対応するＵＩリストをイベント形態でＤＡＥアプリケーション６０３に要請する。イベントの要請を受信する場合に、ＤＡＥアプリケーション６０３は、ステップ６２７及びステップ６２９で、ＵＩリストをＩＰＴＶアプリケーションサーバ６０２に要請して受信する。
【００３５】
図３を参照して説明したように、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストは、ＤＡＥアプリケーション６０３が駆動された後の時間とＵＩリストの要請が遠隔制御プラグイン６０５から受信される前の時間との間で予め受信され得る。
【００３６】
ステップ６３１で、ＤＡＥアプリケーション６０３は、ＩＰＴＶアプリケーションサーバ６０２から受信されたＵＩリストをメソッドのパラメータを通して遠隔制御プラグイン６０５に送信し、遠隔制御プラグイン６０５は、ステップ６３３で、ＤＡＥアプリケーション６０３から受信されたＵＩリストをＤＬＮＡ ＲＵＩＳ６０６に送信する。ステップ６３５及びステップ６３７で、ＤＬＮＡ ＲＵＩＳ６０６は、ＤＡＥアプリケーション６０３により前に確立された方法に従ってＵＩリストをＤＬＮＡ ＲＵＩＣ６００に送信する。この後に、ステップ６３９で、ＤＬＮＡ ＲＵＩＣ６００は、ＤＬＮＡ ＲＵＩＳ６０６から受信されたＵＩリストを画面上に表示する。
【００３７】
以下に示す表１は、本発明の実施形態に従ってオープンＩＰＴＶフォーラム標準に含まれているＤＡＥスペック（specification）に記述されることができる内容を示す。
【００３８】
【表１】
【００３９】
まず、表１に示す属性は、サーバ側ＸＭＬＵＩリスト（useServerSideXMLUIListing）属性を含む。この属性がＴＲＵＥの値で確立され、ＵＩリストの要請がＤＬＮＡ ＲＵＩＣ装置から受信される場合に、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストを送信する。他方、ＦＡＬＳＥの値が確立される場合に、ＯＩＴＦ端末６０１内のＵＩリストを送信する。
【００４０】
次いで、ステップ６２５で説明したonXmlUIListingRequestイベントは、ＵＩリストの要請をＤＬＮＡ ＲＵＩＣ装置６００から受信する場合にＤＡＥアプリケーション６０３で発生するイベントを示す。
【００４１】
最後に、ステップ６３１で説明したsendXMLUIListingメソッドが含まれる。このメソッドを通して、ＤＡＥアプリケーション６３１は、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストをＤＬＮＡ ＲＵＩＳ６０６を通してＤＬＮＡ ＲＵＩＣ装置６００に送信することができる。
【００４２】
図７は、本発明の実施形態によるＵＩリストを提供する他の方法を示すフローチャートであって、オープンＩＰＴＶフォーラム標準に適用される例を示す。
【００４３】
図７を参照すると、まず、ステップ７０１で、ＩＰＴＶアプリケーションサーバ６０２は、ＤＡＥアプリケーション６０３をＯＩＴＦ端末６０１に送信する。送信されたＤＡＥアプリケーション６０３は、ステップ７０３でＤＡＥブラウザー６０４で駆動される。この時に、ＤＡＥアプリケーション６０３は、ステップ７０５で、遠隔制御プラグイン６０５がＩＰＴＶアプリケーションサーバ６０２から制御ＵＩ（Control UI：以下、“ＣＵＩ”と称する）パッケージ（例えば、圧縮された形態）をダウンロードするように命令する。制御ＵＩパッケージは、ＣＵＩ及び制御ＵＩに対するＵＩリスト（XML UI List）を含む。この時に、このダウンロードされたＣＵＩパッケージは、ＤＬＮＡ ＲＵＩＳ６０６で圧縮解除された後に、１つのＵＩリストは、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストとＣＵＩパッケージに含まれているＵＩリストとを結合することにより得られる。このように、１つのＵＩリストは、ダウンロード及び圧縮解除が実行された後にステップ７０９で得られる。もう１つの場合において、ステップ７０７のように、ＤＡＥアプリケーション６０３は、遠隔制御プラグイン６０５が新たなＵＩリストを作るための情報とともに新たなＵＩリストを作るように命令し、これにより、遠隔制御プラグイン６０５が対応する情報に基づいてＵＩリストを作ることもできる。この時に、命令とともに送信された情報は変わり得る。すなわち、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストとＣＵＩパッケージに含まれているＵＩリストとを結合することにより１つのＵＩリストを生成する情報と、ＣＵＩパッケージに含まれているＵＩリストだけを使用する情報と、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストだけを使用する情報などのような様々な情報を含み得る。対応する情報に基づいてＵＩリストを生成する時に、ＣＵＩパッケージに含まれているＵＩリストでのＵＩに関するＵＲＬ情報がＤＬＮＡ ＲＵＩＣ６００で変更されることにより、ＤＬＮＡ ＲＵＩＳ６０６に設置されたＣＵＩパッケージ内のＣＵＩにアクセスすることができるようにする。
【００４４】
ステップ７０９で、ＵＩリストが対応する情報に基づいて生成される場合に、ステップ７１１で、ＤＬＮＡ ＲＵＩＳ６０６は、新たに生成されたＵＩリストをＤＬＮＡ ＲＵＩＣ６００に送信するためにＵＰｎＰディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージをＤＬＮＡ ＲＵＩＣ６００に送信した後に、ステップ７１３でＵＰｎＰディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを送信する。ここで、ＳＳＤＰは、シンプルサービスディスカバリープロトコル（Simple Service Discovery Protocol）を意味する。
【００４５】
ステップ７１１及びステップ７１３の実行なしに、ステップ７１５でＵＰｎＰディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージだけを送信する場合に、ＤＬＮＡ ＲＵＩＣ６００が前に性能マッチング（Capability Matching）を経験した場合に、前に生成されたＵＩリストに基づいて性能マッチングを行わないこともある。しかしながら、ステップ７１１及びステップ７１３のように、ＳＳＤＰ：ｂｙｅｂｙｅメッセージ及びＳＳＤＰ：ａｌｉｖｅメッセージを送信することにより、ステップ７１５及びステップ７１７で、ＤＬＮＡ ＲＵＩＣ６００は、装置記述（Device description）を通して新たなＸＭＬ ＵＩリストをＤＬＮＡ ＲＵＩＳ６０６から取ってきた後に、ステップ７１９で性能マッチングをさらに実行する。
【００４６】
ＤＬＮＡ ＲＵＩＣ６００が前に性能マッチングを経験したことがないか、又はＤＬＮＡ ＲＵＩＣ６０６が前に性能マッチングを経験したことがない事実がＯＩＴＦ端末６０１に通知されるシナリオを仮定する場合に、ステップ７１１でのＳＳＤＰ：ｂｙｅｂｙｅメッセージを送信せず、ステップ７１３でのＳＳＤＰ：ａｌｉｖｅメッセージだけを送信する。
【００４７】
その後に、ＤＬＮＡ ＲＵＩＣ６００は、ステップ７１９でマッチングされた情報に基づいてステップ７２１及びステップ７２３でＤＬＮＡ ＲＵＩＳ６０６からＣＵＩを受信し、ステップ７２５で、ＤＬＮＡ ＲＵＩＳ６０６から受信されたＣＵＩは、ＤＬＮＡ ＲＵＩＣ６００で表示される。
【００４８】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００４９】
１００ 第３の端末
１０１ 第２の端末
１０２ 遠隔サーバ
１０５ ハンドラー
１０６ エンベデッドサーバ
１１１ ＵＩリスト
２００ 遠隔サーバアプリケーション
【技術分野】
【０００１】
本発明は、一般的に、遠隔ユーザインターフェース（Remote User Interface：以下、“ＲＵＩ”と称する）を使用する遠隔ユーザインターフェース（User Interface：以下、“ＵＩ”と称する）システムに関し、特に、遠隔ＵＩシステムにおける端末に遠隔ＵＩリストを提供する方法及び装置に関する。
【背景技術】
【０００２】
ホームネットワーク技術を向上させるための研究が、ディジタルリビングネットワークアライアンス（Digital Living Network Alliance：ＤＬＮＡ）、ホームオーディオビデオインターオペラビリティ（Home Audio-Video Interoperability：ＨＡＶｉ）、及びユニバーサルプラグアンドプレイ（Universal Plug and Play：ＵＰｎＰ）などのような多くの産業標準団体により活発に進んでいる。
【０００３】
ホームネットワーク技術において、ＲＵＩ技術は、１つの装置が他の装置を制御することができるように使用することができる。一般的に、ＲＵＩ技術は、クライアントサーバアーキテクチャに基づいて、ＲＵＩクライアント（RUI Client）がＲＵＩサーバ（RUI Server）からＵＩを取ってき、これにより、ＲＵＩＣでのユーザがＵＩを通してＲＵＩＳを制御することができるようにする。以下、ＲＵＩを遠隔ＵＩと呼び、ＲＵＩＳを遠隔サーバと呼ぶ。
【０００４】
図１は、従来の遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。図１は、第２の端末１１を発見（discovery）した後にＵＩリストを要請して取ってくる第３の端末１０を示す図である。図１において、第３の端末１０は、ＲＵＩクライアントに対応し、第２の端末１１は、第３の端末１１の要請の時に遠隔ＵＩを提供することができるエンベデッドサーバ（embedded server）を含む他の端末に対応する。
【０００５】
図１を参照すると、第３の端末１０は、第２の端末１１を発見した後に遠隔ＵＩリストを要請することにより第２の端末に含まれる遠隔ＵＩリストを取ってくる。その後に、第３の端末１０は、遠隔ＵＩリスト内の遠隔ＵＩの中の１つを選択し、この選択された遠隔ＵＩを第２の端末１１に要請する。第２の端末１１は、この要請された遠隔ＵＩを第３の端末１０に送信する。
【０００６】
従来の方法において、第３の端末がＵＩリストを第２の端末に要請する場合に、第２の端末は、第２の端末に含まれたＵＩリストのみを提供する。すなわち、第３の端末がＵＩリストを第２の端末に要請する時に、第３の端末が第２の端末と相互接続される他の遠隔サーバ（図示せず）に含まれた他のＵＩリストを取ってくることができない。また、第２の端末内の遠隔ＵＩリストを遠隔サーバ内の遠隔ＵＩリストと結合して使用することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、遠隔ＵＩシステムにおける遠隔ＵＩリストを効率的に提供する方法及び装置を提供することにある。
【０００８】
本発明の他の目的は、遠隔ＵＩシステムにおける端末と遠隔サーバ間の通信を通して遠隔ＵＩリストを効率的に提供する方法及び装置を提供することにある。
【０００９】
本発明のまた他の目的は、遠隔ＵＩシステムにおける通信を通して提供される複数の遠隔ＵＩリストの結合を提供する方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記のような目的を達成するために、本発明の一態様によれば、遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する方法が提供される。上記方法は、遠隔サーバと通信する第１の端末が上記遠隔サーバからダウンロードされたアプリケーションを駆動するステップと、上記第１の端末内のエンベデッドサーバが上記アプリケーションから受信されたメッセージに基づいて、現在上記エンベデッドサーバに含まれているユーザインターフェースリストと上記メッセージに含まれた上記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成するステップと、上記第１の端末内のエンベデッドサーバが第２の端末からユーザインターフェースリストの要請を受信するステップと、上記第１の端末内のエンベデッドサーバが上記生成された新たなユーザインターフェースリストを上記第２の端末に提供するステップとを有することを特徴とする。
【００１１】
本発明の他の態様によれば、遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する端末装置が提供される。上記端末装置は、遠隔サーバからダウンロードされたプリケーションを含むブラウザーと、上記アプリケーションから受信されたメッセージに基づいて、現在のユーザインターフェースリストと上記メッセージに含まれた上記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成し、他の端末からユーザインターフェースリストの要請を受信することに従って上記生成された新たなユーザインターフェースリストを上記他の端末に提供するエンベデッドサーバとを有することを特徴とする。
【発明の効果】
【００１２】
従来技術では、１つの端末が他の端末を通して遠隔サーバに含まれる遠隔ＵＩリストを取ってくることができなかった。さらに、他の端末内の遠隔ＵＩリストを遠隔サーバ内のＵＩリストと結合することができなかった。
【００１３】
本発明によると、ＵＩシステムにおいて、１つの端末が端末間の通信を通して遠隔ＵＩリストを他の端末に要請することができるだけではなく、遠隔サーバに含まれるＵＩリスト及び上記他の端末内のＵＩリストの中の少なくとも１つをＵＩリストを要請する端末に提供することができる。さらに、上記遠隔サーバに含まれるＵＩリストと上記他の端末に含まれるＵＩリストとを結合することにより得られるＵＩリストを遠隔ＵＩリストを要請する端末に提供することができる。
【００１４】
本発明によると、任意の端末がアプリケーションを含む特定の端末に遠隔ＵＩリストを要請することにより、遠隔サーバ内の遠隔ＵＩリスト又は特定の端末内の遠隔ＵＩリストを受信することができ、特定の端末内の遠隔ＵＩリストと遠隔サーバ内の遠隔ＵＩリストとを結合することにより得られた遠隔ＵＩリストを受信することができる。
【図面の簡単な説明】
【００１５】
【図１】従来の遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。
【図２】本発明の実施形態に従って複数の遠隔ＵＩリストを結合し端末に提供するネットワークの構成を示すブロック図である。
【図３】本発明の実施形態による遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートである。
【図４】本発明の実施形態によるＵＩリストを提供する方法における遠隔サーバがＵＩリストを含まない場合の手順を示すフローチャートである。
【図５】本発明の実施形態によるＵＩリストを提供する方法における第２の端末内の遠隔サーバアプリケーションが動作しない場合の手順を示すフローチャートである。
【図６】本発明の実施形態によるＵＩリストを提供する方法を示すフローチャートである。
【図７】本発明の実施形態によるＵＩリストを提供する他の方法を示すフローチャートである。
【発明を実施するための形態】
【００１６】
本発明の詳細な構成および要素のような本発明の詳細な説明で定義される特徴は、本発明の実施形態の包括的な理解を助けるために提供される。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００１７】
以下、ＵＩリストを要請する端末は、“第３の端末”と称し、遠隔サーバを通してＵＩリストを第３の端末に提供する他の端末は、“第２の端末”と称する。
【００１８】
本発明は、単純に第２の端末が第２の端末に含まれたＵＩリストを第３の端末に提供する方法に加えて、第２の端末が遠隔サーバに接続される場合に、第３の端末がＵＩリストを第２の端末に要請する時に、第２の端末が遠隔サーバ内のＵＩリストを受信することができるようにする方案と、第２の端末内の遠隔ＵＩリスト及び遠隔サーバ内の遠隔ＵＩリストの中の少なくとも１つを第３の端末に提供するか又は第２の端末内の遠隔ＵＩリストを遠隔サーバ内の遠隔ＵＩリストと結合することにより提供する方案とを提供する。
【００１９】
本発明は、一般的に、第２の端末が自身に含まれている遠隔ＵＩリストと遠隔サーバに含まれている遠隔ＵＩリストとを結合することにより、この結合された遠隔ＵＩリストを第３の端末に提供するようにし、第３の端末が第２の端末により提供される遠隔ＵＩリストを通して遠隔ＵＩリストを第２の端末に要請するようにする方案を提供する。
【００２０】
このために、本発明は、遠隔サーバが遠隔ＵＩリスト制御情報を第２の端末に提供するようにする方法及び第２の端末がこの提供された制御情報を分析して設定するようにする方法を定義する。また、本発明は、第２の端末が第３の端末から遠隔ＵＩリストの要請を受信する時に、第２の端末が遠隔ＵＩリストを第３の端末に提供するようにする方法を定義する。
【００２１】
本発明の実施形態によると、第３の端末が遠隔ＵＩリストを要請する前に確立された情報に基づいて、第３の端末から遠隔ＵＩリストの要請を受信する時に適切な遠隔ＵＩリストを提供することができる。
【００２２】
以下、本発明の実施形態を具体的に説明する。
本発明の実施形態において、第３の端末は、ＲＵＩクライアントに対応し、第２の端末は、遠隔ＵＩリストを第３の端末に提供することができるエンベデッドサーバを含む端末に対応する。また、第２の端末は、遠隔サーバと通信し、遠隔ＵＩリストを遠隔サーバから受信することができるハンドラー（Handler）を含むと仮定する。
【００２３】
図２は、本発明の実施形態に従って複数の遠隔ＵＩリストを結合し端末に提供するネットワークの構成を示すブロック図である。
【００２４】
図２を参照すると、第３の端末１００は、第２の端末１０１を通して第２の端末１０１内のＵＩリスト１１０と第２の端末１０１に接続された遠隔サーバ１０２内のＵＩリスト１１１とを結合することにより得られたＵＩリストを受信する。遠隔サーバ１０２は、第３の端末１００上に表示されることができるＵＩリストに関する情報を示すＵＩリスト１１１を有し、第２の端末１０１は、ＵＩリストを第３の端末１００に送信する方法及び情報を遠隔サーバ１０２から受信することができるハンドラー１０５を含み、ハンドラー１０５は、ＵＩリスト１１１を遠隔サーバ１０２から受信し、ＵＩリスト１１１をエンベデッドサーバ１０６に送信することができる。第２の端末１０１内のエンベデッドサーバ１０６は、第２の端末１０１に関する情報（ディスクリプション情報）を第３の端末１００に提供することができる。エンベデッドサーバ１０６から受信された第２の端末１０１に関する情報は、第３の端末１００がＵＩリストを第２の端末１０１に要請することができるようにする情報を含む。第３の端末１００は、第２の端末１０１を発見し、第２の端末１０１に関する情報を受信し、ＵＩリストを第２の端末１０１に要請する。第３の端末１００は、第２の端末１０１から受信されたＵＩリストを通してＵＩを受信することができる。
【００２５】
図３は、本発明の実施形態による遠隔ＵＩシステムにおけるＵＩリストを提供する方法を示すフローチャートであって、遠隔サーバ１０２がＵＩリストを含む場合にＵＩリストを提供する。
【００２６】
図３を参照すると、まず、ステップ３０１で、遠隔サーバ１０２は、遠隔サーバアプリケーション２００を第２の端末１０１内のハンドラー１０５に送信する。遠隔サーバアプリケーション２００は、遠隔サーバがＵＩリストを有している情報と、対応する情報を確立する方法及び遠隔サーバアプリケーション２００がＵＩリストに対する要請を第３の端末１００又は第２の端末１０１から受信する場合にこれを処理する方法に関する内容とを含む。ステップ３０３で、送信された遠隔サーバアプリケーション２００は、第２の端末１０１内で動作するように駆動され、ステップ３０５で、遠隔サーバがＵＩリストを含むという情報がハンドラー１０５に送信され、ＵＩリストを処理する方法が確立される。ステップ３０７で、ハンドラー１０５は、この確立されたＵＩリストを処理する方法に関する情報をエンベデッドサーバ１０６に送信する。この時に、必要であれば、エンベデッドサーバ１０６は、ＵＩリストをどのように送信するかも第３の端末１００に通知することができる。この後に、ステップ３０９で、第３の端末１００は、第２の端末１０１を発見し、ステップ３１１で、第３の端末１００は、ＵＩリストを第２の端末１０１に要請した後に、ステップ３１３で、第２の端末１０１内のエンベデッドサーバ１０６は、遠隔サーバアプリケーション２００により確立されたＵＩリストを処理する方法に関する情報に基づいて、第２の端末１０１内のＵＩリストを送信するか又は遠隔サーバ内のＵＩリストを送信するかを判定する。
【００２７】
図３のフローチャートが、遠隔サーバアプリケーション２００が遠隔サーバＵＩリストの存在を通知する情報を含む状態を示すので、ステップ３１５で、エンベデッドサーバ１０６は、遠隔サーバＵＩリストをハンドラー１０５に要請する。ステップ３１７で、ハンドラー１０５は、遠隔サーバＵＩリストを取ってくることを遠隔サーバアプリケーション２００に要請し、ステップ３１９で、遠隔サーバアプリケーション２００は、遠隔サーバＵＩリストを遠隔サーバ１０２に要請する。遠隔サーバアプリケーション２００が遠隔サーバＵＩリストを遠隔サーバ１０２に要請することにより受信する過程は、遠隔サーバアプリケーション２００が駆動されたステップ３０３の後とエンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請するステップ３１５の前との間でいつでも実行される。言い換えれば、エンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請する前に、遠隔サーバアプリケーション２００が予め遠隔サーバＵＩリストを受信し、エンベデッドサーバ１０６が遠隔サーバＵＩリストをハンドラー１０５に要請する場合に、その要請が遠隔サーバ１０２に送信される必要なしに予め受信された遠隔サーバＵＩリストをエンベデッドサーバ１０６に送信することもできる。
【００２８】
図３を参照すると、ステップ３２１で、遠隔サーバアプリケーション２００は、遠隔サーバＵＩリストをハンドラー１０５に送信し、ステップ３２３で、ハンドラー１０５は、遠隔サーバＵＩリストをエンベデッドサーバ１０６に送信する。ステップ３２５で、エンベデッドサーバ１０６は、ハンドラー１０５から受信された遠隔サーバＵＩリストを第３の端末１００に直接送信するか、またはエンベデッドサーバに含まれているＵＩリストと遠隔サーバから受信された遠隔サーバＵＩリストとを結合（または変形）した後に第３の端末１００に送信するかを判定する。もちろん、エンベデッドサーバ１０６は、上述したいずれかの判定なしにも、ハンドラー１０５から受信された遠隔サーバＵＩリストを第３の端末１００に直接送信する。ステップ３２７で、エンベデッドサーバ１０６は、ＵＩリストを第３の端末１００に送信し、ステップ３２９で、第３の端末１００は、エンベデッドサーバ１０６から受信されたＵＩリストを画面上に表示する。
【００２９】
図４は、本発明の実施形態によるＵＩリストを提供する方法における遠隔サーバがＵＩリストを含まない場合の手順を示すフローチャートである。言い換えれば、図４は、遠隔サーバ１０２が遠隔サーバアプリケーション２００を通してＵＩリストの要請を第３の端末１００から受信する時に遠隔サーバＵＩリストを含まない場合の動作を示す。
【００３０】
図４を参照すると、ステップ４０１で、遠隔サーバ１０２は、遠隔サーバアプリケーション２００を第２の端末１０１に送信する。対応する遠隔サーバアプリケーション２００は、現在遠隔サーバ１０２が提供できるＵＩリストを有していないという情報を含む。ステップ４０３で、遠隔サーバアプリケーション２００が駆動されて実行されると、ステップ４０５で、遠隔サーバアプリケーション２００は、遠隔サーバ１０２が提供できるＵＩリストを有していないという情報をハンドラー１０５に送信し、ステップ４０７で、対応する情報は、エンベデッドサーバ１０６に送信される。この後に、ステップ４０９で、第３の端末１００が第２の端末１０１を発見し、ステップ４１１で、第３の端末１００がＵＩリストを第２の端末１０１に要請すると、ステップ４１３で、第２の端末１０１は、遠隔サーバ１０２が提供できるＵＩリストを含まないという情報をすでに受信したので、ＵＩリストを遠隔サーバ１０２に要請せず第２の端末１０１に含まれているＵＩリストを第３の端末１００に提供する。ステップ４１５で、第３の端末１００は、第２の端末１０１から受信されたＵＩリストを表示する。
【００３１】
図５は、本発明の実施形態によるＵＩリストを提供する方法における第２の端末内の遠隔サーバアプリケーションが動作しない場合の手順を示すフローチャートである。この場合に、ステップ５０１で、第３の端末１００が第２の端末１０１を発見し、ステップ５０３で、第３の端末１００がＵＩリストを第２の端末１０１に要請すると、ステップ５０５で、第２の端末１０１は、第２の端末に含まれているＵＩリストを第３の端末１００に送信する。また、ステップ５０７で、第３の端末１００は、第２の端末１０１から受信されたＵＩリストを表示する。
【００３２】
図６は、本発明の実施形態によるＵＩリストを提供する方法を示すフローチャートであって、オープンＩＰＴＶフォーラム標準に適用される例を示す。以下、オープンＩＰＴＶ端末機能（Open IPTV Terminal Function：ＯＩＴＦ）、宣伝型アプリケーション環境（Declarative Application Environment：ＤＡＥ）、ＤＬＮＡなどのような略語の一般的な定義は、周知の分野でよく知られているオープンＩＰＴＶフォーラム標準を参照してもよいので、ここでは、その詳細な説明を省略する。
【００３３】
図６を参照すると、まず、ステップ６１１で、ＩＰＴＶアプリケーションサーバ６０２は、ＤＡＥアプリケーション６０３をＯＩＴＦ端末６０１に送信する。送信されたＤＡＥアプリケーション６０３は、ステップ６１３でＤＡＥブラウザー６０４で駆動される。この時に、ステップ６１５で、ＩＰＴＶアプリケーションサーバ６０２が遠隔ＵＩリストを含むことをサーバ側ＵＩリスト属性（setServerSideXmlUIListing Property）を用いて遠隔制御プラグイン（Remote Control Plugin）６０５で確立する。単純に、遠隔ＵＩリストの存在に関する情報をＴｒｕｅ／Ｆａｌｓｅで示す。別の方法では、数字又は文字を使用することができる。例えば、“Ｏ”は、ＯＩＴＦ内のＵＩリストの使用を示し、“１”は、ＩＰＴＶアプリケーションサーバ内のＵＩリストの使用を示し、“２”は、２つのＵＬリストの結合の使用を示す。
【００３４】
ステップ６１７で、遠隔制御プラグイン６０５は、このような情報をディジタルリビングネットワークアライアンス（Digital Living Network Alliance：ＤＬＮＡ）遠隔ユーザインターフェースサーバ（Remote User Interface Server：ＲＵＩＳ）６０６に送信する。ステップ６１９で、ＤＬＮＡ遠隔ユーザインターフェースクライアント（ＲＵＩＣ）６００は、ＯＩＴＦ端末６０１を発見し、ステップ６２１で、ＤＬＮＡ ＲＵＩＣ６００は、ＵＩリストの要請をＯＩＴＦ端末６０１に送信する。ステップ６２３で、ＯＩＴＦ端末６０１内のＤＬＮＡ ＲＵＩＳ６０６は、ＩＰＴＶアプリケーションサーバ６０２内のＵＩリストを遠隔制御プラグイン６０５に要請し、ステップ６２５で、遠隔制御プラグイン６０５は、対応するＵＩリストをイベント形態でＤＡＥアプリケーション６０３に要請する。イベントの要請を受信する場合に、ＤＡＥアプリケーション６０３は、ステップ６２７及びステップ６２９で、ＵＩリストをＩＰＴＶアプリケーションサーバ６０２に要請して受信する。
【００３５】
図３を参照して説明したように、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストは、ＤＡＥアプリケーション６０３が駆動された後の時間とＵＩリストの要請が遠隔制御プラグイン６０５から受信される前の時間との間で予め受信され得る。
【００３６】
ステップ６３１で、ＤＡＥアプリケーション６０３は、ＩＰＴＶアプリケーションサーバ６０２から受信されたＵＩリストをメソッドのパラメータを通して遠隔制御プラグイン６０５に送信し、遠隔制御プラグイン６０５は、ステップ６３３で、ＤＡＥアプリケーション６０３から受信されたＵＩリストをＤＬＮＡ ＲＵＩＳ６０６に送信する。ステップ６３５及びステップ６３７で、ＤＬＮＡ ＲＵＩＳ６０６は、ＤＡＥアプリケーション６０３により前に確立された方法に従ってＵＩリストをＤＬＮＡ ＲＵＩＣ６００に送信する。この後に、ステップ６３９で、ＤＬＮＡ ＲＵＩＣ６００は、ＤＬＮＡ ＲＵＩＳ６０６から受信されたＵＩリストを画面上に表示する。
【００３７】
以下に示す表１は、本発明の実施形態に従ってオープンＩＰＴＶフォーラム標準に含まれているＤＡＥスペック（specification）に記述されることができる内容を示す。
【００３８】
【表１】
【００３９】
まず、表１に示す属性は、サーバ側ＸＭＬＵＩリスト（useServerSideXMLUIListing）属性を含む。この属性がＴＲＵＥの値で確立され、ＵＩリストの要請がＤＬＮＡ ＲＵＩＣ装置から受信される場合に、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストを送信する。他方、ＦＡＬＳＥの値が確立される場合に、ＯＩＴＦ端末６０１内のＵＩリストを送信する。
【００４０】
次いで、ステップ６２５で説明したonXmlUIListingRequestイベントは、ＵＩリストの要請をＤＬＮＡ ＲＵＩＣ装置６００から受信する場合にＤＡＥアプリケーション６０３で発生するイベントを示す。
【００４１】
最後に、ステップ６３１で説明したsendXMLUIListingメソッドが含まれる。このメソッドを通して、ＤＡＥアプリケーション６３１は、ＩＰＴＶアプリケーションサーバ６０２に含まれているＵＩリストをＤＬＮＡ ＲＵＩＳ６０６を通してＤＬＮＡ ＲＵＩＣ装置６００に送信することができる。
【００４２】
図７は、本発明の実施形態によるＵＩリストを提供する他の方法を示すフローチャートであって、オープンＩＰＴＶフォーラム標準に適用される例を示す。
【００４３】
図７を参照すると、まず、ステップ７０１で、ＩＰＴＶアプリケーションサーバ６０２は、ＤＡＥアプリケーション６０３をＯＩＴＦ端末６０１に送信する。送信されたＤＡＥアプリケーション６０３は、ステップ７０３でＤＡＥブラウザー６０４で駆動される。この時に、ＤＡＥアプリケーション６０３は、ステップ７０５で、遠隔制御プラグイン６０５がＩＰＴＶアプリケーションサーバ６０２から制御ＵＩ（Control UI：以下、“ＣＵＩ”と称する）パッケージ（例えば、圧縮された形態）をダウンロードするように命令する。制御ＵＩパッケージは、ＣＵＩ及び制御ＵＩに対するＵＩリスト（XML UI List）を含む。この時に、このダウンロードされたＣＵＩパッケージは、ＤＬＮＡ ＲＵＩＳ６０６で圧縮解除された後に、１つのＵＩリストは、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストとＣＵＩパッケージに含まれているＵＩリストとを結合することにより得られる。このように、１つのＵＩリストは、ダウンロード及び圧縮解除が実行された後にステップ７０９で得られる。もう１つの場合において、ステップ７０７のように、ＤＡＥアプリケーション６０３は、遠隔制御プラグイン６０５が新たなＵＩリストを作るための情報とともに新たなＵＩリストを作るように命令し、これにより、遠隔制御プラグイン６０５が対応する情報に基づいてＵＩリストを作ることもできる。この時に、命令とともに送信された情報は変わり得る。すなわち、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストとＣＵＩパッケージに含まれているＵＩリストとを結合することにより１つのＵＩリストを生成する情報と、ＣＵＩパッケージに含まれているＵＩリストだけを使用する情報と、ＤＬＮＡ ＲＵＩＳ６０６に含まれているＵＩリストだけを使用する情報などのような様々な情報を含み得る。対応する情報に基づいてＵＩリストを生成する時に、ＣＵＩパッケージに含まれているＵＩリストでのＵＩに関するＵＲＬ情報がＤＬＮＡ ＲＵＩＣ６００で変更されることにより、ＤＬＮＡ ＲＵＩＳ６０６に設置されたＣＵＩパッケージ内のＣＵＩにアクセスすることができるようにする。
【００４４】
ステップ７０９で、ＵＩリストが対応する情報に基づいて生成される場合に、ステップ７１１で、ＤＬＮＡ ＲＵＩＳ６０６は、新たに生成されたＵＩリストをＤＬＮＡ ＲＵＩＣ６００に送信するためにＵＰｎＰディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージをＤＬＮＡ ＲＵＩＣ６００に送信した後に、ステップ７１３でＵＰｎＰディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを送信する。ここで、ＳＳＤＰは、シンプルサービスディスカバリープロトコル（Simple Service Discovery Protocol）を意味する。
【００４５】
ステップ７１１及びステップ７１３の実行なしに、ステップ７１５でＵＰｎＰディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージだけを送信する場合に、ＤＬＮＡ ＲＵＩＣ６００が前に性能マッチング（Capability Matching）を経験した場合に、前に生成されたＵＩリストに基づいて性能マッチングを行わないこともある。しかしながら、ステップ７１１及びステップ７１３のように、ＳＳＤＰ：ｂｙｅｂｙｅメッセージ及びＳＳＤＰ：ａｌｉｖｅメッセージを送信することにより、ステップ７１５及びステップ７１７で、ＤＬＮＡ ＲＵＩＣ６００は、装置記述（Device description）を通して新たなＸＭＬ ＵＩリストをＤＬＮＡ ＲＵＩＳ６０６から取ってきた後に、ステップ７１９で性能マッチングをさらに実行する。
【００４６】
ＤＬＮＡ ＲＵＩＣ６００が前に性能マッチングを経験したことがないか、又はＤＬＮＡ ＲＵＩＣ６０６が前に性能マッチングを経験したことがない事実がＯＩＴＦ端末６０１に通知されるシナリオを仮定する場合に、ステップ７１１でのＳＳＤＰ：ｂｙｅｂｙｅメッセージを送信せず、ステップ７１３でのＳＳＤＰ：ａｌｉｖｅメッセージだけを送信する。
【００４７】
その後に、ＤＬＮＡ ＲＵＩＣ６００は、ステップ７１９でマッチングされた情報に基づいてステップ７２１及びステップ７２３でＤＬＮＡ ＲＵＩＳ６０６からＣＵＩを受信し、ステップ７２５で、ＤＬＮＡ ＲＵＩＳ６０６から受信されたＣＵＩは、ＤＬＮＡ ＲＵＩＣ６００で表示される。
【００４８】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００４９】
１００ 第３の端末
１０１ 第２の端末
１０２ 遠隔サーバ
１０５ ハンドラー
１０６ エンベデッドサーバ
１１１ ＵＩリスト
２００ 遠隔サーバアプリケーション
【特許請求の範囲】
【請求項１】
遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する方法であって、
遠隔サーバと通信する第１の端末が前記遠隔サーバからダウンロードされたアプリケーションを駆動するステップと、
前記第１の端末内のエンベデッドサーバが前記アプリケーションから受信されたメッセージに基づいて、現在前記エンベデッドサーバに含まれているユーザインターフェースリストと前記メッセージに含まれた前記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成するステップと、
前記第１の端末内のエンベデッドサーバが第２の端末からユーザインターフェースリストの要請を受信するステップと、
前記第１の端末内のエンベデッドサーバが前記生成された新たなユーザインターフェースリストを前記第２の端末に提供するステップと
を有することを特徴とするユーザインターフースリストを提供する方法。
【請求項２】
前記新たなユーザインターフェースリストを生成するステップは、
前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイ（ＵＰｎＰ）ディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージを前記第２の端末に送信するステップと、
前記新たなユーザインターフェースリストを生成した後に、前記新たなユーザインターフェースリストを受信する必要があることを前記第２の端末に通知するために前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイ（ＵＰｎＰ）ディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信するステップと
を有することを特徴とする請求項１に記載のユーザインターフェースリストを提供する方法。
【請求項３】
前記新たなユーザインターフェースリストを生成するステップは、
前記第１の端末内のエンベデッドサーバが前記第２の端末と性能マッチングを実行するか又は前記ユーザインターフェースリストを前記第２の端末に提供する履歴を有しない場合に、前記新たなユーザインターフェースリストを生成した後に前記新たなユーザインターフェースリストを受信する必要があることを前記第２の端末に通知するために、前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信するステップを有することを特徴とする請求項１に記載のユーザインターフェースリストを提供する方法。
【請求項４】
前記第１の端末内のエンベデッドサーバが前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信した後に前記第２の端末と性能マッチングを実行するステップをさらに有することを特徴とする請求項２に記載のユーザインターフェースリストを提供する方法。
【請求項５】
前記第１の端末内のエンベデッドサーバが前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信した後に前記第２の端末と性能マッチングを実行するステップをさらに有することを特徴とする請求項３に記載のユーザインターフェースリストを提供する方法。
【請求項６】
遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する端末装置であって、
遠隔サーバからダウンロードされたアプリケーションを含むブラウザーと、
前記アプリケーションから受信されたメッセージに基づいて、現在のユーザインターフェースリストと前記メッセージに含まれた前記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成し、他の端末からユーザインターフェースリストの要請を受信することに従って前記生成された新たなユーザインターフェースリストを前記他の端末に提供するエンベデッドサーバと
を有することを特徴とする端末装置。
【請求項７】
前記エンベデッドサーバは、前記新たなユーザインターフェースリストを生成した後に、前記新たなユーザインターフェースリストを受信する必要があることを前記他の端末に通知するためにユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージを前記他の端末に送信した後にユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを送信することを特徴とする請求項６に記載の端末装置。
【請求項８】
前記エンベデッドサーバは、前記他の端末と性能マッチングを実行するか又は前記ユーザインターフェースリストを前記他の端末に提供する履歴を有しない場合に、前記新たなユーザインターフェースリストを生成した後に前記新たなユーザインターフェースリストを受信する必要があることを前記他の端末に通知するために、ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信することを特徴とする請求項６に記載の端末装置。
【請求項９】
前記エンベデッドサーバは、前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信した後に前記他の端末と性能マッチングを実行することを特徴とする請求項６に記載の端末装置。
【請求項１０】
前記エンベデッドサーバは、前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信した後に前記他の端末と性能マッチングを実行することを特徴とする請求項７に記載の端末装置。
【請求項１】
遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する方法であって、
遠隔サーバと通信する第１の端末が前記遠隔サーバからダウンロードされたアプリケーションを駆動するステップと、
前記第１の端末内のエンベデッドサーバが前記アプリケーションから受信されたメッセージに基づいて、現在前記エンベデッドサーバに含まれているユーザインターフェースリストと前記メッセージに含まれた前記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成するステップと、
前記第１の端末内のエンベデッドサーバが第２の端末からユーザインターフェースリストの要請を受信するステップと、
前記第１の端末内のエンベデッドサーバが前記生成された新たなユーザインターフェースリストを前記第２の端末に提供するステップと
を有することを特徴とするユーザインターフースリストを提供する方法。
【請求項２】
前記新たなユーザインターフェースリストを生成するステップは、
前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイ（ＵＰｎＰ）ディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージを前記第２の端末に送信するステップと、
前記新たなユーザインターフェースリストを生成した後に、前記新たなユーザインターフェースリストを受信する必要があることを前記第２の端末に通知するために前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイ（ＵＰｎＰ）ディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信するステップと
を有することを特徴とする請求項１に記載のユーザインターフェースリストを提供する方法。
【請求項３】
前記新たなユーザインターフェースリストを生成するステップは、
前記第１の端末内のエンベデッドサーバが前記第２の端末と性能マッチングを実行するか又は前記ユーザインターフェースリストを前記第２の端末に提供する履歴を有しない場合に、前記新たなユーザインターフェースリストを生成した後に前記新たなユーザインターフェースリストを受信する必要があることを前記第２の端末に通知するために、前記第１の端末内のエンベデッドサーバがユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信するステップを有することを特徴とする請求項１に記載のユーザインターフェースリストを提供する方法。
【請求項４】
前記第１の端末内のエンベデッドサーバが前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信した後に前記第２の端末と性能マッチングを実行するステップをさらに有することを特徴とする請求項２に記載のユーザインターフェースリストを提供する方法。
【請求項５】
前記第１の端末内のエンベデッドサーバが前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記第２の端末に送信した後に前記第２の端末と性能マッチングを実行するステップをさらに有することを特徴とする請求項３に記載のユーザインターフェースリストを提供する方法。
【請求項６】
遠隔ユーザインターフェース（ＵＩ）システムにおけるユーザインターフェースリストを提供する端末装置であって、
遠隔サーバからダウンロードされたアプリケーションを含むブラウザーと、
前記アプリケーションから受信されたメッセージに基づいて、現在のユーザインターフェースリストと前記メッセージに含まれた前記遠隔サーバのユーザインターフェースリストとを結合することにより新たなユーザインターフェースリストを生成し、他の端末からユーザインターフェースリストの要請を受信することに従って前記生成された新たなユーザインターフェースリストを前記他の端末に提供するエンベデッドサーバと
を有することを特徴とする端末装置。
【請求項７】
前記エンベデッドサーバは、前記新たなユーザインターフェースリストを生成した後に、前記新たなユーザインターフェースリストを受信する必要があることを前記他の端末に通知するためにユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ｂｙｅｂｙｅ）メッセージを前記他の端末に送信した後にユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを送信することを特徴とする請求項６に記載の端末装置。
【請求項８】
前記エンベデッドサーバは、前記他の端末と性能マッチングを実行するか又は前記ユーザインターフェースリストを前記他の端末に提供する履歴を有しない場合に、前記新たなユーザインターフェースリストを生成した後に前記新たなユーザインターフェースリストを受信する必要があることを前記他の端末に通知するために、ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信することを特徴とする請求項６に記載の端末装置。
【請求項９】
前記エンベデッドサーバは、前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信した後に前記他の端末と性能マッチングを実行することを特徴とする請求項６に記載の端末装置。
【請求項１０】
前記エンベデッドサーバは、前記ユニバーサルプラグインプレイディスカバリー（ＳＳＤＰ：ａｌｉｖｅ）メッセージを前記他の端末に送信した後に前記他の端末と性能マッチングを実行することを特徴とする請求項７に記載の端末装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１３−５１２５００（Ｐ２０１３−５１２５００Ａ）
【公表日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１２−５４１０３１（Ｐ２０１２−５４１０３１）
【出願日】平成２２年１２月３日（２０１０．１２．３）
【国際出願番号】ＰＣＴ／ＫＲ２０１０／００８６３２
【国際公開番号】ＷＯ２０１１／０６８３８１
【国際公開日】平成２３年６月９日（２０１１．６．９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２２年１２月３日（２０１０．１２．３）
【国際出願番号】ＰＣＴ／ＫＲ２０１０／００８６３２
【国際公開番号】ＷＯ２０１１／０６８３８１
【国際公開日】平成２３年６月９日（２０１１．６．９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]