JP2016091143A - 情報伝達システム、情報伝達方法及び情報伝達プログラム - Google Patents

Abstract

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

Description

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

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

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

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

特開平０８−３１４７６１号公報

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

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

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

図１は、本発明の情報伝達システム１の全体構成を示すブロック図である。 図２は、情報伝達システム１でのサーバ／端末の内部構成を示すブロック図である。 図３は、第１の待機者管理テーブル３０の構成例を示す図である。 図４は、第２の待機者管理テーブル４０の構成例を示す図である。 図５は、連絡環境管理テーブル５０の構成例を示す図である。 図６ａは、第１の連絡結果管理テーブル６１の構成例を示す図である。 図６ｂは、第２の連絡結果管理テーブル６２の構成例を示す図である。 図７は、連絡者検索結果の表示画面７０の構成例を示す図である。 図８は、送信メールに関する情報を示す図である。 図９は、第１の自動連絡結果例の表示画面の構成例９０を示す図である。 図１０は、第２の自動連絡結果例の表示画面１００の構成例を示す図である。 図１１は、待機者への連絡処理を示すフローチャート図である。 図１２は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。 図１３は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。 図１４は、メール送信処理を示すフローチャート図である。 図１５は、連絡中止処理を示すフローチャート図である。

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

また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＭＰ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｏｒ）やＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源（例えばメモリ）及び通信インターフェース装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであっても良い。

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

＜情報伝達システム全体構成＞図１
図１は、本発明の情報伝達システム１の全体構成を示すブロック図である。情報伝達システム１は、サーバ１１、オペレータ端末１２、電話交換機（ＰＢＸ：Private Branch eXchange）１１３／１１８から構成する。また、サーバ１１は、保守拠点１３とイントラネット１４で接続し、待機保守員１０３０が所持する携帯用機器（携帯電話や多機能タブレットなど）とインターネット網１００２や公衆回線網１０１２で接続する。更に、サーバ１１は、保守契約者１０２０（保守契約者の端末やサーバなど）とインターネット網１００１や公衆回線網１０１１で接続する。

サーバ１１は、伝達情報生成部１１１、保守依頼受付部１１２、メール作成部１１４、連絡者登録部１１５、連絡者作成部１１６、連絡部１１７より構成する。なお、各部をハードウェアで構成してもよいし、後述するＣＰＵ上で動作するプログラムでもよい。

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

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

伝達情報生成部１１１は、保守依頼受付部１１２から受け付けた保守内容から待機保守員１０３０（保守員１０３１、１０３２、１０３３など）やオペレータ端末１２を操作するオペレータに伝達する情報を生成する機能部である。伝達情報生成部１１１には、生成した伝達情報を管理する伝達情報ＤＢ１１１１があり、記憶装置に格納される。メール作成部１１４は、待機保守員１０３０に送信するための電子メールを作成する機能部である。作成する電子メールの内容は、伝達情報生成部１１１で生成された伝達情報を中心に構成される。詳細な内容については後述（図８）する。なお、メール作成部１１４で作成された電子メールは、連絡部１１７に送られ、連絡情報ＤＢ１１７１に格納される。

連絡者登録部１１５は、保守拠点１３（拠点１３０１、１３０２など）から登録された待機保守員の情報、すなわち情報を伝達し連絡する連絡者を登録するための機能部である。登録された待機保守員の情報が連絡者ＤＢ１１５１として、記憶装置等に格納される。連絡者作成部１１６は、後述（図４ないし図７）する待機者管理テーブルや待機者一覧情報などを作成する機能部である。作成された待機者管理テーブルや待機者一覧情報などは、連絡部１１７の連絡情報ＤＢ１１７１に格納される。

連絡部１１７は、待機保守員１０３０（保守員１０３１、１０３２、１０３３など）へ電子メール送信や電話連絡を行い、また、連絡した待機保守員１０３０からの応答を受け付ける機能部である。待機保守員１０３０への連絡情報は連絡情報ＤＢ１１７１として、待機保守員１０３０からの応答結果は連絡結果ＤＢ１１７２として記憶装置等に格納される。

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

＜装置内部構成＞図２
図２は、情報伝達システム１でのサーバ１１／端末１２の内部構成を示すブロック図である。サーバ１１及び端末１２は、ＣＰＵ２１、メモリ２２、記憶部２３、入力部２４、出力部２５、表示部２６、通信部２７を備える。

ＣＰＵ２１は、装置全体を制御するプロセッサである。メモリ２２は、各種プログラム及び後述する各種データ（テーブル）などを一時的に記憶するデバイスである。記憶部２３は、各種プログラム及び後述する各種データなどを恒久的に記憶するデバイスで、例えばＨＤＤやＳＳＤである。入力部２４は、入力を受け付けるデバイスで、例えば、キーボードである。

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

＜待機者管理テーブル＞図３、図４
図３は、第１の待機者管理テーブル３０の構成例を示す図である。図４は、第２の待機者管理テーブル４０の構成例を示す図である。待機者管理テーブル３０は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、保守拠点毎に本テーブルが作成される。また、受け付けた保守依頼内容で本待機者管理テーブル３０が更新される。待機者管理テーブル４０は、夜間や休日などに保守対応を行うための待機保守員を管理するテーブルで、待機保守員毎に本テーブルが作成される。

待機者管理テーブル３０は、＃（管理番号）３０１、項目名３０２、設定値／格納値３０３から構成される。 項目名３０２に対応に対する設定値／格納値３０３には、各種情報がテーブル作成時に設定ないし保守依頼受付時に格納され管理される。なお、待機者管理テーブル３０は、連絡部１１７の連絡情報ＤＢ１１７１に格納される。

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

