特許 7538114 インバウンドインタラクションのルーティングを行う方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-13

(45)【発行日】2024-08-21

(54)【発明の名称】インバウンドインタラクションのルーティングを行う方法

(51)【国際特許分類】

   G06Q 10/0631 20230101AFI20240814BHJP

【ＦＩ】

G06Q10/0631

【請求項の数】 5

(21)【出願番号】P 2021511538

(86)(22)【出願日】2019-09-10

(65)【公表番号】

(43)【公表日】2021-12-27

(86)【国際出願番号】 US2019050486

(87)【国際公開番号】W WO2020055925

(87)【国際公開日】2020-03-19

【審査請求日】2022-07-08

(31)【優先権主張番号】62/729,856

(32)【優先日】2018-09-11

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】523074490

【氏名又は名称】ジェネシス クラウド サービシーズ インコーポレイテッド

(74)【代理人】

【識別番号】110002848

【氏名又は名称】弁理士法人ＮＩＰ＆ＳＢＰＪ国際特許事務所

(72)【発明者】

【氏名】ゴウ、アンディ ラファエル

(72)【発明者】

【氏名】ター、ウェイシュン

(72)【発明者】

【氏名】ドシ、ナマン

(72)【発明者】

【氏名】ハンプリーズ、トラヴィス

(72)【発明者】

【氏名】ウィカクコソ、バユアジ

(72)【発明者】

【氏名】スミス、キャメロン デイビット

【審査官】牧 裕子

(56)【参考文献】

【文献】米国特許出願公開第２０１４／０２１９４３６（ＵＳ，Ａ１）

【文献】特開２０１５－１６７２７９（ＪＰ，Ａ）

【文献】特開２００１－２３６３３７（ＪＰ，Ａ）

【文献】特開２００７－２０６８７７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

プロセッサを含むコンピュータシステムを用いて、コンタクトセンタ環境におけるエンドユーザーデバイスからエージェントデバイスへのインバウンドインタラクションのルーティングを行う方法であって、
前記プロセッサが、
ネットワークに動作可能に結合された統計サーバによって提供されたルーティングパラメータを使用して、前記ネットワークに動作可能に結合されたルーティングサーバーによって、前記インバウンドインタラクションをルーティングするためのエージェントデバイスを選択するステップを実行し、前記ルーティングパラメータは、履歴データから計算され、
前記選択は、
前記ネットワークに動作可能に結合された前記プロセッサによって、前記ネットワークに動作可能に結合されたデータベースから顧客の動線を識別する情報と、前記動線の特定された部分を表す段階と、当該部分において経過した時間を表す経過時間と、前記顧客が開始から終了まで進行する段階を表す動線モーメントと、前記動線のうちの前記顧客がいる段階を表すシーケンスと、を含む前記履歴データを抽出することと、
前記履歴データを前処理することであって、前記前処理されたデータが段階経路を近似する確率ベクトルを構成するように、前記履歴データに基づいて、前記動線における各段階の接続関係をモデル化した隣接グラフを導出し、前記顧客が動線を開始する段階としてのシーケンスゼロを導出し、前記モデル化された各段階における入力と出力の割合を表す破棄率を含む段階履歴を導出することと、
前記前処理された履歴データを用いて段階予測を決定し、予測モデルを構築することと、
前記予測モデルに基づいて、前記プロセッサがエージェントを選択することと、
前記ルーティングサーバーによって、選択された前記エージェントの前記エージェントデバイスへの前記インバウンドインタラクションをルーティングすることと、
前記エンドユーザーデバイスと前記エージェントデバイスの接続を行うことと、を含み、
前記段階予測が、
前記履歴データの繰り返しを実行して複数の段階及び期間を通して、前記確率ベクトルによって決定されたボリュームをフラッシュするアルゴリズムを実行することと、
検証のために履歴データの一部を取っておくことにより、残存部分を得ることと、
前記予測モデルを構築及び訓練するために前記残存部分を使用することと、
前記予測モデルを較正することと、を含み、
前記動線モーメントの所与の段階に対して、周辺のエッジ及びノードをモデル化する処理によって、前記隣接グラフが求められ、
前記動線における前記シーケンスの第１の段階として、前記シーケンスゼロが求められ、
前記経過時間から求められる持続時間閾値よりも長い前記経過時間を有するインタラクションに対して破棄を表すタグ付けを行うことによって、前記シーケンスゼロに対応する各段階について、前記段階に入る総ボリュームに対する前記段階の破棄ボリュームの比率である前記破棄率が決定され、
第ｉ段階から出た総ボリュームに対する、第ｉ段階から第ｊ段階への総ボリュームの比率である前記第ｉ段階から前記第ｊ段階への確率値を求めることによって（ｉ及びｊは段階を特定する異なる整数）、前記確率ベクトルが決定される、
方法。

【請求項2】

前記段階が、前記顧客の動線の焦点と、前記顧客の動線の各段階からの移行とを含む、請求項１に記載の方法。

【請求項3】

前記抽出することが、ユーザアクション、予定されたジョブ、及び別のサービスからの待ち行列要求のうちの１つによってトリガされる、請求項１に記載の方法。

【請求項4】

シーケンスゼロが、シーケンスの進行の連鎖の第１の段階を含む、請求項１に記載の方法。

【請求項5】

段階履歴が、履歴ベクトル計数、破棄率、及び確率ベクトル行列を含む各段階の特性を含む、請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、全体として、電気通信システム及び方法、並びにコンタクトセンタの人員配置に関する。より具体的には、本発明は、コンタクトセンタにおけるインバウンドインタラクションのルーティングに関する。

【0002】

（関連出願の相互参照）
本出願は、２０１８年９月１１日に米国特許商標庁に出願された「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＴＯ ＰＲＥＤＩＣＴ ＷＯＲＫＬＯＡＤ ＤＥＭＡＮＤ ＩＮ Ａ ＣＵＳＴＯＭＥＲ ＪＯＵＲＮＥＹ ＡＰＰＬＩＣＡＴＩＯＮ」と題する米国仮特許出願第６２／７２９，８５６号の利益を主張し、その内容を本明細書に組み込むものとする。

【発明の概要】

【0003】

顧客動線アプリケーションにおける負荷需要を予測するためのシステム及び方法が提示される。動線の分析からの履歴情報を使用して、様々な段階を通じて、行程モーメントを集約することができる。確率分布ベクトルは、複数の段階を接続した様々な経路用に近似することができる。このような確率分布の安定性は、統計的手法によって決定することができる。複数の段階を通じて進行する将来のボリュームの予測は、初期段階で時系列の予測アルゴリズムを適用した後の再帰的アルゴリズムを通じて決定することができる。将来のボリュームが全ての段階で予測されると、将来の負荷を推定して、より良好なキャパシティプランニング及びスケジューリングに活用し、そうした需要に対処することで、コスト関数に沿って性能指標を達成することができる。

【0004】

一実施形態では、コンタクトセンタ環境におけるリソースプランニングのために負荷需要を予測するための方法が提示され、この方法は、データベースから履歴データを抽出することであって、履歴データは、コンタクトセンタリソースが、顧客の動線において段階レベルにサービスを提供する時間を表す複数の段階レベルを含む、抽出することと、履歴データを前処理することであって、前処理が、それぞれの段階レベルについて、隣接グラフを導出すること、シーケンスゼロを導出すること、及び段階履歴を導出することを更に含む、前処理することと、前処理された履歴データを使用して段階予測を決定し、予測モデルを構築することと、構築されたモデルを使用して予測される負荷需要を導出することと、を含む。

【0005】

段階レベルは、顧客の動線の焦点と、顧客の動線の各段階からの移行とを含む。抽出することは、ユーザアクション、予定されたジョブ、及び別のサービスからの待ち行列要求のうちの１つによってトリガされる。隣接グラフは、段階間のグラフ接続をモデル化する。シーケンスゼロは、シーケンスの進行の連鎖の第１の段階を含む。段階履歴は、履歴ベクトル計数、破棄率、及び確率ベクトル行列を含む各段階の特性を含む。

【0006】

段階予測は、履歴データの繰り返しを実行して複数の段階及び期間を通してボリュームをフラッシュするフラッシングアルゴリズムを実行することと、検証のために履歴データの一部を取っておくことにより、残存部分を得ることと、予測モデルを構築及び訓練するために残存部分を使用することと、予測モデルを較正することと、を更に含む。ボリュームをフラッシュすることは、予測開始日から１期間遡って作業し、各繰り返しが各期間を１ずつ増加させて繰り返すことを含む。

【0007】

予測される負荷需要は、予測される破棄を含む、顧客の動線において顧客が段階を通じて進行する際に、あるボリュームのインタラクションから生成される負荷を含む。予測される負荷需要が、コンタクトセンタのＫＰＩ指標目標を送達するために、予測された負荷を処理するために必要なリソースを更に含む。

【0008】

別の実施形態では、コンタクトセンタ環境におけるリソースプランニングのために負荷需要を予測するための方法が提示され、この方法は、データベースから履歴データを抽出することであって、履歴データは、コンタクトセンタリソースが、顧客の動線において段階レベルにサービスを提供するアクションを表す複数の段階レベルを含む、抽出することと、履歴データを前処理することであって、前処理が、それぞれの段階レベルについて、隣接グラフを導出すること、シーケンスゼロを導出すること、及び段階履歴を導出することを更に含む、前処理することと、前処理された履歴データを使用して段階予測を決定し、予測モデルを構築することと、構築されたモデルを使用して予測される負荷需要を導出することと、を含む。

【0009】

別の実施形態では、コンタクトセンタ環境におけるリソースプランニングのために負荷需要を予測するためのシステムが提示され、このシステムは、プロセッサと、プロセッサと通信するメモリと、を備え、メモリは、プロセッサによって実行されると、データベースから履歴データを抽出させることであって、履歴データは、コンタクトセンタリソースが、顧客の動線において段階レベルにサービスを提供する時間を表す複数の段階レベルを含む、抽出することと、履歴データを前処理することであって、前処理が、それぞれの段階レベルについて、隣接グラフを導出すること、シーケンスゼロを導出すること、及び段階履歴を導出することを更に含む、前処理することと、前処理された履歴データを使用して段階予測を決定し、予測モデルを構築することと、構築されたモデルを使用して予測される負荷需要を導出することと、をプロセッサに実行させる命令を格納している。

