JP2010200265A - 呼分散装置及び呼分散方法 - Google Patents

Abstract

【課題】複数の呼グループに応対可能なオペレータに所定の呼グループの呼を優先的に処理させることのできる呼分散技術を提供する。
【解決手段】呼分散装置が、オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループをそのオペレータが受付可能である状態を示す状態通知を上記オペレータ端末から受信する受信手段と、保持部で保持される各呼グループに関する各オペレータの状態を上記状態通知が示す状態で更新する更新手段と、呼が着信された場合に、上記保持部を参照することにより着信呼が属する呼グループを受付可能なオペレータを特定し、この特定されたオペレータが利用するオペレータ端末に当該着信呼を分配する呼分配手段と、を備える。
【選択図】図１

Description

本発明は、呼分散技術に関する。

コールセンタシステムやコンタクトセンタシステムのような複数の着信呼に応対するシステムは、着信された呼を特定の端末に集中させることなく自動的に分配するＡＣＤ（Automatic Call Distribution）機能を有する。各端末にそれぞれ分配された各呼は、その
端末に配置されたオペレータにより応対される。

このＡＣＤ機能には、着信先電話番号や問い合わせ内容等のような呼の内容により着信呼をグループ分けし、各グループ内で着信呼の分配を行う機能がある。以降、このようにグループ分けされた各グループをＡＣＤグループと表記する。このようなＡＣＤグループを利用するシステムでは、オペレータは、割り当てられた端末を用いてシステムにログインすると所定のＡＣＤグループ内で分配される呼に対して応対する。これに対し、マルチログイン機能は、１人のオペレータが複数のＡＣＤグループの着信呼に応対できるようにする。

更に、各オペレータにそれぞれスキルレベルを設定し、高いスキルレベルが設定されたオペレータから優先的に着信呼を割り当てる機能がある。以降、この機能をスキルレベル機能と表記する。マルチログイン機能及びスキルレベル機能を持つシステムでは、各オペレータのマルチログイン可能な各ＡＣＤグループについてそれぞれ異なるスキルレベルを設定することができる。このようなシステムは、全ての着信呼のうち待ち時間の長い呼から順に処理対象とし、その処理対象呼の属するＡＣＤグループにログインしているオペレータのうち高いスキルレベルを有し待機時間の長いオペレータを選択し、その選択されたオペレータに当該処理対象呼を処理させる。

図１８は、従来のマルチログイン機能及びスキルレベル機能を有するシステムの処理例を示す概念図である。図１８に示すように、例えば、システムで呼１、２、３及び４がその番号順に受信されたものとする。更に、このとき、呼１及び３はＡＣＤグループ１００に属し、呼２及び４はＡＣＤグループ２００に属し、受付可能なオペレータが存在しないものとする。この場合、呼１、２、３及び４は、所属する各ＡＣＤグループの待ち行列にそれぞれ入れられる。

その後、オペレータＯＰ１が受付可能状態となり、その直後に、オペレータＯＰ２が受付可能状態となったと仮定する。なお、システムにおいてオペレータＯＰ１は、ＡＣＤグループ１００及び２００にマルチログイン可能に登録されており、そのスキルレベルがＡＣＤグループ１００よりもＡＣＤグループ２００のほうが高く設定されている。オペレータＯＰ２は、ＡＣＤグループ１００にのみログイン可能に登録されており、そのスキルレベルがオペレータＯＰ１のそれと同等に設定されている。

このような場合、システムは、最も待ち時間の長い呼１を処理対象に選択し、この呼１の属するＡＣＤグループ１００にログインしているオペレータのうち待機時間の長いオペレータＯＰ１を選択する。受付可能なオペレータＯＰ１及びＯＰ２のスキルレベルは、ＡＣＤグループ１００においてはそれぞれ同一に設定されているため、スキルレベルはその判断に影響を与えない。システムは、選択されたオペレータＯＰ１の端末に呼１を分配し、この呼１をオペレータＯＰ１に処理させる。これにより、オペレータＯＰ１は通話中状態となるため、受付可能状態のオペレータとしてオペレータＯＰ２が残ることになる。

特開２００４−２４１９６３号公報 特開２００６−３４５１２５号公報

しかしながら、上述のような従来技術では、マルチログイン機能が利用されている状況下において特定のＡＣＤグループの着信呼が増加すると、その混雑している特定ＡＣＤグループが偏って処理され、混雑していないＡＣＤグループの呼を処理するオペレータが不足する。これにより、従来技術では、特定のＡＣＤグループが混雑すると混雑していないＡＣＤグループも実質的に混雑している状況に陥ってしまう現象が生じる場合がある。

問い合わせの多い窓口、即ち着信呼が多く忙しいＡＣＤグループでは、受付可能なオペレータが不足状態となり易く、着信呼の待ち行列が発生している場合が多い。この状況で、この忙しいＡＣＤグループと他のＡＣＤグループとにマルチログイン可能なオペレータが受付可能となった場合には、そのオペレータは、例え上記他のＡＣＤグループのほうに高いスキルレベルを有していたとしても、忙しいＡＣＤグループの着信呼を処理させられる。これは、着信呼の待ち時間に応じて処理対象の呼が決定され、このように決定された呼に応じてオペレータが選択されるためである。

当該スキルレベルは、一般的には、オペレータにとって高いスキルレベルを有するＡＣＤグループの呼を優先的に処理するために利用される。しかしながら、上述のような理由により、混雑している２つのＡＣＤグループにマルチログイン可能なオペレータがスキルレベルの高いＡＣＤグループの呼を処理する確立は２分の１程度である。図ＡＡに示される例によれば、オペレータＯＰ１は、高いスキルレベルに設定されているＡＣＤグループ２００の呼ではなく、着信呼の待ち時間に応じてスキルレベルの低いほうのＡＣＤグループ１００の呼を先に処理する。これにより、呼２は、新たにＡＣＤグループ２００にログインしているオペレータで新たに受付可能な状態となるオペレータが現れるまで、処理されず待ち状態となる。従って、例えば、ＡＣＤグループ２００にＡＣＤグループ１００よりも重要度（緊急度）の高い呼が属するように決められている場合には、重要度の高い呼を長く待たせることになる。

つまり、従来のマルチログイン機能では、混雑しているＡＣＤグループを対象とした場合には、スキルレベル機能が有効活用されないという問題点があった。従って、緊急性の高い呼や重要顧客の呼等のような優先的に処理することが望ましい呼に対応するＡＣＤグループをマルチログインに含めることは困難であった。

このような問題点を解決するために、マルチログイン機能が利用されている状況において、受付可能なオペレータが各ＡＣＤグループについてそれぞれ一定人数存在するように分配する手法が考えられる。しかしながら、この手法によれば、受付可能なオペレータを確保したＡＣＤグループの呼が着信されない場合には、逆に、オペレータの稼働率が低下するという問題点が生じる。

本開示の課題は、上述のような問題点に鑑み、複数の呼グループに応対可能なオペレータに所定の呼グループの呼を優先的に処理させることのできる呼分散技術を提供することにある。

本開示の各態様は、上述した課題を解決するために、それぞれ以下の構成を採用する。

第１の態様では、呼分散装置が、オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループをそのオペレータが受付可能である状態を示す状態通知を上記オペレータ端末から受信する受信手段と、保持部で保持される各呼グループに関する各オペレータの状態を上記状態通知が示す状態で更新する更新手段と、呼が着信された場合に、上記保持部を参照することにより着信呼が属する呼グループを受付可能なオペレータを特定し、この特定されたオペレータが利用するオペレータ端末に当該着信呼を分配する呼分配手段と、を備える。

本開示の別態様としては、以上の何れかの処理を実行する呼分散方法であってもよいし、プログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記憶媒体であってもよい。

上記態様によれば、複数の呼グループに応対可能なオペレータに所定の呼グループの呼を優先的に処理させ得る呼分散技術を提供することができる。

図１は、実施例１におけるコンタクトセンタシステムのシステム構成の概略を示す図である。 図２は、実施例１におけるＧＷの構成を示す概念図である。 図３は、実施例１におけるＳＩＰ基本サーバの構成を示す概念図である。 図４は、実施例１におけるＳＩＰ拡張サーバの構成を示す概念図である。 図５は、実施例１におけるボタン構成情報テーブルの例を示す図である。 図６は、実施例１におけるＭＣＤサーバの構成を示す概念図である。 図７は、実施例１におけるオペレータ状態テーブルの例を示す図である。 図８は、実施例１におけるスキルレベル情報テーブルの例を示す図である。 図９は、実施例１におけるオペレータ端末の構成を示す概念図である。 図１０は、実施例１におけるオペレータ端末の概観を示す図である。 図１１は、オペレータ端末がログインする際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。 図１２は、オペレータ端末で特定受付可状態を示す機能ボタンが押下された際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。 図１３は、顧客端末からの呼を着信させる際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。 図１４は、実施例１のＭＣＤサーバ７におけるコールフロー制御を示すフローチャートである。 図１５は、実施例２におけるコンタクトセンタシステムのシステム構成の概略を示す図である。 図１６は、実施例２における状態変化許容テーブルの例を示す図である。 図１７は、オペレータ端末で特定受付可状態を示す機能ボタンが押下された際における実施例２のコンタクトセンタシステムの動作例を示すシーケンス図である。 図１８は、従来のマルチログイン機能及びスキルレベル機能を有するシステムの処理例を示す概念図である。

以下、実施形態としてのコンタクトセンタシステムについて具体例を挙げ説明する。実施形態としてのコンタクトセンタシステムは、例えばコンタクトセンタやコールセンタで
利用され、顧客からの電話対応業務のサポートを行う。なお、以下の各実施例では、顧客からの電話（呼）を扱う処理について主に説明するが、電話の呼に限らず、Ｅメール、ファクシミリ等の顧客からの要求全般を扱うようにしてもよい。以下に挙げた各実施例はそれぞれ例示であり、本実施形態は以下の各実施例の構成に限定されない。

以下、実施例１のコンタクトセンタシステムについて説明する。