また、項目名３０２に対応する設定値／格納値３０３の例として、“Ｔ１４０６Ａ３９８２−２０１４０７０７１０５５２１”、“２０１４／０７／０７ １０：５５：２１（ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ）”、“０”、“４名”、“拠点１３０２（ＺＤＬ７）”、“Ａ電機”、“Ｂデータセンタ”、“待機者連絡システムよりの障害対応依頼”、“Ａ電機様のＢデータセンタのサーバ（製造番号：ＨＳ１２３４ＡＢＣ）に障害が発生しました。主な障害現象は、リブートの繰り返しです。その他の障害現象は・・・”、“１２３−４５６７−８９０１”、“Ａ電機様のＢデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話の“Ａボタン”を押してください。オペレータ転送希望の場合は、“Ｂボタン”を押してください。”、“Ｂ”などである。なお、＃１の“待機者認識番号”での“Ｔ１４０６Ａ３９８２−２０１４０７０７１０５５２１”には、“２０１４０７０７１０５５２１（２０１４／０７／０７ １０：５５：２１）”というテーブル作成時刻情報も付加されている。

待機者管理テーブル３０の＃１から＃５に対応する情報は、連絡者ＤＢ１１５１の情報を連絡者作成部１１６で加工し生成された情報が格納される。また、＃６、＃７、＃９、＃１１、＃１２は、保守依頼受付部１１２からの保守依頼内容の情報が格納される。

待機者管理テーブル４０は、＃（管理番号）４０１、項目名４０２、設定値４０３から構成される。項目名４０２に対応する設定値４０３に各種情報がテーブル作成時に設定される。なお、 待機者管理テーブル４０は、連絡者登録部１１５１の連絡者ＤＢ１１５１に格納される。

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

項目名４０２に対応する設定値／格納値４０３の例として、“Ｔ１４０６Ａ３９８２−２０１４０７０７０８５９２１”、“２０１４／０７／０４ １０：５５：２１（ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ）”、“２”、“Ｈ６７７８５００１５Ａ”、“Ｃ山Ｇ男”、“シーヤマジーオ”、“１１１−２２２２−３３３３”、“ｃｙａｍａｇｏ２２２＠ｄｅｆ３３３．ｎｅｔｗ”、“拠点１３０２（ＺＤＬ７）”、“ＣＲＣ９９”、“７Ｇ”、“ローテーショングループ２”などである。

＜連絡環境管理テーブル＞図５
図５は、連絡環境管理テーブル５０の構成例を示す図である。連絡環境管理テーブル５０は、障害情報の伝達手段毎に設定される伝達環境情報（連絡回数上限、許容エラー回数、待機時間上限など）を管理するテーブルである。連絡環境管理テーブル５０は、＃（管理番号）５０１、項目名５０２、設定値５０３から構成される。なお、連絡環境管理テーブル５０は、連絡部１１７の連絡情報ＤＢ１１７１などに格納される。

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

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

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

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

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

項目名５０２に対応する設定値／格納値５０３として、“３０秒”、“ポート５５番”、“３回”、“５回”、“１８０秒（３分）”、“３０秒”、“２５秒”、“２回”、“６０秒”などである。

＜連絡結果管理テーブル＞図６ａ、図６ｂ
図６ａは、第１の連絡結果管理テーブル６１の構成例を示す図である。図６ｂは、第２の連絡結果管理テーブル６２の構成例を示す図である。連絡結果管理テーブル６１は、保守依頼に対する保守対応の詳細情報を管理するテーブルで、連絡結果管理テーブル６２は連絡結果管理テーブル６１での主要部分の情報を抽出し管理するテーブルである。連絡結果管理テーブル６１及び連絡結果管理テーブル６２は、連絡部１１７の連絡情報ＤＢ１１７１などに格納される。

連絡結果管理テーブル６１は、＃（管理番号）６１１、項目名６１２及び設定値／格納値６１３から構成される。項目名６１２の例として、依頼された保守を一意に識別するための“保守案件番号”、“作成日時”、“優先順位”、“保守拠点名（コード）”、“部課コード”、“グループ名”、“社員認識番号”、“氏名”、“連絡媒体（１：メール、２：電話）”、“連絡媒体（１：メール、２：電話）”、“メール連絡結果（０：正常、０以外：異常）”、“電話連絡回数”、“電話連絡結果（０：ダイヤル入力値確認で成功、１：オペレータ転送で成功、２：オペレータ転送失敗、３：不在、４：話し中、５：途中切断、６：回線異常、７：電源ＯＦＦ・電波状態異常）”、“ダイヤル入力正解値（受信確認）”、“ダイヤル入力正解値（オペレータ転送）”、“最終ダイヤル入力値”などである。

項目名６１２に対応する設定値／格納値６１３として、“Ｔ１４０６Ａ３９８２−２０１４０７０７ＸＹＺ”、“２０１４／０７／０７ ２２：５４：２１（ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ）”、“２番”、“拠点１３０２（ＺＤＬ７）”、“ＣＲＣ９９”、“７Ｇ”、“Ｈ６７７８５００１５Ａ”、“Ｃ山Ｇ男”、“２（電話）”、“１”、“０（正常）”、“２”、“０（ダイヤル入力正解値（受信確認））”、“１”、“３”、“１”である。なお、＃１の“保守案件番号”の設定値／格納値６１３である“Ｔ１４０６Ａ３９８２−２０１４０７０７ＸＹＺ”は、前述の“待機者認識番号”で時刻情報の代わりに“ＸＹＺ”という保守依頼の管理番号を付加したものである。これにより、各テーブルの関係を情報伝達システム１が認識することができる。

