JP2008165510A - ステータスモニタプログラム - Google Patents

Abstract

【課題】情報処理装置が省電力状態への移行・復帰した場合でも適切なステータス情報を表示可能なステータスモニタのプログラムを提供すること。
【解決手段】ＰＣが、省電力状態（第２状態）から通常の作動状態（第１状態）へ復帰し、その旨を示すメッセージがＯＳ側から到来した際、そのメッセージを検知したら（Ｓ１０１１：ＹＥＳ）、ステータス情報の提供開始を要求するための開始信号を、プリンタに対して送信する（Ｓ１０１７）。その結果、仮にＰＣが省電力状態へ移行している間にプリンタ側の状態が初期化されていたとしても、プリンタは、あらためてステータス情報を提供可能な状態になる。したがって、ＰＣは、プリンタの状態を表示する処理を問題なく再開することができる。
【選択図】図１１

Description

本発明は、ステータスモニタプログラムに関する。

従来、コンピュータにおいて、プリンタの動作状況や用紙切れ等のステータス情報をプリンタから受信し、受信したステータス情報をコンピュータのディスプレイに表示する技術は、既に実用化されている。この種の機能を持つソフトウェアは、一般に、ステータスモニタと呼ばれている（例えば、特許文献１参照）。

また、ステータス情報を提供可能なプリンタとしては、ステータス情報の提供開始を要求するための開始信号がコンピュータ側からプリンタ側へ送信されると、その開始信号の受信以降、ステータス情報を提供する状態になるものが知られている。

このようなプリンタからステータス情報を取得したい場合、ステータスモニタは、最初に開始信号の送信処理を実行し、その後は、必要に応じてステータス情報の取得処理を繰り返すことになる。
特開２００６−２６０１８７号公報

ところで、上記のようなコンピュータは、近年、サスペンド機能あるいはハイバネーション機能と呼ばれるような電源管理機能を備えるものが主流になっている。
サスペンド機能を備えるコンピュータは、通常の作動状態（電源オン状態；以下、第１状態ともいう）にあった時の各種情報や状態をメモリに保持したまま、電源オフ状態に近い省電力状態（以下、第２状態ともいう）へ移行することができる。そして、必要時には、省電力状態へ移行する前の状態に復帰することができる。

また、ハイバネーション機能を備えるコンピュータは、通常の作動状態（第１状態）にあった時の各種情報や状態をハードディスク等の記憶装置に書き出した上で、電源オフ状態と同等な省電力状態（第２状態）へ移行することができる。そして、必要時には、記憶装置に書き出しておいた各種情報や状態を読み込むことにより、省電力状態へ移行する前の状態に復帰することができる。

しかし、ステータスモニタが起動されているコンピュータにおいて、上記の様な省電力機能が利用されると、以下に述べるような問題が生じる場合がある。
すなわち、上記の様な省電力機能が利用されるのは、通常、利用者がコンピュータの使用を中断ないし終了するときであるため、同時にプリンタの電源スイッチもオフにされることは多い。そして、その後、利用者がコンピュータやプリンタの使用を再開する時に、コンピュータは省電力状態から通常の作動状態に復帰することになり、その際、あらためてプリンタの電源スイッチがオンにされることがある。

このような場合、プリンタ側においては、電源オフ／オンに伴ってプリンタの状態は初期化されるため、電源オフ前に情報処理装置側から開始信号を受信していたとしても、その開始信号の受信は無効となる。

一方、コンピュータ側においては、コンピュータが省電力状態に移行している間に、プリンタの電源オフ／オンが実施されているので、そのようなプリンタ側での状態変化があったことをコンピュータ側で認識することができない。しかも、コンピュータ側においては、ステータスモニタが、既に開始信号送信済みという状態に復帰するので、以降は、必要に応じてステータス情報の取得処理を繰り返そうとする。

そのため、コンピュータでは、開始信号送信済みとの前提で、ステータス情報の取得処理が行われるものの、プリンタでは、開始信号を受信していないので、コンピュータ側へステータス情報を提供しない状態となる。

したがって、この状態において、例えば、プリンタ側で何らかのエラーが発生したとしても、その様なステータス情報をコンピュータ側で取得することができず、ステータス情報を適切に表示できなくなってしまう、という問題があった。

本発明は、上記問題を解決するためになされたものであり、その目的は、情報処理装置を、省電力状態への移行・復帰後も適切なステータス情報を表示可能なステータスモニタとして機能させることができるステータスモニタプログラムを提供することにある。

以下、本発明において採用した構成について説明する。
本発明のステータスモニタプログラムは、通常の作動状態である第１状態から当該第１状態よりも電力消費を抑制する状態である第２状態へ移行可能、且つ、前記第２状態から前記第１状態に復帰可能に構成された情報処理装置を、前記情報処理装置が前記第２状態から前記第１状態へ復帰したことを検知する第１検知手段と、前記第１検知手段によって前記第１状態への復帰を検知した場合に、画像形成装置に対し、当該画像形成装置の状態を示すステータス情報の提供開始を要求するための開始信号を送信する第１送信手段と、前記開始信号を受信した前記画像形成装置から前記ステータス情報を取得する取得手段と、前記取得手段によって取得された前記ステータス情報に基づいて、前記画像形成装置の状態を表示する表示処理手段として機能させることにより、前記画像形成装置の状態を表示するステータスモニタとして機能させることを特徴とする。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置が第２状態から第１状態へ復帰した時点で、情報処理装置側から画像形成装置側へ開始信号が送信される。

したがって、仮に情報処理装置が第２状態へ移行している間に画像形成装置側の状態が初期化されていたとしても、あらためて画像形成装置の状態を表示する処理を開始することができる。

なお、本発明において、第２状態とは、通常の作動状態である第１状態よりも電力消費を抑制する状態のことであり、いわゆるサスペンド状態、ハイバネート状態は、いずれも本発明でいう第２状態に相当する。また、サスペンド／ハイバネートは、それぞれスタンバイ／休止状態等と呼ばれることもあるが、このように単に呼び方が変わっても、当然ながら本発明でいう第２状態に相当する。

さらに、より高度な電源管理を行う情報処理装置の中には、最初はサスペンド状態へ移行し、その後、バッテリー電圧が所定以下に低下すると、メモリに保持していた情報をハードディスク等の記憶装置に書き出した上で、ハイバネート状態へ移行するものもある。このようなサスペンド状態およびハイバネート状態が併用される状態も、本発明でいう第２状態に相当するものである。

ところで、本発明のステータスモニタプログラムは、前記情報処理装置を、前記画像形成装置と通信可能か通信不能かを判定する第１判定手段として機能させ、前記第１送信手段を、前記第１判定手段によって通信可能と判定された場合に、前記開始信号を送信する手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置が、画像形成装置と通信できることを確認した上で開始信号を送信するので、開始信号を確実に画像形成装置へ伝送することができる。

また、本発明のステータスモニタプログラムは、前記情報処理装置を、前記第１判定手段によって通信不能と判定された場合に、前記情報処理装置を前記ステータスモニタとして機能させる処理を終了する制御手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置において、ステータスモニタが不要な状態であれば、ステータスモニタが終了する。したがって、ステータスモニタが終了する分だけ情報処理装置の資源を開放することができ、情報処理装置にかかる負荷を軽減できる。

また、本発明のステータスモニタプログラムは、前記情報処理装置を、前記第１状態から前記第２状態へ移行することを検知する第２検知手段と、前記第２検知手段によって前記第２状態への移行を検知した場合に、前記画像形成装置に対し、前記ステータス情報の提供終了を要求するための終了信号を送信する第２送信手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置は、第２の状態へ移行する際に、画像形成装置側での処理を終了させる。したがって、画像形成装置における不要な処理を実施しなくてもよくなり、画像形成装置にかかる負荷を軽減できる。

また、前記情報処理装置が、前記第１状態から前記第２状態へ移行してもよいかどうかの問い合わせを行った後、当該問い合わせに対して前記第２状態への移行を拒否する応答がなかった場合に、前記第１状態から前記第２状態へ移行する旨の通知を行った上で、前記第１状態から前記第２状態へ移行するように構成されている場合、本発明のステータスモニタプログラムは、前記第２検知手段を、前記第１状態から前記第２状態へ移行してもよいかどうかの問い合わせを検知する手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置をステータスモニタとして機能させる処理系に対して問い合わせがあった段階で、画像形成装置に対する終了信号が送信される。したがって、情報処理装置が第１状態から第２状態へ移行する前に、終了信号の送信処理を開始することができる。

また、本発明のステータスモニタプログラムは、前記情報処理装置を、前記第２送信手段によって前記終了信号が外部へ送信されたか否かを判定する第２判定手段と、前記第２判定手段によって前記終了信号が外部へ送信されたと判定された場合、前記問い合わせに対して前記第２状態への移行を許可する応答を行う応答手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置は、画像形成装置に対する終了コマンドの送信を確実に行った後に、第１状態から第２状態へ移行することができる。

また、本発明のステータスモニタプログラムは、前記情報処理装置を、前記第１検知手段によって前記第１状態への復帰を検知した場合に、前記画像形成装置に対し、前記画像形成装置のスリープ状態を解除するための信号を送信する第３送信手段として機能させるように構成されていてもよい。

このように構成されたプログラムによって情報処理装置をステータスモニタとして機能させれば、情報処理装置は、第２状態から第１状態への復帰に伴い、事前に画像形成装置のスリープ状態を解除できる。したがって、その後、印刷を行う場合には、直ちに画像形成装置を利用することができる。

