図面 (/)

技術 情報伝達システム、情報伝達方法及び情報伝達プログラム

出願人 株式会社日立システムズ
発明者 高畑勇細木裕高島俊哉篠原大輔
出願日 2014年10月31日 (6年0ヶ月経過) 出願番号 2014-222277
公開日 2016年5月23日 (4年5ヶ月経過) 公開番号 2016-091143
状態 特許登録済
技術分野 デバッグ/監視 特定用途計算機
主要キーワード 障害現象 監視ループ 最終ダイ 伝達環 対応要求 伝達データ 同一ダイ 待機者
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年5月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

本発明では、ユーザから依頼内容に対し、適切な対応要員の迅速な選別と依頼内容の伝達を可能とする情報伝達システムを提供する。

解決手段

本発明の情報伝達システムでは、対応要員へ受け付けた依頼内容の一部を含む第1の対応要求を第1の情報通信部で伝達し、第1の対応要求から第1の所定時間が経過した後、第2の対応要求を第2の情報通信部で伝達し、第2の対応要求から第2の所定時間が経過しても第2の対応要求に対する応答が無い場合、次の対応要員へ対応要求を伝達する。

概要

背景

汎用コンピュータサーバなどから構成される情報処理システムを用いたオンラインシステムでは、昼夜を問わず24時間365日常稼働し、停止することのなく使用されることが多い。そのために、このような情報処理システムには、高い信頼性と可用性が求められている。情報処理システムの可用性を向上させるには、システムを構成する機器、例えば、コンピュータやサーバなどを冗長化する方法がある。この冗長化は、ある機器に故障などの障害が発生した場合においても、他の機器が業務を引き継ぐことで、業務サービスの停止を防止することができる。また、この冗長化で迅速に障害機器切り離すことができ、故障した機器の業務サービスへの影響を最小限に留めて、正常な機器で業務サービスを継続させることができる。

しかしながら、どのような高い信頼性と可用性なシステムを構築しても障害は必ず発生し、最悪の場合システムがダウンする可能性もある。情報処理システムに障害が発生しシステムがダウンしたときには、できるだけ早急に復旧させることが必要である。また、システムダウンが発生しなくとも、障害が発生した機器を早急に交換し、障害が他の機器に伝播しないようにする必要がある。

このような障害発生時に対するため、従来では、情報処理システムにシステム障害が発生した場合、情報処理システムのユーザが障害の発生した箇所に応じて、保守サービス提供会社電話電子メール等で連絡して、障害箇所修理や交換をしてもらっていた。また、保守サービス提供会社では、連絡を受けたオペレータが適切な保守員選別し、その保守員にメールや電話等で保守依頼を行っていた。これに関する技術としては、特許文献1記載のものがある。特許文献1記載の従来技術は、適切な保守員を迅速に障害発生装置あるいはシステムに向かわせることができる障害通報システムを提供するため、あらかじめ記憶テーブルに順次保守員を記憶しておき、応答がなかったときに次の保守員を呼び出すものである。

概要

本発明では、ユーザから依頼内容に対し、適切な対応要員の迅速な選別と依頼内容の伝達を可能とする情報伝達システムを提供する。本発明の情報伝達システムでは、対応要員へ受け付けた依頼内容の一部を含む第1の対応要求を第1の情報通信部で伝達し、第1の対応要求から第1の所定時間が経過した後、第2の対応要求を第2の情報通信部で伝達し、第2の対応要求から第2の所定時間が経過しても第2の対応要求に対する応答が無い場合、次の対応要員へ対応要求を伝達する。

目的

特許文献1記載の従来技術は、適切な保守員を迅速に障害発生装置あるいはシステムに向かわせることができる障害通報システムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ユーザからの受け付け対応要求情報対応要員連絡する情報伝達システムであって、前記情報伝達システムは、システム全体を制御するCPUと、前記対応要求情報を受け付ける受付部と、前記対応要求情報を格納するメモリと、前記対応要求情報を伝達する第1の情報通信部と、前記対応要求情報を伝達する第2の情報通信部とを備え、前記CPUが、前記対応依頼情報の一部を含む第1の対応要求を前記第1の情報通信部で前記対応要員へ伝達し、前記第1の対応要求から第1の所定時間が経過した後、第2の対応要求を前記第2の情報通信部で前記対応要員へ伝達し、前記第2の対応要求から第2の所定時間が経過しても、前記第1ないし第2の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達することを特徴とする情報伝達システム。

請求項2

請求項1記載の情報伝達システムであって、前記第1の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第1の対応要求を前記電子メールで前記対応要員へ行うことを特徴とする情報伝達システム。

請求項3

請求項2記載の情報伝達システムであって、前記第2の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第2の対応要求を前記電話回線で前記対応要員へ行うことを特徴とする情報伝達システム。

請求項4

請求項3記載の情報伝達システムであって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納されることを特徴とする情報伝達システム。

請求項5

請求項4記載の情報伝達システムであって、前記対応要員が2人以上存在する場合、全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達することを特徴とする情報伝達システム。

請求項6

請求項4記載の情報伝達システムであって、前記対応要員が2人以上存在する場合、全員に前記電子メールを同報した後、前記対応要員へ同時に前記電話回線で情報を伝達することを特徴とする情報伝達システム。

請求項7

請求項4記載の情報伝達システムであって、前記第2の対応要求に対する応答は、前記電話回線に接続された電話ダイヤル入力で行い、前記応答には2種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、前記割り当てられた電話のダイヤル入力同士が隣接せず、前記第2の対応要求毎に前記電話のダイヤル入力をランダムに変更することを特徴とする情報伝達システム。

請求項8

請求項7記載の情報伝達システムであって、前記対応要員が保守会社における保守員であることを特徴とする情報伝達システム。

請求項9

ユーザからの受け付けた対応要求情報を対応要員へ連絡する情報伝達システムの情報伝達方法であって、前記情報伝達システムは、システム全体を制御するCPUと、前記対応要求情報を受け付ける受付部と、前記対応要求情報を格納するメモリと、前記対応要求情報を伝達する第1の情報通信部と、前記対応要求情報を伝達する第2の情報通信部とを備え、前記CPUが、前記対応依頼情報の一部を含む第1の対応要求を前記第1の情報通信部で前記対応要員へ伝達し、前記第1の対応要求から第1の所定時間が経過した後、第2の対応要求を前記第2の情報通信部で前記対応要員へ伝達し、前記第2の対応要求から第2の所定時間が経過しても、前記第1ないし第2の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達することを特徴とする情報伝達システムの情報伝達方法。

