JP6128962B2 - 管理装置、その制御方法およびプログラム - Google Patents

Description

本発明は、画像形成装置をはじめとするネットワーク機器上で発生した障害情報などを含む稼働情報の管理する技術に関する。

従来から、特許文献１にあるように、ネットワーク機器を管理する管理装置は、管理対象のネットワーク機器で発生したアラームなどを含む障害情報などを、機器の稼働情報として収集し、データベースに保存している。そして、管理装置のオペレーターでもあるネットワーク機器の管理者は、ネットワークで接続された外部ＰＣなどから専用のツールなどを用いて管理装置に対して特定の稼働情報を要求できる。管理装置は、この要求を受信すると、自身のデータベースに保存された特定の稼働情報（例えば、アラームの一覧）を検索して、外部ＰＣに返却する。外部ＰＣでは、稼働情報を要求する際に、ネットワーク機器を特定するためのパラメータや、アラームの発生期間を特定するためのパラメータを指定可能である。

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

ここで、管理対象のネットワーク機器で、異常な数のアラームが発生する場合などがある。こういった場合には、前述した外部ＰＣからの要求に対して、管理装置が異常な数のアラームの情報を返却しようとする。しかしながら、このような場合には、アラームの検索や、異常な数のアラームの情報のネットワーク上の通信などにより、外部ＰＣに対して迅速にアラーム情報を返却できない場合がある。このような場合は、管理者にサーバーへのアクセスで障害が起きたのか不安を与えたりするので、ある程度レスポンスタイムの性能はシステムとして担保する必要がある。ここで、検索結果にある程度の上限を設けて、上限以上の検索結果が予想されるパラメータが指定された要求に対しては、外部ＰＣ上で入力エラーとし、未然に前述した返却に時間がかかる状態を防ぐといった方法が考えられる。

しかしながら、大量に発生するアラームの種類は、管理対象のネットワーク機器ごとに傾向があり、絞り込みのためのパラメータ指定の仕方によっては、必ずしも前述の上限を超えるような検索結果とならない場合が考えられる。

そこで、本発明では、アラームの種類などのパラメータ指定をさらに考慮して入力エラーとする条件を例外的に緩和することで、先行技術に比べて、管理装置で管理されている稼働情報を外部ＰＣからより柔軟に要求することができる仕組みを提供することを目的とする。

上記課題を解決するために、本発明の管理装置は、ネットワークを介して管理対象の複数のネットワーク機器から収集した稼働情報を、記憶部を用いて管理する管理装置であって、ネットワークを介して接続される外部の情報処理装置から、稼働情報の取得要求を受け付ける受け付け手段と、前記取得要求に稼働情報の種類を示すパラメータが指定されているか否かを判定する第１の判定手段と、前記第１の判定手段により前記取得要求に稼働情報の種類を示すパラメータが指定されていると判定された場合に、当該指定されたパラメータが例外コードであるか否かを判定する第２の判定手段と、前記第１の判定手段により前記取得要求に稼働情報の種類を示すパラメータが指定されていないと判定された場合、または、前記第２の判定手段により前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードであると判定された場合に、第１の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第３の判定手段と、前記第２の判定手段により前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードではないと判定された場合、第１の条件よりも条件が緩和された第２の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第４の判定手段と、前記第３の判定手段または前記第４の判定手段により入力エラーとすべきではないと判定された場合に、前記取得要求で指定された複数のパラメータに対応する稼働情報を、前記記憶部から検索する検索手段と、前記取得要求の応答として、前記検索手段による検索結果を、前記外部の情報処理装置に対して送信する送信手段と、を有し、前記送信手段は、前記第３の判定手段または前記第４の判定手段により入力エラーとすべきと判定された場合に、前記取得要求の応答として、入力エラーを前記外部の情報処理装置に対して送信することを特徴とする。

本発明によれば、管理装置で管理されている稼働情報を外部ＰＣからより柔軟に要求することができる。

