JP2004220560A - 電子装置保守システム - Google Patents

Abstract

【課題】電子装置の遠隔保守を効率的におこなう電子保守システムを提供する。
【解決手段】電子保守システムの中央サーバ５０は、不定期の保守を必要とする複写機、プリンタ、及びスキャナなどの複数の電子装置２６、２８、３０、３２、３４、３６、３８、４０、４２、４４、４６、４８からステータス情報を受信するために設けられる。必要に応じて、中央サーバは装置のうちの特定の１台に関連する保守機構５２に、例えば、その装置において障害が発生したことを報告するメッセージを送信する。メッセージにより、保守機構は中央サーバからその装置に関するステータス情報を取得することができる。
【選択図】図３

Description

本発明は、電子装置の遠隔保守(remote maintenance)に関する。

プリンタ、複写機、及びスキャナなどの電子装置に対する保守の提供が知られている。オフィス環境には、何種類もの電子装置が存在し、これらの装置に対して１社以上の保守会社が保守サービスを提供していることもある。これらのうちの１台が、専門家のサポートを必要とする障害が識別されるときには、関連する保守会社にサービスコールをかける。

図１はサービスコールを処理する典型的な構成を示す。図１の構成は、顧客２、コール入力オペレータ４、ディスパッチャ６、及びエンジニア８を含む。

顧客２は、電話をかけて電子装置の障害をコール入力オペレータ４に報告する。例えば、顧客は複写機の動作が停止し、エラーメッセージを表示していると報告する。コール入力オペレータ４は、発信者の氏名、障害のある装置のＩＤ、及びエラーメッセージのメモを含む障害の詳細などの情報を記録することによって通話のログを残す。この場合、発信者には、そのジョブ参照を与えるようにしても良い。

コール入力オペレータ４が記録した情報はデータベース上に記録される。このデータベースにはディスパッチャ６がアクセスする。ディスパッチャ６はその障害を査定し、適切な処置を取る。ここで必要とされる処置は、自力で障害を復旧する方法を顧客２に説明することであっても良い。あるいは、顧客の元へエンジニア８を派遣することであっても良い。ここで、ディスパッチャ６は、コール入力オペレータ４と同一人物であっても良い。

図１のサービス構成の問題点は、顧客２が障害を検出してコール入力オペレータ４に報告しない限りサポートが受けられないことである。障害の報告が遅れ、障害への対処が可能になるまで、例えば、エンジニア８が顧客２の元へ到着するまでに更に遅れることは必至であろう。この間、その装置は使用不可能となる可能性が高い。

図１のサービス構成の更なる問題点は、顧客２は障害の発生後にならないと報告することができないことである。つまり、顧客２は潜在的(potential)な障害を監視する手段を持たない。障害を予測することができ、発生前に処置を取ることができるならば、装置の故障を防止することができる。更に、障害の発生前に処理することによって、時には損傷を与えるような紙詰まりなどの障害を回避することができる。損傷を受けた装置の修理に要する費用は、障害の発生を防止するのにかかる費用よりも格段に高い可能性がある。

図２は、上述の障害に対処するために開発された既知の保守システム（符号１０で示される）を示す。このシステムは、第１の電子装置１２、第２の電子装置１４、及び第３の電子装置１６を含む。これらの装置は複写機、プリンタ、又はスキャナなどであっても良い。システムは、クライアントコンピュータ１８及びサーバコンピュータ２０を更に含む。遠隔故障診断ソフトウェア２２は、サーバコンピュータ２０と関連付けられている。遠隔故障診断ソフトウェア２２は、以降、略語のＲＤＳを用いて呼ぶこととする。サーバ２０は、遠隔バックエンド２４（サービス管理コンピュータシステムとも呼ばれる）に電子的に接続される。

電子装置１２、１４、及び１６、クライアントコンピュータ１８、及びサーバ２０の全てはローカルネットワークバス２６を用いて接続されている。装置１２、１４、及び１６のステータスに関する情報をサーバ２０が回収する。この情報に基づいてＲＤＳ２２の制御を受けながら、サーバ２０はクライアントコンピュータ１８及びバックエンド２４と通信を行なう。

バックエンド２４は、装置１２、１４、及び１６の保守を担当する機構である。バックエンド２４は、ＲＤＳ２２により提供されるデータを受信すると、これに応じた処置（アクションン）を開始することができる。すなわち、バックエンド２４は、図１のコール入力オペレータ４及びディスパッチャ６の機能を実行するので、顧客はコール入力オペレータに電話をかける必要がない。

図２の例において、装置１２及び１６はデジタルステータス情報を提供することが可能なデジタル装置であり、この情報はバス２６を介して収集することができる。実際には、ステータス情報の送信は、ＲＤＳが装置をポーリングし、それに応答する形で行なわれる。装置１４はこの機能を持たないアナログ装置である。装置１４には直接アクセス機構２８が備わっており、装置１４のステータスに関するアナログ情報をバス２６を介してアクセス可能なデジタルデータへと変換する。

バス２６を介して収集可能なデータには、用紙及びトナーの量の示度、紙詰まり（ジャム）、エラー又はアラーム、部品数（parts conters）、用紙使用情報、装置使用情報、装置に取り付けられている機器（文書フィーダなど）、及び装置にインストールされているソフトウェアが含まれる。

ＲＤＳは複数の機能を実行する。この機能には、接続している装置のステータスの監視、装置に関するデータの格納及び分析、障害及び潜在的な障害の顧客及び／又はバックエンドへの通知、及び用紙及びトナーなどの消耗品の使用状況の探知が含まれる。

