US20090307140A1

US20090307140A1 - Mobile device over-the-air (ota) registration and point-of-sale (pos) payment

Info

Publication number: US20090307140A1
Application number: US12/249,145
Authority: US
Inventors: Upendra Mardikar
Original assignee: Individual
Current assignee: PayPal Inc
Priority date: 2008-06-06
Filing date: 2008-10-10
Publication date: 2009-12-10
Also published as: US8108318B2; CN105046479A; US20180218358A1; WO2010002541A1; US20180225654A1; EP2308014A1; US8417643B2; US20090307139A1; US20150056957A1; US9858566B2; US8554689B2; CN102057386A; EP2308014A4; US8150772B2; US9852418B2; US11521194B2; US20130198086A1; US20090307778A1; US20120173434A1; US20120089520A1

Abstract

A method for enabling secure registration of a mobile device OTA and for conducting a financial transaction at a point-of-sale (POS) has been described herein. In one embodiment, a method of mobile device registration over-the-air (OTA) comprises enabling a pre-loaded payment application having payment account information; enabling a certificate request; receiving payment credentials; associating the payment credentials with the payment account information; transmitting the payment account information and the certificate request OTA; and receiving a certificate of registration of the mobile device OTA.

Description

RELATED APPLICATIONS

This application claims priority and the benefit of U.S. Provisional Application No. 61/059,395, filed Jun. 6, 2008; and U.S. Provisional Application No. 61/059,907 filed Jun. 9, 2008, the entire disclosures of which are incorporated herein by reference.

BACKGROUND

1. Field of the Invention
The present invention generally relates to financial transactions and more particularly to secure financial transactions initiated from an electronic device.
2. Related Art
In direct (face-to-face) or online financial transactions customers may search for and purchase products and/or services from a merchant. In the case of online shopping, transactions are conducted through electronic communications with online merchants over electronic networks. A variety of electronic devices and various electronic techniques may be utilized to conduct such electronic transactions. Methods of initiating or making financial transactions from an electronic device include wireless communication as well as mobile Internet-based payments to name a few.
One such wireless technology, Near Field Communication, herein referred to a “NFC” is the most recently explored technology for object augmentation to bring mobile devices and physical objects together to enable a user to interact with the augmented objects for information and/or data communication. In this regard, NFC is a short range high frequency wireless communication technology that enables the exchange of data between devices over a relatively short distance.
A key feature of NFC devices is that the NFC chip that is integrated into the NFC device can read out an RFID tag's information (reader/writer mode), emulate a smart card so that a reader can access its data (card emulation mode), or communicate directly with another NFC device when the two NFC devices are brought in close proximity or together with each other (peer-to-peer mode).
NFC technology may be incorporated into most any electronic device; however vast business opportunities potentially exist in the use of NFC technology in a mobile device such a cell phone, PDA, or similar device. As such, in one context mobile NFC may be defined as a combination of contactless services and mobile telephony.
NFC in mobile devices may provide for contactless payment; information gathering; loyalty, promotional, and other value-added programs; and other services. More specifically, mobile NFC enables product and/or service purchases including tickets to a theater performance or a sporting event, access to smart posters that provide on the spot wait times and neighborhood maps, download and redeeming of electronic coupons and vouchers, electronic fund transfer between accounts, and other related applications.
As shown in FIG. 1, any number of involved parties may comprise an NFC electronic communications ecosystem. Such involved parties may include a customer or user, a merchant, a mobile network operator (MNO), a service provider (SP), a trusted service manager (TSM), a mobile phone manufacturer, a integrated chip (IC) manufacturer, and application (software) developers to name a few. The duties or roles of one or more involved parties may be combined and preformed by a single entity.
For example, as shown in FIG. 2, service providers, banks, or other financial institutions are those entities that typically issue credit and provide authorization for conducting financial transactions between the customer and the merchant. A payment provider system (PP), such as PayPal, may provide payment processing for online transactions on behalf of the customer so that the customer does not expose payment information directly to the merchant. Instead, the customer may register his account with the payment provider system, map the account to an email address, and then use the payment provider system to make purchases when redirected to the payment provider system from the merchant's site. After the financial transaction is authorized the payment provider system completes the transaction.
In online financial transactions, the role of the payment provider system may be expanded to include or share duties generally associated with the service provider such that customers may use the payment provider system as a credit issuer, and for services such as electronic bank transfers from one account to another account, and/or provide access to other related financial activities through electronic communications over electronic networks operated by the MNO, such as the Internet. The payment provider system may provide an infrastructure, software, and services that enable customers and merchants to make and receive payments.
A central issue with mobile NFC or other wireless technology is the need for cooperation between the many involved parties to meet the needs of the customer via secure over-the-air (OTA) link. As shown in FIGS. 2 and 3, the payment provider system may further act as a TSM to provide a single point of contact for the service provider to access their customer base through the MNOs. More specifically, with the ever changing electronic communications environment including the emergence of NFC, service providers may not be ready or willing to change their working methods or the functions they provide, but they may still want to participate in the new mode of service operation by enhancing the services they offer while maintaining existing core processes. This conflict is solved by the TSM who can help service providers securely distribute and manage contactless services for their customers using the MNOs. In this regard, the TSM may manage the secure download and life-cycle management of the mobile NFC applications on behalf of the service providers.
Mobile devices generally associated with NFC include, for example, radio frequency-enabled credit and debit cards, key fobs, and NFC-enabled cell phones and PDAs. When registering a mobile device or conducting a financial transaction, or for that matter any transaction, security is generally an issue in that data transferred wirelessly will typically include credit card/financial instrument information, a user name, a password, etc., that is susceptible to theft and/or malicious attack. A user may at various times use any of several different payment applications for different service providers. To the extent that each payment application has its own separate security registration and verification procedures, the user experience may be cumbersome in that a user must separately load and run separate dedicated applications each of which must be separately registered and verified for making secure financial transactions. Moreover, the security of each of these applications may be compromised by viruses, Trojans, key loggers and the like since the applications and their security information may reside on the same data storage element. Accordingly, a secure, user-friendly method and system may be desirable for enabling secure registration of a mobile device OTA and for conducting a financial transaction at a point-of-sale (POS).

