EP3996019A1 - Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu - Google Patents

Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu Download PDF

Info

Publication number
EP3996019A1
EP3996019A1 EP21198983.5A EP21198983A EP3996019A1 EP 3996019 A1 EP3996019 A1 EP 3996019A1 EP 21198983 A EP21198983 A EP 21198983A EP 3996019 A1 EP3996019 A1 EP 3996019A1
Authority
EP
European Patent Office
Prior art keywords
data
cryptogram
mobile device
account
cryptographic key
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.)
Pending
Application number
EP21198983.5A
Other languages
German (de)
English (en)
Inventor
Douglas Yeager
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OV Loop Inc
Original Assignee
OV Loop Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=47745052&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP3996019(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US13/491,922 external-priority patent/US20120317628A1/en
Application filed by OV Loop Inc filed Critical OV Loop Inc
Publication of EP3996019A1 publication Critical patent/EP3996019A1/fr
Pending legal-status Critical Current

Links

Images

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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • 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/382—Payment protocols; Details thereof insuring higher security of 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • This disclosure relates to the field of payment and authorization methods. More particularly this disclosure relates to using a mobile computing device in combination with a remotely hosted Secure Element representation to make payments, authorizations or exchange information with other devices.
  • a microchip referred to as a "Secure Element” is embedded into a payment card, a payment fob (medallion), a cell phone, or other mobile devices that may be used for making payments.
  • a device that houses the SE will be referred to as a "card” or “card device”.
  • the "card” or “card device” may not physically resemble the shape or size of a typical payment card and may come in various form factors such as embedded into a mobile phone or embedded into a removable storage or removable device.
  • the SE may be an emulated software based SE and not strictly hardware based. For example, virtually any electronic device with a digital memory and processor or controller may be adapted to emulate and pretend to be an SE.
  • an interrogator also referred to in this document as a "reader”
  • the reader typically follows standards set forth by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) and by application providers (such as VISA and MASTERCARD).
  • Secure element systems typically require that the user have physical possession of a card that matches the authorization capabilities of a merchant's system where a purchase is made. In many instances this is inconvenient. Therefore more flexible and convenient systems and methods for authorizing financial transactions are needed.
  • a method for acquiring digital credential data by a point-of-sale terminal from a mobile device for authorization of a financial transaction includes a step of using a remote permanent cryptographic key to calculate an expected cryptogram that is expected to include at least a portion of the digital credential data.
  • the remote permanent cryptographic key is persistently stored at a remote source that is remote from the mobile device and the mobile device does not store or access a duplicate local permanent cryptographic key persistently stored locally to the mobile device.
  • This embodiment also includes a step of performing an interrogation between the point-of-sale terminal and the mobile device.
  • This performing an interrogation step includes sending through a communication channel at least one POS command communication from the point-of-sale terminal to the mobile device requesting the digital credential data.
  • This performing an interrogation step also includes sending through the communication channel at least one device response communication from the mobile device to the point-of-sale terminal including the expected cryptogram as the at least a portion of the digital credential data, such that the financial transaction is authorized.
  • a further embodiment provides another method for acquiring digital credential data by a point-of-sale terminal from a mobile device for authorization of a financial transaction.
  • This embodiment includes a step of performing an interrogation between the point-of-sale terminal and the mobile device.
  • This performing an interrogation step includes sending through a communication channel at least one POS command communication from the point-of-sale terminal to the mobile device, the at least one POS command communication that includes (a) a request for the digital credential data that is expected to include an expected cryptogram that is expected to be calculated, at least in part, from unpredictable data, and, at least in part, from a permanent cryptographic key and (b) the unpredictable data.
  • This performing an interrogation step further includes sending through the communication channel at least one device response communication from the mobile device to the point-of-sale terminal, with the at least one device response communication including at least a portion of the digital credential data that includes an unexpected cryptogram, substituted in place of the expected cryptogram, such that the financial transaction is authorized.
  • a further embodiment provides a method for acquiring digital credential data by a point-of-sale terminal from a secure mobile device for authorization of a financial transaction.
  • This embodiment includes a step of performing an interrogation between the point-of-sale terminal and the secure mobile device.
  • the performing an interrogation step includes sending through a communication channel at least one POS command communication from the point-of-sale terminal to the secure mobile device, the at least one POS command communication comprising (a) a request for the digital credential data that is expected to comprise an expected cryptogram that is expected to be calculated, at least in part, from unpredictable data, and, at least in part, from a permanent cryptographic key and (b) the unpredictable data.
  • the performing an interrogation step also includes sending through the communication channel at least one device response communication from the secure mobile device to the point-of-sale terminal, where the at least one device response communication includes at least a portion of the digital credential data that includes the expected cryptogram.
  • a secure mobile device transmitting step is provided, which includes sending over a second communication channel the unpredictable data from the secure mobile device to a remote application system.
  • a point-of-sale terminal transmitting step which includes sending over a third communication channel an authorization request from the point of sale terminal to the remote application system, where the authorization request includes the expected cryptogram and the unpredictable data.
  • a corroborative authorizing step is provided in a step that follows the secure mobile device transmitting step and the point-of-sale terminal transmitting step. The corroborative authorizing step includes verifying a correctness of the expected cryptogram by the application system and verifying a correctness of the unpredictable data by the application system by comparing the unpredictable data sent over the second communication channel with the unpredictable data sent over the third communication channel.
  • the corroborative authorizing step further includes sending through the third communication channel an authorization response from the remote application system to the point-of-sale terminal wherein data contained in the authorization response is determined, at least in part, by the verifying of the correctness of the unpredictable data and at least in part by the verifying of the correctness of the expected cryptogram, such that the financial transaction is authorized.
  • an SE Prior to card issuance, an SE is typically injected with personalization or "credential" data that is generated from a "Hardware Security Module” (HSM).
  • HSM Secure Security Module
  • the HSM securely contains the cryptographic keys and algorithms that relate to a particular banking application and more specifically may contain a set of individual digital credentials.
  • An HSM typically is accessed in a secure environment and never allows direct access to master keys which are used to create diversified keys or to encrypt or decrypt input data that may be provided to the HSM.
  • a significant advantage of extracting and delivering data that are contained within an SE is provided by an ability to know beyond reasonable doubt that the data string being delivered indeed came from a particular SE or card. This knowledge creates a more secure transaction with lower risk to the merchant, card issuing bank, and card associations.
  • the methods for extracting information from a banking card involve swiping the magnetic stripe on a card through a magnetic stripe reader, or extracting the information with a separate contact or contactless reader connected to a point-of-sale (POS) terminal. Because of inherent security that is provided by these methods of extracting the information on the card, a merchant may receive a lower transaction fee for that particular transaction.
  • reading or entering account numbers, expiration dates, and card verification codes off of a card during a phone call or internet shopping experience is less secure, and may result in a higher transaction fee.
  • the acquisition of transactional Track1/Track2 data from a SE is "singular." In other words, those data have a life span of a single transaction or a single “swipe" and then the data are no longer valid.
  • the Track1/Track2 data acquired during normal usage of an SE cannot be created by any other entity except the SE which has been programmed with at least one secret key owned by the bank that loaded the key(s) and their accessing system to that SE.
  • Radio Frequency Identification Radio Frequency Identification
  • Mobile phones that contain NFC (Near Field Communication) functionality with embedded SEs have the ability to pretend to be (or emulate) a card that contains an SE.
  • the mobile phone may be presented to the RFID reader just as a card would be presented, and the information may be extracted from the SE that is on the mobile phone and delivered to POS, which then forwards the data on to a card processor for authorization.
  • NFC Near Field Communication
  • Fig. 1 describes a protocol level communication between a reader and an SE.
  • the protocol layer is a standard protocol referred to as APDU.
  • APDU stands for Application Protocol Data Unit and typically the protocol is defined by ISO/IEC specification 7816.
  • ISO/IEC specification 7816 This specification (commonly referred to as "ISO 7816" is a broad specification with different sections directed toward different "layers" of communication protocols, as seen in Table 1.
  • Communications referred to herein as being according to ISO7816-4 correspond to Open Systems Interconnection (OSI) layer 7.
  • OSI Open Systems Interconnection
  • the OSI model is a product of the Open Systems Interconnection effort at the ISO.
  • OSI layer 7 is a high-level software applications layer.
  • C-APDU command APDU
  • R-APDU response APDU
  • “Commands” are sometimes referred to as “queries” because they originate from an “interrogator,” which has a querying connotation.
  • the APDU data typically are transmitted over the air on 13.56 MHz radio waves between the reader and the SE.
  • the APDU commands are just data moving from one entity to another.
  • Various embodiments disclosed herein use the standard APDU commands to interact with the SE regardless of whether the SE is the mobile device's own embedded SE, or is a remote SE embedded into a different mobile device or a card.
  • Communications 1, 2, 3 and 4 show the sequential commands of a typical command and response between and SE and a reader. Usually multiple steps are involved with accessing a SE, which involves multiple APDU commands and responses. Fig.
  • digital credential data refers to at least a portion of all data, including any data that are required to calculate the data, that are necessary to authorize approval of a transaction at a POS terminal.
  • Fig. 2 describes the detailed commands and responses expected when a reader interrogates a MASTERCARD PayPass Mag Stripe Ver. 3.3 application running on a SE. This sequence is provided in the MASTERCARD PayPass card specification. Shown in Fig. 2 are communications 5, 6, 7, 8 and 9 with details including abbreviations and acronyms explained subsequently herein.
  • Fig. 3 describes example transactions at the ISO/IEC 7816-4 Application Protocol Data Unit (APDU) protocol level between a reader and a card.
  • the transaction processing depicted in Fig. 3 is representative of the MASTERCARD PayPass Mag Stripe application card specification v. 3.3.
  • the notation ">CARD” denotes commands to the card and the notation "CARD>” denotes responses from the card.
  • Communication 9 defines some of the initial parameters used in the transaction which include an unpredictable number issued by the reader, a transaction counter maintained on the SE.
  • Communication 10 describes the command that the reader issues to the SE to find out what applications exist on the SE. This example shows that the MASTERCARD PayPass application responds as an active one.
  • communication 11 shows how the reader commands the SE to properly select the PayPass application for further processing.
  • Communication 12 shows how the reader receives the type of processing options that the PayPass application supports.
  • Communication 13 shows how the reader commands and then receives the PayPass application specific credential information about its card holder including card account number, holder name, expiration date, and more.
  • Communication 14 shows how the reader receives the dynamic aspects of the transaction that will be inserted into the Track 1 and Track 2 data.
  • This command uses a shared key on the SE, the unpredictable number from the reader, and the transaction counter on the SE to determine a new number sequence for each transaction called a cryptogram. After the SE calculates the cryptogram, it sends it back to the reader in the response APDU.
  • Fig. 4 describes how the reader 21 in Fig. 5 formats the response data received from the SE into accepted Track1 and Track2 data strings that are used in existing processing systems.
  • Communication 15 shows a Track2 data string built from the card interrogation in Fig. 3 .
  • the CVC3(Track2) UN and ATC numbers will all vary with each transaction or interrogation of the SE.
  • Communication 16 shows a Track1 data string built from the card interrogation in figure 3 .
  • CVC3(Track1), ATC, and UN numbers will all vary with each transaction or interrogation of the SE.
  • Fig. 5 describes the inner architecture of a mobile device that supports NFC functionality. Examples of such devices are described in U.S. Patent 8,151,345 issued to C. Douglas Yeager from U.S. Patent Application Number 12/019,318 . U.S. Patent 8,151,345 and U.S. Patent Application Number 12/019,318 are incorporated by reference in their entirety herein.
  • a base band processor 17 of a mobile device typically runs an OS (Operating System) to control all aspects and interfaces on the device including communication access to the SIM, NFC controller, Secure IC 19.
  • the NFC controller acts as a router to determine where the communication is routed.
  • the baseband controller has the option:
  • Fig. 6 describes a typical interaction between a mobile device with NFC functionality and an RFID POS reader.
  • the mobile device 25 is set to NFC mode in which it is emulating or pretending to be a card.
  • the mobile device 25 is then presented to the RFID reader 27 and communication begins over the 13.56 MHz baseband 26.
  • the reader then interrogates the card similar to Fig. 1 and Fig. 2 , and Fig. 3 and compiles the standardized credential data into Track1 and Track2 equivalent data like in Fig. 4 .
  • Track1/Track2 data that were not generated by a magnetic-head reader from a magnetic stripe on a card, but instead are created in a purely digital data form, such as by an RFID reader.
  • Track Data is used herein to refer to data comprising all or portions of the Track 1 and/or Track 2 data as defined in ISO7813.
  • the data are then delivered to the connected POS computer 29 that then routes the data properly to the processor with other transactional information for authorization.
  • Track Data are delivered to a field in a transaction authorization system using keyboard emulation.
  • keyboard emulation refers to a process of delivering data by a device or software representation of a device that is not a physical keyboard in manner that tricks the operating system into believing that a key has been pressed. Effectively the keyboard emulation system provides an entry as if it were a keystroke in a form field that correctly has the focus of the cursor.
  • Fig. 7 describes a typical transaction flow between an NFC enabled mobile device 52 or a contactless card 53.
  • Step 54 describes setting up the mobile device to perform a transaction with an RFID POS reader.
  • Step 55 describes presenting the mobile device within field range of the RFID POS reader.
  • Step 59 describes presenting a contactless payment card to an RFID POS reader.
  • Step 56 describes the RFID POS reader interrogating either the mobile device or the contactless card over the 13.56 MHz radio.
  • Step 57 describes how the RFID POS reader constructs the Track1/Track2 data from the interrogation.
  • Step 58 describes how the formatted data are delivered to the POS and on to the processor for authorization.
  • RHSE Remote Hosted Secure Element
  • An RHSE is a repository for a plurality of "secure element representations" each of which is provided for one or more mobile devices or mobile device owners.
  • the repository storing the plurality of secure element representations is typically remote from the point-of-sale terminal.
  • remote refers to locations that are geographically far apart.
  • remoteness is that the two locations are not within a distances such that most persons at one or the other of the remote locations would consider walking to the other location, or at least would not be able to do so within one day.
  • This frame of reference is provided merely to explain the meaning of the term "remote" and does not imply that actually walking between remote locations has anything to do with embodiments disclosed herein.
  • remoteness using as an example the situation where many point-of-sale terminals are serviced by one repository, it is entirely possible that one or more of the point-of-sale terminals may be within walking distance of the repository.
  • the term "local” refers to locations that are geographically proximate to each other. One indication of a local relationship between two locations would be the locations are separated by a distance of less than one foot.
  • the plurality of secure element representations (or the "array of secure element representations") is typically hosted in a secure environment such that it is protected from cyber attack.
  • the secure element representations may be (a) actual SE hardware (referred to herein as a "hardware representation”), or may be (b) virtual hardware secure element representations such as a computer model that simulates the operation of a hardware SE element (referred to herein as a “virtual hardware secure element representation”), or may be (c) data in a database (typically a secure database), such as static Track Data or data dynamically or statically generated by an HSM (Hardware Security Module), where the data in the database are elements of data that are typically stored in an SE memory (referred to herein as a “database secure element representation”).
  • HSM Hardware Security Module
  • a "secure element,” a “remote secure element,” an “SE,” or a “remote SE” may be a hardware representation, or a virtual hardware secure element representation, or a database secure element representation.
  • Each form of representation, or a combination of just two of these three forms of representation, may be advantageously employed in certain embodiments such as described in the context of various figures and descriptions provided herein.
  • a repository may be created with a network server that is connected to a wide-area network (such as the internet) and one or more SE readers that are each addressable by the network server.
  • the one or more SE readers receive ISO 7816 protocol commands for communication to an SE using a communications protocol such as TCP/UDP/IP data packets.
  • the one or more SE readers are each in communication with one or more SE's.
  • Software and hardware that interacts with each card reader has the ability to query (command) each SE at a particular network address that corresponds to a particular remote mobile device.
  • the one or more SE readers may interact with the virtual hardware secure element representations in substantially the same manner as the one or more SE readers interact with hardware representations (i.e., actual SE hardware).
  • a software representation allows a completely contained system that gives the same remote mobile device functionality as the previous completely hardware based case.
  • An example of a virtual hardware secure element representation is the jcop.exe software that is presently sold and supplied by NXP semiconductor within the JCOP tools suite.
  • the jcop.exe software provided is not a secure element, but rather a self-contained smart card operating system contained within an executable file that is meant to run on a host computer as a process.
  • JCOP tools suite that contains jcop.exe additionally is a development platform to develop Java Card applications. JCOP tools give the user the ability to program and test application-specific software. This is accomplished using a combination of a virtual machine (the Java Card Virtual Machine, one version of which is contain in the jcop.exe referenced above) and a well-defined runtime library, which largely abstracts the applet from differences between smart cards. Using this technique one can run and debug both the Java Card code for the application that will eventually be embedded in a smart card, as well as a Java application that will be in systems that will use the smart card, all working jointly in the same environment.
  • a virtual machine the Java Card Virtual Machine, one version of which is contain in the jcop.exe referenced above
  • a well-defined runtime library which largely abstracts the applet from differences between smart cards.
  • an array of SEs may include combinations of one or more types of secure element representations. That is, an array may include hardware representations and/or virtual hardware representations and/or database secure element representations.
  • the SE hardware implementation may be the preferred case by the financial transaction industry simply because of the more secure nature of controlling the removable SE that may be manufactured with secure data residing on the SE chip in a secure facility and then shipped to the remote system facility to be plugged in and activated and verified.
  • Fig. 10 illustrates a repository 300 that employs hardware representations of secure elements.
  • the repository 300 includes at least one secure element reader 304, and in the embodiment illustrated the repository 300 includes one secure element reader 304 having four RFID antennas 308.
  • the secure element reader 304 is a contactless (RFID) reader operating under ISO 14443A or B protocols.
  • a repository (such as the repository 300) typically includes a plurality of secure element representations, and in the embodiment of Fig. 10 the repository 300 includes eleven secure element hardware representations 312 each of which is integrated into one of eleven bank-issued transaction cards.
  • the secure element reader 304 is disposed adjacent to the plurality of secure element hardware representations 312.
  • a data server 316 is provided to communicate with the plurality of secure element representations 312 through the secure element reader 304.
  • a data server (e.g., the data server 316) is a hardware/firmware device that includes a multitasking processor, such as a multithreading processor, or a parallel processor, or a time-shared processor, to communicate with a plurality of secure element representations (e.g., the secure element hardware representations 312) through a secure element reader (e.g., the secure element reader 304).
  • a multitasking processor such as a multithreading processor, or a parallel processor, or a time-shared processor
  • a secure element reader e.g., the secure element reader 304
  • such communication is conducted according at least one part (e.g., part 1, part 2, part 3 or part 4) of the ISO7816 specification to extract at least a portion of the digital credential data from a the paired secure element representation.
  • the secure element reader 304 includes a multiplexor in order to sequentially address the secure hardware element representations 312. Typically the multiplexor is part of the hardware at the reader circuitry level. In other embodiments the multiplexor may be provided in software. The multiplexing function allows a single secure element reader to rotate through multiple ports or antennas in order to address and communicate with a plurality of secure element representations.
  • Such a configuration allows a data server (e.g., the data server 316) to conduct a plurality of command/response time-wise overlapping sessions with the plurality of secure element representations (e.g., the secure element hardware representations 312) without causing confusion about which card is being interrogated and which card is responding.
  • the data server 316 also includes a network interface processor that communicates with the internet over an internet connection 320.
  • the use a plurality of secure element hardware representations to store multiple different secure elements in a common processing environment in order to conduct a plurality of command/response time-wise overlapping sessions with the plurality of secure element hardware representations provides utility (as an SE repository) that is unexpected from the usual application a secure hardware representation, such as a single bank-issued card that is read by an SE reader at a point-of-sale terminal.
  • Fig 8 illustrates an embodiment of a repository 400 that employs a plurality of contact readers 404 operating under ISO 7816.
  • a separate dedicated reader is provided for each of a plurality of secure element hardware representations 408.
  • the secure element hardware representations 408 are bank-issued cards containing a secure element chip that is accessible by a Universal Serial Bus (USB) connector, and the contact readers 404 are USB readers.
  • a first portion 420 of a CPU 424 in a computer 428 is a multitasking data server to conduct a plurality of command/response time-wise overlapping sessions with the plurality of secure element hardware representations 408 through the plurality of contact readers 404.
  • the USB standards typically limit the number of USB ports on a computer to 127 ports.
  • a different bus architecture may be used to overcome that limitation, or a single USB reader may be configured to address multiple cards through electronic or even mechanical switching mechanisms. In the latter case the switching mechanism acts as a portion of a multitasking data server.
  • a plurality of secure element representations may be disposed proximate to a secure element reader.
  • proximate to and local refers to a spatial condition where two devices are close to each other, but may not be adjacent to each other. For example, two devices that are in the same building (but not the same room) are considered to be proximate to each other.
  • the term "proximate to” encompasses devices that are "adjacent to” each other.
  • a second portion 432 of the CPU 424 is a network interface processor that communicates with the internet over an internet connection 436.
  • the internet connection 436 to the second portion 432 of the CPU 524 provides addressability of the plurality of secure element hardware representations 408 over the internet.
  • the use a plurality of secure element hardware representations to store multiple different secure elements in a common processing environment in order to conduct a plurality of command/response time-wise overlapping sessions with the plurality of secure element hardware representations provides utility (as an SE repository) that is unexpected from the usual application a secure hardware representation, such as a bank-issued card.
  • Fig. 9 illustrates a repository 500 that employs virtual hardware secure element representations.
  • a plurality of instances of virtual hardware secure element representations (shown symbolically as elements 504) is provided in a memory 508 of a computer 512.
  • These virtual hardware secure element representations 508 may be multiple instances of the Java Card software previously described. Each instance is programmed as if it were a different secure element. Typically each instance is a separately-running thread of a standard jcop.exe program.
  • Each instance may be run from a DOS command line such as: jcop.exe -port 50000 Running that command opens up a TCP/IP PORT number 50000 and, presuming that the computer is on the internet (such as per internet connection 516), the program listens for telnet terminal type data on the telnet port, shown symbolically as element 518. It is expecting ISO7816-4 data communications and will respond just like a real SE with response ISO7816-4 data.
  • DOS command line such as: jcop.exe -port 50000
  • Running that command opens up a TCP/IP PORT number 50000 and, presuming that the computer is on the internet (such as per internet connection 516), the program listens for telnet terminal type data on the telnet port, shown symbolically as element 518. It is expecting ISO7816-4 data communications and will respond just like a real SE with response ISO7816-4 data.
  • telnet 192.168.0.14 50000 where the 192.168.0.14 is the IP address of the computer 512 where the simulation program (jcop.exe) is running, and where 50000 is the port number that it is running on.
  • a local I/O bus 520 is controlled by a CPU 424 in the computer 512 so that when the telnet window on the second computer connects to that IP address and port number on the first computer 512, standard command/response communications may be established by sending 7816-4 formatted data and getting the response from the designated virtual hardware secure element representation 504 back into the telnet window of the second computer.
  • a first portion 520 of the CPU 524 operates as a secure element reader using a local I/O bus 528 to communicate with the virtual hardware secure element representations 504.
  • the instances of virtual hardware secure element representations 504 are a plurality of secure element representations proximate to the secure element reader (I/O bus 528).
  • a second portion 532 of the CPU 524 is a data server to conduct a plurality of command/response time-wise overlapping sessions with the plurality of secure element representations (e.g., the virtual hardware secure element representations 504) through the first portion 520 of the CPU 524 that is operating as the secure element reader.
  • the second portion 532 also includes a network interface processor that communicates with the internet over the internet connection 516.
  • the secure element reader i.e., the first portion 520 of the CPU 524) is disposed adjacent to the plurality of virtual hardware secure element representations 504. In other embodiments a secure element reader may be disposed proximate to the plurality of virtual hardware secure element representations.
  • the internet connection 516 to the second portion 532 of the CPU 524 provides addressability of the plurality of secure element representations (504) over the internet.
  • the use of multiple instances of the JCOP environment to store multiple different virtual hardware secure elements in a common processing environment in order to conduct a plurality of command/response time-wise overlapping sessions with the plurality of virtual hardware secure element representations provides utility (as an SE repository) that is unexpected from the usual application of the JCOP programming environment.
  • Fig. 11 describes an inner architecture of a mobile device 626 that supports NFC functionality and how that device may allow access to its attached secure elements as well as access to a secure element where the mobile device is remote from the secure element.
  • a base band processor 17 is provided in the mobile device and the baseband processor 17 typically runs an OS (Operating System) to control all aspects and interfaces on the device including communication access to the SIM 20, NFC controller 18, Secure IC 19, or data that are eventually that are eventually sent to the internet 35.
  • the NFC controller 18 acts as a router to determine where the communication is routed.
  • the mobile device may emulate a card (pretend to be a payment card).
  • the NFC controller 18 which is controlled by the baseband processor 17 in the mobile device may be configured to route interrogation commands and responses (such as communications 1, 2, 3, 4, 5, 6, 7, and 8 depicted in Figs. 1 and 2 ) from the reader (interrogator) 21 to a secure element for processing and response.
  • interrogation commands and responses such as communications 1, 2, 3, 4, 5, 6, 7, and 8 depicted in Figs. 1 and 2
  • an SE application that is used in a payment transaction may be configured to respond to interrogation commands the same or similar to the sequences described in Fig. 1 and Fig. 2 .
  • the commands and responses illustrated in Fig. 1 and Fig. 2 are comprised of a string of data that conforms to ISO/IEC 7816 specification.
  • the baseband controller may choose to route the commands from the reader 21 to any secure element it chooses for processing.
  • All options a., b., c., and d. use APDU data to exchange information between the RFID reader 21 and the applications located in an SE located in the mobile device 626 or in a remote SE 634. It is important to note that the remote SE 634 may also be created with software and emulated within the remote system 631. The interrogation example mapped out in Figs. 3 and 4 may be implemented on this system in all 4 modes a., b., and c., and d. above. Thus the remote system SE 634 may perform the identical interrogation on a remote secure element 634
  • an entire interrogation similar to those described in Fig. 1 , and Fig. 2 may be carried out from a RFID POS reader 21 through an NFC enabled mobile device 626, through a data connection over the internet 35 to a remote system 631 that contains the actual SE 634.
  • An example of reader commands is illustrated in element 638 as a PayPass reader.
  • the PayPass reader 638 shows an exemplary sequence of ISO/IEC 7816-4 APDU commands and responses that may be pushed through the reader 21 and end up at the remote SE 634.
  • Element 637 shows an example of APDU commands that are received by the remote SE 634 and the appropriate response that is issued as defined by the 7816-4 application for MASTERCARD PayPass.
  • Elements 638 and 637 show how Figure 2 may be broken up so that the PayPass card may be hosted on a remote SE 634 on a remote system 631 and show that the PayPass reader may be an RFID POS 621.
  • the remote system 631 has a connection to the internet 630 and connections to an array or plurality of SE readers 633 that are each connected to an SE 634.
  • a server or set of servers 632 may be used for pairing the connections originating at the mobile NFC device 626 to the correct SE 634 within the remote system 631.
  • the server or set of servers 632 may, for example, be one or more computers each of which has access to control one or more of the SE readers 633.
  • the data connection described in Fig. 11 is a TCP/UDP/IP connection that is offered by most cellular carriers over a cellular network and cellular towers 629 using a cellular link 628.
  • the TCP/UDP/IP connection may run socket software that allows for raw data to be transmitted from one end of the data connection 626 and the other 631 and vice versa.
  • the data packets within the socket software may be configured to exchange data that contains ISO/IEC 7816-4 data.
  • a stationary device may be used in place of the mobile device 626 depicted in Fig. 11 .
  • Fig. 12 describes a remote system 700 that is capable of bridging a data (TCP/UDP/IP) connection through the internet 35 to a single addressable SE reader 749 and SE 750.
  • Communications 740 and 741 show how a data link (TCP/UDP/IP) 740 may be used to pass ISO/IEC 7816-4 APDU data 741 to a remote server 742.
  • the remote system is identified on the internet through the IP address 743.
  • the remote system is comprised of a remote server 742 that routes the connection to an internet network of attached SE Array Managers 746.
  • the TCP/UDP/IP data 740 that enters this remote system and is routed to the internal SE Array Manager 746 over TCP/UDP/IP 744 contains data that uses the protocol for ISO/IEC 7816-4 APDU data 741 and 745.
  • Each SE Array Manager 746 contains an internally unique IP address 748 within a TCP/UDP/IP socket server 747.
  • Each TCP/UDP/IP socket server 747 is responsible for receiving ISO/IEC 7816-4 APDU data 745 and routing as it as ISO/IEC 7816-4 APDU data 751 to the appropriate addressable SE reader 749 and SE 750.
  • Fig. 12 further illustrates one method to create a communication channel from the remote system to the mobile device over TCP/UDP/IP using socket server and client methods.
  • Identification data from the mobile device may be used to set up a socket connection all the way through the remote server 742 to the TCP/UDP/IP socket server 747.
  • the data that are sent over the socket server and client may be formatted to be ISO/IEC 7816-4 APDU data.
  • the APDU command may enter the socket server 747 and be routed to the appropriate SE reader 749 and SE 750 and the response APDU may be sent from the SE 750 and SE reader 749 back to the remote mobile device through the SE Array Manager socket server 748, the remote system socket server 742, and through the internet 35 and be received by the socket client on the remote mobile device.
  • Fig. 12 also depicts a plurality of remote SEs that are each addressable and may be accessed by a plurality of remote mobile devices independently.
  • the descriptions herein above describe how a single remote mobile device may connect to a remote system and specifically a single remote SE to complete a transaction. This same process may occur through this same system concurrently with different SE's in the system from different remote mobile devices.
  • Fig. 13 depicts a table in a database that may be used to identify which remote SE within a remote system described in Fig. 12 that a user and particular mobile device may be attached to.
  • Unique row identifiers 754 are provided in the table. Each row contains related data.
  • the other columns of this table are the User ID 752 and the SE Address 753.
  • the SE address is the unique address within the remote system for a particular SE.
  • the table of Fig. 13 further illustrates a relationship 755 between two fields that form a row in the database. This table in Fig. 13 may be used to properly match a remote user or remote mobile device with the address of a particular SE.
  • validating a mobile device by a repository involves pairing a particular secure element or secure element representation to a specific mobile device. Generally this involves establishing at the repository a digital database that lists at least one secure element representation identifier for each of a plurality of mobile device identifications.
  • Fig. 14 describes one process flow for allowing a data connection between a mobile device and remote hosted secure element.
  • Step 756 describes how a mobile device that supports NFC is initiated and presented to a RFID POS reader in order to make a payment transaction.
  • the phone is placed into a mode that is referred to as card emulation mode where the NFC interface on the phone pretends to be contactless RFID card.
  • the phone has a bit more control to select which card is presented to the POS.
  • the subject of this patent describes how the NFC mobile device has the ability to use a SE for the transaction that is not physically located in the mobile device. This may be done be creating a data connection to a remote SE for which is used for the payment transaction.
  • step 757 while the phone is being placed into card emulation mode, the connection to the remote SE that will be used for emulation is attempting to connect. As illustrated in step 758 there is a chance that the connection is already open in which case the flow in Fig. 14 will simply allow the ISO/IEC 7816-4 APDU data to pass directly through the connection to the remote SE and back 763 successfully completing the transaction 764. There is also a chance that the connection to the remote SE does not exist and needs to be created, as described subsequently in step 762.
  • a mobile device authenticate itself with a remote hosted secure element.
  • the method of authentication to the remote system may, for example, be initiated and completed using HTTPS/SSL (Hypertext Transfer Protocol Secure / Secure Socket Layer (SSL) or Transport Layer Security (TLS)) web services.
  • HTTPS/SSL Hypertext Transfer Protocol Secure / Secure Socket Layer
  • TLS Transport Layer Security
  • Authentication may also be initiated and completed using a telephone link, such as a cell-phone connection.
  • authentication is facilitated through a remote system authorization server.
  • remote authorization server refers to an electronic computer or set of computers configured for the purpose of approving or disapproving access to a particular secure element by a particular mobile device or stationary device.
  • a remote system authorization server may be configured to access secure element representations that may be either proximate to the remote authorization server or that may be proximate to the remote authorization server, and in such embodiments the remote system authorization server is considered to be a remote repository having a plurality of secure element representations.
  • the mobile device connecting to the remote system is able to pass various credentials to the remote system such as user ID, passwords, PIN, "gesture signal,” unique electronic communication device identity number, and so on securely to the remote system for mobile device validation 759.
  • the system attempts to match and verify the user information in the remote system.
  • the verification includes an assessment as to whether the gesture signal is a valid gesture signal (i.e., a gesture signal that is expected by the remote system).
  • the remote system Upon a successful match the remote system is said to "validate” the remote device, and the remote system opens up a communication channel (step 762) to the appropriate SE within the remote system and creates a handle to that communication channel that may be used to access it from the remote mobile device.
  • a communication link is established between a mobile device (or a stationary device) and a particular SE in a repository, the device and the particular SE may be described as being “paired" with each other.
  • the remote system may securely pass back over HTTPS/SSL a shared encryption key and handle to the communication channel that may be used for continued communication over that communication channel through a TCP/UDP/IP data socket 762. If the authorization fails (step 765), the connection to the remote SE is not opened, and the process ends.
  • the remote device receives the shared encryption key and handle to the communication channel to a particular SE on the remote system, the ISO/IEC 7816-4 APDU commands from the RFID POS may be passed to this remote hosted SE through a socket connection and the data may be encrypted with the shared encryption key.
  • the remote system may decrypt the data and send it to the correct SE within the remote system.
  • the remote system may then send the response APDU from the SE back to the remote mobile device in a similar manner.
  • the remote mobile device may forward this response APDU back through the NFC interface to the RFID POS reader.
  • Some electronic communication devices (such as a mobile device) have memory for storing at least a portion of digital credential data as cached data. Such electronic communication devices are configured to send the cached data as at least a portion of a device response communication.
  • cache data can be copied from or extracted from data within a single secure element representation that is specifically matched or "paired" to an electronic communication device and may be provided to the electronic communication device, such as in Fig. 17 , element 801.
  • the electronic communication device may be paired with the single secure element representation for the purpose of extracting or copying cache data and may not be paired for any subsequent command/response communications.
  • Such cache data are a "cached portion" of a set of digital credential data, and in some embodiments this cached portion is all of the digital credential data that are needed to complete a transaction.
  • the cache data may include an ISO 7816-4 protocol response communication.
  • the cache data may also include ISO7816-4 protocol command communication for the purposes of matching or analyzing it against other incoming ISO7816-4 protocol command communication data to determine which ISO7816-4 protocol response communication from the cache to use.
  • Fig. 15 illustrates an authorization and communication process in more detail.
  • the vertical line 766 represents the RFID POS entity.
  • the vertical line 767 represents the mobile device.
  • the vertical line 768 represents a remote system authorization server, and the vertical line 769 represents the remote hosted SE.
  • the mobile device 767 may interact with a remote authorization server (e.g., remote authorization server 768) in order to facilitate the access of digital credential data from a remote hosted SE (e.g., remote SE 769).
  • a remote authorization server e.g., remote authorization server 768
  • a communication channel is opened between the RFID POS 766 and the remote SE 769.
  • Authorization over SSL is initiated where credentials 770 are sent to the remote authorization server 768.
  • the remote authorization server 768 verifies the credentials and sends back a successful response 771 which contains a handle to a communication channel and an encryption key.
  • the mobile device 767 may then open a channel to the remote SE 769.
  • APDU command and response APDUs may be sent securely between the RFID POS reader 766 and the remote SE 769 and back through the mobile device 767.
  • An APDU command 772 is sent from the RFID POS reader 766 to the mobile phone 767, which may encrypt that APDU as command 773 and forwards an APDU command 773 on to the remote system 768 and on to the remote SE 769 as APDU command 774.
  • the command communications 773 and 774 comprise at least a portion of the command communication 772 from the RFID POS 766 to the mobile device 767.
  • the mobile device 767 may know ahead of time what the RFID POS 766 will command the mobile device 767 in the APDU command 772 in advance of actually interacting with the RFID POS 766.
  • the command 773 may have been sent already sent by the mobile device 767 before the command 772 was received by the mobile device 767 from the RFID POS 766.
  • the return APDU response from the SE is delivered back to the RFID POS through the communication channel using the handle provided by the response 771, via communications 775, 776, and 777.
  • data are intended to go round-trip from a mobile device to a remote SE.
  • Many payment applications that communicate with an SE may require a plurality of commands and responses to the SE for each transaction carried out by an interrogation from the POS RFID reader.
  • Each or some of these command and responses to the SE may be subject to network delays and latency. Prolonged delays during a transaction with the RFID POS may cause an unsatisfactory user experience.
  • the remote SE took ⁇ 400ms longer in the above example due to network latency and delay during the SE interrogation.
  • a local cache (a memory located in the mobile device for data caching) may be implemented for use in some embodiments.
  • Many of the responses to a 7816-4 APDU commands or queries are static and unchanging in a payment application on a SE.
  • a cache system may be configured to respond locally for these static information requests with the known 7816-4 APDU data responses, and to only generate real-time commands the remote SE in the event that the response 7816-4 APDU data are dynamic or changing with each transaction. This should limit the number of round trip data requests to the remote SE. Because each round trip request to the remote SE is subject to network delay and latency, a relatively significant total transaction time savings may be realized.
  • the main advantages of implementing a caching system in the current invention is to save over-all time to perform a full transaction with a payment card application between a RFID POS reader through a mobile device to a remote SE.
  • Fig. 16 illustrates an example of caching being used during a MASTERCARD PayPass transaction between a RFID POS and a remote SE.
  • the vertical line 778 represents the RFID POS entity.
  • the vertical line 779 represents the mobile device.
  • the vertical line 781 represents the remote system authentication server, and the vertical line 782 represents the remote hosted SE.
  • the vertical line 780 represents the caching system in the mobile device.
  • the MASTERCARD PayPass card specification indicates that the response to the Select PPSE APDU 83 will always be the same:
  • the MASTERCARD PayPass card specification indicates that the response to the Select PayPass AID APDU 84 always be the same:
  • the MASTERCARD PayPass card specification indicates that the response to the GPO (Get Processing Options) APDU 785 always be the same:
  • the MASTERCARD PayPass card specification indicates that the response to the Read Record APDU 786 is to always be the same for a particular card that has been personalized, but will be different from personalized card to a different personalized card:
  • the MASTERCARD PayPass card specification indicates that the request and the response to the Compute Cryptographic Checksum APDU 787 will always be different for each transaction. This means that this APDU will always need to be processed by the actual remote SE through the data network.
  • Communication 793 indicates the estimated or example of network processing time for this single APDU command and response 787.
  • the over-all example in Fig. 16 illustrates how there is potentially only a single command and response that need to happen in real time over the data network 793 as a result of implementing a caching system.
  • communications 788 illustrate one method to maintain the proper state of the remote SE 882 when a caching system is used. It is important that the remote SE 782 maintain the same processing state as the system is expecting when introducing a caching system. For this reason, it is important to actually issue the APDU commands to the remote SE in order to bring that SE to the appropriate system state.
  • the dashed line illustrates how these ghost commands may be issued by the remote system in order for the SE to maintain an up-to-date state.
  • the communications 789, 790, 791, and 792 mirror the APDU commands and responses 783, 784, 785, and 786 managed by the caching system 780.
  • Fig. 17 illustrates a slightly different caching concept using a VISA payWave transaction as an example.
  • the entire transactional sequence with all APDU commands and responses is cached at a separate time 802 prior to the actual transaction.
  • the RFID POS 794 does not initiate the initial request to the remote authentication server 797. Instead, it is initiated by the mobile device application at some prior time from the actual RFID POS transaction.
  • the remote system authentication server 797 When the mobile device 795 makes a request to the remote system authentication server 797, the remote system authentication server 797 either retrieves caching information from a database, or from making a request to a HSM (Hardware Security Module) or other storage system or, if needed, makes commands with a remote SE 799 as indicated by the dotted box in the figure with a read record request 800 to the remote SE 799.
  • the remote SE 799 may be a hardware representation of a secure element or a software representation of a secure element. This example is particularly pertinent in the event that the response to the read record request 800 is dynamically changing data with each individual transaction with the SE.
  • the entire set of caching information may be passed back to the mobile device 795 as shown in communication 801.
  • communication 801 the SE responses to Select PPSE, Select PayPass, GPO, and Read Record APDU is passed back to the mobile device all at once.
  • Fig. 17 illustrates an unspecified time delay 802 after communication 801 until the actual start of the RFID POS transaction 803.
  • the cached APDU command and response data may be stored safely in non-persistent memory or RAM in a cached format 796.
  • An alternative is to store this data safely through encryption techniques in a persistent manner.
  • Communications 804, 805, 806, and 807 illustrate the real time transaction with an RFID POS at a later time 802 than the previous interaction with the remote authentication server 797.
  • each and every response APDU command that the RFID POS requested was replied to locally by the mobile device cache 796.
  • Fig. 18 closely represents an embodiment which employs secure element software representations where the secure element software representations are in the remote system authorization server 836.
  • Much of the transaction scenario in Fig. 18 is identical to Fig. 23 including the time delay 838 (802 in Fig. 23 ) prior to the actual transaction 840 (803 in Fig. 23 ) and the delivery of the transactional data from the server 836 (801 in Fig. 23 ).
  • This type of data substitution is possible with existing contactless APDU commands as defined in the VISA payWave card specification. That card specification allows for a transaction with an RFID POS to be made using these commands:
  • the read record command for VISA payWave indicates there may be 3 data elements with the tags:
  • Specifically Tag 57 is a required tag that presents Track 2 Equivalent Data to the POS transaction.
  • This format of the data is processed by the RFID POS and converted into ISO7813 data format.
  • An example of this data conversion is this:
  • Fig. 19 illustrates two embodiments of SE repositories, repository 156 and repository 157, to illustrate some similarities between hardware representations of an SE 147 and a software representation of an SE 154.
  • the mobile device that is accessing the secure element representation is remote from repository 156/157, and the secure element representation is accessed over an internet 152 or other global network.
  • the hardware representation of the SE 156 is a "chip" that may be mounted to a circuit board or located in a physical plastic card or a SIM module.
  • Each such form factor has both power 145 and ground 146 lines, and also includes a data line 150 that is configured to be half duplex communication over various serial data rates 149.
  • the SE 147 is a fully functional processor chip that includes ROM, RAM, communications controller, EEPROM or persistent memory and a processor. It is addressable by and communicated with by a Network Server 148 provided the correct conversion hardware is in place to do so. Such conversion hardware is depicted in Fig. 12 where the SE array manager 746 sits in between the network server 742 and the SE's 750. One job performed by the SE array manager 746 is to translate TCP/UDP/IP communication packets from the network server 742 into 7816-4 data packets for the SE's and vice versa.
  • the Network Server 148 serves as a communication server for communicating with the SEs and as a network interface with the internet 152.
  • the APDU data communication (typically standard SE communication) between the Network Server 148 and the SEs 147 is extended to the Internet 152 over TCP/UDP/IP protocol.
  • Fig. 27 for clarity of illustration, details are depicted for only one hardware representation of SE 147.
  • Fig. 19 shows a repository 157 where the function of the SE are handled as multiple software representations 154 (SE Emulation Instances) in a single computer or a bank of several computers. In this configuration, there is no separate hardware that is the SE.
  • the functions of the SEs are provided as software representations depicted as SE Emulation Instances 154 that are established entirely in software and contained inside a Network Server 153.
  • the communication format of APDU 7816-4 structure 155 may also be provided by the software of the Network Server 153.
  • a general purpose computer or server typically has all the necessary components (such as ROM, RAM, Persistent Memory, and a processor) that are necessary to provide the SE software representations.
  • the software architecture within the Network Server 153 may be arranged as such to divide and address many different SE software representations 154 within a single computer. In the same manner the hardware based SEs 147 are exposed to the Internet over TCP/UDP/IP, the software representations of the SEs 154 are also be exposed to the Internet.
  • Fig. 19 illustrates that either of the depicted architectures (i.e., the hardware representations 147 and the software representations 154) are functionally interchangeable and are interoperable from the external world over the Internet.
  • Fig. 19 also suggests that a repository (such as repository 157) using software representations of SEs may be more easily scalable than a repository (such as repository 156) using many hardware representations.
  • the use of virtual hardware representations may be a good compromise between the security of hardware representations and portability and scalability of database secure element representations.
  • Fig. 20 illustrates communications channels and communications between a point-of-sale terminal and an electronic communication device and a repository, according to some embodiments.
  • the first communication channel may, for example, include a near field communication channel or an internet connection.
  • the electronic communication device 912 may be a mobile device or a stationary device.
  • the second communication channel 916 may include, for example, a cell-phone connection or an internet connection.
  • a POS command communication 924 may be sent over the first communication channel 904 and a device command communication 928 may be sent over the second communication channel 916.
  • a repository response communication 932 may be sent over the second communication channel 916 and a device response communication 936 may be sent over the first communication channel.
  • Fig. 21 illustrates an arrangement of an application system 201 (a variant of remote system auth server) that contains a Hardware Security Module (HSM) 200.
  • the application system also includes a system of one or more computers that all may have access to the transaction table 205 and the credential table 206 within the application system.
  • the application system contains data that should be kept in a secure manner and as a result may have both network accessibility and physical accessibility limitations built in to it.
  • the application system can be further detailed as a "software representation" of a plurality of secure element representations as the application system has access to all the information used to create APDU responses for any particular SE representation in its repository data.
  • An added feature of the application system that extend its capabilities beyond a "software representation" of a plurality of secure element representations is that because it has access to the HSM that stores keys used to create the data in each SE representation, it can be configured for authorizing or verifying the output data (digital credential data) for any of the SEs contained in its repository data as well.
  • An HSM is a device commonly used in the banking and processing industry. The HSM is responsible for securely containing encryption keys 203 (cryptographic keys) that are used to authorize card payments, or create digital credential data for new cards. Encryption algorithms 204 that use these keys are also contained on the HSM.
  • An example of an HSM used in the industry at the time of this filing is currently distributed by SafeNet Inc. and is named the Luna EFT Mark II Edition.
  • an issuer Master Key An example, from the MasterCard PayPass MSD v3.3 card specification document, of an encryption key that may be stored on the HSM is called an Issuer Master Key (IMK).
  • the HSM can then, for example, use the embedded algorithms 204 to create a "diversified key for card verification code creation" (KDcvc3) from the IMK that is used for each individual card that is issued based on a certain algorithm that is also stored in the HSM.
  • KDcvc3 "diversified key for card verification code creation”
  • the HSM is designed to protect individual encryption keys, and to use embedded encryption algorithms to calculate encryption output based on an encryption input request from an application system.
  • the encryption algorithm must be located within the HSM because the algorithm must have direct access to the protected encryption keys 203.
  • the application system will provide additional input data to be used in the encryption algorithms to the HSM.
  • the application system will also expect output data from the encryption algorithms from the HSM.
  • the input data to the HSM may be stored in the transaction table 205 and the credential table 206.
  • An HSM is commonly a separate device within the application system that is connected to other devices within the application system through a communication channel.
  • the communication channel may be a network connection such as an RJ45 cable or in some cases is a hardware bus connection such as a PCI connector within a computer casing.
  • An example of using this arrangement may be that the application system contains:
  • the application system 201 is an embodiment of a "software representation" of a repository of a plurality of secure element representations and has access to all the information that is used to create APDU responses generated by any particular database SE representation in its repository data.
  • This repository data is represented in the credential database table 206.
  • credential data such as PAN, expiration date, card holder name, contactless application type, automated transaction counter, card record, etc.
  • the application system has the ability, using the data in the credential table, transaction table, and HSM, to formulate all the responses that the mobile device may need at a later point in time when the mobile device is being interrogated by the point-of-sale.
  • This set of responses could be in the format of APDU responses and passed to the mobile device to be cached for use later.
  • just the data required for the mobile device to formulate the responses may be passed to the mobile device cache.
  • the application system also may have access to the encryption key for creating cryptograms in the HSM, in which case the keys themselves could be sent to a mobile device to allow the mobile device to calculate a cryptogram that may be requested by a point-of-sale.
  • SE responses are shown in Fig. 3 next to the 'CARD>:' prompt indicating data from the SE to the point-of-sale.
  • the application system may know the specific responses based on a number of factors.
  • the responses are for a PayPass 3.3 MSD transaction, because the application system knows the particular card id or PAN is associated to this PayPass 3.3 MSD transaction, and the PayPass card specification for 3.3 MSD dictates specifically elements 10, 11, and 12 exactly as shown in figure 3 , so the response APDU data as shown in 10,11, and 12 can be sent verbatim over a communication channel to the mobile device cache when requested by the mobile device.
  • element 13 after the 'CARD>:' prompt shows the format of the read record command response, but the data inside the response may change from one card id or PAN to another because it is credential data that is stored in the read record command response.
  • the application system has access to all the credential data that comprises the response to the read record command such as displayed, in part in figure 2 , element 7:
  • the term "cryptogram” refers to encrypted data that may or may not be able to be un-encrypted. Encrypted data that cannot be un-encrypted is many times called a "hash.”
  • a cryptogram is typically calculated from a series of input data that comprises some data and a cryptographic key, where the cryptographic key is used to encrypt some data.
  • the term “cryptographic key” refers to a key used, at least in part, to calculate a cryptogram.
  • a cryptogram is calculated based on an algorithm or calculation formula.
  • the term “calculation formula” refers to an algorithm or formula that is specified by a card specification as the method to calculate a cryptogram. A calculation formula typically may be known by any entity.
  • the output result of the calculation formula that uses the input data and a cryptographic key is a cryptogram.
  • Examples of cryptograms at the time of this filing are defined by the following card specifications in table 4.
  • a "cryptogram” as used herein may be classified as "dynamic” meaning that it is always changing from one interrogation (transaction) to the next over the life a digital credential (SE representation).
  • life of' refers to the life beginning when it is used its first interrogation and ending when it is used in its last interrogation.
  • One indication of this dynamic aspect of a cryptogram is to perform two sequential independent interrogations between a mobile device and a point-of-sale terminal where the same digital credential is used on the mobile device, and the point-of-sale terminal receives two sets of digital credential data with each including a single cryptogram, one with each interrogation. If the cryptogram received by the point-of-sale terminal is different from one interrogation to the next, it is dynamic.
  • card specifications The details of an interrogation between a point-of-sale and a digital credential, card, SE representation, and mobile device are defined in "card specifications" and implemented in point-of-sale terminals. Examples of these card specifications at the time of this filing are MasterCard PayPass - Mag Stripe v3.3, Contactless EMV, Discover Network RF Contactless Specification - Supplement Guide For Functional Support, AMEX ALIS v1.7, and Visa Contactless Payment Specification v2.0.2. Used herein the term "card specification” refers to a specification or reference within the specification to other specifications and so on that a point-of-sale terminal must adhere to in order to interrogate a card, SE, mobile device as expected by that card specification.
  • a point-of-sale terminal controls the interrogation.
  • the card specification that defines the details of an interrogation may also define the details of a cryptogram request, calculation, and delivery from the card, SE, or mobile device to the point-of-sale as part of the interrogation sequence.
  • Card specifications may include references to other specifications and those other specifications to even more specification wherein the card specification may be defined by the card specification in conjunction with other supporting documents sited within a card specification.
  • Card specifications typically consist of an application layer that defines an interrogation sequence and calculations that are to be performed by both the card, SE, mobile device and also the interrogator or point-of-sale. Both a mobile device and a point-of-sale are expected to be operating under the direction of a card specification during an interrogation.
  • the card specification may define a cryptogram to be calculated by the card, SE or mobile device based, at least in part, on unpredictable data sent from the point-of-sale during the interrogation.
  • the cryptogram delivered by the mobile device is "expected" because the card specification indicates it will be calculated, at least in part, from the unpredictable data delivered by the point-of-sale during the interrogation and that is what the card specification expects.
  • the card specification may define a cryptogram to be calculated by the card, SE, or mobile device based, at least in part, on a cryptographic key, where the cryptographic key is a "permanent cryptographic key".
  • the cryptogram delivered by the mobile device is "expected” because the card specification indicates it will be calculated, at least in part, from a permanent cryptographic key and that is what the card specification expects.
  • permanent cryptographic key refers to a cryptographic key that is unchanging (or static) throughout the life of a card, SE, mobile device, or digital credential.
  • temporary cryptographic key refers to a cryptographic key that changes (or is dynamic) from one interrogation to the next over the life of a digital credential (e.g., an SE representation).
  • a temporary cryptographic key may be selected or changed randomly from its use in one interrogation to the next. It is unpredictable from one interrogation to the next.
  • a temporary cryptographic key may be recorded or stored in assigned to an individual transaction (interrogation) as shown in the "TEMP KEY" column 380 in the transaction table 210.
  • the term “cryptographic key” means a “permanent cryptographic key”.
  • encryption key means a "permanent cryptographic key”.
  • persistent or “persistently stored” refers to of data that are stored in a storage container (such as non-volatile read-only-memory) where the data "persists", and is not erased in the event of a power failure or outage to that storage container.
  • a persistent storage container is a hard drive, or flash memory.
  • transient used herein the terms “transient,” “transiently stored,” “non-persistent,” and “non-persistently stored” refers to data that are stored in a storage container where the are erased or otherwise rendered not accessible after a power failure to the storage container.
  • An example of a transient storage container is RAM (Random Access Memory).
  • Cryptograms used herein may be "expected” to be calculated, at least in part, from unpredictable data passed from a point-of-sale to a mobile device during an interrogation that is dictated by a card specification.
  • predetermined cryptogram refers to a cryptogram that is formulated without the use of unpredictable data passed from the point-of-sale terminal to a mobile device during an interrogation; wherein the interrogation is defined by a card specification; and the card specification indicates the cryptogram to be calculated, at least in part, by the unpredictable data. This may include a predetermined cryptogram being entirely made up of a string of random data. This may also include a predetermined cryptogram being calculated based on other unpredictable data instead of the unpredictable data from the point-of-sale. As used herein "predetermined cryptogram” also refers to a type of unexpected cryptogram.
  • Cryptograms used herein are many times may be "expected” to be calculated, at least in part, from a permanent cryptographic key that during an interrogation between a mobile device and a point-of-sale.
  • the term “unpredictable cryptogram” refers to a cryptogram calculated, at least in part, from a temporary cryptographic key for use in an interrogation between a mobile device and a point-of-sale; wherein the interrogation is defined by a card specification; and the card specification indicates a cryptogram to be calculated, at least in part, by a permanent cryptographic key.
  • unpredictable cryptogram also refers to a type of unexpected cryptogram.
  • the terms "unexpected cryptogram”, “unexpected predetermined cryptogram”, and “unexpected unpredictable cryptogram” refer to a cryptogram that is sent from a mobile device to a point-of-sale during an interrogation; wherein the interrogation is defined by a card specification implemented on the point-of-sale; and the cryptogram is calculated from a different calculation formula than is defined in the card specification.
  • the "different calculation formula” includes a predetermined cryptogram.
  • predetermined cryptogram refers to a cryptogram that is calculated without the use of unpredictable data passed from the point-of-sale terminal to a mobile device during an interrogation; wherein the interrogation is defined by a card specification; and the card specification indicates the cryptogram to be calculated, at least in part, by the unpredictable data.
  • a predetermined cryptogram may be entirely made up of a string of random data.
  • a predetermined cryptogram may also be calculated based on other unpredictable data instead of the unpredictable data from the point-of-sale.
  • predetermined cryptogram is an example of an unexpected cryptogram.
  • the "different calculation formula” includes an unpredictable cryptogram.
  • the term “unpredictable cryptogram” refers to a cryptogram calculated, at least in part, from a temporary cryptographic key instead of a permanent cryptographic key for use in an interrogation between a mobile device and a point-of-sale; wherein the interrogation is defined by a card specification; and the card specification indicates a cryptogram to be calculated, at least in part, by a permanent cryptographic key.
  • unpredictable cryptogram is an example of an unexpected cryptogram. An unexpected cryptogram can also be said to deviate from the card specification.
  • the "different calculation formula” may include using a temporary cryptographic key in place of a permanent cryptographic key in the case of an "unexpected unpredictable cryptogram", or may include using a random value in place of the cryptogram in the case of an "unexpected predetermined cryptogram”.
  • the value of the unexpected cryptogram may be different than that of an expected cryptogram; however, it is to be of the same general data format as the expected cryptogram. For example, if the expected cryptogram is 3 bytes long, then the unexpected cryptogram will be 3 bytes long, however the data within the respective cryptograms may not match.
  • the response for the compute cryptographic checksum command ( figure 3 , element 14), is created by a method employed in figures 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 and 30 called "Cryptogram Substitution" using a predetermined cryptogram or unpredictable cryptogram and in some embodiments sent for each transaction to the mobile device cache over a communication channel when requested by the mobile device. In other embodiments cryptogram substitution is used with unexpected cryptograms created on the mobile device and sent to a remote application system. For a MasterCard PayPass MSD v. 3.3 credential, table 3 shows a technical breakdown of how the data in the read compute cryptographic checksum response is formulated from data in the application system in proper APDU response BER-TLV format.
  • ATC 90 00 The ATC is the automated transaction counter that increments with every point-of-sale interrogation, and can be stored in the transaction table or credential table and updated with each interrogation by a mobile device.
  • the CVC3 is cryptogram that is expected to be calculated with this algorithm from the MasterCard PayPass MSD v3.3 card specification:
  • KDcvc3 cryptographic key is a permanent cryptographic key.
  • the permanent key of KDcvc3 is not used and is replaced by a temporary cryptographic key that may consist of a random value that changes, and may be erased or altered after a single interrogation.
  • the temporary cryptographic key that is used can be recorded in the application system transaction table for future reference during cryptogram verification. Proceding with the following formula using the termperary cryptographic key instead of the permanent cryptographic key will yield an unpredictable cryptogram.
  • the UN input value in this algorithm is intended (expected) to be an unpredictable number from the point-of-sale that was acquired during interrogation.
  • this UN number will be created randomly and used as input to the cryptogram algorithm.
  • the UN number used will be recorded in the application system transaction table for future reference during cryptogram verification.
  • the predetermined cryptogram can now be used to formulate a response to the "compute cryptographic checksum" request without consulting the application system during the interrogation.
  • the mobile device may share access to the predetermined cryptogram during the scope of the authorization process.
  • random data could simply be used to create the predetermined cryptogram.
  • the mobile device may share access to the predetermined cryptogram during the scope of the authorization process.
  • a temporary cryptographic key could be used to allow the mobile device to calculate and create the unpredictable cryptogram.
  • the temporary cryptographic key would be recorded in the application system transaction table for future reference during cryptogram verification.
  • the mobile device may share access to the temporary cryptographic key with the application system during the scope of the authorization process.
  • the application system could deliver the permanent cryptographic key to the mobile device to be stored transiently to allow the mobile device to calculate and create an expected cryptogram that can be used to formulate the "compute cryptographic checksum" response without consulting the application system.
  • a cache is a component that transparently stores data so that future requests for that data may be served faster.
  • the data that are stored within a cache may be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data are contained in the cache ("cache hit”), this request may be served by simply reading the local cache, which is comparatively faster that accessing the remote source. Otherwise (“cache miss”), the data have to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the more requests that may be served from the local cache, the faster will be the overall system performance.
  • non-persistent cache and “transient cache” refers to the cached data to be transient or non-persistent. Unless otherwise stated the term “cache” also refers to the cached data to be transient or non-persistent.
  • the mobile device cache is setup to hold the cached data in preparation for the next interrogation from the point-of-sale that will happen at a later time. It is important to note that the data transmitted to the mobile device cache may hold the literal APDU formatted data, or may simply hold the data required to formulate a correctly formatted APDU response. The important aspect is that the cache holds all the data required to properly create APDU responses to the APDU commands.
  • card data or “credential data” may refer to the data used to create a proper APDU response to credential specific APDU commands such "read record” 7, and data used in "compute cryptographic checksum” 8. It is common for an application system in a software representation of a plurality of remote secure element repository to have access to all the data to properly create a valid APDU response.
  • Fig. 16 illustrates a caching system for each transaction or interrogation between a point-of-sale 778 and a mobile device 779 for a MasterCard PayPass transaction.
  • the advantage of caching secure element responses is to lessen the effect of network latency and speed up an interrogation.
  • network latency is reduced from a potential 800ms to a potential 200ms because of the caching technique applied.
  • This is a significant effect in the application of NFC or RFID because the as the total interrogation timeframe shrinks, the likelihood of a successful interrogation sequence goes up because it is less likely the communication channel between the point-of-sale and the mobile device will be interrupted from the mobile device moving out of the field generated by the point-of-sale.
  • Not all interrogation command and responses 787 and 793 in Fig. 16 are handled from the mobile device cache 780. The non-cached command and response, lead to the 200ms network latency of the entire transaction in figure 16 .
  • Fig. 17 illustrates a caching system for each transaction or interrogation between a point-of-sale 794 and a mobile device 795 for a Visa PayWave transaction.
  • the concept of 100% transaction caching is employed. It illustrates how all of the responses for an interrogation from a point-of-sale may be cached at some point of time ahead 802 of the actual mobile device and point-of-sale interrogation. This causes network latency of the interrogation to be 0ms (zero) because no data is queried during the interrogation over the network from the remote system auth server's remote repository. This is a tremendous advantage over the system in Fig. 16 , which in-turn had a tremendous advantage to the system that does not employ transaction caching at all.
  • the point-of-sale may request a cryptogram and supply some data to be used in cryptogram calculation to the mobile device in the same APDU command request.
  • the APDU response to this request by the mobile device which is also in the same interrogation sequence, is expected to contain the cryptogram itself, calculated, at least in part, using the input data from the point-of-sale, and also other input data.
  • the point-of-sale After receiving the cryptogram in the APDU response from the mobile device, the point-of-sale then sends the cryptogram, the input data it used to request the cryptogram, and possibly other information about the credential data from the mobile device to a remote processor for an authorization request.
  • the cryptogram is verified based on the input data that was used to create it, some of which was generated by the point-of-sale.
  • the step of calculating the cryptogram requires the secure element at the time of interrogation because the secure element contains the permanent cryptographic key required to create the cryptogram. If the secure element is contained in a remote repository, network latency must be factored into the total interrogation time in order for the secure element to calculate the cryptogram using data from the point-of-sale.
  • the cryptogram can be calculated by the remote repository, transferred to the mobile device, and cached for use at a later time during point-of-sale interrogation. This scenario creates no network latency and allows for one hundred percent transaction caching during the interrogation, because the secure element representation need not be accessed during the actual interrogation time.
  • dCVV Visa Contactless MSD cryptogram
  • one hundred percent (100%) transaction caching refers to the ability for the mobile device to complete the interrogation with a point-of-sale terminal without the requirement to contact the secure element during the interrogation, and instead have all the data on hand local to the mobile device to complete the interrogation.
  • FIG. 22 illustrates how one embodiment of an application system could create cryptograms using random, predetermined, or "made up" input data.
  • a transaction table 210 is defined in which each row represents a transaction between a mobile device and a point-of-sale. The state of the data in this table currently shows transaction data that have been delivered to a mobile device cache, but have not been verified through a point-of-sale. In order to comply with the request of a point-of-sale to a mobile device during an interrogation, the mobile device must deliver cryptogram in the proper data format that the point-of-sale expects.
  • the data that is contained in the actual cryptogram that is delivered to the point-of-sale from the mobile device may not be accurately calculated with the input data from the point-of-sale, but it does not matter at this point as the point-of-sale alone does not verify the cryptogram, it simply receives the cryptogram and relays it for verification to the application system, which has access to the input data used to create the original pre-determined cryptogram.
  • the predetermined cryptogram 218 can may be calculated based on randomly selected terminal input data UN 213, and Transaction Data 215.
  • the other inputs to create the predetermined cryptogram are based on credential data of each secure element such as the Application Transaction Counter 214, the Issuer Master Key id 212, and the account Personal Account Number 211.
  • the application system After gathering all predetermined cryptogram input data, the application system sends the input to the HSM and receives the predetermined cryptogram as an output response.
  • the application system may optionally store the predetermined cryptogram 218 into the table 210, for use during verification later
  • the actual unpredictable number 216 and transaction data 217 sent by the point-of-sale terminal during interrogation is not known at this point in time because the interrogation has not actually happened yet.
  • This predetermined cryptogram is formatted properly, but will not be calculated based on the input data from the point-of-sale interrogation. Because it is formatted properly, it will still be accepted by the point-of-sale and sent to off for verification in an authorization request.
  • 219 shows two different rows representing two different transactions currently being processed for the same PAN 211.
  • the application system has the ability to process each of the transactions independently because there is a row in the table to discern each one separately.
  • predetermined cryptogram creation is simply make up a predetermined cryptogram from random data without performing a calculation from input data at all.
  • This embodiment requires the application system to store the random predetermined cryptogram 218 into the table 210 for verification later.
  • This embodiment also does not require an HSM to create the cryptogram as it is simply created randomly.
  • this embodiment it is possible to create a temporary cryptographic key for each transaction.
  • This key may be shared with the mobile device allowing the mobile device to calculate an unpredictable cryptogram using, at least in part, the unpredictable data received from the point-of-sale during the interrogation.
  • This embodiment requires the application system to store the temporary key 380 into table 210 for use during unpredictable cryptogram verification later.
  • the calculation time to create a predetermined cryptogram may also removed from the overall interrogation time. In the case of an unpredictable cryptogram, this calculation time persists and cannot be removed from the overall interrogation time.
  • Fig. 29 illustrates a representation of a table of digital credentials 350 (digital credential data) that may be stored inside the application system.
  • This table in conjunction with the transaction table, and in some embodiements the HSM allows the application system to perform as a repository of a plurality of secure element software representations.
  • the credential data used to create data inside an SE and also allow it to formulate its proper APDU responses is contained in this table for a plurality of credentials (SEs).
  • Fig. 23 illustrates a method for a mobile device 220 to request a transaction cache 224 prior to being interrogated by a point-of-sale.
  • transaction cache refers to data required to formulate proper mobile device responses during an interrogation with a point-of-sale, which may comprise digital credential data.
  • figure 23 is very similar and describes a method for a mobile device 220 to receive a cache of transaction data (transaction cache) 227 over a communication channel to be used during a point-of-sale interrogation at a later point in time.
  • the mobile device Before an interrogation with a point-of-sale, the mobile device will request a transaction cache to be used during the point-of-sale interrogation from the application system 222 over a communication channel.
  • This transaction cache data may comprise the randomly generated unpredictable data such as UN and transaction data from the application system, the other credential based inputs 225 to cryptogram calculation and sends them to the HSM 223 over a communication channel.
  • the HSM then may calculate the predetermined cryptogram 226 and return it to the application system.
  • the predetermined cryptogram may then be used to formulate the cache response to a "request cryptogram" APDU command from a point-of-sale.
  • the application system could avoid the step of contacting the HSM and simply make up a random sequence of bytes to be used as a predetermined cryptogram to be used in place of the expected cryptogram.
  • This predetermined cryptogram is a sequence of random data and is shared with the mobile device, so the mobile device could have, just as well, created the random bytes as the predetermined cryptogram and shared them with the application system.
  • the application system could avoid the step of contacting the HSM and simply make up a temporary cryptographic key from a random sequence of bytes to be shared with and used by the mobile device while creating an unpredictable cryptogram to be used in place of the expected cryptogram.
  • This temporary cryptographic key is a sequence of random data and is shared with the mobile device, so the mobile device could have, just as well, created the random bytes as the temporary cryptographic key and shared them with the application system.
  • the MasterCard PayPass interrogation from the point of sale incorporates an APDU command request called "compute cryptographic checksum" 14 as seen in figure 3 .
  • the command APDU follows a particular format and may look like this: 80 2A 8E 80 04 00 00 08 99 00
  • the digits 00 00 08 99 in the APDU command above from the point-of-sale indicate the unpredictable number to be used as an expected cryptogram calculation input. This unpredictable number is a random sequence of numbers that changes with each interrogation the point-of-sale initiates.
  • the format of this APDU command request is discussed in more detail inside the MasterCard PayPass MSD v3.3 card specification.
  • the immediate APDU response from the mobile device is expected to follow a particular format and may look like this: 77 0F 9F 61 02 B8 92 9F 60 02 FB C7 9F 36 02 00 5E 90 00
  • the digits B8 92 represent the cryptogram. It is identified by the preceding BER-TLV formatted tag 9F 61 (track 2 CVC3), and length value of 02. It was expected to have been calculated from the unpredictable number issued by the preceding point-of-sale APDU command request in combination with other inputs such as the ATC. A correct expected cryptogram must be calculated using the permanent cryptographic key that is securely stored inside the SE. Because figure 23 implements 100% transaction caching, it is not impossible for the expected cryptogram to be calculated after receiving the unpredictable number from the point-of-sale, because in that event, the mobile device would need to access the network to contact the remote repository as in figure 16 , elements 787 and 793 in order to perform the expected cryptogram calculation.
  • the method of substituting a predetermining a cryptogram, or an unpredictable cryptogram in place of the expected cryptogram, in this case, needs to be applied in order to create this response.
  • the "compute cryptographic checksum" response from the mobile device can be successfully delivered interrogation with the point-of-sale without contacting the remote SE representation during the interrogation.
  • the cached response may look like this instead: 77 0F 9F 61 02 A4 56 9F 60 02 FB C7 9F 36 02 00 5E 90 00
  • the digits A4 56 is the predetermined cryptogram, and NOT calculated using, at least in part, the expected unpredictable number from point-of-sale.
  • the digits A4 56 is the unpredictable cryptogram, and NOT calculated, at least in part, using the expected permanent cryptographic key rather using a temporary cryptographic. This is an example of "Cryptogram Substitution" technique.
  • the point-of-sale does not have the means or keys to check the received cryptogram for correctness, so it will accept the cryptogram answer because it is of the proper format. The point-of-sale will rely on the authorization request later to verify the correctness of the cryptogram.
  • the entire transaction cache data comprising elements that make up the response to "compute cryptographic checksum" 227 may be returned to the mobile device from the application system over a communication channel prior to point-of-sale interrogation.
  • the transaction cache can be used during interrogation from a point-of-sale to successfully cache the responses to 100% of the interrogation requests without requiring network access to the remote repository and SE during the complete interrogation time.
  • the data supplied in the transaction cache response 227 may be literally APDU formatted responses. It may also simply contain all the data required to formulate proper APDU responses without requesting more information from the application system during interrogation time. In this case the mobile device must employ some logic to properly formulate the APDU responses. This logic may also be delivered with transaction cache data 227.
  • the point-of-sale may request one of a plurality of cryptograms.
  • the response to more than one cryptogram type request must be delivered in the transaction cache response 227 over a communication channel.
  • the mobile device must employ some logic as to which cryptogram response is being requested and direct the mobile device cache appropriately to deliver the correct cryptogram response. This logic may also be delivered with transaction cache data 227.
  • card risk management is described by the card having enough logic and information about the transaction at the point-of-sale to approve or decline the transaction without consulting an application system or remote processing server.
  • An example of performing card risk management logic using unpredictable data is:
  • Element 227 in addition to delivering transaction cache information, may also contain logic and data to make decisions regarding card risk management during the interrogation with the point-of-sale.
  • Element 227 although it may be less secure, in another embodiment could contain the permanent cryptographic key that is used to create an expected cryptogram.
  • Element 227 in a further embodiment could contain a temporary cryptographic key that is used to create an unpredictable cryptogram.
  • Element 227 could also contain data required to be used with the encryption key to create the cryptogram such as ATC. This would allow the mobile device to create a cryptogram without consulting the application system and effectively cache a response to a cryptogram request from a point-of-sale during an interrogation. Sharing the permanent cryptographic key with the mobile device would be an alternative to using a predetermined cryptogram to achieve a similar system performance result with the context of 100% transaction caching. Also sharing a temporary cryptographic key with the mobile device wherein the mobile device calculates an unpredictable cryptogram would be an alternative to using a predetermined cryptogram to achieve a similar system performance result with the context of 100% transaction caching.
  • the verification of correctness method that pertains to the mobile device calculated cryptogram and unpredictable cryptogram compared to a predetermined cryptogram may be different as the mobile device may use the unpredictable data passed from the point-of-sale in the cryptogram calculation.
  • the mobile device may store the transaction cache data and card risk management logic securely in a mobile device cache 221 which can be non-persistent memory or RAM, or possibly encrypted memory.
  • Fig. 24 illustrates an interrogation between a point of sale 230 and mobile device 231 sometime after the mobile device has received the mobile device cache data 227 from the application system 222.
  • This interrogation may be carried out over near field communication (NFC) on both the point-of-sale and mobile device.
  • the data protocol layer within this interrogation may be configured for IS07816-4 and follow APDU command and response formats.
  • Figure 24 is very similar to the lower half of figure 16 , with the exception of cryptogram request 239 and response 241 on figure 24 and 787 and 792 of figure 16 .
  • the APDU response in figure 24 , element 241 is formulated as a response from the mobile device using the mobile device cache 232 and contains a predetermined cryptogram or an unpredictable cryptogram.
  • Both unpredictable number (UN) and transaction data from the point-of-sale terminal passed to the mobile device 239 are not actively used to create the predetermined cryptogram response 241, however, they are used to create an unpredictable cryptogram response. They are both kept by the mobile device 240 to be transmitted to the application system later over a communication channel. If there are card risk management tests to be performed to determine which predetermined cryptogram or unpredictable cryptogram response 241 is used, they are performed by the mobile device at this time 242.
  • the interrogation sequence from the point-of-sale may contain additional requests such as select payment card application 233, which is followed by a response 234 from the mobile device cache, GPO request 235, which is followed by a response 236 from the mobile device cache, and read record request 237, which is followed by a response 238 from the mobile device cache.
  • Fig. 25 illustrates an authorization request after an interrogation between a mobile device and a point-of-sale has been preformed, such as in fig. 24 .
  • the point-of-sale 255 will formulate an authorization request which may be in the form of IS08583 format.
  • This format will contain data that pertains to the interrogation such as the cryptogram received from the mobile device, the unpredictable number and transaction data passed to the mobile device for cryptogram calculation, and other credential data.
  • the authorization request will be passed to the application system 251 over a communication channel 252.
  • This communication channel may not go directly to the application system, but may go first to an acquiring gateway, then to an issuing processor, and eventually to the application system 251.
  • This communication channel may be referred to herein as "the interchange”.
  • the interchange is a private network that is used exclusively by the payment card industry for the purpose of authorization requests.
  • the authorization request may be matched to a particular transaction that is listed in the transaction table 210 based on the PAN 211 that is listed in the credential data of the authorization request.
  • the application system will make the authorization decision for the authorization request.
  • the application system has access to the HSM 250 as well as the transaction table 253 that is also shown in figure 22 , element 210. It may contain the original randomly created UN 213 and transaction data 215 used to create the predetermined cryptogram. It may contain the predetermined cryptogram. It may also contain a temporary cryptographic key that allows the mobile device to create an unpredictable cryptogram.
  • the cryptogram that was received over the interchange communication channel 252 may be a predetermined cryptogram that may have been originally delivered to the mobile device in the response to a request for transaction cache data ( figure 23 , element 227).
  • the cryptogram that was received over the interchange communication channel 252 may also be an unpredictable cryptogram that was created by the mobile device using a temporary cryptographic key.
  • the mobile device 256 In parallel to the data being sent from the point-of-sale to the application system, the mobile device 256, after the interrogation, sends the unpredictable number and transaction data it received from the point-of-sale terminal, the results from the card risk management tests over a separate communication channel 254 to the application system.
  • This separate communication channel may be internet communication over a mobile network.
  • This data from the mobile device was acquired from the point-of-sale and kept by the mobile device as shown in figure 24 , elements 240 and 242, but may not have been used in the calculation of the cryptogram passed in figure 24 element 241.
  • This data which is sent to the application system by the mobile device 254 may be used to compare and corroboratively verify unpredictable number and transaction data that was separately sent by the point-of-sale 252.
  • the unpredictable number and transaction data reported from the point-of-sale should match the reported unpredictable number and transaction data from the mobile device.
  • corroboratively herein refers to verifying unpredictable data delivered by two separate communication channels.
  • An added security measure may be implemented that pertains to the data sent from the mobile device to the application system over the communication channel 254. Prior to sending the data, if the data contains transactional amount data for example: "$16.24 USD", that data may be presented to the mobile device display screen 371 from for card holder validation like this:
  • Fig. 26 illustrates the transaction table 262 that is also shown in figure 25 , element 253 and figure 22 , element 210.
  • the state of the transaction table in figure 26 represents that of after a transaction interrogation has been preformed and after the application system has received data from the mobile device as in figure 25 , element 254.
  • the example of the data received is shown for the unpredictable number from the terminal 260 and the transaction data 261. Both of these numbers may be used to verify an authorization request shown in figure 25 , element 252, as they could be compared and match that of the authorization request. These numbers also may be used as placeholders to identify that a system authorization is complete.
  • Fig. 27 illustrates how the application system 270 may make an authorization decision regarding a particular transaction such as that listed in figure 26 .
  • a method of verifying a predetermined cryptogram 278 is shown.
  • the data from a row in the transaction list table 262 in figure 26 which matches element 272 in figure 27 , in addition to the cryptogram and PAN passed to the application system 271 by the point-of-sale over a communication channel, may be used to create the input to the "verify cryptogram" request 273.
  • the HSM 275 may then use a particular key that is kept securely inside it to calculate a cryptogram based on the algorithm supplied by the applicable card specification and see if it matches the one passed in 273.
  • the values in 276 can be ignored for the cryptogram verification process and substituted with the application system values.
  • the emphasis about this figure and how it relates to the verification of a cryptogram is that the input data, at least in part, to the cryptogram verification is NOT the unpredictable number and transaction data passed from the point-of-sale 276 over a communication channel, but instead the randomly generated values that were previously selected and stored in a transaction table are used 272.
  • the unpredictable number and transaction data that was generated by the point-of-sale terminal 276 is never actively used to create or verify the cryptogram, but may be used to match with a reported response from the mobile device 277 after the interrogation as an additional verification method.
  • the application system may verify a cryptogram by simply comparing the cryptogram received from the point-of-sale with a reference to a predetermined cryptogram that is kept in the application system.
  • a method of verifying an unpredictable cryptogram 279 is shown.
  • the application system would verify the cryptogram from the point-of-sale using the temporary cryptographic key that was assigned to the transaction as seen in table 210, element 380.
  • the temporary key was used by the mobile device to create the unpredictable cryptogram that was sent from the point-of-sale.
  • the inputs for the calculation 391 comprise data from the application system 390 and inputs from the point-of-sale 393.
  • the inputs from the application system may comprise a temporary cryptographic key, and an application transaction counter.
  • the inputs from the point-of-sale may comprise a cryptogram, a PAN, a UN, a transaction data.
  • the application system may then follow the expected algorithm supplied in the card specification for verifying an expected cryptogram with the exception of substituting the expected permanent cryptographic key with the temporary cryptographic key. Notice in this embodiment a permanent cryptographic key is never used for cryptogram verification. Notice the UN and transactional data from the mobile device 392 may not be used for cryptogram verification.
  • Fig. 28 illustrates an overview of the authorization of a transaction process comprising a method for substituting an expected cryptogram with a predetermined cryptogram or unpredictable cryptogram.
  • Fig. 28 also illustrates an overview of the authorization of a transaction process comprising a method of authorization using an expected cryptogram.
  • Fig. 28 employs the concept of the mobile device without having local access to a permanent cryptographic key that is expected to be used to create an expected cryptogram.
  • Fig. 21 , 22 , 23 , 24 , 25 , 26 , 27 , 29, and 30 all have a part of this process.
  • Fig. 21 illustrates a repository of a plurality of secure element software representations.
  • Fig. 22 , 23 and 29 illustrate how the mobile device shares data with an application system over a communication channel.
  • Fig. 24 illustrates interrogation between a point-of-sale and mobile device.
  • Fig. 25 , 26 and 27 illustrate the authorization process after an interrogation is completed.
  • Fig. 30 illustrates a mobile device that comprises one embodiment of corroborative authorization that displays the transaction amount data for manual verification by a card holder.
  • a mobile device first requests transaction cache information from an application system 280 over a communication channel.
  • the application system may have created or creates at that time random data such as unpredictable number and transaction data that is required to calculate a predetermined cryptogram 281.
  • This random data is similar in format to that of which the point-of-sale would generate at the time of interrogation with the mobile device.
  • the application system keeps this data for later, and shares a predetermined cryptogram with the mobile device 282.
  • one embodiment may comprise the application system and the mobile device simply sharing a random sequence of data that represents a predetermined cryptogram. This is possible because the application system is the only entity that both creates and verifies the predetermined cryptogram.
  • a further embodiment may comprise the application system and mobile device sharing a temporary cryptographic key that the mobile devices will use to create an unpredictable cryptogram.
  • a further embodiment although less secure, comprises the application system sending the permanent cryptographic key needed to create an expected cryptogram to the mobile device to be stored transiently; the mobile device would then have the capability to calculate the expected cryptogram locally when receiving a request for an expected cryptogram from the point-of-sale.
  • Data may be delivered to the mobile device 283 that comprises, for example, card risk management logic, information needed to respond to "select AID”, “get processing options”, “read record”, and “compute cryptographic checksum” APDU requests during interrogation 282.
  • the mobile device receives the transaction caching data information over a communication channel and keeps it for use in the next point-of-sale interrogation 283.
  • sending data from one entity to another such as a mobile device to a remote application system or vise versa should be taken to mean sending the data from one location to another wherein the receiving entity may receive the data as a duplicate from the sending entity or receive the data in parts in addition to receiving information about the data that would enable the receiving entity to reconstruct the original data that was sent from the sending entity.
  • a point-of-sale performs an interrogation 284 with the mobile device, the mobile device has a cache prepared to answer the point-of-sale APDU requests over its NFC interface. As part of the interrogation, the mobile device receives a request to calculate an expected cryptogram using, at least in part, the unpredictable data sent by the point-of-sale such as an unpredictable number and transaction data.
  • the mobile device saves, but does not use this unpredictable data from the point-of-sale 290, and instead delivers a response APDU that contains the predetermined cryptogram that is in the mobile device cache 291.
  • the interrogation is completed.
  • element 399 is not used.
  • the mobile device creates an unpredictable cryptogram calculated from a temporary cryptographic key and, at least in part, the unpredictable data from the point-of-sale 399.
  • elements 290 and 291 are not used.
  • the mobile device creates an expected cryptogram calculation from a permanent cryptographic key transiently stored on the mobile device; and, at least in part, the unpredictable data from the point-of-sale.
  • elements 290, 291, and 399 are not used.
  • the point-of-sale sends data it had acquired from the mobile device during the interrogation, such as the expected cryptogram, predetermined cryptogram or unpredictable cryptogram, and ATC, in addition to details about the transaction to the application system over a communication channel 285; and the mobile device sends, over a separate communication channel, information it had acquired from the interrogation with the point-of-sale such as unpredictable number and transaction data to the application system 286.
  • transactional data such as transactional dollar amount is delivered to the mobile device from the point-of-sale during the interrogation.
  • the card holder that is using the mobile device may be asked to verify a purchase amount displayed on the mobile device display screen 371 prior to the mobile device sending the data to the application system over the seperate communication channel.
  • the application system then uses the data from the point-of-sale, and optionally from the mobile device, to verify and authorize the transaction 287.
  • the application system may identify a particular transaction from a transaction table 210 as a transaction using a predetermined cryptogram, unpredictable cryptogram, or an expected cryptogram and proceed with the appropriate verification technique.
  • the application system may have to compare the unpredictable data sent from the point-of-sale and the unpredictable data sent from the mobile device to corroborate the transaction as an added corroborative verification method 289.
  • the application system may verify the predetermined cryptogram with an HSM by using the previously randomly selected unpredictable number 213 and transaction data 215 as part of the input data as a substitute for the unpredictable number and transaction data sent to the application system by the point-of-sale.
  • the verification process could be a simple comparison between the predetermined cryptogram delivered to the mobile device ( figure 23 , elements 226, 227) and the predetermined cryptogram received from the point-of-sale ( figure 25 , element 252).
  • the verification process could be verification of an unpredictable cryptogram using a temporary cryptographic key assigned to the transaction in the transaction table to calculate and verify the unpredictable crytptogram.
  • the verification process is the verification of an expected cryptogram using an HSM that contains a permanent cryptographic key.
  • Fig. 30 illustrates a mobile device.
  • the mobile device screen 371 is contained within the body of the mobile device 370 and can be configured to display text or graphics.
  • An input button 372 to the mobile device can be used to manually submit input to the mobile device.
  • Figures 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29, 30 comprise the method of cryptogram substitution where an expected cryptogram is substituted by either a predetermined cryptogram or an unpredictable cryptogram.
  • the method using an application system that may contain an HSM as a repository for software secure element representations. It is important to note that a cryptogram in these figures may be calculated by using a HSM that securely houses keys used to create a cryptogram. Because the application system, however, is the only entity trusted to both create and verify the cryptogram, the cryptogram that is substituted could effectively be made up of completely random data without the use of an HSM, or created from a temporary cryptographic key assigned to each transaction.
  • interrogation refers to all the APDU command requests and APDU responses between a mobile device and a point-of-sale using RFID (NFC) required to deliver a complete credential for authorizing a financial transaction to a point-of-sale as defined by a card specification.
  • NFC RFID
  • an NFC interrogation does not span multiple NFC field entrances and exits.
  • the beginning of an interrogation starts when a mobile device enters the NFC field of a point-of-sale and ends at least prior to when the mobile device exits the NFC field.
  • An interrogation sequence is can be entirely defined by a card specification and an interrogation is expected to gather all the digital credential data required from the mobile device in order to authorize a financial transaction.
  • the timing of an interrogation or interrogation sequence may also be defined by a card specification. As used herein an interrogation ad heirs to the timing requirement that indicates a maximum interrogation time as specified in the card specification. Maximum interrogation time the time required to complete the entire interrogation. If the card specification does not contain timing requirements that define a maximum interrogation time, the maximum interrogation time is one second as used herein.
  • a "fast interrogation" as used herein refers to an interrogation wherein the maximum interrogation time is to be less than 250 milliseconds.
  • a "super fast interrogation” as used herein refers to an interrogation wherein the maximum interrogation time is to be less than 150ms.
  • An “ultra fast interrogation” as used herein refers to an interrogation wherein the maximum interrogation time is to be less than 100ms.
  • An “efficient interrogation” as used herein refers to an interrogation wherein the total interrogation time does not comprise system latency time, wherein system latency time is incurred by sending or receiving data to or from a remote source from a mobile device during the interrogation.
  • transaction as in "100% transaction caching" and other uses, based on context, may be used as a synonym for interrogation or interrogation sequence. Examples of an interrogation and interrogation data are shown in figures 1 , 2 , and 3 .
  • An interrogation can be considered time sensitive as the likely hood of a successful interrogation sequence greatly increases the shorter it is. This is a property of proximate nature of NFC. It is simply hard to "hover" a mobile device in an NFC field for any long length of time.
  • FIG. 28 elements 285, 286, 287, 288, and 289. This is the process following the interrogation of authorizing the transaction. In a retail environment, this is expected to take less than 15 seconds and require little or no manual input from the time just after interrogation step to a receipt of an authorization response from the application system.
  • completed authorization refers to the part of the method for authorization following that starts when the interrogation step is complete and stopping when the point-of-sale receives an authorization response from the application system.
  • fast completed authorization step refers to a completed authorization with a maximum duration time of 15 seconds.
  • the term “super fast completed authorization” refers to a completed authorization with a maximum duration time of 5 seconds.
  • the term “authorization step requiring no manual input” refers to a completed authorization that contains no requirement for manual input to the mobile device by a card holder.
  • the method of Cryptogram Substitution is only possible in the event there is a channel to share a predetermined cryptogram or unpredictable cryptogram between the application system and the mobile device. Because of this channel for delivery, there is never a need for a permanent cryptographic key to be persistently stored local to the mobile device. Persistent storage of a permanent cryptographic key in a second location remote from the application system, as in the typical scenario of distributed secure elements inside plastic cards, is no longer a requirement in the event there is an active communication channel between a mobile device and the remote application system.
  • the SE on the plastic card must create an expected cryptogram independent of the remote application system, because it has no channel to receive the digital credential data.
  • the remote application system is then used to verify the expected cryptogram by the SE after each interrogation. This means the SE and the remote authentication server must both possess a copy of the permanent cryptographic key that generates the expected cryptogram.
  • various embodiments describe methods for performing a timely authorization of digital credential data delivered from a mobile device that is without access to a local persistently stored permanent cryptographic key; through an interrogation with a point-of-sale that behaves according to the direction of a card specification.
  • the card specification expects the mobile device to create a cryptogram that is calculated, at least in part, using a permanent cryptographic key and, at least in part, from unpredictable data delivered from the point-of-sale to the mobile device during the interrogation.
  • a mobile device may be without power in which case the local permanent cryptographic key would need to be stored persistently in order to function properly in the system when power is restored.
  • a further consideration is that a mobile device, or an application running in the operating system of that mobile device, may have no means to persistently store the permanent cryptographic key locally based on the requirements set forth by the card specification and based on the resources available to the mobile device or application on the mobile device.
  • the card specification requirements may dictate that the mobile device, or application running in the operating system of that mobile device, is too hostile and vulnerable, based on various criteria, to be qualified to persistently store the permanent cryptographic key in the operating system.
  • the mobile device or the application running in the operating system of the mobile device may not have local access to the persistently stored cryptographic key in an embedded SE or embedded secure storage, or any other secure local storage container.
  • point-of-sale As used herein the terms “point-of-sale”, “POS”, and “point-of-sale terminal” are synonyms and include, for example, terminals that are installed at merchant checkout counters, automated teller machines (ATMs), self-serve facilities (such as gasoline pumps), and similar service stations where financial transactions are authorized, and the terms also include computers that accept payment card data for authorizing financial transactions.
  • POS terminals may accept payment card data in a plurality of ways including magnetic stripe reading, NFC reading, IS078161-3 contact card reading, manual typing of card data, etc.
  • point-of-sale POS
  • point-of-sale terminal are limited to a point-of-sale that behaves according to the direction of a card specifications during an interrogation with a mobile device such that the point-of-sale controls the interrogation through sending commands to the mobile device and receiving responses from a mobile device.
  • mobile device refers to an electronic communication device having a weight of less than 2 pounds (0.907 kg).
  • mobile devices are cell phones, smart phones, personal digital assistants (PDAs), electronic book readers and tablet computers, provided that the device weighs less than 2 pounds (0.907 kg).
  • PDAs personal digital assistants
  • tablet computers provided that the device weighs less than 2 pounds (0.907 kg).
  • a mobile device does not access a local persistently stored permanent cryptographic key
  • a reference may include a mobile device that comprises an operating system, with an application that runs in that operating system, such that the application does not have access to a local persistently stored permanent cryptographic key; and/or such that that local persistently stored permanent cryptographic key is expected to be used to calculate an expected cryptogram, and/or such that the expected cryptogram is expected to be contained within at least a portion of the digital credential data sent to the point-of-sale during an interrogation; and/or such that the process is under the direction of the application.
  • NFC emulating mobile device is a mobile device that comprises an operating system, with an application that runs in that operating system, wherein the application has the capability of being interrogated by a point-of-sale in the role of a card, SE, or mobile device as that capability is defined in a card specification.
  • secure mobile device is a mobile device that has access to a local persistently stored permanent cryptographic key; wherein that local persistently stored permanent cryptographic key is expected to be used to calculate the expected cryptogram, wherein the expected cryptogram is expected to be contained within at least a portion of the digital credential data.
  • a cryptogram may be computed with unpredictable input data such as an unpredictable number (UN) and transaction data such as a transaction amount that is created un-predictably by a point-of-sale terminal. Even though a transaction amount may seem deterministic, it is unpredictable to the authorization system and considered unpredictable data. As used herein, this "unpredictable input data" that is used as input to a cryptogram calculation may for example be an unpredictable number, terminal input data, unpredictable terminal input data, transaction data, a transaction amount, or some other unpredictable data such as a random number, or combinations thereof.
  • the point-of-sale typically has no means to verify the expected cryptogram it received was actually calculated, at least in part or if at all, by the unpredictable data that it had delivered, or that the expected cryptogram it receives was actually calculated, at least in part or if at all, by the expected permanent cryptographic key.
  • the mobile device may typically substitute the "expected" cryptogram with an "unexpected cryptogram" without detection of the substitution by the point-of-sale.
  • the point-of-sale may request an authorization based on data, including the unexpected cryptogram that was received during the interrogation.
  • This data is sent to an authorization authority (application system) for verification and authorization.
  • the authorization authority is assumed to have access to the credential data, including cryptogram calculation keys, automated transaction counter, etc. that are linked to the credential data delivered by the card, SE or mobile device during the interrogation. If the authorizing authority is aware of the substitution and also has access to the unexpected cryptogram itself, or the unpredictable data that may have been used, at least in part, to create it, or the temporary cryptographic key that may have been used, at least in part, to create it, then the authorization authority may successfully verify the correctness of the cryptogram. This may happen either through a simple comparison of the cryptogram delivered by the point-of-sale with the unexpected cryptogram reference in the application system, or by performing correctness verification of the cryptogram delivered by the point-of-sale by re-calculating it.
  • Figure 23 discusses the idea of a mobile device requesting cache data to be used in a future interrogation with a point-of-sale.
  • Element 227 indicates the passing of this data from the remote source of the application system to the local source of the mobile device for caching.
  • the data contained in element 227 are data required to respond to a point-of-sale during an interrogation. This could include a predetermined cryptogram.
  • this cache data may also include the permanent cryptographic key, in addition with other required data, to calculate an expected cryptogram locally on the mobile device when an expected cryptogram is requested.
  • the cache data may also include a temporary cryptographic key, in addition with other required data, to calculate an unpredictable cryptogram locally on the mobile device.
  • the application system has access to the cryptogram key, and additional data used to calculate a cryptogram, so it has the ability to calculate a cryptogram or simply pass the encryption key to the mobile device with supporting calculation data, and allow the mobile device to calculate the cryptogram during an interrogation.
  • the application server and mobile device can be said to share information if the data at any point in time is sent from one entity to another.
  • unpredictable data that are used to create a predetermined cryptogram may be created by the application system and share that data with the mobile device. It is entirely possible that the mobile device creates the unpredictable data and sends it to the application system. Similarly, in another example it is possible that the mobile device creates a predetermined cryptogram made exclusively from random data and sends the predetermined cryptogram to the application system instead of the application system sending the predetermined cryptogram to the mobile device. Similarly, in another example it is possible that the mobile device creates a temporary cryptographic key that is used to create an unpredictable cryptogram and sends it to the application system instead of the inverse.
  • an application running on an operating system in a mobile device may not have access to a local persistently stored cryptographic key. Consequently it may be said that the mobile device does not have a permanent cryptographic key for use to create an expected cryptogram to be sent to the application system because the permanent cryptographic key is expected to be persistent for the life of the card, and this implies that the mobile device has the means to access the permanent cryptographic key for use during the life of the card which needs to persist through mobile device power cycles.; Inversely, however, it is possible for an application system to create the permanent cryptographic key, store it persistently, and send it to the mobile device to be stored transiently.
  • NFC payment transactions may be made secure by using disclosed data connection methods because the security of the transaction is based largely on the data content itself.
  • Each transactional request that is passed through the interrogation phase of the reader and card yields Track1/Track2 equivalent data that change with every subsequent transaction, offering a single credential for each and every transaction.
  • the data content itself is shared-key-based data that may be, with virtually 100% certainty, verified that it was received from a specific card holder secure element. Because of this, the security of the data pipeline that actively transports the data are less important and may actually be considered a non-factor for the security of the financial transaction.
  • a specific payment standard issued from MASTERCARD International This standard is based on reference documentation published by PayPass - Mag Stripe (V3.3).pdf and other derivations.
  • PayPass contactless payment card reader and card interrogation is documented. This document discusses specifically how an RFID reader interrogator would interact with a card containing a SE to extract and build Track1/Track2 equivalent data that is compatible for existing processing infrastructure, but contains the more secure and dynamic aspects of SE driven credential data.
  • provisions are made for managing a remote system containing of a plurality of SE readers, each one being addressable and matched to a particular mobile device.
  • provisions are made for authenticating and validating a mobile device with a remote system to obtain access to a particular SE within a plurality of SEs in that remote system.
  • provisions are made for connecting a mobile device to a remote service via activating a data-pass-through mode for IS07816-4 data commands from an POS RFID reader through a mobile device NFC interface through the mobile device OS, to a data connection to a remote system containing a plurality SEs.
  • provisions are made for using TCP/UDP/IP sockets to enable a communication channel between a RFID POS reader and a single SE within remote system containing a plurality of SEs.
  • provisions are made for authenticating over SSL to enable a TCP/UDP/IP socket communication channel between a RFID POS reader and a single SE within a remote system containing a plurality of SEs.
  • provisions are made for one hundred percent transaction caching. These are methods and configurations that allow a mobile device to request a cache from the remote authentication system, where the cache request response encompasses data that can be used to create APDU responses to an entire point-of-sale interrogation sequence that may happen in the future.
  • This cache may be stored securely in non-persistent memory (RAM) in the mobile device and used at the time of interrogation with the RFID (NFC) point-of-sale reader.
  • RAM non-persistent memory
  • some embodiments may allow a mobile device and an RFID (NFC) point-of-sale reader to interact exclusively with each other at the time of transaction (interrogation) without performing a remote request, which would result in a network delay, using data stored in the mobile device cache.
  • NFC RFID
  • provisions are made for substituting a properly formatted predetermined cryptogram that was created without using unpredictable data, at all, from the point-of-sale in place of actively creating and using an expected cryptogram that was created using data, at least in part, from a point-of-sale during an NFC interrogation sequence between a point-of-sale and a mobile device.
  • provisions are made for substituting a properly formatted unpredictable cryptogram that was created using a temporary key in place of an expected cryptogram that was created with a permanent cryptographic key.
  • Cryptogram substitution builds on the advantages by transaction caching because a predetermined cryptogram or unpredictable cryptogram allows for the caching of data on a mobile device that may be used to create a response to a cryptogram request; where the cryptogram request from the point-of-sale expects the cryptogram response to use, at least in part, unpredictable data from the point-of-sale, and a permanent cryptographic key, at least in part, to create an expected cryptogram. Substituting a predetermined cryptogram or unpredictable cryptogram as the data to be used in the expected cryptogram response removes the requirement to use network resources that incur the effect of network latency time while contacting the remote secure element representation to perform the cryptogram calculation.
  • the predetermined cryptogram or unpredictable cryptogram may be delivered to the point-of-sale instead, in this manner, as a "cache hit.”
  • the secure element When the secure element is said to be remote, it indicates that there is no access to a locally stored permanent cryptographic key to be used in an expected cryptogram calculation.
  • provisions are made for a remote source to deliver a permanent cryptographic key, along with any other required data, that are used to create an expected cryptogram in a mobile device.
  • a remote source to deliver a permanent cryptographic key, along with any other required data, that are used to create an expected cryptogram in a mobile device.
  • the concept of 100% transaction caching can also be achieved with this embodiment as all of the elements to create an expected cryptogram are now located in the local cache and the mobile device need not access the remote source during the cryptogram calculation phase of the interrogation.
  • the mobile device has access to transactional data information such as transactional amount that it acquired during an interrogation with a point-of-sale.
  • This transactional amount may be used as a second verification method to the mobile device user, or card holder.
  • the mobile device may display this amount with a verification request to the mobile device screen.
  • the application system may use this input in the authorization decision.
  • Advantages to this added verification method is related to added security and confirmation of transaction amount to be authorized. This method further confirms that the user knows the dollar amount that is to be authorized during a financial transaction.
  • Various embodiments provide a software representation of a SE.
  • the advantages of such embodiments include replacing a concept that may commonly perceived as a hardware solution with a software solution that saves in cost as well as space requirements.
  • some embodiments use the base-band processor in the mobile device to do one or all of the following tasks:
  • Some embodiments disclosed herein use a remote server network and remote array of secure elements or representations of secure elements (remote system) to do one or all of the following tasks:
  • Some embodiments disclosed herein combine both the tasks performed by the NFC mobile device and the remote system to allow for a complete and un-interrupted interrogation between a RFID POS reader or remote terminal and an NFC mobile device.
  • the interrogation may be performed as set forth by payment card standards such as MASTERCARD PayPass, VISA Contactless, AMEX Express Pay, DISCOVER Zip, and contactless EMV.
  • the data link or data connection and communication between the mobile device and the remote system or remote terminal stated above may be carried out over standard TCP/UDP/IP services that are currently available on mobile devices.
EP21198983.5A 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu Pending EP3996019A1 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201161575846P 2011-08-30 2011-08-30
US201161573476P 2011-09-06 2011-09-06
US201261685863P 2012-03-26 2012-03-26
US13/491,922 US20120317628A1 (en) 2011-06-09 2012-06-08 Systems and methods for authorizing a transaction
EP19199694.1A EP3754577A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu
PCT/US2012/053129 WO2013033388A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés destinés à autoriser une transaction avec un cryptogramme inattendu
EP12827026.1A EP2751754A4 (fr) 2011-08-30 2012-08-30 Systèmes et procédés destinés à autoriser une transaction avec un cryptogramme inattendu

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
EP19199694.1A Division EP3754577A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu
EP12827026.1A Division EP2751754A4 (fr) 2011-08-30 2012-08-30 Systèmes et procédés destinés à autoriser une transaction avec un cryptogramme inattendu

Publications (1)

Publication Number Publication Date
EP3996019A1 true EP3996019A1 (fr) 2022-05-11

Family

ID=47745052

Family Applications (3)

Application Number Title Priority Date Filing Date
EP19199694.1A Withdrawn EP3754577A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu
EP12827026.1A Withdrawn EP2751754A4 (fr) 2011-08-30 2012-08-30 Systèmes et procédés destinés à autoriser une transaction avec un cryptogramme inattendu
EP21198983.5A Pending EP3996019A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu

Family Applications Before (2)

Application Number Title Priority Date Filing Date
EP19199694.1A Withdrawn EP3754577A1 (fr) 2011-08-30 2012-08-30 Systèmes et procédés permettant d'autoriser une transaction avec un cryptogramme inattendu
EP12827026.1A Withdrawn EP2751754A4 (fr) 2011-08-30 2012-08-30 Systèmes et procédés destinés à autoriser une transaction avec un cryptogramme inattendu

Country Status (7)

Country Link
US (3) US10032171B2 (fr)
EP (3) EP3754577A1 (fr)
CN (2) CN104025137B (fr)
AU (2) AU2012301897B2 (fr)
CA (2) CA3012991A1 (fr)
WO (1) WO2013033388A1 (fr)
ZA (1) ZA201401522B (fr)

Families Citing this family (343)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140019352A1 (en) 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
US8762263B2 (en) 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US7937324B2 (en) 2007-09-13 2011-05-03 Visa U.S.A. Inc. Account permanence
US8219489B2 (en) 2008-07-29 2012-07-10 Visa U.S.A. Inc. Transaction processing using a global unique identifier
AU2009311303B2 (en) 2008-11-06 2015-09-10 Visa International Service Association Online challenge-response
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US8602293B2 (en) 2009-05-15 2013-12-10 Visa International Service Association Integration of verification tokens with portable computing devices
US7891560B2 (en) * 2009-05-15 2011-02-22 Visa International Service Assocation Verification of portable consumer devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US9038886B2 (en) * 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US10140598B2 (en) 2009-05-20 2018-11-27 Visa International Service Association Device including encrypted data for expiration date and verification value creation
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
EP2524471B1 (fr) 2010-01-12 2015-03-11 Visa International Service Association Validation permanente de jetons de vérification
US10255601B2 (en) 2010-02-25 2019-04-09 Visa International Service Association Multifactor authentication using a directory server
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
US9342832B2 (en) 2010-08-12 2016-05-17 Visa International Service Association Securing external systems with account token substitution
AU2012217606A1 (en) 2011-02-16 2013-05-09 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
SG193510A1 (en) 2011-02-22 2013-10-30 Visa Int Service Ass Universal electronic payment apparatuses, methods and systems
CN107967602A (zh) 2011-03-04 2018-04-27 维萨国际服务协会 支付能力结合至计算机的安全元件
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
AU2012278963B2 (en) 2011-07-05 2017-02-23 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
WO2013019567A2 (fr) 2011-07-29 2013-02-07 Visa International Service Association Introduction d'authentifieurs de paiement par l'intermédiaire d'une page hop/sop
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US9165294B2 (en) 2011-08-24 2015-10-20 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
SG11201403861XA (en) 2012-01-05 2014-08-28 Visa Int Service Ass Data protection with translation
US9830595B2 (en) 2012-01-26 2017-11-28 Visa International Service Association System and method of providing tokenization as a service
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US8712407B1 (en) * 2012-04-05 2014-04-29 Sprint Communications Company L.P. Multiple secure elements in mobile electronic device with near field communication capability
EP2839421A4 (fr) * 2012-04-18 2015-07-15 Google Inc Traitement de transactions de paiement sans élément sécurisé
US20130297501A1 (en) 2012-05-04 2013-11-07 Justin Monk System and method for local data conversion
US9027102B2 (en) 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US8862181B1 (en) 2012-05-29 2014-10-14 Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
WO2014008403A1 (fr) 2012-07-03 2014-01-09 Visa International Service Association Concentrateur de protection de données
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US8863252B1 (en) * 2012-07-25 2014-10-14 Sprint Communications Company L.P. Trusted access to third party applications systems and methods
US9256871B2 (en) 2012-07-26 2016-02-09 Visa U.S.A. Inc. Configurable payment tokens
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
US9183412B2 (en) 2012-08-10 2015-11-10 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US8954588B1 (en) 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
US9754270B2 (en) * 2012-08-31 2017-09-05 Ncr Corporation Techniques for channel-independent offer management
US8752140B1 (en) 2012-09-11 2014-06-10 Sprint Communications Company L.P. System and methods for trusted internet domain networking
AU2013315510B2 (en) 2012-09-11 2019-08-22 Visa International Service Association Cloud-based Virtual Wallet NFC Apparatuses, methods and systems
CA2830260C (fr) 2012-10-17 2021-10-12 Royal Bank Of Canada Virtualisation et donnees a traitement sur
US11080701B2 (en) 2015-07-02 2021-08-03 Royal Bank Of Canada Secure processing of electronic payments
US11210648B2 (en) 2012-10-17 2021-12-28 Royal Bank Of Canada Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments
US10176478B2 (en) 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
WO2014087381A1 (fr) 2012-12-07 2014-06-12 Visa International Service Association Composant de génération de jeton
US8706081B1 (en) * 2012-12-18 2014-04-22 Google Inc. Packet inspection in near field communication controller for secure element protection
US8972296B2 (en) 2012-12-31 2015-03-03 Ebay Inc. Dongle facilitated wireless consumer payments
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US10740731B2 (en) 2013-01-02 2020-08-11 Visa International Service Association Third party settlement
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US8881977B1 (en) 2013-03-13 2014-11-11 Sprint Communications Company L.P. Point-of-sale and automated teller machine transactions using trusted mobile access device
WO2014142857A1 (fr) * 2013-03-14 2014-09-18 Hewlett-Packard Development Company, L.P. Communication sans fil d'un identificateur d'utilisateur et données sensibles au temps cryptées
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
CN104104646B (zh) * 2013-04-02 2017-08-25 中国银联股份有限公司 基于安全载体主动式命令的安全性信息交互系统、设备及方法
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
US11055710B2 (en) 2013-05-02 2021-07-06 Visa International Service Association Systems and methods for verifying and processing transactions using virtual currency
US9760886B2 (en) * 2013-05-10 2017-09-12 Visa International Service Association Device provisioning using partial personalization scripts
US10032185B2 (en) * 2013-05-10 2018-07-24 Excalibur Ip, Llc Automating price guarantees
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
US9436652B2 (en) * 2013-06-01 2016-09-06 General Electric Company Honeyport active network security
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
US10878422B2 (en) 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
CA2919199C (fr) 2013-07-24 2020-06-16 Visa International Service Association Systemes et procedes de communication d'un risque au moyen de donnees d'assurance de jeton
CN115907763A (zh) 2013-07-26 2023-04-04 维萨国际服务协会 向消费者提供支付凭证
US10496986B2 (en) 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
CN114819961A (zh) 2013-08-08 2022-07-29 维萨国际服务协会 用于为移动设备供应支付凭证的方法和系统
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
FR3011653B1 (fr) 2013-10-09 2018-01-12 Oberthur Technologies Procedes et dispositifs de masquage et demasquage
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
AU2014331673B2 (en) 2013-10-11 2018-05-17 Mastercard International Incorporated Network token system
US10515358B2 (en) 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
US10489779B2 (en) 2013-10-21 2019-11-26 Visa International Service Association Multi-network token bin routing with defined verification parameters
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US10366387B2 (en) 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
US8930274B1 (en) 2013-10-30 2015-01-06 Google Inc. Securing payment transactions with rotating application transaction counters
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
SG10201900029SA (en) 2013-11-19 2019-02-27 Visa Int Service Ass Automated account provisioning
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
DE102013019870B4 (de) * 2013-11-28 2019-08-08 Friedrich Kisters Authentifizierungs- und/oder Identifikationsverfahren in einem Kommunikationsnetzwerk
CN115082065A (zh) 2013-12-19 2022-09-20 维萨国际服务协会 基于云的交易方法和系统
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US10445718B2 (en) 2013-12-27 2019-10-15 Visa International Service Association Processing a transaction using multiple application identifiers
US10433128B2 (en) 2014-01-07 2019-10-01 Visa International Service Association Methods and systems for provisioning multiple devices
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
US8924260B1 (en) * 2014-02-04 2014-12-30 Scvngr, Inc. Dynamic ingestion and processing of transactional data at the point of sale
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US10026087B2 (en) 2014-04-08 2018-07-17 Visa International Service Association Data passed in an interaction
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9680942B2 (en) 2014-05-01 2017-06-13 Visa International Service Association Data verification using access device
WO2015171625A1 (fr) 2014-05-05 2015-11-12 Visa International Service Association Système et procédé de contrôle de domaine de jeton
US9584509B2 (en) 2014-05-07 2017-02-28 Cryptography Research, Inc. Auditing and permission provisioning mechanisms in a distributed secure asset-management infrastructure
EP3146747B1 (fr) 2014-05-21 2020-07-01 Visa International Service Association Authentification hors ligne
EP2950229B1 (fr) * 2014-05-28 2018-09-12 Nxp B.V. Procédé permettant de faciliter des transactions, produit de programme informatique et dispositif mobile
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US10484345B2 (en) 2014-07-31 2019-11-19 Visa International Service Association System and method for identity verification across mobile applications
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
FR3025341B1 (fr) 2014-09-02 2016-12-30 Oberthur Technologies Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise
EP2996299B1 (fr) * 2014-09-15 2021-05-12 Wincor Nixdorf International GmbH Procédé et système d'autorisation d'une action sur un système auto-commandé
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
SG11201701653WA (en) 2014-09-26 2017-04-27 Visa Int Service Ass Remote server encrypted data provisioning system and methods
US11257074B2 (en) 2014-09-29 2022-02-22 Visa International Service Association Transaction risk based token
CN106031050B (zh) * 2014-09-30 2019-06-11 华为技术有限公司 一种信息处理方法及nfc终端
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
GB201419016D0 (en) 2014-10-24 2014-12-10 Visa Europe Ltd Transaction Messaging
US9819396B2 (en) * 2014-10-28 2017-11-14 Google Inc. Managing contactless communications
CN105608576A (zh) * 2014-11-24 2016-05-25 中国移动通信集团公司 一种信息处理方法、装置及终端
US10325261B2 (en) 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
EP3224784A4 (fr) 2014-11-26 2017-11-08 Visa International Service Association Demande de tokénisation par le biais d'un dispositif d'accès
FR3029324B1 (fr) * 2014-11-28 2017-12-15 Proton World Int Nv Acces a des donnees dans un dispositif mobile nfc
CN107005563B (zh) 2014-12-12 2021-03-30 维萨国际服务协会 用于机器对机器装置的供应平台
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
CN107408253B (zh) 2015-01-19 2021-08-06 加拿大皇家银行 电子支付的安全处理
US11354651B2 (en) 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US11250391B2 (en) 2015-01-30 2022-02-15 Visa International Service Association Token check offline
WO2016126729A1 (fr) 2015-02-03 2016-08-11 Visa International Service Association Jetons d'identité de validation pour des transactions
US10977657B2 (en) 2015-02-09 2021-04-13 Visa International Service Association Token processing utilizing multiple authorizations
EP3259876B1 (fr) * 2015-02-17 2020-08-12 Visa International Service Association Jeton et cryptogramme utilisant des informations spécifiques à une transaction
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
US20160267466A1 (en) * 2015-03-13 2016-09-15 Phillip Kumnick Device with multiple identifiers
US11037139B1 (en) 2015-03-19 2021-06-15 Wells Fargo Bank, N.A. Systems and methods for smart card mobile device authentication
US11188919B1 (en) 2015-03-27 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for contactless smart card authentication
US10528945B1 (en) 2015-03-31 2020-01-07 Square, Inc. Open ticket payment handling with incremental authorization
US10043162B1 (en) 2015-03-31 2018-08-07 Square, Inc. Open ticket payment handling with bill splitting
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
CN107438992B (zh) 2015-04-10 2020-12-01 维萨国际服务协会 浏览器与密码的集成
US10601818B2 (en) * 2015-04-13 2020-03-24 Visa International Service Association Enhanced authentication based on secondary device interactions
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
US10552834B2 (en) 2015-04-30 2020-02-04 Visa International Service Association Tokenization capable authentication framework
US20200402049A1 (en) * 2015-06-11 2020-12-24 APPI Technologia S/A (D.B.A. MUXI) Antifraud Resilient Transaction Identifier Datastructure Apparatuses, Methods and Systems
US11599879B2 (en) 2015-07-02 2023-03-07 Royal Bank Of Canada Processing of electronic transactions
EP3122082A1 (fr) * 2015-07-24 2017-01-25 Gemalto Sa Procédé de sécurisation d'une fonction applicative dans un contexte utilisant des éléments sécurisés virtuels dans le cloud
US9825946B2 (en) * 2015-08-27 2017-11-21 Mastercard International Incorporated Method and system for enhanced validation of cryptograms in cloud-based systems
CA2930705C (fr) * 2015-08-27 2019-06-11 Samsung Pay, Inc. Systemes de fin de transaction mobile et methodes
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
US9569757B1 (en) 2015-09-30 2017-02-14 Square, Inc. Anticipatory creation of point-of-sale data structures
US20170103396A1 (en) * 2015-10-13 2017-04-13 Mastercard International Incorporated Adaptable messaging
AU2016337614A1 (en) 2015-10-15 2018-03-15 Visa International Service Association Instant token issuance system
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
CN108370319B (zh) 2015-12-04 2021-08-17 维萨国际服务协会 用于令牌验证的方法及计算机
EP3185194A1 (fr) * 2015-12-24 2017-06-28 Gemalto Sa Procédé et système pour améliorer la sécurité d'une transaction
CN107038541A (zh) * 2015-12-29 2017-08-11 奇克逻辑有限责任公司 用于控制寄托库存的方法、系统及装置
CA3009659C (fr) 2016-01-07 2022-12-13 Visa International Service Association Systemes et procedes de fourniture de push pour dispositif
FR3046864B1 (fr) * 2016-01-18 2018-11-16 Proton World International N.V. Controle d'applications dans un terminal mobile
CN108604989B (zh) 2016-02-01 2022-07-22 维萨国际服务协会 用于代码显示和使用的系统和方法
US10496982B2 (en) 2016-02-03 2019-12-03 Accenture Global Solutions Limited Secure contactless card emulation
US11501288B2 (en) 2016-02-09 2022-11-15 Visa International Service Association Resource provider account token provisioning and processing
US10861019B2 (en) * 2016-03-18 2020-12-08 Visa International Service Association Location verification during dynamic data transactions
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
AU2016403734B2 (en) 2016-04-19 2022-11-17 Visa International Service Association Systems and methods for performing push transactions
US11113688B1 (en) 2016-04-22 2021-09-07 Wells Fargo Bank, N.A. Systems and methods for mobile wallet provisioning
CN107330685B (zh) * 2016-04-29 2021-03-05 中国电信股份有限公司 基于nfc的通信方法以及tsm系统
US11250424B2 (en) 2016-05-19 2022-02-15 Visa International Service Association Systems and methods for creating subtokens using primary tokens
BR112018072903A2 (pt) 2016-06-03 2019-02-19 Visa International Service Association método, e, dispositivos de comunicação e conectado.
US11068899B2 (en) 2016-06-17 2021-07-20 Visa International Service Association Token aggregation for multi-party transactions
US10311420B1 (en) 2016-06-17 2019-06-04 Square, Inc. Synchronizing open ticket functionality with kitchen display systems
US10289992B1 (en) * 2016-06-17 2019-05-14 Square, Inc. Kitchen display interfaces with in flight capabilities
US10360648B1 (en) 2016-06-22 2019-07-23 Square, Inc. Synchronizing KDS functionality with POS waitlist generation
US10361856B2 (en) 2016-06-24 2019-07-23 Visa International Service Association Unique token authentication cryptogram
US10580062B1 (en) * 2016-06-28 2020-03-03 Square, Inc. Integrating predefined templates with open ticket functionality
WO2018013431A2 (fr) 2016-07-11 2018-01-18 Visa International Service Association Procédé d'échange de clés de chiffrement utilisant un dispositif d'accès
EP3488406A4 (fr) 2016-07-19 2019-08-07 Visa International Service Association Procédé de distribution de jetons et de gestion de relations de jetons
US10509779B2 (en) 2016-09-14 2019-12-17 Visa International Service Association Self-cleaning token vault
CN117009946A (zh) 2016-11-28 2023-11-07 维萨国际服务协会 供应到应用程序的访问标识符
US10764056B2 (en) * 2017-01-12 2020-09-01 Oleksandr Senyuk Short-distance network electronic authentication
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
US10915899B2 (en) 2017-03-17 2021-02-09 Visa International Service Association Replacing token on a multi-token user device
EP3600060B1 (fr) * 2017-04-14 2022-03-16 Samsung Electronics Co., Ltd. Transmission acoustique sécurisée (ast)
US10902418B2 (en) 2017-05-02 2021-01-26 Visa International Service Association System and method using interaction token
US11494765B2 (en) 2017-05-11 2022-11-08 Visa International Service Association Secure remote transaction system using mobile devices
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
US10491389B2 (en) 2017-07-14 2019-11-26 Visa International Service Association Token provisioning utilizing a secure authentication system
US10467559B1 (en) 2017-09-29 2019-11-05 Square, Inc. Order fulfillment and tracking systems and methods
US10943311B1 (en) 2017-09-29 2021-03-09 Square, Inc. Order fulfillment and tracking systems and methods
US20190172037A1 (en) * 2017-12-01 2019-06-06 Qualcomm Incorporated Privacy protection in financial transactions conducted on mobile platforms
US10317504B1 (en) * 2017-12-12 2019-06-11 Nxp B.V. RFID orientation detection
EP3762844A4 (fr) 2018-03-07 2021-04-21 Visa International Service Association Libération de jeton à distance sécurisée avec authentification en ligne
US11481837B1 (en) 2018-04-12 2022-10-25 Wells Fargo Bank, N.A. Authentication circle management
US11386412B1 (en) 2018-04-12 2022-07-12 Wells Fargo Bank, N.A. Authentication circle management
US10943308B1 (en) 2018-05-03 2021-03-09 Wells Fargo Bank, N.A. Systems and methods for pervasive advisor for major expenditures
US11256789B2 (en) 2018-06-18 2022-02-22 Visa International Service Association Recurring token transactions
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
EP3841498A4 (fr) 2018-08-22 2021-10-13 Visa International Service Association Procédé et système permettant de fournir et de traiter un jeton
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10505738B1 (en) * 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202102798TA (en) 2018-10-02 2021-04-29 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
JP2022508026A (ja) 2018-10-02 2022-01-19 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー 非接触カードの暗号化認証のためのシステムおよび方法
CA3115107A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systemes et procedes d'authentification cryptographique des cartes sans contact
US10783519B2 (en) 2018-10-02 2020-09-22 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
SG11202101221WA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
BR112021005150A2 (pt) 2018-10-02 2021-06-15 Capital One Services, Llc sistema de transmissão de dados, método para guiar um dispositivo de transmissão, e, aplicação de recepção
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072440A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés d'authentification cryptographique de cartes sans contact
US10607216B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10630653B1 (en) 2018-10-02 2020-04-21 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
WO2020072583A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systèmes et procédés d'établissement d'identité pour retrait de commande
CA3115142A1 (fr) 2018-10-02 2020-04-09 Capital One Services, Llc Systemes et procedes pour authentification cryptographique de cartes sans contact
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
JP2022511281A (ja) 2018-10-02 2022-01-31 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー 非接触カードの暗号化認証のためのシステムおよび方法
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
KR20210065109A (ko) 2018-10-02 2021-06-03 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
US10748138B2 (en) 2018-10-02 2020-08-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202104782TA (en) 2018-11-14 2021-06-29 Visa Int Service Ass Cloud token provisioning of multiple tokens
US11138680B1 (en) 2018-11-21 2021-10-05 Square, Inc. Updating menus based on predicted efficiencies
EP3657419A1 (fr) * 2018-11-23 2020-05-27 Mastercard International Incorporated Gestion de mémoire cache de système de transactions
US10915905B1 (en) 2018-12-13 2021-02-09 Square, Inc. Batch-processing transactions in response to an event
US11361302B2 (en) 2019-01-11 2022-06-14 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US20200279258A1 (en) * 2019-03-01 2020-09-03 Visa International Service Association Mobile payments using multiple cryptographic protocols
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US11227280B2 (en) * 2019-03-25 2022-01-18 Capital One Services, Llc Systems and methods for increased efficiency and reliability of contactless card transactions
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
US11849042B2 (en) 2019-05-17 2023-12-19 Visa International Service Association Virtual access credential interaction system and method
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US11296862B2 (en) * 2019-08-29 2022-04-05 Visa International Service Association Provisioning method and system with message conversion
US11269987B2 (en) * 2019-09-09 2022-03-08 International Business Machines Corporation Security credentials management for client applications
US11928666B1 (en) 2019-09-18 2024-03-12 Wells Fargo Bank, N.A. Systems and methods for passwordless login via a contactless card
CN114424202A (zh) * 2019-09-19 2022-04-29 维萨国际服务协会 用于使用动态标签内容的系统和方法
US20220376933A1 (en) * 2019-09-25 2022-11-24 Commonwealth Scientific And Industrial Research Organisation Cryptographic services for browser applications
RU2724793C1 (ru) * 2019-10-01 2020-06-25 Общество с ограниченной ответственностью "ЭВОТОР" Способ удаленной загрузки комплекта ключей в смарт-терминал
EP4038587A4 (fr) 2019-10-02 2023-06-07 Capital One Services, LLC Authentification de dispositif client utilisant des données de bande magnétique existante sans contact
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US11301863B2 (en) * 2020-01-27 2022-04-12 Mastercard International Incorporated Cardholder selected card validation code for card-not-present transactions
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
CN113569247A (zh) * 2020-04-28 2021-10-29 深圳绿米联创科技有限公司 设备升级方法、装置、系统及电子设备
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11423392B1 (en) 2020-12-01 2022-08-23 Wells Fargo Bank, N.A. Systems and methods for information verification using a contactless card
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11783316B2 (en) * 2021-02-25 2023-10-10 Visa International Service Association Method and system of capturing contactless communication interactions for debugging and evaluating contactless card transaction
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1931808A (en) 1931-11-24 1933-10-24 Andersen Hans Rope sling
WO2001008113A1 (fr) * 1999-07-22 2001-02-01 Visa International Service Association Systeme de paiement, d'authentification et de chargement par internet au moyen d'une carte a puce virtuelle
US20020026414A1 (en) * 2000-08-25 2002-02-28 Mitsuru Nakajima Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
WO2009017754A1 (fr) * 2007-07-30 2009-02-05 Ebay Inc. Procédé et système pour un financement dynamique
US20100153721A1 (en) * 2008-12-12 2010-06-17 Anders Mellqvist Portable Electronic Devices, Systems, Methods and Computer Program Products for Accessing Remote Secure Elements
US20110099079A1 (en) * 2009-10-27 2011-04-28 At&T Mobility Ii Llc Secure Mobile-Based Financial Transactions
US8151345B1 (en) 2007-01-25 2012-04-03 Yeager C Douglas Self-authorizing devices

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5636280A (en) * 1994-10-31 1997-06-03 Kelly; Tadhg Dual key reflexive encryption security system
US5737423A (en) * 1995-08-23 1998-04-07 Pitney Bowes Inc. Old modified smart card or similar apparatus having a remote inspection capability
US6199762B1 (en) 1998-05-06 2001-03-13 American Express Travel Related Services Co., Inc. Methods and apparatus for dynamic smartcard synchronization and personalization
US7093761B2 (en) 2001-09-24 2006-08-22 E2Interactive, Inc. System and method for distributing stored-value cards
US7774231B2 (en) 2000-09-29 2010-08-10 Nokia Corporation Electronic payment methods for a mobile device
US20040218762A1 (en) * 2003-04-29 2004-11-04 Eric Le Saint Universal secure messaging for cryptographic modules
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
WO2003073286A1 (fr) 2002-02-27 2003-09-04 James Tang Elimination de fraudes au moyen d'une gestuelle et d'un identificateur secrets
US20040143550A1 (en) * 2002-12-19 2004-07-22 International Business Machines Corporation Cellular electronic wallet device and method
CN1882963A (zh) * 2003-06-30 2006-12-20 塞尔维纳坦·纳拉因萨米 交易验证系统
WO2005004069A1 (fr) 2003-07-02 2005-01-13 Mobipay International, S.A. Systeme de transactions et de paiements par telephone mobile numerique
AU2005274950B2 (en) * 2004-07-15 2010-12-09 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
BRPI0514505A (pt) * 2004-08-18 2008-06-10 Mastecard Internat Inc método e sistema para autorizar uma transação
US20070075133A1 (en) 2005-08-15 2007-04-05 Sirit Technologies, Inc. Method, System and Computer-Readable Medium for Radio Frequency Identification Device
US20090075592A1 (en) 2005-12-16 2009-03-19 Sebastian Nystrom Method and device for controlling and providing indications of communication events
US8511547B2 (en) * 2005-12-22 2013-08-20 Mastercard International Incorporated Methods and systems for two-factor authentication using contactless chip cards or devices and mobile devices or dedicated personal readers
US20070156436A1 (en) 2005-12-31 2007-07-05 Michelle Fisher Method And Apparatus For Completing A Transaction Using A Wireless Mobile Communication Channel And Another Communication Channel
US8290433B2 (en) * 2007-11-14 2012-10-16 Blaze Mobile, Inc. Method and system for securing transactions made through a mobile communication device
US20070266131A1 (en) * 2006-05-12 2007-11-15 Simpera Inc. Obtaining and Using Primary Access Numbers Utilizing a Mobile Wireless Device
US7957532B2 (en) * 2006-06-23 2011-06-07 Microsoft Corporation Data protection for a mobile device
US20080046367A1 (en) 2006-08-18 2008-02-21 Patent Navigation Inc. Mobile device confirmation of transactions
US7962369B2 (en) 2006-09-29 2011-06-14 Einar Rosenberg Apparatus and method using near field communications
US20090006262A1 (en) 2006-12-30 2009-01-01 Brown Kerry D Financial transaction payment processor
FR2913550A1 (fr) * 2007-03-07 2008-09-12 Inside Contactless Sa Procede de chargement securise de donnees d'acces a un service dans un chipset nfc
US8667285B2 (en) * 2007-05-31 2014-03-04 Vasco Data Security, Inc. Remote authentication and transaction signatures
US20090070691A1 (en) * 2007-09-12 2009-03-12 Devicefidelity, Inc. Presenting web pages through mobile host devices
US20090143104A1 (en) 2007-09-21 2009-06-04 Michael Loh Wireless smart card and integrated personal area network, near field communication and contactless payment system
US9947002B2 (en) 2008-02-15 2018-04-17 First Data Corporation Secure authorization of contactless transaction
EP2128830A1 (fr) * 2008-05-30 2009-12-02 Gemplus Procédé et dispositif électronique pour transférer des données d'application depuis un dispositif électronique source vers un dispositif électronique de destination
US8814052B2 (en) 2008-08-20 2014-08-26 X-Card Holdings, Llc Secure smart card system
SK288757B6 (sk) 2008-09-19 2020-05-04 Smk Kk Systém a spôsob bezkontaktnej autorizácie pri platbe
US9824355B2 (en) * 2008-09-22 2017-11-21 Visa International Service Association Method of performing transactions with contactless payment devices using pre-tap and two-tap operations
US10037524B2 (en) * 2009-01-22 2018-07-31 First Data Corporation Dynamic primary account number (PAN) and unique key per card
EP2852070B1 (fr) * 2009-01-26 2019-01-23 Google Technology Holdings LLC Dispositif de communication sans fil pour fournir au moins un service de communication à champ proche
US20100317318A1 (en) * 2009-06-10 2010-12-16 Carter Ronald D Methods and apparatus for providing pre-paid payment capability on mobile telephone
US8706556B2 (en) 2009-11-06 2014-04-22 Mastercard International Incorporated Methods for risk management in payment-enabled mobile device
US10579995B2 (en) * 2010-03-30 2020-03-03 Visa International Service Association Event access with data field encryption for validation and access control
US8746553B2 (en) * 2010-09-27 2014-06-10 Mastercard International Incorporated Purchase Payment device updates using an authentication process
US8799087B2 (en) * 2010-10-27 2014-08-05 Mastercard International Incorporated Systems, methods, and computer readable media for utilizing one or more preferred application lists in a wireless device reader
GB201105765D0 (en) * 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
WO2012170895A1 (fr) * 2011-06-09 2012-12-13 Yeager C Douglas Systèmes et procédés conçus pour autoriser une transaction
US9767262B1 (en) * 2011-07-29 2017-09-19 Amazon Technologies, Inc. Managing security credentials
US10515359B2 (en) * 2012-04-02 2019-12-24 Mastercard International Incorporated Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements
GB2505678B (en) * 2012-09-06 2014-09-17 Visa Europe Ltd Method and system for verifying an access request
EP2939363A1 (fr) * 2012-12-28 2015-11-04 Vasco Data Security International GmbH Signatures d'authentification et de transaction distantes

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1931808A (en) 1931-11-24 1933-10-24 Andersen Hans Rope sling
WO2001008113A1 (fr) * 1999-07-22 2001-02-01 Visa International Service Association Systeme de paiement, d'authentification et de chargement par internet au moyen d'une carte a puce virtuelle
US20020026414A1 (en) * 2000-08-25 2002-02-28 Mitsuru Nakajima Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
US8151345B1 (en) 2007-01-25 2012-04-03 Yeager C Douglas Self-authorizing devices
WO2009017754A1 (fr) * 2007-07-30 2009-02-05 Ebay Inc. Procédé et système pour un financement dynamique
US20100153721A1 (en) * 2008-12-12 2010-06-17 Anders Mellqvist Portable Electronic Devices, Systems, Methods and Computer Program Products for Accessing Remote Secure Elements
US20110099079A1 (en) * 2009-10-27 2011-04-28 At&T Mobility Ii Llc Secure Mobile-Based Financial Transactions

Also Published As

Publication number Publication date
US10032171B2 (en) 2018-07-24
AU2017204649A1 (en) 2017-08-03
CA2846462A1 (fr) 2013-03-07
AU2017204649B2 (en) 2019-03-28
CN110111087A (zh) 2019-08-09
CN110111087B (zh) 2024-01-02
BR112014004374A2 (pt) 2017-03-21
ZA201401522B (en) 2016-09-28
US20130054474A1 (en) 2013-02-28
AU2012301897B2 (en) 2017-04-13
CA3012991A1 (fr) 2013-03-07
EP2751754A1 (fr) 2014-07-09
EP2751754A4 (fr) 2015-06-03
WO2013033388A1 (fr) 2013-03-07
CN104025137A (zh) 2014-09-03
CA2846462C (fr) 2018-09-11
EP3754577A1 (fr) 2020-12-23
AU2012301897A1 (en) 2014-03-06
CN104025137B (zh) 2019-05-03
US20220358513A1 (en) 2022-11-10
US20180349913A1 (en) 2018-12-06

Similar Documents

Publication Publication Date Title
US20220358513A1 (en) Systems and methods for authorizing a transaction with an unexpected cryptogram
US20120317628A1 (en) Systems and methods for authorizing a transaction
EP2761553B1 (fr) Système de paiement
US8548924B2 (en) Self-authorizing token
US20140310182A1 (en) Systems and methods for outputting information on a display of a mobile device
KR20140058564A (ko) 보안 요소를 구비한 모바일 기기
CN109564659B (zh) 经由启用支付的移动设备中的钱包应用与卡发行方共享数据
TW201349143A (zh) 交易處理系統及方法
JP2016076262A (ja) インターネット接続及び対応の端末を介した商業サイトにおける製品又はサービスの決済方法
US11615406B2 (en) Method and system for providing a service at a self-service machine
AU2015100744B4 (en) Systems and methods for authorizing a transaction with an unexpected cryptogram
US20210256495A1 (en) Portable device loading mechanism for account access
KR20090023433A (ko) 통합 금융 서비스를 위한 아이씨 카드 단말 및 기록매체
KR100928412B1 (ko) 가상 가맹점 망을 이용한 결제처리 시스템
KR101113555B1 (ko) 메모리 카드의 사용 인증방법 및 시스템과 이를 위한 기록매체
BR112014004374B1 (pt) Método para participação com base em aplicação segura em um processo de autorização de transação de cartão de pagamento por um dispositivo móvel, sistema para participação com base em aplicação segura por um dispositivo móvel em interrogações de ponto de venda
KR20080096637A (ko) 결제처리 방법 및 시스템
KR20090016618A (ko) 가상 가맹점 망을 이용한 결제처리 방법 및 기록매체
KR20110012590A (ko) 메모리 카드를 이용한 물품 결제방법 및 시스템과 이를 위한 기록매체
KR20080084872A (ko) 카드 단말기와 프로그램 기록매체와 이를 이용한결제처리방법 및 시스템

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AC Divisional application: reference to earlier application

Ref document number: 2751754

Country of ref document: EP

Kind code of ref document: P

Ref document number: 3754577

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221111

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40075052

Country of ref document: HK