処理装置及びその制御方法、並びに制御プログラム
【課題】処理装置自身のパフォーマンスを低下させることなく、外部処理装置から効率的にエラーログの受け付けを行うことができる処理装置を提供する。
【解決手段】親機６０１は、通常のジョブログを定期的に子機６０２〜６０５から取得している。そこで、ジョブログから子機の稼動状況を確認してその稼動率を算出し、稼動率の高い子機は頻繁に使われるため子機のログ用メモリがメモリフルになり易いと判断して、このような子機からのエラーログ格納要求を優先的に受け付ける。逆に、稼動率の低い子機は、ログ用メモリがメモリフルになり難いと判断して、エラーログ格納要求の受け付けの優先度を下げる。このように、管理対象の子機が多数あっても、稼動率の高い機器からのエラーログを優先的に受け付けるようにして、稼動率の低い機器からの受け付けを制限する。
【解決手段】親機６０１は、通常のジョブログを定期的に子機６０２〜６０５から取得している。そこで、ジョブログから子機の稼動状況を確認してその稼動率を算出し、稼動率の高い子機は頻繁に使われるため子機のログ用メモリがメモリフルになり易いと判断して、このような子機からのエラーログ格納要求を優先的に受け付ける。逆に、稼動率の低い子機は、ログ用メモリがメモリフルになり難いと判断して、エラーログ格納要求の受け付けの優先度を下げる。このように、管理対象の子機が多数あっても、稼動率の高い機器からのエラーログを優先的に受け付けるようにして、稼動率の低い機器からの受け付けを制限する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ログを収集する機能を備えた複写機等の処理装置及びその制御方法、並びに前記制御方法を実現するための制御プログラムに関するものである。
【背景技術】
【０００２】
オフィス内で、専用のサーバ機器を置かずに、画像形成装置をサーバとして利用して、専用サーバ機器レスで運用できる環境が広まりつつある。このような状況において、ＣＰＵの速度が速かったり、メモリを多く搭載しているなど性能が高い画像形成装置（親機）が、サーバの機能を有し、前述した複数のネットワーク上の画像形成装置（子機）を管理するデバイス管理の機能を持つようになってきている。
【０００３】
このような親機による子機のデバイス管理においては、子機からのログの収集が行われる。ログには、印刷枚数など通常のログと、エラーが発生したときに障害を特定するためのエラーログがある。特にエラーログは、障害特定のために多くの情報を含むのでデータのサイズが大きい。
【０００４】
子機は、ログを記憶する記憶領域のサイズが小さいため、記憶領域がメモリフルになると、ログが古いものから順番に削除され、エラーログを多く格納することができない。そこで、子機は、格納しきれないログが消えてしまうことを回避するために、エラーが発生したときにはエラーログを逐一親機へ送る必要がある。
【０００５】
しかし、親機が複数の子機からエラーログのような大きなサイズのログを無条件に受け付けてしまうと、親機自身のパフォーマンスが劣化する可能性がある。この問題に対応するために子機側のメモリ容量を増やすことは、コスト面から難しい。そこで、一定容量のエラーログ用のメモリしかなくても効率よくエラーログの収集を行える技術が求められていた。
【０００６】
このようなログ収集を行う従来の技術として、次のようなものがあった（例えば特許文献１参照）。即ち、複数の子機と、ネットワークを介してそれらの子機のログを収集する親機から成る。子機の優先度が定義された優先度定義テーブルがあり、子機に格納されたログの量が所定量に達した場合に、当該子機の優先度が予め設定された優先度より高い場合にのみログを収集する。また、情報に優先度を付けて、子機に格納されたログの量が所定量に達した場合に、情報の優先度が予め設定された優先度より高い場合にのみログを収集する。
【特許文献１】特開２００１−１４７８３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来の技術は、個々の子機或いは情報に対して予め設定された固定的な優先度を基にして、指定した優先度以上の場合のみにログ収集を行うものである。そのため、子機の稼動状況に応じて自動的に優先度を設定することができない。また、親機自身がパフォーマンスを落とさずに機能を実行しなければならないような状況において、親機自身の状態に応じて動的にログの受け入れの可否を決定することができない。
【０００８】
このように上記従来技術では、未だ十分効率よくエラーログの収集を行うことができなかった。
【０００９】
本発明は上記従来の問題点に鑑み、処理装置自身のパフォーマンスを低下させることなく、外部処理装置から効率的にエラーログの受け付けを行うことができる処理装置及びその制御方法、並びに制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明の処理装置は、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置において、前記外部処理装置から送信された前記第１のログを受信する受信手段と、前記受信手段によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出手段と、前記算出手段によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定手段とを備えたことを特徴とする。
【００１１】
本発明の処理装置の制御方法は、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法であって、前記外部処理装置から送信された前記第１のログを受信する受信工程と、前記受信工程によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出工程と、前記算出工程によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定工程とを備えたことを特徴とする。
【００１２】
本発明の制御プログラムは、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、前記外部処理装置から送信された前記第１のログを受信する受信ステップと、前記受信ステップによって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出ステップと、前記算出ステップによって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定ステップとを備えたことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、処理装置自身のパフォーマンスを低下させることなく、外部処理装置から効率的にエラーログの受け付けを行うことが可能になる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１５】
［第１の実施の形態］
＜画像形成システムの全体構成＞
図１は、本発明の実施の形態に係る処理装置を含む画像形成システムの全体の構成を示すブロック図である。
【００１６】
この画像形成システムは、ＬＡＮ ２０１１に接続された画像形成装置６０１を有している。画像形成装置６０１は処理装置の一例であり、画像入力デバイスであるスキャナ部２０７０、画像出力デバイスであるプリンタ部２０９５、コントロールユニット２０００、及びユーザインターフェースである操作部２０１２から構成される。
【００１７】
スキャナ部２０７０、プリンタ部２０９５、及び操作部２０１２は、それぞれコントロールユニット２０００に接続され、コントロールユニット２０００は、ＬＡＮ ２０１１などのネットワーク伝送手段、公衆回線等に接続されている。公衆回線からはカラー画像送信を含むＧ３、Ｇ４ファックスによる送受信が可能である。
【００１８】
また、ＬＡＮ ２０１１には、外部処理装置の一例である他の画像形成装置６０２〜６０５のほか、パーソナルコンピュータ（以下、単にＰＣと記す）１４０も接続されている。他の画像形成装置６０２〜６０５も、画像形成装置６０１と同様の機器構成を持つ。
【００１９】
なお、図１に示す画像形成装置は、プリンタ機能、スキャナ機能の両方を有するように記載しているが、例えば、プリンタ機能だけを持つような画像形成装置やスキャナ機能やファックス機能だけを持つ画像形成装置でも構わない。
【００２０】
＜画像形成装置の構成＞
図２は、図１中の画像形成装置の構成を示すブロック図である。
【００２１】
コントロールユニット２０００は、画像入力デバイスであるスキャナ２０７０や画像出力デバイスであるプリンタ２０９５と接続しこれらの動作を制御する。また、一方ではＬＡＮ２０１１や公衆回線（ＷＡＮ）２０５１と接続することで、画像情報やデバイス情報の入出力を行うためのコントローラである。
【００２２】
コントロールユニット２０００は、システムバス２００７上に、ＣＰＵ２００１、ＲＡＭ２００２、ＲＯＭ２００３、及びＨＤＤ２００４を配置している。
【００２３】
ＣＰＵ２００１は、装置全体の動作を制御する。ＲＡＭ２００２は、ＣＰＵ２００１が動作するためのシステムワークメモリであり、画像データを一時記憶するための画像メモリでもある。また、オペレーティングシステムやシステムソフトウェア、アプリケーションソフトウェアなどのプログラムを動作させるために配置されることもある。ＲＯＭ２００３はブートＲＯＭであり、システムのブートプログラムが格納されている。また、システムプログラムやアプリケーションプログラムが格納されている場合もある。ＨＤＤ２００４はハードディスクドライブで、システムソフトウェア、アプリケーションソフトウェア、画像データ等を格納する。また、図示していないが、小型の画像形成装置では、ＨＤＤ２００４を搭載せずにシステムソフトウェア、アプリケーションソフトウェア等をＲＯＭ２００３に格納して、ハードディスクレスの構成もある。
【００２４】
さらに、コントロールユニット２０００は、システムバス２００７上に、ログ用メモリ２１００、操作部Ｉ／Ｆ２００６、ネットワーク部２０１０、及びモデム２０５０を配置している。
【００２５】
ログ用メモリ２１００は、ログを格納するためのメモリであり、エラーログや稼動状況などの各種ログが格納される。なお、ログの内容については、後述する。また、ログ用メモリ２１００を用意せずに、ＲＡＭ２００２の一部をログ用メモリとして利用するような仕組みとしてもよい。操作部Ｉ／Ｆ２００６は、操作部（ＵＩ）２０１２とのインターフェース部であり、操作部２０１２に表示する画像データを操作部２０１２に対して出力する。また、操作部２０１２から操作者が入力した情報をＣＰＵ２００１に伝える役割をする。ネットワーク部２０１０は、ＬＡＮ２０１１に接続して情報の入出力を行う。モデム２０５０は、公衆回線２０５１に接続して画像情報の入出力を行う。
【００２６】
イメージバスＩ／Ｆ２００５は、システムバス２００７と画像データを高速で転送する画像バス２００８を接続し、データ構造を変換するバスブリッジである。画像バス２００８は、ＰＣＩバスなどで構成される。
【００２７】
画像バス２００８上には、ラスターイメージプロセッサ（ＲＩＰ）２０６０、デバイスＩ／Ｆ部２０２０、スキャナ画像処理部２０８０、及びプリンタ画像処理部２０９０が配置されている。
【００２８】
ラスターイメージプロセッサ（ＲＩＰ）２０６０は、ＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部２０２０は、スキャナ２０７０やプリンタ２０９５とコントローラ２０００とを接続し、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２０８０は、入力画像データに対し補正、加工、編集を行う。また入力された画像がカラー原稿であるか或いは白黒原稿かを画像の彩度信号から判断しその結果を保持する機能を有する。プリンタ画像処理部２０９０は、出力画像データに対し補正、加工、編集を行う。
【００２９】
また、画像バス２００８上には、画像回転部２０３０、解像度変換部２０３１、色空間変換部２０３２、及び階調変換部２０３３も配置されている。
【００３０】
画像回転部２０３０は、スキャナ画像処理部２０８０と連携して、スキャナ２０７０からの画像読み込みを行う。解像度変換部２０３１は、画像の解像度を変換する処理を行い、色空間変換部２０３２はマトリクス演算により、画像の色空間を変換する処理を行う。階調変換部２０３３は、画像の階調を変換する処理を行い、画像圧縮部２０４０は、画像の圧縮伸長の処理を行う。
【００３１】
上記の説明においては、画像回転などの画像処理は、画像バス２００８に接続されたデバイスで行っているが、ＨＤＤ２００４やＲＯＭ２００３に画像処理のソフトウェアを格納しておき、ＲＡＭ２００２に読み込んで、ＣＰＵ２００１で実行するようにしてもよい。なお、実行するソフトウェアは、画像処理に限らず、画像形成装置で必要となる他の処理でも構わないのは、いうまでもない。また、ＲＯＭ２００３に格納されたプログラムは、ＲＡＭ２００２に読み込まずに実行してもよい。
【００３２】
また、図２のＨＤＤ２００４において、ハードディスク内には、システムソフトウェアや、アプリケーションソフトウェア、画像データを格納すると記載した。しかし、これらに限らず、画像管理のためのデータなどの画像以外の一般データファイルや画像形成装置で管理するデータを格納することができる。画像形成装置で管理するデータとしては、例えば、どの利用者が、いつ、どのような機能を利用したかを記録するジョブログなどがある。
【００３３】
上記構成の画像形成システムにおいて、画像形成装置６０１が、ログ収集のサーバ機能を有する親機の画像形成装置である。また、画像形成装置６０２、６０３、６０４、６０５は、画像形成装置６０１にログが収集される管理対象となる子機の画像形成装置であるものとする。そして、以下、親機である画像形成装置を単に親機と記し、子機である画像形成装置を単に子機と記す。なお、子機６０２、６０３、６０４、６０５は、ＨＤＤ２００４を搭載していなかったり、メモリ容量が少ない場合がある。
【００３４】
＜本実施の形態におけるログ＞
次に、本実施の形態におけるログについて説明する。
【００３５】
ログは２種類あり、１つは、どの利用者が、いつ、どれだけ（使用頻度）、どの機能を利用したかを表すジョブログである。もう一つは、エラーが発生したときに障害を特定するためのエラーログである。エラーログは、エラーが発生したときにそのエラーを解析するために必要となる内部モジュールの呼び出しシーケンス情報や、エラー発生時点でのメモリのダンプ結果情報などを含む。エラーログのサイズは、このような情報を含むため大きいものとなる。ジョブログは第１のログの一例であり、エラーログは第２のログの一例である。
【００３６】
（Ａ）ログの一例
（ｉ）ジョブログの一例
ジョブログの一例を図３を参照して説明する。図３は、ジョブログの一例を示す表形式図である。
【００３７】
図３に示すように、ジョブログには、ジョブの処理が行われた日付の情報５０１、時間の情報５０２、誰が処理を実行したかを表すユーザ識別子５０３が記録されている。更に、どのような処理を実行したのかを示すタイプ情報５０４が記載される。タイプ情報５０４には、例えば、ＰＣ１４０などからアプリケーションの印刷を実行したＰｒｉｎｔや、画像形成装置の複写機能（以下、コピー機能と記す）を実行したＣｏｐｙ、スキャンして画像を読み取るＳｃａｎ、ファクシミリ送信を行うＦＡＸなどがある。
【００３８】
また、ジョブログには、処理に要したページ数情報５０５が記録されている。さらに、そのページ数の中で、白黒で処理したページ数情報５０６、カラーで処理したページ数情報５０７、及び両面処理されたページ数情報５０８などが記録されている。
【００３９】
例えば、図３における５０９の事項では、ユーザ「５０２５１」が、「２００７年１０月５日８時２５分４１秒」に、コピー機能を実行したことを表している。そのときに５４枚コピーを行い、そのうち３７枚が白黒、１７枚がカラーであり、２７枚が両面処理されていることが記録されている。その他も同様である。
【００４０】
本実施の形態では、ジョブログに含まれる情報として９種類の項目（５０１〜５０９）を挙げているが、この限りでなく他の項目を含んでよいのは勿論のこと、この中のいくつかの項目だけを選択してジョブログとしても構わない。
【００４１】
（ｉｉ）エラーログの一例
エラーログの一例を図４を参照して説明する。図４は、エラー時の画像形成装置における動作状況を記録したエラーログの一例を示す図である。
【００４２】
エラーログのヘッダー部２４０２は、画像形成装置の機種名「ＩＲＸＸＸＸ」、システムソフトウェアのバージョン「ＣＯＮＴ ｖｅｒ０．４２」、及びエラーログ情報取得時の日付などで構成される。
【００４３】
動作手順は、図４における２４０３、２４０５などに示されるように、時間、ブロックの場所、動作内容、などが読み取れる。これらの情報を基に、エラー発生の原因などを解析することができる。また、エラーレベルによって、例えば、簡易的な情報（２４０１）や、詳細な情報（２４０４）など情報量の異なるエラーログの生成が行える。
【００４４】
（Ｂ）ログの収集
ログ収集について、具体的に図５を参照して説明する。図５は、親機６０１によって行われるログ収集を示す概念図である。
【００４５】
子機６０２〜６０５は、ログを親機６０１へ送付する。なお、このときにログ自体を親機６０１へ送付するのでなく、ログ送付依頼を先へ送付して、送付が許可されたときにログ本体を送るような仕組みとしてもよい。図５の例では、子機６０２〜６０５が、それぞれログ６０６、６０７、６０８、６０９を親機６０１へ送付している。この例では、子機を４台としたが、子機が４台に限定されるものでない。
【００４６】
また、親機６０１自体も画像形成装置として機能するため、ログを持っているので、親機６０１も自身のログ６１０を収集することになる。
【００４７】
なお、図５の例では、各子機６０２〜６０５から親機６０１へログを送信しているが、親機６０１が、子機６０２〜６０５からログを収集するような仕組みとしても構わない。例えば、前述したジョブログの場合には、親機６０１が定期的に子機６０２〜６０５に対してログを収集するようにしてもよい。
【００４８】
子機を親機の管理対象にする設定の方法は、例えば、親機６０１に予め登録しておく方法や、子機が新規にネットワークに接続された場合に、ブロードキャストで自身の存在を親機に通知するなどの公知の方法を用いる。
【００４９】
＜親機６０１の動作＞
以下、親機６０１の動作について説明する。
【００５０】
親機６０１は、１台以上の子機を管理するための、管理機能を持ち、ログを収集するサーバとして動作する。なお、本実施の形態では、管理機能として、ログ収集機能のみしか記載していないが、その他の管理機能を有していても構わない。
【００５１】
ログとしては、前述したように、ジョブログとエラーログの収集を行う。ジョブログは、定期的に収集されており、定められた時間になると、親機６０１が、親機６０１のネットワーク部２０１０を用いてＬＡＮ２０１１を経由して管理対象の子機６０２〜６０５に接続する。
【００５２】
子機６０２〜６０５では、ログ用メモリ２１００に格納されているジョブログをネットワーク部２０１０を用いてＬＡＮ２０１１を経由して親機６０１に送信する。親機６０１は、受信したジョブログをＨＤＤ２００４の所定の格納場所に書込む。親機６０１は、管理対象の全ての子機６０２〜６０５に対して、同様にしてジョブログの収集を行い、ＨＤＤ２００４に書込む。更には、親機６０１自身のジョブログも、親機６０１のログ用メモリ２１００から読み出し、ＨＤＤ２００４の所定の格納場所に書込む。
【００５３】
このようにして、定期的に収集された全ての管理対象の子機６０２〜６０５と親機６０１自身のジョブログが、親機６０１のＨＤＤ２００４に保存されている。
【００５４】
（Ａ）ジョブログを収集したときの動作
（ｉ）各子機の稼動状況を求める
子機６０２〜６０５からジョブログを収集したときに、親機６０１は、各子機６０２〜６０５の稼動状況を求める。以下、図５及び図６を参照して、収集されたジョブログから稼動状況を求める一例について説明する。４台の子機６０２〜６０５のジョブログの一例を示す表形式図である。
【００５５】
図６における７０１、７０２、７０３、７０４に示すものは、それぞれ４台の子機６０２、６０３、６０４、６０５から取得された親機６０１のＨＤＤ２００４に格納されているジョブログである。ここで、本実施の形態では、説明を簡単にするために、１日分のジョブログのみを記載している。当然であるが、親機６０１のＨＤＤ２００４に格納されるジョブログは、１日分だけなく、複数日分格納されていても構わない。また、そのような場合は、稼動状況を求めるために、格納される子機のジョブログを１日分（或いは、所定の日数分）だけ用いるようになっていても構わない。
【００５６】
子機の稼動状況の求め方は、例えば、ユーザが子機を利用した回数で判断する。７０１のジョブログから、子機６０２は、「２００７年１０月５日の８時２５分４１秒」、「１１時２１分４３秒」、「１４時１１分５２秒」、「１５時１２分３２秒」、「１７時４５分５３秒」、「１９時３６分２５秒」の合計６回、利用されていることが分かる。同様に、７０２のジョブログから子機６０３は２回、７０３のジョブログから子機６０４は２回、７０４のジョブログから子機６０５は４回の利用がそれぞれあったことが分かる。
【００５７】
（ｉｉ）稼動状況から優先度を算出
親機は、ジョブログから求められた稼動状況に基づいて、子機の優先度を算出する。優先度の算出として、例えば、各利用回数を最大の利用回数で割って、１００を掛けるようなものがある。子機６０２の場合は、
【００５８】
【数１】
【００５９】
となり、優先度は１００となる。同様に、子機６０３、６０４は、利用回数が２であるので、優先度が３３．３、子機６０５は、利用回数が４であるので、優先度が６６．７となる。
【００６０】
優先度の求め方は、このような算定式だけでなく、他の算定式でも構わないことはいうまでもない。また、利用回数で判定するだけでなく、例えば、合計処理枚数で判定するようにしてもよい。合計処理枚数は、子機６０２、６０３、６０４、６０５それぞれ２１５、２７，３７６、１４８となるので、先の算出式を用いれば、子機６０２の優先度は、
【００６１】
【数２】
【００６２】
となる。同様に、子機６０３、６０４、６０５の優先度は、それぞれ７．２、１００、３９．４となる。
【００６３】
また、処理の種別毎に重み付けを変えてもよい。例えば、ＰＣ１４０からアプリケーションの印刷を実行したＰｒｉｎｔの重み付けを１、画像形成装置のコピー機能を実行したＣｏｐｙの重み付けを１．３とする。また、スキャンして画像を読み取るＳｃａｎの重み付けを０．９、ファクシミリ送信を行うＦＡＸの重み付けを１．１とする。その結果、子機６０２、６０３、６０４、６０４の重み付け後の枚数は、それぞれ２６２．５、２８．２、４２１、１４９．８となるので、先の算出式を用いれば、子機６０２の優先度は、
【００６４】
【数３】
【００６５】
となる。同様に、子機６０３、６０４、６０５の優先度は、それぞれ６．７、１００、３５．６となる。
【００６６】
本実施の形態では、ジョブログの情報だけから優先度を求めているが、子機のスペック（例えば、単位時間処理枚数）やログ用メモリ容量などを基準として、優先度に重み付けをするようにしてもよい。例えば、単位時間処理枚数が予め定めた基準より少ない場合や、ログ用メモリ容量が予め定めた基準より少ない場合に、優先度を高くする重み付けを与えるようなことを行ってもよい。
【００６７】
（ｉｉｉ）優先度テーブルを更新
このようにして、求めた優先度で優先度テーブルを更新する。ここで、優先度テーブルの一例について、図７を参照して説明する。図７は、優先度テーブルの一例を示す図である。
【００６８】
図７に示すように、優先度テーブルは、子機を特定するフィールド８０１と、子機の優先度を表す優先度フィールド８０２から成る。
【００６９】
図７の例では、フィールド８０１には、子機を特定する名称が記載されている。なお、子機を特定する情報は、名称に限らず、例えばＩＰアドレスでなど、子機を一意に特定できる情報であればよい。ここで、図７中の８０３のデバイス名称Ａは、図５中の子機６０２を表す。同様に、８０４のデバイス名称Ｂは子機６０３、８０５のデバイス名称Ｃは子機６０４、８０６のデバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【００７０】
図７の優先度フィールド８０２には、先に説明した利用回数による優先度がデバイス名称Ａ〜Ｄに対応してそれぞれ記載されている。
【００７１】
なお、優先度テーブル自体の新規作成や、子機のフィールド追加や削除については、本発明の本質的なものでない。しかし、例えば、ジョブログとして親機６０１のＨＤＤ２００４に記録があるものを優先度テーブルのフィールド８０２に追加して、一定期間存在していないものは削除するような仕組みとしてもよい。
【００７２】
（ｉｖ）処理の流れ
次に、上述した、親機６０１が子機６０２〜６０５からジョブログを収集して優先度テーブルを更新する処理の流れについて、図８のフローチャートを参照して説明する。
【００７３】
図８は、ジョブログを収集して優先度テーブルを更新する処理の流れを示すフローチャートである。図８の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【００７４】
まずＳ９０１において、ＣＰＵ２００１は、各子機６０２〜６０５からジョブログを収集する。次のＳ９０２では、ＣＰＵ２００１は、Ｓ９０１で収集した各子機６０２〜６０５のジョブログから各子機６０２〜６０５の稼動状況を求める。稼動状況とは、例えば子機６０２において利用回数であれば、処理が行われた回数である「６」がジョブログ７０１から求められる。また、合計処理枚数を稼動状況とするのであれば、ジョブログ７０１の各処理の処理枚数を合計して、子機６０２の稼動状況は、「２１５」とする。
【００７５】
Ｓ９０３において、ＣＰＵ２００１は、各子機６０２〜６０５の稼動状況から優先度を求める。これは、例えば、先の説明では、各稼動状況の値を全ての子機６０２〜６０５の稼動状況の最大値で割ったものに１００を掛けることで優先度を求めていた。本実施の形態で説明した、Ｓ９０２、Ｓ９０３での稼動状況、及び優先度の求め方は一例であり、他の算出の仕方でも構わない。
【００７６】
Ｓ９０４において、ＣＰＵ２００１は、優先度テーブルの各子機６０２〜６０５の優先度をＳ９０３で求められた優先度に置き換える。
【００７７】
（Ｂ）エラーログが送付されたときの動作
次に、子機６０２〜６０５から親機６０１に対してエラーログが送付されたときの親機６０１の動作について説明する。
【００７８】
（ｉ）エラーログ受け付けの可否判定の詳細
以下、子機６０２〜６０５からエラーログが送付されたときに、親機６０１がエラーログを受け付けるかどうかを判定する動作について、図９を参照して具体的に説明する。 図９は、親機６０１のエラーログ受け付け可否判定動作を説明する概念図であり、図５と共通する要素には同一符号を付与する。
【００７９】
・親機６０１が処理を行っていない場合
まず、親機６０１が処理を行っていない場合について説明する。この場合、エラーログの格納要求１３０１が子機６０２から親機６０１へ送付されると、親機６０１は、自身のジョブログ６１０から、使用の集中が予想される時間であるかどうかを判断する。
【００８０】
図１０は、親機６０１自身のジョブログ６１０の一例を示す表形式図である。
【００８１】
このジョブログ６１０は、１時間毎に８時台（図１０の１００１）、９時台（１００２）、１０時台（１００３）、１１時台（１１０４）、１５時台（１００５）、１７時台（１００６）、及び１９時台（１００７）と分割されている。
【００８２】
この分割された時間の中で、稼動状況を求める。稼動状況の求め方は、先に示した利用回数であったり、合計処理枚数などである。この求めた稼動状況に対して閾値を設けて、それ以上の場合は、使用の集中が予想される時間と判断する。
【００８３】
例えば、稼動状況を利用回数として、閾値を３回とすると、図１０の例では、８時台、９時台にエラーログの格納要求が子機６０２からあった場合は、エラーログの書込みを延期する。
【００８４】
本実施の形態では、１日のジョブログとしているが、親機６０１自身のジョブログ６１０の格納がより多くあった場合には、１日だけに限らず、日にち毎に各時間の稼動状況を求めて、更に各時間の平均の稼動状況を算出して、それを利用するようにしてもよい。
【００８５】
また、本実施の形態のように１時間単位とは限らず、例えば、午前、午後で分けるとか、９時以前、９時から１２時、１２時から１３時、１３時から１７時、１７時以降のようにオフィスの勤務状況に合わせたりしてもよい。更には、時間で区切るのでなく、エラーログの格納要求時点から１時間以内などのようにしてもよい。
【００８６】
親機６０１の使用が予想されるときに、子機６０２からのエラーログ格納要求を延期すると記載した。しかし、エラーログ自体が致命的なエラーであったり、子機６０２内のエラーログ格納用のログ用メモリ２１００がメモリフルの状態になっている（或いは、メモリフルになりかけている）ときなど緊急にエラーログを格納する必要がある。
【００８７】
そのような場合には、次の処理を行う。図示しないが、エラーログ格納要求内に設けられた緊急用のフラグが立つことで、親機６０１は、エラーログの書込みが必要なことであると判断する。親機６０１は、エラーログの送信を子機６０２へ要求して、子機６０２のエラーログを親機６０１のＨＤＤ２００４へ書込む。
【００８８】
また、例えば、子機６０２で紙詰まり（ジャム）が頻発する場合などは、エラーログもすぐに埋まってしまうので、次の処理を行う。予め定めた回数以上のジャムが発生すると、子機６０２で、先の緊急用フラグを立ててエラーログの格納要求を送信する。これにより、エラーログによってログ用メモリ２１００のメモリフルが発生する前に親機６０１にエラーログを書込むことができる。
【００８９】
エラーログを親機６０１６０２へ書込むことができた子機６０２は、ログ用メモリ２１００をクリアする。なお、ログ用メモリ２１００にエラーログ以外のログが格納されている場合は、格納したエラーログだけを削除する。
【００９０】
なお、本実施の形態の説明では、エラーログの格納要求をまず親機６０１に送信しているが、子機６０２からダイレクトにエラーログを親機６０１へ送信してもよい。また、親機６０１において機能が実行されていない状態で使用の集中が予想されるときに、上記の緊急用フラグが立っていない場合であっても、次のような子機からのエラーログの格納要求を受け付けるようにしても構わない。即ち、子機の優先度に基づいて、一定の閾値以上の優先度を持つ子機からのエラーログ格納要求を受け付けるようにしても構わない。
【００９１】
・親機６０１が機能を実行している場合
次に、親機６０１が機能を実行している場合について具体的に説明する。この場合、先に説明した優先度テーブルから取得した子機の優先度を親機６０１の状態によって補正し、補正された優先度が予め定めた閾値以上であれば、親機６０１は、エラーログの書込みを行う。
【００９２】
ここで、説明のために、図１１の優先度テーブルと、図１２の閾値及び各種補正値を用いることにする。図１１は、優先度テーブルの一例を示す図であり、図１２（ａ），（ｂ）は、優先度の閾値と各種補正値の一例を示す図である。
【００９３】
図１１中の１１０１に示すデバイス名称Ａは、図５中の子機６０２を表す。同様に、１１０２に示すデバイス名称Ｂは子機６０３、１１０３に示すデバイス名称Ｃは子機６０４、１１０４に示すデバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【００９４】
図１２（ａ）において、閾値θは、補正された優先度がこの値以上であれば、エラーログの書込みを認めるという境界値である。再送用補正値πについては後で説明する。パネル操作補正値ρは、親機６０１の操作パネル（操作部２０１２）を使用しているときに優先度を補正するための値である。即ち、操作パネルが利用されているということは、親機６０１の前で利用者が使っているため、親機６０１の処理をより優先させるために優先度を補正する。
【００９５】
図１２（ｂ）に示すジョブ種類別補正テーブルは、親機６０１が処理中のジョブの種類によって優先度の補正を行うためのものである。これは、例えば、カラーデータの処理を行うときには白黒データに比べてデータ量が多いため、親機６０１のＣＰＵ２００１に負担が大きいなど、ジョブの種類に応じて優先度を変えるためのテーブルである。
【００９６】
このジョブ種類別補正テーブルは、ジョブ種類を表すフィールド１２０５と、その補正値を表すフィールド１２０６から成る。図１２（ｂ）の例では、カラージョブに対する補正値が−１５、白黒ジョブの補正値が−５、ＦＡＸジョブの補正値が−２０、プリントジョブの補正値が−１０である。また、１枚の用紙に複数ページを面付けして印刷するＮｉｎ１のジョブに対する補正値は−５である。
【００９７】
なお、図１２（ｂ）に示すジョブ種類別補正テーブルは、一例であり、ジョブ種類はこれらに限定されることはないし、これらを含まなくてもよい。
【００９８】
以下、ＪＣＴ（Ｘ）は、ジョブ種類Ｘに対する補正値を表すものとする。例えば、ＪＣＴ（ＦＡＸ）は、ジョブ種類別補正テーブルから−２０となる。なお、Ｘの部分は１つに限らず複数併記することができ、その場合は、補正値の合計となる。例えば、ＪＣＴ（Ｃｏｌｏｒ，Ｎｉｎ１）は、Ｃｏｌｏｒの補正値−１５とＮｉｎ１の補正値−５の合計−２０となる。
【００９９】
子機の優先度をαとすると、補正された優先度α’が、閾値θ以上であればエラーログの書込みを親機６０１は行う。具体的に例を挙げて説明する。
【０１００】
子機６０２（図１１中のデバイス名称Ａ）からエラーログの格納要求が親機６０１に対して送られると、親機６０１は、優先度テーブルから当該子機６０２の優先度α６０２（＝１００）を取得する。この例では、１００である。
【０１０１】
このとき、親機６０１で操作パネルを利用してカラーコピーを実行している場合は、パネル操作補正値ρ＝−２０、カラーのジョブ補正値ＪＣＴ（Ｃｏｌｏｒ）＝−１５であるので、
となり、補正された優先度
は６５となり、閾値θ（＝７０）を下回っているため親機６０１にエラーログの格納は行われない。
【０１０２】
なお、先に説明したように、緊急時のエラーログについては、優先的に書込まれる。これは、以下の説明においても明記はしないが同様である。一方、同じく操作パネルを利用していても、白黒コピーを実行している場合は、白黒のジョブ補正値ＪＣＴ（ＢＷ）＝−５であるので、
【０１０３】
であり、閾値θを上回るので、親機６０１にエラーログは書込まれる。また、親機６０１の操作パネルを使わずにＰＣ１４０などからＦＡＸ送信されている場合は、ＦＡＸのジョブ補正値ＪＣＴ（ＦＡＸ）＝−２０であるので、
【０１０４】
となり、エラーログの格納要求を親機６０１は受け付けるが、親機６０１の操作パネルからＦＡＸ送信した場合では、パネル操作補正値ρが追加されるので、
【０１０５】
となり、エラーログの格納要求を親機６０１は受け付けない。
【０１０６】
更には、例えば、子機６０５（図１１中のデバイス名称Ｄ）は、優先度が８０である。パネル操作補正値が−２０であることから、親機６０１のパネル操作が行われている場合には、それだけで優先度が６０となり、エラーログの格納要求が受け付けられない。
【０１０７】
しかしながら、親機６０１にＰＣ１４０などからプリントジョブが送信されてきて、それを処理しているだけであれば、Ｐｒｉｎｔのジョブ補正値ＪＣＴ（Ｐｒｉｎｔ）＝−１０であるので、
【０１０８】
であり、閾値と同じ７０でエラーログ格納要求を親機６０１は受け付ける。
【０１０９】
なお、これまでの説明で用いた例は、各子機６０２〜６０５からの初回のエラーログ格納依頼とする。エラーログ格納依頼が再送された場合の処理については、後述する。
【０１１０】
このように、各子機６０２〜６０５の優先度が異なるので、親機６０１が同一の状態であっても、エラーログの格納要求の受け付けの可否が動的に変わる。また、同一の子機からのエラーログ格納要求であっても、親機６０１の状態によって、エラーログの格納要求の受け付けの可否が動的に変わる。
【０１１１】
・エラーログの格納を受け付けなかった場合
次に、子機６０２〜６０５からのエラーログの格納を親機６０１が受け付けなかった場合について説明する。
【０１１２】
親機６０１は、先に図１０を参照して例示したように、自身のジョブログ６１０から使用の集中が予想される時間について算出することができる。親機６０１が、その時点でのエラーログの格納を受け付けず、延期させる子機に対して、使用の集中が無いと予想される時間での再送を指示する。
【０１１３】
延期の指示を受けた子機は、指定された時間になると、不図示であるエラーログ格納要求に再送であることを示す再送フラグを立てて、再度、親機６０１へエラーログ格納要求を送付する。
【０１１４】
親機６０１では、エラーログ格納要求を受け取り、再送フラグが立っていることを確認すると、優先度を補正するときに、先の図１２（ａ）の再送用補正値πを補正値として加える。例えば、先の例で、親機６０１で操作パネルを利用して、カラーコピーを実行している場合の初回のエラーログ格納要求における補正後の優先度は、６５であったが、同じ状況で再送の場合は、再送用補正値πが１４５であるので、
【０１１５】
となり、エラーログの格納要求は、親機６０１で受け付けられる。
【０１１６】
図１２の例で、再送用補正値πを１４５としたのは、どのような場合でも再送されたエラーログ格納要求を受け付けさせるためである。つまり、補正されていない優先度がゼロ以上であるとすると、
【０１１７】
から、再送用補正値πが１４５以上であれば、常に閾値θ（７０）を上回る。
【０１１８】
この例では、常にエラーログ格納要求が再送時に受け入れられるようにしたが、その限りでなくてもよい。より低い値で、一定以上の（補正された）優先度を持つものでないと、再送された場合でも受け付けなくしてもよい。或いは、再送用補正値πを固定値でなく、例えば再送回数によって値を変えるような仕組みでもよい。
【０１１９】
一例として、再送用補正値πを
【０１２０】
として、子機６０４（図１１中のデバイス名称Ｃ）からエラーログの格納要求が、親機６０１へ送付され、その格納要求が１度目の再送であったとする。このとき、親機６０１では、ＰＣ１４０などからＦＡＸ送信が実行されていると、子機６０４の優先度が６５であるから、
【０１２１】
となり、エラーログ格納要求は受け付けられず、親機６０１から再度、子機６０４に対してエラーログ格納要求の延期が要求される。２回目の再送を子機６０４が行ったときに、親機６０１で操作パネル上で白黒コピーが行われていたとすると、
【０１２２】
となり、エラーログ格納要求は受け入れられて、親機６０１は、子機６０５のエラーログを書込む。
【０１２３】
２回目の親機６０１は、操作パネルが使われており、再送用補正値を除いた補正値が、１度目の再送時の−２０と比べて−２５と大きく、エラーログ格納要求を受け入れづらい状態である。それにも関わらず、且つ元々の優先度が閾値を下回るような子機６０５のエラーログ格納要求であっても、再送回数が多いことで受け入れることが可能となる。なお、この場合は、前述したエラーログ格納要求に再送であることを示す再送フラグを設けるだけでなく、再送回数を示す値をエラーログ格納要求に入れることになる。
【０１２４】
本実施の形態では、親機６０１自身のジョブログ６１０を参照して、使用の集中が予想されない時間の再送を子機に対して行うように説明しているが、そのような時間を指示しないで、予め定められた一定時間後に再送するように指示してもよい。或いは、親機６０１で時間を指定しないで、子機が一定時間経過したら再送するような仕組みでも構わない。更には、再送用補正値πを無くして（π＝０）として、子機の優先度と親機６０１のエラーログ格納要求時の状態だけで補正された優先度を求めて判定するようにしても構わない。
【０１２５】
（ｉｉ）エラーログ受け付けの可否判定処理の流れ
次に、親機６０１が子機のエラーログ格納要求を受け付けるか否かの決定を行う際の処理の流れについて、図１３を参照して説明する。図１３は、第１の実施の形態におけるエラーログ受け付けの可否判定処理の流れを示すフローチャートである。図１３の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１２６】
まずＳ１４０１において、ＣＰＵ２００１は、優先度テーブルからエラーログ格納要求のあった子機の優先度を取得して、Ｓ１４０２へ進む。Ｓ１４０２では、ＣＰＵ２００１は、エラーログ格納要求を確認して、再送されたエラーログを示すフラグが立っている場合には、Ｓ１４０３へ進み、そうでなければＳ１４０４へ進む。
【０１２７】
Ｓ１４０３では、ＣＰＵ２００１は、子機からのエラーログ格納要求が、再送されたエラーログ格納要求であったので、Ｓ１４０１で取得した優先度を再送用補正値を用いて補正して、Ｓ１４０４へ進む。
【０１２８】
Ｓ１４０４では、ＣＰＵ２００１は、親機６０１自身が複合機としての機能を実行しているかを判定する。実行していればＳ１４０５へ進み、実行していなければＳ１４１３へ進む。Ｓ１４０５において、ＣＰＵ２００１は、親機６０１が自身の操作パネルから機能を実行しているかどうかを判定する。操作パネルから機能を実行していれば、Ｓ１４０６へ進む。
【０１２９】
Ｓ１４０６において、ＣＰＵ２００１は、子機の優先度を、操作パネルが操作されているとして補正、つまりパネル操作用に補正を行う。Ｓ１４０５で操作パネルから実行されていなければＳ１４０７へ進む。これは、例えば、ＰＣ１４０などからジョブが投入された場合などである。Ｓ１４０７では、ＣＰＵ２００１は、親機６０１が画像形成装置で実行中のジョブの種類に応じて、子機の優先度の補正を行う。
【０１３０】
一方、Ｓ１４１３は、Ｓ１４０４で親機６０１が複合機としての機能を実行していない場合に実行される。Ｓ１４１３では、ＣＰＵ２００１は、親機６０１が自分自身のジョブログを確認して、現在の時間が親機６０１の使用が集中する時間であるかどうかを判定する。使用の集中が予想される場合は、Ｓ１４０８へ進み、使用の集中が予想されない場合は、Ｓ１４１４へ進んで、親機６０１にエラーログを書込んで終了する。
【０１３１】
Ｓ１４０８において、ＣＰＵ２００１は、エラーログ格納要求がハード的に動作しないなどの致命的なエラーかどうかを判定する。これは、エラーログ格納要求中にフラグなどを準備して判断することができるようにする。致命的なエラーログの場合は、Ｓ１４１４へ進む。致命的なものでない場合は、Ｓ１４０９へ進む。
【０１３２】
Ｓ１４０９において、ＣＰＵ２００１は、子機のログ用メモリ２１００がメモリフルになっているかを判定する。これも、エラーログ格納要求中にフラグなどを準備して判断できるようにする。メモリフルの場合は、Ｓ１４１４へ進み、そうでない場合は、Ｓ１４１０へ進む。
【０１３３】
Ｓ１４１０において、ＣＰＵ２００１は、エラーログ格納要求が、ジャムが一定回数発生した後のエラーログであるかどうかを判定する。これも、エラーログ格納要求中にフラグなどを準備して判断することができるようにする。一定回数以上のジャム発生のエラーログの場合は、Ｓ１４１４へ進み、そうでなければ、Ｓ１４１１へ進む。
【０１３４】
Ｓ１４１１において、ＣＰＵ２００１は、補正された優先度が、予め定められた閾値より大きいかどうかを判定し、閾値よりも大きければＳ１４１４へ進む。閾値未満であれば、Ｓ１４１２へ進む。
【０１３５】
Ｓ１４１２において、ＣＰＵ２００１は、エラーログ格納要求を送信した子機に対して、親機６０１のジョブログを用いて稼動状況を確認する。そして、親機６０１の稼動状況が低下すると予想される時間での再送を子機に指示して終了する。Ｓ１４１４において、ＣＰＵ２００１は、当該子機のエラーログを書込んで終了する。
【０１３６】
なお、本実施の形態においては、エラーログとして説明したが、突発的に発生してサイズが大きいことなどが親機６０１の処理のパフォーマンスを劣化させるようなログであれば、エラーログでなくても構わない。
【０１３７】
＜本実施の形態に係る利点＞
第１の実施の形態によれば、次のような利点を有する。
【０１３８】
親機６０１は、通常のジョブログを定期的に子機６０２〜６０５から取得している。そこで、ジョブログから子機の稼動状況を確認してその稼動率を算出し、稼動率の高い子機は頻繁に使われるため子機のログ用メモリ２１００がメモリフルになり易いと判断して、このような子機からのエラーログ格納要求を優先的に受け付ける。逆に、稼動率の低い子機は、ログ用メモリ２１００がメモリフルになり難いと判断して、エラーログ格納要求の受け付けの優先度を下げる。このように、管理対象の子機が多数あっても、稼動率の高い機器からのエラーログを優先的に受け付けるようにして、稼動率の低い機器からの受け付けを制限する。これにより、親機自身の画像形成装置としてのパフォーマンスを低下させることなく、効率的にエラーログの受け付けを行うことができる。このとき、単純に子機側の稼動率だけで優先度を決定するのではなく、親機６０１自身の稼動率や稼動状況（実際にユーザが機器の操作をしているかなど）を基にして優先度を決めるので、子機に対して自動的に動的な優先度の設定を行うことが可能になる。
【０１３９】
即ち、本実施の形態では、逐次変化するジョブログを用いることにより、子機のジョブログから算出された優先度と、逐次変化する親機６０１の稼動状態とによって、子機からのエラーログ格納要求の可否を動的に判定することができる。
【０１４０】
また、親機６０１のジョブログ６１０から親機６０１自身の稼動状況の予測を行って、子機からのエラーログ格納要求の可否を決めたり、エラーログ格納要求が拒否された子機への再送時間を決めたりすることができる。
【０１４１】
更には、親機６０１で実行中のジョブの種類や、操作パネル上の実行かどうかによって、子機の優先度の補正を動的に行うことができる。また、エラーログ格納要求で、緊急エラーログを優先的に格納できる仕組みも実現することができる。
【０１４２】
［第２の実施の形態］
第１の実施の形態では、エラーログ格納要求を延期する場合には、親機６０１が子機に対して再送を指示して、エラーログ格納要求を再送してもらうようにした形態について説明した。これに対して、第２の実施の形態では、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに、子機のエラーログを取得するようにした形態について説明する。
【０１４３】
＜エラーログ格納要求を延期した場合の動作＞
第２の実施の形態に係る、親機６０１がエラーログ格納要求を延期した場合の動作について、図１４を参照して説明する。図１４は、エラーログ格納要求を延期した場合の動作を説明するための概念図であり、図５と共通の要素には同一符号を付与する。
【０１４４】
子機６０２からエラーログ格納要求１６０１があったが、親機６０１は、このエラーログ格納要求１６０１を拒否したとする。このとき、親機６０１は、エラーログ書込み待ちリストに子機６０２を追加する。同様に、子機６０４からエラーログ格納要求１６０２があったが、親機６０１がこのエラーログ格納要求１６０２を拒否すると、親機６０１はエラーログ書込み待ちリストに子機６０４を追加する。なお、エラーログ格納要求の受け付けの可否の方法は、第１の実施の形態で示したものとする。
【０１４５】
エラーログ書込み待ちリストは、例えば、図１５に示すようなものである。図１５は、エラーログ書込み待ちリストの一例を示す図である。
【０１４６】
図１５において、１７０１は、エラーログ書込み待ちリストを特定するデバイスの名称であり、１７０２、１７０３はそれぞれ、エラーログ格納要求を送付した日付と時間である。なお、第１の実施の形態の図１１で示したものと同様に、デバイス名称Ａは、図５中の子機６０２を表す。同様に、デバイス名称Ｂは子機６０３、デバイス名称Ｃは子機６０４、デバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【０１４７】
図１５の１７０４に示すものは、子機６０４が「２００７年１０月５日」の「１１時２４分５５秒」に送ったエラーログ格納要求は、親機６０１に拒否されたことを示す。１７０５に示すものは、子機６０２が「２００７年１０月５日」の「１３時１０分００秒」に送ったエラーログ格納要求は、親機６０１に拒否されたことを示す。
【０１４８】
親機６０１では、自身がコピーなど画像形成装置としての機能を実行していないとき、または自身のジョブログ６１０から機能の集中使用が予想されないときは、次の処理を行う。即ち、エラーログ書込み待ちリストを確認して、エラーログ格納要求があったが、まだエラーログを書込んでない子機からエラーログを取得する。図１５の例では、子機６０４と６０２がエラーログの書込み待ちになっているが、親機６０１は、優先度テーブルを参照して優先度が高い子機からエラーログを取得する。
【０１４９】
例えば、図７の優先度テーブルであったとすると、子機６０４の優先度は６５、子機６０２の優先度は１００である。時間的には子機６０４よりも後にエラーログ格納要求を行った子機６０２のエラーログが先に取得される。当然ながら、単純にエラーログ格納要求した時間が早いものから順にエラーログを取得するような仕組みでも構わない。
【０１５０】
また、複数回のエラーログ格納要求がある場合に、例えば、図１６のようなエラーログ書込み待ちリストであったとする。優先度は、子機６０５（デバイス名称Ｄ）が８０で、子機６０３（デバイス名称Ｂ）が３５である。しかし、エラーログ格納要求の回数が、子機６０３からの方が多いため、親機６０１は、子機６０３のエラーログを先に取得してもよい。
【０１５１】
また、一定回数以上のエラーログ格納要求が延期された子機がエラーログ書込み待ちリストにある場合には、その子機を優先として親機６０１が当該子機のエラーログを取得してもよい。
【０１５２】
＜エラーログ取得決定処理の流れ＞
次に、親機６０１が、エラーログ書込み待ちリスト中のどの子機のエラーログを取得するのかを決定する処理の流れについて、図１７及び図１８を参照して説明する。
【０１５３】
図１７及び図１８は、本発明の第２の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートであり、図１３と同一処理の部分については、図１３と同一符号を付与して、その説明は割愛する。なお、図１７及び図１８の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１５４】
まずＳ１５０１において、ＣＰＵ２００１は、子機からのエラーログ格納要求を受信したかを判定する。受信した場合は、Ｓ１４０１へ進み、図１３のフローチャートで説明した処理を実施する。エラーログ格納要求を延期する場合に、図１３のフローチャートでは、Ｓ１４１２で子機へ再送要求を行っていたが、本フローチャートでは、Ｓ１５０２へ進む。Ｓ１５０２において、ＣＰＵ２００１は、エラーログ書込み待ちリストに当該子機の情報を追加する。
【０１５５】
Ｓ１５０１で、親機６０１が、エラーログ格納要求を受信していない場合は、Ｓ１５０３へ進む。Ｓ１５０３において、ＣＰＵ２００１は、親機６０１自身が複合機としての機能を実行しておらず、自身のジョブログ６１０から使用の集中が予想される時間帯でないかを判定する。Ｎｏの場合、即ち親機６０１が機能を実行しているか、或いは使用の集中が予想される時間帯であれば、終了する。Ｙｅｓの場合、即ち親機６０１で機能も実行されていないし、使用が集中されることも予想されないときは、Ｓ１５０４へ進む。
【０１５６】
Ｓ１５０４において、ＣＰＵ２００１は、エラーリスト書込み待ちリストを確認して、空であれば終了する。空でなければ、Ｓ１５０５へ進む。Ｓ１５０５において、ＣＰＵ２００１は、エラーログ書込み待ちリストに予め定められた一定回数以上延期された子機があるかを判定する。あればＳ１５０７へ進み、無ければＳ１５０６へ進む。
【０１５７】
Ｓ１５０６において、ＣＰＵ２００１は、エラーログ書込み待ちリスト中で優先度が一番高い子機を選択して、Ｓ１５１０へ進む。なお、このとき同一優先度の複数の子機があった場合は、１つを選択する。選択の仕方は、例えば、最初に見つかったものであっても構わない。或いは、該当する子機の中で一番最初にエラーログ格納要求があったものでも構わない。或いは、延期回数が一番多いものでも構わないし、ここに挙げた以外の方法でも１つを選択する方法であれば構わない。
【０１５８】
Ｓ１５０７において、ＣＰＵ２００１は、エラーログ書込みリスト中で、エラーログ格納要求の延期回数が一番多い子機を選択する。次のＳ１５０８において、ＣＰＵ２００１は、Ｓ１５０７で選択した子機が複数あるか判定する。１つだけなら、Ｓ１５１０へ進み、複数あれば、Ｓ１５０９へ進む。
【０１５９】
Ｓ１５０９において、ＣＰＵ２００１は、Ｓ１５０７で選択された複数の子機の優先度が一番高いものを選択する。このとき、優先度が同一のものが複数あった場合は、先にＳ１５０６で説明したような方法で１つの子機を選択する。Ｓ１５１０において、ＣＰＵ２００１は、親機６０１が選択した子機のエラーログを取得して、Ｓ１４１４へ進む。
【０１６０】
Ｓ１４１４において、ＣＰＵ２００１が、当該子機のエラーログを親機６０１に書込んだ後、Ｓ１５１１へ進む。Ｓ１５１１において、ＣＰＵ２００１は、エラーログ書込み待ちリストから当該子機の項目を削除して、終了する。なお、Ｓ１５０１でＹｅｓの場合は、エラーログ書込み待ちリストでなく、子機から直接要求のあったエラーログを書込む場合となる。このときに、当該子機がエラーログ書込み待ちリストになければ、当然ながらＳ１５１１では、何も処理しない。
【０１６１】
＜第２の実施の形態に係る利点＞
第２の実施の形態では、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに子機のエラーログを取得することができる。即ち、親機６０１は、エラーログ格納要求が延期された回数の多い子機のエラーログ、或いは高い優先度の子機のエラーログを、親機６０１自身の処理が行われていない合間に取得しに行くことができ、効率的なエラーログ書込み処理を行うことができる。
【０１６２】
［第３の実施の形態］
第３の実施の形態においても、エラーログ格納要求を延期した場合には親機６０１が都合が良いときに子機のエラーログを取得する点において第２の実施の形態と同様であるが、その取得の方法が異なる。
【０１６３】
即ち、第３の実施の形態では、親機６０１自身が複合機としての機能を実行しておらず、自身のジョブログ６１０から使用の集中が予想される時間帯でない場合に、エラーログ書込み待ちリスト中の子機の優先度を補正する。そして、補正された優先度が最も高いの子機のエラーログを取得するような方法を採る。
【０１６４】
＜優先度補正方法＞
以下、本実施の形態における優先度補正方法について説明する。
【０１６５】
例えば、エラーログ格納要求の回数による補正値を
【０１６６】
とすると、子機６０３の補正値は、γ＝１５×３＝４５となり、補正値を優先度３５に加えて、８０となる。一方、子機６０５の補正値は、γ＝１５×１＝１５となり、補正値を優先度６５に加えて、９５となる。子機６０５の方が、エラーログ格納要求の回数が少ないが、補正された優先度が大きいため、親機６０１は、子機６０５のエラーログを取得する。
【０１６７】
また、待ち時間に応じて優先度を変えるように補正してもよい。例えば、現時点から待ち時間の分単位の経過時間を求めて、それを
【０１６８】
として、子機６０２〜６０５の優先度を補正する。例えば、現在の時刻を１４時丁度とすると、図１５のエラーログ書込み待ちリストにおいて、子機６０４は、１５６分待ち、子機６０２は、５０分待ちとなる。但し、秒単位は切り捨てとする。すると、子機６０４の補正値は、ε＝１５６×０．５＝７８、子機６０２の補正値は、ε＝５０×０．５＝２５となる。したがって子機６０４、６０２の優先度が６５、１００であるので、補正後の優先度は、それぞれ１４３と１２５となって、親機６０１は、子機６０４のエラーログを取得する。
【０１６９】
また、複数の同一子機のエラーログ書込み待ちがあるときは、例えば、一番長い間待っているものにするなどの方法がある。
【０１７０】
いくつかの優先度の補正方法の例を説明したが、これらの補正方法を組み合わせて優先度を補正するようにしても構わない。また、ある一定の時間内に特定の子機からのエラーログ格納要求が一定回数以上あったときは、当該子機の優先度を上げるようにしてもよい。
【０１７１】
＜エラーログ取得決定処理の流れ＞
次に、親機６０１が、補正された優先度を用いて、エラーログ書込み待ちリスト中のどの子機のエラーログを取得するのかを決定する処理の流れについて、図１９及び図２０を参照して説明する。
【０１７２】
図１９及び図２０は、本発明の第３の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートであり、図１３、図１７及び図１８と同一処理の部分については、図１３、図１７及び図１８と同一符号を付与して、その説明は割愛する。図１９及び図２０の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１７３】
Ｓ１９０１は、親機６０１が処理を実行しておらず、使用の集中も予想されないときに、子機からエラーログ格納要求がなく、且つエラーログ書込み待ちリストが空で無いときに実行されるステップである。Ｓ１９０１において、ＣＰＵ２００１は、エラーログ書込み待ちリスト中の子機に対して、上述した優先度補正方法を用いて優先度の補正を行い、Ｓ１９０２へ進む。
【０１７４】
Ｓ１９０２において、ＣＰＵ２００１は、補正された優先度の中で、優先度が最も高い子機を選択して、Ｓ１５１０へ進む。同一の優先度を持つ子機が複数あった場合には、先にＳ１５０６で説明したような方法で１つを選択する。
【０１７５】
＜第３の実施の形態に係る利点＞
第２の実施の形態によれば、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに子機のエラーログを取得することができる。即ち、親機６０１は、エラーログ格納要求が延期された子機の中で高い優先度の子機のエラーログを、親機６０１自身の処理が行われていない合間に取得しに行くことができ、効率的なエラーログ書込み処理を行うことができる。
【０１７６】
［変形例］
本発明は、上記した各実施の形態に限定されず、種々の変形が可能であり、その変形例としては例えば次のようなものがある。
【０１７７】
（１）上記した第２の実施の形態または第３の実施の形態は、第１の実施の形態で説明した再送指示を行う方式との複合でも構わない。つまり、エラーログ格納要求を延期する場合に、当該子機に対して再送指示をすると同時にエラーログ書込み待ちリストにも当該子機の情報を追加する。子機が再送もしてくるし、再送が行われる前に親機６０１が処理を実行していない且つ使用の集中が予想されない場合は、親機６０１が、エラーログ書込み待ちリスト中の子機にエラーログを取りに行くようにする。このような形態は、図１３、図１７、図１８、図１９及び図２０のフローチャートの組み合わせで実現できることは容易に分かる。
【０１７８】
（２）子機のエラーログ格納要求が親機６０１に拒否されたときに、子機側では、ログ用メモリ２１００がメモリフルである場合に、緊急用フラグを立てて、親機６０１に対して、優先的にエラーログを書込むよう依頼することを第１の実施の形態で説明した。このように緊急用フラグを設けずに、子機で、エラーログが取得されるまで、子機の動作できないように操作パネルなどをロックしてしまう仕組みとしてもよい。
【０１７９】
（３）また、子機側の処理として、次のような処理を行ってもよい。即ち、同一のエラーが発生している場合に、親機６０１がエラーログ格納要求を何度も拒否していると、同じようなエラーログが何度も子機側のログ用メモリ２１００に記録されて、すぐにログ用メモリ２１００がフルになってしまう可能性がある。そこで、同じエラーが発生して、既にログ用メモリ２１００に記録されている場合には、同一のエラーログとして、エラーログのレベルを下げて、簡略化したエラーログをログ用メモリ２１００に書込む。これによって、ログ用メモリ２１００がメモリフルになるのをなるべく抑えるようにしてもよい。
【０１８０】
或いは、同じエラーが発生している場合は、通常よりもエラーログのレベルを上げて、詳細なエラーログを取得し、ログ用メモリ２１００に書込んで、エラーの原因を究明し易くする。同時に、ログ用メモリ２１００のメモリフルを早期に発生させて、緊急用フラグを立てたエラーログ格納要求を送出し易くして、エラーログをなるべく早く親機６０１に書込ませるようにしてもよい。
【０１８１】
（４）本実施の形態において画像形成装置として説明しているが、サービスを提供する機能を有する装置であれば、本発明の適用は画像形成装置に限定されない。例えば、サーバ機器にスキャナ、プリンタ等を接続して、画像形成装置と同等の機能を有するようにした構成を画像形成装置と読み換えても構わない。
【０１８２】
（５）本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【０１８３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１８４】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【０１８５】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１８６】
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【図面の簡単な説明】
【０１８７】
【図１】実施の形態に係る処理装置を含む画像形成システムの全体の構成を示すブロック図である。
【図２】図１中の画像形成装置の構成を示すブロック図である。
【図３】ジョブログの一例を示す表形式図である。
【図４】エラー時の画像形成装置における動作状況を記録したエラーログの一例を示す図である。
【図５】親機のログ収集を示す概念図である。
【図６】子機のジョブログの一例を示す表形式図である。
【図７】優先度テーブルの一例を示す図である。
【図８】ジョブログを収集して優先度テーブルを更新する処理の流れを示すフローチャートである。
【図９】親機のエラーログ受け付け可否判定動作を説明する概念図である。
【図１０】親機自身のジョブログの一例を示す表形式図である。
【図１１】優先度テーブルの一例を示す図である。
【図１２】優先度の閾値と各種補正値の一例を示す図である。
【図１３】第１の実施の形態におけるエラーログ受け付けの可否判定処理の流れを示すフローチャートである。
【図１４】エラーログ格納要求を延期した場合の動作を説明するための概念図である。
【図１５】エラーログ書込み待ちリストの一例を示す図である。
【図１６】エラーログ書込み待ちリストの一例を示す図である。
【図１７】第２の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートである。
【図１８】図１７の続きのフローチャートである。
【図１９】第３の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートである。
【図２０】図１９の続きのフローチャートである。
【符号の説明】
【０１８８】
６０１ 親機（画像形成装置）
６０２〜６０５ 子機（画像形成装置）
２００１ ＣＰＵ
２００２ ＲＡＭ
２００３ ＲＯＭ
２００４ ＨＤＤ
２０１２ 操作部
２１００ ログ用メモリ
【技術分野】
【０００１】
本発明は、ログを収集する機能を備えた複写機等の処理装置及びその制御方法、並びに前記制御方法を実現するための制御プログラムに関するものである。
【背景技術】
【０００２】
オフィス内で、専用のサーバ機器を置かずに、画像形成装置をサーバとして利用して、専用サーバ機器レスで運用できる環境が広まりつつある。このような状況において、ＣＰＵの速度が速かったり、メモリを多く搭載しているなど性能が高い画像形成装置（親機）が、サーバの機能を有し、前述した複数のネットワーク上の画像形成装置（子機）を管理するデバイス管理の機能を持つようになってきている。
【０００３】
このような親機による子機のデバイス管理においては、子機からのログの収集が行われる。ログには、印刷枚数など通常のログと、エラーが発生したときに障害を特定するためのエラーログがある。特にエラーログは、障害特定のために多くの情報を含むのでデータのサイズが大きい。
【０００４】
子機は、ログを記憶する記憶領域のサイズが小さいため、記憶領域がメモリフルになると、ログが古いものから順番に削除され、エラーログを多く格納することができない。そこで、子機は、格納しきれないログが消えてしまうことを回避するために、エラーが発生したときにはエラーログを逐一親機へ送る必要がある。
【０００５】
しかし、親機が複数の子機からエラーログのような大きなサイズのログを無条件に受け付けてしまうと、親機自身のパフォーマンスが劣化する可能性がある。この問題に対応するために子機側のメモリ容量を増やすことは、コスト面から難しい。そこで、一定容量のエラーログ用のメモリしかなくても効率よくエラーログの収集を行える技術が求められていた。
【０００６】
このようなログ収集を行う従来の技術として、次のようなものがあった（例えば特許文献１参照）。即ち、複数の子機と、ネットワークを介してそれらの子機のログを収集する親機から成る。子機の優先度が定義された優先度定義テーブルがあり、子機に格納されたログの量が所定量に達した場合に、当該子機の優先度が予め設定された優先度より高い場合にのみログを収集する。また、情報に優先度を付けて、子機に格納されたログの量が所定量に達した場合に、情報の優先度が予め設定された優先度より高い場合にのみログを収集する。
【特許文献１】特開２００１−１４７８３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来の技術は、個々の子機或いは情報に対して予め設定された固定的な優先度を基にして、指定した優先度以上の場合のみにログ収集を行うものである。そのため、子機の稼動状況に応じて自動的に優先度を設定することができない。また、親機自身がパフォーマンスを落とさずに機能を実行しなければならないような状況において、親機自身の状態に応じて動的にログの受け入れの可否を決定することができない。
【０００８】
このように上記従来技術では、未だ十分効率よくエラーログの収集を行うことができなかった。
【０００９】
本発明は上記従来の問題点に鑑み、処理装置自身のパフォーマンスを低下させることなく、外部処理装置から効率的にエラーログの受け付けを行うことができる処理装置及びその制御方法、並びに制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明の処理装置は、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置において、前記外部処理装置から送信された前記第１のログを受信する受信手段と、前記受信手段によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出手段と、前記算出手段によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定手段とを備えたことを特徴とする。
【００１１】
本発明の処理装置の制御方法は、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法であって、前記外部処理装置から送信された前記第１のログを受信する受信工程と、前記受信工程によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出工程と、前記算出工程によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定工程とを備えたことを特徴とする。
【００１２】
本発明の制御プログラムは、使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、前記外部処理装置から送信された前記第１のログを受信する受信ステップと、前記受信ステップによって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出ステップと、前記算出ステップによって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定ステップとを備えたことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、処理装置自身のパフォーマンスを低下させることなく、外部処理装置から効率的にエラーログの受け付けを行うことが可能になる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１５】
［第１の実施の形態］
＜画像形成システムの全体構成＞
図１は、本発明の実施の形態に係る処理装置を含む画像形成システムの全体の構成を示すブロック図である。
【００１６】
この画像形成システムは、ＬＡＮ ２０１１に接続された画像形成装置６０１を有している。画像形成装置６０１は処理装置の一例であり、画像入力デバイスであるスキャナ部２０７０、画像出力デバイスであるプリンタ部２０９５、コントロールユニット２０００、及びユーザインターフェースである操作部２０１２から構成される。
【００１７】
スキャナ部２０７０、プリンタ部２０９５、及び操作部２０１２は、それぞれコントロールユニット２０００に接続され、コントロールユニット２０００は、ＬＡＮ ２０１１などのネットワーク伝送手段、公衆回線等に接続されている。公衆回線からはカラー画像送信を含むＧ３、Ｇ４ファックスによる送受信が可能である。
【００１８】
また、ＬＡＮ ２０１１には、外部処理装置の一例である他の画像形成装置６０２〜６０５のほか、パーソナルコンピュータ（以下、単にＰＣと記す）１４０も接続されている。他の画像形成装置６０２〜６０５も、画像形成装置６０１と同様の機器構成を持つ。
【００１９】
なお、図１に示す画像形成装置は、プリンタ機能、スキャナ機能の両方を有するように記載しているが、例えば、プリンタ機能だけを持つような画像形成装置やスキャナ機能やファックス機能だけを持つ画像形成装置でも構わない。
【００２０】
＜画像形成装置の構成＞
図２は、図１中の画像形成装置の構成を示すブロック図である。
【００２１】
コントロールユニット２０００は、画像入力デバイスであるスキャナ２０７０や画像出力デバイスであるプリンタ２０９５と接続しこれらの動作を制御する。また、一方ではＬＡＮ２０１１や公衆回線（ＷＡＮ）２０５１と接続することで、画像情報やデバイス情報の入出力を行うためのコントローラである。
【００２２】
コントロールユニット２０００は、システムバス２００７上に、ＣＰＵ２００１、ＲＡＭ２００２、ＲＯＭ２００３、及びＨＤＤ２００４を配置している。
【００２３】
ＣＰＵ２００１は、装置全体の動作を制御する。ＲＡＭ２００２は、ＣＰＵ２００１が動作するためのシステムワークメモリであり、画像データを一時記憶するための画像メモリでもある。また、オペレーティングシステムやシステムソフトウェア、アプリケーションソフトウェアなどのプログラムを動作させるために配置されることもある。ＲＯＭ２００３はブートＲＯＭであり、システムのブートプログラムが格納されている。また、システムプログラムやアプリケーションプログラムが格納されている場合もある。ＨＤＤ２００４はハードディスクドライブで、システムソフトウェア、アプリケーションソフトウェア、画像データ等を格納する。また、図示していないが、小型の画像形成装置では、ＨＤＤ２００４を搭載せずにシステムソフトウェア、アプリケーションソフトウェア等をＲＯＭ２００３に格納して、ハードディスクレスの構成もある。
【００２４】
さらに、コントロールユニット２０００は、システムバス２００７上に、ログ用メモリ２１００、操作部Ｉ／Ｆ２００６、ネットワーク部２０１０、及びモデム２０５０を配置している。
【００２５】
ログ用メモリ２１００は、ログを格納するためのメモリであり、エラーログや稼動状況などの各種ログが格納される。なお、ログの内容については、後述する。また、ログ用メモリ２１００を用意せずに、ＲＡＭ２００２の一部をログ用メモリとして利用するような仕組みとしてもよい。操作部Ｉ／Ｆ２００６は、操作部（ＵＩ）２０１２とのインターフェース部であり、操作部２０１２に表示する画像データを操作部２０１２に対して出力する。また、操作部２０１２から操作者が入力した情報をＣＰＵ２００１に伝える役割をする。ネットワーク部２０１０は、ＬＡＮ２０１１に接続して情報の入出力を行う。モデム２０５０は、公衆回線２０５１に接続して画像情報の入出力を行う。
【００２６】
イメージバスＩ／Ｆ２００５は、システムバス２００７と画像データを高速で転送する画像バス２００８を接続し、データ構造を変換するバスブリッジである。画像バス２００８は、ＰＣＩバスなどで構成される。
【００２７】
画像バス２００８上には、ラスターイメージプロセッサ（ＲＩＰ）２０６０、デバイスＩ／Ｆ部２０２０、スキャナ画像処理部２０８０、及びプリンタ画像処理部２０９０が配置されている。
【００２８】
ラスターイメージプロセッサ（ＲＩＰ）２０６０は、ＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部２０２０は、スキャナ２０７０やプリンタ２０９５とコントローラ２０００とを接続し、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２０８０は、入力画像データに対し補正、加工、編集を行う。また入力された画像がカラー原稿であるか或いは白黒原稿かを画像の彩度信号から判断しその結果を保持する機能を有する。プリンタ画像処理部２０９０は、出力画像データに対し補正、加工、編集を行う。
【００２９】
また、画像バス２００８上には、画像回転部２０３０、解像度変換部２０３１、色空間変換部２０３２、及び階調変換部２０３３も配置されている。
【００３０】
画像回転部２０３０は、スキャナ画像処理部２０８０と連携して、スキャナ２０７０からの画像読み込みを行う。解像度変換部２０３１は、画像の解像度を変換する処理を行い、色空間変換部２０３２はマトリクス演算により、画像の色空間を変換する処理を行う。階調変換部２０３３は、画像の階調を変換する処理を行い、画像圧縮部２０４０は、画像の圧縮伸長の処理を行う。
【００３１】
上記の説明においては、画像回転などの画像処理は、画像バス２００８に接続されたデバイスで行っているが、ＨＤＤ２００４やＲＯＭ２００３に画像処理のソフトウェアを格納しておき、ＲＡＭ２００２に読み込んで、ＣＰＵ２００１で実行するようにしてもよい。なお、実行するソフトウェアは、画像処理に限らず、画像形成装置で必要となる他の処理でも構わないのは、いうまでもない。また、ＲＯＭ２００３に格納されたプログラムは、ＲＡＭ２００２に読み込まずに実行してもよい。
【００３２】
また、図２のＨＤＤ２００４において、ハードディスク内には、システムソフトウェアや、アプリケーションソフトウェア、画像データを格納すると記載した。しかし、これらに限らず、画像管理のためのデータなどの画像以外の一般データファイルや画像形成装置で管理するデータを格納することができる。画像形成装置で管理するデータとしては、例えば、どの利用者が、いつ、どのような機能を利用したかを記録するジョブログなどがある。
【００３３】
上記構成の画像形成システムにおいて、画像形成装置６０１が、ログ収集のサーバ機能を有する親機の画像形成装置である。また、画像形成装置６０２、６０３、６０４、６０５は、画像形成装置６０１にログが収集される管理対象となる子機の画像形成装置であるものとする。そして、以下、親機である画像形成装置を単に親機と記し、子機である画像形成装置を単に子機と記す。なお、子機６０２、６０３、６０４、６０５は、ＨＤＤ２００４を搭載していなかったり、メモリ容量が少ない場合がある。
【００３４】
＜本実施の形態におけるログ＞
次に、本実施の形態におけるログについて説明する。
【００３５】
ログは２種類あり、１つは、どの利用者が、いつ、どれだけ（使用頻度）、どの機能を利用したかを表すジョブログである。もう一つは、エラーが発生したときに障害を特定するためのエラーログである。エラーログは、エラーが発生したときにそのエラーを解析するために必要となる内部モジュールの呼び出しシーケンス情報や、エラー発生時点でのメモリのダンプ結果情報などを含む。エラーログのサイズは、このような情報を含むため大きいものとなる。ジョブログは第１のログの一例であり、エラーログは第２のログの一例である。
【００３６】
（Ａ）ログの一例
（ｉ）ジョブログの一例
ジョブログの一例を図３を参照して説明する。図３は、ジョブログの一例を示す表形式図である。
【００３７】
図３に示すように、ジョブログには、ジョブの処理が行われた日付の情報５０１、時間の情報５０２、誰が処理を実行したかを表すユーザ識別子５０３が記録されている。更に、どのような処理を実行したのかを示すタイプ情報５０４が記載される。タイプ情報５０４には、例えば、ＰＣ１４０などからアプリケーションの印刷を実行したＰｒｉｎｔや、画像形成装置の複写機能（以下、コピー機能と記す）を実行したＣｏｐｙ、スキャンして画像を読み取るＳｃａｎ、ファクシミリ送信を行うＦＡＸなどがある。
【００３８】
また、ジョブログには、処理に要したページ数情報５０５が記録されている。さらに、そのページ数の中で、白黒で処理したページ数情報５０６、カラーで処理したページ数情報５０７、及び両面処理されたページ数情報５０８などが記録されている。
【００３９】
例えば、図３における５０９の事項では、ユーザ「５０２５１」が、「２００７年１０月５日８時２５分４１秒」に、コピー機能を実行したことを表している。そのときに５４枚コピーを行い、そのうち３７枚が白黒、１７枚がカラーであり、２７枚が両面処理されていることが記録されている。その他も同様である。
【００４０】
本実施の形態では、ジョブログに含まれる情報として９種類の項目（５０１〜５０９）を挙げているが、この限りでなく他の項目を含んでよいのは勿論のこと、この中のいくつかの項目だけを選択してジョブログとしても構わない。
【００４１】
（ｉｉ）エラーログの一例
エラーログの一例を図４を参照して説明する。図４は、エラー時の画像形成装置における動作状況を記録したエラーログの一例を示す図である。
【００４２】
エラーログのヘッダー部２４０２は、画像形成装置の機種名「ＩＲＸＸＸＸ」、システムソフトウェアのバージョン「ＣＯＮＴ ｖｅｒ０．４２」、及びエラーログ情報取得時の日付などで構成される。
【００４３】
動作手順は、図４における２４０３、２４０５などに示されるように、時間、ブロックの場所、動作内容、などが読み取れる。これらの情報を基に、エラー発生の原因などを解析することができる。また、エラーレベルによって、例えば、簡易的な情報（２４０１）や、詳細な情報（２４０４）など情報量の異なるエラーログの生成が行える。
【００４４】
（Ｂ）ログの収集
ログ収集について、具体的に図５を参照して説明する。図５は、親機６０１によって行われるログ収集を示す概念図である。
【００４５】
子機６０２〜６０５は、ログを親機６０１へ送付する。なお、このときにログ自体を親機６０１へ送付するのでなく、ログ送付依頼を先へ送付して、送付が許可されたときにログ本体を送るような仕組みとしてもよい。図５の例では、子機６０２〜６０５が、それぞれログ６０６、６０７、６０８、６０９を親機６０１へ送付している。この例では、子機を４台としたが、子機が４台に限定されるものでない。
【００４６】
また、親機６０１自体も画像形成装置として機能するため、ログを持っているので、親機６０１も自身のログ６１０を収集することになる。
【００４７】
なお、図５の例では、各子機６０２〜６０５から親機６０１へログを送信しているが、親機６０１が、子機６０２〜６０５からログを収集するような仕組みとしても構わない。例えば、前述したジョブログの場合には、親機６０１が定期的に子機６０２〜６０５に対してログを収集するようにしてもよい。
【００４８】
子機を親機の管理対象にする設定の方法は、例えば、親機６０１に予め登録しておく方法や、子機が新規にネットワークに接続された場合に、ブロードキャストで自身の存在を親機に通知するなどの公知の方法を用いる。
【００４９】
＜親機６０１の動作＞
以下、親機６０１の動作について説明する。
【００５０】
親機６０１は、１台以上の子機を管理するための、管理機能を持ち、ログを収集するサーバとして動作する。なお、本実施の形態では、管理機能として、ログ収集機能のみしか記載していないが、その他の管理機能を有していても構わない。
【００５１】
ログとしては、前述したように、ジョブログとエラーログの収集を行う。ジョブログは、定期的に収集されており、定められた時間になると、親機６０１が、親機６０１のネットワーク部２０１０を用いてＬＡＮ２０１１を経由して管理対象の子機６０２〜６０５に接続する。
【００５２】
子機６０２〜６０５では、ログ用メモリ２１００に格納されているジョブログをネットワーク部２０１０を用いてＬＡＮ２０１１を経由して親機６０１に送信する。親機６０１は、受信したジョブログをＨＤＤ２００４の所定の格納場所に書込む。親機６０１は、管理対象の全ての子機６０２〜６０５に対して、同様にしてジョブログの収集を行い、ＨＤＤ２００４に書込む。更には、親機６０１自身のジョブログも、親機６０１のログ用メモリ２１００から読み出し、ＨＤＤ２００４の所定の格納場所に書込む。
【００５３】
このようにして、定期的に収集された全ての管理対象の子機６０２〜６０５と親機６０１自身のジョブログが、親機６０１のＨＤＤ２００４に保存されている。
【００５４】
（Ａ）ジョブログを収集したときの動作
（ｉ）各子機の稼動状況を求める
子機６０２〜６０５からジョブログを収集したときに、親機６０１は、各子機６０２〜６０５の稼動状況を求める。以下、図５及び図６を参照して、収集されたジョブログから稼動状況を求める一例について説明する。４台の子機６０２〜６０５のジョブログの一例を示す表形式図である。
【００５５】
図６における７０１、７０２、７０３、７０４に示すものは、それぞれ４台の子機６０２、６０３、６０４、６０５から取得された親機６０１のＨＤＤ２００４に格納されているジョブログである。ここで、本実施の形態では、説明を簡単にするために、１日分のジョブログのみを記載している。当然であるが、親機６０１のＨＤＤ２００４に格納されるジョブログは、１日分だけなく、複数日分格納されていても構わない。また、そのような場合は、稼動状況を求めるために、格納される子機のジョブログを１日分（或いは、所定の日数分）だけ用いるようになっていても構わない。
【００５６】
子機の稼動状況の求め方は、例えば、ユーザが子機を利用した回数で判断する。７０１のジョブログから、子機６０２は、「２００７年１０月５日の８時２５分４１秒」、「１１時２１分４３秒」、「１４時１１分５２秒」、「１５時１２分３２秒」、「１７時４５分５３秒」、「１９時３６分２５秒」の合計６回、利用されていることが分かる。同様に、７０２のジョブログから子機６０３は２回、７０３のジョブログから子機６０４は２回、７０４のジョブログから子機６０５は４回の利用がそれぞれあったことが分かる。
【００５７】
（ｉｉ）稼動状況から優先度を算出
親機は、ジョブログから求められた稼動状況に基づいて、子機の優先度を算出する。優先度の算出として、例えば、各利用回数を最大の利用回数で割って、１００を掛けるようなものがある。子機６０２の場合は、
【００５８】
【数１】
【００５９】
となり、優先度は１００となる。同様に、子機６０３、６０４は、利用回数が２であるので、優先度が３３．３、子機６０５は、利用回数が４であるので、優先度が６６．７となる。
【００６０】
優先度の求め方は、このような算定式だけでなく、他の算定式でも構わないことはいうまでもない。また、利用回数で判定するだけでなく、例えば、合計処理枚数で判定するようにしてもよい。合計処理枚数は、子機６０２、６０３、６０４、６０５それぞれ２１５、２７，３７６、１４８となるので、先の算出式を用いれば、子機６０２の優先度は、
【００６１】
【数２】
【００６２】
となる。同様に、子機６０３、６０４、６０５の優先度は、それぞれ７．２、１００、３９．４となる。
【００６３】
また、処理の種別毎に重み付けを変えてもよい。例えば、ＰＣ１４０からアプリケーションの印刷を実行したＰｒｉｎｔの重み付けを１、画像形成装置のコピー機能を実行したＣｏｐｙの重み付けを１．３とする。また、スキャンして画像を読み取るＳｃａｎの重み付けを０．９、ファクシミリ送信を行うＦＡＸの重み付けを１．１とする。その結果、子機６０２、６０３、６０４、６０４の重み付け後の枚数は、それぞれ２６２．５、２８．２、４２１、１４９．８となるので、先の算出式を用いれば、子機６０２の優先度は、
【００６４】
【数３】
【００６５】
となる。同様に、子機６０３、６０４、６０５の優先度は、それぞれ６．７、１００、３５．６となる。
【００６６】
本実施の形態では、ジョブログの情報だけから優先度を求めているが、子機のスペック（例えば、単位時間処理枚数）やログ用メモリ容量などを基準として、優先度に重み付けをするようにしてもよい。例えば、単位時間処理枚数が予め定めた基準より少ない場合や、ログ用メモリ容量が予め定めた基準より少ない場合に、優先度を高くする重み付けを与えるようなことを行ってもよい。
【００６７】
（ｉｉｉ）優先度テーブルを更新
このようにして、求めた優先度で優先度テーブルを更新する。ここで、優先度テーブルの一例について、図７を参照して説明する。図７は、優先度テーブルの一例を示す図である。
【００６８】
図７に示すように、優先度テーブルは、子機を特定するフィールド８０１と、子機の優先度を表す優先度フィールド８０２から成る。
【００６９】
図７の例では、フィールド８０１には、子機を特定する名称が記載されている。なお、子機を特定する情報は、名称に限らず、例えばＩＰアドレスでなど、子機を一意に特定できる情報であればよい。ここで、図７中の８０３のデバイス名称Ａは、図５中の子機６０２を表す。同様に、８０４のデバイス名称Ｂは子機６０３、８０５のデバイス名称Ｃは子機６０４、８０６のデバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【００７０】
図７の優先度フィールド８０２には、先に説明した利用回数による優先度がデバイス名称Ａ〜Ｄに対応してそれぞれ記載されている。
【００７１】
なお、優先度テーブル自体の新規作成や、子機のフィールド追加や削除については、本発明の本質的なものでない。しかし、例えば、ジョブログとして親機６０１のＨＤＤ２００４に記録があるものを優先度テーブルのフィールド８０２に追加して、一定期間存在していないものは削除するような仕組みとしてもよい。
【００７２】
（ｉｖ）処理の流れ
次に、上述した、親機６０１が子機６０２〜６０５からジョブログを収集して優先度テーブルを更新する処理の流れについて、図８のフローチャートを参照して説明する。
【００７３】
図８は、ジョブログを収集して優先度テーブルを更新する処理の流れを示すフローチャートである。図８の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【００７４】
まずＳ９０１において、ＣＰＵ２００１は、各子機６０２〜６０５からジョブログを収集する。次のＳ９０２では、ＣＰＵ２００１は、Ｓ９０１で収集した各子機６０２〜６０５のジョブログから各子機６０２〜６０５の稼動状況を求める。稼動状況とは、例えば子機６０２において利用回数であれば、処理が行われた回数である「６」がジョブログ７０１から求められる。また、合計処理枚数を稼動状況とするのであれば、ジョブログ７０１の各処理の処理枚数を合計して、子機６０２の稼動状況は、「２１５」とする。
【００７５】
Ｓ９０３において、ＣＰＵ２００１は、各子機６０２〜６０５の稼動状況から優先度を求める。これは、例えば、先の説明では、各稼動状況の値を全ての子機６０２〜６０５の稼動状況の最大値で割ったものに１００を掛けることで優先度を求めていた。本実施の形態で説明した、Ｓ９０２、Ｓ９０３での稼動状況、及び優先度の求め方は一例であり、他の算出の仕方でも構わない。
【００７６】
Ｓ９０４において、ＣＰＵ２００１は、優先度テーブルの各子機６０２〜６０５の優先度をＳ９０３で求められた優先度に置き換える。
【００７７】
（Ｂ）エラーログが送付されたときの動作
次に、子機６０２〜６０５から親機６０１に対してエラーログが送付されたときの親機６０１の動作について説明する。
【００７８】
（ｉ）エラーログ受け付けの可否判定の詳細
以下、子機６０２〜６０５からエラーログが送付されたときに、親機６０１がエラーログを受け付けるかどうかを判定する動作について、図９を参照して具体的に説明する。 図９は、親機６０１のエラーログ受け付け可否判定動作を説明する概念図であり、図５と共通する要素には同一符号を付与する。
【００７９】
・親機６０１が処理を行っていない場合
まず、親機６０１が処理を行っていない場合について説明する。この場合、エラーログの格納要求１３０１が子機６０２から親機６０１へ送付されると、親機６０１は、自身のジョブログ６１０から、使用の集中が予想される時間であるかどうかを判断する。
【００８０】
図１０は、親機６０１自身のジョブログ６１０の一例を示す表形式図である。
【００８１】
このジョブログ６１０は、１時間毎に８時台（図１０の１００１）、９時台（１００２）、１０時台（１００３）、１１時台（１１０４）、１５時台（１００５）、１７時台（１００６）、及び１９時台（１００７）と分割されている。
【００８２】
この分割された時間の中で、稼動状況を求める。稼動状況の求め方は、先に示した利用回数であったり、合計処理枚数などである。この求めた稼動状況に対して閾値を設けて、それ以上の場合は、使用の集中が予想される時間と判断する。
【００８３】
例えば、稼動状況を利用回数として、閾値を３回とすると、図１０の例では、８時台、９時台にエラーログの格納要求が子機６０２からあった場合は、エラーログの書込みを延期する。
【００８４】
本実施の形態では、１日のジョブログとしているが、親機６０１自身のジョブログ６１０の格納がより多くあった場合には、１日だけに限らず、日にち毎に各時間の稼動状況を求めて、更に各時間の平均の稼動状況を算出して、それを利用するようにしてもよい。
【００８５】
また、本実施の形態のように１時間単位とは限らず、例えば、午前、午後で分けるとか、９時以前、９時から１２時、１２時から１３時、１３時から１７時、１７時以降のようにオフィスの勤務状況に合わせたりしてもよい。更には、時間で区切るのでなく、エラーログの格納要求時点から１時間以内などのようにしてもよい。
【００８６】
親機６０１の使用が予想されるときに、子機６０２からのエラーログ格納要求を延期すると記載した。しかし、エラーログ自体が致命的なエラーであったり、子機６０２内のエラーログ格納用のログ用メモリ２１００がメモリフルの状態になっている（或いは、メモリフルになりかけている）ときなど緊急にエラーログを格納する必要がある。
【００８７】
そのような場合には、次の処理を行う。図示しないが、エラーログ格納要求内に設けられた緊急用のフラグが立つことで、親機６０１は、エラーログの書込みが必要なことであると判断する。親機６０１は、エラーログの送信を子機６０２へ要求して、子機６０２のエラーログを親機６０１のＨＤＤ２００４へ書込む。
【００８８】
また、例えば、子機６０２で紙詰まり（ジャム）が頻発する場合などは、エラーログもすぐに埋まってしまうので、次の処理を行う。予め定めた回数以上のジャムが発生すると、子機６０２で、先の緊急用フラグを立ててエラーログの格納要求を送信する。これにより、エラーログによってログ用メモリ２１００のメモリフルが発生する前に親機６０１にエラーログを書込むことができる。
【００８９】
エラーログを親機６０１６０２へ書込むことができた子機６０２は、ログ用メモリ２１００をクリアする。なお、ログ用メモリ２１００にエラーログ以外のログが格納されている場合は、格納したエラーログだけを削除する。
【００９０】
なお、本実施の形態の説明では、エラーログの格納要求をまず親機６０１に送信しているが、子機６０２からダイレクトにエラーログを親機６０１へ送信してもよい。また、親機６０１において機能が実行されていない状態で使用の集中が予想されるときに、上記の緊急用フラグが立っていない場合であっても、次のような子機からのエラーログの格納要求を受け付けるようにしても構わない。即ち、子機の優先度に基づいて、一定の閾値以上の優先度を持つ子機からのエラーログ格納要求を受け付けるようにしても構わない。
【００９１】
・親機６０１が機能を実行している場合
次に、親機６０１が機能を実行している場合について具体的に説明する。この場合、先に説明した優先度テーブルから取得した子機の優先度を親機６０１の状態によって補正し、補正された優先度が予め定めた閾値以上であれば、親機６０１は、エラーログの書込みを行う。
【００９２】
ここで、説明のために、図１１の優先度テーブルと、図１２の閾値及び各種補正値を用いることにする。図１１は、優先度テーブルの一例を示す図であり、図１２（ａ），（ｂ）は、優先度の閾値と各種補正値の一例を示す図である。
【００９３】
図１１中の１１０１に示すデバイス名称Ａは、図５中の子機６０２を表す。同様に、１１０２に示すデバイス名称Ｂは子機６０３、１１０３に示すデバイス名称Ｃは子機６０４、１１０４に示すデバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【００９４】
図１２（ａ）において、閾値θは、補正された優先度がこの値以上であれば、エラーログの書込みを認めるという境界値である。再送用補正値πについては後で説明する。パネル操作補正値ρは、親機６０１の操作パネル（操作部２０１２）を使用しているときに優先度を補正するための値である。即ち、操作パネルが利用されているということは、親機６０１の前で利用者が使っているため、親機６０１の処理をより優先させるために優先度を補正する。
【００９５】
図１２（ｂ）に示すジョブ種類別補正テーブルは、親機６０１が処理中のジョブの種類によって優先度の補正を行うためのものである。これは、例えば、カラーデータの処理を行うときには白黒データに比べてデータ量が多いため、親機６０１のＣＰＵ２００１に負担が大きいなど、ジョブの種類に応じて優先度を変えるためのテーブルである。
【００９６】
このジョブ種類別補正テーブルは、ジョブ種類を表すフィールド１２０５と、その補正値を表すフィールド１２０６から成る。図１２（ｂ）の例では、カラージョブに対する補正値が−１５、白黒ジョブの補正値が−５、ＦＡＸジョブの補正値が−２０、プリントジョブの補正値が−１０である。また、１枚の用紙に複数ページを面付けして印刷するＮｉｎ１のジョブに対する補正値は−５である。
【００９７】
なお、図１２（ｂ）に示すジョブ種類別補正テーブルは、一例であり、ジョブ種類はこれらに限定されることはないし、これらを含まなくてもよい。
【００９８】
以下、ＪＣＴ（Ｘ）は、ジョブ種類Ｘに対する補正値を表すものとする。例えば、ＪＣＴ（ＦＡＸ）は、ジョブ種類別補正テーブルから−２０となる。なお、Ｘの部分は１つに限らず複数併記することができ、その場合は、補正値の合計となる。例えば、ＪＣＴ（Ｃｏｌｏｒ，Ｎｉｎ１）は、Ｃｏｌｏｒの補正値−１５とＮｉｎ１の補正値−５の合計−２０となる。
【００９９】
子機の優先度をαとすると、補正された優先度α’が、閾値θ以上であればエラーログの書込みを親機６０１は行う。具体的に例を挙げて説明する。
【０１００】
子機６０２（図１１中のデバイス名称Ａ）からエラーログの格納要求が親機６０１に対して送られると、親機６０１は、優先度テーブルから当該子機６０２の優先度α６０２（＝１００）を取得する。この例では、１００である。
【０１０１】
このとき、親機６０１で操作パネルを利用してカラーコピーを実行している場合は、パネル操作補正値ρ＝−２０、カラーのジョブ補正値ＪＣＴ（Ｃｏｌｏｒ）＝−１５であるので、
となり、補正された優先度
は６５となり、閾値θ（＝７０）を下回っているため親機６０１にエラーログの格納は行われない。
【０１０２】
なお、先に説明したように、緊急時のエラーログについては、優先的に書込まれる。これは、以下の説明においても明記はしないが同様である。一方、同じく操作パネルを利用していても、白黒コピーを実行している場合は、白黒のジョブ補正値ＪＣＴ（ＢＷ）＝−５であるので、
【０１０３】
であり、閾値θを上回るので、親機６０１にエラーログは書込まれる。また、親機６０１の操作パネルを使わずにＰＣ１４０などからＦＡＸ送信されている場合は、ＦＡＸのジョブ補正値ＪＣＴ（ＦＡＸ）＝−２０であるので、
【０１０４】
となり、エラーログの格納要求を親機６０１は受け付けるが、親機６０１の操作パネルからＦＡＸ送信した場合では、パネル操作補正値ρが追加されるので、
【０１０５】
となり、エラーログの格納要求を親機６０１は受け付けない。
【０１０６】
更には、例えば、子機６０５（図１１中のデバイス名称Ｄ）は、優先度が８０である。パネル操作補正値が−２０であることから、親機６０１のパネル操作が行われている場合には、それだけで優先度が６０となり、エラーログの格納要求が受け付けられない。
【０１０７】
しかしながら、親機６０１にＰＣ１４０などからプリントジョブが送信されてきて、それを処理しているだけであれば、Ｐｒｉｎｔのジョブ補正値ＪＣＴ（Ｐｒｉｎｔ）＝−１０であるので、
【０１０８】
であり、閾値と同じ７０でエラーログ格納要求を親機６０１は受け付ける。
【０１０９】
なお、これまでの説明で用いた例は、各子機６０２〜６０５からの初回のエラーログ格納依頼とする。エラーログ格納依頼が再送された場合の処理については、後述する。
【０１１０】
このように、各子機６０２〜６０５の優先度が異なるので、親機６０１が同一の状態であっても、エラーログの格納要求の受け付けの可否が動的に変わる。また、同一の子機からのエラーログ格納要求であっても、親機６０１の状態によって、エラーログの格納要求の受け付けの可否が動的に変わる。
【０１１１】
・エラーログの格納を受け付けなかった場合
次に、子機６０２〜６０５からのエラーログの格納を親機６０１が受け付けなかった場合について説明する。
【０１１２】
親機６０１は、先に図１０を参照して例示したように、自身のジョブログ６１０から使用の集中が予想される時間について算出することができる。親機６０１が、その時点でのエラーログの格納を受け付けず、延期させる子機に対して、使用の集中が無いと予想される時間での再送を指示する。
【０１１３】
延期の指示を受けた子機は、指定された時間になると、不図示であるエラーログ格納要求に再送であることを示す再送フラグを立てて、再度、親機６０１へエラーログ格納要求を送付する。
【０１１４】
親機６０１では、エラーログ格納要求を受け取り、再送フラグが立っていることを確認すると、優先度を補正するときに、先の図１２（ａ）の再送用補正値πを補正値として加える。例えば、先の例で、親機６０１で操作パネルを利用して、カラーコピーを実行している場合の初回のエラーログ格納要求における補正後の優先度は、６５であったが、同じ状況で再送の場合は、再送用補正値πが１４５であるので、
【０１１５】
となり、エラーログの格納要求は、親機６０１で受け付けられる。
【０１１６】
図１２の例で、再送用補正値πを１４５としたのは、どのような場合でも再送されたエラーログ格納要求を受け付けさせるためである。つまり、補正されていない優先度がゼロ以上であるとすると、
【０１１７】
から、再送用補正値πが１４５以上であれば、常に閾値θ（７０）を上回る。
【０１１８】
この例では、常にエラーログ格納要求が再送時に受け入れられるようにしたが、その限りでなくてもよい。より低い値で、一定以上の（補正された）優先度を持つものでないと、再送された場合でも受け付けなくしてもよい。或いは、再送用補正値πを固定値でなく、例えば再送回数によって値を変えるような仕組みでもよい。
【０１１９】
一例として、再送用補正値πを
【０１２０】
として、子機６０４（図１１中のデバイス名称Ｃ）からエラーログの格納要求が、親機６０１へ送付され、その格納要求が１度目の再送であったとする。このとき、親機６０１では、ＰＣ１４０などからＦＡＸ送信が実行されていると、子機６０４の優先度が６５であるから、
【０１２１】
となり、エラーログ格納要求は受け付けられず、親機６０１から再度、子機６０４に対してエラーログ格納要求の延期が要求される。２回目の再送を子機６０４が行ったときに、親機６０１で操作パネル上で白黒コピーが行われていたとすると、
【０１２２】
となり、エラーログ格納要求は受け入れられて、親機６０１は、子機６０５のエラーログを書込む。
【０１２３】
２回目の親機６０１は、操作パネルが使われており、再送用補正値を除いた補正値が、１度目の再送時の−２０と比べて−２５と大きく、エラーログ格納要求を受け入れづらい状態である。それにも関わらず、且つ元々の優先度が閾値を下回るような子機６０５のエラーログ格納要求であっても、再送回数が多いことで受け入れることが可能となる。なお、この場合は、前述したエラーログ格納要求に再送であることを示す再送フラグを設けるだけでなく、再送回数を示す値をエラーログ格納要求に入れることになる。
【０１２４】
本実施の形態では、親機６０１自身のジョブログ６１０を参照して、使用の集中が予想されない時間の再送を子機に対して行うように説明しているが、そのような時間を指示しないで、予め定められた一定時間後に再送するように指示してもよい。或いは、親機６０１で時間を指定しないで、子機が一定時間経過したら再送するような仕組みでも構わない。更には、再送用補正値πを無くして（π＝０）として、子機の優先度と親機６０１のエラーログ格納要求時の状態だけで補正された優先度を求めて判定するようにしても構わない。
【０１２５】
（ｉｉ）エラーログ受け付けの可否判定処理の流れ
次に、親機６０１が子機のエラーログ格納要求を受け付けるか否かの決定を行う際の処理の流れについて、図１３を参照して説明する。図１３は、第１の実施の形態におけるエラーログ受け付けの可否判定処理の流れを示すフローチャートである。図１３の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１２６】
まずＳ１４０１において、ＣＰＵ２００１は、優先度テーブルからエラーログ格納要求のあった子機の優先度を取得して、Ｓ１４０２へ進む。Ｓ１４０２では、ＣＰＵ２００１は、エラーログ格納要求を確認して、再送されたエラーログを示すフラグが立っている場合には、Ｓ１４０３へ進み、そうでなければＳ１４０４へ進む。
【０１２７】
Ｓ１４０３では、ＣＰＵ２００１は、子機からのエラーログ格納要求が、再送されたエラーログ格納要求であったので、Ｓ１４０１で取得した優先度を再送用補正値を用いて補正して、Ｓ１４０４へ進む。
【０１２８】
Ｓ１４０４では、ＣＰＵ２００１は、親機６０１自身が複合機としての機能を実行しているかを判定する。実行していればＳ１４０５へ進み、実行していなければＳ１４１３へ進む。Ｓ１４０５において、ＣＰＵ２００１は、親機６０１が自身の操作パネルから機能を実行しているかどうかを判定する。操作パネルから機能を実行していれば、Ｓ１４０６へ進む。
【０１２９】
Ｓ１４０６において、ＣＰＵ２００１は、子機の優先度を、操作パネルが操作されているとして補正、つまりパネル操作用に補正を行う。Ｓ１４０５で操作パネルから実行されていなければＳ１４０７へ進む。これは、例えば、ＰＣ１４０などからジョブが投入された場合などである。Ｓ１４０７では、ＣＰＵ２００１は、親機６０１が画像形成装置で実行中のジョブの種類に応じて、子機の優先度の補正を行う。
【０１３０】
一方、Ｓ１４１３は、Ｓ１４０４で親機６０１が複合機としての機能を実行していない場合に実行される。Ｓ１４１３では、ＣＰＵ２００１は、親機６０１が自分自身のジョブログを確認して、現在の時間が親機６０１の使用が集中する時間であるかどうかを判定する。使用の集中が予想される場合は、Ｓ１４０８へ進み、使用の集中が予想されない場合は、Ｓ１４１４へ進んで、親機６０１にエラーログを書込んで終了する。
【０１３１】
Ｓ１４０８において、ＣＰＵ２００１は、エラーログ格納要求がハード的に動作しないなどの致命的なエラーかどうかを判定する。これは、エラーログ格納要求中にフラグなどを準備して判断することができるようにする。致命的なエラーログの場合は、Ｓ１４１４へ進む。致命的なものでない場合は、Ｓ１４０９へ進む。
【０１３２】
Ｓ１４０９において、ＣＰＵ２００１は、子機のログ用メモリ２１００がメモリフルになっているかを判定する。これも、エラーログ格納要求中にフラグなどを準備して判断できるようにする。メモリフルの場合は、Ｓ１４１４へ進み、そうでない場合は、Ｓ１４１０へ進む。
【０１３３】
Ｓ１４１０において、ＣＰＵ２００１は、エラーログ格納要求が、ジャムが一定回数発生した後のエラーログであるかどうかを判定する。これも、エラーログ格納要求中にフラグなどを準備して判断することができるようにする。一定回数以上のジャム発生のエラーログの場合は、Ｓ１４１４へ進み、そうでなければ、Ｓ１４１１へ進む。
【０１３４】
Ｓ１４１１において、ＣＰＵ２００１は、補正された優先度が、予め定められた閾値より大きいかどうかを判定し、閾値よりも大きければＳ１４１４へ進む。閾値未満であれば、Ｓ１４１２へ進む。
【０１３５】
Ｓ１４１２において、ＣＰＵ２００１は、エラーログ格納要求を送信した子機に対して、親機６０１のジョブログを用いて稼動状況を確認する。そして、親機６０１の稼動状況が低下すると予想される時間での再送を子機に指示して終了する。Ｓ１４１４において、ＣＰＵ２００１は、当該子機のエラーログを書込んで終了する。
【０１３６】
なお、本実施の形態においては、エラーログとして説明したが、突発的に発生してサイズが大きいことなどが親機６０１の処理のパフォーマンスを劣化させるようなログであれば、エラーログでなくても構わない。
【０１３７】
＜本実施の形態に係る利点＞
第１の実施の形態によれば、次のような利点を有する。
【０１３８】
親機６０１は、通常のジョブログを定期的に子機６０２〜６０５から取得している。そこで、ジョブログから子機の稼動状況を確認してその稼動率を算出し、稼動率の高い子機は頻繁に使われるため子機のログ用メモリ２１００がメモリフルになり易いと判断して、このような子機からのエラーログ格納要求を優先的に受け付ける。逆に、稼動率の低い子機は、ログ用メモリ２１００がメモリフルになり難いと判断して、エラーログ格納要求の受け付けの優先度を下げる。このように、管理対象の子機が多数あっても、稼動率の高い機器からのエラーログを優先的に受け付けるようにして、稼動率の低い機器からの受け付けを制限する。これにより、親機自身の画像形成装置としてのパフォーマンスを低下させることなく、効率的にエラーログの受け付けを行うことができる。このとき、単純に子機側の稼動率だけで優先度を決定するのではなく、親機６０１自身の稼動率や稼動状況（実際にユーザが機器の操作をしているかなど）を基にして優先度を決めるので、子機に対して自動的に動的な優先度の設定を行うことが可能になる。
【０１３９】
即ち、本実施の形態では、逐次変化するジョブログを用いることにより、子機のジョブログから算出された優先度と、逐次変化する親機６０１の稼動状態とによって、子機からのエラーログ格納要求の可否を動的に判定することができる。
【０１４０】
また、親機６０１のジョブログ６１０から親機６０１自身の稼動状況の予測を行って、子機からのエラーログ格納要求の可否を決めたり、エラーログ格納要求が拒否された子機への再送時間を決めたりすることができる。
【０１４１】
更には、親機６０１で実行中のジョブの種類や、操作パネル上の実行かどうかによって、子機の優先度の補正を動的に行うことができる。また、エラーログ格納要求で、緊急エラーログを優先的に格納できる仕組みも実現することができる。
【０１４２】
［第２の実施の形態］
第１の実施の形態では、エラーログ格納要求を延期する場合には、親機６０１が子機に対して再送を指示して、エラーログ格納要求を再送してもらうようにした形態について説明した。これに対して、第２の実施の形態では、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに、子機のエラーログを取得するようにした形態について説明する。
【０１４３】
＜エラーログ格納要求を延期した場合の動作＞
第２の実施の形態に係る、親機６０１がエラーログ格納要求を延期した場合の動作について、図１４を参照して説明する。図１４は、エラーログ格納要求を延期した場合の動作を説明するための概念図であり、図５と共通の要素には同一符号を付与する。
【０１４４】
子機６０２からエラーログ格納要求１６０１があったが、親機６０１は、このエラーログ格納要求１６０１を拒否したとする。このとき、親機６０１は、エラーログ書込み待ちリストに子機６０２を追加する。同様に、子機６０４からエラーログ格納要求１６０２があったが、親機６０１がこのエラーログ格納要求１６０２を拒否すると、親機６０１はエラーログ書込み待ちリストに子機６０４を追加する。なお、エラーログ格納要求の受け付けの可否の方法は、第１の実施の形態で示したものとする。
【０１４５】
エラーログ書込み待ちリストは、例えば、図１５に示すようなものである。図１５は、エラーログ書込み待ちリストの一例を示す図である。
【０１４６】
図１５において、１７０１は、エラーログ書込み待ちリストを特定するデバイスの名称であり、１７０２、１７０３はそれぞれ、エラーログ格納要求を送付した日付と時間である。なお、第１の実施の形態の図１１で示したものと同様に、デバイス名称Ａは、図５中の子機６０２を表す。同様に、デバイス名称Ｂは子機６０３、デバイス名称Ｃは子機６０４、デバイス名称Ｄは子機６０５をそれぞれ表すものとする。
【０１４７】
図１５の１７０４に示すものは、子機６０４が「２００７年１０月５日」の「１１時２４分５５秒」に送ったエラーログ格納要求は、親機６０１に拒否されたことを示す。１７０５に示すものは、子機６０２が「２００７年１０月５日」の「１３時１０分００秒」に送ったエラーログ格納要求は、親機６０１に拒否されたことを示す。
【０１４８】
親機６０１では、自身がコピーなど画像形成装置としての機能を実行していないとき、または自身のジョブログ６１０から機能の集中使用が予想されないときは、次の処理を行う。即ち、エラーログ書込み待ちリストを確認して、エラーログ格納要求があったが、まだエラーログを書込んでない子機からエラーログを取得する。図１５の例では、子機６０４と６０２がエラーログの書込み待ちになっているが、親機６０１は、優先度テーブルを参照して優先度が高い子機からエラーログを取得する。
【０１４９】
例えば、図７の優先度テーブルであったとすると、子機６０４の優先度は６５、子機６０２の優先度は１００である。時間的には子機６０４よりも後にエラーログ格納要求を行った子機６０２のエラーログが先に取得される。当然ながら、単純にエラーログ格納要求した時間が早いものから順にエラーログを取得するような仕組みでも構わない。
【０１５０】
また、複数回のエラーログ格納要求がある場合に、例えば、図１６のようなエラーログ書込み待ちリストであったとする。優先度は、子機６０５（デバイス名称Ｄ）が８０で、子機６０３（デバイス名称Ｂ）が３５である。しかし、エラーログ格納要求の回数が、子機６０３からの方が多いため、親機６０１は、子機６０３のエラーログを先に取得してもよい。
【０１５１】
また、一定回数以上のエラーログ格納要求が延期された子機がエラーログ書込み待ちリストにある場合には、その子機を優先として親機６０１が当該子機のエラーログを取得してもよい。
【０１５２】
＜エラーログ取得決定処理の流れ＞
次に、親機６０１が、エラーログ書込み待ちリスト中のどの子機のエラーログを取得するのかを決定する処理の流れについて、図１７及び図１８を参照して説明する。
【０１５３】
図１７及び図１８は、本発明の第２の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートであり、図１３と同一処理の部分については、図１３と同一符号を付与して、その説明は割愛する。なお、図１７及び図１８の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１５４】
まずＳ１５０１において、ＣＰＵ２００１は、子機からのエラーログ格納要求を受信したかを判定する。受信した場合は、Ｓ１４０１へ進み、図１３のフローチャートで説明した処理を実施する。エラーログ格納要求を延期する場合に、図１３のフローチャートでは、Ｓ１４１２で子機へ再送要求を行っていたが、本フローチャートでは、Ｓ１５０２へ進む。Ｓ１５０２において、ＣＰＵ２００１は、エラーログ書込み待ちリストに当該子機の情報を追加する。
【０１５５】
Ｓ１５０１で、親機６０１が、エラーログ格納要求を受信していない場合は、Ｓ１５０３へ進む。Ｓ１５０３において、ＣＰＵ２００１は、親機６０１自身が複合機としての機能を実行しておらず、自身のジョブログ６１０から使用の集中が予想される時間帯でないかを判定する。Ｎｏの場合、即ち親機６０１が機能を実行しているか、或いは使用の集中が予想される時間帯であれば、終了する。Ｙｅｓの場合、即ち親機６０１で機能も実行されていないし、使用が集中されることも予想されないときは、Ｓ１５０４へ進む。
【０１５６】
Ｓ１５０４において、ＣＰＵ２００１は、エラーリスト書込み待ちリストを確認して、空であれば終了する。空でなければ、Ｓ１５０５へ進む。Ｓ１５０５において、ＣＰＵ２００１は、エラーログ書込み待ちリストに予め定められた一定回数以上延期された子機があるかを判定する。あればＳ１５０７へ進み、無ければＳ１５０６へ進む。
【０１５７】
Ｓ１５０６において、ＣＰＵ２００１は、エラーログ書込み待ちリスト中で優先度が一番高い子機を選択して、Ｓ１５１０へ進む。なお、このとき同一優先度の複数の子機があった場合は、１つを選択する。選択の仕方は、例えば、最初に見つかったものであっても構わない。或いは、該当する子機の中で一番最初にエラーログ格納要求があったものでも構わない。或いは、延期回数が一番多いものでも構わないし、ここに挙げた以外の方法でも１つを選択する方法であれば構わない。
【０１５８】
Ｓ１５０７において、ＣＰＵ２００１は、エラーログ書込みリスト中で、エラーログ格納要求の延期回数が一番多い子機を選択する。次のＳ１５０８において、ＣＰＵ２００１は、Ｓ１５０７で選択した子機が複数あるか判定する。１つだけなら、Ｓ１５１０へ進み、複数あれば、Ｓ１５０９へ進む。
【０１５９】
Ｓ１５０９において、ＣＰＵ２００１は、Ｓ１５０７で選択された複数の子機の優先度が一番高いものを選択する。このとき、優先度が同一のものが複数あった場合は、先にＳ１５０６で説明したような方法で１つの子機を選択する。Ｓ１５１０において、ＣＰＵ２００１は、親機６０１が選択した子機のエラーログを取得して、Ｓ１４１４へ進む。
【０１６０】
Ｓ１４１４において、ＣＰＵ２００１が、当該子機のエラーログを親機６０１に書込んだ後、Ｓ１５１１へ進む。Ｓ１５１１において、ＣＰＵ２００１は、エラーログ書込み待ちリストから当該子機の項目を削除して、終了する。なお、Ｓ１５０１でＹｅｓの場合は、エラーログ書込み待ちリストでなく、子機から直接要求のあったエラーログを書込む場合となる。このときに、当該子機がエラーログ書込み待ちリストになければ、当然ながらＳ１５１１では、何も処理しない。
【０１６１】
＜第２の実施の形態に係る利点＞
第２の実施の形態では、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに子機のエラーログを取得することができる。即ち、親機６０１は、エラーログ格納要求が延期された回数の多い子機のエラーログ、或いは高い優先度の子機のエラーログを、親機６０１自身の処理が行われていない合間に取得しに行くことができ、効率的なエラーログ書込み処理を行うことができる。
【０１６２】
［第３の実施の形態］
第３の実施の形態においても、エラーログ格納要求を延期した場合には親機６０１が都合が良いときに子機のエラーログを取得する点において第２の実施の形態と同様であるが、その取得の方法が異なる。
【０１６３】
即ち、第３の実施の形態では、親機６０１自身が複合機としての機能を実行しておらず、自身のジョブログ６１０から使用の集中が予想される時間帯でない場合に、エラーログ書込み待ちリスト中の子機の優先度を補正する。そして、補正された優先度が最も高いの子機のエラーログを取得するような方法を採る。
【０１６４】
＜優先度補正方法＞
以下、本実施の形態における優先度補正方法について説明する。
【０１６５】
例えば、エラーログ格納要求の回数による補正値を
【０１６６】
とすると、子機６０３の補正値は、γ＝１５×３＝４５となり、補正値を優先度３５に加えて、８０となる。一方、子機６０５の補正値は、γ＝１５×１＝１５となり、補正値を優先度６５に加えて、９５となる。子機６０５の方が、エラーログ格納要求の回数が少ないが、補正された優先度が大きいため、親機６０１は、子機６０５のエラーログを取得する。
【０１６７】
また、待ち時間に応じて優先度を変えるように補正してもよい。例えば、現時点から待ち時間の分単位の経過時間を求めて、それを
【０１６８】
として、子機６０２〜６０５の優先度を補正する。例えば、現在の時刻を１４時丁度とすると、図１５のエラーログ書込み待ちリストにおいて、子機６０４は、１５６分待ち、子機６０２は、５０分待ちとなる。但し、秒単位は切り捨てとする。すると、子機６０４の補正値は、ε＝１５６×０．５＝７８、子機６０２の補正値は、ε＝５０×０．５＝２５となる。したがって子機６０４、６０２の優先度が６５、１００であるので、補正後の優先度は、それぞれ１４３と１２５となって、親機６０１は、子機６０４のエラーログを取得する。
【０１６９】
また、複数の同一子機のエラーログ書込み待ちがあるときは、例えば、一番長い間待っているものにするなどの方法がある。
【０１７０】
いくつかの優先度の補正方法の例を説明したが、これらの補正方法を組み合わせて優先度を補正するようにしても構わない。また、ある一定の時間内に特定の子機からのエラーログ格納要求が一定回数以上あったときは、当該子機の優先度を上げるようにしてもよい。
【０１７１】
＜エラーログ取得決定処理の流れ＞
次に、親機６０１が、補正された優先度を用いて、エラーログ書込み待ちリスト中のどの子機のエラーログを取得するのかを決定する処理の流れについて、図１９及び図２０を参照して説明する。
【０１７２】
図１９及び図２０は、本発明の第３の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートであり、図１３、図１７及び図１８と同一処理の部分については、図１３、図１７及び図１８と同一符号を付与して、その説明は割愛する。図１９及び図２０の各ステップは、親機６０１が備えるＣＰＵ２００１が、ＲＯＭ２００３に格納されたプログラムをＲＡＭ２００２に展開して実行される。
【０１７３】
Ｓ１９０１は、親機６０１が処理を実行しておらず、使用の集中も予想されないときに、子機からエラーログ格納要求がなく、且つエラーログ書込み待ちリストが空で無いときに実行されるステップである。Ｓ１９０１において、ＣＰＵ２００１は、エラーログ書込み待ちリスト中の子機に対して、上述した優先度補正方法を用いて優先度の補正を行い、Ｓ１９０２へ進む。
【０１７４】
Ｓ１９０２において、ＣＰＵ２００１は、補正された優先度の中で、優先度が最も高い子機を選択して、Ｓ１５１０へ進む。同一の優先度を持つ子機が複数あった場合には、先にＳ１５０６で説明したような方法で１つを選択する。
【０１７５】
＜第３の実施の形態に係る利点＞
第２の実施の形態によれば、エラーログ格納要求を延期した場合には、親機６０１の都合が良いときに子機のエラーログを取得することができる。即ち、親機６０１は、エラーログ格納要求が延期された子機の中で高い優先度の子機のエラーログを、親機６０１自身の処理が行われていない合間に取得しに行くことができ、効率的なエラーログ書込み処理を行うことができる。
【０１７６】
［変形例］
本発明は、上記した各実施の形態に限定されず、種々の変形が可能であり、その変形例としては例えば次のようなものがある。
【０１７７】
（１）上記した第２の実施の形態または第３の実施の形態は、第１の実施の形態で説明した再送指示を行う方式との複合でも構わない。つまり、エラーログ格納要求を延期する場合に、当該子機に対して再送指示をすると同時にエラーログ書込み待ちリストにも当該子機の情報を追加する。子機が再送もしてくるし、再送が行われる前に親機６０１が処理を実行していない且つ使用の集中が予想されない場合は、親機６０１が、エラーログ書込み待ちリスト中の子機にエラーログを取りに行くようにする。このような形態は、図１３、図１７、図１８、図１９及び図２０のフローチャートの組み合わせで実現できることは容易に分かる。
【０１７８】
（２）子機のエラーログ格納要求が親機６０１に拒否されたときに、子機側では、ログ用メモリ２１００がメモリフルである場合に、緊急用フラグを立てて、親機６０１に対して、優先的にエラーログを書込むよう依頼することを第１の実施の形態で説明した。このように緊急用フラグを設けずに、子機で、エラーログが取得されるまで、子機の動作できないように操作パネルなどをロックしてしまう仕組みとしてもよい。
【０１７９】
（３）また、子機側の処理として、次のような処理を行ってもよい。即ち、同一のエラーが発生している場合に、親機６０１がエラーログ格納要求を何度も拒否していると、同じようなエラーログが何度も子機側のログ用メモリ２１００に記録されて、すぐにログ用メモリ２１００がフルになってしまう可能性がある。そこで、同じエラーが発生して、既にログ用メモリ２１００に記録されている場合には、同一のエラーログとして、エラーログのレベルを下げて、簡略化したエラーログをログ用メモリ２１００に書込む。これによって、ログ用メモリ２１００がメモリフルになるのをなるべく抑えるようにしてもよい。
【０１８０】
或いは、同じエラーが発生している場合は、通常よりもエラーログのレベルを上げて、詳細なエラーログを取得し、ログ用メモリ２１００に書込んで、エラーの原因を究明し易くする。同時に、ログ用メモリ２１００のメモリフルを早期に発生させて、緊急用フラグを立てたエラーログ格納要求を送出し易くして、エラーログをなるべく早く親機６０１に書込ませるようにしてもよい。
【０１８１】
（４）本実施の形態において画像形成装置として説明しているが、サービスを提供する機能を有する装置であれば、本発明の適用は画像形成装置に限定されない。例えば、サーバ機器にスキャナ、プリンタ等を接続して、画像形成装置と同等の機能を有するようにした構成を画像形成装置と読み換えても構わない。
【０１８２】
（５）本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。
【０１８３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１８４】
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【０１８５】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１８６】
更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。
【図面の簡単な説明】
【０１８７】
【図１】実施の形態に係る処理装置を含む画像形成システムの全体の構成を示すブロック図である。
【図２】図１中の画像形成装置の構成を示すブロック図である。
【図３】ジョブログの一例を示す表形式図である。
【図４】エラー時の画像形成装置における動作状況を記録したエラーログの一例を示す図である。
【図５】親機のログ収集を示す概念図である。
【図６】子機のジョブログの一例を示す表形式図である。
【図７】優先度テーブルの一例を示す図である。
【図８】ジョブログを収集して優先度テーブルを更新する処理の流れを示すフローチャートである。
【図９】親機のエラーログ受け付け可否判定動作を説明する概念図である。
【図１０】親機自身のジョブログの一例を示す表形式図である。
【図１１】優先度テーブルの一例を示す図である。
【図１２】優先度の閾値と各種補正値の一例を示す図である。
【図１３】第１の実施の形態におけるエラーログ受け付けの可否判定処理の流れを示すフローチャートである。
【図１４】エラーログ格納要求を延期した場合の動作を説明するための概念図である。
【図１５】エラーログ書込み待ちリストの一例を示す図である。
【図１６】エラーログ書込み待ちリストの一例を示す図である。
【図１７】第２の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートである。
【図１８】図１７の続きのフローチャートである。
【図１９】第３の実施の形態におけるエラーログ取得決定処理の流れを示すフローチャートである。
【図２０】図１９の続きのフローチャートである。
【符号の説明】
【０１８８】
６０１ 親機（画像形成装置）
６０２〜６０５ 子機（画像形成装置）
２００１ ＣＰＵ
２００２ ＲＡＭ
２００３ ＲＯＭ
２００４ ＨＤＤ
２０１２ 操作部
２１００ ログ用メモリ
【特許請求の範囲】
【請求項１】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置において、
前記外部処理装置から送信された前記第１のログを受信する受信手段と、
前記受信手段によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出手段と、
前記算出手段によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定手段とを備えたことを特徴とする処理装置。
【請求項２】
前記処理装置自身の動作状況を判断する判断手段と、
前記判断手段によって判断された動作状況に応じて、前記優先度を補正する補正手段とをさらに備え、
前記決定手段は、前記補正手段によって補正された優先度に基づいて、前記第２のログを格納するか否かを決定することを特徴とする請求項１に記載の処理装置。
【請求項３】
操作者が情報を入力するための操作手段を備え、
前記補正手段は、前記操作手段が操作されている場合に優先度を補正することを特徴とする請求項２に記載の処理装置。
【請求項４】
前記補正手段は、前記処理装置で処理中のジョブの種類に応じて優先度を補正することを特徴とする請求項２に記載の処理装置。
【請求項５】
前記処理装置自身の前記第１のログを格納する格納手段と、
前記格納手段に格納された前記処理装置自身の第１のログを解析して、当該処理装置が使用される時間帯の頻度を算出する演算手段と、
前記演算手段によって算出された現在の時刻における使用頻度が一定の閾値以上の場合に、前記外部処理装置が前記処理装置に対して前記第２のログの格納を要求するためのログ格納要求を拒否する手段とを備えたことを特徴とする請求項１乃至４のいずれか一項に記載の処理装置。
【請求項６】
前記ログ格納要求を拒否した場合に、前記演算手段が求めた前記処理装置の使用頻度が一定の閾値未満の時間帯において当該ログ格納要求を再送するように前記外部処理装置に指示する手段を有することを特徴とする請求項５に記載の処理装置。
【請求項７】
前記ログ格納要求内に、優先して前記第２のログを格納することを指示する緊急用のフラグを有することを特徴とする請求項５または６に記載の処理装置。
【請求項８】
前記ログ格納要求を拒否した場合に、前記第２のログの格納を延期した外部処理装置が記載されたログ書込み待ちリストに、前記ログ格納要求が拒否された外部処理装置を追加する更新手段と、
前記ログ書込み待ちリストから外部処理装置を選択する選択手段と、
前記選択手段で選択された外部処理装置の第２のログを取得する取得手段とを備え、
前記取得手段で取得された第２のログを前記格納手段に格納することを特徴とする請求項５に記載の処理装置。
【請求項９】
前記処理装置の動作状況と前記演算手段によって求められた現在の時刻における使用頻度とに基づいて、前記取得手段の実行の可否を決めることを特徴とする請求項８に記載の処理装置。
【請求項１０】
前記選択手段は、前記算出手段で算出された優先度に基づいて外部処理装置を選択することを特徴とする請求項８に記載の処理装置。
【請求項１１】
前記選択手段が前記ログ書込み待ちリストから外部処理装置を選択するときに用いる前記優先度を補正する補正手段を備えたことを特徴とする請求項１０に記載の処理装置。
【請求項１２】
前記補正手段は、前記ログ格納要求の回数に基づいて前記優先度を補正することを特徴とする請求項１１に記載の処理装置。
【請求項１３】
前記補正手段は、前記ログ格納要求があった時間に基づいて前記優先度を補正することを特徴とする請求項１１に記載の処理装置。
【請求項１４】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法であって、
前記外部処理装置から送信された前記第１のログを受信する受信工程と、
前記受信工程によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出工程と、
前記算出工程によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定工程とを備えたことを特徴とする処理装置の制御方法。
【請求項１５】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、
前記外部処理装置から送信された前記第１のログを受信する受信ステップと、
前記受信ステップによって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出ステップと、
前記算出ステップによって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定ステップとを備えたことを特徴とする制御プログラム。
【請求項１】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置において、
前記外部処理装置から送信された前記第１のログを受信する受信手段と、
前記受信手段によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出手段と、
前記算出手段によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定手段とを備えたことを特徴とする処理装置。
【請求項２】
前記処理装置自身の動作状況を判断する判断手段と、
前記判断手段によって判断された動作状況に応じて、前記優先度を補正する補正手段とをさらに備え、
前記決定手段は、前記補正手段によって補正された優先度に基づいて、前記第２のログを格納するか否かを決定することを特徴とする請求項１に記載の処理装置。
【請求項３】
操作者が情報を入力するための操作手段を備え、
前記補正手段は、前記操作手段が操作されている場合に優先度を補正することを特徴とする請求項２に記載の処理装置。
【請求項４】
前記補正手段は、前記処理装置で処理中のジョブの種類に応じて優先度を補正することを特徴とする請求項２に記載の処理装置。
【請求項５】
前記処理装置自身の前記第１のログを格納する格納手段と、
前記格納手段に格納された前記処理装置自身の第１のログを解析して、当該処理装置が使用される時間帯の頻度を算出する演算手段と、
前記演算手段によって算出された現在の時刻における使用頻度が一定の閾値以上の場合に、前記外部処理装置が前記処理装置に対して前記第２のログの格納を要求するためのログ格納要求を拒否する手段とを備えたことを特徴とする請求項１乃至４のいずれか一項に記載の処理装置。
【請求項６】
前記ログ格納要求を拒否した場合に、前記演算手段が求めた前記処理装置の使用頻度が一定の閾値未満の時間帯において当該ログ格納要求を再送するように前記外部処理装置に指示する手段を有することを特徴とする請求項５に記載の処理装置。
【請求項７】
前記ログ格納要求内に、優先して前記第２のログを格納することを指示する緊急用のフラグを有することを特徴とする請求項５または６に記載の処理装置。
【請求項８】
前記ログ格納要求を拒否した場合に、前記第２のログの格納を延期した外部処理装置が記載されたログ書込み待ちリストに、前記ログ格納要求が拒否された外部処理装置を追加する更新手段と、
前記ログ書込み待ちリストから外部処理装置を選択する選択手段と、
前記選択手段で選択された外部処理装置の第２のログを取得する取得手段とを備え、
前記取得手段で取得された第２のログを前記格納手段に格納することを特徴とする請求項５に記載の処理装置。
【請求項９】
前記処理装置の動作状況と前記演算手段によって求められた現在の時刻における使用頻度とに基づいて、前記取得手段の実行の可否を決めることを特徴とする請求項８に記載の処理装置。
【請求項１０】
前記選択手段は、前記算出手段で算出された優先度に基づいて外部処理装置を選択することを特徴とする請求項８に記載の処理装置。
【請求項１１】
前記選択手段が前記ログ書込み待ちリストから外部処理装置を選択するときに用いる前記優先度を補正する補正手段を備えたことを特徴とする請求項１０に記載の処理装置。
【請求項１２】
前記補正手段は、前記ログ格納要求の回数に基づいて前記優先度を補正することを特徴とする請求項１１に記載の処理装置。
【請求項１３】
前記補正手段は、前記ログ格納要求があった時間に基づいて前記優先度を補正することを特徴とする請求項１１に記載の処理装置。
【請求項１４】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法であって、
前記外部処理装置から送信された前記第１のログを受信する受信工程と、
前記受信工程によって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出工程と、
前記算出工程によって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定工程とを備えたことを特徴とする処理装置の制御方法。
【請求項１５】
使用頻度に関する情報を含む第１のログ、及び、エラーに関する情報を含む第２のログを送信する複数の外部処理装置に接続され、該各外部処理装置から前記第１及び第２のログを収集する処理装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、
前記外部処理装置から送信された前記第１のログを受信する受信ステップと、
前記受信ステップによって受信された第１のログから求められた前記外部処理装置の稼動状況に基づいて、当該外部処理装置の優先度を算出する算出ステップと、
前記算出ステップによって算出された優先度に基づいて、前記外部処理装置が送信した前記第２のログを格納するか否かを決定する決定ステップとを備えたことを特徴とする制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００９−２５１７４７（Ｐ２００９−２５１７４７Ａ）
【公開日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願番号】特願２００８−９６３５２（Ｐ２００８−９６３５２）
【出願日】平成２０年４月２日（２００８．４．２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２１年１０月２９日（２００９．１０．２９）
【国際特許分類】
【出願日】平成２０年４月２日（２００８．４．２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]