［システム構成］
図１は、実施例１におけるコンタクトセンタシステムのシステム構成の概略を示す図である。実施例１におけるコンタクトセンタシステムは、ゲートウェイ（以降、ＧＷと表記する）２、ＳＩＰ（Session Initiation Protocol）基本サーバ５、ＳＩＰ拡張サーバ６
、ＭＣＤ（Multi-Channel Distribution）サーバ７、複数のオペレータ端末９等を備える。ＧＷ２、ＳＩＰ基本サーバ５、ＳＩＰ拡張サーバ６、ＭＣＤサーバ７はそれぞれＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワーク８により接続される。実施例１では、各ノード間の通信にＩＰ（Internet Protocol）が利用される例を示す。但し、本実施形態はこのような各ノード間の通信方式を限定するものではない。

ＧＷ２は、実施例１のコンタクトセンタシステムをＰＳＴＮ（Public Switched Telephone Networks）やインターネット等の公衆網１に接続させる。ＧＷ２は、公衆網１の呼制御プロトコルと実施例１のコンタクトセンタシステム内の呼制御プロトコルとを相互に変換して通信を可能とする。実施例１では、コンタクトセンタシステムで利用される呼制御プロトコルとしてＳＩＰが利用され、公衆網１としてＰＳＴＮが利用される場合を例に挙げる。

ＳＩＰ基本サーバ５は、実施例１のコンタクトセンタシステム内の呼制御、各オペレータ端末９とＭＣＤサーバ７との間の通信の中継などを行う。ＳＩＰ拡張サーバ６は、各オペレータ端末９の機能ボタンの制御などを行う。ＭＣＤサーバ７は、コンタクトセンタで応対する呼のフロー制御、オペレータの状態管理などを行う。実施例１では、ＭＣＤサーバ７は、各オペレータ端末９と直接通信せず、ＳＩＰ基本サーバ５を介して通信する。なお、各オペレータ端末９にＭＣＤサーバ７のアドレスを保持させ、ＭＣＤサーバ７と各オペレータ端末９との間を直接通信させるようにしてもよい。また、実施例１では、図１に示されるように、ＧＷ２、ＳＩＰ基本サーバ５、ＳＩＰ拡張サーバ６、ＭＣＤサーバ７がそれぞれ個別のノードとして実現される例を示すが、これらが１つのノードとして実現されるようにしてもよい。

ここで、ＭＣＤサーバ７で管理されるオペレータの作業状態（以降、ログイン状態と表記する）について説明する。ここで、オペレータのログインとは、オペレータがいずれかのＡＣＤグループに属する呼に応対可能状態であることを示す。マルチログインとは、オペレータが応対可能なＡＣＤグループが複数存在することを示す。

オペレータのログイン状態には、受付可、ワーク、離席、通話中、特定受付可の状態がある。受付可状態は、ログイン可能な全てのＡＣＤグループの呼を受信できる状態を意味する。ワーク状態は、業務中ではあるが呼を受信できない状態を意味する。離席状態は、休憩中等のような業務外であり呼を受信できない状態を意味する。通話中状態は、呼を着信し通話中である状態を意味する。特定受付可状態は、マルチログイン可能なオペレータにのみ生ずる状態であり、マルチログイン対象の複数のＡＣＤグループのうちのいずれか１つのＡＣＤグループに属する呼のみを受信できる状態を意味する。この特定受付可状態は、その受信可能なＡＣＤグループが受付可状態であり、それ以外のＡＣＤグループが他優先受付状態であることを示す。

このようなログイン状態は、オペレータによりログイン操作を行ったオペレータ端末９の機能ボタンが押下されることで、本コンタクトセンタシステムへ申告される。オペレータ端末９には、複数の機能ボタンが備えられており、各機能ボタンにはそのオペレータのログイン状態を示す情報がそれぞれ割り当てられている。よって、オペレータは、自身の作業状態に応じた機能ボタンを押下することで、作業状態を本コンタクトセンタシステムに申告することができる。ＳＩＰ拡張サーバ６は、このような各オペレータ端末９の機能ボタンの構成を制御する。

オペレータのログイン状態は、オペレータ端末９の機能ボタンが押下された場合のみでなく、オペレータのログイン操作時、呼接続時、呼切断時等に変更される。

各オペレータは、業務を開始する際には、本コンタクトセンタシステムにそれぞれログインするためのログイン操作を行う。具体的には、各オペレータは、自身が利用するオペレータ端末９を用いてオペレータＩＤを入力しログインボタンを押下することにより、本コンタクトセンタシステムに各オペレータが利用するオペレータ端末９を知らせる。本コンタクトセンタシステムにおいてこのオペレータのログイン処理が完了すると、このオペレータのログイン状態はワーク状態となる。その他、オペレータ端末９と顧客端末などの他の端末との間で呼接続が完了すると、そのオペレータのログイン状態は通話状態となり、当該呼接続が切断されると、そのオペレータのログイン状態はワーク状態に戻る。

［装置構成］
以下、実施例１のコンタクトセンタシステム内の各ノードについてそれぞれ詳細を説明する。

〔ＧＷ〕
図２は、実施例１におけるＧＷの構成を示す概念図である。ＧＷ２は、図２に示されるように、バス２０でそれぞれ接続される、制御部２１、記憶部２２、公衆網通信部２５、ＩＰ通信部２７等を備える。公衆網通信部２５及びＩＰ通信部２７は、例えば、ハードウェアの構成要素としてそれぞれ実現される（［その他］の項参照）。

公衆網通信部２５は、公衆網１からの回線を収容し、シグナリング信号及び音声信号の送受信を行う。更に、公衆網通信部２５は複数の公衆網回線を収容する。これにより、コンタクトセンタシステムは、一度に複数の顧客要求に応対することができる。ＩＰ通信部２７は、ＩＰネットワーク８に接続され、ＳＩＰパケット及び音声パケットの送受信を行う。記憶部２２は、例えばハードディスクであり、制御部２１で実行される処理で利用される各種情報を記憶する。制御部２１は、ＣＰＵ（Central Processing Unit）等の１又
は複数のプロセッサ、このプロセッサの処理に利用される周辺回路（ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、インタフェース回路等）を有する。

ＧＷ２は、更に、ゲートウェイ（ＧＷ）処理部２３を有する。ＧＷ処理部２３は、記憶部２２に格納されるプログラムが制御部２１により実行されることによりソフトウェア構成要素として実現されてもよいし、ハードウェア構成要素として実現されてもよい（［その他］の項参照）。

ＧＷ処理部２３は、公衆網通信部２５で接続される公衆網１のプロトコル終端機能、ＩＰ通信部２７で接続されるＩＰネットワーク８のプロトコル終端機能、公衆網１のプロトコルとＩＰネットワーク８のプロトコルとの間の相互変換機能等を有する。具体的には、ＧＷ処理部２３は、公衆網通信部２５を介して公衆網１からのシグナリング（呼）信号を受けると、ＩＰ通信部２７を介してこの呼信号に対応するＳＩＰパケットを送受すること
により、オペレータ端末９と当該呼の発信元の顧客端末とを呼接続させる。

ＧＷ処理部２３は、呼接続が確立すると当該オペレータ端末９と発信元の顧客端末との間で送受される音声データを中継する。この音声データの中継処理において、ＧＷ処理部２３は、公衆網１上を伝送される音声信号と音声ＩＰパケットとの間の変換処理を行う。この変換処理では所定のコーデック方式が利用され、音声信号から抽出される音声データに対し所定の方式によりデータ圧縮等を行い、当該音声データを音声パケット化する。音声パケットの転送には、例えばＲＴＰ（Real-time Transport Protocol）が利用される。

〔ＳＩＰ基本サーバ〕
図３は、実施例１におけるＳＩＰ基本サーバの構成を示す概念図である。

ＳＩＰ基本サーバ５は、図３に示されるように、バス５０でそれぞれ接続される、制御部５１、記憶部５２、通信部５９等を備える。通信部５９は、例えば、ハードウェアの構成要素として実現される（［その他］の項参照）。記憶部５２は、例えばハードディスクであり、制御部５１で実行される処理で利用される各種情報を記憶する。制御部５１は、ＣＰＵ等の１又は複数のプロセッサ、このプロセッサの処理に利用される周辺回路（ＲＯＭ、ＲＡＭ、インタフェース回路等）を有する。通信部５９は、ＩＰネットワーク８に接続され、ＳＩＰパケット等のＩＰパケットの送受信を行う。

ＳＩＰ基本サーバ５は、更に、端末管理部５６、呼制御部５７を有する。端末管理部５６及び呼制御部５７は、記憶部５２に格納されるプログラムが制御部５１により実行されることによりソフトウェア構成要素として実現されてもよいし、ハードウェア構成要素として実現されてもよい（［その他］の項参照）。

呼制御部５７は、通信部５９を介してＳＩＰパケットを送受信することにより、ＳＩＰ手続きを実行する。このＳＩＰ手続きにより、呼制御部５７は、コンタクトセンタシステム内のオペレータ端末９とＰＳＴＮ呼を終端するＧＷ２との間を呼接続する。このとき着信先となるオペレータ端末９は、ＭＣＤサーバ７から通知される情報に基づいて特定される。ＭＣＤサーバ７から通知される情報は、着信先として選択されたオペレータ端末９にログインするオペレータのオペレータＩＤである。呼制御部５７は、オペレータ端末９を特定するにあたり、記憶部５２に格納される端末情報ＤＢ５３を参照する。端末情報ＤＢ５３は、オペレータＩＤとそのオペレータがログインしているオペレータ端末９のＩＰ（Internet Protocol）アドレスとが関連付けられたテーブルを含む。

ところで、公衆網１からのシグナリング信号では着信番号（接続先電話番号）及び発信番号（発信元電話番号）が示されている。呼制御部５７は、ＧＷ２から当該シグナリング信号に対応する通話要求パケット（例えば、SIPのINVITEパケット）を受けると、そのＳ
ＩＰパケットに含まれる着信番号をＶＤＮ（Virtual Dial Number）に変換する。この変
換には、呼制御部５７は、記憶部５２に格納されるＶＤＮ変換ＤＢ５４を参照する。ＶＤＮ変換ＤＢ５４は、着信番号とＶＤＮとが関連付けられたテーブルを含む。呼制御部５７は、このＶＤＮに基づいてこの呼をコンタクトセンタで処理すると決定すると、このＶＤＮを含めた通話要求パケット（例えば、SIPのINVITEパケット）をＭＣＤサーバ７へ転送
する。

