▶ キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-13
(45)【発行日】2023-12-21
(54)【発明の名称】顧客サポート呼の第２の要素認証のためのシステムおよび方法
(51)【国際特許分類】
G06F 21/31 20130101AFI20231214BHJP
G06F 21/35 20130101ALI20231214BHJP
【ＦＩ】
G06F21/31
G06F21/35
【請求項の数】
19
【外国語出願】
(21)【出願番号】P 2023069473
(22)【出願日】2023-04-20
(62)【分割の表示】P 2021542373の分割
【原出願日】2020-03-17
(65)【公開番号】P2023089249
(43)【公開日】2023-06-27
【審査請求日】2023-04-27
(31)【優先権主張番号】16/357,266
(32)【優先日】2019-03-18
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】519111877
【氏名又は名称】キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー
【氏名又は名称原語表記】Ｃａｐｉｔａｌ Ｏｎｅ Ｓｅｒｖｉｃｅｓ， ＬＬＣ
(74)【代理人】
【識別番号】100145403
【弁理士】
【氏名又は名称】山尾 憲人
(74)【代理人】
【識別番号】100135703
【弁理士】
【氏名又は名称】岡部 英隆
(72)【発明者】
【氏名】イリンチック，ライコ
(72)【発明者】
【氏名】ニューマン，ケイトリン
(72)【発明者】
【氏名】ルール，ジェフリー
【審査官】宮司 卓佳
(56)【参考文献】
【文献】特開２００８－１８６３２１（ＪＰ，Ａ）
【文献】特開２００２－３６６８６８（ＪＰ，Ａ）
【文献】特開２０１２－０４８３４８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ２１／３１－２１／４６
(57)【特許請求の範囲】
【請求項1】
デバイスと顧客サポートサービスとの間の第１の通信チャネルをサポートするように構成されたインターフェースであって、前記第１の通信チャネルは、前記デバイスによるアクセス要求を前記顧客サポートサービスに転送するように構成され、前記アクセス要求は、前記デバイスに関連付けられたクライアントに関連する前記顧客サポートサービスの情報を求める、インターフェースと、前記インターフェースは、前記デバイスと認証サーバとの間の第２の通信チャネルをサポートするように構成され、前記第２の通信チャネルは、前記アクセス要求の検証のために前記顧客サポートサービスから前記認証サーバへの要求に応答して、前記認証サーバによって確立され、
前記第２の通信チャネルを介した前記認証サーバからの認証要求に応答して、前記クライアントに関連付けられた非接触カードから暗号文を取得するように構成された近距離無線通信インターフェースであって、前記暗号文は、前記非接触カードに格納された鍵およびカウンタ値を使用して、前記非接触カードによって生成される、近距離無線通信インターフェースと、
前記インターフェースは、前記第２の通信チャネルを介して前記暗号文を前記認証サーバに転送するように構成され、前記認証サーバが、前記クライアントのために前記認証サーバによって格納された格納された鍵および格納されたカウンタ値を使用して、前記暗号文を検証することを可能にし、
生成された前記第２の通信チャネルは、前記クライアントの事前に検証された連絡先情報を使用して、前記認証サーバによって生成される、デバイス。
【請求項2】
前記第１の通信チャネルは、前記デバイスと前記顧客サポートサービスとの間の第１の要素認証交換に続いて、前記デバイスと前記顧客サポートサービスとの間で確立されたアプリケーションセッションを含む、請求項１に記載のデバイス。
【請求項3】
前記第２の通信チャネルは、非接触カード暗号文要求、ショートメッセージサービス（ＳＭＳ）コード要求、アプリケーション内通知、またはそれらの組み合わせを含む第２の要素認証要求を配信する、請求項１に記載のデバイス。
【請求項4】
前記非接触カードに格納されている前記カウンタ値は、前記顧客サポートサービスにアクセスするたびに変化する、請求項１に記載のデバイス。
【請求項5】
前記暗号文は、前記カウンタ値を使用して、前記非接触カードのメモリに格納された暗号文生成アプレットによって生成される、請求項１に記載のデバイス。
【請求項6】
前記事前に検証された連絡先情報は、インターネットモバイル機器識別子（ＩＭＥＩ）、事前に検証されたデバイスの電話番号、電子メールアドレス、またはそれらの組み合わせを含む、請求項１に記載のデバイス。
【請求項7】
前記第１の通信チャネルは、アプリケーションセッション識別子を含む、請求項２に記載のデバイス。
【請求項8】
前記第２の通信チャネルは、前記アプリケーションセッション識別子を使用してさらに確立される、請求項７に記載のデバイス。
【請求項9】
前記認証サーバは、前記クライアントの認証レベルを含むクライアントデータを格納し、前記認証サーバは、前記クライアントの前記認証レベルを前記アクセス要求によって求められる情報のアクセスレベルと比較することによって、前記アクセス要求を選択的に検証する、請求項１に記載のデバイス。
【請求項10】
前記認証サーバによって格納される前記クライアントデータは、アカウント情報、パスワード、アドレス、および／または電話番号を含み、前記アクセス要求は、読み取り要求または変更要求を含む、請求項９に記載のデバイス。
【請求項11】
クライアントのデバイスと顧客サポートサービスとの間の通信を保護するための方法であって、前記方法は、前記デバイスが、前記デバイスと前記顧客サポートサービスとの間に第１の通信チャネルを確立することであって、前記第１の通信チャネルは、前記クライアントに関連する前記顧客サポートサービスの情報へのアクセス要求をサポートする、ことと、
前記デバイスが、前記クライアントと前記顧客サポートサービスの間で第１の要素認証情報の交換を実行することと、
前記デバイスが、前記デバイスと前記顧客サポートサービスとの間で確立されたアプリケーションセッションを確立することと、
前記デバイスが、前記デバイスと前記顧客サポートサービスとの間で確立されたアプリケーションセッションを使用して、前記アクセス要求を前記顧客サポートサービスに転送することであって、前記アプリケーションセッションは、セッション識別子を含む、ことと、
前記デバイスが、認証サーバから、前記デバイスの第２の通信チャネルを介して、前記認証サーバからの第２の要素認証要求を受信することと、
前記クライアントの非接触カードが、前記クライアントの非接触カードに格納されている鍵とカウンタから形成される暗号文を形成することと、
前記デバイスが、前記第２の要素認証要求に応答して、前記デバイスの近距離無線通信インターフェースを介して、前記クライアントの非接触カードから暗号文を取得することと、
前記デバイスが、前記第２の通信チャネルを介して、前記暗号文を前記認証サーバに転送することと、
前記認証サーバが、前記クライアントの格納された鍵と格納されたカウンタに応答して、前記暗号文と、前記認証サーバによって生成された期待される暗号文との一致を決定することと、
前記デバイスが、前記第１の通信チャネルを介して、前記アクセス要求に関連する情報を受信することと、
のステップを含む方法。
【請求項12】
前記第２の通信チャネルは、前記第１の通信チャネルのセッション識別子を使用して確立される、請求項１１に記載の方法。
【請求項13】
前記第２の通信チャネルは、前記クライアントの事前に検証された連絡先情報および前記第１の通信チャネルの前記セッション識別子を使用して生成される、請求項１２に記載の方法。
【請求項14】
前記方法は、前記事前に検証された連絡先情報を使用して確立された第３の通信チャネルを使用して、前記デバイスによって前記アクセス要求の通知を受信するステップをさらに含む、請求項１３に記載の方法。
【請求項15】
前記事前に検証された連絡先情報は、インターネットモバイル機器識別子（ＩＭＥＩ）、および事前に検証されたクライアントデバイスの電話番号、前記クライアントの電子メールアドレス、またはそれらの組み合わせを含む、請求項１３に記載の方法。
【請求項16】
前記第２の通信チャネルで転送される前記第２の要素認証要求は、非接触カード暗号文要求、ショートメッセージサービス（ＳＭＳ）コード要求、アプリケーション内通知、またはそれらの組み合わせを含む、請求項１５に記載の方法。
【請求項17】
前記非接触カードに格納された前記カウンタおよび認証サーバ変更の格納されたカウンタは、前記クライアントによるアクセス要求ごとにそれぞれ動的に更新される、請求項１１に記載の方法。
【請求項18】
前記クライアントの前記非接触カードから前記暗号文を取得するステップは、前記非接触カードに格納された暗号文生成アプレットの近距離無線通信読み取り操作を発行するステップを含む、請求項１１に記載の方法。
【請求項19】
顧客サポートサービスによって格納されたクライアント情報に対してアクセス要求を検証するための方法であって、前記方法は、クライアントのデバイスが、前記デバイスと前記顧客サポートサービスとの間に第１の通信チャネルを確立することであって、前記第１の通信チャネルは、前記クライアントに関連する前記顧客サポートサービスの情報へのアクセス要求をサポートする、ことと、
前記デバイスが、前記クライアントと前記顧客サポートサービスの間で第１の要素認証情報の交換を実行することと、
前記デバイスが、前記デバイスと前記顧客サポートサービスとの間のアプリケーションセッションを確立することと、
前記デバイスが、前記アプリケーションセッションを使用して、前記アクセス要求を前記顧客サポートサービスに転送することであって、前記アプリケーションセッションは、セッション識別子を含む、ことと、
前記デバイスが、前記セッション識別子を使用して、認証サーバによって確立された認証サーバから、前記デバイスの第２の通信チャネルを介して、前記認証サーバからの第２の要素認証要求を受信することであって、前記第２の通信チャネルは、前記セッション識別子および前記クライアントの事前に検証された連絡先情報を使用して生成される、ことと、
前記デバイスが、前記クライアントの前記事前に検証された連絡先情報を使用して確立された第３の通信チャネルを介して、前記アクセス要求の通知を受信することと、
前記クライアントの非接触カードが、アクセス要求毎に変化する前記非接触カードに保存された鍵及び動的カウンタとから形成される暗号文を形成することと、
前記デバイスが、前記第２の要素認証要求に応答して、前記デバイスの近距離無線通信インターフェースを介して、前記クライアントの非接触カードから前記暗号文を取得することと、
前記デバイスが、前記第２の通信チャネルを介して、前記暗号文を前記認証サーバに転送することと、
前記認証サーバが、前記クライアントのために格納された鍵と格納されたカウンタに応答して、前記暗号文と、前記認証サーバによって生成された期待される暗号文との間の一致を決定することと、
前記デバイスが、前記第１の通信チャネルを介して、前記アクセス要求に関連する情報を受信することと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願
この出願は、２０１９年３月１８日に出願された「顧客サポート呼の第２の要素認証のためのシステムおよび方法」という名称の米国特許出願第１６／３５７，２６６号の優先権を主張する。前述の出願の内容は、その全体が参照により本明細書に援用される。
この出願は、２０１９年３月１８日に出願された「顧客サポート呼の第２の要素認証のためのシステムおよび方法」という名称の米国特許出願第１６／３５７，２６６号の優先権を主張する。前述の出願の内容は、その全体が参照により本明細書に援用される。
【背景技術】
【0002】
コールセンタサービスは通常、クライアントがアカウントにアクセス、変更、削除、またはその他の方法で制御できるようにするために、サービスプロバイダによって提供される。セキュリティの観点から、コールセンタのトランザクションは、機密の顧客情報を悪意のある第三者に公開し得るため、コールセンタは、企業の最もリスクの高い領域になり得る。顧客コールセンタで特定の日に受信される呼の最大９０％は、顧客アカウントへの不適切なアクセスを試みている不正な発信者からのものである。
【0003】
これらのセキュリティ上の懸念に対処するために、支払いカード業界セキュリティ標準評議会（ＰＣＩ ＳＳＣ）は、支払いカード業界（ＰＣＩ）セキュリティ標準の継続的な進化を管理している。サービスプロバイダは、機密の顧客データを保護するためにＰＣＩ標準への準拠を実施する責任がある。例えば、ＰＣＩ標準は、クライアントが顧客アカウント情報にアクセスおよび／または変更することを許可する前に従うべき認証標準を指示し得る。コールセンタでは、パスワードの交換、個人的な質問への回答、生体認証データなどの形でクライアント認証が必要になり得る。しかしながら、認証技術は、情報や資金を盗もうとしてクライアントになりすますために、詐欺師が着信番号、電子メールアドレス、ＩＰアドレスなどをマスクまたは変更する「なりすまし」や「フィッシング」などの問題の影響を受けることがよくある。外部リスクは、顧客情報を盗む目的で、サービスプロバイダの通信、特に、コールセンタの通信を監視するハッカによっても引き起こされる。
【発明の概要】
【0004】
一態様によれば、情報アクセス要求を認証するためのデバイスは、顧客サービスエージェントから認証要求を受信するように構成された顧客サービスインターフェースであって、認証要求は、第１の通信チャネルを介してクライアントのデバイスから顧客サービスエージェントによって受信されたアクセス要求に関連付けられる、顧客サービスインターフェースを含む。認証要求は、デバイスがアクセス要求によって求められる情報へのアクセスを承認されているかどうかを決定するために使用され得る。デバイスはさらに、クライアントの事前検証された連絡先情報を備えるクライアントデータを格納するように構成されたストレージデバイスと、事前検証された連絡先情報を使用して確立された第２の通信チャネルを介して第２の要素認証要求をクライアントにプッシュするように構成されたクライアントインターフェースを含む。クライアントインターフェースは、クライアントから認証応答を受信するように構成し得る。第２の通信チャネルは、第１の通信チャネルとは異なり得る。デバイスは、第２の要素認証要求を生成するための、顧客サービスインターフェースとクライアントインターフェースに結合された認証サーバを含み、認証応答と格納されているクライアントデータの一致に応じて、アクセス要求によって求められる情報へのアクセスを選択的にロック解除する。
【0005】
他の態様によれば、顧客サービスエージェントが受信したアクセス要求を認証するための方法は、顧客サービスエージェントからの認証要求を受信することであって、認証要求は、第１の通信チャネルを介してクライアントのデバイスから前記顧客サービスエージェントによって受信されたアクセス要求に関連付けられるステップを含む。認証要求は、デバイスがアクセス要求によって求められる情報にアクセスできるかどうかを決定するために使用され得る。方法は、データストアからクライアントの事前検証された連絡先情報を含むクライアントデータを取得することと、事前検証された連絡先情報を使用して、第２の通信チャネルを介して認証要求をデバイスにプッシュすることのステップを含む。認証要求は、クライアントからの第２の要素認証の要求を備え得る。方法は、第２の通信チャネルを介してデバイスから第２の要素認証応答を受信することと、第２の要素認証応答を前記クライアントデータと比較することと、アクセス要求によって求められた情報へのアクセスを選択的にロック解除することを含む、比較のステップに応じてクライアントを選択的に認証することとのステップを含む。
【0006】
さらなる態様によれば、顧客サービスエージェントが受信した情報アクセス要求を認証するための方法は、顧客サービスエージェントからの認証要求の受信することであって、認証要求は、クライアントのデバイスからの第１の通信チャネルを介して顧客サービスエージェントによって受信されたアクセス要求に関連付けられるステップを含む。第１の通信チャネルは、セッション識別子を含み得、認証要求は、デバイスがクライアントアクセス要求によって求められる情報へのアクセスを許可されているかどうかを決定するために使用され得る。方法は、データストアからクライアントの事前検証されたクライアント連絡先情報を取得することと、事前検証されたクライアント連絡先情報を使用して確立された第２の通信チャネルを使用して認証要求をデバイスにプッシュすることのステップを含み得る。第２の通信チャネルは、第１の通信チャネルとは異なり得る。認証要求は、クライアントの非接触カードからの暗号文の要求を含み得、方法は、アクセス要求の認証することは、第２の通信チャネルを介してクライアントデバイスから暗号文を受信することを含み、クライアントに関連付けられた鍵のコピーを使用して暗号文を復号し、復号されたカウンタ情報を提供することと、復号されたカウンタ情報を、クライアントのために維持されているカウンタのコピーと比較することと、情報へのアクセスを選択的にロック解除することを含む、比較のステップに応じて、クライアントデバイスを選択的に認証することとのステップを含む。方法は、事前検証されたクライアント連絡先情報に応答して生成された第３の通信チャネルを使用してアクセス要求をクライアントに通知することであって、第３の通信チャネルは、第１および第２の通信チャネルの両方とは異なる、こととのステップをさらに含む。
【0007】
顧客データへのアクセスを許可する前に認証情報を交換するために異なる通信チャネルを使用すると、悪意のある当事者がすべてのクライアント通信インターフェースを中断できないため、機密の顧客情報が開示される可能性が低くなる。
【図面の簡単な説明】
【0008】
【図1A】例示的な実施形態に係る、顧客の要求を事前認証するように構成されたデータ伝送システムのブロック図である。
【図1B】例示的な実施形態に係る、認証されたアクセスを提供するためのシーケンスを示す図である。
【図9】事前認証されたサービス要求を受け入れるコールサービスセンタにおける例示的な呼処理パイプラインを示すブロック図である。
【図10】クライアントデータに提供され得る階層化されたセキュリティ制御を説明するために提供されるブロック図である。
【図11】一実施形態において、顧客サービスエージェントおよび認可サービスによって実行され得る例示的なステップを説明するために提供されるフロー図である。
【図12A】様々な実施形態において顧客サービスエージェントおよびクライアントに表示され得る例示的なグラフィックユーザインターフェース（ＧＵＩ）コンテンツを示している。
【図12B】様々な実施形態において顧客サービスエージェントおよびクライアントに表示され得る例示的なグラフィックユーザインターフェース（ＧＵＩ）コンテンツを示している。
【発明を実施するための形態】
【0009】
本開示のいくつかの実施形態の目的は、オズボーンらによって２０１８年１１月２９日に出願された「非接触カードの暗号化認証のためのシステムおよび方法」と題され、参照により本明細書に援用される米国特許出願第１６／２０５，１１９号（以下、１１９出願という）に記載されているように、１つまたは複数の非接触カードに組み込まれた１つまたは複数の鍵の使用である。非接触カードは、認証や、ユーザが非接触カードに加えて別の物理トークンを携帯する必要があるその他の多くの機能を実行するために使用され得る。非接触インターフェースを採用することにより、非接触カードは、ユーザのデバイス（携帯電話など）とカード自体との間で相互作用および通信するための方法を提供され得る。例えば、多くのクレジットカードトランザクションの基礎となるＥＭＶプロトコルは、Ａｎｄｒｏｉｄ（登録商標）のオペレーティングシステムには十分であるが、読み取り専用でのみ使用されるため、近距離無線通信（ＮＦＣ）の使用に関してより制限されているｉＯＳ（登録商標）には課題がある認証プロセスを含む。かなりの距離で動いているデバイスを読み取るために使用され得るＲＦＩＤとは異なる。１１９出願に記載されている非接触カードの例示的な実施形態は、ＮＦＣ技術を利用し得る。
【0010】
したがって、サービスプロバイダの多要素認証機能とインテリジェントな呼ルーティングを活用して、顧客コールセンタのセキュリティと効率を向上させるシステムおよび方法が開示されている。顧客サポート要求の事前認証により、呼処理中に機密の顧客データが悪用される可能性が低くなる。クライアントに一意に関連付けられた非接触カードは、認証の第２の要素を提供して、クライアントの悪意のある第三者のなりすましの可能性を減らし得る。事前承認された顧客サポート呼は、悪意のある呼の干渉や情報の盗難の機会を減らす方法で、インテリジェントかつ効率的にルーティングされる。
【0011】
他の態様によれば、顧客サービス要求の処理中に、顧客サービス担当者がクライアントをさらに認証することが有益であり得ることが認識されている。そのようなさらなる認証は、パスワードおよび連絡先情報を含む非常に機密性の高いデータの変更を許可する前、またはローンサービスなどの特定のサービスへのアクセスを許可する前を含む様々な理由で実行され得る。顧客が顧客サービスエージェント間で転送された場合、または顧客サービスエージェントがクライアント情報へのアクセスを求めるクライアントの信頼性に疑いを持った場合にも、さらなる認証が必要になり得る。
【0012】
一態様によれば、認証は、情報アクセスを要求するために使用されるもの以外の通信チャネルおよびプロトコルを使用して実行され得る。いくつかの実施形態では、通信チャネルは、サービスプロバイダによって事前に検証されたクライアントの連絡先情報を使用して確立される。いくつかの実施形態では、アクセスが許可された後、電子メールまたはテキストメッセージングなどの他の通信方法を使用して、クライアントにそのようなアクセスを通知し得る。認証の様々な段階で異なる通信チャネルとプロトコルを使用すると、悪意のある第三者が認証に使用される各通信媒体に同時に干渉することが困難になるため、悪意のある第三者の干渉の可能性が制限される。
【0013】
本発明のこれらおよび他の特徴は、図を参照して説明され、ここで、同様の参照番号は、全体を通して同様の要素を参照するために使用される。
【0014】
この出願で使用される「システム」、「コンポーネント」、および「ユニット」という用語は、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すことを意図しており、その例は、本明細書に記載されている。例えば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、ハードディスクドライブ、（光および／または磁気記憶媒体の）複数のストレージドライブ、オブジェクト、実行可能なもの、実行スレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。実例として、サーバ上で実行されているアプリケーションとサーバの両方は、コンポーネントであり得る。１つまたは複数のコンポーネントは、プロセスおよび／または実行スレッド内に配置され得、コンポーネントは、１つのコンピュータにローカライズされ、および／または２つ以上のコンピュータに分散され得る。
【0015】
さらに、コンポーネントは、動作を調整するために、様々なタイプの通信媒体によって互いに通信可能に結合され得る。調整には、一方向または双方向の情報交換が含まれ得る。例えば、コンポーネントは、通信媒体を介して通信される信号の形で情報を通信し得る。この情報は、様々な信号線に割り当てられた信号として実施され得る。このような割り当てでは、各メッセージは、信号である。しかしながら、さらなる実施形態は、代替的に、データメッセージを使用し得る。このようなデータメッセージは、様々な接続を介して送信され得る。例示的な接続には、パラレルインターフェース、シリアルインターフェース、およびバスインターフェースが含まれる。
【0016】
図１Ａは、ネットワーク１１５を介してサービスプロバイダ１２０に結合された１つまたは複数のクライアントデバイス１１０を含むシステム１００を示している。一態様によれば、クライアントデバイス１１０は、ネットワーク対応コンピュータを備え、ネットワーク１１５および１２５を介してサービスプロバイダ１２０と通信して、サービスプロバイダのコンテンツおよびサービスにアクセスする。
【0017】
本明細書で言及されるように、ネットワーク対応コンピュータは、例えば、コンピュータデバイス、または、例えば、サーバ、ネットワークアプライアンス、パーソナルコンピュータ（ＰＣ）、ワークステーション、モバイルデバイス、電話、ハンドヘルドＰＣ、携帯情報端末（ＰＤＡ）、シンクライアントデバイス、ファットクライアントデバイス、インターネットブラウザ、またはその他のデバイスを含む通信デバイスを含み得るが、これらに限定されない。
【0018】
したがって、クライアントデバイス１１０は、プロセッサおよびメモリを含み得、処理回路は、本明細書に記載の機能を実行するために必要に応じて、プロセッサ、メモリ、エラーおよびパリティ／ＣＲＣチェッカ、データエンコーダ、衝突防止アルゴリズム、コントローラ、コマンドデコーダ、セキュリティプリミティブ、および改ざん防止ハードウェアを含む追加のコンポーネントを含み得ることが理解される。クライアントデバイス１１０は、ディスプレイおよび入力デバイスをさらに含み得る。ディスプレイは、コンピュータモニタ、フラットパネルディスプレイ、および液晶ディスプレイ、発光ダイオードディスプレイ、プラズマパネル、およびブラウン管ディスプレイを含むモバイルデバイス画面などの視覚情報を提示するための任意のタイプのデバイスであり得る。入力デバイスは、タッチスクリーン、キーボード、マウス、カーソル制御デバイス、タッチスクリーン、マイク、デジタルカメラ、ビデオレコーダまたはカムコーダなど、ユーザのデバイスによって利用可能でサポートされている情報をユーザのデバイスに入力するための任意のデバイスを含み得る。これらのデバイスは、情報を入力し、本明細書に記載のソフトウェアおよび他のデバイスと相互作用するために使用され得る。
【0019】
１つまたは複数のクライアントデバイス１１０はまた、例えば、Ａｐｐｌｅ（登録商標）のｉＰｈｏｎｅ（登録商標）、ｉＰｏｄ（登録商標）、ｉＰａｄ（登録商標）、またはＡｐｐｌｅのｉＯＳ（登録商標）オペレーティングシステムを実行するその他のモバイルデバイス、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）モバイルオペレーティングシステムを実行する任意のデバイス、および／または他のスマートフォンまたは同様のウェアラブルモバイルデバイスなどのモバイルデバイスであり得る。
【0020】
図１Ａの様々なクライアントデバイス１１０は、携帯電話１４２、ラップトップ１４４、タブレット１４８、および端末１４６を含む。クライアントデバイス１１０は、サービスプロバイダ１２０との通信に特に適合されたシンクライアントアプリケーションを含み得る。シンクライアントアプリケーションは、クライアントデバイスのメモリに格納され、クライアントデバイスによって実行されたときに動作可能であり、クライアントデバイスとサービスプロバイダアプリケーションとの間のインターフェースを制御し、クライアントデバイスのユーザがサービスプロバイダコンテンツおよびサービスにアクセスできるようにし得る。
【0021】
いくつかの例では、ネットワーク１１５は、無線ネットワーク、有線ネットワーク、または無線ネットワークと有線ネットワークの任意の組み合わせのうちの１つまたは複数であり得、クライアントデバイス１１０をサービスプロバイダ１２０に接続するように構成され得る。例えば、ネットワーク１１５は、光ファイバネットワーク、パッシブ光ネットワーク、ケーブルネットワーク、インターネットネットワーク、衛星ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）、移動体通信のためのグローバルシステム、パーソナルコミュニケーションサービス、パーソナルエリアネットワーク、無線アプリケーションプロトコル、マルチメディアメッセージングサービス、拡張メッセージングサービス、ショートメッセージサービス、時間分割マルチプレックスベースのシステム、コード分割マルチアクセスベースのシステム、Ｄ－ＡＭＰＳ、Ｗｉ－Ｆｉ、固定無線データ、ＩＥＥＥ８０２．１１ｂ、８０２．１５．１、８０２．１１ｎおよび８０２．１１ｇ、ブルートゥース（登録商標）、ＮＦＣ、無線周波数識別（ＲＦＩＤ）、Ｗｉ－Ｆｉなどのうちの１つまたは複数を含み得る。
【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】
【表1】
【0064】
初期化後、非接触カードと認証サーバの両方が、カード所有者を一意に識別するための情報を格納する。これらの機能は、以下に説明するように、高リスクサービスへのクライアントアクセスを認証するための１つの態様に従って使用され得る。
【0065】
図５は、非接触カード５１０が、表１に含まれるような情報を格納し得、ユーザをサービスプロバイダの高リスクサービスに接続する前にユーザを認証するために使用され得る通信システムを示している。一態様では、「高リスクサービス」は、サービスが機密の顧客または他の情報を公開する機会があるため、多要素認証プロセスの恩恵を受け得るサービスである。図３に関して説明したように、各非接触カードは、識別子、鍵、乱数などのような１つまたは複数の一意に識別する属性を含む顧客情報５１８を格納するためのメモリ５１６を含み得る。一態様では、メモリは、本明細書で説明される認証プロセスを制御するためにマイクロプロセッサ５１２によって実行されるときに動作可能な認証アプレット５１７をさらに含む。さらに、各非接触カード５１０は、１つまたは複数のアプリケーショントランザクションカウンタ（ＡＴＣ）５１４、およびインターフェース５１５を含み得る。上記のように、一実施形態では、インターフェースは、ＮＦＣまたは他の通信プロトコルを動作する。
【0066】
クライアントデバイス５２０はまた、非接触カードと通信するためのカードインターフェース５２５、およびクライアントデバイス５２０が上記のような様々な通信プロトコルを使用してサービスプロバイダと通信することを可能にする１つまたは複数の他のネットワークインターフェース（図示せず）を含む。クライアントデバイスは、サービスプロバイダアプリケーションとクライアントデバイス５２０のユーザとの間の通信を可能にする、キーボードまたはタッチスクリーンディスプレイのうちの１つまたは複数を含み得るユーザインターフェース５２６をさらに含み得る。クライアントデバイス５２０はさらに、サービスプロバイダのアプリケーションへのアクセスおよび使用を容易にするためにサービスプロバイダによってクライアントに提供され得る、例えば、クライアント側アプリケーション５２３を含む、クライアントデバイス５２０の動作を制御する情報およびプログラムコードを格納するメモリ５２２を含む。一実施形態では、クライアント側アプリケーション５２３は、認証情報を非接触カード５１０からサービスプロバイダによって提供される１つまたは複数のサービスに通信するように構成されたプログラムコードを含む。クライアント側アプリケーション５２３は、ユーザインターフェース５２６に表示されるサービスプロバイダ（ＳＰ）アプリケーションインターフェース５２７で受信された入力を介して制御され得る。例えば、ユーザは、ＳＰアプリケーションインターフェース５２７の一部として提供されるアイコン、リンク、または他のメカニズムを選択して、クライアント側アプリケーションを起動して、ＳＰアプリケーションサービスにアクセスし得る。
【0067】
図１Ａに関して述べたように、クライアントデバイス５２０は、顧客関係管理（ＣＲＭ）サーバ５４０および認証サーバ５５０を含む、サービスプロバイダ５０５によって提供される様々なサービスに接続され得る。一実施形態では、ＣＲＭサーバ５４０は、受信されたサポート呼のルーティングおよび受信された呼の呼処理パイプライン５４２への転送を管理する。認証サーバ５５０は、サービスプロバイダのクライアントのための表１のような情報を格納するためのクライアント情報テーブル５５２を含む。認証サーバ５５４は、クライアントカウンタ値テーブル５５６からの情報を使用してクライアントに対して様々な認証プロセスを実行するためのハードウェアおよびソフトウェアを含む。一実施形態では、認証サーバはさらに、認証メッセージをクライアントデバイスと交換するためのクライアントインターフェース５５７と、認証メッセージをＣＲＭサーバ５４０と交換するための顧客サービスインターフェース５５３とを含むことが示されている。認証サーバはまた、非接触カード５１０と組み合わせて認証を実行するために以下に説明されるように使用され得るクライアントカウンタ値テーブル５５６を含み得る。
【0068】
図６は、クライアントを事前認証するための多要素認証プロトコルの一部として鍵多様化技術を使用するように構成された、非接触カード６０１、クライアントデバイス６１１、およびサービスプロバイダ６２１の認証サービスによって実行され得る様々なステップを示している。例えば、クライアントデバイス６１１にアクセスできる非接触カード６０１のカード所有者は、コールセンタサポートなどの高リスクサービスへのアクセスのための多要素認証を求めることを含む、サービスへのアクセスを可能にするためにサービスプロバイダ６２１からの認証を求め得る。
【0069】
ステップ６１０で、クライアントデバイス６１１は、最初に、ログイン資格情報をサービスプロバイダと交換することによって、サービスプロバイダ６２１によって維持されるクライアントアカウントにアクセスし、ログイン資格情報は、パスワード、鍵、生体認証データ、画像データ、クエリを含み得るが、これらに限定されない。一実施形態では、クライアントは、ＳＰアプリケーションインターフェース５２７を介してクライアント側アプリケーションを起動することによって、このアクセスを開始し得る。アプリの起動は、ユーザからの第１の資格情報を受け入れるように構成されたサービスプロバイダのウェブページの表示を含み得る。
【0070】
いくつかの実施形態では、第１のレベルの認証は、第２のレベルの認証について以下に説明する暗号文交換プロセスを使用して実行され得る。サービスプロバイダアプリは、非接触カード６０１をクライアントデバイス６１１にタップすることによって起動され得、サービスプロバイダアプリへのアクセスを許可するための前兆として暗号文交換を開始する。
【0071】
サービスプロバイダは、ステップ６２０で資格情報を受信し、これらの資格情報を、認証サーバによって維持されているクライアントの資格情報と比較する。ステップ６２２でログイン資格情報が一致しない場合、サービスプロバイダは、ステップ６３１に進み、他の方法を使用してクライアントデバイスの認証を追求する。ステップ６２２で一致があると決定された場合、クライアントは、認証され、サービスプロバイダは、クライアントデバイス６１１によって維持されるクライアント側アプリケーションと調整して、サービスプロバイダのウェブページをクライアントに表示して、１つまたは複数のサービスへのアクセスを可能にする。
【0072】
ステップ６１４で、クライアントデバイスは、高リスクアプリケーション、例えば、顧客サービスアプリケーションへのアクセスを要求する。クライアントは、例えば、サービスプロバイダのウェブサイトで提供される複数のハイパーリンクのうちの１つを選択して、クライアントを選択されたサービスに誘導することによって、アクセスを要求し得る。ハイパーリンクは、例えば、サービスのランディングページのウェブアドレスを含み得る。あるいは、ハイパーリンクは、顧客サポートシステムの電話番号を含み得る。
【0073】
ステップ６２４で顧客サービス要求を受信すると、サービスプロバイダは、選択されたサービスが、認証の第２のレベルから利益を得るであろう高リスクサービスであると決定する。例えば、非接触カードを使用して第２の要素認証を提供する実施形態では、サービスプロバイダは、検証目的で暗号文を取得するために非接触カードを使用するようにクライアントデバイスに促し得る。プロンプトは、テキストプロンプト、視覚プロンプト、可聴プロンプト、およびその他の利用可能な表示メカニズムを含む、非接触カードを使用する必要があることをクライアントに示す任意の方法であり得る。
【0074】
クライアントデバイス６１１は、ステップ６１６でこの要求を受信し、非接触カードを使用する。一態様では、クライアントデバイスは、上記のＮＦＣ通信チャネルを使用して、非接触カードとメッセージを交換し、非接触カードが協力して、対称鍵、対称暗号化処理、およびカウンタの組み合わせを通じて第２の要素認証を提供する。
【0075】
ステップ６０２で、非接触カードは、認証要求を受信する。ステップ６０４で、非接触カード内の処理コンポーネントは、アプリケーションサービストランザクション（ＡＳＴ）カウンタをインクリメントし、対称暗号化アルゴリズムを使用して非接触カードに格納されたマスター鍵を使用してカウンタを符号化し、多様化された鍵を生成する。暗号化アルゴリズムは、対称暗号化アルゴリズム、ＨＭＡＣアルゴリズム、およびＣＭＡＣアルゴリズムのうちの少なくとも１つを含むグループから選択され得る。いくつかの例では、多様化値を処理するために使用される対称アルゴリズムは、所望の長さの多様化された対称鍵を生成するために必要に応じて使用される任意の対称暗号化アルゴリズムを備え得る。対称アルゴリズムの非限定的な例は、３ＤＥＳ（トリプルデータ暗号化アルゴリズム）または高度暗号化標準（ＡＥＳ）１２８などの対称暗号化アルゴリズム、ＨＭＡＣ－ＳＨＡ－２５６などの対称ハッシュベースのメッセージ認証（ＨＭＡＣ）アルゴリズム、ＡＥＳ－ＣＭＡＣなどの対称暗号ベースのメッセージ認証コード（ＣＭＡＣ）アルゴリズムを含み得る。選択された対称アルゴリズムの出力が十分に長い鍵を生成しない場合、異なる入力データと同じマスター鍵を用いて対称アルゴリズムの複数の反復を処理するなどの技術により、必要に応じて組み合わせて十分な長さの鍵を生成する複数の出力を生成し得ることが理解される。
【0076】
非接触カードの処理コンポーネントは、選択された暗号化アルゴリズムを使用し、マスター対称鍵を使用してカウンタ値を処理し得る。例えば、非接触カード６０１は、対称暗号化アルゴリズムを選択し、非接触カードによって処理される認証トランザクションごとにインクリメントするカウンタを使用し得る。次に、非接触カード６０１は、マスター対称鍵を使用して選択された対称暗号化アルゴリズムでカウンタ値を暗号化して、多様化された対称鍵を生成し得る。
【0077】
一態様では、多様化された対称鍵を使用して、認証目的で送信する前にカウンタを処理し得る。例えば、非接触カード６０１は、対称暗号化アルゴリズムおよび多様化された対称鍵を使用してカウンタ値を暗号化し得、出力は、暗号化されたＭＡＣ暗号文を備える。次に、非接触カード６０１は、認証のために暗号文をサービスプロバイダ６２１に送信し得る。いくつかの例では、カウンタ値は暗号化され得ない。これらの例では、カウンタ値は、暗号化なしで、ブロック２３０で送信デバイス２０５と受信デバイス２１０との間で送信され得る。
【0078】
一実施形態では、暗号文を備える認証メッセージのテンプレートは、実際の動的認証データを提供するための周知のインデックスを備えた第１のレコードを備え得る。以下の表２は、クライアントデバイス６１１と非接触カード６０１との間で交換され得る認証メッセージの一例である。
【0079】
【表2】
【0080】
一例では、追加のタグが追加される場合、第１のバイトは、メッセージの開始を示すように変更されるが、終了は示さず、後続のレコードが追加され得る。ＩＤ長さがゼロであるため、ＩＤ長さフィールドとＩＤは、レコードから省略される。以下の表３に示されているメッセージの例は、ＵＤＫＡＵＴ鍵。派生ＡＵＴセッション鍵（０ｘ１２３４を使用）；バージョン１．０；ｐＡＴＣ＝０ｘ１２３４；ＲＮＤ＝７６ａ６６２７ｂ６７ａ８ｃｆｂｂ；ＭＡＣ＝＜計算された８バイト＞を含み得る。第１の列は、ＮＤＥＦメッセージデータへのアドレス／インデックスを備え得る。
【0081】
【表3】
【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】
いくつかの実施形態では、認証サーバは、クライアントごとに、クライアントの承認レベルを格納し得る。一実施形態では、承認レベルは、数値スケールとして表し得、値は、データベース１３０にクライアントデータとして格納されるクライアントデータの一部として、各クライアントに対して格納され得る。
【0109】
ステップ１１２４で、顧客サービスエージェントは、アクセス要求の承認レベルを要求しているクライアントの承認レベルと比較することによって、要求されたアクセスに対してクライアントが承認されているかどうかを決定する。クライアントが承認されている場合、プロセスはステップ１１２８に進み、そこでアクセスが許可される。例えば、いくつかの実施形態では、そのようなアクセスの承認は、顧客サービスエージェントおよびクライアントの一方または両方に機密情報を可視化し得る。他の実施形態では、承認は、データフィールドのロックを解除し、変更を可能にし得る。
【0110】
ステップ１１２９で、通知がクライアントに転送される。一実施形態では、通知は、クライアントの事前検証された連絡先アドレス、例えば、事前検証されたメールアドレスに送信されたメール、または事前検証された電話番号に送信されたテキストメッセージに転送される。好ましくは、通知を転送するために使用される通信チャネルは、情報へのアクセスを要求するためにクライアントによって使用される通信チャネルとは異なる。例えば、クライアントがウェブアプリケーションを使用してアクセスを要求し、その通知が独立したメールアプリケーションでサポートされているメールアドレスに送信され得る。他の通信チャネルを使用してクライアントに通知を提供することは、悪意のある第三者がクライアントになりすましてアクセスする機会を減らすのに役立つ。通知ステップ１１２９は、ステップ１１２８でのアクセスに続いて発生することが示されているが、様々な実施形態では、そのような通知は、アクセスを許可する前に発生し得、クライアントがそのような要求を発行しなかった場合の修復を可能にするための遅延を伴う。
【0111】
ステップ１１２４で、最初の事前承認が要求されたアクセスに対して不十分であると決定された場合、ステップ１１２５で、顧客サービスエージェントは、サーバからの追加の認証を要求し、認証結果を待つためにステップ１１２６で処理される。
【0112】
ステップ１１３１で、認証サーバが認証要求を受信すると、ステップ１１３２で、認証サーバは、認証要求をクライアントにプッシュする。一態様によれば、バックチャネル通信リンクは、事前に検証された通信チャネルを使用して、認証サーバとクライアントデバイスとの間に確立され得る。例えば、認証サーバは、電話番号、インターネットモバイル機器識別子（ＩＭＥＩ）、インターネットプロトコル（ＩＰ）アドレスなどを含むがこれらに限定されない、各クライアントの１つまたは複数の事前検証済み連絡先情報を格納し得る。「プッシュ」リクエストは、事前に検証された連絡先情報を使用してクライアントに送信され得る。「プッシュ」リクエストには、特定の形式の認証情報（すなわち、ＳｗｉｆｔＩＤ、ＳＭＳコード、暗号文など）のリクエストが含まれる。クライアントがアクセスを求めるチャネルとは異なるチャネルを使用して認証要求をクライアントにプッシュすることにより、詐欺師が機密情報へのアクセスを許可される機会が減少する。
【0113】
事前に検証された連絡先へのプッシュに加えて、あるいは、いくつかの実施形態では、プッシュメッセージおよび関連する認証応答は、クライアント／顧客サービスエージェント通信セッションに関連付けられたセッション識別子を使用して、クライアントと認証サーバとの間で交換され得る。セッションＩＤは、ウェブサイトのサーバがクライアントの訪問（セッション）中にクライアントに割り当てる一意の番号である。これは、時間制限のある一意の値であるため、ハッカがセッション通信を正常に復号して侵入することは困難な場合が多い。セッションＩＤは、顧客サービスエージェントとクライアントデバイスの両方で、クッキー、フォームフィールド、またはＵＲＬ（ユニフォームリソースロケータ）として格納され得る。多くのサーバは、セッション識別子を生成するより複雑な方法を含むアルゴリズムを使用しているため、セッション識別子を使用して通信を転送すると、クライアント／顧客サービスエージェントの通信にセキュリティの層がさらに追加される。
【0114】
ステップ１１３４で、認証サーバ１１３０は、クライアントデバイスを認証するために使用される認証トークン（すなわち、電話画像、ＳＭＳコード、暗号文）を受信する。認証サーバ１１３０は、トークンをデータストアから取得された期待値と比較し、認証または拒否信号の１つを顧客サービスエージェントに転送する。
【0115】
ステップ１１２６で、顧客サービスエージェントが拒否信号を受信した場合、クライアントは、認証されず、プロセスは、ステップ１１２７に進み、そこでアクセス要求が拒否される。このような場合、顧客サービスエージェントは、他の認証手段を探すか、呼を終了するか、不正処理のために呼を転送し得る。ステップ１１２６で、顧客サービスエージェントが認証信号を受信した場合、要求されたアクセスは、ステップ１１２８で許可され、メールがステップ１１２９で転送されて、クライアントにアクセス要求を通知する。
【0116】
いくつかの実施形態では、要求された変更の実施は、クライアントからのメールへの応答を待つ間、遅延され得る。例えば、メールメッセージには、アクセス要求が承認されたことを示すクライアントからの肯定的な指示の要求が含まれ得る。いくつかの実施形態では、メール要求は、さらなる認証、例えば、ＳｗｉｆｔＩＤ、ＳＭＳコード、または暗号文交換を要求し得る。
【0117】
図１２Ａおよび図１２Ｂは、図１１に関して上記のプロセスを使用して通信し得る顧客サービスエージェント（ＣＳＡ）１２３２およびクライアント１２３４の例示的なグラフィックユーザインターフェース（ＧＵＩ）ディスプレイを示している。顧客サービスエージェントが処理のための呼を受信すると、顧客サービス画面１２２０は、ユーザ名１２２２、パスワード１２２４、および社会保障番号１２２６など、クライアントに関する情報を表示する様々なフィールドを含み得る。クライアントディスプレイ１２５０は、同様に、ユーザ名１２５２、パスワード１２５４、および社会保障番号１２５６を含む、顧客サービスエージェントに表示される１つまたは複数の情報フィールドのサブセットを含み得る。一態様によれば、上記のように、特定の情報は、エンティティそれぞれの承認レベルに応じて、ＣＳＡ１２３２および／またはクライアントの一方または両方に表示され得ない。したがって、図１２Ａでは、ＣＳＡ１２３２は、クライアントのパスワード１２２４または社会保障番号１２２６を表示することを承認されていない。しかしながら、クライアント１２３４は、これらのフィールドを表示することを承認されている。しかしながら、ロックアイコン１２５８は、クライアントがそれ以上の認証なしにフィールドを変更することを承認されていないことを示している。図１１のようなステップを使用してクライアントをさらに認証するプロセスは、顧客サービスエージェントがディスプレイ上の認証ボタン１２６０を選択することによって、またはＣＳＡ１２３２またはクライアント１２３４の一方または両方がロックアイコン１２５８などのロックアイコンの１つを選択することによってなど、様々な方法で開始され得る。さらに、上記のように、ＣＳＡ１２３２がクライアントの信頼性に疑わしい場合、呼処理中の任意の時点で、ＣＳＡは、認証プロセスを開始するために認証ボタン１２６０を選択し得る。
【0118】
したがって、複数の異なる通信チャネルを使用してクライアントの信頼性を検証することにより、顧客サービストランザクション中にクライアント情報への悪意のあるアクセスの機会を減らすシステムおよび方法が示され、説明されてきた。このような認証は、事前認証の後に、または事前認証の代わりに実行され得る。
【0119】
いくつかの実施形態は、それらの派生物と共に「一実施形態」または「実施形態」という表現を使用して説明され得る。これらの用語は、実施形態に関連して説明される特定の特徴、構造、または特性が、少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な場所における「一実施形態では」という句の出現は、必ずしも全てが同じ実施形態を指すとは限らない。さらに、特に断りのない限り、上記の特徴は、任意の組み合わせで一緒に使用できると認識されている。したがって、別々に議論された任意の特徴は、特徴が互いに互換性がないことに留意されない限り、互いに組み合わせて使用され得る。
【0120】
本明細書で使用される表記法および命名法を一般的に参照して、本明細書の詳細な説明は、コンピュータまたはコンピュータのネットワーク上で実行されるプログラム手順として実施され得る機能ブロックまたはユニットに関して提示され得る。これらの手順の説明および表現は、当業者によって、それらの作業の実体を当業者に最も効果的に伝えるために使用される。
【0121】
手順はここにあり、一般に、望ましい結果につながる自己矛盾のない一連の操作であると考えられている。これらの操作は、物理量の物理的な操作を必要とする操作である。通常、必ずしもそうとは限らないが、これらの量は、格納、転送、結合、比較、およびその他の方法で操作できる電気信号、磁気信号、または光信号の形をとる。主に一般的な使用法の理由から、これらの信号をビット、値、要素、記号、文字、用語、数値などと呼ぶと便利な場合がある。しかしながら、これらおよび類似の用語は全て、適切な物理量に関連付けられており、これらの量に適用される便利なラベルにすぎないことに留意されたい。
【0122】
さらに、実行される操作は、追加または比較などの用語で参照されることが多く、これらは一般に、人間のオペレータによって実行される知的な演算に関連付けられている。１つまたは複数の実施形態の一部を形成する、本明細書に記載の操作のいずれにおいても、人間のオペレータのそのような能力は必要ではないか、またはほとんどの場合望ましくない。むしろ、操作は機械操作である。様々な実施形態の操作を実行するための有用な機械には、汎用デジタルコンピュータまたは同様のデバイスが含まれる。
【0123】
いくつかの実施形態は、それらの派生物と共に「結合された」および「接続された」という表現を使用して説明され得る。これらの用語は、必ずしも相互の同義語として意図されているわけではない。例えば、いくつかの実施形態は、２つ以上の要素が互いに直接物理的または電気的に接触していることを示すために、「接続された」および／または「結合された」という用語を使用して説明され得る。しかしながら、「結合された」という用語はまた、２つ以上の要素が互いに直接接触していないが、それでも互いに協力または相互作用していることを意味し得る。
【0124】
様々な実施形態はまた、これらの操作を実行するための装置またはシステムに関する。この装置は、必要な目的のために特別に構築され得るか、またはコンピュータに格納されたコンピュータプログラムによって選択的にアクティブ化または再構成される汎用コンピュータを備え得る。本明細書に提示される手順は、本質的に特定のコンピュータまたは他の装置に関連するものではない。本明細書の教示に従って書かれたプログラムと共に様々な汎用機械を使用され得、または必要な方法ステップを実行するためのより特殊な装置を構築することが便利であることがわかり得る。これらの様々な機械に必要な構造は、与えられた説明から明らかになる。
【0125】
読者が技術的開示の性質を迅速に確認できるように、開示の要約が提供されていることが強調されている。請求項の範囲または意味を解釈または制限するために使用されないことを理解した上で提出される。さらに、前述の詳細な説明では、開示を合理化するために、様々な特徴が単一の実施形態にまとめられている。この開示方法は、請求された実施形態が各請求項に明示的に記載されているよりも多くの特徴を必要とするという意図を反映していると解釈されるべきではない。むしろ、以下の請求の範囲が反映するように、本発明の主題は、単一の開示された実施形態の全ての特徴よりも少ない特徴にある。したがって、以下の請求の範囲は、詳細な説明に組み込まれ、各請求項は、別個の実施形態として独立している。添付の請求の範囲において、「含む」および「その中」という用語は、それぞれ「備える」および「ここで」というそれぞれの用語の平易な英語の同等物として使用される。さらに、「第１」、「第２」、「第３」などの用語は、単にラベルとして使用され、それらの対象に数値要件を課すことを意図するものではない。
【0126】
上で説明されたことは、開示されたアーキテクチャの例を含む。もちろん、コンポーネントおよび／または方法論の考えられる全ての組み合わせを説明することは不可能であるが、当業者は、さらに多くの組み合わせおよび順列が可能であることを認識し得る。したがって、新規のアーキテクチャは、添付の請求の範囲の精神および範囲内にあるそのような全ての変更、修正、および変形を包含することを意図している。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】