特許 7493950 情報処理装置、情報処理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-24

(45)【発行日】2024-06-03

(54)【発明の名称】情報処理装置、情報処理方法及びプログラム

(51)【国際特許分類】

   H04L 67/00 20220101AFI20240527BHJP

   B41J 29/38 20060101ALI20240527BHJP

   G06F 11/36 20060101ALI20240527BHJP

【ＦＩ】

H04L67/00

B41J29/38 401

G06F11/36 160

【請求項の数】 10

(21)【出願番号】P 2020020922

(22)【出願日】2020-02-10

(65)【公開番号】P2021128381

(43)【公開日】2021-09-02

【審査請求日】2023-02-02

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100114775

【弁理士】

【氏名又は名称】高岡 亮一

(74)【代理人】

【識別番号】100121511

【弁理士】

【氏名又は名称】小田 直

(74)【代理人】

【識別番号】100208580

【弁理士】

【氏名又は名称】三好 玲奈

(72)【発明者】

【氏名】馬場 翔平

【審査官】中川 幸洋

(56)【参考文献】

【文献】特開２０１３－０６５２２３（ＪＰ，Ａ）

【文献】特開２０１９－１６４５１８（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１１／０２８３３５１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／０３５２７７０（ＵＳ，Ａ１）

【文献】特開２０１８－１３６８７６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ６７／００

Ｂ４１Ｊ ２９／３８

Ｇ０６Ｆ １１／３６

(57)【特許請求の範囲】

【請求項1】

複数のネットワークデバイスを監視する情報処理装置であって、
監視の対象となるネットワークデバイスの登録情報が第１の情報であることに従い、前記情報処理装置から要求することで当該ネットワークデバイスから稼働情報を取得して、該取得された稼働情報を、ネットワークを介して管理サーバに送信する監視手段と、
ネットワークデバイスから前記管理サーバへの情報の送信に際して、当該ネットワークデバイスにとってのプロキシサーバとして動作するためのプロキシ手段と、
監視の対象となるネットワークデバイスの登録情報が前記第１の情報とは異なる第２の情報であることに従い、前記プロキシ手段が前記プロキシサーバとして正常に動作しているかを確認する確認手段と、を有し、
前記第２の情報は、前記監視手段の取得の対象となる稼働情報を、前記情報処理装置からの要求ではなく、前記プロキシサーバを経由してネットワークデバイスから前記管理サーバへ送信する設定に対応する情報であることを特徴とする情報処理装置。

【請求項2】

前記確認手段は、周期的に、前記プロキシ手段が前記プロキシサーバとして正常に動作しているかを確認し、前記プロキシサーバが停止していた場合には前記プロキシ手段の再起動を実行することを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記稼働情報を前記管理サーバへ送信する機能を備えたネットワークデバイスについて、該ネットワークデバイスの登録情報を前記第１の情報から前記第２の情報に書き換えることを特徴とする請求項１に記載の情報処理装置。

【請求項4】

前記プロキシサーバとしての動作が異常と判断された場合に、前記ネットワークデバイスが稼働情報の送信時に参照する前記ネットワークデバイスのプロキシサーバの設定を空に変更するための指示を送信する、設定変更手段をさらに有することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。

【請求項5】

前記プロキシサーバとしての動作が異常と判断された場合に、前記ネットワークデバイス自身が稼働情報を生成して前記ネットワークデバイスにとってのプロキシサーバへ送信する機能を停止するための指示を送信する、自己監視停止手段をさらに有することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。

【請求項6】

前記確認手段は、自己装置内の前記プロキシ手段を介さずに前記管理サーバへデータを送信できたにも拘わらず当該プロキシ手段を介して前記管理サーバへデータを送信できなかった場合に、前記プロキシ手段が前記プロキシサーバとして正常に動作していないと判断することを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。

【請求項7】

前記確認手段は、前記プロキシ手段の負荷が所定の状態よりも高いと判断したときに、前記稼働情報のデータ量を低減するための指示を送信する、負荷低減手段をさらに有することを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。

【請求項8】

前記確認手段は、前記プロキシ手段の負荷が所定の状態よりも高いと判断したときに、複数の前記ネットワークデバイスの少なくとも一部が前記プロキシ手段を用いずに前記稼働情報を送信するための指示を送信する、送信変更手段をさらに有することを特徴とする請求項１乃至７の何れか１項に記載の情報処理装置。

