JP2020010164A - 画像処理装置、情報処理装置、画像処理システム、画像処理プログラム、及び情報処理プログラム - Google Patents

Abstract

【課題】不具合に対する誤った動作を抑制可能な画像処理装置、情報処理装置、画像処理システム、画像処理プログラム、及び情報処理プログラムを提供することを目的とする。【解決手段】デバイス１２に不具合が発生した場合、デバイス１２から管理サーバ１６に不具合を通知する。そして、管理サーバ１６が、同仕様の他のデバイス１２に停止信号を送信することでデバイス１２の通信機能以外の機能を即時に停止させるようになっている。また、デバイス１２の停止状態は、管理サーバ１６がデバイス１２の不具合の改修を確認し、停止解除信号を送信するまで継続させる。【選択図】図１

Description

本発明は、画像処理装置、情報処理装置、画像処理システム、画像処理プログラム、及び情報処理プログラムに関する。

特許文献１には、複数のデバイスと複数のデバイスをネットワークを介して管理するデバイス管理サーバとを備えた故障予測システムが提案されている。

詳細には、各デバイスは、自己の状態を診断してその診断結果を通知するデバイス診断手段を備える。一方、デバイス管理サーバは、各デバイス診断手段から送られる診断結果を基に故障傾向のあるデバイスを予測する故障予測手段を備えている。これにより、想定される要因による故障のみならず想定できない要因による故障までも的確に予測することを可能にしている。

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

故障を予測しても不具合が発生している場合に、誤って動作させてしまう場合があった。そこで、本発明は、不具合に対する誤った動作を抑制可能な画像処理装置、情報処理装置、画像処理システム、画像処理プログラム、及び情報処理プログラムを提供することを目的とする。

請求項１に記載の画像処理装置は、予め定めた管理装置から不具合による停止信号を受信する受信部と、前記受信部によって前記停止信号を受信した場合に、前記管理装置との通信に必要な機能以外の機能を停止させる停止制御を行う制御部と、を含む。

請求項２に記載の発明は、請求項１に記載の発明において、不具合が発生した場合に、前記管理装置に不具合の種別を通知する通知部を更に含む。

請求項３に記載の発明は、請求項２に記載の発明において、前記通知部が通知した前記種別に対応する、不具合の発生状況を把握するための把握情報を収集し、前記管理装置に送信する送信部を更に含む。

請求項４に記載の発明は、請求項３に記載の発明において、前記受信部は、前記種別に対応する不具合の発生状況を把握するための把握リストを前記管理装置から更に受信し、前記送信部は、前記受信部によって受信した前記把握リストに従って前記把握情報を収集して前記管理装置に送信する。

請求項５に記載の発明は、請求項４に記載の発明において、前記受信部は、前記把握情報から生成された、同じ不具合が発生するか否かを確認するための確認リストを前記管理装置から更に受信し、前記送信部は、前記受信部によって受信した前記確認リストに従って同じ不具合が発生するか否かを確認するための確認情報を収集して前記管理装置に更に送信する。

請求項６に記載の発明は、請求項５に記載の発明において、前記受信部は、前記確認情報を用いて診断した不具合の診断結果を前記管理装置から更に受信し、前記制御部は、前記診断結果が問題ない場合に、前記機能の停止を解除し、問題がある場合は、前記機能の停止を継続する制御を行う。

請求項７に記載の発明は、請求項１〜６の何れか１項に記載の発明において、前記受信部は、停止解除信号を前記管理装置から更に受信し、前記制御部は、前記停止解除信号を受信した場合に、機能の停止を解除する制御を更に行う。

請求項８に記載の発明は、請求項７に記載の発明において、前記停止制御によって機能を停止する際に当該機能が動作中であった場合、前記機能の停止を解除する制御を行う際に、前記機能の動作再開の可否を受け付ける受付部を更に含み、前記制御部は、前記受付部によって前記動作再開の指示を受け付けた場合に、機能の動作を再開させる制御を行う。

請求項９に記載の発明は、請求項１に記載の発明において、前記管理装置に対して画像処理装置の種別を特定するための特定情報を送信して不具合発生状況の問い合わせを行う問い合わせ部を更に含み、前記受信部は、前記問い合わせ部によって前記不具合発生状況の問い合わせた結果として前記停止信号を受信する。

請求項１０に記載の発明は、請求項９に記載の発明において、前記受信部は、不具合が発生している場合に、自装置の不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを確認するためのデバイス確認リストを更に受信し、前記デバイス確認リストに従って前記同じ仕様を持つ画像処理装置であるかを確認するためのデバイス確認情報を収集して前記管理装置に返信する返信部を更に含む。

請求項１１に記載の発明は、請求項１０に記載の発明において、前記受信部は、前記停止信号と共に、同じ不具合が発生するか否かを確認するための確認リストを更に受信し、前記返信部は、前記受信部によって受信した前記確認リストに従って同じ不具合が発生するか否かを確認するための確認情報を収集して前記管理装置に更に返信する。

請求項１２に記載の情報処理装置は、管理対象の複数の画像処理装置の不具合の発生の有無を検出する検出部と、前記検出部によって不具合の発生が検出された場合、不具合が発生した画像処理装置の仕様を持つ画像処理装置に対して、通信に必要な機能以外の機能を停止する停止信号を送信する信号送信部と、を含む。

請求項１３に記載の発明は、請求項１２に記載の発明において、前記検出部は、不具合が発生した画像形成装置からの不具合の種別の通知により、前記複数の画像処理装置の不具合の発生を検出する。

請求項１４に記載の発明は、請求項１３に記載の発明において、不具合が発生した画像処理装置が収集した、前記種別に対応する不具合の発生状況を把握するための把握情報を受信する第１受信部を更に含む。

請求項１５に記載の発明は、請求項１４に記載の発明において、前記信号送信部は、前記種別に対応する不具合の発生状況を把握するための把握リストを不具合が発生した画像処理装置に更に送信し、前記第１受信部は、前記把握リストに従って収集された把握情報を受信する。

請求項１６に記載の発明は、請求項１５に記載の発明において、前記信号送信部は、前記把握情報から同じ不具合が発生するか否かを確認するための確認リストを生成し、前記管理対象の複数の画像処理装置に更に送信し、前記第１受信部が、前記確認リストに従って収集された確認情報を更に受信する。

請求項１７に記載の発明は、請求項１６に記載の発明において、前記第１受信部が受信した前記確認情報を用いて不具合の診断を行い、診断結果を返信する診断返信部を更に含む。

請求項１８に記載の発明は、請求項１７に記載の発明において、前記診断返信部は、前記診断結果が問題ない場合、機能の停止を解除する停止解除信号を更に返信する。

請求項１９に記載の発明は、請求項１２に記載の発明において、前記複数の画像処理装置から、画像処理装置の種別を特定するための特定情報と共に不具合の問い合わせを受信する第２受信部と、前記第２受信部が前記問い合わせを受信した場合、不具合の発生状況を確認し、不具合の発生が確認された場合に、前記信号送信部による前記停止信号の送信を制御する送信制御部と、を更に含む。

