JP2003280731A

JP2003280731A - 制御仲介サーバ、制御機器及び制御対象機器

Info

Publication number: JP2003280731A
Application number: JP2002078918A
Authority: JP
Inventors: Haruyuki Kitawaki; 晴之北脇
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2002-03-20
Filing date: 2002-03-20
Publication date: 2003-10-02

Abstract

(57)【要約】【課題】制御機器と対象機器とを仲介するサーバを設
け、様々なユーザインタフェース（ＵＩ）をユーザに提
供する。【解決手段】制御の対象となる複数の対象機器１５０
及び対象機器１６０をコントロール機器１００から制御
する際に該制御を仲介するサーバ１３０が提供される。
対象機器１５０等の状態を予め登録しておき、コントロ
ール機器１００からＵＩの定義データを要求されると、
登録されている対象機器の状態に対応した定義データを
選択する。選択された定義データはコントロール機器１
００に送信される。コントロール機器１００は、定義デ
ータに基づいて提供されるユーザインタフェースに従っ
て対象機器を制御するためのコマンドを発行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本願発明は、ネットワークに
接続されたコントロール機器、このコントロール機器に
よる制御の対象となる対象機器、及び、制御機器及び対
象機器を仲介するサーバとを含むネットワークシステム
に係り、とりわけ、サーバを介して対象機器を制御する
ためのユーザインタフェースを制御機器に提供する方法
に関する。

【０００２】

【従来の技術】ネットワーク上に存在する機器をコント
ロールする技術として、例えば、ＵＰｎＰ（Universal
Plug and Play）が知られている。

【０００３】この技術では、制御の対象となる機器をＵ
ＰｎＰデバイスと呼び、制御の主体となる機器をＵＰｎ
Ｐコントロールポイントと定義している。ＵＰｎＰコン
トロールポイントは、ＵＤＰ（User Datagram Protoco
l）を用いてブロードキャストを行い、ＵＰｎＰデバイ
スを発見する。ＵＰｎＰコントロールポイントは、発見
したＵＰｎＰデバイスにアクセスし、ディスクリプショ
ンを取得する。このディスクリプションとは、ＵＰｎＰ
デバイスの機能を定義したデータのことである。ＵＰｎ
Ｐコントロールポイントは、定義データに基づいて命令
を発行し、ＵＰｎＰデバイスをコントロールする。

【０００４】ＵＰｎＰでは、Presentationという機能を
定義している。この機能は、ＵＰｎＰデバイスを制御す
るためのユーザインタフェースをＵＰｎＰコントロー
ルに提供する機能である。ユーザインタフェースの定義
データは、presentation pageと呼ばれ、ＵＰｎＰデバ
イスがＵＰｎＰコントロールポイントに提供するもので
ある。

【０００５】ＵＰｎＰデバイスは子のＵＰｎＰデバイス
を持つことができる。子のＵＰｎＰデバイスにも専用の
presentation pageを定義でき、UPｎPコントロールポイ
ントはpresentation pageを用いて子のＵＰｎＰデバイ
スを個々にコントロールすることができる。

【０００６】

【発明が解決しようとする課題】しかしながら、ＵＰｎ
Ｐは、単体の機器をコントロールするためのユーザイン
タフェース定義データを提供する方法に過ぎず、複数の
機器を統合してコントロールするためのユーザインタフ
ェース定義データを提供することができない。あくまで
１つ１つのUPｎPデバイスをコントロールするpresentat
ion-pageを提供することができるだけであり、複数のpr
esentation-pageから複数のUPnPデバイスを統合してコ
ントロールすることはできない。

【０００７】また、複数の制御機器から少なくとも１つ
の対象機器を制御するためのユーザインタフェース定義
データを提供することもできない。つまり、複数の機器
が連動した場合に、それに適したユーザインタフェース
を提供することが困難であった。

【０００８】そこで、本願発明は、制御機器と対象機器
とを仲介し、複数の機器を統合してコントロールできる
ユーザインタフェースの定義データを制御機器に送信す
るサーバを提供することを目的とする。

【０００９】

【課題を解決するための手段】上記課題を解決すべく、
本願発明の第１の観点によれば、制御の対象となる複数
の制御対象機器を制御機器から制御する際に該制御を仲
介する制御仲介サーバであって、前記制御対象機器の状
態に関する状態関連情報を前記制御対象機器のそれぞれ
から受信する受信手段と、前記制御機器からの要求に応
じて、前記受信された複数の状態関連情報に対応するユ
ーザインタフェースの定義データを選択する選択手段
と、前記選択された定義データを前記制御機器に送信す
る送信手段と、を含み、前記制御機器は、前記送信され
た定義データに基づいて提供されるユーザインタフェー
スに従って前記複数の制御対象機器を統合制御すること
を特徴とする制御仲介サーバが提供される。

【００１０】このように、複数の制御対象機器を制御す
るためのユーザインタフェースを記述した定義データを
サーバから制御機器に提供することで、ユーザは、単独
のユーザインタフェースを通じて複数の制御対象機器を
統合的に制御することが可能となる。

【００１１】好適な実施形態によれば、前記選択手段
は、前記制御機器の種別及び前記状態関連情報に基づい
て、対応する定義データを選択するようにしてもよい。
このようにすれば、制御機器及び制御対象機器の組み合
わせ一つ一つごとに定義データを用意する必要がなくな
り、例えば、携帯電話ごとやＰＤＡごとに定義データを
用意すれば良いため、必要となるデータベースを簡潔に
することができよう。

【００１２】好適な実施形態によれば、前記受信手段
は、さらに前記制御機器の状態に関する状態関連情報を
受信し、前記選択手段は、前記制御機器の状態関連情報
及び前記制御対象機器の状態関連情報に基づいて、対応
する定義データを選択するようにしてもよい。すなわ
ち、制御対象機器だけでなく制御機器にも様々な動作状
態が存在するため、その動作状態を考慮してより適した
定義データを提供することができる。

【００１３】好適な実施形態によれば、前記制御対象機
器の状態が変更されると、該制御対象機器から送信され
る状態更新情報に基づいて、前記定義データを更新する
更新手段をさらに含み、前記更新手段により更新が実行
されると、前記送信手段は、更新された定義データを前
記制御機器に送信するようにしてもよい。例えば、動作
状態などの変更に応じて、ユーザインタフェースを変更
することが好ましい場合が存在する。そのような場合に
対処すべく、制御対象機器の状態の変更に応じて定義デ
ータを更新してもよい。

【００１４】好適な実施形態によれば、前記選択手段
は、複数の前記制御機器に対してそれぞれ異なる定義デ
ータを選択してもよい。すなわち、制御機器の種類が異
なる場合だけでなく、種類が同一の場合であってもそれ
ぞれ異なるユーザインタフェースを提供することが望ま
しい場合がある。例えば、プレゼンテーションの説明者
と、その観客とがそれぞれ制御機器たる携帯電話を有し
ている場合には、それぞれの役割に応じて、それぞれ異
なるユーザインタフェースを提供することが望ましいで
あろう。そのような場合に、本願発明は効果的に適用で
きる。

【００１５】好適な実施形態によれば、前記制御対象機
器により送信されるコンテンツデータを所定規則に基づ
いて加工する加工手段をさらに含み、前記加工されたコ
ンテンツデータは前記送信手段により前記制御機器に送
信されるようにしてもよい。なお、コンテンツデータと
は、画像、動画、音声、音楽及び文字データなどの情報
をいう。

【００１６】例えば、複数の制御対象機器からの画像を
マージして１つの画像として制御機器に提供することが
可能となる。そのため、ユーザは、複数の制御対象機器
を切り替えて、１つずつ画像を見る手間を省ける。

【００１７】また、前記制御対象機器の状態が変更され
ると、前記加工手段は、前記所定規則を変更し、変更後
の所定規則でもって前記コンテンツデータを加工するよ
うにしてもよい。

【００１８】例えば、４つのネットワークカメラから取
得した４つの画像をマージ処理して一の画面として制御
機器に提供しているときに、一台のネットワークカメラ
からの画像送信が途絶えると、加工方法を無加工に変更
し、４分割表示用の画像を提供することができる。

【００１９】好適な実施形態によれば、前記複数の制御
対象機器の相互関連性又は前記複数のコンテンツデータ
の相互関連性を検出する検出手段をさらに備え、前記加
工手段は、前記検出された相互関連性に基づいて所定規
則を決定し、前記複数のコンテンツデータを加工するよ
うにしてもよい。例えば、複数の画像をマージする際に
は、画像の連続性を検出することで、連続した１つの画
像を提供することができよう。

【００２０】前記定義データは、ＸＭＬ形式、テキスト
形式、ハイパーテキスト形式又はバイナリ形式にて記述
されていてもよい。とりわけ、ＸＭＬ形式であれば、規
則をタグにより表現できるため、拡張性の点で優れてい
よう。

【００２１】本願発明の第２の観点によれば、上記の制
御仲介サーバから定義データを受信する手段、該定義デ
ータに基づいて提供されるユーザインタフェースを表示
する手段と、前記ユーザインタフェースに応じて前記複
数の制御対象機器を統合的に制御するための命令情報を
送信する手段とを含むことを特徴とする制御機器が提供
される。

【００２２】すなわち、制御仲介サーバにより提供され
た定義データに基づいて、複数の制御機器を制御するこ
とが可能なユーザインタフェースを、ユーザに対し提供
することができよう。

【００２３】好適な実施形態によれば、制御仲介サーバ
がネットワーク上に存在するかを検出する検出手段と、
前記制御サーバが存在する場合には該制御サーバに定義
データを要求し、前記制御サーバが存在しない場合には
前記制御対象機器に定義データを要求する要求手段とを
備えてもよい。すなわち、制御仲介サーバが存在してい
るときには、こちらを優先して定義データを取得し、ユ
ーザに付加価値の高い制御環境を提供できよう。

