JP2013141066A - コールセンタ運用システムおよびコールセンタ運用方法 - Google Patents

Abstract

【課題】ユーザにとって使いやすいコールセンタを実現する。
【解決手段】コールセンタ運用システム１０は、コールセンタに発呼した携帯端末の電話番号を取得する端末ＩＤ取得部１０２と、携帯端末との間に確立された呼を介して取得された情報を使用して、ユーザの認証を行うユーザ認証部１１８と、その認証が成功した場合、ウェブアクセス用パスワードを生成するウェブアクセス用パスワード生成部１２０と、ウェブアクセス用パスワードを、ユーザに、確立された呼を使用して音声で通知するウェブアクセス用パスワード通知部１１６と、携帯端末の電話番号を使用して、インターネット上のリソースを特定する送信ＵＲＬを携帯端末のユーザに通知するモバイルゲートウェイ群２２と、通知された送信ＵＲＬが特定するリソースへのアクセスが要求された場合、ウェブアクセス用パスワードを使用して認証を行うアクセス認証部１３６と、を備える。
【選択図】図２

Description

本発明は、コールセンタの運用に係るシステムおよび方法に関する。

銀行、証券会社、クレジットカード会社などの金融機関の多くは、自己が提供する金融サービスの利用者のためにコールセンタを設けている。一般に、コールセンタには多くのオペレータが常駐し、日々、利用者からかかってくる電話に応対している。そのような電話の目的は例えば、登録情報の変更や残高、明細の照会やクレームや質問である。

コールセンタを運営する側としてはオペレータ数を必要最小限程度としてコスト削減を図りたいが、一般にコールセンタへの呼量には時期や増減があるので、オペレータ数を減らしすぎると呼量が増大したときに利用者を長く待たせることとなる。これでは顧客満足度の維持は難しい。そこで、コールセンタに電話をかけてきた利用者を処理能力の高いウェブへ誘導するシステムが求められる。

近年、インターネットへアクセスする機能を備えているスマートホンに代表される多機能端末を用いてコールセンタに電話をかける利用者が増えてきている。このことから、特許文献１の技術によりコールセンタに電話をかけてきた利用者をウェブへ誘導することが可能となる。

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

しかしながら、従来のそのようなシステムは、単に電話口で自社のトップページのＵＲＬを読み上げるだけであったり、ウェブへ誘導されてきた利用者に煩雑な認証処理を要求するなど、使い勝手がよいとは言い難い。

本発明はこうした課題に鑑みてなされたものであり、その目的は、ユーザにとって使いやすいコールセンタを実現できるコールセンタ運用技術の提供にある。

本発明のある態様はコールセンタ運用システムに関する。このコールセンタ運用システムは、コールセンタに発呼した端末を特定する端末ＩＤを取得する端末ＩＤ取得部と、端末との間に確立された呼を使用して取得された情報を使用して、端末のユーザの認証を行うユーザ認証部と、ユーザ認証部における認証が成功した場合、アクセス認証情報を生成するアクセス認証情報生成部と、アクセス認証情報生成部によって生成されたアクセス認証情報を、端末との間に確立された呼を使用して音声で通知する音声通知部と、端末ＩＤ取得部によって取得された端末ＩＤに従い、インターネット上のリソースを特定するリソースＩＤを端末のユーザに通知するリソース通知部と、リソース通知部によって通知されたリソースＩＤが特定するリソースへのアクセスが要求された場合、アクセス認証情報生成部によって生成されたアクセス認証情報を使用して認証を行うアクセス認証部と、を備える。

この態様によると、ユーザ認証部における認証を利用してアクセス認証部における認証が行われる。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、ユーザにとって使いやすいコールセンタを実現できる

実施の形態に係るコールセンタ運用システムの構成を示す模式図である。 実施の形態に係るコールセンタ運用システムの機能および構成を示すブロック図である。 図２のユーザ情報保持部の一例を示すデータ構造図である。 図２のコールセンタ運用システムにおける、携帯端末からの着呼から携帯端末へのショートメッセージの送信までの一連の処理の一例を示すフローチャートである。 携帯端末のディスプレイに表示される例示的なＵＲＬ通知に係るショートメッセージの代表画面図である。 図２のコールセンタ運用システムにおける、アクセス要求からアクセス許可までの一連の処理の一例を示すフローチャートである。 携帯端末のディスプレイに表示される例示的なウェブアクセス用パスワード入力画面の代表画面図である。 携帯端末のディスプレイに表示される例示的なアクセス発生通知に係るショートメッセージの代表画面図である。

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。

コールセンタに電話をかけてきた利用者をウェブへ誘導する特許文献１に記載されるような従来のシステムにおいては、多機能端末によりウェブにアクセスしたとしても利用者は認証処理を求められるのが一般的である。特に金融機関では必須となる例が多い。そのため、利用者は多機能端末からウェブサイトにアクセスした後、ユーザＩＤやパスワードなどを入力することで認証することになるが、コールセンタに電話をかけたときに口頭で個人情報の確認により行う認証に比較すると不便である。

さらに、緊急時や災害時などではユーザＩＤなどを記憶していない他人の多機能端末を利用した場合や利用者がユーザＩＤなど思い出すことができなかった場合は、ウェブでの利用をあきらめることにもつながることから、利用者にとっては必ずしも便利なシステムではない。

そこで、実施の形態に係るコールセンタ運用システムは、コールセンタに電話をかけてきたユーザと通話状態にある間にそのユーザの本人認証を行う。コールセンタ運用システムは、オペレータが利用可能でない場合、公知のショートメッセージサービス（ＳＭＳ）を使用してユーザにアクセスすべきＵＲＬ（Uniform Resource Locator）を通知する。これにより、ユーザは、オペレータと話をすることができない場合でも、より容易かつ正確にアクセスすべきＵＲＬを知ることができる。特にユーザがインターネットにアクセス可能なスマートホンなどの多機能端末を使用している場合、ショートメッセージに含まれるＵＲＬをそのまま使用できる。

コールセンタ運用システムは、通知したＵＲＬへのアクセスが要求されると、通話状態におけるユーザの本人認証と連動したアクセス認証を行う。すなわち、コールセンタ運用システムは、通話状態におけるユーザの本人認証が成功すると、ユーザにワンタイムパスワードなどのアクセス認証情報を発行しておき、後にアクセス要求があったときのアクセス認証においてそのアクセス認証情報を使用する。ユーザは、通知されたＵＲＬへアクセスする際の認証において、コールセンタ運用システムによって発行されたアクセス認証情報を提供すればよい。したがって、通知されたＵＲＬへアクセスする際に通話状態におけるユーザの本人認証とは関連のない新たなアクセス認証が要求される場合と比較して、ユーザ側のアクセス認証にかかる手間や労力を削減できる。

