JP5998343B2 - デバイスサーバシステム、デバイスサーバおよびプログラム - Google Patents

Description

本発明はデバイスサーバシステムに関し、クライアントとデバイスとの間で効率的に連続してデータ通信を行うデバイスサーバシステム、デバイスサーバおよびプログラムに関する。

ネットワークを通じて、コンピュータ周辺機器であるＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）デバイスを当該ネットワークに接続しているクライアントから利用することのできるシステム（ＵＳＢデバイスサーバシステム）が知られている（特許文献１、非特許文献１を参照）。

ＵＳＢデバイスサーバシステムでは、クライアントのデバイスドライバが発行したコマンド等のデータがネットワークパケット（トンネリングパケットと呼ぶ）に変換され、これがクライアントからＵＳＢデバイスサーバに向けて送信される。当該トンネリングパケットを受信したＵＳＢデバイスサーバは、受信したトンネリングパケットに含まれるコマンド等のデータを取り出し、ＵＳＢ通信に変換して自身に接続しているＵＳＢデバイスに転送する。

ＵＳＢデバイスサーバシステムにおける通信は、ＵＳＢ規格の通信に準じている。たとえばクライアントからＵＳＢデバイスへの送信の場合、クライアントからＵＳＢデバイスサーバを経由してＵＳＢデバイスにデータを送信するとともに、随時、ＵＳＢデバイスのステータスに関する応答をクライアントはデバイスサーバ経由で受信する。

他方、クライアントがＵＳＢデバイスからデータを受信したい場合は、所定の単位に区切られたデータの要求をＵＳＢデバイスサーバ経由でＵＳＢデバイスに送信し、当該要求を受信したＵＳＢデバイスからのデータをクライアントがＵＳＢデバイスサーバ経由で受信することによって行われる。

ところがこのような通信方式は、片方向のデータ、特に、クライアントとＵＳＢデバイスとの間で片方向の連続通信を行う場合には、処理効率が悪いという問題がある。つまり、送信・受信を目的としたデータ通信に付随して行われる応答やデータ要求にかかる通信が、ＵＳＢデバイスサーバシステムのパフォーマンスを落とす原因となっていたわけである。

特開２００８−２８７４５３号公報

サイレックス・テクノロジー株式会社ホームページ＜http://www.silex.jp/products/usbdeviceserver/sx3000gb.html＞

上記状況に鑑みて、本発明は、効率よく片方向の連続データ通信を行うデバイスサーバシステム、デバイスサーバおよびプログラムを提供することを目的とする。

上記目的を達成すべく、本発明のデバイスサーバシステムは、ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムであって、当該クライアントおよび当該デバイスサーバは以下の手段を備える。

１−１）クライアント
・所定のデバイスを制御する命令を発行するデバイス制御手段
・デバイス制御手段が発行した前記命令であって、所定単位のデータを前記所定のデバイスに対して送信するデータ送信手段
・データ送信手段によるデータ送信であって、複数の連続した当該データ送信が行われる旨の連続送信通知を前記デバイスサーバに対して送信する連続送信通知手段
１−２）デバイスサーバ
・連続送信通知を受信した場合、所定の場合についてのみ、前記連続送信通知にかかる応答をクライアントに対して送信する通知応答送信手段

所定のデバイスを制御する命令を発行するデバイス制御手段とは、例えば、所定のデバイスがプリンタ装置やスキャナー装置などのＵＳＢデバイスの場合、それらのデバイスのドライバプログラムが該当する。
また、デバイス制御手段が発行する命令は、ＵＳＢデバイスの場合、ＵＲＢ（USB Request Block）が該当する。
また、連続送信通知手段では、デバイス制御手段が発行する命令を解析して、例えば、ＵＳＢデバイスの場合にはＵＲＢ（USB Request Block）を解析して、連続する送信が行われる場合、複数の連続した当該データ送信が行われる旨の連続送信通知パケットデータを生成し、それをデバイスサーバに対して送信する。
デバイスサーバでは、連続送信通知を受信した場合、所定の場合についてのみ、連続送信通知にかかる応答をクライアントに対して送信する。
ここで、所定の場合とは、「デバイスからの応答データを検出した場合」または「デバイスのステータス変化を検出した場合」である。