請求項10

請求項9記載の情報伝達システムの情報伝達方法であって、前記第1の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第1の対応要求を前記電子メールで前記対応要員へ行うことを特徴とする情報伝達システムの情報伝達方法。

請求項11

請求項10記載の情報伝達システムの情報伝達方法であって、前記第2の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第2の対応要求を前記電話回線で前記対応要員へ行うことを特徴とする情報伝達システムの情報伝達方法。

請求項12

請求項11記載の情報伝達システムの情報伝達方法であって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納されることを特徴とする情報伝達システムの情報伝達方法。

請求項13

請求項12記載の情報伝達システムの情報伝達方法であって、前記対応要員が2人以上存在する場合、全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達することを特徴とする情報伝達システムの情報伝達方法。

請求項14

請求項12記載の情報伝達システムの情報伝達方法であって、前記対応要員が2人以上存在する場合、全員に前記電子メールを同報した後、前記対応要員へ同時に前記電話回線で情報を伝達することを特徴とする情報伝達システムの情報伝達方法。

請求項15

請求項12記載の情報伝達システムの情報伝達方法であって、前記第2の対応要求に対する応答は、前記電話回線に接続された電話のダイヤル入力で行い、前記応答には2種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、前記割り当てられた電話のダイヤル入力同士が隣接せず、前記第2の対応要求毎に前記電話のダイヤル入力をランダムに変更することを特徴とする情報伝達システムの情報伝達方法。

請求項16

請求項15記載の情報伝達システムの情報伝達方法であって、前記対応要員が保守会社における保守員であることを特徴とする情報伝達システムの情報伝達方法。

請求項17

ユーザからの受け付けた対応要求情報を対応要員へ連絡する情報伝達システムで動作する情報伝達プログラムであって、前記情報伝達システムは、システム全体を制御するCPUと、前記対応要求情報を受け付ける受付部と、前記対応要求情報を格納するメモリと、前記対応要求情報を伝達する第1の情報通信部と、前記対応要求情報を伝達する第2の情報通信部とを備え、前記CPUで、前記対応依頼情報の一部を含む第1の対応要求を前記第1の情報通信部で前記対応要員へ伝達する機能と、前記第1の対応要求から第1の所定時間が経過した後、第2の対応要求を前記第2の情報通信部で前記対応要員へ伝達する機能と、前記第2の対応要求から第2の所定時間が経過しても、前記第1ないし第2の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達する機能とを有することを特徴とする情報伝達システムの情報伝達プログラム。

請求項18

請求項1記載の情報伝達システムで動作する情報伝達プログラムであって、前記第1の情報通信部で、インターネット網に接続され電子メールの送受信を行う機能と、前記第1の対応要求を前記電子メールで前記対応要員へ行う機能とを有することを特徴とする情報伝達システムの情報伝達プログラム。

請求項19

請求項2記載の情報伝達システムで動作する情報伝達プログラムであって、前記第2の情報通信部で、公衆電話回線網に接続され電話回線での通信を行う機能と、前記第2の対応要求を前記電話回線で前記対応要員へ行う機能とを有することを特徴とする情報伝達システムの情報伝達プログラム。

技術分野

0001

本発明は、情報伝達システム情報伝達方法及び情報伝達プログラムに関する。

背景技術

0002

汎用コンピュータサーバなどから構成される情報処理システムを用いたオンラインシステムでは、昼夜を問わず24時間365日常稼働し、停止することのなく使用されることが多い。そのために、このような情報処理システムには、高い信頼性と可用性が求められている。情報処理システムの可用性を向上させるには、システムを構成する機器、例えば、コンピュータやサーバなどを冗長化する方法がある。この冗長化は、ある機器に故障などの障害が発生した場合においても、他の機器が業務を引き継ぐことで、業務サービスの停止を防止することができる。また、この冗長化で迅速に障害機器切り離すことができ、故障した機器の業務サービスへの影響を最小限に留めて、正常な機器で業務サービスを継続させることができる。

0003

しかしながら、どのような高い信頼性と可用性なシステムを構築しても障害は必ず発生し、最悪の場合システムがダウンする可能性もある。情報処理システムに障害が発生しシステムがダウンしたときには、できるだけ早急に復旧させることが必要である。また、システムダウンが発生しなくとも、障害が発生した機器を早急に交換し、障害が他の機器に伝播しないようにする必要がある。

0004

このような障害発生時に対するため、従来では、情報処理システムにシステム障害が発生した場合、情報処理システムのユーザが障害の発生した箇所に応じて、保守サービス提供会社電話電子メール等で連絡して、障害箇所修理や交換をしてもらっていた。また、保守サービス提供会社では、連絡を受けたオペレータが適切な保守員選別し、その保守員にメールや電話等で保守依頼を行っていた。これに関する技術としては、特許文献1記載のものがある。特許文献1記載の従来技術は、適切な保守員を迅速に障害発生装置あるいはシステムに向かわせることができる障害通報システムを提供するため、あらかじめ記憶テーブルに順次保守員を記憶しておき、応答がなかったときに次の保守員を呼び出すものである。

先行技術

0005

特開平08−314761号公報

発明が解決しようとする課題

0006

特許文献1の障害通報システムでは、ユーザからの保守依頼について、対応する手段に関する開示がない。そのため、定型的な保守対応はできても、ユーザが直接依頼する障害への保守には対応できない。そこで、保守会社にオペレータを常駐させ、保守依頼を受け付けることが考えられる。しかしながら、夜間/休日の受付体制は、どの受付部署に置いても最低限の人数のオペレータで保守依頼の受付を処理している。そのため、待機している保守員で、1番目の保守員に連絡が付かないと2番目の保守員に連絡する。もし、2番目の保守員にも連絡が付かないと3番目、4番目と保守員への連絡をオペレータが行い、1つのユーザからの保守依頼に長時間オペレータが拘束され、他のオペレータの負荷が高くなり、別のユーザからの保守依頼を受け付けられなくなる可能性が高くなるという問題がある。そこで、本発明では、ユーザから直接、依頼のあった保守に対し、迅速な保守員の選別と依頼保守内容の伝達を可能とする情報伝達システムを提供することを目的とする。

課題を解決するための手段

0007