管理装置１０４を含むネットワーク構成の例を示す図。 ネットワーク機器のハードウェア構成の例を示す図。 管理装置などの情報処理装置のハードウェア構成の例を示す図。 各機器の処理モジュールの構成例を示す図である。 管理装置でアラームを管理するために用いるテーブルの内容を示す図。 実施例１における、管理装置１０４によるアラーム履歴の取得要求の入力パラメータの検査処理について説明するためのフローチャートである。 実施例２における、管理装置１０４によるアラーム履歴の取得要求の入力パラメータの検査処理について説明するためのフローチャートである。 取得要求の際に入力されるパラメータを説明するための図。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

［実施例１］
図１では、実施例１における管理装置１０４を含むネットワーク構成の例について説明する。管理装置がネットワーク１０１とインターネット１０５を介して、中継機器１０２や管理対象のネットワーク機器１０３と通信するための構成となっている。また、管理装置１０４には、クライアント装置１００も通信可能に接続されている。

管理装置１０４は、複数の顧客の環境に設置されたネットワーク機器１０３を集中管理するサーバーであり、インターネット１０５上に設置される。管理装置１０４、図示した通り、各顧客環境に設置された中継機器１０２を介して１以上の管理対象のネットワーク機器１０３の機器情報や稼働情報を収集することで遠隔でそれら機器の管理を行う。また、不図示ではあるが、管理装置１０４が中継機器を介さずに、ネットワーク１０１とインターネット１０５を経由して、管理対象のネットワーク機器１０３の機器情報や稼働情報を収集することも可能である。

ネットワーク機器１０３は、プリンターや複写機などを含む画像形成装置である。中継機器１０２は、ネットワーク機器１０３から、カウンタ情報やアラーム情報などの稼働情報を取得し、管理装置１０４へ送信する装置である。図中には示していないが、中継機器１０２は、複数のネットワーク機器１０３を管理することが可能である。

クライアント装置１００は、ネットワークを介して、管理装置１０４に対して所望のデータの取得要求を行なうことができる。取得対象のデータとしては、管理装置１０４で管理されているネットワーク機器１０３における印刷枚数などのカウンタ情報や、機器上で発生したアラーム情報などの障害情報などが含まれる。

図１において、システム全体が４つの装置から構成されているが、これは必ずしも４つの装置である必要はない。例えば、管理装置１０４は、機能ごとに複数の装置で構成されていてもよい。また、クライアント装置１００は、必ずしもパーソナルコンピュータである必要はなく、携帯端末などの同機能を持つ情報端末でもよい。

図２は、ネットワーク機器１０３のハードウェア構成の例を示すブロック図である。

ネットワーク機器１０３は、画像処理ユニット２００、ＣＰＵ２０１、主記憶装置２０２、２次記憶装置２０３、ユーザーインターフェース２０４、外部インターフェース２０５、印刷ユニット２０６、読み込みユニット２０７から構成されている。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、所定のプログラムを実行し、画像処理装置１０４、１０５の各種制御を指示するユニットである。主記憶部２０２は、ＣＰＵ２０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０１が実行するプログラムは主記憶装置２０２にロードされる。２次記憶装置２０３は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などにより実現され、アプリケーションプログラムが記憶されている。２次記憶装置２０３に記憶されている各種プログラムは、ＣＰＵ２０１がプログラムを実行する際に２次記憶装置２０３にロードされる。２次記憶装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により実現される。２次記憶装置２０３には、不図示のセンサなどから得られたカウンタ情報や障害情報などを記録される。外部インターフェース２０５は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっており、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのプロトコルを介して、２次記憶装置２０３に記録された各種稼働情報を外部に提供できる。例えば、外部装置としては、外付けＨＤＤやＵＳＢメモリなどの外部記憶装置やネットワークを介して接続されたコンピューターや、デバイスなどが含まれる。

次に、図３を用いて、管理装置１０４などを含む情報処理装置のハードウェア構成の例について説明する。

情報処理装置は、ＣＰＵ３００、主記憶装置３０１、２次記憶装置３０２、ユーザーインターフェース３０３、外部インターフェース３０４から構成されている。ＣＰＵ３００、主記憶装置３０１の詳細については、それぞれデバイス１０２、１０４が持つものと変わらないため説明を省略する。２次記憶装置３０２はアプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。２次記憶装置３０２はＲＯＭまたはＨＤＤ、ＳＳＤなどで構成され、管理対象となるネットワーク機器１０３の機器情報や稼働情報などを記憶することが可能である。ユーザーインターフェース３０３は、ユーザーの操作入力を受け付ける機能を持つユニットである。例えば、キーボード、マウス等を用いたユーザーの操作に応じた信号を受け付ける。外部インターフェース３０４は、ネットワーク１０１およびインターネット１０５に接続して、他の機器との通信を可能にする機能を持つ。

