JP2022534737A - 動的応答目標を備えるマルチチャネル通信プラットフォーム - Google Patents

Abstract

マルチチャネル通信プラットフォームが、メッセージングエンジンと、ルーティングエンジンと、キューマネージャとを含む。メッセージングエンジンは、メッセージングエンジンと通信する複数の異なるメッセージングサービスのいずれかを通じてユーザから複数のテキストメッセージを受信するように作動する。複数のテキストメッセージは、メッセージスレッドを形成し、返事を要求する少なくとも１つのクエリを含む。ルーティングエンジンは、複数のテキストメッセージの運動量を決定して、エージェントと関連付けられるメッセージキューにメッセージスレッドを割り当てるように作動する。キューマネージャは、少なくとも１つのクエリに返事を提供する応答時間目標を特定するように作動し、応答時間目標は、前記決定する運動量に反比例する。

Description

（関連出願の参照）
本出願は、２０１９年５月３１日に出願された米国仮特許出願第６２／８５５，９１７号からの優先権の利益を主張し、その全文を参照により援用する。

（技術分野）
本開示は、通信及びワークフローを管理するためのマルチチャネル通信プラットフォームに関する。

モバイルインターネット技術の台頭を受けて、個人と企業とが通信する方法は急速に変化している。個人が一般に任意の所与の時点で１つの会話のみを維持することができる音声通信とは異なり、新しい形態の通信（例えば、ＳＭＳ、ＭＭＳ、ＩＰベースのクライアントメッセージング）は、ユーザが複数の異なる当事者と同時に会話することを可能にする。より多くの同時会話を処理することができることに加えて、これらの新しい通信手段は、各々、ユーザの緊急性に基づいて変化し得る許容可能な応答時間を有することがある。例えば、緊急の問合せを持つアクティブなユーザは、即時のほぼリアルタイムの応答を要求することがある。逆に、ＳＭＳ経由で送られた簡単な質問を持つユーザは、質問の後に自分のデバイスを下に置いて、数時間に亘ってそれを再度チェックしないことがある。１件の研究では、８分間の連続した時間ブロックに亘る平均８分間のハンドル時間を含む標準的なウェブチャットでは、ＳＭＳチャットは、１．５時間の散発的な接触に亘って広がったが、類似の平均８分間のハンドル時間を含んだ。

エージェントが複数のメッセージングプラットフォームに亘って会話するように求められるならば、許容可能な応答時間の目標を管理するという課題は、特に問題となり、各メッセージングプラットフォームは、応答を受け取ることにおいて何が許容可能な遅延を構成するかの異なる期待を持っている。より長い応答時間が許容されるならば、人員配置要件が削減されることがあり、それは企業にとってコスト削減を提供する。よって、新しい形態の通信への移行は、ライブの電話会話では利用できない顧客サービスの応答ワークロードのバランスを取る機会を提供する。

本開示は、とりわけ、消費者と企業との間に動的な顧客サービス体験を提供することができるロボット的な最適化されたクライアンティング通信プラットフォーム（ＲＯＯＣｏ：Robotic Optimized Clienteling Communications platform）を提供する。ロボット的性質は、機械学習および自然言語理解を利用して、消費者に優れたレベルのサービスを提供しながら、ライブエージェント能力／応答性を強化することができる。このシステムは、クライアンティングを大規模に許容して、壊れにくい長期的な関係を生み出す一方で、リアルタイムの消費者需要に枢動することができるクロスプラットフォーム通信も可能にすることがある。広い意味で、本システムの目標は、会話を簡単にする一方で、関係の豊富なオムニチャネル通信及び支援を大規模に提供することである。

本開示のいくつかの実施形態において、マルチチャネル通信プラットフォームは、メッセージングエンジンと、ルーティングエンジンと、キューマネージャとを含む。メッセージングエンジンは、メッセージングエンジンと通信する複数の異なるメッセージングサービスのいずれかを通じてユーザから複数のテキストメッセージを受信するように作動してよい。複数のテキストメッセージは、メッセージスレッドを形成し、返事を要求する少なくとも１つのクエリを含む。ルーティングエンジンは、複数のテキストメッセージの運動量を決定するように作動してよい。最後に、キューマネージャは、エージェントと関連付けられるメッセージキューにメッセージスレッドを割り当ててよい。メッセージキューは、少なくとも１つのクエリに返事を提供する応答時間目標を特定し、応答時間目標は、決定する運動量に反比例する。

本開示のさらなる拡張は、ライブエージェントがユーザに顧客サービスを提供すること及び／又はユーザのクエリに回答することを支援するシステムを提供する。そのようなシステムは、ユーザのクエリに対処するために提案された応答言語をライブエージェントに提供する自然言語処理容量(能力)を有する自動化エージェントを含んでよい。幾つかの実施形態において、自動化エージェントは、ユーザに関する情報でライブエージェントのユーザインターフェース上のサポートウィンドウを一杯にしてよい。そのような情報は、限定されるものではないが、ユーザの製品嗜好、ユーザのサイズ、ユーザの最近の閲覧履歴の表示、ユーザの製品関心の要約、ユーザの消費パターンの要約、ユーザとの以前のメッセージスレッドの要約、ユーザタグ付き製品の要約、またはユーザの購入履歴の要約を含んでよい。

さらに、自動化エージェントは、製品が販売のために提供されるインターネットウェブページへの１つ以上のハイパーリンクサポートウィンドウ上を生成して表示してよい。そのようなリンクは、ユーザとライブエージェントとの間のメッセージスレッドのコンテキストから導かれてよい。１つの実施形態において、インターネットウェブページは、小売業者に属してよいが、第三者からの在庫が売業者のウェブページを通して購入されることを可能にしてよい。

ユーザに顧客サービス及び／又はサポートを提供するために使用されることがあるマルチチャネル通信システムの概略図である。

図１に示すようなマルチチャネル通信システムにおける１つ以上の会話スレッドを管理するための概略的なフロー図である。

会話運動量分布の関数として設定された応答時間目標の概略的なグラフである。

自動化エージェントを介してユーザに最初に応答するための概略的なフロー図である。

会話の運動量を決定するための概略的なフロー図である。

顧客サービスエージェントによって管理されることがあるメッセージスレッドのキューを示す概略的な表である。

複数のメッセージングスレッドを管理する目的のために並びにユーザに迅速な応答を提供するために顧客サービスエージェントに提示されることがある概略的なディスプレイスクリーンである。

複数の顧客サポートエージェントをユーザとの単一の会話に統合するプロセスを示す概略的なフロー図である。

小売業者又は複数の第三者小売業者のうちの１つから製品販売を行うための電子商取引リンクを生成するシステムを示す概略的なフロー図である。

ユーザ集団からの問い合わせを受け付けるための、ライブの顧客サービスエージェントの弾力的プールを作成するためのシステムを示す概略的なフロー図である。

以下の議論及び添付の図面は、ユーザに顧客サービス及び／又はサポートを提供するために使用されることがあるマルチチャネル通信システム（例えば、図１のシステム１０）を開示している。多くの実施形態において、ユーザは、エンドユーザ及び／又は既存のもしくは見込み顧客であってよい。しかしながら、他の実施形態において、ユーザは、小売販売員であることがあり、システムは、特定の製品情報、スタイル助言、及び／又はカスタム製品注文に関する質問に応答することがある。

一般的な用語の問題として、本開示が「ユーザ(user)」に言及するとき、これはサポート(支援)を求める人を指すことが意図されている。小売のコンテキスト(脈絡)において、ユーザは、一般的に、既存の又は見込み顧客である。更に、情報提供者及び／又は問い合わせ(inquiry)に応じる人を「エージェント(agent)」又は「スペシャリスト(specialist)」と呼ぶ。

幾つかの実施形態において、このシステムは、ユーザの会話速度及び／又はユーザのメッセージの認識された緊急性に基づいて、エージェントのための適切な応答時間目標を決定するように構成されることがある。そうする際に、本システムは、応答時間目標がメッセージングモダリティのみに基づく従来のシステムとは異なる（例えば、エージェントは、５つの同時ＳＭＳスレッドを維持することができる）。

システムは、ユーザのクエリ(query)を分析し、その特定の主題に関して最も知識のあるエージェント又はスペシャリストにスレッド又はクエリをルーティングすること(routing)によって、サービスエージェントの応答の質及び／又は速度を改良するように更に作動することがある。異なる主題事項の複数のクエリが互いに近接して行われる場合には、各クエリは、異なるエージェントに別々にルーティングされてよい。ユーザとの会話により良い流れを提供するために、１つのエージェントは、一次応答エージェントと見なされ、他のすべての二次応答エージェントは、会話内への合成(synthesis)のためにそれらの応答をその一次応答エージェントに供給することがある。

システムは、メッセージングクライアントをユーザのアカウント情報と調整することによって、関連する製品情報又はサポート情報を提供するエージェントの能力(ability)をサポートすることもある。このようにして、エージェントのディスプレイは、（例えば、出荷又は返品サポートを提供するための）特定の販売情報、顧客固有の好み／サイズ、購入傾向、又は他のそのような関連情報で一杯になることがある。幾つかの実施形態において、この補助的な情報は、ユーザアカウントデータに基づくことがあり、幾つかの実施形態において、この補助的な情報は、受信するメッセージのコンテキストによって更に精緻化されてよい。