次に、本発明の実施形態について一例を挙げて説明する。
［システム全体の構成］
図１は、パーソナルコンピュータ１（本発明でいう情報処理装置の一例に相当；以下、ＰＣ１という）とプリンタ２Ａ、２Ｂ（本発明でいう画像形成装置の一例に相当）とを備えてなるシステム全体の構成を示した概略構成図である。

図１において、ＰＣ１については、ＰＣ１が備えるソフトウェアおよびハードウェアの内、プリンタ２Ａ、２Ｂからステータス情報を取得する処理に関連する処理系だけを抜粋して示してある。

このＰＣ１には、マルチタスク機能を備えたＯＳ（Operating System）が搭載され、複数のプロセスが並列に機能するとともに、それら複数のプロセスが連携して各種処理を実行するようになっている。

このようなマルチタスク機能を有するＯＳの具体例としては、例えば、Ｗｉｎｄｏｗｓ（登録商標）を挙げることができる。なお、ＯＳによって提供される各種機能そのものは公知なので、ここでの詳細な説明は省略するが、以下の説明においては、ＰＣ１が、Ｗｉｎｄｏｗｓ（登録商標）によって提供される各種機能を有するとの前提で説明を続ける。

ＰＣ１において、プリンタ２Ａ、２Ｂからのステータス情報取得処理を実行する処理系は、図１に示すように、ＵＩ（入力／表示）の層、構文解析層、ポートアクセスの層、クラスドライバ、および物理層からなる階層構造になっている。

より具体的には、ＰＣ１において、プリンタ２Ａ、２Ｂに対する印刷出力が行われる際には、プリンタドライバＵＩ１１が印刷関連の処理を実行する。そして、その処理の中で、ステータスモニタＵＩ１２がプリンタドライバＵＩ１１とは別のプロセスとして起動される。

ただし、ステータスモニタＵＩ１２を起動する契機は任意であり、例えば、印刷時にポートモニタがステータスモニタＵＩ１２を起動するように構成されていてもよいし、ＰＣ１の起動時にステータスモニタＵＩ１２が起動されてもよい。あるいは、利用者がマニュアル操作でステータスモニタＵＩ１２を起動できるように構成されていてもよい。

ステータスモニタＵＩ１２は、利用者から情報の入力を受け付ける処理や、ステータス情報を表示する処理を実行するプロセスで、その処理の中で、ステータスデータパーサ１３（以下、単にパーサ１３とも称する。）が、ステータスモニタＵＩ１２とは別のプロセスとして起動される。

パーサ１３は、プリンタ２Ａ、２Ｂに対して、プリンタジョブ言語（ＰＪＬ；Printer Job Language）に準拠した形式で記述されたコマンド（以下、ＰＪＬコマンドともいう）を出力する。そして、そのＰＪＬコマンドを受け取ったプリンタ２Ａ、２Ｂから出力されるステータス情報を取得する。

また、取得したステータス情報の構文解析を行って、そのステータス情報をステータスモニタＵＩ１２が参照可能なデータ形式に変換し、ステータスモニタＵＩ１２へと出力する。なお、ＰＪＬは、プリンタが備える各種機能の制御を可能とするコマンド言語で、Hewlett-Packard社において開発され、その後他社でも採用された周知のものである。

また、パーサ１３は、その処理の中で、ローカルポートアービトレイタ１４（以下、単にアービトレイタ１４とも称する。）を動的にリンクし、これにより、アービトレイタ１４が機能する状態になる。

アービトレイタ１４は、同一ポートを利用する他のプロセスとの間で調停を行って、あるプロセスに渡るべきデータが他のプロセスに渡らないように制御する。
パラレルプリンタクラスドライバ１５Ａ、およびＵＳＢプリンタクラスドライバ１５Ｂ（以下、単にクラスドライバ１５Ａ、１５Ｂとも称する。）は、いずれもＯＳが備える機能の一部である。これらクラスドライバ１５Ａ、１５Ｂは、ＰＣ１の起動時または各クラスドライバ１５Ａ、１５Ｂに対応するデバイスの起動時に起動される。

パラレル物理層１６Ａ、およびＵＳＢ物理層１６Ｂは、各プリンタポートを構成するハードウェアである。
さらに、ＰＣ１に搭載されたＯＳは、スプーラシステム２１、ＰｎＰマネージャ２３、Ｉ／Ｏマネージャ２５などを備えている。

スプーラシステム２１は、ＰＣ１上で機能する複数の処理系（例えばアプリケーション）から出力される印刷データを印刷ジョブとして一元管理し、順次プリンタ２Ａ、２Ｂ側へ送出する処理を実行する周知のシステムである。パーサ１３がＰＪＬコマンドを出力した場合、そのＰＪＬコマンドも、他の印刷データ同様に、一つの印刷ジョブとしてスプーラシステム２１により管理される。

例えば、プリンタ２Ａを出力先とするＰＪＬコマンドであれば、スプーラシステム２１による制御の下、パラレルプリンタクラスドライバ１５Ａおよびパラレル物理層１６Ａ経由で、プリンタ２Ａ側へ送出されることになる。また、プリンタ２Ｂを出力先とするＰＪＬコマンドであれば、ＵＳＢプリンタクラスドライバ１５ＢおよびＵＳＢ物理層１６Ｂ経由で、プリンタ２Ｂ側へ送出されることになる。

本実施形態においては、後述する処理の中で、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”、“ＩＮＦＯ ＤＥＶＩＣＥ”といったＰＪＬコマンドが、スプーラシステム２１経由でプリンタ２Ａ、２Ｂへと伝送される。

ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”は、プリンタ２Ａ、２Ｂの状態が変化したときにステータス情報を提供する処理の開始をプリンタ２Ａ、２Ｂに対して命令するコマンドである。また、ＰＪＬコマンド“ＩＮＦＯ ＤＥＶＩＣＥ”は、その時点でのステータス情報の提供をプリンタ２Ａ、２Ｂに対して命令するコマンドである。

これらの命令を受けたプリンタ２Ａ、２Ｂは、ステータス情報を提供可能な状態になるので、パーサ１３は、所望のタイミングでプリンタ２Ａ、２Ｂからステータス情報を読み取る（リードバックする）ことができる。

また、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”は、プリンタ２Ａ、２Ｂによるステータス情報提供処理の終了をプリンタ２Ａ、２Ｂに対して命令するコマンドである。この命令を受けたプリンタ２Ａ、２Ｂは、ステータス情報の提供処理を終了する。

プリンタ２Ａ、２Ｂからステータス情報が提供される状態になった場合、パーサ１３は、プリンタ２Ａ、２Ｂから読み取ったステータス情報を、ステータスモニタＵＩ１２側で扱うためのバイナリデータに変換する。そして、変換後のステータス情報をプロセス間通信により上位のステータスモニタＵＩ１２へと出力する。

また、ＰｎＰマネージャ２３およびＩ／Ｏマネージャ２５は、プリンタ２Ａ、２Ｂの接続および切断に関する状態変化があった場合に、その旨を各プロセスに通知する機能を備えている。

より詳しくは、プリンタ２Ａ、２Ｂを含む各種デバイスの接続および切断に関する状態変化があった場合、その状態変化がＩ／Ｏマネージャ２５によって検出される。そして、Ｉ／Ｏマネージャ２５と連携して機能するＰｎＰマネージャ２３は、各プロセスにメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”を通知する。

したがって、ＰＣ１上で機能する各プロセスは、ＰｎＰマネージャ２３からの通知（＝メッセージ）に基づいて、プリンタ２Ａ、２Ｂの接続および切断に関する状態変化があったことを認識することができる。

本実施形態の場合は、パーサ１３が、プリンタ２Ａ、２Ｂの接続および切断に関する状態変化があったことを認識した場合に、それに応じた処理を実行することになるが、その処理の詳細については後述する。

［ＰＣにおいて実行される各種処理］
次に、ＰＣ１において実行される各種処理について、フローチャートに基づいてより具体的に説明する。

［プリンタドライバインストール処理］
まず、ステータス情報を表示する処理に先立って行われるプリンタドライバのインストール処理について、図２のフローチャートに基づいて説明する。このプリンタドライバのインストール処理は、新たなプリンタ（例えば、プリンタ２Ａ、２Ｂ）をＰＣ１から利用できるようにしたい場合に実行される処理である。

プリンタドライバインストール処理を開始すると、ＰＣ１は、まず、通常のプリンタドライバインストール処理を実行する（Ｓ１０１）。このＳ１０１の処理では、例えば、プリンタドライバのプログラムを格納したファイルのファイル名をＯＳの管理する記憶領域に登録する処理など、この種のＰＣにプリンタを導入する際に一般的に行われている一連の処理が実行される。

そして、ステータスモニタ設定ファイルにプリンタ名とパーサ名を登録して（Ｓ１０３）、本処理を終える。ステータスモニタ設定ファイルは、ＰＣ１が備えるハードディスク等の記憶装置に格納されているファイルである。このステータスモニタ設定ファイルには、ＰＣ１がステータスモニタとして機能する際に必要となる各種情報が記録されるようになっている。

上記Ｓ１０３の処理では、インストール中のプリンタドライバに対応するプリンタのプリンタ名と、そのプリンタに対応するパーサ名（＝パーサプログラムが格納されたファイルのファイル名）とが、対にして記録される。この記録は、後述する処理の中で、プリンタ名に基づいて起動すべきパーサ１３を特定する際に参照されることになる。

［印刷処理］
次に、ＰＣ１が実行する印刷処理について、図３のフローチャートに基づいて説明する。この印刷処理は、印刷機能を持ったアプリケーションプログラムに従ってＰＣ１が各種処理を行う中で、プリンタドライバが起動されると実行される処理である。

