JP2005514869A - 通信補助システムおよび方法 - Google Patents

Abstract

【手段】本発明は、各リストが少なくとも一つの連絡先名と対応する連絡先番号を有する複数のリストを含む第一のデータベース（１８）を備えた通信補助システムに向けられる。電話技術ハードウェア（１２）が提供され、ユーザの電話装置（６）を本システムに連結するよう構成される。過去リクエスト・リスティングテーブルもまた本システムの少なくとも一人のユーザに対し提供され、ユーザからリクエストに応じて、データベースから取得する過去リクエスト・リストを格納するよう構成される。ユーザが電話装置を用いて本システムとコンタクトをとると、システムはユーザを認識し、本システムのオペレータターミナルに対し、過去リクエスト・リスティングテーブルを転送する。

Description

本発明は、リクエスタが通信装置のユーザとコンタクトをとることを可能にするシステム及び方法に向けられ、特に、ある特定のリクエスタからの過去のリクエスト・リストを格納し、かつ優先順位付けをするシステムおよび方法に向けられる。

関連出願

本願は、２００２年１月２日に出願された米国仮特許出願第６０/３４５，６７４号、発明の名称「通信補助システムおよび方法」に基づく優先権を主張するものであり、その全体は参照により本明細書に組み込まれる。

現行の番号案内システムの難点の一つは、そのシステムを利用するリクエスタが、頻繁に同じ情報またはリストを要求する場合に生じる。現行の番号案内システムにおけるこのような状況下においては、リクエスタがリクエストをするたびに、オペレータが検索条件を入力する必要がある。このような構成においては、番号案内オペレータは、長期間にわたって、同一のリクエスタのために何度も同じディレクトリ・リストを検索することを求められる。これは、オペレータの時間を無駄に使用することになり、同様に、同じリスト情報を頻繁にリクエストするリクエスタにとっても、フラストレーションとなる。

しかるに、リクエスタがおなじ情報リストを頻繁にリクエストする場合には、番号案内オペレータによるデータの取得をより効率的にできるようなシステムおよび方法を有することが望ましい。また、頻繁にリクエストされるリストが再度要求された場合に、リストの検索時間を短縮するために、頻繁にリクエストされるリストを有意義に利用できるシステムを作ることも望ましい。携帯電話やＰＤＡのような無線遠隔装置に用いられる技術と、それらをサポートするネットワークの発達により、携帯機器と番号案内プロバイダの間で、双方が高頻度に呼出される番号にアクセスできる状態であるようにデータを同期させることが必要とされる。

本発明は、リクエスタが頻繁に同じ情報リストを要求する場合、番号案内オペレータによるデータの効率的な取得を容易にするシステムと方法を有利に提供する。本システムは、所定のリクエスタにより過去にリクエストされたリストを格納し操作することによって、頻繁にリクエストされたリストを有意義に利用することが可能であり、それを整理してオペレータに示し、頻度高くリクエストされるリストが再度要求された場合に、リストの検索時間を軽減させるようにすることができる。

この目的を達成するために、地上ラインまたはワイヤレスのいずれかのリスティングのための番号案内システムは、リクエスタ・リスティングテーブルを採用する。このリクエスタ・リスティングテーブルは、リクエスタの電話番号およびリクエスタの出したリクエストの日時を追跡する。リストが求められると、その情報はリクエスタ・リスティングテーブルに格納され、このテーブルに番号案内システムにより提供される情報が読み込まれる。

リクエスタがリストを要求するために電話をした後、かつオペレータがリスト検索を行う前に、番号案内システムはリクエスタの電話番号に一致するものがあるかどうかを見るために、過去にリクエストされたリストのテーブル（過去リクエスト・リスティングテーブル）を検索する。もし一致するものがあれば、過去にリクエストされたリストがオペレータに対して提示され、リクエスタの電話番号、過去にリクエストされたリスト、およびこれらのリストに関連する日時情報を表示する。リクエスタによってリクエストされている現行のリストがスクリーン上に表示されていれば、オペレータはリストを検索する手間が省け、その代わりリクエスタを直接所望のリストへ移行させることができる。従って、オペレータとリクエスト双方の時間の節約となる。

過去リクエスト・リスティングテーブルはさらに、格納されたリストのカテゴリを表形式にして構成される。このようなカテゴリには、レクリエーション、映画、レストラン、商業用店舗、１−８００番号、航空会社、ホテル、タクシーおよび個人の番号を含むが、これに限定されない。このカテゴリ指定は、過去リクエスト・リスティングテーブル上で直接利用することが可能であるし、あるいは、格納されたリストを、各々のカテゴリとリクエストされた回数によってさらに編成した、トップリクエストリスティング・サブテーブル９４を提供して、リクエスタがさらに速く所望のリストに接続できるようにしてもよい。

ここで、同じ参照番号は同じ構成要素を意味する図面を参照すると、図１において、本発明の一実施例による通信補助システム２が示される。リクエスタ４は、デバイス６の識別番号を知らない場合であっても、システム２によって、デバイス６との通信を開始することができる。デバイス６は、ワイヤレスまたはワイヤラインサービスへの加入者により使用される装置を参照し、リクエスタ４が連絡をとろうとしている装置を検索するために、アプリケーション全体を通じて利用される。リクエスタ４は、従来のワイヤライン・ローカル・エクスチェンジ・キャリア（ＬＥＣ）およびまたはインターエクスチェンジ・キャリア、ワイヤレスキャリア（音声およびデータアクセスを含む）、またはインターネットへの接続を介して、システム２にアクセスすることができる。デバイス６は、携帯電話およびモデム、ポケットベル、ＰＣＳ電話およびモデム、ＲＩＭ（Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ）社Ｂｌａｃｋｂｅｒｒｙ、ワイヤレスＰＤＡ、インスタントメッセージ装置、ＳＭＳ装置等を含む、周知のいかなる通信装置であってもよい。

本発明は、地上ライン電話、ビジネス電話および音声通信能力を伴うパーソナル携帯情報機器（ＰＤＡ）等のいずれにも適応できるように実施可能であると考察される。

加入者６は、その情報が本システムにより検索されるように格納されている個人またはビジネスのエンティティであれば、いかなるものでも参照する。図１は、このようにワイヤレス装置を使用する加入者を表しているが、地上ライン電話番号、ポケットベル番号、電子メールアドレス等の加入者６に関連するいかなる通信情報も、本システムによって格納および検索が可能であると認められる。また図示する上で、リクエスタ４は、情報を探すためにシステム２にアクセスするリクエスタ４全体を指す。リピートリクエスタ４は、システム２によって、その情報をシステム２に提供するよう促され、検索可能な加入者６のリストを含むデータベース内に、これらの情報が組み込まれることに留意することが重要である。

通信補助システム２は、好ましくは、ワイヤレスＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）８を直接経由して、または公衆交換電話網(ＰＳＴＮ) １０を介して、一つ以上のサービスプロバイダ２６と連結される。

一般に、デバイス６は、図１で示すモバイル・スイッチング・センター（ＭＳＣ）８を介して、システム２と通信を行う。図示はされていないが、デバイス６は、ＰＳＴＮ１０と連結しているＭＳＣ８を介して、システム２と通信可能であると考察される。

図１に示すように、システム２は、好ましくは、一つ以上のスイッチ、統合型音声応答装置（ＶＲＵ）１２（ＶＲＵは上記のような統合型ではなくスタンドアロン型でもよい）、課金データベース１４、主コールセンター１６、エージェントによって操作可能な高度サービスモジュール２１にアクセスしているエージェントアップリケーション１９を実行しているリスティング・データベース１８および複数のオペレータターミナル２０、クロージングプロンプト・ストレージモジュール１３、呼出し完了テーブル１７、広域ネットワーク２５（ＷＡＮ）、エージェントアプリケーション１９に連結されるクロージングプロンプト・モジュール２７、コンピュータ・テレフォニ・インターフェース２９（ＣＴＩ）、発信者データベース３１を備える。特に、課金データベース１４はＷＡＮ２５に接続され、システム２のどの構成要素とも連結させることが可能である。ユニット１２は、主コールセンター１６と同様に、モバイル・スイッチング・センター（ＭＳＣｓ）およびＰＳＴＮ１０に連結される。主コールセンター１６はまた、少なくとも一つのオペレータターミナル２０およびリスティング・データベース１８に連結される。

主コールセンター１６およびオペレータターミナル２０は、それらの間で音声通信が直接送信され、データ情報がコンピュータ・テレフォニ・インタフェース２９を介して送信されるように接続される。

後述するように、これはまた、帯域内周波信号を介して実現することも可能である。オペレータターミナル２０は、リスティング・データベース１８だけでなく、他のデータベースやソフトウェアアプリケーションモジュールとも接続される。

本発明の好ましい実施例においては、図１に示す、システム２およびシステム２’のような複数のコールセンターを国内の様々な地理的位置に戦略的に配置することができる。例えば、各コールセンター、システム２またはシステム２’は、米国全体に広がる主な大都市圏に配置可能である。各コールセンターは、考えられるすべてのタイプの呼出しを包括することが可能なコールセンター用に指定されたコールトラフィックに対処するよう構成されている。

