JP2004334079A

JP2004334079A - 情報収集装置、情報収集方法

Info

Publication number: JP2004334079A
Application number: JP2003132833A
Authority: JP
Inventors: Nobuyuki Kojima; 信之小嶋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2003-05-12
Filing date: 2003-05-12
Publication date: 2004-11-25

Abstract

【課題】各色の記録材に応じた印刷枚数を通知することで、センタ側管理サーバで高精度のトナーＬＯＷ発生タイミングを推測することが可能となり、効率的な在庫管理および顧客への対応も十分余裕を持って行うことが可能となる。
【解決手段】第１の記録材の残量が所定量になった場合、モノクロ印刷枚数とカラー印刷枚数と含む総印刷枚数を通知し、第２の記録材が所定量になった場合、カラー印刷枚数を通知する通知手段を有する情報収集装置。
【選択図】図７

Description

【０００１】
【発明の属する技術分野】
本発明は、情報収集装置および情報収集方法に関する。
【０００２】
【従来の技術】
顧客先のネットワーク環境に拠点側管理サーバを設置して、同じネットワークに接続されたコピー機、複合機の状態を監視し、収集した情報をセンタ側管理サーバに通知して、概デバイスを統合管理するシステムにおいて、概拠点側管理サーバはデバイスの使用トナーの残量が少なくなったことを検知すると、センタ側管理サーバにエラーとして通知する。センタ側管理サーバで、トナー残量が少なくなったエラーが通知されたら、トナーカートリッジを顧客先に送付したり、サービスマンを派遣したりすることで、概デバイスがトナー切れになる前に、交換用カートリッジを用意し、継続して利用できるようにする手段を講じることができる。
【０００３】
さらに、精度を上げてトナーＬＯＷになる時期を早い時期から検知することが可能であれば、より効率的な在庫管理が可能となる。
【０００４】
一般に、コピー機や複合機は、使用するトナーの量を正確に計測できる機能、あるいはトナーの残量を計測できる機能を持っておらず、トナーの量が少なくなったというエラー（トナーＬＯＷ）や、トナーが完全になくなったというエラー（トナーＯＵＴ）が発生した時にのみ、トナーの量を検知することができる。そこで、トナー残量の絶対量の代わりとして、トナーカートリッジが、コピー機や複合機が通常使用でどの程度の印刷枚数まで可能であるかその寿命をデータとして持ち、その印刷枚数によりトナーの残量を推測している。
【０００５】
また、特開平１１−３５３１４５号公報には、各エージェント装置は、第１の周期毎に、ＬＡＮ経由で接続されている各ネットワークプリンタから、その状態を示すステータス情報φ１を獲得する。各エージェント装置は、ネットワークプリンタからステータス情報φ１を獲得する毎に、獲得したステータス情報φ１を、ステータスログデータファイルに上書する。各エージェント装置は、第１の周期よりも長い第２の周期毎に、ステータスログデータファイルに格納されている全てのステータス情報φ１を、電子メールであるステータスメールφ２に変換し、メールサーバ１９へ送信する。一方、コンソール装置は、独自の周期で、メールサーバにアクセスし、ステータスメールφ２を読み出すことが開示されている。
【０００６】
【発明が解決しようとする課題】
実際にはユーザの使用環境、使用手段により一枚あたりでのトナーの消費量は異なるので、単純な印刷枚数からだけでは、精度の高い残量推定はできない。しかし、個別のデバイス、ユーザごとにトナーの残量が少なくなったエラーが発生したときの印刷枚数を統計していけば、トナー使用に関する傾向が推察することができる。しかしながらこの場合であっても単純な総印刷枚数だけでは統計処理するに足るデータとしては不足である。なぜなら、カラー印刷であれば、ＣＭＹＫいずれのトナーも消費されるが、モノクロ印刷においてはカラートナー（ＣＭＹ）が消費されることはない。あるいは大判用紙の印刷であれば、トナー消費量は通常版とは異なることは明白である。
【０００７】
よって、上記課題を解決するために、本発明の目的は、状況に適した情報を提供することにある。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明の情報収集装置は、第１の記録材の残量が所定量になった場合、モノクロ印刷枚数とカラー印刷枚数と含む総印刷枚数を通知し、第２の記録材が所定量になった場合、カラー印刷枚数を通知する通知手段を有することを特徴とする。
【０００９】
【発明の実施の形態】
図１は、本実施形態におけるシステム全体図を示すものである。拠点側サーバ（２）とセンタ側サーバ（６）は、インターネット（８）を介して、特定のプロトコル（１０）で接続されている。不正アクセスを防ぐためと、ファイアウォールを越すために、一般的なプロトコル（ＳＭＴＰ）や認証も設ける。
【００１０】
センタ側管理サーバ（７）と情報収集装置として機能する拠点側管理サーバ（１）は、上記のサーバ（６）および（７）を介して通信可能となっている。
【００１１】
なお、拠点側サーバ（２）と拠点側管理サーバ（１）は複数の装置（別体）になっているが、ひとつの装置（一体）でもよい。また、センタ側サーバ（６）とセンタ側管理サーバ（７）は複数の装置（別体）になっているが、ひとつの装置（一体）でもよい。
【００１２】
図１中には、拠点側管理サーバが１つしか示されていないが、実施には、複数の拠点側管理サーバと、それら複数の拠点側管理サーバを一元的に管理するセンタ側管理サーバが回線を介し通信可能とされている。そのため、センタ側管理サーバ（２）にはデータベース（１１）が設置され、大量のデータが管理されている。
【００１３】
また、図１中の（３）、（４）、（５）はデバイスを示すものであり、デバイスとしては画像形成装置としてのプリンタ（電子写真方式及びインクジェット方式を含む）や、スキャナーや、ファクシミリや、プリンタ及びファクシミリ機能が統合的に設けられたデジタル複合機や、パーソナルコンピュータや、プリントサーバなどが挙げられる。尚、画像形成装置につていは後述にて詳しく説明することとする。拠点側管理サーバ（１）は、（３）〜（５）の機器の状態や部品の消耗度を示す部品カウンタやトナー残量や印刷回数等の情報を収集する。
【００１４】
図２は、図１に示す拠点側管理サーバ（１）のハードウェアブロック構成図である。
【００１５】
本体２１は一般的なパーソナルコンピュータであり、各種プログラムを実行するＣＰＵ、ＲＡＭ、後述する処理にかかわるプログラム等を記憶するＲＯＭ、ＨＤ（ハードディスク）と、入力装置としてマウス２３およびキーボード２４が接続された入力インタフェース、モニタに出力するためのビデオ装置およびネットワークに接続するＬＡＮアダプタで構成される。出力装置としてモニタ２５が本装置のビデオ装置に接続される。本装置は、ＬＡＮアダプタを介してネットワーク２２に接続され、同じくネットワーク２２に接続されているルータやネットワークプリンタと通信することが可能になっている。
【００１６】
図３は拠点側管理サーバ１によるデバイス障害監視処理プログラムを示すフローチャートである。拠点側管理サーバ１から拠点側サーバ２或いはセンタ側サーバ６或いはセンタ側管理サーバ７（以下ホストと称する）に対する情報送信は上記ＳＭＴＰで行い、情報受信はＰＯＰ（ＰｏｓｔＯｆｆｉｃｅＰｒｏｔｏｃｏｌ）により行う場合について説明する。
【００１７】
図３の障害情報確認プログラムは、拠点側管理サーバ１は監視対象のデバイスの障害情報を確認する。また、障害情報確認プログラムは、監視対象のデバイスそれぞれに関し、ステップＳ３０３〜ステップＳ３０７の処理を行うことにより、例えば１分間隔で障害情報の確認処理を行っている。先ずステップＳ３０３において、拠点側管理サーバ１はＬＡＮ９を介して監視対象のデバイスに対し障害情報を取得しに行く。次にステップＳ３０４において、上記ステップＳ３０４で障害情報を取得したかどうかを判定し、障害情報を取得したと判断した場合は、ステップＳ３０５に進む。
【００１８】
ステップＳ３０５において、拠点側管理サーバ１はホストに対し、上記ステップＳ３０３において取得した障害情報を送信する。次にステップＳ３０６において、拠点側管理サーバ１はホストからの応答を待つ応答確認プログラムを起動する。一方、ステップＳ３０４において、上記ステップＳ３０３で障害情報を取得しなかったと判断した場合は、ステップＳ３０７に進む。ステップＳ３０７において、拠点側管理サーバ１は１分間隔で障害情報の確認を行うために、１分間待機する。
【００１９】
図３の応答確認プログラムは、拠点側管理サーバ１は上記ステップＳ３０５でホストへ障害情報を送信した後、ステップＳ３０６で起動される。拠点側管理サーバ１から障害情報をホストが受け取った場合、受け取ったことを示す情報をホストから拠点側管理サーバ１宛に電子メール（以下メールと略称）で通知する仕組みとなっている。応答確認プログラムにおいては、拠点側管理サーバ１はステップＳ３０８〜ステップＳ３１０の処理を例えば３０秒間隔で繰り返しながら、最高３０分間ホストからの応答を待ち、その間に応答がなければホストに対し１回のみ障害情報の再送処理を行う。
【００２０】
ステップＳ３０８では、拠点側管理サーバ１は上記３０秒間隔で処理を行うための３０秒待機を行う。次にステップＳ３０９において、拠点側管理サーバ１はホストからのメールを受信し、受信したメールが障害処理に対する応答メールかどうかをチェックする。ステップＳ３１０において、障害処理に対する応答メールであると判断した場合は、本応答確認プログラムの処理を終了する。一方、ステップＳ３１０において、障害処理に対する応答メールでないと判断した場合は、本応答確認プログラムが起動されてから３０分以内であればステップＳ３０８に戻り、本応答確認プログラムが起動されてから３０分を超えた場合はステップＳ３１１に進む。
【００２１】
ステップＳ３１１において、拠点側管理サーバ１はホストに対する障害情報の送信回数を判断し、既にホストに障害情報の再送を行っていた場合、再送は１回のみ行うことになっているので、本応答確認プログラムを終了する。一方、ステップＳ３１１において、まだ１回もホストに障害情報を再送していない場合、ステップＳ３１２において、拠点側管理サーバ１は障害情報をホストへ再送する。
【００２２】
図４は拠点側管理サーバ１がデバイス３〜５やパーソナルコンピュータのカウンタ情報を収集するカウンタ情報取得、送信処理プログラムを示すフローチャートである。本実施形態でのカウンタ情報とは、デバイス３〜５やパーソナルコンピュータの上記メンテナンス情報の一部或いは全てを含む情報であり、本フローチャートに示すカウンタ情報取得処理は各デバイスのそれぞれに対して実行される。
【００２３】
図４のカウンタ情報取得プログラムは、拠点側管理サーバ１はカウンタ情報を取得するカウンタ情報取得プログラムを実行し、監視対象のデバイスそれぞれに関し、ステップＳ４０３〜ステップＳ４０５の処理を例えば６０分間隔で行うことによりホストからのカウンタ情報の取得要求に備えている。先ずステップＳ４０３において、拠点側管理サーバ１はデバイスからカウンタ情報を取得する。次にステップＳ４０４において、拠点側管理サーバ１は上記ステップＳ４０３でデバイスから取得したカウンタ情報を、ホストからのカウンタ情報要求に備えフラッシュＲＯＭ２０４に保存する。ここで、デバイスから取得するカウンタ情報のデータ形式とホストへ送信するカウンタ情報のデータ形式が異なる場合には、このカウンタ情報の保存の時点でデータ変換しておくことも可能である。また、このデータ変換をホストからカウンタ情報要求があった時点で行う方法もある。次にステップＳ４０５において、拠点側管理サーバ１は６０分後に同様のカウンタ情報の取得処理を行うために、６０分待機する。
【００２４】
図４のカウンタ情報送信プログラムは、拠点側管理サーバ１はホストからのカウンタ情報の要求に対しカウンタ情報を送るために起動される。ホストは拠点側管理サーバ１に対してカウンタ情報要求コマンドを含むメールを送信することで、カウンタ情報を要求する。本カウンタ情報送信プログラムは、例えば３分間隔でホストからのメールをチェックし、カウンタ情報の要求に備える。先ずステップＳ４０６において、拠点側管理サーバ１はホストからのカウンタ情報の要求の有無をチェックする。ステップＳ４０７において、カウンタ情報の要求なしと判断した場合は、ステップＳ４１１へ進む。ステップＳ４０７において、カウンタ情報の要求ありと判断した場合は、ステップＳ４０８に進む。
【００２５】
ステップＳ４０８においては、拠点側管理サーバ１は上記カウンタ情報取得プログラムによりカウンタ情報を保存しているかどうかを判断する。カウンタ情報が保存されている場合は、ステップＳ４０９において、拠点側管理サーバ１は保存してあるカウンタ情報をホストへ送信する。本処理が実行されることにより拠点側管理サーバ１からホストに送信されたカウンタ情報は、上記で説明したようにセンタ側クライアントＰＣ７において共有され、例えばオペレータにより参照することが可能となっている。ステップＳ４１０では、拠点側管理サーバ１は例えば３分間隔でホストからのカウンタ情報の要求をチェックするため３分待機する。一方、カウンタ情報が保存されていない場合は、Ｓ４１２で拠点側管理サーバ１はカウンタ情報が未収集である旨をホストへ通知する。
【００２６】
＜画像形成装置のブロック図＞
次に、図５は画像形成装置全体の制御を司るコントローラの構成を示すブロック図である。
【００２７】
コントローラは、図５に示すように、ＣＰＵ回路部（５０７）を有し、５０７は、ＣＰＵ（図示せず）、ＲＡＭ（５０８）、ＲＯＭ（５０９）、Ｈａｒｄｄｉｓｋ（５１０）が接続され、５０９に格納されている制御プログラムにより各ブロック５０２、５０３、５０４、５０５、５０６、５１１、５１２、５１３、５１４、５１５を総括的に制御する。５０８は、制御データを一時的に保持し、また制御に伴う演算処理の作業領域として用いられる。５１０は、制御にプログラムに必要な情報や各ブロック５０２、５０３、５０４、５０５、５０６、５１１、５１２、５１３、５１４、５１５から受信した情報を記憶する。
【００２８】
原稿給送装置制御部（５０２）は、原稿給送装置（図中なし）を５０７からの指示に基づき駆動制御する。イメージリーダ制御部（５０３）は、スキャナユニット（図中なし）、イメージセンサ（図中なし）などに対する駆動制御を行い、イメージセンサから出力されたアナログ画像信号を画像信号制御部（５０４）に転送する。
【００２９】
５０４は、アナログ画像信号をデジタル信号に変換した後に各処理を施し、このデジタル信号をビデオ信号に変換してプリンタ制御部（５０５）に出力する。外部Ｉ／Ｆ（５０６）はＬＡＮインターフェイスを介してコンピュータ（５０１）から入力されたデジタル画像信号に各種処理を施し、このデジタル画像信号をビデオ信号に変換して５０５に出力する。また、５０６はＬＡＮインターフェイスを介して図示しないデバイス管理装置と通信を行う。５０４による処理動作は、５０７により制御される。５０５は、入力されたビデオ信号に基づき上述の露光制御部（図中なし）を駆動する。
【００３０】
操作部（５１１）は、画像形成に関する各種機能を設定する複数のキー、設定状態を示す情報を表示するための表示部などを有し、各キーの操作に対応するキー信号を５０７に出力するとともに、５０７からの信号に基づき対応する情報を表示部（５１２）に表示する。
【００３１】
ソータ制御部（５１３）、フィニッシャ制御部（５１４）は、５０６を経由したユーザからの入力または５１１からの設定により、５０７からの信号に基づき動作する。状態検知部は、各部位からの状態情報を収集し、異常検知等の判断を行い、結果を５０７に通知する。この通知に従い、５０７は５１２や５０６を経由して、５０１等へ異常を表示する。
【００３２】
図６は、画像形成装置のソフト構成図を示す。
【００３３】
タスクのマネージャー（Ａ−１０１）は複数のタスクを同時に管理するためのものである。紙搬送部タスク群（Ａ−１０２）は原稿および画像形成されるシートの紙搬送を司るタスク群である。シーケンス制御タスク（Ａ−１０３）は、画像形成装置全体の管理を行うタスクである。通信タスク（Ａ−１０４）はデバイス管理装置と通信を行うためのタスクである。また、本実施形態の遠隔管理用データを作成するための管理用データ作成タスク（Ａ−１０５）がある。
【００３４】
画像形成装置では、画像形成ごとに用紙サイズ別、モード別、紙種別、カラー別のカウントを行っている。これらのカウント結果は管理用データ作成タスク（Ａ−１０５）にて行われ、画像形成装置内のメモリ装置に格納されている。
【００３５】
同様にして、ジャム、エラー、アラームなどのステータス情報が所定のデータフォーマットで画像形成装置内のメモリ装置に格納される。
【００３６】
さらに、画像形成装置内の各部ごとに構成消耗部品の交換寿命と、使用度数を表したカウンタ（以下、部品カウンタとする）を持っており、管理用データ作成タスク（Ａ−１０５）の中でカウントされた結果が画像形成装置のメモリ装置に格納される。
【００３７】
画像形成装置の状態監視タスク（Ａ−１０６）は、画像形成装置内の異常（ジャム、エラー、アラーム）を検知したり、予め設定されたデバイスのステータス変化を検知したりする。そして、こうした検知結果を、管理用データ作成タスクＡ−１０５を介して画像形成装置のメモリ装置に格納する。
【００３８】
これらメモリ装置に格納された情報は、所定のタイミングや拠点側管理サーバ１からの情報の要求に応じて拠点側管理サーバ１に通知される。
【００３９】
以上が本発明の基本構成で、図７〜図９を参照して、本発明のトナーカートリッジの使用量を高い精度で検知する手段を説明する。
【００４０】
図８は、トナーＬＯＷエラーが発生したときに、拠点側管理サーバからセンタ側管理サーバに通知されるエラーメッセージの内容である。エラーメッセージは、すべてのエラー種類において同じフォーマットが使用される。転送データトータルサイズは、この通知メッセージの総バイト数で、転送ページ番号には、この通知メッセージがアラートである事を示すＩＤが格納される。通信種類は、この通知メッセージの転送手段を表すＩＤで、通常は電子メールであることを示すＩＤ番号が格納される。アラームレベルは、アラームの深刻度を表す。たとえば、トナーＯＵＴは重障害であるが、トナーＬＯＷはまだデバイスの動作に影響を及ぼすわけではないので軽障害であるとされる。アラームコードおよびアラームサブコードによりアラームの種類を指し示す値が格納される。発生日時は、この障害が発生した、あるいは概拠点側管理サーバが検知した時間が格納される。トータルカウンタには、この障害が発生したときまでに印刷されたカウンタの値が格納されています。位置情報及び位置詳細には、エラー発生個所に関する情報が格納されている。
【００４１】
本発明では、この拠点側サーバからセンタ側管理サーバに通知する通知メッセージの中にあるトータルカウンタ値に格納する値をそのエラーコードによって変更するものである。図９に示したように、エラーコードがＢＬＡＣＫトナーＬＯＷあるいはＢＬＡＣＫトナーＯＵＴであれば、通常サイズの印刷枚数＋大判サイズの印刷枚数に２を乗じた値をトータルカウンタ値としてアラートメッセージに格納して通知する。カラー系のトナーＬＯＷあるいはトナーＯＵＴのエラーであれば、通常サイズのカラー印刷枚数＋大判サイズのカラー印刷枚数に２を乗じた値をトータルカウンタ値としてアラートメッセージに格納して通知する。その他のエラーの場合は、通常サイズの印刷枚数＋大判サイズの印刷枚数をトータルカウンタ値としてアラートメッセージに格納して通知する。
【００４２】
具体的な処理を図７のフローチャートに示す。
【００４３】
本装置では、定期的にデバイスよりステータス情報を収集している。ステータス情報の中にエラー情報が含まれていたら、このフローで説明するシーケンスが呼び出される。最初に、Ｓ７０１において、エラーの種類を解析する。Ｓ７０２で、エラーがカラー系のＴＯＮＥＲ（イエロートナー、マゼンタトナー、シアントナー）のＬＯＷエラーあるいはＯＵＴエラーであるかを判定する。もしカラー系ＴＯＮＥＲのエラーであれば、Ｓ７０７で、トータルカウンタ値として、通常サイズのカラー印刷枚数カウンタ値と、大判のカラー印刷枚数カウンタ値を２倍したものを加えた値を格納する。さらに、Ｓ７０５において、図８に示したフォーマットでエラー情報を作成する。そして、できたデータをＳ７０６でセンタ側管理サーバに送信する。
【００４４】
Ｓ７０２で、エラー種類がカラー系ＴＯＮＥＲでなければ、次にＳ７０３で黒系ＴＯＮＥＲ（ブラックトナー）のＬＯＷあるいはＯＵＴエラーかどうかを判定する。もし黒系トナーのエラーであれば、Ｓ７０８でトータルカウンタ値として、通常サイズの印刷枚数カウンタ値と、大判のイン去る枚数カウンタ値を２倍したものを加えた値を格納する。そしてＳ７０５で、図８に示したフォーマットでエラー情報を作成し、Ｓ７０６でセンタ側管理サーバに送信する。
【００４５】
もし、エラー種類が、カラー系トナーでも黒系トナーに関するものでもない場合は、Ｓ７０４において、トータルカウンタ値として、通常サイズの印刷枚数に大判サイズの印刷枚数を加えた値を格納する。さらに、Ｓ７０５で、図８に説明したフォーマットでエラー情報を作成し、Ｓ７０６において、センタ側管理サーバに送信する。
【００４６】
図１０を用いて、センタ側管理サーバが受け取った情報を処理する仕組みを解説する。グラフは、横軸が日付、縦軸がトータルカウンタ値である。このトータルカウンタ値は、上述した図９の表に則ったカウンタ値である。すなわち、折れ線１０１は、通常サイズの印刷枚数＋大判サイズの印刷枚数に２を乗じた値であり、折れ線１０２は、通常サイズのカラー印刷枚数＋大判サイズのカラー印刷枚数に２を乗じた値である。これらの値は、トナー系のエラー発生時以外にもデバイスの課金情報を求めるパラメータとして、定期的に収集を行っている。Ｙ１、Ｃ１、Ｍ１、Ｋ１は、それぞれＹＥＬＬＯＷ、ＣＹＡＮ、ＭＡＧＥＮＴＡ、ＢＬＡＣＫのトナーで最初にトナーＬＯＷが通知された時点をプロットしたものである。カラー系のＹ１、Ｃ１、Ｍ１で使用される縦軸カウンタ値は図７におけるＳ７０７で計算されたトータルカウンタ値である。また、黒トナーの縦軸カウンタ値は、図７におけるＳ７０８で計算されたトータルカウンタ値である。
【００４７】
同様にＹ２、Ｃ２、Ｍ２、Ｋ２は、二回目にトナーＬＯＷが通知された時点をプロットしている。ちなみにトナーＬＯＷの通知は、交換されるまで同じトナーカートリッジからの通知は受け取らないようになっている。
【００４８】
たとえば、Ｙトナーについて注目すると、Ｙ１からＹ２までの差分がこのデバイスのこの使用環境におけるＹトナーの寿命であると考えられる。したがって、次のトナーＬＯＷ発生カウント値が推定される。それを予測線として１０３で表示している。センタ側では、このデバイスの折れ線１０２が予測線１０３に接近してきたならば、トナーＬＯＷが近々発生するであろう事を推測することができる。
【００４９】
さらにトナーＬＯＷによるプロット数が増えてくれば、各差分の平均値を使って予測カウンタ値を推測するなど、より精度を上げるロジックを使用することが可能になる。
【００５０】
なお、本実施の形態ではトナーカートリッジを用いる画像形成装置の例を説明したが、インクカートリッジを用いる画像形成装置にも適用できる。
【００５１】
【発明の効果】
以上のように本発明により、状況に適した情報を提供することができる。また、各色の記録材に応じた印刷枚数を通知することで、センタ側管理サーバで高精度のトナーＬＯＷ発生タイミングを推測することが可能となり、効率的な在庫管理および顧客への対応も十分余裕を持って行うことが可能となる。
【図面の簡単な説明】
【図１】本実施形態におけるシステム全体図を示す図である。
【図２】図１に示す拠点側管理サーバ（１）のハードウェアブロック構成図である。
【図３】拠点側管理サーバ１によるデバイス障害監視処理プログラムを示すフローチャートを示す図である。
【図４】拠点側管理サーバ１がデバイス３〜５やパーソナルコンピュータのカウンタ情報を収集するカウンタ情報取得、送信処理プログラムに係るフローチャートを示す図である。
【図５】画像形成装置全体の制御を司るコントローラの構成を示すブロック図である。
【図６】画像形成装置のソフト構成図である。
【図７】拠点側管理サーバが実行するプログラムに係るフローチャートを示す図である。
【図８】トナーＬＯＷエラーが発生したときに、拠点側管理サーバからセンタ側管理サーバに通知されるエラーメッセージの内容を示す図である。
【図９】エラーコードによってトータルカウンタ値に入る内容が変わることを示す図である。
【図１０】総印刷枚数、カラー印刷枚数の変化をあらわすグラフを示す図である。