請求項２０に記載の発明は、請求項１９に記載の発明において、前記信号送信部は、不具合が発生している場合に、前記第２受信部が受信した前記問い合わせを行った画像処理装置に対して、不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを確認するためのデバイス確認リストを更に送信し、前記第２受信部が、前記デバイス確認リストに従って収集したデバイス確認情報を更に受信する。

請求項２１に記載の発明は、請求項２０に記載の発明において、前記信号送信部は、前記デバイス確認情報が前記同じ仕様を持つ画像処理装置を表す場合に、前記停止信号と共に、同じ不具合が発生するか否かを確認するための確認リストを更に送信し、前記第２受信部は、前記確認リストを用いて同じ不具合が発生するか否かを確認した発生確認結果を更に受信し、前記送信制御部は、前記発生確認結果が同じ不具合が発生することを表す場合に、前記信号送信部による前記停止信号の送信を制御する。

請求項２２に記載の画像処理システムは、請求項１〜１１の何れか１項に記載の画像処理装置と、請求項１２〜２１の何れか１項に記載の情報処理装置と、前記画像処理装置と前記情報処理装置とを通信接続する通信回線と、を含む。

請求項２３に記載の画像処理プログラムは、コンピュータを、請求項１〜１１の何れか１項に記載の画像処理装置を構成する各部として機能させる。

請求項２４に記載の情報処理プログラムは、コンピュータを、請求項１２〜２１の何れか１項に記載の情報処理装置を構成する各部として機能させる。

請求項１に記載の画像処理装置によれば、不具合に対する誤った動作を抑制可能な画像処理装置を提供できる。

請求項２に記載の発明によれば、画像処理装置において発生している不具合の種別を管理装置が認識することが可能となる。

請求項３に記載の発明によれば、不具合の種別に応じた把握情報を管理装置に集めることが可能となる。

請求項４に記載の発明によれば、把握リストを管理装置から受信せずに把握情報を収集する場合に比べて、把握情報の収集を容易に行うことが可能となる。

請求項５に記載の発明によれば、確認リストを管理装置から受信せずに確認情報を収集する場合に比べて、確認情報の収集を容易に行うことが可能となる。

請求項６に記載の発明によれば、問題がないまま機能が停止し続けることを抑制することが可能となる。

請求項７に記載の発明によれば、利用者による機能の停止の誤解除を抑制することが可能となる。

請求項８に記載の発明によれば、機能の停止が解除されても直ぐに機能の動作を再開させたくない場合に対応することが可能となる。

請求項９に記載の発明によれば、管理装置が全ての画像処理装置の所在を把握していない形態であっても、不具合に対する誤った動作を抑制可能な画像処理装置を提供できる。

請求項１０に記載の発明によれば、管理装置が全ての画像処理装置の所在を把握していない形態であっても、不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを管理装置が認識することが可能となる。

請求項１１に記載の発明によれば、管理装置が全ての画像処理装置の所在を把握していない形態であっても、確認リストを管理装置から受信せずに確認情報を収集する場合に比べて、確認情報の収集を容易に行うことが可能となる。

請求項１２に記載の情報処理装置によれば、不具合に対する誤った動作を抑制可能な情報処理装置を提供できる。

請求項１３に記載の発明によれば、管理対象の画像処理装置の不具合の発生と共に不具合の種別を認識することが可能となる。

請求項１４に記載の発明によれば、不具合の種別に応じた把握情報を集めることが可能となる。

請求項１５に記載の発明によれば、把握リストを画像処理装置に送信せずに把握情報を画像処理装置から受信する場合に比べて、把握情報の収集を容易に行うことが可能となる。

請求項１６に記載の発明によれば、確認リストを画像処理装置に送信せずに確認情報を受信する場合に比べて、確認情報の収集を容易に行うことが可能となる。

請求項１７に記載の発明によれば、問題がないまま画像処理装置の機能が停止し続けることを抑制することが可能となる。

請求項１８に記載の発明によれば、利用者による画像形成装置の機能の停止の誤解除を抑制することが可能となる。

請求項１９に記載の発明によれば、管理対象の全ての画像処理装置の所在を把握していない形態であっても、不具合に対する誤った動作を抑制可能な情報処理装置を提供できる。

請求項２０に記載の発明によれば、管理対象の全ての画像処理装置の所在を把握していない形態であっても、不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを認識することが可能となる。

請求項２１に記載の発明によれば、管理対象の全ての画像処理装置の所在を把握していない形態であっても、不具合が発生した画像処理装置と同じ不具合が発生するか否かを確認してから停止信号を送信することが可能となる。

請求項２２に記載の画像処理システムによれば、不具合に対する誤った動作を抑制可能な画像処理システムを提供できる。

請求項２３に記載の画像処理プログラムによれば、不具合に対する誤った動作を抑制可能な画像処理プログラムを提供できる。

請求項２４に記載の情報処理プログラムによれば、不具合に対する誤った動作を抑制可能な情報処理プログラムを提供できる。

本実施形態に係る画像処理システムの概略構成を示す図である。 本実施形態に係るデバイスとしての画像形成装置の外観を示す斜視図である。 本実施形態に係るデバイスの電気系の要部構成を示すブロック図である。 本実施形態に係る情報処理装置及び管理サーバの電気系の要部構成を示すブロック図である。 本実施形態に係る画像処理システムにおける、デバイスの不具合通知から不具合検証までの信号の流れを説明するための図である。 本実施形態に係る画像処理システムのデバイスのコントロール・ユニットで行われる処理の流れの一例を示すフローチャートである。 本実施形態に係る画像処理システムの管理サーバで行われる処理の流れの一例を示すフローチャートである。 デバイスが管理サーバに対して不具合の問い合わせを行うように構成した場合の不具合検証の際の信号の流れを示す図である。 デバイスが管理サーバに対して不具合の問い合わせを行うように構成した場合の画像処理システムのデバイスのコントロール・ユニットで行われる処理の流れの一例を示すフローチャートである。 デバイスが管理サーバに対して不具合の問い合わせを行うように構成した場合の画像処理システムの管理サーバで行われる処理の流れの一例を示すフローチャートである。 不具合問い合わせ対応処理の流れの一例を示すフローチャートである。

以下、図面を参照して本実施形態の一例を詳細に説明する。本実施形態では、複数のデバイス、複数の情報処理装置、及び管理サーバがネットワーク等の通信回線を介して各々接続された画像処理システムを一例として説明する。図１は、本実施形態に係る画像処理システム１０の概略構成を示す図である。

本実施形態に係る画像処理システム１０は、図１に示すように、複数のデバイス１２ａ、１２ｂ、・・・、複数の情報処理装置１４ａ、１４ｂ、・・・と、管理サーバ１６とを備えている。なお、デバイス１２ａ、１２ｂ、・・・、及び情報処理装置１４ａ、１４ｂ・・・のそれぞれを区別して説明する必要がない場合は、符号末尾のアルファベットを省略して記載することがある。また、本実施形態では、複数の情報処理装置１４ａ、１４ｂ、・・・を備える例を説明するが、情報処理装置１４は１つでもよい。また、各デバイス１２は画像処理装置に対応し、管理サーバ１６は管理装置及び情報処理装置に対応する。

