JP2009118190A - 画像形成装置、解析方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】 ネットワーク通信装置における障害を解析するために必要なパケットを可及的に過不足なく取得できるようにする。
【解決手段】 ＭＦＰ１０１は、受信したパケットを印刷ジョブ単位でファイルとして一時的に保存すると共に、異常通信情報をログ（異常通信ログ）として保存する。ＭＦＰ１０１は、保存したファイルの中で、アプリケーションでエラーが発生しないデータについては削除する。そして、ＭＦＰ１０１は、任意の印刷ジョブの処理中にエラーが発生した場合、受信したパケットを記憶装置に保存し、且つエラーが発生したジョブパケットに含まれる異常通信と、受信した全ての印刷ジョブに関するパケットに含まれる異常通信とを比較する。そして、その比較の結果として、エラーが発生したジョブパケットにのみ含まれる異常通信を抽出し、抽出した結果が分かるようにログ化する。
【選択図】 図１

Description

本発明は、画像形成装置、解析方法、及びコンピュータプログラムに関し、特に、装置で発生したエラーの解析をパケット用いて行う技術に関する。

従来から、ネットワーク通信機器で障害が発生した場合に、ネットワーク（通信路）を流れるパケットを採取して障害の原因を調査する手法が存在している。その一般的な方法は、パケットの取得を行う専用の機器をＨＵＢ等の集線機器に接続して、ＬＡＮ（Local Area Network）を流れるパケットを採取する。調査対象となるネットワーク通信機器が送受信しているパケットのデータの内容を、採取したパケットから解析して、規定外のデータを受信している箇所や、受信パケットに対する応答遅延が発生している箇所を特定する。そして、それらの箇所が障害の原因であるか否かを切り分けるために、同一のパケットをネットワーク通信機器に送信して障害が再現されるかどうかを確認することや、ネットワーク通信機器の通信を司るソースコードを解析するといった調査を行う。

このようなパケットの取得や解析作業を行う際に、パケットの取得機器の記憶領域を確保することと、パケットの解析作業の労力を削減することとを目的として、パケットのフィルタリング機能が用いられる。このフィルタリング機能を用いることで、特定の条件にマッチするパケットのみを取得することができる。これにより、取得するパケットの数を削減することができ、取得したパケットを記憶するメモリ領域や、取得したパケットを長期的に記憶するためのハードディスクの記憶領域を削減することができる。加えて解析に要する工数を削減することが可能となる。フィルタリングのルールは、一般的に、ネットワークプロトコルの要素で指定されることが多い。例えばＩＰ（Internet Protocol）やＡＲＰ（Address Resolution Protocol）等のように特定のプロトコルのみをフィルタリングして、それらのプロトコルのパケットのみを取得することが可能となる。また各々のプロトコルにおいても、より詳細な要素に分解したフィルタリングが可能である。例えば、ＩＰプロトコルにおいて、特定のＤＳＴアドレス（送信先アドレス）、特定のＳＲＣアドレス（送信元アドレス）、特定の上位層のプロトコル等の条件を設定することで詳細なフィルタリングを行うことが可能になる。

また近年、パケットの取得機能が備わったネットワーク通信機器も普及し始めている。これにより、パケットの取得を行うための専用の機器を使用しなくてもパケットの取得が可能となる。このため、スイッチングＨＵＢが導入された環境のように、専用機器を接続したとしてもパケットの取得を正しく行うことができないような環境であっても、パケットの取得が可能になった。加えて最近では、ネットワーク機器の用途や特徴に特化したフィルタリングが可能となっている。このフィルタリングは、前述のネットワークプロトコルの要素単位でのフィルタリングとは異なり、機器が持っている機能に特化してフィルタリングする。これにより、障害解析の効率をより向上させることが可能である。特許文献１には、ネットワークプリンタにおいて受信した印刷ジョブ単位でデータの保存する技術が開示されている。これにより、ネットワーク経由で受信した印刷ジョブの印刷時に発生した障害を解析するに際し、障害が発生した印刷ジョブのみを抽出することが可能となり、解析の効率を向上させることができる。

特開２００４−３６２３８６号公報

しかしながら、前述した従来の技術には、以下のような問題点がある。
まず、フィルタリングを施したことにより、正常状態との比較ができなくなることが問題である。前述した従来の技術のように、印刷ジョブ単位でフィルタリングを施した場合、障害の解析者が得ることができるパケットは、障害が発生した印刷ジョブに関連したもののみである。したがって、取得したパケットの中に障害の原因となり得る異常通信が見つかったとしても、それが障害の原因であるか否かを判断することが困難である。例えば、取得した印刷ジョブにおいて、パケットの再送や送信のリトライといった、障害の原因になる可能性のある現象が発生していても、その現象が正常に印刷できる印刷ジョブでも発生しているならば、その現象が障害の原因である可能性は低い。しかしながら、従来の技術ではパケット内で発見された異常な通信を全て調査する必要があり、解析者の負担になっていた。

また、フィルタリングを施して相対的にパケットの数を減少させたとしても、絶対的なパケット数（データ数）が多い場合には、解析に多くの時間が必要とされることも問題である。近年のネットワークアプリケーションはより複雑化・多機能化しており、それに伴いネットワークを流れるデータサイズも増大している。従来の技術では、ネットワークプリンタが受信する印刷ジョブ単位でフィルタリングを行うが、近年のネットワークプリンタが受信する印刷ジョブは、そのデータサイズが１ギガバイトを超えることもある。そのような場合に、解析者が１ギガバイト分のパケットデータを解析するには多大な時間が必要とされる。

本発明は、このような問題点に鑑みてなされたものであり、全取得パケットの中から、異常通信を解析するために必要なパケットを過不足なく取得できるようにすることを目的とする。

本発明の画像形成装置は、ジョブの処理に用いるアプリケーションの実行に基づくパケットを取得する取得手段と、前記取得手段により取得されたパケットに異常があるか否かを判断する判断手段と、前記判断手段によりパケットに異常があると判断されると、当該パケットに関する情報を記憶媒体に記憶する記憶手段と、ジョブの処理に用いるアプリケーションの実行にエラーが発生した場合、当該アプリケーションの実行に基づき取得されるパケットの出現傾向と、当該アプリケーションが正常に実行された際に前記記憶手段に記憶された異常があると判断されたパケットの出現傾向とを比較する比較手段と、前記比較手段により、当該アプリケーションが正常に実行された際に前記記憶手段に記憶された異常があると判断されたパケットの出現傾向に対して、当該アプリケーションの実行に基づき取得されるパケットのうち異なる出現傾向を示すパケットの種類を検出する検出手段とを有することを特徴とする。

本発明の解析方法は、ジョブの処理に用いるアプリケーションの実行に基づくパケットを取得する取得工程と、前記取得工程により取得されたパケットに異常があるか否かを判断する判断工程と、前記判断工程によりパケットに異常があると判断されると、当該パケットに関する情報を記憶媒体に記憶する記憶工程と、ジョブの処理に用いるアプリケーションの実行にエラーが発生した場合、当該アプリケーションの実行に基づき取得されるパケットの出現傾向と、当該アプリケーションが正常に実行された際に前記記憶工程に記憶された異常があると判断されたパケットの出現傾向とを比較する比較工程と、前記比較工程により、当該アプリケーションが正常に実行された際に前記記憶工程に記憶された異常があると判断されたパケットの出現傾向に対して、当該アプリケーションの実行に基づき取得されるパケットのうち異なる出現傾向を示すパケットの種類を検出する検出工程とを有することを特徴とする。