また、本発明のデバイスサーバシステムは、ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムであって、当該クライアントおよび当該デバイスサーバは以下の手段を備える。
２−１）クライアント
・所定のデバイスを制御する命令を発行するデバイス制御手段
・デバイス制御手段が発行した前記命令であって、前記所定のデバイスに対し所定単位のデータを要求するデータ要求手段
・データ要求手段による要求であって、複数の連続した当該要求を単一のデータ要求（単一データ要求）として、前記デバイスサーバに対して送信する単一データ要求手段
２−２）デバイスサーバ
・単一データ要求を受信すると、当該単一データ要求に含まれる複数の所定単位のデータ要求を、前記デバイスに対して個別に送信し、当該デバイスからの所定単位のデータを受信して、受信した所定単位のデータを前記クライアントに対して送信するデータ転送手段

かかる構成によれば、クライアントがデバイスに対して、画像データなどのサイズの大きいデータを要求する場合、クライアントは、単一データ要求手段によって、デバイスサーバに対して、複数の連続した当該要求を単一データ要求として送信する。
デバイスサーバは、データ転送手段によって、クライアントから単一データ要求を受信すると、単一データ要求に含まれる複数の所定単位のデータ要求を、デバイスとの間のデータ通信プロトコルに従って、デバイスに対して個々に分けて個別に送信し、デバイスからの所定単位のデータを受信する。受信した所定単位のデータは、クライアントに対して受信の都度、送信する。

また、本発明のデバイスサーバは、ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムにおけるデバイスサーバであって、以下の手段を備える。

・クライアントが前記所定のデバイスに対して送信した、所定単位のデータを受信するデータ受信手段
・データ受信手段が受信した前記所定単位のデータが複数連続して受信（連続受信）するか否かを判断する連続受信判断手段
・連続受信判断手段が連続受信をすると判断した場合、所定の場合についてのみ、前記連続受信にかかる応答を前記クライアントに対して送信する応答送信手段

ここで、所定の場合とは、「デバイスからの応答データを検出した場合」または「デバイスのステータス変化を検出した場合」である。

また、本発明のプログラムは、ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムにおけるデバイスサーバを、以下の手段Ａ、手段Ｂ、手段Ｃとして機能させるためのプログラムである。

（手段Ａ）クライアントが前記所定のデバイスに対して送信した、所定単位のデータを受信するデータ受信手段
（手段Ｂ）データ受信手段が受信した所定単位のデータが複数連続して受信（連続受信）するか否かを判断する連続受信判断手段
（手段Ｃ）連続受信判断手段が連続受信をすると判断した場合、所定の場合についてのみ、連続受信にかかる応答をクライアントに対して送信する応答送信手段

ここで、所定の場合とは、「デバイスからの応答データを検出した場合」または「デバイスのステータス変化を検出した場合」である。

本発明は、デバイスサーバシステムにおいて、片方向の連続通信を行う場合、クライアントとデバイスサーバとの間の通信における無駄なネットワーク通信を間引くことで、当該ネットワーク通信に要するオーバーヘッドを軽減し、デバイスサーバシステムのパフォーマンスを向上させることができるといった効果を奏する。

