JP2002157357A

JP2002157357A - 機器管理装置、機器管理プログラム、機器管理プログラムが格納された記録媒体、及び機器管理方法

Info

Publication number: JP2002157357A
Application number: JP2000351263A
Authority: JP
Inventors: Yasujirou Katayama; 康二朗片山; Shinichi Nakamura; 真一中村; Hiroyuki Hara; 寛行原; Junichi Hirose; 淳一廣瀬; Kazuyuki Omori; 和志大森; Makoto Kawashima; 真川島
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-11-17
Filing date: 2000-11-17
Publication date: 2002-05-31
Anticipated expiration: 2020-11-17
Also published as: JP4185661B2; US20020073356A1; US7017071B2; US20060107088A1

Abstract

(57)【要約】【課題】顧客先のコンピュータと周辺機器とを一元的
に管理する遠隔サイト管理システムを提供する。【解決手段】遠隔サイト管理システムが、オフィスの
ＰＣ・サーバ系の機器とデバイス系の機器との障害情報
及び予兆情報を自動的に受信し、顧客になにも意識させ
ることなく、メンテナンスサービスを提供し、更に、実
際にメンテナンスサービスを行なうサービス会社への依
頼書の送付処理、サービス会社からの作業報告書の受信
処理を一本化することができる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

【０００７】

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

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

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

【００１０】特に、管理サイトが、オフィスのＰＣ・サ
ーバ系の機器とデバイス系の機器との障害情報及び予兆
情報を自動的に受信し、顧客になにも意識させることな
く、メンテナンスサービスを提供し、更に、実際にメン
テナンスサービスを行なうサービス会社への依頼書の送
付、サービス会社からの作業報告書を一本化することを
目的とする。

【００１１】また、カウンタ情報と障害履歴を用いて、
オフィス環境での機器の稼動報告書を顧客に提供するこ
とを目的とする。

【００１２】

【課題を解決するための手段】本発明は、ネットワーク
を介して機器を管理する場合に、前記機器の障害を示す
データを受信すし、障害が検知されるのに応じて、作業
依頼書を示すデータを作成し、複数の会社のうち、前記
機器の復旧作業を行なう会社を選択し、選択された会社
宛てに、前記生成手段により生成された作業依頼書を示
すデータを送信するよう制御することを特徴とする。

【００１３】また、本発明では、送信された作業依頼書
を示すデータに対する、作業報告書を示すデータを会社
から受信することを特徴とする。

【００１４】さらに、本発明では、作業依頼書を示すデ
ータが作成される際に、当該作業依頼に対する識別子を
発行し、発行された識別子と共に、当該作業依頼の状態
を管理する。

【００１５】さらに、本発明では、前記作業依頼書を示
すデータとともに、前記発行手段により発行された識別
子を送信するように制御し、前記作業報告書を示すデー
タとともに、前記送信制御手段により送信された識別子
を受信し、受信された前記作業報告書を示すデータに基
づいて、受信された識別子に対応する作業依頼の状態を
変更することを特徴とする。

【００１６】さらに、本発明では、電子メールにおいて
前記作業依頼書を示すデータを送信することを特徴とす
る。

【００１７】さらに、本発明では、障害が検知された機
器を識別する機器情報を受信し、受信された前記機器情
報をに基づいて、会社を選択することを特徴とする。

【００１８】さらに、本発明では、検知された障害を識
別する障害情報を受信し、受信された障害情報を、前記
作業依頼書を示すデータに埋め込むことを特徴とする。

【００１９】さらに、本発明では、受信された障害情報
により識別される障害の対応方法を示すデータを、前記
作業依頼書を示すデータに埋め込むことを特徴とする。

【００２０】さらに、本発明では、検知された障害の対
応者を判断し、前記対応者が前記機器を有する顧客であ
ると判断されるのに応じて、前記顧客に関する顧客情報
と、検知された障害の対処方法を示すメッセージを表示
部に表示させることを特徴とする。

【００２１】さらに、本発明では、前記対応者が会社で
あると判断されるのに応じて、会社を選択することを特
徴とする。

【００２２】また、本発明は、ネットワークを介して機
器を管理する場合に、前記機器の障害を示すデータを受
信し、障害が検知されるのに応じて、作業依頼書を示す
データを作成し、前記機器の復旧作業を行なう会社宛て
に、前記生成手段により生成された作業依頼書を示すデ
ータを送信するよう制御するとともに、前記機器のカウ
ント情報を取得し、取得されたカウンタ情報に基づい
て、前記機器の稼動報告書を示すデータを作成し、さら
に、障害が複数回発生した機器を示す機器情報を、前記
稼動報告書を示すデータに埋め込むことを特徴とする。

【００２３】また、本発明は、ネットワークを介して機
器を管理する場合に、前記機器の障害を示すデータを受
信し、障害が検知されるのに応じて、作業依頼書を示す
データを作成し、前記機器の復旧作業を行なう会社宛て
に、前記生成手段により生成された作業依頼書を示すデ
ータを送信するよう制御し、作業依頼書を示すデータが
作成される際に、当該作業依頼の状態を管理するととも
に、前記機器のカウント情報を取得し、取得されたカウ
ンタ情報に基づいて、前記機器の稼動報告書を示すデー
タを作成し、さらに、前記管理手段により管理されてい
る作業依頼の状態に基づいて、当該作業依頼が処理され
ていない機器を示す機器情報を、前記稼動報告書を示す
データに埋め込むことを特徴とする。