ＶＤＮ変換ＤＢ５４に格納される各ＶＤＮは、例えば、コンタクトセンタ宛ての顧客要求内容に応じて区別される番号となる。なお、ＶＤＮ変換ＤＢ５４において着信番号とＶＤＮとは１対１で関連付けられていてもよいし、着信番号に対して複数のＶＤＮが関連付けられていてもよい。また、当該着信番号がコンタクトセンタ宛ての場合には、まず顧客要求内容を問い合わせるための自動音声を流すことにより、顧客要求内容に対応する番号
を取得し、この番号によりＶＤＮが生成されるようにしてもよい。

端末管理部５６は、各オペレータ端末９を操作するオペレータのログイン処理、状態管理処理等を行う。

端末管理部５６は、通信部５９を介してログイン要求を受けると、ログイン処理を実行する。このログイン要求は、オペレータによりログイン操作が行われた際に、そのオペレータ端末９からＳＩＰ基本サーバ５へ送られる。当該ログイン処理では、まず、端末管理部５６は、当該ログイン要求をＳＩＰ拡張サーバ６及びＭＣＤサーバ７へ転送する。端末管理部５６は、ＳＩＰ拡張サーバ６及びＭＣＤサーバ７のアドレスを管理している。端末管理部５６は、ＳＩＰ拡張サーバ６及びＭＣＤサーバ７からそのログイン処理の完了を示す応答（例えば、ＡＣＫ）を受けると、当該ログイン要求に含まれていたオペレータＩＤ及びオペレータ端末のＩＰアドレスを端末情報ＤＢ５３に格納する。端末管理部５６は、当該ログイン要求を受けた際に、オペレータ認証を行うようにしてもよい。

端末管理部５６は、オペレータ端末９から状態変化通知を受けると、その通知をＭＣＤサーバ７へ転送する。この状態変化通知は、例えば、オペレータ端末９において機能ボタンが押下された場合に、その機能ボタンに割り当てられたログイン状態を示す情報を含んだ状態でオペレータ端末９からＳＩＰ基本サーバ５へ送られる。

ＭＣＤサーバ７では、各オペレータのログイン状態がそれぞれ管理される。ログイン状態が更新されると、ＭＣＤサーバ７からＳＩＰ基本サーバ５へ、その更新されたログイン状態を示すオペレータ状態通知が送られる。端末管理部５６は、ＭＣＤサーバ７からそのオペレータ状態通知を受けると、この通知をＳＩＰ拡張サーバ６に転送する。

更に、端末管理部５６は、いずれか１つのオペレータ端末９が顧客からの呼を着信した、すなわち、上記呼制御部５７の処理により呼接続が成功したことを検知すると、そのオペレータ端末９を操作するオペレータが通話中状態となったことを知らせるための状態変化通知をＭＣＤサーバ７へ送る。端末管理部５６は、この状態変化通知に、そのオペレータを示すオペレータＩＤと通話中状態を示すログイン状態とを含める。

〔ＳＩＰ拡張サーバ〕
図４は、実施例１におけるＳＩＰ拡張サーバの構成を示す概念図である。

ＳＩＰ拡張サーバ６は、図４に示されるように、バス６０でそれぞれ接続される、制御部６１、記憶部６２、通信部６９等を備える。記憶部６２は、例えばハードディスクであり、制御部６１で実行される処理で利用される各種情報を記憶する。制御部６１は、ＣＰＵ等の１又は複数のプロセッサ、このプロセッサの処理に利用される周辺回路（ＲＯＭ、ＲＡＭ、インタフェース回路等）を有する。通信部６９は、例えば、ハードウェアの構成要素として実現される（［その他］の項参照）。通信部６９は、ＩＰネットワーク８に接続され、ＳＩＰパケット等のＩＰパケットの送受信を行う。

ＳＩＰ拡張サーバ６は、更に、端末管理部６５を有する。端末管理部６５は、記憶部６２に格納されるプログラムが制御部６１により実行されることによりソフトウェア構成要素として実現されてもよいし、ハードウェア構成要素として実現されてもよい（［その他］の項参照）。

端末管理部６５は、各オペレータ端末９を操作するオペレータのログイン処理、各オペレータ端末９に対するボタン構成情報ダウンロード処理、ボタン点灯処理等を行う。

ログイン処理では、端末管理部６５は、オペレータ端末９から送信されＳＩＰ基本サーバ５で中継されたログイン要求を受けると、このログイン要求に含まれていたオペレータＩＤ及びオペレータ端末のＩＰアドレスを端末情報ＤＢ６７に格納する。端末管理部６５は、当該ログイン要求を受けた際に、オペレータ認証を行うようにしてもよい。端末管理部６５は、そのオペレータのログイン処理を完了すると、ＳＩＰ基本サーバ５へログイン処理の完了を示す応答（例えば、ＡＣＫ）を返信する。

端末管理部６５は、ＳＩＰ基本サーバ５からログイン状態がログイン完了後のワーク状態に設定されたオペレータ状態通知を受信すると、そのオペレータのためのボタン構成情報をそのオペレータ状態通知の対象のオペレータ端末９へダウンロードする。端末管理部６５は、記憶部６２に格納されるボタン構成情報ＤＢ６６からオペレータ状態通知に含まれるオペレータＩＤに対応するボタン構成情報を取得する。端末管理部６５は、このボタン構成情報をそのオペレータが利用するオペレータ端末９のＩＰアドレス宛てにダウンロードする。

図５は、実施例１におけるボタン構成情報テーブルの例を示す図である。ボタン構成情報ＤＢ６６は、図５に示されるようなボタン構成情報テーブルを含む。ボタン構成情報テーブルには、オペレータＩＤ毎に、オペレータ端末９の各機能ボタンに割り当てられるログイン状態を示す設定情報がそれぞれ格納される。図５の例では、オペレータＩＤが１００３であるオペレータがログイン操作を行ったオペレータ端末９のボタン構成情報には、機能ボタン１が受付可状態を示し、機能ボタン２がワーク状態を示し、機能ボタン３が離席状態を示し、機能ボタン４がＡＣＤグループＡの呼を受付可能な特定受付状態を示し、機能ボタン５がＡＣＤグループＣの呼を受付可能な特定受付状態を示し、機能ボタン６がＡＣＤグループＤの呼を受付可能な特定受付状態を示す設定情報が含まれる。図５には図示していないが、他の機能ボタンについては何ら機能が割り当てられていないことを示す情報が設定されていればよい。なお、ボタン構成情報に含まれるログイン状態を示す設定情報には、オペレータにとってマルチログイン可能な各ＡＣＤグループをそれぞれ指定する特定受付可状態が含まれるため、当該ログイン状態を示す設定情報とはオペレータにとってマルチログイン可能な複数のＡＣＤグループの各々を識別可能な情報が含まれることをも意味する。

端末管理部６５は、通信部６９を介してオペレータ状態通知を受けると、本コンタクトセンタシステムで認識されているログイン状態をオペレータ端末９へフィードバックする。オペレータ状態通知には、ＭＣＤサーバ７で管理されている該当オペレータのログイン状態を示す情報が含まれる。端末管理部６５は、上記オペレータ状態通知を受けると、その通知によって示されるオペレータのログイン状態に対応する機能ボタンの点灯指示をオペレータ端末９へ送信する。当該点灯指示の宛先となるオペレータ端末９は、端末情報ＤＢ６７から取得される、オペレータ状態通知に含まれるオペレータＩＤに対応するオペレータ端末９のＩＰアドレスが利用される。点灯指示の対象となる機能ボタンは、ボタン構成情報ＤＢ６６に基づいて、オペレータ状態通知に含まれるログイン状態に対応する機能ボタンに決定される。なお、言い換えれば、この点灯指示は、対応するログイン状態が特定受付可状態を示す場合にはオペレータにとってマルチログイン可能なＡＣＤグループのうち受付可状態にあるＡＣＤグループを示す情報を含むことになる。

〔ＭＣＤサーバ〕
図６は、実施例１におけるＭＣＤサーバの構成を示す概念図である。

ＭＣＤサーバ７は、図６に示されるように、バス７０でそれぞれ接続される、制御部７１、記憶部７２、通信部７９等を備える。記憶部７２は、例えばハードディスクであり、制御部７１で実行される処理で利用される各種情報を記憶する。制御部７１は、ＣＰＵ等
の１又は複数のプロセッサ、このプロセッサの処理に利用される周辺回路（ＲＯＭ、ＲＡＭ、インタフェース回路等）を有する。通信部７９は、例えば、ハードウェアの構成要素として実現される（［その他］の項参照）。通信部７９は、ＩＰネットワーク８に接続され、ＳＩＰパケット等のＩＰパケットの送受信を行う。

ＭＣＤサーバ７は、更に、オペレータ管理部７４、コールフロー制御部７５を有する。オペレータ管理部７４及びコールフロー制御部７５は、記憶部７２に格納されるプログラムが制御部７１により実行されることによりソフトウェア構成要素として実現されてもよいし、ハードウェア構成要素として実現されてもよい（［その他］の項参照）。

オペレータ管理部７４は、各オペレータ端末９を操作する各オペレータのログイン処理、ログイン状態管理処理等を行う。

ログイン処理では、オペレータ管理部７４は、オペレータ端末９から送信されＳＩＰ基本サーバ５から中継されたログイン要求を受けると、このログイン要求に含まれているオペレータＩＤを記憶部７２内のオペレータ状態ＤＢ７７に格納する。同時に、オペレータ管理部７４は、オペレータ状態ＤＢ７７におけるそのオペレータのログイン状態をワーク状態に設定する。なお、オペレータ管理部７４は、当該ログイン要求を受けた際に、オペレータ認証を行うようにしてもよい。オペレータ状態ＤＢ７７に、ログインを許可する全オペレータのＩＤが予め格納されるようにし、オペレータ管理部７４がこのオペレータ状態ＤＢ７７を参照することにより当該オペレータ認証を行うようにしてもよい。