そして全体として、ユーザにとってより使いやすく満足度の高いコールセンタが実現される。

図１は、実施の形態に係るコールセンタ運用システム１０の構成を示す模式図である。コールセンタ運用システム１０は、移動体通信網などの電話網１４およびインターネット１６のそれぞれを介してユーザの携帯端末１２と接続される。携帯端末１２は、例えば通話機能およびクライアントとしての機能の両方を備える携帯電話である。電話網１４は、それぞれ異なる通信事業者すなわち通信キャリアによって提供される複数の通信キャリア別電話網を含む。図１の例では、電話網１４は、第１通信キャリアによって提供される第１電話網１４ａと、第１通信キャリアとは異なる第２通信キャリアによって提供される第２電話網１４ｂと、を含む。

コールセンタ運用システム１０は、ＰＢＸ（Private Branch eXchange、構内交換機）サーバ１８と、ＩＶＲ（Interactive Voice Response）サーバ２０と、モバイルゲートウェイ群２２と、ＣＴＩ（Computer Telephony Integration）サーバ２４と、ウェブサーバ２６と、を備える。

ＰＢＸサーバ１８は電話網１４と接続され、携帯端末１２とコールセンタ運用システム１０との間の呼の確立、維持、切断等を制御する。
ＩＶＲサーバ２０は、ＰＢＸサーバ１８によって確立された呼を使用して、携帯端末１２に対して音声による自動応答を行う。ＩＶＲサーバ２０は、ユーザのボタン操作に合わせて、予め録音してある音声を自動的に再生してもよい。また、ＩＶＲサーバ２０は音声認識機能を備え、ユーザの発話に応じて再生内容を決めてもよい。
モバイルゲートウェイ群２２は複数のゲートウェイを含み、各ゲートウェイは電話網１４に対して、所定の通信キャリアのショートメッセージサービスにおけるショートメッセージを送信可能に構成されている。なお、ショートメッセージサービスは通信キャリアごとに異なっており、それらの間の連携はあってもよいしなくてもよい。

ＣＴＩサーバ２４は、電話とコンピュータとの連携をサポートする機能を提供するサーバであり、例えば、携帯端末１２を特定する端末ＩＤすなわち電話番号と、ユーザのプロフィールや過去の応対履歴などと、を対応付けてユーザデータベースに保持する。ＣＴＩサーバ２４は、ＰＢＸサーバ１８がユーザからの電話を受けると、その発信者番号を基にユーザデータベースからそのユーザのプロフィールや過去の応対履歴などを自動的に検索して、オペレータのＰＣ（Personal Computer）端末のディスプレイに表示させる。

ウェブサーバ２６は、インターネット１６を介して外部からアクセス可能なリソースを保持する。リソースは、例えばウェブページやウェブ上のファイルなどの、ＵＲＬが差し示す対象であってもよい。コールセンタ運用システム１０を使用して運用されるコールセンタが金融サービスに係るものである場合、リソースは、住所変更などの金融サービスに登録されたユーザ情報の変更を行うためのウェブページや、利用明細を表示するウェブページや、ポイントサービスにおけるポイント残高を照会するためのウェブページや、暗証番号を変更するためのウェブページなどであってもよい。

ＰＢＸサーバ１８、ＩＶＲサーバ２０、モバイルゲートウェイ群２２、ＣＴＩサーバ２４およびウェブサーバ２６は構内ＬＡＮ（Local Area Network）２８を介して相互に接続されている。構内ＬＡＮ２８にはオペレータの電話機（図１では不図示）も接続されている。

図２は、実施の形態に係るコールセンタ運用システム１０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

ＰＢＸサーバ１８は、携帯端末１２から呼の設定要求を受けると、携帯端末１２とオペレータ電話機３０との接続を試みる。ここでコールセンタ運用システム１０の全てのオペレータ電話機３０が通話中である（オペレータビジー）などの何らかの理由でオペレータ電話機３０との接続が不可能または困難である場合、ＰＢＸサーバ１８は呼をＩＶＲサーバ２０に転送し、携帯端末１２とＩＶＲサーバ２０との間に呼を確立する。
なお、ＰＢＸサーバ１８は、オペレータビジー以外の他の条件によって呼をＩＶＲサーバ２０に転送してもよい。

ＩＶＲサーバ２０は、携帯端末１２との間に呼が確立されると、ユーザをウェブへ誘導するための音声案内メッセージを携帯端末１２に送信する。ＩＶＲサーバ２０は、音声案内メッセージに対する回答がウェブへの誘導を希望することを示す場合、ユーザの本人認証を行うための本人認証情報と、ユーザがコールセンタに発呼した目的を示す目的情報と、の提供を促す音声メッセージを携帯端末１２に送信する。ＩＶＲサーバ２０は、本人認証が成功した場合、ウェブアクセス用パスワードを音声で携帯端末１２に通知する。

ＩＶＲサーバ２０は、誘導判定部１０１と、端末ＩＤ取得部１０２と、ユーザＩＤ取得部１０４と、キャリア情報取得部１０６と、機種情報取得部１０８と、本人認証情報取得部１１０と、目的情報取得部１１２と、ウェブアクセス用パスワード通知部１１６と、を含む。

誘導判定部１０１は、携帯端末１２との間に呼が確立されると、ユーザをウェブへ誘導するための音声案内メッセージを携帯端末１２に送信する。誘導判定部１０１は音声案内メッセージに対する回答から、ユーザがウェブへの誘導を希望するか否かを判定する。誘導判定部１０１は、音声案内メッセージに対する回答がウェブへの誘導を希望することを示す場合、ウェブ誘導のための以下の処理を続行させる。

端末ＩＤ取得部１０２は、コールセンタに発呼した携帯端末１２の電話番号を取得する。端末ＩＤ取得部１０２は端末ＩＤ確認部１０３と端末ＩＤ要求部１０５とを含む。
端末ＩＤ確認部１０３は、着呼の情報から携帯端末１２の電話番号が特定できるかを確認する。端末ＩＤ確認部１０３は、携帯端末１２からの着呼を知らせる情報のなかに携帯端末１２の電話番号が含まれている場合、その電話番号を抽出する。
端末ＩＤ要求部１０５は、携帯端末１２からの着呼を知らせる情報のなかに携帯端末１２の電話番号が含まれていない場合すなわち端末ＩＤ確認部１０３により電話番号が特定できない場合、携帯端末１２のユーザに電話番号の入力を要求し、要求に従って携帯端末１２に入力された電話番号を携帯端末１２の電話番号として取得する。

