JP2007048137A - 制御装置、制御方法、プログラム及び記憶媒体 - Google Patents

Abstract

【課題】 プロトコルの違いにより相互運用性が確保されていない場合に、他装置のプロトコルを自装置に反映させてシステム内の相互運用性を高める。
【解決手段】 ネットワークシステムには、第１のプロトコルデータに準拠して通信するように構成された複数の装置が接続している。ここで、他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、当該他装置間の通信データを収集する。そして、収集した通信データを解析して第２のプロトコルデータを取得し、他装置との通信に用いる自装置のプロトコルデータとして、第１のプロトコルデータに代えて第２のプロトコルデータを適用する。
【選択図】 図６

Description

本発明は、プロトコルデータによって相互運用性が確保されたシステムにおける装置を制御する制御装置、制御方法、プログラム及び記憶媒体に関する。

電子計算機技術の進歩により、従来は単一の機能しか有せず相互に有機的に接続することができなかったオフィス機器や一般の家庭用機器においても、ネットワークを通じた結合と処理の連携といった機能が実現されるようになった。このような機器制御装置のネットワークを通じた融合を実現するネットワーク技術として、ＵＰｎＰ（Universal Plug and Play）、Ｊｉｎｉ、Ｊｘｔａ等の機器制御用プロトコルが知られている。

次に、これらの機器制御用プロトコルの代表例として、ＵＰｎＰについて説明する。ＵＰｎＰは、インターネットの世界で事実上のデファクトスタンダードとなった、以下のようなプロトコルをサポートするネットワーク上で用いられる機器制御用プロトコルである。すなわち、ＩＰ（Internet Protocol）、ＴＣＰ（Transfer Control Protocol）、ＵＤＰ（User Datagram Protocol）がある。また、ＨＴＴＰ（Hyper Text Transfer Protocol）及びＸＭＬ（eXtensible Markup Language）等もある。

ＵＰｎＰでは、ネットワーク上に接続された機器制御装置の発見にＳＳＤＰ（Simple Service Discover Protocol）を用いる。また、制御対象となる機器制御装置のあらかじめ定義されている仕様や設定を表現するプロファイル情報の把握にもＳＳＤＰを用いる。ＳＳＤＰは、ＵＰｎＰを構成するための基幹部分であり、ＩＥＴＦから標準仕様が発行されている。機器の発見には、ＩＰブロードキャストを用いる。

例えば、「デジタルビデオストリームを再生できる機器は？」とブロードキャストする。この場合、条件に合う機器が自主的に問い合わせ元に対してＩＰアドレスとホスト名を送信する。制御対象となる機器制御装置のあらかじめ定義されている仕様や設定、具体的にどのような機能を持っているか等のプロファイル情報もこのときに交換する。情報交換に使われるデータ形式はＸＭＬであり、ＨＴＴＰにより通信される。

機器の制御には、ＳＯＡＰ（Simple Object Access Protocol）を用いる。ＳＯＡＰは、ＸＭＬ Ｗｅｂサービスのやり取りを円滑に行うために取り決められた、ＲＰＣベースのインターネット通信の業界標準プロトコルである。ＳＯＡＰを使用して制御メッセージを機器に送信し、リザルト又はエラーを取得する。ＵＰｎＰ制御要求は、パラメータを指定して呼び出すアクションを含んでいるＳＯＡＰメッセージであり、レスポンスもＳＯＡＰメッセージでステータスが含まれており、値とパラメータが返却される。

ＵＰｎＰに代表されるようなネットワークを通じて機器を相互に接続するために用いる機器制御用プロトコルは、ノード間の相互接続性を確保するため、仕様が決められている。当該仕様は、さまざまな組織で策定され勧告として発表されている。例えば、ＨＴＴＰ、ＳＯＡＰ等のＷｅｂ関連又はＷｅｂサービス関連の仕様の多くは、World Wide Web Consortium（ｗ３ｃ、Http://www.w3c.org）で策定されている。そして、インターネット関連の仕様の多くは、The Internet Engineering Task Force（ＩＥＴＦ、http://www.ietf.org）で策定され勧告として発表されている。

