JP4600402B2

JP4600402B2 - 情報分配システム、プログラム、および情報分配方法

Info

Publication number: JP4600402B2
Application number: JP2007033978A
Authority: JP
Inventors: 政敏門田
Original assignee: Brother Industries Ltd
Current assignee: Brother Industries Ltd
Priority date: 2007-02-14
Filing date: 2007-02-14
Publication date: 2010-12-15
Anticipated expiration: 2027-02-14
Also published as: JP2008198026A

Description

本発明は、情報分配システム、プログラム、および情報分配方法に関する。

従来、デバイスに関するデバイス情報をインターフェースを通じてデバイスから取得するとともに、そのデバイス情報を利用した情報処理を実施する技術が知られている（例えば、下記特許文献１参照）。
特開２０００−２９３３２４号公報

ところで、従来、一方の情報処理システムがデバイスに直接アクセスでき、且つ、他方の情報処理システムが前記一方の情報処理システム経由でデバイスにアクセスできるように構成されたシステムが知られている。

例えば、ネットワークを介して接続された二つのコンピュータの内、一方で機能する情報処理システムがデバイスに直接アクセスでき、他方で機能する情報処理システムが前記一方で機能する情報処理システム経由でデバイスにアクセスできるものがある。

また、単一のコンピュータに二つのＯＳ（Operating System）をインストールして運用している環境の中には、一方のＯＳ上で機能する仮想コンピュータに他方のＯＳをインストールした形態をとるものがある。このようなコンピュータにおいては、一方のＯＳ上で機能する情報処理システムがデバイスに直接アクセスでき、且つ、他方のＯＳ上で機能する情報処理システムが前記一方のＯＳ経由でデバイスにアクセスできる構成となる。

以上のようなシステムでは、上記のような二つの情報処理システムそれぞれにおいて、デバイスから取得したデバイス情報を利用した情報処理を実施したいことがある。
しかし、上記のような二つの情報処理システムそれぞれにおいて、上記特許文献１に記載の技術を採用した場合、二つの情報処理システムそれぞれがデバイスから情報を取得しようとする。そのため、デバイスが一度しか情報を提供しない場合、本来であれば一方の情報処理システムが取得すべき情報であっても、他方の情報処理システムが横取りしてしまい、上記一方の情報処理システムに必要な情報が渡らなくなるおそれがあった。

より具体的な例を挙げれば、デバイスが自身にとって都合のよいタイミングでデバイス情報を一度だけ用意し、このデバイス情報を、情報処理システムが自身にとって都合のよいタイミングで取得するように構成されたシステムがある。

このようなシステムの場合、デバイスがデバイス情報を用意した後、先に上記他方の情報処理システムがデバイス情報の取得を試みると、デバイス情報を取得してしまう。そのため、後からデバイス情報の取得を試みた上記一方の情報処理システムは、所期のデバイス情報を取得することができないことになる。

本発明は、このような問題を解決するためになされたものであり、その目的は、一つの情報処理システムだけがデバイス情報を取得してしまい、他の情報処理システムがデバイス情報を取得できなくなるのを防止可能な情報分配システムを提供することにある。また、そのような情報分配方法と、情報分配システムを構築するためのプログラムを提供することにある。

以下、本発明において採用した構成について説明する。
本発明の情報分配システムは、デバイスが接続された単一のコンピュータ上で機能する情報分配システムであって、前記コンピュータには、前記デバイスと通信可能な第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載されて、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されており、しかも、前記第１ＯＳの制御下で機能する情報処理システムとして、前記デバイスと通信可能な第１情報処理システムを備えるとともに、前記第２ＯＳの制御下で機能する情報処理システムとして、前記第１情報処理システムと通信可能な第２情報処理システムを備えてなり、前記第１情報処理システムは、前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手段と、前記第１取得手段によって取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手段とを備え、前記第２情報処理システムは、前記第１分配手段によって分配される前記デバイス情報を取得する第２取得手段と、前記第２取得手段によって取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手段とを備えたことを特徴とする。

上記のように構成された情報分配システムによれば、第１ＯＳおよび第２ＯＳの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１ＯＳおよび第２ＯＳそれぞれの制御下にある複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。

さらに、「デバイス情報をデバイスから取得する手段」は、第１ＯＳの制御下にのみ存在し、第２ＯＳの制御下には存在しないものの、第１分配手段および第２取得手段が協働することにより、第２ＯＳ側においてもデバイス情報を取得できる仕組みになっている。

したがって、第２ＯＳの制御下にある各手段は、デバイスと通信できなくてもよく、その場合でも、第２ＯＳの制御下にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。

なお、本発明の情報分配システムにおいて、前記第１分配手段および前記第２分配手段は、複数の前記分配先に対応付けて確保された複数のバッファそれぞれに前記デバイス情報を格納するとともに、複数の前記分配先それぞれから情報送信要求があった場合に、要求元となった前記分配先に対応する前記バッファに格納された前記デバイス情報を、前記要求元となった前記分配先へと送信するように構成してあると好ましい。

また、本発明の情報分配システムにおいて、前記第１分配手段および前記第２分配手段は、前記情報送信要求の要求元となった前記分配先への前記デバイス情報の送信を終えたら、前記情報送信要求の要求元となった前記分配先に対応する前記バッファから、当該バッファに格納された前記デバイス情報を削除するように構成してあると好ましい。

また、本発明の情報分配システムにおいて、前記第１分配手段および前記第２分配手段は、新たな前記分配先から分配先追加要求があった場合に、前記分配先追加要求の要求元となった前記分配先に対応する前記バッファを新たに確保する一方、既存の前記分配先から分配先削除要求があった場合に、前記分配先削除要求の要求元となった前記分配先に対応する前記バッファを解放するように構成してあると好ましい。

さらに、本発明の情報分配システムを構成するには、次のようなプログラムを利用すると好ましい。すなわち、前記コンピュータを、請求項１〜請求項４のいずれか一項に記載の情報分配システムとして機能させるプログラムであって、前記コンピュータを、前記第１ＯＳおよび前記第２ＯＳのうち、いずれの制御下にある状態かを判定する判定手段として機能させ、前記判定手段によって前記第１ＯＳの制御下にあると判定された場合には、前記コンピュータを、前記第１情報処理システムが備える各手段として機能させる一方、前記判定手段によって前記第２ＯＳの制御下にあると判定された場合には、前記コンピュータを、前記第２情報処理システムが備える各手段として機能させることを特徴とするプログラムを利用すると好ましい。

また、本発明の情報分配方法は、デバイスが接続された単一のコンピュータ上において実行される情報分配方法であって、前記コンピュータには、前記デバイスと通信可能な第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載されて、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されており、しかも、前記第１ＯＳの制御下で機能する情報処理システムとして、前記デバイスと通信可能な第１情報処理システムを備えるとともに、前記第２ＯＳの制御下で機能する情報処理システムとして、前記第１情報処理システムと通信可能な第２情報処理システムを備えてなり、前記第１情報処理システムには、前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手順と、前記第１取得手順において取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手順とを実行させ、前記第２情報処理システムには、前記第１分配手順の実行によって分配される前記デバイス情報を取得する第２取得手順と、前記第２取得手順において取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手順とを実行させることを特徴とする。

上記のように構成された情報分配方法によれば、第１ＯＳおよび第２ＯＳそれぞれの制御下にある複数の分配先へデバイス情報を分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。

したがって、第１ＯＳおよび第２ＯＳの内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、第１ＯＳおよび第２ＯＳそれぞれの制御下にある複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。

さらに、「デバイス情報をデバイスから取得する手順」は、第１ＯＳ側で実行されて、第２ＯＳ側では実行されないものの、第１分配手順および第２取得手順を実行することにより、第２ＯＳ側においてもデバイス情報を取得できる仕組みになっている。

したがって、第２ＯＳ側においては、デバイスと通信できなくてもよく、その場合でも、第２ＯＳの制御下にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。

次に、本発明の実施形態について、具体的な例を挙げて説明する。なお、以下に説明する実施形態のうち、第１実施形態は参考例であり、第２実施形態が本発明の実施形態に該当する。
（１）第１実施形態
まず、第１実施形態について説明する。

［システム全体の構成］
図１は、パーソナルコンピュータ１（以下、ＰＣ１という）、パーソナルコンピュータ２（以下、ＰＣ２という）、およびデバイス３を備えてなるシステム全体の構成を示した概略構成図である。

これらの内、ＰＣ１とＰＣ２は、ＬＡＮ（Local Area Network）５を介して通信可能になっている。また、ＰＣ１とデバイス３は、ＵＳＢ（Universal Serial Bus）インターフェースを介して通信可能になっている。なお、本実施形態において例示するデバイス３は、プリンタである。