稼動中に、システム２が操作上の問題またはその容量を超えるリクエスト量に直面している場合、主コールセンター１６’は、主コールセンター１６から転送された呼出しを受信する。さらに、ネットワーク内のインテリジェント・プレルーティングを通じて、この呼出しを自動的に主コールセンター１６’に配信することが可能である。この構成により提供される重要な利点は、システム２が技術的問題点または高ボリュームの呼出しに直面している場合に、システム２の主コールセンター１６のためのオーバーフローユニットとしてシステム２’の主コールセンター１６’が働くことができることである。この構成により、上記のシステム２の主ダイレクト接続時にブレークダウンが生じた場合でも、主コールセンター１６は、高ボリューム時に呼出しを主コールセンター１６’へと転送できる。

システム２または２’の別の構成要素は、呼出し完了テーブル１７である。呼出し完了テーブル１７によって、スイッチ１２は、最も効率的に呼出しを最終送信先に転送できるアウトバウンドトランクグループを選択できる。例えば、リクエスタ４が従来の番号案内リスト（すなわち、ワイヤラインの会社または居住地リスト）を要求する場合、リクエスタ４のサービスプロバイダ２６は、自身のネットワーク上でこれらの呼出しを完了することを好む場合がある。この場合は、呼出し完了テーブル１７は、リクエスタ４のサービスプロバイダ２６へのアウトバウンドトランクグループを選択する。リクエスタ４がデバイス６のリストを要求する場合、デバイス６のサービスプロバイダ２６のネットワーク経由で呼出しを完了することがより望ましい場合がある。この場合、呼出し完了テーブル１７は、デバイス６のサービスプロバイダ２６へのダイレクトアウトバウンドトランクグループを選択する。

呼出し完了テーブル１７はまた、日時、リクエスタ４のサービスプロバイダ２６、デバイス６のサービスプロバイダ２６、各サービスプロバイダ２６の対応レート、日時、そして送信先のＮＰＡ／ＮＸＸ（これらに限られない）により、各呼出しのための複数のアウトバウンドルートをプログラミングすることを可能にする。

リスティング・データベース１８およびリスティング・データベース１８’は同様に構成されており、互いのミラーイメージであることが好ましい。オペレータターミナル２０は、主コールセンター１６’とリスティング・データベース１８’に直接連結されていないが、オペレータターミナル２０は、ＷＡＮ２５を介してそのように連結されることが可能であり、または、図１、２、３に示すように主コールセンター１６を介して、コールセンター１６’およびデータベース１８’にアクセスすることが可能である。このようにすることにより、システム２において、データベース１８がダウンしたような場合、オペレータターミナル２０がデータベース１８’上に格納される情報を利用して呼出しを完了させることによりその状況を克服する。

システム２のさまざまな構成要素を、モバイル・スイッチング・センター（ＭＳＣ）８と公衆交換電話網（ＰＳＴＮ）１０を介してサービスプロバイダ２６と連結するリンクは、周知のいかなる音声およびまたはデータ通信技術でもよい。これは、広域ネットワーク通信技術およびローカルエリアネットワーク通信技術を含み、例えば、デジタル加入者線（ＤＳＬ）、デジタルＴ１、リースライン、サテライトまたはワイヤレスリンク、統合サービスディジタル網（ＩＳＤＮ）回路、非同期転送モード（ＡＴＭ）、イーサネット、トークンリング、ＦＤＤＩ等を含む。また、システム２やサービスプロバイダ２６およびＰＳＴＮ１０のさまざまな構成要素は、通信リンク全体でのデータ送受信のための適切な通信ハードウェアインターフェースとともに構成されると推定される。

例えば、ワイヤレスサービスプロバイダ２６は、システム２のスイッチ１２に直接連結されたモバイル・スイッチング・センター（ＭＳＣ）８を介して、システム２と直接インターフェースをとることができる。スイッチ１２は、好ましくは統合型音声応答装置を含むいかなるスイッチでもよい。スイッチ１２により実行される多くの機能は当業者にとって周知であり、回線間の電話コールルーティングを含み、例えば、デジタル信号システム、デュアルトーン多周波（ＤＴＭＦ）信号、多周波（ＭＦ）信号、ＩＳＤＮ，ＳＳ７等の間で、ある信号方式を別の信号に変換し、呼出し長と課金のための送信先データ等を取得する。

図１に示すように、呼出しがスイッチ１２に入る際、この呼出しは、リクエスタによりダイヤルされた番号に関連するＤＮＩＳにより識別される。これにより、システム２により生成される適切なデータ、例えば呼出し完了データパケット５０（図５）などを、この呼出しを完了するために正しいスイッチ１２に転送することが可能である。これについてのさらなる詳細は後述する。

図１に示すように、クロージングプロンプト・ストレージモジュール１３は、様々なクロージングプロンプト・メッセージおよびデータを格納するように構成され、スイッチ１２がリクエスタ４からデバイス６への呼出しを完了したときに、スイッチ１２は、詳細を後述する呼出し完了パケット５０から受け取った情報に基づいて、さまざまなクロージングプロンプトのいずれか一つの役割を行うことができるようになっている。図１においては、スイッチ１２は一つだけ図示されているが、システム２の容量を増やすために、システム２においてスイッチ１２はいくつあってもよい。

図２は、スイッチ１２により提供される着信情報レコード１５を示しており、スイッチ１２がリクエスタ４から呼出しを受けた後に、レコード１５は主コールセンター１６に送信される。

本発明の一実施例に従い、着信情報レコード１５には、リクエスタによりダイヤルされた番号フィールド、優先言語コードフィールド、リクエスタの発信側電話番号フィールド、リクエスタサービスプロバイダ・フィールドおよび機能コードフィールドが含まれる、いくつかのフィールドが入っているがこれに限定されない。

リクエスタによりダイヤルされた番号フィールドには、リクエスタ４によってダイヤルされた番号が入っており、着信の発信側スイッチの場所を識別するために使用される。

優先言語コードフィールドには、リクエスタ４が優先する言語を示す情報が含まれる。システム２、特にスイッチ１２は、多くの異なるダイヤル文字列をシステム２用に変換する能力を保持している。リクエスタ４の優先言語を判断するための可能性の一つとしては、ダイヤルされたある特定の番号、例えば、ＮＰＡ−５５５−１８１８からの呼出しを、直接自動的に、例えばスペイン語を話すオペレータ宛に転送する。他には、発信者データベース３１に格納されている情報を利用して呼出しを転送することも可能である。優先言語コードフィールドは、着信情報レコード１５を用いて、スイッチ１２を介し、主コールセンター１６に呼出しを転送するために使用される。

リクエスタの発信側電話番号フィールドは、リクエスタ４の発信側電話番号を保持する。リクエスタサービスプロバイダ・フィールドは、リクエスタ４のサービスプロバイダを伝える。このフィールドによって、システム２は、導入プロンプト、クロージングプロンプト、課金情報、使用トラッキング等のさまざまな機能とともに使用される発信側のサービスプロバイダ２６を識別できる。このデータの使用例の一つは、リクエスタ４のサービスプロバイダ２６とデバイス６のサービスプロバイダ２６間の請求額の清算を可能にすることである。

機能コードフィールドは、リクエスタ４の装置と関連する特別な機能であればどんなものでも識別するために使用することが可能である。これらの機能は、販売促進用料金プラン、標準料金プラン、一括サービスプラン、デバイス性能などを含むが、これに限定されない。例えば、サービスプロバイダ２６は、月々均一料金で無制限の電話番号案内を提供できる。または、プロモーション期間中は無料でサービスを提供できる。

着信情報レコード１５に関し５つのフィールドのみが識別されるが、本発明の要旨の範囲内で、呼出しを完了するために必要なデータをシステム２に提供するために使用されるフィールドはいくつであってもよい。

図１に示すように、課金データベース１４が、課金データのためのリポジトリとして使用され、好ましくは、呼出し日付、呼出し開始時刻、呼出し終了時刻、および結果として生じる時間すなわち呼出し長、リクエスタ４のための発信側電話番号、デバイス６のためのリスティング情報、および発信側および着信側サービスプロバイダを識別するフィールドから成るレコードを含むが、これに限定されない。課金データは、スイッチ１２、ＡＣＤ、ＰＢＸ、エージェントアプリケーション１９およびまたはデータベース１８のいずれからでも累算できるが、これに限定されない。

コールセンター１６および１６’は、ハードウェアおよびソフトウェアから成り、スイッチ１２からのインバウンドコールを受けつけ、標準的な自動呼出し分配（ＡＣＤ）技術を用いて、複数のオペレータターミナル２０へ呼出しを分配する。オペレータターミナル２０は、データベース１８とやりとりをして、デバイス６に対応するリストを検索し取り出す。この検索は、後述するように、テーブル５２Ａから５２Ｅに定義されている単一のフィールドまたはフィールドの組合せを使用して行うことができる。

コールセンター１６および１６’は、これらの機能を達成するために、ネットワーク化された構成においてともに連結された少なくとも一つのプロセッサを備えることが可能であり、パーソナルコンピュータ、ミニまたはメインフレーム演算装置、ルータ、スイッチ等を使用する周知のコンピュータ技術を用いて構築することが可能である。コールセンター１６と１６’の構成および動作は同様であるので、主コールセンター１６についての議論は、主コールセンター１６’について説明していると理解する。