オペレータ管理部７４は、そのオペレータのログイン処理を完了すると、ＳＩＰ基本サーバ５へログイン処理の完了を示す応答（例えば、ＡＣＫ）を返信する。続いて、オペレータ管理部７４は、そのオペレータのオペレータＩＤと現状のログイン状態とを含めたオペレータ状態通知をＳＩＰ基本サーバ５を送る。このときオペレータ状態通知に設定されるログイン状態は、ログイン完了後のワーク状態を示す。

図７は、実施例１におけるオペレータ状態テーブルの例を示す図である。オペレータ状態ＤＢ７７は、図７に示されるオペレータ状態テーブルを含む。オペレータ状態テーブルは、オペレータＩＤ毎にログイン状態が格納される。ログイン状態は、各ＡＣＤグループに関するオペレータの作業状態、すなわち、離席状態、受付可状態、ワーク状態、他優先受付状態、通話中状態がそれぞれ設定される。図７に示されるオペレータ状態テーブルの例では、オペレータＩＤが１００１のオペレータは、ＡＣＤグループＡ、Ｂ及びＣにマルチログイン可能であり、ログイン状態がワーク状態であることが示されている。オペレータＩＤが１００２のオペレータは、ＡＣＤグループＢ及びＣにマルチログイン可能であり、ログイン状態がＡＣＤグループＢ及びＣ共にワーク状態であることが示されている。オペレータＩＤが１００３のオペレータは、ＡＣＤグループＡ、Ｃ及びＤにマルチログイン可能であり、ログイン状態がＡＣＤグループＣのみが受付可状態であり他のＡＣＤグループが他優先受付状態、すなわちＡＣＤグループＣの特定受付状態であることが示されている。オペレータＩＤが１００４のオペレータは、ＡＣＤグループＡ及びＢにマルチログイン可能であり、ログイン状態が離席状態であることが示されている。

オペレータ管理部７４は、ログイン成功時と共に、ＳＩＰ基本サーバ５から送られる状態変化通知を受けた場合にも、その状態変化通知に含まれるオペレータＩＤ及びログイン状態で上記オペレータ状態ＤＢ７７を更新する。この状態変化通知は、上述したように、オペレータ端末９によりいずれかの機能ボタンが押下された場合、ＳＩＰ基本サーバ５により呼接続が完了された場合に受信される。前者の場合には、状態変化通知には、離席状態、受付可状態、ワーク状態、特定受付可状態のいずれかが含められ、後者の場合には、通話中状態又はワーク状態が含められる。オペレータ管理部７４は、オペレータ状態ＤＢ
７７を更新すると、新たなログイン状態を示す情報を含めたオペレータ状態通知をＳＩＰ基本サーバ５へ送信する。

オペレータ管理部７４は、更に、本コンタクトセンタシステムで利用される各ＡＣＤグループについてそれぞれ設けられる待機オペレータキューを制御する。オペレータ管理部７４は、オペレータのログイン状態が受付可状態となったことを検知すると、その受付可状態のＡＣＤグループの待機オペレータキューに、そのオペレータのオペレータＩＤを入れる。ここで、マルチログイン可能なオペレータのログイン状態には、マルチログイン可能な全てのＡＣＤグループが受付可状態の場合と、いずれか１つのＡＣＤグループが受付可状態でその他のＡＣＤグループが他優先受付状態の場合とが存在する。オペレータ管理部７４は、マルチログイン可能なオペレータであっても、受付可状態となっているＡＣＤグループの待機オペレータキューにのみそのオペレータのオペレータＩＤを入れ、他優先受付状態のＡＣＤグループの待機オペレータキューにはそのオペレータＩＤを入れない。これにより、マルチログイン可能なオペレータは、その受付可状態のＡＣＤグループに属する呼のみを応対することになる。

図８は、実施例１におけるスキルレベル情報テーブルの例を示す図である。スキルレベル情報ＤＢ７６は、図８に示されるようなスキルレベル情報テーブルを含む。スキルレベル情報テーブルには、オペレータＩＤ毎に、各ＡＣＤグループのスキルレベルがそれぞれ格納される。各オペレータにつきマルチログイン可能な各ＡＣＤグループにそれぞれスキルレベルが設定される。図８の例では、マルチログイン対象とならないＡＣＤグループには、スキルレベルが設定されていない。

オペレータ管理部７４は、上記スキルレベル情報ＤＢ７６に格納されるスキルレベルに応じて、各ＡＣＤグループの待機オペレータキュー内の情報をスキルレベルが高くかつ待機時間が長いオペレータほど早く取り出されるように並び替える。ここで、オペレータの待機時間は、そのＡＣＤグループが受付可状態となってから経過した時間を示す。この待機オペレータキューへのオペレータＩＤのキューイングは、例えば、上記オペレータ管理部７４によりオペレータ状態ＤＢ７７の更新タイミングで実行される。

コールフロー制御部７５は、ＳＩＰ基本サーバ５から送られる通話要求パケットに応じて、コールフロー制御を行う。コールフロー制御には、待ち呼制御、呼選択制御、オペレータ選択制御が含まれる。ＭＣＤサーバ７は、本コンタクトセンタシステムで利用される各ＡＣＤグループについてそれぞれ設けられる待ち呼キューを制御する。

コールフロー制御部７５は、ＳＩＰ基本サーバ５から送られる通話要求パケットを受けると、この通話要求パケットに対応する呼の情報をその呼の属するＡＣＤグループの待ち呼キューに入れる。待ち呼キューに入れられる呼情報としては、例えば通話要求パケットに含まれるＶＤＮが利用される。コールフロー制御部７５は、通話要求パケットに含まれるＶＤＮに基づいて、この通話要求パケットに対応する呼が属するＡＣＤグループを決定する。ＶＤＮとそれに対応するＡＣＤグループの種類とが対応付けられたテーブルが記憶部７２に予め格納されるようにしてもよい。待ち呼キューには着信された順に呼情報がプッシュされるため、待ち時間が長い順に呼情報が取り出される。

コールフロー制御部７５は、待ち呼制御と並行して、待ち呼が存在する場合には上記呼選択制御及び上記オペレータ選択制御を実行する。呼選択制御では、待ち呼キューに入れられている待ち呼のうち呼接続を行うべき呼が選択される。呼選択制御では、基本的には、全ＡＣＤグループの待ち呼キュー内の待ち呼のうち最も待ち時間が長い待ち呼が選択される。オペレータ選択制御では、呼選択制御により選択された呼に応対させるオペレータが選択される。具体的には、選択された呼の属するＡＣＤグループのログイン状態が受付可状態であるオペレータの中からスキルレベルの最も高いオペレータが選択される。コールフロー制御部７５は、待機オペレータキューを用いて上記オペレータ選択を行う。なお、呼選択制御及びオペレータ選択制御の詳細については動作例の項において説明する。

コールフロー制御部７５は、選択された呼を示すＶＤＮ及び選択されたオペレータを示すオペレータＩＤを含めた接続依頼をＳＩＰ基本サーバ５へ送信する。

〔オペレータ端末〕
図９は、実施例１におけるオペレータ端末の構成を示す概念図である。オペレータ端末９は、図９に示されるように、バス９０でそれぞれ接続される、制御部９１、記憶部９２、操作入力部９６、表示部９７、音声処理部９８、通信部９９等を備える。操作入力部９６、表示部９７、音声処理部９８及び通信部９９は、例えば、ハードウェアの構成要素としてそれぞれ実現される（［その他］の項参照）。

操作入力部９６は、機能ボタン、基本ボタン等の操作ボタンやフックスイッチ等を含み、オペレータの操作を検出してこの操作内容を制御部９１へ送る。表示部９７は、ＬＣＤ（Liquid Crystal Display）やＬＥＤ（Light Emitting Diode）等を含み、制御部９１からの指示に応じて各種情報や状態を表示する。音声処理部９８は、通信部９９を介して受信した音声パケットを音声信号に変換して受話器やスピーカから出力し、受話器等に設置されたマイクから入力された音声信号をデジタル音声データに変換して制御部９１へ送る。通信部９９は、ネットワーク８に接続され、ＧＷ２を介して顧客端末との間でＲＴＰ手続きにより音声パケットを送受信し、ＳＩＰ基本サーバ５及びＳＩＰ拡張サーバ６との間でＳＩＰパケットの送受信を行う。記憶部９２は、例えばハードディスクであり、制御部９１で実行される処理で利用される各種情報を記憶する。制御部９１は、ＣＰＵ（Central Processing Unit）等の１又は複数のプロセッサ、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、インタフェース回路等を含む。

図１０は、実施例１におけるオペレータ端末の概観を示す図である。オペレータ端末９は、ディスプレイ１０１、受話器１０２、基本ボタンエリア１０５、機能ボタンエリア１０４等を備える。基本ボタンエリア１０５には、保留ボタン、転送ボタン、数字ボタン等のような通話操作で主に利用される複数の基本ボタンが配置される。この基本ボタンエリア１０５には、ログインボタン１０７が含まれる。オペレータは、本コンタクトセンタシステムにログインする際に、基本ボタンエリア１０５内の数字ボタンでオペレータＩＤを入力した後、ログインボタン１０７を押下する。なお、本実施形態では、このようなログイン操作及び基本ボタンの配置を限定するものではない。

機能ボタンエリア１０４には、複数の機能ボタン１０９が配置される。各機能ボタン１０９にはそのオペレータのログイン状態を示す情報がそれぞれ割り当てられる。各機能ボタン１０９は、ログインしているオペレータに応じてその機能が変更される。例えば、オペレータＡがログインしている場合には、機能ボタン１０９Ａが受付可状態を通知する機能を持ち、機能ボタン１０９Ｂがワーク状態を通知する機能を持ち、機能ボタン１０９Ｃが離席状態を通知する機能を持ち、ボタン１０９ＤがＡＣＤグループＡの特定受付可状態を通知する機能を持ち、ボタン１０９ＥがＡＣＤグループＢの特定受付可状態を通知する機能を持つ。一方で、オペレータＢがログインしている場合には、機能ボタン１０９Ａ、Ｂ及びＣはオペレータＡの場合と同様であるが、ボタン１０９ＤがＡＣＤグループＢの特定受付可状態を通知する機能を持ち、ボタン１０９ＥがＡＣＤグループＣの特定受付可状態を通知する機能を持つように設定される。

