JP5802049B2 - デバイス制御装置及び方法、クライアント装置、並びにデバイス制御システム - Google Patents

Description

本発明は、デバイス制御装置及び方法、クライアント装置、並びにデバイス制御システムに関し、特に、ネットワークを介してデバイスを制御する機能を備えたデバイス制御装置及び方法、クライアント装置、並びにデバイス制御システムに関するものである。

ネットワークの普及により、従来、パーソナルコンピュータ（ＰＣ）等にローカル接続して利用していたデバイス（周辺機器）をネットワーク上のクライアントＰＣから利用できるように構成されたデバイスサーバが発表されている。

例えば、プリンタ、ストレージ、スキャナ等のデバイスを、ネットワーク上のクライアントＰＣからデバイスサーバを介して共有デバイスとして利用する方法がいくつか提案されている。

ひとつの方法として、クライアントＰＣに専用のアプリケーションソフトウェア（以下、「ユーティリティ」という）を導入しておき、ユーザがデバイスにアクセスしようとするときに、導入されたユーティリティを操作して、クライアントＰＣに、アクセスすべきデバイスをローカル接続したデバイスとして仮想的に認識させることにより、ネットワーク上のクライアントＰＣから、アクセスすべきデバイスにローカル接続したデバイスとしてアクセスできるようにするものがある。

この方法では、ユーザによるセッション（接続）の開始・終了操作が必要であり、ユーザがユーティリティを使ってデバイスの終了操作をしない限り、デバイスサーバとのセッションが専有されてしまうため、他のクライアントＰＣがデバイスを使用することができない。

かかる問題を解決するために、ブロックヘッダで特定されるデータ長を有するブロックデータが伝送される間だけ、デバイスサーバがデータ伝送専有状態にあるとして、特定のクライアントＰＣにデバイスとの間のデータ伝送を許可するネットワークファイル管理システムが開示されている（例えば、特許文献１参照）。

特開２００７−３１７０６７号公報

確かに、特許文献１に開示されたネットワークファイル管理システムでは、複数のクライアントＰＣは手動操作を行うことなくデバイスを共有することはできる。

しかしながら、クライアントＰＣがネットワーク経由で接続された１台のデバイスを専有している状態においては、当該クライアントＰＣが他のデバイスを使用することはできないという技術的な制限により、クライアントＰＣとの専有状態を高頻度で必要とするデバイスが接続された場合には、そのクライアントＰＣは他のデバイスとの同時使用が困難になってしまう。

例えば、ＩＣカードリーダのようなデバイスの場合、ＩＣカードが検知されたか否かの問い合わせ（ポーリング）、すなわち、デバイス監視処理（状態変化検知処理）を周期的に行う必要があるが、このデバイス監視処理は、一般的に、クライアントＰＣにインストールされたデバイスドライバによって実行される。

このため、クライアントＰＣによるネットワークを介したデバイスの専有が頻繁に発生するとともに、当該デバイスの専有中はネットワーク上のトラフィックが著しく増加するので、このようなデバイスの専有は、必要最小限であることが望ましい。

また、デバイスの専有が頻発し、常にネットワーク上にデータが伝送されている状態では、データがハッキングされやすく、セキュリティの面からも望ましくない。

加えて、前述のデバイス監視処理（状態変化検知処理）は、デバイス毎に処理内容が異なる機種依存性をなくすようにするために、デバイスサーバに特定のデバイスに適合したトリガ検知アルゴリズムだけを保持させたときは、デバイスサーバの汎用性が損なわれるという問題がある。一方で、デバイスサーバにシステムに存在する様々なデバイスに適合したトリガ検知アルゴリズムをすべて保持させたときは、デバイスサーバの汎用性は確保できるものの、デバイスサーバは大容量の記憶領域を必要とし、コスト増を招くという問題がある。

本発明の第１の目的は、従来、クライアント装置に実装されていたデバイス監視処理（状態変化検知処理）をデバイス制御装置が備えることで、デバイス制御装置がクライアント装置との通信を伴わずに自立的にデバイスの状態変化を監視し、デバイスの状態変化を検知した時点でこれをクライアント装置へ通知することにより、クライアント装置によるデバイスの監視（ポーリング）を不要とし、ネットワーク上のトラフィックを低減することができるデバイス制御装置及び方法、クライアント装置、並びにデバイス制御システムを提供することにある。

本発明の第２の目的は、デバイスの状態変化を契機に、クライアント装置とデバイスが通信を行うことで、クライアント装置は必要なときだけデバイスを専有してセキュリティの脆弱性を低減するとともに、専有が頻繁に必要なデバイスであっても複数台数を同時に使用することができるデバイス制御装置及び方法、クライアント装置、並びにデバイス制御システムを提供することにある。

本発明の第３の目的は、監視対象となったデバイスに適合したトリガ検知アルゴリズムや定義ファイルをデバイスサーバへ動的にインストールまたはダウンロードすることにより、デバイスサーバは汎用性を確保しながらも様々なデバイスの検知処理を実行することができるデバイス制御装置及び方法、クライアント装置、並びにデバイス制御システムを提供することにある。

上記目的を達成するために、本発明のデバイス制御装置は、ネットワークを介してクライアント装置に接続されていると共にデバイスがローカル接続されるべきデバイス制御装置であって、前記デバイスの状態を監視するための定義ファイル及びトリガ検知アルゴリズムを用いて当該デバイスの状態を監視し、当該デバイスの状態変化を検知する第１の検知手段と、前記デバイスの状態変化が検知されたときに、当該状態変化の検知を示すトリガ通知を前記クライアント装置に送信する送信手段と、前記トリガ通知を受信したクライアント装置とセッションを開始して、前記状態変化を検知したデバイスとのデータ通信を中継するデータ通信制御手段と、前記デバイスとのデータ通信が終了して当該クライアント装置とのセッションが切断されたことを検知する第２の検知手段と、前記クライアント装置とのセッションが切断されたとき、前記第１の検知手段に前記デバイスの状態の監視を再開させる再開手段とを備えることを特徴とする。

本発明のクライアント装置は、デバイスがローカル接続されるべきデバイス制御装置にネットワークを介して接続されているクライアント装置であって、当該デバイス制御装置にローカル接続されたデバイスの動作状態を確認するためのポーリングを行う際に蓄積された前記デバイスに対する要求情報及び前記デバイスからの応答情報を含む定義ファイルを作成する作成手段と、前記作成された定義ファイルを前記デバイス制御装置に送信する送信手段と、前記デバイスの状態変化を検知した前記デバイス制御装置から前記デバイスの状態変化の検知を示すトリガ通知を受信する受信手段と、前記受信手段によって受信された前記トリガ通知に応じて前記デバイス制御装置とのセッションを開始するセッション制御手段とを備えることを特徴とする。

