JP5065811B2 - 障害受付対応方法および障害受付対応装置 - Google Patents

Description

本発明は、顧客装置の障害通報を受け付けて保守員を決定して出動を依頼する障害受付対応方法および障害受付対応装置に関するものである。

従来、保守契約を結んだ顧客の機器が故障した場合、作業員が現場へ急行して保守作業を行う。深夜に故障した場合には電車、バスがないため、保守員は障害発生場所までタクシを利用する。タクシの利用か否かについての判断は、保守員が待機している待機センタの責任者が電車やバスの交通機関、道路の交通状況、障害の重要度、重要顧客か否かなどにより決定し承認している。

保守会社の障害受付部門が障害情報を顧客から電話や電子メールにより受け付けると、保守員が待機している待機センタに連絡する。待機センタでは権限を持つ者が保守員出動の可否を決定し、出動させる場合には予め契約しているタクシ会社にタクシ手配を依頼し、保守員はタクシ券を使用して障害発生場所まで出向き、下車時にタクシ券を運転手に渡す。タクシ会社はタクシ券と実績料金とを対応づけて月締めで請求書を作成し、会社に請求書を送る。会社は、請求書を受け取ると、所定期日に振込によって支払うようにしていた。

また、電子タクシ券を申請して承認者が発行を承認すると、電子タクシ券（電子チケット）をユーザ端末に送信する技術がある（特許文献１）。
特開２００５−１３５３３０号公報

上述した前者では、タクシ券を利用して後日、タクシ会社から請求された金額を保守会社が振り込む方法では、タクシ会社から請求された金額の確認を行って精算処理を行う作業工数が多く必要になってしまうと共に、本当に作業員が業務上の必要から利用したものか、不正にタクシを使用した金額も含まれているのか確認ができないという問題があった。また、タクシ会社では、タクシ券を回収して契約会社毎に請求書を作成して料金を回収することにかなりの工数を要してしまうなどの問題もあった。

上述した後者では、ユーザは電子タクシ券を要求し、承認者が発行を承認すると、電子タクシ券をユーザ端末に送信し、これを用いて保守員がタクシを利用して下車時に支払うことが可能である。しかし、承認者の承認を待っていたのでは緊急な障害に対応できないと共に、特に、深夜の重要顧客からの障害発生時に承認者がいない場合が多く承認を得られず、緊急性に対応できないという問題があった。

本発明は、これらの問題を解決するため、顧客装置の障害通報を受け付けて保守員を決定して出動を依頼する障害受付対応方法において、顧客装置の障害通報を受け付けるステップと、受け付けた障害情報を解析して保守員出動の承認可否を決定および障害受付番号を採番するステップと、保守員出動の承認が決定された場合には、障害情報をもとに担当保守員および交通手段を決定して出動依頼を当該担当保守員に通知するステップとを有するようにしている。

この際、受け付けた障害情報を解析して顧客装置の重要障害かおよび重要顧客の障害発生かの１つ以上をもとに保守員出動の承認を決定するようにしている。

また、受け付けた障害情報を解析して深夜帯で電車やバス使用不可かをもとに交通手段をタクシ、あるいは電車やバスのいずれかと決定するようにしている。

また、交通手段として、タクシと決定された場合には、タクシ会社サーバに配車依頼を通知するようにしている。

また、タクシ会社サーバに配車依頼を通知した場合には、保守員の待機センタから障害情報をもとに検索した顧客装置の場所までの距離を算出して概算のタクシ料金を計算し、概算タクシ料金に相当する電子マネーを保守員の端末にチャージあるいはチャージを許可するようにしている。

また、タクシ会社サーバに配車依頼した時刻と、保守員が端末から電子マネーを支払ったときの時刻との差が一定時間以内のときに乗車実績チェック済と判定するようにしている。

本発明は、顧客装置の障害通報を受け付けて当該障害情報を解析して保守員出動の承認可否を決定および障害受付番号を採番し、保守員出動の承認が決定された場合には、障害情報をもとに担当保守員および交通手段を決定して出動依頼を当該担当保守員に通知すると共に、タクシを使用する場合には概算の料金を計算して電子マネーを保守員の端末にチャージして支払わせると共にタクシ配車依頼時刻と保守員がタクシに乗車した時刻との差が一定時間内のときに乗車実績チェック済と判定することにより、夜間などの障害対応時におけるタクシ利用の管理者による承認作業を無くして出動の迅速化を図ると共に、タクシ利用時の乗車実績チェックを簡易に実現し、かつタクシ料金の後日の請求書による支払などの手間を無くすことが可能となる。

本発明は、夜間などの障害対応時におけるタクシ利用の管理者による承認作業を無くして出動の迅速化を図ると共に、タクシ利用時の乗車実績チェックを簡易に実現し、かつタクシ料金の後日の請求書による支払などの手間を無くすことを実現した。

図１は、本発明のシステム構成図を示す。
図１において、顧客装置１は、保守契約を結んだ、顧客の保守対象の装置およびその付属装置であって、例えば図９の（ａ−２）の装置分類テーブル中のＵＮＩＸサーバ（装置型名”ＧＰ７”）およびその付属装置である空調機（装置型名”ＡＡＡ”）、煙検出器（装置型名”ＢＢＢ”）などである。

サーバ２は、複数の顧客装置１を監視するサーバであって、ここでは、監視手段３などから構成されるものである。

監視手段３は、顧客装置１を常時監視して何らかの障害の発生（例えば”ハードディスに故障が発生”）を検出し、障害発生が検出された場合には、予め登録した保守会社宛に通報（例えば電子メールの本文に障害発生内容を設定して保守会社のアドレス宛に送信して通報）したりなどするものである。

保守会社システム４は、顧客装置１の保守を行う保守会社のシステムであって、ここでは、４１から４８などから構成されるものである。

障害通報受付手段４１は、顧客装置１を監視するサーバ２を構成する監視手段３から障害発生の通報を受け付けるものであって、例えば電子メールの本文に装置の障害発生内容を設定した当該電子メールを受信するものである。

交通料金算出・登録手段４２は、障害通報受付手段４１で顧客装置の障害発生を受け付けて障害受付番号を採番したときに、待機中の保守員の場所（待機センタ）から顧客装置の場所までの距離、通路に従い交通料金を計算し、障害受付番号に対応づけて登録したりなどするものである。

担当保守員依頼手段４３は、障害通報受付手段４１で顧客装置の障害発生を受け付けて障害発生番号を採番したときに、待機中で当該顧客装置の障害を担当する担当保守員を選定し、選定した担当保守員に保守依頼を通報、例えば電子メールに障害発生した顧客装置および障害発生内容などを設定した電子メールを送信して通報したりなどするものである。

電子マネー処理依頼手段４４は、交通料金算出・登録手段４２で待機センタから顧客装置の場所までの算出した交通料金について、担当保守員に電子マネーとしてチャージ依頼するものである。

タクシ配車依頼手段４５は、障害通報受付手段４１で顧客装置の障害発生を受け付けて障害受付番号を採番したときに、夜間などで電車やバスなどの交通手段が使えなく、タクシと決定したときに待機センタから顧客の障害発生装置の場所までのタクシの配車をタクシ会社に依頼したりなどするものである。

乗車実績チェック手段４６は、保守担当者がチャージされた電子マネーを使ってタクシ下車時に支払を行った場合に、タクシ乗車実績報告（支払った電子マネーの金額および支払日時（あるいは乗車日時））と、タクシ配車依頼手段４５がタクシ配車手配した日時とを比較し、時間差が一定時間以内のときはチェック結果がＯＫとし、一定時間以上のときは管理者端末へ通知して管理者の判断を仰ぐようにしたりなどするものである。

携帯残額更新手段４７は、保守担当者がタクシを使用し、下車時に電子マネーで運転手の携帯端末に料金を支払ったときに、その実績報告を受けて残額を更新するものである。

ＤＢ４８は、保守会社システム４が使用・管理する各種データを保存するデータベースであって、ここでは、４９から６１などから構成されるものである。

顧客ＤＢ４９は、保守契約した顧客および保守対象の装置などを登録したものであって、ここでは、顧客名、顧客住所、顧客装置などを登録したデータベースである（図９の（ａ−１）参照）。

装置分類テーブル５０は、保守対象の装置を分類したものであって、ここでは、装置型名に対応づけて装置分類を登録したものである（図９の（ａ−２）参照）。