各機能ボタン１０９はそれぞれＬＥＤ１０８を有する。上述のようにＭＣＤサーバ７で管理されているログイン状態に応じてそのログイン状態を示す機能ボタン１０９のＬＥＤ
１０８が点灯される。例えば、上述のオペレータＡがログインしている例において、そのオペレータＡのログイン状態がワーク状態である場合には、機能ボタン１０９ＢのＬＥＤが点灯される。

オペレータ端末９は、更に、ボタン制御部９３、呼制御部９４を有する。ボタン制御部９３及び呼制御部９４は、例えば、記憶部９２に格納されるプログラムが制御部９１により実行されることによりソフトウェア構成要素として実現されてもよいし、ハードウェア構成要素として実現されてもよい（［その他］の項参照）。

ボタン制御部９３は、上述した機能ボタン１０９の設定を行う。ボタン制御部９３は、ＳＩＰ拡張サーバ６からダウンロードされるボタン構成情報を通信部９９を介して受信すると、このボタン構成情報に応じて機能ボタンエリア１０４内の各機能ボタン１０９にそれぞれ設定情報を割り当てる。このボタン構成情報とは、図５に示されたボタン構成情報テーブルに格納される情報である。例えば、ボタン制御部９３は、図５の例における機能ボタン１、２、３及び４をそれぞれ機能ボタン１０９Ａ、Ｂ、Ｃ及びＤに割り当てる。

この割り当ては、例えば、各機能ボタン１０９を特定するための識別情報と各機能ボタン１０９に割り当てられたログイン状態を示す情報とがそれぞれ対応付けられたテーブルが更新されることで実現される。ボタン制御部９３は、機能ボタン１０９が押下されたことを検知すると、この押下された機能ボタン１０９の識別情報を取得し、上記テーブルからその識別情報と対応付けられたログイン状態を示す情報を取得する。

ボタン制御部９３は、機能ボタン１０９のいずれかが押下されると、上記のように取得されたログイン状態を示す情報を含めた状態変化通知をＳＩＰ基本サーバ５へ送る。例えば、ＡＣＤグループＢの特定受付可状態を示すように設定されたボタン１０９Ｅが押下された場合には、ログインしているオペレータのオペレータＩＤと共にＡＣＤグループＢの特定受付可状態を示す情報を含めた状態変化通知をＳＩＰ基本サーバ５へ送る。

ボタン制御部９３は、この状態変化通知に応じてＳＩＰ拡張サーバ６からボタン点灯指示を受信する。ボタン制御部９３は、このボタン点灯指示に含まれるボタン特定情報に応じて、そのボタン特定情報により特定される機能ボタン１０９のＬＥＤを点灯させる。

呼制御部９４は、通信部９９を介してＳＩＰ基本サーバ５との間でＳＩＰ手続きを行うことにより、顧客端末からのＰＳＴＮ呼を終端するＧＷ２との間で呼接続する。以降、呼制御部９４は、音声処理部９８から送られる音声データに基づいて音声データパケットを生成し、この音声データパケットをＲＴＰ等を用いて送受信する。

［動作例］
以下、実施例１におけるコンタクトセンタシステムの動作例を説明する。

図１１は、オペレータ端末がログインする際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。

オペレータは、業務を開始する際に、複数のオペレータ端末９のいずれか１台を用いてログイン操作を行う。このログイン操作では、例えば、オペレータ端末９の基本ボタンエリア１０５内の数字ボタンでそのオペレータを特定するためのオペレータＩＤが入力された後、ログインボタン１０７が押下される。オペレータ端末９は、ログインボタン１０７が押下されると、オペレータＩＤを含めたログイン要求をＳＩＰ基本サーバ５へ送信する（Ｓ１０１）。このログイン要求は、例えばＳＩＰパケットで送信され、本コンタクトセンタシステムにどのオペレータがどのオペレータ端末９を用いるかを申告するために送信
される。よって、このログイン要求には、オペレータＩＤとそのオペレータが利用するオペレータ端末９のＩＰアドレスとが含まれる。

ＳＩＰ基本サーバ５ではこのログイン要求が受信されると、端末管理部５６がそのログイン要求をＳＩＰ拡張サーバ６及びＭＣＤサーバ７へ転送する（Ｓ１０２、Ｓ１０３）。

ＳＩＰ拡張サーバ６ではこのログイン要求を受けると、端末管理部６５がそのログイン要求からオペレータＩＤ及びオペレータ端末のＩＰアドレスを取得する。端末管理部６５は、そのオペレータＩＤ及びオペレータ端末のＩＰアドレスを端末情報ＤＢ６７に格納する（Ｓ１０４）。このようなログイン処理が完了すると、端末管理部６５は、ＳＩＰ基本サーバ５へログイン処理の完了を示す応答（例えば、ＡＣＫ）を返信する（Ｓ１０６）。

ＭＣＤサーバ７ではこのログイン要求を受けると、オペレータ管理部７４がこのログイン要求に含まれているオペレータＩＤをオペレータ状態ＤＢ７７に格納する。更に、オペレータ管理部７４は、オペレータ状態ＤＢ７７におけるそのオペレータＩＤに対応するログイン状態をワーク状態に設定する（Ｓ１０５）。このようなログイン処理を完了させると、オペレータ管理部７４は、ＳＩＰ基本サーバ５へログイン処理の完了を示す応答（例えば、ＡＣＫ）を返信する（Ｓ１０７）。

ＳＩＰ基本サーバ５においてＳＩＰ拡張サーバ６及びＭＣＤサーバ７からログイン処理の完了を示す応答をそれぞれ受けると、端末管理部５６がログイン要求に含まれていたオペレータＩＤ及びオペレータ端末９のＩＰアドレスを端末情報ＤＢ５３に格納する（Ｓ１０８）。ＳＩＰ基本サーバ５は、ＭＣＤサーバ７及びＳＩＰ拡張サーバ６のログイン処理の完了を検知し、自身のログイン処理が完了すると、端末管理部５６はオペレータ端末９にログイン処理が完了したことを示す応答を送る（Ｓ１１０）。

ＭＣＤサーバ７で上述のようにログイン処理の完了を示す応答が行われた後、ＭＣＤサーバ７のオペレータ管理部７４がログイン処理対象のオペレータＩＤと現状のログイン状態とを含めたオペレータ状態通知をＳＩＰ基本サーバ５へ送る（Ｓ１１１）。ログイン完了後のオペレータのログイン状態はワーク状態となる。このオペレータ状態通知は例えばＳＩＰパケットで送信される。オペレータ状態通知は、最終的に、オペレータ端末９に現在のオペレータのログイン状態を表示させるために利用される。

ＳＩＰ基本サーバ５でこのオペレータ状態通知が受信されると、端末管理部５６がそのオペレータ状態通知をＳＩＰ拡張サーバ６へ転送する（Ｓ１１２）。ＳＩＰ基本サーバ５はオペレータ端末９のボタン構成情報を有していないため、当該オペレータ状態通知はオペレータ端末９の機能ボタンの制御を主に行うＳＩＰ拡張サーバ７へ転送される。

ＳＩＰ拡張サーバ７でこのオペレータ状態通知が受信されると、端末管理部６５は、そのオペレータ状態通知からログイン状態とオペレータＩＤとを取得する。端末管理部６５は、このログイン状態がログイン完了後のワーク状態を示すと判断すると、ボタン構成情報ＤＢ６６から上記取得されたオペレータＩＤに対応するボタン構成情報を取得する（Ｓ１１３）。端末管理部６５は、更に、その取得されたオペレータＩＤに対応するオペレータ端末９のＩＰアドレスを端末情報ＤＢ６７から取得する。端末管理部６５は、上記取得されたボタン構成情報を上記取得されたＩＰアドレス宛てに送信する（Ｓ１１４）。

オペレータ端末９でＳＩＰ拡張サーバ６からボタン構成情報が受信されると、ボタン制御部９３がこのボタン構成情報に応じて機能ボタンエリア１０４内の各機能ボタン１０９にそれぞれ設定情報を割り当てる（Ｓ１１５）。

ＳＩＰ拡張サーバ６ではボタン構成情報が送信された後、端末管理部６５が、オペレータのログイン状態に対応する機能ボタンの点灯指示をオペレータ端末９へ送信する（Ｓ１１６）。このときのオペレータのログイン状態はワーク状態である。端末管理部６５は、ボタン構成情報ＤＢ６６内の該当オペレータＩＤに対応するボタン構成情報を参照することにより、ワーク状態に対応付けられた機能ボタンを特定する。端末管理部６５は、この機能ボタンを特定するための情報をボタン点灯指示に含めて送信する。

オペレータ端末９ではこのボタン点灯指示が受信されると、ボタン制御部９３がその指示に含まれている機能ボタン特定情報に基づいて特定される機能ボタン１０９のＬＥＤ１０８を点灯させる。このとき、ワーク状態が割り当てられている機能ボタン１０９のＬＥＤ１０８が点灯される。これにより、そのオペレータ端末９を利用するオペレータは、ログインに成功しワーク状態となったことを認識することができる。

図１２は、オペレータ端末で特定受付可状態を示す機能ボタンが押下された際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。

オペレータは、上述のようにログインが完了すると、オペレータ端末９の機能ボタン１０９を押下することにより自身の作業状態をコンタクトセンタシステムへ申告することができる。例えば、オペレータは、ログイン完了後及び通話完了後のワーク状態において離席する場合には離席状態を示す機能ボタン１０９を押下する。同様に、オペレータは、ワーク状態においてマルチログイン可能な全てのＡＣＤグループの呼を受ける場合には受付可状態を示す機能ボタン１０９を押下する。

ここで、着信呼が頻発しているＡＣＤグループＢ及びＣと重要度の高い呼が属するＡＣＤグループＡとをマルチログイン対象としているオペレータが、ワーク状態でありＡＣＤグループＡに属する呼の着信を検知した場合を例に挙げる。この場合には、そのオペレータがそのＡＣＤグループＡに属する呼を受けたほうが、重要度の高い呼に即座に応対できるため、効果的である。このような場合、実施例１では、そのオペレータは、その重要度の高い呼が属するＡＣＤグループＡの特定受付可状態を示す機能ボタン１０９を押下する（Ｓ１２０）。これにより、そのオペレータは、着信呼が頻発しているＡＣＤグループの呼ではなく、重要度の高い呼に応対することができる。

