JP2008275317A - 冷熱機器管理システム、および冷熱機器の遠隔保守監視システム - Google Patents

Abstract

【課題】 従来の冷熱器等の遠隔保守は、保守会社自身で実作業から機器監視までをしなければならず、全ての業務を十分に行うことができないという問題があった。
【解決手段】 この発明にかかる冷熱機器管理システムにおいては、通信機器から送られた冷熱機器を利用する顧客との契約情報に基づいて、監視装置を制御する制御プログラムを生成する生成手段と、制御プログラムを前記監視装置に送信する送信手段とを有するものとした。
【選択図】 図１２

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実施の形態１における遠隔保守監視システムの構成図である。 サーバシステムの構成図である。 現地情報ＤＢのフォーマット図である。 顧客情報ＤＢのフォーマット図である。 契約情報ＤＢのフォーマット図である。 故障統計ＤＢのフォーマット図である。 運転情報ＤＢのフォーマット図である。 サービス情報ＤＢのフォーマット図である。 保守会社登録ＤＢのフォーマット図である。 冷熱機器システムの構成図である。 サーバーシステムとクライアント端末との情報伝達の構成を示す構成図である。 実施の形態１における遠隔保守監視システムでの情報の流れを示すブロック図である。 保守会社の選定・確認方法を示すフロー図である。 契約情報ＤＢへの登録方法を示すフロー図である。 保守実施時の報告書の作成方法を示すフロー図である。 実施の形態１における情報・サービス・対価を示すフロー図である。 自動決済の方法を示すフロー図である。 実施の形態２における遠隔保守監視システムでの情報の流れを示すブロック図である。 異常発生時でのサービスマンの情報入手方法を示すフロー図である。 報告書作成方法を示すフロー図である。 実施の形態２における情報・サービス・対価を示すフロー図である。 実施の形態３における遠隔保守監視システムでの情報の流れを示すブロック図である。 顧客情報ＤＢのフォーマット図である。 実施の形態３における情報・サービス・対価を示すフロー図である。 実施の形態４における遠隔保守監視システムでの情報の流れを示すブロック図である。 ユニオンＤＢのフォーマット図である。 異常・発生時のサーバーシステムの動作を示すフロー図である。 実施の形態４における情報・サービス・対価を示すフロー図である。 実施の形態５における情報・サービス・対価を示すフロー図である。 実施の形態６における遠隔保守監視システムでの情報の流れを示すブロック図である。 契約情報ＤＢに保守販売会社を登録する方法を示すフロー図である。 実施の形態６における情報・サービス・対価を示すフロー図である。

符号の説明

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

Claims (22)