ＵＳＢデバイスサーバシステムの全体構成の一例 従来のＵＳＢデバイスサーバシステムの機能ブロック図 従来のＵＳＢデバイスサーバシステムにおけるクライアント端末の機能ブロック図 従来のＵＳＢデバイスサーバシステムにおけるデータ通信フロー図（クライアント端末からＵＳＢデバイスへの送信の場合） 従来のＵＳＢデバイスサーバシステムにおけるデータ通信フロー図（ＵＳＢデバイスからクライアント端末への送信の場合） 本発明のデバイスサーバシステムにおけるクライアント端末の機能ブロック図 本発明のデバイスサーバシステムにおけるデバイスサーバの機能ブロック図 連続通信通知のパケット構造の一例 本発明のデバイスサーバシステムにおけるデータ通信フロー図（クライアント端末からデバイスへの送信の場合） 本発明のデバイスサーバシステムにおけるデータ通信フロー図（デバイスからクライアント端末への送信の場合）

以下、本発明の実施形態について、図面を参照しながら詳細に説明していく。なお、本発明の範囲は、以下の実施例や図示例に限定されるものではなく、幾多の変更及び変形が可能である。

図１は、ＵＳＢデバイスサーバシステムの全体構成の一例を示している。
ＵＳＢデバイスサーバシステムでは、クライアント端末１からネットワーク５経由でデバイスサーバ２に接続されているＵＳＢデバイス３を制御できる。例えば、ＵＳＢデバイス３がスキャナーである場合、クライアント端末１からあたかもローカルに接続されているスキャナーと同様に、ＵＳＢデバイス３（この例ではスキャナー）を制御して画像データを取り込むことができる。
また、一方で、図示するように、ＵＳＢデバイスサーバシステムを用いることにより、クライアント端末１の映像信号をデバイスサーバ２がネットワーク５経由でＵＳＢ信号データを受け取り、これをＲＧＢ信号データに置き換えて、ＵＳＢデバイス３に送り、ＵＳＢデバイス３にＲＧＢ接続されたモニター端末７に表示させることができる。

スキャナーから取り込む画像データや、画面の映像信号データの場合、特に高解像度画面の場合は、データ量が非常に大きくなる。そのため、ＵＳＢデバイスサーバシステムにおけるデータ転送も１回で完結することなく、複数回のデータ転送を伴うことになる。
例えば、ＵＳＢデバイスがスキャナーの場合は、ＵＳＢデバイス側からクライアント端末側に向けた片方向の複数回のデータ転送が生じることになる。また、クライアント端末の映像信号をＵＳＢデバイスに転送する場合は、クライアント端末側からＵＳＢデバイス側に向けた片方向の複数回のデータ転送が生じることになる。
本実施例のＵＳＢデバイスサーバシステムでは、このように、片方向の複数回のデータ転送が生じる場合に、無駄な通信フローを減らし、通信に要するオーバーヘッドを軽減する。以下にて詳細を説明する。

図２は、従来のＵＳＢデバイスサーバシステムの機能ブロックを示している。
クライアント端末１には、ドライバ１１とトンネリングドライバ１３とネットワークＩ／Ｆ１５の機能が搭載されている。
また、デバイスサーバ２には、ＵＳＢＩ／Ｆ２１とＵＳＢコントローラ２３とトンネリングドライバ２５とネットワークＩ／Ｆ２９の機能が搭載されている。

図３は、従来のＵＳＢデバイスサーバシステムにおけるクライアント端末１の機能ブロックであり、トンネリングドライバ１３がＵＲＢ（USB Request Block）解析１３１とトンネリングパケット生成１３２の機能ブロックで構成されていることを示している。トンネリングドライバ１３は、ドライバ１１からＵＲＢ（USB Request Block）を受け取ると、ＵＲＢの解析１３１を行い、ＵＲＢを含むトンネリングパケットを生成１３２し、それをネットワークＩ／Ｆ１５に送る。

図４、図５は、従来のＵＳＢデバイスサーバシステムにおけるデータ通信フローを示している。図４はクライアント端末１からＵＳＢデバイス３へのデータ送信の場合を示しており、図５はＵＳＢデバイス３からクライアント端末１へのデータ送信の場合を示している。
まず図４に示すように、従来、クライアント端末１からＵＳＢデバイス３へデータ送信する場合、クライアント端末１からデバイスサーバ２に対して１つのデータを送信する毎に（４１ａ，４２ａ，４３ａ）、デバイスサーバ２からクライアント端末１に対して応答通信（４１ｃ，４２ｃ，４３ｃ）が発生していた。これらの応答通信（４１ｃ，４２ｃ，４３ｃ）は、ＵＳＢデバイス３のステータスを、ホストであるクライアント端末１に通知するものであり、ＵＳＢデバイス３のステータス変化や通信エラーなど，特定の場合が発生しない限りは通知する必要性が低く、ＵＳＢ通信において比較的重要度の低い通信である。本発明はクライアント端末１とデバイスサーバ２との間は、信頼性が確保されているＴＣＰ通信を用いることから、ネットワーク通信に伴う遅延以外の事象が発生することは稀であり、この意味で、ＵＳＢデバイスサーバシステムにおいて、上述の応答通信（４１ｃ，４２ｃ，４３ｃ）は冗長な（無駄な）応答通信となっている。

また、逆に図５に示すように、従来、ＵＳＢデバイス３からクライアント端末１へデータ送信する場合、クライアント端末１からデバイスサーバ２に対してコマンド（データ要求）データを送信し（５１ａ）、デバイスサーバ２がＵＳＢデバイス３に対して当該コマンドを送信する（５１ｂ）。デバイスサーバ２がＵＳＢデバイス３からデータを受信すると（５１ｃ）、クライアント端末１に対してデータを送信する（５１ｄ）。従来、クライアント端末１は、１つのデータを受信するにはそのたびにコマンド（データ要求）データを送信する必要があった。たとえば、連続してデータ要求のコマンドを送信する場合、同じコマンドを複数回に分けて（細切れに）デバイスサーバ２に送信する必要があった。このように、同じコマンドを複数回送信することから、特に、２回目以降のコマンド送信（５２ａ，５３ａ）は、非効率な（無駄な）通信となっていた。

以下、本発明のデバイスサーバシステムの実施例について、上述の従来のＵＳＢデバイスサーバシステムの機能ブロック、データ通信フローと対比しながら詳細に説明する。
図６は本発明のデバイスサーバシステムにおけるクライアント端末１の機能ブロックを、図７は本発明のデバイスサーバシステムにおけるデバイスサーバ２の機能ブロックを示している。
まず、本発明のデバイスサーバシステムにおけるクライアント端末１の機能ブロックに関して、図６を参照して、従来のデバイスサーバシステムにおけるクライアント端末１の機能ブロックの図３と対比しながら説明する。
従来のデバイスサーバシステムにおけるクライアント端末１では、図３に示すように、トンネリングドライバ１３は、ドライバ１１からＵＲＢ（USB Request Block）を受け取ると、ＵＲＢの解析１３１を行い、ＵＲＢを含むトンネリングパケットを生成１３２し、それをネットワークＩ／Ｆ１５に送る。

一方、本発明のデバイスサーバシステムにおけるクライアント端末１では、図６に示すように、トンネリングドライバ１３は、ＵＲＢの内容を解析して、従来のトンネリングパケット又は連続通信トンネリングパケットのいずれを生成するかを判断する。
ＵＲＢに含まれる「データ単位」、「通信タイミング」、および「停止タイミング」の情報から連続通信であるか否かを判断するのである。なお、連続通信であるか否かの判断基準は、これらの情報に限定されず、他のパラメータにより判断しても構わない。
ＵＲＢの中身を解析して、連続通信（データ送信、データ受信のいずれも可）であるか否かの判断を行い、後続して連続通信が発生することを検知すると、連続通信トンネリングパケット（連続通信通知のパケット）を生成して、デバイスサーバ２に通知する点が、本発明のデバイスサーバシステムの特徴である。
これにより、本発明は、従来なら必要となっていたネットワーク通信を間引くことができるため、クライアント端末１とデバイスサーバ２と間の通信のパフォーマンスを向上させることができる。
具体的には、データ送信の場合は、図４で説明した、デバイスサーバ２からクライアント端末１への応答通信を間引き、データ受信の場合は、図５で説明した、クライアント端末１からデバイスサーバ２へのコマンド送信を間引くわけである。

次に、本発明のデバイスサーバシステムにおけるデバイスサーバ２の機能ブロックに関して、図７を参照して、従来のデバイスサーバシステムにおけるデバイスサーバ２の機能ブロックの図２と対比しながら説明する。
従来のデバイスサーバシステムにおけるデバイスサーバ２では、図２に示すように、ＵＳＢＩ／Ｆ２１とＵＳＢコントローラ２３とトンネリングドライバ２５とネットワークＩ／Ｆ２９の機能が搭載されている。
一方、本発明のデバイスサーバシステムにおけるデバイスサーバ２では、図７に示すように、ネットワークＩ／Ｆ２９とトンネリングドライバ２５の間に、新たに、パケット解析手段２８を設け、クライアント端末１から送信されるトンネリングパケットを解析して、従来のトンネリングパケットか連続通信トンネリングパケット（連続通信通知のパケット）か否かを解析する。そして、解析の結果、連続通信トンネリングパケット（連続通信通知のパケット）であると判断すると、連続通信トンネリングドライバ２６が当該パケットを処理する。

ここで、連続通信トンネリングドライバの動作について、送信の場合（デバイスに向けてデータを送る）と受信の場合（デバイスからのデータを要求する）について説明する。
まず、送信の場合（ＵＳＢデバイス３に向けてデータを送る）、ＵＳＢデバイス３からの応答データを検出した場合や，ＵＳＢデバイス３のステータス変化を検出した場合などの所定の事象が発生しない限り、デバイスサーバ２はクライアント端末１に応答を返さない。これにより、応答に必要なネットワーク通信を削減できる。応答通信は、クライアント端末１のドライバ１１に通信のステータスを報告するものなので、一番厳密な動きは、１つの送信ごとに応答（ステータス）を返すことである。しかし、本発明はデバイスサーバシステムであり、ＴＣＰ（Transmission
Control Protocol）通信を使用していることから、クライアント端末１とデバイスサーバ２との間の通信の信頼性は確保されている。このためドライバ１１に応答通信をする必要性が低い。つまり、必要性の低い応答通信を間引いて、応答通信にかかるオーバーヘッドを軽減している。勿論，上述したように，ＵＳＢデバイス３からの応答データを検出した場合やＵＳＢデバイス３のステータス変化を検出した場合など，クライアント１にとって重要度の高い事象が発生した場合，デバイスサーバ２はクライアント１に対して応答通信を行う。

次に、受信の場合（デバイスからのデータを要求する）、細切れ単位の連続したデータ要求を１つの要求に統合して要求する。これにより、複数の要求に必要なネットワーク通信を削減できる。
例えば、従来のデバイスサーバシステムの場合であると、１０（ｂｙｔｅ）のデータ要求コマンドを１ｍｓ間隔で１０回送信していたものが、本発明のデバイスサーバシステムの場合では、１０（ｂｙｔｅ）のデータ要求コマンドを１０ｍｓ単位にまとめて１回送信することになる。なお、本発明のデバイスサーバシステムの場合、クライアント端末１からデバイスサーバ２へのデータ要求はこのように１回に統合されるが、デバイスサーバ２からＵＳＢデバイス３へのデータ要求は、元の細切れ状態で１０回要求する。
図５の場合だと、クライアント端末１からデバイスサーバ２への通信は、トンネリングパケット（５１ａ，５２ａ，５３ａ）のコマンド送信を１回のトンネリングパケットに統合し、デバイスサーバ２からＵＳＢデバイス３への通信は、従来通り、細切れのコマンド（５１ｂ，５２ｂ，５３ｂ）として送信する。