この処理を開始すると、ＰＣ１は、まず、プリンタドライバに関する設定を行うか否かを判断する（Ｓ２０１）。ここで、利用者が設定を行う旨の操作を行っている場合には（Ｓ２０１：ＹＥＳ）、設定用のダイアログを表示して利用者の操作を受け付け、設定された内容を所定の記憶領域に保存する（Ｓ２０３）。

また、利用者が設定を行う旨の操作を行っていない場合（Ｓ２０１：ＮＯ）、もしくはＳ２０３の処理を終えた場合は、引き続いて、印刷処理を行うか否かを判断する（Ｓ２０５）。

ここで、まだ印刷処理を行わない場合は（Ｓ２０５：ＮＯ）、Ｓ２０１の処理へと戻ることにより、Ｓ２０１〜Ｓ２０５の処理を繰り返し、プリンタに対する設定処理を継続する。

一方、Ｓ２０５の処理で、印刷処理を行うと判断された場合は（Ｓ２０５：ＹＥＳ）、引き続いて、ステータスモニタＯＮの設定がなされているか否かを判断する（Ｓ２０７）。

ステータスモニタＯＮ／ＯＦＦの設定は、上記Ｓ２０３の処理で行うことができ、ステータスモニタＯＮの設定になっていたら（Ｓ２０７：ＹＥＳ）、ステータスモニタＵＩ１２を、別のプロセスとして起動する（Ｓ２０９）。

そして、ステータスモニタＯＮの設定になっていなかった場合（Ｓ２０７：ＮＯ）、もしくはＳ２０９の処理を終えた場合には、引き続いて、通常の印刷処理を行い（Ｓ２１１）、本処理を終える。

なお、Ｓ２１１の処理は、スプーラシステム２１からＦＩＦＯで送出される印刷データをプリンタ２Ａ、２Ｂ側へ伝送する処理や、同印刷データに対して二次的な加工を施す処理であるが、これらは周知の処理なので、ここでの詳細な説明は省略する。

［ステータスモニタＵＩ処理］
次に、上記Ｓ２０９の処理によって起動されるステータスモニタＵＩ１２の処理について、図４のフローチャートに基づいて説明する。

この処理を開始すると、ステータスモニタＵＩ１２は、まず、パーサ名の読み込みを行う（Ｓ３０１）。この処理では、先に説明したＳ１０３の処理において、ステータスモニタ設定ファイルに登録された情報（プリンタ名とパーサ名との対応関係）が参照され、このステータスモニタＵＩ１２が対象としているプリンタに対応するパーサ名が読み込まれる。

そして、Ｓ３０１の処理で読み込んだパーサ名を使用して、パーサ１３を別のプロセスとして起動する（Ｓ３０３）。このとき、パーサ１３には、プリンタ名をコマンドラインで渡す。

続いて、別プロセスでステータスモニタＵＩ１２を既に起動済みかどうかを判断し（Ｓ３０５）、起動済みでなければ（Ｓ３０５：ＮＯ）、メッセージループ処理に移行する（Ｓ３０７）。また、起動済みである場合（Ｓ３０５：ＹＥＳ）、もしくはＳ３０７の処理を終えた場合は、本処理を終了する。

Ｓ３０７のメッセージループ処理は、詳しくは図５のフローチャートに示すような処理となる。このメッセージループ処理では、メッセージとして到来する指示の内容を判断して、その指示（メッセージ）に対応する処理を実行することが繰り返される。

具体的には、まず、メッセージによる指示が“初期化”かどうかを判断し（Ｓ４０１）、“初期化”であれば（Ｓ４０１：ＹＥＳ）、初期化処理を実行して（Ｓ４０３）、Ｓ４０１の処理へと戻る。

また、メッセージによる指示が“初期化”でない場合（Ｓ４０１：ＮＯ）、メッセージによる指示が“終了”かどうかを判断し（Ｓ４０５）、“終了”であれば（Ｓ４０５：ＹＥＳ）、他プロセスとの間の全通信を閉じて（Ｓ４０７）、このメッセージループ処理を終える。

また、メッセージによる指示が“終了”でない場合（Ｓ４０５：ＮＯ）、パーサ１３からのメッセージかどうかを判断する（Ｓ４０９）。パーサ１３からのメッセージとは、上述したＳ３０３の処理で起動したパーサ１３のプロセスから到来するメッセージである。

パーサ１３が実行する処理の具体的な内容については、後から詳述するが、このメッセージループ処理では、パーサ１３との間でプロセス間通信を行いながら、各種処理を実行することになる。

Ｓ４０９の処理において、パーサ１３からのメッセージでない場合は（Ｓ４０９：ＮＯ）、その他のメッセージに対する処理を実行した上で（Ｓ４１１）、Ｓ４０１の処理へと戻る。

一方、Ｓ４０９の処理において、パーサ１３からのメッセージであった場合は（Ｓ４０９：ＹＥＳ）、そのメッセージによる指示が“インストール”かどうかを判断する（Ｓ４１３）。ここで、“インストール”であれば（Ｓ４１３：ＹＥＳ）、対象となるパーサ１３との通信を確立する（Ｓ４１５）。

Ｓ４１５の処理において、本実施形態では、後述するパーサ１３処理において確保される共有メモリにアタッチして、共有メモリを介してプロセス間でデータのやり取りを行う方法を採用している。ただし、プロセス間で相互にデータを送受信できるような仕組みになっていれば、対象となるパーサ１３との具体的な通信手順や通信方法については、特に限定されない。

Ｓ４１５の処理を終えたら、表示バッファを確保して（Ｓ４１７）、Ｓ４０１の処理へと戻る。表示バッファは、ＰＣ１が備える表示部にステータス情報を表示出力するためのバッファである。

また、メッセージによる指示が“インストール”でない場合（Ｓ４１３：ＮＯ）、メッセージによる指示が“ステータスアップデート”かどうかを判断する（Ｓ４１９）。
ここで、“ステータスアップデート”であれば（Ｓ４１９：ＹＥＳ）、アタッチしている共有メモリからステータス情報を読み出し、そのステータス情報を対象となる表示バッファに書き込むことにより更新する（Ｓ４２１）。

表示バッファは、上記Ｓ４１７の処理によって確保されたメモリであるが、複数のパーサ１３が起動されている場合には、Ｓ４１７の処理が複数のパーサ１３と同数回実行されて、複数の表示バッファが確保されている。

そこで、このＳ４２１の処理では、メッセージに基づいて、どのパーサ１３から到来したメッセージなのかを特定し、特定したパーサ１３に対応する表示バッファを対象にして表示バッファを更新する。

そして、表示バッファを更新したら、更新したステータス情報をＰＣ１が備える表示部に実際に表示出力するため、表示部の表示を更新するための制御を実行する（Ｓ４２３；Ｓ４２３の処理を実行する手段が、本発明でいう表示処理手段の一例に相当）。そして、Ｓ４２３の処理を終えたら、Ｓ４０１の処理へと戻る。

また、メッセージによる指示が“ステータスアップデート”でない場合（Ｓ４１９：ＮＯ）、メッセージによる指示が“アンインストール”かどうかを判断する（Ｓ４２５）。ここで、“アンインストール”であれば（Ｓ４２５：ＹＥＳ）、対象となるパーサ１３との通信を閉じる（Ｓ４２７）。

具体的には、本実施形態では、上記Ｓ４１５の処理でアタッチした共有メモリをデタッチする。ただし、上記Ｓ４１５の処理において共有メモリ以外の手段でプロセス間通信を実現した場合は、そのプロセス間通信のために確保したリソースを解放する処理等を行うことになる。

そして、Ｓ４１７の処理で確保した対象表示バッファを消去する（Ｓ４２９）。なお、これらＳ４２７およびＳ４２９の処理でも、メッセージに基づいて、どのパーサ１３から到来したメッセージなのかを特定する。パーサ１３を特定したら、特定したパーサ１３との通信を閉じるとともに、特定したパーサ１３に対応する表示バッファを対象にして表示バッファを消去することになる。

そして、監視対象となるパーサ１３のプロセスが一つもない状態になったかどうかを判断し（Ｓ４３１）、監視対象となるパーサ１３のプロセスが残っていれば（Ｓ４３１：ＮＯ）、Ｓ４０１の処理へと戻る。一方、Ｓ４３１の処理において、監視対象となるパーサ１３のプロセスが残っていなければ（Ｓ４３１：ＹＥＳ）、このメッセージループ処理を終える。

なお、Ｓ４２５の処理において、“アンインストール”でなければ（Ｓ４２５：ＮＯ）、その他の処理を実行して（Ｓ４３３）、Ｓ４０１の処理へと戻る。
［パーサ処理］
次に、パーサ処理について、図６〜図１０のフローチャートに基づいて説明する。

ステータスモニタＵＩ１２が、以上説明したようなメッセージループ処理を実行するのと並行して、上記Ｓ３０３の処理（図４参照）によって起動されたパーサ１３は、図６のフローチャートに示す処理を実行する。

具体的には、パーサ１３は、まず、図６に示す処理を実行し、この処理の中でメッセージ配信処理を実行する（Ｓ５０１）。このＳ５０１の処理は、所定の条件が成立すると、図７〜図１０に示した各処理を含む複数の処理の内、成立した条件に応じた処理を実行するものである。

また、このＳ５０１の処理において、成立した条件が終了条件であった場合、Ｓ５０１の処理を終了することになり、その場合は、図６に示した処理全体を終了することになる。

ただし、成立した条件が終了条件以外の条件であった場合は、Ｓ５０１の処理は終了せず、再び新たに所定の条件が成立するまで待機し、所定の条件が成立すれば、成立した条件に応じた処理を実行する。

