JP5581470B2 - デバイス共有システム、デバイス共有サーバ、デバイス共有クライアント、およびデバイス共有方法 - Google Patents

Description

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

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

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

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

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

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

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

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

しかしながら、デバイスが、プリント機能の他にスキャン機能やストレージ機能などを兼ね備えた多機能周辺機器（ＭＦＰ：Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である場合、デバイスが備える各々の機能が相互作用を及ぼすことがある。

具体的には、プリンタ機能やスキャン機能などは、その機能を使用したいときだけクライントＰＣからデバイスに対してセッション接続制御（いわゆる、シームレス制御）をすれば済むにも関わらず、常にトラフィックが発生するストレージ機能に作用されて、ＭＦＰを接続シミュレートする際に、常時接続が必要となり、プリンタ機能やスキャン機能のシームレス制御ができなかった。

また、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）デバイスを対象とした従来の接続シミュレート手段では、複数の機能を備えたＵＳＢデバイスであっても、同時に接続可能なセッションは一つである。従って、ＵＳＢデバイスの具備する複数機能を使用できるのは一つのクライアントＰＣのみであり、このクライアントＰＣの使用（セッション）が終了しないと他のクライアントＰＣは当該ＵＳＢデバイスを使用することはできない。

このことは、例えば、プリント機能、スキャン機能、ストレージ機能をあわせ持ったＭＦＰを接続シミュレートする際に、あるクライアントＰＣのユーザがプリント機能しか使用していない状況でも、他のクライアントＰＣのユーザはスキャン機能とストレージ機能を利用することができないことを意味する。これは、前述の特許文献１に開示されたネットワークファイル管理システムでは解決できない課題であった。

上記問題に鑑みて、本発明は、ストレージやプリンタなどのデバイス（周辺機器）をネットワーク上の複数のクライアントＰＣで共用する場合、ユーザに手動操作を強いることなく、必要なときだけデバイスにアクセスするように制御する手段を提供することを目的とする。

また、本発明は、複数の機能を備えたデバイスに対し、各機能ごとにネットワークを介したデータ入出力に使用するプロトコルを使い分けることによって、各々のデバイスの相互作用を排除することを目的とする。

また、本発明は、複数のクライアントＰＣから複数の機能を備えたデバイスの各機能を独立して使用可能にすることを目的とする。

上記の課題を解決するために、請求項１に記載のデバイスサーバは、ネットワークを介して接続されたクライアントと、自身にローカル接続又は内蔵されたデバイスとの間のデータ通信を制御するデバイスサーバであって、前記デバイスからデバイス情報を取得する情報取得手段と、前記情報取得手段で取得したデバイス情報に基づいて前記デバイスが備える各機能をそれぞれ管理し、前記機能を使用するためのプロトコルを前記機能ごとにそれぞれ設定するデバイス管理手段と、前記クライアントからのセッション要求を受信するセッション要求受信手段と、前記セッション要求受信手段で受信したセッション要求に基づき、前記デバイスの機能ごとに独立したセッションを介して、前記機能ごとに対応したプロトコルによるデータ通信を制御するセッション制御手段と、を備えることを特徴とする。

また、上記の課題を解決するために、請求項４に記載のクライアントは、デバイスサーバにローカル接続又は内蔵されたデバイスとの間でネットワークを介してデータ通信を行うクライアントであって、前記デバイスサーバから前記デバイスのデバイス情報と前記デバイスの有する機能ごとに設定されたプロトコルの情報を取得する情報取得手段と、前記情報取得手段で取得した前記デバイス情報に基づいて、前記デバイスを直接接続しているように制御するためのドライバソフトウェア群を生成するデバイス仮想化手段と、前記デバイスと前記デバイスの有する機能を指定する機能指定手段と、前記機能指定手段で指定されたデバイスと機能に基づいて、当該機能に応じたドライバソフトウェア群を指定するドライバソフトウェア群指定手段と、前記ドライバソフトウェア群指定手段で指定されたドライバソフトウェア群を使用して、当該機能を実行させるための命令・データを生成する命令・データ生成手段と、前記ドライバソフトウェア群指定手段で指定されたドライバソフトウェア群に対応したプロトコルによるデータ通信のためのセッションを介して前記命令・データに基づくデータ入出力を制御する通信制御手段と、を備えることを特徴とする。

また、上記の課題を解決するために、請求項５に記載のデバイスサーバにおけるデバイス共有方法は、ネットワークを介して接続されたクライアントと、自身にローカル接続又は内蔵されたデバイスとの間のデータ通信を制御するデバイスサーバにおけるデバイス共有方法であって、情報取得手段が前記デバイスからデバイス情報を取得する情報取得ステップと、デバイス管理手段が前記情報取得ステップで取得したデバイス情報に基づいて前記デバイスが備える各機能をそれぞれ管理し、前記機能を使用するためのプロトコルを前記機能ごとにそれぞれ設定するデバイス管理ステップと、セッション要求受信手段が前記クライアントからのセッション要求を受信するセッション要求受信ステップと、セッション制御手段が前記セッション要求受信ステップで受信したセッション要求に基づき、前記デバイスの機能ごとに独立したセッションを介して、前記機能ごとに対応したプロトコルによるデータ通信を制御するセッション制御ステップと、を有することを特徴とする。