ＲＤＳ２２は、２つの異なる条件の下、すなわち、イベントデータとして又は定期データとしてバックエンド２４にデータを送信することができる。イベントデータは、ＲＤＳがイベントを検出するか、あるいは、一定の条件又は閾値が満たされると送信される。定期データは、毎週（例えば、毎週月曜日の０時３０分）又は毎月（例えば、毎月２８日の０時３０分）などの一定の間隔で送信される。

収集される定期データは、例えば、装置内の部品の予想寿命に関する情報を含む。

先ず、イベントデータについて考察する。ＲＤＳ２２は、様々なクラスのイベントをそれぞれ異なった方法で処理する。最も重大なイベントは装置の動作を妨げるイベントであり、これを「エラー」と呼ぶ。装置の動作を妨げない重大なイベントは「アラーム」を発する。「アラーム」には深刻な性質のものがあり、その場合、バックエンド２４への迅速な通知が必要である。深刻でない性質のものもあるが、その場合でも再発する可能性が高い。例えば、エラーとしては紙詰まり、アラームとしてはトナー残量の僅少がある。

ＲＤＳは各装置１２、１４、及び１６を監視し、いずれかの装置が動作を停止するとエラーが識別される。ＲＤＳがエラーを検出すると、クライアントコンピュータ１８及びバックエンド２４の双方がその通知を受ける。（尚、クライアントコンピュータ及びサーバコンピュータは１台の同じ装置であっても良い。）
本質的に、エラーには顧客が復旧可能なものとエンジニアの派遣が必要なものとの２種類がある。エラーへの対応はバックエンド２４により判定される。エラーメッセージを受信すると、関連する装置のステータスを調べ、適切な処置を取ることができる。場合によって、エンジニアを装置の設置場所へ派遣する必要、あるいは、顧客と連絡を取って顧客自身が実行可能な手順を説明する必要が生じる。いずれの選択肢が実施される場合でも、顧客がエラーに気づくのを待つのではなく、バックエンド２４が主導権を取ることができる。

また、ＲＤＳは、装置１２、１４、及び１６において、動作を妨げない重大なイベント又は潜在的に重大なイベントの発生を監視する。上述のように、このようなイベントをアラーム状態と呼ぶ。ＲＤＳがアラーム状態を検出すると、バックエンド２４は通知を受けるが、顧客には通知されない。これは、当該装置が動作中であり、クライアントは障害の可能性があることを認識する必要がないからである。障害があることに顧客が気づく前に、バックエンド２４は上述のように適切な処置を取ることができる。これにより、当該装置の休止時間を最小限にして潜在的に重大な障害を防止することができるであろう。

ＲＤＳの使用により、保守部門は事前に処置を取ることが可能になる。例えば、アラーム状態は、障害が近い将来に発生する可能性が高いことを示すかもしれない。この場合、障害発生前に保守処置を取ることが可能になり、機械類の休止時間及び損傷を減少させる結果となる。

上述のシステムは、バックエンドが１つしかない場合でも十分に機能するが、必ずしもこの構成でなくても良い。システムの多様な顧客をサポートする複数の異なる保守機構があっても良い。この異なる機構は、異なるサービスバックエンド（以降、「サービス管理システム」と呼ぶ）を有するものと想定される。

この場合、異なるサービス管理システムは、ＲＤＳにより送信されるデータを理解・格納することが可能なように、修正したり、あるいは、特別なアプリケーションを備えたりする必要がある。

この実現は可能であるが、費用がかさむ可能性がある。

このような問題は、複数の国家にまたがって保守システムが実施されており、各国に少なくとも１つの異なるサービス管理システムが提供されている場合に起こる。

更に、各サービス管理システムにおいて、ＲＤＳから受信したデータを処理（例えば、データのデータベースへの格納又はデータに基づく処置）する必要が生じるであろう。これが費用を倍増させることになる。

本発明の目的は、上述の問題のうちの少なくとも一部に対処する電子保守システムを提供することである。

本発明によると、遠隔保守データシステムにおいて、
不定期の保守を必要とする複数の電子装置に関するステータス情報を受信するように構成される中央サーバであって、前記ステータス情報が前記装置から前記中央サーバへと直接に、あるいは、１台以上の中間装置を介して送信される中央サーバと、
前記中央サーバと通信するウェブサーバとを具備し、
前記中央サーバは、前記ステータス情報に基づく情報を含み、ハイパーテキストリンクから構成されるメッセージを特定の電子装置に関連するエンティティへと送信するように更に構成され、
前記ウェブサーバは、少なくとも前記特定の電子装置に関連する前記ステータス情報へのアクセス権を有し、前記リンクが活動化されるのに応じて前記ステータス情報を提供するように構成される遠隔保守データシステムを提供する。

また、本発明によると、不定期の保守を必要とする複数の電子装置のインタフェーシング方法において、
前記装置から中央サーバへと直接に、あるいは、１台以上の中間装置を介してステータス情報を送信し、
前記ステータス情報に基づく情報を含み、ハイパーテキストリンクから構成されるメッセージを特定の電子装置に関連するエンティティへと送信し、
少なくとも前記特定の電子装置に関連する前記ステータス情報へのアクセス権を有し、前記リンクの活動化に応じて前記ステータス情報を提供するウェブサーバを提供する構成のインタフェーシング方法を提供する。

本発明によれば、異なるシステム間でのインタフェーシングの場合、ハイパーテキストリンクを用いたメッセージを提供する方法が簡単である。このメッセージは中央サーバにあるメールサーバにより容易に生成することができる。その送信先であるエンティティは、ハイパーテキストリンクを容易に活動化し、装置の障害の性質を確認する際に必要であろう詳細なステータス情報をアクセスすることができる。この機構により、異なるデータ及び制御システムを用いる異なる保守機構が全て中央サーバに接続される場合に起こり得る問題が減少する。