各種組織において仕様が厳密に策定され、また機器制御装置を開発するベンダーが仕様に完全に沿って機器制御用プロトコルを実装することによって、機器制御用プロトコルを用いた通信は全て成功し、相互運用性が確保される。しかし、現実には、仕様には「あいまいさ」があり厳密ではないことが多い。そのため、機器制御装置のベンダーが仕様に完全に沿って機器制御用プロトコルを実装したつもりであっても、仕様のあいまいさのために解釈の違いが発生し、通信が失敗するように相互運用性が確保されないことがある。

また、仕様に沿っていない実装も多々ある。さらに、仕様に沿っていないプロトコルを用いる機器制御装置が事実上の標準（デファクトスタンダード）となると次のような失敗が生じる。すなわち、仕様に沿ったプロトコルを用いる機器制御装置をベンダーが開発しても、事実上の標準となった機器制御用プロトコルを用いる機器制御装置との通信は失敗してしまう。通信が失敗する例として、例えば、ある実装では大文字小文字を区別していないが、別の実装では区別するため通信が失敗することがある。また、ＳＯＡＰ等のＸＭＬ関連の機器制御用プロトコルでは、ネームスペースの有無により通信が失敗する等といった例も挙げられる。

相互運用性を向上させるために、機器制御用装置のベンダーは様々なことを行う。例えば、プロトコルモニタを用いてネットワーク上を流れる機器制御用プロトコルを監視して違いを把握する、複数のベンダーが製品を一箇所に持ち寄って通信実験を行う、等といったことが行われる。そして、機器制御用プロトコルの違いを発見した場合には、それを修正することによって相互運用性を向上させる。機器制御用プロトコルの違いを発見するプロトコルモニタに関する提案の１つとして、機器制御用プロトコルの誤り箇所を検出し、自動的に指摘することを可能とするものがある（例えば、特許文献１参照。）。
特開平８−８８６７２号公報

しかしながら、上記特許文献１に記載されたような対応は、製品を出荷する前に行う対応であり、出荷後の対応は容易ではない。前述した相互運用性を向上させるための通信実験にしても、市場に存在する全ての機器制御装置を集めて実験することは不可能であり、検証が十分に行われることはない。そのため、製品を使用するユーザは、製品購入前に、購入対象の製品がどのような機器と通信を行えたかを調査し、インターネット上での報告を探す等して、相互運用性が高いと思われる製品を選ばざるをえない。また、ベンダー側としては、相互運用性を確保するため、ユーザにファームウェアを更新させたり、製品を回収し、製品内のプログラムを書き換えたりする等の対応を取らなければならない場合がある。

本発明は、このような事情を考慮してなされたものであり、特定のプロトコルに準拠した複数の装置から構成されるネットワークにおいて相互運用性を高めるために、以下のような制御装置、制御方法、プログラム及び記憶媒体を提供することを目的とする。すなわち、プロトコルの違いにより相互運用性が確保されていない場合に、他装置のプロトコルを自装置に反映させてシステム内の相互運用性を高めることができる。

上記課題を解決するため、本発明に係る制御装置は、
第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステムにおいて、他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集手段と、
前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用手段と
を備えることを特徴とする。

また、上記課題を解決するため、本発明は、第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステム内の装置の制御方法であって、
他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集工程と、
前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用工程と
を有することを特徴とする。

さらに、上記課題を解決するため、本発明に係るプログラムは、
第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステム内のコンピュータに、
他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集手順と、
前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用手順と
を実行させることを特徴とする。

さらにまた、上記課題を解決するため、本発明に係る記憶媒体は、上記プログラムを格納したことを特徴とする。

本発明によれば、プロトコルの違いにより相互運用性が確保されていない場合に、他装置のプロトコルを自装置に反映させてシステム内の相互運用性を高めることができる。

特に、プロトコル仕様のあいまいさによりベンダー間の解釈の違いが発生して相互運用性が確保されていない場合に、事実上の標準として相互運用性が確保されているプロトコルを自装置に反映させてシステム内の相互運用性を高めることができる。

以下、図面を参照して、本発明の一実施形態について説明する。以下では、具体的な一実施形態について記載しているが、本発明はこの具体的な一実施形態だけに限定されるものではない。