保守員ＤＢ５１は、保守員情報を登録したものであって、ここでは、保守員の待機センタ、担当地区、保守員ＩＤなどを予め登録したデータベースである（図９の（ａ−３）参照）。

タクシ料金テーブル５２は、タクシの料金を登録したものであって、ここでは、距離に対応づけて料金を登録したテーブルである（図９の（ａ−４）参照）。

配車依頼専用アドレステーブル５３は、タクシ配車依頼を行う専用の電子メールのアドレスを登録したものである（図９の（ａ−６）参照）。

タクシ配車判断時間テーブル５４は、障害受け付けたときに、タクシ配車するときの判断時間を予め登録したものである（図９の（ａ−５）参照）。

チャージ用誘導ＵＲＬテーブル５５は、タクシ使用時の概算料金を、保守担当員の携帯端末にチャージさせるためのＵＲＬを登録したものである（図９の（ａ−７）参照）。

顧客別重要障害テーブル５６は、顧客別の重要度を予め登録したものであって、例えば顧客別に電子メールで受け付けたメッセージについて、重要障害に該当するメッセージを予め登録したテーブルである（図９の（ａ−９）参照）。

重要顧客テーブル５７は、重要顧客を予め登録したテーブルである（図９の（ａ−８）参照）。

出勤時間チェック閾値テーブル５８は、乗車実績チェック時の一定時間を登録したものである（図９の（ａ−１０）参照）。

障害受付ＤＢ５９は、障害を受け付けたときに採番した障害受付番号に対応づけて、障害内容などを登録した管理するものである（図９の（ａ−１１）。

保守員端末電子マネー管理ＤＢ６０は、保守員の端末が保持する電子マネーを管理するものである（図９の（ａ−１２）参照）。

電子メール雛型テーブル６１は、電子メールの雛型を登録したものである（図１１参照）。

電子マネー処理サーバ７は、タクシ利用時の電子マネーを、保守員携帯端末８にチャージするものであって、ここでは、電子マネー処理手段７１およびマネーチャージ履歴ＤＢ７２などから構成されるものである。

電子マネー処理手段７１は、保守員携帯端末８から電子マネーのチャージ要求があったときに、予め保守会社システム４から通知された情報をもとにチェックしＯＫとなったときに保守員端末携帯８に電子マネーをチャージすると共にその履歴をマネーチャージ履歴ＤＢ７２に保存するものである。

マネーチャージ履歴ＤＢ７２は、電子マネーを保守員携帯端末８にチャージしたときにその履歴を保存するものである（図１０の（ｂ−１）参照）。

保守員携帯端末８は、保守員が携帯する端末であって、ここでは、８１ないし８４から構成されるものである。

障害対応依頼受信手段８１は、障害発生してその依頼を受信、例えば電子メールで受信するものである。

旅費チャージ手段８２は、タクシ使用時などに、電子マネー処理サーバ７にアクセスして電子マネーのチャージを受けるものである。

乗車実績報告手段８３は、タクシなどに乗車して電子マネーで料金を支払ったときに当該支払った金額、日時などの乗車実績情報を保守会社システム４に通知、例えば電子メールで通知したりなどするものである。

ＤＢ８４は、保守員携帯端末８が保持する情報を登録して管理するものであって、８５から８７などから構成されるものである。

作業依頼情報テーブル８５は、障害発生したときの作業依頼情報を登録して管理するものである（図１０の（ｃ−１）参照）。

作業指示情報ＤＢ８６は、作業指示情報を登録して管理するものである（図１０の（ｃ−２）参照）。

携帯端末履歴情報ＤＢ８７は、各種履歴を登録した管理するものである（図１０の（ｃ−３）参照）。

タクシ端末９は、タクシの運転手が携帯（あるいはタクシに設置）した端末であって、ここでは、９１ないし９５などから構成されるものである。

出勤依頼受付手段９１は、保守担当者の出勤依頼（配車依頼）の情報を受け付けるものである。

電子マネー支払処理手段９２は、保守担当員がタクシを利用し、下車時に、保守員携帯端末８から電子マネーで支払を受けるものである。

業務実績報告手段９３は、タクシを利用した顧客（保守担当者）の実績（乗車日時、下車日時、料金などの実績）をタクシ会社サーバ１０に送信して報告するものである。

位置情報取得手段９４は、現在位置（例えば公知のＧＰＳなどで検出した現在位置）を取得するものである。

ＤＢ９５は、タクシ端末９で使用する各種情報を登録して管理するものであって、ここでは、９６ないし９８などから構成されるものである。

タクシ状況テーブル９６は、タクシが空車か否か、現在位置などを登録したものである（図１０の（ｅ−１）参照）。

電子メール雛型テーブル９８は、送信する電子メールの雛型を予め作成して登録したものである（図１１参照）。

タクシ会社サーバ１０は、タクシ会社のサーバであって、ここでは、１１ないし１３などから構成されるものである。

配車受付手段１１は、保守会社システム４から配車依頼を受け付ける、例えば電子メールで受け付けるものである。

業務実績報告受取手段１２は、タクシ端末９の業務実績報告手段９３からの業務実績報告を受け取る、ここでは、例えばタクシを利用した保守員が乗車した日時、下車した日時、料金などの業務実績情報を電子メールで受け取るものである。

ＤＢ１３は、タクシ会社サーバ１０で使用する情報を登録して管理するものであって、ここでは、１４ないしＳ７などから構成されるものである。

配車依頼受付ＤＢ１４は、保守会社システム４から配車依頼を受け付け、管理するものである（図１０の（ｄ−１）参照）。

契約会社情報テーブル１５は、契約会社を登録して管理するものである（図１０の（ｄ−２）参照）。

タクシ出勤情報テーブル１６は、タクシの出勤情報を管理するものである（図１０の（ｄ−３）参照）。

電子メール雛型テーブル１７は、タクシ会社サーバ１０が送信する電子メールの雛型を登録して管理するものである（図１１参照）。

ネットワーク２１は、サーバ３、保守会社システム４、電子マネー処理サーバ７、タクシ端末９、タクシ会社サーバ１０などが相互に通信するネットワークであって、インターネット、無線電話網などである。

次に、図２から図８のフローチャートの順番に従い、図１の構成について、図９から図１１を参照して順次詳細に説明する。

図２から図８は、本発明の動作説明フローチャートを示す。
図２において、Ｓ１は、障害通報を受信したか判別する。これは、例えば電子メール、例えば後述する図１１の（ａ）の電子メール、
・装置ＩＤ：ＧＰ７−２
・メッセージ：ハードディスクが故障しました。
というメッセージで障害通報を受信する。

Ｓ２は、障害通報を登録する。これは、Ｓ１で受信した障害通報を、図９の（ａ−１１）の障害受付ＤＢ５９に登録、例えば
・障害受付日時：２００７年４月１日２３時１０分
・障害装置ＩＤ：ＧＰ７−２
・障害メッセージ：ハードディスクが故障しました。
を電子メールから抽出して、および受付日時を登録する。

Ｓ３は、障害通報の受信時刻は夜間受付時間内か判別する。これは、障害通報の受信時刻が、通常の勤務以外の夜間受付時間内か判別する。ＹＥＳの場合には、夜間受付時間内と判明したので、Ｓ４に進む。ＮＯの場合には、夜間受付時間内でなく、通常の業務時間内と判明したので、Ｓ１０に進む。

Ｓ４は、Ｓ３のＹＥＳで夜間受付時間内と判明したので、障害メッセージは重要障害か判別する。これは、受信した電子メールに設定されているメッセージが、当該顧客毎に登録されている図９の（ａ−９）の顧客別重要障害テーブル５６に登録されているメッセージ（重要障害メッセージ）に該当するか判別、ここでは、顧客（田中研究所）について”ハードディスクが故障しました。”は登録されており、重要障害発生と判定し、ＹＥＳとなり、Ｓ６に進む。ＮＯのときはＳ５に進む。

Ｓ５は、Ｓ４のＮＯで重要障害メッセージに該当しなかったので、更に、重要顧客か判別する。これは、図９の（ａ−８）の重要顧客テーブル５７を参照し、障害通報を受け取った顧客が登録されているか判別する。ＹＥＳの場合には、重要障害メッセージではなかったが、重要顧客からの障害通知と判明したので、Ｓ６に進む。一方、ＮＯの場合には、重要障害メッセージではなく、かつ重要顧客からの障害通知でもなかったと判明したので、Ｓ９で障害重要度を”低い”に設定して翌日案件（翌日の平常業務内の案件）とし登録（例えば図９の（ａ−１１）の障害受付ＤＢ５９中の障害重要度の欄に”低い”と設定）し、Ｓ１０に進む。

