(57)【要約】【課題】本発明によれば、クライアントは、信頼された認証サービスプロバイダを用いて消費者を認証することが可能となる。本システムは、消費者およびビジネス組織の問題に等しく対処する。目的は、認証サービスのクライアントに、消費者の真の識別を保証することである。【解決手段】リモート認証サービスプロバイダは、消費者名および固有の消費者コードに基づく消費者の高速認証を容易にするために、消費者データを管理する。好ましいシステムでは、固有の消費者コードは、消費者により保有されるハードウェアトークンによって生成されるワンタイムパスワード（ＯＴＰ）である。リモート認証サービスプロバイダは、トークンにより生成されたパスワードが正当であることを確かめる。【選択図】図１
2004524605.tif 000002
【特許請求の範囲】
【請求項１】
複数の異なるクライアントからの認証要求に応答するように適応したリモート認証サービスプロバイダを用いて消費者をクライアントに対して認証する認証サービスであって、該認証サービスプロバイダは、
消費者名および固有の消費者コードを含む認証要求を受信するステップと、
前記消費者名に関連する消費者データを含む少なくとも１つの認証データ記憶部にアクセスするステップと、
前記消費者データによって前記固有の消費者コードの正当性を判定するステップと、
前記消費者が認証されたかどうかを確認する認証応答を前記クライアントに送信するステップと
を実行する認証サービス。
【請求項２】
前記固有の消費者コードは、ハードウェアトークンにより生成されるワンタイムパスワードである請求項１に記載の認証サービス。
【請求項３】
請求項１または２に記載の方法を実行するためのコンピュータ実行可能コードを含むコンピュータプログラム製品。
【請求項４】
クライアントにより提供される取引を履行する前またはサービスもしくはアプリケーションへのアクセスを許可する前に消費者の認証を要求する複数の異なるクライアントに対してリモート認証サービスを提供する認証エンジンであって、
消費者名および固有の消費者コードを含む認証要求をクライアントから受け入れる通信インタフェースと、
前記消費者名に関連する消費者データを含む少なくとも１つの認証データ記憶部と、
前記少なくとも１つの認証データ記憶部にアクセスし、前記消費者データによって前記固有の個人コードの正当性を判定し、および前記消費者が認証されたかどうかを確認する前記クライアントへの認証応答を生成するように適応した処理システムと
を備える認証エンジン。
【請求項５】
前記固有の消費者コードは、ハードウェアトークンにより生成されるワンタイムパスワードである請求項４に記載の認証サービス。
【請求項６】
消費者がクライアントにより提供される取引またはサービスもしくはリソースへのアクセスを要求する認証方法であって、前記クライアントは、
前記消費者から消費者名および固有の消費者コードを取得するステップと、
前記消費者名および前記固有の消費者コードを含む認証要求を、いくつかの異なるクライアントによりアクセス可能なリモート認証サービスプロバイダに送信するステップと、
前記消費者が認証されたかどうかを確認する認証応答を前記リモート認証サービスプロバイダから受信するステップと、
前記消費者が認証されている場合、前記取引を続行するか、または前記消費者により要求された前記アクセスまたはサービスを提供するステップと
を実行する方法。
【請求項７】
前記固有の消費者コードは、ハードウェアトークンにより生成されるワンタイムパスワードである請求項６に記載の方法。
【請求項８】
クライアントが消費者取引に関する決済承認要求を、いくつかの異なるクライアントからの決済承認要求に応答するように適応したリモートサービスプロバイダに送信する決済承認サービスであって、前記リモートサービスプロバイダは、
消費者名および固有の消費者コードを含む決済承認要求をクライアントから受信するステップと、
前記消費者名に関連する消費者データを含む少なくとも１つのデータ記憶部にアクセスし、前記消費者データによって前記固有の消費者コードの正当性を判定することにより、前記消費者を認証するステップと、
決済プロセスを実行するステップであって、それにより前記決済承認要求を満たし、承認された取引を履行する、実行するステップと
を実行する決済承認サービス。
【請求項９】
前記固有の消費者コードは、ハードウェアトークンにより生成されるワンタイムパスワードである請求項８に記載の決済承認サービス。
【請求項１０】
決済承認が取得される方式は、獲得者および／または発行者により規定される決済プロトコルによって決まる請求項８または９に記載の決済承認サービス。
【請求項１１】
いくつかの異なる決済モジュールを通じて複数の異なる決済プロトコルをサポートする請求項８ないし１０のいずれかに記載の決済承認サービス。
【請求項１２】
商人のＰＯＳ決済モジュールをホストする請求項１１に記載の決済承認サービス。
【請求項１３】
請求項８ないし１２のいずれかに記載の方法を実行するためのコンピュータ実行可能コードを含むコンピュータプログラム製品。
【請求項１４】
消費者と取引する複数の異なるクライアントに対して、ホストされたリモート決済承認サービスを提供する決済承認エンジンであって、
消費者名および固有の消費者コードを含む決済承認要求をクライアントから受信する通信インタフェースと、
消費者決済カードの細目を含む消費者データを含むいくつかのデータ記憶部と、
所定のプロトコルに従って、承認された決済を可能にするいくつかの決済モジュールを有する処理システムであって、前記消費者名に関連する消費者データを含む少なくとも１つのデータ記憶部にアクセスし、前記固有の個人コードの正当性を判定することにより、前記消費者を認証し、選択された決済モジュールを使用して決済プロセスを実行して前記決済承認要求を満たすことにより、承認された取引を履行するように適応した処理システムと
を備える決済承認エンジン。
【請求項１５】
前記固有の消費者コードは、ハードウェアトークンにより生成されるワンタイムパスワードである請求項１４に記載の決済承認エンジン。
【請求項１６】
決済承認が取得される方式は、獲得者および／または発行者により規定される決済プロトコルによって決まる請求項１４または１５に記載の決済承認エンジン。
【請求項１７】
いくつかの異なる決済モジュールを通じて複数の異なる決済プロトコルをサポートする請求項１４ないし１６のいずれかに記載の決済承認エンジン。
【請求項１８】
商人のＰＯＳ決済モジュールをホストする請求項１７に記載の決済承認エンジン。
【請求項１９】
それぞれの消費者名に関連するデータを含み、消費者が認証されることを可能にする第１データベースをさらに備える請求項１４ないし１８のいずれかに記載の決済承認エンジン。
【請求項２０】
それぞれの消費者に関連するクレジットおよび／またはデビットカード細目を含む第２データベースをさらに備える請求項１４ないし１９のいずれかに記載の決済承認エンジン。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、取引を行う目的で、またはサービスもしくはリソースにアクセスするために、ユーザをエンティティに対して認証するシステムに関する。
【背景技術】
【０００２】
認証は、要求されたリソースへのアクセスを許可する前に、ユーザまたは他のエンティティ（例えばプロセスまたは外部システム）の識別を確認するプロセスである。これは通常、ユーザ名およびパスワードに基づいている。静的パスワードは最も広く使用される認証メカニズムであり続けているが、セキュリティハザードとして認識されている。特に、静的パスワードは、記録、共有、「スニッフィング」（パスワードが伝送中に捕捉される）、および「ショルダーサーフィング」（ユーザがパスワードを使用中に監視される）に対して脆弱である。静的パスワードはまた、「リプレイ」攻撃を受けやすい。この問題点に対する比較的新しい手法は、ワンタイムパスワード（ＯＴＰ）の使用である。これは、ユーザ名とともに使用される点で従来の静的パスワードと類似しているが、ハードウェアトークンを用いて動的に生成される点で異なる。
【０００３】
金融取引は、非常に多くの方法で実行され得る。例えば、現金を用いて商品およびサービスに対する決済をすることができるのはもちろん、クレジットカードおよびデビットカード決済も可能である。これに加えて、決済をするために銀行口座間の直接振替を手配することが可能である。
【０００４】
これらの取引が履行され得るための技法は、取引が実行される状況に応じて異なる。例えば、商店では通常、顧客は自己の決済カードを店員に提示する。すると店員は、その細目を店頭（ＰＯＳ）デバイスに入力し、ＰＯＳデバイスはその細目を獲得者（商人から取引に関係する金融データを獲得しそのデータを交換システムに伝える金融機関、またはその代行業者）に転送し、獲得者はその決済カードが所望の取引を実行するために使用され得るかどうかを確かめる。店員は、その決済カードが認可されたユーザによって提示されたことを、顧客の署名をカードの裏側の署名と対照してチェックすることにより確かめる。これらの段階のそれぞれが首尾よく進行したとすれば、取引は承認される。この場合、獲得者または発行者（決済カードブランドのために固有の主口座番号（ＰＡＮ）をカード保有者に発行する金融機関、またはその代行業者）が、購買された商品に対する商店の請求額をまかない、後日にカード所有者から引き落とされる。
【０００５】
しかし、この形態のシステムは、決済カードが店員にとって利用可能とされなければならないという重大な欠点を有する。このことは、第三者がカード細目を取得し、これらの細目を用いて不正に取引を実行する機会を提供する。特に、これは偽造決済カードを製造することによって、あるいは単にカード細目を用いて直接「カード保有者不立会」の購買を行うことによって遂行され得る。
【０００６】
最近では、消費者が品物をウェブサイトから購入することを可能にするインターネットショッピングの導入によって、状況は悪化している。この例では、ウェブサイト所有者が取引を検証することを可能にするために、ユーザの決済カード細目が通常、インターネットを通じてウェブサイトに転送されなければならない。これもまたもちろん、顧客のカード細目が公衆に利用可能となることにより不正な取引がこれらの細目を用いて実行されるリスクがあることを意味する。さらに、カード保有者が立ち会わないため、この取引にはいかなる形態の認証もない。
【０００７】
従来の銀行および支店のない金融機関は、インターネットを通じて配信される大量のサービスによって、ホームバンキングおよびビジネスバンキングの市場に波のように押し寄せている。会社はインターネットバンキングを、コストを減少させ効率を向上させる手段として評価している。銀行は高度なインターネットバンキングサービスを提供し始めている。そのようなサービスとしては、口座および資金情報へのアクセス、勘定決済、同一金融機関での口座間の振替、住宅ローン情報、ならびに選択された口座に関する最近の取引およびその他の履歴情報へのアクセスがある。インターネットバンキングは、株式売買、商品取引の契約、または任意の金額を任意の金融機関の任意の口座への電子振替のような、ますます高度な取引サービスを銀行が提供することができるための新しいチャネルを提供する。しかし、機密金融情報をさらす不安が、オンラインバンキングの広範な実施および使用の主要な障害であり続けている。銀行は、口座にオンラインでアクセスしている顧客が申告通りの者であることを確かめること、すなわち顧客を認証することを必要とする。さらに、顧客は、個人情報、口座番号および資金が安全であることを知りたいと思っている。現在のシステムは依然として静的パスワードに基づく認証システムに頼る傾向があり、それゆえ本質的に攻撃を受けやすい。これは、インターネットバンキングが消費者の信頼を確保する前に対処する必要のある主要な問題であり続けている。
【発明の開示】
【課題を解決するための手段】
【０００８】
本発明の第１の態様によると、複数の異なるクライアントからの認証要求に応答するように適応したリモート認証サービスプロバイダを用いて消費者をクライアントに対して認証する認証サービスであって、該認証サービスプロバイダは、
消費者名および固有の消費者コードを含む認証要求を受信するステップと、
消費者名に関連する消費者データを含む少なくとも１つの認証データ記憶部にアクセスするステップと、
消費者データによって固有の消費者コードの正当性を判定するステップと、
消費者が認証されたかどうかを確認する認証応答をクライアントに送信するステップと
を実行する認証サービス。
【０００９】
本発明の第２の態様によると、コンピュータプログラム製品は、本発明の第１の態様の方法を実行するためのコンピュータ実行可能コードを含む。
【００１０】
本明細書において、「消費者」という用語は、取引を行う目的で、またはサービスもしくはリソースにアクセスするために、自己を認証することを要求しているエンドユーザを指す。「クライアント」という用語は、リモート認証サービスに加入している組織を指す。これらは、サービスまたはリソースへの制御されたアクセスを提供する小売店（商人）、インターネットバンク、またはいかなるビジネス組織をも含み得る。
【００１１】
本発明の第３の態様によると、クライアントにより提供される取引を履行する前またはサービスもしくはアプリケーションへのアクセスを許可する前に消費者の認証を要求する複数の異なるクライアントに対してリモート認証サービスを提供する認証エンジンであって、
消費者名および固有の消費者コードを含む認証要求をクライアントから受け入れる通信インタフェースと、
消費者名に関連する消費者データを含む少なくとも１つの認証データ記憶部と、
少なくとも１つの認証データ記憶部にアクセスし、消費者データによって固有の個人コードの正当性を判定し、および消費者が認証されたかどうかを確認するクライアントへの認証応答を生成するように適応した処理システムと
を備える認証エンジン。
【００１２】
本発明の第４の態様によると、消費者がクライアントにより提供される取引またはサービスもしくはリソースへのアクセスを要求する認証方法であって、クライアントは、
消費者から消費者名および固有の消費者コードを取得するステップと、
消費者名および固有の消費者コードを含む認証要求を、いくつかの異なるクライアントによりアクセス可能なリモート認証サービスプロバイダに送信するステップと、
消費者が認証されたかどうかを確認する認証応答をリモート認証サービスプロバイダから受信するステップと、
消費者が認証されている場合、取引を続行するか、または消費者により要求されたアクセスまたはサービスを提供するステップと
を実行する方法。
【００１３】
本発明によれば、クライアントは、信頼された認証サービスプロバイダを用いて消費者を認証することが可能となる。本システムは、消費者およびビジネス組織の問題を等しく対処する。目的は、認証サービスのクライアントに、消費者の真の識別を保証することである。リモート認証サービスプロバイダは、消費者名および固有の消費者コードに基づく消費者の高速認証を容易にするために、消費者データを管理する。
【００１４】
好ましいシステムでは、固有の消費者コードは、消費者により保有されるハードウェアトークンによって生成されるワンタイムパスワード（ＯＴＰ）である。リモート認証サービスプロバイダは、トークンにより生成されたパスワードが正当であることを確かめる。消費者名は、消費者の実名である必要はないが、リモート認証サービスプロバイダにより記憶されている消費者名に一致しなければならない。したがって、所望であれば、消費者は自己の匿名性を維持することができる。さらに、認証応答は、消費者がそう呼びかけられたいと思う好みの「愛称名」を含み得る。
【００１５】
本システムは、企業が特定のサービスまたはアプリケーションへのアクセスを許可する前にエンドユーザを認証することを必要とするようなインターネットアプリケーションに特に適している。特に、本システムは、銀行がウェブサイトへのアクセスを許可する前に顧客の認証を要求するようなインターネットバンキングアプリケーションにおいて使用可能である。本発明では、銀行は、顧客のブラウザにより表示されるログオンページを提供し、そのページは、顧客はユーザＩＤと、自己の個人用トークンにより生成されたパスワードとをタイプ入力することができるウィンドウを有する。すると銀行はこの情報を安全な方式で認証要求の形態でリモート認証サービスプロバイダに送信する。リモート認証サービスプロバイダは、単純な合否結果の形態で認証応答を生成する。顧客が認証された場合、ウェブサイトへのアクセスが通常の方式で許可される。
【００１６】
消費者は、相異なる銀行にいくつかのインターネットバンク口座を有し得る。それらの銀行がリモート認証サービスプロバイダのクライアントである場合には、ユーザはパスワードを生成するための単一のハードウェアトークンを保持するだけでよい。
【００１７】
本発明の第５の態様によると、クライアントが消費者取引に関する決済承認要求を、いくつかの異なるクライアントからの決済承認要求に応答するように適応したリモートサービスプロバイダに送信する決済承認サービスであって、リモートサービスプロバイダは、
消費者名および固有の消費者コードを含む決済承認要求をクライアントから受信するステップと、
消費者名に関連する消費者データを含む少なくとも１つのデータ記憶部にアクセスし、消費者データによって固有の消費者コードの正当性を判定することにより、消費者を認証するステップと、
決済プロセスを実行するステップであって、それにより決済承認要求を満たし、承認された取引を履行する、実行するステップと
を実行する決済承認サービス。
【００１８】
本発明の第６の態様によると、コンピュータプログラム製品は、本発明の第５の態様の方法を実行するためのコンピュータ実行可能コードを含む。
【００１９】
本発明の第７の態様によると、消費者と取引する複数の異なるクライアントに対して、ホストされたリモート決済承認サービスを提供する決済承認エンジンであって、
消費者名および固有の消費者コードを含む決済承認要求をクライアントから受信する通信インタフェースと、
消費者決済カードの細目を含む消費者データを含むいくつかのデータ記憶部と、
所定のプロトコルに従って、承認された決済を可能にするいくつかの決済モジュールを有する処理システムであって、消費者名に関連する消費者データを含む少なくとも１つのデータ記憶部にアクセスし、固有の個人コードの正当性を判定することにより、消費者を認証し、選択された決済モジュールを使用して決済プロセスを実行して決済承認要求を満たすことにより、承認された取引を履行するように適応した処理システムと
を備える決済承認エンジン。
【００２０】
本発明はまた、リモート認証サービスプロバイダが消費者の決済カードの細目を含むデータベースも管理するようなリモート認証サービスの拡張も提供する。本システムは、ローカル（ＰＯＳデバイスにおいて）であるか、電話を通じてであるか、インターネットを通じてウェブサイトに対するものであるかにかかわらず、カードまたはカード細目を商人に提示する必要性をなくすことにより、クレジットまたはデビット決済を使用する消費者による安全な商取引を容易にし可能にするように設計される。
【００２１】
決済承認が取得される方式は、獲得者および／または発行者により規定される決済プロトコルによって決まる。したがって、本発明は、いくつかの異なる決済モジュールを通じて多くの異なる決済プロトコルをサポートする。アーキテクチャのモジュール性により、個別に新しい決済サービスの追加が可能である。
【００２２】
決済モジュールの一例は、ホストされた商人ＰＯＳである。この例では、決済承認要求は消費者名、固有の消費者コード、取引額および選択された決済方法を含む。サービスプロバイダは、決済承認要求を、選択された決済方法に関連する獲得者に送信して取引識別子を取得した後、承認応答をクライアントに送信する。承認応答は、獲得者により提供された取引識別子を含む。
【００２３】
好ましいシステムでは、サービスプロバイダは、消費者が認証されることを可能にするために、それぞれの消費者名に関連するデータを含む「ボールト」を管理する。サービスプロバイダはまた、消費者に関連するクレジットおよびデビットカード細目を含む「レジストリ」も管理する。サービスプロバイダのクライアントが、承認された決済を要求すると、サービスプロバイダはまず、クライアントにより転送された消費者名およびＯＴＰを用いて消費者を認証した後、獲得者へ送信するための承認要求を生成する。承認要求は通常、消費者名、選択された決済方法に関連する主口座番号（ＰＡＮ）、取引額、および商人識別子を含む。獲得者は、取引識別子と、取引の否認防止を保証する取引承認コードとを返す。こうして、サービスプロバイダはリモートＰＯＳをホストするように効果的に機能する。場合によっては、獲得者は適切な承認を取得するためにカード発行者と通信しなければならない可能性がある。
【００２４】
ＳＥＴ(Secure Electronic Transaction)プロトコルは、本発明を通じて提供され得るもう１つの決済サービスである。このプロトコルでは、システムは、消費者に代わってＳＥＴ交換に関与する消費者ＳＥＴウォレット決済モジュールをホストする。提案されるソリューションは、レジストリのデータベースおよびＳＥＴ決済モジュール内のすべての必要なＳＥＴソフトウェアおよび暗号データ（デジタル証明書、暗号鍵）をホストする。この手法は、ＳＥＴソフトウェアおよびデジタル証明書を搬送し導入することを必要とせずに、消費者が任意のチャネル（例えばインターネット、ＷＡＰ、電話）を通じて購買を行うことを可能にすることにより、消費者が自己のコンピューティングプラットフォームにＳＥＴクライアントソフトウェアを導入することを不要にするとともに、移動性の大幅な向上を可能にする。この場合も、好ましいシステムは、消費者名およびＯＴＰを用いたＳＥＴウォレットへのアクセスを安全にする。
【００２５】
以下、本発明の実施例について、添付図面を参照して詳細に説明する。
【発明を実施するための最良の形態】
【００２６】
上記のように、本明細書において、「消費者」という用語は、取引を行う目的で、またはサービスもしくはリソースにアクセスするために、自己を認証することを要求しているエンドユーザを指す。「クライアント」という用語は、リモート認証サービスプロバイダ（ＡＳＰ）と加入している組織を指す。これらは、サービスまたはリソースへの制御されたアクセスを提供する小売店（商人）、インターネットバンク、またはいかなるビジネス組織をも含み得る。
【００２７】
図１は、本発明によるトークンに基づく認証システムの例を示す。本システムは、ワンタイムパスワード（ＯＴＰ）を生成するために当技術分野で一般に知られているタイプの消費者ハードウェアトークン１０を含む。パスワードは、消費者１１がＰＩＮまたはその他の形態の秘密コードをキー入力するたびにトークンによって生成される。消費者は、消費者名と、トークンにより生成されたパスワードを、リモート認証サービスプロバイダ１３（ＡＳＰ）のいくつかのクライアント１２のうちの１つに提示する。いくつかの通信チャネル１４が考えられる。例えば、消費者が単に認証データをじかにクライアント１２に提供してもよく、また認証データは、消費者のブラウザにより表示されるウィンドウとして提示されるフォームに記入することによって、インターネットを通じて提供されてもよい。
【００２８】
クライアント１２は、安全な通信チャネル１５、例えばインターネットＶＰＮ、暗号化された専用線、ＳＳＬ(Secure Socket Layer)コネクションまたはその他の任意の暗号化されたチャネルを通じて、消費者により提供される認証データを含む認証要求の送信と、ＡＳＰ１３により生成される認証応答の受信のために、ＡＳＰ１３と通信する。ＡＳＰは、クライアント１２により提供される認証データに基づく消費者の高速な認証を容易にするために、それぞれの消費者名に関連する消費者データを含むいくつかのデータ記憶部を管理する１つまたは複数の認証サーバ１６を運営する。消費者により使用される消費者名はその人の実名である必要はなく、そのため消費者は所望であれば自己の匿名性を維持することができる。ＡＳＰ１３は、消費者１１により提供されるパスワードが正当であるかどうかを、同一であるべきパスワードを独立に計算することによって確認する。成功した場合、ＡＳＰ１３は認証応答を生成し、これをクライアント１２に送信することにより、消費者をクライアントに対して認証する。
【００２９】
本システムは、クライアントが企業であり、その企業が特定のサービスまたはアプリケーションへのアクセスを許可する前にエンドユーザを認証することを必要とするようなインターネットアプリケーションに特に適している。特に、本システムは、銀行がウェブサイトへのアクセスを許可する前に顧客の認証を要求するようなインターネットバンキングアプリケーションにおいて使用可能である。本発明では、銀行は、顧客のブラウザにより表示されるログオンページを提供し、そのページは、顧客はユーザＩＤと、自己の個人用トークンにより生成されたパスワードとをタイプ入力することができるウィンドウを有する。すると銀行はこの情報を安全な方式で認証要求の形態でＡＳＰに送信する。ＡＳＰは、単純な合否結果の形態で認証応答を生成する。顧客が認証された場合、ウェブサイトへのアクセスが通常の方式で許可される。
【００３０】
消費者は、相異なる銀行にいくつかのインターネットバンク口座を有し得る。それらの銀行がリモート認証サービスプロバイダのクライアントである場合には、ユーザはパスワードを生成するための単一のハードウェアトークンを保持するだけでよい。
【００３１】
図２は、消費者トークン１０の例を概略的に示す。
【００３２】
上記の認証プロセスは、消費者トークン１０および認証サーバ１６が同一の変数（クロックカウンタ２０およびイベントカウンタ２１）を用いて一連のタスクを実行する同期認証モードに依拠する。それらの変数はその後、６桁のチャレンジを生成するために共有秘密２２を用いて暗号化される。トークン上および認証サーバで提供されるクロックは時間とともにドリフトするのが普通である。この現象を補償し信頼できるサービスを保証するため、トークンにより生成され認証サーバに送られるパスワードは、チャレンジに前置される２桁の数字を含む。これらの数字は、トークンのクロックカウンタおよびイベントカウンタのそれぞれからの最下位ビット２３および２４であり、認証サーバ１６によって自己をトークンに同期させるために使用される。
【００３３】
顧客トークン１０は以下のステップを実行する。
１．トークンは、２個の変数、すなわちトークンクロックカウンタ値２０およびトークンイベントカウンタ値２１を用いて、内部チャレンジを（認証サーバとは独立に）形成する
２．トークンは、第３の変数を用いて５６ビットＤＥＳアルゴリズム２５によりこの内部チャレンジを暗号化する。この第３の変数は、その特定トークンに固有の導出された秘密鍵であり、ＯＴＰを作成するためにその特定の暗号化セッションに対してだけ使用される
３．トークンは、２個の最下位ビット（イベントカウンタおよびクロックカウンタからそれぞれ１個ずつ）を選択し、それらを暗号化結果に前置する。この結果２６が、認証要求プロセス中に認証サーバ１６に送られる
４．トークンは自己のイベントカウンタ２１を１だけインクリメントする
５．トークンは新しい秘密鍵２２を導出し、これは前の暗号化セッションで使用された秘密を上書きする。その鍵導出プロセスはＡＮＳＩ  Ｘ９．２４標準に基づく。それは、イベントカウンタおよび前の秘密鍵を用いて次のセッションのための新しい鍵を生成する。
【００３４】
上記のように、その次の一連のタスクは認証サーバ１６によって実行され、認証サーバ１６はパスワード照合に基づいて消費者を認証する。認証サーバは、セッションの最後に有意味な結果を比較するためには同じ３個の変数で厳密に同じ計算を実行しなければならないため、サーバ変数はすべての時点でクライアント変数と同期していなければならない。上記のように、これは、５６ビットＤＥＳ暗号化プロセスにより生成される値に前置された２桁の特別の数字を使用して達成される。認証サーバ１６は、その２桁の数字を比較し、トークンの数字がサーバに記憶されているものと一致するかどうかを判定する。必要であれば、認証サーバは自己のイベントおよびクロックカウンタを、トークンのものに（規定されたセキュリティパラメータ内で）一致するように再同期させた後、トークンにより使用されている鍵に対応する必要な鍵を導出するまで鍵導出プロセスを繰り返す。サーバは、自己の数字が再同期したと判定すると、自己のクロックおよびイベントカウンタ値を用いて自己の内部チャレンジを形成し、適当な鍵および５６ビットＤＥＳアルゴリズムを用いてそのチャレンジを暗号化し、消費者とサーバの暗号化されたチャレンジ同士を比較して、認証が成功したかどうかを判定する。一致が成功したときにのみ、サーバは自己のイベントカウンタを１だけインクリメントし、その消費者に対する新しい秘密鍵を導出する。その新しい秘密鍵は、安全データブロック（ＳＤＢ）の一部としてデータベース内に記憶される。
【００３５】
認証サーバ１６は、トークンと同じアルゴリズムおよび値を用いて必要な検証を実行する。各トークン１０は、そのトークンの初期化段階に設定される固有の初期化値を有する。これらの初期値は、認証サーバ１６により使用されるデータファイル（図示せず）に暗号化されて記憶され、初期５６ビットＤＥＳ秘密鍵、３２ビットランダムイベントカウンタ、トークンシリアル番号、およびトークンのプロファイルからなる。各エントリはＳＤＢとして記憶される。ＳＤＢの復号は、そのＳＤＢに対する５６ビットＤＥＳ秘密鍵が供給されるコンピュータプログラムにより処理される。
【００３６】
本発明はまた、ＡＳＰが消費者の決済カードの細目を含むデータベースを管理するような上記のリモート認証サービスの拡張も提供する。以下で説明するように、本システムは、ローカル（ＰＯＳデバイスにおいて）であるか、インターネットを通じてウェブサイトに対するものであるかにかかわらず、カードまたはカード細目を商人に提示する必要性をなくすことにより、クレジットまたはデビット決済を使用する消費者による安全な商取引を容易にし可能にするように設計される。
【００３７】
図３に示すように、ＡＳＰ３０は、「ボールト」３１、すなわち、消費者が上で詳細に説明した方式で認証されることを可能にする認証サーバを管理する。サービスプロバイダはまた、認可された決済を容易にするための「レジストリ」３２も管理する。
【００３８】
高いレベルでは、当事者間の通信は以下のように要約することができる。サービスプロバイダ３０のクライアント３３、例えば商人が、承認された決済を要求すると、サービスプロバイダ３０はまず、商人３３により転送された消費者名およびＯＴＰに基づきボールト３１を用いて消費者３４を認証した後、獲得（acquiring）銀行３５に送信するための承認要求を生成する。承認要求は通常、消費者名、選択された決済方法に関連する主口座番号（ＰＡＮ）、取引額、および商人識別子を含む。獲得者３５は、取引識別子と、取引の否認防止を保証する承認コードとを返す。こうして、サービスプロバイダ３０はリモートＰＯＳをホストするように効果的に機能する。場合によっては、獲得者は適切な承認を取得するためにカード発行者３６と通信しなければならない可能性がある。
【００３９】
ＡＳＰ３０が取引承認を取得する方式は、獲得者および／または発行者により規定される決済プロトコルに依存する。したがって、本発明は多くの異なる決済プロトコルをサポートする。
【００４０】
図３に示すサーバアーキテクチャは、次の４つの主要コンポーネントおよびそれらの相互作用に分解することができる。
１．認証システム３１（ボールト）
２．決済システム３２（レジストリ）
３．消費者プロファイルのデータベース（図示せず）、ならびに、
４．監査およびデータロギングコンポーネント（図示せず）。
【００４１】
この例では、サービスをホストする主なプラットフォームはHewlett-PackardのＨＰ９０００ＬおよびＮ  ｃｌａｓｓ  ＨＰ−ＵＸサーバである。アプリケーションとしては、Ｏｒａｃｌｅデータベース、ｉＰｌａｎｅｔウェブサーバ、ステートレス認証カーネル、およびコンポーネントを連結するための特注ソフトウェアがある。周辺防御３７は、ファイアウォール技術、侵入検出システムおよびＨＰ  Ｖｉｒｔｕａｌ  Ｖａｕｌｔ上のサーバのホスティングを含む。
【００４２】
図３のアーキテクチャで実施される認証システムは、図１および図２を参照して上で説明した通りである。しかし、システムはデジタル証明書３８を含むさまざまな認証メカニズムをサポートすることができるが、上記のＯＴＰハードウェアトークンメカニズム３９が好ましい。さらに、静的パスワード４０は、一時的フォールバック認証として使用され得る。
【００４３】
決済システム３２は、それぞれ既存の決済プロトコル４１〜４４を使用して取引を行うことが可能ないくつかの決済サービスモジュールからなる。これらは、ＳＥＴ取引４１、ＰＯＳ取引４２またはその他の任意の許容可能な決済プロトコルでもあり得る。このモジュール設計は、必要に応じて新しい決済モジュールを追加することを可能にする。
【００４４】
決済システム３２は、消費者の加入および初期化段階（その際にトークンもまた消費者に発送される）中にアウトオブバンドで取得されレジストリデータベース内に格納される消費者のプロファイルおよび関連する決済カード細目を用いて、商人に代わって決済取引を効果的に代行する。クレジットカードの場合、システムは、獲得銀行と直接取引することにより個人の決済カード細目を商人に送信する必要性をなくすことによって、セキュリティおよびある程度の匿名性を消費者に提供する。
【００４５】
決済取引中の対話は、ＡＳＰ３０、商人３３および獲得銀行３５に制限される。これは、商人が、ＡＳＰ決済オプションを有するウェブサイトを正当にする必要がある。いったん正当にされると、商人のウェブサイトは、以下の細目を含む購買要求を送信する。
１．消費者名
２．ＯＴＰ
３．取引額
４．商人ＩＤ
５．獲得銀行のＩＤ
６．ＰＡＮ、および
７．決済方法。
【００４６】
ＡＳＰボールト３１内での認証が成功した後、消費者の細目および供給された商人細目を用いてＡＳＰレジストリ３２との決済取引が行われる。レジストリ３２は、決済モジュール４１〜４４のうちの１つに関連する適当な決済および通信プロトコルを用いて獲得銀行と通信する。クレジットカード取引の結果、レジストリ３２は、取引コードを、購買額および商人ＩＤならびに決済を履行するのに必要なその他のデータとともに供給することになる。成功した場合、レジストリ３２は、承認コードを記録のために商人３３に返す。
【００４７】
システムは、３つのデータベース（図示せず）に依拠する。すなわち、トークンの細目および鍵のための認証サーバ用のデータベース（ＳＤＢ）、レジストリが決済取引について消費者細目をホストするためのデータベース、そして顧客関係管理のための第３のデータベースである。これらのデータベースは、必要に応じて増減可能な大量の記憶容量およびパフォーマンスを提供する。
【００４８】
あらゆる消費者は、システム内で初期化され、ユーザプロファイル内に規定される。これらのプロファイルは、認証を行い、続いて認証された消費者に代わって決済取引を履行するための必要なデータを含む。トークン初期化データおよびトークンシリアル番号、ユーザ名ならびにその他の認証データが、ボールトによりアクセスされる１つのデータベースに格納される。
【００４９】
クレジットカード細目のような消費者細目は、消費者に関連する最も明らかなデータである。しかし、ＳＥＴに基づく決済のためのＳＥＴ証明書や、供給業者または商人が商品を消費者に発送するための必要な細目を自動的に供給することにより購買を容易にするための発送先住所のような追加細目を格納することが必要になることもあり得る。この情報は、レジストリによりアクセスされるデータベースに格納される。
【００５０】
否認防止の重要性および執行は、高度のセキュリティ、監査およびロギング能力を必要とする。この目的のため、アーキテクチャは、周辺防御３７、すなわち、広範な監視およびロギングサービスを構成し可能にする論理的および物理的アクセス制御およびプランとともに設計されている。あらゆる認証および取引要求はその結果とともに、ログエントリの記録後にデータが変更できないことを保証するために、追記型（ＷＯＲＭ）媒体（図示せず）にロギングされる。
【００５１】
監査データの種類には、消費者、商人および獲得銀行の要求、応答およびタイムスタンプが含まれる。
【００５２】
ＳＥＴ(Secure Electronic Transaction)プロトコルは、提供され得る１つの決済サービスである。このプロトコルでは、システムは、消費者に代わってＳＥＴ交換に関与することになる消費者ＳＥＴウォレット決済モジュールをホストする。システムは、レジストリのデータベースおよびＳＥＴ決済モジュール内のすべての必要なＳＥＴソフトウェアおよび暗号データ（デジタル証明書、暗号鍵）をホストする。この手法は、ＳＥＴソフトウェアおよびデジタル証明書を搬送し導入することを必要とせずに、消費者が任意のチャネル（例えばインターネット、ＷＡＰ、電話）を通じて購買を行うことを可能にすることにより、消費者が自己のコンピューティングプラットフォームにＳＥＴクライアントソフトウェアを導入することを不要にするとともに、移動性の大幅な向上を提供する。
【００５３】
図４は、本アーキテクチャがＳＥＴ取引においてどのように動作するかを概略的に示す。ステップは以下の通りである。
（Ａ）消費者４０は、追加ソフトウェアがなく、かつスマートカードリーダなしの標準的なブラウザを用いて、商人のサイト４１を閲覧する。消費者は、ショッピングバスケットに記入し、決済ページに進む。このページで消費者は、ＡＳＰオプションを用いて決済することを選択する。消費者は、自己の消費者名およびパスコードの入力を促される。
（Ｂ）消費者名およびパスワードが、商人４１によってリモートＡＳＰ４３のボールト４２に転送され、ボールト４２は消費者を上記のように認証し、その結果（ステータス）が商人に返送される。
（Ｃ）消費者４０の成功した認証の一部として、商人４１は、ＡＳＰレジストリ４６にある消費者のホストされているＳＥＴウォレットとのＳＥＴ取引を開始し、必要な注文情報（ＯＩ）を供給する。
（Ｄ）購買初期化要求および応答が、商人と、消費者のＳＥＴウォレットをホストしているリモートＡＳＰ４３との間でやりとりされる。
（Ｅ）購買要求がＡＳＰ４３（消費者に代わって）から商人４１に送られる。
（Ｆ）ここで商人は、自己の獲得者４４に対して承認を要求する。この随意選択的な交換は、商人４１とその獲得者４４の間で、通常のクレジットカード取引に従い、商人−獲得者交換についてＳＥＴＣｏにより規定されている標準的なＳＥＴプロトコル交換を用いて行われる。
（Ｇ）獲得者は、承認を取得するためにカード発行者４５に照会する選択の自由を有する。この随意選択的なやりとりは、獲得者４４とカード発行者４５の間で、通常のクレジットカード取引に従い、商人−獲得者のやりとりについてＳＥＴＣｏにより規定されている標準的なＳＥＴプロトコルのやりとりを用いて行われる。
（Ｈ）商人４１は、ＡＳＰ４３においてホストされているＳＥＴウォレットに購買応答を返す。
（Ｉ）商人４１は、決済の確認を消費者４０に返す。
【００５４】
図４において、商人４１は、取引承認を取得するために、ＡＳＰレジストリ４６を使用する代わりに獲得者４４に直接接続する。これは、商人を、通常のＳＥＴにできるだけ近く保つためである。所望であれば、商人は、ＡＳＰ４３にその機能性のＰＯＳ部分をホストさせることも可能であり、その場合ＡＳＰ４３が承認のために決済ゲートウェイに接続することになる。
【００５５】
顧客４０から商人４１を介してボールト４２に至り商人に戻る認証ステップは、他のいかなるカード取引とも厳密に同一である。以下で、図４および図５を参照して、カード保有者が正しく認証されたことを確認する肯定応答が商人４１に返された後で何が起こるかについて詳細に説明する。
【００５６】
カード保有者から商人への開始メッセージ（ＰＩｎｉｔＲｅｑ）および商人からカード保有者への開始応答（ＰＩｎｉｔＲｅｓ）の目的は、カード保有者についての証明書およびＣＲＬを取得することである。このメッセージ対がない場合、この情報は他の何らかの手段（ＣＤＲＯＭのような）を通じて取得されなければならない。
【００５７】
開始要求メッセージは以下のものを含む：
・ＲＲＰＩＤ、複数のセッションの場合にカード保有者がこのメッセージをその応答にリンクすることを可能にする識別子
・Ｌａｎｇｕａｇｅ、カード保有者の選択言語
・ＬＩＤ＿ＣおよびＬＩＤ＿Ｍ、カード保有者および商人が割り当てたローカルＩＤ
・Ｃｈａｌｌ＿Ｃ、商人のリプレイ応答を防ぐためにカード保有者により生成されるチャレンジ
・ＢｒａｎｄＩＤ、カード保有者の選択した決済カードブランド
・ＢＩＮ、銀行識別番号（カード保有者の口座番号の最初の６桁）
・Ｔｈｕｍｂｓ、カード保有者がすでに有しており、したがって送信される必要のない証明書、ＣＲＬおよびＢｒａｎｄＣＲＬＩｄｅｎｔｉｆｉｅｒのサムプリントのリスト。
【００５８】
開始応答メッセージは、商人により署名され、以下のものを含む：
・ＴｒａｎｓＩＤｓ、取引ＩＤ
・ＲＲＰＩＳ、（上記と同様）
・Ｃｈａｌｌ−Ｃ、カード保有者からのチャレンジ
・Ｃｈａｌｌ−Ｍ、カード保有者の応答の正当期限が確認され得ることを保証するために商人により生成されるチャレンジ
・ＢｒａｎｄＣＲＬＩｄｅｎｔｉｆｉｅｒ、ブランドＣＡの下にあるすべてのＣＡに対する現在のＣＲＬのリスト
・ＰＥＴｈｕｍｂｓ、決済ゲートウェイ鍵交換証明書のサムプリント
・Ｔｈｕｍｂｓ、ＰＩｎｉｔＲｅｑからコピーされる。
【００５９】
ＳＥＴプロトコルは、このメッセージ対が非インタラクティブな環境で省略されることを許容するが、その場合データは、オフラインメカニズム（ＣＤＲＯＭのような）によりこれらのメッセージで提供され、チャレンジは省略され、メッセージの正当期限の保証は低くなる。
【００６０】
本発明では、システムは、商人およびその他のＳＥＴ証明書に対する取消情報を取得する別の手段を有する。上記のメッセージ対の重要なコンポーネントで、この実施態様に反映されるものは次の通りである：
・取引ＩＤ
・次のメッセージの正当期限
・決済ブランドの識別
【００６１】
商人のシステムが、一度に複数のセッションをセットアップする消費者を扱い得ることは、商人の責任である。したがって、消費者により生成される取引ＩＤはもはやＳＥＴの問題ではない。決済ブランドの識別は、商人サイトにおいてユーザがＡＳＰ決済オプションを選択したことによってすでに行われている。また、カード保有者のブラウザと商人のウェブサイトの間のリンク上の十分な機密性およびインテグリティを保証することも商人の責任である。
【００６２】
本発明では、（ＰＩｎｉｔＲｅｑ，ＰＩｎｉｔＲｅｓ）メッセージ対は、ＡＳＰにおいてホストされているＳＥＴウォレットのフロントエンドへの商人の「ウェイクアップ」メッセージによって置き換えられる。「ウェイクアップ」メッセージは、カード保有者の肯定的認証によりトリガされ、以下のものを含む署名されたメッセージである：
・商人およびカード保有者の識別
・応答の正当期限がチェックされ得ることを保証するためのチャレンジ（上記のＣｈａｌｌ−Ｍ）
・次のメッセージＰＲｅｓを完成するために必要な注文情報
・リプレイまたはメッセージ重複により多重購買となることを防ぐための、この商人の（ＡＳＰにおける）カウンタ。ＡＳＰは、カウンタがこの商人に対する最終カウンタに１を加えたものであることをチェックし、そうでない場合には取引を拒否する。
【００６３】
「ウェイクアップ」呼出しにより、ホストされているＳＥＴウォレットは、購買要求（ＰＲｅｑ）メッセージを商人へ発行する。
【００６４】
ＰＲｅｑは２つの部分、すなわち、注文情報であるＯＩと、決済情報であるＰＩとからなる。商人がＯＩのみを復号することができ、獲得者がＰＩのみを見ることができるが、両者ともメッセージ全体のインテグリティを確認することができるような方法で、両方の部分とも暗号化され署名される。
【００６５】
通常のＳＥＴでは、カード保有者が証明書を有しないことが許容される。このようなカード保有者からのメッセージは署名されていない。本発明では、すべてのカード保有者は証明書（ＡＳＰにおいてリモートで保有される）を有し、通常の認証メカニズムによって証明書へのアクセスを確保する。
【００６６】
ホストされているＳＥＴウォレットモジュールは、ＰＲｅｑメッセージ（ＰｒｅｑＤｕａｌＳｉｇｎｅｄｄａｔａ）をまとめて新しいチャレンジＣｈａｌｌ−Ｃを生成する。というのは、（ＰＩｎｉｔＲｅｑ，ＰＩｎｉｔＲｅｓ）メッセージが交換されていないからである。決済情報データは、商人からの「ウェイクアップ」メッセージ内のカード保有者情報に基づいて、ＡＳＰにあるレジストリから来ることになる。
【００６７】
ＰＲｅｑメッセージを受信した商人は、この時点で、（ＩＰアドレスに関して）ＡＳＰに位置するカード保有者を扱うのと全く同様に、通常のＳＥＴステップを実行する。続いて商人は、その決済ゲートウェイを通じて取引についての決済承認を取得しようと試みる。商人のポリシーに応じて、成功した場合か、または回答が戻ってくる前に、商人はＰＲｅｓメッセージを生成し、それをカード保有者に送る。このメッセージは、そのステータスに応じて、履行コード、承認コード、捕捉コードおよびクレジットコードを含む。
【００６８】
ＳＥＴウォレットモジュールは、そのメッセージを受信しチェックして、カード保有者に渡す情報を有する非ＳＥＴメッセージを商人に送る。別法として、データの一部を捕捉し、他の手段によりそれをカード保有者に送信してもよい（例えば月別計算書）。
【００６９】
商人ウェブサイトにおける購買がハードウェアトークンを用いて消費者を認証することによりトリガされる上記の決済方法を使用することに加えて、本発明によれば、トークン保有者が、すでにクレジットカードをオンラインで受け付けている任意の商人のところで、自己の既存のクレジットカードの直接の置き換えとして本システムを使用することが可能となる。これは以下のように行われる。
【００７０】
１．消費者は、ハードウェアトークンの発行者に直接クレジットファシリティ（credit facility、信用枠）を申し込む。消費者が信用を承認されたと仮定すると、消費者には、ハードウェアトークンが与えられるか、または消費者の現在のトークンがクレジットカードとしての使用のために今や正当化されたことが通知される。消費者には以下の情報が与えられる。
（ｉ）トークンを用いたすべてのクレジットカード購買に使用される標準的な８桁のプレフィクス、および
（ｉｉ）満了日。
【００７１】
２．その後、消費者は、以前にいずれかの他の従来型クレジットカードを使用することができたところではどこでも、以下のステップを実行することにより、そのクレジットファシリティを使用することができる。
（ｉ）消費者は、クレジットカード細目のために使用される１６桁のボックスの最初の８桁に標準的な８桁のプレフィクスを記入する
（ｉｉ）消費者は、トークンをロック解除し、トークンにより生成されたワンタイムパスワードを残りの桁に記入する
（ｉｉｉ）消費者は、与えられた満了日を書き入れる、および
（ｉｖ）消費者は、通常はカード保有者名を書き込むところに自己のユーザ名を記入する。
【００７２】
３．次に商人は、通常のようにして取引を獲得者に渡す。
【００７３】
４．獲得者は、番号（最初の８桁）を認識し、通常の取引と同様にトークン発行者に取引を渡す。
【００７４】
５．次に発行者は、次の８桁（ワンタイムパスワード）およびユーザ名を認証のためにボールトに渡す。するとボールトはユーザおよびＯＴＰを特定の顧客および口座に変換し、これを発行者に返す。
【００７５】
６．発行者は、口座が依然として正当であり、かつ十分な資金が利用可能であることを確認した後、それに従って取引を承認または拒否し、商人に通知し、適宜、承認コードを与える。
【００７６】
上記の使用法に加えて、カードは、いくつかの異なるクレジットカードの代用として使用可能である。ユーザ名および満了日は不変なままであり、変化するのは８桁のプレフィクスのみである。例えば、１つのハードウェアトークンで、顧客は複数の８桁プレフィクスを有することが可能であり、それぞれのプレフィクスがそれぞれのクレジットカード口座にリンクする。
【図面の簡単な説明】
【００７７】
【図１】本発明によるトークンに基づく認証システムの例である。
【図２】消費者トークンの単純化した概略図である。
【図３】本発明によるトークンに基づく認証および決済システムの例である。
【図４】図３に示されるシステムを用いたＳＥＴ取引を示す。
【図５】ＳＥＴ取引におけるイベントの順序を示す。
【図１】
2004524605.tif 000003
【図２】
2004524605.tif 000004
【図３】
2004524605.tif 000005
【図４】
2004524605.tif 000006
【図５】
2004524605.tif 000007
【国際公開パンフレット】
2004524605.tif 000008
2004524605.tif 000009
2004524605.tif 000010
2004524605.tif 000011
2004524605.tif 000012
2004524605.tif 000013
2004524605.tif 000014
2004524605.tif 000015
2004524605.tif 000016
2004524605.tif 000017
2004524605.tif 000018
2004524605.tif 000019
2004524605.tif 000020
2004524605.tif 000021
2004524605.tif 000022
2004524605.tif 000023
2004524605.tif 000024
2004524605.tif 000025
2004524605.tif 000026
2004524605.tif 000027
2004524605.tif 000028
2004524605.tif 000029
2004524605.tif 000030
2004524605.tif 000031
2004524605.tif 000032
2004524605.tif 000033
2004524605.tif 000034
2004524605.tif 000035
【国際公開パンフレット（コレクトバージョン）】
2004524605.tif 000036
2004524605.tif 000037
【国際調査報告】
2004524605.tif 000038
2004524605.tif 000039
2004524605.tif 000040