JP2019134336A - 通信システム、通信装置、通信装置の制御方法、プログラム - Google Patents

Abstract

【課題】異常発生時の通信パケットを効率的に取得することが可能な技術を提供する。【解決手段】ＭＦＰ（通信装置）は、現在のデータ通信時の通信条件とエラー履歴情報に含まれる過去の一のエラー発生時の通信条件との両通信条件を比較しＳＰ１４、少なくとも１つの所定項目に関する両通信条件の内容が互いに同一であると判定されることを条件として、現在のデータ通信に関する通信パケット群の取得処理を開始するＳ３０。また、ＭＦＰは、エラー履歴情報に含まれる一のエラーのエラー種別と同じ種別のエラーが現在のデータ通信にて発生したことを条件として、通信パケット群の取得処理によって取得された通信パケット群を所定の格納部に格納する。【選択図】図３

Description

本発明は、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））などの通信装置およびそれに関連する技術に関する。

企業等に構築された通信ネットワークにおいて通信障害が発生した場合、当該通信障害の原因を早急に究明し当該通信障害を早急に解消することが求められる。

このような通信障害の原因を特定する技術として、ネットワークにおける通信パケット群を取得し、当該通信パケット群の内容を解析する技術（通信パケット解析技術）が存在する。近年、通信パケット群の取得機能を備えた通信装置（ＭＦＰ等）も存在し、通信装置自体で通信パケット群を取得することも可能である。

しかしながら、このような技術において、全てのデータ通信に関する全ての通信パケットを一律に取得して格納すると、データ格納容量が増大する、との問題が生じる。

これに対して、特許文献１には次のような技術が記載されている。

特許文献１に記載の技術においては、ＭＦＰが、全てのデータ通信の実行時において常に通信パケットデータを取得しておき、取得された通信パケットデータを印刷ジョブ単位で一旦保存する。その後、エラーが発生していない印刷ジョブに関する通信パケットデータは、削除される。

これによれば、エラーが発生していない印刷ジョブに関する通信パケットデータは、最終的には削除されるので、データ格納容量の増大を抑制することが可能である。

特開２００９−１１８１９０号公報

しかしながら、特許文献１では、通信パケットの取得自体は常に実行されており、通信パケット取得処理のための処理負荷がＭＦＰにおいて常に発生しているなど、必ずしも効率的なパケット取得処理は行われていない。

そこで、本発明は、異常発生時の通信パケットを効率的に取得することが可能な技術を提供することを課題とする。

上記課題を解決すべく、請求項１の発明は、通信装置であって、前記通信装置と外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得する履歴情報取得手段と、前記通信装置と一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較する比較手段と、少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するパケット取得手段と、前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納する格納制御手段と、を備えることを特徴とする。

請求項２の発明は、請求項１の発明に係る通信装置において、前記格納制御手段は、前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生しなかった場合、前記取得処理によって取得された前記通信パケット群を前記所定の格納部に格納せずに廃棄することを特徴とする。

請求項３の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記第２の通信条件と同じ通信条件を有し且つエラーが発生した別の過去のデータ通信である同一条件異常通信に関する別の通信パケット群が未だ格納されていないことをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする。

請求項４の発明は、請求項３の発明に係る通信装置において、前記エラー履歴情報は、前記同一条件異常通信に関する前記別の通信パケット群が既に取得され格納されているか否かを示す格納実績情報をも含み、前記パケット取得手段は、前記エラー履歴情報に含まれる前記格納実績情報に基づいて、前記同一条件異常通信に関する前記別の通信パケット群が既に格納されているか否かを判定することを特徴とする。

請求項５の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記第２の通信条件と同じ通信条件を有し且つ前記一のエラー発生時のデータ通信と前記新たなデータ通信との間にエラーを伴って実行された少なくとも１つのデータ通信である少なくとも１つの同一条件異常通信に関する別の通信パケット群の格納回数が所定回数未満であることをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする。

請求項６の発明は、請求項５の発明に係る通信装置において、前記エラー履歴情報は、前記少なくとも１つの同一条件異常通信に関する前記通信パケット群が取得され格納された回数を示す格納実績情報をも含み、前記パケット取得手段は、前記エラー履歴情報に含まれる前記格納実績情報に基づいて、前記少なくとも１つの同一条件異常通信に関する前記別の通信パケット群の前記格納回数を判定することを特徴とする。

請求項７の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、通信パケットの取得許可が前記通信装置に付与されていることをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする。

請求項８の発明は、請求項１の発明に係る通信装置において、前記格納制御手段は、前記取得処理によって取得された前記通信パケット群を、データ通信ごとに設けられるデータファイルに格納することを特徴とする。

請求項９の発明は、請求項８の発明に係る通信装置において、前記エラー履歴情報において、前記少なくとも１つの所定項目に関して前記第１の通信条件と同じ通信条件を有する前記過去のデータ通信に関連付けて、前記データファイルのファイル名と前記データファイルの格納先装置名とを記録する履歴情報更新手段、をさらに備えることを特徴とする。

請求項１０の発明は、請求項１の発明に係る通信装置において、前記格納制御手段は、前記取得処理により取得された前記通信パケット群を前記所定の格納部に格納するにあたって、当該通信パケット群に含まれる各通信パケットの通信タイミングと前記通信装置における所定のアプリケーションソフトウエアの進捗段階との関係を記録したデータをも格納することを特徴とする。

請求項１１の発明は、請求項１の発明に係る通信装置において、前記格納制御手段は、前記取得処理により取得された前記通信パケット群に関連付けて、前記新たなデータ通信の実行ジョブの情報をも格納することを特徴とする。

請求項１２の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始した後、前記一のエラーのエラー種別と同じ種別のエラーの原因が解消されていると判定される場合、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を中止することを特徴とする。

請求項１３の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記両通信条件が互いに同一であると判定された場合であっても、前記一のエラーの原因が既に解消されていると判定されるときには、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始しないことを特徴とする。

請求項１４の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記両通信条件が互いに同一であると判定された場合であっても、前記一のエラーの解消策が既に得られていると判定されるときには、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始しないことを特徴とする。

請求項１５の発明は、請求項１の発明に係る通信装置において、前記少なくとも１つの所定項目は、通信先装置と通信プロトコルとポート番号とのいずれかを含むことを特徴とする。

請求項１６の発明は、請求項１の発明に係る通信装置において、前記少なくとも１つの所定項目は、階層化された複数の項目を含み、前記複数の項目は、上位階層項目と当該上位階層項目よりも下位の下位階層項目とを含むことを特徴とする。

請求項１７の発明は、請求項１６の発明に係る通信装置において、前記上位階層項目は、通信プロトコルであり、前記下位階層項目は、前記通信プロトコルでの認証方式であることを特徴とする。

請求項１８の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記新たなデータ通信としてデータ送信が行われる場合、前記データ送信の開始前に前記通信パケット群の前記取得処理を開始することを特徴とする。

請求項１９の発明は、請求項１８の発明に係る通信装置において、前記パケット取得手段は、前記新たなデータ通信としてスキャン画像のデータ送信が行われる場合、前記スキャン画像の生成開始指示の直後ではなく、前記生成開始指示に応じて原稿の読取処理が開始された後且つ前記データ送信の開始直前に、前記通信パケット群の前記取得処理を開始することを特徴とする。

請求項２０の発明は、請求項１の発明に係る通信装置において、前記パケット取得手段は、前記新たなデータ通信としてデータ受信が行われる場合、前記データ受信の開始後において前記第１の通信条件における前記少なくとも１つの所定項目の内容が確定した後に、前記少なくとも１つの所定項目に関する前記両通信条件の内容の同一性を判定することを特徴とする。

請求項２１の発明は、請求項１８または請求項１９の発明に係る通信装置において、前記パケット取得手段は、前記新たなデータ通信としてデータ受信が行われる場合、前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であるか否かにかかわらず、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始し、前記データ受信の開始後において前記第１の通信条件における前記少なくとも１つの所定項目の内容が確定した後に、前記少なくとも１つの所定項目に関する前記両通信条件の内容の同一性を判定し、前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一ではないと判定される場合、前記通信パケット群の前記取得処理を終了し、前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定される場合、前記通信パケット群の前記取得処理を継続することを特徴とする。

請求項２２の発明は、請求項１の発明に係る通信装置において、前記格納制御手段は、前記通信装置と前記通信装置の外部の一または複数の装置との間で授受される全ての通信パケットのうち、予め設定された所定の条件に合致する一部の通信パケットのみを、前記通信パケット群として前記所定の格納部に格納することを特徴とする。

請求項２３の発明は、請求項１の発明に係る通信装置において、前記所定の格納部は、前記通信装置に設けられることを特徴とする。

請求項２４の発明は、請求項１の発明に係る通信装置において、前記所定の格納部は、前記通信装置と通信可能な所定の外部の装置に設けられることを特徴とする。

請求項２５の発明は、請求項１の発明に係る通信装置において、前記エラー履歴情報は、前記通信装置に格納されることを特徴とする。

請求項２６の発明は、請求項１の発明に係る通信装置において、前記エラー履歴情報は、前記通信装置と通信可能な所定の外部の装置に格納されることを特徴とする。

請求項２７の発明は、通信装置の制御方法であって、ａ）前記通信装置と外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得するステップと、ｂ）前記通信装置と一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較するステップと、ｃ）少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するステップと、ｄ）前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納するステップと、を備えることを特徴とする。

請求項２８の発明は、請求項２７の発明に係る制御方法を、前記通信装置に内蔵されたコンピュータに実行させるプログラムであることを特徴とする。

請求項２９の発明は、複数の通信装置を備える通信システムであって、前記複数の通信装置は、それぞれ、外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得する履歴情報取得手段と、一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較する比較手段と、少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するパケット取得手段と、前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納する格納制御手段と、を備え、前記複数の通信装置のそれぞれは、前記複数の通信装置に共通する共通エラー履歴情報を前記エラー履歴情報として利用することを特徴とする。

請求項３０の発明は、請求項２９の発明に係る通信システムにおいて、前記エラー履歴情報は、前記複数の通信装置のそれぞれに設けられ、前記複数の通信装置のそれぞれは、自装置内の前記エラー履歴情報を更新した際に、他の各装置内の前記エラー履歴情報をも更新させることによって、前記共通エラー履歴情報を構築することを特徴とする。

請求項３１の発明は、請求項２９の発明に係る通信システムにおいて、前記複数の通信装置と通信することが可能なサーバ、をさらに備え、前記共通エラー履歴情報は、前記サーバに設けられ、前記複数の通信装置のそれぞれは、前記サーバに設けられた前記共通エラー履歴情報にアクセスして前記エラー履歴情報を取得することを特徴とする。

請求項３２の発明は、請求項３１の発明に係る通信システムにおいて、前記サーバと通信することが可能な上位サーバ、をさらに備え、前記サーバは、前記一のエラーの解消策が既に得られているか否かを前記上位サーバに問い合わせ、前記サーバは、前記一のエラーの解消策が既に得られている旨の問合せ結果を前記上位サーバから受信すると、前記サーバに格納された前記エラー履歴情報における実行制御情報を更新し、前記一のエラーの発生時と同じ通信条件を有する前記新たなデータ通信に関する前記通信パケット群の前記取得処理を前記複数の通信装置のそれぞれに実行させないことを特徴とする。

請求項１から請求項３２に記載の発明によれば、全てのデータ通信に関して一律に通信パケット群が取得される場合に比べて、効率的に通信パケット群を取得することが可能である。

通信システムを示す図である。 ＭＦＰの機能ブロックを示す図である。 第１実施形態に係るＭＦＰの動作を示すフローチャートである。 第１実施形態に係るＭＦＰの動作を示すフローチャートである。 エラー履歴情報の一例を示す図である。 第２実施形態に係るＭＦＰの動作を示すフローチャートである。 第２実施形態に係るＭＦＰの動作を示すフローチャートである。 第２実施形態に係るエラー履歴情報の一例を示す図である。 変形例に係る通信システムを示す図である。 別の変形例に係る通信システムを示す図である。 更に別の変形例に係る通信システムを示す図である。

以下、本発明の実施形態を図面に基づいて説明する。

＜１．第１実施形態＞
＜１−１．システム構成＞
図１は、本発明の第１実施形態に係る通信システム１（１Ａとも称する）を示す図である。図１に示すように、通信システム１は、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））１０と複数の通信先装置（パーソナルコンピュータ５０等）とを備える。ここでは、通信装置としてＭＦＰ１０を例示する。

本システム１における各要素１０，５０等は、ネットワーク１０８を介して互いに通信可能に接続される。ネットワーク１０８は、ＬＡＮ（Local Area Network）およびインターネットなどによって構成される。また、当該ネットワーク１０８に対する接続態様は、有線接続であってもよく、あるいは無線接続であってもよい。

この実施形態では、ＭＦＰ１０は、他の装置（５０等）とのデータ通信（スキャン画像のネットワーク送信等）における通信パケット群を取得して保存する処理を実行する。