上記構成によれば、デバイスサーバが「トリガ検知アルゴリズム」／「定義ファイル」に基づき、該当デバイスを監視し、デバイスの状態変化を検知すると、トリガ通知する。トリガ通知を受けたクライアントＰＣは、デバイスサーバとセッションを開始し、クライアントＰＣ及びデバイス間でデータ通信を実行する。データ通信が終了し、セッションが切断されると、デバイスサーバは、該当デバイスの監視を再開する。これにより、クライアントＰＣ側で実装されていたデバイス監視処理を、デバイスサーバが実施するので、クライアントＰＣ側での監視処理が不要となり、必要な時だけ、クライアントＰＣ及びデバイス間でデータ通信し、通信終了すると、当該デバイスの監視を再開する。

また、クライアントＰＣは、デバイスの接続を検知すると、当該デバイスの動作状態を確認するためのポーリングを実行し、このときの送受信パケットを蓄積してデバイスサーバに送る。デバイスサーバは、この送受信パケットを定義ファイルとして用いることで、監視処理を実行することができるので、新たに接続が検知されたデバイスであっても、当該デバイスの監視処理が可能となる。

本発明の第１の実施の形態に係るデバイス制御システムの概略構成を示す図である。 図１のデバイス制御システムの動作シーケンスを説明するのに用いられるシーケンス図である。 図１におけるデータ記憶部に格納される定義ファイルのデータ構成を説明するのに用いられる図である。 図１におけるデバイスサーバによって実行されるトリガ検知処理の手順を示すフローチャートである。 本発明の第２の実施の形態に係るデバイス制御システムの動作シーケンスを説明するのに用いられるシーケンス図である。 図５の動作シーケンスで送受信されるパケットの基本構成を説明するのに用いられる図である。 図５の動作シーケンスで送信される要求／応答パケットのデータ構造、及びこれらを蓄積して作成される定義ファイルを説明するのに用いられる図である。

以下、本発明を図面に示す実施の形態を参照しながら詳細に説明する。

＜デバイス制御システムの構成＞
図１は、本発明の第１の実施の形態に係るデバイス制御システムの概略構成を示す図である。

図１において、本発明の第１の実施の形態に係るデバイス制御システムは、クライアントＰＣ１００（クライアント装置）と、デバイス３００（３００Ａ，３００Ｂ）がローカル接続されるデバイスサーバ２００（デバイス制御装置）とを備える。クライアントＰＣ１００とデバイスサーバ２００は、互いにネットワーク５００を介して接続されている。ネットワーク５００は有線又は無線の通信回線で構成されてもよい。

デバイス３００は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インターフェースに準拠した接続ケーブル４００でデバイスサーバ２００に接続（ローカル接続）される。ただし、接続ケーブル４００は、ＵＳＢインターフェースに限定されるものではなく、ＩＥＥＥ１３９４等他のインターフェースに準拠したものであってもよい。

次に、デバイス制御システムを構成する各装置の構成について順次説明する。

＜クライアントＰＣ１００の構成＞
クライアントＰＣ１００は、内部バスで互いに接続されたＣＰＵ、入力部、表示部、メモリ、通信部、外部記憶部で構成され、ネットワーク５００を介してデバイスサーバ２００と通信することができる。

外部記憶部は、不図示のオペレーティングシステム（以下、ＯＳ）、アプリケーションプログラム１０１、常駐モジュール１０２、デバイスドライバ１０３、仮想化制御部１０４、通信制御部１０５等のソフトウェア部品に加えて、各種データを格納しているデータ記憶部１０６が記憶される。これらソフトウェア部品及び各種データは、ＣＰＵの制御に従い、メモリ上に読み出されて各種制御が実行される。

アプリケーションプログラム１０１は、常駐モジュール１０２やデバイスドライバ１０３に対してデータ入出力要求を指示することでデバイス３００を制御するためのソフトウェアプログラムである。

常駐モジュール１０２は、（１）デバイスサーバ２００にローカル接続されるデバイス３００を個体別に識別するためのデバイス個体情報を取得する機能、（２）デバイス個体情報によってデバイスの機種等を個体ごとに識別する機能、（３）デバイス３００との間のデータ送受信に必要となるデバイスドライバ１０３及び仮想化制御部１０４を一意に特定し、順次、それらのソフトウェア部品を動的に生成・起動する機能、（４）通信制御部１０５を介してデバイスサーバ２００とのセッションの開始・切断を指示する機能、（５）デバイスサーバ２００とのセッションが開始されると、デバイスドライバ１０３及び仮想化制御部１０４を用いて、デバイス３００との間のデータ送受信を制御する機能を備えている。

デバイスドライバ１０３は、ＯＳ（不図示）やアプリケーションプログラム１０１（以下、「上位層のソフトウェアプログラム」という）からのデータ入出力要求を、デバイス３００に応じたデータ形式のデータ（以下、「制御コマンド」という）に変換し、この制御コマンドを仮想化制御部１０４に送り、この制御コマンドに対する応答を上位層のソフトウェアプログラムへ通知するソフトウェア部品である。

仮想化制御部１０４は、デバイスドライバ１０３で制御コマンドに変換されたデータ入出力要求をＵＳＢデータ形式に準拠したパケットデータ（以下、「ＵＳＢデータ」という）に変換し、通信制御部１０５から送られてくるＵＳＢデータを制御コマンドと同様のデータ形式に変換してデバイスドライバ１０３へ送るソフトウェア部品である。また、デバイス３００に対するデータ送受信要求に対して、デバイス３００がクライアントＰＣ１００に直接的に接続（ローカル接続）しているときと同様の振る舞いをシミュレートする機能（以下、「仮想化制御」という）を備えたソフトウェア部品である。この「仮想化制御」によって、デバイス３００をローカル接続したときと同じ状態でデータ送受信することができるようになる。

通信制御部１０５は、仮想化制御部１０４を経由して送られてくる「ＵＳＢデータ」とネットワーク５００を介してデバイスサーバ２００と通信するときの「ネットワークパケット」との変換処理を行い、デバイスサーバ２００との間のデータ送受信を制御するソフトウェア部品である。また、仮想化制御部１０４を経由して送られてくる上位層のソフトウェアプログラムやデバイスドライバ１０３からのデータ送受信要求に応じて、デバイスサーバ２００との間のセッションの開始・切断の制御を行う。

また、データ記憶部１０６は、後述する図３の定義ファイル１０７、トリガ検知アルゴリズム１０８等の各種データが格納される。