図１に示すように、マルチチャネル通信システム１０は、１つ以上のメッセージングサービス２４と通信するメッセージングエンジン２２、スレッド管理システム２６、ルーティングエンジン２８、及びキューマネージャ３０を含むことがある。幾つかの実施形態において、ルーティングエンジン２８は、自動化されたエージェント３２、及び運動量モニタ３４を含むことがある。

様々なメッセージングサービス２４は、典型的には、外部のプロバイダによって管理され、各々が、異なる通信ネットワーク上で動作し、１つ以上の異なるトランスポートプロトコルを利用し、且つ／或いは異なるエンドポイントデバイスと通信することがある。異なるメッセージングサービス２４の例は、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、プッシュ通知サービス、インターネットプロトコル（ＩＰ）メッセージングサービス、専用の第三者メッセージングサービス、電子メールサービス、及び／又は任意の適切な通信サービスを含む。メッセージングサービス２４の各々は、専用の通信サービスインスタンス、チャネル、及び異なるルーティングオプションを含むことができる。

メッセージングエンジン２２は、接続されたメッセージングサービス２４の各々又はいずれかを通じて通信するように構成されたメッセージングクライアントを含んでよく、或いはそのようなメッセージングクラウドと動作可能に接続されてよい。メッセージングクライアントは、メッセージングエンジン２２を介した通信のためのフロントエンドとして機能してよく、例えば、ユーザが通信することができる音声及び／又はテキストベースのインターフェースを含んでよい。メッセージングエンジン２２は、メッセージングクライアントを介してメッセージを送信すること、メッセージを受信すること、及び同期／非同期通信セッションを管理することにおいて使用されてよい。１つの構成において、メッセージングエンジン２２は、異なるメッセージングサービス２４によって特定及び／又は利用されてよい複数の異なる通信プロトコルを使用して通信するように構成されてよい。例えば、ＳＭＳメッセージでは、通信は、様々なサービスプロバイダ宛先へのＳＭＰＰ接続に依存することがあり、ＭＭＳメッセージでは、通信は、（ＭＭ４について）様々なサービスプロバイダ宛先へのＳＭＴＰ接続に依存することがあり、代替的に、それらは（ＭＭ７について）ＨＴＴＰ／ＳＯＡＰを通じてアクセスされるサービスリソースに依存することができる。多くの場合、特定のメッセージングサービス２４に関与するサービスプロバイダは、そのサービス上の他のクライアント／ユーザとの双方向通信を可能にするＡＰＩを提供することがある。

図２は、図１に示すように、メッセージングサービス２４から受信したメッセージを取り、それをメッセージスレッドに組み込んで、メッセージルーティングエンジン２８に渡す方法を概略的に示している。一般的に示すように、（５０で）メッセージングサービス２４からメッセージを受信した後に、メッセージングエンジン２２は、（５２で）そのメッセージからユーザ識別情報及びメッセージコンテンツの両方を抽出するように構成されてよい。ユーザ識別情報は、例えば、電話番号、ユーザ名、ユーザ番号、デバイスＩＤ番号、又は同等のものであってよい。多くの場合に、ユーザ識別情報は、メッセージの一部として符号化されてよく、且つ／或いはヘッダブロック内でメッセージの前に置かれてよい。ひとたび抽出されると、この情報は、スレッド管理システム２６に渡されてよく、スレッド管理システム２６で、メッセージコンテンツは、ユーザデータベース３６内に維持されたユーザアカウントに関連付けられてよい。

スレッド管理システム２６は、一般的には、メッセージがいつ受信されるかにかかわらず、各ユーザについて１つ以上の進行中のメッセージスレッドを維持することに関与してよい。図２を引き続き参照すると、メッセージからのユーザ識別情報は、（５４で）ユーザデータベースから認識されるならば、スレッド管理システム２６は、そのユーザのアカウントをチェックして、既存の通信スレッドが開いているかどうかを決定してよい。既存の開いているスレッドがあるならば、メッセージコンテンツは、（５８で）その開いているスレッドに追加されてよい。開いているスレッドが存在しないならば、スレッド管理システム２６は、（６０で）新しいスレッドを生成し、（６２で）そのスレッドをルーティングエンジン２８に渡してよい。

（５４で）ユーザ識別情報が認識されないならば、（６４で）新しい一時アカウントが作成されてよく、或いは、ユーザアカウントがアクセスされることを可能にすることがある識別情報を提供するために、ユーザは（同じメッセージングサービス２４を介して）返品メッセージによってプロンプトされてよい。幾つかのインスタンスでは、例えば、ひとたび注文特異な詳細がエージェントに提供されると、孤立スレッド(orphan thread)又は作成された一時アカウントが、会話の後にユーザのアカウントに移行されてよい。一例として、ユーザのメッセージが、ユーザがアイテムを返品することを望むことを示すならば、ユーザ識別情報は、最終的に、ユーザアカウントにリンクされることがある注文番号のようなメッセージコンテンツから流れてよい。

再び図１を参照すると、ルーティングエンジン２８は、一般的には、新しいメッセージスレッド及び（メッセージスレッドに関連する任意の二次情報を含む）新しいメッセージを、ユーザのクエリを最もよくサポートすることがある適切なライブエージェント(live agent)にルーティングすることに関与することがある。上述のように、幾つかの実施形態において、ルーティングエンジン２８は、メッセージの性質及びコンテキストを理解することができる自動化エージェント (自動化されたエージェント)３２又は人工知能と、メッセージスレッドの運動量(モーメンタム)(momentum)を決定するように作動する運動量モニタ３４とを含んでよい。メッセージの性質及びコンテキストを知ることは、ルーティングエンジン２８が、リクエスト(要求)の主題事項、技術的専門知識、又は感度に基づいてクエリを処理するための適切なエージェント（又は適格なエージェントのプール）を識別することを可能にすることがある。更に、メッセージスレッドの運動量を知ることによって、システムは、特定のスレッドの感度及び／又はメッセージ頻度に従って、個々のエージェント間のメッセージロードのバランスを取ることにより熟練することがある。

自動化エージェント３２は、リクエストの性質及びコンテンツを理解することができる自然言語応答エンジンを含んでよい。幾つかの実施形態において、自動化エージェント３２は、初期メッセージの受信後に、ユーザとの予備的な議論を行うように作動する人工知能コンポーネントを更に含んでよい。例えば、自動化エージェント３２は、特定の連絡先情報を得ること、小売アドレスを得ること、注文状況を決定すること、及び同等のことのような、単純なリクエストに対処してよい。更に、自動化エージェント３２は、ライブエージェントによって必要とされることがある必須情報を得る機能を果たしてもよい。例えば、返品が要求されるならば、自動化エージェント３２は、特定の製品、注文番号、及び／又は返品の根本的な理由について問い合わせてよい。

一般的には、初期メッセージ受信に自動化エージェント３２を含めることは、幾つかの利益をもたらすことがある。第１に、それはライブエージェントが必要とされる場合よりも低いコストで単純なリクエストを処分することがある。第２に、それは特定のクエリに回答するためにエージェントによって必要とされることがある情報を収集することがある。このようにして、ライブエージェントは、予備的な事実発見を行う応答時間／努力を費やす必要がない。第３に、自動化エージェント３２は、たとえライブエージェントが現在利用可能でないとしても或いは回答するクエリの大きなキューを有しているとしても、初期応答性の感覚をユーザに提供するために、迅速な方法でユーザと関わることがある。この応答性は、ユーザの欲求不満の生成や増大を防ぐのに役立つことがある。最後に、自動化エージェント３２とのやりとりは、ベースメッセージスレッドを生成することがあり、ベースメッセージスレッドから、運動量モニタ３４は、会話の運動量を決定し、ライブエージェントのための適切な応答時間目標を設定することがある。

会話運動量の概念は、テキストベースのメッセージングプラットフォーム上で会話するときに、異なるユーザが異なる速度で異なるレベルの緊急度でメッセージを送ることがあることを認識している。同期的な会話（すなわち、リアルタイムのやりとり）に関わっているユーザは、より大きなエージェント容量(能力)(capacity)を要求することがある高速を有することがある（すなわち、エージェントがリアルタイムのやりとりに関わっているならば、他のユーザとの追加メッセージスレッドを処理する容量はより少ない）。逆に、非同期的な方法でメッセージを送るユーザは、遅い速度を有することがある（すなわち、ユーザは、テキストメッセージ応答の間に自分の電話を数時間下に置くことがあり、或いは１日を通じて定期的に電子メールをチェックするだけのことがある）。このより遅い速度は、同期的な会話で要求されるのと同じ迅速な応答を必要としないことがある。よって、遅い速度は、エージェントが任意の所与の期間で比較的多くのメッセージスレッドを処理することを可能にすることがある。

速度と同様に、応答目標を決定する際には、クエリの緊急性や質量(mass)も考慮に入れられなければならない。非常に緊急なリクエスト、又はユーザの欲求不満又は怒りをより強く感じるリクエストは、懸念を非必要に増大させないように、より迅速なエージェント応答を必要とすることがある。逆に、気軽なリクエスト（例えば、今週末に新しいものが出てくるかどうか）は、同じレベルの迅速な注目を必要としない比較的より低い質量を有することがある。１つの実施形態において、会話質量は、スレッドによって伝達される感情のレベルと共にリクエストの性質を理解することを目的とすることがある自然言語処理アルゴリズムによって決定されてよい。

