JP2017054288A - 遠隔保守サービスシステム - Google Patents

Abstract

【課題】携帯端末の障害を検知した場合に、保守形態をオンサイト保守とするかまたは持ち込み保守とするかを決定する遠隔保守サービスシステムを提供する。【解決手段】遠隔保守サービスシステムとして、携帯端末と、携帯端末の保守に係る情報を格納したデータベースを備える遠隔保守センタ２と、携帯端末１と前記遠隔保守センタとの通信を行う通信環境とを備える。携帯端末は、稼働中の間、定期的に自らの状態情報および位置情報を遠隔保守センタに送信し、遠隔保守センタは、受信した状態情報から携帯端末の障害の有無を判断し、障害を検知した場合に、受信した位置情報およびデータベースに基づいて障害から復旧させるための保守形態をオンサイト保守とするかまたは持ち込み保守とするかを決定する。【選択図】図２

Description

本発明は、顧客が所持する携帯端末に対する遠隔保守サービスシステムに関する。

従来、顧客のコンピュータ関連端末機器に対する保守やヘルプデスク等の業務サービスに係わる保守サービスシステムの代表的な形態として、以下の流れに沿ったシステムが挙げられる。顧客のコンピュータ関連端末機器の状態を監視し、障害やエラー等の状態を検知した時に、必要な復旧対策等の保守作業の内容を判定する。保守作業の内容が決まれば、保守作業を行う保守員を選定し、この保守員に対して保守作業に係る指示を通知する。通知を受けた保守員はその指示に従って保守作業を行う。

その一例として、先行技術文献に掲げた特許文献１には、以下の保守対応システムが示されている。
顧客の機器を対象とした保守対応の業務に係わる情報処理を行う保守対応システムであって、複数の拠点の複数の保守員の中から顧客の機器の保守対応を行う担当者を決定する機能を持つ情報処理装置を有し、情報処理装置は、診断部と、管理情報を格納するＤＢとを有し、情報処理装置は外部から前記保守対応の要求の情報を入力し、診断部は管理情報または入力情報をもとに対象の顧客の機器の状態、必要な保守対応の内容及び条件を診断または確認する第１の処理と、管理情報または入力情報をもとに複数の拠点と複数の保守員の最新の状態を診断または確認する第２の処理と、第１、第２の処理をもとに、対象の顧客の機器の保守対応のために、前記複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する第３の処理と、を行い、第３の処理において、第１条件として、前記必要な保守対応の条件として対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第１候補として選択し、第２条件として、第１候補から対象の顧客の機器との距離がなるべく近い拠点の保守員を第２候補として選択し、第３条件として、第２候補から複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第３候補として選択することを特徴とする。

顧客が使用するコンピュータ関連端末機器については、従前、設置型の端末機器が大半であったところ、近年のコンピュータ関連端末機器の小型化・高性能化が進み、端末機器のニーズとして高い機動性を併せ持つことが求められるようになった。それにより、タブレットタイプの情報機器やスマートフォン等を代表とする携帯型の端末機器（以下、「携帯端末」と総称する）への移行が進み、それらが急速に普及している状況にある。保守対象機器が携帯端末であると、特定の場所に設置し固定化して使用される形態ではなく、国内、場合によっては国外も含めて、地域を移動する、いわゆる移動端末として使用されることになる。そうなると、保守サービスシステムもそれに適合したものとする必要がある。

大規模システムに接続された複数の携帯端末に対する運用管理システムとして、先行技術文献に掲げた特許文献２には、以下のシステムが示されている。
ＧＰＳ機能と自己診断機能とを有し、電源投入時に携帯端末のＧＰＳ機能により現在位置している所在地を抽出し、電源投入時に内蔵する自己診断機能により自己診断プログラムによる自己診断を開始し、前記所在地と診断結果をインターネットを介してセンターサーバへ送付する機能を有する複数の携帯端末と、センターサーバおよび保守センターを、インターネットを介し接続し、センターサーバは、資産データベースを備え、携帯端末から送付された携帯端末の資産管理番号と診断結果を資産データベースに記録することにより携帯端末の資産管理を行い、保守センターは、コンピュータの修理をする保守するセンターであり、携帯端末が障害時にはセンターサーバからインターネットを介して修理が要請されることを特徴とする運用管理システム。

