JP2002106930A - 管理システム、および遠隔保守監視システム - Google Patents

Abstract

(57)【要約】 【課題】 従来の冷熱器等の遠隔保守は、保守会社自身
で実作業から機器監視までをしなければならず、全ての
業務を十分に行うことができないという問題があった。 【解決手段】 機器を利用する顧客と、機器の保守を担
当する保守会社とを対応付けて登録した契約記憶部を有
し、遠隔監視装置から送られた運転情報から機器の異常
または変調を検知した場合には、契約記憶部を参照し、
異常または変調が検知された機器の保守を担当する保守
会社に通知することとした。なお、この契約は、契約記
憶部の登録は、端末から顧客と契約内容が送信された時
点で行われる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ビル等に設置さ
れた空調機等の機器の運転状況を遠隔監視し、問題の発
生の予測や、障害発生時にはサービスマンの手配等を行
う遠隔保守監視システム、および、そのシステムで使用
されている管理システムに関するものである。

【０００２】

【従来の技術】従来、冷熱機器の遠隔監視保守業務にお
いては、保守会社自身で、保守営業から、実作業、遠隔
監視保守のためのインフラ構築とその維持管理に至るま
で全ての業務を行っていた。従って、特に夏や冬の保守
サービス業務の繁忙期には保守業務で手いっぱいとな
り、顧客開拓のための営業活動が十分に行えないという
問題があった。またインフラの整備や維持には莫大な時
間と費用を要するので、それが結局保守料金または初期
コストに影響を与え、顧客の負担が大きくなると共に、
保守会社自体にとっては遠隔監視保守の採算を悪くする
原因にもなっていた。

【０００３】さらに、地域工事会社のような、比較的規
模の小さい保守会社においては、営業活動やインフラ整
備が十分にできないばかりか、保守サービスを実施する
うえでも十分な情報やノウハウの蓄積がないので、保守
作業の効率が悪くなるという問題もあった。

【０００４】また、各ビルに配置され、冷熱機器の情報
を収集する遠隔監視装置に関しても、冷熱機器の変更や
追加をする場合には、設定変更作業が必要となるが、こ
の場合、現地でのクライアント側管理装置自体もしくは
ＲＯＭの交換には顧客が冷熱機器を使用していない時間
帯を利用しなければならなくなり、フレキシブルに契約
内容の更新が実施できないという問題があった。さら
に、Ｗｅｂ方式での集中監視を試みた場合においても、
結局はサーバ側アプリケーションの変更がクライアント
側に影響を与えたり、遠隔監視装置を高性能のものに変
更する必要がある。

【０００５】

【発明が解決しようとする課題】このように、従来の遠
隔保守監視システムでは、各事業者が個別で全ての業務
を実施することで、営業活動に支障をきたしたり、イン
フラ整備にコストがかかったり、保守のための十分なノ
ウハウが得られないという問題点があった。また、シス
テムのバージョンアップ作業に時間を要したり、高性能
なマシンが必要とされるという問題点があった。

【０００６】この発明は上述の問題点を解決するために
なされたものであり、第１の目的は、顧客との窓口を情
報センターのサーバシステムに集約し、サービス会社や
保守販売会社や機器メーカ、地域工事会社はこのサーバ
システムを介して情報のやり取りをすることで、各者が
自らが得意の業務に特化できる遠隔保守監視システムを
提供することである。

【０００７】さらに、第２の目的は、障害発生時に、保
守サービス員が迅速に対応し、保守作業を短時間で行う
ことができる遠隔保守監視システムを提供することであ
る。さらに、第３の目的は、各ビルに配置された遠隔監
視端末の設定を遠隔で設定できる遠隔保守監視システム
を提供することである。

【０００８】

【課題を解決するための手段】この発明にかかる管理シ
ステムにおいては、通信機器から送られた機器を利用す
る顧客との契約情報に基づいて、監視装置を制御する制
御プログラムを生成する生成手段と、制御プログラムを
前記監視装置に送信する送信手段とを有するものとし
た。

【０００９】また、この発明にかかる管理システムにお
いては、通信機器から送られた機器を利用する顧客との
契約情報に基づいて、監視装置で動作する制御プログラ
ムにより参照される制御パラメータを生成する生成手段
と、制御パラメータを監視装置に送信する送信手段とを
有するものとした。

【００１０】また、この発明にかかる管理システムにお
いては、機器を利用する顧客と、機器の保守を担当する
保守会社とを対応付けて登録した契約記憶部を有し、運
転情報から機器の異常または変調を検知した場合には、
契約記憶部を参照し、異常または変調が検知された機器
の保守を担当する保守会社に通知するものとした。

【００１１】さらに、保守会社と、保守会社の保守業務
条件とを対応付けて登録した保守会社記憶部を有し、通
信機器から顧客との契約条件が送信された場合には、保
守会社記憶部を参照して、契約条件に適合する保守業務
条件の保守会社を抽出し、契約記憶部に保守会社と顧客
とを対応付けて登録するものとした。

【００１２】さらに、保守会社と、保守会社の保守業務
条件とを対応付けて登録した保守会社記憶部を有し、通
信機器から顧客とその顧客に対応付ける保守会社が送信
された場合には、顧客に保守会社を対応付けて契約記憶
部に登録し、通信機器から顧客との契約条件が送信され
た場合には、保守会社記憶部を参照して、契約条件に適
合する保守業務条件の複数の保守会社を抽出して前記通
信機器に送信し、複数の保守会社から選択された１社が
通信機器から送信された場合には、契約記憶部に顧客と
を対応付けて登録するものとした。

【００１３】さらに、通信機器に、顧客と顧客の契約条
件の入力を促す画面を送信するものとした。

【００１４】さらに、契約記憶部には、保守会社と保守
会社の権限とが対応付けられて登録されているものとし
た。

【００１５】さらに、通信機器から保守会社と保守会社
の保守業務条件、および権限を受信した場合には、契約
記憶部に保守会社と権限とを対応つけて登録し、保守会
社記憶部に保守会社と保守業務条件とを対応付けて登録
するものとした。

【００１６】さらに、通信機器に、保守会社と保守会社
の保守業務条件、権限の入力を促す画面を送信するもの
とした。

【００１７】さらに、契約記憶部には、保守販売会社と
保守販売会社の権限とが対応付けられて登録されてお
り、さらに、機器を利用する顧客と、機器の保守を担当
する保守会社と、顧客と保守契約を結んだ保守販売会社
とが対応付けられて登録されているものとした。

【００１８】さらに、顧客の口座から予め契約された内
容に基づく料金を引き落とす引き落とし手段と、契約記
憶部を参照し、顧客に対応付けられた保守会社と保守販
売会社とに料金を按分して保守会社料金および保守販売
会社料金を算出する第１の計算手段と、契約記憶部を参
照して、保守会社手数料と保守販売会社手数料を算出す
る第２の計算手段と、保守会社料金から保守会社手数料
を差し引いたものを保守会社の口座に振り込み、保守販
売会社料金から保守販売会社手数料を差し引いたものを
保守販売会社の口座に振り込む振り込み手段とを有する
ものとした。

【００１９】さらに、顧客の地図情報が登録された顧客
情報記憶部を有し、通信機器から送信された要求によ
り、地図情報を通信機器に送信するものとした。

【００２０】さらに、監視装置から送信された機器の運
転情報を顧客と対応付けて登録する運転状態記憶部を有
し、運転状態記憶部を参照して顧客毎の運転状況報告書
を作成するものとした。

【００２１】さらに、機器の異常または変調の現象と故
障原因、対処方法が対応付けて登録された故障統計記憶
部を有し、通信機器から受信した現象から、故障統計記
憶部を参照し、現象に対応した故障原因および故障方法
を通信機器に送信するものとした。

【００２２】さらに、通信機器に現象の入力を促す画面
を送信するものとした。

【００２３】さらに、通信機器から機器の異常または変
調の現象と故障原因、対処方法が送信された場合には、
送信された情報を故障統計記憶部に登録するとともに、
送信された情報に基づいて報告書を作成するものとし
た。

【００２４】さらに、通信機器に機器の異常または変調
の現象と故障原因、対処方法の入力を促す画面を送信す
るものとした。

【００２５】さらに、契約記憶部には、機器を利用する
顧客と、機器の保守を担当する複数の保守会社とが対応
付けて登録されており、運転情報から機器の異常または
変調を検知した場合には、契約記憶部を参照し、異常ま
たは変調が検知された機器の修理を担当する複数の保守
会社に通知するものとした。

【００２６】さらに、 契約記憶部に登録された保守販
売会社の権限に基づき、運転状態記憶部へのアクセスが
制限されるものとした。