一例として、添付の図面を参照しながら本発明の実施例を説明する。

図３は、複数のクライアント２６、２８、３０、３２、３４、３６、３８、４０、４２、４４、４６、及び４８と、複数の保守機構(maintenance organisations)５２、５４、及び５６を有する本発明のシステムを示す。各クライアントは中央サーバ５０と通信を行ない、中央サーバは保守機構５２、５４、及び５６の各々と通信を行なう。各クライアントは、少なくとも１つの保守機構と関連付けられており、サーバ５０を介して適切な保守機構と通信を行なう。必要があれば、クライアントは異なる保守機構に異なる種類のイベントデータ又は定期データを送信したり、あるいは、異なる装置に関して異なる保守機構と通信を行なったりすることができるであろう。

図２及び図３を参照する。複数のクライアント２６、２８、３０、３２、３４、３６、３８、４０、４２、４４、４６、及び４８の各々は、図２の装置１２、１４、及び１６などの電子装置を含んでも、クライアントコンピュータ１８及びＲＤＳ２２を含むサーバ２０を含んでも良い。図１のバックエンド２４は、クライアントが関連付けられる保守機構に対応する。中央サーバ５０はクライアントが保守機構と通信する際に媒介する手段である。

図４は、本発明のシステムを使用して装置１２の障害に対処する方法を示す。図４は、図２の例のように電気装置１２、クライアントコンピュータ１８、及びＲＤＳ２２を有するサーバ２０を含むクライアント２６を示す。クライアント２６は、保守機構コールセンタ５８及びディスパッチシステム６０を含む保守機構５２と中央サーバ５０を介して通信を行なう。ディスパッチシステム６０は、エンジニア６２と通信を行なう。エンジニア６２は、クライアントを訪問して障害のある装置１２を修理することができる。

ＲＤＳ２２は、先に概説したように装置１２を監視する。障害が検出されると、ＲＤＳ２２によりサーバ５０を介して関連する保守機構に通知される。障害の種類によっては、先に説明したようにクライアントコンピュータ１８にも通知される。保守機構において、コールセンタ５８は通話のログを残し、ディスパッチシステム６０が必要な処置を取る。この処置は、エンジニア６２を現場に派遣することを必要とするかもしれない。

データは、様々な方法でＲＤＳ２２から中央サーバ５０へと転送されても良い。例えば、インターネットを介したＴＣＰ／ＩＰ又は電子メールであっても、直通の電話接続又は無線接続を使用しても良い。以下の例では、電子メールの使用を想定することとする。

図５は、クライアント２６が中央サーバ５０を介して保守機構５２と通信を行なう際に使用するシステムを詳細に示している。クライアント２６は、図２及び図４に示すように電子装置１２、クライアントコンピュータ１８、及びＲＤＳ２２を有するサーバ２０を含む。中央サーバ５０は、第１のメールサーバ６４、パーサ６６、メッセージコンポーザ６７、第２のメールサーバ６８、データベース７０、ウェブポータル７２、及びＭＱメールサーバ７３を具備する。保守機構５２は、メールサーバ７４、サーバネットワーク７６、ＭＱメールサーバ７７、ブリッジングシステム７９、及びサービス管理システム（ＳＭＳ）９６を具備する。

ＲＤＳ２２が保守機構５２と通信を行なう場合、ＲＤＳ２２は中央サーバ５０の第１のメールサーバ６４に電子メールを送信する。第１のメールサーバ６４が受信した電子メールは、第２のメールサーバ６８（メッセージコンポーザ６７を介する）及びデータベース７０に渡される前にパーサ６６により解析される。第２の電子メールが中央サーバ５０の第２のメールサーバ６８から保守機構５２のメールサーバ７４へと送信される。情報は、メールサーバ７４から保守機構サーバネットワーク７６へと渡されるが、端末７８、８０、８２、及び８４のいずれか１台を介してアクセスすることができる。端末７８、８０、８２、及び８４のうちの１台（図５の例では端末８４）で作業中のユーザは、このサーバ端末で表示される情報をサービス管理システム９６へと転送する。（サービス管理システムは、クライアント、電子装置、部品、消耗品、及びエンジニアの可用性などに関する情報を含むことができる。）サービス管理システムは、保守機構にメッセージを送信する原因となった障害を復旧するための処置（例えば、必要に応じてエンジニアをクライアントの現場に派遣）を実施する。

保守機構側のユーザは、２つの別々のデータシステムへのアクセス権を有することができる。１つは中央サーバ５０により提供されるデータシステムであり、もう１つは保守機構のローカルサービス管理システム９６により提供されるデータシステムである。勿論、ユーザは、別々のプログラムを実行する１台の端末を有することで２つのシステムのデータをアクセスすることもできる。

本例では、ユーザは電子メールクライアントを使用して中央サーバ５０の情報をアクセスし、中央サーバ５０によりメールサーバ７４に送信されたメッセージを読む。ユーザは、障害の情報を入手可能でなければならない。ユーザは、ウェブポータル７２により中央サーバから必要な詳細を全て取得することができる。

このアーキテクチャを使用すると、保守機構の各ユーザが（中央サーバ５０を介して）ＲＤＳ２２の情報へのアクセス権を有しながらも、各保守機構に対するサービス管理システムインタフェースに別々の電子ＲＤＳを提供する問題は回避される。また、提供されるインタフェースは簡易なものであるので、いかなるサービス機構のシステムでも容易に対応することができる。更に、サービス管理システムの特定の機能は、ＲＤＳから得られる全てのデータに適切に対応することができないが、電子装置及びその障害に関するあらゆる情報は中央サーバに収容される。

