Method for providing automatic service for communication

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、通信の分野、特に通信動作のために自動サービスを提供することに関する。

【０００２】

【従来技術】本発明の原理は、ファクシミリや電子メールやネットワーク化やセルラー・サービスやＰＣＳやＩ
ＳＤＮユーティリティや他の通信アプリケーションのような、通信のモードに同様に適用できるが、本発明は、
電話サービスに関連して、その利用について次に示す説明から、十分に理解できると思われる。

【０００３】

【発明が解決しようとする課題】この国の消費者の大部分は、個人用と業務用の通信サービスに依存している。
そのために、平均的な電話会社が非常に数多くのサービス依頼を日常処理していることは、それほど驚くべきことでない。 一般的に顧客の呼から生じる、サービス依頼は、呼び出している顧客に提示される一部の特殊なサービスの提示に用いられる情報を含んでいる。 サービスの依頼は、更に多くの目的をもっている。 それらは、新しい顧客を得るために、サービス加入状態を識別するために、電話番号を変更又は追加するために、属性（呼者Ｉ
Ｄ、呼待機状態など）を追加又は削除するために、サービスを開始又は終了するために、他の通信事業者のホストを構成するために、特に用いられている。

【０００４】最近の通信業界では、サービス更新業務は、サービス要請を取り扱う顧客サービス・オペレータを活用して行われている。 通信会社にとって、サービス依頼の連続的な処理は高価なものになっている。 このコスト要因は、多数の操作スタッフが、呼を受信して、対応するサービス依頼を処理するために勤務する必要性があることから部分的に由来する。 そのために生じる経費が、更に高価な電話サービスの形態で、消費者に必然的に請求されることになる。 少なくともこの理由のために、多数の操作スタッフに起因するコスト負担が、ＡＴ
＆Ｔのような大きな通信会社にとって縮小の主な対象になる。

【０００５】しかし、これらのコストを低減する試みには以前から問題が多かった。 例えば、電話会社がサービス員を減らしてコストを下げようと試みる際に問題が生じていた。 会社が操作スタッフを縮小する時に、顧客サービスのことで悩むことになる。 これはピーク呼時間帯において特に顕著になり、その場合に、長い待機時間が顧客をいらいらさせ、必要な修理又は他のサービスの着手を遅らせることになる。 この点に関してのサービス提供はマイナスの影響を受けていた。

【０００６】従って、少なくとも二重のジレンマが、サービスを提供する操作スタッフを通信会社が採用することから生じる。 一方で、サービス員を縮小してコストを下げることは、顧客サービスの許容レベルを低下させることになる。 他方で、効率的な係員のレベルを維持することは、しばしば、会社にとって我慢できないほどの経費負担になる。

【０００７】商業用通信業界の全体にわたって明らかなことであるが、このジレンマは、地方電話サービスの分野で恐らく最も深刻と思われる。 そこでは、消費者は、
各々加入のためのサービス依頼を処理する地方電話会社に直接加入することになる。 顧客サービスは、初期依頼の取扱だけでなく、地域サービスに対する後の修理又は変更を行う際にも必要になる。 この後の部分では、顧客サービスを維持しながらコストを管理するために前向きに解決する必要性が、最近、最も重要になってきている。

【０００８】サービスを提供する方法は、これらの方法が音声データ変換のように大がかりな自動化を呈しているので、部分的に自動化されている従来技術にも存在する。 しかし、人的なスタッフには、サービス要請を処置して満足させることが常に要求される。 例えば、従来の方法は、要請されたサービス変更に対応するサービス依頼を処理するために、人的な係員の採用を必要とする。
残念なことに、サービス依頼の処理は、サービス提供業務に関連する処理時間の大半を費やしている。 従って、
従来の方法では、会社は、十分な操作スタッフを採用して、顧客サービスに関して最も複雑な部分を処置して満足させなければならない。 このような設定業務は、人的な係員を減らして実現するコスト低減効果を低下させることになる。 要するに、従来のサービス提供方法に付随する種々の欠点は、具体的なコスト低減と効率的な顧客サービスとが両立しないことにある。

