(57)【要約】 【課題】回線交換装置に負荷が集中することを回避できるリクエスト集約装置、電話システムおよびリクエスト集約方法を提供する。【解決手段】リクエスト集約装置は電話網から着信した呼を内線電話機に振り分け、通話終了後、前記呼を切断する回線交換装置にネットワークを介して接続されたリクエスト集約装置において、記憶部と制御部とを備える。記憶部はネットワークに接続されたコンピュータから内線電話機への要求の発生状況を管理するためのものである。制御部は内線電話機に対するコンピュータからの要求が発生および解除する毎に、記憶部に要求毎に設定されている要求個数を増減し、記憶部の要求個数の増減が０→１および１→０かそれ以外かを判定し、それ以外の場合はコンピュータからの同じ要求を回線交換装置に送信しない。【選択図】図１
2017073667.tif 000002
【特許請求の範囲】
【請求項１】
電話網から着信した呼を内線電話機に振り分け、通話終了後、前記呼を切断する回線交換装置にネットワークを介して接続されたリクエスト集約装置において、
前記ネットワークに接続されたコンピュータから前記内線電話機への要求の発生状況を管理するための記憶部と、
前記内線電話機に対する前記コンピュータからの要求が発生および解除する毎に、前記記憶部に要求毎に設定されている要求個数を増減し、前記テーブルの前記要求個数の増減が０→１および１→０かそれ以外かを判定し、判定の結果、それ以外の場合は前記コンピュータからの同じ要求を前記回線交換装置に送信しない制御部と
を備えるリクエスト集約装置。
【請求項２】
前記制御部は、
前記記憶部の個数増減を行った結果、当該内線電話機に対する要求が１つ目であった場合、前記内線電話機に対する要求のメッセージを前記回線交換装置に送信する請求項１記載のリクエスト集約装置。
【請求項３】
前記制御部は、
前記記憶部の個数増減を行った結果、当該内線電話機に対する要求個数が０になった場合、前記内線電話機に対して行った要求の解除のメッセージを前記回線交換装置に送信する請求項１記載のリクエスト集約装置。
【請求項４】
前記制御部は、
前記記憶部の個数増減を行った結果、当該内線電話機から受信されたイベント通信について前記記憶部に登録されているすべてのコンピュータに対してイベント通知を行う請求項１記載のリクエスト集約装置。
【請求項５】
前記制御部は、
前記記憶部の個数増減を行った結果、当該内線電話機から受信されたイベント通信について前記記憶部に登録されていないコンピュータにはイベント通知を行わない請求項１記載のリクエスト集約装置。
【請求項６】
電話網から着信した呼を内線電話機に振り分け、通話終了後、前記呼を切断する回線交換装置と、
前記回線交換装置にネットワークを介して接続され、前記内線電話機に対する要求を前記回線交換装置に送るコンピュータと、
前記回線交換装置と前記コンピュータとの間に介在して設けられたリクエスト集約装置とを備え、
前記リクエスト集約装置は、
前記内線電話機に対する前記コンピュータからの要求の発生状況を管理するための記憶部と、
前記内線電話機に対する前記コンピュータからの要求が発生および解除する毎に、前記記憶部に要求毎に設定されている要求個数を増減し、前記テーブルの前記要求個数の増減が０→１および１→０かそれ以外かを判定し、判定の結果、それ以外の場合は前記コンピュータからの同じ要求を前記回線交換装置に送信しない制御部と
を備える電話システム。
【請求項７】
前記内線電話機に対する前記コンピュータからの要求の発生状況を記憶部で管理し、
前記内線電話機に対する前記コンピュータからの要求が発生および解除する毎に、前記記憶部に要求毎に設定される要求個数を増減し、
この増減の結果、前記記憶部の前記要求個数の増減が０→１および１→０かそれ以外かを判定し、判定の結果、それ以外の場合は前記コンピュータからの同じ要求を前記回線交換装置に送信しないリクエスト集約方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、リクエスト集約装置、電話システムおよびリクエスト集約方法に関する。
【背景技術】
【０００２】
昨今、製造業、販売業、金融業など、さまざまな事業形態があるが、これらの事業を行う上で、顧客サービスの一環として、顧客からの問い合わせ対応窓口（部署）として、コールセンターなどを設置するケースが多い。
【０００３】
コールセンターには、電話機とコンピュータとを回線交換装置に接続し、これら電話機およびコンピュータを連動させて顧客にオペレータが電話応対を行うためのＣＩＴシステムが導入されている。
【０００４】
ところで、コールセンターの規模が大きくなると、以下のような問題が生じる。  
すなわち、回線交換装置が電話回線からの着信を内線電話機に振り分けたり、コンピュータからのリクエストを基に内線電話機を制御（ＣＴＩ制御）する際に、回線交換装置に負荷が集中し、呼の振り分けやＣＴＩ制御に遅延を起こす可能性がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−３２４５２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、コールセンターの規模が拡大すると、回線交換装置に負荷が集中し、遅延など、電話応対業務に支障を来たす可能性があるという問題があった。
【０００７】
本発明が解決しようとする課題は、回線交換装置に負荷が集中することを回避することができるリクエスト集約装置、電話システムおよびリクエスト集約方法を提供することにある。
【課題を解決するための手段】
【０００８】
実施形態のリクエスト集約装置は、電話網から着信した呼を内線電話機に振り分け、通話終了後、前記呼を切断する回線交換装置にネットワークを介して接続されたリクエスト集約装置において、記憶部と制御部とを備える。記憶部はネットワークに接続されたコンピュータから内線電話機への要求の発生状況を管理するためのものである。制御部は内線電話機に対するコンピュータからの要求が発生および解除する毎に、記憶部に要求毎に設定されている要求個数を増減し、記憶部の要求個数の増減が０→１および１→０かそれ以外かを判定し、それ以外の場合はコンピュータからの同じ要求を回線交換装置に送信しない。
【図面の簡単な説明】
【０００９】
【図１】第１実施形態のリクエスト集約システムの概要構成を示す図である。
【図２】コールセンター側の装置構成を示すブロック図である。
【図３】リクエスト集約システムの動作を示すフローチャートである。
【図４】モニタ要求が最初に発生したときのシーケンスチャートである。
【図５】２つ目のモニタ要求が発生したときのシーケンスチャートである。
【図６】内線電話機に対するイベントを通知するシーケンスチャートである。
【図７】モニタ実施中に最後から２番目のモニタ解除要求が発生したときのシーケンスチャートである。
【図８】モニタ実施中に最後のモニタ解除要求が発生したときのシーケンスチャートである。
【発明を実施するための形態】
【００１０】
以下、図面を参照して実施形態を詳細に説明する。
（第１実施形態）  
図１は電話システムの一つの実施の形態であるリクエスト集約システムの構成を示す図である。  
図１および図２に示すように、第１実施形態のリクエスト集約システムは、ユーザの電話機１、公衆交換電話網２：Public Switched Telephone Networks２（以下「ＰＳＴＮ２」、ＰＢＸ３などの回線交換装置、オペレータ用の電話機４（以下「内線電話機４」と称す）およびオペレータ用の操作端末としてのコンピュータ５（以下「オペレータ用ＰＣ５」と称す）、集約サーバ６、管理用のコンピュータ７（以下「管理用ＰＣ７」と称す）、ローカルエリアネットワーク（ＬＡＮ）などのネットワークを介して接続された通話録音装置９、音声認識装置１０を備える。
【００１１】
すなわちこのリクエスト集約システムは、電話回線に接続されるＰＢＸ３にセンター内のＬＡＮを介して接続された音声認識装置１０と、ユーザとオペレータの通話内容を録音する通話録音装置９と、オペレータ用ＰＣ５からＰＢＸ３へのリクエストを仲介する集約サーバ６とを有する。
【００１２】
ＰＢＸ３は回線交換部３１とComputer Telephony Integrationゲートウェイ部３２（以下「ＣＴＩゲートウェイ部３２」と称す）とを有する。
【００１３】
回線交換部３１はコールセンターなどの電話問い合わせ応対窓口（部署）において、ＰＳＴＮ２からの呼の発着信制御および振り分け制御を行う。具体的には、回線交換部３１はＰＳＴＮ２から着信した呼を内線電話機４に振り分け、通話終了後、呼を切断する。
【００１４】
ＣＴＩゲートウェイ部３２は集約サーバ６との間でＣＴＩに関する通信（各種要求およびイベント通信のメッセージの送受信など）を行う。
【００１５】
内線電話機４はＰＢＸ３により振り分けられた顧客（お客様またはユーザなどともいう）からの電話をオペレータが受けて電話対応業務を行うための電話機である。
【００１６】
オペレータ用ＰＣ５は集約サーバ６を介してＰＢＸ３とのセッションが確立された後、集約サーバ６からのユーザの情報やオペレータがキーボードから入力した情報を画面に表示して、オペレータが電話対応業務を行うための情報端末である。
【００１７】
オペレータ用ＰＣ５には電話応対業務に関する複数のアプリケーションプログラムがインストールされており、それぞれアプリケーションＩＤ（以下「アプリＩＤ」と称す）を持っている。
【００１８】
管理用ＰＣ７はオペレータ用ＰＣ５と同様の機能を備えており、管理者が操作するコンピュータであり、管理者権限により各オペレータ用ＰＣ５および内線電話機４を監視（通信のモニタ、傍受など）することができる。
【００１９】
具体的に、オペレータ用ＰＣ５および管理用ＰＣ７には、ＣＩＴ制御用のソフトウェアがインストールされており、内線電話機４の動作状態（呼び出し、通話中、待機中、切断など）などを画面に表示する。アプリケーションプログラムは業務処理を実行するときに、ＰＢＸ３に対してモニタ要求、イベント通信、モニタ解除要求などを発行する。イベント通信には、例えば呼び出し、着信、切断などのイベントがある。
【００２０】
集約サーバ６はComputer Telephony Integrationゲートウェイ部６１（以下「ＣＴＩゲートウェイ部６１」と称す）、記憶部としての管理テーブル６２、制御部６３を備える。
【００２１】
ＣＴＩゲートウェイ部６１はＰＢＸ３のＣＴＩゲートウェイ部３２との間で情報（リクエスト）のやりとりを行う。
【００２２】
ＣＴＩゲートウェイ部６１はオペレータがオペレータ用ＰＣ５を操作して発行されたリクエスト情報（モニタ要求、イベント通信発生、モニタ解除要求など）を受け取り制御部６３に渡す。
【００２３】
図２に示すように、管理テーブル６２には、内線電話番号毎に、モニタ要求、イベント通信、モニタ解除要求などの要求項目毎にリクエスト情報の個数が管理されている。
【００２４】
この管理テーブル６２の例の場合、例えば内線電話番号＃１について、アプリＩＤ＝１からのモニタ要求があり、モニタ要求の個数は全部で１個、つまり内線電話番号＃１に対するモニタ要求はアプリＩＤ＝１からしかないことを示している。
【００２５】
また内線電話番号＃２については、複数のアプリ（アプリＩＤ＝２、アプリＩＤ＝３）からのモニタ要求があり、モニタ要求の個数は全部で２個であることを示している。
【００２６】
この管理テーブル６２はＬＡＮに接続されたオペレータ用ＰＣ５および管理用ＰＣ７から内線電話機４への各種要求またはイベントの発生状況を管理するためのテーブルである。
【００２７】
制御部６３は内線電話機４に対するオペレータ用ＰＣ５および管理用ＰＣ７からのモニタ要求またはイベント通信およびモニタ解除要求が受信される毎に、各要求項目に設定されている個数（要求個数またはイベント個数）を増減し、増減した後、これらの個数を確認し、要求個数またはイベント個数に応じて以下のような処理を行う。
【００２８】
制御部６３が個数を確認した結果、管理テーブル６２の要求個数の増減が０→１および１→０かそれ以外かを判定し、判定の結果、それ以外の場合はオペレータ用ＰＣ５および管理用ＰＣ７からの同じ要求のメッセージをＰＢＸ３に送信しない。
【００２９】
また制御部６３は管理テーブル６２の個数の増減を行った結果、当該内線電話機４に対するモニタ要求個数の増減が０→１、つまりモニタ要求個数が１つ目であった場合、内線電話機４に対するモニタ要求のメッセージをＰＢＸ３に送信する。
【００３０】
制御部６３は管理テーブル６２の個数の増減を行った結果、当該内線電話機４に対するモニタ解除要求によりモニタ要求個数の増減が１→０、つまりモニタ要求個数が０になった場合、内線電話機４に対して行ったモニタ要求の解除のメッセージをＰＢＸ３に送信する。
【００３１】
制御部６３は管理テーブル６２の個数の増減を行った結果、当該内線電話機４からのイベント通信に対してモニタ実施中のすべてのアプリケーションプログラム（オペレータ用ＰＣ５および管理用ＰＣ７）に対してイベント発生のメッセージ（イベント通知）を送信する。
【００３２】
制御部６３は管理テーブル６２の個数の増減を行った結果、当該内線電話機４からのイベント通信に対して管理テーブル６２に登録されていない（モニタ実施中でない）アプリケーションプログラム（オペレータ用ＰＣ５および管理用ＰＣ７）にはイベント通知を行わない。
【００３３】
制御部６３はＰＢＸ３から受け取った情報から呼情報（オペレータＩＤと業務ＩＤとの対）を生成しオペレータ用ＰＣ５に送る。
【００３４】
また制御部６３は、通話録音装置９、音声認識装置１０などを制御し、各装置の動作を制御する。
【００３５】
この他、集約サーバ６の制御部６３はユーザの電話に対する自動応答機能を備えており、ユーザの電話操作を促し、電話操作に応じて問い合わせ先（業務）を特定してＰＢＸ３に通知し、業務の内線電話機４にユーザの電話を接続させる。
【００３６】
自動応答機能は予め設定された応答メッセージとこの応答メッセージに紐付けられた電話機のボタンの番号（トーン）に応じた業務種別の識別情報（業務ＩＤ）と、この業務ＩＤの業務に電話対応するオペレータの識別情報（オペレータＩＤ）および電話機の識別情報などが設定されており、ユーザが行った電話機のボタン操作（トーン発信操作）で業務ＩＤを特定する。
【００３７】
通話録音装置９はユーザとオペレータとの会話（通話内容）をそれぞれ別の音声ファイルとして着呼ＩＤ（図示せず）などで紐付けて（対応付けて）録音（記憶）する。すなわち通話録音装置９は、ユーザに電話対応したオペレータの音声およびユーザの音声を録音する。
【００３８】
音声認識装置１０は予め設定されている音声認識用の辞書を参照して音声認識対象の音声の音声認識処理を行う。具体的には、通話録音装置９に録音された音声の音声ファイルを読み出し、音声ファイルをテキストデータ（文字列）に変換する。
【００３９】
以下、図３のフローチャートを参照してこの実施形態のリクエスト集約システムの動作を説明する。図３はリクエスト集約システムの動作を示すフローチャートである。
【００４０】
このリクエスト集約システムでは、ユーザからコールセンターの電話対応窓口の代表番号への発信があると、ＰＳＴＮ２を通じてＰＢＸ３に着呼し、着呼の情報（ユーザの電話番号）が集約サーバ６に送られる。
【００４１】
集約サーバ６では、制御部６３が、自動応答機能により、既に登録済みのユーザであるか、どういった問い合わせであるかの応答メッセージを流し、ユーザに対して、センター側の問い合わせ先（業務）を、電話機１のテンキー操作にて選択させる。
【００４２】
ユーザの選択操作により、ユーザが登録ユーザであり、かつ問い合わせ先の業務ＩＤが特定されると、集約サーバ６は、ＰＢＸ３に対して該当する業務のオペレータの電話機４にユーザからの電話（着呼）を接続するよう指示する。
【００４３】
ＰＢＸ３は、集約サーバ６から指示された内線電話機４にユーザからの電話（着呼）を接続する。
【００４４】
集約サーバ６の制御部６３は、オペレータが電話機４で応答した時点から、通話録音装置９に通話録音を指示し、これにより、通話録音装置９は、通話録音を開始し、通話の内容を着呼ＩＤに紐付く音声ファイルを生成し、内部のハードディスクなどに記憶する。
【００４５】
また集約サーバ６では、ＣＴＩゲートウェイ部６１が、オペレータとユーザとの通話開始の情報（着呼ＩＤ、オペレータＩＤ、業務ＩＤ、ユーザの電話番号（顧客ＩＤ）など）を基に呼情報（着呼ＩＤに紐付けられたオペレータＩＤと業務ＩＤの対）を生成し当該オペレータ用ＰＣ５へ送る。これによりオペレータ用ＰＣ５ではアプリケーションプログラムが応対画面を表示し、ユーザに関する業務処理をオペレータが行えるようになる。
【００４６】
これに先立ち、オペレータ用ＰＣ５より、ＰＢＸ３への要求またはイベントが集約サーバ６のＣＴＩゲートウェイ部６１に受信されると（図３のステップＳ３１のＹｅｓ）、ＣＴＩゲートウェイ部６１はその要求またはイベントの情報を制御部６３に通知する。
【００４７】
制御部６３は、受け取った要求またはイベントの情報を基に管理テーブル６２を検索し、要求に応じて該当項目の個数を増減する（ステップＳ３２）。
【００４８】
例えば新たなモニタ要求であれば個数の値を＋１、つまりインクリメントし、既にあるモニタ実施中のオペレータ用ＰＣ５のモニタの解除要求であれば、その個数の値を−１、つまりディクリメントする。
【００４９】
図２の管理テーブル６２を例にすると、要求が例えば内線電話番号＃１に対するモニタ要求であれば、該当する内線電話番号＃１のレコードの該当要求項目の欄に、アプリＩＤ（例えばＩＤ＝１）を設定すると共に、要求の個数を“０”から“１”へ個数を一つインクリメントする。つまり、この内線電話番号＃１に対するモニタ要求が初めての場合は“１”となる。
【００５０】
管理テーブル６２の個数を増減した後、制御部６３は、管理テーブル６２の該当項目の個数の増減をチェックし、チェックした結果、個数の増減に応じた処理を行う（ステップＳ３３）。
【００５１】
具体的には、チェックの結果、個数が“０”から“１”に増加した場合（０→１）、その要求のメッセージをＰＢＸ３へ送信し（ステップＳ３４）、個数が“１”から“０”に減少した場合（１→０）、その要求の解除のメッセージをＰＢＸ３へ送信する（ステップＳ３５）。個数の増減がそれ以外の場合（“２”以上や個数に変化がない場合）、次の要求またはイベントの受信を待機する状態になり、ＰＢＸ３へは要求のメッセージを送信しない。
【００５２】
ここで、図４〜図８のシーケンスチャートを参照して各要求毎の動作を説明する。  
図４はモニタ要求が最初に発生したときのシーケンスチャート、図５は２つ目のモニタ要求が発生したときのシーケンスチャート、図６は内線電話機４（＃２）に対するイベント（着信など）を通知するシーケンスチャート、図７はモニタ実施中に最後から２番目のモニタ解除要求が発生したときのシーケンスチャート、図８はモニタ実施中に最後のモニタ解除要求が発生したときのシーケンスチャートである。
【００５３】
まず、図４を参照してある内線電話機４（内線電話番号＃２）に対するモニタ要求が最初に発生したときの動作を説明する。
【００５４】
この場合、図４に示すように、内線電話機４（内線電話番号＃２）に対応するオペレータ用ＰＣ５のアプリケーションプログラム（ＩＤ＝２）より、内線電話機４（内線電話番号＃２）に対するモニタ要求が最初に発行される（図４のステップＳ１０１）。
【００５５】
このモニタ要求を集約サーバ６が受信すると、制御部６３は管理テーブル６２の該当要求欄の個数を“０”から“１”へインクリメントし、個数の増減が“０”から“１”なので、ＰＢＸ３へモニタ要求のメッセージを送信する（ステップＳ１０２）。
【００５６】
これにより、ＰＢＸ３は通話中の内線電話機４（内線電話番号＃２）の内線のイベントモニタを実施する（ステップＳ１０３）。
【００５７】
続いて、図５を参照して内線のイベントモニタ実施中の内線電話機４（内線電話番号＃２）に対して管理用ＰＣ７のアプリケーションプログラム（ＩＤ＝３）から２つ目のモニタ要求が発生したときの動作を説明する。
【００５８】
この場合、図５に示すように、内線電話機（内線電話番号＃２）に対して管理用ＰＣ７のアプリケーションプログラム（ＩＤ＝３）から２つ目のモニタ要求が発行され（図５のステップＳ２０１）、このモニタ要求を集約サーバ６が受信すると、制御部６３は管理テーブル６２の該当要求欄の個数を“１”から“２”へインクリメントする。
【００５９】
そして、制御部６３が該当要求欄の個数をチェックした結果、同じ内線電話機４（内線電話番号＃２）に対するモニタ要求の個数の増減が“１”から“２”なので、制御部６３は、ＰＢＸ３へモニタ要求のメッセージを送信しない（ステップＳ２０２）。これにより、ＰＢＸ３は２つ目以降に発生する要求メッセージの処理をしなくて済む。
【００６０】
次に、図６を参照して内線のイベントモニタ実施中の内線電話機４（内線電話番号＃２）に対するイベント（着信など）を通知する動作を説明する。
【００６１】
この場合、図６に示すように、内線のイベントモニタ実施中の内線電話機４（内線電話番号＃２）に対して、例えばＰＳＴＮ２からの着信などのイベントが発生した場合（図６のステップＳ３０１）、ＰＢＸ３は着信した呼を内線電話機４（内線電話番号＃２）に振り分けると共に（ステップＳ３０２）、集約サーバ６に対してイベント通信を行う（ステップＳ３０３）。つまりＰＢＸ３は着信を示すメッセージを集約サーバ６に送信する。
【００６２】
集約サーバ６では、制御部６３が、ＰＢＸ３からの着信を示すメッセージを受けると、管理テーブル６２を参照してモニタ実施中のアプリケーションプログラム、例えばアプリケーションプログラムＩＤ＝２とアプリケーションプログラムＩＤ＝３に対して内線のイベント通知を行う（ステップＳ３０４）。
【００６３】
次に、図７を参照して既に２つのアプリケーションプログラム（ＩＤ＝２、ＩＤ＝３）から内線のイベントモニタ実施中に、オペレータ用ＰＣ５のアプリケーションプログラム（ＩＤ＝２）から内線電話機４（内線電話番号＃２）に対して内線のモニタ解除の要求があった場合の動作を説明する。
【００６４】
図７に示すように、既に２つのアプリケーションプログラム（ＩＤ＝２、ＩＤ＝３）から内線のイベントモニタ実施中の内線電話機４（内線電話番号＃２）に対してオペレータ用ＰＣ５のアプリケーションプログラム（ＩＤ＝２）から内線のモニタ解除の要求が集約サーバ６に発行された場合（図７のステップＳ４０１）、このモニタ解除の要求を集約サーバ６が受信すると、制御部６３は管理テーブル６２の該当要求欄の個数を“２”から“１”へディクリメントする。
【００６５】
そして、制御部６３が該当要求欄の個数をチェックした結果、同じ内線電話機４（内線電話番号＃２）に対するモニタ解除の要求の個数が“２”から“１”へ減数されただけなので、制御部６３は、ＰＢＸ３へモニタ解除の要求のメッセージを送信しない（ステップＳ４０２）。これにより、ＰＢＸ３は最後のモニタ解除の要求が発生するまでモニタ解除の処理をしなくて済む。
【００６６】
次に、図８を参照して図７の動作でアプリケーションプログラムが一つ減って残り１つのアプリケーションプログラム（ＩＤ＝３）が内線電話機４（内線電話番号＃２）の内線のイベントモニタ実施中に、アプリケーションプログラム（ＩＤ＝３）が内線電話機４（内線電話番号＃２）に対して内線のモニタ解除の要求を発行した場合の動作を説明する。
【００６７】
図８に示すように、残り１つのアプリケーションプログラム（ＩＤ＝３）から内線のイベントモニタ実施中の内線電話機４（内線電話番号＃２）に対して内線のモニタ解除の要求が集約サーバ６に発行された場合（図８のステップＳ５０１）、このモニタ解除の要求を集約サーバ６が受信すると、制御部６３は管理テーブル６２の該当要求欄の個数を“１”から“０”へディクリメントする。
【００６８】
そして、制御部６３が該当要求欄の個数をチェックした結果、同じ内線電話機４（内線電話番号＃２）に対するモニタ解除の要求の個数が“１”から“０”へ減数されたため、制御部６３は、ＰＢＸ３へモニタ解除の要求のメッセージを送信する（ステップＳ５０２）。これにより、ＰＢＸ３は内線電話機４（内線電話番号＃２）の内線のイベントモニタ動作を終了する（ステップＳ５０３）。
【００６９】
このようにこの第１実施形態によれば、内線電話機４とＣＴＩ制御により連動するオペレータ用ＰＣ５および管理用ＰＣ７などのコンピュータとＰＢＸ３との間に介在させた集約サーバ６が、コンピュータからＰＢＸ３への要求を一度受信して、不要な要求を排除した上で必要な要求をＰＢＸ３へ送信するので、ＰＢＸ３の負荷を軽減することができる。この結果、ＰＢＸ３に負荷が集中することを回避できる。
【００７０】
本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【００７１】
上記実施形態に示した集約サーバ６やＰＢＸ３の各構成要素を、コンピュータのハードディスク装置などのストレージにインストールしたプログラムで実現してもよく、また上記プログラムを、コンピュータ読取可能な電子媒体：electronic mediaに記憶しておき、プログラムを電子媒体からコンピュータに読み取らせることで本発明の機能をコンピュータが実現するようにしてもよい。電子媒体としては、例えばＣＤ−ＲＯＭ等の記録媒体やフラッシュメモリ、リムーバブルメディア：Removable media等が含まれる。さらに、ネットワークを介して接続した異なるコンピュータに構成要素を分散して記憶し、各構成要素を機能させたコンピュータ間で通信することで実現してもよい。
【符号の説明】
【００７２】
１…電話機、２…公衆交換電話網（ＰＳＴＮ）、３…回線交換装置（ＰＢＸ）、４…オペレータ用電話機、５…コンピュータ（オペレータ用ＰＣ）、６…集約サーバ、７…監視用ＰＣ、９…通話録音装置、１０…音声認識装置、３１，６１…ＣＴＩゲートウェイ部、６２…管理テーブル、６３…制御部。
【図１】
2017073667.tif 000003
【図２】
2017073667.tif 000004
【図３】
2017073667.tif 000005
【図４】
2017073667.tif 000006
【図５】
2017073667.tif 000007
【図６】
2017073667.tif 000008
【図７】
2017073667.tif 000009
【図８】
2017073667.tif 000010