上記課題を解決するために、代表的な本発明の情報伝達システムでは、待機保守員へ受け付けた保守依頼内容の一部を含む第1の保守対応要求を第1の情報通信部で伝達し、第1の対応要求から第1の所定時間が経過した後、第2の保守対応要求を第2の情報通信部で伝達し、第2の対応要求から第2の所定時間が経過しても第1ないし第2の保守対応要求に対する応答が無い場合、次の待機保守員へ保守対応要求を伝達する。

発明の効果

0008

本発明では、ユーザ直接の保守依頼への対応時間を短縮することができ、ユーザ満足度を向上できる。なお、前述以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

図面の簡単な説明

0009

図1は、本発明の情報伝達システム1の全体構成を示すブロック図である。
図2は、情報伝達システム1でのサーバ/端末の内部構成を示すブロック図である。
図3は、第1の待機者管理テーブル30の構成例を示す図である。
図4は、第2の待機者管理テーブル40の構成例を示す図である。
図5は、連絡環境管理テーブル50の構成例を示す図である。
図6aは、第1の連絡結果管理テーブル61の構成例を示す図である。
図6bは、第2の連絡結果管理テーブル62の構成例を示す図である。
図7は、連絡者検索結果の表示画面70の構成例を示す図である。
図8は、送信メールに関する情報を示す図である。
図9は、第1の自動連絡結果例の表示画面の構成例90を示す図である。
図10は、第2の自動連絡結果例の表示画面100の構成例を示す図である。
図11は、待機者への連絡処理を示すフローチャート図である。
図12は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。
図13は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。
図14は、メール送信処理を示すフローチャート図である。
図15は、連絡中止処理を示すフローチャート図である。

実施例

0010

以下、図面を参照しながら実施の形態を説明する。なお、実施例の説明では、保守会社などの待機保守員に対する情報伝達を例とするが、巡回保守員などへの情報伝達でもよく、また、運送会社運送員、ビル管理会社警備員などへの情報伝達にも用いることができる。また、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。

0011

また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、MP(Micro Processor)やCPU(Central Processing Unit)によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源(例えばメモリ)及び通信インターフェース装置(例えば、通信ポート)を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、CPUの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであっても良い。

0012

また、各要素、例えば、コントローラは番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。本実施例の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。

0013

<情報伝達システム全体構成>図1
図1は、本発明の情報伝達システム1の全体構成を示すブロック図である。情報伝達システム1は、サーバ11、オペレータ端末12、電話交換機PBX:Private Branch eXchange)113/118から構成する。また、サーバ11は、保守拠点13とイントラネット14で接続し、待機保守員1030が所持する携帯用機器携帯電話多機能タブレットなど)とインターネット網1002や公衆回線網1012で接続する。更に、サーバ11は、保守契約者1020(保守契約者の端末やサーバなど)とインターネット網1001や公衆回線網1011で接続する。

0014

サーバ11は、伝達情報生成部111、保守依頼受付部112、メール作成部114、連絡者登録部115、連絡者作成部116、連絡部117より構成する。なお、各部をハードウェアで構成してもよいし、後述するCPU上で動作するプログラムでもよい。

0015

オペレータ端末12は、保守契約者1020(ユーザ1020、1021など)から公衆回線網1011経由PBX113から保守依頼を受け付けるための端末で、サーバ11にも接続され待機保守員の情報や待機保守員への伝達情報の内容を閲覧するなどの機能を有する端末で、保守依頼受付部署のオペレータにより操作される。

0016

サーバ11の保守依頼受付部112は、保守契約者1020(ユーザ1020、1021など)からインターネット網1001ないし公衆回線網1011経由PBX113から受信した保守依頼を受け付ける機能部である。保守依頼受付部112には受け付けた保守依頼内容を管理する保守依頼DB1121があり、保守依頼DB1121が、後述する記憶装置(メモリないしHDDなどの記憶部)に格納される。保守依頼DB1121には、“障害受付日時”、“お客様名”、“お客様部署名”、“保守契約形態”、“保守対応機種”、“型名/製造番号”、“障害現象”、“お客様住所”などの情報が格納される。これらの情報が、伝達情報生成部111や連絡部117に送られ、送信メールの生成や情報伝達先及び方法が決定される。

0017

伝達情報生成部111は、保守依頼受付部112から受け付けた保守内容から待機保守員1030(保守員1031、1032、1033など)やオペレータ端末12を操作するオペレータに伝達する情報を生成する機能部である。伝達情報生成部111には、生成した伝達情報を管理する伝達情報DB1111があり、記憶装置に格納される。メール作成部114は、待機保守員1030に送信するための電子メールを作成する機能部である。作成する電子メールの内容は、伝達情報生成部111で生成された伝達情報を中心に構成される。詳細な内容については後述(図8)する。なお、メール作成部114で作成された電子メールは、連絡部117に送られ、連絡情報DB1171に格納される。

0018

連絡者登録部115は、保守拠点13(拠点1301、1302など)から登録された待機保守員の情報、すなわち情報を伝達し連絡する連絡者を登録するための機能部である。登録された待機保守員の情報が連絡者DB1151として、記憶装置等に格納される。連絡者作成部116は、後述(図4ないし図7)する待機者管理テーブルや待機者一覧情報などを作成する機能部である。作成された待機者管理テーブルや待機者一覧情報などは、連絡部117の連絡情報DB1171に格納される。

0019

連絡部117は、待機保守員1030(保守員1031、1032、1033など)へ電子メール送信電話連絡を行い、また、連絡した待機保守員1030からの応答を受け付ける機能部である。待機保守員1030への連絡情報は連絡情報DB1171として、待機保守員1030からの応答結果は連絡結果DB1172として記憶装置等に格納される。

0020

本発明の実施形態の情報伝達システム1では、以上のように保守拠点13からの待機保守員情報の登録、保守契約者1020からの保守依頼受付、待機保守員1030への依頼保守内容の連絡と応答の確認により、ユーザから直接、依頼のあった保守に対し、迅速な保守員の選別と依頼保守内容の伝達を可能とするものである。

0021

<装置内部構成>図2
図2は、情報伝達システム1でのサーバ11/端末12の内部構成を示すブロック図である。サーバ11及び端末12は、CPU21、メモリ22、記憶部23、入力部24、出力部25、表示部26、通信部27を備える。

0022

CPU21は、装置全体を制御するプロセッサである。メモリ22は、各種プログラム及び後述する各種データ(テーブル)などを一時的に記憶するデバイスである。記憶部23は、各種プログラム及び後述する各種データなどを恒久的に記憶するデバイスで、例えばHDDやSSDである。入力部24は、入力を受け付けるデバイスで、例えば、キーボードである。