図１は、本発明の一実施形態に係るネットワークシステム全体の構成図である。図１に示すように、本ネットワークシステムには、デジタルカメラ１００、デジタルビデオカメラ１０１、プリンタ１０２、スキャナ１０３、プロジェクタ１０４が、ネットワーク１０５を介して互いに接続している。尚、本実施形態では、５種類のデバイスがネットワーク１０５に接続している例を挙げているが、この種類だけのデバイスに限定されるものではない。

図２は、本発明の従来技術に係るネットワークシステム構成の概要を説明するための図である。図２に示す従来のネットワークシステムでは、ネットワークシステム２００は、機器制御用プロトコルＡに準拠して構成されている複数の機器制御装置からなる。図２では、機器制御プロトコルＡに準拠している機器制御装置である機器制御装置Ａ（２０１）、機器制御装置Ｂ（２０２）、機器制御装置Ｃ（２０３）が接続している。そして、機器制御装置Ｂ（２０２）と機器制御装置Ｃ（２０３）が、機器制御用プロトコルＡの仕様のあいまいさにより生じた誤解により機器制御用プロトコルＡには厳密に準拠していない機器制御用プロトコルＡ’により相互運用性が確保されている。すなわち、この３台の装置から構成されるネットワーク環境下では、機器制御用プロトコルＡ’がローカルルールになっている。このような場合に、機器制御装置Ｂ（２０２）と機器制御装置Ｃ（２０３）の間の通信（２０５）は成功する。しかし、機器制御装置Ａ（２０１）と機器制御装置Ｂ（２０２）の間の通信（２０４）と、機器制御装置Ａ（２０１）と機器制御装置Ｃ（２０３）の間の通信（２０６）は失敗する。したがって、このようなネットワークシステムでは、３台での相互運用性が確保できていないこととなる。

例えば、機器制御用プロトコルＡを「ＨＴＴＰ／１．１」（RFC2616 R.Fielding他、 http://www.ietf.org/rfc/rfc2616.txt、June、1999）として説明する。具体的には、「ＨＴＴＰ／１．１」において、図４（ａ）に示すメッセージを機器制御用プロトコルＡ、図４（ｃ）のメッセージを機器制御用プロトコルＡ’とする。この場合、機器制御装置Ａ（２０１）と機器制御装置Ｂ（２０２）の間の通信（２０４）、及び機器制御装置Ａ（２０１）と機器制御用装置Ｃ（２０３）の間の通信（２０６）は次のようになる。すなわち、図４（ａ）、（ｃ）に示すように、１行目の文字列「ＧＥＴ」と「ｇｅｔ」のような大文字と小文字の違いにより、図４（ｂ）に示すエラーメッセージを返すため、失敗してしまう場合がある。

図４（ａ）は、標準に準拠した機器制御プロトコルＡによる通信メッセージの一例を示す図である。また、図４（ｂ）は、標準に準拠した機器制御プロトコルＡによる通信に失敗した際の返信メッセージの一例を示す図である。さらに、図４（ｃ）は、仕様のあいまいさ等の理由により、厳密にはトリビアルＡ’による通信メッセージの一例を示す図である。図４（ｄ）は、仕様のあいまいさ等の理由により、厳密には標準に準拠していない機器制御用プロトコルＡ’による通信に成功した際の返信メッセージの一例を示す図である。

一方、図３は、本発明の一実施形態に係るネットワークシステム構成の概要を説明するための図である。図３では、ネットワークシステム３００は、機器制御用プロトコルＡに準拠している複数の機器制御装置から構成されている。システム内の装置として、機器制御プロトコルＡに準拠している機器制御装置である機器制御装置Ａ（３０１）、機器制御装置Ｂ（３０２）、機器制御装置Ｃ（３０３）が接続している。そして、機器制御装置Ｂ（３０２）と機器制御装置Ｃ（３０３）は、機器制御用プロトコルＡの仕様のあいまいさにより生じた誤解により、機器制御用プロトコルＡには厳密に準拠していない機器制御用プロトコルＡ‘により相互運用性が確保されている。

このような場合に、機器制御装置Ａ（３０１）は、機器制御装置Ｂ（３０２）から受信するメッセージ（３０４）と機器制御装置Ｃ（３０３）から受信するメッセージ（３０６）を監視する。また、機器制御装置Ａ（３０１）は、機器制御装置Ｂ（３０２）と機器制御装置Ｃ（３０３）の間で通信されるメッセージ（３０５）を監視する。