【請求項9】

複数のネットワークデバイスを監視する情報処理装置による情報処理方法であって、
監視の対象となるネットワークデバイスの登録情報が第１の情報であることに従い、前記情報処理装置から要求することで当該ネットワークデバイスから稼働情報を取得して、該取得された稼働情報を、ネットワークを介して管理サーバに送信する監視工程と、
ネットワークデバイスから前記管理サーバへの情報の送信に際して、プロキシ手段を当該ネットワークデバイスにとってのプロキシサーバとして動作させるプロキシ工程と、
監視の対象となるネットワークデバイスの登録情報が前記第１の情報とは異なる第２の情報であることに従い、前記プロキシ手段が前記プロキシサーバとして正常に動作しているかを確認する確認工程と、を有し、
前記第２の情報は、前記監視工程における取得の対象となる稼働情報を、前記情報処理装置からの要求ではなく、前記プロキシサーバを経由してネットワークデバイスから前記管理サーバへ送信する設定に対応する情報であることを特徴とする情報処理方法。

【請求項10】

請求項１乃至８の何れか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、デバイスでのエラー処理や消耗品の補充等のデバイスメンテナンスを迅速に行うための、情報処理装置、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

従来より、オフィス等に設置したデバイス（例えば画像形成装置）のメンテナンスを、ネットワークを介して行うデバイス管理システムが知られている。デバイス管理システムを用いることで、例えば、デバイスに障害が発生したことや、消耗品の補充が必要になったこと等を、ネットワーク経由で検出して、迅速に対応することができる。デバイス管理システムを開示する文献としては、例えば下記特許文献１が知られている。

【0003】

従来のデバイス管理システムとして、各デバイスを一元的に管理する管理サーバーと、複数のデバイスから稼働情報を収集して該管理サーバーに転送する監視装置として動作する情報処理装置と、を含むものが、知られている。稼働情報とは、デバイスの障害や消耗品に関連する情報であるステータス情報や、カウンター情報、センサー情報、ログ情報等を含む情報である。稼働情報は、管理サーバが、デバイス管理サービスやデバイス保守サービス等を行うために、使用される。監視装置は、例えば定期的なポーリング等の方法を用いて、この稼働情報を各デバイスから取得する。

【0004】

デバイスで障害等が発生した場合、その障害等の種類等によっては、復旧作業を行うために作業員がデバイス設置場所へ出向く必要が生じる。このため、障害等の発生から復旧までの時間、すなわちダウンタイムを短縮するためには、デバイス管理システムの安定した稼働が望まれる。

【0005】

特許文献１のデバイス管理システムでは、監視装置が、その内部に、管理データ（稼働情報）の通信を中継するプロキシ機能（以下、単に「プロキシ」と称す）を有している。さらに、監視装置のプロキシを使用するための設定が、管理対象のデバイスに対しても成される。その結果、管理データは、監視装置のプロキシを経由して、デバイスから管理サーバーへ送られる。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２０１８－１３６８７６

【発明の概要】

【発明が解決しようとする課題】

【0007】

特許文献１が開示するシステムのように、監視装置のプロキシ機能を利用してデバイスを管理する場合、その監視装置のプロキシ機能が正常に動作していないと、管理サーバーで稼働情報を受信して、管理できない。

【0008】

また、監視装置がプロキシ機能を利用する場合、この監視クライアントのプロキシ設定に対応するように、デバイスのプロキシ設定がなされる。デバイスにプロキシ設定が１種類しかない場合などには、監視装置のプロキシ機能に不具合が生じると、その影響がデバイス内の該プロキシ設定を利用する他の機能に影響するおそれがある。

【0009】

本発明は、上記課題を解決するために成されたものであり、プロキシ機能を備える情報処理装置において、そのプロキシ機能に異常が発生したことを認識できる仕組みを提供することを目的とする。

【課題を解決するための手段】

【0010】