Ｓ６は、障害通報が夜間受付時間内であり、更に、障害メッセージが当該顧客毎の重要メッセージに一致したと判明、あるいは障害メッセージが当該顧客毎の重要メッセージに一致しないが重要顧客であると判明したので、障害重要度を”高い”に設定する。これは、図９の（ａ−１１）の障害受付ＤＢ５９の障害重要度の欄に”高い”と設定する。

Ｓ７は、交通手段が”タクシ使用”と判定する。
Ｓ８は、障害受付番号を採番する。これにより、図９の（ａ−１１）の障害受付ＤＢ５９のエントリ中の障害受付番号欄に一意に採番された障害受付番号（例えば”５５５５５５”）が設定される。

以上のＳ１，Ｓ２、Ｓ３のＹＥＳ，Ｓ４からＳ８によって、電子メールで障害通報を受付け、受付時刻が夜間受付時間内であって、かつ障害メッセージが顧客毎の重要メッセージに一致したと判明、あるいは一致しないが重要顧客であると判明した場合には、障害受付番号を採番して障害受付ＤＢ５９に当該障害受付番号を設定すると共に重要度を”高い”に設定、および電子メールで受信した障害情報（障害装置ＩＤ，メッセージ、顧客名などの障害情報）を図９の（ａ−１１）の障害受付ＤＢ１１に登録し、障害を受け付けることが可能となる。

一方、Ｓ１０は、Ｓ３のＮＯで夜間受付時間内でないと判明、あるいは夜間受付時間内ではあるが障害メッセージが重要でないかつ重要顧客でないと判明したので、障害受付番号を採番する。

Ｓ１１は、障害内容の重要度は高いか判別する。ＹＥＳの場合には、Ｓ１２で交通手段は”タクシ”使用と判定する。一方、ＮＯの場合には、Ｓ１３で料金表をもとに最低料金を検索し、電車又はバスでの行き方を検索する。そして、Ｓ１４に進む。

Ｓ１４は、タクシ利用あるいは電車、バス利用のいずれか判別する。タクシ利用の場合には、（１）（図３）へ進む。電車、バス利用の場合には、（２）（図４）へ進む。

図３は、タクシ利用の場合のフローチャートを示す。
図３において、Ｓ１５は、予定交通費を距離から算出して乗車場所、下車場所とともに登録する。これは、図２のＳ１４でタクシ利用と判明したので、保守員の場所（待機センタの場所）から顧客の場所までの距離を公知の地図ＤＢを利用して計測し、当該距離をもとに後述する図９の（ａ−４）のタクシ料金テーブル５２から予定交通費（タクシ料金）を算出し、図９の（ａ−１１）の障害受付ＤＢ５９に、例えば
・乗車場所：東京都西新宿２−２−２
・降車場所：東京都新宿１−１−１
・距離：例えば２キロ（２ｋｍ）
・予定交通費：１０００円
と登録する。

Ｓ１６は、ステータスが「待機中」の保守員がいるか判別する。これは、後述する図９の（ａ−３）の保守員ＤＢ５１を検索し、待機センタに担当地区の保守員かつ「待機中」の保守員がいるか検索し、担当可能な保守員がいるか判別する。ＹＥＳの場合には、待機センタにステータスが「待機中」の保守員がいると判明したので、Ｓ１７に進む。ＮＯの場合には、ここでは、「待機中」の保守員が見つかるまで所定時間繰り返し、所定時間経過しても見つからないときは、管理者に提示して知らせる。

Ｓ１７は、「待機中」の保守員の端末に出動依頼メールを送信する。例えば図１１の（ｂ）の電子メールメッセージを待機中の保守員の端末に送信する。

Ｓ１８は、前記保守員のステータスを「作業中」に変更する。これは、Ｓ１７で「待機中」の保守員に出動依頼メールを送信したことに対応して、後述する図９の（ａ−３）の保守員ＤＢ中の当該保守員のステータス「待機中」を「作業中」に変更する。

Ｓ１９は、タクシ会社サーバへ配車依頼メールを送信する。これは、例えば後述する図１１の（ｄ）の配車依頼メールを、契約した所定のタクシ会社サーバに送信する。

Ｓ２０は、保守員端末より保守会社へのチャージ依頼のアクセスありか判別する。これは、保守員が保守員端末を操作し、保守会社のサーバへタクシ料金のチャージ依頼のアクセスがあったか判別する。ＹＥＳの場合には、Ｓ２１に進む。ＮＯの場合には、Ｓ２０を繰り返し実行する。

Ｓ２１は、保守員端末から入力された保守員番号が障害受付番号に対応づけられた保守員番号と一致するか判別する。これは、例えばＳ２０で保守員が保守員端末を操作し、後述する図１１の（ｃ−１）のメニュー画面を保守会社サーバからダウンロードして表示し、当該画面上から電子マネーチャージを選択し、ダウンロードして表示した図１１の（ｃ−２）の画面上から保守員番号、障害受付番号、パスワードを入力して送信し、入力された保守員番号が障害受付番号に対応づけられた保守員番号に一致するか、図９の（ａ−１１）の障害受付ＤＢ５９を参照して判別する。ＹＥＳの場合には、Ｓ２２に進む。ＮＯの場合には、Ｓ２１を繰り返し実行する。

Ｓ２２は、担当保守員端末に記憶されている残額と必要となる交通費とから、チャージする金額を算出し、障害受付番号および金額を指定して電子マネー処理サーバへチャージ処理依頼する。これは、担当保守員端末に記憶されている残額と、必要となる交通費（Ｓ１５で算出した予定交通費）とから、チャージする金額を算出（例えば予定交通費を使った後の残額が１０００円となるように、現在の残額と、（１０００円＋予定交通費）との差額をチャージする金額として算出）し、算出したチャージする金額と障害受付番号とを指定して電子マネー処理サーバ７にチャージ依頼する。保守担当員は、後述する図１１の（ｃ−３）の画面上でチャージしますかのメッセージに応じて［はい］ボタンを選択し、電子マネー処理サーバ７からチャージする金額を保守員端末内にチャージする。

Ｓ２３は、担当保守員端末より保守会社システムが乗車実績報告を受信したか判別する。これは、保守員がＳ１９で配車依頼されたタクシが待機センタに来たときに乗車し、顧客の装置障害発生場所で降車し、保守員端末からタクシ端末に電子マネーで支払った情報を記憶しておき、顧客先の障害装置の故障修理などの作業を終了した時（あるいは待機センタに帰社した時）などに、保守員端末に記憶されている乗車実績報告（乗車場所、乗車日時、降車場所、降車日時、実際に支払ったタクシ料金など）を保守会社システムへ送信し、保守会社システムが当該乗車実績報告を受信したか判別する。ＹＥＳの場合には、Ｓ２４に進む。ＮＯの場合には、待機する。

Ｓ２４は、保守員のステータスを「待機中」に変更する。これは、顧客先の障害装置の故障修理などの一連の作業が終了したと判明したので、後述する図９の（ａ−３）の保守員ＤＢ５１中の該当保守員のステータスを「作業中」から「待機中」に変更する。

Ｓ２５は、乗車実績報告の送信者が前記障害受付番号における担当保守員と同一人物でありタクシ配車依頼日時と乗車日時との差が一定時間内か判別する。これは、作業終了した保守員から受信した乗車実績報告中の、待機センタからタクシに乗車した乗車日時が、Ｓ１９でタクシ会社サーバへ配車依頼した配車依頼日時との差が一定時間（例えば２０分）以内か判別する。ＹＥＳの場合には、乗車日時が配車依頼日時から一定時間以内の時間と判明し、正常な利用（不正なタクシ利用ではない）と判定し、Ｓ２７に進む。ＮＯの場合には、乗車日時が配車依頼日時から一定時間経過後の時間と判明し、不正タクシ利用の可能性がありと判定し、Ｓ２６で管理者端末へ報告する。

尚、ここでは、配車依頼日時から保守員のタクシへの乗車日時までの経過時間が一定時間以内のときに正常な利用と判定したが、これに限られず、保守員がタクシの下車時の日時あるいはタクシの料金を電子マネーで支払った日時までの経過時間が一定時間以内のときに正常な利用と判定するようにしてもよい。