【0010】

別の実施形態では、コンタクトセンタ環境におけるリソースプランニングのために負荷需要を予測するためのシステムが提示され、このシステムは、プロセッサと、プロセッサと通信するメモリと、を備え、メモリは、プロセッサによって実行されると、データベースから履歴データを抽出させることであって、履歴データは、コンタクトセンタリソースが、顧客の動線において段階レベルにサービスを提供するアクションを表す複数の段階レベルを含む、抽出することと、履歴データを前処理することであって、前処理が、それぞれの段階レベルについて、隣接グラフを導出すること、シーケンスゼロを導出すること、及び段階履歴を導出することを更に含む、前処理することと、前処理された履歴データを使用して段階予測を決定し、予測モデルを構築することと、構築されたモデルを使用して予測される負荷需要を導出することと、をプロセッサに実行させる命令を格納している。

【図面の簡単な説明】

【0011】

【図1】通信インフラストラクチャの一実施形態を示す図である。

【0012】

【図2】労働力管理アーキテクチャの一実施形態を示す図である。

【0013】

【図3】負荷需要予測用モデルを作成するためのプロセスの一実施形態を示すフローチャートである。

【0014】

【図4A】動線の一実施形態の有向グラフ表示である。

【0015】

【図4B】隣接グラフ表示の一実施形態である。

【0016】

【図4C】隣接グラフ表示の一実施形態である。

【0017】

【図5】シーケンスゼロを導出するためのプロセスの一実施形態を示すフローチャートである。

【0018】

【図6】段階履歴を導出するためのプロセスの一実施形態を示すフローチャートである。

【0019】

【図7】需要フラッシングのためのプロセスの一実施形態を示すフローチャートである。

【0020】

【図8A】コンピューティングデバイスの一実施形態を示す図である。

【0021】

【図8B】コンピューティングデバイスの一実施形態を示す図である。

【発明を実施するための形態】

【0022】

本発明の原理の理解を促進する目的で、ここでは図面に示される実施形態を参照し、特定の言語を使用してその説明を行う。上記にかかわらず、これが本発明の範囲の限定を意図したものではないことは理解されよう。記載される実施形態における任意の変更及び更なる修正、並びに本明細書に記載される本発明の原理の任意の更なる用途は、本発明が関連する当業者に通常生じるものとして想到される。

【0023】

コンタクトセンタ環境における顧客インタラクション管理は、当事者間のインタラクション、例えば、顧客とエージェント、顧客とボットとの間のインタラクション、又はその両方の混合を管理することを含む。これは、コンタクトセンタ内の任意の数のチャネルにわたって発生し、スキル及び／又は任意の数のパラメータに基づいて、可能な限り最高のリソース（エージェント又はセルフサービス）を追跡及び標的化することができる。報告は、チャネルのインタラクションについてリアルタイムでも履歴上でも実行できる。同じサービス、ニーズ、又は目的に関連して顧客が行う全てのインタラクションは、顧客の動線として説明され得る。顧客の動線の周囲の分析は、本明細書において、及び当該技術分野において、「動線分析」と呼ばれる場合がある。例えば、ある顧客が企業Ａのオンラインストアを閲覧していて、資格情報を使用してログインして購入を行い、その後、そのオンライン購入アクションから一定期間内にＡ社の顧客サポート回線に電話をかけた場合、その顧客はそのオンライン購入について電話をかけている可能性が高い（例えば、商品が発送されなかった理由の問い合わせ、翌日配達へのアップグレード、注文の取り消しなど）。本実施例では顧客が行った全てのインタラクションは、１つの動線を含む。「動線分析」プラットフォームは、ある期間にわたって所与のエンティティ（例えば、ウェブサイト、事業者、コンタクトセンタ、ＩＶＲ）とのインタラクションを通して、顧客のエンドツーエンド動線を分析するために使用されてもよい。

【0024】

顧客サポート回線を介して行われる大多数の電話が出荷の問い合わせに関するかどうかを前もって判定できれば、Ａ社は、チャネル（例えば、電子メール、ＳＭＳ、コールバックなど）を介して顧客に通知を送信するなど、率先行動を取る機会が得られる。この例では、Ａ社は、注文確認、追跡番号、及び／又は出荷方法のアップグレード可能性を送信し得る。

【0025】

顧客の動線のモーメントを認識して積極的に行動することで、より良好な顧客サービス及び成果を提供することができる。顧客が段階を進むにつれて一連のイベントに対して視覚的及び統計的に報告する必要性もまた、リソースの需要及び負荷の予測を通じてリソースを計画する事業にとって重要である。

【0026】

コンタクトセンタシステム

【0027】

図１は、全体が１００で示される通信インフラストラクチャの一実施形態を示した図である。例えば、図１は、コンタクトセンタサービスを提供するにあたり、コンタクトセンタをサポートするためのシステムを示す。コンタクトセンタは、企業を通じて利用可能な製品及びサービスに関連する販売及びサービスの機能を実行するにあたり、企業にサービスを提供するためのビジネス又は企業への社内施設であってもよい。別の態様では、コンタクトセンタは、サードパーティサービスプロバイダによって運用されてもよい。一実施形態では、コンタクトセンタは、コンタクトセンタシステムのいくつかの構成要素が、コンタクトセンタ構内でホストされ、他の構成要素がリモートホスト（例えば、クラウドベースの環境で）されるハイブリッドシステムとして運用されてもよい。コンタクトセンタは、企業又はサードパーティサービスプロバイダ専用の機器上に配設されてもよく、かつ／又は、例えば、複数の企業向けの複数のコンタクトセンタをサポートするためのインフラストラクチャを備えたプライベート又はパブリッククラウド環境などのリモートコンピューティング環境に配設されてもよい。コンタクトセンタシステムの各種構成要素はまた、様々な地理的位置及びコンピューティング環境にわたって分散されてもよく、必ずしも単一の場所、コンピューティング環境、又は更にはコンピューティングデバイスに含まれていなくてもよい。

【0028】

全体が１００で示される通信インフラストラクチャの構成要素は、複数のエンドユーザデバイス１０５Ａ、１０５Ｂ、１０５Ｃと、通信ネットワーク１１０と、スイッチ／メディアゲートウェイ１１５と、コールコントローラ１２０と、ＩＭＲサーバー１２５と、ルーティングサーバー１３０と、ストレージデバイス１３５と、統計サーバー１４０と、ワークビン１４６Ａ、１４６Ｂ、１４６Ｃを含む複数のエージェントデバイス１４５Ａ、１４５Ｂ、１４５Ｃであって、そのうちの１つが、コンタクトセンタアドミン又はスーパーバイザ１４５Ｄと関連付けられ得るエージェントデバイス１４５Ａ、１４５Ｂ、１４５Ｃと、マルチメディア／ソーシャルメディアサーバー１５０と、ウェブサーバー１５５と、ｉＸｎサーバー１６０と、ＵＣＳ１６５と、レポーティングサーバー１７０と、メディアサービス１７５と、を含む。

【0029】

一実施形態では、コンタクトセンタシステムは、電話又は他の通信機構を介したサービスの提供を可能にするために、リソース（例えば、作業者、コンピュータ、電気通信機器など）を管理する。このようなサービスは、コンタクトセンタの種類に応じて異なり得るものであり、顧客サービスから、ヘルプデスク、緊急応答、テレマーケティング、受注などに及ぶ。

【0030】

コンタクトセンタからサービスを受けることを望む顧客、潜在的顧客、又は他のエンドユーザ（顧客又はエンドユーザと総称される）は、エンドユーザデバイス１０５Ａ、１０５Ｂ、及び１０５Ｃ（１０５と総称される）を介して、コンタクトセンタへのインバウンド通信（例えば、電話コール、電子メール、チャットなど）を開始することができる。エンドユーザデバイス１０５のそれぞれは、当該技術分野において従来の通信デバイス、いくつかの非限定的な例を挙げると、電話、無線電話、スマートフォン、パーソナルコンピュータ、電子タブレット、ラップトップなどであってもよい。エンドユーザデバイス１０５を操作するユーザは、電話コール、電子メール、チャット、テキストメッセージ、ウェブブラウジングセッション、及び他のマルチメディアトランザクションを開始し、管理し、応答することができる。簡略化のために、１００には３つのエンドユーザデバイス１０５が示されているが、任意の数が存在してもよい。

【0031】

エンドユーザデバイス１０５からのインバウンド通信及びエンドユーザデバイス１０５へのアウトバウンド通信は、使用されているデバイスのタイプに応じてネットワーク１１０をトラバースし得る。ネットワーク１１０は、電話、セルラー、及び／又はデータサービスの通信ネットワークを含んでもよく、非限定的な例を挙げると、私設又は公衆交換電話網（ＰＳＴＮ）、ローカルエリアネットワーク（ＬＡＮ）、プライベートワイドエリアネットワーク（ＷＡＮ）、及び／又はインターネットなどの公衆ＷＡＮを含んでもよい。ネットワーク１１０としてはまた、符号分割多元接続（ＣＤＭＡ）ネットワーク、移動通信用のグローバルシステム（ＧＳＭ）ネットワーク、又は３Ｇ、４Ｇ、ＬＴＥなどを含むがこれらに限定されない、当該技術分野において従来の任意の無線ネットワーク／技術を含む、無線キャリアネットワークが挙げられ得る。

【0032】