また、上記の課題を解決するために、請求項８に記載のクライアントにおけるデバイス共有方法は、デバイスサーバにローカル接続又は内蔵されたデバイスとの間でネットワークを介してデータ通信を行うクライアントにおけるデバイス共有方法であって、情報取得手段が前記デバイスサーバから前記デバイスのデバイス情報と前記デバイスの有する機能ごとに設定されたプロトコルの情報を取得する情報取得ステップと、デバイス仮想化手段が前記情報取得ステップで取得した前記デバイス情報に基づいて、前記デバイスを直接接続しているように制御するためのドライバソフトウェア群を生成するデバイス仮想化ステップと、機能指定手段が前記デバイスと前記デバイスの有する機能を指定する機能指定ステップと、ドライバソフトウェア群指定手段が前記機能指定ステップで指定されたデバイスと機能に基づいて、当該機能に応じたドライバソフトウェア群を指定するドライバソフトウェア群指定ステップと、命令・データ生成手段がドライバソフトウェア群指定ステップで指定された機能に基づいて、前記デバイス仮想化ステップで生成したドライバソフトウェア群を使用して、当該機能を実行させるための命令・データを生成する命令・データ生成ステップと、通信制御手段が前記ドライバソフトウェア群指定ステップで指定された機能に対応したプロトコルによるデータ通信のためのセッションを介して前記命令・データ生成ステップで生成された命令・データに基づくデータ入出力を制御する通信制御ステップと、を有することを特徴とする。

本発明によれば、複数の機能を備えたデバイスに対し、各機能が相互作用を及ぼすことなく独立して制御することが可能となる。これによって、例えば、プリント機能、スキャン機能、ストレージ機能をあわせ持ったＭＦＰに対して、１台のクライアントＰＣから接続シミュレートしてプリント機能とストレージ機能を同時使用する場合には、ストレージ機能だけを常時接続し、プリント機能については常時接続を必要としないシームレス制御ができるようになる。

また、本発明によれば、複数の機能を備えたデバイスに対し、複数のクライアントＰＣから別々の機能を独立して使用することが可能となる。これによって、例えば、プリント機能、スキャン機能、ストレージ機能をあわせ持ったＭＦＰに対して、複数のクライアントＰＣ（例えば、ＰＣ１、ＰＣ２、ＰＣ３）から同時に接続シミュレートして、ＰＣ１がプリント機能を、ＰＣ２がスキャン機能を、ＰＣ３がストレージ機能を、というように、ＭＦＰが備える個々の機能を独立して制御できるようになる。

本発明に係るデバイス共有システムの概略構成を示す図である。 図１に示したクライアントＰＣ１００の内部構成を例示するブロック図である。 図１に示したサーバ２００の内部構成を例示するブロック図である。 デバイスサーバ２００におけるデバイス３００接続時の制御について説明するフローチャートである。 実施例１に係るデバイス機能ツリーを例示する図である。 クライアントＰＣ１００におけるデバイス３００の仮想制御について説明するフローチャートである。 クライアントＰＣ１００におけるアプリケーションプログラム１０９の制御について説明するフローチャートである。 デバイスサーバ２００におけるクライアントＰＣ１００からの接続時の制御について説明するフローチャートである。 実施例1に係るパケットのデータ構成を例示する図である。 本発明に係るデバイス共有システムにおいて、１台のクライアントＰＣ１００がデバイス制御する場合の過程を説明するシーケンス図である。 本発明に係るデバイス共有システムにおいて、２台のクライアントＰＣ１００がデバイス制御する場合の過程を説明するシーケンス図である。 実施例２に係るデバイス機能ツリーを例示する図である。 実施例２に係るパケットのデータ構成を例示する図である。

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

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

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

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

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

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

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

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

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

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

通信部１０５は、Ｅｔｈｅｒｎｅｔ（登録商標）のような有線ネットワーク、若しくは、ＩＥＥＥ８０２．１１ａやＩＥＥＥ８０２．１１ｇのような無線ネットワークなど、ネットワーク５００に対応したネットワークパケットによる送受信や通信制御を行うためのインターフェースであり、デバイスサーバ２００とデータ通信を行うことで、クライアントＰＣ１００から入出力データを送受信することが可能となる。

外部記憶部１０６には、ＯＳ１０８、アプリケーションプログラム１０９、常駐モジュール１１０、デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３、通信制御部１１４を備えたソフトウェアプログラムを格納する。外部記憶部１０６に格納されたこれらのソフトウェアプログラムは、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行される。

デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３は、常駐モジュール１１０からデバイス３００のデバイス情報を取得、登録することにより、動的に生成されるドライバソフトウェア部品である。

アプリケーションプログラム１０９は、上記の各ドライバソフトウェア部品が生成された後、デバイス３００に対して、デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３を介して、通信制御部１１４にデータの入出力を要求するアプリケーションソフトウェア部品である。

では、常駐モジュール１１０、デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３、通信制御部１１４の詳細について順に説明する。

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

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