Ｓ２６は、Ｓ１５のＮＯで保守担当者のタクシ乗車日時が配車依頼日時から一定時間経過後の時間と判明したと報告を受けたので、管理者はその理由を保守担当者に別途、電子メールなどで聞いて妥当性があれば承認し、Ｓ２７に進む。妥当性がなければ、タクシ不正利用と判定し、該当する処置を別途、行う。

Ｓ２７は、チェック結果を登録して、電子マネー管理情報の携帯端末残額を更新する。これは、例えば後述する図９の（ａ−１２）の保守員端末電子マネー管理ＤＢ６０中の該当保守担当員の情報（取引（チャージ、支払の区別）、取引内容、携帯端末残額）を更新する。そして、図４の（３）に進む。

図４のＳ４５は、締め日か判別する。ＹＥＳの場合には、Ｓ４６で報告情報リストを出力する。例えば後述する図１１の（ｈ）の報告情報リスト（障害受付番号、担当保守員、チェック結果（Ｓ２５のチェック結果）、出動時間、交通費実績）を出力する。一方、ＮＯの場合には、報告情報リストを出力することなく、終了する。

以上の図３のＳ１５からＳ２７、図４のＳ４５、Ｓ４６によって、タクシ利用と決定された場合に、待機中の保守員を見つけて当該保守員の待機中を作業中に変更およびタクシ配車依頼すると共に、タクシ料金を算出して保守員端末に不足金額をチャージし、保守員がタクシを利用して顧客先の障害装置の場所に出向き、電子マネーでタクシ料金を支払い、障害装置の故障修理などの作業が終了したとき（あるいは待機センタに帰社したとき）に乗車実績情報を保守会社システムへ送信し、保守会社システムは受信した保守担当者からの乗車実績情報中の乗車日時（電子マネー支払日時）と、タクシ配車依頼日時とが一定時間以内のときにチェックＯＫ（タクシ不正利用なし)と判定および保守担当員の図９の（ａ−１２）の保守員端末電子マネー管理ＤＢ６０中の残額などを更新することを繰り返し、締め日になったときに図１の（ｈ）の報告情報リストを自動作成して出力することが可能となる。これらにより、夜間などの障害対応時におけるタクシ利用の管理者による承認作業を無くして出動の迅速化を図ると共に、タクシ利用時の乗車実績チェックを簡易に実現し、かつタクシ料金の後日の請求書による支払などの手間を無くすことが可能となる。

図４は、電車、バス利用の場合のフローチャートを示す。
図４において、Ｓ３５は、障害場所を担当する待機場所から障害場所までの最寄の駅間の交通料金を算出する。これは、顧客の障害発生装置の場所を担当する待機センタの場所から、顧客の障害発生装置の場所までの交通料金が最低のルートとその料金を、公知のソフトウェアを用いて算出（検索）する。

Ｓ３６からＳ４４は、既述した図３のＳ１６からＳ２４の該当する番号にそれぞれ対応し、ほぼ同じであるので、ここでは、説明を省略する。

Ｓ４５は、締め日か判別する。ＹＥＳの場合には、Ｓ４６で報告情報リストを出力する。例えば後述する図１１の（ｈ）の報告情報リスト（障害受付番号、担当保守員、チェック結果、出動時間、交通費実績）を出力する。一方、ＮＯの場合には、報告情報リストを出力することなく、終了する。

以上の図４のＳ３５からＳ４６によって、電車、バス利用と決定された場合に、待機中の保守員を見つけて当該保守員の待機中を作業中に変更すると共に、ルートを通知、および交通費を算出して保守員端末に不足金額をチャージし、保守員が電車、バスを利用して通知されたルートを経て顧客先の障害装置の場所に出向き、電子マネーで交通費を支払い、障害装置の故障修理などの作業が終了したとき（あるいは待機センタに帰社したとき）に乗車実績情報を保守会社システムへ送信し、保守会社システムは受信した保守担当者からの乗車実績情報をチェックしてＯＫと判定および保守担当員の図９の（ａ−１２）の保守員端末電子マネー管理ＤＢ６０中の残額などを更新することを繰り返し、締め日になったときに図１の（ｈ）の報告情報リストを自動作成して出力することが可能となる。これらにより、障害対応時における電車、バス利用の管理者による承認作業を無くして出動の迅速化を図ると共に、電車、バス利用時の乗車実績チェックを簡易に実現し、かつ電車、バス料金の後日の保守担当者からの個別の交通費請求書による支払などの手間を無くすことが可能となる。

図５は、本発明の動作説明フローチャート（タクシ会社サーバ）を示す。
図５において、Ｓ５１は、タクシよりステータス変更通知を受信したか判別する。これは、タクシより、ステータス変更通知、ここでは、実車から空車へステータス変更通知を受信したか判別する。ＹＥＳの場合には、Ｓ５２でステータス変更、ここでは、実車から空車にステータス変更し、Ｓ５３に進む。Ｓ５１のＮＯの場合には、Ｓ５１を繰り返す。

Ｓ５３は、配車依頼メールを受信したか判別する。これは、既述した図３のＳ１９で保守会社システム４がタクシ会社サーバ１０に配車依頼メールを送信したことに対応して、当該タクシ会社サーバ１０が配車依頼メールを受信したか判別する。ＹＥＳの場合には、Ｓ５４に進む。ＮＯの場合には、Ｓ５３を繰り返し実行する。

Ｓ５４は、発信者アドレスより待機センタの場所から最も近くの「空車」タクシを抽出して出動依頼メールを送信する。これは、受信した配車依頼メールの発信者アドレスより待機センタの場所を、図示外のテーブルから検索してその場所を見つけ、当該場所に最も近い空車のタクシを抽出し、出動依頼メール（待機センタの場所、乗車する保守員氏名など）をタクシ端末に送信し、出動依頼（配車手配）する。

Ｓ５５は、タクシ端末より実績データを受信か判別する。これは、Ｓ５４で出動依頼メールで待機センタに最も近い空車のタクシのタクシ端末に出動依頼メールを送信して出動依頼し、出動依頼を受けたタクシが待機センタに出向いて保守員を乗せ、障害発生装置の場所で降車したときの乗車実績データ（乗車場所、乗車日時、降車場所、降車日時、料金（電子マネー））をタクシ会社サーバ１０が受信か判別する。ＹＥＳの場合には、Ｓ５６で実績データを登録する。一方、ＮＯの場合には、Ｓ５５を繰り返し実行する。

以上によって、タクシ会社サーバ１０は、保守会社システム（待機センタ）４から配車依頼メールを受信してタクシを配車し、保守員が待機センタで乗車し、顧客先の障害発生装置の場所で降車して電子マネーでタクシ料金を支払うとその乗車実績データをタクシ会社サーバ１０に送信し、タクシ会社サーバが登録して管理することが可能となる。これらにより、タクシ会社では電子マネーでタクシ利用料金をその都度、支払を受けるので、従来の締め日に当月の会社別に利用料金を集計して請求書を作成して各社宛に送付する手間を不要にすることが可能となる。

図６は、本発明の動作説明フローチャート（保守員端末）を示す。
図６において、Ｓ６１は、出動依頼メールを受信したか判別する。これは、既述した図３のＳ１７で保守会社システム４から送信された出動依頼メールを、保守員携帯端末８で受信したか判別する。これは、例えば後述する図１１の（ｂ）の出動依頼メールを受信したか判別する。ＹＥＳの場合には、Ｓ６２に進む。ＮＯの場合には、Ｓ６１を繰り返し実行する。

Ｓ６２は、指定先ＵＲＬへアクセスし、保守員ＩＤ、パスワード、障害受付番号を入力する。これは、受信した出動依頼メール中の指定アドレスをクリックし、指定先ＵＲＬにアクセスして図１１の（ｃ−２）の画面をダウンロードして表示させ、当該画面上から保守員のＩＤ，障害受付番号、パスワードを入力し、図示外の実行（ＯＫ）ボタンを押下する。

Ｓ６３は、電子マネーをチャージする。これは、Ｓ６２で後述する図１１の（ｃ−２）の画面で入力された保守員ＩＤ，障害受付番号、パスワードを受信した電子マネー処理サーバ７が予め保守会社システム４からチャージ依頼を受けた情報（保守員ＩＤ，障害受付番号、パスワードなど）と照合し、ＯＫのときに後述する図１１の（ｃ−３）の画面を保守員携帯端末８に表示させ、「はい」ボタンがクリックされたときに、電子マネーを保守員携帯端末８にダウンロードしてチャージすると共に、後述する図１１の（ｃ−４）の画面を表示してチャージ完了した旨を通知する。