【００２７】また、この発明における管理システムは、
部品名と、その部品を取り扱う管理場所、および部品の
有無が対応付けられて登録されたサービス情報記憶部を
有し、通信機器から受信した部品名から、サービス情報
記憶部を参照し、部品名に対応する管理場所を通信機器
に送信するものとした。

【００２８】さらに、通信機器から住所情報が送信され
た場合には、通信機器に送信した管理場所から住所に部
品を配送する配送時間を通信機器に送信するものとし
た。

【００２９】さらに、通信機器から指定時間が送信され
た場合には、指定時間に通信機器から受信した部品を発
送する発送伝票を発行するものとした。

【００３０】また、この発明における管理システムは、
機器を利用する顧客と、機器の修理を担当する保守会社
のグループとを対応付けて登録した契約記憶部と、各保
守会社と、保守会社の対応可能人数とを対応付けて登録
したユニオン記憶部とを有し、運転情報から機器の異常
または変調を検知した場合には、契約記憶部を参照して
異常または変調が検知された機器の修理を担当するグル
ープを抽出し、ユニオン記憶部を参照して、対応可能人
数に基づきグループ内の保守会社から少なくとも１つの
保守会社を選択し、保守会社に通知するものとした。

【００３１】さらに、対応可能人数は、通信機器により
常時修正可能であるとした。

【００３２】また、この発明にかかる遠隔保守監視シス
テムでは、機器を監視する監視装置と、監視装置に接続
された上述の管理システムと、この管理システムと通信
媒体を介して接続された通信装置とを有するものとし
た。

【００３３】

【発明の実施の形態】実施の形態１．図１はこの発明の
実施の形態１における、冷熱機器での遠隔保守監視シス
テムに関するシステム構成図である。図１において、１
ａ、１ｂは情報伝送手段、２は情報センター内に位置
し、保守監視情報等を管理・制御する管理システムであ
るサーバーシステム、３は顧客監視物件であるビル内に
設置された冷熱機器等からなる冷熱機器システム、４は
顧客監視物件の通信機器であるクライアント端末、５は
サービス会社や地域工事会社などの保守会社のクライア
ント端末、６は保守販売会社（保守営業会社）のクライ
アント端末、７は機器メーカー（冷凍機メーカー、空調
機メーカー等）のクライアント端末である。また、これ
らクライアント端末は、情報伝達手段１ｂを介してサー
バシステム２と接続可能である。なお、サービス会社と
地域工事会社とは、その規模で区別しており、サービス
会社は拠点を全国展開して大規模な保守体制を完備した
会社、地域工事会社とは、拠点が一カ所または数カ所
で、一定地域内での保守業務のみが行える会社を指して
いる。

【００３４】また、情報伝送手段１ａは、サーバシステ
ム２と冷熱機器システム３の間で各種情報を伝達する為
の、一般的な伝送媒体である携帯電話・ＰＨＳ・アナロ
グ回線等の公衆回線である。情報伝送手段１ｂはサーバ
システム２と顧客監視物件のクライアント端末４、保守
会社のクライアント端末５、保守販売会社のクライアン
ト端末６、機器メーカーのクライアント端末７との間で
各種情報を伝達する為の伝送媒体であり、インターネッ
ト、イントラネット等である。

【００３５】次に、情報センターに設置されたサーバシ
ステムの詳細構成について説明する。図２は、サーバシ
ステム２のシステム構成図である。図２中、サーバシス
テム２は、プログラム配信手段１００と、ＷＷＷサーバ
ー・情報発信手段１１０と、アプリケーションサーバー
１２０と、現地情報記憶部に相当する現地情報データベ
ース（以下、「現地情報ＤＢ」とする）１３０と、顧客情
報記憶部に相当する顧客情報データベース（以下、「顧
客情報ＤＢ」とする）１４０と、契約情報記憶部に相当
する契約情報データベース（以下、「契約情報ＤＢ」とす
る）１５０と、故障統計記憶部に相当する故障統計デー
タベース（以下、「故障統計ＤＢ」とする）１６０と、運
転状態記憶部に相当する運転状態データベース（以下、
「運転状態ＤＢ」とする）１７０と、サービス情報記憶部
に相当するサービス情報データベース（以下、「サービ
ス情報ＤＢ」とする）１８０と、保守会社記憶部に相当
する保守会社登録データベース（以下、「保守会社登録
ＤＢ」とする）１９０とを有している。

【００３６】プログラム配信手段１００は、ビルオーナ
ー等の顧客との契約内容に基づき必要なアプリケーショ
ン及びデータを、冷熱機器システムに設置された遠隔監
視端末に配信するものであり、遠隔監視端末は配信され
たプログラム及びデータに基づき動作し、必要データの
収集などを実施することになる。ＷＷＷサーバー・情報
発信手段１１０は、顧客監視物件、保守会社、保守販売
会社、機器メーカーに設置されたクライアント端末との
通信インタフェースを制御するものである。アプリケー
ションサーバー１２０は、各ＤＢからのデータの抽出・
書込みや、データの処理を行うものである。

【００３７】なお、クライアント端末とのやり取りは、
クライアント端末から送られた要求やデータがアプリケ
ーションサーバー１２０に送られ、アプリケーションサ
ーバー１２０が実際に各ＤＢからのデータの抽出・書込
み処理を行い、画面イメージに変換してクライアント端
末に送信するようなメカニズムで実現されている。

【００３８】次に、各ＤＢに記憶されている情報につい
て、図３〜図９のデータフォーマットに基づいて説明す
る。 図３は現地情報ＤＢ１３０のレコードのフォーマット
であり、顧客ＩＤ１３１と、顧客の所在地情報１３２
と、場所情報１３３とを有している。なお、サービス会
社や地域工事会社の保守実務担当者（以下、「サービス
マン」）は、出動時、クライアント端末から現地情報Ｄ
Ｂ１３０にアクセスすることで、顧客の場所の確認を行
うことができる。

【００３９】図４（ａ）は顧客情報ＤＢ１４０の顧客
情報レコードのフォーマットであり、顧客ＩＤ１４１
と、顧客名称１４２と、連絡先１４３と、顧客の所在地
のある県等の顧客集所１４４と、遠隔監視装置ＩＤ（号
機Ｎｏ）１４５とを有している。図４（ｂ）は顧客情報
ＤＢ１４０の機器情報レコードのフォーマットであり、
顧客ＩＤ１４１と、遠隔監視装置ＩＤ１４６と、システ
ム情報１４７と、故障実績１４８とを有している。ま
た、システム情報１４７は、その顧客に設置された冷熱
機器システムの機器を識別するための号機Ｎｏ１４７
ａ、型名１４７ｂ、据付日１４７ｃからなり、故障実績
１４８は、故障内容１４８ａ、修理時間１４８ｂ、交換
部品１４８ｃ、作業者１４８ｄからなっている。

【００４０】図５（ａ）は、契約情報ＤＢ１５０の顧
客契約レコードのフォーマットであり、顧客ＩＤ１５１
と、契約内容１５２と、保守費用（定額のもの）１５３
とを有している。また、契約内容１５２は、契約開始日
１５２ａ、契約内容１５２ｂ、報告書提出日１５２ｃ、
保守会社の保守会社ＩＤ１５２ｄ、保守販売会社ＩＤ１
５２ｅからなっている。図５（ｂ）は、契約情報ＤＢ１
５０の保守会社レコードのフォーマットであり、保守会
社ＩＤ１５４と、登録日１５５と、サービス内容１５６
とを有している。また、サービス内容１５６は、保守会
社のクライアント端末がシステムの各機能にアクセスで
きる権限を示すものであり、故障統計閲覧の可否１５６
ａ、サービス情報閲覧の可否１５６ｂからなっている。
図５（ｃ）は、契約情報ＤＢ１５０の保守販売会社契約
レコードのフォーマットであり、保守販売会社ＩＤ１５
７と、登録日１５８と、サービス内容１５９とを有して
いる。また、サービス内容１５９は、保守販売会社のク
ライアント端末がシステムの各機能にアクセスできる権
限を示すものであり、契約内容閲覧の可否１５９ａ、全
情報閲覧の可否１５９ｂからなっている。

【００４１】図６は、故障統計ＤＢ１６０のレコード
のフォーマットであり、機種１６１と、故障情報１６２
と、機器状況１６３と、故障発生時環境１６４と、対処
方法１６５と、作業時間１６６とを有している。また、
故障情報１６２は、故障内容１６２ａ、現象１６２ｂ、
原因１６２ｃからなっている。機器状況１６３は、設置
場所１６３ａ、使用年数１６３ｂからなっている。な
お、サーバーシステム２では、故障統計ＤＢ１６０から
情報を読み込み、故障部位を推測したり、ランク付けし
てクライアント端末に表示することできる。