ＵＳＢクラスドライバ１１２は、プラグアンドプレイイベントを生成し、また、制御コマンドを送受信するためのＵＳＢポートを作成するとともに、その上位にデバイスドライバ１１１をロードする。さらに、デバイスドライバ１１１で生成される制御コマンドをＵＳＢパケットに変換し、ＵＳＢパケットを制御コマンドに変換するソフトウェアである。

ＵＳＢ仮想バスデバイス１１３は、アプリケーションプログラム１０９からデバイスドライバ１１１、ＵＳＢクラスドライバ１１２を介して要求されるデバイス３００へのデータ入出力に対して、デバイス３００がクライアントＰＣ１００に直結しているときと同様の振る舞いを提供する仮想制御ソフトウェアである。

通信制御部１１４は、ＵＳＢ仮想バスデバイス１１３から要求されるデータ入出力について、通信部１０５を介してデバイスサーバ２００と送受信するソフトウェアである。ＵＳＢ仮想バスデバイス１１３からデータ入出力を要求された場合、デバイス３００のアドレスに対してセッションを接続し、通信を行う。通信が完了した場合、セッションを切断する。

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

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

外部記憶部２０５は、情報取得部２０７、デバイス管理部２０８、クライアント制御部２０９、セッション制御部２１０を備えるソフトウェア機能部である。

情報取得部２０７は、デバイス３００からＵＳＢ Ｉ／Ｆ２０４を介して後述するデバイス識別情報と機能識別情報を取得する機能部である。

デバイス管理部２０８は、情報取得部２０７が取得したデバイス識別情報と機能識別情報に基づいて、デバイス３００を管理する機能部である。

クライアント制御部２０９は、クライアントＰＣ１００からの要求に応じて、デバイス管理部２０８が管理するデバイス３００のデバイス識別情報と機能識別情報を、クライアントＰＣ１００に対して通知し、クライアントＰＣ１００からのデータ入出力要求（セッション要求）を受け付ける機能部である。

セッション制御部２１０は、クライアント制御部２０９が受け付けたデータ入出力要求（セッション要求）に応じてデバイス３００とのセッションを制御する機能部である。

上述した情報取得部２０７とデバイス管理部２０８によって、クライアントＰＣ１００から受信するデータの入出力要求に対して、プロトコル上に指定されているデバイス３００を識別するための情報とデバイス３００が具備する各機能の情報を判定し、クライアントＰＣ１００がデータ入出力を求めるデバイス３００および機能を特定する。これによって、１台または複数台のデバイス３００との間のＵＳＢ Ｉ／Ｆ２０４を介したデータ入出力の制御が可能となる。

また、上述したクライアント制御部２０９とセッション制御部２１０によって、１台または複数台のクライアントＰＣ１００との間のネットワーク５００を介したデータ入出力の制御が可能となる。デバイス３００が複数の機能を実装している場合、各機能をネットワーク上で独立して通信させるために、各機能に固有のＴＣＰセッションを受け付ける。ＰＣ１００Ａがデバイス３００の機能ａを制御し、ＰＣ１００Ｂがデバイス３００の機能ｂを制御する場合、機能ａをセッションａ、機能ｂをセッションｂで接続を受け付けることにより、独立してデータ入出力することを可能にする。なお、一つのＰＣ１００Ａからデバイス３００の複数の機能を制御する場合は、複数セッションは勿論のこと、単一セッションでもプロトコルの内容を判定することにより機能ａ、機能ｂを独立して制御できる。

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

また、デバイスサーバ２００、デバイス３００をそれぞれ別体の装置として説明したが、これに限定されるものではなく、デバイスサーバ２００をデバイス３００のケーシング内に収まるように一体構造としても良い。

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

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

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

次に、情報取得部２０７は、デバイス３００からＵＳＢ Ｉ／Ｆ２０４を介してデバイス３００が具備する機能識別情報を取得し、メモリ２０２に格納する（ステップＳ４０２）。ここで、機能識別情報とは、機能番号（インタフェース番号）、データの送受信先を示すエンドポイントアドレスなどである。また、デバイス３００が複数の機能を備えている場合には、全ての機能識別情報を取得するまで処理を繰り返し、取得した機能識別情報をメモリ２０２に格納する。なお、複数のデバイス３００が接続された場合には、ここで再びステップＳ４０１に戻り、ステップＳ４０１、ステップＳ４０２の処理を繰り返すことになる。

続いて、デバイス管理部２０８は、デバイス３００から取得してメモリ２０２に格納したデバイス識別情報と機能識別情報に基づいて、デバイス機能ツリー（図５で詳述）を作成し、記憶する（ステップＳ４０３）。

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

クライアント制御部２０９は、クライアントＰＣ１００からデバイス識別情報および機能識別情報の問い合わせがあるとデバイス管理部２０８に通知し（ステップＳ４０４でＹｅｓ）、デバイス管理部２０８は、デバイス機能ツリーを検索して、デバイスサーバ２００に接続されているデバイス３００のデバイス識別情報と機能識別情報を特定する（ステップＳ４０５）。

そして最後に、クライアント制御部２０９が、特定したデバイス識別情報と機能識別情報をクライアントＰＣ１００に通知して処理を終了する（ステップＳ４０６）。これによって、クライアントＰＣ１００は、デバイスサーバ２００に接続されているデバイス３００のデバイス識別情報と機能識別情報を取得することができる。

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