図５の例示のシステムの動作の更なる詳細は以下の通りである。

上述のように、図５の例では、ＲＤＳ２２が保守機構５２と通信を行なう場合、ＲＤＳ２２から中央サーバ５０の第１のメールサーバ６４へと電子メールが送信される。この電子メールは本文及び添付ファイルから構成される。ＲＤＳからメールサーバ６４に送信される電子メールの本文は、対象のＲＤＳを識別するものであり、送信されるデータに関する汎用的なコード化情報のみを提供する。データ自体は添付ファイルに含まれる。

ＲＤＳ２２とメールサーバ６４との間の通信は、メールサーバ６４からＲＤＳ２２へのアクノリッジ信号の送信を除いては単方向である（アクノリッジが受信されない場合、ＲＤＳは時間をおいてメッセージの再送信を試みる）。

メールサーバ６４は、電子メールの添付ファイルに含まれるデータをパーサ６６に渡す。データは解析され、解析後のデータはデータベース７０に格納される。また、この情報から（メッセージコンポーザ６７によって）新規の電子メールメッセージが作成され、第２のメールサーバ６８へと渡される。第２のメールサーバ６８は、電子メールメッセージを関連する保守機構へと回送する。どの保守機構が関連するかは、データベース中の情報から判定することができる。この情報は、通常、その保守機構に対して責任があることが明確に記録されている当のＲＤＳによるものである。関連する保守機構は、後述するように、ＲＤＳからのメッセージ中の情報（送信先アドレスに含めることが可能）から判定することができる。

受信されたイベントデータは直ちに保守機構へと回送される。

別の実施形態では、イベントデータの一部をデータベースに格納した後、しばらく送信を延期しても良い。イベントデータは、回送する前に他のイベントデータと共に集めることができるであろう。

別の実施形態では、一定の条件が満たされた場合のみ、保守機構はイベントデータの通知を受ける。この条件は、データベースに格納されるパラメータとして定義することができる。例えば、消耗品（トナーなど）が交換されたことを示す「消耗品の交換（consumables replacement）」イベントは、直ちに中央サーバ５０に転送される。ユーザが消耗品のストックを有する場合、保守機構はそのストックが限界レベルに到達したときのみメッセージを受信することを望むであろう。従って、中央サーバ５０は、同じＲＤＳに関連する全ての「消耗品交換」イベントをデータベース中に格納し、一定数の「消耗品交換」イベントを受信し次第、関連する保守機構にメッセージを送信する。この好適な例では、中央サーバが同じＲＤＳから幾つの「消耗品交換」イベントを受信した後に関連する機構に通知すべきであるかを指定する閾値として条件をデータベース中に定義することができる。

本実施形態では、保守機構が即時処理を必要としないメッセージで混み合うことはない。中央サーバは、即時処理が必要なときのみ保守機構が通知を受けられるようにする。

受信された定期データは、保守機構の選択によって直ちに転送されたり、あるいは、予定に沿って転送されたりする。

中央サーバはＲＤＳからの電子メールをチェックする。これらのメールはセキュリティ上の理由から暗号化される。メールのチェックは、ＲＤＳのＩＤ番号が正しいことと、メールが参照する電子装置のＩＤが正しいこととを確認するために行なう。サーバは、予定された通りＲＤＳからデータを受信中であるかを確認する。そうでない場合、関連する保守機構及び中央サーバの管理者に通知する。

保守機構に送信されるメッセージは、ＲＤＳからの元のメッセージよりも多くの情報を含むのが好ましい。この補足情報は、中央サーバがデータベースを参照して追加されるものである。このようなメッセージの一例を図６に示す。補足情報は、元の情報において符号化されていた情報を自然言語化したもの（例えば、障害コードの説明）であっても、何らかの追加の関連情報（例えば、ＲＤＳが特定の装置の障害を報告すると、中央サーバのデータベースが特定のクライアントの現場にその装置があることを記録しているので、クライアントの氏名が保守機構に送信されるメッセージに追加される）であっても良い。

保守機構へのメッセージは特定の保守機構に合わせて変更されても良い。例えば、英語又はポルトガル語などの適切な言語で提示されても良い。

図６から明らかなように、保守機構に送信されるメッセージは、データをほとんど含まない通知であることが好ましい。保守機構のユーザは、メッセージ中のハイパーテキストリンクにアクセスすることによって、報告される障害に関連するより詳細な情報をアクセスする。このリンクを付勢（activating）することにより、中央サーバ５０のウェブポータル７２のより詳細な情報を読み出す。ウェブページは、保守機構へのメッセージと同時に編纂されるが、実行中に作成することもできる。障害に関する基本的なデータは、上述のように、元のメッセージがＲＤＳから受信されたときにパーサ６６によりデータベースへと格納されている。ウェブポータルはその情報のみならず補足情報も提供する。この補足情報は、例えば、クライアントの氏名及び住所、特定の装置の詳細（ここでは、部品数、特定の機器に関する障害のログ、又は障害があると思われる部品の部品番号及び明細）、必要な消耗品などを含んでも良い。

