(57)【特許請求の範囲】
【請求項１】
画像データの入力または出力の少なくとも一方を行う画像入出力ジョブの実行に必要となるデータを記憶蓄積する記憶蓄積手段と、
前記記憶蓄積手段に記憶蓄積されたデータを用いて前記画像入出力ジョブを実行するジョブ実行手段と、
前記ジョブ実行手段での前記画像入出力ジョブの実行エラーを検出するエラー検出手段と、
前記ジョブ実行手段が前記記憶蓄積手段内のデータを用いて前記画像入出力ジョブを行っている最中に、前記エラー検出手段が実行エラーの発生を検出すると、当該実行エラーの発生時に前記ジョブ実行手段が処理していた当該データの処理部分を特定する情報と、当該実行エラーの発生時に当該データを処理していたアプリケーションを特定する情報とを、ログ情報として抽出するログ抽出手段と
を備えることを特徴とする画像処理装置。
【請求項２】
前記エラー検出手段が実行エラーを検出すると、当該実行エラーの種類を特定し、特定した種類に対応する処理を前記ログ抽出手段による抽出結果に対して施すログ情報処理手段
を備えることを特徴とする請求項１記載の画像処理装置。
【請求項３】
前記ログ情報処理手段が施す処理の内容を実行エラーの種類別に登録するための登録手段
を備えることを特徴とする請求項２記載の画像処理装置。
【請求項４】
一種類の実行エラーに対して複数の処理内容が前記登録手段によって登録されている場合に、登録された処理内容の中から前記ログ情報処理手段が施す処理内容を選択するための選択手段
を備えることを特徴とする請求項３記載の画像処理装置。
【請求項５】
一種類の実行エラーに対して複数の処理内容が前記登録手段に登録されている場合に、登録された処理内容の実行順を特定するための順位特定手段
を備えることを特徴とする請求項３または４記載の画像処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コピージョブ、スキャンジョブ、プリントジョブ、ＦＡＸジョブ等といった、画像データの処理ジョブを実行するための画像処理装置に関する。
【０００２】
【従来の技術】
近年、画像データの処理ジョブを実行する画像処理装置としては、例えばコピー機能、スキャナ機能、プリンタ機能、ＦＡＸ機能等といった複数の機能を1台の装置で提供する、いわゆる複合機（以下「ＭＦ機」という）が普及している。ＭＦ機は、紙原稿スキャンのための画像入力部（Image Input Terminal；以下「ＩＩＴ」という）、ＦＡＸ受信のための公衆回線接続部、プリントデータ受信のためのＬＡＮ（Local Area Network）等へのネットワーク接続部、といった複数の画像入力手段を持つ。また、用紙への印刷出力のための画像出力部（Image Output Terminal;以下「ＩＯＴ」という）、ＦＡＸ送信のための公衆回線接続部、様々な入力画像データのホストコンピュータへの送信のためのＬＡＮ等へのネットワーク接続部、といった複数の画像出力手段も併せ持つ。さらには、入力画像データを一旦蓄積・保管して様々な機能を提供するためのＨＤＤ（Hard Disk Drive）等の画像蓄積手段を持つものもある。
【０００３】
このようなＭＦ機では、複数の画像入力手段のうちのいずれか１つと、複数の画像出力手段のうちのいずれか１つを組み合わせることによって、様々な画像入出力ジョブをユーザに提供することが可能である。例えば、ＩＩＴでスキャンした画像データをＩＯＴで出力することによるコピー機能、ネットワーク経由で受信したＰＤＬ（Page Description Language）等のデータをデコンポーズしてＩＯＴで出力することによるプリンタ機能、ＩＩＴでスキャンした画像データを公衆回線経由で送信するＦＡＸ機能等、多種多様な機能を提供できる。
【０００４】
それに伴い、ＭＦ機では、ユーザからの画像入出力ジョブの提供要求が一時期に複数集中する可能性も増大している。ところが、ＩＩＴ／ＩＯＴ等の画像入出力デバイスは同時に１つの画像入出力ジョブしか処理できないので、一時期に複数の画像入出力ジョブが集中すると、ユーザがジョブの終了状況を容易に確認できないことも考えられる。これは、一時期に複数の画像入出力ジョブが集中すると、自分の要求したジョブが即座に実行開始されずに待たされてしまったり、ジョブの処理結果である印刷出力が他のユーザの要求したジョブによる印刷出力と排紙トレイ上で混在したりして、自分の要求したジョブがいつ終了したかといった状況を確認するのが困難になるからである。
【０００５】
そのため、最近では、例えば特開平１１−２８９４１３号公報に開示されているように、画像処理ジョブの実行状況と終了状況を記憶する記憶手段を設けておき、実行途中のジョブの一覧表示や実行完了したジョブの一覧表示を行うようにする制御方法が提案されている。また、特開平１１−３４１２１２号公報に開示されているように、過去に行ったジョブの実行履歴を保存して、それを必要に応じて表示する制御方法も提案されている。これらは、いずれも、ジョブの状況確認を可能にする機能を提供しているため、ユーザが自分の要求したジョブがいつ終了したのかを容易に確認することができるようになっている。
【０００６】
【発明が解決しようとする課題】
しかしながら、上述した従来の制御方法を用いたＭＦ機では、ジョブの実行途中に予期せぬエラーが発生した場合に、以下に述べるような問題が生じてしまうおそれがある。
【０００７】
例えば、ジョブの実行途中に予期せぬ電源断エラーが発生した場合には、その実行途中のジョブに関する履歴を確認することは依然不可能である。これは、電源断エラーによって、実行途中のジョブに関する情報（実行状況等）が全て失われてしまうからである。そのため、このような場合に、ユーザは、自分の要求したジョブが、電源断エラーにより実行完了せずに異常終了したのか、未だ実行開始されていないのか、それとも既に実行完了しているのか、といった判断を容易に行うことができなくなってしまう。
【０００８】
特に、昨今、ＭＦ機を企業等で利用する場合には、複数の部門にまたがる複数のユーザが１台のＭＦ機を共有している場合が多く、その際には部門毎の当該ＭＦ機の使用頻度を把握して課金したり、ＩＳＯ（国際標準化機構）１４００１等に準拠するために省エネ動向をユーザ毎に把握して管理目標を立てる、といった利用形態を満足させる必要がある。そのために、ＭＦ機に対しては、そのＭＦ機内で保存されるジョブ履歴情報を外部の集計装置や集計ソフトウエアで収集して、部門別集計やユーザ別集計、モノクロ／カラー印刷比率、両面印刷率、Ｎ−ｕｐ率等の情報提供を可能にすることが要求されている。したがって、このような情報収集の際に、電源断エラーによる実行途中ジョブの情報消失が発生すると、課金情報や部門別集計情報・ユーザ別集計情報の精度が低下することになり、被害損失が増大化することが考えられる。
【００１０】
また、ジョブの実行途中に発生する予期せぬエラーには、上述した電源断エラーの他に、ネットワークの接続切れやデータの転送状態等が原因で印刷出力に障害が発生するといった、電源断を伴わないエラーもある。このようなエラーの場合、実行途中のジョブに関する情報が失われることはないため、ジョブの実行履歴等を保存しておけば、これを解析してエラー発生の原因特定に役立てることも考えられる。
【００１１】
実際に、例えば特開平６−８９２３９号公報には、通信回線上でのエラー発生時に、エラーを自己診断して、エラー発生時からの通信トレース情報を採取してファイルに格納することで、無人の環境でも通信エラーの発生したプロトコルを採取して、エラー発生の原因特定に役立てるようにした装置が提案されている。また、特開平５−２０４７１８号公報には、コンピュータシステムの周辺機器のデバイスプログラムの実行パラメータの履歴を保存しておくことによって、周辺機器接続の際のエラー発生の原因特定を容易にした装置が提案されている。
【００１２】
ただし、ＭＦ機をはじめとする画像処理装置は、その使用環境や設置環境に依存してエラー発生することが多い。しかも、通常は、その設置場所でエラー発生の原因特定を行うことが要求される。したがって、画像処理装置には、エラー発生の原因特定のための情報収集を保守員等の介在無しに無人で的確に行うことが可能であり、さらには収集した情報からエラー発生の原因特定を迅速に行えることが望まれている。
【００１３】
ところが、上述した特開平６−８９２３９号公報に開示の従来技術によれば、無人での情報収集は可能であるが、これは通信プロトコル上のエラー採取を目的としたものであることから、印刷出力時に発生するエラー（例えばジョブの処理シーケンス上で発生するエラー）の原因を特定することはできない。しかも、プロトコルトレースの結果が膨大な量となってしまうため、その中からエラーの発生箇所やその原因等を特定するのに多大な手間が必要となり、迅速なエラー発生の原因特定を行えるとはいえない。また、特開平５−２０４７１８号公報に開示の従来技術では、デバイスプログラムの実行パラメータが保存されているので、エラー発生時におけるデバイスの異常原因を特定しやすいが、デバイスの設定に異常がない場合、具体的には複数デバイスの動作処理やデバイスが取り扱うデータそのものに原因がある場合には、エラー原因を特定できなくなってしまうため、必ずしもエラー発生の原因特定を的確に行えるとはいえない。
【００１４】
そこで、本発明は、上記問題点に鑑み、エラー発生時に処理していたデータとこれを処理するソフトウエアモジュールの動作とを関連付けてログ情報として保存することにより、エラー発生の原因特定のための情報収集を的確に行え、しかも収集した情報からエラー発生の原因特定を迅速に行える画像処理装置を提供することを目的とする。
【００１７】
本発明は、上記目的を達成するために案出された画像処理装置で、画像データの入力または出力の少なくとも一方を行う画像入出力ジョブの実行に必要となるデータを記憶蓄積する記憶蓄積手段と、前記記憶蓄積手段に記憶蓄積されたデータを用いて前記画像入出力ジョブを実行するジョブ実行手段と、前記ジョブ実行手段での前記画像入出力ジョブの実行エラーを検出するエラー検出手段と、前記ジョブ実行手段が前記記憶蓄積手段内のデータを用いた前記画像入出力ジョブを行っている最中に、前記エラー検出手段が実行エラーの発生を検出すると、当該実行エラーの発生時に前記ジョブ実行手段が処理していた当該データの処理部分を特定する情報と、当該実行エラーの発生時に当該データを処理していたアプリケーションを特定する情報とを、ログ情報として抽出するログ抽出手段とを備えることを特徴とする。
【００１８】
上記構成の画像処理装置によれば、エラー検出手段が実行エラーを検出すると、ログ抽出手段は、その際にジョブ実行手段が処理していたデータの処理部分を特定する情報と、当該実行エラーの発生時に当該データを処理していたアプリケーションを特定する情報とを抽出する。ここで、データの処理部分を特定する情報としては、例えばデータのファイル名や処理部分のアドレス等といった情報が挙げられる。また、アプリケーションを特定する情報としては、エラー発生時に動作していたアプリケーション名やその状態を特定するレジスタ値等といった情報が挙げられる。つまり、ログ抽出手段は、エラー発生時に処理されていたデータの処理部分を特定する情報と、その処理環境を特定する情報を抽出する。したがって、ログ抽出手段による抽出結果を、例えば不揮発性のメモリに格納したり外部装置に転送すれば、その格納内容または転送内容を基にエラー発生の原因特定が行えるようになる。
【００１９】
【発明の実施の形態】
以下、図面に基づき本発明に係る画像処理装置について説明する。
【００２０】
〔画像処理装置の一具体例の説明〕
【００２１】
先ず、画像処理装置の基本的な構成について説明する。図１は、画像処理装置の一具体例の基本構成を示すブロック図である。
【００２２】
ここで例に挙げて説明する画像処理装置（以下「本装置」という）は、ユーザからのジョブ要求等の操作指示を受け付けたり、本装置の動作状況等を表示したりする操作手段１と、この操作手段１等からの様々な画像入出力ジョブ要求を受け付けて複数のジョブの実行を制御するジョブ制御手段２と、画像入出力ジョブを実行する際に必要となる画像入出力手段３と、画像入出力ジョブの実行中の経過情報および実行結果情報をジョブ・ログとして管理するジョブ・ログ管理手段４と、画像入出力手段３により入出力される画像データやジョブ・ログ管理手段４により管理されるジョブ・ログ・データ等を記憶保存する記憶手段５と、これらを相互接続するシステムバス６と、によって構成される。また、本装置には、操作手段１とは別に、ＬＡＮ等のネットワーク７を介してコンピュータ装置（以下「ＰＣ」と略す）８上で動作するリモート操作手段９が接続されている。以下、これらの各手段を順に説明する。
【００２３】
操作手段１は、ユーザ・インタフェースを司る部分であり、表示画面および各種操作ボタンを備える。したがって、ユーザは、操作手段１の各種操作ボタンを押下することによって、本装置への画像入出力ジョブの実行要求、ジョブ状態確認、各画像入出力手段３の機器状態表示、等を行うことになる。例えば、コピー機能を実現する場合であれば、操作ボタンとして、コピー倍率やコピー部数等を指定するためのテンキー、用紙トレイ選択ボタン、コピースタートを行わせるためのスタートボタン、実行中の処理を一時停止させるためのストップボタン、全ての設定情報を初期化するクリアボタン、割り込みコピージョブを行わせるための割り込みボタン等が実装される。また、プリンタ機能やファクシミリ機能を実現する場合であれば、上記ボタンに加え、ネットワーク７との画像データの送受信を一時的に停止させるオフラインボタン、用紙入れ替え等の操作のために印刷中のジョブを一時停止させるポーズボタン（これはストップボタンと共用される場合もある）、ＦＡＸ主導送受信を行わせるための手動スタートボタン、電話番号を入力するためのテンキー（これはコピー倍率等を指定するテンキーと共用される場合もある）等が実装される。
【００２４】
また、ＰＣ８上で動作するリモートの操作手段９にも、必要に応じて上記ボタンが実装される。ただし、この場合、ローカルの操作手段１とは異なり、全てのボタンがハードウエアで構成されるわけではなく、ＰＣ８上のＧＵＩ（Graphical User Interface）機能によって実現される。このＧＵＩボタンを操作することによって、指定された各種ジョブ指示は、ネットワーク７を経由して本装置内に入力される。
【００２５】
ジョブ制御手段２は、ユーザが操作手段１、９等を操作することによって要求される各種画像入出力ジョブを複数受け付け、それらジョブの順序制御やスケジューリング処理を施し、実行開始可能なジョブについては画像入出力手段３の中から必要な資源を適切に選択して組み合わせ、それら画像入出力手段３に対して当該ジョブの実行指示を発行する機能を持つ。
【００２６】
また、ジョブ制御手段２は、受け付けたジョブについてはそのライフタイム（ジョブの生成から消滅までの期間）を管理し、ジョブのライフタイム内で適切なジョブ状態値を割り当て、その状態遷移を管理する。ジョブ状態値には、「Creating（生成中）」、「Pending（実行開始待ち中）」、「Processing（実行中）」、「Paused（一時停止中）」、「Terminating（強制終了処理中）」、「Completed（終了）」等の値があり、操作手段１，９等がジョブの要求をジョブ制御手段２に行っている最中は「Creating」、ジョブ制御手段２がジョブを受け付けそれが画像入出力手段３によって画像入出力処理が開始されるまでの期間を「Pending」、画像入出力手段３によって画像入出力処理が行われている期間を「Processing」、その「Processing」の期間に操作手段１，９等のストップボタン（ポーズボタン）押下によりジョブの実行が一時停止している期間を「Paused」、キャンセル（中止）ボタン押下によりジョブの実行を強制終了している期間を「Terminating」、ジョブが正常終了／異常終了した時点以降を「Completed」と割り当てる。
【００２７】
これら各ジョブ状態値は、操作手段１の表示パネルに表示させることにより、現時点でのジョブ状況を確認できることになる。また、ネットワーク制御部等の画像入出力手段３が外部機器にこの値を送出することによって、操作手段９等の外部機器からジョブ状況を確認することも可能となる。さらに、後述するジョブ・ログ管理手段４もこれらジョブ状態値を参照することによって適切なジョブ・ログ保存タイミングを知る。
【００２８】
画像入出力手段３は、詳細は図示しないが、ＩＩＴを制御し紙原稿情報をスキャンしてデジタル画像データを入力するＩＩＴ制御部、公衆回線に接続しＦＡＸ画像データを相手先ＦＡＸ装置１０と送受信するＦＡＸ制御部、ＬＡＮ等のネットワーク７と接続しＰＤＬや画像データファイルをＰＣ８と送受信するネットワーク制御部、ＭＯやＣＤ−ＲＷ等の外部記憶媒体に接続し画像データ等を読み書きする外部記憶媒体制御部、ＩＯＴを制御し装置内の画像データを用紙に印刷するＩＯＴ制御部、記憶手段５等の二次記憶媒体を制御し本装置内に入力された画像データを記憶手段５に蓄積する画像蓄積制御部、入力画像データがＰＤＬであったり圧縮画像データである場合に必要に応じてデコンポーザ／圧縮・伸長を行うデコンポーズ制御部および圧縮／伸長制御部、装置内の各種システムデータやユーザ登録データ等を参照してこの情報を印刷／送信するために画像データ化するレポート生成部、等がある。
【００２９】
これらの各部は、本装置の製品構成上、必要に応じて実装されるものである。例えば、コピー機能を実現する場合には、ＩＩＴ制御部並びにＩＯＴ制御部（必要に応じて画像蓄積制御部および圧縮／伸長制御部）が、画像入出力手段３として実装される。また、プリンタ機能を実現する場合には、ネットワーク制御部、デコンポーズ制御部並びにＩＯＴ制御部（必要に応じて画像蓄積制御部および圧縮／伸長制御部）が、画像入出力手段３として実装される。さらに、ＦＡＸ機能を実現する場合には、ＩＩＴ制御部、ＦＡＸ制御部並びにＩＯＴ制御部（必要に応じて画像蓄積制御部および圧縮／伸長制御部）が、画像入出力手段３として実装される。
【００３０】
ジョブ・ログ管理手段４は、ジョブ制御手段２によって管理される各種画像入出力ジョブの実行途中経過および処理結果を、ジョブ・ログとして管理し、必要に応じて記憶手段５に保存または更新する機能を持つ。
【００３１】
ここで、このジョブ・ログ管理手段４が管理するジョブ・ログの内容について、具体例を挙げて説明する。図２は、本装置で行うプリントジョブの場合におけるジョブ・ログの内容情報の一例を示す説明図である。
【００３２】
図中において、「ジョブ識別子」には、ジョブ制御手段２によって各ジョブ毎に一意に採番された値が設定される。「ジョブ・ログ更新日時」には、当該ジョブ・ログがジョブ・ログ管理手段４によって最終更新された日時が設定される。「終了日付」と「終了時刻」には、当該ジョブの処理が終了した日時が設定される。「ユーザ名」には、当該ジョブの実行要求を行ったユーザのユーザ名が設定される。「データ送信プロトコル」には、当該プリントジョブの処理対象データ（ＰＤＬ）を送受信する際に使用したプリンティング・プロトコル名が設定される。「カラーモード」、「用紙サイズ」および「用紙種類」には、当該プリントジョブの印刷時のカラーモード、印刷に使用した用紙のサイズおよび種類がそれぞれ設定される。「ページ数」および「枚数」には、当該プリントジョブで印刷処理した処理ページ数および使用した用紙枚数が設定される。「印字指定」には、当該プリントジョブの処理内容、具体的にはＮ−ｕｐ処理の有無、片面／両面印刷等の情報が設定される。「ジョブ処理状態」には、当該ジョブの終了状態、具体的には「正常終了」、「異常終了」、「シャットダウン」および「強制終了」といった情報が設定される。「処理状態詳細情報」には、上述の「ジョブ処理状態」の情報を補足するような情報、例えば異常終了／シャットダウン／強制終了した理由などが設定される。図例では、「ユーザ名Taro.Yamadaがlpdプロトコルを使用して要求したプリントジョブが、白黒モードでＡ４普通紙に１upで片面印刷を６ページ目まで処理完了し、２０００年９月１８日１４時２７分７秒に正常終了した。」という情報がジョブ・ログとして保持・管理されることを示している。
【００３３】
また図１において、記憶手段５は、ＨＤＤやＮＶＲＡＭ（Nonvolatile Random Access Memory）等の不揮発性メモリを記憶媒体とし、画像入出力手段３を構成する画像蓄積制御部およびジョブ・ログ管理手段４によって制御される。画像蓄積制御部が制御する場合には、記憶手段５に対する画像データの読み書きが行われる。また、ジョブ・ログ管理手段４が制御する場合には、記憶手段５に対するジョブ・ログ・データの読み書きが行われる。
【００３４】
記憶手段５の内部には、画像データ、ジョブ・ログ・データ用にそれぞれ独立した領域が確保される。例えば、ＨＤＤの場合には、画像データ用とジョブ・ログ・データ用の別パーティションが構築される。また、ＮＶＲＡＭの場合には、独立したメモリ空間を持つ。さらに、ジョブ・ログ・データ用の領域は、途中経過ジョブ・ログ用領域と処理結果ジョブ・ログ用領域の２つに分けて管理される。例えば、ＨＤＤの場合には、ジョブ・ログ・データ用パーティション内に、途中経過ジョブ・ログ用ディレクトリと処理結果ジョブ・ログ用ディレクトリの２つが作成され、それぞれが独立して管理される形式をとる。
【００３５】
次に、以上のように構成された本装置における処理動作例、特にジョブ・ログ管理手段４が行うジョブ・ログ保存・更新の処理動作例について説明する。図３は、ジョブ・ログ保存・更新の処理動作例を示すフローチャートである。
【００３６】
本装置の起動後、ジョブ・ログ管理手段４は、ジョブ制御手段２によって管理される各ジョブのジョブ状態値をモニタし、いずれかのジョブに何らかのジョブ状態の遷移が発生したか否かを、常時チェックしている（ステップ１０１、以下ステップを「Ｓ」と略す）。そして、ジョブ状態の遷移がなければ、さらに、画像入出力手段３が発行するログ更新イベントが発生したか否かのチェックを行う（Ｓ１０２）。
【００３７】
ここで、ログ更新イベントとは、画像入出力手段３がジョブ実行中に発生させるものであり、ジョブ・ログに記録または更新すべき情報が検出されたタイミングで発生される。例えば、図２に示した項目からなるジョブ・ログの情報を更新する場合について考えると、画像入出力手段３を構成するＩＯＴ制御部は、特定のジョブの印刷処理を行っている期間中に印刷用紙の用紙サイズ、カラーモード、用紙種類、印字指定等といった情報を検出するので、その時点でログ更新イベントを発行して、検出した内容のジョブ・ログへの記録をジョブ・ログ管理手段４に要求する。さらに、ＩＯＴ制御部は、印刷処理したページ数や消費した印刷用紙の枚数が増加する度にログ更新イベントを発行する。これと同様に、例えば、画像入出力手段３を構成するネットワーク制御部では、ＰＣ８等から送られてくるプリントデータ（ＰＤＬ）を受信した時点で、当該ジョブのユーザ名、データ送信プロトコル等の情報を検出するので、その時点でログ更新イベントを発行して、検出した内容のジョブ・ログへの記録をジョブ・ログ管理手段４に要求する。なお、ログ更新イベントの発行および受信には、ソフトウエアで実現されるＩＰＣ（interprocessor communication）メッセージ通信等を用いればよい。
【００３８】
ところで、図３において、ジョブ状態の遷移チェックの結果（Ｓ１０１）、いずれかのジョブに何らかのジョブ状態の遷移が発生したことを検出した場合には、ジョブ・ログ管理手段４は、そのジョブ状態値を調べる。そして、ジョブ状態値が「Creating」状態であれば（Ｓ１０３）、ジョブ・ログ管理手段４は、そのジョブのジョブ識別子をジョブ制御手段２から取得し（Ｓ１０４）、記憶手段５内の途中経過ジョブ・ログ用領域内から当該ジョブの途中経過ジョブ・ログを記録するための領域を確保した後に（Ｓ１０５）、その領域の「ジョブ識別子」フィールドに取得したジョブ識別子をセットする。
【００３９】
また、ジョブ状態値が「Processing」状態であれば（Ｓ１０６）、ジョブ・ログ管理手段４は、途中経過ジョブ・ログの更新処理を行う（Ｓ１０７）。これは、「Creating」状態になったときに領域確保した途中経過ジョブ・ログ用領域に、図２に例示したような当該ジョブの各種情報をセットする処理である。例えば、図２中に示したジョブ・ログ情報のうち「ジョブ・ログ更新日時のみ」をセットし、他の情報は何も更新しない。
【００４０】
この時点で、「Processing」状態になったジョブは、画像入出力手段３によって画像入出力処理を施されている。そのため、画像入出力手段３からは、非同期にログ更新イベントが発生する。ジョブ・ログ管理手段４は、先に述べたチェック（Ｓ１０２）によってそのログ更新イベントを検出するので、上述のステップ（Ｓ１０７）で更新した途中経過ジョブ・ログをさらに更新する処理を行う（Ｓ１０８）。例えば、ログ更新イベントの発生源がＩＯＴ制御部だった場合には、図２のジョブ・ログ情報のうち、「カラーモード」、「用紙サイズ」、「用紙種類」、「ページ数」、「枚数」、「印字指定」フィールドを最新の情報に更新する。また、ログ更新イベントの発生源がネットワーク制御部だった場合には、図２のジョブ・ログ情報のうち、「ユーザ名」、「データ送信プロトコル」フィールドを最新の情報に更新する。最新の情報に更新する際には、常に「ジョブ・ログ更新日時」フィールドに更新日時をセットする。
【００４１】
また、ジョブ状態の遷移チェックの結果、ジョブ状態値が「Completed」状態であれば（Ｓ１０９）、ジョブ・ログ管理手段４は、ジョブ・ログのうちの終了日時に関する情報、例えば図２中に示したジョブ・ログ情報のうちの「終了日付」および「終了時刻」フィールドを更新する（Ｓ１１０）。さらに、ジョブ・ログ管理手段４は、終了したジョブの終了状態をジョブ制御手段２に問い合わせ、「ジョブ処理状態」および「処理状態詳細情報」フィールドにその値をセットする（Ｓ１１１）。このとき、ジョブ制御手段２は、当該ジョブの終了状態として「正常終了」、「異常終了」または「強制終了」といった情報を、また終了状態の詳細情報として「問題なく終了」、「エラー終了」、「警告付き終了」、「ユーザ要求によるキャンセル」、「オペレータ要求によるキャンセル」または「システム判断によるアボート」といった情報を、それぞれジョブ・ログ管理手段４に通知する。したがって、ジョブ・ログ管理手段４は、これらの情報に基づきジョブ・ログを更新することになる。
【００４２】
その後、ジョブ・ログ管理手段４は、記憶手段５内の処理結果ジョブ・ログ用領域から当該ジョブ用の領域を確保し、確保した領域に途中経過ジョブ・ログに書かれた全情報をコピーするとともに、当該ジョブ用に確保された途中経過ジョブ・ログの領域を廃棄する（Ｓ１１２）。この処理によって、実行開始されたジョブの途中経過ジョブ・ログは、そのジョブの実行期間中は途中経過ジョブ・ログ用領域に保存されることになる。
【００４３】
このとき、例えばジョブの実行期間中に電源断エラーが発生すると、その時点までに終了している処理内容が途中経過ジョブ・ログに記録されたままの状態になる。そして、その次に電源投入されるまで、当該途中経過ジョブ・ログが途中経過ジョブ・ログ領域に残ることになる。したがって、この残存した途中経過ジョブ・ログを利用すれば、次回電源投入時の初期化処理時に、電源断直前までのジョブの情報を処理結果ジョブ・ログとして復旧させることが可能である。この処理は、ジョブ・ログ管理手段４の電源投入時の初期化処理によって行われる。
【００４４】
ここで、ジョブ・ログ管理手段４が電源投入（初期化処理）時に行う、処理結果ジョブ・ログ復旧の処理動作例について説明する。図４は、ジョブ・ログ管理手段の初期化時の処理動作例を示すフローチャートである。
【００４５】
本装置の電源が投入された時点で、ジョブ・ログ管理手段４は、記憶手段５内の途中経過ジョブ・ログ用領域を検索し（Ｓ２０１）、残存する途中経過ジョブ・ログが存在するか否かをチェックする（Ｓ２０２）。
【００４６】
このチェックの結果、残存する途中経過ジョブ・ログが存在した場合、図２に例示したジョブ・ログ内容であれば、その途中経過ジョブ・ログは、次に述べるような情報を持っていることになる。図５は、実行途中で電源断されたジョブの残存ジョブ・ログの内容情報の一例を示す説明図である。図例は、「Hanako.YamadaというユーザがSMBプロトコルを使用して投入したプリントジョブが、２０００年９月１９日１０時５分３秒までにカラーモードでＡ４普通紙に１up片面で３ページ目まで印刷処理完了したが、その後の処理を行っている最中に電源断された」という状態を表している。
【００４７】
この場合、ジョブ終了前、すなわちジョブ状態値が「Completed」になる前に電源断されたため、先に説明したジョブ・ログの終了日時に関する情報の更新等（図３におけるＳ１１０〜Ｓ１１２参照）の処理は行われない。つまり、図５中の「終了日付」、「終了時刻」、「ジョブ処理状態」および「処理状態詳細情報」フィールドには、何も情報が記録されていない。
【００４８】
このことから、ジョブ・ログ管理手段４は、図４に示すように、「ジョブ・ログ更新日時」フィールドにセットされている値（図５の例では２０００／０９／１９ １０:０５:０３）を、「終了日付」および「終了時刻」フィールドにコピーし（Ｓ２０３）、さらに「ジョブ処理状態」フィールドには「シャットダウン」という情報を表すための値を、「処理状態詳細情報」フィールドには「システム停止のため異常終了しました」といったメッセージを表すための情報値をそれぞれセットする（Ｓ２０４）。
【００４９】
これにより、図５に示した残存ジョブ・ログは、図６に示すような情報を持つことになる。図６は、残存ジョブ・ログに基づき生成された処理結果ジョブ・ログの内容情報の一例を示す説明図である。
【００５０】
その後、ジョブ・ログ管理手段４は、図４に示すように、記憶手段５内の処理結果ジョブ・ログ用領域から当該ジョブ用の領域を確保し、確保した領域に、残存ジョブ・ログに書かれた全情報をコピーするとともに、当該残存ジョブ・ログ用が使用していた途中経過ジョブ・ログ領域を廃棄する（Ｓ２０５）。この処理を、ジョブ・ログ管理手段４は、残存ジョブ・ログ全てに対して繰り返し行う。こうすることで、電源断エラーによって実行途中で異常終了したジョブの情報は、次回電源投入時に残存ジョブ・ログとして途中経過ジョブ・ログ領域に保持されていて、その情報に基づき電源断直前までの処理内容に基づいた処理結果ジョブ・ログが生成されることになる。
【００５１】
以上の説明から明らかなように、本装置では、実行中のジョブの途中経過をジョブ・ログとして所定のタイミングで不揮発性の記憶手段５の内部の途中経過ジョブ・ログ用領域に保存または更新するとともに、ジョブが終了したときにはその途中経過ジョブ・ログ用領域に保存されているジョブ・ログを処理結果ジョブ・ログ用領域に移し替え、そしてジョブ実行途中で予期せぬ電源断エラーが発生した場合には、その次の電源投入時の初期化処理時に、途中経過ジョブ・ログ用領域のジョブ・ログを、全て処理結果ジョブ・ログ用領域に移動する処理を行うようになっている。つまり、本装置では、ジョブの実行途中経過に関するジョブ・ログを記憶手段５内の途中経過ジョブ・ログ用領域に保存するが、その記憶手段５は不揮発性であるため、予期せぬ電源断エラーが発生しても、途中経過ジョブ・ログ用領域に保存されたジョブ・ログが消失してしまうことがない。
【００５２】
そのため、本装置によれば、電源断エラーの回復時または回復後に、途中経過ジョブ・ログ用領域内のジョブ・ログを処理結果ジョブ・ログ用領域内に移し替えることで、電源断エラーによって途中終了した処理ジョブについても、その実行履歴が処理結果ジョブ・ログ用領域内に残ることになる。つまり、本装置を用いれば、ユーザは、処理結果ジョブ・ログ用領域内のジョブ・ログを参照することで、自分の要求したジョブが正常終了したか、実行途中で異常終了したか、あるいは未だ実行開始されていないのか、といった判断を容易かつ的確に行うことができるようになる。
【００５３】
しかも、本装置では、途中経過ジョブ・ログ用領域内のジョブ・ログを処理結果ジョブ・ログ用領域内に移し替える際に、そのジョブ・ログの保存または最終更新時刻に関する情報と、電源断エラーによる異常終了であることを表すメッセージとを、それぞれ併せて処理結果ジョブ・ログ用領域内に記憶させるようになっている。したがって、処理結果ジョブ・ログ用領域内のジョブ・ログを参照すれば、実行途中での異常終了があっても、それが電源断エラーによる異常終了であること、および、その異常終了がいつあったかが明確化される。
【００５４】
その上、例えば本装置を用いて課金情報、ユーザ別情報、部門別情報等を集計するシステムを構築した場合には、電源断エラーの直前までに完了していた画像入出力ジョブの内容が、たとえジョブが終了していなくてもジョブ・ログとして記録されるので、電源断エラーによる実行途中ジョブの情報消失が発生することがなく、集計結果の信頼性が上がり、被害損失が増大化も防止できるようになる。
【００５５】
なお、ここでは、ジョブ・ログに記載する情報としてプリントジョブの場合における内容情報を例に挙げて説明したが、他の情報、例えば画像入出力手段３の一部を構成するＦＡＸ制御部が検出する「ＦＡＸ送信元電話番号」といった情報であっても、ログ更新イベントを発行・受信できることは、上述した説明からも明らかである。すなわち、ジョブ・ログのログ更新イベントおよび記載するジョブ・ログの内容情報は、上述した説明の内容に限定されるものではなく、プリンタジョブ以外にも、コピージョブ、ＦＡＸジョブ、その他の画像処理装置が行うジョブに適用できる。
【００５６】
〔本発明の実施の形態の説明〕
次に、本発明に係る画像処理装置について説明する。ただし、本実施形態では、本発明を、コピージョブ、スキャンジョブ、プリントジョブ、ＦＡＸジョブ等といった各種ジョブの実行が可能なＭＦ機ではなく、プリントジョブのみが実行可能なプリンタ装置に適用した場合を例に挙げて説明する。
【００５７】
ここでは、先ず、本発明が適用されたプリンタ装置の基本的な構成について説明する。図７は、本発明に係る画像処理装置の構成例を示すブロック図である。
【００５８】
本実施形態で説明するプリンタ装置は、ＬＡＮ等のネットワーク２０を介して、ＰＣ等からなる複数のクライアント装置（ただし不図示）が接続されており、そのクライアント装置から発行されたプリンタジョブを受け付けて、これを処理実行するものである。そのために、プリンタ装置は、ネットワークインタフェース部３１と、システム制御部３２と、メモリ管理部３３と、印刷処理管理部３４と、画像データ展開処理部３５と、記録出力部３６と、記録出力制御部３７と、操作制御部３８と、操作パネル３９と、ログ情報処理部４０と、によって構成される。以下、これらの各部を順に説明する。
【００５９】
ネットワークインタフェース部３１は、ネットワーク２０を介してデータの送受信を行うものであり、ネットワークインタフェース部３１内のネットワーク通信制御部３１ａによる制御に従いつつ、ネットワーク２０上のクライアント装置から受信データである画像データやコードデータ等を受信して、その受信データをネットワークインタフェース部３１内の受信データ処理部３１ｂに渡す処理を行っている。そして、受信データ処理部３１ｂは、受け取った受信データを後述する蓄積装置３３ｃに蓄積させたり、その蓄積装置３３ｃ内から画像データを取り出して印刷処理管理部３４に印刷処理の要求を行ったりする。なお、ネットワークインタフェース部３１がデータの送受信を行う際に用いられるプロトコルおよびネットワークＯＳとしては、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）や、米国ノベル（Novell）社が開発したNetWare等がある。
【００６０】
システム制御部３２は、プリンタ装置全体の動作制御を行うものであり、電源起動時の初期化処理を行ったり、プリンタ装置を構成する各部のハード的なエラーを検出したりしている。
【００６１】
メモリ管理部３３は、各種データを記憶保持する機能を有したリングバッファ３３ａ、ページメモリ３３ｂ、蓄積装置３３ｃおよびＮＶＲＡＭ３３ｄを管理している。リングバッファ３３ａは、ネットワークインタフェース部３１が動作する際に必要となるデータ送受信用のメモリである。ページメモリ３３ｂは、後述する画像データ展開処理部３５がビットマップ画像データへの展開処理を行う際に用いられるページ単位のメモリである。蓄積装置３３ｃは、受信データ処理部３１ｂから受け取った受信データやログ情報処理部４０が管理するログの履歴情報等を格納するものである。ＮＶＲＡＭ３３ｄは、ログ情報処理部４０が管理するログ情報や操作パネル３９から設定された設定情報等を記憶するものである。なお、蓄積装置３３ｃとしてはＨＤＤを、またＮＶＲＡＭ３３ｄとしては不揮発性のＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）を、それぞれ用いることが考えられる。
【００６２】
印刷処理管理部３４は、受信データ処理部３１ｂが受け取った画像データの印刷出力処理に関する動作制御を行うものである。例えば、印刷処理管理部３４では、ネットワーク２０上のクライアントホスト装置から順次送られてくる画像データをその到着順に印刷出力するためのスケジューリング処理を行う。
【００６３】
画像データ展開処理部３５は、受信データ処理部３１ｂが受け取った画像データに対し、これを印刷出力可能なデータ形式であるビットマップ画像データに展開するものである。
【００６４】
記録出力部３６は、画像データ展開処理部３５によって展開されたビットマップ画像データを記録紙上に印刷出力するものであり、周知技術であるレーザービームの静電記録方式を用いての印刷出力を行うものである。
【００６５】
記録出力制御部３７は、さらに詳しくは記録出力部３６における処理動作の一時停止および再開や、記録出力部が印刷出力するページ順の制御等といった、記録出力部３６の動作制御を行うものである。
【００６６】
操作制御部３８は、プリンタ装置のユーザが操作する操作パネル３９またはネットワーク２０上のクライアント装置から指示される設定情報を、印刷処理管理部３４やシステム制御部３２に通知する処理を行うものである。
【００６７】
ログ情報処理部４０は、記録出力部３６での印刷出力の結果に関する情報や、プリンタ装置で発生したエラーに関する情報等を、ログ情報として管理するものであり、さらにはそのログの履歴情報を管理するものである。そのために、ログ情報処理部４０は、エラー情報検出部４１と、印刷情報検出部４２と、ログ情報記録制御部４３と、ログ処理情報制御部４４と、から構成される。
【００６８】
エラー情報検出部４１は、記録出力部３６で発生する記録紙の搬送にかかわる障害情報や、画像データ展開処理部３５で発生するビットマップ画像データ生成にかかわる障害情報や、ネットワーク通信制御部で発生するネットワークに関する障害情報等を、各部からメッセージとして受信して検出するものである。
【００６９】
印刷情報検出部４２は、記録出力部３６で印刷出力する部数、カラー／白黒の別、印刷出力を指示したユーザ名、その印刷出力の結果等といった印刷出力の属性に関する情報を、印刷出力を行うジョブ単位毎に検出するものである。
【００７０】
ログ情報記録制御部４３は、エラー情報検出部４１および印刷情報検出部４２で検出された情報を、ログ情報またはログの履歴情報として、ＮＶＲＡＭ３３ｄまたは蓄積装置３３ｃに記憶させるものである。なお、ログ情報記録制御部４３では、記録数が予め定められた規定値に達した場合に最も古いログを削除するといったように、ログの記憶制御をも行うようになっている。
【００７１】
ログ処理情報制御部４４は、エラー情報検出部４１および印刷情報検出部４２での検出内容に基づいて、必要に応じて詳細を後述するような所定処理を行うものである。なお、ログ処理情報制御部４４が行う処理の内容は、少なくとも１種類、好ましくは複数種類がコード番号によって識別可能な状態で、事前に登録されているものとする。
【００７２】
次に、以上のように構成されたプリンタ装置における処理動作例、特にログ情報処理部４０が行うログ管理の処理動作例について説明する。
【００７３】
先ず、第一の処理動作例について説明する。本処理動作例は、請求項１に記載の発明に対応するものである。図８は、ログ管理を行う際の第一の処理動作例を示すフローチャートである。
【００７４】
ログ情報処理部４０は、システム制御部３２をはじめとした他部からの処理要求メッセージを受け取った動作する構成となっており、定常状態ではメッセージ待ち状態となっている。その状態で他部からの処理要求メッセージを受け取ると（Ｓ３０１）、ログ情報処理部４０は、受信したメッセージの解析処理を行う（Ｓ３０２）。そして、エラー情報検出部４１が、解析したメッセージがエラー検出メッセージであるか否かの判別を行う（Ｓ３０３）。この判別については、周知技術を利用して行えばよいため、ここではその説明を省略する。
【００７５】
この判別の結果、エラー検出メッセージでなければ、ログ情報処理部４０は、受信したメッセージに応じた処理を行い（Ｓ３０４）、再びメッセージ待ち処理に戻る。受信したメッセージに応じた処理としては、例えば正常に終了した印刷出力の結果等をログ情報として記憶させる処理、すなわち一般的に行われているログの記録処理が挙げられる。
【００７６】
一方、解析したメッセージがエラー検出メッセージである場合には、ログ情報処理部４０では、印刷情報検出部４２が印刷状況の確認処理を実施する（Ｓ３０５）。つまり、印刷情報検出部４２は、エラー情報検出部４１によって何らかのエラー発生が検出されると、その際にプリンタ装置内のいずれかで印刷のためのデータ処理が行われている最中であるか否かを判断する（Ｓ３０６）。
【００７７】
そして、データ処理中であれば、印刷情報検出部４２は、当該処理中であるデータの位置情報を取得する（Ｓ３０７）。例えば、画像データ展開処理部３５が蓄積装置３３ｃ内の画像データを取り出して画像展開処理を行ってページメモリ３３ｂへ格納している最中にその展開エラーが発生すると、印刷情報検出部４２は、そのエラー発生時点で画像データ展開処理部３５が処理していた画像データのファイル名、処理していた部分の先頭からのサイズ、処理していた部分のアドレスに関する情報等を、データの処理部分に関する情報として画像データ展開処理部３５から取得する。
【００７８】
さらに、印刷情報検出部４２は、エラー発生時に実行中のアプリケーション情報を取得する（Ｓ３０８）。ここで、アプリケーション情報とは、エラー発生時に実行中のアプリケーション、すなわちエラー発生時にデータを処理していたアプリケーションに関する情報のことをいい、具体的にはアプリケーション名やその実行状態を特定するレジスタ値等といった情報のことをいう。例えば、NetWareによる受信データに対する処理の実行中にエラーが発生すると、そのエラー発生時に実行中のアプリケーション名は、NetWareということになる。
【００７９】
その後、ログ情報処理部４０では、印刷情報検出部４２が取得したデータの位置情報およびアプリケーション情報を基にログ処理情報制御部４４がログ情報の生成を行い、ログ情報記録制御部４３がその生成されたログ情報をＮＶＲＡＭ３３ｄに格納する（Ｓ３０９）。また、このときに、ログ情報記録制御部４３は、エラー情報検出部４１が解析したメッセージについても、エラーに関するログ情報としてＮＶＲＡＭ３３ｄに格納する（Ｓ３１０）。
【００８０】
これにより、ＮＶＲＡＭ３３ｄ内には、エラー発生時におけるデータの処理部分に関する位置情報と、そのデータのアプリケーション情報とが、ログ情報として抽出されて記憶保持されることになる。つまり、ＮＶＲＡＭ３３ｄ内には、エラー発生時に処理されていたデータの処理部分を特定するための情報とその処理環境に関する情報とが抽出されて記憶保持されることになる。
【００８１】
したがって、ＮＶＲＡＭ３３ｄに記憶保持されたログ情報を読み出すとともに、エラー発生時に処理対象となっていたデータを蓄積装置３３ｃから読み出して、これらを比較参照すれば、読み出したデータが膨大な量であっても、その中からログ情報によってエラーの発生箇所やその原因等を容易に特定することができるようになる。しかも、ログ情報にはアプリケーション情報も含まれているので、そのログ情報によってエラー発生時のデータ処理環境も分かるようになり、各種データの処理シーケンス等にエラーの原因がある場合であっても、そのエラー原因を的確に特定することができる。
【００８２】
これらのことから、上述した第一の処理動作例を実施するプリンタ装置においては、エラー発生時に処理していたデータとこれを処理するアプリケーション（ソフトウエアモジュール）の動作とを関連付けてログ情報として抽出して保存することにより、エラー発生の原因特定のための情報収集を的確に行え、しかも収集した情報からエラー発生の原因特定を迅速に行えるようになる。
【００８３】
続いて、第二の処理動作例について説明する。本処理動作例は、請求項２に記載の発明に対応するものである。なお、ここでは、上述した第一の処理動作例との相違点を中心に説明するものとする。図９は、ログ管理を行う際の第二の処理動作例を示すフローチャートである。
【００８４】
ここで説明する第二の処理動作例においても、第一の処理動作例の場合と同様に、受け取ったメッセージがエラー検出メッセージでなければ、ログ情報処理部４０は、受信したメッセージに応じた処理を行う（Ｓ４０１〜Ｓ４０４）。
【００８５】
ただし、受け取って解析したメッセージがエラー検出メッセージである場合には、第一の処理動作例の場合と異なり、ログ情報処理部４０では、そのエラー検出メッセージを解析して、そのエラー番号を特定する（Ｓ４０５）。ここで、エラー番号とは、エラーの種類に対応して一義的に定められたコード番号のことをいう。このようなエラー番号は、エラー検出メッセージに包含されて送られてくるものとする。
【００８６】
エラー番号を特定すると、その後、ログ処理情報制御部４４は、そのエラー番号に応じて行うべき処理の内容が事前に登録されているか否かを検索し（Ｓ４０６）、該当する処理があれば（Ｓ４０７）、そのエラー番号に対応する処理を実行する（Ｓ４０８）。ここで実行する処理としては、例えば、ある特定の種類のエラーが発生した場合には、そのエラー発生によって抽出されるログ情報等を外部装置に転送する、といった処理が考えられる。さらに具体的には、例えばネットワークインタフェース部３１で通信エラーが発生した場合には、その通信エラーによって抽出されるログ情報等を、通信相手であるクライアント装置へ転送したり、ネットワーク２０上に設けられたデータ解析装置等へ転送する、といった処理が考えられる。
【００８７】
その後、ログ情報処理部４０では、ログ情報抽出等のために、第一の処理動作例の場合と同様の手順で処理動作を行う（Ｓ４０９〜Ｓ４１４）。
【００８８】
このように、上述した第二の処理動作例を実施するプリンタ装置においては、第一の処理動作例の場合に加えて、エラー発生を検出した際にそのエラーの種類を特定し、かつ、特製した種類に対応した処理を実行する機能を有している。したがって、データの処理部分に関する位置情報とそのデータのアプリケーション情報とを含むログ情報に対し、エラーの種類に応じて異なる処理を施すことができるので、様々なエラー種類に対する適応性を確保でき、どのような種類のエラーに対しても適切な対応を行うことが可能となる。
【００８９】
次いで、第三の処理動作例について説明する。本処理動作例は、請求項３に記載の発明に対応するものである。なお、ここでも、上述した第一または第二の処理動作例との相違点を中心に説明するものとする。図１０は、ログ管理を行う際の第三の処理動作例を示すフローチャートである。
【００９０】
ここで説明する第三の処理動作例においても、第一および第二の処理動作例の場合と同様に、受け取ったメッセージがエラー検出メッセージでなければ、ログ情報処理部４０は、受信したメッセージに応じた処理を行う（Ｓ５０１〜Ｓ５０４）。
【００９１】
ただし、受け取って解析したメッセージがエラー処理登録要求メッセージである場合には、第一または第二の処理動作例の場合と異なり、ログ情報処理部４０では、そのエラー処理登録要求メッセージを解析して、そのエラー番号を特定する（Ｓ５０５）。
【００９２】
ここで、エラー処理登録要求メッセージとは、プリンタ装置の操作制御部３８またはネットワーク２０上のクライアント装置から発行されるもので、ログ処理情報制御部４４がエラーの種類の対応して行う処理の内容を、ユーザ等がログ処理情報制御部４４に対して登録するためのものである。そのため、このエラー処理登録要求メッセージは、処理の内容に加えて、登録対象となるエラー種類を特定するためのエラー番号が包含されて、操作制御部３８またはクライアント装置から送られてくるものとする。
【００９３】
エラー処理登録要求メッセージに包含されるエラー番号を特定した後は、ログ処理情報制御部４４は、そのエラー番号に対応した処理テーブルを検索する（Ｓ５０６）。この処理テーブルとは、ログ処理情報制御部４４が有しているテーブルのことをいい、エラー番号と処理内容との対応関係が登録されている。
【００９４】
そして、検索の結果、エラー番号に対応した領域が処理テーブル内に存在していれば（Ｓ５０７）、ログ処理情報制御部４４は、エラー処理登録要求メッセージに包含される処理内容を、その領域内に登録（上書き）し（Ｓ５０８）、登録が完了した旨のメッセージをその要求元、すなわちエラー処理登録要求メッセージを発行した操作制御部３８またはクライアント装置へ返信する（Ｓ５０９）。一方、エラー番号に対応した領域が処理テーブル内に存在していない場合には、ログ処理情報制御部４４は、その旨のエラーメッセージを要求元へ返信する（Ｓ５１０）。
【００９５】
このように、上述した第三の処理動作例を実施するプリンタ装置においては、エラー発生を検出した際に、そのエラーの種類の対応して行うべき処理の内容を、ユーザ等が任意に設定することができるようになる。したがって、様々なエラー種類に対する適応性がより一層増し、エラー発生に対する処理の柔軟性も向上することになる。
【００９６】
次いで、第四の処理動作例について説明する。本処理動作例は、請求項４に記載の発明に対応するものである。なお、ここでも、上述した第一〜第三の処理動作例との相違点を中心に説明するものとする。図１１は、ログ管理を行う際の第三の処理動作例を示すフローチャートである。
【００９７】
ここで説明する第四の処理動作例においても、第一〜第三の処理動作例の場合と同様に、受け取ったメッセージがエラー検出メッセージでなければ、ログ情報処理部４０は、受信したメッセージに応じた処理を行う（Ｓ６０１〜Ｓ６０４）。
【００９８】
ただし、受け取って解析したメッセージがエラー処理の選択要求メッセージである場合には、第一〜第三の処理動作例の場合と異なり、ログ情報処理部４０では、そのエラー処理の選択要求メッセージを解析して、そのエラー番号を特定する（Ｓ６０５）。
【００９９】
ここで、エラー処理の選択要求メッセージとは、プリンタ装置の操作制御部３８またはネットワーク２０上のクライアント装置から発行されるもので、ログ処理情報制御部４４の処理テーブルに複数の処理内容が登録されている場合に、これら複数の処理内容の中からログ処理情報制御部４４が行う処理内容を、ユーザ等が選択するためのものである。そのため、このエラー処理の選択要求メッセージは、エラー種類を特定するためのエラー番号およびこれに対応する処理内容に加えて、そのエラー番号に対応する処理内容の実行可否を表すフラグ（実行可否フラグ）が包含されて、操作制御部３８またはクライアント装置から送られてくるものとする。
【０１００】
エラー処理の選択要求メッセージに包含されるエラー番号を特定した後は、ログ処理情報制御部４４は、そのエラー番号に対応した処理テーブルを検索する（Ｓ６０６）。この処理テーブルとは、第三の処理動作例で説明したのと同様のものであるが、エラー番号と処理内容との対応関係に加えて、各処理内容別に実行可否フラグの有無（または「１」or「０」）が登録されている。
【０１０１】
そして、検索の結果、該当するエラー番号およびこれに対応する処理内容が処理テーブル内に存在していれば（Ｓ６０７）、ログ処理情報制御部４４は、その処理内容の実行可否フラグを実行可状態に変更または設定し（Ｓ６０８）。処理内容の選択が完了した旨のメッセージをその要求元、すなわちエラー処理の選択要求メッセージを発行した操作制御部３８またはクライアント装置へ返信する（Ｓ６０９）。一方、該当するエラー番号およびこれに対応する処理内容が処理テーブル内に存在していない場合には、ログ処理情報制御部４４は、その旨のエラーメッセージを要求元へ返信する（Ｓ６１０）。
【０１０２】
このように、上述した第四の処理動作例を実施するプリンタ装置においては、エラー発生を検出した際に、そのエラーの種類の対応して行うべき処理の内容を、ユーザ等が任意に選択することができるようになる。したがって、本処理動作例の場合も、様々なエラー種類に対する適応性がより一層増し、エラー発生に対する処理の柔軟性も向上することになる。
【０１０３】
具体的には、例えば、ネットワークインタフェース部３１で発生する通信エラーについて、これに対応する処理内容として、ログ情報をＴＣＰ／ＩＰに準拠してネットワーク２０上へブロードキャストする処理と、ログ情報をNetWareプロトコルに準拠してネットワーク２０上に設けられたデータ解析装置等へ転送する処理とが登録されている場合に、どちらの処理を行うか選択できるようになる。これにより、一方の処理ではエラー解析が困難な場合であっても、他方の処理への選択切り替えによって、そのエラー解析を行えるようになることも考えられる。
【０１０４】
次いで、第五の処理動作例について説明する。本処理動作例は、請求項５に記載の発明に対応するものである。なお、ここでも、上述した第一〜第四の処理動作例との相違点を中心に説明するものとする。図１２は、ログ管理を行う際の第三の処理動作例を示すフローチャートである。
【０１０５】
ここで説明する第五の処理動作例においても、第一〜第四の処理動作例の場合と同様に、受け取ったメッセージがエラー検出メッセージでなければ、ログ情報処理部４０は、受信したメッセージに応じた処理を行う（Ｓ７０１〜Ｓ７０４）。
【０１０６】
ただし、受け取って解析したメッセージがエラー処理の処理順位変更要求メッセージである場合には、第一〜第四の処理動作例の場合と異なり、ログ情報処理部４０では、そのエラー処理の処理順位変更要求メッセージを解析して、そのエラー番号を特定する（Ｓ７０５）。
【０１０７】
ここで、エラー処理の処理順位変更要求メッセージとは、プリンタ装置の操作制御部３８またはネットワーク２０上のクライアント装置から発行されるもので、ログ処理情報制御部４４の処理テーブルに一つのエラー番号当たり複数の処理内容が登録されている場合に、これら複数の処理内容の中からログ処理情報制御部４４が行う処理の実行順を、ユーザ等が選択するためのものである。そのため、このエラー処理の処理順位変更要求メッセージは、エラー種類を特定するためのエラー番号およびこれに対応する処理内容に加えて、各処理内容についてのプライオリティ（優先順）情報が包含されて、操作制御部３８またはクライアント装置から送られてくるものとする。
【０１０８】
エラー処理の処理順位変更要求メッセージに包含されるエラー番号を特定した後は、ログ処理情報制御部４４は、そのエラー番号に対応した処理テーブルを検索する（Ｓ７０６）。この処理テーブルとは、第三の処理動作例で説明したのと同様のものであるが、エラー番号と処理内容との対応関係に加えて、各処理内容別にプライオリティ情報が登録されている。
【０１０９】
そして、検索の結果、該当するエラー番号が処理テーブル内に存在しており、かつ、そのエラー番号に対応する処理内容の中で第四の処理動作例で説明したような選択された処理内容があれば（Ｓ７０７）、ログ処理情報制御部４４は、その処理内容の実行順位、すなわちその処理内容についてのプライオリティ情報を変更する（Ｓ７０８）。その後、ログ処理情報制御部４４は、他に実行順位を変更する処理内容があるか否かを判断して（Ｓ７０９）、他にあれば再びその処理内容について上述したステップ（Ｓ７０７〜Ｓ７０９）を繰り返す。ただし、他に順位の変更が必要な処理内容がなければ、ログ処理情報制御部４４は、処理テーブルへの登録が完了した旨のメッセージをその要求元、すなわちエラー処理の選択要求メッセージを発行した操作制御部３８またはクライアント装置へ返信する（Ｓ７１０）。
【０１１０】
また、選択された処理内容が処理テーブル内に存在していない場合には、ログ処理情報制御部４４は、その旨のエラーメッセージを要求元へ返信して（Ｓ７１１）、再びメッセージ待ち処理に戻る。
【０１１１】
このように、上述した第五の処理動作例を実施するプリンタ装置においては、エラー発生を検出した際に、そのエラーの種類の対応して複数の処理を行うことが可能となり、しかもその複数の処理の実行順をユーザ等が任意に選択することができるようになる。したがって、本処理動作例の場合においても、様々なエラー種類に対する適応性がより一層増し、エラー発生に対する処理の柔軟性も向上することになる。
【０１１２】
具体的には、例えば、ネットワーク２０がルータを介して接続された複数のＬＡＮからなる場合に、各ＬＡＮに向けたログ情報のブロードキャストを、所定の優先順に従いつつ各ＬＡＮに適した条件で順次行うことができるようになる。
【０１１３】
以上の説明から明らかなように、上述した第一〜第五の処理動作例を含む本発明の実施の形態では、エラー発生時に処理していたデータとこれを処理するアプリケーション（ソフトウエアモジュール）の動作とを関連付けてログ情報として抽出して保存するようになっている。したがって、エラー発生がプリンタ装置の使用環境や設置環境に依存したものであり、その設置場所でエラー発生の原因特定を行うことが要求される場合であっても、エラー発生の原因特定のための情報収集を保守員等の介在無しに無人で的確に行うことができ、また保守員等が収集した情報からエラー発生の原因特定を迅速に、すなわち少ない工数で行うことができる。しかも、アプリケーションに関する情報をも抽出して保存するので、複数デバイスの動作処理やデバイスが取り扱うデータそのものにエラーの原因がある場合であっても、そのエラー原因を的確に特定することができるようになる。
【０１１４】
なお、第一〜第五の処理動作例を含む本発明の実施の形態では、本発明をプリンタ装置に適用した場合を例に挙げて説明したが、コピージョブ、スキャンジョブ、ＦＡＸジョブ等といった画像データの処理ジョブを実行するものであれば、他の画像処理装置であっても適用可能であることはいうまでもない。
【０１１５】
また、本発明の実施の形態では、ログ処理情報制御部４４がエラー番号に対応した処理の内容を管理するために処理テーブルを用いていたが、本発明はこれに限定されるものではない。すなわち、処理内容の管理はその方法に依存することはなく、例えばエラー属性によって管理した場合方怯であっても全く同様の効果が得られる。さらに、本発明の実施の形態では、処理テーブルに処理内容を直接登録する場合を例に挙げたが、予め登録された処理の実行パラメータのみを変更する場合であっても同様の効果が得られる。
【０１１６】
また、エラー発生に対応して行う処理内容は、本発明の実施の形態で説明した以外にも様々なものが考えられる。例えば、エラー番号に対応した処理としては、発生したエラーに関係する装置内における処理の他にも、クライアント装置にエラーが発生したことを通知するといった装置外への処理も考えられる。この場合には、外部装置に情報を収集することになるので、その外部装置がデータを取りこぼさないような信号を生成する点に留意することが好ましい。さらには、エラー解析機能を有した外部装置等の専用ツールがなくても、エラー発生時の障害情報の収集およびその解析ができるように、エラー番号に対応した処理として、エラー発生時に処理対象となっていたデータおよびそのエラー発生時のログ情報の印刷出力を行うことも考えられる。
【０１１７】
また、処理中にネットワークの障害エラー発生を検出した場合には、発生時間、発生処理アプリケーション、発生元になるデータ（ファイル）、データの発生個所に加え、障害となるネットワークパケット情報を記憶する処理を行うことも考えられる。このようにすれば、プリンタ装置が受信したデータだけでなく、ネットワーク上で転送されているデータを採取して障害要因となるパケットを特定することができるので、特にネットワークの接続切れやデータの転送状態が原因で印刷出力に障害が発生した場合に、その障害の原因を解析するのに有効となる。
【０１１８】
【発明の効果】
以上に説明したように、本発明の画像処理装置によれば、ジョブの実行途中に予期せぬエラーが発生した場合であっても、そのエラーに対して従来よりも好適に対処し得るようになる。
【０１２０】
すなわち、例えばジョブの実行途中にエラーが発生した場合には、そのエラー発生時に処理していたデータとその処理部分、およびこれを処理するアプリケーションを特定する情報とを関連付けて抽出することで、エラー発生の原因特定のための情報収集を的確に行うことができ、さらには収集した情報からエラー発生の原因特定を迅速に行うことができる。しかも、アプリケーションを特定する情報をも抽出するので、複数デバイスの動作処理やデバイスが取り扱うデータそのものにエラーの原因がある場合であっても、そのエラー原因を的確に特定することができるようになる。
【図面の簡単な説明】
【図１】  画像処理装置の一具体例の基本構成を示すブロック図である。
【図２】  プリントジョブの場合におけるジョブ・ログの内容情報の一例を示す説明図である。
【図３】  図１の画像処理装置におけるジョブ・ログ保存・更新の処理動作例を示すフローチャートである。
【図４】  図１の画像処理装置におけるジョブ・ログ管理手段の初期化時の処理動作例を示すフローチャートである。
【図５】  実行途中で電源断されたジョブの残存ジョブ・ログの内容情報の一例を示す説明図である。
【図６】  残存ジョブ・ログに基づき生成された処理結果ジョブ・ログの内容情報の一例を示す説明図である。
【図７】  本発明に係る画像処理装置の構成例を示すブロック図である。
【図８】  図７の画像処理装置がログ管理を行う際の第一の処理動作例を示すフローチャートである。
【図９】  図７の画像処理装置がログ管理を行う際の第二の処理動作例を示すフローチャートである。
【図１０】  図７の画像処理装置がログ管理を行う際の第三の処理動作例を示すフローチャートである。
【図１１】  図７の画像処理装置がログ管理を行う際の第四の処理動作例を示すフローチャートである。
【図１２】  図７の画像処理装置がログ管理を行う際の第五の処理動作例を示すフローチャートである。
【符号の説明】
１，９…操作手段、２…ジョブ制御手段、３…画像入出力手段、４…ジョブ・ログ管理手段、５…記憶手段、３１…ネットワークインタフェース部、３２…システム制御部、３３…メモリ管理部、３４…印刷処理管理部、３５…画像データ展開処理部、３６…記録出力部、３７…記録出力制御部、３８…操作制御部、３９…操作パネル、４０…ログ情報処理部、４１…エラー情報検出部、４２…印刷情報検出部、４３…ログ情報記録制御部、４４…ログ処理情報制御部
【図１】
0004114315.tif 000002
【図２】
0004114315.tif 000003
【図３】
0004114315.tif 000004
【図４】
0004114315.tif 000005
【図５】
0004114315.tif 000006
【図６】
0004114315.tif 000007
【図７】
0004114315.tif 000008
【図８】
0004114315.tif 000009
【図９】
0004114315.tif 000010
【図１０】
0004114315.tif 000011
【図１１】
0004114315.tif 000012
【図１２】
0004114315.tif 000013