(57)【要約】支払提供者と支払受領者との間でトークン化されたトランザクションを実行する暗号方法が記載される。トークン化されたトランザクションはトランザクションスキームによって成立する。支払受領者は、販売者アイデンティティと、そのアイデンティティによってトランザクションスキーム提供者によって関連付けられた販売者証明書との提供を受ける。前記支払受領者は、前記販売者アイデンティティとトランザクションシードデータとを前記支払提供者に提供する。支払提供者は、前記販売者アイデンティティを確認し、前記販売者アイデンティティと前記トランザクションシードデータとを用いて、トークン化されたトランザクションについての暗号を生成する。支払提供者は、前記トークン化されたトランザクションの承認のために、前記トランザクションスキーム提供者への送信用の前記暗号を前記支払受領者へ提供する。支払提供者及び支払受領者として動作するための適切なユーザコンピューティング装置及び販売者コンピューティング装置がそれぞれ記載される。
2019525645.tif 000002
【特許請求の範囲】
【請求項１】
トランザクションスキームによって成立する、支払提供者と支払受領者との間のトークン化されたトランザクションを実行する暗号方法であって、前記支払受領者は、トランザクションスキーム提供者によって販売者アイデンティティと前記販売者アイデンティティに関連付けられた販売者証明書との提供を受け、前記方法は、
前記支払受領者が、前記販売者アイデンティティとトランザクションシードデータとを前記支払提供者に提供するステップと、
前記支払提供者が、前記販売者アイデンティティを確認し、前記販売者アイデンティティと前記トランザクションシードデータとを用いて、トークン化されたトランザクションについての暗号を生成するステップと、
前記支払提供者が、前記トークン化されたトランザクションの承認のために、前記トランザクションスキーム提供者への送信用の前記暗号を前記支払受領者へ提供するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法において、前記トランザクションシードデータは前記販売者証明書に関連付けられた鍵によって保護され、前記販売者証明書は前記支払受領者によって前記支払提供者へ提供される、方法。
【請求項３】
請求項２に記載の方法において、前記販売者証明書は、前記支払提供者でのトランザクション処理の１以上の特徴を定義する、方法。
【請求項４】
請求項３に記載の方法において、前記１以上の特徴は顧客検証方法を含む、方法。
【請求項５】
先行する請求項のいずれか１項に記載の方法において、前記トランザクションシードデータは予測不可能な番号を含む、方法。
【請求項６】
先行する請求項のいずれか１項に記載の方法において、前記支払提供者は発行者認証状態情報を前記支払受領者に提供し、前記トークン化されたトランザクション用のトークンが前記支払提供者のアカウントに関連付けられた発行者によって認証されたか否かを示す、方法。
【請求項７】
請求項７に記載の方法において、前記支払提供者は前記発行者認証状態情報を、トランザクションデータ内ではなくメッセージ内で提供する、方法。
【請求項８】
先行する請求項のいずれか１項に記載の方法において、前記トークン化されたトランザクションに関連付けられたトークンは、前記支払受領者とのトランザクションのみに用いるためにロックされる、方法。
【請求項９】
請求項８に記載の方法において、前記トランザクションスキーム提供者は、前記トークンが前記支払受領者とのトランザクションのみに用いるためにロックされるか否かを判定し、この判定を、トランザクション承認を提供する際に用いる、方法。
【請求項１０】
プロセッサとメモリとを含むユーザコンピューティング装置であって、前記プロセッサはウォレットアプリケーションと前記メモリに格納されたモバイル支払アプリケーションとを駆動するよう適合され、前記ユーザコンピューティング装置は前記ウォレットアプリケーションと前記モバイル支払アプリケーションとにより、請求項１乃至９のいずれか１項に記載の方法における前記支払提供者によって実行されるステップを実行するよう適合される、ユーザコンピューティング装置。
【請求項１１】
プロセッサとメモリとを含む販売者コンピューティング装置であって、販売者の販売時点端末として、トランザクションスキームに関連付けられたトランザクションを実行するよう適合され、前記販売者コンピューティング装置は、請求項１乃至９のいずれか１項に記載の方法における前記支払受領者によって実行されるステップを実行するよう適合される、販売者コンピューティング装置。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は、英国特許出願第1613882.8号（2016年8月12日出願）の優先権を主張する。上記出願の開示全体は参照によってここに取り込まれる。
【技術分野】
【０００２】
本願発明は暗号認証とトークン化されたトランザクションとに関する。実施形態では、本開示は認証メカニズムと、このメカニズムを用いたデータフローとに関し、トークン化されたトランザクションにおいて追加の機能（特徴）を提供する。
【背景技術】
【０００３】
支払カード（例えばクレジットカード及びデビットカード）は、金融トランザクションの全ての形態で、非常に広く使用されている。支払カードの使用は、近年の技術的発展に伴い、非常に発展した。元々、トランザクションは、紙のトランザクションカードを用いて紙で行われ、署名によって確認された。このアプローチは、トランザクションを実行するために販売時点（POS）端末上の磁気ストライプリーダを通してスワイプされたトランザクションカードの磁気ストライプを使用することによって、大部分が置き換えられた。トランザクションカードは発展し、集積回路（「チップカード」又は「スマートカード」）を含み、これはPOS端末におけるスマートカードリーダと通信する。このアプローチを用いて、トランザクションは典型的には、カードユーザによって入力される個人識別番号（ＰＩＮ）によって確認される。このタイプのカードは、典型的には、チップカードと関連装置（例えばＰＯＳ端末及びＡＴＭ等）との相互動作のためのＥＭＶ規格のもとで動作する。ISO/IEC7816は、このタイプのカードの動作についての規格を提供する。支払カードと装置とはトランザクションスキーム（例えばMasterCard（登録商標）、American  Express（登録商標）又はVisa（登録商標））の元で提供される。トランザクションメカニズムはトランザクションスキームインフラストラクチャによって成立する。
【０００４】
EMV仕様は接触及び非接触支払プロトコルに関連し、EMVCoウェブサイト（https://www.emvco.com/document-search/）にて公に利用可能であり（EMVCoは主要なトランザクションスキーム提供者の支援によりこれらの仕様を維持する産業体である）、当業者によって容易に考慮される。本開示にて明示的に定義されないEMV技術に関する用語は、当業者によって理解されるように、EMV仕様にて示され且つ定義される。
【０００５】
技術は更に発展し、支払カードを提供した。当該支払カードはEMVのもとで非接触で動作し、ISO/IEC14443規格（標準）のもとに包含される。そのようなカードを使用して、主要アカウント番号（PAN）はＰＯＳ端末によってNFCプロトコルを用いて自動的にカードから読取り可能である。このアプローチは概して、「非接触」又は「近接」支払を指す。これは典型的には、適切なアンテナと共にNFCチップをカード本体に一緒に埋め込むことで可能になる。これにより、無線信号の送受信が可能になる。当該送信は、ＰＯＳ端末内の近接リーダによって発される磁気誘導の磁界によって強化されてよい。効率的なトランザクションが実行されるために、支払カードは近接リーダの近傍に移動する必要があってよい。EMVCoはレベル１の動作容量範囲として０−４ｃｍのもとでその範囲を定義した。
【０００６】
現時点では消費者モバイル装置等のコンピューティング装置を支払カードの代替として使用することが可能である。典型的には、これは、ユーザ証明書へのアクセスを有しモバイル支払アプリケーションを駆動する、ユーザのスマートフォンである。そのようなモバイル支払アプリケーションは典型的には、消費者モバイル装置（以下、「携帯電話」と称する）に安全に提供され、NFC技術規格を用いて支払カードの代替として動作する。これは、現在の携帯電話の大部分に埋め込まれる。そのようなアプリケーションを用いて、ユーザは近接リーダに対して、「タップを基礎とした」トランザクションを実行することができ、また、ユーザのアカウント提供者とのオンラインバンキングインタフェースにおいて、適切なネットワークインタフェース（セルラのローカル無線ネットワーク）上でアカウント管理動作を実行することができる。ユーザは現在、バンキングサービスを得るときに、自身の携帯電話を一般に用いる。
【０００７】
コンピューティング装置を用いてデジタルトランザクションを実行するとき、好適なアプローチはトークン化である。これは、カードの主要アカウント番号（PAN：この番号は発行者銀行でのカード保有者のアカウントに関連付けられる）のトランザクションを、代替のカード番号又はトークンと置換することを伴う。トークン化は典型的には、モバイル装置を用いた、アプリ内購入又はオンライン購入の販売時点トランザクションに用いられる。トークン化を支援するために、カード詳細はウォレット提供者によって支援されるカード保有者の装置上のデジタルウォレットに保持される。トランザクションスキームはデジタル対応サービスを提供してトークンを支援する。トークンはトークンサービス提供者によって管理される。支払プロトコルが提供され、トランザクションが、カードPANではなくトークンを用いてEMV仕様に応じて実行されることを可能にする。モバイルでの仕様のための他の支払技術が存在する。しかし、本願発明は、Mobile  PayPassモバイル支払アプリケーション支援の、トークン化のための支払解決手段（これはDSRP（デジタル安全遠隔支払）と称される）を使用する。これは、Mastercard  Digital  Enablement  Service(MDES)によって提供されるトランザクションスキームインフラストラクチャにおけるデジタル機能を有する。
【０００８】
トークン化は、詐欺を低減することによって消費者及び販売者に利益をもたらす。というのもそれは、EMV支援の暗号処理を使用することを可能にするからである。しかし、トークン化アプローチを更に発展させて、販売者と消費者とにとってトランザクション制御における追加の利益を提供することが望ましい。
【発明の概要】
【０００９】
第１の態様では、本開示は、トランザクションスキームによって成立する、支払提供者と支払受領者との間のトークン化されたトランザクションを実行する暗号方法であって、前記支払受領者は、トランザクションスキーム提供者によって販売者アイデンティティと前記販売者アイデンティティに関連付けられた販売者証明書との提供を受け、前記方法は、
前記支払受領者が、前記販売者アイデンティティとトランザクションシードデータとを前記支払提供者に提供するステップと、
前記支払提供者が、前記販売者アイデンティティを確認し、前記販売者アイデンティティと前記トランザクションシードデータとを用いて、トークン化されたトランザクションについての暗号を生成するステップと、
前記支払提供者が、前記トークン化されたトランザクションの承認のために、前記トランザクションスキーム提供者への送信用の前記暗号を前記支払受領者へ提供するステップと、
を含む方法を提供する。
【００１０】
このアプローチにより、トランザクションの実行において、追加の機能が提供されることが可能である。そのようなメカニズムを用いて販売者における信頼を可能にすることで、販売者がトランザクションの機能を追加し、トランザクションが、安全性の損失無く販売者の要求に沿うことが可能である。
【００１１】
実施形態では、前記トランザクションシードデータは前記販売者証明書に関連付けられた鍵によって保護され、前記販売者証明書は前記支払受領者によって前記支払提供者へ提供される。その場合、前記販売者証明書は、前記支払提供者でのトランザクション処理の１以上の特徴を定義してよい。前記１以上の特徴は顧客検証方法を含んでよい。
【００１２】
前記トランザクションシードデータは予測不可能な番号を含んでよい。
【００１３】
実施形態では、前記支払提供者は発行者認証状態情報を前記支払受領者に提供し、前記トークン化されたトランザクション用のトークンが前記支払提供者のアカウントに関連付けられた発行者によって認証されたか否かを示す。この場合、前記支払提供者は前記発行者認証状態情報を、トランザクションデータ内ではなくメッセージ内で提供してよい。
【００１４】
実施形態では、前記トークン化されたトランザクションに関連付けられたトークンは、前記支払受領者とのトランザクションのみに用いるためにロックされる。このことは、トランザクションに関連付けられた全ての当事者に、重要な安全性の利益を追加的にもたらす。この場合、前記トランザクションスキーム提供者は、前記トークンが前記支払受領者とのトランザクションのみに用いるためにロックされるか否かを判定し、この判定を、トランザクション承認を提供する際に用いてよい。
【００１５】
第２の態様では、本開示は、プロセッサとメモリとを含むユーザコンピューティング装置であって、前記プロセッサはウォレットアプリケーションと前記メモリに格納されたモバイル支払アプリケーションとを駆動するよう適合され、前記ユーザコンピューティング装置は前記ウォレットアプリケーションと前記モバイル支払アプリケーションとにより、上記の方法における前記支払提供者によって実行されるステップを実行するよう適合される、ユーザコンピューティング装置を提供する。
【００１６】
第３の態様では、本開示は、プロセッサとメモリとを含む販売者コンピューティング装置であって、販売者の販売時点端末として、トランザクションスキームに関連付けられたトランザクションを実行するよう適合され、前記販売者コンピューティング装置は、上記の方法における前記支払受領者によって実行されるステップを実行するよう適合される、販売者コンピューティング装置を提供する。
【図面の簡単な説明】
【００１７】
一例として本開示の実施形態が、次の添付図面を参照してここに記載される。
【００１８】
【図１】図１は４当事者モデルを用いたトランザクションシステムを示す。
【図２】図２は、本開示の実施形態を実行するために適合された、図１のトランザクションシステムの実装を示す。
【図３Ａ】図３Ａは、図２のトランザクションシステム実装において使用するユーザコンピューティング装置の機能的要素を示す。
【図３Ｂ】図３Ｂは、図２のトランザクションシステム実装において使用する販売者装置の機能的要素を示す。
【図４】図４は、本開示の方法の実施形態を示す。
【図５】図５は、本開示の実施形態によって提供される機能を概念的に示すものである。
【図６】図６は、本実施形態において、販売者が認証済み販売者として真正且つ適格であると判定する処理を示す。
【図７】図７は、本実施形態において、販売者鍵ペアの管理と販売者証明書の発行との処理を示す。
【図８】図８は、本実施形態において、販売者によって用いられる処理と、認証済みの予測不可能な番号の伝送のためのウォレットとを示す。
【図９】図９は、本実施形態におけるチャネルロックを示す。
【図１０】図１０は、本実施形態における、トランザクションに関連付けられた追加の機能についての選択肢を示す。
【図１１】図１１は、本実施形態における、発行者認証状況を提供する処理を示す。
【発明を実施するための形態】
【００１９】
本開示の一般的及び特定の実施形態が、図面を参照して下記で記載される。
【００２０】
図１は４当事者モデル又は４当事者支払トランザクションスキームのブロック図である。この図は、モデル内に存在する当事者と、カードスキーム内で動作する当事者間で生じる相互作用とを示す。
【００２１】
通常、カードスキーム（支払カードにリンクされた支払ネットワーク）は、３当事者モデル又は４当事者モデル（これが本願発明によって採用される）の２つのモデルのうち１つに基づく。本明細書の目的により、４当事者モデルが下記で更に詳述される。
【００２２】
４当事者はトランザクションネットワークの基礎として使用されてよい。各トランザクションでは、モデルは４つの種別の当事者を含む。すなわち、カード保有者１１０と販売者１２０と発行者１３０とアクワイアラ１４０である。このモデルでは、カード保有者１１０は販売者１２０から商品又は役務を購入する。発行者１３０は、カード保有者１１０へカードを発行した銀行又は他の任意の金融機関である。アクワイアラ１４０は販売者１２０へ、カード処理のための役務を提供する。
【００２３】
モデルはまた、中央のスイッチ１５０を含む。発行者１３０とアクワイアラ１４０との間の相互作用はスイッチ１５０を介してルーティングされる。スイッチ１５０は、１つの特定の銀行のアクワイアラ１４０に関連付けられた販売者１２０が、異なる銀行の発行者１３０に関連付けられたカード保有者１１０から支払トランザクションを受け付けることを可能にする。
【００２４】
４当事者モデル内の当事者間の典型的トランザクションは、主に２つの段階に分割されてよい。すなわち、承認と清算である。カード保有者１１０は、自身のカードを用いた販売者１２０からの商品及び役務を開始する。カードとトランザクションとの詳細は、アクワイアラ１４０とスイッチ１５０とを介して発行者１３０に送信されて、トランザクションを承認する。発行者１３０によって、トランザクションが異常と考慮されるときは、カード保有者１１０は追加の検証処理を実行して、自身のアイデンティティとトランザクションの詳細とを検証するよう求められる。一旦追加の検証処理が完了すると、トランザクションは承認される。
【００２５】
カード保有者１１０と販売者１２０との間でトランザクションが完了すると、トランザクション詳細は清算のために販売者１２０によってアクワイアラ１４０へ提出される。
【００２６】
トランザクション詳細は次いで、アクワイアラ１４０によって、スイッチ１５０を介して関連の発行者１３０にルーティングされる。これらのトランザクション詳細を受信すると、発行者１３０は清算資金をスイッチ１５０に提供する。これは今度は、これらの資金をアクワイアラ１４０を介して販売者１２０に転送する。
【００２７】
それとは別に、発行者１３０とカード保有者１１０とはそれらの間で支払を清算する。それに対して、各トランザクションにつき役務費用が販売者１２０によってアクワイアラ１４０に支払われる。交換費用は、資金清算に対するものとして、アクワイアラ１４０によって発行者１３０に支払われる。
【００２８】
４当事者システムモデルの実用的実装では、特定の当事者の役割は、共に動作する複数の要素を伴ってよい。これは典型的には、消費者カードと販売者端末との間の接触を基礎とした相互作用を超えてデジタル実装（これは、スマートフォン等のユーザコンピューティング装置上の代替物又は仮想カードを用いたものである）へと発展した実装にて当てはまる。
【００２９】
図２は、ユーザコンピューティング装置と販売者の販売時点（POS）端末との間の相互作用にとって適切な実施形態による構造を示す。
【００３０】
カード保有者１は自身のコンピューティング装置を用いる。これは、携帯電話ハンドセット、タブレット、ラップトップ、静的なパーソナルコンピュータ、又は任意の他の適切なコンピューティング装置のいずれか又は全てであってよい（ここでは携帯電話ハンドセット又はスマートフォン１１が示される）。コンピューティング装置は、物理支払カード６の代替として動作し、又は、デジタル領域のみで動作する仮想支払カードとして動作する。スマートフォン１１はこれを、モバイル支払アプリケーションとデジタルウォレットとを用いて実現する（下記の通り）。したがってスマートフォン１１は、NFC又は他の非接触技術を用いて、販売者のPOS端末７と取引することができる。スマートフォン１１はまた、任意の適切なネットワーク接続（例えば公衆ネットワーク）上で、販売者２を示す販売者サーバ１２と相互作用することができる。
【００３１】
トランザクションスキームのインフラストラクチャ（トランザクションインフラストラクチャ）５は、カードスキームを操作するのに必要なコンピューティングインフラストラクチャを提供し、トランザクションと当事者（例えばアクワイアラ３及び発行者４）へのメッセージとのルーティングを提供する。インフラストラクチャ５はそれだけでなく、ウォレットサービス１７を提供して、カード保有者のコンピューティング装置上のデジタルウォレットを支援し、更に、インターネットゲートウェイ１８を提供して、トランザクションインフラストラクチャによる処理のためにインターネットを基礎としたトランザクションを受け付ける。他の実施形態では、ウォレットサービス１７が、トランザクションスキーム提供者と適切な信頼関係を有する第三者によって、類似的に提供されてよい。トークン化を支援するために、トークンサービス提供者１９が存在する（再び、これはトランザクションインフラストラクチャ５の一部として示されるが、適切な信頼関係を有する第三者によって提供されてよい）。トランザクションスキームインフラストラクチャはデジタル対応サービス１６を提供して、トークン化されたデジタルトランザクションの実行を支援し、他のシステムの他の要素と相互作用して、トランザクションが正しく実行されることを可能にする。
【００３２】
トークン化されたトランザクションについては、トランザクションは、カード保有者トークンを自身のカードPANにマッピングすることと、トークンの状態と使用される任意の顧客検証アプローチとを確認（して、それが有効期限内であること又は有効であることを確実に）することとによって、トランザクションスキーム内で確認される。これによって発行者は通常の方法でトランザクションを承認することができる。
【００３３】
図３Ａと３Ｂとは、機能によってユーザコンピューティング装置と販売者POS装置とのそれぞれを概略的に示す。図２の構造における他の要素は、本開示の実施形態にて修正されず、又は、本質的に従来の方法で組織化される。例えば販売者サーバ１２については、これは、クライアント（例えばユーザのスマートフォン上の販売者アプリケーション）と、従来のサーババ／クライアント関係を有するようプログラムされた業界標準のサーバによって実装されてよい。類似的に、トランザクションスキーム内に明示された要素は、トランザクションスキームに関連付けられ適切にプログラムされたサーバによって実行されてよい。概して、トランザクションスキームインフラストラクチャ５はサーバとネットワーク通信とスイッチとを含み、トランザクションが正しくルーティング及び処理されることを可能にする。
【００３４】
図３Ａは、ユーザコンピューティング装置（ここではスマートフォン１１）を示す。スマートフォンは少なくとも１つのプロセッサ３１と少なくとも１つのメモリ３２とを有し、それらの間でアプリケーションの実行のためのコンピューティング環境３３を定義する。コンピューティング環境にて駆動するアプリケーションは、ウォレットアプリケーション３３１と販売者アプリケーション３３２と近接支払システム環境３３３とを含む。これらは下記で詳述される。他の要素（例えば生体アプリケーション３３４）が存在してよい。これは、動作がなされる前に、スマートフォン１１のユーザ１を認証するために使用されてよい。メモリ３２は１以上の物理的又は論理的保護領域３２１を含み、これらのアプリケーションによって必要とされる機密データを保護してよい。そのような安全（セキュア）環境は、（当業者が理解する）様々な方法で実装されてよいが、ここで明示されない。しかし、安全なデータ処理へのアクセスは、典型的には、ウォレットアプリケーションと生体アプリケーションとの両方によって要求される。もちろんスマートフォン１１が携帯通信（と、概して近距離無線通信）に採用され、無線通信システム３４を有する。スマートフォン１１はまたここで、生体センサ（ここでは指紋読み取り機３５）を有する。スマートフォン装置（例えばタッチスクリーンユーザインタフェース３６とカメラ３７）の他の従来的要素が存在してよい。しかし、それらの動作が従来であるとき、それらはここでは明示されない。
【００３５】
図３Ｂは、本実施形態を実装するよう適合されたPOS端末７を示す。この場合、POS端末７はモバイル装置として示されるが、他の実施形態では静的なコンピューティング装置であってよい。POS端末７はまた、少なくとも１つのプロセッサ３１ａと少なくとも１つのメモリ３２ａとを有し、それらの間でアプリケーションの実行のためのコンピューティング環境３３ａを定義する。ここでのアプリケーションは、ユーザスマートフォン１１との通信のための通信インタフェース３４ａとユーザインタフェース３６ａとを用いた販売時点（POS）アプリケーション３３５を含む（他の通信選択肢（例えば典型的には、一層広いネットワーク構造内の他のネットワーク装置への接続）が提供されてよい。）。POSアプリケーション３３５の特徴は下記で詳述される。下記で示されるように、これは販売者POS装置上で実行される特徴であって、販売者サーバ等の他の販売者システム内でも実行される特徴についての議論を含む。
【００３６】
本開示による方法の一般的実施形態が図４に概略的に示される。図４は本願発明の実施形態によるトークン化されたトランザクションの実行時のステップを示す。このアプローチにおいて、支払受領者（販売者）は、販売者アイデンティティと、そのアイデンティティによってトランザクションスキーム提供者によって関連付けられた販売者証明書との提供を受ける。トークン化されたトランザクションについては、販売者は販売者アイデンティティとトランザクションシード（seed）データとを支払提供者（モバイル支払アプリケーションとウォレットアプリケーションとを含む顧客コンピューティング装置によって示される顧客）に提供する（４１０）。顧客装置は販売者アイデンティティを確認し、販売者アイデンティティとトランザクションシードデータとを用いて、トークン化されたトランザクションについての暗号を生成する（４２０）。暗号は、（アプリケーション暗号として）EMV仕様によって生成されてよい。そのとき本開示の機能に関するデータは、適宜意図された又は再度意図された既存のEMVデータフィール内のデータフィールドにて提供される。顧客装置は次いで、トークン化されたトランザクションの承認のためのトランザクションスキーム提供者への送信のために、販売者へ暗号を提供する（４３０）。
【００３７】
図５は、本開示の実施形態によって提供される機能を概念的に示すものである。図５はデジタルウォレット提供者によって提供されるトークンを用いて電子商取引を実行する販売者のためのシステムを概略的に示し、従来のトークン化されたトランザクションに対する改善策を示す。提示される改善は、下記の４つの領域にある。
・ウォレット提供者は販売者が、ウォレット提供者によって保持される支払トークン（これは、支払ネットワーク（又はトークンサービス提供者）によって作成されたもの）を用いることを合法に許可されるか否かを識別することができる。
【００３８】
これによりウォレット提供者は許可された使用にのみ、自身のウォレットの機能を制限することができる。例えば消費者の検証（例えばPIN又はパスコードの入力）を要求すると、トランザクション暗号を生成するウォレットは合法な販売者にのみ制限される。
・販売者はウォレットトランザクションにつき自身が選好するユーザ体験を示してよい。
これによって例えば、販売者は、消費者検証が実行されることを希望しないことと、トランザクションが後に詐欺であると判明したときの関連するリスクを受け付けることを示すことができる。
・販売者は、ウォレットからトランザクション情報を受信して検証することができる。
これにより販売者は、最適化されたユーザ体験を提供することができる。
・例えばウォレットは、販売者に、消費者検証が実行されたか否かと、消費者検証がカード発行者に関わって且つそれによりトランザクションが販売者から発行者への責任移転の利益を受けることができるか否かとを通知することができる。もし消費者検証が実行されなかったとき、販売者は、ウォレットからトークントランザクションデータを受信した後、カード保有者認証処理（例えばSecureCode）を追加的に実行することを選択してよい。
・支払ネットワーク（又はトークンサービス提供者）は、所望であれば、ウォレット内で特定の販売者への特定のトークンの使用をロックすることができる。
【００３９】
これは更に、販売者によって保持されるトークンの盗難を伴う可能なデータ侵害が、トランザクションの実行のために詐欺的な販売者によって提出されないことを確実にすることによって、支払トークンの安全性を向上させる。
【００４０】
本開示の態様が、本願発明の出願人のデジタルセキュアリモートペイメント（ＤＳＲＰ）支払手段に関して記載される。この支払手段によって、カードを介さない（Card  Not  Present）販売者が、トークン化を用いたモバイル支払アプリケーションによって生成される動的トランザクションデータから利益を受けることが可能である。カードを介さない販売者は、物理カード以外のエンティティ（当事者）を用いて取引する販売者である。このとき、販売者は販売者端末にて顧客の物理カードを使用することでの保証を受けることができない。DSRPは、MastercardのDigital  Enablement  Service(MDES)によって可能となるトークン化されたカードに関して使用される。
・Digital  Secure  Remote  Paymentトランザクションは、トランザクションを安全にするためにEMVを基礎とした暗号を用いてモバイル支払アプリケーションによって生成される、動的データ（暗号）を含む。
・Digital  Secure  Remote  Paymentトランザクションは、カード保有者認証を要求すると共に、カード保有者認証が実行されたことの証拠を提供するデータを含む。
・Digital  Secure  Remote  Paymentトランザクションは、カード保有者認証を実行可能な任意の装置（これはモバイル装置と適切に安全化されたウェブベースの実装とを含む）から開始されてよい。
【００４１】
これらのトランザクションは典型的なモバイルの電子商取引状況を含む。ここではカード保有者はモバイルのブラウザ又は特定の販売者アプリケーションを用いて、商品及び／又は役務を購入する。本開示の態様は、DSRPとMDESとの実施形態に関して記載される。しかし、その態様はこれらの技術に限定されず、異なる対応サービスによって可能になるトークン化カードを用いた実施形態にて、異なる支払手段を用いて、使用されてよい。
【００４２】
認証済み販売者と取引するときにDigital  Secure  Remote  Payment（DSRP）又は任意の類似の支払手段を向上させるために使用される５つの新たな概念が下記で示される。これらは下記の通りであり、それぞれは下記で詳述される。
・販売者認証処理
・認証済み予測不可能な番号の伝送
・認証モデルを用いたチャネルロック
・販売者により実行されるユーザ体験
・販売者についての発行者認証状態
【００４３】
販売者を認証し販売者証明書を生成するために使用される処理が記載される。一意の識別子が認証済み販売者に割り当てられる（実施形態ではこれは、Mastercard  Authenticated  Accepter  ID又はMAAIDと称される）。販売者との用語は、トランザクションスキームカードを受け付けて、次いで直接又は間接的にトランザクションを開始することができる人物又は組織につき使用される。
【００４４】
情報の認証済み伝送は、支払手段の安全性を改善するために使用され、また、更に、チャネルロックのために使用されてよい。トークンの使用を確実にする手段は、特定の販売者のトランザクションのみに制限されてよい。
【００４５】
チャネルロック処理は認証モデルを使用して、次のことを可能にする。
１．スキーム提供者が販売者を認証すること。
２．ウォレットが販売者を認証すること。
３．認証システムがウォレット／支払アプリケーションを認証すること。
４．ウォレットが消費者を認証すること。
【００４６】
認証システムは次のことを確認可能である。
・消費者がウォレットによって検証されたこと。
・トランザクションが、真正なトークンを用いてウォレット／支払アプリケーションによって認証された認証済み販売者を用いて、実行されたこと。
【００４７】
少なくとも１つの実施形態にて、販売者はウォレットのユーザ体験を促進する一方で、販売者とウォレットとの間で安全な方法で情報を伝送する。このように販売者は、実行された購入の種別に応じた消費者の支払体験と、販売者のレベルでの消費者検証処理の利用可能性とを、調整可能である。
【００４８】
解決手段が提供されて、発行者認証済みトランザクションと販売者環境との統合が、販売者が発行者認証状態（Issuer  Authentication  Status）（これはトランザクションを提出する前に支払アプリケーションによって伝送される）を信頼することを可能にすることによって、単純化される。これは、販売者がトランザクションについての可能な詐欺責任の移転から利益を受けるなら、代替のカード保有者認証メカニズム（例えばSecureCode）を起動するか否かにつき販売者を支援してよい。
【００４９】
本開示に記載される解決手段は、アクワイアラと発行者とにつき、何らの変更も要求しない。販売者につき定義された技術的変更が存在する。これらは、支払手段トランザクションの安全性を改善し、責任移転が認証済み販売者に付与される機会を追加的に付与するために使用され、販売者に、重大な実用的利益をもたらす。支払アプリケーションは既存の処理を拡張してよく、本開示で提供される追加の機能を統合してよい。
【００５０】
販売者認証処理は次の２つの部分に分割される。すなわち、販売者が、トランザクションスキームブランドを受付可能な販売者であることの判定と、真正な販売者（Genuine  Merchant）に伝送される販売者証明書（Merchant  Certificate）の生成とである。
【００５１】
図６は、第１の部分を示す。すなわち、販売者が認証済み販売者として真正且つ適格であると判定する処理である。販売者が真正であるとの判定に使用される処理は、トークン化された支払トランザクションを用いて、販売者（販売者識別子を用いて識別されたもの）がトランザクションスキームブランドを受け付け可能であることを確認する。
【００５２】
処理のステップは次の通りである：
１．販売者は、認証済み販売者として登録されるトランザクションスキームに適用する（６０１）。
２．トランザクションスキームは支払トークン販売者を伝送する（６０２）。
３．販売者はトークンを用いて１つのオンライントランザクションを実行する（６３０）。
４．トランザクションスキームオンライン承認システムはトランザクションを確認する（６０４）。
【００５３】
トランザクションの成功確認は、販売者が販売者証明書を受信するのに適格な真正な販売者であることを確認するために使用される。他の実施形態では、手作業の、紙を基礎にした又はフォームを基礎にした処理がまた、販売者の適格性を判定するために使用されてよい。
【００５４】
図７は、販売者認証処理の第２の部分を示す。これは、販売者鍵ペアの管理と販売者証明書の発行との処理である。
【００５５】
真正な販売者は、販売者証明書を受信するのに適格である。処理のステップは次の通りである：
１．トランザクションスキームは、一意の識別子（ここではMastercard  Authenticated  Accepter  ID又はMAAID）を販売者（これは、真正な販売者の処理を成功裏に完了したもの）に割り当てる（７０１）。
○MAAIDは既に、真正な販売者によって実行されたトークン化されたトランザクションとは独立して定義されていてよい。
○実施形態ではMAAIDは一意性を確実にするための、１６バイトの世界的に一意の識別子（GUID）である。
２．トランザクションスキームはこの販売者に特有な追加フィールド／データ要素を割り当て／定義することができる。選択的に、販売者はまた、何らかのデータ要素の定義に貢献することができる。
３．販売者は、例えば次の方法のうち１つを用いて、鍵ペアの提供を受ける（７０２）（公的な鍵インフラストラクチャへの参加を可能にするため）。
○トランザクションスキーム鍵管理サービスは、鍵ペア（PKI）を販売者の代わりに生成可能である。
□処理は、鍵と証明書とを管理するときに任意の手作業処理を避けるために、自動化されてよい。
□処理は、鍵管理サービスリソースの制御化にあってよい。
○販売者は、自身の鍵ペアを生成可能である。
【００５６】
販売者は任意の要求された情報をトランザクションスキームポータルにアップロード可能である。あるいは任意の他の方法が使用されて、情報をトランザクションスキーム鍵管理サービスに伝送してよい。実施形態では処理は任意の適切な合意済み暗号方法と鍵種別（例えばRSA又はECC）とを用いる。
４．トランザクションスキームは、トランザクションスキーム鍵管理サービスによって署名されるべき全ての情報を含む、証明書署名要求（CSR）を準備する。実施形態では販売者は証明書署名要求（CSR）を準備して、それを、トランザクションスキーム提供者ポータル又は任意の他の方法を用いて伝送可能である。
５．トランザクションスキーム鍵管理サービスは、証明書認証局（Certification  Authority）を用いて、販売者証明書を生成する（７０３）。販売者証明書はMAAIDを含まなくてはならないことに留意されたい。
６．トランザクションスキームは次いで販売者のためのコンテナを生成する（７０４）。
○もしトランザクションスキームが販売者に変わって鍵ペアを生成したとき、トランザクションスキーム提供者は（例えばPKCS#12を用いて）アーカイブファイルフォーマットを生成して、生成された鍵ペアと販売者証明書と信頼チェーンの全てのメンバー（構成員）とをまとめることができる。
○もし鍵が販売者によって生成されると、トランザクションスキームは（例えばPKCS#7を用いて）証明書の一覧を生成して、販売者証明書と信頼チェーンの全てのメンバー（構成員）とをまとめることができる。
○トランザクションスキームはまた、コンテナに追加の証明書（例えばトークンに関連付けられた証明書とトークンの発行者のトークンとを確認するために使用される証明書）を含むことができる（下記の発行者認証状態（Issuer  Authentication  Status）を参照）。
７．トランザクションスキームは販売者へコンテナを伝送する（７０５）。
８．販売者はコンテナを受信する。
９．販売者認証処理は次の事後条件により完了する。
○販売者は、鍵ペア（PKI）を有する。
○販売者は販売者証明書と関連付けられた信頼チェーンとを有する。
○販売者は信頼チェーンを有し、これはトークン（ICC鍵ペアと発行者（TSP）証明書）に関連付けられた証明書を確認するために使用されてよい。
○販売者は販売者の一意の識別子（MAAID）を有する。
【００５７】
図８は、本実施形態において、販売者によって用いられる処理と、認証済みの予測不可能な番号の伝送のためのウォレットとを示す。予測不可能な番号は、EMV仕様と調和するトランザクションのための、特定の既存の暗号プロトコルにおいて使用される。真正な販売者による認証済みの手法において提供される予測不可能な番号（MAAIDに関連付けられたもの）を使用することは、追加の利益をもたらす（下記）。
【００５８】
DSRPトランザクションにつき使用されるこの処理の基礎的な記述は次の通りである。
１．販売者はDSRPトランザクションの一部として予測不可能な番号（UN）を生成する。
２．UNは販売者とウォレットとの間でAPIを介してウォレットに送信される。
３．ウォレットは、同一の装置内のハードウェア装置内に、又は、装置内又はサーバ上のソフトウェアとして、トークンを含む。
４．UNは暗号の生成の一部として使用される。
５．ウォレットは販売者に暗号を返信する。
６．暗号はオンライン承認のために、（EMV仕様にて定義されたDE55又はDE48フィールドを使用して）DSRPトランザクションの一部として送信される。
【００５９】
認証済みの予測不可能な番号（UN）伝送は、暗号により、販売者に関連付けられたMastercard  Authenticated  Accepter  ID（マスターカード認証済み承諾ID）と、UNの伝送とを関連付ける。認証済みの予測不可能な番号（UN）の伝送処理は次の２つの部分に分割される。
A.販売者によって実行される動作＝販売者処理
B.ウォレットによって実行される動作＝ウォレット処理
【００６０】
認証済みUN（UN）の伝送：販売者処理
販売者は認証済みの番号（UN）を伝送する必要がある。
【００６１】
処理のステップは次の通りである：
１．販売者はMAAIDを提供するチャレンジを要求する（８０１）。
２．ウォレットはその要求を受信し、チャレンジ（４バイト）を生成する。
３．ウォレットはチャレンジとMAAIDとを格納する。
４．ウォレットは販売者にチャレンジを返信する（８０２）。
５．販売者は予測不可能な番号（UN）を生成する（８０３）。
６．販売者は自身の秘密鍵（これはコンテナを用いて伝送され、又は、上記の通り販売者によって生成される）を用いて、次のメッセージに署名する。
【００６２】
MSG=予測不可能な番号|チャレンジ|Mastercard  Authenticated  Accepter  ID
ただし、「|」は連結演算子である。
７．販売者はまた、メッセージを用いて、下記で詳述されるようにトランザクションにおけるユーザ体験についての情報を伝送することができる（８０４）。
８．メッセージを保護するためにはいくつかの選択肢がある。
I.署名回復を用いて、メッセージを署名する。
小さなサイズのメッセージ（４バイトのUNと４バイトのチャレンジと１６バイトのMAAID値とを含む２４バイト）により、情報が係数内に合致することを可能にする。
II.メッセージを署名する。
III.メッセージを暗号化及び署名する。
９．販売者は、DSRP暗号を生成するためにウォレットに送信された要求の一部として、次の要素を伝送する（８０６）。
a.データ（「８」で提示された次の選択肢の１つ）
I.メッセージ回復（message  recovery）により生成された署名
II.メッセージと署名
III.暗号化されたメッセージと署名
b.販売者証明書
認証済みUN（UN）の伝送：販売者処理
ウォレットは予測不可能な番号（UN）を認証する必要がある。必要条件として、ウォレットはトランザクションスキームCA公開鍵と、関連付けられた信頼チェーンとへのアクセスを有さなくてはならない。
【００６３】
処理のステップは次の通りである：
１．ウォレットは販売者によって（又はDSRP処理を誘起するために使用される任意のゲートウェイによって）送信された要求の一部として次の要素を受信する。
a.データ（上記の通り）
I.メッセージ回復（message  recovery）により生成された署名
II.メッセージと署名
III.暗号化されたメッセージと署名
b.販売者証明書
２．ウォレットは、トランザクションスキーム公開鍵を用いて、販売者証明書を確認する（８０７）。署名書違反者リスト（CRL）又はオンライン証明書状態プロトコル（OCSP）を使用することは選択的である。というのも、任意の違反販売者は、オンライン承認の一部として識別され、関連付けられたトークン及び／又はMAAIDが違反となり又は停止されるからである。
３．販売者証明書の確認が成功すると、ウォレットは署名を確認し、販売者によって構築された元のメッセージを回復する（８０８）。
【００６４】
MSG=予測不可能な番号|チャレンジ|Mastercard  Authenticated  Accepter  ID
【００６５】
メッセージ回復により署名を用いることは、支払アプリケーションが販売者によって生成された署名の確認を実行したことの保証をもたらすことに留意されたい。
【００６６】
このようにウォレットは予測不可能な番号（UN）と、チャレンジと、MAAIDとの値にアクセスすることができる。
【００６７】
保証は、暗号を用いた暗示的な証明である。これは、予測不可能な番号（UN）とMAAIDとが、（ウォレットによって使用される）販売者アプリケーションによって使用されてアプリケーション暗号を生成するとき（下記で詳述）に明示的となる。
【００６８】
４．ウォレットはメッセージに含まれたMAAIDの値を、販売者証明書にて定義されたMAAIDに対して確認する（８０９）。
５．MAAIDの確認が成功すると、ウォレットはチャレンジを確認することができる（８１０）。
６．（トランザクションにつきMAAIDに関連付けられた）チャレンジの確認が成功すると、ウォレットは認証済みの予測不可能な番号（UN）と認証モデルを用いたチャネルロック用のMAAIDとを使用する（下記で詳述）。
７．ウォレットはまた、下記で詳述されるように適用される、販売者によって提案されたユーザ体験についての情報を検索することができる。
８．認証済みの予測不可能な番号（UN）の伝送処理は次の事後条件により完了する。
○伝送が、チャレンジ／レスポンス処理の状況で実行されたこと（真新しさ（freshness））。
○ウォレットが、販売者によって生成された認証済みの予測不可能な番号（UN）を有すること。
○ウォレットが販売者のMAAIDを有すること。
【００６９】
図９はチャネルロックを提供する実施形態を開示する。これにより、トークンの使用を制御することができ、それが特定の販売者とのトランザクションにおける特定の状況のみで使用されることができる。
【００７０】
再び、DSRPトランザクションにおいて使用される例示的処理が次の通り記述される。
１．販売者はDSRPトランザクションの一部として予測不可能な番号（UN）を生成する。
２．UNはウォレットに送信され、アプリケーション暗号の生成の一部として使用される。
【００７１】
UNは認証及び承認処理と関連したチャネルロックメカニズムを実現するために使用される。この処理で使用される認証モデルは次の通りである：
１．トランザクションスキームは、上記の処理を用いて販売者を認証することができる。
２．ウォレットは、認証済みの予測不可能な番号の伝送について上述された署名処理を用いて、販売者を認証することができる。
３．承認システムは、EMV仕様と処理とに応じた暗号確認を用いて、ウォレット／支払アプリケーション（カード認証方法：CAM）を認証することができる。
４．ウォレットは、EMV仕様とプロトコルとに再び応じて、CDCVM（消費者装置カード保有者検証方法）等のカード保有者検証方法（CVM）又は任意の同等な方法を用いて、消費者を認証することができる。
【００７２】
承認システムは、CDCVMが実行されたときに消費者がウォレットによって検証されたことと、トランザクション情報から利用可能なカード検証結果（CVR）情報とを用いてそれが成功したこととを、確認することができる。
【００７３】
このアプローチを用いて承認システムは、真正なトークンを用いてウォレット提供者によって認証された認証済み販売者を用いてトランザクションが実行されて、「カード」及び「消費者」認証を伝送する（このときUNとMAAIDとが暗号生成のための入力として使用されるデータの一部である）ことを確認することができる。
【００７４】
この認証モデルはチャネルロックのために使用される。全体アプローチは３つの部分で考慮されてよい。その各々は下記で詳述される。
A.ウォレット／支払アプリケーションによって実行される動作＝ウォレット／支払アプリケーション処理
B.販売者によって実行される動作＝販売者処理
C.承認システムによって実行される動作＝承認システム処理
【００７５】
チャネルロック：ウォレット／支払アプリケーション処理
ウォレットは支払アプリケーションを用いて、DSRPトランザクションの状況でアプリケーション暗号を生成する。支払アプリケーションは、アプリケーション暗号を、認証済みの予測不可能な番号とMAAIDとに、関連付ける。
【００７６】
DSRPトランザクションを実行するとき、アプリケーション暗号生成のための入力として使用されるデータの一覧は下記の表１に示される。本開示にて明示的に定義されない用語は、当業者によって理解されるように、適切なEMV仕様にて示され且つ定義される。
【００７７】
【表１】
2019525645.tif 000003
【００７８】
処理のステップは次の通りである：
１．ウォレットは消費者の検証に責任を有する（９０１）。選択的に、販売者は、販売者選好（これは上記の販売者証明書にて伝送された情報の一部である）に応じて検証処理を調整することによって、ウォレットのユーザ体験において役割を果たしてよい。
２．ウォレットは支払アプリケーションへ、証明書検証の結果を提供する。
３．支払アプリケーションは、データの標準リスト（これは、認証済みの予測不可能な番号の伝送処理の一部として回復された、予測不可能な番号とMAAIDとを含む）を用いてアプリケーション暗号を生成する。
a.MAAIDは、DSRPトランザクション用の更新済みCDOL（これはEMVトランザクションの状況で伝送されるデータ一覧を示す）を用いたアプリケーション暗号生成のための入力として使用されるデータ内の追加情報項目であってよいし、カーネル又は他のコマンドがDSRPトランザクションの状況でアプリケーション暗号の生成のために使用されるときの任意の同等の方法についての入力として使用されるデータ内の追加情報項目であってよい。
b.MAAIDはAC（アプリケーション暗号）生成のための入力として使用される既存のデータ一覧における１以上の要素の値として、アプリケーション暗号生成のための入力に使用されるデータに埋め込まれてよい。
４．ウォレットは、販売者への応答を伝送する前に、発行者認証状態に関連して下記で示される追加の動作（９０３）を実行してよい。
５．ウォレットは販売者にDSRPデータ（これはアプリケーション暗号を含む）を返信する（９０４）。認証済みの販売者が、販売者にロックされたトークンを使用するとき、ウォレットはMAAIDを販売者に返信しなくてよい。
【００７９】
チャネルロック：販売者処理
販売者はウォレットと取得システムとの間のインタフェースである。販売者によって実行される処理のステップは次の通りである：
１．販売者は、ウォレットによって送信された応答の一部として、DSRPデータを受信する。
２．販売者は、オンライン承認のためのトランザクションを提出する前に、発行者認証に関連して下記で示される追加の動作を実行することができる。
３．販売者はトランザクションのオンライン承認のための情報を準備する（９０５）。情報は次のものを含む。
a.認証済み予測不可能な番号の伝送処理の一部として販売者によって生成された予測不可能な番号。
b.ウォレットから受信された、DSRPデータの内容。
４．販売者はトランザクションデータを、オンライン承認のために取得システムに伝送する。
○販売者にロックされたトークンを使用する認証済みの販売者は、オンライン承認メッセージに使用されるトランザクションデータの一部として、MAAIDを提供しなくてよい。MAAIDは、トークンの属性を用いて、承認システムによって検索されることができる（というのもそれは販売者にロックされるので）。
○販売者にロックされたトークンを使用しない認証済みの販売者は、オンライン承認メッセージに使用されるトランザクションデータの一部として、MAAIDを提供しなければならない。
【００８０】
チャネルロック：承認システム処理
承認システムは、DSRPトランザクションの確認に責任を有する。本開示のメカニズムは、チャネルロックの概念を支援する（ただし、要求しない）。承認システムによって実行される処理のステップは次の通りである：
１．承認システムは確認のためのトランザクションデータを受信する（９０６）。
２．承認システムはMAAIDを検索しなければならない。
○販売者にロックされたトークンを用いるとき、識別子は、トランザクションのために使用されるトークンに関連付けられた情報から検索される。MAAIDはデジタル対応の一部として伝送されるトークンの属性として定義されてよい。その情報はトークンサービス提供者のデータベースに格納される。
○トークンが販売者にロックされないとき、MAAIDは、オンライン承認メッセージの一部として販売者によって伝送される。
３．承認システムは次のことを確認する（９０７）。
a.MAAIDは、そのサービス（例えばチャネルロック）に適格である。
b.販売者の証明書（例えば、販売者証明書が取り消されなかったこと）は依然として有効である。
c.トークンは有効であり、停止されなかった。
４．承認システムは、他の基準の中でも、オンライン承認メッセージの一部として検索された予測不可能な番号と、例えばトークンサービス提供者データベースから検索されたMAAIDとを用いて、トランザクションのアプリケーション暗号を確認する。
５．暗号の確認が成功すると、処理が完了する。
【００８１】
図１０は、本実施形態における、トランザクションに関連付けられた追加の機能についての選択肢を示す。
【００８２】
ログイン処理を用いて、清算及び支払トランザクション処理の前に、販売者サーバ１２にホストされた販売者ウェブサイトへユーザにアクセスさせる販売者は、責任移転を許可し且つ装置上のユーザ認証を迂回（バイパス）する（CDCVMバイパス）ことを可能にする販売者証明書を取得することができる。というのも、ユーザ認証は、その支払トランザクションにつきそれが有効であるかもしれないと考慮されるように、販売者ウェブサイト上で既に実行されているからである。
【００８３】
図１０に示すように、販売者は様々な方法（例えば次の通り）を用いて、ウォレットのユーザ体験を促すことができる。
・販売者証明書は、各トランザクションにつき適用可能なポリシー情報（例えば、販売者によって実行される組織的な消費者検証）又は、（例えば低い価値のデジタル商品を販売するときに）ウォレット上での任意の消費者検証を迂回する販売者ポリシーを含むことができる。
・販売者は販売者証明書に含まれる情報と、販売者によって実行された消費者検証についての追加の情報とを用いて、動的モデルを使用することができる。その場合、追加の情報は、上記で定義された認証済みの予測不可能な番号（UN）を伝送するために使用される処理の一部として、ウォレットに伝送されることができる。販売者によって実行される消費者検証が署名され、ウォレットによって使用前に検証されることができ、ウォレットでのユーザ体験を促進させる。
【００８４】
図１１は、本実施形態における、発行者認証状況を提供する処理を示す。このアプローチは、認証済みのデジタル安全遠隔支払（DSRP）トランザクションを支援する改善を可能にする。トークン化されたトランザクションの状況（例えばMDESトークンを用いて生成されたDSRPトランザクション）では、トランザクションスキームは、トランザクション内の既存のビットを用いることができ、それを用いて追加の情報を伝送することができる。可能な解決手段は、アプローチ交換プロファイル（AIP：Application  Interchange  Profile）データオブジェクト内の保存ビットを用いて、トークンが発行者認証を可能か否かを識別する。DSRPトランザクションの状況において、これは次のように実装されてよい。
・AIPバイト２、ビット６、値（バリュー）１は、トークンが発行者認証されたDSRPトランザクションを可能であることを示すことができる。
・AIPバイト２、ビット６、値（バリュー）０は、トークンが発行者認証されたDSRPトランザクションを可能でないことを示すことができる。
【００８５】
このAIP値は、トークンに関連付けられたカードプロファイルの一部である静的な値である。
【００８６】
既存のトランザクションフローを用いて、DRSPトランザクションが発行者認証されたか否かを知ろうとする販売者は、その処理が、DE55又はDE48（ユニバーサルカード保有者認証フィールド：UCAF）を用いながら、DSRPデータを販売者へ伝送するのに使用される方法に依存していると考慮しながら、AIP値を検索しなければならない。特定のUCAFフォーマットがトランザクションスキーム提供者によって定義されてよい。AIP値が販売者によって一旦検索されると、後者は値（２バイト）を解析して、AIPバイト２、ビット６を検索しなければならない。
【００８７】
本実施形態を用いて、発行者認証状態は、トークン情報に基づいて（AIPバイト２、ビット６を用いて定義された発行者認証済みフラグを用いて）、ウォレット／支払アプリケーションによって判定されることができる。発行者認証済みトランザクションは、発行者が、カード保有者を検証する機会に参加した、又はその機会を有したことを意味する。発行者認証状態は、消費者がカード保有者であることを報告するために使用される。
【００８８】
発行者認証状態の管理は次の２つの部分に分割される。
A.ウォレット／支払アプリケーションによって実行される動作（１１０１）＝ウォレット／支払アプリケーション処理これらは、カードと信頼チェーンとを用いて、発行者認証状態を取得し、適切なメッセージを生成及び署名したことを含む。このとき、メッセージと発行者証明書とが、販売者への伝送のために提供される。
B.販売者によって実行される動作（１１０２）＝販売者処理これらは、ウォレットと支払アプリケーションとによって伝送された情報を受信することと、信頼チェーンを用いて発行者とカード証明書とを確認することと、署名を確認することと、発行者認証状態を含むメッセージデータを回復することとを含む。
【００８９】
発行者認証状態についての導入部分が、AIPバイト２、ビット６の使用と比較される追加の機能としてみなされる必要があることに留意されたい。この解決手段を用いるとき、販売者は支払データを解析して発行者認証状態を検索する必要がない。
【００９０】
当業者が理解するように、上記実施形態に対して修正及び変形がなされてよい。また、本開示の趣旨及び範囲から逸脱すること無く、更なる実施形態が開発されてよい。標準及び専用技術に対する参照は、効果的な実装を記述する目的でなされる。当該参照は、本開示の範囲を限定しない。
【図１】
2019525645.tif 000004
【図２】
2019525645.tif 000005
【図３Ａ】
2019525645.tif 000006
【図３Ｂ】
2019525645.tif 000007
【図４】
2019525645.tif 000008
【図５】
2019525645.tif 000009
【図６】
2019525645.tif 000010
【図７】
2019525645.tif 000011
【図８】
2019525645.tif 000012
【図９】
2019525645.tif 000013
【図１０】
2019525645.tif 000014
【図１１】
2019525645.tif 000015
【国際調査報告】
2019525645.tif 000016
2019525645.tif 000017
2019525645.tif 000018