この好適な例では、中央サーバのウェブポータルは、保守機構に送信される障害メッセージに対して簡易なステータス記録システムを提供する。メッセージ（図６）中のリンクをクリックするか、あるいは、ウェブポータルにより提供されるページ中の後続のリンクをたどることによって、保守機構のユーザは、受信したメッセージの処理ステータスを記録可能なページに到達することができる。ユーザが処理ステータスとして記録可能な値は、「未処理」、「処理中」、「処理済（派遣有）」、又は「処理済（派遣無）」であることが好ましい。別のページにおいて、ウェブポータルは特定の保守機構に送信されたメッセージ及びそのステータスのリスト（ステータスによりフィルタリングされたリスト又は完全なリスト）を提供する。これにより、保守機構のユーザ又はその管理者は、どの作業が未処理であるかを見たり、全ての送信メッセージが受信されていることを確認したりすることができる。また、保守機構が現場で障害の報告を受けていることを確認できるように、ウェブポータルは、必要に応じて障害及びその処理ステータスのページをクライアントに提供することができる。

また、ウェブポータルにより、装置レポート（警報の出ている装置に関する）をアクセスすることができる（図６の電子メール中のリンクで開始することによって、あるいは、それ以外の方法で）。このレポートは、どの装置であるか、どんな部品を装着しているか、警報の履歴、及び実施された保守の履歴を含む装置についての関連する詳細を含む。更に、ウェブポータルにより、現場の他の装置（すなわち、通常、同じＲＤＳを有する装置）に関する「事前保守（pre-maintenance）」レポートをアクセスすることができる。このレポートでは、装置の過去の障害を列挙したり、あるいは、時宜に適っていると思われる他の保守又は部品交換を提案したりする。

中央サーバにより提供される補足データ（保守機構に送信されるメッセージ及びウェブポータルを介するメッセージの双方における）は、中央サーバに提供されなければならない。データは、例えば、保守機構のユーザ又は現場のインストレーションエンジニアによりウェブポータルへとキー入力される。この入力は、例えば、新規のクライアント又は装置を追加するとき、あるいは、保守機構がイベントデータ又は定期メッセージの通知をいつ受けるべきかを示す条件を設定又は変更するときに行なわれる可能性がある。現場で詳細（例えば、新規の装置の詳細）を入力するオペレータにとっての別の選択肢は、ＲＤＳのユーザインタフェースに対してデータを入力し、ＲＤＳが特別な電子メールを中央サーバに送信し、中央サーバがその情報をデータベースに記録することである。

既存のデータは、サービス管理システムからエクスポートし、中央サーバへとインポートすることもできる。このようなエクスポートデータのファイルは、ＭＱメールサーバ７７又はＸＭＬ、ＳＯＡＰ、電子メールなどのデータ形式プロトコルを使用する他のインタフェーシング技術によりウェブポータルへとアップロードすることができる。ブリッジングシステム７９はデータ変換を提供する。別の方法としては、このブリッジングシステムがデータをＸＭＬ形式へと変換し、ウェブポータルへとアップロードしても良い。

障害（イベント）を保守機構に通知するための上述の機構は、ユーザに電子メールを送信し（標準ＳＭＴＰ電子メールを使用）、ユーザの注意を喚起し、ウェブポータル上のより詳細な情報へのアクセス権をユーザに与える。別の機構では、ＭＱメールサーバ７３及び７７（又は他の同等の技術）を使用して保守機構のブリッジングシステム７９にデータを送信し（ＭＱ電子メール又はＸＭＬ、単層ファイル電子メールなどの他の形式）、ブリッジングシステム７９が、データを変換してサービス管理システムへとインポートする。好適な実施形態では、これらの２つの機構の組み合わせが使用される。障害（イベント）発生時には、保守機構のユーザに障害を通知する電子メールが送信されるが、定期的な送信もＭＱメールにより行なうことが可能であり、情報は保守機構のサービス管理システムに自動的にインポートされる。

このようなエクスポート／インポートの詳細は、特定のサービス管理システムに特有である可能性もあるが、通常、ＲＤＳをＳＭＳに直接インタフェーシングする（本発明ではこの方法を取らない）よりも簡単なタスクである。このエクスポート／インポートは単なるデータ変換演習でしかなく、ＲＤＳにより送信される種々の形式のメッセージに動的に応答する必要がないからである。中央サーバは、保守機構のシステムとインタフェースを取り、中央サーバと保守機構との間のインタフェースに基づいて必要なデータを送信する機能を持つことができる。

メールサーバ６４は様々な電子メールアドレスを有し、ＲＤＳはこれらのアドレスに警報及び定期レポートを送信する。定期レポートメッセージは処理待ちの警報がないときに処理される。これにより、警報及び定期送信（すなわち、保守機構への即時の電子メール送信及びＭＱメール又はＸＭＬなどの他の形式による定期送信）により異なる処理が容易に実行されるようになる。また、この処理を使用することで、サーバは容易に警報メッセージを最優先にすることもできる。定期メッセージは、中央サーバのデータベースにも格納される。

サーバ６４は、保守機構ごとに異なる電子メールボックスを提供するのが好ましく、ＲＤＳは警報及び定期メッセージをクライアントが所属する保守機構の関連するボックス宛に送信するようにプログラムされる。保守機構と警報及び定期メッセージとの間の区別は、電子メールアドレスにより行なわれる必要はなく、電子メール又は添付ファイル中の情報により行なうことも、あるいは、データベースから取り出すこともできる。

更なるオプションとして、異なる種類の警報に対して異なるアドレスを持つこともできるであろう。

中央サーバは、ウェブポータルへとキー入力され、保守機構のサービス管理システムから転送されたＲＤＳからのメッセージにより、大規模なデータベースを構築する。このデータベースの使用法の１つは、特定の電子装置の障害履歴、装置種別、現場、クライアント、保守機構などに関して分析・報告することである。このようなレポートはウェブポータルを介してアクセスされる。