【００４２】図７は、運転状態ＤＢ１７０のレコード
のフォーマットであり、顧客ＩＤ１７１と、号機Ｎｏ１
７２と、室外機状態１７３と、室内機状態１７４と、故
障発生時環境１７５と、対処方法１７６と、作業時間１
７７とを有している。また、室外機状態１７３は、室外
機運転時間１７３ａ、蓄冷熱運転時間１７３ｂからなっ
ている。室内機状態１７４は、運転時間１７４ａ、サー
モＯＮ時間１７４ｂからなっている。なお、この運転状
態ＤＢ１７０の情報を利用することで、契約内容に従っ
た運転状況の報告書の作成や、メンテナンス提案、機器
リニューアル提案等を実施することが可能になる。

【００４３】図８（ａ）は、サービス情報ＤＢ１８０
の機種情報レコードのフォーマットであり、機種名１８
１と、価格１８２と、機能１８３と、メーカー情報１８
４とを有している。図８（ｂ）は、サービス情報ＤＢ１
８０のサービス部品情報レコードのフォーマットであ
り、機種名１８５と、部品１８６と、価格１８７と、メ
ーカ在庫１８８と、物流管理センター１８９とを有して
いる。なお、サービス情報ＤＢ１８０の情報は、基本的
に機器メーカーによってアップロードされるものであ
る。

【００４４】図９は、保守会社登録ＤＢ１９０のレコ
ードのフォーマットであり、保守会社名１９１と、保守
会社ＩＤ１９２と、業務内容１９３と、対応状況１９４
と、地域１９５と、請負費用１９６と、住所１９７と、
連絡先１９８とを有している。

【００４５】次に、各顧客監視物件のビル内に設置され
る冷熱機器システムのシステム構成につき、図１０の構
成図に基づいて説明する。図１０中、冷熱機器システム
３は、保守監視対象である複数の冷熱機器３１と、遠隔
監視装置３２と、冷熱機器３１と遠隔監視装置３２とを
結ぶ制御線３３とから主に構成されている。また、遠隔
監視装置３２は遠隔保守に必要なデータ等の収集や異常
監視、故障予知を実施するアプリケーションプログラム
が記憶され、動作するアプリケーションプログラム部３
２ａと、各冷熱機種毎にどのようなデータを収集すれば
いいかのデータを有するデータ部３２ｂと、サーバシス
テム２から送られたアプリケーションプログラムやデー
タを受信する、遠隔ローディング手段３２ｃとを有して
いる。

【００４６】次に、遠隔監視装置３２の動作について説
明する。遠隔監視装置３２は、アプリケーションプログ
ラム部３２ａに記憶されたプログラム内容とデータ部３
２ｂに記憶されたデータ内容から、冷熱機器３１の運転
状態監視を実施する。なお、アプリケーションプログラ
ムとしては、 機器の運転状態監視プログラム・・冷熱機器の運転状
態、すなわち、空調機であれば、室内機のサーモ状態、
吸込温度、設定温度、室外機の圧縮機吐出温度、圧縮機
周波数、凝縮温度等機種固有のデータを定期的に収集
し、必要に応じて、つまり契約内容に従って、サーバー
システム２へ送信する 機器の異常監視プログラム・・冷熱機器の異常を検出
し、サーバーシステム２に対して情報伝達手段１ａを用
いて通知する。 機器の故障予知プログラム・・の運転状態のデータ
から、冷熱機器の部品の摩耗状態等を予測し、いずれは
故障停止するであろうことが予測される場合、故障停止
する前に、その旨をサーバーシステム２に通知する。 機器の運転制御プログラム・・サーバーシステム２か
らの指令送信に従い、空調機や、冷凍機の運転を制御す
る。 といったものがある。

【００４７】また、データ部３２ｂに記憶されたデータ
は、アプリケーションプログラムが動作するためのもの
であり、アプリケーションプログラムは、このデータ部
３２に記憶されたデータを参照して動作することにな
る。例えば、アプリケーションプログラムは、機種固
有の部位データを有しておらず、動作時にデータ部３２
ｂに記憶された部位データを読み込み、動作する。

【００４８】また、このアプリケーションプログラム及
びデータは遠隔ローディング手段３２ｃを経由して、サ
ーバーシステム２から受信されるものである。

【００４９】次に、情報センターのサーバシステム２
と、顧客監視物件、保守会社、保守販売会社、機器メー
カーに設置されたクライアント端末との情報伝達のしく
みを、図１１の構成図に基づいて説明する。サーバーシ
ステム２のアプリケーションサーバー１２０は、クライ
アント端末から送られた要求に基づいて各ＤＢにアクセ
スしてデータを抽出・整理し、その結果をクライアント
端末に画面イメージで送信する。クライアント端末で
は、アプリケーション実行用のインターフェース部分の
みを有している。すなわち、クライアント端末ではサー
バーシステム２が送ってきた画面イメージを画面に表示
し、マウスやキーボードでの操作インターフェースを通
じて入力されたデータのみが情報伝達手段１ｂを介して
サーバーシステム２に送られ、サーバーシステム２のア
プリケーションサーバー１２０が送られたデータを処理
することになる。つまり、サーバシステム２と各クライ
アント端末の関係は、一般にＴｈｉｎＣｌｉｅｎｔとい
われる構成である。

【００５０】なお、この様な構成にするのは、アプリケ
ーション実行時には、インターフェース部分のみが各社
に開示することになり、データの機密保持に多大な威力
を発揮するだけでなく、各社においては、クライアント
端末として高性能なものは不要となり、初期投資を低く
設定することが可能になるからである。また、アプリケ
ーションの変更もサーバーシステム２側で実施すれば良
く、各社のクライアント端末へのアプリケーションのダ
ウンロード等も不要となり、運用費用を大幅に低減する
ことができることになる。また、情報センターとして
も、自社内の設備のみメンテナンスすればよく、システ
ム維持・運営費用を大幅に低減できる。

【００５１】次に、上述で説明した構成で、実際に業務
を行う場合の動作について説明する。図１２は、保守販
売会社と顧客監視物件であるビルのビルオーナー間で、
冷熱機器の保守契約が成立した場合の、サーバーシステ
ム２と各社のクライアント端末、および冷熱機器システ
ムとでの情報の流れを示すブロック図である。以下に、
保守販売会社の営業マンがビルオーナーと運転状況監視
の契約を交わした後、実際に保守監視がなされるまでの
流れを、各段階毎に説明する。 （１）顧客契約ＤＢ・顧客情報ＤＢの登録 まず、ビルオーナーと運転状態監視の契約を交わした保
守販売会社の営業マンは、クライアント端末６にてサー
バーシステム２にアクセスする。サーバーシステム２
は、メニュー操作のためのインターフェースを情報伝達
手段１ｂを介して、保守販売会社のクライアント端末６
に送る。クライアント端末６では、営業マンが送られて
きたメニュー画面を見ながら、キーボード及びマウスを
操作して、顧客情報登録及び、契約情報更新のメニュー
を選択し、さらにサーバシステム２から送られてくる、
顧客情報登録及び、契約情報の更新のインターフェース
に従って、必要な操作を行い、その結果、サーバーシス
テム２内の顧客情報ＤＢ１４０及び契約情報ＤＢ１５０
が更新されることになる。なお、契約内容の登録につい
ては、登録が完成した時点で、契約の内容が保守サービ
ス（定期点検等）を実施する保守会社のクライアント端
末５に、メール等を用いて通知されることになる。保守
会社では、クライアント端末５に表示された内容から、
それが新規のものである場合には、サービスマンをその
監視対象システムの元に派遣し、遠隔監視装置３２の設
置・据え付け等の作業を行うことになる。

【００５２】次に、特に顧客の登録時に、保守代行を実
施する保守会社の選定・確認方法について、図１３のフ
ロー図に基づいて説明する。なお、代行を依頼する保守
会社は、基本的に図９の保守会社登録ＤＢに保守業務条
件である業務内容（対象機種）、対応状況（３６５日、
２４時間対応可能かどうか？）、対象地域、各業務毎の
請負費用が登録されている。