本実施形態において、ＰＣ１、２にはマルチタスク機能を備えたＯＳが搭載され、ＰＣ１、２が備えるＣＰＵは、ＯＳのマルチタスク機能により、複数のソフトウェアに基づく処理を時分割で並列に実行することができる。

そして、このマルチタスク機能を利用して、ＰＣ１、２上では、本発明に関連するソフトウェアとして、後から詳述するステータスモニタ１２、２２、リードバックツール１３、２３、情報分配部１５、２５などが機能するようになっている。

また、ＰＣ１上では、ＯＳが備える標準機能として、物理ポートドライバ１６や、デバイス３へ出力する印刷データを印刷ジョブとして管理する印刷スプーラなどが機能するようになっている。デバイス３との通信を行う際には、物理ポートドライバ１６によってＰＣ１が備える物理ポート１７が制御される。

なお、ＯＳによって提供されるこれらの各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＰＣ１が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。

ＰＣ１、２上で機能するソフトウェアのうち、情報分配部１５はサーバーとして機能し、ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、情報分配部１５に対するクライアントとして機能する。また、情報分配部２５はサーバーとしても機能し、ステータスモニタ２２、およびリードバックツール２３は、情報分配部２５に対するクライアントとして機能する。

より詳しくは、情報分配部１５は、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれからの要求に応じて、デバイス３からデバイス情報を取得する。そして、取得したデバイス情報を、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれからの要求に応じて、ステータスモニタ１２、リードバックツール１３、および情報分配部２５それぞれへ提供する。

なお、ステータスモニタ１２、２２、リードバックツール１３、２３、情報分配部１５、２５は、それぞれ同一のプログラムである。これらは同一のプリンタドライバインストールセットに包含され供給されるものである。ただし、本例では、便宜上、ＰＣ１とＰＣ２とで、その符号を変えてある。

ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、それぞれが、デバイス情報を利用して各種情報処理を行っている。具体的には、例えば、ステータスモニタ１２は、取得したデバイス情報に基づいてデバイス３の状態をほぼリアルタイムで表示部に表示する処理を実行する。

リードバックツール１３は、デバイス情報を参照したい利用者が任意に操作してデバイス情報を取得するための専用ツールである。このリードバックツール１３を利用すれば、例えば、取得したデバイス情報に基づいてデバイス３のシリアル番号やファームウェアヴァージョン等の情報を表示する処理などを実行することができる。

情報分配部２５は、ステータスモニタ２２、およびリードバックツール２３それぞれからの要求に応じて、情報分配部１５からデバイス情報を取得する。そして、取得したデバイス情報を、ステータスモニタ２２、およびリードバックツール２３それぞれからの要求に応じて、ステータスモニタ２２、およびリードバックツール２３それぞれへ提供する。

つまり、本実施形態において、情報分配部１５、２５は、具体的なデバイス情報をどこから取得するか、どのクライアントに対するサーバーとなっているか、といった点が異なるものの、クライアントへデバイス情報を提供するという機能には差異がない。

さらに、図１においては図示を省略してあるが、ＰＣ２にデバイスが接続されている場合、情報分配部２５は、情報分配部１５と全く同様に、ＰＣ２に接続されたデバイスからデバイス情報を取得することができる。

また、この場合、情報分配部１５は、情報分配部２５に対するクライアントとして機能することもでき、ＰＣ２に接続されたデバイスから取得されたデバイス情報を、情報分配部２５から情報分配部１５へ提供することができる。

すなわち、情報分配部１５、２５は、どちらがサーバーとなり、どちらがクライアントとなるかについて、必要に応じて互いの立場を入れ替えることもできる。このようなことができるのは、情報分配部１５、２５が、全く同等な機能を備えた同一のプログラムだからである。

ただし、図１においては、サーバーとクライアントの関係を理解しやすくするため、ＰＣ２にはデバイスが接続されておらず、且つ、情報分配部１５がサーバー、情報分配部２５がクライアントとなる関係で機能する事例のみを図示してある。

なお、本実施形態では、情報分配部１５に対するクライアントとして、ステータスモニタ１２、リードバックツール１３、および情報分配部２５を例示してあるが、情報分配部１５に対するクライアントは、さらに並列にいくつ機能してもよい。また、各クライアントが処理を開始するタイミングや処理を終了するタイミング等は任意であり、クライアント毎に独立したタイミングで構わない。

同様に、情報分配部２５に対するクライアントも、ステータスモニタ２２、およびリードバックツール２３以外にいくつ機能してもよく、それら各クライアントによる処理の開始タイミングや終了タイミング等も任意である。

一方、デバイス３は、ＰＣ１側からの要求に応じて、デバイス３に関する情報であるデバイス情報をＰＣ１に対して提供する機能を備えている。
本実施形態の場合、デバイス情報としては、例えば、オンライン、オフラインといった「デバイスの状態に関する情報」、用紙サイズ毎の印刷枚数あるいは総印刷枚数といった「使用頻度に関する情報」が提供される。

また、ドラム交換時期などの「交換部品の使用度合に関する情報」、トナーないしインク残量や記録用紙残量といった「消耗品の消耗度合に関する情報」、紙詰まり回数といった「異常の発生回数に関する情報」なども提供される。これらのデバイス情報のうち、どれを提供するかは、ＰＣ１側から送信されてくるコマンドにより指定される。

本実施形態において、ＰＣ１がデバイス３に対してデバイス情報を要求する際には、ＰＣ１からデバイス３に対してＰＪＬコマンドを送信する。ＰＪＬ（Printer Job Language；プリンタジョブ言語）は、プリンタが備える各種機能を制御するために用意されたコマンド言語で、Hewlett-Packard社において開発され、その後他社でも採用された周知のものである。

ＰＣ１上で機能するクライアント（本実施形態の場合、ステータスモニタ１２、およびリードバックツール１３）が、情報分配部１５に対してコマンド送信要求を送信すると、このコマンド送信要求に応じて情報分配部１５がＰＪＬコマンドを出力する。

また、ＰＣ２上で機能するクライアント（本実施形態の場合、情報分配部２５）が、ＬＡＮ５経由で情報分配部１５に対してコマンド送信要求を送信する場合もある。この場合も、ＰＣ２上で機能するクライアントからのコマンド送信要求に応じて、情報分配部１５がＰＪＬコマンドを出力する。

情報分配部１５が出力したＰＪＬコマンドは、通常の印字データと同様に、プリンタドライバ経由で印刷スプーラに引き渡され、印刷スプーラは、受け取ったＰＪＬコマンドを印刷ジョブとして処理する。その結果、ＰＪＬコマンドは、物理ポート１７を通じてデバイス３へと出力されることになる。

デバイス３では、通常の印刷データと同様にＰＪＬコマンドを受信するが、受信したデータのヘッダ情報からＰＪＬコマンドであることを認識し、その内容を解析する。その解析の結果、デバイス３が応答可能なＰＪＬコマンドであった場合は、デバイス３が内蔵するメモリに蓄積されているデバイス情報を読み出して、そのデバイス情報をＰＣ１へと送信する。

ＰＣ１では、情報分配部１５がデバイス３から返されるデバイス情報を取得する。このとき、どのような方法でデバイス情報を取得するかは、ＰＣ１−デバイス３間の通信インターフェースによっても変わり得るが、本実施形態において、ＰＣ１−デバイス３間はＵＳＢインターフェースを介して接続されている。

そのため、デバイス情報を取得する際には、情報分配部１５が情報の受信を行い、受信した情報量が０（ゼロ）であった場合には再び情報の受信を繰り返し、その繰り返し処理によって情報を取得する、という方法がとられる。以下、このような方法でデバイス３からデバイス情報を読み取ることをリードバックを行うという。

リードバックを行うことにより、何らかのデータを受信した場合は、そのデータが所期のデバイス情報であるかどうかをチェックし、所期のデバイス情報でない場合は、さらに受信処理をやり直し、最終的に所期のデバイス情報を取得することになる。

デバイス情報を取得した情報分配部１５は、図２に示すように、ＰＣ１上で機能するクライアント（本実施形態の場合、ステータスモニタ１２、およびリードバックツール１３）それぞれに対応付けて用意されたバッファ１５Ａ、１５Ｂにデバイス情報を格納する。すなわち、バッファ１５Ａ、１５Ｂには、同じ内容のデバイス情報が格納される。

ただし、クライアントが、ＰＣ１とは別ＰＣにおいて機能する情報分配部となる場合は、別ＰＣ側でバッファが用意されるので、ＰＣ１ではバッファを用意せず、直ちにＰＣ２へデバイス情報を送信する。