【００２４】前記制御機器は、例えば、携帯電話、ブラ
ウザフォン、ＰＤＡまたはＰＣなどであるが、もちろん
これらは、専用の制御機器であってもよいし、汎用の制
御機器であっても良い。要するに定義データを解釈し、
ユーザインタフェースを提供できるのであれば機種の種
別は問わない。

【００２５】本願発明の第３の観点によれば、上記の制
御機器により制御される制御対象機器であって、前記状
態関連情報を取得する手段と、前記取得された状態関連
情報を前記制御仲介サーバに送信する手段と、前記制御
機器からの命令情報を受信する手段と、前記命令情報に
基づいた所定処理を実行する手段と、前記所定処理の実
行結果を前記制御機器又は前記制御仲介サーバに送信す
る手段とを含むことを特徴とする制御対象機器が提供さ
れる。

【００２６】本願発明の第４の観点によれば、制御の対
象となる複数の制御対象機器を制御機器から制御する際
に該制御機器の補助を行う制御仲介サーバであって、前
記制御対象機器と前記制御機器との組み合わせに基づい
て決定されるユーザインタフェースの定義データを管理
するデータベースと、前記制御対象機器のうち現在制御
可能な制御対象機器と、前記制御補助対象機器に前記定
義データを要求してきた制御機器とを検索キーとして前
記データベースを検索する検索手段と、前記検索により
抽出された定義データを前記制御機器に送信する送信手
段と、を含み、前記制御機器は前記送信された定義デー
タに基づいて提供されるユーザインタフェースに従って
前記複数の制御対象機器を制御することを特徴とする制
御仲介サーバが提供される。

【００２７】このような構成によっても第１の観点と同
様の効果が得られよう。

【００２８】好適な実施形態によれば、前記検索手段
は、前記制御機器の種別情報及び前記制御対象機器の種
別情報を検索キーとして検索を実行してもよい。

【００２９】

【発明の実施の形態】以下に本願発明の一実施形態を示
す。もちろん以下の実施形態は、本願発明の技術分野に
おける当業者による実施を容易にするために開示を提供
するものであり、特許請求の範囲によって確定される本
願発明の技術的範囲に含まれるほんの一部の実施形態に
すぎない。従って、本願明細書に直接的に記載されてい
ない実施形態であっても、技術思想が共通する限り本願
発明の技術的範囲に包含されることは当業者にとって自
明であろう。

【００３０】なお、便宜上複数の実施形態を記載する
が、これらは個別に発明として成立するだけでなく、も
ちろん、複数の実施形態を適宜組み合わせることでも発
明が成立することは、当業者であれば容易に理解できよ
う。

【００３１】［実施形態１］はじめに本実施形態で使用
する用語を定義する。「コントロール機器」とは、携帯
電話（ブラウザフォンなど）、ＰＤＡ及びＰＣなどであ
って、制御の主体となる機器をいう。「対象機器」と
は、コントロール機器により制御される機器をいう。
「サーバ」とは、対象機器の状態情報などを保存する機
器であり、本実施形態の中核をなす機器である。

【００３２】また、本実施形態に係る各機器間で送受信
されるデータはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒ
ｋｕｐＬａｎｇｕａｇｅ）形式に準拠しているが、も
ちろん、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐ
Ｌａｎｇｕａｇｅ）形式、テキスト形式及びバイナリ
形式など他のデータ形式であってもよい。

【００３３】実施形態１では、１台のコントロール機器
により１台以上の対象機器をコントロールする例を示
す。

【００３４】図１は、本実施形態に係るシステムの構成
例を示す図である。コントロール機器１００は、携帯電
話、ＰＤＡ、ノートＰＣ又はＰＣなどであり、アクセス
ポイント１１０及びグローバルネットワーク１２０を介
してサーバ１３０にアクセスする。本実施形態では、コ
ントロール機器１００を携帯電話と仮定する。コントロ
ール機器１００によりアクセスされるアクセスポイント
とは、携帯電話の基地局、ブルートゥースのアクセスポ
イント、無線ＬＡＮのアクセスポイント又はユビキタス
ネットワークの基地局などである。グローバルネットワ
ーク１２０は、例えば、インターネット、イントラネッ
ト及びピコネットなどである。ローカルネットワーク１
４０は、グローバルネットワーク１２０に接続されてい
る。ローカルネットワーク１４０は、例えば、インター
ネットプロトコルに準拠したＬＡＮやブルートゥースの
ピコネットなどである。ローカルネットワーク１４０に
は、複数の対象機器が接続されている。対象機器は、例
えばプロジェクタ１５０、動画撮影カメラ１６０、ノー
トＰＣ及びＰＣなどであり、ローカルネットワーク１４
０を介してサーバ１３０と通信可能なも機器であれば種
類は問わない。プロジェクタ１５０は、プレゼンテーシ
ョンファイルの保存処理、表示処理及び切り替え処理な
どを実行する。

【００３５】図２は、コントロール機器としての携帯電
話１００に係る例示的なブロック図である。ＣＰＵ２０
１は、携帯電話の各部を統合的に制御するための演算装
置である。ＲＯＭ２０２には、基本ＯＳやブラウザプロ
グラムなどを格納する記憶装置である。ＲＡＭ２０３
は、各種プログラムを実行する際のワークエリアとなる
記憶装置である。無線部２０４は、アクセスポイントと
通信するための通信規格に準拠した通信回路である。操
作部２０５は、後述のようにテンキーやカーソルキーな
どからなる入力装置である。ＬＣＤ部２０６は、液晶表
示装置（ＬＣＤ）とＬＣＤ駆動回路を含む表示装置装置
である。

【００３６】例えば、上記の制御仲介サーバ（サーバ１
３０）から定義データを受信する手段（例：無線部２０
４、ＣＰＵ２０１）、該定義データに基づいて提供され
るユーザインタフェースを表示する手段（例：ＬＣＤ部
２０６）と、前記ユーザインタフェースに応じて前記制
御対象機器を制御するための命令情報を送信する手段
（例：無線部２０４、ＣＰＵ２０１）とを含むことを特
徴とする制御機器（コントロール機器１００）が提供さ
れる。

【００３７】図３は、制御仲介サーバとしてのサーバ１
３０に係る例示的なブロック図である。ＣＰＵ３０１
は、サーバの各部を統合的に制御するための演算装置で
ある。ＲＯＭ３０２には、ＢＩＯＳなどの基本プログラ
ムを格納する記憶装置である。ＲＡＭ３０３は、各種プ
ログラムを実行する際のワークエリアとなる記憶装置で
ある。通信インタフェース３０４は、ＩＥＥＥ８０２．
３などのネットワーク規格に準拠した通信を行うための
通信回路である。操作部３０５は、キーボードやポイン
ティングデバイスなどの入力装置である。表示部２０６
は、外部に接続されたモニターに映像信号を出力するた
めの表示回路である。ハードディスクドライブ（ＨＤ
Ｄ）３０７は、基本ＯＳや本実施形態に係るアプリケー
ションプログラム及び後述の状態管理リスト３１０、ユ
ーザインタフェース（ＵＩ）定義データの決定テーブル
３２０及びクライアント管理テーブル３３０及びＵＩ定
義データ（不図示）などを記憶する記憶装置である。

【００３８】これらの構成により、例えば、制御の対象
となる複数の制御対象機器（例：対象機器１５０及び対
象機器１６０）を制御機器（例：コントロール機器１０
０）から制御する際に該制御を仲介する制御仲介サーバ
（例：サーバ１３０）であって、前記制御対象機器の状
態に関する状態関連情報を受信する受信手段（例：ＣＰ
Ｕ３０１、通信インタフェース３０４）と、前記制御機
器からの要求に応じて、前記受信された状態関連情報に
対応するユーザインタフェースの定義データを選択する
選択手段（例：ＣＰＵ３０１）と、前記選択された定義
データを前記制御機器に送信する送信手段（例：ＣＰＵ
３０１、通信インタフェース３０４）と、を含み、前記
制御機器は、前記送信された定義データに基づいて提供
されるユーザインタフェースに従って前記制御対象機器
を制御することを特徴とする制御仲介サーバが提供され
る。

【００３９】また、制御の対象となる１以上の制御対象
機器を制御機器から制御する際に該制御機器の補助を行
う制御仲介サーバであって、前記制御対象機器と前記制
御機器との組み合わせに基づいて決定されるユーザイン
タフェースの定義データを管理するデータベース（例：
ＣＰＵ３０１、ＨＤＤ３０７）と、前記制御対象機器の
うち現在制御可能な制御対象機器と、前記制御補助対象
機器に前記定義データを要求してきた制御機器とを検索
キーとして前記データベースを検索する検索手段（例：
ＣＰＵ３０１）と、前記検索により抽出された定義デー
タを前記制御機器に送信する送信手段（例：ＣＰＵ３０
１、通信インタフェース３０４）と、を含む制御仲介サ
ーバを提供することができる。

【００４０】図４は、対象機器に係る例示的なブロック
図である。ＣＰＵ４０１は、対象機器の各部を統合的に
制御するための演算装置である。ＲＯＭ４０２には、基
本ＯＳやブラウザプログラムなどを格納する記憶装置で
ある。ＲＡＭ４０３は、各種プログラムを実行する際の
ワークエリアとなる記憶装置である。通信インタフェー
ス部４０４は、ＩＥＥＥ８０２．３などのネットワーク
規格に準拠した通信を行うための通信回路である。操作
部４０５は、テンキーやカーソルキーなどからなる入力
装置である。表示部４０６は、液晶表示装置（ＬＣＤ）
とＬＣＤ駆動回路を含む表示装置である。固有機構部４
０７は、対象機器に装備されている固有の機構と当該機
構を制御するための制御回路などを含んでいる。対象機
器がプロジェクタ１５０であれば、固有機構部４０７に
は、投影用のＬＣＤ、ＬＣＤ駆動回路及び光源などが含
まれる。また、対象機器が動画撮影カメラ１６０であれ
ば、固有機構部４０７には、レンズ駆動機構、ＣＣＤ、
映像回路及び記録回路などが含まれよう。