1. 冷熱機器を監視する監視装置から送信された前記冷熱機器の運転情報に基づいて、前記冷熱機器の運転状況を管理する冷熱機器管理システムにおいて、通信機器から送られた前記冷熱機器を利用する顧客との契約情報に基づいて、前記監視装置を制御する制御プログラムを生成する生成手段と、前記制御プログラムを前記監視装置に送信する送信手段とを有することを特徴とする冷熱機器管理システム。
2. 冷熱機器を監視する監視装置から送信された前記冷熱機器の運転情報に基づいて、前記冷熱機器の運転状況を管理する冷熱機器管理システムにおいて、通信機器から送られた前記冷熱機器を利用する顧客との契約情報に基づいて、前記監視装置で動作する制御プログラムにより参照される制御パラメータを生成する生成手段と、前記制御パラメータを前記監視装置に送信する送信手段とを有することを特徴とする冷熱機器管理システム。
3. 冷熱機器を監視する監視装置から送信された前記冷熱機器の運転情報に基づいて、前記冷熱機器の運転状況を管理する冷熱機器管理システムにおいて、前記冷熱機器を利用する顧客と、前記冷熱機器の保守を担当する保守会社とを対応付けて登録した契約記憶部を有し、前記運転情報から冷熱機器の異常または変調を検知した場合には、前記契約記憶部を参照し、前記異常または変調が検知された冷熱機器の保守を担当する保守会社に通知することを特徴とする冷熱機器管理システム。
4. 保守会社と、前記保守会社の保守業務条件とを対応付けて登録した保守会社記憶部を有し、通信機器から顧客との契約条件が送信された場合には、前記保守会社記憶部を参照して、前記契約条件に適合する保守業務条件の保守会社を抽出し、契約記憶部に前記保守会社と前記顧客とを対応付けて登録することを特徴とする請求項３に記載の冷熱機器管理システム。
5. 保守会社と、前記保守会社の保守業務条件とを対応付けて登録した保守会社記憶部を有し、通信機器から顧客とその顧客に対応付ける保守会社が送信された場合には、前記顧客に前記保守会社を対応付けて契約記憶部に登録し、前記通信機器から顧客との契約条件が送信された場合には、前記保守会社記憶部を参照して、前記契約条件に適合する保守業務条件の複数の保守会社を抽出して前記通信機器に送信し、前記複数の保守会社から選択された１社が前記通信機器から送信された場合には、前記契約記憶部に前記顧客と対応付けて登録するとともに、前記選択された保守会社に通知することを特徴とする請求項３に記載の冷熱機器管理システム。
6. 通信機器に、顧客と前記顧客の保守業務条件の入力を促す画面を送信することを特徴とする請求項４または５に記載の冷熱機器管理システム。
7. 契約記憶部には、保守会社と前記保守会社の権限とが対応付けられて登録されていることを特徴とする請求項４から６のいずれかに記載の冷熱機器管理システム。
8. 通信機器から保守会社と前記保守会社の保守業務条件、および権限を受信した場合には、契約記憶部に前記保守会社と前記権限とを対応つけて登録し、前記保守会社記憶部に前記保守会社と前記保守業務条件とを対応付けて登録することを特徴とする請求項７に記載の冷熱機器管理システム。
9. 通信機器に、保守会社と前記保守会社の保守業務条件、権限の入力を促す画面を送信することを特徴とする請求項８に記載の冷熱機器管理システム。
10. 契約記憶部には、保守販売会社と前記保守販売会社の権限とが対応付けられて登録されており、さらに、冷熱機器を利用する顧客と、前記冷熱機器の保守を担当する保守会社と、前記顧客と保守契約を結んだ保守販売会社とが対応付けられて登録されていることを特徴とする請求項３から９のいずれかに記載の冷熱機器管理システム。
11. 顧客の口座から予め契約された内容に基づく料金を引き落とす引き落とし手段と、契約記憶部を参照し、前記顧客に対応付けられた保守会社と保守販売会社とに前記料金を按分して保守会社料金および保守販売会社料金を算出する第１の計算手段と、前記契約記憶部を参照して保守会社手数料と保守販売会社手数料を算出する第２の計算手段と、前記保守会社料金から前記保守会社手数料を差し引いたものを前記保守会社の口座に振り込み、前記保守販売会社料金から前記保守販売会社手数料を差し引いたものを前記保守販売会社の口座に振り込む振り込み手段とを有することを特徴とする請求項１０に記載の冷熱機器管理システム。
12. 顧客の地図情報が登録された顧客情報記憶部を有し、通信機器から送信された要求により、前記地図情報を前記通信機器に送信することを特徴とする請求項３から１１のいずれかに記載の冷熱機器管理システム。
13. 監視装置から送信された冷熱機器の運転情報を顧客と対応付けて登録する運転状態記憶部を有し、前記運転状態記憶部を参照して前記顧客毎の運転状況報告書を作成することを特徴とする請求項３から１２のいずれかに記載の冷熱機器管理システム。
14. 冷熱機器の異常または変調の現象と故障原因、対処方法が対応付けて登録された故障統計記憶部を有し、通信機器から送信された前記現象から、前記故障統計記憶部を参照し、前記現象に対応した故障原因および故障方法を前記通信機器に送信することを特徴とする請求項３から１３のいずれかに記載の冷熱機器管理システム。
15. 通信機器に現象の入力を促す画面を送信することを特徴とする請求項１４に記載の冷熱機器管理システム。
16. 通信機器から冷熱機器の異常または変調の現象と故障原因、対処方法が送信された場合には、前記送信された情報を故障統計記憶部に登録するとともに、前記送信された情報に基づいて報告書を作成することを特徴とする請求項１４または１５に記載の冷熱機器管理システム。
17. 通信機器に冷熱機器の異常または変調の現象と故障原因、対処方法の入力を促す画面を送信することを特徴とする請求項１６に記載の冷熱機器管理システム。
18. 契約記憶部には、冷熱機器を利用する顧客と、前記冷熱機器の保守を担当する複数の保守会社とが対応付けて登録されており、運転情報から冷熱機器の異常または変調を検知した場合には、前記契約記憶部を参照し、前記異常または変調が検知された冷熱機器の修理を担当する複数の保守会社に通知することを特徴とする請求項３に記載の冷熱機器管理システム。
19. 契約記憶部に登録された保守販売会社の権限に基づき、運転状態記憶部へのアクセスが制限されることを特徴とする請求項１１に記載の冷熱機器管理システム。
20. 冷熱機器を監視する監視装置から送信された前記冷熱機器の運転情報に基づいて、前記冷熱機器の運転状況を管理する冷熱機器管理システムにおいて、前記冷熱機器を利用する顧客と、前記冷熱機器の修理を担当する保守会社のグループとを対応付けて登録した契約記憶部と、各保守会社と、前記保守会社の対応可能人数とを対応付けて登録したユニオン記憶部とを有し、前記運転情報から冷熱機器の異常または変調を検知した場合には、前記契約記憶部を参照して前記異常または変調が検知された冷熱機器の修理を担当するグループを抽出し、前記ユニオン記憶部を参照して、前記対応可能人数に基づき前記グループ内の保守会社から少なくとも１つの保守会社を選択し、前記保守会社に通知することを特徴とする冷熱機器管理システム。
21. 対応可能人数は、通信機器により常時修正可能であることを特徴とする請求項２０に記載の冷熱機器管理システム。
22. 冷熱機器を監視する監視装置と、前記監視装置に接続された請求項１から請求項２１のいずれかに記載の冷熱機器管理システムと、前記冷熱機器管理システムと通信媒体を介して接続された通信装置とを有することを特徴とする冷熱機器の遠隔保守監視システム。

Images