SUMMARY

For purposes of summarizing the disclosure, exemplary embodiments of systems and methods for enabling secure registration of a mobile device OTA and conducting a financial transaction at a POS have been described herein.
In one embodiment, a method of mobile device registration OTA comprises enabling a pre-loaded payment application having payment account information; enabling a certificate request; receiving payment credentials; associating the payment credentials with the payment account information; transmitting the payment account information and the certificate request OTA; and receiving a certificate of registration of the mobile device OTA.
In another embodiment, an apparatus for registration OTA comprises a mobile device adapted to enable a pre-loaded payment application having payment account information; enable a certificate request; receive payment credentials; associate the payment credentials with the payment account information; transmit the payment account information and the certificate request OTA; and receive a certificate of registration for the mobile device.
In still another embodiment, a method of payment instrument deployment to a mobile device for payment at a point-of-sale comprises transmitting a payment instrument request from a mobile device; receiving data including a payment instrument and a card verification value (CVV) by the mobile device; and storing the payment instrument and card verification value in a secure element of the mobile device for payment at a POS.
These and other features and advantages of the present invention will be more readily apparent from the detailed description of the embodiments set forth below taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an example of a mobile device ecosystem including involved parties.

FIG. 2 shows one example of the relationship between involved parties of FIG. 1 including the role of a trusted service manager.

FIG. 3 shows one example of a portion of the network connectivity between involved parties in the mobile device ecosystem of FIG. 1.

FIG. 4 shows one embodiment of a mobile device architecture including the physical separation of secure elements within the mobile device.

FIG. 5 shows various architectural schemes for a secure element within a mobile device.

FIG. 6 is a flow chart showing one embodiment of secure customer registration of a mobile device for financial transactions at a point-of-sale over a network.

FIG. 7 is a flow chart showing one embodiment of payment instrument deployment to a mobile device for payment at a point-of-sale.

Exemplary embodiments and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating exemplary embodiments and not for purposes of limiting the same.

DETAILED DESCRIPTION