【００４１】これらの構成により、上記の制御機器
（例：コントロール機器１００）により制御される制御
対象機器（例：対象機器１５０又は対象機器１６０）で
あって、前記状態関連情報を取得する手段（例：ＣＰＵ
４０１）と、前記取得された状態関連情報を前記制御仲
介サーバに送信する手段（例：ＣＰＵ４０１、通信イン
タフェース４０４）と、前記制御機器からの命令情報を
受信する手段と、前記命令情報に基づいた所定処理を実
行する手段（例：ＣＰＵ４０１）と、前記所定処理の実
行結果を前記制御機器又は前記制御仲介サーバに送信す
る手段（例：ＣＰＵ４０１、通信インタフェース４０
４）とを含むことを特徴とする制御対象機器が提供され
る。

【００４２】次に、対象機器の一例であるプロジェクタ
１５０により表示される画像をコントロール機器１００
にも表示する方法について説明する。なお、動画撮影カ
メラ１６０により撮影された映像についても同様にコン
トロール機器１００の表示部に表示してもよい。

【００４３】図５は、対象機器の画面サイズを示した図
である。図６は、コントロール機器の画面サイズを示し
た図である。対象機器は幅Ｘ、高さＹの画面サイズを持
ち、画面上のある座標（×で示す）は（ＰＸ、ＰＹ）を
持つとする。同様に、コントロール機器１００は幅ｘ、
高さｙの画面サイズを持ち、画面上のある座標（×で示
す）は（ｐｘ、ｐｙ）を持つとする。対象機器の画像を
コントロール機器の画面全体に表示する場合、幅Ｘ、高
さＹの画像は、幅はｘ／Ｘ倍、高さはｙ／Ｙ倍される。
コントロール機器の座標（ｐｘ，ｐｙ）は、ｐｘ＝Ｐ
Ｘ（ｘ／Ｘ），ｐｙ＝ＰＹ（ｙ／Ｙ）の式より算出され
る。対象機器の画像がＸ＞Ｙであり、コントロール機
器の画面がｘ＝ｙであり、縦横の比率を変えずに表示し
たい場合は、ｐｘ＝ＰＸ（ｘ／Ｘ），ｐｙ＝ＰＹ（ｘ
／Ｘ）となる。

【００４４】例えばＸ＝８００、Ｙ＝６００、ｘ＝２５
６，ｙ＝２５６でＸ，Ｙの縦横比を変えずに表示した
い場合、コントロール機器に表示される画像はｘ＝２５
６，ｙ＝６００（２５６／８００）＝１９２のサイズに
なる。図５のような座標軸があり、画面左下を基点
（０，０）とすると、座標（ＰＸ，ＰＹ）＝（６０
０，４００）は、（ｐｘ，ｐｙ）＝（６００（２５
６／８００），４００（２５６／８００））＝（１９
２，１２８）と算出される。上記の計算式で、割り算の
結果は整数以下切り捨てとする。

【００４５】図７は、対象機器の動作例を示すフローチ
ャートである。対象機器１５０、対象機器１６０の電源
がＯＮにされると、本フローチャートは実行される。

【００４６】ステップＳ７０１において、ＣＰＵ４０１
は、初期状態データを取得し、取得した初期状態データ
を通信ＩＦ４０４を介してサーバ１３０に送信する。こ
こで、状態とは、例えば対象機器がプロジェクタ１５０
であれば、電源のＯｎ／Ｏｆｆ／待機状態、明度、ピン
ト、絞り、プレゼンテーションファイルのファイル名、
ページ番号、プレゼンテーションを指し示すポインタの
座標などである。対象機器が動画撮影カメラ１６０であ
れば、電源のＯｎ／Ｏｆｆ／待機状態、カメラの水平／
垂直方向の角度、ホワイトバランス値、ズーム倍率など
である。送信された初期データは、サーバにより受信さ
れ、状態管理リスト３１０に登録される。

【００４７】図８、プロジェクタ１５０の初期状態デー
タの一例を示す図である。図９は、動画撮影カメラ１６
０の初期状態データの一例を示す図である。この例で
は、ＸＭＬ形式にてデータが記述されている。

【００４８】図８において、＜ＰｏｒｊｅｃｔｏｒＳｔ
ａｔｕｓ＞タグで囲まれた範囲は、プロジェクタ１５０
の状態を示すデータである。＜Ｌｏｃａｔｉｏｎ＞内の
値は場所を示すＵＲＬである。＜Ｂｒｉｇｈｔｎｅｓｓ
＞内の値は明度を示す値である。＜Ｆｏｃｕｓ＞内の値
はピントを示す値である。＜Ｐｏｉｎｔｏｒ＞内の＜ｘ
＞、＜ｙ＞で囲まれた値はそれぞれポインタのｘ、ｙ座
標を示す値である。＜ＰｒｅｓｅｎＦｉｌｅｎａｍｅ＞
内の値はプレゼンテーションファイルの名前である。＜
Ｐａｇｅ＞内の値はプレゼンテーションファイル内で表
示しているページ番号である。

【００４９】同様に、図９において＜ＭｏｖｉｅＣａｍ
ｅｒａＳｔａｔｕｓ＞タグで囲まれた範囲は動画撮影カ
メラ１６０の状態を示すデータである。＜Ｌｏｃａｔｉ
ｏｎ＞内の値は場所を示すＵＲＬである。＜Ｐａｎ＞内
の値は水平方向の角度である。＜Ｔｉｌｔ＞内の値は垂
直方向の角度である。＜ＷｈｉｔｅＢａｌａｎｃｅ＞内
の値はホワイトバランスを示す値である。＜Ｚｏｏｍ＞
内の値はズーム倍率を示す値である。

【００５０】ステップＳ７０２において、ＣＰＵ４０１
は、動作状態の変化を監視する。変化が検出されるとス
テップＳ７０３に移行する。例えば、プロジェクタ１５
０のページ番号が１から２に変化したなどである。

【００５１】ステップＳ７０３において、ＣＰＵ４０１
は、変化した状態を特定し、変化後の状態をサーバに通
知するための状態データを作成し、通信インタフェース
４０４に当該状態データを送信させる。サーバ１３０
は、この状態データを受信すると状態管理リスト３１０
を更新する。

【００５２】図１０は、状態データの一例を示す図であ
る。図１０からわかるように、Ｌｏｃａｔｉｏｎタグ
と、変化した状態に関連するタグ（例：＜Ｐａｇｅ＞）
が状態データに含まれている。

【００５３】図１１、サーバ１３０の動作例を示すフロ
ーチャートである。このフローチャートは、サーバ１３
０の電源が投入されると起動されるアプリケーションプ
ログラムに関するものである。

【００５４】ステップＳ１１０１において、ＣＰＵ３０
１は、通信インタフェース３０４を介して、対象機器又
はコントロール機器１００からアクセス要求を受信す
る。

【００５５】ステップＳ１１０２において、ＣＰＵ３０
１は、アクセス要求に含まれるソースアドレスなどに基
づいて、アクセスを希望している機器が対象機器である
か否かを判定する。対象機器であればステップＳ１１０
３に移行し、そうでなければステップＳ１１２１に移行
する。なお、アクセス要求に係る機器を判定するには、
例えば、機器の種別とソースアドレス（例：機器のＩＰ
アドレス）とを対応付けたテーブルを用意しておけばよ
いであろう。また、ネゴシエーションにより、直接、ア
クセス要求機器から機器の種別情報を取得してもよい。

【００５６】ステップＳ１１０３において、ＣＰＵ３０
１は、通信インタフェース３０４を介して、状態データ
を受信する。

【００５７】ステップＳ１１０４において、ＣＰＵ３０
１は、状態データを状態管理リストに追加し、ＨＤＤ３
０７に記憶する。

【００５８】図１２は、状態管理リストの一例を示す図
である。デバイス名（ｎａｍｅ）、デバイスのタイプ
（ｔｙｐｅ）、場所（ｌｏｃａｔｉｏｎ）及び状態デー
タファイル名（ｓｔａｔｕｓＦｉｌｅ）を含んでいる。
状態データファイルは、図８や図９に示したように、対
象機器から受信したデータファイルそのものであっても
よいし、図１３又は図１４に示すように、受信した状態
データを所定のテーブルに変換して保存してもよい。テ
ーブルへの変換処理もＣＰＵ３０１が行えばよい。

【００５９】図１５は、コントロール機器１００の動作
例を示すフローチャートである。コントロール機器１０
０が起動されると、本フローチャートに沿って処理が進
行する。

【００６０】ステップＳ１５０１において、ＣＰＵ２０
１は、サーバ１３０にＵＩ定義データのリクエストを作
成し、作成されたリクエストを無線部２０４により送信
させる。送信されたリクエストはアクセスポイント１１
０及びグローバルネットワーク１２０を経由してサーバ
１３０に転送される。なお、このリクエストには、コン
トロール機器１００のタイプを示すデータが含まれる。

【００６１】サーバ１３０は、図１１のステップＳ１１
２１乃至ステップＳ１１２３を実行する。

【００６２】ステップＳ１１２１において、通信インタ
フェース３０４によりＵＩ定義データのリクエストを受
信する。