【０００９】更に、従来のシステムは、顧客の柔軟な行動を過酷に制限している。 顧客は、最も基本的なサービス・ベースのニーズを実施するにも、人的な係員に依存しなければならない。 例えば、顧客が呼待機属性を今の番号に加えるために、電話サービスを変えたいと希望する時に、顧客は、それを自動的に変更できない。 代わりに、顧客は、最も日常的なサービス要請の場合でも、人的な係員と常に連絡をとらなければならない。 顧客にとって、顧客アシスタントが顧客の要請に対応できる状態になるまで、回線上で、かなりの保留時間を費やす結果にしばしばなる。 電話会社にも顧客サービスのジレンマがある。 会社がフィールド・ルーチン・サービス要請に相応するサービス員の実質的なスタッフを採用しても、
コスト的な検討が再び最も重大な課題になる。 そこで、
サービスを提供するための新しい方法が、従来の方法の種々の現実的な欠点を克服するために、特に望まれる。

【００１０】従って、本発明の目的は、通信会社のために十分な自動化されたサービスを提供する方法を提供することにある。

【００１１】本発明の更なる目的は、従来の方法より実質的に更に効率的な自動サービス提供方法を提供することにある。

【００１２】本発明の別の目的は、広範囲にわたる顧客ベース・サービス・オペレーションを実施できる方法を提供することにある。

【００１３】本発明の別の目的は、多数の操作スタッフが顧客からの電話呼を定期的に監視する必要性を解消し、その必要性が自動サービスの提供によって更に効率的に好都合に高信頼性のもとで満たすことができる、方法を提供することにある。

【００１４】本発明の別の目的は、複数のサービス提供者のサービス依頼フォーマットに対応するために、十分に統合できるサービス提供方法を提供することにある。

【００１５】本発明の更に別の目的は、顧客が好都合な自己提供機能に基づいて或る物理的な位置から別の物理的位置に移動することを可能にする、通信する顧客の移動と他のサービスとをサポートすることにある。

【００１６】本発明の更なる別の目的は、サービスの維持管理を顧客に、サービス依頼の保存と確保とによって提供する、通信サービス・オペレーションのための方法を提供することにある。

【００１７】

【課題を解決するための手段】本発明のこれらの及び他の目的は、十分に自動化され且つ事実上無制限の多種多様なサービス要請をサポートする、サポート提供と維持管理のための方法を提供する、本発明の原理に基づいて達成される。 従来の通信システムに準じてサービス更新を実施する自動的で高信頼性の方法を提供することによって、本発明は、顧客サービス機能を行う具体的な操作スタッフを必要とする高価な旧来の方法に代わることになる。 本発明によれば、今の顧客は、通信会社を呼び出して、１つ又は複数のサービス要請を行う。 接続して、
顧客のＤＴＭＦトーン又は音声データが入力された後に、ＤＴＭＦトーン又は音声が、音声データ変換ステップを用いて、データに変換される。 次に、受信された顧客データが検証される。 呼者が要請されたサービスを受信する資格を有する今の顧客と識別される場合に、この方法は、受信されたサービス要請に関連するサービス依頼を自動的に処理する。 サービス依頼は、顧客の特定のサービス提供者と共用できるフォーマットを用いて処理される。 次に、サービス依頼が実施されて、要請されたサービスが行われる。 ある実施例では、この方法は、顧客にダイアル・バックして、要請されたサービス状態を確認するために、呼者の電話番号を自動的に記録する、
記録機能を提供する。 この方法は、顧客が呼を終了するまで、顧客サービス要請に関する任意の回数だけ繰り返される。 また、ある実施例では、サービス依頼プロセスで、加入者の属性情報を更新して、将来のサービス要請に対応している。

【００１８】自動サービスを提供する前述の方法から、
種々の実施例と変形を考えられることができる。 これらの実施例と変形は本発明の趣旨と範囲に属する。 本発明の更なる特徴と種々の長所は、添付する図面と本発明の次に示す詳細な説明から更に明らかになると思われる。

【００１９】

