(57)【特許請求の範囲】
【請求項１】
機器管理クライアントからの通知を処理する機器情報管理装置であって、
前記機器管理クライアントからの通知を受け付ける受付手段と、
前記受付手段によって受け付けた前記通知の重要度と前記機器情報管理装置の負荷度とに基づいて、前記通知が処理対象であるか否かを判定する判定手段と、
前記判定手段によって前記通知が処理対象であると判定された場合には前記通知を処理する処理手段と、
前記判定手段によって前記通知が処理対象でないと判定された場合には前記通知を廃棄する廃棄手段とを有し、
前記判定手段は前記重要度と前記負荷度との和があらかじめ定めた閾値以上であるときには、前記通知が処理対象であると判定し、前記重要度と前記負荷度との和が前記閾値より小さいときには処理対象でないと判定することを特徴とする機器情報管理装置。 
【請求項２】
請求項１に記載の機器情報管理装置において、
前記処理手段は、
前記通知が定常通知のときに通知内容を記憶する記憶手段と、
前記通知が非常通知のときに前記非常通知を情報活用システムへ送信する非常通知送信手段と、
を有することを特徴とする機器情報管理装置。
【請求項３】
請求項２に記載の機器情報管理装置において、前記記憶手段は定常通知の内容をテキスト形式で記憶することを特徴とする機器情報管理装置。 
【請求項４】
請求項１乃至３のいずれか一項に記載の機器情報管理装置において、前記重要度は、通知のサービス種別に基づいて決定されることを特徴とする機器情報管理装置。 
【請求項５】
機器管理クライアントからの通知を処理する機器情報管理装置が実行する機器情報管理プログラムであって、
前記機器管理クライアントからの通知を受け付ける受付工程と、
前記受付工程によって受け付けた前記通知の重要度と前記機器情報管理装置の負荷度とに基づいて、前記通知が処理対象であるか否かを判定する判定工程と、
前記判定工程によって前記通知が処理対象であると判定された場合には前記通知を処理する処理工程と、
前記判定工程によって前記通知が処理対象でないと判定された場合には前記通知を廃棄する廃棄工程とを前記機器情報管理装置に実行させ、
前記判定工程は前記重要度と前記負荷度との和があらかじめ定めた閾値以上であるときには、前記通知が処理対象であると判定し、前記重要度と前記負荷度との和が前記閾値より小さいときには処理対象でないと判定することを特徴とする機器情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＦＰ（Multi Function Printer：多機能複写機）等の画像処理装置に代表される機器の稼動状況に関する機器情報を、ネットワークを介して収集し管理する機器情報管理装置に関する。
【背景技術】
【０００２】
ＭＦＰ等の画像処理装置を対象に、印刷枚数等のカウンタ情報、故障等の障害発生情報、トナー切れ等の消耗品残量情報等をインターネット等のネットワークを介して収集する遠隔管理システムが実用化されている（例えば、特許文献１等を参照。）。
【０００３】
このようなシステムでは、画像処理装置とは別体の通信装置もしくは画像処理装置内部の通信機能により、カウンタ情報、障害発生情報等についてセンタ側に通知を行う。通知された情報は、重要度に応じてサービスマンの派遣等の対応がとられる。
【０００４】
【特許文献１】特開２００１−２５０００８
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述した遠隔管理システムは顧客先の機器を適正に管理する上で不可欠のものとなっており、管理システム側の装置（サーバ）に障害が発生した場合には不測の事態が想定されることから、障害対策が重要なテーマとなる。
【０００６】
従来、この種のシステムにおける障害対策としては、
（１）同一性能のサーバを複数台用意し、１台に障害が生じても他のサーバで処理を継続できるようにする（クラスタ構成）
（２）遠隔地にセカンダリサーバを配置し、障害時にはセカンダリサーバで業務を継続させる（コールドサイト、ホットサイト）
のいずれかが採用されており、いずれにしてもサーバの提供するサービスをそのまま別のサーバが引き継ぐことで業務を継続させるものとなっている。
【０００７】
従って、代替用のサーバは通常時と同等の処理性能を持つことが要求されることになり、管理対象の機器数が膨大で通常時用のサーバが相当大規模なものである場合には、代替用のサーバにも同等の規模のものが要求される。
【０００８】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、規模の小さいバックアップ装置により障害対策を行うことのできる機器情報管理装置を提供することにある。
【課題を解決するための手段】
【０００９】
上述した課題を解決するため、請求項１に記載の発明に係る機器情報管理装置は、機器管理クライアントからの通知を処理する機器情報管理装置であって、前記機器管理クライアントからの通知を受け付ける受付手段と、前記受付手段によって受け付けた前記通知の重要度と前記機器情報管理装置の負荷度とに基づいて、前記通知が処理対象であるか否かを判定する判定手段と、前記判定手段によって前記通知が処理対象であると判定された場合には前記通知を処理する処理手段と、前記判定手段によって前記通知が処理対象でないと判定された場合には前記通知を廃棄する廃棄手段とを有し、前記判定手段は前記重要度と前記負荷度との和があらかじめ定めた閾値以上であるときには、前記通知が処理対象であると判定し、前記重要度と前記負荷度との和が前記閾値より小さいときには処理対象でないと判定することを特徴とする。 
【００１５】
また、請求項６に記載の発明に係る情報機器管理プログラムは、機器管理クライアントからの通知を処理する機器情報管理装置が実行する機器情報管理プログラムであって、前記機器管理クライアントからの通知を受け付ける受付工程と、前記受付工程によって受け付けた前記通知の重要度と前記機器情報管理装置の負荷とに基づいて、前記通知が処理対象であるか否かを判定する判定工程と、前記判定工程によって前記通知が処理対象であると判定された場合には前記通知を処理する処理工程と、前記判定工程によって前記通知が処理対象でないと判定された場合には前記通知を廃棄する廃棄工程とを前記機器情報管理装置に実行させ、前記判定工程は前記重要度と前記負荷度との和があらかじめ定めた閾値以上であるときには、前記通知が処理対象であると判定し、前記重要度と前記負荷度との和が前記閾値より小さいときには処理対象でないと判定することを特徴とする。
【発明の効果】
【００１６】
本発明の機器情報管理装置にあっては、障害時に機器情報管理装置により処理を行うにあたり、機器情報管理装置の負荷が高いときには重要度の高い通知のみを処理し、負荷が低いときには重要度の低い通知も処理するようにしているため、通常時処理のサーバに比して小規模なサーバであってもシステム障害時に適切に対応することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の好適な実施形態につき説明する。
【００１８】
＜システム構成＞
図１は本発明の一実施形態にかかるシステムの構成例を示す図である。
【００１９】
図１において、ＭＦＰ等の管理対象機器１の内部もしくは外部には機器情報の収集を行なう機器管理クライアント２が設けられ、この機器管理クライアント２はインターネット等のネットワーク３に接続されている。
【００２０】
センタ側では負荷分散装置（ロードバランサ）４が機器管理クライアント２によって収集された機器情報をネットワーク３経由で受け付け、トランザクションシステム５に振り分ける。トランザクションシステム５ではアプリケーションサーバ５１で機器情報を管理し、また、このトランザクションシステム５で収集した機器情報はネットワークにて接続された情報活用システム８にて活用する。トランザクションシステム５に障害が発生したときには負荷分散装置４が機器情報を機器情報管理装置６に送信する。
更に、情報活用システム８にはサービス拠点の利用者が使用する利用者端末９がネットワークを介して接続されている。
【００２１】
トランザクションシステム５は、アプリケーションサーバ５１Ａ、５１Ｂ、・・・と、ＤＢ（Data Base）サーバ５２Ａ、５２Ｂ、・・・と、記憶装置（ディスクアレイ）５３とを備えている。機器情報管理装置６は受付手段６１、負荷取得手段６２、判定手段６３、処理手段６４、廃棄手段６５、記憶手段６６を備えており、記憶手段６６に保存されたデータを復旧時にトランザクションシステム５に記憶させる復旧時処理部７が接続されている。
【００２２】
負荷分散装置４は、機器管理クライアント２からネットワーク３を介して受け付けた通知を、トランザクションシステム５が正常に動作している時にはアプリケーションサーバ５１Ａ、５１Ｂ、・・に負荷分散のために均等に振り分け、トランザクションシステム５に障害が発生している時には機器情報管理装置６に振り分ける機能を有している。トランザクションシステム５が正常に動作している時の振り分けのアルゴリズムとしては、ラウンドロビン方式とファステスト（最速）方式がよく用いられる。ラウンドロビン方式では、アプリケーションサーバ５１が例えばＡ〜Ｄまである場合、Ａ→Ｂ→Ｃ→Ｄ→Ａ→Ｂ→Ｃ→Ｄ・・・のように順番に振り分けていく。また、ファステスト方式では、複数のアプリケーションサーバ５１に呼びかけ、返事の早かったものに振り分ける。
【００２３】
トランザクションシステム５に障害が発生している時における負荷分散装置４から機器情報管理装置６への振り分けとしては、
（１）全てのアプリケーションサーバ５１Ａ、５２Ｂ、・・の反応が失われたときに、全ての通知を機器情報管理装置６に振り分けるように、予め負荷分散装置４に設定しておく方式
（２）トランザクションシステムに障害が発生した時に、負荷分散装置４の設定をオペレータが手動で変更し、全ての通知が機器情報管理装置６に振り分けられるようにする方式
の２方式が考えられる。ただし、（１）の方式は、一時的な高負荷などによってアプリケーションサーバ５１Ａ、５１Ｂ、・・の反応が遅くなったときにも機器情報管理装置６に処理が移されてしまうという問題がある。また、（２）の方式は、そのような切替ミスは生じないが、切替までに時間がかかるという問題がある。
【００２４】
アプリケーションサーバ５１Ａ、５１Ｂ、・・・は、サービス提供のためのビジネスロジックを実行する機能部であり、負荷分散装置４から振り分けられた機器管理クライアント２からの通知を、定常通知についてはＤＢサーバ５２Ａ、５２Ｂ、・・・により記憶装置５３に蓄積し、非常通知については情報活用システム８即座に転送する機能を有している。なお、定常通知とは例えばカウンタ情報等を定期的に知らせる通知であり、非常通知とは障害発生情報や消耗品残量情報等、事象が発生するごとに行う通知である。アプリケーションサーバ５１Ａ、５１Ｂ、・・・はそれぞれ複数のＤＢサーバ５２Ａ、５２Ｂ、・・・に接続しているが、それぞれのアプリケーションサーバごとに、最初にアクセスを試みるＤＢサーバであるプライマリサーバと、プライマリサーバが反応しないときにアクセスを試みるＤＢサーバであるセカンダリサーバというようにＤＢサーバに順位付けを行っている。
【００２５】
ＤＢサーバ５２Ａ、５２Ｂ、・・・は、ＤＢＭＳ（Data Base Management System：データベース管理システム）が動作するサーバであり、アプリケーションサーバ５１Ａ、５１Ｂ、・・・からの要求に基づき、記憶装置５３に格納されたデータベースの実体を操作する機能を有している。複数のＤＢサーバ５２Ａ、５２Ｂ、・・・によるデータベースの競合を防ぐため、ＤＢ単位、テーブル単位、行単位などでのロックをかける。また、ＤＢサーバ間で同期信号をやり取りすることもある。
【００２６】
機器情報管理装置６は、トランザクションシステム５に障害が発生した時の処理を行う機能部であり、負荷分散装置４から振り分けられた機器管理クライアント２からの通知を、受付手段６１で受け付け、負荷取得手段６２で機器情報管理装置６の負荷を取得する。次に判定手段６３にて重要障害通知、定時通知、トナーニアエンド通知といったその通知が示すサービスの種類であるサービス種別に応じて予め定められた重要度と、負荷取得手段６２で取得した現時点の負荷状況を考慮して処理するか廃棄するかを判定する。通知にはカウンタ情報等の定常通知と障害発生情報や消耗品残量情報等の非常通知があり、重要度が高く、かつ定常的な通知について一時蓄積し、重要度の高く、かつ非常時の通知については情報活用システム８に即座に転送する処理手段６４を有している。機器情報管理装置６の負荷が高いときに受け付けた重要度の低い通知については何も処理をせずに廃棄手段６５にて破棄する。
【００２７】
復旧時処理部７は、トランザクションシステム５の障害からの復旧時に、機器情報管理装置６の記憶手段６６に一時蓄積された定常的な通知の内容を本番系のＤＢサーバ５２Ａ、５２Ｂ、・・・に記憶させる機能を有している。なお、復旧時処理部７の機能は、機器情報管理装置６の内部に設けても、あるいは、負荷分散装置４やアプリケーションサーバ５１Ａ、５１Ｂ、・・・の内部に設けてもよい。
【００２８】
一方、情報活用システム８は、アプリケーションサーバ８１と、ＤＢサーバ８２と、記憶装置８３とを備えている。
【００２９】
アプリケーションサーバ８１は、サービス提供のためのビジネスロジックを実行する機能部であり、トランザクションシステム５から転送された非常時の通知を利用者端末９に伝えるとともに、トランザクションシステム５のデータベースでの蓄積情報を適時に取得してＤＢサーバ８２の管理のもと記憶装置８３に蓄積し、利用者端末９からの情報活用の要求に応じる機能を有している。
【００３０】
図２（ａ）は機器管理クライアント２からトランザクションシステム５に対して行なわれる通知のデータ形式の例を示す図である。全ての通知データは、サービスの種別を表すサービス種別と、クライアントを特定するためのクライアントＩＤと、通知した日時を示す通知日時と、サービスに関わるデータの本体とを含んでいる。図２（ｂ）はサービス種別の構造例を示しており、サービスを特定するためのサービスＩＤと、種別の識別子とを含んでいる。種別としては、定常通知と非常通知に分けられる。図２（ｃ）はサービスに関わるデータの例をサービス種別ごとに示しており、サービス種別によりデータの内容は異なる。サービスに関わるデータは、項目ごとにカンマで区切られたＣＳＶ（Comma Separated Values）形式のテキストである。もちろん、システムで規約を定めることで、他のデータ形式とすることもできる。
【００３１】
図３はトランザクションシステム５のデータベース上のデータ構造例を示す図である。トランザクションシステム５では通知のサービス種別ごとに別のテーブルを保持している。図３（ａ）は定時通知のデータ構造例を示しており、機器管理クライアント２を特定するためのクライアントＩＤと、通知が行なわれた日時を示す通知日時と、ＭＦＰのカウンタを読み出した日時を示すカウンタ情報取得日時と、各種のカウンタ別のカウンタ情報と、発生日時順のジャム履歴情報（ジャムが、いつ、どこで、どんな状況で起きたかを示す情報）と、発生日時順の障害履歴情報（障害は、いつ、どんなものだったかを示す情報）とを含んでいる。ＭＦＰはカラーや白黒、用紙サイズ、用紙の向き、用紙トレイなどの様々な枚数カウンタを持つため、カウンタ情報はそれらの項目別に分かれている。また、ジャム履歴情報、障害履歴情報については、例えば最近１０回分の情報が含まれる。
【００３２】
図３（ｂ）は課金カウンタ通知のデータ構造例を示しており、機器管理クライアント２を特定するためのクライアントＩＤと、通知が行なわれた日時を示す通知日時と、ＭＦＰのカウンタを読み出した日時を示すカウンタ情報取得日時と、課金計算に関わるそれぞれのカウンタの値を示す課金カウンタ情報とを含んでいる。
【００３３】
図４は機器情報管理装置６の構成例を示す図である。
【００３４】
図４において、機器情報管理装置６は、負荷分散装置４経由の通知(サービス)を受付手段６１で受け取り、負荷取得手段６２で機器情報管理装置の負荷を取得する。判定手段６３にてサービス種別リスト６３１により通知のサービス種別ごとに対応付けられる重要度と機器情報管理装置６の負荷を負荷度リスト６３２で対応付けた負荷度とを比較して、条件に合うときは処理手段６４に通知を振り分け、条件に合わないときには通知を廃棄手段６５に振り分ける。
【００３５】
また、処理手段６４は、定常通知を処理する定常通知処理部６４１と、非常通知を処理する非常通知処理部６４５とを備えていてもよい。この場合、定常通知処理部６３１は、定常通知の種類を分析する定常通知分析部６４２と、定時通知に対して処理を行う定時通知処理部６４３と、課金カウンタ通知に対して処理を行う課金カウンタ通知処理部６４４等を備えている。定時通知処理部６４３、課金カウンタ通知処理部６４４等は、通知の内容を、一時的に蓄積する。その内容は、トランザクションシステム５に復旧時処理部７によりＤＢサーバ５２Ａ、５３Ｂ、・・・に保存される。ここでデータベースを用いず（データベース形式に変換せず）、テキスト形式のまま記憶記憶手段６６に記憶しても良い。その場合、システム障害下において機器情報管理装置６における処理の負荷を低く抑え、処理できる通知の範囲を広げることができる。
【００３６】
非常通知処理部６４５は、非常通知を情報活用システム８に送信する非常通知送信部６４６を備えている。
【００３７】
図５は判定手段６３に保持されるサービス種別リスト６３１のデータ構造例を示す図である。ここでは、重要度「４」が最も重要度が高く、次いで「３」「２」「１」という順に重要度が設定されている。例えば、重要障害通知や定時通知は重要度「４」に設定されている。重要障害通知の重要度を高くしたのは、顧客先の業務に影響が大きく、システム障害下であっても緊急に対処すべきであるからである。定時通知の重要度を高くしたのは、定時通知の内容を一時蓄積してデータの消失を防ぎ、システム復旧時にトランザクションシステムに記憶させるためである。トナーニアエンド通知、課金カウンタ通知、ジャム発生通知、部品劣化通知等はさほど緊急性がなく、後に定時通知から内容を把握できるものでもあるため、重要度が低く設定されている。
【００３８】
図６は機器情報管理装置６の負荷を負荷度数として定義した負荷度リスト６３２の例を表した図である。ここでは、機器情報管理装置６の負荷が最も低い０〜４０％のときには負荷度を「４」、４０〜６０％のときには「３」、次いで「２」「１」と設定されている。
【００３９】
図７は機器情報管理装置６により一時蓄積される通知のファイル構造例を示す図である。機器情報管理装置６はサービス種別を含む各通知を保存する。このとき、ＣＳＶ形式のテキストデータとして蓄積してもよい。図７（ａ）は定時通知のファイル構造例を示しており、通知の内容を加工せずにそのままＣＳＶ形式のテキストとして蓄積する様子を示している。図７（ｂ）は課金カウンタ通知のファイル構造例を示しており、同様に、通知の内容を加工せずにそのままＣＳＶ形式のテキストとして蓄積する様子を示している。
【００４０】
＜動作＞
図８はシステム正常時のデータの流れを示すシーケンス図である。
【００４１】
図８において、機器管理クライアント２から負荷分散装置４を経てトランザクションシステム５に定常通知が送信されると（ステップＳ１１）、通知を振り分けられたアプリケーションサーバ５１Ａ、５１Ｂ、・・・がデータベースへの通知内容の蓄積を行う（ステップＳ１２）。
【００４２】
その後、情報活用システム８からトランザクションシステム５に蓄積情報の参照要求があると（ステップＳ１３）、トランザクションシステム５はデータベースからの読み出しを行い（ステップＳ１４）、情報活用システム８に蓄積情報を送信する（ステップＳ１５）。
【００４３】
また、機器管理クライアント２から負荷分散装置４を経て、トランザクションシステム５に非常通知が送信されると（ステップＳ１６）、通知を振り分けられたアプリケーションサーバ５１Ａ、５１Ｂ、・・・が非常通知を情報活用システム８に転送する（ステップＳ１７）。
【００４４】
図９はシステム障害時のデータの流れを示すシーケンス図である。
【００４５】
図９において、機器管理クライアント２からの通知が負荷分散装置４を経て機器情報管理装置６に定常通知が送信されると（ステップＳ２１）、機器情報管理装置６は通知の重要度および現時点の負荷状況に基づく処理の振り分けを行う（ステップＳ２２）。そして、処理するものとした場合には一時ファイルに格納する（ステップＳ２３）。処理できないとした場合、その通知は破棄する。非常通知が送信されると（ステップＳ２４）、機器情報管理装置６は通知の重要度および現時点の負荷状況に基づく処理の振り分けを行う（ステップＳ２５）。そして、処理するものとした場合には情報活用システム８に通知し（ステップＳ２６）、処理できないとした場合、その通知は破棄する。
【００４６】
このように障害時には重要度の低い通知を破棄することによって通知を記憶する記憶装置の容量を少なくすることができる。なお、データベースに記憶しても良いが、保存の形式にはこだわらない。たとえば、テキスト形式でファイルに保存すれば、より簡易な仕組みとなり、ＨＤＤの容量を節約することができる。
【００４７】
一方、トランザクションシステム５は、システムが復旧すると、復旧時処理部７の制御のもと、機器情報管理装置６の記憶手段６６に一時的に格納してある定常通知の内容を取得し、本番系のＤＢサーバ５２Ａ、５２Ｂ、・・・に内容を記憶させる（ステップＳ２７）。
【００４８】
図９のステップＳ２２、Ｓ２５における重要度および負荷度に基づく処理振り分けの処理について説明する。機器情報管理装置６はトランザクションシステム５に障害が発生したとき、機器管理クライアント２から受け付けた通知の重要度と機器情報管理装置６の負荷度に演算を施し、その結果があらかじめ定めた処理必要度以上であれば処理するものと判断する。演算はたとえば通知の重要度と機器情報管理装置の負荷度の和とするとしてもよい。たとえば、処理必要度が５のとき、重要度が「３」で負荷度が「４」、「３」もしくは「２」であれば処理する。重要度が「３」で負荷度が「１」であれば処理しない。
【００４９】
上記実施例では通知の重要度と機器情報管理装置の負荷度との両方に基づいて判断を行ったが、通知の重要度のみに基づいて判断を行ってもよいし、機器情報管理装置の負荷度のみに基づいて判断を行ってもよい。
【００５０】
また、図１０のように重要度を優先させた判断を行ってもよい。図１０は図９のステップＳ２２、Ｓ２５における重要度および負荷度に基づく処理振り分けの処理例を示すフローチャートである。  図１０において、処理を開始し（ステップＳ１０１）、通知を受信すると（ステップＳ１０２）、重要度が「４」であるか否か判断する（ステップＳ１０３）。ここで、重要度が「４」である場合（ステップＳ１０３のＹｅｓ）、通知を処理し（ステップＳ１１０）、処理を終了する（ステップＳ１１１）。
【００５１】
また、重要度が「４」でない場合（ステップＳ１０３のＮｏ）、続いて重要度が「３」であるか否か判断する（ステップＳ１０４）。ここで、重要度が「３」である場合（ステップＳ１０４のＹｅｓ）、続いて障害用機器管理装置の負荷（以下、サーバ負荷と記す。）が８０％より小さいか否か判断する（ステップＳ１０５）。ここで、サーバ負荷が８０％より小さい場合（ステップＳ１０５のＹｅｓ）、通知を処理し（ステップＳ１１０）、処理を終了する（ステップＳ１１１）。サーバ負荷が８０％より小さくない場合（ステップＳ１０５のＮｏ）、特に処理を行わずに処理を終了する（ステップＳ１１１）。
【００５２】
また、重要度が「３」でない場合（ステップＳ１０４のＮｏ）、続いて重要度が「２」であるか否か判断する（ステップＳ１０６）。ここで、重要度が「２」である場合（ステップＳ１０６のＹｅｓ）、続いてサーバ負荷が６０％より小さいか否か判断する（ステップＳ１０７）。ここで、サーバ負荷が６０％より小さい場合（ステップＳ１０７のＹｅｓ）、通知を処理し（ステップＳ１１０）、処理を終了する（ステップＳ１１１）。サーバ負荷が６０％より小さくない場合（ステップＳ１０７のＮｏ）、特に処理を行わずに処理を終了する（ステップＳ１１１）。
【００５３】
また、重要度が「２」でない場合（ステップＳ１０６のＮｏ）、続いて重要度が「１」であるか否か判断する（ステップＳ１０８）。ここで、重要度が「１」である場合（ステップＳ１０８のＹｅｓ）、続いてサーバ負荷が４０％より小さいか否か判断する（ステップＳ１０９）。ここで、サーバ負荷が４０％より小さい場合（ステップＳ１０９のＹｅｓ）、通知を処理し（ステップＳ１１０）、処理を終了する（ステップＳ１１１）。サーバ負荷が４０％より小さくない場合（ステップＳ１０９のＮｏ）、特に処理を行わずに処理を終了する（ステップＳ１１１）。
【００５４】
また、重要度が「１」でない場合（ステップＳ１０８のＮｏ）、特に処理を行わずに終了する（ステップＳ１１１）。
【００５５】
なお、通知を処理すると判定された場合には、図１１に示すように、その通知が定常通知であれば記憶手段６６に保存し、非常通知であれば情報活用システム８へ転送する。さらに、前述したように記憶手段６６で保存された定常通知はトランザクションシステム５が復旧したときに復旧時処理部７によってトランザクションシステム５のDBサーバ５２に記憶させる。また、情報活用システム８へ転送された非常通知は利用者端末９から参照することができる。
【００５６】
＜総括＞
以上説明したように、本発明の実施形態によれば、
（１）機器情報管理装置では、トランザクションシステムのアプリケーションサーバおよびDBサーバで行っている全ての業務を継続するのではなく、重要度の高い業務のみを提供し、重要度の低い緊急性のないトランザクションは捨ててしまう。
（２）機器情報管理装置の記憶手段では、データベースを使わず、ファイルにデータを蓄積しておくことで、記憶容量を節減する。
（３）システム障害からの復旧後に、機器情報管理装置の記憶手段に保存しておいた通知をトランザクションシステムのDBサーバに保存する。
という特徴を有することで、結果として、機器情報管理装置は機能の低いものにすることができる。
【００５７】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【００５８】
【図１】本発明の一実施形態にかかるシステムの構成例を示す図である。
【図２】通知のデータ形式の例を示す図である。
【図３】DBサーバ内のデータ構造例を示す図である。
【図４】機器情報管理装置の構成例を示す図である。
【図５】サービス種別リストのデータ構造例を示す図である。
【図６】負荷度リストの構造例を示す図である。
【図７】機器情報管理装置の記憶手段により一時蓄積される通知のファイル構造例を示す図である。
【図８】トランザクションシステムの正常動作時のデータの流れを示すシーケンス図である。
【図９】トランザクションシステムの障害時のデータの流れを示すシーケンス図である。
【図１０】重要度／負荷に基づく処理振り分けの処理例を示すフローチャートである。
【図１１】通知を処理する例を示すフローチャートである。
【符号の説明】
【００５９】
１                管理対象機器
２                機器管理クライアント
３                ネットワーク
４                負荷分散装置
５                トランザクションシステム
５１Ａ、５１Ｂ    アプリケーションサーバ
５２Ａ、５２Ｂ    ＤＢサーバ
５３              記憶装置
６                機器情報管理装置
６１              受付手段
６２              負荷取得手段
６３              判定手段
６３１            サービス種別リスト
６３２            負荷度リスト
６４              処理手段
６４１            定常通知処理部
６４２            定常通知分析部
６４３            定時通知処理部
６４４            課金カウンタ通知処理部
６４５            非常通知処理部
６４６            非常通知送信部
６５              廃棄手段
６６              記憶手段
７                復旧時処理部
８                情報活用システム
８１              アプリケーションサーバ
８２              ＤＢサーバ
８３              記憶装置
９                利用者端末
【図１】
0005228652.tif 000002
【図２】
0005228652.tif 000003
【図３】
0005228652.tif 000004
【図４】
0005228652.tif 000005
【図５】
0005228652.tif 000006
【図６】
0005228652.tif 000007
【図７】
0005228652.tif 000008
【図８】
0005228652.tif 000009
【図９】
0005228652.tif 000010
【図１０】
0005228652.tif 000011
【図１１】
0005228652.tif 000012