【００２４】また、本発明は、ネットワークを介して機
器を管理する場合に、前記機器の障害を示すデータを受
信し、障害が検知されるのに応じて、作業依頼書を示す
データを作成し、前記機器の復旧作業を行なう会社宛て
に、前記生成手段により生成された作業依頼書を示すデ
ータを送信するよう制御するとともに、前記機器のカウ
ント情報を取得し、取得されたカウンタ情報に基づい
て、前記機器の稼動報告書を示すデータを作成し、さら
に、障害が発生していない機器を示す機器情報を、前記
稼動報告書を示すデータに埋め込むことを特徴とする。

【００２５】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１８０】＜サービス作業依頼＞上記で説明した第１
の遠隔サイト管理システム或いは第２の遠隔サイト管理
システムにおいて、顧客先のオフィスで機器に障害が発
生したときに、センタシステムが、その旨を通知を受
け、それに対処する処理を説明する。特に、発生した障
害が顧客によって対応できない場合に、作業依頼書を作
成し、サービス会社へメンテナンスサービスを依頼する
処理について説明する。

【０１８１】図２０は、障害発生の通知を受けて、メン
テナンスサービスを遂行するために、管理サイト（セン
タシステム）で使用されるアプリケーションシステムが
処理する内容を示すフローチャートである。

【０１８２】まず、被管理サイトのＰＣ・サーバ系の機
器やデバイス系の機器において障害発生すると、障害イ
ベントが、デバイス監視サーバやＰＣ監視クライアント
からデバイスセンタサーバやセンタサーバに通知され
る。そして、更に、アプリケーションシステムは、その
障害イベントを受ける（ステップＳ２００１）。図２１
は、障害イベントのデータ構造を示す図である。障害イ
ベントのデータには、障害が発生した機器の機番（シリ
アル番号）、障害が発生した発生日時、障害の内容を示
す障害コード、障害が発生した機器の機器区分を示すＰ
Ｃ／デバイス区分（ＰＣ系であるか、デバイス系である
か）が含まれる。

【０１８３】すると、障害に含まれている、機番（或い
はシリアル番号）、発生日時、障害コード、ＰＣ／デバ
イス区分を取得する（ステップＳ２００２）。そして、
必要に応じて、図２１や図２２のような表示画面を表示
部に表示する。

【０１８４】図２２は、障害リストを示す表示画面であ
る。発生した障害ごとに、その障害が発生した日時、そ
の障害が発生した機器のＰＣ／デバイス区分（ＰＣ系で
あるか、デバイス系であるか）、その障害の内容を示す
障害コード、その障害が発生した機器の機番（或いはシ
リアル番号）をリスト表示している。

【０１８５】図２３は、顧客の機器ごとに発生した障害
を示す表示画面である。まず、左上には、顧客の情報と
してユーザ情報が表示される。また、右上には、対象と
なる機器に関する機器情報が表示される。そして、下に
は、その顧客のオフィスに設置されたその機器において
発生した障害の履歴が表示される。履歴情報には、発生
した障害ごとに、その障害が発生した日時、その障害の
内容を示す障害コード、その障害の種別、その障害が発
生した機器における箇所（位置）、その障害に関する備
考が表示される。

【０１８６】つぎに、障害コードとＰＣ／デバイス区分
とに基づいて、その障害に対応すべき対応者を判定す
る。判定する際には、図２４のテーブルを用いる。な
お、図２４のテーブルは、図２のイベントリデータベー
ス１０９に格納されている。

【０１８７】図２４は、障害コードマスタテーブルを示
す図である。このテーブルには、障害のタイプ別に、そ
の障害の障害コード、その障害が発生した機器のＰＣ／
デバイス区分、その障害に対応すべき対応者区分（顧客
であるか、サービスマンであるか）、その招待に対する
対応方法が格納されている。

【０１８８】従って、ステップＳ２００３では、障害コ
ードとＰＣ／デバイス区分を検索キーにして、その障害
に対する対応者を割り出す。対応者が「顧客」になって
いる場合にはステップＳ２００４に進み、対応者が「サ
ービス」になっている場合には、ステップＳ２００６に
進む。

【０１８９】ステップＳ２００４では、障害イベントに
含まれていた機番（シリアル番号）から顧客情報を所得
する。顧客情報を所得する際には、まず、図２５のテー
ブルを用いて、機番（シリアル番号）に対応する顧客コ
ード、顧客サブコードを割り出す。図２５は、機番（シ
リアル番号）マスタテーブルを示す図である。ここに
は、機器ごとに、その機器の機番（シリアル番号）、そ
の機器のメーカ名、その機器を所有する顧客の顧客コー
ド及び顧客サブコード、その機器の設置場所、その機器
のメンテナンスサービスを行なっているサービス会社コ
ードが格納されている。

【０１９０】そして、障害コードと顧客サブコードが割
り出されると、つぎに、図２６のテーブルを用いて、顧
客コードと顧客サブコードとに対応する顧客情報を引き
出す。図２６は、顧客マスタテーブルを示す図である。
ここには、顧客ごとに、その顧客の顧客コード、その顧
客の顧客サブコード、その顧客の会社名、その顧客の部
署名、その顧客の住所、その顧客の電話番号、その顧客
のＦＡＸ番号、その顧客の電子メールアドレス、その顧
客の担当者、その顧客の契約レベル、その顧客のＰＣ系
機器のメンテナンスサービスを行なうサービス会社コー
ド、その顧客のデバイス系機器のメンテナンスサービス
を行なうサービス会社コードが格納されている。なお、
顧客コードと顧客サブコードとは、同じ会社の違う部署
を区別するために使われ、その場合には、顧客コードは
会社を示し、顧客サブコードは部署を示す。