【実施例】図１は、本発明に基づく自動サービス提供のための方法を搭載する事象の全体的なシーケンスを示す。 この図は電話サービスを更新する今の加入者に関連する方法を示しているが、この方法は、通信の他のモードにも同様に応用できる。 加入者は、今の電話サービスの一部の変更を希望している。 加入者は、電話会社のサービス・センターの電話番号にダイアルする。 データ・
パス１と６で示す接続が、そこで、加入者とサービス・
センターとの間で構築される。 この接続は、ボックス１
０で示す音声データ変換要素と加入者との間で特に構築される。 本申請の趣旨から、“要素”という用語は、本発明の対応するステップに相応して、必然的に関連し且つ機能を呈する、物理的な構成要素又はソフトウェアあるいその両方を、全体的に意味する。 オーラル・プロンプトに対応して、加入者は、加入者の電話番号及び希望するサービス更新の特長のような一部の情報を提示する。 加入者は、音声又はＤＴＭＦ（タッチ）トーンのいずれかを用いて入力する。 音声データ変換ステップ１０
の目的は、加入者の音声又はＤＴＭＦトーン入力を、自動方式で作動するプロセッサが理解できるデータ・ストリームに変換することにある。

【００２０】従って、音声データ変換ステップ１０では、この入力情報を、後のステップにおける更なる処理のために、互換性のあるデータに変換する。 音声データ変換要素１０の物理的で機能的な詳細は、従来技術で周知のことであり、特許請求する方法を理解するうえで重要なことでないと思われる。

【００２１】音声データ変換ステップ１０に準じて、変換されたデータ・ストリームが、ボックス２０で図形的に示す、顧客確認と呼ぶ要素によって次に受信される。
音声データ変換要素１０から顧客検証要素２０にいたるデータの概念的な流れが、データ・パス２によって表されている。 顧客検証ステップ２０の目的は、既に電話サービスを受けている顧客に対するサービスの自動提供を制限することにある。 すなわち、既に電話会社の顧客になっている顧客だけ、自己提供が許可されるのである。
顧客検証ステップ２０は、要請されたサービス変更が顧客に対して可能であるかどうか、又は他の要因（顧客のクレジットやサービス・タイプなどのように）のために要請されたサービスに対する顧客の資格を除外すべきかどうかについても、データベース２５に含まれている顧客属性に基づいて決定する。 例えば、顧客検証ステップ２０では、データベース２５にアクセスして、顧客の属性について検討する。 顧客属性として、加入者の所在地、加入者が用いるサービスのタイプ、加入者のクレジットの等級、サービス場所、サービスの入手性、装置タイプ、今の電話番号、サービスの過程、加入者の要請に関連する他の情報などのような、情報を一般的に含んでいる。 顧客検証ステップ２０において、いかなる理由であっても、加入者が要請したサービスに相応する資格を有していないと決定する場合に、それは、該当するエラー・メッセージを加入者に送り返す。 このエラー・メッセージは、データ・パス７と５を経由して音声データ変換ステップ１０に戻される。 音声データ変換ステップ１
０では、エラー・メッセージを搭載する電子データを、
データ・パス６上で加入者に伝えるために音声データに変換する。

【００２２】顧客検証ステップ２０は、任意の周知の方式を用いている。 一般的に、顧客の検証は、ルーチンを実行する周辺回路を具備する１つ又は複数の適切なマイクロプロセッサと共に、ソフトウェア・ルーチン（又はルーチンのセット）を用いて行われる。 ある実施例では、顧客検証情報が、サービス依頼の処理（次に説明）
に関連する情報と同じデータベースのなかに含まれている。 他の実施例では、データベースは全く別のものになる。

【００２３】検索から、顧客がサービス提供者と既に契約していて、加入者が変更に対する資格を有していることが分かると、サービス更新ステップは次のステップに進む。 顧客検証要素２０は、関連する顧客データをサービス依頼生成ステップ３０に送る。 要素２０から要素３
０にいたる概念的なデータの流れが、データ・パス３によって図形的に表されている。