コンピュータ・テレフォニ・インターフェース（ＣＴＩ）２９がコールセンター１６とオペレータターミナル２０の間に配置されている。ＣＴＩ２９は、リクエスタによってダイヤルされた番号およびリクエスタからオペレータターミナル２０への発信側電話番号などの、入ってくるリクエスタ４の呼出しのデータ部分を転送するよう構成され、一方、この呼出しの音声部分は、コールセンター１６とオペレータターミナル２０の間で直接送信される。ここでは検討されていないが、本発明の要旨の範囲内において、入ってくるリクエスタ４の呼出しのデータ部分もまた、帯域内信号方式を使用して（すなわち、呼出しの音声経路とともに）、オペレータターミナル２０に送信することも可能である。

オペレータターミナル２０はまた、データを受信することができ、そのディスプレイ上にデータを表示できるものであれば周知のいかなるコンピュータ装置であってもよい。これは、パーソナルコンピュータ、ＵＮＩＸワークステーション等を含むがこれに限られない。別個のカスタマーサービス担当電話が、システム２の一部として導入され、リクエスタ４と通信するための主コールセンター１６と連結されることが好ましいが、オペレータターミナル２０はこの構成に限られない。例えば、オペレータターミナル２０は、（図示されるように）統合型の電話を含むように構成可能である。換言すれば、カスタマーサービス担当者が、リクエスタ４との口頭の通信を行うことができれば、いかなる構成であっても足りる。さらに、単一のオペレータターミナル２０のみが図示されているが、システム２はこの構成に限られない。システム２は、二人以上のカスタマーサービス担当者がシステム２のユーザに対応できるように、複数のオペレータターミナル２０を備えると考えられる。ここで、主コールセンター１６およびそのスイッチ１２との通信、オペレータターミナル２０およびデータベース１８は、主コールセンター１６’とスイッチ１２’の間の構成と通信と同様に、２００２年６月１１日に発行された米国特許６，４０４，８８４号に記載された接続および通信技術に従って実施することが可能であり、この特許文書の内容は参照により本明細書に組み込まれることに留意すべきである。本発明の別の実施例において、リクエスタ４が、例えば非音声方法を使用して、エージェントとやりとりを行う場合が考察される。非音声方法とは例えば、後述のショートメッセージサービス（ＳＭＳ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ライブ・チャットおよびインスタントメッセージング等であるが、これに限られない。

エージェントアプリケーション１９のプラットフォームは、オペレータターミナル２０およびデータベース１８を操作するために用いられる。このシステムは、これらのモジュール間の通信をサポートするだけでなく、最終的に呼出しを完了するためにスイッチ１２に送られる呼出し完了データパケット５０の準備を行う。

呼出し完了データパケット５０を生成するために、オペレータターミナル２０およびエージェントアプリケーション１９は、データベース１８から検索される情報を必要とする。このデータは、さらに詳細を後述するように、呼出し完了データパケット５０のさまざまなフィールドに読み込むために使用される。

リスティング・データベース１８は、好ましくは、ワイヤライン電話番号簿リスト、リクエスタ４の発信側サービスプロバイダ２６のリスト、ワイヤレスリスト、および商品やサービスのプロバイダというような他のリストのすべて（但し、これに限定されない）を格納するようプログラムすることができるものであれば、いかなる周知のデータベースシステムであってもよい。リスティング・データベース１８は、各ユーザまたはユーザグループを主催している組織体と関連する、かなり大量のリストとマルチメディアデータのために複数のデータベース・テーブルをサポートすることが好ましい。

本発明は、本願明細書において述べられている新規な特徴をサポートするために、いくつかの追加フィールドを含めることによって、米国特許６，４０４，８８４号に記載されているデータベース・テーブルを補強したものであることに留意すべきである。

リスティング・データベース１８は、周知のいかなるデータベース・ソフトウェアやデータベース・フォーマットを基礎にしてもよい。リスティング・データベース１８のハードウェア構成は、それぞれのデータベース・テーブルにおけるユーザとエントリ数をサポートできるハードウェアプラットフォームであればいかなるものでもよい。このように、リスティング・データベース１８は、この情報を記憶できるデバイスであればいかなるデバイス上にも格納できる。

当業者であれば、データベース１８が単一のユニットとして図示されていても、その構成に限定されないということを認めることができる。データベース１８は、複数のハードウェアユニットを備えることができる。すなわち、中央処理装置および／またはＣＤ−ＲＯＭのような記憶装置、ハードディスクドライブ、テープ・ディスクドライブ等であり、それらは伝送リンク全体に亘って互いに通信可能である。さらに、リスティング・データベース１８内の特定のテーブルおよびフィールドのみについて詳細に述べたが、本発明はリスティング・データベース１８内のテーブル・スキーマに限定されない。本発明の一実施例によると、システム２またはシステム２’内のデータベース１８または１８’などの各データベースは、同じ情報を格納する。別の実施例では、リスティング・データベース１８は、分散型データベースの形態をとることが可能であると考察する。例えば、主に西海岸に基礎をおくユーザは、カリフォルニアに配置されるリスティング・データベース１８’などのデータベースの一部からサポートを受けるが、一方、主に東海岸に位置するユーザは、ニューヨークに配置されるデータベース１８などのデータベースの一部にアクセスすることができる。

本発明の一実施例において、リスティング・データベース１８は、リクエスタ４のサービスプロバイダ２６に関連する商標つき音声メッセージを格納し、リクエスタ４がシステム２にアクセスするときに、この音声によるウェルカムメッセージがオペレータターミナル２０により取り出され、リクエスタ４に対し再生される。本発明の他の実施例において、コールセンター１６またはスイッチ１２上で音声によるウェルカムメッセージが取り出され再生されてもよい。このウェルカム音声メッセージについては以下に詳細に論じられる。

リスティング・データベース１８および１８’はまた、図３に示すような接続フィールドを含む。この接続フィールドは、リストの開示可用性の程度を識別する。この接続フィールドは、接続フィールドサブテーブルリスティング７０から成り、これは、リストされているか、されていないかのいずれかにまず番号を分類する。もし番号がリストされていない場合、その番号は呼出しを完了するために使用することはできない。しかし、番号がリストされている場合、接続フィールドサブテーブルリスト７０はさらに、「対エージェント非マスク状態」または「対エージェントマスク状態」というカテゴリにさらに分けられる。「対エージェントマスク状態」の場合は、呼出しは完了可能であるが、リクエスタ４はその番号を受信しない。この場合、番号またはその一部はエージェントまたはカスタマーサービス担当者に対しても同様に遮蔽され、エージェントはその番号にアクセスせずに、単に呼出しが接続される。「対エージェント非マスク状態」の場合は、デバイス６の加入者は、エージェントおよび／またはリクエスタ４に対して番号を明らかにすることを、システム２に許可している。これは、企業体のワイヤレス装置の場合が多い。

リクエスタ４が、マスクリストを要求する場合、そのリストが本発明の過去リクエスト・リスティングの機能に従ってセーブされているときは、その格納されたリスト上でマスクされたフォーマットで、マスクリストが現れることに留意することが重要である。このさらなる詳細はオペレーションセクションにおいて後述する。

図６に示すように、本発明の他の実施例において過去リクエスト・リスティングテーブル９２が提供され、例えば、リスティング・データベース１８に格納される。テーブル９２は、過去のリクエスタ４からの情報とリクエストされたリストに関する各リクエスタの対応情報を格納するよう構成される。過去リクエスト・リスティングテーブル９２は、入ってくるリクエスタ４の番号と関連する、リクエスタ４の呼出し番号フィールドを保持する。このフィールドは、ある特定のリクエスタ４の過去のリクエスト・リストと対応させるように構成され、システム２が、個々のリクエスタ４に基づく過去のリクエスト・リストを識別できるようにする。過去リクエスト・リスティングテーブル９２は、各リクエスタ４が最初にシステム２とコンタクトをとるとすぐに各リクエスタ４に対して生成され、それぞれ追加の呼出しとともに保持されかつ更新される。

その過去リクエスト・リスティングテーブル９２は、システム２により生成され、データベース１８内に格納され、先に提案されたようにオペレータターミナル２０により利用される。しかしながら、これは、テーブル９２を格納するための一つの構成例のみを意図したに過ぎず、本発明の範囲を限定することは全く意図していないことに留意する。

例えば、過去リクエスト・リスティングテーブル９２は、システム２に格納されることが可能であり、サービスプロバイダ２６を介して、リクエスタ４により使用されるワイヤレス装置で直接操作される。このような場合、システム２はサーバ上で過去リクエスト・リスティングテーブル９２を作成かつ格納し、動作可能なプロトコルを介してリクエスタ４のサービスプロバイダ２６に対してリストを送信する。そして、リクエスタ４のサービスプロバイダ２６は、リクエスタ４のワイヤレス装置に対しリストを送る。

この構成において、テーブル９２は、ＷＡＰ（ワイヤレス・アプリケーション・プロトコル）、または、システム２とインターフェースをとり、接続されるべき所望のリストと通信することが可能な他の互換性があるプロトコルを介して操作され得る。この構成は、所望のリストが過去リクエスト・リスティングテーブルに含まれる場合に、所望のリンクに接続するためのより速いサービスを提供し、また、システム２とインターフェースをとるために必要なプロトコルを操作するのに十分なメモリを有するワイヤレス通信装置において特に効果的である。これによって、リクエスタ４は、自身のワイヤレス装置のスイッチを入れれば、その装置上で過去リクエスト・リスティングテーブル９２を検索することが可能になり、リストはシステム２により更新される。より詳細については後述する。