本発明のコンピュータプログラムは、上記解析方法の工程をコンピュータに実行させることを特徴とする。

本発明によれば、ネットワークを介して取得された"ジョブに関するパケット"が異常通信であると、その異常通信の内容を記憶媒体に記憶しておく。そして、ジョブを処理するためのアプリケーションの実行にエラーが発生すると、そのアプリケーションの実行に関するパケットの異常通信の内容と、記憶しておいた異常通信の内容とを比較する。したがって、取得した全てのパケットを記憶しなくても、異常通信を解析することが可能になる。よって、異常通信を解析するために必要なパケットを可及的に過不足なく取得することができる。

（第１の実施形態）
以下に、図面を参照しながら、本発明の第１の実施形態について説明する。
図１は、ネットワークシステムの構成の一例を示すブロック図である。
ユーザ環境のネットワークはＬＡＮ（Local Area Network）１０３であり、ＬＡＮ１０３は例えばEthernet（登録商標）である。ＬＡＮ１０３には、以下に説明する"複数のネットワークインターフェイスを有するノード"が接続されている。

ＭＦＰ（Multi Function Peripherals）１０１は複合機である。ＭＦＰ１０１のハードウェアの詳細な説明は、図２にて後述する。
ＰＣ１０２、１０４は一般的なパーソナルコンピュータである。ＰＣ１０２、１０４のハードウェアを構成する主な装置を以下に示す。まず、中央演算装置としてＣＰＵ（Central Processing Unit）が存在する。また記憶装置として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、及びＨＤＤ（Hard Disk Drive）が存在する。また外部記憶装置として、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）ドライブ等が存在する。また外部インターフェイスとして、ＮＩＣ（Network Interface Card）、及びＵＳＢ（Universal Serial Bus）ホストインターフェイス等が存在する。また、これらの装置やＭＦＰ１０１等を制御するための通信経路となるバスが備わっている。またＰＣ１０２、１０４の本体に接続される周辺機器としては、マウス、ＣＲＴディスプレイ、及びキーボード等が存在する。

