JP6803935B2 - 不正および改ざんに対するデバイスの論理的妥当性確認 - Google Patents
不正および改ざんに対するデバイスの論理的妥当性確認 Download PDFInfo
- Publication number
- JP6803935B2 JP6803935B2 JP2018567857A JP2018567857A JP6803935B2 JP 6803935 B2 JP6803935 B2 JP 6803935B2 JP 2018567857 A JP2018567857 A JP 2018567857A JP 2018567857 A JP2018567857 A JP 2018567857A JP 6803935 B2 JP6803935 B2 JP 6803935B2
- Authority
- JP
- Japan
- Prior art keywords
- payment
- terminal
- payment terminal
- ticket
- proof
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000010200 validation analysis Methods 0.000 title description 47
- 238000012545 processing Methods 0.000 claims description 286
- 238000001514 detection method Methods 0.000 claims description 188
- 238000012544 monitoring process Methods 0.000 claims description 176
- 238000000034 method Methods 0.000 claims description 170
- 238000012360 testing method Methods 0.000 claims description 169
- 230000006854 communication Effects 0.000 claims description 151
- 238000004891 communication Methods 0.000 claims description 145
- 230000004044 response Effects 0.000 claims description 75
- 230000009471 action Effects 0.000 claims description 50
- 230000007613 environmental effect Effects 0.000 claims description 20
- 238000003780 insertion Methods 0.000 claims description 16
- 230000037431 insertion Effects 0.000 claims description 16
- 238000012546 transfer Methods 0.000 claims description 10
- 230000000737 periodic effect Effects 0.000 claims description 8
- 238000003672 processing method Methods 0.000 claims 1
- 230000008569 process Effects 0.000 description 69
- 230000015654 memory Effects 0.000 description 47
- 230000006870 function Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 16
- 230000006399 behavior Effects 0.000 description 14
- 238000004458 analytical method Methods 0.000 description 13
- 238000005516 engineering process Methods 0.000 description 13
- 230000003993 interaction Effects 0.000 description 11
- 230000000670 limiting effect Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 9
- 238000005259 measurement Methods 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 8
- 238000013475 authorization Methods 0.000 description 7
- 230000001960 triggered effect Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000002452 interceptive effect Effects 0.000 description 6
- 230000002085 persistent effect Effects 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 4
- 238000011156 evaluation Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000002441 reversible effect Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 238000011022 operating instruction Methods 0.000 description 3
- HRANPRDGABOKNQ-ORGXEYTDSA-N (1r,3r,3as,3br,7ar,8as,8bs,8cs,10as)-1-acetyl-5-chloro-3-hydroxy-8b,10a-dimethyl-7-oxo-1,2,3,3a,3b,7,7a,8,8a,8b,8c,9,10,10a-tetradecahydrocyclopenta[a]cyclopropa[g]phenanthren-1-yl acetate Chemical compound C1=C(Cl)C2=CC(=O)[C@@H]3C[C@@H]3[C@]2(C)[C@@H]2[C@@H]1[C@@H]1[C@H](O)C[C@@](C(C)=O)(OC(=O)C)[C@@]1(C)CC2 HRANPRDGABOKNQ-ORGXEYTDSA-N 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 230000002547 anomalous effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000013480 data collection Methods 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000002349 favourable effect Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000001939 inductive effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 238000001228 spectrum Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000003936 working memory Effects 0.000 description 2
- 241000819999 Nymphes Species 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 206010000210 abortion Diseases 0.000 description 1
- 239000012190 activator Substances 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 230000004071 biological effect Effects 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000003066 decision tree Methods 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000005672 electromagnetic field Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 210000003811 finger Anatomy 0.000 description 1
- 230000001976 improved effect Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 210000001525 retina Anatomy 0.000 description 1
- 238000010079 rubber tapping Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000003595 spectral effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000000528 statistical test Methods 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/045—Payment circuits using payment protocols involving tickets
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/206—Point-of-sale [POS] network systems comprising security or operator identification provisions, e.g. password entry
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4093—Monitoring of device authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
- H04W12/122—Counter-measures against attacks; Protection against rogue devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/126—Anti-theft arrangements, e.g. protection against subscriber identity module [SIM] cloning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/128—Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Cash Registers Or Receiving Machines (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Mobile Radio Communication Systems (AREA)
- Traffic Control Systems (AREA)
- Lock And Its Accessories (AREA)
Description
関連出願の相互参照
本出願は２０１６年６月３０日に出願の「ＬＯＧＩＣＡＬ ＶＡＬＩＤＡＴＩＯＮ ＯＦ ＤＥＶＩＣＥＳ ＡＧＡＩＮＳＴ ＦＲＡＵＤ ＡＮＤ ＴＡＭＰＥＲＩＮＧ」と題する米国特許出願第１５／１９９,９１７号、および２０１６年６月３０日に出願の「ＬＯＧＩＣＡＬ ＶＡＬＩＤＡＴＩＯＮ ＯＦ ＤＥＶＩＣＥＳ ＡＧＡＩＮＳＴ ＦＲＡＵＤ ＡＮＤ ＴＡＭＰＥＲＩＮＧ」と題する米国仮特許出願第１５／１９９,９３３号に優先権を主張し、それらの全内容を本願明細書に援用する。
本出願は２０１６年６月３０日に出願の「ＬＯＧＩＣＡＬ ＶＡＬＩＤＡＴＩＯＮ ＯＦ ＤＥＶＩＣＥＳ ＡＧＡＩＮＳＴ ＦＲＡＵＤ ＡＮＤ ＴＡＭＰＥＲＩＮＧ」と題する米国特許出願第１５／１９９,９１７号、および２０１６年６月３０日に出願の「ＬＯＧＩＣＡＬ ＶＡＬＩＤＡＴＩＯＮ ＯＦ ＤＥＶＩＣＥＳ ＡＧＡＩＮＳＴ ＦＲＡＵＤ ＡＮＤ ＴＡＭＰＥＲＩＮＧ」と題する米国仮特許出願第１５／１９９,９３３号に優先権を主張し、それらの全内容を本願明細書に援用する。
電子支払は、様々な方法で実行することができる。支払端末は、支払トランザクションを処理することができて、支払端末の磁気読取機において読み取られる磁気ストリップを有する支払カード、支払端末の対応するＥＭＶスロットに入れられるＥｕｒｏｐａｙ／Ｍａｓｔｅｒｃａｒｄ／Ｖｉｓａ（ＥＭＶ）チップを有する支払デバイスおよび近接場通信（ＮＦＣ）対応デバイス、例えば支払端末でタップされて安全な無線接続上で支払情報を送信するスマートフォンまたはＥＭＶカードなどの、支払デバイスと対話することができる。支払端末は、支払デバイスからのトランザクションに関する情報ならびに支払情報を受け取ることができ、トランザクションの処理のための支払システムにこの情報を通信することができる。
取引処理システムのその中心的役割の結果として、支払端末は、第三者攻撃者が、支払情報にアクセスしたり、不正なトランザクションを処理したり、また不正行為または窃盗に関与することを試みる主要な目標となっている。多くの場合に、攻撃者は、データを搬送している１つ以上の通信回線、または支払情報を通信して処理するプロセッサなどの、支払端末のコンポーネントに物理的にアクセスすることを試みる。
攻撃者は、悪意のある信号を注入することによって、信号を盗聴する（例えば、受動型攻撃）かまたは、支払端末に支払トランザクション通信を変更するかまたはなりすますこと（例えば、能動型攻撃）を試みることができる。支払端末は、不正なトランザクションおよび改ざんの試みを識別することを試みることができる。しかしながら、攻撃者がより巧妙になるにつれて、改ざんスイッチまたは改ざんメッシュなどの手段は回避することができ、または、攻撃が支払端末のいかなるコンポーネントにも物理アクセスを得ずに実行されることもできる。例えば、攻撃者の中には、偽造であるか変更された支払カード（例えば、ＥＭＶカード）を作製することができるか、または支払端末と支払デバイスの間で伝送信号を傍聴するか、転送するかもしくは、変更する改ざんデバイスを構築することができるものもある。さらに、支払端末は発生している他の支払トランザクションに関する情報が、したがって、不正なトランザクションに関与するかまたは支払対象リーダを改ざんする試みの情報が欠如していることがあり得る。
発明を実施するための形態は、添付の図面を参照して説明する。図面において、参照番号の左端の数字（複数可）は、参照番号が最初に現れる図面を特定している。異なる図面において同一の参照番号を使用する場合は、類似しているかまたは同一の項目か特徴であることを示す。さらに、同じ部分の複数の例は、ダッシュによって例番号から切り離されている共通の接頭部によって示される。図面は一定の比率ではない。
本明細書において記載されている一部の実装は、支払サービスが支払端末などの支払デバイスを証明することを可能にし、それから支払デバイスと支払オブジェクトリーダなどの別のデバイスの間のセッションを妥当性確認する、方法およびシステム含む。証明および妥当性確認は、デバイスが財務情報の交換などのすべての通信に対して安全であると判定されることを共に示す。
一般に、商用アプリケーションのために使われるコンピュータプラットフォームは、通常それらの挙動がローカルまたは遠隔のエンティティによる修正に脆弱である環境において作動する。例えば、１つの当事者に属する販売時点（ＰＯＳ）端末は、ＰＯＳ端末にインストールされる第三者に属しているモバイルアプリケーションによって第２の当事者からデータを受け取っていてもよい。一例を挙げると、支払トランザクションは、買い手が小売業者から購入する製品またはサービスに対する支払をするためのクレジットカードまたはデビットカードなどの支払カードを提示している買い手に関係する。クレジットカードはカードリーダに読み取られるかまたは入れられ、それは支払アプリケーションを実行している販売時点（ＰＯＳ）端末に接続しているかまたは中に含まれて、小売業者が、利用できる項目を示し、注文を受け、買い手等から電子署名を取得することなどができる。ＰＯＳ端末は、読み取り動作に応答して、かつ、クレジットカードから集められるデータに基づいて、支払要求を生成する。ＰＯＳ端末は、認可のために、利用できるネットワークの上の支払カードプロセッサに支払要求を電子的に送信する。
多くの別々のアプリケーションおよびプロセスがコンピュータプラットフォーム上で同時に動作している場合に、アプリケーションは必ずしも互いから分離されているか保護されているというわけではない。最新のオペレーティングシステムでは関係するソフトウェアコンポーネントに対するソースコード量が通常は非常に多いので、実質的にソースコードの正当性および、ソースコードの動作が予想通りにふるまうかどうかを確かめることは不可能である。支払カードは機密財務情報を有しており、顧客はＰＯＳ端末またはカードリーダ上のセキュリティ機構に関与していないので、ＰＯＳ端末、支払アプリケーションおよびカードリーダ（集合的に支払エンティティと呼ばれる）の機能が不正操作されておらず、変更されておらず、かつ安全であって、支払トランザクションの処理の間にも後にもその状態であることが、非常に重要である。
少なくとも前述の問題を軽減するために、本明細書の実施形態は、支払エンティティおよびモバイル支払アプリケーションをサポートする支払エンティティまたは支払プラットフォームが、後述するように、改ざん検出または証明または両方ともによって安全と考えられる、方法および装置を開示する。実施形態は、概して、サーバによって開始される１つ以上の信頼コマンドに基づいて支払エンティティの計算プラットフォームへの拡張改ざんおよび詐欺検出システム方法論（すなわち、信頼ルーチン）の組入れを提供する。信頼コマンドは、支払プラットフォームの母集団にわたって収集された確実に測定されたデータもしくはテスト基準、またはセキュリティエキスパートによって決定される事前設定値に基づいて、ソフトウェアコードの一部をハッシングすること、支払エンティティのメモリをスキャンすること、ソフトウェアコードのジェイルブレーキングについて検査すること、マウント済みファイルシステムのメタデータをギャザリングすることなどを含むがこれに限らず様々なレベルの特定性および粒状度を含む。信頼ルーチンの組入れの後、支払処理システム（ＰＰＳ）は、支払プラットフォームを所定の期間の間信頼されるものとして割り当てて、すべての今後のインタラクションに証明チケットを割り当てる。期間が経過すると、証明ルーチンは、再初期化されて、支払プラットフォームを２回目に証明するために再実行することができる。
このような証明および信頼されたデバイスとして支払プラットフォームにタグを付けることの機能は、デバイス、アプリケーションおよび関連ソフトウェア操作環境を含んで、支払プラットフォームの完全性測定基準を提供する確実に測定されたデータにプラットフォームのアイデンティティを結合することである。アイデンティティおよび完全性測定基準は、プラットフォームの信頼性を保証する用意ができている信頼できる機関（ＴＰ）により提供される期待値と比較されてもよい。任意選択的に、信頼できる第三者機関により提供される期待値は、それぞれの物理的な信頼されたデバイスおよびＰＰＳに確実に格納される。一致がある場合、その意味するところは、プラットフォームおよび操作システムの少なくとも一部が、完全性測定基準の範囲に応じて正しく作動しているということである。加えて、ＰＰＳは、証明チケットを生成して、今後のトランザクションのために、または、不正イベントが支払プラットフォームの信頼性を脅かすまで、プラットフォームに割り付ける。その時、ＰＰＳはそれがプラットフォームを再証明するまで、支払プラットフォームのすべての処理および機能性を停止させる。
支払エンティティ上の支払トランザクションの場合、ＰＰＳは、プラットフォームとのデータ交換の前に、証明チケットの状態を通して、プラットフォームおよび操作環境の正しい動作を検証する。ＰＰＳは、物理的な信頼されたプラットフォームおよび仮想てきな信頼されたデバイスのアイデンティティおよび完全性測定基準を要求することによってこれを行う。（任意選択的に、信頼されたデバイスは、それ自体がプラットフォームの正しい動作を検証することができない場合、アイデンティティの証拠を提供することを拒否する。）ＰＰＳは、アイデンティティおよびアイデンティティ測定基準の証明を受信して、信頼できる第三者機関により提供される値に対してそれらを比較する。信頼されたデバイスによって報告される測定したデータが信頼できる第三者機関により提供されるものと同じである場合、ＰＰＳはプラットフォームを信頼することができる。
さらに、チケットはリーダとＰＯＳ端末の間にあらゆるインタラクションに対してＰＯＳ端末に保存されて、すべてのトランザクションはセッションが安全であるということを証明するために証明チケットが添付される。
加えて、コンピュータプラットフォームが複数の別々の小売業者アカウントをサポートするように調整される場合（例えば、ＰＰＳと関連したいくつかのアプリケーション、ピアツーピア送金サービスおよびトランザクション処理アプリケーション、があってもよい）では、１つのアプリケーションの動作環境などのそれら自身の証明チケットを有する各アカウントは、同じコンピュータプラットフォーム上で実行されている他のいかなる動作環境からも分離される。
一旦ＰＰＳがプラットフォームの信頼された動作および操作環境を確立すると、プラットフォームのユーザは機密財務データを含むデータを他の態様のプラットフォームおよびＰＰＳと交換することが可能である。ローカルシステムに対しては、有効な（すなわち期限切れでない）証明チケットを伴う交換は、プラットフォーム上の操作環境内で実行されるいくつかのソフトウェアアプリケーションと対話することによるものでもある可能性がある。ＰＰＳなどのリモートシステムに対しては、有効な証明チケットを伴う交換は、安全なトランザクションの完了を含む可能性がある。いずれの場合も、交換されるデータは、通常は信頼されたデバイスまたはプラットフォームのうち１つによって「署名」される。ＰＰＳはそれで、挙動を信頼することができるプラットフォームとデータが交換されているというより大きな確信を得ることができる。証明チケットは、プラットフォームを信頼することができる時間を示すこともできる。
一実装では、信頼されたプラットフォームは、暗号プロセスを使用するが、必ずしも外部インターフェースをそれらの暗号プロセスに提供するというわけではない。第１の実施形態では、ＰＰＳがコンピュータプラットフォーム上で動作している危険なソフトウェアによってソフトウェア攻撃に影響されやすいというリスクが最小限であることを確実にするために、ＰＰＳは、コンピュータプラットフォーム上で実行されている他のソフトウェアアプリケーションへのアクセスを制限するプロセッサ特権レベルにおいて実行されるように調整される（後述するように）。加えて、ＰＰＳ内の非常に機密性のあるデータは、ＰＰＳが実行されるレベルより低いプロセッサ特権レベルにおいて実行されているソフトウェアアプリケーションにとってデータがアクセスできないように、格納される。また、最も望ましい実装は、支払プラットフォームを不正操作がきかなくして、それらを他のプラットフォーム機能にとってアクセスできなくすることによってデータを保護して、無許可の修正に実質的に影響を受けない環境を提供することである改ざん防止は不可能であるので、それに最も近いのは、改ざん耐性があるか改ざん検出ができる信頼されたデバイスである。信頼されたデバイスは、したが改ざん耐性のある１つの物理的なコンポーネントから成るのが好ましい。改ざん耐性に関連する技術はセキュリティの当業者によく知られている。これらの技術は、改ざんに抵抗する方法（例えば信頼されたデバイスの適切なカプセル化）、改ざんを検出する方法（例えば信頼された装置ケーシングの仕様逸脱電圧、Ｘ線または物理完全性の喪失の検出）および、改ざんが検出されるとデータを除去する方法を含む。
前述のように、ＰＰＳは、ＰＰＳからコマンドを受信すると、プラットフォームが信頼され得るかどうかを判定して、プラットフォームのための証明チケットを可能であれば生成することができるかどうか決定するための、信頼コマンドを有する証明ルーチンを生成する。信頼コマンドは、ＰＰＳ内の改ざん／不正検出コンポーネントおよび、改ざん／不正報告コンポーネントなどの支払プラットフォーム内のコンパニオンコンポーネントなどの、モニタリングコンポーネントを起動させるが、それらは、種々のタイプの支払デバイスと対話してソフトウェアコンポーネントの動作をテストする支払インターフェースなどの支払アプリケーション、ＰＯＳ端末、支払オブジェクトリーダの各種コンポーネントの電気的特性を測定する。これらのモニタリングコンポーネントを用いて、プラットフォームは、電流、電圧、インピーダンスおよび容量などの値をモニタして、コンポーネントが異常な方法で動作しているかどうかを判定することが可能である。モニタリングコンポーネントは、テスト要求を例えば、ＥＭＶカードとのインターフェースの入出力ライン上に送信することもできる。それから、モニタリングコンポーネントはテスト信号の電気的特性を測定することができ、それは入出力ライン上の偽造カードまたは改ざんデバイスを示すことができる。モニタリングコンポーネントは、支払プラットフォームが予想される方法で応答するかどうかテストするために、テスト要求メッセージを送信することもできる。
モニタリングコンポーネントは、支払プラットフォームの母集団にわたって収集された確実に測定されたデータもしくはテスト基準との比較に基づいて、モニタされた電気的特性および不正なトランザクションまたは改ざんの試みが起こっているか最近起こったかどうかを判定する支払プラットフォームからの応答などの情報を利用することができる。いくつかの場合では、そして、不正なトランザクションまたは改ざんの試みのタイプに応じて、ＰＰＳは、支払トランザクションを中止するか、支払オブジェクトリーダのコンポーネントを一時的に無効にするか、またはＰＰＳのコンポーネントを永久に無効にするなどの修正処置をすることができる。
いくつかの場合では、このような動作は、リーダまたは支払いアプリケーションによって実行することができる。そのような場合、支払オブジェクトリーダは、支払処理システムと（例えば、小売業者デバイスおよび通信ネットワークを通して）通信することもできる。支払処理システムに支払トランザクション情報を送信することに加えて、支払オブジェクトリーダは、モニタされた電気的特性および応答メッセージを支払処理システムに送信することもできる。支払処理システムは、この情報を利用して、完全性測定基準との比較に基づいて、不正なトランザクションまたは改ざんの試みが発生したかどうか判定することができる。支払処理システムは、この情報をトランザクションデータベースに格納することもできる。トランザクションデータベースの情報を用いて、不正なトランザクションまたは改ざんの試みが、例えば、類似の以前のトランザクションに基づいて起こったかどうか判定することもできる。
支払処理システムは、このプラットフォームおよび他のプラットフォームの今後のトランザクションおよび証明のために支払オブジェクトリーダおよび支払処理システムの両方により用いられるテスト基準を更新することもできる。不正なトランザクションおよび改ざんの試みに関するさらなる情報がトランザクションデータベースで集められるにつれて、この情報を用いて新しいテスト基準を生成することができる。加えて、支払処理システムは、他のシステムから、支払トランザクションが不適切に拒まれた（フォールスポジティブ）かまたは不適切に受け入れられた（フォールスネガティブ）かどうかなどの、フィードバックを受信することができる。この情報を用いて、テスト基準を更新することもできる。支払プラットフォームに対する更新されたテスト基準は、更新されたテスト基準に基づいてそのローカルテスト基準を更新することができるモニタリングコンポーネントに発信され得る。一部の実装において、証明は周期的に、またはランダムな時間間隔で発生し、証明チケットはそれが期限切れになるまで有効である。一部の実装において、証明トリガーが発生すると、証明チケットの妥当性は無効にすることができ、すおよび／または再生成ることができる。照明トリガーの例としては、限定するものではないが、ＰＯＳ端末に新規なリーダをペアリングすること、未知のデバイスに支払アプリケーションをインストールすること、リーダまたはＰＯＳ端末の新しい、例えば、不正なことが公知の位置への再配置を検出すること、不正なユーザからのカードの挿入を検出すること、不正なカードを検出すること、確立したジオフェンスの中で、不正なデバイスの入力を検出することなどが含まれる。このように、証明チケットは、プラットフォームだけでなく環境、例えば小売業者ストアがある位置、顧客または支払オブジェクトまたはジオフェンスに入る支払デバイス（例えばＡｐｐｌｅ Ｗａｔｃｈ（登録商標））も証明することができる。
一部の実装において、ＰＰＳは、フェイルオーバー技術の範囲内で実装される。第１のコンポーネントは、支払端末と対話するための公開のエンドポイントを提供して、チケット要求を受信し、デバイスが問題無く支払プラットフォームによってスキャンされたということを証明するチケットを作製して、妥当性確認する。しかしながら、改ざん検出および他の種類のセキュリティ分析のためのスキャンを評価する作業は、別のコンポーネントに送られる。第２のコンポーネントが失敗する場合、これもクライアントに対応する第１のコンポーネントは、第２のコンポーネントがすべてのデバイスを承認していると偽ることによって「ファイルオープン」することができる。これは、セキュリティが無効にされるいくらかの期間があり得ることを意味するが、しかしながら、これらの期間は、はっきり分かるものであり、攻撃者のコントロールまたは視野の下にはない。さらに、「ダウン時間」の間に、第２のコンポーネントが戻ってくると、要求はバッチ処理されることができて、見直しされ得る。
上述の通り、開示された技術は、プラットフォームが初めてスキャンされるときかスキャンされる毎に、証明チケットオブジェクトの生成を有効にし、それは支払プラットフォームがスキャンされたスキャンの結果は認証されて暗号化された形であることを示して、存在すれば支払プラットフォームの動作を妨げるセキュリティ脅威が検出されなかったことをさらに示す。さらに、証明チケットは、スキャンが実行されたタイムスタンプおよび、失効日または有効期間（例えば１５分）をそれと関連させている。支払デバイス、支払端末、支払アプリケーションおよび他の任意の第三者のシステムなどのプラットフォームへのこのようなチケットの、いかなる条件の有無にもかかわらない定義済みであるか未定義期間に対する割り当ては、トランザクションが処理されるなどのイベントが発生するたびのセキュリティーチェックを必要とせずに、支払プラットフォームの無制限の動作を許容する。そのため、支払プラットフォームは、動作を実行する時はいつでも、ＰＰＳに証明チケットを送信して、それが信頼されて、安全であるということを証明する。それから、ＰＰＳは、不正および改ざん検出コンポーネントに存在する論理に基づいて、動作を許容するかまたは拒否し、またそうでなければアクセスができるようにする。支払プラットフォームはＰＰＳと対話するすべての時に証明チケットを生成する必要がないので、それはスキャンと関係しているどのような遅延も無しに、トランザクションを許すべきか否かなどの、迅速で同期した判断を可能にする。
一部の実装において、証明チケットはスキャンがプラットフォームに関する問題を示すかどうかに関係なく生成されるが、問題を示している情報を含む。ＰＰＳはチケットを解析すると、それはセッションが安全ではないことを判定して、それからトランザクションを拒否する。これは、サードパーティアプリケーションなどの支払プラットフォームの不正ユーザが証明チケットを保存して、より早期に不正であると判定された他のプラットフォームに対して使用する方法を発見する場合、役立つ。チケットは、信頼されて許可されたデバイスまたはプラットフォームに関連した情報を含むことができ、それにより、どのようなコピー動作でも、チケットを破壊するかまたはチケットを他のいかなるデバイスまたは目的のためにも使用不可能であるようにする。以前に暗示したように、証明チケットは、チケットが特定のデバイス、ソフトウェアのバージョンに対して、または、オンライン／オフラインモードにおいてなどしか用いられることができない、ということを示す条件と関連付けることができる。
ＥＭＶプロトコルのような特定のプロトコル上で動作している特定のリーダは、証明チケットを組み込んで、例えば、ハードウェアＰＩＮの代わりにソフトウェアＰＩＮ機能の実装を可能にする。ＰＰＳはリーダと端末の両方の安全なセッション妥当性確認を実行することができ、それは実装するのが容易であり、チケットがクライアント装置を通さないので、リバースエンジニアリングするのが不可能で、フェイルオーバー実装を有しており、各種の小売業者をサポートする。ＰＰＳは、例えば過酷な影響を与えずに短時間の間実行を止めるかデグレードさせることによって、改ざん検出および修復を実行することもできる。一部の実装において、証明プロセスは改ざん検出とは分けられており、分離された別のコンポーネントによって実行される。
開示された方法および装置の利点は、偶然の攻撃、明らかな非難読化保護を防止し、偶然の攻撃への防衛が意図的に回避されてかつ非難読化保護を回避／無効化することが強い信号である場合を検出し、攻撃発見および最初の利用を妨げ、改ざん耐性、改ざん検出、改ざん応答および改ざん証拠のためのソフトウェア反改ざん技術を実装し、展開された攻撃を振り払って開発費を上げるダイナミズムに適応し、複数の「等価な」不明瞭な検出の保存を回転させ、攻撃などに反応するのを助ける。一部の実装の他の利点は安全なセッションを確立するプロセスから証明のプロセスを分離すること含み、それによってシステムは、費用のかかる土壇場での計算を回避することができる。また、異なるサービスレベル契約（ＳＬＡ）によるプロセスを分割することによって、フェイルオーバーシステムは、低位のＳＬＡプロセス（例えば、改ざん検出）に対して高位のＳＬＡプロセス（例えば、証明チケットの生成）に優先順位をつけるために確立することができる。
本明細書において記載されている実施形態が、セルフチェックアウト端末を含むＰＯＳ端末を用いる実店舗型小売店に関することができる一方で、実施形態は、小売業者ウェブサイトまたはアプリケーションを介したオンラインショッピングを含むあらゆる電子商取引場所でのショッピングまで広げることができることが理解されよう。
開示される改ざんおよび詐欺検出システム技術の種々の実施形態および実装をここで説明する。以下の説明は、これらの実装の完全な理解および効果的な説明のための具体的な詳細を提供する。しかしながら、当業者は、これらの詳細の多くが無くても開示されるシステムおよび方法が実施され得ると理解するであろう。加えて、いくつかの周知の構造または機能は、種々の実装の関連した説明を不必要にあいまいにすることを回避するために、示されていないか詳述しない場合もある。以下に示す説明において使われる用語は、それが開示されるシステムおよび方法の特定の具体的な実装の詳細な説明と連動して用いられている場合であっても、その最も幅広い合理的な方法で解釈されることを意図する。次に、いくつかの頻繁に使われる用語を説明する。
本明細書において使用する場合、小売業者は、買い手による獲得のための商品またはサービスの提供に携わっているいかなる事業も含むことができる。小売業者に起因している動きは小売業者の所有者、従業員または他の代理人によって実行される動作を含み得るので、特に述べられない限り、本明細書においては区別されない。加えて、本明細書において使用する場合、買い手は、小売業者から商品またはサービスを、例えば購入、賃貸、リース、借用、ライセンシングなどによって得るいかなるエンティティも含むことができる。以下、小売業者によって提供される商品および／またはサービスは、項目と呼んでもよい。したがって、小売業者および買い手は、買い手が小売業者から項目を得るトランザクションを行うために互いに対話することができて、代わりに、買い手は支払を小売業者に提供する（例えばバイオメトリック支払手段を通して）。
本明細書において使用する場合、『支払トランザクション』または単に『トランザクション』は、買い手と小売業者の間に行われる商品および／またはサービスの獲得のための金融トランザクションを含むことができる。例えば、トランザクションの支払を行うときに、買い手は支払プロキシを用いて小売業者による額を提示することができる。他の場合には、支払トランザクションは、多くの理由に対してある当事者からもう一方の関係者への送金を含む。したがって、記述が買い手および小売業者を支払トランザクションの関係者と称する一方で、当事者が、送り主および受取人、地主および貸借人、銀行と銀行顧客、第１の友人および第２の友人などであり得ることが理解されよう。
『支払カード』または『支払オブジェクト』という用語は、従来のデビットカード、従来のクレジットカード、前払いのギフトカード等、埋め込み集積回路チップを備えるスマートカード（例えば、Ｅｕｒｏｐａｙ−ＭａｓｔｅｒＣａｒｄ−ｖｉｓａ（ＥＭＶ）カード）、プロキシカードまたはこれらの機構のいずれかの組合せとして機能するいかなるカードも含む支払機構を指す。『プロキシカード』という本明細書で用いられる用語は、本当のクレジットまたはデビットカードアカウントのもののように見えるが、しかし、そのカード／アカウント番号が実際には買い手の本当のカード／アカウント番号のためのプロキシだけである、カード番号またはアカウント番号（すなわち、それは、正しいフォーマットである）がついているかまたはついていなくてもよいカードを指す。加えて、上記の例で用いられる支払カードは、金融手段の特定のタイプである。支払カード以外の他のタイプの金融手段は、資金の送金を開始するために用いることができる。金融手段は、ソフトウェア手段またはバーチャルウォレットなどの仮想手段であることができる。支払カードの他の例は、プリペイドカード、ギフトカード、懸賞金カード、ロイヤルティポイントのカード、マイレージサービスカード、小切手、現金または金銭的価値を保持するかまたは後で支払うという約束を提供する他のいかなる種類の支払手段も含むこともできる。支払カードは、支払オブジェクト、例えば非接触の支払トランザクションを開始するように構成される電子デバイス、例えば、キーフォブ、モバイル機器（ＮＦＣタグを有するモバイル機器など）を含むこともできる。そして最後に、支払オブジェクトは、一連の英数字かまたは一般的には、買い手または小売業者の金融口座を表す任意の識別子が後に続く金融インジケータの構文を有する支払プロキシであることもできる。支払プロキシは、ウェブアドレス、ソーシャルネットワーキングハンドル名またはユーザ名、フォーラム、メッセージングアプリケーションなどの一部として、ウェブページの前後関係およびその範囲内において用いることができる。
「バイオメトリック支払手段」という用語は、生体的に識別可能で、生体的特性、例えば人の指（例えば、指紋認識のため）、顔、虹彩または網膜、鼓動、声などによって初期化される一種の支払オブジェクトまたは金融手段である
支払オブジェクトリーダは、いかなる支払オブジェクトからもデータを検出して取得するように構成される、磁気ストライプカードリーダ、光学式スキャナ、スマートカード（埋め込みＩＣチップを有するカード）リーダ（例えば、ＥＭＶ対応カードリーダまたはＮＦＣ使用可能リーダ）、無線周波数識別（ＲＦＩＤ）リーダなどでもよい。したがって、支払オブジェクトリーダは、支払オブジェクトの検出および受入れを容易にする１つ以上のセンサまたは電気的接触を有するスロット、磁気トラックおよびレールなどのハードウェア実装を含むことができる。加えて、または、任意選択的に、支払オブジェクトリーダは、このような生体的特性が支払処理システムによって登録されて、金融口座に接続していると想定すれば、生体的特性を受信して、処理して、支払手段としてそれらを処理するためにバイオメトリックセンサを含むこともできる。
１つの実施例において、ＰＯＳ端末は、小売業者に関連した携帯電話、ラップトップ、タブレット型コンピュータなどのような携帯用デバイスであることができる。別の実施例では、ＰＯＳ端末は着用できられるかまたは買い手に接続しているかまたは関連するモバイル機器である、または、小売業者（例えば、コンピューティング装置）はＡｐｐｌｅ Ｗａｔｃｈ（登録商標）またはＦｉｔＢｉｔ（登録商標）でもよい。
用語「安全を証明する」または「デバイスの証明」は、ハードウェアまたはソフトウェアがそのオリジナルあるいは工場構成から修正されたかどうか判定する方法を意味することを意図している。例えば、システムは、ソフトウェアの無許可の変更を、それらのソフトウェアを改ざんして技術的保護手段を迂回するユーザを含んで、識別することができる。それは、どのようなソフトウェアが現在動作しているかについて示している証明書をハードウェアに生成させることによって機能する。それから、コンピュータは、変更されていないソフトウェアが現在実行されていることを示すために、この証明書を遠隔の当事者に提示することができる。
本明細書で用いる場合、「ペアリングする」または「関連付ける」ことは、ＰＯＳ端末および支払オブジェクトリーダが無線通信プロトコル、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（登録商標）、Ｗｉ−Ｆｉ（登録商標）などを使用して互いに通信チャネルを確立するプロセスを指す。ＰＯＳ端末および前記支払オブジェクトリーダは、いったん「ペアリング」されるとそれらの間でデータを送信できるトランシーバを各々含む。本明細書において記載されているペアリング技術は、リアルタイムおよびオフラインモードでＰＯＳ端末に支払オブジェクトリーダをペアリングすることができる。さらに、ＢｌｕｅｔｏｏｔｈまたはＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙが特定の実施形態を記載するために用いられているが、ＮＦＣ、Ｗｉ−Ｆｉなどの他の無線プロトコルも用いることができる。
本明細書で用いる場合、「ランディングページ」という用語は、個人化された位置アドレスと関連した受取人に代わって支払を徴収するために専用である個人化された位置アドレスによって識別される仮想位置を指す。個人化された位置アドレスは、上記の支払プロキシを含むことができる。一部の実施形態において、ランディングページは支払プロキシを含むユニフォームリソースロケータ（ＵＲＬ）によって識別されて、ここで、ＵＲＬは送信者のクライアント装置にインストールされたウェブブラウザアプリケーションを通してアクセス可能である。
本明細書で用いる場合、「登録アプリケーション」または「モバイル支払ポータル」という用語は、有線であるか無線の通信ネットワーク上のユーザ（例えば、メッセージの送信者および受信者）の間の通信を可能にするあらゆるメッセージングアプリケーションを指す。通信サービス（例えば、チャット機能）をユーザに提供するサービス提供者は、メッセージングアプリケーションを使用することができる。メッセージングアプリケーションは、例えば、電話（例えば、従来の形態電話またはスマートフォン）の間の通信のためのテキストメッセージングアプリケーションまたは通信のためにインターネットを使用するスマートフォンおよび電話用のクロスプラットフォームのインスタントメッセージングアプリケーションを含むことができる。メッセージングコンテクストの中で、ユーザは、ユーザがメッセージングアプリケーションの中で入力する、例えば、メッセージのＴＯフィールドの支払プロキシを特定することによって送金する意図を示すことができる。例えば、ユーザは、ＴＯフィールドに「＄ｒｅｄｃｒｏｓｓ」を入力する。別の例では、ユーザは、ＴＯフィールドに「＄ａａｒｏｎ」を入力する。いったんユーザが支払プロキシを入力するか、またはＴＯフィールドに入力をすると、ユーザはメッセージ本文に、例えば、「ここに１０ドルあります」というメッセージを入力することができて、メッセージを送ることができる。種々の実施形態において、メッセージは、テキストメッセージ、チャットメッセージ、ｅメールメッセージまたは実際コンピューティング装置の間で交換されることができる他のタイプのいかなるメッセージでもあることができる。本仕様では例としてテキストメッセージを使用することができるが、支払プロキシ技術がこの種のメッセージのいずれをも使用することができることを理解すべきである。送信する指示を受け取ると（例えば、ユーザが「送信する」をクリックしたのを検出した後に）即座に、メッセージングアプリケーションは、メッセージ、例えば、メッセージングアプリケーションコンピュータシステム（「メッセージングアプリケーションシステム」）に対するテキストメッセージを送信する。メッセージングアプリケーションシステムは、それが受信したメッセージのＴＯフィールドへの入力が１つ以上の英数字の前に金融インジケータの構文を含むことを検出する。それに応じて、メッセージングアプリケーションシステムは、処理のための支払処理システムに、テキストメッセージを転送する。支払処理システムは、ＴＯフィールドから引き出された入力（または支払プロキシ）と関連した受取人を識別して、さらにその受取人と関連した受取人金融口座を識別する。受取人金融口座の識別に応じて、支払処理システムは、送金を開始する。
「通信ネットワーク」という用語は、公知技術の任意のタイプのネットワーク、例えばローカルエリアネットワークまたはインターネットのような広域ネットワークでもよく、携帯電話ネットワークなどの無線ネットワーク、クラウドネットワーク、例えばＷｉ−Ｆｉおよび／またはＢｌｕｅｔｏｏｔｈおよびＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙなどの近距離無線通信のようなローカル無線ネットワーク、近接場通信（ＮＦＣ）、有線ネットワークもしくはあらゆるそのようなネットワーク、またはそれらの任意の組合せを含むことができる。したがって、ネットワークは有線および／または無線通信技術を含むことができ、そこに含まれるものには、Ｂｌｕｅｔｏｏｔｈ、Ｂｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ、Ｗｉ−Ｆｉおよび、ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ（Ｗｉ−ＭＡＸ）、３Ｇ、４Ｇ、ＣＤＭＡ、デジタル加入者線（ＤＳＬ）などのようなセルラ通信技術、クラウドコンピューティング技術、ならびに有線または光ファイバ技術がある。加えて、または、代替的に、通信ネットワークは、メッシュネットワークでもよい。例えば、無線ローカルエリアネットワーク（ＷＬＡＮ）で、ネットワーク装置は通信を受信して転送するように構成することができ、それは最終的に異なるデバイスに向かうことになる。この種のネットワークは「メッシュ」ネットワークと一般的に呼ばれて、そこでは、ネットワークノードは通信がそれらの目的地に到達するために進行することができるパスの「メッシュ」を形成することができる。無線ネットワークは、ビーコン送信を使用してネットワークの存在を広告することができ、ならびにネットワークおよびネットワークと関連した能力に関する情報を提供することができる。異なる種類のビーコン送信機構、例えば、インフラストラクチャモードネットワーク（基本サービスセット（ＢＳＳ）ネットワークとも呼ばれる）のためのもの、およびアドホックモードネットワーク（独立ベーシックサービスセット（ＩＢＳＳ）ネットワークとも呼ばれる）のためのものを用いることができる。インフラストラクチャネットワークにおいて、アクセスポイント（ＡＰ）はビーコンを生成する役割を果たすエンティティであるが、アドホックネットワークでは、すべてのネットワークノード（ユーザ局を含む）はビーコンの生成に参加する。アドホックネットワークビーコン（ＩＢＳＳビーコンと呼ばれる）は全体として、ネットワーク（すべてのノードから成る）を広告するために用いるが、一方でインフラストラクチャネットワークビーコン（ＢＳＳビーコンと呼ばれる）はＡＰによって生成され、その個々のＡＰの存在だけを知らせるものである。このような通信のために用いられるコンポーネントは、ネットワークのタイプ、選択される環境、または、両方ともに少なくとも部分的に依存し得る。このようなネットワークを通じて通信するためのプロトコルは周知であり、本明細書においては詳細に述べられない。
本明細書の「読み取る」という用語は、支払オブジェクトからデータを読み込むために、例えば中に入れたり、タップしたり、かざしたり、密接な接触をさせたり、または支払オブジェクトを支払オブジェクトリーダの中に、または、それを通して通過させたりすることによって支払オブジェクトリーダを起動するあらゆる方法を指す。
この文書の「実施形態」に対する参照は、記載されている要素を単一の実施形態に制限するものではなく、すべての記載されている要素は、いかなる数の方法でいかなる実施形態に組み込んでもよい。さらに、本仕様を解釈するために、本明細書における「または」の使用は、特に明記しない限り「および／または」を意味する。「ａ」または「ａｎ」の使用は、特に明記しない限り「一つ以上」を本明細書において意味する。使用、「含む（ｃｏｍｐｒｉｓｅ）」、「含む（ｃｏｍｐｒｉｓｅｓ）」「含む（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅ）」、「含む（ｉｎｃｌｕｄｅｓ））」および、「含む（ｉｎｃｌｕｄｉｎｇ）」の使用は、互換性があり、制限的であることを意図していない。また、特に明記しない限り、「第１」、「第２」、「第３」、「上位」、「下位」などのような用語の使用は、いかなる空間的、逐次的、または階層的な順序または重要性も意味するものではなく、１つの要素を別のものと区別するために用いる。例えば、「Ａおよび／またはＢ」および「ＡおよびＢの少なくとも１つ」の場合における、「および／または」および、「の少なくとも１つ」という用語の使用は、第１の列挙されたオプション（Ａ）だけの選択、または第２の列挙されたオプション（Ｂ）だけの選択、または両方のオプション（ＡおよびＢ）の選択を包含することを意図していることが理解されるべきである。さらなる例として、「Ａ、Ｂおよび／またはＣ」および「Ａ、ＢおよびＣの少なくとも１つ」の場合には、このような言葉遣いは、第１の列挙されたオプション（Ａ）だけの選択、または、第２の列挙したオプション（Ｂ）だけの選択、または第３の列挙したオプション（Ｃ）だけの選択、または第１および第２の列挙したオプション（ＡおよびＢ）だけの選択、または第１および第３の列挙したオプション（ＡおよびＣ）だけの選択、または第２および第３の列挙したオプション（ＢおよびＣ）だけの選択、または３つのすべてのオプション（ＡおよびＢおよびＣ）の選択を包含することを意図している。これは、本技術および関連技術の当業者によって直ちに明らかな様に、列挙しただけ多くの項目さらに拡張することができる。
本明細書において用いる場合、「の最中に」、「する間」および「するとき」という語は、ある動作がある開始動作と同時に即座に起きることを意味する正確な用語ではなく、初期動作と初期動作によって開始されるその反応の間に伝播遅延などのいくらかの小さいが合理的な遅延があってもよいことを意味するものであることも当業者によって理解されよう。本仕様および本出願のあらゆる請求項において用いられる場合、「コンピュータ」、「サーバ」、「プロセッサ」および「メモリ」という用語はすべて、電子的あるいは他の技術のデバイスを指す。これらの用語は、人々または人々のグループは除外する。仕様の目的に対して、「表示する」または「表示している」という用語は、電子デバイスに表示することを意味する。本仕様および本出願のあらゆる請求項において用いられる場合、「コンピュータ可読媒体」という用語は、コンピュータによって読み込み可能である形に情報を保存する非一時的な有形の物理的エンティティに完全に限定される。これらの用語は、いかなる一時的無線信号も、有線のダウンロード信号および他のいかなる短命な信号も除外する。コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、一般には互いにリモート状態にあり、通常は通信ネットワークによって対話する。クライアントおよびサーバの関係は、それぞれのコンピュータで動作しており、互いにクライアント対サーバの関係があるコンピュータプログラムによって生じる。一部の実施形態において、サーバはデータ（例えば、ＨＴＭＬページ）をクライアント装置に対して（例えば、クライアント装置と対話しているユーザに対するデータの表示およびそのユーザからのユーザ入力の受信の目的で）送信する。クライアント装置で生成されるデータ（例えば、ユーザとの対話処理の結果）は、サーバでクライアント装置から受け取られることができる。
本明細書におけるいかなるブロック図、ステップまたはサブプロセスも本発明の主題の原理を実施している例示的システムの概念図を表すことはまた当業者によって認識されるはずである。同様に、すべてのフローチャート、フロー図、状態遷移図、疑似コードなどは、基本的にコンピュータ可読媒体において表示することができ、そしてそうしたコンピュータあるいはプロセッサがはっきり示されているかどうかに関係なく、コンピュータ又はプロセッサによってそのように実行できる種々のプロセスを示している。方法が記載されている順序は制限と解釈されることを目的としておらず、いかなる数の記載されている方法ブロックも、任意の順序で削除し、移動し、追加し、再分割し、結合し、および／または修正することができて、方法または代替の組合せまたはサブコンビネーションを実施することができる。また、ステップ、サブプロセスまたはブロックが連続的に実行されるとして示される場合があるが、当業者によって認識されるように、いくつかのステップ、サブプロセスまたはブロックはその代わりに並行して実行することができるか、または異なる時間に実行することができる。さらに、本明細書において強調されるいかなる固有の番号も、単に例に過ぎず、代替的な実装では、異なった値または範囲を使用することができる。さらに、方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせなどで実装することができる。
特定のデバイス、例えば、支払オブジェクトリーダおよびＰＯＳ端末が異なったコンポーネントを含むとして示されるが、これは単に説明を容易にするためだけであり、限定することを意図しない。種々の実装において、支払オブジェクトリーダおよびＰＯＳ端末は、同一でもよく、類似していてもよく、あるいは別のものでもよい。さらに、支払オブジェクトリーダおよびＰＯＳ端末について図と共に記載されるコンポーネントは、より多くのコンポーネントとして、または、より少ないコンポーネントとして実装されてもよく、コンポーネントについて記載されている機能は実装の詳細に応じて再分配することができる。加えて、一部の実装では、数百、数千、数十万またはそれ以上の支払オブジェクトリーダおよびＰＯＳ端末があってもよい。さらに、一部の実装では、支払オブジェクトリーダおよび／またはＰＯＳ端末の構成、構造および動作特性は、デバイスごとに変化してもよい。一般に、支払オブジェクトリーダおよびＰＯＳ端末は各々、１つ以上のネットワーク上で、または、互いに直接にデータ、要求、メッセージ、電子メッセージ、テキストメッセージ、アラート、通知、ポップアップメッセージ、プッシュ通知または他のタイプの情報を送受信するように動作可能な、いかなる適切なデバイスでもあり得る。
本明細書で導入される技術は、特殊目的ハードウェア（例えば、回路）として、ソフトウェアおよび／またはファームウェアによって適切にプログラムされるプログラム可能な回路として、または、特殊目的およびプログラム可能な回路の組合せとして実施することができる。したがって、実施形態は、１つ以上のプロセッサに方法、方法の変化形および本明細書に記載される他の動作を実行させるために用いることができる命令を格納している、機械可読媒体を含むことができる。機械可読媒体は、フロッピーディスク、光ディスク、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、光磁気ディスク、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読取り専用メモリ（ＥＥＰＲＯＭ）、特定用途向け集積回路（ＡＳＩＣ）、磁気もしくは光学カード、フラッシュメモリ、または電子命令を保存するのに適している他のタイプの媒体／機械可読媒体を含むことができるが、これに限定されるものではない。以下、１つ以上の図面を参照して各種実施形態について詳細に説明する。
支払プロキシ技術が、種々の他のコンテンツプロバイダおよび金融サービスプロバイダなどの種々の他のタイプのプロバイダに対して、または、ユーザ間のメッセージの通信を含むいかなるアプリケーションに対しても他の実施形態において等しく適用できて、そして支払プロキシ技術が媒体チャンネルおよび／またはメッセージングアプリケーションに限られていないことに留意されたい。
前述の概要は、いくつかの例示的実施形態を要約して本明細書において記載されている主題の態様を基本的に理解するために設けられている。したがって、上記の特徴は単に例に過ぎず、いかなる形であれ制限するものとして解釈されるべきでない。本明細書において記載されている主題の他の特徴、態様および利点は、図および請求項の以下の記述から明らかになる。
ここで図を参照すると、図１Ａは、本発明の主題のいくつかの実施形態によるネットワーク環境１の例示的なブロック図を表す。一実施形態において、ネットワーク環境１は、支払オブジェクト１０、支払端末２０、ネットワーク３０および支払サーバ４０を含む。例示的な実施形態において、支払サーバ４０は、支払処理システム５０（ＰＰＳ５０とも呼ばれる）およびトランザクションサーバ６０など、取得者、発行者、カード処理ネットワークまたはすべてなどの、異なるエンティティによって作動される複数のサーバを含むことができる。ＰＰＳ５０は、改ざん検出コンポーネント８０および暗号９５などの追加コンポーネントを含むことができる暗号９５は、さらにハードウェアセキュリティモジュール（ＨＳＭ）９８を含むかまたは、それと関連付けられる。ネットワーク環境１のこれらのコンポーネントは、支払トランザクション同期した証明方式を用いて安全かつ高速な方法で、小売業者と顧客の間の電子支払トランザクションを容易にする。
小売業者と顧客の間の電子的対話は、顧客の支払オブジェクト１０と小売業者の支払端末２０（支払オブジェクトリーダ３を含む）の間に起こる。顧客は、磁気ストライプを有するクレジットカード、ＥＭＶチップを有するクレジットカードまたは例えばスマートフォン支払アプリケーションを実行するＮＦＣ対応電子デバイスなどの支払オブジェクト１０を有する。小売業者は、支払端末または、支払情報（例えば、暗号化された支払カードデータおよびユーザ認証データ）およびトランザクション情報（例えば、購入額および購入時点情報）を処理することができる他の電子デバイス、例えば支払アプリケーションを実行しているスマートフォンまたはタブレットなどの、支払端末２０を有する。小売業者は、支払端末２０にペアリングされるかまたは接続している支払オブジェクトリーダ３に、支払オブジェクト１０を挿入する。ペアリングのプロセスは記載されていなが、当業者には理解されるであろう。
一部の実施形態において（例えば、低価値トランザクションに対して、または、ＮＦＣまたはＥＭＶ支払オブジェクト１０によって示される支払制限より少ない支払トランザクションに対して）、支払トランザクションの初期処理および承認は、支払端末２０で処理することができる。他の実施形態において、支払端末２０は、ネットワーク３０上で支払サーバ４０と通信することができる。支払サーバ４０は単一エンティティによって運用することができるが、一実施形態において、支払サーバ４０は、支払処理システム５０ならびに小売業者および顧客の１つ以上の銀行（例えば、トランザクションサーバ６０）などの任意の適切なエンティティによって運営される、任意の適当な数のサーバを含むことができる。支払端末２０および支払サーバ４０は、支払およびトランザクション情報を通信してトランザクションが許可されているかどうかを判定する。例えば、支払端末２０は、暗号化された支払データ、ユーザ認証データ、購入額情報および購買時点情報をネットワーク３０上で支払サーバ４０に提供することができる。支払サーバ４０は、トランザクションがこの受信情報ならびに顧客か小売業者アカウントに関連している情報に基づいて許可されているかどうか判定することができ、支払トランザクションが許可されているか否か示すためにネットワーク３０上で支払端末２０に応答する。支払サーバ４０は、支払端末２０に対するトランザクション識別子などの追加情報を送信することもできる。
一部の実施形態において、支払端末２０は物理および論理的スキャンまたはテストを実行して、トランザクションが不正か否か、または、攻撃者が支払端末２０を改ざんすることを試みているかどうか判定することに役立つ情報を集めることができる。支払端末２０は、収集した情報と１つ以上のテスト基準またはコマンドの比較に基づいて、修正処置（例えば、トランザクションを中止するかまたは支払端末２０の１つ以上のコンポーネントを無効にすること）を行うことができる。一部の実施形態において、情報は、処理のために支払サーバ４０（例えば、支払処理システム５０）に送信することができる。支払サーバ４０は、受信情報ならびに以前のトランザクションおよび他の進行中のトランザクションからの情報に基づいて、修正処置を行うべきかどうか決定することができる。支払サーバ４０は不正の判定メッセージを支払端末２０に提供することができ、それにより支払端末２０に修正処置をさせることができる。一部の実施形態において、支払サーバ４０は、支払端末２０の更新されたテスト基準を生成して、今後のトランザクションの処理のために更新を支払端末２０に提供することもできる。
支払サーバ４０から支払端末２０で受け取られる情報に基づいて、小売業者は、トランザクションが承認されたかどうか顧客に示すことができる。チップカード支払デバイスなどの一部の実施形態において、承認は、支払端末で、例えば、支払端末のスクリーンで示すことができる。ＮＦＣ支払デバイスとして作動しているスマートフォンまたはスマートウォッチなどの他の実施形態において、承認されたトランザクションに関する情報および追加情報（例えば、領収書、特価提供、クーポンまたはロイヤルティプログラム情報）は、スマートフォンまたはスマートウォッチのスクリーンでの表示またはメモリへの記憶のためにＮＦＣ支払デバイスに提供することができる。
一実装では、支払システム１は、証明チケット８５を生成して、他のいかなるエンティティにも、支払端末２０、支払オブジェクトリーダ３、支払アプリケーション２５（合わせて支払プラットフォーム５と呼ばれる）が安全でかつ信頼され、したがってプラットフォーム５から起こるいかなる要求も安全であるということを示す、方法およびシステムを開示する。例えば、支払プラットフォームがソフトウェアＰＩＮを受信するように構成される場合、それが証明されている限り、プラットフォームはそうすることができる。支払プラットフォームが証明されていない場合、例えば、支払端末が証明されていない場合、リーダ３は、支払処理システム５０が支払端末２０を妥当性確認完了するまで、支払端末２０または支払アプリケーション２５と通信しない。ソフトウェアＰＩＮは、当業者によって理解されるように、妥当性確認が実行される多くの理由の中の単に１つである。
動作上、改ざん検出コンポーネント８０は支払処理システム５０の中に含まれ、証明ルーチンを送信するように構成され、それがクライアントコンポーネント、すなわち改ざんモニタリングコンポーネント７０に、クライアント装置、すなわち支払プラットフォーム５上で実行することを望む種々のスキャンおよびテストを特定する。例えば、証明ルーチンは、以下に改ざんモニタリングコンポーネント７０に、支払アプリケーション、ＰＯＳ端末、支払オブジェクトリーダ、例えば種々のタイプの支払デバイスと対話してソフトウェアコンポーネントの動作をテストする支払インターフェースの各種コンポーネントの電気的特性を計測し、電流、電圧、インピーダンスおよび容量などの値をモニタリングして、コンポーネントが異常な方法で動作しているかどうかを判定し、製造または工学的許容度、タイミングパラメータ、関連する挙動などのプラットフォーム特性を測定し、特定の通信ポートのアクティブ化をチェックし、位相誤差、周波数誤差、電力およびスペクトル、ＲＳＳＩレベルなどの電源信号レベル、ＲＳＳＩ対周波数の測定値を測定し、工学的許容度、デバイスのアナログコンポーネントに固有のハードウェア不完全性、特定の信号への無線周波数応答を測定し、物理的、機械的、磁気的、電気機械的または動作的な特性を測定し、プラットフォーム特性を他のすべてのプラットフォームの集団または地理的領域の範囲内のプラットフォームと比較することなどを指示するテスト基準またはコマンドを含むことができる。
一実装では、支払プラットフォーム５（または支払端末２０の範囲内などのエンティティの１つ）は、支払サービスシステム５０から証明チケットに対する要求をする。例えば、改ざんモニタリングコンポーネント７０は、最初に改ざん検出コンポーネント８０に証明チケットを要求して、支払端末２０またはネットワーク装置、例えば通信装置または端末上で実行している支払アプリケーションなどを証明することを要求する。これは、周期的に、ランダムに、または、証明チケットの失効の前後に起こり得る。他の実装では、証明は、物理的なイベント、例えば小売業者がリーダ３を支払端末２０と接続すること、または小売業者が支払端末２０上に新規な支払アプリケーション２５をインストールすることによって起動され得る。
それに応じて、改ざん検出コンポーネント８０は、前述の例示的なテスト基準またはコマンドを有する証明ルーチンを生成する。コマンドを受信すると、改ざんモニタリングコンポーネント７０は、支払プラットフォーム５またはその一部を、支払プラットフォーム５における修正、障害または異常に対して、アプリケーション、ハードウェアおよびオペレーティングシステムを含んでスキャンする。支払処理システムは、改ざん検出コンポーネント８０を実行して、支払プラットフォーム５が実行するチェックを特定するだけでなく、改ざんモニタリングコンポーネント７０から結果データも集めて、そして、支払モニタリングコンポーネント７０からのデータ（以下「証明データ７５」と呼ぶ）を分析して、疑わしいアクティビティを識別する。例えば、改ざん検出コンポーネント８０および改ざんモニタリングコンポーネント７０は、ＨＴＴＰ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）上で実装される難読化および暗号化されたプロトコル（以下「信頼されたチャネル」と呼ぶ）を介して通信することができる。
一実装では、改ざん検出コンポーネント８０は、証明データ７５の分析の際に、支払プラットフォームに既知の問題がなく、かつセキュリティ脅威が識別されていないことを判定して、証明チケット８５を生成して、今後のトランザクションのために支払端末７０に（またはリーダ３にさえ）送信する。したがって、改ざん検出コンポーネント８０は、証明チケットが有効である限りはリーダ３と支払端末２０またはアプリケーション２５の間の安全なセッションを妥当性確認することができる。リーダ３が支払端末２０に接続されていると、リーダ３は、チケットをリーダ３に、さらに、トランザクションが処理されるときには支払処理システム５０に提示することによって、支払端末２０と通信することができる。対照的に、改ざん検出コンポーネント８０が支払プラットフォーム５、例えば小売業者の支払端末２０上の改ざんまたはセキュリティ問題を検出した場合、改ざん検出コンポーネント５０は証明チケット８５を生成しないか、または改ざん検出コンポーネント５０が安全なセッションを妥当性確認することに失敗したことを示すエラーコードを有する証明チケット８５を生成する。支払処理システム５０がいずれの場合においてもチケットを生成する理由は、不正ユーザがチケットの欠如に基づいて１つのデバイスを別のものと区別することができず、偽の証明にリバースエンジニアリングするからである。
改ざん検出コンポーネント８０は、証明チケット８５に寿命を割り当てることができ、トランザクションが発生するたびにプラットフォームがスキャンされるかまたはテストされないように、妥当性確認を要求したプラットフォーム５のデバイスにそれを送ることができる。チケットが有効期限切れになると、改ざんモニタリングコンポーネント７０は証明チケット用の要求を再提出する。一実装では、証明チケットは、さもなければ証明チケットが寿命に従って有効な場合であっても、他の証明トリガーに応答して無効にされることもできておよび／または再生成することもできる。
証明トリガーの例は、リーダ３と異なる新規なリーダを支払端末にペアリングすること、未知のデバイスに支払アプリケーションをインストールすること、例えば不正なことが公知の新しい位置へのリーダまたはＰＯＳ端末の再配置を検出すること、不正ユーザからのカードの挿入を検出すること、不正なカードを検出すること、確立したジオフェンスの範囲内への不正なデバイスの入り込みを検出することなどを含むが、これに限定されるものではない。このように、証明チケットは、プラットフォームだけでなく環境、例えば小売業者ストアがある位置、顧客または支払オブジェクトまたはジオフェンスに入る支払デバイス（Ａｐｐｌｅ Ｗａｔｃｈ（登録商標）のような）も証明することができる。
トランザクションが支払端末２０と支払オブジェクトリーダ３の間に発生するときに、支払オブジェクトリーダ３は支払端末２０に証明チケット８５を共有することを要求する。リーダ３は証明チケット８５を解読するか現状のままでサーバ５０に送信し、サーバ５０は安全なセッションの間に内容および／またはタイミングから証明チケット８５が有効かどうか判定する。それが有効である場合、サーバは両方とも、または、リーダおよび端末に承認を送る。そうでない場合には、拒否が当事者に送られる。
図１Ｂは、本発明の主題の一部の実施形態による、改ざんモニタリングコンポーネント７０と改ざん検出コンポーネント８０の間の例示的な方法フロー２および４を表す。
方法フロー２を参照すると、改ざんモニタリングコンポーネント７０はＨＴＴＰエンドポイントを使用して、改ざん検出コンポーネント８０と通信する。それがＨＴＴＰを通じて起こるので、これは改ざん検出コンポーネント８０からの応答が後に続く改ざんモニタリングコンポーネント７０からの要求として構築される。しかしながら、論理上、それは、改ざんモニタリングコンポーネント７０からの結果が後に続く改ざん検出コンポーネント８０からのコマンドのようであり得る。改ざんモニタリングコンポーネント７０は、（ａ）スタートアップ時に、（ｂ）送信すべきデータをそれが有するときはいつでも、そして（ｃ）数分ごとに、要求を送信し、これは、改ざん検出コンポーネント８０に新たなコマンドを送る正規の機会を与える。示すように、Ａで、改ざんモニタリングコンポーネント７０は、構成または証明のための初期要求を送信する。Ｉで、改ざん検出コンポーネント８０は、ルーチンを生成する。Ｂで、改ざん検出コンポーネント８０は、改ざんモニタリングコンポーネント７０が実行するための証明コマンドまたはルーチン（即ち、デバイス全体を特定のマルウェアまたはジェイルブレーキング徴候を求めて調べる）を送信する。Ｃで、改ざんモニタリングコンポーネント７０は改ざん検出コンポーネント８０への証明コマンドの結果を生成し、それはＪで解析され、そして例えば、証明もしくはセッション妥当性確認を否定するかまたは承認するという応答を、Ｄを使用して改ざんモニタリングコンポーネント７０に送信することができる。プロセスは数回か、または一定の数のコマンドが実行されるかもしくは応答が取得されるまで繰り返すことができる。コマンドは、要求側デバイス、小売業者、位置などに基づいて設定することができる。さらに、改ざんモニタリングコンポーネントは、チケットまたはセッション証明書が有効なことを検証するために、所定の時間間隔で改ざん検出コンポーネントをチェックすることができる。これは、図のループ部によって示される。サーバはコマンドを送信して、最初のコマンドに対する応答が受け取られると、新たなコマンドを生成する。詐欺行為者がシステムに侵入しようとしていて、パターンを決めようとしている場合、複数の交換プロトコルを有するこのメッセージ送信は役立ち得る。したがって、１つの例で、それは、５サイクルの情報交換を有する５ステップの決定木であり得る。コマンドに対する応答は、善良な行為者から悪意のある行為者をフィルタリングするのを助けることができる。同じタイプの証明チケットは、詐欺行為者がリバースエンジニアリングすることができないように、両方のデバイスに送信することができる。改ざんモニタリングコンポーネントならびに検出コンポーネント７０および８０は、定期的なチェックインに関与して、証明チケットの状態を更新するかまたはより良好な分析のための状態情報を送信することもできる。コンポーネント７０からのあらゆる「フレーム」またはデータのパッケージは、今後の分析のためにＨＤＦＳに保存される。特に疑わしいフレームは、即時の対応によってチェックすることができる。閾値レベルよりも多い疑わしいフレームを生成したいくつかのデバイスは、証明のための要求を拒否され得る。
方法フロー４において、改ざんモニタリングコンポーネント７０はＨＴＴＰエンドポイントを使用して、改ざん検出コンポーネント８０と通信する。それがＨＴＴＰを通じて起こるので、これは改ざん検出コンポーネント８０から応答が続く改ざんモニタリングコンポーネント７０からの要求として構築される。しかしながら、論理上、それは、改ざんモニタリングコンポーネント７０からの結果が後に続く改ざん検出コンポーネント８０からの低レベルコマンドのようであり得る。改ざんモニタリングコンポーネント７０は、（ａ）スタートアップ時に、（ｂ）送信すべきデータをそれが有するときはいつでも、そして（ｃ）数分ごとに、要求を送信し、これは、改ざん検出コンポーネント８０に新たなコマンドを送る正規の機会を与える。ステップＡＡ〜ＫＫに示すように、コンポーネント７０は、証明のための要求とともに、すぐにすべてのそのデバイス仕様を送信することができる。また、示すように、この実装では、定期的なチェックインはデバイス仕様の１回限りのディスパッチと置き換えられ、それに基づいて、改ざん検出コンポーネント８０は証明のためのコマンドを生成する。したがって、コンポーネント８０は、コマンドを生成して、必要であれば追加のものを続行する。
図１Ｃは、本発明の主題の別の実施形態によるネットワーク環境１の例示的なブロック図を表す。一実施形態において、ネットワーク環境１は、支払オブジェクト１０、支払端末２０、ネットワーク３０および支払サーバ４０を含む。例示的な実施形態において、支払サーバ４０は、支払処理システム５０（ＰＰＳ５０とも呼ばれる）およびトランザクションサーバ６０など、取得者、発行者、カード処理ネットワークまたはすべてなどの、異なるエンティティによって作動される複数のサーバを含むことができる。ＰＰＳ５０は、改ざん検出コンポーネント８０、証明サブシステム８２、フェイルオーバーコンポーネント９０および暗号９５などの追加コンポーネントを含むことができる。暗号９５は、さらにハードウェアセキュリティモジュール（ＨＳＭ）９８を含むかまたは、それと関連付けられる。ＰＰＳ５０は、分配ネットワークまたはチケットトラフィックコントローラであることができるコントローラ９３に関連することもできるかまたはそれに制御されることもできる。環境は追加サーバ５５を含むことも示し、それはサーバ５０と動作において同様であってもよい。一実装では、サーバ５５は特定のタイプの要求または、特定のレベルのリスクを処理するように設計することができ、その場合、高リスクのチケットはサーバ５５に送信されてもよい。別の例では、サーバ５５は、異なる裁判権、ルールまたはデータベースに関連する規則によって動作するように設計することができる。別の例において、サーバは、例えばロードバランシングまたはフェイルオーバー管理に利用可能な異なる位置の、または、同じ位置の支払サーバに対応することができる。証明チケットおよび／またはセッション証明は、国籍に関係なく、１台のサーバから別のサーバに移動することができ、異なる位置にわたって同期することもできる。ネットワーク環境１のこれらのコンポーネントは、支払トランザクション同期した証明方式を用いて安全かつ高速な方法で、小売業者と顧客の間の電子支払トランザクションを容易にする。
小売業者と顧客の間の電子的対話は、顧客の支払オブジェクト１０と小売業者の支払端末２０（支払オブジェクトリーダ３を含む）の間に起こる。顧客は、磁気ストライプを有するクレジットカード、ＥＭＶチップを有するクレジットカードまたは例えばスマートフォン支払アプリケーションを実行するＮＦＣ対応電子デバイスなどの支払オブジェクト１０を有する。小売業者は、支払端末または、支払情報（例えば、暗号化された支払カードデータおよびユーザ認証データ）およびトランザクション情報（例えば、購入額および購入時点情報）を処理することができる他の電子デバイス、例えば支払アプリケーションを実行しているスマートフォンまたはタブレットなどの、支払端末２０を有する。小売業者は、支払端末２０にペアリングされるかまたは接続している支払オブジェクトリーダ３に、支払オブジェクト１０を挿入する。ペアリングのプロセスは記載されていなが、当業者には理解されるであろう。
一部の実施形態において（例えば、低価値トランザクションに対して、または、ＮＦＣまたはＥＭＶ支払オブジェクト１０によって示される支払制限より少ない支払トランザクションに対して）、支払トランザクションの初期処理および承認は、支払端末２０で処理することができる。他の実施形態において、支払端末２０は、ネットワーク３０上で支払サーバ４０と通信することができる。支払サーバ４０は単一エンティティによって運用することができるが、一実施形態において、支払サーバ４０は、支払処理システム５０ならびに小売業者および顧客の１つ以上の銀行（例えば、トランザクションサーバ６０）などの任意の適切なエンティティによって運営される、任意の適当な数のサーバを含むことができる。支払端末２０および支払サーバ４０は、支払およびトランザクション情報を通信してトランザクションが許可されているかどうかを判定する。例えば、支払端末２０は、暗号化された支払データ、ユーザ認証データ、購入額情報および購買時点情報をネットワーク３０上で支払サーバ４０に提供することができる。支払サーバ４０は、トランザクションがこの受信情報ならびに顧客か小売業者アカウントに関連している情報に基づいて許可されているかどうか判定することができ、支払トランザクションが許可されているか否か示すためにネットワーク３０上で支払端末２０に応答する。支払サーバ４０は、支払端末２０に対するトランザクション識別子などの追加情報を送信することもできる。
一部の実施形態において、支払端末２０は物理および論理的スキャンまたはテストを実行して、トランザクションが不正か否か、または、攻撃者が支払端末２０を改ざんすることを試みているかどうか判定することに役立つ情報を集めることができる。支払端末２０は、収集した情報と１つ以上のテスト基準またはコマンドの比較に基づいて、修正処置（例えば、トランザクションを中止するかまたは支払端末２０の１つ以上のコンポーネントを無効にすること）を行うことができる。一部の実施形態において、情報は、処理のために支払サーバ４０（例えば、支払処理システム５０）に送信することができる。支払サーバ４０は、受信情報ならびに以前のトランザクションおよび他の進行中のトランザクションからの情報に基づいて、修正処置を行うべきかどうか決定することができる。支払サーバ４０は不正の判定メッセージを支払端末２０に提供することができ、それにより支払端末２０に修正処置をさせることができる。一部の実施形態において、支払サーバ４０は、支払端末２０の更新されたテスト基準を生成して、今後のトランザクションの処理のために更新を支払端末２０に提供することもできる。
支払サーバ４０から支払端末２０で受け取られる情報に基づいて、小売業者は、トランザクションが承認されたかどうか顧客に示すことができる。チップカード支払デバイスなどの一部の実施形態において、承認は、支払端末で、例えば、支払端末のスクリーンで示すことができる。ＮＦＣ支払デバイスとして作動しているスマートフォンまたはスマートウォッチなどの他の実施形態において、承認されたトランザクションに関する情報および追加情報（例えば、領収書、特価提供、クーポンまたはロイヤルティプログラム情報）は、スマートフォンまたはスマートウォッチのスクリーンでの表示またはメモリへの記憶のためにＮＦＣ支払デバイスに提供することができる。
一実装では、支払システム１は、証明チケット８５を生成して、他のいかなるエンティティにも、支払端末２０、支払オブジェクトリーダ３、支払アプリケーション２５（合わせて支払プラットフォーム５と呼ばれる）が安全でかつ信頼され、したがってプラットフォーム５から起こるいかなる要求も安全であるということを示す、方法およびシステムを開示する。例えば、支払プラットフォームがソフトウェアＰＩＮを受信するように構成される場合、それが証明されている限り、プラットフォームはそうすることができる。支払プラットフォームが証明されていない場合、例えば、支払端末が証明されていない場合、リーダ３は、支払処理システム５０が支払端末２０を妥当性確認完了するまで、支払端末２０または支払アプリケーション２５と通信しない。ソフトウェアＰＩＮは、当業者によって理解されるように、妥当性確認が実行される多くの理由の中の単に１つである。
動作上、改ざん検出コンポーネント８０は支払処理システム５０の中に含まれ、証明ルーチンを送信するように構成され、それがクライアントコンポーネント、すなわち改ざんモニタリングコンポーネント７０に、クライアント装置、すなわち支払プラットフォーム５上で実行することを望む種々のスキャンおよびテストを特定する。例えば、証明ルーチンは、以下に改ざんモニタリングコンポーネント７０に、支払アプリケーション、ＰＯＳ端末、支払オブジェクトリーダ、例えば種々のタイプの支払デバイスと対話してソフトウェアコンポーネントの動作をテストする支払インターフェースの各種コンポーネントの電気的特性を計測し、電流、電圧、インピーダンスおよび容量などの値をモニタリングして、コンポーネントが異常な方法で動作しているかどうかを判定し、製造または工学的許容度、タイミングパラメータ、関連する挙動などのプラットフォーム特性を測定し、特定の通信ポートのアクティブ化をチェックし、位相誤差、周波数誤差、電力およびスペクトル、ＲＳＳＩレベルなどの電源信号レベル、ＲＳＳＩ対周波数の測定値を測定し、工学的許容度、デバイスのアナログコンポーネントに固有のハードウェア不完全性、特定の信号への無線周波数応答を測定し、物理的、機械的、磁気的、電気機械的または動作的な特性を測定し、プラットフォーム特性を他のすべてのプラットフォームの集団または地理的領域の範囲内のプラットフォームと比較することなどを指示するテスト基準またはコマンドを含むことができる。
証明サブシステム８２は改ざん検出コンポーネント８０によって機能して、端末２０などの第三者に要求を送受信する。従って、それはクライアントに対応するものである。それは、暗号化および解読を、即ちＨＳＭ８に格納されるキーを用いて作動する暗号９５を使用して、処理することもできる。
暗号は、限定するものではないが、マイクロコントローラ、プロセッサ、インターフェースおよび／または、証明サブシステム８２などのデバイスに接続されることができ、および／またはそれと通信することができるデバイスなどのユニットを含むことができる。暗号ユニットは、対話しているエージェントからの通信の認証をサポートするだけでなく、匿名のトランザクションを考慮に入れる。暗号ユニットは、ＣＰＵの一部として構成することもできる。
暗号９５はＨＳＭキー９５を含むことを示し、それは工場設定であることができて、リーダおよびサーバに対応するキーを有することができる。暗号９５は、ＰＰＳ上のリソースの安全なアクセスを容易にして、リモートシステム上の安全なリソースのアクセスを容易にし、すなわち、それは、安全なリソースのクライアントおよび／またはサーバとして機能することができる。暗号プロセッサのインターフェースは、暗号コンポーネントによって暗号化および／または解読要求の迅速性を考慮に入れることができる。暗号コンポーネントは、提供されるデータの暗号化および／または解読を考慮に入れる。暗号コンポーネントは、対称および非対称（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））の両方の暗号化および／または解読を考慮に入れる。暗号コンポーネントは、デジタル証明書（例えば、Ｘ．５０９認証フレームワーク）、デジタル署名、二重署名、エンベロープ化、パスワードアクセス保護、公開鍵管理および／または同様のものなどの暗号技術を使用することができるが、それに限定されるものではない。暗号コンポーネントは、限定するものではないが、チェックサム、データ暗号化規格（ＤＥＳ）、Ｅｌｌｉｐｔｉｃａｌ Ｃｕｒｖｅ Ｅｎｃｒｙｐｔｉｏｎ（ＥＣＣ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ（ＩＤＥＡ）、Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ５（ＭＤ５（片方向ハッシュ演算である））、パスワード、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）、Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）、ＨＭＡＣおよび／または同様のものなどの数多くの（暗号化および／または解読）セキュリティプロトコルを容易にすることができる。このような暗号化セキュリティプロトコルを使用して、サーバ５０は、すべての着信および／または送信通信を暗号化することができる。復号データがＨＭＡＣによって署名されているとわかる場合、セッションは承認されることができ、したがって、証明チケットおよび／またはセッション証明を生成することができる。
サーバ５０は、安全であるか、保護されているかまたは隔離された環境を作成して維持するためのいかなるロジック、回路、ハードウェアまたはその他の構造を表すこともできるセキュアエンクレーブユニット（図示せず）と関連付けてもよく、そこでは、アプリケーションまたは他のソフトウェアは、情報処理システムにおいて動作することができるか、実行することができるか、ロードされることができるか、または、存在することができる。セキュアエンクレーブユニットは暗号化部（図示せず）をさらに含むことができ、それは１つ以上のいかなる暗号化アルゴリズムおよび対応する解読アルゴリズムも実行するいかなるロジック、回路または他のハードウェアを含むことができて、プロセッサの別の暗号化ユニットと共有されるロジック、回路または他のハードウェアを含むことができる。一実施形態において、セキュアエンクレーブユニットは、ＨＳＭ鍵などの鍵を含む。
さらに、通信の命令は、所望の動作を容易にするプログラムおよび／またはデータコンポーネントとしてバッチ（例えば、命令のバッチ）で格納されることができ、および／または送信されることができる。
サーバ５０は、フェイルオーバーユニット９０を含むことも示す。１つのコンポーネントまたは全サーバがダウンする場合、サーバ５０はプロセス、特にセッションの妥当性確認のような重要なプロセスをプロセッサ５５のような別のプロセッサに割り当てることができる。フェイルオーバーは、フェイルオーバーポリシーに従ってリソースグループ（またはアプリケーション）を別のノードに割り当てるプロセスである。フェイルオーバーは、リソースの障害、ノードメンバシップの変化（例えばノードが機能しないかまたは始まる時など）または管理者による手動要求によって起動することができる。示される可用性ネットワークは、第１のネットワークによって接続される複数のサーバを含み、そこでは、サーバは互いに通信してサーバ障害を検出して、「フェイルオーバー」と呼ばれるプロセスを通してサーバ故障を検出すると他のサーバへアプリケーションを転送する。
サーバ５０はまた、トラフィックコントローラ９３を含み、すべてのデバイスからチケットを受信して適切なサーバに、例えば特定の位置の、または、コマンドが異なるこのような高リスクのデバイスなどに関連したサーバに、委任する。コントローラ９３は、チケットを受信し、ヘッダフィールドまたはユーザ情報を分析して、それがどこに経路指定されなければならないかを決定する。
一実装では、支払プラットフォーム５（または支払端末２０の範囲内などのエンティティの１つ）は、支払サービスシステム５０から証明チケットに対する要求をする。例えば、改ざんモニタリングコンポーネント７０は、最初に改ざん検出コンポーネント８０に証明チケットを要求して、支払端末２０またはネットワーク装置、例えば通信装置または端末上で実行している支払アプリケーションなどを証明することを要求する。これは、周期的に、ランダムに、または、証明チケットの失効の前後に起こり得る。他の実装では、証明は、物理的なイベント、例えば小売業者がリーダ３を支払端末２０と接続すること、または小売業者が支払端末２０上に新規な支払アプリケーション２５をインストールすることによって起動され得る。
それに応じて、改ざん検出コンポーネント８０は、前述の例示的なテスト基準またはコマンドを有する証明ルーチンを生成する。コマンドを受信すると、改ざんモニタリングコンポーネント７０は、支払プラットフォーム５またはその一部を、支払プラットフォーム５における修正、障害または異常に対して、アプリケーション、ハードウェアおよびオペレーティングシステムを含んでスキャンする。支払処理システムは、改ざん検出コンポーネント８０を実行して、支払プラットフォーム５が実行するチェックを特定するだけでなく、改ざんモニタリングコンポーネント７０から結果データも集めて、そして、支払モニタリングコンポーネント７０からのデータ（以下「証明データ７５」と呼ぶ）を分析して、疑わしいアクティビティを識別する。例えば、改ざん検出コンポーネント８０および改ざんモニタリングコンポーネント７０は、ＨＴＴＰ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）上で実装される難読化および暗号化されたプロトコル（以下「信頼されたチャネル」と呼ぶ）を介して通信することができる。
一実装では、改ざん検出コンポーネント８０は、証明データ７５の分析の際に、支払プラットフォームに既知の問題がなく、かつセキュリティ脅威が識別されていないことを判定して、証明チケット８５を生成して、今後のトランザクションのために支払端末７０に（またはリーダ３にさえ）送信する。したがって、改ざん検出コンポーネント８０は、証明チケットが有効である限りはリーダ３と支払端末２０またはアプリケーション２５の間の安全なセッションを妥当性確認することができる。リーダ３が支払端末２０に接続されていると、リーダ３は、チケットをリーダ３に、さらに、トランザクションが処理されるときには支払処理システム５０に提示することによって、支払端末２０と通信することができる。対照的に、改ざん検出コンポーネント８０が支払プラットフォーム５、例えば小売業者の支払端末２０上の改ざんまたはセキュリティ問題を検出した場合、改ざん検出コンポーネント５０は証明チケット８５を生成しないか、または改ざん検出コンポーネント５０が安全なセッションを妥当性確認することに失敗したことを示すエラーコードを有する証明チケット８５を生成する。支払処理システム５０がいずれの場合においてもチケットを生成する理由は、不正ユーザがチケットの欠如に基づいて１つのデバイスを別のものと区別することができず、偽の証明にリバースエンジニアリングするからである。
改ざん検出コンポーネント８０は、証明チケット８５に寿命を割り当てることができ、トランザクションが発生するたびにプラットフォームがスキャンされるかまたはテストされないように、妥当性確認を要求したプラットフォーム５のデバイスにそれを送ることができる。チケットが有効期限切れになると、改ざんモニタリングコンポーネント７０は証明チケット用の要求を再提出する。一実装では、証明チケットは、さもなければ証明チケットが寿命に従って有効な場合であっても、他の証明トリガーに応答して無効にされることもできておよび／または再生成することもできる。
証明トリガーの例は、リーダ３と異なる新規なリーダを支払端末にペアリングすること、未知のデバイスに支払アプリケーションをインストールすること、例えば不正なことが公知の新しい位置へのリーダまたはＰＯＳ端末の再配置を検出すること、不正ユーザからのカードの挿入を検出すること、不正なカードを検出すること、確立したジオフェンスの範囲内への不正なデバイスの入り込みを検出することなどを含むが、これに限定されるものではない。このように、証明チケットは、プラットフォームだけでなく環境、例えば小売業者ストアがある位置、顧客または支払オブジェクトまたはジオフェンスに入る支払デバイス（Ａｐｐｌｅ Ｗａｔｃｈ（登録商標）のような）も証明することができる。
トランザクションが支払端末２０と支払オブジェクトリーダ３の間に発生するときに、支払オブジェクトリーダ３は支払端末２０に証明チケット８５を共有することを要求する。リーダ３は証明チケット８５を解読するか現状のままでサーバ５０に送信し、サーバ５０は安全なセッションの間に内容および／またはタイミングから証明チケット８５が有効かどうか判定する。それが有効である場合、サーバは両方とも、または、リーダおよび端末に承認を送る。そうでない場合には、拒否が当事者に送られる。
図２は、本発明の主題の一部の実施形態による支払オブジェクト１０および支払端末２０の例示的なブロック図を表す。支払システム１の支払オブジェクト１０および支払端末２０がいかなる好適な方法でも実装できることが理解されるであろうが、一実施形態では、支払端末２０は支払オブジェクトリーダ２２（支払オブジェクト３と同様であるか異なる）および小売業者デバイス２９を含むことができる。しかしながら、本明細書において用いる場合、支払端末という用語が支払オブジェクトリーダ２２などの支払端末のいかなる適切なコンポーネントを指してもよいことが理解されよう。一実施形態において、支払端末２０の支払オブジェクトリーダ２２は、支払オブジェクト１０と、図１に示される支払アプリケーション２５などの販売時点アプリケーションを実行している小売業者デバイス２９の間のトランザクションを容易にする、無線通信装置でもよい。
一実装では、支払処理システムなどの支払処理システムは、支払端末２０を妥当性確認して、それが安全なセッションにおいてリーダ２２を介して支払オブジェクト１０とのトランザクションを行うことを可能にすることができる。このことのために、支払端末は支払処理システムから取得される（図１で述べた）証明チケット８５をその上に格納しており、証明チケットが有効である限り安全なセッションが有効である。証明チケット８５は寿命に関連付いており、その寿命の後に支払端末２０は証明チケットを再取得しなければならない。
一実施形態において、支払オブジェクト１０は、（例えば、支払オブジェクトリーダ２２を介して）支払端末２０と通信することができる、ＮＦＣデバイス１２またはＥＭＶチップカード１４などのデバイスでもよい。チップカード１４は、支払端末２０などの支払端末と通信し、暗号化された支払情報を生成し、１つ以上の電子支払標準、例えばＥＭＶＣｏによって広められるものに従って、暗号化された支払情報ならびに他の支払またはトランザクション情報（例えば、ローカルに処理される支払のためのトランザクション限度）を提供することができる安全な集積回路を含むことができる。チップカード１４は、支払オブジェクトリーダ２２と（例えば、ＩＳＯ７８１６に従って）通信するための接触ピンを含むことができて、一部の実施形態では近接場１５を介して支払オブジェクトリーダ２２に誘導結合されてもよい。支払オブジェクトリーダ２２に誘導結合されるチップカード１４は、ＩＳＯ１４４４３などの無線通信規格に従って支払オブジェクトリーダ２２によって提供される無線キャリア信号の負荷変調を用いて、支払オブジェクトリーダ２２と通信することができる。
ＮＦＣデバイス１２は、（例えば、支払オブジェクトリーダ２２との通信を介して）支払端末２０との安全なトランザクションに関わることができるスマートフォン、タブレットまたはスマートウォッチなどの電子デバイスでもよい。ＮＦＣデバイス１２は、安全なトランザクション機能を実行するためのハードウェア（例えば、ハードウェアおよび実行可能コードを含むセキュリティ要素）および／またはソフトウェア（例えば、ホストカードエミュレーションルーチンに従ってプロセッサ上で動作する実行可能コード）を有することができる。支払トランザクションの間、ＮＦＣデバイス１２は、近接場１５を介して支払オブジェクトリーダ２２に誘導結合されてもよく、ＩＳＯ１４４４３およびＩＳＯ１８０９２などの１つ以上の無線通信規格に従って、支払オブジェクトリーダ２２により提供される無線キャリア信号の能動型または受動型負荷変調によって、支払端末２０と通信することができる。
支払端末２０はいかなる好適な方法でも実装することができるが、一実施形態において、支払端末２０は支払オブジェクトリーダ２２および小売業者デバイス２９を含むことができる。小売業者デバイス２９は、ユーザインターフェースを小売業者に提供して、支払オブジェクトリーダ２２および支払サーバ４０との通信を容易にする販売時点アプリケーションを実行する。支払オブジェクトリーダ２２は、支払オブジェクト１０と小売業者デバイス２９の間の通信を容易にすることができる。本明細書において記載されているように、ＮＦＣデバイス１２またはチップカード１４などの支払オブジェクト１０は、誘導的結合を介して支払オブジェクトリーダ２２と通信することができる。これは近接場１５として図２において表され、それは支払オブジェクトリーダ２２から発される適切な周波数（例えば、１３．５６ＭＨｚ）を有する無線キャリア信号を含む。
一実施形態において、支払オブジェクト１０はＮＦＣデバイス１２またはチップカード１４などの非接触の支払デバイスでもよく、支払オブジェクトリーダ２２および非接触の支払オブジェクト１０は近接場１５の中で無線キャリア信号を変調することによって通信することができる。支払オブジェクト１０に情報を通信するために、支払オブジェクトリーダ２２は支払オブジェクトリーダ２２から送信されるデータに基づいて無線キャリア信号の振幅および／または位相を変更し、結果として支払デバイスに発信される無線データ信号になる。この信号は１３．５６ＭＨｚで伝送するために調整される支払オブジェクトリーダ２２のアンテナによって発信されて、支払オブジェクト１０が近接場１５の範囲（例えば、０〜１０ｃｍ）の中で最適に調整されたアンテナも有する場合、支払デバイスは支払オブジェクトリーダ２２によって送信される無線キャリア信号または無線データ信号を受信する。無線データ信号の場合、支払オブジェクト１０の処理回路は、受信信号を復調して、支払オブジェクトリーダ２２から受信されるデータを処理することが可能である。
支払オブジェクト１０などの非接触の支払デバイスが近接場１５の範囲の中にあるときに、それは支払オブジェクトリーダ２２に誘導結合される。したがって、支払オブジェクト１０も、能動型または受動型負荷変調を介して無線キャリア信号を変調することができる。支払オブジェクト１０のアンテナの同調特性を（例えば送信される変調データに基づいてアンテナ回路に並列負荷を選択的に切り替えることによって）変えることによって、無線キャリア信号は支払オブジェクト１０および支払オブジェクトリーダ２２の両方で修正され、結果として変調された無線キャリア信号になる。このようにして、支払デバイスは、支払オブジェクトリーダ２２に変調データを送信することができる。
一部の実施形態において、支払オブジェクトリーダ２２は、チップカード１４を受けることができるＥＭＶスロット２１も含む。チップカード１４は、チップカード１４がＥＭＶスロット２１に挿入されるときに支払オブジェクトリーダ２２の対応する接点によって係合する接点を有することができる。支払オブジェクトリーダ２２はこれらの接点を通してチップカード１４のＥＭＶチップに電力を供給して、支払オブジェクトリーダ２２およびチップカード１４は接点によって確定される通信路を通して通信する。
支払オブジェクトリーダ２２は、磁気ストリップカード（図２において表されない）とのインタフェーシングのためのハードウェアを含むこともできる。一部の実施形態において、ハードウェアは、磁気ストリップリーダが磁気ストリップカードから支払情報を受けることができるように、顧客が磁気ストリップカードの磁化ストリップを読み取るかまたは入れるのを案内するスロットを含むことができる。受け取った支払情報は、それから支払オブジェクトリーダ２２によって処理される。
支払端末２０（例えば、支払端末２０の支払オブジェクトリーダ２２）が支払デバイス１０と接続して支払情報を処理するので、支払端末２０は不正なトランザクションに関与するかまたは支払端末２０を改ざんする試みの主要な目標である。いくつかの攻撃者は受動型攻撃に関与することができて、そこで、それらはＮＦＣ通信を傍受することを試みるか、ＥＭＶカードとの物理接続を通じて伝送されているデータを読み込むか、または、従来の読み取りトランザクションの磁気ストライプからデータを傍受する。さらに、これおよび他の重要情報を搬送している信号は、支払オブジェクトリーダの中に送られて、支払オブジェクトリーダのプロセッサおよび他の回路によって処理される。それから、このような攻撃によって取得される情報は、多くの方法で、例えば支払情報を用いて、または、支払端末２０を通して不正なトランザクションに係わるために、支払端末２０に関する情報（例えば、認証データ、証明書情報または静的データ認証（ＳＤＡ）情報）を取得することによって、または、支払端末２０を模倣することによって購入をすることで不正なトランザクションに関与するために用いることができる。
攻撃者の中には、修正するか、注入するか、転送するかまたは、修正するためにデバイスまたは偽造カードを利用することを含むか、または支払オブジェクト１０と支払端末２０の間で交換される信号（例えば、メッセージ）を修正する攻撃に関与することができるものがある。このような攻撃の非限定的な例には、ｙｅｓ−ｃａｒｄ攻撃、再操作攻撃、操作前攻撃、ダウングレード攻撃、中継攻撃および中間者攻撃を含む。これらのデバイス、偽造カードおよび攻撃は、常に作り出され、更新され、修正されている。本明細書において記載されているように、一部の実施形態では、デバイスまたは偽造カードの存在を識別するか、または、支払端末２０とやりとりされているメッセージをモニタしてこれらのメッセージの特性（例えば、タイミング、信号波形など）をモニタすることによって、そして、支払端末２０の電気的特性または他のパラメータをモニタすることによって、攻撃が起こっていることを認識することができてもよい。一実装では、このような識別は、既存の証明チケット８５が無効にされるかまたは再生成されるのを起動することができる。
小売業者デバイス２９は、タブレット支払デバイス２４、モバイル支払デバイス２６または支払端末２８などのいかなる好適な装置であってもよい。タブレット支払デバイス２４またはモバイル支払デバイス２６などのコンピューティング装置の場合、販売時点アプリケーションは、購入および支払情報の入力、顧客とのインタラクションおよび支払サーバ４０との通信を提供することができる。例えば、支払アプリケーションは、小売業者が選択することが可能であるサービスのメニューおよび、トランザクションを自動化するための一連のメニューまたはスクリーンを提供することができる。支払アプリケーションは、署名、ＰＩＮ番号または生体情報などの顧客認証情報の入力を容易にすることもできる。同様の機能性を、専用の支払端末２８に追加することもできる。
小売業者デバイス２９は、通信経路２３／２５／２７を介して、支払オブジェクトリーダ２２と連絡してもよい。通信経路２３／２５／２７は有線（例えば、Ｅｔｈｅｒｎｅｔ、ＵＳＢ、ＦｉｒｅＷｉｒｅ、ライトニング）または無線（例えば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣまたはＺｉｇＢｅｅ）接続を介して実装することができるが、一実施形態においては、支払オブジェクトリーダ２２はＢｌｕｅｔｏｏｔｈ ｃｌａｓｓｉｃまたはＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙインターフェースを介して小売業者デバイス２９と通信することができる。一部の実施形態において、支払トランザクションの処理は、例えばトランザクション量が少ないか、または、支払サーバ４０への接続性がないときには、支払オブジェクトリーダ２２および小売業者デバイス２９にローカルに起こってもよい。他の実施形態において、小売業者デバイス２９または支払オブジェクトリーダ２２は、公共であるか専用の通信ネットワーク３０を介して、支払サーバ４０と通信することができる。通信ネットワーク３０はいかなる適切な通信ネットワークであってもよいが、一実施形態において、通信ネットワーク３０はインターネットであってもよく、支払およびトランザクション情報は、ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ（ＴＬＳ）またはｓｅｃｕｒｅ ｓｏｃｋｅｔｓ ｌａｙｅｒ（ＳＳＬ）プロトコルなどにより暗号化されたフォーマットで。支払端末２０と支払サーバ４０の間で通信することができる。
図３は、本開示のいくつかの実施形態による例示的な支払いオブジェクトリーダ２２のブロック図を表す。一実施形態において、支払オブジェクトリーダ２２は、例えば、対話式の電子デバイス（例えば小売業者デバイス２９）がＢｌｕｅｔｏｏｔｈ ｃｌａｓｓｉｃまたはＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙを使用して無線で通信する無線通信装置でもよい。図３において特定の部品が特定の配置で表されるが、支払オブジェクトリーダ２２が追加コンポーネントを含むことができ、図３において表される１つ以上のコンポーネントは支払オブジェクトリーダ２２に含まれなくてもよく、支払オブジェクトリーダ２２のコンポーネントはいかなる好適な方法でも再編成することができるということが理解されよう一実施形態において、支払オブジェクトリーダ２２は、リーダチップ１００、複数の支払インターフェース（例えば、ＮＦＣインターフェース１０２および接触インターフェース１０４）、電源１０６、無線通信インターフェース１０８および有線インターフェース１１０を含む。支払オブジェクトリーダは、処理ユニット１２０およびメモリ１２２も含む。一実施形態で処理ユニット１２０およびメモリ１２２はリーダチップ１００にパッケージ化されて特定の方法で構成されるとして記載されるが、本明細書において記載されていているように、処理ユニット１２０およびメモリ１２２が支払オブジェクトリーダ２２の機能性を実行するいかなる好適な方法でも構成され得ることが理解されよう。リーダチップ１００の機能性が複数のチップで実施されることができ、各々が処理ユニットおよびメモリのいかなる好適な組合せも含んで集合的に、本明細書において記載されているリーダチップ１００の機能性を実行することも理解されよう。
支払オブジェクトリーダは複数のモニタリングコンポーネントを含むこともでき、コンポーネントのそれぞれは、支払オブジェクトリーダ２２の１つ以上のコンポーネントと関連付けられてそれをモニタする。特定のモニタリングコンポーネントは本開示の特定の実施形態に関して記載され得るが、モニタリングコンポーネントが、支払オブジェクトリーダ２２のコンポーネントに関する情報をモニタするのに必要ないかなる適切な機械的コンポーネント、センサ、スイッチ、ハードウェア、処理ユニットまたは他のいかなる適切なコンポーネントも含むことができることが理解されよう。モニタリングコンポーネントはが支払オブジェクトリーダ２２のいかなる適切なコンポーネントとも関連付けられてもよいが、一部の実施形態では、ＮＦＣモニタリングコンポーネント１４２はＮＦＣインターフェース１０２と関連付けられてもよく、接触モニタリングコンポーネント１４４は接触インターフェース１０４と関連付けられてもよく、電源モニタリングコンポーネント１４６は電源１０６と関連付けられてもよく、そしてチップカード検出コンポーネント１４８は接触インターフェース１０４と関連付けられてもよい。
支払オブジェクトリーダ２２のリーダチップ１００の処理ユニット１２０は、支払オブジェクトリーダ２２の機能を実行して制御するのに必要であるような、任意の適切なハードウェア、ソフトウェア、メモリおよび回路を含むこともできる。処理ユニット１２０は、リーダチップ１００のメモリ１２２に格納された命令を実行して支払オブジェクトリーダ２２の動作および処理を制御することができる。本明細書において使用する場合、プロセッサまたは処理ユニットは、ハードウェアロジック（例えば、ハードウェア記述言語（ＨＤＬ）ソフトウェアなどのハードウェアの構成を記載するソフトウェアによって設計したハードウェア）、プロセッサ上で実行するコンピュータ可読命令、またはそれらのいかなる好適な組合せも含むがこれに限らない、本明細書において記載されている処理機能を実行するのに必要な処理能力を有する、１つ以上のプロセッサを含むことができる。プロセッサは、有形の非一時的計算機可読の記憶媒体上の機械可読形式でアクセスされるソフトウェアを含むソフトウェアを実行して、本明細書において記載されている動作を実行することができる。
例示的な実施形態において、リーダチップ１００の処理ユニット１２０は、一般の処理および暗号プロセシングファンクションを、それぞれメモリ１２２に格納される命令に基づいて実行するように構成される２つのＲＩＳＣプロセッサを含むことができる。本明細書において使用する場合、メモリは、有形であるか非一時的記憶媒体を指すことができる。有形の（または非一時的）記憶媒体の例には、ディスク、サムドライブおよびメモリ、その他を含むが、伝達される信号は含まない。有形の計算機可読の記憶媒体は、揮発性および不揮発性、着脱可能なおよび取り外し不可能な媒体、例えばコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを含む。このような媒体の例には、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ディスクもしくは光記憶装置、磁気記憶装置またはプロセッサもしくはコンピューティング装置によってアクセスされる情報を記憶する他のいかなる非一時的媒体も含む。
リーダチップ１００は、インターフェース回路構成、アナログフロントエンド回路、セキュリティ回路およびモニタリングコンポーネント回路などの追加的な回路を含むこともできる。一実施形態において、インターフェース回路は、無線通信インターフェース１０８（例えば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ ｃｌａｓｓｉｃおよびＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ）とのインタフェーシングのための回路、有線インターフェース１１０（例えば、ＵＳＢ、Ｅｔｈｅｒｎｅｔ、ＦｉｒｅＷｉｒｅおよびライトニンフ）とのインタフェーシングのための回路、他の通信インターフェースまたはバス（例えば、Ｉ２Ｃ、ＳＰＩ、ＵＡＲＴおよびＧＰＩＯ）とのインタフェーシングのための回路、電源１０６（例えば、電力管理回路、電力変換回路、整流器およびバッテリ充電回路）とのインタフェーシングのための回路および接触インターフェース１０４（例えば、スロット２１に挿入されるチップカード１４のＥＭＶチップとの直接的インタフェーシングのための電源および通信回路）とのインタフェーシングのための回路を含むことができる。
一実施形態において、リーダチップ１００のアナログフロントエンド回路は、ＮＦＣインターフェース１０２（例えば、電磁場適合性（ＥＭＣ）回路、整合回路、変調回路および計測回路）のアナログコンポーネントとのインタフェーシングのための回路を含む。
リーダチップ１００のセキュリティ回路は、暗号鍵、小売業者情報および顧客情報などの機密情報を保護するための回路、ならびに不正なトランザクションおよび改ざんの試みに（例えば、修正処置をすることによって）応じるための回路を含むことができる。一実施形態において、セキュリティ回路は、リーダチップ１００に対する不適当なアクセスを取得し、支払オブジェクトリーダ２２を改ざんし、または不正なトランザクションに関与する試みに応答して、リーダチップ１００の１つ以上のコンポーネントを選択的に電源切断するかまたは無効にするための改ざん防止回路および電子ヒューズを含むことができる。セキュリティ回路は、コンポーネントから、または無効にされるコンポーネントに対して、電力が除去されるようにすることができる。電源の除去またはコンポーネントの無効化は永続的でもよくまたは一時的でもよく、それはセキュリティ脅威の重大度に基づいて変更することができる。一部の実施形態において、セキュリティ回路は電気信号を支払オブジェクトリーダ２２のコンポーネントに提供する回路を含むことができる。電気信号は、支払オブジェクトリーダ２２のコンポーネントによって特定の応答（例えば、情報の消去、コンポーネントの一時的な無効化、コンポーネントの動作の修正、または任意の他の適切な応答をさせること）を引き起こすためか、または、支払オブジェクトリーダ２２に連結されるか、あるいはそれと通信するデバイスまたはコンポーネントに衝撃を与えるために、提供することができる。例えば、一実施形態で、電気信号（例えば、特定の電圧、電流、波形などを有する信号）は、支払情報を傍受するかまたは支払オブジェクトリーダ２２に信号を注入することを試みているデバイス（例えば、接触インターフェース１０４に結合された不正なＥＭＶカードまたは改ざんデバイス）に損傷を引き起こすために、提供することができる。セキュリティ回路は、あり得る改ざんの試みまたは不正なトランザクションが検出されると機密情報に消去、暗号化、難読化または他の動作を引き起こす回路を含むこともできる。
一実施形態において、モニタリングコンポーネント回路は、モニタリングコンポーネント、（例えば、モニタリングコンポーネント１４２、１４４、１４６および１４８）のいずれか、例えば、信号調整回路、制御回路、アナログデジタル変換回路、デジタルアナログ変換回路、インダクタンスまたは容量測定のための回路、タイミング測定回路、他の任意の適切な回路、またはそれらの任意の組み合わせとの、インタフェーシングのための回路を含むことができる。
ＮＦＣインターフェース１０２は、ＮＦＣデバイス１２またはチップカード１４などの非接触デバイスとのＮＦＣ通信を提供することができる。リーダチップ１００により提供される信号に基づいて、ＮＦＣインターフェース１０２のアンテナは、キャリア信号または被変調信号のいずれかを出力することができる。キャリア信号は、１３．５６ＭＨＺなどの固定周波数を有する信号でもよい。被変調信号は、ＩＳＯ１４４４３およびＩＳＯ１８０９２などの変調手順に従うキャリア信号の変調されたバージョンでもよい。支払オブジェクトリーダ２２が非接触デバイスに誘導結合されているときに、非接触デバイスはキャリア信号を変調することもでき、そしてそれはＮＦＣインターフェース１０２によって検出されて、処理のためにリーダチップ１００に提供することができる。キャリア信号のこれらの変調に基づいて、支払オブジェクトリーダ２２および非接触デバイスは、支払情報などの情報を通信することが可能である。
ＮＦＣモニタリングコンポーネント１４２は、ＮＦＣインターフェース１０２のいかなる適切な電気的特性もモニタすることができる。一部の実施形態において、ＮＦＣモニタリングコンポーネント１４２は、リーダチップ１００、ＮＦＣインターフェース１０２に近接しているデバイスに関する情報を判定するための回路（例えば、センサ）、ＮＦＣインターフェースに関連した測定値（例えば、信号対雑音比、変調比、エネルギーレベルなど）を提供するための回路（例えば、センサ）、他のあらゆる適切なモニタリングコンポーネント、またはそれらの任意の組み合わせに対して、直接１つ以上のアナログ信号を提供する信号経路を設けることができる。ＮＦＣインターフェース１０２のこれらのモニタされた状況は、支払情報が交換されている最中のＮＦＣインターフェース１０２に近接した不適切なデバイスの存在、無線キャリア信号の異常な変調、またはＮＦＣインターフェース１０２をバイパスするかまたは改ざんする試みなどの、攻撃を表す情報を提供することができる。
接触インターフェース１０４は、電力をチップカード１４のＥＭＶチップなどの支払チップへ供給しそしてＥＭＶチップと通信するための適切なインターフェースであることができる。接触インターフェース１０４は、ＥＭＶ仕様に従ったチップカード１４との物理的インタフェーシングのための複数の接続ピン（図３において表さず）を含むことができる。一部の実施形態において、接触インターフェース１０４は、電源（ＶＣＣ）ピン、グラウンド（ＧＮＤ）ピン、ＥＭＶカードをリセットするためのリセット（ＲＳＴ）ピン、クロック信号を提供するためのクロック（ＣＬＫ）ピン、プログラミング電圧をＥＭＶカードへ供給するためのプログラミング電圧（ＶＰＰ）ピン、ＥＭＶ通信を提供するための入出力（Ｉ／Ｏ）ピンおよび２つの補助ピンを含むことができる。このようにして、支払オブジェクトリーダおよびチップカードは、支払情報などの情報を交換することが可能である。
接触モニタリングコンポーネント１４４は、接触インターフェース１０４のいかなる適切な電気的特性もモニタすることができる。一部の実施形態において、接触モニタリングコンポーネント１４４は、リーダチップ１００に対して、例えば接触インターフェースのピンの１つ以上から、直接１つ以上のアナログ信号（例えば、接触インターフェース１０４の入出力ピンで見られる信号のアナログバージョン）を提供する信号経路を設けることができる。接触モニタリングコンポーネント１４４は、接触インターフェースに関連した測定値（例えば、接触インターフェース１０４のピンの１つ以上での電圧、電流、容量、インダクタンスまたは他のあらゆる適切な電気測定値）、他の任意の適切なモニタリングコンポーネントまたはそれらの任意の組み合わせを提供するための回路（例えば、センサ）を含むこともできる。接触インターフェース１０４のこれらのモニタされた状況は、ＥＭＶスロット２１への偽造カードの挿入（例えば、接触インターフェース１０４の１つ以上のピンで測定された電気的特性に基づく）、接触インターフェース１０４を介して（例えば、入出力ピン上で）正当なチップカードと交換される情報を傍受している不適切なデバイスの存在、またはＥＭＶカードをシミュレーションするデバイスの使用（例えば、Ｉ／Ｏライン上の異常な波形に基づく）などの、攻撃を表す情報を提供することができる。
チップカード検出コンポーネント１４８はまた、接触インターフェース１０４と関連付けられてもよく、チップカードがいつＥＭＶスロット２１に挿入されるかを判定するための電気および機械的コンポーネントを提供することもできる。一部の実施形態において、チップカード検出コンポーネント１４８は、ＥＭＶカード物理仕様（例えば、サイズ、厚さなど）を満たしているチップカードがＥＭＶスロット２１に挿入されるときに起動する、１つ以上の機械的デバイス（例えば、スイッチ）を含むことができる。一部の実施形態において、チップカード検出コンポーネント１４８は、挿入されたカードの物理構造（例えばサイズまたは材料）に関する情報を検出する１つ以上のセンサを含むことができる。一部の実施形態において、チップカード検出コンポーネント１４８は、挿入されたカードのＥＭＶチップに関する情報を提供する１つ以上の電気ラインまたはセンサを含むことができるか、または、いくつかの実施形態においては、測定された電気信号がＥＭＶ仕様に対応しないときに、異なる方法で反応することができる。他のいかなる適切なチップカード検出コンポーネント１４８も本開示に従って利用することができて、様々なタイプのチップカード検出コンポーネント１４８が組み合わせて使用可能であることが理解されよう。
電源１０６は、１つ以上の電源、例えばＡＣ電源またはバッテリ対する物理接続を含むことができる。電源１０６は、支払オブジェクトリーダ２２のコンポーネントによる使用のためにＡＣ電源を変換して複数の直流電圧を発生させる電力変換回路を含むことができる。電源１０６がバッテリを含むときに、バッテリは物理電力接続を介して、誘導充電を介して、または、他の任意の好適な方法を介して充電することができる。
電源モニタリングコンポーネント１４６は、電源１０６のいかなる適切な電気的特性もモニタすることができる。一部の実施形態において、電源モニタリングコンポーネント１４６は、リーダチップ１００に対して、例えば電源１０６の電源入力、バッテリ、充電回路、電力変換回路または他の任意の適切なコンポーネントから、直接１つ以上のアナログ信号を提供する信号経路を設けることができ。電源モニタリングコンポーネント１４６は、電源１０６に関連した測定値を提供するための回路（例えば、センサ）を含むこともできる。これらのモニタされた電源信号は、電源への接続の異常パターンまたは電源使用パターンなどの、攻撃を表す情報を提供することができる。
無線通信インターフェース１０８は、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ ｃｌａｓｓｉｃまたはＢｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙなどの無線通信プロトコルを使用して外部電子デバイスと通信するための、ハードウェアおよびソフトウェアを含むことができる。一部の実施形態において、無線通信インターフェース１０８は、支払オブジェクトリーダが小売業者デバイス２９および支払サーバ４０の一方または両方と通信することを可能にすることができる。
有線インターフェース１１０は、ＵＳＢ、ライトニング、ＦｉｒｅＷｉｒｅ、Ｅｔｈｅｒｎｅｔ、他のあらゆる適切な有線通信インターフェースまたはそれらのあらゆる組み合わせなどの、他のデバイスまたは通信ネットワークとの有線通信のためのいかなる適切なインターフェースも含むことができる。一部の実施形態において、有線インターフェース１１０は、支払オブジェクトリーダが小売業者デバイス２９および支払サーバ４０の一方または両方と通信することを可能にすることができる。
メモリ１２２は支払オブジェクトリーダ２２の処理操作を実行するための複数のセットの命令、例えば動作命令１３０、トランザクション処理命令１３２、暗号命令１３４、無線通信命令１３６および証明ルーチン１３８を含むことができて、そこでは、証明ルーチン１３８は支払処理システム５０のような支払処理システムから取得される。図３において表されないが、一部の実施形態では、暗号命令１３２、暗号鍵、パスワードおよび他の類似の情報などの機密情報は、他の命令および記憶とは論理的および物理的に異なったメモリに格納することができる。メモリ１２２またはその一部は、プロセッサ（例えばＲＩＳＣプロセッサ）と関連付けられてもよく、また特定のハードウェアロジック、例えば電子ヒューズと関連したハードウェアロジック、改ざん防止回路および暗号操作と関連付けられてもよい。
動作命令１３０は、内部通信、電源管理、メッセージの処理、システムモニタリング、スリープモード、ユーザインターフェース応答およびコントロールならびに他のセットの命令の管理などの、支払オブジェクトリーダ２２のあらゆる適切な一般の動作も制御するための命令を含むことができる。一実施形態において、動作命令１３０は、支払オブジェクトリーダ２２のリーダチップ１００の処理ユニット１２０によって実行される大部分の処理操作を実行するのに必要なオペレーティングシステムおよびアプリケーションを提供することができる。
加えて、動作命令１３０は、支払オブジェクトリーダ２２と支払オブジェクト１０の間の（例えば、ＮＦＣインターフェース１０２および接触インターフェース１０４を介した支払デバイスとのインタフェーシングのための）インタラクションを制御するための命令を含むことができる。一実施形態において、動作命令は、無線キャリア信号を生成し、無線キャリア信号をＮＦＣインターフェース１０２に（例えば、アナログフロントエンド回路を介して）提供し、通信プロトコルに従って送信されるデータに基づいて無線キャリア信号を変調し、ＮＦＣインターフェース１０２から（例えば、アナログフロントエンド回路を介して）変調された無線キャリア信号を受信し、通信プロトコルに従って受信した変調された無線キャリア信号を復調し、復調された信号から受信データを判定するための命令を含むことができる。動作命令１３０は、接触インターフェース１０４のＩ／Ｏラインを通してチップカード１４と通信するための命令を含むこともできる。
動作命令１３０は、小売業者デバイス２９と対話するための命令を含むこともできる。一実施形態において、小売業者デバイス２９は、販売時点アプリケーションを実行していてもよい。動作命令１３０は、情報を販売時点アプリケーションと交換するために、リーダチップ１００の処理ユニット１２０で実行する補完的なアプリケーションのための命令を含むことができる。例えば、販売時点アプリケーションは、小売業者などのユーザが顧客との購入トランザクションに関わるのを容易にするユーザインターフェースを提供することができる。メニューは、項目、税金の算出、チップの追加および他の関連した機能性の選択を提供することができる。支払を受領する時になると、販売時点アプリケーションは支払オブジェクトリーダ２２に（例えば、無線命令１３６に基づいて無線インターフェース１０８を介して）メッセージを送ることができる。動作命令１３２は、例えば、ＮＦＣインターフェース１０２または接触インターフェース１０４を介して支払情報を取得してトランザクション処理命令１３２および暗号の命令１３４を呼び出してその支払情報を処理することによって、そして、無線命令１３６に基づいて無線インターフェース１０８を介して小売業者デバイスの販売時点アプリケーションに送信される応答メッセージを生成することによって、支払の処理を容易にする。
動作命令１３０は、支払サーバ４０で支払処理システム５０と対話するための命令を含むこともできる。一実施形態において、支払処理システム５０は、支払オブジェクトリーダ２２および小売業者デバイス２９の販売時点アプリケーションと関連付けられてもよい。例えば、支払処理システム５０は、支払処理システム５０に（例えば、一意の識別子に基づいて）登録される支払オブジェクトリーダ２２および小売業者デバイス２９に関する情報を有することができる。この情報を用いて、分析および報告を小売業者に提供してトランザクションデータを集約するために、小売業者および顧客金融機関のサーバとのトランザクションを処理することができる。支払オブジェクトリーダ２２は支払情報を（例えば、トランザクション処理命令１３２および暗号の命令１３４に基づいて）処理することができ、その処理された支払情報を販売時点アプリケーションに通信することができて、次にそれが支払処理システム５０と通信する。このようにして、支払オブジェクトリーダ２２からのメッセージは、支払サーバ４０の支払処理システム５０に転送されることができ、その結果、（支払オブジェクトリーダ２２および支払処理システム５０が集合的に支払トランザクションを処理することができる。一部の実施形態において、動作命令は、（例えば、証明ルーチン１３８に基づいて）支払処理システム５０についての不正および改ざんに関連したメッセージの通信を容易にすることができる。このようにして、支払オブジェクトリーダ２２および支払処理システム５０は、対話することができて、不正なトランザクションおよび改ざんの試みが起こっているかどうかを判定し、不正なトランザクションおよび改ざんの試みに応答して修正処置を決定し、支払処理システム５０の（例えば、不正なトランザクションおよび改ざんの試みを識別するための情報をコンパイルした）トランザクションデータベースを更新して、支払オブジェクトリーダ２２により用いられるローカルテスト基準に関する更新を通信する。
トランザクション処理命令１３２は、支払オブジェクトリーダ２２での処理支払トランザクションのための命令を含むことができる。一実施形態において、トランザクション処理命令は、ＥＭＶによって広められているような支払標準に準拠することができる。用いられている支払方法（例えば、Ｅｕｒｏｐａｙ、Ｍａｓｔｅｒｃａｒｄ、Ｖｉｓａ、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓなど）に応じて、支払方法と関連した特定の処理手順を選択することができ、トランザクションはその手順に従って処理することができる。処理ユニット１２０によって実行されると、これらの命令は、ローカルにトランザクションを処理するべきかどうか、支払情報が支払デバイスからどのようにアクセスされるか、その支払情報はどのように処理されるか、どの暗号関数を実行するか、支払サーバと交換するための通信のタイプ、および支払トランザクションの処理と関連した他のあらゆる適切な情報を決定することができる。
暗号命令１３４は、暗号操作を実行するための命令を含むことができる。処理ユニット１２０は、暗号命令を実行して、支払トランザクションの一部として暗号化し、解読し、署名し、または支払時の署名およびトランザクション情報を検証することなどの、様々な暗号関数を実行することができる。無線通信命令１３６は、対話式の電子デバイス（例えば、小売業者デバイス２９）などの他のデバイスと無線で通信するための命令を含むことができる。無線通信命令１３６はいかなる適切な無線通信頼インターフェース１０８に対しても用いることができるが、一実施形態において、無線通信インターフェース１０８はＢｌｕｅｔｏｏｔインターフェース（例えば、Ｂｌｕｅｔｏｏｔｈ ｃｌａｓｓｉｃ、Ｂｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙまたはその両方）であってもよく、無線通信命令１３６はＢｌｕｅｔｏｏｔｈインターフェースの動作に対するものであってもよい。処理ユニット１２０は無線通信命令１３６を実行して、メッセージを（例えば、ブロードキャストまたは接続モードにおいて）送受信して、小売業者デバイス２９と通信することができる。
証明ルーチン１３８は、支払処理システム５０のような支払処理システムから取得されるものであって、支払オブジェクトリーダ２２などの支払端末２０上での不正なトランザクション、改ざんの試みおよびその他の攻撃を識別するための命令を含むことができる。証明ルーチン１３８は処理ユニット１２０によって実行されるときにいかなる適切な動作も実行することができるが、一部の実施形態で、不正改ざん命令は、モニタリングコンポーネント（例えば、モニタリングコンポーネント１４２、１４４、１４６および１４８）を操作することができ、モニタリングコンポーネントから受信するモニタリング信号を処理することができ、支払デバイスと交換されるメッセージをモニタすることができ、不正または改ざんに対してテストするために要求メッセージを送信することができ、要求メッセージに応答して受け取られる応答メッセージを処理することができ、ローカルテスト基準に基づいて不正または改ざんを識別することができ、不正または改ざんに関する情報を支払サーバ４０（例えば、支払処理システム５０）に伝達することができ、支払サーバ４０（例えば、支払処理システム５０）から不正の判定メッセージを受信することができ、ローカルテスト基準および不正の判定メッセージに基づいて修正処置をすることができる。
一部の実施形態において、証明ルーチン１３８は、モニタリングコンポーネント（例えば、モニタリングコンポーネント１４２、１４４、１４６および１４８）を操作するための命令を含むことができる。本明細書において記載されているように、様々なタイプのモニタリングコンポーネントを本開示に従って利用することができる。証明ルーチン１３８は、リーダチップ１００のモニタリングコンポーネント回路に提供される信号を制御するための命令を提供することができ、例えば、電力、テスト信号および他の適切な信号をモニタリングコンポーネントに提供する。一部の実施形態において、証明ルーチン１３８は、１つ以上のモニタリングコンポーネントとの通信を制御する命令を提供することができて、制御メッセージを提供し、データを受信し、またはモニタリングコンポーネントについて他のいかなる適切な機能も実行する。一部の実施形態において、モニタリングコンポーネントを操作することは、モニタリングコンポーネントの１つ以上に対してテスト信号またはテスト波形などの信号を提供することを含むことができる。例えば、一実施形態において、テスト波形は、モニタリングコンポーネント１４４を介して接触インターフェース１０４のＩ／Ｏラインに提供することができる。
一部の実施形態では、証明ルーチン１３８は、モニタリングコンポーネントから受信したモニタリング信号を処理するよう命令を提供してもよい。モニタリング信号は、リーダチップ１００においてアナログ信号、デジタル信号、およびデータ信号を含む様々な形態で受信され得る（例えば、モニタリングコンポーネント回路を介して）。証明ルーチン１３８は、処理ユニット１２０が、受信したモニタリング信号から有用なデータを抽出するよう命令を提供し得る。一部の実施形態では、有用なデータを抽出することは、監視された信号の一部の態様、例えば、電圧、電流、インピーダンス、静電容量、電力、エネルギー、波形状等を測定することを含み得る。一実施形態では、接触モニタリングコンポーネント１４４は、接触インターフェース１０４のＩ／Ｏライン上でアナログ信号を受信および監視してもよく、そうして、ＥＭＶ通信中にリーダチップ１００によって伝送される出力信号、および接触インターフェース１０４を介して受信される入力信号を監視する。一部の実施形態では、監視された信号は、デジタルであってもよく、あるいは、アナログデジタル変換器によってデジタル信号に変換されてもよい。一部の実施形態では、証明ルーチン１３８は、データを交換することによって、例えば、データラインまたは通信バスにおいてセンサなどのモニタリングコンポーネントと通信することで、モニタリングコンポーネントと通信するための命令を提供してもよい。
一部の実施形態では、証明ルーチン１３８は、支払オブジェクト１０と交換されるメッセージを監視するよう命令を提供してもよい。例えば、メッセージは、ＮＦＣインターフェース１０２または接触インターフェース１０４を介して支払デバイスと交換され得る。本明細書に記載するように、処理ユニット１２０が、これらのメッセージを生成および受信してもよく、また、証明ルーチン１３８が、これらのメッセージおよび、これらのメッセージの態様、例えばそれらのコンテンツ、シーケンス、およびタイミングを監視するための命令を含んでもよい。一部の実施形態では、メッセージを、一つ以上のモニタリングコンポーネントから受信した情報と共に監視してもよい。例えば、接触インターフェース１０４を介してＩ／Ｏラインで送受信されるメッセージのタイミングは、接触モニタリングコンポーネント１４４から受信する監視された信号に基づいて判定されてもよい。
一部の実施形態では、証明ルーチン１３８は、不正または改ざんをテストする要求メッセージを送信するよう命令を提供してもよい。単に支払トランザクション中の通常のメッセージフローを監視するのではなく、証明ルーチン１３８は、リーダチップ１００が、改ざんデバイスおよび偽造カードをテストするのに用いられる要求メッセージを送信するための命令を提供し得るが、改ざんデバイスおよび偽造カードは、非定型メッセージに応答するのに際して、適切に機能しているカードとは異なった応答をし得る。一部の実施形態では、追加的なメッセージ（例えば、エラー条件テスト要求）が支払デバイスと支払オブジェクトリーダとの間で支払情報を交換するための通常のメッセージスキームに挿入されてもよい。別の実施形態では、メッセージプロトコル（例えば、エラー条件テスト要求）に準拠しないメッセージが支払オブジェクト１０に伝送されてもよい。危険にさらされていないＥＭＶカードは、例えば、カード発行者または製造者に基づいて、既知の動作をとり得る。
一部の実施形態では、メッセージが、支払デバイスの下位の回路の機能をテストするために送信されてもよい。例えば、多数の要求（例えば、乱数テスト要求）が、乱数を含む情報に対してなされ得る。その後結果を、ランダム性についてテストし得る。別の非制限的な実施例として、チップカードの処理速度および能力をテストし得る、多数の要求（例えば、メッセージタイミングテスト要求）が連続してなされてもよく、異常な結果は、偽造カード、あるいは改ざんデバイスに対応する可能性が高い。
一部の実施形態では、証明ルーチン１３８は、要求メッセージに応答して受信した応答メッセージを処理するよう命令を提供してもよい。例えば、応答メッセージは、タイムスタンプに関連付けられ得る（例えば、モニタリングコンポーネントによって取得されたデータに基づいて、あるいは、メッセージコンテンツによって、または処理ユニット１０２によって確立されるタイミングに基づいて）。一部の実施形態では、乱数などのデータがメッセージから抽出されてもよく、あるいは、応答メッセージが要求メッセージに関連付けられてもよい。
一部の実施形態では、証明ルーチン１３８は、ローカルテスト基準に基づいて不正または改ざんを識別するよう命令を提供してもよい。不正または改ざんは、任意の適切な情報に基づいて識別され得るが、一部の実施形態では、不正または改ざんは、モニタリングコンポーネントから取得された監視された信号、監視された応答、監視されたタイミング、トランザクション情報、支払情報、またはそれらの任意の組み合わせに基づいて識別され得る。ローカルテスト基準は、支払オブジェクト１０とインターフェースしているのと同一の支払端末２０においてローカルで実行する（例えば、ＮＦＣデバイス１２またはチップカード１４とインターフェースする支払オブジェクトリーダ２２において）のに利用可能な閾値または論理テストなどの基準とし得る。ローカルテスト基準は、支払サーバ４０（例えば、支払処理システム５０）などの別のデバイスと通信する必要なく、支払端末が特定のタイプの不正トランザクションおよび改ざんの試みに迅速に応答することを可能にし得る。
一部の実施形態では、ローカルテスト基準は更新されてもよい（例えば、支払端末２０の一部へのメモリデバイスの挿入、ネットワークでの更新メッセージの受信、または、更新を提供する任意のその他の適切な方法によって）。処理ユニット１２０は、更新を受信し、そして、証明ルーチン１３８を変更することでローカルテスト基準を更新し得る。ローカルテスト基準はまた、ローカル条件に基づいて変化し得るが、ローカル条件は、任意の適切な入力（例えば、ネットワーク接続の時間、位置、有無等）に基づいて判定され得る。例えば、ローカルテスト基準は、支払端末２０がネットワークに接続されておらず、そのため支払サーバ４０と通信して不正判定メッセージを受信できない場合に変更（例えば、強化）され得る。
例示的なローカルテスト基準の一つはタイミングテストとし得るが、これは、支払端末２０と支払オブジェクト１０との間で交換されるメッセージ（例えば、ＥＭＶプロトコルまたは特定の応答のタイミングをテストすることを企図するメッセージタイミング要求に従って交換されるメッセージ）のタイミングに基づき得る。改ざんデバイスまたは偽造カードは、製造の結果として、または攻撃（例えば、リレー攻撃）の結果として、通常のタイミングパターン内で応答しない場合がある。本明細書に記載するように、タイミングについての情報は、例えば、モニタリングコンポーネントからの監視されたタイミングに基づいて取得され得る。タイミングテストは、様々な方法で行われ得る。一部の実施形態では、特定の応答メッセージ（例えば、EMVプロトコルにおける、初期応答（ＡＴＲ）メッセージ、認証要求暗号文（ＡＲＱＣ）メッセージ等）を受信する時間が、一の範囲または閾値と比較され得る。タイミングが該範囲内とならない、あるいは閾値に満たない場合、タイミングテストは、失敗として登録し得る。一部の実施形態では、メッセージタイミングのその他の態様、例えば、カードが異なるメッセージタイプを送信するのにかかる相対時間、トランザクションを処理する全体時間等が考慮されてもよい。
別の例示的なローカルテスト基準は、エラー条件テストとし得る。本明細書に記載するように、一部の実施形態では、エラー条件テスト要求が伝送されてもよく、応答のタイミングおよびコンテンツが監視されてもよい。改ざんデバイスまたは偽造カードは、実際のチップカードとは異なってエラー条件テスト要求に応答する場合がある。一部の実施形態では、監視された応答へのタイミングが、一の範囲または閾値と比較されてもよく、応答または応答のセットのコンテンツが論理テストに照らしてチェックされてもよく、あるいは、これらおよびその他の技術の任意の組み合わせを使用してエラー条件テストを行ってもよい。例示的なエラー条件テストは、応答メッセージが受信されたかどうかを調べるためにチェックし、受信の時間が閾値を超えるか否かを判定し、そして予期される応答コンテンツに照らして応答コンテンツをチェックし得る。
別の例示的なローカルテスト基準は、ランダム値テストとし得る。改ざんデバイスまたは偽造カードは、乱数、ならびに実際のチップカードを生成しない場合がある。本明細書に記載するように、一部の実施形態では、支払端末２０（例えば、支払オブジェクトリーダ２２のリーダチップ１００）は、乱数テスト要求を支払デバイスに伝送し（例えば、チップカード１４、支払オブジェクトリーダ２２の接触インターフェース１０４を介して）、そして応答を受信し得る。乱数または乱数に基づくその他の情報が、応答から抽出されてもよい。統計的テストが受信した乱数に行われてこれらが実際にランダムである可能性が高いか否か、あるいは、応答の値がランダムでない確率が高いか否かを判定してもよい。
別の例示的なローカルテスト基準は、電気的特性テストとし得る。改ざんデバイスまたは偽造カードは、支払端末２０（例えば、支払オブジェクトリーダ２２）の電気信号に影響を与える場合があり、あるいは、予期される電気信号とは異なる電気信号を生成する場合がある。例えば、接触インターフェース１０４のいずれかのピン（例えば、ＶＣＣピン、ＧＮＤピン、ＲＳＴピン、ＣＬＫピン、ＶＰＰピン、およびＩ／Ｏピン）の電気的特性（例えば、電圧、電流、インピーダンス、静電容量、電力、エネルギー）は、接触モニタリングコンポーネント１４４などのモニタリングコンポーネントから判定され得る。一部の実施形態では、テスト波形がこれらのピンの一つ以上に伝送されてもよい。一つ以上の電気的特性が一の範囲または閾値と比較されてもよく、一部の実施形態では、電気的特性から統計が計算されてもよい。比較または統計は、不正または改ざんの試みを識別するのに使用され得る。例えば、一実施形態では、接触モニタリングコンポーネント１４４は、接触インターフェース１０４のＩ／Ｏラインを監視し得る。接触モニタリングコンポーネント１４４によって提供されるアナログモニタリング信号は、デジタル信号に変換されてもよい（例えば、アナログデジタル変換器を使用して）。リーダチップ１００の処理ユニット１２０は、証明ルーチン１３８からの範囲または閾値に基づいてデジタル化されたＩ／Ｏライン信号の波形（例えば、形状、デューティサイクル、立ち上がり時間、立ち下がり時間、周波数、位相、等）を分析して、接触インターフェースにおいて偽造カードあるいは改ざんデバイスがある可能性が高いか否かを判定してもよい。
別の例示的なローカルテスト基準は、カード挿入テストとし得る。不正トランザクションまたは改ざんの試みの間、改ざんデバイスまたは偽造カードが適切な時に提示されない、不適切な時に提示される、あるいは、仕様に準拠した物理的なパッケージ（例えば、形状、材料等）を有していない場合がある。一実施形態では、チップカード検出コンポーネント１４８は、チップカードが検出されたか否かを示す検出信号を提供してもよく、あるいは、一部の実施形態では、挿入されたチップカードについての情報（例えば、物理的なパッケージに関する）を提供する。リーダチップ１００の処理ユニット１２０は、その他の情報（例えば、監視されたタイミング、応答メッセージ、電気的特性等）の観点から受信した検出信号を分析して、検出信号が不正または改ざんの試みが発生する可能性が高いことを示すか否かを判定し得る（例えば、検出したカードが閾値挿入時間を超えると同時に、支払トランザクションが完了しなかった旨のメッセージを送信する）。
別の例示的なローカルテスト基準は、電源テストとし得る。不正トランザクションまたは改ざんの試みの間、支払端末２０（例えば、支払オブジェクトリーダ２２）が、異常期間（例えば、延長期間）の間あるいは異常なパターンで電力がオンされたままである場合がある。一実施形態では、電源モニタリングコンポーネント１４６が電源１０６を監視してもよく、そしてリーダチップ１００の処理ユニット１２０が監視した電源信号を分析して（例えば、閾値、範囲、パターン、統計、またはその他の監視した信号に基づいて）、不正または改ざんの試みが発生する可能性が高いか否かを判定してもよい。
一部の実施形態では、証明ルーチン１３８は、支払端末２０（例えば、支払端末２０の支払オブジェクトリーダ２２）に、支払サーバ４０（例えば、支払処理システム５０、小売業者デバイス２９およびネットワーク３０を介して）に対する不正または改ざんに関する情報を通信させる命令を提供してもよい。本明細書に記載するように、支払端末２０は、モニタリングコンポーネントから受信した信号およびデータに基づいて電気的特性を判定してもよく、支払デバイスに提供された要求に基づいて応答を受信してもよく、そして、支払端末の機能のタイミングを監視してもよい（例えば、監視した応答の）。一部の実施形態では、ローカルテスト基準を使用して、支払端末２０におけるローカルな不正または改ざんの試みを判定してもよい。一部の実施形態では、不正および改ざん検出の一部または全部が、支払端末２０（例えば、支払オブジェクトリーダ２２）とは遠隔で行われてもよい。したがって、一部の実施形態では、サーバ要求メッセージを生成して支払サーバ４０（例えば、支払処理システム５０）に送信してもよい。サーバ要求メッセージは、監視された電気的特性、監視されたタイミング、監視された応答、それらから判定された統計、トランザクション情報、支払端末についての情報（例えば、位置等）、環境情報（例えば、温度等）、ローカルテスト基準に基づく予備アセスメント、あるいはそれらの任意の適切な組み合わせなどの任意の適切な情報を含み得る。一部の実施形態では、サーバ要求メッセージは、ローカルテスト基準が、ローカルテスト基準のサブセットに対して不正トランザクションまたは改ざんの試みがある可能性が高いことを示す場合、または可能性のある不正トランザクションまたは改ざんの試みの重要度に基づいてのみ送信されてもよい。
一部の実施形態では、証明ルーチン１３８は、支払サーバ４０（例えば、支払処理システム５０）から不正判定メッセージを受信するよう命令を提供してもよい。本明細書に記載するように、支払サーバ４０（例えば、支払処理システム５０）は、サーバ要求メッセージに提供された情報を利用して不正トランザクションまたは改ざんの試みが発生しているか否かを判定してもよく、そして、不正判定メッセージで応答してもよい（例えば、不正判定メッセージをネットワーク３０および小売業者デバイス２９を介して支払オブジェクトリーダ２２に伝送することで）。証明ルーチン１３８は、リーダチップ１００の処理ユニット１２０に、不正判定メッセージから、不正トランザクションまたは改ざんの試みが発生しているとの指標、不正トランザクションまたは改ざんの試みのタイプについての情報、および行うべき是正措置のタイプに関する命令などの情報を抽出させ得る。
一部の実施形態では、証明ルーチン１３８は、ローカルテスト基準および不正判定メッセージに基づいて是正措置を取るよう命令を提供してもよい。任意の適切な是正措置を取り得るが、一部の実施形態では、是正措置は、トランザクションを中止すること（例えば、支払オブジェクト１０との通信を止める）、一時的または永久的に電力を取り除く、または支払端末４０の一つ以上のコンポーネントを無効にすること（例えば、改ざん保護回路、セキュリティ回路、または電気ヒューズを使用して）、支払オブジェクト１０にクエリして（例えば、要求メッセージを送信して）、不正トランザクションまたは改ざんの試みについての追加的な情報を収集すること、あるいは偽造カードまたは改ざんデバイスを損傷するために、対策を用いること（例えば、セキュリティ回路を利用して高電流を、接触インターフェース１０４を介して支払オブジェクト１０のＩ／Ｏラインに切り替える）を含み得る。
前述の通り、証明ルーチン１３８の結果が証明データ７５として取得され、支払端末に送信された後、リーダが将来の全てのトランザクションについて安全であることを示す証明チケットを生成するために支払処理システムに送信される。
図４は、本開示の一部の実施形態による例示的な小売業者デバイス２９を示す。小売業者デバイス２９は任意の適切な方法で実施され得るが、一実施形態では、小売業者デバイス２９は、ユーザインターフェースを提供し、一つ以上のその他のデバイスと通信する、対話型電子デバイスとしてもよい。対話型電子デバイスの例には、タブレット、スマートフォン、スマートウォッチ、デスクトップコンピュータ、ラップトップコンピュータ、カスタム電子デバイス、または、必要なユーザインターフェースおよび本明細書に記載する機能を行う通信能力を有する任意のその他の適切な電子デバイスが含まれる。
図４では特定のコンポーネントが特定の配置で示されているが、小売業者デバイス２９が追加的なコンポーネントを含んでもよく、図４に示す一つ以上のコンポーネントが小売業者デバイス２９に含まれなくてもよく、そして小売業者デバイス２９のコンポーネントを任意の適切な方法で置き換えてもよいことが理解されよう。一実施形態では、小売業者デバイス２９は、処理ユニット２０２、メモリ２０４、インターフェースバス２０６、電源２０８、ユーザインターフェース２１０、第一の無線インターフェース２１２、第二の無線インターフェース２１４、および有線インターフェース２０１を含む。
一実施形態では、小売業者デバイス２９は、小売業者デバイス２９を制御し、小売業者デバイス２９の必要な動作を行うように構成される、処理ユニット２０２およびメモリ２０４を含む。一実施形態では、処理ユニット２０２は、モバイルオペレーティングシステム、プログラム、およびメモリ２０４に記憶され得る命令に基づくアプリケーションに対する命令を実行する汎用プロセッサとし得る。メモリは、本明細書に記載するように、フラッシュメモリおよびＲＡＭメモリなどの、命令およびその他のデータを記憶し、小売業者デバイス２９のオペレーティングシステム、プログラム、およびアプリケーションの実行のためのワーキングメモリを提供する、任意の適切なメモリタイプ、またはそれらの組み合わせを含み得る。一実施形態では、メモリは、動作命令２２０、ＰＯＳアプリケーション命令２２２、および証明ルーチン２２４などの複数の命令のセットを含み得る。
処理ユニット２０２は、メモリ２０４の命令を実行して、小売業者デバイス２９の一つ以上のその他のコンポーネントと対話してこれを制御し得る。処理ユニット２０２は任意の適切な方法で小売業者デバイス２９のその他のコンポーネントと通信し得るが、一実施形態では、処理ユニットはインターフェースバス２０６を利用してもよい。インターフェースバス２０６は、Ｉ２Ｃ、 ＳＰＩ、ＵＳＢ、ＵＡＲＴ、およびＧＰＩＯなどの一つ以上の通信バスを含み得る。一実施形態では、処理ユニット２０２は、メモリの命令を実行し、これらの命令に基づいて、インターフェースバス２０６の通信バスを介して小売業者デバイス２９のその他のコンポーネントと通信し得る。
小売業者デバイス２９はまた、電源２０８を含み得る。電源２０８は、小売業者デバイス２９のコンポーネントによる使用のために、ＡＣ電力を変換する、および／または複数のＤＣ電圧を生成するための、電力変換回路を含み得る。電源２０８がバッテリを含む場合、バッテリは、物理的電力接続によって、非接触充電によって、あるいは、任意のその他の適切な方法によって充電され得る。図４では小売業者デバイス２９のその他のコンポーネントに物理的接続されて図示していないが、電源２０８は、小売業者デバイス２９のコンポーネントに対してこれらのコンポーネントの要件に応じて様々な電圧を供給し得る。
小売業者デバイス２９はまた、ユーザインターフェース２１０を含み得る。ユーザインターフェース２１０は、小売業者デバイス２９のユーザが、小売業者デバイス２９上で実行されるアプリケーションおよびプログラムと対話するための様々なオプションを提供し得る。例示的なユーザインターフェース２１０は、タッチスクリーンインターフェース、音声コマンドインターフェース、キーボード、マウスジェスチャ認識、任意のその他の適切なユーザインターフェース、またはそれらの任意の組み合わせなどの任意の適切なユーザインターフェース用のハードウェアおよびソフトウェアを含み得る。一実施形態では、ユーザインターフェース２１０は、小売業者デバイス２９上で実行されるプログラムおよびＰＯＳアプリケーションなどのアプリケーションに対する対話型ユーザインターフェースを表示し、不正トランザクション、改ざんの試み、および是正措置に関連するプロンプトおよびディスプレイを提供する、タッチスクリーンインターフェースとしてもよい。
小売業者デバイス２９はまた、複数の無線通信インターフェースを含んでもよい。無線通信インターフェースは、Ｂｌｕｅｔｈｏｏｔｈ ｃｌａｓｓｉｃ、Ｂｌｕｅｔｈｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ、ＷｉＦｉ、移動体通信、ショートメッセージサービス（ＳＭＳ）、 ＮＦＣ、任意のその他の適切な無線通信インターフェース、またはそれらの任意の組み合わせなどの無線通信インターフェースを提供するための、任意の適切なハードウェアおよびソフトウェアを含み得る。第一の無線通信インターフェース２１２は、支払オブジェクトリーダ２２と主に通信する無線通信インターフェース（例えば、Ｂｌｕｅｔｈｏｏｔｈ ｃｌａｓｓｉｃおよび／またはＢｌｕｅｔｈｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙインターフェース）としてもよく、第二の無線通信インターフェース２１４は、支払サーバ４０の支払処理システム５０と主に通信する（例えば、インターネットを介して）無線通信インターフェース（例えば、ＷｉＦｉ）としてもよい。
小売業者デバイスはまた、有線インターフェース２１６を含み得るが、これは、ＵＳＢ、Ｌｉｇｈｔｎｉｎｇ、 ＦｉｒｅＷｉｒｅ、 Ｅｔｈｅｒｎｅｔなどの、その他のデバイスとの有線通信のための任意の適切なインターフェースまたは通信ネットワーク、任意のその他の適切な有線通信インターフェース、あるいはそれらの任意の組み合わせを含み得る。
メモリ２０４は、動作命令２２０、ＰＯＳアプリケーション命令２２２、改ざんモニタリングコンポーネント２２３、証明ルーチン２２４、および小売業者デバイス２９を動作させるための任意のその他の適切な命令（例えば、小売業者デバイス２９の一つ以上のその他のアプリケーションまたはコンポーネントの動作に関連する命令）などの、小売業者デバイス２９の処理動作を行うための複数の命令のセットを含み得る。
動作命令２２０は、内部通信、電力管理、Ｉ／Ｏデバイスの制御、通信デバイスの制御、小売業者デバイス２９のその他のハードウェアの制御、任意のその他の適切な命令、またはそれらの任意の組み合わせなどの、小売業者デバイス２９の任意の適切な一般的な動作を制御するための命令を含み得る。一実施形態では、動作命令は、小売業者デバイス２９のオペレーティングシステム、ならびに、小売業者デバイス２９上で動作する、ほとんどのドライバ、プログラム、およびアプリケーションに対する命令を提供し得る。
動作命令２２０は、ユーザインターフェース２１０の動作を制御するための命令を含み得る。ユーザインターフェースは、動作命令２２０、ＰＯＳアプリケーション命令２２２、および証明ルーチン２２４のプログラムおよびアプリケーションの命令に従って制御され得る。一実施形態では、ＰＯＳアプリケーション命令２２２は、不正トランザクションおよび改ざんの試みの通知を表示し、支払オブジェクトリーダ２２によってとるべき是正措置を選択するためのメニューまたはその他の選択オプションを表示する命令を含んでもよい。ユーザインターフェース２１０は、処理ユニット２０２によって実行される動作命令２２０に基づいてメニューまたはその他の選択オプションを表示し得る。
動作命令２２０はまた、支払オブジェクトリーダ２２と対話するため、そして、支払サーバ４０において支払処理システム５０と対話するための、命令を含んでもよい。小売業者デバイス２９上で実行される支払オブジェクトリーダ２２および／またはアプリケーションは、支払処理システム５０に既知であるため（例えば、登録プロセスを通して）、小売業者デバイス２９は、ＰＯＳアプリケーション命令に従って、支払を支払処理システム５０で処理し得る。
ＰＯＳアプリケーション命令２２２は、小売業者デバイス２９上でＰＯＳアプリケーションを動作させる命令を含む。処理ユニット２０２によって実行されるとき、ＰＯＳアプリケーション命令２２２は、小売業者が、顧客との支払トランザクションを処理することが可能になる、対話型インターフェースの豊富な表示を提供してもよい。これらの命令は、小売業者または顧客が、購入用の製品を選択し、消費税を計算し、チップを処理し、領収書を提供し、割引または特価提供を生成し、顧客用ロイヤリティプログラムを処理し、在庫の中のまたは配送向けの品目を探し、いかなる他の好適な小売業務を行うことが可能になる、カスタマイズされたインターフェースを含んでもよい。一部の実施形態では、ＰＯＳアプリケーション命令は、不正トランザクションおよび改ざんの試行、ならびに不正トランザクションおよび改ざんの試行に応じて講じる是正措置の選択肢に関する情報の豊富な表示を提供する、命令を含んでもよい。
改ざんモニタリングコンポーネント２２３は、証明ルーチン２２４を実行するように構成される、回路および命令を含む。証明ルーチン内のコマンドにより、改ざんモニタリングコンポーネント２２３は、デバイス、ならびにその上で動作するアプリケーションの物理的および動作特性を取得するように、パラメータ、個々にまたは組み合わせてのいずれかで、立ち上がり時間シグネチャ、スペクトル値、過渡信号、ハードウェア障害、チャネル特性、電力値、信号強度、受信信号の識別、例えば、周波数または位相の点から、受信信号と関連付けられるタイミングパラメータ、および類似のものを検出する。
改ざんモニタリングコンポーネント２２３は、証明ルーチン２２４の中のコマンドに少なくとも基づき、特定のシーケンスまたはペイロードを生成してもよい。ペイロードは、正当性を確認された全デバイス間に共通するか、または各デバイスに一意であるかのいずれかであってもよい。ペイロードは、応答する送信機もしくはセンサのような、デバイスもしくはあるコンポーネントをトリガーする、データ信号または一連の命令であり得る。端末またはその中のコンテンツからの応答の性質は、各デバイスに対して一意であると言われており、証明データとして保存される。選択されたデバイスからの証明データはまた、コマンドの中にロードされたクエリへの肯定的なまたは否定的な回答の形態でもあり得る。バイナリ情報または文字情報のいずれかである応答は、支払処理システムなど、サーバへ送り返される前に、条件付けされおよび／または暗号化され得る。
証明ルーチン２２４は、支払オブジェクトリーダ２２からテストの一部分をオフロードし、支払オブジェクトリーダ２２の動作を制御するユーザインターフェース向けの選択肢を提供し、支払サーバ４０（例えば、支払処理システム５０）と通信する命令を含む、不正および改ざんの検出を支援する、いかなる好適な命令を含んでもよい。一部の実施形態では、小売業者デバイス２９は、支払オブジェクトリーダ２２から受信する情報（例えば、監視される応答、監視されるタイミングおよび電気的特性、トランザクション情報、環境情報、支払オブジェクトリーダ情報）のローカル分析（例えば、ローカルテスト基準に基づく）のうちの一部またはすべてを行ってもよい。このように、支払オブジェクトリーダでは、必要とされる処理能力が少なくてもよく、または、一部の実施形態では、小売業者デバイス２９でより複雑な分析を行ってもよい。
証明ルーチン２２４は、小売業者デバイス２９（または統合支払端末２０）が、潜在的な不正トランザクションまたは改ざんの試行に応答するように、インターフェースを提供する命令を含んでもよい。一部の実施形態では、改ざんの試行に関する警告などの情報、および、一部の実施形態では、警告をオーバーライドしてトランザクションを処理する選択肢を提供するユーザインターフェースに対して、表示を生成してもよい。他のユーザインターフェース情報は、不正トランザクションまたは改ざんの試行の処理に対する命令を含んでもよい。一部の実施形態では、ユーザインターフェース情報は、ローカルテスト基準を修正するインターフェース、支払オブジェクトリーダ２２で行われるテスト基準の選択、異なるタイプの不正トランザクショもしくは改ざんの試行に対する、異なる形態の是正措置の指定、いかなる他の好適なユーザインターフェース情報、またはそれらのいかなる好適な組み合わせを含んでもよい。
前に言及した通り、証明ルーチン２２４の結果は、証明データ７５として取得され、支払端末が、将来の全トランザクションに対して安全であると示す、証明チケット８５を生成するために、チケットが有効である限り、または、例えば、リーダとの接続が切断されるか、もしくは端末が再起動されるなど、無効にされるかもしくは再生成されるように、イベントが証明をトリガーするまで、支払端末へ、その後、支払処理システムへ送信される。
図５は、本開示の一部実施形態に従う、支払サーバ４０の例示的支払処理システム５０を描写する。支払処理システム５０は、単一のサーバとして描写されるものの、支払処理システム５０の操作およびメモリは、いかなる好適な数のサーバに渡って分散されてもよいことは、理解されるであろう。ある特定のコンポーネントが、ある特定の配列で図５に描写されているものの、支払処理システム５０は、追加のコンポーネントを含んでもよく、図５に描写するコンポーネントのうちの一つ以上は、支払処理システム５０の中に含まれなくてもよく、支払処理システム５０のコンポーネントは、いかなる好適な方式で再配列されてもよいことは理解されるであろう。一実施形態では、支払処理システム５０は、少なくとも処理ユニット３０２、メモリ３０４、インターフェースバス３０６、電源３０８、通信インターフェース３１０およびトランザクションデータベース３３０を含む。
一実施形態では、支払処理システム５０は、支払処理システム５０の必要な動作を制御して行うように構成される、処理ユニット３０２およびメモリ３０４を含む。一実施形態では、処理ユニット３０２は、メモリ３０４に記憶されてもよい命令に基づき、サーバ、プログラムおよびアプリケーション向けオペレーティングシステムに対して命令を実行する、高速プロセッサであってもよい。メモリ３０４は、命令および他のデータを記憶し、支払処理システム５０のオペレーティングシステム、プログラムおよびアプリケーションの実行に作業メモリを提供する、本明細書に記載する通りのいかなる好適なメモリタイプならびにそれらの組み合わせを含んでもよい。一実施形態では、メモリは、動作命令３２０、支払処理命令３２２、証明サブシステム３２３、フェイルオーバーコンポーネント３４８、ネットワークコントローラ３４６またはそのインスタンス、および証明ルーチン３２４を含むがそれらに限定されない、命令の複数セットを含んでもよい。セキュアエンクレーブ３４０内には、改ざん検出コンポーネント３４４、暗号３５０およびＨＳＭ３５２が保存され得る。
処理ユニット３０２は、支払処理システム５０の一つ以上の他のコンポーネントと対話し制御するように、メモリ３０４の命令を実行してもよい。処理ユニット３０２は、いかなる好適な方式で、支払処理システム５０の他のコンポーネントと通信してもよいものの、一実施形態では、処理ユニット３０２は、インターフェースバス３０６を利用してもよい。インターフェースバス３０６は、Ｉ２Ｃ、ＳＰＩ、ＵＳＢ、ＵＡＲＴおよびＧＰＩＯなど、一つ以上の通信バスを含んでもよい。一実施形態では、処理ユニット３０２は、メモリ３０４の命令を実行してもよく、それらの命令に基づき、インターフェースバス３０６の通信バスを介して、支払処理システム５０の他のコンポーネントと通信してもよい。
支払処理システム５０はまた、電源３０８を含んでもよい。電源３０８は、支払処理システム５０のコンポーネントによる使用のために、交流電力を変換し、および／または複数の直流電圧を生成する、電力変換回路を含んでもよい。一部の実施形態では、電源３０８は、停電中のサービス中断を回避するように、バッテリのバックアップなどのバックアップシステムを含んでもよい。図５では、電源３０８は、支払処理システム５０の他のコンポーネントへ物理的に接続されるように描写されていないものの、それらのコンポーネントの要件に従い、支払処理システム５０のコンポーネントへ、様々な電圧を供給してもよい。
支払処理システム５０はまた、通信インターフェース３１０を含んでもよい。通信インターフェース３１０が、いかなる好適な通信インターフェースまたはそれらの組み合わせを含んでもよいものの、一部の実施形態では、通信インターフェース３１０は、ＷｉＦｉ、セルラー、イーサネットまたは光ファイバなど、より高速の通信インターフェースを利用してもよい。通信インターフェースは、潜在的な不正トランザクションまたは改ざんの試行（例えば、サーバ要求メッセージおよび不正判定メッセージ）に関するメッセージを交換するために、支払端末２０（例えば、小売業者デバイス２９を介して支払オブジェクトリーダ２２）と、安全な接続（例えば、ＴＬＳまたはＳＳＬによる）を確立してもよい。通信インターフェースはまた、一部の実施形態では、支払処理システム５０から遠隔に設置され、支払処理システム５０を制御するエンティティとは異なるエンティティにより操作されてもよい、トランザクション処理サーバなどの支払サーバ４０である他のサーバと通信してもよい。例えば、一実施形態では、支払処理システム５０は、支払オブジェクトリーダ２２、小売業者デバイス２９またはＰＯＳアプリケーションのうちの一つ以上を提供する、エンティティによって操作されてもよい。トランザクション処理サーバは、小売業者、発行人または顧客銀行のうちの一つ以上と関連付けられ、操作されてもよい。
メモリ３０４は、動作命令３２０、支払命令３２２、証明ルーチン３２４、および支払処理システム５０を操作するいかなる他の好適な命令（例えば、支払処理システム５０の一つ以上の他のアプリケーションまたはコンポーネントの動作に関係する命令）など、支払処理システム５０の処理動作を行う命令の複数セットを含んでもよい。
動作命令３２０は、内部通信、電力管理、通信デバイスの制御、支払処理システム５０の他のハードウェアの制御、いかなる他の好適な命令、またはそれらのいかなる組み合わせなど、支払処理システム５０のいかなる好適な通常動作を制御する命令を含んでもよい。一実施形態では、動作命令により、支払処理システム５０のオペレーティングシステム、ならびに支払処理システム５０上で動作する大部分のドライバ、プログラムおよびアプリケーションに、命令を提供してもよい。
動作命令３２０はまた、小売業者デバイス２９と対話する命令を含んでもよい。一実施形態では、支払処理システム５０は、通信インターフェース３１０を介して、小売業者デバイス２９と通信してもよい。動作命令３２０は、処理ユニット３０２によって実行されるとき、ＴＬＳ、ＳＳＬ、または鍵に基づく暗号化データなどの手順を実施することによって、これらの通信を制御し、安全な通信を提供する命令を含んでもよい。
支払処理命令３２２は、支払を処理する命令を含み、小売業者デバイス２９、支払オブジェクトリーダ２２（例えば、小売業者デバイス２９を介する）および／またはトランザクション処理サーバへ伝達されるメッセージのコンテンツを制御してもよい。一実施形態では、支払処理命令は、インストール済みＰＯＳアプリケーションを有する、各支払オブジェクトリーダ２２および小売業者デバイス２９についての情報を含んでもよい。金額およびクレジットカード番号などの支払情報を、トランザクション処理システムへ提供し、応答を小売業者へ伝達し戻すなどの支払処理機能を行うのに加えて、支払処理システム５０はまた、小売業者（例えば、複数の場所で複数の小売業者デバイス２９を操作する小売業者）へ、レポート、メトリクスまたは他のデータを提供するように使用されてもよい、小売業者データの複雑な分析を行ってもよい。支払処理命令３３２はまた、共有される秘密鍵、または支払オブジェクト１０、支払オブジェクトリーダ２２もしくは小売業者デバイス２９のうちの一つ以上によって提供されるデータを暗号化して復号する、公開／秘密鍵の対である鍵など、暗号鍵にアクセスする命令を含んでもよい。
証明ルーチン３２４は、支払端末２０から（例えば、小売業者デバイス２９およびネットワーク４０を介して支払オブジェクトリーダ２２から）受信する通信に基づき、不正トランザクションまたは改ざんの試行を識別し、メッセージを支払端末２０へ提供し、支払端末２０からトランザクションデータベース３３０へ受信されるデータ（例えば、電気的特性、監視される応答、監視されるタイミング、トランザクション情報、環境データ、支払オブジェクトリーダ情報など）のログを取り、テスト基準を識別および更新するように、トランザクションデータベース３３０に記憶されるデータを分析する命令を含む。
証明ルーチン３２４により、支払端末２０から（例えば、小売業者デバイス２９、ネットワーク３０および通信インターフェース３１０を介して支払オブジェクトリーダ２２から）のメッセージ（例えば、サーバ要求メッセージ）を受信して処理するように、支払処理システム５０に命令を提供してもよい。受信メッセージは、監視される電気的特性、監視されるタイミング、監視される応答、トランザクション情報、支払端末についての情報（例えば、場所、モデル、対の小売業者デバイスなど）、環境情報（例えば、温度など）、それらから判定される統計、およびローカルテスト基準に基づく初期評価などの情報を含んでもよい。この情報は、不正トランザクションまたは改ざんの試行が発生しているかを判定するように、サーバテスト基準と比較されてもよい。一部の実施形態では、サーバテスト基準は、ローカルテスト基準に対して上に記載したテスト基準だけでなく、関係するトランザクション、並列トランザクション、以前のトランザクションおよびフィードバック情報との比較に関与する、追加のテスト基準をも含んでもよい。一部の実施形態では、サーバテスト基準は、支払端末２０および他の支払端末２０から獲得される最近のデータに基づき、規則的に更新することができるような、動的であってもよい（例えば、動的な閾値を利用する）。サーバテスト基準はまた、他の並列トランザクションまたは最近のトランザクションからの類似データとの比較を伴ってもよく、それにより、単一の支払端末で容易に識別することができない不正行為（例えば、類似の電気的特性、監視されるタイミング、支払端末特性、環境情報またはモニタリングメッセージを有する、最近のトランザクションの大半が不正である場合）のパターンの検出が可能になってもよい。
証明ルーチン３２４により、支払端末２０へ（例えば、不正判定メッセージによって）メッセージを提供するように、支払処理システム５０に命令を提供してもよい。一旦支払処理システム３０が、トランザクションが不正であるか、または改ざんの試行が発生しているかを判定すると、不正判定メッセージが生成されてもよい。不正判定メッセージは、不正トランザクションまたは改ざんの試行が発生しているという指標、不正トランザクションまたは改ざんの試行のタイプについての情報、および行うべき是正措置のタイプに関する命令などの情報を含んでもよい。不正判定メッセージはその後、支払端末２０へ伝送されてもよい。
証明ルーチン３２４により、支払端末２０からトランザクションデータベース３３０へ受信されるデータ（例えば、電気的特性、監視される応答、監視されるタイミング、トランザクション情報、支払端末情報、環境データなど）のログを取る命令を提供してもよい。支払端末２０から受信するデータに加えて、サーバテスト基準の結果および提案される是正措置など、いかなる他の好適な情報が、トランザクションデータベース３３０に記憶されてもよい。
証明ルーチン３２４により、トランザクションデータベース３３０に記憶されるデータを分析する命令を提供してもよい。トランザクションデータベース３３０は、大量に記憶されるトランザクション情報を含み、何百万ものトランザクションが日々更新されていてもよい。トランザクションデータベース３３０に記憶される情報は、電気的特性、監視されるタイミング、監視される応答、トランザクション情報、支払端末情報、環境データ、トランザクションが不正であったか、もしくは改ざんの試行が発生したかの指標、または是正措置のタイプなど、いかなる好適な情報も含む。
セキュアエンクレーブ３４０は、アプリケーションが、ＯＳプロセスの状況でコードを実行し内部にデータを記憶する、安全な場所を提供する命令のセットである。この環境で実行するアプリケーションを、エンクレーブと呼ばれる。エンクレーブはエンクレーブページキャッシュ（ＥＰＣ）から実行される。エンクレーブページは、ＯＳによってＥＰＣの中へロードされる。エンクレーブのページがＥＰＣから除去されるときはいつでも、暗号保護を使用して、エンクレーブがＥＰＣの中へロードし戻されるときに、エンクレーブの機密性を保護し、改ざんを検出する。ＥＰＣ内部では、エンクレーブデータはプロセッサにより提供されるアクセス制御機構を使用して保護される。
暗号３５０およびＨＳＭ３５２は、構築および動作において暗号９０およびＨＳＭ９８に類似する。改ざん検出コンポーネント３４４および証明サブシステム３２３は、一実施形態に従い、改ざん検出コンポーネント８０によって行われるタスクを共有する。改ざん検出コンポーネント３４４はセッションの正当性を確認し、一方証明サブシステム３２３は証明チケットを提供する。
加えて、他の電子システム（例えば、トランザクションサーバ６０）によって、または他の方法（例えば、不正トランザクションのビジネスまたは消費者報告）によって、不正トランザクションが、支払オブジェクトリーダ２２（例えば、ローカルテスト基準によって）または支払サーバ５０（例えば、サーバテスト基準によって）によって捕捉されなかったと判定されてもよい。そのようなトランザクションは、偽陰性と称されてもよい。また、他の電子システム（例えば、トランザクションサーバ６０）または他の方法（例えば、不正トランザクションのビジネスまたは消費者報告）によって、トランザクションが不適切に、支払オブジェクトリーダ２２（例えば、ローカルテスト基準によって）または支払サーバ５０（例えば、サーバテスト基準によって）によって拒絶されたと判定されてもよい。そのようなトランザクションは、偽陽性と称されてもよい。偽陽性および偽陰性は、証明ルーチン３２４に基づき、トランザクション用の情報と関連付けられ、トランザクションデータベース３３０に記憶されてもよい、フィードバックを提供してもよい。
また、他の電子システム（例えば、トランザクションサーバ６０）によって、または他の方法（例えば、不正トランザクションのビジネスまたは消費者報告）によって、不正トランザクションまたは改ざんの試行に携わる、新規のまたは修正された方法が行われており、これらの基準が支払処理システムへ提供されてもよいと判定されてもよい。そのような基準により、外部更新基準と称される、フィードバックが提供されてもよい。ローカルテスト基準およびサーバテスト基準は、これらの外部更新基準および証明ルーチン３２４に基づき更新されてもよい。
トランザクションデータベース３３０に記憶されるデータの分析を、いかなる好適な方式で行ってもよいものの、一部の実施形態では、データを分析するのに機械学習法が使用されてもよい。不正トランザクションおよび改ざんの試行に関連する、この大量の情報の可用性により、支払処理システムの反応性を向上させる、複雑な分析が可能になることは理解されるであろう。サーバテスト基準およびローカルテスト基準を微調整することによって、新規タイプの攻撃または向上した攻撃を捕捉しながら、偽陽性（例えば、トランザクションが不正である、または改ざんの試行が発生しているという誤った判定）を回避するように、テスト基準を動的に較正し得る。支払処理システム５０は、支払端末２０により捕捉されるあるデータが、不正トランザクションまたは改ざんの試行の結果である可能性が高いと判定し、それに応じてローカルテスト基準を生成してもよい。ローカルテスト基準はその後、更新メッセージによって更新されてもよい。支払処理システムは同様に、サーバテスト基準を更新してもよい。
一実施形態では、クライアント（すなわち、支払端末２０）およびサーバ５０は、サーバがそれ以上寄与できなくなるまで、メッセージを交換する。サーバからの全メッセージは、最後の一つを除いて、証明チケット８５を含む、より多くの命令またはメッセージを伴うフレームを有してもよい。クライアントは、チケット８５を受信するとディスクに書き込む（以前のチケットがある場合には、上書きする）。証明チケット８５の暗号文のコンテンツは、変わらなくてもよい。コンテンツは、最後に承認された時間、最後に拒絶された時間、有効時間（チケットが有効である時間）、およびデバイス名（例えば、ｉＰｈｏｎｅ（登録商標）、ｉＰａｄ（登録商標）など）、オペレーティングシステムのバージョン、支払アプリケーションのバージョン、デバイスのタイプ（タブレット、電話など）などのデバイス識別子を伴うＪＳＯＮオブジェクトであり得る。最後に承認された時間は、プレーンテキストに現れる有効期限と同じであってもよく、これによって、有効期限が認証データに含まれることを保証する。一部の実施では、サーバ５０は常に、改ざんを検出した場合でさえ、チケットを戻す。チケットの暗号文部分は、クライアントが承認されるべきか否かを示す。一部の実施では、チェックインの頻度は、チケットの持続時間に結び付いていなくてもよい。チケットのサイズを制限する実施がある一方、チケットを制約しないままの実施もある。例えば、チケットサイズは、１ＫＢまでに保持され得るか、または利用可能なデバイス識別子の数に基づき保持され得る。サイズは、フェイルオープン戦略を使用して制約され得る。証明チケットは、上に説明する通りに作り出される。チケットサイズが閾値を満たす場合、サーバは、そのチケットを、承認のために最小限の情報を包含するチケットと置き換え、警告のログを取り得る。
証明チケットのコンテンツは、サーバ５０以外のいかなる当事者に対しても不透明であるが、しかしながら、一部のコンテンツを、ある当事者には見られるようにできる。例えば、一つの実施では、証明チケットの妥当性と関連付けられる有効期限を、すべてのデバイスが利用可能とし得る。一つのシナリオでは、クライアントは、安全なセッションを要求する前に、チケットがまだ有効かを確認するように、チケットの有効期限を検査する。一つのシナリオでは、有効期限がＵＮＩＸ時間であるため、タイムゾーンのパリティはない。しかしながら、クライアントは、ＵＮＩＸ時間を追跡する信頼性のある手段を有さなくてもよく、そのため、クライアントのクロックは、サーバのクロックとほとんど同期しない場合がある。この目的のために、チケットは有効期限だけでなく、作成時間フィールドの両方を含み得る。これが、チケットの持続時間を判定するのに役立つ。
一部の実施では、証明チケットの例は実質的にフォームから成り得る。
ｍｅｓｓａｇｅ ＳｅａｌｅｄＴｉｃｋｅｔ ｛
ｏｐｔｉｏｎａｌ ｕｉｎｔ６４ ｅｘｐｉｒａｔｉｏｎ ＝ １；
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｃｉｐｈｅｒｔｅｘｔ ＝ ２；
｝
ｍｅｓｓａｇｅ ＧｅｔＴｉｃｋｅｔＲｅｑｕｅｓｔ ｛
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｆｒａｍｅ ＝ １；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｃｕｒｒｅｎｔ＿ｔｉｃｋｅｔ ＝ ２；
｝
ｍｅｓｓａｇｅ ＧｅｔＴｉｃｋｅｔＲｅｓｐｏｎｓｅ ｛
／／ ｍｓ ＿ｆｒａｍｅ（サーバが送信するコマンドをより多く有する場合）； ｎｅｗ＿ｔｉｃｋｅｔ（交換されるのが以下の場合）
／／ ｏｖｅｒ．
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｍｓ＿ｆｒａｍｅ ＝ １；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｎｅｗ＿ｔｉｃｋｅｔ ＝ ２；
｝
ｓｅｒｖｉｃｅ ＰａｙｍｅｎｔＳｅｒｖｅｒＳｅｒｖｉｃｅ ｛
ｒｐｃ ＧｅｔＴｉｃｋｅｔ （ＧｅｔＴｉｃｋｅｔＲｅｑｕｅｓｔ） ｒｅｔｕｒｎｓ （ＧｅｔＴｉｃｋｅｔＲｅｓｐｏｎｓｅ） ｛｝
ｒｐｃ ＶａｌｉｄａｔｅＳｅｓｓｉｏｎ （ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ） ｒｅｔｕｒｎｓ （ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ） ｛
ｏｐｔｉｏｎ （ｍｕｌｔｉｐａｓｓ．ｃｒｅｄｅｎｔｉａｌｓ） ＝ ＜ｒｅｔｒｉｅｖｅ＞；
｝
｝
ｍｅｓｓａｇｅ ＳｅａｌｅｄＴｉｃｋｅｔ ｛
ｏｐｔｉｏｎａｌ ｕｉｎｔ６４ ｅｘｐｉｒａｔｉｏｎ ＝ １；
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｃｉｐｈｅｒｔｅｘｔ ＝ ２；
｝
ｍｅｓｓａｇｅ ＧｅｔＴｉｃｋｅｔＲｅｑｕｅｓｔ ｛
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｆｒａｍｅ ＝ １；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｃｕｒｒｅｎｔ＿ｔｉｃｋｅｔ ＝ ２；
｝
ｍｅｓｓａｇｅ ＧｅｔＴｉｃｋｅｔＲｅｓｐｏｎｓｅ ｛
／／ ｍｓ ＿ｆｒａｍｅ（サーバが送信するコマンドをより多く有する場合）； ｎｅｗ＿ｔｉｃｋｅｔ（交換されるのが以下の場合）
／／ ｏｖｅｒ．
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｍｓ＿ｆｒａｍｅ ＝ １；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｎｅｗ＿ｔｉｃｋｅｔ ＝ ２；
｝
ｓｅｒｖｉｃｅ ＰａｙｍｅｎｔＳｅｒｖｅｒＳｅｒｖｉｃｅ ｛
ｒｐｃ ＧｅｔＴｉｃｋｅｔ （ＧｅｔＴｉｃｋｅｔＲｅｑｕｅｓｔ） ｒｅｔｕｒｎｓ （ＧｅｔＴｉｃｋｅｔＲｅｓｐｏｎｓｅ） ｛｝
ｒｐｃ ＶａｌｉｄａｔｅＳｅｓｓｉｏｎ （ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ） ｒｅｔｕｒｎｓ （ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ） ｛
ｏｐｔｉｏｎ （ｍｕｌｔｉｐａｓｓ．ｃｒｅｄｅｎｔｉａｌｓ） ＝ ＜ｒｅｔｒｉｅｖｅ＞；
｝
｝
安全なセッションの妥当性確認が、実質的にフォームから成る手段で行われ得る。
ｍｅｓｓａｇｅ ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ ｛
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｓｅｃｕｒｅ＿ｓｅｓｓｉｏｎ＿ｒｅｑｕｅｓｔ ＝ １；
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｆｒａｍｅ ＝ ２；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｔｉｃｋｅｔ ＝ ３；
｝
ｍｅｓｓａｇｅ ＶａｌｉｄａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ ｛
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｓｅｃｕｒｅ＿ｓｅｓｓｉｏｎ＿ｒｅｑｕｅｓｔ ＝ １；
ｏｐｔｉｏｎａｌ ｂｙｔｅｓ ｆｒａｍｅ ＝ ２；
ｏｐｔｉｏｎａｌ ＳｅａｌｅｄＴｉｃｋｅｔ ｔｉｃｋｅｔ ＝ ３；
｝
上記の通り、記載した構造およびデバイスを考慮して、開示する主題に従い実施され得る方法は、図６〜７のフローチャートを参照の上、より良く認識されるであろう。説明を平易にする目的で、方法が一連のステップとして示され記載される一方、そのような図または対応する描写は、一部のステップが、本明細書に描写し記載するものとは異なった順序で、および／または他のステップと並列して発生してもよいため、ステップの順序によって限定されないことは、理解および認識されるべきである。フローチャートによって図示する、いかなる不連続の、すなわち、分岐するフローも、同じまたは類似の結果を実現する、ステップの様々な他の分岐、フローの進路および順序を実施し得ることを示すことは理解されるべきである。さらに、図示するステップのすべてが、以下に記載する方法を実施するのに必要とされるわけではない場合がある。
図６は、本開示の一部実施形態に従い、不正トランザクションおよび改ざんの試行の物理的および論理的検出を行うステップ４００を描写する。一実施形態では、図６に描写する通り、ステップ４００は、支払オブジェクトリーダ２２（図６に（Ｒ）を伴って示す）および支払サーバ４０の支払処理システム５０（図６に（Ｓ）を伴って示す）など、支払端末デバイスによって行われる。これらのステップは、一実施形態では、ある特定のデバイスによって行われていると記載されるものの、デバイス間のステップの割り当てが、いかなる好適な方式で修正されてもよく、またはステップを行うデバイスの数が、いかなる好適な方式で修正されてもよいことは、理解されるであろう。
ステップ４０２で、支払オブジェクトリーダ２２の処理ユニット１２０は、ＮＦＣデバイス１２またはＥＭＶチップ１４などの支払オブジェクト１０で、支払トランザクションを開始してもよい。一部の実施形態（図６に描写せず）では、図６の残りのステップは、トランザクションが開始されていないときでも行うことができる。このように、トランザクションを処理していないときでも、改ざんの試行を調べることが可能であってもよい。一旦支払トランザクションがステップ４０２で開始されると、処理はステップ４０４へ続いてもよい。
ステップ４０４で、支払オブジェクトリーダ２２の処理ユニット１２０は、証明ルーチン１３８に基づき物理的信号を監視してもよく、証明ルーチン１３８は、支払処理システム５０のような支払処理システムから取得される。いかなる好適な物理的信号を、いかなる好適な方式で監視してもよいものの、一部の実施形態では、ＮＦＣモニタリングコンポーネント１４２、接触モニタリングコンポーネント１４４、電源モニタリングコンポーネント１４６およびチップカード検出コンポーネント１４８などのモニタリングコンポーネントを、本明細書に記載する通りに監視してもよい。一部の実施形態では、信号が、テスト波形など、一つ以上のモニタリングコンポーネントへ提供されてもよい。これらの監視される物理的信号は、いかなる好適な情報を判定するように使用されてもよいものの、一部の実施形態では、電気的特性、検出信号および監視されるタイミングは、監視される物理的信号に基づいて判定されてもよい。その後、処理はステップ４０６へ続いてもよい。
ステップ４０６で、支払オブジェクトリーダ２２の処理ユニット１２０は、証明ルーチン１３８に基づきアクティブテストを行ってもよい。本開示に従い、いかなる好適なアクティブテストを行ってもよいものの、一部の実施形態では、アクティブテストは、信号と、要求メッセージ（例えば、乱数テスト要求、エラー条件テスト要求およびメッセージタイミングテスト要求）などのメッセージとを提供することを含んでもよい。支払デバイスから受信する応答に基づき、一部の実施形態では、他の信号（例えば、電気的特性およびタイミング情報）、監視される応答などの情報、および監視されるタイミングが取得されてもよい。その後、処理はステップ４０８へ続いてもよい。
ステップ４０８で、支払オブジェクトリーダ２２の処理ユニット１２０は、証明ルーチン１３８に基づきローカルの不正および改ざん検出を行ってもよい。いかなる好適な方式で、不正および改ざん検出をローカルで行ってもよいものの、一部の実施形態では、ステップ４０４および４０６で集められた情報が、ローカルテスト基準に従い分析されてもよい。その後、処理はステップ４１０へ続いてもよく、ステップ４０８での分析から、支払オブジェクトリーダ２２が即座に是正措置を講じるべきであるような、不正トランザクションまたは改ざんの試行が検出されたかを判定し、是正措置を講じるべき場合には、処理はステップ４２６へ続いてもよい。図６に描写する通りの一部の実施形態では、ローカルテスト基準が、即座に是正措置を講じるべきと示さない場合、処理はステップ４１２へ続いてもよい。しかしながら、一部の実施形態（図６に描写せず）では、疑わしいトランザクション（例えば、即座の是正措置を必要としない）が発生したとローカルテスト基準が示す場合、処理はステップ４１２へ続くのみであってもよいことは理解されるであろう。
ステップ４１２で、支払オブジェクトリーダ２２の処理ユニット１２０は、証明ルーチン１３８に基づき、サーバへ情報を送信してもよい。いかなる好適な情報が、いかなる好適なサーバへ送信されてもよいものの、一部の実施形態では、支払オブジェクトリーダ２２は、小売業者デバイス２９およびネットワーク３０を介して、支払サーバ４０の支払処理システム５０へサーバ要求メッセージを送信してもよい。いかなる好適な情報が、サーバ要求メッセージの中で提供されてもよいことは理解されるであろうものの、一部の実施形態では、情報は、監視される電気的特性、監視されるタイミング、監視される応答、トランザクション情報、支払端末についての情報（例えば、場所など）、環境情報（例えば、温度など）、それらから判定される統計、およびローカルテスト基準に基づく初期評価を含んでもよい。その後、処理はステップ４１４へ続いてもよい。
ステップ４１４で、支払処理システム５０の処理ユニット３０２は、動作命令３２０および証明ルーチン３２４に基づき、通信インターフェース３１０を介して情報（例えば、サーバ要求メッセージ）を受信してもよい。受信情報（例えば、監視される電気的特性、監視されるタイミング、監視される応答、トランザクション情報、支払端末についての情報（例えば、場所など）、環境情報（例えば、温度など）、それらから判定される統計、およびローカルテスト基準に基づく初期評価）は、支払処理システム５０によって、処理のためにサーバ要求メッセージから抽出されてもよい。その後、処理はステップ４１６へ続いてもよい。
ステップ４１６で、支払処理システム５０の処理ユニット３０２は、証明ルーチン３２４に基づき受信情報を分析してもよい。一部の実施形態では、受信情報は、サーバテスト基準を使用して、同じ支払端末２０（例えば、支払端末２０の支払オブジェクトリーダ２２）から、同じ支払オブジェクト１０から、他の支払端末から、および他の支払デバイスから以前に記憶された情報など、情報の他の資源に基づき分析されてもよい。受信情報はまた、並列して生じている他のトランザクションに基づき、分析されてもよい。受信情報はまた、トランザクションデータベース３３０の中などに記憶されてもよい。その後、処理はステップ４１８へ続いてもよい。
ステップ４１８で、支払処理システム５０の処理ユニット３０２は、不正トランザクションまたは改ざんの試行が、証明ルーチン３２４に基づき検出されたかを判定してもよい。本明細書に記載する通り、一部の実施形態では、受信情報は、サーバテスト基準、トランザクションデータベース３３０の中に記憶された情報、および並列支払トランザクションに基づき分析されてもよい。不正トランザクションまたは改ざんの試行が発生したかを判定する場合、処理はステップ４２４へ続いてもよい。不正トランザクションまたは改ざんの試行が発生していなかったかを判定する場合、処理はステップ４２０へ続いてもよい。
ステップ４２０で、支払処理システム５０の処理ユニット３０２は、動作命令３２０、支払処理命令３２２および証明ルーチン３２４に基づき、トランザクションを処理すべきであると示すメッセージを、支払端末１０へ送信してもよい。一部の実施形態では、支払処理システムは、トランザクションサーバ６０など、一つ以上のサーバと通信し、トランザクションを処理し、トランザクションが承認されたことを示し、処理されたトランザクションに関する情報を含む、承認メッセージを生成し、ネットワーク３０および小売業者デバイス２９を介して、支払オブジェクトリーダ２２へメッセージを伝送してもよい。その後、処理はステップ４２２へ続いてもよい。
ステップ４２２で、支払オブジェクトリーダ２２の処理ユニット１２０は、承認メッセージおよびトランザクション処理命令１３２に基づき、トランザクションを処理してもよい。トランザクションが処理されるとすぐに、ステップ４００の処理が終了してもよい。
ステップ４２４で、支払処理システム５０の処理ユニット３０２は、動作命令３２０および証明ルーチン３２４に基づき、不正判定メッセージなどのメッセージを生成し、支払端末２０（例えば、支払オブジェクトリーダ２２）へ送信してもよい。一部の実施形態では、不正判定メッセージは、不正トランザクションまたは改ざんの試行が発生しているという指標、不正トランザクションまたは改ざんの試行のタイプについての情報、および行うべき是正措置のタイプに関する命令などの情報を含んでもよい。その後、処理はステップ４２６へ続いてもよい。
ステップ４２６で、支払オブジェクトリーダ２２の処理ユニット１２０は、証明ルーチン１３８に基づき是正措置を講じてもよい。本明細書に記載する通り、ステップ４２６の処理は、支払オブジェクトリーダ２２（例えば、ローカルテスト基準に基づく）、または支払処理システム５０（例えば、サーバテスト基準、並列トランザクション、およびトランザクションデータベース３３０に記憶されるデータに基づく）のいずれかで、判定に基づき発生してもよい。本明細書に記載する通り、支払オブジェクトリーダはその後、適切な是正措置（例えば、トランザクションの中止、一時的もしくは恒久的な電力の除去または支払端末の一つ以上のコンポーネントの無効化、追加情報を集めるための支払デバイスへのクエリ、または対策の採用）を講じてもよい。その後、ステップ４００の処理が終了してもよい。
図７は、本開示の一部実施形態に従い、テスト基準を更新する例示的なステップ５００を図示する、非限定的なフロー図を描写する。テスト基準が、いかなる好適な方式でも、いかなる好適なデバイスによっても更新されてよいことは理解されるであろうものの、例示的実施形態では、テスト基準は、支払オブジェクトリーダ２０から受信する情報に基づき、支払サーバ４０の支払処理システム５０で更新されてもよい。
ステップ５０２で、支払処理システム５０の処理ユニット３０２は、動作命令３２０および証明ルーチン３２４に基づきリーダのデータを受信し記憶してもよい。一部の実施形態では、支払処理システム５０は、支払オブジェクトリーダ２０からサーバ要求メッセージを受信してもよい。それらのサーバ要求メッセージは、監視される電気的特性、監視されるタイミング、監視される応答、トランザクション情報、支払端末についての情報（例えば、場所など）、環境情報（例えば、温度など）、それらから判定される統計、およびローカルテスト基準に基づく初期評価など、トランザクションデータベース３３０にその後記憶される情報を含む。その後、処理はステップ５０４へ続いてもよい。
ステップ５０４で、支払処理システム５０の処理ユニット３０２は、証明ルーチン３２４に基づき、不正トランザクションまたは改ざんの試行が発生したかを判定し、トランザクションデータベース３３０でその判定についての情報を記憶するように、サーバ要求メッセージを処理してもよい。本明細書に記載する通り、支払処理システム５０は、図６のステップ４１４〜４２０およびステップ４２４に描写し記載するように、受信したサーバ要求メッセージを処理してもよい。この処理の結果（例えば、サーバテスト基準に対するテストの結果）は、リーダのデータと関連付けられ、トランザクションデータベース３３０で記憶されてもよい。その後、処理はステップ５０６へ続いてもよい。
ステップ５０６で、支払処理システム５０の処理ユニット３０２は、証明ルーチン３２４に基づき、フィードバックを受信し、トランザクションデータベース３３０でフィードバックを記憶してもよい。いかなる好適なフィードバックが、本開示に従って受信および記憶されてもよいものの、一部の実施形態では、偽陽性および偽陰性が、トランザクションデータベース３３０で受信され、トランザクションと関連付けられてもよい。フィードバックはまた、外部で更新されたテスト基準を含んでもよく、そのテスト基準は、トランザクションデータベース３３０に記憶される情報に基づき、データを分析しテスト基準を更新するように、ステップ５０８および５１０で使用されてもよい。
ステップ５０８で、支払処理システム５０の処理ユニット３０２は、証明ルーチン３２４に基づき、トランザクションデータベース３３０の中のデータを分析してもよい。一部の実施形態では、トランザクションデータベース３３０の大きなデータセット上で、および、一部の実施形態では、外部で更新されたテスト基準で、機械学習法が利用されてもよい。一部の実施形態では、不正トランザクションをもたらすパターンが、トランザクションデータベース３３０で記憶される情報に基づいて識別されてもよく、テスト基準は、識別に基づいて更新されてもよい。偽陽性および偽陰性は、修正されるべきテスト基準を識別するように使用されてもよい。不正トランザクションおよび改ざんの試行の重大度などの情報、またはある特定の情報（例えば、電気的特性、監視される応答、監視されるタイミング、支払オブジェクトリーダ情報、環境情報など）が不正トランザクションまたは改ざんの試行をもたらしたという可能性は、講じるべき是正措置のタイプだけでなく、どのテスト基準がローカルテスト基準であるべきか、およびどのテスト基準がサーバテスト基準となってもよいかを判定するように使用されてもよい。一旦データが分析されると、処理はステップ５１０へ続いてもよい。
ステップ５１０で、支払処理システム５０の処理ユニット３０２は、証明ルーチン３２４に基づきテスト基準を更新してもよい。一部の実施形態では、サーバテスト基準は、支払処理システム５０で更新されてもよく、ローカルテスト基準は、ネットワーク３０および小売業者デバイス２９を介して、支払オブジェクトリーダ２２へ更新メッセージを伝送することによって、更新されてもよい。その後、ステップ５００の処理が終了してもよい。
図８Ａは、本開示の一部実施形態に従い、支払端末、もしくは小売業者に属するいかなる他の小売業者デバイスの正当性を確認する証明チケットを生成し、また、証明済みの端末と支払オブジェクトリーダとの間に安全なセッションを確立する、データフロー８００を描写する。一実施形態では、図８に描写する通り、ステップ８００は、支払リーダ３、支払端末（小売業者デバイスとも称される）２０、および支払サーバ５０（すなわち、支払処理システム５０による）などの支払端末デバイスによって行われる。これらのステップは、一実施形態では、ある特定のデバイスによって行われていると記載されるものの、デバイス間のステップの割り当てが、いかなる好適な方式で修正されてもよく、またはステップを行うデバイスの数が、いかなる好適な方式で修正されてもよいことは、理解されるであろう。さらに、方法８００は、支払デバイスの名前に対する証明チケットの前の履歴がない、初めて生成されるチケットに適用され、証明チケットを更新するように要求するデバイスを求め得る。
ステップ８０２で、例えば、改ざんモニタリングコンポーネント７０である支払端末２０は、インストールされるデバイスの状態についてのデータ（例えば、ハードウェア／ＯＳの詳細、ジェイルブレイクまたはマルウェアの兆候、デバイス特性など）を周期的に更新する。支払サーバ５０（例えば、改ざん検出コンポーネント８０）は、そのデータを受信し記憶してもよい。状態データを収集することで、開示するシステムが、どのプラットフォーム（アプリケーションのインストール、デバイスなど）が信頼でき安全かについて、より良い決定を下すことが可能になる。状態データはまた、すべての過去のチケット情報、サーバの過去の決定、小売業者がリスクに対して優良な状態を有するか、改ざんまたはジェイルブレイクのいかなる過去の指標、トランザクションまたは小売業者の履歴、およびそのある特定のデバイスまたはアプリケーションに関係する情報を明らかにする。デバイスまたはアプリケーションが、正当性を確認されるか、または証明されるように要求しているのが、今回初めてである場合、そのようなデータは利用可能でない場合があり、そのため状態データは無効であってもよい。したがって、本記載の目的のため、このステップは、第１ステップまたは証明後のステップのいずれかとして発生してもよい。一部の場合には、ステップ８０４によってステップ８０２が冗長となり、二つのうちの一つのみを行う。他の場合には、両方のステップを行い、ステップ８０２は、ハウスキーピングと、状態データが常に最新であることを保証することとに集中するが、証明に対する明示的な要求は行わず、一方、ステップ８０４では、支払デバイスの正当性を確認する証明チケットを生成するプロセスをトリガーする。いかなる数のデバイス、アプリケーション、オペレーティングプラットフォーム、小売業者およびオブジェクトを証明し得ることは理解されるであろう。
改ざんモニタリングコンポーネント７０は、支払サーバ５０に周期的にチェックインし、有効な証明チケットの候補であるかを判定するように、支払端末２０上でスキャンおよびテストの完全なセットを動作させる。これはまた「周期的スキャン」とも称される。例示のＨＴＴＰエンドポイントは、証明ルーチンを要求し、暗号化チャネルでデータを交換するように、フォーム「／ｆｒａｍｅ／ｕｐｌｏａｄ」から成り得る。ここでフレームは証明データおよびルーチンを指す。証明チケットに対する要求の他に、要求はまた、安全なセッションの妥当性確認に対する要求も含み得る。一部の場合には、セッションの妥当性確認に対する要求は、チケットが生成され、支払端末２０によって受信された後に送信され得る。例示のＨＴＴＰエンドポイントは、フォーム「／ｓｅｓｓｉｏｎ／ｖａｌｉｄａｔｅ」から成り得る。リーダ３を差し込むと、改ざんモニタリングコンポーネント７０は、減らしたチェックのセットを動作させ、その後、支払端末のアプリケーション２５が、リーダ３と通信することが可能であることを確認するように、サーバの改ざん検出コンポーネント８０でチェックする。続いてこれについて説明する。
説明および明快さのために、以下の記載は、デバイス、特に、支払デバイスまたはリーダ１０と対話する支払アプリケーション２５を実行している支払端末２０の証明に重点を置く。
ステップ８０３で、支払端末２０は証明トリガーを検出する。例えば、支払端末２０は、通信ポートとリーダ３との間の対話を検出し得る。証明トリガーの他の例は、限定するものではないが、新規リーダとＰＯＳ端末とを対にすること、支払アプリケーションを未知のデバイスへインストールすること、リーダまたはＰＯＳ端末が、例えば、不正であると知られている新規の場所へ再配置されたことを検出すること、不正なユーザのカード挿入を検出すること、不正なカードを検出すること、確立されたジオフェンス内で不正デバイスの入力を検出することなどを含む。そのため、証明チケットは、プラットフォームだけでなく、小売業者の店舗がある場所などの環境、ジオフェンスに進入する顧客もしくは支払オブジェクト、または支払デバイス（Ａｐｐｌｅ Ｗａｔｃｈ（登録商標）など）をも証明し得る。明らかに、小売業者により駆動されてもよい証明トリガーがある一方、支払端末２０周辺で、または支払端末２０に対して発生するイベントによって、開始されるものもある。
ステップ８０４で、支払端末２０は、支払サーバ５０へ要求を送信して、差し込まれたリーダ３による証明チケットの生成を促進するように要求してもよい。証明トリガー、例えば、差し込まれているリーダ３に応じて、支払端末２０は、支払サーバ５０が支払端末２０を証明する要求を生成する。ここで「証明トリガー」は、リーダ３との接続の検出であるが、しかしながら、証明トリガーは、様々であり得るか、またはいくつかのトリガーの組み合わせであり得る。改ざんモニタリングコンポーネント７０は、（ａ）起動時、（ｂ）ステップ８０２に示す通り、送信するデータを有するときはいつでも、および（ｃ）数分ごとに証明要求を送信することができ、これにより、サーバ５０に、必要なとき必要に応じて、新規コマンドを送信し証明する機会が定期的に与えられる。
一つの実施では、改ざんモニタリングコンポーネント７０は、ホワイトボックス暗号技術の下で鍵を使用して、証明チケットに対する要求を暗号化し得る。加えてまたは代替として、改ざんモニタリングコンポーネント７０は、ＨＴＴＰＳ暗号化および認証を適用することができ、要求をコード化するように全エンドポイントによって使用される。改ざんモニタリングコンポーネント７０は、例えば、ＨＴＴＰに基づき、証明プロトコルとも称される、暗号化および難読化通信プロトコルで証明チケット要求を送信する。本明細書では、改ざんモニタリングコンポーネント７０が起源である全要求またはデータは、「フレーム」の形態で表現され得る。
ステップ８０６で、サーバ５０は、証明チケット要求（例えば、コード化された）を受信し、要求と関連付けられるいかなるデータ、例えば、サーバ５０が依存し得る、任意の履歴データがあるかを示す状態データがあるかを判定する。加えて、データは、環境要因、デバイス識別子または小売業者識別子を含んでもよく、サーバ５０は、それらに基づいて、データと関連付けられるいかなる条件があるかを判定し得る。条件のうちの一つは、「オフラインモードでは証明しない」もしくは「小売業者が優良な状態を有するかを証明する」、または小売業者のアカウントがある基準に合致するかを証明するなどであってもよい。それに応じてサーバ５０は、端末が実行する証明ルーチンを生成する。証明ルーチンは、改ざんモニタリングコンポーネント７０が支払端末２０上で行う、一つ以上の改ざん対策チェック、データ収集スキャンおよび／もしくはテストを粒度で規定する、コマンド／テスト基準または単一のコマンドを含み得る。どのようなコマンドをどのような状況下で送信するかというポリシーは、改ざん検出コンポーネント８０の中でコード化され得る。一例では、証明ルーチンは、どのような端末がテストされているかにかかわらず、同じルーチンが送信され、異なる順序であってもよいように、固定することができる。他の例では、証明ルーチンは、端末のタイプ（ｉＯＳまたはＡｎｄｒｏｉｄ）、小売業者プロファイル、デバイスプロファイル、状況などに基づき得る。一部の場合には、ルーチンにおけるコマンドの順序はまた、改ざんモニタリングコンポーネント７０から取得する応答に基づき構成され得る。したがって、コマンドは、フローに予測不可能性を追加するために、ループして次々に送信される。例えば、端末２０への第２コマンドは、端末２０がどのように第１コマンドに応答するかに基づき構成される。一部の変形では、コマンドは、例えば、スクリプト言語を使用することによる、低レベルのクエリおよびコマンドである。
ステップ８０８で、サーバ５０は証明ルーチンを端末２０へ送信する。一部の実施では、改ざんモニタリングコンポーネント７０からの証明チケットの要求に続き、コマンドまたは証明ルーチンの形態で、改ざん検出コンポーネント８０から応答がある。一部の他の場合では、改ざん検出コンポーネント８０からのルーチンまたはコマンドに続き、改ざんモニタリングコンポーネント７０から結果が届く。
ステップ８１０で、改ざんモニタリングコンポーネント７０は、例えば、端末２０のスキャンまたはテストを伴う、証明ルーチンを実行する。証明ルーチンは、端末上で実施されると、例えば、ソフトウェアコードの一部分をハッシュ化すること、支払端末のメモリをスキャンすること、ソフトウェアコードのジェイルブレイクを調べること、取り付けられたファイルシステムのメタデータを集めることなどを引き起こし得る。
ステップ８１２で、改ざんモニタリングコンポーネント７０は、永続的データまたは証明データとも呼ばれる、ルーチンに対応するデータを取得し、フレームとしてコード化し、さらなる処理のためにサーバ５０へ送信する。改ざん検出コンポーネント８０は大抵ステートレスであるため、端末に関係する状態および全イベントは、クライアント側に保存され、攻撃者がいかなる手段でもデータにアクセスも利用もできないように、不透明なままである。上で言及した通り、この時点で改ざん検出コンポーネント８０は、より多くのコマンドによって追加情報を要求し得る。そのため、ステップ８０６〜８１２が繰り返される。ここでは、コマンドの一サイクルのみを交換すると想定する。永続化されたデータは、改ざんモニタリングコンポーネント７０が、改ざん検出コンポーネント８０から「ｓｅｔ＿ｐｅｒｓｉｓｔｅｄ＿ｄａｔａ」コマンドを受信するときに書き込まれる。永続化されたデータファイルが存在することができ、改ざんモニタリングコンポーネント７０が毎回上書きする。
永続化されたデータ／証明データが暗号化されているため、攻撃者はデータを読み取ることも、修正することも、偽造することもできないが、データはいつでも削除できる。このことから、永続化されたデータ／証明データが、「このデバイスは本チェックのセットに合格しました」など、「有利な」データを記憶するのに役立つ。一部の場合には、攻撃者が常に削除できるため、「このクライアント上で改ざんが検出されました」など、「不利な」データがある。しかしながら、一部の場合、「ｌａｓｔＤｅｎｙＴｉｍｅｓｔａｍｐ」などの不利なデータを保存し得る。
一例では、証明データは、プロトコルのバージョンをコード化する４バイトの整数、次のフィールドの長さをコード化する４バイトの整数、および可変長の暗号文ｂｌｏｂを含んでもよい。暗号文は、「チケット」のような他の属性を記憶するように、暗号化されたＪＳＯＮオブジェクトであることができ、チケットオブジェクトを包含する。改ざんモニタリングコンポーネント７０は、フレームを改ざん検出コンポーネント８０へ送信するときはいつでも、８１２に示すｐｅｒｓｉｓｔｅｄ＿ｄａｔａメッセージに現在の証明データを含む。永続化されたデータ（またはその要素のいずれか）のフォーマットが変化するとき、プロトコルのバージョン数が増加する。改ざん検出コンポーネント８０は、期限切れのバージョンを伴う証明データを受信した場合は、無視して最終的には上書きする。
永続化されたデータもまた、例えば、１２８ビットの鍵を伴うＡＥＳ‐ＧＣＭを使用して、暗号化され認証され得る。一実施形態では、暗号化および復号は、サーバ側で、すなわち、証明データがクライアントに対して完全に不透明であるために生じる。全サーバは、鍵管理システム（図示せず）によって記憶され提供される、同じ鍵を使用する。
改ざん検出コンポーネント８０は、永続化されたデータを復号しない場合（例えば、ＭＡＣが不良のため）には、プロトコルのバージョンが期限切れであったかのように、データを破棄する。不良のＭＡＣはまた、改ざんの信号として使用され得る。
ステップ８１４で、サーバ５０は、既知の動作と、または支払プラットフォームの集団に渡って収集した、信頼性をもって測定されたデータ、もしくはセキュリティの専門家により判定された事前設定値に、証明データの基礎を置くことによって、コード化された証明データを比較する。データが合致する場合、サーバ５０は、端末５０が安全であるという正当性を確認する、証明チケットを生成する。データがそれほど合致しない場合、チケットは拒絶され、改ざんモニタリングコンポーネント７０に通知される。この場合、改ざんモニタリングコンポーネント７０は、しばらくの後、要求を再提出し得る。前に言及した通り、チケットは、所与のデバイス上で動作され、成功または予想される応答を返してきたチェックの要約である。チケットは、タイムスタンプおよびクライアント識別子という、二つのタイプの情報を含んでもよい。タイムスタンプは、前回ある特定タイプのイベントが、デバイスに対して発生した時間を示し、「拒絶」および「承認」といった、様々なタイプのイベントを追跡し得る。「拒絶」は、改ざん検出コンポーネント８０が、問題を示すコマンド結果を確認するときいつでも生じ得る。「承認」は、改ざん検出コンポーネント８０が、送信するさらなるコマンドを有さず、かつ「拒絶」イベントも有していなかった場合に生じる。一つの例示的な実施では、タイムスタンプは、エポックを過ぎて数秒後であり、サーバのクロックを使用する。
クライアント識別子は、ある特定のデバイスを識別する文字列である。改ざんモニタリングコンポーネント７０は、全フレームでデバイス識別子の１セットを送信し、正確なセットはプラットフォームによる。「デバイス識別子」は、改ざんモニタリングコンポーネント７０が送信する未加工データを指し、「クライアント識別子」は、改ざん検出コンポーネント８０により抽出される特徴のセットを指す。クライアント識別子はまた、改ざんモニタリングコンポーネント７０のメッセージと関連付けられるＨＴＴＰヘッダから抽出され得る（しかし、これらは改ざんするのがより容易である場合がある）。
すべてのフレーム改ざんモニタリングコンポーネント７０は、１セットのデバイス識別子を送信し有する。クライアントがいずれかの永続化されたデータを有する場合は、ｐｅｒｓｉｓｔｅｄ＿ｄａｔａメッセージも存在するであろう。それゆえ、改ざん検出コンポーネント８０は常に、存在する場合には、改ざんモニタリングコンポーネント７０の以前のチケットを確認し得る。通信プロセス中、改ざん検出コンポーネント８０は、「承認」または「拒絶」イベントに遭遇した場合、現在のチケットを更新し、クライアントに「ｓｅｔ＿ｐｅｒｓｉｓｔｅｄ＿ｄａｔａ」コマンドを伴い送信し戻す。通信プロセスの終了までに、改ざん検出コンポーネント８０は、二つのイベントの少なくとも一つ、すなわち、問題に遭遇した（「拒絶」）、または問題なくチェックのすべてが終了した（「承認」）のいずれかに遭遇していなくてはならない。
ステップ８１６で、サーバ５０の改ざん検出コンポーネント８０（改ざんモニタリングコンポーネント７０のコンパニオン）は、証明チケットを生成する。他の実施では、改ざん検出コンポーネント８０は、改ざんモニタリングコンポーネント７０から、証明チケットに対するコード化された要求を受信し、その後、例えば、デコードし、続いてチケットを生成する暗号９５を、サーバ５０内の別のコンポーネントへ送信する。これについてはさらに、図８Ｄで議論する。この実施では、改ざん検出コンポーネント８０は、特に、チケットを要求する端末用に証明チケットを生成する。一部の実施では、改ざん検出コンポーネント８０は、デバイスの集団と比較すると、状態データおよび他のデータを含む要求が異常を示すときのみ、チケットを生成する。例として、チケットは実質的にフォームから成り得る。
｛”ｌａｓｔＡｐｐｒｏｖｅＴｉｍｅｓｔａｍｐ”： １８９４５７９８４，
”ｌａｓｔＤｅｎｙＴｉｍｅｓｔａｍｐ”： １４４３８７５８７５８５，
”ｃｌｉｅｎｔＩｄ”： ｛
”ｉｄ＿ＯＳ＿ｃａｒｄ＿ｄａｔａ”： ”￥”ｖｄｊｆｈｇｉｕｇ＝＝￥””，
"ｉｄ＿ＯＳ＿ｒｏ＿ｓｅｒｉａｌｎｏ”： ”￥”ＨＬＯＩＯ￥””，
”ｉｄ＿ｈｅａｄｅｒ＿ｉｎｓｔａｌｌａｔｉｏｎ”： ”￥”ｉｏｒｅｕｔｉｏｒｅｕｔ￥””，
”ｉｄ＿ＯＳ＿ｒｏ＿ｂｏｏｔ＿ｓｅｒｉａｌｎｏ”： ”￥”ｒｅｔｏｉｒｔｏｅｒｉｔ０￥””｝｝
”ｌａｓｔＤｅｎｙＴｉｍｅｓｔａｍｐ”： １４４３８７５８７５８５，
”ｃｌｉｅｎｔＩｄ”： ｛
”ｉｄ＿ＯＳ＿ｃａｒｄ＿ｄａｔａ”： ”￥”ｖｄｊｆｈｇｉｕｇ＝＝￥””，
"ｉｄ＿ＯＳ＿ｒｏ＿ｓｅｒｉａｌｎｏ”： ”￥”ＨＬＯＩＯ￥””，
”ｉｄ＿ｈｅａｄｅｒ＿ｉｎｓｔａｌｌａｔｉｏｎ”： ”￥”ｉｏｒｅｕｔｉｏｒｅｕｔ￥””，
”ｉｄ＿ＯＳ＿ｒｏ＿ｂｏｏｔ＿ｓｅｒｉａｌｎｏ”： ”￥”ｒｅｔｏｉｒｔｏｅｒｉｔ０￥””｝｝
それに応じて、改ざん検出コンポーネント７０は、ステップ８１６に示す通り、証明チケットを生成する。他の実施では、チケットは承認シナリオで生成のみされる。改ざん検出コンポーネント８０はまた、時間の有効期限および持続時間以外に、証明チケットに関する妥当性条件を適用し得る。例えば、証明チケットは、あるアプリケーションに対して、またはあるタイプもしくはある数のトランザクションに対して、端末２０の一部分を証明のみしてもよく、そのような条件は、チケット上に設定され得る。証明チケットおよび状態／証明データは、ステップ８１８に示す通り、改ざん検出コンポーネント７０へ再送信され得る。このステップで、モニタリングコンポーネントにより送信されるデータを使用して、サーバはまた、要求するデバイスと接続されるリーダとの間に安全なセッションを設定するように、セッション証明書を生成し得る。
ステップ８２０で、証明データおよび／またはチケットは、例えば、Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＨＤＦＳ）といった安全なデータベースに記憶され得る。証明ルーチンの取り込み後、支払サーバ５０は、所定の期間中に支払プラットフォームを信頼できると指定し、将来の全対話用に証明チケットを指定する。加えて、支払サーバ５０は、安全なセッションを確立するセッション証明書も生成し得る。期間が経過すると、証明ルーチンは、二度目となる支払プラットフォームの証明のために、再開し再実行され得る。
ステップ８２２で、証明チケットはまた、一実施形態では、セッションが確立されたおよび／または正当性が確認されたと示す、セッション証明書を伴い得る。別の実施形態では、別個のセッション証明書が、続いて記載する別個のプロセスによって要求され得る。ユーザがリーダ３に差し込むと、妥当性確認プロセスが開始される。このプロセスでの改ざんモニタリングコンポーネント７０の役割は、より小さいチェックのセットを動かし、その後、（ａ）それらのチェックの結果、（ｂ）セットが動いているデバイスを識別するデータ、および（ｃ）前回のｓｅｔ＿ｐｅｒｓｉｓｔｅｄ＿ｄａｔａコマンドにより書き込まれたデータを包含するフレームを組み合わせることである。このフレームは、セッション妥当性確認要求へ添付され、改ざん検出コンポーネント８０のセッション／正当性確認エンドポイントへ送信される。
このセッション妥当性確認要求を評価するとき、改ざん検出コンポーネント８０は、チケットを復号し、（ａ）改ざんモニタリングコンポーネント７０が最近通信プロセスを行ったこと、（ｂ）問題は見つからなかったこと、および（ｃ）プロセスは、現在の妥当性確認プロセスが動いている、同じデバイス上で動かされたことをチェックする。
証明時の他のチェックと共に、改ざん検出コンポーネント８０はまた、永続化されたデータからチケットを抽出し、接続済みのリーダ用、または他のデバイスとのいかなる将来の接続用に、安全なセッションの正当性を確認するように試み得る。改ざん検出コンポーネント８０からの他のチェックのように、チケットの妥当性確認プロセスは設定可能である。チケットが存在しない；チケットが「ｌａｓｔＡｐｐｒｏｖｅＴｉｍｅｓｔａｍｐ」を有さない；チケットは「ｌａｓｔＡｐｐｒｏｖｅＴｉｍｅｓｔａｍｐ」を有さないが、遠い過去には有していた可能性がある；チケットが「ｌａｓｔＤｅｎｙＴｉｍｅｓｔａｍｐ」を有する；チケットの中のクライアント識別子が、現在のフレームのものと合致しない；ある必須のクライアント識別子が、チケットから失われている、リーダが接続していない、または正しく接続していない場合がある、リーダが不正確なポート、すなわち、不正オブジェクトに接続している場合がある、ユーザまたは買い手のデバイスが、ジオフェンスの中で検出される場合があるなど、以上の理由のいずれかにより、セッションが拒絶され得る。しかしながら、ステップ８２６に示す通り、セッションの正当性が確認できない場合、支払端末は、チケットに拒絶の理由を記憶し、ステップ８２８で行う通り、更新を必要とする場合がある、いかなるコンポーネントも更新し得る。
図８Ｂは、本開示の一部実施形態に従い、証明済みの端末と支払オブジェクトリーダとの間に安全なセッションを確立する、データフロー８３０を描写する。一実施形態では、図８Ｂに描写する通り、ステップ８３０は、支払リーダ３、支払端末（小売業者デバイスとも称される）２０、および支払サーバ５０（すなわち、支払処理システム５０による）などの支払端末デバイスによって行われる。これらのステップは、一実施形態では、ある特定のデバイスによって行われていると記載されるものの、デバイス間のステップの割り当てが、いかなる好適な方式で修正されてもよく、またはステップを行うデバイスの数が、いかなる好適な方式で修正されてもよいことは、理解されるであろう。さらに、方法８３０は、支払デバイスの名前に対する証明チケットの前の履歴がない、初めて生成されるチケットに適用され、証明チケットを更新するように要求するデバイスを求め得る。
ステップ８３２で、支払端末２０は、リーダ３と作った接続を検出すると、以前に指定された証明チケットを送信してもよい。任意で、接続もしくは再起動、または、例えば、証明トリガーに類似する、いかなる他のトリガーの検出のみで、リーダと端末との間に安全なセッションを確立するプロセスを開始し得る。一例では、安全なセッションにより、二つのデバイス間の安全な情報交換が可能になる。そのとき、リーダ３は、端末２０は改ざんされていないと保証するように、セッション承認を要求し得る。他のトリガーにより、リーダ３に、支払端末から証明チケットを受信させ得る。リーダ３は、この妥当性確認プロセスを一度行い、その妥当性が持続する間は、セッション承認を要求しなくてもよい。一部の例では、安全なセッションの妥当性は、リーダ３との接続が切れるか、またはそうでなければ、リーダ３が利用できなくなるとすぐに、有効期限が切れるが、それは、これが信頼できるデバイスから信頼できないデバイスへの、端末２０の切り替えを示す可能性があるからである。
ステップ８３４‐１および８３４‐２で、リーダ３は、端末が改ざんされておらず、そうでなければ、セキュリティ脅威とも関連付けられないことを立証するように、支払トランザクションに応じて、以前に指定された証明チケットを支払端末２０から受信し得る。リーダ３はまた、端末２０から公開鍵と、端末２０が動いているデバイスの状態を要約するフレームとを受信し得る。端末のフレームはまた、証明エンドポイントとの以前の対話より保存されたデータを包含し得る。このデータは、支払サーバ５０によって暗号化され、クライアントデバイス上に記憶され、セッション妥当性確認時にフレームに入れて送信され、サーバへ戻される。
リーダ３は、送信されるべき場所、および有効期限ｌａｓｔ＿ｄｅｎｙ＿ｔｉｍｅｓｔａｍｐなど、他の基本情報を判定するように、チケットの少なくとも一部分をデコードし得る。一部の実施では、リーダ３は、読み取り得るデータの一部分に完全に基づき、ローカルの決定を下し得る。例えば、オフラインモードでは、リーダ３は、その他の点では有効な証明チケットの妥当性を拒否することを選んで、関連するリスクを減らし得る。他の実施では、リーダ３は、検証のため、支払サーバ５０がさらなるセッション承認を提供し得るように、証明チケットを支払サーバ５０へ送信する。証明チケットのコンテンツについて、ステップ８１６に関して記載してきた。しかしながら、この証明チケットは、リーダのタイプ、セッションが要求された時間、トランザクションのタイプ、リーダと端末との間の接続のタイプ、端末と関連付けられるトランザクションの履歴などに関連する、リーダ３により加えられる、修正されコード化される情報を含んでもよい。そのような情報はまた、製造時に支払サーバ５０によって提供される、リーダ識別子またはセキュリティ証明書を含み得る。他の例では、証明チケットは暗号化され、リーダ３および端末２０に対して完全に不透明である。証明チケットは限定された期間のみ有効であるため、これは、クライアントがチケットの期限が切れたか否かを教えられないことを意味する。これが原因の一つとなり、クライアントは、最近のチケットを獲得せずにセッション妥当性確認を求めて、サーバに疑似承認または疑似拒絶のいずれかを与えさせてもよい。一部の場合には、ステップ８３４‐１および８３４‐２に示す通り、リーダ３は、支払端末２０へ要求を送信することができ、その後、支払端末２０が要求を支払サーバ５０へ送信する。
ステップ８３６で、リーダ３は、セッション要求を支払サーバ２０へ送信する。ステップ８３８で、支払サーバ２０は、リーダ３から受信したチケットが有効かを判定し、さらに、安全なセッションの承認を妨げる、チケットと関連付けられたいかなる他の条件があるかを判定するように、チケットを分析する。一部の例では、リーダ３は、改ざん検出コンポーネント８０へチケットを送信する。改ざん検出コンポーネント８０はその後、暗号コンポーネント（暗号）９５へチケットを送信し、ＨＳＭ９８および提供される特殊な鍵と組み合わせてチケットを復号する。鍵は、ＨＭＡＣによって例示するために、チケットに埋め込まれた端末２０およびリーダ３の鍵と比較される。鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）は、秘密暗号鍵と組み合わせて、暗号ハッシュ機能（故に、「Ｈ」）を伴う、特定タイプのメッセージ認証コード（ＭＡＣ）である。また、他の技術を使用してもよいことは、理解されるであろう。
一つの例示の実施では、暗号９５は、リーダ３からの「ｓｅｃｕｒｅ＿ｓｅｓｓｉｏｎ＿ｉｎｉｔ」要求をデコードし、改ざん検出コンポーネント８０へコンテンツを提供する。これには、ＨＳＭ９８に記憶される鍵を使用して、メッセージのＨＭＡＣをチェックすることを含む。改ざん検出コンポーネント８０は、端末２０が安全な環境で動いているかを判定する。これを行うために、改ざん検出コンポーネント８０は、デコードされた要求からの情報、リーダ３からのフレーム（証明データ）、およびブラックリストまたはホワイトリストなど、記憶されたいかなる情報を使用する。改ざん検出コンポーネント８０が、安全なセッションを承認することを決定したと想定すると、改ざん検出コンポーネント８０は、セッションに対して最大の持続時間およびトランザクション数を選択し、暗号９５で承認メッセージをコード化する。このメッセージもまた、ＨＳＭ９８の中の鍵を使用してコード化される。
ステップ８３８‐１および８３８−２で、コード化されたセッション承認は、支払端末および／またはリーダ３へ送信され、ステップ８４０に示す通り、安全なセッションが、現在および将来のトランザクション用に、リーダ３と端末２０との間に確立される。サーバ２０は、セッションの正当性が確認され安全である限り、証明をチェックする必要はない。
ステップ８４２で行われる通り、分析後に端末２０および／または暗号９５によって、セッションを無効にしてもよい実施がある。その後、セッション要求の拒絶が、記憶するために、およびリーダ３がすべての支払トランザクションを拒絶するためにも、端末２０および／またはリーダ３へ送信され得る。
図８Ｃは、本開示の一部実施形態に従い、支払端末、もしくは小売業者に属するいかなる他の小売業者デバイスの正当性を確認する証明チケットを生成し、また、フェイルオーバー配列を使用して、証明済み端末と支払オブジェクトリーダとの間に安全なセッションを確立する、データフロー８５０を描写する。一実施形態では、図８Ｃに描写する通り、プロセス８５０のステップは、支払リーダ３、支払端末（小売業者デバイスとも称される）２０、および支払サーバ５０（すなわち、支払処理システム５０による）などの支払端末デバイスによって行われる。これらのステップは、一実施形態では、ある特定のデバイスによって行われていると記載されるものの、デバイス間のステップの割り当てが、いかなる好適な方式で修正されてもよく、またはステップを行うデバイスの数が、いかなる好適な方式で修正されてもよいことは、理解されるであろう。さらに、方法８５０は、支払デバイスの名前に対する証明チケットの前の履歴がない、初めて生成されるチケットに適用され、証明チケットを更新するように要求するデバイスを求め得る。
本明細書に記載する通り、改ざんモニタリングコンポーネント７０がデバイスをスキャンした後、サーバ５０は、デバイス上に記憶される（期間限定）チケットを生成する。安全なセッション妥当性確認時に、サーバ５０は、それらのチェックを再度動かす代わりに、チケットを検査し得る。それゆえ、改ざん検出コンポーネント５０のタスクは二つに分割される。作動部により前と同じ公開エンドポイントを提供するが、公開エンドポイントが行う作業は、デバイスが改ざんモニタリングコンポーネントによって問題なくスキャンされたと証明するチケットを作り出して、正当性を確認することのみである。これは、例えば、証明サブシステム３２３によって行われる。スキャンを指示して評価する作業は、改ざん検出コンポーネント３４４に記憶される妥当性確認論理へ転送される。改ざん検出コンポーネント３４４がダウンする場合、フロント部は、改ざん検出コンポーネント３４４が全デバイスを承認すると装うことによって、「フェイルオープン」し得る。これは、セキュリティが無効になってもよい、一定期間が存在するであろうことを意味するが、しかしながら、これらの期間は顕著であり、攻撃者の制御下ではないであろう。他の実施では、一つが失敗すると他方が引き継ぐように、様々な場所に渡って記憶される、複数の改ざん検出コンポーネント３４４があってもよい。この意味では、フェイルオーバーシステムは可用性が高くステートレスであり、妥当性確認プロセスのリスクを減らしながら、証明チケットを生成する速度を上げる。
チケットの作成およびチケットの妥当性確認の両方は、高可用性であり得る。これは、改ざん検出時にチケットが作り出されるからであり、改ざん検出がダウンする場合、一部のクライアントはチケットを得られないであろう。それらのクライアントが安全なセッションを得ようと試みるとき、セッション妥当性確認コンポーネントは、失われているチケットがサーバの故障によるものか、または悪質な行為によるものか知らなくてもよい。これが、改ざん検出コンポーネントが働いていない場合でさえも、システムは常に、チケットを作り出すことができる理由である。他の例では、一方または他方が高可用性であってもよい。延長時間中、検出論理がダウンする場合、セッションの持続時間は、一部の場合には、リスクに基づき無期限とされ得る。
図面に戻ると、ステップ８５２で、改ざんモニタリングコンポーネント７０によって支払端末２０は、支払サーバ５０に周期的にチェックインし、有効な証明チケットの候補であるかを判定するように、支払端末２０上でスキャンおよびテストの完全なセットを動作させる。これはまた「周期的スキャン」とも称される。例示のＨＴＴＰエンドポイントは、証明ルーチンを要求し、暗号化チャネルでデータを交換するように、フォーム「／ｆｒａｍｅ／ｕｐｌｏａｄ」から成り得る。ここでフレームは証明データおよびルーチンを指す。証明チケットに対する要求の他に、要求はまた、安全なセッションの妥当性確認に対する要求も含み得る。一部の場合には、セッションの妥当性確認に対する要求は、チケットが生成され、支払端末２０によって受信された後に送信され得る。例示のＨＴＴＰエンドポイントは、フォーム「／ｓｅｓｓｉｏｎ／ｖａｌｉｄａｔｅ」から成り得る。リーダ３を差し込むと、改ざんモニタリングコンポーネント７０は、減らしたチェックのセットを動作させ、その後、支払端末のアプリケーション２５が、リーダ３と通信することが可能であることを確認するように、サーバの改ざん検出コンポーネント８０でチェックする。続いてこれについて説明する。
ステップ８５２に示す通り、証明チケットに対する要求は、支払サーバ５０の証明システム３２３へ送信され、その後、ステップ８５４で、改ざん検出コンポーネントへ転送される。ステップ８５２での要求は、証明トリガーを検出する支払端末２０の結果としてであってもよい。例えば、支払端末２０は、通信ポートとリーダ３との間の対話を検出し得る。証明トリガーの他の例は、限定するものではないが、新規リーダとＰＯＳ端末とを対にすること、支払アプリケーションを未知のデバイスへインストールすること、リーダまたはＰＯＳ端末が、例えば、不正であると知られている新規の場所へ再配置されたことを検出すること、不正なユーザのカード挿入を検出すること、不正なカードを検出すること、確立されたジオフェンス内で不正デバイスの入力を検出することなどを含む。そのため、証明チケットは、プラットフォームだけでなく、小売業者の店舗がある場所などの環境、ジオフェンスに進入する顧客もしくは支払オブジェクト、または支払デバイス（Ａｐｐｌｅ Ｗａｔｃｈ（登録商標）など）をも証明し得る。明らかに、小売業者により駆動されてもよい証明トリガーがある一方、支払端末２０周辺で、または支払端末２０に対して発生するイベントによって、開始されるものもある。
ステップ８５６で、改ざん検出コンポーネント３４４は、証明チケット要求（例えば、コード化された）を受信し、要求と関連付けられるいかなるデータ、例えば、改ざん検出コンポーネント３４４が依存し得る、任意の履歴データがあるかを示す状態データがあるかを判定する。加えて、データは、環境要因、デバイス識別子または小売業者識別子を含んでもよく、改ざん検出コンポーネント３４４は、それらに基づいて、データと関連付けられるいかなる条件があるかを判定し得る。条件のうちの一つは、「オフラインモードでは証明しない」もしくは「小売業者が優良な状態を有するかを証明する」、または小売業者のアカウントがある基準に合致するかを証明するなどであってもよい。それに応じて、改ざん検出コンポーネント３４４は、端末が実行する証明ルーチンを生成する。証明ルーチンは、改ざんモニタリングコンポーネント７０が支払端末２０上で行う、一つ以上の改ざん対策チェック、データ収集スキャンおよび／もしくはテストを粒度で規定する、コマンド／テスト基準または単一のコマンドを含み得る。どのようなコマンドをどのような状況下で送信するかというポリシーは、改ざん検出コンポーネント３４４の中でコード化され得る。一例では、証明ルーチンは、どのような端末がテストされているかにかかわらず、同じルーチンが送信され、異なる順序であってもよいように、固定することができる。他の例では、証明ルーチンは、端末のタイプ（ｉＯＳまたはＡｎｄｒｏｉｄ）、小売業者プロファイル、デバイスプロファイル、状況などに基づき得る。小売業者プロファイル（小売業者アカウント情報、在庫情報、デモグラフィック情報、地理的場所、購入の主体、連続するトランザクション間の経過時間、総収益額、および類似のもの）、および顧客プロファイル（顧客または小売業者イベントなど、例えば、支払拒否（購入トランザクションの不和）、不履行、滞納、不正、顧客へ登録された支払オブジェクト、顧客へ登録されたデバイス、顧客優先傾向（例えば、クレジットカードのみ使用）、顧客の名前または支払オブジェクトに対して行われた全トランザクションを示す顧客トランザクション履歴など）は、端末またはサーバ上のいずれかに保存することができ、一部の例では、あるサブセットは、例えば、キャッシュメモリの中といった、リーダ上に保存され得る。プロファイルは、買い手のトランザクション履歴を捕捉し、買い手の購買行動（例えば、頻度）および興味を表す。例えば、買い手が家庭用電化製品およびスポーツアクセサリーの大量購入者である場合、カテゴリ「スポーツ用品」および「家庭用電化製品」が買い手に指定されてもよい。買い手のプロファイルはまた、Ａｐｐｌｅ Ｐａｙ（登録商標）またはＧｏｏｇｌｅ Ｗａｌｌｅｔ（登録商標）など、非接触型支払と関連付けられる買い手の識別子を含み得る。そのような買い手の識別子は、買い手が非接触型支払のそのような選択肢に登録した後、買い手の電話へ送信されてもよい。
一部の場合には、ルーチンにおけるコマンドの順序はまた、改ざんモニタリングコンポーネント７０から取得する応答に基づき構成され得る。したがって、コマンドは、フローに予測不可能性を追加するために、ループして次々に送信される。例えば、端末２０への第２コマンドは、端末２０がどのように第１コマンドに応答するかに基づき構成される。一部の変形では、コマンドは、例えば、スクリプト言語を使用することによる、低レベルのクエリおよびコマンドである。
ステップ８５８で、改ざん検出コンポーネント３４４は、証明ルーチンを証明システム３２３へ送信し、その後、ステップ８６０に示す通り、証明システム３２３が端末２０へ転送する（例えば、暗号化の後）。
ステップ８６２で、改ざんモニタリングコンポーネント７０は、例えば、端末２０のスキャンまたはテストを伴う、証明ルーチンを実行する。証明ルーチンは、端末上で実施されると、例えば、ソフトウェアコードの一部分をハッシュ化すること、支払端末のメモリをスキャンすること、ソフトウェアコードのジェイルブレイクを調べること、取り付けられたファイルシステムのメタデータを集めることなどを引き起こすことができ、ステップ８６４でそのようなデータを証明システム３２３へ送信し、その後、ステップ８６６で改ざん検出コンポーネント３４４へ転送される。
ステップ８６８で、証明システム３２３は、永続的データまたは証明データとも呼ばれる、ルーチンに対応するデータを取得し、フレームとしてコード化し、証明システム３２３へ送信して、その後、比較のために改ざん検出コンポーネント３４４へ転送される。永続化されたデータ／証明データが暗号化されているため、攻撃者はデータを読み取ることも、修正することも、偽造することもできないが、データはいつでも削除できる。このことから、永続化されたデータ／証明データが、「このデバイスは本チェックのセットに合格しました」など、「有利な」データを記憶するのに役立つ。一部の場合には、攻撃者が常に削除できるため、「このクライアント上で改ざんが検出されました」など、「不利な」データがある。しかしながら、一部の場合、「ｌａｓｔＤｅｎｙＴｉｍｅｓｔａｍｐ」などの不利なデータを保存し得る。
一例では、証明データは、プロトコルのバージョンをコード化する４バイトの整数、次のフィールドの長さをコード化する４バイトの整数、および可変長の暗号文ｂｌｏｂを含んでもよい。暗号文は、「チケット」のような他の属性を記憶するように、暗号化されたＪＳＯＮオブジェクトであることができ、チケットオブジェクトを包含する。改ざんモニタリングコンポーネント７０は、フレームを改ざん検出コンポーネント８０へ送信するときはいつでも、８１２に示すｐｅｒｓｉｓｔｅｄ＿ｄａｔａメッセージに現在の証明データを含む。永続化されたデータ（またはその要素のいずれか）のフォーマットが変化するとき、プロトコルのバージョン数が増加する。改ざん検出コンポーネント８０は、期限切れのバージョンを伴う証明データを受信した場合は、無視して最終的には上書きする。
永続化されたデータもまた、例えば、１２８ビットの鍵を伴うＡＥＳ‐ＧＣＭを使用して、暗号化され認証され得る。一実施形態では、暗号化および復号は、サーバ側で、すなわち、証明データがクライアントに対して完全に不透明であるために生じる。全サーバは、鍵管理システム（図示せず）によって記憶され提供される、同じ鍵を使用する。
改ざん検出コンポーネント３４４は、永続化されたデータを復号しない場合（例えば、ＭＡＣが不良のため）には、プロトコルのバージョンが期限切れであったかのように、データを破棄する。不良のＭＡＣはまた、改ざんの信号として使用され得る。
ステップ８６８で、改ざん検出コンポーネント３４４は、既知の動作と、または支払プラットフォームの集団に渡って収集した、信頼性をもって測定されたデータ、もしくはセキュリティの専門家により判定された事前設定値に、証明データの基礎を置くことによって、コード化された証明データを比較する。データが合致する場合、サーバ５０は、ステップ８７０にて、例えば、プレーンテキストフォーマットで、端末５０が安全であるという正当性を確認する、証明チケットを生成する。データがそれほど合致しない場合、チケットは拒絶され、証明システム３２３によって改ざんモニタリングコンポーネント７０に通知される。この場合、改ざんモニタリングコンポーネント７０は、しばらくの後、要求を再提出し得る。前に言及した通り、チケットは、所与のデバイス上で動作され、成功または予想される応答を返してきたチェックの要約である。チケットは、タイムスタンプおよびクライアント識別子という、二つのタイプの情報を含んでもよい。タイムスタンプは、前回ある特定タイプのイベントが、デバイスに対して発生した時間を示し、「拒絶」および「承認」といった、様々なタイプのイベントを追跡し得る。「拒絶」は、改ざん検出コンポーネント８０が、問題を示すコマンド結果を確認するときいつでも生じ得る。「承認」は、改ざん検出コンポーネント８０が、送信するさらなるコマンドを有さず、かつ「拒絶」イベントも有していなかった場合に生じる。一つの例示的な実施では、タイムスタンプは、エポックを過ぎて数秒後であり、サーバのクロックを使用する。
クライアント識別子は、ある特定のデバイスを識別する文字列である。改ざんモニタリングコンポーネント７０は、全フレームでデバイス識別子の１セットを送信し、正確なセットはプラットフォームによる。「デバイス識別子」は、改ざんモニタリングコンポーネント７０が送信する未加工データを指し、「クライアント識別子」は、改ざん検出コンポーネント８０により抽出される特徴のセットを指す。クライアント識別子はまた、改ざんモニタリングコンポーネント７０のメッセージと関連付けられるＨＴＴＰヘッダから抽出され得る（しかし、これらは改ざんするのがより容易である場合がある）。
すべてのフレーム改ざんモニタリングコンポーネント７０は、１セットのデバイス識別子を送信し有する。クライアントがいずれかの永続化されたデータを有する場合は、ｐｅｒｓｉｓｔｅｄ＿ｄａｔａメッセージも存在するであろう。それゆえ、改ざん検出コンポーネント８０は常に、存在する場合には、改ざんモニタリングコンポーネント７０の以前のチケットを確認し得る。通信プロセス中、改ざん検出コンポーネント８０は、「承認」または「拒絶」イベントに遭遇した場合、現在のチケットを更新し、クライアントにｓｅｔ＿ｐｅｒｓｉｓｔｅｄ＿ｄａｔａコマンドを伴い送信し戻す。通信プロセスの終了までに、改ざん検出コンポーネント８０は、二つのイベントの少なくとも一つ、すなわち、問題に遭遇した（「拒絶」）、または問題なくチェックのすべてが終了した（「承認」）のいずれかに遭遇していなくてはならない。
改ざん検出コンポーネント３４４がチケットを戻す場合、証明システム３２３は、ステップ８７２に示す通り、クライアント２０へ戻す前に、チケットを包み、暗号化し、署名する。改ざん検出コンポーネント３４４は、デバイスの承認ステータス、有効期限日、および場合により、一部の追加状態を包含するプレーンテキストデータ構造で、チケットを返してもよい。しかしながら、チケット証明システム３２３の返送は、大部分暗号化され、暗号文の中にチケットを包含する。デバイスが承認されない場合でさえ、クライアントは常にチケットを手に入れるが、デバイスは、セッション妥当性確認ステップまで承認されるか分からない。
改ざん検出コンポーネント３４４が利用できない場合、証明システム３２３は、とにかく承認済み「緊急」チケットを作り出す。このチケットは、通常より短い有効期限を有する可能性がある。
ステップ８７４で、支払端末２０は、リーダ３と作った接続を検出すると、例えば、ステップ８７２または以前のステップに関する、以前に指定された証明チケットを送信し得る。そのとき、リーダ３は、端末２０は改ざんされていないと保証するように、セッション承認を要求し得る。他のトリガーにより、リーダ３に、支払端末から証明チケットを受信させ得る。リーダ３は、この妥当性確認プロセスを一度行い、その妥当性が持続する間は、セッション承認を要求しなくてもよい。一部の例では、安全なセッションの妥当性は、リーダ３との接続が切れるか、またはそうでなければ、リーダ３が利用できなくなるとすぐに、有効期限が切れるが、それは、これが信頼できるデバイスから信頼できないデバイスへの、端末２０の切り替えを示す可能性があるからである。
ステップ８７６で、証明システムは、要求をデコードすることができ、例えば、証明システム３２３ｔは、チケットを暗号コンポーネント（暗号）９５へ送信し、ＨＳＭ９８および提供される鍵と組み合わせて、チケットを復号する。鍵は、ＨＭＡＣによって例示するために、チケットに埋め込まれた端末２０およびリーダ３の鍵と比較される。鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）は、秘密暗号鍵と組み合わせて、暗号ハッシュ機能（故に、「Ｈ」）を伴う、特定タイプのメッセージ認証コード（ＭＡＣ）である。また、他の技術を使用してもよいことは、理解されるであろう。
ステップ８７８で、証明システム３２３は、デコードされたセッション妥当性確認要求を生成し、ステップ８８０で、改ざん検出コンポーネント３４４へ送信する。８９０で、改ざん検出コンポーネント３４４は、セッションパラメータを取得するように要求を評価する。このセッション妥当性確認要求を評価するとき、改ざん検出コンポーネント３４４は、（ａ）改ざんモニタリングコンポーネント７０が最近通信プロセスを行ったこと、（ｂ）問題は見つからなかったこと、および（ｃ）プロセスは、現在の妥当性確認プロセスが動いている、同じデバイス上で動かされたことをチェックする。改ざん検出コンポーネント３４４が、安全なセッションを承認することを決定したと想定すると、改ざん検出コンポーネント８０は、セッションに対して最大の持続時間およびトランザクション数を選択し、暗号９５で承認メッセージをコード化する。このメッセージもまた、ＨＳＭ９８の中の鍵を使用してコード化される。
ステップ８９２で、コード化されたセッション承認は、支払端末および／またはリーダ３へ送信され、例えば、暗号を使用してセッション承認をコード化する証明システム３２３によって、ステップ８９６に示す通り、安全なセッションが、現在および将来のトランザクション用に、リーダ３と端末２０との間に確立される。サーバ２０は、セッションの正当性が確認され安全である限り、証明をチェックする必要はない。
図８Ｄは、本開示の一部実施形態に従い、支払サーバ５０内で安全に証明データに対処する、データフロー８０５を描写する。一実施形態では、図８Ｄに描写する通り、ステップ８０５は、支払リーダ３、支払端末（小売業者デバイスとも称される）２０、および改ざん検出コンポーネント８０とＨＳＭ９８を伴う暗号９５とを有する支払サーバ５０（すなわち、支払処理システム５０による）などの支払端末デバイスによって行われる。これらのステップは、一実施形態では、ある特定のデバイスによって行われていると記載されるものの、デバイス間のステップの割り当てが、いかなる好適な方式で修正されてもよく、またはステップを行うデバイスの数が、いかなる好適な方式で修正されてもよいことは、理解されるであろう。さらに、方法８０５は、支払デバイスの名前に対する証明チケットの前の履歴がない、初めて生成されるチケットに適用され、証明チケットを更新するように要求するデバイスを求め得る。
支払端末２０は、リーダ３と作った接続を検出すると、以前に指定された証明チケットを送信し得る。そのとき、リーダ３は、端末２０は改ざんされていないと保証するように、セッション承認を要求し得る。他のトリガーにより、リーダ３に、支払端末から証明チケットを受信させ得る。リーダ３は、この妥当性確認プロセスを一度行い、その妥当性が持続する時間は、セッション承認を要求しなくてもよい。一部の例では、安全なセッションの妥当性は、リーダ３との接続が切れるか、またはそうでなければ、リーダ３が利用できなくなるとすぐに、有効期限が切れるが、それは、これが信頼できるデバイスから信頼できないデバイスへの、端末２０の切り替えを示す可能性があるからである。リーダ３は、端末が改ざんされておらず、そうでなければ、セキュリティ脅威とも関連付けられないことを立証するように、支払トランザクションに応じて、以前に指定された証明チケットを支払端末２０から受信し得る。リーダ３はまた、端末２０から公開鍵と、端末２０が動いているデバイスの状態を要約するフレームとを受信し得る。端末のフレームはまた、証明エンドポイントとの以前の対話より保存されたデータを包含し得る。このデータは、支払サーバ５０によって暗号化され、クライアントデバイス上に記憶され、セッション妥当性確認時にフレームに入れて送信され、サーバへ戻される。
リーダ３は、送信されるべき場所、および有効期限ｌａｓｔ＿ｄｅｎｙ＿ｔｉｍｅｓｔａｍｐなど、他の基本情報を判定するように、チケットの少なくとも一部分をデコードし得る。一部の実施では、リーダ３は、読み取り得るデータの一部分に完全に基づき、ローカルの決定を下し得る。例えば、オフラインモードでは、リーダ３は、その他の点では有効な証明チケットの妥当性を拒否することを選んで、関連するリスクを減らし得る。他の実施では、リーダ３は、検証のため、支払サーバ５０がさらなるセッション承認を提供し得るように、証明チケットを支払サーバ５０へ送信する。証明チケットのコンテンツについて、ステップ８１６に関して記載してきた。しかしながら、この証明チケットは、リーダのタイプ、セッションが要求された時間、トランザクションのタイプ、リーダと端末との間の接続のタイプ、端末と関連付けられるトランザクションの履歴などに関連する、リーダ３により加えられる、修正されコード化される情報を含んでもよい。そのような情報はまた、製造時に支払サーバ５０によって提供される、リーダ識別子またはセキュリティ証明書を含み得る。他の例では、証明チケットは暗号化され、リーダ３および端末２０に対して完全に不透明である。証明チケットは限定された期間のみ有効であるため、これは、クライアントがチケットの期限が切れたか否かを教えられないことを意味する。これが原因の一つとなり、クライアントは、最近のチケットを獲得せずにセッション妥当性確認を求めて、サーバに疑似承認または疑似拒絶のいずれかを与えさせてもよい。
一部の場合には、リーダ３は、支払端末２０へ要求を送信することができ、その後、支払端末２０が要求を支払サーバ５０へ送信する。
図面に戻ると、ステップ８１５で、リーダ３は、セッション要求を改ざん検出コンポーネント８０へ送信する。ステップ８２５で、改ざん検出コンポーネント８０は、暗号９５へ要求を転送する。改ざん検出コンポーネント８０は、リーダ３から受信したチケットが有効かを判定し、さらに、安全なセッションの承認を妨げる、チケットと関連付けられたいかなる他の条件があるかを判定するように、チケットを分析する。一部の例では、リーダ３は、改ざん検出コンポーネント８０へチケットを送信する。
ステップ８３５で、暗号コンポーネント（暗号）９５は、ＨＳＭ９８および提供される鍵と組み合わせて、チケットを復号する。鍵は、ＨＭＡＣによって例示するために、チケットに埋め込まれた端末２０およびリーダ３の鍵と比較される。鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）は、秘密暗号鍵と組み合わせて、暗号ハッシュ機能（故に、「Ｈ」）を伴う、特定タイプのメッセージ認証コード（ＭＡＣ）である。また、他の技術を使用してもよいことは、理解されるであろう。
一つの例示の実施では、暗号９５は、リーダ３からの「ｓｅｃｕｒｅ＿ｓｅｓｓｉｏｎ＿ｉｎｉｔ」要求をデコードし、改ざん検出コンポーネント８０へコンテンツを提供する。これには、ＨＳＭ９８に記憶される鍵を使用して、メッセージのＨＭＡＣをチェックすることを含む。改ざん検出コンポーネント８０は、端末２０が安全な環境で動いているかを判定する。これを行うために、改ざん検出コンポーネント８０は、デコードされた要求からの情報、リーダ３からのフレーム（証明データ）、およびブラックリストまたはホワイトリストなど、記憶されたいかなる情報を使用する。改ざん検出コンポーネント８０が、安全なセッションを承認することを決定したと想定すると、改ざん検出コンポーネント８０は、セッションに対して最大の持続時間およびトランザクション数を選択し、暗号９５で承認メッセージをコード化する。このメッセージもまた、ＨＳＭ９８の中の鍵を使用してコード化される。
ステップ８４０で、暗号は、改ざん検出コンポーネント８０に追加パラメータを要求する。ステップ８４５で、コンポーネント８０は、パラメータを生成するように一つ以上の規則を適用し、ステップ８５５で暗号９５へ送信し戻す。規則は、暗号化が行われる、改ざん検出または特定パラメータの抽出に関係し得る。パラメータはステップ８５５へ送信される。暗号は、ステップ８６５にてパラメータでこのときのＨＭＡＣ応答を組み立て、ステップ８７５で改ざん検出コンポーネント８０へセッション承認を送信し、その後、ステップ８９５でセッション承認を端末２０へ転送する。コード化されたセッション承認は、支払端末および／またはリーダ３へ送信され、ステップ８４０に示す通り、安全なセッションが、現在および将来のトランザクション用に、リーダ３と端末２０との間に確立される。サーバ２０は、セッションの正当性が確認され安全である限り、証明をチェックする必要はない。ステップ８４２で行われる通り、分析後に端末２０および／または暗号９５によって、セッションを無効にしてもよい実施がある。その後、セッション要求の拒絶が、記憶するために、およびリーダ３がすべての支払トランザクションを拒絶するためにも、端末２０および／またはリーダ３へ送信され得る。
前述は、本開示の原理を単に示し、本開示の範囲から逸脱することなく、当業者によって様々な変形がなされてもよい。上に記載する実施形態は、説明のために提示され、限定のためではない。本開示はまた、本明細書に明示的に記載する形態以外にも、多くの形態を取り得る。それに応じて、本開示は、以下の請求項の精神の範囲内である、明示的に開示する方法、システムおよび装置に限定されないが、それらの変形および修正を含むように意図されていることを強調する。
さらなる例として、装置または処理パラメータ（例えば、寸法、構成、コンポーネント、処理ステップの順序など）は、本明細書に示し記載する通り、提供される構造、デバイスおよび方法をさらに最適化するように変形が成されてもよい。いかなる事象において、本明細書に記載する構造およびデバイスだけでなく、関連する方法も多くの用途を有する。したがって、開示する主題は、本明細書に記載する、いかなる単一の実施形態にも限定されるべきではなく、むしろ、添付の請求項に従う範囲で解釈されるべきである。
項
項１
支払オブジェクトリーダと通信できる支払端末上で、セキュリティ脅威を検出するコンピュータ実施方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
支払処理サーバの改ざん検出コンポーネントによって、
所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
支払処理サーバの改ざん検出コンポーネントによって、コマンドを支払端末へ送信することと、
改ざんモニタリングコンポーネントによって、一つ以上のセキュリティ脅威を示す証明データを生成するように、支払端末上でコマンドを実行することと、
改ざん検出コンポーネントによって、コマンドに基づき証明データを判定することであって、証明データが、支払端末の現在の状態、支払端末の以前の状態、リスク格付け、および支払端末上に保存される小売業者プロファイルのうちの少なくとも一つを含む、ことと、
改ざん検出コンポーネントから改ざんモニタリングコンポーネントへ、証明データを送信することと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全であることを示す、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
他方の証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全ではないと示す、ことと、を含む方法。
項２
支払端末によって、証明トリガーを受信することであって、証明トリガーは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、無線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、支払端末を再起動すること、支払オブジェクトリーダを再起動すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することのうちの少なくとも一つのイベントを含む、ことをさらに含む、項１に記載の方法。
支払端末の改ざんモニタリングコンポーネントによって、証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成すること。
項３
支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行うことと、
証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送することと、をさらに含む、項１に記載の方法。
項４
コマンドを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成することを含む、ことと、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成することと、をさらに含む、項１に記載の方法。
項５
支払トランザクションを支払端末にて処理する方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
支払処理サーバの改ざん検出コンポーネントによって、
所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
改ざん検出コンポーネントによって、支払端末上でのコマンドの実行に基づき、証明データを判定することであって、証明データは、支払端末の不正または改ざんのうちの一つ以上の兆候を示す、支払端末の状態を含む、ことと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
証明チケットを支払端末へ送信することであって、証明チケットは、支払間隔が安全であることを示す、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
他方の証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全ではないと示す、ことと、を含む方法。
項６
支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行うことと、
証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送することと、をさらに含む、項５に記載の方法。
項７
小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成することと、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成することと、をさらに含む、項５に記載の方法。
項８
支払端末によって、証明トリガーを受信することであって、証明トリガーは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、無線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含む、ことと、
支払端末の改ざんモニタリングコンポーネントによって、証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成することと、をさらに含む、項５に記載の方法。
項９
要求が拒絶される場合、支払処理サーバによって、第１是正措置および第２是正措置を実施することであって、第１是正措置は、トランザクションを中止すること、および支払デバイスに問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項５に記載の方法。
項１０
コマンドを実行することは、支払端末、または支払端末上で実行する支払アプリケーションの電気的特性、機械的特性もしくはソフトウェア特性に基づき、証明データを示す一つ以上の応答のタイミングを監視することを含む、項５に記載の方法。
項１１
支払端末上に証明チケットまたは証明データを記憶することと、支払トランザクションの妥当性確認に応じて、または支払端末と別のデバイスとの間での安全な通信チャネルの確立に向けて、証明チケットを提示することと、をさらに含む、項５に記載の方法。
項１２
コマンドは、エラー条件テストコマンド、暗号化・復号テストコマンド、ハードウェアテストコマンドおよびメッセージタイミングテストコマンドのうちの一つ以上を含む、項５に記載の方法。
項１３
他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをコード化することをさらに含む、項１１に記載の方法。
項１４
支払サーバを含む複数のサーバへ通信連結されるコントローラによって、支払サーバのアドレスを示すヘッダフィールド、またはリスクスコアを判定することであって、各サーバが、リスクスコアのある特定範囲の要求に対処する、ことと、
ヘッダフィールドに基づき、要求を適切なサーバへルーティングすることと、をさらに含む、項５に記載の方法。
項１５
通信インターフェースであって、通信インターフェースは、支払端末のセキュリティに対して証明する要求を受信するように構成され、要求は、支払端末に対応するデータフレームを備える、通信インターフェースと、
支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、
記録と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成し、
要求を提出する支払端末から、コマンドに応じて証明データを取得し、
証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定し、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットを生成し、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含み、
証明チケットを支払端末へ送信し、証明チケットは、支払間隔が安全であることを示し、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットを生成し、拒絶通知は、要求の拒絶の理由を示し、
他方の証明チケットを支払端末へ送信し、証明チケットは、支払端末が安全ではないと示す、
ように構成される、処理要素と、を備える、支払サーバ。
項１６
処理要素はさらに、支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行い、証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送するように構成される、項１５に記載の支払サーバ。
項１７
処理要素はさらに、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成し、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成するように構成される、項１５に記載の支払サーバ。
項１８
処理要素はさらに、支払端末によって、証明トリガーを受信するように構成され、証明トリガーが、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと前支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含み、
証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成するように構成される、項１５に記載の支払サーバ。
項１９
処理要素はさらに、他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをコード化するように構成される、項１５に記載の支払サーバ。
項２０
処理要素はさらに、支払端末特性、監視される応答、監視されるタイミング、以前の支払端末特性、以前の応答および以前の監視されるタイミングに基づき、コマンドに対する一つ以上のテスト基準を更新するように構成され、支払サーバは、更新されるテスト基準を含み、後続の要求に使用するために記憶される、更新メッセージを生成するように構成される、項１５に記載の支払サーバ。
項２１
証明チケットを生成する要求を一つのコンポーネントへ、および潜在的改ざんに対して証明データを分析する要求を別のコンポーネントへ送信するように構成される、フェイルオーバーコンポーネントをさらに備える、項１５に記載の支払サーバ。
項２２
支払端末が通信する支払オブジェクトリーダを、一意的に識別する鍵を記憶するように構成される、ハードウェアセキュリティモジュールをさらに備える、項１５に記載の支払サーバ。
項２３
支払オブジェクトリーダと支払端末との間で、情報の安全な交換を推進するコンピュータ実施方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払オブジェクトリーダが、支払端末へ接続したという指標を受信することと、
改ざんモニタリングコンポーネントによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することと、
改ざんモニタリングコンポーネントによって、スキャンに対応する応答を含む妥当性確認データ、端末と関連付けられた識別子、および証明チケットを取得することであって、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき前回生成されたものである、ことと、
改ざんモニタリングコンポーネントによって、支払サーバ用に、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を生成することであって、要求は、妥当性確認データを含む、ことと、
改ざんモニタリングコンポーネントによって、支払処理サーバへ、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を送信することと、
改ざんモニタリングコンポーネントによって、妥当性確認データと一つ以上の妥当性確認基準とを比較することであって、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含む、ことと、
支払処理サーバの改ざん検出コンポーネントによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成することと、
セッション承認割込みを支払端末へ送信することであって、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままである、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
セッション拒絶割込みを支払端末へ送信することと、を含む、方法。
項２４
改ざんモニタリングコンポーネントによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントによってトリガーされる、項２３に記載の方法。
項２５
項証明チケットを取得することはさらに、
改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
改ざん検出コンポーネントによって、所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
改ざん検出コンポーネントによって、支払端末上でのコマンドの実行に基づき、証明データを判定することであって、証明データは、支払端末の不正または改ざんのうちの一つ以上の兆候を示す、支払端末の状態を含む、ことと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
記憶のために証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全であることを示す、ことと、を含む、項２３に記載の方法。
項２６
命令のセットを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、命令のセットを構成することを含む、ことと、
支払処理サーバから受信するフォローアップ要求に少なくとも基づき、命令の後続セットを生成することと、をさらに含む、項２３に記載の方法。
項２７
支払オブジェクトリーダと支払端末との間で、情報の安全な交換を推進するコンピュータ実施方法であって、
支払処理サーバのプロセッサによって、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信することであって、要求が、証明チケットを含み、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき、要求と同時にまたは前回生成されたもので、証明チケットは、支払端末のセキュリティに対して証明できる、ことと、
プロセッサによって、証明チケットと一つ以上の妥当性確認基準とを比較することであって、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含む、ことと、
プロセッサによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成することと、
セッション承認割込みを支払端末へ送信することであって、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままである、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
セッション拒絶割込みを支払端末へ送信することと、を含む、方法。
項２８
プロセッサによって、不正または改ざんを含むセキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することであって、支払端末のスキャンにより、支払端末の状態、支払端末と関連付けられる識別子、およびスキャンのタイムスタンプを生成する、ことと、
支払端末の状態、支払端末と関連付けられる識別子、およびスキャンのタイムスタンプを、安全な通信チャネルを確立する要求へ加えることと、をさらに含む、項２７に記載の方法。
項２９
命令のセットを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、命令のセットを構成することを含む、ことと、
支払処理サーバから受信するフォローアップ要求に少なくとも基づき、命令の後続セットを生成することと、をさらに含む、項２８に記載の方法。
項３０
プロセッサによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントによってトリガーされる、項２８に記載の方法。
項３１
要求が拒絶される場合、支払処理サーバによって、第１是正措置および第２是正措置を実施することであって、第１是正措置は、トランザクションを中止すること、および支払デバイスに問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項２７に記載の方法。
項３２
命令のセットが、支払端末、または支払端末上で実行する支払アプリケーションの電気的特性、機械的特性もしくはソフトウェア特性の構成の変化を監視する命令を含む、項２７に記載の方法。
項３３
支払端末上に安全な通信チャネルと関連付けられる安全なセッションの証明書を記憶することと、支払トランザクションの妥当性確認に応じて、または支払端末と別のデバイスとの間の安全な通信チャネルの証明として、安全なセッションの証明書を提示することと、
をさらに含む、項２７に記載の方法。
項３４
セッション承認割込みを提供するように構成される、支払端末の改ざん検出コンポーネントが、現在利用不可能であるかを判定することと、
改ざん検出コンポーネントが利用不可能である場合、証明サブシステムによって、仮のセッション承認割込みを生成することであって、仮のセッション承認割込みは、安全なセッションの証明書を提示できる、ことと、
改ざん検出コンポーネントが利用可能になるとき、処理のために仮のセッション承認割込みを一括処理することと、をさらに含む、項３３に記載の方法。
項３５
他方のデバイスまたは支払端末と関連付けられる、少なくともハードウェアのセキュリティキーを記憶した暗号コンポーネントへ、証明チケットを送信することと、
証明チケットをデコードするように、ハードウェアのセキュリティキーを適用することと、をさらに含む、項２７に記載の方法。
項３６
支払サーバを含む複数のサーバへ通信連結されるコントローラによって、支払サーバのアドレスを示すヘッダフィールド、またはリスクスコアを判定することであって、各サーバが、リスクスコアのある特定範囲の要求に対処する、ことと、
ヘッダフィールドに基づき、要求を適切なサーバへルーティングすることと、をさらに含む項２７に記載の方法。
項３７
通信インターフェースであって、通信インターフェースが、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信するように構成され、要求が、支払端末に対応する証明チケットを備える、通信インターフェースと、
支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、
支払処理サーバのプロセッサによって、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信し、要求が、証明チケットを含み、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき、要求と同時にまたは前回生成されたもので、証明チケットは、支払端末のセキュリティに対して証明でき、
プロセッサによって、証明チケットと一つ以上の妥当性確認基準とを比較し、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含み、
プロセッサによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定し、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成し、
セッション承認割込みを支払端末へ送信し、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままであり、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成し、拒絶通知は、要求の拒絶の理由を示し、
セッション拒絶割込みを支払端末へ送信する、
ように構成される、処理要素と、を備える、支払サーバ。
項３８
処理要素はさらに、他方のデバイスまたは支払端末と関連付けられる、少なくともハードウェアのセキュリティキーを、暗号コンポーネント上に記憶し、
証明チケットをデコードするように、ハードウェアのセキュリティキーを適用する、
暗号コンポーネントへ、証明チケットを送信するように構成される、項３７に記載の支払サーバ。
項３９
処理要素はさらに、セッション承認割込みを提供するように構成される、支払端末の改ざん検出コンポーネントが、現在利用不可能であるかを判定し、
改ざん検出コンポーネントが利用不可能である場合、証明サブシステムによって、仮のセッション承認割込みを生成し、仮のセッション承認割込みは、安全なセッションの証明書を提示でき、
仮のセッション承認割込みを一括処理する、ように構成される、項３７に記載の支払サーバ。
項４０
処理要素はさらに、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントに基づき、キュリティ脅威に対して、支払端末のハードウェアまたはソフトウェア缶をトリガーするように構成される、項３７に記載の支払サーバ。
項４１
処理要素はさらに、他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをデコードするように構成される、項３７に記載の支払サーバ。
項４２
処理要素はさらに、支払処理サーバによって、第１是正措置および第２是正措置を実施するように構成され、第１是正措置は、要求が拒絶されるとき、トランザクションを中止すること、および支払端末に問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項３７に記載の支払サーバ。
項４３
支払端末が通信する支払オブジェクトリーダを、一意的に識別する鍵を記憶するように構成される、ハードウェアセキュリティモジュールをさらに備える、項３７に記載の支払サーバ。
項
項１
支払オブジェクトリーダと通信できる支払端末上で、セキュリティ脅威を検出するコンピュータ実施方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
支払処理サーバの改ざん検出コンポーネントによって、
所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
支払処理サーバの改ざん検出コンポーネントによって、コマンドを支払端末へ送信することと、
改ざんモニタリングコンポーネントによって、一つ以上のセキュリティ脅威を示す証明データを生成するように、支払端末上でコマンドを実行することと、
改ざん検出コンポーネントによって、コマンドに基づき証明データを判定することであって、証明データが、支払端末の現在の状態、支払端末の以前の状態、リスク格付け、および支払端末上に保存される小売業者プロファイルのうちの少なくとも一つを含む、ことと、
改ざん検出コンポーネントから改ざんモニタリングコンポーネントへ、証明データを送信することと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全であることを示す、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
他方の証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全ではないと示す、ことと、を含む方法。
項２
支払端末によって、証明トリガーを受信することであって、証明トリガーは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、無線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、支払端末を再起動すること、支払オブジェクトリーダを再起動すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することのうちの少なくとも一つのイベントを含む、ことをさらに含む、項１に記載の方法。
支払端末の改ざんモニタリングコンポーネントによって、証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成すること。
項３
支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行うことと、
証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送することと、をさらに含む、項１に記載の方法。
項４
コマンドを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成することを含む、ことと、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成することと、をさらに含む、項１に記載の方法。
項５
支払トランザクションを支払端末にて処理する方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
支払端末の改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
支払処理サーバの改ざん検出コンポーネントによって、
所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
改ざん検出コンポーネントによって、支払端末上でのコマンドの実行に基づき、証明データを判定することであって、証明データは、支払端末の不正または改ざんのうちの一つ以上の兆候を示す、支払端末の状態を含む、ことと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
証明チケットを支払端末へ送信することであって、証明チケットは、支払間隔が安全であることを示す、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
他方の証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全ではないと示す、ことと、を含む方法。
項６
支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行うことと、
証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送することと、をさらに含む、項５に記載の方法。
項７
小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成することと、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成することと、をさらに含む、項５に記載の方法。
項８
支払端末によって、証明トリガーを受信することであって、証明トリガーは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、無線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含む、ことと、
支払端末の改ざんモニタリングコンポーネントによって、証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成することと、をさらに含む、項５に記載の方法。
項９
要求が拒絶される場合、支払処理サーバによって、第１是正措置および第２是正措置を実施することであって、第１是正措置は、トランザクションを中止すること、および支払デバイスに問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項５に記載の方法。
項１０
コマンドを実行することは、支払端末、または支払端末上で実行する支払アプリケーションの電気的特性、機械的特性もしくはソフトウェア特性に基づき、証明データを示す一つ以上の応答のタイミングを監視することを含む、項５に記載の方法。
項１１
支払端末上に証明チケットまたは証明データを記憶することと、支払トランザクションの妥当性確認に応じて、または支払端末と別のデバイスとの間での安全な通信チャネルの確立に向けて、証明チケットを提示することと、をさらに含む、項５に記載の方法。
項１２
コマンドは、エラー条件テストコマンド、暗号化・復号テストコマンド、ハードウェアテストコマンドおよびメッセージタイミングテストコマンドのうちの一つ以上を含む、項５に記載の方法。
項１３
他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをコード化することをさらに含む、項１１に記載の方法。
項１４
支払サーバを含む複数のサーバへ通信連結されるコントローラによって、支払サーバのアドレスを示すヘッダフィールド、またはリスクスコアを判定することであって、各サーバが、リスクスコアのある特定範囲の要求に対処する、ことと、
ヘッダフィールドに基づき、要求を適切なサーバへルーティングすることと、をさらに含む、項５に記載の方法。
項１５
通信インターフェースであって、通信インターフェースは、支払端末のセキュリティに対して証明する要求を受信するように構成され、要求は、支払端末に対応するデータフレームを備える、通信インターフェースと、
支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、
記録と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成し、
要求を提出する支払端末から、コマンドに応じて証明データを取得し、
証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定し、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットを生成し、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含み、
証明チケットを支払端末へ送信し、証明チケットは、支払間隔が安全であることを示し、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも含む別の証明チケットを生成し、拒絶通知は、要求の拒絶の理由を示し、
他方の証明チケットを支払端末へ送信し、証明チケットは、支払端末が安全ではないと示す、
ように構成される、処理要素と、を備える、支払サーバ。
項１６
処理要素はさらに、支払端末によって、支払端末の状態およびスキャンのタイムスタンプを生成するように、支払端末の周期的スキャンを行い、証明チケットの妥当性を更新するように、所定の間隔で状態を記憶するか、または支払処理サーバへ状態を転送するように構成される、項１５に記載の支払サーバ。
項１７
処理要素はさらに、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、コマンドを構成し、
支払端末から受信する証明データに少なくとも基づき、後続のコマンドを生成するように構成される、項１５に記載の支払サーバ。
項１８
処理要素はさらに、支払端末によって、証明トリガーを受信するように構成され、証明トリガーが、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続すること、支払オブジェクトリーダと前支払端末とを対にすること、支払端末上に新規な支払アプリケーションをインストールすること、支払オブジェクトリーダまたは支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含み、
証明トリガーに少なくとも基づき、支払端末のセキュリティを証明する要求を生成するように構成される、項１５に記載の支払サーバ。
項１９
処理要素はさらに、他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをコード化するように構成される、項１５に記載の支払サーバ。
項２０
処理要素はさらに、支払端末特性、監視される応答、監視されるタイミング、以前の支払端末特性、以前の応答および以前の監視されるタイミングに基づき、コマンドに対する一つ以上のテスト基準を更新するように構成され、支払サーバは、更新されるテスト基準を含み、後続の要求に使用するために記憶される、更新メッセージを生成するように構成される、項１５に記載の支払サーバ。
項２１
証明チケットを生成する要求を一つのコンポーネントへ、および潜在的改ざんに対して証明データを分析する要求を別のコンポーネントへ送信するように構成される、フェイルオーバーコンポーネントをさらに備える、項１５に記載の支払サーバ。
項２２
支払端末が通信する支払オブジェクトリーダを、一意的に識別する鍵を記憶するように構成される、ハードウェアセキュリティモジュールをさらに備える、項１５に記載の支払サーバ。
項２３
支払オブジェクトリーダと支払端末との間で、情報の安全な交換を推進するコンピュータ実施方法であって、
支払端末の改ざんモニタリングコンポーネントによって、支払オブジェクトリーダが、支払端末へ接続したという指標を受信することと、
改ざんモニタリングコンポーネントによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することと、
改ざんモニタリングコンポーネントによって、スキャンに対応する応答を含む妥当性確認データ、端末と関連付けられた識別子、および証明チケットを取得することであって、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき前回生成されたものである、ことと、
改ざんモニタリングコンポーネントによって、支払サーバ用に、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を生成することであって、要求は、妥当性確認データを含む、ことと、
改ざんモニタリングコンポーネントによって、支払処理サーバへ、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を送信することと、
改ざんモニタリングコンポーネントによって、妥当性確認データと一つ以上の妥当性確認基準とを比較することであって、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含む、ことと、
支払処理サーバの改ざん検出コンポーネントによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成することと、
セッション承認割込みを支払端末へ送信することであって、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままである、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
セッション拒絶割込みを支払端末へ送信することと、を含む、方法。
項２４
改ざんモニタリングコンポーネントによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントによってトリガーされる、項２３に記載の方法。
項２５
項証明チケットを取得することはさらに、
改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を生成することと、
改ざんモニタリングコンポーネントによって、支払端末のセキュリティを証明する要求を、支払処理サーバへ送信することと、
改ざん検出コンポーネントによって、所定のテスト基準と対比して支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
改ざん検出コンポーネントによって、支払端末上でのコマンドの実行に基づき、証明データを判定することであって、証明データは、支払端末の不正または改ざんのうちの一つ以上の兆候を示す、支払端末の状態を含む、ことと、
改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する要求を承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、妥当性条件は、証明チケットが無効になった後の時間を示す、有効期限を含む、ことと、
記憶のために証明チケットを支払端末へ送信することであって、証明チケットは、支払端末が安全であることを示す、ことと、を含む、項２３に記載の方法。
項２６
命令のセットを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、命令のセットを構成することを含む、ことと、
支払処理サーバから受信するフォローアップ要求に少なくとも基づき、命令の後続セットを生成することと、をさらに含む、項２３に記載の方法。
項２７
支払オブジェクトリーダと支払端末との間で、情報の安全な交換を推進するコンピュータ実施方法であって、
支払処理サーバのプロセッサによって、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信することであって、要求が、証明チケットを含み、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき、要求と同時にまたは前回生成されたもので、証明チケットは、支払端末のセキュリティに対して証明できる、ことと、
プロセッサによって、証明チケットと一つ以上の妥当性確認基準とを比較することであって、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含む、ことと、
プロセッサによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定することと、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成することと、
セッション承認割込みを支払端末へ送信することであって、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままである、ことと、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成することであって、拒絶通知は、要求の拒絶の理由を示す、ことと、
セッション拒絶割込みを支払端末へ送信することと、を含む、方法。
項２８
プロセッサによって、不正または改ざんを含むセキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することであって、支払端末のスキャンにより、支払端末の状態、支払端末と関連付けられる識別子、およびスキャンのタイムスタンプを生成する、ことと、
支払端末の状態、支払端末と関連付けられる識別子、およびスキャンのタイムスタンプを、安全な通信チャネルを確立する要求へ加えることと、をさらに含む、項２７に記載の方法。
項２９
命令のセットを生成することは、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、命令のセットを構成することを含む、ことと、
支払処理サーバから受信するフォローアップ要求に少なくとも基づき、命令の後続セットを生成することと、をさらに含む、項２８に記載の方法。
項３０
プロセッサによって、セキュリティ脅威に対して、支払端末のハードウェアまたはソフトウェアをスキャンするように、命令のセットを実行することは、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントによってトリガーされる、項２８に記載の方法。
項３１
要求が拒絶される場合、支払処理サーバによって、第１是正措置および第２是正措置を実施することであって、第１是正措置は、トランザクションを中止すること、および支払デバイスに問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項２７に記載の方法。
項３２
命令のセットが、支払端末、または支払端末上で実行する支払アプリケーションの電気的特性、機械的特性もしくはソフトウェア特性の構成の変化を監視する命令を含む、項２７に記載の方法。
項３３
支払端末上に安全な通信チャネルと関連付けられる安全なセッションの証明書を記憶することと、支払トランザクションの妥当性確認に応じて、または支払端末と別のデバイスとの間の安全な通信チャネルの証明として、安全なセッションの証明書を提示することと、
をさらに含む、項２７に記載の方法。
項３４
セッション承認割込みを提供するように構成される、支払端末の改ざん検出コンポーネントが、現在利用不可能であるかを判定することと、
改ざん検出コンポーネントが利用不可能である場合、証明サブシステムによって、仮のセッション承認割込みを生成することであって、仮のセッション承認割込みは、安全なセッションの証明書を提示できる、ことと、
改ざん検出コンポーネントが利用可能になるとき、処理のために仮のセッション承認割込みを一括処理することと、をさらに含む、項３３に記載の方法。
項３５
他方のデバイスまたは支払端末と関連付けられる、少なくともハードウェアのセキュリティキーを記憶した暗号コンポーネントへ、証明チケットを送信することと、
証明チケットをデコードするように、ハードウェアのセキュリティキーを適用することと、をさらに含む、項２７に記載の方法。
項３６
支払サーバを含む複数のサーバへ通信連結されるコントローラによって、支払サーバのアドレスを示すヘッダフィールド、またはリスクスコアを判定することであって、各サーバが、リスクスコアのある特定範囲の要求に対処する、ことと、
ヘッダフィールドに基づき、要求を適切なサーバへルーティングすることと、をさらに含む項２７に記載の方法。
項３７
通信インターフェースであって、通信インターフェースが、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信するように構成され、要求が、支払端末に対応する証明チケットを備える、通信インターフェースと、
支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、
支払処理サーバのプロセッサによって、支払オブジェクトリーダと支払端末との間に、安全な通信チャネルを確立する要求を受信し、要求が、証明チケットを含み、証明チケットは、支払端末と支払処理サーバとの間の対話に基づき、要求と同時にまたは前回生成されたもので、証明チケットは、支払端末のセキュリティに対して証明でき、
プロセッサによって、証明チケットと一つ以上の妥当性確認基準とを比較し、妥当性確認基準は、支払端末に対して証明チケットの妥当性を判定することを含み、
プロセッサによって、比較に基づき、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立する要求を、承認または拒絶するかを判定し、
要求が承認されたと判定が示す場合、一つ以上のセッション承認条件を有するセッション承認割込みを、さらに生成し、
セッション承認割込みを支払端末へ送信し、セッション承認割込みにより、支払オブジェクトリーダと支払端末との間に安全な通信チャネルを確立させ、安全な通信チャネルは、セッション承認条件に基づく期間中利用可能なままであり、
要求が拒絶されたと判定が示す場合、拒絶通知を少なくとも有するセッション拒絶割込みをさらに生成し、拒絶通知は、要求の拒絶の理由を示し、
セッション拒絶割込みを支払端末へ送信する、
ように構成される、処理要素と、を備える、支払サーバ。
項３８
処理要素はさらに、他方のデバイスまたは支払端末と関連付けられる、少なくともハードウェアのセキュリティキーを、暗号コンポーネント上に記憶し、
証明チケットをデコードするように、ハードウェアのセキュリティキーを適用する、
暗号コンポーネントへ、証明チケットを送信するように構成される、項３７に記載の支払サーバ。
項３９
処理要素はさらに、セッション承認割込みを提供するように構成される、支払端末の改ざん検出コンポーネントが、現在利用不可能であるかを判定し、
改ざん検出コンポーネントが利用不可能である場合、証明サブシステムによって、仮のセッション承認割込みを生成し、仮のセッション承認割込みは、安全なセッションの証明書を提示でき、
仮のセッション承認割込みを一括処理する、ように構成される、項３７に記載の支払サーバ。
項４０
処理要素はさらに、次の、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、有線接続を使用して、支払オブジェクトリーダを支払端末へ接続することと、支払オブジェクトリーダと支払端末とを対にすることと、支払端末上に新規な支払アプリケーションをインストールすることと、支払オブジェクトリーダまたは支払端末の再配置を検出することと、支払端末を再起動することと、支払オブジェクトリーダを再起動することと、既知の不正ユーザによる支払オブジェクトの挿入を検出することと、既知の不正支払オブジェクトを検出することと、確立されたジオフェンス内に既知の不正デバイスの入力を検出することとのうちの少なくとも一つのイベントに基づき、キュリティ脅威に対して、支払端末のハードウェアまたはソフトウェア缶をトリガーするように構成される、項３７に記載の支払サーバ。
項４１
処理要素はさらに、他方のデバイスと関連付けられる、少なくともハードウェアのセキュリティキーを使用して、証明チケットをデコードするように構成される、項３７に記載の支払サーバ。
項４２
処理要素はさらに、支払処理サーバによって、第１是正措置および第２是正措置を実施するように構成され、第１是正措置は、要求が拒絶されるとき、トランザクションを中止すること、および支払端末に問い合わせることのうちの一つ以上を含み、第２是正措置は、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントから、電力を除去すること、支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および支払端末にて対策を用いることのうちの一つ以上を含む、項３７に記載の支払サーバ。
項４３
支払端末が通信する支払オブジェクトリーダを、一意的に識別する鍵を記憶するように構成される、ハードウェアセキュリティモジュールをさらに備える、項３７に記載の支払サーバ。
Claims (15)
- 支払トランザクションを処理する方法であって、
支払端末の改ざんモニタリングコンポーネントによって、前記支払端末のセキュリティを証明する要求を生成することと、
前記支払端末の前記改ざんモニタリングコンポーネントによって、前記支払端末のセキュリティを証明する前記要求を、支払処理サーバへ送信することと、
前記支払処理サーバの改ざん検出コンポーネントによって、
所定のテスト基準と対比して前記支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
前記改ざん検出コンポーネントによって、前記支払端末上での前記コマンドの実行に基づき、証明データを判定することであって、証明データは、前記支払端末の不正または改ざんのうちの一つ以上の兆候を示す、前記支払端末の状態を含む、ことと、
前記改ざん検出コンポーネントによって、証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する前記要求を承認または拒絶するかを判定することと、
前記要求が承認されたと前記判定が示す場合、一つ以上の妥当性条件を有する証明チケットをさらに生成することであって、前記妥当性条件は有効期限を含み、前記有効期限はある時間を示し、当該時間の後は前記証明チケットが無効になる、ことと、
前記証明チケットを前記支払端末へ送信することであって、前記証明チケットは、支払端末が安全であることを示す、ことと、
前記要求が拒絶されたと前記判定が示す場合、拒絶通知を少なくとも含む別の証明チケットをさらに生成することであって、前記拒絶通知は、前記要求の拒絶の理由を示す、ことと、
前記別の証明チケットを前記支払端末へ送信することであって、前記別の証明チケットは、前記支払端末が安全ではないと示す、ことと、を含む方法。 - 前記支払端末によって、前記支払端末の状態および前記スキャンのタイムスタンプを生成するように、前記支払端末の周期的スキャンを行うことと、
前記証明チケットの妥当性を更新するように、所定の間隔で前記状態を記憶するか、または前記支払処理サーバへ前記状態を転送することと、をさらに含む、請求項１に記載の方法。 - 小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、前記コマンドを構成することと、
前記支払端末から受信する前記証明データに少なくとも基づき、後続のコマンドを生成することと、をさらに含む、請求項１に記載の方法。 - 前記支払端末によって、証明トリガーを受信することであって、前記証明トリガーは、次の、有線接続を使用して、支払オブジェクトリーダを前記支払端末へ接続すること、無線接続を使用して、前記支払オブジェクトリーダを前記支払端末へ接続すること、前記支払オブジェクトリーダと前記支払端末とを対にすること、前記支払端末上に新規な支払アプリケーションをインストールすること、前記支払オブジェクトリーダまたは前記支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含む、ことと、
前記支払端末の前記改ざんモニタリングコンポーネントによって、前記証明トリガーに少なくとも基づき、前記支払端末のセキュリティを証明する前記要求を生成することと、をさらに含む、請求項１に記載の方法。 - 前記要求が拒絶される場合、前記支払処理サーバによって、第１是正措置および第２是正措置を実施することであって、前記第１是正措置は、トランザクションを中止すること、および前記支払端末に問い合わせることのうちの一つ以上を含み、前記第２是正措置は、支払オブジェクトリーダまたは前記支払端末の一つ以上のコンポーネントから、電力を除去すること、前記支払オブジェクトリーダまたは支払端末の一つ以上のコンポーネントを無効にすること、および前記支払端末にて対策を用いることのうちの一つ以上を含む、請求項１に記載の方法。
- 前記コマンドを前記実行することは、前記支払端末、または前記支払端末上で実行する支払アプリケーションの電気的特性、機械的特性もしくはソフトウェア特性に基づき、前記証明データを示す一つ以上の応答のタイミングを監視することを含む、請求項１に記載の方法。
- 前記支払端末上に前記証明チケットまたは前記証明データを記憶することと、支払トランザクションの妥当性確認に応じて、または前記支払端末と別のデバイスとの間の安全な通信チャネルの確立に向けて、前記証明チケットを提示することと、をさらに含む、請求項１に記載の方法。
- 前記コマンドは、エラー条件テストコマンド、暗号化・復号テストコマンド、ハードウェアテストコマンドおよびメッセージタイミングテストコマンドのうちの一つ以上を含み、他方のデバイスと関連付けられる、少なくとも前記ハードウェアのセキュリティキーを使用して、前記証明チケットをコード化することをさらに含む、請求項１に記載の方法。
- 支払サーバを含む複数のサーバへ通信連結されるコントローラによって、前記支払サーバのアドレスを示すヘッダフィールド、またはリスクスコアを判定することであって、各サーバが、リスクスコアのある特定範囲の要求に対処する、ことと、
前記ヘッダフィールドに基づき、前記要求を適切なサーバへルーティングすることと、をさらに含む、請求項１に記載の方法。 - 通信インターフェースであって、前記通信インターフェースは、支払端末のセキュリティに対して証明する要求を受信するように構成され、前記要求は、前記支払端末に対応するデータフレームを備える、通信インターフェースと、
前記支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、
前記記録と対比して前記支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成し、
前記要求を提出する前記支払端末から、前記コマンドに応じて証明データを取得し、
証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する前記要求を承認または拒絶するかを判定し、
前記要求が承認されたと前記判定が示す場合、一つ以上の妥当性条件を有する証明チケットを生成し、前記妥当性条件は有効期限を含み、前記有効期限はある時間を示し、当該時間の後は前記証明チケットが無効になり、
前記証明チケットを前記支払端末へ送信し、前記証明チケットは、支払端末が安全であることを示し、
前記要求が拒絶されたと前記判定が示す場合、拒絶通知を少なくとも含む別の証明チケットを生成し、前記拒絶通知は、前記要求の拒絶の理由を示し、
前記別の証明チケットを前記支払端末へ送信し、前記別の証明チケットは、前記支払端末が安全ではないと示す、
ように構成される、処理要素と、を備える、支払サーバ。 - 前記支払端末は、前記支払端末の状態および前記スキャンのタイムスタンプを生成するように、前記支払端末の周期的スキャンを行い、前記証明チケットの妥当性を更新するように、所定の間隔で前記状態を記憶するか、または前記支払サーバへ前記状態を転送するように構成される、請求項１０に記載の支払サーバ。
- 前記処理要素はさらに、小売業者識別子、支払端末識別子、リスクスコアまたは環境パラメータに基づき、前記コマンドを構成し、
前記支払端末から受信する前記証明データに少なくとも基づき、後続のコマンドを生成するように構成される、請求項１０に記載の支払サーバ。 - 前記処理要素はさらに、前記支払端末によって、証明トリガーを受信するように構成され、前記証明トリガーが、次の、有線接続を使用して、支払オブジェクトリーダを前記支払端末へ接続すること、無線接続を使用して、前記支払オブジェクトリーダを前記支払端末へ接続すること、前記支払オブジェクトリーダと前記支払端末とを対にすること、前記支払端末上に新規な支払アプリケーションをインストールすること、前記支払オブジェクトリーダまたは前記支払端末の再配置を検出すること、既知の不正ユーザによる支払オブジェクトの挿入を検出すること、既知の不正支払オブジェクトを検出すること、確立されたジオフェンス内に既知の不正デバイスの入力を検出することなどのうちの少なくとも一つのイベントを含み、
前記証明トリガーに少なくとも基づき、前記支払端末のセキュリティを証明する前記要求を生成するように構成される、請求項１０に記載の支払サーバ。 - 通信インターフェースであって、前記通信インターフェースは、支払端末のセキュリティに対して証明する要求を受信するように構成され、前記要求は、前記支払端末に対応するデータフレームを備える、通信インターフェースと、
前記支払端末および複数の追加の支払端末用に、以前の要求のときの以前の応答メッセージおよび所定のテスト基準の記録を備える、トランザクションデータベースと、を備える支払サーバのプロセッサによって実行されると、コンピュータ実施方法を実施する、コンピュータ実行可能命令を記憶する、一つ以上のコンピュータ可読媒体であって、前記方法は、
前記記録と対比して前記支払端末をスキャンまたはテストする、少なくとも一つのコマンドを生成することと、
前記要求を提出する前記支払端末から、前記コマンドに応じて証明データを取得することと、
証明データの一つ以上と、既知の動作との比較に基づき、セキュリティを証明する前記要求を承認または拒絶するかを判定することと、
前記要求が承認されたと前記判定が示す場合、一つ以上の妥当性条件を有する証明チケットを生成することであって、前記妥当性条件は有効期限を含み、前記有効期限はある時間を示し、当該時間の後は前記証明チケットが無効になる、ことと、
前記証明チケットを前記支払端末へ送信することであって、前記証明チケットは、支払端末が安全であることを示す、ことと、
前記要求が拒絶されたと前記判定が示す場合、拒絶通知を少なくとも含む別の証明チケットを生成することであって、前記拒絶通知は、前記要求の拒絶の理由を示す、ことと、
前記別の証明チケットを前記支払端末へ送信することであって、前記別の証明チケットは、前記支払端末が安全ではないと示す、ことと、を含む、一つ以上のコンピュータ可読媒体。 - 前記支払端末は、前記支払端末の状態および前記スキャンのタイムスタンプを生成するように、前記支払端末の周期的スキャンを行い、前記証明チケットの妥当性を更新するように、所定の間隔で前記状態を記憶するか、または前記支払サーバへ前記状態を転送するように構成される、請求項１４に記載の一つ以上のコンピュータ可読媒体。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/199,917 | 2016-06-30 | ||
| US15/199,933 | 2016-06-30 | ||
| US15/199,933 US10546302B2 (en) | 2016-06-30 | 2016-06-30 | Logical validation of devices against fraud and tampering |
| US15/199,917 US10373167B2 (en) | 2016-06-30 | 2016-06-30 | Logical validation of devices against fraud |
| PCT/US2017/040460 WO2018006060A1 (en) | 2016-06-30 | 2017-06-30 | Logical validation of devices against fraud and tampering |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2019530040A JP2019530040A (ja) | 2019-10-17 |
| JP6803935B2 true JP6803935B2 (ja) | 2020-12-23 |
Family
ID=59383628
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018567857A Active JP6803935B2 (ja) | 2016-06-30 | 2017-06-30 | 不正および改ざんに対するデバイスの論理的妥当性確認 |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP3479320B1 (ja) |
| JP (1) | JP6803935B2 (ja) |
| AU (3) | AU2017290878B2 (ja) |
| CA (1) | CA3032173C (ja) |
| WO (1) | WO2018006060A1 (ja) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8997230B1 (en) | 2012-06-15 | 2015-03-31 | Square, Inc. | Hierarchical data security measures for a mobile device |
| US10733594B1 (en) | 2015-05-11 | 2020-08-04 | Square, Inc. | Data security measures for mobile devices |
| US10373167B2 (en) | 2016-06-30 | 2019-08-06 | Square, Inc. | Logical validation of devices against fraud |
| US10546302B2 (en) | 2016-06-30 | 2020-01-28 | Square, Inc. | Logical validation of devices against fraud and tampering |
| US10496993B1 (en) | 2017-02-15 | 2019-12-03 | Square, Inc. | DNS-based device geolocation |
| US10552308B1 (en) | 2017-06-23 | 2020-02-04 | Square, Inc. | Analyzing attributes of memory mappings to identify processes running on a device |
| US10657512B2 (en) * | 2017-09-07 | 2020-05-19 | Clover Network, Inc. | Multi-use near field communication front end on a point of sale system |
| US10715536B2 (en) | 2017-12-29 | 2020-07-14 | Square, Inc. | Logical validation of devices against fraud and tampering |
| US10929838B2 (en) | 2018-01-19 | 2021-02-23 | Leadot Innovation, Inc. | Card not present transaction system and method for operating card not present transaction system to simplify hardware required at client sites |
| US10685192B2 (en) * | 2018-01-19 | 2020-06-16 | Leadot Innovation, Inc. | Card reading transaction system with an intermediate server |
| US11494762B1 (en) | 2018-09-26 | 2022-11-08 | Block, Inc. | Device driver for contactless payments |
| US11507958B1 (en) | 2018-09-26 | 2022-11-22 | Block, Inc. | Trust-based security for transaction payments |
| CN111383011B (zh) * | 2018-12-29 | 2023-09-29 | 华为技术有限公司 | 一种处理中继攻击的方法以及安全单元 |
| US11875350B2 (en) * | 2019-09-12 | 2024-01-16 | Visa International Service Association | Systems and methods for improved fraud detection |
| US11356460B2 (en) | 2019-12-31 | 2022-06-07 | Equifax Inc. | Secure online access control to prevent identification information misuse |
| JP7038969B2 (ja) * | 2020-01-09 | 2022-03-22 | ブロック， インコーポレイテッド | 電子マネー（ｅマネー）支払処理 |
| KR102161416B1 (ko) * | 2020-07-15 | 2020-09-29 | 이종훈 | 실시간 제상동작의 제어가 가능한 냉동장치 |
| US11463438B2 (en) | 2020-11-11 | 2022-10-04 | Bank Of America Corporation | Network device authentication for information security |
| EP4315753A1 (en) * | 2021-03-23 | 2024-02-07 | Royal Bank of Canada | Protocol and gateway for communicating secure transaction data |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009146107A (ja) * | 2007-12-13 | 2009-07-02 | Jun Kamiaka | ネットワークシステムおよびネットワーク接続確立方法 |
| JP5320561B2 (ja) * | 2009-03-19 | 2013-10-23 | 株式会社日立製作所 | 真正性を保証する端末システム、端末及び端末管理サーバ |
| US9734496B2 (en) * | 2009-05-29 | 2017-08-15 | Paypal, Inc. | Trusted remote attestation agent (TRAA) |
| US9224146B2 (en) * | 2009-09-30 | 2015-12-29 | The Toronto Dominion Bank | Apparatus and method for point of sale terminal fraud detection |
| US9525689B2 (en) * | 2014-03-25 | 2016-12-20 | Symbol Technologies, Llc | Detection of an unauthorized wireless communication device |
| US10438187B2 (en) * | 2014-05-08 | 2019-10-08 | Square, Inc. | Establishment of a secure session between a card reader and a mobile device |
| EP3140796B1 (en) * | 2014-05-08 | 2021-05-05 | Square, Inc. | Establishment of a secure session between a card reader and a mobile device |
-
2017
- 2017-06-30 WO PCT/US2017/040460 patent/WO2018006060A1/en unknown
- 2017-06-30 JP JP2018567857A patent/JP6803935B2/ja active Active
- 2017-06-30 EP EP17742588.1A patent/EP3479320B1/en active Active
- 2017-06-30 CA CA3032173A patent/CA3032173C/en active Active
- 2017-06-30 AU AU2017290878A patent/AU2017290878B2/en active Active
-
2021
- 2021-01-13 AU AU2021200169A patent/AU2021200169B2/en active Active
-
2023
- 2023-03-08 AU AU2023201454A patent/AU2023201454B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP3479320B1 (en) | 2021-11-10 |
| WO2018006060A1 (en) | 2018-01-04 |
| AU2021200169B2 (en) | 2022-12-08 |
| EP3479320A1 (en) | 2019-05-08 |
| AU2017290878A1 (en) | 2019-01-17 |
| AU2023201454A1 (en) | 2023-04-13 |
| JP2019530040A (ja) | 2019-10-17 |
| AU2021200169A1 (en) | 2021-03-18 |
| AU2023201454B2 (en) | 2023-11-16 |
| CA3032173A1 (en) | 2018-01-04 |
| CA3032173C (en) | 2023-05-23 |
| AU2017290878B2 (en) | 2020-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6803935B2 (ja) | 不正および改ざんに対するデバイスの論理的妥当性確認 | |
| US11663612B2 (en) | Logical validation of devices against fraud and tampering | |
| US11374949B2 (en) | Logical validation of devices against fraud and tampering | |
| US10373167B2 (en) | Logical validation of devices against fraud | |
| US10127409B1 (en) | Tamper detection system | |
| US9892293B1 (en) | Tamper detection system | |
| CN113014400B (zh) | 用户和移动装置的安全认证 | |
| US10547625B2 (en) | Software tampering detection and reporting process | |
| KR102526100B1 (ko) | 클라우드-기반 트랜잭션 방법 및 시스템 | |
| RU2523304C2 (ru) | Доверенный администратор достоверности (tim) | |
| RU2537795C2 (ru) | Доверенный дистанционный удостоверяющий агент (traa) | |
| WO2018111601A1 (en) | Tamper detection system | |
| JP2019537776A (ja) | 携帯型支払い用リーダにおける詐欺検出 | |
| CN109496405B (zh) | 利用密码技术的多装置认证方法和系统 | |
| JP2022502881A (ja) | 非接触カードへの潜在的な攻撃を通知するためのシステムおよび方法 | |
| EP3853796A1 (en) | A payment authentication device, a payment authentication system and a method of authenticating payment | |
| Fonte | Host card emulation with tokenisation: Security risk assessments | |
| da Fonte | Host Card Emulation with Tokenisation: Security Risk Assessments |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190206 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20200221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20200313 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200612 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20201120 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20201201 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6803935 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |