JP2011129111A - クライアント装置、デバイス制御方法、およびデバイス制御システム - Google Patents

Abstract

【課題】ローカル接続した場合に１台から数台しか制御できないデバイスであっても、接続インターフェースの規格上の最大接続台数まで接続し、制御可能な手段を提供する。
【解決手段】クライアント装置は、デバイスが接続されたことを検知すると、そのデバイスのデバイス情報を取得し、ドライバソフトウェア部品とアプリケーションソフトウェア部品とから成るデバイススタックを、接続されたことを検知したデバイスの個体毎に生成し、当該デバイススタックの各々によって、デバイスの各個体を独立して制御する。
【選択図】図２

Description

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

ネットワークの普及により、従来、パーソナルコンピュータ（ＰＣ）などにローカル接続して利用していたプリンタ、ストレージ、スキャナなどのデバイス（周辺機器）をネットワーク上のクライアントＰＣから利用できるように工夫したデバイス制御システムが発表されている。

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

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

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

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

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

例えば、カードリーダなどのデバイスの場合、その仕様上、一台のクライアントＰＣに同一機種のデバイスを複数台接続することは考慮されていないものが多い。これは、消費電流やトラフィックが増加することなどを考慮した結果、品質保証および動作保証上の観点から、メーカーやベンダーが提供するソフトウェア部品であるＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）において、接続台数制限が設けられているためである。例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）の場合、規格スペック上の接続台数は最大１２７台であるが、上述のＳＤＫに設けられた接続台数制限により、規格スペックを生かしきれていないのが現状である。

また、カードリーダのように同一のクライアントＰＣからの複数台制御が考慮されていないデバイスの場合、シリアル番号など、同一機種／別個体を識別するための情報がデバイス情報として記述されていないことが多く、こうしたデバイスを複数台ネットワーク接続して共有したときに、いかにして同一機種／別個体を識別するかも問題である。

上記問題に鑑みて、本発明は、デバイスの制御に必要なソフトウェア部品を、ネットワーク上に存在するデバイスの台数（ｎ台）分だけクライアントＰＣ内に構成して、仮想的にｎ対ｎの接続環境を構築することにより、クライアントＰＣにローカル接続した場合に１台〜数台しか制御できないデバイスであっても接続インターフェースの規格上の最大接続台数までデバイスを接続（認識）できるように制御することを目的とする。

また、本発明は、カードリーダのようにシリアル番号が付与されておらず、同一のクライアントＰＣからの複数台制御（複数台接続）が考慮されていないデバイスであっても、ユニークな情報（例えば、デバイスが接続されたデバイスサーバのＭＡＣアドレスとＵＳＢポート番号）をデバイス情報に追加することによって、シリアル番号がないデバイスが複数接続されても、各々のデバイスを同一機種であっても別個体として識別可能とし、複数のデバイスを独立して使用できるように制御することを目的とする。

上記の課題を解決するために、請求項１に記載のクライアント装置は、ネットワークを介して接続されたデバイス制御装置にローカル接続されているデバイスを検知するためのデバイス検知手段と、前記デバイス検知手段によって検知した前記デバイスのデバイス情報を取得するデバイス情報取得手段と、前記デバイス情報取得手段で取得したデバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知手段が接続を検知した前記デバイスの個体毎に生成するデバイススタック生成手段と、前記デバイススタック生成手段で生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求手段と、前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始するセッション制御手段と、前記デバイススタックの各々により、前記セッション制御手段で開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御手段と、を備えることを特徴とする。

また、上記の課題を解決するために、請求項４に記載のデバイス制御方法は、デバイス制御装置にローカル接続されているデバイスを検知するためのデバイス検知ステップと、前記デバイス検知ステップにおいて検知した前記デバイスのデバイス情報を取得するデバイス情報取得ステップと、前記デバイス情報取得ステップで取得したデバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知ステップにおいて検知した前記デバイスの個体毎に生成するデバイススタック生成ステップと、前記デバイススタック生成ステップにおいて生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求ステップと、前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始するセッション制御ステップと、前記デバイススタックの各々によって、前記セッション制御ステップで開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御ステップと、を備えることを特徴とする。

また、上記の課題を解決するために、請求項７に記載のデバイス制御システムは、クライアント装置と、前記クライアント装置とネットワークを介して接続されたデバイス制御装置と、前記デバイス制御装置とローカル接続されたデバイスからなるデバイス制御システムであって、前記クライアント装置は、前記デバイス制御装置を介して前記デバイスを検知するためのデバイス検知手段と、前記デバイス検知手段によって検知した前記デバイスのデバイス情報を取得する第１のデバイス情報取得手段と、前記第１のデバイス情報取得手段で取得した前記デバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知手段が接続を検知した前記デバイスの個体毎に生成するデバイススタック生成手段と、前記デバイススタック生成手段で生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求手段と、前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始する第１のセッション制御手段と、前記デバイススタックの各々により、前記第１のセッション制御手段で開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御手段と、を備え、前記デバイス制御装置は、前記デバイスからデバイス情報を取得する第２のデバイス情報取得手段と、前記第２のデバイス情報取得手段で取得した前記デバイス情報を前記クライアント装置へ送信するデバイス情報送信手段と、前記クライアント装置で生成された前記デバイススタックの各々からの接続要求に応じて、当該デバイススタックの各々との間で独立したセッションを開始する第２のセッション制御手段と、を備えることを特徴とする。

本発明によれば、デバイスの制御に必要なソフトウェア部品を、ネットワーク上に存在するデバイスの台数（ｎ台）分だけクライアントＰＣ内に構成して、仮想的にｎ対ｎの接続環境を構築することにより、クライアントＰＣにローカル接続した場合に１台〜数台しか制御できないデバイスであっても接続インターフェースの規格上の最大接続台数までデバイスを接続（認識）できるようになる。

また、本発明によれば、カードリーダのようにシリアル番号が付与されておらず、同一のクライアントＰＣからの複数台制御（複数台接続）が考慮されていないデバイスであっても、ユニークな情報（例えば、デバイスが接続されたデバイスサーバのＭＡＣアドレスとＵＳＢポート番号）をデバイス情報に追加することによって、シリアル番号がないデバイスが複数接続されても、各々のデバイスが同一機種であっても別個体として識別可能とし、複数のデバイスを独立して使用できるようになる。

実施例１に係るデバイス制御システムの概略構成を示す図である。 クライアントＰＣ１００の内部構成を例示するブロック図である。 実施例１に係るデバイスサーバ２００の内部構成を例示するブロック図である。 実施例１に係るデバイスサーバ２００におけるデバイス情報取得処理の手順について説明するフローチャートである。 クライアントＰＣ１００におけるデバイス３００の仮想化制御について説明するフローチャートである。 クライアントＰＣ１００におけるアプリケーションプログラム１１１実行時の制御について説明するフローチャートである。 デバイスサーバ２００におけるデータ送受信の制御について説明するフローチャートである。 パケットのデータ構成を例示する図である。 本発明に係るデバイス制御システムにおいて、クライアントＰＣ１００がデバイス制御する場合の過程を説明するシーケンス図である。 実施例２に係るデバイス制御システムの概略構成を示す図である。 実施例２に係るネットワークデバイス２５０の内部構成を例示するブロック図である。

以下、本発明の実施の形態について、詳細に説明する。

実施例１に係る実施の形態を説明する。

＜１． デバイス制御システムの構成＞
図１は、本発明を実現するためのデバイス制御システムの概略構成であり、クライアントＰＣ１００（１００Ａ，１００Ｂ）、デバイスサーバ２００（２００Ａ，２００Ｂ）、デバイス３００（３００Ａ，３００Ｂ，３００Ｃ）から構成される。

このデバイス制御システムでは、デバイスサーバ２００とデバイス３００をＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やＩＥＥＥ１３９４などのインターフェースに準拠した接続ケーブル４００で接続する。また、デバイスサーバ２００とクライアントＰＣ１００（クライアントＰＣ１００Ａ，１００Ｂ）は、有線または無線のネットワーク５００で接続する。

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

＜２． クライアントＰＣ１００の構成＞
クライアントＰＣ（クライアント装置）１００のハードウェア構成およびソフトウェア構成について図２を用いて説明する。

クライアントＰＣ１００は、ＣＰＵ１０１、入力部１０２、表示部１０３、メモリ１０４、通信部１０５、外部記憶部１０６などから構成されており、これらが内部バス１０７で接続されている。

ＣＰＵ１０１は、中央処理制御部であり、メモリ１０４や外部記憶部１０６に格納された所定のプログラムを実行することによってクライアントＰＣ１００を全体的に制御する。

入力部１０２は、各種入力、指示操作などを行なうための操作部であり、キーボードやマウスなどで構成される。

表示部１０３は、各種画面などを表示するディスプレイであり、クライアントＰＣ１００に内蔵もしくは外部接続される。

メモリ１０４は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）およびＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）で構成される記憶領域であり、所定のプログラムやデータを格納する。

通信部１０５は、Ｅｔｈｅｒｎｅｔ（登録商標）のような有線ネットワーク、若しくは、ＩＥＥＥ８０２．１１ａやＩＥＥＥ８０２．１１ｇのような無線ネットワークなど、ネットワーク５００の通信方式に対応したネットワークパケットによるデータ送受信の制御を通信制御部１１６（後述）と連携して行う通信制御インターフェースである。

外部記憶部１０６は、ＯＳ１０８、常駐モジュール１０９、デバイススタック１１０（後述）、通信制御部１１６などの各種ソフトウェアプログラムを記憶する。

外部記憶部１０６に格納されたこれらのソフトウェアプログラムは、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行される。

本実施例では、３台のデバイス（デバイスａ３００Ａ、デバイスｂ３００Ｂ、デバイスｃ３００Ｃ）が接続され、３つのデバイススタック１１０（デバイススタックＡ１１０Ａ、デバイススタックＢ１１０Ｂ、デバイススタックＣ１１０Ｃ）が生成された場合を例にして説明する。

では、常駐モジュール１０９、デバイススタック１１０を構成する各ソフトウェアプログラム（アプリケーションプログラム１１１、アプリケーション／デバイスドライバインターフェース１１２、デバイスドライバ１１３、ＵＳＢクラスドライバ１１４、ＵＳＢ仮想バスデバイス１１５）及び通信制御部１１６の詳細について説明する。

常駐モジュール１０９は、ＯＳ１０８が起動している間、常に待機および動作しているソフトウェアプログラムである。ネットワーク５００上にあるデバイスサーバ２００とデータ送受信を行うことにより、デバイスサーバ２００にローカル接続されたデバイス３００を検知する機能（デバイス検知手段）、当該デバイス３００のデバイス情報を取得する機能（デバイス情報取得手段）、取得したデバイス情報をもとに、デバイス３００とのデータ送受信に必要なドライバソフトウェア部品を構成するＵＳＢ仮想バスデバイス１１５、ＵＳＢクラスドライバ１１４、デバイスドライバ１１３を一意に特定し、動的に生成する。

常駐モジュール１０９は、さらに、ドライバソフトウェア部品を生成した後、当該デバイス３００を制御するためのアプリケーションソフトウェア部品を構成するアプリケーションプログラム１１１とアプリケーション／デバイスドライバインターフェース１１２をメモリ１０４から起動することで、デバイス３００の個体毎にデバイススタック１１０を動的に生成する機能（デバイススタック生成手段）を備えており、上記の機能によって生成されたデバイススタック１１０を用いてデバイス３００を個体毎に独立して制御するソフトウェアプログラム（デバイス制御手段）である。

デバイスドライバ１１３は、ＯＳ１０８やアプリケーションプログラム１１１など（以下、上位層のソフトウェアプログラム）の指示により、デバイス３００に対する制御コマンドを生成してデータ送受信を実行し、この制御コマンドに対するデバイス３００からの応答（すなわち、データ送受信の結果）を待ち、この応答を上位層のソフトウェアプログラムへ通知するソフトウェアプログラムである。

ＵＳＢクラスドライバ１１４は、制御コマンドを送受信するためのＵＳＢポートを有し、アプリケーションプログラム１１１やデバイスドライバ１１３で生成される制御コマンドをＵＳＢパケットに変換し、ＵＳＢパケットを制御コマンドに変換するソフトウェアプログラムである。

ＵＳＢ仮想バスデバイス１１５は、アプリケーションプログラム１１１やデバイスドライバ１１３から要求されるデバイス３００へのデータ送受信に対して、デバイス３００がクライアントＰＣ１００に直結しているときと同様の振る舞い（仮想化制御）を提供するソフトウェアプログラムである。この「仮想化制御」によって、デバイス３００をローカル接続したときと同じ状態でデータ送受信することができる。

通信制御部１１６は、デバイススタック１１０で生成される「ＵＳＢパケット」とネットワーク５００を介してデバイスサーバ２００と通信するときの「ネットワークパケット」とのプロトコル変換を行い、通信部１０５と連携してデバイスサーバ２００との間のデータ送受信を制御するソフトウェアプログラムである。また、各デバイススタック１１０からのデータ送受信要求（接続要求）をデバイスサーバ２００に送信し（接続要求手段）、当該デバイスサーバ２００との間で、それぞれのデバイススタック１１０毎に独立したセッションを開始させ、データ送受信が完了したセッションを終了させるセッション制御機能（セッション制御手段）を備えている。

アプリケーションプログラム１１１、アプリケーション／デバイスドライバインターフェース１１２は、アプリケーションソフトウェア部品を構成するソフトウェアプログラムであり、常駐モジュール１０９によって、ドライバソフトウェア部品の上位層に起動される。アプリケーションプログラム１１１は、デバイス３００に対してデータ送受信の要求（接続要求）を行い、デバイス３００を制御するためのソフトウェアプログラムである。アプリケーション／デバイスドライバインターフェース１１２は、デバイス３００の制御に必要なツール（機能）を提供するソフトウェアプログラムであり、メーカーやベンダーから提供されるＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）に該当するものである。

＜３． デバイスサーバ２００の構成＞
続いて、デバイスサーバ２００のハードウェア構成およびソフトウェア構成について図３を用いて説明する。

デバイスサーバ２００（デバイス制御装置）は、ＣＰＵ２０１、メモリ２０２、通信部２０３、ＵＳＢ Ｉ／Ｆ２０４、外部記憶部２０５などから構成されており、これらが内部バス２０６で接続されている。

ＣＰＵ２０１、メモリ２０２、通信部２０３、および、内部バス２０６については、前述したクライアントＰＣ１００における構成と同一であるため詳細な説明を省略する。

ＵＳＢ Ｉ／Ｆ２０４は、例えば、ＵＳＢ仕様に準拠した送受信インターフェースであって、デバイス３００との接続などに利用される。

外部記憶部２０５は、通信制御部２０７、デバイス制御部２０８などのソフトウェア機能部やデータを記憶するための記憶部である。

では、通信制御部２０７、デバイス制御部２０８の詳細について順に説明する。

通信制御部２０７は、通信部２０３を介してネットワーク５００に接続されているクライアントＰＣ１００内で生成される各デバイススタック１１０との間のセッションを制御（開始、終了）するとともに、クライアントＰＣ１００と通信するための「ネットワークパケット」とデバイス３００との間で送信する「ＵＳＢパケット」とのプロトコル変換を行い、クライアントＰＣ１００とデバイス３００との間のデータ送受信を仲介（中継）するための機能部（データ送受信手段）である。また、クライアントＰＣ１００に対してデバイス３００から取得したデバイス情報を送信するための機能部（デバイス情報送信手段）を備えている。

デバイス制御部２０８は、デバイス３００とＵＳＢ Ｉ／Ｆ２０４を介して接続される機能部であり、接続されたデバイス３００からデバイス情報を取得する機能（デバイス情報取得手段）、取得したデバイス情報にシリアル番号が含まれるか否かを判別する機能（シリアル情報有無判別手段）、取得したデバイス情報にシリアル番号が含まれない場合に、シリアル番号に相当する個体識別番号を生成して当該デバイス情報に追加する機能（シリアル情報追加手段）、クライアントＰＣ１００から受信した当該制御コマンドに含まれるデバイス情報に基づいてクライアントＰＣ１００がデータ送受信を求めるデバイス３００を特定し、ＵＳＢ Ｉ／Ｆ２０４を介してデバイス３００を制御する機能を備える。

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

＜５． デバイスサーバ２００にデバイス３００が接続された時の処理＞
次に、デバイスサーバ２００にデバイス３００が接続された時に、デバイスサーバ２００上で実行される処理について、図４のフローチャートで説明する。

デバイスサーバ２００は、デバイス３００が接続されると、本デバイス情報取得処理のフローに従って処理を開始する。

まずはじめに、デバイス制御部２０８は、デバイス３００からＵＳＢ Ｉ／Ｆ２０４を介してデバイス３００を識別するためのデバイス情報を取得し、メモリ２０２に格納する（ステップＳ４０１）。ここで、デバイス情報とは、メーカーを識別するために機器を製造したメーカー毎に割り当てられたベンダーＩＤ（ＶＩＤ）、機種を識別するために機種毎に割り当てられた製品ＩＤ（ＰＩＤ）、機器の個体を識別するために個体毎に割り当てられたシリアル番号などである。

続いて、デバイス３００から取得したデバイス情報にシリアル番号が格納されているかどうかを判別する（ステップＳ４０２）。

デバイス３００から取得したデバイス情報にシリアル番号が格納されている場合には（ステップＳ４０２でＹｅｓ）、次のステップＳ４０３に進むが、デバイス３００から取得したデバイス情報にシリアル番号が格納されていない場合には（ステップＳ４０２でＮｏ）、デバイスサーバ２００の有する固有情報、若しくは、固有情報とデバイスサーバ２００の接続ポート固有情報から個体識別番号を生成し、デバイス情報に追加する（ステップＳ４０５）。これにより、シリアル番号が格納されていない同一機種のデバイス３００が複数接続された場合でも、クライアントＰＣ１００から識別可能となる。

本処理において、デバイスサーバ２００に複数台のデバイス３００が接続された場合、デバイスごとに本デバイス情報取得処理が繰り返される。

なお、デバイスサーバ２００の有する固有情報とは、デバイスサーバ２００を識別するための情報である。例えば、デバイスサーバ２００のＩＰアドレスやＭＡＣアドレス、シリアルナンバー（製造番号）などであるが、これらに限定されない。さらに、これらの情報を組み合わせたものであってもよい。

また、デバイスサーバ２００の接続ポート固有情報とは、デバイスサーバ２００の接続ポートを識別するための情報である。例えば、デバイスサーバ２００の有するＵＳＢポートの番号やＩＥＥＥ１３９４ポートの番号などであるが、これらに限定されない。

ステップＳ４０２又はステップＳ４０５に続いて、通信制御部２０７は、クライアントＰＣ１００からデバイス情報の問い合わせがあるまで待機する（ステップＳ４０３でＮｏ）。クライアントＰＣ１００からの問い合わせは、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いて行なわれる。

通信制御部２０７は、クライアントＰＣ１００からデバイス情報の問い合わせがあるとデバイス制御部２０８に通知し（ステップＳ４０３でＹｅｓ）、デバイス制御部２０８が、メモリ２０２に格納されている中から該当するデバイス情報を特定し、通信制御部２０７は、特定したデバイス情報を、通信部２０３を介してクライアントＰＣ１００に通知して処理を終了する（ステップＳ４０４）。これによって、クライアントＰＣ１００は、デバイスサーバ２００に接続されているデバイス３００のデバイス情報を取得することができる。

なお、上記では、クライアントＰＣ１００からデバイスサーバ２００に対して問い合わせを行なうことで、クライアントＰＣ１００がデバイス情報を取得する方法について説明したが、デバイスサーバ２００がクライアントＰＣ１００に対して通知することで、クライアントＰＣ１００がデバイス情報を取得するようにしてもよい。

＜６． クライアントＰＣ１００におけるデバイス３００の仮想化制御＞
図５は、クライアントＰＣ１００におけるデバイス３００の仮想化制御の一例を示したものである。

クライアントＰＣ１００内の常駐モジュール１０９は、デバイスサーバ２００を介してネットワーク５００に接続されたデバイス３００を知るために、通信部１０５を介して、デバイスサーバ２００に対して検索パケットをブロードキャストする（ステップＳ５０１）。具体的には、ＵＤＰなどのプロトコルを用いて、デバイスサーバ２００に対する検索（問い合わせ）を行なうための検索パケットを送信する。

常駐モジュール１０９は、デバイスサーバ２００からの応答を待ち（ステップＳ５０２）、デバイスサーバ２００から応答がない場合には（ステップＳ５０２でＮｏ）、仮想化制御は行わず、処理を終了する。

一方、常駐モジュール１０９は、デバイスサーバ２００から応答があると（ステップＳ５０２でＹｅｓ）、デバイスサーバ２００からの応答電文に含まれるデバイス情報（ディスクリプタ）を取得する（ステップＳ５０３）。

常駐モジュール１０９は、取得したデバイス情報のうち、デバイスディスクリプタに記述されたベンダーＩＤ（ＶＩＤ）と製品ＩＤ（ＰＩＤ）、ストリングディスクリプタに記述されたシリアル番号とデバイス名称によってデバイスの種類と個体を識別する。また、インターフェースディスクリプタに記述されたインターフェース番号を識別する（ステップＳ５０４）。このようにして識別されたデバイスの個体に関する情報に基づいて、ドライバソフトウェア部品（ＵＳＢ仮想バスデバイス１１５、ＵＳＢクラスドライバ１１４、デバイスドライバ１１３）を一意に特定し、動的に生成する（ステップＳ５０５〜ステップＳ５０７）。

その後、上記で生成されたドライバソフトウェア部品（ＵＳＢ仮想バスデバイス１１５、ＵＳＢクラスドライバ１１４、デバイスドライバ１１３）に適合するアプリケーションプログラム１１１と、アプリケーション／デバイスドライバインターフェース１１２をメモリ１０４から起動する（ステップＳ５０８）。

複数のデバイス３００からデバイス情報を取得した場合、取得した情報数（台数）に応じて、ステップＳ５０４〜ステップＳ５０８の処理を繰り返し行う。また、接続されたデバイス３００がＭＦＰである場合には、ステップＳ５０５〜ステップＳ５０７において、当該ＭＦＰが備えるプリント、スキャン、コピーなどの機能毎に必要なドライバソフトウェア部品がすべて生成される。

このようにして、クライアントＰＣ１００内において、ドライバソフトウェア部品（ＵＳＢ仮想バスデバイス１１５、ＵＳＢクラスドライバ１１４、デバイスドライバ１１３）とこれに対応したアプリケーションソフトウェア部品（アプリケーションプログラム１１１、アプリケーション／デバイスドライバインターフェース１１２）とから構成されるデバイススタック１１０が動的に生成されることで、アプリケーションプログラム１１１とこれによって制御されるデバイス３００とが１対１に関連付けられ、対象となるデバイス３００の仮想化制御が実行される。

＜７． アプリケーションプログラム１１１実行時の制御＞
次に、クライアントＰＣ１００がこの仮想化制御下において、デバイススタック１１０のアプリケーションプログラム１１１によって、デバイス３００との間でデータ送受信を実行する際の制御フローについて図６を用いて説明する。

ここでは、クライアントＰＣ１００Ａがデバイスサーバａ２００Ａを介してデバイスａ３００Ａとデータ送受信を行う場合について説明する。

クライアントＰＣ１００Ａは、デバイススタックＡ１１０Ａのアプリケーションプログラム１１１Ａによって、デバイスａ３００Ａとのデータ送受信が必要と判断した場合、デバイスａ３００Ａに対するデータ送受信要求を、アプリケーション／デバイスドライバインターフェース１１２Ａを介してドライバソフトウェア部品に送る。ドライバソフトウェア部品では、このデータ送受信要求（接続要求）に応じた制御コマンドを生成してＵＳＢパケットに変換して通信制御部１１６に送る。通信制御部１１６は、これをネットワークパケットに変換し、通信部１０５を介してデバイスサーバａ２００Ａに送ることで、デバイスサーバａ２００Ａとの間でＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）によるセッションを開始させる（ステップＳ６０１）。

デバイスサーバａ２００Ａとのセッションの開始に失敗した場合（ステップＳ６０２でＮｏ）は、本処理を終了する。

デバイスサーバａ２００Ａとのセッションの開始に成功すると（ステップＳ６０２でＹｅｓ）、クライアントＰＣ１００Ａは、デバイススタックＡ１１０Ａによって、デバイスサーバａ２００Ａを介して、デバイスａ３００Ａとの間のデータ送受信が可能となる（ステップＳ６０３）。データ送受信用パケットのデータ構造は図８で詳述する。

そして、送受信すべきデータがある間は（ステップＳ６０４でＮｏ）、ステップＳ６０３を繰り返す。

クライアントＰＣ１００Ａでは、デバイススタックＡ１１０Ａのアプリケーションプログラム１１１Ａによりすべてのデータの送受信が終了すると（ステップＳ６０４でＹｅｓ）、デバイスサーバａ２００ＡとのＴＣＰによるセッションを終了させて、データ送受信の処理を終了する（ステップＳ６０５）。

＜８． デバイスサーバ２００におけるデータ送受信の制御フロー＞
次に、上述したような仮想化制御下における、デバイスサーバａ２００Ａによるデータ送受信の制御フローについて図７を用いて説明する。

通信制御部２０７は、クライアントＰＣ１００ＡのデバイススタックＡ１１０Ａからのデータ送受信要求に応じてセッションを開始する（ステップＳ７０１）。次に、通信制御部２０７は、クライアントＰＣ１００Ａからデータ送受信を要求してきたパケットを解析し、デバイス制御部２０８は、通信制御部２０７で解析されたパケットに含まれるデバイス情報に基づいてデータ送受信を求めるデバイス３００を特定し（ここでは、デバイスａ３００Ａ）、ＵＳＢ Ｉ／Ｆ２０４を介して、該当するデバイスａ３００Ａとの間のデータ送受信を行なう（ステップＳ７０２）。デバイスサーバ２００とデバイス３００との間のデータ送受信用パケットのデータ構造は図８で詳述する。

ステップＳ７０２において、デバイス制御部２０８によるデバイスａ３００Ａとのデータ送受信を終えると、通信制御部２０７はクライアントＰＣ１００Ａとのセッションを終了する（ステップＳ７０３）。

このように、デバイスサーバ２００は、１台のクライアントＰＣ１００から異なるデバイススタック１１０を利用したデータ送受信要求に対して、各々独立してデバイス３００との接続を制御することはもちろんのこと、複数台のクライアントＰＣ１００からのデータ送受信要求に対しても、各々独立してデバイス３００との接続を制御することができる。

＜９． パケットのデータ構成＞
データ送受信用パケットのデータ構成の一例を図８に示す。パケットは、プロトコルヘッダ８００とＵＳＢ転送データ８１０で構成される。通信制御部２０７が、パケットを解析することにより、デバイス３００を判定する。

プロトコルヘッダ８００には、本システムのプロトコルであることを識別するための署名データ８０１、電文サイズ８０２、デバイスサーバ２００に対するコマンドＩＤ８０３（ｂｕｌｋ−ｉｎ転送要求など）、ベンダーＩＤ（ＶＩＤ）８０４、製品ＩＤ（ＰＩＤ）８０５、シリアル番号８０６などが格納される。

このうち、ベンダーＩＤ８０４、製品ＩＤ８０５、シリアル番号８０６によって、デバイス３００を一意に識別することができる。なお、シリアル番号８０６は、図４で説明したように、デバイスサーバ２００がデバイス３００から取得したデバイス情報に記述されたシリアル番号が格納されるが、デバイス情報にシリアル番号が記述されていない場合には、デバイスサーバ２００の有する固有情報と、デバイスサーバ２００の接続ポート固有情報から生成されたシリアル番号が格納される。

＜１０．概略シーケンス＞
図９は、本デバイス制御システムの概略シーケンス図である。なお、この例では、ネットワーク５００上に、デバイスａ３００Ａが接続されたデバイスサーバａ２００Ａと、デバイスｂ３００Ｂが接続されたデバイスサーバｂ２００Ｂが存在し、これらとクライアントＰＣ１００との間でデータ送受信を行なうものとする。

デバイスサーバａ２００Ａは、デバイスａ３００Ａの接続時に、接続されたデバイスａ３００Ａからデバイス情報を取得する（タイミングＴ９０１）。

デバイスａ３００Ａからデバイス情報を取得したデバイスサーバａ２００Ａは、デバイス情報をメモリ２０２に格納する（タイミングＴ９０２）。なお、デバイス情報にシリアル番号が格納されていない場合、デバイスサーバ２００の有する固有情報と、デバイスサーバ２００の接続ポート固有情報からシリアル番号を生成し、当該デバイス情報に追加して格納する。

デバイスサーバａ２００Ａは、クライアントＰＣ１００からデバイス情報の問い合わせがあると（タイミングＴ９０３）、クライアントＰＣ１００に対して、デバイスａ３００Ａのデバイス情報を通知する（タイミングＴ９０４）。

クライアントＰＣ１００では、通知されたデバイス情報を元に、デバイスａ３００Ａを仮想化制御するためのデバイススタックＡ１１０Ａが生成される（タイミングＴ９０５）。

その後、デバイスサーバｂ２００Ｂにデバイスｂ３００Ｂが接続されて、クライアントＰＣ１００においてデバイスｂ３００Ｂの仮想化制御のためのデバイススタックＢ１１０Ｂが生成されるまでの過程（タイミングＴ９０６〜Ｔ９１０）は、前述のタイミングＴ９０１〜Ｔ９０５と同様であるため、説明を省略し、タイミングＴ９１１から説明する。

クライアントＰＣ１００において、デバイススタックＡ１１０Ａのアプリケーションプログラム１１１Ａが実行されると（タイミングＴ９１１）、デバイスサーバａ２００Ａとの間でセッションを開始する（タイミングＴ９１２）。

クライアントＰＣ１００は、セッションが開始されると、デバイスサーバａ２００Ａを介して、デバイスａ３００Ａとの間でデータ送受信が可能となり、デバイススタックＡ１１０Ａを使用してデバイスａ３００Ａを制御することができる（タイミングＴ９１３）。

また、クライアントＰＣ１００において、上記アプリケーションプログラム１１１Ａとは別に、デバイススタックＢ１１０Ｂのアプリケーションプログラム１１１Ｂが実行されると（タイミングＴ９１４）、デバイスサーバｂ２００Ｂに対して、デバイスサーバａ２００Ａとの間のセッションとは別の独立したセッションを開始する（タイミングＴ９１５）。

クライアントＰＣ１００は、このセッションが開始されると、デバイスサーバｂ２００Ｂを介して、デバイスｂ３００Ｂとの間でデータ送受信が可能となり、デバイススタックＢ１１０Ｂを使用してデバイスｂ３００Ｂを制御することができる（タイミングＴ９１６）。

以後、クライアントＰＣ１００とデバイスａ３００Ａとの間では、デバイスサーバａ２００Ａを介して、デバイススタックＡ１１０Ａによるデータ送受信（タイミングＴ９１３）が行われ、クライアントＰＣ１００とデバイスｂ３００Ｂとの間では、デバイスサーバｂ２００Ｂを介して、デバイススタックＢ１１０Ｂによるデータ送受信（タイミングＴ９１６）が行われる、というように、各デバイス３００に対する制御がそれぞれ独立したセッションのもとで実施される。

クライアントＰＣ１００において、デバイススタックＡ１１０Ａのアプリケーションプログラム１１１Ａの実行が終了し、データ送受信が終了した場合は（タイミングＴ９１７）、デバイスサーバａ２００Ａに対するセッションを終了する（タイミングＴ９１８）。

上記デバイスサーバａ２００Ａに対するセッションの終了は、デバイスサーバｂ２００Ｂに対するセッションにはなんら作用せず、クライアントＰＣ１００において、デバイススタックＢ１１０Ｂのアプリケーションプログラム１１１Ｂの使用が続く限り、デバイスサーバｂ２００Ｂに対するセッションは継続される。そして、クライアントＰＣ１００において、デバイススタックＢ１１０Ｂのアプリケーションプログラム１１１Ｂの実行が終了し、データ送受信が終了した場合に（タイミングＴ９１９）、デバイスサーバｂ２００Ｂに対するセッションを終了する（タイミングＴ９２０）。

上述のとおり、クライアントＰＣ１００は、デバイスｂ３００Ｂの使用（データ送受信）が完了しない場合でも、デバイスａ３００Ａの使用（データ送受信）が完了した時点でデバイスサーバａ２００Ａに対するセッションを終了する。これによって、例えば、デバイスｂ３００Ｂの使用（データ送受信）が、頻繁または長時間にわたって必要な場合であっても、デバイスａ３００Ａはそれに作用されることなく使用が終了次第、セッションを終了することが可能となる。

なお、デバイスａ３００Ａの使用（データ送受信）が完了しない場合でも、デバイスｂ３００Ｂの使用（データ送受信）が完了した時点でデバイスサーバｂ２００Ｂに対するセッションを終了できることは言うまでもない。

以上により、クライアントＰＣ１００内には、ネットワーク５００越しに見えているデバイス３００の台数（ｎ台）分だけデバイススタック１１０が生成される。これにより、複数のデバイス３００をそれぞれ独立して制御することが可能となり、本システム内の他のデバイス３００の振る舞いに影響されることなく各デバイスを独立して動作させることが可能となる。

なお、図９において、デバイスサーバａ２００Ａにデバイスａ３００Ａが接続され、デバイスサーバｂ２００Ｂにデバイスｂ３００Ｂが接続される場合について説明したが、図１のように同一のデバイスサーバｂ２００Ｂにデバイスｂ３００Ｂ、デバイスｃ３００Ｃが接続されている場合でも、同様にクライアントＰＣ１００からデバイスｂ３００Ｂ、デバイスｃ３００Ｃを制御することが可能であることはいうまでもない。

実施例２に係る実施の形態について図１０を用いて説明する。本実施例は、図１のデバイスサーバａ２００Ａに替わりに、ネットワークデバイス２５０が接続されており、クライアントＰＣ１００のデバイススタック１１０がネットワークデバイス２５０を介してデバイスａ３００Ａを制御することが特徴である。なお、ネットワークデバイス２５０とは、ネットワーク５００に接続して複数のクライアントＰＣ１００によって共用可能なデバイスであり、例えば、ネットワーク接続ストレージやネットワークプリンタなどの装置であるが、これらの装置に限定されるものではない。

実施例１において図２、図４〜図９を用いて説明した部分は、すべて、デバイスサーバ２００をネットワークデバイス２５０に読み替えることで本実施例に適用可能であるため、詳細な説明を省略する。

図１０は、実施例２に係るデバイス制御システムの概略構成であり、クライアントＰＣ１００（１００Ａ，１００Ｂ）、ネットワークデバイス２５０、デバイスサーバ２００、デバイス３００（３００Ａ，３００Ｂ，３００Ｃ）から構成される。実施例１において図１を用いて説明したデバイス制御システムの構成に対して、デバイスサーバ２００Ａをネットワークデバイス２５０に置き替えた以外は同じであるため詳細な説明を省略する。

図１１は、実施例２に係るネットワークデバイス２５０の内部構成を例示するブロック図である。ネットワークデバイス２５０は、デバイスとしての機能を実行するためのデバイス機能部２５９を備えている点が特徴である。外部記憶部２５５内にデバイス機能部２５９を具備している以外、ＣＰＵ２５１、メモリ２５２、通信部２５３、ＵＳＢ Ｉ／Ｆ２５４、内部バス２５６、通信制御部２５７、デバイス制御部２５８の機能や構成については、実施例１において図３を用いて説明したデバイスサーバ２００のＣＰＵ２０１、メモリ２０２、通信部２０３、ＵＳＢ Ｉ／Ｆ２０４、内部バス２０６、通信制御部２０７、デバイス制御部２０８と同一であるため詳細な説明を省略する。

上述のとおり、本実施例のネットワークデバイス２５０は、デバイスとしての機能（例えば、ネットワークプリンタであれば印刷機能）を実行する他に、実施例１で述べたデバイスサーバ２００と同等の機能を備えることで、クライアントＰＣ１００と自らにＵＳＢ接続されたデバイス３００（例えば、カードリーダ）との間のデータ送受信を制御することもできるようになる。

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

上記では、デバイスサーバ２００またはネットワークデバイス２５０を介してネットワーク共有されたデバイス３００に適用した例について説明したが、これに限らず、クライアントＰＣ１００がデバイスサーバ２００やネットワークデバイス２５０と同様のＵＳＢ Ｉ／Ｆなどのローカルインターフェースを備えることで、クライアントＰＣ１００に直接接続（ローカル接続）されたデバイス３００に対しても本発明を適用可能である。

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

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

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

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

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

１００（１００Ａ，１００Ｂ）：クライアントＰＣ
１０１：ＣＰＵ
１０２：入力部
１０３：表示部
１０４：メモリ
１０５：通信部
１０６：外部記憶部
１０７：内部バス
１０８：ＯＳ
１０９：常駐モジュール
１１０（１１０Ａ，１１０Ｂ，１１０Ｃ）：デバイススタック
１１１（１１１Ａ，１１１Ｂ，１１１Ｃ）：アプリケーションプログラム
１１２（１１２Ａ，１１２Ｂ，１１２Ｃ）：アプリケーション／デバイスドライバインターフェース
１１３（１１３Ａ，１１３Ｂ，１１３Ｃ）：デバイスドライバ
１１４（１１４Ａ，１１４Ｂ，１１４Ｃ）：ＵＳＢクラスドライバ
１１５（１１５Ａ，１１５Ｂ，１１５Ｃ）：ＵＳＢ仮想バスデバイス
１１６：通信制御部
２００（２００Ａ，２００Ｂ）：デバイスサーバ
２０１：ＣＰＵ
２０２：メモリ
２０３：通信部
２０４：ＵＳＢ Ｉ／Ｆ（ＵＳＢインターフェース）
２０５：外部記憶部
２０６：内部バス
２０７：通信制御部
２０８：デバイス制御部
２５０：ネットワークデバイス
２５１：ＣＰＵ
２５２：メモリ
２５３：通信部
２５４：ＵＳＢ Ｉ／Ｆ（ＵＳＢインターフェース）
２５５：外部記憶部
２５６：内部バス
２５７：通信制御部
２５８：デバイス制御部
２５９：デバイス機能部
３００（３００Ａ，３００Ｂ，３００Ｃ）：デバイス
４００：接続ケーブル
５００：ネットワーク

Claims (10)

1. ネットワークを介して接続されたデバイス制御装置にローカル接続されているデバイスを検知するためのデバイス検知手段と、
   前記デバイス検知手段によって検知した前記デバイスのデバイス情報を取得するデバイス情報取得手段と、
   前記デバイス情報取得手段で取得したデバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知手段が接続を検知した前記デバイスの個体毎に生成するデバイススタック生成手段と、
   前記デバイススタック生成手段で生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求手段と、
   前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始するセッション制御手段と、
   前記デバイススタックの各々により、前記セッション制御手段で開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御手段と、
   を備えることを特徴とするクライアント装置。
2. 前記デバイススタック生成手段は、前記ドライバソフトウェア部品を生成後、当該ドライバソフトウェア部品の上位層に、前記アプリケーションソフトウェア部品を起動すること
   を特徴とする請求項１に記載のクライアント装置。
3. 前記デバイススタック生成手段は、前記デバイス情報取得手段で取得した前記デバイス情報から当該デバイスの種類および個体を識別し、当該識別した種類および個体に適合するドライバソフトウェア部品を生成すること
   を特徴とする請求項１に記載のクライアント装置。
4. デバイス制御装置にローカル接続されているデバイスを検知するためのデバイス検知ステップと、
   前記デバイス検知ステップにおいて検知した前記デバイスのデバイス情報を取得するデバイス情報取得ステップと、
   前記デバイス情報取得ステップで取得したデバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知ステップにおいて検知した前記デバイスの個体毎に生成するデバイススタック生成ステップと、
   前記デバイススタック生成ステップにおいて生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求ステップと、
   前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始するセッション制御ステップと、
   前記デバイススタックの各々によって、前記セッション制御ステップで開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御ステップと、
   を備えることを特徴とするデバイス制御方法。
5. 前記デバイススタック生成ステップにおいて、前記ドライバソフトウェア部品を生成後、当該ドライバソフトウェア部品の上位層に、前記アプリケーションソフトウェア部品を起動すること
   を特徴とする請求項４に記載のデバイス制御方法。
6. 前記デバイススタック生成ステップにおいて、前記デバイス情報取得ステップで取得した前記デバイス情報から当該デバイスの種類および個体を識別し、当該識別した種類および個体に適合するドライバソフトウェア部品を生成すること
   を特徴とする請求項４に記載のデバイス制御方法。
7. クライアント装置と、前記クライアント装置とネットワークを介して接続されたデバイス制御装置と、前記デバイス制御装置とローカル接続されたデバイスからなるデバイス制御システムであって、
   前記クライアント装置は、
   前記デバイス制御装置を介して前記デバイスを検知するためのデバイス検知手段と、
   前記デバイス検知手段によって検知した前記デバイスのデバイス情報を取得する第１のデバイス情報取得手段と、
   前記第１のデバイス情報取得手段で取得した前記デバイス情報に基づき、当該デバイス情報によって識別したデバイスとのデータ送受信に必要なドライバソフトウェア部品を生成し、当該生成したドライバソフトウェア部品と当該デバイスを制御するためのアプリケーションソフトウェア部品とから成るデバイススタックを、前記デバイス検知手段が接続を検知した前記デバイスの個体毎に生成するデバイススタック生成手段と、
   前記デバイススタック生成手段で生成された前記デバイススタックの各々からの接続要求を前記デバイス制御装置に送信する接続要求手段と、
   前記接続要求を送信したデバイススタックの各々と当該接続要求を受信したデバイス制御装置との間で独立したセッションを開始する第１のセッション制御手段と、
   前記デバイススタックの各々により、前記第１のセッション制御手段で開始したセッションを介して、前記デバイスの各個体を独立して制御するデバイス制御手段と、を備え、
   前記デバイス制御装置は、
   前記デバイスからデバイス情報を取得する第２のデバイス情報取得手段と、
   前記第２のデバイス情報取得手段で取得した前記デバイス情報を前記クライアント装置へ送信するデバイス情報送信手段と、
   前記クライアント装置で生成された前記デバイススタックの各々からの接続要求に応じて、当該デバイススタックの各々との間で独立したセッションを開始する第２のセッション制御手段と、
   を備えることを特徴とするデバイス制御システム。
8. 前記クライアント装置のデバイススタック生成手段は、前記ドライバソフトウェア部品を生成後、当該ドライバソフトウェア部品の上位層に、前記アプリケーションソフトウェア部品を起動すること
   を特徴とする請求項７に記載のデバイス制御システム。
9. 前記クライアント装置のデバイススタック生成手段は、前記デバイス情報取得手段で取得した前記デバイス情報から当該デバイスの種類および個体を識別し、当該識別した種類および個体に適合するドライバソフトウェア部品を生成すること
   を特徴とする請求項７に記載のデバイス制御システム。
10. 前記デバイス制御装置は、
    前記第２のデバイス情報取得手段で取得したデバイス情報に、当該デバイスの個体を識別可能なシリアル情報が含まれるか否かを判別するシリアル情報有無判別手段と、
    前記シリアル情報有無判別手段が、前記シリアル情報が含まれないと判別した場合、前記デバイス制御装置の固有情報をもとに個体識別番号を生成し、当該生成した個体識別番号を前記第２のデバイス情報取得手段で取得したデバイス情報に追加するシリアル情報追加手段と、
    前記第２のデバイス情報取得手段で取得した前記デバイス情報、または、前記シリアル情報追加手段で生成した個体識別番号を追加したデバイス情報のいずれかを前記クライアント装置へ送信するデバイス情報送信手段と、を更に備えること
    を特徴とする請求項７に記載のデバイス制御システム。

Images