具体的には、機器制御装置Ａ（３０１）のネットワークインタフェースをプロミスキャスモード（Promiscuous mode）で動作させ、ネットワーク２００上に流れる全パケットを受信して通信データを収集する。そして、収集した通信データを解析し、機器制御用プロトコルＡと機器制御用プロトコルＡ’の差分を抽出し、機器制御用装置Ａ（３０１）が使用できる機器制御用プロトコルに適用する。その結果、機器制御装置Ａ（３０１）は、ローカルルールである機器制御用プロトコルＡ’を使用して機器制御装置Ｂ（３０２）との通信（３０７）と機器制御装置Ｃ（３０３）との通信（３０８）が可能となり、３台での相互運用性を確保することが可能となる。

例えば、機器制御用プロトコルＡを「ＨＴＴＰ／１．１」とする。すなわち、図４（ａ）に示すメッセージを機器制御用プロトコルＡ、図４（ｃ）に示すメッセージを機器制御用プロトコルＡ’とする。この場合、機器制御装置Ａ（３０１）と機器制御装置Ｂ（３０２）の間の通信（３０４）、及び機器制御装置Ａ（３０１）と機器制御用装置Ｃ（３０３）の間の通信（３０６）は、次のようになる。すなわち、１行目の文字列「ＧＥＴ」と「ｇｅｔ」のような大文字と小文字の違いにより、図４（ｂ）に示すエラーメッセージを返すこととなる。そのため、通信に失敗した場合には、機器制御装置Ａ（３０１）は、機器制御装置Ｂ（３０２）から受信するメッセージ（３０４）と機器制御装置Ｃ（３０３）から受信するメッセージ（３０６）を監視して通信データを収集する。また、機器制御装置Ａ（３０１）は、機器制御装置Ｂ（３０２）と機器制御装置Ｃ（３０３）の間で通信されるメッセージ（３０５）を監視して通信データを収集する。

そして、収集した通信データを解析し、機器制御用プロトコルＡと機器制御用プロトコルＡ’の差分（例えば、図４（ａ）と図４（ｃ）の１行目の文字列「ＧＥＴ」と「ｇｅｔ」の違い）を抽出する。そして、機器制御装置Ａ（３０１）は、その差分を機器制御用装置Ａ（３０１）が使用できる機器制御用プロトコルに適用する。その結果、機器制御装置Ａ（３０１）は、ローカルルールである機器制御用プロトコルＡ’（図４（ｃ））を使用して機器制御装置Ｂ（３０２）との通信（３０７）及び機器制御装置Ｃ（３０３）との通信（３０８）が可能となる。尚、通信が可能な場合には、リターン値として、図４（ｄ）に示すメッセージが返却される。これによって、３台での相互運用性を確保することが可能となる。

次に、本発明の一実施形態に係るネットワークシステムに接続している機器制御装置について説明する。図５は、本発明の一実施形態に係るネットワークシステム内の機器制御装置をＰＣ（パーソナルコンピュータ）を使用して実現した場合のブロック図である。尚、機器制御装置としては、ＰＣ以外に、ワークステーション、ノートブックＰＣ、パームトップＰＣ等でも実現可能である。また、コンピュータを内蔵したテレビ等の各種家電製品、通信機能を有するゲーム機、電話、ＦＡＸ、携帯電話、ＰＨＳ、電子手帳、等を含む他の機器制御装置と通信するための通信機能を有する端末、又は、これらの組合せによっても実施可能である。

図５において、５０１は、システムの制御を司る中央演算装置（ＣＰＵ）である。５０２は、ランダムアクセスメモリ（ＲＡＭ）であり、ＣＰＵ５０１の主メモリとして、及び実行プログラムの領域や当該プログラムの実行エリア並びにデータエリアとして機能する。

５０３は、ＣＰＵ５０１の動作処理手順を記録しているリードオンリーメモリー（ＲＯＭ）である。ＲＯＭ５０３には、システムの機器制御を行うシステムプログラムである基本ソフト（ＯＳ）を記録したプログラムＲＯＭとシステムを稼動するために必要な情報等が記録されたデータＲＯＭがある。ＲＯＭ５０３の代わりに、後述のＨＤＤ５０９を用いる場合もある。