具体的には、後述するように、現在のデータ通信時の通信条件Ｅ１と、エラー履歴情報２１０（図５）に含まれる過去の一のエラー発生時の通信条件Ｅ２との両者（両通信条件）が比較される。そして、少なくとも１つの所定項目（「通信先装置」等）に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一であると判定されることを条件として、現在のデータ通信に関する通信パケット群の取得が開始される。その後、当該現在のデータ通信にエラー（詳細には当該過去の一のエラーと同じ種別のエラー）が発生する場合、取得された通信パケット群が格納部５に格納される。これによれば、非常に効率的な通信パケット群の取得処理および格納処理が実現される。これらの動作については後に詳述する。

図２は、ＭＦＰ１０の機能ブロックを示す図である。

ＭＦＰ１０は、スキャン機能、コピー機能、ファクシミリ機能、ボックス格納機能およびウエブブラウザ機能などを備える装置（複合機とも称する）である。具体的には、ＭＦＰ１０は、図２の機能ブロック図に示すように、画像読取部２、印刷出力部３、通信部４、格納部５、操作部６およびコントローラ（制御部）９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。なお、ＭＦＰ１０は、画像処理装置あるいは画像形成装置などとも称される。

画像読取部２は、ＭＦＰ１０の所定の位置に載置された原稿を光学的に読み取って（すなわちスキャンして）、当該原稿の画像データ（原稿画像あるいはスキャン画像とも称する）を生成する処理部である。

印刷出力部３は、印刷対象に関するデータ（印刷対象データ）に基づいて紙などの各種の媒体に画像を印刷出力する出力部である。

通信部４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部４は、ネットワーク１０８を介したネットワーク通信を行うことも可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。当該ネットワーク通信を利用することによって、ＭＦＰ１０は、所望の相手先（コンピュータ５０および各種サーバ等）との間で各種のデータを授受することが可能である。通信部４は、各種データを送信する送信部４ａと各種データを受信する受信部４ｂとを有する。

格納部５は、ハードディスクドライブ（ＨＤＤ）および半導体メモリ等の記憶装置で構成される。格納部５には、エラー履歴情報２１０（後述）等が格納される。エラー履歴情報２１０には、ＭＦＰ１０と外部装置群（一または複数の装置（コンピュータ５０等））とのネットワーク通信に関する過去のエラー発生時の通信条件（ＭＦＰ１０の通信設定等）、および当該過去のエラーの種別情報等が含まれる。また、格納部５には、通信エラー解析等のために取得された通信パケット等も格納される。

操作部６は、ＭＦＰ１０に対する操作入力を受け付ける操作入力部６ａと、各種情報の表示出力を行う表示部６ｂとを備えている。

このＭＦＰ１０においては、略板状の操作パネル部６ｃ（図１参照）が設けられている。また、操作パネル部６ｃは、その正面側にタッチパネル２５（図１参照）を有している。タッチパネル２５は、操作入力部６ａの一部としても機能するとともに、表示部６ｂの一部としても機能する。タッチパネル２５は、液晶表示パネルに各種センサ等が埋め込まれて構成され、各種情報を表示するとともに操作ユーザからの各種の操作入力を受け付けることが可能である。

コントローラ９は、ＭＦＰ１０に内蔵され、ＭＦＰ１０を統括的に制御する制御装置である。コントローラ９は、ＣＰＵ（Central Processing Unit）（マイクロプロセッサあるいはコンピュータプロセッサなどとも称される）および各種の半導体メモリ（ＲＡＭおよびＲＯＭ）等を備えるコンピュータシステムとして構成される。コントローラ９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ（登録商標））内に格納されている所定のソフトウエアプログラム（以下、単にプログラムとも称する）を実行することによって、各種の処理部を実現する。なお、当該プログラム（詳細にはプログラムモジュール群）は、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体から読み出されてＭＦＰ１０にインストールされるようにしてもよい。あるいは、当該プログラムは、ネットワーク１０８等を経由してダウンロードされてＭＦＰ１０にインストールされるようにしてもよい。

具体的には、図２に示すように、コントローラ９は、当該プログラムの実行により、通信制御部１１と入力制御部１２と表示制御部１３と履歴情報取得部１４と比較部１５とパケット取得部１６と格納制御部１７と履歴情報更新部１８とを含む各種の処理部を実現する。

通信制御部１１は、他の装置（コンピュータ５０等）との間の通信動作を通信部４等と協働して制御する処理部である。通信制御部１１は、各種データの送信動作を制御する送信制御部と各種データの受信動作を制御する受信制御部とを有する。

入力制御部１２は、操作入力部６ａ（タッチパネル２５等）に対する操作入力動作を制御する制御部である。たとえば、入力制御部１２は、タッチパネル２５に表示された操作画面に対する操作入力を受け付ける動作を制御する。

表示制御部１３は、表示部６ｂ（タッチパネル２５等）における表示動作を制御する処理部である。

履歴情報取得部１４は、格納部５等に格納されているエラー履歴情報２１０（図５参照）を当該格納部５等から取得する処理部である。エラー履歴情報２１０は、ＭＦＰ１０と外部装置群（５０等）とのネットワーク通信（データ通信）に関する過去のエラー発生時における情報（具体的には、通信条件（当該ＭＦＰ１０の通信設定等）に関する情報、および当該過去のエラー（通信エラー）の種別に関する情報（エラー種別情報））を含む情報である。

なお、この実施形態では、エラー履歴情報２１０がＭＦＰ１０内の格納部５に格納されている。詳細には、ＭＦＰ１０に内蔵された記憶装置（ＨＤＤ、あるいは半導体メモリ（ＳＳＤ（Solid State Drive）、フラッシュメモリ、ＲＡＭ）等）にエラー履歴情報２１０が記録されている。しかしながら、これに限定されず、エラー履歴情報２１０は、ＭＦＰ１０に外付けされた記憶装置（ＵＳＢメモリ等）に記録されてもよい。あるいは、エラー履歴情報２１０は、ＭＦＰ１０内の格納部５ではなく、ＭＦＰ１０と通信可能な外部装置（たとえばサーバ７０（図９等参照）（後述））内の格納部等に格納されていてもよい。なお、エラー履歴情報２１０は、揮発性の記憶装置に記録されてもよいが、不揮発性の記憶装置に記録されることが好ましい。

比較部１５は、エラー履歴情報２１０に含まれる過去の一のエラーが発生した時の通信条件Ｅ２と、現在のデータ通信時の通信条件Ｅ１との両通信条件を比較する処理部である。

パケット取得部１６は、現在のデータ通信における通信パケット（詳細には通信パケット群）の取得動作を制御する処理部である。パケット取得部１６は、上記両通信条件Ｅ１，Ｅ２において少なくとも１つの所定項目に関する内容が互いに同一である（少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一である）と判定されることを条件として、当該現在のデータ通信に関する通信パケット群の取得動作を開始する。

格納制御部１７は、取得されたパケットの格納動作を制御する処理部である。格納制御部１７は、エラー履歴情報に含まれる一のエラーのエラー種別と同じ種別のエラーが現在のデータ通信にて発生したことを条件として、当該現在のデータ通信にて取得された通信パケット群を所定の格納部に格納する。

なお、この実施形態では、当該所定の格納部として、ＭＦＰ１０内の格納部５が主に例示される。詳細には、ＭＦＰ１０に内蔵された記憶装置（ＨＤＤ、あるいは半導体メモリ（ＳＳＤ，フラッシュメモリ、ＲＡＭ）等）に、当該現在のデータ通信にて取得された通信パケット群が記録される。しかしながら、これに限定されず、当該現在のデータ通信にて取得された通信パケット群は、ＭＦＰ１０に外付けされた記憶装置（ＵＳＢメモリ等）に記録されてもよい。あるいは、当該現在のデータ通信にて取得された通信パケット群は、ＭＦＰ１０内の格納部５ではなく、ＭＦＰ１０と通信可能な外部装置（たとえばサーバ７０（図９等参照））内の格納部等に格納されていてもよい。なお、当該通信パケット群は、揮発性の記憶装置に記録されてもよいが、不揮発性の記憶装置に記録されることが好ましい。

履歴情報更新部１８は、エラー履歴情報２１０（図５参照）にアクセスし、当該エラー履歴情報２１０の内容を更新する処理部である。

なお、ここでは、主にコントローラ９のＣＰＵにてソフトウエアプログラムを実行することによって、上述の各種の動作が実行されているが、これに限定されず、ＭＦＰ１０（詳細には、コントローラ９の内部あるいは外部）にて設けられた専用ハードウエア等を用いて、上述の各種の動作が実行されるようにしてもよい。たとえば、通信制御部１１、入力制御部１２、表示制御部１３、比較部１５、パケット取得部１６、格納制御部１７および履歴情報更新部１８（図２）等の全部または一部が、１または複数の専用ハードウエアを用いて実現されてもよい。

＜１−２．エラー履歴情報＞
次に、エラー履歴情報２１０について説明する。図５は、エラー履歴情報２１０の一例を示す図である。エラー履歴情報２１０には、過去の少なくとも１つのデータ通信（図５では複数のデータ通信）において発生したエラーに関する情報が記録される。エラー履歴情報２１０は、ＭＦＰ１０の格納部５内に格納される。

図５のエラー履歴情報２１０においては、複数のデータ通信で発生した複数のエラーのそれぞれに関して、複数の項目（「番号（Ｎｏ．）」、「登録日時（エラー発生日時）」、「送信先情報」、「プロトコル」、「エラー種別」、「ステータス」、「ファイル名」等）に関する内容が記録されている。また、各行のデータ（データレコードとも称する）は、それぞれ、一のエラーに関する情報（詳細には、当該一のエラーの複数の項目に関する情報）を有している。

各データレコードに関する上記の複数の項目には、過去のエラー発生時の通信条件（ＭＦＰ１０での通信設定等）（ここでは、「送信先情報」および「プロトコル」）が含まれる。「送信先情報」欄には、過去のエラー発生時の通信先装置の情報（ＩＰアドレス、ホスト名、および／またはドメイン名等）が記録される。また、「プロトコル」欄には、過去のエラー発生時に利用されていたプロトコル（通信プロトコル）の種類に関する情報が記録される。プロトコルの種類としては、ＦＴＰ（File Transfer Protocol）、ＳＭＢ（Server Message Block ）、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＷｅｂＤＡＶ（Web-based Distributed Authoring and Versioning）、ＬＰＤ（Line Printer Daemon）、ＩＰＰ（internet printing protocol）などが存在する。

また、当該複数の項目には、過去のエラー（通信エラー）の種別情報（「エラー種別」）等も含まれる。「エラー種別」としては、「接続エラー」（通信先装置の通信ポートが閉じている場合等に生じるエラー）、「名前解決エラー」、「認証エラー」、「コマンドエラー」、「その他の通信エラー」等が存在する。

また、当該複数の項目には、「ファイル名」および「ステータス」も含まれる。

「ファイル名」は、通信パケット記録用のデータファイルのファイル名（およびフォルダパス名））を示す欄である。当該データファイルには、過去のデータ通信の後に別のデータ通信（エラー発生通信）にて取得された通信パケット群の内容が記述される。詳細には、当該データファイルには、一のデータレコードに対応する一のエラーの発生後の別のデータ通信（同一条件異常通信（後述））にて取得された通信パケット群の内容が記述される。当該データファイルは、データ通信ごとに生成される。なお、当該データファイルがＭＦＰ１０以外の装置に格納される場合には、当該データファイルの格納先装置名も併せて記録されればよい。当該データファイルの格納先装置名は、フォルダパス名に含まれてもよく、フォルダパス名とは別に記録されてもよい。

また、「ステータス」は、同一種類の複数のエラーに関して取得された複数の通信パケット群の重複保存の是非等を制御するためのフラグ欄である。換言すれば、項目「ステータス」の値（「保存済」／「有効」）は、更なるエラー情報の保存を行うか否かを制御するための情報等として利用される。具体的には、或る種別のエラーが発生した場合、当該エラーの項目「ステータス」には、まず（初期的には）値「有効」が記録される。その後、当該或る種別のエラーに関するエラーが発生した場合に当該エラーに関する通信パケット群の情報が格納（保存）されると、項目「ステータス」の項目値が「有効」から「保存済」に変更される。「保存済」への変更後においては、同種のエラーが更に発生しても、更なる格納動作は実行されない。このような制御によれば、同種のエラーに関しては、１回のエラーに関する通信パケット群のみが記録される。

この「ステータス」欄の値は、「同一条件異常通信」（次述）に関する通信パケット群が既に取得され格納（ファイル保存）されているか否かを示す格納実績情報（あるいは保存実績情報）である、とも表現される。値「保存済」は、当該通信パケット群が既に取得され且つ格納（ファイル保存）されていること（且つ、当該データレコードの通信条件が比較処理（ステップＳ１３）に関して有効でないこと）を表す。また、値「有効」は、当該通信パケット群が未だファイル保存されていないこと（且つ、当該データレコードの通信条件が比較処理（ステップＳ１３）に関して有効であること）を表す。なお、「同一条件異常通信」は、少なくとも１つの所定項目（たとえば「通信先装置」）に関する通信条件が過去のデータ通信における通信条件Ｅ２（エラー履歴情報２１０の何れかのデータレコードの通信条件Ｅ２）と同じ内容を有するデータ通信であって、当該過去のデータ通信と現在のデータ通信との間にエラー（異常）を伴って実行されたデータ通信（当該過去のデータとは別の過去のデータ通信）である。