過去リクエスト・リスティングテーブル９２はまた、リスティングリクエスト・フィールドを保持し、これは、ある特定のリクエスタ４によってリクエストされる加入者６情報に対応する。このリスティングリクエスト・フィールドに対応付けされるリスト日時フィールドは、リストが要求された最新の日時を記憶する。リスティングリクエスト・フィールドに対応付けられるカウンタフィールドもまた保持され、これは、ある特定のリストがリクエスタ４によりリクエストされた回数をトラッキングする。

本発明の一実施例において、過去リクエスト・リスティングテーブル９２は、長時間ダイヤルされなかった番号は再度リクエストされる可能性が低いという前提に基づいて、ある設定された時間だけ過去リクエスト・リストを格納するよう構成されている。例えば、過去リクエスト・リスティングテーブル９２は、テーブル９２上の各リストはリクエスタ４によって最近９０日以内に少なくとも一回リクエストされたものであるという、９０日間の格納タイムフレームを有してもよい。

さらに、ある特定のリストがリクエストされた回数に従って、このタイムフレームを修正してもよい。例えば、過去リクエスト・リスティングテーブルに対する基礎タイムフレームは、一回リクエストがされたリストに対して９０日としてもよい。しかし、ある特定のリストが３回リクエストされた場合は、過去リクエスト・リスティングテーブル９２はこのリストを１８０日間保持する。これは、このリストは、一度だけリクエストされたリストよりも将来再度リクエストされる可能性が高いという予想に基づく。

ある特定のリストが過去リクエスト・リスティングテーブル９２に格納される期間を変更する他の可能な方法は、リストが要求されるたびに９０日の格納期間をリセットすることである。この構成において、最初の９０日の格納期間内であるリストが二度目にリクエストされると、この格納期間はリセットされ、さらに９０日間このリストは格納される。過去リクエスト・リスティングテーブル９２のリストに対するストレージの設計数はいくつであってもよいと理解される。これによって、このテーブルは、所望のリストを検索するために必要とされる時間を軽減するため、オペレータターミナル２０により要求される時間量を減らす際に効果的である。

この点で、過去リクエスト・リスティングテーブル９２は、ある特定のリクエスタ４のために過去にリクエストされたリストの数を保持するよう設計されている。これによって、このテーブルは、必要以上の数の期限切れのリストをふるいにかける必要なく、多くのリクエストの効率を上げるために十分な数の過去リクエスト・リストをオペレータターミナル２０に提供する。

所与のリクエスタ４に対し、過去リクエスト・リスティングテーブル９２上で十分なリストを維持するためのこのような標準の一つは、リクエスタ４の呼出しのほぼ２０％がこのリストから完了されるようにするために十分なリストを格納することである。この所望の比率を達成するために、過去リクエスト・リスティングテーブル９２上に格納されるリスト数を操作するためのさまざまな方法が使用できる。例えば、上記のように、格納期間を９０日間引き伸ばすことについては、適切な数のリストが過去リクエスト・リスティングテーブル９２上に格納されるまで、１２０日まで上げて調節してもよいし、４５日に下げて調節してもよい。

過去リクエスト・リスティングテーブル９２のリストを管理するための他の方法として、格納されたリストのカテゴリに基づいて格納時間を調整してもよい。例えば、ホテルおよび航空会社のカテゴリ上のリストは、これらの番号が長期間再度コンタクトされないという理論の下で、３０日間のみ格納可能し、一方、個人連絡先リストは、より頻繁にリクエストがあるという理由で１８０日間格納してもよい。

さらに、所望の２０％完了目標に到達するための他の可能な方法は、過去リクエスト・リスティングテーブル９２上に格納されるべきリストの最大数または最小数を設定することである。

最小数の場合、テーブルのリスト量が少ないときに、システム２が、いくつかの方法によって、過去リクエスト・リスティングテーブル９２にリストを追加する。この方法とは、例えば、最初の映画館がリクエストされたときに、可能性のあるリストを予測することを試みることによって、さらに近傍の映画館も追加するなどの方法である。あるいは、最大数の場合、過去リクエスト・リスティングテーブル９２上のリスト数がより高い数字になると、過去リクエスト・リスティングテーブル９２の効率を維持するために、ホテルおよび航空会社などのカテゴリにある特定のリストを早めに（格納期間が満了する前に）リストから落とすようにしてもよい。

いずれにしても、過去リクエスト・リスティングテーブル９２の目標は、所望のリストを検索するために必要な時間量を減少させることである。このために、例えば、リクエスタ４によりリクエストされたリストの２０％がテーブル９２を介してオペレータターミナル２０と接続できるようにして、システム２は過去リクエスト・リスティングテーブル９２上に多くのリストを維持しようとする。

過去リクエスト・リスティングテーブル９２上にあまりに多くのリストが入れられた場合、オペレータターミナル２０がテーブル９２上のすべてのリストを検索する時間がかかりすぎて、そもそもテーブルを有する目的が意味をなさない。テーブル９２上にほとんどリストが保持されていない場合は、データベース１８全体を連続的に検索する必要があり（テーブル９２に含まれていない、リクエストされたリストを取り出すために）、検索できる回数が減ることになる。このように、過去リクエスト・リスティングテーブル９２から取り出されるべきリクエストの最適な比率数は、リスト検索時間を軽減するという所望の目標を達成する必要がある。

しかしながら、過去リクエスト・リスティングテーブル９２から検索されるリクエスト・リストの所望の比率２０％というのは、例示のみを意図するものであって、本発明の範囲を限定するものではないことに留意すべきである。例えば、この比率は、下記で説明するように、その特定のリクエスタ４からのリクエストの一貫性や非一貫性により、上下に調節することが可能である。

例えば、リクエスタ４が、リストのうちの小さいグループからのリストを頻繁に要求する場合は、過去リクエスト・リスティングテーブル９２上に含まれる情報から完了されるべき呼出しの目標比率は、リクエスト検索回数を効率化するために、上記のパラメータを用いて３０％または４０％に上げて調節され得る。あるいは、リクエスタ４が頻繁にランダムリストを要求する場合は、過去リクエスト・リスティングテーブル９２があまりに多くの無関係なリストで雑然とならないように、上記のパラメータを再度調節して、目標比率が１０〜１５％に引き下げられてもよい。リクエスタ４により要求されるリストのための検索時間を軽減させるという視点は、常に、過去リクエスト・リスティングテーブル９２のパラメータを調節する際の判断要因である。

いずれにしても、上記の過去リクエスト・リスティングテーブル９２に設定するための上述のすべてのパラメータは、システムにより使用される可能な設定の例示のみを意図するに過ぎず、本発明の範囲を制限するものではないことに留意すべきである。このようなパラメータは、過去リクエスト・リスティングテーブル９２に対し単独でまたは組み合わせて使用され、その結果、頻繁にシステム２にコンタクトをとるリクエスタ４により要求されるリストを検索する効率が上がるようにする。

過去リクエスト・リスティングテーブル９２のフィールドに含まれる情報は、多くの異なるバリエーションで編成され得る。例えば、リスティングリクエスト・フィールドは、リクエストが作成されるごとに別々のエントリを含むようにしてもよいし、あるいは、リクエストされたリストごとに単一のエントリを維持し、カウンタフィールドに、そのリストが要求された回数を入れて表にしてもよい。

図６に示したように、本発明の一実施例において、過去リクエスト・リスティングテーブル９２は、検索されたリストのカテゴリを格納するためのカテゴリ・フィールドを維持する。例えば、リクエスタ４がレストランのリストを必要とする場合、そのエントリが過去リクエスト・リスティングテーブル９２に格納され、そのカテゴリ・フィールドはそのエントリとしてレストランの表記を保持する。同様に、リクエスタ４がガソリンスタンドを要求する場合、ガソリンスタンドまたはサービス全般の表記がカテゴリ・フィールド内のリストの次にエンターされる。

カテゴリ・フィールドの指定は、レクリエーション、映画、レストラン、商業用店舗、１−８００番号、航空会社、ホテル、タクシーおよび個人番号を含めてもよい。このリストは、カテゴリ情報を指定するための可能な方法の例示のみを意図するに過ぎず、本発明の範囲を限定することは全く意図していない。過去リクエスト・リスティングテーブル９２のカテゴリ・フィールドに入力するために使用されるカテゴリ指定はいかなるものであっても、本発明の考察の範囲内である。

過去リクエスト・リスティングテーブル９２にはカテゴリランキングフィールドも備えられており、カテゴリ・フィールドに格納されるある特定のカテゴリ指定を有する各リストに対し、対応するカテゴリランクが各リストに属するようにしている。例えば、ある特定のリクエスタ４が、三つの異なるレストランリストをリクエストした場合、つまり、第一のレストランは４回、第二のレストランは３回、第三のレストランは１回、とすると、これらはそのカテゴリランクの中で、１、２、３とそれぞれランク付けされる。このランク付けのための情報は、カテゴリまたはカウンタフィールドからの情報の組合せを使用して、システム２により生成されるか、または、他の基準を用いて独立して生成することができる。