５０４は、ネットワークインタフェース（ＮＥＴＩＦ）であり、ネットワークを介してシステム間のデータ転送を行うための制御や接続状況の診断を行う。５０５は、ビデオＲＡＭ（ＶＲＡＭ）であり、システムの稼動状態を示す後述するＣＲＴ５０６の画面に表示される画像を展開し、その表示の制御を行う。５０６は、表示装置であって、例えば、ディスプレイである。本実施形態では、ＣＲＴと記す。

５０７は、後述する外部入力装置５０８からの入力信号を制御するコントローラである。５０８は、システムの利用者がシステムに対して行う操作を受け付けるための外部入力装置であり、例えば、キーボード等である。

５０９は、記憶装置を示し、例えば、ハードディスク等である。アプリケーションプログラムや、画像情報等のデータ保存用に用いられる。本実施形態におけるアプリケーションプログラムとは、本実施形態を構成する各種機器制御手段を実行するソフトウェアプログラム等である。

５１０は、外部入出力装置であって、例えばフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ等のリムーバブル記憶装置を入出力するものであり、上述したアプリケーションプログラムの媒体からの読み出し等に用いられる。以下では、ＦＤＤと記す。尚、ＨＤＤ５０９に格納するアプリケーションプログラムやデータをＦＤＤ５１０に格納して使用することも可能である。

そして、図５において、５００は、上述した各ユニット間の接続するための入出力バス（アドレスバス、データバス、及び制御バス）である。

図６は、本発明の一実施形態に係る機器制御装置で実行されるアプリケーションモジュール構成を説明するための図である。

図６に示すように、機器制御装置は、機器制御アプリケーション６００、機器制御機能提供部６０１、機器制御機能実行部６０２、メッセージ送受信部６０３を有する。まず、機器制御機能提供部６０１は、プロファイル情報表現部６０１ａ、プロファイル情報操作部６０１ｂ、機器集合情報操作部６０１ｃを含む構成である。また、機器制御機能実行部６０２は、プロトコル制御部６０２ａ、相互運用性判定部６０２ｂ、プロトコルデータ収集部６０２ｃ、差分抽出部６０２ｄ、差分適用部６０２ｅを含む構成である。さらに、メッセージ送受信部６０３は、メッセージ送信部６０３ａ、メッセージ受信部６０３ｂを含む構成である。

図７は、本発明の一実施形態に係る機器制御装置における処理を説明するためのフローチャートである。

まず、機器制御機能提供部６０１が、機器制御アプリケーション６００から処理要求を受信する（ステップＳ７００）。次に、機器制御機能提供部６０１は、制御内容を決定し、プロトコル制御部６０２ａに対してコマンドを発行する（ステップＳ７０１）。そして、プロトコル制御部６０２ａは、メッセージ送信部６０３ａから制御対象機器制御装置に対して送信する（ステップＳ７０２）。尚、メッセージ送信部４０７ａから送信される際には、インターネットプロトコル（ＩＰ）が用いられる。この場合ＩＰのバージョンは、ＩＰｖ４とＩＰｖ６の双方が使用可能である。また、実際に通信経路として使用される媒体は、有線或いは無線を用いることができる。機器制御用プロトコルによっては、さらにＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ、ＳＮＭＰ、ＦＴＰ等の通信プロトコルが用いられる場合もある。そして、相互運用性判定部６０２ｂは、メッセージの送信が成功したかどうかを判定する（ステップＳ７０３）。

ステップＳ７０３の判定結果から、メッセージ送信成功と判定された場合（Ｙｅｓ）は、相互運用性が確保されているため、ステップＳ７０７の処理に移行する。一方、ステップＳ７０３において、メッセージ送信失敗と判定された場合（Ｎｏ）は、相互運用性が確保されていないため、ステップＳ７０４に移行する。

ステップＳ７０４では、プロトコルデータ処理部６０２ｃ及び差分抽出部６０２ｄは、データ収集及び差分抽出処理を実施する。尚、ステップＳ７０４における処理の詳細については図８を用いて後述する。