【００２４】サービス依頼生成ステップ３０は、自己提供ルーチンに関連するコンピュータ処理の殆どを一般的に含んでいる。 サービス依頼生成ステップ３０ではサービス依頼を処理する。 サービス依頼は、加入者が送る情報だけでなく、サービス依頼生成ステップ３０のために定めた顧客の属性とフォーマット記述の情報にも準じて処理される。 サービス依頼のフォーマットは、加入者のサービス提供者の識別要素に部分的に従属する。 本申請を提出する時に、発明者は、ＡＴ＆ＴやＧＤＥやＭＣＩ
を含めて、７つの地方ベル運営会社（ＲＢＯＣＳ）を知っていた。 これらの会社の各々が、独自のフォーマットを備えてサービス依頼を活用できる。 更に、これらの及び他の通信の会社は他の送信サービス提供者も利用できる。 通信会社は、外国の会社と業務関係を結ぶことができるので、外国のサービス提供者も使用できる。 特定のサービス提供者、又は種々のサービス提供者に付随するフォーマットが、データベース３５に保存されている。
加入者の識別要素又は他の加入者情報あるいその両方を用いて、サービス生成ステップ３０では、データベース３５にアクセスして、サービス依頼に相応して用いる適切なフォーマットを読み取る。 特に、サービス依頼生成ステップ３０では、加入者のサービス提供者に付随してデータベース３５に含まれているサービス依頼マッピングについて検討する。 それに準じて、サービス依頼生成ステップ３０では、加入者のサービス提供者と共用するように識別したフォーマットを用いて、サービス依頼を作成する。 サービス提供者にかかわらず、サービス依頼のフォーマットは、その提供者が要求したパラメータに常に適合していることは、非常に優れているといえる。

【００２５】一度サービス依頼生成ステップ３０で該当するサービス依頼を処理すると、サービス依頼がデータ・パス４を経由してサービス依頼処理ステップ４０に送られる。 サービス依頼プロセス・ステップ４０の機能は、全ての必要なデータベースと動作システムにアクセスして、サービス依頼の項目に基づく決定として、サービス変更の物理的な実施を促すことにある。

【００２６】サービス依頼処理ステップ４０の実行中に、状態確認メッセージが、音声データ変換ステップ１
０にデータ・パス５を経由して送り返される。 音声データ変換ステップ１０ではメッセージを音声に変換し、それがデータ・パス６を経由して電話接続により加入者に伝えられる。 このメッセージは、要請されたサービスが承認されて完全に実行されることを、加入者に知らせるものである。 更に、好ましい実施例では、サービス依頼処理でデータベース２５の加入者属性が更新され、更なるサービス要請に伴う顧客検証のために順に利用できる。

【００２７】前述の状態確認メッセージに加えて、又はその代わりに、この方式は自動ダイアル・バックも行う。 このステップは、サービス要請が成功した後に行われる、加入者に対する自動電話呼を含んでいる。 ダイアル・バックは、加入者に対するサービス更新が成功して終了したことを、確認するものである。 ダイアル・バック・ステップでは、記録ステップ（次を参照）に保存してある電話番号を用いて、顧客をコール・バックする。

【００２８】単純にするために、前述のステップ間の接続性は、個別のデータ・パスとして全体的に説明してきた。 しかし、これらのデータ・パスは、必ずしも特殊な物理的接続でなく、本発明のステップ間の概念的な関係を示すことを意図していることが、当業者には自明のことと思われる。 更に、ある実施例では、図１のデータ・
パスは、ある場所から別の場所にいたるデータの物理的伝搬を常に要求するわけでない。 これらの事例では、図１のデータ・パスは、種々のステップで行われる依頼を明確にすることを意図しているにすぎない。 一例として、ある実施例では、音声データ変換要素１０の出力は、顧客検証のために第２の場所に物理的に伝わらない。 代わりに、これらの実施例では、顧客検証ステップ２０は、変換された顧客データが保存される所定の保存位置から、データを読み取るプロセッサを用いて行われる。