＜６．デバイス機能ツリー＞
次に、図４のステップＳ４０３において、デバイス管理部２０８で作成、記憶されるデバイス機能ツリーについて説明する。デバイス機能ツリーは、装着されたデバイス数を頂点として、第１階層であるデバイス識別情報と、第２階層である機能識別情報から構成される。

図５は、デバイス機能ツリーの一例である。この例は、デバイスサーバ２００に２台のデバイス３００が接続された場合を示している。従って、装着されたデバイス数５１０には値＝２が設定され、デバイス識別情報５２０，５４０と、機能識別情報５３０，５５０を有する。

デバイス識別情報５２０、５４０は、デバイスを一意に識別する識別情報とデバイスの持つ機能数から構成される。

この例では、識別情報として、ベンダーＩＤ（ＶＩＤ）、製品ＩＤ（ＰＩＤ）、シリアル番号、デバイス名称を保持し、また、デバイス識別情報５２０は機能数＝２を、デバイス識別情報５４０は機能数＝１を保持していることを示している。

機能識別情報５３０、５５０は、各デバイスの持つ機能を識別でき、機能を制御するのに必要な情報である。ここでは、機能番号とエンドポイント数、エンドポイントであり、上位階層であるデバイス識別情報５２０、５４０に設定された機能数に応じた数の機能番号とエンドポイント数を保持し、エンドポイント数に対応するエンドポイントを保持する。

このように、デバイス機能ツリーは、どのデバイスのどの機能を使用できるかを検索できるように構成され、クライアントＰＣ１００からデバイスサーバ２００に問い合わせがあった場合に、デバイス機能ツリーを検索して、デバイス識別情報と機能識別情報を特定し、それらをクライアントＰＣ１００へ通知するために使用される。

また、クライアントＰＣ１００からリクエストがあったデバイス／機能、およびデバイス３００との通信に使用するエンドポイントを特定するために使用される。

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

クライアントＰＣ１００内の常駐モジュール１１０は、デバイスサーバ２００を介してネットワーク５００に接続されたデバイス３００を知るために、通信部１０５を介して、デバイスサーバ２００に対して検索パケットをブロードキャストする（ステップＳ６０１）。

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

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

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

その後、アプリケーションプログラム１０９を起動し、アプリケーションプログラム１０９からドライバソフトウェア部品を制御するためのインタフェース（アプリケーション／ドライバインタフェース）を起動して処理を終了する（ステップＳ６０８）。このようにして、クライアントＰＣ１００内においてデバイス３００の仮想制御が実行される。

＜８．アプリケーションプログラム１０９実行時の制御＞
次に、この仮想制御下において、アプリケーションプログラム１０９が、クライアントＰＣ１００とデバイス３００が直結されたのと同等の状態で仮想化されたドライバソフトウェア部品（デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３）および通信制御部１１４を使ってデバイス３００とデータ入出力を行う際の制御について図７を用いて説明する。

アプリケーションプログラム１０９は、特定のデバイス３００との入出力が必要と判断した場合、通信制御部１１４を介してデバイスサーバ２００とＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを開始する（ステップＳ７０１）。このとき、アプリケーションプログラム１０９は、デバイスサーバ２００から取得したデバイス３００のデバイス識別情報と機能識別情報に基づいて、セッションに使用するプロトコルを選択する。

プロトコルの選択とは、すなわち、どのデバイス３００のどの機能、エンドポイントに対してデータ入出力を行なうかを指定することである。アプリケーションプログラム１０９で実行された処理内容に基づき、データ入出力にどのドライバソフトウェア部品（デバイスドライバ１１１、ＵＳＢクラスドライバ１１２、ＵＳＢ仮想バスデバイス１１３）を使用するかが決まることによって、プロトコル（デバイス，機能，エンドポイント）が選択される。

デバイスサーバ２００との接続に失敗した場合（ステップＳ７０２でＮｏ）は、処理を終了する。

デバイスサーバ２００との接続に成功した場合（ステップＳ７０２でＹｅｓ）、デバイスサーバ２００にネットワーク５００を介して、ＵＳＢデータを送受信する（ステップＳ７０３）。

そして、すべてのＵＳＢデータの送受信が終了するまで、ステップＳ７０３が繰り返される（ステップＳ７０４でＮｏ）。

すべてのＵＳＢデータの送受信が終了すると（ステップＳ７０４でＹｅｓ）、デバイスサーバ２００とのＴＣＰセッションを切断して処理を終了する（ステップＳ７０５）。

＜９．デバイスサーバ２００におけるクライアントＰＣ１００からの接続時の制御＞
次に、この仮想制御下における、デバイスサーバ２００の制御について図８を用いて説明する。デバイスサーバ２００は、クライアントＰＣ１００からデータ入出力を要求してきたプロトコル（デバイス，機能，エンドポイントの指定）の内容から、図５に示すようなデバイス機能ツリーを用いて、使用するデバイスおよび機能を特定して、該当するエンドポイントと通信を行う制御を行なう。