【００５３】保守販売会社の営業マンは、ビルオーナー
から保守会社（予め、保守会社登録ＤＢに登録されてい
る必要がある）の指定があった場合には、保守販売会社
のクライアント端末６を使用して顧客契約ＤＢ１５０の
登録・更新時に会社指定画面を選択して指定した保守会
社を設定し、指定がない場合には指定ナシを設定する。
サーバーシステム２は、会社指定がなされたか否かを判
定し（Ｓ１０）、指定がなされた場合には、その会社を
保守会社として契約情報ＤＢ１５０の保守会社ＩＤ１５
２ｄに登録する(Ｓ１１)。また、指定がなされてなかっ
た場合には、自動選択画面をクライアント端末６に送信
する（Ｓ１２）。なお、この自動選択画面には、契約内
容入力フィールド、機種情報入力フィールド、費用入力
フィールド、地域入力フールドが存在している。営業マ
ンは、この画面に従い各入力フィールドに契約条件に従
った事項を入力する（Ｓ１３）。サーバーシステム２で
は、保守会社登録ＤＢ１９０に設定された情報を読み込
み、入力された条件と合う会社を抽出する（Ｓ１４）。

【００５４】次に、抽出された保守会社が１社であるか
否かを判定し（Ｓ１５）、１社である場合には、その保
守会社を顧客契約ＤＢ１５０の会社ＩＤ１５２ｄに登録
する（Ｓ１６）。また、複数の保守会社が抽出された場
合には、その一覧をクライアント端末６に表示し、営業
マンが指定した保守会社を顧客契約ＤＢ１５０の保守会
社ＩＤ１５２ｄに登録する（Ｓ１７）。なお、Ｓ１７の
段階では仮登録とし、仮登録された保守会社のクライア
ント端末５にメール等で保守代行依頼を通知する（Ｓ１
８）。そのメールを受領した保守会社では、契約内容を
確認し、保守請負を受諾する際には、受諾した旨を受託
メールにて送信する（Ｓ１９）。サーバーシステム２で
は、受託メールが一定期間内に送信されたか否かを判定
し（Ｓ２０）、送信された場合には顧客契約ＤＢ１５０
の内容を仮登録から本登録に変更し、その旨、保守販売
会社のクライアント端末６へも通知する（Ｓ２１）。ま
た、受託メールを受信していないと判定した場合には、
再度Ｓ１７以降を実行する。このようにして、保守契約
顧客との契約内容により、自動的に保守会社が割り当て
られることになる。

【００５５】（２）遠隔監視の開始 サーバーシステム２では、契約情報ＤＢ１５０の内容を
常時把握し、顧客契約レコードの契約開始日１５２ａに
設定された日付けとなった時点から、契約内容１５２ｂ
の契約内容での監視が実施できるように、例えば１５２
ａに設定された日付け、もしくはその前日までに、顧客
ＩＤ１５１をキーとして、顧客情報ＤＢ１４０を検索
し、機器情報レコードの顧客ＩＤ１４１が顧客ＩＤ１５
１と一致する機器情報を抽出する。この機器情報と契約
内容から遠隔監視装置３２に送信するべきプログラム
（データ及び、アプリケーションプログラム）を作成
し、情報伝達手段１ａおよび、遠隔ローディング手段３
２ｃを介して、遠隔監視装置３２のアプリケーションプ
ログラム部３２のアプリケーションプログラム部３２ａ
およびデータ部３２ｂにローディングする。

【００５６】（３）遠隔監視装置の作動 冷熱機器システム３では、遠隔監視装置３２がデータ部
３２ｂに記憶された内容に従って、冷熱機器３１の運転
状態監視を実施し、収集した運転状態データをサーバー
システム２へ送信する。サーバーシステム２では、送信
された運転状態データを運転状態ＤＢ１７０に格納す
る。また、遠隔監視装置３２からサーバーシステム２へ
送信された運転状態データは運転状態ＤＢ１７０に登録
され、報告書等の作成に用いられる。なお、運転状態デ
ータについては、サーバーシステム２が定期的に遠隔監
視装置３２から収集するようにしてもよいし、遠隔監視
装置３２が定期的に、自発的にサーバーシステム２に送
信するようにしても良い。なお、そのデータ送信のため
の回線使用料金は情報センターに課金されるものであ
る。

【００５７】（４）障害発生時の対応 保守会社においては、保守代行依頼された契約の内容に
よって、実際に物件に赴き、定期点検等のサービスを実
施し、必要に応じて監視運転状況報告書などの作成を行
う。その作業は、やはり、サーバシステム２と通信しな
がら実施する。その報告書のベース（テンプレート）は
当然のことながら、契約の内容や、監視機器によってそ
れぞれに適したフォームでサーバーシステム２に準備さ
れており、インタフェース入力にて簡単に作成可能であ
る。実際に保守契約を結んでいる保守販売会社は、代行
先の保守会社の作成した報告書もしくは、上記テンプレ
ートから自社で作成したものを、最終的なフォームとし
て、ビルオーナー等の顧客に報告書として提示する。ま
た、顧客監視物件にクライアント端末４が設置されてい
る場合には、情報伝達手段１ｂを用いて、運転状況報告
書を送付するようにしてもよい。

【００５８】（５）契約情報ＤＢ、保守会社登録ＤＢへ
の登録 この遠隔保守監視システムでは、サービス会社や地域工
事会社等の保守会社も一種の顧客としてみなしており、
これらの保守会社は情報センターに登録し、一定の料金
を支払えば情報センターから保守代行の斡旋を受けるこ
とができる。この保守代行業務の仕事の斡旋を受けるた
め必要となる、サーバーシステム２の契約情報ＤＢ１５
０への登録方法について図１４のフロー図に基づいて説
明する。

【００５９】保守会社の従業員は、自らの端末からサー
バーシステム２のＷＷＷサーバ・情報発信手段１１０に
アクセスし、保守会社登録ページを端末に表示させる
（Ｓ２１）。なお、この保守会社登録ページには登録に
必要となる会社名入力フィールド、住所入力フィール
ド、連絡先入力フィールド、業務内容入力フィールド、
対応状況入力フィールド、および故障統計閲覧の可否、
サービス情報閲覧の可否指定フィールドが存在してい
る。サービス会社や地域工事会社は、表示されたフィー
ルドに必要事項を入力する（Ｓ２２）。この内容は、Ｗ
ＷＷサーバ・情報発信手段１１０が受信する（Ｓ２
３）。その後、アプリケーションサーバー１２０では、
受信した内容に不備がないかを確認し、問題がなけれ
ば、保守会社ＩＤを割り付けて契約情報ＤＢ１５０と保
守会社登録ＤＢ１９０にこの保守会社を登録し、保守会
社の端末に保守会社ＩＤを通知する（Ｓ２４）。なお、
Ｓ２２にて登録する内容には、契約情報ＤＢ１５０の会
社契約レコードのフォーマット、保守会社登録ＤＢ１９
０のフォーマットに添った形のものの他に、クライアン
ト端末環境のレンタル情報、保守義務に関わる契約情報
が含まれていてもよい。保守会社は、クライアント端末
をレンタルし、設置することで情報センターからのサー
ビスを受けることができる。

【００６０】（６）保守実施時の報告書の作成 次に、保守実施時の報告書の作成方法について図１５の
フロー図に基づて説明する。サーバーシステム２では、
契約情報ＤＢ１５０の内容が常時把握され、報告書提出
日１５２ｃに登録された日の例えば１週間前に、報告書
作成通知を保守会社ＩＤ１５２ｄに指定された保守会社
のクライアント端末５に通知する（Ｓ３１）。ここで報
告書提出の１週間前としているのは、顧客への提出納期
に対して余裕を持たせるためであり、５日前でも、３日
前でも構わない。報告書作成通知を受信した保守会社で
は、従業員がクライアント端末５でサーバーシステム２
にアクセスする（Ｓ３２）。サーバーシステム２では、
アクセスした会社の保守会社ＩＤから、顧客契約ＤＢ１
５０を検索し、保守会社ＩＤ１５２ｄが一致する顧客Ｉ
Ｄ１５１を抽出、この顧客ＩＤ１５１をキーに顧客情報
ＤＢを検索することで、その保守会社が保守をしている
顧客名をクライアント端末５に表示する（Ｓ３３）。こ
こで、従業員がクライアント端末５で画面に表示された
一覧から対象の顧客を選択すると、その情報がサーバー
システム２に送られ、サーバーシステム２では運転状態
ＤＢ１５０を検索してその顧客の冷熱機器の運転情報を
抽出し、契約内容に添ったテンプレートに必要事項を全
て記載した状態で報告書フォームをクライアント端末５
に表示する（Ｓ３４）。保守会社の従業員は、その内容
を確認し、問題なければ報告書として保存する（Ｓ３
５）。なお、報告書のテンプレートとしては、例えば、
室外機毎の運転時間とその室外機に接続された室内機の
運転時間、サーモＯＮ時間等である。また、必要に応じ
て、その室内機の設定温度と吸込温度を確認し、運転状
態についてのコメントを入力することも可能である。こ
のように、自動的に報告書のテンプレートが作成され、
また報告書提出期限間近になると、その旨通知されるの
で、報告書の作成にかかる時間を短縮できるだけでな
く、作成ミスや作成忘れの防止も可能である。