ＰＣ１０２、１０４に導入されている主なソフトウェアは、ＯＳ（Operating System(Software））や、ワードプロセッサや表計算ソフトといったオフィスソフトウェア等である。ＯＳにはその機能の１つとして、ＬＡＮ１０３等のネットワークを経由して、不図示のプリンタやＭＦＰ１０１に印刷データを送信するためのポートモニタが備わっている。また後述のメールサーバ１０５に電子メールを送信したり、電子メールを受信したりといった電子メール送受信を行うためのメーラもＯＳに導入されているものとする。
メールサーバ１０５は電子メールサーバであり、ＳＭＴＰ（Simple Mail Transfer Protocol）やＰＯＰ３（Post Office Protocol）を用いて電子メールの送受信を司るサーバである。メールサーバ１０５には、ＭＦＰ１０１やＰＣ１０２、１０４の電子メールアカウントが設定されており、夫々のノード（ＭＦＰ１０１、ＰＣ１０２、１０４）がメールサーバ１０５を経由して電子メールを送信する事が可能な設定がなされているものとする。

図２は、ＭＦＰ１０１のコントローラの主要部の構成の一例を示すブロック図である。
コントローラユニット２０００には、画像入力デバイスであるスキャナ２０７０や画像出力デバイスであるプリンタ２０９５が接続される。コントローラユニット２０００は、スキャナ２０７０で読み取られた画像データをプリンタ２０９５により印刷出力するコピー機能を実現するための制御を行う。また、コントローラユニット２０００は、ＬＡＮ１０３に接続することによって、画像情報やデバイス情報の入出力を行うための制御を行う。具体的にコントローラユニット２０００は、ＣＰＵ２００１を有し、ＣＰＵ２００１は、ＲＯＭ２００３に格納されているブートプログラムによりＯＳを立ち上げる。そして、ＨＤＤ２００４に格納されているアプリケーションプログラムを、このＯＳ上で実行することによって各種処理が実行される。このＣＰＵ２００１の作業領域としてはＲＡＭ２００２が用いられる。ＲＡＭ２００２は、作業領域と共に、画像データを一時記憶するための画像メモリ領域を提供する。ＨＤＤ２００４は、前記アプリケーションプログラムや、画像データ等を格納する。

ＣＰＵ２００１には、操作部ＩＦ（操作部インターフェイス）２００６、ネットワークＩ／Ｆ（Interface）２０１０、モデム２０５０、及びイメージバスＩ／Ｆ２００５が、システムバス２００７を介して接続されている。操作部Ｉ／Ｆ２００６は、タッチパネルを有する操作部２０１２とのインターフェイスであり、操作部２０１２に表示する画像データを操作部２０１２に対して出力する。また、操作部Ｉ／Ｆ２００６は、操作部２０１２においてユーザにより入力された情報をＣＰＵ２００１に送出する。次に、ネットワークＩ／Ｆ２０１０は、ＬＡＮ１０３に接続され、ＬＡＮ１０３を介してＬＡＮ１０３に接続された各装置との間で情報の入出力を行う。モデム２０５０は、不図示の公衆回線に接続され、情報の入出力を行う。イメージバスＩ／Ｆ２００５は、システムバス２００７と、画像データを高速で転送する画像バス２００８とを相互に接続し、データ構造を変換するためのバスブリッジである。画像バス２００８は、ＰＣＩバス又はＩＥＥＥ１３９４から構成される。画像バス２００８には、ＲＩＰ（Raster image processor）２０６０、及びデバイスＩ／Ｆ２０２０が接続されている。この他、画像バス２００８には、スキャナ画像処理部２０８０、プリンタ画像処理部２０９０、画像回転部２０３０、サムネイル作成部２０３５、及び画像圧縮部２０４０が接続されている。ＲＩＰ２０６０は、ＰＤＬ（Page Description Language）コードをビットマップイメージに展開するプロセッサである。デバイスＩ／Ｆ２０２０には、スキャナ２０７０及びプリンタ２０９５が接続され、デバイスＩ／Ｆ２０２０は、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２０８０は、入力した画像データに対して、補正、加工、編集を行う。プリンタ画像処理部２０９０は、プリント出力する画像データに対して、補正、解像度変換等を行う。画像回転部２０３０は、画像データの回転を行う。画像圧縮部２０４０は、多値画像データをＪＰＥＧデータに、２値画像データをＪＢＩＧ、ＭＭＲ、ＭＨ等のデータに圧縮するとともに、その伸張処理を行う。

図３は、ＭＦＰ１０１の主要な機能構成の一例を示すブロック図である。尚、図３に示す構成のうち、ネットワークＩ／Ｆ２０１０はハードウェアであり（図２を参照）、その他の構成は、ソフトウェアである。
ＭＦＰ１０１は、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳを有している。アプリケーション（アプリケーションプログラム）３０１は、ＭＦＰ１０１上で動作するネットワークアプリケーションの集合である。アプリケーション３０１に含まれる詳細なネットワークアプリケーションの説明は図４を用いて後述する。

ソケットＩ／Ｆ３０２は、ＯＳによって提供されるソケットＩ／Ｆプログラムである。アプリケーション３０１に含まれるネットワークアプリケーションが通信を行うに際し、ソケットＩ／Ｆ３０２が呼び出されることによって、データの送信や受信といった処理が可能になる。ソケットＩ／Ｆ３０２は、ネットワークアプリケーションが通信を行う際に必ずしも必要なプログラムではない。しかしながら、ＯＳの種類によらず汎用的なプログラム命令と処理フローを用いることができるため、ソケットＩ／Ｆ３０２によって、アプリケーション３０１の開発工数を削減することができる。そのため本実施形態では、ネットワークアプリケーションはソケットＩ／Ｆ３０２を呼び出してデータの送受信を行うこととする。

ネットワークスタック３０３はプロトコルスタック群である。ネットワークデバイスドライバ３０４は、ネットワークＩＦ２０１０のデバイスドライバである。パケット取得アプリケーション３０５は、ネットワークＩ／Ｆ２０１０が送受信するネットワークパケットの取得やログの出力を行うアプリケーションである。パケット取得アプリケーション３０５は、ネットワークデバイスドライバ３０４からデータの取得を行うことによって、ネットワークＩ／Ｆ２０１０が受信した全てのパケットと、ネットワークＩＦ２０１０が送信する全てのパケットとを取得する。アプリケーション３０１及びパケット取得アプリケーション３０５はアプリケーションスペースで動作しており、ソケットＩＦ３０２、ネットワークスタック３０３、及びネットワークデバイスドライバ３０４はカーネルスペースで動作している。

図４は、アプリケーション３０１の構成の一例を詳細に示したブロック図である。
ＬＰＤ（Line Printer Daemon）部４０１は、ＬＰＲプロトコルを使用して、ＬＡＮ１０３等のネットワークを経由して印刷ジョブを受信するサーバプログラムである。例えばＰＣ１０２がＬＰＲプロトコルを使用して印刷ジョブをＭＦＰ１０１に送信すると、ＬＰＤ部４０１が印刷ジョブのデータを受信する。ＬＰＤ部４０１が受信した印刷ジョブデータは、ＰＤＬ部４０２に転送される。ＰＤＬ部４０２は印刷ジョブの展開を行うプログラムである。印刷ジョブデータはＰＤＬと呼ばれる記述言語で記載される。この言語には、印刷データの他に印刷に必要な情報が付加されている。例えば用紙のサイズや部数といった情報がそれに当てはまる。ＰＤＬ部４０２はＰＤＬで記載された印刷ジョブデータを展開し、印刷データをビデオ画像に変換し、指定された印刷属性に従ってビデオデータを作成する。作成されたビデオデータはプリンタ２０９５に転送され、印刷処理が行われる。

データ送信アプリケーション４０４は、スキャナ２０７０でスキャンされた画像データを、ＬＡＮ１０３等のネットワークを通じてメールサーバ１０５に送信する機能を有する。スキャナ２０７０でスキャンされた画像データは、ＪＰＥＧ（Joint Photographic Experts Group）やＰＤＦ（Portable Document Format）といった画像フォーマットでファイル化される。データ送信アプリケーション４０４は、その画像データのファイルを、ＳＭＴＰ部４０３を通じてメールサーバ１０５に転送する。ＳＭＴＰ部４０３は、ＳＭＴＰプロトコルを用いてメールサーバ１０５に電子メールの送信を行うネットワークアプリケーションである。本実施形態においては、メールサーバ１０５に電子メールを送信する設定が予め為されているものとする。

図５は、通常状態におけるパケットを取得する際の動作の一例を説明するフローチャートである。ＭＦＰ１０１にパケット取得機能が有効に設定されている場合には、図５の処理が常に行われる。
ステップＳ５０１において、パケット取得アプリケーション３０５は、ネットワークＩ／Ｆ２０１０における"パケットの送受信"の有無を監視する。そして、ネットワークＩ／Ｆ２０１０における"パケットの送信又は受信"がない場合には、ステップＳ５０２〜Ｓ５０４を省略して後述するステップＳ５０５に進む。一方、ネットワークＩ／Ｆ２０１０における"パケットの送信又は受信"を確認した場合には、ステップＳ５０２に進む。

ステップＳ５０２に進むと、パケット取得アプリケーション３０５は、送信又は受信されたパケットの数をプログラム内部で一時的に記憶する。
次に、ステップＳ５０３において、パケット取得アプリケーション３０５は、送信又は受信パケットに異常があるか否か（異常通信であるか否か）を判定する。この判定の結果、パケットに異常がない場合には、ステップＳ５０４を省略して後述するステップＳ５０５に進む。一方、パケットに異常がある場合には、ステップＳ５０３に進む。ステップＳ５０３に進むと、パケット取得アプリケーション３０５は、異常のあったパケットに関する情報をログ化する。

図６は、ステップＳ５０３において異常と判定すべき通信上の挙動の一例を示した図である。
図６では、異常と判定すべき通信上の挙動として、通信切断６０１、通信タイムアウト６０２、ビジー６０３、及び再送６０４を例示している。
まず、通信切断６０１について説明する。例えばＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）では、通信を切断する場合にはＲＳＴパケットを相手に送出する。ＲＳＴパケットは、ＴＣＰ／ＩＰによる正常な通信でも使用されるが、アプリケーションに異常が発生したとき等にも送信されることがある。このため、送信又は受信するパケットがＲＳＴパケットであった場合には異常通信（通信異常）であると判断する。

通信タイムアウト６０２について説明する。例えば、ＴＣＰ／ＩＰ等のコネクション指向プロトコルにおいて、一定時間以上パケットの応答が無かった場合、何らかの異常が発生している可能性がある。このため、一定時間以上パケットの応答が無かった場合には異常通信であると判断する。
ビジー６０３について説明する。例えば、ＴＣＰ／ＩＰでは、受信バッファの受け入れ可能スペースをWindowSizeとして通信先に通知する。アプリケーションに何らかの異常が発生して、受信バッファからデータの読み出しができない状態が続くと、受信バッファがフル状態になり、これ以上データの受信ができない状態になる。この状態をビジーと呼ぶ。ビジーは、アプリケーションの処理速度が遅い場合に発生することが多いが、アプリケーションに異常が発生している場合でも発生する可能性がある。このため、ビジーとなった場合には異常通信であると判断する。

再送６０４について説明する。例えば、ＴＣＰ／ＩＰでは、送信したデータに対する確認が一定時間ない場合、パケットは再送されることになる。したがって、パケットが再送された場合には、アプリケーションに異常が発生している場合でも発生する可能性がある。このため、パケットを再送した場合には異常通信であると判断する。

次に、受信したパケットに対して、異常通信の有無をチェックする仕組みの一例を、図７を用いて説明する。図７は、受信したパケットのデータグラムを可視化したものの一例を示す図である。
図７において、データ１５０１とデータ１５０２は、夫々受信パケットのデータグラムを表している。一例として、ビジー６０３の有無を検査する処理シーケンスを説明する。
パケット取得アプリケーション３０５は、受信した各々のパケットについてＴＣＰ／ＩＰのWindowサイズの値を検査する。次に、パケット取得アプリケーション３０５は、データ１５０１のパケットデータグラムのEthernet（登録商標）ヘッダに含まれる次プロトコル情報１５１１を参照する。そして、次プロトコル情報１５１１がＩＰを示す０ｘ０８００であった場合、パケット取得アプリケーション３０５は、ＩＰヘッダの次ヘッダ情報（プロトコル）１５１２を参照する。

ＩＰヘッダの次ヘッダ情報１５１２がＴＣＰを示す０ｘ０６であった場合、パケット取得アプリケーション３０５は、ＴＣＰのWindowサイズを参照する。パケットデータを示すデータ１５０１において、ＴＣＰのWindowサイズ１５１３は０ｘ４００ａであるため、Windowサイズは０ｘ４００ａバイトということになる。したがって、パケット取得アプリケーション３０５は、ビジーでないと判定する（異常通信でないと判定する）。

次に、パケット取得アプリケーション３０５は、次パケットとなるデータ１５０２を検査する。パケット取得アプリケーション３０５は、データ１５０１の場合と同様に、Windowサイズを参照する。データ１５０２において、Windowサイズ１５１４は０ｘ００００である。この場合には、パケット取得アプリケーション３０５は、ビジーであると判断する。

図５の説明に戻り、前述したように、ステップＳ５０３において送信又は受信パケットに異常があると判定された場合には、ステップＳ５０４に進み、パケット取得アプリケーション３０５は、異常のあったパケットに関するログを生成する。ログはＨＤＤ２００４に生成される。ログとして保存される情報には、取得日時、プロトコル情報、及び異常通信の種別が含まれる。プロトコル情報には、ネットワークアプリケーションを特定することができる情報が含まれる。以下の説明では、このログを必要に応じて異常通信ログと称する。

図８は、異常通信ログの一例を示す図である。
図８に示す例では、４パケット分の異常通信がログ化されており、夫々のログ内容７０１〜７０４が記載されている。フレームＩＤ７１０、ステータス７１１、送信元アドレス７１２、送信先アドレス７１３、サイズ７１４、相対時間７１５、デルタ時間７１６、絶対時間７１７、プロトコルサマリ７１８は、夫々のパケットに関する情報である。

フレームＩＤ７１０とは、送受信されたパケットを一意に示すＩＤであり、各々のパケットにユニークなＩＤが割り当てられる。ステータス７１１には、異常通信の内容が記載される。ＩＰプロトコルであれば、送信元アドレス７１２には送信元のＩＰアドレスが記載され、送信先アドレス７１３には送信先のＩＰアドレスが記載される。サイズ７１４には、パケットのサイズが記載される。パケットのサイズの単位はバイトである。相対時間７１５には、パケットの取得を開始してからの経過時間が記載される。デルタ時間７１６には、前回のパケットの"送信時刻又は受信時刻"から経過した時間が記載される。

絶対時間７１７には、パケットを取得した日時が記載される。プロトコルサマリ７１８には、主にトランスポート層の情報が記載される。例えばＴＣＰの場合には、送信先ポート、送信元ポート、オプションビット情報、シーケンス番号、データレングス、Windowサイズがプロトコルサマリ７１８に記載される。ポート番号を参照することによってネットワークアプリケーションを特定することが可能である。

図５の説明に戻り、ステップＳ５０５に進むと、パケット取得アプリケーション３０５は、取得したパケットを例えばＨＤＤ２００４に保存する。パケット取得アプリケーション３０５は、取得したパケットのデータの全てをＨＤＤ２００４にファイルとして所定のフォーマットで書き込む。尚、ファイルはジョブ単位で生成される。つまり、ＬＰＤ部４０１が受信した"１つの印刷ジョブのデータ"に対応するパケットの集合が、１つのファイルとしてＨＤＤ２００４に保存される。

図９は、ステップＳ５０５で生成されたファイルのデータの内容の一例を可視化した図である。
パケット取得アプリケーション３０５で取得されたパケットのデータは、取得（受信）された順序のままファイルに書き込まれる。ファイル中の"各パケットのデータ"は、フレームＩＤ、データレングス、パケットデータグラム、及び受信時間によって構成される。図９では、データ１４０１〜１４０３は、夫々パケットデータを表す。データ１４０１は、フレームＩＤを表すデータ１４１１と、データレングスを表すデータ１４２１と、パケットデータグラム１４３１と、パケットの受信時間を表す受信時間１４４１によって構成されている。フレームＩＤとは、ファイル中のパケットを一意に表すＩＤである。データレングスとは、１パケットのデータグラムのサイズであり、単位はオクテットである。パケットデータグラムとは、パケットのデータである。受信時間は、１９７０年からの経過時間であり、単位は１／１００秒である。

図５の説明に戻り、ステップＳ５０６に進むと、アプリケーション３０１は、エラーが発生したか否かを判定する。具体的には、ＰＤＬ部４０２やデータ送信アプリケーション４０４は、処理エラーの発生の有無を確認する。このステップＳ５０６の判定の結果、アプリケーション３０１でエラーが発生している場合には、ステップＳ５０９に進み、エラー解析処理が行われる。このエラー解析処理の詳細については、図１０のフローチャートを用いて後述する。一方、アプリケーション３０１でエラーが発生していない場合には、ステップＳ５０７に進む。

ステップＳ５０７に進むと、パケット取得アプリケーション３０５は、アプリケーション３０１による印刷ジョブの処理が終了したか否かを判定する。具体的に説明すると、例えば、ＰＤＬ部４０２やデータ送信アプリケーション４０４が処理した印刷ジョブが、エラーを発生することなく終了したか否かを判定する。このステップＳ５０７の判定の結果、アプリケーション３０１による印刷ジョブの処理が終了していない場合には、ステップＳ５０８を省略してステップＳ５０１に戻る。

一方、ステップＳ５０７において、アプリケーション３０１による印刷ジョブの処理が終了した場合には、ステップＳ５０８に進む。ステップＳ５０８に進むと、パケット取得アプリケーション３０５は、関連するパケットのファイルを削除する。そして、ステップＳ５０１に戻る。
具体的に説明すると、パケット取得アプリケーション３０５は、ステップＳ５０５においてジョブ単位で一時的に記憶されたパケットのデータのファイルを削除する。ここで削除されるデータは、ステップＳ５０６にてエラーが発生していないと判定された印刷ジョブに関連するパケットのファイルである。即ち、ネットワーク経由で問題なくパケットが送受信され、アプリケーション３０１の動作も問題がない場合には、関連するパケットは削除される。

以上のように、ステップＳ５０１〜Ｓ５０９の一連のフローによって、ネットワークＩ／Ｆ２０１０によって送受信されるパケットのうち、異常通信が発生したパケットについては、そのパケットに関するログが異常通信ログとしてＨＤＤ２００４に記憶される。また、受信したパケットはジョブ単位でファイル化されＨＤＤ２００４に記憶されるが、アプリケーション３０１でエラーが発生しない正常な印刷ジョブに関連するパケットについては、エラーが発生せずに終了したと判定された時点で削除される。

次に、図１０のフローチャートを参照しながら、図５のステップＳ５０９におけるエラー解析処理の詳細を説明する。図１０では、アプリケーションの一例としてＰＤＬ部４０２でエラーが発生した場合の処理を示す。
まず、ＰＤＬ部４０２で発生するエラーの内容の具体例を説明する。図１１は、ＬＰＤ部４０１を経由して受信したＰＤＬデータをＰＤＬ部４０２が処理する際に発生するエラー（ＰＤＬエラー）の内容と、そのエラーの原因となる可能性が考えられる"ネットワーク通信上の異常"との一例を表形式で対応させて示す図である。
ＭＦＰ１０１は、図１１の内容に相当する情報を内部的に予め保持しており、後述の処理にて使用する。

図１１において、SYNTAXエラー９０１とは、ＰＤＬデータに文法的な間違い箇所が存在する場合に発生するエラーである。例えば、ＰＤＬデータの命令文として、下記が正しい文法であるものとする。
[５０ １００ ｍｏｖｅｔｏ]
これに対して、例えば下記の命令のように、命令文の記載が間違ったデータをＰＤＬ部４０２が受信した場合にSYNTAXエラーが発生する。
[５０ １００ ｍｏｖｅｔ]
図１１では、SYNTAXエラーを発生させる原因となるネットワーク上の異常通信９１１として、ビジーと通信タイムアウトを挙げている。ネットワーク上でビジーや通信タイムアウトが発生すると、ＰＤＬ部４０２に代表される上位アプリケーションに一定時間データが転送されない現象が発生する。その場合に、ＰＤＬ部４０２内で処理が進行して、不完全なＰＤＬデータのまま処理されてしまう可能性がある。SYNTAXエラーは文法上の誤りであるため、データが不完全である場合にも発生する可能性がある。

デコードエラー９０２とは、ＰＤＬデータに含まれる画像書式から画像データを導き出す処理を施した際に、文法以外の誤りがあり、画像データへの複合化ができなかった場合のエラーを指す。例えば、ＰＤＬデータの命令文として、下記が正しい文法であるものとする。
[５０ １００ ｍｏｖｅｔｏ]
この命令文の数値５０を指定しているパラメータの上限値が１０２４であるにも関わらず、１０２５以上の値が指定された場合、複合処理ができなくなり、デコードエラーとして出力される。デコードエラーでは、ネットワーク上の異常通信の中で原因となるものが存在しないため、その旨をＭＦＰ１０１は記憶する。

文字化け９０３は、指定された文字コードセットに存在しない文字コードが指定された場合等に発生する。この場合も、ネットワーク上の異常通信の中で原因となるものが存在しないため、その旨をＭＦＰ１０１は記憶する。

ジョブタイムアウト９０４は、タイムアウトにより処理が中止又は中断する場合等に発生する。ＰＤＬの中には、ＰＤＬデータの受信開始後に一定の時間、ＰＤＬデータを受信しないブランク（期間）が存在すると、タイムアウトにより処理が中止又は中断してしまうものが存在する。その場合にネットワーク上の動作として疑うべき現象は、データの通信（送信又は受信）に一定時間のブランクが存在することである。このようなブランクが存在すると、ＰＤＬ部４０２が受信（又は送信）する際にもブランクが発生するため、ジョブタイムアウトの原因となる可能性がある。

図５のステップＳ５０６において発生したと判定されるエラーは、図１１に記載の何れかのエラーであるものとする。

図１０のステップＳ８０１において、パケット取得アプリケーション３０５は、ＰＤＬ部４０２でエラーが発生したＰＤＬデータを送受信したパケットのデータから、エラーを発生させた印刷ジョブにおける異常通信を抽出する処理を行う。具体的に説明すると、パケット取得アプリケーション３０５は、ＨＤＤ２００４に保存されている"エラーを発生させたパケットのファイルをオープンし、異常通信を抽出する。尚、以下の説明では、エラーが発生したＰＤＬデータを送受信したパケットを、必要に応じて、エラージョブパケットと称する。

次に、ステップＳ８０２において、パケット取得アプリケーション３０５は、エラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数を確認し、異常通信ログが比較可能な状態か否かを判定する。エラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数が少ない場合、互いの異常通信の内容を比較したとしても、比較結果から導き出されるエラーの原因の信頼性は高くない。そのため、比較の信頼性を確保できる状態になるまで異常通信ログの採取を続行する。本実施形態では、比較の信頼性を確保できる状態とは、エラージョブパケットのパケット数に対して、そのエラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数が閾値を超えた（例えば１０倍を超えた）状態であるとする。これに対し、エラージョブパケットのパケット数に対して、そのエラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数が閾値以下（例えば１０倍以下）の場合には、異常通信ログの採取を続行する。

このステップＳ８０２の判定の結果、異常通信ログが比較可能な状態である場合には、ステップＳ８０３を省略してステップＳ８０４に進む。一方、異常通信ログが比較可能な状態でない場合には、ステップＳ８０３に進む。ステップＳ８０３に進む。
ステップＳ８０２の処理をより具体的に説明すると、まず、パケット取得アプリケーション３０５は、エラージョブパケットのファイルから、パケットの総数を取得する。そして、パケット取得アプリケーション３０５は、取得したパケットの総数と、図５のステップＳ５０２にて内部的に確保しているパケットの総数とを比較する。この比較の結果、図５のステップＳ５０２にて内部的に確保しているパケットの総数が、エラージョブパケットのパケットの総数の１０倍以上であるならば、ステップＳ８０３を省略してステップＳ８０４に進む。

一方、図５のステップＳ５０２にて内部的に確保しているパケットの総数が、エラージョブパケットのパケットの総数の１０倍に達していない場合には、ステップＳ８０３に進む。ステップＳ８０３に進むと、パケット取得アプリケーション３０５は、パケットの取得を続行する。具体的に説明すると、ステップＳ８０３において、パケット取得アプリケーション３０５は、図５を用いて説明したのと同様に、異常通信ログを採取するステップを繰り返し行う。その後、エラージョブパケットのパケットの総数の１０倍以上になったら、ステップＳ８０４へ移行する。

ステップＳ８０４に進むと、パケット取得アプリケーション３０５は、異常通信ログ内の異常通信内容と、エラージョブパケットのファイル内の異常通信内容とを比較する処理を行う。具体的に説明すると、パケット取得アプリケーション３０５は、異常通信ログと、エラージョブパケットのファイルとの各々において、異常通信が何回発生しているかを算出して、統計的に出現傾向に比べ、特異な結果が発生している箇所を抽出する。異常通信ログ内の異常通信内容から回数を算出する場合には、エラーが発生したアプリケーションと同一のアプリケーションによって通信されたログのみを抽出して算出する。

例えば、エラーが発生したアプリケーションがＰＤＬ部４０２であるとする。そうすると、ＰＤＬ部４０２の下位層でネットワークサーバとして動作するアプリケーションはＬＰＤ部４０１である。したがって、パケット取得アプリケーション３０５は、ＬＰＤ部４０１による通信で使用されたパケットのみを異常通信ログから抽出する。より具体的に説明すると、ＬＰＤ部４０１のポート番号は５１５であるため、パケット取得アプリケーション３０５は、ＳＲＣポート及びＤＳＴポートが５１５であるパケットを抽出する。加えて、パケット取得アプリケーション３０５は、抽出したパケットに関連したパケットも抽出する。関連したパケットとは、例えばＡＲＰパケットである。

そして、パケット取得アプリケーション３０５は、抽出したパケットに対して、夫々の異常通信の発生回数を算出して、統計的な出現傾向を抽出する。図１２は、異常通信ログのパケット数とエラージョブパケットのパケット数と、特異性の有無との一例を、異常通信の内容毎に表形式で示した図である。
図１２において、再送１００１、通信切断１００２、ビジー１００３、通信タイムアウト１００４が、異常通信（異常なパケット）の種類である。
異常通信ログ１０１０のパケットのうち、該当するエラー（再送１００１、通信切断１００２、ビジー１００３、通信タイムアウト１００４）が発生したパケットの個数が、異常通信ログ１０１０の列に示される。同様に、エラージョブパケット１０２０のパケットのうち、該当するエラーが発生したパケットの個数が、エラージョブパケット１０２０の列に示される。
対象パケット数１００５は、対象となるパケット（異常通信ログ１０１０のパケット及びエラージョブパケット１０２０のパケット）の総数が示される。
特異性１０３０の列には、出現傾向の特異性の有無が示されている。
再送１００１については、異常通信ログ１０１０の発生回数が８９８回であるのに対してエラージョブパケット１０２０の発生回数は２回である。ここで、対象パケット数１００５の割合は略４５００：１であるため、その割合を再送１００１の発生回数に当てはめると、完全ではないが比例の相関関係にあることが分かる。通信切断１００２とビジー１００３についても同様に、異常通信ログ１０１０とエラージョブパケット１０２０の発生回数に相関関係がある。よってこれらはデータ上の特異性はないと判断できる。一方、通信タイムアウト１００４については、異常通信ログ１０１０の発生回数に対してエラージョブパケット１０２０での発生回数が相対的に多いことが確認できる。そのため、通信タイムアウト１００４については特異性があるものと判断される。このように、異常通信ログ１０１０とエラージョブパケット１０２０とを比較して異常通信に特異性が存在したと判断された場合には、特異性のある現象がアプリケーションエラーの発生に関連している可能性がある。

尚、上述では対象パケット数に対する各異常パケット数の割合の比較を行っていたが、出現傾向の特異性を求める手法はそれに限らない。例えば、異なる種類の異常パケット同士の関係同士を比較することにより、出現傾向の特異性を求めることができる。具体的には、異常通信ログ１０１０の再送、通信切断、通信タイムアウトの割合の比は略８：４：１である。それと比較して、エラージョブパケット１０２０は再送、通信切断、通信タイムアウトの割合の比は略２：１：５０である。この場合、通信タイムアウトが相対的に出現傾向に特異性を含むことが判断できる。このように、エラーによっては、いくつかの異常パケットを抽出して、出現傾向の特異性を求めてもよい。

図１０の説明に戻り、ステップＳ８０５に進むと、パケット取得アプリケーション３０５は、発生したアプリケーションのエラーから推測される異常通信を導き出す。ＰＤＬエラーに対応する異常通信としては、例えば、前述した図１１に示すようなものである。パケット取得アプリケーション３０５は、内部的に保持している"図１１に示す情報"から異常通信を抽出する。例えば、発生したＰＤＬエラーがSYNTAXエラーであるとすると、ＰＤＬエラーの原因と推測できる異常通信（異常なパケット）の種類は、図１１から、ビジーと通信タイムアウトであると検出できる。
以上のように本実施形態では、パケット取得アプリケーション３０５は、次のような処理を行う。すなわち、図１２に示す情報を用いて、異常通信ログ１０１０における異常なパケットの出現傾向に対して、アプリケーション３１０の実行に基づいて取得されたパケットのうち異なる出現傾向を示すパケットの種類１００１〜１００４を検出する。

次に、ステップＳ８０６において、パケット取得アプリケーション３０５は、エラージョブパケットの異常通信のログ化処理を行う。具体的に説明すると、パケット取得アプリケーション３０５は、エラージョブパケットの全てのパケットに対して、図６に示した異常通信の発生の有無を抽出し、抽出した内容を、アプリケーションの異常通信ログとしてファイル化する。ログとして保存される情報は、例えば、ステップＳ５０４の処理と同様に、取得日時、プロトコル情報、及び異常通信の種別を含む。プロトコル情報には、ネットワークアプリケーションを特定することができる情報が含まれる。更に、パケット取得アプリケーション３０５は、ステップＳ８０４で抽出（推測）した特異性のある異常通信と、ステップＳ８０５で抽出したＰＤＬエラーの原因と推測される異常通信とを、それらが分かるようにアプリケーションの異常通信ログに書き込む。図１３は、アプリケーションの異常通信ログの一例を示す図である。

図１３において、フレーム１１０１は異常通信である再送が発生しているためログ化されている。フレーム１１０２はビジーであったためログ化される。加えて、ビジーはステップＳ８０５において、ＰＤＬエラー（SYNTAXエラー）の原因である可能性があると抽出されているため、ログ中に下記のメッセージが含まれている。
［ＰＤＬエラー（SYNTAXエラー）との関連可能性あり］

また、フレーム１１０３はタイムアウトが発生しているためログ化される。加えて、タイムアウトはステップＳ８０５において、ＰＤＬエラー（SYNTAXエラー）の原因である可能性があると抽出されているため、ログ中に下記のメッセージが含まれている。
［ＰＤＬエラー（SYNTAXエラー）との関連可能性あり］
更に、タイムアウトは、ステップＳ８０４において、異常通信の発生個数において特異な結果が確認された現象である。このため、パケット取得アプリケーション３０５は、ステータスに「（特異現象）」メッセージを記載して、ログの解析者にその旨を促す。つまりフレーム１１０３のタイムアウトは、エラーの種類から類推される障害の原因となるパケットでもあり、ＰＤＬエラー発生時に統計的にも異常な発生頻度を示したものであることを解析者に容易に知らせることができる。このように本実施形態では、パケット取得アプリケーション３０５は、図１３に示す情報を表示することにより、異常通信ログ（パケット）を表示する際に、ステップＳ８０５で検出された異常通信（異常なパケット）の種類を解析者が識別可能に表示する。

そして、解析者（例えばＰＣ１０２、１０４）は、ＨＤＤ２００４に保存されている"ＰＤＬエラーを発生させたエラージョブパケットのファイル"と、ステップＳ８０６で作成したアプリケーションの異常通信ログとをＭＦＰ１０１から吸い上げる。これにより、障害解析を高速に行う事を可能とする。エラージョブパケットのファイルと、アプリケーションの異常通信ログとを吸い上げる手法は、例えばＦＴＰ（File Transfer Protocol）やＳＳＨ（Secure Shell）といったプロトコルによって実現される。

以上のように本実施形態では、ＭＦＰ１０１は、受信したパケットを印刷ジョブ単位でファイルとして一時的に保存すると共に、異常通信情報をログ（異常通信ログ）として保存する。ＭＦＰ１０１は、保存したファイルの中で、アプリケーションでエラーが発生しないデータについては削除する。そして、ＭＦＰ１０１は、任意の印刷ジョブの処理中にエラーが発生した場合、受信したパケットを記憶装置に保存し、且つエラーが発生したジョブパケットに含まれる異常通信と、受信した全ての印刷ジョブに関するパケットに含まれる異常通信とを比較する。そして、その比較の結果として、エラーが発生したジョブパケットにのみ含まれる異常通信を抽出し、抽出した結果が分かるようにログ化する。また、エラーの内容から原因の可能性が疑われる異常通信を判断してログ化する。

以上のようにすることにより、機器（ＭＦＰ１０１）が取得した全てのパケットを記憶装置に保存するのではなく、アプリケーションでエラーが発生したアプリケーションデータに関連したパケットのみを保存するため、記憶装置の容量削減が可能になる。また、アプリケーションでエラーが発生したデータのパケットと、通常時のパケットとに含まれる異常通信との発生頻度を比較してその結果をログ化することにより、異常通信の中で、特異な現象を抽出することができ、障害原因の調査の補助情報を提供できる。また、アプリケーションで発生したエラーの内容から、障害の原因である可能性が高い異常通信を導き、ログ化することにより障害原因の調査の補助情報を提供できる。

尚、本実施形態では、取得したパケットの全てを異常通信ログとするようにしたが、必ずしもこのようにする必要はない。例えば、取得したパケットのうち、アプリケーションによる処理の実行（ジョブの実行）が正常に終了したが、異常通信があったパケットのみを異常通信ログとして記憶するようにしてもよい。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。前述した第１の実施形態では、アプリケーションの一例としてＰＤＬ部４０２でエラーが発生した場合を例に挙げて説明した。これに対し、本実施形態では、データ送信アプリケーション４０４でエラーが発生した場合を例に挙げて説明する。このように本実施形態と前述した第１の実施形態とはエラーが発生したアプリケーションが異なるだけであるので、本実施形態の説明において、前述した第１の実施形態と同一の部分については、図１〜図１３に付した符号を付すこと等により、詳細な説明を省略する。

図１４は、データ送信アプリケーション４０４で発生するエラーの内容の一例を示す図である。
図１４において、データ送信アプリケーションエラーの内容１２１０は、データ送信アプリケーション４０４がスキャンデータをメールサーバ１０５に送信する際に発生したエラーの内容の一例を示すものである。疑うべき異常通信１２２０は、エラーの原因として考えられるネットワークの異常通信の一例を示すものである。データ送信アプリケーション４０４がデータを送信中にエラーが発生した場合、図１０に示したフローチャートに従って処理が進行する。ステップＳ８０１〜Ｓ８０４までの処理は、前述した第１の実施形態と基本的に同じであるため、ここでの説明は割愛する。
ステップＳ８０５に進むと、パケット取得アプリケーション３０５は、発生したデータ送信アプリケーション４０４のエラー（データ送信アプリケーションエラー）から推測される異常通信を導き出す。具体的に説明すると、パケット取得アプリケーション３０５は、内部的に保持している"図１４に示す情報"から異常通信を抽出する。例えば、データ送信アプリケーションエラーが送信タイムアウトであるとすると、データ送信アプリケーションエラーの原因と推測できる異常通信は、図１４から、通信切断と通信タイムアウトとビジーであると推測できる。

次に、ステップＳ８０６において、パケット取得アプリケーション３０５は、エラージョブパケットの異常通信のログ化処理を行う。具体的に説明すると、パケット取得アプリケーション３０５は、エラージョブパケットの全てのパケットに対して、図６に示した異常通信の発生の有無を抽出し、抽出した内容を、アプリケーション異常通信ログとしてファイル化する。ログとして保存される情報は、例えば、ステップＳ５０４の処理と同様に、取得日時、プロトコル情報、及び異常通信の種別を含む。プロトコル情報には、ネットワークアプリケーションを特定することができる情報を含む。更に、パケット取得アプリケーション３０５は、次の処理を行う。すなわち、ステップＳ８０４で抽出（推測）した特異性のある異常通信と、ステップＳ８０５で抽出したデータ送信アプリケーションエラーの原因と推測される異常通信とを、それらが分かるようにアプリケーション異常通信ログに書き込む。
以上のように、データ送信アプリケーション４０４でエラーが発生した場合にも、第１の実施形態で説明したのと同様の効果を得ることができる。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。前述した第１の実施形態では、図１０のステップＳ８０２において、パケット数を比較して異常通信ログが比較可能な状態か否かを判定するようにした。これに対し本実施形態では、パケット数に加えて経過時間等も考慮して異常通信ログが比較可能な状態か否かを判定するようにした。このように本実施形態と前述した第１及び第２の実施形態とは、異常通信ログが比較可能な状態か否かを判定する際の動作が主として異なる。したがって、本実施形態の説明において、前述した第１及び第２の実施形態と同一の部分については、図１〜図１４に付した符号を付すこと等により、詳細な説明を省略する。

図１０のステップＳ８０２において、パケット取得アプリケーション３０５は、エラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数を確認する。エラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数が少ない場合、互いの異常通信の内容を比較したとしても、比較結果から導き出されるエラーの原因の信頼性は高くない。そのため、比較の信頼性を確保できる状態になるまで異常通信ログの採取を続行する。本実施形態においても、エラージョブパケットのパケット数に対して、そのエラージョブパケットの異常通信内容と比較する対象となる異常通信ログのパケット数が１０倍を超えた場合に、比較の信頼性を確保できる状態であるとする。

ステップＳ８０２の処理をより具体的に説明すると、まず、パケット取得アプリケーション３０５は、エラージョブパケットのファイルから、パケットの総数を取得する。そして、パケット取得アプリケーション３０５は、取得したパケットの総数と、図５のステップＳ５０２にて内部的に確保しているパケットの総数とを比較する。この比較の結果、図５のステップＳ５０２にて内部的に確保しているパケットの総数が、エラージョブパケットのパケットの総数の１０倍を超えたならば、ステップＳ８０３を省略してステップＳ８０４に進む。

一方、図５のステップＳ５０２にて内部的に確保しているパケットの総数が、エラージョブパケットのパケットの総数の１０倍を超えていない場合には、ステップＳ８０３に進む。ステップＳ８０３に進むと、パケット取得アプリケーション３０５は、パケットの取得を続行する。ここで、パケットの取得を開始してからの経過時間が、一定時間を過ぎた場合には、内部的に確保するパケットの総数が規定値（１０倍）を超えていない場合でも、パケットの取得を中止する。前記一定時間に到達する前に、受信したパケットの数がエラージョブパケットのパケット数の１０倍を超えた場合には、ステップＳ８０４に進む。

以上のようにすることにより、第１及び第２の実施形態で説明した効果に加え、異常通信ログとエラージョブパケットとの比較（ステップＳ８０４）が行われない状態になることを防止することができる。
尚、本実施形態では、内部的に確保するパケットの総数が規定値に達していない場合でも、パケットを取得するための処理時間が一定時間を過ぎた場合には、パケットの取得を中止してステップＳ８０４に進むようにしたが、必ずしもこのようにする必要はない。例えば、内部的に確保するパケットの総数が規定値に達していない場合でも、通信サービス（例えば、印刷、スキャン、コピー等）の内容によって、パケットの取得を中止するようにしてもよい。このようにする場合、異常通信ログに、通信サービスに関する情報を含めるようにする。

（第４の実施形態）
次に、本発明の第４の実施形態について説明する。本実施形態では、図５のステップＳ５０３における判定の判定基準（異常通信であるか否かの判断基準）を編集可能にするようにしている。このように本実施形態と前述した第１〜第３の実施形態に、図５のステップＳ５０３における判定の判定基準を編集する構成を付加したものになる。したがって、本実施形態の説明において、前述した第１〜第３の実施形態と同一の部分については、図１〜図１４に付した符号を付すこと等により、詳細な説明を省略する。

パケット取得アプリケーション３０５は、起動時に、ＨＤＤ２００４の所定のディレクトリを確認し、そこにコンフィギュレーションファイルが存在しているか否かを判定する。この判定の結果、ＨＤＤ２００４の所定のディレクトリにコンフィギュレーションファイルがない場合、パケット取得アプリケーション３０５は、第１の実施形態で説明した"図６に示したルール"に従って、異常通信と判定すべき通信上の挙動を定義する。
一方、ＨＤＤ２００４の所定のディレクトリにコンフィギュレーションファイルが存在している場合、パケット取得アプリケーション３０５は、コンフィギュレーションファイルに示されているルールに従って、異常通信と判定すべき通信上の挙動を定義する。

図１５は、コンフィギュレーションファイルの一例を示す図である。コンフィギュレーションファイルは、ユーザによって予め設定されるものである。
図１５において、命令部１３０１は、図６に示した異常通信の各動作に対して、異常通信と見なすか否かを設定している部分である。各項目についてＹＥＳ又はＮＯが指定されることによって、異常通信と判断する／しないが設定される。命令部１３０２は、より詳細なデータ指定を行うための部分である。パケットのデータを１バイト単位で指定していくことにより、指定されたパターンにマッチするパケットを受信した際に、それを異常通信と見なす。コンフィギュレーションファイルは、ＦＴＰやＳＳＨといったプロトコルによってＭＦＰ１０１内にプットされる。
以上のようにすることにより、第１〜第３の実施形態で説明した効果に加え、特定のパターンを予めユーザが設定しておくことで、異常通信であるか否かをより柔軟に判定することができる。

（本発明の他の実施形態）
前述した本発明の実施形態における画像形成装置を構成する各手段、並びに解析方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図５、図１０に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給するものを含む。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の第１の実施形態を示し、ネットワークシステムの構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、ＭＦＰのコントローラの主要部の構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、ＭＦＰの主要な機能構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、アプリケーションの構成の一例を詳細に示したブロック図である。 本発明の第１の実施形態を示し、通常状態におけるパケットを取得する際の動作の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、ステップＳ５０３において異常と判定すべき通信上の挙動の一例を示した図である。 本発明の第１の実施形態を示し、受信したパケットのデータグラムを可視化したものの一例を示す図である。 本発明の第１の実施形態を示し、異常通信ログの一例を示す図である。 本発明の第１の実施形態を示し、ステップＳ５０５で生成されたファイルのデータの内容の一例を可視化した図である。 本発明の第１の実施形態を示し、図５のステップＳ５０９におけるエラー解析処理の詳細を説明するフローチャートである。 本発明の第１の実施形態を示し、ＬＰＤ部を経由して受信したＰＤＬデータをＰＤＬ部が処理する際に発生するエラーの内容と、そのエラーの原因となる可能性が考えられる"ネットワーク通信上の異常"との一例を表形式で対応させて示す図である。 本発明の第１の実施形態を示し、異常通信ログのパケット数とエラージョブパケットのパケット数と、特異性の有無との一例を、異常通信の内容毎に表形式で示した図である。 本発明の第１の実施形態を示し、アプリケーションの異常通信ログの一例を示す図である。 本発明の第２の実施形態を示し、データ送信アプリケーションで発生するエラーの内容の一例を示す図である。 本発明の第４の実施形態を示し、コンフィギュレーションファイルの一例を示す図である。

符号の説明

１０１ ＭＦＰ
１０２、１０４ ＰＣ
１０３ ＬＡＮ
１０５ メールサーバ
３０１ アプリケーション
３０２ ソケットＩ／Ｆ
３０３ ネットワークスタック
３０４ ネットワークデバイスドライバ
３０５ パケット取得アプリケーション

Claims (13)

1. ジョブの処理に用いるアプリケーションの実行に基づくパケットを取得する取得手段と、
   前記取得手段により取得されたパケットに異常があるか否かを判断する判断手段と、
   前記判断手段によりパケットに異常があると判断されると、当該パケットに関する情報を記憶媒体に記憶する記憶手段と、
   ジョブの処理に用いるアプリケーションの実行にエラーが発生した場合、当該アプリケーションの実行に基づき取得されるパケットの出現傾向と、当該アプリケーションが正常に実行された際に前記記憶手段に記憶された異常があると判断されたパケットの出現傾向とを比較する比較手段と、
   前記比較手段により、当該アプリケーションが正常に実行された際に前記記憶手段に記憶された異常があると判断されたパケットの出現傾向に対して、当該アプリケーションの実行に基づき取得されるパケットのうち異なる出現傾向を示すパケットの種類を検出する検出手段とを有することを特徴とする画像形成装置。
2. 前記検出手段は、アプリケーションの実行で発生したエラーの種類に応じて、当該エラーの原因の可能性があるパケットの種類を検出する特徴とする請求項１に記載の画像形成装置。
3. 前記記憶手段に記憶されたパケットを表示する際、前記検出手段により検出された種類のパケットを識別可能に表示する表示手段を有することを特徴とする請求項１または２に記載の画像形成装置。
4. 前記比較手段は、ジョブの処理に用いるアプリケーションの実行にエラーが発生した際に前記記憶手段に記憶された当該アプリケーションの実行に基づくパケットの数が閾値以下の場合は比較を行わず、前記記憶手段に記憶された当該アプリケーションの実行に基づくパケットの数が当該閾値を超えた場合に比較を行うことを特徴とする請求項１乃至３の何れか１項に記載の画像形成装置。
5. 前記比較手段は、ジョブの処理に用いるアプリケーションの実行にエラーが発生した際に前記記憶手段に記憶された当該アプリケーションの実行に基づくパケットの数が閾値以下の場合は比較を行わず、予め定められた時間が経過した場合に比較を行うことを特徴とする請求項１乃至４の何れか１項に記載の画像形成装置。
6. 前記取得手段により取得されたパケットをジョブ単位で記憶媒体に保存する保存手段と、
   前記保存手段により保存されたパケットに関連するジョブが正常に終了すると、そのパケットを削除する削除手段とを有することを特徴とする請求項１乃至５の何れか１項に記載の画像形成装置。
7. ジョブの処理に用いるアプリケーションの実行に基づくパケットを取得する取得工程と、
   前記取得工程により取得されたパケットに異常があるか否かを判断する判断工程と、
   前記判断工程によりパケットに異常があると判断されると、当該パケットに関する情報を記憶媒体に記憶する記憶工程と、
   ジョブの処理に用いるアプリケーションの実行にエラーが発生した場合、当該アプリケーションの実行に基づき取得されるパケットの出現傾向と、当該アプリケーションが正常に実行された際に前記記憶工程に記憶された異常があると判断されたパケットの出現傾向とを比較する比較工程と、
   前記比較工程により、当該アプリケーションが正常に実行された際に前記記憶工程に記憶された異常があると判断されたパケットの出現傾向に対して、当該アプリケーションの実行に基づき取得されるパケットのうち異なる出現傾向を示すパケットの種類を検出する検出工程とを有することを特徴とする解析方法。
8. 前記検出工程は、アプリケーションの実行で発生したエラーの種類に応じて、当該エラーの原因の可能性があるパケットの種類を検出する特徴とする請求項７に記載の解析方法。
9. 前記記憶工程に記憶されたパケットを表示する際、前記検出工程により検出された種類のパケットを識別可能に表示するための制御を行う制御工程を有することを特徴とする請求項７または８に記載の解析方法。
10. 前記比較工程は、ジョブの処理に用いるアプリケーションの実行にエラーが発生した際に前記記憶工程に記憶された当該アプリケーションの実行に基づくパケットの数が閾値以下の場合は比較を行わず、前記記憶工程に記憶された当該アプリケーションの実行に基づくパケットの数が当該閾値を超えた場合に比較を行うことを特徴とする請求項７乃至９の何れか１項に記載の解析方法。
11. 前記比較工程は、ジョブの処理に用いるアプリケーションの実行にエラーが発生した際に前記記憶工程に記憶された当該アプリケーションの実行に基づくパケットの数が閾値以下の場合は比較を行わず、予め定められた時間が経過した場合に比較を行うことを特徴とする請求項７乃至１０の何れか１項に記載の解析方法。
12. 前記取得工程により取得されたパケットをジョブ単位で記憶媒体に保存する保存工程と、
    前記保存工程により保存されたパケットに関連するジョブが正常に終了すると、そのパケットを削除する削除工程とを有することを特徴とする請求項７乃至１１の何れか１項に記載の解析方法。
13. 請求項７乃至１２の何れか１項に記載の解析方法の工程をコンピュータに実行させることを特徴とするコンピュータプログラム。

Images