なお、＃１４の“ダイヤル入力正解値（受信確認）”でのダイヤル入力正解値と、＃１５の“ダイヤル入力正解値（オペレータ転送）” でのダイヤル入力正解値とは、誤入力を防止するため隣接した番号ではなく離れた異なった番号とする。例えば、＃１４の“ダイヤル入力正解値（受信確認）”でのダイヤル入力正解値が“１”であれば、＃１５の“ダイヤル入力正解値（オペレータ転送）” でのダイヤル入力正解値は“２”を挟んだ“３”ないし“５”を挟んだ“９”とする。また、＃１４の“ダイヤル入力正解値（受信確認）”でのダイヤル入力正解値が“２”であれば、＃１５の“ダイヤル入力正解値（オペレータ転送）” でのダイヤル入力正解値は“５”及び“８”を挟んだ“０”とする。また、＃１４の“ダイヤル入力正解値（受信確認）”でのダイヤル入力正解値と、＃１５の“ダイヤル入力正解値（オペレータ転送）”は、電話連絡毎にランダムに変更することで、誤入力を防止する。但し、このランダムでの変更時も隣接したダイヤル番号（同一ダイヤル番号も含め）が選択されないようにする。

連絡結果管理テーブル６２は、＃（管理番号）６２１、項目名６２２、設定値／格納値６２３を備える。項目名６２２の例として、“保守案件番号”、“作成日時”、“全体最終結果（０：成功、９０：異常終了、９１：中断ボタンが押下され、処理中止、９２：規定回数、連絡処理を実行したが連絡者なし）”、“全体最終結果更新日時”などである。

項目名６２２に対応する設定値／格納値６２３は、“Ｔ１４０６Ａ３９８２−２０１４０７０７ＸＹＺ”、 “２０１４／０７／０７ ２２：５４：２１（ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ）”、“０”、“２０１４／０７／０７ ２２：５７：３５（ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ）”である。

＜連絡者検索結果の表示画面＞図７
図７は、連絡者検索結果の表示画面７０の構成例を示す図である。連絡者検索結果の表示画面７０は、
待機部署を検索するための条件（検索条件）７１、検索条件７１に対応する検索の結果である検索結果７２（休日の待機保守員情報７２）及び検索結果７３（夜間の待機保守員情報７３）、連絡条件７４が表示される。

情報伝達システム１は、検索条件７１として“拠点コード：ＺＤＬ７”、“部課コード：ＣＲＣ９９”、“グループ：９Ｇ”が入力部２４で入力されると、オペレータ端末１２の表示部２６などに、休日での待機保守員情報７２及び夜間での待機保守員情報７３が表示する。その待機保守員情報７２及び待機保守員情報７３には、“日付情報”、“連絡条件”、“優先順位番号（１〜４）”及び“連絡者氏名”、“連絡者の電話番号”、“メール及び電話での連絡選択条件（１：メール＆電話、２：メールのみ）”及び“送信メールアドレス”が表示される。

連絡条件７４として、“１”は“１名毎、順番にメール送信と電話連絡を実施”を表し、“２”は“メールを全員へ同時に送信後、順番に電話連絡を実施”を表し、“３”は“メールを全員へ同時に送信後、電話連絡を実施しない”を表す。また、情報伝達システム１は、“２０１４／７／６（日）”の休日での保守対応では、連絡条件７４が“１”であるの“１名毎、順番にメール送信と電話連絡を実施”を行い、優先順位が“１”である“Ｂ田Ｆ道”（電話番号：１１１−２２２２−９９９９１、メール：ｂｄｅｎｆｍｉｃｈｉ１１１＠ａｂｃ２２２．ｎｅｔｗ）に対し、メール及び電話での連絡選択条件（１：メール＆電話）に従い連絡（情報伝達）をまず実行する。連絡が取れない場合、情報伝達システム１は、優先順位番号２の“Ｃ山Ｇ男”に連絡を実施する。以下、優先順位番号が“４”までの待機保守員に対し連絡を取れるまで連絡を実行する。また、情報伝達システム１は、“２０１４／７／７（月）”の平日夜間での保守対応も、“２０１４／７／６（日）”の休日での保守対応と同様な連絡を実行する。

＜送信メール情報＞図８
図８は、送信メールに関する情報を示す図である。送信メール８０の例として、メール送信先８１、送信メールヘッダ情報８２、メール本文８３から構成される。メール送信先８１は、図７で示した優先順位番号に従った第１連絡者から第４連絡者の氏名と送信メールアドレスで構成される。例えば、第１連絡者は“Ｂ田Ｆ道”で、送信先メールアドレスは“ｂｄｅｎｆｍｉｃｈｉ１１１＠ａｂｃ２２２．ｎｅｔｗ”である。

送信メールヘッダ情報８２は、送信日時、題名、送信元メールアドレスを備え、図８のように、例えば、送信日時が“２０１４／７／７ ２２：５２：３０”、題名が“保守受付拠点への依頼（障害連絡）”、送信元メールアドレスとして、“Ｓｕｐｅｒｖｉｓｏｒ＠Ｍａｉｎｔｅｎａｎｃｅ−ｍａｓｔｅｒ．ｗｗｗｎｅｔｗ”という情報が、送信メール８０に付加されている。