図６Ａに示したように、本発明の一実施例において、トップランクリクエスト・サブテーブル９４が提供され、カテゴリ・フィールドおよびカテゴリランクフィールドに含まれる情報に基づいてリストを編成するように構成されている。トップランク・リスティング・サブテーブル９４は、前述したような過去リクエスト・リスティングテーブル９２に格納されるリクエストのカテゴリに基づいた、いくつかのフィールドを含む。

例えば、トップランク・リクエストテーブル９４は、レストラン・フィールド、個人連絡先フィールド、1-８００番号フィールド、および特定のリクエスタ４によって頻繁にリクエストされる他のいかなるカテゴリも備えてもよい。テーブル９４にある各フィールドは、リスティングテーブル９２からの各カテゴリに対するトップランクのリスティングのリストを維持し、これによってさらにオペレータターミナル２０によるリストの検索が容易になる。

例えば、トップランク・リクエストテーブル９４のレストラン・フィールドは、カテゴリランクフィールドにより識別された、過去リクエスト・リスティングテーブル９２からの、トップ５のリクエストされたレストランリストを示すものである。同様に、トップランク・リクエストテーブル９４の個人連絡先フィールドは、過去リクエスト・リスティングテーブル９２からの、トップ５のリクエストされた個人リストを示したものであり、各カテゴリに対しても同様である。トップランク・リクエストテーブル９４のさまざまなフィールドに格納された、このランク付けカテゴリリストの数は、システム２のリスト検索時間を改善するために使用される、可能な方法とカテゴリ情報のリスト量の例示のみを意図するに過ぎず、本発明の範囲を制限することは全く意図していない。トップランク・リクエストテーブル９４において使用されるカテゴリのリスト数または種類は、いかなるものであっても本発明において考慮される。

図６Ａに示すように、トップランク・リスティングテーブル９４は、別個のテーブルにおける目録であってもよいが、これはカテゴリのランキングを使用してリストの検索時間を改善するための一つの可能な方法のみを意図するに過ぎないことに留意すべきである。例えば、過去リクエスト・リスティングテーブル９２からのカテゴリランキングフィールド情報を利用するための他の手段として、過去リクエスト・リスティングテーブル９２において、直接、各カテゴリに対するトップランクリストを強調表示し、オペレータターミナル２０において注意を引くようにし、リスト検索時間を向上させることも可能である（図示せず）。各カテゴリに対するトップランク・リクエストリストに注意を向けることにより動作する、いかなる類似の方法も本発明の考察の範囲内である。

全てのリクエストが格納されると、各リクエストの日時が各々のリクエストに対し格納される。各リストのための一つのエントリが格納されると、そのリストに対する最後のリクエストの日時も格納され得る。過去リクエスト・リスティングテーブル９２に情報を格納するための多数の組合せが、システム２のオペレータに対して可能であり、それについてはあまりに数が多いので詳細に述べることはできないことに留意すべきである。説明の便宜上、システム２の実施例を示すために使用される内容は、各リストに対する単一エントリとリクエストがされる毎のカウンタフィールドへのエントリを保持している過去リクエスト・リスティングテーブル９２を示すものである。

リクエスタ４がリピート発信者であるとシステム２が決定し、システム２が、しかるべき過去リクエスト・リスティングテーブル９２用にデータベース１８を検索すると、その情報はオペレータターミナル２０の画面上に置かれる。これについてはオペレーションセクションにおいて、さらに詳細を述べる。

過去リクエスト・リスティングテーブル９２およびトップランク・リスティングテーブル９４は双方とも、システム２の他の構成要素から収集された情報を使用して、頻繁に更新され再読み込みされる必要がある。過去リクエスト・リスティングテーブル９２およびトップランク・リクエストテーブル９４は、一日一回、一時間に一回、またはリアルタイムで再読み込みすることが可能である。再読み込みのための速度の選択は、システム操作上の観点からシステムにおける最高効率を求めて決定されるか、または所定のリクエスタ４のためのリストを適正に機能させるために必要な更新回数のサンプルにより決定される。あるいは、可能であればその組合せにより決定される。

テーブル９２が、上記のようにリクエスタ４のワイヤレス装置に再送されるように、ワイヤレスキャリア２６用のサーバに維持される場合には、テーブル９２はそれに従って更新される。例えば、サービスプロバイダ２６用のサーバは、上記のように一日に一回、一時間に一回またはリアルタイムベースで更新され、リクエスタ４のワイヤレス装置上の目録としてのリストは、リクエスタ４がそのワイヤレス装置の電源の入切をしたとき、あるいは他の類似の可用タイムフレームで更新してもよい。その場合、そのワイヤレス装置は、テーブル９２に対応するコピーを格納する。その後、そのワイヤレス装置のユーザは、番号案内のための電話をすることなく、リストを検索できる。リクエストされたリストがコピーされたテーブル９２に存在しない場合、ワイヤレス装置のユーザは番号案内を呼び出す。このような場合、この番号案内は、リクエスタがすでにワイヤレス装置に格納されたテーブルのコピーからの番号検索を試みたという仮定に基づいて、過去リクエスト・リスティングテーブル９２は検索してはならない。

本発明の一実施例によれば、過去リクエスト・リスティングテーブルは、リクエスタ４が手動で更新されてもよい。これは、ウェブサイト（ＨＴＴＰ）、ＳＭＳまたはＷＡＰインターフェースまたは互換性のあるプロトコルを使用する他のインターフェースを介して、直接システム２にアクセスすることによって実現される。

動作において、課金データベース１４に格納されている、過去リクエスト・リスティングテーブル９２のメンテナンスとオペレーションと関連させて、システム２のためのさまざまな課金オプションを利用することができる。このような課金オプションは、過去リクエスト・リスティングテーブル９２を維持するためのチャージ、過去リクエスト・リスティングテーブル９２からの接続を受けるためのチャージ、テーブル９２を更新する速度に基づく追加費用のチャージ、テーブル９２に対する拡張内容に基づくチャージ、およびサービスプロバイダ２６を経由してリクエスタ４のワイヤレス装置から操作されるサービスを維持するためのチャージを含んでもよいが、これに限定されない。

このリストは、過去リクエスト・リスティングテーブル９２と関連するシステム２のための可能な課金構成の例示のみを意図し、本発明の範囲を限定することは全く意図していないことに留意すべきである。過去リクエスト・リスティングテーブルに関連する課金構成、または過去リクエスト・リスティングテーブル９２のシステム２の他の機能との組み合わせは、本発明が考察する範囲内である。

クロージングプロンプト・モジュール２７は、図５に示すように、呼出し完了データパケット５０のクロージングプロンプトコード・フィールド５８のような定義フィールドに含まれる、クロージングプロンプト識別データを提供する。上記のように、呼出し完了データパケット５０は、しかるべきクロージングプロンプトを起動させるためのコマンドでスイッチ１２に指示を与える。図５を参照して以下により詳細に説明するように、クロージングプロンプト・モジュール２７は、呼出し完了データパケット５０を作成するためにエージェントアプリケーション１９と連携して機能する。呼出し完了データパケット５０は、スイッチ１２に認識される呼出し完了データパケット５０のクロージングプロンプトコード・フィールド５８に基づいてクローズ・プロンプトを生成するために、スイッチ１２に情報を提示する。クロージングプロンプト・モジュール２７は、物理的に独立した装置として存在するか、または、エージェントアプリケーション１９のソフトウェアの機能モジュールとして存在することが可能である。

本発明の一実施例を上記のように説明したが、本発明では、呼出し完了データパケット５０にあるクロージングプロンプトコード・フィールド５８に基づいてクロージングプロンプトを生成するために、呼出し完了パケット５０は、例えば、ＡＣＤ、ＰＢＸ、スタンドアロンＶＲＵ（ボイス・レスポンス・ユニット：音声応答装置）／ＡＳＲ（アドバンスト・スピーチ・レコグニション：最新式言語認識）、アプリケーションソフトウェア等のハードウェアおよびソフトウェアのいかなる組合せによっても使用され得ると考える。

図４に示されるように、クロージングプロンプト・モジュール２７は、クロージングプロンプト処理モジュール６４、オーバーライドモジュール６６および呼出し完了データテーブル６８を備える。呼出し完了データテーブル６８は、クロージングプロンプト・モジュール２７内の別個のテーブルであるか、または、クロージングプロンプト処理モジュール６４にあるソフトウェアとして存在するかのいずれかが可能である。本発明の別の実施例において、クロージングプロンプト処理モジュール６４およびオーバーライドモジュール６６は、スイッチ１２に属すか、あるいは、ＡＣＤ、ＰＢＸ、スタンドアロンＶＲＵ／ＡＳＲ、アプリケーションソフトウェアなどのハードウェアおよびソフトウェアのいかなる組合せに属し得る。

新規のリクエスタ４の場合は、クロージングプロンプト・モジュール２７は、リクエスタ４が加入者６の（リスティングテーブル５２Ａに格納される）リストを設定するように促すクロージングプロンプトを生成してもよい。これによって、システム２はより完全な加入者６のデータベースを累積できる。

エージェントアプリケーション１９のソフトウェアは、その後、呼出し完了データパケット５０を生成する。あるいは、クロージングプロンプト・モジュール２７、または他のいくつかのアプリケーションが呼出し完了データパケット５０を生成できる。しかし、説明の便宜上、エージェントアプリケーション１９が、呼出し完了データパケット５０を形成することとする。図５に示したように、呼出し完了データパケット５０は、複数のデータフィールドから成る。これは、リクエスタ発信側電話番号フィールド５４、デバイス識別番号情報フィールド５６、クロージングプロンプトコード・フィールド５８および事前通知フィールド５９を含むことができるが、それらに限定されない。