図８は、連続通信通知のパケット構造の一例である。これが連続通信トンネリングパケットのフォーマットになる。
図８の連続通信通知のパケットは、クライアント端末１からデバイスサーバ２に対して連続通信である旨を通知するものである。連絡送信、連続受信の双方にこのパケットを用いることが可能である。パケットは、宛先アドレス３１、送信元アドレス３２、データ単位３３、通信タイミング３４、停止タイミング３５、実データ３６の情報データで構成されている。
また、デバイスサーバ２に複数のＵＳＢデバイス３が接続されている場合、このパケットには連続通信を要求するデバイス識別情報も含まれる。

図９、図１０は、本発明のデバイスサーバシステムにおけるデータ通信フローを示している。図９はクライアント端末１からＵＳＢデバイス３へのデータ送信の場合を示しており、図１０はＵＳＢデバイス３からクライアント端末１へのデータ送信の場合を示している。
本発明のデバイスサーバシステムでは、クライアント端末１からＵＳＢデバイス３へデータ送信する場合、従来とは異なり、クライアント端末１からデバイスサーバ２に対して１つのデータを送信する毎に、デバイスサーバ２からクライアント端末１に対して応答通信が発生することがない（所定の場合を除く）。クライアント端末１からデバイスサーバ２に対して連続通信トンネリングパケットが連続して送られるだけである（１０１ａ，１０２ａ，１０３ａ，１０４ａ）。なお、２回目以降の送信（１０２ａ，１０３ａ，１０４ａ）は、必ずしも図８に示すようなフォーマットのパケットでなくてもよい。１回目の送信（１０１ａ）により、後続の通信が連続通信であることを通知することができるためである。
このように、クライアント端末１からデバイスサーバ２経由でＵＳＢデバイス３にデータを送信する場合、連続通信トンネリングパケットとして送信することで、原則として、デバイスサーバ２はクライアント端末１に応答を返さない。デバイスサーバ２では、エラー発生などの場合に限り、クライアント端末１に応答を返す。

また、本発明のデバイスサーバシステムでは、ＵＳＢデバイス３からクライアント端末１へデータ送信する場合、クライアント端末１からデバイスサーバ２に対してコマンド（データ要求）データとしての連続通信トンネリングパケットを送信し（１１１ａ）、デバイスサーバ２がＵＳＢデバイス３に対してコマンドを送信する（１１１ｂ）。デバイスサーバ２がＵＳＢデバイス３からデータを受信すると（１１１ｃ）、クライアント端末１に対してデータを送信する（１１１ｄ）。上述の通り、従来、クライアント端末１は、１つのデータを受信するにはそのたびにコマンド（データ要求）データを送信する必要があった。しかし、本発明のデバイスサーバシステムの場合、従来と異なり、２回目以降のコマンド（データ要求）データの送信は無く、最初にデバイスサーバ２に対してコマンド（データ要求）データとしての連続通信トンネリングパケットを送信したら（１１１ａ）、クライアント端末１は要求したデータを連続して受信するだけである（１１１ｄ，１１２ｄ，１１３ｄ）。
このように、クライアント端末１からデバイスサーバ２へのデータ要求は１回に統合され（１１１ａ）、デバイスサーバ２からＵＳＢデバイス３へのデータ要求は、従来と同様に細切れ状態で複数回に分けてコマンドを発行する（１１１ｂ，１１２ｂ，１１３ｂ）。