つまり、Ｓ５０１の処理は、終了条件が成立するまでは、終了条件以外の条件が成立する毎に、成立した条件に応じた処理の実行を繰り返すことになる。
以下、Ｓ５０１の処理において、各種条件が成立した場合に実行される処理について説明する。

［初期化メッセージ処理］
まず、図７に示す初期化メッセージ処理について説明する。この初期化メッセージ処理は、パーサ１３の起動直後であるとの条件が成立した場合に実行される処理となる。

初期化メッセージ処理を開始すると、パーサ１３は、まず、各種フラグの初期化を行う（Ｓ６０１）。このＳ６０１の処理において、デバイス着脱フラグ、データ要求指令送信済みフラグ、および通信不可表示フラグには初期値としてＯＦＦが設定され、通信失敗回数カウンタはゼロクリアされる。

続いて、パーサ１３は、ステータスモニタＵＩ１２との通信確立を行うための準備を行う（Ｓ６０３）。具体的には、共有メモリとなるメモリ領域を確保する処理などが行われる。そして、パーサ１３の起動時に引数として渡されたプリンタ名に基づいて、そのプリンタが使用するポート名を調査し（Ｓ６０５）、そのポート名に応じた下位層のロードを行う（Ｓ６０７）。

Ｓ６０７の処理においてロードされるプログラムは、ダイナミック・リンク・ライブラリ（以下、ＤＬＬともいう）として提供され、パーサ１３としての処理を実行するプロセスが、ポート名に応じたアービトレイタ１４をメモリにロードする。以降、パーサ１３は、処理対象としているプリンタが利用するポートに対応したアービトレイタ１４を利用して、ステータス情報を取得することができるようになる。

以上の処理を終えたら、パーサ１３は、ステータスモニタＵＩ１２のプロセスに対して、インストールメッセージを送信する（Ｓ６０９）。このメッセージは、先に説明したステータスモニタＵＩ１２のメッセージループ処理（図５参照）において、Ｓ４１５、Ｓ４１７の処理を実行する契機となるメッセージである。

このメッセージを受けたステータスモニタＵＩ１２側の処理が完了した時点で、ステータスモニタＵＩ１２とパーサ１３との通信が確立することになる。なお、Ｓ６０９の処理を終えたら、図７に示した初期化メッセージ処理を終えることになり、以降、パーサ１３は、上記Ｓ５０１（図６参照）の処理において、再び所定の条件が成立するまで待機することになる。

［終了メッセージ処理］
次に、図８に示す終了メッセージ処理について説明する。この終了メッセージ処理は、終了条件が成立した場合に実行される処理である。例えば、利用者がＰＣ１の操作部を操作して所定の終了指示を入力した場合に終了条件が成立し、終了メッセージ処理が実行されることになる。また、エラーその他の事情により、終了条件が成立することもある。

終了メッセージ処理を開始すると、パーサ１３は、アンインストールメッセージを送信する（Ｓ７０１）。このメッセージは、先に説明したステータスモニタＵＩ１２のメッセージループ処理（図５参照）において、Ｓ４２７〜Ｓ４３１の処理を実行する契機となるメッセージである。

そして、Ｓ７０１の処理を終えたら、Ｓ６０３の処理（図７参照）で準備された共有メモリを解放する処理などを行った上で、図８に示した終了メッセージ処理を終えることになる。終了メッセージ処理を終えた場合、パーサ１３は、上記Ｓ５０１の処理（図６参照）を終えることになる。

［デバイス構成変更メッセージ処理］
次に、図９に示すデバイス構成変更メッセージ処理について説明する。本実施形態において、ＰＣ１に接続されているデバイスの構成に変更があった場合には、ＰｎＰマネージャ２３からパーサ１３にメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”が通知される（図１参照）。この機能は、本実施形態においてＰＣ１に搭載されたＯＳが持つ機能である。

ここで、デバイスの構成に変更があった場合とは、例えば、プリンタ２Ａ、２Ｂの電源スイッチがＯＮ／ＯＦＦいずれか一方から他方に切り替えられた場合、あるいは、ＰＣ１とプリンタ２Ａ、２Ｂとを接続するための通信ケーブルが抜き挿しされた場合等である。

以下に説明するデバイス構成変更メッセージ処理は、上記メッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”がＰｎＰマネージャ２３から通知されたとの条件が成立した場合に実行される処理となる。

デバイス構成変更メッセージ処理を開始すると、パーサ１３は、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）か否かを判断する（Ｓ８０１）。

より詳しくは、パーサ１３にメッセージ“ＷＭ＿ＤＥＶＩＣＥＣＨＡＮＧＥ”が通知された場合、メッセージにはいくつかのパラメータが付属している。そこで、Ｓ８０１の処理では、メッセージに付属するパラメータが“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”であるか否かを判断する。

Ｓ８０１の処理において、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）であった場合（Ｓ８０１：ＹＥＳ）、パーサ１３は、デバイス着脱フラグをＯＮにする（Ｓ８０３）。そして、デバイス構成変更メッセージ処理を終了する。

一方、Ｓ８０１の処理において、発生したイベントがデバイスノード変更イベント（“ＤＢＴ＿ＤＥＶＮＯＤＥＳ＿ＣＨＡＮＧＥＤ”イベント）ではなかった場合（Ｓ８０１：ＮＯ）、パーサ１３は、そのままデバイス構成変更メッセージ処理を終了する。なお、Ｓ８０３の処理においてＯＮがセットされたデバイス着脱フラグは、後述するタイマーメッセージ処理の中で参照されることになる。

［タイマーメッセージ処理］
次に、図１０に示すタイマーメッセージ処理について説明する。このタイマーメッセージ処理は、一定時間が経過したとの条件が成立した場合に実行される処理、すなわち、一定時間が経過するたびに繰り返し実行される処理となる。ただし、その繰り返し処理の中で各種フラグの値その他が変化するため、タイマーメッセージ処理内における処理の流れは随時変化する。

そこで、以下の説明においては、タイマーメッセージ処理が実行される際の様々な状況を想定しながら、想定した状況に応じたタイマーメッセージ処理の流れについて説明することにする。

まず、初期段階として、プリンタ２Ａ、２Ｂとの通信を正常に実行できる状況下で、タイマーメッセージ処理が初めて実行された場合を想定して説明を続ける。
タイマーメッセージ処理を開始すると、パーサ１３は、まず、デバイス着脱フラグがＯＮであるか否かを判断する（Ｓ９０１）。このデバイス着脱フラグには、上記デバイス構成変更メッセージ処理（図９参照）が実行されると、その処理の中でＯＮがセットされることがある。

ただし、初期段階においては、多くの場合、上記初期化メッセージ処理（図７参照）の中で初期値：ＯＦＦがセットされたままになっている。そこで、ここでは、デバイス着脱フラグにＯＦＦがセットされていることを想定して以下の説明を続けることにし、デバイス着脱フラグにＯＮがセットされている場合については、後から別途説明する。

デバイス着脱フラグはＯＦＦとなっている場合（Ｓ９０１：ＮＯ）、パーサ１３は、通信失敗回数カウンタが規定回数（例えば５回）未満か否かを判断する（Ｓ９０３）。
通信失敗回数カウンタは、後述する処理の中でプリンタ２Ａ、２Ｂとの通信に失敗するとカウントアップされる場合があるが、初期段階では、上記初期化メッセージ処理（図７参照）の中でゼロクリアされている。

Ｓ９０３の処理で、通信失敗回数カウンタの値は規定回数未満であると判断された場合（Ｓ９０３：ＹＥＳ）、パーサ１３は、下位（＝アービトレイタ１４）よりデータ（＝ステータス情報）を受信する（Ｓ９０５；Ｓ９０５の処理を実行する手段が、本発明でいう取得手段の一例に相当）。そして、その通信に失敗したか否かを判断する（Ｓ９０７）。

より詳しくは、Ｓ９０５の処理では、まずプリンタ２Ａ、２Ｂとの間でネゴシエーションを行って通信を確立し、通信を確立した後にステータス情報の受信を行う。
そして、Ｓ９０７の処理では、通信確立に成功し、且つ、ステータス情報の受信が正常終了すれば、通信成功と判断する。一方、Ｓ９０７の処理において、通信確立に失敗するか、あるいは、ステータス情報の受信が異常終了したら、通信失敗と判断する。

Ｓ９０７の処理において、プリンタ２Ａ、２Ｂの電源がＯＮになっていて、プリンタ２Ａ、２Ｂとの間で正常な通信ができる場合は、通信成功と判断される（Ｓ９０７：ＮＯ）。その場合は、通信失敗回数カウンタをゼロクリアし（Ｓ９１１）、Ｓ９０５の処理で取得したデータ（＝ステータス情報）がないかどうかを判断する（Ｓ９１３）。

すなわち、Ｓ９１３の処理が実行されるのはＳ９０７の処理で通信成功と判断された場合であるが、通信に成功した結果として、取得したデータがない場合があり、そのような場合には、Ｓ９１３の処理で肯定判断がなされることになる。

ここで、Ｓ９０５の処理でデータ（＝ステータス情報）を受信するためには、事前にプリンタ２Ａ、２Ｂに対してデータ要求指令（＝ＰＪＬコマンド）を送信することにより、プリンタ２Ａ、２Ｂがステータス情報を提供できる状態にしておく必要がある。