各デバイス１２、各情報処理装置１４、及び管理サーバ１６は、各種ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、イントラネット等）の通信回線１８を介して各々接続されている。そして、デバイス１２、情報処理装置１４、及び管理サーバ１６の各々は、通信回線１８を介して各種データの送受信を相互に行うことが可能とされている。

管理サーバ１６は、通信回線１８に接続されたデバイス１２に関する不具合を管理する。管理サーバ１６は、通信回線１８に直接接続されたデバイス１２ａ、１２ｄ以外に、サーバとして機能する情報処理装置１４ｂまたは主となるマスタのデバイス１２ｄに接続されたデバイス１２ｂ、１２ｃ、１２ｅ、１２ｆを管理してもよい。

本実施形態では、各デバイス１２の一例として、プリンタ、コピー、スキャナ、ファクシミリなど複数の機能を有する画像形成装置を適用した例を一例として説明する。

ここで、デバイス１２として適用する画像形成装置の一例について説明する。図２は、本実施形態に係るデバイス１２としての画像形成装置の外観を示す斜視図である。本実施形態に係るデバイス１２は、通信回線１８を介して各種データを受信し、受信したデータに基づく画像形成処理を行うプリント機能を有する。また、本実施形態に係るデバイス１２は、原稿を読み取って原稿を表す画像情報を得る読取機能、原稿に記録された画像を用紙に複写する複写機能、図示しない電話回線を介して各種データの送信及び受信を行うファクシミリ機能等も有する。

また、本実施形態に係るデバイス１２は、装置上部に原稿読取部５２を備え、原稿読取部５２の下方に画像形成部２４が配置されている。原稿読取部５２は、原稿カバー５４内に原稿搬送部（図示省略）を備えている。原稿搬送部は、原稿カバー５４に設けられている原稿給紙部５４Ａ上に載せられた原稿５６を順に引き込んで図示しないプラテンガラス上に搬送して原稿５６に記録された画像の読み取りを行う。また、原稿搬送部は、画像の読み取りが終了した原稿５６を原稿カバー５４に設けられている原稿排出部５４Ｂ上に排出する。

また、原稿読取部５２には、ユーザによる各種の指示操作を受け付けるユーザインタフェース２２が設けられている。このユーザインタフェース２２は、ソフトウェアプログラムによって指示操作の受け付けを実現する表示ボタンや各種情報が表示されるタッチパネル式のディスプレイ２２Ａ、テンキーやスタートボタン等のハードウェアキー２２Ｂ等が設けられている。ユーザインタフェース２２は、ディスプレイ２２Ａの表示ボタンやハードウェアキー２２Ｂによって複写機能を用いるときの複写枚数の設定や倍率設定、ファクシミリ機能を用いるときの電話機のダイヤルキー等として用いられる。

一方、画像形成部２４は、画像形成用の記録媒体となる用紙が収容される給紙格納部５８を備えている。画像形成部２４では、給紙格納部５８に収容されている用紙を、１枚ずつ取り出し、例えば、電子写真プロセスによって画像データに基づいた画像を用紙に形成する。また、画像形成部２４では、画像形成を行った用紙を順に図示しない排紙部上へ排出する。

情報処理装置１４は、画像形成要求を送信することにより、デバイス１２のプリント機能により用紙に画像を形成させる。

管理サーバ１６及びサーバとして機能する情報処理装置１４ｂは、情報処理装置１４からの画像形成要求を要求先のデバイス１２に送信する機能や、デバイス１２の状況を監視して管理サーバ１６または情報処理装置１４に通知する機能等を有する。

図３は、本実施形態に係るデバイス１２の電気系の要部構成を示すブロック図である。

本実施形態に係るデバイス１２は、図３に示すように、ＣＰＵ（Central Processing Unit）２０Ａ、ＲＯＭ（Read Only Memory）２０Ｂ、及びＲＡＭ（Random Access Memory）２０Ｃを含むコントロール・ユニット２０を備えている。ＣＰＵ２０Ａは、デバイス１２の全体の動作を司る。ＲＡＭ２０Ｃは、ＣＰＵ２０Ａによる各種プログラムの実行時のワークエリア等として用いられる。ＲＯＭ２０Ｂは、各種制御プログラムや各種パラメータ等が予め記憶される。そして、デバイス１２は、コントロール・ユニット２０の各部がシステムバス４２によって電気的に接続されている。

一方、本実施の形態に係るデバイス１２は、各種のデータやアプリケーション・プログラム等を記憶するＨＤＤ（hard disk drive）２６を備えている。また、デバイス１２は、ユーザインタフェース２２に接続され、ユーザインタフェース２２のディスプレイ２２Ａへの各種の操作画面等の表示を制御する表示制御部２８を備えている。また、デバイス１２は、ユーザインタフェース２２に接続され、ユーザインタフェース２２を介して入力される操作指示を検出する操作入力検出部３０を備えている。そして、デバイス１２では、ＨＤＤ２６、表示制御部２８、および操作入力検出部３０がシステムバス４２に電気的に接続されている。なお、本実施の形態に係るデバイス１２では、記憶部としてＨＤＤ２６を適用しているが、これに限らず、フラッシュメモリ等の不揮発性の記憶部を適用してもよい。

また、本実施形態に係るデバイス１２は、原稿読取部５２による光学的な画像の読み取り動作、及び原稿搬送部による原稿送り動作を制御する読取制御部３２と、画像形成部２４による画像形成処理、及び搬送部２５による画像形成部２４への用紙の搬送を制御する画像形成制御部３４と、を備えている。また、デバイス１２は、通信回線１８に接続され、当該通信回線１８に接続された管理サーバ１６等の他の外部装置と通信データの送受信を行う通信回線Ｉ／Ｆ（インタフェース）部３６と、デバイス１２の障害の発生を検知する不具合検知部４６と、を備えている。また、デバイス１２は、図示しない電話回線に接続され、当該電話回線に接続されているファクシミリ装置とファクシミリデータの送受信を行うファクシミリＩ／Ｆ（インタフェース）部３８を備えている。また、デバイス１２は、ファクシミリＩ／Ｆ部３８を介したファクシミリデータの送受信を制御する送受信制御部４０を備えている。そして、デバイス１２では、送受信制御部４０、読取制御部３２、画像形成制御部３４、通信回線Ｉ／Ｆ部３６、ファクシミリＩ／Ｆ部３８、及び不具合検知部４６がシステムバス４２に電気的に接続されている。