この際、端末ＩＤ要求部１０５は、携帯端末１２との間に確立された呼を使用して、電話番号の入力を促すＩＤ要求音声メッセージを携帯端末１２に送信してもよい。端末ＩＤ要求部１０５は、そのＩＤ要求音声メッセージの送信中または後、携帯端末１２から受信するＰＢ（Push Button）信号を電話番号に変換し、そのように変換された電話番号を携帯端末１２の電話番号として取得してもよい。あるいはまた、端末ＩＤ要求部１０５は、ユーザが携帯端末１２に対して発話することで携帯端末１２に入力する音声情報を携帯端末１２から受信し、受信された音声情報を公知の音声認識技術を使用して解析することで、携帯端末１２の電話番号を取得してもよい。
この場合、発信者番号が非通知の場合でも携帯端末１２の電話番号を取得することができる。

ユーザＩＤ取得部１０４、キャリア情報取得部１０６、機種情報取得部１０８、本人認証情報取得部１１０、目的情報取得部１１２はそれぞれ携帯端末１２との間に確立された呼を使用してユーザから、ユーザを特定するユーザＩＤ、携帯端末１２の通信キャリアを示すキャリア情報、携帯端末１２の機種を示す機種情報、本人認証情報、目的情報を取得する。

ユーザＩＤは例えばユーザの名前やコールセンタ運用システム１０におけるユーザの登録名である。
キャリア情報は例えば携帯端末１２が第１通信キャリアに属するかまたは第２通信キャリアに属するかを示す情報である。
本人認証情報は例えば予め登録されているパスワードや、ユーザの生年月日、出生地、干支、登録先住所などの属性情報である。
目的情報は例えばユーザが登録先住所の変更を望んでいることや残高の照会を望んでいることやパスワードの変更を望んでいることを示す。

ユーザＩＤ取得部１０４、キャリア情報取得部１０６、機種情報取得部１０８、本人認証情報取得部１１０、目的情報取得部１１２はいずれも情報取得の際、端末ＩＤ取得部１０２と同様の、確立された呼を使用した応答処理を行う。

ウェブアクセス用パスワード通知部１１６は、本人認証情報取得部１１０によって取得された本人認証情報を使用した本人認証が成功した場合に生成されるウェブアクセス用パスワードを、携帯端末１２のユーザに、携帯端末１２との間に確立された呼を使用して音声で通知する。例えば、ウェブアクセス用パスワードが「ＸＹＺ１２３」である場合、ウェブアクセス用パスワード通知部１１６は、携帯端末１２で処理された場合に携帯端末１２のスピーカから「ＸＹＺ１２３」と発声される合成音声情報を公知の音声合成技術を使用して生成し、携帯端末１２に送信する。

ＣＴＩサーバ２４は、ユーザ認証部１１８と、ウェブアクセス用パスワード生成部１２０と、アクセス先決定部１２２と、ゲートウェイ選択部１２４と、ユーザ情報保持部１２６と、ショートメッセージ送信指示部１２８と、を含む。

図３は、ユーザ情報保持部１２６の一例を示すデータ構造図である。ユーザ情報保持部１２６は、ユーザの名前と、登録先住所と、生年月日と、電話番号と、通信キャリアと、機種名と、アクセス先決定部１２２によって決定される送信ＵＲＬと、ウェブアクセス用パスワード生成部１２０によって生成されるウェブアクセス用パスワードと、そのウェブアクセス用パスワードの有効期限と、を対応付けて保持する。

ユーザ情報保持部１２６に電話番号が登録されているユーザについては、端末ＩＤ取得部１０２はユーザから電話番号を取得する代わりに、ユーザＩＤ取得部１０４によって取得されたユーザの名前に対応する電話番号をユーザ情報保持部１２６から取得してもよい。通信キャリア、機種についても同様である。なお、ここではユーザの名前をキーにして他の情報を引き出すことを説明したが、これに限られず、電話番号をキーにしてユーザの名前などの他の情報を引き出してもよい。また、ＣＴＩサーバ２４は、ユーザ情報保持部１２６に電話番号が登録されていないユーザについて、端末ＩＤ取得部１０２によって取得された電話番号をユーザ情報保持部１２６に登録してもよい。

図２に戻り、ユーザ認証部１１８は、ＩＶＲサーバ２０と携帯端末１２との間に確立された呼を使用して、携帯端末１２のユーザの本人認証を行う。ユーザ認証部１１８は、ユーザＩＤ取得部１０４によって取得されたユーザの名前がユーザ情報保持部１２６に登録されており、かつ、そのユーザの名前に対応してユーザ情報保持部１２６に登録されている生年月日が本人認証情報取得部１１０によって取得されたユーザの生年月日と一致する場合、携帯端末１２のユーザが本人であると判定する。すなわち、ユーザ認証部１１８におけるユーザの本人認証が成功する。ユーザ認証部１１８は、それ以外の場合、ユーザは本人でないと判定し、ＰＢＸサーバ１８に携帯端末１２との間の呼を切断させる。
なお、本人認証においてユーザＩＤとしてユーザの名前以外のものが使用されてもよいし、本人認証情報として生年月日以外のもの、例えば登録先住所が使用されてもよい。

ウェブアクセス用パスワード生成部１２０は、ユーザ認証部１１８における本人認証が成功した場合、アクセス認証情報すなわちウェブアクセス用パスワードを生成する。特に、ウェブアクセス用パスワードは有効期限が設定されたワンタイムパスワードである。ウェブアクセス用パスワード生成部１２０は、生成されたウェブアクセス用パスワードおよびその有効期限を、ユーザ認証部１１８において本人認証されたユーザの名前に対応付けてユーザ情報保持部１２６に登録する。ＩＶＲサーバ２０のウェブアクセス用パスワード通知部１１６は、ユーザ情報保持部１２６からウェブアクセス用パスワードを取得してもよい。

アクセス先決定部１２２は、ウェブサーバ２６によって保持されるリソースのなかから携帯端末１２のユーザがアクセスすべきリソースを決定する。リソースを決定することはリソースを特定するリソースＩＤすなわちＵＲＬを決定することであり、ここで決定されるＵＲＬを送信ＵＲＬと称す。アクセス先決定部１２２は送信ＵＲＬを短縮ＵＲＬの形で決定してもよい。この場合、ショートメッセージサービスにおけるショートメッセージのように一回に送信できる情報の量が制限されている状況においても、ＵＲＬ以外により多くの情報をユーザに伝達できる。アクセス先決定部１２２は、決定された送信ＵＲＬを、ユーザ認証部１１８において本人認証されたユーザの名前に対応付けてユーザ情報保持部１２６に登録する。