幾つかの実施形態において、会話の質量は、ユーザのアカウントの１つ以上の属性によって更に影響されることがある。例えば、小売店の従業員からのメッセージは、会社との以前の経験のないユーザよりも高い質量が割り当てられてよい。同様に、販売履歴、ソーシャルメディアへの露出、世間への影響力、会社の関わり、及び／又は顧客層のような他の要因も、質量に影響を与えることがある。例えば、ソーシャルメディアへの露出度が高く、世間への影響力が高く、会社からの企業スポンサーシップを有する著名人は、最小の販売履歴を有し且つソーシャルメディアへの露出のない顧客よりも、より大きな質量を有することがある。質量は、ユーザが扱われる注意に影響を与えるべきでないが、質量は、エージェントのキューサイズ、又はエージェントがそのリクエストと同時に処理することがある他のメッセージスレッドの数を調整するために使用されることができる。この例において、著名人は、エージェントが他のメッセージスレッドを処理しないように、エージェントのキュー全体を消費することがある。同様に、散発的な消費者は、複数のメッセージスレッドを同時に管理しているエージェントに割り当てられてよい。

１つの実施形態では、会話の質量は、自動化エージェント３２によって０～１００のスケールでスコアリング(スコア付け)されてよい。このスコアリングは、パーセンタイルのようなスコアリングであってよく、この場合、０は、絶対に緊急性又は感情を有さず、１００は、純粋な緊急性及び純粋な感情を有する（すなわち、両方の数は、理論的には、得ることができない）。次に、メッセージの各メッセージ又は集合は、時間に敏感な問い合わせを意味する表現的又は刺激的な単語、語句又はコンテキストなどのそれらの使用に従ってスコアリングされてよい。メッセージ速度は、例えば、受信されたメッセージの周波数（すなわち、メッセージ間の瞬間的又は平均的な期間の逆数）としてスコアリングされてよい。従って、会話運動量は、相対的なスコアリングされた質量に平均周波数を乗じた値に等しいことがある。

会話運動量６５のヒストグラムは、一般に、図３に示すような、正規分布／ベル曲線の形態（すなわち、会話運動量が水平方向のｘ軸上で表され、周波数がｙ軸上で表された形態）を取ることが見出されている。幾つかの実施形態において、運動量分布６５は、（二次的なｙ軸上で表された）応答時間目標６６を設定するために使用されてよい。例えば、最低十分位６８における運動量（すなわち、比較的より遅いメッセージング速度及び比較的より低い緊急性を構成する最低運動量）を有する会話は、１５分のような第１の値７０で設定された応答時間目標を有してよい。逆に、最大十分位７２における運動量（すなわち、比較的より大きなメッセージング速度及び比較的より大きな緊急性を構成する最大運動量）を有する会話は、１５秒のような第２の値７４で設定された応答時間目標を有してよい。最後に、運動量分布の中央値７６にある運動量を有する会話は、３０秒のような第３の値７８で設定された応答時間目標を有してよい。例示的な目標を介して示されるような１つの構成において、分布全体に亘る応答時間目標関数は、非線形であってよい。これは、何故ならば、分布の上端でのユーザの期待の差は僅かに変化するにすぎないことが分かっているのに対し、分布の下端での許容可能な応答時間はユーザの散発的な会話パターンによってより大きく影響され、それは有意により大きな応答時間をもたらすからである。よって、適用可能な応答時間目標は、決定された運動量と非線形ではあるが、反比例的に変化することがある。図示しない別の実施形態において、適用可能な応答時間目標は、決定された運動量に反比例的に且つ線形に変化することがある。

再び図１を参照すると、１つの構成において、運動量モニタ３４は、ユーザと自動化エージェント３２との間の予備的な会話を分析して、ユーザが会話する速度と共にクエリの質量を評価してよい。次に、これら２つの要因の定量的な尺度(測定値)を組み合わせて、エージェント応答時間目標を動的に設定し、エージェントのキューのサイズを調整し、エージェントがどの未解決のクエリに最初に応答すべきかの優先順位を付けることを可能にするために使用される運動量の尺度(測定値)を形成してよい。

図４は、自動化エージェント３２によって行われることがあるような、ユーザクエリに最初に応答する方法を概略的に示している。図示のように、メッセージスレッド（新しいスレッドが開かれていることの何らかのしるし）がルーティングエンジン２８にひとたび渡されると、自動化エージェント３２は、（８０で）１つ以上の自然言語アルゴリズムを用いて初期メッセージを検討して、リクエストの性質及び緊急性を決定してよい。次に、自動化エージェント３２は、（８２で）挨拶、ユーザのリクエストの認識、及びユーザのリクエストに対する回答又はフォローアップ質問のいずれかで、ユーザに応答してよい。ユーザからの後続のメッセージの受信後に、自動化エージェント３２は、（８４で）先行応答がユーザのクエリを満足したかどうかを決定してよい。満足しているのであれば、自動化エージェント３２は、（８６で）スレッドを閉じてよい。満足していないのであれば、エージェント３２は、（８８で）ユーザにフォローアップするか、或いは（９０で）スレッドを運動量モニタ３４に渡してよい。

図５は、運動量モニタ３４の動作の１つの方法を概略的に示している。図示のように、運動量モニタ３４は、スレッドを検討して、ユーザが応答する（すなわち、応答を開始する或いは送信する）平均時間に基づいて（９２で）会話速度を決定してよい。１つの実施形態において、速度は、全応答時間の総平均を反映してよい。別の実施形態において、速度は、単純移動平均又は（初期のユーザ応答時間よりも最近のユーザ応答時間により重きを置くことがある）指数移動平均を反映してよい。次に、運動量モニタ３４は、メッセージの感情（例えば、強い肯定～強い否定）及び／又はリクエストの性質（例えば、平常通り～緊急）の自然言語評価、又はユーザ特性、属性、会社との関係もしくは関わり、販売履歴、公衆への影響、ソーシャルメディアの存在、及び／又は同等のもののうちの少なくとも１つに基づいて、（９４で）会話の質量の評価を行ってよい。

次に、計算された速度及び決定された質量から、運動量モニタ３４は、２つのパラメータの組み合わせを反映する運動量スコアを（９６で）計算してよい。次に、この運動量スコアを、自動化エージェントからの任意の利用可能な会話コンテキストと共に、ルーティングエンジン２８によって使用して、利用可能なライブエージェントにメッセージスレッドを動的に割り当ててよい。ひとたび割り当てられると、スレッドは、各ユーザのそれぞれのキュー内の応答の適時性を監視するために、（９８で）キューマネージャ３０に渡されてよい。

再び図１を参照すると、本システムは、一般的には、複数のライブエージェント（Ａ１乃至Ａｎ）を含み、各ライブエージェントは、ライブエージェントが回答／管理に関与するそれらの独自のそれぞれのメッセージキュー（Ｑ１乃至Ｑｎ）を有する。一般的には、メッセージキューは、ライブエージェントが任意の所与のときに応答している１つ以上の会話スレッドを含んでよい。図６は、複数の開いたメッセージスレッド１００を含むメッセージキュー３８の例を概略的に示しており、各メッセージスレッドは、決定されたスレッド運動量１０２を有する。各ライブエージェントは、エージェントとしてのスキル及びスループットを表す所定の最大応答容量１０４を有してよい。ルーティングエンジン２８は、キューマネージャ３０との組み合わせにおいて、ライブエージェントのキュー３８内のスレッド運動量１０２の合計が、そのエージェントの最大応答容量１０４を超えないように作動しなければならない。キュー３８は、エージェントの利用可能な容量１０６を更に表してよく、エージェントの利用可能な容量１０６は、そのエージェントの最大容量１０６から、キュー３８内のスレッド運動量１０２の合計を減算したものである。

１つの実施形態において、ルーティングエンジン２８は、ライブエージェントに未だ割り当てられていないが、それぞれのスレッド運動量１０２に割り当てられた、１つ以上の割り当てられていないメッセージスレッドを維持することがある。そのような場合、ルーティングエンジン２８は、先ず、全エージェントのプールをフィルタリングして、自動化エージェント３２によって最もよく理解されるようにクエリを処理するための技術的専門知識及び／又は顧客サービス専門知識を有するサブセットを識別することがある。次に、ルーティングエンジン２８は、キューマネージャ３０に相談して、このサブセット内のどのエージェントが新しいスレッドを受け入れるか並びにそれらの利用可能な容量１０６を超えることなく割り当てられていないスレッドを処理するための利用可能な容量を有するかを決定してよい。１つの実施形態では、ひとたびルーティングエンジン２８によって割り当てられると、キューマネージャ３０は、次に、割り当てられていないスレッド１０８をエージェントのキュー３８に転送し、利用可能な容量を更新してよい。別の構成において、ライブエージェントは、ライブエージェントが回答するための関連する専門知識を有する、割り当てられていないメッセージスレッドのプール全体を見ることができる場合があり、次に、会話を選択する或いはオプトインすることができる場合がある。

メッセージスレッドがエージェントのキュー３８にひとたびロードされると、キューマネージャ３０は、スレッドの決定された運動量スコア／値に基づいてスレッド１００に応答時間目標１１２を割り当てるように作動することがある。一般的には、応答時間目標は、未解決のユーザクエリに応答するためにエージェントが割り当てた目標最大時間である。応答時間目標は、高い運動量スレッドがより低い運動量スレッドよりも比較的より短い応答時間目標を有するように、運動量値に反比例して変化することがある。１つの実施形態において、各スレッド１００は、所与の応答ウィンドウ(窓)内で残っている時間１１４の量を更に反映することがある。この残り時間メトリック１１４(time-remaining metric)は、最後のメッセージがそのスレッド１００内のユーザから受信されてからの経過時間を応答時間目標から引いたものを反映してよい。この残り時間メトリック１１４は、どれぐらいの時間が応答するために依然として利用可能であるかをそれぞれのエージェント３６に示すカウントダウンタイマに似ていることがある。