具体例を交えて説明すると、クライアントが、ＰＣ２において機能する情報分配部２５となる場合、情報分配部２５がバッファ２５Ａ、２５Ｂを用意するので、情報分配部１５ではバッファを用意せず、直ちにＰＣ２へデバイス情報を送信する。ここで送信されたデバイス情報は、情報分配部２５がバッファ２５Ａ、２５Ｂに格納することになる。

さて、ＰＣ１では、情報分配部１５がＰＣ１上のクライアントのいずれかからの要求を受けた場合、情報分配部１５は、要求元のクライアントに対応するバッファに格納されたデバイス情報を、要求元のクライアントに対して送信する。

例えば、情報分配部１５がステータスモニタ１２からの要求を受けた場合であれば、情報分配部１５は、ステータスモニタ１２に対応するバッファ１５Ａに格納されたデバイス情報を、ステータスモニタ１２へ送信する。

その結果、要求元のクライアント（例えば、ステータスモニタ１２）は、デバイス情報を取得することができるので、取得したデバイス情報に基づく情報処理（例えば、デバイス３の状態をＰＣ１の表示部に表示する処理等）を実行することができる。

なお、ＰＣ２では、情報分配部２５が上記情報分配部１５と同様に機能する。すなわち、ＰＣ２上のクライアントのいずれかからの要求を受けた場合、情報分配部２５は、要求元のクライアントに対応するバッファに格納されたデバイス情報を、要求元のクライアントに対して送信する。

その結果、要求元のクライアント（例えば、ステータスモニタ２２）は、デバイス情報を取得することができるので、取得したデバイス情報に基づく情報処理（例えば、デバイス３の状態をＰＣ２の表示部に表示する処理等）を実行することができる。

さて、以上のような仕組みにより、ＰＣ１とデバイス３との間、さらにＰＣ１とＰＣ２との間では、ＰＪＬコマンドの送受信およびデバイス情報の送受信が行われる。ただし、デバイス３は、ＰＣ１側からの要求に応じてデバイス情報を提供するものの、クライアントのいずれが要求元であるのかを認識する仕組みにはなっていない。

そのため、ＰＣ１側からのリードバックを受ければ、その時点でデバイス３が要求されていたすべてのデバイス情報をＰＣ１側へ提供する。このような仕組みを採用しているため、情報分配部１５が設けられていない場合には、次のような問題が発生する。

例えば、ステータスモニタ１２、およびリードバックツール１３双方が、デバイス３に対して直接デバイス情報の取得要求を発しするように構成してある場合、デバイス３は、それらに対する応答として返すべきデバイス情報を用意する。

しかし、その後、例えば、ステータスモニタ１２が独自にデバイス３からのリードバックを行ってしまうと、リードバックツール１３に送信されるべきデバイス情報までステータスモニタ１２に送信されてしまう。この場合、送信済みのデバイス情報は、デバイス３の送信バッファ内から消されてしまう。

このような状況になった場合、その後、リードバックツール１３がデバイス３からのリードバックを行ったとしても、リードバックツール１３では、必要なデバイス情報を受け取れないという事態を招く。

上記同様の情報の取り合いは、クライアントとして機能する情報分配部２５とステータスモニタ１２との間でも発生し、クライアントとして機能する情報分配部２５とリードバックツール１３との間でも発生する。

上記情報分配部１５は、こうした事態が発生するのを防止するために設けられたものである。具体例を交えて説明すると、例えば、ステータスモニタ１２、およびリードバックツール１３それぞれがデバイス情報の取得要求を発した場合、それらに対する応答として返すべきデバイス情報をデバイス３が用意する。

情報分配部１５は、代表してデバイス３からのリードバックを行い、取得したデバイス情報を複数のバッファ１５Ａ、１５Ｂに複製する。また、ＰＣ２側に存在するクライアントである情報分配部２５に対しては、取得したデバイス情報を送信する。

このような処理が行われるため、ステータスモニタ１２、リードバックツール１３、および情報分配部２５は、独自にデバイス３からのリードバックを行わず、必ず情報分配部１５からデバイス情報の提供を受ける。

ここで、例えば、ステータスモニタ１２が情報分配部１５からデバイス情報の提供を受けた場合、送信済みのデバイス情報はバッファ１５Ａ内から消されてしまう。しかし、その後も、バッファ１５Ｂ内には、複製されたデバイス情報が残っているので、リードバックツール１３は、情報分配部１５からデバイス情報の提供を受けることができるのである。

なお、以上、情報分配部１５の役割について説明したが、情報分配部２５も全く同様に機能することで、ステータスモニタ２２、およびリードバックツール２３に対してデバイス情報を分配する。したがって、ステータスモニタ２２とリードバックツール２３がデバイス情報を取り合った結果、一方だけがデバイス情報を取得し、他方がデバイス情報を取得できない、といった事態に至るのを防ぐことができる。

［情報分配部における主処理］
次に、上記のような情報分配部１５、２５の機能を実現するため、情報分配部１５、２５において実行される主処理について、図３および図４のフローチャートに基づいて説明する。この処理は、情報分配部１５、２５を機能させたい時点で開始されていればよい処理であり、例えば、ＰＣ１の起動に伴って開始される処理となっていればよい。

なお、上述の通り、情報分配部１５、２５は、まったく同じプログラムである。ただし、図１においては、情報分配部１５がサーバーとして機能し、情報分配部２５がクライアントとして機能する事例を図示してある。

そこで、以下の説明においては、図１に示す具体的事例との関係も考慮し、サーバーとして機能する部分に関しては、情報分配部１５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部２５を例に挙げて説明する。

主処理を開始すると、図３に示すように、情報分配部１５（正確には、情報分配部１５として機能しているＰＣ１のＣＰＵ）は、まず、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）からの要求待ちになる（Ｓ１０５）。ここで、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）のいずれかから何らかの要求があるとＳ１０５の処理を抜ける。

続いて、情報分配部１５は、ＰＣ１内のクライアントから受けた新規クライアント追加要求か否かを判断する（Ｓ１１０）。
Ｓ１１０の処理において、新規クライアント追加要求であった場合（Ｓ１１０：ＹＥＳ）、情報分配部１５は、要求元となったクライアントのＩＤをＰＣ１内のメモリに記憶させる（Ｓ１１５）。

上記ＩＤは、新規クライアント追加要求ごとに情報分配部１５によりユニークな値が生成されるものである。このＩＤは、このクライアントからの追加要求終了時に、戻り値としてクライアントに渡される。

以後クライアントは、後述する別の要求（クライアント削除要求、新規コマンド送信要求、デバイス情報呼び出し情報など）を発行する際に、このＩＤを指定することにより、その処理対象が自分であることを情報分配部１５に知らせる。

図２に示すように、クライアント（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）には、それぞれユニークなＩＤ（図２に示した例では、ＣＬ−１Ａ、ＣＬ−１Ｂ、ＣＬ−１Ｃ）が付与される。

例えば、ステータスモニタ１２が新規クライアント追加要求を行った場合を例に挙げれば、その追加要求中にはＩＤ：ＣＬ−１Ａが含まれているので、Ｓ１１５の処理では、ＩＤ：ＣＬ−１Ａを記憶する。以後は、クライアントからの要求中にＩＤ：ＣＬ−１Ａが含まれていれば、その要求がステータスモニタ１２からの要求であることを、情報分配部１５側で認識できるようになる。

次に、Ｓ１１５の処理を終えたら、要求元となったクライアントに対応するバッファを確保する（Ｓ１２０）。Ｓ１２０の処理で確保されるバッファは、図２に示したバッファ１５Ａ、１５Ｂに相当するものである。例えば、ステータスモニタ１２が新規クライアント追加要求を行った場合を例に挙げれば、Ｓ１２０の処理によりバッファ１５Ａが確保されることになる。

そして、Ｓ１２０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。なお、このバッファは、先のＳ１１５の処理により、生成・記憶されたＩＤと関連づけられて管理される。すなわちＩＤが与えられれば、対応するバッファが特定できるように管理される。

さて一方、上記Ｓ１１０の処理において、新規クライアント追加要求ではなかった場合（Ｓ１１０：ＮＯ）、続いて、情報分配部１５は、クライアント削除要求か否かを判断する（Ｓ１２５）。

Ｓ１２５の処理において、クライアント削除要求であった場合（Ｓ１２５：ＹＥＳ）、情報分配部１５は、要求元となったクライアントに対応するバッファを削除する（Ｓ１３０）。この際、クライアントはＳ１１５の処理で自分に与えられたＩＤを指定して、この削除要求を発行する。

情報分配部１５は、その指定されたＩＤに対応するバッファを削除するのである。例えば、ステータスモニタ１２がクライアント削除要求を行った場合を例に挙げれば、Ｓ１３０の処理によりバッファ１５Ａが削除されることになる。そして、Ｓ１３０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。