図４を用いて、管理装置１０４及びそれと連携する各装置が持つ機能について説明する。

はじめに、中継機器１０２のソフトウェア構成について説明する。本実施例では、管理装置１０４とネットワーク機器１０３間の通信が、顧客環境に配置された中継機器１０２によって行われる場合について説明する。

中継機器１０２は、送信部４２１と機器管理部４２２を持つ。中継機器１０２は、顧客環境に設置された１以上のネットワーク機器１０３を管理することができる。機器管理部４２２は、機器識別部４２３と稼働情報収集部４２４からなる。機器識別部４２３は、顧客環境に配置された各ネットワーク機器を識別し、一覧として管理する。稼働情報収集部４２４は各ネットワーク機器１０３からアラーム情報などの障害情報や、カウンタ情報や各種ログを収集する。稼働情報の収集方法は、ネットワーク機器１０３側が発生時に通知を行なう方法でもよいし、定期的にネットワーク機器１０３へ問い合わせを行なう方法でもかまわない。送信部４２１は、各ネットワーク機器１０３から受信したアラーム情報をはじめとする稼働情報を定期的に、もしくはネットワーク機器から通知を受けるたびに、管理装置１０４に送信する。

本実施例では、ネットワーク機器がプリンターや複写機などの画像形成装置であるとして、障害情報、特にアラームについての説明を行なう。ただし、本実施例は、本発明の代表的な実施形態を説明するものであり、本発明の適用範囲を限定するものではない。例えば、画像形成装置におけるアラームの種類としては、画像形成処理に使われる消耗品の残量に関する通知、画像形成処理の際に帯電する装置部品における電気の漏出に関する通知などがあげられる。

クライアント装置１００は、要求部４１１を持っており、管理装置１０４の管理する稼働情報の取得要求を送信し、返却された結果を受信できる。要求部４１１の実現形態としては、一般的なウェブブラウザでもかまわないし、アラーム情報の取得要求を行なうための専用のアプリケーションでもかまわない。

続いて、管理装置１０４のソフトウェアモジュールの構成例についても説明する。稼働情報管理部４０１は、稼働情報登録部４０２と稼働情報検索部４０３、パラメータ検査部４０４と受信部４０５を持つ。稼働情報管理部４０１は、中継機器を介して収集し、管理する。例えば、稼働情報の一部であるアラームの履歴管理テーブルを用いて、各アラーム情報を、発生日時、発生したネットワーク機器１０３の識別子、アラームの種類を表すアラームコードの情報とともに管理する。稼働情報登録部４０２は、受信部４０５によって受信した中継機器１０２からの稼働情報の一部であるアラームを、アラーム履歴管理テーブルに登録する。

図５は、稼働情報管理部４０１の保持するテーブルの一例であるアラーム履歴管理テーブルを示している。このテーブルに含まれる情報は、ネットワーク機器で生成され中継機器１０２を介して受信した通知の内容に基づき保持される。５０１は、アラーム発生時刻であり、ネットワーク機器においてアラームが発生した時刻を表す。５０５は、機器識別子であり、アラームの発生したネットワーク機器１０３を一意に特定する識別子を格納する。５０３は、アラームコードであり、発生したアラームの種類を格納する。図５の例では、２つのアラームが、２台のネットワーク機器においてそれぞれ発生したことが記録されていることを示している。

稼働情報検索部４０３は、クライアント装置１００からのアラーム情報の取得要求があったときに、アラーム履歴管理テーブルから要求の内容にしたがって、クライアント装置１００に提供すべきアラームを検索する。パラメータ検査部４０４は、アラーム情報の取得要求に設定される入力パラメータが適切か検査する。パラメータ検査部４０４は、アラーム履歴を検索した際の検索結果が膨大であると、検索機能やクライアントへの返却において多大な負荷がかかるため、入力パラメータが適切かを、稼働情報検索部４０３による検索前に、あらかじめ検査する。受信部４０５は、クライアント装置１００からのアラームなどの稼働情報の取得要求と、中継機器１０２からの稼働情報を受け付ける機能を持つ。