以上の構成により、本実施形態に係るデバイス１２は、ＣＰＵ２０Ａにより、ＲＡＭ２０Ｃ、ＲＯＭ２０Ｂ、及びＨＤＤ２６へのアクセスを各々実行する。また、デバイス１２は、ＣＰＵ２０Ａにより、表示制御部２８を介したユーザインタフェース２２のディスプレイ２２Ａへの操作画面、各種のメッセージ等の情報の表示の制御を実行する。また、デバイス１２は、ＣＰＵ２０Ａにより、読取制御部３２を介した原稿読取部５２及び原稿搬送部の作動の制御を実行する。また、デバイス１２は、ＣＰＵ２０Ａにより、画像形成制御部３４を介した画像形成部２４及び搬送部２５の作動の制御と、通信回線Ｉ／Ｆ部３６を介した通信データの送受信の制御と、を各々実行する。また、デバイス１２は、ＣＰＵ２０Ａにより、送受信制御部４０によるファクシミリＩ／Ｆ部３８を介したファクシミリデータの送受信の制御を実行する。さらに、デバイス１２は、ＣＰＵ２０Ａにより、操作入力検出部３０によって検出された操作情報に基づくユーザインタフェース２２における操作内容の把握が行われ、この操作内容に基づく各種の制御を実行する。

また、不具合検知部４６は、原稿読取部５２や画像形成部２４、搬送部２５等で発生する不具合を検知する。検知する不具合の一例としては、例えば、原稿読取部５２や搬送部２５のモータの故障や、給紙格納部５８に格納された用紙の不足、搬送部２５における用紙詰まり、セキュリティホールなどのソフトウエア容易の不具合等が挙げられる。これらの不具合は一例であって、不具合検知部４６は他の不具合を検知してもよい。

続いて、本実施形態に係る情報処理装置１４及び管理サーバ１６の電気系の要部構成について説明する。図４は、本実施形態に係る情報処理装置１４及び管理サーバ１６の電気系の要部構成を示すブロック図である。なお、情報処理装置１４及び管理サーバ１６は基本的には一般的なコンピュータの構成とされているので、管理サーバ１６を代表して説明する。

本実施の形態に係る管理サーバ１６は、図４に示すように、ＣＰＵ１６Ａ、ＲＯＭ１６Ｂ、ＲＡＭ１６Ｃ、ＨＤＤ１６Ｄ、キーボード１６Ｅ、ディスプレイ１６Ｆ、及び通信回線Ｉ／Ｆ（インタフェース）部１６Ｇを備えている。ＣＰＵ１６Ａは、管理サーバ１６の全体の動作を司る。ＲＯＭ１６Ｂは、各種制御プログラムや各種パラメータ等が予め記憶される。ＲＡＭ１６Ｃは、ＣＰＵ１６Ａによる各種プログラムの実行時のワークエリア等として用いられる。ＨＤＤ１６Ｄは、各種のデータやアプリケーション・プログラム等が記憶される。キーボード１６Ｅは各種の情報を入力するために用いられる。ディスプレイ１６Ｆは、各種の情報を表示するために用いられる。通信回線Ｉ／Ｆ部１６Ｇは、通信回線１８に接続され、当該通信回線１８に接続された他の装置と各種データの送受信を行う。以上の管理サーバ１６の各部はシステムバス１６Ｈにより電気的に相互に接続されている。なお、本実施の形態に係る管理サーバ１６では、ＨＤＤ１６Ｄを記憶部として適用しているが、これに限らず、フラッシュメモリ等の他の不揮発性の記憶部を適用してもよい。

以上の構成により、本実施の形態に係る管理サーバ１６は、ＣＰＵ１６Ａにより、ＲＯＭ１６Ｂ、ＲＡＭ１６Ｃ、及びＨＤＤ１６Ｄに対するアクセス、キーボード１６Ｅを介した各種データの取得、ディスプレイ１６Ｆに対する各種情報の表示を各々実行する。また、管理サーバ１６は、ＣＰＵ１６Ａにより、通信回線Ｉ／Ｆ部１６Ｇを介した通信データの送受信の制御を実行する。

ところで、上述のように構成された画像処理システム１０では、例えば、セキュリティホールなどの不具合がデバイス１２に発見された場合、その影響を最小限に抑えるために、可能な限り早急にデバイス１２の使用を停止させる必要がある。また、不具合が解消されるまでは、デバイス１２の利用を停止させることが望ましい。

そこで、本実施形態に係る画像処理システム１０では、デバイス１２に不具合が発生した場合、デバイス１２から管理サーバ１６に不具合を通知する。そして、管理サーバ１６が、同仕様の他のデバイス１２に停止信号を送信することでデバイス１２の通信機能以外の機能を即時に停止させるようになっている。また、デバイス１２の停止状態は、管理サーバ１６がデバイス１２の不具合の改修を確認し、停止解除信号を送信するまで継続させる。

図５は、本実施形態に係る画像処理システム１０における、デバイス１２の不具合通知から不具合検証までの信号の流れを説明するための図である。

デバイス１２は、不具合検知部４６によってデバイス１２内の不具合を検知し、不具合が検知された場合には、不具合発生のデバイス１２から管理サーバ１６に不具合種別を通知する。

管理サーバ１６は、不具合発生のデバイス１２へ不具合種別に応じた不具合発生状況を把握するための不具合発生状況把握パラメータリストを把握リストとして送付する。不具合発生状況把握パラメータリストのパラメータ例としては、例えば、ハードウエアが要因の不具合は、デバイス１２に搭載されるモータなどの駆動装置の種類、製造年月日、使用期間、駆動時間、モータ回転数（累積回転数等）、温度（平均温度や、最高温度等）などが挙げられる。また、セキュリティホール等のソフトウエアが要因の不具合の場合は、デバイス１２に搭載されるソフトウエア構成、及びソフトウエアのバージョン（例えば、カーネルVer6.0、システムVer1.0、ネットワークモジュールVer3.1、セキュリティモジュールVer2.0など）や、設定値（例えば、ネットワーク設定値、暗号化プロトコル（ＷＥＰ／ＷＡＰ／ＷＡＰ２など）、実行サービス（ｆｆｐサーバ、ｓｍｂサーバ等）などのソフトウエア情報が挙げられる。

デバイス１２は、不具合発生状況把握パラメータリストに従いデバイス１２内のパラメータを把握情報として収集し、管理サーバ１６へ返送する。なお、パラメータの収集及び通知は、情報処理装置１４や管理サーバ１６が行ってもよい。

管理サーバ１６は、受信したパラメータを元に、同じ仕様を持つデバイスリストと、同じ不具合が発生するか否かをチェックするための不具合発生確認パラメータリストを確認リストとして生成する。なお、同じ仕様とは、ハードウエアが要因の不具合の場合は、デバイス１２に搭載されるモータなどの駆動装置の種類や、製造日などのハードウエアの仕様が同じことを指す。一方、セキュリティホールなどのソフトウエアが要因の不具合の場合は、デバイス１２に搭載されるソフトウエアの構成や、ソフトウエアのバージョンなどのソフトウエアの仕様が同じことを指す。また、不具合発生確認パラメータリストは、不具合発生状況把握パラメータリストと基本的には同じ内容をパラメータである。

続いて、管理サーバ１６は、同じ仕様を持つデバイスリスト上のデバイス１２に対して不具合発生確認パラメータリスト及び停止信号を送信する。