呼出し完了データパケット５０は、着信情報レコード１５、データベース１８からのリスティングテーブル５２Ａ、クロージングプロンプト・モジュール２７からの情報を用いて、オペレータターミナル２０において、エージェントアプリケーション１９により形成される。この情報は、その後編成され、呼出し完了データパケット５０のフィールドに読み込むために使用される。

発信側電話番号フィールド５４は、リクエスタ４の発信電話番号である。デバイス識別番号情報フィールド５６は、リクエストされた加入者６のリストである。この情報は、リスティング・データベース１８から検索されたリストによって、オペレータターミナル２０に与えられる。デバイス識別情報フィールドは、完了した呼出しの適正な発信先を識別する。この情報は、リクエスタ４を適正にデバイス６に接続するために用いられる。後述するように、適正なリストは、検索によって、オペレータターミナル２０により取り出されるか、または、繰返しリクエストさらた場合は、過去リクエスト・リスティングテーブル９２またはトップランク・リスティング・サブテーブル９４から提供される情報から、直接入力される。

呼出し完了データパケット５０のクロージングプロンプトコード・フィールド５８は、リクエスタ４のために、どのクロージングプロンプトにおいて、検索、使用および再生を行うかの指示を含む。

上記のように、新規のリクエスタ４に対しては、呼出し完了データパケット５０のクロージングプロンプト・フィールド５８は、加入者６のレコードを生成するために、システム２にそれらの情報を提出するようにリクエスタに促すことに向けられているクロージングプロンプト用の指示を含んでもよい。呼出し完了データパケット５０の事前通知フィールド５９は、音声応答装置（ＶＲＵ）に対して、事前通知機能が作動しているかどうかを表示する。事前通知機能が作動している場合、ＶＲＵは音声またはテキストメッセージによって、デバイス６に対してリクエスタ４の識別を知らせ、ワイヤレス装置６が呼出しを受け付けるかどうかを決定できるようにする。

組み合わせると、リクエスタ発信側電話番号フィールド５４、デバイス識別情報フィールド５６、クロージングプロンプトコード・フィールド５８、および事前通知フィールド５９は、呼出しを開始および完了させ、しかるべきクロージングおよび事前通知を行うために必要な情報をすべて含む。

広域ネットワーク（ＷＡＮ）２５は、すべてのオペレータターミナル２０をシステム２と２’につなげるよう構成される。これは、地理的位置間の接続を含み、コールセンターに位置するオペレータターミナル２０が、他の遠隔地にあるスイッチ１２と接続できるようにする。上述したように、かつ、さらに詳細に後述するように、主コールセンター１６は、呼出しを遠隔地のオペレータターミナル２０’に送るので、適正な呼出しに接続するために、これらのオペレータターミナル２０’は発信側スイッチ１２に通信を返すことができる必要がある。ＷＡＮ２５は、リクエスタ４の呼出しを完了するために、呼出し完了データパケット５０をしかるべきスイッチ１２へと中継するよう構成される。システム２内のＷＡＮ２５の機能のより全面的な説明については後述する。

オペレータターミナル２０の一つによってサポートされている、エージェントアプリケーション１９は、広域ネットワーク２５（ＷＡＮ）を経由しシステム２、２'などを連結して、オペレータターミナル２０を介してスイッチ１２のいずれか一つと通信する。ＷＡＮ２５により、オペレータターミナル２０におけるカスタマーサービス担当者が、オペレータターミナル２０からスイッチ１２のいずれか一つに対して呼出し完了データパケット５０を送信できる。いくつかの理由により、エージェントアプリケーション１９がうまく呼出し完了データパケット５０を渡すことができない場合、エージェントアプリケーション１９は、ＤＴＭＦ等の帯域内信号方式を用いて、呼出し完了を開始できる。上記理由には、ＷＡＮ２５が使用できない場合や、呼出し完了データパケット５０が拒絶される場合などが含まれるがそれらに限られない。これによって、エージェントアプリケーション１９は、発信者を穏やかに電話待ち状態にし、同じ回線を介してスイッチ１２に発信先の数字を渡すことができる。スイッチ１２は、その後、その数字を受付け、コールセンター１６への呼出しを解放し、後述するように呼出し完了を開始する。

呼出し完了処理の一部として、スイッチ１２は、加入者６に対するリクエスタ４の完了のために使用される最適なトランクグループを選択する能力を備える。例えば、スイッチ１２が加入者６のサービスプロバイダ２６に対する直接的な接続を備える場合、この呼出しの完了はこのリンクを通じて実施される。

スイッチ１２が加入者６のサービスプロバイダ２６への直接的な接続を備えていなかった場合は、この呼出しの完了はＰＳＴＮ１０を介して行われる。これによって、スイッチ１２は、呼出しを加入者６に配信する最も費用効果的な手段を選ぶことができる。このアウトバウンドトランクグループの選択は、呼出し完了データパケット５０に含まれる情報に基づいて、（図１に示すように）呼出し完了テーブル１７により決定されてもよい。例えば、呼出し完了データパケット５０のデバイス識別情報フィールド５６にある番号のＮＰＡ．ｎｘｘは、そのリスティングのためのサービスプロバイダ２６を示すために用いることができる。この情報は、スイッチ１２からサービスプロバイダ２６への直接的な接続が存在するかどうかを決定するために用いられる。このような直接的な接続が存在する場合、この呼出しのための第一の選択ルートは、そのリンクを経由するものである。このような直接的な接続が利用できない、または存在しない場合は、ＰＳＴＮ１０への接続というような代替のルートも使用可能である。

図７のフローチャートに示されているように、先ずステップ１００において、リクエスタ４がシステム２を呼び出す。システム２にアクセスするための方法は、「８００」番号、ＮＰＡ．ｎｘｘ．ｘｘｘｘ番号またはＮＰＡ−５５５−ｘｘｘなど周知のいかなるダイヤルパターンであってもよいが、「４１１」、「５５５」、「＃５５５」等の短縮情報タイプの番号であってもよい。好ましくは、システム２へのアクセスは、リクエスタ４によってダイヤルされるアクセス番号が全国的に利用できるように構成されるようにし、リクエスタ４が、その所在地による個々のアクセス番号や、ワイヤレス装置またはワイヤライン装置を介してシステム２にアクセスしているか否かを考慮する必要がないようにする。

過去リクエスト・リスティングテーブル９２またはトップランク・リスティングテーブル９４が、サービスプロバイダ２６と通信するためのサーバに格納されており、上記のように、サービスプロバイダ２６が、今度はリクエスタ４のワイヤレス装置と通信し、リクエスタがそこに含まれるリストのうちの一つと通話を行いたいと望む場合、その呼出しは、ワイヤレスキャリア２６を直接経由して、ワイヤレス装置から直接ダイヤルされることに留意すべきである。その呼出しはまた、任意のオペレータターミナル２０の番号案内リスト検索をバイパスして、呼出しが直接完了へと進むことができるようなテーブル９２の構成に基づいて、システム２のスイッチ１２を介して処理され得る。

ステップ１０２において、モバイル・スイッチング・センター（ＭＳＣ）８が、リクエスタ４によってダイヤルされたパターンがシステム２に帰属すると認識し（すなわち通信補助の要求）、その呼出しを、リクエスタ４の発信側電話番号とともにスイッチ１２へと配信する。スイッチ１２は、ＭＳＣ８から呼出しを受け取ると、呼出し詳細情報を追跡する。

スイッチ１２は、追加的な機能として、ダイヤル番号とＡＮＩ文字列を認識し変換する能力を有し、これによって、システム２がエージェントアプリケーションを複数の顧客に提供できる。しかるべき番号をダイヤルすると、ＭＳＣ８は、ダイヤルされた番号文字列が通信補助システム及び方法に属しておりインバウンドコールをスイッチ１２へ配信することを認識するよう構成されている。必要であれば、スイッチ１２に呼出しを配信する前に、ＭＳＣ８は、ユーザのダイヤル文字列（例えば＃５５５）をシステム２により認識される数字列に変換してもよい。

この変換によって、ユニバーサルアクセス番号または異なるユーザダイヤル文字列のいずれかを使用して、異なるサービスキャリアが、本発明により提供されるサービスにアクセスすることが可能になる。例えば、二つのキャリアが異なるダイヤル文字列を使用すると決めた場合（すなわち、携帯電話キャリアＡはダイヤル文字列＊５によって、システム２へのアクセスをサポートするが、携帯電話キャリアＢは、ダイヤル文字列４１１を用いてこのサービスにアクセスできる）、各キャリアのモバイル・スイッチング・センター（ＭＳＣ）８は、呼出しをスイッチ１２へ配信する前にこのダイヤル文字列を変換することを選択してもよいし選択しなくてもよい。このインバウンドコールを受信すると、スイッチ１２はさらにＭＳＣ８のダイヤル文字列を変換し、主コールセンター１６に対してこの呼出しを配信する。スイッチ１２により送信される番号によって、システム２は、実際のＭＳＣダイヤル文字列とともにダイヤル文字列を受信したときの送信元である特定のＭＳＣ８を識別することが可能となり、システム２の構成要素は、どのようなサービスが望まれており、インバウンドコールがどこから発信されているかを判断できる。図１に示すように、呼出しがワイヤラインキャリアおよびまたはＶｏＩＰキャリアから発信される場合もあるということは本発明により考察される。