メール本文８３の項目の例として、“障害受付日時”、“お客様名”、“お客様部署名”、“保守契約形態”、“保守拠点（コード）”、“部課コード（グループ）”、“保守対応機種”、“型名／製造番号”、“障害現象”、“お客様住所”がある。
また、メール本文８３の項目に対応する内容（待機保守員への伝達情報の内容）として、“２０１４／７／７ ２２：５１：５９”、“Ａ電機”、“Ｂデータセンタ”、“Ｘ：標準出張保守契約”、“拠点１３０２（ＺＤＬ７）”、“ＣＲＣ９９（７Ｇ）”、“ＥＸサーバ”、“Ｔｙｐｅ−ＦｌｏｒａＰｒｉｕｓ／ＨＳ１２３４ＡＢＣ”、“リブート繰り返し／メモリエラー”、“東京都Ｓ区ＸＸ町ＡＡ−ＢＢ−ＣＣ ＤビルＥ階”、“００５５−２４５８−９８７６−内線２２４５”がある。

＜自動連絡結果の表示画面＞図９、図１０
図９は、第１の自動連絡結果例の表示画面の構成例９０を示す図である。図１０は、第２の自動連絡結果例の表示画面の構成例１００を示す図である。自動連絡結果の表示画面構成９０として、連絡先の検索条件９１と、その検索条件９１に対応する連絡結果を表示する。図９の例では、連絡結果１（符号９２）及び連絡結果２（符号９３）を表示しているが、実際にはどちらか一方がオペレータ端末１２の表示部２６に表示される。情報伝達処理（連絡処理）を中止するための中断ボタン９４も備える。

検索条件９１（拠点コード：ＺＤＬ７、部課コード：ＣＲＣ９９、グループ：９Ｇ）の入力が完了し、情報伝達システム１（サーバ１１）の入力部で入力情報が受け付けられると、オペレータ端末１２やサーバ１１の表示部２６に、検索条件９１とそれに対応する連絡結果が表示される。

連絡結果１（符号９２）を説明する。情報伝達システム１は、第１連絡者の“Ｂ田Ｆ道”へのメール送信が“２０１４／７／７ ２２：５３：３０”に完了し、送信完了の１分後（通話時刻１が“２２：５４：３１”）に電話連絡したが、“不在”であった。そこで、情報伝達システム１は、第２連絡者である“Ｃ山Ｇ男”へ“２２：５５：０２”にメールを送信し、“２２：５６：０３”に電話連絡を行ったが、“不在”であった。そのため、情報伝達システム１は、第３連絡者である“Ｄ海Ｈ仁”へ“２２：５６：３４”にメールを送信し、“２２：５７：３５”に電話連絡を行い通話ができ、保守依頼内容という情報の伝達を完了した。その結果が、符号９２に示す連絡結果１である。

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

次に、第２の自動連絡結果例の表示画面構成１００を説明する。表示画面構成例１００は、検索条件１０１と、入力された検索条件１０１に対する検索結果１０２で構成する。検索条件１０１への入力項目は、保守依頼を受け付けた期間、保守拠点を一意に識別する保守拠点コード、保守契約者１０２０からの問合せＮｏ（保守依頼番号）である。図１０での検索条件１０１は、期間が“２０１４／７／６−２０１４／７／７”で、拠点コード及び問合せＮｏは“指定なし”である。

検索結果１０２の項目は、＃（管理番号）、連絡部署、拠点コード、連絡者、最終連絡結果、問合せ番号、お客様名、連絡開始日時である。例えば、＃（管理番号）が“１”である情報伝達結果（自動連絡結果）は、
連絡部署が“ＣＲＣ９９”、拠点コードが“ＺＤＬ７”である連絡者“３ｒｄ＿Ｄ海Ｈ仁”（優先順位番号が３）に連絡が成功し、連絡開始日時が“２０１４／７／７ ２２：５２：００”から約２分後の連絡終了時間が“２２：５４：２１”に連絡が完了していることが分かる。これにより、お客様名が“Ａ電機”で問合せ番号が“Ｔ１４０６Ａ３９８２”に対する保守が開始されることも分かる。＃（管理番号）が“１”以外の番号における情報伝達の状況も一覧表示できるので、情報伝達及び保守対応状況の全体を迅速に把握することができる。

＜待機者への連絡処理＞図１１−図１３
図１１は、待機者への連絡処理を示すフローチャート図である。図１２は、待機者への連絡処理での電話応答判断処理を示すフローチャート図である。図１３は、待機者への連絡処理でのオペレータ転送処理を示すフローチャート図である。図１１から図１３の処理で待機者への連絡処理を構成する。なお、処理の主体をサーバ１１のＣＰＵ２１とするが、サーバ１１ないし情報伝達システム１全体でもよい。

Ｓ１１０１で、ＣＰＵ２１は、連絡者発信データの有無をチェックする。そのため、ＣＰＵ２１は、連絡部１１７の連絡情報ＤＢ１１７１に待機保守員へ伝達すべき情報（未送信メール等）があるかをチェックする。
Ｓ１１０２で、ＣＰＵ２１は、Ｓ１１０１でのチェック結果から未伝達データが有るかを判断する。無い場合（Ｓ１１０２：Ｎｏ）、ＣＰＵ２１は再びＳ１１０１を実行し、有る場合（Ｓ１１０２：Ｙｅｓ）はＳ１１０３を実行する。