特開２０１３−６９２３９号公報 特許第３８８０４５３号公報

保守対象となる顧客の機器が携帯端末である場合に、保守拠点（保守センタなど）が固定化されていると保守サービスの利便性および即応性に欠ける。例えば、携帯端末に障害が発生した場合に、顧客はどこへそれを持ち込めばよいのかまたは保守員が来てくれるのか判断がつかないケースや、どこの保守拠点が実際の保守サービスに当たるのか決定が遅れるケースなど、故障等による障害が長期化する恐れがあり顧客の業務等に支障をきたすことになる。

上記特許文献２に示される運用管理システムは、センターサーバが各携帯端末の所在地と自己診断結果を保有管理して、携帯端末機の障害発生時には保守センターの方へ修理依頼を要請するまでを運用管理するものである。センターサーバは、所定期間毎に各携帯端末からの連絡の有無を判定し、障害を通知した携帯端末に対してセンターサーバから保守センターの方へ修理依頼を要請する。しかし、この運用管理システムでは、携帯端末が自己診断機能を搭載する必要があり、障害の内容によってはこの自己診断機能が及ばない場合（例えば、送信系の障害など）が想定される。また、修理依頼を受けた保守センターにおける具体的な修理の対処方法についての言及がなく、迅速で柔軟な対処が行えるか不明である。

本発明の目的は、携帯端末からの状態情報および位置情報を受信した遠隔保守センタが、携帯端末の障害を検知すると共に、速やかに障害回復のための保守形態を決定し、迅速かつ柔軟に携帯端末の障害回復のための対処を図ることを可能にした遠隔保守サービスシステムを提供することにある。

本発明に係る遠隔保守サービスシステムは、携帯端末と、携帯端末の保守に係る情報を格納したデータベースを備える遠隔保守センタと、携帯端末と前記遠隔保守センタとの通信を行う通信環境とを備え、携帯端末は、稼働中の間、定期的に自らの状態情報および位置情報を遠隔保守センタに送信し、遠隔保守センタは、受信した状態情報から携帯端末の障害の有無を判断し、障害を検知した場合に、受信した位置情報およびデータベースに基づいて障害から復旧させるための保守形態をオンサイト保守とするかまたは持ち込み保守とするかを決定することを特徴とする。

本発明によれば、遠隔保守センタは、使用場所を固定せず移動して使用することが大半となる携帯端末の障害をいち早く検知し、速やかに障害回復のための保守形態を決定することが可能となる。これにより、迅速かつ柔軟に携帯端末の障害回復に対処できる保守サービスを提供する。

図１は、携帯端末と遠隔保守センタとの間の情報のやり取りの概要を示す図である。 図２は、携帯端末の障害発生から保守終了までの処理フローの概要を示す図である。 図３は、実施例１に係り、携帯端末および遠隔保守センタにおける処理フローの詳細を示す図である。 図４は、保守業務ＤＢを構成するデータベースの一例を示す図である。 図５は、実施例２に係り、携帯端末および遠隔保守センタにおける処理フローの詳細を示す図である。

以下、本発明の実施形態として、先ず全体像を説明した後に、実施例１および２について順に説明する。
図１は、保守対象となる顧客の携帯端末と保守業務に当たる遠隔保守センタとの間の情報のやり取りの概要を示す図である。

保守対象となる携帯端末１は、その稼働中において、遠隔保守センタ２へ定期的に機器の状態情報および位置情報を送信する。遠隔保守センタ２は、保守対象となる種々の携帯端末１からの送信情報を受信し、それら受信情報に応じて携帯端末１の状態を把握して障害の有無を検知する。そして、遠隔保守センタ２は、携帯端末１の障害を検知するとその障害から修復（復旧）するための対処方法等を決定し顧客に対して返信する。そのための詳細な処理については後述する。

遠隔保守センタ２は、少なくとも、障害対応を含む保守業務全般を処理する処理装置２１および保守業務のための各種情報（データ）を格納した保守業務データベース（以下、「保守業務ＤＢ」という）２４を備えている。この保守業務ＤＢ２４には、保守対象となる顧客の携帯端末等の保守に係る情報（データ）が格納されている。
また、保守対象となる種々の携帯端末１と遠隔保守センタ２との間の情報通信は、インターネットまたは通信回線などを介して行われる。