定義ファイル１０７は、デバイスサーバ２００がデバイス３００を監視する際、トリガ検知アルゴリズム１０８に必要な命令・情報等を格納しているデータファイルである。

トリガ検知アルゴリズム１０８は、デバイスサーバ２００において、デバイス３００を監視し、その状態変化を検知するための実行手順が記述されたプログラムコードであり、定義ファイル１０７を読み込むことで、本実行手順に従って、デバイス３００の監視処理（以下、「トリガ検知処理」という）が行われる。このトリガ検知処理は図４を用いて後述する。

定義ファイル１０７とトリガ検知アルゴリズム１０８は、デバイス３００の監視を行うための１組の「監視情報」（監視プログラム）であり、デバイス３００の機種ごとに異なる。

図３は、図１におけるデータ記憶部１０６に格納される定義ファイルのデータ構成を説明するのに用いられる図である。

図３の定義ファイルは、デバイス３００の機能（仕様）に基づいて作成され、ベンダーＩＤ（ＶＩＤ）、製品ＩＤ（ＰＩＤ）などのデバイス識別情報と、デバイス３００に対して発行する要求パケットのデータパターンと、デバイス３００の状態変化時の応答パケットのデータパターンを含む。応答パケットのデータパターンには、デバイス３００の状態変化時にデバイス３００から返送されてくる応答パケットのみが含まれている。

＜デバイスサーバ２００の構成＞
デバイスサーバ２００は、内部バスで互いに接続されたＣＰＵ、メモリ、通信部、ＵＳＢインターフェース、及び外部記憶部で構成されており、ネットワーク５００を介してクライアントＰＣ１００と通信すると共に、ローカル接続されているデバイス３００と接続ケーブル４００を介してデータ送受信することができる。

外部記憶部は、ＯＳ（不図示）、通信制御部２０１、デバイス制御部２０２等のソフトウェア部品を格納する。これらのソフトウェア部品、及びデータ記憶部２０３に格納された各種データは、ＣＰＵの制御に従い、メモリ上に読み出されて各種制御が実行される。

通信制御部２０１は、ＯＳの制御に従ってネットワーク５００経由で接続されているクライアントＰＣ１００との間のセッションを制御（開始、切断）する機能を有する。

デバイス制御部２０２は、デバイス３００を制御するための機能を有する。また、デバイス制御部２０２は、通信制御部２０１を介してデバイス個体情報２０４、定義ファイル２０５、トリガ検知アルゴリズム２０６を取得し、取得したこれらの情報（データ）に基づいて、以下で説明する処理を実行するための機能を備えている。

（１）クライアントＰＣ１００と通信するための「ネットワークパケット」とデバイス３００との間で送受信する「ＵＳＢデータ」との変換処理を行い、デバイス制御部２０２と連携してクライアントＰＣ１００とデバイス３００間のデータ送受信を仲介（中継）する機能、（２）「デバイス」から取得したデバイス個体情報２０４をクライアントＰＣ１００に送信する機能、（３）クライアントＰＣ１００から定義ファイル１０７／トリガ検知アルゴリズム１０８を受信（取得）する機能、（４）定義ファイル２０５及びトリガ検知アルゴリズム２０６（後述）を用いてデバイス３００を一定間隔で監視（ポーリング）する「トリガ検知処理」を実行し、状態変化を検知すると、当該検知を示す情報（以下、トリガ通知）をクライアントＰＣ１００へ送信する機能、（５）通信制御部２０１でクライアントＰＣ１００との間のセッションが切断されるとこれを検知して、（４）の「トリガ検知処理」を再開させる機能を備えている。

デバイス個体情報２０４は、「デバイス」を個体ごとに識別するための情報であって、メーカーを識別するために機器を製造したメーカーごとに割り当てられたベンダーＩＤ（ＶＩＤ）、機種を識別するために機種ごとに割り当てられた製品ＩＤ（ＰＩＤ）、機器の個体を識別するために個々の機器に割り当てられたシリアル番号等である。デバイス個体情報２０４は、デバイス３００が接続されたとき等に、デバイス制御部２０２によってデバイス３００から取得される。

定義ファイル２０５とトリガ検知アルゴリズム２０６は、デバイスサーバ２００自身に接続されたデバイス３００の監視（ポーリング）に必要な情報であり、デバイスサーバ２００は、デバイス個体情報２０４に基づいてクライアントＰＣ１００から取得する。

＜デバイス３００の構成＞
デバイス３００（３００Ａ、３００Ｂ）は、ＵＳＢインターフェースを持つ汎用的な入出力機器（デバイス）である。例えば、キーボード、マウス、カードリーダのような入力機器、ディスプレイ等の表示（出力）機器、プリンタ等の単機能周辺機器（ＳＦＰ：Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、又は、プリント機能の他にスキャン機能やコピー機能、ストレージ機能等を兼ね備えた多機能周辺機器（ＭＦＰ：Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である。ただし、これらに限定されるものでなく、別のデバイスであってもよい。

例えば、デバイス３００がＩＣカードリーダのような機器である場合、ＩＣカードがかざされ、ＩＣカードリーダがＩＣカードの読み取り処理を実行すると、デバイスサーバ２００は、この読み取り処理の動作をデバイス３００の状態変化として検知し、クライアントＰＣ１００にトリガ通知を送信する。

ここで、デバイス３００の状態変化とは、機器の動作状態の変化のことであり、例えば、ＩＣカードリーダに対してＩＣカードの読み取り操作（ユーザＩＤの取得）が行われたことや、操作ボタンが押下されたこと等によって生じるものであるが、これらに限定されるものではない。

なお、上述したデバイスサーバ２００、デバイス３００は、それぞれ別体の装置、機器として説明したが、これに限定されるものではなく、デバイスサーバ２００をデバイス３００と一体構造としてもよい。

＜予めデバイスに応じて作成された定義ファイルを用いる場合＞
図２は、図１のデバイス制御システムの動作シーケンスを説明するのに用いられるシーケンス図である。

図２のシーケンス図は、クライアントＰＣ１００と、デバイスサーバ２００に接続されたデバイス３００Ａとの間でデータ送受信する過程を示している。

図２において、デバイスサーバ２００は、デバイス３００Ａが接続されると、当該デバイス３００Ａのデバイス個体情報を取得し（ステップＳ２０１）、デバイス個体情報２０４としてデータ記憶部２０３に格納する（ステップＳ２０２）。

このとき、デバイスサーバ２００は、取得したデバイス個体情報２０４にシリアル番号が格納されているか否かを判断し、シリアル番号が格納されていない場合は、デバイスサーバ２００の有する固有情報（例えば、ＭＡＣアドレス等）及びデバイスが接続されているポートの固有情報（例えば、ポート番号等）からシリアル番号に相当する固有情報を生成し、デバイス個体情報２０４に追加する。これにより、シリアル番号が格納されていない同一機種が複数接続された場合でも識別可能となる。