Ｓ６４は、タクシでの精算により乗車実績情報を登録する。これは、保守員が保守員携帯端末８を所持してタクシに乗車し、降車時に、当該保守員携帯端末８からタクシのタクシ端末に向けて電子マネーでタクシ料金を支払うと共に、乗車実績情報（乗車日時、乗車場所、降車日時、降車場所、実際に支払ったタクシ料金）を保守員携帯端末８の不揮発メモリに登録する。

Ｓ６５は、乗車実績報告情報を送信する。これは、顧客先の障害発生装置の故障修理などの作業を完了したとき（あるいは待機センタに帰社とき）に、Ｓ６４で登録しておいた乗車実績情報に、作業情報などを付加した乗車実績報告情報を作成（編集）し、保守会社システム４に送信する。これにより、既述した図３のＳ２３で乗車実績報告を、保守会社システムが受信したこととなる。

以上によって、保守員が携帯する保守員携帯端末８で出動依頼メールを受信したときに、図１１の（ｃ−２）のダウンロードして表示した画面上から保守員ＩＤ、障害受付番号、パスワードを入力して交通費を保守員携帯端末８にチャージし、タクシ、電車、バスの利用時にチャージした電子マネーでその都度、支払ってその乗車実績情報（乗車日時、降車日時、支払った料金）を登録しておき、顧客先の障害発生装置の故障修理などの作業終了時（あるいは待機センタに帰社時）に、これら乗車実績情報をもとに乗車実績報告を編集（作成）し、保守会社システム４に送信することが可能となる。これらにより、障害対応時におけるタクシ、電車、バスの利用時の管理者による承認作業を無くして出動の迅速化を図ると共に、タクシ、電車、バスの利用時の乗車実績チェックを簡易に実現し、かつタクシ、電車、バスの料金の後日の請求書による支払などの手間を無くすことが可能となる。

図７は、本発明の動作説明フローチャート（タクシ端末）を示す。
図７において、Ｓ７１は、ステータスを「空車」にセットする。これは、タクシの業務開始時に、最初に、ステータスを「空車」にセットする。

Ｓ７２は、一定間隔でＧＰＳ情報を送信する。これは、タクシに設置されたＧＰＳから取得した現在位置情報を、タクシ会社サーバ１０に一定時間間隔で送信し、自車の位置およびステータス（ここでは、「空車」）を知らせる。

Ｓ７３は、実車か判別する。タクシ業務開始時は「空車」であるので、ＮＯとなり、Ｓ７４に進む。一方、ＹＥＳの場合（「実車」の場合）には、Ｓ７９に進む。

Ｓ７４は、Ｓ７３のＮＯで空車と判明したので、出動依頼メールを受信か判別する。ＹＥＳの場合には、Ｓ７５に進む。ＮＯの場合には、Ｓ７２以降を繰り返す。

Ｓ７５は、Ｓ７４のＹＥＳで出動依頼メールを受信したと判明したので、出動依頼画面を表示すると共に、音声読み上げを行う。これにより、受信した出動依頼メールで指示された、顧客の乗車時刻と乗車場所などの情報を容易に認識できる。

Ｓ７６は、乗車時刻と乗車場所を登録して、ステータスを「実車」に変更して送信する。これは、タクシが保守員を乗せたので、その乗車時刻と乗車場所（ＧＰＳから取得）を不揮発メモリに登録して、ステータスを「空車」から「実車」に変更し、タクシ会社サーバ１０に送信する。

Ｓ７７は、電子マネー用精算ボタンが押されると、実績料金の電子マネーを保守員携帯端末８から受け取り、乗車情報を前記保守員携帯端末８に登録する。これにより、保守員は保守員携帯端末８中の電子マネーでタクシ料金をタクシ端末９に送信して支払うと共に、タクシ端末９から乗車情報（乗車時刻、乗車場所、降車時刻、降車場所、料金）を保守員携帯端末８に送信して登録することが可能となる。

Ｓ７８は、降車時にステータスを「空車」に変更して送信する。Ｓ７７で電子マネーでタクシ利用料金を支払いを受け、保守員が降車したので、タクシのステータスを「実車」から「空車」に変更してタクシ会社サーバ１０に送信する。

Ｓ８１は、業務終了か判別する。ＹＥＳの場合には、Ｓ８２で実績データをタクシ会社サーバ１０に送信し、終了する。ＮＯの場合には、Ｓ７１に戻り繰り返す。

Ｓ７９は、Ｓ７３のＹＥＳでタクシのステータスが「実車」と判明したので、ステータを「実車」に変更してタクシ会社サーバ１０に送信し、料金計算をスタートさせる。

Ｓ８０は、降車時に精算し、ステータスを「空車」に変更して送信する。
Ｓ８１は、業務終了か判別する。ＹＥＳの場合には、Ｓ８２で実績データをタクシ会社サーバ１０へ送信し、終了する。ＮＯの場合には、Ｓ７１以降を繰り返す。

以上によって、タクシが空車のときに出動依頼メールを受信すると、出動依頼を受けた場所に出向いて保守員を乗せ、障害発生装置の場所で降車する時に、電子マネーで料金を支払うと共に乗車情報（乗車場所、乗車時刻、降車場所、降車時刻、料金）を保守員携帯端末８に書き込んで登録すると共に、「空車」をタクシ会社サーバ１０に送信することにより、タクシ利用時の乗車情報を収集して乗車実績報告を作成して保守会社システムに簡易に送信して、実績チェックを簡易に実現し、かつタクシ料金の後日の請求書による支払などの手間を無くすことが可能となる。

図８は、本発明の動作説明フローチャート（電子マネー処理サーバ）を示す。
図８において、Ｓ９１は、チャージ処理依頼があったか判別する。これは、既述した図３のＳ２２で保守会社システム４から電子マネー処理サーバ７へチャージ処理依頼があったか判別する。ＹＥＳの場合には、Ｓ９２に進む。ＮＯの場合には、Ｓ９１を繰り返す。

Ｓ９２は、チャージ処理依頼金額が会社として残高範囲内か判別する。ＹＥＳの場合には、Ｓ９４に進む。ＮＯの場合には、Ｓ９３に進む。

Ｓ９３は、Ｓ９２のＮＯでチャージ処理依頼金額が会社として残高範囲内でないと判明したので、不足金額を後日入金依頼とし、現在の残高分についてＳ９４に進む。

Ｓ９４は、障害受付番号およびチャージ金額を登録してチャージ処理する。これは、Ｓ９１のＹＥＳでチャージ処理依頼メールでチャージ依頼を受けた金額の電子マネーについて、チャージ処理依頼メール中の障害受付番号およびチャージ金額を登録（後述する図１０の（ｂ−１）のマネーチャージ履歴ＤＢ７２に登録）すると共に、チャージ金額に相当する電子マネーを、保守員携帯端末８に書き込んでチャージする。そして、Ｓ９１に戻り繰り返す。

以上によって、保守会社システム４が電子マネー処理サーバ７にチャージ処理依頼すると、電子マネー処理サーバ７が図１１の（ｃ−２）の画面から保守員番号、障害受付番号、パスワードを入力させてチャージ処理依頼時に通知された情報（あるいは予め電子マネー処理サーバ７１に登録した情報（パスワードなど））と比較して一致したときに認証ＯＫとし、チャージ依頼された金額の電子マネーを、保守員携帯端末８に登録してチャージすることが可能となる。

図９および図１０は、本発明のＤＢ／テーブル例を示す。
図９の（ａ）は、保守会社システムのＤＢ／テーブル例を示す。

図９の（ａ−１）は、顧客ＤＢ例を示す。顧客ＤＢ４９は、装置の障害発生時などに保守（修理など）を行う対象の契約した顧客の情報を登録したデータベースであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・顧客名：
・顧客住所：
・顧客装置ＩＤ：
・その他：
ここで、顧客名は、装置の保守契約を結んだ、保守対象の顧客名である。顧客住所は、ここでは、顧客の保守対象の装置が設置されている住所である。顧客装置ＩＤは、保守対象の装置を識別するＩＤである。

以上の情報を顧客ＤＢ４９に登録しておくことにより、障害発生時に、顧客名、顧客装置ＩＤの知らせを受けると、障害発生装置の場所が顧客住所、障害発生装置の種類、型番などが顧客装置ＩＤで保守会社システム側で一意に認識し、保守担当者を出向かせて修理などを行わせることが可能となる。