本発明の一実施形態に係る情報処理装置は、複数のネットワークデバイスを監視する情報処理装置であって、監視の対象となるネットワークデバイスの登録情報が第１の情報であることに従い、前記情報処理装置から要求することで当該ネットワークデバイスから稼働情報を取得して、該取得された稼働情報を、ネットワークを介して管理サーバに送信する監視手段と、ネットワークデバイスから前記管理サーバへの情報の送信に際して、当該ネットワークデバイスにとってのプロキシサーバとして動作するためのプロキシ手段と、監視の対象となるネットワークデバイスの登録情報が前記第１の情報とは異なる第２の情報であることに従い、前記プロキシ手段が前記プロキシサーバとして正常に動作しているかを確認する確認手段と、を有し、前記第２の情報は、前記監視手段の取得の対象となる稼働情報を前記情報処理装置からの要求ではなく、前記プロキシサーバを経由してネットワークデバイスから前記管理サーバへ送信する設定に対応する情報であることを特徴とする。

【発明の効果】

【0011】

本発明によれば、情報処理装置のプロキシ機能に異常が発生したことを認識できるといった効果がある。

【図面の簡単な説明】

【0012】

【図1】本発明の各実施形態に係る情報処理装置を含むデバイス管理システムのネットワーク構成を概略的に示す概念図である。

【図2】各実施形態に係る画像処理装置のハードウェア構成を概略的に示すブロック図である。

【図3】各実施形態に係る管理サーバ及び監視装置のハードウェア構成を概略的に示すブロック図である。

【図4】第１実施形態に係る管理サーバ及び監視装置のソフトウェア構成を概略的に示すブロック図である。

【図5】第１実施形態に係る監視装置の動作例を示すフローチャートである。

【図6】本発明の第２実施形態に係る管理サーバ及び監視装置のソフトウェア構成を概略的に示すブロック図である。

【図7】第２実施形態に係る画像処理装置のソフトウェア構成を概略的に示すブロック図である。

【図8】第２実施形態に係る監視装置の動作例を示すフローチャートである。

【図9】第２実施形態に係る監視装置のデバイス管理情報例を示す表である。

【図10】第３実施形態に係る監視装置の動作を示すフローチャートである。

【図11】第４実施形態に係る監視装置の動作を示すフローチャートである。

【発明を実施するための形態】

【0013】

以下、本発明の実施形態について、図面を参照して説明する。
［第１実施形態］
本発明の第１実施形態について、図１～５を参照して説明する。

【0014】

＜システム構成＞
図１は、本実施形態に係る管理システムのネットワーク構成を示す概念図である。
本実施形態の管理システムは、画像形成装置の管理を行うシステムであり、１又は複数台の画像形成装置１０１と、監視装置１０２と、管理サーバ１０３とを含む。

【0015】

図１において、画像形成装置１０１は、本発明の「ネットワークデバイス」に対応しており、本実施形態に係る管理システムの管理対象である。この画像形成装置１０１としては、例えば、コピーやプリント等のジョブを実行するデジタル複合機等を採用できる。また、画像形成装置１０１に代えて、単機能のプリンタやスキャナ、複写機、三次元プリンター等の、他のデバイスを採用してもよい。

【0016】

監視装置１０２は、例えばＬＡＮ(Local Area Network)１０５等のネットワークを介して、各画像形成装置１０１へ接続されている。そして、監視装置１０２は、各画像形成装置１０１から、稼働情報すなわち障害の発生や消耗品の補充等に関するデータを、取得する。監視装置１０２は、取得した稼働情報を、管理サーバ１０３へ送信する。

【0017】

管理サーバ１０３は、例えばＷＡＮ(Wide Area Network)１０４等のネットワークを介して、監視装置１０２へ接続されている。後述するように、管理サーバ１０３は、監視装置１０２と、各画像形成装置１０１とを、一元的に管理する。この管理には、監視装置１０２から受け取った稼働情報が使用される。管理サーバ１０３は、１台のコンピュータを含む構成でもよいし、複数のコンピュータを含む構成でもよい。さらには、管理サーバ１０３として、クラウドコンピューティング技術を用いたコンピュータを使用してもよい。なお、図１に示したように、管理サーバ１０３は、ＷＡＮ１０４及びＬＡＮ１０５を介して、画像形成装置１０１へ直接接続されていてもよい。

【0018】

＜画像形成装置のハードウエア構成＞
図２は、画像形成装置１０１のハードウエア構成の一例を概略的に示すブロック図である。
図２に示したように、本実施形態の画像形成装置１０１は、全体制御部２１１を有する。全体制御部２１１は、画像形成装置１０１に接続された外部機器２１２～２１５やネットワーク２１７（ＬＡＮ１０５等）とのインタフェースを制御すると共に、画像形成装置１０１全体の動作を制御する。