Ｓ１１０３で、ＣＰＵ２１は、メール送信済かを連絡結果ＤＢ１１７２内の連絡結果管理テーブル６１により判断する。具体的には、ＣＰＵ２１は、連絡結果管理テーブル６１の＃１０の“メール送信回数”と＃１１の“メール連絡結果”で、“メール送信回数”が１回以上で、“メール連絡結果”が“０（正常）”である場合にメール送信済と判断する。メール送信済の場合（Ｓ１１０３：Ｙｅｓ）、ＣＰＵ２１はＳ１１０８を実行し、メール送信が済んでない場合（Ｓ１１０３：Ｙｅｓ）、Ｓ１１０４を実行する。
Ｓ１１０４で、ＣＰＵ２１は、まず、優先順位が一番高い第１連絡者にメールを送信する。

Ｓ１１０５で、ＣＰＵ２１は、メール送信が成功したかを判断する。メール送信が成功している場合（Ｓ１１０５：Ｙｅｓ）、ＣＰＵ２１は、Ｓ１１０６を実行する。メール送信が失敗している場合（Ｓ１１０５：Ｎｏ）、ＣＰＵ２１は、連絡結果管理テーブル６１の＃１０の“メール送信回数”に“１”を格納し、＃１１の“メール連絡結果”に０以外の値（異常）を格納して、再度Ｓ１１０４を実行する。なお、Ｓ１１０５の判断では、ＣＰＵ２１がメール送信回数の上限に到達したかも連絡環境管理テーブル５０（＃８の“メール送信リトライ回数”）により判断する。図示はしていないが、メール送信回数の上限に到達した場合、ＣＰＵ２１は、次の連絡者（第２連絡者）に対する連絡処理を実行するため、処理をＳ１１０１に戻す。

Ｓ１１０６で、ＣＰＵ２１は、連絡結果管理テーブル６１の更新、すなわち、＃１０の“メール送信回数”に“１”を格納し、＃１１の“メール連絡結果”に“０（正常）”を格納する。
Ｓ１１０７で、ＣＰＵ２１は、所定時間（ａ）の間、待機する。所定時間（ａ）は、連絡環境管理テーブル５０の＃９の“メール送信後の待機秒数”に設定された値で、例えば図５のように６０秒（１分）である。

Ｓ１１０８で、ＣＰＵ２１は、メールを送信した待機者へ電話発信を連絡部１１７に指示する。指示を受けた連絡部１１７はＰＢＸ１１８経由公衆回線網１０１２で、連絡者（待機保守員）の携帯電話に電話発信を行う。連絡部１１７は、連絡者（待機保守員）からの応答を所定時間待つ。その所定時間は、連絡環境管理テーブル５０の＃６の“電話発信秒数”に設定された時間である。図５の例では、“３０秒”である。また、話し中の応答があった場合、連絡部１１７は、連絡環境管理テーブル５０の＃５の“話し中時の待機秒数”に設定された時間（図５の例では“１８０秒（３分）”）、待機する。そして、その結果を連絡部１１７は、ＣＰＵ２１に送信する。

Ｓ１１０９で、ＣＰＵ２１は、連絡部１１７からの送信された結果で応答が有ったか否かを判断する。応答があった場合（Ｓ１１０９：Ｙｅｓ）、ＣＰＵ２１はＳ１１１０を実行し、無い場合（Ｓ１１０９：Ｎｏ）、Ｓ１２０１（図１２）を実行する。以降の説明では連絡部１１７等が実行する処理があるが、ＣＰＵ２１が処理するものとして説明する。
Ｓ１１１０で、ＣＰＵ２１は、音声連絡１と音声連絡１の受信確認を行う。音声連絡１としては、例えば、図３の待機者管理テーブル３０の＃１１で示すように、“Ａ電機様のＢデータセンタで障害が発生しました。対応お願いします。受信確認のため、電話のＡボタン（１のダイヤル）を押してください。オペレータ転送希望の場合は、Ｂボタン（３のダイヤル）を押してください。”という音声をＣＰＵ２１が、連絡者（待機保守員）の携帯電話に連絡する。連絡を受けた連絡者（待機保守員）は、所定のダイヤルを押下する。ＣＰＵ２１は、押下されたダイヤルの情報を入力部２４経由で受け付ける。

Ｓ１１１１で、ＣＰＵ２１は、受け付けた入力値が何であるかを判断する。連絡結果管理テーブル６１の＃１４の“ダイヤル入力正解値（受信確認）”に設定された“１”であればＳ１１１２を、＃１５の“ダイヤル入力正解値（オペレータ転送）” に設定された“３”であればＳ１３０１（図１３）を、それ以外であればＳ１１１７を実行する。
Ｓ１１１２で、ＣＰＵ２１は、音声連絡２、例えば“保守対応をお願いします”等の音声連絡を連絡者（待機保守員）の携帯電話に送信する。

Ｓ１１１３で、ＣＰＵ２１は、連絡者（待機保守員）の携帯電話との電話回線を切断する。
Ｓ１１１４で、ＣＰＵ２１は、連絡結果管理テーブル６１を更新する。つまり、ＣＰＵ２１は、連絡結果管理テーブル６１の＃１２の“電話連絡回数”に電話連絡を実行した回数を、＃１３の“電話連絡結果”に“０：ダイヤル入力値確認で成功”を、“最終ダイヤル入力値”に“１（受信確認）”をそれぞれ設定する。
Ｓ１１１５で、ＣＰＵ２１は、連絡結果管理テーブル６２を更新する。つまり、ＣＰＵ２１は、連絡結果管理テーブル６２の＃３の“全体最終結果”に“０（成功）”を、＃４の“全体最終結果更新日時”に最終結果更新時刻情報を格納する。