図９の（ａ−２）は、装置分類テーブル例を示す。装置分類テーブル５０は、装置の分類を予め登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・装置型名：
・装置分類：
・その他：
ここで、装置型名は保守契約した顧客先の装置の型名を登録したものである。装置分類は、装置型名に対応づけて装置の分類を登録したものである。

図９の（ａ−３）は、保守員ＤＢ例を示す。保守員ＤＢ５１は、装置を保守する保守員の情報を登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・待機センタ：
・担当地区：
・保守員ＩＤ：
・待機場所：
・ステータス：
・メールアドレス：
・その他：
ここで、待機センタ、担当地区は、待機センタの名前、およびその保守の担当地区である。保守員ＩＤは保守員を一意に表すＩＤである。待機場所は、保守員が待機する場所である。ステータスは、保守員が待機中、作業中、−（待機中でもなく作業中でもない、未就業中）のいずれかを設定して状態を管理するためのステータスである。メールアドレスは、保守員が所持する保守員携帯端末８に電子メールで出動依頼などを送信するときのメールアドレスである。

図９の（ａ−４）は、タクシ料金テーブル例を示す。タクシ料金テーブル５２は、タクシ利用時の概算の料金を算出するためのテーブルであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・距離：
・タクシ料金：
・その他：
ここで、距離は、待機センタの場所から、顧客先の障害発生装置の場所までの距離であって、公知のナビシステムなどで道路地図上の車の走行距離に対応するものである。タクシ料金は、距離に対応した料金を予め登録したものである。

図９の（ａ−５）は、タクシ配車判断時間テーブル例を示す。タクシ配車判断時間テーブル５４は、夜間などの障害発生時に、電車、バスの利用か、電車、バスが夜間で利用不可でタクシ利用かを判断するための時間帯を登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・設定時間帯：
・判断：
・その他：
ここで、設定時間帯は、夜間受付、管理者判断などの判断を行う時間帯を登録するものである。判断は、設定時間帯に対応する判断を登録したものである。

以上のタクシ配車判断時間テーブル５４中に設定時間帯に対応づけてその判断を登録しておくことにより、夜間などに発生した顧客先の装置障害発生を受け付けたときに、自動的に夜間受付時間帯でタクシ利用と判断したり、管理者判断として管理者端末に表示して管理者の判断を仰いだりして判断したり、自動的に切り替えることが可能となる。

図９の（ａ−６）は、配車依頼専用アドレステーブル例を示す。配車依頼専用アドレステーブル５３は、配車依頼を行うときの電子メールアドレスなどを登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・タクシ会社名：
・依頼用アドレス：
・配車コード：
・その他：
ここで、タクシ会社名はタクシ配車依頼を行うタクシ会社名である。依頼用アドレスは、タクシ会社に依頼を行う電子メールアドレスである。配車コードは、タクシ会社に配車するときの配車コード（タクシ会社毎に付与された配車コード）である。

図９の（ａ−７）は、チャージ用誘導ＵＲＬテーブル例を示す。チャージ用誘導ＵＲＬテーブル５５は、保守員が交通費のチャージを受けるときにアクセスする電子マネー処理サーバ７のＵＲＬを登録したものであって、ここでは、図示の下記の情報を登録したものである。

・チャージ用誘導ＵＲＬ
・その他：
ここで、チャージ用誘導ＵＲＬは、保守員が交通費を保守員携帯端末８にチャージするときに、当該保守員携帯端末８から無線でネットワーク上の電子マネー処理サーバ７にアクセスし、チャージを受けるためのＵＲＬである。

図９の（ａ−８）は、重要顧客テーブル例を示す。重要顧客テーブル５７は、保守契約した重要な顧客を登録したものであって、ここでは、図示の下記の情報を登録したものである。

・顧客名：
・その他：
ここでは、顧客名は、保守契約した重要な顧客名である。

以上のように、重要顧客テーブル５７に重要顧客を登録しておくことにより、夜間などに装置障害発生を受信したときに、当該障害発生した装置の顧客が、当該重要顧客テーブル５７を検索して登録されているときは、既述した図２のＳ５のＹＥＳとなり、タクシ利用して重要顧客の装置の場所に保守員が出向き、故障修理などを行うと決定することが可能となる。

図９の（ａ−９）は、顧客別重要障害テーブル例を示す。顧客別重要障害テーブル５６は、顧客別に重要障害発生と判断するメッセージを登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・顧客名：
・メッセージ：
・その他：
ここで、顧客名は、保守契約を結んだ顧客名である。メッセージは、当該顧客に設置した保守対象の装置について、重要障害と判定するメッセージを予め登録したものである。

以上のように、顧客別重要障害テーブル５６に重要障害と判定するメッセージを予め登録したことにより、顧客から障害発生の電子メールを受信、例えば後述する図１１の（ａ）の電子メールを受信すると、電子メール中のメッセージ「ハードディスクが故障しました。」を取り出して顧客別重要障害テーブル５６中の当該顧客に対応づけて登録されているメッセージ中にあれば、重要障害と判明するので、既述した図２のＳ４のＹＥＳと判断することが可能となる。

図９の（ａ−１０）は、出動時間チェックテーブル例を示す。出動時間チェックテーブル５８は、保守会社システム４が電子メールで待機中の保守員に出動依頼メールを送信した時刻から、電子メールで出動依頼を受けた保守員が配車されたタクシに乗車して顧客先に向かったときの当該乗車時刻（あるいは降車時刻）までの時間が、ここでは、２０分以内（あるいは降車時刻のときは更にタクシ乗車時間を加算した時間以内）のときにチェックＯＫと判定するためのものである。

図９の（ａ−１１）は、障害受付ＤＢ例を示す。障害受付ＤＢ５９は、顧客から障害を受け付けたときにその情報を登録した管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・障害受付番号：
・障害受付日時：
・障害装置ＩＤ：
・障害メッセージ：
・障害重要度：
・担当保守員：
・保守員依頼日時：
・配車依頼日時：
・乗車場所：
・降車場所：
・距離：
・予定交通費：
報告情報
・報告受信日時：
・乗車場所：
・乗車日時：
・降車場所：
・降車日時：
・交通費実費：
・出動時間：
・チェック結果：
・その他：
ここで、障害受付番号、障害受付日時、障害装置ＩＤ、障害メッセージ、障害重要度は、障害を受け付けた番号、障害を受け付けた日時、障害を受け付けた障害装置のＩＤ、電子メールで受信した障害メッセージ、障害メッセージあるいは顧客重要度をもとに判定した障害重要度である。担当保守員、保守員依頼日時、配車依頼日時、乗車場所、降車場所、距離、予定交通費は、障害を受け付けとときに選定された保守員、電子メールで保守員に出動依頼した日時、タクシの配車依頼をした日時、タクシの乗車場所（保守員が待機する待機センタ）、タクシの降車場所（障害発生装置の場所）、乗車場所から降車場所までの距離、タクシの予定交通費である。報告情報（作業終了後に保守員が保守会社システム４に送信した乗車実績報告情報で報告された実際の報告受信日時、乗車場所、乗車日時、降車場所、降車日時、交通費実費、出動時間（出動電子メールを受信してから例えばタクシに乗車するまでの時間）、チェック結果（出動時間が図９の（ａ−１０）の出動時間チェックテーブル５８に登録されている時間以内のときのチェック結果ＯＫ，それ以外は管理者判断結果）である。

図９の（ａ−１２）は、保守員端末電子マネー管理ＤＢ例を示す。保守員端末電子マネー管理ＤＢ６０は、保守員携帯端末８が保持する電子マネーを管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・保守員ＩＤ：
・取引：
・金額：
・取引内容：
・携帯端末残高：
・その他：
ここで、保守員ＩＤは電子マネーを管理する対象の保守員のＩＤである。取引は電子マネーの取引であって、チャージ、支払などである。金額は、チャージあるいは支払った金額である。取引内容は、最初の準備金、障害受付番号などである。携帯端末残高は、電子マネーの残高である。