一実施形態では、コンタクトセンタシステムは、エンドユーザとコンタクトセンタとの間で電話コールを送受信するための、ネットワーク１１０に結合されたスイッチ／メディアゲートウェイ１１５を含む。スイッチ／メディアゲートウェイ１１５としては、センタ内のエージェントレベルルーティングのための中央スイッチとして機能するように構成された電話スイッチ又は通信スイッチが挙げられ得る。スイッチは、ハードウェアスイッチングシステム又はソフトウェアを介して実装されるソフトスイッチであってもよい。例えば、スイッチ１１５としては、自動コールディストリビュータ、構内交換機（ＰＢＸ）、ＩＰベースのソフトウェアスイッチ、及び／又は顧客からインターネットソース型インタラクション及び／又は電話網ソース型インタラクションを受信し、これらのインタラクションを、例えば、エージェント電話又は通信デバイスにルーティングするように構成された専用ハードウェア及びソフトウェアを有する任意の他のスイッチが挙げられ得る。この例では、スイッチ／メディアゲートウェイは、例えば、顧客の電話デバイスとエージェント電話デバイスとの間の接続を確立することによって、呼び出し元の顧客とエージェント電話デバイスとの間の音声経路／接続（図示せず）を確立する。

【0033】

一実施形態では、スイッチは、例えば、スイッチと、コンタクトセンタのルーティング、監視などの通信処理構成要素のうちのスイッチ以外の部分との間のアダプタ又はインターフェースとして機能し得るコールコントローラ１２０に結合される。コールコントローラ１２０は、ＰＳＴＮコール、ＶｏＩＰコールなどを処理するように構成されてもよい。例えば、コールコントローラ１２０は、スイッチ／メディアゲートウェイ及びコンタクトセンタ装置とインターフェースするためのコンピュータテレフォニーインテグレーション（ＣＴＩ）ソフトウェアで構成されてもよい。一実施形態では、コールコントローラ１２０は、ＳＩＰコールを処理するためのセッション開始プロトコル（ＳＩＰ）サーバーを含んでもよい。コールコントローラ１２０はまた、発信者の電話番号（例えば、自動番号識別（ＡＮＩ）番号）、顧客のインターネットプロトコル（ＩＰ）アドレス、又は電子メールアドレスなど、顧客とのインタラクションに関するデータを抽出し、インタラクションを処理するにあたりシステム１００の他の構成要素と通信してもよい。

【0034】

一実施形態では、システム１００は、インタラクション型メディア応答（ＩＭＲ）サーバー１２５を更に含む。ＩＭＲサーバー１２５はまた、自己ヘルプシステム、仮想アシスタントなどと称されてもよい。ＩＭＲサーバー１２５は、ＩＭＲサーバー１２５が音声に制限されず、更に様々なメディアチャネルをカバーし得ることを除いて、双方向型音声応答（ＩＶＲ）サーバーと同様であってもよい。音声を示す実施例では、ＩＭＲサーバー１２５は、顧客のニーズを照会するためのＩＭＲスクリプトで構成されてもよい。例えば、銀行のコンタクトセンタは、顧客が自分の預金残高を取得したい場合は「１を押す」ように、ＩＭＲスクリプトを介して顧客に伝えることができる。ＩＭＲサーバー１２５との継続的なインタラクションを介して、顧客は、エージェントとの会話を必要とせずにサービスを完了させることが可能であり得る。ＩＭＲサーバー１２５はまた、「どのようなご用件でしょうか」などの自由回答式の質問をしてもよく、顧客は、コンタクトセンタに問い合わせる理由を話すか、ないしは別の方法で入力することができる。顧客の応答は、適切なコンタクトセンタリソースにコール又は通信をルーティングするため、ルーティングサーバー１３０によって使用されてもよい。

【0035】

通信がエージェントにルーティングされる場合、コールコントローラ１２０は、ルーティングサーバー（オーケストレーションサーバーとも称される）１３０と相互作用して、インタラクションを処理するための適切なエージェントを見つける。インバウンドインタラクションをルーティングするための適切なエージェントの選択は、例えば、ルーティングサーバー１３０によって用いられるルーティング戦略に基づいてもよく、更に、例えば統計サーバー１４０によって提供されるエージェント可用性、スキル、及び他のルーティングパラメータに関する情報に基づいてもよい。

【0036】

一実施形態では、ルーティングサーバー１３０は、顧客データベースに問い合わせてもよく、顧客データベースは、連絡先情報、サービスレベル契約（ＳＬＡ）要件、以前の顧客連絡先の性質、及び任意の顧客の問題を解決するためにコンタクトセンタによって取られた行動などの、既存のクライアントに関する情報を格納する。データベースは、例えば、Ｃａｓｓａｎｄｒａ又は任意のＮｏＳＱＬデータベースであり得、大容量ストレージデバイス１３５に格納され得る。データベースはまたＳＱＬデータベースであってもよく、いくつかの非限定的な例を挙げると、例えば、Ｏｒａｃｌｅ、ＩＢＭ ＤＢ２、Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバー、Ｍｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓ、ＰｏｓｔｇｒｅＳＱＬなどの任意のデータベース管理システムによって管理されてもよい。ルーティングサーバー１３０は、ＡＮＩ又はＩＭＲサーバー１２５によって収集された任意の他の情報を介して顧客データベースに顧客情報を照会してもよい。

【0037】

適切なエージェントが、通信を処理するために利用可能と識別されると、顧客と識別されたエージェントのエージェントデバイス１４５Ａ、１４５Ｂ、及び／又は１４５Ｃ（１４５と総称される）との間の接続がなされ得る。簡潔にするために図１には３つのエージェントデバイスが示されているが、任意の数のデバイスが存在してもよい。顧客及び／又は顧客の履歴情報に関する収集情報はまた、通信をより良好にサービスする際にエージェントを補助するためにエージェントデバイスに提供されてもよく、それに加えて、負荷に対処するためにスケジューリングスタッフを含むコンタクトセンタアドミン／スーパーバイザデバイス１４５Ｄに提供されてもよい。この点に関して、各デバイス１４５は、定期電話通話、ＶｏＩＰ通話などに適合された電話を含むことができる。デバイス１４５はまた、コンタクトセンタの１つ以上のサーバーと通信し、コンタクトセンタ動作に関連付けられたデータ処理を実行し、音声及び他のマルチメディア通信機構を介して顧客と対話するためのコンピュータを含んでもよい。

【0038】

コンタクトセンタシステム１００はまた、エンドユーザデバイス１０５及び／又はウェブサーバー１５５との音声インタラクション以外のメディアインタラクションに関与するためのマルチメディア／ソーシャルメディアサーバー１５０を含んでもよい。メディアインタラクションは、例えば、電子メール、ボイスメール（電子メールを介したボイスメール）、チャット、ビデオ、テキストメッセージ、ウェブ、ソーシャルメディア、共同ブラウジングなどに関連し得る。マルチメディア／ソーシャルメディアサーバー１５０は、マルチメディアイベントを受信、処理、及び転送するための特殊なハードウェア及びソフトウェアを用いて、当該技術分野において従来の任意のＩＰルータの形態をとることができる。

【0039】

ウェブサーバー１５５としては、例えば、いくつかの非限定的な例を挙げると、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、Ｉｎｓｔａｇｒａｍなど、エンドユーザが加入し得る様々な既知の社会交流サイトのための社会交流サイトホストが挙げられ得る。一実施形態では、ウェブサーバー１５５はコンタクトセンタシステム１００の一部として示されているが、ウェブサーバーはまた、サードパーティによって提供されてもよく、かつ／又はコンタクトセンタ構内の外側に維持されてもよい。ウェブサーバー１５５はまた、コンタクトセンタシステム１００によってサポートされている企業のウェブページを提供してもよい。エンドユーザは、ウェブページをブラウズし、企業の製品及びサービスに関する情報を取得することができる。ウェブページはまた、例えば、ウェブチャット、ボイスコール、電子メール、ウェブリアルタイム通信（ＷｅｂＲＴＣ）などを介してコンタクトセンタに問い合わせるための機構を提供してもよい。ウィジェットは、ウェブサーバー１５５上でホストされるウェブサイト上に展開され得る。

【0040】

一実施形態では、延期可能なインタラクション／活動も、リアルタイムインタラクションに加えて、コンタクトセンタエージェントにルーティングされてもよい。延期可能なインタラクション／活動は、バックオフィス業務、又は電子メール、手紙、訓練への参加、若しくは顧客とのリアルタイム通信を必要としない他の活動に応答するなど、オフラインで実行され得る業務を含んでもよい。インタラクション（ｉＸｎ）サーバー１６０は、活動を処理するのに適切なエージェントを選択するためにルーティングサーバー１３０と相互作用する。エージェントに割り当てられると、活動はエージェントにプッシュされてもよく、又はエージェントによって完了されるタスクとしてエージェントのワークビン１４６Ａ、１４６Ｂ、１４６Ｃ（集合的に１４６）に現れてもよい。エージェントのワークビンは、例えば、リンクされたリスト、アレイなどの、当該技術分野において従来の任意のデータ構造を介して実装され得る。一実施形態では、ワークビン１４６は、例えば、各エージェントデバイス１４５のバッファメモリ内に維持されてもよい。

【0041】

一実施形態では、大容量ストレージデバイス１３５は、エージェントデータ（例えば、エージェントプロファイル、スケジュールなど）、顧客データ（例えば、顧客プロファイル）、インタラクションデータ（例えば、限定するものではないが、インタラクションの理由、処理データ、待ち時間、処理時間などを含む、顧客とのそれぞれのインタラクションの詳細）などに関連する１つ以上のデータベースを格納してもよい。別の実施形態では、データ（例えば、顧客プロファイルデータ）の一部は、大容量ストレージデバイス１３５又は他の場所でホストされる顧客関係管理（ＣＲＭ）データベース内に保持されてもよい。大容量ストレージデバイス１３５は、当該技術分野において従来のように、ハードディスク又はディスクアレイの形態をとってもよい。

【0042】

一実施形態では、コンタクトセンタシステムは、ＣＲＭデータベースに格納された情報を取得したり、情報をＣＲＭデータベースに格納されるように方向付けたりするように構成されたユニバーサルコンタクトサーバー（ＵＣＳ）１６５を含んでもよい。ＵＣＳ１６５はまた、顧客の好みの履歴及びインタラクション履歴を維持することを容易にし、エージェント、顧客通信履歴などからコメントに関するデータを捕捉し、格納するように構成されてもよい。