【０１９１】最後に、先ほどの図２４の障害コードマス
タテーブルを用いて、障害コードに対応する対処方法を
引き出す。そして、図２７のような表示画面をディスプ
レイに表示する（ステップＳ２００５）。図２７は、対
応方法表示画面を示す図である。この画面には、顧客の
ユーザ情報、障害が発生した機器の機器情報、発生した
障害に対する対処方法が表示されている。従って、セン
タシステムのオペレータが、この画面を見ながら、顧客
先に電話をかけ、機器に障害が発生していること、その
障害の対処方法を伝える。

【０１９２】一方、ステップＳ２００６以降では、作業
依頼を作成する処理に進む。そのためにまず、トラブル
チケットＩＤ（トラブルＩＤとも言う）を発行する（ス
テップＳ２００６）。トラブルチケットＩＤとは、作業
依頼を識別するＩＤであり、作業以来ごとに発行され
る。そして、新しいトラブルチケットＩＤが発行される
たびに、図２８のようなテーブルに登録され、その作業
依頼の依頼内容や作業経過を管理するために使用され
る。なお、トラブルチケットＩＤは、一例としては、
“日付＋連番”で付けられる。

【０１９３】図２８は、トラブルチケットテーブルを示
す図である。ここでは、作業依頼ごとに、その作業依頼
のトラブルチケットＩＤ、その作業依頼の状態（経過状
況）、その作業依頼の発生日時、その作業依頼に対する
対応日時（作業日時）、その作業依頼の顧客コード及び
顧客サブコード、その作業依頼の機器の機番（シリアル
番号）、その作業依頼に対する作業を実施する実施サー
ビス会社のサービス会社コード、その作業依頼に対する
作業の実施者名、その作業依頼における障害原因、その
作業依頼に対する対処内容が格納されている。

【０１９４】つぎに、作業依頼書を作成する（ステップ
Ｓ２００７）。作業依頼書を作成する処理は、後に説明
する。作業依頼書を作成した後は、それを電子メールで
サービス会社に送付する（ステップＳ２００８）。この
とき、電子メールの内容そのものが作業依頼書になって
いてもいいし、作業依頼書を示すファイルが電子メール
に添付されていてもよい。

【０１９５】その後、サービス会社が、サービスを行な
って、作業報告書を送付してくるのを待って、作業報告
書を電子メールで受信する（ステップＳ２００８）。こ
のときも、電子メールの内容そのものが作業報告書にな
っていてもいいし、作業報告書を示すファイルが電子メ
ールに添付されていてもよい。

【０１９６】いずれにしても、電子メールの件名（Ｓｕ
ｂｊｅｃｔ）欄には、この作業依頼に対するトラブルチ
ケットＩＤが記載されているので、そのトラブルチケッ
トＩＤを認識する（ステップＳ２００９）。そして、図
２８のトラブルチケットテーブルにおいて、認識したト
ラブルチケットＩＤに対応する状態を「対応済み」に変
更する。また、作業報告書の原因、対処の欄に記載され
ているメッセージ（テキストデータ）を、トラブルチケ
ットテーブルの原因、対処の欄に格納する。

【０１９７】＜作業依頼書作成・送付＞図２９は、図２
０のステップＳ２００７の、作業依頼書を作成・送付す
る処理を示すフローチャートである。まず、作業依頼書
兼作業報告書のテンプレートファイルを読み出す（ステ
ップＳ２９０１）。この実施例では、作業依頼書と作業
報告書を一枚のシートにまとめることとしたが、別々の
シートで実装されてもよい。

【０１９８】図３０は、作業依頼書兼作業報告書のテン
プレートファイルを示す図である。このテンプレートフ
ァイルには、トラブルチケットＩＤ（トラブルＩＤ）、
障害の発生時刻、顧客のユーザ情報、故障が発生した機
器の機器情報、障害コード、障害に対する対処内容、原
因、対処が埋め込まれるようになっている。

【０１９９】従って、図２０のステップＳ２００６で発
行したトラブルチケットＩＤを埋め込む（ステップＳ２
９０２）。つぎに、図２０のＳ２００２で得た発行日時
を埋め込む（ステップＳ２９０３）。つぎに、図２０の
Ｓ２００４と同様にして顧客情報（ユーザ情報）を引き
出し、それを埋め込む（ステップＳ２９０４）。つぎ
に、図２０のＳ２００４と同様にして機器情報を引き出
し、それを埋め込む（ステップＳ２９０５）。つぎに、
図２０のステップＳ２００５同様にして対処内容を引き
出し、ステップＳ２００２で得た障害コードと対処内容
を埋め込む（ステップＳ２９０６）。

【０２００】つぎに、図２６を用いて得た顧客情報に含
まれる契約レベルがいずれかを判断する（ステップＳ２
９０７）。レベル１の場合には、緊急に対処すべく、対
応期限を２時間後に設定し、それを埋め込む（ステップ
Ｓ２９０８）。レベル２の場合には、対応期限を４時間
後に設定し、それを埋め込む（ステップＳ２９０９）。
レベル４の場合には、対応期限を翌日に設定し、それを
埋め込む（ステップＳ２９１０）。