図１０の（ｂ）は、電子マネー処理サーバで管理するテーブル、ＤＢの例を示す。
図１０の（ｂ−１）は、マネーチャージ履歴ＤＢ例を示す。マネーチャージ履歴ＤＢ７２は、電子マネー処理サーバ７が保守員携帯端末８に電子マネーをチャージしたときの履歴を保存して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・アクセス日時：
・担当保守員：
・障害受付番号：
・チャージ料金：
・処理後会社残高：
・その他：
ここで、アクセス日時は、保守員携帯端末８が電子マネー処理サーバ７にチャージのためのアクセスした日時である。担当保守員、障害受付番号、チャージ料金は、チャージ要求した保守員のＩＤ、障害受付番号、チャージした料金である。処理後会社残高は、電子マネー処理サーバ７で保持する電子マネーの残高である。

図１０の（ｃ）は、保守員携帯端末が管理するテーブル、ＤＢの例を示す。
図１０の（ｃ−１）は、作業依頼情報テーブル例を示す。作業依頼情報テーブル８５は、受信した出動依頼メールの内容を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・担当保守員ＩＤ：
・出動依頼受信日時：
・障害受付番号：
・チャージ用誘導ＵＲＬ：
・その他：
ここで、担当保守員ＩＤは保守員携帯端末８を所持する保守員のＩＤである。出動依頼受信日時は、保守会社システム４から出動依頼メールを受信した日時である。障害受付番号は、出動依頼メールで指示を受けた装置障害に付与された一意の障害受付番号である。チャージ用誘導ＵＲＬは交通費のチャージを受けるために、電子マネー処理サーバ７にアクセスするＵＲＬである。

図１０の（ｃ−２）は、作業指示情報ＤＢ例を示す。作業指示情報ＤＢ８６は、作業指示情報を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・障害受付番号：
・担当保守員ＩＤ：
・障害受付日時：
・障害装置ＩＤ：
・障害内容：
・タクシ乗車場所：
・タクシ降車場所：
・距離：
・タクシ予定料金：
ここで、障害受付番号、担当保守員ＩＤ、障害受付日時、障害装置ＩＤ、障害内容、タクシ乗車場所、タクシ降車場所、距離、タクシ予定料金は、出動依頼メールで保守会社システム４から通知されて指示された情報を登録したものである。

図１０の（ｃ−３）は、携帯端末履歴情報ＤＢ例を示す。携帯端末履歴情報ＤＢ８７は、保守員携帯端末８でタクシに障害など、電子マネーのチャージを受けたなどを登録した管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・担当保守員ＩＤ：
・入出金日時：
・乗車場所：
・乗車日時：
・降車場所：
・降車日時：
・残高：
・ステータス：
・その他：
ここで、担当保守員ＩＤは保守員携帯端末８を所持する保守員のＩＤである。入出金日時、乗車場所、乗車日時、降車場所、降車日時は、電子マネーの入出金日時、タクシなどの実際の乗車場所、乗車日時、降車場所、降車日時である。残高は電子マネーのチャージ、支払した後の残高である。ステータスは、チャージあるいは支払などの区別である。

図１０の（ｄ）は、タクシ会社サーバが管理するテーブル、ＤＢの例を示す。
図１０の（ｄ−１）は、配車依頼受付ＤＢ例を示す。配車依頼受付ＤＢ１４は、タクシ会社サーバ１０が配車依頼メールを受信したときに当該配車依頼メールの内容を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・配車依頼受付日時：
・会社コード：
・担当保守員：
・発場所：
・発住所：
・降車場所：
・降車住所：
・その他：
ここで、配車依頼受付日時、会社コード、担当保守員、発場所、発住所、降車場所、降車住所は、配車依頼メールを受信した受付日時、配車依頼した会社のコード、乗車する担当保守員名（ＩＤ）、乗車場所、乗車住所、降車場所（会社名）、降車住所である。

図１０の（ｄ−２）は、契約会社情報テーブル例を示す。契約会社情報テーブル１５は、タクシ会社が契約した会社の情報を登録したものであって、ここでは、図示の下記の情報を対応づけて登録したものである。

・契約会社名：
・電話番号：
・メールアドレス：
・その他：
ここで、契約会社名、電話番号、メールアドレスは、タクシの配車契約した会社名、その電話番号、担当者への連絡用のメールアドレスである。

図１０の（ｄ−３）は、タクシ出動状況テーブル例を示す。タクシ出動状況テーブル１６は、タクシ毎の現在位置などをリアルタイムに登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・タクシＮＯ：
・ＧＰＳ情報：
・ステータス（空車／実車）：
・メールアドレス：
・その他：
ここで、タクシＮＯはタクシ毎に付与した一意の番号である。ＧＰＳ情報は現在のタクシの位置情報（例えば５分毎の位置情報）である。ステータスはタクシが空車か実車の区別である。メールアドレスはタクシ端末に電子メールを送信するアドレスである。

図１０の（ｅ）は、タクシ端末が管理するテーブル、ＤＢの例を示す。
図１０の（ｅ−１）は、タクシ状況テーブル例を示す。タクシ状況テーブル９６は、タクシの現在位置などを登録して管理するものであって、ここでは、図示の下記の情報を登録して管理するものである。

・タクシＮＯ：
・ステータス：
・ＧＰＳ情報：
・その他：
ここで、タクシＮＯはタクシ端末を設置したタクシのＮＯである。ステータスは、現在、空車、実車の区別である。ＧＰＳ情報は、ＧＰＳ装置から取得した現在位置の情報である。

図１０の（ｅ−２）は、タクシ出動実績ＤＢ例を示す。タクシ出動実績ＤＢ９７は、タクシが保守員などを乗せて走行などした実績を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。

・受付ＮＯ：
・出動依頼メール受信日時：
・会社コード：
・担当保守員ＩＤ：
顧客が乗車時： ・発場所：
・発住所：
・乗車時刻：
顧客が降車時：
・降車場所：
・降車住所：
・降車時刻：
・精算時刻：
・受取金額：
・実績走行距離：
・その他：
ここで、受付ＮＯ、出動依頼メール受信日時、会社コード、担当保守員ＩＤは、出動依頼メールを受信したときの受付ＮＯ、受信日時、出動依頼した会社のコード、乗車する担当保守員ＩＤである。顧客が乗車時の、発場所、発住所、乗車時刻は、顧客である保守担当員が実際に乗車した場所、住所、乗車時刻である。顧客が降車時の、降車場所、降車住所、降車時刻、精算時刻、受取金額、実績走行距離は、顧客である保守担当員が実際に降車した場所、住所、降車時刻、料金を精算した時刻、電子マネーで受け取った金額、実績走行距離である。

図１１は、本発明のメール、画面、リストの例を示す。
図１１の（ａ）は、障害通報の例を示す。これは、顧客の障害発生装置から障害通報メールが送信され、保守会社システム４で受信された例を示す。図示の障害通報メールには、図示の下記の情報が設定されている。

・装置ＩＤ：ＧＰ７−２
・メッセージ：ハードディスクが故障しました。

ここで、受信された障害通報メールが例えば「田中研究所」から送信されたとした場合には、既述した図９の（ａ−１）の顧客ＤＢ４９を参照し、装置ＩＤ：ＧＰ７−２が存在し、顧客住所（新宿１−１−１）と判明し、更に、図９の（ａ−９）の顧客別重要障害テーブル５６を参照し、顧客名「田中研究所」のエントリ中にメッセージ「ハードディスクが故障しました。」がここでは存在し重要障害と判定できる。

図１１の（ｂ）は、保守員端末へ送信する出動依頼メール例を示す。図示の出動依頼メールは、図１１の（ａ）の障害通報メールを保守会社システム４が受信し、保守担当者に送信するメール例である。ここでは、図示の下記の情報を出動依頼メールに設定して送信する。

保守員番号［ＣＥ１２３］殿
障害対応をお願いします。

下記サイトへアクセスし、電子マネーのチャージをお願いします。
指定アドレス：・・・ｗｗｗ．ｃｈａｒｇｅ
乗車場所［新宿待機センター］住所［西新宿２−２−２］
行き先［田中研究所］住所［新宿１−１−１］
距離［２キロメータ］タクシ予定料金［１０００円］
ー障害情報ー
障害受付番号［５５５５５５］
障害受付日時［２００７／４／１ ２３時１０分］
障害内容［ハードディスクが故障しました。］
障害装置ＩＤ［ＧＰ７−２］
図１１の（ｃ）は、電子マネーチャージ例を示す。

図１１の（ｃ−１）は、保守員携帯端末で保守会社システム４へアクセスした場合の画面例を示す。これは、保守員が保守員携帯端末を操作し、保守会社システム４へアクセスしたときに表示される画面例である。画面上からここでは、［電子マネーチャージ］を選択すると、図１１の（ｃ−２）の画面に遷移する（画面がダウンロードされて表示される）。