次に、保守対象となる携帯端末１の障害発生から、遠隔保守センタ２による保守終了までの保守の流れについて説明する。図２は、携帯端末１の障害発生から保守終了までの処理フローの概要を示す図である。

顧客が所有（保有）する携帯端末１は、自らの状態情報（機器の状態情報）を定期的に採取する。携帯端末１に障害が発生すると、機器の状態情報はその障害を反映したものになる。また併せて、携帯端末１の位置（場所）を遠隔保守センタ２が把握する必要があるため、携帯端末１は内蔵するＧＰＳ機能により自端末の位置情報を採取する。携帯端末１は、採取した機器の状態情報および位置情報を遠隔保守センタ２に送信する。ここで、機器の状態情報および位置情報の採取にあたるソフトウェア（プログラム）は、携帯端末１が内蔵するメモリに格納されている。

遠隔保守センタ２は、保守対象の携帯端末１から送信された、機器の状態情報および位置情報を受信する。その受信情報に基づいて、以下に示す処理を実行する。
機器の状態情報からその携帯端末１の機器状態を分析して障害の有無を判断する。続いて、位置情報から携帯端末１が所在する位置を確認する（以後、障害が発生した携帯端末のことを「障害端末」ということがある）。次に、障害状況（内容）および位置情報から、保守サービスを提供できる保守拠点を検索する。この保守拠点の検索では、障害内容に対する修復（復旧）を含めた保守サービスの提供が可能で、かつ障害端末に最も近い場所に存在する保守拠点が選択される。

次に、遠隔保守センタ２は、検索した保守拠点において、障害端末１に対してオンサイト保守（出張修理）で対応するか持ち込み保守（持ち込み修理）で対応するかを判断する。この判断は、障害端末１の障害内容のレベル（障害程度）および検索により選択された保守拠点が提供可能な保守サービス（保守内容）のレベルに基づいて行われる。

上記判断の結果、オンサイト保守（出張修理）で対応する場合には、遠隔保守センタ２から障害端末１の所在地（現地）へ保守員を派遣させる指示が出され、保守員が障害端末１の所在地に向かい現地で修理作業等に当たる。
一方、持ち込み保守（持ち込み修理）で対応する場合には、遠隔保守センタ２から、障害端末１を持ち込む保守拠点に関する情報（保守拠点が所在する場所、保守拠点の営業日時など）が障害端末１を所有（保有）する顧客に連絡される。連絡手法としては、障害端末へ直接送信するか、障害端末が電源オフ状態にあることを想定して別途所有者（顧客）宛てに電話連絡するかメール送信により連絡を行う。

障害端末１側においては、オンサイト保守（出張修理）の場合、派遣された保守員により適切な修理（修復）が行われ、他方、持ち込み保守（持ち込み修理）の場合、持ち込まれた保守拠点において適切な修理（修復）が行われ、これらにより保守が終了することになる。

実施例１は、図２に示した処理フローを具体化したもので、携帯端末からの情報発信の態様、それを受ける遠隔保守センタが携帯端末の障害を検知しその対処（復旧）を実行する処理の態様を示すものである。

図３は、実施例１に係り、携帯端末１および遠隔保守センタ２における処理フローの詳細を示す図である。
携帯端末１における状態情報発信フローについて説明する。携帯端末１は、少なくとも処理部１１、メモリ１２および通信部１３を内蔵し、それらを用いてこの状態情報発信フローの処理が実行される。この状態情報発信フローには、処理部１１が、例えばメモリ１２に格納されている状態情報取得プログラムを実行する処理、ＧＰＳ機能を使用して位置情報を取得する処理および通信部１３を介して情報を発信する処理が含まれる。

ステップＳ１５で、処理部１１は、状態情報取得プログラムを実行して携帯端末１の状態情報を取得する。併せて、処理部１１は、携帯端末１が内蔵するＧＰＳ機能を使って携帯端末１の位置情報を取得する。そして、処理部１１は、取得した状態情報および位置情報を遠隔保守センタ２へ通信部１３を介して送信する。ここで、状態情報としては、携帯端末１のシャットダウン（電源オフ）情報も含まれる。また、後述するが、状態情報および位置情報の送信に当たっては、携帯端末１を識別するための機器識別情報も併せて送信する。
ステップＳ１６で、処理部１１は、タイマ機能を働かせる。このタイマ機能により、一定時間毎（例えば、１分毎）に状態情報取得プログラムおよびＧＰＳ機能の実行およびその結果の送信が処理されることになる。