たとえば、図５において、最上段のデータレコード（番号＝１）には、登録日時「２０１７年８月３０日１０時０５分」、送信先情報（ＩＰアドレス）「192.168.10.123」、プロトコル「ＳＭＢ」、エラー種別「接続エラー」、ステータス「保存済」、ファイル名「2017*****1.cap」が記録されている。このデータレコード（番号＝１）では、送信先情報「192.168.10.123」等の通信条件を有する過去のデータ通信において、「接続エラー」が発生したことが示されている。また、当該データレコードに対応する同一条件異常通信に関する通信パケット群がデータファイル（ファイル名「2017*****1.cap」のデータファイル）に既に格納されていること（ステータス「保存済」）等も示されている。

また、次のデータレコード（上から２段目のデータレコード）には、登録日時「２０１７年８月３０日１０時２２分」、送信先情報（ＩＰアドレス）「192.168.10.150」、プロトコル「ＦＴＰ」、エラー種別「その他の通信エラー」、ステータス「有効」が記録されており、ファイル名は未だ記録されていない。このデータレコード（番号＝２）には、送信先情報「192.168.10.150」等の通信条件を有する過去のデータ通信において、「その他の通信エラー」が発生したことが示されている。また、当該データレコードに対応する同一条件異常通信に関する通信パケット群は未だ格納されていないこと（ステータス「有効」）等も示されている。

なお、他のデータレコードに関しても各種の情報が記録されている。

＜１−３．動作＞
上述のように、ＭＦＰ１０は、他の装置（５０等）とのデータ通信に関する通信パケット群を取得して格納（保存）する処理等を実行する。

図３および図４は、第１実施形態に係るＭＦＰ１０の動作を示すフローチャートである。以下では、これらの図等を参照しつつ、ＭＦＰ１０の動作について説明する。ここでは、スキャン画像のネットワーク送信（原稿の読取処理によってスキャン画像を生成し、生成した当該スキャン画像を通信ネットワークを介して他の装置へ送信する処理）がデータ通信として行われる場合について例示する。

ステップＳ１１においては、ユーザによる設定処理等が行われる。たとえば、スキャン画像の送信先の設定処理等が実行される。ユーザは、所望の設定内容への更新操作（変更操作）を実行する。これによって、スキャン画像のデータ送信に関する通信条件が更新される。更新後の通信条件Ｅ１には、予め設定されている設定内容（デフォルトによる設定内容）とユーザによる更新操作によって変更された設定内容との双方が含まれ得る。

その後、ステップＳ１２において、スタートボタン４１がユーザによって押下され、スキャン画像のネットワーク送信指示（スキャン画像の生成開始指示（あるいは原稿の読取開始指示）であるとも表現される）が付与される。当該指示は、スキャンジョブ（画像生成処理および画像送信処理を含む）の開始指示、などとも表現される。

当該ネットワーク送信指示の付与に応答して（スキャン画像のネットワーク送信に先立って）、ＭＦＰ１０は通信条件の比較処理等を実行する（ステップＳ１３，Ｓ１４）。

具体的には、ＭＦＰ１０は、まず、当該ＭＦＰ１０の現在の通信条件Ｅ１と、エラー履歴情報２１０に含まれる過去の各エラーの発生時の（ＭＦＰ１０の）通信条件Ｅ２との両者を比較する（ステップＳ１３）。詳細には、少なくとも１つの所定項目（同一性判定用の項目として予め定められた少なくとも１つの項目）に関する両通信条件Ｅ１，Ｅ２の同一性が判定される。ここでは、当該少なくとも１つの所定項目として、「通信先情報」が採用される（予め指定されている）ものとし、ステップＳ１１等で設定された送信先（現在の通信先設定の送信先（外部装置群のうちの一の外部装置））とエラー履歴情報２１０における複数のデータレコードの送信先のそれぞれとが順次に比較される。

ただし、ステップＳ１３の比較処理では、エラー履歴情報２１０における複数のデータレコードのうち、エラー履歴情報２１０の「ステータス」欄が「有効」であるデータレコードのみが比較処理の対象として選択される。エラー履歴情報２１０の「ステータス」欄が「保存済」であるデータレコードは、比較処理の対象から除外される。

その後、当該比較処理（ステップＳ１３）の処理結果に応じた分岐処理（ステップＳ１４）が実行される。

現在の通信先がエラー履歴情報２１０内の何れのデータレコードの「通信先（情報）」とも異なる場合には、ステップＳ１４からステップＳ１５に進む。ステップＳ１５では、パケット取得を伴わずに通常の通信処理（スキャン画像のネットワーク送信（データ送信））が実行される。

そして、当該ネットワーク送信が終了（正常終了と異常終了（エラー発生を伴う終了）とのいずれをも含む）すると、エラー発生の有無が判定される（ステップＳ１６）。当該ネットワーク送信にてエラー（通信エラー）が発生した場合には、当該エラーに関する情報がエラー履歴情報２１０に追加記録される（ステップＳ１７）。一方、当該ネットワーク送信にてエラー（通信エラー）が発生していない場合には、エラー履歴情報２１０は変更されない。なお、いずれの場合も、その後、再びステップＳ１１に戻る。

一方、現在の通信先がエラー履歴情報２１０内の何れかのデータレコードの「通信先（情報）」に一致する場合（換言すれば、両通信条件Ｅ１，Ｅ２が同一である旨が判定される場合）、ステップＳ１４からステップＳ３０に進む。

ステップＳ３０（図４も参照）では、パケット取得を伴う通信処理（スキャン画像のネットワーク送信）が実行される（次述）。

具体的には、先ず、ステップＳ３１（図４）において、ＭＦＰ１０と外部装置群（ＭＦＰ１０の外部の一または複数の装置）との間で授受される通信パケット群の取得が開始されると同時に、スキャン画像に関する通信処理（スキャン画像のネットワーク送信）が開始される（ステップＳ３２）。このように、データ送信（スキャン画像のデータ送信）の開始前（より詳細には、スキャン画像の生成開始指示の直後（スタートボタン４１の押下直後））にパケット群の取得が開始される。

その後、当該通信処理（スキャン画像のデータ送信）が終了する（ステップＳ３３）と、ＭＦＰ１０は通信パケット群の取得処理を終了する（ステップＳ３４）。ステップＳ３１からステップＳ３４までの期間にて取得される通信パケット群には、当該スキャン画像のデータ送信に関する複数の通信パケットが含まれる。

さらに、ステップＳ３５において、エラー発生の有無が判定される。

当該ネットワーク送信（ステップＳ３２〜Ｓ３３）にてエラー（通信エラー）が発生していないと判定される場合には、処理はステップＳ３６に進む。ステップＳ３６では、ＭＦＰ１０は、ステップＳ３１の開始時点から取得されてきた通信パケット群を格納部５には記録せずに廃棄（削除）する。

一方、当該ネットワーク送信にてエラー（通信エラー）が発生したと判定される場合には、ステップＳ３５からステップＳ３７に進む。ステップＳ３７では、現在のネットワーク通信（データ通信）で発生したエラーと、ステップＳ１３で抽出された過去のデータ通信（同じ通信条件を有する過去の一のデータ通信）で発生していたエラーとの両エラーの種別が互いに同一であるか否かが判定される。

当該両エラーの種別が互いに異なる場合、現在のエラーの種別と同じ種別のエラーは未だ発生していない（換言すれば、当該種別のエラーは初めて発生したもの）と判定され、ステップＳ４１に進む。そして、初めて発生した種別のエラーのエラー情報が新たなデータレコードとしてエラー履歴情報２１０に記録される（ステップＳ４１）。この際、当該新たなデータレコードの「ステータス」欄には、たとえば「有効」が記録される。また、ステップＳ４１においては、当該ネットワーク送信（ステップＳ３１〜Ｓ３４）にて取得された通信パケット群は、格納部５には記録されず、廃棄される。通信パケット群の取得処理は、今回のデータ通信に関しては実行されず、少なくとも一部の所定項目に関する通信条件が同一である次回以降のデータ通信において同種のエラーが発生したときに実行される。

これに対して、当該両エラーが互いに同一の種別を有する場合、ステップＳ３７からステップＳ３８に進む。ステップＳ３８では、上記ネットワーク送信（ステップＳ３１〜Ｓ３４）（現在のデータ通信）にて取得された通信パケット群が所定の格納部（ここでは格納部５の所定フォルダ）に格納（記録）される。各通信パケット群は、ファイル化されて（外部参照可能な状態で）格納される。より詳細には、当該通信パケット群は、データ通信ごとに設けられるデータファイル（通信パケット記録用のデータファイル）に記録され、当該データファイルが格納部５に格納される。

さらに、エラー履歴情報２１０も更新される（ステップＳ３９）。

具体的には、エラー履歴情報２１０の「ファイル名」欄には、現在のデータ通信にて取得された通信パケット群が記録されたデータファイルのファイル名（および格納先装置名）が記録される。換言すれば、エラー履歴情報２１０において、少なくとも１つの所定項目に関して通信条件Ｅ１と同じ通信条件（Ｅ２）を有する過去のデータ通信と関連付けて、当該データファイルのファイル名（および格納先装置名）が記録される。

また、エラー履歴情報２１０の「ステータス」欄には、たとえば「保存済」が記録される。

その後、ステップＳ１１に戻る。

以後、データ送信が行われるごとに上述のような動作（図３および図４参照）が実行される。

なお、ステップＳ１３においては、上述のように、エラー履歴情報２１０における当該複数のデータレコードのうち、その「ステータス」欄が「有効」であるデータレコードのみが比較処理の対象にされる。換言すれば、当該複数のデータレコードのうち、その「ステータス」欄が「保存済」であるデータレコードは、比較処理の対象から除外される。これによれば、同じ通信条件且つ同じエラー発生時の通信パケット群が再び保存されること（端的に言えば、実質的な重複保存）を回避することが可能である。また、比較処理の対象から除外されたデータレコードと同様の通信条件（詳細には、少なくとも１つの所定項目に関して通信条件Ｅ２と同じ通信条件）を現在のデータ通信が有していても、当該現在のデータ通信に関する通信パケット群の取得処理は開始されないので、非常に効率的な通信パケット群の取得処理を実現することが可能である。

＜動作例＞
以上のような動作によれば、（１）過去にエラーが発生した通信（過去のエラー発生通信）とは異なる通信条件でデータ通信が行われる場合には、通信パケット群の取得処理および格納処理は行われない（ステップＳ１５）。詳細には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一ではないと判定される場合、現在のデータ通信に関する通信パケット群の取得処理および格納処理は行われない。したがって、無用なパケット取得処理が行われないので、効率的な通信パケット群の取得処理が実現され得る。また、無用なパケット格納処理も行われないので、パケット格納容量を抑制することも可能である。また、この場合において当該通信でエラーが発生したときには、次回以降の通信に備えて、そのエラーの情報がエラー履歴情報２１０に格納される（ステップＳ１７）。

たとえば、図５の「Ｎｏ．２」のエラー情報が未だエラー履歴情報２１０に登録されていない状態において、通信先を「192.168.10.150」とする通信が行われる場合、ステップＳ１４にて条件非充足と判定され、通信パケット群の取得処理および格納処理は行われない（ステップＳ１５）。また、この場合において通信エラーが発生すると、たとえば図５の「Ｎｏ．２」のエラー情報がエラー履歴情報２１０に記録される。この際、当該通信エラーに関するデータレコードの「ステータス」欄には、「有効」が記録される。

一方、（２）過去にエラーが発生した通信と同じ通信条件（詳細には、少なくとも１つの所定項目に関して同じ通信条件）で現在の通信が行われ且つ当該現在の通信においてエラーが発生しなかった場合には、（現在のデータ通信に関する通信パケット群の取得処理は行われる（ステップＳ３１）ものの、）通信パケット群の格納処理は行われない（ステップＳ３６）。詳細には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一であると判定され且つ現在のデータ通信においてエラーが発生しなかった場合には、現在のデータ通信に関する通信パケット群の格納処理は行われない（当該通信パケット群は廃棄される）。これによれば、エラーが発生していない通信に関する通信パケット群は格納されないので、パケット格納容量を抑制することが可能である。なお、ステップＳ３６においてはエラー履歴情報２１０への記録（書込処理）も行われない。

たとえば、図５の「Ｎｏ．２」のエラー情報がエラー履歴情報２１０に登録されている状態において、通信先を「192.168.10.150」とするデータ通信が行われる場合、ステップＳ１４にて条件充足と判定され、ステップＳ３０に進む。その後、現在のデータ通信に関する通信パケット群の取得処理が行われる（ステップＳ３１）。ただし、当該データ通信にて通信エラーが発生しなかった場合（ステップＳ３５でＮｏ）には、取得されたパケットは格納部５には格納されずに廃棄される（ステップＳ３６）。

