(57)【要約】      （修正有）【課題】３−Ｄセキュア・プロトコルまたは任意の他の認証プロトコルに少なくとも部分的に基づく、改良認証システムを提供する。【解決手段】トランザクション・システム１００におけるカード保有者認証方法は、認証ネットワークにおいて、アカウントを含む認証要求を受信するステップを含む。更に、アカウントに関連するアカウント識別子の一部に少なくとも基づいて、認証サービスを決定するステップを含む。加えて、前記認証サービスおよび前記アカウント識別子の一部に少なくとも基づいて、認証応答を決定するステップを含む。また、アカウントを伴うトランザクションに関連する商人に、認証応答を送信するステップを含む。【選択図】図１
2019067442.tif 000002
【特許請求の範囲】
【請求項１】
カード保有者認証方法であって、
認証ネットワーク・コンピュータにおいて、アカウントを含む認証要求を受信するステップと、
前記アカウントに関連するアカウント識別子の一部に少なくとも基づいて、認証サービスを決定するステップと、
前記認証サービスおよび前記アカウント識別子の一部に少なくとも基づいて、認証応答を決定するステップと、
前記アカウントを伴うトランザクションに関連する商人に、前記認証応答を送信するステップと、
を含む、カード保有者認証方法。
【請求項２】
請求項１記載のカード保有者認証方法において、前記認証サービスを決定する前記ステップが、強化認証が要求されると判定するステップを含む、カード保有者認証方法。
【請求項３】
請求項２記載のカード保有者認証方法において、前記強化認証が、代理サービス・プロバイダによって提供される少なくとも第１サービスを含む、カード保有者認証方法。
【請求項４】
請求項１記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、カード保有者認証方法。
【請求項５】
請求項１記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータが代理サービス・コンピュータである、カード保有者認証方法。
【請求項６】
請求項１記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方法。
【請求項７】
請求項１記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのユーザから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方法。
【請求項８】
装置であって、
プロセッサと、
前記プロセッサと通信可能なメモリであって、前記メモリがプログラム命令を格納し、前記プロセッサが以下の機能を実行するために、前記プログラム命令によって動作する、メモリと、
を含み、前記機能が、
アカウントを含む認証要求を受信する機能と、
前記アカウントに関連するアカウント識別子の一部に少なくとも基づいて、認証サービスを決定する機能と、
前記認証サービスおよび前記アカウント識別子の一部に少なくとも基づいて、認証応答を決定する機能と、
前記アカウントを伴うトランザクションに関連する商人に、前記認証応答を送信する機能と、
を含む、装置。
【請求項９】
請求項８記載の装置において、前記認証サービスを決定する前記機能が、強化認証が要求されると判定する機能を含む、装置。
【請求項１０】
請求項９記載の装置において、前記強化認証が、代理サービス・プロバイダによって提供される少なくとも第１サービスを含む、装置。
【請求項１１】
請求項８記載の装置において、前記プロセッサが認証ネットワーク・コンピュータのコンポーネントである、装置。
【請求項１２】
請求項１１記載の装置において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、装置。
【請求項１３】
請求項１１記載の装置において、前記認証ネットワーク・コンピュータが代理サービス・コンピュータである、装置。
【請求項１４】
請求項８記載の装置において、前記プロセッサが、更に、
前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するプログラム命令によって動作し、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、装置。
【請求項１５】
請求項８記載の装置において、前記プロセッサが、更に、
前記認証要求を受信する前に、前記アカウントのユーザから構成メッセージを受信するプログラム命令によって動作し、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、装置。
【請求項１６】
カード保有者認証方法であって、
認証ネットワーク・コンピュータにおいて、アカウントを含む認証要求を受信するステップと、
前記支払いアカウントに関連するアカウント識別子の一部に少なくとも基づいて、認証サービスを決定するステップと、
前記認証サービスおよび前記アカウント識別子の一部に少なくとも基づいて、認証応答を決定するステップと、
前記認証要求に関連するトークン要求元に、前記認証応答を送信するステップと、
を含む、カード保有者認証方法。
【請求項１７】
請求項１６記載のカード保有者認証方法において、前記認証サービスを決定する前記ステップが、強化認証が要求されると判定するステップを含む、カード保有者認証方法。
【請求項１８】
請求項１７記載のカード保有者認証方法において、前記強化認証が、イシュアー・アクセス制御サーバによって提供される少なくとも第１サービスを含む、カード保有者認証方法。
【請求項１９】
請求項１６記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、カード保有者認証方法。
【請求項２０】
請求項１６記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方
法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願に対する相互引用
本願は、２０１３年１２月９日に出願された米国仮特許出願第６１／９１３，６７０号の優先権を主張する。その内容は、ここで引用したことにより事実上本願にも含まれるものとする。
背景
本明細書において説明する本発明の実施形態は、商品／サービスの支払いのためのトランザクションに関し、更に特定すれば、複数の商業チャネルにわたる認証トランザクションの提供(provision)に関する。
【背景技術】
【０００２】
カード・イシュアー（card issuer）および他の金融機関は、現在、標準的なインター
ネット・トランザクション・プロトコルを提供または使用して、オンライン・トランザクション処理能力を高め、電子商取引の成長を加速化している。ある標準化プロトコルの下では、カード・イシュアーまたは発行元銀行がトランザクションを認証することによって、カード保有者の無許可トランザクションに帰される詐欺および関連する支払取り消しの可能性を低下させることもできる。このような標準化プロトコルの一例に、３−Ｄセキュア・プロトコルがある。認証トランザクションの存在により、オンライン購入の間にカード保有者を認証する努力にも拘わらず詐欺が起きた場合に、イシュアーが詐欺の責任を負う結果になる場合もある。商人は、カード・イシュアーまたは発行元銀行によって、イシュアーが認証したトランザクションに対して支払いが行われることが保証される。３−Ｄセキュア（３ＤＳ）プロトコルは、インターネットに関連するトランザクションのような遠隔トランザクションの間に、顧客を商人に認証するために（例えば、ＶｉｓａまたはＭａｓｔｅｒＣａｒｄ  ＳｅｃｕｒｅＣｏｄｅによって検証される）カード・イシュアーによって提供される認証プログラムと密接に結びついており、これを基礎とする。
【０００３】
３−Ｄセキュア・プロトコルは、既存のセキュア・ソケット・レイヤ（ＳＳＬ）暗号化機能を利用し、オンライン買い物セッションの間カード保有者のイシュアー「認証」によって高められた安全性を提供する。オンライン購入の間カード保有者と彼らのカード・イシュアーとの間において認証セッションを開設するために、Ｍｅｒｃｈａｎｔ  Ｐｌｕｇ  Ｉｎ（ＭＰＩ）と呼ばれる１つのソフトウェアが、メッセージを交換する、情報を渡す、関与者に問い合わせるために、関与する商人によって使用される。３−Ｄセキュア・プロトコル・サービスは、一般に、三ドメイン・モデル、即ち、イシュアー・ドメイン、アクワイアラー(acquirer)、および相互運用性(interoperability)ドメインに基づく。イシュアーは、サービスにおけるカード保有者の登録を管理し、オンライン・トランザクションの間カード保有者を認証する責任がある。アクワイアラーは、インターネット・トランザクションに関与する商人が、アクワイアラーとの契約の下で運営するように手順を定め、認証トランザクションに対してバック・エンド処理を行う責任がある。相互運用性ドメインは、他の２つのドメインと共通プロトコルおよび共有サービスとの間におけるトランザクション交換を容易にする。
【０００４】
カード保有者および彼らの銀行は、「イシュアー・ドメイン」に該当し、商人および彼らの銀行は「アクワイアラー・ドメイン」に該当するであろう。イシュアーおよびアクワイアラー銀行または金融機関とカード・イシュアー・インフラストラクチャ間の通信は、「相互運用性ドメイン」に該当するであろう。３−Ｄセキュアに準拠する銀行および商人とトランザクションを行う間、消費者は、以前と同じインターネット買い物体験を有することができるが、トランザクションを行っている者が本当に記録に載っているカード保有
者であるか否か判定するために、カード保有者の銀行からの別個の認証ウィンドウ、即ち、ｉ−フレーム・エレメントがあることを除く。このプロトコルの下では、オンライン・インターネット購入トランザクションのトランザクション・フローは、次のようにすることができる。
【０００５】
（１）顧客は、暗号化セキュア・ソケット・レイヤ（ＳＳＬ）接続を介して、通常通りに商人ウェブ・サイトにおいて支払いデータを記入する。
（２）次いで、商人はメッセージをＭＰＩを介してディレクトリ・サーバまたはシステムに送り、一方ディレクトリ・サーバまたはシステムは、顧客が３−Ｄセキュア・プログラムに登録されているか否か確認するために、カード・イシュアーに問い合わせる。
【０００６】
（３）カード・イシュアーは、カード保有者が登録されているか否かを示すメッセージでディレクトリに応答し、登録されている場合、カードを発行した金融機関にウェブ・アドレスを提供する。次いで、このメッセージは処理され、応答が商人に転送される。
【０００７】
（４）次いで、商人は、カード保有者とカード・イシュアーとの間において認証セッションを開始するために、カード保有者のデバイスを介してメッセージを発行元金融機関に送る。ここで、商人の名称およびトランザクション額というようなトランザクションの詳細が、確認のためにカード保有者に提示されてもよい。
【０００８】
（５）次いで、発行元金融機関は、商人の名称および金額、個人安全性メッセージというような、トランザクションに関係するカード保有者詳細情報を、認証ウィンドウに入力する。応答エリアには、カード保有者が認証詳細を入力することができる。
【０００９】
（６）顧客は、発行元金融機関がどのようにシステムを実装するのを選択したかに依存して、種々の方法の内１つでトランザクションを承認する。選択肢には、認証トークンを生成するために固定パスワードまたはＰＩＮを入力することから、スマート・カードよび個人カード・リーダ （ＰＣＲ）を利用することにまで及ぶことができ、更に、スマート
・フォン・アプリケーションまたは顧客生物データ・リーダのような顧客のデバイスにおいて認証方法を利用することも含んでもよい。
【００１０】
（７）認証が有効である場合、イシュアーは、トランザクションが有効であったことを示すメッセージを商人に送る。また、イシュアーは、認証が失敗した場合または完了することができなかった場合、商人に通知する。
【発明の概要】
【００１１】
以上で説明した３−Ｄセキュア・プロトコルまたは任意の他の認証プロトコルに少なくとも部分的に基づく、改良認証システムを提供することができれば望ましいであろう。
【図面の簡単な説明】
【００１２】
実施形態の特徴および利点、ならびにこれらを遂行する方法は、以下の詳細な説明を、実施形態例を例示する添付図面と併せて参照することによって、一層容易に明らかになるであろう。
【図１】図１は、本発明の実施形態によるトランザクション・システムのブロック図である。
【図２】図２は、ある実施形態によるトランザクション・システムの一部のブロック図である。
【図３】図３は、ある実施形態によるトランザクション・システムの一部のブロック図である。
【図４】図４は、ある実施形態によるトランザクション・システムの一部のブロック図である。
【図５Ａ】図５Ａと図５Ｂは、ある実施形態によるプロセスを例示する流れ図である。
【図５Ｂ】図５Ａと図５Ｂは、図５Ａと合わさって、ある実施形態によるプロセスを例示する流れ図である。
【図６Ａ】図６Ａ〜図６Ｃは、ある実施形態によるプロセスを例示する流れ図である。
【図６Ｂ】図６Ａ〜図６Ｃは、ある実施形態によるプロセスを例示する流れ図である。
【図６Ｃ】図６Ａ〜図６Ｃは、ある実施形態によるプロセスを例示する流れ図である。
【図７】図７は、図１のトランザクション・システムの１つ以上のコンポーネントを構成することができるコンピュータ・システム／コンピュータ・アーキテクチャのブロック図である。
【図８】図８は、ある実施形態によるプロセスを例示する流れ図である。
【図９】図９は、ある実施形態によるプロセスを例示する流れ図である。
【発明を実施するための形態】
【００１３】
一般に、そして本明細書において説明する新規な実施形態の概念を紹介する目的のために、金融トランザクション用に改良された認証システムを提供するシステム、装置、および方法を提供する。
【００１４】
ある実施形態では、特に、移動体デバイスを含むトランザクションと共に使用されるときに、商人および消費者のために改良されたユーザ体験を可能にする、改良認証技法および方法を提供する。ある実施形態では、トークン化(tokenization)を伴う金融トランザクション（MasterCard International IncorporatedおよびVisa Internationalによって最
近告知されたトークン化規格に従うトランザクションのような）との使用を可能にする認証技法および方法を提供する。
【００１５】
更に、ある実施形態では、認証技法は、カード・イシュアーによって、またはトランザクション毎に決定することができる追加の認証レベルを含むことができ、所与のトランザクションに要求される認証を、ある状況では強化することを可能にする。実施形態は、このような改良認証技法の採択、および合法カードが提示されないトランザクションである拒否トランザクション(declined transaction)の低減を可能にする。
【００１６】
これより、図１を参照しながら、ある実施形態の特徴について説明する。図１は、ある実施形態によるトランザクション・システム１００を示す。ある実施形態によるシステムは、トランザクションを実行するために相互作用する複数のデバイスおよびエンティティを伴う。例えば、支払いカード保有者(payment cardholder)が、金融トランザクションを開始するために、１つ以上の消費者デバイス１０２と相互作用することもある。消費者デバイス１０２は、例えば、移動体電話機、コンピュータ、セット・トップ・ボックス、または他のデバイス（ゲーム・コンソール等のような）を含むことができる。トランザクションは、カード無提示トランザクション(card not present transaction)である（例えば、トランザクションの間に物理カードが商人に提示されない）。実施形態は、このようなカード無提示トランザクションを、過去におけるよりも高い認証レベルで実行することを可能にする。本明細書において使用する場合、消費者デバイス１０２は、本発明の「消費者対話処理ドメイン」の一部であると呼ばれる。
【００１７】
消費者デバイス１０２の各々は、「相互運用性ドメイン」における１つ以上のデバイスと通信することができる。相互運用性ドメインは、少なくとも部分的に認証ネットワーク
１０３によって構成されてもよい。認証ネットワーク１０３は、所与のトランザクションに対してどの種類(kind or kinds)の認証処理が採用されるべきかに関する意思決定に関
与するまたはこれを容易にする任意のデバイスまたはコンピュータを含むことができる。認証ネットワーク１０３は、例えば、（Ａ）消費者インターフェース・アプリケーション・プログラミング・インターフェース（「ＡＰＩ」）１０４を提供する１つ以上のサーバまたはデバイス、（Ｂ）ディレクトリ・サーバ１０６を提供する１つ以上のサーバまたはデバイス、および（Ｃ）代理（ＯＢＯ：on-behalf-of)サービス１０８を提供する１つ以上のサーバまたはデバイスを含むことができる。
【００１８】
「相互運用性ドメイン」内にあるデバイスおよびシステムは、例えば、１つ以上のアクセス制御サーバ１１０および１つ以上のイシュアー１１２のような、「イシュアー・ドメイン」内にある１つ以上のデバイスまたはシステムと通信する。
【００１９】
消費者デバイス１０２および「消費者相互作用ドメイン」を再度参照すると、これらの双方は三ドメイン・モデルにおける「アクワイアラー・ドメイン」と相互作用できることは注記してしかるべきである。アクワイアラー・ドメインは、図１では、少なくとも部分的にブロック１１４によって表され、ブロック１１４は、現在のトランザクションに関わる商人によるサービス、またはこの商人のためにサービスを実行する１つ以上のサーバまたは他のデバイスを代表する。商人サービス・コンポーネント１１４は、例えば、商人によって、または商人によって保持されたサービス・プロバイダによって運営される電子商取引サーバであってもよい。尚、商人サービス・コンポーネント１１４は、消費者デバイス１０２および認証ネットワーク１０３の１つ以上のコンポーネントの双方と相互作用できることを注記しておく。
【００２０】
ある実施形態によれば、本発明は、以前の認証システムよりも改良された顧客体験を、異なるタイプの消費者デバイスにわたる認証相互作用において可能にする。例えば、ある実施形態において、状況によっては商人プラグインの必要性を低減または解消することができる。他の実施形態は、商人が彼らの望む外観および感覚(look and feel)をトランザ
クションの間維持することを可能にする。ある実施形態では、コンテキスト特定メッセージ集合を供給することができる。例えば、トークン化トランザクションに認証サポートを設けることができる。ある実施形態によれば、消費者デバイス１０２と相互運用性ドメインにおけるデバイスとの間の相互作用は、商人によって行われる認証選択に依存することもできる。例えば、商人が、異なる消費者デバイス１０２を伴うトランザクションの認証のために、標準的なＭＰＩを使用することもでき、このような実施形態では、消費者デバイス１０２と相互運用性ドメインにおけるデバイスとの間の相互作用は、認証ネットワーク１０３との相互作用を含むことができる。また、商人が認証トランザクションの間相互作用のためにＡＰＩを使用することを（代わりに）選択することもでき、このような実施形態では、消費者デバイス１０２と相互運用性ドメインにおけるデバイスとの間の相互作用は、消費者インターフェースＡＰＩ１０４との相互作用を含むことができる。いずれのイベントでも、代理サービス・デバイス１０８に関連する規則を適用することによって、１つ以上の代理サービスを実行するためにも、相互運用性ドメインを呼び出すことができる。ある実施形態によれば、任意の代理サービス１０８の適用は、消費者デバイス１０２において消費者によって使用された支払いカードに関連するデータに基づくことができる。例えば、ある実施形態では、所与のトランザクションにおいて任意の代理（ＯＢＯ）サービスを適用すべきか否かは、支払いカード・イシュアーによって決められたＢＩＮ−レベルまたはアカウント−レベルの規則に基づくのでもよい。支払いカード・イシュアーによってＯＢＯサービスに対する意思決定(decisioning)を行う構成を許すことに加えて、またはその代わりに、トランザクション・システム１００は、支払いカードのカード保有者／ユーザによるこのような意思決定の構成も組み込むことができる。ある実施形態では、イシュアーによって構成された規則およびユーザによって構成された規則の双方が有効である場合、どの規則または複数の規則を所与の場合に適用すべきか決定するために、適した規則階層を制定してもよい。ある実施形態では、規則階層は、１つ以上のユーザによって構成された規則を含めるために、イシュアーによって、またはイシュアーに応答して制定されてもよい。ある実施形態では、規則階層は、イシュアー構成入力にしたがって制定された反対の規則を優先して、ユーザによって構成された規則を無視するように動作することもできる。
【００２１】
本発明によるトランザクションには、複数の異なるタイプの代理サービスを使用して適用することができる。例えば、追加の認証または強化された認証をトランザクションに対して行う代理サービスを提供することができる。例えば、金融アカウント・イシュアーが、ある種のアカウントを伴うトランザクションは生物計量認証技法を利用すべきことを決定してもよい。本発明によるこのようなアカウントを伴うトランザクションに、代理サービス１０８を適用することもでき、このようなトランザクションの間に、追加の生物計量認証要求を行わせてもよい。本発明のシステムを伴うトランザクションの間に適用される他のタイプの代理サービスには、例えば、リスク・ベース意思決定サービス、動的検証コード・サービス等を含むことができる。
【００２２】
ある実施形態によれば、相互運用性ドメインとイシュアー・ドメインとの間の通信は、１つ以上の相互作用を伴うことができる（従来の認証解決策とは異なる）。例えば、認証相互作用が、消費者デバイス１０２、消費者インターフェースＡＰＩ１０４、およびイシュアー１１２間の通信を伴うこともできる。このように、イシュアー、商人、および消費者が、ＡＣＳと相互作用する必要なく、またはＭＰＩを使用する必要なく、本発明の認証システムに関与することができる。また、このような相互作用は、１つ以上の代理サービス１０８の適用を呼び出すこともできる。ある実施形態によれば、消費者インタースＡＰＩ１０４の使用により、広範囲のデバイスにわたり、認証ウェブ・サービスの提供が可能になる。更に、代理サービスを全てのイシュアーに利用可能にすることができ、トランザクション体験の向上を図ることができる。例えば、イシュアーは、リスク・ベース意思決定（または「ＲＢＤ」）を利用することを選択してもよく、ＲＢＤサービスは、このイシュアー（またはイシュアーに関連するアカウントの内所定の部分集合）に関連するトランザクションに適用されてもよい。ある実施形態によれば、認証ネットワーク１０３をイシュアー１１２毎に構成可能にしてもよく、メッセージ・タイプ毎に、そしてＢＩＮ（またはアカウント番号）範囲毎に、一意のルーティングを可能にする。例えば、あるエリート・カード(elite card)は、ＲＢＤを提供する代理サービスを使用するように構成されてもよく、そのイシュアーからの全ての他のカード・タイプが認証処理のためにＡＣＳに送られてもよい。ある実施形態では、消費者インターフェースＡＰＩ１０４の使用により、ＡＣＳ１１０および／またはイシュアー１１２がセキュア・チャネルを介して消費者デバイス１０２と相互作用することが可能になる。
【００２３】
認証フローの種々の組み合わせの実証例を図２〜図４に示す（各々において、消費者デバイス１０２は、例示の目的のためにのみ移動体デバイスとして図示されているが、多種多様の消費者デバイスがフローの各々において使用されてもよい）。
【００２４】
図２の認証フローでは、トークン化を実施することができる（即ち、ＰＡＮ（主アカウント番号）の代わりに、トランザクション・フローの少なくとも一部において使用される支払いトークンによる）。この理由のために、消費者デバイス１０２は、トークン要求元サーバ２０２および商人サービス・プロバイダ１１４と相互作用することができる。図２に示す例では、消費者デバイス１０２とトークン要求元２０２との間、および消費者デバイス１０２と商人サービス・プロバイダ１１４との間における相互作用は、ＡＰＩを介してでもよい。同様に、ＡＣＳ１１０とイシュアー１１２（一方で）、および消費者デバイス１０２（他方で）との間において必要な相互作用はいずれも、ＡＰＩを介してでよい。
認証ネットワーク１０３、商人サービス・プロバイダ１１４、およびトークン要求元２０２間における通信は、ＸＭＬ（拡張可能マークアップ言語）、ＪＳＯＮ（Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）、または他の通信フォーマットによって、ウェブに基づくのでよい。
【００２５】
図３では、電子商取引トランザクション−ブロック３０２（認証ネットワーク１０３とのＡＰＩ通信を介して）、ならびに識別および検証（「ＩＤ＆Ｖ」）トランザクション−ブロック３０４（認証ネットワーク１０３とのＡＰＩ通信を介して）のいずれにおいても消費者デバイス１０２を使用することができる実施形態を示す。あるトランザクションでは、認証ネットワーク１０３は、ＡＣＳ１１０と通信し、他のトランザクションでは、認証ネットワーク１０３はイシュアー１１２と通信する。
【００２６】
図４では、種々のメッセージ発信ステップが識別され、本発明のＡＰＩのトークン化トランザクションと併せた使用を示す実施形態が図示されている。Ｓ４０２において、カード保有者／ユーザは消費者デバイス１０２を操作することによって、ＤＩ＆Ｖプロセスを開始する。Ｓ４０４において、トークン要求元２０２は、ＰＡＮおよび全ての適用可能なデバイス情報をＡＰＩを介して認証ネットワーク１０３に送る。
【００２７】
Ｓ４０６において、認証ネットワーク５０３は、要求を受信し、適用可能なプロセス・フローはＩＤ＆Ｖのためであると判定する。このステップの一部として、認証ネットワーク１０３は、しかるべきイシュアー・インターフェースを調べ、このインターフェースを介してＩＤ＆Ｖ要求をイシュアー１１２に送る（該当するイシュアー・インターフェースが利用可能でない場合、認証サーバは、それに応じて、トークン要求元２０２に応答し、プロセスはその時点で終了する）。
【００２８】
Ｓ４０８において、イシュアー１１２は認証ネットワーク１０３に応答して、ＩＤ＆Ｖプロセス・フローを承認する。
Ｓ４１０において、認証ネットワーク１０３はイシュアー応答およびイシュアーＡＰＩ参照を逆にトークン要求元２０２に転送する。
【００２９】
Ｓ４１２において、トークン要求元２０２はＩＤ＆Ｖ確認要求をイシュアー１１２のウェブ・サービスに、消費者デバイス１０２を介して送る。
Ｓ４１４において、イシュアー１１２はＩＤ＆Ｖ確認要求を受信する。
【００３０】
Ｓ４１６において、イシュアー１１２は、要求の有効性を確認し、次いでＡＣＳ（図１、図４では図示せず）はＩＤ＆Ｖ応答メッセージを作る。
Ｓ４１８において、イシュアー１１２はＩＤ＆Ｖ応答をトークン要求元２０２に消費者デバイス１０２を介して戻す。（加えて、イシュアー１１２は、選択したＩＤ＆Ｖトランザクション・レコードを、図示しない、履歴サーバに送ることもできる。）
Ｓ４２０において、トークン要求元２０２はＩＤ＆Ｖ応答を受信する。
【００３１】
Ｓ４２２において、トークン要求元２０２はＩＤ＆Ｖ応答の有効性を確認する。
Ｓ４２４において、肯定的応答の場合、トークン要求元２０２は消費者デバイス１０２のトークン化を完了する。否定的応答の場合、これはこの時点においてトークン要求元２０２から消費者デバイス１０２に伝えられる。
【００３２】
本発明の代理サービスの特徴を含むトランザクション・フローの実証例を、図５〜図６に示す。図５〜図６において、商人プラグイン（「ＭＰＩ」）の使用が示される。しかしながら、実施形態はＭＰＩがないフローも含むことができる（例えば、消費者デバイス１０２と相互運用性レイヤとの間の通信がＡＰＩまたは他の接続を介する場合）。図５Ａ／図５Ｂの実証的実施形態では、１つ以上の代理サービスが処理の間トランザクションに適用される第１シナリオを示す。図５Ａの処理では、カード保有者／ユーザは、商人とのトランザクションを行うために、消費者デバイス１０２と対話処理する（図５Ａ、ブロック５０２）。これは、ユーザが支払いカード・アカウント・データを商人の電子商取引チェックアウト・ページに入力することを含むのでもよい。商人は、カード保有者に関連する支払いアカウント・データを相互運用性ドメイン（例えば、前述のＭＰＩに。例えば、これはＡＰＩコールまたはソフトウェア・コールを介して行うことができる）に送信させる（ブロック５０４）。
【００３３】
ブロック５０６において、ＭＰＩは対応するメッセージを生成し、認証ネットワーク１０３（図１）に送信することができる。再度図５Ａを参照すると、判断ブロック５０８において、認証ネットワーク１０３は（例えば、ディレクトリ・サーバ１０６を介して）、支払いアカウント・データに基づいて（例えば、支払いアカウントのＢＩＮに基づいてというように）ルーティングの決定を行う。このルーティングの決定に基づいて、ある代理サービスを適用すべきであると（例えば、支払いアカウントのイシュアーによって提供される情報に基づいて）判定を行うことができる（判断ブロック５１０において）。この場合も、この判定も認証ネットワーク１０３によって（恐らくディレクトリ・サーバ１０６を介して）行うことができる。
【００３４】
ブロック５１２において、認証ネットワーク１０３／ディレクトリ・サーバ１０６は、次に、メッセージ（例えば、ＸＭＬメッセージ等のような）を、処理のために代理サービス１０８に送信させる。判断ブロック５１４において、ＯＢＯサービス１０８は、それがホストする対応するアプリ(app)が、先にブロック５１２に関して引用したメッセージを
受信したと判定することができる。図５Aに示す実証的な例では、代理サービスの処理１
０８は、カード保有者が低リスク・カード保有者であると（例えば、リスク・ベース意思決定サービスを使用して）判定し(判断ブロック５１６）、ＯＢＯサービス１０８から認
証ネットワーク１０３に応答を認証応答と共に送信する（ブロック５１８）。ここでは認証が成功したと考えられると仮定すると、応答はトランザクション暗号または「ＡＡＶ」（アカウント認証値）のような他のトークンを含むことができる。ＯＢＯサービス１０８によって提供されたデータは、認証ネットワーク１０３からＭＰＩに転送される（図５Ｂ、ブロック５２０）。次いで、図５Ｂの５２２において示すように、ＭＰＩは３ＤＳトランザクションを完了し、要求されたデータ・エレメントを商人１１４（図１）に送信し、商人が、本質的に従来通りのアクワイアラー（図示せず）への認証要求であってもよいものの処理を進める（ブロック５２４）ことを可能にする。次いで、電子商取引トランザクションの従来からの慣例にしたがって、トランザクションを完了することができる。
【００３５】
ある実施形態では、この相互運用性ドメインによる処理は、トランザクションのためにある「設定」または認証強化が求められてもよいという判定を含むことができる。このような例は、図６Ａ／図６Ｂ／図６Ｃによって形成された流れ図において示す。ここで、代理サービス１０８は、カード保有者またはトランザクションが追加の認証方法（１つまたは複数）を要求すると判定し、トランザクションを完了するために、消費者および／または商人によって何らかの追加の処理を実行させる。このように、実施形態は、改良された認証処理を実行することを可能にする。イシュアーは、容易にトランザクションに適用することができる「設定」または追加のサービスを提供することができる。
【００３６】
図５Ａにおけるブロック５０２〜５１４に関係する以上の説明は、図６Ａのブロック６０２〜６１４にも該当する。図６Ａに示す実証的な例では、ＯＢＯサービス処理１０８は、カード保有者が設定プロセスを迂回できる程十分に低リスクではないと判定する（判断ブロック６１６）。言い換えると、リスク・ベース意思決定（ＲＢＤ）に基づいて、ＯＢＯサービス処理１０８は、設定が必要であると判定する。その結果、図６Ｂのブロック６１８に示すように、ＯＢＯサービス処理１０８は、消費者デバイス１０２を介して、および／またはカード・アカウント・イシュアーがカード保有者と連絡を取るために規定した、設定プロセスのためのいずれか１つまたは複数の方法にしたがって、カード保有者／ユーザへのコールを開始することができる。ブロック６２０に示すように、カード保有者は認証要求を受信する。認証要求は、１回使用トークン、電子メール・リンク、プッシュ通知、生物計量認証を行う要求等の内１つ以上を含むことができる。
【００３７】
６１８および６２０において示したプロセス・ステップと併せて、ＯＢＯサービス処理１０８は応答を認証ネットワーク１０３に送信する（ブロック６２２）。この応答は、設定プロセスが実行されようとしていることを示すようにセットされた設定フラグを有するメッセージであってもよい。すると、認証ネットワーク１０３は応答を定式化し、ＭＰＩに送信することができる（ブロック６２４）。この応答は、設定フラグがセットされている。次いで、ＭＰＩはプレゼンテーション・インターフェース・チャネルへの設定コールを、消費者デバイス１０２を介してポストすることによって(via post)開始する（ブロック６２６）。次いで、カード保有者／ユーザは、消費者デバイス１０２を操作することによって 関与し、プレゼンテーション・インターフェースを使用して消費者デバイス１０
２上のウィンドウ内に設定インターフェースを開く（ブロック６２８）。
【００３８】
ブロック６３０において、認証ネットワーク１０３は、プレゼンテーション・インターフェースを介して、ウェブ・コンテンツ（即ち、ＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔ（登録商標）等）をウェブ・ブラウザにｉ−フレーム、ページ・リダイレクション等を介してロードするか、または消費者デバイス１０２におけるソフトウェア開発キット（ＳＤＫ）と相互作用を行い、設定プロセス要求（１つまたは複数）に対するカード保有者の入力／応答に基づいて、ＸＭＬを介して設定応答を使用してＡＣＳ１１０をコールする。
【００３９】
判断ブロック６３２において、ＯＢＯサービス処理１０８は、結果として生じたメッセージを受信し、カード保有者の応答が有効であるか否か判定することができる。次いで、ブロック６３４（図６Ｃ）において、ＯＢＯサービス処理１０８は、認証応答を定式化し、認証ネットワーク１０３／プレゼンテーション・インターフェースに送ることができる。ここでは認証が成功したと考えられると仮定すると、応答は、トランザクション暗号または「ＡＡＶ」（アカウント認証値）のような他のトークンを含むことができる。
【００４０】
ブロック６３６において、認証ネットワーク１０３／プレゼンテーション・インターフェースは、消費者デバイス１０２を介したカード保有者とのセッションを完了し、ＭＰＩによって応答をポストすることができる。次いで、図６Ｃの６３８において示すように、ＭＰＩは３ＤＳトランザクションを完了し、要求されたデータ・エレメントを商人１１４（図１）に送信することができ、本質的に従来通りのアクワイアラー（図示せず）に対する許可認証要求であってもよいものの処理を商人が進める（ブロック６４０）ことを可能にする。次いで、電子商取引トランザクションの従来の慣例にしたがって、トランザクションを完了することができる。
【００４１】
図７は、図１のトランザクション・システム１００の１つ以上のコンポーネントを構成することができるコンピュータ・システム／コンピュータ・アーキテクチャのブロック図である。例えば、図７に示すコンピュータ・システム７０２は、ディレクトリ・サーバ１０６および／またはＯＢＯサービス・コンピュータ１０８および／または認証ネットワーク１０３の他のコンポーネントの内１つ以上を実装することができる。以下で更に説明するが、コンピュータ・システム７０２は、本明細書において説明した機能の内１つ以上を設けるために、本発明の形態にしたがってプログラミングすることができる。
【００４２】
これより図７を参照すると、コンピュータ・システム７０２は、そのハードウェア態様
では従来通りでもよいが、本明細書において説明したようにこれを機能させるためにソフトウェアによって制御することができる。例えば、コンピュータ・システム７０２は、従来のサーバ・コンピュータ・ハードウェアによって構成されてもよい。
【００４３】
コンピュータ・システム７０２は、通信デバイス７０１に動作可能に結合されたコンピュータ・プロセッサ７００、記憶デバイス７０４、入力デバイス７０６、および出力デバイス７０８を含むことができる。
【００４４】
コンピュータ・プロセッサ７００は、１つ以上の従来のプロセッサによって構成することができる。プロセッサ７００は、所望の機能を設けるためにコンピュータ・システム７０２を制御するように、本明細書において説明したプログラム命令に含まれるプロセッサ実行可能ステップを実行するように動作する。
【００４５】
通信デバイス７０１は、例えば、他のデバイス（トランザクション・システム１００の他のコンポーネントのような）との通信を容易にするために使用することができる。例えば、通信デバイス７０１は、１つ以上の移動体通信ネットワーク（図示せず）を介した無線(over-the-air)通信を容易にするために複数の通信ポートおよびインターフェースを含むことができ、および／または通信デバイス７０１はインターネットによるおよび／または１つ以上の私用または専用データ通信ネットワークを介した、サービスに対する複数のコールを容易にすることができる。
【００４６】
入力デバイス７０６は、データをコンピュータに入力するために通例使用される任意のタイプの周辺デバイスの内１つ以上を含むことができる。例えば、入力デバイス７０６は、キーボードおよびマウスを含むのでもよい。出力デバイス７０８は、例えば、ディスプレイおよび／またはプリンタを含むことができる。
【００４７】
記憶デバイス７０４は、任意のしかるべき情報記憶デバイスを含むことができ、磁気記憶デバイス（例えば、ハード・ディスク・ドライブ）、ＣＤおよび／またはＤＶＤのような光記憶デバイス、および／またはランダム・アクセス・メモリ（ＲＡＭ）およびリード・オンリ・メモリ（ＲＯＭ）デバイス、ならびにいわゆるフラッシュ・メモリのような半導体メモリ・デバイスの組み合わせを含む。このような情報記憶デバイスの内任意の１つ以上は、コンピュータ読み取り可能記憶媒体またはコンピュータ使用可能媒体、あるいはメモリであると見なすことができる。
【００４８】
記憶デバイス７０４は、プロセッサ７００を制御するための１つ以上のプログラムを格納する。これらのプログラムは、コンピュータ・システム７０２のプロセッサ実行可能プロセス・ステップを含むプログラム命令（コンピュータ読み取り可能プログラム・コード手段と呼んでもよい）を含み、コンピュータ・システム７０２に、本明細書において説明した１つ以上のシステム・コンポーネントの機能を実現させるために、プロセッサ７００によって実行される。
【００４９】
これらのプログラムは、コンピュータ・システム７０２におけるリソースの動作(activities)および共有を管理ならびに調整するように、そしてコンピュータ・システム７０２において実行するアプリケーション・プログラム（以下で説明する）のためのホストとして役割を果たすように、プロセッサ７００を制御する１つ以上の従来のオペレーティング・システム（図示せず）を含むことができる。
【００５０】
記憶デバイス７０４によって格納されたプログラムは、例えば、トランザクション処理アプリケーション・プログラム７１０を含むことができる。トランザクション処理アプリケーション・プログラム７１０は、コンピュータ・システム７０２が本開示において説明
したトランザクション関係機能の内１つ以上を実行することを可能にするように、プロセッサ７００を制御することができる。例えば、これは、少なくとも部分的に、現在のトランザクションにおいて関与するアカウントに関連するアカウント番号のような、アカウント関係情報に基づいて、所与のトランザクションに対してどのようなタイプ(type or types)の認証サービス（１つまたは複数）を実行すべきか判定することを含むのでもよい。コンピュータ・システム７０２によって処理されるトランザクションは、支払いトランザクションおよびＩＤ＆Ｖ（トークン化）トランザクションを含むことができる。
【００５１】
また、記憶デバイス７０４は、１つ以上の判断規則７１２も格納することができる。判断規則７１２は、コンピュータ・システム７０２がトランザクション毎にどの認証サービス（１つまたは複数）を適用すべきかどのように決定するかについて示す。先に注記したように、判断規則は、カード・アカウント・イシュアーおよび／またはカード・アカウント・ユーザのいずれかまたは双方からの入力にしたがって構成されなければならない(subject to)のでもよい。
【００５２】
加えて、記憶デバイス７０４は、コンピュータ・システム７０２がトランザクション・システム１００の他コンポーネントとのデータ通信に関与することを可能にするために必要とされることがあるような、データ通信プログラム７１４も格納することができる。
【００５３】
また、記憶デバイス７０４は、図示しない他のプログラムも格納することができ、コンピュータ・システム７０２はこれらのプログラムも実行することができる。例えば、このようなプログラムは報告アプリケーションを含むことができる。報告アプリケーションは、コンピュータ・システム７０２によって実行された動作についての報告を求めるシステム・アドミニストレータからの要求に応答することができる。また、他のプログラムには、例えば、ウェブサイト・ホスティング・プログラム、データベース管理プログラム、デバイス・ドライバ等も含むことができる。
【００５４】
また、記憶デバイス７０４は、コンピュータ・システム７０２の動作のために要求される１つ以上のデータベース７１６も格納することができる。
本発明の教示によれば、カード・アカウント・イシュアーおよび／またはカード・アカウント・ユーザによって認証サービスを構成できることにより、トランザクションの安全性および利便性に対するイシュアーおよび／またはアカウント・ユーザの目標と一致する認証プロセスを予め念頭に置く(allow for)ことができる。例えば、ある実施形態では、
特定のイシュアーが、その最上層のアカウント保有者のために、非常に大量の購入に対してのみ設定を実行し、設定が行われたとき、アカウント保有者に都合が良い特定の生物計量プロセスが利用されることを指定することもできる。ある実施形態では、最上層の顧客のためにイシュアーによって指定された規則が、いくつかまたは殆どのトランザクションについてはＲＢＤを迂回させることもできる。認証ネットワーク１０３は、特定のイシュアーが構成した規則が特定のトランザクションに適用可能であることを、トランザクションに対して提出された支払いアカウント番号（または、ＢＩＮのような、その一部）に基づいて判定することができる。ある実施形態では、他のアカウント保有者に対して、設定が可能な従来のＲＢＤプロセスを適用可能にすることもできる。
【００５５】
本開示の他の教示によれば、アカウント・ユーザが、認証処理に関するユーザの好みを実現するように、規則を構成することを許されてもよい。例えば、ユーザが、生物計量認証またはＰＩＮ入力による認証に対する好みを示すことを許されてもよい。ある実施形態では、トランザクション・システム１００／認証ネットワーク１０３は、イシュアーの好みをユーザの好みと調和させるように動作することもできる。ある実施形態では、イシュアーの認証の好みとユーザの認証の好みとの間に解決できない矛盾がある場合、トランザクション・システム１００／認証ネットワーク１０３は、イシュアーの好みを優先させる
ように動作するのでもよい。
【００５６】
ある実施形態では、認証規則が少なくともある場合には、商人による構成に従うのでもよい。例えば、商人が顧客のアカウント情報（および／または支払いトークン）をファイル内に有しており、この商人が顧客を非常に良く知っている（および／または顧客に対するそれ自体のリスク評価を行い満足がいく結果が得られた）場合、商人は、認証ネットワーク１０３によるＲＢＤ／可能な設定を迂回することを優先させることができる。このように、所与のアカウント番号／支払いトークンおよび所与の商人に対して、商人からの構成データ入力にしたがって認証処理を決定できるように、トランザクション・システム１００／認証ネットワーク１０３によってトランザクションを処理することができる。他の実施形態例によれば、商人は、アカウント・イシュアーが３ＤＳモデルによる認証をサポートしなければトランザクションが完遂しないように、認証意思決定を構成することもできる。認証ネットワーク１０３は、提出されたアカウント番号に対するＢＩＮに基づいて、この点についての判定を行うことができる。
【００５７】
場合に応じてイシュアー、ユーザ、または商人から入力された構成データは、この構成データ入力に基づくトランザクションの実行に先立って、当事者(party in question)か
ら、管理運用または設定動作の間に、認証ネットワーク１０３によって送信および受信されたメッセージによって提供されてもよい。
【００５８】
図８および図９は、ある実施形態によるプロセスを例示する流れ図である。
図８および図９は、本発明の形態にしたがってＩＤ＆Ｖ（識別および検証）を実行するプロセス例を示す。当業者には理解されようが、ＩＤ＆Ｖはトークン化動作と関連付けて実行されてもよい。
【００５９】
図８のシナリオでは、ＩＤ＆Ｖは設定なしで実行される。図８のブロック８０２において、トークン要求元２０２（図２）はＩＤ＆Ｖ要求を認証ネットワーク１０３に送る。図８を参照し続けると、判断ブロック８０４において、認証ネットワーク１０３は、支払いアカウント・データに基づいて（例えば、支払いアカウントのＢＩＮに基づいてというように）、（例えば、図１のディレクトリ・サーバ１０６を介して）ルーティング決定を行う。ブロック８０６において、認証ネットワーク１０３は、認証要求を含むメッセージを定式化して送る。このメッセージはイシュアーＡＣＳ１１０（図１）に送ることができ、ブロック８０４において、特定のＡＣＳが決定され、および／またはメッセージ／要求の内容が決定される。
【００６０】
判断ブロック８０８において、イシュアーＡＣＳ１１０は、所望のタイプの認証プロセスを選択する。判断ブロック８１０において、イシュアーＡＣＳ１１０は、カード保有者の識別を判定し、および／または現在の認証要求にどの程度のリスクを伴うか判定する。図８に示す実証的な例では、イシュアーＡＣＳ１１０は、この要求はリスクが低いと判定し、認証ネットワーク１０３に応答を認証ステータスと共に返信する（ブロック８１２）。ここでは認証が成功したと考えられると仮定すると、応答は、暗号または「ＡＡＶ」（アカウント認証値）のような他のトークンを含むことができる。
【００６１】
ブロック８１４において、認証ネットワーク１０３は、認証ステータスを示すために、応答を定式化してトークン要求元２０２に送る。次いで、ブロック８１６において、トークン要求元２０２はトークン化プロセスを継続することができる。
【００６２】
ある実施形態では、トランザクション・システム１００の認証ネットワーク１０３または他のコンポーネントにおける処理は、ＩＤ＆Ｖ要求には何らかの「設定」または認証強化が要求されるかもしれないという判定を含むことができる。このような例を図９に提示
された流れ図に示す。
【００６３】
以上の図８に関連付けたブロック８０２〜８０６の説明は、図９に示すブロック９０２〜９０６にも適用可能である。図９の判断ブロック９０８では、イシュアーＡＣＳ１１０は所望のタイプの認証プロセスを選択する。この実証的な例では、イシュアーＡＣＳ１１０は（例えばＲＢＤにしたがって）設定が要求されると判定したと仮定する。これは、ユーザ認証プロセス（ブロック９１０）を含むことができ、このプロセスは、銀行顧客ログイン手順、トークン有効性判断等のような機能を実行するために、カード保有者／ユーザが顧客デバイス１０２と対話処理することを伴うのでもよい。
【００６４】
判断ブロック９１２において、イシュアーＡＣＳ１１０は、ブロック９１０において与えられた成果／ユーザ応答を考慮することができ、これに基づいて、カード保有者の識別を判定することができ、および／または現在の認証要求にどの程度リスクが伴うか判定することができる。図９に示す実証的な例では、イシュアーＡＣＳ１１０は、要求のリスクは低いと判定詞、認証ネットワーク１０３に応答を認証ステータスと共に返送する（ブロック９１４）。ここでは認証が成功したと考えられると仮定すると、応答は暗号または「ＡＡＶ」（アカウント認証値）のような他のトークンを含むことができる。
【００６５】
ブロック９１６において、認証ネットワーク１０３は応答を定式化し、トークン要求元２０２に送り、認証ステータスを示すことができる。次いで、ブロック９１８において、トークン要求元２０２はトークン化プロセスを継続することができる。
【００６６】
ある実施形態では、改良認証処理は、部分的に、変更メッセージングを含む既存の３−Ｄセキュア・トランザクション方法に基づく（例えば、追加の購入者情報フィールド、リスク・ベース意思決定データ、および他の任意データを含む）。例えば、トークン化プロセスのような新たなプロセスをサポートするために、追加のメッセージ・タイプが設けられる。デバイス間における相互作用を改良するために、ウェブ・サービス・インターフェースが設けられ、イシュアーが代理サービスおよび他のサービスを指定することを可能にするルーティングが設けられる。
【００６７】
本明細書および添付した特許請求の範囲において使用される「支払いアカウント識別子」という用語は、ＰＡＮ（主アカウント番号）、およびトークン化システムにしたがってＰＡＮの代わりに使用される支払いトークンを含む。
【００６８】
以上、支払いアカウント・システム・プロセスのコンテキストの範囲内で本開示の教示について説明したが、これらの教示は、顧客ロイヤルティ(customer loyalty)アカウント、アクセス・アカウント（例えば、部屋、建物、計算リソース、および／またはウェブページ・アカウントへの）、および他のタイプの金融アカウントのような、他のタイプのアカウントにも同様に適用可能である。本明細書および添付した特許請求の範囲において使用される場合、「アカウント」という用語は、支払いアカウントおよび他のタイプのアカウントを含み、以上で述べたものを含むがそれらには限定されず、「アカウント識別子」という用語は支払いアカウント識別子および他のタイプのアカウントの識別子を含む。
【００６９】
以上の本明細書におけるプロセスの説明および例示は、プロセス・ステップを実行する固定順序を暗示すると考えてはならない。逆に、プロセス・ステップは、少なくともあるステップの同時実行を含む、実用可能な任意の順序で実行することができる。
【００７０】
以上、具体的な実施形態例に関連付けて本発明について説明したが、添付した請求項において記載される発明の主旨および範囲から逸脱することなく、当業者には明白な種々の変更、代用、および変容(alternation)を、開示した実施形態に対して行えることは理解
されてしかるべきである。
【図１】
2019067442.tif 000003
【図２】
2019067442.tif 000004
【図３】
2019067442.tif 000005
【図４】
2019067442.tif 000006
【図５Ａ】
2019067442.tif 000007
【図５Ｂ】
2019067442.tif 000008
【図６Ａ】
2019067442.tif 000009
【図６Ｂ】
2019067442.tif 000010
【図６Ｃ】
2019067442.tif 000011
【図７】
2019067442.tif 000012
【図８】
2019067442.tif 000013
【図９】
2019067442.tif 000014
【手続補正書】
【提出日】平成31年1月8日(2019.1.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
カード保有者認証方法であって、
認証ネットワーク・コンピュータにおいて、アカウントを含む認証要求を受信するステップと、
前記アカウントに関連するアカウント識別子の一部に基づいて、認証サービスを決定するステップと、
前記認証サービスと前記アカウント識別子の一部とに基づいて、認証応答を決定するステップと、
前記アカウントを伴うトランザクションに関連する商人に、前記認証応答を送信するステップと、
を含み、
前記認証サービスを決定する前記ステップが、追加の認証が要求されると判定するステップを含む、カード保有者認証方法。
【請求項２】
請求項１記載のカード保有者認証方法において、前記追加の認証が、代理サービス・プロバイダによって提供される少なくとも１つのサービスを含む、カード保有者認証方法。
【請求項３】
請求項１記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、カード保有者認証方法。
【請求項４】
請求項１記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータが代理サービス・コンピュータである、カード保有者認証方法。
【請求項５】
請求項１記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方法。
【請求項６】
請求項１記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのユーザから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方法。
【請求項７】
装置であって、
プロセッサと、
前記プロセッサと通信可能なメモリであって、前記メモリがプログラム命令を格納し、前記プロセッサが以下の機能を実行するために、前記プログラム命令によって動作する、メモリと、
を含み、前記機能が、
アカウントを含む認証要求を受信する機能と、
前記アカウントに関連するアカウント識別子の一部に基づいて、認証サービスを決定する機能と、
前記認証サービスと前記アカウント識別子の一部とに基づいて、認証応答を決定する機能と、
前記アカウントを伴うトランザクションに関連する商人に、前記認証応答を送信する機能と、
を含み、
前記認証サービスを決定する前記機能が、追加の認証が要求されると判定する機能を含む、装置。
【請求項８】
請求項７記載の装置において、前記追加の認証が、代理サービス・プロバイダによって提供される少なくとも１つのサービスを含む、装置。
【請求項９】
請求項７記載の装置において、前記プロセッサが認証ネットワーク・コンピュータのコンポーネントである、装置。
【請求項１０】
請求項９記載の装置において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、装置。
【請求項１１】
請求項９記載の装置において、前記認証ネットワーク・コンピュータが代理サービス・コンピュータである、装置。
【請求項１２】
請求項７記載の装置において、前記プロセッサが、更に、
前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するプログラム命令によって動作し、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、装置。
【請求項１３】
請求項７記載の装置において、前記プロセッサが、更に、
前記認証要求を受信する前に、前記アカウントのユーザから構成メッセージを受信するプログラム命令によって動作し、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、装置。
【請求項１４】
カード保有者認証方法であって、
認証ネットワーク・コンピュータにおいて、アカウントを含む認証要求を受信するステップと、
前記アカウントに関連するアカウント識別子の一部に基づいて、認証サービスを決定するステップと、
前記認証サービスと前記アカウント識別子の一部とに基づいて、認証応答を決定するステップと、
前記認証要求に関連するトークン要求元に、前記認証応答を送信するステップと、
を含み、
前記認証サービスを決定する前記ステップが、追加の認証が要求されると判定するステップを含む、カード保有者認証方法。
【請求項１５】
請求項１４記載のカード保有者認証方法において、前記追加の認証が、イシュアー・アクセス制御サーバによって提供される少なくとも１つのサービスを含む、カード保有者認証方法。
【請求項１６】
請求項１４記載のカード保有者認証方法において、前記認証ネットワーク・コンピュータがディレクトリ・サーバである、カード保有者認証方法。
【請求項１７】
請求項１４記載のカード保有者認証方法であって、更に、
前記認証ネットワーク・コンピュータにおいて、前記認証要求を受信する前に、前記アカウントのイシュアーから構成メッセージを受信するステップを含み、前記構成メッセージが、前記認証応答を決定する少なくとも１つの判断基準を定める、カード保有者認証方法。
【外国語明細書】
2019067442000001.pdf