アクセス先決定部１２２は、目的情報取得部１１２によって取得された目的情報に対応するリソースを、ユーザがアクセスすべきリソースとして決定する。例えば、目的情報が登録先住所の変更を示す場合、アクセス先決定部１２２は、ユーザ認証部１１８において本人認証されたユーザの住所変更を行うためのウェブページのＵＲＬを送信ＵＲＬとして決定する。

アクセス先決定部１２２は、機種情報取得部１０８によって取得された機種情報に基づき、携帯端末１２がインターネット１６と接続可能であるか否かを判定してもよい。接続不可と判定された場合、アクセス先決定部１２２は送信ＵＲＬの決定を中止してもよい。あるいはまた、目的情報取得部１１２によって取得された目的情報に対応するリソースが携帯端末１２の機種ごとに存在する場合は、アクセス先決定部１２２は機種情報が示す機種に対応するほうのリソースのＵＲＬを送信ＵＲＬとして決定してもよい。例えば住所変更を行うためのウェブページとして携帯電話専用のウェブページと一般ＰＣ（Personal Computer）用のウェブページとが用意されている場合、アクセス先決定部１２２は、機種情報が示す機種が携帯電話専用のウェブページしか扱えない機種であれば前者を、一般ＰＣ用のウェブページを扱える機種であれば後者を、選択してもよい。

ゲートウェイ選択部１２４はキャリア情報取得部１０６によって取得されたキャリア情報に基づき、モバイルゲートウェイ群２２に含まれるゲートウェイのなかからショートメッセージの送信に使用すべきゲートウェイを選択する。特にゲートウェイ選択部１２４は、携帯端末１２が属する通信キャリアによって提供される電話網に対応するゲートウェイを選択する。

ショートメッセージ送信指示部１２８は、アクセス先決定部１２２によって決定された送信ＵＲＬをメッセージ内容に含むショートメッセージを、端末ＩＤ取得部１０２によって取得された電話番号（以下、発番号と称す）宛に送信するよう、ゲートウェイ選択部１２４によって選択されたゲートウェイに指示する。この指示はＰＢＸサーバ１８を介して行われてもよい。ショートメッセージ送信指示部１２８は、送信ＵＲＬと発番号とを含むショートメッセージ送信依頼信号を、ゲートウェイ選択部１２４によって選択されたゲートウェイに送信する。

モバイルゲートウェイ群２２は、第１電話網１４ａに対応する第１キャリア用ゲートウェイ１３０と、第２電話網１４ｂに対応する第２キャリア用ゲートウェイ１３２と、を含む。ゲートウェイ選択部１２４におけるゲートウェイの選択の結果、モバイルゲートウェイ群２２は、キャリア情報取得部１０６によって取得されたキャリア情報に対応するショートメッセージサービスにおけるショートメッセージを送信する。

第１キャリア用ゲートウェイ１３０は、ショートメッセージ送信依頼信号を受信すると、ショートメッセージ送信依頼信号に含まれる発番号を使用して、ショートメッセージ送信依頼信号に含まれる送信ＵＲＬを携帯端末１２のユーザに通知する。特に第１キャリア用ゲートウェイ１３０は、第１通信キャリアのショートメッセージサービスにおけるショートメッセージに送信ＵＲＬを含め、発番号宛に第１電話網１４ａを介して送信する。
第２キャリア用ゲートウェイ１３２についても同様である。

ウェブサーバ２６は、リソースを保持するリソース保持部１３４と、アクセス認証部１３６と、アクセス発生通知部１４０と、を含む。
アクセス認証部１３６は、モバイルゲートウェイ群２２によってユーザに通知された送信ＵＲＬが特定するリソースへのアクセスが要求された場合、ウェブアクセス用パスワード生成部１２０によって生成されたウェブアクセス用パスワードを使用して認証を行う。アクセス認証部１３６は、携帯端末１２からインターネット１６を介して、リソース保持部１３４によって保持されるリソースへのアクセス要求を受けると、ユーザ情報保持部１２６を参照し、そのリソースに対してウェブアクセス用パスワードが発行されているか否かを判定する。アクセス認証部１３６は、アクセス要求に係るＵＲＬがユーザ情報保持部１２６に送信ＵＲＬとして登録されている場合、対応するウェブアクセス用パスワードおよび有効期限をユーザ情報保持部１２６から抽出する。登録されていない場合、アクセス認証部１３６はＩＶＲサーバ２０における本人認証とは連動しない任意の認証処理を行ってもよいし、認証を行わなくてもよい。

アクセス認証部１３６は、アクセス要求を受けた時刻が抽出された有効期限を過ぎている場合、送信ＵＲＬが特定するリソースへのアクセスを許可しない。この場合、アクセス認証部１３６はその送信ＵＲＬ、ウェブアクセス用パスワード、有効期限をユーザ情報保持部１２６から消去してもよい。これにより、ユーザは、ウェブアクセス用パスワードの有効期限が切れてしまった場合でも、本人認証とは連動しない任意の認証処理を経ることで送信ＵＲＬが特定するリソースにアクセスできる。

アクセス認証部１３６は、ウェブアクセス用パスワードの有効期限が切れていない場合、ユーザによって携帯端末１２に入力されるウェブアクセス用パスワードをインターネット１６を介して取得する。例えばアクセス認証部１３６は、ウェブアクセス用パスワードの入力を促すウェブアクセス用パスワード入力画面を携帯端末１２のディスプレイに表示させるためのパスワード入力画面情報を生成し、インターネット１６を介して携帯端末１２に送信する。アクセス認証部１３６は、ウェブアクセス用パスワード入力画面に対して入力されたウェブアクセス用パスワードをインターネット１６を介して取得する。

アクセス認証部１３６は、ユーザによって携帯端末１２に入力されたウェブアクセス用パスワードとユーザ情報保持部１２６から抽出されたウェブアクセス用パスワードとが一致する場合、送信ＵＲＬが特定するリソースへのアクセスを許可し、一致しない場合は許可しない。