【0019】

ＣＰＵ２０１は、システム全体を制御するコントローラとして機能する。このために、ＣＰＵ２０１は、ＲＯＭ２０２やＨＤＤ２０５から制御プログラムを読み出す。ＨＤＤ２０５から制御プログラムを読み出す場合には、ディスクコントローラ（ＨＤＣ）２０４によって、読み出しが制御される。そして、ＣＰＵ２０１は、システムバス２０６を介して接続された、各部２０７～２１０、２１６を制御する。

【0020】

ＲＡＭ２０３は、ＣＰＵ３０１が制御プログラムを実行する際に、ワークエリアとして使用される。
リーダＩ／Ｆ２０７は、リーダ部２１２（後述）に接続されて、このリーダ部２１２の動作を制御する。

【0021】

プリンタＩ／Ｆ２０８は、プリンタ部２１３（後述）に接続されて、このプリンタ部２１３の動作を制御する。
操作部Ｉ／Ｆ２０９は、操作部２１４に接続されて、この操作部２１４から入力されたユーザ操作情報をＣＰＵ２０１へ送信する処理や、ＣＰＵ２０１から受け取った情報に基づいて操作部２１４の表示を制御する処理等を行う。

【0022】

スイッチＩ／Ｆ２１０は、スイッチ部２１５に接続されて、スイッチ部２１５のオン／オフ状態等をＣＰＵ２０１へ伝える。
リーダ部２１２は、リーダＩ／Ｆ２０７の制御に基づいて、原稿の画像を読み取る。そして、リーダ部２１２は、ユーザーからの指示に応じて、その原稿画像に対応する画像データをプリンタ部２１３に印刷出力させる処理や、ＨＤＤ２０５に保存する処理を行う。更には、リーダ部２１２が出力した画像データを、ネットワーク２１７を介して外部コンピュータ等へ送信する処理を行うことも可能である。

【0023】

プリンタ部２１３は、プリンタＩ／Ｆ２０８の制御に基づいて、リーダ部２１２により読み取られた原稿や、ＨＤＤ２０５から読み出された画像データを、印刷出力する。更に、プリンタ部２１３は、ネットワーク２１７を介して外部コンピュータ等から印刷ジョブを受信し、実行する。

【0024】

操作部２１４は、例えば、キーボード、ポインティングデバイス、表示デバイス等を含み、ユーザの操作入力の受け付けやユーザへの情報表示等を行う。また、操作部２１４は、タッチパネル付の表示デバイスでもよい。

【0025】

スイッチ部２１５は、ユーザが画像形成装置１０１を操作するためのスイッチ等の、オン／オフ状態を制御する。
ネットワーク（ＮＷ）Ｉ／Ｆ２１６は、ネットワーク２１７へ接続される。このネットワークＩ／Ｆ２１６を介して、全体制御部２１１は、とネットワーク２１７上の他の情報機器等と、相互通信を行う。

【0026】

＜監視装置及び管理サーバのハードウエア構成＞
図３は、監視装置１０２及び管理サーバ１０３のハードウエア構成例を概略的に示すブロック図である。このように、監視装置１０２と管理サーバ１０３とは、同じハードウエア構成を有する。

【0027】

図３において、通信Ｉ／Ｆ部３０１は、外部のシステムや装置等と通信を行うための、ネットワークインターフェースである。
記憶装置３０２は、ＯＳ（Operating System）や、プログラム、稼働情報、外部システムや装置等から収集したデータ等を格納する。

【0028】

ＣＰＵ３０３は、記憶装置３０２からメモリ３０４へプログラムをロードして、実行する。
すなわち、メモリ３０４は、ＣＰＵ３０３の作業用メモリとして使用される。
出力Ｉ／Ｆ部３０５は、表示デバイス等の出力装置に接続され、プログラム実行結果の出力等を行う。

【0029】

＜監視装置のソフトウエア構成＞
図４は、監視装置１０２のソフトウエア構成（機能構成）の一例を概略的に示すブロック図である。
図４において、取得部４０１は、画像形成装置１０１から稼働情報等のデータを取得する。
送信部４０２は、取得した稼働情報等を管理サーバ１０３へ送る。

【0030】