Embodiments of the present disclosure related to systems and methods of secure customer registration of a mobile device for financial transactions at a POS over a network. As indicated above, mobile devices may provide for contactless payment; information gathering; loyalty, promotional, and other value-added programs; and other services.
As shown in FIGS. 2 and 3, in one embodiment a mobile device 100 may be used to communicate over a network 105 via a MNO 110, e.g., Sprint, Verizon, or other mobile network operators, to purchase products and/or services from a merchant 115. In one embodiment, a TSM 120 may provide a single point of contact between the mobile device 100, merchant 115, and service provider 125 through any of the various MNOs 110. In this regard, the TSM 120, or payment provider acting as the TSM, may manage the secure download and life-cycle management of the mobile applications, e.g., payment applications, on behalf of the service provider 125. Although an NFC is illustrated generally discussed herein with regard to various embodiments, the TSM's role or the role of other entities discussed herein is not limited to NFC and can be applied to other types of electronic communication including technologies such as Bluetooth, infrared, SMS (Short Message Service), and similar wireless technologies.
FIG. 4 shows an example of mobile device architecture 130. The major components of the mobile device include an antenna (not shown) built into the mobile device's case, an NFC or communication (COMM) chip 135, secure elements (SEs) 140, 145, and other associated elements. The communication chip may support one or more modes of communication, including, for example, NFC, GSM (Global System for Mobile Communication), UMTS (Universal Mobile Telecommunications System) and CDMA (Code Division Multiple Access) cellular phone protocols, SMS and internet access via a mobile network or local network, e.g., WAP (Wireless Application Protocol).
Within NFC or other mobile standards, security is typically managed by the SE. By one definition, a SE is a platform where applications can be installed, personalized and managed preferably OTA. It is a combination of hardware, software, interfaces and protocols that enable secure storage and the use of credentials for payments, authentication and other services. The SE may be pre-loaded with applications and/or may be capable of downloading various applications, for example, applications for facilitating financial transactions over a network. As shown in FIG. 5, a subscriber identification module (SIM) card 150, a secure flash card, or an embedded security controller could all act as a SE. A UICC (Universal Integrated Circuit Card) is a smart card that may be embedded in the mobile device and contains account information and memory that is used to enable GSM (Global System for Mobile communication) cellular telephones. One of the applications running on the smart card may be the SIM 150. As explained in more detail below, the SE hosts the fire walled applications and user credentials, and controls security and cryptography using an onboard microprocessor and software. The SE shares mobile functionality with the NFC chipset 135, which manages network communications.
In one embodiment, the architecture of the mobile device may include separate secure elements (SEs), one SE dedicated to running various service provider applications (App SE) 145 and another SE dedicated to providing security for the applications and financial transactions (Crypto SE) 140.
In this regard, software on the device may consist of a number of applications from credit card companies that require different types of encryption. The number of applications that reside on the mobile device may be numerous as individual retailers may also provide applications to promote and support loyalty programs such as coupons and vouchers, or, provide access to their services. In other words, the customer may shop for ticket(s) remotely OTA using an application supported by a company such as Ticketmaster, pay for the tickets using a credit or debit card application by a company such a PayPal, and then download the electronic ticket to the phone using an application by a company such as Verizon.
The SE may have logical and end-to-end security. For example, there may be an authenticated and encrypted channel for communication with the SE. In one embodiment, the SE may have physical security. For example, the SE may adhere to certain security standards, for example, FIPS 140-2 Level 3 (tamper proof and copy protection) and Common Criteria ISO 15408 EAL 4+, or other standard as required or desired. The SE may be global. In other words, an SE may be compatible with a variety of communications protocols or systems. For example, as indicated above, the mobile device may be compatible with GSM, UMTS and CDMA cellular phone protocols.
In one embodiment the SE may be portable, capable of dynamic and remote management, and standardization. A portable application may be an application that may be easily transferred from one device to another. This may be achieved, for example, by porting the SE or by having a TSM 120 that can port applications. Portability may enable a user who has registered one mobile device to register any other mobile devices of the user. For example, a user may have one mobile phone for business and another mobile phone for home where transactions from each of the mobile devices are intended for business or personal use respectively.
In one embodiment, the SE may be compatible with OTA loading or dynamic remote management. For example, applications resident in the App SE 145 may be compatible with OTA management for life cycle management of the applications. For example, resident applications may be managed, updated, or altered. OTA management may be used to fix newly discovered vulnerabilities in the applications or update the application to add features or modify features.
In one embodiment, an SE may be standardized. For example, the SE may be compatible with standards set out by a known standards or protocols, for example those established by GlobalPlatform.org and/or Bearer Independent Protocol. The SE may work even when the device is turned off. For example, an NFC transaction or purchase may be made even when the phone is turned off, e.g., when on an airplane or other location where electronic devices may be required to be turned off for operational or security reasons.
As indicated above, in one embodiment the device may include an App SE 145 and a Crypto SE 140. As used herein, unless otherwise specified the term “Crypto SE” 140 is used to refer to any one of payment, credential, or wallet SEs. Splitting the Crypto SE 140 and the App SE 145 may improve the user experience by reducing the necessity of registering and verifying various applications separately for each service provider and/or re-certification after changes are made to any of the applications. In other words, splitting the App SE 145 and Crypto SE 140 may enable a single certification of a particular mobile device through the Crypto SE 140 while permitting changes to be made to the App SE 145 without requiring additional certification(s) or re-certification of the mobile device. Splitting the Crypto SE 140 from the App SE 145 may also reduce the likelihood of security information on the Crypto SE 140 being compromised by viruses, Trojans, key loggers and the like that may find their way onto the App SE.
The App SE 145 is configured to store various resident financial transaction applications 155, each of which may facilitate financial transactions for a different financial service provider 125. Such applications 155 may include, for example, a PayPal and/or other payment applications provided by alternative service providers and which facilitate financial transactions over a network 105. In one embodiment, the App SE 145 is a dynamic SE configured to permit application(s) to be managed and modified as needed through, for example, OTA management. Typically, the App SE 145 will not include any payment instruments, certificates, keys or credentials, all of which may be stored in the separate Crypto SE 140.
Although certain credentials or other sensitive data may be dynamic, the Crypto SE 140 is configured primarily as a static SE. The Crypto SE 140 may be configured for loading and storing credentials, payment instruments 191, certificates, crypto keys and other security-related information, including, for example, unique biometric authentication information related to a specific user. The Crypto SE 140 may provide verification and authentication 196, 197 for multiple applications 155 stored in the App SE 145.
In one embodiment, the mobile device 100 may include a biometric sensor 160, e.g., a thumbprint sensor, to provide biometric information to the Crypto SE 140 for transactional security. In alternative embodiments, the biometric sensor 160 may be any sensor that provides unique user identification by biometric means, including for example, retina scan, voice identification, etc. As used herein, the term biometric sensor refers not just to the physical sensor that senses biometric data, but to the arrangement of the sensor, logic, algorithms, and the like that collectively sense and generate a data signal or signals representative of the user being biometrically sensed.
The sensed biometric data from the biometric sensor may be tunneled through a biometric tunnel 165 and may be received by the Crypto SE 140. A biometric authorization application 170 may reside on the Crypto SE 140 to evaluate the biometric data and compare the data to data from a registered user, or may register the data where the data is being collected as part of a registration or certification procedure.
In one embodiment, the Crypto SE may be certified, for example by a credit processing company such as MasterCard or VISA. The Crypto SE 140 may be certified, for example, using the biometric sensor and biometric authorization application 170. Once the Crypto SE portion is certified, the mobile device 100 is certified for use.
In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). A TSM 120 may act as the CA. The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at the CA. A Registration Authority (RA) assures this binding. For each user, the user identity, the public key, binding, validity conditions and other attributes are stored on the certificates issued by the CA.
As shown in FIG. 4, a cryptographic key-pair may be pre-loaded on a Crypto SE 140 of the mobile device 100. For example, an X509 key-pair 175, EMV (Europay, MasterCard, VISA) 180, or ECC 185 may be pre-loaded on the Crypto SE 140. A TSM Root CA certificate 190 may also be pre-loaded in a Crypto SE 140 of the mobile device 100. In addition, a financial transaction application 155 such as a PayPal application or other payment application may be pre-loaded on the App SE 145. In one embodiment, all applications may be registered and deployed using a TSM public key. An application may include instructions for periodically checking whether an update to the application is available. If the update is available and customer verification is approved, applications are downloaded and the signature is verified. Once the signature is matched the new application is activated.
In one embodiment, a user may unlock a payment credential pre-loaded on the mobile device 100 by registering the user's unique biometric profile using the biometric sensor 160. In this regard, the credential may be unlocked, for example, by registering a thumb-print twice using a thumb-print/finger print biometric sensor.
FIG. 6 is a flow chart showing one embodiment of secure customer registration 600 of a mobile device for financial transactions at a POS over a network. As illustrated in FIG. 6, when registering a mobile device 100, payment credentials (account number, credit card number, etc.) are first unlocked, such as with a thumbprint or other biometric technique, to enable a pre-loaded payment application (step 605). The pre-loaded payment application may be associated with a payment provider such as PayPal. Enablement of the pre-loaded payment application causes a SCEP/CRMF (Simple Certificate Enrolment Protocol/Certificate Request Message Format) or similar certificate request protocol to be invoked (step 610). A user's TSM credential(s) such as user name and password is entered and associated with the payment provider's user account information stored in the payment application (step 620 and step 630). A random counter 195 or timestamp 200 may be generated and stored in the Crypto SE 140 for counter based replay protection (step 660). The timestamp, user's credentials or associated account information, and phone information, e.g., IMEI number, as well as the certificate request protocol is sent to the TSM OTA and a phone certificate may be issued to the mobile device for registration of the phone (step 640 and step 650).
FIG. 7 is a flow chart showing one embodiment of payment instrument 191 deployment to a mobile device for payment at a point-of-sale 700. Payment account numbers such as associated with credit or debit cards may be deployed to a mobile device OTA for payment to an offline merchant using the payment/service provider account. For example, a payment account number may be generated by the payment/service provider along with a CVV (card verification value). In one embodiment, a payment instrument request is transmitted from the mobile device 100 to the TSM 120 (step 705). In response, a payment account number 710, a CVV 711, and a counter/timestamp (to prevent replay attacks) 712 may be SMS encrypted using the public key 713 of the mobile phone, signed using the TSM's private key 714, and sent to the mobile device 100 (step 720). The counter/timestamp may be checked and the payment account number 710 and the CVV 711 (payment instruments 191) may be stored in the Crypto SE 140 of the mobile device 100 (step 725). The mobile device 100 is now able to make payments (step 730). The payment account number 710 may also be obtained from the service provider 125, such as from a representative, either by phone, e-mail, or other method of inquiry as may be required for entry of the account number when making a payment (step 730). In this regard, a customer may manually enter an account number, obtain as indicated above, using a keypad on the mobile device. This may be done after activating the biometric credential and registering the mobile device. The application may then load the Crypto SE 140 with a payment instrument identified by its account number.
In one embodiment, instead of entering a PIN on a POS keypad or making a signature at a POS electronic signature screen as is currently done, a customer may enter a POS PIN directly onto a keyboard 198 on their mobile device 100. In this regard, a user may authenticate their mobile device 100 for secure keyboard PIN entry using the biometric sensor 160 and biometric authentication application 170 on their mobile device 100. Biometric authentication of the mobile device 100 may create a secure tunnel 165 from the keyboard to the Crypto SE 140 on the mobile device 100. The user may then enter a PIN on a keyboard on the mobile device 100.
Banking regulations do not allow entering a PIN in a non-encrypted PIN pad. As such, in one embodiment, the mobile device PIN pad has an encrypted PIN pad mode where PIN is tunneled directly to Crypto SE. The SE will behave as Chip and PIN Authentication and/or as ARQC-ARPC.
In one method of conducting a NFC transaction at a point of sale POS a customer may prepare a mobile device for use, for example by opening the mobile phone. The user may select a “Payment” function on the mobile device by selecting a corresponding payment button, utilizing voice recognition technology, or any other appropriate method of selection as appropriate for a particular mobile device.
Selecting “Payment” may prompt a payment application 155 on the mobile device 100 to check the biometric sensor 160 for biometric input. For example, a user may place their thumb on a thumb/finger print sensor or swipe their thumb on a biometric input. The biometric input may be directly linked to the Crypto SE 140 via tunnel circuitry 165. The tunnel circuitry 165 may be FIPS 140-2 level 3 compliant and may be arranged so that biometric data, for example thumbprint data, is input directly into the Crypto SE 140 for authentication/unlocking. Using the tunnelling circuitry 165 to input biometric data directly into a Crypto SE 140 may improve the security of a transaction over devices without such a tunnel circuitry, e.g., where the architecture is such that biometric data may be captured by any application on the mobile device 100. In this regard, tunnelling the biometric data to a separate Crypto SE 140 may improve security of a transaction and prevent compromising a user's unique identifying information. The App SE 145 may then send a request to the Crypto SE 140 for payment information.
Once a user's biometric identity is authenticated properly, the Crypto SE 140 may then send payment or other information to the App SE 145. The payment information may then be sent to Comm/NFC chip 135 and POS by NFC technology when customer taps on POS. The payment information may include payment information and the CVV.
In implementation of the various embodiments, the mobile device may comprise a personal computing device, such as a personal computer, laptop, PDA, cellular phone or other personal computing or communication devices. The payment provider system may comprise a network computing device, such as a server or a plurality of servers, computers, or processors, combined to define a computer system or network to provide the payment services provided by a payment provider system.
In this regard, a computer system may include a bus or other communication mechanism for communicating information, which interconnects subsystems and components, such as processing component (e.g., processor, micro-controller, digital signal processor (DSP), etc.), system memory component (e.g., RAM), static storage component (e.g., ROM), disk drive component (e.g., magnetic or optical), network interface component (e.g., modem or Ethernet card), display component (e.g., CRT or LCD), input component (e.g., keyboard or keypad), and/or cursor control component (e.g., mouse or trackball). In one embodiment, disk drive component may comprise a database having one or more disk drive components.
The computer system may perform specific operations by processor and executing one or more sequences of one or more instructions contained in a system memory component. Such instructions may be read into the system memory component from another computer readable medium, such as static storage component or disk drive component. In other embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.
Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to the processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media includes optical or magnetic disks, such as disk drive component, volatile media includes dynamic memory, such as system memory component, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave, or any other medium from which a computer is adapted.
In various embodiments, execution of instruction sequences for practicing the invention may be performed by a computer system. In various other embodiments, a plurality of computer systems coupled by communication link (e.g., LAN, WLAN, PTSN, or various other wired or wireless networks) may perform instruction sequences to practice the invention in coordination with one another.
Computer system may transmit and receive messages, data, information and instructions, including one or more programs (i.e., application code) through communication link and communication interface. Received program code may be executed by processor as received and/or stored in disk drive component or some other non-volatile storage component for execution.
Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.
Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
The foregoing disclosure is not intended to limit the present invention to the precise forms or particular fields of use disclosed. It is contemplated that various alternate embodiments and/or modifications to the present invention, whether explicitly described or implied herein, are possible in light of the disclosure.