アクセス発生通知部１４０は、アクセス認証部１３６におけるアクセス認証が成功した場合、アクセス認証に係る送信ＵＲＬに対応してユーザ情報保持部１２６に保持されている電話番号（以下、対応保持番号と称す）を使用して、送信ＵＲＬが特定するリソースにアクセスがあったことを示すアクセス発生情報を携帯端末１２のユーザに通知する。アクセス発生通知部１４０は、アクセス発生情報をメッセージ内容に含むショートメッセージを対応保持番号宛に送信するよう、ゲートウェイ選択部１２４によって選択されたゲートウェイに指示する。アクセス発生通知部１４０は、アクセス発生情報と対応保持番号とを含むアクセス発生メッセージ送信依頼信号を、ゲートウェイ選択部１２４によって選択されたゲートウェイに送信する。選択されたゲートウェイは、ショートメッセージにアクセス発生情報を含め、対応保持番号宛に電話網１４を介して送信する。
この場合、万が一送信ＵＲＬが特定するリソースへの不正アクセスが有った場合でもユーザはその事実を素早く知ることができ、より迅速に適切な対策を取ることができる。

以上の構成によるコールセンタ運用システム１０の動作を説明する。
図４は、コールセンタ運用システム１０における、携帯端末１２からの着呼から携帯端末１２へのショートメッセージの送信までの一連の処理の一例を示すフローチャートである。例えば登録先住所の変更を希望するユーザは、携帯端末１２にコールセンタの電話番号を入力し、発信ボタンを押す。すると携帯端末１２はコールセンタの電話番号宛に発呼する。ＰＢＸサーバ１８は電話網１４を介してそのような発呼に対応する呼の接続要求を受ける（着呼、Ｓ２０２）。ＰＢＸサーバ１８は着呼があると、その呼をオペレータ電話機３０と接続可能か否かを判定する（Ｓ２０４）。可能な場合（Ｓ２０４のＹ）、ＰＢＸサーバ１８は呼をオペレータ電話機３０に転送する（Ｓ２０６）。ユーザとオペレータとの通話が終了すると、呼が切断される（Ｓ２２２）。可能でない場合（Ｓ２０４のＮ）、ＰＢＸサーバ１８は呼をＩＶＲサーバ２０と接続し、ＩＶＲサーバ２０は音声案内メッセージを携帯端末１２に送信する（Ｓ２０８）。携帯端末１２では例えば「只今オペレータが混み合っておりますので改めてお掛け直し頂くか、お客様はウェブ回答サービス、もしくは音声自動応答サービスをご利用されるかお知らせください。ウェブ回答サービスは、お客様に後ほどお知りになりたい内容のＵＲＬをショートメッセージで通知するサービスです。ウェブ回答サービスご利用のお客様は１を、音声自動応答サービスご利用のお客様は２を押して下さい。」というメッセージが流れる。

ＩＶＲサーバ２０は、ユーザがウェブへの誘導を希望するか否かを判定する（Ｓ２１０）。ＩＶＲサーバ２０は、音声案内メッセージの送信中または後に「１」に対応するＰＢ信号を受信すると、ユーザがウェブへの誘導を希望すると判定し、「２」に対応するＰＢ信号を受信すると、ユーザがウェブへの誘導を希望せず音声自動応答を希望すると判定する。ユーザが音声自動応答を希望すると判定された場合（Ｓ２１０のＮ）、ＩＶＲサーバ２０は所定の音声自動応答処理を行う（Ｓ２１２）。音声自動応答処理が終了すると、呼が切断される（Ｓ２２２）。ユーザがウェブへの誘導を希望すると判定された場合（Ｓ２１０のＹ）、ＩＶＲサーバ２０は着呼を知らせる情報のなかに発番号の情報が含まれているか否かを判定する（Ｓ２１４）。含まれていないと判定された場合（Ｓ２１４のＮ）、ＩＶＲサーバ２０は確立された呼を使用して音声でユーザに問い合わせることによって発番号を取得する（Ｓ２１６）。特にＩＶＲサーバ２０はＩＤ要求音声メッセージを携帯端末１２に送信する。携帯端末１２では例えば「お客様のお電話の電話番号を取得できません。ウェブ回答サービスではショートメッセージを使用するため、お客様のお電話番号が必要となります。ピッという音の後にお客様のお電話番号を押して下さい。」というメッセージが流れる。

ステップＳ２１６で発番号が取得された場合または着呼を知らせる情報のなかに発番号の情報が含まれていると判定された場合（Ｓ２１４のＹ）、ＩＶＲサーバ２０は、確立された呼を使用して音声でユーザに問い合わせることによってユーザの名前、通信キャリア、機種、生年月日、登録先住所、などのユーザ情報を取得する（Ｓ２１８）。ＣＴＩサーバ２４は、取得されたユーザ情報を使用してユーザの本人認証を行う（Ｓ２２０）。本人認証が失敗した場合（Ｓ２２０のＮＧ）、呼が切断される（Ｓ２２２）。本人認証が成功した場合（Ｓ２２０のＯＫ）、ＣＴＩサーバ２４はウェブアクセス用パスワードを発行する（Ｓ２２４）。ＩＶＲサーバ２０は、確立された呼を使用して音声でユーザに問い合わせることによって目的情報を取得する（Ｓ２２６）。ＩＶＲサーバ２０は、確立された呼を使用して音声で、ウェブアクセス用パスワードをユーザに通知する（Ｓ２２８）。携帯端末１２では例えば「ウェブアクセス用認証パスワードを発行致します。メモのご用意をお願い致します。ウェブアクセス用のパスワードは、ＸＹＺ１２３です。ショートメッセージ送信後の有効期限は１０分です。１０分以内にウェブアクセスをお願いいたします。」というメッセージが流れる。そして「後ほど、ウェブ回答サービスをご案内します。」というメッセージが流れ、呼が切断される（Ｓ２３０）。

ＣＴＩサーバ２４は、取得された目的情報に基づいて送信ＵＲＬを決定する（Ｓ２３２）。ＣＴＩサーバ２４は、携帯端末１２の通信キャリアに対応するゲートウェイを選択する（Ｓ２３４）。モバイルゲートウェイ群２２は、選択されたゲートウェイから、取得された発番号宛に、送信ＵＲＬを含むショートメッセージを送信する（Ｓ２３６）。

図５は、携帯端末１２のディスプレイに表示される例示的なＵＲＬ通知に係るショートメッセージ３００の代表画面図である。ショートメッセージ３００は送信ＵＲＬ３０２を含む。送信ＵＲＬ３０２は携帯端末１２の機能によりハイパーリンク化されている。