【００６１】次に、このような業務形態での情報・サー
ビス・対価（金銭）の流れを図１６に示す。基本的に
は、保守販売会社が、顧客と保守契約を結び、その保守
料金を受領することになる。保守販売会社は営業活動に
特化し、その実際の保守サービス業務は保守専門の保守
会社へ依頼する。依頼を受けた保守会社は実際に顧客機
器の保守サービスを代行する代りに、その代行対価を保
守販売会社から受領する。保守に必要な各種データは情
報センターから提供され、各事業者はその料金を情報セ
ンターに支払うことになる。

【００６２】以下、詳細について説明する。顧客監視物
件、保守販売会社、保守会社などの各者は、情報センタ
ーが構築したサーバーシステムのインフラを使用するこ
とで、様々な情報を得ることが可能になる。また、この
インフラを使用することが、この遠隔保守監視システム
に加わるための必要要件であるため、契約情報ＤＢ１５
０に登録された全ての顧客や販売会社、サービス会社・
地域工事会社は、このインフラ使用料を情報センターに
支払うことになる。このインフラ使用料の中には、運転
状況報告書などの文書作成を支援する各種テンプレート
の使用料金や、運転状態の生データなどの情報料金、ク
ライアント端末のレンタル料金を含んでいる。

【００６３】インフラ使用料金は、各事業者が享受でき
るサービス内容によって、設定されてもいいし、サービ
ス内容によらず、定額としても良い。但し、サービス内
容毎に別料金にする場合は、単純な基本料金としてのイ
ンフラ使用料金（維持管理に必要な基本料金）を設定
し、それにサービス内容毎の異なる料金体系、すなわ
ち、顧客との契約内容により異なる料金を請求すること
が可能である。契約情報ＤＢ１５０の内容から自動的に
課金することも当然可能である。

【００６４】保守販売会社と保守会社間のフローとして
は、販売会社から保守代行を依頼された保守会社は、顧
客監視物件の機器を、契約内容に従い保守実施する。保
守販売会社はその保守代行料金を保守会社に支払うこと
になる。なお、金銭そのものの流れの概念は、図１６の
様になるが、実際は情報センターのサーバーシステム２
にて自動決済する方法がとられており、その自動決済の
方法のフローを図１７に示す。

【００６５】情報センターのサーバーシステム２は、月
末になると契約情報ＤＢ１５０の顧客契約レコードにあ
る保守費用１５３に従い、登録された全ての顧客の顧客
口座から保守料金を引き落とす（Ｓ４１）。次に、その
保守料金を、顧客契約レコードに登録された保守会社お
よび保守販売会社へ按分し保守会社料金と保守販売会社
料金に分配する（Ｓ４２）。次に、保守販売会社及び、
保守会社のインフラ使用料金を計算する（Ｓ４３）。そ
して最後に、Ｓ４２で按分した保守会社料金と保守販売
会社料金からインフラ使用料金を差し引き、残りを保守
販売会社及び保守会社の口座へ振り込み、インフラ使用
料は情報センターの口座に振り込む（Ｓ４４）。なお、
自動決済の時期は、ここでは月末としたが、半年毎でも
良いし、３カ月毎でも構わない。

【００６６】この遠隔保守監視システムでは、サーバー
システム一極で遠隔保守監視の処理を行い、保守会社や
保守販売会社は、サーバーシステムから情報を得るよう
な構成にしたので、各事業者は自前の設備を構築する必
要はなく、自前で遠隔保守監視のための機器を管理・維
持にかかるであろう、多大な労務費を削減できる。

【００６７】さらに、保守会社や、保守販売会社におい
ては、保守業務に関して、自己が得意とする分野に注力
して業務を遂行し、あとは情報センターを経由して、別
の業務形態の会社に任せることが可能になり、業務の選
択と集中を加速することが可能である。

【００６８】さらに、保守会社においては、業務内容、
費用等を登録して、その内容に見合った保守依頼のみ受
けることができるので、さらに業務を効率化することが
可能になるだけでなく、電子化された情報を用いること
で、業務効率を大幅に改善可能であり、保守販売会社に
おいても、顧客の要求に見合った保守サービス代行請負
先を簡単に選定することができ、業務を効率化できる。

【００６９】また、顧客との契約内容が変更されても、
遠隔ローディング技術を用いて、任意に遠隔監視装置の
設定変更を手間をかけずに、自動で実施することが可能
となり、現場での機器、Ｓ／Ｗ交換等の業務費用を削減
することができる。

【００７０】また、顧客もシステムコストが低下するこ
とで、保守費用の低減が期待でき、契約を更新した場合
にも、すぐに新しい契約内容での保守を享受できること
になる。さらに、契約内容により、対応可能な保守会社
が自動的に選定されるので、場合によっては保守費用を
低く押さえることも可能である。

【００７１】実施の形態２．図１８は、この遠隔保守監
視システムで異常監視や故障予知を実施し、異常・変調
発生時には、即時出動対応するといったサービスを顧客
に提供する場合での、サーバーシステム２と各社のクラ
イアント端末、および冷熱機器システムとでの情報の流
れを示すブロック図である。

【００７２】以下に、異常が検知された後、保守会社の
サービスマンに異常を通知し、サービスマンが冷熱機器
システムに赴き、機器を修復させるまでの流れを、各段
階毎に説明する。 （１）異常の通知 遠隔監視装置３２は、冷熱機器３１からの情報に基づい
て異常の監視を行なっており、機器に異常や、その予兆
（変調）が発生したことを検出した場合には、情報伝達
手段１ａを介して、その旨がサーバーシステム２に異常
検出通知がなされる。なお、異常検出通知には、異常発
生顧客を示す顧客ＩＤと、故障機器を示す号機番号、故
障内容を示す異常コードが付加されている。サーバーシ
ステム２では、契約情報ＤＢ１５０を顧客ＩＤに基づき
検索することで、担当の保守会社ＩＤ１５２ｄを抽出す
る。次に、この保守会社ＩＤ１５２ｄに基づき、保守会
社登録ＤＢ１９０を検索して、この保守会社のレコード
を抽出し、この保守会社の連絡先１９８に異常もしく
は、変調が発生した旨を情報伝達手段１ｂを介して通知
する。なおこの際、連絡先としてサービスマンのメール
アドレスや、ポケベルの電話番号が設定されていれば、
メールやポケベルでの連絡も当然に可能である。

【００７３】（２）現場での作業 通知を受けた、保守会社もしくは、サービスマンは即座
に現場に向かうことになるが、現場地理に詳しくない場
合などは、クライアント端末５により、サーバーシステ
ム２にアクセスし、顧客ＩＤに基づいて現地情報ＤＢ１
３０に登録された現場付近の地図を参照することが可能
である。また、現場作業時には、サーバーシステム２の
故障統計ＤＢ１６０へアクセスし、異常・変調内容から
得られる故障部位情報を取得し、機器の早期復旧を実施
することになる。また、機器販売会社によりアップロー
ドされるサービス情報ＤＢ１８０へアクセスし、サービ
ス部品情報や、サービス部品の発注作業も実施可能であ
る。また、作業結果報告書の作成などにおいても、サー
バーシステム２で簡単に実施できる。

【００７４】なお、サービスマンによる、サーバーシス
テム２へのアクセスに関しては、携帯電話等の携帯端末
からクライアント端末と同様の操作を行うことができ
る。既に実施の形態１で述べたように、アプリケーショ
ンを端末で実行する必要がないので、例えば、Ｉ-モー
ドや、ＥＺ-ＷＥＢといった、携帯電話のコンテンツサ
ービスにて、携帯電話のみで、簡単にサーバーシステム
２にアクセス可能で、パソコンを用いて、ブラウジング
するといった作業は不要になる。

【００７５】以下に故障発生時のサービスマンの作業
と、故障統計ＤＢへの故障状況の登録、報告書の保存、
及びサービス部品の発注方法の詳細について説明する。
図１９は異常発生時の故障対応時にサービスマンがサー
バーシステム２から必要情報を得る際の方法を示すフロ
ー図である。まず、機器故障現場に到着したサービスマ
ンは、対象機器とその故障内容から故障原因を推定する
必要がある。故障原因が一目瞭然であれば問題ないが、
原因が不明である場合は、サーバーシステム２の故障統
計ＤＢ１６０に登録した情報を活用することで問題箇所
の推定が可能となる。