Ｓ１１１６で、ＣＰＵ２１は、電話連絡回数が規定回数を超えたかを連絡環境管理テーブル５０の＃４の“ダイヤルエラー回数”の設定値で判断する。図５の例では、設定値（規定回数）が５回なので、電話連絡回数が５回以下の場合（Ｓ１１１６：Ｎｏ）、ＣＰＵ２１はＳ１１１７を実行し、５回を超える場合（Ｓ１１１６：Ｙｅｓ）、図１２のＳ１２０４を実行する。
Ｓ１１１７で、ＣＰＵ２１は、音声連絡３、例えば“指定されたダイヤル番号が入力されませんでした。ダイヤル番号１かダイヤル番号３のどちからを押してください”との音声ガイダンスで音声連絡を行い、再度受信確認を行う。そして、ＣＰＵ２１は、Ｓ１１１１を再び実行する。

Ｓ１２０１で、ＣＰＵ２１は、話し中であるかを判断する。話し中である場合（Ｓ１２０１：Ｙｅｓ）、ＣＰＵ２１はＳ１２０２を実行し、話し中でない場合（Ｓ１２０１：Ｎｏ）、Ｓ１２０２３実行する。
Ｓ１２０２で、ＣＰＵ２１は、話し中の状態が１回目であるかを判断する。これは、同じ連絡者（待機保守員）に対し１回だけ電話連絡を繰り返す。なお、連絡環境管理テーブル５０に話し中での繰り返し連絡回数の上限値という項目を設け、その設定値に応じて２回以上の電話連絡を繰り返すこともできる。話し中の状態が１回目である場合（Ｓ１２０２：Ｙｅｓ）、ＣＰＵ２１はＳ１２１０を実行し１回目でない場合（Ｓ１２０２：Ｎｏ）、Ｓ１２０３を実行する。
Ｓ１２０３で、ＣＰＵ２１は、連絡者（待機保守員）の携帯電話の留守電等に“連絡事項を確認願います。連絡内容は・・・”という音声連絡４を録音させる処理を実行する。

Ｓ１２０４で、ＣＰＵ２１は、連絡者（待機保守員）の携帯電話との電話回線を切断する。
Ｓ１２０５で、ＣＰＵ２１は、連絡結果管理テーブル６１を更新する。つまり、連絡結果管理テーブル６１の＃１３の“電話連絡結果”に対応する設定値／格納値６１３の欄に“４（話し中）”を格納する。
Ｓ１２０６で、ＣＰＵ２１は、現在連絡した連絡者が最終連絡者であるかを判断する。最終連絡者でない場合（Ｓ１２０６：Ｎｏ）、ＣＰＵ２１は、次の連絡者（待機保守員）に同じ情報伝達を行うためＳ１１０１からの処理を再び実行する。最終連絡者である場合（Ｓ１２０６：Ｙｅｓ）、ＣＰＵ２１は、Ｓ１２０７を実行する。
Ｓ１２０７で、ＣＰＵ２１は、所定ループ回数を超過したかを判断する。つまり、全ての連絡者（待機保守員）への連絡処理を所定回数、つまり連絡環境管理テーブル５０の＃３の“連絡ループ（繰り返し）回数”での設定値（図５の例では“３回”）の回数分、連絡処理を実行したかを判断する。超過した場合（Ｓ１２０７：Ｙｅｓ）、ＣＰＵ２１はＳ１２０８を実行し、超過していない場合（Ｓ１２０７：Ｎｏ）はＳ１１０１を再び実行する。

Ｓ１２０８で、ＣＰＵ２１は、連絡結果管理テーブル６１を更新する。つまり、ＣＰＵ２１は、連絡結果管理テーブル６１の＃１３の“電話連絡結果”に“３：不在”を設定する。
Ｓ１２０９で、ＣＰＵ２１は、連絡結果管理テーブル６２を更新する。つまり、ＣＰＵ２１は、連絡結果管理テーブル６２の＃３の“全体最終結果”に“９２（規定回数、連絡処理を実行したが連絡者なし）”を設定する。そして、本保守案件で、保守員を確保できなかったことをオペレータ端末１２に通知する。次に、別の保守対応案件が存在するかを確認するため、再びＳ１１０１の処理を実行する。
Ｓ１２１０で、ＣＰＵ２１は、所定時間（ｂ）待機する。つまり、ＣＰＵ２１は、連絡環境管理テーブル５０の＃５の“話し中時の待機秒数”での設定値の時間（図５では“１８０秒（３分）”）、待機状態とする。
Ｓ１２１２で、ＣＰＵ２１は、連絡結果管理テーブル６１を更新する。つまり、連絡結果管理テーブル６１の＃１２の“電話連絡回数”に“１回”を、＃１３の“電話連絡結果”に“４：話し中”を設定する。そして、ＣＰＵ２１は、Ｓ１１０８以降の処理を再び実行する。

Ｓ１３０１で、ＣＰＵ２１は、音声連絡５として“オペレータに転送します。暫くお待ちください。”との音声を、連絡者（待機保守員）の携帯電話に送信する。
Ｓ１３０２で、ＣＰＵ２１は、オペレータへの転送に成功したかを判断する。成功した場合（Ｓ１３０２：Ｙｅｓ）、ＣＰＵ２１はＳ１３０３を実行し、失敗した場合（Ｓ１３０２：Ｎｏ）はＳ１３０４を実行する。

Ｓ１３０３で、ＣＰＵ２１は、オペレータへの転送結果が成功したと判断し、次のＳ１１１３を実行する。
Ｓ１３０４で、ＣＰＵ２１は、オペレータへの転送結果が失敗したと判断し、Ｓ１３０５を実行する。
Ｓ１３０５で、ＣＰＵ２１は、音声連絡６として“転送に失敗しました” との音声を、連絡者（待機保守員）の携帯電話に送信する。

