JP2002157171A - 情報処理装置、機器管理プログラム、機器管理プログラムが格納された記録媒体、及び機器管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 顧客先ののコンピュータと周辺機器とを一元
的に管理する遠隔サイト管理システムを提供する。 【解決手段】 遠隔サイト管理システムは、オフィスの
サービス対象の機器がエラーを起こし、オフィスの顧客
が保守サービス会社に電話で通知（センターコール）し
たときに、エラー発生に的確に対応し、スムーズにメン
テナンスの手配（サービスマンの手配、他のサービス会
社への代行メンテナンス依頼）を行なう。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、たとえばコンピュ
ータネットワークを介して接続された、汎用性のあるパ
ーソナルコンピュータ（ＰＣ）やサーバコンピュータと
いったＰＣ・サーバ系機器と、専用の機能、特にプリン
タや複写機、スキャンといった入出力機能に特化した周
辺機器（デバイス）系機器の状態を、包括的に遠隔監視
する遠隔サイト管理システムに関するものである。

【０００２】

【従来の技術】従来、オフィス内の機器に関する稼動情
報、エラー情報、ログ情報などをオフィス内で収集する
ような監視・管理システムは存在していた。また、その
ようにオフィスで収集された情報をネットワークを介し
てオフィスの外部に設置・接続されたセンタサーバに収
集し監視・管理するようなシステムも存在していた。

【０００３】しかしながら、それらの管理・監視システ
ムはＰＣ・サーバ系すなわち汎用コンピュータのみを監
視・管理するようなシステムであったり、プリンタや複
写機などのデバイス系のみを監視・管理するようなシス
テムであった。

【０００４】このように、汎用コンピュータとデバイス
とが別個に管理されていたのは、汎用コンピュータとデ
バイスとを管理する手順等が全く異なるためである。す
なわち、汎用コンピュータを管理する場合には、コンピ
ュータのオペレーティングシステム等の環境に応じて所
望の機能を果たすプログラムを作成し、管理対象のコン
ピュータで実行させることが必要であるのに対して、周
辺機器を管理する場合には、機能の後付や変更が実際上
ほとんど不可能であった。

【０００５】加えて、周辺機器を管理する場合、監視・
管理システムが周辺機器とやりとりするデータ形式や交
換の手順（プロトコル）に標準的なものが存在しなかっ
た。そのため、周辺機器ごとに対応した管理手順を開発
しなければならず、個々の周辺機器がそれぞれ管理サイ
トに接続され、管理されていた。

【０００６】このようにデバイス系の管理システムはＰ
Ｃ・サーバ系の管理システムとは相容れず、それぞれ全
く別個に存在していた。

【０００７】

【発明が解決しようとする課題】その一方、デバイス系
の周辺機器とＰＣ・サーバ系のコンピュータが共にオフ
ィス環境で普及するにつれて、それらを統括的に監視・
管理する保守サービスが望まれている。

【０００８】しかし、従来の方法では、保守サービス会
社（管理サイト）が、あるオフィスのデバイス系とＰＣ
・サーバ系との両方を監視・管理するためには、両方の
システムをオフィスに設置して、別々の回線を通じて情
報を収集し、別々に監視・管理しなければならなかっ
た。そのため、保守サービス会社における管理の煩雑
化、システムの運用費・維持費の高価格化が生じた。

【０００９】そこで、本発明は、上記問題点を鑑みてな
されたものであり、管理サイトが、オフィスにおけるＰ
Ｃ・サーバ系の機器とデバイス系の機器との双方を、一
元的に管理できる遠隔サイト管理システムを提供するこ
とを目的とする。

【００１０】特に、オフィスのサービス対象の機器がエ
ラーを起こし、オフィスの顧客が保守サービス会社に電
話で通知（センターコール）したときに、エラー発生に
的確に対応し、スムーズにメンテナンスの手配（サービ
スマンの手配、他のサービス会社への代行メンテナンス
依頼）を行なう遠隔サイト管理システムを提供すること
を目的とする。

【００１１】

【課題を解決するための手段】本発明は、第１タイプの
機器とローカルネットワークを介して接続され、前記第
１タイプの機器を管理する第１ローカルサーバと、第２
タイプの機器とローカルネットワークを介して接続さ
れ、前記第２タイプの機器を管理する第２ローカルサー
バと接続されている場合であって、前記第１タイプの機
器における障害であるか、前記第２タイプの機器におけ
る障害であるかを判定し、判定結果に基づいて、前記第
１ローカルサーバに、又は前記第２ローカルサーバに、
又は前記第１ローカルサーバと前記第２ローカルサーバ
とに診断を行なわせることを特徴とする。

【００１２】さらに、本発明では、前記第１ローカルサ
ーバに対して、又は前記第２ローカルサーバに対して、
又は前記第１ローカルサーバと前記第２ローカルサーバ
とに対して、診断要求を発行することを特徴とする。

【００１３】さらに、本発明では、前記ローカルネット
ワークに接続されている機器の一覧を表示部に表示させ
る。

【００１４】さらに、本発明では、前記第１ローカルサ
ーバ又は前記第２ローカルサーバによって障害が特定さ
れない場合、復旧作業に向うようにサービスマンに通知
することを特徴とする。

【００１５】さらに、本発明では、サービスマンが所有
する携帯端末に、復旧作業に向う向かい先を示す情報を
送信することを特徴とする。

【００１６】さらに、本発明では、前記第１ローカルサ
ーバ又は前記第２ローカルサーバによって障害が特定さ
れる場合、障害内容を示すレポート情報を生成すること
を特徴とする。

【００１７】さらに、本発明では、障害に対して自社が
対応できない場合、復旧作業の依頼を他社に通知する。

【００１８】さらに、本発明では、前記第１タイプの機
器は周辺機器であり、前記第２タイプの機器はコンピュ
ータ機器であることを特徴とする。

【００１９】さらに、本発明では、前記第１タイプの機
器は、プリンタ、複写機、スキャナのうちの少なくとも
一つであることを特徴とする。

【００２０】さらに、本発明では、前記第２タイプの機
器は、パーソナルコンピュータ、サーバコンピュータ、
ネットワーク機器のうちの少なくとも一つであることを
特徴とする。

【００２１】

【発明の実施の形態】＜第１の遠隔サイト管理システム
の構成＞図を参照して本発明に係る遠隔サイト管理シス
テムを説明する。

【００２２】図１は、遠隔サイト管理システムにおける
被管理サイト（オフィス側）と管理サイト（保守サービ
ス会社側）の構成を示すブロック図である。被管理サイ
トでは、汎用コンピュータであるＰＣ１０３、デバイス
監視サーバ２０３ａ（オフィスのローカルネットワーク
上に接続されたデバイス系の周辺機器を管理する情報機
器）、周辺機器である複写機１０１、プリンタ１０５、
プリンタ１０４がＬＡＮ（ローカルエリアネットワー
ク）で接続されている。

【００２３】なお、ここでいう汎用コンピュータは、パ
ーソナルコンピュータやサーバコンピュータのほか、ゲ
ートウエイ、ルータなどのコンピュータネットワークに
欠かせないネットワーク機器をも含むものとする。周辺
機器は、複写機、プリンタ、スキャナー、ＦＡＸ、複合
機等を含むものとする。

【００２４】ＰＣ１０３では、後述するＰＣ監視クライ
アントモジュールが実行され、これは、オフィスのロー
カルネットワーク上に接続された汎用コンピュータ機器
等を管理することができる。また、デバイス監視サーバ
２０３ａとＰＣ監視クライアントモジュールは物理的に
別々のコンピュータで実行されてもよく、また一つのコ
ンピュータで実行されても良い。

【００２５】また、図１に記載はされてはいないが、こ
の遠隔サイト管理システムには、データフォーマット変
換装置がある。これは、デバイス監視サーバ２０３ａと
ＰＣ監視クライアントモジュールとの間のデータフォー
マット形式を変換・調整する装置である。

【００２６】また、管理サイトには、被管理サイトの機
器を一元的に管理するためのセンタサーバ１１０、管理
情報等を蓄積するためのインベントリデータベース１０
９、被管理サイトにおける周辺機器の管理を専門に行う
ためのデバイスセンタサーバ２１０が、それぞれＬＡＮ
に接続されている。また、このシステムでは、サーバ・
ＰＣ１１１といったその他のコンピュータが接続されて
いる。このコンピュータ１１１では、管理情報を用い
て、オフィス機器を統括管理するアプリケーションプロ
グラムが実行されている。

【００２７】また、図１に記載はされてはいないが、管
理サイトには、被管理サイトから通知されてくる情報を
表示させる表示装置や、センタサーバ１１０とデバイス
センタサーバ２１０との間でデータフォーマット形式を
変換・調整する変換装置もある。

【００２８】また、複数の管理サイトを統合的に管理す
るサービスセンタ（図２のアプリケーションシステム２
０５に相当）もあり、これは、管理サイトと外部ネット
ワークまたはＬＡＮを介して接続さている。

【００２９】これら被管理サイトと管理サイトは、互い
にゲートウエイ１０６，１０７で接続されている。この
接続は、汎用のルータやモデム等を用いても良い。ま
た、ＰＣ１０３においてＰＣ監視クライアントモジュー
ルが実行されている場合には、ＰＣ１０３とセンタサー
バ１０９との間の回線と、デバイス監視サーバ２０３ａ
とデバイスセンタサーバ２１０との間の回線が、それぞ
れ別々に設けられ、それぞれ独立していてもよい。

【００３０】図３は、ＰＣ及びサーバコンピュータの構
成を示すブロック図である。図３において、コンピュー
タ３０００は、ＣＰＵ１、ＲＡＭ２、ＲＯＭ３、システ
ムバス４、ＫＢＣ５、ＣＲＴＣ６、ＭＣ７、ＬＡＮ制御
部８、ＫＢ９、ＣＲＴ１０、外部メモリ１１とを備え
る。

【００３１】ＣＰＵ１は、ＲＯＭ３のプログラム用ＲＯ
Ｍに記憶された通信制御プログラムを実行して、それに
基づいて、指定されたデータの外部への送信を制御した
り、あるいは外部からのデータの受信を制御したりす
る。また、ＣＰＵ１は、システムバス４に接続される各
デバイスを統括的に制御する。