クライアント制御部２０９は、クライアントＰＣ１００からのデータ入出力要求に対してセッションを開始する（ステップＳ８０１）。次に、クライアント制御部２０９は、クライアントＰＣ１００からデータ入出力を要求してきたパケットを解析して、プロトコルを判定する（ステップＳ８０２）。パケットのデータ構造は図９で詳述する。なお、ここでは、データ入出力に使用可能なプロトコルを、プロトコルａ，ｂの２種類であるものとする。

ステップＳ８０２において、クライアントＰＣ１００からデータ入出力を要求してきたパケットがプロトコルａ，ｂのどちらでもない場合には、クライアント制御部２０９は、エラーと判断してクライアントＰＣ１００に対してエラー通知を行なう（ステップＳ８０３）。

クライアントＰＣ１００からデータ入出力を要求してきたパケットがプロトコルａの場合には、クライアント制御部２０９は、デバイス機能ツリーでデバイス３００と機能（ここでは機能ａ）を特定し、セッション制御部２１０が、機能ａに該当するエンドポイントと通信を行う（ステップＳ８０４）。

一方、クライアントＰＣ１００からデータ入出力を要求してきたパケットがプロトコルｂの場合には、クライアント制御部２０９は、デバイス機能ツリーでデバイス３００と機能（ここでは機能ｂ）を特定し、セッション制御部２１０が、機能ｂに該当するエンドポイントと通信を行う（ステップＳ８０５）。

ステップＳ８０３〜ステップＳ８０５のいずれかの処理を終えるとセッションを終了する（ステップＳ８０６）。

＜１０．パケットのデータ構成＞
実施例１のセッションに用いられるパケットのデータ構成の一例を図９に示す。パケットは、プロトコルヘッダ９００とＵＳＢ転送データ９１０で構成される。クライアント制御部２０９が、パケットを解析することにより、プロトコル（デバイス，機能，エンドポイント）を判定する。

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

このうち、ベンダーＩＤ９０４、製品ＩＤ９０５、シリアル番号９０６によって、デバイス３００を一意に識別することができる。また、機能番号９０７およびエンドポイント９０８によって、機能を一意に識別することができる。

＜１１．概略シーケンス（クライアントＰＣ１００が１台の場合）＞
図１０は、本デバイス共有システムの概略シーケンス図である。

デバイスサーバ２００は、デバイス３００装着時に、装着されたデバイス３００からデバイス情報を取得する。デバイス情報には、デバイス３００の個体を識別するための情報（デバイス識別情報）と、デバイス３００が具備する機能（この例では機能ａ／機能ｂの２つ）を識別するための情報（機能識別情報）が含まれる（タイミングＴ１００１）。

デバイス３００からデバイス情報を取得したデバイスサーバ２００は、デバイス機能ツリーを作成する。デバイス３００が具備する機能毎に、セッションで使用するプロトコルを決定して保存する（タイミングＴ１００２）。この例では、機能ａに対してプロトコルａが、機能ｂに対してプロトコルｂが設定される。

ＰＣ１００Ａから、デバイス情報の問い合わせがあると（タイミングＴ１００３）、デバイスサーバ２００は、ＰＣ１００Ａに対して、デバイス３００のデバイス情報（機能毎に決定されたプロトコルの情報を含む）を通知する（タイミングＴ１００４）。

ＰＣ１００Ａでは、通知されたデバイス情報を元に、デバイス３００がＵＳＢで直結されたのと同等の環境を提供するための仮想化処理が行われる（タイミングＴ１００５）。

ＰＣ１００Ａ上でデバイス３００の機能ａを使用するアプリケーションａが実行されると（タイミングＴ１００６）、アプリケーションａは、機能ａに対応したプロトコルａを使用することを判断（指定）して、デバイスサーバ２００およびデバイス３００に対して、プロトコルａによるセッションを開始する（タイミングＴ１００７）。

ＰＣ１００Ａは、セッションが開始されると、デバイス３００との間でプロトコルａによるデータ入出力を実施し、デバイス３００の機能ａを使用する（タイミングＴ１００８）。

ＰＣ１００Ａ上で、デバイス３００の機能ｂを使用する別のアプリケーションｂが実行されると（タイミングＴ１００９）、アプリケーションｂは、機能ｂに対応したプロトコルｂを使用することを判断（指定）して、デバイスサーバ２００およびデバイス３００に対して、プロトコルｂによるセッションを開始する（タイミングＴ１０１０）。

ＰＣ１００Ａは、セッションが開始されると、デバイス３００との間でプロトコルｂによるデータ入出力を実施し、デバイス３００の機能ｂを使用する（タイミングＴ１０１１）。

以後、ＰＣ１００Ａとデバイス３００との間では、デバイスサーバ２００を介して、プロトコルａによるデータ入出力（タイミングＴ１０１２）とプロトコルｂによるデータ入出力（不図示）とがそれぞれ独立したセッションのもとで実施される。

ＰＣ１００Ａにおいて、アプリケーションＡによる機能ａの使用が終了し、プロトコルａによる入出力が終了した場合は（タイミングＴ１０１３）、デバイス３００の機能ａに対するセッションを終了する（タイミングＴ１０１４）。