また、（３）過去にエラーが発生した通信（過去のエラー発生通信）と同じ通信条件（詳細には、少なくとも１つの所定項目に関して同じ通信条件）で現在の通信が行われ且つ当該現在の通信において当該過去のエラー発生通信のエラー種別とは異なるエラー種別を有するエラーが（初めて）発生した場合には、次回以降の通信に備えて、そのエラーの情報がエラー履歴情報２１０に記録される（ステップＳ４１）。ただし、（通信パケット群の取得処理は実行される（ステップＳ３１，Ｓ３４）ものの、）当該取得処理にて取得さされた通信パケット群の格納処理は行われず、取得された当該通信パケット群は廃棄される（ステップＳ４１）。換言すれば、過去のエラー発生通信と同じ通信条件（詳細には、少なくとも１つの所定項目に関して同じ通信条件）を有する現在のデータ通信において、（エラー自体は発生したものの）当該過去のエラー発生通信のエラー種別と同種のエラーが発生しなかった場合には、現在のデータ通信にて取得された通信パケット群の格納処理は行われず、当該通信パケット群は廃棄される。ここにおいて、同種のエラーが初めて発生した（１回のみ発生した）場合には、当該エラーは偶発的に発生したものである可能性（暫時に解消する可能性）を有し、当該エラーに対応する通信パケット解析を要しないかもしれない。そのため、同種のエラーが初めて発生したデータ通信（同種のエラーが１回しか発生していないデータ通信）に関する通信パケット群は格納されないことによれば、パケット格納容量の増大を効率的に抑制することが可能である。

たとえば、図５の「Ｎｏ．２」のエラー情報がエラー履歴情報２１０に登録されている状態において、通信先を「192.168.10.150」とする新たなデータ通信（現在のデータ通信）が行われる場合、ステップＳ１４にて条件充足と判定され、ステップＳ３０に進む。そして、当該データ通信にて、当該過去のエラー発生通信のエラー種別「その他の通信エラー」とは異なるエラー種別（たとえば、「認証エラー」）を有するエラーが（初めて）発生した場合には、次回以降の通信に備えて、当該エラーの情報がエラー履歴情報２１０に記録される（ステップＳ４１）。この際、当該エラーに関するデータレコードの「ステータス」欄には、「有効」が記録される。また、取得された通信パケット群の格納処理は行われず、当該通信パケット群は廃棄される。

これに対して、（４）過去にエラーが発生した通信（過去のエラー発生通信）と同じ通信条件で現在の通信が行われ且つ当該現在の通信において当該過去のエラー発生通信と同種のエラーが発生した場合には、通信パケット群の取得処理および格納処理が行われる（ステップＳ３１〜Ｓ３４，Ｓ３８）。詳細には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一であると判定され且つ現在のデータ通信において同種のエラー（当該過去のエラー発生通信のエラー種別と同じエラー種別を有する通信エラーが）が発生した場合には、現在のデータ通信に関する通信パケット群の取得処理および格納処理が行われる。これによれば、２回目の同種エラーが発生している通信（且つ同一または類似の通信条件を有する通信）に関する通信パケット群を確実に取得して所定の格納部に格納することが可能である。また、この際、エラー履歴情報２１０において、通信条件Ｅ２を有する過去のエラー発生通信のデータレコード（当該通信エラーに対応するデータレコード）が更新される（ステップＳ３９）。

たとえば、図５の「Ｎｏ．２」のエラー情報がエラー履歴情報２１０に登録されている状態において、通信先を「192.168.10.150」とするデータ通信が行われる場合、ステップＳ１４にて条件充足と判定され、ステップＳ３０に進む。そして、現在のデータ通信にて通信エラーが発生し且つ当該通信エラーが「その他の通信エラー」である場合（「Ｎｏ．２」のエラー情報と同じ種別の通信エラーが発生したと判定される場合）、ステップＳ３１〜Ｓ３４で取得された通信パケット群が格納部５に格納される（ステップＳ３８）。詳細には、当該データ通信時の通信パケット群を含むファイル（データファイル）が作成されて格納部５に格納される。また、当該通信エラーの情報がエラー履歴情報２１０に記録される（ステップＳ３９）。特に、当該通信エラーに対応するデータレコードの「ファイル名」欄には、当該データ通信時の通信パケット群を含む当該データファイルのファイル名等が記録される。また、当該通信エラーに対応するデータレコードの「ステータス」欄には「保存済」が記録される。この「ステータス」欄の情報を利用することによれば、上述のように、実質的な重複保存が排除され得る。

＜１−４．第１実施形態の効果＞
上述の動作においては、現在のデータ通信（新たなデータ通信）時における通信条件Ｅ１と、エラー履歴情報２１０に含まれる過去の一のエラー発生時の通信条件Ｅ２との両者が比較される（ステップＳ１３）。そして、当該両者Ｅ１，Ｅ２の少なくとも１つの所定項目に関する内容が互いに同一であることを条件として、現在のデータ通信に関する通信パケット群（より詳細には、現在のデータ通信を含む通信に関する通信パケット群）の取得処理が開始される（ステップＳ３１）。換言すれば、複数のデータ送信の全てに関して通信パケット群の取得処理が実行されるのではなく、一部のデータ送信のみに関して通信パケット群の取得処理が実行される。

ここにおいて、少なくとも１つの所定項目に関する通信条件が互いに同一であると判定される場合（端的に言えば、過去のエラー発生時と同様の通信条件がなされている場合）には、過去のエラーと同じ原因のエラー（特に再現性を有するエラー）が発生する可能性が一定程度以上存在する。

したがって、複数のデータ通信のうち、少なくとも１つの所定項目に関する通信条件が通信条件Ｅ２と同一であると判定される一部のデータ送信のみに関して通信パケット群の取得処理が実行されること（ステップＳ１３，Ｓ１４，Ｓ３１）によれば、異常発生通信（特に、過去と同じ原因のエラーが発生したデータ通信）に関する通信パケット群を効率的に取得することが可能である。より具体的には、全てのデータ通信に関して常に（一律に）通信パケット群の取得動作が実行される場合に比べて、効率的に通信パケット群を取得することが可能である。換言すれば、複数のデータ通信のうち、特定の通信条件（詳細には、少なくとも１つの所定項目の値（内容）が一致する通信条件）を有するデータ通信が実行される場合にのみ通信パケットの取得処理が実行されるので、効率的な通信パケット群の取得処理が実現される。ひいては、ＭＦＰ１０の負荷を抑制することが可能である。

特に、ステップＳ１３においては、（過去の）「同一条件異常通信」に関する（過去の）通信パケット群が既に（取得され）格納されているか否かが、エラー履歴情報２１０に含まれる格納実績情報（「保存済」等）に基づいて判定される（図５も参照）。そして、「同一条件異常通信」（少なくとも１つの所定項目に関して第２の通信条件Ｅ２と同じ通信条件を有し且つエラーが発生した別の過去のデータ通信）に関する通信パケット群が未だ格納されていないこと（当該通信パケット群を含むデータファイルが未だ保存されていないこと）をも条件として（ステップＳ１３，Ｓ１４）、新たなデータ通信に関する通信パケット群の取得が開始される（ステップＳ３１）。したがって、特定の通信条件（詳細には少なくとも１つの所定項目の値が一致する通信条件）を有するデータ通信（詳細には異常データ通信）が複数回行われる場合であっても、そのうちの１回のデータ通信に関する通信パケット群のみが取得されるので、非常に効率的な通信パケット群の取得処理が実現される。

さらに、ステップＳ１４，Ｓ３１の後、過去の一のエラーのエラー種別と同じ種別のエラーが現在のデータ通信にて発生したことを条件として（ステップＳ３５，Ｓ３７）、現在のデータ通信にて取得された通信パケット群が所定の格納部に格納される（ステップＳ３８）。したがって、現在のデータ通信の通信パケット群をエラーの発生の有無にかかわらずに（あるいはエラー種別にかかわらずに）全て格納する技術に比べて、通信パケットの格納容量を抑制することが可能である。

＜１−５．ステップＳ１４における判定条件＞
上記ステップＳ１４においては、現データ通信の通信条件Ｅ１と過去のデータ通信の通信条件Ｅ２との両通信条件のうちの、少なくとも１つの所定項目に関する内容が互いに同一であるか否かが判定されている。

当該少なくとも１つの所定項目としては、上述のように、たとえば「送信先情報（送信先装置のＩＰアドレス等）」が例示される。すなわち、項目「送信先情報（送信先装置のＩＰアドレス等）」の内容の同一性に基づき、両通信条件Ｅ１，Ｅ２の同一性が判定されればよい。しかしながら、本発明はこれに限定されない。

たとえば、項目「プロトコル」の内容（設定内容）の同一性に基づき、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。

あるいは、これら２つの項目「送信先情報」および「プロトコル」の双方の内容の同一性に基づき、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。具体的には、通信条件Ｅ１における項目「送信先情報」の内容と通信条件Ｅ２における項目「送信先情報」の内容とが同一であり且つ通信条件Ｅ１における項目「プロトコル」の内容と通信条件Ｅ２における項目「プロトコル」の内容とが同一である場合に、両通信条件Ｅ１，Ｅ２が同一であると判定されてもよい。

また、図５に示される項目以外の項目の内容に基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。

たとえば、項目「ポート番号」（ソフトウエアにおけるポート番号）の内容に基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。これによれば、「ポート番号」ごとに通信パケット群（エラー発生時の通信パケット群）が保存され得る。したがって、（ポート番号の誤設定等に起因して）同じポート番号の設定で繰り返しエラーが発生する場合等において、当該ポート番号が設定されている通信データ（エラー発生時の通信パケット群）を効率的に取得（保存）することが可能である。

あるいは、プロトコルの設定内容と当該プロトコルの認証で利用される「ユーザ名」および「パスワード」の各項目の設定内容とに基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。「ユーザ名」の設定内容の同一性が考慮されることによれば、「ユーザ名」ごとに通信パケット群（エラー発生時の通信パケット群）が取得され得る。したがって、（ユーザ名の誤入力等に起因して）同じユーザ名が設定された状態で繰り返しエラーが発生する場合等において、当該ユーザ名が設定されている通信データ（エラー発生時の通信パケット群）を効率的に取得（保存）することが可能である。「パスワード」に関しても同様である。

あるいは、プロトコルの設定内容と「当該プロトコルで利用される認証方式（プロトコルごとの認証方式）」の設定内容とに基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。

より具体的には、ＳＭＴＰプロトコルの認証方式が「ダイジェスト（ＭＤ５）認証」と「ベーシック認証」（「プレイン」とも称する）とのいずれであるかに関する設定内容にも基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。なお、「ダイジェスト（ＭＤ５）認証」では、パスワード等が各認証方式で秘匿化（ハッシュ化等）されて送受信されるのに対して、「ベーシック認証」（「プレイン」）では、パスワード等は秘匿化されずに送受信される。

また、ＷＥＢＤＡＶプロトコルの認証方式が「ＮＴＬＭ（Windows NT LAN Manager authentication ）認証」と「ダイジェスト（ＭＤ５）認証」と「ベーシック認証」（「プレイン」とも称する）とのいずれであるかに関する設定内容にも基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。

さらに、各認証方式のバージョン情報にも基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。たとえば、ＳＭＢプロトコルの認証方式「ＮＴＬＭ認証」のバージョン情報にも基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。

「各プロトコルで利用される認証方式（プロトコルごとの認証方式）」の設定内容にも基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されることによれば、認証方式ごとに通信パケット群（エラー発生時の通信パケット群）が取得され得る。したがって、（認証方式の誤設定等に起因して）同じ認証方式が設定された状態で繰り返しエラーが発生する場合等において、当該認証方式が設定されている通信データ（エラー発生時の通信パケット群）を効率的に取得（保存）することが可能である。

このように、或る上位階層項目（通信プロトコル）と当該上位階層項目よりも下位の下位階層項目（認証方式、ユーザ名、パスワード等）との全項目に関する同一性が判定されてもよい。換言すれば、階層化された複数の項目に関する同一性が判定されてもよい。

あるいは、通信先（通信相手）との間で送信（あるいは受信）される画像データのファイルフォーマット（「ＰＤＦ（Portable Document Format）形式」、「ＪＰＥＧ（Joint Photographic Experts Group）形式」等）の内容（設定内容）に基づいて、両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。たとえば、通信先装置（たとえばメールサーバ）において特定のファイル形式を受け付けない設定がなされている場合、ファイル形式に起因して通信エラーが発生し得る。このような状況において、画像データのファイルフォーマットの同一性が考慮されることによれば、ファイルフォーマットごとに通信パケット群（エラー発生時の通信パケット群）が取得され得る。したがって、特定のファイルフォーマットの画像に関する通信で繰り返しエラーが発生する場合等において、当該特定のファイルフォーマットの画像が送信（あるいは受信）される通信データ（エラー発生時の通信パケット群）を効率的に取得（保存）することが可能である。

また、上位階層項目（「送信先情報」（通信先装置））と当該上位階層項目の下位階層項目（ファイル形式）との双方に関する同一性が判定されてもよい。

また、上述の各種項目の全部（あるいは一部）を含む複数の所定項目（予め定められた複数の項目）の内容（項目値）が同一であることを条件に、両通信条件Ｅ１，Ｅ２が同一であると判定されてもよい。

＜２．第２実施形態＞
第２実施形態は、第１実施形態の変形例である。以下では、第１実施形態との相違点を中心に説明する。

上記第１実施形態では、データ送信処理（詳細にはスキャン画像（画像データ）の送信処理）に本発明を適用する態様について説明した。

