(57)【特許請求の範囲】
【請求項１】
製品またはサービスの、プロバイダの端末と、ユーザモバイルデバイスのモバイル決済アプリケーションが関与する取引を認証する方法であって、
ユーザモバイルデバイスに送るべき、取引上の予測不能な数字の組を生成する手段によって、ユーザモバイルデバイスに送るべき、取引上の予測不能な数字の組を生成するように認証サーバを動作させるステップと、
生成された、取引上の予測不能な数字の組を受信し、格納する手段によって、生成された、取引上の予測不能な数字の組を受信し、格納するようにユーザモバイルデバイスを動作させるステップと、
取引の認証の間に、
格納されている取引上の予測不能な数字の組から、使用されているものとしてマークされていない取引上の予測不能な数字を、選択の所定の順に従って選択し、前記選択された取引上の予測不能な数字を前記取引に関連付ける手段によって、格納されている取引上の予測不能な数字の組から、使用されているものとしてマークされていない取引上の予測不能な数字を、選択の所定の順に従って選択し、前記選択された取引上の予測不能な数字を前記取引に関連付けるようにモバイル決済アプリケーションを動作させるステップと、
モバイル決済アプリケーションが、少なくとも、取引に関連付けられた、選択された取引上の予測不能な数字から、取引許可要求の暗号を計算するステップと、
暗号を画像の決済コードに符号化する手段によって、暗号を画像の決済コードに符号化するようにモバイル決済アプリケーションを動作させるステップであって、前記画像の決済コードは、決済のために、モバイル決済アプリケーションからプロバイダの端末に送られる、ステップとを含み、
前記プロバイダの端末は、受信した画像の決済コードを復号し、認証のために、復号された画像の決済コードを認証サーバに送信するように構成された手段を備え、復号された画像の決済コードの、取引上の予測不能な数字は、認証サーバのデータベースに以前に格納された取引上の予測不能な数字の組と比較され、比較が成功した場合に、取引が認証される、方法。
【請求項２】
取引上の予測不能な数字の認証の間に、前記方法は、
復号された画像の決済コードから、認証サーバが、そのデータベースに以前に格納された取引上の予測不能な数字の組から取引上の予測不能な数字を回復するステップと、
認証サーバによって、回復された取引上の予測不能な数字を、復号された暗号中の、受信し選択された取引上の予測不能な数字と比較するステップと、
比較が成功した場合に、認証サーバによって、回復された取引上の予測不能な数字を暗号に加えて、取引の認証のために、回復された取引上の予測不能な数字が加えられた暗号を認証サーバからイシュアに送るステップとを含む、請求項１に記載の方法。
【請求項３】
画像の決済コードが、プロバイダの端末によってスキャンされるためにユーザモバイルデバイスに表示され、認証サーバに送られる、請求項１または２に記載の方法。
【請求項４】
画像の決済コードがＱＲコードまたはバーコードである、請求項３に記載の方法。
【請求項５】
画像の決済コードが、変調された音、変調された振動またはＮＦＣタグメッセージである、請求項１または２に記載の方法。
【請求項６】
使用されていない取引上の予測不能な数字が所定の順に従って選択され、取引上の予測不能な数字が、暗号の許可要求に追加されたユーザの一意の識別子および所定の順に従って認証サーバによって回復される、請求項２から５のいずれか一項に記載の方法。
【請求項７】
取引上の予測不能な数字が、暗号の許可要求に追加された、ユーザの一意の識別子、選択された取引上の予測不能な数字に関連付けられたインデックスおよび所定の順から、認証サーバによって回復される、請求項２から６に記載の方法。
【請求項８】
使用されていない取引上の予測不能な数字がランダムに選択され、インデックスが前記選択された取引上の予測不能な数字に関連付けられ、取引上の予測不能な数字が、暗号の許可要求に追加された、ユーザの一意の識別子および選択された取引上の予測不能な数字に関連付けられたインデックスから、認証サーバによって回復される、請求項２から６に記載の方法。
【請求項９】
取引上の予測不能な数字が、選択ステップおよび回復ステップの後、使用されているものとしてストレージにおいてマークされる、請求項２から８のいずれか一項に記載の方法。
【請求項１０】
モバイル決済アプリケーションに格納された取引上の予測不能な数字がすべて使用されているものとしてマークされると、取引上の予測不能な数字の新たな組が認証サーバによって生成され、格納のためにモバイル決済アプリケーションに送られる、請求項９に記載の方法。
【請求項１１】
認証サーバからモバイル決済アプリケーションへの、取引上の予測不能な数字の生成された組の送信が、
認証サーバとモバイル決済アプリケーションの間で共有される鍵が関与する暗号化アルゴリズムを適用すること、および／または
認証サーバとモバイル決済アプリケーションの間で共有される鍵が関与する完全性アルゴリズムを適用すること
によって保護される、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
モバイル決済アプリケーションおよび取引上の予測不能な数字の組が、ユーザモバイルデバイスのセキュア要素に格納される、請求項１から１１のいずれか一項に記載の方法。
【請求項１３】
認証サーバとイシュアが同じエンティティである、請求項１から１２のいずれか一項に記載の方法。
【請求項１４】
取引が、ＥＭＶ取引規格、Ｍｉｆａｒｅ取引規格、またはＣａｌｙｐｓｏ取引規格に適合する金銭上の取引である、請求項１から１３のいずれか一項に記載の方法。
【請求項１５】
暗号の取引許可要求メッセージが、ユーザによってユーザモバイルデバイスで入力された取引の額、選択された取引上の予測不能な数字、ユーザの金融データ、種々の鍵および取引規格によって規定されるデータ要素から生成される、請求項１から１４に記載の方法。
【請求項１６】
ユーザモバイルデバイスがセルラー電話またはワイヤレス電話、タブレット、スマートフォン、携帯情報端末（ＰＤＡ）、ページャ、ポータブルコンピュータである、請求項１から１５のいずれか一項に記載の方法。
【請求項１７】
製品またはサービスの、プロバイダの端末と、ユーザモバイルデバイスのモバイル決済アプリケーションが関与する取引を、認証サーバによって、請求項１から１６のいずれか一項に従って、認証および許可するためのシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一方向のみに生じる単信通信によって取引を認証するシステムおよび方法に関する。より具体的には、本発明は、画像の決済コードによって決済される販売／サービス提供時点情報管理（「ＰＯＳ」）端末で行われる取引を認証するシステムおよび方法に関する。
【０００２】
より詳細には、本発明は、業者の端末でのモバイルデバイス決済時に表示されるＱＲコード（登録商標）による決済のシステムおよび方法に関する。
【背景技術】
【０００３】
よく知られている決済カードは、さまざまな種類の商取引を容易にするために、世界中の何百万人もの人々に利用されている。業者の敷地での製品またはサービスの購入に関する典型的な取引では、決済カードは、業者の営業所に配置された販売時点端末（「ＰＯＳ端末」）に提示される。ＰＯＳ端末は、決済カードに格納されたデータにアクセスすることが可能なカードリーダまたは類似のデバイスであってもよく、このデータは識別データおよび認証データを含む。決済カードから読み取られたデータは、業者の取引処理システムに提供され、次いで、典型的には業者のアカウントを管理する銀行または他の機関であるアクワイアラに提供される。
【０００４】
チップ型の決済カードのセキュリティおよび世界的な相互運用性を保証するために、ＥＭＶ規格がＥＭＶ対応の決済カードとＥＭＶ対応のＰＯＳ端末の対話を規定していることがよく知られている。したがって、ＥＭＶ決済を受け入れるためには、業者は二方向通信プロトコルをサポートするＥＭＶ対応のＰＯＳ端末を配備する必要がある。そのようなＥＭＶ対応のＰＯＳ端末ハードウェア、それらの配備および維持は、業者にとって相当なコストである。
【０００５】
この既存の決済手段は十分に機能しているが、主として、カード会社が損失を業者および銀行に回すことによって消費者を保護してきていることにより、銀行、業者および消費者が、金銭上の取引を行うための簡単で安全な方法を所望しているのは明らかである。
【０００６】
今日では、技術によって、消費者が購入する方法には変革が起こり、小売経路の範囲が拡大してきた。実際、携帯電話などのモバイルデバイスは、日常生活においてますます多様な役割を担うようになっている。音声およびメッセージの伝送という従来の役割を越えて携帯電話を機能拡張させようとする試みの中で、多くの新たな機能およびサービスが開発されつつある。
【０００７】
ユーザが取引を実行するための機構は、今日の技術とともに進化しつつある。そのような機構には、ブルートゥース（登録商標）通信、近距離無線通信（ＮＦＣ）、クイックレスポンス（ＱＲ）コードスキャニング、ＷｉＦｉ通信などが含まれる。
【０００８】
決済行為が施設によって近距離無線通信（ＮＦＣ）で自動化される場合、施設にはＮＦＣに適合した決済端末がなければならず、これは、現場にＮＦＣ対応のデバイスを置くことに関するハードウェア、ソフトウェア、およびサポート費のために、施設には不便である。さらに、顧客がＮＦＣ機構を使用するためには、顧客のスマートフォンが、クレジットカード番号、ロイヤルティ番号などの機密情報を顧客のスマートフォンに格納している必要がある。最良のソフトウェアであっても、スマートフォンが取得されるか、または遠隔接続がスマートフォンに行われ得る場合は、ハッキングの対象になり、危険にさらされる可能性がある。
【０００９】
顧客が容易に決済できるようにするＱＲ（クイックレスポンス）コードまたはバーコードを使用する取引の場合、情報は、取引する三者：売り手（自身のＰＯＳを使用）、買い手（自身の携帯電話を使用）、および決済システムのサーバ（銀行など）の間で流れる。売り手は、１つまたは複数の製品を売る取引を行う必要があるとき、ＰＯＳに対するバーコードまたはクイックレスポンス（ＱＲ）コードを必要とする。バーコードまたはＱＲコードが表示または印刷され、買い手に提供され、買い手は、モバイルデバイスによってそれを取り込み、ＳＭＳ、ＷｉＦｉ、ネットワーク、インターネットなどによってサーバへ送る。サーバは、買い手の識別子を確認する。ひとたびそのような識別子が確認されると、サーバは、実施された決済の通知を売り手に送り、これによって、売り手は販売を終わらせ、品物および購入受領書を送り届けることができる。
【００１０】
この方法には、ＰＯＳを使用する必要があり、サーバが多くの情報交換に占有され、その年の期間によっては、膨大な量の必要な取引のためにこれが重大になり得るという欠点がある。
【００１１】
オンライン取引の場合、インターネット上のｅコマースおよびｍコマースサイトの大半は特別な（ａｄ  ｈｏｃ）決済方法を使用する。たとえば、ある人がオンラインでコーヒーを購入したい場合、その人は自身の個人情報および金融情報をウェブサイトで入力することによって、アカウントを作成し、オンライン上のコーヒー業者に登録する必要がある。さらに、このアカウント作成処理は、他の購入では他のベンダについて繰り返さなければならない。この処理は、関与するいずれの当事者にも不便である。業者は、専用のアカウント管理および決済システムを維持しなければならない。顧客は、業者のウェブサイトごとにユーザ名およびパスワード情報を覚えておくだけでなく、多くの業者について別個のアカウントを作らなければならない。この決済システムでは、消費者が決済する準備ができたとき、ＰＯＳ端末／システムは、２次元（２Ｄ）バーコードまたはクイックレスポンス（ＱＲ）コードを取引詳細とともに印刷または表示することができる。業者はこれを消費者に提供し、消費者は自身のモバイルデバイスでコードをスキャンする。スキャンされた画像コードは消費者の携帯電話と関連付けられ、次いで、取引決済に向けて、モバイルデバイスを介してユーザアカウントに送られ得る。
【００１２】
この決済システムには、決済の間、ユーザアカウントとモバイルデバイスの間で接続データを使用する必要があり、接続データが決済の間利用できないときにこれが重大になり得るという欠点がある。
【００１３】
顧客と対話するために使用される多様な既存の機構についての１つの問題は、しばしば顧客が、取引が完了し得る前に接続を確立するように要求されることである。これは、消費者によっては取引に関わりたいと思わないセキュリティのリスクを生じさせ、取引を遅らせることもある。
【００１４】
さらに、ＱＲコード決済は、双方向通信ではないため、ＥＭＶ取引プロトコルに準拠していない。したがって、１つのＱＲコードのみを使用することによって取引を認証できるようにする種類のＥＭＶ取引を行うことはできない。
【００１５】
モバイルコンピューティング機能とロバストな無線ネットワークインフラの開発が結びつくにつれて、ＥＭＶ規格などの標準的なプロトコルに準拠し得る金銭上の取引を行うための、より早く、安く、安全かつ便利な画像コード決済システムがますます求められるのは明らかである。
【００１６】
その結果、モバイルデータ接続に依存する必要も、取引を認証可能にしたままＮＦＣのような双方向通信をサポートする必要もなく、個人間で金銭上の取引を行うことに対する強い要求が存在する。
【発明の概要】
【課題を解決するための手段】
【００１７】
本発明は、一方向の通信対従来のセキュリティ保護された二方向通信（ＥＭＶ取引）での取引の認証についての上記のセキュリティ上の欠点に対処する。
【００１８】
本発明は、一方向の通信を介して、モバイルデバイス内のモバイル決済アプリケーションと業者の間の取引を認証するシステムおよび方法に関する。本発明の範囲外の安全なチャネルおよびプロトコルによって、これらの取引がモバイル決済アプリケーションのイシュアに送られることがさらに想定される。
【００１９】
本明細書における技法は、消費者（顧客またはユーザ）が、以下を必要とせずに自身の取引について決済できるようにする機構を提供する：モバイルの販売時点（ＰＯＳ）端末、手渡すクレジット／デビットカードまたは近距離無線通信（ＮＦＣ）でのタップ。その代わりに、画像の決済コードが取引の決済をするために使用される。今日では、ＱＲコード決済またはバーコード決済などの画像の決済コードがモバイル決済の分野でますます一般的になっており、これは、スマートフォン、タブレットまたはカメラインターフェースを備えた類似のデバイスなどの、人口の多くが既に所有している一般的なパーソナルアクセサリ以外の追加のハードウェアを必要としないためである。決済は、ユーザモバイルデバイスに表示された画像の決済コードを業者の画像スキャナが読み取ったときに完了される。
【００２０】
この種の決済は双方向通信プロトコルをサポートする追加のハードウェアを必要とせず、通常は消費者の携帯電話の画面である、ＱＲコードを表示するためのディスプレイと、金銭登録器のＱＲコードスキャナまたは消費者の携帯電話画面に表示されるＱＲコードをスキャンするための業者の携帯電話のカメラであり得る、ＱＲコードスキャナとが必要なだけである。
【００２１】
ＱＲコード決済を受け入れるために、アクワイアラは１つのソフトウェアを業者の金銭登録器または携帯電話に組み込むだけでよく、コストはほぼゼロである。
【００２２】
画像コードによる決済での取引を信頼できるようにするために、本発明は、前記取引を認証する手段を提案する。そのため、モバイル決済アプリケーションが好ましくはユーザモバイルデバイスのセキュア要素にダウンロードされたとき、登録処理が可能になる。サーバへのこの登録処理では、ユーザのアカウントが作成され、個数Ｎの取引上の予測不能な数字の組が生成される。この予測不能な数字の組は、モバイル決済アプリケーションに安全に送信され、セキュア要素の中に安全に格納される。決済アプリケーションは、モバイル決済アプリケーションによって連続して実行される次のＮ回の取引に、格納されたＮ個の取引上の予測不能な数字を使用する。同じ予測不能な数字の組がサーバデータベースに格納され、サーバによって、連続して次のＮ回の取引認証に使用される。生成された取引上の予測不能な数字は、ある取引に対して厳密に１回使用される。
【００２３】
シーケンスの参照によって、サーバは標準的な取引認証アルゴリズムを使用して取引を認証することができ、このアルゴリズムは、決済アプリケーションとサーバの間で共有される取引上の予測不能な数字と鍵を必要とする。標準的な取引アルゴリズムは、ＥＭＶ取引処理、Ｍｉｆａｒｅ取引処理、またはＣａｌｙｐｓｏ取引処理であってもよい。こういった規格は、当業者にはよく知られており、本明細書にではこれ以上の説明は必要ない。
【００２４】
本明細書に記載される実施形態は、任意の適切な取引規格であり得ることが分かっていることにより、ＥＭＶ取引処理を対象とする。決済処理では、業者は精算端末に決済額を表示する。消費者は、モバイル決済アプリケーションを自身のモバイルデバイスで起動する。カード保有者は、取引額を自身のモバイルデバイスに入力する。モバイル決済アプリケーションは、最初の使用されていない取引上の予測不能な数字を選び、標準的なＥＭＶ許可要求を作り出す。この許可要求は、消費者によって入力された取引額と、取引額、取引上の予測不能な数字および他の関連する金融データを含む取引データのリストから、ＥＭＶ鍵を使用して生成された取引暗号とを含む。許可要求が生成されると、現在使用されている取引上の予測不能な数字は、使用されているものとしてセキュア要素においてマークされる。モバイル決済アプリケーションは、許可要求を含む画像の決済コードを生成する。前記画像の決済コードはＱＲコードであり得る。業者は、消費者のモバイルデバイスに表示されたＱＲコードをスキャンする。
【００２５】
業者は、スキャンされたＱＲコードから復号された許可要求をサーバに送る。サーバは受信した許可要求を確認する。受信した許可要求の内容から、サーバは、そのデータベースに格納されている対応する取引上の予測不能な数字を回復する。回復された取引上の予測不能な数字は、使用されているものとしてサーバのデータベースにおいてマークされる。許可要求の取引暗号は、回復された取引上の予測不能な数字とともにイシュアの銀行に送られる。イシュアの銀行は、ＥＭＶ鍵および取引データの同じリストが関与する標準的なＥＭＶアルゴリズムを使用して許可要求を確認する。業者は最終的に、イシュアの銀行から、直接的にまたはサーバを介して許可要求の結果を通知される。
【００２６】
本発明は、モバイルデバイスと業者の間の一方向の取引に依拠する。取引を認証するために提案される方法では、決済アプリケーションと、取引を認証するイシュアとの間で相互の認証を実行する必要はない。
【００２７】
本発明の実施形態の各態様は概して、ユーザモバイルデバイスを介してモバイル決済アプリケーションによって提供される画像コードによって取引を認証する方法に関し、この方法は、以下を含む：
−  来るべきＥＭＶ取引のために、取引上の予測不能な数字の組をサーバによって生成するステップ、
−  取引上の予測不能な数字の生成された組を、消費者のモバイルデバイスのセキュア要素に常駐するモバイル決済アプリケーションに送るステップ、
−  受信した取引上の予測不能な数字の組を消費者のモバイルデバイスの内部に格納するステップ、
−  取引上の予測不能な数字の同じ組をサーバのデータベースに格納するステップ、
−  取引許可要求のＥＭＶ暗号を生成するために、セキュア要素に格納された取引上の予測不能な数字を順に使用するステップ、
−  取引許可要求メッセージから画像コードを生成するステップ、
−  ユーザのモバイルデバイスディスプレイに画像コードを表示するステップ、
−  画像コードをスキャンし、許可要求メッセージを復号し、復号された許可要求をサーバに送るステップ、
−  取引上の予測不能な数字をサーバデータベースから回復するステップ、
−  取引許可要求の最終的な承認のために、回復された取引上の予測不能な数字とともに許可要求をイシュアの銀行に転送するステップ。
【００２８】
本発明の実施形態の各態様は、特に、製品またはサービスの端末プロバイダとユーザモバイルデバイスのモバイルアプリケーションが関与する取引を認証および許可する方法に関し、この方法は、以下を含む：
−  サーバへのモバイルアプリケーションの登録処理において：
−  取引上の予測不能な数字の組を生成するようにサーバを動作させるステップ、
−  取引上の予測不能な数字の前記生成された組をモバイルアプリケーションに送るようにサーバを動作させるステップ、
−  取引の認証および許可において：
−  格納されている使用されていない取引上の予測不能な数字を選択するようにモバイルアプリケーションを動作させるステップであって、前記選択された使用されていない取引上の予測不能な数字が前記取引を識別可能にする、動作させるステップ、
−  選択された取引上の予測不能な数字から、取引許可要求メッセージを作り出すようにモバイルアプリケーションを動作させるステップ、
−  許可要求を単信通信データに符号化するようにモバイルアプリケーションを動作させるステップ、
−  単信通信データを受信し、復号するように端末プロバイダを動作させるステップ、
−  取引の認証および許可のために、復号された単信通信データをサーバに送るように端末プロバイダを動作させるステップ、
−  復号された取引許可要求メッセージの内容と、サーバの取引上の予測不能な数字のデータベースとの間での、取引上の予測不能な数字の一致を確認するようにサーバを動作させるステップ、
−  確認が成功した場合、一致した取引上の予測不能な数字を許可要求メッセージに加えるようにサーバを動作させるステップ、
−  取引許可要求をイシュアに送るようにサーバを動作させるステップ、
−  イシュアから、前記取引が認証および許可されるかどうかを示す取引許可の結果を受信するようにサーバを動作させるステップ、
−  取引許可の結果を端末プロバイダに転送するようにサーバを動作させるステップ。
【００２９】
これらおよび他の利点を実現するために、また、具現化され、広く説明される本発明の目的に従って、本発明は、製品またはサービスのプロバイダとユーザモバイルデバイスのモバイルアプリケーションが関与する取引を認証および許可する方法を提案し、この方法は、以下を含む：
−  サーバによって、取引上の予測不能な数字の組を生成するステップ、
−  取引上の予測不能な数字の前記生成された組をモバイルアプリケーションに送るステップ、
−  モバイルアプリケーションに格納された使用されていない取引上の予測不能な数字を前記取引の識別に選択するステップ、
−  選択された取引上の予測不能な数字から取引許可要求メッセージを作り出すステップ、
−  許可要求を単信通信データに符号化するステップ、
−  単信通信データを受信および復号し、取引の認証および許可のために、プロバイダからサーバに復号された単信通信データを送るステップ、
−  サーバにおいて取引上の予測不能な数字を回復するステップ、
−  回復された取引上の予測不能な数字を許可要求に追加するステップ、
−  サーバによって、取引許可要求をイシュアに送るステップ、
−  イシュアから、前記取引が認証および許可されるかどうかを示す取引許可の結果を受信するステップ。
【００３０】
他のさまざまな方法では、単信通信データを受信するために、プロバイダのスキャナ端末は、符号化された許可要求をスキャンする。
【００３１】
他のさまざまな方法では、単信通信データはＱＲコードまたはバーコードなどの画像コードであり、この画像コードは、プロバイダによってスキャンされるためにユーザモバイルデバイスに表示され、サーバに送られる。単信通信データはまた、変調された音、変調された振動またはＮＦＣタグメッセージであり得る。
【００３２】
他のさまざまな方法では、選択された取引上の予測不能な数字が、作り出された取引許可要求メッセージに追加されたとき、サーバは、受信した選択された取引上の予測不能な数字を、回復された取引上の予測不能な数字と比較する。比較が成功した場合、サーバは、回復された取引上の予測不能な数字を許可要求に追加し、それをイシュアに送る。
【００３３】
他のさまざまな方法では、使用されていない取引上の予測不能な数字が所定の順に従って選択される。取引上の予測不能な数字は、ユーザの一意の識別子および所定の順に従ってサーバによって回復される。他のさまざまな方法では、取引上の予測不能な数字は、サーバによって、ユーザの一意の識別子、許可要求に追加された選択された取引上の予測不能な数字に関連付けられたインデックスおよび所定の順から回復され得る。
【００３４】
他のさまざまな方法では、使用されていない取引上の予測不能な数字がランダムに選択され、インデックスが前記選択された取引上の予測不能な数字に関連付けられ、取引上の予測不能な数字が、サーバによって、ユーザの一意の識別子および選択された取引上の予測不能な数字に関連付けられたインデックスから回復される。
【００３５】
他のさまざまな方法では、取引上の予測不能な数字が、選択ステップおよび回復ステップの後、使用されているものとしてストレージにおいてマークされる。モバイル決済アプリケーションに格納された取引上の予測不能な数字がすべて使用されているものとしてマークされると、取引上の予測不能な数字の新たな組がサーバによって生成され、格納のためにモバイルアプリケーションに送られる。
【００３６】
他のさまざまな方法では、サーバからモバイル決済アプリケーションへの、取引上の予測不能な数字の生成された組の送信が、以下によって保護される：
−  サーバとモバイル決済アプリケーションの間で共有される鍵が関与する暗号化アルゴリズムを適用すること、および／または
−  サーバとモバイル決済アプリケーションの間で共有される鍵が関与する完全性アルゴリズムを適用すること。
【００３７】
他のさまざまな方法では、モバイルアプリケーションおよび取引上の予測不能な数字の組は、モバイルデバイスのセキュア要素に格納される。
【００３８】
他のさまざまな方法では、取引は、ＥＭＶ取引規格、Ｍｉｆａｒｅ取引規格またはＣａｌｙｐｓｏ取引規格に適合する金銭上の取引である。
【００３９】
本発明の方法は、とりわけ以下の多くの技術的利点を有する：
−  既存のＥＭＶインフラへの影響がない、
−  セキュア要素に格納された決済モバイルアプリケーションを使用することによる高いセキュリティレベル、
−  ＮＦＣのＰＯＳを配備する必要がない、
−  決済ネットワークのための配備および維持のコストを減少させる、
−  ＱＲコードスキャナを既に備えている業者がますます増えており、ＱＲコードスキャナのコストはＮＦＣのＰＯＳよりもはるかに小さい、
−  決済においてモバイルデータは必要ではなく、決済についてモバイルデータに依存しない、
−  消費者側における迅速な決済処理、
−  消費者は取引額を自身で入力するのでより信頼を感じる、
−  簡単であること、
−  人間工学的設計、
−  ＥＭＶインフラからの完全な独立。
【００４０】
以下の詳細な説明は、図面を用いてより深く理解されよう。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態による、画像の決済コードを用いた取引に関与する様々なエンティティを示す図である。
【図２】本発明の例示的な一実施形態による、決済アプリケーションの登録段階における論理流れ図である。
【図３】本発明の例示的な一実施形態による、取引の流れ図である。
【発明を実施するための形態】
【００４２】
本発明は、任意の特定ハードウェアまたはソフトウェアの実装に固有のものではなく、実装の細部を越えた概念レベルにある。本発明の種々の他の実施形態および変形形態は、本発明の趣旨または範囲を逸脱することなく形成され得ることを理解されたい。以下は、特定の本発明の実施形態を実際に実装することについての理解を助けるために記載する。
【００４３】
異なる図面において、同一の要素には同じ参照番号を付してある。分かりやすくするために、本発明の理解に有用なそれらの要素およびステップのみを図面に示し、以下で説明している。
【００４４】
さらに、当事者間のデータ通信およびその環境の機構はいずれも詳述しておらず、本発明はここでも通常の機構に対応する。
【００４５】
さらに、本明細書に含まれる種々の図に示す接続線は、種々の要素間の例示的な機能的関係および／または物理的結合を表すことが意図されている。多くの代替形態または追加の機能的関係もしくは物理的接続は、実用的なシステムに存在し得ることに留意されたい。さらに、図１における種々のエンティティは、任意の適切な通信プロトコルを使用して、任意の適切な通信媒体（インターネットを含む）を介して通信できる。
【００４６】
さらに、行為が端末によって行われると述べられているとき、その行為は、前記端末のプログラムメモリに記録された命令コードによって制御されるこの端末のマイクロプロセッサによって実際に実行される。行為はまた、アプリケーションまたはソフトウェアに帰する。これは、アプリケーションまたはソフトウェアを構成する命令コードの一部がマイクロプロセッサによって実行されることを意味する。
【００４７】
図１は、モバイル通信デバイス１１のモバイル決済アプリケーション１０を管理するための流れ図に関与するエンティティを示す。議論を分かりやすくするために、各エンティティは１つだけ図１に示してある。しかしながら、技術の実施形態は、各エンティティを２つ以上含んでもよいことが理解される。さらに、技術のいくつかの実施形態は、図１に示すエンティティのすべてよりも少ないエンティティを含んでいてもよい。図１は、サーバ処理環境１２およびイシュア１３が実装されるシステムの例を描いている。
【００４８】
モバイルデバイス１１はセキュア要素１５を含む。モバイルデバイス１１の内部のセキュア要素１５は、高度なセキュリティを必要とするデータおよびアプリケーションをホスト管理し、格納するために使用される。好ましい実施形態において、決済アプリケーション１０はセキュア要素１５にインストールされる。セキュア要素１５は、セキュア要素のイシュアによってモバイルデバイス１１に提供される。セキュア要素のイシュアは、必ずしも決済処理のメンバまたは決済のイシュア１３と同じエンティティでなくてもよい。たとえば、セキュア要素のイシュアは、モバイルネットワークオペレータ（ＭＮＯ）であっても、モバイルデバイス１１の製造業者であってもよい。
【００４９】
モバイル決済アプリケーション１０は、モバイルデバイス１１の内部にあるセキュア要素１５で実装され得る決済機能を提供するソフトウェアまたはアプリケーションである。モバイル決済アプリケーション１０は、ユーザの決済情報を管理し、取引署名を生成する機能を提供する。決済取引において、モバイル決済アプリケーション１０は、業者１４を介して単信通信で決済データをサーバ１２に送信する。
【００５０】
モバイル決済アプリケーション１０は、ユーザの対話（たとえば、情報の入力および閲覧）のために、モバイルデバイス１１のユーザインターフェースソフトウェアとのインターフェースをとる。ユーザインターフェースソフトウェアはまた、モバイル決済アプリケーション１０と通信して、決済取引情報を業者１４のために表示する。
【００５１】
本明細書で使用される場合、「イシュア」という用語は、金融口座（たとえば、クレジット、デビット、またはプリペイド）および金融口座に関連付けられたモバイル決済アプリケーション１０を発行および維持する任意のエンティティを含む。あるいは、イシュア１３は、モバイル決済アプリケーション１０を直接発行しなくてもよく、代わりにサーバ１２などの、モバイル決済アプリケーション１０を発行する別の当事者と契約してもよい。イシュアは銀行であり得る。
【００５２】
モバイル決済アプリケーション１０は、ユーザモバイルデバイス１１の内部のセキュア要素１５にロードされる。モバイル決済アプリケーション１０は、セキュア要素１５がユーザに送達される前に、セキュア要素１５の製造またはパーソナライゼーションの段階で事前にロードされることもある。モバイル決済アプリケーション１０はまた、セキュア要素１５の発行後の段階で、通信ネットワークを介してイシュア１３または他のエンティティのデータベースからユーザによってダウンロードされることもある。
【００５３】
モバイルデバイス１１は、画像決済デバイス用の任意の適切な形態であってもよい。たとえば、適切なモバイル通信デバイス１１は、ユーザの財布および／またはポケットに収まるように、手で持てる大きさかつコンパクト（たとえば、ポケットサイズ）であり得る。モバイルデバイス１１は、典型的には、プロセッサ、メモリ、入力装置、出力装置、および画像コード生成装置を備え、このすべては、プロセッサに動作可能に結合されている。モバイル通信デバイス１１の具体例には、セルラー電話またはワイヤレス電話、タブレット、スマートフォン、携帯情報端末（ＰＤＡ）、ポータブルコンピュータなどが含まれ得る。モバイル通信デバイス１１が本出願において言及されているが、本発明の実施形態は、本明細書に記載のエンティティと通信し、画像コードを生成することが可能ないくつかの異なるモバイルユーザデバイスで実装され得る。
【００５４】
一実施形態によれば、画像の決済コードは、クイックレスポンス（ＱＲ）コード、任意の他のタイプのコード、またはそこに形成されるか、それに関連する各タイプのコードの任意の組み合わせであり得る。
【００５５】
サーバ処理環境１２は、業者１４と通信するように構成されたサーバコンピュータまたは一連のサーバコンピュータであり得る。サーバ１２はイシュア１３と通信する。サーバ１２は、イシュア、アクワイアラ、サードパーティのサービスプロバイダ、または信頼のおけるサービス管理者によって実装され得る。サーバ１２は、画像の決済コード１７を介して取引の認証を容易にするために使用され得る。たとえば、サーバ１２は、画像の決済コード１７の内容を示す業者１４からの通信を受信することができ、通信に応答して購入取引を容易にすることができる。
【００５６】
業者１４は、たとえば、１つまたは複数のサーバを使用して実装され得る。具体的には、業者は、プロバイダによって管理されるサーバおよびデータベースによって具現化され得る。業者１４は、たとえば、業者の精算端末、モバイルデバイス、コンピュータ、および／またはサーバであり得る。業者１４は、画像の決済コードによってユーザによる購入を行うために使用され得る。業者１４はスキャナ１６を備える。スキャナ１６は、ＱＲコードスキャナ、バーコードスキャナ、ＳＫＵスキャナ、画像認識ソフトウェアによって制御されるカメラまたは任意の他のタイプの画像コードスキャナであり得る。スキャナ１６は、画像の決済コード１７をスキャンするために使用され得る。
【００５７】
よく知られている安全な通信は、業者１４と、イシュア１３と、サーバ１２との間で確立され得る。この安全な通信は、相互に認証されたセキュアソケット層（ＳＳＬ）チャネルによって確立され得る。この安全な通信は、たとえば、少なくとも１０２４ビットの鍵を用いるＲＳＡ、トリプルデータ暗号化規格（ＤＥＳ）、１２８ビットの高度暗号化規格（ＡＥＳ）、最低でも１２８ビットの鍵長を使用するＲＣ４ストリーム暗号化アルゴリズムなどのデータ暗号化規格を使用してもよい。これらの暗号化規格は、安全なセッションを作成するために使用され得る。当業者には認識されるように、これらのエンティティ間での、任意の他の適切な形態のセキュリティ保護された通信が実装されてもよい。
【００５８】
モバイル決済アプリケーション１０がモバイルデバイス１１のセキュア要素１５にロードされると、ユーザは、登録処理を開始し、ユーザアカウントをサーバ１２に作成することができる。
【００５９】
図２は、サーバ１２にモバイル決済アプリケーション１０を登録する例示的な流れ図を示す。その中で、セキュア要素１５とサーバ１２の間の処理フローが、個々の番号を割り振られたラベル付き矢印によって描かれている。フローは、大きくなる番号で示されているように、上から下に連続して実行されることが理解される。しかしながら、このプロトコルの実行には、特定の順番に沿わない複数の例が並行して存在し得ることに留意されたい。
【００６０】
図２は、例示的実施形態に従って実行され得る機能の組２０を描くフローチャートである。機能の組２０は、ユーザモバイル決済アプリケーション１０をサーバ１２に登録するために実行され得る。機能の組２０は、ステップ２１から３２に示してある。次にこれらのステップの説明を続ける。
【００６１】
ステップ２１では、モバイル決済アプリケーション１０が、登録処理を開始するためにユーザがアクティブ化することができるモバイルデバイス１１に登録アイコン（図示せず）を表示する。登録アイコンは、「登録する」という文字列または何らかの他の文字列もしくはシンボルを含むことができる。
【００６２】
ステップ２２では、モバイル決済アプリケーション１０が、ユーザがユーザの識別子を入力するように促されるユーザモバイルデバイス１１に自由形式の入力フィールドを表示する。このユーザの識別子は、移動局国際加入者登録番号（Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ  Ｎｕｍｂｅｒ）（「ＭＳＩＳＤＮ」、ユーザの携帯電話番号）、決済アカウントの主口座番号（「ＰＡＮ」）、または身分登録番号（Ｎａｔｉｏｎａｌ  Ｉｄｅｎｔｉｆｙ  Ｎｕｍｂｅｒ）であり得る。ユーザ識別子は、ユーザの何らかの他の一意の識別子でもあり得る。別の実施形態において、ユーザ識別子はまた、モバイル決済アプリケーション１０、セキュア要素１５、またはユーザモバイルデバイス１１から自動的に読み出され得る。
【００６３】
ステップ２３では、モバイル決済アプリケーション１０が、モバイルデバイスを介して、ユーザの一意の識別子をサーバ１２に送信する。ステップ２４では、サーバ１２が、ユーザの一意の識別子に関連するユーザアカウントが既にそのデータベースに存在するかどうかを確認する検索を実施する。そのようなユーザアカウントが存在しない場合、ステップ２５で、サーバ１２は、たとえばワンタイムＰＩＮコードを含むＳＭＳによってユーザモバイルデバイス１１に応答することができる。ステップ２６で、次いでユーザが、モバイル決済アプリケーション１０によってユーザモバイルデバイス１１に表示された対応するフィールドにＰＩＮコードを入力することができる。ステップ２７では、モバイルデバイス１１が、ユーザによって入力されたＰＩＮコードをサーバ１２に返し、サーバ１２は返されたＰＩＮをステップ２８で確認する。ＰＩＮの確認が成功した場合、ステップ２９で、クラウド１２がユーザアカウントをそのデータベースに作成し、モバイル決済アプリケーション１０に、登録が成功したことを通知することができる。この説明のために、ＰＩＮコードは、数字だけであってもよいが、数字だけである必要はない。数字だけではないＰＩＮコードは、アルファベットと数字のＰＩＮコードであり得る。
【００６４】
別の実施形態において、ユーザアカウントが存在しない場合、ステップ２４で、クラウドサーバ１２はステップ２９にジャンプし、ＰＩＮ入力を要求することなくユーザアカウントをそのデータベースに作成する。
【００６５】
一実施形態において、モバイル決済アプリケーション１０は、ユーザプロフィールをサーバ１２に作成することができ、そのためにユーザのファーストネーム、ユーザのラストネーム、生年月日、ｅメールアドレス、物理アドレス、イシュア１３の識別などのユーザ属性をユーザに入力させる。モバイルデバイスは、データをサーバ１２に渡し、サーバ１２は、新たに作成されたユーザアカウントにおけるこれらの細目をそのデータベースに格納する。
【００６６】
ユーザのアカウントが作成されると、ステップ３０で、サーバ１２は、個数Ｎの取引上の予測不能な数字の組を連続して生成する。これらの取引上の予測不能な数字は、ＥＭＶの取引上の予測不能な数字のフォーマットおよび質に適合し得る。
【００６７】
サーバ１２は、暗号化されたデータおよびメッセージ認証コード（「ＭＡＣ」）の値を含み得るメッセージを生成する。暗号化されたデータは、生成された取引上の予測不能な数字の組を、セキュア要素１５と共有されるセッション暗号化鍵ＥＮＣで暗号化した結果である。ＭＡＣ値は、メッセージの内容の少なくとも一部についてのＭＡＣ演算の結果である。ＭＡＣ演算は、セキュア要素１５と共有されるセッション鍵ＭＡＣおよび暗号のチェックサムアルゴリズムを使用してＭＡＣ値を生成し、この値は後でデータが改変されていないことを保証するために使用され得る。
【００６８】
これらのセッション鍵は、モバイル決済アプリケーション１０とサーバ１２の間で交換されるメッセージの秘匿性および完全性を保護するために使用される。
【００６９】
ステップ３１では、サーバ１２が、暗号化されたデータおよびＭＡＣ値を含むメッセージをセキュア要素１５に送ることができる。モバイル決済アプリケーション１０はＭＡＣ値を計算する。計算されたＭＡＣ値は、受信したメッセージが変更されているかどうか確認するために、受信したＭＡＣ値と比較される。一実施形態において、ＭＡＣ値の確認が失敗した場合、処理フローは閉じられてもよく、モバイル決済アプリケーションはサーバ１２に、ＭＡＣ値が改ざんされていることを通知することができる。ＭＡＣ値が成功裏に確認された場合、セキュア要素１５は、共有されているセッション鍵ＥＮＣを用いて、暗号化されたデータを復号することができる。
【００７０】
各実施形態において、ステップ３０では、サーバ１２によって生成された取引上の予測不能な数字の組が、モバイル決済アプリケーション１０に、暗号化およびＭＡＣなしのクリアテキストで（ｉｎ  ｃｌｅａｒ）、ＭＡＣありのクリアテキストで、またはＭＡＣなしの暗号化されたメッセージで送られ得る。
【００７１】
生成された取引上の予測不能な数字の復号された組は、外部からはアクセスできないセキュア要素のメモリに好ましくは記憶される。
【００７２】
図３は、一実施形態における例示的な取引の流れ図４０を示す。業者の場所での購入において、取引フローがユーザの行為で開始される。実際、取引フロー４０は、ユーザによって、たとえばモバイルデバイス１１に表示された前記モバイル決済アプリケーションのアイコンをクリックすることにより、モバイル決済アプリケーション１０との対話を介してアクティブ化される。
【００７３】
ステップ４１では、次いでユーザが、ユーザモバイルデバイスに表示された対応するフィールドに購入取引の額を入力することができる。ステップ４２では、モバイルデバイス１１が、ユーザが入力した取引額を、ＥＭＶ規格に適合するフォーマットでモバイル決済アプリケーション１０に送る。
【００７４】
額が受信されると、ステップ４３で、モバイル決済アプリケーション１０は、サーバ１２によって前のステップ３０から３２で生成された使用されていない取引上の予測不能な数字が残っているかどうか確認する。セキュア要素１５のモバイル決済アプリケーション１０に残っている使用されていない取引上の予測不能な数字がない場合、ステップ４４で、コマンドがサーバ１２に送られて、取引上の予測不能な数字の別の組を生成する。サーバ１２がそのような生成コマンドを受信すると、図２のステップ３０から３２が再び実施される。セキュア要素１５のモバイル決済アプリケーション１０に残っている使用されていない取引上の予測不能な数字（複数可）がある場合、モバイル決済アプリケーション１０は、１つの使用されていない取引上の予測不能な数字を選ぶ。一実施形態において、使用されていない取引上の予測不能な数字は、ステップ４５で、所定の順に従って選ばれる。使用されるとき、前記取引上の予測不能な数字は選ばれたものとしてマークされる。
【００７５】
別の実施形態において、モバイル決済アプリケーション１０は、１つの使用されていない取引上の予測不能な数字を、所定の順を使用するのではなくランダムに選ぶ。一実施形態において、インデックスが選ばれた取引上の予測不能な数字に関連付けられ得る。この場合、インデックスは許可要求に付加される。好ましい実施形態において、ステップ４６では、モバイル決済アプリケーションがＥＭＶ取引処理を実施する。
【００７６】
この処理の終わりに、応答メッセージは、モバイル決済アプリケーション１０によって生成されたＥＭＶフォーマットに適合する。この応答メッセージは取引暗号を含む。このメッセージは、ステップ４１でユーザによって入力された取引額およびステップ４５で選ばれた取引上の予測不能な数字を使用して生成され、ＥＭＶ規格で規定されている種々の鍵およびデータ要素が関与する。一実施形態において、ステップ４７では応答メッセージがユーザモバイルデバイスに送信される。次いでユーザモバイルデバイスは、ステップ４８で、応答メッセージを画像コードフォーマットに符号化し、前記符号化された画像コード１７をモバイルデバイスに表示する。別の実施形態において、モバイル決済アプリケーション１０は、応答メッセージを画像コードに符号化する。ユーザモバイルデバイスに送信された画像コードが表示される。
【００７７】
画像コードはクイックレスポンス（ＱＲ）コードであり得る。コードは、バーコード、または任意の他の画像タイプのコードであり得る。コードは、モバイルデバイスによって読み取られるか、またはスキャンされ得る。ステップ４９では、コードは、業者のスキャナ１６によってモバイルデバイス画面からスキャンされる。
【００７８】
本明細書で使用される場合、「スキャン」という用語は、画像コードなどから、コードまたは他の情報を決定する任意の処理を指すことができる。
【００７９】
スキャンされたコードは、スキャナ１６を介して業者１４に通信される。次いでステップ５０で、業者１４はスキャンされたコードを復号して、そこに含まれる情報を回復する。業者は、業者識別コードおよびリポジトリアドレスを応答メッセージに付加することができる。
【００８０】
ステップ５１では、業者１４は、取引を認証および許可するために応答メッセージをサーバ１２に送信する。
【００８１】
ステップ５２では、サーバ１２はまず、応答メッセージからユーザ識別子を抽出する。この抽出されたユーザ識別子から、サーバは、この取引に使用される取引上の予測不能な数字を、そのデータベースから所定の順序に従って回復する。サーバ１２は、回復された取引上の予測不能な数字を、使用しているものとしてそのデータベースにおいてマークする。次いで、サーバ１２は、応答メッセージの取引暗号を含むＥＭＶ許可要求を作り上げ、ここには、回復された取引上の予測不能な数字が追加される。
【００８２】
ステップ５３では、サーバ１２は許可要求をイシュア１３に送る。ステップ５４では、イシュア１３は、ＥＭＶ規格で規定された種々の鍵およびデータ要素を含む、許可要求から抽出された他のデータ要素とともに、ステップ４１でユーザによって入力された額およびステップ５２でサーバ１２によって回復された取引上の予測不能な数字を使用することによって、ＥＭＶ規格で規定されている手順に従って許可要求の内容を確認する。
【００８３】
確認がステップ５４で成功すると、ステップ５５ではイシュア１３が、ユーザの金融データに従って、受信された許可要求に対する応答を作り上げる。この応答は、取引を受け入れるか、または拒否する取引結果コード、許可応答暗号などであり得る。
【００８４】
ステップ５６では、イシュア１３が応答をサーバ１２に送る。ステップ５７では、サーバ１２は取引の応答を受信する。ステップ５８では、サーバ１２は、応答から抽出された取引結果コードを業者１４に転送する。ステップ５９では、業者１４は取引許可結果を受信する。
【００８５】
本発明は実装が単純かつ容易であり、業者側に追加のハードウェアを必要としない。ＥＭＶ暗号を適用することにより、画像コードの不正流用による詐欺および盗用をなくすことができる。セキュア要素１５のモバイル決済アプリケーション１０の内部で取引上の予測不能な数字の組をバッファに入れておくことによって、ＥＭＶ取引のための双方向通信という要件が取り除かれる。
【００８６】
別の実施形態において、図３のステップ４６では、ＥＭＶ取引処理の終わりに、モバイル決済アプリケーション１０によって生成された応答メッセージが、ステップ４５で選ばれた取引上の予測不能な数字も含む。ステップ５２では、サーバ１２が、ユーザ識別子を応答メッセージから抽出する。この抽出されたユーザ識別子から、サーバ１２は、この取引に使用される取引上の予測不能な数字を、そのデータベースから所定の順序に従って回復する。サーバ１２は、回復された取引上の予測不能な数字を、使用しているものとしてそのデータベースにおいてマークする。サーバ１２は、応答メッセージ内の取引上の予測不能な数字を、そのデータベースから回復された取引上の予測不能な数字と比較する。この確認により、サーバ１２は、許可要求が、本物のモバイル決済アプリケーション１０および本物のセキュア要素１５からのものであるかどうかを識別することができる。取引上の予測不能な数字が成功裏に確認された場合、ステップ５２で、サーバ１２は、応答メッセージの取引暗号を含むＥＭＶ許可要求を作り上げ、ここには、回復された取引上の予測不能な数字が追加される。他方で、取引上の予測不能な数字の確認が失敗した場合、処理フローは閉じられてもよく、サーバは、モバイル決済アプリケーションに、取引上の予測不能な数字が改ざんされていることを通知することができる。
【００８７】
別の実施形態において、ステップ４６では、選ばれた取引のインデックスが応答メッセージに追加されてもよい。次いで、ステップ５２では、サーバ１２が、この取引に使用される取引上の予測不能な数字を、そのデータベースから、所定の順序を使用する代わりに応答メッセージに示されるインデックスによって回復することができる。
【００８８】
別の実施形態において、ステップ４５では、使用されていない取引上の予測不能な数字が、所定の順を使用する代わりにランダムに選ばれる。この場合、回復を容易にするために、インデックスが、前記選ばれた使用されていない取引上の予測不能な数字に関連付けられる。図３のステップ４６では、ＥＭＶ取引処理の終わりで、モバイル決済アプリケーション１０によって生成された応答メッセージは、関連するインデックスを含む。ステップ５２では、サーバ１２が、ユーザ識別子を応答メッセージから抽出する。この抽出されたユーザ識別子および関連するインデックスから、サーバ１２は、この取引に使用される取引上の予測不能な数字を、そのデータベースから回復する。ステップ５２では、サーバ１２が、応答メッセージの取引暗号を含むＥＭＶ許可要求を作り上げ、ここには、回復された取引上の予測不能な数字が追加される。
【００８９】
別の実施形態において、ステップ４５では、インデックスに関連付けられた使用されていない取引上の予測不能な数字がランダムに選ばれる。図３のステップ４６では、ＥＭＶ取引処理の終わりに、モバイル決済アプリケーション１０によって生成された応答メッセージが、取引上の予測不能な数字をそのインデックスとともに含む。ステップ５２では、サーバ１２が、ユーザ識別子を応答メッセージから抽出する。この抽出されたユーザ識別子および受信したインデックスから、サーバ１２は、この取引に使用される取引上の予測不能な数字を、そのデータベースから回復する。
【００９０】
サーバ１２は、応答メッセージ内の取引上の予測不能な数字を、そのデータベースから回復された取引上の予測不能な数字と比較する。取引上の予測不能な数字が成功裏に確認された場合、ステップ５２で、サーバ１２は、応答メッセージの取引暗号を含むＥＭＶ許可要求を作り上げ、ここには、回復された取引上の予測不能な数字が追加される。他方で、取引上の予測不能な数字の確認が失敗した場合、処理フローは閉じられてもよく、サーバは、モバイル決済アプリケーションに、取引上の予測不能な数字が改ざんされていることを通知することができる。
【００９１】
別の実施形態において、別の単信通信方法が、ユーザモバイルデバイス１１を介して取引の応答メッセージをモバイル決済アプリケーション１０から業者１４へ搬送するために、ステップ４８からステップ５０の画像コード符号化、表示、スキャンおよび復号の処理に取って代わることができる。単信通信方法は、ユーザモバイルデバイスによってサポートされる変調された音、変調された振動、ＮＦＣタグメッセージであり得る。
【００９２】
「取引」という表現は、その最も広い意味で解釈できる。すなわち、金銭上の取引には限定されず、本明細書において述べるように、サービスプロバイダのサービスにアクセスする任意の取引、単信通信によって生じる任意の取引も包含し得る。
【図１】
0006401278.tif 000002
【図２】
0006401278.tif 000003
【図３】
0006401278.tif 000004