次に、遠隔保守センタ２が実行する遠隔保守管理フローについて説明する。遠隔保守センタ２は、少なくとも処理装置２１、記憶装置２２、通信装置２３および保守業務ＤＢ２４を備え、それらを用いてこの遠隔保守管理フローの処理が実行される。この遠隔保守管理フローは、記憶装置２２に格納されている遠隔保守管理プログラムを処理装置２１が実行することにより処理される。

ステップＳ２５で、通信装置２３は、携帯端末１から送信されたその状態情報および位置情報を受信する。
ステップＳ２６で、処理装置２１は、遠隔保守管理プログラムを実行して、通信装置２３から入力した携帯端末１の状態情報に基づいて携帯端末１の障害の有無を判断する。このステップＳ２６以降の各ステップは、処理装置２１が遠隔保守管理プログラムを実行することによって処理される。
なお、図示しないが、携帯端末１からシャットダウン（電源オフ）に係る状態情報を受け取った場合には、それ以後に障害の有無を判断する必要がなくなるので、この状態情報を送信した携帯端末については、以後の処理は不要となるので処理フローは停止する。
また、携帯端末１からシャットダウン（電源オフ）に係る状態情報を受け取っていないにも拘らず、携帯端末１から状態情報および位置情報が送られて来ず、時間猶予をもってしても受信されない場合には、携帯端末１の送信系に障害が発生したものと判断する。

ステップＳ２７で、処理装置２１は、携帯端末１に障害有り（Ｙｅｓ）と判断すれば続くステップＳ２８を実行し、障害なし（Ｎｏ）と判断すればステップＳ２５へ処理を戻す。
ステップＳ２８で、処理装置２１は、携帯端末１の障害状況（内容）および位置情報に基づいて携帯端末１が所在する位置に最も近く、かつ携帯端末１の障害の修復（復旧）に対応可能な保守拠点を、保守業務ＤＢ２４を用いて検索する。

ステップＳ２９で、処理装置２１は、検索の結果選択された保守拠点において提供するサービスが、オンサイト保守となるか持ち込み保守となるかを判断する。この判断は、携帯端末１の障害レベルおよび保守拠点が提供可能な保守内容（保守サービス）のレベルに基づいて行われる。端末機器の障害レベルおよび各保守拠点が提供可能な保守内容（保守サービス）等の情報については、保守業務ＤＢ２４を参照する。この点については後述する。

ステップＳ３０で、処理装置２１は、提供する保守サービスの内容について携帯端末１を所有（保有）する顧客に連絡する。すなわち、オンサイト保守であれば、保守員派遣に関する情報（例えば、派遣日時や派遣保守員名など）を、持ち込み保守であれば、保守拠点に関する情報（例えば、保守拠点までのアクセス経路や保守拠点の営業日時など）を、電話連絡（音声案内）またはメール連絡等の形で、通信装置２３を介して送信する。送信先としては携帯端末１へ送信するが、携帯端末１が電源オフとなる事態も想定して少なくとも携帯端末１および顧客の電話や他の通信機器のいずれかに送信するようにしてもよい。

その後、少なくとも携帯端末１および顧客の電話や他の通信機器のいずれかが、遠隔保守センタ２から送信された保守サービスに関する情報を受信する。携帯端末１等は、受信した保守サービスに関する情報がメール連絡であれば、その内容を画面上に表示するなどして所有者（保有者）である顧客に通知する。顧客は、受け取った情報に従って、オンサイト保守の場合には、保守員が来て修理等を行うまで待機することになり、持ち込み保守の場合には、保守拠点に関する情報に従って障害端末１を指定された保守拠点へ持参して修理等を行うことになる。