【００７６】まず、携帯端末等を使用してサーバーシス
テム２にアクセスし（Ｓ５１）、故障箇所検索画面を表
示、この表示に従って、機種、故障内容を入力する（Ｓ
５２）。サーバーシステム２では、その機種、故障内容
をキーにして故障統計ＤＢ１６０を検索し、該当するレ
コードを抽出する。そして、抽出したレコード中の原因
１６２ｃの内容状況を調べ、その件数の多い順に携帯端
末等に表示する（Ｓ５３）。これにより、サービスマン
は表示された原因に基づいて、順次該当しないかを調査
していき（Ｓ５４）、表示された原因が一致した場合に
は、その原因に付随する対処方法１６５を携帯端末等に
表示させ、その表示に基づき処置を行うことになる（Ｓ
５５）。

【００７７】また、対処方法として、部品の交換が必要
な場合には、必要となる交換対象部品リストも携帯端末
等に表示される（Ｓ５６）。ここで、サービスマンが交
換部品を選定すると、サーバーシステム２では、サービ
ス情報ＤＢ１８０を検索して、部品の有無、その部品が
存在する物流管理センターが表示される（Ｓ５７）。さ
らに、サービスマンが故障現場の住所を入力する（Ｓ５
８）ことで、サーバーシステム２では、その住所と各物
流センターの住所から部品が現地に届くまでの時間を表
示する（Ｓ５９）。この状態で、サービスマンが指定時
間を入力すると、サーバーシステム２は物流管理センタ
ーに指定場所に指定時間に部品が届くように発注をだす
ことになる（Ｓ６０）。

【００７８】このようにすることで、サービスマン自身
のスケジュールに部品の到着を合わせることが可能とな
り、特に繁忙期などには時間を有効に使用することが可
能になる。また、当然のことであるが、前もって交換部
品の予測が可能であるなら、先に在庫状況を確認し、近
辺の物流センターへ受け取りに行くことも可能である。

【００７９】なお、一通りの修理作業が終了した後に、
サービスマンは顧客に提出する報告書を作成する必要が
ある。この遠隔監視システムで、報告書を作成する方法
を図２０のフロー図に基づいて説明する。まず、サービ
スマンはサーバーシステム２へアクセスし、報告書作成
メニューを選択する（Ｓ６１）。これにより、サーバー
システム２は端末に報告書作成のためのテンプレートを
表示する（Ｓ６２）。なお、このテンプレートには、故
障発生日時、修復完了日時、故障機器種類、故障原因、
交換部品、故障原因を調べるために参考にした内容等の
入力フィールドがある。サービスマンは、このフィール
ドを入力し、登録完了とする（Ｓ６３）。サーバーシス
テム２では、この内容に従って故障報告書を作成し、顧
客監視物件のクライアント端末４に送信し、さらに、故
障統計ＤＢ１６０にも入力された故障原因、処置方法等
が自動的に登録される（Ｓ６４）。このようにすること
で、故障統計ＤＢ１６０に蓄積された故障情報が増え、
障害発生時により充実した故障統計情報の提供が可能に
なる。

【００８０】なお、この実施の形態における、情報・サ
ービス・対価の流れを図２１に示す。但し、顧客、情報
センター、保守販売会社、保守会社間のフローは基本的
に実施の形態１で示した図１６と同じであるので説明は
省略し、機器メーカーと情報センター間との金銭、情報
等について説明する。機器メーカーはサーバーシステム
２のサービス情報ＤＢ１８０に、機器の最新のサービス
情報をアップロードする。内容としては、サービスパー
ツ等保守部品価格、在庫状況や、故障発生時の対処方法
等である。情報センター２はこれに対し、サービス情報
対価を支払うことになる。また、反対に、機器メーカー
としても、顧客に治めた機器の運転状況を、設置環境や
使用環境毎のデータとして情報センターから得ることが
できる。当然、この情報対価をインフラ使用料として、
情報センターに支払うことになる。

【００８１】次に、金銭の支払方法について、その一例
を記載する。基本的に保守料金としては、契約時に取り
交わす固定料金と、保守会社の緊急出動回数、修理時
間、交換部品費に応じて支払われる変動料金とがある。
固定料金は１月に１回、顧客の口座（クレジット会社）
から、契約された料金を引き落とす。その料金から保守
販売会社及び保守会社の口座に対して按分実施したもの
を振り込む。なお、その際、インフラ使用料として、保
守販売会社、保守会社に支払ううちの、数％を控除した
ものを振り込む。次に、変動費用の支払い方法について
記載する。サービスマンによる保守部品の手配は情報セ
ンターを介して機器メーカーに行く。情報センターはそ
の手配した機器の価格をサービス情報ＤＢ１８０から入
手し、これに手配した数を掛けたものを保守部品料金と
する。なお、この場合に、この保守部品料金の何パーセ
ントかを情報センターの売り上げとして計上し、顧客か
ら得た料金を分配する。

【００８２】ここで、サーバーシステム２での変動費用
の自動決済する流れを以下に示す。例えば、顧客Ａから
１回／月で変動費用を引き落とそうとした場合、サーバ
ーシステム２では顧客情報ＤＢ１４０の機器情報レコー
ドから修理時間１４８ｂと交換部品１４８ｃを読み込
み、サービス情報ＤＢ１８０から交換部品の価格を読み
込み、契約情報ＤＢ１５０から契約内容を読み込み、そ
の月の変動保守料金を計算する。次に、Ａの口座から変
動保守料金を引き落とす次に、契約情報ＤＢ１５０から
保守会社と保守販売会社を抽出し、変動保料金を保守会
社変動料金と保守販売会社変動料金に分配する。次に、
保守会社変動料金、保守販売会社変動料金から、契約内
容に従い、インフラ使用料金を控除し、控除後のものを
それぞれの口座に振り込む。このようにすることで、固
定費、変動費の支払いを全て情報センター経由で実施す
ることが可能となる。

【００８３】このように、故障部位の推定においては、
通常各保守会社及び、サービスマンのノウハウによるも
のが一般的であるが、故障統計ＤＢを活用することによ
り、ノウハウのない、熟練度の低いサービスマンにおい
ても、機器の復旧が容易になる。

【００８４】また、この故障統計ＤＢは特定保守会社用
に用いるものではないことから、他の保守会社、もしく
は機器メーカーのノウハウも織り込まれることになり、
様々な発生パターンへの対応が可能となる。

【００８５】また、報告書作成時にインプットする故障
原因等が自動的に故障統計ＤＢに蓄積されるので、故障
解析・処置のためのノウハウとなるバックデータを自動
的に蓄積することが可能になる。

【００８６】さらに、アプリケーションインターフェー
ス部分をクライアントへ提供する形になっているので、
現地で作業を実施するサービスマンは、特にパソコンを
保持しなくても必要なデータを携帯電話などの携帯端末
から簡単に入手可能であるだけでなく、作業報告書など
も作成できる。

【００８７】また、当然のことながら、サービスマンの
現場への早期到着と、早期の原因究明がなされれば、顧
客にとっては、不快な環境から早期に逃れることげでき
るというメリットを享受できる。

【００８８】また、機器メーカーとしては、最新のサー
ビス情報を即座に伝達可能であるとともに、設置環境や
使用環境毎の機器の運転状態データを収集することが可
能で、初期流動の監視や、バージョンアップ品開発への
フィードバックに有益なデータを、そのための設備開発
や、営業活動なしに得ることが可能である。

【００８９】実施の形態３．図２２は、この遠隔保守監
視システムで異常・変調発生時に保守代行を請け負って
いる保守会社（一次保守会社）が、他の保守会社（二次
保守会社）に出動代行を依頼する場合の情報の流れを示
すブロック図である。なお、通常一次保守会社としては
サービス会社、二次保守会社としては地域工事会社とさ
れるであろう。また、この実施の形態３における遠隔保
守監視システムでは、図２３に示す様に、サーバーシス
テムの顧客情報ＤＢ１５０の保守会社ＩＤに一次保守会
社ＩＤと二次保守会社ＩＤとが登録されることになる。

【００９０】次に、異常・変調が発生した場合の代行依
頼について以下に説明する。まず、サーバーシステム２
では、異常検出通知を受けた場合、契約情報ＤＢ１５０
を顧客ＩＤに基づき検索することで、担当の一次保守会
社と二次保守会社に対して異常もしくは、変調が発生し
た旨を情報伝達手段１ｂを介して通知する。

【００９１】この場合、一次保守会社で対応可能である
ならば、一次保守会社から二次保守会社へその旨連絡す
れば良い。現場では、一次保守会社のサービスマンが修
理作業を実施することになる。また、一次保守会社で、
サービスマンが出払っている場合には、一次保守会社か
ら二次保守会社へ連絡がなされ、二次保守会社のサービ
スマンが現場へ赴くことになる。