【0043】

コンタクトセンタシステムはまた、統計サーバー１４０によって集約されたデータからレポートを生成するように構成されたレポーティングサーバー１７０を含んでもよい。このような報告は、例えば、平均待ち時間、緩和速度、エージェント占有率などの、リソースの状態に関する、ほぼリアルタイムのレポート又は履歴レポートを含んでもよい。レポートは、自動的に、又はリクエスタ（例えば、エージェント／管理者、コンタクトセンタアプリケーションなど）からの特定の要求に応じて生成されてもよい。

【0044】

コンタクトセンタシステムはまた、労働力管理（ＷＦＭ）サーバー１８０を含んでもよい。ＷＦＭサーバーは、構成データを自動的に同期させ、ＷＦＭクライアントのメインデータ及びアプリケーションサービスソース及びロケータとして機能する。ＷＦＭサーバー１８０は、コンタクトセンタの動線分析プラットフォームへのアクセスなど、エージェントデバイス１４５のうちのいずれかからアクセス可能なＧＵＩアプリケーション、及び、コンタクトセンタ管理用コンタクトセンタアドミン／スーパーバイザデバイス１４５Ｄをサポートする。ＷＦＭサーバー１８０は、統計サーバー１４０と通信し、設定を目的として構成サーバー（図示せず）と通信してもよい。一実施形態では、ＷＦＭサーバー１８０はまた、データアグリゲータ１８４、ビルダ１８５、ウェブサーバー１５５、及びデーモン１８２と通信してもよい。これは、以下の図２でより詳細に説明される。

【0045】

図１の各種サーバーはそれぞれ、コンピュータプログラム命令を実行し、本明細書に記載される各種機能を実行するための他のシステム構成要素と相互作用する１つ以上のプロセッサを含んでもよい。コンピュータプログラム命令は、例えば、ランダムアクセスメモリ（ＲＡＭ）などの標準メモリデバイスを使用して実装されるメモリに格納される。コンピュータプログラム命令はまた、例えば、ＣＤ－ＲＯＭ、フラッシュドライブなどの他の非一時的なコンピュータ可読媒体に格納され得る。それぞれのサーバーの機能は、特定のサーバーによって提供されるものとして説明されているが、当業者は、各種サーバーの機能が組み合わされるか若しくは単一のサーバーに統合されてもよいこと、又は特定のサーバーの機能が、本発明の実施形態の範囲から逸脱することなく、１つ以上の他のサーバー間に分散されてもよいことを理解すべきである。

【0046】

一実施形態では、用語「インタラクション」及び「通信」は互換的に使用され、概して、限定するものではないが、電話コール（ＰＳＴＮ又はＶｏＩＰコール）、電子メール、Ｖメール、ビデオ、チャット、画面共有、テキストメッセージ、ソーシャルメディアメッセージ、ＷｅｂＲＴＣコールなどを含む、任意の通信チャネルを使用する任意のリアルタイム及び非リアルタイムインタラクションを指す。

【0047】

メディアサービス１７５は、ＩＶＲ又はＩＭＲシステムのプロンプト（例えば、オーディオファイルの再生）、保留音、ボイスメール／単一相手との記録、複数相手との記録（例えば、オーディオ及び／又はビデオコール）、音声認識、デュアルトーンマルチ周波数（ＤＴＭＦ）認識、ファックス、オーディオ及びビデオトランスコーディング、セキュアなリアルタイム転送プロトコル（ＳＲＴＰ）、音声会議、ビデオ会議、コーチング（例えば、コーチが顧客とエージェントとの間のインタラクションを聞くためのサポート、及び顧客がコメントを聞くことなくコーチがエージェントにコメントを提供するためのサポート）、コール分析、及びキーワードのスポッティングなどのコンタクトセンタ機能をサポートするためのオーディオ及び／又はビデオサービスを提供してもよい。

【0048】

一実施形態では、構内ベースのプラットフォーム製品は、エージェントデバイス１４５Ａ～Ｃ上に存在するユーザインターフェース（ＵＩ）を介したシステム１００の構成要素へのアクセス及び制御を提供してもよい。構内ベースのプラットフォーム製品内に、グラフィカルアプリケーションジェネレータプログラムを統合することができ、これにより、ユーザは、構内ベースのプラットフォーム製品内の各種インタラクション処理動作を制御するプログラム（ハンドラ）を作成できる。

【0049】

上述のように、コンタクトセンタは、クラウドベースの環境などで、一部又は全ての構成要素がリモートホストであるハイブリッドシステムとして動作することができる。便宜上、本発明の実施形態の態様は、クラウドベースの環境から構内に収容された構成要素にモジュール式ツールを提供することに関して以下に説明される。

【0050】

図２は、全体として、労働力管理アーキテクチャの実施形態を示す図である。構成要素は、スーパーバイザデバイス１４５Ｄ、エージェントデバイス１４５、ウェブサーバー１５５、ＷＦＭサーバー１８０、デーモン１８１、ＡＰＩ１８２、データアグリゲータ１８３、ビルダ１８４、ストレージデバイス１３５、及び統計サーバー１４０を含み得る。

【0051】

ウェブサーバー１５５は、サープレットコンテナ上でホスティングされ、複数のウェブブラウザベースのユーザインターフェースのためのコンテンツを提供できるサーバーアプリケーションを含む（例えば、１つのＵＩは、エージェント用であってもよく、別のＵＩはスーパーバイザ用であってもよい）。ログイン後に、適切なインターフェースが開く。スーパーバイザＵＩは、スーパーバイザが、カレンダー管理、予測、スケジューリング、リアルタイムエージェントアドヒアランス、コンタクトセンタ性能統計、電子メール通知の設定、及び報告のような機能にアクセスすることを可能にする。エージェントＵＩは、スケジュール情報を（例えば、マネージャから従業員へ）分配することを可能にし、スケジュールの好み、計画タイムオフ、スケジュール案内、トレードなどを入力するなど、プロアクティブスケジュール機能を有するエージェントを提供する。

【0052】

ＷＦＭサーバー１８０は、構成データを自動的に同期させ、ＷＦＭクライアントのメインデータ及びアプリケーションサービスソース及びロケータとして機能する。ＷＦＭサーバー１８０はハブであり、アーキテクチャ内の他の構成要素に接続される。

【0053】

ＷＦＭデーモン１８１は、電子メール通知をエージェント及びスーパーバイザに送信するように構成可能なデーモンである。ＡＰＩ１８２は、統合、オブジェクトに対する変更、及びウェブサーバー１５５とＷＦＭサーバー１８０との間の情報の取得を促進することができる。

【0054】

データアグリゲータ１８３は、統計サーバー１４０から履歴データを収集し、ＷＦＭサーバー１８０を介して、スーパーバイザデバイス１４５Ｄにリアルタイムのエージェントアドヒアランス情報を提供する。データアグリゲータ１８３と統計サーバー１４０の接続を介して、ＷＦＭアーキテクチャとコンタクトセンタ１００との間に単一の相互作用点が提供される。ビルダ１８４は、データアグリゲータ１８３からの情報を使用してスケジュールを構築する。

【0055】

ウェブサーバー１５５は、ウェブブラウザベースのＧＵＩアプリケーションのコンテンツを提供し、スーパーバイザデバイス１４５Ｄのユーザからの要求時にレポートを生成する。ＷＦＭサーバー１８０、デーモン１８１、データアグリゲータ１８３、ビルダ１８４、及びウェブサーバー１５５は、ＧＵＩアプリケーションをサポートする。データベース１３５は、全ての関連する構成、予測、スケジューリング、エージェントのアドヒアランス、性能、及び履歴データを格納する。ＷＦＭアーキテクチャの構成要素は、図２に示されるように、データベースに直接接続してもよく、又はＷＦＭサーバー１８０を通じて間接的に接続してもよい。ＷＦＭアーキテクチャは、単一サイト環境又は多サイト企業全体で動作し得る。

【0056】

図３は、全体が３００で示される負荷需要予測のモデルを作成するためのプロセスの一実施形態を示すフローチャートである。このモデルは、コンタクトセンタ環境１００に対する負荷需要の予測を生成するためにＷＦＭサーバー１８０によって使用されてもよく、また、コンタクトセンタ内のリソースを割り当てるためにスーパーバイザ／アドミンによって使用される出力を生成することができる。

【0057】

動作３０５では、履歴データが抽出される。抽出は、所望のデータを出力するために書き込まれたコードによって実行されてもよい。抽出コードは、労働力管理アプリケーション（図２）内から動作し、ユーザインターフェース内のボタンを介して利用されてもよい。抽出器は、段階情報文書オブジェクト（データベース内のテーブルに類似）をデータベース１３５から抽出する。抽出器によって使用されるフィルタは、上記ユーザによって指定されたものと同じである。データ抽出器は、説明されるように、フロントエンド上のユーザアクションによってトリガされてもよく、又はバックエンドからトリガされてもよい。例えば、抽出器は、スケジュールされたＣＲＯＮジョブによってトリガされるバックエンド上のバッチサービスとして存在してもよく、提供されるデータは、Ａｍａｚｏｎ Ｓ３のようなクラウドオブジェクトストレージなどのエンドポイントで格納されてもよい。別の実施例では、抽出器は、別のサービスからの待ち行列要求によってトリガされるバックエンド上のバッチサービスとして存在してもよい。

【0058】