図１１の（ｃ−２）は、保守員番号などを入力する画面例を示す。ここでは、画面に示すように、下記の情報および入力域を表示する。

入力して下さい。
保守員番号 ［ＣＥ１２３］
障害受付番号［５５５５５５］
パスワード ［＊＊＊＊ ］
図示の入力した状態で、図示外の送信ボタンを押下すると、保守会社システム４が入力した情報をチェックなどし、ＯＫとなると、図１１の（ｃ−３）の画面に遷移する（画面がダウンロードされた表示される）。

図１１の（ｃ−３）は、チャージする内容を確認する画面例を示す。ここでは、画面に示すように、下記の情報を表示して確認を求める。

障害受付番号［５５５５５５］
タクシ予定料金［１０００円］
チャージ金額 ［８００円］
現在の金額［１２００円］
チャージしますか？［はい］［いいえ］
図示の確認情報を表示して確認してＯＫのときに、図示の［はい］ボタンを押下すると、確認した情報（障害受付番号、チャージ金額など）および確認ＯＫの情報が電子マネー処理サーバ７に送信され、電子マネー処理サーバ７が保守員携帯端末に電子マネーをチャージし、チャージが完了すると、図１１の（ｃ−４）の画面に遷移する（画面がダウンロードされた表示される）。そして、チャージ完了したとき、電子マネー処理サーバ７は併せて保守会社システム４にチャージ処理終了と確認した情報とを送信して当該保守会社システム４がチャージ履歴として保存する。

図１１の（ｃ−４）は、チャージ確認の画面例を示す。ここでは、画面に示すように、下記の情報を表示し、チャージ完了を知らせる。

チャージが完了しました。
残額［２０００円］
チャージ日時［２００４／４／１ ２３時１３分］
図１１の（ｄ）は、タクシ会社サーバが受信する配車依頼メール例を示す。ここでは、図示の情報を配車依頼メールで、タクシ会社サーバ１０が受信する。

図１１の（ｅ）は、タクシ端末が受信する出動依頼メールの例を示す。ここでは、図示の情報を出動依頼メールでタクシ端末９が受信する。

図１１の（ｆ）は、降車時に保守員端末によるタクシ端末への支払画面例を示す。ここでは、図示の情報を保守員端末に表示する。

図１１の（ｇ）は、保守員端末による保守会社システムへの乗車実績報告時の画面例を示す。ここでは、図示の情報を保守員端末に表示する。

図１１の（ｈ）は、保守会社システムが出力する報告情報リスト例を示す。ここでは、図示の報告情報リストを保守会社システム４が出力する。

本発明は、夜間などの障害対応時におけるタクシ利用の管理者による承認作業を無くして出動の迅速化を図ると共に、タクシ利用時の乗車実績チェックを簡易に実現し、かつタクシ料金の後日の請求書による支払などの手間を無くす障害受付対応方法および障害受付対応装置に関するものである。

本発明のシステム構成図である。 本発明の動作説明フローチャート（その１）である。 本発明の動作説明フローチャート（その２）である。 本発明の動作説明フローチャート（その３）である。 本発明の動作説明フローチャート（タクシ会社サーバ）である。 本発明の動作説明フローチャート（保守員端末）である。 本発明の動作説明フローチャート（タクシ端末）である。 本発明の動作説明フローチャート（電子マネー処理サーバ）である。 本発明のＤＢ／テーブル例（その１）である。 本発明のＤＢ／テーブル例（その２）である。 本発明のメール、画面、リストの例である。の実施例の説明図である。

符号の説明

１：顧客装置
２：サーバ
３：監視手段
４：保守会社システム
４１：障害通報受付手段
４２：交通料金算出・登録手段
４３：担当保守員依頼手段
４４：電子マネー処理依頼手段
４５：タクシ配車依頼手段
４６：乗車実績チェック手段
４７：携帯残高更新手段
４８：ＤＢ
４９：顧客ＤＢ
５０：装置分類テーブル
５１：保守員ＤＢ
５２：タクシ料金テーブル
５３：配車依頼専用アドレステーブル
５４：タクシ配車判断時間テーブル
５５：チャージ用誘導ＵＲＬテーブル
５６：顧客別重要障害テーブル
５７：重要顧客テーブル
５８：出動時間チェック閾値テーブル
５９：障害受付ＤＢ
６０：保守員端末電子マネー管理ＤＢ
６１：電子メール雛型ＤＢ
７：電子マネー処理サーバ
７１：電子マネー処理手段
７２：マネーチャージ履歴ＤＢ
８：保守員携帯端末
８１：障害対応依頼受信手段
８２：旅費チャージ手段
８３：乗車実績報告手段
８４：ＤＢ
８５：作業依頼情報テーブル
８６：作業指示情報ＤＢ
８７：携帯端末履歴情報ＤＢ
９：タクシ端末
９１：出動依頼受付手段
９２：電子マネー支払処理手段
９３：業務実績報告手段
９４：位置情報取得手段
９５：ＤＢ
９６：タクシ状況テーブル
９７：タクシ出動実績ＤＢ
９８：電子メール雛型ＤＢ
１０：タクシ会社サーバ
１１：配車受付手段
１２：業務実績報告受取手段
１３：ＤＢ
１４：配車依頼受付ＤＢ
１５：契約会社情報テーブル
１６：タクシ出動状況テーブル
１７：電子メール雛型ＤＢ
２１：ネットワーク（インターネットなど）

Claims (5)

1. 顧客装置の障害情報を受け付けて保守員を決定して出動を依頼する障害受付対応方法において、
   コンピュータが備える手段が、
   顧客装置の障害通報を受け付けて受付テーブルに登録するステップと、
   前記受付テーブルに登録した障害情報を解析して保守員出動の承認可否を決定および障害受付番号を採番するステップと、
   前記保守員出動の承認が決定された場合には、前記受付テーブルに登録された前記障害情報をもとに、保守員の担当地区を登録した保守員テーブルを参照して担当保守員を決定、および保守員の待機場所、障害通報のあった顧客装置の場所を登録したテーブルを参照して交通手段を決定し、出動依頼を当該担当保守員に通知するステップと、
   前記交通手段として、タクシと決定された場合には、タクシ会社サーバに配車依頼を通知するステップと、
   前記タクシ会社サーバに配車依頼した時刻と、前記保守員が前記タクシに乗車した時刻との差が一定時間以内のときに乗車実績チェック済と自動判定するステップと
   を実行することを特徴とする障害受付対応方法。
2. 前記受付テーブルに登録した障害情報を解析して顧客装置の重要障害かおよび重要顧客の障害発生かの１つ以上をもとに保守員出動の承認を決定することを特徴とする請求項１記載の障害受付対応方法。
3. 前記受付テーブルに登録した障害情報を解析して深夜帯で電車やバス使用不可かをもとに交通手段をタクシ、あるいは電車やバスのいずれかと決定することを特徴とする請求項１あるいは請求項２記載の障害受付対応方法。
4. 前記タクシ会社サーバに配車依頼を通知した場合には、保守員の待機センタから前記受付テーブルに登録した障害情報をもとに検索した顧客装置の場所までの距離を算出して概算のタクシ料金を計算し、当該概算タクシ料金に相当する電子マネーを当該保守員の端末にチャージあるいはチャージを許可することを特徴とする請求項１から請求項３のいずれかに記載の障害受付対応方法。
5. 顧客装置の障害情報を受け付けて保守員を決定して出動を依頼する障害受付対応装置において、
   顧客装置の障害通報を受け付けて受付テーブルに登録する手段と、
   前記受付テーブルに登録した障害情報を解析して保守員出動の承認可否を決定および障害受付番号を採番する手段と、
   前記保守員出動の承認が決定された場合には、前記受付テーブルに登録された前記障害情報をもとに、保守員の担当地区を登録した保守員テーブルを参照して担当保守員を決定、および保守員の待機場所、障害通報のあった顧客装置の場所を登録したテーブルを参照して交通手段を決定し、出動依頼を当該担当保守員に通知する手段と、
   前記交通手段として、タクシと決定された場合には、タクシ会社サーバに配車依頼を通知する手段と、
   前記タクシ会社サーバに配車依頼した時刻と、前記保守員が前記タクシに乗車した時刻との差が一定時間以内のときに乗車実績チェック済と自動判定する手段と
   を備えたことを特徴とする障害受付対応装置。

Images