【０２０１】つぎに、図３１のテーブルを用いて、サー
ビス会社の電子メールアドレス（Ｅｍａｉｌアドレス）
を引き出す（ステップＳ２９１１）。そのためにまず、
サービス会社コードを特定する。図２６の顧客マスター
テーブルを用いて、図２０のＳ２００２で得たＰＣ／デ
バイス区分が「ＰＣ」の場合には、ＰＣ系サービス会社
コードを読み出し、ＰＣ／デバイス区分が「デバイス」
の場合には、デバイス系サービス会社コードを読み出
す。そして、図３１のテーブルを用いて、そのサービス
会社コードに対応する会社の電子メールアドレスを引き
出す。

【０２０２】図３１は、サービス会社マスターテーブル
を示す図である。ここには、サービス会社ごとに、その
会社のサービス会社コード、その会社のサービス区分、
その会社の会社名、その会社の部署名、その会社の住
所、その会社の電話番号、その会社のＦＡＸ番号、その
会社のＥｍａｉｌアドレス、その会社の担当者が格納さ
れている。なお、この実施例では、各会社の部署ごとに
異なるサービス会社コードを割り当てている。

【０２０３】最後に、電子メールの件名にトラブルチェ
ックＩＤを記入し、情報が埋められた作業依頼書兼作業
報告書のテンプレートファイルを電子メールに添付し
て、ステップＳ２９１１で得た電子メールアドレス宛て
に電子メールを送付する（ステップＳ２９１２）。

【０２０４】＜作業報告書作成・送付＞一方、サービス
会社に設置されているコンピュータは、作業依頼書付の
電子メールを受信する（ステップＳ２０５０）。そし
て、添付されている作業依頼書兼作業報告書の内容をデ
ィスプレイに表示する。すると、サービス会社のサービ
スマンが、その作業依頼書の中身を見て、顧客先に向
い、作業を行なう。

【０２０５】つぎに、サービス会社のコンピュータは、
作業報告書の作成・送付の処理を行なう。図３２は、作
業報告書作成・送付の処理を示すフローチャートであ
る。まず、図２０のＳ２０５０で受信した作業依頼書兼
作業報告書のファイルを読み出す（ステップＳ３２０
１）。そして、キーボードから入力された原因に関する
メッセージ、対処に関するメッセージ、担当者を作業依
頼書兼作業報告書のファイルに埋め込む（ステップＳ３
２０２）。そして、電子メールの件名にこの作業依頼に
対するトラブルチケットＩＤを記載し、作成した作業依
頼書兼作業報告書のファイルを電子メールに添付して、
電子メールを送付する。

【０２０６】＜稼動報告書作成＞もうひとつ、遠隔サイ
トシステムのもう一つの機能として、稼動報告の処理を
説明する。図３５は、稼動報告書のテンプレートファイ
ルを示す図である。ここには、当月使用枚数、用途別使
用枚数、用紙別使用枚数率、障害履歴などが埋め込まれ
るようになっている。

【０２０７】図３３は、顧客に対して機器の稼動報告を
行なうために、管理サイト（センタシステム）で使用さ
れるアプリケーションシステムが処理する内容を示すフ
ローチャートである。

【０２０８】まず、月次に、所定の機器のカウンタ情報
を取得要求するコマンドを、被管理サイトのデバイス監
視サーバに送信する（ステップＳ３３０１）。そして、
カウンタ情報を受信し、図３４に示すテーブルに格納す
る。図３４は、カウンタテーブルを示す図である。ここ
では、機器の月別の稼動情報、具体的には、機器の機番
（シリアル番号）、どの年月の稼動情報であるか、その
月時点でのカウンタ値、両面の印刷枚数、多重の印刷枚
数、２ｉｎ１の印刷枚数、４ｉｎ１の印刷枚数、ＦＡＸ
出力枚数、ホストコンピュータからの印刷データのプリ
ント枚数、スキャン送信数、電子メール送信数、あと、
コピーやプリントで使用された用紙の用紙サイズごとの
枚数などが格納されている。そして、カウンタ情報に
は、それぞれの値が含まれている。

【０２０９】つぎに、当月時点でのカウンタ値から先月
時点でのカウンタ値を引き算し、当月だけの使用枚数を
算出し、それを稼動報告書用のテンプレートファイルに
埋め込む。次に、用途別の印刷枚数をそれぞれ埋め込む
（ステップＳ３３０４）。つぎに、用紙別の印刷枚数を
使用枚数で割った％を用紙別の用紙枚数率として、テン
プレートファイルに埋め込む（ステップＳ３３０５）。

【０２１０】つぎに、図２８のトラブルチケットテーブ
ルにおいて、顧客コード、顧客サブコード、発生日時＝
当月をキーにして、それに該当するトラブルチケットＩ
Ｄを引き出し、そのトラブルチケットＩＤに対応する情
報を障害履歴に埋め込む（ステップＳ３３０６）。

【０２１１】そして、そのトラブルチケットＩＤの中
で、機番が同一のトラブルチケットＩＤが２こ以上ある
かを判定する（ステップＳ３３１０）。また、作業依頼
の状態が「未対応」になっているトラブルチケットＩＤ
があるかを判定する（ステップＳ３３０８）。また、障
害があるかないかを判定する（ステップＳ３３０９）。