図８で示すように、クライアント装置１００から、稼働情報の取得要求の入力パラメータとして、少なくとも機器識別子５０４、開始日時５０５、終了日時５０６、稼働情報の種類（ここでは、アラームコード５０７）の指定が可能となっている。各パラメータについて、複数の値を入力することも可能である。

ここで、各パラメータについて説明する。機器識別子５０４は、取得対象のアラームが発生したネットワーク機器１０３を一意に特定する識別子を表す。値を指定しない場合は、すべてのネットワーク機器で発生したアラームが取得対象となる。開始日時５０５、終了日時５０６は、２つのパラメータによって取得対象のアラーム発生期間を決定している。アラームコード５０７は、取得対象のアラームの種類を表す。値を指定しない場合は、すべての種類のアラームが取得対象となる。

ここで、パラメータ検査部４０４による入力パラメータの妥当性の判断は、アラームコード５０７が指定の有無、指定されたコードの内容で処理が異なる。

具体的には、クライアント装置１００から受け付けた取得要求に、入力パラメータとして、アラームコード５０７が指定されている場合は、同時に指定可能な機器識別子５０４及び開始日時５０５、終了日時５０６で示す期間の条件を緩和する。ただし、指定されたアラームコード５０７に、ネットワーク機器上で異常に頻出するアラームの種類に対応するコードが含まれている場合は、条件を緩和せずに、通常の条件で機器識別子５０４及び開始日時５０５、終了日時５０６で示す期間の指定を可能とする。

本実施例では、この頻出するアラームの種類に対応するコードを、例外コードと呼ぶ。例外コードの一覧は、あらかじめパラメータ検査部４０４が設定として保持しているものとする。具体的には、例外コードとして、画像形成処理の際に帯電する装置部品における電気の漏出に関するアラーム通知に対応するコードを、例外コードに指定するといったことが考えられる。

一方で、ライアント装置１００から受け付けた取得要求に、入力パラメータとして、アラームコード５０７が指定されていない場合には、上述したような条件の緩和はおこなわれない。

ここで、上述した条件の緩和が具体的にどのように行われるかを、図８で指定されている入力パラメータを参照しながら説明する。

図８の例では、アラームの検索条件となる入力パラメータとして、５，０００台のデバイスの指定と、開始日時５０５と終了日時５０６（指定期間としては、１５時間分）とが指定されている。さらに、３つのアラームコードが指定されている。ここで「ＡＬＭ４０００」は、前述した例外コードであるとする。

≪パラメータ検査部４０４による入力パラメータの妥当性チェック処理の詳細≫
まず、パラメータ検査部４０４は、機器識別子５０４で指定可能なネットワーク機器の台数の通常の上限値として、１０，０００台といった上限を管理している。ここで、例外コード以外のアラームコードが取得要求の入力パラメータに含まれる場合には、この上限が緩和され上限値は１００，０００台とする。

図８の例では、例外コードとなるアラームコードが指定されているので、条件の緩和が行われず、パラメータ検査部４０４により、機器識別子５０４で指定された機器の台数が１０，０００台以内であるか否かがチェックされる。本チェックでは、図８の場合は５０００台の指定であるので、問題がない。ここで、もし上限を超えるような台数が指定されていた場合には、入力パラメータが妥当ではないとして入力チェックエラーとなる。

つぎに、パラメータ検査部４０４は、取得要求で指定されたネットワーク機器の台数及び期間の両方についても異なる判定を行う。

この際の判定条件としては、通常は、指定台数が２０台以下の場合は期間の上限値は７日間、指定台数が１００台以下の場合は期間の上限値は１日分、指定台数が１０，０００台以下の場合は期間の上限値を６０分といった指定条件により判定する。ここで、この条件を超えるような入力パラメータが指定された場合は、上限である期間までの稼働情報（ここではアラームの情報）を取得対象として、稼働情報検索部４０３に稼働情報の検索を行わせてもよい。なお、ここでの条件を超えるような期間が入力パラメータとして指定された場合にも、妥当な入力パラメータではないと判定して入力チェックエラーとしてもよい。