この第２実施形態では、データ受信処理（詳細にはプリントデータ（プリントジョブデータ）の受信処理）に本発明を適用する態様について説明する。

図６および図７は、第２実施形態に係るＭＦＰ１０の動作を示すフローチャートである。図３および図４と比較すると判るように、第２実施形態の動作は、次の点において第１実施形態の動作と相違する。具体的には、第１実施形態では、データ通信の開始（ステップＳ１５，Ｓ３２）前にパケット取得の開始の是非が判定される（ステップＳ１４）。これに対して、第２実施形態では、データ通信の開始（ステップＳ５２）後にパケット取得の開始の是非が判定される（ステップＳ５４）。

第２実施形態においては、まずステップＳ５１の待機ループ（受信データ待機ループ）にて他の装置からの最初の通信パケットが受信された時点から、通信処理（データ受信処理）が開始される（ステップＳ５２）。ステップＳ５３〜Ｓ５７では、ステップＳ１３〜Ｓ１７とそれぞれ同様の処理が実行される。また、ステップＳ３０（Ｓ３０ｂとも称する）（図７）においては、ステップＳ３２（「通信開始」）が存在しない点で、図４のステップＳ３０（Ｓ３０ａとも称する）と相違する。

第２実施形態では、ステップＳ５４（図６）で条件充足が判定されるとステップＳ３１（図７）でパケット取得が開始されるものの、ステップＳ５４，Ｓ３１よりも前にデータ受信処理（ステップＳ５２）が開始されている。そのため、パケット取得処理において、パケット取得開始時点（ステップＳ３１）よりも前の微小期間に受信された幾つかの通信パケット（最初の幾つかの通信パケット）が欠落する。しかしながら、当該最初の幾つかの通信パケット以後の通信パケット（特に、エラー発生時点前後の通信パケット群等）を（ステップＳ３１以後にて）受信することが可能である。換言すれば、実際にエラーが発生する時点までには通信パケット群の取得処理が開始される可能性が高い。このようにして受信される通信パケット群を上記第１実施形態と同様にして取得（保存）することによって、パケット解析処理用の通信パケット群を取得（保存）することが可能である。

図８は、第２実施形態に係るエラー履歴情報２１０（２１２）の一例を示す図である。図５のエラー履歴情報２１０（２１１とも称する）と比較すると判るように、エラー履歴情報２１２の「プロトコル」欄には、プリントデータの送受信に固有のプロトコル（ＬＰＤ、ＩＰＰ等）も含まれ得る。

以下では、ステップＳ５４での判定条件として、「プロトコル」（あるいはポート番号）に関する同一性が判定される態様について主に説明する。換言すれば、少なくとも所定項目として「（通信）プロトコル」が採用される（予め指定されている）態様について主に説明する。

具体的には、（１）過去にエラーが発生した通信とは異なる通信条件で通信が行われる場合（ステップＳ５４で条件非充足と判定される場合）には、通信パケット群の取得処理および格納処理は行われない（ステップＳ５５）。詳細には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一ではないと判定される場合、現在のデータ通信に関する通信パケット群の取得処理および格納処理は行われない。したがって、無用なパケット取得処理が行われないので、効率的な通信パケット群の取得処理が実現され得る。また、無用なパケット格納処理が行われないので、パケット格納容量を抑制することも可能である。また、この場合において当該通信でエラーが発生したときには次回以降の通信に備えて、そのエラーの情報がエラー履歴情報２１２に格納される（ステップＳ５７）。

たとえば、図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に未だ登録されていない状態において、４４５番ポートにてデータ受信が開始（ステップＳ５２）された場合、ＳＭＢプロトコルによるデータ受信である旨が判定される。ここでは、各プロトコルによるデータは予め定められたポートで受信される（各プロトコルの待ち受けポートが固定されている）ものとする。具体的には、ＳＭＢプロトコルによるデータは「４４５番」ポートで受信開始され、ＦＴＰプロトコルによるデータは「２１番」ポートで受信開始されるものとする。

図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に未だ登録されていない状態にてＳＭＢプロトコルによるデータ受信が開始された旨が判定される場合には、ステップＳ５４にて条件非充足と判定され、通信パケット群の取得処理および格納処理は行われない（ステップＳ５５）。また、この場合において通信エラーが発生すると、たとえば図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に記録される（ステップＳ５６，Ｓ５７）。この際、当該通信エラーに関するデータレコードの「ステータス」欄には、「有効」が記録される。

一方、（２）過去にエラーが発生した通信（過去のエラー発生通信）と同じ通信条件（詳細には、少なくとも１つの所定項目に関して同じ通信条件）で現在の通信が行われ且つ当該現在の通信においてエラーが発生しなかった場合には、通信パケット群の格納処理は行われず（通信パケット群は廃棄される）且つエラー履歴情報２１２への書込処理も行われない（ステップＳ５６）。これによれば、エラーが発生していない通信に関する通信パケット群は格納されないので、パケット格納容量を抑制することが可能である。

たとえば、図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に登録されている状態において、４４５番ポートにてデータ受信が開始（ステップＳ５２）された場合、ＳＭＢプロトコルによるデータ受信である旨が判定されるとともに、ステップＳ５４にて条件充足と判定されステップＳ３０ｂに進む。その後、現在のデータ通信に関する通信パケット群の取得処理は行われる（ステップＳ３１）。ただし、当該データ通信にて通信エラーが発生しなかった場合（ステップＳ３５でＮｏ）には、取得されたパケットは格納部５には格納されずに廃棄される（ステップＳ３６）。

また、（３）過去にエラーが発生した通信（過去のエラー発生通信）と同じ通信条件（詳細には、少なくとも１つの所定項目に関して同じ通信条件）で現在の通信が行われ且つ当該現在の通信において当該過去のエラー発生通信のエラー種別とは異なるエラー種別を有するエラーが発生した場合には、次回以降の通信に備えて、そのエラーの情報がエラー履歴情報２１２に記録される（ステップＳ４１）。ただし、（通信パケット群の取得処理は実行される（ステップＳ３１，Ｓ３４）ものの、）当該取得処理にて取得された通信パケット群の格納処理は行われず、当該通信パケット群は廃棄される（ステップＳ４１）。ここにおいて、同種のエラーが初めて発生した（１回のみ発生した）場合には、当該エラーは偶発的に発生したものである可能性（暫時に解消する可能性）を有し、当該エラーに対応する通信パケット解析を要しないかもしれない。そのため、同種のエラーが初めて発生したデータ通信（同種のエラーが１回しか発生していないデータ通信）に関する通信パケット群が格納されないことによれば、パケット格納容量の増大を効率的に抑制することが可能である。

たとえば、図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に登録されている状態において、４４５番ポートにてデータ受信が開始（ステップＳ５２）された場合、ＳＭＢプロトコルによるデータ受信である旨が判定される。この場合、ステップＳ５４にて条件充足と判定され、ステップＳ３０ｂに進む。そして、当該過去のエラー発生通信のエラー種別「接続エラー」とは異なるエラー種別（たとえば、「認証エラー」）を有するエラーが（初めて）発生した場合には、次回以降の通信に備えて、当該エラーの情報がエラー履歴情報２１０に記録される（ステップＳ４１）。この際、当該通信エラーに関するデータレコードの「ステータス」欄には、「有効」が記録される。また、取得された通信パケット群の格納処理は行われず、当該通信パケット群は廃棄される。

これに対して、（４）過去にエラーが発生した通信（過去のエラー発生通信）と同じ通信条件で現在の通信が行われ且つ当該現在の通信において当該過去のエラー発生通信と同種のエラーが発生した場合には、通信パケット群の取得処理および格納処理が行われる（ステップＳ３１，Ｓ３３，Ｓ３４，Ｓ３８）。詳細には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一であると判定され且つ現在のデータ通信において同種のエラー（当該過去のエラー発生通信のエラー種別と同じエラー種別を有するエラーが）が発生した場合には、現在のデータ通信に関する通信パケット群の取得処理および格納処理が行われる。これによれば、２回以上のエラーが発生している通信（且つ同一または類似の通信条件を有する通信）に関する通信パケット群を確実に取得して所定の格納部に格納することが可能である。

たとえば、図８の「Ｎｏ．１」のエラー情報がエラー履歴情報２１２に登録されている状態において、４４５番ポートにてデータ受信が開始（ステップＳ５２）された場合、ＳＭＢプロトコルによるデータ受信である旨が判定される。この場合、ステップＳ５４にて条件充足と判定され、ステップＳ３０ｂに進む。そして、当該データ通信にて通信エラーが発生し且つ当該通信エラーが「接続エラー」である場合（「Ｎｏ．１」のエラー情報と同じ種別の通信エラーが発生したと判定される場合）、パケット取得開始時点（ステップＳ３１）からパケット取得終了時点（Ｓ３４）までの期間に取得された通信パケット群が格納部５に格納される（ステップＳ３８）。詳細には、当該データ通信時の通信パケット群を含むファイル（データファイル）が作成されて格納部５に格納される。また、当該通信エラーの情報がエラー履歴情報２１２に記録される（ステップＳ３９）。特に、当該通信エラーに関するデータレコードの「ファイル名」欄には、当該データ通信時の通信パケット群を含む当該データファイルのファイル名等が記録される。また、当該通信エラーに関するデータレコードの「ステータス」欄には「保存済」が記録される。この「ステータス」欄の情報を利用することによれば、上述のように、実質的な重複保存が排除され得る。

なお、ステップＳ５４では、ステップＳ１４と同様、各種の所定項目（通信先情報、認証方式等）に関する同一性に基づいて両通信条件Ｅ１，Ｅ２の同一性が判定されてもよい。また、ステップＳ５４の判定処理（両通信条件Ｅ１，Ｅ２の相互間における少なくとも１つの所定項目に関する内容の同一性を判定する処理）は、ステップＳ５４で同一性の判定対象となる「少なくとも１つの所定項目に関する通信条件（内容）」が確定した時点の後（好ましくは直後）に、実行されればよい。たとえば、エラー履歴情報２１０内の項目「各プロトコルで利用される認証方式（プロトコルごとの認証方式）」（不図示）の内容にも基づいて両通信条件Ｅ１，Ｅ２の同一性が判定される場合には、データ受信開始後において、各プロトコルでの通信が開始され両装置間での認証方式に関する情報の授受が行われ且つ当該認証方式の取り決めが確定（採用される認証方式（取り決め内容）が確定）した時点で、ステップＳ５４の判定処理が実行されればよい。

以上のような動作が行われるようにしてもよい。これによれば、第１実施形態と同様の効果を得ることが可能である。

＜３．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

＜保存回数＞
たとえば、上記各実施形態等においては、（過去の）同一条件異常通信に関する別の通信パケット群が未だ格納されていないことをも条件として、現在のデータ通信に関する通信パケット群の取得が開始されている（ステップＳ１３（Ｓ５３），Ｓ１４（Ｓ５４），Ｓ３１）が、これに限定されない。たとえば、少なくとも１つの同一条件異常通信に関する別の通信パケット群の格納回数（保存回数）が所定回数未満であることをも条件（ステップＳ１３，Ｓ１４等）として、新たなデータ通信に関する通信パケット群の取得が開始（ステップＳ３１）されてもよい。

詳細には、たとえば、エラー履歴情報２１０内の「ステータス」欄において、「保存済」に代えて「（保存回数）Ｎ」が記録されてもよい。換言すれば、エラー履歴情報２１０は、同一条件異常通信に関する（別の）通信パケット群が取得され且つ格納（保存）された回数を示す格納実績情報を含むものであってもよい。そして、エラー履歴情報２１０に含まれる当該格納実績情報（保存回数情報）に基づいて、少なくとも１つの同一条件異常通信に関する通信パケット群の格納回数（保存回数）が判定されればよい。より詳細には、ステップＳ１３の比較処理において、エラー履歴情報２１０における複数のデータレコードのうち、エラー履歴情報２１０の「ステータス」欄の値Ｎが所定値ＴＨ１（たとえば５回）未満であるデータレコードのみが比較処理の対象として選択されればよい。なお、エラー履歴情報２１０内の「ステータス」欄の情報は、通信パケット群の取得処理の実行の有無等を制御する情報（実行制御情報）などとも表現される。

このような動作によれば、通信条件Ｅ２と同じ通信条件（少なくとも１つの所定項目に関して同じ通信条件）を有する異常通信での通信パケット群の取得回数が所定回数までに制限されるので、効率的な通信パケット群の取得動作を実現することが可能である。また、このような取得動作が行われた通信パケット群のみが格納対象になり得るので、格納対象の通信パケット群が絞り込まれ、パケット格納容量を抑制することが可能である。

なお、上記各実施形態等では、エラー履歴情報２１０を表す一のデータテーブル内に格納実績情報が含まれているが、これに限定されず、当該一のデータテーブルとは別個に（たとえば別ファイルとして）格納実績情報が格納されていてもよい。

＜複数のＭＦＰでのエラー履歴情報の共有（クライアントサーバシステム）＞
上記各実施形態では、或るＭＦＰ１０にて取得されたエラー履歴情報２１０が当該ＭＦＰ１０によってのみ利用されているが、これに限定されない。