複数の装置１２、１４、及び１６を監視し、これらの装置に関する情報を収集して中央サーバ５０へと転送する遠隔故障診断ソフトウェア２２に関して説明してきた。各電子装置が自身に関する情報を直接中央サーバへと送信できるようにシステムを構成しても良いが、ＲＤＳ２２の提供は、中央サーバへの転送前に情報を便利に一括化できることを意味する。

このシステムの更なる利点は、各保守機構が自身の装置だけでなく、中央サーバのデータベースに保持されている全ての装置のあらゆるデータへのアクセス権を有することができる（少なくともその可能性がある）ことである。これにより、クライアントのサービス機構間の移動が容易になり、大規模な装置群における傾向を識別できるようになる。

サービスコールを処理する構成を示す図である。 既知の保守システムを示す図である。 中央サーバを有する保守システムを示す図である。 障害の処置方法を示す図である。 保守システムの更なる詳細を示す図である。 ユーザに送信される電子メールメッセージの一例を示す図である。

Claims (68)

1. 遠隔保守データシステムであって、
   不定期の保守を必要とする複数の電子装置に関するステータス情報を受信するように構成される中央サーバと、
   ここで、前記ステータス情報は前記電子装置から前記中央サーバへと直接に、あるいは、１台以上の中間装置を介して送信される；、
   前記中央サーバと通信するウェブサーバとを具備し、
   前記中央サーバは、前記ステータス情報に基づく情報を含み、ハイパーテキストリンクを有するメッセージを特定の電子装置に関連するエンティティへ送信するように構成され、
   前記ウェブサーバは、少なくとも前記特定の電子装置に関連する前記ステータス情報へのアクセス権を有し、前記リンクのアクティブになるのに応じて前記ステータス情報を提供するように構成される
   ことを特徴とする遠隔保守データシステム。
2. 前記中央サーバ又はウェブサーバは、前記受信されたステータス情報を分析する手段を具備することを特徴とする請求項１に記載の遠隔保守データシステム。
3. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージを関連するエンティティに送信するか否かを判定することを特徴とする請求項２に記載の遠隔保守データシステム。
4. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージを関連するエンティティにいつ送信するかを判定することを特徴とする請求項２に記載の遠隔保守データシステム。
5. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージをどの関連するエンティティに送信するかをを判定することを特徴とする請求項２に記載の遠隔保守データシステム。
6. 前記分析手段は、条件データに従い、前記メッセージを関連するエンティティに送信するか否かを判定することを特徴とする請求項２に記載の遠隔保守データシステム。
7. 前記中央サーバ又はウェブサーバは、データを格納するデータベースへのアクセス権を有し、前記サーバにより受信されるステータス情報は、前記データベースに格納されることを特徴とする請求項１乃至６のいずれか１項に記載の遠隔保守データシステム。
8. 前記分析手段は、前記データベースに格納されるデータへのアクセス権を有することを特徴とする請求項２乃至６のいずれか１項に従属した請求項７記載の遠隔保守データシステム。
9. 前記分析手段は前記メッセージを生成する請求項２から６のいずれか１項、又は、請求項２から６のいずれか１項に従属する場合の請求項７又は８のいずれか１項に記載の遠隔保守データシステム。
10. 前記中央サーバに送信されるステータス情報は、前記電子装置のうちの少なくとも１台の保守の必要性を示す第１の種類のステータス情報、及び、前記電子装置のうちの少なくとも１台の使用に関する第２の種類の情報を含むことを特徴とする請求項１乃至９のいずれか１項に記載の遠隔保守データシステム。
11. 前記中央サーバに送信されるステータス情報は、前記電子装置を識別のための情報を含むことを特徴とする請求項請求項１乃至１０のいずれか１項に記載の遠隔保守データシステム。
12. 前記メッセージは、前記特定の電子装置に関する前記ステータス情報の少なくとも一部を含むことを特徴とする請求項請求項１乃至１１のいずれか１項に記載の遠隔保守データシステム。
13. 前記中央サーバにより前記メッセージ中で前記エンティティに対して提供される前記ステータス情報には、前記中央サーバ又はウェブサーバにアクセス可能なデータベースからの追加の関連するデータにより補足されることを特徴とする請求項１２に記載の遠隔保守データシステム。
14. 前記エンティティは、少なくとも１つのサービス管理コンピュータシステムへのアクセス権を有し、前記サービス管理コンピュータは前記メッセージを送信したのがどのエンティティであるかについての少なくとも幾つかのデバイスについてのデータを有することを特徴とする請求項１乃至１３のいずれか１項に記載の遠隔保守データシステム。
15. 前記ウェブサーバにより供給される前記ステータス情報の少なくとも一部は、前記中央サーバ又はウェブサーバにアクセス可能なデータベースからの追加の関連するデータにより補足されることを特徴とする請求項１乃至１４のいずれか１項に記載の遠隔保守データシステム。
16. 前記中央サーバ又はウェブサーバによりエンティティに提供されるデータ又は前記データの形態は、前記エンティティによって依存することを特徴とする請求項１乃至１５のいずれか１項に記載の遠隔保守データシステム。
17. 前記中央サーバ又はウェブサーバは、或るサービス管理コンピュータシステム又は前記サービス管理コンピュータシステムからデータを受信するように構成されることを特徴とする請求項１乃至１６のいずれか１項に記載の遠隔保守データシステム。
18. 前記サービス管理コンピュータシステムから受信される前記データは、前記サービス管理コンピュータシステムによりサービスを受ける前記装置に関するデータを含むことを特徴とする請求項１７記載の遠隔保守データシステム。
19. 前記中央サーバ又はウェブサーバは、或るサービス管理コンピュータシステム又は前記サービス管理コンピュータシステムへデータを送信するように構成されることを特徴とする請求項１乃至１８のいずれか１項に記載の遠隔保守データシステム。
20. 転送される前記データは、電子装置の使用に関するデータを含むことを特徴とする請求項１９記載の遠隔保守データシステム。
21. 前記電子装置の使用に関するデータは、少なくとも１つのサービス管理コンピュータシステムにオペレータの介入なしに直接転送されることを特徴とする請求項２０に記載の遠隔保守データシステム。
22. 前記電子装置の使用に関する前記データは、前記サービス管理コンピュータシステムにバッチにより送信されることを特徴とする請求項２０又は２１記載の遠隔保守データシステム。
23. 前記電子装置の使用に関する前記データは、閾値条件が満たされ次第、前記サービス管理コンピュータシステムに送信されることを特徴とする請求項２２記載の遠隔保守データシステム。
24. 前記中央サーバは、異なる電子装置又は複数組の装置からステータス情報を受信するための異なるメールボックスを有するメールサーバを具備することを特徴とする請求項１乃至２３のいずれか１項に記載の遠隔保守データシステム。
25. 前記中央サーバは、装置が対処を要することを示す電子装置ステータス情報を受信ため、及び、前記装置の使用に関するステータス情報を受信するための異なるメールボックスを有するメールサーバを具備することを特徴とする請求項１乃至２４のいずれか１項に記載の遠隔保守データシステム。
26. １組の装置に対するステータス情報は、前記中央サーバへ、共通のユニットにより中継されることを特徴とする請求項１乃至２５のいずれか１項に記載の遠隔保守データシステム。
27. 前記中央サーバ又はウェブサーバは、どの電子装置が前記共通のユニットにステータス情報を提供するかについてのレポートを提供するように構成されることを特徴とする請求項２６記載の遠隔保守データシステム。
28. 前記中央サーバ又はウェブサーバは、前記共通のユニットにステータス情報を提供する複数の前記電子装置に関するステータス情報についての単一のレポートを提供するように構成されることを特徴とする請求項２６又は２７記載の遠隔保守データシステム。
29. 前記中央サーバ又はウェブサーバは、特定の電子装置に関する情報の履歴を提供するように構成されることを特徴とする請求項１乃至２８のいずれか１項に記載の遠隔保守データシステム。
30. 前記中央サーバ又はウェブサーバは、複数の電子装置における障害又は使用の分析を提供するように構成されることを特徴とする請求項１乃至２９のいずれか１項に記載の遠隔保守データシステム。
31. ステータス情報の送信は、前記装置又は中間装置により開始されることを特徴とする請求項１乃至３０のいずれか１項に記載の遠隔保守データシステム。
32. 前記エンティティは、関連していない１台以上の電子装置に関するステータス情報へのアクセス権を与えられることを特徴とする請求項１乃至３１のいずれか１項に記載の遠隔保守データシステム。
33. 前記システムは、
    前記複数の電子装置と、
    複数の異なるサービス管理コンピュータシステムとを更に具備し、
    前記中央サーバは前記メッセージを前記サービス管理コンピュータシステムのユーザに送信するように構成されることを特徴とする請求項１乃至３２のいずれか１項に記載の遠隔保守データシステム。