一方で、例外コード以外のアラームコードが取得要求の入力パラメータに含まれる場合には、２１台以上の場合に一律で１日分までのデータを取得可能とする。つまり、１０１台以上の機器指定が行われた場合であっても１日分までのデータを取得できるようになるので、その部分で通常の上限値が緩和されているといえる。

図８の例では、例外コードとなるアラームコードが指定されているので、条件の緩和が行われず、開始日時５０５の指定時刻から６０分までのデータが取得されることになる。したがって、２０１３／４／１ ００：００〜０１：００までのデータが稼働情報検索部４０３により検索され、クライアント装置１００に対して、実際の取得期間の情報とともに検索結果が返却される。

ここまでで説明したパラメータ検査部４０４による妥当性チェック処理に関して、例外コード以外のアラームコードが取得要求の入力パラメータに含まれる場合の処理は、後述の図６のＳ６０５及び図７のＳ７０５で実行される。また、アラームコードが取得要求の入力パラメータに含まれない場合、または、例外コードのアラームコードとして取得要求の入力パラメータに含まれる場合の処理は、後述の図６のＳ６０４及び図７のＳ７０４で実行される。

図６は、管理装置１０４によるアラーム履歴の取得要求の入力パラメータの検査処理について説明するためのフローチャートである。本動作の主体は管理装置１０４の入力パラメータ検査部４０４である。

Ｓ６０１で、受信部４０５が受信した取得要求に含まれる入力パラメータを受け付ける。次にＳ６０２で、入力パラメータにアラームコード５０７が指定されているかどうかを確認する。指定されていればＳ６０３の処理に移行し、指定されていなければＳ６０４の処理に移行する。

Ｓ６０３では、指定されているアラームコード５０７が例外コード一覧に存在するかどうかを判断する。ここで存在すればＳ６０４の処理に移行し、存在しなければＳ６０５に処理を移行する。

Ｓ６０４で、入力パラメータ中の機器識別子５０４で指定されたネットワーク機器の台数および開始日時５０５、終了日時５０６から指定された期間について、妥当性を判定する。ここでの判定は、前述の≪パラメータ検査部４０４による入力パラメータの妥当性チェック処理の詳細≫で説明した通りである。ここで、妥当と判定されればＳ６０６の処理に移行し、妥当でなければＳ６０８の処理に移行する。

Ｓ６０５で、例外コード以外のアラームコードが指定されているので、条件を緩和した上で、入力パラメータ中の機器識別子５０４で指定されたネットワーク機器の台数および開始日時５０５、終了日時５０６から指定された期間について、妥当性を判定する。ここでの判定は、前述の≪パラメータ検査部４０４による入力パラメータの妥当性チェック処理の詳細≫で説明した通りである。ここで、妥当と判定されればＳ６０６の処理に移行し、妥当でなければＳ６０８の処理に移行する。

Ｓ６０６で、入力パラメータにしたがってアラーム履歴の管理テーブルから一致するアラームを、稼働情報検索部４０３により検索させる。Ｓ６０７で、検索されたアラーム履歴の一覧を含む結果を、取得要求の応答として、クライアント装置１００に返却する。Ｓ６０７で、アラーム履歴の検索を行なわず、入力チェックエラーを、取得要求の応答として、クライアント装置１００に返却する。

上記の処理を用いることで、膨大な検索結果になり得る取得要求に対しては、検索処理自体を行なわないといった制御を行なうことになる。また、比較的多数のネットワーク機器を対象としたい場合や、広い発生期間を対象としたい場合には、例外コード以外の種別（アラームコード）を指定された場合に限り検索処理を実行し、検索実行の利便性を測ることが可能となった。

［実施例２］
本実施例では、実施例１に加え、例外コードの対象をより運用に即した形で管理することを目的とする。具体的には、ネットワーク機器において頻出するアラームコードは、市場で運用されるネットワーク機器のファームウェアアップデートや、ネットワーク機器そのものの入れ替えが行われた場合に、変化（増減）する可能性がある。そこで、本実施例では、運用環境においてネットワーク機器で頻出するアラームコードの変化に対応できるシステムを説明する。