オペレータ端末９において機能ボタン１０９が押下されると、ボタン制御部９３がその機能ボタン１０９に割り当てられたログイン状態を示す状態変化通知をＳＩＰ基本サーバ５へ送信する（Ｓ１２１）。このときの状態変化通知には、ＡＣＤグループＡの特定受付可状態を示す情報が設定される。

ＳＩＰ基本サーバ５はこの状態変化通知を受信すると、端末管理部５６がその状態変化通知をＭＣＤサーバ７へ転送する（Ｓ１２２）。

ＭＣＤサーバ７はこの転送された状態変化通知を受信すると、オペレータ管理部７４がその状態変化通知からオペレータＩＤ及びログイン状態を取得する。オペレータ管理部７４は、オペレータ状態ＤＢ７７におけるこの取得されたオペレータＩＤに該当するレコードのログイン状態をその取得されたログイン状態に更新する（Ｓ１２３）。ここでは、オペレータ状態テーブルにおいて、ＡＣＤグループＡが受付可状態に、ＡＣＤグループＢ及びＣが他優先受付状態にそれぞれ更新される。

オペレータ管理部７４は、オペレータ状態ＤＢ７７のオペレータ状態テーブルを更新すると、その新たなログイン状態を示す情報及びオペレータＩＤを含めたオペレータ状態通知をＳＩＰ基本サーバ５へ送信する（Ｓ１２４）。

ＳＩＰ基本サーバ５はこのオペレータ状態通知を受信すると、端末管理部５６がこのオペレータ状態通知をＳＩＰ拡張サーバ６へ転送する（Ｓ１２５）。

ＳＩＰ拡張サーバ６はこのオペレータ状態通知を受信すると、端末管理部６５がそのオペレータ状態通知からオペレータＩＤ及びログイン状態を取得する。端末管理部６５は、端末情報ＤＢ６７内のボタン構成情報テーブルを参照することにより、この取得されたログイン状態に割り当てられている機能ボタンを特定する（Ｓ１２６）。更に、端末管理部６５は、取得されたオペレータＩＤに対応するオペレータ端末９のＩＰアドレスを端末情報ＤＢ６７から抽出する。端末管理部６５は、特定された機能ボタンを示す情報を含めたボタン点灯指示をその取得されたＩＰアドレス宛てに送信する（Ｓ１２７）。

オペレータ端末９はこのボタン点灯指示を受信すると、ボタン制御部９３がそのボタン点灯指示に含まれるボタン特定情報に対応する機能ボタン１０９のＬＥＤ１０８を点灯させる（Ｓ１２８）。オペレータは、オペレータ端末９のＬＥＤ１０８が点灯することにより、自身の状態がコンタクトセンタシステムにおいてＡＣＤグループＡの特定受付可状態となっていることを確認することができる。

図１３は、顧客端末からの呼を着信させる際における実施例１のコンタクトセンタシステムの動作例を示すシーケンス図である。

顧客端末からの呼が公衆網１を介して本コンタクトセンタシステムに到達すると、ＧＷ２のＧＷ処理部２３が通話要求を示すシグナリング信号を公衆網通信部２５を介して受信する（Ｓ１３０）。ＧＷ処理部２３は、このシグナリング信号に対応したＳＩＰパケットを生成し、このＳＩＰパケットをＩＰ通信部２７を介してＳＩＰ基本サーバ５へ送信する（Ｓ１３１）。

ＳＩＰ基本サーバ５はこの通話要求パケットを受信すると、呼制御部５７が、ＶＤＮ変換ＤＢ５４を参照することにより、このＳＩＰパケットに含まれる着信番号をＶＤＮに変換する（Ｓ１３２）。呼制御部５７は、このＶＤＮに基づいてこの呼をコンタクトセンタで処理すると決定すると、着信番号をＶＤＮに変換した通話要求パケットをＭＣＤサーバ７へ転送する（Ｓ１３３）。

ＭＣＤサーバ７はこの通話要求パケットを受信すると、コールフロー制御部７５がこの通話要求パケットに対応する呼の待ち呼制御を行う（Ｓ１３４）。具体的には、コールフロー制御部７５は、通話要求パケットに含まれるＶＤＮを取得し、このＶＤＮに基づいてこの通話要求パケットに対応する呼が属するＡＣＤグループを決定する。コールフロー制御部７５は、この決定されたＡＣＤグループの待ち呼キューにこの通話要求パケットに対応する呼の情報を入れる。なお、ＳＩＰによれば、通話要求パケットにはＩＮＶＩＴＥパケットが利用され、その応答メッセージにはＴＲＹＩＮＧ（１００）メッセージが利用される（図１３で示す点線のメッセージ）。

コールフロー制御部７５は、逐次、待ち呼キューを監視する。コールフロー制御部７５は、待ち呼キューに待ち呼が存在する場合には、待ち呼の中から接続対象呼を選択し（Ｓ１３５）、この選択された呼を応対させるオペレータを選択する（Ｓ１３６）。コールフロー制御部７５は、選択された呼を示すＶＤＮ及び選択されたオペレータを示すオペレータＩＤを含めた接続依頼をＳＩＰ基本サーバ５へ送信する（Ｓ１３７）。

ＳＩＰ基本サーバ５はこの接続依頼を受信すると、呼制御部５７がその接続依頼からオペレータＩＤとＶＤＮとを取得する。呼制御部５７は、このオペレータＩＤに対応するオ
ペレータ端末９のＩＰアドレスを端末情報ＤＢ５３から取得する。呼制御部５７は、取得されたＶＤＮに基づいてＧＷ２からの通話要求パケットを特定し、この通話要求パケットを上記取得されたＩＰアドレスを該当のオペレータ端末９へ転送する（Ｓ１３８）。

オペレータ端末９はこの通話要求パケットを受信すると、呼制御部９４が呼出中通知をＳＩＰ基本サーバ５へ返信する（Ｓ１３９）。この呼出中通知は、ＳＩＰ基本サーバ５からＧＷ２へ転送され（Ｓ１４０）、通話要求元の顧客端末へ呼び出し中を示すシグナリング信号として転送される（Ｓ１４１）。なお、ＳＩＰによれば、この呼出中通知にはＲＩＮＧＩＮＧ（１８０）メッセージが利用される。

この状態においてオペレータ端末９によりオペレータが着信操作を行うと、呼制御部９４がＳＩＰ基本サーバ５へ着信許可を送る（Ｓ１４２）。この着信許可は、ＳＩＰ基本サーバ５からＧＷ２へ転送され（Ｓ１４３）、通話要求元の顧客端末へ着信許可を示すシグナリング信号として転送される（Ｓ１４４）。なお、ＳＩＰによれば、この着信許可にはＯＫ（２００）メッセージが利用される。

これにより、オペレータ端末９と顧客端末との間の呼接続が完了し、通話が開始される。

ＳＩＰ基本サーバ５はオペレータ端末９で着信されたことを検知すると、この着信したオペレータを示すオペレータＩＤ及び通話中状態を示す情報を含めた状態変化通知をＭＣＤサーバ７へ送る（Ｓ１４５）。

ＭＣＤサーバ７はこの状態変化通知を受信すると、オペレータ管理部７４がその状態変化通知からオペレータＩＤ及びログイン状態を取得する。オペレータ管理部７４は、オペレータ状態ＤＢ７７におけるこの取得されたオペレータＩＤに該当するレコードのログイン状態をその取得されたログイン状態に更新する（Ｓ１４６）。ここでは、オペレータ状態テーブルにおいて、マルチログイン可能な全ＡＣＤグループが通話中状態に設定される。

図１４は、実施例１のＭＣＤサーバ７におけるコールフロー制御を示すフローチャートである。具体的には、図１４には、コールフロー制御のうち、接続対象呼選択処理及びオペレータ選択処理が示される。

ＭＣＤサーバ７のコールフロー制御部７５は、逐次、待ち呼キュー及び待機オペレータキューを監視する。この監視において、コールフロー制御部７５は、待ち呼キュー及び待機オペレータキューにそれぞれデータが存在するか否かを判定する（Ｓ１５０）。待ち呼キュー及び待機オペレータキューの少なくとも一方にデータが存在しない場合には（Ｓ１５０；ＮＯ）、コールフロー制御部７５は処理を終了させる。

コールフロー制御部７５は、待ち呼キュー及び待機オペレータキューにそれぞれデータが存在する場合には（Ｓ１５０；ＹＥＳ）、全ＡＣＤグループの待ち呼キューの情報を参照することにより待ち時間が最も長い呼が属するＡＣＤグループを選択する（Ｓ１５１）。

次に、コールフロー制御部７５は、選択されたＡＣＤグループの待ち呼キューから呼情報（ＶＤＮ）を取得する（Ｓ１５２）。この取得された呼は、このＡＣＤグループに属する待ち呼のうち最も待ち時間が長い呼となる。ここで取得された情報により示される呼が接続対象呼となる。

次に、コールフロー制御部７５は、上記選択されたＡＣＤグループに関し、受付可状態のオペレータが存在するか否かを判定する（Ｓ１５３）。具体的には、コールフロー制御部７５は、上記選択されたＡＣＤグループの待機オペレータキューにオペレータＩＤが存在しているか否かを判定する。コールフロー制御部７５は、受付可状態のオペレータが存在する、すなわちオペレータＩＤが存在すると判断すると（Ｓ１５３；ＹＥＳ）、その待機オペレータキューからオペレータＩＤを取得する（Ｓ１５５）。ここで取得されるオペレータＩＤは、選択されたＡＣＤグループをログイン対象としているオペレータのうちスキルレベルが最も高く待機時間が最も長いオペレータを示している。

コールフロー制御部７５は、上述のように決定された接続対象呼を示すＶＤＮ及び上述のように取得されたオペレータＩＤを含む接続依頼をＳＩＰ基本サーバ５へ送信する（Ｓ１５６）。コールフロー制御部７５は、このときの接続対象呼及びオペレータを示す各情報を待ち呼キュー及び待機オペレータキューからそれぞれ削除して（Ｓ１５７）、（Ｓ１５０）の判定に戻る。