【０２１２】その結果に従って、ステップＳ３３１０で
は、「故障の頻度が高くなっています。しばらく観察が
必要です」の欄に、障害が２回以上発生している機番、
或いは、「未対応」になっているトラブルチケットＩＤ
の機番を埋め込む。また、ステップＳ３３１１では、
「全く問題ありません。快適にお使いいただいていま
す」の欄に、機番を埋め込む。ステップＳ３３１２で
は、「障害がありましたが、対処済みなので問題ありま
せん」の欄に機番を埋め込む。

【０２１３】そして、現在の日付をテンプレートファイ
ルに埋め込む（ステップＳ３３１３）。最後に、テンプ
レートファイルをＨＴＭＬ形式で保存し、顧客に送付す
る（ステップＳ３３１４）。ステップＳ３３１４では、
ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａ
ｎｇｕａｇｅ）形式の稼動報告書のファイルを電子メー
ルに添付して送ってもよいし、また、このＨＴＭＬ形式
の稼動報告書ファイルのＵＲＬ（ＵｎｉｆｏｒｍＲｅ
ｓｏｕｒｃｅＬｏｃａｔｉｏｎ）を電子メールで知ら
せ、顧客がＷＷＷブラウザで閲覧するときに稼動報告書
ファイルを送ってもよい。

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

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

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

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

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

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

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

【０２２１】

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

【０２２２】特に、管理サイトが、オフィスのＰＣ・サ
ーバ系の機器とデバイス系の機器との障害情報及び予兆
情報を自動的に受信し、顧客になにも意識させることな
く、メンテナンスサービスを提供し、更に、実際にメン
テナンスサービスを行なうサービス会社への依頼書の送
付処理、サービス会社からの作業報告書の受信処理を一
本化することができる。それにより、顧客は、各サービ
ス会社と個別に契約することなく、１つの管理サイトと
契約するだけで様々な機器のメンテナンスサービスを受
けることができる。

【０２２３】また、カウンタ情報と障害履歴を用いて、
オフィス環境での機器の稼動報告書を自動的に顧客に提
供することができる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２０】管理サイト（センタシステム）で使用される
アプリケーションシステムが処理する内容を示すフロー
チャートである。

【図２１】障害イベントのデータ構造を示す図である。

【図２２】障害リストを示す表示画面である。

【図２３】顧客の機器ごとに発生した障害を示す表示画
面である。

【図２４】障害コードマスタテーブルを示す図である。

【図２５】機番（シリアル番号）マスタテーブルを示す
図である。

【図２６】顧客マスタテーブルを示す図である。

【図２７】対応方法表示画面を示す図である。

【図２８】トラブルチケットテーブルを示す図である。

【図２９】作業依頼書を作成・送付する処理を示すフロ
ーチャートである。

【図３０】作業依頼書兼作業報告書のテンプレートファ
イルを示す図である。

【図３１】サービス会社マスターテーブルを示す図であ
る。

【図３２】作業報告書作成・送付の処理を示すフローチ
ャートである。

【図３３】管理サイト（センタシステム）で使用される
アプリケーションシステムが処理する内容を示すフロー
チャートである。

【図３４】カウンタテーブルを示す図である。