【００２９】図２は、本発明に基づく自己提供方式を更に明確に示すフローチャートである。 前述のように、加入者は、顧客サービス・センターにダイアルして１つ又は複数のサービス変更を要請する。 ダイアル時に、加入者は音声データ変換要素１００に接続される。 音声データ変換要素は、ある情報の入力を加入者に促す音声パターンを出力する。 加入者は、その今の電話番号と加入者の識別要素に関連する他の情報とを、音声又はＤＴＭＦ
トーンを用いて送る。 加入者の音声又はタッチ・トーン入力が、ステップ１００と１１０に示すようにして、データに変換される。 このデータは、サービス提供方式を実施するために目印を付記したプロセッサ構成要素が理解できる、任意の適切な形態になることができる。 ある実施例では、音声データ変換ステップ１００が記録機能（図示せず）を搭載している。 記録機能を用いて加入者の電話番号を保存するので、後のサービス確認のためのダイアルバック機能が可能になる。

【００３０】加入者が送った情報がデータ形態に変換された後に、データは、顧客検証ステップ１２０で処理される。 このデータを用いて、顧客検証ステップ１２０では、加入者データベース１２５にアクセスして、加入者の状態を従来の顧客と確認するか、又は要請されたサービスに対する加入者の資格について検証する。 前述のようにして、検証ステップ１２０では、加入者が今の顧客であるかどうかについて決定する（ブロック１３０を参照）。 そうでない場合、該当するエラー・メッセージが、音声データ変換ステップ１００に送り戻されて、加入者に音声で伝えられる。 その場合に、加入者のデータは、サービス依頼生成ステップ１４０で次に処理される。

【００３１】本発明の好ましい実施例では、サービス依頼生成ステップ１４０で、サービス依頼を、（１）要請された特定のサービスを指定する加入者が送ったデータと、（２）要請されたサービスの実施に必要な特定の依頼事項を定めるシステム情報と、（３）サービス依頼のフォーマット（サービス提供者に特有）とに基づいて生成する。 ポイント（１）に関して、サービス依頼生成ステップ１４０では、この情報を顧客から入手する（ステップ１００と１２０を参照）。 （２）と（３）に関して、サービス依頼生成ステップ１４０では、１つ又は複数の知識ベース・データベースにアクセスして、必要な情報を読み取る。 図２に示した好ましい実施例では、サービス依頼生成ステップが、２つのサブステップ、すなわち、依頼設定サブステップ１４６と依頼フォーマット構成サブステップ１４８とに分離できる。 依頼設定サブステップ１４６では、サービス依頼生成ステップ１４０
でデータベース１４７にアクセスする。 加入者の特定のサービス要請を詳細に記す加入者による情報入力に基づいて、依頼設定サブステップ１４６では、対応するサービス依頼設定をデータベース１４７から読み取る。 サービス依頼処理ステップ１４０では、適正に設定されたサービス依頼を処理するために、この情報を用いる。 次に、依頼フォーマット構成サブステップ１４８では、サービス依頼生成ステップ１４０で、加入者の入力情報を用いてデータベース１４９からサービス依頼に適したフォーマットを読み取る。 好ましい実施例では、データベース１４８は、加入者のサービス提供者に特有のフォーマットに関連する情報を含んでいる、総称的依頼マッピング・データベースである。 次にデータベース１４７と１４９から得た情報を用いて、サービス依頼生成ステップ１４０でサービス依頼を生成する。

【００３２】図２の例では、各々設定フォーマット・データが、２つの別個のデータベース１４７と１４９に保存されていた。 他の実施例では、この情報が全て単一のデータベースに含まれている。 代わりに、サービス依頼生成ステップ１４０では、情報を３つ以上のデータベースから抽出できる。 更に他の実施例では、データベース１２５に含まれている顧客属性情報は、サービス依頼生成ステップ１４０で用いた１つ又は複数のデータベースに代わりに常駐している。 他で説明したように、本発明は、データベースが構成される特別な方式に従属しない。

【００３３】ある実施例では、サービス依頼生成ステップ１４０で、処理したサービス依頼をデータベース１４
７又は１４９又は別に指定されたデータベースに書き込む。 この情報は、顧客情報の維持管理と自動記録保持とのために用いられる。