Claims

1. Method of mobile device registration over-the-air (OTA) comprising:

enabling a pre-loaded payment application having payment account information;

enabling a certificate request;

receiving payment credentials;

associating the payment credentials with the payment account information;

transmitting the payment account information and the certificate request OTA; and

receiving a certificate of registration by the mobile device OTA.

2. The method of claim 1, further comprising unlocking the payment credentials prior to receiving the payment credentials.

3. The method of claim 2, wherein unlocking the payment credentials further comprising receiving a biometric input.

4. The method of claim 3, wherein the biometric input includes one of a fingerprint, a retinal scan, or voice recognition.

5. The method of claim 1, wherein enabling the certificate request includes one of invoking a simple certificate enrollment protocol (SCEP) or a certificate request message format (CRMF).

6. The method of claim 1, wherein the payment credentials are one of a user name or a password.

7. The method of claim 1, further comprising transmitting a counter or a timestamp along with the payment account information and the certificate request.

8. The method of claim 1, wherein at least a portion of the OTA is via near field communication.

9. An apparatus for registration over-the-air (OTA) comprising:

a mobile device adapted to enable a pre-loaded payment application having payment account information; enable a certificate request; receive payment credentials; associate the payment credentials with the payment account information; transmit the payment account information and the certificate request OTA; and receive a certificate of registration for the mobile device.