0023

出力部25は、情報やデータを出力するデバイスで、例えば、スピーカプリンタである。表示部26は、情報やデータを表示するデバイスで、例えば、液晶ディスプレイである。通信部27は、ネットワーク(図示せず)を介し他のサーバや他の装置との間を接続するデバイスである。以上の構成要素は内部バスで相互に接続される。なお、入力部34、出力部35、表示部36のいずれかを各装置に備えない構成とすることもできる。

0024

<待機者管理テーブル>図3図4
図3は、第1の待機者管理テーブル30の構成例を示す図である。図4は、第2の待機者管理テーブル40の構成例を示す図である。待機者管理テーブル30は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、保守拠点毎に本テーブルが作成される。また、受け付けた保守依頼内容で本待機者管理テーブル30が更新される。待機者管理テーブル40は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、待機保守員毎に本テーブルが作成される。

0025

待機者管理テーブル30は、#(管理番号)301、項目名302、設定値格納値303から構成される。 項目名302に対応に対する設定値/格納値303には、各種情報がテーブル作成時に設定ないし保守依頼受付時に格納され管理される。なお、待機者管理テーブル30は、連絡部117の連絡情報DB1171に格納される。

0026

待機者管理テーブル30の項目名302の例として、図3のように保守待機者を管理している情報を一意識別するための“待機者認識番号”、本テーブルの作成日時を一意に特定する“作成日時”、保守待機者への連絡方法を特定する“連絡区分(0:通常(1名毎メール送信→電話連絡)、1:特殊1(メール送信/全員同時、電話/順番)、2:特殊2(メール送信/全員同時、電話/実施せず)など)”、“通報者数”、“保守拠点(拠点コード)”、“保守先名称(障害連絡時に格納)、保守先部署名(障害連絡時に格納)”、“送信メールタイトル”、“送信メール内容(障害連絡時に格納)”、“発信電話番号”、“音声再生内容(障害連絡時に格納)”、“緊急度(A:高(最優先・至急)、B:中(優先)、C:低(障害連絡時に格納))”などである。

0027

また、項目名302に対応する設定値/格納値303の例として、“T1406A3982−20140707105521”、“2014/07/07 10:55:21(YYYY/MM/DDhh:mm:ss)”、“0”、“4名”、“拠点1302(ZDL7)”、“A電機”、“Bデータセンタ”、“待機者連絡システムよりの障害対応依頼”、“A電機様のBデータセンタのサーバ(製造番号:HS1234ABC)に障害が発生しました。主な障害現象は、リブートの繰り返しです。その他の障害現象は・・・”、“123−4567−8901”、“A電機様のBデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話の“Aボタン”を押してください。オペレータ転送希望の場合は、“Bボタン”を押してください。”、“B”などである。なお、#1の“待機者認識番号”での“T1406A3982−20140707105521”には、“20140707105521(2014/07/07 10:55:21)”というテーブル作成時刻情報も付加されている。

0028

待機者管理テーブル30の#1から#5に対応する情報は、連絡者DB1151の情報を連絡者作成部116で加工し生成された情報が格納される。また、#6、#7、#9、#11、#12は、保守依頼受付部112からの保守依頼内容の情報が格納される。

0029

待機者管理テーブル40は、#(管理番号)401、項目名402、設定値403から構成される。項目名402に対応する設定値403に各種情報がテーブル作成時に設定される。なお、 待機者管理テーブル40は、連絡者登録部1151の連絡者DB1151に格納される。

0030

待機者管理テーブル40の項目名402の例として、図4のように、待機保守員を一意に識別するための“待機者認識番号”、本テーブルの生成日時である“作成日時”、連絡の順番を特定する“優先順位”、待機保守員を社員として一意に識別するための“社員認識番号”、“氏名”、“フリガナ”、“連絡先電話番号”、“メールアドレス”、“保守拠点名(コード)”、保守拠点での“部課コード”、保守拠点での“グループ名”、“その他”などである。

0031

項目名402に対応する設定値/格納値403の例として、“T1406A3982−20140707085921”、“2014/07/04 10:55:21(YYYY/MM/DDhh:mm:ss)”、“2”、“H677850015A”、“C山G”、“シーヤマジーオ”、“111−2222−3333”、“cyamago222@def333.netw”、“拠点1302(ZDL7)”、“CRC99”、“7G”、“ローテーショングループ2”などである。

0032

<連絡環境管理テーブル>図5
図5は、連絡環境管理テーブル50の構成例を示す図である。連絡環境管理テーブル50は、障害情報の伝達手段毎に設定される伝達環境情報(連絡回数上限、許容エラー回数、待機時間上限など)を管理するテーブルである。連絡環境管理テーブル50は、#(管理番号)501、項目名502、設定値503から構成される。なお、連絡環境管理テーブル50は、連絡部117の連絡情報DB1171などに格納される。

0033

連絡環境管理テーブル50の項目名502として、“連絡監視ループ秒数”、“発信利用回線番号”、“連絡ループ(繰り返し)回数”、“ダイヤルエラー回数”、“話し中時の待機秒数”、“電話発信秒数”、“ダイヤル入力待機秒数”、“メール送信リトライ回数”、“メール送信後の待機秒数”などである。

0034

“連絡監視ループ秒数”には、連絡処理を正常に行われているかを判断する間隔(時間)が設定される。もし、異常が発生している場合、情報伝達システム1のサーバ11は、後述する待機保守員への連絡処理(図11)を初期化し、再度最初から連絡処理を実行する。

0035

“発信利用回線番号”には、待機保守員への電子メール送信に使用する通信部のポート番号ないし電話連絡で使用するPBX118のポート番号が設定される。“連絡ループ(繰り返し)回数” には、電子メールの送信から電話連絡までの情報伝達回数(連絡回数)数が設定される。“ダイヤルエラー回数” には、電話連絡のダイヤルでのエラー(話し中、電源FF等)発生時に、再度電話連絡のダイヤルを行う回数の上限が設定される。つまり、許容するダイヤルエラーの上限回数を、“ダイヤルエラー回数”に設定する。

0036

“話し中時の待機秒数”には、電話連絡時に待機保守員の携帯電話が“話し中”状態であれば、次にダイヤルするまでの待機時間が設定される。“電話発信秒数” には、電話連絡時に電話への発信状態(呼び出し状態)を継続する時間が設定される。“ダイヤル入力待機秒数” には、電話が通じた状態になり音声ガイダンスによるダイヤル入力要求に対しダイヤル入力が完了するまでの待機時間の上限値が設定される。この設定値の待機時間を超えた場合は、ダイヤル入力がされないエラーが発生したと情報伝達システム1(ないしサーバ11)は判断する。

