IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ビザ インターナショナル サービス アソシエーションの特許一覧

<>
  • 特許-相互作用処理における端末タイプ識別 図1
  • 特許-相互作用処理における端末タイプ識別 図2
  • 特許-相互作用処理における端末タイプ識別 図3
  • 特許-相互作用処理における端末タイプ識別 図4
  • 特許-相互作用処理における端末タイプ識別 図5
  • 特許-相互作用処理における端末タイプ識別 図6
  • 特許-相互作用処理における端末タイプ識別 図7
  • 特許-相互作用処理における端末タイプ識別 図8
  • 特許-相互作用処理における端末タイプ識別 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-21
(45)【発行日】2023-07-31
(54)【発明の名称】相互作用処理における端末タイプ識別
(51)【国際特許分類】
   G06Q 20/32 20120101AFI20230724BHJP
   G06Q 20/36 20120101ALI20230724BHJP
【FI】
G06Q20/32 330
G06Q20/36 300
【請求項の数】 22
(21)【出願番号】P 2022035766
(22)【出願日】2022-03-09
(62)【分割の表示】P 2021544296の分割
【原出願日】2020-01-27
(65)【公開番号】P2022071174
(43)【公開日】2022-05-13
【審査請求日】2022-03-15
(31)【優先権主張番号】16/262,699
(32)【優先日】2019-01-30
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】505468864
【氏名又は名称】ビザ インターナショナル サービス アソシエーション
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】シェンカー、ギャビン
(72)【発明者】
【氏名】サリバン、ブライアン
(72)【発明者】
【氏名】オービエ、クリスチャン
(72)【発明者】
【氏名】ゴー、ハオ
【審査官】小池 堂夫
(56)【参考文献】
【文献】特表2018-513449(JP,A)
【文献】特表2017-533528(JP,A)
【文献】特表2015-529863(JP,A)
【文献】特表2015-527656(JP,A)
【文献】米国特許出願公開第2016/0248479(US,A1)
【文献】米国特許出願公開第2016/0055480(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
ーザデバイスによって、利用可能なアプリケーション要求メッセージをアクセスデバイスから受信することであって、前記利用可能なアプリケーション要求メッセージは、アプリケーション識別子(AID)を含むデータフィールドを備え、前記アプリケーション識別子は、(1)近接決済システム環境(PPSE)識別子を含む登録アプリケーションプロバイダ識別子(RID)と(2)アクセスデバイスタイプ識別子を含む専有アプリケーション識別子拡張(PIX)とを含む、前記受信することと、
前記ユーザデバイスによって、前記アクセスデバイスタイプ識別子と、前記ユーザデバイス上に格納された複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子との間にリンクが存在するかを判定することであって、前記複数のアプリケーション識別子が、前記ユーザデバイス上の異なるアプリケーションそれぞれに対応する、前記判定することと、
前記ユーザデバイスが、前記リンクが存在するかどうかに基づいて、前記複数のアプリケーション識別子のうち少なくとも1つのアプリケーション識別子を選択することと、
利用可能なアプリケーション応答を、前記ユーザデバイスによって前記アクセスデバイスに送信することであって、前記利用可能なアプリケーション応答は、少なくとも1つのアプリケーション識別子を含み、前記少なくとも1つのアプリケーション識別子は、前記ユーザデバイス上の異なるアプリケーションのうち特定のアプリケーションを選択するために使用される、前記送信することと、を含む、方法。
【請求項2】
前記利用可能なアプリケーション要求メッセージおよび前記利用可能なアプリケーション応答が、近距離無線通信(NFC)プロトコルを使用してそれぞれ送信される、請求項1に記載の方法。
【請求項3】
前記利用可能なアプリケーション要求メッセージおよび前記利用可能なアプリケーション応答が、アプリケーションプロトコルデータユニット(APDU)メッセージである、請求項1に記載の方法。
【請求項4】
前記利用可能なアプリケーション要求メッセージのフォーマットが、コマンドAPDUフォーマットであり、前記アクセスデバイスタイプ識別子が、前記コマンドAPDUのデータフィールドとして受信される、請求項3に記載の方法。
【請求項5】
前記アクセスデバイスタイプ識別子は、(1)前記アクセスデバイスの機能、または(2)前記アクセスデバイスが前記ユーザデバイスのサポートを許可または期待する動作のタイプを識別する、請求項1に記載の方法。
【請求項6】
前記アクセスデバイスは、交通機関端末である、請求項5に記載の方法。
【請求項7】
前記アクセスデバイスタイプ識別子と、前記ユーザデバイス上に格納された前記複数のアプリケーション識別子のうちの前記一つ以上のアプリケーション識別子との間に前記リンクが存在するかどうかの前記判定が、前記ユーザデバイスの特徴に部分的に基づいて実施される、請求項1に記載の方法。
【請求項8】
前記ユーザデバイスの前記特徴が携帯電話であり、前記アクセスデバイスが公共交通機関端末である、請求項7に記載の方法。
【請求項9】
プロセッサと、
前記プロセッサに結合された、コンピュータ可読媒体であって、前記コンピュータ可読媒体が、
アプリケーション選択メッセージを受信する前に、ユーザデバイスによって、利用可能なアプリケーション要求メッセージをアクセスデバイスから受信することであって、前記利用可能なアプリケーション要求メッセージは、アプリケーション識別子(AID)を含むデータフィールドを備え、前記アプリケーション識別子は、(1)近接決済システム環境(PPSE)識別子を含む登録アプリケーションプロバイダ識別子(RID)と(2)アクセスデバイスタイプ識別子を含む専有アプリケーション識別子拡張(PIX)とを含む、前記受信することと、
前記アクセスデバイスタイプ識別子と、前記ユーザデバイス上に格納された複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子との間にリンクが存在するかどうかを判定することであって、前記複数のアプリケーション識別子が、前記ユーザデバイス上の異なるアプリケーションにそれぞれ対応する、前記判定することと、
前記ユーザデバイスが、前記リンクが存在するかどうかに基づいて、前記複数のアプリケーション識別子のうち少なくとも1つのアプリケーション識別子を選択することと、
利用可能なアプリケーション応答を、前記ユーザデバイスによって前記アクセスデバイスに送信することであって、前記利用可能なアプリケーション応答は、少なくとも1つのアプリケーション識別子を含み、前記少なくとも1つのアプリケーション識別子は、前記ユーザデバイス上の異なるアプリケーションのうち特定のアプリケーションを選択するために使用される、前記送信することと、を含む方法を実装するため前記プロセッサによって実行可能なコードを含む、コンピュータ可読媒体と、を備える、ユーザデバイス。
【請求項10】
前記利用可能なアプリケーション要求メッセージおよび前記利用可能なアプリケーション応答が、それぞれ近距離通信(NFC)プロトコルを使用して送信される、請求項9に記載のユーザデバイス。
【請求項11】
前記利用可能なアプリケーション要求メッセージおよび前記利用可能なアプリケーション応答が、アプリケーションプロトコルデータユニット(APDU)メッセージである、請求項9に記載のユーザデバイス。
【請求項12】
前記利用可能なアプリケーション要求メッセージのフォーマットが、コマンドAPDUフォーマットであり、前記アクセスデバイスタイプ識別子が、前記コマンドAPDUフォーマットのデータフィールド内で受信される、請求項11に記載のユーザデバイス。
【請求項13】
前記方法が、
前記アクセスデバイスが前記ユーザデバイスに近接していることを検出すること
をさらに含む、請求項9に記載のユーザデバイス。
【請求項14】
前記ユーザデバイスが携帯電話であり、前記アクセスデバイスが公共交通機関端末である、請求項13に記載のユーザデバイス。
【請求項15】
前記アクセスデバイスタイプ識別子と、前記ユーザデバイス上に格納された前記複数のアプリケーション識別子のうちの前記一つ以上のアプリケーション識別子との間の前記リンクが存在するかどうかの前記判定が、部分的に前記ユーザデバイスの特徴に基づいて実施される、請求項9に記載のユーザデバイス。
【請求項16】
前記ユーザデバイスの前記特徴が、前記ユーザデバイス上に格納されたアプリケーションであり、前記アプリケーションが、前記利用可能なアプリケーション要求メッセージの前記アクセスデバイスタイプ識別子を分析するように構成される、請求項15に記載のユーザデバイス。
【請求項17】
アプリケーション選択メッセージを送信する前に、アクセスデバイスによって、ユーザデバイスに対する利用可能なアプリケーション要求メッセージを生成することであって、前記利用可能なアプリケーション要求メッセージは、アプリケーション識別子(AID)を含むデータフィールドを備え、前記アプリケーション識別子は、(1)近接決済システム環境(PPSE)識別子を含む登録アプリケーションプロバイダ識別子(RID)と(2)アクセスデバイスタイプ識別子を含む専有アプリケーション識別子拡張(PIX)とを含む、生成することと、
前記アクセスデバイスによってユーザデバイスに前記利用可能なアプリケーション要求メッセージを送信することと、
前記ユーザデバイスから利用可能なアプリケーション応答を前記アクセスデバイスによって受信することであって、前記利用可能なアプリケーション応答が、ユーザ装置に格納されている複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子を含み、前記一つ以上のアプリケーション識別子のそれぞれは、アクセスデバイスタイプ識別子とリンクしていることに部分的に基づいてユーザデバイスによって選択され、前記複数のアプリケーション識別子は、それぞれユーザデバイス上の異なるアプリケーションに対応する、前記受信することと、
前記アクセスデバイスによって、前記ユーザデバイス上の異なるアプリケーションのうち特定のアプリケーションの選択を示すアプリケーション選択メッセージを送信することと、を含む、方法。
【請求項18】
前記アクセスデバイスタイプ識別子が、所定の文字列値のセットの文字列値である、請求項17に記載の方法。
【請求項19】
前記アクセスデバイスによって、前記ユーザデバイスから受信された前記一つ以上のアプリケーション識別子のうちのアプリケーション識別子を選択することと、
前記アクセスデバイスによって、前記アプリケーション選択メッセージを生成することであって、前記アプリケーション選択メッセージは、前記選択されたアプリケーション識別子を含む、生成することと、をさらに含む、請求項17に記載の方法。
【請求項20】
選択することが、前記利用可能なアプリケーション応答において前記ユーザデバイスから受信された一つ以上のアプリケーション優先度インジケータに部分的に基づいており、前記一つ以上のアプリケーション優先度インジケータは、前記一つ以上のアプリケーション識別子の異なるアプリケーション識別子にそれぞれ対応する、請求項19に記載の方法。
【請求項21】
記アクセスデバイスによって、前記ユーザデバイスが前記利用可能なアプリケーション要求メッセージを処理できなかったことを示すエラーメッセージを前記ユーザデバイスから受信することであって、前記利用可能なアプリケーション要求メッセージが、拡張された利用可能なアプリケーション要求メッセージである、受信することと、
前記アクセスデバイスによって、第二の利用可能なアプリケーション要求メッセージを生成することであって、前記第二の利用可能なアプリケーション要求メッセージが非拡張の利用可能なアプリケーション要求メッセージである、生成することと、
前記アクセスデバイスによって、前記第二の利用可能なアプリケーション要求メッセージを前記ユーザデバイスに送信することと、をさらに含む、請求項17に記載の方法。
【請求項22】
前記アクセスデバイスタイプ識別子に部分的に基づいて、前記ユーザデバイスによって、前記ユーザデバイス上のユーザ相互作用が必要でないことを判定することと、を含む、請求項1に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本国際出願は、2019年1月30日出願の米国特許出願16/262,699号に対する優先権を主張するもので、その開示の全体があらゆる目的のために参照により本明細書に組み込まれる。
【背景技術】
【0002】
ユーザデバイスとアクセスデバイスとの間の取引を処理するシステムおよび方法が公知である。例えば、支払取引の場合、消費者は、ユーザデバイス(例えば、スマートフォンデバイス上の支払カードまたはデジタルウォレットアプリケーション)を使用して、アクセスデバイス(例えば、POS端末(Point-of-Sale(POS)terminal))と非接触(または接触)データ交換を実行し得る。
【0003】
別の実施例では、ユーザデバイスは、アクセスデバイス(例えば、スマートカードリーダ)とのデータ交換を実行して、ユーザが建物および/またはイベントにアクセスできるようにするために使用され得る。
【0004】
これらの実施例では、データは、ユーザデバイスとアクセスデバイスとの間で通信または交換される。
【0005】
しかしながら、取引処理のための既存のシステムおよび方法には、いくつかの問題が存在する。例えば、ユーザデバイスがスマートフォンである場合、ユーザデバイスは、任意のタイプの取引(例えば、支払いまたは非支払い)を行うためにユーザデバイスが使用される度に、ユーザの認証情報を入力するようにユーザに無差別に促す可能性がある。
【0006】
しかし、一部の取引タイプでは、ユーザプロンプトなどの追加の処理が不要になったり、取引体験が悪化する場合がある。
【0007】
例えば、交通機関の取引では、ユーザは、改札口の端末に対して自分の電話をタップして、交通機関の駅の安全なエリアにアクセスすることができる。交通機関の駅の各顧客は、改札口を素早く通過する必要がある。
【0008】
この環境では、ユーザが制限された領域に入ることができる前に、ユーザが自身の認証情報をそのユーザデバイスに入力することは面倒であり、多くの場合不要である。
【0009】
別の問題は、ユーザがユーザデバイス上で複数のアプリケーションを維持する可能性がある場合に存在する。
【0010】
この状況では、各アプリケーションは異なるタイプの取引を実行することができる。ユーザデバイスがアクセスデバイスに近接している時、ユーザデバイス上のアプリケーション(例えば、デジタルウォレットアプリケーション)は、ユーザデバイス上のデジタルウォレットに関連付けられたアプリケーションのリストをアクセスデバイスに送信してもよい。
【0011】
しかしながら、ユーザは、特定のアクセスデバイスタイプに遭遇するときに、特定のアプリケーションを使用することを望む場合がある(例えば、ユーザがロイヤルティアカウントを有する特定の小売業者での支払いのために特定のクレジットカードを使用する、または、常に既定のクレジットカードを使用する代わりに、プリペイドカードに対応する特定の公共交通機関のアプリケーションを使用して、列車の端末ゲートを通過する)。
【0012】
ユーザは、取引時に適切なアプリケーションを選択するために、ユーザデバイスと物理的に相互作用することなく、これを実行することができることを望む場合がある。
【0013】
本開示の実施形態は、これらおよび他の問題に、個々にかつまとめて対処する。
【発明の概要】
【課題を解決するための手段】
【0014】
一つの実施形態は、アクセスデバイスからユーザデバイスによって、利用可能なアプリケーション要求メッセージを受信することであって、利用可能なアプリケーション要求メッセージが、アクセスデバイスタイプの識別子を含む、受信することと、ユーザデバイスによって、アクセスデバイスタイプ識別子と、ユーザデバイス上に格納された複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子との間に関連付けが存在するかどうかを判定することであって、複数のアプリケーション識別子が、ユーザデバイス上の異なるアプリケーションそれぞれに対応する、判定することと、ユーザデバイスによって、関連が存在するかどうかに部分的に基づいて、利用可能なアプリケーション応答をアクセスデバイスに送信することであって、利用可能なアプリケーション応答は、アクセスデバイスタイプ識別子に関連付けられた複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子を含む、送信することと、を含む、方法を含む。
【0015】
別の実施形態は、プロセッサおよびプロセッサに結合されたコンピュータ可読媒体を備える通信デバイスを含む。コンピュータ可読媒体は、方法を実装するため、プロセッサにより実行可能なコードを備える。方法は、アクセスデバイスから利用可能なアプリケーション要求メッセージを受信することとであって、利用可能なアプリケーション要求メッセージが、アクセスデバイスタイプの識別子を含む、受信することと、アクセスデバイスタイプ識別子と、ユーザデバイス上に格納された複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子との間に関連付けが存在するかを判定することとであって、複数のアプリケーション識別子が、ユーザデバイス上の異なるアプリケーションそれぞれに対応する、判定することと、関連付けが存在するかどうかに部分的に基づいて、利用可能なアプリケーション応答をアクセスデバイスに送信することであって、利用可能なアプリケーション応答は、アクセスデバイスタイプ識別子に関連付けられた複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子を含む、送信することと、を含む、方法。
【0016】
別の実施形態は、アクセスデバイスによって、利用可能なアプリケーション要求メッセージを生成することであって、利用可能なアプリケーション要求メッセージが、アクセスデバイスタイプ識別子を含む、生成することと、アクセスデバイスによって、利用可能なアプリケーション要求メッセージを、ユーザデバイスに送信することと、ユーザデバイスからアクセスデバイスによって、利用可能なアプリケーション応答を受信することであって、利用可能なアプリケーション応答は、アクセスデバイスタイプ識別子に関連付けられた一つ以上のアプリケーション識別子を含む、受信することと、を含む方法、を含む。
【0017】
別の実施形態は、アクセスデバイスからユーザデバイスによって、利用可能なアプリケーション要求メッセージを受信することであって、利用可能なアプリケーション要求メッセージは、アクセスデバイスタイプ識別子を含む、受信することと、ユーザデバイスによってアクセスデバイスタイプ識別子に部分的に基づいて、ユーザデバイス上のユーザ対話が必要かどうかを判定することと、を含む方法、を含む。
【0018】
本開示の実施形態に関するさらなる詳細は、発明を実施するための形態および図面に記載される。
【図面の簡単な説明】
【0019】
図1図1は、一実施形態によるシステムのブロック図を示す。
図2図2は、一実施形態によるユーザデバイスおよびアクセスデバイスのブロック図を示す。
図3図3は、一実施形態によるユーザデバイスのブロック図を示す。
図4図4は、一実施形態による、ユーザデバイスとアクセスデバイスとの間のメッセージ交換プロセスを示す流れ図を示す。
図5図5は、一実施形態による、ユーザデバイスとアクセスデバイスとの間のメッセージ交換プロセスを示す流れ図を示す。
図6図6は、一実施形態による、ユーザデバイスとアクセスデバイスとの間のメッセージ交換プロセスを示す流れ図を示す。
図7図7は、一実施形態による、ユーザデバイス上の異なるアプリケーションとアクセスデバイスタイプ識別子との間のリンクの例示的な図を示す。
図8図8は、建物アクセスシステムを示すブロック図を示す。
図9図9は、支払処理システムを示すブロック図を示す。
【発明を実施するための形態】
【0020】
実施形態は、ユーザデバイス(例えば、携帯電話、接触/非接触カード)とアクセスデバイス(例えば、POS端末、交通機関またはイベントのゲート、スマートカードリーダなど)との間の取引の処理を容易にすることができる方法およびシステムを含み得る。取引中にユーザデバイスとアクセスデバイスとの間で交換されるメッセージは、ユーザデバイスとアクセスデバイスの両方の機能(例えば、ソフトウェアおよび/またはハードウェア機能)に依存し得る。例えば、アクセスデバイスは、アクセスデバイスが、ユーザデバイスがその近位にあると検出したときに、アクセスデバイスタイプ識別子を含むメッセージをユーザデバイスに送信するように構成され得る。アクセスデバイス識別子は、ユーザデバイスに対するアクセスデバイスのタイプ(例えば、公共交通機関用スマートカードリーダ、特定の小売業者のPOS端末、野球スタジアム電子チケットリーダなど)を識別する。
【0021】
ユーザデバイスは、アクセスデバイスからメッセージを受信してもよく、メッセージは、アクセスデバイスタイプ識別子を含み得る。ユーザデバイスは、アクセスデバイスタイプ識別子を、ユーザデバイス上の一つ以上のアプリケーション識別子(各アプリケーション識別子は、それぞれ異なるアプリケーションに対応する)と関連付けることができる。この関連付けに基づいて、ユーザデバイスは、アクセスデバイスタイプ識別子に関連付けられた一つ以上のアプリケーション識別子を含む、アクセスデバイスへの応答メッセージを送信し得る。
【0022】
例示的には、ユーザデバイスが、交通機関端末から公共交通機関の端末識別子を含むメッセージを受信する場合、ユーザデバイスは、交通機関専用アプリケーションおよび/または交通機関端末への交通機関取引に特に使用されるユーザによって選択される支払アプリケーションに対応するアプリケーション識別子のみを送信し得る。これは、ユーザデバイス上のアプリケーション識別子の一般リストを、ユーザデバイスが交通機関端末に送信するよりも効率的である。そうでない場合、ユーザデバイスから交通機関端末に送信され得る不必要なデータを減少させることによって、処理速度を改善でき、追加のコンピューティングリソース(例えば、追加のメモリおよびプロセッサ電力)の必要性を低減する。また、特定のアプリケーション識別子のリストを交通機関端末に送信することにより、交通機関端末が多くのアプリケーションのうちの一つを選択する必要性を回避することができ、かつユーザは必ずしも好まないアプリケーションを選択する可能性も回避することができる。
【0023】
追加で、ユーザデバイスはまた、アクセスデバイスから受信されたアクセスデバイスタイプ識別子に部分的に基づいて、ユーザデバイス上で特定の機能を実行するかどうかを決定するように構成されてもよい。例えば、アクセスデバイスタイプ識別子の値に応じて、ユーザデバイスは、生体認証サンプル、パスコード、またはPINなどの検証情報を入力するようにユーザに促してもよく、または促さなくてもよい。これにより、ユーザデバイスは、あらゆるタイプの取引においてユーザからかかる情報を要求する必要がないため、処理をより効率的にすることができる。
【0024】
実施形態は、従来のシステムを改善し、いくつかの技術的利点を提供する。上述のように、実施形態は、特定の状況下で取引を実施するために、ユーザが自身のユーザデバイスと相互作用する必要性を低減または排除することによって、ユーザの時間を節約する。また、ユーザデバイスは、端末タイプに基づいて、一つ以上の適切なアプリケーションを自動的に選択することができる。これにより、人為的エラーのリスクが減少し、望ましい取引が効率的に、かつユーザの望ましいアプリケーションで進行していることを確実にする。
【0025】
この改善は、同様に、接触および/または非接触カードなどのユーザデバイスにも適用され得ることに留意されたい。例えば、カードは、複数のアプリケーション(例えば、クレジットカード、デビットカードなど)を含んでもよく、各アプリケーションは、複数のアクセスデバイスタイプのうちの一つ以上に対応してもよい。ユーザは、カード上の適切なアプリケーションを特定のアクセスデバイスタイプに自動的に提示して、単一のカードを使用して様々な取引タイプを安全かつ便利に実行することができる。これにより、ユーザは、より多様な取引を行うためにより少ないユーザデバイスを保有しさえすればよいため、セキュリティと利便性が向上する。
【0026】
最後に、実施形態はまた、実行される取引のタイプに基づいて、ユーザデバイスが機能を実行できるようにするか、または実行できないようにする。例えば、ユーザデバイスは、特定のタイプの取引に対して適切なレベルのセキュリティおよび/または利便性(例えば、速度)で取引を実行できる。ユーザが公共交通機関端末カードリーダに対して改札口でユーザデバイスをタップしている時などの非支払取引では、ユーザデバイスは、ユーザ認証プロセスによって妨げられることなく取引が進行できるように、PIN、パスワード、または生体認証をユーザに促さなくてもよい。しかし、小売業者のPOS端末での支払取引では、より高いセキュリティが望まれてもよく、ユーザデバイスは、ユーザデバイスがPOS端末との取引を完了させる前にユーザを認証してもよい。
【0027】
本開示の一部の実施形態の詳細を論じるのに先立ち、一部の用語についての記載が、さまざまな実施形態を理解するのに役立つ可能性がある。
【0028】
「ユーザデバイス」は、ユーザによって使用され得る任意の適切なデバイス(例えば、支払カードまたは携帯電話)であってもよい。ユーザデバイスは、任意の好適な形態であってもよい。ユーザデバイスの一部の例には、磁気ストライプまたは非接触素子(例えば、非接触チップおよびアンテナを含む)を有するカード(例えば、クレジットカード、デビットカード、またはプリペイドカードなどの支払カード)、携帯電話、PDA、パーソナルコンピュータ(PC)、タブレットコンピュータなどが含まれる。実施形態によっては、ユーザデバイスがモバイルデバイスである場合、モバイルデバイスは、ディスプレイ、メモリ、プロセッサ、コンピュータ可読媒体、および任意の他の適切な構成要素を含み得る。
【0029】
「モバイルデバイス」(モバイル通信デバイスと呼ばれることがある)は、ユーザによって運搬および操作可能な任意の適切な電子デバイスを含むことができ、また、ネットワークへの遠隔通信機能を提供することができる。モバイル通信デバイスは、移動電話(無線)ネットワーク、無線データネットワーク(例えば、3G、4Gまたは同様のネットワーク)、Wi-Fi、ペンティアム(登録商標)、ブルートゥース(登録商標)ローエナジー(BLE)、Wi-Max、またはインターネットもしくはプライベートネットワークなどのネットワークへのアクセスを提供できる任意の他の通信媒体を使用して通信することができる。モバイルデバイスの例として、移動電話(例えば、携帯電話)、PDA、タブレットコンピュータ、ネットブック、ラップトップコンピュータ、ウェアラブルデバイス(例えば、腕時計)、車両(例えば、自動車およびオートバイ)、パーソナル音楽プレーヤ、手持ち式専用リーダなどが挙げられる。モバイルデバイスは、こうした機能を実行するための任意の好適なハードウェアおよびソフトウェアを含んでもよく、また複数のデバイスまたはコンポーネントを含んでもよい(例えば、デバイスが他のデバイスにテザリングすることによりネットワークへリモートアクセスする場合、すなわち、他のデバイスをモデムとして使用する場合、両方のデバイスを合わせて単一のモバイルデバイスと考えてもよい)。
【0030】
「非接触」通信は、デバイスが物理的に結合される必要性なしに、二つのデバイス間でデータが交換される通信であってもよい。前述の一般性を制限することなく、“非接触”通信は、近距離通信(NFC)トランシーバ、レーザ、無線周波数、赤外線通信、またはペンティアム(登録商標)、ブルートゥース(登録商標)ローエナジー(BLE)、Wi-Fi、iBeacon(登録商標)などの他の無線周波数または無線通信プロトコルによるデータ伝送を含み得る。
【0031】
「アクセスデバイス」は、何かへのアクセスを提供するための任意の好適なデバイスであってもよい。アクセスデバイスは、任意の好適な形態であってもよい。アクセスデバイスの一部の例として、POSデバイス、携帯電話、PDA、パーソナルコンピュータ(PC)、タブレットPC、手持ち式専用リーダ、セットトップボックス、電子キャッシュレジスタ(ECR)、現金自動預入支払機(ATM)、仮想キャッシュレジスタ(VCR)、キオスク、セキュリティシステム、交通機関またはイベントのゲート、アクセスシステム、ウェブサイトなどが挙げられる。アクセスデバイスは、任意の好適な接触または非接触動作モードを使用して、ユーザデバイスとの間でデータ、または該ユーザデバイスに関連付けられたデータの送受信を行うことができる。アクセスデバイスがPOS端末を含んでもよい一部の実施形態では、任意の好適なPOS端末を使用でき、該端末はリーダと、プロセッサと、コンピュータ可読媒体とを含むことができる。リーダは、任意の好適な接触または非接触動作モードを含むことができる。例えば、例示的なカードリーダは、ユーザデバイスと相互作用するために、無線周波数(RF)アンテナ、光学スキャナ、バーコードリーダまたは磁気ストライプリーダを含み得る。
【0032】
「リソースプロバイダ」は、取引中にリソース(例えば、物品、サービス、安全なデータへのアクセス、場所へのアクセス、またはこれに類するもの)を提供する事業体であり得る。例えば、リソース提供事業体は、小売業者、交通機関または会場運営者、建物所有者、政府機関などであり得る。「小売業者」は通常、取引に携わり、物品もしくはサービスを販売する、または物品もしくはサービスへのアクセスを提供することができる事業体であり得る。
【0033】
「認証データ」は、事業体を認証するために適切な任意のデータを含むことができる。認証データは、ユーザまたはユーザによって操作される装置から取得することができる。ユーザから取得される認証データの例として、PIN(個人識別番号)、生体認証データ、パスワードなどを含み得る。装置から取得することができる認証データの例として、装置のシリアル番号、ハードウェア安全要素識別子、装置で読み取られた指紋、電話番号、IMEI番号などを含み得る。
【0034】
「アクセスデータ」は、リソースにアクセスするために使用され得る、またはリソースにアクセスすることができるデータを生成する任意の好適なデータを含み得る。実施形態によっては、アクセスデータは、支払口座のアカウント情報であってもよい。アカウント情報として、PAN、支払トークン、有効期限、検証値(例えば、CVV、CVV2、dCVVおよびdCVV2)などを挙げることができる。他の実施形態では、アクセスデータは、アカウントデータをアクティブ化するために使用することができるデータであってもよい。例えば、場合によっては、アカウント情報は、モバイル装置に保存することができるが、特定の情報をそのモバイル装置が受信するまでアクティブ化されないこともあり得る。他の実施形態では、アクセスデータは、場所にアクセスするために使用することができるデータを含んでもよい。こうした情報は、イベントのためのチケット情報、建物にアクセスするためのデータ、交通機関のチケット情報などであってもよい。さらに他の実施形態では、アクセスデータは、機密データへのアクセスを取得するために使用されるデータを含み得る。アクセスデータの例としては、機密データへのアクセスを許可するためにサーバコンピュータが必要なコードまたはその他のデータを挙げることができる。
【0035】
“アクセス要求”は、リソースへのアクセス要求を含み得る。リソースは、物理的リソース(例えば、物品)、デジタルリソース(例えば、電子文書、電子データなど)、またはサービスであってもよい。一部の事例では、アクセス要求は、アクセス要求データを含むアクセス要求メッセージの送信によって提出されてもよい。典型的には、要求者に関連付けられたデバイスは、アクセス要求メッセージを、リソースプロバイダに関連付けられたデバイスに送信し得る。
【0036】
“アクセス要求データ”には、アクセス要求の周囲の、またはアクセス要求に関連する任意の情報が含まれ得る。アクセス要求データには、アクセスデータが含まれ得る。アクセス要求データには、アクセス要求の処理および/または検証に有用な情報が含まれ得る。例えば、アクセス要求データは、アクセス要求の処理に関与する事業体(例えば、リソースプロバイダコンピュータ、処理サーバコンピュータ、承認コンピュータなど)、例えば、事業体識別子(例えば、名前など)、事業体に関連付けられた位置情報、および事業体のタイプ(例えば、カテゴリーコード)を示す情報に関連する詳細を含み得る。例示的なアクセス要求データは、アクセス要求量、アクセス要求場所、受け取ったリソース(例えば、製品、文書、など)、受け取ったリソースに関する情報(例えば、サイズ、量、タイプ、など)、事業体データを提供するリソース(例えば、リソースプロバイダデータ、文書所有者データ、など)、ユーザデータ、アクセス要求の日時、アクセス要求を実行するために利用された方法(例えば、接触、非接触、など)、および他の関連情報を示す情報を含んでもよい
【0037】
「認証情報」とは、価値、所有権、身元、または権限の信頼できる証拠として機能する任意の適切な情報であり得る。認証情報は、数字、文字、または他の任意の好適な記号の列、ならびに確認の役目を果たすことができる任意のオブジェクトまたは文書であってもよい。認証情報の例には、価値の証明書、IDカード、認定文書、アクセスカード、パスコード、および他のログイン情報などが含まれる。認証情報のその他の例には、PAN(プライマリアカウント番号)、氏名、住所、電話番号などのPII(個人識別情報)などが挙げられる。
【0038】
「承認事業体」は、要求を承認する事業体であってもよく、典型的には、承認を行う承認コンピュータを使用する。承認事業体は、発行者、政府機関、文書保管所、アクセス管理者などであり得る。「発行者」は通常、ユーザのアカウントを保持するビジネス事業体(例えば、銀行)を含み得る。発行者はまた、ユーザに対して携帯電話、スマートカード、タブレット、またはラップトップなどのユーザデバイス上に格納される、支払認証情報を発行することができる。
【0039】
「サービスプロバイダ」は、通常サービスプロバイダコンピュータを介して、物品、サービス、情報および/またはアクセスなど、リソースを提供できる事業体であってもよい。サービスプロバイダの例としては、データプロバイダ、交通機関代理店、小売業者、デジタルウォレット、決済処理業者などが挙げられる。
【0040】
「トークン」は、認証情報の置換値であってもよい。トークンは、数字、文字、または任意のその他の適切な記号の列であってもよい。トークンの例には、支払トークン、アクセストークン、個人識別トークンなどが含まれる。
【0041】
「支払トークン」は、プライマリアカウント番号(PAN)などの口座識別子の代替である支払口座のための識別子を含むことができる。例えば、トークンは、元の口座識別子の代替として使用することができる、ひと続きの英数字を含んでもよい。例えば、トークン「4900 0000 0000 0001」を、PAN「4147 0900 0000 1234」の代わりに使用してもよい。実施形態によっては、トークンは、「形式保存」であってもよく、既存の取引処理ネットワークで使用されるアカウント識別子に準拠する数値形式(例えば、ISO8583金融取引メッセージ形式)を有することができる。一部の実施形態では、トークンは、支払取引を開始、認可、決済もしくは解決するように、または元の認証情報が通常提供されるであろう他のシステムで元の認証情報を表すように、PANの代わりに使用されてもよい。一部の実施形態では、トークン値は、元のPAN、またはトークン値からの他のアカウント識別子の回復が、計算上導き出されないように生成されてもよい。さらに、一部の実施形態では、トークン形式は、トークンを受け取る事業体が、それをトークンとして識別し、トークンを発行した事業体を認識することが可能になるように構成されてもよい。
【0042】
「承認要求メッセージ」は、相互作用の承認を要求する電子メッセージであってよい。一部の実施形態では、承認要求メッセージは、処理ネットワークコンピュータおよび/または支払カードの発行者へ送られて、取引の承認を要求する。一部の実施形態による承認要求メッセージは、支払デバイスまたは支払口座を使用するユーザによりなされる支払いに関連付けられる、電子取引情報を交換するシステムの標準である、国際標準化機構(ISO)8583に準拠することができる。承認要求メッセージは、支払デバイスまたは支払口座に関連付けられてもよい、発行者アカウント識別子を含んでもよい。承認要求メッセージはまた、ほんの例として、サービスコード、CVV(カード検証値)、dCVV(動的カード検証値)、PAN(プライマリアカウント番号または「アカウント番号」)、支払いトークン、ユーザ名、有効期限などを含む、「識別情報」に対応する追加のデータ要素を含んでもよい。承認要求メッセージはまた、取引額、小売業者識別子、小売業者の場所、アクワイアラ銀行識別番号(BIN)、カードアクセプタID、購入された品目を識別する情報など、現在の取引に関連付けられるいずれの情報などの「取引情報」、ならびに取引を識別および/または承認するかを判定するのに利用することができる、いかなる他の情報を含んでもよい。また、位置へのアクセス、安全なデータへのアクセスなどの承認を要求するには、“承認要求メッセージ”を使用してもよい。
【0043】
「承認応答メッセージ」は、認証要求に応答するメッセージであり得る。場合によっては、メッセージは、発行金融機関または処理ネットワークコンピュータによって生成される、承認要求メッセージへの電子メッセージ返信であり得る。承認応答メッセージは、単に例として、次の状態指標のうちの一つ以上を含んでもよい。承認―取引が承認された。拒否―取引が承認されなかった。または、コールセンタ―応答はより多くの情報を保留中で、小売業者は、フリーダイヤルの承認電話番号に電話する必要がある。承認応答メッセージはまた、クレジットカード発行銀行が承認要求メッセージに応じて、取引の承認を示す小売業者のアクセスデバイス(例えば、POS装置)に電子メッセージ(直接または処理ネットワークコンピュータを介してのいずれか)で返信するコードであり得る、承認コードを含むことができる。コードは、承認の証明として役割を果たし得る。
【0044】
「承認事業体」は、要求を承認する事業体とすることができる。承認事業体の例は、発行者、交通機関代理店、政府機関、文書保管所、アクセス管理者などであり得る。承認事業体は、承認事業体コンピュータを操作できる。「発行者」は、ユーザ用のアカウントを発行し、選択的に保持するビジネス事業体(例えば、銀行)を指してもよい。発行者はまた、消費者、もしくは一部の実施形態では、ポータブルデバイスに対して、携帯電話、スマートカード、タブレット、またはラップトップなどのユーザデバイスに記憶される、支払認証情報を発行することができる。
【0045】
「サーバコンピュータ」は通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。
【0046】
「プロセッサ」は、任意の好適な一つ以上のデータ計算デバイスを含むことができる。プロセッサは、所望の機能を達成するために共に動作する、一つ以上のマイクロプロセッサを備えることができる。プロセッサは、ユーザおよび/またはシステム生成要求を実行するプログラム構成要素を実行するために適切な、少なくとも一つの高速データプロセッサを備えるCPUを含んでもよい。CPUは、AMDのアスロン、デュロン、および/もしくはオプテロン、IBMおよび/もしくはモトローラーのPowerPC、IBMおよびソニーのセルプロセッサ、インテルのセレロン、アイテニウム、ペンティアム(登録商標)、ジーオン、および/もしくはXScale、ならびに/または同様のプロセッサなどのマイクロプロセッサであり得る。
【0047】
「メモリ」は、電子データを格納できる、任意の好適な一つ以上のデバイスであり得る。好適なメモリとして、所望の方法を実施するためにプロセッサにより実行され得る命令を格納する、非一過性コンピュータ可読媒体が含まれ得る。メモリの例として、一つ以上のメモリチップ、ディスクドライブなどが含まれ得る。こうしたメモリは、任意の好適な電気的、光学的、および/または磁気的な動作モードを使用して動作することができる。
【0048】
「アプリケーション」は、特定の目的に対して使用されるコンピュータプログラムであり得る。アプリケーションの例としては、交通機関のアプリケーション、セキュアデータアクセスアプリケーション、バンキングアプリケーション、デジタルウォレットアプリケーション、イベントチケット発行アプリケーション、ロイヤルティリワードアプリケーションなどが挙げられる。実施形態によっては、アプリケーションは、リソースまたはサービスプロバイダ(例えば、銀行口座、公共交通機関プリペイドアカウント、建物アクセスアカウントなど)によって維持されるユーザのアカウントと関連付けられてもよい。
【0049】
「アプリケーション識別子」(AID)は、アプリケーションを識別できるデータであり得る。一部の実施形態では、AIDは、各アプリケーションを一意に識別するために使用される16バイト値であってもよい。ユーザデバイスとアクセスデバイスの両方が、複数のAIDをサポートし得る。AIDはまた、アクセスデバイス(例えば、PSE、PPSE)によってサポートされるシステム環境を識別するために使用されてもよい。ユーザデバイスは、アプリケーション識別子のリストを格納してもよく、各アプリケーション識別子は、ユーザデバイス上の異なるアプリケーションに対応する。リストの一つ以上のアプリケーションのAIDは、取引初期化プロセス中にアクセスデバイスに送信されて、どのアプリケーションがアクセスデバイスとユーザデバイスの両方によって相互にサポートされるか、そして最終的にどのアプリケーションが候補リストからアクセスデバイスによって取引を開始するために選択されるべきかを決定する際に、アクセスデバイスによって使用されてもよい。実施形態によっては、AIDは、16進数値でもよい5バイトの登録アプリケーションプロバイダ識別子(RID)と、典型的には数値である任意の専有アプリケーション識別子拡張(PIX)との連結によって形成され得る。例えば、PPSEをサポートするアクセスデバイスのAIDは、16進数325041592E5359532E4444463031(すなわち、16進数325041592EのRIDおよび16進数5359532E4444463031のPIX拡張)であってもよい。また、クレジットカードアプリケーションのAIDは、例えば、16進AA000000003のRID値および16進1010のPIX値を有してもよい。したがって、連結されたAIDは、16進AA0000000031010であってもよい。
【0050】
「決済システム環境」(PSE)は、ユーザデバイスが、トランザクションの実行に使用されるユーザデバイス上で利用可能ないくつかのアプリケーションを含む記録を保持するディレクトリ構造を格納するための機構とすることができる。「近接決済システム環境(Proximity Payment System Environment)」(PPSE)は、ユーザデバイスとアクセスデバイスとの間の非接触通信にのみ適用される。ユーザデバイス上のPPSEは、非接触型インターフェースによってサポートされるすべてのアプリケーションのリストを含み、ユーザデバイスから、PPSEに対してSELECTコマンドを発行したアクセスデバイスへ返信される。PSEおよびPPSEメカニズムの両方を使用して、メッセージ交換プロトコルを容易にすることができ、それによって、アクセスデバイスは、ユーザデバイス上のアプリケーション(例えば、アプリケーションの返信されたリストから)を選択して、取引を進行し得る。PSEおよびPPSEメカニズムの両方の下で交換されるメッセージは、「アプリケーションプロトコルデータユニット(Application Protocol Data Unit)」(APDU)形式を利用し得る。APDUは、アクセスデバイスとユーザデバイスとの間で転送されるデータユニットである。取引は、ユーザデバイスからデータを読み取り、必要な処理ステップを実施するための複数のAPDU交換を含み得る。
【0051】
「カード所有者検証方法(Cardholder Verification Method)」(CVM)は、カード所有者またはユーザの身元を検証するために、システム(例えば、アクセスデバイスまたはユーザデバイス)によって実施される機能である。CVMは、パスコードまたはオンラインPIN、カード所有者の署名などの入力を含む検証メカニズムを含み得る。「消費者デバイスによるカード所有者の検証方法(Consumer Device Cardholder Verification Method)」(CDCVM)は、カード所有者が端末によって検証される代わりに、そのユーザデバイス(例えばスマートフォン)を介して検証されるCVMの一種である。CDCVMは、上記に列挙されたメカニズム(ユーザデバイス上でローカルに実施される)に加えて、生体照合(例えば、指紋または顔認識)、またはユーザデバイスのパスコードの入力を含み得る。一部の事例では、アクセスデバイスは、取引を初期化する前にCDCVMをユーザが実施することを要求し得る。
【0052】
ここで、本開示の一部の実施形態の詳細についてより詳細に説明する。
【0053】
図1は、本発明の一実施形態による、いくつかの構成要素を備えるシステム100を示す。システム100は、ユーザ101によって使用されるユーザデバイス102、およびアクセスデバイス103を備える。明確にするために、特定の数の構成要素を図1に示す。本開示の実施形態は、各構成要素の一つより多くを含んでもよいことは理解されるものとする。
【0054】
実施形態によっては、ユーザデバイス102は、ユーザデバイス102がアクセス取引を実行できるように、アクセスデータをプロビジョニングされ得る、モバイルウォレットアプリケーション、支払アプリケーション、またはアクセスアプリケーションなどのサービスプロバイダアプリケーションを含み得る。また、一部の実施形態では、ユーザデバイス102は、非接触または接触通信を介して、アクセスデバイス103と動作可能に通信してもよい。実施形態によっては、ユーザデバイス102は、NFC(近距離通信)、ペンティアム(登録商標)、ペンティアム(登録商標)ローエナジー(BLE)、Wi-Fiなどの近距離非接触通信モードを介してアクセスデバイス103と通信できる。実施形態によっては、非接触通信モードは、可聴信号および光信号の使用も含み得る。
【0055】
図2は、一実施形態によるユーザデバイス102およびアクセスデバイス103のブロック図200を示す。
【0056】
ユーザデバイス102はまた、ユーザデバイス102の機能を処理するためのプロセッサ102A(例えば、マイクロプロセッサ)と、ユーザが情報を見ることを可能にするディスプレイ102Gを含んでもよい。ユーザデバイス102は、入力要素102E(例えば、タッチスクリーン、キーボード、タッチパッド、バイオメトリックセンサなどのセンサ)、スピーカ102H、およびマイク102Fをさらに含み、それぞれがプロセッサ102Aに動作可能に結合される。非接触要素インターフェース102I、アンテナ102D、メモリ102C、およびコンピュータ可読媒体102Bも、プロセッサ102Aに動作可能に結合されてもよい。
【0057】
コンピュータ可読媒体102Bおよびメモリ102Cは、本体102J内に存在してもよい。本体102Jは、プラスチック基板、ハウジング、または他の構造の形態であってもよい。場合によっては、メモリ102Cは、安全な要素であってもよく、および/またはトークン、PAN、チケットなどを含むアクセスデータなどの情報も格納してもよい。メモリ102C内の情報は、ユーザデバイス102によって、アンテナ102Dまたは非接触要素インターフェース102Iを使用して別のデバイスに送信されてもよい。ユーザデバイス102は、無線データ転送(例えば、IEEE(アメリカ電気電子学会)802.11などの無線ネットワーキングプロトコルを使用する)または携帯電話通信(例えば、3G、4G、および/またはLTE)のためにアンテナ102Dを使用し得る。非接触要素インターフェース102Iのアンテナ102Kは、NFC(近距離無線通信)、BLE(ペンティアム(登録商標)ローエナジー)、RFID(無線周波数識別子)、または狭域もしくは中域通信メカニズムの任意の他の好適な形態などの、個々の無線プロトコルによって指定された周波数での無線信号の送受信用に構成され得る。
【0058】
一部の実施形態では、非接触要素インターフェース102Iは、アンテナなどの連動無線転送(例えば、データ伝送)要素と共に半導体チップ(または他のデータ記憶要素)の形態で実装される。セルラーネットワークを介して伝送されるデータまたは制御命令は、非接触要素インターフェース102Iに適用され得る。非接触要素インターフェース102Iは、狭域無線通信機能を使用してデータを送受信することができてもよい。したがって、ユーザデバイス102は、セルラーネットワーク(または任意の他の好適な無線ネットワーク、例えばインターネットもしくは他のデータネットワーク)または任意の狭域通信メカニズムの両方を介して、データまたは制御命令を通信および転送することが可能であり得る。
【0059】
一部の実施形態では、コンピュータ可読媒体102Bは、方法を実装するために、プロセッサにより実行可能なコードを含み得る。例えば、コンピュータ可読媒体102Bは、利用可能なアプリケーション要求メッセージをアクセスデバイスから受信することであって、利用可能なアプリケーション要求メッセージは、アクセスデバイスタイプ識別子を含む、受信することと、アクセスデバイスタイプ識別子と、ユーザデバイス上に格納された複数のアプリケーション識別子の一つ以上のアプリケーション識別子との間の関連付けが存在するかを判定することであって、複数のアプリケーション識別子が、ユーザデバイス上の異なるアプリケーションそれぞれに対応する、判定することと、関連付けが存在するかどうかに部分的に基づいて、利用可能なアプリケーション応答をアクセスデバイスに送信することであって、利用可能なアプリケーション応答が、アクセスデバイスタイプ識別子に関連付けられた複数のアプリケーション識別子のうちの一つ以上のアプリケーション識別子を含む、送信することと、を含む方法を実装するため、プロセッサ102Aによって実行可能な、コードを含み得る。
【0060】
コンピュータ可読媒体102Bは、一つ以上のサービスプロバイダアプリケーション102B-1~102B-nを含み得る。サービスプロバイダアプリケーション102B-1~102B-nは、プロセッサ102Aと併せて、ユーザデバイス102が様々なサービスプロバイダコンピュータと通信することを可能にすることができる。各アプリケーションは、それぞれのサービスプロバイダによって提供される機能を提供することができる。サービスプロバイダアプリケーションの例として、デジタルウォレットアプリケーション、支払アプリケーション(例えば、銀行または支払処理ネットワークによって設計および維持されるモバイルバンキングアプリケーション)、小売業者アプリケーション(例えば、ロイヤルティリワードプログラムへのユーザの参加を可能にする)、交通機関アプリケーション(例えば、プリペイドカードからのクレジットを格納)、チケット発行アプリケーション(例えば、イベントまたは場所へのアクセスのための事前購入チケットを格納し得る)、安全なデータへのアクセスのためのアプリケーションなどを挙げることができる。
【0061】
アクセスデバイス103は、プロセッサ103Aを含む。プロセッサ103Aは、アクセスデバイスタイプ識別子103C、アンテナ103Fを含み得る非接触要素インターフェース103D、および通信ポート103Eを含み得るメモリ103Bに動作可能に結合されてもよい。非接触要素103Dは、ユーザデバイス102の非接触要素インターフェース102Iと通信する(データを送信および/または受信する)ように構成される。一実施形態では、通信ポート103Eは、無線ネットワーク通信(例えば、IEEE 802.11)を容易にするハードウェアを含む。
【0062】
一実施形態では、識別子103Cは、アクセスデバイスの一つ以上の機能(例えば、特定の独自のメッセージフォーマットを処理する能力、典型的な支払取引(特定の小売業者が提供するロイヤルティリワードプログラムなど)を超えて、拡張されたサービスを提供する能力、および/またはアクセスデバイス103がユーザデバイス102がサポートすること(例えば、認証アクションをユーザに促さないこと、または、アクセスデバイスに、アクセスデバイスによるアプリケーション選択の候補として、カスタマイズされたAIDのリストを送信すること)を可能にする、および/または期待する行為の一種を識別するアクセスデバイスタイプ識別子(ADTI)であってよい。一部の実施形態では、識別子103Cは、ADTIをさらに含んでもよいアプリケーション識別子(AID)であってもよい。
【0063】
図3は、カードの形態のユーザデバイス105を示す。ユーザデバイス105は、プラスチック基板などの基板105Aを備える。データアクセスまたはデータ転送デバイスとインターフェースするための非接触要素105Bは、ユーザデバイス基板105A上、またはその内に埋め込まれてもよい。非接触要素105Bは、チップを含んでもよく、近距離無線通信(NFC)技術または他の狭域通信技術を使用して、データを通信および転送する能力を含んでもよい。ユーザデバイス105はまた、アカウント番号、有効期限、およびユーザ名などのユーザ情報を格納し得る、メモリ105Cを含んでもよい。こうした情報は、基板105A上に印刷または型押しされてもよい。基板105Aはまた、その上に磁気ストライプ105Dを有してもよい。
【0064】
図4は、本開示の実施形態によるシステムおよび方法の図を示す。システム400は、リソースプロバイダに関連付けられ得るアクセスデバイス403を含む。また、システムは、ユーザに関連付けられ得るユーザデバイス402を含む。ユーザは、ユーザデバイス403を使用して、アクセスデバイス403と相互作用して、リソースへのアクセスを得ることができる。
【0065】
一部の実施形態では、ユーザは、ユーザデバイス402を使用して、小売業者アクセスデバイス403で購入を実行することができる。購入取引では、ユーザデバイス402は、支払認証プロセスを開始し得るアクセスデバイス403に支払証明書を提供することができる。
【0066】
ユーザデバイス402は、特定のタイプのユーザ情報を格納することができるか、または該ユーザ情報にアクセスすることができる。例えば、ユーザデバイス402は、PAN(プライマリアカウント番号)、支払トークン、名前、住所、CVV、有効期限、および任意の他の適切な情報などのユーザの支払証明書を格納してもよい。こうしたデータは、ハードウェア(例えば、セキュアエレメント)またはソフトウェアを介して安全に保存され得る。
【0067】
さらに、ユーザデバイス402は、一つ以上のユーザアカウントについての情報を含み得るデジタルウォレットアプリケーションを含んでもよい。アカウントは、例えば、クレジットカードまたはデビットカードアカウントなどの支払口座、およびプリペイドカードにリンクされた公共交通機関のアカウントなどの非支払口座、建物アクセスアカウント、特定の小売業者と関連付けられたロイヤルティリワードプログラムアカウント、イベントへのアクセスを取得するために使用され得る事前購入チケット情報を維持するアカウントなどを含む、様々な可能なタイプを含み得る。ユーザは、デジタルウォレットアプリケーションを介して、アカウントを追加し、デフォルトアカウントを設定し、取引用にユーザデバイス402を準備し、および他の支払関連機能を実施することが可能であってもよい。一部の実施形態では、デジタルウォレットアプリケーションでの異なるアカウントが、異なるアプリケーションに関連付けられてもよく、各アプリケーションは、上述のアプリケーション識別子(AID)に関連付けられてもよい。
【0068】
また、ユーザデバイス402は、ユーザデバイス402上の一つ以上のアプリケーションと一つ以上のアクセスデバイスタイプとの間に関連付けが存在するかどうかを示す情報も格納してもよく、各アクセスデバイスタイプは、アクセスデバイスタイプ識別子(ADTI)に一致してもよい。この関連付け情報は、ユーザデバイス402上の複数のアプリケーションに対する関連付け情報を含み得る、ユーザデバイス102(例えば、コンピュータ可読媒体102B)のメモリ内に格納されてもよい。一部の実施形態では、関連付け情報は、ユーザデバイス402上の特定のアプリケーション内に直接格納されてもよい。
【0069】
ユーザデバイス402上のアプリケーションとアクセスデバイスタイプとの間のリンク(すなわち、関連付け)の例示的な図を図7に示す。例えば、ユーザデバイス402が携帯電話である場合、アプリケーション702、704、706、708、710、712は、ユーザデバイス402のコンピュータ可読媒体102B上に格納され、デジタルウォレットアプリケーションにリンクされているアプリケーションであってもよい。各アプリケーション702、704、706、708、710、712は、関連付けられたAIDを有してもよい。端末タイプ識別子714、716、718は、それぞれ異なるアクセスデバイスタイプに対応し得る。各識別子714、716、718は、固有のADTI値であってもよい。ADTI値は、アクセスデバイスに関連付けられたAIDのデータフィールド内にあってもよい。対照的に、汎用端末識別子720は、いずれのADTI値とも関連付けられていないアクセスデバイスに対応し得るため、特定の端末タイプであるとユーザデバイスによって具体的に識別できない。図7に示すように、複数のアプリケーションを単一のADTIに関連付けることができる。
【0070】
図7では、第一、第二、および第三の承認事業体アプリケーション702、704、706は、それぞれ異なるクレジットカード支払アプリケーションに対応し得る。クレジットカード支払アプリケーションの三つすべては、デフォルトで汎用端末識別子720と関連付けられてもよい。すなわち、汎用端末識別子720を有するアクセスデバイスは、任意の特定のADTIまたは端末タイプと関連付けられておらず、単に標準的な支払取引を処理するように構成されてもよい。例えば、アクセスデバイスから汎用端末識別子720を受信するユーザデバイスは、三つのペイメントアプリケーション702、704、706すべてに対するAIDのリストをアクセスデバイスに返信し得る。
【0071】
対照的に、端末タイプ識別子718を有するアクセスデバイスは、「LOYALTY」ADTIであってもよい。クレジットカード支払アプリケーション704およびロイヤルティアプリケーション710の両方は、「LOYALTY」ADTIと関連付けられてもよい。したがって、ユーザデバイスは、端末タイプ識別子718(すなわち、「LOYALTY」ADTI)を有するアクセスデバイスからメッセージを受信すると、さらなる処理のために、アプリケーション704、710の関連付けられたAIDのみをアクセスデバイスに選択的に送信し得る。
【0072】
端末タイプ識別子716を有するアクセスデバイスは、「EVENT」ADTIであってもよい。会場アクセスアプリケーション712は、例えば、将来使用するために事前に購入済みの映画チケットを維持する、映画劇場アプリケーションであってもよい。ユーザデバイスは、端末タイプ識別子716(すなわち、「EVENT」ADTI)を有するアクセスデバイスからメッセージを受信すると、さらなる処理のために、会場アクセスアプリケーション712の関連付けられたAIDのみをアクセスデバイスへ選択的に送信してもよい。
【0073】
端末タイプ識別子714を有するアクセスデバイスは、「TRANSIT」ADTIであってもよい。クレジットカード支払アプリケーション706および交通機関アプリケーション708の両方は、「TRANSIT」ADTIと関連付けられてもよい。クレジットカード支払アプリケーション706は、公共交通機関のシステム上での購入および使用のために、その雇用主によってユーザに提供される場合がある、法人クレジットカードアカウントに対応してもよい。ユーザデバイス402は、端末タイプ識別子714(すなわち、「TRANSIT」ADTI)を有するアクセスデバイスからメッセージを受信すると、さらなる処理のために、アプリケーション706、708の関連付けられたAIDのみを選択的にアクセスデバイスに送信し得る。
【0074】
図4に戻ると、実施形態による方法も説明され得る。以下の説明は、支払処理の説明を含むが、方法は、他の文脈(例えば、安全な場所または安全なデータへのアクセス)で使用することができることが理解される。
【0075】
一実施形態では、ユーザは小売業者における購入用の一つ以上の物品および/またはサービスを選択し、続いて、支払取引を開始することができる。ユーザはユーザデバイス402を介して支払うことを選択できる。一部の実施形態では、ユーザは、デジタルウォレットアプリケーションを起動し、支払口座を選択し、デジタルウォレットアプリケーション上で支払機能を開始することができる。ステップS402で、ユーザは、ユーザデバイス402をアクセスデバイス403の近くに保持し、その結果、両方のデバイスが相互に互いを検出する。
【0076】
一部の実施形態では、続いて、メッセージ(例えば、アプリケーションプロトコルデータユニット(APDU)メッセージ)をユーザデバイス402とアクセスデバイス403との間で交換することによって、非接触取引が実行され得る。メッセージは、アクセスデバイス403からユーザデバイス402に送信されるAPDUコマンドの形態、およびユーザデバイス402からアクセスデバイス403に送信されるAPDU応答の形態であり得る。本方法で説明されるように、NFCが通信用に使用される。しかしながら、実施形態では、他の通信手段(例えば、BLE、RFID)も使用可能である。
【0077】
ステップS404で、ユーザデバイス402は、アクセスデバイス403がサポートする取引のタイプを示すメッセージをアクセスデバイス403から受信するまで、認証データをユーザに促すことを遅らせるべきであると決定し得る。後で(例えば、ステップS408)、ユーザデバイス402は、認証データをユーザに促すかどうかを判定することができる。ユーザデバイス402が相互作用しているアクセスデバイス403のタイプを決定するまで、認証データを求める促しを遅延させることによって、ユーザデバイス402は、より効率的に取引を実行し得る(すなわち、特定のタイプの取引を完了する必要がある場合にのみ、認証データを促す)。
【0078】
ステップS406で、アクセスデバイス403は、利用可能なアプリケーション要求メッセージをユーザデバイス402に送信して、どのアプリケーション(例えば、AIDのリスト)がユーザデバイス402のデジタルウォレットアプリケーション上で利用可能であり得るかに関する情報を要求し得る。利用可能なアプリケーション要求メッセージには、アクセスデバイス403のADTIが含まれる。実施形態によっては、利用可能なアプリケーション要求メッセージは、SELECT「拡張PSPE」(ePPSE)コマンドの形態の、拡張された利用可能なアプリケーション要求メッセージであってもよい。
【0079】
実施形態によっては、ADTIは、アクセスデバイス403によって、SELECTコマンドメッセージ内のデータフィールド内の値として送信されてもよい。以下の表1は、SELECTコマンドメッセージに含まれる可能性のあるコードおよび値の例を示す。以下の表2はさらに、SELECTコマンドメッセージ内のデータフィールドに対するADTI値の例を提供し、これは、SELECTコマンドメッセージに含まれる場合、そのメッセージをSELECT ePPSEコマンド(拡張PPSEコマンド)として表示し得る。ADTI値は、既存のデータフィールドに挿入されてもよく、またはデータフィールドをADTI値に追加してもよい。
【表1】


【表2】
【0080】
表2に示すように、SELECT ePPSEコマンドの形態の拡張された利用可能なアプリケーション要求メッセージは、上述のように、RIDおよびPIX値の連結によって形成されるAIDを含むデータフィールドを含み得る。アクセスデバイスによってサポートされる支払環境を示すために、AIDは、RID値内に支払環境識別子(例えば、325041592E5359532E4444463031(PPSEサポートを示す)または315041592E5359532E4444463031(PSEサポートを示す))を含み得る。SELECT ePPSEコマンドのADTIは、AIDのPIX内に含まれる値であってもよい。ADTI値の例には、表2に示される文字列値が含まれるが、これらに限定されない。したがって、例えば、PPSEをサポートする公共交通機関拡張アクセスデバイスのAIDは、RID(32 50 41 59 2E)およびPIX(54 52 41 4E E 53 49 54)の連結であってもよく、これはさらに32 50 41 59 2E 54 52 41 4E 53 49 54として表され、ユーザデバイスに送信されてもよい。
【0081】
ステップS408で、ユーザデバイス402は、アクセスデバイス403から受信したADTIに部分的に基づいて、ユーザデバイス上のユーザ相互作用が必要かどうかを判定し得る。例えば、ユーザデバイス402は、認証データをユーザに促すかどうかを判定し得る。例えば、ADTI値が「LOYALTY」である実施形態では、ユーザデバイス402は、アクセスデバイス403が、ユーザの支払口座に関連付けられたロイヤルティリワード情報を処理する追加機能を有する支払取引をサポートすることを、ADTIから判定し得る。したがって、ユーザデバイス402は、取引を進行し、アクセスデバイス403に拡張された利用可能なアプリケーション応答メッセージで応答する前に、ユーザに認証データを促すように判定し得る。
【0082】
ステップS410で、ユーザデバイス402は、アクセスデバイス403から受信したADTIと、ユーザデバイス402上に格納された複数のAIDのうちの一つ以上のAIDとの間に関連付けが存在するかを判定し得る。複数のAIDはそれぞれ、ユーザデバイス402上の異なるアプリケーションに対応する。ユーザデバイス402は、例えば、ユーザデバイス402上のデジタルウォレットアプリケーションによって維持される関連付けテーブル(例えば、図7に示す関連付けに類似)にアクセスすることによって、この判定を実施し得る。
【0083】
ステップS412で、ユーザデバイス402は、部分的に、ステップS410で判定された関連付けが存在するかどうかに部分的に基づいて、ADTIに関連付けられた複数のAIDのうちの一つ以上のAIDを含む、拡張された利用可能なアプリケーション応答をアクセスデバイス403に送信してもよい。一部の実施形態では、拡張された利用可能アプリケーション応答メッセージは、拡張PPSE(ePPSE)応答の形態であってもよい。
【0084】
上述のように、SELECT ePPSE応答メッセージは、SELECT PPSE応答メッセージと同じデータフィールドを利用することができ、ファイル制御情報(FCI)を含み得る。これには、限定されるものではないが、アプリケーション定義ファイル(ADF)名、アプリケーションラベル、アプリケーション優先度インジケータ、言語基本設定、アプリケーションのカーネル基本設定を示すカーネル識別子、および/または特定のADFに関する追加情報が含まれ得る。また、各ADF名は、ユーザデバイス402上のアプリケーションのAIDと一致してもよい。したがって、ユーザデバイス402は、一つ以上のディレクトリエントリのアプリケーションリストを返信することができ、各ディレクトリエントリは、ユーザデバイス402上の関連付けられたAIDと一致し、上記に列挙されたデータフィールドの一つ以上を含み得る。例えば、アクセスデバイス403がADTI値「LOYALTY」718を有する場合、ユーザデバイスは、関連付けられたAID(例えば、ロイヤルティアプリケーション710および第二の承認事業体アプリケーション704)を含むアプリケーションリストを送信することを決定し得る。上述のデータフィールドの一部は、以下のようにリスト形式で表されてもよい。
ディレクトリエントリ(‘61){
ADF名=「A0 00 00 00 06 01」
アプリケーションラベル=「My Best Buy Reward」
アプリケーション優先度インジケータ=「0002」


ディレクトリエントリ(‘61’){
ADF名=「A0 00 00 00 03 90 10」
アプリケーションラベル=「My Best Buy Visa」
アプリケーション優先度インジケータ=「0001」


上述の例では、各ディレクトリエントリには、ADF名(16進数形式でのAID名(すなわち、RID || PIX)として表される)、アプリケーションラベルとしてのニーモニック、および数値を有するアプリケーション優先度インジケータが含まれる。一部の実施形態では、1の値は、最高優先度のアプリケーションと一致し得る。したがって、この実施例では、アクセスデバイス403でADTI値「LOYALTY」で取引する場合、「My Best Buy Visa」アプリケーションは、「My Best Buy Rewards」アプリケーションよりも高い優先順位を有してもよい。拡張された利用可能なアプリケーション応答は、FCI発行者の裁量データまたはその他の関連情報などの他のデータも含み得る。
【0085】
ステップS414で、アクセスデバイス403は、ステップS412で受信した関連付けられたAIDの受信したアプリケーションリストに基づいて、相互にサポートされるアプリケーションを決定し得る。アクセスデバイス403は、(例えば、アクセスデバイス403の好ましいアプリケーションも考慮して)アプリケーションリストからアプリケーションを選択するためにために、ユーザデバイス402から受信されたアプリケーション優先度インジケータを含むがこれに限定されない、任意の適切な機構を利用し得ることに留意されたい。次に、アクセスデバイス403は、選択されたAIDを含む「アプリケーション選択」コマンドをユーザデバイス402に送信し得る。
【0086】
図4の以降のステップ(すなわち、S416~S424)に図示される実施形態では、アクセスデバイス403によって選択される特定のアプリケーションは、APDUフォーマットされたメッセージを利用して支払取引を実行するために使用され得る。例えば、アクセスデバイス403を「LOYALTY」ADTI値とする場合、S416~S424のその後のAPDUメッセージは、標準的な支払取引を実行するためだけでなく、この特定の取引ごとに更新され得るユーザのロイヤルティリワードアカウントに関する追加情報を伝達するためにも使用され得る。しかしながら、以下の図5で論じるように、他の実施形態では、アクセスデバイス403は、専有アプリケーション(すなわち、ステップS514)を選択してもよく、その場合、交換される後続のメッセージは、専有プロトコルに従って交換されてもよい。
【0087】
ステップS416で、ユーザデバイス402は、ステップS414でアプリケーション選択メッセージを受信すると、端末取引データ要求を送信して、アクセスデバイス403から取引データを要求してもよく、これは、選択されたAIDに関連付けられた選択されたアプリケーションのプロビジョニングプロセスを完了する必要がある場合がある。実施形態によっては、端末取引データ要求は、「選択AID応答」の形態であってもよく、かつ選択されたAIDを専用ファイル名として含むアプリケーション識別子(AID)ファイル制御情報(FCI)を含んでもよい。端末取引データ要求は、アクセスデバイス403から適切なデータを要求する取引データ識別子のリストを含み得る。取引データ識別子のリストは、処理オプションデータオブジェクトリスト(PDOL)の形態であり得る。
【0088】
ユーザデバイス402によって取引のために要求される取引データは、アクセスデバイス403、端末処理オプション(TPO)、量、およびその他の情報に関連付けられた事業体識別子を含み得る。さらに、取引データは、一つ以上の動的データ要素(例えば、乱数)を含み得る。他の実施形態では、取引情報は、ステップS414でアプリケーション選択メッセージの一部として提供されてもよい。
【0089】
ステップS418で、ユーザデバイス402から端末取引データ要求を受信した後、アクセスデバイス403は、ユーザデバイス402に、ユーザデバイス402によって要求された端末取引データを送信してもよい。一部の実施形態では、端末取引データは、ゲット処理オプション取得(GPO)コマンドの形態で送信されてもよく、処理オプションデータオブジェクトリスト(PDOL)における要求された端末取引データを含んでもよい。端末取引データ(例えば、取引処理オプション(TPO))は、アクセスデバイス403がどの取引データタイプをサポートするかを示すTPOインジケータを含み得る。実施形態によっては、APDUコマンドを利用してアクセスデータプロビジョニングプロセスを容易にするために、アクセスデバイス403は、端末取引データの一部としてゼロドル値をユーザデバイス402に送信し得る。一部の実施形態では、値は任意の量であってもよいことが理解されるべきである。
【0090】
ステップS420で、ユーザデバイス402が端末取引データを受信すると、ユーザデバイス402は関連する認証情報(例えば、カードの認証情報)を取得でき、一連の取引処理情報をアクセスデバイス403に送信し得る。一部の実施形態では、取引処理情報は、「ゲット処理オプション」(GPO)応答の形態で送信され得る。一部の実施形態では、取引処理情報は、ユーザデバイス403に格納されたアカウントデータを読み出すために、アクセスデバイス403がファイルアドレスとして使用可能な、一つ以上のアプリケーションファイルロケータ(AFL)および支払アプリケーションの機能を示すために使用することができるアプリケーション相互交換プロファイルを含んでもよい。
【0091】
取引処理情報は、取引情報、Track-2等価データ(例えば、PAN、有効期限)、および/または追加データを使用して生成された暗号を含む、取引のための任意の認証情報を含み得る。例えば、暗号は、動的データ要素(例えば、乱数)、ユーザデバイス402識別子(例えば、PAN)、および任意選択で、セッション識別子、ゼロドル額などの値、および取引カウンタなどのその他の情報を含み得る、取引情報を使用して生成され得る。また、取引処理情報には、発行者アプリケーションデータ(IAD)、フォームファクタインジケータ(FFI)、カード取引修飾子(CTQ)、暗号情報データ(CID)、および/またはアプリケーションPANシーケンス番号(PAN)が含まれ得る。実施形態によっては、発行者アプリケーションデータ(IAD)は、IADの長さを示す長さインジケータ、取引暗号のバージョンを示す暗号バージョン番号(CVN)、マスターキー(例えば、発行者に関連付けられたマスターキー)を識別するために使用できる派生キーインジケータ(DKI) および/またはカード検証結果(CVR)を含み得る。
【0092】
ステップS422で、アクセスデバイス403が取引処理情報を受信した後、アクセスデバイス403は、ユーザデバイス402にアカウントデータ要求を送信して、ユーザデバイス402に格納され得る追加のアカウントデータを読み出すことができる。一部の実施形態では、アカウントデータ要求は、「記録読み出し」コマンドの形態であってもよく、アクセスデバイス403が読み出しをしようとしているアカウントデータの場所を示すアプリケーションファイルロケータ(AFL)を含んでもよい。アカウントデータ要求に含まれるAFLは、ユーザデバイス402からアクセスデバイス403に提供された取引処理情報におけるAFLに対応してもよい。
【0093】
ステップS424で、アクセスデバイス403からアカウントデータ要求を受信することに応じて、ユーザデバイス402は、AFLによって示される場所に格納されたアカウントデータをアクセスデバイス402に送信してもよい。一部の実施形態では、アカウントデータは「記録読み出し」応答の形態で送信されてもよい。口座データは、例えば、アプリケーションに対して許可されている使用およびサービスに対する発行者の制限、カード所有者の氏名、顧客専用データ、発行者国コード、および/またはAFLの場所でアクセス可能であり、ユーザデバイス402に格納されているその他の口座関連データを示す、アプリケーション使用管理を含み得る。実施形態によっては、アカウントデータは、アクセスデバイス403が、さらなる処理(例えば、顧客のロイヤルティリワードアカウントへのポイントの追加)を行うように構成されてもよい、ロイヤルティリワードプログラムへの参加に関するユーザデータを含んでもよい。前のステップでアクセスデバイス403によって受信されたアカウントデータ、取引処理情報、およびその他のデータは、その後、アクセスデバイス403によって使用されて、支払取引を完了し得る。
【0094】
図5は、本開示の実施形態によるシステム図および方法を示す。システム500は、アクセスデバイス503およびユーザデバイス502を備えるシステム400のシステムと類似していてもよい。しかしながら、図5に示す方法は、ユーザデバイス502上の専有アプリケーション(例えば、非支払取引に使用される)と、専有アプリケーションからの専有メッセージ(例えば、非APDU形式)を受信して処理するよう構成されるアクセスデバイス503との間の取引を示す。アクセスデバイス503は、その後、専有メッセージ交換に基づいて、専有動作を実施するように構成されてもよい。こうした専有取引システムの例を以下に記載し、図8にも図示する。
【0095】
ユーザデバイス502は、携帯電話であってもよい。アプリケーション(例えば、デジタルウォレットアプリケーション)はまた、ユーザデバイス502上に格納されてもよい。アプリケーションは、各アプリケーションが対応するAIDを有するユーザデバイス502上に格納されたアプリケーションにリンクされてもよい。ユーザデバイス502上のアプリケーションのうちの一つ以上は、それぞれ、特定のタイプのアクセスデバイスと関連付けられ得る。
【0096】
アクセスデバイス503は、ユーザがアクセスデバイス503にユーザデバイス502をタップまたは保持して、公共交通機関サービスにアクセスすることを要求する、公共交通機関環境において、デバイスリーダおよび改札口を含み得る。
【0097】
ステップS504で、ユーザデバイス502は、アクセスデバイス503がサポートする取引のタイプを示すメッセージをアクセスデバイス503から受信するまで、ユーザに認証データを促すことを遅延させるように決定し得る。
【0098】
ステップS506で、図4のステップS406と同様に、アクセスデバイス503は、拡張された利用可能なアプリケーション要求メッセージ(例えば、SELECT ePPSEコマンド)をユーザデバイス402に送信して、どのアプリケーション(例えば、AIDのリスト)がユーザデバイス402のアプリケーション上で利用可能であり得るかの情報を要求することによって、取引を開始し得る。SELECT ePPSEコマンドは、「TRANSIT」ADTI値を持つことができる。
【0099】
ステップS508で、ユーザデバイス502は、アクセスデバイス503から受信したADTI(例えば、「TRANSIT」)に少なくとも部分的に基づいて、ユーザデバイス上のユーザインタラクションが必要かどうか(例えば、ユーザに認証データを促すかどうか)を判定し得る。ユーザデバイス502は、アクセスデバイス503が公共交通機関取引をサポートすることをADTIから判定し得る。したがって、ユーザデバイス402は、アクセスデバイス503が、進行するために認証を必要としないと判定し得る。したがって、ユーザデバイス402は、認証データについてユーザに促さない。
【0100】
ステップS510で、ユーザデバイス502は、アクセスデバイス503から受信したADTIと、ユーザデバイス402上に格納された一つ以上のAIDとの間に関連付けが存在するかどうかを判定し得る。図示のために図7を使用する一実施形態では、ユーザデバイス502は、第三の承認事業体アプリケーション706と交通機関アプリケーション708の両方のAIDをアクセスデバイス503に返信してもよい。どちらも“TRANSIT”ADTI値と関連付けられるからである。実施形態によっては、アプリケーション優先度インジケータは、アクセスデバイス503によって使用されて、アクセスデバイス503およびユーザデバイス502の両方によってサポートされるおよび/または好まれる適切なアプリケーションを選択することができる、拡張された利用可能なアプリケーション応答内にも含まれ得る。
【0101】
ステップS512では、図4のステップS412と同様に、ユーザデバイス502は、ステップS510で決定された関連付けが存在するかどうか部分的に基づいて、ADTIに関連付けられた一つ以上のAIDを含む、拡張された利用可能なアプリケーション応答を、アクセスデバイス503に送信してもよい。
【0102】
ステップS514で、アクセスデバイス503は、ステップS512で受信した関連付けられたAIDの受信したアプリケーションリストに基づいて、相互にサポートされるアプリケーションを決定し得る。図5の実施形態では、アクセスデバイス503は、専有アプリケーション(例えば、非APDUフォーマットを使用してメッセージを処理することができる)を選択し得る。当然のことながら、取引自体を処理するために交換されるメッセージは、専有フォーマットを有し得るが、ユーザデバイス上で選択する適切なアプリケーションの決定を容易にするために使用されるメッセージ交換プロセス(S502~S514)は、APDUフォーマットされたメッセージを利用し得る。また、アクセスデバイス503は、(例えば、アクセスデバイス503の好ましいアプリケーションも考慮して)アプリケーションリストからアプリケーションを選択するために、ユーザデバイス502から受信されたアプリケーション優先度インジケータを含むがこれに限定されない、任意の適切な機構を利用し得ることに留意されたい。例えば、アクセスデバイス503は、交通機関アプリケーション708のアプリケーション優先度インジケータが、第三の承認事業体アプリケーション706よりも高いランクにあると判定し得る。したがって、アクセスデバイス503は、交通機関アプリケーションを選択し得る。次に、アクセスデバイス503は、選択されたAIDを含む「アプリケーション選択」コマンドをユーザデバイス502に送信し得る。
【0103】
ステップS516で、ユーザデバイス502およびアクセスデバイス503は、専有メッセージ交換を進行して、取引を実行することができる。この交換は、例えば、ユーザに交通機関カードの再充填が必要であることを促すために、一定の金額をプリペイド交通機関カードから差し引くように専有アプリケーションに指示するメッセージを含み得る。
【0104】
図6は、本開示の実施形態によるシステムおよび方法の図を示す。システム600は、ユーザデバイス602およびアクセスデバイス603を含み得る。この例では、アクセスデバイス603は、端末タイプ識別子またはADTIを含まない。また、ユーザデバイス602は、ユーザデバイス502上に格納されたアプリケーションを有してもよい。アプリケーションは、各アプリケーションが対応するAIDを有するユーザデバイス502上に格納されたアプリケーションにリンクされてもよい。しかしながら、この実施例では、ユーザデバイス602は、アクセスデバイス603から拡張された利用可能なアプリケーション要求メッセージ内で受信されたADTI値を分析または処理するための機能を備えて構成されていない。例えば、ユーザデバイス602上のデジタルウォレットアプリケーションは、ADTI値を処理できない初期バージョンであってもよい。
【0105】
ステップS602で、ユーザは、ユーザデバイス602をアクセスデバイス603の近くに保持してもよく、その結果、両方のデバイスが相互に互いを検出する。
【0106】
ステップS604で、ユーザデバイス602は、ユーザに認証データを促してもよい。この実施形態では、ユーザデバイス602は、アクセスデバイス603から利用可能なアプリケーション要求メッセージを受信するまで促しを遅延せず、アクセスデバイス603から受信されたADTI値に基づいて認証データを促すかどうかの後での決定もしない。代わりに、認証データ(CDCVM)をユーザに必ず促してもよい。
【0107】
ステップS606で、アクセスデバイス603は、第一の利用可能なアプリケーション要求メッセージ(すなわち、拡張された利用可能なアプリケーション要求メッセージ)を生成してもよく、これはSELECT ePPSEコマンドであってもよく、メッセージをユーザデバイス602に送信してもよい。
【0108】
ステップS608で、ユーザデバイス602は、第一の利用可能なアプリケーション要求メッセージを処理できない(すなわち、拡張された利用可能なアプリケーション要求メッセージ内でADTI値を解釈できない)と判定し得る。したがって、ユーザデバイス602は、エラーメッセージ(例えば、「ファイルが見つからない」、または他の適切なフォーマット)をアクセスデバイス603に返信してもよい。
【0109】
ステップS610で、ステップS608から「ファイルが見つからない」エラーメッセージを受信すると、アクセスデバイス603は、第二の利用可能なアプリケーション要求メッセージをユーザデバイス602に送信してもよく(すなわち、非拡張の利用可能なアプリケーション要求メッセージ)、これは、SELECT PPSE/PSEコマンドの形態であってもよい。実施形態によっては、第一の利用可能なアプリケーション要求メッセージと第二の利用可能なアプリケーション要求メッセージ(すなわち、エラーメッセージのために取引に追加された追加時間)との間の経過した追加時間は、最大20ミリ秒(ms)であり得る。
【0110】
ステップS612で、ユーザデバイス602は、アクセスデバイス603に、利用可能なアプリケーション応答(すなわち、アクセスデバイス603から以前に受信したADTIの値から独立して決定される、非拡張の利用可能なアプリケーション応答)を送信してもよい。利用可能なアプリケーション応答(例えば、SELECT PPSE応答)は、ユーザデバイス上に格納されるAIDのリストを含み得る。それはまた、図4のステップS412に記載されたデータフィールドの一部またはすべてを含んでもよい。
【0111】
ステップS614で、アクセスデバイス603は、ステップS612で受信した関連付けられたAIDの受信したアプリケーションリストに基づいて、相互にサポートされるアプリケーションを決定し得る。アクセスデバイス603は、(例えば、アクセスデバイス603の好ましいアプリケーションも考慮して)アプリケーションリストからアプリケーションを選択するためにために、ユーザデバイス602から受信されたアプリケーション優先度インジケータを含むがこれに限定されない、任意の適切な機構を利用し得ることに留意されたい。次に、アクセスデバイス603は、選択されたAIDを含む「アプリケーション選択」コマンドをユーザデバイス602に送信し得る。
【0112】
図6の残りのステップ(すなわち、S616~S624)は、標準支払取引を実行するために、アクセスデバイス603とユーザデバイス602との間で実施されてもよい(すなわち、ADTIを使用して追加機能を提供することなく(例えば、支払取引に基づいて顧客のロイヤルティリワードアカウントにポイントを追加する))。したがって、残りのステップS616~S624は、標準支払取引を処理するために、図4のステップS416~S424とそれぞれ実質的に類似していてもよい。図4のステップの説明は本明細書に組み込まれている。
【0113】
アクセスデバイスが、上述のようにユーザデバイスから適切なデータを受信すると、異なるタイプの取引または相互作用を実行することができる。異なるタイプの取引の二つの例を図8および図9で説明する。
【0114】
図8は、ユーザ101によって操作される建物アクセスシステムおよびユーザデバイス102のブロック図を示す。ユーザデバイス102は、アクセスデバイス810と相互作用して、建物、イベントなどに入るために必要なアクセスデータを取得し得る。アクセスデバイス810は、受信したアクセスデータを現地で照合することができるか、または、遠隔配置された認証サーバコンピュータ(図示せず)と通信することができる。遠隔配置認証サーバコンピュータは、アクセスデータが真性であることを検証し、これを示す信号をアクセスデバイス810に送信し返すことができる。次いで、アクセスデバイス810は、ユーザ101が建物820に入るのを許可するように進行することができる。
【0115】
図9は、取引処理システムのブロック図を示す。ユーザ101は、アクセスデータ(例えば、トークン)をプロビジョニングされたユーザデバイス102を操作する。ユーザ101は、ユーザデバイス102を使用して、小売業者などのリソースプロバイダで物品またはサービスに対して支払うことができる。小売業者は、リソースプロバイダコンピュータ920および/またはアクセスデバイス910を操作することができる。小売業者は、アクワイアラおよび支払処理ネットワークなどの処理ネットワーク940が運用する転送コンピュータ930を介して、発行者によって運用される承認事業体コンピュータ950と通信することができる。
【0116】
支払処理ネットワークは、データ処理サブシステム、ネットワーク、および認証サービス、例外ファイルサービス、ならびに清算および決済サービスをサポートし配信するのに使用される操作を含んでいてもよい。例示的な支払処理ネットワークは、VisaNet(商標)を含んでいてもよい。VisaNet(商標)などの支払処理ネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。具体的には、VisaNet(商標)には、承認要求を処理するVIPシステム(Visa Integrated Paymentシステム)と、清算および決済サービスを実施するBase IIシステムが含まれる。支払処理ネットワークは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。
【0117】
アクセスデバイス910と相互作用するためユーザデバイス102を使用する典型的な支払取引フローを、以下のように説明することができる。ユーザ101は、自身のユーザデバイス102をアクセスデバイス910に提示して、品目またはサービスに対して支払う。ユーザデバイス102およびアクセスデバイス910が相互作用することにより、ユーザデバイス102からのアクセスデータ(例えば、PAN、支払トークン、検証値、有効期限など)が、アクセスデバイス910によって(例えば、接触インターフェースまたは非接触インターフェースを介して)受信される。リソースプロバイダコンピュータ920は、この情報を外部の通信インターフェースを介してアクセスデバイス910から受信することができる。続いて、リソースプロバイダコンピュータ920は、追加の取引情報(例えば、取引額、小売業者固有の情報など)と共にアクセスデバイス910から受信した情報(すなわち、ユーザデバイス103に対応する情報)を含む承認要求メッセージを生成し、この情報を転送コンピュータ930へ電子的に送信することができる。次いで転送コンピュータ930は、承認要求メッセージを受信し、処理し、承認のために処理ネットワーク940へ転送してもよい。
【0118】
一般に、クレジットカードまたはデビットカードの取引の発生に先立ち、処理ネットワーク940は、発行人の取引がどのように承認されるべきかについて、各発行人との確立したプロトコルを有する。取引額が閾値未満であるときなどの場合には、処理ネットワーク940は、承認要求メッセージを生成して承認事業体コンピュータ950に送信することなしに、ユーザのアカウントに関して有する情報に基づいて取引を承認するように構成され得る。取引額が閾値より大きいときなどの他の場合では、処理ネットワーク940は、承認要求メッセージを受信し、ユーザデバイス102に関連付けられた発行者を決定し、検証および承認用に取引用の承認要求メッセージを承認事業体コンピュータ950に転送することができる。取引が承認されると、承認事業体コンピュータ950は、(取引が承認または拒否されたことを示す承認コードを含み得る)承認応答メッセージを生成し、この電子メッセージを外部の通信インターフェースを介して処理ネットワーク940に送信することができる。次いで、処理ネットワーク940は、承認応答メッセージを、転送コンピュータ930に転送することができ、転送コンピュータ930は、承認指示を含む電子メッセージをリソースプロバイダコンピュータ920に、続いてアクセスデバイス910に送信することができる。
【0119】
アクセスデータがトークンの形態である場合、処理ネットワーク940は、トークンを実際の認証情報(例えば、PAN)と交換し得る。その後、いかなる承認要求メッセージも、実際の認証情報を含むように変更されてもよく、検証のために承認事業体コンピュータ950に転送されてもよい。承認事業体コンピュータ950は、承認または拒否を伴う承認応答メッセージを生成できる。承認応答メッセージは、処理ネットワーク940に送信されてもよく、処理ネットワーク940は、認証情報をトークンで置換してもよい。次いで、処理ネットワーク940は、承認応答メッセージをアクセスデバイス910に送信し返すことができる。
【0120】
一日の終わりに、または他の好適な時間間隔で、リソースコンピュータ920と、転送コンピュータ930と、処理ネットワーク940と、承認事業体コンピュータ950との間の清算および決済処理が、取引に対して行われ得る。
【0121】
本発明の実施形態のいずれも、ハードウェア(例えば、特定用途向け集積回路またはフィールドプログラマブルゲートアレイ)を使用する、および/またはモジュール式のもしくは統合された方式で、一般的にプログラム可能なプロセッサを有するコンピュータソフトウェアを使用する、制御ロジックの形態で実装され得ることは理解されるべきである。本明細書で使用される通り、プロセッサは、シングルコアプロセッサ、同じ集積チップ上のマルチコアプロセッサ、または単一回路基板上もしくはネットワーク上の複数の処理装置を含む。本明細書に提供する開示および教示に基づき、当業者は、ハードウェア、およびハードウェアとソフトウェアとの組み合わせを使用して、本開示の実施形態を実装する他のやり方および/または方法を知り、理解するであろう。
【0122】
本出願に記載のソフトウェア構成要素または機能のいずれも、例えば、従来の技術またはオブジェクト指向の技術を使用する、例えば、Java、C、C++、C#、Objective-C、Swift、またはPerlもしくはPythonのようなスクリプト言語など、いずれの好適なコンピュータ言語を使用して、プロセッサによって実行されるソフトウェアコードとして実装されてもよい。ソフトウェアコードは、記憶および/もしくは送信用のコンピュータ可読媒体上に、一連の命令またはコマンドとして記憶されてもよく、好適な媒体には、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはコンパクトディスク(CD)もしくはDVD(デジタル多目的ディスク)などの光媒体、フラッシュメモリ、および類似のものを含む。コンピュータ可読媒体は、そのような記憶または送信デバイスのいかなる組み合わせであってもよい。
【0123】
また、そのようなプログラムはコード化され、送信用に適応したキャリア信号を使用して、インターネットを含む、様々なプロトコルに適合する有線ネットワーク、光ネットワーク、および/または無線ネットワークによって送信されてもよい。このように、本開示の実施形態によるコンピュータ可読媒体は、そのようなプログラムでコード化されたデータ信号を使用して作成されてもよい。プログラムコードでコード化されたコンピュータ可読媒体は、互換デバイスでパッケージ化されてもよく、または他のデバイスから(例えば、インターネットのダウンロードによって)別個に提供されてもよい。いかなるそのようなコンピュータ可読媒体も、単一のコンピュータ製品(例えば、ハードドライブ、CDまたはコンピュータシステム全体)上またはその内部にあってもよく、システムもしくはネットワーク内の異なるコンピュータ製品上またはその内部に存在してもよい。コンピュータシステムは、本明細書で言及する結果のいずれかをユーザに提供する、モニタ、プリンタ、または他の好適なディスプレイを含んでもよい。
【0124】
上の記載は例示であり、限定するものではない。本開示を検討すると、本発明の多くの変形が、当業者に対して明らかとなるであろう。そのため、本開示の範囲は、上の記載を参照して判定されるべきではなく、代わりに、係属中の特許請求の範囲を参照して、それらの全範囲または同等物と併せて判定されるべきである。
【0125】
いずれの実施形態の一つ以上の特徴は、本開示の範囲から逸脱することなく、いずれの他の実施形態の一つ以上の特徴と組み合わせてもよい。
【0126】
「一つの(a)」、「一つの(an)」、または「その(the)」の列挙は、特に反対の指示がない限り、「一つ以上」を意味することを意図している。
【0127】
上で言及したすべての特許、特許出願、刊行物、および記載は、あらゆる目的のためにその全体が参照により本明細書に援用される。いずれも先行技術と認められない。
図1
図2
図3
図4
図5
図6
図7
図8
図9