一方で、コールフロー制御部７５は、選択されたＡＣＤグループの待機オペレータキューにオペレータＩＤが存在しないと判断すると（Ｓ１５３；ＮＯ）、他のＡＣＤグループの待ち呼キューにデータが存在するか否かを判定する（Ｓ１５８）。コールフロー制御部７５は、他のＡＣＤグループの待ち呼キューにデータが存在しないと判定すると（Ｓ１５８；ＮＯ）、処理を終了する。

コールフロー制御部７５は、他のＡＣＤグループの待ち呼キューにデータが存在すると判定すると（Ｓ１５８；ＹＥＳ）、他のＡＣＤグループの中から待ち時間が最も長い呼が属するＡＣＤグループを選択する（Ｓ１５９）。以降、（Ｓ１５２）の処理に戻って、上述と同様の処理が実行される。

〔実施例１の作用及び効果〕
上述のように実施例１におけるコンタクトセンタシステムでは、オペレータがログイン操作を行うと、ＳＩＰ拡張サーバ６からそのオペレータが操作するオペレータ端末９へ機能ボタンの構成情報がダウンロードされる。オペレータ端末９では、そのダウンロードされた構成情報に基づいて各機能ボタン１０９の機能がそれぞれ再構成される。

これにより、各オペレータはどのオペレータ端末９を用いても、各自のマルチログイン可能なＡＣＤグループに応じた機能ボタンを利用することができる。つまり、実施例１におけるコンタクトセンタシステムによれば、オペレータが利用するオペレータ端末９を固定しないですむため、効率的な運用を行うことができる。

実施例１では、オペレータ端末９の各機能ボタン１０９には各ログイン状態を示す情報がそれぞれ割り当てられる。そして、マルチログイン可能なオペレータのログイン状態のうち着信可能な状態として、受付可状態と特定受付可状態とが設けられる。すなわち、マルチログイン可能なＡＣＤグループのうちどのＡＣＤグループの呼でも受付できる状態と、オペレータにより選択されたいずれか１つのＡＣＤグループの呼のみを受付できる状態とが設けられる。オペレータは、所望のログイン状態を示す機能ボタン１０９を押下することにより、そのログイン状態をＭＣＤサーバ７へ通知する。このように通知された各オペレータのログイン状態はＭＣＤサーバ７でそれぞれ管理される。

結果、マルチログイン可能なオペレータであってもそのオペレータのログイン状態が特定受付可状態の場合には、その特定受付の対象となるＡＣＤグループに属する呼のみがそのオペレータで着信される。

このように、実施例１によれば、オペレータは、自らの判断で優先して応対するＡＣＤグループをリアルタイムで選択することができる。例えば、マルチログイン対象の複数のＡＣＤグループに待ち呼が存在する場合に、それらＡＣＤグループのうち重要性や緊急性の高いＡＣＤグループの呼をオペレータ自ら選択して応対できる。従って、実施例１によれば、優先的に処理することが望ましい呼の待ち時間を少なくすることができ、ひいては、顧客満足度を向上させることができる。

更に、実施例１では、応対するＡＣＤグループの呼をオペレータが端末操作によって決定することができるため、システム管理者をそのために配置することなく、様々な着信状況に柔軟に対応することができる。実施例１によれば、特定のＡＣＤグループの呼のみを応対する状態に設定したり、マルチログイン状態に設定したりというふうにオペレータのログイン状態を柔軟に変更することができるため、オペレータの稼働率の低下も抑えることができる。

上述の実施例１のコンタクトセンタシステムでは、オペレータは、独自の判断でオペレータ端末９の機能ボタン１０９を押下することにより所望のＡＣＤグループに属する呼のみを受付する状態へ移行することができた。しかしながら、オペレータの判断のみに委ねると、マルチログイン可能なオペレータが常に所定のＡＣＤグループの特定受付可状態とし、このＡＣＤグループの呼が着信されない場合に、そのオペレータの稼働率が低下してしまうという問題がある。

そこで、実施例２におけるコンタクトセンタシステムは、特定受付可状態への移行を許容するか否かをＭＣＤサーバ７で判定する。以下、実施例２のコンタクトセンタシステムについて、実施例１と異なる部分のみを取り上げ説明する。

［システム構成］
図１５は、実施例２におけるコンタクトセンタシステムのシステム構成の概略を示す図である。実施例２におけるコンタクトセンタシステムは、実施例１の構成に加えて、管理者端末１０を更に備える。管理者端末１０は、オペレータ端末９と通信可能にネットワーク８に接続される。

［装置構成］
以下、実施例２のコンタクトセンタシステムの各ノードのうち、実施例１と異なるノードについて詳細を説明する。

〔ＭＣＤサーバ〕
ＭＣＤサーバ７の構成は、実施例１と同様である。以下、ＭＣＤサーバ７における実施例１と異なる処理部について説明する。オペレータ状態ＤＢ７７には、実施例１のオペレータ状態テーブルと共に、状態変化許容テーブルが含まれる。

図１６は、実施例２における状態変化許容テーブルの例を示す図である。図１６に示されるように、状態変化許容テーブルには、オペレータＩＤ毎に許容フラグが格納される。許容フラグは、特定受付可状態への変化を許容できるか否かを示す。例えば、図１６の「ＯＫ」が許可を示し、「ＮＧ」が拒絶を示す。

オペレータ管理部７４は、ＳＩＰ基本サーバ５から送られる状態変化通知を受け、この状態変化通知に含まれるログイン状態が特定受付可状態を示している場合に、この状態変化を許容するか否かを判定する。この判定において、オペレータ管理部７４は、状態変化通知に含まれるオペレータＩＤに対応する許容フラグを上記状態変化許容テーブルから抽
出する。オペレータ管理部７４は、この抽出された許容フラグが許可を示している場合に、その状態変化を許容する。オペレータ管理部７４は、抽出された許容フラグが拒絶を示している場合には、その状態変化を許容しない。

〔管理者端末〕
管理者端末１０は、パーソナルコンピュータや携帯情報端末などのようなコンピュータである。管理者端末１０は、スーパバイザ、リーダなどのオペレータを管理する管理者が利用する。管理者は、管理者端末１０を操作することにより、ＭＣＤサーバ７にアクセスし、上記オペレータ状態ＤＢ７７の状態変化許容テーブルの許容フラグを設定変更する。この設定変更は、例えば、ＷＥＢインタフェースで実現される。

例えば、ＭＣＤサーバ７は、管理者端末１０からオペレータＩＤを含む設定変更要求（HTTP）を受け、状態変化許容テーブルの該当オペレータＩＤを示す許容フラグを表示するＷＥＢページを管理者端末１０へ送信する。管理者端末１０ではこのＷＥＢページにより表示される画面上でその許容フラグを変更する操作が行われる。この操作により管理者端末１０からＭＣＤサーバ７へ変更通知が送られ、ＭＣＤサーバ７は、状態変化許容テーブルの該当レコードをその通知に含まれるデータで更新する。

［動作例］
図１７は、オペレータ端末で特定受付可状態を示す機能ボタンが押下された際における実施例２のコンタクトセンタシステムの動作例を示すシーケンス図である。

特定受付可状態を示す機能ボタン１０９が押下されると、実施例１と同様に、オペレータ端末９からＳＩＰ基本サーバ５を介してＭＣＤサーバ７へ状態変化通知が送られる（Ｓ１２０、１２１、１２２）。実施例２のＭＣＤサーバ７はこの状態変化通知を受信すると、オペレータ管理部７４は、その状態変化通知に含まれるオペレータＩＤ及びログイン状態を取得する。オペレータ管理部７４は、このオペレータＩＤに対応する許容フラグを上記状態変化許容テーブルから抽出する。オペレータ管理部７４は、この抽出された許容フラグを用いてその特定受付可状態への状態変化を受け付けるか否かを判定する（Ｓ１７１）。

オペレータ管理部７４は、その許容フラグが許可を示している場合には、実施例１と同様の処理を行う（図１２のＳ１２３、Ｓ１２４、Ｓ１２５、Ｓ１２６、Ｓ１２７、Ｓ１２８）。一方で、オペレータ管理部７４は、その許容フラグが拒絶を示している場合には、エラー通知をＳＩＰ基本サーバ５へ送信する（Ｓ１７２）。

ＳＩＰ基本サーバ５はこのエラー通知を受けると、端末管理部５６がそのエラー通知をオペレータ端末９へ送信する（Ｓ１７３）。オペレータ端末９はこのエラー通知を受信すると、ボタン制御部９３は、当該状態変化に失敗したことを認識し、ＬＥＤを元の状態のままとする。

例えば、ワーク状態において特定受付可状態を示す機能ボタン１０９が押下された後に、エラー通知を受けた場合には、ワーク状態を示す機能ボタン１０９のＬＥＤを点灯したままとする。オペレータ端末９は、表示部９７にこのエラーを示す情報を表示するようにしてもよい。この場合、オペレータは、特定受付可状態となれないことを認識し、特定受付可状態以外の状態を示す機能ボタン１０９（例えば、受付可状態を示す機能ボタン）を選択する。

〔実施例２の作用及び効果〕
実施例２では、オペレータ端末９から送られる、特定受付可状態への状態変化を要求す
る状態変化通知がＭＣＤサーバ７で受信されると、ＭＣＤサーバ７においてその状態変化を許すか否かが判定される。この判定において許可されない場合には、そのオペレータの特定受付可状態への状態変化は行われない。更に、この状態変化を許すか否かを示す許容フラグは、管理者端末１０から設定変更可能である。

従って、実施例２によれば、特定受付可状態への移行をオペレータの判断のみに委ねることなく、第三者の管理者がその移行の正当性を判断することができる。よって、オペレータの判断ミス等による稼働率の低下を防ぐことができる。

〔実施例２の変形例〕
上述の実施例２では、管理者端末１０により特定受付可状態への移行を許すか否かを示す許容フラグを設定変更していたが、この許容フラグを利用せず、ＭＣＤサーバ７の自動判定が行われるようにしてもよい。