0037

“メール送信リトライ回数”には、電子メールの送信回数が設定される。これは、送信エラーの発生や、携帯電話への1回のメール受信では、待機保守員がメールを受信したことが気づかない場合があるので、複数回のメール送信回数、つまりメール送信リトライ回数を設定しメール受信状況を待機保守員が確実に把握できるようにする。“メール送信後の待機秒数” には、メール送信後に電話連絡をするまでの待機時間が設定される。これは、前述のようにメール送信エラー発生時の再送信時間や、受信メールの内容の確認時間が必要なため、メール送信後に電話連絡をするまでの待機時間を設けて、待機保守員への連絡を確実に取れるようにする。

0038

項目名502に対応する設定値/格納値503として、“30秒”、“ポート55番”、“3回”、“5回”、“180秒(3分)”、“30秒”、“25秒”、“2回”、“60秒”などである。

0039

<連絡結果管理テーブル>図6a図6b
図6aは、第1の連絡結果管理テーブル61の構成例を示す図である。図6bは、第2の連絡結果管理テーブル62の構成例を示す図である。連絡結果管理テーブル61は、保守依頼に対する保守対応の詳細情報を管理するテーブルで、連絡結果管理テーブル62は連絡結果管理テーブル61での主要部分の情報を抽出し管理するテーブルである。連絡結果管理テーブル61及び連絡結果管理テーブル62は、連絡部117の連絡情報DB1171などに格納される。

0040

連絡結果管理テーブル61は、#(管理番号)611、項目名612及び設定値/格納値613から構成される。項目名612の例として、依頼された保守を一意に識別するための“保守案件番号”、“作成日時”、“優先順位”、“保守拠点名(コード)”、“部課コード”、“グループ名”、“社員認識番号”、“氏名”、“連絡媒体(1:メール、2:電話)”、“連絡媒体(1:メール、2:電話)”、“メール連絡結果(0:正常、0以外:異常)”、“電話連絡回数”、“電話連絡結果(0:ダイヤル入力値確認で成功、1:オペレータ転送で成功、2:オペレータ転送失敗、3:不在、4:話し中、5:途中切断、6:回線異常、7:電源OFF・電波状態異常)”、“ダイヤル入力正解値(受信確認)”、“ダイヤル入力正解値(オペレータ転送)”、“最終ダイヤル入力値”などである。

0041

項目名612に対応する設定値/格納値613として、“T1406A3982−20140707XYZ”、“2014/07/07 22:54:21(YYYY/MM/DDhh:mm:ss)”、“2番”、“拠点1302(ZDL7)”、“CRC99”、“7G”、“H677850015A”、“C山G男”、“2(電話)”、“1”、“0(正常)”、“2”、“0(ダイヤル入力正解値(受信確認))”、“1”、“3”、“1”である。なお、#1の“保守案件番号”の設定値/格納値613である“T1406A3982−20140707XYZ”は、前述の“待機者認識番号”で時刻情報の代わりに“XYZ”という保守依頼の管理番号を付加したものである。これにより、各テーブルの関係を情報伝達システム1が認識することができる。

0042

なお、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値と、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値とは、誤入力を防止するため隣接した番号ではなく離れた異なった番号とする。例えば、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値が“1”であれば、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値は“2”を挟んだ“3”ないし“5”を挟んだ“9”とする。また、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値が“2”であれば、#15の“ダイヤル入力正解値(オペレータ転送)” でのダイヤル入力正解値は“5”及び“8”を挟んだ“0”とする。また、#14の“ダイヤル入力正解値(受信確認)”でのダイヤル入力正解値と、#15の“ダイヤル入力正解値(オペレータ転送)”は、電話連絡毎にランダムに変更することで、誤入力を防止する。但し、このランダムでの変更時も隣接したダイヤル番号同一ダイヤル番号も含め)が選択されないようにする。

0043

連絡結果管理テーブル62は、#(管理番号)621、項目名622、設定値/格納値623を備える。項目名622の例として、“保守案件番号”、“作成日時”、“全体最終結果(0:成功、90:異常終了、91:中断ボタンが押下され、処理中止、92:規定回数、連絡処理を実行したが連絡者なし)”、“全体最終結果更新日時”などである。

0044

項目名622に対応する設定値/格納値623は、“T1406A3982−20140707XYZ”、 “2014/07/07 22:54:21(YYYY/MM/DDhh:mm:ss)”、“0”、“2014/07/07 22:57:35(YYYY/MM/DD hh:mm:ss)”である。

0045

<連絡者検索結果の表示画面>図7
図7は、連絡者検索結果の表示画面70の構成例を示す図である。連絡者検索結果の表示画面70は、
待機部署を検索するための条件(検索条件)71、検索条件71に対応する検索の結果である検索結果72(休日の待機保守員情報72)及び検索結果73(夜間の待機保守員情報73)、連絡条件74が表示される。

0046

情報伝達システム1は、検索条件71として“拠点コード:ZDL7”、“部課コード:CRC99”、“グループ:9G”が入力部24で入力されると、オペレータ端末12の表示部26などに、休日での待機保守員情報72及び夜間での待機保守員情報73が表示する。その待機保守員情報72及び待機保守員情報73には、“日付情報”、“連絡条件”、“優先順位番号(1〜4)”及び“連絡者氏名”、“連絡者の電話番号”、“メール及び電話での連絡選択条件(1:メール&電話、2:メールのみ)”及び“送信メールアドレス”が表示される。

0047

連絡条件74として、“1”は“1名毎、順番にメール送信と電話連絡を実施”を表し、“2”は“メールを全員へ同時に送信後、順番に電話連絡を実施”を表し、“3”は“メールを全員へ同時に送信後、電話連絡を実施しない”を表す。また、情報伝達システム1は、“2014/7/6(日)”の休日での保守対応では、連絡条件74が“1”であるの“1名毎、順番にメール送信と電話連絡を実施”を行い、優先順位が“1”である“B田F道”(電話番号:111−2222−99991、メール:bdenfmichi111@abc222.netw)に対し、メール及び電話での連絡選択条件(1:メール&電話)に従い連絡(情報伝達)をまず実行する。連絡が取れない場合、情報伝達システム1は、優先順位番号2の“C山G男”に連絡を実施する。以下、優先順位番号が“4”までの待機保守員に対し連絡を取れるまで連絡を実行する。また、情報伝達システム1は、“2014/7/7(月)”の平日夜間での保守対応も、“2014/7/6(日)”の休日での保守対応と同様な連絡を実行する。