以上説明した実施例では、クライアント端末１からの連続したデータ送信の場合、クライアント端末１側で連続通信を認識し、連続通信トンネリングパケットを生成・送信した。他方、当該連続通信トンネリングパケットを受信したデバイスサーバ２は、当該受信によって連続したデータ送信であることを認識し、応答通信を送信しないようにしていた。
このように、上述した実施例では、連続したデータ送信であることを判断するのはクライアント端末１であったが、必ずしも、当該判断はクライアント端末１で行われる必要はない。たとえば、連続通信トンネリングパケットではなく、何らかの手段により、デバイスサーバ２が連続したデータ送信であることを認識することができれば、デバイスサーバ２自身は、応答通信を間引く動作を実現することが可能である。つまり、デバイスサーバ２単独で応答通信を間引くことができるわけである。
デバイスサーバ２が連続通信であることを認識する手段として、たとえば、実データが含まれる上述の連続通信トンネリングパケットではなく、連続通信のみを通知する通信を利用することや、通常のトンネリングパケットの内容から、デバイスサーバ２が連続通信であることを推定することなどが利用可能である。

なお、これまでの実施例では、ＵＳＢデバイスサーバシステムを例に説明したが、本発明の適用範囲はこれに限定されず、図４および図５に示すように、ＵＳＢ通信規格と同等の通信方式を用いたデバイスのデバイスサーバシステムであればどのようなものでも適用可能である。

本発明は、ＵＳＢデバイスなどの周辺デバイスの利便性を高めるデバイスサーバシステムに有用である。

１ クライアント端末
２ デバイスサーバ
３ ＵＳＢデバイス
４ ＵＳＢ接続ケーブル
５ ネットワーク
７ モニター端末
８ ＲＧＢ信号ケーブル

Claims (3)

1. ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムであって、
   前記クライアントは、
   前記所定のデバイスを制御する命令を発行するデバイス制御手段と、
   前記デバイス制御手段が発行した前記命令であって、所定単位のデータを前記所定のデバイスに対して送信するデータ送信手段と、
   前記データ送信手段によるデータ送信であって、複数の連続した当該データ送信が行われると判断すると、連続送信通知のパケットを前記デバイスサーバに対して送信する連続送信通知手段と、を備え、
   前記デバイスサーバは、
   前記連続送信通知を受信した場合、所定の場合についてのみ、前記連続送信通知にかかる応答を前記クライアントに対して送信する通知応答送信手段と、
   を備え、
   前記所定の場合は、「前記デバイスからの応答データを検出した」または「前記デバイスのステータス変化を検出した」のいずれか１つを含む、デバイスサーバシステム。
   
2. ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムにおけるデバイスサーバであって、
   前記クライアントが前記所定のデバイスに対して送信した、所定単位のデータを受信するデータ受信手段と、
   前記データ受信手段が受信した前記所定単位のデータが複数連続して受信（連続受信）するか否かを判断する連続受信判断手段と、
   前記連続受信判断手段が連続受信をすると判断した場合、所定の場合についてのみ、前記連続受信にかかる応答を前記クライアントに対して送信する応答送信手段と、
   を備え、
   前記所定の場合は、「前記デバイスからの応答データを検出した」または「前記デバイスのステータス変化を検出した」のいずれか１つを含む、デバイスサーバ。
   
3. ネットワークを通じてクライアントとデバイスサーバとがＴＣＰプロトコルにて接続されており、当該デバイスサーバには所定のデバイスが接続され、当該クライアントがネットワークを通じて当該デバイスサーバ経由にて当該所定のデバイスを利用するデバイスサーバシステムにおけるデバイスサーバを、
   前記クライアントが前記所定のデバイスに対して送信した、所定単位のデータを受信するデータ受信手段、
   前記データ受信手段が受信した前記所定単位のデータが複数連続して受信（連続受信）するか否かを判断する連続受信判断手段、
   前記連続受信判断手段が連続受信をすると判断した場合、所定の場合についてのみ、前記連続受信にかかる応答を前記クライアントに対して送信する応答送信手段、
   として機能させ、
   前記所定の場合は、「前記デバイスからの応答データを検出した」または「前記デバイスのステータス変化を検出した」のいずれか１つを含む、プログラム。