実施例２におけるネットワーク構成やそれに含まれる各機器の内部構成については、実施例１と同様であるため説明を省略する。また、管理装置１０４における稼働情報の管理テーブルや、クライアント装置１００の取得要求で指定されるパラメータの内容なども同様なので、その説明を省略する。

実施例２では、パラメータ検査部４０４が保持する例外コードについては、必要に応じて更新することが可能な構成とする。例外コード一覧を更新する仕組みについては、後述する。なお、例外コードの一覧には、当初は１つの指定がない、または、実施例１と同様いくつかの例外コードが初期値として含まれるものとする。

図７は、本実施例における、管理装置１０４によるアラーム履歴の取得要求の入力パラメータの検査処理について説明するためのフローチャートである。本動作の主体は管理装置１０４の入力パラメータ検査部４０４である。

Ｓ７０１〜Ｓ７０６、Ｓ７０９、Ｓ７１０で示す処理は、前述の図６のＳ６０１〜Ｓ６０６、Ｓ６０８、Ｓ６０７で示す処理と同様であるため、その説明を省略する。

Ｓ７０７で、Ｓ７０６における検索結果がある一定の既定値を超えているかどうかを判断する。超えている場合はＳ７０８の処理に移行し、超えていない場合はＳ７１０の処理に移行する。

Ｓ７０８で、例外コードの一覧に、今回取得要求の入力パラメータとして指定されていたアラームコードを追加で登録し、さらに、Ｓ７０９で取得要求を行ったクライアント装置１００に入力チェックエラーを返却する。これにより、クライアント装置１００側のユーザーに対して、入力パラメータの再指定を促す。

ここで、取得要求に複数のアラームコードが指定されていた場合は、Ｓ７０８ではその組み合わせを例外コードとして追加する。例えば、「ＡＬＭ３００」、「ＡＬＭ４００」が入力パラメータのアラームコードとして指定されていた場合は、「ＡＬＭ３００」、「ＡＬＭ４００」として登録する。この際には、後にクライアント装置１００から受信する取得要求に、「ＡＬＭ３００」および「ＡＬＭ４００」のそれぞれ一方だけ指定された場合は、例外コードが指定されているとは判定しない。なお、例外コードの更新に際しては、取得要求の入力パラメータとして指定されていたアラームコードだけでなく、開始日時５０５、終了日時５０６といった他のパラメータも組み合わせた形で例外コードとして追加登録を行ってもよい。

上記の処理を用いることによって、運用に合わせた、例外コードの指定が行われるようになる。

（応用例）
さらに、管理装置１０４で、収集した稼働情報を用いて、ネットワーク機器のモデル情報とアラームコードを紐付け、モデル情報ごとの各アラームの発生頻度のデータを管理しておく。取得要求で特定のモデル情報のネットワーク機器１０３がパラメータにより指定された場合に、同時に指定されたアラームコードのアラームの発生頻度がある一定の閾値を超えている際には、図６のＳ６０４や図７の７０４での上限値を小さくするよう制御してもよい。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

さらに、本発明には、上述した実施形態の適宜組み合わせることにより構成されたシステムやその機能も含まれるものとする。

Claims (9)

1. ネットワークを介して管理対象の複数のネットワーク機器から収集した稼働情報を、記憶部を用いて管理する管理装置であって、
   ネットワークを介して接続される外部の情報処理装置から、稼働情報の取得要求を受け付ける受け付け手段と、
   前記取得要求に稼働情報の種類を示すパラメータが指定されているか否かを判定する第１の判定手段と、
   前記第１の判定手段により前記取得要求に稼働情報の種類を示すパラメータが指定されていると判定された場合に、当該指定されたパラメータが例外コードであるか否かを判定する第２の判定手段と、
   前記第１の判定手段により前記取得要求に稼働情報の種類を示すパラメータが指定されていないと判定された場合、または、前記第２の判定手段により前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードであると判定された場合に、第１の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第３の判定手段と、
   前記第２の判定手段により前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードではないと判定された場合、第１の条件よりも条件が緩和された第２の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第４の判定手段と、
   前記第３の判定手段または前記第４の判定手段により入力エラーとすべきではないと判定された場合に、前記取得要求で指定された複数のパラメータに対応する稼働情報を、前記記憶部から検索する検索手段と、
   前記取得要求の応答として、前記検索手段による検索結果を、前記外部の情報処理装置に対して送信する送信手段と、を有し、
   前記送信手段は、前記第３の判定手段または前記第４の判定手段により入力エラーとすべきと判定された場合に、前記取得要求の応答として、入力エラーを前記外部の情報処理装置に対して送信することを特徴とする管理装置。