0048

送信メール情報図8
図8は、送信メールに関する情報を示す図である。送信メール80の例として、メール送信先81、送信メールヘッダ情報82、メール本文83から構成される。メール送信先81は、図7で示した優先順位番号に従った第1連絡者から第4連絡者の氏名と送信メールアドレスで構成される。例えば、第1連絡者は“B田F道”で、送信先メールアドレスは“bdenfmichi111@abc222.netw”である。

0049

送信メールヘッダ情報82は、送信日時、題名、送信元メールアドレスを備え、図8のように、例えば、送信日時が“2014/7/7 22:52:30”、題名が“保守受付拠点への依頼(障害連絡)”、送信元メールアドレスとして、“Supervisor@Maintenance−master.wwwnetw”という情報が、送信メール80に付加されている。

0050

メール本文83の項目の例として、“障害受付日時”、“お客様名”、“お客様部署名”、“保守契約形態”、“保守拠点(コード)”、“部課コード(グループ)”、“保守対応機種”、“型名/製造番号”、“障害現象”、“お客様住所”がある。
また、メール本文83の項目に対応する内容(待機保守員への伝達情報の内容)として、“2014/7/7 22:51:59”、“A電機”、“Bデータセンタ”、“X:標準出張保守契約”、“拠点1302(ZDL7)”、“CRC99(7G)”、“EXサーバ”、“Type−FloraPrius/HS1234ABC”、“リブート繰り返し/メモリエラー”、“東京都S区XXAA−BB−CC DビルE階”、“0055−2458−9876−内線2245”がある。

0051

<自動連絡結果の表示画面>図9図10
図9は、第1の自動連絡結果例の表示画面の構成例90を示す図である。図10は、第2の自動連絡結果例の表示画面の構成例100を示す図である。自動連絡結果の表示画面構成90として、連絡先の検索条件91と、その検索条件91に対応する連絡結果を表示する。図9の例では、連絡結果1(符号92)及び連絡結果2(符号93)を表示しているが、実際にはどちらか一方がオペレータ端末12の表示部26に表示される。情報伝達処理(連絡処理)を中止するための中断ボタン94も備える。

0052

検索条件91(拠点コード:ZDL7、部課コード:CRC99、グループ:9G)の入力が完了し、情報伝達システム1(サーバ11)の入力部で入力情報が受け付けられると、オペレータ端末12やサーバ11の表示部26に、検索条件91とそれに対応する連絡結果が表示される。

0053

連絡結果1(符号92)を説明する。情報伝達システム1は、第1連絡者の“B田F道”へのメール送信が“2014/7/7 22:53:30”に完了し、送信完了の1分後(通話時刻1が“22:54:31”)に電話連絡したが、“不在”であった。そこで、情報伝達システム1は、第2連絡者である“C山G男”へ“22:55:02”にメールを送信し、“22:56:03”に電話連絡を行ったが、“不在”であった。そのため、情報伝達システム1は、第3連絡者である“D海H”へ“22:56:34”にメールを送信し、“22:57:35”に電話連絡を行い通話ができ、保守依頼内容という情報の伝達を完了した。その結果が、符号92に示す連絡結果1である。

0054

次に、連絡結果2(符号93)を説明する。連絡結果2では、第1連絡者から第4連絡者までの1回目の電話連絡が“不在”で通話できなかったため、再度第1連絡者他に対し電話連絡を行ったものである。その結果、第1連絡者は“不在”、第2連絡者は“話し中で規定時間経過”したため、第3連絡者に電話連絡し保守依頼内容を伝達できたものである。

0055

次に、第2の自動連絡結果例の表示画面構成100を説明する。表示画面構成例100は、検索条件101と、入力された検索条件101に対する検索結果102で構成する。検索条件101への入力項目は、保守依頼を受け付けた期間、保守拠点を一意に識別する保守拠点コード、保守契約者1020からの問合せNo(保守依頼番号)である。図10での検索条件101は、期間が“2014/7/6−2014/7/7”で、拠点コード及び問合せNoは“指定なし”である。

0056

検索結果102の項目は、#(管理番号)、連絡部署、拠点コード、連絡者、最終連絡結果、問合せ番号、お客様名、連絡開始日時である。例えば、#(管理番号)が“1”である情報伝達結果(自動連絡結果)は、
連絡部署が“CRC99”、拠点コードが“ZDL7”である連絡者“3rd_D海H仁”(優先順位番号が3)に連絡が成功し、連絡開始日時が“2014/7/7 22:52:00”から約2分後の連絡終了時間が“22:54:21”に連絡が完了していることが分かる。これにより、お客様名が“A電機”で問合せ番号が“T1406A3982”に対する保守が開始されることも分かる。#(管理番号)が“1”以外の番号における情報伝達の状況も一覧表示できるので、情報伝達及び保守対応状況の全体を迅速に把握することができる。

0057

<待機者への連絡処理>図11図13
図11は、待機者への連絡処理を示すフローチャート図である。図12は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。図13は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。図11から図13の処理で待機者への連絡処理を構成する。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。

0058

S1101で、CPU21は、連絡者発信データの有無をチェックする。そのため、CPU21は、連絡部117の連絡情報DB1171に待機保守員へ伝達すべき情報(未送信メール等)があるかをチェックする。
S1102で、CPU21は、S1101でのチェック結果から未伝達データが有るかを判断する。無い場合(S1102:No)、CPU21は再びS1101を実行し、有る場合(S1102:Yes)はS1103を実行する。

0059

S1103で、CPU21は、メール送信済かを連絡結果DB1172内の連絡結果管理テーブル61により判断する。具体的には、CPU21は、連絡結果管理テーブル61の#10の“メール送信回数”と#11の“メール連絡結果”で、“メール送信回数”が1回以上で、“メール連絡結果”が“0(正常)”である場合にメール送信済と判断する。メール送信済の場合(S1103:Yes)、CPU21はS1108を実行し、メール送信が済んでない場合(S1103:Yes)、S1104を実行する。
S1104で、CPU21は、まず、優先順位が一番高い第1連絡者にメールを送信する。

0060