データ管理部４０３は、取得した稼働情報等を保存する処理や、管理対象となる画像形成装置１０１のデバイス情報を管理する処理等を行う。
プロキシサーバ４０４は、画像形成装置１０１と管理サーバ１０３との間のデータ通信を中継する。なお、このプロキシサーバ４０４に加えて、画像形成装置１０１と管理サーバ１０３との通信経路に他のプロキシサーバを設けてもよい。
監視部４０５は、プロキシサーバ４０４の稼働状態を監視することともに、プロキシサーバの開始処理や停止処理等を行う。

【0031】

＜監視装置の動作＞
図５は、監視装置１０２が監視部４０５が行う処理の一例を概略的に示すフローチャートである。
本実施形態では、監視部４０５が、所定の監視タイミングごとに、プロキシサーバ４０４の稼働状態を監視する。このため、監視部４０５は、時刻が監視タイミングに達するまで待機する（ステップＳ５０１）。時刻が監視タイミングに達した場合、処理はステップＳ５０２へ移行する。

【0032】

ここで、監視タイミングは、予め定めた時刻であってもよいし、前回の監視処理から所定時間経過後の時刻であってもよいし、他の基準で定めてもよい。
ステップＳ５０２で、監視部４０５は、プロキシサーバ４０４の稼働状態を確認する処理を実行する。

【0033】

そして、ステップＳ５０３で、監視部４０５は、稼働状態の確認結果に基づいて、プロキシサーバ４０４の動作／停止を判断する。プロキシサーバ４０４が動作している場合、処理は終了する。
一方、ステップＳ５０３でプロキシサーバ４０４が停止していると判断した場合、監視部４０５は、ステップＳ５０４で、プロキシサーバ４０４を再起動させる。

【0034】

以上説明したように、本実施形態では、監視部４０５が、監視装置１０２のプロキシサーバ４０４が動作しているか否かを、所定のタイミングで自動的に判断し、停止している場合にそのプロキシサーバ４０４を再起動する。このため、本実施形態によれば、プロキシサーバ４０４で異常が発生したことを、情報処理装置が認識できる。

【0035】

［第２実施形態］
上記第１実施形態では、監視装置１０２が自身のプロキシサーバ４０４を監視し、プロキシサーバ４０４が停止していた場合に再起動を行っていた。しかし、プロキシサーバ４０４の再起動が失敗する場合も想定される。本実施形態では、プロキシサーバ４０４の再起動が失敗した場合には、このプロキシサーバ４０４を使用せずに、画像形成装置１０１から管理サーバ１０３へのデータ送信を行うための構成を、上記第１実施形態の管理システムに追加した。

【0036】

以下、本発明の第２実施形態について、図面を参照しつつ説明する。
本実施形態に係る画像形成装置１０１、監視装置１０２及び管理サーバ１０３のネットワーク構成及びハードウエア構成は、上記第１実施形態と同様である（図１～図３参照）。その一方で、監視装置１０２及び管理サーバ１０３のソフトウエア構成は、以下の点で、第１実施形態と異なる。

【0037】

＜監視装置のソフトウエア構成＞
図６は、本実施形態の監視装置１０２に係るソフトウエア構成の一例を概略的に示すブロック図である。図６において、図４と同じ符号を附した構成要素は、それぞれ図４と同じものを示している。

【0038】

本実施形態の監視装置１０２は、デバイス管理部４０６を備えた点で、上記第１実施形態の監視装置１０２と異なる。このデバイス管理部４０６は、画像形成装置１０１のプロキシ設定の変更や、この画像形成装置１０１に設けられた自己監視機能（後述）の開始・停止処理等を行う。

【0039】

＜画像形成装置のソフトウエア構成＞
図７は、画像形成装置１０１の機能構成の一例を示すブロック図である。
図７において、受信部６０１は、外部装置からリクエストを受信する。リクエストとしては、例えば、画像形成装置１０１内の稼働情報等を自己監視部６０４（後述）に収集させる旨のリクエストがある。

【0040】

送信部６０２は、受信部６０１が受信したリクエストに対する応答を、監視装置１０２等へ送信する。
設定部６０３は、プロキシの設定等、監視装置１０２等から指定された情報に基づく各種設定を行う。

【0041】

自己監視部６０４は、画像形成装置１０１内の状態を監視する。そして、自己監視部６０４は、その監視結果を示すデータのうち、監視装置１０２から指定されたデータを、予め定められたスケジュールに従って送信部６０２へ送り、監視装置１０２へ送信させる。