図６は、コールセンタ運用システム１０における、アクセス要求からアクセス許可までの一連の処理の一例を示すフローチャートである。ユーザが携帯端末１２のディスプレイに表示されたショートメッセージ３００の送信ＵＲＬ３０２をクリック等で指定すると、携帯端末１２は送信ＵＲＬ３０２が特定するリソースへのアクセス要求をインターネット１６に送信する。ウェブサーバ２６はそのアクセス要求を受け付ける（Ｓ２３８）。ウェブサーバ２６は、ユーザ情報保持部１２６を参照し、アクセス要求に含まれるアクセス対象のＵＲＬが、ショートメッセージによってユーザに通知された送信ＵＲＬであるか否かを判定する（Ｓ２４０）。送信ＵＲＬでないと判定された場合（Ｓ２４０のＮ）、ウェブサーバ２６は任意の認証処理を行う（Ｓ２４２）。送信ＵＲＬであると判定された場合（Ｓ２４０のＹ）、ウェブサーバ２６はアクセス要求を受け付けた時刻が有効期限内であるか否かを判定する（Ｓ２４４）。有効期限内でないと判定された場合（Ｓ２４４のＮ）、ウェブサーバ２６はリソースへのアクセスを許可しない（Ｓ２４６）。有効期限内であると判定された場合（Ｓ２４４のＹ）、ウェブサーバ２６はユーザにウェブアクセス用パスワードの入力を要求する（Ｓ２４８）。

図７は、携帯端末１２のディスプレイに表示される例示的なウェブアクセス用パスワード入力画面３０４の代表画面図である。ウェブアクセス用パスワード入力画面３０４は、ユーザによってウェブアクセス用パスワードが入力されるウェブアクセス用パスワード入力領域３０６を有する。ユーザがウェブアクセス用パスワード入力領域３０６にウェブアクセス用パスワードを入力し、ＯＫボタン３０８を指定すると、携帯端末１２はウェブアクセス用パスワード入力領域３０６に入力されたウェブアクセス用パスワードをインターネット１６を介してウェブサーバ２６に送信する。

図６に戻り、ウェブサーバ２６は、ユーザによって入力されたウェブアクセス用パスワードを受信すると、そのパスワードがユーザ情報保持部１２６に保持されるウェブアクセス用パスワードと一致するか否かを判定する（Ｓ２５０）。一致しないと判定された場合（Ｓ２５０のＮ）、ウェブサーバ２６はリソースへのアクセスを許可しない（Ｓ２４６）。一致すると判定された場合（Ｓ２５０のＹ）、ウェブサーバ２６はリソースへのアクセスを許可する（Ｓ２５２）。リソースへのアクセスが許可されると、ウェブサーバ２６は、送信ＵＲＬが特定するリソースがアクセスされた旨を対応保持番号宛に通知する（Ｓ２５４）。

図８は、携帯端末１２のディスプレイに表示される例示的なアクセス発生通知に係るショートメッセージ３１０の代表画面図である。ショートメッセージ３１０は、送信ＵＲＬ３１２を含み、送信ＵＲＬ３１２へのアクセスが有った旨を示す。

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。

本実施の形態に係るコールセンタ運用システム１０によると、ユーザはオペレータと話ができない場合でも、システムによって案内されるＵＲＬにアクセスすることによって自己解決を図ることができる。これにより、ユーザはオペレータが利用可能となるまで待つ必要はないので、顧客満足度が向上する。また、そのようなウェブによる自己解決に抵抗のないＩＴリテラシーの高いユーザが増えるにつれて、より少ないオペレータでコールセンタを運営できるようになり、コスト的に有利となりうる。

また、本実施の形態に係るコールセンタ運用システム１０は、コールセンタに発呼した携帯端末１２に、ユーザがアクセスすべき送信ＵＲＬをショートメッセージで通知する。したがって、ユーザはアクセスすべきＵＲＬを自分で探したり入力したりする必要はないので、ウェブへのアクセスの際のユーザ側の手間を軽減できる。

また、携帯端末１２とＩＶＲサーバ２０との間に呼が確立されている間に、ユーザの本人認証、ウェブアクセス用パスワードの発行およびウェブアクセス用パスワードの音声による通知が行われる。したがって、例えばウェブアクセス用パスワードを呼の切断後に別便の電子メール等で伝える場合と比較して、本人認証が成功したユーザにより確実にかつ素早くウェブアクセス用パスワードを伝えることができる。

また、送信ＵＲＬはショートメッセージ、ウェブアクセス用パスワードは音声、というようにそれぞれ別々の手段でユーザに通知されるので、セキュリティの度合いを高めることができる。

そして、本人認証に基づくウェブアクセス用パスワードの発行、ウェブアクセス用パスワードを使用したアクセス認証、さらには短縮ＵＲＬに有効期限を設定することにより、ユーザにシームレスなセキュリティ施策を提供することができ、コールセンタの円滑な運用をサポートできる。
特に、コールセンタ運用システム１０によってシームレスなウェブ誘導が実現されるので、東日本大震災に代表される大規模災害等によって突発的に呼量が増加した場合でもより少ないオペレータ数で顧客満足度を維持できる。

また、本実施の形態に係るコールセンタ運用システム１０では、ウェブサーバ２６におけるアクセス認証は呼を介したユーザの本人認証と連動しており、アクセス認証では、本人認証が成功した場合に発行されるウェブアクセス用パスワードが使用される。これにより、アクセス認証を、セキュリティの度合いを維持しつつ、本人認証の結果を援用してより簡易にすることができる。その結果、アクセス認証時のユーザ側の負担を軽減できる。例えば、ユーザはアクセス認証用の別途のユーザＩＤ、パスワードを覚えておかなくても、コールセンタ運用システム１０から通知されるウェブアクセス用パスワードを使用することができる。

また、本実施の形態に係るコールセンタ運用システム１０によると、コールセンタの受付時間外やオペレータの不在時にも、ユーザは自らウェブで要望を処理することができるので、顧客満足度を向上できる。

また、本実施の形態に係るコールセンタ運用システム１０では、ユーザの呼の目的に対応するリソースを特定する送信ＵＲＬがユーザに通知される。例えば、呼の目的が住所変更である場合に、金融機関のトップページのＵＲＬが通知されるのではなく、その金融機関のウェブページのなかでも発呼したユーザの登録先住所を変更するためのウェブページのＵＲＬが通知される。これにより、ユーザ側のブラウジングの手間を省くことができる。