S1105で、CPU21は、メール送信が成功したかを判断する。メール送信が成功している場合(S1105:Yes)、CPU21は、S1106を実行する。メール送信が失敗している場合(S1105:No)、CPU21は、連絡結果管理テーブル61の#10の“メール送信回数”に“1”を格納し、#11の“メール連絡結果”に0以外の値(異常)を格納して、再度S1104を実行する。なお、S1105の判断では、CPU21がメール送信回数の上限に到達したかも連絡環境管理テーブル50(#8の“メール送信リトライ回数”)により判断する。図示はしていないが、メール送信回数の上限に到達した場合、CPU21は、次の連絡者(第2連絡者)に対する連絡処理を実行するため、処理をS1101に戻す。

0061

S1106で、CPU21は、連絡結果管理テーブル61の更新、すなわち、#10の“メール送信回数”に“1”を格納し、#11の“メール連絡結果”に“0(正常)”を格納する。
S1107で、CPU21は、所定時間(a)の間、待機する。所定時間(a)は、連絡環境管理テーブル50の#9の“メール送信後の待機秒数”に設定された値で、例えば図5のように60秒(1分)である。

0062

S1108で、CPU21は、メールを送信した待機者へ電話発信を連絡部117に指示する。指示を受けた連絡部117はPBX118経由公衆回線網1012で、連絡者(待機保守員)の携帯電話に電話発信を行う。連絡部117は、連絡者(待機保守員)からの応答を所定時間待つ。その所定時間は、連絡環境管理テーブル50の#6の“電話発信秒数”に設定された時間である。図5の例では、“30秒”である。また、話し中の応答があった場合、連絡部117は、連絡環境管理テーブル50の#5の“話し中時の待機秒数”に設定された時間(図5の例では“180秒(3分)”)、待機する。そして、その結果を連絡部117は、CPU21に送信する。

0063

S1109で、CPU21は、連絡部117からの送信された結果で応答が有ったか否かを判断する。応答があった場合(S1109:Yes)、CPU21はS1110を実行し、無い場合(S1109:No)、S1201(図12)を実行する。以降の説明では連絡部117等が実行する処理があるが、CPU21が処理するものとして説明する。
S1110で、CPU21は、音声連絡1と音声連絡1の受信確認を行う。音声連絡1としては、例えば、図3の待機者管理テーブル30の#11で示すように、“A電機様のBデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話のAボタン(1のダイヤル)を押してください。オペレータ転送希望の場合は、Bボタン(3のダイヤル)を押してください。”という音声をCPU21が、連絡者(待機保守員)の携帯電話に連絡する。連絡を受けた連絡者(待機保守員)は、所定のダイヤルを押下する。CPU21は、押下されたダイヤルの情報を入力部24経由で受け付ける。

0064

S1111で、CPU21は、受け付けた入力値が何であるかを判断する。連絡結果管理テーブル61の#14の“ダイヤル入力正解値(受信確認)”に設定された“1”であればS1112を、#15の“ダイヤル入力正解値(オペレータ転送)” に設定された“3”であればS1301(図13)を、それ以外であればS1117を実行する。
S1112で、CPU21は、音声連絡2、例えば“保守対応をお願いします”等の音声連絡を連絡者(待機保守員)の携帯電話に送信する。

0065

S1113で、CPU21は、連絡者(待機保守員)の携帯電話との電話回線を切断する。
S1114で、CPU21は、連絡結果管理テーブル61を更新する。つまり、CPU21は、連絡結果管理テーブル61の#12の“電話連絡回数”に電話連絡を実行した回数を、#13の“電話連絡結果”に“0:ダイヤル入力値確認で成功”を、“最終ダイヤル入力値”に“1(受信確認)”をそれぞれ設定する。
S1115で、CPU21は、連絡結果管理テーブル62を更新する。つまり、CPU21は、連絡結果管理テーブル62の#3の“全体最終結果”に“0(成功)”を、#4の“全体最終結果更新日時”に最終結果更新時刻情報を格納する。

0066

S1116で、CPU21は、電話連絡回数が規定回数を超えたかを連絡環境管理テーブル50の#4の“ダイヤルエラー回数”の設定値で判断する。図5の例では、設定値(規定回数)が5回なので、電話連絡回数が5回以下の場合(S1116:No)、CPU21はS1117を実行し、5回を超える場合(S1116:Yes)、図12のS1204を実行する。
S1117で、CPU21は、音声連絡3、例えば“指定されたダイヤル番号が入力されませんでした。ダイヤル番号1かダイヤル番号3のどちからを押してください”との音声ガイダンスで音声連絡を行い、再度受信確認を行う。そして、CPU21は、S1111を再び実行する。

0067

S1201で、CPU21は、話し中であるかを判断する。話し中である場合(S1201:Yes)、CPU21はS1202を実行し、話し中でない場合(S1201:No)、S12023実行する。
S1202で、CPU21は、話し中の状態が1回目であるかを判断する。これは、同じ連絡者(待機保守員)に対し1回だけ電話連絡を繰り返す。なお、連絡環境管理テーブル50に話し中での繰り返し連絡回数の上限値という項目を設け、その設定値に応じて2回以上の電話連絡を繰り返すこともできる。話し中の状態が1回目である場合(S1202:Yes)、CPU21はS1210を実行し1回目でない場合(S1202:No)、S1203を実行する。
S1203で、CPU21は、連絡者(待機保守員)の携帯電話の留守電等に“連絡事項を確認願います。連絡内容は・・・”という音声連絡4を録音させる処理を実行する。

0068

S1204で、CPU21は、連絡者(待機保守員)の携帯電話との電話回線を切断する。
S1205で、CPU21は、連絡結果管理テーブル61を更新する。つまり、連絡結果管理テーブル61の#13の“電話連絡結果”に対応する設定値/格納値613の欄に“4(話し中)”を格納する。
S1206で、CPU21は、現在連絡した連絡者が最終連絡者であるかを判断する。最終連絡者でない場合(S1206:No)、CPU21は、次の連絡者(待機保守員)に同じ情報伝達を行うためS1101からの処理を再び実行する。最終連絡者である場合(S1206:Yes)、CPU21は、S1207を実行する。
S1207で、CPU21は、所定ループ回数超過したかを判断する。つまり、全ての連絡者(待機保守員)への連絡処理を所定回数、つまり連絡環境管理テーブル50の#3の“連絡ループ(繰り返し)回数”での設定値(図5の例では“3回”)の回数分、連絡処理を実行したかを判断する。超過した場合(S1207:Yes)、CPU21はS1208を実行し、超過していない場合(S1207:No)はS1101を再び実行する。