【００３４】システムがサービス依頼生成ステップ１４
０でサービス依頼の作成に成功したと決定する（ブロック１５０を参照）と、サービス依頼がサービス依頼プロセス１８０に送られる。 特に、ブロック１６０と１７０
に示すように、サービス依頼処理ステップ１８０では、
要請されたサービスを実施するために、通信網で必要な全ての動作システム１７０を呼び出す。 このステップは、必要なサービス・ベース業務を種々のマシンに割り当てる動作と、あるケースでは、要請された変更の物理的な実施に必要な回路要素の起動動作とを含んでいる。

【００３５】サービス依頼処理１８０をサポートするために、数多くの動作システムが従来技術に存在する。 このように、サービス依頼処理１８０に関連する構成要素は、各々サービス提供者の装置が全体的に異なると、それに伴って変わる。 サービス依頼処理は複雑である。 幸いなことに、この処理の物理的で機能的な詳細部は、任意の従来のサービス依頼構成方式がサービス依頼処理ステップ１８０に十分に適しているので、本発明を理解するうえで重要な部分にならない。 従って、本発明は、ハードウェアと、ソフトウェアと、サービス依頼対応要素１８０を搭載するネットワーク構成要素とが、特に、通信会社と加入者の特定のサービス提供者とに基づいて変わることになる。

【００３６】ある実施例では、この方式は、サービス依頼処理１８０の結果を自動的に検査して、サービス更新が成功したかどうかについて決定する。 いちどサービス情報がサービス要請を実施するネットワーク上で該当するデバイスに送られることに成功すると、サービス依頼処理ステップ１８０では、ブロック２００に示すようにして、サービス確認メッセージを作成する。 このメッセージは、加入者に順に伝えられる音声に変換するために、音声データ変換要素１００に送り返される。 一般的に、このメッセージは、加入者の要請を概略的に示すサービス依頼の作成が成功し、その依頼が実行中であることを、加入者に知らせる。 好都合に、このメッセージは、要請された変更が有効になる日時と時刻も提示する。 要請した変更がプロンプトも作動できる他の実施例では、サービス依頼プロセス１８０では、ブロック２１
０に示すように、加入者のサービスに対する変更に関連する新しい情報に準じてデータベース１２５の加入者属性を更新する。 この更新した加入者情報は、将来のサービス要請のために顧客検証ステップ１２０で用いられる。 また、サービス依頼プロセスでは、要請されたサービスの実行に成功したというメッセージを、音声データ変換ステップ１００に送る。 更に他の実施例では、この方式は、記録情報（前述の説明を参照）を用いて、サービスが完了した時に加入者に自動的にダイアル・バックする。 これらの実施例では、この方式は、要請されたサービスの実行に成功したことを、顧客に確認する。 前述の確認方式の特長との組合せも同様に考えることができる。

【００３７】本発明によれば、顧客は、ある物理的位置から別の位置に好都合に移動すると思われる。 顧客移動の許可は、顧客の電話番号が顧客始動時に自動的に更新する際に行われる。 電話番号変更のためのサービス依頼は、自動的に処理されて顧客に確認されるので、顧客サービス応答時間が大幅に短縮することになる。 このように、この方式は、大多数の顧客の満足を得ることができるので優れている。

【００３８】

【発明の効果】本発明によれば、加入する顧客は、単一ダイアル・サービスに依存して、顧客のサービス変更を更新できる。 操作スタッフがこれらの動作の実施のために必要とされず、サービス依頼も自動的に処理される。
更に、好ましい実施例では、この方式は今の顧客に関する全てのサービス依頼を効果的に追跡するので、全ての顧客状態情報を確保できる。 更に、この方式は、新しい電話番号の追加、今の電話番号の削除、新規サービスの属性の追加、今のサービスの属性の削除、今のサービス提供者の変更、請求情報の変更、サービスの除外とを制限せずに、事実上無制限で多種多様なサービス要請をサポートするように構成できる。

【００３９】今までの説明は本発明の原理を図示するだけのものであり、種々の変更と変形が本発明の範囲と趣旨から逸脱せずに実施できることを、当業者は認めるものと思われる。

【図面の簡単な説明】

【図１】本発明に基づく方法の事象の全体的なシーケンスのブロック図を示す。

【図２】本発明に基づく方法の典型的な実施例のフローチャートを示す。