(57)【特許請求の範囲】
【請求項１】
仮想環境を実現しコンタクト・センタとのインターフェースを有するコンピュータ・システムを操作する方法において、
（ａ）コンタクト・センタから、前記コンタクト・センタにより維持されている待ち行列システムに関する情報を、受領するステップと、
（ｂ）仮想環境内に、前記待ち行列システムの仮想待ち行列表示を，前記受領した情報に基づいて、提供するステップと、
（ｃ）前記仮想環境の住人に、前記コンタクト・センタの待ち行列システム内の前記住人の為に、コンタクト先が待ち行列にいる時に、前記仮想待ち行列表示へのアクセスを提供するステップと、
（ｄ）前記仮想待ち行列表示内に、前記住人が相互作用し可変の結果を発生するエンティティを提供するステップと、
（ｅ）前記住人が前記エンティティと相互作用すると、前記相互作用の結果を決定するステップと、
（ｆ）前記相互作用の結果を、前記コンタクト・センタの待ち行列に通知するステップと、
を有し、
これにより、前記コンタクト・センタの待ち行列内の前記住人の待ち行列の位置が、前記結果に基づいて、変更される
ことを特徴とする仮想環境を実現しコンタクト・センタとのインターフェースを有するコンピュータ・システムを操作する方法。
【請求項２】
前記住人が相互作用し可変の結果を発生するエンティティは以下の何れかを含む、
（ｉ）前記仮想環境のユーザにより操作される前記仮想環境の住人、
（ｉｉ）前記仮想環境の自動化された住人、
（ｉｉｉ）ネゴシエイトすべき障害物、
（ｉｖ）横切るべき迷宮、
（ｖ）完了すべきジャーニー、
（ｖｉ）解決すべき問題、
（ｖｉｉ）取り組むべきチャレンジ、
（ｖｉｉｉ）プレイすべきゲーム
ことを特徴とする請求項１記載の方法。
【請求項３】
前記コンタクト・センタに於いて、
（ａ）前記待ち行列システムに関する情報を、前記コンピュータシステムに提供するステップと、
（ｂ）前記相互作用の結果の通知を受領するステップと、
（ｃ）前記コンタクト・センタの待ち行列システム内の住人の待ち行列の位置を、前記結果に基づいて修正するステップと
を更に有する
ことを特徴とする請求項１記載の方法。
【請求項４】
仮想環境を実現しコンタクト・センタとのインターフェースを有するコンピュータ・システムにおいて、
前記コンピュータ・システムがプログラムを実行すると、
前記コンピュータ・システムは、
（ａ）コンタクト・センタから、前記コンタクト・センタにより維持されている待ち行列システムに関する情報を、受領し、
（ｂ）仮想環境内に、待ち行列システムの仮想待ち行列表示を，前記受領した情報に基づいて、提供し、
（ｃ）前記仮想環境の住人に、前記コンタクト・センタの待ち行列システム内の前記住人の為に、コンタクト先が待ち行列にいる時に、前記仮想待ち行列表示へのアクセスを提供し、
（ｄ）前記仮想待ち行列表示内に、前記住人が相互作用し可変の結果を発生するエンティティを提供し、
（ｅ）前記住人が前記エンティティと相互作用すると、前記相互作用の結果を決定し、
（ｆ）前記相互作用の結果を、前記コンタクト・センタの待ち行列に通知し、
これにより、前記コンタクト・センタの待ち行列内の前記住人の待ち行列の位置が、前記結果に基づいて、変更される
ことを特徴とする仮想環境を実現しコンタクト・センタとのインターフェースを有するコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンタクト・センターの技術を他の技術と一体化する技術に関し、特に、コンタクト・センターと仮想環境（ゲームあるいは他の世界)と一体化する方法に関する。
【背景技術】
【０００２】
関連する米国特許出願第１１／６０８４７５号明細書は、オンラインのマルチプレーヤゲームとコンタクト・センターとの間を結ぶリンクを提供することを開示する。ゲームがプレーヤにより活性化された後、通信チャネルがゲームからコンタクト・センターのエージェントに開通する機構が提案されている。かくしてプレーヤは、ゲーム内部に留まりながら、ゲーム環境からコンタクト・センターへの通信ができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、コンタクト・センターとオンラインの仮想環境(必ずしもオンラインゲームに限らない)との間の通信を改善することである。
【課題を解決するための手段】
【０００４】
本発明によれば、コンピュータ・システムで実現される仮想環境とのインターフェースを有するコンタクト・センタを操作する方法において、
（ａ）仮想環境から空間情報を受領するステップと、
前記空間情報は、仮想環境の住人の仮想環境内の空間ポジションに関連し、
（ｂ）前記コンタクト・センター内にコンタクト情報を創設し維持するステップと、
前記コンタクト情報は、前記住人に関連し、前記空間情報を有し、
（ｃ）前記コンタクト情報を、前記コンタクト・センターの待ち行列システムに提供するステップと、
（ｄ）前記待ち行列システムが、前記空間情報に基づいて、待ち行列の決定を実行するステップ
を有する。
この方法により、待ち（行列）順番の決定は、コンタクト・センターには通常では利用可能ではない情報、即ち仮想環境の住人（inhabitant）の位置情報に基づいて、行なわれる。このような情報により、待ち行列システム内のコンタクト先のより周到なルーティングが可能となり、仮想環境の住人により代表される顧客と、コンタクト・センターのエージェント間の相互作用をより正確に取り扱うことができるようになる。
【０００５】
前記コンタクト情報は、前記ステップ（ｂ）で、前記ステップ（ａ）で受領した結果として生成される。
かくして、例えば、仮想環境の住人の動きにより、その住人に関連するコンタクト・センター内のコンタクト先が形成される。例えば、店舗のドアから歩いて入ってくるキャラクターは、自動的に待ち行列のコンタクト（以下文脈によっては「コンタクト先」「コンタクト情報」とも称する）を形成するようトリガーし、その結果、コンタクト（先）が待ち行列のトップに達し、エージェントが自由となると、エージェントが仮想環境内でのコンタクトを開始する。
【０００６】
前記コンタクト先は、前記住人の空間位置と所定の条件との間で、一致が見出された時に、創設される。
かくして、住人の動きは、所定の基準に対してモニターされ、住人の位置がこのような基準に達すると、仮想環境からコンタクト・センターが受領したロケーション情報に基づいて、コンタクトの形成が行なわれる。
【０００７】
別の構成として、前記コンタクトは、前記ステップ（ｂ）で、前記コンタクト・センターとのコンタクトを開始した前記住人の制御を有する、前記仮想環境のユーザの結果として、創設される。
これの一例は、次のようなユーザーである。即ち、電話のブースに入り、電話をコンタクト・センターにかけるキャラクターを制御するユーザーであるか、あるいは仮想店のアシスタントと相互作用（会話）を開始するユーザーである。
【０００８】
前記（ｄ）ステップの待ち行列の順番の決定は、前記空間情報と前記待ち行列システムに利用可能な他の情報とに、基づいて行われる。
例えば、ユーザーのプロファイルと、コンタクト・センターの住人の購入披瀝等は、待ち行列の順番の決定に影響を及ぼす。
前記空間情報は、以下を含む。
（ｉ）前記仮想環境内の絶対位置、
（ｉｉ）前記仮想環境のゾーン又は領域の表示、
（ｉｉｉ）前記住人の近傍の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｉｖ）前記住人の視野の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｖ）前記住人の移動パス近傍の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｖｉ）前記仮想環境内に存在する複数のクラスのエンティティの特定、前記複数のクラスは、前記個人のロケーションの近接性又はアクセス可能性。
本発明の方法は、
（ｅ）前記コンタクト先を、前記コンタクト・センターのエージェントに割り当てるステップと、
（ｆ）前記ロケーション情報を、前記住人との相互作用の前或いはその間に、前記コンタクト・センターのエージェントにより採用されたシステムに与えるステップと、
を更に有する。
一実施例において、エージェントは、コンタクト・センターのエージェントのソフトウェアを用いて住人のロケーションが通知される。
【０００９】
より好ましくは、前記エージェントにより採用されるシステムは、アクセスを前記仮想環境に提供するプログラムを含む。
かくして、エージェントは、仮想環境内の住人と相互作用（会話）し、このようなアクセスを求めるエージェントにより使用されるプログラムが、住人のロケーション情報と共に供給される。これを用いて、エージェントを住人の近傍に配置するか、あるいはエージェントに対面的相互作用(a face to face interaction)のために同一のロケーションに容易にナビゲートをする機能を与える。
【００１０】
本発明によれば、仮想環境とのインターフェースを有するコンタクト・センタのコンピュータ・システムで実行される機械で読み取り可能なインストラクションを有するデータキャリアを有するコンピュータ・プログラム製品を提供できる。
更にシステムが上記した方法を動作するようなプログラムを操作するコンタクト・センターのコンピュータシステムを提供できる。
【００１１】
本発明によれば、コンピュータ・システムで実現される仮想環境とのインターフェースを有するコンタクト・センタを操作する方法は、
（ａ）仮想環境から空間情報を受領するステップと、
前記空間情報は、仮想環境の住人の仮想環境内の空間ポジションに関連し、
（ｂ）前記コンタクト・センター内にコンタクト情報を創設し維持するステップと、
前記コンタクト情報は、前記住人に関連し、
（ｃ）前記コンタクト情報を、前記コンタクト・センターの待ち行列システムに提供するステップと、
これにより、前記住人は、前記コンタクト・センターのライブ・エージェントと相互作用する為に、待ち行列に並び、
（ｄ）前記住人と相互作用するために、ライブ・エージェントが利用可能となるまでの待ち時間を予測するステップと、
（ｅ）自動化された相互作用の後、前記住人がライブ・エージェントとの相互作用を必要とする遅延時間を予測する為に、前記空間情報を利用するステップと、
（ｆ）前記予測した遅延時間と予測した待ち時間とを比較するステップと、
（ｇ）前記予測した遅延時間と予測した待ち時間との差を減らす為に、前記住人に、自動化された相互作用を提供するステップとを有する。
【００１２】
この方法は、エージェント（人）の相互作用により行われる自動化された相互作用を提供し、自動化された相互作用を実行する際に、待ち時間を考慮に入れて、自動化された相互作用に関連する住人を制御するユーザーの経験を最適化する。かくしてシステムは、相互作用のペースをスローダウンするか、あるいは相互作用のコンテンツを拡張したり短くしたりする。その結果、ユーザーは、エージェントが相互作用を採ることができるようになるまで、出来るだけ占有されかつ興味を持っている。
住人がエージェント（人）の干渉（手伝い)を必要とするような予測時間遅延は、空間情報のみを、あるいはコンピューター化されたシステムに利用可能な他の情報と共に用いる。システムは、空間情報を採用することなく、時間遅延を予測することができ、これは、ユーザーの履歴やプロファイルに基づいて行なう。
【００１３】
本発明によれば、前記（ｅ）ステップの空間情報は、以下から選択される。
（ｉ）前記仮想環境内の絶対位置、
（ｉｉ）前記仮想環境のゾーン又は領域の表示、
（ｉｉｉ）前記住人の近傍の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｉｖ）前記住人の視野の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｖ）前記住人の移動パス近傍の前記仮想環境の、他のキャラクタ、アーティファクト、オブジェクト、エンティティの何れかの特定、
（ｖｉ）前記仮想環境内に存在する複数のクラスのエンティティの特定、前記複数のクラスは、前記個人のロケーションの近接性又はアクセス可能性。
本発明によれば、本発明の前記（ｇ）ステップは、複数のスクリプトオプションの中から、相互作用の割合を加速させる或いは遅らせるステップ、相互作用の開始を遅延させるステップを含む。
この点に関し本発明は、コンピューター・プログラム製品を提供する。このコンピューター・プログラム製品は、機械で読み取り可能なインストラクションを符号化された状態で有するデータキャリアを有する。このインストラクションは、仮想環境とインターフェースを有するコンタクト・センターのコンピューターシステムで実行されると、コンピューターシステムが上記の方法を実行できるようになる。
【００１４】
更にコンピューターシステムが実行できるようなコンタクト・センターのコンピューターシステムが提供できる。
本発明によれば、仮想環境を実現しコンタクト・センタとのインターフェースを有するコンピュータ・システムを操作する方法は、
（ａ）コンタクト・センタから、前記コンタクト・センタにより維持されている待ち行列システムに関する情報を、受領するステップと、
（ｂ）仮想環境内に、待ち行列システムの仮想待ち行列表示を，前記受領した情報に基づいて、提供するステップと、
（ｃ）前記仮想環境の住人に、前記コンタクト・センタの待ち行列システム内の前記住人の為に、コンタクト先が待ち行列にいる時に、前記仮想待ち行列表示へのアクセスを提供するステップと、
（ｄ）前記仮想待ち行列表示内に、前記住人が相互作用し可変の結果が発生するエンティティを提供するステップと、
（ｅ）前記住人が前記エンティティと相互作用すると、前記相互作用の結果を決定するステップと、
（ｆ）前記相互作用の結果を、前記コンタクト・センタの待ち行列に通知するステップと、
これにより、前記コンタクト・センタの待ち行列内の前記住人の待ち行列の位置が、前記結果に基づいて、変更される
を有する。
【００１５】
従来のコンタクト・センターにおいて、ユーザーは、待ち行列における自分の位置に関して、コールバックを選択するオプション、あるいは待ち行列に参加せずメッセージを残すオプション以外にほとんど制御するオプションを有さない。同様にユーザーは、自分自身の待ち行列の位置に関する最小の情報しか持っておらず、予測される待ち時間を設定する周期的に録音されたメッセージを再生する以外にはほとんど情報を持っていない。
この方法は、これら２つの問題を取り扱う。まず最初にコンタクト・センターの待ち行列システムの仮想環境内における表示を提供し、その結果、ユーザーには待ち行列内の自分の位置（順番）と進捗情報の感覚が与えられる。更にユーザーには、可変の出力を有するエンティティとの相互作用を引き受ける機会が提供されるか、あるいはユーザーの待ち行列の位置が出力に基づいて修正されるような結果が与えられる。この事は、ユーザーは、相互作用ベースに待ち行列の位置に影響を及ぼすことができることを、意味する。
【００１６】
好ましい実施例において、仮想の待ち行列表示は、仮想環境内の住人により取られるジャーニー（旅行)を含む。
待ち行列を、移るべきジャーニー又はパスとして表すことにより、ゴール又はエンドポイントを導入すること、あるいは進捗状況の他の表示（例えば、マイルストーン)を導入することができる。このような表示は、ユーザーに対し、実際の進捗状況をコンタクト・センターの待ち行列内で待つことで経験する無益な留保状態(uninformative on-hold status )に対して、実際の進捗状況を表示することにより、ユーザーに活力を与えることができる。ゴール又はエンドポイントまでの距離あるいは進捗状況の割合をダイナミックに処理し、コンタクト・センターにおいて変化する状況あるいは待ち行列内の進捗状況を考慮に入れることができる。
【００１７】
本発明によれば、前記住人が相互作用し可変の結果が発生するエンティティは、以下の何れかを含む。
（ｉ）前記仮想環境のユーザにより操作される前記仮想環境の住人、
（ｉｉ）前記仮想環境の自動化された住人、
（ｉｉｉ）ネゴシエイトすべき障害物、
（ｉｖ）横切るべき迷宮、
（ｖ）完了すべきジャーニー、
（ｖｉ）解決すべき問題、
（ｖｉｉ）取り組むべきチャレンジ、
（ｖｉｉｉ）プレイすべきゲーム。
本発明によれば、前記住人が相互作用するエンティティは、前記住人に対し順番に現れる。
かくして、ユーザーは、仮想環境内の自分のキャラクターが直面するチャレンジ、障害、戦い、当惑等により占拠される。各相互作用は、更なるチャンスを与えて、待ち行列の時間を減らすこと、あるいは増える待ち行列時間を回避することができる。
本発明によれば、前記住人に対し順番に現れることは、前記住人が前記仮想環境内で、パスに沿って移動するにつれて順番に現れることである。
かくしてパスは、一連の遭遇として物語の筋書きのように移動する。遭遇の数と性質は、予測される待ち時間に合わせて適切に作られるか、システムは、ユーザーが待ち行列のトップに来るまで新たな遭遇を提示し続ける。
本発明によれば、前記住人が相互作用し可変の結果を有するエンティティは、前記仮想待ち行列表示内に現れる他の住人を含む。前記他の住人は、前記コンタクト・センターの待ち行列システム内の待ち行列位置を有する。前記相互作用の結果は、前記相互作用に関与する住人の待ち行列の位置の修正に対し決定的である。
【００１８】
このオプションは、競合的待ち行列の概念を導入する。この概念によれば、ユーザーは、仮想環境内で互いに競い合い、一方あるいは両方の競争者（competitors）に対し、待ち行列の位置の変更で表現されるような利点を求めて競う。この修正は、待ち行列の位置の交換か、あるいは各プレイヤーには相互作用の結果に基づいて待ち行列の位置の増加又は減少が与えられる。複数の住人が、互いに削除しあうような待ち行列も考えることができるが、１つのパーティーあるいは複数のパーティーの待ち行列の位置は、各相互作用により影響される。
本発明によれば、前記コンタクト・センターは、
（ａ）前記待ち行列システムに関する情報を、前記コンピュータシステムに提供するステップと、
（ｂ）前記相互作用の結果の通知を受領するステップと、
（ｃ）前記コンタクト・センターの待ち行列システム内の住人の待ち行列の位置を前記結果に基づいて、修正するステップを更に有する。
選択的事項として、本発明によれば、前記住人の待ち行列の位置は、前記相互作用の結果に関わらず、前記待ち行列内の進捗が最小割合となるよう、修正される。
かくしてユーザーは、自分が相互作用に参加しない場合でも、あるいは相互作用で上手く振る舞うことができなかった場合でも、早晩ゴールに達することができる。
【００１９】
この点に関し本発明は、コンピューター・プログラム製品と上記の方法を実行するコンピュータ・システムを提供する。
本発明によれば、コンピュータ・システムで実現される仮想環境と前記仮想環境とのインターフェースを有するコンタクト・センタを有するシステムの操作方法は、、
（ａ）仮想環境内に、セールスを提供する外部のウエブサイトとのインターフェースを、提供するステップと、
（ｂ）前記仮想環境の住人に、購入決定に際しライブ・エージェントのアシスタンスを要求する機構を、提供するステップと、
（ｃ）前記仮想環境の住人がライブ・エージェントのアシスタンスを要求すると、前記リクエストを前記仮想環境から前記コンタクト・センタに提供するステップと、
（ｄ）前記コンタクト・センタが前記リクエストを前記コンタクト・センタのエージェントに割り当てると、前記エージェントと前記住人を相互に通信状態に置くステップとを有する。
本発明によれば、コンピュータ・システムで実現される仮想環境とのインターフェースを有するコンタクト・センタを操作する方法は、
（ａ）仮想環境から、前記仮想環境の住人により発行された或いは住人のために発行されたリクエストを受領するステップと、
（ｂ）前記リクエストを、前記コンタクト・センターのエージェントとして動くリクエストとして、特定するステップと、
（ｃ）前記住人に、前記コンタクト・センターのエージェントとしての権限を与えるステップと、
（ｄ）前記コンタクト・センターの利用可能なエージェントの登録された記録に、前記住人に関する情報を追加するステップと、
（ｅ）前記エージェントと接触するために、前記仮想環境から、前記仮想環境の住人からのコンタクトリクエストを受領するステップと、
（ｆ）前記コンタクトリクエストを、前記記録されたレコード内で特定されたエージェント内に、割り当てるステップと、
を有する。
本発明によれば、前記（ａ）ステップの前記リクエストは、前記仮想環境内のロケーションにアクセスした第１住人の結果として、受領され、前記ロケーションは、エージェントとして動作しようとする住人の為の、登録ロケーションとして割り当てられる。
本発明によれば、前記（ｃ）ステップは、前記第１住人は、エージェントとして認証された登録されている、或いは前記第１住人が、前記第１住人に提示されたテストに合格したと決定するステップを含む。
本発明によれば、前記（ｄ）ステップは、前記レコード内の前記第１住人のスキルセットを記録し、これにより前記スキルセットの情報が、前記（ｆ）ステップのコンタクトリクエストを割り当てるのに使用される。
この点に関し本発明は、コンピューター・プログラム製品と上記の方法を実行するコンピュータ・システムを提供する。
【図面の簡単な説明】
【００２０】
【図１】ゲーム・サーバーと通信するコンタクト・センターを有するシステムのブロック図。
【図２】仮想環境の住人からコンタクト先を待ち行列に入れる方法のフローチャート。
【図３】仮想環境の住人からのコンタクト・リクエストを自動化する方法のフローチャート。
【図４】予測待ち時間に適合するための自動化された相互作用を形成する方法のフローチャート。
【図５】ゲーム内の仮想待ち行列表示を表す図。
【図６】ゲーム内の競合する待ち行列を実行する方法のフローチャート。
【図７】仮想環境（セールス・ウェブサイト)とコンタクト・センターとを一体化する方法のフローチャート。
【図８】仮想環境からのアドホックを採用する方法のフローチャート。
【発明を実施するための形態】
【００２１】
図１は、コンタクト・センター１０とゲーム・サーバー１２とを一体化するシステムのブロック図である。図１において、接続は、論理的な接続を表し、様々なエンティティを接続するネットワークの詳細は割愛している。様々な接続が、有線ネットワークと無線ネットワークで実現されている。このネットワークには、ＬＡＮ(local area networks)とＷＡＮ(wide area network)とインターネット等を含む。
【００２２】
ゲーマー・コンピューター・システム１４は、ゲーム・サーバー１２に接続されている。即ち、ゲーマー・コンピューター・システム１４のユーザーは、ゲームにログインしており、ゲーム環境内でキャラクター（「アバター(avatar)」、「インディビジュアル(individual)」)を制御する。通常、ゲーム環境は、多くのこのようなキャラクターを同時に提供する。用語、「キャラクター」、「アバター」、「インディビジュアル」は、本明細書においては交換可能に使用する、即ちほぼ同意である。
【００２３】
ゲーム・サーバー１２は、様々なソフトウェアを含み、複雑なゲーム環境とその関連システムを実現する。特に、ゲーム・サーバー１２上で走るソフトウェアは、ＳＩＰユーザー・エージェント１６を実行する。このＳＩＰユーザー・エージェント１６は、ＩＥＴＦ標準のＲＦＣ３２６１により規定されるＳＩＰを用いて、通信セッションに参加するソフトウェア・エンティティ(開始時あるいはリクエストに応答して、ユーザー・エージェント・クライアントとして、あるいはユーザー・エージェント・サーバーとして機能する)である。
【００２４】
ＳＩＰユーザー・エージェント１６は、ゲーム環境内にインターフェースを有し、ゲーム環境と一体化されている。この一体化方法は、ゲーマーのキャラクターがＳＩＰ  ＵＡを活性化して、ＩＮＶＩＴＥメッセージをコンタクト・センターに送ることにより、行なわれる。例えば、プレイヤーのキャラクターは、仮想の電話ブースに入り、その通信を開始する。別の構成として、ゲームのクライアントにより使用されるプログラム・インターフェースは、ゲーマーにより使用できるコマンド又はアイコンを有し、このようなコンタクトを開始する。様々な他の可能性、例えば、プレイヤーのキャラクターが店舗に入り、店舗のアシスタントにアプローチして、ＳＩＰ  ＩＮＶＩＴＥメッセージをコンタクト・センターに送るようトリガーするか、あるいは広告用のディスプレイの前にキャラクターが立って、ＳＩＰ  ＩＮＶＩＴＥをトリガーすることもできる。
【００２５】
ＳＩＰ  ＩＮＶＩＴＥメッセージは、コンタクト・センターに向けられ、コンタクト・センター内でバックトゥバックユーザーエージェント（ＢＢＵＡ）１８により処理される。ＢＢＵＡは、ＩＥＴＦ標準ＲＦＣ３２６１で定義され、ＳＩＰユーザー・エージェント・サーバーとＳＩＰユーザー・エージェント・クライアントの連続（concatination）である。より具体的には、ＢＢＵＡは、ロジカル・エンティティであり、リクエストを受領し、それをユーザー・エージェント・サーバー(ＵＡＳ)として処理する。リクエストに如何に応えるべきかを決定するために、ＢＢＵＡは、ユーザー・エージェント・クライアント(ＵＡＣ)として機能してリクエストを生成する。プロキシ・サーバーとは異なり、それは、ダイアログ（通信）状態を保持して、ダイアログ上で送信された全てのリクエストに参加しなければならない。
【００２６】
ＢＢＵＡのユーザー・エージェント・サーバー・コンポーネントは、ゲーム・サーバーのＳＩＰユーザー・エージェント１６からのメッセージ（例、ＳＩＰ  ＩＮＶＩＴＥ)を処理する。このメッセージに、ＢＢＵＡのコンポーネントは、ゲーマーのＳＩＰユーザー・エージェント１６とのＳＩＰセッションに参加する旨の合意をすることにより、応答する。ＢＢＵＡのユーザー・エージェント・クライアント・コンポーネントは、コンタクト・センターの他のコンポーネントと通信し、サーバーのコンポーネントがどのような応答を送るべきかを決定する。かくしてＢＢＵＡは、ＳＩＰ  ＩＮＶＩＴＥメッセージを受領し、それを受領確認し、ＳＩＰ  ＩＮＶＩＴＥを受け入れ、コンタクト・センターの内部コンポーネントとリソース(資源)とのそれ自身のＳＩＰセッションを開始する。このコンタクト・センターの内部コンポーネントとリソースは、例えば、エージェン端末２０と、メディア・サーバー２２と、コンタクト・センター・サービス２４として公知のセントラル・マネッジメント・ユニットである。
【００２７】
コンタクト・センター・サービス２４は、様々なコンポーネント、例えば、動作管理要素（ＯＡ＆Ｍ）２６と、エージェント・マネージメント要素２８と、待ち行列管理要素３０と、ワークフロー要素３２とを有する。
エージェント・マネージメント要素２８と、待ち行列管理要素３０と、ワークフロー要素３２は、スクリプト３４に従って動作する。スクリプト３４は、コンタクト・センターの管理者により設定されたプログラミング・ルールを実行し、コンタクト・センター１０によりなされたあらゆる種類のコンタクト、例えば、入来コンタクト、発信コンタクトを効率的に処理する。
【００２８】
一般的に、ＳＩＰセッションの形態で入来する電話の呼びは、  バックトゥバックユーザーエージェント１８により、メディア・サーバー２２に通知される。このコンタクトの一般的な進行状況は、ワークフロー要素３２により指定される。このワークフロー要素３２は、入来するボイスコンタクトを音声自動応答(ＩＶＲ：interactive voice response)セッションにルーティングする。これを行なうために、バックトゥバックユーザーエージェント１８は、メディア・サーバー２２との接続を開くよう指示される。
次のメディア・サーバーは、通信スペース又はカンファレンス３６を生成し、ＢＢＵＡは、遠隔地にいるＳＩＰユーザー・エージェント１６とネゴシエートし、カンファレンス３６との通信を、リアルタイム・プロトコル(ＲＴＰ：real time protocol)・ストリーム介して、設定する。このリアルタイム・プロトコル・ストリームは、ゲーマー端末１４とカンファレンス３６の間で、音声及び他のデータを搬送する。
【００２９】
メッセージ又は音声プロンプト(voice prompts)は、アナウンスメント・サーバー３８に記憶される。このアナウンスメント・サーバー３８は、ワークフロー要素３２により制御され、個々に記録された音声プロンプトを、カンファレンス３６内に、ゲーマー・コンピューター・システム１４に通信された場所から、分配される。ゲーマーは、音声応答あるいは他の装置からの入力で応答する。これらの応答は、ワークフロー要素３２に通知される。このワークフロー要素３２は、それに従って動く。即ち他のアナウンスメントを再生することにより、データをこの発呼者に関連するコンタクト・ファイルに追加することにより、待ち行列の決定を行なうことにより、ＢＢＵＡに対し電話の呼びを特定のエージェントに直接転送するよう指示することにより、行なう。
より一般的には、電話の呼びは、これまでのセッションから得られた情報を基に、待ち行列に入れられるが、これはコンタクト・センターが利用できるデータベースからのコンタクトに関し知られた情報と共に入力される。例えば、顧客はＩＶＲセッションの間、アカウント・ナンバーを入力する。この場合、そのアカウントに関連する情報を用いてコンタクトの待ち行列をアシストする。
【００３０】
コンタクト先には、優先権（prioority）とスキルセット(skillsets)が割り当てられる。これらを用いて、コンタクトを待ち行列管理要素３０が管理する待ち行列の１つに配置する。複数のエージェント、例えばエージェント２０が、待ち行列をサービスするのに利用され、エージェントを特定の待ち行列に割り当てることは、エージェント・マネージメント２８により制御される。このエージェント・マネージメント２８は、エージェントと彼らの技術の観点から、コンタクト・センターに利用可能なリソースを、各待ち行列により必要とされるリソースとマッチさせる。
コンタクト先が待ち行列のトップに達すると、特定の呼びを特定のエージェントに割り当てる決定が行なわれ、バックトゥバックユーザーエージェント１８は、２人の当事者をコンタクト先に置く。これは、エージェント２０を、同一のカンファレンス３６にゲーマー・コンピューター・システム１４として、入れ込むことにより、行われる。
これまで記載したプロセスは、ＳＩＰユーザー・エージェント１６をゲーム・サーバー１２で一体化する部分以外は、従来公知のものである。しかし、ゲーム・サーバー１２の関与により新たな可能性が開けてくる。これに関して以下詳述する。
【００３１】
ゲーム・サーバー１２は、仮想環境の一形態である。仮想環境は、必ずしもゲームの形態を取る必要はない。現在人気のある仮想環境は、マルチプレーヤーのオンラインゲームで、例えば、"World of Warcraft"、"EverQuest"、"Final Fantasy"等であり、別の世界では"Second Life"である。後者のものは必ずしもゲームとは言えない。このような仮想環境は、ゲームの形態を取るか否かを問わず、商品やサービスのプロバイダー(仮想と現実)に対し、魅力的なマーケットを提供している。ただしこれらが、特定の興味を持つ個人を集めることを構成する場合であるが。コンタクト・センターは、これらの仮想世界のプレーヤーあるいはユーザー等に係わりある有効なメカニズムを提供する。更に仮想環境は、経済的な要素を含み、例えば、マネーの表示、銀行口座等含む。
仮想環境内の個人（indivisual 或いは、ゲーマー又はユーザーのキャラクター又はアバター)は、空間位置（spatial position)を有するために、この空間位置に関する情報をコンタクト・センターに提供することが可能である。その結果、コンタクト・センターは、コンタクトを待ち行列に入れること及びルーティングすることに対し、このような空間情報を採用することができる。
【００３２】
従って、ゲーム・サーバー１２は、ＳＩＰユーザー・エージェント１６と相互作用して、仮想環境における個人の位置に関する情報を、ＳＩＰ  ＩＮＶＩＴＥメッセージとして、あるいはＳＩＰ  ＩＮＦＯメッセージ通信として、コンタクト・センターのＢＢＵＡに送る。この空間情報は、コンタクト・センターに対し、コンタクト先を如何に処理すべきかに関する有力な手掛かりを与えることができる。
【００３３】
第１の実施例において、コンタクト・センターは、仮想環境内の様々な空間領域を重み付ける優先権を割り当てる。これをベースに、第１のコンタクト先は、第２のコンタクト先よりも高い待ち行列の優先権を有する。即ち、第１のコンタクト先は、高い優先度が割り当てられたエリアにいるプレーヤーからのコンタクト先であり、第２のコンタクト先は、このような領域外にいる個人からのもの、或いは低い優先度にいる個人からのものである。仮想環境全体を２つのゾーンに分けることができる。各ゾーンは、それぞれの優先権の重み付けを有するか、あるいは優先権の重み付けが、特定の領域、例えば、個人ショップのみに割り当てられる。
【００３４】
第２の実施例においては、優先権による重み付けではなく、スキルセットが様々なゾーンに割り当てられる。かくして、仮想世界の主にスペイン語を話す地域にいる個人は、スペイン語を話すスキルセットに自動的に割り当てられ、その結果、コンタクト先は、スペイン語を話すことがスキルセットであるコンタクト・センターのエージェントに、ルーティングされる。
【００３５】
別な構成として、キャラクターが仮想環境のショッピング地域内で、ある仮想ショップから別の仮想ショップに移動すると、そのプレーヤーからのコンタクト先に接続されるスキルセットは、それに応じて変わる。その結果、キャラクターがソフトウェアショップにいる時には、それは、コンタクト・センター内でブラウズされたソフトウェアのタイプに関連するスキルセットを有するコンタクトにより、特定される。同一の個人（グラフィックカード・イシューを取り扱う仮想のライブラリーのセクションにいる）からコンタクト・センターに到着したコンタクト先は、それに付属したグラフィックカードに関連するスキルセットを有する。
【００３６】
図２に本発明のプロセスを示す。この実施例において、ゲーマー（仮想世界での住人を制御する人）は、あるアクション、ジェスチャー、コマンドにより、コンタクト・センターとのコンタクトを開始する（ステップ４０）。これは意図的に始めるか、あるいは自分の行動がコンタクトを開始するとはゲーマーが知らずに始めたものかのいずれでもよい。かくして、例えば、あるショップに迷い込むだけで、ゲーマーには分からないバックグランドで、コンタクトを開始することになる。
【００３７】
ステップ４２において、ゲーマー・サーバー１２と一体に形成されたステップ４６は、ＩＮＶＩＴＥメッセージをコンタクト・センター１０のバックトゥバックユーザーエージェント１８（ＢＢＵＡ）に送る。このバックトゥバックユーザーエージェント（ＢＢＵＡ）１８は、このリクエストの受領確認をし、コンタクト・センター・サービス２４のワークフロー要素３２とスクリプト３４とにより、指定されたアクションを取る。
ステップ４４において、ＳＩＰ  ＵＡは、仮想環境内のゲーマーのアバターのロケーションを、要求する。ゲーム・サーバー１２は、このロケーションをステップ４６で与える。ステップ４７で示すように、ロケーション情報（空間情報とも称する）は、様々な方法で提供される。最も単純な方法は、ｘ−ｙ−ｚの座標軸であるいは他の座標軸系で絶対位置（ロケーション）を供給することである。
【００３８】
ロケーションは、様々な方法で表すことができる。例えば、そのアバターに最も近いキャラクターを特定すること（その結果、別のキャラクターの近接性で定義される）あるいはアバターの特定の範囲内にある全てのキャラクターを特定することにより、行う。別の方法は、仮想環境内の所定のゾーンでロケーションを表現することである。様々なロケーションが、同一のゾーン識別子を共有する。これは広く分布している場合でもそうである。かくして、例えば、全てのミュージック・ショップは、１つのゾーン識別子を有し、全てのソフトウェア・ヘルプデスクは、別のゾーン識別子を有する。
【００３９】
別の例を挙げる。十代の若者が制御する住人が主に居住している環境領域は、第１のゾーン識別子で特定される。他方で、大人が制御する住人が居住する可能性の高いロケーションは、別のゾーン識別子を有する。その為、スケートボード・パーク、コーヒーショップ、瞑想場所、ミュージック・フェスティバル（音楽祭）は、それぞれ別々のゾーン識別子で特定される。これによりコンタクト・センターは、このような領域からのコンタクトをルーティングし、待ち行列に入れることが可能となる。ミュージック・フェスティバルの領域においてさえ様々な段階領域があり、それらは各領域に割り当てられた音楽の周囲によって別のゾーン識別子を有する。このゾーン識別は、ダイナミックであり、時間のと共に変動する。
【００４０】
ロケーション情報をステップ４６でゲーム・エンジンでいかに提供するかの一例は、仮想環境内の個人のロケーションを、様々なオブジェクトの観点から特定することである。例えば、その個人の視点のオブジェクトの観点から、個人が興味を持つオブジェクトの観点から、声の届く範囲内のオブジェクトの観点から、個人が面と向かう方向にあるオブジェクトの観点から、特定することである。かくして、ショップ環境にいる場合には、個人の現在の興味は、その個人が面と向かっている方向から推測される。ただし、様々なディスプレイのスタンドで包囲されている場合であるが。
【００４１】
ロケーション情報の別の例は、あるエンティティに最も近いエンティティを特定することである。例えば、最も近いショップを特定すること、あるいは所定の範囲内即ち所定の移動距離内のこのようなエンティティの識別子を特定することである。このような情報は、コンタクト・センターのエージェントにとって有効なものであり、これにより、ゲーマーのアバターを最も近いショップに向ける際に、エージェントを補助できる。
【００４２】
例えば、ロケーション情報は、移動中の個人のルートを特定すること、広い範囲を移動する個人が遭遇する可能性のあるオブジェクトを特定することである。
ロケーション情報を特定する方法は、多種多様であり、コンタクト・センターの興味、仮想環境の機能、仮想環境を実現する基礎的エンジンとソフトウェアの機能、デザイナーのイマジネーションにより、大きく変わる。個人のロケーションに関連するゲーム環境から得られた情報は、潜在的に使用可能である。
【００４３】
ステップ４８において、ＳＩＰ  ＵＡは、ゲーム・サーバーから受領したこのロケーション情報を、メッセージ内にパッケージできる。例えば、ＳＩＰ  ＩＮＦＯメッセージ、初期のＩＮＶＩＴＥメッセージ内のオプショナル・ヘッダーとしてパッケージ化することができる。これは、バックトゥバックユーザーエージェント１８（ＢＢＵＡ）に送られ、バックトゥバックユーザーエージェント１８（ＢＢＵＡ）は、これをワークフロー要素３２に流す。このワークフロー要素３２は、コンタクト先を待ち行列に入れて、コンタクト先に、双方向音声応答処理、メディア・デリバリー、エージェントの割り当ての処理を、ロケーション情報に基づいて、提供する（ステップ５０）。
【００４４】
ステップ５２におて、ロケーション情報は、コンタクト先が割り当てられた時に、エージェントに送られる。一般的に、エージェントは、ゲーマー・コンピューター・システム１４が使用したものと同様なクライアント・プログラムを操作する。その結果、エージェントは、仮想環境内にキャラクターを有するか、あるいは仮想環境内にビューを有する。しかしこれは可視できない状態である。エージェントのクライアント・プログラムは、コンタクト・センター・エージェントのデスクトップの従来の態様と一体化されるか、あるいはエージェントのデスクトップ・プログラムと並行して走る。ロケーション情報は、エージェントにはっきりと示される。例えば、人が話している相手が、グリッド・ロケーション３１５−１０２−００８にいるか、あるいは、８番ストリートと４番アベニューのコーナーにいるといった情報である。ロケーションは、エージェントにアクセス可能なマップ上に指示されるか、あるいはロケーションは、エージェントが話しているゲーマーのアバターをハイライトすることにより、提供される。例えば、ハロー（halo）あるいは他のインディケータで、示される。
【００４５】
ロケーション情報は、ステップ５２で、エージェントのワークステーションに送られ、エージェントに採用されたゲーム・クライアントにより、直接使用され、エージェントをゲーマーのアバターに隣接する環境内に配置する（ステップ５４）。かくしてエージェントは、既に仮想環境内にいるが、新たなに割り当てられたコンタクト先から離れている場合には、テレポート機能が、エージェントのアバターを、ゲーマーのアバターあるいは最も近いテレポート・ステーション、バス・ストップ、スポーン・ポイント（spawn point）、あるいは他の所定の場所に、移す。
【００４６】
コンタクト先がエージェントに割り当てられると、コンタクト・センターの通常のプロセスが同時に行われる。例えば、エージェントがメディア・サーバー２２上のカンファレンス３６と音声通信に入るか、ゲーム・サーバー上で走るＳＩＰユーザ・エージェント１６に対し同一の会議内にゲーマーを入れるよう指示する。このセッション開始は、セッションの設定時のみに働き、ゲーマー・コンピューター・システム１４とエージェント２０との間の音声、画像、マルチメディアのコンタクト・セッションは、カンファレンス３６との間の直接遣り取りされるデータ・ストリームの手段により、行われる。
【００４７】
図２において、ロケーション情報は、ゲーム・サーバーによりコンタクト・センターのＢＢＵＡに送られる。これは、仮想世界のオペレーターとコンタクト・センターのオペレーター間の共同作業作業の存在が前提である。このような共同作業がない場合でも、コンタクト・センターのオペレーターは、仮想世界から受領したロケーション情報を利用する。これは、仮想世界の各住人に本来的に提供されるロケーション情報を利用して行われる。例えば、コンタクト・センターのエージェントが、ゲームのクライアントを操作すると（ゲームの他のプレーヤーと同様に）、エージェントのゲーム・クライアントは、仮想世界に対するエージェントのアバターのロケーションに関する情報（それは、アバターを仮想世界に置かなければならない為に、この情報は、ある形態で提供しなければならない）と、エージェントのアバターの近傍の仮想世界の他の住人のロケーションに関連する情報（この情報がないと、このような住人は、エージェントのクライアントにより表すことはできない。）を受領する。ゲームのクライアントに利用できる情報は、あらゆるプレーヤーが他のプレーヤーのアバターを追跡できるような追跡機能を含み、このような機能を含む場合には、この情報が使用される。それゆえに、仮想環境のサーバーにより空間情報が提供されることは、ゲームから各プレーヤーに通常提供される付加物である必要はなく、仮想環境のサーバーが、コンタクト・センターに最も有効なフォーマットで空間情報を形成できる場合には、好ましい。
図２は、ゲーマーとコンタクト・センターとの間の相互作用を示し、ＳＩＰ  ＵＡのイニシエーションが、あらゆる方向で行われる。コンタクトのイニシエーションの例を詳述する。
【００４８】
図３は、ゲーム・サーバーあるいは仮想環境・サーバーが、仮想環境の住人とコンタクト・センターとの間のコンタクトを、自動的に開始する方法を表すフローチャートである。
ステップ６０において、個人が仮想環境にログインし、仮想環境内を移動する。連続的にあるいは周期的に、仮想環境内の個人のポジションに対する責任のあるサーバーは、この個人のロケーションとコンタクト・センターで特定された所定の基準とを比較する（ステップ６２）。これらの基準は、図２のステップ４６で説明したような基準である。
【００４９】
チェック、即ち個人のロケーションと基準との間にマッチ（一致）が有るか否かのチェックがなされる（ステップ６４）。マッチ（一致）がない場合には、プロセスはステップ６０に戻り、マッチ（一致）があるまでそのプロセスが繰り返される。マッチ（一致）がステップ６４で見い出されると、ゲーム・サーバーは、一体化されたＳＩＰ  ＵＡに対し、コンタクト・センターのＢＢＵＡへ、コンタクト・リクエストを送るよう指示する（ステップ６６）。この時点で、ユーザーあるいはゲーマーは、仮想世界の住人に対し責任があるが、コンタクト・リクエストが送られたことは、通知されない。
ＳＩＰ  ＵＡは、サーバーにより提供されたロケーション情報を有するこのコンタクト・リクエストをフォローアップし、これもＢＢＵＡに送る（ステップ６８）。
【００５０】
このプロセスの一例は、住人が競合する仮想環境内でのリソースが少ない場合である。例えば、デザイナー又はスタイリストが、サロンに到着した最初の１０人（即ち、仮想環境の住人）が、無料のコスチューム(コスチューム、サロン、人は、その環境内で全て仮想エンティティである)を得られると宣言したとする。このアナウンスをしたデザイナーは、実在の人により制御され、自動化され、複数の事象で提供され、コンタクト・センターの様々なエージェントのような様々な人々により、制御される。
【００５１】
デザイナーの店舗の前の所定の場所に到達した各人に対し、ステップ６２、６４で示すようにロケーションの一致が検討される。これにより各人に対し、コンタクト・リクエストは、その人のロケーションの表示と共に、ＢＢＵＡに送られる。ＢＢＵＡは、このコンタクト・リクエストを、住人をオファーされているサービスの待ち行列に加わるようにする指示として採用する。以下のようなルールが決められる。そのルールによれば、住人は、待ち行列にいるために店舗の近傍にいる必要があるか、あるいはその位置を確立して、住人は呼び出されるまで自由に動き回ることができる。待ち行列は、サロンの前の到達順に従ってデザイナーによりサービスされる。
【００５２】
本発明の方法の他の実施例は、コンタクト・センターが様々な店舗に顧客サービスを提供する場合である。店舗に入って来る各人には、ロケーション・マッチがコンタクト・センターのために保持される基準に対し行なわれる。コンタクト・センターのエージェントが自由になると、このエージェントは、各店舗の待ち行列の先頭の人にアプローチする。これは、店舗の中に到達しブラウジングを開始するためには、仮想世界の住人のために入力を必要としない。彼らに判らないバックグラウンドにおいて、彼らはサービスの待ち行列におり、彼らが行列の先頭に来た時に、エージェントのアバター（ショップの店員を表す)によりアプローチされる。
【００５３】
図４は、別のプロセスを示し、このプロセスは、コンタクト・センターのより良い経験を提供するために、ロケーション情報を利用する。
ステップ７０で、自動化されたアバターは、仮想環境内のコンタクト・センターのために働くが、住人との会話を開始する。これは、目標として特定された住人、あるいはランダムに出会った住人でもある。自動化されたアバターは、スクリプトを提供する。このスクリプトにより、サービスが提供されるものについて、住人の興味にアクセスすることができる。
ステップ７２で、住人が肯定的に応答すると、自動化されたアバターにより、コンタクトがセットアップされ、コンタクト・センター内で待ち行列を作る。これは、ＳＩＰ  ＩＮＶＩＴＥリクエストをコンタクト・センターのＢＢＵＡに生成することにより行なわれるか、あるいは自動化されたアバターが、ワークフローと待ち行列にアクセスするコンタクト・センターのプロセスにより制御される。
【００５４】
このプロセスを開始する別の方法として、住人により、コンタクト・リクエストがコンタクト・センターに送られる。これは、所定のエリアに入ることにより自動的に行なわれる（ステップ７６)。
住人に関連するロケーション情報が、コンタクト・センターに送られる。これは、例えば、ＩＮＦＯメッセージをＢＢＵＡに送ることにより、行なわれる。このＩＮＦＯメッセージは、ゲーム・サーバーから受領したロケーション情報を含む。このロケーション情報は、住人と会話中の自動化されたアバターのロケーションである。このプロセスにおいて、住人のロケーションは、このコンタクトの進捗状況のインディケーターであるとする。例えば、あるロケーションは、エージェントが必要とされる高い可能性に関連し、他のロケーションは低い可能性に関連する。あるロケーションは、それらに関連してエージェントができるだけ早く必要とされる可能性を有する。他のロケーションは、自動化されたアバターと相互作用する消費者の披瀝を、エージェント（人）が必要とされるまで長時間に渡り有する。
【００５５】
従って、ステップ８０において、このロケーション情報に基づいて、ライブ・エージェント（人）の介在に関する要件に関する予測がなされる。この予測は、ロケーション情報に加えて他のファクターに基づいても行なわれる。例えば、住人とコンタクト・センターとの間の過去の通信披瀝、仮想環境内で他の購入をなした住人に過去の通信披瀝、住人に関連するアカウントのプロファイルから抽出された人口学的情報(demographic information)である。ロケーション情報は、決定を行なうための唯一の情報ではない。この決定は、他のファクター、例えば、キャラクターのプロファイル、そのキャラクターのユーザー、購入披瀝等を考慮に入れて、行なわれる。
【００５６】
ロケーション情報に基づいてなされたこの種の予測の例を次に示す。
【００５７】
１．住人は、チケット・デスクへの看板に従う。このチケット・デスクは、有名なアーティストのコンサートチケットを販売している。この様な場合、必要とされるエージェント（人）の助けは極めて低い。その理由は、多くの顧客がチケットを購入するために、日付け、時間、チケット枚数、自動化されたアバターとの経済取引手続きの完了を選択するだけであり、これは、ＡＴＭの自動手続きに類似している。
【００５８】
２．住人は音楽のカタログをブラウザする。これにより自動購入が可能となり、顧客のヘルプデスクにアプローチできる。このデスクにいる顧客の存在は、人のエージェントの手助けが直ぐに必要であることを表している。その理由は、自動化されたカタログは、多くの簡単な質問には答えるができ、カタログにはカバーされていない事項即ちエージェントを必要とする事項に関する明瞭な説明を顧客が必要としているからである。
【００５９】
３．顧客は、コンピュータ・ショップのオンライン表示内でブラウジングし、顧客サービス・アバターにアプローチする。このロケーションにおいて、人のエージェントが関与する必要性は数分であり、即ち顧客はアバターによりオプションを話し合う所定の時間を過ごし、最終的に決定する時点で、エージェント（人）を必要とし購入する。
【００６０】
４．自動化されたアバターは、ツアーガイド・サービスを提供する。仮想環境内におり、このようなツアーガイド・サービスに関連する基本的な質問に答えることはできるが、実際にツアーが始まると、人のエージェントが必要である。このような場合、アバターがスケートボード・パークで住人と話している時には、エージェントの関与の可能性は極めて低い。その理由は、スケートボード・パークの使用者は、過去にツアーガイドに実際に関与する可能性が最も低いとされているからである。逆の同一のツアーガイドで、富裕層が住む地区、休暇旅行先、仮想環境の新たな住人が頻繁に訪れる場所は、このような場所では、短い間、人のエージェントの必要の可能性が極めて高い。
【００６１】
予測がステップ８０で行なわれると、自動化されたアバターは、この予測時間に基づいて住人と相互作用する。従って、自動化されたアバターは、スクリプトに従う。このスクリプトは、あるポイントまで会話をもってくるよう意図したものである。あるポイントとは、人のエージェントの相互作用が、エージェントの手の空いた時と、人のエージェントの関与の予測に適した時間で必要とされるなポイントである。
【００６２】
エージェントの関与が会話が始まってから２分以内に必要とされると予測され、実際には、３分間はこのコンタクト先にサービスと提供するコンタクト・センター内で、手の空いたエージェントが期待できない場合には、自動化されたアバターは、スクリプトに従う。このスクリプトは、相互作用を遅らせる為に、ゆっくりしゃべる人、ピントがずれて話をする人、期待されるセールスあるいはサービスに直接関係しない会話を行なう人を提示する。
【００６３】
別の構成として、問題の住人が来店すると、店舗のアシスタントは、このようなエージェントを必要とするような予測時間に関連するエージェント（人）の利用可能性の遅延に基づいて、顧客へのアプローチを遅らせたり、一時的に消えたりする。人のエージェントが利用可能になると、エージェントは必要に応じて会話に関与したり邪魔をする(ステップ８４)。エージェントが自由となる予測時間に基づいて、相互作用を形成すると、自動化されたシステムは、エージェントを、顧客が行列に並ぶあるいはエージェントを待つようなより適切な時間に、顧客に紹介する。
【００６４】
更なるアプリケーションでは、あるエリアのアバターは、ライブ・エージェント（人）が、例えば３０秒以内に利用可能でない場合には、相互作用を放棄する可能性が大きという統計を示す。このような領域は、自動化されたコンタクト・センターのアバターによりエージェントが３０秒以内に自由になることを予測するまで、回避される。その結果、自動化されたアバターとの相互作用を、自由になるためのエージェントの予測待ち時間と、自動化されたアバターと相互作用する必要があるエージェントに対する予測遅延時間との間の差が最小となるよう、操作する。
【００６５】
仮想世界の住人の空間ロケーションは、必要とされるライブ・エージェントに対する予測遅延時間に影響を及ぼす唯一のファクターではない。住人とコンタクト・センターとの過去の披瀝、あるいは商品あるいはサービスの他のプロバイダーとの他の披瀝も予測遅延時間に影響を及ぼす。これは、住人、住人を制御する人、人に関連するプロファイルの他の要素と同じである。その結果、早急に購買の決定を成す真面目な購入者は、購買決定をするまで長時間掛かる人とは区別される。このような更なる情報を考慮に入れても、ロケーションは、このような決定を成すために使用される更なるそして重要なファクターを提供する。その結果、音楽をダウンロードする真面目な購入者は、仮想環境からコンピューターを購入するよう決定する時の同じ住人よりもより早くエージェントを必要とすることが期待されている。
【００６６】
図５は、競合的なコンタクト・センターの待ち行列のスクリーン上の表示を示し、これは、ゲーマーにより使用されるゲームクライアントにより提示される。このシーンは、ゲーマーのキャラクターの第１の人の視点から見たものであり、顧客がアクセスしようとするショップ９０(このショップは、限られたコンタクト・センターのリソースのスクリーン上の表示である)と、ショップ９０の方向に曲がりくねったパス９２を示す。これはゲーマーのキャラクターが完了しなければならない（乗り越えるべき）ものである。コンタクト・センターの待ち行列の構成要素は、ゲーマーが限られたリソースにアクセスするための予測待ち時間を評価し、この情報をゲーム・サーバーに与える。ゲーム・サーバーは、パス（path）を障害物（obstacles）とチャレンジ（challenges）で追加(投入)し、これらはパスに沿って進むためには乗り越えなければならないものである。
【００６７】
障害物やチャレンジは、図５に示され、これは前進するためには超えなければならない創造物（creatures）９４と登らなければならない壁９６のような風景の特徴と障害物である。これらのチャレンジを打ち勝つための成功又は失敗、又はこの様な挑戦を完了するような時間基準は、コンタクト・センターの待ち行列内のプレイヤーのコンタクト先を昇格させたり降格させたりする為に、使用される。
【００６８】
ゲーム・サーバーにより挿入された障害物とチャレンジ９４、９６に加えて、他のプレイヤーのアバター９８ａ−９８ｆも見える。プレイヤーは、他のプレイヤーの犠牲のもとで、待ち行列内の自分のポジションを増やすが、これは他のアバターと戦うことにより行うことができる。他のアバターとは、例えば、アバター９８ｂとアバター９８ｃ、あるいはアバター９８ｅとアバター９８ｆである。
ゲームのデザイナーは、コンタクト・センターのデザイナーと共に、この待ち行列を調整してどの程度の競争が望ましいかを決める。かくして、風景が調整されて、互いにゴールに向かい抜け出すにつれて、キャラクターが互いに隠れたりする。プレイヤーは、他の見えるキャラクターを「狙い打ち（sniping）」して、彼らの待ち行列の位置を増分させるか、あるいは殺されたプレイヤーの待ち行列内の場所と交換する。
最終的な目的は、プレイヤーにとって目に見えるようにすることではなく、プレイヤーは、単に自分のキャラクターを変化するパスに沿って動かす、あるいは各プレイヤーに関連するコンタクト先が待ち行列のトップに達するまで、風景（例、障害物）を変えることである。この時点において、プレイヤーにはゴールが示され、競合的な環境から外され、静止領域あるいは店舗の環境に移させる。
【００６９】
図６に、競合的待ち行列の動作のフローチャートを示す。フローチャートの左側は、ゲームサーバーで行われるステップを示し、右側は、コンタクト・センターのサーバーで行なわれるステップを示す。
ステップ１００において、キャラクターは競合的待ち行列環境に入る。これは例えば、コマンドを入力することにより、あるいはポータル(portal)を通過することにより行なわれる。これにより図５の風景に入る。競合的待ち行列環境の実際の概観は、図５に示す荒涼とした風景とは明らかに異なるものである。競合的待ち行列環境に入ることにより、キャラクターを表すコンタクト先が、コンタクト・センターの適宜の待ち行列に配置される（ステップ１０２)。コンタクト・センターの待ち行列の構成要素が、待ち行列の位置に基づいて、そのコンタクト先の予測待ち時間を計算する（ステップ１０４)。
【００７０】
キャラクターのプレイヤーに提示される環境は、この予測待ち時間に基づいて、ゲームサーバーにより生成あるいは修正される（ステップ１０６)。かくしてキャラクターは、一連のパズル、チャレンジ、モンスター等の最初の物と出会う。これは、予測待ち時間の少なくとも一部の間、キャラクターを占領すると期待されているものである。ゴールが見えてくると、ゴールまでの距離と、キャラクターとゴールまでの障害物を調整して、ゴールに到達する予測時間が、コンタクト・センターにより計算された待ち時間と等しくなるようにする。
キャラクターが障害物を乗り越える（克服する)と、ステップ１０８において、これはゲームサーバーにより、これはコンタクト・センターの待ち行列構成要素に通知される。ステップ１１４において、待ち行列のコンタクト先位置が、進捗状況に基づいて更新される。別の構成として、障害物の克服は、待ち行列の位置に影響を及ぼさず、単にキャラクターがゴールの方向に進行するのを許すだけである。
【００７１】
図５に示すように、キャラクターは競合的待ち行列環境内で互いに戦う。その進行が図６に示すようなキャラクターが別のキャラクターを打ち負かすと（ステップ１１０)、これを用いて、待ち行列内にある勝者のキャラクターの位置を更新する。最も単純な方法では、キャラクターの優先レベルをこの勝利で増加させ、その結果、待ち行列の位置を新たな優先に基づいて、ステップ１１４で更新する。別の構成として、キャラクターの待ち行列の位置を、負けたキャラクターの待ち行列の位置と交換し、キャラクターは、待ち行列に沿って飛び越えて行くことができる。これは、その環境にある自分より前にある他のキャラクターの連続を負かすことにより行なわれる。
逆に考慮中のキャラクターが、他のキャラクターに負けると（ステップ１１２)、待ち行列にいるキャラクターの位置は、ステップ１１４で悪い方に更新される。これは、割り当てられた低い優先レートにより、或いは勝ったキャラクターの位置と交換することにより、行なわれる。
【００７２】
ステップ１１４の更新した位置の決定に従って、コンタクト先が待ち行列のトップに居るか否かのチェックがなされる（ステップ１１６)。トップに居ない場合には、プロセスは、ステップ１０４と１０６に戻る。即ち待ち行列のトップに達するまでの待ち時間を新たな待ち行列の位置に基づいて更新し、ゲームサーバーに通知し、この新たな待ち時間を反映させるために、プレイヤーの仮想環境を修正する。
ステップ１１６において、コンタクト先が待ち行列のトップに達すると、それがエージェントに割り当てられる（ステップ１１８)。キャラクターが、ゲームのデザインにより競合的待ち行列環境から外されると（ステップ１２０)、通常、ゲームサーバが、コンタクト・センターとかつプレイヤーのコンピューターシステムと協同して、キャラクターのプレイヤーを、キャラクターが成功裏に並んでるリソースと直ちにコンタクトさせる。
【００７３】
このプロセスに対して多くの変形例が考えらえる。例えば、キャラクターが最低速度で待ち行列に沿って移動して、下手なプレイヤーによる幻滅を回避することができる。あるいは、シーリングを、コンタクト先のポジションが、環境との相互作用によりあるいは他のプレイヤーにより悪影響あるいは良い影響の受けるよう、課すこともできる。これにもかかわらず、競争的な待ち行列技術の導入により、コンタクト・センターのオペレーターに対し、新規で魅力的な待ち行列モデルを提供でき、かつゲーム要素を追加することにより、コンタクト・センターのユーザーの待ち行列の魅力の無さを取り除くことができる。
【００７４】
仮想環境は、他のビジネス及びコンタクト・センターと一体化することもできる。図７は、仮想世界とオークションサイトとコンタクト・センターとの一体化を示す。しばしばゲームのプレイヤーと仮想環境のユーザーは、ゲーム外で宣伝されているアイテムを購入しようとする。例えば、彼らのアバターにより使用される仮想の装置のアイテムあるいはアバターその物を購入しようとする。その結果、新たなプレイヤーは、そのスキルを既に開発し、そして有効なアイテムの倉庫にあるキャラクターを購入することができる。オークションサイト、例えばe.Bay.comは、このようなアイテムとアバターを販売できる。以下の議論は、オークションを操作するサイトと単純なセールスを操作するサイト、あるいはオークションとセールスの両方がオファーするe.Bayのようなサイトにも適応できる。
【００７５】
図７を実施するために、仮想環境は、オークション、セールス領域、又は販売サイトを含む。オークション又はセールス領域には、キャラクターが訪問することができ、かつe.Bayあるいは他のオークションで販売されているアイテムにアクセスできる。これらのアイテムは、その仮想環境で使用できるものである。オークションサイトにおいては、この仮想環境に関連性を有する全てのアイテムは、このオークションエリアに現れるか、あるいはオークションサイトにより提供されるプレミアム・サービスである。例えば、販売者は、余分の支出をしてゲーム上で広告できる。同様にこの領域への入口は、無料あるいは有料でも良い。
【００７６】
アイテムをプレイヤーのキャラクターに提示する方法は、仮想上でのことである。ある場合においては、アイテムを仮想環境のコンテキスト中で提示することが重要と見なされる場合もある。その結果、中世のゲーム世界ではプログラミング・インターフェースを用いて、そのゲームで使用される武器に関連するe.Bayからのリストを取り寄せることができ、かつこの様なリストを同様な武器のラック上に表示される武器の仮想表示に変換することができ、その結果、プレーヤーは、それぞれそれらを調査し取り扱うことができる。このテキストのリスト内に含まれるアイテムは、武器に付けられるタグにプリントされる。別のケースとして、ゲーム内のオークションサイトのリストを示すことに問題がない場合には、アイテムは、オークションサイトに実際にリストアップされるよう表示することができる。例えば、各リストをカタログの提示として示すか、あるいは仮想端末をゲーム内で提供して、ユーザーがオークションサイトにアクセスするようにすることもできる。
【００７７】
この様なゲーム内セールス(in-game sales)の問題点は、プレーヤー、特に、未経験のプレーヤーは、リストからアイテムの価値を判断できないことである。その結果、プレーヤーは、様々な属性や魔術機能を持った沢山の刀を見るが、自分のキャラクターにとって最適な刀を区別して、購入することができない、あるいは明らかに不当価格の刀を見つけることもできない。
ステップ１３０において、購入に興味を持つプレーヤーのアバターが、オークションエリアに入る。仮想世界のデザイナーは、それを表示できる。アバターは、調査のためにアイテムを選択し(ステップ１３２)、アバターに、専門家の意見を得るためのオプションを提示する。このオプションを選択する（ステップ１３４)と、リクエストが、コンタクト・センターに送られて、アバターのプレイヤーとコンタクト・センターのエージェントの間で、コンタクトが開始される。コンタクト・センターのエージェントは、アイテムの種類や、購入するために調査するアバターな関する専門的知識を有する（ステップ１３６)。
【００７８】
コンタクト・センターは、コンタクト先を、このリクエストに基づいて適宜の待ち行列にいれる（ステップ１３８）。コンタクト先が待ち行列のトップに到達すると、あるいはエージェントが直ちに利用可能になった時には、コンタクトはエージェントに割り当てられる。
コンタクト先を割り当てる２つのオプションを示す。一つオプションは、コンタクト先を従業員のエージェント（即ちコンタクト・センターのオペレーターにより採用されたエージェント）に割り当てることである（ステップ１４０）。別のオプションでは、コンタクト・センターは、エージェントが特定のスキルセットを有する場合には、ゲームの他のプレーヤーに、一時的な信任を与える。このようなエージェントは、アドホック・ゲーマー・エージェントと称し、コンタクト先は、この様なエージェントに割り当てられる（ステップ１４４）。
【００７９】
いずれの場合にも、エージェントは、コンタクト先を受け入れる（ステップ１４６）。この時点で、プレーヤーとエージェントは接触するようになる。２つのオプションを示す。いずれのオプションも、従業員のエージェントとアドホック・ゲーマー・エージェントに適用可能である。呼びが、プレーヤーとエージェント間に設定される（ステップ１４８）。別の構成として、エージェントのアバターが、購入を考えているアバターとゲーム内で接触する（ステップ１５０）。これはエージェントのアバターを、オークションエリアに持って行くことにより（或いは、プレイヤーのアバターをエージェントのアバターの場所に持っていくことにより）行われる。あるいは他のゲーム内の通信方法を用いて行われる。かくして、エージェントは、購入希望者にエージェント自身の経験の利点を与えることができ、これにより上手な販売ができるようになる。
購入が行われると（ステップ１５０）、その後、支払いのメカニズムが働いて、支払いがエージェント又はエージェントの従業員に割り当てられる（ステップ１５４）。オークションセンターのルールは、エージェントの手数料は、全てのケースで支払うべきであり、購入がなされない場合でも手数料を支払う。この支払いは交渉できる、一定の手数料、あるいは購入価格の一定割合である。
【００８０】
図８は、アドホックのゲーマー・エージェントが、ゲーム（或いは他の仮想環境）と一体化されたコンタクト・センター、あるいは図７で採用されたコンタクト・センターに関与して、購入に際してのアドバイスを提供する方法を示す。
アドホック・エージェントとして行動しようとするゲームのユーザーは、自分のアバターを制御して「エージェント・ビルディング（agent building）」に入る（ステップ１６０）。これは、この様な興味が仮想環境のコンテキスト内でいかに表せるかの一例である。これは、オークション領域あるいはセールス領域への、メインのバイヤー脇のスタッフの入口である。
【００８１】
アバターのこの動作は、SIP UA INVITEメッセージを、ゲームサーバーからコンタクト・センターのＢＢＵＡに開始することになる。ＩＮＶＩＴＥメッセージは、コンタクトを新たなエージェントに関連するリクエストとして認定する（ステップ１６２)。ＢＢＵＡは、このリクエストをＣＣ（コンタクト・センター）ワークフローに送り、そこで処理する。このＣＣワークフローは、新たなエージェントの信頼性と技術をチェックする（ステップ１６４)。このチェックは、必要と見なされる程度に応じて、簡単あるいは詳細なものである。例えば、前に認証したアバターにとっては、既知のエージェントのリストを検索して、アバターがそのリストに居ることを確認するだけである。高価な取引に対するアドバイスを求める新たなエージェントに対しては、アバターの知識とコミュニケーション能力等の検査が行なわれる。そこからエージェントのスキルセットが決定される。例えば、流暢にスペイン語や英語を話すこと、あるいは刀に関する専門知識があること、あるいは衣服のスタイルに関する初心者レベルの知識である等である。これらのスキルセットを用いて、どのコンタクトがそのエージェントが取り扱うかを決定する。
アバターがエージェントとして受け入れられる（ステップ１６６)と、それは、コンタクト・センターのエージェントのリソースに付加される（ステップ１６８)。それはアバターがログインされている限り、あるいはアバターがオークションエリアに居る限りエージェントのリソース内にある。その観点から、コンタクト・センターは、このアバターを、それを利用できる別のエージェントのリソースと見なすことができる。かくしてコンタクトは、エージェントに割り当てられ（ステップ１７０)、これによりエージェントのアバターは、そのコンタクトに関連する購入希望者のアバターと接触する（ステップ１７２)。その取引の終了後に、支払いがなされる（ステップ１７４)。
【００８２】
アドホックのエージェントが利用する別の方法は、オークションあるいはアイテムのセールスのコンテキスト外で、サービスを提供することである。例えば、サービスは仮想環境内で広告されて、経験も知識もあるガイドによる仮想環境のツアーを提供する。あらゆる住人は、このツアーガイド・ポジションに申し込むことができ、資格検査は、双方向のテストあるいは書き込みテスト、インタビューあるいはアプリカントによるデモンストレーション・ツアーを観測することにより、行なわれる。成功が確認されると、住人には、知識が十分示されたロケーションにおけるスキルセットが割り当てられる。
受け入れられると、成功した住人は、アクティブなエージェントのリストに追加される。住人は、ログインされた時は常にアクティブと見なされるか、あるいは自分自身がアクティブになることや仕事ができることを選択した時のみアクティブと見なされる。
【００８３】
新たなプレイヤーがツアーを行なおうと決定すると、この新たなプレイヤーは、ツアー・オフィスに行き、エージェントに尋ねる、あるいはオフィスに行かずにエージェントに尋ねることもできる。このツアーのリクエストは、コンタクトのリクエストとしてコンタクト・センターに送られ、利用可能なエージェントが割り当てられる。利用可能なエージェントが、顧客としての住人に接触し、支払いがツアー会社のビジネスモデルに従って行なわれる。
【００８４】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００８５】
１２  ゲーム・サーバー
１４  ゲーマー・コンピューター・システム
１６  ＳＩＰユーザー・エージェント
２０  エージェント
２２  メディア・サーバー
２４  コンタクト・センター・サービス
２６  動作管理要素
２８  エージェント・マネージメント
３０  待ち行列管理要素
３２  ワークフロー要素
３４  スクリプト
３６  カンファレンス
３８  アナウンスメント・サーバー
図２
４０  ゲーマーがコンタクトを開始する。
４２  SIP UAがINVIEをBBUAに送る。
４４  SIP UAがアバターロケーションを要求する。
４６  ゲームエンジンがロケーションを与える。
４７  XYZ座標軸位置、最短なキャラクター、ゾーン識別子、最短なショップで見えるオブジェクト、形成されたルート。
４８  SIP UAがINFOメッセージでロケーションを送る。
５０  CCワークフローがロケーション情報に基づいてコンタクト先を待ち行列に入れる。
５２  ロケーション情報をコンタクトが割り当てられた時にエージェントに送る。
５４  ゲーマーのアバターに近い環境に、エージェントを配置する。
図３
６０  個人が仮想環境内で動く。
６２  ロケーションとコンタクト・センターで規定された基準とを比較する。
６４  一致したか？
６６  SIP UAがコンタクト・リクエストをBBUAに送る。
６８  SIP UAがロケーション情報をBBUAに送る。
図４
７０  自動化されたアバターが住人との会話を開始する。
７２  住人が肯定的応答をする。
７４  BBUAへのコンタクト・リクエストを生成する。
７６  住人が所定の領域に入る。
７８  ロケーション情報をBBUAに送る。
８０  ロケーション情報に基づいてエージェント（人）の要件を予測する。
８２  予測と待ち時間とマッチさせる為に相互作用のプロセスを処理する。
８４  利用可能あるいは必要な時には、エージェント（人）が介在する。
図６
１００  キャラクターが競合的待ち行列環境に入る。
１０２  コンタクトがコンタクト・センターの待ち行列に入る。
１０４  待ち行列の場所により待ち時間を計算する。
１０６  待ち時間に基づいて環境を生成／修正する。
１０８  キャラクターが障害を克服する。
１１０  キャラクターが別のキャラクターに勝つ。
１１２  キャラクターが別のキャラクターに負ける。
１１４  待ち行列の位置を更新する。
１１６  待ち行列のトップ？
１１８  エージェントに割り当てる。
１２０  競合的待ち行列環境から出る。
図７
１３０  アバターがオークション／セールスアイテムの領域に入る。
１３２  検査用にアイテムを選択する。
１３４  専門家のアドバイスを得るオプションを選択する。
１３６  リクエストをコンタクト・センターに送る。
１３８  製品の知識に基づいてコンタクト先を待ち行列に入れる。
１４０  従業員のエージェントに割り当てる。
１４４  アドホックのゲーマー・エージェントに割り当てる。
１４６  エージェントがコンタクト先を受け入れる。
１４８  呼びがプレイヤーとエージェント間に設定される。
１５０  エージェントのアバターがプレイヤーのエージェントに会う。
１５２  購入が行なわれる。
１５４  エージェントへの支払い。
図８
１６０  アバターがエージェント・ビルディングに入る。
１６２  SIP UA INVITEが新たなエージェントを特定する。
１６４  CCワークフローが信用とスキルをチェックする。
１６６  アバターをエージェントとして受け入れる。
１６８  エージェントのリソースに追加する。
１７０  コンタクトがエージェントに割り当てられる。
１７２  アバターがコンタクトをエージェントとして扱う。
１７４  支払いが行なわれる。
【図１】
0005485159.tif 000002
【図２】
0005485159.tif 000003
【図３】
0005485159.tif 000004
【図４】
0005485159.tif 000005
【図５】
0005485159.tif 000006
【図６】
0005485159.tif 000007
【図７】
0005485159.tif 000008
【図８】
0005485159.tif 000009