一方、上記Ｓ１２５の処理において、クライアント削除要求ではなかった場合（Ｓ１２５：ＮＯ）、情報分配部１５は、新規コマンド送信要求であるか否かを判断する（Ｓ１３５）。本実施形態においては、各クライアント（（ステータスモニタ１２、リードバックツール１３、および情報分配部２５）からＰＪＬコマンドを含むコマンド送信要求がクライアントを示すＩＤとともに送信されてくる。

ただし、これは、各クライアントからＰＪＬコマンドを示すＰＪＬ識別子を含むコマンド送信要求を送信するとともに、送信されて来たＰＪＬ識別子に基づいて、情報分配部１５側でＰＪＬ識別子に対応するＰＪＬコマンドを用意するようにしてもよい。

Ｓ１３５の処理において、新規コマンド送信要求であった場合（Ｓ１３５：ＹＥＳ）、情報分配部１５は、送信要求されたＰＪＬコマンドをスプーラ経由で物理ポート１７を通じてデバイス３へ送信する（Ｓ１４０）。

なお、Ｓ１４０の処理では、送信要求されたＰＪＬコマンドが前記ＩＤと関連付けてメモリに記憶される。そして、Ｓ１４０の処理を終えたら、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。

一方、Ｓ１３５の処理において、新規コマンド送信要求ではなかった場合（Ｓ１３５：ＮＯ）、情報分配部１５、２５は、図４に示すように、他ＰＣへの接続要求か否かを判断する（Ｓ２０５）。また、他ＰＣへの接続要求ではなかった場合（Ｓ２０５：ＮＯ）、他ＰＣからの接続要求か否かを判断する（Ｓ２２５）。

ここで、上記Ｓ２０５の処理では、例えば、ＰＣ２において、情報分配部２５がステータスモニタ２２からの要求を受けた結果、ＰＣ１の情報分配部１５との通信が必要となった場合に肯定判断がなされる。

また、上記Ｓ２２５の処理では、例えば、ＰＣ１において、情報分配部１５が情報分配部２５からの要求を受けた結果、ＰＣ２の情報分配部２５との通信が必要となった場合に肯定判断がなされる。

そこで、ここでは、上記の通り、ＰＣ２の情報分配部２５において上記Ｓ２０５の処理で肯定判断がなされ、ＰＣ１の情報分配部１５において上記Ｓ２２５の処理で肯定判断がなされた場合を例に挙げて説明を続ける。

ＰＣ２の情報分配部２５において上記Ｓ２０５の処理で肯定判断がなされた場合（Ｓ２０５：ＹＥＳ）、他ＰＣ（本実施形態の場合、ＰＣ１）の接続情報を取得する（Ｓ２１０）。他ＰＣの接続情報は、他ＰＣのＩＰアドレス等、他ＰＣと通信を行う上で必要となる情報である。

本実施形態の場合、ＰＣ２は、デバイス３を共有プリンタとして認識するように構成されており、その共有プリンタに関する情報中にＳ２１０の処理で取得したい情報が含まれているので、その情報を他ＰＣの接続情報として取得する。

続いて、情報分配部２５は、ネットワーク経由で他ＰＣに対し、接続要求を発行し（Ｓ２１５）、他ＰＣが自ＰＣと接続するために必要となる自ＰＣ情報（自ＰＣのＩＰアドレス等）を送信する（Ｓ２２０）。

上記Ｓ２１５の処理により、本実施形態の場合、情報分配部２５から情報分配部１５へ接続要求が送信されることになる。情報分配部２５からの接続要求が送信された場合、Ｓ１０５の処理によってクライアントからの要求待ちとなっていた情報分配部１５は、Ｓ１０５の処理を抜けた後、Ｓ２２５の処理で他ＰＣからの接続要求であると判断する（Ｓ２２５：ＹＥＳ）。

この場合、情報分配部１５は、接続に必要な他ＰＣ情報を受信する（Ｓ２３０）。Ｓ２３０の処理で受信する他ＰＣ情報は、上述したＳ２２０の処理によって送信された情報である。この他ＰＣ情報を受信した情報分配部１５は、他ＰＣ（ＰＣ２）の情報分配部２５をクライアントの一つとして認識することになり、そのクライアントのＩＤをメモリに記憶する（Ｓ２３５）。

なお、以上説明したＳ２１０〜Ｓ２２０の処理、あるいは、Ｓ２３０〜Ｓ２３５の処理を終えたら、いずれの場合とも、Ｓ１０５の処理へと戻る。
ちなみに、上述の事例では、情報分配部２５がＳ２１０〜Ｓ２２０の処理を実行し、情報分配部１５がＳ２３０〜Ｓ２３５の処理を実行する場合を例に挙げて説明したが、これらの処理が入れ替わることもあり得る。

すなわち、情報分配部１５がＳ２１０〜Ｓ２２０の処理を実行し、情報分配部２５がＳ２３０〜Ｓ２３５の処理を実行する状態になることもある。そのような状態になるのは、先に説明した通り、情報分配部２５がＰＣ２に接続されたデバイスからデバイス情報を取得し、そのデバイス情報を情報分配部１５へ分配する場合である。

さて、以上が他ＰＣとの通信を行う場合についての説明であるが、上記Ｓ２２５の処理において、他ＰＣからの接続要求でもないと判断した場合（Ｓ２２５：ＮＯ）、本実施形態では、クライアントからデバイス情報のリード要求を受けたものと判断する。

すなわち、新規クライアント追加要求、クライアント削除要求、新規コマンド送信要求、他ＰＣへの接続要求、および他ＰＣからの接続要求、以上のいずれでもない要求としては、デバイス情報リード要求しか存在しないとの前提で処理を進める。

この場合、情報分配部１５は、クライアントが付与したＩＤに基づいて要求元となったクライアントに対応するバッファをサーチし、そのバッファ内に記憶されたデバイス情報（後述する常駐スレッド処理により記憶されたもの）を読み出す（Ｓ２４０）。そして、読み出したデバイス情報を要求元となったクライアントに送信する（Ｓ２４５）。

例えば、ステータスモニタ１２からデバイス情報のリード要求を受けた場合を例に挙げれば、Ｓ２４０の処理によりバッファ１５Ａからデバイス情報が読み出される。そして、そのデバイス情報が、Ｓ２４０の処理によってクライアントであるステータスモニタ１２に送信されることになる。

なお、Ｓ２４０の処理により、バッファから読み出されるデバイス情報は、本処理と並列に実行される常駐スレッド処理によりデバイス３から読み出されてバッファに格納されたものであるが、この常駐スレッド処理の詳細については後述する。

そして、Ｓ２４５の処理を終えたら、送信分のデバイス情報をバッファから削除して（Ｓ２５０）、Ｓ１０５の処理へと戻り、再びＳ１０５以降の処理を繰り返す。
［情報分配部における常駐スレッド処理］
次に、情報分配部１５、２５において主処理と並列に実行される常駐スレッド処理について、図５のフローチャートに基づいて説明する。なお、先に説明した主処理（図３、図４参照）の場合と同様に、サーバーとして機能する部分に関しては、情報分配部１５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部２５を例に挙げて説明する。

この処理を開始すると、情報分配部１５、２５は、ターゲット（デバイス情報の取得対象となるデバイス）は他ＰＣのデバイスか否かを判断する（Ｓ３０５）。
本実施形態の場合、ＰＣ２において情報分配部２５が情報分配部１５からデバイス情報を取得する場合であれば（Ｓ３０５：ＹＥＳ）、他ＰＣ（本実施形態の場合、ＰＣ１）よりデバイス情報を取得する（Ｓ３１０）。このデバイス情報は、情報元となるＰＣ（本例ではＰＣ１）で機能する情報分配部（本例では情報分配部１５）のＳ３３０の処理（後述）により送り出されたものである。

また、ＰＣ１において情報分配部１５がデバイス３からデバイス情報を取得する場合であれば（Ｓ３０５：ＮＯ）、デバイス３からデバイス情報を読み取る（Ｓ３１５）。
ここで、まだデバイス３に対してＰＪＬコマンドが送信されていない場合など、デバイス３側がデバイス情報を送信できる状態にない場合は、Ｓ３１０またはＳ３１５の処理で待機状態になり、何らかの情報を取得したらＳ３１０またはＳ３１５の処理を抜ける。

続いて、情報分配部１５は、ループ処理にてすべてのクライアントを順に処理するため、未処理のクライアントに対応するＩＤの中から、処理対象とするクライアントに対応する１つのＩＤを選ぶ（Ｓ３２０）。このＳ３２０の処理において、未処理のクライアントに対応するＩＤとは、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤのうち、Ｓ３２０の処理でまだ選ばれたことがないＩＤである。