停止信号を受信したデバイス１２は、まず管理サーバ１６との通信に必要な機能以外の機能の動作を停止させる。続いて、デバイス１２は、不具合発生確認パラメータリストに従いデバイス１２内のパラメータを確認情報として収集し、管理サーバ１６へ収集したパラメータを返送する。なお、パラメータの収集及び通知は、情報処理装置１４や管理サーバ１６が行ってもよい。

また、不具合発生のデバイス１２は、管理サーバ１６との通信に必要な機能以外の機能の動作を停止させ、不具合の改修後に、不具合発生確認パラメータリストに従いデバイス１２内のパラメータを収集し、管理サーバ１６へ収集したパラメータを返送する。

管理サーバ１６は、デバイス１２が収集して返送されたパラメータから不具合発生リスクを診断し、診断結果をデバイス１２に送信する。ここで、診断結果が不具合の発生リスクがなく問題ない場合は、停止解除信号をデバイス１２に送信する。

診断結果を受けたデバイス１２は、診断結果をユーザインタフェース２２のディスプレイ２２Ａに表示すると共に、問題が無ければ停止解除信号に従って、機能の停止状態を解除する。また、診断結果に問題がある場合は、機能の停止状態を継続する。そして、不具合の改修後に、改めて不具合発生確認パラメータリストに従い、デバイス１２内のパラメータを収集して管理サーバ１６へ収集したパラメータを返信し、上述のように、不具合発生リスクの診断を再度行う。

続いて、上述のように構成された本実施形態に係る画像処理システム１０の各部で行われる具体的な処理について説明する。

まず、デバイス１２のコントロール・ユニット２０で行われる処理の具体例について説明する。図６は、本実施形態に係る画像処理システム１０のデバイス１２のコントロール・ユニット２０で行われる処理の流れの一例を示すフローチャートである。なお、図６の処理は、例えば、不具合検知部４６が不具合を検知した場合、または通信回線Ｉ／Ｆ部３６が、管理サーバ１６等から情報を受信した場合に開始するものとする。

ステップ１００では、ＣＰＵ２０Ａが、不具合検知部４６によってデバイス１２の不具合を検知したか否かを判定する。該判定が肯定された場合にはステップ１０２へ移行し、否定された場合にはステップ１０６へ移行する。

ステップ１０２では、ＣＰＵ２０Ａが、不具合検知部４６から検知した不具合の種別を取得してステップ１０４へ移行する。

ステップ１０４では、ＣＰＵ２０Ａが、管理サーバ１６へ発生した不具合の種別を通知してステップ１０６へ移行する。

ステップ１０６では、ＣＰＵ２０Ａが、不具合発生状況把握パラメータリストを管理サーバ１６から受信したか否かを判定する。該判定が肯定された場合にはステップ１０８へ移行し、否定された場合にはステップ１１２へ移行する。

ステップ１０８では、ＣＰＵ２０Ａが、管理サーバ１６から受信した不具合発生状況把握パラメータリストに従ってパラメータを収集してステップ１１０へ移行する。

ステップ１１０では、ＣＰＵ２０Ａが、収集したパラメータを管理サーバ１６へ返送してステップ１１２へ移行する。

ステップ１１２では、ＣＰＵ２０Ａが、停止信号と不具合発生確認パラメータリストを管理サーバ１６から受信したか否かを判定する。該判定が肯定された場合にはステップ１１４へ移行し、否定された場合にはステップ１２０へ移行する。

ステップ１１４では、ＣＰＵ２０Ａが、管理サーバ１６と通信する機能以外の機能の動作を停止してステップ１１６へ移行する。

ステップ１１６では、ＣＰＵ２０Ａが、管理サーバ１６から受信した不具合発生確認パラメータリストに従ってパラメータを収集してステップ１１８へ移行する。

ステップ１１８では、ＣＰＵ２０Ａが、収集したパラメータを管理サーバ１６へ返送してステップ１２０へ移行する。

ステップ１２０では、ＣＰＵ２０Ａが、管理サーバ１６から停止解除信号を受信したか否かを判定する。該判定が肯定された場合にはステップ１２２へ移行し、否定された場合にはステップ１２４へ移行する。

ステップ１２２では、ＣＰＵ２０Ａが、停止機能再開処理を実行して一連の処理を終了する。停止機能再開処理は、例えば、停止解除信号を受信したところで、停止していた機能を直ぐに再開してもよい。或いは、停止する際に動作中であった機能であっても直ぐに動作を再開する必要がない場合などがあるため、停止する際に動作していた機能を再開する場合は、受付部としてのユーザインタフェース２２により再開の可否を利用者から受け付ける処理を行ってもよい。例えば、停止する際に動作中であった機能の動作を再開するか否かをユーザインタフェース２２のディスプレイ２２Ａに表示する。そして、ユーザインタフェース２２を介して再開の指示を受け付けた場合に停止した機能を再開するようにしてもよい。

一方、ステップ１２４では、ＣＰＵ２０Ａが、機能停止中であるか否かを判定する。該判定が肯定された場合にはステップ１２６へ移行し、否定された場合にはそのまま一連の処理を終了する。

ステップ１２６では、ＣＰＵ２０Ａが、停止している通信機能以外の機能の停止を継続してステップ１２８へ移行する。

ステップ１２８では、ＣＰＵ２０Ａが、不具合が解消されたか否かを判定する。該判定は、ＣＰＵ２０Ａが、不具合検知部４６によって不具合の改修を検知したか否か等を判定する。該判定が肯定されるまで待機し、判定が肯定された場合はステップ１１６に戻って上述の処理を繰り返す。

なお、ステップ１０４は通知部に対応し、ステップ１０６、１１２は受信部に対応し、ステップ１０８、１１０、１１６、１１８は送信部に対応し、ステップ１１４、１２０〜１２６は制御部に対応する。

次に、管理サーバ１６で行われる処理の具体例について説明する。図７は、本実施形態に係る画像処理システム１０の管理サーバ１６で行われる処理の流れの一例を示すフローチャートである。なお、図７の処理は、例えば、通信回線１８に接続されたデバイス１２や情報処理装置１４等から情報を受信した場合に開始するものとする。

ステップ２００では、ＣＰＵ１６Ａが、通信回線Ｉ／Ｆ部１６Ｇを介して不具合種別を受信したか否かを判定する。すなわち、デバイス１２の不具合検知部４６によってデバイス１２の不具合が検知されて、上述のステップ１０４により不具合の種別がデバイス１２から通知されたか否かを判定する。該判定が肯定された場合にはステップ２０２へ移行し、否定された場合にはステップ２０４へ移行する。

ステップ２０２では、ＣＰＵ１６Ａが、不具合発生のデバイス１２に対して不具合種別に応じた不具合発生状況把握パラメータリストを送付してステップ２０４へ移行する

ステップ２０４では、ＣＰＵ１６Ａが、不具合発生把握パラメータリストに対するパラメータ（不具合発生把握パラメータ）を不具合発生のデバイス１２から受信したか否かを判定する。すなわち、上述のステップ１１０によりデバイス１２から返送されたパラメータを受信したか否かを判定する。該判定が肯定された場合にはステップ２０６へ移行し、否定された場合にはステップ２０８へ移行する。