次いで、クライアントＰＣ１００の常駐モジュール１０２は、デバイスサーバ２００にローカル接続されたデバイス３００Ａを確認するために、通信制御部１０５を介して、デバイスサーバ２００に対して検索パケットを送信する。例えば、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等のプロトコルを用いて、デバイスサーバ２００に対する検索（問い合わせ）を行う。デバイスサーバ２００は、検索パケットを受信すると、データ記憶部２０３に格納されているデバイス個体情報２０４をクライアントＰＣ１００に送信する（ステップＳ２０３）。

クライアントＰＣ１００の常駐モジュール１０２は、デバイスサーバ２００からデバイス個体情報２０４を取得すると、デバイス個体情報２０４に含まれているベンダーＩＤ（ＶＩＤ）と製品ＩＤ（ＰＩＤ）、シリアル番号等により「デバイス」の識別処理を行い、当該デバイス個体情報２０４に含まれている個体を識別するための情報に基づいて、デバイスドライバ１０３、仮想化制御部１０４を一意に特定し、順次、これらのソフトウェア部品を動的に生成して起動する。これらのソフトウェア部品によって、デバイス３００Ａの仮想化制御が可能な状態となる（ステップＳ２０４）。

次に、クライアントＰＣ１００は、データ記憶部１０６に格納している定義ファイル１０７、トリガ検知アルゴリズム１０８の中から、デバイス個体情報２０４に基づいて識別したデバイス３００Ａの機種に対応した定義ファイル１０７、トリガ検知アルゴリズム１０８を特定する。

そして、クライアントＰＣ１００は、特定した定義ファイル１０７、トリガ検知アルゴリズム１０８を含んだインストール用パケットを生成し、通信制御部１０５によってデバイスサーバ２００との間でセッションを開始して（ステップＳ２０５）、生成したインストール用パケットをデバイスサーバ２００に対して送信する（ステップＳ２０６）。

なお、応答がない（タイムアウト）、接続拒否等、何らかの理由でセッションを開始することができない場合、デバイスサーバ２００は、エラー処理（例えば、デバイス３００Ａに対してエラー通知する、自装置でアラーム報知する等）を実行し、本処理を終了させる。

デバイスサーバ２００は、インストール用パケットを受信すると、このパケットに含まれる定義ファイル１０７とトリガ検知アルゴリズム１０８をインストールし、それぞれ定義ファイル２０５（第１の定義ファイル）とトリガ検知アルゴリズム２０６としてデータ記憶部２０３に格納する（ステップＳ２０７）。

なお、クライアントＰＣ１００のアプリケーションプログラム１０１は、デバイス個体情報２０４による識別処理の結果、デバイス３００Ａ以外の「デバイス」であると識別した場合、ソフトウェア部品の生成処理は実行しない。

＜トリガ検知処理開始＞
デバイスサーバ２００のデバイス制御部２０２は、クライアントＰＣ１００とデバイスサーバ２００との間でセッションが切断されると（ステップＳ２０８）、データ記憶部２０３に格納した定義ファイル２０５とトリガ検知アルゴリズム２０６を用いて、デバイス３００Ａの後述する図４のトリガ検知処理（監視処理）を開始する（ステップＳ２０９）。このトリガ検知処理の開始条件は、トリガ通知後、所定時間内にクライアントＰＣ１００からセッション開始がない場合も含む。

＜デバイス制御開始〜終了＞
図４は、図１におけるデバイスサーバによって実行されるトリガ検知処理の手順を示すフローチャートである。

図４のトリガ検知処理（図２のステップＳ２０９〜Ｓ２１４）により、デバイス３００Ａの状態変化が監視される。また、図４のトリガ検知処理は、この処理の実行中にクライアントＰＣ１００からの割り込み処理が発生した場合は中断され、当該割り込み処理の終了により、再開される。

図４において、まず、デバイスサーバ２００とクライアントＰＣ１００とのセッションが切断されるか、トリガ通知後、所定時間内にクライアントＰＣ１００からセッション開始がないことにより、監視（ポーリング）が開始すると（ステップＳ４０１でＹＥＳ）、定義ファイル２０５（図３）に含まれている要求データパターン（要求情報）に従い、要求パケットを通信制御部２０１を介してデバイス制御部２０２からデバイス３００Ａに対して送信する（ステップＳ４０２）。上記監視（ポーリング）の間隔は、定義ファイル２０５（図３）で設定することができる。この間隔は、デバイスサーバ２００がトリガ検知処理で専有されることを回避し、他の機能（デバイス）を使用できるようにするためのものである。

次いで、デバイス３００Ａからの応答パケットを受信したか否かを判別し（ステップＳ４０３）、応答パケットを受信したときは、応答パケットとしてエラー情報が返送されて来た（例えば、デバイス３００Ａと接続断となった場合等）か否かを判別する（ステップＳ４０５）。

ステップＳ４０５の判別の結果、エラー情報が返送されて来たときは、直ちに本処理を終了し、応答パケットがエラーでなければ（ステップＳ４０５でＮＯ）、デバイス制御部２０２は、デバイス３００Ａからの応答パケットと定義ファイル２０５に含まれている応答パケットの各データパターン（応答情報）を比較する（ステップＳ４０６（図２のステップＳ２１０））（第１の検知手段、第１の判別手段）。

ステップＳ４０６の比較の結果、デバイス３００Ａからの応答パケットと定義ファイル２０５に含まれている応答パケットの各データパターンが一致したときは、デバイス３００Ａで状態変化があり（図２のステップＳ２１１）（第１の検知手段）、この状態変化を示すトリガ通知を送信すべきと判断して（ステップＳ４０７でＹＥＳ）、通信制御部２０１を介してクライアントＰＣ１００にトリガ通知を送信して（ステップＳ４０９（図２のステップＳ２１３））（送信手段）、本処理を終了する（図２のステップＳ２１４）。

一方、ステップＳ４０６の比較の結果、デバイス３００Ａからの応答パケットと定義ファイル２０５に含まれている応答パケットの各データパターンが一致していない（不一致）ときは、デバイス３００Ａで状態変化がなく、トリガ通知すべきでないとして（ステップＳ４０７でＮＯ）、監視（ポーリング）が終了するまで（ステップＳ４０８でＹＥＳ）、ステップＳ４０２以降の処理の処理を実行して、次の要求パケットをデバイス３００Ａに送信する。