次に、情報分配部１５は、Ｓ３２０の処理で選んだＩＤに対応するクライアントは、他ＰＣの情報分配部か否かを判断する（Ｓ３２５）。ここで、情報分配部１５が、情報分配部２５のＩＤ（ＣＬ−１Ｃ）を選択していれば（Ｓ３２５：ＹＥＳ）、他ＰＣであるＰＣ２の情報分配部２５へデバイス情報を送信し（Ｓ３３０）、後述するＳ３５０の処理へと進む。

一方、他ＰＣの情報分配部のＩＤを選択していなければ（Ｓ３２５：ＮＯ）、情報分配部１５は、Ｓ３２０の処理で選んだＩＤに対応するバッファに十分な空き領域があるか否かを判断する（Ｓ３３５）。

そして、バッファに十分な空き領域がない場合は（Ｓ３３５：ＹＥＳ）、古いデバイス情報を捨ててバッファ内の領域を空ける（Ｓ３４０）。一方、バッファに十分な空き領域がある場合は（Ｓ３３５：ＮＯ）、Ｓ３４０の処理をスキップする。

こうしてＳ３３５の処理またはＳ３４０の処理を終えたら、続いて、情報分配部１５は、Ｓ３１５の処理で読み取ったデバイス情報を、Ｓ３２０の処理で選んだＩＤに対応するバッファに追記書き込みする（Ｓ３４５）。このＳ３４５の処理により、バッファ１５Ａ、１５Ｂにはデバイス情報が格納され、このデバイス情報が上述したＳ２４０の処理によってバッファ１５Ａ、１５Ｂから読み出されることになる。

そして、Ｓ３３０またはＳ３４５の処理を終えたら、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤについての処理が終了したか否かを判断する（Ｓ３５５）。その判断の結果、終了していなければ（Ｓ３５５：ＮＯ）、Ｓ３２０の処理へと戻り、再びＳ３２０〜Ｓ３５５の処理を繰り返す。

一方、上記Ｓ１１５またはＳ２３５の処理で記憶されたすべてのＩＤについての処理が終了した場合（Ｓ３５５：ＹＥＳ）、この常駐スレッド処理を終了するか否かを判断する（Ｓ３５５）。

その判断の結果、終了する場合は（Ｓ３５５：ＹＥＳ）、常駐スレッド処理を終了する。また、常駐スレッド処理を終了しない場合は（Ｓ３５５：ＮＯ）、１秒待機して（Ｓ３６０）、Ｓ３１５の処理へと戻り、再びＳ３１５以降の処理を繰り返す。

以上のような常駐スレッド処理が情報分配部１５、２５において実行されることにより、Ｓ３１０またはＳ３１５の処理でデバイス情報を取得する毎に、Ｓ３２０〜Ｓ３５０のループ処理が実行される。その結果、このループ処理により、すべてのクライアントに対応するバッファ（１５Ａ、１５Ｂ、あるいは、２５Ａ、２５Ｂ）にデバイス情報が分配される。

そして、このデバイス情報の分配が完了したら、１秒の待機（Ｓ３６０）を経て、再びデバイス情報を取得するための処理（Ｓ３０５〜Ｓ３１５）以降の処理が繰り返されることになる。

［第１実施形態の効果］
以上説明したように、上記第１実施形態においては、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。

したがって、ＰＣ１およびＰＣ２の内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、ＰＣ１およびＰＣ２それぞれが備える複数のクライアントに関しても、一つのクライアントにデバイス情報が提供されたことが原因で、他のクライアントにデバイス情報を提供できなくなることがない。

さらに、デバイス３からデバイス情報を取得する手段は、ＰＣ１にのみ存在し、ＰＣ２には存在しないものの、情報分配部１５および情報分配部２５が協働することにより、ＰＣ２においてもデバイス情報を取得できる仕組みになっている。

したがって、ＰＣ２側にある手段は、デバイス３と直接通信できなくてもよく、その場合でも、ＰＣ２内にある複数のクライアントに、何ら問題なくデバイス情報を提供することができる。

（２）第２実施形態
次に、第２実施形態について説明する。
［システム全体の構成］
図６は、パーソナルコンピュータ３０（以下、ＰＣ３０という）、およびデバイス３を備えてなるシステム全体の構成を示した概略構成図である。

本実施形態において例示するデバイス３も、第１実施形態同様、ＰＪＬに対応したプリンタであり、ＰＣ３０とデバイス３は、ＵＳＢインターフェースを介して通信可能になっている。

また、ＰＣ３０には、第１実施形態同様、マルチタスク機能を備えたＯＳ３１が搭載されている。このＯＳ３１の制御下で、ステータスモニタ３２、リードバックツール３３、情報分配部３５、物理ポートドライバ３６などが機能する点、物理ポート３７を介してデバイス３との通信を行う点も、第１実施形態同様である。

また、第１実施形態では明示しなかったが、ＯＳ３１は、カーネルドライバ３８を備えている。カーネルドライバ３８は、ＯＳ３１が提供する機能を実現する上で中心的な役割を果たすモジュールで、例えば、ＰＣ１が備えるメモリに対する入出力（リード／ライト）機能等は、カーネルドライバ３８によって管理される。

さらに、ＰＣ３０には、ＯＳ３１の他に、もう一つのＯＳ４１が搭載されている。このＯＳ４１は、ＯＳ３１の制御下で機能するソフトウェアによって実現された仮想コンピュータに対してインストールされた形態になっている。

なお、以下の説明において、ＯＳ３１とＯＳ４１を明示的に区別したい場合は、ＰＣ１の各部を直接制御する方をホストＯＳ３１、ホストＯＳ３１の制御下で機能する方をクライアントＯＳ４１とも称する。

ＯＳ４１は、ＯＳ３１同様、マルチタスク機能を備えたもので、ＰＣ３０が備えるＣＰＵは、ＯＳ４１のマルチタスク機能により、複数のソフトウェアに基づく処理を時分割で並列に実行することができる。

そして、このマルチタスク機能を利用して、ＯＳ４１の制御下では、本発明に関連するソフトウェアとして、ステータスモニタ４２、リードバックツール４３、情報分配部４５などが機能するように構成されている。

また、ＯＳ４１も、カーネルドライバ４６を備え、このカーネルドライバ４６を介して、ＯＳ３１が備えるカーネルドライバ３８との間でデータをやり取り可能になっている。
なお、ＯＳ３１とＯＳ４１が、それぞれどのようなＯＳであるのかは任意であるが、例えば、アーキテクチャが全く異系統のＯＳ、あるいは、アーキテクチャは同系統であるもののバージョンが異なるＯＳなどを考えることができる。この場合、一方のＯＳの制御下では作動させることができないソフトウェアを、他方のＯＳの制御下で作動させる、といった運用が可能となる。

あるいは、ＯＳ３１とＯＳ４１が、全く同じＯＳであってもよい。この場合、通常の運用を行う場合にはＯＳ３１の制御下で各種処理を実行させ、特殊な運用を行う場合にはＯＳ４１の制御下で各種処理を実行させる、といった使い分けができる。

なお、ＯＳによって提供されるこれらの各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＯＳ３１、４１の双方が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。

ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５等は、サーバーとして機能する情報分配部が、自身に対応するクライアントに対してデバイス情報を分配するように構成されており、この点は第１実施形態と同様である。

すなわち、図７に示すように、情報分配部３５は、デバイス３から取得したデバイス情報をバッファ３５Ａ、３５Ｂに分配し、各バッファ３５Ａ、３５Ｂに格納されたデバイス情報をクライアント（ステータスモニタ３２、リードバックツール３３）に提供する。

また、情報分配部３５は、デバイス３から取得したデバイス情報を、クライアントである情報分配部４５へも提供する。情報分配部４５は、情報分配部３５から取得したデバイス情報をバッファ４５Ａ、４５Ｂに分配する。そして、各バッファ４５Ａ、４５Ｂに格納されたデバイス情報をクライアント（ステータスモニタ４２、リードバックツール４３）に提供する。

一方、上記第１実施形態では、情報分配部１５と情報分配部２５が、別ＰＣ上で機能するように構成されていたのに対し、第２実施形態では、情報分配部３５と情報分配部４５が、同一ＰＣ上の別ＯＳ上で機能するように構成されており、この点では相違する。

このような相違点があるため、情報分配部３５と情報分配部４５は、互いに情報伝送を行う際に、第１実施形態とは異なる方式で情報伝送を行うことになる。具体的には、第１実施形態では、ＬＡＮ５経由での通信が可能なプロトコル（例えば、ＴＣＰ／ＩＰ等）を使って情報伝送を行っていたが、第２実施形態では、ＯＳ３１、４１が、カーネルドライバ３８、４６経由でＰＣ１内のメモリを共有し、情報伝送を実現する。