ステップＳ７０４においてデータ収集及び差分抽出処理が終了した後、差分抽出が成功したかどうかを判定する（ステップＳ７０５）。その結果、差分抽出に成功したと判定された場合（Ｙｅｓ）は、差分適用部６０２ｅは、図９に示したような抽出された差分情報をプロトコル制御部６０２ａに適用する（ステップＳ７０６）。すなわち、図９は、抽出された差分情報を記憶したテーブルの一例を示す図である。

その後、アプリケーションを終了するかどうかを判定する（ステップＳ７０７）。その結果、アプリケーションをまだ継続すると判定された場合（Ｎｏ）は、ステップＳ７００の処理に移行する。一方、ステップＳ７０７において、終了と判定された場合（Ｙｅｓ）は、本処理を終了する。

尚、図７に示すフローチャートでは、メッセージを送信した機器制御装置が、メッセージ送信失敗と判定した場合に（ステップＳ７０３でＮｏの場合）、データ収集及び差分抽出処理を実施する形態（ステップＳ７０４）を説明した。これ以外に、例えば、メッセージを受信した機器制御装置が、受信メッセージを解釈できずにエラーメッセージを送信する場合に、データ収集及び差分抽出処理を実施するようにしてもよい。

図８は、図７に示すフローチャートにおけるデータ収集及び差分抽出処理（ステップＳ７０７）を詳細に説明するためのフローチャートである。

まず、プロトコルデータ収集部６０２ｃは、ネットワーク上に流れる全パケットを受信するために、メッセージ送受信部６０３に対して自身が管理するネットワークインターフェースをプロミスキャスモードで動作させるよう依頼する（ステップＳ８００）。そして、ネットワーク上に流れているメッセージをメッセージ受信部６０３ｂにおいて受信する（ステップＳ８０１）。尚、メッセージ受信部６０３ｂで受信する際には、インターネットプロトコル（ＩＰ）が用いられる。この場合のＩＰのバージョンは、ＩＰｖ４とＩＰｖ６の双方が使用可能である。また、実際に通信経路として使用される媒体は、有線或いは無線を用いることができる。機器制御用プロトコルによっては、さらにＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ、ＳＮＭＰ、ＦＴＰ等の通信プロトコルが用いられる場合もある。

次いで、プロトコルデータ収集部６０２ｃは、ステップＳ８０１において受信したメッセージを解析する（ステップＳ８０２）。さらに、差分抽出部６０２ｄは、プロトコル制御部６０２ａが制御している機器制御用プロトコルとステップＳ８０２においてプロトコルデータ収集部６０２ｃが解析したデータとの差分情報を抽出する（ステップＳ８０３）。このときに抽出される差分情報としては、例えば、機器制御用プロトコルが「ＨＴＴＰ／１．１」の場合は、図４（ａ）と図４（ｃ）の１行目の文字列「ＧＥＴ」と「ｇｅｔ」のようなトリビアルな（些細な）差分を抽出する。また、抽出された差分情報は、図９に示すようなテーブルの形態で記録される。

そして、差分情報の抽出に成功したかどうかを判定する（ステップＳ８０４）。その結果、差分情報の抽出に成功したと判定された場合（Ｙｅｓ）は、本処理を終了し、図７のステップＳ７０５の処理に移行する。一方、差分情報の抽出に失敗したと判定された場合（Ｎｏ）は、ステップＳ８０５の処理に移行する。ステップＳ８０５では、データ収集及び差分抽出処理を継続するかどうかを判定する。尚、ステップＳ８０５において用いられる判定基準としては、例えば、収集時間や収集回数等がある。また、判定基準はこの２つに限定されるものではなく、任意の判定基準を適用することが可能である。

ステップＳ８０５において、データ収集及び差分抽出処理を継続すると判定された場合（Ｙｅｓ）は、ステップＳ８０１の処理に移行する。一方、ステップＳ８０５において、データ収集及び差分抽出処理を終了すると判定された場合（Ｎｏ）は、本処理を終了し、図７のステップＳ７０５の処理に移行する。

例えば、制御コマンド「ＧＥＴ」を送信してエラーメッセージを受信した場合は、送信した「ＧＥＴ」を所定の関係を有するメッセージを収集する。例えば、「ＧＥＴ」と大文字／小文字の文字の種別の異なるコマンド「ｇｅｔ」を収集する。そして、この差分（大文字小文字の文字種別の差）の抽出に成功すると（ステップＳ７０５）、「ＧＥＴ」の代わりに「ｇｅｔ」を送信する。