ステップ２０６では、ＣＰＵ１６Ａが、不具合のデバイス１２から受信した不具合発生把握パラメータから不具合発生確認パラメータリストを生成して、不具合発生のデバイス１２と同仕様のデバイス１２に停止信号と共に送信してステップ２０８へ移行する。

ステップ２０８では、ＣＰＵ１６Ａが、不具合発生確認パラメータリストに対するパラメータ（不具合発生確認パラメータ）をデバイス１２から受信したか否かを判定する。すなわち、上述のステップ１１８によりデバイス１２から返送されたパラメータを受信したか否かを判定する。該判定が肯定された場合にはステップ２１０へ移行し、否定された場合にはそのまま一連の処理を終了する。

ステップ２１０では、ＣＰＵ１６Ａが、不具合発生確認パラメータより不具合発生リスクを診断してステップ２１２へ移行する。

ステップ２１２では、ＣＰＵ１６Ａが、不具合発生リスクの診断結果が問題なしか否かを判定し、該判定が肯定された場合にはステップ２１４へ移行し、否定された場合には一連の処理を終了する。

ステップ２１４では、ＣＰＵ１６Ａが、停止解除信号及び診断結果をデバイス１２に送信して一連の処理を終了する。

なお、ステップ２００は検出部に対応し、ステップ２０４は第１受信部に対応し、ステップ２０２、２０６は信号送信部に対応し、ステップ２１０〜２１４は診断返信部に対応する。

以上のようにデバイス１２及び管理サーバ１６の各々が処理を行うことで、上述した図５に示す不具合通知から不具合検証の際の信号の授受が行われる。これにより、不具合が発生したデバイス１２や不具合が発生する可能性があるデバイス１２は、通信機能以外の機能が停止され、不具合に対して誤って動作されることなく、不具合による影響が抑制される。また、通信機能について停止されないので、不具合の問題がないことが確認された場合には、管理サーバ１６からデバイス１２の停止した機能が速やかに復帰される。

ところで、本実施形態では、管理サーバ１６が全てのデバイス１２の所在を把握している必要があり、管理サーバ１６とデバイス１２が１対Ｎ（Ｎは自然数）の構成となっていることが前提である。図５〜７の処理では、管理サーバ１６が全ての管理対象のデバイス１２の所在を把握していない場合には対応できない。例えば、管理サーバ１６をクラウドサーバへ移行して、クラウドサーバを管理サーバ１６として適用し、管理サーバ１６とデバイス１２がＮ対Ｎの構成になったときに対応できない。

そこで、管理サーバ１６とデバイス１２がＮ対Ｎの構成の場合に適用可能にするために、デバイス１２がプッシュ方式で管理サーバ１６に不具合を通知するのではなく、デバイス１２がプル方式で管理サーバ１６に対して不具合の問い合わせを行ってもよい。図８は、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の不具合検証の際の信号の流れを示す図である。

具体的には、図８に示すように、デバイス１２が、定期的（例えば、予め定めた時間毎等）に不具合の発生状況を管理サーバ１６に問い合わせる。なお、不具合の発生状況を管理サーバ１６に問い合わせる際には、デバイス１２の種別を特定するための特定情報を送付する。

管理サーバ１６は、デバイス１２の種別から不具合発生状況を確認し、不具合が発生していたら、同じ仕様を持つデバイスかを特定するための同仕様デバイス特定パラメータリストをデバイス確認リストとしてデバイス１２に返信する。

デバイス１２は、管理サーバ１６から受信した同仕様デバイス特定パラメータリストに従ってデバイス１２内のパラメータをデバイス確認情報として収集し、収集したパラメータを管理サーバ１６に返送する。なお、パラメータの収集及び通知は、情報処理装置１４や管理サーバ１６が行ってもよい。

管理サーバ１６は、デバイス１２から返送された同仕様デバイス特定パラメータリストに対するパラメータ（同仕様デバイス特定パラメータ）から不具合発生のデバイス１２と同仕様であることを確認した場合、同じ不具合が発生するか否かをチェックするための不具合発生確認パラメータリスト及び停止信号をデバイス１２に送信する。

以降は上記と同様に処理を行う。すなわち、停止信号を受信したデバイス１２は、まず管理サーバ１６との通信に必要な機能以外の機能の動作を停止させる。次にデバイス１２は、不具合発生確認パラメータリストに従いデバイス１２内のパラメータを収集し、管理サーバ１６へ収集したパラメータを返送する。なお、パラメータの収集及び通知は、情報処理装置１４や管理サーバ１６が行ってもよい。

管理サーバ１６は、デバイス１２が収集して返送されたパラメータから不具合発生リスクを診断し、診断結果をデバイス１２に送信する。ここで、診断結果が不具合の発生リスクがない場合は停止解除信号をデバイス１２に送信する。

診断結果を受けたデバイス１２は、診断結果をユーザインタフェース２２のディスプレイ２２Ａに表示すると共に、問題が無ければ停止解除信号に従って、機能の停止状態を解除する。また、診断結果に問題がある場合は、機能の停止状態を継続する。そして、不具合の改修後に、改めて不具合発生確認パラメータリストに従い、デバイス１２内のパラメータを収集して管理サーバ１６へ収集したパラメータを返信し、上述のように、不具合発生リスクの診断を行う。

続いて、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の画像処理システム１０の各部で行われる具体的な処理について説明する。

まず、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合のデバイス１２のコントロール・ユニット２０で行われる処理の具体例について説明する。図９は、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の画像処理システム１０のデバイス１２のコントロール・ユニット２０で行われる処理の流れの一例を示すフローチャートである。なお、図９の処理は、定期的（例えば、予め定めた時間毎）に開始するものとする。

ステップ１５０では、ＣＰＵ２０Ａが、不具合発生状況を管理サーバ１６に問い合わせてステップ１５２へ移行する。ここで、不具合の発生状況を管理サーバ１６に問い合わせる際に、デバイス１２の種別を特定するための特定情報を管理サーバ１６に送付する。

ステップ１５２では、ＣＰＵ２０Ａが、管理サーバ１６に不具合発生状況を問い合わせた結果不具合の発生があるか否かを判定する。該判定が肯定された場合にはステップ１５４へ移行し、否定された場合には一連の定期的に行う処理を終了する。

ステップ１５４では、ＣＰＵ２０Ａが、管理サーバ１６から同仕様デバイス特定パラメータリストを受信したか否かを判定し、該判定が肯定されるまで待機してステップ１５６へ移行する。

ステップ１５６では、ＣＰＵ２０Ａが、同仕様デバイス特定パラメータリストに従ってデバイス１２内のパラメータを収集してステップ１５８へ移行する。

ステップ１５８では、ＣＰＵ２０Ａが、収集したパラメータを管理サーバ１６へ返送して一連の定期的に行う処理を終了する。

なお、デバイス１２は、不具合検知部４６が不具合を検知した場合、または通信回線Ｉ／Ｆ部３６が、管理サーバ１６等から情報を受信した場合には、上述した図６の処理を行う。