ステップＳ４０３の判別の結果、要求パケットを送信した後、所定時間内にデバイスからの応答パケットが受信されなかった（タイムアウト）ときは（ステップＳ４０４でＹＥＳ）、監視（ポーリング）が終了するまで（ステップＳ４０８でＹＥＳ）、ステップＳ４０２以降の処理を実行して、次の要求パケットを送るようにする。

図２に戻り、クライアントＰＣ１００は、デバイスサーバ２００からトリガ通知を受信すると、デバイスサーバ２００との間でセッションを開始し（ステップＳ２１５）、デバイスサーバ２００を介してデバイス３００Ａとの間でデータ送受信（データ通信の中継）を開始して（ステップＳ２１６）、データ送受信を実行する（ステップＳ２１７）（データ通信制御手段）。ステップＳ２１３において、デバイスサーバ２００は、クライアントＰＣ１００にトリガ通知を送信すると共にセッション開始を要求してもよい。

＜トリガ検知処理再開＞
そして、クライアントＰＣ１００の通信制御部１０５によって、データ送受信（デバイス制御）の終了が検知される（例えば、ユーザの終了操作の検知等）（ステップＳ２１８）と、デバイスサーバ２００とのセッションが切断される（ステップＳ２１９）。デバイスサーバ２００は、当該セッションの切断が検知される（第２の検知手段）と、トリガ検知処理を開始（ステップＳ２２０）し、デバイス３００Ａの監視（ポーリング）を再開する（再開手段）。ステップＳ２１３において、トリガ通知後、所定時間内にクライアントＰＣ１００からセッション開始がない場合も、同様にトリガ検知処理を開始し（ステップＳ２２０）、デバイス３００Ａの監視（ポーリング）を再開する。

このように、本第１の実施の形態によれば、デバイス３００Ａに対する制御権（通信）が、トリガ通知によってデバイスサーバ２００からクライアントＰＣ１００へ切り替わり、セッション切断を契機にクライアントＰＣ１００からデバイスサーバ２００に再び切り替わることで、クライアントＰＣ１００とデバイス３００Ａは必要なときだけデータ通信を実施することが可能となり、データ通信が終了すると、デバイスサーバ２００によるデバイス３００Ａの監視が再開される。

＜クライアントＰＣが蓄積した要求／応答パケットを定義ファイルとする場合＞
図５は、本発明の第２の実施の形態に係るデバイス制御システムの動作シーケンスを説明するのに用いられるシーケンス図であり、クライアントＰＣ１００と、デバイスサーバ２００に接続されたデバイス３００Ｂとの間でデータ送受信する過程を示している。

本発明の第２の実施の形態に係るデバイス制御システムは、システム構成は図１のものと同じであるが、先に説明した本発明の第１の実施の形態とは異なり、クライアントＰＣ１００が、接続を検知したデバイス３００Ｂに対してポーリングを行い、その際の要求／応答パケットを蓄積しておき、これらを定義ファイルとしてデバイスサーバ２００に送信する点に特徴がある。

具体的には、クライアントＰＣ１００の仮想化制御部１０４が、アプリケーションプログラム１０１からの指示に従い、デバイス３００Ｂにおいて状態変化していない時の応答、例えば、デバイス３００Ｂが処理や制御を実行していない「実行待機状態」の応答を確認するため、通信制御部１０５を介してポーリングを行い、この際に送受信される要求／応答パケットをデータ記憶部１０６に記憶させる機能を備えることで実現される。

また、図５の動作シーケンスでは、図４のトリガ検知処理において、デバイス３００Ｂからの応答パケットと定義ファイルに含まれている応答パケットの各データパターンを比較し、この比較の結果、デバイス３００Ｂからの応答パケットと定義ファイルに含まれている応答パケットの各データパターンが一致していない（不一致）とき、クライアントＰＣ１００にトリガ通知を行う点が本発明の第１の実施の形態とは異なっている。

＜シーケンス動作の説明＞
図５において、クライアントＰＣ１００は主要な構成のみを図示しており、クライアントＰＣ１００がデバイスサーバ２００とセッション開始までの動作シーケンス（ステップＳ５０１〜Ｓ５０５）は、図２のステップＳ２０１〜Ｓ２０５と同じ動作である。

次いで、クライアントＰＣ１００は、アプリケーションプログラム１０１によって、新たに接続が検知されたデバイス３００Ｂに対するポーリングの開始が指示されると（ステップＳ５１１）、デバイスドライバ１０３を介して、ポーリングで送受信される後述する図６のパケットの蓄積開始（ステップＳ５１２）及びデバイス３００Ｂの動作状態を確認するための要求パケットの送信（ステップＳ５１３）を仮想化制御部１０４に指示する。

仮想化制御部１０４は、デバイス３００Ｂの動作状態（ここでは、「実行待機状態」）を確認するための要求パケットを、通信制御部１０５を介して順次送信させる（ステップＳ５１４）と共に、当該要求パケットをデータ記憶部１０６に蓄積させる（ステップＳ５１５）ように指示する。また、通信制御部１０５で受信した応答パケットをデータ記憶部１０６に蓄積させる（ステップＳ５１６）ように指示する。そして、一連のポーリングが終了するまでこれが繰り返される（ステップＳ５１７〜Ｓ５１９）（作成手段）。なお、これらパケットの送受信プロセス（順序等）の記録を指示するようにしてもよい。

＜パケットのデータ構成について＞
図６は、図５の動作シーケンスで送受信される要求／応答パケットのデータ構成を説明するのに用いられる図である。

図６において、ヘッダ部には、本システムのプロトコルであることを識別するための「署名データ」、当該パケットのデータサイズを示す「電文サイズ」、パケットの種類を示す「コマンドＩＤ」、デバイスを識別するための「機器情報」（「ベンダーＩＤ」、「製品ＩＤ」、「シリアル番号」）が格納される。データ部には、パケットの種類（「コマンドＩＤ」）に応じたデータが格納される。「コマンドＩＤ」の違いによって、要求パケットか応答パケットかを判別している。

図５に戻り、アプリケーションプログラム１０１から仮想化制御部１０４にポーリングの終了（ステップＳ５２０）が通知されると、デバイスドライバ１０３を介して、図６のパケット蓄積終了を仮想化制御部１０４に指示する。仮想化制御部１０４は、データ記憶部１０６に蓄積した要求パケット及び応答パケットを後述する図７の定義ファイル（第２の定義ファイル）としてデバイスサーバ２００に送信する（ステップＳ５２１）（送信手段）。

＜蓄積した要求／応答パケットで作成した定義ファイル＞
図７は、図５の動作シーケンスで送信される要求／応答パケットのデータ構造、及びこれらを蓄積して作成される定義ファイルを説明するのに用いられる図である。

