(57)【要約】【課題】処理対象となるデバイスに対してより確実に状態情報要求指令を送信可能な状態情報取得処理プログラム、状態情報取得装置、および状態情報取得システムの提供。【解決手段】ＰＣにおいて、パーサーは、ＰｎＰマネージャからデバイス構成変更メッセージが届いた場合に(S710:YES，S770:YES)、プリンタ２と通信可能と判定されたら(S740)、プリンタ２に対して状態情報要求指令を送る(S790)。したがって、プリンタ２との通信ができないにもかかわらず(S740:NO)、プリンタ２に対して状態情報要求指令が送られてしまうことがない。また、プリンタ２との通信ができる場合には、プリンタ２に対して状態情報要求指令が送られるので、以後は、プリンタ２から適切に状態情報を取得することができ(S740:NO，S760:NO)、状態情報をステータスモニターＵＩに送ることにより(S820，S840)、状態情報をＰＣの表示部に表示することができる。【選択図】図１０
2007156512.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置と各種デバイスとの接続状態の変化を検知する検知手段、
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段、
前記検知手段によって前記各種デバイスとの接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段、および
前記処理対象デバイスから前記状態情報を取得する状態情報取得手段
として、前記情報処理装置に備えられたコンピュータを機能させることを特徴とする状態情報取得処理プログラム。
【請求項２】
前記検知手段は、前記各種デバイスとの接続状態の変化通知するための情報を、前記情報処理装置から受信することで、前記各種デバイスとの接続状態の変化を検知する
ことを特徴とする請求項１に記載の状態情報取得処理プログラム。
【請求項３】
前記コンピュータを、さらに、
前記状態情報取得手段によって前記処理対象デバイスから前記状態情報を取得できたか否かを判定する取得状況判定手段
として機能させるように構成されており、
前記状態情報要求指令手段は、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、さらに、前記取得状況判定手段によって前記状態情報を取得できなかったと判定されたら、前記処理対象デバイスに対して状態情報要求指令を送る手段とされている
ことを特徴とする請求項２に記載の状態情報取得処理プログラム。
【請求項４】
前記コンピュータを、さらに、
前記通信可否判定手段による判定結果に基づいて、前記処理対象デバイスと通信できない旨を示す通信不可情報を利用者に対して通知すべきか否かを判定する通知要否判定手段、および
前記通知要否判定手段によって前記通信不可情報を利用者に対して通知すべきと判定された場合に、前記通信不可情報を利用者に対して通知する通信不可情報通知手段
として機能させるように構成されていることを特徴とする請求項２または請求項３に記載の状態情報取得処理プログラム。
【請求項５】
前記通知要否判定手段は、前記通信可否判定手段によって前記処理対象デバイスと通信できないと判定された回数があらかじめ定められた規定回数以上となったことを条件の一つとして、当該条件を満足する場合に、前記通信不可情報を利用者に対して通知すべきと判定する手段とされている
ことを特徴とする請求項４に記載の状態情報取得処理プログラム。
【請求項６】
前記通知要否判定手段は、１度満足した条件に対しては、一旦条件が解除されるまでは、前記通信不可情報を利用者に対して通知すべきと判定しない手段とされている
ことを特徴とする請求項４または請求項５に記載の状態情報取得処理プログラム。
【請求項７】
前記コンピュータを、さらに、
前記状態情報取得手段が取得した前記状態情報を報知する状態情報報知手段
として機能させることを特徴とする請求項２〜請求項６のいずれかに記載の状態情報取得処理プログラム。
【請求項８】
前記コンピュータを、さらに、
前記通信可否判定手段によって前記処理対象デバイスと通信できないと判定された回数があらかじめ定められた規定回数以上となったことを条件の一つとして、当該条件を満足する場合に、前記状態情報取得手段による前記状態情報の取得を停止させる状態情報取得停止手段、および
前記状態情報取得停止手段により前記状態情報の取得が停止された後、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記状態情報取得手段による前記状態情報の取得を再開させる状態情報取得再開手段
として機能させることを特徴とする請求項２〜請求項７のいずれかに記載の状態情報取得処理プログラム。
【請求項９】
各種デバイスとの接続状態の変化を検知可能な検知手段と、
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段と、
前記検知手段によって前記各種デバイスとの接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、
前記処理対象デバイスから前記状態情報を取得する状態情報取得手段と
を備えたことを特徴とする状態情報取得装置。
【請求項１０】
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わる処理対象デバイスと、前記処理対処デバイスを接続可能な状態情報取得装置とを備えてなり、
前記状態情報取得装置は、
各種デバイスとの接続状態の変化を検知可能な検知手段と、
前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段と、
前記検知手段によって前記各種デバイスとの接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、
前記処理対象デバイスから前記状態情報を取得する状態情報取得手段とを備える
ことを特徴とする状態情報取得システム。
【請求項１１】
情報処理装置と各種デバイスとの接続状態の変化を検知する検知手段、
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段、
前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段、および
前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合に、前記処理対象デバイスに対して前記状態情報要求指令を送る状態情報要求指令手段
として、前記情報処理装置に備えられたコンピュータを機能させることを特徴とする状態情報取得処理プログラム。
【請求項１２】
各種デバイスとの接続状態の変化を検知する検知手段と、
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段と、
前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段と、
前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合に、前記処理対象デバイスに対して前記状態情報要求指令を送る状態情報要求指令手段と
を備えたことを特徴とする状態情報取得装置。
【請求項１３】
電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わる処理対象デバイスと、前記処理対処デバイスを接続可能な状態情報取得装置とを備えてなり、
前記状態情報取得装置は、
各種デバイスとの接続状態の変化を検知する検知手段と、
前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段と、
前記検知手段によって各種デバイスとの接続状態の変化が検知された場合に、前記状態情報報知手段が前記状態情報を報知している処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、
前記処理対象デバイスから前記状態情報を取得する状態情報取得手段とを備える
ことを特徴とする状態情報取得システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わる処理対象デバイスから、前記状態情報を取得する処理をコンピュータに実行させるための状態情報取得処理プログラムと、前記処理対象デバイスから前記状態情報を取得する状態情報取得装置、および前記処理対象デバイスと前記状態情報取得装置とを備えてなる状態情報取得システムに関する。
【背景技術】
【０００２】
従来、本件発明者は、プラグアンドプレイ機能を備えたＯＳ（Operating System）が搭載されたコンピュータにおいて、コンピュータに接続されたデバイスの電源がＯＮとなったこと、あるいは、デバイスとコンピュータとを結ぶ通信ケーブルが挿し込まれたことをＯＳが検出した場合に、ＯＳからのメッセージに基づいてステータスモニターを起動するシステムを提案している（下記特許文献１参照）。
【０００３】
このシステムにおいては、ステータスモニターの起動に伴って、デバイスの状態を示す状態情報の提供を要求する指令（以下、状態情報要求指令と称する。）がステータスモニターからデバイスに対して送信され、以後、デバイスから状態情報を取得することができるようになっていた。
【０００４】
なお、デバイスから取得された状態情報は、例えば、表示装置等に出力することができ、これにより、利用者がデバイスの状態を知ることができるので、例えば、下記特許文献１に記載されたプリンタの場合であれば、利用者が紙切れ、紙詰まり、インク・トナー切れ等が発生したことを知ることができた。また、デバイスから取得された状態情報は、表示する以外にも用途があり、例えば、ログファイルに状態情報を記録することにより、後から、管理者がログファイルを参照して各種管理を行うようなこともできた。
【特許文献１】特開２００１−２６５５４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１に記載の技術には、以下のような点で改良の余地があった。
コンピュータには、一般に、状態情報の取得処理を行う対象となるデバイス（以下、処理対象デバイスと称す。）以外にも、各種デバイスが接続されているが、プラグアンドプレイ機能を備えたＯＳの中には、各種デバイスの電源がＯＮとなった場合等に、デバイスの構成に変化があった旨のメッセージを通知することはできるものの、そのメッセージだけでは、処理対象デバイスの電源がＯＮとなったのか否かを判断できないものがあった。
【０００６】
そのため、単にデバイスの構成に変化があった旨のメッセージを受けたことを条件に、状態情報要求指令をデバイスに対して送信しようとしても、その状態情報要求指令がデバイスに伝わらず、以後の処理で不具合が発生するおそれがあった。
【０００７】
発生する具体的な不具合は、コンピュータとデバイスとの間の通信方式によっても変わり得る。例えば、上記特許文献１に記載のシステムの場合、処理対象デバイスがプリンタであるため、状態情報要求指令をスプーラ経由で送信するように構成してある。そのため、処理対象デバイスが実際にＯＮとなったか否かが定かでないまま、状態情報要求指令をスプーラ経由で送信すると、処理対象デバイスがＯＮとなっていなかった場合には、状態情報要求指令がスプーラ内で保留状態になってしまい、スプーラシステムから利用者にとって予期しないエラーメッセージが出力されるなどの問題を招くおそれがあった。
【０００８】
また、デバイスによっては、スプーラを経由することなく状態情報要求指令をコンピュータからデバイスへ送信できるものもあると考えられるが、例えば、単にコンピュータがデバイスに対して一方的に状態情報要求指令を送信するものにおいては、デバイスが状態情報要求指令を受信していないにもかかわらず、指令の送信を完了したものとして以降の処理を続けてしまうため、状態情報の取得時にエラーが発生する等の問題を招くおそれがあった。
【０００９】
また、上記特許文献１に記載の技術では、クラスドライバーがステータスモニターを起動している。ところが、ＯＳによっては、クラスドライバーを一般ベンダーが作成することが認められていないもの、あるいは、クラスドライバーの作成方法が公開されていないものがあり、そのようなＯＳには上記特許文献１に記載の技術を使用することはできなかった。
【００１０】
また、上記特許文献１に記載の技術では、デバイスがＵＳＢ（Universal Serial Bus）ポートから外されたり、デバイスの電源がＯＦＦされたときにステータスモニターが終了しているため、ステータスモニターの表示を見ていた利用者にとってはステータスモニタになんらかの異常が発生し、エラー終了したと見える可能性がある。また、利用者と同様にステータスモニターの表示を監視するアプリケーションがさらに存在するシステムにおいても、そのアプリケーションは監視していたステータスモニターの表示が突如監視できなくなることになる。
【００１１】
本発明は、上記問題を解決するためになされたものであり、その目的は、何らかのデバイスが新たに接続されたことが検出されるものの、そのデバイスが処理対象か否かが定かでない場合でも、処理対象となるデバイスに対してより確実に状態情報要求指令を送信することができる状態情報取得処理プログラム、状態情報取得装置、および状態情報取得システムを提供することにある。
【課題を解決するための手段】
【００１２】
以下、本発明において採用した特徴的構成について説明する。
本発明の状態情報取得処理プログラムは、情報処理装置と各種デバイスとの接続状態の変化を検知する検知手段、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段、前記検知手段によって前記各種デバイスとの接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段、および前記処理対象デバイスから前記状態情報を取得する状態情報取得手段として、前記情報処理装置に備えられたコンピュータを機能させることを特徴とする。
【００１３】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、検知手段によってデバイスとの接続状態の変化が検知されただけで、デバイスに対して状態情報要求指令が送られてしまうことがなく、通信可否判定手段によって処理対象デバイスと通信可能と判定された場合に、処理対象デバイスに対して状態情報要求指令が送られる。したがって、処理対象デバイスとの通信ができないにもかかわらず、処理対象デバイスに対して状態情報要求指令が送られてしまうことに起因して発生する種々の不具合を、未然に防止することができる。また、処理対象デバイスとの通信ができる場合には、処理対象デバイスに対して状態情報要求指令が送られるので、以後は、処理対象デバイスから適切に状態情報を取得することができるようになる。
【００１４】
また、本発明の状態情報取得処理プログラムにおいて、前記検知手段は、前記各種デバイスとの接続状態の変化通知するための情報を、前記情報処理装置から受信することで、前記各種デバイスとの接続状態の変化を検知するとよい。
【００１５】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、情報処理装置が備える機能を利用して、情報処理装置からの情報により各種デバイスとの接続状態の変化を検知することができる。
【００１６】
また、本発明の状態情報取得処理プログラムは、前記コンピュータを、さらに、前記状態情報取得手段によって前記処理対象デバイスから前記状態情報を取得できたか否かを判定する取得状況判定手段として機能させるように構成されており、前記状態情報要求指令手段は、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、さらに、前記取得状況判定手段によって前記状態情報を取得できなかったと判定されたら、前記処理対象デバイスに対して状態情報要求指令を送る手段とされているとよい。
【００１７】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、状態情報を取得できなかった場合には、処理対象デバイスに対して状態情報要求指令が送られるものの、状態情報を取得できた場合には、処理対象デバイスに対して状態情報要求指令が送られないので、デバイス側が既に状態情報を取得できる状態になっているにもかかわらず、無駄に状態情報要求指令が送られてしまうのを、未然に防止することができる。
【００１８】
また、本発明の状態情報取得処理プログラムは、前記コンピュータを、さらに、前記通信可否判定手段による判定結果に基づいて、前記処理対象デバイスと通信できない旨を示す通信不可情報を利用者に対して通知すべきか否かを判定する通知要否判定手段、および前記通知要否判定手段によって前記通信不可情報を利用者に対して通知すべきと判定された場合に、前記通信不可情報を利用者に対して通知する通信不可情報通知手段として機能させるように構成されているとよい。
【００１９】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、処理対象デバイスと通信できない旨を示す通信不可情報を利用者に対して通知すべきと判定された時点で、通信不可情報が利用者に通知されるので、利用者は、コンピュータが処理対象デバイスと通信できない状態にあることを察知することができ、必要があれば適切な対処を行うことができる。
【００２０】
なお、処理対象デバイスと通信できない旨を示す通信不可情報を利用者に対して通知すべきと判定するための条件については、様々な条件を考え得るが、いくつか例を挙げれば、例えば、本発明の状態情報取得処理プログラムにおいて、前記通知要否判定手段は、前記通信可否判定手段によって前記処理対象デバイスと通信できないと判定された回数があらかじめ定められた規定回数以上となったことを条件の一つとして、当該条件を満足する場合に、前記通信不可情報を利用者に対して通知すべきと判定する手段とされているとよい。
【００２１】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、処理対象デバイスと通信できないと判定された回数が規定回数未満であれば、通信不可情報を利用者に対して通知すべきではないと判定されるので、例えば、何らかの原因で一過性の通信エラーが発生した（例えば、たまたまノイズにより通信障害が発生した等）に過ぎないような場合、次の機会に通信に成功すれば、通信不可情報が利用者に通知されることはないので、通信不可情報が過剰に通知されやすくなってしまうことがなく、利用者にとっては煩わしさが軽減される。
【００２２】
また、本発明の状態情報取得処理プログラムにおいて、前記通知要否判定手段は、１度満足した条件に対しては、一旦条件が解除されるまでは、前記通信不可情報を利用者に対して通知すべきと判定しない手段とされているとよい。
【００２３】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、１度満足した条件に対しては、一旦条件が解除されるまでは、通信不可情報が利用者に通知されなくなるので、既に通信不可情報が通知済みであるにもかかわらず、再び同じ通信不可情報の通知が行われてしまうことがなく、利用者にとっては煩わしさが軽減される。
【００２４】
また、本発明の状態情報取得処理プログラムにおいて、前記コンピュータを、さらに、前記状態情報取得手段が取得した前記状態情報を報知する状態情報報知手段として機能させるように構成してあるとよい。
【００２５】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、利用者は、報知された状態情報に基づいて処理対象デバイスの状態を知ることができ、例えば、何らかの対処が必要な状態になっている場合には、直ちに対処を行うことができる。
【００２６】
また、本発明の状態情報取得処理プログラムにおいて、前記コンピュータを、さらに、前記通信可否判定手段によって前記処理対象デバイスと通信できないと判定された回数があらかじめ定められた規定回数以上となったことを条件の一つとして、当該条件を満足する場合に、前記状態情報取得手段による前記状態情報の取得を停止させる状態情報取得停止手段、および前記状態情報取得停止手段により前記状態情報の取得が停止された後、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記状態情報取得手段による前記状態情報の取得を再開させる状態情報取得再開手段として機能させるように構成してあるとよい。
【００２７】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、処理対象デバイスと通信できなかった回数が規定回数以上となった場合に、状態情報の取得を停止することになるので、処理対象デバイスと通信できないにもかかわらず、いつまでも無駄に通信を試行し続けることがなく、コンピュータにかかる負荷を軽減することができる。また、状態情報の取得が停止された後、接続状態の変化を通知するための情報が受信され、且つ、処理対象デバイスと通信可能と判定された場合に、状態情報の取得が再開されるので、以後は、処理対象デバイスから適切に状態情報を取得することができるようになる。
【００２８】
次に、本発明の状態情報取得装置は、各種デバイスとの接続状態の変化を検知可能な検知手段と、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段と、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段とを備えたことを特徴とする。
【００２９】
このように構成された状態情報取得装置は、既に説明した本発明の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置となる。したがって、この状態情報取得装置でも、処理対象デバイスとの通信ができないにもかかわらず、処理対象デバイスに対して状態情報要求指令が送られてしまうことに起因して発生する種々の不具合を、未然に防止することができる。また、処理対象デバイスとの通信ができる場合には、処理対象デバイスに対して状態情報要求指令が送られるので、以後は、処理対象デバイスから適切に状態情報を取得することができるようになる。
【００３０】
なお、請求項９に記載の状態情報取得装置は、請求項２に記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置であるが、本発明の情報状態取得装置は、さらに、請求項２〜請求項８のいずれかに記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置として構成されていてもよい。
【００３１】
次に、本発明の状態情報取得装置は、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わる処理対象デバイスと、前記処理対処デバイスを接続可能な状態情報取得装置とを備えてなり、前記状態情報取得装置は、各種デバイスとの接続状態の変化を検知可能な検知手段と、前記処理対象デバイスと通信可能か否かを判定する通信可否判定手段と、前記検知手段によって前記接続状態の変化が検知され、且つ、前記通信可否判定手段によって前記処理対象デバイスと通信可能と判定された場合に、前記処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段とを備えることを特徴とする。
【００３２】
このように構成された状態情報取得システムにおいて、状態情報取得装置は、既に説明した本発明の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置であり、この状態情報取得装置と処理対象デバイスとによって、本発明の状態情報取得システムが構成される。
【００３３】
したがって、この状態情報取得システムでも、処理対象デバイスとの通信ができないにもかかわらず、処理対象デバイスに対して状態情報要求指令が送られてしまうことに起因して発生する種々の不具合を、未然に防止することができる。また、処理対象デバイスとの通信ができる場合には、処理対象デバイスに対して状態情報要求指令が送られるので、以後は、処理対象デバイスから適切に状態情報を取得することができるようになる。
【００３４】
なお、請求項１０に記載の状態情報取得システムにおいて、状態情報取得装置は、請求項２に記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置であるが、本発明の状態情報取得システムにおいて、情報状態取得装置は、さらに、請求項２〜請求項８のいずれかに記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置として構成されていてもよい。
【００３５】
さらに、本発明の状態情報取得処理プログラム、状態情報取得装置、および状態情報取得システムは、それぞれ次のような特徴的構成を備えた発明として把握することもできる。
【００３６】
すなわち、本発明の状態情報取得処理プログラムは、情報処理装置と各種デバイスとの接続状態の変化を検知する検知手段、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段、前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段、および前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合に、前記処理対象デバイスに対して前記状態情報要求指令を送る状態情報要求指令手段として、前記情報処理装置に備えられたコンピュータを機能させることを特徴とする。
【００３７】
このように構成された状態情報取得処理プログラムにより、コンピュータを上記各手段として機能させれば、各種デバイスとの接続状態の変化が検知された場合にも状態情報を報知するので、状態情報の報知を停止してしまうものとは異なり、デバイスの接続状態の変化に起因して利用者に「状態情報取得処理プログラムに基づく処理を行っているプロセス（例えば、ステータスモニター）」の異常と誤解させてしまうようなことや、「状態情報取得処理プログラムに基づく処理を行っているプロセス」を監視しているアプリケーションに対して、突如監視対象がなくなるといった事態を防ぐことができる。
【００３８】
また、本発明の状態情報取得装置は、各種デバイスとの接続状態の変化を検知する検知手段と、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わるデバイスを処理対象デバイスとして、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段と、前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段と、前記検知手段によって前記各種デバイスとの接続状態の変化が検知された場合に、前記処理対象デバイスに対して前記状態情報要求指令を送る状態情報要求指令手段とを備えたことを特徴とする。
【００３９】
このように構成された状態情報取得装置は、請求項１１に記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置となる。したがって、この状態情報取得装置でも、状態情報の報知を停止してしまうものとは異なり、デバイスの接続状態の変化に起因して利用者に状態情報取得装置の異常と誤解させてしまうようなことや、状態情報取得装置による処理を監視しているアプリケーションに対して、突如監視対象がなくなるといった事態を防ぐことができる。
【００４０】
また、本発明の状態情報取得システムは、電源投入後に状態情報要求指令を受けるとデバイスの状態を示す状態情報を提供可能な状態に切り替わる処理対象デバイスと、前記処理対処デバイスを接続可能な状態情報取得装置とを備えてなり、前記状態情報取得装置は、各種デバイスとの接続状態の変化を検知する検知手段と、前記状態情報取得手段が取得した前記状態情報を報知する手段であり、前記検知手段によって各種デバイスとの接続状態の変化が検知された場合にも前記状態情報を報知する状態情報報知手段と、前記検知手段によって各種デバイスとの接続状態の変化が検知された場合に、前記状態情報報知手段が前記状態情報を報知している処理対象デバイスに対して状態情報要求指令を送る状態情報要求指令手段と、前記処理対象デバイスから前記状態情報を取得する状態情報取得手段とを備えることを特徴とする。
【００４１】
このように構成された状態情報取得システムにおいて、状態情報取得装置は、請求項１１に記載の状態情報取得処理プログラムによってコンピュータ上で機能する各手段と同等な手段を備える装置であり、この状態情報取得装置と処理対象デバイスとによって、請求項１１に記載の状態情報取得システムが構成される。
【００４２】
したがって、この状態情報取得システムでも、状態情報取得装置が状態情報の報知を停止してしまうシステムとは異なり、デバイスの接続状態の変化に起因して利用者に状態情報取得装置の異常と誤解させてしまうようなことや、状態情報取得装置による処理を監視しているアプリケーションに対して、突如監視対象がなくなるといった事態を防ぐことができる。
【発明を実施するための最良の形態】
【００４３】
次に、本発明の実施形態について一例を挙げて説明する。
［システム全体の構成］
図１は、パーソナルコンピュータ１（以下、ＰＣ１という）とプリンタ２とを備えてなるシステム全体の構成を示した概略構成図である。
【００４４】
ＰＣ１は、図１に示すように、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスク装置１４（以下、ＨＤＤ１４という）、操作部１５、表示部１６、およびＵＳＢインターフェース１７（以下、ＵＳＢ  Ｉ／Ｆ１７という）などを備えている。
【００４５】
ＣＰＵ１１は、ＲＯＭ１２やＲＡＭ１３に記憶されたプログラムに従って、ＰＣ１各部に対する制御および各種演算を実行する装置である。
ＲＯＭ１２は、ＰＣ１の電源スイッチを切っても記憶内容を保持可能な記憶装置で、ＢＩＯＳ（Basic Input Output System）や通常であれば更新されない読み出し用のデータ等を記憶している。
【００４６】
ＲＡＭ１３は、ＣＰＵ１１から直接アクセスされるメインメモリ等として利用される記憶装置で、このＲＡＭ１３には、ＯＳ（Operating System）や各種アプリケーションなどのソフトウェアがＨＤＤ１４から読み込まれるようになっている。
【００４７】
ＨＤＤ１４は、ＯＳ、各種アプリケーションプログラム、および各種データファイルを保存しておくための装置である。
操作部１５は、利用者からの各種指示を入力するための入力装置であり、例えば、キーボードや各種ポインティングデバイス（例えば、マウス）等によって構成される。
【００４８】
表示部１６は、各種情報を利用者に提示するための出力装置であり、例えば、カラー画像を表示可能な液晶ディスプレイ等によって構成される。
ＵＳＢ  Ｉ／Ｆ１７は、ＵＳＢ規格準拠のシリアルインターフェースで、このＵＳＢ  Ｉ／Ｆ１７には、様々なデバイス（例えば、プリンタ、キーボード、マウス、スキャナ、スピーカー、各種ストレージデバイスなど）を接続することができるが、本実施形態において、ＵＳＢ  Ｉ／Ｆ１７にはプリンタ２が接続されている。
【００４９】
プリンタ２は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、操作キー２５、表示パネル２６、ＵＳＢ  Ｉ／Ｆ２７、印字部２９などを備えている。
ＣＰＵ２１は、ＲＯＭ２２に記憶されている制御プログラムに従ってプリンタ２各部の制御および各種演算を実行する装置である。
【００５０】
ＲＯＭ２２は、プリンタ２の電源スイッチを切っても記憶内容を保持可能な記憶装置で、上記制御プログラムの他、通常であれば更新されない読み出し用の各種データを記憶している。
【００５１】
ＲＡＭ２３は、ＣＰＵ２１から直接アクセスされるメインメモリ等として利用される記憶装置で、ＣＰＵ２１が処理中に算出する各種データなどが一時的にＲＡＭ２３に記憶されるようになっている。
【００５２】
操作キー２５は、利用者がマニュアル操作でプリンタ２に対して指令を与える場合に操作する入力装置である。
表示パネル２６は、小型液晶ディスプレイによって構成された装置で、プリンタ２の設定や状態などの情報を表示できるようになっている。
【００５３】
ＵＳＢ  Ｉ／Ｆ２７は、ＵＳＢ規格準拠のシリアルインターフェースで、このＵＳＢ  Ｉ／Ｆ２７を利用することにより、ＰＣ１との間でデータ通信を実行できるようになっている。
【００５４】
印字部２９は、シート状の媒体（例えば記録用紙）に対する印刷を実行する部分である。
図２は、ＰＣ１が備えるソフトウェアおよびハードウェアの内、プリンタ２から状態情報を取得する処理に関連するものだけを抜粋して示したブロック図である。
【００５５】
ＰＣ１には、マルチタスク機能を備えたＯＳが搭載され、複数のプロセスが並列に機能するとともに、それら複数のプロセスが連携して各種処理を実行するようになっている。このようなマルチタスク機能を有するＯＳの具体例としては、例えば、Ｗｉｎｄｏｗｓ（登録商標）を挙げることができる。なお、ＯＳによって提供される各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＰＣ１が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。
【００５６】
ＰＣ１において、プリンタ２からの状態情報取得処理を実行する処理系は、図２に示すように、ＵＩ（入力／表示）の層、構文解析層、ポートアクセスの層、クラスドライバー、および物理層からなる階層構造になっている。
【００５７】
より具体的には、ＰＣ１において、プリンタ２に対する印刷出力が行われる際には、プリンタドライバーＵＩ３１が印刷関連の処理を実行し、その処理の中で、ステータスモニターＵＩ３２がプリンタドライバーＵＩ３１とは別のプロセスとして起動される。ただし、ステータスモニターＵＩ３２を起動する契機は任意であり、例えば、ポートモニターがステータスモニターＵＩ３２を起動するように構成されていてもよいし、ＰＣ１の起動時にステータスモニターＵＩ３２が起動されてもよいし、利用者がマニュアル操作でステータスモニターＵＩ３２を起動できるように構成されていてもよい。
【００５８】
ステータスモニターＵＩ３２は、利用者から情報の入力を受け付ける処理や、状態情報を表示する処理を実行するプロセスで、その処理の中で、ステータスモニターＰＪＬパーサー３３（以下、単にパーサー３３とも称する。）が、ステータスモニターＵＩ３２とは別のプロセスとして起動される。
【００５９】
ステータスモニターＰＪＬパーサー３３は、プリンタ２に対して、プリンタジョブ言語（ＰＪＬ；Printer Job Language）に準拠した形式で記述されたコマンド（以下、ＰＪＬコマンドともいう）を出力し、そのＰＪＬコマンドを受け取ったプリンタ２から出力される状態情報を取得する。また、取得した状態情報の構文解析を行って、その状態情報をステータスモニターＵＩ３２が参照可能なデータ形式に変換し、ステータスモニターＵＩ３２へと出力する。なお、ＰＪＬは、プリンタが備える各種機能の制御を可能とするコマンド言語で、Hewlett-Packard社において開発され、その後他社でも採用された周知のものである。
【００６０】
また、ステータスモニターＰＪＬパーサー３３は、その処理の中で、ＵＳＢ／ＬＰＴローカルポートアービトレイター３４を動的にリンクし、これにより、ＵＳＢ／ＬＰＴローカルポートアービトレイター３４が機能する状態になる。ＵＳＢ／ＬＰＴローカルポートアービトレイター３４は、同一ポートを利用する他のプロセスとの間で調停を行って、あるプロセスに渡るべきデータが他のプロセスに渡らないように制御する。
【００６１】
ＵＳＢプリンタクラスドライバー３５は、ＯＳが備える機能の一部であり、ＰＣ１の起動時または各クラスドライバーに対応するデバイスの起動時に起動される。また、ＵＳＢ物理層３６は、各プリンタポートを構成するハードウェアである。
【００６２】
さらに、ＰＣ１に搭載されたＯＳは、スプーラシステム４１、ＰｎＰマネージャ４３、Ｉ／Ｏマネージャ４５などを備えている。
スプーラシステム４１は、複数のプロセス（例えばアプリケーション）から出力される印刷データを印刷ジョブとして一元管理し、ＦＩＦＯもしくは利用者が指定した優先度等に従って、順次プリンタ２側へ送出する処理を実行するシステムである。ステータスモニターＰＪＬパーサー３３がＰＪＬコマンドを出力した場合、そのＰＪＬコマンドも、他の印刷データ同様に、一つの印刷ジョブとしてスプーラシステム４１により管理され、スプーラシステム４１による制御の下、ＵＳＢプリンタクラスドライバー３５およびＵＳＢ物理層３６経由で、プリンタ２側へ送出されることになる。本実施形態においては、後述する処理の中で、状態情報要求指令として“ＵＳＴＡＴＵＳ  ＤＥＶＩＣＥ  ＯＮ”および“ＩＮＦＯ  ＤＥＶＩＣＥ”というＰＪＬコマンドが、スプーラシステム４１経由でプリンタ２へと伝送され、その結果、プリンタ２がプリンタ２の状態を示す状態情報を提供する状態となり、以後、ステータスモニターＰＪＬパーサー３３は、プリンタ２から状態情報を取得可能となる。
【００６３】
このＰＪＬコマンド“ＵＳＴＡＴＵＳ  ＤＥＶＩＣＥ  ＯＮ”は、プリンタの状態が変化したときに、その情報を返すようにプリンタに命令するコマンドである。また、ＰＪＬコマンド“ＩＮＦＯ  ＤＥＶＩＣＥ”は、その時点でのステータスを返すようプリンタに命令するコマンドである。
【００６４】
一例を挙げれば、プリンタ２は、例えば、図３中の“ＰＪＬ”の欄に示したような状態情報を提供可能な状態になるので、ステータスモニターＰＪＬパーサー３３は、所望のタイミングでプリンタ２から状態情報を読み取る（リードバックする）ことができる。そして、ステータスモニターＰＪＬパーサー３３は、プリンタ２から読み取った状態情報を、図３中の“パーサー出力”の欄に示したような、最大７２バイトのバイナリデータに変換して、変換後の状態情報をプロセス間通信により上位のステータスモニターＵＩ３２へと出力する。
【００６５】
また、ＰｎＰマネージャ４３およびＩ／Ｏマネージャ４５は、プリンタ２の接続および切断に関する状態変化があった場合に、その旨を各プロセスに通知する機能を備えている。より詳しくは、プリンタ２を含む各種デバイスの接続および切断に関する状態変化があった場合、その状態変化がＩ／Ｏマネージャ４５によって検出され、Ｉ／Ｏマネージャ４５と連携して機能するＰｎＰマネージャ４３は、各プロセスにメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”を通知する。したがって、ＰＣ１上で機能する各プロセスは、ＰｎＰマネージャ４３からの通知（＝メッセージ）に基づいて、プリンタ２の接続および切断に関する状態変化があったことを認識することができる。本実施形態の場合は、ステータスモニターＰＪＬパーサー３３が、プリンタ２の接続および切断に関する状態変化があったことを認識した場合に、それに応じた処理を実行することになるが、その処理の詳細については後述する。
【００６６】
［状態情報取得処理の詳細］
次に、ＰＣ１において実行される状態情報取得処理の詳細について説明する。この状態情報取得処理は、ステータスモニターＵＩ３２とステータスモニターＰＪＬパーサー３３が協働して実行する処理となる。
【００６７】
まず、ステータスモニターＵＩ３２が実行する処理について、図４および図５のフローチャートに基づいて説明する。
この処理を開始すると、ステータスモニターＵＩ３２は、まず、パーサー名の読み込みを行う（Ｓ１１０）。この処理で読み込まれるパーサー名は、ステータスモニターＵＩ３２が対象としているプリンタ（本実施形態の場合、プリンタ２）に対応するパーサー名が、あらかじめ設定ファイル等に登録されているので、その登録されたパーサー名が読み込まれる。
【００６８】
そして、Ｓ１１０の処理で読み込んだパーサー名を使用して、パーサー３３を別のプロセスとして起動する（Ｓ１２０）。このとき、パーサー３３には、プリンタ名をコマンドラインで渡す。
【００６９】
そして、別プロセスでステータスモニターＵＩ３２を既に起動済みかどうかを判断し（Ｓ１３０）、起動済みでなければ（Ｓ１３０：ＮＯ）、メッセージループ処理に移行する（Ｓ１４０）。また、起動済みである場合（Ｓ１３０：ＹＥＳ）、もしくはＳ１４０の処理を終えた場合は、本処理を終了する。
【００７０】
Ｓ１４０のメッセージループ処理は、詳しくは図５のフローチャートに示すような処理となる。このメッセージループ処理では、メッセージとして到来する指示の内容を判断して、その指示（メッセージ）に対応する処理を実行することが繰り返される。
【００７１】
具体的には、まず、メッセージによる指示が“終了”かどうかを判断し（Ｓ２１０）、“終了”であれば（Ｓ２１０：ＹＥＳ）、他プロセスとの間の全通信を閉じて（Ｓ２２０）、このメッセージループ処理を終える。
【００７２】
また、メッセージによる指示が“終了”でない場合（Ｓ２１０：ＮＯ）、パーサー３３からのメッセージかどうかを判断する（Ｓ２３０）。パーサー３３からのメッセージとは、上述したＳ１２０の処理で起動したパーサー３３のプロセスから到来するメッセージである。パーサー３３が実行する処理の具体的な内容については、後から詳述するが、このメッセージループ処理では、パーサー３３との間でプロセス間通信を行いながら、各種処理を実行することになる。
【００７３】
Ｓ２３０の処理において、パーサー３３からのメッセージでない場合は（Ｓ２３０：ＮＯ）、その他のメッセージに対する処理を実行した上で（Ｓ２４０）、Ｓ２１０の処理へと戻る。
【００７４】
一方、Ｓ２３０の処理において、パーサー３３からのメッセージであった場合は（Ｓ２３０：ＹＥＳ）、そのメッセージによる指示が“インストール”かどうかを判断し（Ｓ２５０）、“インストール”であれば（Ｓ２５０：ＹＥＳ）、パーサー３３との通信を確立する（Ｓ２６０）。パーサー３３との具体的な通信手順や通信方法については、プロセス間で相互にデータを送受信できるような仕組みになっていれば、特に限定されないが、本実施形態では、後述するパーサー３３処理において確保される共有メモリにアタッチして、共有メモリを介してプロセス間でデータのやり取りを行う方法を採用している。そして、表示バッファを確保して（Ｓ２７０）、Ｓ２１０の処理へと戻る。表示バッファは、ＰＣ１が備える表示部１６に状態情報を表示出力するためのバッファである。
【００７５】
また、メッセージによる指示が“インストール”でない場合（Ｓ２５０：ＮＯ）、メッセージによる指示が“ステータスアップデート”かどうかを判断し（Ｓ２８０）、“ステータスアップデート”であれば（Ｓ２８０：ＹＥＳ）、アタッチしている共有メモリから状態情報を読み出し、その状態情報を表示バッファに書き込むことにより更新する（Ｓ２９０）。表示バッファは、上記Ｓ２７０の処理によって確保されたメモリである。そして、表示バッファを更新したら、更新した状態情報をＰＣ１が備える表示部１６に実際に表示出力するため、表示部１６の表示を更新するための制御を実行して（Ｓ３００）、Ｓ２１０の処理へと戻る。
【００７６】
また、メッセージによる指示が“ステータスアップデート”でない場合（Ｓ２８０：ＮＯ）、メッセージによる指示が“アンインストール”かどうかを判断し（Ｓ３１０）、“アンインストール”であれば（Ｓ３１０：ＹＥＳ）、パーサー３３との通信を閉じる（Ｓ３２０）。具体的には、本実施形態では、上記Ｓ２６０の処理でアタッチした共有メモリをデタッチするが、上記Ｓ２６０の処理において共有メモリ以外の手段でプロセス間通信を実現した場合は、そのプロセス間通信のために確保したリソースを解放する処理等を行うことになる。そして、Ｓ２７０の処理で確保した表示バッファを消去して（Ｓ３３０）、メッセージループ処理を終える。
【００７７】
また、上記Ｓ３１０の処理において、“アンインストール”でなければ（Ｓ３１０：ＮＯ）、その他の処理を実行して（Ｓ３５０）、Ｓ２１０の処理へと戻る。なお、その他の処理は、本発明の要部には関連しない処理なので詳細な説明を省略する。
【００７８】
さて、ステータスモニターＵＩ３２が、以上説明したようなメッセージループ処理を実行するのと並行して、上記Ｓ１２０の処理によって起動されたパーサー３３（ステータスモニターＰＪＬパーサー３３）は、図６〜図１０のフローチャートに示す処理を実行する。
【００７９】
具体的には、パーサー３３は、まず、図６に示す処理を実行し、この処理の中でメッセージ配信処理を実行する（Ｓ４１０）。このＳ４１０の処理は、所定の条件が成立すると、図７〜図１０に示した各処理を含む複数の処理の内、成立した条件に応じた処理を実行するものである。また、このＳ４１０の処理において、成立した条件が終了条件であった場合、Ｓ４１０の処理を終了することになり、その場合は、図６に示した処理全体を終了することになるが、成立した条件が終了条件以外の条件であった場合は、Ｓ４１０の処理は終了せず、再び新たに所定の条件が成立するまで待機し、所定の条件が成立すれば、成立した条件に応じた処理を実行する。つまり、Ｓ４１０の処理は、終了条件が成立するまでは、終了条件以外の条件が成立する毎に、成立した条件に応じた処理の実行を繰り返すことになる。
【００８０】
以下、Ｓ４１０の処理において、各種条件が成立した場合に実行される処理について説明する。
まず、図７に示す初期化メッセージ処理について説明する。この初期化メッセージ処理は、パーサー３３の起動直後であるとの条件が成立した場合に実行される処理となる。
【００８１】
初期化メッセージ処理を開始すると、パーサー３３は、まず、各種フラグの初期化を行う（Ｓ５１０）。このＳ５１０の処理において、デバイス着脱フラグ、状態情報要求指令送信済みフラグ、および通信不可表示フラグには初期値としてＯＦＦが設定され、通信失敗回数カウンタはゼロクリアされる。
【００８２】
続いて、パーサー３３は、ステータスモニターＵＩ３２との通信確立を行うための準備を行う（Ｓ５２０）。具体的には、共有メモリとなるメモリ領域を確保する処理などが行われる。そして、パーサー３３起動時に引数として渡されたプリンタ名に基づいて、そのプリンタが使用するポート名を調査し（Ｓ５３０）、そのポート名に応じた下位層のロードを行う（Ｓ５４０）。Ｓ５４０の処理においてロードされるプログラムは、ダイナミック・リンク・ライブラリ（以下、ＤＬＬともいう）として提供され、パーサー３３としての処理を実行するプロセスが、ポート名に応じたアービトレイターをメモリにロードし、以降、パーサー３３は、処理対象としているプリンタが利用するポートに対応したアービトレイターを利用して、状態情報を取得することができるようになる。
【００８３】
以上の処理を終えたら、パーサー３３は、ステータスモニターＵＩ３２のプロセスに対して、インストールメッセージを送信する（Ｓ５５０）。このメッセージは、先に説明したステータスモニターＵＩ３２のメッセージループ処理において、Ｓ２５０〜Ｓ２７０の処理を実行する契機となるメッセージで、ステータスモニターＵＩ３２側の処理が完了した時点で、ステータスモニターＵＩ３２とパーサー３３との通信が確立することになる。
【００８４】
なお、Ｓ５５０の処理を終えたら、図７に示した初期化メッセージ処理を終えることになり、以降、パーサー３３は、上記Ｓ４１０の処理において、再び所定の条件が成立するまで待機することになる。
【００８５】
次に、図８に示す終了メッセージ処理について説明する。この終了メッセージ処理は、終了条件が成立した場合に実行される処理であり、例えば、利用者が操作部１５を操作して所定の終了指示を入力した場合に終了条件が成立し、終了メッセージ処理が実行されることになる。また、エラーその他の事情により、終了条件が成立することもある。
【００８６】
終了メッセージ処理を開始すると、パーサー３３は、アンインストールメッセージを送信する（Ｓ６１０）。このメッセージは、先に説明したステータスモニターＵＩ３２のメッセージループ処理において、Ｓ３１０〜Ｓ３３０の処理を実行する契機となるメッセージである。そして、Ｓ６１０の処理を終えたら、Ｓ５２０の処理で準備された共有メモリを解放する処理などを行った上で、図８に示した終了メッセージ処理を終えることになる。終了メッセージ処理を終えた場合、パーサー３３は、上記Ｓ４１０の処理を終えることになる。
【００８７】
次に、図９に示すデバイス構成変更メッセージ処理について説明する。本実施形態において、ＰＣ１にはＯＳとしてＷｉｎｄｏｗｓ（登録商標）が搭載されており、プリンタ２の電源スイッチがＯＮ／ＯＦＦいずれか一方から他方に切り替えられた場合、あるいは、ＰＣ１とプリンタ２とを接続するための通信ケーブルが抜き挿しされた場合等、ＰＣ１に接続されているデバイスの構成に変更があった場合には、ＰｎＰマネージャ４３からパーサー３３にメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”が通知される。以下に説明するデバイス構成変更メッセージ処理は、上記メッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”がＰｎＰマネージャ４３から通知されたとの条件が成立した場合に実行される処理となる。
【００８８】
デバイス構成変更メッセージ処理を開始すると、パーサー３３は、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）か否かを判断する（Ｓ６６０）。より詳しくは、パーサー３３にメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”が通知された場合、メッセージにはいくつかのパラメータが付属しているので、Ｓ６６０の処理では、メッセージに付属するパラメータが“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”であるか否かを判断する。
【００８９】
Ｓ６６０の処理において、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）であった場合（Ｓ６６０：ＹＥＳ）、パーサー３３は、デバイス着脱フラグをＯＮにして（Ｓ６７０）、デバイス構成変更メッセージ処理を終了する。一方、Ｓ６６０の処理において、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）ではなかった場合（Ｓ６６０：ＮＯ）、パーサー３３は、Ｓ６７０の処理をスキップして、デバイス構成変更メッセージ処理を終了する。なお、Ｓ６７０の処理においてＯＮがセットされたデバイス着脱フラグは、後述するタイマーメッセージ処理の中で参照されることになる。
【００９０】
次に、図１０に示すタイマーメッセージ処理について説明する。このタイマーメッセージ処理は、一定時間が経過したとの条件が成立した場合に実行される処理、すなわち、一定時間が経過するたびに繰り返し実行される処理となる。ただし、その繰り返し処理の中で各種フラグの値その他が変化するため、タイマーメッセージ処理内における処理の流れは随時変化する。
【００９１】
そこで、以下の説明においては、タイマーメッセージ処理が実行される際の様々な状況を想定しながら、想定した状況に応じたタイマーメッセージ処理の流れについて説明することにする。
【００９２】
まず、初期段階として、プリンタ２との通信を正常に実行できる状況下で、タイマーメッセージ処理が初めて実行された場合を想定して説明を続ける。
タイマーメッセージ処理を開始すると、パーサー３３は、まず、デバイス着脱フラグがＯＮであるか否かを判断する（Ｓ７１０）。このデバイス着脱フラグには、上記デバイス構成変更メッセージ処理（図９参照）が実行されると、その処理の中でＯＮがセットされることがあるが、初期段階においては、多くの場合、上記初期化メッセージ処理（図７参照）の中で初期値：ＯＦＦがセットされたままになっている。そこで、ここでは、デバイス着脱フラグにＯＦＦがセットされていることを想定して以下の説明を続けることにし、デバイス着脱フラグにＯＮがセットされている場合については、後から別途説明する。
【００９３】
デバイス着脱フラグはＯＦＦとなっている場合（Ｓ７１０：ＮＯ）、パーサー３３は、通信失敗回数カウンタが規定回数（例えば５回）未満か否かを判断する（Ｓ７２０）。通信失敗回数カウンタは、後述する処理の中でプリンタ２との通信に失敗するとカウントアップされる場合があるが、初期段階では、上記初期化メッセージ処理（図７参照）の中でゼロクリアされている。
【００９４】
Ｓ７２０の処理で、通信失敗回数カウンタの値は規定回数未満であると判断された場合（Ｓ７２０：ＹＥＳ）、パーサー３３は、下位（＝アービトレイター３４）よりデータ（＝状態情報）を受信し（Ｓ７３０）、その通信に失敗したか否かを判断する（Ｓ７４０）。より詳しくは、Ｓ７３０の処理では、まずプリンタ２との間でネゴシエーションを行って通信を確立し、通信を確立した後に状態情報の受信を行う。そして、Ｓ７４０の処理では、通信確立に成功し、且つ、状態情報の受信が正常終了すれば、通信成功と判断し、通信確立に失敗するか、あるいは、状態情報の受信が異常終了したら、通信失敗と判断する。
【００９５】
Ｓ７４０の処理において、プリンタ２の電源がＯＮになっていて、プリンタ２との間で正常な通信ができる場合は、通信成功と判断されるので（Ｓ７４０：ＮＯ）、その場合は、通信失敗回数カウンタをゼロクリアし（Ｓ７５０）、Ｓ７３０の処理で取得したデータ（＝状態情報）がないかどうかを判断する（Ｓ７６０）。すなわち、Ｓ７６０の処理が実行されるのはＳ７４０の処理で通信成功と判断された場合であるが、通信に成功した結果として、取得したデータがない場合があり、そのような場合には、Ｓ７６０の処理で肯定判断がなされることになる。
【００９６】
ここで、Ｓ７３０の処理でデータ（＝状態情報）を受信するためには、事前にプリンタ２に対して状態情報要求指令（＝ＰＪＬコマンド）を送信することにより、プリンタ２が状態情報を提供できる状態にしておく必要がある。
【００９７】
しかし、初期段階では、状態情報要求指令（＝ＰＪＬコマンド）の送信が行われないままＳ７３０の処理が実行されることになるので、プリンタ２からデータ（＝状態情報）が提供されることはなく、Ｓ７６０の処理では、必ず取得データなしとの判断がなされることになる（Ｓ７６０：ＹＥＳ）。
【００９８】
そこで、パーサー３３は、引き続いて、デバイス着脱フラグはＯＮであるか否かを判断することになるが（Ｓ７７０）、初期段階では、上述の想定通り、デバイス着脱フラグがＯＦＦとなっているので（Ｓ７７０：ＮＯ）、パーサー３３は、状態情報要求指令送信済みフラグはＯＦＦであるか否かを判断する（Ｓ７８０）。初期段階において、状態情報要求指令送信済みフラグには、上記初期化メッセージ処理（図７参照）の中で初期値：ＯＦＦがセットされているので、Ｓ７８０の処理では肯定判断がなされ（Ｓ７８０：ＹＥＳ）、その場合、パーサー３３は、状態情報要求指令をプリンタ２へ送信する（Ｓ７９０）。
【００９９】
具体的な状態情報要求指令の送信方法は、送信対象となるプリンタの仕様やそのプリンタが使用するプリンタポートの仕様などを考慮して、問題なくプリンタへ状態情報要求指令を送信できる方法であれば任意であるが、本実施形態においては、状態情報要求指令としてＰＪＬコマンドを送信するので、ＰＣ１が備えるスプーラシステム４１を利用してＰＪＬコマンドを一つの印刷ジョブとして処理し、これにより、状態情報要求指令（ＰＪＬコマンド）をプリンタ２へと送信する。このようにスプーラシステム４１を利用して状態情報要求指令を送信すれば、他の印刷ジョブと状態情報要求指令（ＰＪＬコマンド）が混在するかたちで同時にプリンタ２に送信されてしまうのを防止することができる。
【０１００】
こうして状態情報要求指令をプリンタ２へ送信したら、パーサー３３は、状態情報要求指令送信済みフラグをＯＮにし（Ｓ８００）、デバイス着脱フラグをＯＦＦにして（Ｓ８１０）、図１０に示すタイマーメッセージ処理を終了する。
【０１０１】
さて次に、上記初期段階とは異なる様々な状況を想定しつつ、再び実行されるタイマーメッセージ処理の流れについて説明する。
再びタイマーメッセージ処理を実行した場合、パーサー３３は、既に上記Ｓ７９０の処理によって状態情報要求指令をプリンタ２に対して送信しているので、上記Ｓ７３０の処理においては、下位よりデータ（＝状態情報）を受信することができる。
【０１０２】
本実施形態において、Ｓ７３０の処理で受信するデータは、パーサー３３が受信バッファとなるメモリを確保し、その受信バッファのアドレスを引数としてアービトレイター３４（ＵＳＢ／ＬＰＴローカルポートアービトレイター３４）側に渡し、パーサー３３によって指定されたアドレスにアービトレイター３４がデータを格納することにより、そのデータをパーサー３３側で受信する。その際、アービトレイター３４は、ＵＳＢプリンタクラスドライバー３５の仕様に応じた方式で、ＵＳＢ接続されたプリンタ２からの状態情報を入力し、その状態情報を受信バッファに格納する。このようにアービトレイター３４は、クラスドライバー３５の仕様に応じた方式で状態情報を入力するものの、入力した状態情報は、クラスドライバー３５の仕様に依存しない形式で受信バッファに格納されるので、パーサー３３は、プリンタポートの仕様を全く意識することなく、受信バッファに格納された状態情報を参照することができる。
【０１０３】
実際にパーサー３３が下位からデータを取得するか否かは、プリンタ２の状態に何らかの変化があったか否かによっても変わるが、Ｓ７３０の処理において、パーサー３３が下位からデータを取得していた場合、Ｓ７６０の処理では、取得したデータ（＝状態情報）があると判断されることになり（Ｓ７６０：ＮＯ）、その場合、パーサー３３は、ステータスモニターＵＩ３２との通知バッファに状態情報を書き込む（Ｓ８２０）。Ｓ８２０の処理で状態情報を書き込む通知バッファは、上記Ｓ５２０の処理で確保した共有メモリであり、この共有メモリに状態情報を書き込むことにより、ステータスモニターＵＩ３２側で最新の状態情報を参照できるようになる。
【０１０４】
なお、Ｓ７３０の処理で、受信バッファに格納された状態情報は、図３に示したＰＪＬに対応したプリンタ２の仕様に依存したデータ形式になっているが、Ｓ８２０の処理では、受信バッファに格納された状態情報の字句・構文の解析を行い、図３に示したパーサー出力の欄に示したようなデータ形式に変換した上で、変換後の状態情報を共有メモリに書き込む。これにより、ステータスモニターＵＩ３２側では、ＰＪＬの仕様を全く意識することなく、共有メモリに格納された状態情報を参照することができる。
【０１０５】
以上のようなＳ８２０の処理を終えたら、パーサー３３は、通信不可表示フラグをＯＦＦにして（Ｓ８３０）、ステータスモニターＵＩ３２のプロセスに対して、ステータスアップデートメッセージを送信する（Ｓ８４０）。このメッセージは、先に説明したステータスモニターＵＩ３２のメッセージループ処理において、Ｓ２８０〜Ｓ３００の処理を実行する契機となるメッセージである。
【０１０６】
そして、Ｓ８４０の処理を終えたら、既に説明したＳ８１０の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
一方、Ｓ７３０の処理において、パーサー３３が下位からデータを取得していなかった場合、Ｓ７６０の処理では、取得したデータ（＝状態情報）がないと判断されることになり（Ｓ７６０：ＹＥＳ）、その場合は、上述したＳ７７０、Ｓ７８０の処理へと移行するが、既にＳ８００の処理を実行していれば、状態情報要求指令送信済みフラグにはＯＮがセットされているので、Ｓ７８０の処理では否定判断がなされることになり（Ｓ７８０：ＮＯ）、以降は、既に説明したＳ８１０の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
【０１０７】
さて、以上がプリンタ２との通信が正常に実施できる場合の処理の流れであるが、プリンタ２の電源スイッチがＯＦＦにされた場合や、プリンタ２との間の通信ケーブルがコネクタから抜かれた場合等、プリンタ２との通信が正常に実施できなくなることがある。そのような場合、タイマーメッセージ処理は、以下のような流れで処理を実行することになる。
【０１０８】
すなわち、タイマーメッセージ処理を実行した際に、通信失敗回数カウンタの値がまだ規定回数（例えば５回）未満であれば、Ｓ７２０の処理では肯定判断がなされ（Ｓ７２０：ＹＥＳ）、その場合、パーサー３３は、上記Ｓ７３０の処理を実行することになる。しかし、プリンタ２との通信が正常に実施できないため、上記Ｓ７４０の処理では、通信失敗との判断がなされることになり（Ｓ７４０：ＹＥＳ）、その場合は、通信失敗回数カウンタをカウントアップして（Ｓ８５０）、既に説明したＳ８１０の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
【０１０９】
ここで、タイマーメッセージ処理は、既に述べた通り、一定時間が経過するたびに実行されるので、上記のような流れとなる処理が何回か繰り返されて、そのたびに上記Ｓ８５０の処理が実行されると、通信失敗回数カウンタの値は規定回数（例えば５回）を超えることになる。
【０１１０】
そして、タイマーメッセージ処理を実行した際に、通信失敗回数カウンタの値が規定回数（例えば５回）以上になっていたら、Ｓ７２０の処理では否定判断がなされ（Ｓ７２０：ＮＯ）、その場合、パーサー３３は、通信不可表示フラグはＯＦＦであるか否かを判断する（Ｓ８６０）。
【０１１１】
Ｓ８６０の処理において、通信不可表示フラグがＯＦＦであった場合は（Ｓ８６０：ＹＥＳ）、プリンタ２との通信ができない旨の情報（＝通信不可情報）をステータスモニターＵＩ３２にまだ通知していないことを意味するので、この場合、パーサー３３は、通信不可情報を通知バッファに書き込み（Ｓ８７０）、通信不可表示フラグをＯＮにして（Ｓ８８０）、上記Ｓ８４０の処理へと移行する。これにより、パーサー３３からステータスモニターＵＩ３２のプロセスに対してステータスアップデートメッセージが送信されることになる。そして、以降は、既に説明したＳ８１０の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
【０１１２】
また、Ｓ８６０の処理において、通信不可表示フラグがＯＦＦでなかった場合は（Ｓ８６０：ＮＯ）、プリンタ２との通信ができない旨の情報（＝通信不可情報）をステータスモニターＵＩ３２に既に通知していることを意味するので、この場合は、あらためて通信不可情報をステータスモニターＵＩ３２に通知するようなことはしないまま、既に説明したＳ８１０の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
【０１１３】
なお、プリンタ２との通信できなくなった場合でも、デバイス構成変更メッセージが生じることも考えられ、このメッセージにより、一旦デバイス着脱フラグはＯＮとなり、この場合、通信失敗回数カウンタが規定回数以上であっても、Ｓ７３０の処理によりデータ受信処理を実施することになるが、Ｓ８１０の処理によりデバイス着脱フラグはＯＦＦされるので、一度のみデータ受信処理がなされるだけで済むので、影響はないに等しい。
【０１１４】
さて、以上がプリンタ２との通信が正常に実施できない場合の処理となるが、その後、プリンタ２の電源スイッチが再びＯＮにされた場合や、プリンタ２との間の通信ケーブルが再びコネクタに挿し込まれた場合等、プリンタ２との通信が再び正常に実施できることもある。そのような場合、上述したデバイス構成変更メッセージ処理（図９参照）が実行され、デバイス着脱フラグがＯＮとなるので、それに伴って、タイマーメッセージ処理は、以下のような流れで処理を実行することになる。
【０１１５】
まず、Ｓ７１０の処理では、デバイス着脱フラグがＯＮであると判断されるので（Ｓ７１０：ＹＥＳ）、Ｓ７２０の処理をスキップして、Ｓ７３０の処理へと移行する。すなわち、デバイス着脱フラグがＯＮとなった場合は、通信失敗回数カウンタが規定回数未満であるか否かにかかわらず、通信失敗回数カウンタが規定回数未満である場合と同等な処理を実行することになる。そのため、Ｓ７３０、Ｓ７４０の処理を実行することになり、ここで通信に成功すれば（Ｓ７４０：ＮＯ）、通信失敗回数カウンタが規定回数以上になっていた場合でも、Ｓ７５０の処理により、通信失敗回数カウンタはゼロクリアされることになる。
【０１１６】
また、プリンタ２の電源スイッチが再びＯＮにされた場合、あらためて状態情報要求指令をプリンタ２へ送信しない限り、プリンタ２は状態情報を提供可能な状態にならないため、上記Ｓ７４０の処理で通信成功との判断がなされていても、上記Ｓ７６０の処理では取得データなしとの判断がなされることになるが、この時点では、デバイス着脱フラグがＯＮとなっているので、Ｓ７７０の処理では肯定判断がなされることになり、その結果、Ｓ７９０の処理へと移行して、パーサー３３は、状態情報要求指令をプリンタ２へ送信することになる。したがって、以降、プリンタ２は状態情報を提供可能な状態になる。
【０１１７】
また、プリンタ２の電源ＯＮの状態のまま、プラグが抜き差しされた場合にあっては、プリンタ２自体は状態情報を返すことができる状態を維持しているが、その時点でＰＣ１におけるＵＩ上の表示は「プリンタとの通信ができない旨の情報」になっている可能性がある。その場合にあっても、ＰＪＬのＩＮＦＯコマンドにより、プリンタのステータス変化がない場合にあっても情報が返ることになるので、その情報を受信した際にＳ７６０〜Ｓ８２０〜Ｓ８３０の処理により正常なステータス情報に更新される。
【０１１８】
なお、上記実施形態にあっては、プリンタ２以外のデバイスが抜き差しされた場合にあっても、条件が揃えばＰＪＬコマンドをプリンタに送信することになる。しかし、プリンタ２は複数回ＵＳＴＡＴＵＳ  ＯＮコマンドを送られた場合にあっても、同一の状態を維持するので影響はない。またＩＮＦＯコマンドにより、その都度、状態変化がないにもかかわらずその時点の状態を返すことになるが、ＰＣ１におけるＵＩ上には、同一のステータスが表示され続けるのみであり、これも問題はない。
【０１１９】
［上記実施形態の効果］
以上説明したように、上記ＰＣ１によれば、ＰｎＰマネージャ４３からメッセージが届いただけで、プリンタ２に対して状態情報要求指令が送られてしまうことがなく、Ｓ７４０の処理によってプリンタ２と通信可能と判定された場合に、プリンタ２に対して状態情報要求指令が送られる。したがって、プリンタ２との通信ができないにもかかわらず、プリンタ２に対して状態情報要求指令が送られてしまうことがなく、それに起因して発生する種々の不具合を、未然に防止することができる。また、プリンタ２との通信ができる場合には、プリンタ２に対して状態情報要求指令が送られるので、以後は、プリンタ２から適切に状態情報を取得することができるようになる。
【０１２０】
また、上記ＰＣ１によれば、状態情報を取得できなかった場合には、Ｓ７６０の処理で肯定判断がなされることによりＳ７９０の処理へと移行し、プリンタ２に対して状態情報要求指令が送られるものの、状態情報を取得できた場合には、Ｓ７６０の処理で否定判断がなされることによりＳ８２０の処理へと移行し、プリンタ２に対して状態情報要求指令が送られないので、プリンタ２側が既に状態情報を取得できる状態になっているにもかかわらず、無駄に状態情報要求指令がプリンタ２へ送られてしまうのを、未然に防止することができる。
【０１２１】
また、上記ＰＣ１によれば、Ｓ７２０の処理で通信失敗回数カウンタが規定回数以上になったこと、および、Ｓ８６０の処理で通信不可表示フラグがＯＦＦであることを条件にして、通信不可情報を利用者に対して通知すべきと判定されたら、Ｓ８７０〜Ｓ８４０の処理により、通信不可情報がステータスモニターＵＩ３２へと伝達され、その通信不可情報が表示部１６に表示されることで利用者に通知される。したがって、利用者は、ＰＣ１がプリンタ２と通信できない状態にあることを察知することができ、必要があれば適切な対処を行うことができる。
【０１２２】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１２３】
例えば、上記実施形態では、ステータスモニターＵＩ３２が、状態情報をＰＣ１の表示部１６に表示する例を示したが、具体的な出力先は任意であり、例えば、状態情報をログとしてファイルに出力するようにしてもよいし、ログ出力専用のプリンタを用意して印刷出力するようにしてもよい。また、表示出力する場合でも、一旦ファイルに出力し、そのファイルを汎用の表示プログラムを利用して表示するようにしてあってもよい。
【０１２４】
また、上記実施形態では、特定のプリンタポートの仕様や特定のプリンタの仕様を例示したが、プリンタポートの仕様やプリンタの仕様については特に限定されず、また、処理対象となるデバイスも、プリンタに限らず、他のデバイスであってもよい。
【０１２５】
また、例えば、ＬＰＴポートに接続されたプリンタがカバーを開けた状態で電源ＯＮされたとすると、Ｓ７１０の処理によって通信に成功しても、プリンタがオフライン状態になっており、Ｓ７９０の処理による状態情報要求指令を受け付けないため、状態情報要求指令のＰＪＬコマンドがスプーラに溜まってしまうことになる。この場合、図１１に示すように、Ｓ７９０の処理を実行する前に、プリンタに状態情報要求指令を送信可能な状態か否かを判断する処理（Ｓ７８２）を加え、可能である場合は（Ｓ７８２：ＹＥＳ）、Ｓ７９０の処理によって状態情報要求指令を送信するようにする。また、可能でなかった場合は（Ｓ７８２：ＮＯ）、状態情報要求指令送信済みフラグをＯＦＦにし（Ｓ７８４）、いずれプリンタに状態情報要求指令を送信可能な状態になったときに、状態情報要求指令が送信されるようにしておくとよい。
【０１２６】
また、上記実施形態では、ステータスモニターＵＩ３２とパーサー３３との間でプロセス間通信を行う手段として、メッセージや共有メモリなどの具体例を挙げたが、これらプロセス間通信を行う手段は任意であり、例えば、ミューテックス、セマフォなど、どのような通信手段を利用しても構わない。また、ステータスモニターＵＩ３２とパーサー３３とを別プロセスとするか否かは任意であり、ステータスモニターＵＩ３２とパーサー３３としての機能を備えた単一のプロセスが機能するように構成してあってもよい。さらに、上記実施形態では、パーサー３３とアービトレイター３４とを連携させるため、アービトレイター３４をダイナミック・リンク・ライブラリとして用意し、パーサー３３が必要なアービトレイター３４を動的にリンクするように構成してあったが、パーサー３３が必要なアービトレイターを別プロセスとして起動するように構成してもよく、この場合、ステータスモニターＵＩ３２とパーサー３３との連携方法と同様、パーサー３３とアービトレイター３４とがプロセス間通信を行って、相互に必要な情報を伝送するように構成してあればよい。つまり、これらステータスモニターＵＩ３２、パーサー３３、およびアービトレイター３４は、それぞれの機能を実現することができれば、どのような機能単位でプロセスが分かれていてもよいし、分かれていなくてもよい。
【図面の簡単な説明】
【０１２７】
【図１】ＰＣとプリンタとを備えたシステム全体のブロック図。
【図２】ＰＣが備えるソフトウェアの構成図。
【図３】プリンタが出力する状態情報とパーサーが出力する状態情報を例示するための説明図。
【図４】ステータスモニターＵＩが実行する主処理のフローチャート。
【図５】ステータスモニターＵＩが実行するメッセージループ処理のフローチャート。
【図６】パーサーが実行する主処理のフローチャート。
【図７】パーサーが実行する初期化メッセージ処理のフローチャート。
【図８】パーサーが実行する終了メッセージ処理のフローチャート。
【図９】パーサーが実行するデバイス構成変更メッセージ処理のフローチャート。
【図１０】パーサーが実行するタイマーメッセージ処理のフローチャート。
【図１１】パーサーが実行するタイマーメッセージ処理の変形例のフローチャート。
【符号の説明】
【０１２８】
１・・・パーソナルコンピュータ（ＰＣ）、２・・・プリンタ、１１，２１・・・ＣＰＵ、１２，２２・・・ＲＯＭ、１３，２３・・・ＲＡＭ、１４・・・ハードディスク装置（ＨＤＤ）、１５・・・操作部、１６・・・表示部、１７・・・ＵＳＢインターフェース（ＵＳＢ  Ｉ／Ｆ）、２５・・・操作キー、２６・・・表示パネル、２９・・・印字部、３１・・・プリンタドライバーＵＩ、３２・・・ステータスモニターＵＩ、３３・・・ステータスモニターＰＪＬパーサー（パーサー）、３４・・・ＵＳＢ／ＬＰＴローカルポートアービトレイター（アービトレイター）、３５・・・ＵＳＢプリンタクラスドライバー（クラスドライバー）、３６・・・ＵＳＢ物理層、４１・・・スプーラシステム、４３・・・ＰｎＰマネージャ、４５・・・Ｉ／Ｏマネージャ。
【図１】
2007156512.tif 000003
【図２】
2007156512.tif 000004
【図３】
2007156512.tif 000005
【図４】
2007156512.tif 000006
【図５】
2007156512.tif 000007
【図６】
2007156512.tif 000008
【図７】
2007156512.tif 000009
【図８】
2007156512.tif 000010
【図９】
2007156512.tif 000011
【図１０】
2007156512.tif 000012
【図１１】
2007156512.tif 000013