履歴データは、いくつかの要件を有する。例えば、段階レベルは、需要予測の最終目標がキャパシティプランニングであるため、段階レベルは、エージェントの負荷に最も近いプロキシでなければならない。キャパシティプランニングには、顧客が段階を進むにつれて、インタラクションのボリュームから生成される負荷や、特定のＫＰＩ指標目標（例えば、サービスレベル、ＮＰＳ、破棄）の送達を目的として負荷を処理するために必要なリソース（例えば、常用雇用者換算（ＦＴＥ）エージェント）、が含まれる。一実施形態では、抽出されるべき動線分析データは、時間エージェントに近接する出力段階が実際に段階に供されるフィルタレベルになければならない。これは、プラットフォーム又はイベント型のいずれであってもよく、ユーザインターフェースを介してユーザによって指定することができる。段階レベルは、管理者によって事前定義されてもよく、ユーザカスタマイズ可能である。一実施形態では、段階レベルは、顧客の動線や、動線における各状態からの移行に対する焦点である。これらは、顧客の動線からどの情報が収集されるべきかの目的に依存し得る。また、動線内には複数の経路が存在し得る。事前定義された段階はまた、アクションのグループ分けを含んでもよく、段階内には任意の数のアクションがあってもよい。一実施形態では、抽出された段階レベルは、エージェントの時間に結び付けられなくてもよい。代わりに、抽出された段階レベルは、段階内で取られるアクションに結び付けられてもよい。例えば、顧客が段階を進行するにつれて、アクションは、動線において一段階が完了すると製品サンプルをその顧客に送信することであってもよい。

【0059】

履歴データは、必要なデータ要素を含んでいなくてはならず、これには、動線タイプ名、動線タイプＩＤ、顧客ＩＤ、段階、シーケンス、状態日付、終了日、及び時間経過が含まれる。動線タイプ名は、「ロードリクエスト」など、動線のタイプを説明する文字列データタイプである。動線タイプＩＤは、動線タイプを識別する一意のＩＤを含む文字列データ型である。顧客ＩＤは、顧客を識別する一意のＩＤを含む文字列データ型である。段階は、段階名を含む文字列データ型である。このフィールドは、ユーザによって選択されたラベル付け戦略のフィルタに応じて動的であってもよい。シーケンスは、顧客がいる段階の数を含む整数データ型である。例えば、第１の段階はゼロで開始してもよく、次の段階は１である。

【0060】

段階は、対象となる動線の特定された部分（例えば、フォームでの入力、信用調査、アプリケーション処理、支払いなど）に基づいて、企業にカスタマイズ可能であり、好みに応じて順序が変化し得る番号付けされたシーケンスで生じる顧客動線の一部分であり得る。段階は動線における中間段階であってもよいが、別の動線では同じ段階でも「シーケンスゼロ」であり得る。

【0061】

開始日は、顧客が例えば、１２／２３／１５ ００：００又は０１／１９／１６ １４：２０といった特定の段階から始まる開始日／時間を含む日付データタイプである。終了日は、顧客が例えば、０１／０６／１６ ００：００又は０１／２４／１６ １８：５６といった特定の段階を終了／退出するときの終了日／時間を含む日付データタイプである。時間経過は、終了日と開始日との間の数を含む整数データタイプであってもよい。これは、終了日が常に開始日以上であるため、正数でなければならない。

【0062】

一実施形態では、履歴データ出力は、ＵＴＦ－８を符号化したＣＳＶフォーマット又はＪＳＯＮファイル／ストリームであってもよく、Ｐｙｔｈｏｎ及びＪａｖａクラスに活用できなければならない。

【0063】

履歴データはまた、顧客が特定の段階で動線を破棄するときに、区別可能なタグを含むべきである。制御は動作３１０に渡され、プロセス３００は継続する。

【0064】

動作３１０では、履歴データが前処理される。前処理は、履歴データに対して実行される各種予備計算を含む。前処理工程の出力は、段階予測プロセスアルゴリズムで使用される。前処理は、隣接グラフを導出することと、シーケンスゼロを導出すること（各シーケンスの破棄率を計算し、各シーケンスゼロ段階についてのボリューム予測を生成することを含む）と、段階履歴を導出することと、を含む。

【0065】

第１の前処理工程では、隣接グラフが導出される。動線モーメント間の関係を捕捉するために、プラットフォーム内の段階間接続をモデル化するグラフ表示を使用してもよい。各動線モーメントは、顧客が開始から終了まで進行するシーケンス又は段階である。図４Ａは、全体が４００で示される、動線の一実施形態の有向グラフ表示である。図４Ａでは、全動線の初期段階はｖ０として表され、一方、エンド段階はｖ５として表される。顧客が動線中に通過し得る中間（又は移行）段階は、ｖ１、ｖ２、ｖ３、及びｖ４として表される。一定期間後に、動線を破棄してその段階から出たとみなされる顧客をプールするために、各段階には破棄状態も関連付けられる。段階間の矢印は、分析における接続を表し、隣接グラフでモデル化されてもよい。隣接グラフは、意図した段階に対して周辺のエッジ及びノード（前方隣接及び後方隣接）をモデル化する。各前方隣接ノードは、それに接続された、それ自身の前方隣接ノード及び後方隣接ノードを有する。後方隣接ノードはまた、それ自身の前方隣接ノード及び後方隣接ノードを有する。グラフ内の全接続は、隣接グラフリストを介して、最も左側の隣接段階から開始し、その後方隣接ノードに、更に次の後方隣接ノードといったように繰り返すことによって推定することができる。図４Ｂ及び図４Ｃは、図４Ａに示されている顧客の行為からの隣接グラフの例である。図４Ｂでは、段階ｖ０には前方隣接ノードは存在せず、またこれは空である。ｖ０の後方隣接ノードは、ｖ１及びｖ２である。段階ｖ３を表す図４Ｃでは、ｖ１は前方隣接ノードである。ｖ３の後方隣接ノードは、ｖ４及びｖ５である。単純化のために２個の隣接グラフのみが示されているが、動線４００では他も可能である。顧客の動線４００からの他の例では、段階ｖ１は、前方隣接ノードとしてｖ０を、後方隣接ノードとしてｖ３を有し得る。段階ｖ２は、前方隣接ノードとしてｖ０を、後方隣接ノードとしてｖ４を有し得る。段階ｖ４は、前方隣接ノードとして段階ｖ２及びｖ３を、後方隣接ノードとしてｖ５を有し得る。段階ｖ５は、前方隣接ノードとして段階ｖ３及びｖ４を有し得るが、後方隣接ノードを有さなくてもよい。隣接グラフは、動線の各段階ごとに追加されてもよい。

【0066】

別の前処理工程では、シーケンスゼロが導き出される。シーケンスゼロは、顧客がその動線を開始する段階として説明することができる。これは、シーケンスの進行における第１の段階である。段階は、動線の中間段階であってもよいが、別の動線では同じ段階でもシーケンスゼロであり得る。したがって、シーケンスゼロ段階であることは、中間段階になる可能性を排除しない。図５は、全体が５００で示される、シーケンスゼロを導出するためのプロセスの一実施形態を示すフローチャートである。シーケンスゼロ及びそれらの情報は、以下のように、抽出された履歴データから導出される。

【0067】

所望の期間Ｔの予測長さが設定される（５０２）。これは、予測がどのくらい前に望まれるかを含む。全ての別個の「シーケンス＝０」は、履歴データから識別され、シーケンスゼロリストに保存される。シーケンスゼロリスト内の各段階について、履歴データからの呼び出し／インタラクションのタイムスタンプが取得され、時系列として保存される（５０４）。同時に、履歴データから、シーケンスゼロリスト内の各段階について、その段階で費やされた顧客の平均持続時間は、全てのインタラクションをわたって決定される（５０６）。次に、シーケンスゼロリストの各段階について、その段階で費やされた顧客の持続時間の標準偏差が決定される（５０８）。次いで、シーケンスゼロリスト内の各段階について、「持続時間の破棄閾値」を決定する（５１０）。これは、以下を用いて決定することができる。

【0068】

【数1】

【0069】

式中、ｋは、どのように積極的アルゴリズムが、待機が「長すぎる」インタラクションを（正規のインタラクション用プールから）破棄するものとして分類／タグ付けする必要があるかに応じて、１．０～正の無限大のいずれかの値であり得る。

【0070】

シーケンスゼロリストの各段階について、設定された「持続時間の破棄閾値」よりも長い持続時間を有するインタラクション（複数可）はタグ付けされる（５１２）。タグ付けされたこれらのインタラクションは、「破棄」として計数される。次に、破棄されたものとしてタグ付けされたインタラクションの総数が、シーケンスゼロリスト内の各段階について計数される（５１４）。

【0071】

次に、シーケンスゼロリスト内の各段階について、破棄率を決定する（５１６）。これは、以下のように表され得る。

【0072】

【数2】

【0073】

以下を使用して、シーケンスゼロリスト内の全ての段階について正味総ボリューム履歴を決定する（５１８）。

【0074】

段階ｉの正味総ボリューム履歴＝段階ｉの総ボリューム履歴^＊（１－段階ｉの破棄率）

【0075】

最後に、需要予測エンジンは、正味総ボリュームを履歴として使用して実行されてもよい（予測モデルのトレーニングデータ）（５２０）。シーケンスゼロリストの各段階について、シーケンスゼロのボリューム時系列予測結果が得られる。計算結果は、シーケンスゼロとして格納される（５２２）。エンジンは、予測される履歴時系列データ（例えば、インタラクションボリューム）を取り込み、データに対して特徴量エンジニアリングを実行する。特徴量エンジニアリングは、データ要約及び集約、データのクリーンアップ（データ障害の欠落、先頭及び末尾のゼロ合わせなど）、外れ値検出、パターン検出、並びに、クロス検証によって予測誤差を最小化することが見出されたパターンを考慮して使用すべき最良の方法を選択すること、を含む。

【0076】

より高精度、すなわち、週単位、日単位、時間単位、及び５分／１５分／３０分単位の粒度を得るために、複数の時間寸法の階層を予測することができる。より低粒度の予測（例えば、週単位）をベースラインとして使用し、低粒度から高粒度にデータを接続する予測分配を活用して日単位、時間単位及び更に高粒度に分配するといった分配を経由して、より高粒度の予測を行う。ＡＲＩＭＡ又はＨｏｌｔ－Ｗｉｎｔｅｒ’ｓなどの一般的に使用されている統計的予測方法論の多数は、カスタム、独自のものと共に考慮することができる。複数分割での交差検証を使用して最良の方法が選択される。使用される基準は、精度及び全体的な水平精度の組み合わせである顧客スコアリングに基づくことができる。

