(57)【要約】【課題】一つの情報処理システムだけがデバイス情報を取得してしまい、他の情報処理システムがデバイス情報を取得できなくなるのを防止可能な情報分配システムの提供。【解決手段】一方のＰＣ上で機能する情報分配部は、デバイスが他ＰＣに接続されている場合（Ｓ３０５：ＹＥＳ）、他ＰＣ上で機能する情報分配部からデバイス情報を取得する（Ｓ３１０）。また、デバイスが自ＰＣに接続されていれば（Ｓ３０５：ＮＯ）、デバイスからデバイス情報を取得する（Ｓ３１５）。こうして取得したデバイス情報を複数のクライアントそれぞれに分配する。この分配の際、クライアントが他ＰＣで機能する情報分配部であれば（Ｓ３２５：ＹＥＳ）、他ＰＣへデバイス情報を送信し（Ｓ３３０）、自ＰＣ内で機能するクライアントであれば（Ｓ３２５：ＮＯ）、デバイス情報をクライアントに対応するバッファに格納する（Ｓ３３５〜Ｓ３４０）。【選択図】図５
2008198026.tif 000002
【特許請求の範囲】
【請求項１】
デバイスと通信可能な第１情報処理システムと、
前記第１情報処理システムと通信可能な第２情報処理システムと
を備えてなり、
前記第１情報処理システムは、
前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手段と、
前記第１取得手段によって取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手段と
を備え、
前記第２情報処理システムは、
前記第１分配手段によって分配される前記デバイス情報を取得する第２取得手段と、
前記第２取得手段によって取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手段と
を備えたことを特徴とする情報分配システム。
【請求項２】
第１コンピュータと、前記第１コンピュータとは異なる第２コンピュータとを備えるとともに、前記第１コンピュータと前記第２コンピュータがコンピュータ間用通信手段を介して通信可能に構成されてなり、
前記第１情報処理システムは、前記デバイスと通信可能な前記第１コンピュータ上に構成された情報処理システムであり、
前記第２情報処理システムは、前記第１コンピュータと通信可能な前記第２コンピュータ上に構成された情報処理システムである
ことを特徴とする請求項１に記載の情報分配システム。
【請求項３】
第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載された単一のコンピュータを備えるとともに、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されてなり、
前記第１情報処理システムは、前記デバイスと通信可能な前記第１ＯＳの制御下で機能する情報処理システムであり、
前記第２情報処理システムは、前記第１ＯＳと通信可能な前記第２ＯＳの制御下で機能する情報処理システムである
ことを特徴とする請求項１に記載の情報分配システム。
【請求項４】
請求項１〜請求項３のいずれかに記載の情報分配システムの内、前記第１情報処理システムとして機能する情報処理システムであって、
前記第１取得手段と、
前記第１分配手段と
を備えたことを特徴とする情報処理システム。
【請求項５】
請求項１〜請求項３のいずれかに記載の情報分配システムの内、前記第２情報処理システムとして機能する情報処理システムであって、
前記第２取得手段と、
前記第２分配手段と
を備えたことを特徴とする情報処理システム。
【請求項６】
デバイスと通信可能な第１情報処理システムにおいて、
前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手順と、
前記第１取得手順において取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手順と
を実行させ、
前記第１情報処理システムと通信可能な第２情報処理システムにおいて、
前記第１分配手順の実行によって分配される前記デバイス情報を取得する第２取得手順と、
前記第２取得手順において取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手順と
を実行させることを特徴とする情報分配方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報分配システム、情報処理システム、および情報分配方法に関する。
【背景技術】
【０００２】
従来、デバイスに関するデバイス情報をインターフェースを通じてデバイスから取得するとともに、そのデバイス情報を利用した情報処理を実施する技術が知られている（例えば、下記特許文献１参照）。
【特許文献１】特開２０００−２９３３２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、従来、一方の情報処理システムがデバイスに直接アクセスでき、且つ、他方の情報処理システムが前記一方の情報処理システム経由でデバイスにアクセスできるように構成されたシステムが知られている。
【０００４】
例えば、ネットワークを介して接続された二つのコンピュータの内、一方で機能する情報処理システムがデバイスに直接アクセスでき、他方で機能する情報処理システムが前記一方で機能する情報処理システム経由でデバイスにアクセスできるものがある。
【０００５】
また、単一のコンピュータに二つのＯＳ（Operating System）をインストールして運用している環境の中には、一方のＯＳ上で機能する仮想コンピュータに他方のＯＳをインストールした形態をとるものがある。このようなコンピュータにおいては、一方のＯＳ上で機能する情報処理システムがデバイスに直接アクセスでき、且つ、他方のＯＳ上で機能する情報処理システムが前記一方のＯＳ経由でデバイスにアクセスできる構成となる。
【０００６】
以上のようなシステムでは、上記のような二つの情報処理システムそれぞれにおいて、デバイスから取得したデバイス情報を利用した情報処理を実施したいことがある。
しかし、上記のような二つの情報処理システムそれぞれにおいて、上記特許文献１に記載の技術を採用した場合、二つの情報処理システムそれぞれがデバイスから情報を取得しようとする。そのため、デバイスが一度しか情報を提供しない場合、本来であれば一方の情報処理システムが取得すべき情報であっても、他方の情報処理システムが横取りしてしまい、上記一方の情報処理システムに必要な情報が渡らなくなるおそれがあった。
【０００７】
より具体的な例を挙げれば、デバイスが自身にとって都合のよいタイミングでデバイス情報を一度だけ用意し、このデバイス情報を、情報処理システムが自身にとって都合のよいタイミングで取得するように構成されたシステムがある。
【０００８】
このようなシステムの場合、デバイスがデバイス情報を用意した後、先に上記他方の情報処理システムがデバイス情報の取得を試みると、デバイス情報を取得してしまう。そのため、後からデバイス情報の取得を試みた上記一方の情報処理システムは、所期のデバイス情報を取得することができないことになる。
【０００９】
本発明は、このような問題を解決するためになされたものであり、その目的は、一つの情報処理システムだけがデバイス情報を取得してしまい、他の情報処理システムがデバイス情報を取得できなくなるのを防止可能な情報分配システムを提供することにある。また、そのような情報分配方法と、情報分配システムを構築するための情報処理システムを提供することにある。
【課題を解決するための手段】
【００１０】
以下、本発明において採用した構成について説明する。
請求項１に記載の情報分配システムは、デバイスと通信可能な第１情報処理システムと、前記第１情報処理システムと通信可能な第２情報処理システムとを備えてなり、前記第１情報処理システムは、前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手段と、前記第１取得手段によって取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手段とを備え、前記第２情報処理システムは、前記第１分配手段によって分配される前記デバイス情報を取得する第２取得手段と、前記第２取得手段によって取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手段とを備えたことを特徴とする。
【００１１】
上記のように構成された情報分配システムによれば、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。
【００１２】
したがって、第１情報処理システムおよび第２情報処理システムの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１情報処理システムおよび第２情報処理システムそれぞれが備える複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。
【００１３】
さらに、「デバイス情報をデバイスから取得する手段」は、第２情報処理システムには存在しないものの、第１分配手段および第２取得手段が協働することにより、第２情報処理システムにおいてもデバイス情報を取得できる仕組みになっている。
【００１４】
したがって、第２情報処理システムにある各手段は、デバイスと通信できなくてもよく、その場合でも、第２情報処理システム内にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。
【００１５】
請求項２に記載の情報分配システムは、請求項１に記載の情報分配システムにおいて、第１コンピュータと、前記第１コンピュータとは異なる第２コンピュータとを備えるとともに、前記第１コンピュータと前記第２コンピュータがコンピュータ間用通信手段を介して通信可能に構成されてなり、前記第１情報処理システムは、前記デバイスと通信可能な前記第１コンピュータ上に構成された情報処理システムであり、前記第２情報処理システムは、前記第１コンピュータと通信可能な前記第２コンピュータ上に構成された情報処理システムであることを特徴とする。
【００１６】
上記のように構成された情報分配システムによれば、第１コンピュータおよび第２コンピュータの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１コンピュータおよび第２コンピュータそれぞれが備える複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。
【００１７】
さらに、「デバイス情報をデバイスから取得する手段」は、第２コンピュータには存在しないものの、第１分配手段および第２取得手段が協働することにより、第２コンピュータにおいてもデバイス情報を取得できる仕組みになっている。
【００１８】
したがって、第２コンピュータにある各手段は、デバイスと通信できなくてもよく、その場合でも、第２コンピュータ内にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。
【００１９】
請求項３に記載の情報分配システムは、請求項１に記載の情報分配システムにおいて、第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載された単一のコンピュータを備えるとともに、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されてなり、前記第１情報処理システムは、前記デバイスと通信可能な前記第１ＯＳの制御下で機能する情報処理システムであり、前記第２情報処理システムは、前記第１ＯＳと通信可能な前記第２ＯＳの制御下で機能する情報処理システムであることを特徴とする。
【００２０】
上記のように構成された情報分配システムによれば、第１ＯＳおよび第２ＯＳの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１ＯＳおよび第２ＯＳそれぞれの制御下にある複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。
【００２１】
さらに、「デバイス情報をデバイスから取得する手段」は、第１ＯＳの制御下にのみ存在し、第２ＯＳの制御下には存在しないものの、第１分配手段および第２取得手段が協働することにより、第２ＯＳ側においてもデバイス情報を取得できる仕組みになっている。
【００２２】
したがって、第２ＯＳの制御下にある各手段は、デバイスと通信できなくてもよく、その場合でも、第２ＯＳの制御下にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。
【００２３】
請求項４に記載の情報処理システムは、請求項１〜請求項３のいずれかに記載の情報分配システムの内、前記第１情報処理システムとして機能する情報処理システムであって、前記第１取得手段と、前記第１分配手段とを備えたことを特徴とする。
【００２４】
上記のように構成された情報処理システムによれば、前記第２取得手段および前記第２分配手段を備えた情報処理システムとともに採用することにより、請求項１〜請求項３のいずれかに記載の情報分配システムを構築することができる。
【００２５】
請求項５に記載の情報処理システムは、請求項１〜請求項３のいずれかに記載の情報分配システムの内、前記第２情報処理システムとして機能する情報処理システムであって、前記第２取得手段と、前記第２分配手段とを備えたことを特徴とする。
【００２６】
上記のように構成された情報処理システムによれば、前記第１取得手段および前記第１分配手段を備えた情報処理システムとともに採用することにより、請求項１〜請求項３のいずれかに記載の情報分配システムを構築することができる。
【００２７】
請求項６に記載の情報分配方法は、デバイスと通信可能な第１情報処理システムにおいて、前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手順と、前記第１取得手順において取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手順とを実行させ、前記第１情報処理システムと通信可能な第２情報処理システムにおいて、前記第１分配手順の実行によって分配される前記デバイス情報を取得する第２取得手順と、前記第２取得手順において取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手順とを実行させることを特徴とする。
【００２８】
上記のように構成された情報分配方法によれば、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。
【００２９】
したがって、第１情報処理システムおよび第２情報処理システムの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１情報処理システムおよび第２情報処理システムそれぞれが備える複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。
【００３０】
さらに、「デバイス情報をデバイスから取得する手順」は、第２情報処理システムにおいては実行されないものの、第１分配手順および第２取得手順を実行することにより、第２情報処理システムにおいてもデバイス情報を取得できる仕組みになっている。
【００３１】
したがって、第２情報処理システムにおいては、デバイスと通信できなくてもよく、その場合でも、第２情報処理システム内にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。
【発明を実施するための最良の形態】
【００３２】
次に、本発明の実施形態について、いくつかの具体的な例を挙げて説明する。
（１）第１実施形態
まず、第１実施形態について説明する。
【００３３】
［システム全体の構成］
図１は、パーソナルコンピュータ１（以下、ＰＣ１という）、パーソナルコンピュータ２（以下、ＰＣ２という）、およびデバイス３を備えてなるシステム全体の構成を示した概略構成図である。
【００３４】
これらの内、ＰＣ１とＰＣ２は、ＬＡＮ（Local Area Network）５を介して通信可能になっている。また、ＰＣ１とデバイス３は、ＵＳＢ（Universal Serial Bus）インターフェースを介して通信可能になっている。なお、本実施形態において例示するデバイス３は、プリンタである。
【００３５】
本実施形態において、ＰＣ１、２にはマルチタスク機能を備えたＯＳが搭載され、ＰＣ１、２が備えるＣＰＵは、ＯＳのマルチタスク機能により、複数のソフトウェアに基づく処理を時分割で並列に実行することができる。
【００３６】
そして、このマルチタスク機能を利用して、ＰＣ１、２上では、本発明に関連するソフトウェアとして、後から詳述するステータスモニタ１２、２２、リードバックツール１３、２３、情報分配部１５、２５などが機能するようになっている。
【００３７】
また、ＰＣ１上では、ＯＳが備える標準機能として、物理ポートドライバ１６や、デバイス３へ出力する印刷データを印刷ジョブとして管理する印刷スプーラなどが機能するようになっている。デバイス３との通信を行う際には、物理ポートドライバ１６によってＰＣ１が備える物理ポート１７が制御される。
【００３８】
なお、ＯＳによって提供されるこれらの各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＰＣ１が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。
【００３９】
ＰＣ１、２上で機能するソフトウェアのうち、情報分配部１５はサーバーとして機能し、ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、情報分配部１５に対するクライアントとして機能する。また、情報分配部２５はサーバーとしても機能し、ステータスモニタ２２、およびリードバックツール２３は、情報分配部２５に対するクライアントとして機能する。
【００４０】
より詳しくは、情報分配部１５は、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれからの要求に応じて、デバイス３からデバイス情報を取得する。そして、取得したデバイス情報を、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれからの要求に応じて、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれへ提供する。
【００４１】
なお、ステータスモニタ１２、２２、リードバックツール１３、２３、情報分配部１５、２５は、それぞれ同一のプログラムである。これらは同一のプリンタドライバインストールセットに包含され供給されるものである。ただし、本例では、便宜上、ＰＣ１とＰＣ２とで、その符号を変えてある。
【００４２】
ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、それぞれが、デバイス情報を利用して各種情報処理を行っている。具体的には、例えば、ステータスモニタ１２は、取得したデバイス情報に基づいてデバイス３の状態をほぼリアルタイムで表示部に表示する処理を実行する。
【００４３】
リードバックツール１３は、デバイス情報を参照したい利用者が任意に操作してデバイス情報を取得するための専用ツールである。このリードバックツール１３を利用すれば、例えば、取得したデバイス情報に基づいてデバイス３のシリアル番号やファームウェアヴァージョン等の情報を表示する処理などを実行することができる。
【００４４】
情報分配部２５は、ステータスモニタ２２、およびリードバックツール２３それぞれからの要求に応じて、情報分配部１５からデバイス情報を取得する。そして、取得したデバイス情報を、ステータスモニタ２２、およびリードバックツール２３それぞれからの要求に応じて、ステータスモニタ２２、およびリードバックツール２３それぞれへ提供する。
【００４５】
つまり、本実施形態において、情報分配部１５、２５は、具体的なデバイス情報をどこから取得するか、どのクライアントに対するサーバーとなっているか、といった点が異なるものの、クライアントへデバイス情報を提供するという機能には差異がない。
【００４６】
さらに、図１においては図示を省略してあるが、ＰＣ２にデバイスが接続されている場合、情報分配部２５は、情報分配部１５と全く同様に、ＰＣ２に接続されたデバイスからデバイス情報を取得することができる。
【００４７】
また、この場合、情報分配部１５は、情報分配部２５に対するクライアントとして機能することもでき、ＰＣ２に接続されたデバイスから取得されたデバイス情報を、情報分配部２５から情報分配部１５へ提供することができる。
【００４８】
すなわち、情報分配部１５、２５は、どちらがサーバーとなり、どちらがクライアントとなるかについて、必要に応じて互いの立場を入れ替えることもできる。このようなことができるのは、情報分配部１５、２５が、全く同等な機能を備えた同一のプログラムだからである。
【００４９】
ただし、図１においては、サーバーとクライアントの関係を理解しやすくするため、ＰＣ２にはデバイスが接続されておらず、且つ、情報分配部１５がサーバー、情報分配部２５がクライアントとなる関係で機能する事例のみを図示してある。
【００５０】
なお、本実施形態では、情報分配部１５に対するクライアントとして、ステータスモニタ１２、リードバックツール１３、および情報分配部２５を例示してあるが、情報分配部１５に対するクライアントは、さらに並列にいくつ機能してもよい。また、各クライアントが処理を開始するタイミングや処理を終了するタイミング等は任意であり、クライアント毎に独立したタイミングで構わない。
【００５１】
同様に、情報分配部２５に対するクライアントも、ステータスモニタ２２、およびリードバックツール２３以外にいくつ機能してもよく、それら各クライアントによる処理の開始タイミングや終了タイミング等も任意である。
【００５２】
一方、デバイス３は、ＰＣ１側からの要求に応じて、デバイス３に関する情報であるデバイス情報をＰＣ１に対して提供する機能を備えている。
本実施形態の場合、デバイス情報としては、例えば、オンライン、オフラインといった「デバイスの状態に関する情報」、用紙サイズ毎の印刷枚数あるいは総印刷枚数といった「使用頻度に関する情報」が提供される。
【００５３】
また、ドラム交換時期などの「交換部品の使用度合に関する情報」、トナーないしインク残量や記録用紙残量といった「消耗品の消耗度合に関する情報」、紙詰まり回数といった「異常の発生回数に関する情報」なども提供される。これらのデバイス情報のうち、どれを提供するかは、ＰＣ１側から送信されてくるコマンドにより指定される。
【００５４】
本実施形態において、ＰＣ１がデバイス３に対してデバイス情報を要求する際には、ＰＣ１からデバイス３に対してＰＪＬコマンドを送信する。ＰＪＬ（Printer Job Language；プリンタジョブ言語）は、プリンタが備える各種機能を制御するために用意されたコマンド言語で、Hewlett-Packard社において開発され、その後他社でも採用された周知のものである。
【００５５】
ＰＣ１上で機能するクライアント（本実施形態の場合、ステータスモニタ１２、およびリードバックツール１３）が、情報分配部１５に対してコマンド送信要求を送信すると、このコマンド送信要求に応じて情報分配部１５がＰＪＬコマンドを出力する。
【００５６】
また、ＰＣ２上で機能するクライアント（本実施形態の場合、情報分配部２５）が、ＬＡＮ５経由で情報分配部１５に対してコマンド送信要求を送信する場合もある。この場合も、ＰＣ２上で機能するクライアントからのコマンド送信要求に応じて、情報分配部１５がＰＪＬコマンドを出力する。
【００５７】
情報分配部１５が出力したＰＪＬコマンドは、通常の印字データと同様に、プリンタドライバ経由で印刷スプーラに引き渡され、印刷スプーラは、受け取ったＰＪＬコマンドを印刷ジョブとして処理する。その結果、ＰＪＬコマンドは、物理ポート１７を通じてデバイス３へと出力されることになる。
【００５８】
デバイス３では、通常の印刷データと同様にＰＪＬコマンドを受信するが、受信したデータのヘッダ情報からＰＪＬコマンドであることを認識し、その内容を解析する。その解析の結果、デバイス３が応答可能なＰＪＬコマンドであった場合は、デバイス３が内蔵するメモリに蓄積されているデバイス情報を読み出して、そのデバイス情報をＰＣ１へと送信する。
【００５９】
ＰＣ１では、情報分配部１５がデバイス３から返されるデバイス情報を取得する。このとき、どのような方法でデバイス情報を取得するかは、ＰＣ１−デバイス３間の通信インターフェースによっても変わり得るが、本実施形態において、ＰＣ１−デバイス３間はＵＳＢインターフェースを介して接続されている。
【００６０】
そのため、デバイス情報を取得する際には、情報分配部１５が情報の受信を行い、受信した情報量が０（ゼロ）であった場合には再び情報の受信を繰り返し、その繰り返し処理によって情報を取得する、という方法がとられる。以下、このような方法でデバイス３からデバイス情報を読み取ることをリードバックを行うという。
【００６１】
リードバックを行うことにより、何らかのデータを受信した場合は、そのデータが所期のデバイス情報であるかどうかをチェックし、所期のデバイス情報でない場合は、さらに受信処理をやり直し、最終的に所期のデバイス情報を取得することになる。
【００６２】
デバイス情報を取得した情報分配部１５は、図２に示すように、ＰＣ１上で機能するクライアント（本実施形態の場合、ステータスモニタ１２、およびリードバックツール１３）それぞれに対応付けて用意されたバッファ１５Ａ、１５Ｂにデバイス情報を格納する。すなわち、バッファ１５Ａ、１５Ｂには、同じ内容のデバイス情報が格納される。
【００６３】
ただし、クライアントが、ＰＣ１とは別ＰＣにおいて機能する情報分配部となる場合は、別ＰＣ側でバッファが用意されるので、ＰＣ１ではバッファを用意せず、直ちにＰＣ２へデバイス情報を送信する。
【００６４】
具体例を交えて説明すると、クライアントが、ＰＣ２において機能する情報分配部２５となる場合、情報分配部２５がバッファ２５Ａ、２５Ｂを用意するので、情報分配部１５ではバッファを用意せず、直ちにＰＣ２へデバイス情報を送信する。ここで送信されたデバイス情報は、情報分配部２５がバッファ２５Ａ、２５Ｂに格納することになる。
【００６５】
さて、ＰＣ１では、情報分配部１５がＰＣ１上のクライアントのいずれかからの要求を受けた場合、情報分配部１５は、要求元のクライアントに対応するバッファに格納されたデバイス情報を、要求元のクライアントに対して送信する。
【００６６】
例えば、情報分配部１５がステータスモニタ１２からの要求を受けた場合であれば、情報分配部１５は、ステータスモニタ１２に対応するバッファ１５Ａに格納されたデバイス情報を、ステータスモニタ１２へ送信する。
【００６７】
その結果、要求元のクライアント（例えば、ステータスモニタ１２）は、デバイス情報を取得することができるので、取得したデバイス情報に基づく情報処理（例えば、デバイス３の状態をＰＣ１の表示部に表示する処理等）を実行することができる。
【００６８】
なお、ＰＣ２では、情報分配部２５が上記情報分配部１５と同様に機能する。すなわち、ＰＣ２上のクライアントのいずれかからの要求を受けた場合、情報分配部２５は、要求元のクライアントに対応するバッファに格納されたデバイス情報を、要求元のクライアントに対して送信する。
【００６９】
その結果、要求元のクライアント（例えば、ステータスモニタ２２）は、デバイス情報を取得することができるので、取得したデバイス情報に基づく情報処理（例えば、デバイス３の状態をＰＣ２の表示部に表示する処理等）を実行することができる。
【００７０】
さて、以上のような仕組みにより、ＰＣ１とデバイス３との間、さらにＰＣ１とＰＣ２との間では、ＰＪＬコマンドの送受信およびデバイス情報の送受信が行われる。ただし、デバイス３は、ＰＣ１側からの要求に応じてデバイス情報を提供するものの、クライアントのいずれが要求元であるのかを認識する仕組みにはなっていない。
【００７１】
そのため、ＰＣ１側からのリードバックを受ければ、その時点でデバイス３が要求されていたすべてのデバイス情報をＰＣ１側へ提供する。このような仕組みを採用しているため、情報分配部１５が設けられていない場合には、次のような問題が発生する。
【００７２】
例えば、ステータスモニタ１２、およびリードバックツール１３双方が、デバイス３に対して直接デバイス情報の取得要求を発しするように構成してある場合、デバイス３は、それらに対する応答として返すべきデバイス情報を用意する。
【００７３】
しかし、その後、例えば、ステータスモニタ１２が独自にデバイス３からのリードバックを行ってしまうと、リードバックツール１３に送信されるべきデバイス情報までステータスモニタ１２に送信されてしまう。この場合、送信済みのデバイス情報は、デバイス３の送信バッファ内から消されてしまう。
【００７４】
このような状況になった場合、その後、リードバックツール１３がデバイス３からのリードバックを行ったとしても、リードバックツール１３では、必要なデバイス情報を受け取れないという事態を招く。
【００７５】
上記同様の情報の取り合いは、クライアントとして機能する情報分配部２５とステータスモニタ１２との間でも発生し、クライアントとして機能する情報分配部２５とリードバックツール１３との間でも発生する。
【００７６】
上記情報分配部１５は、こうした事態が発生するのを防止するために設けられたものである。具体例を交えて説明すると、例えば、ステータスモニタ１２、およびリードバックツール１３それぞれがデバイス情報の取得要求を発した場合、それらに対する応答として返すべきデバイス情報をデバイス３が用意する。
【００７７】
情報分配部１５は、代表してデバイス３からのリードバックを行い、取得したデバイス情報を複数のバッファ１５Ａ、１５Ｂに複製する。また、ＰＣ２側に存在するクライアントである情報分配部２５に対しては、取得したデバイス情報を送信する。
【００７８】
このような処理が行われるため、ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、独自にデバイス３からのリードバックを行わず、必ず情報分配部１５からデバイス情報の提供を受ける。
【００７９】
ここで、例えば、ステータスモニタ１２が情報分配部１５からデバイス情報の提供を受けた場合、送信済みのデバイス情報はバッファ１５Ａ内から消されてしまう。しかし、その後も、バッファ１５Ｂ内には、複製されたデバイス情報が残っているので、リードバックツール１３は、情報分配部１５からデバイス情報の提供を受けることができるのである。
【００８０】
なお、以上、情報分配部１５の役割について説明したが、情報分配部２５も全く同様に機能することで、ステータスモニタ２２、およびリードバックツール２３に対してデバイス情報を分配する。したがって、ステータスモニタ２２とリードバックツール２３がデバイス情報を取り合った結果、一方だけがデバイス情報を取得し、他方がデバイス情報を取得できない、といった事態に至るのを防ぐことができる。
【００８１】
［情報分配部における主処理］
次に、上記のような情報分配部１５、２５の機能を実現するため、情報分配部１５、２５において実行される主処理について、図３および図４のフローチャートに基づいて説明する。この処理は、情報分配部１５、２５を機能させたい時点で開始されていればよい処理であり、例えば、ＰＣ１の起動に伴って開始される処理となっていればよい。
【００８２】
なお、上述の通り、情報分配部１５、２５は、まったく同じプログラムである。ただし、図１においては、情報分配部１５がサーバーとして機能し、情報分配部２５がクライアントとして機能する事例を図示してある。
【００８３】
そこで、以下の説明においては、図１に示す具体的事例との関係も考慮し、サーバーとして機能する部分に関しては、情報分配部１５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部２５を例に挙げて説明する。
【００８４】
主処理を開始すると、図３に示すように、情報分配部１５（正確には、情報分配部１５として機能しているＰＣ１のＣＰＵ）は、まず、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）からの要求待ちになる（Ｓ１０５）。ここで、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）のいずれかから何らかの要求があるとＳ１０５の処理を抜ける。
【００８５】
続いて、情報分配部１５は、ＰＣ１内のクライアントから受けた新規クライアント追加要求か否かを判断する（Ｓ１１０）。
Ｓ１１０の処理において、新規クライアント追加要求であった場合（Ｓ１１０：ＹＥＳ）、情報分配部１５は、要求元となったクライアントのＩＤをＰＣ１内のメモリに記憶させる（Ｓ１１５）。
【００８６】
上記ＩＤは、新規クライアント追加要求ごとに情報分配部１５によりユニークな値が生成されるものである。このＩＤは、このクライアントからの追加要求終了時に、戻り値としてクライアントに渡される。
【００８７】
以後クライアントは、後述する別の要求（クライアント削除要求、新規コマンド送信要求、デバイス情報呼び出し情報など）を発行する際に、このＩＤを指定することにより、その処理対象が自分であることを情報分配部１５に知らせる。
【００８８】
図２に示すように、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）には、それぞれユニークなＩＤ（図２に示した例では、ＣＬ−１Ａ、ＣＬ−１Ｂ、ＣＬ−１Ｃ）が付与される。
【００８９】
例えば、ステータスモニタ１２が新規クライアント追加要求を行った場合を例に挙げれば、その追加要求中にはＩＤ：ＣＬ−１Ａが含まれているので、Ｓ１１５の処理では、ＩＤ：ＣＬ−１Ａを記憶する。以後は、クライアントからの要求中にＩＤ：ＣＬ−１Ａが含まれていれば、その要求がステータスモニタ１２からの要求であることを、情報分配部１５側で認識できるようになる。
【００９０】
次に、Ｓ１１５の処理を終えたら、要求元となったクライアントに対応するバッファを確保する（Ｓ１２０）。Ｓ１２０の処理で確保されるバッファは、図２に示したバッファ１５Ａ、１５Ｂに相当するものである。例えば、ステータスモニタ１２が新規クライアント追加要求を行った場合を例に挙げれば、Ｓ１２０の処理によりバッファ１５Ａが確保されることになる。
【００９１】
そして、Ｓ１２０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。なお、このバッファは、先のＳ１１５の処理により、生成・記憶されたＩＤと関連づけられて管理される。すなわちＩＤが与えられれば、対応するバッファが特定できるように管理される。
【００９２】
さて一方、上記Ｓ１１０の処理において、新規クライアント追加要求ではなかった場合（Ｓ１１０：ＮＯ）、続いて、情報分配部１５は、クライアント削除要求か否かを判断する（Ｓ１２５）。
【００９３】
Ｓ１２５の処理において、クライアント削除要求であった場合（Ｓ１２５：ＹＥＳ）、情報分配部１５は、要求元となったクライアントに対応するバッファを削除する（Ｓ１３０）。この際、クライアントはＳ１１５の処理で自分に与えられたＩＤを指定して、この削除要求を発行する。
【００９４】
情報分配部１５は、その指定されたＩＤに対応するバッファを削除するのである。例えば、ステータスモニタ１２がクライアント削除要求を行った場合を例に挙げれば、Ｓ１３０の処理によりバッファ１５Ａが削除されることになる。そして、Ｓ１３０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。
【００９５】
一方、上記Ｓ１２５の処理において、クライアント削除要求ではなかった場合（Ｓ１２５：ＮＯ）、情報分配部１５は、新規コマンド送信要求であるか否かを判断する（Ｓ１３５）。本実施形態においては、各クライアント（（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）からＰＪＬコマンドを含むコマンド送信要求がクライアントを示すＩＤとともに送信されてくる。
【００９６】
ただし、これは、各クライアントからＰＪＬコマンドを示すＰＪＬ識別子を含むコマンド送信要求を送信するとともに、送信されて来たＰＪＬ識別子に基づいて、情報分配部１５側でＰＪＬ識別子に対応するＰＪＬコマンドを用意するようにしてもよい。
【００９７】
Ｓ１３５の処理において、新規コマンド送信要求であった場合（Ｓ１３５：ＹＥＳ）、情報分配部１５は、送信要求されたＰＪＬコマンドをスプーラ経由で物理ポート１７を通じてデバイス３へ送信する（Ｓ１４０）。
【００９８】
なお、Ｓ１４０の処理では、送信要求されたＰＪＬコマンドが前記ＩＤと関連付けてメモリに記憶される。そして、Ｓ１４０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。
【００９９】
一方、Ｓ１３５の処理において、新規コマンド送信要求ではなかった場合（Ｓ１３５：ＮＯ）、情報分配部１５、２５は、図４に示すように、他ＰＣへの接続要求か否かを判断する（Ｓ２０５）。また、他ＰＣへの接続要求ではなかった場合（Ｓ２０５：ＮＯ）、他ＰＣからの接続要求か否かを判断する（Ｓ２２５）。
【０１００】
ここで、上記Ｓ２０５の処理では、例えば、ＰＣ２において、情報分配部２５がステータスモニタ２２からの要求を受けた結果、ＰＣ１の情報分配部１５との通信が必要となった場合に肯定判断がなされる。
【０１０１】
また、上記Ｓ２２５の処理では、例えば、ＰＣ１において、情報分配部１５が情報分配部２５からの要求を受けた結果、ＰＣ２の情報分配部２５との通信が必要となった場合に肯定判断がなされる。
【０１０２】
そこで、ここでは、上記の通り、ＰＣ２の情報分配部２５において上記Ｓ２０５の処理で肯定判断がなされ、ＰＣ１の情報分配部１５において上記Ｓ２２５の処理で肯定判断がなされた場合を例に挙げて説明を続ける。
【０１０３】
ＰＣ２の情報分配部２５において上記Ｓ２０５の処理で肯定判断がなされた場合（Ｓ２０５：ＹＥＳ）、他ＰＣ（本実施形態の場合、ＰＣ１）の接続情報を取得する（Ｓ２１０）。他ＰＣの接続情報は、他ＰＣのＩＰアドレス等、他ＰＣと通信を行う上で必要となる情報である。
【０１０４】
本実施形態の場合、ＰＣ２は、デバイス３を共有プリンタとして認識するように構成されており、その共有プリンタに関する情報中にＳ２１０の処理で取得したい情報が含まれているので、その情報を他ＰＣの接続情報として取得する。
【０１０５】
続いて、情報分配部２５は、ネットワーク経由で他ＰＣに対し、接続要求を発行し（Ｓ２１５）、他ＰＣが自ＰＣと接続するために必要となる自ＰＣ情報（自ＰＣのＩＰアドレス等）を送信する（Ｓ２２０）。
【０１０６】
上記Ｓ２１５の処理により、本実施形態の場合、情報分配部２５から情報分配部１５へ接続要求が送信されることになる。情報分配部２５からの接続要求が送信された場合、Ｓ１０５の処理によってクライアントからの要求待ちとなっていた情報分配部１５は、Ｓ１０５の処理を抜けた後、Ｓ２２５の処理で他ＰＣからの接続要求であると判断する（Ｓ２２５：ＹＥＳ）。
【０１０７】
この場合、情報分配部１５は、接続に必要な他ＰＣ情報を受信する（Ｓ２３０）。Ｓ２３０の処理で受信する他ＰＣ情報は、上述したＳ２２０の処理によって送信された情報である。この他ＰＣ情報を受信した情報分配部１５は、他ＰＣ（ＰＣ２）の情報分配部２５をクライアントの一つとして認識することになり、そのクライアントのＩＤをメモリに記憶する（Ｓ２３５）。
【０１０８】
なお、以上説明したＳ２１０〜Ｓ２２０の処理、あるいは、Ｓ２３０〜Ｓ２３５の処理を終えたら、いずれの場合とも、Ｓ１０５の処理へと戻る。
ちなみに、上述の事例では、情報分配部２５がＳ２１０〜Ｓ２２０の処理を実行し、情報分配部１５がＳ２３０〜Ｓ２３５の処理を実行する場合を例に挙げて説明したが、これらの処理が入れ替わることもあり得る。
【０１０９】
すなわち、情報分配部１５がＳ２１０〜Ｓ２２０の処理を実行し、情報分配部２５がＳ２３０〜Ｓ２３５の処理を実行する状態になることもある。そのような状態になるのは、先に説明した通り、情報分配部２５がＰＣ２に接続されたデバイスからデバイス情報を取得し、そのデバイス情報を情報分配部１５へ分配する場合である。
【０１１０】
さて、以上が他ＰＣとの通信を行う場合についての説明であるが、上記Ｓ２２５の処理において、他ＰＣからの接続要求でもないと判断した場合（Ｓ２２５：ＮＯ）、本実施形態では、クライアントからデバイス情報のリード要求を受けたものと判断する。
【０１１１】
すなわち、新規クライアント追加要求、クライアント削除要求、新規コマンド送信要求、他ＰＣへの接続要求、および他ＰＣからの接続要求、以上のいずれでもない要求としては、デバイス情報リード要求しか存在しないとの前提で処理を進める。
【０１１２】
この場合、情報分配部１５は、クライアントが付与したＩＤに基づいて要求元となったクライアントに対応するバッファをサーチし、そのバッファ内に記憶されたデバイス情報（後述する常駐スレッド処理により記憶されたもの）を読み出す（Ｓ２４０）。そして、読み出したデバイス情報を要求元となったクライアントに送信する（Ｓ２４５）。
【０１１３】
例えば、ステータスモニタ１２からデバイス情報のリード要求を受けた場合を例に挙げれば、Ｓ２４０の処理によりバッファ１５Ａからデバイス情報が読み出される。そして、そのデバイス情報が、Ｓ２４０の処理によってクライアントであるステータスモニタ１２に送信されることになる。
【０１１４】
なお、Ｓ２４０の処理により、バッファから読み出されるデバイス情報は、本処理と並列に実行される常駐スレッド処理によりデバイス３から読み出されてバッファに格納されたものであるが、この常駐スレッド処理の詳細については後述する。
【０１１５】
そして、Ｓ２４５の処理を終えたら、送信分のデバイス情報をバッファから削除して（Ｓ２５０）、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。
［情報分配部における常駐スレッド処理］
次に、情報分配部１５、２５において主処理と並列に実行される常駐スレッド処理について、図５のフローチャートに基づいて説明する。なお、先に説明した主処理（図３、図４参照）の場合と同様に、サーバーとして機能する部分に関しては、情報分配部１５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部２５を例に挙げて説明する。
【０１１６】
この処理を開始すると、情報分配部１５、２５は、ターゲット（デバイス情報の取得対象となるデバイス）は他ＰＣのデバイスか否かを判断する（Ｓ３０５）。
本実施形態の場合、ＰＣ２において情報分配部２５が情報分配部１５からデバイス情報を取得する場合であれば（Ｓ３０５：ＹＥＳ）、他ＰＣ（本実施形態の場合、ＰＣ１）よりデバイス情報を取得する（Ｓ３１０）。このデバイス情報は、情報元となるＰＣ（本例ではＰＣ１）で機能する情報分配部（本例では情報分配部１５）のＳ３３０の処理（後述）により送り出されたものである。
【０１１７】
また、ＰＣ１において情報分配部１５がデバイス３からデバイス情報を取得する場合であれば（Ｓ３０５：ＮＯ）、デバイス３からデバイス情報を読み取る（Ｓ３１５）。
ここで、まだデバイス３に対してＰＪＬコマンドが送信されていない場合など、デバイス３側がデバイス情報を送信できる状態にない場合は、Ｓ３１０またはＳ３１５の処理で待機状態になり、何らかの情報を取得したらＳ３１０またはＳ３１５の処理を抜ける。
【０１１８】
続いて、情報分配部１５は、ループ処理にてすべてのクライアントを順に処理するため、未処理のクライアントに対応するＩＤの中から、処理対象とするクライアントに対応する１つのＩＤを選ぶ（Ｓ３２０）。このＳ３２０の処理において、未処理のクライアントに対応するＩＤとは、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤのうち、Ｓ３２０の処理でまだ選ばれたことがないＩＤである。
【０１１９】
次に、情報分配部１５は、Ｓ３２０の処理で選んだＩＤに対応するクライアントは、他ＰＣの情報分配部か否かを判断する（Ｓ３２５）。ここで、情報分配部１５が、情報分配部２５のＩＤ（ＣＬ−１Ｃ）を選択していれば（Ｓ３２５：ＹＥＳ）、他ＰＣであるＰＣ２の情報分配部２５へデバイス情報を送信し（Ｓ３３０）、後述するＳ３５０の処理へと進む。
【０１２０】
一方、他ＰＣの情報分配部のＩＤを選択していなければ（Ｓ３２５：ＮＯ）、情報分配部１５は、Ｓ３２０の処理で選んだＩＤに対応するバッファに十分な空き領域があるか否かを判断する（Ｓ３３５）。
【０１２１】
そして、バッファに十分な空き領域がない場合は（Ｓ３３５：ＹＥＳ）、古いデバイス情報を捨ててバッファ内の領域を空ける（Ｓ３４０）。一方、バッファに十分な空き領域がある場合は（Ｓ３３５：ＮＯ）、Ｓ３４０の処理をスキップする。
【０１２２】
こうしてＳ３３５の処理またはＳ３４０の処理を終えたら、続いて、情報分配部１５は、Ｓ３１５の処理で読み取ったデバイス情報を、Ｓ３２０の処理で選んだＩＤに対応するバッファに追記書き込みする（Ｓ３４５）。このＳ３４５の処理により、バッファ１５Ａ、１５Ｂにはデバイス情報が格納され、このデバイス情報が上述したＳ２４０の処理によってバッファ１５Ａ、１５Ｂから読み出されることになる。
【０１２３】
そして、Ｓ３３０またはＳ３４５の処理を終えたら、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤについての処理が終了したか否かを判断する（Ｓ３５５）。その判断の結果、終了していなければ（Ｓ３５５：ＮＯ）、Ｓ３２０の処理へと戻り、再びＳ３２０〜Ｓ３５５の処理を繰り返す。
【０１２４】
一方、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤについての処理が終了した場合（Ｓ３５５：ＹＥＳ）、この常駐スレッド処理を終了するか否かを判断する（Ｓ３５５）。
【０１２５】
その判断の結果、終了する場合は（Ｓ３５５：ＹＥＳ）、常駐スレッド処理を終了する。また、常駐スレッド処理を終了しない場合は（Ｓ３５５：ＮＯ）、１秒待機して（Ｓ３６０）、Ｓ３１５の処理へと戻り、再びＳ３１５以降の処理を繰り返す。
【０１２６】
以上のような常駐スレッド処理が情報分配部１５、２５において実行されることにより、Ｓ３１０またはＳ３１５の処理でデバイス情報を取得する毎に、Ｓ３２０〜Ｓ３５０のループ処理が実行される。その結果、このループ処理により、すべてのクライアントに対応するバッファ（１５Ａ、１５Ｂ、あるいは、２５Ａ、２５Ｂ）にデバイス情報が分配される。
【０１２７】
そして、このデバイス情報の分配が完了したら、１秒の待機（Ｓ３６０）を経て、再びデバイス情報を取得するための処理（Ｓ３０５〜Ｓ３１５）以降の処理が繰り返されることになる。
【０１２８】
［第１実施形態の効果］
以上説明したように、上記第１実施形態においては、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。
【０１２９】
したがって、ＰＣ１およびＰＣ２の内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、ＰＣ１およびＰＣ２それぞれが備える複数のクライアントに関しても、一つのクライアントにデバイス情報が提供されたことが原因で、他のクライアントにデバイス情報を提供できなくなることがない。
【０１３０】
さらに、デバイス３からデバイス情報を取得する手段は、ＰＣ１にのみ存在し、ＰＣ２には存在しないものの、情報分配部１５および情報分配部２５が協働することにより、ＰＣ２においてもデバイス情報を取得できる仕組みになっている。
【０１３１】
したがって、ＰＣ２側にある手段は、デバイス３と直接通信できなくてもよく、その場合でも、ＰＣ２内にある複数のクライアントに、何ら問題なくデバイス情報を提供することができる。
【０１３２】
（２）第２実施形態
次に、第２実施形態について説明する。
［システム全体の構成］
図６は、パーソナルコンピュータ３０（以下、ＰＣ３０という）、およびデバイス３を備えてなるシステム全体の構成を示した概略構成図である。
【０１３３】
本実施形態において例示するデバイス３も、第１実施形態同様、ＰＪＬに対応したプリンタであり、ＰＣ３０とデバイス３は、ＵＳＢインターフェースを介して通信可能になっている。
【０１３４】
また、ＰＣ３０には、第１実施形態同様、マルチタスク機能を備えたＯＳ３１が搭載されている。このＯＳ３１の制御下で、ステータスモニタ３２、リードバックツール３３、情報分配部３５、物理ポートドライバ３６などが機能する点、物理ポート３７を介してデバイス３との通信を行う点も、第１実施形態同様である。
【０１３５】
また、第１実施形態では明示しなかったが、ＯＳ３１は、カーネルドライバ３８を備えている。カーネルドライバ３８は、ＯＳ３１が提供する機能を実現する上で中心的な役割を果たすモジュールで、例えば、ＰＣ１が備えるメモリに対する入出力（リード／ライト）機能等は、カーネルドライバ３８によって管理される。
【０１３６】
さらに、ＰＣ３０には、ＯＳ３１の他に、もう一つのＯＳ４１が搭載されている。このＯＳ４１は、ＯＳ３１の制御下で機能するソフトウェアによって実現された仮想コンピュータに対してインストールされた形態になっている。
【０１３７】
なお、以下の説明において、ＯＳ３１とＯＳ４１を明示的に区別したい場合は、ＰＣ１の各部を直接制御する方をホストＯＳ３１、ホストＯＳ３１の制御下で機能する方をクライアントＯＳ４１とも称する。
【０１３８】
ＯＳ４１は、ＯＳ３１同様、マルチタスク機能を備えたもので、ＰＣ３０が備えるＣＰＵは、ＯＳ４１のマルチタスク機能により、複数のソフトウェアに基づく処理を時分割で並列に実行することができる。
【０１３９】
そして、このマルチタスク機能を利用して、ＯＳ４１の制御下では、本発明に関連するソフトウェアとして、ステータスモニタ４２、リードバックツール４３、情報分配部４５などが機能するように構成されている。
【０１４０】
また、ＯＳ４１も、カーネルドライバ４６を備え、このカーネルドライバ４６を介して、ＯＳ３１が備えるカーネルドライバ３８との間でデータをやり取り可能になっている。
なお、ＯＳ３１とＯＳ４１が、それぞれどのようなＯＳであるのかは任意であるが、例えば、アーキテクチャが全く異系統のＯＳ、あるいは、アーキテクチャは同系統であるもののバージョンが異なるＯＳなどを考えることができる。この場合、一方のＯＳの制御下では作動させることができないソフトウェアを、他方のＯＳの制御下で作動させる、といった運用が可能となる。
【０１４１】
あるいは、ＯＳ３１とＯＳ４１が、全く同じＯＳであってもよい。この場合、通常の運用を行う場合にはＯＳ３１の制御下で各種処理を実行させ、特殊な運用を行う場合にはＯＳ４１の制御下で各種処理を実行させる、といった使い分けができる。
【０１４２】
なお、ＯＳによって提供されるこれらの各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＯＳ３１、４１の双方が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。
【０１４３】
ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５等は、サーバーとして機能する情報分配部が、自身に対応するクライアントに対してデバイス情報を分配するように構成されており、この点は第１実施形態と同様である。
【０１４４】
すなわち、図７に示すように、情報分配部３５は、デバイス３から取得したデバイス情報をバッファ３５Ａ、３５Ｂに分配し、各バッファ３５Ａ、３５Ｂに格納されたデバイス情報をクライアント（ステータスモニタ３２、リードバックツール３３）に提供する。
【０１４５】
また、情報分配部３５は、デバイス３から取得したデバイス情報を、クライアントである情報分配部４５へも提供する。情報分配部４５は、情報分配部３５から取得したデバイス情報をバッファ４５Ａ、４５Ｂに分配する。そして、各バッファ４５Ａ、４５Ｂに格納されたデバイス情報をクライアント（ステータスモニタ４２、リードバックツール４３）に提供する。
【０１４６】
一方、上記第１実施形態では、情報分配部１５と情報分配部２５が、別ＰＣ上で機能するように構成されていたのに対し、第２実施形態では、情報分配部３５と情報分配部４５が、同一ＰＣ上の別ＯＳ上で機能するように構成されており、この点では相違する。
【０１４７】
このような相違点があるため、情報分配部３５と情報分配部４５は、互いに情報伝送を行う際に、第１実施形態とは異なる方式で情報伝送を行うことになる。具体的には、第１実施形態では、ＬＡＮ５経由での通信が可能なプロトコル（例えば、ＴＣＰ／ＩＰ等）を使って情報伝送を行っていたが、第２実施形態では、ＯＳ３１、４１が、カーネルドライバ３８、４６経由でＰＣ１内のメモリを共有し、情報伝送を実現する。
【０１４８】
ただし、ＯＳ３１とＯＳ４１との間で情報伝送を行うに当たって、どのような方式を採用するかは任意である。
例えば、ＯＳ３１とＯＳ４１との間に仮想ネットワークを実現するモジュールを介在させてもよい。この場合、アプリケーション側（ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５等）からは、第１実施形態と全く同様の通信方式を利用することができるようになる。
【０１４９】
なお、第２実施形態においても、ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５は、それぞれ同一のプログラムである。これらは同一のプリンタドライバインストールセットに包含され供給されるものである。ただし、本例では、便宜上、ＯＳ３１側とＯＳ４１側とで、その符号を変えてある。
【０１５０】
［情報分配部における主処理］
次に、上記のような情報分配部３５、４５の機能を実現するため、情報分配部３５、４５において実行される主処理について、図８および図９のフローチャートに基づいて説明する。この処理は、情報分配部３５、４５を機能させたい時点で開始されていればよい処理であり、例えば、ＯＳ３１、ＯＳ４１の起動に伴って開始される処理となっていればよい。
【０１５１】
なお、第２実施形態においても、情報分配部３５、４５は全く同等に機能するが、第１実施形態同様、サーバーとしての機能については情報分配部３５を例に挙げて説明し、クライアントとしての機能については情報分配部４５を例に挙げて説明する。また、第１実施形態と差異のない処理等については、第２実施形態では一部説明を省略する。
【０１５２】
主処理を開始すると、図８に示すように、情報分配部３５は、まず、クライアント（ステータスモニタ３２、リードバックツール３３、および情報分配部４５）からの要求待ちになる（Ｓ５０５）。ここで、クライアント（ステータスモニタ３２、リードバックツール３３、および情報分配部４５）のいずれかから何らかの要求があるとＳ５０５の処理を抜ける。
【０１５３】
続いて、情報分配部３５は、ＰＣ３０内のクライアントから受けた新規クライアント追加要求か否かを判断する（Ｓ５１０）。Ｓ５１０の処理において、新規クライアント追加要求であった場合（Ｓ５１０：ＹＥＳ）、情報分配部３５は、要求元となったクライアントのＩＤをＰＣ３０内のメモリに記憶させる（Ｓ５１５）。
【０１５４】
次に、Ｓ５１５の処理を終えたら、要求元となったクライアントに対応するバッファを確保する（Ｓ５２０）。Ｓ５２０の処理で確保されるバッファは、図７に示したバッファ３５Ａ、３５Ｂに相当するものである。そして、Ｓ５２０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。
【０１５５】
さて一方、上記Ｓ５１０の処理において、新規クライアント追加要求ではなかった場合（Ｓ５１０：ＮＯ）、続いて、情報分配部３５は、クライアント削除要求か否かを判断する（Ｓ５２５）。
【０１５６】
Ｓ５２５の処理において、クライアント削除要求であった場合（Ｓ５２５：ＹＥＳ）、情報分配部３５は、要求元となったクライアントに対応するバッファを削除する（Ｓ５３０）。そして、Ｓ５３０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。
【０１５７】
一方、上記Ｓ５２５の処理において、クライアント削除要求ではなかった場合（Ｓ５２５：ＮＯ）、情報分配部３５は、新規コマンド送信要求であるか否かを判断する（Ｓ５３５）。
【０１５８】
Ｓ５３５の処理において、新規コマンド送信要求であった場合（Ｓ５３５：ＹＥＳ）、情報分配部３５は、送信要求されたＰＪＬコマンドをスプーラ経由で物理ポート１７を通じてデバイス３へ送信する（Ｓ５４０）。そして、Ｓ５４０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。
【０１５９】
一方、Ｓ５３５の処理において、新規コマンド送信要求ではなかった場合（Ｓ５３５：ＮＯ）、情報分配部３５、４５は、図９に示すように、ホストＯＳへの接続要求か否かを判断する（Ｓ６０５）。また、ホストＯＳへの接続要求ではなかった場合（Ｓ６０５：ＮＯ）、クライアントＯＳからの接続要求か否かを判断する（Ｓ６２５）。
【０１６０】
ここで、上記Ｓ６０５の処理では、例えば、クライアントＯＳ４１の制御下で機能する情報分配部４５がステータスモニタ４２からの要求を受けた結果、ホストＯＳ３１の制御下で機能する情報分配部３５との通信が必要となった場合に肯定判断がなされる。
【０１６１】
また、上記Ｓ６２５の処理では、例えば、ホストＯＳ３１の制御下で機能する情報分配部３５がクライアントＯＳ４１の制御下で機能する情報分配部４５からの要求を受けた結果、情報分配部４５との通信が必要となった場合に肯定判断がなされる。
【０１６２】
そこで、ここでは、上記の通り、情報分配部４５において上記Ｓ６０５の処理で肯定判断がなされ、情報分配部３５において上記Ｓ６２５の処理で肯定判断がなされた場合を例に挙げて説明を続ける。
【０１６３】
情報分配部４５において上記Ｓ６０５の処理で肯定判断がなされた場合（Ｓ６０５：ＹＥＳ）、ホストＯＳ３１の接続情報を取得する（Ｓ６１０）。ホストＯＳ３１の接続情報は、ホストＯＳ３１との間で情報伝送を行う上で必要となる情報である。
【０１６４】
続いて、情報分配部４５は、ホストＯＳ３１に対し、接続要求を発行し（Ｓ６１５）、ホストＯＳ３１がクライアントＯＳ４１と接続するために必要となる情報を送信する（Ｓ６２０）。
【０１６５】
上記Ｓ６１５の処理により、本実施形態の場合、情報分配部４５から情報分配部３５へ接続要求が送信されることになる。情報分配部４５からの接続要求が送信された場合、Ｓ５０５の処理によってクライアントからの要求待ちとなっていた情報分配部３５は、Ｓ５０５の処理を抜けた後、Ｓ６２５の処理でクライアントＯＳ４１からの接続要求であると判断する（Ｓ６２５：ＹＥＳ）。
【０１６６】
この場合、情報分配部３５は、接続に必要な情報を受信する（Ｓ６３０）。Ｓ６３０の処理で受信する情報は、上述したＳ６２０の処理によって送信された情報である。この情報を受信した情報分配部３５は、情報分配部４５をクライアントの一つとして認識することになり、そのクライアントのＩＤをメモリに記憶する（Ｓ６３５）。
【０１６７】
なお、以上説明したＳ６１０〜Ｓ６２０の処理、あるいは、Ｓ６３０〜Ｓ６３５の処理を終えたら、いずれの場合とも、Ｓ５０５の処理へと戻る。
さて、上記Ｓ６２５の処理において、クライアントＯＳ４１からの接続要求でもないと判断した場合（Ｓ６２５：ＮＯ）、本実施形態では、クライアントからデバイス情報のリード要求を受けたものと判断する。
【０１６８】
この場合、情報分配部３５は、クライアントが付与したＩＤに基づいて要求元となったクライアントに対応するバッファをサーチし、そのバッファ内に記憶されたデバイス情報（後述する常駐スレッド処理により記憶されたもの）を読み出す（Ｓ６４０）。そして、読み出したデバイス情報を要求元となったクライアントに送信する（Ｓ６４５）。
【０１６９】
そして、Ｓ６４５の処理を終えたら、送信分のデバイス情報をバッファから削除して（Ｓ６５０）、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。
［情報分配部における常駐スレッド処理］
次に、情報分配部３５、４５において主処理と並列に実行される常駐スレッド処理について、図１０のフローチャートに基づいて説明する。なお、先に説明した主処理（図８、図９参照）の場合と同様に、サーバーとして機能する部分に関しては、情報分配部３５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部４５を例に挙げて説明する。
【０１７０】
この処理を開始すると、情報分配部３５、４５は、ターゲット（デバイス情報の取得対象となるデバイス）は自ＯＳ制御下のデバイスか否かを判断する（Ｓ７０５）。
本実施形態の場合、情報分配部４５であれば、ターゲットが情報分配部３５となり、これは自ＯＳ制御下のデバイスではないので（Ｓ７０５：ＮＯ）、ホストＯＳ３１側の情報分配部３５よりデバイス情報を取得する（Ｓ７１０）。また、情報分配部３５であれば、ターゲットがデバイス３となり、これは自ＯＳ制御下のデバイスなので（Ｓ７０５：ＹＥＳ）、デバイス３からデバイス情報を読み取る（Ｓ７１５）。
【０１７１】
ここで、まだデバイス３に対してＰＪＬコマンドが送信されていない場合など、デバイス３側がデバイス情報を送信できる状態にない場合は、Ｓ７１０またはＳ７１５の処理で待機状態になり、何らかの情報を取得したらＳ７１０またはＳ７１５の処理を抜ける。
【０１７２】
続いて、情報分配部３５は、ループ処理にてすべてのクライアントを順に処理するため、未処理のクライアントに対応するＩＤの中から、処理対象とするクライアントに対応する１つのＩＤを選ぶ（Ｓ７２０）。
【０１７３】
次に、情報分配部３５は、Ｓ７２０の処理で選んだＩＤに対応するクライアントは、クライアントＯＳ側の情報分配部か否かを判断する（Ｓ７２５）。ここで、情報分配部３５が、情報分配部４５のＩＤ（ＣＬ−１Ｃ）を選択していれば（Ｓ７２５：ＹＥＳ）、クライアントＯＳ側の情報分配部４５へデバイス情報を送信し（Ｓ７３０）、後述するＳ７５０の処理へと進む。
【０１７４】
一方、クライアントＯＳ側の情報分配部４５のＩＤを選択していなければ（Ｓ７２５：ＮＯ）、情報分配部３５は、Ｓ７２０の処理で選んだＩＤに対応するバッファに十分な空き領域があるか否かを判断する（Ｓ７３５）。
【０１７５】
そして、バッファに十分な空き領域がない場合は（Ｓ７３５：ＹＥＳ）、古いデバイス情報を捨ててバッファ内の領域を空ける（Ｓ７４０）。一方、バッファに十分な空き領域がある場合は（Ｓ７３５：ＮＯ）、Ｓ７４０の処理をスキップする。
【０１７６】
こうしてＳ７３５の処理またはＳ７４０の処理を終えたら、続いて、情報分配部３５は、Ｓ７１５の処理で読み取ったデバイス情報を、Ｓ７２０の処理で選んだＩＤに対応するバッファに追記書き込みする（Ｓ７４５）。このＳ７４５の処理により、バッファ３５Ａ、３５Ｂにはデバイス情報が格納され、このデバイス情報が上述したＳ６４０の処理によってバッファ３５Ａ、３５Ｂから読み出されることになる。
【０１７７】
そして、Ｓ７３０またはＳ７４５の処理を終えたら、上記Ｓ５１５またはＳ６３５の処理で記憶されたすべてのＩＤについての処理が終了したか否かを判断する（Ｓ７５５）。その判断の結果、終了していなければ（Ｓ７５５：ＮＯ）、Ｓ７２０の処理へと戻り、再びＳ７２０〜Ｓ７５５の処理を繰り返す。
【０１７８】
一方、上記Ｓ５１５またはＳ６３５の処理で記憶されたすべてのＩＤについての処理が終了した場合（Ｓ７５５：ＹＥＳ）、この常駐スレッド処理を終了するか否かを判断する（Ｓ７５５）。
【０１７９】
その判断の結果、終了する場合は（Ｓ７５５：ＹＥＳ）、常駐スレッド処理を終了する。また、常駐スレッド処理を終了しない場合は（Ｓ７５５：ＮＯ）、１秒待機して（Ｓ７６０）、Ｓ７１５の処理へと戻り、再びＳ７１５以降の処理を繰り返す。
【０１８０】
以上のような常駐スレッド処理が情報分配部３５、４５において実行されることにより、Ｓ７１０またはＳ７１５の処理でデバイス情報を取得する毎に、Ｓ７２０〜Ｓ７５０のループ処理が実行される。その結果、このループ処理により、すべてのクライアントに対応するバッファ（３５Ａ、３５Ｂ、あるいは、４５Ａ、４５Ｂ）にデバイス情報が分配される。
【０１８１】
そして、このデバイス情報の分配が完了したら、１秒の待機（Ｓ７６０）を経て、再びデバイス情報を取得するための処理（Ｓ７０５〜Ｓ７１５）以降の処理が繰り返されることになる。
【０１８２】
［ホストＯＳ−クライアントＯＳ間での情報伝送方法の一例］
次に、ホストＯＳ−クライアントＯＳ間での情報伝送方法について、その一例を説明する。ただし、以下に説明する情報伝送方法は、あくまでも一例に過ぎず、ホストＯＳ−クライアントＯＳ間での情報伝送方法については、様々な具体的手法を考え得る。したがって、第２実施形態において、ホストＯＳ−クライアントＯＳ間で情報伝送を行うに当たって、どのような具体的手法を採用するかは任意である。
【０１８３】
本実施形態において、図１１に示すように、ホストＯＳ３１側では、ホストＯＳ側カーネルドライバ３８（クラスドライバ）経由で、メモリへのアクセスができる仕組みになっている。また、クライアントＯＳ４１側では、クライアントＯＳ側カーネルドライバ４６（クラスドライバ）経由でのリクエストが、ホストＯＳ側カーネルドライバ３８に渡り、その結果、メモリへのアクセスができる仕組みになっている。
【０１８４】
また、情報分配部３５、４５は、それぞれの処理の中で、カーネルドライバ３８、４６に対して指令を与えるための関数（ＡＰＩ；Application Program Interface）を呼び出すことにより、カーネルドライバ３８、４６に対して指令を与えることができる。
【０１８５】
ＡＰＩを利用して与えられる指令は、デバイスマネージャによってＩ／Ｏリクエストパケットと呼ばれる単位のデータとされ、そのデータがカーネルドライバ３８、４６に与えられる。また、カーネルドライバ３８、４６が相互にデータ通信を行う際にも、Ｉ／Ｏリクエストパケット単位でデータがやり取りされる。
【０１８６】
カーネルドライバ３８、４６は、常にクライアントからの要求に対して応答を返すかたちで機能する。そのため、カーネルドライバ３８、４６経由で一方から他方へデータ伝送を行う際には、まず、一方がカーネルドライバ３８、４６に対してデータ送信要求を発行し、カーネルドライバ３８、４６が、送信要求されたデータを受け取る。
【０１８７】
そして、カーネルドライバ３８、４６が受け取ったデータは、カーネルドライバ３８、４６がバッファに保持し、他方がカーネルドライバ３８、４６に対してデータ受信要求を発行した際に、カーネルドライバ３８、４６のバッファから他方へと伝送される。
【０１８８】
以上のような手順で情報を伝送するため、クライアントＯＳ４１側のカーネルドライバ４６が実行する処理を、図１２のフローチャートに示す。また、ホストＯＳ３１側のカーネルドライバ３８が実行する処理を、図１３のフローチャートに示す。
【０１８９】
クライアントＯＳ４１側のカーネルドライバ４６は、Ｉ／Ｏリクエストパケットを受け取った場合、図１２に示すように、まず、その要求が、ホスト側からの受信要求かホスト側への送信要求かを判断する（Ｓ８０５）。
【０１９０】
Ｓ８０５の処理において、ホスト側からの受信要求であれば（Ｓ８０５：ホスト側からの受信要求）、Ｒパケットをホスト側から受信する（Ｓ８１０）。そして、受信したデータをクライアントＯＳ４１側の情報分配部４５に渡して（Ｓ８１５）、処理を終了する。
【０１９１】
また、Ｓ８０５の処理において、ホスト側からへの送信要求であれば（Ｓ８０５：ホスト側への送信要求）、Ｗパケットをホスト側へ送信し（Ｓ８２０）、処理を終了する。
一方、ホストＯＳ３１側のカーネルドライバ３８は、Ｉ／Ｏリクエストパケットを受け取った場合、図１３に示すように、まず、その要求が、書き込み要求か読み込み要求かを判断する（Ｓ９０５）。
【０１９２】
Ｓ９０５の処理において、書き込み要求であった場合（Ｓ９０５：書き込み要求）、要求元がホストＯＳ３１側の情報分配部３５かクライアントＯＳ４１側のカーネルドライバ４６かを判断する（Ｓ９１０）。
【０１９３】
Ｓ９１０の処理において、要求元がホストＯＳ３１側の情報分配部３５であった場合（Ｓ９１０：ホストＯＳ側情報分配部）、ホストＯＳ３１側の情報分配部３５からのデータをＲデータバッファに格納し（Ｓ９２０）、処理を終了する。Ｒデータバッファは、ホストＯＳ３１側の情報分配部３５からクライアントＯＳ４１側のカーネルドライバ４６へと伝送されるデータが格納されるバッファである。
【０１９４】
Ｓ９１０の処理において、要求元がクライアントＯＳ４１側のカーネルドライバ４６であった場合（Ｓ９１０：クライアントＯＳ側カーネルドライバ）、クライアントＯＳ４１側のカーネルドライバ４６からのデータをＷデータバッファに格納し（Ｓ９２０）、処理を終了する。
【０１９５】
Ｗデータバッファは、クライアントＯＳ４１側のカーネルドライバ４６からホストＯＳ３１側の情報分配部３５へと伝送されるデータが格納されるバッファである。このように、ホストＯＳ３１側のカーネルドライバ３８は、情報分配部３５−カーネルドライバ４６間で伝送されるデータを、ＲデータバッファおよびＷデータバッファ、以上２つのバッファを介して伝送する。
【０１９６】
Ｓ９０５の処理において、読み込み要求であった場合（Ｓ９０５：読み込み要求）、要求元がホストＯＳ３１側の情報分配部３５かクライアントＯＳ４１側のカーネルドライバ４６かを判断する（Ｓ９２５）。
【０１９７】
Ｓ９２５の処理において、要求元がホストＯＳ３１側の情報分配部３５であった場合（Ｓ９２５：ホストＯＳ側情報分配部）、Ｗデータバッファ内のデータをホストＯＳ３１側の情報分配部３５に渡し（Ｓ９３０）、処理を終了する。
【０１９８】
Ｓ９２５の処理において、要求元がクライアントＯＳ４１側のカーネルドライバ４６であった場合（Ｓ９２５：クライアントＯＳ側カーネルドライバ）、Ｒデータバッファ内のデータをクライアントＯＳ４１側のカーネルドライバ４６に渡し（Ｓ９３５）、処理を終了する。
【０１９９】
この例にあっては、クライアントＯＳ側のＳ８１０の処理で受信されるデータは、ホストＯＳ側のＳ９１５の処理にてホストＯＳ側の情報分配部３５より受け取り、Ｓ９３５の処理にてクライアントＯＳ側に渡されたものである。また、クライアントＯＳ側のＳ８２０の処理で送信されたデータは、ホストＯＳ側のＳ９２０の処理にて受け取られ、Ｓ９３０の処理にてホストＯＳ側の情報分配部３５に渡される。
【０２００】
以上、一例を挙げて説明したような方法で、ホストＯＳ−クライアントＯＳ間での情報伝送を実現することができる。
［第２実施形態の効果］
以上説明したように、上記第２実施形態においても、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。
【０２０１】
したがって、ホストＯＳ３１およびクライアントＯＳ４１の内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、ホストＯＳ３１およびクライアントＯＳ４１それぞれの制御下にある複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。
【０２０２】
さらに、デバイス情報をデバイス３から直接取得できる構成は、クライアントＯＳ４１の制御下には存在しないものの、情報分配部３５、４５が協働することにより、クライアントＯＳ４１側においてもデバイス情報を取得できる。
【０２０３】
したがって、クライアントＯＳ４１の制御下にある構成そのものは、デバイス３と直接通信できなくてもよく、その場合でも、クライアントＯＳ４１の制御下にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。
【０２０４】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０２０５】
例えば、上記実施形態では、デバイスの例としてプリンタを示したが、プリンタ機能を有する複合機（ＭＦＰ；Multi Function Product）、プリンタ機能を有するファクシミリ装置など、各種プリンタ系デバイスを対象とすることができるのはもちろんである。
【０２０６】
また、これらプリンタ系デバイス以外のデバイスであっても本発明の構成を採用することができる。また、ＰＪＬコマンドは、一般にプリンタ系デバイスを制御するためのコマンドとして採用されているものなので、プリンタ系デバイス以外のデバイスにおいて本発明の構成を採用する場合には、ＰＪＬコマンドとは異なる体系のコマンドを使用してもよい。
【０２０７】
また、上記実施形態では、ステータスモニタやリードバックツールから情報分配部への要求を契機として、デバイス情報がステータスモニタやリードバックツールへ提供されるようになっていたが、これに限らない。例えば、情報分配部側が能動的にステータスモニタやリードバックツールへ情報を提供するように構成してもよい。
【図面の簡単な説明】
【０２０８】
【図１】第１実施形態のシステム全体を示す概略構成図。
【図２】第１実施形態におけるデバイス情報の伝送経路を示す説明図。
【図３】第１実施形態の情報分配部において実行される主処理のフローチャート（その１）。
【図４】第１実施形態の情報分配部において実行される主処理のフローチャート（その２）。
【図５】第１実施形態の情報分配部において実行される常駐スレッド処理のフローチャート。
【図６】第２実施形態のシステム全体を示す概略構成図。
【図７】第２実施形態におけるデバイス情報の伝送経路を示す説明図。
【図８】第２実施形態の情報分配部において実行される主処理のフローチャート（その１）。
【図９】第２実施形態の情報分配部において実行される主処理のフローチャート（その２）。
【図１０】第２実施形態の情報分配部において実行される常駐スレッド処理のフローチャート。
【図１１】第２実施形態における情報分配部間の情報伝送経路を示す説明図。
【図１２】第２実施形態のクライアントＯＳ側カーネルドライバが実行する処理のフローチャート。
【図１３】第２実施形態のホストＯＳ側カーネルドライバが実行する処理のフローチャート。
【符号の説明】
【０２０９】
１，２，３０・・・パーソナルコンピュータ、３・・・デバイス、１２，２２，３２，４２・・・ステータスモニタ、１３，２３，３３，４３・・・リードバックツール、１５，２５，３５，４５・・・情報分配部、１６，３６・・・物理ポートドライバ、１７，３７・・・物理ポート、３１，４１・・・ＯＳ、３８，４６・・・カーネルドライバ。
【図１】
2008198026.tif 000003
【図２】
2008198026.tif 000004
【図３】
2008198026.tif 000005
【図４】
2008198026.tif 000006
【図５】
2008198026.tif 000007
【図６】
2008198026.tif 000008
【図７】
2008198026.tif 000009
【図８】
2008198026.tif 000010
【図９】
2008198026.tif 000011
【図１０】
2008198026.tif 000012
【図１１】
2008198026.tif 000013
【図１２】
2008198026.tif 000014
【図１３】
2008198026.tif 000015