【００６３】ステップＳ１１２２において、サーバ１３
０のＣＰＵ３０１は、受信したリクエストに基づいてコ
ントロール機器１００をクライアント管理テーブル３３
０に登録する。さらに、状態管理リスト３１０を検索
し、ＵＩ定義データを決定する。

【００６４】ここで、ＵＩ定義データの例示的な決定方
法を説明する。この例では、図１のシステム環境下にお
いて、サーバ１３０のＨＤＤ３０７に図１２に示された
状態管理リストが保存されているものとする。

【００６５】図１６は、ＵＩ定義データを決定するため
の決定テーブル３２０の一例を示す図である。ｔｙｐｅ
ｓ１６０１は、サーバ１３０に登録されている対象機器
を示している。ｃｌｉｅｎｔ−ｔｙｐｅ１６０２は、コ
ントロール機器１００のタイプを示す。ｃｌｉｅｎｔ−
ｎｕｍｂｅｒ１６０３は、同一種類のコントロール機器
１００が複数存在する場合に、各コントロール機器を識
別するための識別番号である。この識別番号は、例え
ば、サーバ１３０への登録順に従って付与すればよい。
このように、コントロール機器ごとに識別番号を付せ
ば、各機器ごとに異なるＵＩ定義データを設定すること
が可能となる。例えば、この番号が１であれば最初に登
録されたコントロール機器を表し、２であればなら２番
目に登録されたコントロール機器であることを表してい
る。なお、この番号が０であれば、登録順によらず、同
じＵＩ定義データを使用することを意味する。ＵＩＦｉ
ｌｅｎａｍｅ１６０４は、ＵＩ定義データファイルの名
前を示している。

【００６６】なお、コントロール機器１００からＵＩ定
義データのリクエストを受信すると、ＣＰＵ３０１は、
図１７に示すように、コントロール機器のタイプ毎に登
録数をカウントし、クライアント管理テーブル３３０を
作成してもよい。図１７の例では、携帯電話が１台登録
されていることを意味する。仮に２台目の携帯電話から
リクエストを受信すると、ｃｏｕｎｔの値がインクリメ
ントされ２となる。

【００６７】さて、ＵＩ定義データを決定する処理の説
明に戻ると、サーバ１３０のＣＰＵ３０１は、図１２の
ｔｙｐｅデータに基づいて、現在登録されている対象機
器としてＰｒｏｊｅｃｔｏｒとＭｏｖｉｅＣａｍｅｒａ
を抽出する。抽出されたＰｒｏｊｅｃｔｏｒとＭｏｖｉ
ｅＣａｍｅｒａを検索キーとして、図１６の決定テーブ
ル３２０を検索する。さらに、図１７のクライアント管
理テーブルのｃｏｕｎｔ値からｃｌｉｅｎｔ−ｎｕｍｂ
ｅｒをもとめ、これを検索キーとしてもよい。

【００６８】図１６を参照すると、ｔｙｐｅｓ１６０１
の列から、Ｐｒｏｊｅｃｔｏｒ＆ＭｏｖｉｅＣａｍｅｒ
ａとなっている行を抽出する。さらに、ｃｌｉｅｎｔ−
ｔｙｐｅデータに基づいてｃｌｉｅｎｔ−ｔｙｐｅがｋ
ｅｉｔａｉとなっている行を絞り込み検索する。検索の
結果、ＵＩ定義データがｐｒｏｊ＆ｍｃ−ｋｅｉｔａｉ
−ＵＩ．ｘｍｌと決定することができる。

【００６９】この判定規則は一例であり、他の規則であ
ってもよいが、一意にユーザインタフェース定義データ
を決定できる必要がある。もし、図１において対象機器
１６０がなければ、図１２においてＭｏｖｉｅＣａｍｅ
ｒａのデータもなく、ユーザインタフェース定義データ
はｐｒｏｊ−ｋｅｉｔａｉ−１ｓｔＵＩ．ｘｍｌとな
る。

【００７０】ステップＳ１１２３にいて、ＣＰＵ３０１
は、決定されたＵＩ定義データ（ｐｒｏｊ−ｋｅｉｔａ
ｉ−１ｓｔＵＩ．ｘｍｌ）を、リクエストしてきたコン
トロール機器１００に送信する。

【００７１】再び、図１５に戻って、コントロール機器
１００の説明をする。

【００７２】ステップＳ１５０２において、無線部２０
４は、サーバ１３０により送信されたＵＩ定義データを
受信する。

【００７３】ステップＳ１５０３において、ＣＰＵ２０
１は、ｘｍｌに対応したブラウザプログラムを起動し、
受信ＵＩ定義データを解析し、ＬＣＤ部２０６にユーザ
インタフェースの画面を表示させる。これにより、ユー
ザはインタフェースを操作できる状態となる。

【００７４】ステップＳ１５０４において、ユーザは表
示されたユーザインタフェースを操作し、対象機器をコ
ントロールする。より具体的には、ユーザにより操作部
３０５が操作され、操作内容がＣＰＵ２０１に渡され
る。ＣＰＵ２０１は、操作内容に基づいて、ＸＭＬ形式
のコントロールデータを作成し、無線部２０４から対象
機器に向けて送信する。

【００７５】ステップＳ１５０５において、ＣＰＵ２０
１は、コントロールの結果、対象機器の状態が変化し、
サーバ１３０に登録されている状態データの変化を監視
する。この変化は、例えば、サーバ１３０から変化通知
を受信することにより検出することができよう。変化が
検出されるとステップＳ１５０６に移行する。

【００７６】ステップＳ１５０６において、ＣＰＵ２０
１は、ＵＩ定義データを変更する必要があるか否かを判
定する。変更の必要があれば、ステップＳ１５０１に戻
り、再びリクエストをサーバ１３０に送信する。

【００７７】図１８は、コントロール機器１００に表示
される画像の例を示す図である。例えば、対象機器１５
０の電源がＯｎで、対象機器１６０の電源がＯｆｆであ
る場合に、図１８の画面がＬＣＤ部２０６に表示され
る。図１８の画面は、プレゼンテーションファイルのコ
ントロール画面である。画像１８０１は、プレゼンテー
ションファイルの表示結果である。ボタン１８０３は、
プレゼンテーションを逆にページ送りするボタンであ
る。ボタン１８０４は、順にページ送りするボタンであ
る。ポインタ１８０２は、操作部１２０５に配置される
カーソルキー１０１乃至１０４に連動して移動される。
例えば、ボタン１８０４の上にポインタ１８０２が重ね
られ、決定ボタン１０５が押されたことをＣＰＵ２０１
が検出すると、ＣＰＵ２０１は、順方向にページを送る
ためのコマンドを発行し、対処機器１５０に送信する。

【００７８】図１９は、順方向にページ送りするための
コマンドの一例を示す図である。

【００７９】一方、ボタン１８０３の上にポインタ１５
が重ねられ、決定ボタン１８０２が押されると、ＣＰＵ
２０１は、図１９の＜Ｐａｇｅ＞タグ内の値を「−１」
としてコマンドを発行する。これにより、逆方向にペー
ジ送りされる。

【００８０】ボタン１８０３及び１８０４以外の場所で
ボタン１８０２が押されると、ＣＰＵ２０１は、上述の
画面縮小の場合と逆の演算を実行することで対象機器１
５０の画面サイズに適した座標に変換し、図２０に示す
コマンドを対象機器１５０に送信する。演算結果が＜Ｓ
ｅｔＰｏｉｎｔ＞タグ内に格納されていることを理解で
きよう。コマンドを受信した対象機器１５０は、ポイン
タを移動させる。

【００８１】図２１は、対象機器１５０及び対象機器１
６０がともに電源Ｏｎである場合に、コントロール機器
１００のＬＣＤ部２０６に表示される画面例を示した図
である。

【００８２】図２１に示される画像は画、面全体に対象
機器１６０の画像が表示され、左下に対象機器１５０の
画像が表示される例である。レバー２１０１は、動画撮
影カメラ１６０のズーム機構を操作するためのレバーで
ある。また、ボタン２１０２及びボタン２１０３は、動
画撮影カメラ１６０をチルトさせるためのボタンであ
る。ボタン２１０４及びボタン２１０５は、動画撮影カ
メラ１６０を水平に首振りさせるためのボタンである。

【００８３】例えば、ポインタ１８０２を、レバー２１
０１上に重ねて、ボタン１０５が押し下げたままレバー
２１０１を移動させ、ボタン１８０２を放すと、その位
置に応じた値をＣＰＵ２０１が求め、その値を含むコマ
ンドを対象機器１６０に対して送信する。

【００８４】図２２は、対象機器１６０に対して発行さ
れるコマンドの一例を示す図である。図２２のコマンド
を動画撮影カメラ１６０が受信すると、ＣＰＵ４０１は
コマンドを解析し、解析結果に基づいて、固有機構４０
７を制御する。これにより、例えば、ズームイン、ズー
ムアウトが実行される。ボタン２１０２又は２１０３上
にポインタ１８０２を重ねて、決定ボタン１０５が押さ
れると、ＣＰＵ２０１は、図２３に示されるようなコマ
ンドを対象機器に発行する。これにより動画撮影カメラ
１６０の固有機構４０７が制御され、本体をチルト（垂
直に首振り）させる。一方、ボタン２１０４又は２１０
５上にポインタ１８０２が重ねられ決定ボタン１０５が
押されると、ＣＰＵ２０１は、図２４に示されるような
コマンドを発行する。これにより固有機構４０７が制御
され、カメラがパン（水平に首振り）を実行する。