以上の説明では、携帯端末１および遠隔保守センタ２との間の情報のやり取りについて、双方を１：１の関係として説明したため、携帯端末１の機器識別情報の扱いについては特に触れなかった。実際には、遠隔保守センタ２は複数（Ｎ台）の携帯端末１と情報をやり取りすることになることから、携帯端末１および遠隔保守センタ２とは、Ｎ：１の関係にある。したがって、各携帯端末１を識別するための機器識別情報（番号や記号）が、携帯端末１および遠隔保守センタ２との間の情報のやり取りにおいて先立って送受信されることになる。

次に、遠隔保守センタ２が備える保守業務ＤＢ２４についてその概要を説明する。図４は、保守業務ＤＢ２４を構成するデータベースの一例を示す図である。保守業務ＤＢ２４が格納している情報（データベース）には、例えば、以下に示す種類がある。ただし、以下に示す種類の情報（データベース）に限定されるものではなく、保守業務に関する様々な情報を格納・蓄積しているものである。

図４の（Ａ）に、障害情報に関するデータベースの例を示す。障害内容、それに係る機器の状態情報、過去の発生事例、修復処置の内容（必要な部品等）および障害レベルなどを関連付けて蓄積している。
図４の（Ｂ）に、障害レベルに関するデータベースの例を示す。障害レベル、その障害回復を行うための保守形態、具体的保守内容などを関連付けて蓄積している。

図４の（Ｃ）に、保守拠点に関するデータベースの例を示す。保守拠点名、提供する保守サービス内容、保有在庫部品、場所および営業日時などを関連付けて蓄積している。
図４の（Ｄ）に、保有部品に関するデータベースの例を示す。部品番号、適用機種、在庫数、関連部品および保有している保守拠点などを関連付けて蓄積している。
ここで、蓄積形態としては、例えばテーブル形式が採用される。また、上記各データベースが蓄積するデータ項目としては、上記に限定されるものではない。

障害回復（復旧）時において、上記の保守業務ＤＢに対してどのような参照が発生するかその一例を示す。例えば、障害端末１から送信された状態情報に基づいて、障害内容や障害レベルが特定され、それに応じて保守形態（オンサイト保守、持ち込み保守およびダウンロードなど）が導き出される。また、オンサイト保守の場合には、保守拠点の場所や営業日時の情報が提供される。更に、部品交換等が必要な場合には、その部品の在庫状況（在庫数）や保有場所（保有保守拠点）に基づいて、部品の確保や不足時の発注調達などを行い対処する。

以上のとおり、実施例１によれば、遠隔保守センタは、携帯端末から定期的に送信される状態情報および位置情報に基づいて、携帯端末の障害の有無を判断し、障害を検知した場合には速やかに最適な障害の修復（復旧）を処置することが可能となる。顧客は、遠隔保守センタから送信される保守に関する情報に従って、携帯端末の障害を修復（復旧）させることができる。

実施例２は、実施例１において、遠隔保守センタ２から障害端末１に対して修復（復旧）のための必要情報を直接送信することにより、保守員の派遣や障害端末の持ち込みを経ずして修復（復旧）が可能か否かの判断処理を加えた実施形態である。
図５は、実施例２に係り、携帯端末および遠隔保守センタにおける処理フローの詳細を示す図である。実施例１で示した処理フローに対して、上記の判断処理を加えた処理フローとなっている。

携帯端末１が実行する状態情報発信フローについては、実施例１と同様であるのでその説明は省略する。
遠隔保守センタ２が実行する遠隔保守管理フローにおいて、実施例１の遠隔保守管理フローに対して新たに追加した処理部分を説明する。追加したステップＳ３１からＳ３３を含めステップＳ２５からＳ３３までの一連のフローは、処理装置２１が遠隔保守管理プログラムを実行することにより処理される。

ステップＳ２７で、処理装置２１が携帯端末１に障害有り（Ｙｅｓ）と判断した後、ステップＳ３１で、処理装置２１は、遠隔保守センタ２から障害端末１へ修復（復旧）のための情報（データ）を直接送信することで、障害端末１において修復（復旧）が可能か否かを判断する。例えば、障害内容が使用アプリケーションプログラムの不具合によるもので、修正プログラムのダウンロードにより修復可能な場合や、障害が保守コマンドの実行により修復可能であって、それを実行するための操作手順等の情報を送信することで対処可能である場合など、が想定される。