上記機能ａに対するセッションの終了は、デバイス３００の機能ｂに対するセッションにはなんら作用せず、ＰＣ１００Ａにおいて、アプリケーションＢによる機能ｂの使用が続く限り、機能ｂに対するセッションは継続される（タイミングＴ１０１５）。そして、ＰＣ１００Ａにおいて、アプリケーションＢによる機能ｂの使用が終了し、プロトコルｂによる入出力が終了した場合に（タイミングＴ１０１６）、デバイス３００の機能ｂに対するセッションが終了する（タイミングＴ１０１７）。

上述のとおり、ＰＣ１００Ａは、機能ｂの使用（プロトコルｂによる入出力）が完了しない場合でも、機能ａの使用（プロトコルａによる入出力）が完了した時点で機能ａに対するセッションを終了できる。これによって、例えば、機能ｂの使用（プロトコルｂによる入出力）が、頻繁または長時間にわたって必要な場合であっても、機能ａはそれに作用されることなく使用が終了次第、セッションを解放することが可能となる。

なお、機能ａの使用（プロトコルａによる入出力）が完了しない場合でも、機能ｂの使用（プロトコルｂによる入出力）が完了した時点で機能ｂに対するセッションを終了できることは言うまでもない。

＜１２．概略シーケンス（クライアントＰＣ１００が複数台の場合）＞
図１１は、機能ａ、機能ｂを具備したデバイス３００をデバイスサーバ２００に接続して、ＰＣ１００ＡとＰＣ１００Ｂが制御する場合の概略シーケンス図である。

デバイスサーバ２００は、デバイス３００装着時に、装着されたデバイス３００からデバイス情報を取得する。デバイス情報には、デバイス３００の個体を識別するための情報（デバイス識別情報）と、デバイス３００が具備する機能（この例では機能ａ／機能ｂの２つ）を識別するための情報（機能識別情報）を取得する（タイミングＴ１１０１）。

デバイス３００からデバイス情報を取得したデバイスサーバ２００は、デバイス機能ツリーを作成する。デバイス３００が具備する機能毎に、セッションで使用するプロトコルを決定して保存する（タイミングＴ１１０２）。この例では、機能ａに対してプロトコルａが、機能ｂに対してプロトコルｂが設定される。

ＰＣ１００Ａ，Ｂから、デバイス情報の問い合わせがあると（タイミングＴ１１０３，Ｔ１１０６）、デバイスサーバ２００は、ＰＣ１００Ａ，Ｂに対して、デバイス３００のデバイス情報（機能毎に決定されたプロトコルの情報を含む）を通知する（タイミングＴ１１０４，Ｔ１１０７）。

ＰＣ１００Ａ，Ｂでは、通知されたデバイス情報を元に、デバイス３００がＵＳＢで直結されたのと同等の環境を提供するための仮想化処理が行われる（タイミングＴ１１０５，Ｔ１１０８）。

ＰＣ１００Ａ上でデバイス３００の機能ａを使用するアプリケーションａが実行されると（タイミングＴ１１０９）、アプリケーションａは、機能ａに対応したプロトコルａを使用することを判断（指定）して、デバイスサーバ２００およびデバイス３００に対して、プロトコルａによるセッションを開始する（タイミングＴ１１１０）。

ＰＣ１００Ａは、セッションが開始されると、デバイス３００との間でプロトコルａによるデータ入出力を実施し、デバイス３００の機能ａを使用する（タイミングＴ１１１１）。

同様に、ＰＣ１００Ｂ上でデバイス３００の機能ｂを使用するアプリケーションｂが実行されると（タイミングＴ１１１２）、アプリケーションｂは、機能ｂに対応したプロトコルｂを使用することを判断（指定）して、デバイスサーバ２００およびデバイス３００に対して、プロトコルｂによるセッションを開始する（タイミングＴ１１１３）。

ＰＣ１００Ｂは、セッションが開始されると、デバイス３００との間でプロトコルｂによるデータ入出力を実施し、デバイス３００の機能ｂを使用する（タイミングＴ１１１４）。

以後、ＰＣ１００Ａとデバイス３００との間では、デバイスサーバ２００を介して、プロトコルａによるデータ入出力（タイミングＴ１１１５）が、また、ＰＣ１００Ｂとデバイス３００との間では、デバイスサーバ２００を介して、プロトコルｂによるデータ入出力（タイミングＴ１１１６）とがそれぞれ独立したセッションのもとで実施される。

ＰＣ１００Ａにおいて、アプリケーションＡによる機能ａの使用が終了し、プロトコルａによる入出力が終了した場合は（タイミングＴ１１１７）、デバイス３００の機能ａに対するセッションを終了する（タイミングＴ１１１８）。

同様に、ＰＣ１００Ｂにおいて、アプリケーションＢによる機能ｂの使用が終了し、プロトコルｂによる入出力が終了した場合は（タイミングＴ１１１９）、デバイス３００の機能ｂに対するセッションを終了する（タイミングＴ１１２０）。

以上により、デバイス３００の具備する機能ａ、機能ｂがＰＣ１００Ａ、ＰＣ１００Ｂから独立して制御することが可能となる。