0069

S1208で、CPU21は、連絡結果管理テーブル61を更新する。つまり、CPU21は、連絡結果管理テーブル61の#13の“電話連絡結果”に“3:不在”を設定する。
S1209で、CPU21は、連絡結果管理テーブル62を更新する。つまり、CPU21は、連絡結果管理テーブル62の#3の“全体最終結果”に“92(規定回数、連絡処理を実行したが連絡者なし)”を設定する。そして、本保守案件で、保守員を確保できなかったことをオペレータ端末12に通知する。次に、別の保守対応案件が存在するかを確認するため、再びS1101の処理を実行する。
S1210で、CPU21は、所定時間(b)待機する。つまり、CPU21は、連絡環境管理テーブル50の#5の“話し中時の待機秒数”での設定値の時間(図5では“180秒(3分)”)、待機状態とする。
S1212で、CPU21は、連絡結果管理テーブル61を更新する。つまり、連絡結果管理テーブル61の#12の“電話連絡回数”に“1回”を、#13の“電話連絡結果”に“4:話し中”を設定する。そして、CPU21は、S1108以降の処理を再び実行する。

0070

S1301で、CPU21は、音声連絡5として“オペレータに転送します。暫くお待ちください。”との音声を、連絡者(待機保守員)の携帯電話に送信する。
S1302で、CPU21は、オペレータへの転送に成功したかを判断する。成功した場合(S1302:Yes)、CPU21はS1303を実行し、失敗した場合(S1302:No)はS1304を実行する。

0071

S1303で、CPU21は、オペレータへの転送結果が成功したと判断し、次のS1113を実行する。
S1304で、CPU21は、オペレータへの転送結果が失敗したと判断し、S1305を実行する。
S1305で、CPU21は、音声連絡6として“転送に失敗しました” との音声を、連絡者(待機保守員)の携帯電話に送信する。

0072

<メール送信処理>図14
図14は、メール送信処理を示すフローチャート図である。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。本処理は、CPU21がS1104でのメール送信処理を実行することを契機に開始される。

0073

S1401で、CPU21は、SMTP(Simple Mail Transfer Protocol)動作、すなわち、メールサーバ特定と特定されたメールサーバへの接続を試行する。
S1402で、CPU21は、メールサーバへの接続が成功したかを判断する。接続が成功した場合(S1402:Yes)、CPU21はS1403を実行し、失敗した場合(S1402:No)はS1407を実行する。
S1403で、CPU21は、連絡者(待機保守員)の携帯電話へ電子メールを送信する。
S1404で、CPU21は、メール送信が成功したかを判断する。電子メール送信が成功した場合(S1404:Yes)、CPU21はS1405を実行し、失敗した場合(S1404:No)はS1405を実行する。

0074

S1405で、CPU21は、メール送信回数が規定回数を超えたかを判断する。規定回数は、連絡環境管理テーブル50の#8の“メール送信リトライ回数”に設定された値である(図5の例では2回)。超えた場合(S1405:Yes)、CPU21はS1406を実行し、超えていない場合(S1404:No)はS1403を実行し、再度電子メールを送信する。
S1406で、CPU21は、オペレータ端末12にエラーを報告する。そして、CPU21は処理をS1104へ戻す。

0075

S1407で、CPU21は、特定されたメールサーバへの接続の試行回数が、規定回数を超えたかを判断する。超えた場合(S1407:Yes)、CPU21はS1408を実行し、超えていない場合(S1407:No)は再びS1401を実行し、再度メールサーバへの接続を試みる
S1408で、CPU21は、オペレータ端末12にエラーを報告する。

0076

なお、本電子メール送信では、待機者管理テーブル30の#3の“連絡区分”に従い、連絡者(待機保守員)1名毎に電子メールを送信するか、連絡者全員に同時に電子メールを送信して同報するかを選択できる。同じく、電話連絡も“連絡区分”に従い、1名毎・実施せずという条件より選択することができる。また、図11から図14の処理は、異なる保守対応案件を同時に対応するため並列的に実行することもできる。

0077

<連絡中止処理>図15
図15は、連絡中止処理を示すフローチャート図である。なお、処理の主体をサーバ11のCPU21とするが、サーバ11ないし情報伝達システム1全体でもよい。

0078

S1501で、CPU21は、中断ボタン94が押されたかを判断する。中断ボタン94が押された場合(S1501:Yes)、CPU21はS1502を実行し、押されない場合(S1501:No)は再びS1501の判断を実行する。
S1502で、CPU21は、連絡処理は完了しているかを判断する。連絡処理が完了している場合(S1502:Yes)、CPU21はS1501を再び実行し、連絡処理は完了していない場合(S1502:No)はS1503を実行する。
S1503で、CPU21は、連絡処理を中止する。

0079

以上のように、本発明の実施形態では、待機保守員へ受け付けた保守依頼内容の一部を含む第1の保守対応要求を第1の情報通信部で伝達し、第1の対応要求から第1の所定時間が経過した後、第2の保守対応要求を第2の情報通信部で伝達し、第2の対応要求から第2の所定時間が経過しても第2の保守対応要求に対する応答が無い場合、次の待機保守員へ保守対応要求を伝達する。このように、異なる伝達手段(第1の情報通信部及び第2の情報通信部)で、時間差を設けて保守対応要求と保守情報を伝達する。そして、要求への応答が無い場合は次の保守待機員に情報を伝達するようにした。1人以上の待機保守員に複数回の情報伝達を同時に実行することで、即時応答可能な待機保守員を確保できる。そのため、ユーザ直接の保守依頼への対応時間を短縮することができ、ユーザ満足度を向上できる。なお、上記実施例では、保守会社などの待機保守員に対する情報伝達を例としたが、巡回保守員などへの情報伝達でもよく、また、運送会社の運送員、ビル管理会社の警備員などへの情報伝達にも用いることができる。

0080

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

0081

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、ICカードSDカード、DVD等の記録媒体に置いてもよい。また、制御線情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

0082

1:情報伝達システム、11:サーバ、12:オペレータ端末、21:CPU、22:メモリ、23:記憶部、24:入力部、25:出力部、26:表示部、27:通信部、伝達情報生成部111、保守依頼受付部112、メール作成部114、連絡者登録部115、連絡者作成部116、連絡部117、113/118:PBX、1001/1002:インターネット、1011/1012:公衆電話回線網

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