【００９２】なお、二次保守会社のサービスマンが現場
に出動した際は、その二次保守会社へ料金が支払われる
ことになるが、自動決済を実施する場合には、二次保守
会社が作業を実施した旨の登録は、故障発生時に作成す
る報告書にて、作業者を入力する仕組みを設けること
で、報告書から費用を割り出す際に二次保守会社が作業
実施したことが明確になり、自動決済も正常に行われ
る。

【００９３】なお、この実施の形態における、情報・サ
ービス・対価の流れを図２４に示す。顧客、情報センタ
ー、保守販売会社、一次保守会社、二次保守会社間の情
報・サービス・対価のフローは実施の形態２とほぼ同様
であるが、本実施の形態の場合には、一次保守会社から
の出動代行依頼により出動、対応した二次保守会社が、
その代行料金を受領することになる点が実施の形態２と
異なる。なお、二次保守会社が受け取る対価は、代行出
動の回数により変化するものである。一次保守会社は出
動を実施せず、通常保守しか実施しなかった場合は、そ
の通常保守に対する対価のみ受領することになる。

【００９４】このように、１つの顧客を担当する保守会
社を複数指定できるようにすることで、サービスマンの
割り当てができない場合や、実際にサービスマンが配置
された拠点から離れた場所にある顧客への出動サービス
の場合には、その顧客の近隣の保守会社に依頼すること
ができ、顧客に対してきめこまかいサービスを提供する
ことが可能となる。また、一次保守会社としても、出動
によるサービス料金を受領することはできないが、現場
への移動時間や、対処可能なサービスマンが不足してい
る場合などでも契約の不履行を発生させず、対処可能で
ある。さらに、二次保守会社においては、代行業務を受
けることで、代行料金を享受できる。

【００９５】実施の形態４．一般に、規模の小さい地域
工事会社においては、サービスマンの数が限られている
ことから、異常発生時の２４時間、３６５日の出動体制
を整えることができないことがあり、異常出動に対して
の保守代行業務を受けることができない場合がある。図
２５は、このような問題に対応するため、保守作業を請
け負う地域工事会社が共同で異常・変調発生時の出動を
実施する場合の情報の流れを示すブロック図である。な
お、この実施の形態４における遠隔保守監視システムで
は、サーバーシステムの契約情報ＤＢ１５０の一次保守
会社ＩＤには、異常出動以外の通知点検等を実施し、対
象顧客に対する報告書作成等の基本的保守業務の窓口と
なる保守会社を設定し、二次の保守会社ＩＤには、会社
名称を記載せずに、共同で異常発生出動代行を実施する
地域工事のユニオンＩＤを登録してある。

【００９６】また、新たに、ユニオン記憶部に相当する
ユニオンデータベース（以下、「ユニオンＤＢ」）が設け
られることになる。図２６はユニオンＤＢ２００のレコ
ードのフォーマットであり、ユニオンＩＤ２０１と、保
守会社ＩＤ２０２と、対応人数２０３とを有している。
また、対応人数としては、具体的に、５月の平日に対応
できるサービスマンの数、５月の休日・深夜に対応でき
るサービスマンの数等、曜日、時間帯毎の対応可能人員
である。

【００９７】次に、実際に冷熱機器システムで異常・変
調が発生した際のサーバーシステム２の動作について図
２７のフロー図に基づいて説明する。まず、サーバーシ
ステム２では、異常検出通知を受けた場合、契約情報Ｄ
Ｂ１５０を顧客ＩＤに基づき検索することで、担当の一
次のサービス会社に異常もしくは、変調が発生した旨を
情報伝達手段１ｂを介して通知する（Ｓ７１）。さら
に、二次保守会社ＩＤに指定されたユニオンＩＤをキー
として、ユニオンＤＢ２００にアクセスし、ユニオンＩ
Ｄ２０１が一致する地域工事会社のうち、この時間帯に
対応の可能なサービスマンを保持する地域工事会社を抽
出する（Ｓ７２）。なお、複数の地域工事会社で対応可
能な場合は、今までの出動回数の統計から、自動的に出
動回数の少ない地域工事会社を割り当てることになる。

【００９８】次に、出動可能なサービスマンが０である
か否かを判定する（Ｓ７３）。ここで、０であると判定
された場合には、再度ユニオンＤＢ２００にアクセス
し、今度はユニオンＩＤに関係なく、この時間帯に対応
の可能なサービスマンを保持する地域工事会社を抽出
し、その中から顧客の場所等の面から最適なものを抽出
する（Ｓ７４）。Ｓ７３でサービスマンが０でない場
合、およびＳ７４で抽出できた場合には、保守会社ＩＤ
２０２をキーにして保守会社登録ＤＢ１９０を検索し、
その地域工事会社の連絡先に通知する（Ｓ７５）。

【００９９】なお、万一検索された地域工事会社に通知
したが対応不可能な場合を考慮するのであれば、ユニオ
ンＤＢの対応人数は、各地域会社が現在の状況、例えば
急ぎ障害が発生したためにサービスマンが出払った状況
になった時点で、自分のクライアント端末５からいつで
も変更可能としておけばよい。

【０１００】なお、この実施の形態における、情報・サ
ービス・対価の流れを図２８に示す。顧客、情報センタ
ー、保守販売会社、保守会社間の情報・サービス・対価
の流れは実施の形態３とほぼ同様であるが、通常保守の
料金は一次保守会社として登録されたサービス会社が、
異常発生出動にかかったサービス費用は実際に出動対応
した地域工事会社が受領することになる点で異なる。こ
の実施の形態では、地域工事会社間の連合としている
が、サービス会社を加えて、休日や、夜間の時間帯など
は地域工事会社にて出動対応が困難な場合など、サービ
ス体制の充実したサービス会社に委託することも可能で
ある。また、顧客との契約内容が、定期点検等がなく、
異常発生対応のみであるならば、ユニオンＩＤは当然に
一次保守会社として登録しておいてもよい。

【０１０１】このように、契約情報に、異常発生時の出
動会社グループを登録し、そのグループ（ユニオン）の
スケジュールＤＢを設けることで、出動体制が不足して
いる地域工事会社間でも、出動スケジュールを充実させ
ることが可能であり、さらに、２４時間対応が不可能
で、保守契約を実施できなかった場合など、互いに補完
し合うことで、サービス会社に負けない出動サービス網
を得ることができる。

【０１０２】また、休日・夜間など、どうしても出動で
きない場合には、サービス網の充実した、サービス会社
に出動代行を依頼することも可能である。実際に地域工
事会社が業務代行を実施する場合にも、情報センター内
の各サービス情報を地域工事会社もサービス会社を同等
に享受できるので、サービス品質が落ちることもなく、
また、部品発注手配なども、サービス会社と同等に実施
することが可能である。サービス会社は、出動代行業務
を実施することで、サービスマンを有効活用でき、また
その対価による収益増加が見込める。

【０１０３】実施の形態５．ところで、実施の形態１〜
４においては、実際に現場にて保守サービスを実施する
部門（サービス会社、地域工事会社）、販売を行う部門
（保守販売会社）、機器を製造する部門（機器メーカ
ー）、情報管理部門（情報センター）を別々の会社と
し、また、顧客との保守サービスは保守販売会社が締結
し、客先窓口（契約、報告書提出等）は全て保守販売会
社が実施し、サービス会社、地域工事会社は保守販売会
社からの業務代行を請け負い、各事業者が得意分野に特
化した業務のみ実施することで、保守業務全体の効率化
を図っている。その流れを前提に、情報・サービス・対
価の流れを図示したが、例えば、保守販売会社と情報セ
ンターが同一であった場合や、客先都合により、顧客と
の保守契約はサービス会社が結んだ場合などで、情報・
サービス・対価の流れが異なることもある。

【０１０４】図２９は実施の形態１〜４以外の形態とな
った場合の情報・サービス・対価の流れを示したもので
ある。図２９（ａ）はサービス会社、地域工事会社な
ど、実際に機器の保守を行う会社が、顧客と保守契約を
結ぶ場合での情報・サービス・対価の流れを示したもの
である。具体的には、顧客には決まった一次サービス会
社があり、基本的に機器故障時の対応や通常の定期点検
はその特定のサービス会社が実施しているが、情報セン
ターで保存している機能を有効活用したい場合など、情
報センターが提供するインフラを活用するものである。
なお、当然のことながら、契約情報ＤＢに二次出動対応
の保守会社を登録することで、実施の形態３と同様のフ
ローで、二次対応を委託することも可能である。