【００８５】以上のようにして、対象機器１５０のみが
存在する場合には対象機器１５０をコントロールするた
めのユーザインタフェースがコントロール機器１００に
提供される。一方で、対象機器１５０と対象機器１６０
が存在する場合には、２つの対象機器をコントロールす
るためのユーザインタフェースがコントロール機器１０
０に提供される。

【００８６】第１の実施形態では、対象機器が２台ある
場合について説明したが、対象機器が３台以上であって
も同様に適用可能である。また、対象機器の種類がさら
に増え、それにつれて種類毎の組み合わせも増えたとし
ても、それに応じたＵＩ定義データを用意することで、
ユーザインタフェースを提供できる。

【００８７】［実施形態２］本実施形態は、コントロー
ル機器１００が２台以上ある場合に、それぞれのコント
ロール機器１００に異なるユーザインタフェースを提供
する例である。

【００８８】図２５は、本実施形態のシステム構成例を
示す図である。対象機器１５０はプロジェクタである。
コントロール機器１００ａ、１００ｂ、１００ｃはサー
バ１３０からＵＩ定義データを取得することで対象機器
１５０にアクセスする。なお、基本的な動作について
は、すでに実施形態１において説明したため、ここでは
異なる点、例えば、ＵＩ定義データを選択するステップ
Ｓ１１２２に関し、補足説明をする。

【００８９】コントロール機器１００ａがサーバ１３０
にアクセスし、ユーザインタフェース定義データのリク
エストを送信すると、サーバ１３０は、コントロール機
器のタイプ毎に設けられたカウンタをインクリメントす
る。その結果、図１７に示すクライアント管理テーブル
の該当するＣｏｕｎｔの値が増加する。この例では、コ
ントロール機器１００ａ、コントロール機器１００ｂ及
びコントロール機器１００ｃの計３台が、この順序でア
クセスするためＣｏｕｎｔ値は３となる。

【００９０】サーバ１３０は、図２５の状態を登録した
状態管理リスト３１０のｔｙｐｅデータを参照し、現在
登録されている対象機器がプロジェクタ１５０だけであ
ることを把握する。すなわち、ｔｙｐｅデータとしてＰ
ｒｏｊｅｃｔｏｒが抽出される。

【００９１】続いて、決定テーブル３２０を検索し、ｔ
ｙｐｅｓ１６０１が「Ｐｒｏｊｅｃｔｏｒ」であり、か
つ、ｃｌｉｅｎｔ−ｔｙｐｅ１６０２がｋｅｉｔａｉと
なっている行を抽出する。図１６に示された決定テーブ
ル３２０の例では、３行が合致している。ここでは、コ
ントロール機器１００ａに着目すると、この機器１００
ａは最初に登録されて機器であるからｃｌｉｅｎｔ−ｎ
ｕｍｂｅｒ＝１が付与されている。従って、ｃｌｉｅｎ
ｔ−ｎｕｍｂｅｒが１である行を検索により絞り込み抽
出する。このようにして、コントロール機器１００ａの
ＵＩ定義データはｐｒｏｊ−ｋｅｉｔａｉ−１ｓｔＵ
Ｉ．ｘｍｌに決定される。

【００９２】次にコントロール機器１００ｂが、ＵＩ定
義データのリクエストを送信すると、サーバ１３０は、
クライアント管理テーブル３１０のｋｅｉｔａｉに係る
ｃｏｕｎｔ値をインクリメントする。その結果、値は２
となる。サーバ１３０は、ＵＩ定義決定テーブル３２０
を参照し、ｔｙｐｅｓがＰｒｏｊｅｃｔｏｒであり、か
つ、ｃｌｉｅｎｔ−ｔｙｐｅがｋｅｉｔａｉであり、か
つ、ｃｌｉｅｎｔ−ｎｕｍｂｅｒが２である行を検索に
より抽出する。検索の結果、コントロール機器１００ｂ
のＵＩ定義データはｐｒｏｊ−ｋｅｉｔａｉ−２ｎｄＵ
Ｉ．ｘｍｌと決定される。

【００９３】同様に、コントロール機器１００ｃのＵＩ
定義データはｐｒｏｊ−ｋｅｉｔａｉ−３ｒｄＵＩ．ｘ
ｍｌと決定される。

【００９４】ステップＳ１１２３において、各コントロ
ール機器に決定されたＵＩ定義データが送信される。

【００９５】各コントロール機器は、ステップＳ１５０
２において、決定されたＵＩ定義データを受信し、ステ
ップＳ１５０３でユーザインタフェース画面をＬＣＤ部
２０６に表示させる。

【００９６】図１８は、ＵＩ定義データｐｒｏｊ−ｋｅ
ｉｔａｉ−１ｓｔＵＩ．ｘｍｌを受信したコントロール
機器１００ａに表示される画面例である。図２６は、ｐ
ｒｏｊ−ｋｅｉｔａｉ−２ｎｄＵＩ．ｘｍｌを受信した
コントロール機器１００ｂに表示される画面例である。
図２７は、ｐｒｏｊ−ｋｅｉｔａｉ−３ｒｄＵＩ．ｘｍ
ｌを受信したコントロール機器１００ｃに表示される画
面例である。図１８は、説明者（プレゼンター）のコン
トロール機器に表示される画面であり、実施形態１で説
明したようにコントロール機器１００ａを操作すること
でプレゼンテーションファイルを操作できる。図２６及
び図２７は質問者のコントロール機器に表示される画面
であり、それぞれ形が異なるポインタ２６０１、２７０
１が示される。

【００９７】図２８は、対象機器（プロジェクタ）１５
０に表示される画面例である。図２８からわかるように
３者のポインタ１８０２、２６０１及び２７０１が表示
される。これにより、コントロール機器１００ａ、１０
０ｂ、１００ｃを使用する説明者、質問者の各々が、意
図する場所をポイントすることができ、プレゼンテーシ
ョンをさらに使いやすいものとすることができる。

【００９８】以上、コントロール機器が複数である場合
に、それぞれのコントロール機器に異なるユーザインタ
フェースを提供する例を示した。本実施形態では、同一
種類のコントロール機器を使用して説明したが、他の種
類のコントロール機器と並存しても問題ない。例えば、
コントロール機器のタイプごとに、異なるＵＩ定義デー
タを用意すればよい。もちろん、タイプに依存せず、Ｕ
Ｉ定義データを用意してもよい。

【００９９】また、実施形態１と実施形態２を組み合わ
せれば、複数のコントロール機器１００に対し、複数の
対象機器に応じたユーザインタフェースを提供すること
も可能である。

【０１００】［実施形態３］本実施形態３では、対象機
器の状態が変更された場合の例を示す。

【０１０１】図２９は、対象機器１６０のＵＩ定義デー
タの一例を示す図である。対象機器の状態（例：図１５
の状態データ）に対応したユーザインタフェースを提供
するために必要となる各種のデータが、図２９のＵＩ定
義データに格納されている。ここで、対象機器１６０に
ライト（照明器具）が追加されたとする。

【０１０２】図３０は、対象機器１６０からサーバ１３
０に送信される更新命令の一例である。図３０の更新命
令には、状態を追加することを示す＜Ａｄｄ＞タグと、
状態名＜Ｌｉｇｈｔ＞および状態値０がある。

【０１０３】サーバ１３０は、図３０の更新命令を受信
すると、図３１に示すように状態データを変更する。具
体的には、Ｌｉｇｈｔ３１０１の欄が状態管理テーブル
３１０に追加される。さらに、更新命令に基づいてＵＩ
定義データも更新される。

【０１０４】図３２は、変更された状態データに基づい
て更新されたＵＩ定義データを示す図である。もし既に
変更前のＵＩ定義データを使用しているコントロール機
器１００があれば、当該コントロール機器１００に新し
いＵＩ定義データを送信する。この際、追加された状態
以外の状態に関しては、初期状態ではなくそのときの対
象機器１６０の状態であることはいうまでもない。

【０１０５】図３３は、対象機器１６０からライトが取
り外された場合に発行される更新命令の一例を示す図で
ある。この更新命令もまた、対象機器１６０からサーバ
１３０に送信される。サーバ１３０は上記追加の際の処
理と同様に、状態管理リスト３１０やＵＩ定義データの
更新処理を実行すると、コントロール機器に対し、図２
９に示すようなＵＩ定義データを送信する。

【０１０６】単に状態値が変更になった場合について
は、実施形態１に示したので本実施形態３では特に記さ
ない。

【０１０７】［実施形態４］本実施形態では、サーバ１
３０の存在の有無に依存してユーザインタフェースを提
供しようとするものである。

【０１０８】図３４は、本実施形態の適用されるシステ
ムの概要図である。既に説明した部分に関しては説明を
省略する。図には、コントロール機器１００、サーバ１
３０、対象機器としてのネットワークカメラ３４０２及
び対象機器としてのＰＣ３４０１が記載されている。

【０１０９】図３５は、コントロール機器１００のＬＣ
Ｄ部２０６に表示される画面の例を示す図である。３５
０１は、ＰＣ３４０１とチャットを実行している際に表
示される画面の例である。チャットとは、文字データを
送受信して表示するアプリケーションである。一方、３
５０２には、ネットワークカメラ３４０２により撮影さ
れた画像である。この画像は、例えば、Ｊｐｅｇなどの
静止画データであってもよいし、Ｍｐｅｇ４などの動画
データであってもよい。静止画データのときは、例え
ば、MotionJpegのように、連続してデータを送信するこ
とで、動画のように見せることもできよう。なお、本実
施形態において、サーバ１３０が存在しない場合には、
画面３５０１と画面３５０２を、コントロール機器１０
０が択一的に選択してＬＣＤ部２０６に表示する。

【０１１０】図３６は、本実施形態においてサーバ１３
０が存在する場合にＬＣＤ部２０６に表示される画面例
を示す図である。チャットアプリケーションによる画面
３５０１と動画３５０２とが一度に表示される。