実施例２に係る実施の形態を説明する。本実施例では、デバイス機能ツリーに、エンドポイントＩＤを追加し、クライアントＰＣ１００からデバイスサーバ２００へ送信するパケットのプロトコルヘッダにこのエンドポイントＩＤを記述することで、クライアントＰＣ１００がデータ入出力を要求するデバイス，機能，エンドポイントを特定してセッションを制御する。

なお、図１〜図４、図６〜８、図１０および図１１を用いて説明した実施例１の構成は、実施例２でも同様に適用可能であるので、詳細な説明を省略し、相違点についてのみ説明する。

＜１３．実施例２におけるデバイス機能ツリー＞
図４のステップＳ４０３で作成されるデバイス機能ツリーについて説明する。デバイス機能ツリーは、装着されたデバイス数を頂点として、第１階層であるデバイス識別情報と、第２階層である機能識別情報で構成される点は、実施例１と同様である。

図１２は、デバイス機能ツリーの一例である。この例は、デバイスサーバ２００に２台のデバイス３００が接続された場合を示している。従って、装着されたデバイス数１２１０には値＝２が設定され、デバイス識別情報１２２０，１２４０と、機能識別情報１２３０，１２５０を有する。

デバイス識別情報１２２０、１２４０は、デバイス３００を一意に識別する情報と当該デバイス３００の持つ機能数から構成される。

この例では、デバイス３００を一意に識別する情報として、ベンダーＩＤ（ＶＩＤ）、製品ＩＤ（ＰＩＤ）、シリアル番号、デバイス名称を保持し、また、デバイス識別情報１２２０は機能数＝２を、デバイス識別情報１２４０は機能数＝１を保持していることを示している。

機能識別情報１２３０、１２５０は、各デバイス３００の持つ機能を識別でき、機能を制御するのに必要な情報である。ここでは、機能番号とエンドポイント数、エンドポイントであり、上位階層であるデバイス識別情報１２２０、１２４０に設定された機能数に応じた数の機能番号とエンドポイント数を保持し、エンドポイント数に対応するエンドポイントを保持する。さらに、実施例２のデバイス機能ツリーでは、各エンドポイントを識別するためのエンドポイントＩＤを保持する。

このように、デバイス機能ツリーは、どのデバイス３００のどの機能を使用できるかを検索できるように構成され、クライアントＰＣ１００からデバイスサーバ２００に問い合わせがあった場合に、デバイス機能ツリーを検索して、デバイス識別情報と機能識別情報を特定し、それらをクライアントＰＣ１００へ通知するために使用される。

また、クライアントＰＣ１００からリクエストがあったデバイス３００の個体と機能、およびデバイス３００との通信に使用するエンドポイントを特定するために使用される。

＜１４．実施例２におけるパケットのデータ構成＞
実施例２のセッションに用いられるパケットのデータ構成の一例を図１３に示す。実施例１と同様、パケットは、プロトコルヘッダ１３００とＵＳＢ転送データ１３１０で構成されるが、プロトコルヘッダ１３００には、署名データ１３０１、電文サイズ１３０２、コマンドＩＤ１３０３の他に、エンドポイントＩＤ１３０４だけが格納される点が本実施例のパケットの特徴である。

以上の通り、実施例２のシステムでは、エンドポイントＩＤ１３０４によって、デバイス３００の個体と機能、使用するエンドポイントまでを一意に識別することができる。

なお、エンドポイントＩＤ１３０４は、エンドポイントを識別するために専用のＩＤを設定してもよいが、それ以外に、ＴＣＰポート番号やＩＰアドレスなどの情報を流用してもよい。このように構成した場合には、パケットのＴＣＰヘッダ（不図示）に記述されたＩＰアドレスやＴＣＰポート番号などから、ＴＣＰ／ＩＰレベルでプロトコルを判別することが可能であるので、プロトコルヘッダ１３００内にエンドポイントＩＤ１３０４を含める必要はない。デバイスサーバ２００は、クライアントＰＣ１００から受信したパケットのＴＣＰヘッダを参照し、そこに記述されたＩＰアドレスやＴＣＰポート番号などと、デバイス機能ツリーのエンドポイントＩＤとを照合することで、デバイス３００の個体と機能、使用するエンドポイントを一意に識別することができる。

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

デバイス管理部２０８で作成、記憶される情報は、デバイス３００の個体を識別し、さらにその各々が備える機能を特定することができるように、デバイス識別情報と機能識別情報が階層的に管理されていれば、必ずしも図５のようなツリー構造に限定されるものではない。

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

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

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

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

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

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

Claims (9)

1. ネットワークを介して接続されたクライアントと、自身にローカル接続又は内蔵されたデバイスとの間のデータ通信を制御するデバイスサーバであって、
   前記デバイスからデバイス情報を取得する情報取得手段と、
   前記情報取得手段で取得したデバイス情報に基づいて前記デバイスが備える各機能をそれぞれ管理し、前記機能を使用するためのプロトコルを前記機能ごとにそれぞれ設定するデバイス管理手段と、
   前記クライアントからのセッション要求を受信するセッション要求受信手段と、
   前記セッション要求受信手段で受信したセッション要求に基づき、前記デバイスの機能ごとに独立したセッションを介して、前記機能ごとに対応したプロトコルによるデータ通信を制御するセッション制御手段と、
   を備えることを特徴とするデバイスサーバ。