【００３２】ＲＡＭ２は、ＣＰＵ１の主メモリ、ワーク
エリア等として機能する。ＲＯＭは、それぞれフォント
（フォントＲＯＭ）、プログラム（プログラムＲＯ
Ｍ）、データ（データＲＯＭ）を記憶する。キーボード
コントローラ（ＫＢＣ）５は、キーボード９や不図示の
ポインティングデバイスからのキー入力を制御する。Ｃ
ＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレ
イ１０の表示を制御する。メモリコントローラ（ＭＣ）
７は、外部メモリ１１へのアクセスを制御する。ハード
ディスク（ＨＤ）やフロッピー（登録商標）ディスク
（ＦＤ）等の外部メモリ１１は、ブートプログラム、種
々のアプリケーション、フォントデータ、ユーザファイ
ル、後述する編集ファイル等を記憶する。ＬＡＮ制御部
８は、ネットワークに接続されて、ネットワークに接続
された他の機器との通信処理を実行する。

【００３３】図２は本遠隔サイト管理システムのソフト
ウエアモジュールの構成を示すブロック図である。ユー
ザ拠点システム（被管理サイトを指す）では、デバイス
系機器（複写機、プリンタ、複合機、スキャナ、ＦＡＸ
等の周辺機器）と、ＰＣ・サーバ系機器（汎用コンピュ
ータなど）が混在している。が、デバイス系機器はデバ
イス監視サーバ２０３ａによって、ＰＣ・サーバ系機器
はＰＣ監視クライアントモジュール２０３ｄによってぞ
れぞれローカルで管理される。これらを総称して、拠点
側管理システム２０３と呼ぶことにする。デバイス監視
サーバ２０３ａは、管理情報を蓄積するためのデータベ
ース２０３ａ−１を有する。

【００３４】一方、センターシステム（管理サイトを指
す）は、デバイス監視サーバ２０３ａとの間でデータを
交換するデバイスセンタサーバ２１０と、ＰＣ監視クラ
イアントモジュール２０３ｄとの間でデータを交換する
センタサーバ１１０とを含む。デバイス系機器の管理情
報はインベントリデータベース１０９に蓄積される。ま
た、センタサーバ１１０によって管理される管理情報も
インベントリデータベース１０９に蓄積される。これら
イインベントリデータベース１０９に蓄積される管理情
報は、アプリケーションシステム２０５等により利用さ
れる。なお、インベントリデータベース１０９はデバイ
ス系とＰＣ・サーバ等の汎用コンピュータ系とで、それ
ぞれ論理的に分かれていればよく、無論、物理的に分か
れていてもよい。

【００３５】デバイス監視サーバ２０３ａとデバイスセ
ンタサーバ２１０とは、データ形式や手順を必要に応じ
て変換するための拠点プラグインモジュール２０３ｂと
サーバプラグインモジュールを介して接続されている。
これら拠点プラグインモジュールとサーバプラグインモ
ジュールとによって、拠点側とセンタ側とで使用ＯＳが
異なる場合などでも、お互いの通信が可能になる。ま
た、電気的には、ルータ２０４を介する。この回線は、
ＰＣ監視クライアント２０３ｄとセンタサーバ１１０と
を接続する回線と物理的または論理的に共用されてい
る。

【００３６】デバイスセンタサーバ２１０とデバイス監
視サーバ２３０ａを接続する回線は、監視クライアント
２０３ｄとセンタサーバ間を接続する回線と共用されな
い場合も想定される。その場合には、モデムやルータを
介して、管理クライアント２０３ｄ−センタサーバ１１
０とは独立した回線で接続されても良い。

【００３７】センタサーバ１１０には、イベントモニタ
１１０ａが含まれており、センタサーバ１１０に対して
発行されたイベントを監視し、障害の発生等を伝えるイ
ベントであればモニタ上に表示する。管理者はその表示
を見ることで、被管理サイトにおいて発生した障害の状
況を知ることができる。センタサーバ１１０に対してイ
ベントを発行するのは、イベントアダプタ２１０ａと、
ＰＣ監視クライアント２０３ｄと、アプリケーションシ
ステム２０５である。センタサーバ１１０は、受け取っ
たイベントを、それが示す内容に従って所定の処理を実
行する。イベントとしては例えば、障害通知等がある。

【００３８】デバイスセンタサーバ２１０には、イベン
トアダプタモジュール２１０ａが含まれている。イベン
トアダプタ２１０ａは、デバイス監視サーバ２０３ａか
らデバイスセンタサーバ２１０に対して送られてきて受
信した情報を定期的に検索する機能をもち、その検索さ
れた情報の内から、周辺機器において発生した障害に関
する情報を判別してより分けて、センタサーバ１１０に
おいて処理可能な形式（ファイル形式、プロトコル形式
等）に変換してから、センタサーバ１１０に対して障害
の発生を示すイベントを発行する。あるいは、イベント
アダプタモジュール２１０ａによってセンタサーバに処
理化能な形式に変換する機能をセンタサーバ１１０に持
たせてもよい。障害関連のイベント（障害イベント）に
は、障害の起きた装置やその内容、発生時刻等が含まれ
る。このイベントアダプタ２１０ａを本システム及び装
置に設けることによって、デバイス専用に想定されたプ
ロトコル・フォーマットを使用した管理ソフトによって
得られたデバイス固有の情報、例えば、紙詰まり、ステ
ープル機能チェック等を別の種別のシステム・装置（実
施例では汎用コンピュータ・サーバ等）を監視するソフ
トと一元化して管理することが可能となる。

【００３９】イベントモニタ１１０ａはそれを受けて、
障害の起きた装置やその内容、発生時刻等を、イベント
のリストに加えて表示する。表示の方法としては、たと
えば、１行に１イベントを表示し、時系列的にイベント
のリストを表示する。図２ではイベントモニタ１１０ａ
はセンタサーバ１１０に含まれる形で記載されている
が、このイベントモニタ１１０ａをセンタサーバ１１０
からネットワーク等を介して外部に接続することで、例
えば、デバイスセンタサーバ２１０側やアプリケーショ
ンシステム２０５側でデバース系、ＰＣ・サーバ系を包
括管理することが可能となる。

【００４０】ここで注意すべきなのは、イベントモニタ
１１０ａは、イベントの発生元を意識することなく、障
害系のイベントであればそれを表示することで、管理者
の注意を喚起できる、ということである。すなわち、イ
ベントモニタ１１０ａにおいては、ＰＣ監視クライアン
ト２０３ｄから発行された、汎用コンピュータ系の障害
イベントと、デバイスセンタサーバ２１０のイベントア
ダプタ２１０ａを介してデバイス監視サーバ２０３ａか
ら発行された、周辺機器系の障害イベントとを、同一画
面上のイベントリストにたとえば時系列的に表示する。

【００４１】次に、デバイスセンタサーバ２１０と、デ
バイス監視サーバ２０３ａとの間でなされるデータ交換
の手順の例を、図４を参照しつつ、（１）デバイスへ
の、デバイスセンタサーバ２１０からの設定値のダウン
ロード、（２）デバイス監視サーバ２０３ａからデバイ
スセンタサーバ２１０へのログデータのアップロード、
（３）デバイスセンタサーバ２１０からデバイス監視サ
ーバ２０３ａへのカウンタデータの要求、という３つの
ケースで説明する。その前に、データフォーマットにつ
いて簡単に説明する。

【００４２】図８は、デバイスセンタサーバ２１０とデ
バイス監視サーバ２０３ａとの間で交換されるメッセー
ジフォーマットの一例を示す図である。１つのメッセー
ジは、フラグフィールド，データ種別フィールド，ジョ
ブＩＤフィールド，リターン値フィールド，データ長フ
ィールド，データフィールドを含む。フラグフィールド
には、通信手段を示すビット群と、そのメッセージがデ
ータの最終フレームであるか否かを示すビットが含まれ
る。

【００４３】データ種別フィールドでは、たとえば認証
要求データ（セッションの先頭に送信されるデータ）で
あることや、ダウンロードされる設定値データであるこ
と、後述するデバイス情報要求であること、イベント情
報の通知であること、ログデータ処理要求であることな
どが示される。たとえば障害の通知などは、イベント情
報であることがデータ種別として示され、データフィー
ルドで具体的な内容が示される。

【００４４】ジョブＩＤは、そのセッションの種類を示
すもので、パラメータ設定やデバイス情報の取得、イベ
ント通知などがこれによって示される。データ長には後
続するデータの長さが示され、データフィールドには、
データ長で示された長さのデータが格納される。設定値
のダウンロードやログデータの処理要求には、データフ
ィールドにデータが載せられる。また、カウンタアップ
ロードにおいては、デバイス情報要求に対する応答のデ
ータフィールドに、デバイス情報が載せられる。

【００４５】以下の手順をはじめ、デバイスセンタサー
バ２１０やデバイス監視サーバ２０３ａは、このメッセ
ージを交換しつつ処理を遂行する。なお、以下の説明で
は、イベントとは、イベントの発生を伝えるためのメッ
セージという意味で使用している。

【００４６】＜設定値ダウンロード手順＞図４は、拠点
システムとセンタシステムとの間で行われる、データの
交換の手順を説明するためのブロック図である。

【００４７】設定値のダウンロードは次のようにして行
われる。

【００４８】（１）アプリケーションシステム２０５に
おいて、手作業などで、設定対象のデバイスの指定やデ
バイスのＩＰアドレス、デバイスの拠点デバイスサーバ
に対するエラー等のアラーム通知の時の閾値の設定値等
を入力し、設定値情報ファイル４０１を作成する。

【００４９】（２）アプリケーションシステム２０５よ
りデバイスセンタサーバ２１０との間のセッションを確
立し、設定値情報ファイル４０１に含まれる設定値デー
タを送信する。

【００５０】（３）デバイスセンタサーバ２１０は、設
定値データを受信すると、デバイス監視サーバ２０３ａ
との間でセッションを確立し、デバイス監視サーバ２０
３ａに対して設定値データを送信する。

【００５１】（４）デバイス監視サーバ２０３ａは、設
定値データを受信するとデバイスに設定値を送りつけ
る。この手順は、デバイスごとに定まった手順で行われ
る。

【００５２】（５）デバイスの設定が終了すると、デバ
イス監視サーバ２０３ａは、デバイスセンタサーバ２１
０に対して設定終了を送信する。

【００５３】（６）デバイスセンタサーバ２１０は、ア
プリケーションシステム２０５に対して設定終了通知を
送信する。

【００５４】その後、アプリケーションシステム２０５
はデバイスセンタサーバ２１０との間のセッションを解
放し、デバイスセンタサーバ２１０は、デバイス監視サ
ーバ２０３ａとの間のセッションを解放する。

【００５５】以上のようにして、デバイス監視サーバ２
０３ａとデバイスセンタサーバ２１０とは直接通信する
ことで、デバイスの設定情報をデバイス４０２にダウン
ロードする事ができる。

【００５６】なお、障害に関しては次のようになる。

【００５７】（７）ＰＣ監視クライアント２０３ｄがサ
ーバやＰＣにおいて何らかの障害を検出し、障害イベン
トを発行する際には、センタサーバ１１０に対して直接
イベントを発行する。

