(57)【要約】【課題】ＣＵＰＳが動作するＰＣにより、ローカル接続されたプリンタから所定のデータを好適に取得する。【解決手段】ＣＵＰＳが動作するＰＣのプリンタドライバへの入力データが、プリンタの所定のデータを要求する要求指示であれば、所定のデータの要求がプリンタに送信される。この要求に応じて、プリンタドライバは、プリンタからデータを受信し、受信したデータが所定のデータであるか否かを判断する。受信データが所定のデータである場合に、受信データがアプリケーションに送信されるが、受信データが所定のデータでない場合に、プリンタドライバは、所定のデータを受信するまで、繰り返し、プリンタからデータを受信する。これにより、所定のデータを好適に取得することができる。【選択図】図４
2020001298.tif 000002
【特許請求の範囲】
【請求項１】
ローカル接続されたプリンタと通信可能な通信部を備え、ＣＵＰＳが動作する情報処理装置のコンピュータが読み取り可能なプリンタドライバであって、
前記コンピュータを、
所定のアプリケーションからデータを受信する第１受信手段と、
前記第１受信手段により受信されたデータが、前記プリンタで記憶されている所定のデータを要求する要求指示である場合に、前記所定のデータの要求を、前記ＣＵＰＳのバックエンドを介して前記プリンタに送信する第１送信手段と、
前記第１送信手段により前記所定のデータの要求が送信された後に、前記バックエンドを介して前記プリンタからデータを受信する第２受信手段と、
前記第２受信手段によりデータが受信された場合に、当該データが前記所定のデータの要求に対する応答であるか否かを判断する第１判断手段と、
前記第１判断手段により前記所定のデータの要求に対する応答であると判断された場合に、前記第２受信手段により受信されたデータを、前記アプリケーションに送信する第２送信手段と、
して機能させ、
前記第２受信手段は、
前記第１判断手段により前記所定のデータの要求に対する応答であると判断されるまで、繰り返し、前記プリンタからデータを受信することを特徴とするプリンタドライバ。
【請求項２】
前記コンピュータを、
前記第１受信手段により受信されたデータが、前記プリンタでの印刷対象の対象データである場合に、当該対象データを、前記ＣＵＰＳのバックエンドを介して前記プリンタに送信する第３送信手段と、して機能させることを特徴とする請求項１に記載のプリンタドライバ。
【請求項３】
前記プリンタドライバは、
前記情報処理装置において動作する前記アプリケーションと、前記第１受信手段及び前記第２送信手段を実行することを特徴とする請求項１又は請求項２に記載のプリンタドライバ。
【請求項４】
前記通信部は、管理装置と通信可能であり、
前記プリンタドライバは、
前記管理装置と前記プリンタを共有する設定がされており、前記管理装置において動作する前記アプリケーションと、前記第１受信手段及び前記第２送信手段を実行することを特徴とする請求項１又は請求項２に記載のプリンタドライバ。
【請求項５】
前記コンピュータを、
前記第１判断手段により前記所定のデータの要求に対する応答でないと判断された場合に、当該応答でないと判断されたデータと同じデータの要求を、前記バックエンドを介して前記プリンタに送信する第４送信手段として機能させることを特徴とする請求項１乃至４の何れか１項に記載のプリンタドライバ。
【請求項６】
前記第１送信手段は、
前記所定のデータの要求をする第１コマンド であって、当該要求を受信したタイミングでデータの返信を指示する第１コマンドを、前記バックエンドを介して前記プリンタに送信し、
前記第４送信手段は、
前記第１判断手段により前記所定のデータの要求に対する応答でないと判断され、かつ、当該応答でないと判断されたデータが、前記第１コマンドと異なる第２コマンドに対する応答である場合に、当該応答でないと判断されたデータと同じデータを要求する前記第１コマンドを前記プリンタに送信することを特徴とする請求項５に記載のプリンタドライバ。
【請求項７】
前記アプリケーションの動作により前記コンピュータを、
前記第２送信手段により送信されたデータを受信する第３受信手段と、
前記第３受信手段により受信されたデータに、前記所定のデータと異なる相違データがあるか否かを判断する第２判断手段と、
前記第２判断手段により前記相違データがあると判断された場合に、当該相違データと同じデータの要求指示を、前記プリンタドライバに送信する第５送信手段と、
して機能させ、
前記プリンタドライバの動作により前記コンピュータを、
前記第５送信手段により送信された要求指示を受信した場合に、前記相違データと同じデータの要求とともに、受信不要を示す不要情報を、前記バックエンドを介して前記プリンタに送信する第６送信手段として機能させ、
前記第２受信手段は、
前記第６送信手段により前記不要情報とともに送信されたデータの要求に応じて前記プリンタから送信されたデータを受信せず、前記不要情報をともなわずに送信されたデータの要求に応じて前記プリンタから送信されたデータを受信することを特徴とする請求項６に記載のプリンタドライバ。
【請求項８】
ローカル接続されたプリンタと通信可能な通信部と、
コンピュータと
を備え、ＣＵＰＳが動作する情報処理装置であって、
前記コンピュータを、
所定のアプリケーションからデータを受信する第１受信手段と、
前記第１受信手段により受信されたデータが、前記プリンタで記憶されている所定のデータを要求する要求指示である場合に、前記所定のデータの要求を、前記ＣＵＰＳのバックエンドを介して前記プリンタに送信する第１送信手段と、
前記第１送信手段により前記所定のデータの要求が送信された後に、前記バックエンドを介して前記プリンタからデータを受信する第２受信手段と、
前記第２受信手段によりデータが受信された場合に、当該データが前記所定のデータの要求に対する応答であるか否かを判断する第１判断手段と、
前記第１判断手段により前記所定のデータの要求に対する応答であると判断された場合に、前記第２受信手段により受信されたデータを、前記アプリケーションに送信する第２送信手段と、
して機能させ、
前記第２受信手段は、
前記第１判断手段により前記所定のデータの要求に対する応答であると判断されるまで、繰り返し、前記プリンタからデータを受信することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ローカル接続されたプリンタと通信可能な通信部を備え、ＣＵＰＳが動作する情報処理装置のコンピュータが読み取り可能なプリンタドライバ等に関する。
【背景技術】
【０００２】
下記特許文献には、Ｗｉｎｄｏｗｓ（登録商標）の印刷システムが動作する情報処理装置が、その情報処理装置にローカル接続されたプリンタから所定のデータを取得する技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−１２８８９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記特許文献に記載の技術によれば、Ｗｉｎｄｏｗｓの印刷システムが動作する情報処理装置において、ローカル接続されたプリンタから所定のデータを好適に取得することはできるが、ＣＵＰＳが動作する情報処理装置においては、ＣＵＰＳの制約上、ローカル接続されたプリンタから所定のデータを好適に取得することはできない。そこで、ＣＵＰＳが動作する情報処理装置において、ローカル接続されたプリンタから所定のデータを好適に取得することを課題とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、実施例に開示するプリンタドライバは、ローカル接続されたプリンタと通信可能な通信部を備え、ＣＵＰＳが動作する情報処理装置のコンピュータが読み取り可能なプリンタドライバであって、前記コンピュータを、所定のアプリケーションからデータを受信する第１受信手段と、前記第１受信手段により受信されたデータが、前記プリンタで記憶されている所定のデータを要求する要求指示である場合に、前記所定のデータの要求を、前記ＣＵＰＳのバックエンドを介して前記プリンタに送信する第１送信手段と、前記第１送信手段により前記所定のデータの要求が送信された後に、前記バックエンドを介して前記プリンタからデータを受信する第２受信手段と、前記第２受信手段によりデータが受信された場合に、当該データが前記所定のデータの要求に対する応答であるか否かを判断する第１判断手段と、前記第１判断手段により前記所定のデータの要求に対する応答であると判断された場合に、前記第２受信手段により受信されたデータを、前記アプリケーションに送信する第２送信手段と、して機能させ、前記第２受信手段は、前記第１判断手段により前記所定のデータの要求に対する応答であると判断されるまで、繰り返し、前記プリンタからデータを受信することを特徴とする。
【０００６】
上記課題を解決するために、実施例に開示する情報処理装置は、ローカル接続されたプリンタと通信可能な通信部と、コンピュータとを備え、ＣＵＰＳが動作する情報処理装置であって、前記コンピュータを、所定のアプリケーションからデータを受信する第１受信手段と、前記第１受信手段により受信されたデータが、前記プリンタで記憶されている所定のデータを要求する要求指示である場合に、前記所定のデータの要求を、前記ＣＵＰＳのバックエンドを介して前記プリンタに送信する第１送信手段と、前記第１送信手段により前記所定のデータの要求が送信された後に、前記バックエンドを介して前記プリンタからデータを受信する第２受信手段と、前記第２受信手段によりデータが受信された場合に、当該データが前記所定のデータの要求に対する応答であるか否かを判断する第１判断手段と、前記第１判断手段により前記所定のデータの要求に対する応答であると判断された場合に、前記第２受信手段により受信されたデータを、前記アプリケーションに送信する第２送信手段と、して機能させ、前記第２受信手段は、前記第１判断手段により前記所定のデータの要求に対する応答であると判断されるまで、繰り返し、前記プリンタからデータを受信することを特徴とする。
【発明の効果】
【０００７】
実施例に開示する情報処理装置では、ＣＵＰＳが動作しており、プリンタにローカル接続されている。この情報処理装置のプリンタドライバにデータが入力され、その入力されたデータが、プリンタに記憶されている所定のデータを要求する要求指示である場合に、所定のデータの要求がプリンタに送信される。この要求に応じて、プリンタドライバは、プリンタからデータを受信し、受信したデータが所定のデータの要求に対する応答である否かを判断する。そして、受信したデータが所定のデータの要求に対する応答である場合に、その受信したデータがアプリケーションに送信されるが、受信したデータが所定のデータの要求に対する応答でない場合に、プリンタドライバは、所定のデータと判断されるデータを受信するまで、繰り返し、プリンタからデータを受信する。これにより、ＣＵＰＳが動作する情報処理装置において、ローカル接続されたプリンタから所定のデータを好適に取得することが可能となる。
【図面の簡単な説明】
【０００８】
【図１】第１実施形態のプリンタシステム１のブロック図である。
【図２】アプリケーション３０とプリンタドライバ３２とＣＵＰＳ３６のバックエンド６２とプリンタ６０とステータスモニタ６６との関係を概念的に示すブロック図である。
【図３】プリンタシステム１での各種情報の送受信を概念的に示す図である。
【図４】第１実施形態でのプリンタドライバ３２のフローチャートを示す図である。
【図５】第１実施形態でのアプリケーション３０のフローチャートを示す図である。
【図６】第２実施形態でのプリンタドライバ３２のフローチャートを示す図である。
【図７】第２実施形態でのプリンタドライバ３２のフローチャートを示す図である。
【図８】第２実施形態でのアプリケーション３０のフローチャートを示す図である。
【図９】第３実施形態のプリンタシステム７０のブロック図である。
【図１０】第３実施形態でのアプリケーション９０のフローチャートを示す図である。
【発明を実施するための形態】
【０００９】
以下、適宜図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施形態は、本発明の一例にすぎず、本発明の要旨を変更しない範囲で、本発明の実施形態を適宜変更できることは言うまでもない。例えば、後述する各処理の実行順序は、本発明の要旨を変更しない範囲で、適宜変更できる。
【００１０】
＜第１実施形態＞
図１は、本実施形態に係るプリンタシステム１のブロック図である。図１に示すプリンタシステム１は、３台の被管理ＰＣ（情報処理装置の一例）１０ａ，ｂ，ｃ、管理ＰＣ５０、３台のプリンタ６０ａ，ｂ，ｃを備える。被管理ＰＣ１０ａ，ｂ，ｃの各々は、略同じ構成であるため、被管理ＰＣ１０ａを代表して説明し、被管理ＰＣ１０ｂ，ｃに関して、説明を省略するが、被管理ＰＣ１０ａと異なる構成のみ説明する。
【００１１】
被管理ＰＣ１０ａは、ＣＰＵ（コンピュータ及び制御部の一例）１２、メモリ１４、ＬＣＤ１６、入力Ｉ／Ｆ１８、ネットワークＩ／Ｆ２０、ＵＳＢ  Ｉ／Ｆ（通信部の一例）２２を主に備えている。これらの構成要素は、バス２４を介して互いに通信可能とされている。
【００１２】
被管理ＰＣ１０ａは、ネットワークＩ／Ｆ２０及びネットワーク５２を介して、管理ＰＣ５０と通信可能となっている。通信の方式としては、例えば、有線ＬＡＮ、Ｗｉ−Ｆｉ（登録商標）を採用できる。また、被管理ＰＣ１０ａは、ＵＳＢ  Ｉ／Ｆ２２を介して、プリンタ６０ａと通信可能とされている。なお、被管理ＰＣ１０ｂは、プリンタ６０ｂと通信可能とされており、被管理ＰＣ１０ｃは、プリンタ６０ｃと通信可能とされている。被管理ＰＣ１０ａ〜ｃとプリンタ６０ａ〜ｃの通信プロトコルとしては、例えば、Ｐｒｉｎｔｅｒ  Ｊｏｂ  Ｌａｎｇｕａｇｅ（登録商標、以下、ＰＪＬと称す）が用いられる。
【００１３】
ＣＰＵ１２は、メモリ１４内のアプリケーション３０，プリンタドライバ３２，Ｌｉｎｕｘ（登録商標）３４，ＣＵＰＳ（登録商標）３６に従って処理を実行する。アプリケーション３０は、被管理ＰＣ１０ａと通信可能なプリンタ６０ａの保守情報を取得するためのプログラムである。プリンタドライバ３２は、プリンタ６０ａのドライバであり、例えば、印刷用の画像データをプリンタ６０ａに送信するプログラムである。Ｌｉｎｕｘ３４は、アプリケーション３０，プリンタドライバ３２に利用される基本的な機能を提供するプログラムであり、被管理ＰＣ１０ａのオペレーティングシステムである。ＣＵＰＳ３６は、Ｌｉｎｕｘ３４で用いられる印刷システムである。なお、以下の説明では、プリンタドライバ３２等を実行するＣＰＵ１２のことを、単にプログラム名でも記載する場合がある。例えば、「プリンタドライバ３２が」という記載は、「プリンタドライバ３２を実行するＣＰＵ１２が」ということを意味する場合がある。
【００１４】
また、図２に、アプリケーション３０，プリンタドライバ３２，ＣＵＰＳ３６，プリンタ６０ａの関係を概念的に示す。アプリケーション３０は、プリンタドライバ３２との間で情報の送受信を行い、プリンタドライバ３２は、ＣＵＰＳ３６のバックエンド６２を介して、プリンタ６０ａとの間で情報の送受信を行う。また、被管理ＰＣ１０ａはプリンタ６０ａの作動状態を監視するためのステータスモニタ６６を有しており、そのステータスモニタ６６は、ＣＵＰＳ３６のバックエンド６２を介して、プリンタ６０ａとの間で情報の送受信を行う。つまり、ステータスモニタ６６は、プリンタ６０ａの作動状態を示す情報（以下、「ステータス情報」と記載する）を、バックエンド６２を介して、プリンタ６０ａから受信する。
【００１５】
また、メモリ１４は、図１に示すように、データ記憶領域３８を備える。データ記憶領域３８は、プリンタドライバ３２等の実行に必要なデータなどを記憶する領域である。なお、メモリ１４は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ＨＤＤ、被管理ＰＣ１０に着脱されるＵＳＢメモリ等の可搬記憶媒体、ＣＰＵ１２が備えるバッファなどが組み合わされて構成されている。
【００１６】
なお、メモリ１４は、コンピュータが読み取り可能なストレージ媒体であってもよい。コンピュータが読み取り可能なストレージ媒体とは、ｎｏｎ−ｔｒａｎｓｉｔｏｒｙな媒体である。ｎｏｎ−ｔｒａｎｓｉｔｏｒｙな媒体には、上記の例の他に、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の記録媒体も含まれる。また、ｎｏｎ−ｔｒａｎｓｉｔｏｒｙな媒体は、ｔａｎｇｉｂｌｅな媒体でもある。一方、インターネット上のサーバなどからダウンロードされるプログラムを搬送する電気信号は、コンピュータが読み取り可能な媒体の一種であるコンピュータが読み取り可能な信号媒体であるが、ｎｏｎ−ｔｒａｎｓｉｔｏｒｙなコンピュータが読み取り可能なストレージ媒体には含まれない。
【００１７】
また、ＬＣＤ１６は、ＰＣ１０の各種情報を表示する。なお、本願のディスプレイは、液晶ディスプレイに限らず、有機ＥＬディスプレイ等の他の表示方式のディスプレイでも良い。入力Ｉ／Ｆ１８は、キーボード、マウス等を含み、ユーザ操作を入力するためのインタフェースである。なお、入力Ｉ／Ｆ１８は、キーボード等に限らず、ＬＣＤ１６の表示画面に重畳された膜状のタッチセンサでも良い。
【００１８】
プリンタシステム１では、上述した構成により、被管理ＰＣ１０ａ，ｂ，ｃの各々が、自身と通信可能なプリンタ６０ａ，ｂ，ｃから保守情報を受信し、受信した保守情報をメモリ１４に記憶する。管理ＰＣ５０は、所定のタイミングでメモリ１４に記憶された保守情報を読み出して取得する。これにより、管理ＰＣ５０において、プリンタ６０ａ，ｂ，ｃの保守情報が一元的に管理されている。以下に、プリンタシステム１での処理について詳しく説明する。
【００１９】
なお、本明細書では、基本的に、プログラムに記述された命令に従ったＣＰＵ１２の処理を示す。すなわち、以下の説明における「判断」、「抽出」、「選択」、「算出」、「決定」、「特定」、「取得」、「受付」、「制御」「設定」等の処理は、ＣＰＵ１２の処理を表している。ＣＰＵ１２による処理は、ＯＳ，つまり、Ｌｉｎｕｘ３４を介したハードウェア制御も含む。なお、「取得」は要求を必須とはしない概念で用いる。すなわち、ＣＰＵ１２が要求することなくデータを受信するという処理も、「ＣＰＵ１２がデータを取得する」という概念に含まれる。また、本明細書中の「データ」とは、コンピュータに読取可能なビット列で表される。そして、実質的な意味内容が同じでフォーマットが異なるデータは、同一のデータとして扱われるものとする。本明細書中の「情報」についても同様である。また、「命令」「応答」「要求」等の処理は、「命令」「応答」「要求」等を示す情報を通信することにより行われる。また、「命令」「応答」「要求」等の文言を、「命令」「応答」「要求」等を示す情報そのものという意味で記載してもよい。また、ＣＰＵによる、情報Ａは事柄Ｂであることを示しているか否かを判断する処理を、「情報Ａから、事柄Ｂであるか否かを判断する」のように概念的に記載することがある。ＣＰＵによる、情報Ａが事柄Ｂであることを示しているか、事柄Ｃであるかを示しているかを判断する処理を、「情報Ａから、事柄Ｂであるか事柄Ｃであるかを判断する」のように概念的に記載することがある。
【００２０】
プリンタ６０ａ，ｂ，ｃでは、保守情報として、プリンタ６０ａ，ｂ，ｃでのトナーなどの消耗品の残量，印刷枚数等を示す情報が記憶されている。そして、被管理ＰＣ１０ａ，ｂ，ｃのプリンタドライバ３２が、プリンタ６０ａ，ｂ，ｃから保守情報を取得するが、被管理ＰＣ１０ａ，ｂ，ｃでは、オペレーティングシステムとして、Ｌｉｎｕｘ３４が採用されているため、従来のＷｉｎｄｏｗｓと同等の手法では、保守情報を適切にプリンタ６０ａ，ｂ，ｃから取得することができない。これは、Ｌｉｎｕｘ３４では、印刷システムとして、ＣＵＰＳ３６が用いられており、プリンタドライバ３２と、ＣＵＰＳ３６のバックエンド６２とは、別プロセスであり、かつ、バックエンド６２は印刷ジョブ毎に起動されて印刷ジョブ終了時にプロセスが終了するため、各印刷ジョブ処理の終了後に、プリンタドライバ３２が、プリンタ６０ａ，ｂ，ｃから保守情報を取得できない。一方、オペレーティングシステムとしてＷｉｎｄｏｗｓ（登録商標）等が採用されているＰＣは、単一のプロセスで保守情報を取得するため、各処理の終了後であっても、適切に保守情報を取得することできる。そこで、オペレーティングシステムとしてＬｉｎｕｘ３４が採用されている被管理ＰＣ１０ａ，ｂ，ｃでは、プリンタドライバ３２が、保守情報を取得するまで処理を完了させず、適切に保守情報を取得する。
【００２１】
具体的には、被管理ＰＣ１０ａでは、アプリケーション３０が、所定の保守情報（以下、「所定保守情報」と記載する）（所定のデータの一例）の要求指示を、要リードバックでプリンタドライバ３２に送信する。なお、要リードバックは、後に詳しく説明するが、プリンタドライバ３２がプリンタ６０ａから情報を読み込み、取得することを許容するためのものであり、プリンタドライバ３２は、要リードバックを含む要求指示を受信すると、プリンタ６０ａへの要求指示に応じて、プリンタ６０ａから情報を受信する。一方、要リードバックに反するものとして、リードバック不要がある。リードバック不要も、後に詳しく説明するが、プリンタドライバ３２がプリンタ６０ａから情報を読み込み、取得することを禁止するためのものであり、プリンタドライバ３２は、リードバック不要を含む要求指示を受信すると、プリンタ６０ａへの要求指示に応じてプリンタ６０ａから情報を受信しない。
【００２２】
なお、アプリケーション３０は、要リードバックでの所定保守情報の要求指示を、所定の周期毎に、プリンタドライバ３２に送信する。そして、プリンタドライバ３２は、所定保守情報の要求指示を受信すると、所定保守情報の要求をプリンタ６０ａに、バックエンド６２を介して送信する。具体的には、例えば、所定保守情報が印刷枚数に関する情報および、トナー残量に関する情報である場合に、「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」と、「＠ＰＪＬ  ＩＮＦＯ  ＴＯＮＮＥＲ」とのコマンドが、所定保守情報の要求に含まれる。
【００２３】
これらのコマンドは、ＰＪＬ言語に基づくＩＮＦＯコマンド（第１コマンドの一例）と呼ばれ、コマンドにより指定された保守情報の送信を指示するコマンドである。つまり、「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」は、印刷枚数に関する情報の送信を指示するＩＮＦＯコマンドであり、「＠ＰＪＬ  ＩＮＦＯ  ＴＯＮＮＥＲ」は、トナー残量に関する情報の送信を指示するＩＮＦＯコマンドである。そして、プリンタ６０ａは、ＩＮＦＯコマンドを受信すると、そのＩＮＦＯコマンドを受信したタイミングで、コマンドにより指定された保守情報、つまり、所定保守情報を、バックエンド６２を介して、プリンタドライバ３２に送信する。これにより、プリンタドライバ３２は、アプリケーション３０からの要求指示に応じた所定保守情報をプリンタ６０ａから取得し、その取得した所定保守情報を、アプリケーション３０に送信する。
【００２４】
なお、プリンタドライバ３２が情報をアプリケーション３０に送信すると、プリンタドライバ３２での処理が完了し、プリンタ６０ａとの情報の送受信が遮断される。そして、プリンタドライバ３２とプリンタ６０ａとの間の情報の送受信の遮断は、新たな処理が再開されるまで継続される。つまり、プリンタドライバ３２は、アプリケーション３０に情報を送信した後に、プリンタ６０ａから情報を受信することができない。これは、上述したように、プリンタドライバ３２と、ＣＵＰＳ３６のバックエンド６２とが、別プロセスであるためである。
【００２５】
このため、プリンタドライバ３２が所定保守情報をプリンタ６０ａから取得し、その所定保守情報をアプリケーション３０に送信していれば問題ないが、プリンタドライバ３２が所定保守情報と異なる情報（以下、「相違情報」と記載する）（相違データの一例）をプリンタ６０ａから取得し、その相違情報をアプリケーション３０に送信した場合に、プリンタドライバ３２が所定保守情報を取得することなく、プリンタドライバ３２とプリンタ６０ａとの間の情報の送受信が遮断される。つまり、プリンタドライバ３２は、アプリケーション３０からの要求指示に応じた所定保守情報をプリンタ６０ａから取得することができない。
【００２６】
なお、相違情報の一例としては、ステータス情報がある。詳しくは、上述したように、被管理ＰＣ１０ａでは、ステータスモニタ６６により、プリンタ６０ａの作動状態が監視されている。このため、ステータスモニタ６６は、プリンタ６０ａの作動状態を示す情報、つまり、ステータス情報をプリンタ６０ａから受信するべく、ステータス情報の要求をプリンタ６０ａに送信している。この要求には、「＠ＰＪＬ  ＵＳＴＡＴＵＳ  ＤＥＶＩＣＥ  ＯＮ」のコマンドが含まれる。このコマンドは、ＰＪＬ言語に基づくＵＳＴＡＴＵＳコマンド（第２コマンドの一例）と呼ばれ、プリンタでの作動状態が変化したタイミングでのステータス情報の送信を指示するコマンドである。なお、ステータス情報としては、「ＰＲＩＮＴ」，「ＲＥＡＤＹ」，「ＳＬＥＥＰ」がある。「ＰＲＩＮＴ」は印刷中であることを示し、「ＲＥＡＤＹ」は待機中であることを示し、「ＳＬＥＥＰ」はスリープ中であることを示している。このため、プリンタ６０ａは、ＵＳＴＡＴＵＳコマンドを含む要求を受信すると、作動状態が変化する毎にステータス情報を、バックエンド６２を介して、ステータスモニタ６６に送信する。つまり、例えば、プリンタ６０ａにおいて、印刷処理が完了した後に、プリンタ６０ａが待機状態になると、ステータス情報として「ＲＥＡＤＹ」をステータスモニタ６６に送信する。このように、被管理ＰＣ１０ａでは、ステータスモニタ６６によって、プリンタ６０ａの作動状態が監視されている。
【００２７】
ただし、プリンタ６０ａからバックエンド６２を介して送信されたステータス情報が、ステータスモニタ６６により受信されず、プリンタドライバ３２を介してアプリケーション３０により受信される場合がある。このような場合に、ステータスモニタ６６からのＵＳＴＡＴＵＳコマンドに対する応答としてプリンタ６０ａが出力したステータス情報が、相違情報となる。そして、プリンタドライバ３２が所定保守情報の要求をプリンタ６０ａに送信した後に、ステータス情報を受信し、そのステータス情報をアプリケーション３０に送信すると、上述したように、所定保守情報を取得することができなくなる。
【００２８】
そこで、プリンタドライバ３２は、所定保守情報の要求指示をアプリケーション３０から受信すると、その要求指示を解析し、所定保守情報を認識するためのキーワードを抽出する。例えば、所定保守情報が印刷枚数に関する情報である場合には、キーワードとして、「ＰＡＧＥ」を抽出する。そして、プリンタドライバ３２は、アプリケーション３０からの要求指示に応じて、ＩＮＦＯコマンドを含む要求をプリンタ６０ａに送信する。つまり、プリンタドライバ３２は、キーワードとして「ＰＡＧＥ」を抽出した場合に、「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」をプリンタ６０ａに送信する。
【００２９】
そして、プリンタドライバ３２は情報を受信すると、受信した情報を分析し、その情報にキーワードが含まれているか否かを判断する。例えば、プリンタドライバ３２がプリンタ６０ａから印刷枚数に関する情報を受信した場合には、その情報をＰＪＬの文法に従って解析し、「ＰＡＧＥ」のキーワードは含まれており、かつ、そのキーワードがアプリケーション３０から受信した「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」に対する応答であると判断する。そして、プリンタドライバ３２は、受信した情報、つまり、印刷枚数に関する情報を、アプリケーション３０に送信する。これにより、プリンタドライバ３２は、プリンタ６０ａから情報を受信できなくなるが、印刷枚数に関する情報、つまり、ＩＮＦＯコマンドに応じた所定保守情報を受信しているため問題ない。
【００３０】
一方、プリンタドライバ３２がプリンタ６０ａからステータス情報を受信した場合には、ＰＪＬの文法に従った解析により、「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」に対する応答という形での「ＰＡＧＥ」のキーワードは含まれておらず、受信した情報にキーワードが含まれていないと判断する。この際、プリンタドライバ３２は、受信した情報、つまり、ステータス情報を、アプリケーション３０に送信しない。このように、受信した情報が、アプリケーション３０の要求に応じた情報でない場合に、アプリケーション３０は、受信した情報をアプリケーション３０に送信しない。これにより、プリンタドライバ３２は、継続してプリンタ６０ａから情報を受信することができる。
【００３１】
そして、プリンタドライバ３２がステータス情報を受信した後に、印刷枚数に関する情報を受信した場合には、その情報に、「＠ＰＪＬ  ＩＮＦＯ  ＰＡＧＥ」に対する応答という形で「ＰＡＧＥ」のキーワードは含まれているため、受信した情報にキーワードが含まれていると判断する。このため、プリンタドライバ３２は、印刷枚数に関する情報を、アプリケーション３０に送信する。なお、プリンタドライバ３２は、印刷枚数に関する情報だけでなく、受信した全ての情報を、アプリケーション３０に送信する。つまり、プリンタドライバ３２は、印刷枚数に関する情報の前に、ステータス情報を受信している場合に、印刷枚数に関する情報とステータス情報とを含む全ての情報（以下、「要求含有情報」と記載する）をアプリケーション３０に送信する。
【００３２】
このように、プリンタドライバ３２は、アプリケーション３０からの要求に応じた情報、つまり、所定保守情報を受信するまで、受信した情報をアプリケーション３０に送信せず、所定保守情報を受信した場合に、受信した情報をアプリケーション３０に送信する。これにより、所定保守情報を確実にプリンタ６０ａから取得することができる。
【００３３】
なお、相違情報の一例として、ステータス情報について説明したが、保守情報が相違情報となる場合もある。つまり、例えば、アプリケーション３０からの要求に応じた情報が、印刷枚数に関する情報であるが、プリンタ６０ａから、トナー残量に関する情報が送信される場合がある。これは、アプリケーション３０と異なるプログラムから、トナー残量に関する情報が要求されている場合があるためである。そして、このような場合に、プリンタドライバ３２は、トナー残量に関する情報を受信すると、その情報に、「ＰＡＧＥ」のキーワードが含まれているか否かを判断する。この際、トナー残量に関する情報に、「ＰＡＧＥ」のキーワードは含まれていないため、受信した情報にキーワードが含まれていないと判断される。つまり、トナー残量に関する情報は、相違情報と判断され、プリンタドライバ３２は、そのトナー残量に関する情報を送信せず、プリンタ６０ａからの情報の受信を継続して行う。これにより、プリンタドライバ３２は、保守情報を受信しても、その保守情報がアプリケーション３０からの要求に応じた情報、つまり、所定保守情報でない場合に、所定保守情報を受信するまで、継続してプリンタ６０ａから情報を受信することができる。
【００３４】
なお、プリンタドライバ３２は、プリンタ６０ａのドライバであるため、プリンタドライバ３２には、上述したプリンタ６０ａの保守情報だけでなく、プリンタ６０ａで印刷される一般的な印刷対象の画像データ（以下、「対象データ」と記載する）も入力される。このため、プリンタドライバ３２に何らかの情報が入力されると、プリンタドライバ３２は、入力された情報が対象データであるか否かを判断する。なお、入力された情報が対象データであるか否かの判断は、入力された情報のデータ形式が、例えば、ＰＳ形式，ＰＤＦ形式，ＪＰＥＧ形式などの画像データ形式であるか否かに基づいて行われる。そして、入力された情報が対象データであると判断された場合に、プリンタドライバ３２は、対象データを、プリンタ６０ａで印刷可能な印刷用画像データに変換し、変換した印刷用画像データをプリンタ６０ａに送信する。
【００３５】
一方、入力された情報が対象データでないと判断された場合に、プリンタドライバ３２は、入力された情報がプリンタ６０ａへの要求指示であるか否かを判断する。この際、プリンタドライバ３２は、入力された情報が、ＩＮＦＯコマンド等のようにＰＪＬ言語に基づく情報であるか否かを判断する。そして、入力された情報がＰＪＬ言語に基づく情報である場合に、プリンタドライバ３２は、入力された情報がプリンタ６０ａへの要求指示であると判断する。このように、入力された情報がプリンタ６０ａへの要求指示であると判断されると、プリンタドライバ３２は、上述した手順に従って、ＩＮＦＯコマンドを含む所定保守情報の要求をプリンタ６０ａに送信する。
【００３６】
なお、入力された情報がＰＪＬ言語に基づく情報でない場合に、プリンタドライバ３２は、入力された情報がプリンタ６０ａへの要求指示でないと判断する。そして、その入力された情報は、対象データでもなく、要求指示でもないイリーガルデータとして取り扱われ、エラー処理が実行される。
【００３７】
また、アプリケーション３０は、プリンタドライバ３２から送信された要求含有情報を受信すると、要求含有情報に含まれる所定保守情報を抽出し、その所定保守情報を記憶する。ただし、要求含有情報には、上述したように、所定保守情報だけでなく、ステータス情報が含まれている場合がある。ステータス情報は、本来、ステータスモニタ６６で用いられる情報であるため、アプリケーション３０がステータス情報を受信すると、ステータスモニタ６６が、プリンタ６０ａの作動状態を適切に監視できない虞がある。
【００３８】
具体的には、図３に示すように、ステータスモニタ６６がＵＳＴＡＴＵＳコマンドを出力している場合（Ｓ１０）に、プリンタ６０ａは、作動状態が印刷中から待機中に変化したタイミングで、ステータス情報として、「ＲＥＡＤＹ」を送信する。この際、プリンタドライバ３２が、そのステータス情報を受信すると（Ｓ１２）、ステータスモニタ６６は、「ＲＥＡＤＹ」のステータス情報を受信できず、プリンタ６０ａの作動状態を待機中に変更することができない。また、プリンタ６０ａは、作動状態が待機中からスリープに変化したタイミングで、ステータス情報として、「ＳＬＥＥＰ」を送信する。この際、プリンタドライバ３２が、そのステータス情報を受信すると（Ｓ１４）、ステータスモニタ６６は、「ＳＬＥＥＰ」のステータス情報を受信できず、プリンタ６０ａの作動状態をスリープに変更することができない。このため、図３に示されているように、実際のプリンタのステータスは、印刷中から待機中に変化し、さらに、スリープに変化しているにも拘らず、「再送処理がない場合のステータスモニタの表示」のように、ステータスモニタ６６では、プリンタ６０ａの作動状態が印刷中から変化していないと判断される。
【００３９】
そこで、アプリケーション３０は、要求含有情報をプリンタドライバ３２から受信すると、その要求含有情報にステータス情報が含まれているか否かを判断し、ステータス情報が含まれている場合に、ステータス情報の再送処理を行う。詳しくは、要求含有情報には、所定保守情報を含む複数の情報が含まれている場合があるため、アプリケーション３０は、要求含有情報をＰＪＬの文法に従って解析し、１単位のデータ（以下、「単位データ」と記載する）を抽出する。そして、単位データが所定保守情報であるか否かを判断する。この際、単位データが所定保守情報である場合に、アプリケーション３０は、その単位データ、つまり、所定保守情報をデータ記憶領域３８に記憶する。
【００４０】
また、単位データが所定保守情報でない場合に、アプリケーション３０は、その単位データがステータス情報であるか否かを判断する。この際、アプリケーション３０は、単位データがＵＳＴＡＴＵＳコマンドに対する応答であるか否かを判断する。単位データがステータス情報であり、例えば、「ＲＥＡＤＹ」などである場合には、ＵＳＴＡＴＵＳコマンドに対する応答であることを示す情報が単位データに含まれているため、単位データがステータス情報であると判断される。そして、単位データがステータス情報であると判断されると、アプリケーション３０は、単位データと同じデータのＩＮＦＯコマンドでの要求指示をプリンタドライバ３２に送信する。つまり、単位データが、「ＲＥＡＤＹ」のステータス情報である場合に、アプリケーション３０は、ＩＮＦＯコマンドでのステータス情報の要求指示をプリンタドライバ３２に送信する。なお、アプリケーション３０は、その要求指示をリードバック不要でプリンタドライバ３２に送信する。
【００４１】
プリンタドライバ３２は、ＩＮＦＯコマンドでのステータス情報の要求指示をリードバック不要で受信すると、ステータス情報のＩＮＦＯコマンドを含む要求を、プリンタ６０ａに送信する（Ｓ１６）。これにより、プリンタ６０ａは、その要求を受信したタイミングでステータス情報を送信する。ただし、この要求は、リードバック不要で送信されているため、上述したように、プリンタドライバ３２は、その要求に応じた返信は受信しない。このため、そのステータス情報は、ステータスモニタ６６により受信される（Ｓ１７）。
【００４２】
なお、プリンタドライバ３２が、ＩＮＦＯコマンドを含む所定保守情報の要求をプリンタ６０ａに送信している場合（Ｓ１８）は、所定保守情報を受信するまで、プリンタドライバ３２とプリンタ６０ａとの通信は遮断されない。このため、プリンタ６０ａは、プリンタドライバ３２が所定保守情報を受信した後に（Ｓ２０）、ステータス情報を送信し、そのステータス情報が、ステータスモニタ６６により受信される。なお、ステータス情報が送信される際に、プリンタ６０ａの作動状態はスリープになっているため、プリンタ６０ａはステータス情報として、「ＳＬＥＥＰ」を送信し、ステータスモニタ６６は、ステータス情報として、「ＳＬＥＥＰ」を受信する。
【００４３】
また、図３では、プリンタドライバ３２は、「ＲＥＡＤＹ」を受信した後に、「ＳＬＥＥＰ」も受信しており、アプリケーション３０に送信される要求含有情報に「ＲＥＡＤＹ」だけでなく、「ＳＬＥＥＰ」も含まれている。このため、アプリケーション３０は、ＩＮＦＯコマンドでのステータス情報の要求指示をプリンタドライバ３２に送信した後に、再度、ＩＮＦＯコマンドでのステータス情報の要求指示をリードバック不要でプリンタドライバ３２に送信する。そして、プリンタドライバ３２は、ＩＮＦＯコマンドでのステータス情報の要求指示を受信すると、再度、ステータス情報のＩＮＦＯコマンドを含む要求を、プリンタ６０ａに送信する（Ｓ２２）。これにより、プリンタ６０ａは、その要求を受信したタイミングでステータス情報を送信し、そのステータス情報を、ステータスモニタ６６が受信する（Ｓ２４）。このため、「再送処理がある場合のステータスモニタの表示」のように、ステータスモニタ６６が、ステータス情報を受信した後に、プリンタ６０ａの作動状態が印刷中からスリープに変更される。これにより、ステータスモニタ６６において、実際のプリンタの作動状態に近い状態で、プリンタの作動状態を監視することができる。
【００４４】
また、要求含有情報には、上述したように、相違情報として、ステータス情報だけでなく、所定保守情報と異なる保守情報が含まれる場合もある。このような所定保守情報と異なる保守情報は、アプリケーション３０と異なるプログラムに送信されるべき情報であるため、要求含有情報に所定保守情報と異なる保守情報が含まれる場合も、要求含有情報にステータス情報が含まれる場合と同様に、再送処理が実行される。
【００４５】
つまり、単位データが、所定保守情報でなく、ステータス情報でもない場合に、アプリケーション３０は、単位データが保守情報であるか否かを判断する。この際、アプリケーション３０は、単位データがＩＮＦＯコマンドに対する応答であるか否かを判断する。単位データが保守情報であり、例えば、トナー残量に関する情報である場合には、ＩＮＦＯコマンドに対する応答であることを示す情報が単位データに含まれている。このため、単位データが保守情報であると判断される。そして、単位データが保守情報であると判断されると、アプリケーション３０は、単位データと同じデータのＩＮＦＯコマンドでの要求指示をプリンタドライバ３２に送信する。つまり、単位データがトナー残量に関する情報である場合に、アプリケーション３０は、ＩＮＦＯコマンドでのトナー残量に関する情報の要求指示をリードバック不要でプリンタドライバ３２に送信する。
【００４６】
プリンタドライバ３２は、ＩＮＦＯコマンドでのトナー残量に関する情報の要求指示をリードバック不要で受信すると、トナー残量に関する情報のＩＮＦＯコマンドを含む要求を、プリンタ６０ａに送信する。これにより、プリンタ６０ａは、その要求を受信したタイミングでトナー残量に関する情報を送信する。なお、この要求は、リードバック不要で送信されているため、プリンタドライバ３２は、その要求に応じた返信は受信せず、そのトナー残量に関する情報は、その情報の要求を送信したプログラムにより受信される。これにより、そのプログラムが、必要とする保守情報を取得することができる。
【００４７】
このように、アプリケーション３０の作動により、要求含有情報に含まれる所定保守情報のみがデータ記憶領域３８に記憶され、要求含有情報に含まれる所定保守情報以外の情報、つまり、相違情報は、プリンタ６０ａにリードバック不要で再要求される。そして、データ記憶領域３８に記憶された所定保守情報は、管理ＰＣ５０からの要求に応じて、管理ＰＣ５０に送信される。つまり、管理ＰＣ５０は、所定の周期で、被管理ＰＣ１０ａ，ｂ，ｃの各々に、所定保守情報の要求を送信する。そして、被管理ＰＣ１０ａ，ｂ，ｃの各々は、管理ＰＣ５０からの要求を受信すると、データ記憶領域３８に記憶されている所定保守情報を管理ＰＣ５０に送信する。管理ＰＣ５０は、所定保守情報を受信すると、送信元の被管理ＰＣと、受信した所定保守情報とを管理付けて記憶する。これにより、管理ＰＣ５０において、被管理ＰＣ１０ａ，ｂ，ｃの各々の所定保守情報が管理される。
【００４８】
上述したプリンタドライバ３２による処理は、被管理ＰＣ１０のＣＰＵ１２においてプリンタドライバ３２が実行されることによって行われる。以下に、ＣＰＵ１２でプリンタドライバ３２が実行される際のフローを、図４を用いて説明する。なお、図４に示すフローは、プリンタドライバ３２が起動されたことをきっかけに開始される。
【００４９】
まず、プリンタドライバ３２は、起動されると、入力されたデータが対象データであるか否かを判断する（Ｓ１００）。そして、入力されたデータが対象データである場合（Ｓ１００：ＹＥＳ）に、プリンタドライバ３２は、対象データに基づいて印刷用画像データを作成し、プリンタ６０に送信する（Ｓ１０２）。これにより、本フローが終了する。
【００５０】
また、入力されたデータが対象データでない場合（Ｓ１００：ＮＯ）に、プリンタドライバ３２は、入力されたデータが要求指示であるか否かを判断する（Ｓ１０４）。そして、入力されたデータが要求指示でない場合（Ｓ１０４：ＮＯ）に、プリンタドライバ３２は、エラー処理を実行する（Ｓ１０６）。これにより、本フローが終了する。
【００５１】
一方、入力されたデータが要求指示である場合（Ｓ１０４：ＹＥＳ）に、プリンタドライバ３２は、入力されたデータを解析し、所定保守情報を認識するためのキーワードを抽出する（Ｓ１０８）。次に、プリンタドライバ３２は、要求指示に応じた要求をＩＮＦＯコマンドでプリンタ６０に送信する（Ｓ１１０）。そして、プリンタドライバ３２は、送信した要求指示が要リードバックで送信されたものであるか否かを判断する（Ｓ１１２）。この際、要求指示が要リードバックで送信されたものでない場合（Ｓ１１２：ＮＯ）、つまり、要求指示がリードバック不要で送信されたものである場合に、本フローが終了する。
【００５２】
一方、要求指示が要リードバックで送信されたものである場合（Ｓ１１２：ＹＥＳ）に、プリンタドライバ３２は、プリンタ６０からデータを受信する（Ｓ１１４）。続いて、プリンタドライバ３２は、受信したデータを解析し（Ｓ１１６）、受信したデータに、Ｓ１０８で抽出したキーワードが含まれているか否かを判断する（Ｓ１１８）。この際、受信したデータにキーワードが含まれていない場合（Ｓ１１８：ＮＯ）に、Ｓ１１４に戻る。一方、受信したデータにキーワードが含まれている場合（Ｓ１１８：ＹＥＳ）に、プリンタドライバ３２は、要求含有情報をアプリケーション３０に送信する（Ｓ１２０）。これにより、本フローが終了する。
【００５３】
また、上述したアプリケーション３０による処理は、被管理ＰＣ１０のＣＰＵ１２においてアプリケーション３０が実行されることによって行われる。以下に、ＣＰＵ１２でアプリケーション３０が実行される際のフローを、図５を用いて説明する。なお、図５に示すフローは、アプリケーション３０が起動されたことをきっかけに開始される。
【００５４】
まず、アプリケーション３０は、起動されると、所定のタイミングで、所定保守情報の要求指示を要リードバックでプリンタドライバ３２に送信する（Ｓ１３０）。次に、アプリケーション３０は、プリンタドライバ３２から要求含有情報を受信したか否かを判断する（Ｓ１３２）。この際、プリンタドライバ３２から要求含有情報を受信していない場合（Ｓ１３２：ＮＯ）に、Ｓ１３２の処理が繰り返される。一方、プリンタドライバ３２から要求含有情報を受信している場合（Ｓ１３２：ＹＥＳ）に、アプリケーション３０は、要求含有情報から１単位のデータ、つまり、単位データを抽出する（Ｓ１３４）。
【００５５】
アプリケーション３０は、単位データを抽出すると、その単位データが所定保守情報であるか否かを判断する（Ｓ１３６）。この際、単位データが所定保守情報である場合（Ｓ１３６：ＹＥＳ）に、アプリケーション３０は、単位データ、つまり、所定保守情報をデータ記憶領域３８に記憶する（Ｓ１３８）。次に、アプリケーション３０は、要求含有情報に含まれる全単位のデータに対する処理を完了したか否かを判断する（Ｓ１４０）。そして、要求含有情報に含まれる全単位のデータに対する処理が実行されていない場合（Ｓ１４０：ＮＯ）に、Ｓ１３４に戻り、次の単位データの処理が行われる。一方、要求含有情報に含まれる全単位のデータに対する処理が実行されている場合（Ｓ１４０：ＹＥＳ）に、本フローが終了する。
【００５６】
また、Ｓ１３６で単位データが所定保守情報でない場合（Ｓ１３６：ＮＯ）に、アプリケーション３０は、単位データがＩＮＦＯコマンドに対する応答であるか否かを判断する（Ｓ１４２）。この際、単位データがＩＮＦＯコマンドに対する応答である場合（Ｓ１４２：ＹＥＳ）に、アプリケーション３０は、単位データと同じデータのＩＮＦＯコマンドでの要求指示をリードバック不要でプリンタドライバ３２に送信する（Ｓ１４４）。そして、アプリケーション３０は、Ｓ１４０以降の処理を実行する。
【００５７】
また、Ｓ１４２で単位データがＩＮＦＯコマンドに対する応答でない場合（Ｓ１４２：ＮＯ）に、アプリケーション３０は、単位データがＵＳＴＡＴＵＳコマンドに対する応答であるか否かを判断する（Ｓ１４６）。この際、単位データがＵＳＴＡＴＵＳコマンドに対する応答である場合（Ｓ１４６：ＹＥＳ）に、アプリケーション３０は、単位データと同じデータのＩＮＦＯコマンドでの要求指示をリードバック不要でプリンタドライバ３２に送信する（Ｓ１４８）。そして、アプリケーション３０は、Ｓ１４０以降の処理を実行する。また、Ｓ１４６で単位データがＵＳＴＡＴＵＳコマンドに対する応答でない場合（Ｓ１４６：ＮＯ）に、アプリケーション３０は、Ｓ１４０以降の処理を実行する。なお、Ｓ１３８にて記憶された保守情報は、既知の方式により管理ＰＣ５０により読み取られる。管理ＰＣ５０は被管理ＰＣ１０から読み取った保守情報を基に各プリンタ６０ａ，ｂ，ｃを管理する。
【００５８】
＜第２実施形態＞
第１実施形態の被管理ＰＣ１０では、再送処理がアプリケーション３０により実行されているが、第２実施形態の被管理ＰＣ１０では、再送処理がプリンタドライバ３２により実行される。第２実施形態でのプリンタドライバ３２による処理は、再送処理が実行されることを除いて、第１実施形態でのプリンタドライバ３２による処理と略同じであるため、説明を省略する。ただし、第２実施形態でのプリンタドライバ３２は、再送処理において、相違情報の再送付の要求をプリンタ６０に送信するため、相違情報をアプリケーション３０に送信する必要が無い。このため、第２実施形態でのプリンタドライバ３２は、要求含有情報でなく、所定保守情報のみをアプリケーション３０に送信する。また、プリンタドライバ３２は、自身の判断により相違情報の再送付の要求をプリンタ６０に送信するため、自身の判断により相違情報の再受信を禁止できる。このため、第２実施形態でのプリンタドライバ３２は、要リードバック及びリードバック不要に関する処理を実行しない。つまり、第１実施形態において、アプリケーション３０は、所定保守情報の要求指示を要リードバックで送信し、相違情報の再送付の要求指示をリードバック不要で送信しているが、第２実施形態において、プリンタドライバ３２は、所定保守情報の要求および、相違情報の再送付の要求を、要リードバックとリードバック不要との何れにも指定せず、送信する。また、本実施例においては、アプリケーション３０は要求指示の入力データとして、ＰＪＬの生データを送信する。これは、本実施形態ではリードバック要否情報を送る必要がないため、入力情報とプリンタに送信する情報とを等価とすることができるからである。なお、アプリケーション３０は、要求含有情報でなく、所定保守情報のみを受信するため、所定保守情報を受信すると、その所定保守情報をデータ記憶領域３８に記憶する。
【００５９】
第２実施形態でのプリンタドライバ３２による処理を、図６に示すフローを用いて説明する。本フローのＳ１６０〜Ｓ１６８，Ｓ１７２〜Ｓ１７４の処理は、図４のＳ１００〜Ｓ１０８，Ｓ１１４，Ｓ１１６の処理と同じであるため、Ｓ１６０〜Ｓ１６８，Ｓ１７２〜Ｓ１７４の処理の説明は省略する。Ｓ１７０については、入力データをそのまま送信する処理に置き換わる。そして、Ｓ１７４においてデータが解析される。次に、プリンタドライバ３２は、受信したデータに、Ｓ１６８で抽出したキーワードが含まれているか否かを判断する（Ｓ１７７）。この際、受信したデータにキーワードが含まれている場合（Ｓ１７７：ＹＥＳ）に、所定保守情報をアプリケーション３０に送信する（Ｓ１７８）。一方、Ｓ１７７で受信したデータにキーワードが含まれていない場合（Ｓ１７７：ＮＯ）に再送処理実行サブルーチンが実行される（Ｓ１７６）。
【００６０】
再送処理実行サブルーチンでは、図７に示すように、プリンタドライバ３２は、受信データがＩＮＦＯコマンドに対する応答であるか否かを判断する（Ｓ１９２）。この際、受信データがＩＮＦＯコマンドに対する応答である場合（Ｓ１９２：ＹＥＳ）に、プリンタドライバ３２は、受信データと同じデータのＩＮＦＯコマンドを含む要求をプリンタ６０に送信する（Ｓ１９４）。そして、再送処理実行サブルーチンが終了し、Ｓ１７２に戻る。
【００６１】
また、Ｓ１９２で受信データがＩＮＦＯコマンドに対する応答でない場合（Ｓ１９２：ＮＯ）に、プリンタドライバ３２は、受信データがＵＳＴＡＴＵＳコマンドに対する応答であるか否かを判断する（Ｓ１９６）。この際、受信データがＵＳＴＡＴＵＳコマンドに対する応答である場合（Ｓ１９６：ＹＥＳ）に、プリンタドライバ３２は、受信データと同じデータのＩＮＦＯコマンドを含む要求をプリンタ６０に送信する（Ｓ１９８）。そして、再送処理実行サブルーチンが終了し、Ｓ１７２に戻る。また、Ｓ１９６で受信データがＵＳＴＡＴＵＳコマンドに対する応答でない場合（Ｓ１９６：ＮＯ）にも、再送処理実行サブルーチンが終了し、Ｓ１７２に戻る。
【００６２】
また、第２実施形態でのアプリケーション３０による処理を、図８に示すフローを用いて説明する。本フローでは、アプリケーション３０が、所定保守情報の要求指示を示すＰＪＬコマンドをプリンタドライバ３２に送信する（Ｓ２００）。次に、アプリケーション３０は、プリンタドライバ３２から所定保守情報を受信したか否かを判断する（Ｓ２０２）。この際、プリンタドライバ３２から所定保守情報を受信していない場合（Ｓ２０２：ＮＯ）に、Ｓ２０２の処理が繰り返される。一方、プリンタドライバ３２から所定保守情報を受信している場合（Ｓ２０２：ＹＥＳ）に、アプリケーション３０は、受信した所定保守情報をデータ記憶領域３８に記憶する（Ｓ２０４）。これにより、本フローが終了する。なお、Ｓ２０４で記憶された情報は管理ＰＣ５０により読み取られ、消耗品などの管理に使用される。
【００６３】
＜第３実施形態＞
第１実施形態及び第２実施形態では、アプリケーション３０が被管理ＰＣ１０にインストールされており、そのアプリケーション３０からの要求指示に応じて、プリンタドライバ３２が所定保守情報の要求をプリンタ６０に送信しているが、図９に示すように、第３実施形態のプリンタシステム７０では、管理ＰＣ（管理装置の一例）８０に、アプリケーション９０がインストールされており、そのアプリケーション９０からの要求指示に応じて、プリンタドライバ３２が所定保守情報の要求をプリンタ６０に送信する。なお、プリンタドライバ３２は、管理ＰＣ８０とプリンタ６０を共有する設定がされている。このため、管理ＰＣ８０にインストールされているアプリケーション９０からの指示に応じて、プリンタドライバ３２は作動することが可能とされている。
【００６４】
第３実施形態でのプリンタドライバ３２による処理は、所定保守情報の要求指示の送信元と所定保守情報の送信先とがアプリケーション９０であることを除いて、第２実施形態でのプリンタドライバ３２による処理と同じであるため、説明を省略する。
【００６５】
また、管理ＰＣ８０のアプリケーション９０は、所定の周期で、被管理ＰＣ１０ａ，ｂ，ｃの各々に、所定保守情報の要求を送信する。そして、被管理ＰＣ１０ａ，ｂ，ｃの各々のプリンタドライバ３２は、アプリケーション９０からの要求を受信すると、データ記憶領域３８に記憶されている所定保守情報をアプリケーション９０に送信する。アプリケーション９０は、所定保守情報を受信すると、送信元の被管理ＰＣと、受信した所定保守情報とを管理付けて記憶する。このように、管理ＰＣ８０にインストールされたアプリケーション９０からの要求指示に応じて、被管理ＰＣ１０のプリンタドライバ３２がプリンタ６０から所定保守情報を取得してもよい。
【００６６】
第３実施形態でのアプリケーション９０による処理を、図１０に示すフローを用いて説明する。本フローでは、アプリケーション９０が、被管理ＰＣ１０ａ，ｂ，ｃのうちの何れかを選択する（Ｓ２１０）。次に、アプリケーション９０は、選択された被管理ＰＣ１０と通信可能なプリンタのうちの何れかを選択する（Ｓ２１２）。そして、コマンド送信サブルーチンが実行される（Ｓ２１４）。コマンド送信サブルーチンは、図８に示すフローと同じであるため、図示および説明を省略する。
【００６７】
次に、コマンド送信サブルーチンが終了すると、アプリケーション９０は、Ｓ２１０で選択された被管理ＰＣ１０と通信可能な全てのプリンタに対する処理が完了したか否かを判断する（Ｓ２１６）。この際、選択された被管理ＰＣ１０と通信可能な全てのプリンタに対する処理が完了していない場合（Ｓ２１６：ＮＯ）に、Ｓ２１２に戻る。一方、選択された被管理ＰＣ１０と通信可能な全てのプリンタに対する処理が完了している場合（Ｓ２１６：ＹＥＳ）に、アプリケーション９０は、全ての被管理ＰＣ１０ａ，ｂ，ｃに対する処理が完了したか否かを判断する（Ｓ２１８）。この際、全ての被管理ＰＣ１０ａ，ｂ，ｃに対する処理が完了していない場合（Ｓ２１８：ＮＯ）に、Ｓ２１０に戻る。一方、全ての被管理ＰＣ１０ａ，ｂ，ｃに対する処理が完了している場合（Ｓ２１８：ＹＥＳ）に、本フローが終了する。
【００６８】
第３実施形態でのプリンタドライバ３２による処理では、図６に示すフローと同じフローが実行されるため、第３実施形態でのプリンタドライバ３２による処理のフローの図示および説明を省略する。ただし、第３実施形態でのプリンタドライバ３２による処理では、図６のＳ１７８において、所定保守情報が管理ＰＣ８０のアプリケーション９０に送信される。
【００６９】
なお、Ｓ１００，Ｓ１６０を実行するＣＰＵ１２は、第１受信手段及び第１判断手段の一例である。Ｓ１０２，Ｓ１６２を実行するＣＰＵ１２は、第１送信手段の一例である。Ｓ１０４，Ｓ１６４を実行するＣＰＵ１２は、第１判断手段の一例である。Ｓ１１０，Ｓ１７０を実行するＣＰＵ１２は、第２送信手段及び第６送信手段の一例である。Ｓ１１４，Ｓ１７２を実行するＣＰＵ１２は、第２受信手段の一例である。Ｓ１１８，Ｓ１９０を実行するＣＰＵ１２は、第２判断手段の一例である。Ｓ１２０，Ｓ１７８を実行するＣＰＵ１２は、第３送信手段の一例である。Ｓ１３２実行するＣＰＵ１２は、第３受信手段の一例である。Ｓ１４２及びＳ１４６を実行するＣＰＵ１２は、第３判断手段の一例である。Ｓ１４４及びＳ１４８を実行するＣＰＵ１２は、第５送信手段の一例である。Ｓ１９４及びＳ１９８を実行するＣＰＵ１２は、第４送信手段の一例である。
【００７０】
なお、本発明は、上記実施形態に限定されるものではなく、当業者の知識に基づいて種々の変更、改良を施した種々の態様で実施することが可能である。具体的には、例えば、上記実施形態では、各種情報の要求にＩＮＦＯコマンド，ＵＳＴＡＴＵＳコマンドが含まれているが、これらのコマンドに限定されず、種々のコマンドを採用することが可能である。
【００７１】
また、上記実施形態では、被管理ＰＣ１０とプリンタ６０とはＵＳＢ  Ｉ／Ｆ２２により接続されているが、被管理ＰＣ１０とプリンタ６０との接続はローカル接続であれば、Ｅｔｈｅｒｎｅｔ，ＲＳ２３２，Ｗｉ−Ｆｉ，Ｂｌｕｅｔｏｏｔｈ（登録商標）等を採用することが可能である。
【００７２】
また、上記実施形態では、オペレーティングシステムとしてＬｉｎｕｘ３４が採用されているが、印刷システムとしてＣＵＰＳ３６を用いることが可能なオペレーティングシステムであれば、種々のオペレーティングシステムを採用することが可能である。
【００７３】
また、上記実施形態では、プリンタドライバ３２が、入力データが対象データであるか否かを判断し（図４、Ｓ１００）、入力データが対象データである場合に印刷用データを作成してプリンタに送信している（Ｓ１０２）。しかしながら、プリンタドライバ３２と異なるプリンタドライバを用意し、その異なるプリンタドライバに対象データから印刷用データを作成してプリンタに送信する処理を実行させる構成とすれば、プリンタドライバ３２の処理として、Ｓ１００及びＳ１０２の処理を省略することが可能である。
【００７４】
また、上記実施形態では、ＣＰＵ１２によって図４乃至図８，図１０に示す処理が実行される例を説明したが、これら処理は、ＣＰＵ１２に限らず、ＡＳＩＣや他の論理集積回路により実行されてもよいし、これら処理が、ＣＰＵ等やＡＳＩＣ、他の論理集積回路が協働することにより実行されてもよい。
【符号の説明】
【００７５】
１０：被管理ＰＣ、１２：ＣＰＵ、２２：ＵＳＢ  Ｉ／Ｆ、３０：アプリケーション、３２：プリンタドライバ、３６：ＣＵＰＳ、６０：プリンタ、８０：管理ＰＣ、９０：アプリケーション
【図１】
2020001298.tif 000003
【図２】
2020001298.tif 000004
【図３】
2020001298.tif 000005
【図４】
2020001298.tif 000006
【図５】
2020001298.tif 000007
【図６】
2020001298.tif 000008
【図７】
2020001298.tif 000009
【図８】
2020001298.tif 000010
【図９】
2020001298.tif 000011
【図１０】
2020001298.tif 000012