2. 前記取得要求には、稼働情報の種類を示すパラメータとしてアラームコードが指定され、
   前記例外コードは、ネットワーク機器の画像形成処理の際に帯電する装置部品における電気の漏出に関するアラーム通知に対応するコードを含むことを特徴とする請求項１に記載の管理装置。
3. 前記期間を特定するためのパラメータは、開始日時と終了日時とで指定されることを特徴とする請求項１または２に記載の管理装置。
4. 前記第３の判定手段は、前記取得要求に含まれるネットワーク機器を特定するためのパラメータで指定された台数と前記第１の条件とにより入力エラーとすべきかを判定し、さらに、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータと、前記第１の条件とにより前記検索手段による検索の条件を決定し、
   前記第４の判定手段は、前記取得要求に含まれるネットワーク機器を特定するためのパラメータで指定された台数と前記第２の条件とにより入力エラーとすべきかを判定し、さらに、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータと、前記第２の条件とにより前記検索手段による検索の条件を決定することを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
5. 前記取得要求で稼働情報の種類を示すパラメータが指定された際に、前記検索手段による検索結果に含まれる稼働情報の数が既定値を超えていた場合に、当該取得要求で稼働情報の種類を示すパラメータを、前記第２の判定手段で用いる例外コードとして追加することを特徴とする請求項１乃至４のいずれか１項に記載の管理装置。
6. 前記取得要求で稼働情報の種類を示すパラメータが複数、指定されていた場合には、当該複数のパラメータの組合せを例外コードとして追加することを特徴とする請求項５に記載の管理装置。
7. ネットワークを介して管理対象の複数のネットワーク機器から収集した稼働情報を、記憶部を用いて管理する管理装置における制御方法であって、
   ネットワークを介して接続される外部の情報処理装置から、稼働情報の取得要求を受け付ける受け付け工程と、
   前記取得要求に稼働情報の種類を示すパラメータが指定されているか否かを判定する第１の判定工程と、
   前記第１の判定工程で前記取得要求に稼働情報の種類を示すパラメータが指定されていると判定された場合に、当該指定されたパラメータが例外コードであるか否かを判定する第２の判定工程と、
   前記第１の判定工程で前記取得要求に稼働情報の種類を示すパラメータが指定されていないと判定された場合、または、前記第２の判定工程で前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードであると判定された場合に、第１の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第３の判定工程と、
   前記第２の判定工程で前記取得要求で指定された稼働情報の種類を示すパラメータが例外コードではないと判定された場合、第１の条件よりも条件が緩和された第２の条件に従い、前記取得要求に含まれるネットワーク機器を特定するためのパラメータと、期間を特定するためのパラメータとの少なくとも何れかに基づき入力エラーとすべきか否かを判定する第４の判定工程と、
   前記第３の判定工程または前記第４の判定工程で入力エラーとすべきではないと判定された場合に、前記取得要求で指定された複数のパラメータに対応する稼働情報を、前記記憶部から検索する検索工程と、
   前記取得要求の応答として、前記検索工程での検索結果を、前記外部の情報処理装置に対して送信する送信工程と、を有し、
   前記送信工程では、前記第３の判定工程または前記第４の判定工程で入力エラーとすべきと判定された場合に、前記取得要求の応答として、入力エラーが前記外部の情報処理装置に対して送信されることを特徴とする制御方法。
8. 前記取得要求には、稼働情報の種類を示すパラメータとしてアラームコードが指定され、
   前記例外コードは、ネットワーク機器の画像形成処理の際に帯電する装置部品における電気の漏出に関するアラーム通知に対応するコードを含むことを特徴とする請求項７に記載の制御方法。
9. 請求項１乃至６のいずれか１項に記載の手段としてコンピューターを機能させるためのプログラム。

Images