例えば、スイッチ１２は、モバイル・スイッチング・センター（ＭＳＣ）８のダイヤル文字列４１１を、９６０５などの任意の４桁の数字に変換してよい（この文字列長は例示のみであって、変更可能である）。この４桁列は、呼出し完了データテーブル６８のリクエスタによりダイヤルされた番号フィールド６０Ａに読み込むために使用される。変換された数字列は、ダイレクト・インバウンド・ダイヤル（ＤＩＤ）番号と呼ばれる。各スイッチ１２は、異なるサービスに対するリクエスタ４の要求やその呼出し位置を識別するために、複数のＤＩＤ番号を有することが可能である。

この技術を使用して利用可能なさらなる機能は、システム２に対して、優先言語情報のインジケータとして別のダイヤル文字列を提供することである。例えば、ＮＰＡ.５５５．１８１８ＴＭというようなダイヤル文字列が使用される場合、スイッチ１２は、ＭＳＣダイヤル文字列を変換した後、着信情報レコード１５内にスペイン語優先インジケータを自動的に送信し、主コールセンター１６が、スペイン語を話すオペレータ等、しかるべきオペレータターミナル２０に呼び出しを配信するようにする。スペイン語を話すオペレータがシステム２から離れたところに都合よく配置されていれば、そのオペレータにより対応されるべき呼出しは、図１から３を参照して上述したように、コールセンター１６を経由して、遠隔コールセンター１６’に配信される。

上記の信号方式手法の例は、コールルーティングおよびリクエスタ４の識別についての例示のみを意図しており、本発明の範囲を限定することは意図していない。ＭＳＣ８とスイッチ１２の間で呼出しを送信することが可能なこのような信号方式手法のプロトコルは、本発明の考察の範囲内である。

ステップ１０４において、スイッチ１２は、主コールセンター１６に対して呼出しを配信する。この作業を実行するためにスイッチ１２は、図２に示すように、上記により詳細を述べた関連する情報とともに着信情報レコード１５を生成し、コールセンター１６への直通回線を選択する。スイッチ１２と主コールセンター１６の間で呼出しを運ぶために使用される構成は、好ましくは、上記に詳細を述べたようなリリースリンク回線の構成がよい。ここでは議論されないが、回線（trunking）およびまたは信号方式の構成はいかなるものでも、スイッチ１２からコールセンター１６へ呼出しを配信するために使用可能であると考察される。また、スイッチ１２が、公衆交換電話網（ＰＳＴＮ）１０（すなわち、８００番号またはダイレクトダイヤル番号）を介して、この呼出しをコールセンター１６に接続させてもよいことも、本発明により考察される。

次に、ステップ１０６において、リクエスタ４から呼出しを受信すると、主コールセンター１６は、しかるべきスキルを伴う利用可能なオペレータターミナル２０に対して、必要であれば、インバウンドリクエストが到着している旨を通知し、そこにその呼出しを配信する。リクエスタ４とオペレータターミナル２０との間にリンクを確立すると、主コールセンター１６は、発信者からカスタマーサービス担当者への音声通信リンクを確立する。双方向音声通信は、リクエスタ４から主コールセンター１６を経由して、付加電話通信手段を有するオペレータターミナル２０に配信される。着信情報レコード１５に含まれるいかなる情報（すなわち、リクエスタ４によりダイヤルされた番号（ＤＩＤ）、優先言語コード、リクエスタの発信側電話番号、リクエスタサービスプロバイダフィールド）をも含むデータ通信は、主コールセンター１６からオペレータターミナル２０へ、コンピュータ・テレフォニ・インターフェース（ＣＴＩ）２９を経由して送信される。ＣＴＩ２９は、主コールセンター１６とオペレータターミナル２０との間で展開され、呼出しに対処し完了させるために、カスタマーサービス担当者とエージェントアプリケーション１９のソフトウェアに必要な情報を伝えるために使用される。

このリンクを用いることにより、エージェントは、リクエスタ４が要求しているサービスに関する情報をリクエスタ４に求める。リクエスタ４は必要な情報を提供する。この情報の例としては、ディレクトリ・リスト名、定義された地域名、電子メールアドレス、氏名、ワイヤライン番号、ライセンスプレート等を含んでもよいが、これに限定されない。また、従来の番号案内および機能強化された番号案内もまた、本システムによって提供できることが本発明により考察される。

次に、ステップ１０６Ａにおいて、着信情報レコード１５の発信側電話番号からの情報を使用して、オペレータターミナル２０とエージェントアプリケーション１９は、過去リクエスト・リスティングテーブル９２の発信者番号フィールドを検索し、このリクエスタ４からの電話が過去にあったどうかを判断する。そのリクエスタ４からは電話がなかった場合は、オペレータターミナル２０は、ステップ１０８に進み、そのリクエスタのために、新規の過去リクエスト・リスティングテーブル９２のエントリの生成を開始する。

リクエスタ４が過去に発信したことがある場合、ステップ１０６Ｂにおいて、エージェントアプリケーション１９とオペレータターミナル２０は、過去リクエスト・リスティングテーブル９２とトップランク・リスティング・サブテーブル９４からの情報を、上記の定義済み標準に基づいたなんらかの編成形式で、オペレータに対して表示する。

次に、ステップ１０６Ｃにおいて、オペレータは、新しく要求されたリストが、過去リクエスト・リスティングテーブル９２またはトップランク・リスティングテーブル９４により提供される表示情報上にあるかどうかを判断する。新しく要求されたリストがない場合、オペレータはステップ１０８に進む。そのリストがある場合、オペレータは検索ステップ（１０８）をバイパスして、リクエスタ４を所望のリストに直接リンクさせ、その後、システムはステップ１０９に進む。この構成により、オペレータターミナル２０のサービス担当者はかなりの検索時間を節約できるので、より良好なレスポンスタイムが実現する。

上述したように、リクエスタ４が初めての発信者である場合、または要求されたリストが過去リクエスト・リスティングテーブル９２にない場合、ステップ１０８において、オペレータターミナル２０においてエージェントがデータベース１８の検索を開始する。もちろん、主コールセンター１６が使用中または利用可能なオペレータターミナル２０がない場合、リクエスタ４’の呼出しは、コールセンター１６’に転送され、ここで上記のステップ１０６で説明したものと同じ方式で、リクエスタの問い合わせを受け入れることができる。リクエストされたリストが利用できない場合、エージェントは、リクエスタ４からのさらなる指示を待つ。

ステップ１０９において、情報が過去リクエスト・リスティングテーブル９２から取り出されたものかどうか、またはそのリストが検索によりオペレータが取り出したものかどうか、システム２は、過去リクエスト・リスティングテーブル９２とトップランク・リスティングテーブル９４を、システム２の更新スケジュールに従って更新する。初めての発信者の場合、過去リクエスト・リスティングテーブル９２が作成される。

過去リクエスト・リスティングテーブル９２およびトップランク・リスティングテーブル９４が、リクエスタ４のワイヤレス装置上に直接転送されるために、サービスプロバイダ２６用のサーバ上に格納されている場合、このサーバの更新処理は、一日に一度、一時間に一度、またはリアルタイムというような同様のタイムフレームで行われ、リクエスタ４のワイヤレス装置に現れるリストは、既に説明したように、スケジュールされた間隔、またはリクエスタ４の無線デバイスの電源が入れられサービスプロバイダ２６に再接続されたときに更新されてもよいことに留意する。サービスプロバイダ２６は、テーブル９２の対応コピーを、このスケジュールされた間隔でリクエスタ４によって割り当てられたワイヤレス装置へ送信し、このワイヤレス装置が最新の過去リクエスト・リストを維持できるようにする。更新されたリストはまた、インターネット接続を経由するなど、システム２への直接的な定期スケジュールメンテナンス接続に従ってワイヤレス装置に送信され得る。

次に、ステップ１１０において、リクエストされた番号がリストされていない場合、または、リクエスタ４が実際の番号を受け取れないようにマスキングされている場合、加入者６に対するリストの見直しが行われる。リスティングテーブルにリストされているデータベース１８や１８’のデバイス６に関連するレコードは、接続フィールドを備えており、これは、カスタマーサービス担当者のこの呼出しへの接続が許可されているかどうかをオペレータターミナル２０に示すサブテーブル７０を有する。もし許可されていれば、その番号がリクエスタ４に開示される。これによって、リストされていない番号はアクセスできない状態のままであり、デバイス６の番号は、対応する加入者がそう望むのならば、秘密状態が保たれる。

動作中に、エージェントアプリケーション１９ソフトウェアは、その番号がリストされていないかをチェックするためにサブテーブル７０を調べる。もしリストされていなければ、カスタマーサービス担当者は、リクエスタ４にその旨を知らせ、さらなる指示を待つ。もしその番号がリストされている場合、エージェントアプリケーション１９は、番号がマスクされているかどうかを調べる。これは、加入者６についてのリクエストが「オン」か「オフ」になるという機能である。しかし好ましくは、デフォルトはマスク状態で設定される。もし番号がマスクされている場合、リクエスタ４はその番号を見たり聞いたりすることなく、呼出しが接続される。番号がマスクされていない場合、リクエスタ４はその番号を受信し、自動ダイヤルまたは他の同様なサービスが提供される。もちろん、上記の動作および方法は、このソフトウェア構成または当業者に周知の他のいかなるソフトウェア構成においても、容易に実施されると理解される。また、侵入、ハッキング、または他の無許可アクセス形式または使用からデータベース１８を保護するために、暗号化されたフォーマットでデータベース１８を格納してもよいことも本発明により考察される。