ただし、ＯＳ３１とＯＳ４１との間で情報伝送を行うに当たって、どのような方式を採用するかは任意である。
例えば、ＯＳ３１とＯＳ４１との間に仮想ネットワークを実現するモジュールを介在させてもよい。この場合、アプリケーション側（ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５等）からは、第１実施形態と全く同様の通信方式を利用することができるようになる。

なお、第２実施形態においても、ステータスモニタ３２、４２、リードバックツール３３、４３、情報分配部３５、４５は、それぞれ同一のプログラムである。これらは同一のプリンタドライバインストールセットに包含され供給されるものである。ただし、本例では、便宜上、ＯＳ３１側とＯＳ４１側とで、その符号を変えてある。

［情報分配部における主処理］
次に、上記のような情報分配部３５、４５の機能を実現するため、情報分配部３５、４５において実行される主処理について、図８および図９のフローチャートに基づいて説明する。この処理は、情報分配部３５、４５を機能させたい時点で開始されていればよい処理であり、例えば、ＯＳ３１、ＯＳ４１の起動に伴って開始される処理となっていればよい。

なお、第２実施形態においても、情報分配部３５、４５は全く同等に機能するが、第１実施形態同様、サーバーとしての機能については情報分配部３５を例に挙げて説明し、クライアントとしての機能については情報分配部４５を例に挙げて説明する。また、第１実施形態と差異のない処理等については、第２実施形態では一部説明を省略する。

主処理を開始すると、図８に示すように、情報分配部３５は、まず、クライアント（ステータスモニタ３２、リードバックツール３３、および情報分配部４５）からの要求待ちになる（Ｓ５０５）。ここで、クライアント（ステータスモニタ３２、リードバックツール３３、および情報分配部４５）のいずれかから何らかの要求があるとＳ５０５の処理を抜ける。

続いて、情報分配部３５は、ＰＣ３０内のクライアントから受けた新規クライアント追加要求か否かを判断する（Ｓ５１０）。Ｓ５１０の処理において、新規クライアント追加要求であった場合（Ｓ５１０：ＹＥＳ）、情報分配部３５は、要求元となったクライアントのＩＤをＰＣ３０内のメモリに記憶させる（Ｓ５１５）。

次に、Ｓ５１５の処理を終えたら、要求元となったクライアントに対応するバッファを確保する（Ｓ５２０）。Ｓ５２０の処理で確保されるバッファは、図７に示したバッファ３５Ａ、３５Ｂに相当するものである。そして、Ｓ５２０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。

さて一方、上記Ｓ５１０の処理において、新規クライアント追加要求ではなかった場合（Ｓ５１０：ＮＯ）、続いて、情報分配部３５は、クライアント削除要求か否かを判断する（Ｓ５２５）。

Ｓ５２５の処理において、クライアント削除要求であった場合（Ｓ５２５：ＹＥＳ）、情報分配部３５は、要求元となったクライアントに対応するバッファを削除する（Ｓ５３０）。そして、Ｓ５３０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。

一方、上記Ｓ５２５の処理において、クライアント削除要求ではなかった場合（Ｓ５２５：ＮＯ）、情報分配部３５は、新規コマンド送信要求であるか否かを判断する（Ｓ５３５）。

Ｓ５３５の処理において、新規コマンド送信要求であった場合（Ｓ５３５：ＹＥＳ）、情報分配部３５は、送信要求されたＰＪＬコマンドをスプーラ経由で物理ポート１７を通じてデバイス３へ送信する（Ｓ５４０）。そして、Ｓ５４０の処理を終えたら、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。

一方、Ｓ５３５の処理において、新規コマンド送信要求ではなかった場合（Ｓ５３５：ＮＯ）、情報分配部３５、４５は、図９に示すように、ホストＯＳへの接続要求か否かを判断する（Ｓ６０５）。また、ホストＯＳへの接続要求ではなかった場合（Ｓ６０５：ＮＯ）、クライアントＯＳからの接続要求か否かを判断する（Ｓ６２５）。

ここで、上記Ｓ６０５の処理では、例えば、クライアントＯＳ４１の制御下で機能する情報分配部４５がステータスモニタ４２からの要求を受けた結果、ホストＯＳ３１の制御下で機能する情報分配部３５との通信が必要となった場合に肯定判断がなされる。

また、上記Ｓ６２５の処理では、例えば、ホストＯＳ３１の制御下で機能する情報分配部３５がクライアントＯＳ４１の制御下で機能する情報分配部４５からの要求を受けた結果、情報分配部４５との通信が必要となった場合に肯定判断がなされる。

そこで、ここでは、上記の通り、情報分配部４５において上記Ｓ６０５の処理で肯定判断がなされ、情報分配部３５において上記Ｓ６２５の処理で肯定判断がなされた場合を例に挙げて説明を続ける。

情報分配部４５において上記Ｓ６０５の処理で肯定判断がなされた場合（Ｓ６０５：ＹＥＳ）、ホストＯＳ３１の接続情報を取得する（Ｓ６１０）。ホストＯＳ３１の接続情報は、ホストＯＳ３１との間で情報伝送を行う上で必要となる情報である。

続いて、情報分配部４５は、ホストＯＳ３１に対し、接続要求を発行し（Ｓ６１５）、ホストＯＳ３１がクライアントＯＳ４１と接続するために必要となる情報を送信する（Ｓ６２０）。

上記Ｓ６１５の処理により、本実施形態の場合、情報分配部４５から情報分配部３５へ接続要求が送信されることになる。情報分配部４５からの接続要求が送信された場合、Ｓ５０５の処理によってクライアントからの要求待ちとなっていた情報分配部３５は、Ｓ５０５の処理を抜けた後、Ｓ６２５の処理でクライアントＯＳ４１からの接続要求であると判断する（Ｓ６２５：ＹＥＳ）。

この場合、情報分配部３５は、接続に必要な情報を受信する（Ｓ６３０）。Ｓ６３０の処理で受信する情報は、上述したＳ６２０の処理によって送信された情報である。この情報を受信した情報分配部３５は、情報分配部４５をクライアントの一つとして認識することになり、そのクライアントのＩＤをメモリに記憶する（Ｓ６３５）。

なお、以上説明したＳ６１０〜Ｓ６２０の処理、あるいは、Ｓ６３０〜Ｓ６３５の処理を終えたら、いずれの場合とも、Ｓ５０５の処理へと戻る。
さて、上記Ｓ６２５の処理において、クライアントＯＳ４１からの接続要求でもないと判断した場合（Ｓ６２５：ＮＯ）、本実施形態では、クライアントからデバイス情報のリード要求を受けたものと判断する。

この場合、情報分配部３５は、クライアントが付与したＩＤに基づいて要求元となったクライアントに対応するバッファをサーチし、そのバッファ内に記憶されたデバイス情報（後述する常駐スレッド処理により記憶されたもの）を読み出す（Ｓ６４０）。そして、読み出したデバイス情報を要求元となったクライアントに送信する（Ｓ６４５）。

そして、Ｓ６４５の処理を終えたら、送信分のデバイス情報をバッファから削除して（Ｓ６５０）、Ｓ５０５の処理へと戻り、再びＳ５０５以降の処理を繰り返す。
［情報分配部における常駐スレッド処理］
次に、情報分配部３５、４５において主処理と並列に実行される常駐スレッド処理について、図１０のフローチャートに基づいて説明する。なお、先に説明した主処理（図８、図９参照）の場合と同様に、サーバーとして機能する部分に関しては、情報分配部３５を例に挙げて説明し、クライアントとして機能する部分に関しては、情報分配部４５を例に挙げて説明する。

この処理を開始すると、情報分配部３５、４５は、ターゲット（デバイス情報の取得対象となるデバイス）は自ＯＳ制御下のデバイスか否かを判断する（Ｓ７０５）。
本実施形態の場合、情報分配部４５であれば、ターゲットが情報分配部３５となり、これは自ＯＳ制御下のデバイスではないので（Ｓ７０５：ＮＯ）、ホストＯＳ３１側の情報分配部３５よりデバイス情報を取得する（Ｓ７１０）。また、情報分配部３５であれば、ターゲットがデバイス３となり、これは自ＯＳ制御下のデバイスなので（Ｓ７０５：ＹＥＳ）、デバイス３からデバイス情報を読み取る（Ｓ７１５）。