【0077】

別の前処理工程では、段階履歴は、抽出された履歴データから導出される。各段階は、履歴ベクトル計数、破棄率、及び確率ベクトル行列から構成される、それ自体の段階履歴特性を有する。全ての段階は、各段階ごとに、「入力」及び／又は「終了」履歴ボリュームを有し、これは、ボリューム計数の行列又はベクトル表現に要約することができる。各段階はまた、その段階に入るが後続の隣接段階には進行しないそのボリューム履歴の割合を有してもよい。これは、その段階での破棄に対して計数される。図６は、全体が６００で示される、段階履歴を導出するための一実施形態を示すフローチャートである。

【0078】

別個の段階が識別される（６０２）。段階ごとに日単位のボリューム時系列が追加される（６０４）。各段階の平均持続時間を決定する（６０６）。各段階について全てのインタラクション持続時間の標準偏差が決定される（６０８）。各段階について持続時間の破棄閾値が決定される（６１０）。設定された「持続時間の破棄閾値」を超える持続時間を有するインタラクション（単数又は複数）は、タグ付けされる（６１２）。各段階について全ての破棄を決定する（６１４）。次いで、それぞれの段階について、破棄率を計算する（６１６）。これは、以下を使用して行うことができる。

【0079】

【数3】

【0080】

段階から段階までの全ての組み合わせの日単位のボリューム時系列が入力される（６１８）。段階を出入りするこれらのボリュームは、時間を通じて（例えば、日単位）生じ得るため、これらは時系列データとして表すことができる。は、以下を使用して確率ベクトルを決定する（６２０）。

【0081】

【数4】

【0082】

ベクトル及び破棄率は、動線の各段階の段階履歴として格納される。ベクトルは、以前に決定された隣接グラフの結果を使用して、全動線内の始点－終点の段階のあらゆる組み合わせに確率ベクトル行列を追加するために使用される。制御は動作３１５に渡され、プロセス３００は継続する。

【0083】

動作３１５では、フラッシングアルゴリズムが実行される。動作３１０を実行しないと、動作３１５は実行できない。図４Ａを参照すると、例示的な動線は、段階ｖ０、ｖ１、ｖ３、及びｖ５を含んでもよい。確率ベクトルは、例えば、このような動線から導出することができる。

【0084】

ベクトルＡは、段階ｖ０から段階ｖ１への表現であり得る。ベクトルＢは、段階ｖ１から段階ｖ３への表現であり得る。ベクトルＣは、段階ｖ３から段階ｖ５への表現であり得る。段階ｖ０から段階ｖ１へのインタラクションは、それらの１００％が段階ｖ１に移動する前に１日待っていてもよい。段階ｖ１からは、インタラクションは、１日で段階ｖ３に移動しない。その代わりに、インタラクションの１００％は、２日目に段階ｖ３に移動する。段階ｖ３から、インタラクションは、１日で段階ｖ５に移動しない。インタラクションの５０％は、段階ｖ３から段階ｖ５に２日目に移動してもよく、５０％は３日目に移動してもよい。図７は、全体が７００で示される需要フラッシングのためのプロセスの一実施形態を示すフローチャート図である。最初に予測長さを決定する（７０２）。この例では、９日間の予測が生成される。次いで、予測開始日を設定し（７０４）、この実施例では、０日目から８日目まで開始する。繰り返しｉ＝０を設定する（７０６）。フラッシングアルゴリズムの繰り返しは、以下のように例示することができる。

【0085】

繰り返し＃０：シーケンスゼロアルゴリズムの間に、全ての前処理された段階が予測エンジンから実行され、段階ｖ０に対する予測ボリュームを得る（７０８）。一実施形態では、全てのシーケンスゼロ段階に関して、ボリューム予測及びボリューム予測の正味の破棄は、シーケンスゼロから取得される。段階ｖ０、ｖ１、ｖ３、及び段階ｖ５のそれぞれに関する履歴データ５日分を使用して、段階の予測を取得する（７１０）。段階予測は、シーケンスゼロからの値で設定される。

【0086】

繰り返しの全てが予測長さにわたって実行されたかどうかが判定される。この例では、繰り返しの全てが予測長さにわたって実行されていないと、繰り返しが１増分され（７１４）、次の未処理段階を現在の処理段階に設定する（７１８）ことで、全段階で処理される（７３２）。前の繰り返しからの段階予測が得られ、繰り返しの段階予測にクローン化され（７２０ａ）、次いで、繰り返しの全ての段階について、ボリューム予測の正味の破棄が決定される（７２２ａ）。段階履歴の履歴ベクトル（前処理アルゴリズムから）を同時に取得し（７２０ｂ）、全ての段階履歴が、取得された履歴ベクトルを介してループ化される（７２２ｂ）。段階履歴から確率ベクトルが取得される（７２４）。次いで、ボリューム予測の正味の破棄の各時系列点をループスルーし、時系列タイムスタンプと予測開始日との間の差として経過時間が決定される（７２６ａ）。経過時間が確率ベクトル時間指数と一致し、終点が現在の段階と一致する場合、ボリューム値に確率値を乗算することによってボリュームをフラッシュする（７２８ａ）。同時に、履歴ベクトルを使用した経過時間も決定され（７２６ｂ）、経過時間を決定するためにボリュームがフラッシュされ（７２８ｂ）、履歴ベクトルの各時系列点がループ化され、経過時間が、時系列タイムスタンプと予測開始日との間の差として決定される。その値について特定の期間まで待機し、全てではない場合でも一部のボリュームがフラッシュに適格であれば（確率ベクトル分布によって決定される）、フラッシュされる。現在の繰り返しのためのフラッシュされた値は、段階予測行列に格納される（７３０）。段階の全てが処理され（７３２）、予測長さの繰り返しの全てが実行された場合（７１２）、最終段階予測行列が得られる（７３４）。最終段階予測行列は、予測日から開始した全予測期間にわたって、全ての段階についての最終的なボリュームの状態を含むべきである。上記の例を継続し、以下では、動線４００を関連する繰り返しの処理について説明する。

【0087】

繰り返し＃１：インタラクションは、０日目に段階ｖ０に到達する。

【0088】

繰り返し＃２：段階ｖ０・０日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・１日目に流れ込む。シーケンスゼロ段階としての段階ｖ０の予測値が入力される。

【0089】

繰り返し＃３：段階ｖ０・１日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・２日目に流れ込む。シーケンスゼロ段階としての２日目の段階ｖ０の予測値が入力される。

【0090】

繰り返し＃４：段階ｖ０・２日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・３日目に流れ込む。シーケンスゼロ段階としての３日目の段階ｖ０の予測値が入力される。１日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。

【0091】

繰り返し＃５：段階ｖ０の３日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・４日目に流れ込む。シーケンスゼロ段階としての段階ｖ０・４日目の予測値が入力される。２日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。

【0092】

繰り返し＃６：段階ｖ０・４日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・５日目に流れ込む。シーケンスゼロ段階としての段階ｖ０・５日目の予測値が入力される。３日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。３日目に段階ｖ３にあって２日経過したインタラクションは、この時点で、確率ベクトルＣにより、５０％が段階ｖ５に流れ込む資格がある。

【0093】

繰り返し＃７：段階ｖ０・５日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・６日目に流れ込む。シーケンスゼロ段階としての段階ｖ０・６日目の予測値が入力される。４日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。４日目に段階ｖ３にあって２日経過したインタラクションは、この時点で、確率ベクトルＣにより、５０％が段階ｖ５に流れ込む資格がある。更に、３日目に段階ｖ３にあって３日経過したインタラクションの５０％のうち、その５０％は、この時点で、確率ベクトルＣにより、ｖ５にも流れ込む資格がある。

【0094】

繰り返し＃８：段階ｖ０・６日目からのインタラクションは、１００％の割合で段階ｖ１・７日目に流れ込む。シーケンスゼロ段階としての段階ｖ０・７日目の予測値が入力される。５日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。５日目に段階ｖ３にあって２日経過したインタラクションは、この時点で、確率ベクトルＣにより、５０％が段階ｖ５に流れ込む資格がある。更に、４日目に段階ｖ３にあって３日経過したインタラクションの５０％のうち、その５０％は、この時点で、確率ベクトルＣによりｖ５にも流れ込む資格がある。

【0095】

繰り返し＃９：段階ｖ０・７日目からのインタラクションは、確率ベクトルＡに従って、１００％の割合で段階ｖ１・８日目に流れ込む。シーケンスゼロ段階としての段階ｖ０・７日目の予測値が入力される。６日目に段階ｖ１にあって２日経過したインタラクションは、この時点で、確率ベクトルＢにより、段階ｖ３に完全に流れ込む資格がある。６日目に段階ｖ３にあって２日経過したインタラクションは、この時点で、確率ベクトルＣにより、５０％が段階ｖ５に流れ込む資格がある。更に、５日目に段階ｖ３にあって３日経過した５０％のインタラクションの５０％のうち、その５０％は、ここで、確率ベクトルＣにより、ｖ５にも流れ込む資格がある。

【0096】

簡潔にするために、０から９の繰り返しで示された上記の例では、複数の段階及び期間を通してボリュームをフラッシングするという考え方を伝えるために、０日目より前の過去の履歴データ（予測開始日前）を無視した。０日目よりも前の履歴データを用いる場合、各繰り返しは、履歴データ系列からのボリュームを考慮し、それらのボリュームに対して同じ「ボリュームフラッシング」プロセスを実行しなければならない。予測開始データからマイナス方向に１期間、２期間、３期間といったように遡って開始することになる。同じ確率ベクトルが適用される。

【0097】

制御は動作３２０に渡され、プロセス３００は継続する。

【0098】