しかし、初期段階では、データ要求指令（＝ＰＪＬコマンド）の送信が行われないままＳ９０５の処理が実行されることになる。そのため、プリンタ２Ａ、２Ｂからデータ（＝ステータス情報）が提供されることはなく、Ｓ９１３の処理では、必ず取得データなしとの判断がなされることになる（Ｓ９１３：ＹＥＳ）。

そこで、パーサ１３は、引き続いて、デバイス着脱フラグはＯＮであるか否かを判断することになる（Ｓ９１５）。初期段階では、上述の想定通り、デバイス着脱フラグがＯＦＦとなっているので（Ｓ９１５：ＮＯ）、パーサ１３は、データ要求指令送信済みフラグはＯＦＦであるか否かを判断する（Ｓ９１７）。

初期段階において、データ要求指令送信済みフラグには、上記初期化メッセージ処理（図７参照）の中で初期値：ＯＦＦがセットされているので、Ｓ９１７の処理では肯定判断がなされる（Ｓ９１７：ＹＥＳ）。その場合、パーサ１３は、データ要求指令である“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令をプリンタ２Ａ、２Ｂへ送信する（Ｓ９１９）。

具体的なデータ要求指令の送信方法は、送信対象となるプリンタの仕様やそのプリンタが使用するプリンタポートの仕様などを考慮して、問題なくプリンタへデータ要求指令を送信できる方法であれば任意である。

ただし、本実施形態において、データ要求指令としては、ＰＪＬコマンドの一つである“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令を送信する。ＰＣ１からプリンタ２Ａ、２Ｂへの各種指令としてＰＪＬコマンドを伝送（上記Ｓ９１９の処理の場合は、データ要求指令として“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令を伝送）する場合、ＰＣ１ではスプーラシステム２１が利用される。

すなわち、ＰＣ１が備えるスプーラシステム２１において、ＰＪＬコマンドは一つの印刷ジョブとして処理され、これにより、Ｓ９１９の処理の場合、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令がプリンタ２Ａ、２Ｂへと送信されることになる。

このように、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令は、スプーラシステム２１を利用して送信される命令なので、他の印刷ジョブと“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令が混在するかたちで同時にプリンタ２Ａ、２Ｂに送信されてしまうのを防止することができる。

以上説明したような“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令をプリンタ２Ａ、２Ｂへ送信したら、パーサ１３は、データ要求指令送信済みフラグをＯＮにし（Ｓ９２１）、デバイス着脱フラグをＯＦＦにして（Ｓ９２３）、図１０に示すタイマーメッセージ処理を終了する。

さて次に、上記初期段階とは異なる様々な状況を想定しつつ、再び実行されるタイマーメッセージ処理の流れについて説明する。
再びタイマーメッセージ処理を実行した場合、パーサ１３は、既に上記Ｓ９１９の処理によって“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令をプリンタ２Ａ、２Ｂに対して送信している。したがって、上記Ｓ９０５の処理においては、下位よりデータ（＝ステータス情報）を受信することができる。

本実施形態において、Ｓ９０５の処理でデータを受信するのに先立ち、パーサ１３が受信バッファとなるメモリを確保し、その受信バッファのアドレスを引数としてアービトレイタ１４側に渡している。

アービトレイタ１４は、パーサ１３によって指定されたアドレスにデータを格納し、これにより、そのデータがパーサ１３側で受信される。その際、アービトレイタ１４は、各クラスドライバ１５Ａ、１５Ｂの仕様に応じた方式で、プリンタ２Ａ、２Ｂからのステータス情報を入力し、そのステータス情報を受信バッファに格納する。

このようにアービトレイタ１４は、クラスドライバ１５Ａ、１５Ｂの仕様に応じた方式でステータス情報を入力するものの、入力したステータス情報は、クラスドライバ１５Ａ、１５Ｂの仕様に依存しない形式で受信バッファに格納される。

これにより、パーサ１３は、プリンタポートの仕様を全く意識することなく、受信バッファに格納されたステータス情報を参照することができる。
実際にパーサ１３が下位からデータを取得するか否かは、プリンタ２Ａ、２Ｂの状態に何らかの変化があったか否かによっても変わる。

Ｓ９０５の処理においてパーサ１３が下位からデータを取得していた場合、Ｓ９１３の処理では、取得したデータ（＝ステータス情報）があると判断されることになる（Ｓ９１３：ＮＯ）。その場合、パーサ１３は、ステータスモニタＵＩ１２との通知バッファにデータ（＝ステータス情報）を書き込む（Ｓ９２５）。

Ｓ９２５の処理でステータス情報を書き込む通知バッファは、上記Ｓ６０３の処理（図７参照）で確保した共有メモリであり、この共有メモリにステータス情報を書き込むことにより、ステータスモニタＵＩ１２側で最新のステータス情報を参照できるようになる。

なお、Ｓ９０５の処理で、受信バッファに格納されたステータス情報は、プリンタ２Ａ、２Ｂの仕様に依存した（＝仕様に応じた差異がある）データ形式になっている。これに対し、Ｓ９２５の処理では、受信バッファに格納されたステータス情報の字句・構文の解析を行い、所定のデータ形式に変換した上で、変換後のステータス情報を共有メモリに書き込む。

これにより、ステータスモニタＵＩ１２側では、ＰＪＬの仕様を全く意識することなく、共有メモリに格納されたステータス情報を参照することができる。
以上のようなＳ９２５の処理を終えたら、パーサ１３は、通信不可表示フラグをＯＦＦにして（Ｓ９２７）、ステータスモニタＵＩ１２のプロセスに対して、ステータスアップデートメッセージを送信する（Ｓ９２９）。このメッセージは、先に説明したステータスモニタＵＩ１２のメッセージループ処理（図５参照）において、Ｓ４２１、Ｓ４２３の処理を実行する契機となるメッセージである。

そして、Ｓ９２９の処理を終えたら、既に説明したＳ９２３の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。
一方、Ｓ９０５の処理において、パーサ１３が下位からデータを取得していなかった場合、Ｓ９１３の処理では、取得したデータ（＝ステータス情報）がないと判断されることになる（Ｓ９１３：ＹＥＳ）。その場合は、上述したＳ９１５、Ｓ９１７の処理へと移行する。

このとき、既にＳ９２１の処理を実行していれば、データ要求指令送信済みフラグにはＯＮがセットされているので、Ｓ９１７の処理では否定判断がなされることになる（Ｓ９１７：ＮＯ）。この場合、以降は、既に説明したＳ９２３の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。

さて、以上がプリンタ２Ａ、２Ｂとの通信が正常に実施できる場合の処理の流れであるが、こうした場合以外に、プリンタ２Ａ、２Ｂとの通信が正常に実施できなくなる場合も考え得る。

例えば、プリンタ２Ａ、２Ｂの電源スイッチがＯＦＦにされた場合や、プリンタ２Ａ、２Ｂとの間の通信ケーブルがコネクタから抜かれた場合等は、プリンタ２Ａ、２Ｂとの通信が正常に実施できなくなることがある。そのような場合、タイマーメッセージ処理は、以下のような流れで処理を実行することになる。

すなわち、タイマーメッセージ処理を実行した際に、通信失敗回数カウンタの値がまだ規定回数（例えば５回）未満であれば、Ｓ９０３の処理では肯定判断がなされる（Ｓ９０３：ＹＥＳ）。その場合、パーサ１３は、上記Ｓ９０５の処理を実行することになる。

しかし、プリンタ２Ａ、２Ｂとの通信が正常に実施できないため、上記Ｓ９０７の処理では、通信失敗との判断がなされることになる（Ｓ９０７：ＹＥＳ）。その場合、通信失敗回数カウンタをカウントアップして（Ｓ９３１）、既に説明したＳ９２３の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。

ここで、タイマーメッセージ処理は、既に述べた通り、一定時間が経過するたびに実行される。そのため、上記のような流れとなる処理が何回か繰り返されて、そのたびに上記Ｓ９３１の処理が実行されると、通信失敗回数カウンタの値は規定回数（例えば５回）を超えることになる。

そして、タイマーメッセージ処理を実行した際に、通信失敗回数カウンタの値が規定回数（例えば５回）以上になっていたら、Ｓ９０３の処理では否定判断がなされる（Ｓ９０３：ＮＯ）。その場合、パーサ１３は、通信不可表示フラグはＯＦＦであるか否かを判断する（Ｓ９３３）。

Ｓ９３３の処理において、通信不可表示フラグがＯＦＦであった場合は（Ｓ９３３：ＹＥＳ）、プリンタ２Ａ、２Ｂとの通信ができない旨の情報（＝通信不可情報）をステータスモニタＵＩ１２にまだ通知していないことを意味する。

したがって、この場合、パーサ１３は、通信不可情報を通知バッファに書き込み（Ｓ９３５）、通信不可表示フラグをＯＮにして（Ｓ９３７）、上記Ｓ９２９の処理へと移行する。

これにより、パーサ１３からステータスモニタＵＩ１２のプロセスに対してステータスアップデートメッセージが送信されることになる。そして、以降は、既に説明したＳ９２３の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。

また、Ｓ９３３の処理において、通信不可表示フラグがＯＦＦでなかった場合は（Ｓ９３３：ＮＯ）、プリンタ２Ａ、２Ｂとの通信ができない旨の情報（＝通信不可情報）をステータスモニタＵＩ１２に既に通知していることを意味する。

そこで、この場合は、あらためて通信不可情報をステータスモニタＵＩ１２に通知するようなことはしないまま、既に説明したＳ９２３の処理へと移行し、その後、図１０に示すタイマーメッセージ処理を終了することになる。

なお、プリンタ２Ａ、２Ｂとの通信できなくなった場合でも、デバイス構成変更メッセージが生じる可能性はあり、このメッセージにより、一旦デバイス着脱フラグはＯＮとなる。