【００５８】（８）また、デバイス監視サーバ２０３ａ
がデバイス４０２の障害を検出した場合には、その情報
をデバイスセンタサーバ２１０に送信する。

【００５９】（９）デバイスセンタサーバ２１０は、デ
バイス４０２における障害の通報を受信すると、それを
基に、センタサーバ１１０に対して障害発生を知らせる
イベントを発行する。図４のデバイスセンタサーバ２１
０には図２のイベントアダプタ２０１ａが含まれる形で
記載されおり、イベントアダプタ２０１ａから図４に記
載される障害系イベントが発行されることになる。

【００６０】（１０）イベントモニタ１１０ａは、その
イベントが障害系イベントであるので、イベントコンソ
ールにその障害情報を表示させ、イベントリストを更新
する。

【００６１】このように、障害を通知するイベントは、
被管理サイトのどのデバイス系または汎用コンピュータ
系で生じても、センタサーバ１１０を通ることになり、
管理者は、センタサーバのイベントコンソールを監視す
るだけで、被管理サイトのすべてのデバイス系の情報ま
たは汎用コンピュータ系の情報を監視できる。また、イ
ベントコンソールに表示される情報は、印刷出力された
り、サービスマンの所持する形態端末等に表示されるよ
うな処理を施されることも考えられる。印刷された情報
は、被管理者宛に郵送で送られたり、サービスマンの形
態端末に表示された情報はサービスマンの派遣等に利用
することができる。このようにデバイス系と汎用ＰＣ・
サーバ系を一元管理された情報を様々な形態で応用する
場面が想定される。

【００６２】前述の記載では、デバイス系の障害を図４
中のイベントモニタ１１０ａを介してイベントコンソー
ル１１０ｂに表示させることについて説明してきたが、
本名発明の特徴として、デバイス系で発生した全ての障
害情報をイベントコンソール１１０ｂに表示するわけで
はないことが挙げられる。すなわちデバイス機器の障害
のレベルによってデバイスセンタサーバ２１０に情報を
送信するか否かの判断処理を行う機能を本システムは有
する。

【００６３】例えば、複写機等におけるドアオープンエ
ラー、デバイス機器のパワーオン・オフ機能によるリセ
ットで回復できるようなエラーに関してはデバイス監視
サーバ２０３ａはデバイスセンタサーバ２１０にエラー
通知を行わない。一方、センタサーバに通知されてくる
情報のうちでも、顧客先で顧客による対応がとれるエラ
ー、例えば、デバイスの温度上昇等の現状動作に支障の
無いエラー、ジャムエラー）に関しては、サービスマン
の呼び出し等を行わない。

【００６４】これら、センタサーバへ障害を通知するか
否かの判断機能データベースは監視データベース２０３
ａ−１、デバイス４０２、等のデバイス側の機器のいず
れかに記憶されていれば、デバイス側からセンタ側に情
報を通知するか否かの判断を行うことができる。

【００６５】また、センタサーバ１１０に通知されてき
た障害情報をイベントコンソール１１０ｂに表示するか
否か、または、サービスマンに連絡するか否かの判断機
能データベースはセンタサーバ側のアプリケーションシ
ステム２０９、インベントリデータベース１０９、セン
タサーバ１１０等の機器のいずれかに記憶されていれ
ば、本発明の機能を達成することはできる。

【００６６】これらの情報伝達に伴うフィルタリング機
能を本システムは有することにより、拠点側−センタ側
間のトラフィック量の軽減、また、センタ側で管理する
管理者にとって、重大なエラー情報をより明確且つ容易
に認識することが可能となる。

【００６７】＜カウンタアップロード手順＞カウンタ値
のアップロード、すなわちデバイス情報の収集は次のよ
うにして行われる。カウンタ値とは、複写機やプリンタ
において印刷したページ数を示す値、デバイスの各種モ
ードがどれほど使用されたかを示すモードカウンタ等で
あり、保守料金算定の基本となる値である。これをセン
タシステムからの要求に応じてアップロードすること
で、遠隔サイトからのカウンタ値をはじめとするデバイ
ス情報の取り込みを可能とする。カウンタのアップロー
ドはアプリケーションからの要求に応じて行われるため
に、センタシステム（管理サイト）がイニシエータとな
る。

【００６８】（１）アプリケーションシステム２０５よ
りセッションを確立し、デバイス情報要求をデバイスセ
ンタサーバ２１０に対して送信する。デバイス情報要求
には、拠点システムにおける対象デバイスを指定する情
報等が含まれている。

【００６９】（２）デバイスセンタサーバ２１０は、デ
バイス情報要求を受信すると、デバイス監視サーバ２０
３ａとの間でセッションを確立し、デバイス監視サーバ
２０３ａに対してデバイス情報要求を送信する。

【００７０】（３）デバイス監視サーバ２０３ａは、デ
バイス情報要求を受信すると、デバイス情報を指定され
たデバイスから取得する。この手順は、デバイスごとに
定まった手順で行われ、デバイスごとに定まった情報、
あるいは指定された情報が取得される。

【００７１】（４）デバイス情報を取得すると、デバイ
ス監視サーバ２０３ａは、デバイスセンタサーバ２１０
に対して取得したデバイス情報を含むデバイス情報応答
を送信する。

【００７２】（５）デバイスセンタサーバ２１０は、ア
プリケーションシステム２０５に対してデバイス情報応
答を送信する。

【００７３】その後、アプリケーションシステム２０５
はデバイスセンタサーバ２１０との間のセッションを解
放し、デバイスセンタサーバ２１０は、デバイス監視サ
ーバ２０３ａとの間のセッションを解放する。

【００７４】以上のようにして、デバイス監視サーバ２
０３ａとデバイスセンタサーバ２１０とは直接通信する
ことで、デバイス情報を取得することができる。

【００７５】なお、障害に関しては設定値のダウンロー
ドと同じ要領で行われる。

【００７６】＜ログデータアップロード手順＞ログデー
タのアップロードは次のようにして行われる。ログデー
タとは、たとえば周辺機器において発生した警告やリト
ライの情報などが履歴で、それらの警告が所定回数以上
に達するなど、エラーに至らないまでも、何らかの異常
事態が発生しつつあることが予想される場合にそれを管
理サイトに自発的に送信する。したがって、ログデータ
のアップロードはカウンタのアップロードとは異なり、
被管理サイト（拠点システム）がイニシエータとなる。

【００７７】（１）デバイス監視サーバ２０３ａがデバ
イスのログを収集する。その量が所定値を越えたり、警
告の発生頻度が所定の率を超えた場合には、デバイス監
視サーバ２０３ａはログデータのアップロードを開始す
る。

【００７８】（２）まず、デバイス監視サーバ２０３ａ
よりセッションを確立し、ログデータを含むログデータ
処理要求をデバイスセンタサーバ２１０に対して送信す
る。

【００７９】（３）デバイス監視サーバ２０３ａは、ロ
グデータ処理要求を受信すると、デバイスセンタサーバ
２１０との間でセッションを確立し、デバイスセンタサ
ーバ２１０に対してログ処理要求を送信する。

【００８０】（４）デバイスセンタサーバ２１０は、ロ
グデータ処理要求を受信すると、アプリケーションシス
テム２０５との間にセッションを確立し、ログデータ処
理要求を、ログデータを処理するアプリケーションシス
テム２０５に対して送信する。

【００８１】（５）アプリケーションシステム２０５
は、ログデータ処理要求を受信すると、それと共に受信
したログデータを処理し、ログデータ処理応答を、デバ
イスセンタサーバ２１０に対して送信する。

【００８２】（６）デバイスセンタサーバ２１０は、デ
バイス監視サーバ２０３ａに対してログデータ処理応答
を送信する。

【００８３】（７）デバイス監視サーバ２０３ａは、デ
バイスセンタサーバ２１０との間のセッションを解放
し、後処理を行う。後処理においては、ログデータ処理
応答が、ログデータの処理が正常に完了したことを示す
ものであれば、ログデータ消去などを行う。

【００８４】その後、デバイスセンタサーバ２１０はア
プリケーションシステム２０５との間のセッションを解
放する。

【００８５】以上のようにして、デバイス監視サーバ２
０３ａとデバイスセンタサーバ２１０とは直接通信する
ことで、ログ情報をアップロードすることができる。

【００８６】なお、障害に関しては設定値のダウンロー
ドと同じ要領で行われる。

【００８７】＜デバイスセンタサーバによる処理手順＞
次に、デバイスセンタサーバ２１０、デバイス監視サー
バ２０３ａそれぞれにおける処理手順を簡単に示す。図
５は、デバイスセンタサーバにおけるメッセージ受信時
の処理手順を示すフローチャートである。なお、このメ
ッセージはデバイス監視サーバからのものとは限らず、
アプリケーションシステム２０５からも受信する。この
メッセージのフォーマットは、図８と異なるものでも良
い。いずれにしても、メッセージの発信元を識別可能に
できているか、あるいは、発信元に応じて異なるプロセ
スが実行される。本実施形態では、前者を採用する。

【００８８】メッセージを受信すると、図５の処理が開
始される。まず、受信したメッセージを解析し（ステッ
プＳ５０１）、その発行元が判定される（ステップＳ５
０２）。発行元は、アドレス等をメッセージに付加して
も良いが、その内容によっても識別できる。たとえば、
ログ処理要求であれば、その発行元はデバイス監視サー
バであり、設定値ダウンロード要求であればアプリケー
ションシステム（フローチャートではバックエンドと示
している）である。

【００８９】発行元がデバイス監視サーバ２０３ａであ
れば、それが障害イベントであるか判定し（ステップＳ
５０３）、障害イベントであれば、センタサーバ１１０
へ処理可能な形式に変換してから転送する（ステップＳ
５０４）。センタサーバ１１０においては障害の場所や
内容、時刻などがそのメッセージに含まれたデータから
読み出され、表示される（ステップＳ５０５）。障害イ
ベントでない場合には、データをアプリケーションシス
テムに渡してメッセージに応じた処理をさせ、メッセー
ジ待ちとなる。アプリケーションシステムに渡す処理に
は、たとえばログデータ処理要求や、収集されたデバイ
ス情報が含まれる。

【００９０】一方、発行元がアプリケーションシステム
であれば、そのメッセージがデバイス情報の収集要求で
あるか判定する（ステップＳ５０６）。そうであれば、
デバイス情報収集要求をデバイス監視サーバ２０３ａに
対して発行し、メッセージ待ちとなる。

【００９１】デバイス情報収集要求でなければ設定値の
ダウンロード要求であるかが判定される（ステップＳ５
０８）。ダウンロード要求であれば、受信したダウンロ
ード情報を取得し（ステップＳ５０９）、それをデバイ
ス監視サーバ２０３ａに対して発呼する（ステップＳ５
１０）。