１つの実施形態では、残り時間メトリック１１４がゼロに達し（すなわち、応答時間ウィンドウ全体が経過し）、エージェントが応答の入力を未だ開始していないならば、キューマネージャ３０が介入するように構成されてよい。そのような介入は、エージェントが質問を調査しており、追加の時間を必要としていることを示すために、キューマネージャ３０がユーザにメッセージを送信することを含むことがある。１つの構成において、この介入は、恰もエージェントが個人的にメッセージを送信したかのように表されることがある。１つの実施形態において、この介入メッセージは、図６の「ユーザＤ」に関連する負の数として示されるような二次タイマを開始し、それは、次に、性能評価の目的のために、及び／又はエージェントの最大応答容量１０４を調整するために、モニタリング(監視)されることがある。

再び図１を参照すると、エージェントによって未解決のクエリに応答がひとたび提供されると、それはスレッド管理システム２６にフィードバックされ、スレッド管理システム２６で、エージェント応答は、ユーザのアカウントに関連するメッセージスレッドの端に付加される。そこから、メッセージは、メッセージエンジン２６に渡され、メッセージエンジン２６で、メッセージは、メッセージングサービス２４のうちの１つ以上を介してユーザに送り返される。１つの実施形態では、本システムは、メッセージがどのように受信及び／又は送信されるかとは無関係に作動するので、メッセージスレッドの一部又は全部は、異なるメッセージングサービスを通じて利用可能にされてよい。例えば、ユーザは、移動中にＳＭＳメッセージングを通じてエージェントとの会話を開始し、次に、自宅に到着するとＩＰアプリに切り替えてよい。そのような例において、メッセージングエンジン２２は、ＩＰアプリを介してメッセージスレッド全体（又は少なくとも所定の数の最新のメッセージ）を利用可能にしてよい。

幾つかの実施形態において、ルーティングエンジン２８は、永続的であってよく、各々の入ってくるメッセージがメッセージスレッドに付加されるときに各々の入ってくるメッセージをモニタリングしてよい。例えば、幾つかの実施形態において、運動量モニタ３４は、例えば、単純移動平均又は指数移動平均を使用して、或いは、より最近の運動量計算値により離れたものよりも大きな重みを割り当てることがある他の重み付けスキームを使用して、会話の運動量を連続的に更新してよい。このようにして、延長された遅延の期間の後に同期した会話に関わることを望むユーザは、彼らのメッセージスレッドをより速い応答時間目標とより速く割り当てさせることがある。幾つかの実施形態において、特定のスレッド１００のための更新された運動量がエージェントのキュー３８内のスレッド運動量１０２の合計をエージェントの最大応答容量１０４を超えさせるならば、ルーティングエンジン２８は、自動的に又はライブエージェントによる確認後に、特定のスレッド（例えば、更新されたユーザ関心を有するスレッド、又は比較的より低い質量もしくは運動量のスレッド）を異なるライブエージェントに再割り当てしてよい。別の実施形態において、スレッド運動量１０２の合計が、エージェントの最大応答容量１０４を僅かに超えるだけであるならば（すなわち、所定の量よりも少なく超えるならば）、ルーティングエンジン２８は、追加のスレッドがキューに追加されるのを単に防止してよく、或いは、エージェントの性能／応答性を評価する際にそのようなことを考慮に入れてよい。更に、幾つかの実施形態では、運動量の変動がエージェントの最大容量を超えることなく順応されることがあるように、緩衝容量(buffer capacity)がスレッド運動量１０２の合計とエージェントの最大応答容量１０４との間で維持されてよい。

連続的なスレッド運動量更新に加えて、幾つかの実施例において、ルーティングエンジン２８／自動化エージェント３２は、サポートを提供するライブエージェントを支援するために、自然言語処理アルゴリズムを用いて受信した後に、ユーザメッセージを連続的に評価してよい。より具体的には、自動化エージェント３２は、ライブエージェントに有益であることがあり且つ新たに受信したメッセージと共にライブエージェントに転送されてよい補助情報を生成する目的のために、各々の受信したユーザメッセージを個別に及び／又はより広いスレッドのコンテキストで分析することがある。そのような補助情報は、例えば、ユーザのクエリに対する潜在的な回答、テンプレート応答言語、関連する製品情報、関連する注文情報、及び同等のものを含むことがある。提案された応答言語の場合、ライブエージェントは、提案された言語を応答に含めるか、応答において提案された言語を修正／補足するか、あるいは提案された言語を完全に無視するかの最終的な裁量を有してよい。次に、ライブエージェントの最終応答を使用して、自動化エージェントが将来において改良された及び／又はより関連する示唆を提供することがあるように、自動化エージェントの機械学習モデルを訓練してよい。

図７は、ライブエージェントに提示されることがあるスクリーン／インターフェース１４０の一例を概略的に示している。概ね示されているように、インターフェース１４０は、（図６に示すものと類似する）エージェントのキュー３８の表現、ユーザと対話するためのアクティブチャットスレッド１４２、及び（自動化エージェント３２から）受信された補助情報が表示されることがあるサポートウィンドウ１４４を含む。エージェントのキュー３８は、複数のアクティブスレッド１００を含んでよく、複数のアクティブスレッド１００は、エージェントの応答を待っている第１の複数のアクティブスレッド１４６と、ユーザのフォローアップを待っている応答された第２の複数のアクティブスレッド１４８とを含む。各スレッド１００は、関連付けられた名前１５０（例えば、ユーザネーム又はユーザの名前）、メッセージ状態識別子１５２、及び残り時間メトリック１１４を含んでよい。スレッド１００の１つをクリックするか或いは他の方法で選択すると、チャットスレッド１４２をエージェント／会社とユーザとの間の歴史的及び進行中のメッセージスレッドで一杯にする。スレッド１００のうちの１つを更に選択することは、サポートウィンドウ１４４内にユーザ及び／又はユーザのクエリに関する最近提供された補助情報を呼び出すこともある。

図７に概ね示されているように、チャットスレッド１４２は、エージェント／会社１６０へのメッセージ／クエリ、（例えば、ハンドオフを容易にする）自動化エージェント３２からライブエージェントへのメッセージ１６２、ライブエージェントからの又はライブエージェントに代わってのユーザへの自動生成応答１６４、及びライブエージェントからユーザへのメッセージの混合物を含んでよい。

チャットの間、サポートウィンドウ１４４は、ユーザ及びユーザのクエリに関する情報のエージェントの主なソースとして機能することがある。この情報をディスプレイの単一のウィンドウ／領域に統合することによって、本システムは、エージェントがユーザにより迅速に応答することを可能にすることがある。幾つかの実施形態において、サポートウィンドウ１４４は、ユーザ属性セクション１７０と、提案された応答セクション１７２とを含んでよい。ユーザ属性セクション１７０は、ユーザの関心、好み、購入履歴、及び同等のことについての獲得した洞察をエージェントに提供してよい一方で、提案された応答セクション１７２は、ライブエージェントの応答を誘導又は合理化する努力において（自然言語処理アルゴリズムを介して）自動化エージェント３２によって提供される潜在的な応答言語を含んでよい。

幾つかの実施形態において、ユーザ属性セクションは、例えば、ユーザプロファイル情報１８０、ユーザ履歴情報１８２、ユーザアカウント情報１８４を含んでよい。プロファイル情報１８０は、例えば、ユーザ１９０、ユーザの製品嗜好１９２（例えば、ユーザが購入することがある典型的な製品、スタイル、及び／又は色）、ユーザの最近の閲覧履歴１９４、ユーザの関心、モバイルアプリケーション又はウェブページとのユーザの関わり、ユーザの消費パターン、及び／又はユーザの連絡先情報の簡単な要約を含んでよい。履歴情報１８２（すなわち、タブヘッダがひとたび選択されると一杯になることがある履歴情報）は、例えば、他のエージェントとの以前の会話、ユーザのソーシャルメディアとの関わり、タグ付き製品、共有製品、以前のエージェントの製品提案、及び同等のことの要約を含んでよい。最後に、アカウント情報１８４は、以前のユーザの注文、注文された製品、好まれた製品、ユーザに送られた製品オファー、ユーザに送られた割引オファー、及び同等のことの要約を含んでよい。

本システムは、一のチャットの過程内で複数の特殊化されたライブエージェントを利用して、ユーザに最良の品質の解答を提供するように更に構成されてよい。例えば、１つの会話／クエリの過程中にユーザが無関係のリクエストを行うならば、以前のシステムは、現在の会話を完了し、次に、無関係のリクエストを支援することがある第２のエージェントに会話を転送することを、エージェントに要求したことがある。本システムにおいて、二次エージェントは、ユーザとの能動的な会話を維持している一次エージェントのアシスタントになることがある。このようにして、会話全体は、ユーザの観点からシームレスである一方で、エージェント側に複数の専門家を含む。