【0042】

＜監視装置の動作＞
図８は、本実施形態に係る監視装置１０２の動作例を概略的に示すフローチャートである。
監視部４０５は、上記第１実施形態と同様、時刻が監視タイミングに達するまで待機したのち（ステップＳ５０１）、プロキシサーバ４０４の稼働状態を確認する（ステップＳ５０２）。監視部４０５は、プロキシサーバ４０４が稼働している場合は処理を終了し、停止している場合はこのプロキシサーバ４０４を再起動させる（ステップＳ５０４）。

【0043】

続いて、監視部４０５は、プロキシサーバ４０４が再起動に成功したか否かを確認する（ステップＳ７０１）。再起動が失敗した場合、処理はステップＳ７０６へ進む。
一方、再起動できた場合、ステップＳ７０２で、データ管理部４０３が、管理対象の画像形成装置１０１の中から、自己監視部６０４を備えているにも拘わらずポーリングによってデータを収集している画像形成装置を探す。

【0044】

上述のように、自己監視部６０４を有している場合、画像形成装置１０１は、その画像形成装置１０１自身の制御に基づいて稼働情報を収集し、監視装置１０２のプロキシサーバ４０４を介して管理サーバー１０３へ送信することができる。但し、自己監視部６０４を使用しない設定となっている場合、画像形成装置１０１は、自身の制御で稼働情報を収集せずに、監視装置１０２のポーリング機能に応答してデータを送信する。また、自己監視部６０４を備えていないために、自身の制御で稼働情報を収集できない画像形成装置（ポーリング機能に応答したデータ送信のみ可能な画像形成装置）が、管理システムの管理下に置かれている場合もある。

【0045】

図９は、管理情報テーブル、すなわち画像形成装置を管理する情報を登録するテーブルの一例を示す。この管理情報テーブルは、監視装置１０２のデータ管理部４０３によって管理される。

【0046】

図９において、「デバイスＩＤ」は、システム内で画像形成装置を一意に識別するための情報である。
「シリアルＮｏ」は、同一の製造業者等が提供した製品群の中から、その画像形成装置を一意に識別するための情報である。
「ＩＰアドレス」は、各画像形成装置に割り当てられたＩＰアドレスである。

【0047】

「自己監視機能」は、各画像形成装置が自己監視機能を有するか否か（自己監視部６０４を有するか否か）を示す情報である。
「管理方法」は、監視装置１０２において、自己監視部６０４を用いた管理をしているのか或いは定期的なポーリングで稼働情報を収集して管理しているのかの区別を示す情報である。

【0048】

図９に示した各情報は、各画像形成装置を管理対象として登録する際に、その画像形成装置から取得した情報に基づいて判断して登録する。なお、図９に示した各情報とは異なる種類の情報を用いて、画像形成装置を管理してもよいことはもちろんである。

【0049】

図８のフローチャートへ戻る。ステップＳ７０２で、自己監視部６０４を備えるがポーリングで稼働情報を収集する画像形成装置が見つかった場合、監視装置１０２のデータ管理部４０３は、プロキシサーバ４０４のプロキシ情報を、その画像形成装置の設定部６０３へ通知する。そして、この設定部６０３が、このプロキシ情報に基づいて、画像形成装置１０１のプロキシ設定を行う（ステップＳ７０３）。

【0050】

次に、監視装置１０２のデバイス管理部４０６が、画像形成装置１０１の自己監視部６０４へ、自己監視動作の開始を指示する（ステップＳ７０４）。
その後、監視装置１０２のデータ管理部４０３が、管理情報テーブル（図９参照）の登録情報のうち、対応する画像形成装置１０１の「管理方法」欄を、「ポーリング」から「プロキシ経由」へ書き換える（ステップＳ７０５）。

【0051】

ステップＳ７０３～Ｓ７０５の処理は、自己監視部６０４を備えているがポーリングで稼働情報を収集している画像形成装置全てについて、実行される。
一方、ステップＳ７０１で、プロキシサーバ４０４の再起動が失敗したと判断した場合、データ管理部４０３は、管理対象の画像形成装置の中から、プロキシサーバ４０４を用いた管理を行っている画像形成装置１０１を探す（ステップＳ７０６）。

【0052】