この場合、通信失敗回数カウンタが規定回数以上であっても、Ｓ９０５の処理によりデータ受信処理を実施することになる。ただし、Ｓ９２３の処理によりデバイス着脱フラグはＯＦＦされるので、一度のみデータ受信処理がなされるだけで済み、この点は影響がないに等しい。

さて、以上がプリンタ２Ａ、２Ｂとの通信が正常に実施できない場合の処理となるが、その後、プリンタ２Ａ、２Ｂとの通信が再び正常に実施できることもある。
例えば、プリンタ２Ａ、２Ｂの電源スイッチが再びＯＮにされた場合や、プリンタ２Ａ、２Ｂとの間の通信ケーブルが再びコネクタに挿し込まれた場合であれば、プリンタ２Ａ、２Ｂとの通信が再び正常に実施できる。

そのような場合、上述したデバイス構成変更メッセージ処理（図９参照）が実行され、デバイス着脱フラグがＯＮとなるので、それに伴って、タイマーメッセージ処理は、以下のような流れで処理を実行することになる。

まず、Ｓ９０１の処理では、デバイス着脱フラグがＯＮであると判断されるので（Ｓ９０１：ＹＥＳ）、Ｓ９０３の処理をスキップして、Ｓ９０５の処理へと移行する。
すなわち、デバイス着脱フラグがＯＮとなった場合は、通信失敗回数カウンタが規定回数未満であるか否かにかかわらず、通信失敗回数カウンタが規定回数未満である場合と同等な処理を実行することになる。

そのため、Ｓ９０５、Ｓ９０７の処理を実行することになり、ここで通信に成功すれば（Ｓ９０７：ＮＯ）、通信失敗回数カウンタが規定回数以上になっていた場合でも、Ｓ９１１の処理により、通信失敗回数カウンタはゼロクリアされることになる。

また、プリンタ２Ａ、２Ｂの電源スイッチが再びＯＮにされた場合、あらためて“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令をプリンタ２Ａ、２Ｂへ送信しない限り、プリンタ２Ａ、２Ｂはステータス情報を提供可能な状態にならない。

そのため、上記Ｓ９０７の処理で通信成功との判断がなされていても、上記Ｓ９１３の処理では取得データなしとの判断がなされることになる。しかし、この時点では、デバイス着脱フラグがＯＮとなっているので、Ｓ９１５の処理では肯定判断がなされることになる。

その結果、Ｓ９１９の処理へと移行して、パーサ１３は、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令をプリンタ２Ａ、２Ｂへ送信することになる。したがって、以降、プリンタ２Ａ、２Ｂはステータス情報を提供可能な状態になる。

また、プリンタ２Ａ、２Ｂの電源ＯＮの状態のまま、プラグが抜き差しされた場合にあっては、プリンタ２Ａ、２Ｂ自体はステータス情報を返すことができる状態を維持している。ただし、その時点でＰＣ１におけるＵＩ上の表示は「プリンタとの通信ができない旨の情報」になっている可能性がある。

そのような場合、プリンタのステータス変化がなくても、ＰＪＬのＩＮＦＯコマンドによって情報が返ることになるので、その情報を受信した際にＳ９１３→Ｓ９２５→Ｓ９２７の処理により正常なステータス情報に更新される。

なお、上記実施形態にあっては、プリンタ２Ａ、２Ｂ以外のデバイスが抜き差しされた場合、条件が揃えばＰＪＬコマンドをプリンタに送信することになる。しかし、プリンタ２Ａ、２Ｂは複数回ＵＳＴＡＴＵＳ ＯＮコマンドを送られた場合にあっても、同一の状態を維持するので影響はない。

また、ＩＮＦＯコマンドにより、その都度、状態変化がないにもかかわらずその時点の状態を返すことになるが、ＰＣ１におけるＵＩ上には、同一のステータスが表示され続けるのみであり、これも問題はない。

［パワーマネージメント関連メッセージ処理］
次に、図１１に示すパワーマネージメント関連メッセージ処理について説明する。この処理は、ＰＣ１の電源管理機能により、通常の作動状態（第１状態）から省電力状態（第２状態）へ移行したとの条件、もしくは、省電力状態（第２状態）から通常の作動状態（第１状態）に復帰したとの条件が成立した場合に実行される処理となる。

パワーマネージメント関連メッセージ処理を開始すると、パーサ１３は、まず、ＯＳ側からのメッセージが、サスペンド・ハイバネート（すなわち、第２状態）に入るか否かの問い合わせメッセージかどうかを判断する（Ｓ１００１；Ｓ１００１の処理を実行する手段が、本発明でいう第２検知手段の一例に相当）。

ここで、サスペンド・ハイバネートに入るか否かの問い合わせメッセージである場合（Ｓ１００１：ＹＥＳ）、パーサ１３は、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令を送信する（Ｓ１００３；Ｓ１００３の処理を実行する手段が、本発明でいう第２送信手段の一例に相当）。

この“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令は、Ｓ９１９の処理（図１０参照）で送信された“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令を取り消す命令である。
“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令は、スプーラシステム２１を介して送信される。“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令の送信後、この命令が完全にプリンタ２Ａ、２Ｂに対して送信されたか否かが判定される（Ｓ１００４；Ｓ１００４の処理を実行する手段が、本発明でいう第２判定手段の一例に相当）。

この判定処理では、スプーラシステム２１にデータが残っているか否かで判定が行われる。“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令の送信が完了していなければ（Ｓ１００４：ＮＯ）、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令の送信が開始されてから１秒経過したか否か判定される（Ｓ１００５）。

１秒経過していなければ（Ｓ１００５：ＮＯ）、Ｓ１００４の処理へ戻る。１秒経過していれば（Ｓ１００５：ＹＥＳ）、あるいは“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令の送信が完了してれば（Ｓ１００４：ＹＥＳ）、サスペンド・ハイバネートに入るか否かの問い合わせメッセージに対して「ＯＫ」、すなわち、サスペンド・ハイバネートに入る許可をする応答を行い（Ｓ１００６；Ｓ１００６の処理を実行する手段が、本発明でいう応答手段の一例に相当）、本メッセージ処理を終了する。

上記のように、完全に“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令の送信が終了せず、１秒経過してしまう場合であってもサスペンド・ハイバネートに入る許可をする応答がなされる。これは、サスペンド・ハイバネートに入るか否かの問い合わせメッセージに対する長時間の非応答により、サスペンド・ハイバネートに入るのを妨げるのを防止するためである。

逆に、送信完了まで最大１秒間待った後にサスペンド・ハイバネートに入る許可をする応答がなされるので、正常に“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令を送信できるのに送信不完全のままＰＣ１がサスペンド・ハイバネートに入ってしまうのを防止することができる。

なお、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”命令を受けたプリンタ２Ａ、２Ｂは、ステータス情報の提供処理を終了することになる。
また、サスペンド・ハイバネートに入るか否かの問い合わせメッセージではなかった場合（Ｓ１００１：ＮＯ）、パーサ１３は、サスペンド・ハイバネート問い合わせキャンセルのメッセージか否かを判断する（Ｓ１００７）。

ここで、サスペンド・ハイバネート問い合わせキャンセルのメッセージである場合（Ｓ１００７：ＹＥＳ）、パーサ１３は、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”を送信し（Ｓ１００８）、図１１に示す処理を終了する。この場合、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”を受けたプリンタ２Ａ、２Ｂは、ステータス情報の提供処理を開始することになる。

また、サスペンド・ハイバネート問い合わせキャンセルのメッセージではなかった場合（Ｓ１００７：ＮＯ）、パーサ１３は、サスペンド・ハイバネートに入ることを通知するメッセージか否かを判断する（Ｓ１００９）。

ここで、サスペンド・ハイバネートに入ることを通知するメッセージである場合（Ｓ１００９：ＹＥＳ）、そのまま図１１に示す処理を終了する。
また、サスペンド・ハイバネートに入ることを通知するメッセージではなかった場合（Ｓ１００９：ＮＯ）、パーサ１３は、サスペンド・ハイバネートからの復帰メッセージか否かを判断する（Ｓ１０１１；Ｓ１０１１の処理を実行する手段が、本発明でいう第１検知手段の一例に相当）。

ここで、サスペンド・ハイバネートからの復帰メッセージである場合（Ｓ１０１１：ＹＥＳ）、パーサ１３は、プリンタの電源がオンか否かを判断する（Ｓ１０１３；Ｓ１０１３の処理を実行する手段が、本発明でいう第１判定手段の一例に相当）。

Ｓ１０１３の処理において、プリンタの電源がオンであった場合（Ｓ１０１３：ＹＥＳ）、パーサ１３は、プリンタに対してＮＵＬＬデータを送信する（Ｓ１０１５；Ｓ１０１５の処理を実行する手段が、本発明でいう第３送信手段の一例に相当）。このＳ１０１５の処理は、プリンタのスリープ状態を解除するための処理となる。

ここで送信されたＮＵＬＬデータを受けたプリンタ２Ａ、２Ｂがスリープ状態になっていた場合、プリンタ２Ａ、２Ｂは作動を開始するので、スリープ状態は解除されることになる。

そして、パーサ１３は、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”を送信し（Ｓ１０１７；Ｓ１０１７の処理を実行する手段が、本発明でいう第１送信手段の一例に相当）、図１１に示すメッセージ処理を終了する。この場合、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”を受けたプリンタ２Ａ、２Ｂは、ステータス情報の提供処理を開始することになる。