図８は、ユーザにシームレスな体験を提供しながら、複数のエージェントからの入力をサポート会話に統合するプロセス２００のフロー図を提供している。概ね示されているように、プロセスは、ルーティングエンジン２８が質問スレッド内の１つ以上の質問を検出するときに２０２で開始する。これは、入って来るメッセージフローを連続的にモニタリングする１つ以上の自然言語処理アルゴリズムを使用して発生することがある。１つの実施形態において、１つ以上の質問は、単一のユーザメッセージ内に含まれてよい。別の実施形態において、１つ以上の質問は、直ちに続くことがある或いは介在するエージェント応答を有することがあるユーザからの複数のメッセージに亘って分割されてよい。

様々な質問が２０２で識別されると、各質問は、（２０４で）ソフトウェア内のオブジェクトとしてコード化され、一般的なトピック又はカテゴリに割り当てられてよい。次に、システムは、（２０６で）ユーザが既存のスレッドを開いているかどうかを検査してよい。もしそうでないならば、ルーティングエンジン２８は、２０８で一次質問／クエリを識別することによって開始してよい。一次質問は、最大の質量又は緊急性、増大についての最大の可能性を有すると決定される、且つ／或いは（エージェントの特殊化のレベル及びそれらの洗練度を示す所定のエージェントスコアリングに従った）最も広い数のエージェントによって答えられることがある、質問であってよい。一般的な意味において、知識の豊富な専門的エージェント（例えば、オリンピック選手）は、知識の乏しいエージェントよりも高価なリソースである。図８を引き続き参照すると、（２０８で）ひとたび一次質問が決定されると、（２１０で）その質問について適切な経験を有し且つ利用可能な容量を有するエージェントが一次エージェントとして割り当てられてよい。

エージェントがスレッドに割り当てられるならば或いはエージェントがスレッドに割り当てられるときに、プロセス２００は、（２１０で）受信されて分析されたメッセージをそのエージェントに渡すことを含んでよい。次に、割り当てられた一次エージェントは、（２１４で）メッセージ又はスレッド内に異なる質問／オブジェクトが存在することをプロンプトされてよく(促されてよく)或いは警告されてよい。１つの構成において、一次エージェントは、非一次オブジェクト（すなわち、二次質問／オブジェクト）のうちの１つを選択し、（２１６で）その二次質問を二次エージェントに転送することを選択してよい。次に、二次エージェントは、質問に回答してよく、応答は、会話内への潜在的な包含のために（２１８で）一次エージェントに送り返されてよい。一次エージェントを最初にプロンプトすることによって、このプロセスは、一次エージェントが、より困難な質問又はより専門的な知識を必要とする質問を参照しながら、安心できる質問に回答することを可能にする。

１つの構成では、（２０４で）オブジェクトが作成されると、ルーティングエンジン２８は、クエリが該当する１つ以上のトピックカテゴリを決定してよい。これらのカテゴリは、既存の部署／専門分野に合致するように事前に構成されてよく、且つ／或いはシステムに柔軟性をもたらすために有機的に開発されてよい。それにもかかわらず、一次エージェントが（２１４で）二次質問を手渡すようにプロンプトされると、そのプロンプトには、決定されたカテゴリに適した利用可能なライブエージェントのリストを含んでよい。代替的に、エージェント選択は、依然としてクエリについて決定されたトピックカテゴリの適合性に基づくことがあるが、一次エージェントのビューの外側で生じてよい。更に他の実施形態において、一次エージェントは、補助のためのトピックにフラグを立ててよく、それは他の利用可能なエージェントがクエリを選択することがあるか或いは二次会話に別の方法でオプトインすることがあるより広いライブエージェントのプールにクエリを送り返してよい。二次エージェントについての応答時間目標は、一次会話についての応答時間目標によって決定されてよい。より具体的には、二次エージェントについての応答時間目標は、一次エージェントについての応答時間目標よりも小さくてよい。１つの構成において、それは一次応答時間目標よりも短い固定的な持続時間であってよい。

再び図７を参照すると、サポートウィンドウ１４４は、ユーザが参照製品を購入できる特定の製品ページへの１つ以上の深いリンク（すなわち、ユーザの閲覧履歴１９４として示されているものに類似するリンク）を提供することによって、エージェントを更に支援してよい。これらのリンクは、自動化エージェント３２によって占められてよく、ライブエージェントによってチャットウィンドウに容易にコピーされる。図９は、ユーザが提案された製品を購入できる特定の製品ページへの関連する深いリンクを生成するために使用されることがあるシステム／方法２５０の１つの実施形態を概略的に示している。図示のように、自動化エージェント３２は、利用可能な在庫のデータベース２５２を組み立てることによって開始してよい。このデータベース２５２は、小売業者の実店舗２５６、小売業者の電子商取引ビジネス２５８、１つ以上の第三者実店舗２６０（例えば、ユーザに近接して位置する店舗）、及び／又は１つ以上の第三者電子商取引ビジネス２６２によって維持される製品在庫の一部又は全部を識別してよい。本明細書で使用するとき、データベース２５２は、定期的に更新される永続的なデータベースであってよく、或いは、データベース２５２は、自動化エージェント３２が、提案された製品の識別後に店舗／事業２５６、２５８、２６０、２６２のうちの１つ以上をポーリングすることによって、オンデマンドで生成されてよい。

リンク作成プロセスは、一般に、ユーザ又はライブエージェントから製品リクエスト２６４を受信した後に、又は自動化エージェント３２がユーザの製品履歴を認識するか或いはユーザとエージェントとの間の議論のコンテキストから特定の製品（２６６）を識別することができるときに始まる。これがひとたび生じると、自動化エージェント３２は、データベース２５２に相談して、製品が小売業者又は参加している第三者から入手可能であるかどうかを決定してよい。製品が在庫中であるとエージェント３２が決定するならば、それはウェブサイトへのリンク２７０を生成し、次に、製品は、ウェブサイトで購入されてよい。このリンク２７０は、ライブエージェントに送信され、サポートウィンドウ１４４に表示され、サポートウィンドウで、ライブエージェントは、それをチャットインターフェース２７２にコピーしてよい。

特定の製品にリンクするときに、或いは製品を購入可能にするときに、自動化エージェント３２は、一般に、全ての他の要因が等しいならば小売業者によって維持される製品在庫を優先するように構成されてよい。しかしながら、ユーザのリクエストしたタイムラインが小売業者によって満足されない状況において、タイムラインは、第三者在庫を参照することを指示してよい。例えば、ユーザが同日のピックアップを要求するならば、自動化エージェント３２は、例えばそれが小売業者自身の在庫ではなく第三者にリンクすることを意味するとしても、電子商取引サイトよりも実店舗を優先してよい。このようにして、ユーザの場所ならびに関連する在庫の場所の知識は、最もオンポイント(on-point)の製品リンクを作成する際に重要である。第三者在庫のこの知識を有するならば、ライブエージェントは、製品入手可能性に関する情報の単一のソースであることがあり、この支援役割において自動化エージェント３２を使用することは、ユーザ又はライブエージェントのいずれかが第三者を探し回って入手可能性を決定しなければならない必要性を解消する。

製品のどこに由来するかにかかわらず、１つの構成において、リンク２７０は、ユーザを、全ての購入のための販売インターフェースとして機能する、小売業者によって維持されるインターネットアプリ又は製品ウェブサイト２８０のような、フロントエンドユーザインターフェースに導いてよい。より具体的には、リンク２７０は、ユーザを、（利用可能な在庫がこれをサポートするならば）ローカルピックアップ又は出荷オプションが両方とも利用可能であるアプリ又は製品ウェブサイトに導いてよい。販売がローカル第三者小売業者でのローカルピックアップのためにフロントエンドユーザインターフェースを通じて完了するならば、自動化エージェント３２（又は他の関連する電子商取引システム）は、ピックアップのために製品を保持するよう第三者に指示しながら、その小売業者と購入を調整する。他の実施形態において、リンク２７０は、これらのサイトを通じた直接購入のために、ユーザを第三者ウェブサイトに導いてよい。

再び図７を参照すると、エージェントのためのユーザインターフェースは、それらが支援している消費者に基づいて動的に変化してよい。例えば、インターフェースは、消費者が所在する関連する製品検索（近くの在庫入手可能性）を提供する、好ましい消費者言語に基づいて言語スペルチェッカを切り替える、価格が消費者の正しい通貨であるなどだけである。その場合、これは、世界中のエージェントが、サポートしている消費者と同じ言語を話す／書くことができる限り、どんな顧客をも支援することを可能にすることができる。例えば、米国内のライブエージェントが中国の消費者を支援しているならば、サポートウィンドウ１４４は、中国の関連する応答情報に切り替わり、中国の店舗内の在庫にアクセスし、全ての製品価格はＲＢＭにある。

図１０は、ユーザ集団３０６からの問い合わせ／通信３０４に応答するために複数のライブエージェント３０２（例えば、図１のエージェントＡ_１乃至Ａ_ｎ）を利用することがあるシステムレベルアーキテクチャ３００を概略的に示している。１つの構成において、複数のライブエージェント３０２は、複数の集中ライブエージェント３０８（エージェント_１乃至エージェント_Ｎ）及び／又は複数の分散ライブエージェント３１０（エージェント_Ｄ１乃至エージェント_ＤＮ）を含んでよい。代替的に、この複数のライブエージェント３０２は、複数の専用ライブエージェント３０８（すなわち、物理的に分散された方法で働くとしても、顧客サービスが主たる職務である場合）及び／又は複数のオンデマンドライブエージェント３１０を含んでよい。一般に、集中／専用ライブエージェント３０８は、ユーザ集団３０６に顧客サービスを提供することを主たるタスクとするエージェントのグループであってよい。１つの構成において、これらのエージェントの全ては、共通のコールセンターに配置されてよい。逆に、分散／オンデマンドライブエージェント３１０は、より個別化された又は分散された容量で動作している個人又は異なる責任から顧客サポートを提供する目的に時間をフレックスする能力を有する個人を含んでよい。１つの実施形態において、これらの分散／オンデマンドライブエージェント３１０は、ゆっくりした小売期間中に利用可能な時間を有する実店舗からの小売店員を含んでよい。加えて、幾つかの実施形態において、これらの分散／オンデマンドライブエージェント３１０は、特定の業界に精通しているが、小売容量で直接的に雇用されていない、熱狂者（例えば、他の運動選手をサポートする競技選手、非小売の会社の従業員又は消費者が直面する役割、及び同等のこと）を含んでよい。