なお、要求パケット、応答パケットは、図６で説明した要求／応答パケットのデータ構成と同じであり、「コマンドＩＤ」の違いによって、要求パケットか応答パケットが判別され、データ部（ＵＳＢ転送データ）に要求または応答に応じたデータが格納されている。

例えば、ポーリングでｎ個の要求パケットを用いる場合、データ記憶部１０６には、ｎ個の要求パケット、ｎ個の応答パケットが蓄積され、これらが定義ファイルとしてデバイスサーバ２００に送信される。

＜トリガ検知処理開始〜終了＞
図５に戻り、デバイスサーバ２００は、通信制御部２０１を介してクライアントＰＣ１００から定義ファイル（図７参照）を受信すると、これを定義ファイル２０５としてデータ記憶部１０６に格納する（ステップＳ５２２）。

定義ファイルの送信が完了すると、クライアントＰＣ１００とデバイスサーバ２００の間のセッションは切断され（ステップＳ５２３）、図４のトリガ検知処理が実行される（ステップＳ５２４〜Ｓ５３０）。

デバイスサーバ２００のデバイス制御部２０２は、この定義ファイル２０５を用いて、クライアントＰＣ１００と同様のポーリングを開始する。即ち、デバイス３００Ｂに対する図４のトリガ検知処理を開始する。

図４は、図１におけるデバイスサーバ２００によって実行されるトリガ検知処理の手順を示すフローチャートである。図４の処理は、先に本発明の第１の実施の形態として説明したもの基本的に同じであるが、下記の点が異なる。

具体的には、定義ファイル２０５に含まれている要求データパターンに従い、要求パケットを順次通信制御部２０１を介してデバイス制御部２０２からデバイス３００Ｂに対して送信し（ステップＳ５２５（図４のステップＳ４０２））、デバイス３００Ｂからの応答パケットを受信する（ステップＳ５２６（図４のステップＳ４０３））。

デバイス制御部２０２は、デバイス３００Ｂからの応答パケットと定義ファイル２０５に含まれている応答パケットの各データパターンを比較し（図４のステップＳ４０６）、それらが一致するか否かの判定処理を行う（第１の検知手段、第２の判別手段）。

デバイス３００Ｂからの応答パケットと定義ファイル２０５に含まれている応答パケットの各データパターンが一致するか否かの判定処理は、例えば、しきい値を設定しておき、パケットの先頭からのバイト数を比較し、所定のバイト数以上（例えば、３バイト以上）異なっている場合を一致していないと判断する方法や、ｎ個すべての応答パケットと比較して、何れの応答パケットとも異なるバイト数であった場合、一致していないと判断する等の方法で行う。

上記判定処理の結果、「一致」判定の場合は、状態変化がないと判断し、次の要求パケットをデバイス３００Ｂに送信する。「一致」と判定されている間は、定義ファイル２０５に含まれている要求パケットを順次送信してゆく。

なお、要求パケットを送信した後、所定時間内にデバイスからの応答パケットが受信されなかった（タイムアウト）場合は、次の要求パケットを送るようにしてもよい。

また、要求パケットに対して、デバイス３００Ｂからエラー情報が返送されてきた場合（例えば、デバイス３００Ｂと接続断となった場合等）、トリガ検知処理を終了する。トリガ検知処理が終了した後は、データ記憶部から定義ファイル２０５を削除するようにしてもよいし、データ記憶部２０３に保存しておき、デバイス３００Ｂが改めて接続されたとき（ＰＩＤ、ＶＩＤの一致により判断する）に利用できるようにしておいてもよい。

一方、「不一致」判定の場合、デバイス３００Ｂで状態変化があり、この状態変化（ステップＳ５２７）を検知したものと判断し、この検知を示すトリガ通知（ステップＳ５２８）を、通信制御部２０１を介してクライアントＰＣ１００に送信すると共にこのトリガ通知をクライアントＰＣ１００が受信する（ステップＳ５２９）（送信手段、受信手段）。

＜デバイス制御開始〜終了＞
クライアントＰＣ１００は、デバイスサーバ２００からトリガ通知を受信すると、これを契機にデバイスサーバ２００との間でセッションを開始する（ステップＳ５３１）（セッション制御手段）。これ以降の動作シーケンス（ステップＳ５３２〜Ｓ５３６）は、図２の動作シーケンス（ステップＳ２１６〜Ｓ２２０）と同じであるので、説明を省略する。

このように、クライアントＰＣ１００からトリガ通知を送信しない状態のデバイス３００Ｂに対してポーリングを行い、この際に送受信される要求／応答パケットを蓄積して、これを定義ファイルとしてデバイスサーバ２００に送信することにより、デバイスの状態変化の監視（トリガ検知処理）を行うことができるようになる。

＜定義ファイル有無の判断＞
本発明の第２の実施の形態において、さらに、クライアントＰＣ１００がデータ記憶部１０６に該当するデバイス３００に適った定義ファイルを保持（記憶）しているか否かを判断する機能を備えるようにしてもよい。この場合、デバイス３００の機能（仕様）に応じて予め作成した定義ファイル（図３：本発明の第１の実施の形態）、若しくは、該当デバイス３００と同機種のデバイスとポーリングして作成した定義ファイル（図７参照）を既に保持しているときは、上述したようなポーリングによる定義ファイルの作成を実行せず、保持している定義ファイルをデバイスサーバ２００に送信し、保持していないときのみ、ポーリングによる定義ファイルの作成を実行する。

なお、本発明は、上述した実施の形態に限定されるものではなく、以下に説明する実施の形態も可能であり、本発明の要旨を逸脱しない範囲内において適宜変更可能である。

＜シーケンス開始のタイミング＞
図２及び図５の動作シーケンスでは、デバイスサーバ２００にデバイス３００が接続されたときにデバイス個体情報を取得してシーケンスを開始するものとして記載しているが、デバイスサーバ２００は、これ以外にも、例えば、デバイスサーバ２００やデバイス３００の電源がオンになったとき、クライアントＰＣ１００のアプリケーションプログラムから指示されたとき、デバイスサーバ２００とデバイス３００の一方又は両方で所定の接続操作を実行したときにデバイス個体情報を取得し、このデバイス個体情報に基づいて図２又は図５と動作シーケンスを実行するようにしてもよい。

＜定義ファイルの実行プログラム＞
また、クライアントＰＣ１００は、定義ファイルとともにトリガ検知アルゴリズムの一部として動作する簡易プログラム（例えば、シェル、スクリプトなど）をデバイスサーバ２００に送り、デバイスサーバ２００は、この定義ファイルと簡易プログラムを用いてトリガ検知処理を実行するように構成してもよい。