また、本実施の形態に係るコールセンタ運用システム１０では、送信ＵＲＬの通知手段としてショートメッセージサービスが採用される。ショートメッセージサービスでは、宛先の電話番号が分かればショートメッセージを送れるので、かかってきた電話に対応してメッセージを送るという本実施の形態のコンセプトとの親和性がよい。すなわち、一般に電子メールアドレスはアルファベットと数字と記号との組み合わせであり、電話口で伝えることは難しい。一方電話番号であればＰＢ信号や音声認識により比較的容易に伝えることができる。また、発信者番号が通知される場合は電話口で伝える必要さえない。そのようにより容易に取得できる電話番号を宛先とするショートメッセージサービスを採用することで、ユーザ側の負担を軽減し、コールセンタ運用システム１０の構成をより簡易とすることができる。

また、本実施の形態に係るコールセンタ運用システム１０では、携帯端末１２の通信キャリアに対応したゲートウェイが選択され、そのゲートウェイからショートメッセージが送信される。したがって、通信キャリア間でショートメッセージサービスの連携がない場合でも、より確実に携帯端末１２にショートメッセージを送信できる。

近年、携帯電話の番号持ち運び制度（Mobile Number Portability、ＭＮＰ）の浸透により、電話番号から通信キャリアを割り出すことが困難になってきている。このような状況において、本実施の形態に係るコールセンタ運用システム１０ではキャリア情報取得部１０６がユーザに明示的に通信キャリアを問い合わせる。したがって、通信キャリアごとに異なるショートメッセージサービスのなかから、より確実に適切なショートメッセージサービスを選択することができる。

また、本実施の形態に係るコールセンタ運用システム１０では、オペレータがビジーでないときでもユーザをウェブに誘導することにより、ユーザをオペレータに接続する頻度を下げることができる。一般に、オペレータと話をするほうがウェブアクセス用パスワードを発行するよりも時間がかかるので、オペレータへの接続頻度を下げることで、オペレータおよび電話回線の両方をより効率的に使用できる。

また、本実施の形態に係るコールセンタ運用システム１０では、ＩＴリテラシーの高いユーザは、コールセンタへ最初に電話をかけてウェブへ誘導されると、次回以降はコールセンタに電話をかけることなくウェブで解決する場合が多いと考えられる。コールセンタ運用システム１０は、次回以降そのようにウェブで自己解決することを補助するアプリケーションを、初回のアクセス時にユーザにダウンロードさせてもよい。その結果、ＩＴリテラシーの高いユーザが電話してこなくなった分だけコールセンタへの呼量を低減でき、オペレータ数の削減に寄与する。

一般的に、ＳＭＳは個人−個人間の情報伝達に使用され、またサービスも基本的にはそのような個人−個人間の情報伝達をサポートするよう設計されている。したがって、企業などの事業者が個人に情報を発信するために使用するのには適さない面が存在しうることは否めない。例えば、キャリア間のＳＭＳの連携が無い場合がそうである。そこで本実施の形態は、ＳＭＳを事業者側が実際に利用するときに必要となるソリューションを提供する。

また、コールセンタにかってくるユーザの電話は、ウェブ上で解決できる問い合わせ内容に係るものである場合が多い。それにも関わらず、電話の利便性等から、ユーザはウェブを見ないで直接コールセンタに架電してくる場合が多い。そこで本実施の形態に係るコールセンタ運用システム１０を採用すると、ウェブ上で行う顧客プル型サービスの啓蒙と促進が図られる。

従来では、ＩＶＲのガイダンスは比較的深く、場合によってはユーザ側がかけてきた電話を切断（ゼロアウト）することがある。そして、多くのユーザは切断後再度掛け直してくるので、結果的にコールセンタ側の呼量が増える虞がある。そこで、本実施の形態に係るコールセンタ運用システム１０によると、ウェブへ誘導することでより多くのリクエストを拾うことができるので、そのような放棄呼を削減することができる。

一般的に、ＳＭＳはコールセンタ運営側の効率を意識したサービスではなく、ユーザ側の利便性を意識したサービスであると言える。したがって、本実施の形態のような工夫を施さない状態では、コールセンタ側のコール量削減に寄与しない可能性がある。すなわち、本実施の形態に係るコールセンタ運用システム１０は、そのようなＳＭＳをコールセンタの運営効率向上まで昇華させたサービスを可能とする。

一般的に、電話はＩＶＲ上で処理されるため、処理行為はコールセンタ側が保有する物理的なポート数に依存することが多い。そこで本実施の形態に係るコールセンタ運用システム１０を使用することで、ユーザ側が最初からのウェブ対応に馴染めば、処理はサーバ／ネットワークの処理速度に依存するようになる。これにより、処理パフォーマンスを大きく変えることが可能となる。

以上、実施の形態に係るコールセンタ運用システム１０の構成と動作について説明した。これらの実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施の形態に係るコールセンタ運用システム１０のサーバ構成は一例であり、他の構成も可能である。また、あるサーバの機能の一部または全部を他のサーバに移すことも可能である。

実施の形態では、アクセス認証部１３６はユーザ情報保持部１２６を参照する場合について説明したが、これに限られず、例えばユーザ情報保持部１２６に対応する保持部をウェブサーバ２６に生成しておき、アクセス認証部はこの保持部を参照してもよい。

実施の形態では、ウェブアクセス用パスワード生成部１２０は、ユーザ認証部１１８における本人認証が成功した場合、アクセス認証情報すなわちウェブアクセス用パスワードを生成する場合について説明したが、これに限られない。例えば、アクセス認証情報は、ユーザの属性の種別を指定する情報であってもよい。属性の種別は例えば生年月日、干支、登録先住所、などである。この場合、アクセス認証部はユーザに、属性の種別を指定せずに情報の入力を要求する、ユーザは、属性の種別として生年月日が指定されている場合は、自己の生年月日を入力する。この場合、指定された種別自体がユーザとシステムとの間の秘密となっており、他者はアクセス認証時に入力すべき属性が分からないので不正アクセスは困難である。

実施の形態において、ショートメッセージ送信指示部１２８は、携帯端末１２が属する通信キャリアのＳＭＳにおけるショートメッセージの最大文字数を取得してもよい。ショートメッセージ送信指示部１２８は、送信ＵＲＬの文字数が取得された最大文字数を超える場合、送信ＵＲＬの代わりにＵＲＬを送信できない旨のメッセージをショートメッセージに含めてもよい。あるいはまた、予め非対応のＳＭＳを定めておき、ウェブアクセス用パスワード通知部１１６は、携帯端末１２が属する通信キャリアのＳＭＳが非対応のＳＭＳである場合、非対応である旨の音声メッセージを携帯端末１２に送信してもよい。