【００９２】＜デバイス監視サーバによる処理手順＞図
６は、デバイス監視サーバ２０３ａにおいて発生したイ
ベントに対する処理手順を示すフローチャートである。

【００９３】何らかのイベントが発生すると、発生した
イベントを解析し（ステップＳ６０１）、それがデバイ
スからの警告であり、所定の閾値を越えていれば（ステ
ップＳ６０２）、それまでに蓄積したログデータを取得
してログデータ処理要求のメッセージを作成し（ステッ
プＳ６０３）デバイスセンタサーバ２１０に対してログ
処理要求を発行する。閾値を超えていなければログに蓄
積する。

【００９４】一方、警告でなければ本実施例ではエラー
の発生であるとみなして障害イベントを示すメッセージ
を作成し（ステップＳ６０５）、ステップＳ６０４でデ
バイスセンタサーバ２１０に送信する。

【００９５】図７は、デバイス監視サーバ２０３ａが、
デバイスセンタサーバ２１０から受信したメッセージを
受信する手順を示すフローチャートである。

【００９６】まず、受信したメッセージが設定値のダウ
ンロード要求であるか判定する（ステップＳ７０１）。
ダウンロードであれば、受信した設定値データに基づく
設定をデバイス監視サーバ２０３ａとデバイス間でう。
（ステップＳ７０２）、拠点プラグイン２０３ｂがその
データを削除し（ステップＳ７０３）、デバイスセンタ
サーバ２１０に対してダウンロードが完了した旨の応答
メッセージを発行する（ステップＳ７０４）。なお、拠
点プラグイン２０３ｂはデバイス監視サーバ２０３ａに
論理的に接続されていればよく、接続されていれば物理
的に分かれていてもよい。

【００９７】ダウンロードでなければ、デバイス情報収
集要求であるか判定し（ステップＳ７０６）、そうであ
れば指定されたデバイスから情報を収集して（ステップ
Ｓ７０７）、デバイスセンタサーバにそのデバイス情報
を送信する（ステップＳ７０８）。

【００９８】以上の手順により、汎用コンピュータのた
めの管理システムと、周辺機器のための管理システムと
による障害イベントを、管理サイト側においては統合さ
れた情報として一元的に管理できる。また、本発明はＰ
Ｃ・サーバ系の管理ソフトにデバイス系の管理情報を適
合させるものに限定されるものではなく、その逆、即ち
デバイス系の管理ソフトにＰＣ・サーバ系の管理情報を
適合させるものにすることも可能である。例えば、図２
中のイベントアダプタ２１０ａをセンタサーバ１１０に
設けて、デバイスサーバで発生したイベントをデバイス
センタサーバ２１０に通知するようにしてもよい。

【００９９】また、図２に示したように、デバイス監視
サーバ２０３ａとデバイスセンタサーバ２０１とを接続
する回線と、ＰＣ監視クライアント２０３ｄとセンタサ
ーバ１１０とを接続する回線とを同じ回線とし、ルータ
等で共用することで、回線数の節約を図ることもでき
る。これは回線として専用回線を使用する場合などに有
効である。

【０１００】＜第２の遠隔サイト管理システムの構成＞
図を参照して本発明の第２の実施形態である遠隔サイト
管理システムを説明する。本実施形態のシステムは、第
１の実施形態のそれと比較して、管理サイトと被管理サ
イトとの間における論理的なチャネルの持ち方において
相違する。第１の実施形態においては、通信回線を共用
することは可能であるものの、デバイス監視サーバ２０
３ａとデバイスセンタサーバ２１０とを接続するチャネ
ルと、ＰＣ監視クライアント２０３ｄとセンタサーバ１
１０とを接続するチャネルとは、論理的には互いに独立
した別個のチャネルである。デバイスセンタサーバ２１
０が障害イベントの通知をデバイス監視サーバ２０３ａ
から受信した場合に、障害の発生を通知するイベントを
センタサーバ１１０に送信することで、イベントモニタ
における障害イベントの一元化が図れられている。

【０１０１】これに対して本実施形態では、デバイスセ
ンタサーバ２１０も、デバイス監視サーバ２０３ａとデ
バイスセンタサーバ２０１とを接続するチャネルも存在
しない。デバイスセンタサーバの代わりに、デバイス情
報処理モジュール９０１がセンタサーバ１１０におかれ
（図では別体として示した）、センタサーバ１１０が受
信したデバイス系の情報を処理している。この構成にお
いては、市販のＰＣ監視クライアント２０３ｄとセンタ
サーバ１１０とを用いた場合に、その間に確立されるチ
ャネルに、デバイス系のメッセージも流してしまう。こ
うすることで、第１実施例で説明したように回線を共通
に使用できるメリットの他に、デバイス系の情報のため
に独立した通信チャネルを用意する必要がなく、デバイ
スセンタサーバを別途設ける必要もなくなるという効果
を得ることができる。

【０１０２】＜システム構成＞図９は、本実施形態の遠
隔サイト管理システムのソフトウエアモジュールの構成
を示すブロック図である。ユーザ拠点システム（被管理
サイトを指す）は、デバイス系機器（プリンタ、複写
機、スキャナー、ＦＡＸ、複合機等の周辺機器）と、Ｐ
Ｃ・サーバ系機器（汎用コンピュータ）が混在している
が、デバイス系機器はデバイス監視サーバ２０３ａによ
って、ＰＣ・サーバ系機器はＰＣ監視クライアント２０
３ｄによって管理される。この点は第１の実施形態と同
様である。

【０１０３】センターシステム（管理サイトを指す）
は、デバイス監視サーバ２０３ａとの間でデータを交換
するデバイス情報処理モジュール９０１と、ＰＣ監視ク
ライアント２０３ｄとの間でデータを交換するセンタサ
ーバ１１０とを含む。デバイス系機器およびＰＣ・サー
バ系の管理情報はインベントリデータベース１０９に蓄
積される。図９では一つのデータベースとして図示され
ているが、論理的または物理的にデバイス系とＰＣ・サ
ーバ系のデータベースが分かれていればよい。この情報
はアプリケーションシステム２０５、センタサーバ１１
０等により利用される。これも第１の実施形態と同様で
ある。

【０１０４】管理サイトと被管理サイトとは、ルータ２
０４同士で接続された一本の回線で接続されている。こ
のＰＣ監視クライアント２０３ｄとセンタサーバ１１０
とは市販のサイト管理システムで実現できる。すべての
メッセージは、この市販の管理システムにより提供され
る、ＰＣ監視クライアント２０３ｄとセンタサーバ１１
０とで構成されるチャネルを通して送受信される。な
お、図９ではデバイス情報処理モジュール９０１が独立
してあるものとして（図２のデバイスセンタサーバ２１
０に相当）いるが、この機能をセンタサーバ１１０に組
み込んで実現することもできる。

【０１０５】デバイス監視サーバ２０３ａとＰＣ監視ク
ライアント２０３ｄとは、データ形式（フォーマット）
や手順（プロトコル）を必要に応じて変換するための拠
点プラグインモジュール２０３ｂを介して接続されてい
る。すなわち、デバイス監視サーバの情報をＰＣ監視ク
ライアント２０３ａのフォーマット（またはプロトコ
ル）に変換する機能、その逆の変換の機能を拠点プラグ
インモジュール２０３ｂは有している。また、センタ側
でセンタサーバ１１０とデバイス処理モジュール９０１
間でのデータを受け渡しを行うセンタ側のプラグイン
（図２のサーバプラグインに相当）に、この拠点プラグ
インモジュール２０３ｂと同等の機能を持たせることも
考えられる。

【０１０６】この拠点プラグインモジュール２０３ｂ
は、後述するように、ＰＣ監視クライアント２０３ｄに
対してデバイス監視サーバ２０３ａからのメッセージを
渡して指定した宛先に送信させると共に、ＰＣ監視クラ
イアント２０３ｄが書き込む所定のデータ領域の内容を
定期的にポーリングし検索を行い、デバイス監視サーバ
２０３ａ宛のメッセージがあればそれをデバイス監視サ
ーバ２０３ａに渡す役割を有する。

【０１０７】また、センタサーバ１１０は、受信したメ
ッセージに応じて、そのメッセージの内容がデバイスに
係る情報であればデバイス情報処理モジュールに渡して
処理をさせるし、イベントの発生を知らせるメッセージ
であれば、イベントモニタ１１０ａにより発生したイベ
ントをデバイス系のイベントかＰＣ・サーバ系のイベン
トかを識別可能な表示形態にしてイベントリストとして
表示させる。デバイス系のイベントについてはデバイス
情報処理モジュール９０１から発生されることになる。

【０１０８】このように、デバイス系とＰＣ・サーバ系
間のフォーマット変換機能を有するプラグインを設ける
事により、市販されているＰＣ・サーバ系の管理ソフト
の機能を流用することが可能となり、デバイス系の情報
を拠点側と管理センタ側で送受信をすることができる。
また、市販のＰＣ・サーバ系の管理ソフトでは詳細に管
理できないような、デバイス固有の情報に関しても、セ
ンタ側で送信されてきたデバイス系のない様にに係るデ
ータをＰＣ・サーバ系のフォーマットからデバイス系の
フォーマットに変換してからデバイス情報処理モジュー
ルで処理をすればよく、デバイスの情報を詳細に管理し
たい場合には、デバイす情報処理モジュールのみを独自
に開発すればよく、開発・設計の効率を上げる効果を得
ることができる。

【０１０９】次に、拠点システム（被管理サイト）と、
センタシステム（管理サイト）との間でなされるメッセ
ージ交換の手順の例を、図１０乃至図１２を参照しつ
つ、（１）デバイスへの、デバイスセンタサーバ２１０
からの設定値のダウンロード、（２）デバイス監視サー
バ２０３ａからデバイスセンタサーバ２１０へのログデ
ータのアップロード、（３）デバイスセンタサーバ２１
０からデバイス監視サーバ２０３ａへのカウンタデータ
の要求、という３つのケースで説明する。

【０１１０】＜設定値ダウンロード手順＞図１０は、拠
点システムとセンタシステムとの間で行われる、デバイ
スへの設定値のダウンロードの手順を説明するためのブ
ロック図である。設定値のダウンロードは次のようにし
て行われる。

【０１１１】まずアプリケーションシステム２０５にお
いて、手作業などで、設定対象のデバイスの指定や設定
値等を入力し、設定値情報ファイル１００２を作成して
おく。

【０１１２】（１）アプリケーションシステム２０５よ
りセンタサーバ１１０との間のセッションを確立する。