この場合、トリガ検知アルゴリズムは、定義ファイルに基づいて、デバイス３００とのポーリングの実行、クライアントＰＣ１００へのトリガ通知などトリガ検知処理の基本的な処理を実行するとともに、デバイスの機種に応じた固有（特有）の処理など一部の処理を簡易プログラムで実行させるように構成される。例えば、状態変化として判断（検知）する条件は、デバイスの機種ごとに異なっているので、この判断を簡易プログラムで実行させることができる。

このように構成することで、トリガ検知アルゴリズムは、デバイスの機種に依存しないトリガ検知処理の基本的な実行手順だけを記述しておけばよく、デバイスの機種に応じた処理を実行する簡易プログラムを作成するだけで、多種多様なデバイスに対応することができる。

＜定義ファイル／アルゴリズムの別の取得（インストール）方法＞
デバイスサーバ２００は、定義ファイルとトリガ検知アルゴリズムをクライアントＰＣ１００からではなく、可搬型記憶媒体から取得するようにしてもよい。

＜デバイスサーバが定義ファイル／アルゴリズムをすでに保持している場合＞
また、デバイスサーバ２００は、以前に同一機種のデバイス３００が接続されたときに、該当する定義ファイルとトリガ検知アルゴリズムを取得、格納（インストール）している場合は、改めて取得・格納を行わなくてもよい。さらに、クライアントＰＣ１００に対して、定義ファイルとトリガ検知アルゴリズムの送信が不要である旨を通知してもよい。

＜トリガ通知先が複数の場合＞
また、複数台のクライアントＰＣ１００を配置するシステム構成も可能である。この場合、デバイスサーバ２００は、複数のクライアントＰＣ１００に対してトリガ通知を送信し、最初にセッションの接続開始要求を送信してきたクライアントＰＣ１００に対して、デバイス３００との接続（データ送受信）を許可すればよい。或いは、接続開始要求を送信した複数のクライアントＰＣ１００のうち、任意の台数のみ、デバイス３００との接続を許可するように制御してもよい。また、特定の１台のクライアントＰＣ１００が、電源オフや故障等でトリガ通知の受信が不可能な場合には、別のクライアントＰＣ１００を代替の宛先としてトリガ通知を送信するように制御してもよい。

＜定義ファイルとトリガ検知アルゴリズムについて＞
図１のクライアントＰＣ１００には、デバイス３００に対応した定義ファイル１０７とトリガ検知アルゴリズム１０８が両方ともに格納されており、デバイスサーバ２００がクライアントＰＣ１００から定義ファイル１０７とトリガ検知アルゴリズム１０８を受信する方法（構成）を説明したが、下記のような方法（構成）も可能である。

（１）デバイスサーバ２００に予め必要なトリガ検知アルゴリズム１０８を格納させておき、クライアントＰＣ１００には、定義ファイル１０７のみを格納させる。この場合、デバイスサーバ２００は、クライアントＰＣ１００から、機器情報によって特定されるデバイス３００の機種に対応した定義ファイル１０７のみを受信することになる。

例えば、ソフトウェア・ハードウェアの仕様・設計に依拠する場合やシステムの運用・管理上の理由等から、デバイスサーバ２００へのアクセスが制限されており、トリガ検知アルゴリズム（プログラムコード）を受信して実行（又はインストール）できない場合に適用できる構成である。本構成は、トリガ検知アルゴリズム（プログラムコード）がデバイスサーバに予め格納されているため、改竄が困難であるというメリットがある。

（２）デバイスサーバ２００は、特定したデバイス３００の機種に対応するトリガ検知アルゴリズムや定義ファイルを保持していない場合にのみ、クライアントＰＣ１００等から必要なトリガ検知アルゴリズムや定義ファイルを取得するようにしてもよい。

さらに、デバイスサーバ２００又はクライアントＰＣ１００でトリガ検知アルゴリズムや定義ファイルを管理して、これらの追加・更新等が必要か否かを判断させるようにしてもよい。このような構成とすることで、デバイスサーバ２００は、追加・更新等の必要性が生じたときだけ、トリガ検知アルゴリズムや定義ファイルの全部又は一部を取得できるようになる。

また、上述した実施の形態のように、デバイスサーバ２００がクライアントＰＣ１００からトリガ検知アルゴリズムや定義ファイルを受信するのではなく、デバイスサーバ２００がクライアントＰＣ１００にアクセスしてダウンロード（取得）するように構成してもよい。この場合、クライアントＰＣ１００は、該当するトリガ検知アルゴリズムや定義ファイルを保持していることだけをデバイスサーバ２００に通知すればよい。

上述したトリガ検知アルゴリズム１つに対して複数の定義ファイルを対応付けることで、複数のデバイス３００を連携させて制御することも可能である。例えば、デバイスＡとデバイスＢを連携させて制御する場合、両方のデバイスからのトリガ通知を受信した後、デバイスＡの動作を開始させる、というような制御を行うことができる。

なお、本発明は、デバイスサーバ２００に対して機種の異なる複数のデバイス３００が接続される場合にも適用可能である。この場合、デバイスサーバ２００には、各デバイスに応じた定義ファイルとトリガ検知アルゴリズムが機種ごとに格納される（複数組が格納される）。そして、各デバイスに適ったトリガ検知アルゴリズムと定義ファイルの組み合わせに基づきトリガ検知処理が実行され、それぞれのデバイス３００ごとの状態変化を検知することができる。

また、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して処理を実行することによっても達成することができる。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータで読み取り可能な記憶媒体は本発明を構成することになる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現されるように構成してもよい。

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

なお、プログラムコードを供給するため、例えば、フロッピー（登録商標)ディスク、ハードディスク、光磁気ディスク、ＣＤやＤＶＤに代表される光ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭ等の記憶媒体を用いることができる。又は、プログラムコードは、ネットワークを介してダウンロードしてもよい。

１０１ クライアントＰＣ
１０２ 常駐モジュール
１０３ デバイスドライバ
１０４ 仮想化制御部
１０５ 通信制御部
１０６ データ記憶部
１０７ 定義ファイル
１０８ トリガ検知アルゴリズム
２００ デバイスサーバ
２０１ 通信制御部
２０２ デバイス制御部
２０３ データ記憶部
２０４ デバイス個体情報
２０５ 定義ファイル
２０６ トリガ検知アルゴリズム
２０７ 定義ファイル
３００（３００Ａ，３００Ｂ） デバイス
４００ 接続ケーブル
５００ ネットワーク

Claims (13)