たとえば、サーバ７０と複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）とを備える通信システム１（１Ｂ）（クライアントサーバシステム）（図９参照）において、共通のエラー履歴情報２１０（２１５）がサーバ７０に格納され、当該エラー履歴情報２１５（共通エラー履歴情報とも称する）が当該複数のＭＦＰ１０で共用されるようにしてもよい。すなわち、各ＭＦＰ１０は、当該複数のＭＦＰ１０に共通のエラー履歴情報２１０（２１５）を利用してもよい。換言すれば、各ＭＦＰ１０は、サーバ７０に設けられた共通のエラー履歴情報２１５にアクセスして各ＭＦＰ１０用のエラー履歴情報を取得するようにしてもよい。なお、図９においては、コンピュータ５０等の図示を省略している。

具体的には、いずれかのＭＦＰ１０（たとえば１０ａ）にてエラーが検出された場合、当該エラーが検出されたＭＦＰ１０（１０ａ）が、当該サーバ７０に当該エラーの情報（エラー情報）を送信し、サーバ７０内のエラー履歴情報２１５に当該エラー情報を記録するようにしてもよい。

その後、各ＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）は、サーバ７０内のエラー履歴情報２１５を参照して、上記各実施形態と同様の動作を実行すればよい。

そして、或る通信条件でのエラー通信の通信パケット群が複数のＭＦＰ１０のうちのいずれかのＭＦＰ１０（たとえば１０ｂ）にて取得されると、当該ＭＦＰ１０（１０ｂ）が、当該通信パケット群を含むデータファイルをサーバ７０に送信し、当該データファイル（換言すれば、当該通信パケット群）がサーバ７０内の格納部に格納されればよい。ただし、これに限定されず、当該通信パケット群は、サーバ７０以外の装置の格納部（たとえば、ＭＦＰ１０ｂ内の所定の格納部）に格納されてもよい。

このような動作によれば、複数のＭＦＰ１０のうちの一のＭＦＰ１０（たとえば、１０ａ）でのデータ通信にてエラーが発生した後、当該データ通信と同様の通信条件を有するデータ通信に関する通信パケット群が、他のＭＦＰ１０（１０ｂ，１０ｃ，...）を含む複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）で協働して取得される。したがって、エラー通信に関する通信パケット群が、複数のＭＦＰ１０の協働によって効率的に取得され得る。換言すれば、複数のＭＦＰ１０で同様に生じ得るエラーの原因を、複数のＭＦＰ１０で協働して究明することが可能である。

また、或る通信条件でのエラー通信の通信パケット群がいずれかのＭＦＰ１０にて取得され、当該通信パケット群が所定の格納部（サーバ７０内の格納部等）にて格納された後には、エラー履歴情報２１０（２１５）内の対応データレコードの「ステータス」欄（図５参照）が「保存済」に変更され、他のＭＦＰ１０による通信パケット群の更なる取得処理が実行されないようにしてもよい。換言すれば、同じ通信条件を有する異常データ通信の通信パケット群は、複数のＭＦＰ１０のうちの任意の単一のＭＦＰ１０のみで取得されればよい。これによれば、当該単一のＭＦＰ１０以外の他のＭＰＦでは更なる取得処理が実行されないので、効率的な通信パケット群の取得処理および格納処理が実現され得る。

なお、これに限定されず、エラー履歴情報２１０内の対応データレコードの「ステータス」欄に「保存回数Ｎ」が記録されるようにしてもよい。そして、複数のＭＦＰ１０の全体で所定値ＴＨ２回（たとえば５回）の通信パケット群の格納処理（保存処理）が実行されると、以後においては、何れのＭＦＰ１０による通信パケット群の更なる取得処理も実行されないようにしてもよい。これによれば、同じ通信条件を有する異常データ通信の通信パケット群の格納処理が複数のＭＦＰ１０の全体でＴＨ２回実行されると、その後は、何れのＭＰＦにおいても更なる取得処理が実行されないので、効率的な通信パケット群の取得処理および格納処理が実現され得る。たとえば、仮に１０台のＭＦＰ１０が個別に（それぞれ）５回のパケット群格納処理を行う場合には合計５０回（＝５×１０）のパケット格納処理が行われるのに対して、このような態様によれば１０台のＭＦＰ１０の全体で合計５回のパケット格納処理が行われるだけで済む。

＜複数のＭＦＰでのエラー履歴情報の共有（サーバレスシステム）＞
あるいは、サーバを有しない通信システム１（１Ｃ）、具体的には、複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）を備えるサーバレスシステム（図１０参照）において、複数のＭＦＰ１０のそれぞれに格納されるエラー履歴情報２１０（２１０ａ，２１０ｂ，２１０ｃ，...）が互いに同期されるようにしてもよい。換言すれば、このような同期動作によって実質的に同一化されたエラー履歴情報２１０（共通エラー履歴情報２１０）が利用されてもよい。なお、図１０においては、コンピュータ５０等の図示を省略している。

具体的には、まず、各ＭＦＰ１０は、マルチキャスト等を利用して同一ＬＡＮ内に存在する複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）を把握し、当該複数のＭＦＰ１０を同一グループの装置として認定する。

その後、いずれかのＭＦＰ１０（たとえば１０ａ）にてエラーが検出された場合、当該エラーが検出されたＭＦＰ１０（１０ａ）は、自装置（１０ａ）のエラー履歴情報２１０（２１０ａ）に当該エラー情報を記録するとともに、他のＭＦＰ１０（１０ｂ，１０ｃ，...）に対して当該エラー情報を送信し当該他のＭＦＰ１０内の各エラー履歴情報２１０（２１０ｂ，２１０ｃ，...）に当該エラー情報を格納させる。換言すれば、各ＭＦＰ１０は、自装置内のエラー履歴情報２１０を更新した際に、他の各装置内のエラー履歴情報をも更新させることによって、複数のＭＦＰ１０に共通するエラー履歴情報（共通エラー履歴情報）を構築する。

そして、各ＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）は、自装置内のエラー履歴情報２１０（２１０ａ，２１０ｂ，２１０ｃ，...）（共通エラー履歴情報でもある）をそれぞれ参照して、上記各実施形態と同様の動作を実行すればよい。

このような動作によれば、図９に示す態様と同様、複数のＭＦＰ１０のうちの一のＭＦＰ１０（たとえば、１０ａ）でのデータ通信にてエラーが発生した後、当該データ通信と同様の通信条件を有するデータ通信に関する通信パケット群が、他のＭＦＰ１０（１０ｂ，１０ｃ，...）を含む複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）で協働して取得される。したがって、エラー通信に関する通信パケット群が、複数のＭＦＰ１０の協働によって効率的に取得され得る。換言すれば、複数のＭＦＰ１０で同様に生じ得るエラーの原因を、複数のＭＦＰ１０で協働して究明することが可能である。

また、或る通信条件でのエラー通信の通信パケット群がいずれかのＭＦＰ１０にて取得され、当該通信パケット群が所定の格納部（いずれかのＭＦＰ１０の格納部５等）にて格納された後には、各エラー履歴情報２１０（２１０ａ，２１０ｂ，２１０ｃ，...）内の対応データレコードの「ステータス」欄（図５参照）が「保存済」に変更され、各ＭＦＰ１０による通信パケット群の更なる取得処理が実行されないようにしてもよい。これによれば、同じ通信条件を有する異常データ通信の通信パケット群は、複数のＭＦＰ１０のうちの単一のＭＦＰ１０のみで取得されれば済む。

なお、これに限定されず、各エラー履歴情報２１０（２１０ａ，２１０ｂ，２１０ｃ，...）内の対応データレコードの「ステータス」欄に「（保存回数）Ｎ」が記録されるようにしてもよい。そして、複数のＭＦＰ１０の全体で値ＴＨ３回（たとえば５回）の通信パケット群の格納処理（保存処理）が実行されると、以後においては、何れのＭＦＰ１０による通信パケット群の更なる取得処理も実行されないようにしてもよい。これによれば、同じ通信条件を有する異常データ通信の通信パケット群の格納処理が複数のＭＦＰ１０の全体でＴＨ３回実行されると、その後は何れのＭＰＦにおいても更なる取得処理が実行されないので、効率的な通信パケット群の取得処理および格納処理が実現され得る。

＜パケット取得許可＞
上記各実施形態において、現在のデータ通信に関する通信パケット群の取得処理および当該通信パケット群の格納処理は、通信パケットの取得許可がＭＦＰ１０に付与されていることをも条件として、開始されるようにしてもよい。通信パケットの取得許可は、管理者あるいはユーザなどによってＭＦＰ１０に対して付与されればよい。たとえば、通信パケットの取得許可を付与するための操作画面（承認画面）が表示された状態で、管理者等が、当該操作画面内の案内に従ってＭＦＰ１０によるパケット取得を許可する操作（許可付与操作）を行うようにすればよい。このような許可付与操作は、たとえば、図３の動作の前に予め実行されていてもよく、あるいは、或る通信条件を有するデータ通信のエラーが最初に発生した時点（ステップＳ１７あるいはステップＳ４１）で実行されてもよい。

＜ソフトウエア動作ログ＞
また、上記各実施形態等において、ステップＳ３９（図４）等にて通信パケット群を格納するにあたって、当該通信パケット群に含まれる各通信パケットの通信タイミングとＭＦＰ１０における所定のアプリケーションソフトウエア（通信アプリケーションソフトウエア等）の進捗段階との関係を記録したデータが格納されるようにしてもよい。

詳細には、当該アプリケーションソフトウエアの各実行段階（第ｉ段階）を示す番号（たとえば、プログラムの行番号に対応する番号（シーケンスコード等））が、当該アプリケーションソフトウエアの進捗に応じて通信パケット記録用のデータファイル内に随時記録されればよい。詳細には、当該各実行段階（第ｉ段階）を示す番号と当該各実行段階（進捗段階とも称する）において授受される通信パケットとが互いに対応付けられて、通信パケット記録用のデータファイル内に記録されればよい。これによれば、各通信パケットがアプリケーションソフトウエアの何れの実行段階（進捗段階）で発生しているかを、通信パケット群の解析者（ＭＦＰ１０のサービスマン等）が容易に理解することが可能である。

＜ジョブ情報ログ＞
また、上記各実施形態等において、ステップＳ３９等にて現在のデータ通信に関する通信パケット群を格納するにあたって、当該現在のデータ通信の実行ジョブの情報が当該通信パケット群に関連付けて格納されるようにしてもよい。たとえば、エラー履歴情報２１０において、少なくとも１つの所定項目に関して現在のデータ通信と同一の通信条件を有するデータ通信のデータレコードに関連付けて、当該現在のデータ通信の実行ジョブの情報（たとえば、ジョブ種別およびジョブＩＤ等）もが記録されていてもよい。あるいは、当該現在のデータ通信の実行ジョブの情報は、エラー履歴情報２１０を示すデータテーブルとは別のデータテーブル等において、当該通信パケット群に関連付けて格納されてもよい。

「ジョブ種別」が記録されることによれば、当該現在のデータ通信で発生したエラーが複数のジョブ種別のうちの何れの種別のジョブ（プリントジョブ、スキャンジョブ等）の実行に関するものであるのかを容易に把握することが可能である。また、「ジョブＩＤ（ジョブ識別子）」が記録されることによれば、当該エラーが複数のジョブのうちの何れのジョブ（ジョブＩＤにより識別される）の実行に関するものであるのかを容易に把握することが可能である。

＜通信パケット取得処理の中止（中断）＞
また、上記各実施形態等においては、通信条件の同一性の確認に応じて現在のデータ通信にて開始された通信パケット群の取得処理（ステップＳ３１）は、当該現在のデータ通信の成否にかかわらず、当該データ通信の終了（ステップＳ３３）まで継続されているが、これに限定されない。

現在のデータ通信において通信パケット群の取得処理が開始された後、過去の一のエラーのエラー種別と同じ種別のエラーの原因が解消されていると判定される場合、当該現在のデータ通信に関する通信パケット群の取得処理が中止（中断）されてもよい。

たとえば、エラー種別「接続エラー」（図５参照）の通信エラーが発生していた過去のデータ通信の通信条件と同じ通信条件であることを条件として現在のデータ通信に関する通信パケット群取得処理が開始（ステップＳ３１）された場合において、当該現在のデータ通信の接続が成功したときには、「接続エラー」の原因が解消していると判定される。たとえば、ＭＦＰ１０にて閉じていたポート（接続ポート）が開いたことによって接続エラー（ポートエラー）が解消することがある。あるいは、接続先装置（接続先サーバ等）の一時的な障害発生によって生じていた接続エラーが、当該接続先装置の障害回復によって解消すること等がある。

このとき、接続成功後においては、通信パケット群の取得処理（および解析処理）は不要であるとみなし、通信パケット群の取得処理は、（当該現在のデータ通信の完了（ステップＳ３３）を待つことなく）直ちに中止されてもよい。また、中止されるまでに取得された通信パケット群は、廃棄されればよい（ステップＳ３６）。

あるいは、エラー種別「認証エラー」（図５参照）の通信エラーが発生していた過去のデータ通信の通信条件と同じ通信条件であることを条件として現在のデータ通信に関する通信パケット群の取得処理が開始（ステップＳ３１）された場合において、当該現在のデータ通信における認証処理が成功したときには、「認証エラー」の原因が解消していると判定される。たとえば、ユーザ認証におけるパスワードの誤入力（ユーザの誤入力）によって発生していた認証エラーが、正しいパスワードが入力されることによって解消されること等がある。