ここで、まだデバイス３に対してＰＪＬコマンドが送信されていない場合など、デバイス３側がデバイス情報を送信できる状態にない場合は、Ｓ７１０またはＳ７１５の処理で待機状態になり、何らかの情報を取得したらＳ７１０またはＳ７１５の処理を抜ける。

続いて、情報分配部３５は、ループ処理にてすべてのクライアントを順に処理するため、未処理のクライアントに対応するＩＤの中から、処理対象とするクライアントに対応する１つのＩＤを選ぶ（Ｓ７２０）。

次に、情報分配部３５は、Ｓ７２０の処理で選んだＩＤに対応するクライアントは、クライアントＯＳ側の情報分配部か否かを判断する（Ｓ７２５）。ここで、情報分配部３５が、情報分配部４５のＩＤ（ＣＬ−１Ｃ）を選択していれば（Ｓ７２５：ＹＥＳ）、クライアントＯＳ側の情報分配部４５へデバイス情報を送信し（Ｓ７３０）、後述するＳ７５０の処理へと進む。

一方、クライアントＯＳ側の情報分配部４５のＩＤを選択していなければ（Ｓ７２５：ＮＯ）、情報分配部３５は、Ｓ７２０の処理で選んだＩＤに対応するバッファに十分な空き領域があるか否かを判断する（Ｓ７３５）。

そして、バッファに十分な空き領域がない場合は（Ｓ７３５：ＹＥＳ）、古いデバイス情報を捨ててバッファ内の領域を空ける（Ｓ７４０）。一方、バッファに十分な空き領域がある場合は（Ｓ７３５：ＮＯ）、Ｓ７４０の処理をスキップする。

こうしてＳ７３５の処理またはＳ７４０の処理を終えたら、続いて、情報分配部３５は、Ｓ７１５の処理で読み取ったデバイス情報を、Ｓ７２０の処理で選んだＩＤに対応するバッファに追記書き込みする（Ｓ７４５）。このＳ７４５の処理により、バッファ３５Ａ、３５Ｂにはデバイス情報が格納され、このデバイス情報が上述したＳ６４０の処理によってバッファ３５Ａ、３５Ｂから読み出されることになる。

そして、Ｓ７３０またはＳ７４５の処理を終えたら、上記Ｓ５１５またはＳ６３５の処理で記憶されたすべてのＩＤについての処理が終了したか否かを判断する（Ｓ７５５）。その判断の結果、終了していなければ（Ｓ７５５：ＮＯ）、Ｓ７２０の処理へと戻り、再びＳ７２０〜Ｓ７５５の処理を繰り返す。

一方、上記Ｓ５１５またはＳ６３５の処理で記憶されたすべてのＩＤについての処理が終了した場合（Ｓ７５５：ＹＥＳ）、この常駐スレッド処理を終了するか否かを判断する（Ｓ７５５）。

その判断の結果、終了する場合は（Ｓ７５５：ＹＥＳ）、常駐スレッド処理を終了する。また、常駐スレッド処理を終了しない場合は（Ｓ７５５：ＮＯ）、１秒待機して（Ｓ７６０）、Ｓ７１５の処理へと戻り、再びＳ７１５以降の処理を繰り返す。

以上のような常駐スレッド処理が情報分配部３５、４５において実行されることにより、Ｓ７１０またはＳ７１５の処理でデバイス情報を取得する毎に、Ｓ７２０〜Ｓ７５０のループ処理が実行される。その結果、このループ処理により、すべてのクライアントに対応するバッファ（３５Ａ、３５Ｂ、あるいは、４５Ａ、４５Ｂ）にデバイス情報が分配される。

そして、このデバイス情報の分配が完了したら、１秒の待機（Ｓ７６０）を経て、再びデバイス情報を取得するための処理（Ｓ７０５〜Ｓ７１５）以降の処理が繰り返されることになる。

［ホストＯＳ−クライアントＯＳ間での情報伝送方法の一例］
次に、ホストＯＳ−クライアントＯＳ間での情報伝送方法について、その一例を説明する。ただし、以下に説明する情報伝送方法は、あくまでも一例に過ぎず、ホストＯＳ−クライアントＯＳ間での情報伝送方法については、様々な具体的手法を考え得る。したがって、第２実施形態において、ホストＯＳ−クライアントＯＳ間で情報伝送を行うに当たって、どのような具体的手法を採用するかは任意である。

本実施形態において、図１１に示すように、ホストＯＳ３１側では、ホストＯＳ側カーネルドライバ３８（クラスドライバ）経由で、メモリへのアクセスができる仕組みになっている。また、クライアントＯＳ４１側では、クライアントＯＳ側カーネルドライバ４６（クラスドライバ）経由でのリクエストが、ホストＯＳ側カーネルドライバ３８に渡り、その結果、メモリへのアクセスができる仕組みになっている。

また、情報分配部３５、４５は、それぞれの処理の中で、カーネルドライバ３８、４６に対して指令を与えるための関数（ＡＰＩ；Application Program Interface）を呼び出すことにより、カーネルドライバ３８、４６に対して指令を与えることができる。

ＡＰＩを利用して与えられる指令は、デバイスマネージャによってＩ／Ｏリクエストパケットと呼ばれる単位のデータとされ、そのデータがカーネルドライバ３８、４６に与えられる。また、カーネルドライバ３８、４６が相互にデータ通信を行う際にも、Ｉ／Ｏリクエストパケット単位でデータがやり取りされる。

カーネルドライバ３８、４６は、常にクライアントからの要求に対して応答を返すかたちで機能する。そのため、カーネルドライバ３８、４６経由で一方から他方へデータ伝送を行う際には、まず、一方がカーネルドライバ３８、４６に対してデータ送信要求を発行し、カーネルドライバ３８、４６が、送信要求されたデータを受け取る。

そして、カーネルドライバ３８、４６が受け取ったデータは、カーネルドライバ３８、４６がバッファに保持し、他方がカーネルドライバ３８、４６に対してデータ受信要求を発行した際に、カーネルドライバ３８、４６のバッファから他方へと伝送される。

以上のような手順で情報を伝送するため、クライアントＯＳ４１側のカーネルドライバ４６が実行する処理を、図１２のフローチャートに示す。また、ホストＯＳ３１側のカーネルドライバ３８が実行する処理を、図１３のフローチャートに示す。

クライアントＯＳ４１側のカーネルドライバ４６は、Ｉ／Ｏリクエストパケットを受け取った場合、図１２に示すように、まず、その要求が、ホスト側からの受信要求かホスト側への送信要求かを判断する（Ｓ８０５）。

Ｓ８０５の処理において、ホスト側からの受信要求であれば（Ｓ８０５：ホスト側からの受信要求）、Ｒパケットをホスト側から受信する（Ｓ８１０）。そして、受信したデータをクライアントＯＳ４１側の情報分配部４５に渡して（Ｓ８１５）、処理を終了する。

また、Ｓ８０５の処理において、ホスト側への送信要求であれば（Ｓ８０５：ホスト側への送信要求）、Ｗパケットをホスト側へ送信し（Ｓ８２０）、処理を終了する。
一方、ホストＯＳ３１側のカーネルドライバ３８は、Ｉ／Ｏリクエストパケットを受け取った場合、図１３に示すように、まず、その要求が、書き込み要求か読み込み要求かを判断する（Ｓ９０５）。

Ｓ９０５の処理において、書き込み要求であった場合（Ｓ９０５：書き込み要求）、要求元がホストＯＳ３１側の情報分配部３５かクライアントＯＳ４１側のカーネルドライバ４６かを判断する（Ｓ９１０）。

Ｓ９１０の処理において、要求元がホストＯＳ３１側の情報分配部３５であった場合（Ｓ９１０：ホストＯＳ側情報分配部）、ホストＯＳ３１側の情報分配部３５からのデータをＲデータバッファに格納し（Ｓ９２０）、処理を終了する。Ｒデータバッファは、ホストＯＳ３１側の情報分配部３５からクライアントＯＳ４１側のカーネルドライバ４６へと伝送されるデータが格納されるバッファである。

Ｓ９１０の処理において、要求元がクライアントＯＳ４１側のカーネルドライバ４６であった場合（Ｓ９１０：クライアントＯＳ側カーネルドライバ）、クライアントＯＳ４１側のカーネルドライバ４６からのデータをＷデータバッファに格納し（Ｓ９２０）、処理を終了する。

Ｗデータバッファは、クライアントＯＳ４１側のカーネルドライバ４６からホストＯＳ３１側の情報分配部３５へと伝送されるデータが格納されるバッファである。このように、ホストＯＳ３１側のカーネルドライバ３８は、情報分配部３５−カーネルドライバ４６間で伝送されるデータを、ＲデータバッファおよびＷデータバッファ、以上２つのバッファを介して伝送する。