実施の形態では、図４から図８に関連して、登録先住所の変更を希望するユーザがコールセンタに電話をかけ、そのユーザに住所変更用のウェブページのＵＲＬが通知される場合について説明したが、これに限られない。例えば、コールセンタ運用システムのＩＶＲサーバは、住所変更の架電を受けた場合、変更されるべき住所の情報を所定の音声認識技術を使用して一次受けしてもよい。コールセンタ運用システムのＣＴＩサーバは、一次受けした情報に基づき自動的に住所の変更処理をしてもよい。その後、コールセンタ運用システムのモバイルゲートウェイ群は、変更処理後の住所を示すウェブページのＵＲＬをユーザにショートメッセージを使って通知してもよい。コールセンタ運用システムのウェブサーバは、ユーザがそのＵＲＬを指定したとき、ウェブアクセス用パスワードの入力を要求してもよい。この場合、ユーザは電話口で行った住所変更の結果を確認できる。また、ＳＭＳを利用する場合、一度に送信できるデータ量の制限により、住所変更の結果そのもののような比較的大きなデータを送ることは困難であるが、ＵＲＬであれば十分容易に送ることができる。
あるいはまた、カード使用明細や利用残金確認にも本実施の形態の技術的思想を適用できる。

１０ コールセンタ運用システム、 １２ 携帯端末、 １６ インターネット、 １０２ 端末ＩＤ取得部、 １０６ キャリア情報取得部、 １１２ 目的情報取得部、 １１８ ユーザ認証部、 １３６ アクセス認証部、 １４０ アクセス発生通知部。

Claims (12)

1. コールセンタに発呼した端末を特定する端末ＩＤを取得する端末ＩＤ取得部と、
   前記端末との間に確立された呼を使用して取得された情報を使用して、前記端末のユーザの認証を行うユーザ認証部と、
   前記ユーザ認証部における認証が成功した場合、アクセス認証情報を生成するアクセス認証情報生成部と、
   前記アクセス認証情報生成部によって生成されたアクセス認証情報を、前記端末との間に確立された呼を使用して音声で通知する音声通知部と、
   前記端末ＩＤ取得部によって取得された端末ＩＤに従い、インターネット上のリソースを特定するリソースＩＤを前記端末のユーザに通知するリソース通知部と、
   前記リソース通知部によって通知されたリソースＩＤが特定するリソースへのアクセスが要求された場合、前記アクセス認証情報生成部によって生成されたアクセス認証情報を使用して認証を行うアクセス認証部と、を備えることを特徴とするコールセンタ運用システム。
2. 前記端末ＩＤ取得部は、
   着呼の情報から端末ＩＤが特定できるかを確認する端末ＩＤ確認部と、
   前記端末ＩＤ確認部により端末ＩＤが特定できない場合に、前記端末との間に確立された呼を使用して端末ＩＤの入力を要求する端末ＩＤ要求部と、を含むことを特徴とする請求項１に記載のコールセンタ運用システム。
3. インターネット上のリソースへの誘導を希望するか否かを判定する誘導判定部をさらに備えることを特徴とする請求項１または２に記載のコールセンタ運用システム。
4. 前記端末との間に確立された呼を使用して、前記端末のユーザがコールセンタに発呼した目的を示す目的情報を取得する目的情報取得部をさらに備え、
   前記リソース通知部は、前記目的情報取得部によって取得された目的情報に対応するリソースを特定するリソースＩＤを前記端末のユーザに通知することを特徴とする請求項１から３のいずれかに記載のコールセンタ運用システム。
5. 前記リソース通知部は、インターネット上のリソースを特定するリソースＩＤをショートメッセージサービスにおけるショートメッセージに含め、前記端末ＩＤ取得部によって取得された端末ＩＤ宛に送信することを特徴とする請求項１から４のいずれかに記載のコールセンタ運用システム。
6. 前記端末の通信キャリアを示すキャリア情報を取得するキャリア情報取得部をさらに備え、
   前記リソース通知部は、前記キャリア情報取得部によって取得されたキャリア情報に対応するショートメッセージサービスにおけるショートメッセージを送信することを特徴とする請求項５に記載のコールセンタ運用システム。
7. 前記端末ＩＤ取得部は、前記端末からの着呼を知らせる情報のなかに端末ＩＤが含まれていない場合、前記端末のユーザによって前記端末に入力された端末ＩＤを前記端末を特定する端末ＩＤとして取得することを特徴とする請求項１から６のいずれかに記載のコールセンタ運用システム。
8. 前記アクセス認証情報生成部によって生成されるアクセス認証情報はワンタイムパスワードであることを特徴とする請求項１から７のいずれかに記載のコールセンタ運用システム。
9. 前記アクセス認証情報生成部によって生成されるアクセス認証情報は、ユーザの属性の種別を指定する情報であることを特徴とする請求項１から７のいずれかに記載のコールセンタ運用システム。
10. 前記アクセス認証部における認証が成功した場合、前記端末ＩＤ取得部によって取得された端末ＩＤを使用して、前記リソース通知部によって通知されたリソースＩＤが特定するリソースにアクセスがあったことを示すアクセス発生情報を前記端末のユーザに通知するアクセス発生通知部をさらに備えることを特徴とする請求項１から９のいずれかに記載のコールセンタ運用システム。
11. コールセンタに発呼した端末を特定する端末ＩＤを取得するステップと、
    前記端末との間に確立された呼を使用して取得された情報を使用して、前記端末のユーザの認証を行うステップと、
    ユーザの認証が成功した場合、アクセス認証情報を生成するステップと、
    生成されたアクセス認証情報を、前記端末との間に確立された呼を使用して音声で通知するステップと、
    取得された端末ＩＤに従い、インターネット上のリソースを特定するリソースＩＤを前記端末のユーザに通知するステップと、
    通知されたリソースＩＤが特定するリソースへのアクセスが要求された場合、生成されたアクセス認証情報を使用して認証を行うステップと、を含むことを特徴とするコールセンタ運用方法。
12. コールセンタに発呼した端末を特定する端末ＩＤを取得する機能と、
    前記端末との間に確立された呼を使用して取得された情報を使用して、前記端末のユーザの認証を行う機能と、
    ユーザの認証が成功した場合、アクセス認証情報を生成する機能と、
    生成されたアクセス認証情報を、前記端末との間に確立された呼を使用して音声で通知する機能と、
    取得された端末ＩＤに従い、インターネット上のリソースを特定するリソースＩＤを前記端末のユーザに通知する機能と、
    通知されたリソースＩＤが特定するリソースへのアクセスが要求された場合、生成されたアクセス認証情報を使用して認証を行う機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。

Images