Claims

第１の記録材の残量が所定量になった場合、モノクロ印刷枚数とカラー印刷枚数と含む総印刷枚数を通知し、第２の記録材が所定量になった場合、カラー印刷枚数を通知する通知手段を有することを特徴とする情報収集装置。
第１の記録材はブラックの記録材を含み、第２の記録材はイエローの記録材、マゼンタの記録材、シアンの記録材のいずれかを含むことを特徴とする請求項１記載の情報収集装置。
第１の記録材はブラックトナーを含み、第２の記録材はイエロートナー、マゼンタトナー、シアントナーのいずれかを含むことを特徴とする請求項１記載の情報収集装置。
前記印刷枚数は、用紙サイズを考慮した印刷枚数であることを特徴とする請求項１記載の情報収集装置。
前記所定量は、記録材ロー、記録材なしのいずれかを含むことを特徴とする請求項１記載の情報収集装置。
第１の記録材の残量が所定量になった場合、モノクロ印刷枚数とカラー印刷枚数と含む総印刷枚数を通知し、第２の記録材が所定量になった場合、カラー印刷枚数を通知する通知ステップを有することを特徴とする情報収集方法。
第１の記録材はブラックの記録材を含み、第２の記録材はイエローの記録材、マゼンタの記録材、シアンの記録材のいずれかを含むことを特徴とする請求項６記載の情報収集方法。
第１の記録材はブラックトナーを含み、第２の記録材はイエロートナー、マゼンタトナー、シアントナーのいずれかを含むことを特徴とする請求項６記載の情報収集方法。
前記印刷枚数は、用紙サイズを考慮した印刷枚数であることを特徴とする請求項６記載の情報収集方法。
前記所定量は、記録材ロー、記録材なしのいずれかを含むことを特徴とする請求項６記載の情報収集方法。