なお、Ｓ１０１３の処理において、プリンタの電源がオンか否かは、判定対象となるプリンタからデバイスＩＤを取得できるか否かによって判断する。これは、プリンタの電源がオンの場合、デバイスＩＤであれば比較的迅速かつ確実に取得できるので、デバイスＩＤを直ちに取得できなければ、プリンタの電源がオフであるとの判断も迅速に実施できるからである。

この際、デバイスＩＤが取得できず電源がプリンタの電源がオフであると判断された場合は、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令は送信されない。このため、スプーラシステム２１からの送信不能によるエラーメッセージがＰＣ１で表示されることはない。

また、この場合、プリンタの電源がオンにされた時点で、前述したＳ９１９の処理（図１０参照）により、“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”命令が送信されるので、その後引き続きステータス情報を取得することができる。

一方、Ｓ１０１３の処理において、プリンタの電源がオンではなかった場合（Ｓ１０１３：ＮＯ）、パーサ１３は、ステータスモニタの終了処理を実施する（Ｓ１０１９；Ｓ１０１９の処理を実行する手段が、本発明でいう制御手段の一例に相当）。このＳ１０１９の処理では、図８に示す処理同様、アンインストールメッセージを送信する処理などが実行される。

［第１状態−第２状態間を移行する場合の具体例］
以上説明したようなパワーマネージメント関連メッセージ処理は、例えば、利用者が所定の操作を行うことにより、ＰＣ１が第１状態（通常の作動状態）から第２状態（省電力状態）へ移行することになった場合に実行される。あるいは、ＰＣ１が第２状態（省電力状態）から第１状態（通常の作動状態）に復帰する場合に実行される。

ただし、パワーマネージメント関連メッセージ処理の中で、処理がどのように分岐するかは、個々の具体的状況によって変わるので、以下、具体的なタイミングチャートを例示しながら、ＰＣ１がどのような挙動を示すのかについて、より具体的に説明する。

なお、以下の説明において使用する図１２〜図１４においては、図示を簡略化するため、ステータスモニタ機能を提供する処理系全体のことを、単にステータスモニタと表記することにする。ただし、このステータスモニタ機能を提供する処理系は、上述のステータスモニタＵＩ１２やパーサ１３等のプロセスによって構成されるものである。

また、図１２〜図１４には、ステータスモニタ以外のソフトウェアとして、アプリケーションＡ、Ｂを例示するが、これらアプリケーションＡ、Ｂも、それぞれ単一のプロセスによって構成されてもよいし、複数のプロセスが協働して機能する処理系であってもよい。

［第１状態から第２状態への移行がキャンセルされる事例］
まず、第１状態から第２状態への移行がキャンセルされる事例について説明する。
ＰＣ１が第１状態にある場合に、利用者が所定の操作を行うことによって第２状態への移行を指示すると、図１２に示すように、ＰＣ１のＯＳは、ＰＣ１上で稼働する全ての処理系に対してメッセージを送信する。

ここでＯＳから送信されるメッセージは、サスペンド・ハイバネートに入るか否かの問い合わせメッセージである。このメッセージは、例えば、アプリケーションＡ、アプリケーションＢ、ステータスモニタ等の処理系へと伝達される。

そして、ステータスモニタの場合であれば、このメッセージの受信を契機として、図１１に示したパワーマネージメント関連メッセージ処理が実行され、上記Ｓ１００１の処理で肯定判断がなされ、Ｓ１００３の処理が実行されることになる。また、Ｓ１００３の処理が実行された場合、プリンタ２Ａ、２Ｂ側では、ステータス情報の提供処理を終了することになる。

ここで、ステータスモニタの場合は、Ｓ１００３の処理を実行した後、スプーラシステム２１によるデータ送信が完了したことを確認するＳ１００４の処理が実行される。その上で、サスペンド・ハイバネートに入ってもよい旨の応答（ＯＫ）をＯＳに返すＳ１００６の処理が実行される。

また、サスペンド・ハイバネートに入っても問題がない他の処理系（例えば、アプリケーションＡ）も、サスペンド・ハイバネートに入ってもよい旨の応答（ＯＫ）をＯＳに返す。

しかし、サスペンド・ハイバネートに入ると問題がある他の処理系（例えば、アプリケーションＢ）が存在することもあり、その場合、そのような処理系は、サスペンド・ハイバネートに入るのを拒否する旨の応答（ＮＧ）をＯＳに返す。

このような場合、ＯＳは、サスペンド・ハイバネートに入るのを拒否する旨の応答（ＮＧ）を返す処理系が存在すれば、サスペンド・ハイバネートへの移行をキャンセルすべきと判断し、再びＰＣ１上で稼働する全ての処理系に対してメッセージを送信する。

ここでＯＳから送信されるメッセージは、サスペンド・ハイバネート問い合わせキャンセルのメッセージである。このメッセージも、上記の通り、例えば、アプリケーションＡ、アプリケーションＢ、ステータスモニタ等の処理系へと伝達される。

そして、ステータスモニタの場合であれば、このメッセージの受信を契機として、図１１に示したパワーマネージメント関連メッセージ処理が実行され、上記Ｓ１００７の処理で肯定判断がなされ、Ｓ１００８の処理が実行されることになる。また、Ｓ１００８の処理が実行された場合、プリンタ２Ａ、２Ｂ側では、ステータス情報の提供処理を開始することになる。

そして、ステータスモニタの場合は、Ｓ１００８の処理を実行した後、サスペンド・ハイバネートへの移行がキャンセルされてもよい旨の応答（ＯＫ）をＯＳに返す。また、サスペンド・ハイバネートへの移行がキャンセルされてもよい他の処理系（例えば、アプリケーションＡ、Ｂ）も、同様の応答（ＯＫ）をＯＳに返す。

その結果、サスペンド・ハイバネートへの移行はキャンセルされたことになり、ＰＣ１は、その後も第１状態のまま作動し続けることになる。
［第１状態から第２状態へ移行する事例］
次に、第１状態から第２状態へ移行する事例について説明する。

ＰＣ１が第１状態にある場合に、利用者が所定の操作を行うことによって第２状態への移行を指示すると、図１３に示すように、ＰＣ１のＯＳは、ＰＣ１上で稼働する全ての処理系に対してメッセージを送信する。

ここでＯＳから送信されるメッセージは、サスペンド・ハイバネートに入るか否かの問い合わせメッセージである。このメッセージは、例えば、アプリケーションＡ、アプリケーションＢ、ステータスモニタ等の処理系へと伝達される。

そして、ステータスモニタの場合であれば、このメッセージの受信を契機として、図１１に示したパワーマネージメント関連メッセージ処理が実行され、上記Ｓ１００１の処理で肯定判断がなされ、Ｓ１００３の処理が実行されることになる。また、Ｓ１００３の処理が実行された場合、プリンタ２Ａ、２Ｂ側では、ステータス情報の提供処理を終了することになる。

ここで、ステータスモニタの場合は、Ｓ１００３の処理を実行した後、スプーラシステム２１によるデータ送信が完了したことを確認するＳ１００４の処理を実行した上で、サスペンド・ハイバネートに入ってもよい旨の応答（ＯＫ）をＯＳに返すＳ１００６の処理を実行する。また、サスペンド・ハイバネートに入っても問題がない他の処理系（例えば、アプリケーションＡ、Ｂ）も、サスペンド・ハイバネートに入ってもよい旨の応答（ＯＫ）をＯＳに返す。

このような場合、ＯＳは、サスペンド・ハイバネートに入るのを拒否する旨の応答（ＮＧ）を返す処理系が存在しないので、サスペンド・ハイバネートへ移行すべきと判断し、再びＰＣ１上で稼働する全ての処理系に対してメッセージを送信する。

ここでＯＳから送信されるメッセージは、サスペンド・ハイバネートに入ることを通知するメッセージである。このメッセージも、上記の通り、例えば、アプリケーションＡ、アプリケーションＢ、ステータスモニタ等の処理系へと伝達される。

そして、ステータスモニタの場合であれば、このメッセージの受信を契機として、図１１に示した処理が実行され、上記Ｓ１００９の処理で肯定判断がなされることになる。
そして、ステータスモニタの場合は、サスペンド・ハイバネートへ入ってもよい旨の応答（ＯＫ）をＯＳに返す。また、サスペンド・ハイバネートへ入ってもよい他の処理系（例えば、アプリケーションＡ、Ｂ）も、同様の応答（ＯＫ）をＯＳに返す。

その結果、ＯＳは、ＰＣ１の各部を制御し、ＰＣ１は、第２状態へ移行することになる。
［第２状態から第１状態へ復帰する事例］
次に、第２状態から第１状態へ復帰する事例について説明する。

ＰＣ１が第２状態にある場合に、利用者が所定の操作を行うことによって第１状態への復帰を指示すると、図１４に示すように、ＰＣ１のＯＳは、復帰前にＰＣ１上で稼働していた全ての処理系の稼働を再開させる。そして、各処理系に対してメッセージを送信する。

ここでＯＳから送信されるメッセージは、サスペンド・ハイバネートからの復帰メッセージである。このメッセージは、例えば、アプリケーションＡ、アプリケーションＢ、ステータスモニタ等の処理系へと伝達される。

そして、ステータスモニタの場合であれば、このメッセージの受信を契機として、図１１に示したパワーマネージメント関連メッセージ処理が実行され、上記Ｓ１０１１の処理で肯定判断がなされ、Ｓ１０１３〜Ｓ１０１９の処理が実行されることになる。また、Ｓ１０１３〜Ｓ１０１９の処理の内、Ｓ１０１７の処理が実行された場合、プリンタ２Ａ、２Ｂ側では、ステータス情報の提供処理を開始することになる。