あるいは、デバイス６のためのより安全なリスティングのために、デバイス６と関連する電話番号は、オペレータターミナル２０におけるカスタマーサービス担当者に対して表示されない。システム２がその情報を有していても、それはカスタマーサービス担当者に対して表示されない。この場合、オペレータターミナル２０およびスイッチ１２は、呼出し完了データパケット５０と広域ネットワーク（ＷＡＮ）２５を介して通信し、全体として電話番号の秘密性を維持しながら呼出しを完了する。

次にステップ１１２において、クロージングプロンプト・モジュール２７は、上記の基準に基づいて適切なクロージングプロンプトを決定する。このクロージングプロンプトは、リスティングテーブル５２Ａの、特別通知または一般通知フィールドのいずれかから読み込まれ、オーバーライドモジュール６６により選択されるかまたは修正され、または、呼出し完了データテーブル６８に見られる加入者６とリクエスタ４の情報に基づいて、クロージングプロンプト処理モジュール６４に含まれるロジックにより選択される。

過去リクエスト・リスティングテーブル９２上に格納される加入者６リストは、接続フィールド内の、リスティングテーブルにセーブされているマスキング機能基準に従ってリストされることに留意すべきである。従って、接続フィールドによるとリストがマスキングされていることを示している加入者６リストを、リクエスト４が要求する場合、そのリクエストはマスキング指示とともに接続されるだけでなく、リストが、そのリクエスタの過去リクエスト・リスティングテーブル９２に格納されている場合には、そのリストはマスキングされたフォーマットで現れる。

新規なリクエスタ４の場合、ステップ１０６Ａにおいて見出されるように、クロージングプロンプト・モジュール２７はシステム２にコンタクトするようリクエスタ４に促すプロンプトを選択し、その情報をリスティングテーブル５２Ａにエンターしてもよい。

このプロンプト用のコードまたは複数のコードは、呼出し完了データパケット５０のクロージングプロンプトコード・フィールド５８に読み込むためにクロージングプロンプト・モジュール２７により使用され、記録されたクロージングプロンプトのうちのいずれを再生するかを決定する。

次にステップ１１４において、オペレータターミナル２０上のエージェントアプリケーション１９ソフトウェアが呼出し完了データパケット５０を構築する。呼出し完了データパケット５０は、着信情報レコード１５からの情報、リスティングテーブル５２Ａ、データベース１８、クロージングプロンプト・モジュール２７、エージェントアプリケーション１９およびリクエスタ４からの言語情報を用いて用意される。

呼出し完了データパケット５０が完成すると、オペレータターミナル２０は、広域エリアネットワーク２５を介して、スイッチ１２へ呼出し完了データパケット５０を送信する。ＷＡＮ２５は、システム２内のすべてのスイッチ１２とすべてのオペレータターミナルに接続され、万一オペレータターミナル２０がコールルーティングの結果スイッチ１２から離れたところに配置されている場合、オペレータターミナル２０は、その遠隔地にあるスイッチ１２に対しても、ＷＡＮ２５を介して呼出し完了データパケット５０を送信することが可能である。しかるべきスイッチ１２が、リクエスタ４の呼出しがシステム２にエンターされた発信側スイッチを識別するＤＩＤを用いて、エージェントアプリケーション１９により識別される。

次に、ステップ１１６において、スイッチ１２はリクエスタ４と加入者６の間の呼出しを開始する。スイッチ１２は、その後、呼出し詳細情報と、呼出し完了行程のための他の機能についてトラッキングを始める。スイッチ１２は、それから呼出し完了データパケット５０の情報を用いて、クロージングプロンプトストレージモジュール１３からしかるべきクロージングプロンプトを選択し、呼出し完了テーブル１７から適切なアウトバウンドトランクグループを選択する。

本発明の他の実施例を、図８に示す。図８は、あるデータプロトコルを介してリスティング・データベース１８にアクセスを提供するために用いられる構成要素の例を示す図である。このデータプロトコルは、過去リクエスト・リスティングテーブル９２をリクエスタ４’のリモートワイヤレス装置と同期させるための、ＷＡＰ（ワイヤレスアプリケーションプロトコル）、ＳＭＳ、ｉＭＯＤＥインターフェースが含まれるが、これらに限られない。本発明のこの実施例において、リクエスタ４は、デバイス６を介して問合せを実行する。ＭＳＣ８において、リクエストがＷＳＣＰ（ワイヤレスサービスコントロールポイント）４７により処理され、ＩＳＰ４２を介してキャリアのファイアウォール４５を通ってインターネットに対しインターフェースをとる。リクエストは、次に、システム２のファイアウォール４５を通って処理され、ウェブサーバ４４に渡される。ウェブサーバ４４で、プロセシングアプリケーション４９がその送られた情報を取り込み、リスティング・データベース１８に対して行われる問い合わせを構築する。リスティング・データベース１８は、そのリクエストと整合している、過去リクエスト・リスティングテーブル９２またはトップランク・リスティングテーブル９４に含まれる情報を戻す。この情報は、ファイアウォール４５を介して、デバイス６へ返信される。この返信された情報は、その後、デバイス上のデータベースを更新するために用いられる。

本発明がその特定の実施例に関して記載されてきたが、他の多くの変形、変更および他の用途が、当業者にとって明白である。したがって、本発明は、本願明細書における特定の開示によっては限定されず、添付の請求の範囲のみで限定されることが好ましい。

本発明を説明するために、図面においては、目下のところ好ましいと思われるいくつかの形状で示されているが、本発明は、その図示された構成と手段そのものに限定されるものではないと理解される。
本発明の一実施例による本発明の通信補助システムを図示したものである。 本発明の一実施例による着信情報レコードの構造を説明するためのフィールド図である。 本発明の一実施例によるデータベース１８におけるリスティングテーブルの、コネクトフィールドについてのフィールド図である。 本発明の一実施例によるクロージングプロンプト・モジュールの図である。 本発明の一実施例による呼出し完了データパケットのフィールド図である。 本発明の一実施例による過去リクエスト・リスティングテーブルを示す。 本発明の一実施例によるトップランク・リスティングテーブルを示す。 本発明の一実施例によるシステムの動作を示すフローチャートである。 発信者データベース３１と同期させる目的で、ＷＡＰ（ワイヤレス・アプリケーション・プロトコル）ポータルまたは他のデータ接続を介して、リスティング・データベース１８とのアクセスを提供するために使用される構成要素の例を示す図である。

符号の説明

２・・・通信補助システム
４・・・リクエスタ
６・・・デバイス
８・・・ＭＳＣ
１０・・・ＰＳＴＮ
１２・・・ＶＲＵ
１３・・・クロージングプロンプト・ストレージモジュール１３
１４・・・課金データベース
１６・・・主コールセンター
１７・・・呼出し完了テーブル１７
１８・・・リスティング・データベース
１９・・・エージェントアップリケーション
２０・・・オペレータターミナル
２１・・・高度サービスモジュール
２５・・・ＷＡＮ
２６・・・サービスプロバイダ
２７・・・クロージングプロンプト・モジュール
２９・・・ＣＴＩ
３１・・・発信者データベース

Claims (5)

1. 通信補助システムであって、
   内部に複数のリストを有し、前記リストの各々は少なくとも一つの連絡先名および対応する連絡先番号を有する第一のデータベースと、
   前記システムへユーザの電話装置を連結する電話技術ハードウェアと、
   前記システムの前記ユーザの少なくとも一人に対する過去リクエスト・リスティングテーブルであって、前記ユーザによるリクエストに応じて前記データベースから取得した過去リクエスト・リストを格納するよう構成される過去リクエスト・リスティングテーブルと
   を備え、
   前記ユーザが前記電話装置を用いて前記システムとコンタクトをとる際、前記システムは前記ユーザを認識し、前記過去リクエスト・リスティングテーブルを前記システムのオペレータターミナルへ転送することを特徴とする通信補助システム。
2. 請求項１に記載の通信補助システムであって、
   前記電話装置は携帯電話であることを特徴とする通信補助システム。
3. 請求項１に記載の通信補助システムであって、
   前記過去リクエスト・リスティングテーブル内の前記リストは、カテゴリ・フィールドを保持することを特徴とする通信補助システム。
4. 請求項３に記載の通信補助システムであって、
   前記カテゴリ・フィールドは、レストラン、１−８００番号、個人連絡先、航空会社、ホテル、映画、および娯楽のリストのいずれか一つに対する指定を含むことを特徴とする通信補助システム。
5. 請求項４に記載の通信補助システムであって、
   前記カテゴリ・フィールドに含まれる指定に基づいて、前記過去リクエスト・リスティングテーブルに見られる最もリクエストの多いリストを格納および編成するよう構成されるトップリクエスト・リスティングサブテーブルをさらに備えることを特徴とする通信補助システム。

Images