＜メール送信処理＞図１４
図１４は、メール送信処理を示すフローチャート図である。なお、処理の主体をサーバ１１のＣＰＵ２１とするが、サーバ１１ないし情報伝達システム１全体でもよい。本処理は、ＣＰＵ２１がＳ１１０４でのメール送信処理を実行することを契機に開始される。

Ｓ１４０１で、ＣＰＵ２１は、ＳＭＴＰ（Simple Mail Transfer Protocol）動作、すなわち、メールサーバ特定と特定されたメールサーバへの接続を試行する。
Ｓ１４０２で、ＣＰＵ２１は、メールサーバへの接続が成功したかを判断する。接続が成功した場合（Ｓ１４０２：Ｙｅｓ）、ＣＰＵ２１はＳ１４０３を実行し、失敗した場合（Ｓ１４０２：Ｎｏ）はＳ１４０７を実行する。
Ｓ１４０３で、ＣＰＵ２１は、連絡者（待機保守員）の携帯電話へ電子メールを送信する。
Ｓ１４０４で、ＣＰＵ２１は、メール送信が成功したかを判断する。電子メール送信が成功した場合（Ｓ１４０４：Ｙｅｓ）、ＣＰＵ２１はＳ１４０５を実行し、失敗した場合（Ｓ１４０４：Ｎｏ）はＳ１４０５を実行する。

Ｓ１４０５で、ＣＰＵ２１は、メール送信回数が規定回数を超えたかを判断する。規定回数は、連絡環境管理テーブル５０の＃８の“メール送信リトライ回数”に設定された値である（図５の例では２回）。超えた場合（Ｓ１４０５：Ｙｅｓ）、ＣＰＵ２１はＳ１４０６を実行し、超えていない場合（Ｓ１４０４：Ｎｏ）はＳ１４０３を実行し、再度電子メールを送信する。
Ｓ１４０６で、ＣＰＵ２１は、オペレータ端末１２にエラーを報告する。そして、ＣＰＵ２１は処理をＳ１１０４へ戻す。

Ｓ１４０７で、ＣＰＵ２１は、特定されたメールサーバへの接続の試行回数が、規定回数を超えたかを判断する。超えた場合（Ｓ１４０７：Ｙｅｓ）、ＣＰＵ２１はＳ１４０８を実行し、超えていない場合（Ｓ１４０７：Ｎｏ）は再びＳ１４０１を実行し、再度メールサーバへの接続を試みる。
Ｓ１４０８で、ＣＰＵ２１は、オペレータ端末１２にエラーを報告する。

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

＜連絡中止処理＞図１５
図１５は、連絡中止処理を示すフローチャート図である。なお、処理の主体をサーバ１１のＣＰＵ２１とするが、サーバ１１ないし情報伝達システム１全体でもよい。

Ｓ１５０１で、ＣＰＵ２１は、中断ボタン９４が押されたかを判断する。中断ボタン９４が押された場合（Ｓ１５０１：Ｙｅｓ）、ＣＰＵ２１はＳ１５０２を実行し、押されない場合（Ｓ１５０１：Ｎｏ）は再びＳ１５０１の判断を実行する。
Ｓ１５０２で、ＣＰＵ２１は、連絡処理は完了しているかを判断する。連絡処理が完了している場合（Ｓ１５０２：Ｙｅｓ）、ＣＰＵ２１はＳ１５０１を再び実行し、連絡処理は完了していない場合（Ｓ１５０２：Ｎｏ）はＳ１５０３を実行する。
Ｓ１５０３で、ＣＰＵ２１は、連絡処理を中止する。

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

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

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１：情報伝達システム、１１：サーバ、１２：オペレータ端末、２１：ＣＰＵ、２２：メモリ、２３：記憶部、２４：入力部、２５：出力部、２６：表示部、２７：通信部、伝達情報生成部１１１、保守依頼受付部１１２、メール作成部１１４、連絡者登録部１１５、連絡者作成部１１６、連絡部１１７、１１３／１１８：ＰＢＸ、１００１／１００２：インターネット、１０１１／１０１２：公衆電話回線網

Claims (19)

1. ユーザからの受け付けた対応要求情報を対応要員へ連絡する情報伝達システムであって、
   前記情報伝達システムは、
   システム全体を制御するＣＰＵと、
   前記対応要求情報を受け付ける受付部と、
   前記対応要求情報を格納するメモリと、
   前記対応要求情報を伝達する第１の情報通信部と、
   前記対応要求情報を伝達する第２の情報通信部とを備え、
   前記ＣＰＵが、
   前記対応依頼情報の一部を含む第１の対応要求を前記第１の情報通信部で前記対応要員へ伝達し、
   前記第１の対応要求から第１の所定時間が経過した後、第２の対応要求を前記第２の情報通信部で前記対応要員へ伝達し、
   前記第２の対応要求から第２の所定時間が経過しても、前記第１ないし第２の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達する
   ことを特徴とする情報伝達システム。
2. 請求項１記載の情報伝達システムであって、前記第１の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第１の対応要求を前記電子メールで前記対応要員へ行う
   ことを特徴とする情報伝達システム。
3. 請求項２記載の情報伝達システムであって、前記第２の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第２の対応要求を前記電話回線で前記対応要員へ行う
   ことを特徴とする情報伝達システム。
4. 請求項３記載の情報伝達システムであって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納される
   ことを特徴とする情報伝達システム。
5. 請求項４記載の情報伝達システムであって、前記対応要員が２人以上存在する場合、全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達する
   ことを特徴とする情報伝達システム。