また、コマンドに付加されたパラメータが原因でエラーになった場合には、以下のようになる。すなわち、例えば、受信側は、「ＧＥＴ」コマンドに付加されるパラメータとして、ＨＴＴＰのＧＥＴメソッドとして使用されるＨＯＳＴ（インターネットホストとポート番号）とＡｃｃｅｐｔ−Ｌａｎｇｕａｇｅ（レスポンスとして望む言語）を必須としている。しかし、これにもかかわらず、送信側が、ＨＯＳＴのみ（Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅが付加されない）がパラメータとして付加された「ＧＥＴ」コマンドを送信し、エラーになった場合は以下のようになる。

この場合、送信側は、送信エラーになった「ＧＥＴ」コマンドと所定の関係を有するコマンドを収集する（ステップＳ７０４）。ここでは、送信エラーになった「ＧＥＴ」コマンドとは、付加されるパラメータの異なる「ＧＥＴ」コマンドが収集される。すなわち、パラメータとして「ＨＯＳＴ」と「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」が付加された「ＧＥＴ」コマンドが収集される。このパラメータの差分の抽出に成功すると、「ＨＯＳＴ」のみが付加された「ＧＥＴ」コマンドの代わりに、「ＨＯＳＴ」と「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」が付加された「ＧＥＴ」コマンドとすることができる。

「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」として何を要求するかは、送信側に予め設定された「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」を要求するようにすればよい。また、収集した「ＧＥＴ」コマンドに付加された「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」の内容を表示し、その中から、使用者が所望の「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」を選択するようにしてもよい。

尚、送信側は、受信側で要求されているパラメータ（例えば、「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」）を自装置が有するか判断する。そして、自装置が有さないパラメータであると判断すると、受信側が使用しているプロトコルは許容できないとして、受信側へのメッセージの送信を中止する。また、コマンドの大文字／小文字と、コマンドに付加されたパラメータの両方に差異がある場合も、同様に、対応することができる。

以上説明したように本実施形態によれば、特定の機器制御用プロトコルを用いてネットワークを通じた制御が可能な複数の機器制御装置から構成されるネットワークにおいて、好適に相互接続性（相互運用性）を確保することが可能となる。具体的には、同一の機器制御用プロトコルを使用しているにもかかわらず、仕様のあいまいさ等の理由により生じた実装上の誤解により、相互接続性が確保されない場合がある。すなわち、このような仕様のあいまいさがあると、ベンダー間の解釈の違いが発生し、相互運用性が確保されていない場合が起こり得る。このような場合に、自機器制御装置が使用している機器制御用プロトコルと、接続しているネットワークで有効である機器制御用プロトコルとの差分を抽出し、自機器制御装置の機器制御用プロトコルに反映させて修正する。これによって、当該ネットワーク下において、修正後の機器制御用プロトコルが事実上の標準となり、ローカルルールにより相互運用性を高めることができる。

また、上記処理に併せて、自機器制御装置の機器制御用プロトコルと、接続しているネットワーク上で使用されている機器制御用プロトコルとに相互運用性があるかを判定することができる。さらに、本来であれば同一であるはずであるが、仕様の解釈の違い等の理由で相互運用性がないかを判定することも可能である。

さらに、自機器制御装置が使用している機器制御用プロトコルとネットワーク上で使用されている他の機器制御用プロトコルとの間に相互運用性がないと判定された場合に、仕様の解釈の違い等の相互運用性を阻害している原因を突き止めることが可能となる。

以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体（記録媒体）等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、以下のようなものがある。フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。すなわち、ホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをダウンロードする。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他にも、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

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