【０１０５】図２９（ｂ）は、情報センターと保守販売
会社が同じ会社であった場合での情報・サービス・対価
の流れを示したものである。この場合、当然のことなが
ら、図１０における、情報センターと保守販売会社間の
サービスと対価の授受フローがなくなることになる。事
業規模（保守システムの規模）によっては、このような
形態、すなわち、販売機能とインフラ整備機能が統合さ
れることは考えられる。

【０１０６】このように、各部門（会社）の形態や、顧
客との契約形態により、金銭等のフローは異なってくる
が、情報センターを核とし、顧客との接続形態や、各事
業者間のＨ／Ｗ的なつながり（システム）は実施の形態
１〜４に示す内容と変わらないので、契約形態が変更し
ても、特に投資が増えたり、サービス内容が低下するよ
うなことはありえなく、よって、顧客としても、得られ
るメリットについては、実施の形態１〜４と変わらない
ものを得ることができる。裏を返せば、顧客の望む形態
で、契約が可能となる。

【０１０７】実施の形態６．実施の形態１では、顧客と
の契約内容に従い、実現のために必要なアプリケーショ
ンやデータをサーバーシステムから遠隔監視装置に配信
し、必要なだけのデータをサーバーシステムで受信し、
運用状態ＤＢに記憶していたが、全ての遠隔監視装置を
同じ状態、すなわち全機能（アプリケーション、デー
タ）をあらかじめ顧客監視物件に設置された遠隔監視装
置に配信し、収集可能な全データを運転状態ＤＢに記憶
させるようにしてもよい。図２４は、遠隔保守監視装置
が全て同じ機能、すなはち冷熱機器の全ての情報を収集
して、サーバーシステムに送信する場合の情報の流れを
示すブロック図である。なお、この場合には、収集され
た全てのデータを保守販売会社に開示するのではなく、
契約内容になり、必要な部分のみ開示される。その他の
データについては、必要であれば、追加サービス料金を
情報センターに支払うことで、保守販売会社は情報を得
ることができる。なお、それらのデータは、省エネ運転
の提案や、リニューアル提案に活用できる。また、情報
センターに蓄積されたデータは、機器メーカーが必要と
すれば、機器メーカーにも提供される。機器メーカーと
しては、情報料金を情報センターに支払うだけで、流動
監視したい機器の運転状態データを得ることができる。

【０１０８】この場合、保守販売会社をサーバーシステ
ム２の契約情報ＤＢに登録する場合のフローを図３１に
示す。保守販売会社の従業員は、自らの端末からサーバ
ーシステム２のＷＷＷサーバ・情報発信手段１１０にア
クセスし、保守販売会社登録ページを端末に表示させる
（Ｓ８１）。なお、この保守販売会社登録ページには登
録に必要となる各種情報入力フィールドとともに、保守
販売会社が通常の情報を受信することができる通常契約
か、全情報を受信することができる特別契約かを設定で
きる入力フィールドも存在している。ここで、従業者は
入力フィールドに入力する。サーバーシステム２では、
入力内容を判定し（Ｓ８２）、通常契約の場合には、契
約情報ＤＢ１５０の保守販売会社契約レコードの全情報
閲覧１５９ｂにＮが設定され（Ｓ８３）、特別契約の場
合には、Ｙが設定される（Ｓ８４）。また、料金の自動
決済では、通常契約の場合には、保守販売会社に按分し
た分配額からインフラ使用料金を差し引くが、特別契約
の場合には、実際に閲覧した情報量分に対応した情報料
金をインフラ使用料金とともに差し引くようにする。な
お、情報量の算出は、パケット量によっても良いし、接
続時間によっても問題ない。

【０１０９】図３２はこの実施の形態における、情報・
サービス・対価の流れを示したものである。保守会社
や、機器メーカーは通常のインフラ使用料金の他に、追
加情報料金を支払う仕組みが追加されることになる。な
お、本実施の形態では、運転状態監視サービスの内容に
特化して説明を実施したが、異常・変調出動サービス
や、代行サービスにおいても、情報センターでデータを
全て取り込むこと以外は共通であり、無論そのような形
態で実施されることに問題はない。

【０１１０】このように、情報センターでは、全てのデ
ータをあらかじめ収集可能であるので、そのデータを情
報として、機器メーカは享受でき、保守販売会社も顧客
に対して別の提案を実施する際のバックデータを得るこ
とが可能となる。

【０１１１】情報センターにおいても、それら、追加情
報料金の対価を得ることができる。また、顧客にとって
は、通常の契約料金を支払うだけで良く、さらにそれに
追加して、最適な契約の提案を受けることができる。

【０１１２】

【発明の効果】このように、この発明では、情報センタ
ーに設けられたサーバーシステムを介して、保守会社、
保守販売会社、顧客等で情報の送受信や、業務の委託等
をなすことができ、それぞれが得意の業務の注力できる
ので、業務効率が向上する。

【図面の簡単な説明】

【図１】 実施の形態１における遠隔保守監視システム
の構成図である。

【図２】 サーバシステムの構成図である。

【図３】 現地情報ＤＢのフォーマット図である。

【図４】 顧客情報ＤＢのフォーマット図である。

【図５】 契約情報ＤＢのフォーマット図である。

【図６】 故障統計ＤＢのフォーマット図である。

【図７】 運転情報ＤＢのフォーマット図である。

【図８】 サービス情報ＤＢのフォーマット図である。

【図９】 保守会社登録ＤＢのフォーマット図である。

【図１０】 冷熱機器システムの構成図である。

【図１１】 サーバーシステムとクライアント端末との
情報伝達の構成を示す構成図である。

【図１２】 実施の形態１における遠隔保守監視システ
ムでの情報の流れを示すブロック図である。

【図１３】 保守会社の選定・確認方法を示すフロー図
である。

【図１４】 契約情報ＤＢへの登録方法を示すフロー図
である。

【図１５】 保守実施時の報告書の作成方法を示すフロ
ー図である。

【図１６】 実施の形態１における情報・サービス・対
価を示すフロー図である。

【図１７】 自動決済の方法を示すフロー図である。

【図１８】 実施の形態２における遠隔保守監視システ
ムでの情報の流れを示すブロック図である。

【図１９】 異常発生時でのサービスマンの情報入手方
法を示すフロー図である。

【図２０】 報告書作成方法を示すフロー図である。

【図２１】 実施の形態２における情報・サービス・対
価を示すフロー図である。

【図２２】 実施の形態３における遠隔保守監視システ
ムでの情報の流れを示すブロック図である。

【図２３】 顧客情報ＤＢのフォーマット図である。

【図２４】 実施の形態３における情報・サービス・対
価を示すフロー図である。

【図２５】 実施の形態４における遠隔保守監視システ
ムでの情報の流れを示すブロック図である。

【図２６】 ユニオンＤＢのフォーマット図である。

【図２７】 異常・発生時のサーバーシステムの動作を
示すフロー図である。

【図２８】 実施の形態４における情報・サービス・対
価を示すフロー図である。

【図２９】 実施の形態５における情報・サービス・対
価を示すフロー図である。

【図３０】 実施の形態６における遠隔保守監視システ
ムでの情報の流れを示すブロック図である。

【図３１】 契約情報ＤＢに保守販売会社を登録する方
法を示すフロー図である。

【図３２】 実施の形態６における情報・サービス・対
価を示すフロー図である。

【符号の説明】

１ 情報伝達手段、 ２ サーバーシステム、 ３ 冷
熱機器システム、４ 顧客監視物件のクライアント端
末、 ５ 保守会社のクライアント端末、６ 保守販売
会社のクライアント端末、７ 機器メーカーのクライア
ント端末、３１ 冷熱機器、 ３２ 遠隔監視装置、
３３ 制御線、１００ プログラム配信手段、１１０
ＷＷＷサーバー・情報発信手段、１２０ アプリケーシ
ョンサーバー、 １３０ 現地情報ＤＢ、１４０ 顧客
情報ＤＢ、 １５０ 契約情報ＤＢ、 １６０ 統計情
報ＤＢ、１７０ 運転状態ＤＢ、 １８０ サービス情
報ＤＢ、１９０ 保守会社登録ＤＢ、 ２００ ユニオ
ンＤＢ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 粟田 浩 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 (72)発明者 杉本 達彦 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 (72)発明者 佐藤 康夫 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 Ｆターム(参考） 3L061 BA05 5B049 CC45 EE05 GG02 5K048 AA00 BA08 BA51 DC07 EB08 FC01 GB08 HA01 HA02

Claims (25)

【特許請求の範囲】
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. 【請求項２５】 機器を監視する監視装置と、前記監
    視装置に接続された請求項１から請求項２４のいずれか
    に記載の管理システムと、前記管理システムと通信媒体
    を介して接続された通信装置とを有することを特徴とす
    る遠隔保守監視システム。