This application is a divisional application of patent application No. 201280069962.1, filed on day 2012, 12/19, entitled "system and method for dynamic provisional payment authorization in a portable communication device", and this application 201280069962.1 is a chinese national phase application of PCT application PCT/US2012/070683, claiming priority of U.S. provisional patent application No. 61/577,652, filed on day 2011, 12/19, and U.S. non-provisional patent application No. 13/448,193, filed on day 2012, 4, 16, 2012, each of which is incorporated herein by reference in its entirety.
Detailed Description
The present invention now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The present invention may be embodied as methods or devices, among other things. Accordingly, the present invention and elements thereof may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
Portable communication device
The present invention provides systems and methods that may be used with a variety of different portable communication devices, including but not limited to PDAs, mobile phones, smart phones, laptops, tablets, and other mobile devices that preferably include cellular voice and data services and that preferably access consumer downloadable applications. One such portable communication device may be an iPhone, motorola RAZR, or a DROID; however, the present invention is preferably platform and device independent. For example, the portable communication device technology platform may be Microsoft Windows Mobile, microsoft Windows Phone7, palm OS, RIM Blackberry OS, apple OS, android OS, symbian, java, or any other technology platform. For purposes of this disclosure, the present invention has been described in terms of features and interfaces optimized for smartphones using a common platform, but those skilled in the art will appreciate that all such features and interfaces may also be used and adapted for any other platform and/or device.
The portable communication device includes one or more short-range electromagnetic communication devices, such as NFC, RFID or bluetooth transceivers. It is presently preferred to use an NFC baseband compatible with the NFC IP1 standard (www.nfcforum.org) which, when paired with a secure element on a portable communication device and presented in front of a "contactless payment reader" (see point of sale below), provides standard functionality like peer-to-peer data exchange, reader mode (i.e., collecting information from an RFID tag), and contactless card emulation (emulation) (per NFC IP1 and ISO14443 standards). As will be appreciated by those skilled in the art having the benefit of the present description, drawings and claims, the NFC IP1 standard is merely a presently preferred embodiment and may be output-in whole or in part-for use in connection with any other close range communication standard. More preferably, the portable communication device comprises an NFC/RFID antenna (compliant with NFC IP1 and ISO14443 standards) to enable near field communication. However, as should be appreciated, NFC/RFID communication may be used, although there are even shorter ranges and possible reading issues.
The portable communication device also includes a mobile network interface to establish and manage wireless communications with a mobile network operator. The mobile network interface communicates with the mobile network of the mobile network operator using one or more communication protocols and technologies including, but not limited to, global system for mobile communications (GSM), 3G, 4G, code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), user Datagram Protocol (UDP), transmission control protocol/internet protocol (TCP/IP), SMS, general Packet Radio Service (GPRS), WAP, ultra Wideband (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMAX), SIP/RTP, or any of a variety of other wireless communication protocols. Thus, the mobile network interface may include a transceiver, transceiving device, or Network Interface Card (NIC). It is contemplated that the mobile network interface and the short-range electromagnetic communication device may share a transceiver or transceiving device as will be understood by those of skill in the art having the present specification, drawings and claims herein before.
The portable communication device also includes a location transceiver that can generally determine the physical coordinates of the device on the surface of the earth as a function of latitude, longitude and altitude. Such a location transceiver preferably uses GPS technology, so it may be referred to herein as a GPS transceiver; however, it should be understood that the location transceiver may additionally (or alternatively) employ other geolocation mechanisms, including but not limited to triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS or similar mechanisms to determine the physical location of the portable communication device on the surface of the earth.
The portable communication device also includes a user interface that provides some means for the consumer to receive information and to enter or otherwise respond to the received information. Such user interfaces may include a microphone, audio speaker, tactile interface, graphical display, as well as a keypad, keyboard, pointing device, and/or touch screen, as presently understood (without intending to limit the invention thereto). The portable communication device also includes a microprocessor and a high performance memory. The high performance memory may include, for example, ROM, RAM, and one or more removable memory cards. The mass memory provides storage for computer readable instructions and other data, including a basic input/output system ("BIOS") and an operating system for controlling the operation of the portable communication device.
The portable communication device also includes a device identification memory, such as a SIM card, dedicated to identifying the device. As is commonly understood, the SIM card contains the unique serial number (ESN) of the device, the international unique serial number (IMSI) of the mobile subscriber, security authentication and encryption information, temporary information relating to the home network, a list of services the subscriber has accessed, and two passwords (PIN code and PUK code for unlocking, which are commonly used). As will be appreciated by those skilled in the art having the present specification, drawings, and claims, and the like, other information may be retained in the device identification memory depending on the type of device, its prevailing network type, the local mobile network operator, and the like.
The portable communication device may have two subsystems: (1) A "wireless subsystem", which enables communication and other data applications, has become popular among users of today's mobile phones, and (2) a "secure transaction subsystem", which may also be referred to as a "payment subsystem". The secure transaction subsystem will include a secure element and associated device software for communicating to the management and provisioning system, and a user-oriented interface for using and managing the secure data stored in the secure element. It is contemplated that such a secure transaction subsystem would preferably include a secure element similar, if not identical, to that described as part of the global platform 2.1.X, 2.2, or 2.2.X (www.globalplatform.org). The secure element has been implemented as a dedicated, separate physical memory for use with industry common practice of storing payment card track data with industry common points of sale; in addition, other security credentials that may also be stored in the secure element include employee badge credentials (enterprise access controls), hotels and other card-based access systems, and pass credentials.
Mobile network operator
Each portable communication device is connected to at least one mobile network operator. Mobile network operators typically provide a physical infrastructure that supports wireless communication services, data applications, and secure transaction subsystems via multiple cell towers communicating with multiple portable communication devices within an associated area (cell) of each cell tower. In turn, the cell tower may be in operative communication with the mobile network operator's logical network, POTS, and the internet to communicate communications and data within the mobile network operator's own logical network, as well as to external networks including those of other mobile network operators. Mobile network operators typically provide support for one or more communication protocols and technologies, including but not limited to global system for mobile communications (GSM), 3G, 4G, code Division Multiple Access (CDMA), time Division Multiple Access (TDMA) systems, user Datagram Protocol (UDP), transmission control protocol/internet protocol (TCP/IP), SMS, general Packet Radio Service (GPRS), WAP, ultra-wideband (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMAX), SIP/RTP, or any of a variety of other wireless communication protocols, to communicate with portable communication devices.
Retail subsystem
Today's merchant standard is an internet protocol connected payment system that allows transaction processing for debit, credit, prepaid and gift type products of banking and commercial service providers. By swiping a magnetic stripe enabled card through a magnetic reader at a point of sale (or point of purchase) terminal, the data within the card is transmitted to the point of sale equipment and used to confirm the funds by the issuing bank. Such point-of-sale equipment has begun to include a contactless smart card reader as an accessory, allowing payment card data to be presented on an RF interface in place of a magnetic reader. Data is transferred over an RF interface by the ISO14443 standard and proprietary payment applications like PayPass and payWave to the reader, which transmits the non-card data from the card and future mobile devices including the payment subsystem.
The merchant's point-of-sale device 75 may be connected to the merchant payment network through a wireless or wired connection. Such point-of-sale networks may include the internet in addition to Local Area Networks (LANs), wide Area Networks (WANs), direct connections, such as through a Universal Serial Bus (USB) port, other forms of computer-readable media, or any combination of the preceding. On a set of LANs that are related to each other, including those based on different architectures and protocols, a router acts as a link between LANs, enabling information to be sent from one to another. Additionally, the communication links within a LAN typically comprise twisted wire pairs or coaxial cable, and the communication links between networks may utilize analog telephone lines, full or partial dedicated digital lines, including T1, T2, T3, and T4, integrated Services Digital Networks (ISDN), digital Subscriber Lines (DSL), wireless links, including satellite links, or other communication links known to those skilled in the art. In addition, remote computers and other related electronic devices can be remotely connected to either LANs or WANs via a modem and temporary telephone link. In essence, the point-of-sale network may utilize any communication method that allows information to be disseminated between the point-of-sale device and the financial service provider in order to validate, authenticate and ultimately obtain the financial transaction through the same financial service provider for payment at the point of transaction.
System management back end
The system includes a system management backend. As shown in fig. 1B, the system management backend 300 is connected to a retail subsystem (see point-of-sale device 75), a secure transaction subsystem (consisting of one or more financial service providers) 310, and a plurality of portable communication devices 50 via at least one mobile network operator's infrastructure. The system management backend 300 includes a server in operable communication with one or more client devices. The server is also in operable communication with retailer subsystem 75, secure transaction subsystem 310, and one or more portable communication devices 50. Any type of voice channel may be used in connection with the present invention, including but not limited to VoIP.
The server of the system management backend 300 may include one or more general purpose computers executing programs and functions required to run the system backend in series or in parallel on the same computer or on a local or wide area network distributed over multiple computers, and may even be located in a "cloud" (preferably subject to regulations for adequate security). One or more computers including a server may be hosted by Linux,Windows CE, unix, or @ -based>An operating system, etc. The system management back end server is operatively associated with a mass storage that stores program code and data. The data may include one or more databases, text, spreadsheets, folders, files, etc., which may be configured to maintain and store a repository, user identifiers (ESN, IMSI, PIN number, phone number, email/instant messaging address, billing information, etc.).
The system management back-end server may support a case management system to provide call communication connectivity and distribution on client computers at the customer service center. In a preferred method of voice channel connectivity using VoIP, the case management system is released by Contactual, inc. The contact system is a standard CRM system for VoIP based customer service call centers, which also provides flexibility in handling service issues of simultaneous payment and service concerns related to cell phones. As will be appreciated by those skilled in the art having the benefit of the foregoing description, drawings and claims, other case management systems, such as salesform (san francisco, salesform. Com limited) and Novo (va, novosolutions limited), may be used in the present invention.
The system management back end server also supports a publication engine 2010, a user unique identification database 2011, a merchant geographic location categorization database 2012, and a predictive transaction module 2015. These elements will be described later in this specification.
Each client computer associated with the system management back-end server has a network interface device, a graphical user interface, and voice communication capabilities that match the voice channels supported by the customer service center server, such as VoIP. Each client computer may request the status of both the cellular and secure transaction subsystems of the portable communication device. Such states may include soft memory and core capabilities of the portable communication device, the NFC component: the baseband, the NFC antenna, the state of the secure element and the content of the identification.
Payment subsystem
As shown in fig. 2, each portable communication device 50 may include a one-time payment wallet 160, a payment vault 110, a secure element 120, an NFC (or RF) baseband, a payment subsystem 150 (i.e., secure data storage 115 and secure element 120), and a diagnostic agent 170. The one-time payment wallet 160 is a computer application that enables any portable communication device to request and emulate the credentials associated with the NFC/RF baseband (e.g., cards, coupons, access controls, and ticket data) that are downloaded to the device 50 (preferably into the payment subsystem 150) for temporary use. Applications may also be implemented on legacy feature phones (non-smart phones) using WAP, J2ME RTE and/or SMS channels instead of smart phones. As will be discussed more fully below, the credentials are most preferably NFC-based, but may also be RFID,2-D bar code or Arabic number based.
The payment vault 110 is used by the one-time payment wallet 160 to manage (and housekeeping thereon) the secure element 120, communicate with the system administration backend 300 and perform over-the-air (OTA) configuration on the device 50 via a data communication transceiver (including its SMS channel). It is contemplated that OTA data communications will be encrypted in some manner and that encryption keys will be deployed in card service modules operatively associated with portable communication device 50 and with payment subsystem 150. In one embodiment, the card service module is operably connected to a one-time payment wallet 160 (deployed as a third party application as described below) and a payment subsystem 150. The card service module typically enforces access control to data stored in the payment subsystem 150 and controls the functionality of each application that is allowed to run in the payment subsystem 150. In one embodiment, the card service module authenticates the author/publisher of each third party application used on the portable communication device (as generally described below). The payment subsystem 150 may be used to store credentials, such as temporary one-time payment cards, coupons, access controls, and ticket data (e.g., transportation ticket data, concert ticket data, etc.) among other payment cards. Some of these credential types may be added to the payment subsystem and payment vault as appropriate.
The secure data store 115 provides secure storage on the portable communication device. Different levels of security may be provided depending on the nature of the data expected to be stored in the secure data store 115. For example, the secure data store 115 may simply be an operating system level cryptographic protection of the device 50. As is known in these operating systems, the password may be a simple alphanumeric or hexadecimal code stored somewhere in the storage device 50. Alternatively, the data in the secure data store 115 is preferably encrypted. More likely, however, the Secure data store 115 will be provided as a Virtual Secure Element in the manner disclosed in co-pending patent application Ser. No. 13/279147 (owned by the assignee of the present application) entitled "System and Method for Providing A Virtual Secure Element on a Portable Communication Device", filed on 21.10.2011 and incorporated by reference.
One-time payment via smartphone
Since some point-of-sale devices do not accept NFC payments and some users do not set up NFC accounts, the present invention enables any portable communication device to make highly secure electronic payments via their existing point-of-sale devices at merchants that accept traditional electronic payments.
To pay a retailer once using the system, the consumer should have downloaded a one-time payment wallet application and have at least one existing account with the designated bank. The consumer should also have registered at least one account with the one-time payment issuer 310 (which may also be a designated bank). In addition, consumers should also have the mobile data services of their smart phones (or portable communication devices 50).
Due to the temporary nature of the credentials and their combination with geographic location confirmation, the one-time payment wallet 160 may eliminate some of the complexities involved in the storage, maintenance, and use of credentials. Possible actions that may be controlled by the one-time payment wallet 160 are actions associated with:
a. wallet management (e.g., setting, resetting, or enabling wallet passwords; obtaining URL of OTA server; wireless communication registration configuration; setting payment time; increasing payment time; setting default cards; listing issuers, memory audit lists; determining SE for storing credentials; updating wallet state);
b. voucher management (e.g., add voucher; view voucher details; delete voucher; activate voucher (redemption/payment); deactivate voucher; lock/unlock voucher; request password access; obtain voucher image; set access password); and
c. secure Element (SE) management (e.g., obtain credentials; update metadata; delete credentials; wallet lock/unlock; SE lock/unlock).
Figures 3A-3B together illustrate one possible embodiment (and various possible alternatives) of a process for obtaining and using one-time payment credentials using a one-time payment wallet 160. Consumers may carry their smart phones (i.e., portable communication device 50) into physical retail stores and perform their shopping experience as usual. The one-time payment wallet 160 is downloaded on their smartphone and the consumer can even use their smartphone payment with the legacy system by opening the solution-enabled smartphone application when the consumer is ready to check out at the physical retail store.
The consumer goes to the point of sale 75, opens the one-time payment wallet 160 on the smartphone 50, and enters the consumer's password/passcode through the user interface on the one-time payment screen (see fig. 5). The one-time payment wallet 160 sends the consumer's password and geographic location coordinates (generated by the location identification service 165, fig. 2) to the publication engine 2010 (fig. 4). In one embodiment, the one-time payment wallet 160 may also provide the consumer with the ability to communicate an estimated amount of the upcoming payment to the posting engine 2010 prior to generating information for the temporary payment card. By incorporating the estimated amount information on the one-time payment into the validation process, additional security can be provided for the one-time code.
The publishing engine 2010 validates the password (e.g., using the user unique identification database 2011). Receipt of the correct passcode indicates that the system consumer will make a payment within a short predetermined period of time (on the order of a few minutes, which may be extended in some cases). The publishing engine 2010 uses the geographic location coordinates received from the portable communication device 50 to determine possible merchants and to look up point of sale details of the merchants (e.g., the merchant geographic location collection database 2012) in a database operatively associated with the publishing engine 2010. In particular, based on the received geographic location information, the publication engine 2010 performs database queries to determine which contactless point-of-sale terminals the consumer location is installed (or is likely to be installed). In a preferred embodiment, the portable communication device 50 may also display a list of the most likely retail stores (e.g., the next top five) in which the portable communication device 50 may be located next (see, e.g., fig. 6A). Based on the identified location and/or point of sale terminal, the card services module of portable communication device 50 configures payment system 150 with a data format specific to that location and/or point of sale and other non-connected point of sale data to enable device 50 to be supported or optimized for presentation of the card, coupon, ticket, or access control simulation. The system may also identify consumer new card products that are available for that geographic location without the consumer having downloaded in the payment repository 110. In some embodiments, the system may load the required libraries.
The posting engine 2010 includes a database of all e-payment accepting merchants (e.g., a merchant geographic location collection database 2012) that may include merchant locations, merchant identification numbers used in conventional e-payments, conventional payment schemes accepted by each merchant location, and device performance capabilities for the point of sale for each merchant location (see table 1 below). Although the merchant geolocation collection database 2012 is described as being included in or otherwise part of the publication engine 2010, it is contemplated that the merchant geolocation collection database 2012 may be included within the portable communication device 50, the publisher 310, be part of the portable communication device 50, the publisher 310, or be associated with the portable communication device 50, the publisher 310, or be carried separately.
Table 1-embodiments of merchant and one-time payment information
The issuing engine 2010 then generates a one-time-use temporary payment card and transmits the temporary payment card data and possibly the identity of the merchant to the portable communication device 50 via wireless communication. Such temporary payment card information may be formatted in real-time using existing standards and conventions of the traditional electronic payment industry, including personal account numbers, issuer identification numbers, ISO/IEC7812 (involving issuer identifications using Issuer Identification Numbers (IINs) to operate in international, inter-industry, and/or intra-industry exchanges), ISO/IEC7813 (involving data structures and contents of tracks for initial financial transactions), and ISO8583 formats (which are enterprise messaging protocols, based on proprietary (proprietary) standards).
In a preferred embodiment, the disposable payment wallet 160 formats the temporary payment card based on the capabilities of the portable communication device 50 and the capabilities of the merchant's point-of-sale device 75. The temporary payment card information may also be formatted in a variety of formats to provide the consumer with options that may be presented to the merchant cashier. Fig. 7A and 7B illustrate two possible types of one-time payment codes that may be transmitted to the portable communication device 50. FIG. 7A depicts the one-time pay code as a 2-D barcode. As will be appreciated by those of ordinary skill in the art, such a barcode may be a 3-D or QR code. Fig. 7B depicts the one-time pay codes as numeric codes, which may be 16-digit numbers or have different lengths as desired.
One format in which temporary payment card information may be displayed on a smartphone screen is ISO/IEC7813 standard number (i.e., PAN), which is manually entered into the merchant point of sale by a merchant clerk. Another format in which the transient payment card information may be displayed on the smartphone screen is a barcode (ISO/IEC 15426-1), a 2-D barcode (ISO/IEC 15426-2), a QR code (ISO/IEC 18004-2006), or other similar method of transmitting ASCII data prior to capture by an optical scanner at the point of sale of the merchant. Also shown in the temporary payment card data may be a format using NFC peer-to-peer mode (ISO/IEC 18092), NFC tag emulation (NDEF, ISO14443 and Felica), or NFC card emulation mode (ISO 14443 card emulation) or RFID mode.
The temporary payment card data expires after a short predetermined period of time, such as two (2) minutes, to provide more security. This time can be extended as long as the publisher wishes. It is believed that less than 30 minutes or even less than 20 minutes or even 10 minutes will be preferred. Other expiration times may be used and/or programmed as desired.
Portable communication device 50 receives the temporary credential data, possibly merchant and mock information from publishing engine 2010. In a preferred embodiment, the portable communication device 50 confirms that the possible merchants are properly selected from the database 2012. In one method, illustrated in connection with fig. 6, the portable communication device requests the user to confirm the location. In this exemplary illustrative embodiment, the IS user interface asks whether the location IS "Grocery land"? When the consumer is shown in FIG. 1 as being located in Grocery land, the consumer should select the "YES" button on FIG. 6. If the system has selected the wrong retailer, the system may provide an alternative to ensure the correct retailer. For example, FIG. 6A depicts providing a list of possible merchants near the consumer in an example, where the one-time credentials are required from within a place identified by the publishing engine 2010 as a mall (or other high-density group of merchants). As will be appreciated by those skilled in the art having the benefit of the present description, drawings, and claims, the listing of nearby merchants need not be limited to those in a single store. Alternatives may be selected from other retailers geographically close to the geographic location received by the server. As will also be appreciated, alternatives may be presented to the end user in the form of a drop down menu or list.
In embodiments where the consumer confirms the merchant using the portable device 50, confirmation of the potential merchant may be received by the posting engine 2010. If a potential merchant is incorrectly identified, the distribution engine may distribute new simulation information to portable communication device 50. Once a possible merchant is known, the predictive transaction module 2015 of the publishing engine 2010 transmits the possible merchant's ID, the unique user ID associated with the portable communication device 50, the one-time-use token (token) generated for the transaction, and the expiration time to the verification mapping gateway 2020.
The verification mapping gateway 2020 may be physically hosted by a bank, issuer 310, or payment processor network and may be deployed as a service or installed and integrated into subsystems of existing transaction processors, card systems, financial institutions, and other entities. When data is received from the predictive transaction module 2015, the received data is stored in a database associated with the validation mapping gateway. When such data is provided, the temporary data may be associated with legacy card data previously associated with the unique user ID. If a conventional card-unique user ID association exists, it may be created by the issuer 310 or even directly by the consumer in an electronic transaction between the portable communication device 50 and the verification mapping gateway 2020 arranged by the system administration backend 300.
In a preferred embodiment, the predictive transaction module 2015 sends data to the validation mapping gateway 2020 while one-time-use credential information is transferred to the portable communication device 50. In this approach, the verification mapping gateway 2020 may anticipate consumer transactions from the merchant POS75 via the merchant payment network. In particular, in such an embodiment, the verification mapping gateway 2020 may use the time between receiving data from the predictive transaction module 2015 and receiving a transaction from the merchant point of sale 75, fetching the stored data from the large database and placing it in memory to provide faster access (compared to the access time from the large database) and comparison between the stored data and the data received from the merchant payment network. In this approach, adding this additional verification step in the verification mapping gateway 2020 results in less latency than would otherwise be required to locate and retrieve data after receiving a transaction from the POS75 for such a comparison.
So returning to the consumer, after the portable device 50 receives the temporary credential and the emulation information, the consumer can then click on or otherwise activate the smartphone 50 on the NFC enabled point-of-sale device 75, which will cause the portable communication device to emulate the credential with the one-time payment code using the emulation protocol provided by the server. It will be appreciated that the code may be visually "simulated" on the screen of the portable communication device 50. Since the temporary payment card data may be provided in a conventional format, the temporary payment card data may be accepted by the existing merchant point of sale device 75.
The point-of-sale device 75 then processes the temporary payment card data through the normal merchant payment network as if it were a standard credit or debit instrument. However, since the temporary payment card data is registered and mapped to the issuer identification number (ISO IEC 7812) of the one-time payment system provider as the issuer, the data will be routed to the verification mapping gateway 2020 via the merchant payment network. If the data is received by the authentication mapping gateway 2020 before the provisional credential expiration time expires and from the prospective potential merchant, the authentication mapping gateway 2020 may approve the transaction (subject to funds availability, etc.). The verification mapping gateway 2020 may also compare the method by which the payment card data is entered into the merchant point of sale device 75 (existing ISO8583 specified domain) with the method by which the temporary card data is provided to the mobile phone (e.g., digital code, barcode, NFC).
Again, if all required characterizations match (e.g., temporary code, execution time, merchant ID, and emulation type), the authentication mapping gateway may return an acknowledgement to the merchant with an approval code through the merchant payment network. The merchant point of sale 75 receives authorization (i.e., confirms payment acceptance with the approval code), prints a receipt, and the consumer leaves the store with their new purchase.
Optionally, when verifying the temporary payment card information (including time and possibly merchant ID), the system has the option of forwarding an equivalent payment transaction request to the issuer 310 to approve the transaction. This is known as a back-to-back (back-to-back) payment transaction. In this way, the consumer and merchant will obtain payment confirmation from the consumer's traditional bank credit or debit card account, rather than the temporary card number. In particular, once the one-time payment transaction is validated, the validation mapping gateway 2020 replaces the traditional card payment data in the transaction data, which is then passed to the issuer authorization system 310 along with standard POS transaction information (e.g., merchant ID and transaction amount) and, in some embodiments, an indication that the transaction uses validated one-time-use credentials (to show additional security measures). The issuer 310 will audit the conventional card data and transaction information to determine whether the transaction is authorized in a manner known in the art or in addition to information that the transaction already has the additional security indicated above. The issuer authorization is sent back to the merchant point of sale 75 via the normal existing processing channel.
This one-time-use credential solution can be used in many different types of credential verification scenarios, including: credit and debit card payments, gift cards, membership cards, coupons and offers, access control, and other environments where consumers present credentials for authentication in a physical environment.
While the functionality may be integrated within the disposable payment wallet 160, the user interface may be provided through the wallet user interface, while the wireless communication configuration and management and access of the secure payment subsystem is supported by the functions of the card services module. Beneath the user interface, the card service module facilitates wireless communication configuration, secure element management, and direct exchange of keys (for the one-time payment wallet 160 to be the publishing engine 2010) between the card service module on the user's mobile device 50 and the appropriate publisher server in an encrypted manner as previously known in the art.
Verifying one-time payment applications as third party applications
As illustrated in fig. 8A-8B, the one-time payment wallet 160 may be deployed as one of many trusted third party applications 200. The card service module verifies the trusted status of the application 200 before the application is allowed to access the secure element 120 (or the secure data store 115 and even preferably a metadata repository that stores, among other things, card image data and any embossed card data) on the portable communication device 50 to view, select and/or change the secure data stored in the payment subsystem 150. This verification may be accomplished by accessing a local authorization database for the licensed or trusted application. In a preferred approach, the local authorization database is used in conjunction with a remote authorization database associated with one or more servers associated with the system management backend 300.
Figure 10 is a block diagram of one possible embodiment of a possible combination of local and remote authorization databases to improve the security of the card service module, secure element 120 and payment subsystem 150. As shown in fig. 10, a user a/C registry (or user account registry) may be associated with a server (or otherwise deployed in the cloud). The user's a/C registry may store the identity of the secure element 120 provided in each user's portable device 50. An entry in the user account registry may be added for each user at any point in the process.
The "publisher registry" database is a database of approved publishers. The issuer ID is unique for each type of credential. In other words, if the bank has multiple types of credentials (e.g., debit card, credit card, affinity card, etc.), each credential type will have its own issuer ID (e.g., I-BofA-II). In a preferred approach, the issuer ID among multiple types of credentials also has some common elements, thereby indicating that the credentials are at least related (e.g., I-BofA-I). In this way, applications from the same publisher may share data with other applications of the same "extended" publisher. In a preferred approach, the card service module can be simplified by requiring even the wallet user interface (which is system-attached) to have the issuer ID (as well as an application ID and compilation token).
An "application registry" is a database of applications (primarily third parties) that have been previously approved by operating system providers. Like the user a/C registry, the "application registry" and "publisher registry" databases are maintained on the server side (or otherwise in the cloud) in operable association with the one-time payment application. As will be appreciated by one of ordinary skill in the art having the benefit of the present description, the various registries may be implemented in separate databases or unified databases. At the start of the wallet 160 and preferably at substantially regular intervals thereafter (e.g. daily), the data stored in the application registry of the one-time payment wallet 160 is allocated to the device having the wallet to be stored locally.
As shown in fig. 10, the application registry may include, among other things, an application ID ("App ID"), a publisher ID, and a compilation ID or token. The compilation ID is a global constant generated for each application by one or more processes associated with the one-time payment wallet in an authentication process for the particular application. The compilation indicia is included in or otherwise associated with the application after it is generated by the particular card service module of the unique apparatus 50. Such compilation marks are preferably generated by a pseudo-random number generator local to the device, using a predetermined seed (seed), such as an application ID, compilation ID, publisher ID, or some combination thereof.
When a user attempts to authenticate an application with the card service module on device 50, the compilation ID (numerical token) and application ID (numerical identifier) associated with the third party application may be matched against the compilation ID and application ID stored in the card service registry stored on device 50 (see FIG. 10). As will be appreciated by those skilled in the art having the benefit of the present description, the same compilation and application ID pairs are also transmitted to other devices 50 associated with the system. If the compilation ID/application ID pair matches one of the pairs stored in the card services registry on the device, the secret token ID is preferably generated on the device 50 by a pseudo-random number generator (e.g., one associated with the secure element 120) and then stored in the card services registry of the device 50 in association with the compilation ID/application ID pair. In some cases, the compilation ID may be pre-selected and used to seed (seed) the random number generator. It should be understood that one or more blocks of other predetermined data associated with the card service registry may alternatively be preselected as seeds. The card service registry is preferably stored in secure memory (rather than in secure element 120, since secure element 120 has limited real estate), and is also preferably encrypted using standard encryption techniques. The secret token ID is also embedded or otherwise associated with the application 200 on the device 50 in place of the compilation ID assigned with the application 200 on the device 50.
After the one-time payment wallet 160 has been loaded into the card service registry (and the secret token embedded in the application), the one-time payment wallet 160 may launch and possibly prompt the user to opt-in to provide access to the issuer-specific credentials required by the verified (or trusted) application. On each subsequent launch of the one-time payment wallet application 160, the embedded secret token and/or application ID is compared to the data in the card service registry on the device. If there is a match, the application is trusted and can access the payment subsystem 150 through the card service module. In this manner, it can be seen that the application 200 or wallet user interface may also be deleted from the card service registry and thus will not have access to the payment subsystem and may not have access to the application in common.
The card service module also preferably uses a trusted application verification step to determine the appropriate level of subsystem access to allow the one-time payment wallet 160. For example, in one embodiment, an application may be authorized to access and display all data contained in payment subsystem 150, wherein another application may be authorized to access and display only a subset of the data contained in payment subsystem 150. In yet another embodiment, the application may only be allowed to send payment or transaction requests to the one-time payment wallet 160, but not itself allowed to access any data contained in the payment subsystem 150. In one approach, assigning rights to an application can be thought of as follows:
these rights can be used to form 4 hexadecimal numbers in the order shown above from the most significant to the least significant numbers. As shown in the example card service registry of FIG. 10, the I-BofA-II issuer has a privilege level 11111, which can be considered to be an extension to 0001 0001 0001 0001 0001 0001. In other words, the I-BofA-II application reads, writes, deletes, activates/deactivates, and downloads its credentials, but does not extend the issuer credentials, let alone all credentials. If BofA has another publisher code (e.g., I-BofA-I), then this will be an extended publisher application. Thus, if the permission level of the application associated with the publisher ID "I-BofA-II" is set to 0010 0001 0001 0010 0001 (or 21121 hex), the application will be able to read and activate/deactivate credentials associated with both publisher IDs. In another embodiment, the wallet user interface may be given a 44444 (i.e., 0100 0100 0100 0100) permission level. In other words, the wallet user interface can read, write, delete, activate/deactivate, and download all credentials. As one of ordinary skill in the art will appreciate, these are merely examples of possible permissions that may be granted to an application, other permissions are contemplated. For example, some applications may have the ability to read extended publisher credentials, but only write, delete, activate, and download the application's own credentials (e.g., 21111, which extends to 0010 0001 0001 0001 0001 0001). In another embodiment, the application may only be given the right to activate/deactivate and download (i.e., 0000 0000 0000 0001 or 00011, hex). In another embodiment, the application may be dead-but not deleted from the trusted application database or credit card service registry-by setting all rights to zero.
In embodiments where the one-time payment wallet application 160 is configured as one of the trusted third party applications, it will have to register in order to access the open wallet 100 (or even the card service module). The one-time payment wallet application 160 is developed by a publisher associated with the publication engine 2010. Further, the one-time payment wallet application may emulate NFC credentials. Therefore, the one-time payment wallet application 160 should be given the authority level 11111, which can be considered to be expanded to 0001 0001 0001 0001. In other words, the one-time payment wallet application 160 may read, write, delete, activate/deactivate, and download its own credentials, rather than extended issuer credentials or any other credentials.
The foregoing description and drawings relate to a one-time payment wallet 160 and one-time payment credentials or information or temporary payment card data that expires after a short predetermined period of time. However, it is also recognized that the one-time payment wallet 160 may instead be considered a dynamic temporary wallet 160, while the one-time payment credentials/information and temporary payment card data may be considered dynamic temporary credentials. In this way, the credentials can be (1) "recycled" and reused by other users in the system; (2) Have a predetermined validity time longer than the "short" predetermined time period, and (3) these vouchers can be used to more than simply purchase goods. It is also contemplated that while the foregoing description and drawings refer primarily to point-of-sale devices 75 associated with merchants, the foregoing description, drawings, and embodiments may be applicable to various other electronic control points, such as hotel room transceivers, office transceivers, car rental transceivers, and the like. For example, the electronic control point may include any access point, such as a point of sale device, an RFID transceiver, a barcode transceiver, an NFC transceiver, and the like.
In particular, the credentials typically must be "paid" by the issuer 310 or other organization throughout the larger merchant payment system. In this way, the system may only have a limited number of credentials for use. Using only one time for a particular user and transaction may result in unnecessarily high costs compared to systems where payment credentials are recycled by multiple users at different times, and preferably at different geographical locations, to provide additional security against fraud. For example, the publication engine 2010 may track publication and expiration data relating to credentials of a first user operating a first portable communication device 50 at a first geographic location (e.g., state of california), and after the expiration date and time of the credentials, reassign the exact same credentials to a second user operating a second portable communication device 50 at a second, different geographic location (e.g., state of fornia).
Also, the voucher may have a longer validity time to allow use of the voucher at various "points of sale" or other electronic control points. For example, referring to fig. 9A and 9B, an exemplary wallet user interface is displayed on portable communication device 50. The wallet 160 may include and be associated with various payment cards (e.g., master Charge, VISA, charge-It, etc., as illustrated in fig. 9A), and may also include and be associated with various other non-payment applications (e.g., hotel room keys, office key cards, rental FOB, etc., as illustrated in fig. 9B). While the "validity time" period is preferably short in the case of point-of-sale sales to provide enhanced security, it is contemplated that the "validity time" may be significantly longer when the wallet is associated with a non-payment application, such as a hotel room key. In such instances, the wallet 160 may be used to "open" or "lock" the user's room in the hotel. Thus, the "validity time" should be set to be at least the same time as the user's stay at the hotel. Likewise, the validity time may be set for a period of time (unlimited if necessary) to allow a user of device 50 to use device 50 to access an office or car rental.
Thus, it is also contemplated that the system management backend 300 and the publisher 310 may be associated with non-financial services to allow use of non-payment wallet applications. For example, the system management backend 300 may include data related to non-financial services (e.g., hotel locations, office locations, etc.) and data to and from which the publisher 310 may be associated with non-payment entities (e.g., hotel entities, office management entities, etc.).
The foregoing description and drawings merely explain and illustrate the invention and the invention is not limited thereto. While the specification has been described with respect to certain embodiments or implementations, numerous details are set forth for the purpose of illustration. Accordingly, the foregoing is considered as illustrative only of the principles of the invention. For example, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described arrangements are illustrative and not restrictive. As will be realized, the invention is capable of other embodiments or embodiments and its several details are capable of modifications in various obvious respects, all without departing from the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are thus within its scope and spirit.