【０１１３】（２）センタサーバ１１０において配布モ
ジュール１００１を起動し、設定値情報ファイル１００
２から配布用ファイルパッケージ１００１ａを作成す
る。

【０１１４】（３）配布モジュール１００１ａは、配布
用パッケージファイルをＰＣ監視クライアント２０３ｄ
に送信し、ワークファイルとして格納させる。

【０１１５】（４）拠点プラグイン２０３ｂは、ＰＣ監
視クライアント２０３ｄが格納するデータファイルを定
期的に監視しており、ＰＣ監視クライアントによりワー
クファイルが作成されたことを検知すると、デバイス監
視サーバに設定値の到着を通知すると共に、設定値デー
タをデバイス監視サーバ２０３ａに渡す。デバイス監視
サーバ２０３ａは、指定されたデバイスに、設定された
値を設定する。

【０１１６】（４−２）拠点プラグイン２０３ｂは、Ｐ
Ｃ監視クライアント２０３ｄを介してセンタサーバに設
定が終了したことを通知する。

【０１１７】（５）センタサーバ１１０では、配布モジ
ュール１００１により、配布用パッケージファイル１０
０１ａを削除させる。

【０１１８】（６）センタサーバ１１０は、アプリケー
ションシステム２０５に対して設定の終了を通知する。

【０１１９】以上のようにして、デバイス監視サーバ２
０３ａに設定データを渡すことで、デバイスの設定情報
をデバイスにダウンロードすることができる。

【０１２０】なお、デバイス系で発生した障害に関して
は、上記手順（４−２）と同様にして拠点プラグイン２
０３ｂからＰＣ監視クライアント２０３ｄを介してセン
タサーバ１１０に障害イベントとして送信する。このた
めに、障害を通知するイベントは、センタサーバ１１０
のイベントモニタ１１０ａで処理され、イベントのリス
トに表示される。

【０１２１】＜カウンタアップロード手順＞図１１は、
拠点システムとセンタシステムとの間で行われる、カウ
ントデータのアップロード、すなわちデバイス情報収集
の手順を説明するためのフローチャートである。デバイ
ス情報のアップロードは次のようにして行われる。

【０１２２】（１）アプリケーションシステム２０５は
情報要求コマンドをファイルに格納し、センタサーバ１
１０に対して情報収集のきっかけとなるメッセージ（イ
ベント）を発行する。

【０１２３】（２）アプリケーションシステム２０５か
らのイベントをイベントモニタが解析し、配布モジュー
ル１００１を起動して、情報要求コマンドの配布用ファ
イルパッケージ１００１ａを作成する。

【０１２４】（３）センタサーバ１１０は、作成した情
報要求コマンドを含む配布用パッケージをＰＣ監視クラ
イアント２０３ｄに対して送信する。ＰＣ監視サーバ２
０３ｄは受信したファイルをワークファイルとして格納
する。なお、ワークファイルはＰＣ・サーバ管理システ
ムでの汎用ファイルなるもので、配布用ファイルパッケ
ージ１００１ａの実態に該当するものである。

【０１２５】（４）拠点プラグイン２０３ｂは、ＰＣ監
視サーバ２０３ｄがファイルを格納したことを検知する
と、それを呼んでデバイス監視サーバ２０３ａに渡す。
デバイス監視サーバ２０３ａは、それを受けて指定され
たデバイスから、デバイス情報を収集して拠点プラグイ
ン２０３ｄに渡す。

【０１２６】（５）拠点プラグイン２０３ｂは、受信し
たデバイス情報を、所定の形式のファイル２０３ｅとし
て格納する。本実施例では以下に所定の形式としてＭＩ
Ｆ形式を例に説明を進めていくが、ＭＩＦ形式とは情報
管理系の一般的なファイル形式を指す。

【０１２７】（６）拠点プラグイン２０３ｂは、ワーク
ファイルを削除する。

【０１２８】（７）拠点プラグインは、ＭＩＦファイル
を作成した旨のイベントを作成してセンタサーバ１１０
に送信する。

【０１２９】（８）センタサーバ１１０はそのイベント
を受け、配布用ファイルパッケージを削除する。

【０１３０】（９）また、センタサーバ１１０は、拠点
プラグイン２０３ｂから受信したイベントが、正常な情
報収集の完了を通知するものであれば、共通情報収集モ
ジュール１１０２を起動し、拠点プラグインの作成した
ＭＩＦファイルを読み込ませてデバイス情報を収集させ
る。

【０１３１】（１０）共通情報収集モジュール１１０１
は、ＭＩＦファイル２０３ｅを読み、収集したデバイス
情報を獲得する。

【０１３２】（１１）共通情報収集モジュール１１０１
は獲得したデバイス情報をインベントリデータベースに
格納する。なお、インベントリデータベースは物理的ま
たは論理的にデバイス機器系とＰＣ・サーバ機器系のデ
ータベースとをそれぞれ有しており、対象機器に応じて
柔軟な処理を行うことができる。

【０１３３】（１２）センタサーバは拠点側のＭＩＦフ
ァイル２０３ｅを削除させる。

【０１３４】（１３）アプリケーションに完了通知を送
信する。

【０１３５】以上のようにして、デバイス監視サーバ２
０３ａが収集したデバイス情報をセンタサーバ１１０に
取得することができる。

【０１３６】＜ログデータアップロード手順＞図１２
は、拠点システムからセンタシステムへのログデータの
アップロード手順を説明するためのフローチャートであ
る。ログデータのアップロードは本実施形態では次のよ
うにして行われる。

【０１３７】（１）デバイス監視サーバ２０３ａは、拠
点プラグインに２０３ｂに対して、エラーや警告、それ
らの回数が閾値を超えたことを検知した旨の通知を発行
する。

【０１３８】（２）デバイス監視サーバ２０３ａは、拠
点プラグインに２０３ｄに対して前述した警告のイベン
トデータ発行する。

【０１３９】（３）拠点プラグイン２０３ｂは、ログデ
ータを、ＭＩＦ形式のファイル２０３ｅとして格納す
る。ＭＩＦ形式とは、前述で説明したとおり、情報管理
系の一般的なファイル・データ形式である。

【０１４０】（４）拠点プラグイン２０３ｂは、ＭＩＦ
ファイルを作成した旨のイベントを作成してセンタサー
バ１１０に送信する。

【０１４１】（５）センタサーバ１１０はそのイベント
を受け、共通情報収集モジュール１２０１を起動する。

【０１４２】（６）共通情報収集モジュール１２０１
は、拠点プラグイン２０３ｂの作成したＭＩＦファイル
２０３ｅを読み込ませてログファイルを読む。

【０１４３】（７）共通情報収集モジュール１１０１
は、獲得したデバイス情報をインベントリデータベース
１０９に格納する。

【０１４４】（８）センタサーバは拠点側のＭＩＦファ
イル２０３ｅを削除させる。

【０１４５】（９）アプリケーションに完了通知を送信
する。

【０１４６】以上のようにして、デバイス監視サーバ２
０３ａが作成したログデータファイルをセンタサーバ１
１０は取得することができる。

【０１４７】＜デバイスセンタサーバによる処理手順＞
次に、センタサーバ１１０、デバイス情報処理モジュー
ル９０１、拠点プラグイン２０３ｂ、ＰＣ監視クライア
ント２０３ｄによる処理手順を簡単に示す。図１３は、
センタサーバ１１０におけるイベント受信時の処理手順
を示すフローチャートである。イベントを受信すると、
図１３の処理が開始される。なお、以下の説明におい
て、メッセージとイベントは厳密に区別されていない。
イベントとは、イベントの発生を伝えるメッセージ、と
いう意味で使用している。

【０１４８】まず、受信したイベントを解析し（ステッ
プＳ１３０１）、その発行元が判定される（ステップＳ
１３０２）。発行元がＰＣ監視クライアント２０３ｄで
あれば、イベントモニタにより処理されて、障害イベン
トであればイベントリストに表示される（ステップＳ１
３０３）。

【０１４９】そのあとで、イベントがデバイス系である
か否か、すなわちそれが拠点プラグイン２０３ｂから発
行されたものか否かが判定され（ステップＳ１３０
４）、デバイス系であれば、イベントごとに応じてデバ
イス情報処理モジュールにより処理が行われる。この手
順が図１４乃至図１６に示されている。デバイス系でな
ければ、センタサーバ１１０によりイベントに応じた処
理が行われる。

【０１５０】一方、イベントの発行元がバックエンド、
すなわちアプリケーションシステムであれば、そのイベ
ントが情報収集を行わせるためのものかが判定され（ス
テップＳ１３０５）、そうであれば、情報収集要求を拠
点プラグインモジュール２０３ｂに対して発行する（ス
テップＳ１３０９）。情報収集要求は、その要求を行う
ための配布モジュール１００１に配布用ファイルパッケ
ージを作成し、それを配布させて行わせる。

【０１５１】情報収集要求のイベントでなければ、ダウ
ンロードを要求するためのイベントであるか判定する
（ステップＳ１３０６）。そのイベントでもなければ、
イベントに応じた処理をおこなってイベント待ちとな
る。

【０１５２】ダウンロード要求の場合には、ダウンロー
ドするデータをバックエンドから獲得し（ステップＳ１
３０７）、ダウンロードデータを拠点プラグイン２０３
ｂに対して配布する（ステップＳ１３０８）。

【０１５３】＜デバイス情報処理モジュールによる処理
手順＞図１３のステップＳ１３０４でデバイス系と判定
されたイベントは、更に詳細に分析されて、（１）ダウ
ンロード終了の通知イベント、（２）デバイス情報収集
終了のイベント、（３）ログデータアップロードの要求
のイベント、という３種の処理に分岐する。これらの処
理は、ぞれぞれ図１４乃至図１６のフローチャートの手
順となる。

【０１５４】（ダウンロード終了）図１４は、デバイス
情報処理モジュール９０１による、ダウンロード終了イ
ベントに対する処理手順を示すフローチャートである。
ダウンロードの終了が通知されると、まず配布ファイル
パッケージ１００１ａを削除し（ステップＳ１４０
１）、ダウンロードが終了したことをバックエンドに通
知する（ステップＳ１４０２）。

【０１５５】（デバイス情報の取得）図１５は、デバイ
ス情報処理モジュール９０１による、デバイス情報取得
（カウンタアップロード）の通知に対する処理手順を示
すフローチャートである。

【０１５６】まず、情報収集要求のために作成した配布
用ファイルパッケージ１００１ａを削除する（ステップ
Ｓ１５０１）。次に、データの取得が正常に行われてい
れば、情報収集モジュール１１１０１を起動し（ステッ
プＳ１５０３）、デバイス監視サーバ２０３ａに対して
デバイス情報の格納されたＭＩＦファイルを要求し、そ
れに対する応答であるＭＩＦファイルを受信する（ステ
ップＳ１５０４）。