ステップＳ３１の判断で対処可能であれば（Ｙｅｓ）、ステップＳ３２で、処理装置２１は、通信装置２３を介して修復（復旧）のための必要な情報（データ）を障害端末１に送信する。障害端末１は、修復（復旧）のための必要な情報（データ）を受信し、その情報（データ）に基づいて障害の修復（復旧）に当たる（修正プログラムの実行、保守コマンドの実行等）。これにより、障害からの復旧が完了すると保守サービスは終了となる。
ステップＳ３１の判断で対処不可であれば（Ｎｏ）、処理装置２１は、実施例１と同様に、ステップＳ２８からＳ３０までの処理を実行する。各ステップの処理内容は、実施例１で前述したとおりであるので省略する。

以上のとおり、実施例２によれば、限定的ではあるが、遠隔保守センタから必要な情報（データ）を直接送信することにより端末自身で修復（復旧）が可能なレベルの障害については、保守員の派遣や障害端末の持ち込みなしに速やかに修復（復旧）が可能となり、より迅速な保守サービスを提供することができる。

なお、上記の各構成、機能、処理部、処理装置等は、それらの一部又は全部を、例えば集積回路等を使用したハードウェアで実現してもよい。また、上記の各構成、機能等は、処理部または処理装置として、処理部または処理装置を構成するプロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

また、各機能を実現するためのプログラム、ＤＢを構成するテーブルやファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができるものである。

１ 携帯端末、２ 遠隔保守センタ、１１ 処理部、１２ メモリ、１３ 通信部、
２１ 処理装置、２２ 記憶装置、２３ 通信装置、２４ 保守業務ＤＢ

Claims (6)

1. 携帯端末と、
   前記携帯端末の保守に係る情報を格納したデータベースを備える遠隔保守センタと、
   前記携帯端末と前記遠隔保守センタとの通信を行う通信環境と
   を備え、
   前記携帯端末は、稼働中の間、定期的に自らの状態情報および位置情報を前記遠隔保守センタに送信し、
   前記遠隔保守センタは、受信した前記状態情報から前記携帯端末の障害の有無を判断し、前記障害を検知した場合に、受信した前記位置情報および前記データベースに基づいて前記障害から復旧させるための保守形態をオンサイト保守とするかまたは持ち込み保守とするかを決定する
   ことを特徴とする遠隔保守サービスシステム。
2. 請求項１に記載の遠隔保守サービスシステムであって、
   前記遠隔保守センタは、前記保守形態の決定を、少なくとも前記携帯端末および前記携帯端末を所有する顧客の他の通信機器のいずれかに送信する
   ことを特徴とする遠隔保守サービスシステム。
3. 請求項１または２に記載の遠隔保守サービスシステムであって、
   前記遠隔保守センタは、前記保守形態を決定する前に、前記障害を発生した携帯端末へ前記障害を修復するための情報を送信することで復旧が可能か否かを判断し、可能であれば前記障害を発生した携帯端末へ前記障害を修復するための情報を送信して保守サービスを終了する
   ことを特徴とする遠隔保守サービスシステム。
4. 請求項１〜３のいずれかに記載の遠隔保守サービスシステムであって、
   前記データベースは、前記携帯端末の状態情報、前記携帯端末の障害内容、前記障害のレベルおよび該障害のレベルに対応した保守形態の各データ項目を関連付けて格納している
   ことを特徴とする遠隔保守サービスシステム。
5. 稼働中の間、自らの状態情報および位置情報を定期的に遠隔保守センタに送信し、
   自らの障害に対する保守情報を前記遠隔保守センタから受信し、
   受信した前記保守情報が、前記障害を修復させる情報であれば当該修復させる情報を実行し、オンサイト保守または持ち込み保守により前記障害から復旧させることを通知する情報であれば当該情報を表示する
   ことを特徴とする携帯端末。
6. 顧客の携帯端末の保守に係る情報を格納したデータベースを備える遠隔保守センタであって、
   前記携帯端末から定期的に送信される前記携帯端末の状態情報および位置情報を受信し、前記状態情報から前記携帯端末の障害の有無を判断し、前記障害を検知した場合には前記位置情報および前記データベースに基づいて前記障害から復旧させるための保守形態をオンサイト保守とするかまたは持ち込み保守とするかを決定し、前記決定した保守形態を前記携帯端末に送信する
   ことを特徴とする遠隔保守センタ。

Images