この場合、ＭＣＤサーバ７のコールフロー制御部７５が、空の待ち呼キューに関し、そのＡＣＤグループの呼が着信されていない時間を逐次計測するようにする。オペレータ管理部７４は、状態変化通知を受信した際に、特定受付可状態の対象のＡＣＤグループに関し上記計測された未着信時間が所定の閾値を超えているか否かを判定する。オペレータ管理部７４は、当該状態変化通知が、未着信時間が所定の閾値を超えているＡＣＤグループの特定受付可状態への移行を要求している場合には、その状態変化を許容しないと判定する。なお、待ち呼が存在するＡＣＤグループを特定受付可状態とする要求のみを許容するようにしてもよい。

このようにすれば、長い間呼が着信されていないＡＣＤグループを対象として特定受付可状態とするオペレータが存在しなくなるため、オペレータの稼働率の低下を防ぐことができる。更に、このようにすれば、管理者端末１０を設けなくても済む。

［実施例１及び２の変形例］
実施例１におけるオペレータ端末９は、図１０に示すように、基本ボタンエリア１０５及び機能ボタンエリア１０４にそれぞれハードウェアボタンを備えていた。しかしながら、本実施形態はこのようなオペレータ端末９に限定するものではなく、オペレータ端末９はソフトウェアフォンとして実現されてもよい。ソフトウェアフォンは、パーソナルコンピュータや携帯情報端末などのコンピュータ上のアプリケーションで実現され、当該コンピュータの表示機器上に表示される画面により操作される。

この場合には、ＳＩＰ拡張サーバ６は、ボタン構成情報テーブル（図５参照）にソフトウェアフォン画面内の選択可能な要素を特定する識別情報と共にそのログイン状態を示す情報が格納されるようにすればよい。そして、端末管理部６５は、このような要素を特定する識別情報及びログイン状態を示す情報をボタン構成情報としてオペレータ端末９にダウンロードすればよい。

この場合、ＳＩＰ拡張サーバ６の端末管理部６５は、機能ボタンの点灯指示に替え、ＭＣＤサーバ７で管理されているオペレータのログイン状態を示す情報をソフトフォン画面に表示可能な状態で通知するようにすればよい。これにより、オペレータ端末９は、ＬＥＤ点灯ではなく、そのＭＣＤサーバ７で管理されているオペレータのログイン状態をオペレータに認識可能に表示するようにすればよい。例えば、オペレータ端末９は、「ＡＣＤグループＡの特定受付可能状態」といった文字列を表示するようにしてもよいし、画面上の擬似ＬＥＤ要素の色を変更することでログイン状態を認識させるようにしてもよい。

また、上述の実施例１及び２並びに上記変形例では、特定受付可状態を、マルチログイ
ン可能な複数のＡＣＤグループのうちのいずれか１つを受付可状態とする例を示したが、２つ以上のＡＣＤグループを受付可状態とするようにしてもよい。すなわち、特定受付可状態を、マルチログイン可能な複数のＡＣＤグループ全てよりも少ない数のＡＣＤグループを受付可状態とするようにしてもよい。この場合には、ＡＣＤグループの組み合わせを指定する特定受付可状態をログイン状態に含め、この状態をオペレータ端末９の他の機能ボタン１０９に割り当てるようにすればよい。

［その他］
〈ハードウェアの構成要素（Component）及びソフトウェアの構成要素（Component）について〉
ハードウェアの構成要素とは、ハードウェア回路であり、例えば、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、ゲートアレイ、論理ゲートの組み合わせ、信号処理回路、アナログ回路等がある。

ソフトウェアの構成要素とは、ソフトウェアとして上記処理を実現する部品（断片）であり、そのソフトウェアを実現する言語、開発環境等を限定する概念ではない。ソフトウェアの構成要素としては、例えば、タスク、プロセス、スレッド、ドライバ、ファームウェア、データベース、テーブル、関数、プロシジャ、サブルーチン、プログラムコードの所定の部分、データ構造、配列、変数、パラメータ等がある。これらソフトウェアの構成要素は、１又は複数のメモリ（１または複数のプロセッサ（例えば、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）等）上で実現される。

なお、上述の各実施形態は、上記各処理部の実現手法を限定するものではない。上記各処理部は、上記ハードウェアの構成要素又はソフトウェアの構成要素若しくはこれらの組み合わせとして、本技術分野の通常の技術者において実現可能な手法により構成されていればよい。

以上の本実施形態に関し、更に以下の付記を開示する。各項に開示される態様は、必要に応じて可能な限り組み合わせることができる。

（付記１）
オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループを該オペレータが受付可能である状態を示す状態通知を該オペレータ端末から受信する受信手段と、
保持部で保持される各呼グループに関する各オペレータの状態を前記状態通知が示す状態で更新する更新手段と、
呼が着信された場合に、前記保持部を参照することにより該呼が属する呼グループを受付可能なオペレータを特定し、該特定されたオペレータが利用するオペレータ端末に該呼を分配する呼分配手段と、
を備えることを特徴とする呼分散装置。

（付記２）
オペレータ端末を利用するオペレータの識別情報を該オペレータ端末から受信する識別情報受信手段と、
前記受信された識別情報で特定されるオペレータにとって応対可能な複数の呼グループの各々を識別可能な情報を前記オペレータ端末に送信する送信手段と、
を更に備えることを特徴とする付記１に記載の呼分散装置。

（付記３）
前記保持部で保持される情報に基づいて、オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループのうち該オペレータが受付可能状態にある呼グループを識別可能な情報を該オペレータ端末に通知する通知手段、
を更に備えることを特徴とする付記１又は２に記載の呼分散装置。

（付記４）
前記受信手段により受信された状態通知で示される状態を許可するか否かを判定する判定手段を更に備え、
前記更新手段は、前記判定手段により許可された場合にのみ更新処理を実行する、
ことを特徴とする付記１から３のいずれか１項に記載の呼分散装置。

（付記５）
複数のオペレータ端末と着信呼を該複数のオペレータ端末のいずれかに分配する呼分散装置とを含む呼分散システムで実行される呼分散方法において、
前記呼分散装置が、
オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループを該オペレータが受付可能である状態を示す状態通知を該オペレータ端末から受信するステップと、
保持部で保持される各呼グループに関する各オペレータの状態を前記状態通知が示す状態で更新するステップと、
呼が着信された場合に、前記保持部を参照することにより該呼が属する呼グループを受付可能なオペレータを特定するステップと、
前記特定されたオペレータが利用するオペレータ端末に該呼を分配するステップと、
を実行することを特徴とする呼分散方法。

（付記６）
前記オペレータ端末が、
前記オペレータ端末を利用するオペレータの識別情報を前記呼分散装置へ送信するステップを実行し、
前記呼分散装置が、
前記識別情報で特定されるオペレータにとって応対可能な複数の呼グループの各々を識別可能なグループ情報を前記オペレータ端末に送信するステップを更に実行し、
前記オペレータ端末が、
前記オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から、前記呼分散装置から送信された前記グループ情報に基づいて選択された少なくとも１つの呼グループを該オペレータが受付可能である状態を示す状態通知を前記呼分散装置へ送信するステップを更に実行する、
ことを特徴とする付記５に記載の呼分散方法。

（付記７）
前記呼分散装置が、
前記保持部で保持される情報に基づいて、前記オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループのうち該オペレータが受付可能状態にある呼グループを識別可能な情報を前記オペレータ端末に通知するステップを更に実行し、
前記オペレータ端末が、
前記通知された情報に基づいて、前記オペレータが受付可能状態にある呼グループを前記オペレータに識別可能な状態で出力するステップを更に実行する、
ことを特徴とする付記５又は６に記載の呼分散方法。

（付記８）
前記呼分散装置が、
前記保持部で保持される各呼グループに関する各オペレータの状態を前記状態通知が示す状態で更新する前に、前記受信された状態通知で示される状態を許可するか否かを判定するステップを更に実行する、
ことを特徴とする付記５から７のいずれか１項に記載の呼分散方法。

Claims (5)

1. オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループを該オペレータが受付可能である状態を示す状態通知を該オペレータ端末から受信する受信手段と、
   保持部で保持される各呼グループに関する各オペレータの状態を前記状態通知が示す状態で更新する更新手段と、
   呼が着信された場合に、前記保持部を参照することにより該呼が属する呼グループを受付可能なオペレータを特定し、該特定されたオペレータが利用するオペレータ端末に該呼を分配する呼分配手段と、
   を備えることを特徴とする呼分散装置。
2. オペレータ端末を利用するオペレータの識別情報を該オペレータ端末から受信する識別情報受信手段と、
   前記受信された識別情報で特定されるオペレータにとって応対可能な複数の呼グループの各々を識別可能な情報を前記オペレータ端末に送信する送信手段と、
   を更に備えることを特徴とする請求項１に記載の呼分散装置。
3. 前記保持部で保持される情報に基づいて、オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループのうち該オペレータが受付可能状態にある呼グループを識別可能な情報を該オペレータ端末に通知する通知手段、
   を更に備えることを特徴とする請求項１又は２に記載の呼分散装置。
4. 前記受信手段により受信された状態通知で示される状態を許可するか否かを判定する判定手段を更に備え、
   前記更新手段は、前記判定手段により許可された場合にのみ更新処理を実行する、
   ことを特徴とする請求項１から３のいずれか１項に記載の呼分散装置。
5. 複数のオペレータ端末と着信呼を該複数のオペレータ端末のいずれかに分配する呼分散装置とを含む呼分散システムで実行される呼分散方法において、
   前記呼分散装置が、
   オペレータ端末を利用するオペレータにとって応対可能な複数の呼グループの中から選択された少なくとも１つの呼グループを該オペレータが受付可能である状態を示す状態通知を該オペレータ端末から受信するステップと、
   保持部で保持される各呼グループに関する各オペレータの状態を前記状態通知が示す状態で更新するステップと、
   呼が着信された場合に、前記保持部を参照することにより該呼が属する呼グループを受付可能なオペレータを特定するステップと、
   前記特定されたオペレータが利用するオペレータ端末に該呼を分配するステップと、
   を実行することを特徴とする呼分散方法。

Images