【０１５７】そして受信したファイルをインベントリデ
ータベース１０９に格納し（ステップＳ１５０５）、デ
バイス監視サーバ２０３ａに対してＭＩＦファイルの削
除を要求する（ステップＳ１５０６）。最後にバックエ
ンドに対してデバイス情報の収集が終了したことを通知
する（ステップＳ１５０７）。

【０１５８】一方、ステップ１５０２で正常でないと判
定された場合には、その旨をバックエンドに対して通知
する（ステップＳ１５０８）。

【０１５９】以上のようにして、ＭＩＦファイルとして
作成されたデバイス情報をデバイス監視サーバ２０３ａ
から取得する。

【０１６０】（ログデータアップロード）図１６は、デ
バイス情報処理モジュール９０１による、ログデータア
ップロードの通知に対する処理手順を示すフローチャー
トである。

【０１６１】ログデータをアップロードする通知を受け
ると、共通情報処理モジュール１２０１を起動し（ステ
ップＳ１６０１）、ログデータを含むＭＩＦファイルの
送付要求をデバイス監視モジュール２０３ａに発行する
（ステップＳ１６０２）。

【０１６２】その要求への応答であるＭＩＦファイルを
受信し（ステップＳ１６０３）、それをインベントリデ
ータベース１０９へ格納する（ステップＳ１６０４）。
ＭＩＦファイルの削除要求をデバイス監視サーバ２０３
ａに対して発行し（ステップＳ１６０５）、それらの処
理が終了すると処理終了の旨をバックエンドに通知する
（ステップＳ１６０６）。

【０１６３】＜デバイス監視サーバによる処理手順＞図
１７は、拠点プラグイン２０３ｂにおいて、プラグイン
に対して発行されたメッセージあるいはイベントに対す
る処理手順を示すフローチャートである。なお、センタ
サーバ１１０から拠点プラグイン２０３ｂにあって発行
されたメッセージは、監視クライアント２０３ｄにより
所定の領域に格納されるために、拠点プラグイン２０３
ｂはそれを常時あるいは一定時間おきに監視し続けてい
る。

【０１６４】メッセージがあると、それがデバイス監視
サーバ２０３ａからのメッセージであるか判定し（ステ
ップＳ１７０１）、そうであれば、メッセージを解析し
て（ステップＳ１７０２）、警告や閾値越えであれば、
ログデータをＭＩＦファイルとして書き出し、ＰＣ監視
クライアント２０３ｄを介して、ログファイルのアップ
ロードを行う旨、センタサーバ１１０にあててイベント
を発行する（ステップＳ１７０５）。

【０１６５】警告や閾値越えではない場合には、エラー
であるか判定し（ステップＳ１７０６）、エラーであれ
ば障害イベントを示すメッセージを作成してステップＳ
１７０５へ分岐する。（ステップＳ１７０７）。

【０１６６】デバイス監視サーバ２０３ａからのメッセ
ージでない場合には、センタサーバ１１０からのメッセ
ージであると判定して、ＰＣ監視クライアント２０３ｄ
により書き出された所定の領域を読み出し（ステップＳ
１７０８）、そのデータを解析して内容に応じた処理を
遂行する。この解析した内容に応じた処理の詳細が図１
８に示されている。

【０１６７】図１８は、拠点プラグイン２０３ｂによ
る、センタサーバ１１０１から受信したメッセ維持に応
じた処理の手順を示すフローチャートである。

【０１６８】まず、それがダウンロードデータであるか
判定し（ステップＳ１８０１）、ダウンロードデータで
あれば、デバイス監視サーバ２０３ａに対してダウンロ
ードデータの受信を通知し（ステップＳ１８０２）その
データを渡す（ステップＳ１８０３）。そして、渡し終
えたデータを削除し（ステップＳ１８０４）、センタサ
ーバにあててダウンロード完了イベントを発行する（ス
テップＳ１８０５）。

【０１６９】ダウンロードデータでない場合には、デバ
イス情報の収集要求であるか判定し（ステップＳ１８０
６）、そうであれば、デバイス監視サーバ２０３ａに対
してデバイｓじょうほうの収集を要求する（ステップＳ
１８０７）。

【０１７０】それに応えてデバイス監視サーバ２０３ａ
からデバイス情報を受信すると（ステップＳ１８０
８）、それをＭＩＦファイルとして格納し（ステップＳ
１８０９）、デバイス情報を収集した旨のメッセージを
センタサーバ１１０にあてて発行する。

【０１７１】＜ＰＣ監視クライアントによる処理手順＞
図１９は、ＰＣ監視クライアントがメッセージを受信し
た場合の処理手順を示すフローチャートである。

【０１７２】図１９において、受信データの宛先がどこ
であるか判定し（ステップＳ１９０１）、ＰＣ・サーバ
といった汎用コンピュータにあてたデータであれば、指
定されたプロセスへとそのデータを渡し（ステップＳ１
９０２）、拠点プラグインであれば、前述した所定の領
域へとデータを書き込む。

【０１７３】以上のように、本実施形態のシステムで
は、汎用コンピュータ用の監視システムを用いて、監視
対象の汎用コンピュータと同じ被管理サイトに設置され
た周辺機器をも管理することができる。これにより、管
理サイトにおいては、汎用コンピュータと周辺機器とを
同様な方法で一元的に監視することができる。さらに、
周辺機器に関する情報の収集や、パラメータの設定等
を、その監視システムを通して管理サイト側から行え
る。また、被管理サイト側から、ログを管理サイトに対
して送信することができる。

【０１７４】さらに、汎用コンピュータ用の監視システ
ムに対して、周辺機器を管理するために付加するモジュ
ールは、すべてソフトウエア的に実現できるために、そ
のためのハードウエアを必要とせず、設置面積や機器の
費用、維持作業等、ハードウエア的な規模の増大を防止
できる。

【０１７５】また、本発明は汎用コンピュータ（ＰＣ・
サーバ系）の管理ソフトにデバイス系の管理情報を適合
させるものに限定されるものではなく、その逆、即ち周
辺機器（デバイス系）の管理ソフトにＰＣ・サーバ系の
管理情報を適合させるものにすることも可能である。例
えば、図９中のデバイス系２０１とＰＣ・サーバ系２０
２とを、デバイス監視サーバ２０３ａとＰＣ監視クライ
アントモジュール２０３ｄとを、それぞれ入れ替え、Ｍ
ＩＦファイル２０３ｅをデバイス固有のファイル形式に
し、拠点プラグイン２０３ｂにはＰＣ・サーバ系のフォ
ーマット形式をデバイス系のフォーマット形式に変換さ
せる機能を持たせ、また、センタサーバにデバイス系の
処理をさせ、デバイス処理モジュール９０１にＰＣ・サ
ーバ系の情報を処理させデバイスセンタにイベントを発
行させるなどの形態が考えられる。

【０１７６】＜センターコール＞上記で説明した第１の
遠隔サイト管理システム或いは第２の遠隔サイト管理シ
ステムにおいて、被管理サイトの顧客が管理サイトに電
話をしたときに、管理サイトで使用されるアプリケーシ
ョンシステムについて説明する。上記で説明した遠隔管
理サイト管理システムでは、オフィス内の機器で障害が
発生したときには、通常、その旨の通知がデバイス監視
サーバ２０３ａからデバイスセンタサーバへ送信され
る。

【０１７７】しかし、この通知とは別に、被管理サイト
の顧客が自ら異常を察知したとき、ただし、具体的に障
害を特定できなかったときには、顧客が直接管理サイト
に電話で通知（センターコール）する場合がある。この
場合、管理サイトのスタッフは顧客に対して或いは障害
に対して適切な対応をとらなければならず、そのため
に、このアプリケーションシステム（センターコール用
アプリケーションシステム）を利用する。

【０１７８】＜センターコール用アプリケーションシス
テム＞図２０〜図２２は、センターコール用アプリケー
ションシステムが行なう処理を示すフローチャートであ
る。まず、スタッフが顧客の電話番号を入力する入力画
面を表示し、電話番号の入力を待つ。そして、電話番号
が入力されると、その電話番号をキーにして、ユーザ情
報をインベントリデータベースから取得する（ステップ
Ｓ２００１）。そして、そのユーザ情報を表示画面に表
示する（ステップＳ２００２）。

【０１７９】図２３は、ユーザ表示画面の一例を示す図
である。この画面では、顧客の名前、部署、連絡先が表
示されている。また、機器一覧２３０２には、その顧客
先に設置されている機器が一覧表示される。図では、選
択ボタン２３０１で“ＡＬＬ”が選択されているため、
デバイス系機器、ＰＣ・サーバ系機器が全て表示されて
いる。ここで、“ＤＥＶＩＣＥ”が選択されるとデバイ
ス系機器だけが表示され、“ＰＣ”が選択されるとＰＣ
系機器が一覧表示される。

【０１８０】従って、スタッフは、顧客からの情報に基
づいて、デバイス系の障害が発生していると判断する
と、“ＤＥＶＩＣＥ”を選択する。また、ＰＣ・ネット
ワーク系の障害が発生していると判断すると、“ＰＣ”
を選択する。そして、いれずれとも食んだできなかった
場合には、“ＡＬＬ”を選択する。

【０１８１】一方、センターコール用アプリケーション
システムは、ユーザが“ＤＥＶＩＣＥ”、“ＰＣ”、
“ＡＬＬ”のいずれを選択したか判断する。まず、“Ｄ
ＥＶＩＣＥ”が選択ボタンにより選択されているか否か
に応じて、デバイス系の障害が発生したか否かを判定す
る（ステップＳ２００３）。デバイス系の障害発生して
いると判定した場合には、ステップＳ２１００に進む。
そうでなければ、ステップＳ２００４に進み、“ＰＣ”
が選択ボタンにより選択されているか否かに応じて、Ｐ
Ｃ・ネットワーク系の障害が発生したか否かを判定する
（ステップＳ２００４）。ＰＣ・ネットワーク系の障害
発生していると判定した場合には、ステップＳ２２００
に進み、そうでなければ、ステップＳ２００５に進む。

【０１８２】＜デバイス系の障害＞ステップＳ２００３
において、デバイス系の障害が発生していると判定した
場合には、ステップＳ２０１０に進み、デバイス監視サ
ーバに診断を行なわせるように要求を出す（ステップＳ
２０１０）。具体的には、情報収集を指示するメッセー
ジをデバイスセンタサーバへ送信する．すると、デバイ
スセンタサーバは、図５の処理によって、情報収集要求
をデバイス監視サーバに発行する。次に、デバイス監視
サーバからの情報をデバイスセンタサーバを介して受信
する（ステップＳ２０１１）。