本発明の一実施形態に係るネットワークシステム全体の構成図である。 本発明の従来技術に係るネットワークシステム構成の概要を説明するための図である。 本発明の一実施形態に係るネットワークシステム構成の概要を説明するための図である。 （ａ）は、標準に準拠した機器制御プロトコルＡによる通信メッセージの一例を示す図である。（ｂ）は、標準に準拠した機器制御プロトコルＡによる通信に失敗した際の返信メッセージの一例を示す図である。（ｃ）は、仕様のあいまいさ等の理由により、厳密にはトリビアルＡ’による通信メッセージの一例を示す図である。（ｄ）は、仕様のあいまいさ等の理由により、厳密には標準に準拠していない機器制御用プロトコルＡ’による通信に成功した際の返信メッセージの一例を示す図である。 本発明の一実施形態に係るネットワークシステム内の機器制御装置をＰＣ（パーソナルコンピュータ）を使用して実現した場合のブロック図である。 本発明の一実施形態に係る機器制御装置で実行されるアプリケーションモジュール構成を説明するための図である。 本発明の一実施形態に係る機器制御装置における処理を説明するためのフローチャートである。 図７に示すフローチャートにおけるデータ収集及び差分抽出処理（ステップＳ７０７）を詳細に説明するためのフローチャートである。 抽出された差分情報を記憶したテーブルの一例を示す図である。

符号の説明

３０１ 機器制御装置Ａ
３０２ 機器制御装置Ｂ
３０３ 機器制御装置Ｃ
３０４、３０５、３０６、３０７、３０８ 通信
６００ 機器制御アプリケーション
６０１ 機器制御機能提供部
６０１ａ プロファイル情報表現部
６０１ｂ プロファイル情報操作部
６０１ｃ 機器集合情報操作部
６０２ 機器制御機能実行部
６０２ａ プロトコル制御部
６０２ｂ 相互運用性判定部
６０２ｃ プロトコルデータ収集部
６０２ｄ 差分抽出部
６０２ｅ 差分適用部
６０３ メッセージ送受信部
６０３ａ メッセージ送信部
６０３ｂ メッセージ受信部

Claims (10)

1. 第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステムにおいて、他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集手段と、
   前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用手段と
   を備えることを特徴とする制御装置。
2. 前記適用手段が、
   前記通信データを解析して前記第１のプロトコルデータと前記第２のプロトコルデータとの差分データを抽出する抽出手段と、
   前記差分データを用いて自装置が使用する前記第１のプロトコルデータを前記第２のプロトコルデータに修正する修正手段と
   を備えることを特徴とする請求項１に記載の制御装置。
3. 前記抽出手段による前記差分データの抽出が成功したか否かを判定する抽出判定手段をさらに備え、
   前記修正手段は、前記抽出判定手段によって前記差分データの抽出が成功したと判定されたことを条件として、該差分データを用いて前記第１のプロトコルデータを前記第２のプロトコルデータに修正する
   ことを特徴とする請求項２に記載の制御装置。
4. 前記他装置間で相互運用性が確保されている前記第２のプロトコルの使用を前記自装置が許容することができるかどうかを判定する許容判定手段をさらに備えることを特徴とする請求項１に記載の制御装置。
5. 自装置が使用する前記第１のプロトコルデータによって前記他装置との間で相互運用性が確保されているか否かを判定する運用性判定手段をさらに備え、
   前記収集手段は、前記運用性判定手段によって前記他装置との間で相互運用性が確保されていないと判定されたことを条件として、該他装置間の通信データを収集する
   ことを特徴とする請求項１に記載の制御装置。
6. 前記第２のプロトコルデータが前記第１のプロトコルデータの仕様のあいまいさのために解釈の違いが発生した結果に基づくプロトコルデータであることを特徴とする請求項１から５までのいずれか１項に記載の制御装置。
7. 前記収集手段が、自装置のネットワークインタフェースをプロミスキャスモードで動作させ、前記他装置間で通信される全パケットを受信して前記通信データを収集することを特徴とする請求項１から６までのいずれか１項に記載の制御装置。
8. 第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステム内の装置の制御方法であって、
   他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集工程と、
   前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用工程と
   を有することを特徴とする制御方法。
9. 第１のプロトコルデータに準拠して通信するように構成された複数の装置からなるシステム内のコンピュータに、
   他装置間で第２のプロトコルデータにより相互運用性が確保されている場合に、該他装置間の通信データを収集する収集手順と、
   前記通信データを解析して前記第２のプロトコルデータを取得し、前記他装置との通信に用いる自装置のプロトコルデータとして、前記第１のプロトコルデータに代えて該第２のプロトコルデータを適用する適用手順と
   を実行させるためのプログラム。
10. 請求項９に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記憶媒体。