そして、管理にプロキシサーバ４０４を用いている画像形成装置１０１が見つかると、デバイス管理部４０６は、「空」の設定を、その画像形成装置１０１の設定部６０３に通知する。「空」の設定とは、その画像形成装置１０１が管理対象として登録される前に設定されていたプロキシ情報である。そして、この設定部６０３が、このプロキシ情報に基づいて、画像形成装置１０１のプロキシ設定を行う（ステップＳ７０７）。なお、登録前のプロキシ情報とは、画像形成装置１０１が監視装置１０２のプロキシサーバ４０４を経由しないで通信を行うためのプロキシ情報である。このようなプロキシ情報は、例えば、その画像形成装置１０１を管理対象に設定する際に、画像形成装置１０１から取得して、保存しておけばよい。

【0053】

次に、監視装置１０２のデバイス管理部４０６が、画像形成装置１０１の自己監視部６０４へ、自己監視動作の停止を指示する（ステップＳ７０８）。
その後、監視装置１０２のデータ管理部４０３が、管理情報テーブル（図９参照）の登録情報のうち、対応する画像形成装置１０１の「管理方法」欄を、「プロキシ経由」から「ポーリング」へ書き換える（ステップＳ７０９）。

【0054】

ステップＳ７０７～Ｓ７０９の処理は、プロキシサーバ４０４を用いた管理を行っている画像形成装置全てについて、実行される。
以上示したように、本実施形態では、監視装置１０２のプロキシサーバ４０４が再起動に失敗した場合、このプロキシサーバ４０４を使用しない設定に、画像形成装置１０１を戻すことができる。これにより、本実施形態によれば、プロキシサーバ４０４が正常動作状態へ復帰できない場合に、ポーリングによる管理に切り換えることができる。

【0055】

［第３実施形態］
本実施形態に係る画像形成装置１０１、監視装置１０２及び管理サーバ１０３のネットワーク構成、ハードウエア構成及びソフトウエア構成は、上記第１実施形態とほぼ同じである（図１～図４参照）。但し、監視装置１０２の動作が、以下の点で、第１実施形態と異なる。

【0056】

上記第１実施形態では、プロキシサーバ４０４の正常／異常を判定するために、このプロキシサーバ４０４が稼働しているか否かをチェックすることとした（図５のステップＳ５０２、Ｓ５０３参照）。

【0057】

しかし、稼働はしていても、そのプロキシサーバ４０４の内部的な不具合により、正常に動作していない場合が考えられる。
これに対して、本実施形態では、第１実施形態と同様の処理（図５参照）に代えて、或いは、第１実施形態と同様の処理に加えて、以下のような処理を行う。

【0058】

＜監視装置の動作＞
図１０は、本実施形態に係る監視装置１０２の動作例を概略的に示すフローチャートである。
監視部４０５は、所定の監視タイミングごとに、プロキシサーバ４０４の稼働状態を監視する。このため、監視部４０５は、時刻が監視タイミングに達するまで待機する（ステップＳ９０１）。時刻が監視タイミングに達した場合、処理はステップＳ９０２へ移行する。

【0059】

ここで、監視タイミングは、予め定めた時刻であってもよいし、前回の監視処理から所定時間経過後の時刻であってもよいし、他の基準で定めてもよい。
ステップＳ９０２で、監視部４０５は、管理サーバ１０３に対して、プロキシサーバ４０４を経由した通信を行う。

【0060】

続いて、ステップＳ９０３において、監視部４０５は、ステップＳ９０２の通信が成功したか否かを判断する。そして、通信に成功した場合は、処理を終了する。
一方、ステップ９０３で通信が失敗したと判断した場合、ステップＳ９０４で、監視部４０５は、管理サーバ１０３に対して、プロキシサーバ４０４を経由しない通信を行う。

【0061】

次に、ステップＳ９０５において、監視部４０５は、ステップＳ９０２の通信が成功したか否かを判断する。
ステップＳ９０５で通信に成功したと判断した場合、監視部４０５は、プロキシサーバ４０４を再起動する（ステップＳ９０６）。

【0062】

一方、ステップＳ９０５で通信に失敗したと判断した場合、監視部４０５は、例えば監視装置１０２の管理画面（図示せず）にメッセージを表示することにより、システム管理者に、管理サーバ１０３と接続できないことを通知する（ステップＳ９０７）。なお、管理者への通知方法は特に限定されず、メール通知等であってもよい。