このとき、認証成功後においては、通信パケット群の取得処理は不要であるとみなし、通信パケット群の取得処理は、（当該現在のデータ通信の完了（ステップＳ３３）を待つことなく）直ちに中止されてもよい。また、中止されるまでに取得された通信パケット群は、廃棄されればよい（ステップＳ３６）。

その他の種別の通信エラーについても同様である。

＜エラー原因解消後の例外動作（パケット取得非開始）＞
また、上記各実施形態等においては、或る過去の時点で通信エラーが発生した後においては、当該通信エラーが発生していた過去のデータ通信Ｄ２と同じ通信条件を有するデータ通信にて通信パケット群取得処理が行われる。当該同じ通信条件を有するデータ通信に関する通信パケット群取得処理は、当該同じ通信条件を有するデータ通信で再び通信エラーが発生するまで繰り返し実行される。しかしながら、本発明は、これに限定されない。

現時点において過去のデータ通信Ｄ２で発生した一のエラー原因（詳細には、当該一のエラーのエラー種別と同じ種別のエラーの原因）が既に解消されていると判定される場合には、当該現在のデータ通信（新たなデータ通信）Ｄ１が当該過去のデータ通信Ｄ２と同じ通信条件を有していても、当該新たなデータ通信Ｄ１においては通信パケット群の取得が開始されない（通信パケット群の取得処理は行われない）ようにしてもよい。換言すれば、少なくとも１つの所定項目に関して両通信条件Ｅ１，Ｅ２が互いに同一であると判定された場合であっても、当該一のエラーの原因が既に解消されていると判定されるときには、当該新たなデータ通信Ｄ１においては通信パケット群の取得処理が開始されないようにしてもよい。

たとえば、過去のデータ通信Ｄ２においてエラー種別「接続エラー」（図５参照）の通信エラーが発生した後、当該過去のデータ通信Ｄ２の通信条件と同じ通信条件を有する別の過去のデータ通信Ｄ３が行われている際に、「接続」が成功したときには、「接続エラー」（過去のデータ通信Ｄ２でのエラー種別のエラー）の原因が解消していると判定される。

このとき、「接続」成功後においては、通信パケット群の取得処理は不要であるとみなし、次回以降のデータ通信（詳細には、当該過去のデータ通信Ｄ２の通信条件と同じ通信条件を有する次回以降のデータ通信）（Ｄ１等）における通信パケット群の取得処理は行われないようにしてもよい。具体的には、「接続」が成功した上記データ通信Ｄ３（過去のデータ通信Ｄ２後の別の過去のデータ通信Ｄ３）において、エラー履歴情報２１０内の対応データレコードの「ステータス」欄に値「無効」が（接続成功直後等に）記録されればよい。その後、新たなデータ通信Ｄ１に関して図３等の動作が行われる際に、「ステータス」欄に値「無効」が記録されたデータレコードは、ステップＳ１３（図３）およびＳ５３（図６）にて比較処理の対象から除外されればよい。

同様に、過去のデータ通信Ｄ２においてエラー種別「認証エラー」（図５参照）の通信エラーが発生した後、当該過去のデータ通信Ｄ２の通信条件と同じ通信条件を有する別の過去のデータ通信Ｄ３が行われている際に、「認証」が成功したときには、「認証エラー」の原因が解消していると判定される。

このとき、「認証」成功後においては、通信パケット群の取得処理は不要であるとみなし、次回以降のデータ通信（詳細には、当該過去のデータ通信Ｄ２の通信条件と同じ通信条件を有する次回以降のデータ通信）（Ｅ１等）における通信パケット群の取得処理は行われないようにしてもよい。具体的には、「認証」が成功した上記データ通信Ｄ３（過去のデータ通信Ｄ２後の別の過去のデータ通信Ｄ３）において、エラー履歴情報２１０内の対応データレコードの「ステータス」欄に値「無効」が（認証成功直後等に）記録されればよい。その後、新たなデータ通信Ｄ１に関して図３等の動作が行われる際に、「ステータス」欄に値「無効」が記録されたデータレコードは、ステップＳ１３（図３）およびＳ５３（図６）において比較処理の対象から除外されればよい。

その他の種別の通信エラーについても同様である。

＜エラー解消策取得後の例外動作（パケット取得非開始）＞
また、上記各実施形態において、少なくとも１つの所定項目に関して両通信条件Ｅ１，Ｅ２の内容が互いに同一であると判定された場合であっても、通信条件Ｅ２を有する過去のデータ通信にて発生した一のエラーの解消策が既に得られていると判定されるときには、新たなデータ通信Ｄ１に関する通信パケット群の取得処理が実行されないようにしてもよい。

換言すれば、当該一のエラーの原因が実際には未だ解消されていない場合であっても、当該一のエラーの解消策が既に得られているときには、当該一のエラーが発生した過去のデータ通信Ｄ２と同じ通信条件を有するデータ通信（Ｅ１等）においては、通信パケット群の取得処理が実行されないようにしてもよい。当該一のエラーの解消策が既に得られており、通信パケット群の解析処理を要しない場合には、通信パケット群の取得処理が実行されないので、効率的である。

たとえば、或るバージョン（「バージョン１」）のファームウエア（ＭＦＰ１０にて実行されるファームウエア）の不具合により発生していた特定のエラー（たとえば、特定のプロトコル利用時の特定の接続エラー）の原因が究明され、当該原因への対応策を施した新たなファームウエア（「バージョン２」）が提供されることがある。このような場合には、仮に当該特定のエラーが発生してもファームウエアの更新によれば当該特定のエラーが解消され得る。すなわち、当該特定のエラーの解消策が既に得られていることがある。

このような状況では、当該特定のエラーの原因究明等のために通信パケット群を取得することを要しない。

そこで、特定のエラーが発生した過去のデータ通信と同じ通信条件を有する新たなデータ通信においても、通信パケット群の取得処理が実行されないようにしてもよい。以下では、このような態様について図１１等を参照しながら説明する。

図１１は、２つのサブシステム１００ａ，１００ｂを備える通信システム１（１Ｄ）を示す図である。

各サブシステム１００ａ，１００ｂは、それぞれ、図９のシステム１（１Ｂ）と同様の構成を有している。たとえば、サブシステム１００ａは或る会社に構築され、サブシステム１００ｂは別の会社に構築される。

具体的には、サブシステム１００ａは、サーバ（社内サーバ等）７０ａと複数のＭＦＰ１０（１０ａ，１０ｂ，１０ｃ，...）を備えている。サーバ（社内サーバ等）７０ａには、エラー履歴情報２１０（２１５）、および異常発生通信時に取得された通信パケット群の情報等が格納される。

同様に、サブシステム１００ｂは、サーバ（社内サーバ等）７０ｂと複数のＭＦＰ１０（１０ｐ，１０ｑ，１０ｒ，...）を備えている。サーバ（社内サーバ等）７０ｂには、エラー履歴情報２１０（２１６）、および異常発生通信時に取得された通信パケット群の情報等が格納される。

また、通信システム１Ｄは、メンテナンスサーバ８０（サーバ７０の上位サーバ）をも備えている。メンテナンスサーバ８０は、ネットワーク１０８（１０８ｘ）を介して、各サブシステム１００ａ，１００ｂ内の各サーバ７０（７０ａ，７０ｂ）と通信することが可能である。

メンテナンスサーバ８０には、各サーバ７０に格納されていた情報（エラー履歴情報２１０、および異常発生通信時に取得された通信パケット群の情報等）が各サーバ７０から（定期的に或いは不定期に）送信されてきて格納される。

また、メンテナンスサーバ８０には、各種エラーの情報が集約されている。より詳細には、各種エラーの解消策の有無等が記録されている。たとえば、或るエラーが、当該原因への対応策を施した新たなファームウエア（「バージョン２」）の導入によって解消されることなどが記録されている。

そして、たとえば、サブシステム１００ａのＭＦＰ１０ａにおいて上記各実施形態等と同様の動作が行われ、一のエラーが最初に検出された場合、当該一のエラーの情報がエラー履歴情報２１０に記録される。具体的には、エラー履歴情報２１０（２１５）の「ステータス」欄に「有効」が記録される。

ただし、この変形例では、このとき、当該一のエラーの解消策が既に得られているか否かを、サーバ７０ａがメンテナンスサーバ８０にまず問い合わせる。より具体的には、当該一のエラー発生時の通信条件の情報を含むデータレコード（図５参照）とともに、当該一ののエラーが発生したＭＦＰ１０ａにインストールされているファームウエアのバージョン情報（たとえば「バージョン１」等）、および当該ＭＦＰ１０のモデル情報（型番情報等）もが、サーバ７０からメンテナンスサーバ８０に送信される。

そして、これらの情報によって特定される当該一のエラーの解消策が既に判明しているか否かがメンテナンスサーバ８０によって判定され、その判定結果がサーバ７０ａ（問合せ元装置）に返信される。たとえば、当該一のエラーが特定の種類のエラー（「特定のプロトコル利用時の特定の接続エラー」）であり、且つＭＦＰ１０ａ（エラー発生装置の）には古いバージョンのファームウエア（「バージョン１」）がインストールされており新しいバージョン（改善後の）のファームウエア（「バージョン２」）が未だインストールされていないときには、当該一のエラーの解消策が既に判明している旨が判定される。

サーバ７０ａは、当該判定結果として当該一のエラーの解消策が既に判明している旨をメンテナンスサーバ８０から受信した場合、エラー履歴情報２１５の変更処理を実行する。具体的には、サーバ７０ａは、当該一のエラーのデータレコードの「ステータス」欄を「無効」に変更する。そして、「ステータス」欄に値「無効」が記録されたデータレコードは、ステップＳ１３（図３）およびＳ５３（図６）において比較処理の対象から除外されればよい。このように、サーバ７０ａは、当該サーバ７０ａに格納されたエラー履歴情報２１５における実行制御情報（ステータス欄の情報）を更新し、複数のＭＦＰ１０のそれぞれにおいて当該一のエラーの発生時と同じ通信条件を有する新たなデータ通信に関する通信パケット群の取得処理を実行させないように制御するようにしてもよい。なお、この場合、サーバ７０は、エラー原因を有するＭＦＰ１０（「バージョン２」のファームウエアが未だインストールされていないＭＦＰ）に対して、警告表示を行うべき旨の指令を送信し、当該ＭＦＰ１０に当該警告表示（ファームウエアを「バージョン２」にアップデートすべき旨を含む表示）を行わせることが好ましい。

このような動作によれば、一のエラーの解消策が既に得られているときには、当該一のエラーが発生した過去のデータ通信と同じ通信条件を有する新たなデータ通信においても、通信パケット群の取得処理は実行されない。すなわち、通信パケット群の解析処理を要しない場合には、通信パケット群の取得処理は実行されない。したがって、効率的な通信パケット群の取得処理を実現することが可能である。

なお、ここでは、サブシステム１００ａについて主に説明したが、サブシステム１００ｂについても同様である。

また、ここでは、サーバ７０ａがメンテナンスサーバ８０に問い合わせる態様が例示されているが、これに限定されない。たとえば、各ＭＦＰ１０（１０ａ等）が（サーバ７０を介さずに）メンテナンスサーバ８０に問い合わせてもよい。この場合には、各ＭＦＰ１０が、メンテナンスサーバ８０から受信した問合せ結果に基づき、エラー履歴情報２１０の内容を更新すればよい。

＜データ送信時における通信パケット群の他の取得開始タイミング＞
上記第１実施形態等では、新たなデータ通信としてスキャン画像のデータ送信が行われる場合、ＭＦＰ１０は、スキャン画像の生成開始指示の直後（スタートボタン４１の押下直後）に通信パケット群の取得が直ちに開始されている（ステップＳ３１）が、これに限定されない。たとえば、同様の場合において、ＭＦＰ１０は、スキャン画像の生成開始指示の直後（スタートボタンの押下直後）ではなく、当該生成開始指示に応じて原稿の読取処理が開始（スキャン画像の生成処理が開始）された後且つ当該データ送信の開始直前に、通信パケット群の取得が開始されるようにしてもよい。すなわち、スタートボタン４１が押下されたとしても、スキャン画像に関するデータ送信の開始直前までは、通信パケットが取得されないようにしてもよい。これによれば、スキャン画像の送信処理以外の通信に関する通信パケットの取得を排除あるいは抑制しつつ、当該スキャン画像の送信処理に関する通信パケットを適切に取得することが可能である。なお、通信パケット群の取得は、当該スキャン画像の読取処理途中に開始されてもよく、当該スキャン画像の読取処理完了後に開始されてもよい。

＜パケットフィルタリング処理＞
また、上記各実施形態等においては、通信パケット群の取得処理および格納処理においては、原則として、ＭＦＰ１０とその外部装置群（ＭＦＰ１０の外部の一または複数の装置）との間で授受される複数の通信パケットの全てが取得され格納されている。しかしながら、これに限定されず、たとえば、パケットフィルタリング処理によって当該複数の通信パケットの全てのうちの一部のみが取得され格納されてもよい。より詳細には、当該複数の通信パケットのうち、予め設定された所定の条件（通信条件等）に合致する通信パケットのみが通信パケット群として取得され格納部に５等に格納されてもよい。