【０１１１】すなわち、サーバ１３０が存在する場合に
は、図３６のようなユーザインタフェースがサーバ１３
０によりコントロール機器１００に提供される。一方、
サーバ１３０が存在しない場合には、直接、ＰＣ３４０
１やネットワークカメラ３４０２からユーザインタフェ
ースが提供される。

【０１１２】図３７は、本実施形態に係るコントロール
機器の処理フローチャートである。

【０１１３】ステップＳ３７０１において、ＣＰＵ２０
１は、無線部２０４を介してサーバ１３０を探索する。
例えば、リクエストをサーバ１３０に送信し、一定時間
以内にレスポンスがあればサーバ１３０が存在すると判
定し、一方、レスポンスがなければサーバ１３０が存在
しないと判定すればよい。サーバ１３０が存在すれば、
既説の通り、ステップＳ１５０１乃至ステップＳ１５０
６を実行する。そうでなければ、ステップＳ３７０２を
実行する。

【０１１４】ステップＳ３７０２は、直接、所望の対象
機器と接続して、上記のインタフェースの提供を受け
る。

【０１１５】図３８は、対象機器におけるフローチャー
トである。

【０１１６】ステップＳ３８０１において、対象機器の
ＣＰＵ４０１は、サーバ１３０が存在するか否かを判定
する。判定方法は、例えば、ステップＳ３７０１と同様
の方法を採用すればよい。もし、サーバが存在しない場
合は、ステップＳ３８２１に進み、通信インタフェース
４０４を介してコントロール機器１００から操作命令を
受信し、ステップＳ３８２２においてＣＰＵ４０１は操
作命令を実行し、ステップＳ３８２３において通信イン
タフェース４０４からコントロール機器１００に実行結
果を送信する。

【０１１７】ステップＳ３８０２において、ＣＰＵ４０
１は、ＲＡＭ４０３又はＲＯＭ４０２から初期状態デー
タを読み出し、通信インタフェース４０３を介してサー
バ１３０に初期状態データを送信する。ここで、状態と
は、対象機器３４０１のＰＣであれば、例えば、機種情
報、チヤット能力の有無などである。一方、対象機器３
４０２のネットワークカメラであれば、例えば、電源の
Ｏｎ／０ＦＦ／待機状態、カメラの水平／垂直方向の角
度、ホワイトバランス値又はズーム倍率などである。

【０１１８】図３９は、ＰＣについての初期状態データ
の一例を示す図である。製品タイプ、製品名、シリアル
番号及びチャット対応の有無が含まれている。

【０１１９】図４０は、ネットワークカメラについての
初期状態データの一例を示す図である。製品タイプ、製
品名、シリアル番号、電源状態、パン、チルト、ホワイ
トバランス、ズーム倍率及び画面サイズなどが含まれて
いる。

【０１２０】本実施形態では、初期状態データはテキス
トにより記述されているものとするが、もちろん、ＨＴ
ＭＬ、ＸＭＬなどのフォーマットに従った形式や、バイ
ナリ形式であってもよい。

【０１２１】図４１は、サーバの処理例を示したフロー
チャートである。図１１のフローチャートと同様の処理
については説明を省略する。

【０１２２】ステップＳ４１０１において、サーバ１３
０のＣＰＵ３０１は、対象機器からのリクエストが状態
データの登録要求であるかを判定する。判定の結果、状
態データの登録要求であれば、ステップＳ１１０３に進
み、状態データを受信し、ステップＳ１１０４において
状態管理リスト３１０に状態データを保存する。一方、
状態データの登録要求でなければ、ステップＳ４１０２
に進む。例えば、データが撮影画像であれば、コントロ
ール機器に応じて画像処理を実行し、処理後の画像デー
タをコントロール機器に送信する。

【０１２３】このようにして、初期状態データの登録が
完了すると、対象機器の処理はステップＳ３８０３へと
進む。

【０１２４】ステップＳ３８０３において、対象機器３
４０１および対象機器３４０５は、サーバ１３０を介し
てコントロール機器１００からの操作命令を受信する。

【０１２５】ステップＳ３８０４において、ＣＰＵ４０
１は、操作命令を実行する。

【０１２６】ステップＳ３８０５において、ＣＰＵ４０
１は、通信インタフェース４０４からコントロール機器
１００に実行結果を送信する。

【０１２７】例えば、対象機器（ＰＣ）３４０１なら、
チャットの文字列を受信し、それを表示したり、対象機
器３４０１のユーザにより入力された文字列をサーバ１
３０に送信したりする。一方、対象機器（ネットワーク
カメラ）３４０２なら、パン、チルトなどカメラの向き
を変える命令や、ズームなどの命令を受け付けて、カメ
ラを駆動し、撮影した画像をサーバ１３０に送信する。

【０１２８】中継サーバ１３０は、ステップＳ４１０２
において、対象機器３４０１及び３４０２から受信した
データをマージし、図３６に示すような画像を作成して
コントロール機器１００に送信する。

【０１２９】次に、ＵＩ定義データの決定処理について
説明する。サーバ１３０は、コントロール機器１００か
らのアクセスを受け付けると、ステップＳ４１１１に進
む。

【０１３０】ステップＳ４１１１において、ＣＰＵ３０
１は、コントロール機器１００から受信したデータの内
容が、ＵＩ定義データのリクエストであるか否かを判定
する。例えば、対象機器に対する操作命令であれば、ス
テップＳ４１１４に進み、当該操作命令を対象機器に送
信する。

【０１３１】ステップＳ４１１２において、ＣＰＵ３０
１は、ＵＩ定義データのリクエストを処理すべく、状態
管理リスト３１０を検索し、コントロール機器１００を
登録する。状態管理リストは、対象機器用とコントロー
ル機器用について個別に設けられてもよいし、双方を１
つのリストで扱うようにしてもよい。以下では、前者の
場合を説明する。

【０１３２】図４２は、対象機器用の状態管理リストの
一例を示す図である。図４３は、コントロール機器用の
状態管理リストの一例を示す図である。それぞれ、状態
データやリクエストにに基づいて、製品タイプ、製品名
及びシリアル番号などが登録される。

【０１３３】ステップＳ４１１３において、ＵＩ定義デ
ータを決定するルーチンを呼び出す。ＵＩ定義データが
決定されば、前述のようにステップＳ１１２３において
当該ＵＩ定義データをコントロール機器１００に送信す
る。

【０１３４】図４４は、ＵＩ定義データの決定ルーチン
に関する例示的なフローチャートである。

【０１３５】ステップＳ４４０１において、サーバ１３
０のＣＰＵ３０１は、状態管理リスト３１０を検索し、
登録されている対象機器を抽出する。具体的には、製品
タイプＰＣと製品タイプｃａｍｅｒａが同時に存在する
かをチェックする。例えば、図３１に例示された対象機
器用の状態管理リスト３１０において、製品タイブの欄
をチェックする。当該状態管理リストをチェックする
と、ＰＣ及びｃａｍｅｒａとも登録されているので、Ｃ
ＰＵ３０１は、両方とも存在すると判定し、ステップＳ
４４０２に移行する。

【０１３６】ステップＳ４４０２において、ＣＰＵ３０
１は、ＰＣ＆Ｃａｍｅｒａを検索キーとして、ＵＩ定義
データの決定テーブル３２０を検索し、この検索キーと
一致するタグを見つけると、対応するＵＩ定義データを
抽出する。

【０１３７】図４５は、ＵＩ定義データの決定テーブル
を例示的に示した図である。この図によれば、Ｂｕｎｋ
ａｔｓｕ．ｘｍｌが抽出される。

【０１３８】ステップＳ４４０３において、ＰＣのみが
状態管理リスト３１０に登録されているかを判定する。
ＰＣのみが登録されている場合は、ステップＳ４４０４
において、決定テーブル３２０を検索し、Ｃｈａｔ．ｘ
ｍｌといったＵＩ定義データを抽出する。

【０１３９】ステップＳ４４０５において、Ｃａｍｅｒ
ａのみが状態管理リスト３１０に登録されているかを判
定する。ＰＣのみが登録されている場合は、ステップＳ
４４０６において、決定テーブル３２０を検索し、Ｚｅ
ｎｇａｍｅｎ．ｘｍｌといったＵＩ定義データを抽出す
る。

【０１４０】ステップＳ４４０７は、機器間の関係を検
索するための検索キーが存在しない場合及び対応するＵ
Ｉ定義データがない場合のエラー処理である。具体的に
は、ＣＰＵ３０１は、デフォルトのＵＩ定義データを抽
出する。あるいは、ＵＩ定義データが存在しない旨を返
す。

【０１４１】以上のように、対象機器３４０１と対象機
器３４０２とが存在する場合は、コントロール機器１０
０のＬＣＤ部２０６に図３６に例示したような画面が表
示される。これにより、ユーザには対象機器を操作する
ためのユーザインタフェースが提供される。

【０１４２】本実施形態では、図４４に示す決定ルーチ
ンと、図４５に示す決定テーブルとを用いたが、登録さ
れている機器に対応するＵＩ定義データを決定できるの
であれば、他の決定ルーチン及び他の決定テーブルを用
いても良い。

【０１４３】［実施形態５］本実施形態は、コントロー
ル機器１００が複数の対象機器からサービスの提供を享
受するものである。

【０１４４】図４６は、本実施形態に係るシステム構成
の一例を示す図である。コントロール機器１００及び対
象機器３４０２ａ乃至３４０２ｃの動作は、前記の実施
形態とほぼ同様なので省略する。サーバ１３０の処理フ
ローも前記の実施形態とほぼ同様であるの、以下では、
本実施形態において特長的な部分を詳細に説明すること
にする。