動作３２０では、モデルが検証される。検証用に、履歴データの一部を取っておく。例えば、１０％を取っておいてもよい。履歴データの他の９０％は、モデルを訓練／構築するために使用される。次いで、このモデルを使用して予測生成を行い、取っておいたデータと比較する。平均予測誤差を決定し、ＫＰＩとして使用することができる。予測は、予測された値から実際の値を減算して判定され得る。これは、各データポイントについて行われる。平均予測誤差を得るために、平均を全てのデータポイントにわたって取得する。取っておいた履歴データが異なる期間又は範囲からであり、訓練データが異なる期間からのサブセットからのものである、交差検証が実行される。平均予測誤差もまた、交差検証シナリオのそれぞれについて決定される。誤差の標準偏差も提示され得る。制御は動作３２５に渡され、プロセス３００は継続する。

【0099】

動作３２５では、モデルは較正され、プロセスは終了する。検証工程が完了すると、予測モデルの再較正を実行して、予測誤差を最小化する。これは、当該技術分野において既知の任意の標準的な手順を使用して行うことができる。

【0100】

一実施形態では、モデルは、顧客が段階を進行する際にインタラクションのボリュームから生成された負荷を含み、顧客の動線の中に予測される破棄を含む。モデルを使用して作成される予測には、コンタクトセンタのＫＰＩ指標目標（例えば、サービスレベル、ＮＰＳ、破棄）を送達するために、負荷を処理するために必要なリソース（例えば、常用雇用者換算エージェント）が挙げられる。モデルは、コンタクトセンタの、動線分析プラットフォームに適用されてもよい。

【0101】

コンピュータシステム

【0102】

一実施形態では、説明される図の各種サーバー、制御部、スイッチ、ゲートウェイ、エンジン、及び／又はモジュール（サーバーと総称される）のそれぞれは、当業者に理解されるように、ハードウェア又はファームウェア（例えば、ＡＳＩＣ）を介して実装される。各種サーバーのそれぞれは、１つ以上のプロセッサ上で実行され、１つ以上のコンピューティングデバイス（例えば、図８Ａ、図８Ｂ）においてコンピュータプログラム命令を実行し、本明細書に記載される様々な機能を実行するための他のシステム構成要素と相互作用するプロセス又はスレッドであってもよい。コンピュータプログラム命令は、例えばＲＡＭなどの標準メモリデバイスを使用してコンピューティングデバイスに実装され得るメモリに格納される。コンピュータプログラム命令はまた、例えば、ＣＤ－ＲＯＭ、フラッシュドライブなどの他の非一時的コンピュータ可読媒体に格納されてもよい。当業者は、コンピューティングデバイスが、ファームウェア（例えば、特定用途向け集積回路）、ハードウェア、又はソフトウェア、ファームウェア、及びハードウェアの組み合わせを介して実装され得ることを認識するべきである。当業者はまた、各種コンピューティングデバイスの機能が組み合わされるか若しくは単一のコンピューティングデバイスに統合されてもよいこと、又は特定のコンピューティングデバイスの機能が、本発明の例示的な実施形態の範囲から逸脱することなく、１つ以上の他のコンピューティングデバイス間に分散されてもよいことを認識すべきである。サーバーは、ソフトウェアモジュールであってもよく、これも単にモジュールとも称され得る。コンタクトセンタ内のモジュールのセットは、サーバー及び他のモジュールを含んでもよい。

【0103】

各種サーバーは、コンタクトセンタのエージェントと同じ物理的場所にあるオンサイトのコンピューティングデバイス上に配置されてもよく、又は地理的に異なる場所、例えば、インターネットなどのネットワークを介してコンタクトセンタに接続されたリモートデータセンタ内でオフサイトに配置されてもよい。更に、サーバーのいくつかは、コンタクトセンタにあるオンサイトのコンピューティングデバイス内に配置されてもよく、一方、他のサーバーは、オフサイトのコンピューティングデバイス内に配置されてもよく、又は冗長な機能を提供するサーバーは、より優れたフォールトトレランスを提供するためにオンサイト及びオフサイトのコンピューティングデバイスの両方を介して提供されてもよい。一部の実施形態では、オフサイトのコンピューティングデバイスに配置されたサーバーによって提供される機能は、かかるサーバーがオンサイトにあるかのように仮想プライベートネットワーク（ＶＰＮ）を介してアクセス及び提供されてもよく、又は機能は、例えば、拡張可能なマークアップ言語（ＸＭＬ）又はＪＳＯＮでの符号化を使用してデータを交換することなどによって、様々なプロトコルを使用してインターネット上に機能を提供するためのサービスとしてのソフトウェア（ＳａａＳ）を使用して提供されてもよい。

【0104】

図８Ａ及び図８Ｂは、全体が８００で示される、本発明の実施形態で用いられ得るようなコンピューティングデバイスの一実施形態を示す図である。それぞれのコンピューティングデバイス８００は、ＣＰＵ８０５及びメインメモリユニット８１０を含む。図８Ａに示すように、コンピューティングデバイス８００はまた、ストレージデバイス８１５、リムーバブルメディアインターフェース８２０、ネットワークインターフェース８２５、入出力（Ｉ／Ｏ）コントローラ８３０、１つ以上の表示デバイス８３５Ａ、キーボード８３５Ｂ、及びポインティングデバイス８３５Ｃ（例えば、マウス）を含んでもよい。ストレージデバイス８１５としては、限定するものではないが、オペレーティングシステム及びソフトウェアのためのストレージが挙げられ得る。図８Ｂに示すように、それぞれのコンピューティングデバイス８００はまた、メモリポート８４０、ブリッジ８４５、１つ以上の追加の入出力デバイス８３５Ｄ、８３５Ｅ、及びＣＰＵ８０５と通信するキャッシュメモリ８５０などの追加の任意の要素を含んでもよい。入出力デバイス８３５Ａ、８３５Ｂ、８３５Ｃ、８３５Ｄ、及び８３５Ｅは、本明細書では、８３５と総称される場合がある。

【0105】

ＣＰＵ８０５は、メインメモリユニット８１０からの命令に応答し、それを処理する任意の論理回路である。例えば、マイクロプロセッサ、マイクロコントローラ、若しくはグラフィックス処理ユニットの形態の集積回路に、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは特定用途向け集積回路（ＡＳＩＣ）に実装されてもよい。メインメモリユニット８１０は、データを格納し、任意のストレージ位置が中央処理ユニット８０５によって直接アクセスされることを可能にする１つ以上のメモリチップであってもよい。図８Ａに示すように、中央処理ユニット８０５は、システムバス８５５を介してメインメモリ８１０と通信する。図８Ｂに示すように、中央処理ユニット８０５はまた、メモリポート８４０を介してメインメモリ８１０と直接通信してもよい。

【0106】

一実施形態では、ＣＰＵ８０５は、複数のプロセッサを含んでもよく、命令の同時実行又は１つ以上のデータ上での単一の命令の同時実行のための機能を提供してもよい。一実施形態では、コンピューティングデバイス８００は、１つ以上のコアを有する並列プロセッサを含んでもよい。一実施形態では、コンピューティングデバイス８００は、単一のグローバルアドレス空間として全ての利用可能なメモリにアクセスする、複数のプロセッサ及び／又は複数のプロセッサコアを有する共有メモリ並列デバイスを備える。別の実施形態では、コンピューティングデバイス８００は、それぞれローカルメモリのみにアクセスする複数のプロセッサを有する分散メモリ並列デバイスである。コンピューティングデバイス８００は、共有されているいくつかのメモリと、特定のプロセッサ又はプロセッサのサブセットによってのみアクセスされ得るいくつかのメモリとの両方を有してもよい。ＣＰＵ８０５は、２つ以上の独立したプロセッサを単一のパッケージに、例えば、単一の集積回路（ＩＣ）に組み合わせるマルチコアマイクロプロセッサを含んでもよい。例えば、コンピューティングデバイス８００は、少なくとも１つのＣＰＵ８０５及び少なくとも１つのグラフィックス処理ユニットを含んでもよい。

【0107】

一実施形態では、ＣＰＵ８０５は、単一命令多重データ処理（ＳＩＭＤ）機能、例えば、複数のデータ上での単一の命令の同時実行のための機能を提供する。別の実施形態では、ＣＰＵ８０５内のいくつかのプロセッサは、複数のデータ上での複数の命令の同時実行のための機能（ＭＩＭＤ）を提供してもよい。ＣＰＵ８０５はまた、単一のデバイス内でＳＩＭＤ及びＭＩＭＤコアの任意の組み合わせを使用してもよい。

【0108】

図８Ｂは、ＣＰＵ８０５が、バックサイドバスと呼ばれることもある二次バスを介してキャッシュメモリ８５０と直接通信する実施形態を示す。他の実施形態では、ＣＰＵ８０５は、システムバス８５５を用いてキャッシュメモリ８５０と通信する。キャッシュメモリ８５０は典型的には、メインメモリ８１０よりも速い応答時間を有する。図８Ａに示すように、ＣＰＵ８０５は、ローカルシステムバス８５５を介して様々なＩ／Ｏデバイス８３５と通信する。限定するものではないが、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス（ＶＬＢ）、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、拡張業界標準アーキテクチャ（Extended Industry Standard Architecture：ＥＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス、ＰＣＩ拡張（PCI Extended：ＰＣＩ－Ｘ）バス、ＰＣＩ－Ｅｘｐｒｅｓｓバス、又はＮｕＢｕｓを含む様々なバスが、ローカルシステムバス８５５として使用され得る。Ｉ／Ｏデバイスが表示デバイス８３５Ａである実施形態の場合、ＣＰＵ８０５は、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を介して表示デバイス８３５Ａと通信することができる。図８Ｂは、ＣＰＵ８０５がＩ／Ｏデバイス８３５Ｅと直接通信するコンピュータ８００の一実施形態を示す。図８Ｂはまた、ローカルバス及び直接通信が混合される一実施形態を示す。ＣＰＵ８０５は、Ｉ／Ｏデバイス８３５Ｅと直接通信している間にローカルシステムバス８５５を使用してＩ／Ｏデバイス８３５Ｄと通信する。