特に分散／オンデマンドライブエージェント３１０の中で、弾力的エージェントプールを奨励するために、ユーザ集団３０６のニーズに対応するために、ならびに事業の全体的な目的を支援するために、１つ以上の報酬３１２が提供されてよい。１つの構成において、報酬３１２の大きさは、１つ以上の問い合わせ価格決定メトリック３１６及び／又は問い合わせを処理するのに適格なエージェント集団のサイズ３１８に従って報酬を調整するために、供給／需要価格決定モジュール３１４を介してスケーリングされてよい。そのような問い合わせ価格決定メトリック３１６は、リクエストの技術的複雑性、未解決の／割り当てられていないユーザ問い合わせの総数、及び／又は特定のリクエストの質量を含んでよい。より複雑な問い合わせ、より大規模な問い合わせは、より大量の割り当てられていない問い合わせと同様に、より大きな報酬を指示してよい。

１つの実施形態において、ライブエージェント３０２は、それぞれ、関連する技術的専門知識及び／又はエージェントとしての容量における専門知識に基づいてスコアリングされてよく、それらの相対的なスコア又は能力は、彼らを特定の問い合わせを処理するのに適させることがある。例えば、運動競技のコンテキストにおいて、大学の競技者は、高校の競技者よりも、自分のスポーツにおいてより大きな技術的専門知識を有しているとみなされるが、異なるスポーツについては、比較的より少ない専門知識を有することがある。同様に、キャリア顧客サービス（ＣＳ）専門家は、正式なＣＳ経験が殆どない運動選手よりも、繊細な問い合わせ／顧客の関心事を扱うことにおいてより大きな専門知識を有することがある。更に、特定のスポーツについてのキャリアＣＳエージェントは、たとえＣＳエージェントがそのスポーツを個人的にしないとしても、アマチュア運動選手よりもそのスポーツにおいてより多くの技術的専門知識を発達させていることがある。１つの実施形態において、専門知識は、経験ポイント（ＸＰ）値として、或いは次のレベルに進むために特定の量の経験が必要とされるレベルとして、伝達されてよい。

図１０を引き続き参照すると、各ユーザ問い合わせ３０４は、問い合わせの感情の強さ及び所要の技術的専門知識を決定するために、その自然言語処理を用いて自動化エージェント３２によって評価されてよい。次に、この評価は、エージェントフィルタ３２０を調整して、利用可能なエージェントの集団を、関連する技術的及び顧客サービス専門知識（例えば、スコア）を有するエージェントにのみ制限してよい。このようにして、緊急の競技前の問い合わせを有するマラソン選手は、特定のレベルのランニング経験及び実証されたレベルの即応性／問題解決能力を有するエージェントのみが問い合わせを見ることがあるように、問い合わせをフィルタにかけてよい。

このフィルタリングに続いて、新しい会話の質量がエージェントの利用可能な予め決定された容量を超えないならば、利用可能なエージェントは、会話／問い合わせにオプトインし、ユーザとのチャットセッション３２２を確立してよい。各チャットセッション３２２は、様々な紛争解決及びビジネス促進メトリックに従って報酬調整モジュール３２４によって連続的に評価されてよい。この実施例では、積極的な紛争解決の結果及びビジネスの促進目標の前進は、正の報酬調整を引き起こすことがあるのに対し、紛争増大及び反ビジネス声明は、負の報酬調整を引き起こすことがある。報奨されるべき積極的な商慣行の例は、例えば、ユーザを新規顧客アカウントに参加させること、ユーザを促して既存のアカウントにログインさせること、最初の問い合わせの解決に続いて問い合わせ又は連絡が生じるように消費者との関係を確立すること、ユーザに製品ページへのリンクをクリックさせること、及び販売を行うことを含む。ペナルティが課されるべき消極的な商慣行の例は、例えば、会社、製品、消費者を貶めるコメントを行うことを含む。同様に、紛争解決の結果は、例えば、セッションに続く顧客満足度調査に基づいてよい。

ひとたび問い合わせが解決され、報酬値が決定されると、報酬は、エージェントに属するアカウントにクレジットされる。１つの実施形態において、報酬は、直接的な金銭的価値を有してよく、報酬ストア３２６を介して現金、商品、及び／又は割引と交換されてよい。別の実施形態において、報酬は、直接的な金銭的価値を持たないトークン又はクレジットであってよいが、１つ以上のデジタルアイテム又はガチャスタイルゲームで交換されて、ストア３２６を介してルートボックス／景品箱が受け取られてよい。このルートボックスは、例えば、ユーザのアカウントを飾るために及び／又はユーザに属するアバターと共に表示されるために使用されてよい、異なる希少価値の１つ以上のデジタルアイテムを含んでよい。１つの実施形態において、ガチャスタイルゲームは、エージェントが、１つ以上のデジタル収集物(デジタルコレクタブル)(digital collectables)を受信することを可能にしてよく、１つ以上のデジタル収集物は、それらの希少価値を確実にするために、ブロックチェーン台帳（すなわち、デジタル収集物が分散型ブロックチェーン台帳に格納されたトークンに直接対応する場所）に一意に格納／識別／検証されてよい。さらなる拡張において、このデジタル収集物は、その全文が開示の全てについて参照により援用される２０１９年１２月９日に出願された米国特許出願第１６／７０７，７４１号に記載されているように、ユーザのキャラクタ又はゲームプレイの属性を改良するために１つ以上のビデオゲームアプリケーションで使用することができてよい。

図１０に示すアーキテクチャのさらなる拡張では、１つの実施形態において、各エージェントは、（図７に示すユーザインターフェースの左上隅に示すような）ユーザに対するエージェントの前向きイメージとして作用することがあるアバターを有してよい。１つの実施形態において、アバターの１つ以上の属性は、エージェントのスコアリングされた技術的専門知識に従って進化してよく或いは存在してよい。例えば、エージェントがランニングについてより精通するようになるにつれて、アバターは、異なる又はより希少なランニングシューズを獲得することがある。幾つかの実施形態において、エージェントによるアバター装飾（衣服、アクセサリ、活動、シーンなど）の選択は、エージェントの関心についての洞察を提供することがあり、それはユーザの問い合わせをルーティングする際に更に役立つことがある。

更に別の実施形態において、本システムは、ユーザが、例えば、Ｎｉｋｅ Ｉｎｃ．によって商品化されているＮＩＫＥＩＤ（登録商標）又はＮＩＫＥ ＢＹ ＹＯＵ（登録商標）システムのようなウェブインターフェースを介して、カスタム製品（例えば、靴又はアパレル製品）を設計するのを支援するために使用されてよい。ユーザが支援又は創造的刺激を必要とするならば、ユーザは、本システムを介してライブエージェントと接続する選択肢を有してよい。同様に、ユーザが所定の量の時間よりも多くの時間に亘って特定の設計上の選択を思案したり、所定の回数よりも多くそれらの選択を変更したりするならば、自動化エージェント３２は、消費者が苦労しているのを見ることがあり、自動的に設計エージェントに支援を通知することがある。次に、接続されたライブエージェントは、ユーザとチャットして、設計を支援したり、ユーザのＵＩ制御を引き継いだり、或いはユーザと更に関わるためにビデオチャットセッションを開いたりするという選択肢を有してよい。加えて、ユーザが製品を設計しているときに、ユーザインターフェース／体験を記録することができ、次に、それは消費者によって彼らのソーシャルネットワークに共有される時間経過ビデオに変換されてよく、或いは、それは消費者を次回により良く支援することができる記録としてエージェントによって使用されることができる。幾つかの実施形態では、消費者及び後続のユーザのための作成体験をどのように改善するかについて更に学習するために、データがビデオから抽出されてよい。

上述の開示は、主として小売／顧客サービスのコンテキストに焦点を当てているが、現在の機能性のこの例は、本技術を不必要に制約するように解釈されるべきではない。代わりに、それはビジネス－消費者通信を容易にするために使用される本技術の一例である。しかしながら、他の例において、本技術は、会社間の通信（例えば、ＯＥＭと通信する供給ベース）を管理するために、或いは単一組織（例えば、マネージャ及びそのチーム）内の個人間の通信を管理するためにさえも使用されてよい。

これらのビジネス－ビジネスの例において、通信の方法は、しばしば、小売／顧客サポートのコンテキストとそれほど変わらない。従業員、プロジェクトチーム、及びサプライヤは、ＳＭＳ／ＭＭＳメッセージング、ＩＰベースのチャットシステム、他のそのような通信手段を含む、新しい通信方法を探している。明示的な応答時間は同じ程度には当て嵌まらないことがあるが、会話運動量の概念は、個人の応答優先順位を管理するために類似の方法で使用されてよい（すなわち、スーパーバイザーが同期的にテキストすることは、高い速度及び高い質量の両方を有することがあるのに対し、電子メールを通じてピザランチのＲＳＶＰを求めるオフィスマネージャは、低い質量及び低い速度を有することがある）。自動化された応答の類似の概念は、ビジネス内又はビジネス間のコンテキストにおいても同様に当て嵌まることがある。