【０１８３】そして、障害の内容が、デバイス監視サー
バによって切り分け可であるか否かを判定する（ステッ
プＳ２０１２）。切り分け可である場合とは、デバイス
監視サーバで障害が検出できた場合（例えば、受信した
情報に障害イベントが含まれている場合）などである。
切り分けが不可の場合には、修理Ａ（図２１）を行な
う。

【０１８４】切り分けが可の場合には、更に、その障害
が被管理サイトで復旧可であるか否かを判定する（ステ
ップＳ２０１３）。被管理サイトで復旧が不可の場合に
は、修理Ｂ（図２２）を行なう。復旧が可の場合には、
障害の内容がスタッフに分かるように表示する。例え
ば、図２４の表示画面では、レーザビームプリンタであ
る“ＬＢ１８１０”が電源ＯＦＦであることを点滅表示
する。すると、スタッフはその表示を見て、顧客にアド
バイスする。

【０１８５】＜ＰＣ・ネットワーク系の障害＞ステップ
Ｓ２００４において、ＰＣ・ネットワーク系の障害が発
生していると判定した場合には、ステップＳ２０２０に
進み、ＰＣ監視クライアントに診断を行なわせるように
要求を出す（ステップＳ２０２０）。具体的には、情報
収集を指示するメッセージをセンタサーバへ送信する。
すると、センタサーバは、情報収集要求をＰＣ監視クラ
イアントに発行する。次に、ＰＣ監視クライアントから
の情報をセンタサーバを介して受信する（ステップＳ２
０２１）。

【０１８６】そして、障害の内容が、ＰＣ監視クライア
ントによって切り分け可であるか否かを判定する（ステ
ップＳ２０２２）。切り分け可である場合とは、ＰＣ監
視クライアントで障害が検出できた場合（例えば、受信
した情報に障害イベントが含まれている場合）などであ
る。切り分けが不可の場合には、修理Ａ（図２１）を行
なう。

【０１８７】切り分けが可の場合には、更に、その障害
が被管理サイトで復旧可であるか否かを判定する（ステ
ップＳ２０２３）。被管理サイトで復旧が不可の場合に
は、修理Ｂ（図２２）を行なう。復旧が可の場合には、
障害の内容がスタッフに分かるように表示する。例え
ば、図２５の表示画面では、ネットワークルータである
“Ｒｏｕｔｅｒ−０１”が電源ＯＦＦであることを点滅
表示する。すると、スタッフはその表示を見て、顧客に
アドバイスする。

【０１８８】＜デバイス系又はＰＣ・ネットワーク系の
障害の判定＞ステップＳ２００３及びＳ２００４におい
て、デバイス系とＰＣ・ネットワーク系とのいずれの障
害とも判定できなかった場合には、具体的には、スタッ
フが、選択ボタン２３０１において、“ＡＬＬ”を選択
した場合には、ＰＣ監視クライアントとデバイス監視サ
ーバとのそれぞれに診断を行なわせるように要求を出す
（ステップＳ２００５）。具体的には、情報収集を指示
するメッセージをデバイスセンタサーバやセンタサーバ
へ送信する。すると、センタサーバは、情報収集要求を
ＰＣ監視クライアントに発行する。また、デバイスセン
タサーバは、情報収集要求をデバイス監視サーバへ発行
する。次に、デバイス監視サーバとＰＣ監視クライアン
トからの情報をデバイスセンタサーバとセンタサーバを
介して受信する（ステップＳ２００６）。

【０１８９】そして、障害の内容が、デバイス監視サー
バとＰＣ監視クライアントとの組み合わせによって切り
分け可であるか否かを判定する（ステップＳ２００
７）。切り分け可である場合とは、デバイス監視サーバ
やＰＣ監視クライアントで障害が検出できた場合（例え
ば、受信した情報に障害イベントが含まれている場合）
などである。切り分けが不可の場合には、修理Ａ（図２
１）を行なう。

【０１９０】切り分けが可の場合には、更に、その障害
が被管理サイトで復旧可であるか否かを判定する（ステ
ップＳ２００８）。被管理サイトで復旧が不可の場合に
は、修理Ｂ（図２２）を行なう。復旧が可の場合には、
障害の内容がスタッフに分かるように表示する。する
と、スタッフはその表示を見て、顧客にアドバイスす
る。

【０１９１】図２６は、ステップＳ２００７の判定にお
いて、切り分けが可の場合の事例である。コール内容
は、スタッフが顧客から電話で聞いた内容である。監視
結果は、ＰＣ監視クライアント及びデバイス監視サーバ
から送られてきた情報の内容である。

【０１９２】まず、１番目の事例では、ＰＣ１からプリ
ンタ１にプリントの指示が出されたが、プリント処理が
行なわれなかった。そこで、デバイス監視サーバとＰＣ
監視クライアントに診断を行なわせた結果、ＰＣ１及び
プリンタ１は正常であった。ただし、プリントサーバの
役割をしているＰＣのハードディスクの空き容量が２０
０Ｋバイトまで減っていた。そこで、プリントサーバの
ハードディスク容量が少なく、プリントデータが正しく
格納されない（スプールされない）と判定し、プリント
サーバのハードディスクの空き容量を確保するよう対処
すると判断した。

【０１９３】また、２番目の事例では、新しくＰＣ２を
セットアップして、プリンタの設定を行なったが、ＰＣ
２からプリンタ２は見えるが、プリンタ３は見えない。
そこで、デバイス監視サーバとＰＣ監視クライアントに
診断を行なわせた結果、ルータ１、プリンタ２、プリン
タ３は正常であった。ただし、ＰＣ２からの反応がなか
った。そこで、新規ＰＣ２は、デフォルトゲートウェイ
の設定が正しく行なわれずに、セグメントを越えての通
信ができなかったと判定し、ＰＣ２におけるデフォルト
ゲートウェイにルータ１のＩＰアドレスを設定するよう
対処すると判断した。

【０１９４】３番目の事例では、ＰＣ３からプリンタ４
にプリント指示を出したが、プリンタ処理が行なわれな
かった。そこで、デバイス監視サーバとＰＣ監視クライ
アントに診断を行なわせた結果、ＰＣ３は正常であった
が、プリンタ４でソータの接続不良が検出された。そこ
で、プリンタ４のソータが正しく接続されていないと判
定し、ソータを正しく接続するよう対処すると判断し
た。

【０１９５】＜修理Ａ＞図２１は、センターコール用ア
プリケーションシステムが、修理Ａを行なう場合の処理
を示すフローチャートである。修理Ａは、ステップＳ２
０１２、Ｓ２０２２、Ｓ２００７で、デバイス管理サー
バやＰＣ監視クライアントによる切り分けができないと
判定された場合に実行される。

【０１９６】修理Ａでは、障害の内容が切り分けされな
かったために、まず、サービスマンを被管理サイトへ向
かわせる（ステップＳ２１０１）。具体的には、サービ
スマンが持っている情報携帯端末、例えば、ノートパソ
コンや携帯電話にディスパッチ情報を送信し、図２７の
ような表示画面を情報携帯端末に表示させる。

【０１９７】図２７は、サービスマンの情報携帯端末に
表示されるディスパッチ画面の一例でである。ここで
は、まず、向い先の顧客情報（顧客名や電話番号）を表
示する。そして、現地に向えるかどうか、向える場合に
は何分で到着できるかをサービスマンに入力させ、その
内容を受信する。

【０１９８】次に、顧客先に向ったサービスマンからの
障害報告を待ち、それを受信する（ステップＳ２１０
２）。この障害報告は、被管理サイトのデバイス監視サ
ーバやＰＣ監視クライアントでサービスマンによって入
力され、それをデバイスセンタサーバやセンタサーバを
介して受信する。その障害報告に基づいて、障害が自社
で対処可能であるか否かを判定する（ステップＳ２１０
２）。

【０１９９】自社で対応可能な場合には、そのままサー
ビスマンが復旧作業を行なうので、復旧が確認されるの
を待つ（ステップＳ２１０４）。デバイス監視サーバ或
いはＰＣ監視クライアントから受信された情報により、
復旧が確認されたのち処理を終了する。

【０２００】自社で対応不可能な場合には、協力会社へ
作業依頼を出す（ステップＳ２１０５）。自社が主にデ
バイス系の機器を扱っていて、ＰＣ系の障害が発生した
場合には、その復旧作業（メンテナンスサービス）を協
力会社にお願いするためである。ここで、図２８に示す
ような依頼書が電子メールで協力会社に送られるものと
する。この依頼書には、ユーザ情報の他、障害が発生し
ている機器の機器情報も盛り込まれる。障害が発生して
いる機器の特定は、ステップＳ２１０２における障害報
告に基づいて行なわれる。ステップＳ２１０５では、依
頼書のテンプレートとなるファイルをまず読み出し、そ
こに、ステップＳ２００１で引き出したユーザ情報を埋
め込む。次に、障害内容をもとに機器を特定し、その機
器に関する機器情報を埋め込む。更に、受信された障害
内容をコメントとして所定の欄に埋め込む。そのファイ
ルを電子メールに添付して協力会社に送信する。

【０２０１】協力会社のサービスマンがメンテナンス作
業を行なうので、それが終了し、復旧が確認されるのを
待つ（ステップＳ２１０６）。更に、協力会社から、図
２９のような作業レポートを電子メールで受信する（ス
テップＳ２１０６）。

【０２０２】図２９は、協力会社からの作業レポートの
一例を示す図である。このレポートには、作業を行なっ
た時間、メンテナンス対象機器の機種名とシリアル番
号、障害の原因、処置内容が示されている。また、メン
テナンス代行に対する料金を、のちにこの協力会社に支
払うために、作業レポートの内容に関する情報を依頼履
歴としてデータベースに格納しておく（ステップＳ２１
０８）。

【０２０３】＜修理Ｂ＞図２２は、センターコール用ア
プリケーションシステムが、修理Ｂを行なう場合の処理
を示すフローチャートである。修理Ｂは、ステップＳ２
０１３、Ｓ２０２３、Ｓ２００８で、被管理サイトでの
復旧ができないと判定された場合に実行される。

【０２０４】修理Ｂでは、既に障害内容が把握されてい
るので、まず、デバイス監視サーバやＰＣ監視クライア
ントからの情報をもとに障害レポートを作成する（ステ
ップＳ２２０１）。図３０は、障害レポートの一例を示
す図である。障害レポートには、障害が発生した時刻、
障害が発生した機器の機種名及びシリアル番号、障害の
原因、障害への対処方法が示されている。