また、ステップ１５０は問い合わせ部に対応し、ステップ１５４は受信部に対応し、ステップ１５６、１５８は返信部に対応する。

次に、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の管理サーバ１６で行われる処理の具体例について説明する。図１０は、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の画像処理システム１０の管理サーバ１６で行われる処理の流れの一例を示すフローチャートである。なお、図１０の処理は、例えば、通信回線１８に接続されたデバイス１２や情報処理装置１４等から情報を受信した場合に開始するものとする。また、図７の処理と同一処理は同一符号を付して説明する。

ステップ２００では、ＣＰＵ１６Ａが、通信回線Ｉ／Ｆ部１６Ｇを介して不具合種別を受信したか否かを判定する。すなわち、デバイス１２の不具合検知部４６によってデバイス１２の不具合が検知されて、上述のステップ１０４により不具合の種別がデバイス１２から通知されたか否かを判定する。該判定が肯定された場合にはステップ２０２へ移行し、否定された場合にはステップ２０４へ移行する。

ステップ２０２では、ＣＰＵ１６Ａが、不具合発生のデバイス１２に対して不具合種別に応じた不具合発生状況把握パラメータリストを送付してステップ２０４へ移行する。

ステップ２０４では、ＣＰＵ１６Ａが、不具合発生把握パラメータリストに対するパラメータ（不具合発生把握パラメータ）を不具合発生のデバイス１２から受信したか否かを判定する。すなわち、上述のステップ１１０によりデバイス１２から返送されたパラメータを受信したか否かを判定する。該判定が肯定された場合にはステップ２０５へ移行し、否定された場合にはステップ２０７へ移行する。

ステップ２０５では、ＣＰＵ１６Ａが、不具合のデバイス１２から受信した不具合発生把握パラメータから不具合発生確認パラメータリストを生成してステップ２０７へ移行する。

ステップ２０７では、ＣＰＵ１６Ａが、不具合問い合わせ対応処理を行ってステップ２０８へ移行する。なお、不具合対応処理は、デバイス１２からの不具合問い合わせに対して行われる処理であり、詳細は後述する。

ステップ２０８では、ＣＰＵ１６Ａが、不具合発生確認パラメータリストに対するパラメータ（不具合発生確認パラメータ）をデバイス１２から受信したか否かを判定する。すなわち、上述のステップ１１８によりデバイス１２から返送されたパラメータを受信したか否かを判定する。該判定が肯定された場合にはステップ２１０へ移行し、否定された場合にはそのまま一連の処理を終了する。

ステップ２１０では、ＣＰＵ１６Ａが、不具合発生確認パラメータより不具合発生リスクを診断してステップ２１２へ移行する。

ステップ２１２では、ＣＰＵ１６Ａが、不具合発生リスクの診断結果が問題なしか否かを判定し、該判定が肯定された場合にはステップ２１４へ移行し、否定された場合には一連の処理を終了する。

ステップ２１４では、ＣＰＵ１６Ａが、停止解除信号及び診断結果をデバイス１２に送信して一連の処理を終了する。

なお、ステップ２０８は第２受信部に対応し、ステップ２１４は送信制御部に対応する。

ここで、上述の不具合問い合わせ対応処理の詳細について説明する。図１１は、不具合問い合わせ対応処理の流れの一例を示すフローチャートである。

ステップ２５０では、ＣＰＵ１６Ａが、デバイス１２から不具合発生状況の問い合わせを受信したか否かを判定する。すなわち、上述のステップ１５０によりデバイス１２により不具合発生状況の問い合わせが行われたか否かを判定する。該判定が肯定された場合にはステップ２５２へ移行し、否定された場合には不具合問い合わせ対応処理をリターンして上述のステップ２０８へ移行する。

ステップ２５２では、ＣＰＵ１６Ａが、管理対象のデバイス１２の不具合の発生状況を確認してステップ２５４へ移行する。

ステップ２５４では、ＣＰＵ１６Ａが、不具合発生状況の問い合わせ元のデバイス１２から送付された特定情報に対応する種別のデバイス１２に不具合が発生しているか否かを判定する。該判定は、上述のステップ１０４において、不具合発生状況の問い合わせ元から送付された特定情報に対応するデバイス１２から不具合の種別が通知されているか否かを判定する。該判定が否定された場合にはステップ２５６へ移行し、肯定された場合にはステップ２５８へ移行する。

ステップ２５６では、ＣＰＵ１６Ａが、不具合発生なしとして、不具合が発生していないことを表す情報を不具合発生状況の問い合わせ元のデバイス１２に送信して一連の不具合問い合わせ対応処理をリターンして上述のステップ２０８へ移行する。

一方、ステップ２５８では、ＣＰＵ１６Ａが、同仕様デバイス特定パラメータリストをデバイス１２に送信してステップ２６０へ移行する。これにより、上述のステップ１５４の判定が肯定される。

ステップ２６０では、ＣＰＵ１６Ａが、同仕様デバイス特定パラメータリストに対するパラメータ（同仕様デバイス特定パラメータ）をデバイス１２から受信したか否かを判定する。すなわち、上述のステップ１５６によりデバイス１２から送信された同仕様デバイス特定パラメータを受信したか否かを判定する。該判定が肯定されるまで待機してステップ２６２へ移行する。

ステップ２６２では、ＣＰＵ１６Ａが、デバイス１２から受信した同仕様デバイス特定パラメータから同じ仕様を持つデバイス１２であるか否かを特定してステップ２６４へ移行する。

ステップ２６４では、ＣＰＵ１６Ａが、特定した結果が同仕様のデバイス１２であるか否かを判定し、該判定が肯定された場合にはステップ２６６へ移行し、否定された場合には不具合問い合わせ対応処理をリターンして上述のステップ２０８へ移行する。

ステップ２６６では、ＣＰＵ１６Ａが、ステップ２０５において生成した不具合発生確認パラメータリストと、停止信号を不具合発生状況問い合わせ元のデバイス１２に送信し、不具合問い合わせ対応処理をリターンして上述のステップ２０８へ移行する。

なお、ステップ２５０、２６０は第２受信部に対応し、ステップ２５２、２５４、２６６は送信制御部に対応し、ステップ２５８は信号送信部に対応する。

以上のようにデバイス１２及び管理サーバ１６の各々が処理を行うことで、上述した図８に示すように、デバイス１２が管理サーバ１６に対して不具合の問い合わせを行うように構成した場合の不具合検証の際の信号の授受が行われる。

なお、上記の実施形態では、デバイス１２として画像形成装置を適用した例を説明したが、これに限るものではない。例えば、画像を読み取る機能のみを有する画像読取装置１７を適用してもよい。或いは、プリンタ、コピー、スキャナ、ファクシミリなどの複数の機能のうち少なくとも１以上の機能を備えたものを適用してもよい。

また、上記の実施形態に係るデバイス１２及び管理サーバ１６で行われる処理は、ソフトウエアで行われる処理としてもよいし、ハードウエアで行われる処理としてもよいし、双方を組み合わせた処理としてもよい。また、これらの各処理は、プログラムとして記憶媒体に記憶して流通させるようにしてもよい。