本システムのさらなる拡張では、ルーティングエンジン２８及び自動化エージェント３２は永続的であることがあり、各メッセージが受信されるときに各メッセージを処理することがあるので、本システムはマクロレベルの問題及び傾向を決定するのに特に適している。更に、システムはユーザの特性を理解するので、それは問題／傾向を推進している人口統計、関心、及び／又は地理的領域を識別するように構成されてよい。いずれのインスタンスにおいても、このリアルタイム情報は、会社が消費者のニーズ及び／又は要求をより良く満たすように旋回すること（例えば、問題を解決するためにメッセージを微調整すること、トレンドにより迅速に対応するよう開発／製品計画を変更すること）を可能にする、同様に、エージェント３２は、特定の回答タイプに対するユーザ応答及び満足度を評価するために（すなわち、ライブエージェントの関与の前に）適切に位置付けられてよい。このマクロレベルの理解により、自動化エージェント３２は、より大きなユーザの満足感に向かって推進するよう、その応答戦略を経時的に適応させてよい。加えて、自動化エージェント３２は、ユーザに直接応答する能力を向上させるための及び／又はライブエージェントに意味のある示唆された応答を提供する能力を向上させるためのトレーニングデータとして、ユーザに対する実際のライブエージェント応答を使用してよい。このトレーニングデータは、更に、ライブエージェントの相対的ランク又は顧客サービススコアに従って重み付けられてよく、その場合、より熟練したエージェントの応答は、熟練度のより少ないエージェントの応答よりも、トレーニングデータセットにおいてより大きな重みを有する。

１つの実施形態において、自動化エージェント３２は、適切なトーンを有する自然言語応答を生成する目的で、定義されたパーソナリティを有することがある。例えば、本システムが運動用品／機器ブランドをサポートするために使用されるならば、自動化エージェント３２は、２５～３０歳の大学卒業後のＤ１運動選手（例えば、全米ランナー）、ＤＮＡレベルの運動選手であるが、オフィスでは誇大な獣、熱心なブランド支持者／大使、排他的なスニーカーに対処するが、ソーシャルメディアからスポーツの分野まで貴方のキック(kicks)を着用すべきだと信じる人、誰がＧＯＡＴであるか及びきついワークアウトの後の最良の食事が何であるかについて真剣な意見を持っている人、ウィットの利く人、小生意気な人、長く続く身内のジョークを培うプロ、決して貴方を論破しないが、非常に情熱的で、かつ非常に自信がある（傲慢でない）友人、普段通りであるが、常軌を逸しない人、高級な愛を祝う人に似るように構成されてよい。他の人格タイプも使用されてよい。最後に、自動化エージェントは、ユージンのような名前を有することがあるが、それをよく知っている人はそれを単にロッコと呼ぶことがある。

本開示の態様は、幾つかの実施形態では、本明細書に記載するコントローラ又はコントローラの変形のいずれかによって実行されるソフトウェアアプリケーション又はアプリケーションプログラムと一般的に呼ばれる、プログラムモジュールのような、命令のコンピュータ実行可能プログラムを通じて実装されてよい。ソフトウェアは、非限定的な例において、特定のタスクを実行する或いは特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、及びデータ構造を含むことがある。ソフトウェアは、コンピュータが入力ソースに従って反応することを可能にするインターフェースを形成することがある。ソフトウェアは、他のコードセグメントと協働して、受信したデータのソースと共に受信したデータに応答して様々なタスクを開始してもよい。ソフトウェアは、ＣＤ－ＲＯＭ、磁気ディスク、バブルメモリ、及び半導体メモリ（例えば、様々なタイプのＲＡＭ又はＲＯＭ）のような、様々なメモリ媒体のいずれかに格納されてよい。

その上、本開示の態様は、マルチプロセッサシステム、マイクロプロセッサベース又はプログラマブル消費者電子機器、ミニコンピュータ、メインフレームコンピュータ、及び同等物を含む、様々なコンピュータシステム及びコンピュータネットワーク構成で実施されてよい。加えて、本開示の態様は、タスクが通信ネットワークを通じてリンクされる常駐及び遠隔処理デバイスによって実行される分散コンピューティング環境において実施されてよい。分散コンピューティング環境において、プログラムモジュールは、メモリ記憶装置を含むローカル及び遠隔コンピュータ記憶媒体の両方に配置されてよい。従って、本開示の態様は、コンピュータシステム又は他の処理システムにおいて、様々なハードウェア、ソフトウェア又はそれらの組み合わせに関連して実装されることがある。

１つの構成において、図１の様々な態様は、デジタル情報のフロー及び処理を管理するように動作する１つ以上のサーバクラスコンピューティングデバイスを含む、分散型のクラウドベースのコンピューティングインフラストラクチャ内に実行可能なコードとして実装されてよい。図７に示すようなユーザディスプレイは、例えば、専用アプリケーション又はインターネットブラウザを介して、ユーザデバイス上で見ることがある。図７のユーザディスプレイ内を占める情報は、例えば、図１を実施するために使用されるサーバクラスコンピューティングデバイスによって提供されてよい。ここに記載するシステムを具体化及び／又は実装するために、他のハードウェア又はコンピュータ構成が使用されてよいことが理解されるべきである。

本明細書に記載する方法のいずれも、（ａ）プロセッサ、（ｂ）コントローラ、及び／又は（ｃ）任意の他の適切な処理デバイスによる実行のための機械可読命令を含んでよい。本明細書に開示する任意のアルゴリズム、ソフトウェア、制御論理、プロトコル又は方法は、例えば、フラッシュメモリ、ＣＤ－ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）、又は他のメモリデバイスのような、有形媒体に格納されたソフトウェアとして具現されてよい。代替的に、全体的なアルゴリズム、制御論理、プロトコル、又は方法及び／又はそれらの一部は、コントローラ以外のデバイスによって実行されてよく、且つ／或いは、利用可能な方法においてファームウェア又は専用ハードウェアで具現されてよい（例えば、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブル論理デバイス（ＦＰＬＤ）、個別論理などによって実施されてよい）。更に、特定のアルゴリズムが、本明細書に示すフローチャートを参照して記載されるが、例示的な機械可読命令を実装する多くの他の方法が代替的に使用されてよい。

本技術のさらなる開示は、以下の条項において提供される。

条項１。メッセージングエンジンと、ルーティングエンジンと、キューマネージャとを含み、メッセージングエンジンは、メッセージングエンジンと通信する複数の異なるメッセージングサービスのいずれかを通じてユーザから複数のテキストメッセージを受信するように作動し、複数のテキストメッセージはメッセージスレッドを形成し、返事を要求する少なくとも１つのクエリを含み、ルーティングエンジンは、複数のテキストメッセージの運動量を決定して、エージェントと関連付けられるメッセージキューにメッセージスレッドを割り当てるように作動し、キューマネージャは、少なくとも１つのクエリに返事を提供する応答時間目標を特定するように作動し、応答時間目標は、決定する運動量に反比例する、マルチチャネル通信プラットフォーム。

条項２。複数の異なるメッセージングサービスは、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、プッシュ通知サービス、インターネットプロトコル（ＩＰ）メッセージングサービス、又は電子メールサービスのうちの少なくとも２つを含む、条項１に記載のマルチチャネル通信プラットフォーム。

条項３。ルーティングエンジンは、自動化エージェントであり、自動化エージェントは、少なくとも１つのクエリのコンテキストを理解するように構成される自然言語応答エンジンを含む、条項１又は２に記載のマルチチャネル通信プラットフォーム。

条項４。自動化エージェントは、少なくとも１つのクエリのうちの第１に受信するクエリに応答するように構成される、条項３に記載のマルチチャネル通信プラットフォーム。

条項５。運動量は、メッセージスレッドの質量及び速度の関数であり、メッセージスレッドの質量は、メッセージスレッドの緊急性の尺度であり、速度は、複数のテキストメッセージが受信される速さの尺度である、条項１～４のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項６。メッセージキューは、複数のメッセージスレッドを含み、各メッセージスレッドは、異なる運動量値を有し、メッセージキューは、最大運動量を有し、メッセージキュー内の複数のメッセージスレッドの各メッセージスレッドからの運動量値の合計が、最大運動量よりも少ない、条項１～５のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項７。マルチチャネル通信プラットフォームは、エージェントインターフェースを更に含み、エージェントインターフェースは、ライブエージェントと関連付けられるメッセージキューの表現と、メッセージスレッドを表示し、ライブエージェントから返事を受信するように作動する、アクティブチャットスレッドと、ユーザについての情報を表示するように作動するサポートウィンドウと、を含む、条項１～６のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項８。ルーティングエンジンは、自動化エージェントを含み、自動化エージェントは、クエリを分析して、サポートウィンドウを介してライブエージェントに１つ以上の提案された応答を提供するように作動する、条項７に記載のマルチチャネル通信プラットフォーム。

条項９。自動化エージェントは、メッセージスレッドを分析し、応答して、製品が販売のために提供されるインターネットウェブページへのハイパーリンクを提供するように作動し、製品は、メッセージスレッド内で参照される、条項８に記載のマルチチャネル通信プラットフォーム。