10. The apparatus of claim 9, wherein the mobile device is adapted to unlock the payment credentials prior to receipt of the payment credentials.

11. The apparatus of claim 10, wherein the mobile device is adapted to unlock the payment credentials upon receipt of a biometric input.

12. The apparatus of claim 11, wherein the biometric input includes one of a fingerprint, a retina scan, or voice recognition.

13. The apparatus of claim 9, wherein the certificate request includes one of a simple certificate enrollment protocol (SCEP) or a certificate request message format (CRMF).

14. The apparatus of claim 9, wherein the payment credentials are one of a user name or a password.

15. The apparatus of claim 9, wherein the mobile device is adapted to transmit a counter or a timestamp along with the payment account information and the certificate request.

16. The apparatus of claim 9, wherein at least a portion of the OTA is via near field communication.

17. A method of payment instrument deployment to a mobile device for payment at a point-of-sale (POS) comprising:

transmitting a payment instrument request from a mobile device;

receiving data including a payment instrument and a card verification value (CVV) by the mobile device; and

storing the payment instrument and card verification value in a secure element of the mobile device for payment at a POS.

18. The method of claim 17, wherein the payment instrument is a payment account number.

19. The method of claim 17, wherein the payment instrument and the CVV is encrypted using a public key of the mobile device and signed using a private key of a payment/service provider system.

20. The method of claim 17, wherein the data further includes counter or timestamp information to prevent replay attacks.