1. ネットワークを介してクライアント装置に接続されていると共にデバイスがローカル接続されるべきデバイス制御装置であって、
   前記デバイスの状態を監視するための定義ファイル及びトリガ検知アルゴリズムを用いて当該デバイスの状態を監視し、当該デバイスの状態変化を検知する第１の検知手段と、
   前記デバイスの状態変化が検知されたときに、当該状態変化の検知を示すトリガ通知を前記クライアント装置に送信する送信手段と、
   前記トリガ通知を受信したクライアント装置とセッションを開始して、前記状態変化を検知したデバイスとのデータ通信を中継するデータ通信制御手段と、
   前記デバイスとのデータ通信が終了して当該クライアント装置とのセッションが切断されたことを検知する第２の検知手段と、
   前記クライアント装置とのセッションが切断されたとき、前記第１の検知手段に前記デバイスの状態の監視を再開させる再開手段とを備えること
   を特徴とするデバイス制御装置。
2. 前記定義ファイルは、前記デバイスの状態変化時における前記デバイスの応答情報を含む第１の定義ファイルからなり、
   前記第１の検知手段は、前記デバイスの応答情報と前記第１の定義ファイルに含まれている応答情報が一致したか否かを判別する第１の判別手段を備え、
   前記送信手段は、前記デバイスの応答情報と前記第１の定義ファイルに含まれている応答情報が一致したときに、前記トリガ通知を前記クライアント装置に送信すること
   を特徴とする請求項１記載のデバイス制御装置。
3. 前記定義ファイルは、前記デバイスにおいて状態変化していない時の当該デバイスの応答情報を含む第２の定義ファイルからなり、
   前記第１の検知手段は、前記デバイスの応答情報と前記第２の定義ファイルに含まれている応答情報が一致したか否かを判別する第２の判別手段を備え、
   前記送信手段は、前記デバイスの応答情報と前記第２の定義ファイルに含まれている応答情報が一致しないときに、前記トリガ通知を前記クライアント装置に送信すること
   を特徴とする請求項１記載のデバイス制御装置。
4. 前記再開手段は、前記クライアント装置から応答がないとき、前記第１の検知手段に前記デバイスの状態の監視を再開させること
   を特徴とする請求項１乃至３のいずれか１項に記載のデバイス制御装置。
5. 前記第１の検知手段が前記デバイスの状態を監視している間に前記クライアント装置から前記デバイス制御装置とのセッションの要求があるとき、前記第１の検知手段は、前記デバイスの状態の監視を終了し、前記セッションが切断されると、前記再開手段は、前記デバイスの状態の監視を再開させること
   を特徴とする請求項１乃至４のいずれか１項に記載のデバイス制御装置。
6. ネットワークを介してクライアント装置に接続されていると共にデバイスがローカル接続されるべきデバイス制御装置によって実行されるデバイス制御方法であって、
   前記デバイスの状態を監視するための定義ファイル及びトリガ検知アルゴリズムを用いて前記デバイスの状態を監視し、当該デバイスの状態変化を検知する第１の検知ステップと、
   前記デバイスの状態変化が検知されたときに、当該状態変化の検知を示すトリガ通知を前記クライアント装置に送信する送信ステップと、
   前記トリガ通知を受信したクライアント装置とセッションを開始して、前記状態変化を検知したデバイスとのデータ通信を中継するデータ通信制御ステップと、
   前記デバイスとのデータ通信が終了して当該クライアント装置とのセッションが切断されたことを検知する第２の検知ステップと、
   前記クライアント装置とのセッションが切断されたとき、前記第１の検知手段に前記デバイスの状態の監視を再開させる再開ステップとを備えること
   を特徴とするデバイス制御方法。
7. 前記定義ファイルは、前記デバイスの状態変化時における前記デバイスの応答情報を含む第１の定義ファイルからなり、
   前記第１の検知ステップは、前記デバイスの応答情報と前記第１の定義ファイルに含まれている応答情報が一致したか否かを判別する第１の判別ステップを備え、
   前記送信ステップは、前記デバイスの応答情報と前記第１の定義ファイルに含まれている応答情報が一致したときに、前記トリガ通知を前記クライアント装置に送信すること
   を特徴とする請求項６記載のデバイス制御方法。
8. 前記定義ファイルは、前記デバイスにおいて状態変化していない時の当該デバイスの応答情報を含む第２の定義ファイルからなり、
   前記第１の検知ステップは、前記デバイスの応答情報と前記第２の定義ファイルに含まれている応答情報が一致したか否かを判別する第２の判別ステップを備え、
   前記送信ステップは、前記デバイスの応答情報と前記第２の定義ファイルに含まれている応答情報が一致しないときに、前記トリガ通知を前記クライアント装置に送信すること
   を特徴とする請求項６記載のデバイス制御方法。
9. 前記再開ステップは、前記クライアント装置から応答がないとき、前記第１の検知ステップに前記デバイスの状態の監視を再開させること
   を特徴とする請求項６乃至８のいずれか１項に記載のデバイス制御方法。
10. 前記第１の検知ステップが前記デバイスの状態を監視している間に前記クライアント装置から前記デバイス制御装置とのセッションの要求があるときは、前記第１の検知ステップは、前記デバイスの状態の監視を終了し、前記セッションが切断されると、前記再開ステップは、前記デバイスの状態の監視を再開させること
    を特徴とする請求項６乃至９のいずれか１項に記載のデバイス制御方法。
11. デバイスがローカル接続されるべきデバイス制御装置にネットワークを介して接続されているクライアント装置であって、
    当該デバイス制御装置にローカル接続されたデバイスの動作状態を確認するためのポーリングを行う際に蓄積された前記デバイスに対する要求情報及び前記デバイスからの応答情報を含む定義ファイルを作成する作成手段と、
    前記作成された定義ファイルを前記デバイス制御装置に送信する送信手段と、
    前記デバイスの状態変化を検知した前記デバイス制御装置から前記デバイスの状態変化の検知を示すトリガ通知を受信する受信手段と、
    前記受信手段によって受信された前記トリガ通知に応じて前記デバイス制御装置とのセッションを開始するセッション制御手段とを備えること
    を特徴とするクライアント装置。
12. 前記デバイスに適った定義ファイルを自装置で保持しているか否かを判断する判断手段をさらに備え、
    当該デバイスに適った定義ファイルを保持していると判断した場合、前記作成手段による定義ファイルの作成を行わず、前記送信手段によって当該保持している定義ファイルを送信すること
    を特徴とする請求項１１記載のクライアント装置。
13. 請求項１又は３に記載のデバイス制御装置と請求項１１又は１２に記載のクライアント装置とが互いにネットワークを介して接続されていることを特徴とするデバイス制御システム。

Images