条項１０。マルチチャネル通信プラットフォームは、利用可能な製品在庫のデータベースを更に含み、自動化エージェントは、製品が利用可能な製品在庫内に存在する場合にのみ、ハイパーリンクを提供するように作動する、条項９に記載のマルチチャネル通信プラットフォーム。

条項１１。ハイパーリンクは、ライブエージェントによってアクティブチャットスレッドにコピーされることができる、条項９又は１０に記載のマルチチャネル通信プラットフォーム。

条項１２。ユーザについての情報は、ユーザの製品嗜好、ユーザのサイズ、ユーザの最近の閲覧履歴の表示、ユーザの製品関心の表示、ユーザの消費パターンの表示、ライブエージェントとユーザとの間の以前のメッセージスレッドの要約、ユーザタグ付き製品の要約、又はユーザの購買履歴の要約のうちの少なくとも１つを含む、条項７～１１のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項１３。メッセージキューは、複数のメッセージスレッドを含み、各メッセージスレッドは、異なるそれぞれのユーザを有する複数のテキストメッセージを含む、条項７～１２のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項１４。キューマネージャは、クエリに対する応答に続いて、エージェントに報酬を提供するように作動する、条１～１３のうちのいずれか１つに記載のマルチチャネル通信プラットフォーム。

条項１５。報酬は、デジタル通貨を含み、プラットフォームは、ユーザに表示されるように作動するエージェントを表すアバターと、デジタル通貨の代わりにアバターと共に表示するためのデジタル装飾を提供するように作動するデジタル報酬ストアと、を更に含む、条項１４に記載のマルチチャネル通信プラットフォーム。

条項１６。デジタル装飾は、分散型ブロックチェーン台帳に格納されるトークンに一意に保管される、条項１５に記載のマルチチャネル通信プラットフォーム。

条項１７。ユーザとライブ顧客サービスエージェントとの間のテキスト交換を容易にする顧客サービスシステムであって、顧客サービスシステムは、メッセージングエンジンと、ルーティングエンジンとを含み、メッセージングエンジンは、メッセージングエンジンと通信する複数の異なるメッセージングサービスのいずれかを通じてユーザから複数のテキストメッセージを受信するように作動し、複数のテキストメッセージは、メッセージスレッドを形成し、返事を要求する少なくとも１つのクエリを含み、ルーティングエンジンは、メッセージスレッドを分析して、ユーザ、メッセージスレッド、又はクエリのうちの少なくとも１つに関連する補助情報をライブ顧客サービスエージェントに提供するように作動する、自動化エージェントを含む、顧客サービスシステム。

条項１８。自動化エージェントは、少なくとも１つのクエリのコンテキストを理解するように構成される自然言語応答エンジンを含む、条項１７に記載の顧客サービスシステム。

条項１９。顧客サービスシステムは、エージェントインターフェースを更に含み、エージェントインターフェースは、メッセージスレッドを表示し、ライブエージェントから回答を受信するように作動する、アクティブチャットスレッドと、補助情報を表示するように作動するサポートウィンドウとを含む、条項１７又は１８に記載の顧客サービスシステム。

条項２０。自動化エージェントは、クエリを分析するように作動し、補助情報は、クエリに対する１つ以上の提案される応答を含む、条項１７～１９のうちのいずれか１つに記載の顧客サービスシステム。

条項２１。補助情報は、製品が販売のために提供されるインターネットウェブページへのハイパーリンクを含み、製品は、メッセージスレッド内で参照される、条項１７～２０のうちのいずれか１つに記載の顧客サービスシステム。

条項２２。顧客サービスシステムは、利用可能な製品在庫のデータベースを更に含み、自動化エージェントは、製品が利用可能な製品在庫内に存在する場合にのみ、ハイパーリンクを提供するように作動する、条項２１に記載の顧客サービスシステム。

条項２３。補助情報は、ユーザの製品嗜好、ユーザのサイズ、ユーザの最近の閲覧履歴の表示、ユーザの製品関心の表示、ユーザの消費パターンの表示、ライブエージェントとユーザとの間の以前のメッセージスレッドの要約、ユーザタグ付き製品の要約、又はユーザの購買履歴の要約のうちの少なくとも１つを含む、条項１７～２２のうちのいずれか１つに記載の顧客サービスシステム。

Claims (16)

1. メッセージングエンジンと、
   ルーティングエンジンと、
   キューマネージャと、を含み、
   前記メッセージングエンジンは、前記メッセージングエンジンと通信する複数の異なるメッセージングサービスのいずれかを通じてユーザから複数のテキストメッセージを受信するように作動し、該複数のテキストメッセージは、メッセージスレッドを形成し、返事を要求する少なくとも１つのクエリを含み、
   前記ルーティングエンジンは、前記複数のテキストメッセージの運動量を決定して、エージェントと関連付けられるメッセージキューに前記メッセージスレッドを割り当てるように作動し、
   前記キューマネージャは、前記少なくとも１つのクエリに前記返事を提供する応答時間目標を特定するように作動し、該応答時間目標は、前記決定する運動量に反比例する、
   マルチチャネル通信プラットフォーム。
2. 前記複数の異なるメッセージングサービスは、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、プッシュ通知サービス、インターネットプロトコル（ＩＰ）メッセージングサービス、又は電子メールサービスのうちの少なくとも２つを含む、請求項１に記載のマルチチャネル通信プラットフォーム。
3. 前記ルーティングエンジンは、自動化エージェントであり、該自動化エージェントは、前記少なくとも１つのクエリのコンテキストを理解するように構成される自然言語応答エンジンを含む、請求項１に記載のマルチチャネル通信プラットフォーム。
4. 前記自動化エージェントは、前記少なくとも１つのクエリのうちの第１に受信するクエリに応答するように構成される、請求項３に記載のマルチチャネル通信プラットフォーム。
5. 前記運動量は、前記メッセージスレッドの質量及び速度の関数であり、前記メッセージスレッドの前記質量は、前記メッセージスレッドの緊急性の尺度であり、前記速度は、前記複数のテキストメッセージが受信される速さの尺度である、請求項１に記載のマルチチャネル通信プラットフォーム。
6. 前記メッセージキューは、複数のメッセージスレッドを含み、各メッセージスレッドは、異なる運動量値を有し、
   前記メッセージキューは、最大運動量を有し、
   前記メッセージキュー内の前記複数のメッセージスレッドの各メッセージスレッドからの前記運動量値の合計が、前記最大運動量よりも少ない、
   請求項１に記載のマルチチャネル通信プラットフォーム。
7. エージェントインターフェースを更に含み、該エージェントインターフェースは、
   ライブエージェントと関連付けられる前記メッセージキューの表現と、
   前記メッセージスレッドを表示し、前記ライブエージェントから前記返事を受信するように作動する、アクティブチャットスレッドと、
   前記ユーザについての情報を表示するように作動するサポートウィンドウと、を含む、
   請求項１に記載のマルチチャネル通信プラットフォーム。
8. 前記ルーティングエンジンは、自動化エージェントを含み、該自動化エージェントは、前記クエリを分析して、前記サポートウィンドウを介して前記ライブエージェントに１つ以上の提案された応答を提供するように作動する、請求項７に記載のマルチチャネル通信プラットフォーム。
9. 前記自動化エージェントは、前記メッセージスレッドを分析し、応答して、製品が販売のために提供されるインターネットウェブページへのハイパーリンクを提供するように作動し、前記製品は、前記メッセージスレッド内で参照される、請求項８に記載のマルチチャネル通信プラットフォーム。
10. 利用可能な製品在庫のデータベースを更に含み、前記自動化エージェントは、前記製品が前記利用可能な製品在庫内に存在する場合にのみ、前記ハイパーリンクを提供するように作動する、請求項９に記載のマルチチャネル通信プラットフォーム。
11. 前記ハイパーリンクは、前記ライブエージェントによって前記アクティブチャットスレッドにコピーされることができる、請求項９に記載のマルチチャネル通信プラットフォーム。
12. 前記ユーザについての前記情報は、前記ユーザの製品嗜好、前記ユーザのサイズ、前記ユーザの最近の閲覧履歴の表示、前記ユーザの製品関心の表示、前記ユーザの消費パターンの表示、ライブエージェントと前記ユーザとの間の以前のメッセージスレッドの要約、ユーザタグ付き製品の要約、又は前記ユーザの購買履歴の要約のうちの少なくとも１つを含む、請求項７に記載のマルチチャネル通信プラットフォーム。
13. 前記メッセージキューは、複数のメッセージスレッドを含み、各メッセージスレッドは、異なるそれぞれのユーザを有する複数のテキストメッセージを含む、請求項７に記載のマルチチャネル通信プラットフォーム。
14. 前記キューマネージャは、前記クエリに対する応答に続いて、前記エージェントに報酬を提供するように作動する、請求項１に記載のマルチチャネル通信プラットフォーム。
15. 前記報酬は、デジタル通貨を含み、
    当該マルチチャネル通信プラットフォームは、
    前記ユーザに表示されるように作動する前記エージェントを表すアバターと、
    前記デジタル通貨の代わりに前記アバターと共に表示するためのデジタル装飾を提供するように作動するデジタル報酬ストアと、を更に含む、
    請求項１４に記載のマルチチャネル通信プラットフォーム。
16. 前記デジタル装飾は、分散型ブロックチェーン台帳に格納されるトークンに一意に保管される、請求項１５に記載のマルチチャネル通信プラットフォーム。

Images