ここで、ステータスモニタの場合は、Ｓ１０１３〜Ｓ１０１９の処理を実行した後、サスペンド・ハイバネートからの復帰に問題がない旨の応答（ＯＫ）をＯＳに返す。また、サスペンド・ハイバネートからの復帰に問題がない他の処理系（例えば、アプリケーションＡ、Ｂ）も、同様の応答（ＯＫ）をＯＳに返す。その結果、ＰＣ１は、第１状態へ復帰することになる。

［上記実施形態の効果］
上記ステータスモニタ機能を備えたＰＣ１によれば、ＰＣ１が第２状態から第１状態へ復帰した時点で、Ｓ１０１７の処理により、ＰＣ１側からプリンタ２Ａ、２Ｂ側へＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”（開始信号）が送信される。

したがって、仮にＰＣ１が第２状態へ移行している間にプリンタ２Ａ、２Ｂの電源オフ等の要因により、プリンタ２Ａ、２Ｂ側の状態が初期化されていたとしても、プリンタ２Ａ、２Ｂからステータス情報を取得する処理や、そのステータス情報を表示する処理を、何ら問題なく再開することができる。

また、上記ＰＣ１によれば、Ｓ１０１３の処理により、プリンタ２Ａ、２Ｂと通信できることを確認した上で、Ｓ１０１７の処理により、ＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＮ”（開始信号）を送信する。したがって、開始信号を確実にプリンタ２Ａ、２Ｂへ伝送することができる。

また、ＰＣ１において、Ｓ１０１３の処理により、プリンタ２Ａ、２Ｂと通信できないことが判明した場合は、ステータスモニタが不要な状態であると推察されるため、Ｓ１０１９の処理により、ステータスモニタが終了する。したがって、ステータスモニタが終了する分だけＰＣ１の資源を開放することができ、ＰＣ１にかかる負荷を軽減できる。

また、ＰＣ１は、第１の状態から第２の状態へ移行する際に、Ｓ１００３の処理により、プリンタ２Ａ、２Ｂ側でのステータス情報提供処理を終了させる。したがって、プリンタ２Ａ、２Ｂ側では、不要な処理を実施しなくてもよくなり、プリンタ２Ａ、２Ｂにかかる負荷を軽減できる。

また、プリンタ２Ａ、２Ｂに対する終了信号（＝Ｓ１００３の処理によって送信されるＰＪＬコマンド“ＵＳＴＡＴＵＳ ＤＥＶＩＣＥ ＯＦＦ”）は、ＯＳ側から第２状態への移行についての問い合わせがあった段階で、プリンタ２Ａ、２Ｂへ送信される。したがって、ＰＣ１の各部が実際に第１状態から第２状態へ移行する前に、終了信号の送信処理を開始することができる。

また、ＰＣ１は、終了信号がスプーラシステム２１から送出されたのを確認した上で、ＯＳ側からの問い合わせに対し、第２状態への移行を許可する旨の応答を行う。したがって、プリンタ２Ａ、２Ｂに対する終了コマンドの送信を確実に行った後に、第１状態から第２状態へ移行することができる。

また、ＰＣ１は、第２状態から第１状態への復帰に伴い、Ｓ１０１５の処理により、実際の印刷に先立って、プリンタ２Ａ、２Ｂのスリープ状態を解除する。したがって、その後、印刷を行う場合には、直ちにプリンタ２Ａ、２Ｂを利用することができる。

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

例えば、上記実施形態では、プリンタ２Ａ、２Ｂに対し、第１状態から第２状態への移行時に終了信号を送信し、且つ、第２状態から第１状態への復帰時に開始信号を送信する例を挙げたが、これに限らない。

具体的には、例えば、第１状態から第２状態への移行時に終了信号を送信しないものであっても、第２状態から第１状態への復帰時に開始信号を送信する手段さえ備えていれば、第２状態から第１状態への復帰時にはステータス情報が取得できるようになる。したがって、このような構成を採用しても相応の効果がある。

なお、参考までに例を挙げれば、プリンタ２Ａ、２Ｂにかかる負荷を軽減したいだけであれば、第１状態から第２状態への移行時に終了信号を送信する手段だけを備えていても、相応の効果がある。

また、上記実施形態では、第２状態から第１状態への復帰時に、プリンタの電源がオンであることを確認した上で開始信号を送信していたが、プリンタの電源がオフの場合に開始信号を送信しても特段の問題がない場合は、無条件に開始信号を送信してもよい。

具体例を挙げれば、例えば、プリンタ２Ａ、２Ｂ側に開始信号を出力する際、プリンタの電源がオフであっても、その開始信号がプリンタ２Ａ、２Ｂ側に受信されないだけで、特にエラーが発生しないのであれば、無条件に開始信号を送信してもよい。

また、上記実施形態では、第２状態から第１状態への復帰時に、プリンタの電源がオフになっていれば、ステータスモニタを終了するように構成してあったが、これに限らない。例えば、プリンタの電源がオン／オフいずれであるかにかかわらず、ステータスモニタがＰＣ１上に常駐して、次にプリンタの電源がオンになるまで待機または監視を続けるような構成としてもよい。

ステータスモニタ機能を備えたＰＣを含むシステム全体の概略構成図。 プリンタドライバインストール処理のフローチャート。 印刷処理のフローチャート。 ステータスモニタＵＩ処理のフローチャート。 メッセージループ処理のフローチャート。 パーサ処理のフローチャート。 初期化メッセージ処理のフローチャート。 終了メッセージ処理のフローチャート。 デバイス構成変更メッセージ処理のフローチャート。 タイマーメッセージ処理のフローチャート。 パワーマネージメント関連メッセージ処理のフローチャート。 第１状態から第２状態への移行がキャンセルされる事例についてのタイミングチャート。 第１状態から第２状態へ移行する事例についてのタイミングチャート。 第２状態から第１状態へ復帰する事例についてのタイミングチャート。

符号の説明

１・・・パーソナルコンピュータ、２Ａ，２Ｂ・・・プリンタ、１１・・・プリンタドライバＵＩ、１２・・・ステータスモニタＵＩ、１３・・・ステータスデータパーサ、１４・・・ローカルポートアービトレイタ、１５Ａ・・・パラレルプリンタクラスドライバ、１５Ｂ・・・ＵＳＢプリンタクラスドライバ、１６Ａ・・・パラレル物理層、１６Ｂ・・・ＵＳＢ物理層、２１・・・スプーラシステム、２３・・・ＰｎＰマネージャ、２５・・・Ｉ／Ｏマネージャ。

Claims (7)

1. 通常の作動状態である第１状態から当該第１状態よりも電力消費を抑制する状態である第２状態へ移行可能、且つ、前記第２状態から前記第１状態に復帰可能に構成された情報処理装置を、
   前記情報処理装置が前記第２状態から前記第１状態へ復帰したことを検知する第１検知手段と、
   前記第１検知手段によって前記第１状態への復帰を検知した場合に、画像形成装置に対し、当該画像形成装置の状態を示すステータス情報の提供開始を要求するための開始信号を送信する第１送信手段と、
   前記開始信号を受信した前記画像形成装置から前記ステータス情報を取得する取得手段と、
   前記取得手段によって取得された前記ステータス情報に基づいて、前記画像形成装置の状態を表示する表示処理手段
   として機能させることにより、前記画像形成装置の状態を表示するステータスモニタとして機能させることを特徴とするステータスモニタプログラム。
2. 前記情報処理装置を、
   前記画像形成装置と通信可能か通信不能かを判定する第１判定手段
   として機能させ、
   前記第１送信手段を、前記第１判定手段によって通信可能と判定された場合に、前記開始信号を送信する手段として機能させる
   ことを特徴とする請求項１に記載のステータスモニタプログラム。
3. 前記情報処理装置を、
   前記第１判定手段によって通信不能と判定された場合に、前記情報処理装置を前記ステータスモニタとして機能させる処理を終了する制御手段
   として機能させることを特徴とする請求項２に記載のステータスモニタプログラム。
4. 前記情報処理装置を、
   前記第１状態から前記第２状態へ移行することを検知する第２検知手段と、
   前記第２検知手段によって前記第２状態への移行を検知した場合に、前記画像形成装置に対し、前記ステータス情報の提供終了を要求するための終了信号を送信する第２送信手段
   として機能させることを特徴とする請求項１〜請求項３のいずれかに記載のステータスモニタプログラム。
5. 前記情報処理装置は、前記第１状態から前記第２状態へ移行してもよいかどうかの問い合わせを行った後、当該問い合わせに対して前記第２状態への移行を拒否する応答がなかった場合に、前記第１状態から前記第２状態へ移行する旨の通知を行った上で、前記第１状態から前記第２状態へ移行するように構成されており、
   前記第２検知手段を、前記第１状態から前記第２状態へ移行してもよいかどうかの問い合わせを検知する手段
   として機能させることを特徴とする請求項４に記載のステータスモニタプログラム。
6. 前記情報処理装置を、
   前記第２送信手段によって前記終了信号が外部へ送信されたか否かを判定する第２判定手段と、
   前記第２判定手段によって前記終了信号が外部へ送信されたと判定された場合、前記問い合わせに対して前記第２状態への移行を許可する応答を行う応答手段
   として機能させることを特徴とする請求項５に記載のステータスモニタプログラム。
7. 前記情報処理装置を、
   前記第１検知手段によって前記第１状態への復帰を検知した場合に、前記画像形成装置に対し、前記画像形成装置のスリープ状態を解除するための信号を送信する第３送信手段
   として機能させることを特徴とする請求項１〜請求項６のいずれかに記載のステータスモニタプログラム。

Images