また、本発明は、上記に限定されるものでなく、上記以外にも、その主旨を逸脱しない範囲内において種々変形して実施可能であることは勿論である。

１０ 画像処理システム
１２ デバイス
１４ 情報処理装置
１６ 管理サーバ
１８ 通信回線
２０ コントロール・ユニット
２２ ユーザインタフェース

Claims (24)

1. 予め定めた管理装置から不具合による停止信号を受信する受信部と、
   前記受信部によって前記停止信号を受信した場合に、前記管理装置との通信に必要な機能以外の機能を停止させる停止制御を行う制御部と、
   を含む画像処理装置。
2. 不具合が発生した場合に、前記管理装置に不具合の種別を通知する通知部を更に含む請求項１に記載の画像処理装置。
3. 前記通知部が通知した前記種別に対応する、不具合の発生状況を把握するための把握情報を収集し、前記管理装置に送信する送信部を更に含む請求項２に記載の画像処理装置。
4. 前記受信部は、前記種別に対応する不具合の発生状況を把握するための把握リストを前記管理装置から更に受信し、
   前記送信部は、前記受信部によって受信した前記把握リストに従って前記把握情報を収集して前記管理装置に送信する請求項３に記載の画像処理装置。
5. 前記受信部は、前記把握情報から生成された、同じ不具合が発生するか否かを確認するための確認リストを前記管理装置から更に受信し、
   前記送信部は、前記受信部によって受信した前記確認リストに従って同じ不具合が発生するか否かを確認するための確認情報を収集して前記管理装置に更に送信する請求項４に記載の画像処理装置。
6. 前記受信部は、前記確認情報を用いて診断した不具合の診断結果を前記管理装置から更に受信し、
   前記制御部は、前記診断結果が問題ない場合に、前記機能の停止を解除し、問題がある場合は、前記機能の停止を継続する制御を行う請求項５に記載の画像処理装置。
7. 前記受信部は、停止解除信号を前記管理装置から更に受信し、
   前記制御部は、前記停止解除信号を受信した場合に、機能の停止を解除する制御を更に行う請求項１〜６の何れか１項に記載の画像処理装置。
8. 前記停止制御によって機能を停止する際に当該機能が動作中であった場合、前記機能の停止を解除する制御を行う際に、前記機能の動作再開の可否を受け付ける受付部を更に含み、
   前記制御部は、前記受付部によって前記動作再開の指示を受け付けた場合に、機能の動作を再開させる制御を行う請求項７に記載の画像処理装置。
9. 前記管理装置に対して画像処理装置の種別を特定するための特定情報を送信して不具合発生状況の問い合わせを行う問い合わせ部を更に含み、
   前記受信部は、前記問い合わせ部によって前記不具合発生状況の問い合わせた結果として前記停止信号を受信する請求項１に記載の画像処理装置。
10. 前記受信部は、不具合が発生している場合に、自装置の不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを確認するためのデバイス確認リストを更に受信し、
    前記デバイス確認リストに従って前記同じ仕様を持つ画像処理装置であるかを確認するためのデバイス確認情報を収集して前記管理装置に返信する返信部を更に含む請求項９に記載の画像処理装置。
11. 前記受信部は、前記停止信号と共に、同じ不具合が発生するか否かを確認するための確認リストを更に受信し、
    前記返信部は、前記受信部によって受信した前記確認リストに従って同じ不具合が発生するか否かを確認するための確認情報を収集して前記管理装置に更に返信する請求項１０に記載の画像処理装置。
12. 管理対象の複数の画像処理装置の不具合の発生の有無を検出する検出部と、
    前記検出部によって不具合の発生が検出された場合、不具合が発生した画像処理装置の仕様を持つ画像処理装置に対して、通信に必要な機能以外の機能を停止する停止信号を送信する信号送信部と、
    を含む情報処理装置。
13. 前記検出部は、不具合が発生した画像形成装置からの不具合の種別の通知により、前記複数の画像処理装置の不具合の発生を検出する請求項１２に記載の情報処理装置。
14. 不具合が発生した画像処理装置が収集した、前記種別に対応する不具合の発生状況を把握するための把握情報を受信する第１受信部を更に含む請求項１３に記載の情報処理装置。
15. 前記信号送信部は、前記種別に対応する不具合の発生状況を把握するための把握リストを不具合が発生した画像処理装置に更に送信し、
    前記第１受信部は、前記把握リストに従って収集された把握情報を受信する請求項１４に記載の情報処理装置。
16. 前記信号送信部は、前記把握情報から同じ不具合が発生するか否かを確認するための確認リストを生成し、前記管理対象の複数の画像処理装置に更に送信し、
    前記第１受信部が、前記確認リストに従って収集された確認情報を更に受信する請求項１５に記載の情報処理装置。
17. 前記第１受信部が受信した前記確認情報を用いて不具合の診断を行い、診断結果を返信する診断返信部を更に含む請求項１６に記載の情報処理装置。
18. 前記診断返信部は、前記診断結果が問題ない場合、機能の停止を解除する停止解除信号を更に返信する請求項１７に記載の情報処理装置。
19. 前記複数の画像処理装置から、画像処理装置の種別を特定するための特定情報と共に不具合の問い合わせを受信する第２受信部と、
    前記第２受信部が前記問い合わせを受信した場合、不具合の発生状況を確認し、不具合の発生が確認された場合に、前記信号送信部による前記停止信号の送信を制御する送信制御部と、を更に含む請求項１２に記載の情報処理装置。
20. 前記信号送信部は、不具合が発生している場合に、前記第２受信部が受信した前記問い合わせを行った画像処理装置に対して、不具合が発生した画像処理装置と同じ仕様を持つ画像処理装置であるか否かを確認するためのデバイス確認リストを更に送信し、
    前記第２受信部が、前記デバイス確認リストに従って収集したデバイス確認情報を更に受信する請求項１９に記載の情報処理装置。
21. 前記信号送信部は、前記デバイス確認情報が前記同じ仕様を持つ画像処理装置を表す場合に、前記停止信号と共に、同じ不具合が発生するか否かを確認するための確認リストを更に送信し、
    前記第２受信部は、前記確認リストを用いて同じ不具合が発生するか否かを確認した発生確認結果を更に受信し、
    前記送信制御部は、前記発生確認結果が同じ不具合が発生することを表す場合に、前記信号送信部による前記停止信号の送信を制御する請求項２０に記載の情報処理装置。
22. 請求項１〜１１の何れか１項に記載の画像処理装置と、
    請求項１２〜２１の何れか１項に記載の情報処理装置と、
    前記画像処理装置と前記情報処理装置とを通信接続する通信回線と、
    を含む画像処理システム。
23. コンピュータを、請求項１〜１１の何れか１項に記載の画像処理装置を構成する各部として機能させるための画像処理プログラム。
24. コンピュータを、請求項１２〜２１の何れか１項に記載の情報処理装置を構成する各部として機能させるための情報処理プログラム。