【０１４５】図４７は、図４６に示された環境下におい
てサーバ１３０により作成される状態管理リスト３１０
の一例を示す図である。ここでは、対象機器３４０２ａ
乃至３４０２ｃはすべてネットワークカメラであるか
ら、製品タイプにはＣａｍｅｒａが登録され、製品名に
は任意のカメラ名が登録され、シリアル番号には、各ネ
ットワークカメラのシリアル番号が登録される。なお、
コントロール機器１００用の状態管理リストは、図４３
に示されたものが使用される。

【０１４６】図４８は、本実施形態に係るＵＩ定義デー
タの決定ルーチンを例示したフローチャートである。実
施形態では、製品タイプＣａｍｅｒａが３つ登録されて
いるとする。

【０１４７】ステップＳ４８０１において、ＣＰＵ３０
１は、図４７に示された対象機器用の状態管理リストを
検索し、ネットワークカメラが何台登録されているかを
判定する。とりわけ、本ステップでは、ネットワークカ
メラの登録台数が４台であるかを判定する。４台であれ
ば、ステップＳ４８０２に移行し、４台のカメラによる
パノラマ画像の作成が可能かを判定する。例えば、２つ
の画像の端部を比較し、重ねることが可能かを判定す
る。また、２つの画像を多少ずらして重ねることができ
れば、パノラマ画像を形成できると判定とする。もちろ
ん、パノラマ画像を形成可能であると判定できるのであ
れば方法は問わない。判定の結果、パノラマ可能であれ
ばステップＳ４８０３に移行する。ステップＳ４８０３
において、「Ｃａｍｅｒａ４台＆パノラマ可」を検索キ
ーとし、ＵＩ定義データの決定テーブル３２０を検索す
る。

【０１４８】図４９は、決定テーブルの一例を示す図で
ある。「Ｃａｍｅｒａ４台＆パノラマ可」の場合は、Ｐ
ａｎｏｒａｍａ４．ｘｍｌが抽出される。

【０１４９】なお、ステップＳ４８０２において、パノ
ラマ不可と判定されたり、カメラの台数が不一致と判定
されたりすれば、ステップ４８１０に進み、デフォルト
のＵＩ定義データ（４Ｂｕｎｋａｔｕ．ｘｍｌ）を抽出
する。

【０１５０】ステップＳ４８０４乃至ステップＳ４８０
６は、カメラ台数が３台の場合の処理である。ステップ
Ｓ４８０７乃至ステップＳ４８０９は、カメラ台数が３
台の場合の処理である。

【０１５１】このようにして決定されたＵＩ定義データ
は、コントロール機器１００に送信される。さらに、サ
ーバ１３０のＣＰＵ３０１は、対象機器３４０２ａ乃至
３４０２ｃに対して撮影画像を送信するよう要求する。
各対象機器は、画像要求を受信すると（Ｓ３８０３）、
画像を撮影し（Ｓ３８０４）、撮影画像をサーバ１３０
に送信する（Ｓ３８０５）。

【０１５２】サーバ１３０は、撮影画像データを受信す
ると、パノラマ画像の作成プログラムを実行し、パノラ
マ画像を作成し、作成されたパノラマ画像をコントロー
ル機器１００に送信する（Ｓ４１０２）。コントロール
機器１００は、サーバ１３０からパノラマ画像を受信し
てＬＣＤ２０６に表示する（Ｓ１５０３）。

【０１５３】図５０は、各対象機器により撮影された画
像を例示した図である。例えば、５００１は、対象機器
３４０２ａにより撮影された画像であり、５００２は、
対象機器３４０２ｂにより撮影された画像であり、５０
０３は、対象機器３４０２ｃにより撮影された画像であ
る。サーバ１３０が存在しない場合は、コントロール機
器１００は、３つの画像を切り替えて表示する。表示画
像の切り替えは、接続する対象機器の選択により行えば
よいであろう。

【０１５４】図５１は、上記３つの画像から作成したパ
ノラマ画像の一例を示す図である。

【０１５５】図５２は、デフォルトのＵＩ定義データが
選択された場合に表示される画面の一例を示す図であ
る。いずれも、ＵＩ定義データに基づいてコントロール
機器１００により表示される。ちなみに、図５２の四分
割画面が表示されている場合に、何れかの対象機器が動
作不能になると、その対象機器からの画像部分を表示し
ないように制御される。

【０１５６】図４８に示された決定ルーチンはほんの一
例に過ぎない。例えば、４台のカメラが状態管理データ
ベースに登録されているときに、そのうち２台づつペア
でパノラマ画像の作成が可能かを判定し、可能であれば
２つのパノラマ画像を作成し、コントロール機器１００
に提供しても良い。また、３台のカメラが存在し、その
うちの２台の画像についてパノラマ画像が作成可能であ
るかを判定し、可能であれば１つのパノラマ画像を作成
して提供しても良い。また、パノラマ画像の表示中に対
象機器が動画を送信できなくなったら、そのままパノラ
マ画面でフリーズしてもいいし、図５２に示すように分
割画面にし、動作中の対象機器により取得された画像を
表示しつづけてもよい。あるいは、図５０に示すように
全画像の表示を切り替えてもよい。

【０１５７】［他の実施形態］なお、前述した各実施形
態の機能を実現するソフトウェアのプログラムコードを
記憶した記憶媒体を、システムあるいは装置に供給し、
そのシステムあるいは装置のコンピュータ（またはＣＰ
ＵやＭＰＵ）が記憶媒体に格納されたプログラムコード
を読み出して実行することによっても、本願発明が達成
されることは言うまでもない。

【０１５８】この場合、記憶媒体から読み出されたプロ
グラムコード自体が、前述の各実施形態の機能を実現す
ることになり、そのプログラムコードを記憶した記憶媒
体が本願発明を構成することになる。

【０１５９】プログラムコードを供給するための記憶媒
体として、例えば、フロッピィディスク、ハードディス
ク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ
−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、
あるいは、通信可能なネットワークに接続されたサーバ
コンピュータなどを用いることができる。

【０１６０】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述した各実施形態の
機能が実現されるだけでなく、そのプログラムコードの
指示に基づき、コンピュータ上で稼働しているＯＳなど
が実際の処理の一部または全部を行い、その処理によっ
て前述した各実施形態の機能が実現される場合も、本願
発明に含まれることは言うまでもない。

【０１６１】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部または全部を行
い、その処理によって前述した各実施形態の機能が実現
される場合も、本願発明に含まれることは言うまでもな
い。

【０１６２】

【発明の効果】本願発明によれば、制御機器と対象機器
とを仲介し、ユーザインタフェースの定義データを制御
機器に送信するサーバが提供される。

【図面の簡単な説明】

【図１】図１は、本実施形態に係るシステムの構成例を
示す図である。

【図２】図２は、コントロール機器としての携帯電話１
００に係る例示的なブロック図である。

【図３】図３は、制御仲介サーバとしてのサーバ１３０
に係る例示的なブロック図である。

【図４】図４は、対象機器に係る例示的なブロック図で
ある。

【図５】図５は、対象機器の画面サイズを示した図であ
る。

【図６】図６は、コントロール機器の画面サイズを示し
た図である。

【図７】図７は、対象機器の動作例を示すフローチャー
トである。

【図８】図８、プロジェクタ１５０の初期状態データの
一例を示す図である。

【図９】図９は、動画撮影カメラ１６０の初期状態デー
タの一例を示す図である。

【図１０】図１０は、状態データの一例を示す図であ
る。

【図１１】図１１、サーバ１３０の動作例を示すフロー
チャートである。

【図１２】図１２は、状態管理リストの一例を示す図で
ある。

【図１３】図１３は、プロジェクタの状態データをテー
ブルで管理する場合の一例を示す図である。

【図１４】図１４は、動画撮影カメラの状態データをテ
ーブルで管理する場合の一例を示す図である。

【図１５】図１５は、コントロール機器１００の動作例
を示すフローチャートである。

【図１６】図１６は、ＵＩ定義データを決定するための
決定テーブル３２０の一例を示す図である。

【図１７】図１７は、クラインアント管理テーブルの一
例を示す図である。

【図１８】図１８は、コントロール機器１００に表示さ
れる画像の例を示す図である。

【図１９】図１９は、順方向にページ送りするためのコ
マンドの一例を示す図である。

【図２０】図２０は、対象機器に送信される命令情報
（コマンド）の一例を示す図である。

【図２１】図２１は、対象機器１５０及び対象機器１６
０がともに電源Ｏｎである場合に、コントロール機器１
００のＬＣＤ部２０６に表示される画面例を示した図で
ある。

【図２２】図２２は、対象機器１６０に対して発行され
るコマンドの一例を示す図である。

【図２３】図２３は、対象機器１６０に対して発行され
るコマンドの一例を示す図である。

【図２４】図２４は、対象機器１６０に対して発行され
るコマンドの一例を示す図である。

【図２５】図２５は、実施形態２のシステム構成例を示
す図である。

【図２６】図２６は、ｐｒｏｊ−ｋｅｉｔａｉ−２ｎｄ
ＵＩ．ｘｍｌを受信したコントロール機器１００ｂに表
示される画面例である。

【図２７】図２７は、ｐｒｏｊ−ｋｅｉｔａｉ−３ｒｄ
ＵＩ．ｘｍｌを受信したコントロール機器１００ｃに表
示される画面例である。

【図２８】図２８は、対象機器（プロジェクタ）１５０
に表示される画面例である。

【図２９】図２９は、対象機器１６０のＵＩ定義データ
の一例を示す図である。

【図３０】図３０は、対象機器１６０からサーバ１３０
に送信される更新命令の一例を示す図である。