【０２０５】次に、障害が自社で対処可能であるかを判
定する（ステップＳ２２０２）。自社で対処可能である
場合には、サービスマンを被管理サイトへ向わせる（ス
テップＳ２１０３）。具体的には、図２１のステップＳ
２１０１と同様にである。更に、障害レポートを電子メ
ールに添付してサービスマンの情報携帯端末に送信し、
必要な部品の手配処理を行なう（ステップＳ２２０
４）。そして、顧客先に向ったサービスマンが復旧作業
を行ない、復旧が確認されるのを待つ（ステップＳ２２
０５）。デバイス監視サーバ或いはＰＣ監視クライアン
トから受信された情報により、復旧が確認されたのち処
理を終了する。

【０２０６】自社で対応不可能な場合には、協力会社へ
作業依頼を出す（ステップＳ２２０６）。ここでは、図
２１のステップＳ２１０５と同様に、依頼書が電子メー
ルで協力会社へ送られる。それとともに、障害レポート
も電子メールで協力会社へ送られる。協力会社のサービ
スマンがメンテナンス作業を行なうので、それが終了
し、復旧が確認されるのを待つ（ステップＳ２２０
７）。更に、協力会社から、図２９のような作業レポー
トを電子メールで受信する（ステップＳ２２０８）。メ
ンテナンス代行に対する料金を、のちにこの協力会社に
支払うために、作業レポートの内容に関する情報を依頼
履歴としてデータベースに格納しておく（ステップＳ２
２０９）。

【０２０７】＜その他の実施の形態＞なお、本発明の目
的は、前述した実施形態の機能を実現するソフトウェア
のプログラムコードを記録した記憶媒体を、システムあ
るいは装置に供給し、そのシステムあるいは装置のコン
ピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納さ
れたプログラムコードを読み出し実行することによって
も達成される。

【０２０８】この場合、記憶媒体から読み出されたプロ
グラムコード自体が本発明の新規な機能を実現すること
になり、そのプログラムコードに記憶した記憶媒体は本
発明を構成することになる。

【０２０９】また、デバイス情報データは、画像処理装
置及び画像データ展開装置に内蔵されているＨＤＤ、外
部接続されている記憶媒体、画像データ展開装置からア
クセス可能なサーバ等に保持されていても構わない。さ
らに、デバイス情報データはユーザが任意に設定したも
のを使用することが可能であっても構わない。

【０２１０】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピーディスク、ハードディ
スク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、Ｃ
Ｄ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモ
リカード、ＲＯＭなどを用いることができる。

【０２１１】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述した実施形態の機
能が実現されるだけでなく、そのプログラムコードの指
示に基づき、コンピュータ上で稼動しているＯＳ（オペ
レーティングシステム）などが、実際の処理の一部また
は全部を行い、その処理によって前述した実施の形態の
機能が実現される場合も含まれる。

【０２１２】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部または全部を行
い、その処理によって前述した実施形態の機能が実現さ
れる場合も含まれる。

【０２１３】本発明を上記記憶媒体に適用する場合、そ
の記憶媒体には、先に説明した（図５乃至図７、図１３
乃至図１９、図２０乃至図２２に示す）フローチャート
に対応するプログラムコードが格納されることになる。

【０２１４】

【発明の効果】本発明は、管理サイトが、オフィスにお
けるＰＣ・サーバ系の機器とデバイス系の機器との双方
を一元的に管理できる。

【０２１５】特に、オフィスのサービス対象の機器がエ
ラーを起こし、オフィスの顧客が保守サービス会社に電
話で通知（センターコール）したときに、エラー発生に
的確に対応し、スムーズにメンテナンスの手配（サービ
スマンの手配、他のサービス会社への代行メンテナンス
依頼）を行なうことができる。

【０２１６】特に、エラーの内容が把握できる場合に
は、障害レポートを作成し、メンテナンスに向うサービ
スマンがその障害レポートをもとに迅速にメンテナンス
作業を行なえるようにし、また、エラーの内容が把握で
きない場合には、まず先にサービスマンをこきょく先に
向わせるようにすることで、サービスマンに、エラー発
生に対して迅速に行動をとらせることができる。

【０２１７】また、自社がエラーに対処可能であるか否
かを判定することにより、対処可能である場合には自社
のサービスマンを自動的に手配し、退社可能でない場合
には協力会社に自動的にメンテナンス代行を依頼するこ
とができる。

【図面の簡単な説明】

【図１】被管理サイトと管理サイトの構成を示すブロッ
ク図である。

【図２】本遠隔サイト管理システムのソフトウエアモジ
ュールの構成を示すブロック図である。

【図３】各ＰＣ及びサーバであるコンピュータの構成を
示すブロック図である。

【図４】拠点システムとセンタシステムとの間で行われ
る、データの交換の手順を説明するためのブロック図で
ある。

【図５】デバイスセンタサーバにおけるメッセージ受信
時の処理手順を示すフローチャートである。

【図６】デバイス監視サーバ２０３ａにおいて発生した
イベントに対する処理手順を示すフローチャートであ
る。

【図７】デバイス監視サーバ２０３ａが、デバイスセン
タサーバ２１０から受信したメッセージを受信する手順
を示すフローチャートである。

【図８】デバイスセンタサーバ２１０とデバイス監視サ
ーバ２０３ａとの間で交換されるメッセージフォーマッ
トの一例を示す図である。

【図９】本実施形態の遠隔サイト管理システムのソフト
ウエアモジュールの構成を示すブロック図である。

【図１０】拠点システムとセンタシステムとの間で行わ
れる、デバイスへの設定値のダウンロードの手順を説明
するためのフローチャートである。

【図１１】拠点システムとセンタシステムとの間で行わ
れる、カウントデータのアップロード、すなわちデバイ
ス情報収集の手順を説明するためのフローチャートであ
る。

【図１２】拠点システムからセンタシステムへのログデ
ータのアップロード手順を説明するためのフローチャー
トである。

【図１３】センタサーバ１１０におけるイベント受信時
の処理手順を示すフローチャートである。

【図１４】デバイス情報処理モジュール９０１による、
ダウンロード終了イベントに対する処理手順を示すフロ
ーチャートである。

【図１５】デバイス情報処理モジュール９０１による、
デバイス情報取得（カウンタアップロード）の通知に対
する処理手順を示すフローチャートである。

【図１６】デバイス情報処理モジュール９０１による、
ログデータアップロードの通知に対する処理手順を示す
フローチャートである。

【図１７】拠点プラグイン２０３ｂにおいて、プラグイ
ンに対して発行されたメッセージあるいはイベントに対
する処理手順を示すフローチャートである。

【図１８】拠点プラグイン２０３ｂによる、センタサー
バ１１０１から受信したメッセ維持に応じた処理の手順
を示すフローチャートである。

【図１９】ＰＣ監視クライアントがメッセージを受信し
た場合の処理手順を示すフローチャートである。

【図２０】センターコール用アプリケーションシステム
が行なう処理を示すフローチャートである。

【図２１】センターコール用アプリケーションシステム
が、修理Ａを行なう場合の処理を示すフローチャートで
ある。

【図２２】センターコール用アプリケーションシステム
が、修理Ｂを行なう場合の処理を示すフローチャートで
ある。

【図２３】ユーザ表示画面の一例を示す図である。

【図２４】復旧の指示をする表示画面の一例を示す図で
ある。

【図２５】復旧の指示をする表示画面の一例を示す図で
ある。

【図２６】切り分けが可の場合の事例を示す図である。

【図２７】ディスパッチ画面の一例を示す図である。

【図２８】依頼書の内容を示す図である。

【図２９】作業レポートの内容を示す図である。

【図３０】障害レポートの内容を示す図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 9/00 ３１１ Ｈ０４Ｑ 9/00 ３１１Ｊ ３２１ ３２１Ｅ (72)発明者 原 寛行 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内 (72)発明者 廣瀬 淳一 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内 (72)発明者 大森 和志 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内 (72)発明者 川島 真 東京都大田区下丸子３丁目30番２号キヤノ ン株式会社内 Ｆターム(参考） 5B089 GA11 HA06 JA35 JB10 KA12 KB04 LB15 5K048 AA02 BA10 CA08 DA02 DA05 DC04 DC07 EA11 EB08 EB12 FB04 FB08 FC01 GB08 HA01 HA02 HA05 HA07 HA13 HA22 HA23 5K101 KK13 LL01 LL03 LL05 MM05 MM07 NN03 NN18 NN21 NN35 RR12 SS07 TT06 UU16

Claims (40)

【特許請求の範囲】
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. 【請求項３２】 前記診断制御ステップは、前記第１ロ
    ーカルサーバに対して、又は前記第２ローカルサーバに
    対して、又は前記第１ローカルサーバと前記第２ローカ
    ルサーバとに対して、診断要求を発行することを特徴と
    する請求項３１に記載の機器管理方法。
33. 【請求項３３】 前記ローカルネットワークに接続され
    ている機器の一覧を表示部に表示させる表示制御ステッ
    プを有することを特徴とする請求項３１或いは３２に記
    載の機器管理方法。
34. 【請求項３４】 前記第１ローカルサーバ又は前記第２
    ローカルサーバによって障害が特定されない場合、復旧
    作業に向うようにサービスマンに通知する第１通知ステ
    ップを有することを特徴とする請求項３１乃至３３のい
    ずれかに記載の機器管理方法。
35. 【請求項３５】 前記第１通知ステップは、サービスマ
    ンが所有する携帯端末に、復旧作業に向う向かい先を示
    す情報を送信することを特徴とする請求項３４に記載の
    機器管理方法。
36. 【請求項３６】 前記第１ローカルサーバ又は前記第２
    ローカルサーバによって障害が特定される場合、障害内
    容を示すレポート情報を生成するレポート生成ステップ
    を有することを特徴とする請求項３１乃至３５のいずれ
    かに記載の機器管理方法。
37. 【請求項３７】 障害に対して自社が対応できない場
    合、復旧作業の依頼を他社に通知する第２通知ステップ
    を有することを特徴とする請求項３１乃至３６のいずれ
    かに記載の機器管理方法。
38. 【請求項３８】 前記第１タイプの機器は周辺機器であ
    り、前記第２タイプの機器はコンピュータ機器であるこ
    とを特徴とする請求項３１乃至３７のいずれかに記載の
    機器管理方法。
39. 【請求項３９】 前記第１タイプの機器は、プリンタ、
    複写機、スキャナのうちの少なくとも一つであることを
    特徴とする請求項３８に記載の機器管理方法。
40. 【請求項４０】 前記第２タイプの機器は、パーソナル
    コンピュータ、サーバコンピュータ、ネットワーク機器
    のうちの少なくとも一つであることを特徴とする請求項
    ３８に記載の機器管理方法。