特に、当該予め設定された所定の条件は、ステップＳ１３の判定処理で利用される「少なくとも１つの所定項目」に関する通信条件を含むことが好ましい。たとえば、ステップＳ１３での比較処理における比較対象項目（少なくとも１つの所定項目）として「通信先装置」が含まれる場合には、現在のデータ通信においてＭＦＰ１０とその外部の装置群との間で授受される複数の通信パケットの全てのうち、その通信先装置が通信条件Ｅ２での「通信先装置」に合致する通信パケットのみで構成される通信パケット群が取得され格納部５等に格納されてもよい。

＜その他＞
また、上記各実施形態等においては、データ送信時の動作（第１実施形態等）とデータ受信時の動作（第２実施形態等）とを別の態様にて説明しているが、これに限定されず、両動作が１つの通信装置（ＭＦＰ１０等）において実行されるようにしてもよい。この場合、データ送信時には第１実施形態等の動作が実行され、データ受信時には第２実施形態等の動作が実行されればよい。

また、上記第２実施形態等では、新たなデータ通信としてデータ受信が行われる場合、当該データ受信の開始後に比較処理（Ｓ５３）が行われ、通信条件の同一性が確認された後に、当該通信パケット群の取得が開始されているが、これに限定されない。

たとえば、新たなデータ通信としてデータ受信が開始される場合には、少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容が互いに同一であるか否かにかかわらず、当該新たなデータ通信を含む通信に関する通信パケット群の取得が直ちに開始されてもよい。より具体的には、ステップＳ５２（図６）において、データ受信の開始と同時に通信パケット群の取得処理が開始されればよい。これによれば、データ通信開始部分での通信パケットの取りこぼしを抑制することが可能である。なお、新たなデータ通信としてデータ送信が行われる場合には、上記第１実施形態等と同様の動作が行われればよい。

また、通信パケット群の取得処理の開始後において、第１の通信条件Ｅ１における少なくとも１つの所定項目の内容が確定した後に、当該少なくとも１つの所定項目に関する両通信条件Ｅ１，Ｅ２の内容の同一性が判定され、その判定結果に応じた処理が行われればよい。具体的には、当該少なくとも１つの所定項目に関する両通信条件の内容が互いに同一であると判定される場合には、当該通信パケット群の取得が継続されればよい。一方、当該少なくとも１つの所定項目に関する両通信条件の内容が互いに同一ではないと判定される場合には、当該通信パケット群の取得が終了（中止）されればよい。このような動作によっても、効率的な通信パケット群の取得処理を実現することが可能である。

１，１Ｂ，１Ｃ，１Ｄ 通信システム
１０，１０ａ，１０ｂ，１０ｃ，１０ｐ，１０ｑ，１０ｒ ＭＦＰ
５０ パーソナルコンピュータ
７０ サーバ
８０ メンテナンスサーバ（上位サーバ）
２１０ エラー履歴情報

Claims (32)

1. 通信装置であって、
   前記通信装置と外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得する履歴情報取得手段と、
   前記通信装置と一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較する比較手段と、
   少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するパケット取得手段と、
   前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納する格納制御手段と、
   を備えることを特徴とする通信装置。
2. 請求項１に記載の通信装置において、
   前記格納制御手段は、前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生しなかった場合、前記取得処理によって取得された前記通信パケット群を前記所定の格納部に格納せずに廃棄することを特徴とする通信装置。
3. 請求項１に記載の通信装置において、
   前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記第２の通信条件と同じ通信条件を有し且つエラーが発生した別の過去のデータ通信である同一条件異常通信に関する別の通信パケット群が未だ格納されていないことをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする通信装置。
4. 請求項３に記載の通信装置において、
   前記エラー履歴情報は、前記同一条件異常通信に関する前記別の通信パケット群が既に取得され格納されているか否かを示す格納実績情報をも含み、
   前記パケット取得手段は、前記エラー履歴情報に含まれる前記格納実績情報に基づいて、前記同一条件異常通信に関する前記別の通信パケット群が既に格納されているか否かを判定することを特徴とする通信装置。
5. 請求項１に記載の通信装置において、
   前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記第２の通信条件と同じ通信条件を有し且つ前記一のエラー発生時のデータ通信と前記新たなデータ通信との間にエラーを伴って実行された少なくとも１つのデータ通信である少なくとも１つの同一条件異常通信に関する別の通信パケット群の格納回数が所定回数未満であることをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする通信装置。
6. 請求項５に記載の通信装置において、
   前記エラー履歴情報は、前記少なくとも１つの同一条件異常通信に関する前記通信パケット群が取得され格納された回数を示す格納実績情報をも含み、
   前記パケット取得手段は、前記エラー履歴情報に含まれる前記格納実績情報に基づいて、前記少なくとも１つの同一条件異常通信に関する前記別の通信パケット群の前記格納回数を判定することを特徴とする通信装置。
7. 請求項１に記載の通信装置において、
   前記パケット取得手段は、通信パケットの取得許可が前記通信装置に付与されていることをも条件として、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始することを特徴とする通信装置。
8. 請求項１に記載の通信装置において、
   前記格納制御手段は、前記取得処理によって取得された前記通信パケット群を、データ通信ごとに設けられるデータファイルに格納することを特徴とする通信装置。
9. 請求項８に記載の通信装置において、
   前記エラー履歴情報において、前記少なくとも１つの所定項目に関して前記第１の通信条件と同じ通信条件を有する前記過去のデータ通信に関連付けて、前記データファイルのファイル名と前記データファイルの格納先装置名とを記録する履歴情報更新手段、
   をさらに備えることを特徴とする通信装置。
10. 請求項１に記載の通信装置において、
    前記格納制御手段は、前記取得処理により取得された前記通信パケット群を前記所定の格納部に格納するにあたって、当該通信パケット群に含まれる各通信パケットの通信タイミングと前記通信装置における所定のアプリケーションソフトウエアの進捗段階との関係を記録したデータをも格納することを特徴とする通信装置。
11. 請求項１に記載の通信装置において、
    前記格納制御手段は、前記取得処理により取得された前記通信パケット群に関連付けて、前記新たなデータ通信の実行ジョブの情報をも格納することを特徴とする通信装置。
12. 請求項１に記載の通信装置において、
    前記パケット取得手段は、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始した後、前記一のエラーのエラー種別と同じ種別のエラーの原因が解消されていると判定される場合、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を中止することを特徴とする通信装置。
13. 請求項１に記載の通信装置において、
    前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記両通信条件が互いに同一であると判定された場合であっても、前記一のエラーの原因が既に解消されていると判定されるときには、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始しないことを特徴とする通信装置。
14. 請求項１に記載の通信装置において、
    前記パケット取得手段は、前記少なくとも１つの所定項目に関して前記両通信条件が互いに同一であると判定された場合であっても、前記一のエラーの解消策が既に得られていると判定されるときには、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始しないことを特徴とする通信装置。
15. 請求項１に記載の通信装置において、
    前記少なくとも１つの所定項目は、通信先装置と通信プロトコルとポート番号とのいずれかを含むことを特徴とする通信装置。
16. 請求項１に記載の通信装置において、
    前記少なくとも１つの所定項目は、階層化された複数の項目を含み、
    前記複数の項目は、上位階層項目と当該上位階層項目よりも下位の下位階層項目とを含むことを特徴とする通信装置。
17. 請求項１６に記載の通信装置において、
    前記上位階層項目は、通信プロトコルであり、
    前記下位階層項目は、前記通信プロトコルでの認証方式であることを特徴とする通信装置。
18. 請求項１に記載の通信装置において、
    前記パケット取得手段は、前記新たなデータ通信としてデータ送信が行われる場合、前記データ送信の開始前に前記通信パケット群の前記取得処理を開始することを特徴とする通信装置。
19. 請求項１８に記載の通信装置において、
    前記パケット取得手段は、前記新たなデータ通信としてスキャン画像のデータ送信が行われる場合、前記スキャン画像の生成開始指示の直後ではなく、前記生成開始指示に応じて原稿の読取処理が開始された後且つ前記データ送信の開始直前に、前記通信パケット群の前記取得処理を開始することを特徴とする通信装置。
20. 請求項１に記載の通信装置において、
    前記パケット取得手段は、前記新たなデータ通信としてデータ受信が行われる場合、前記データ受信の開始後において前記第１の通信条件における前記少なくとも１つの所定項目の内容が確定した後に、前記少なくとも１つの所定項目に関する前記両通信条件の内容の同一性を判定することを特徴とする通信装置。
21. 請求項１８または請求項１９に記載の通信装置において、
    前記パケット取得手段は、
    前記新たなデータ通信としてデータ受信が行われる場合、前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であるか否かにかかわらず、前記新たなデータ通信に関する前記通信パケット群の前記取得処理を開始し、
    前記データ受信の開始後において前記第１の通信条件における前記少なくとも１つの所定項目の内容が確定した後に、前記少なくとも１つの所定項目に関する前記両通信条件の内容の同一性を判定し、
    前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一ではないと判定される場合、前記通信パケット群の前記取得処理を終了し、
    前記少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定される場合、前記通信パケット群の前記取得処理を継続することを特徴とする通信装置。
22. 請求項１に記載の通信装置において、
    前記格納制御手段は、前記通信装置と前記通信装置の外部の一または複数の装置との間で授受される全ての通信パケットのうち、予め設定された所定の条件に合致する一部の通信パケットのみを、前記通信パケット群として前記所定の格納部に格納することを特徴とする通信装置。
23. 請求項１に記載の通信装置において、
    前記所定の格納部は、前記通信装置に設けられることを特徴とする通信装置。
24. 請求項１に記載の通信装置において、
    前記所定の格納部は、前記通信装置と通信可能な所定の外部の装置に設けられることを特徴とする通信装置。
25. 請求項１に記載の通信装置において、
    前記エラー履歴情報は、前記通信装置に格納されることを特徴とする通信装置。
26. 請求項１に記載の通信装置において、
    前記エラー履歴情報は、前記通信装置と通信可能な所定の外部の装置に格納されることを特徴とする通信装置。
27. 通信装置の制御方法であって、
    ａ）前記通信装置と外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得するステップと、
    ｂ）前記通信装置と一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較するステップと、
    ｃ）少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するステップと、
    ｄ）前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納するステップと、
    を備えることを特徴とする制御方法。
28. 請求項２７に記載の制御方法を、前記通信装置に内蔵されたコンピュータに実行させるプログラム。
29. 複数の通信装置を備える通信システムであって、
    前記複数の通信装置は、それぞれ、
    外部装置群との過去のデータ通信におけるエラー発生時の通信条件と前記過去のデータ通信におけるエラーの種別情報とを含むエラー履歴情報を取得する履歴情報取得手段と、
    一の外部装置との間での新たなデータ通信において、当該新たなデータ通信時の通信条件である第１の通信条件と、前記エラー履歴情報に含まれる過去の一のエラー発生時の通信条件である第２の通信条件との両通信条件を比較する比較手段と、
    少なくとも１つの所定項目に関する前記両通信条件の内容が互いに同一であると判定されることを条件として、前記新たなデータ通信に関する通信パケット群の取得処理を開始するパケット取得手段と、
    前記エラー履歴情報に含まれる前記一のエラーのエラー種別と同じ種別のエラーが前記新たなデータ通信にて発生したことを条件として、前記取得処理によって取得された前記通信パケット群を所定の格納部に格納する格納制御手段と、
    を備え、
    前記複数の通信装置のそれぞれは、前記複数の通信装置に共通する共通エラー履歴情報を前記エラー履歴情報として利用することを特徴とする通信システム。
30. 請求項２９に記載の通信システムにおいて、
    前記エラー履歴情報は、前記複数の通信装置のそれぞれに設けられ、
    前記複数の通信装置のそれぞれは、自装置内の前記エラー履歴情報を更新した際に、他の各装置内の前記エラー履歴情報をも更新させることによって、前記共通エラー履歴情報を構築することを特徴とする通信システム。
31. 請求項２９に記載の通信システムにおいて、
    前記複数の通信装置と通信することが可能なサーバ、
    をさらに備え、
    前記共通エラー履歴情報は、前記サーバに設けられ、
    前記複数の通信装置のそれぞれは、前記サーバに設けられた前記共通エラー履歴情報にアクセスして前記エラー履歴情報を取得することを特徴とする通信システム。
32. 請求項３１に記載の通信システムにおいて、
    前記サーバと通信することが可能な上位サーバ、
    をさらに備え、
    前記サーバは、前記一のエラーの解消策が既に得られているか否かを前記上位サーバに問い合わせ、
    前記サーバは、前記一のエラーの解消策が既に得られている旨の問合せ結果を前記上位サーバから受信すると、前記サーバに格納された前記エラー履歴情報における実行制御情報を更新し、前記一のエラーの発生時と同じ通信条件を有する前記新たなデータ通信に関する前記通信パケット群の前記取得処理を前記複数の通信装置のそれぞれに実行させないことを特徴とする通信システム。

Images