2. 前記デバイス情報は、前記デバイスを識別するデバイス識別情報と前記デバイスの備える機能を識別する機能識別情報とを含み、
   前記デバイス管理手段は、前記デバイスが複数接続されている場合、前記複数のデバイスが備える機能をそれぞれ管理し、各デバイスの機能ごとにプロトコルを設定することを特徴とする請求項１に記載のデバイスサーバ。
3. 前記クライアントからの要求に応じて当該クライアントに対して前記デバイス情報と前記設定したプロトコルの情報を送信する情報送信手段をさらに備えることを特徴とする請求項１又は請求項２に記載のデバイスサーバ。
4. デバイスサーバにローカル接続又は内蔵されたデバイスとの間でネットワークを介してデータ通信を行うクライアントであって、
   前記デバイスサーバから前記デバイスのデバイス情報と前記デバイスの有する機能ごとに設定されたプロトコルの情報を取得する情報取得手段と、
   前記情報取得手段で取得した前記デバイス情報に基づいて、前記デバイスを直接接続しているように制御するためのドライバソフトウェア群を生成するデバイス仮想化手段と、
   前記デバイスと前記デバイスの有する機能を指定する機能指定手段と、
   前記機能指定手段で指定されたデバイスと機能に基づいて、当該機能に応じたドライバソフトウェア群を指定するドライバソフトウェア群指定手段と、
   前記ドライバソフトウェア群指定手段で指定されたドライバソフトウェア群を使用して、当該機能を実行させるための命令・データを生成する命令・データ生成手段と、
   前記ドライバソフトウェア群指定手段で指定されたドライバソフトウェア群に対応したプロトコルによるデータ通信のためのセッションを介して前記命令・データに基づくデータ入出力を制御する通信制御手段と、
   を備えることを特徴とするクライアント。
5. ネットワークを介して接続されたクライアントと、自身にローカル接続又は内蔵されたデバイスとの間のデータ通信を制御するデバイスサーバにおけるデバイス共有方法であって、
   情報取得手段が前記デバイスからデバイス情報を取得する情報取得ステップと、
   デバイス管理手段が前記情報取得ステップで取得したデバイス情報に基づいて前記デバイスが備える各機能をそれぞれ管理し、前記機能を使用するためのプロトコルを前記機能ごとにそれぞれ設定するデバイス管理ステップと、
   セッション要求受信手段が前記クライアントからのセッション要求を受信するセッション要求受信ステップと、
   セッション制御手段が前記セッション要求受信ステップで受信したセッション要求に基づき、前記デバイスの機能ごとに独立したセッションを介して、前記機能ごとに対応したプロトコルによるデータ通信を制御するセッション制御ステップと、
   を有することを特徴とするデバイス共有方法。
6. 前記デバイス情報は、前記デバイスを識別するデバイス識別情報と前記デバイスの備える機能を識別する機能識別情報とを含み、
   前記デバイス管理ステップは、前記デバイスが複数接続されている場合、前記複数のデバイスが備える機能をそれぞれ管理し、各デバイスの機能ごとにプロトコルを設定することを特徴とする請求項５に記載のデバイス共有方法。
7. 情報送信手段が前記クライアントからの要求に応じて当該クライアントに対して前記デバイス情報と前記設定したプロトコルの情報を送信する情報送信ステップをさらに備えることを特徴とする請求項５又は請求項６に記載のデバイス共有方法。
8. デバイスサーバにローカル接続又は内蔵されたデバイスとの間でネットワークを介してデータ通信を行うクライアントにおけるデバイス共有方法であって、
   情報取得手段が前記デバイスサーバから前記デバイスのデバイス情報と前記デバイスの有する機能ごとに設定されたプロトコルの情報を取得する情報取得ステップと、
   デバイス仮想化手段が前記情報取得ステップで取得した前記デバイス情報に基づいて、前記デバイスを直接接続しているように制御するためのドライバソフトウェア群を生成するデバイス仮想化ステップと、
   機能指定手段が前記デバイスと前記デバイスの有する機能を指定する機能指定ステップと、
   ドライバソフトウェア群指定手段が前記機能指定ステップで指定されたデバイスと機能に基づいて、当該機能に応じたドライバソフトウェア群を指定するドライバソフトウェア群指定ステップと、
   命令・データ生成手段がドライバソフトウェア群指定ステップで指定された機能に基づいて、前記デバイス仮想化ステップで生成したドライバソフトウェア群を使用して、当該機能を実行させるための命令・データを生成する命令・データ生成ステップと、
   通信制御手段が前記ドライバソフトウェア群指定ステップで指定された機能に対応したプロトコルによるデータ通信のためのセッションを介して前記命令・データ生成ステップで生成された命令・データに基づくデータ入出力を制御する通信制御ステップと、を有することを特徴とするデバイス共有方法。
9. 請求項１乃至３の何れかに記載のデバイスサーバと請求項４に記載のクライアントとが互いにネットワークを介して接続されていることを特徴とするデバイス共有システム。

Images