【図３５】稼動報告書のテンプレートファイルを示す図
である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者原寛行東京都大田区下丸子３丁目30番２号キヤノン株式会社内 (72)発明者廣瀬淳一東京都大田区下丸子３丁目30番２号キヤノン株式会社内 (72)発明者大森和志東京都大田区下丸子３丁目30番２号キヤノン株式会社内 (72)発明者川島真東京都大田区下丸子３丁目30番２号キヤノン株式会社内Ｆターム(参考） 5H223 AA13 DD03 DD07 DD09 EE06 5K048 BA21 DC07 EB08 EB12 FB04 FC01 GB05 HA01 HA02

Claims

【特許請求の範囲】

【請求項１】ネットワークを介して機器を管理する機
器管理装置であって、前記機器の障害を示すデータを受信する障害検知手段
と、前記障害検知手段により障害が検知されるのに応じて、
作業依頼書を示すデータを作成する作成手段と、複数の会社のうち、前記機器の復旧作業を行なう会社を
選択する選択手段と、前記選択手段により選択された会社宛てに、前記生成手
段により生成された作業依頼書を示すデータを送信する
よう制御する送信制御手段とを有することを特徴とする
機器管理装置。
【請求項２】送信された作業依頼書を示すデータに対
する、作業報告書を示すデータを会社から受信する受信
手段を有することを特徴とする請求項１に記載の機器管
理装置。
【請求項３】前記作成手段により作業依頼書を示すデ
ータが作成される際に、当該作業依頼に対する識別子を
発行する発行手段と、前記発行手段により発行された識別子と共に、当該作業
依頼の状態を管理する管理手段とを有することを特徴と
する請求項２に記載の機器管理装置。
【請求項４】前記送信制御手段は、前記作業依頼書を
示すデータとともに、前記発行手段により発行された識
別子を送信するように制御し、前記受信手段は、前記作業報告書を示すデータととも
に、前記送信制御手段により送信された識別子を受信
し、前記管理手段は、前記受信手段により受信された前記作
業報告書を示すデータに基づいて、前記受信手段により
受信された識別子に対応する作業依頼の状態を変更する
ことを特徴とする請求項３に記載の機器管理装置。
【請求項５】前記送信制御手段は、電子メールにおい
て前記作業依頼書を示すデータを送信することを特徴と
する請求項１乃至４のいずれかに記載の機器管理装置。
【請求項６】前記障害検知手段は、障害が検知された
機器を識別する機器情報を受信し、前記選択手段は、受信された前記機器情報をに基づい
て、会社を選択することを特徴とする請求項１乃至５の
いずれかに記載の機器管理装置。
【請求項７】前記障害検知手段は、検知された障害を
識別する障害情報を受信し、前記作成手段は、受信された障害情報を、前記作業依頼
書を示すデータに埋め込むことを特徴とする請求項１乃
至６のいずれかに記載の機器管理装置。
【請求項８】前記作業手段は、受信された障害情報に
より識別される障害の対応方法を示すデータを、前記作
業依頼書を示すデータに埋め込むことを特徴とする請求
項１乃至７のいずれかに記載の機器管理装置。
【請求項９】前記障害検知手段により検知された障害
の対応者を判断する判断手段と、前記対応者が前記機器を有する顧客であると判断される
のに応じて、前記顧客に関する顧客情報と、検知された
障害の対処方法を示すメッセージを表示部に表示させる
表示制御手段とを有することを特徴とする請求項１乃至
８のいずれかに記載の機器管理装置。
【請求項１０】前記選択手段は、前記対応者が会社で
あると判断されるのに応じて、会社を選択することを特
徴とする請求項９に記載の機器管理装置。
【請求項１１】ネットワークを介して機器を管理する
機器管理プログラムであって、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成する作成ステップ
と、複数の会社のうち、前記機器の復旧作業を行なう会社を
選択する選択ステップと、前記選択ステップにより選択された会社宛てに、前記生
成ステップにより生成された作業依頼書を示すデータを
送信するよう制御する送信制御ステップとをコンピュー
タに実行させることを特徴とする機器管理プログラム。
【請求項１２】送信された作業依頼書を示すデータに
対する、作業報告書を示すデータを会社から受信する受
信ステップをコンピュータに実行させることを特徴とす
る請求項１１に記載の機器管理プログラム。
【請求項１３】前記作成ステップにより作業依頼書を
示すデータが作成される際に、当該作業依頼に対する識
別子を発行する発行ステップと、前記発行ステップにより発行された識別子と共に、当該
作業依頼の状態を管理する管理ステップとをコンピュー
タに実行させることを特徴とする請求項１２に記載の機
器管理プログラム。
【請求項１４】前記送信制御ステップは、前記作業依
頼書を示すデータとともに、前記発行ステップにより発
行された識別子を送信するように制御し、前記受信ステップは、前記作業報告書を示すデータとと
もに、前記送信制御ステップにより送信された識別子を
受信し、前記管理ステップは、前記受信ステップにより受信され
た前記作業報告書を示すデータに基づいて、前記受信ス
テップにより受信された識別子に対応する作業依頼の状
態を変更することを特徴とする請求項１３に記載の機器
管理プログラム。
【請求項１５】前記送信制御ステップは、電子メール
において前記作業依頼書を示すデータを送信することを
特徴とする請求項１１乃至１４のいずれかに記載の機器
管理プログラム。
【請求項１６】前記障害検知ステップは、障害が検知
された機器を識別する機器情報を受信し、前記選択ステップは、受信された前記機器情報をに基づ
いて、会社を選択することを特徴とする請求項１１乃至
１５のいずれかに記載の機器管理プログラム。
【請求項１７】前記障害検知ステップは、検知された
障害を識別する障害情報を受信し、前記作成ステップは、受信された障害情報を、前記作業
依頼書を示すデータに埋め込むことを特徴とする請求項
１１乃至１６のいずれかに記載の機器管理プログラム。
【請求項１８】前記作業ステップは、受信された障害
情報により識別される障害の対応方法を示すデータを、
前記作業依頼書を示すデータに埋め込むことを特徴とす
る請求項１１乃至１７のいずれかに記載の機器管理プロ
グラム。
【請求項１９】前記障害検知ステップにより検知され
た障害の対応者を判断する判断ステップと、前記対応者が前記機器を有する顧客であると判断される
のに応じて、前記顧客に関する顧客情報と、検知された
障害の対処方法を示すメッセージを表示部に表示させる
表示制御ステップとをコンピュータに実行させることを
特徴とする請求項１１乃至１８のいずれかに記載の機器
管理プログラム。
【請求項２０】前記選択ステップは、前記対応者が会
社であると判断されるのに応じて、会社を選択すること
を特徴とする請求項１９に記載の機器管理プログラム。
【請求項２１】ネットワークを介して機器を管理する
機器管理プログラムを格納したコンピュータにより読み
取り可能な記録媒体であって、前記機器管理プログラム
は、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成する作成ステップ
と、複数の会社のうち、前記機器の復旧作業を行なう会社を
選択する選択ステップと、前記選択ステップにより選択された会社宛てに、前記生
成ステップにより生成された作業依頼書を示すデータを
送信するよう制御する送信制御ステップとをコンピュー
タに実行させることを特徴とする記録媒体。
【請求項２２】前記機器管理プログラムは、送信された作業依頼書を示すデータに対する、作業報告
書を示すデータを会社から受信する受信ステップをコン
ピュータに実行させることを特徴とする請求項２１に記
載の記録媒体。
【請求項２３】前記機器管理プログラムは、前記作成ステップにより作業依頼書を示すデータが作成
される際に、当該作業依頼に対する識別子を発行する発
行ステップと、前記発行ステップにより発行された識別子と共に、当該
作業依頼の状態を管理する管理ステップとをコンピュー
タに実行させることを特徴とする請求項２２に記載の記
録媒体。
【請求項２４】前記送信制御ステップは、前記作業依
頼書を示すデータとともに、前記発行ステップにより発
行された識別子を送信するように制御し、前記受信ステップは、前記作業報告書を示すデータとと
もに、前記送信制御ステップにより送信された識別子を
受信し、前記管理ステップは、前記受信ステップにより受信され
た前記作業報告書を示すデータに基づいて、前記受信ス
テップにより受信された識別子に対応する作業依頼の状
態を変更することを特徴とする請求項２３に記載の記録
媒体。
【請求項２５】前記送信制御ステップは、電子メール
において前記作業依頼書を示すデータを送信することを
特徴とする請求項２１乃至２４のいずれかに記載の記録
媒体。
【請求項２６】前記障害検知ステップは、障害が検知
された機器を識別する機器情報を受信し、前記選択ステップは、受信された前記機器情報をに基づ
いて、会社を選択することを特徴とする請求項２１乃至
２５のいずれかに記載の記録媒体。
【請求項２７】前記障害検知ステップは、検知された
障害を識別する障害情報を受信し、前記作成ステップは、受信された障害情報を、前記作業
依頼書を示すデータに埋め込むことを特徴とする請求項
２１乃至２６のいずれかに記載の記録媒体。
【請求項２８】前記作業ステップは、受信された障害
情報により識別される障害の対応方法を示すデータを、
前記作業依頼書を示すデータに埋め込むことを特徴とす
る請求項２１乃至２７のいずれかに記載の記録媒体。
【請求項２９】前記機器管理プログラムは、前記障害検知ステップにより検知された障害の対応者を
判断する判断ステップと、前記対応者が前記機器を有する顧客であると判断される
のに応じて、前記顧客に関する顧客情報と、検知された
障害の対処方法を示すメッセージを表示部に表示させる
表示制御ステップとをコンピュータに実行させることを
特徴とする請求項２１乃至２８のいずれかに記載の記録
媒体。
【請求項３０】前記選択ステップは、前記対応者が会
社であると判断されるのに応じて、会社を選択すること
を特徴とする請求項２９に記載の記録媒体。
【請求項３１】ネットワークを介して機器を管理する
機器管理方法であって、前記機器の障害を検知する障害検知ステップと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成する作成ステップ
と、複数の会社のうち、前記機器の復旧作業を行なう会社を
選択する選択ステップと、前記選択ステップにより選択された会社宛てに、前記生
成ステップにより生成された作業依頼書を示すデータを
送信するよう制御する送信制御ステップとを有すること
を特徴とする機器管理方法。
【請求項３２】送信された作業依頼書を示すデータに
対する、作業報告書を示すデータを会社から受信する受
信ステップを有することを特徴とする請求項３１に記載
の機器管理方法。
【請求項３３】前記作成ステップにより作業依頼書を
示すデータが作成される際に、当該作業依頼に対する識
別子を発行する発行ステップと、前記発行ステップにより発行された識別子と共に、当該
作業依頼の状態を管理する管理ステップとを有すること
を特徴とする請求項３２に記載の機器管理方法。
【請求項３４】前記送信制御ステップは、前記作業依
頼書を示すデータとともに、前記発行ステップにより発
行された識別子を送信するように制御し、前記受信ステップは、前記作業報告書を示すデータとと
もに、前記送信制御ステップにより送信された識別子を
受信し、前記管理ステップは、前記受信ステップにより受信され
た前記作業報告書を示すデータに基づいて、前記受信ス
テップにより受信された識別子に対応する作業依頼の状
態を変更することを特徴とする請求項３３に記載の機器
管理方法。
【請求項３５】前記送信制御ステップは、電子メール
において前記作業依頼書を示すデータを送信することを
特徴とする請求項３１乃至３４のいずれかに記載の機器
管理方法。
【請求項３６】前記障害検知ステップは、障害が検知
された機器を識別する機器情報を取得し、前記選択ステップは、受信された前記機器情報をに基づ
いて、会社を選択することを特徴とする請求項３１乃至
３５のいずれかに記載の機器管理方法。
【請求項３７】前記障害検知ステップは、検知された
障害を識別する障害情報を取得し、前記作成ステップは、受信された障害情報を、前記作業
依頼書を示すデータに埋め込むことを特徴とする請求項
３１乃至３６のいずれかに記載の機器管理方法。
【請求項３８】前記作業ステップは、受信された障害
情報により識別される障害の対応方法を示すデータを、
前記作業依頼書を示すデータに埋め込むことを特徴とす
る請求項３１乃至３７のいずれかに記載の機器管理方
法。
【請求項３９】前記障害検知ステップにより検知され
た障害の対応者を判断する判断ステップと、前記対応者が前記機器を有する顧客であると判断される
のに応じて、前記顧客に関する顧客情報と、検知された
障害の対処方法を示すメッセージを表示部に表示させる
表示制御ステップとを有することを特徴とする請求項３
１乃至３８のいずれかに記載の機器管理方法。
【請求項４０】前記選択ステップは、前記対応者が会
社であると判断されるのに応じて、会社を選択すること
を特徴とする請求項３９に記載の機器管理方法。
【請求項４１】ネットワークを介して機器を管理する
機器管理装置であって、前記機器の障害を示すデータを受信する障害検知手段
と、前記障害検知手段により障害が検知されるのに応じて、
作業依頼書を示すデータを作成し、前記機器の復旧作業
を行なう会社宛てに、前記生成手段により生成された作
業依頼書を示すデータを送信するよう制御する送信制御
手段と、前記機器のカウント情報を取得するカウンタ取得手段
と、前記カウンタ取得手段により取得されたカウンタ情報に
基づいて、前記機器の稼動報告書を示すデータを作成す
る作成手段とを有し、前記作成手段は、障害が複数回発生した機器を示す機器
情報を、前記稼動報告書を示すデータに埋め込むことを
特徴とする機器管理装置。
【請求項４２】ネットワークを介して機器を管理する
機器管理装置であって、前記機器の障害を示すデータを受信する障害検知手段
と、前記障害検知手段により障害が検知されるのに応じて、
作業依頼書を示すデータを作成し、前記機器の復旧作業
を行なう会社宛てに、前記生成手段により生成された作
業依頼書を示すデータを送信するよう制御する送信制御
手段と、作業依頼書を示すデータが作成される際に、当該作業依
頼の状態を管理する管理手段と、前記機器のカウント情報を取得するカウンタ取得手段
と、前記カウンタ取得手段により取得されたカウンタ情報に
基づいて、前記機器の稼動報告書を示すデータを作成す
る作成手段とを有し、前記作成手段は、前記管理手段により管理されている作
業依頼の状態に基づいて、当該作業依頼が処理されてい
ない機器を示す機器情報を、前記稼動報告書を示すデー
タに埋め込むことを特徴とする機器管理装置。
【請求項４３】ネットワークを介して機器を管理する
機器管理装置であって、前記機器の障害を示すデータを受信する障害検知手段
と、前記障害検知手段により障害が検知されるのに応じて、
作業依頼書を示すデータを作成し、前記機器の復旧作業
を行なう会社宛てに、前記生成手段により生成された作
業依頼書を示すデータを送信するよう制御する送信制御
手段と、前記機器のカウント情報を取得するカウンタ取得手段
と、前記カウンタ取得手段により取得されたカウンタ情報に
基づいて、前記機器の稼動報告書を示すデータを作成す
る作成手段とを有し、前記作成手段は、障害が発生していない機器を示す機器
情報を、前記稼動報告書を示すデータに埋め込むことを
特徴とする機器管理装置。
【請求項４４】ネットワークを介して機器を管理する
機器管理プログラムであって、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとをコンピュータに実行させ、前記作成ステップは、障害が複数回発生した機器を示す
機器情報を、前記稼動報告書を示すデータに埋め込むこ
とを特徴とする機器管理プログラム。
【請求項４５】ネットワークを介して機器を管理する
機器管理プログラムであって、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、作業依頼書を示すデータが作成される際に、当該作業依
頼の状態を管理する管理ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとを実行させ、前記作成ステップは、前記管理ステップにより管理され
ている作業依頼の状態に基づいて、当該作業依頼が処理
されていない機器を示す機器情報を、前記稼動報告書を
示すデータに埋め込むことを特徴とする機器管理プログ
ラム。
【請求項４６】ネットワークを介して機器を管理する
機器管理プログラムであって、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとを実行させ、前記作成ステップは、障害が発生していない機器を示す
機器情報を、前記稼動報告書を示すデータに埋め込むこ
とを特徴とする機器管理プログラム。
【請求項４７】ネットワークを介して機器を管理する
機器管理プログラムが格納されたコンピュータにより読
み取り可能な記録媒体であって、前記機器管理プログラ
ムは、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとをコンピュータに実行させ、前記作成ステップは、障害が複数回発生した機器を示す
機器情報を、前記稼動報告書を示すデータに埋め込むこ
とを特徴とする機器管理プログラム。
【請求項４８】ネットワークを介して機器を管理する
機器管理プログラムが格納されたコンピュータにより読
み取り可能な記録媒体であって、前記機器管理プログラ
ムは、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、作業依頼書を示すデータが作成される際に、当該作業依
頼の状態を管理する管理ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとを実行させ、前記作成ステップは、前記管理ステップにより管理され
ている作業依頼の状態に基づいて、当該作業依頼が処理
されていない機器を示す機器情報を、前記稼動報告書を
示すデータに埋め込むことを特徴とする機器管理プログ
ラム。
【請求項４９】ネットワークを介して機器を管理する
機器管理プログラムが格納されたコンピュータにより読
み取り可能な記録媒体であって、前記機器管理プログラ
ムは、前記機器の障害を示すデータを受信する障害検知ステッ
プと、前記障害検知ステップにより障害が検知されるのに応じ
て、作業依頼書を示すデータを作成し、前記機器の復旧
作業を行なう会社宛てに、前記生成ステップにより生成
された作業依頼書を示すデータを送信するよう制御する
送信制御ステップと、前記機器のカウント情報を取得するカウンタ取得ステッ
プと、前記カウンタ取得ステップにより取得されたカウンタ情
報に基づいて、前記機器の稼動報告書を示すデータを作
成する作成ステップとを実行させ、前記作成ステップは、障害が発生していない機器を示す
機器情報を、前記稼動報告書を示すデータに埋め込むこ
とを特徴とする機器管理プログラム。