【0063】

以上示したように、本実施形態では、プロキシサーバ４０４の正常／異常を、通信を行えるか否かで判断することとした。このため、本実施形態によれば、プロキシサーバ４０４が内部的な不具合を起こしている場合であっても、その状態を自動的に検知することができる。

【0064】

［第４実施形態］
本実施形態の監視装置１０２は、上記第２実施形態と同様、画像形成装置１０１を管理するためのデバイス管理部４０６を有する（図６参照）。但し、後述するように、デバイス管理部４０６が行う処理の内容は、上記第２実施形態と異なる（図１１参照）。

【0065】

監視装置１０２の他の構成や、画像形成装置１０及び管理サーバ１０３の構成、ネットワーク全体の構成等は、上記第１実施形態とほぼ同じである（図１～図４参照）。
上記各実施形態では、プロキシサーバ４０４の稼働状態が正常か否かを、定期的に確認することとした。

【0066】

これに対して、本実施形態では、プロキシサーバ４０４に異常が発生し易い状態になることを防ぐための制御を設けた。
例えば、画像形成装置１０１と管理サーバ１０３との間の通信データ量が増大すると、プロキシサーバ４０４の負荷が高くなって、異常が発生し易くなる。

【0067】

＜監視装置の動作＞
図１１は、本実施形態に係る監視装置１０２の動作例を概略的に示すフローチャートである。
上述の各実施形態と同様、本実施形態でも、監視部４０５は、所定の監視タイミングごとに、プロキシサーバ４０４の稼働状態を監視する。このため、監視部４０５は、時刻が監視タイミングに達するまで待機する（ステップＳ１００１）。時刻が監視タイミングに達した場合、処理はステップＳ１００２へ移行する。上記各実施形態と同様、監視タイミングは限定されない。

【0068】

ステップＳ１００２で、監視部４０５は、プロキシサーバ４０４の負荷の高さを確認する。プロキシサーバ４０４の負荷は、そのプロキシサーバ４０４のＣＰＵ使用率やメモリ使用率、単位時間当たりのコネクション数等の情報に基づいて数値化できる。そして、その数値を所定の基準値と比較することで、負荷が高いか否かを判断する。なお、負荷の数値化に使用する情報としては、これら情報の一部のみを使用してもよいし、これら情報に代えて、或いは追加して、他の情報を使用してもよい。

【0069】

ステップＳ１００２で、プロキシサーバ４０４の負荷が基準値より低い場合、監視部４０５は処理を終了する。
一方、ステップＳ１００２で、プロキシサーバ４０４の負荷が基準値を超えていた場合、監視装置１０２のデバイス管理部４０６が、画像形成装置１０１の自己監視部６０４に対して、監視情報の設定変更を指示する。

【0070】

例えば、自己監視部６０４が、緊急度の高い情報のみ監視するように設定を変更すれば、管理サーバ１０３へ送信する稼働情報のデータ量（すなわちプロキシサーバ４０４が中継するデータ量）が減って、そのプロキシサーバ４０４の負荷が低減する。緊急度が高い情報とは、例えば、画像形成装置１０１のエラーや、消耗品の補充に関する情報である。それ以外の情報、すなわち緊急度が高くない情報については、例えば、監視装置１０２の取得部４０１が定期的にポーリング取得を行って、管理サーバ１０３へ送信すればよい。

【0071】

以上示したように、本実施形態によれば、プロキシサーバ４０４の負荷の高低に応じて自己監視部６０４からの送信データ量を抑制することとしたので、このプロキシサーバ４０４の通信データ量の過多に起因して発生する異常を減らすことが可能になる。

【0072】

なお、自己監視部６０４からの送信データ量を抑制する方法は、本実施形態の方法に限定されない。例えば、複数の画像形成装置１０１のうちの一部について、自己監視部６０４からの送信するデータを、プロキシサーバ４０４を経由させるのではなく、監視装置１０２がＷｅｂサーバとして機能して受信してもよい。これにより、プロキシサーバ４０４が扱うデータ量を抑制できる。

【符号の説明】

【0073】

１０１ 画像形成装置
１０２ 監視装置
１０３ 管理サーバ
１０４ ＷＡＮ(Wide Area Network)
１０５ ＬＡＮ(Local Area Network)
２１７ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】