【0109】

多種多様なＩ／Ｏデバイス８３５が、コンピューティングデバイス８００内に存在してもよい。入力デバイスは、いくつかの非限定的な例を挙げると、１つ以上のキーボード８３５Ｂ、マウス、トラックパッド、トラックボール、マイクロフォン、及び製図台が挙げられる。出力デバイスとしては、ビデオ表示デバイス８３５Ａ、スピーカ、及びプリンタが挙げられる。図８Ａに示されるＩ／Ｏコントローラ８３０は、例えば、キーボード８３５Ｂ及びポインティングデバイス８３５Ｃ（例えば、マウス又は光学ペン）などの１つ以上のＩ／Ｏデバイスを制御してもよい。

【0110】

再び図８Ａを参照すると、コンピューティングデバイス８００は、フロッピーディスクドライブ、ＣＤ－ＲＯＭドライブ、ＤＶＤ－ＲＯＭドライブ、各種フォーマットのテープドライブ、ＵＳＢポート、セキュアデジタル若しくはＣＯＭＰＡＣＴ ＦＬＡＳＨ（商標）メモリカードポート、又は読み出し専用メディアからデータを読み取るため、若しくは読み書きメディアからデータを読み取るため、若しくは読み書きメディアにデータを書き込むために好適な任意の他のデバイスなど、１つ以上のリムーバブルメディアインターフェース８２０をサポートしてもよい。Ｉ／Ｏデバイス８３５は、システムバス８５５とリムーバブルメディアインターフェース８２０との間のブリッジであってもよい。

【0111】

リムーバブルメディアインターフェース８２０は、例えば、ソフトウェア及びプログラムをインストールするために使用されてもよい。コンピューティングデバイス８００は、オペレーティングシステム及び他の関連するソフトウェアを格納するための、及びアプリケーションソフトウェアプログラムを格納するための、１つ以上のハードディスクドライブ又はハードディスクドライブアレイなどのストレージデバイス８１５を更に含んでもよい。任意選択的に、リムーバブルメディアインターフェース８２０はまた、ストレージデバイスとして使用されてもよい。例えば、オペレーティングシステム及びソフトウェアは、ブータブルメディア、例えばブータブルＣＤから実行されてもよい。

【0112】

一実施形態では、コンピューティングデバイス８００は、それぞれが同じ又は異なるタイプ及び／又は形態であり得る複数の表示デバイス８３５Ａを含んでもよく、又はそれらに接続されてもよい。したがって、Ｉ／Ｏデバイス８３５及び／又はＩ／Ｏコントローラ８３０のいずれかは、コンピューティングデバイス８００による複数の表示デバイス８３５Ａへの接続及びその使用をサポートするか、有効にするか、又は提供するために、任意のタイプ及び／又は形態の好適なハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせを含んでもよい。例えば、コンピューティングデバイス８００は、表示デバイス８３５Ａをインターフェース、通信、接続、ないしは別の方法で使用するための、任意のタイプ及び／又は形態のビデオアダプタ、ビデオカード、ドライバ、及び／又はライブラリを含んでもよい。一実施形態では、ビデオアダプタは、複数の表示デバイス８３５Ａにインターフェースするための複数のコネクタを含んでもよい。別の実施形態では、コンピューティングデバイス８００は、複数のビデオアダプタを含んでもよく、それぞれのビデオアダプタは、表示デバイス８３５Ａのうちの１つ以上に接続される。他の実施形態では、表示デバイス８３５Ａのうちの１つ以上は、例えば、ネットワークを介してコンピューティングデバイス８００に接続された１つ以上の他のコンピューティングデバイスによって提供されてもよい。これらの実施形態は、コンピューティングデバイス８００のための第２の表示デバイス８３５Ａとして別のコンピューティングデバイスの表示デバイスを使用するように設計及び構築された任意のタイプのソフトウェアを含んでもよい。当業者であれば、コンピューティングデバイス８００が複数の表示デバイス８３５Ａを有するように構成され得る様々な方法及び実施形態を認識及び理解するであろう。

【0113】

全体が図８Ａ及び図８Ｂに示されるコンピューティングデバイスの実施形態は、オペレーティングシステムの制御下で動作してもよく、タスクのスケジューリング及びシステムリソースへのアクセスを制御する。コンピューティングデバイス８００は、任意のオペレーティングシステム、任意の組み込みオペレーティングシステム、任意のリアルタイムオペレーティングシステム、任意のオープンソースオペレーティングシステム、任意のプロプライエタリオペレーティングシステム、モバイルコンピューティングデバイスのための任意のオペレーティングシステム、又はコンピューティングデバイス上で実行可能であり、本明細書に記載される動作を実行する任意の他のオペレーティングシステムを実行していてもよい。

【0114】

コンピューティングデバイス８００は、任意のワークステーション、デスクトップコンピュータ、ラップトップ若しくはノートブックコンピュータ、サーバーマシン、ハンドル付きコンピュータ、携帯電話若しくは他のポータブル電気通信デバイス、メディア再生デバイス、ゲームシステム、モバイルコンピューティングデバイス、又は通信可能であり、本明細書に記載される動作を実行するために十分なプロセッサ電力及びメモリ容量を有する、任意の他のタイプ及び／若しくは形態のコンピューティング、電気通信、若しくはメディアデバイスであってもよい。一部の実施形態では、コンピューティングデバイス８００は、デバイスと一致する異なるプロセッサ、オペレーティングシステム、及び入力デバイスを有してもよい。

【0115】

他の実施形態では、コンピューティングデバイス８００はモバイルデバイスである。例としては、Ｊａｖａ対応移動電話若しくはパーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、デジタルオーディオプレーヤ、又はポータブルメディアプレーヤが挙げられ得る。一実施形態では、コンピューティングデバイス８００としては、デジタルオーディオプレーヤ又はポータブルメディアプレーヤと組み合わされた携帯電話など、デバイスの組み合わせが挙げられる。

【0116】

コンピューティングデバイス８００は、ネットワークによって接続された複数のマシンのうちの１つであってもよく、又はそのように接続された複数のマシンを含んでもよい。ネットワーク環境としては、１つ以上のネットワークを介して１つ以上のリモートマシン（概してサーバーマシン又はリモートマシンとも称され得る）と通信する１つ以上のローカルマシン、クライアントノード、クライアントマシン、クライアントコンピュータ、クライアントデバイス、エンドポイント、又はエンドポイントノードが挙げられ得る。一実施形態では、ローカルマシンは、サーバーマシンによって提供されるリソースへのアクセスを求めるクライアントノード、及び他のクライアントのためのホスト型リソースへのアクセスを提供するサーバーマシンの両方として機能する能力を有する。ネットワークは、ＬＡＮ又はＷＡＮリンク、ブロードバンド接続、無線接続、又は上記のいずれか若しくは全ての組み合わせであってもよい。接続は、様々な通信プロトコルを使用して確立され得る。一実施形態では、コンピューティングデバイス８００は、セキュアソケットレイヤ（ＳＳＬ）又はトランスポート層セキュリティ（ＴＬＳ）など、任意のタイプ及び／又は形態のゲートウェイ又はトンネリングプロトコルを介して、他のコンピューティングデバイス８００と通信する。ネットワークインターフェースとしては、コンピューティングデバイスを通信可能な任意のタイプのネットワークにインターフェースし、本明細書に記載される動作を実行するのに好適な、ネットワークインターフェースカードなどの内蔵ネットワークアダプタが挙げられ得る。Ｉ／Ｏデバイスは、システムバスと外部通信バスとの間のブリッジであってもよい。

【0117】

一実施形態では、ネットワーク環境は、ネットワークの様々な構成要素が仮想化される仮想ネットワーク環境であってもよい。例えば、各種マシンは、物理マシン上で実行されるソフトウェアベースのコンピュータとして実装された仮想マシンであってもよい。仮想マシンは、同じオペレーティングシステムを共有してもよい。他の実施形態では、異なるオペレーティングシステムがそれぞれの仮想マシンインスタンス上で実行されてもよい。一実施形態では、複数の仮想マシンが同じホスト物理マシン上で実行され、それぞれがそれ自体の専用ボックスを有するかのように機能する「ハイパーバイザ」タイプの仮想化が実装される。仮想マシンはまた、異なるホスト物理マシン上で実行されてもよい。

【0118】

例えば、ネットワーク（例えば、ソフトウェア定義ネットワーク（Software Defined Networking：ＳＤＮ）を介して）など、他のタイプの仮想化も想到される。セッション境界コントローラの機能及び他のタイプの機能などの機能もまた、例えば、ネットワーク機能仮想化（Network Functions Virtualization：ＮＦＶ）などを介して仮想化されてもよい。

【0119】

一実施形態では、大きな１組の事前接続されたオーディオ記録内のキャリアオーディオメッセージを自動的に発見するためのＬＳＨの使用は、コンタクトセンタ環境のためのメディアサービスのサポートプロセスに適用されてもよい。例えば、これは、コンタクトセンタのためのコール分析プロセスを支援し、新しいキャリアオーディオメッセージを発見するために大きな組の音声記録を人間が聴く必要性を除去することを支援することができる。

【0120】

本発明は、図面及び前述の説明において詳細に例示及び記載されてきたが、これは限定的な特性ではなく、例示的なものと見なされるべきであり、好ましい実施形態のみが示され、記載されていること、並びに本明細書及び／又は以下の特許請求の範囲によって記載されるように本発明の趣旨に含まれる全ての等価物、変更、及び修正は保護されることが望ましいことが理解される。

【0121】

したがって、本発明の適切な範囲は、かかる全ての修正、並びに図面に例示され、本明細書に記載されるものに等しい全ての関係を包含するように、添付の特許請求の範囲の最も広い解釈によってのみ決定されるべきである。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図5】

【図6】

【図7】

【図8A】

【図8B】