Ｓ９０５の処理において、読み込み要求であった場合（Ｓ９０５：読み込み要求）、要求元がホストＯＳ３１側の情報分配部３５かクライアントＯＳ４１側のカーネルドライバ４６かを判断する（Ｓ９２５）。

Ｓ９２５の処理において、要求元がホストＯＳ３１側の情報分配部３５であった場合（Ｓ９２５：ホストＯＳ側情報分配部）、Ｗデータバッファ内のデータをホストＯＳ３１側の情報分配部３５に渡し（Ｓ９３０）、処理を終了する。

Ｓ９２５の処理において、要求元がクライアントＯＳ４１側のカーネルドライバ４６であった場合（Ｓ９２５：クライアントＯＳ側カーネルドライバ）、Ｒデータバッファ内のデータをクライアントＯＳ４１側のカーネルドライバ４６に渡し（Ｓ９３５）、処理を終了する。

この例にあっては、クライアントＯＳ側のＳ８１０の処理で受信されるデータは、ホストＯＳ側のＳ９１５の処理にてホストＯＳ側の情報分配部３５より受け取り、Ｓ９３５の処理にてクライアントＯＳ側に渡されたものである。また、クライアントＯＳ側のＳ８２０の処理で送信されたデータは、ホストＯＳ側のＳ９２０の処理にて受け取られ、Ｓ９３０の処理にてホストＯＳ側の情報分配部３５に渡される。

以上、一例を挙げて説明したような方法で、ホストＯＳ−クライアントＯＳ間での情報伝送を実現することができる。
［第２実施形態の効果］
以上説明したように、上記第２実施形態においても、デバイス情報を複数の分配先へ分配することができるので、各分配先において、デバイス情報を利用した情報処理を適切に実施することができる。

したがって、ホストＯＳ３１およびクライアントＯＳ４１の内、いずれか一方にデバイス情報が提供されたことが原因で、他方にデバイス情報を提供できなくなることがない。また、ホストＯＳ３１およびクライアントＯＳ４１それぞれの制御下にある複数の分配先に関しても、一つの分配先にデバイス情報が提供されたことが原因で、他の分配先にデバイス情報を提供できなくなることがない。

さらに、デバイス情報をデバイス３から直接取得できる構成は、クライアントＯＳ４１の制御下には存在しないものの、情報分配部３５、４５が協働することにより、クライアントＯＳ４１側においてもデバイス情報を取得できる。

したがって、クライアントＯＳ４１の制御下にある構成そのものは、デバイス３と直接通信できなくてもよく、その場合でも、クライアントＯＳ４１の制御下にある複数の分配先に、何ら問題なくデバイス情報を提供することができる。

［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

例えば、上記実施形態では、デバイスの例としてプリンタを示したが、プリンタ機能を有する複合機（ＭＦＰ；Multi Function Product）、プリンタ機能を有するファクシミリ装置など、各種プリンタ系デバイスを対象とすることができるのはもちろんである。

また、これらプリンタ系デバイス以外のデバイスであっても本発明の構成を採用することができる。また、ＰＪＬコマンドは、一般にプリンタ系デバイスを制御するためのコマンドとして採用されているものなので、プリンタ系デバイス以外のデバイスにおいて本発明の構成を採用する場合には、ＰＪＬコマンドとは異なる体系のコマンドを使用してもよい。

また、上記実施形態では、ステータスモニタやリードバックツールから情報分配部への要求を契機として、デバイス情報がステータスモニタやリードバックツールへ提供されるようになっていたが、これに限らない。例えば、情報分配部側が能動的にステータスモニタやリードバックツールへ情報を提供するように構成してもよい。

第１実施形態のシステム全体を示す概略構成図。第１実施形態におけるデバイス情報の伝送経路を示す説明図。第１実施形態の情報分配部において実行される主処理のフローチャート（その１）。第１実施形態の情報分配部において実行される主処理のフローチャート（その２）。第１実施形態の情報分配部において実行される常駐スレッド処理のフローチャート。第２実施形態のシステム全体を示す概略構成図。第２実施形態におけるデバイス情報の伝送経路を示す説明図。第２実施形態の情報分配部において実行される主処理のフローチャート（その１）。第２実施形態の情報分配部において実行される主処理のフローチャート（その２）。第２実施形態の情報分配部において実行される常駐スレッド処理のフローチャート。第２実施形態における情報分配部間の情報伝送経路を示す説明図。第２実施形態のクライアントＯＳ側カーネルドライバが実行する処理のフローチャート。第２実施形態のホストＯＳ側カーネルドライバが実行する処理のフローチャート。

１，２，３０・・・パーソナルコンピュータ、３・・・デバイス、１２，２２，３２，４２・・・ステータスモニタ、１３，２３，３３，４３・・・リードバックツール、１５，２５，３５，４５・・・情報分配部、１６，３６・・・物理ポートドライバ、１７，３７・・・物理ポート、３１，４１・・・ＯＳ、３８，４６・・・カーネルドライバ。

Claims

デバイスが接続された単一のコンピュータ上で機能する情報分配システムであって、
前記コンピュータには、前記デバイスと通信可能な第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載されて、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されており、しかも、前記第１ＯＳの制御下で機能する情報処理システムとして、前記デバイスと通信可能な第１情報処理システムを備えるとともに、前記第２ＯＳの制御下で機能する情報処理システムとして、前記第１情報処理システムと通信可能な第２情報処理システムを備えてなり、
前記第１情報処理システムは、
前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手段と、
前記第１取得手段によって取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手段と
を備え、
前記第２情報処理システムは、
前記第１分配手段によって分配される前記デバイス情報を取得する第２取得手段と、
前記第２取得手段によって取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手段と
を備えたことを特徴とする情報分配システム。
前記第１分配手段および前記第２分配手段は、複数の前記分配先に対応付けて確保された複数のバッファそれぞれに前記デバイス情報を格納するとともに、複数の前記分配先それぞれから情報送信要求があった場合に、要求元となった前記分配先に対応する前記バッファに格納された前記デバイス情報を、前記要求元となった前記分配先へと送信する
ことを特徴とする請求項１に記載の情報分配システム。
前記第１分配手段および前記第２分配手段は、前記情報送信要求の要求元となった前記分配先への前記デバイス情報の送信を終えたら、前記情報送信要求の要求元となった前記分配先に対応する前記バッファから、当該バッファに格納された前記デバイス情報を削除する
ことを特徴とする請求項２に記載の情報分配システム。
前記第１分配手段および前記第２分配手段は、新たな前記分配先から分配先追加要求があった場合に、前記分配先追加要求の要求元となった前記分配先に対応する前記バッファを新たに確保する一方、既存の前記分配先から分配先削除要求があった場合に、前記分配先削除要求の要求元となった前記分配先に対応する前記バッファを解放する
ことを特徴とする請求項２又は請求項３に記載の情報分配システム。
前記コンピュータを、請求項１〜請求項４のいずれか一項に記載の情報分配システムとして機能させるプログラムであって、
前記コンピュータを、前記第１ＯＳおよび前記第２ＯＳのうち、いずれの制御下にある状態かを判定する判定手段として機能させ、
前記判定手段によって前記第１ＯＳの制御下にあると判定された場合には、前記コンピュータを、前記第１情報処理システムが備える各手段として機能させる一方、前記判定手段によって前記第２ＯＳの制御下にあると判定された場合には、前記コンピュータを、前記第２情報処理システムが備える各手段として機能させる
ことを特徴とするプログラム。
デバイスが接続された単一のコンピュータ上において実行される情報分配方法であって、
前記コンピュータには、前記デバイスと通信可能な第１ＯＳと、前記第１ＯＳの制御下で機能する第２ＯＳが搭載されて、前記第１ＯＳと前記第２ＯＳがＯＳ間用通信手段を介して通信可能に構成されており、しかも、前記第１ＯＳの制御下で機能する情報処理システムとして、前記デバイスと通信可能な第１情報処理システムを備えるとともに、前記第２ＯＳの制御下で機能する情報処理システムとして、前記第１情報処理システムと通信可能な第２情報処理システムを備えてなり、
前記第１情報処理システムには、
前記デバイスに関するデバイス情報を前記デバイスから取得する第１取得手順と、
前記第１取得手順において取得された前記デバイス情報を、前記第１情報処理システム内にある分配先および前記第２情報処理システムへ分配する第１分配手順と
を実行させ、
前記第２情報処理システムには、
前記第１分配手順の実行によって分配される前記デバイス情報を取得する第２取得手順と、
前記第２取得手順において取得された前記デバイス情報を、前記第２情報処理システム内にある分配先へ分配する第２分配手順と
を実行させることを特徴とする情報分配方法。