6. 請求項４記載の情報伝達システムであって、前記対応要員が２人以上存在する場合、全員に前記電子メールを同報した後、前記対応要員へ同時に前記電話回線で情報を伝達する
   ことを特徴とする情報伝達システム。
7. 請求項４記載の情報伝達システムであって、
   前記第２の対応要求に対する応答は、前記電話回線に接続された電話のダイヤル入力で行い、
   前記応答には２種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、
   前記割り当てられた電話のダイヤル入力同士が隣接せず、
   前記第２の対応要求毎に前記電話のダイヤル入力をランダムに変更する
   ことを特徴とする情報伝達システム。
8. 請求項７記載の情報伝達システムであって、前記対応要員が保守会社における保守員である
   ことを特徴とする情報伝達システム。
9. ユーザからの受け付けた対応要求情報を対応要員へ連絡する情報伝達システムの情報伝達方法であって、
   前記情報伝達システムは、
   システム全体を制御するＣＰＵと、
   前記対応要求情報を受け付ける受付部と、
   前記対応要求情報を格納するメモリと、
   前記対応要求情報を伝達する第１の情報通信部と、
   前記対応要求情報を伝達する第２の情報通信部とを備え、
   前記ＣＰＵが、
   前記対応依頼情報の一部を含む第１の対応要求を前記第１の情報通信部で前記対応要員へ伝達し、
   前記第１の対応要求から第１の所定時間が経過した後、第２の対応要求を前記第２の情報通信部で前記対応要員へ伝達し、
   前記第２の対応要求から第２の所定時間が経過しても、前記第１ないし第２の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達する
   ことを特徴とする情報伝達システムの情報伝達方法。
10. 請求項９記載の情報伝達システムの情報伝達方法であって、前記第１の情報通信部は、インターネット網に接続され電子メールの送受信を行う機能を有し、前記第１の対応要求を前記電子メールで前記対応要員へ行う
    ことを特徴とする情報伝達システムの情報伝達方法。
11. 請求項１０記載の情報伝達システムの情報伝達方法であって、前記第２の情報通信部は、公衆電話回線網に接続され電話回線での通信を行う機能を有し、前記第２の対応要求を前記電話回線で前記対応要員へ行う
    ことを特徴とする情報伝達システムの情報伝達方法。
12. 請求項１１記載の情報伝達システムの情報伝達方法であって、前記対応要員に依頼情報または対応要求を実行する優先順位が付けられ、当該優先順位の情報が、前記情報伝達システムに格納される
    ことを特徴とする情報伝達システムの情報伝達方法。
13. 請求項１２記載の情報伝達システムの情報伝達方法であって、前記対応要員が２人以上存在する場合、全員に前記電子メールを同報した後、前記優先順位に従い前記対応要員へ前記電話回線で情報を伝達する
    ことを特徴とする情報伝達システムの情報伝達方法。
14. 請求項１２記載の情報伝達システムの情報伝達方法であって、前記対応要員が２人以上存在する場合、全員に前記電子メールを同報した後、前記対応要員へ同時に前記電話回線で情報を伝達する
    ことを特徴とする情報伝達システムの情報伝達方法。
15. 請求項１２記載の情報伝達システムの情報伝達方法であって、
    前記第２の対応要求に対する応答は、前記電話回線に接続された電話のダイヤル入力で行い、
    前記応答には２種類以上の応答方法があり、当該応答毎に異なる電話のダイヤル入力が割り当てられ、
    前記割り当てられた電話のダイヤル入力同士が隣接せず、
    前記第２の対応要求毎に前記電話のダイヤル入力をランダムに変更する
    ことを特徴とする情報伝達システムの情報伝達方法。
16. 請求項１５記載の情報伝達システムの情報伝達方法であって、前記対応要員が保守会社における保守員である
    ことを特徴とする情報伝達システムの情報伝達方法。
17. ユーザからの受け付けた対応要求情報を対応要員へ連絡する情報伝達システムで動作する情報伝達プログラムであって、
    前記情報伝達システムは、
    システム全体を制御するＣＰＵと、
    前記対応要求情報を受け付ける受付部と、
    前記対応要求情報を格納するメモリと、
    前記対応要求情報を伝達する第１の情報通信部と、
    前記対応要求情報を伝達する第２の情報通信部とを備え、
    前記ＣＰＵで、
    前記対応依頼情報の一部を含む第１の対応要求を前記第１の情報通信部で前記対応要員へ伝達する機能と、
    前記第１の対応要求から第１の所定時間が経過した後、第２の対応要求を前記第２の情報通信部で前記対応要員へ伝達する機能と、
    前記第２の対応要求から第２の所定時間が経過しても、前記第１ないし第２の対応要求に対する応答が前記対応要員から受け付けられない時、次の対応要員へ対応要求を伝達する機能とを有する
    ことを特徴とする情報伝達システムの情報伝達プログラム。
18. 請求項１記載の情報伝達システムで動作する情報伝達プログラムであって、
    前記第１の情報通信部で、
    インターネット網に接続され電子メールの送受信を行う機能と、
    前記第１の対応要求を前記電子メールで前記対応要員へ行う機能とを有する
    ことを特徴とする情報伝達システムの情報伝達プログラム。
19. 請求項２記載の情報伝達システムで動作する情報伝達プログラムであって、
    前記第２の情報通信部で、
    公衆電話回線網に接続され電話回線での通信を行う機能と、
    前記第２の対応要求を前記電話回線で前記対応要員へ行う機能とを有する
    ことを特徴とする情報伝達システムの情報伝達プログラム。

Images