34. 不定期の保守を必要とする複数の電子装置のインタフェーシング方法であって、
    前記装置から中央サーバへと直接に、あるいは、１台以上の中間装置を介してステータス情報を送信し、
    前記ステータス情報に基づく情報を含み、ハイパーテキストリンクから構成されるメッセージを特定の電子装置に関連するエンティティへ送信し、
    少なくとも前記特定の電子装置に関連する前記ステータス情報へのアクセス権を有し、前記リンクがアクティブになるのに応じて前記ステータス情報を提供するウェブサーバを提供する
    ことを特徴とするインタフェーシング方法。
35. 前記中央サーバ又はウェブサーバは、前記受信されたステータス情報を分析する手段を具備することを特徴とする請求項３４記載のインタフェーシング方法。
36. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージを関連するエンティティに送信するか否かを判定することを特徴とする請求項３５記載のインタフェーシング方法。
37. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージを関連するエンティティにいつ送信するかを判定することを特徴とする請求項３５記載のインタフェーシング方法。
38. 前記分析手段は、前記受信されたステータス情報に基づいて、前記メッセージをどの関連するエンティティに送信するかを判定することを特徴とする請求項３５記載のインタフェーシング方法。
39. 前記分析手段は、条件データに従って、前記メッセージを関連するエンティティに送信するか否かを判定することを特徴とする請求項３５記載のインタフェーシング方法。
40. 前記中央サーバ又はウェブサーバは、データを格納するためのデータベースへのアクセス権を有し、前記サーバにより受信されるステータス情報は、前記データベースに格納されることを特徴とする請求項３４乃至３９のいずれか１項に記載のインタフェーシング方法。
41. 前記分析手段は、前記データベースに格納されるデータへのアクセス権を有することを特徴とする、請求項３５から３９のいずれか１項に従属する場合の請求項４０に記載のインタフェーシング方法。
42. 前記分析手段は、前記メッセージを生成することを特徴とする、請求項３５乃至３９のいずれか１項、又は、請求項３５乃至３９のいずれか１項に従属する場合の請求項４０又は４１のいずれか１項に記載のインタフェーシング方法。
43. 前記中央サーバに送信されるステータス情報は、前記電子装置のうちの少なくとも１台の保守の必要性を示す第１の種類のステータス情報及び前記電子装置のうちの少なくとも１台の使用に関する第２の種類の情報を含むことを特徴とする請求項３４乃至４２のいずれか１項に記載のインタフェーシング方法。
44. 前記中央サーバに送信されるステータス情報は、前記電子装置の識別のための情報を含むことを特徴とする請求項３４乃至４３のいずれか１項に記載のインタフェーシング方法。
45. 前記メッセージは、前記特定の電子装置に関する前記ステータス情報の少なくとも一部を含むことを特徴とする請求項３４乃至４４のいずれか１項に記載のインタフェーシング方法。
46. 前記ウェブサーバにより提供される前記ステータス情報は、前記中央サーバ又はウェブサーバにアクセス可能なデータベースからの追加の関連するデータにより補足されることを特徴とする請求項４５に記載のインタフェーシング方法。
47. 前記中央サーバ又はウェブサーバによりエンティティに提供されるデータ又は前記データの形態は、前記エンティティに依存するよって決まる請求項３４から４６のいずれか１項に記載のインタフェーシング方法。
48. 前記エンティティから前記中央サーバにデータを送信する工程を含むことを特徴とする請求項３４乃至４７のいずれか１項に記載のインタフェーシング方法。
49. 送信される前記データは、前記エンティティによりサービスを受ける前記装置に関するデータを含むことを特徴とする請求項４８記載のインタフェーシング方法。
50. 前記中央サーバから前記エンティティにデータを送信する工程を含むことを特徴とする請求項３４乃至４９のいずれか１項に記載のインタフェーシング方法。
51. 転送される前記データは電子装置の使用に関するデータを含むことを特徴とする請求項５０記載のインタフェーシング方法。
52. 前記エンティティは、少なくとも１つのサービス管理コンピュータシステムへのアクセス権を有し、前記サービス管理コンピュータは、前記メッセージを送信したのがどのエンティティであるのかについての少なくとも幾つかのデバイスについてのデータを有することを特徴とする請求項３４乃至５１のいずれか１項に記載のインタフェーシング方法。
53. 前記中央サーバは、或るサービス管理コンピュータシステム又は前記サービス管理コンピュータシステムからデータを受信するように構成されることを特徴とする請求項３４乃至５２のいずれか１項に記載のインタフェーシング方法。
54. 前記サービス管理コンピュータシステムから受信される前記データには、前記サービス管理コンピュータシステムによりサービスを受ける前記装置に関するデータが含まれることを特徴とする請求項５３記載のインタフェーシング方法。
55. 前記中央サーバ又はウェブサーバは、或るサービス管理コンピュータシステム又は前記サービス管理コンピュータシステムへデータを送信するように構成されることを特徴とする請求項３４乃至５４のいずれか１項に記載のインタフェーシング方法。
56. 前記転送される前記データは電子装置の使用に関するデータを含むことを特徴とする請求項５５記載のインタフェーシング方法。
57. 前記電子装置の使用に関するデータは、少なくとも１つのサービス管理コンピュータシステムにオペレータの介入なしに直接転送されることを特徴とする請求項５６記載のインタフェーシング方法。
58. 前記電子装置の使用に関する前記データは、前記サービス管理コンピュータシステムのバッチにより送信されることを特徴とする請求項５６又は５７記載のインタフェーシング方法。
59. 前記電子装置の使用に関する前記データは、閾値条件が満たされ次第、前記サービス管理コンピュータシステムに送信されることを特徴とする請求項５８記載のインタフェーシング方法。
60. 前記装置から前記中央サーバへの前記ステータス情報の送信は、異なる電子装置又は複数組の装置からのステータス情報に対して異なるアドレスを指定する電子メールにより行なわれることを特徴とする請求項３４乃至５９のいずれか１項に記載のインタフェーシング方法。
61. 前記装置から前記中央サーバへの前記ステータス情報の送信は、前記装置が対処を要することの表示及び前記装置の使用に関する情報に対して異なるアドレスを指定する電子メールにより行なわれることを特徴とする請求項３４乃至６０のいずれか１項に記載のインタフェーシング方法。
62. １組の装置に対するステータス情報は、前記中央サーバへ、共通のユニットにより中継されることを特徴とする請求項３４乃至６１のいずれか１項に記載のインタフェーシング方法。
63. どの電子装置が前記共通のユニットにステータス情報を提供するかについてのレポートを提供する中央サーバ又はウェブサーバを有することを特徴とする請求項６２記載のインタフェーシング方法。
64. 前記共通のユニットにステータス情報を提供する複数の前記電子装置に関するステータス情報についての単一のレポートを提供する中央サーバ又はウェブサーバを有することを特徴とする請求項６２又は６３記載のインタフェーシング方法。
65. 特定の電子装置に関する情報の履歴を提供する中央サーバ又はウェブサーバを有することを特徴とする請求項３４乃至６４のいずれか１項に記載のインタフェーシング方法。
66. 複数の電子装置における障害又は使用の分析を提供する中央サーバ又はウェブサーバを有することを特徴とする請求項３４乃至６５のいずれか１項に記載のインタフェーシング方法。
67. ステータス情報の送信は、前記装置又は中間装置により開始されることを特徴とする請求項３４乃至６６のいずれか１項に記載のインタフェーシング方法。
68. 前記エンティティには、関連していない１台以上の電子装置に関するステータス情報へのアクセス権が与えられることを特徴とする請求項３４乃至６７のいずれか１項に記載のインタフェーシング方法。

Images