【図３１】図３１は、状態変更により更新された状態管
理リストの一例を示す図である。

【図３２】図３２は、変更された状態データに基づいて
更新されたＵＩ定義データを示す図である。

【図３３】図３３は、対象機器１６０からライトが取り
外された場合に発行される更新命令の一例を示す図であ
る。

【図３４】図３４は、本実施形態の適用されるシステム
の概要図である。

【図３５】図３５は、コントロール機器１００のＬＣＤ
部２０６に表示される画面の例を示す図である。

【図３６】図３６は、本実施形態においてサーバ１３０
が存在する場合にＬＣＤ部２０６に表示される画面例を
示す図である。

【図３７】図３７は、本実施形態に係るコントロール機
器の処理フローチャートである。

【図３８】図３８は、対象機器におけるフローチャート
である。

【図３９】図３９は、ＰＣについての初期状態データの
一例を示す図である。

【図４０】図４０は、ネットワークカメラについての初
期状態データの一例を示す図である。

【図４１】図４１は、サーバの処理例を示したフローチ
ャートである。

【図４２】図４２は、対象機器用の状態管理リストの一
例を示す図である。

【図４３】図４３は、コントロール機器用の状態管理リ
ストの一例を示す図である。

【図４４】図４４は、ＵＩ定義データの決定ルーチンに
関する例示的なフローチャートである。

【図４５】図４５は、ＵＩ定義データの決定テーブルを
例示的に示した図である。

【図４６】図４６は、本実施形態に係るシステム構成の
一例を示す図である。

【図４７】図４７は、図４６に示された環境下において
サーバ１３０により作成される状態管理リスト３１０の
一例を示す図である。

【図４８】図４８は、本実施形態に係るＵＩ定義データ
の決定ルーチンを例示したフローチャートである。

【図４９】図４９は、決定テーブルの一例を示す図であ
る。

【図５０】図５０は、各対象機器により撮影された画像
を例示した図である。

【図５１】図５１は、上記３つの画像から作成したパノ
ラマ画像の一例を示す図である。

【図５２】図５２は、デフォルトのＵＩ定義データが選
択された場合に表示される画面の一例を示す図である。

【符号の説明】

１００…コントロール機器１０１…ポインタを上に動かすボタン１０２…ポインタを下に動かすボタン１０３…ポインタを右に動かすボタン１０４…ポインタを左に動かすボタン１０５…ポインタをクリックするボタン１１０…アクセスポイント１２０…グローバルネットワーク１３０…サーバ１４０…ローカルネットワーク１５０…対象機器（プロジェクタ）１６０…対象機器（動画撮影カメラ）２０５…操作部２０６…表示部（ＬＣＤ）

Claims

【特許請求の範囲】

【請求項１】制御の対象となる複数の制御対象機器を少
なくとも１つの制御機器から制御する際に該制御を仲介
する制御仲介サーバであって、前記制御対象機器の状態に関する状態関連情報を前記複
数の制御機器のそれぞれから受信する受信手段と、前記制御機器からの要求に応じて、前記受信された複数
の状態関連情報に対応するユーザインタフェースの定義
データを選択する選択手段と、前記選択された定義データを前記制御機器に送信する送
信手段と、を含み、前記制御機器は、前記送信された定義データに基づいて
提供されるユーザインタフェースに従って前記複数の制
御対象機器を制御することを特徴とする制御仲介サー
バ。
【請求項２】前記選択手段は、前記制御機器の種別及び
前記状態関連情報に基づいて、対応する定義データを選
択することを特徴とする請求項１に記載の制御仲介サー
バ。
【請求項３】前記受信手段は、さらに前記制御機器の状
態に関する状態関連情報を受信し、前記選択手段は、前
記制御機器の状態関連情報及び前記制御対象機器の状態
関連情報に基づいて、対応する定義データを選択するこ
とを特徴とする請求項１に記載の制御仲介サーバ。
【請求項４】前記制御対象機器の状態が変更されると、
該制御対象機器から送信される状態更新情報に基づい
て、前記定義データを更新する更新手段をさらに含み、前記更新手段により更新が実行されると、前記送信手段
は、更新された定義データを前記制御機器に送信するこ
とを特徴とする請求項１乃至請求項３の何れか１項に記
載の制御仲介サーバ。
【請求項５】前記選択手段は、複数の前記制御機器に対
してそれぞれ異なる定義データを選択することを特徴と
する請求項１乃至請求項４の何れか１項に記載の制御仲
介サーバ。
【請求項６】いずれかの前記制御対象機器により送信さ
れるコンテンツデータを所定規則に基づいて加工する加
工手段をさらに含み、前記加工されたコンテンツデータは前記送信手段により
前記制御機器に送信されることを特徴とする請求項１乃
至請求項５の何れか１項に記載の制御仲介サーバ。
【請求項７】少なくとも１つの前記制御対象機器の状態
が変更されると、前記加工手段は、前記所定規則を変更
し、変更後の所定規則でもって前記コンテンツデータを
加工することを特徴とする請求項６に記載の制御仲介サ
ーバ。
【請求項８】前記加工手段は、前記複数の制御対象機器
から受信した複数のコンテンツデータをより少ない数の
コンテンツデータへとマージ処理することを特徴とする
請求項６又は請求項７に記載の制御仲介サーバ。
【請求項９】前記複数の制御対象機器の相互関連性又は
前記複数のコンテンツデータの相互関連性を検出する検
出手段をさらに備え、前記加工手段は、前記検出された相互関連性に基づいて
所定規則を決定し、前記複数のコンテンツデータを加工
することを特徴とする請求項８に記載の制御仲介サー
バ。
【請求項１０】前記定義データは、ＸＭＬ形式、テキス
ト形式、ハイパーテキスト形式又はバイナリ形式にて記
述されていることを特徴とする請求項１乃至請求項９の
何れか１項に記載の制御仲介サーバ。
【請求項１１】請求項１乃至請求項１０の何れか１項に
記載の制御仲介サーバから定義データを受信する手段、
該定義データに基づいて提供されるユーザインタフェー
スを表示する手段と、前記ユーザインタフェースに応じ
て前記制御対象機器を制御するための命令情報を各制御
対象機器に送信する手段とを含むことを特徴とする制御
機器。
【請求項１２】制御仲介サーバがネットワーク上に存在
するかを検出する検出手段と、前記制御サーバが存在する場合には該制御サーバに定義
データを要求し、前記制御サーバが存在しない場合には
前記制御対象機器に定義データを要求する要求手段と、を備えることを特徴とする請求項１１に記載の制御機
器。
【請求項１３】前記制御機器は、携帯電話、ブラウザフ
ォン、ＰＤＡまたはＰＣであることを特徴とする請求項
１２に記載の制御機器。
【請求項１４】請求項１１乃至請求項１３の何れか１項
に記載の制御機器により制御される制御対象機器であっ
て、前記状態関連情報を取得する手段と、前記取得され
た状態関連情報を前記制御仲介サーバに送信する手段
と、前記制御機器からの命令情報を受信する手段と、前
記命令情報に基づいた所定処理を実行する手段と、前記
所定処理の実行結果を前記制御機器又は前記制御仲介サ
ーバに送信する手段とを含むことを特徴とする制御対象
機器。
【請求項１５】制御の対象となる複数の制御対象機器を
制御機器から制御する際に該制御機器の補助を行う制御
仲介サーバであって、前記制御対象機器と前記制御機器との組み合わせに基づ
いて決定されるユーザインタフェースの定義データを管
理するデータベースと、前記制御対象機器のうち現在制御可能な制御対象機器
と、前記制御補助対象機器に前記定義データを要求して
きた制御機器とを検索キーとして前記データベースを検
索する検索手段と、前記検索により抽出された定義データを前記制御機器に
送信する送信手段と、を含み、前記制御機器は前記送信された定義データに基づいて提
供されるユーザインタフェースに従って前記複数の制御
対象機器を制御することを特徴とする制御仲介サーバ。
【請求項１６】前記検索手段は、前記制御機器の種別情
報及び前記制御対象機器の種別情報を検索キーとして検
索を実行することを特徴とする請求項１５に記載の制御
仲介サーバ。
【請求項１７】制御の対象となる複数の制御対象機器を
制御機器から制御する際に、該制御を仲介する制御仲介
方法であって、前記制御対象機器の状態に関する状態関連情報を各制御
対象機器から受信するステップと、前記制御機器からの要求に応じて、前記受信された複数
の状態関連情報に対応するユーザインタフェースの定義
データを選択するステップと、前記選択された定義データを前記制御機器に送信するス
テップと、を含み、前記制御機器は、前記送信された定義データに基づいて
提供されるユーザインタフェースに従って前記複数の制
御対象機器を制御することを特徴とする制御仲介方法。
【請求項１８】制御の対象となる複数の制御対象機器を
制御機器から制御する際に該制御を仲介する制御仲介方
法であって、前記制御対象機器及び前記制御機器の組み合わせと、ユ
ーザインタフェースの定義データとの関係を管理するデ
ータベースを、前記制御対象機器のうち現在制御可能な
制御対象機器と前記定義データを要求する制御機器とを
検索キーとして検索するステップと、前記検索により抽出された定義データを前記制御機器に
送信するステップと、を含み、前記制御機器は前記送信された定義データに基づいて提
供されるユーザインタフェースに従って前記複数の制御
対象機器を制御することを特徴とする制御仲介方法。
【請求項１９】請求項１乃至請求項１６のいずれか１項
に記載された前記手段のすべてをコンピュータに機能さ
せるための制御プログラム。
【請求項２０】請求項１７乃至請求項１８のいずれか１
項に記載された前記ステップのそれぞれをコンピュータ
に実行させるためのプログラムコードを含む制御プログ
ラム。