KR102495688B1 - System and method for dynamic temporary payment authorization in a portable communication device - Google Patents

Abstract

A system for issuing dynamic temporary certificates to a portable communication device for use in transacting with an electronic control point. The system receives the current geolocation of the portable communication device and sends a dynamic temporary certificate from the centralized computer to the portable communication device. The system also uses the issued dynamic temporary certificates to score the risk of authorizing transactions associated with electronic control points. The system may prevent transmission of dynamic temporary certificates until the end user is authenticated. The system may further include a validation mapping gateway operatively connected to one or more issuers that replaces dynamic temporary certificates in payment transactions with legacy payment data prior to sending the payment transaction with the risk score to the issuer associated with the legacy payment data. there is.

Description

System and method for dynamic temporary payment authorization of portable communication device {SYSTEM AND METHOD FOR DYNAMIC TEMPORARY PAYMENT AUTHORIZATION IN A PORTABLE COMMUNICATION DEVICE}

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application Serial No. 61/577,652 entitled "System and Method for One-Time Payments to a Retailer in a Portable Communication Device" filed on December 19, 2011; CIP Application Serial No. 13/448,193 entitled "System and Method for Dynamic Temporary Payment Authorization in a Portable Communication Device" filed on April 16, 2012, which claims Continuation-in-Part), claiming priority to U.S. Patent Application Serial No. 14/052,640 entitled "System and Method for Dynamic Temporary Payment Authorization in a Portable Communication Device" filed on October 11, 2013; The contents of each of these are incorporated herein by reference in their entirety.

The present invention relates generally to the use of secure data to complete wireless transactions, and more particularly to systems and methods for processing temporary electronic payment credentials for use on portable communication devices.

Wireless transactions using RFID-based proximity cards are very common. For example, many workers use RFID keycards to access their workplace and drivers use RFID passes to pay tolls on highways. RFID, which represents radio frequency identification, uses electromagnetic waves to exchange data between a terminal and some object for identification purposes. More recently, companies have attempted to use RFIDs supported by cellular telephones to implement electronic payment products (ie, credit and/or debit cards). However, basic RFID technology poses a number of security issues that have prompted modifications of the basic technology. Still, widespread adoption of RFID as a mechanism for electronic payments has been slow.

Smartphone penetration by consumers is also growing rapidly. A challenge arises as to how to enable consumers to make electronic payments using their existing mobile phones. Near Field Communication technology in phones with built-in secure elements enables one potential solution to this challenge.

Near Field Communication (NFC) is another technology where similar RFIDs use electromagnetic waves to exchange data. NFC is an open standard (eg, see ISO/IEC 18092) that specifies modulation schemes, coding, transmission rates, and RF interfaces. Unlike RFID, NFC transmission and reception relies on electromagnetic coupling of the transmitter and receiver rather than RF propagation. Thus, NFC communication is only possible over short ranges (of the order of a few inches). There has been wider adoption of NFC as a communication platform because it is highly selective and thus requires an intentional physical gesture (eg waving the mobile device in front of the reader device) to enable communication. In this way, NFC provides better security for financial transactions and access control. Other short-range communication protocols are known and can be accepted for use in supporting financial transactions and access control.

NFC devices were already being used to make payments in some point of sale devices. However, many mobile devices do not have the Secure Element hardware commonly used to securely store contactless payment credentials. Accordingly, the present invention seeks to provide a solution that enables any smartphone to make highly secure electronic payments to merchants that accept contactless electronic payments using existing point-of-sale equipment.

Another problem is the myriad of certificate types and communication protocols associated with the various different point-of-sale terminals available. Thus, for example, one merchant may rely on barcode scanning while other merchants may rely on contactless NFC or Bluetooth Low Energy. And the radio protocols required to successfully communicate wirelessly with IBM point-of-sale terminals may be very different from those required to communicate with NCR terminals. Accordingly, some embodiments of the present invention attempt to pre-determine the likely certificate types, point-of-sale redemption methods, terminal device types, and/or communication protocols present at a retail location co-located with the portable communication device. We're going to use geo-location data (if available) to try.

The ability of physical merchants to accept electronic forms of payment has grown considerably in developed countries and is growing rapidly in developing countries as well. The financial industry has developed and deployed stringent systems, methods and requirements for electronic transactions to mitigate and minimize fraudulent activity.

Accordingly, the present invention also seeks to provide one or more solutions to the above opportunities and associated problems that can be understood by those skilled in the art having access to this disclosure.

These and other objects and advantages of the present disclosure will also be apparent to those skilled in the art upon reading these drawings, specification, and claims. All such additional systems, methods, features, and advantages are intended to be included within this description, within the scope of this disclosure, and protected by the appended claims.

For a better understanding of the present disclosure, non-limiting and non-exclusive embodiments are described with reference to the following figures. In the drawings, like reference numbers refer to like parts throughout all the various views unless otherwise specified.
1A illustrates an end user attempting to use his portable communication device to conduct a secure payment transaction at a point of sale.
1B illustrates operative interconnections between an end user's smartphone (ie, a portable communication device) and various subsystems including a system management back end.
2 is a block diagram illustrating some of the logic blocks within a portable communication device that may be associated with the present system.
3A and 3B together illustrate the flow in one potential embodiment of a process for a one-time (ie temporary) payment credential.
4 is a block diagram illustrating information flow between a portable communication device and the rest of the payment ecosystem in relation to the payment process illustrated in FIGS. 3A and 3B.
5, 6, and 6A are examples of representative wallet user interfaces that may be deployed on typical portable communication devices.
7A and 7B are examples of two potential embodiments of one-time payment credentials generated by an exemplary wallet user interface on a typical portable communication device.
8A is a block diagram illustrating some of the logic blocks within a portable communication device that may be associated with the present system.
FIG. 8B is a block diagram illustrating additional details of the "one-time payment wallet" block of FIG. 8A that may be relevant to the present system.
9A and 9B together illustrate one potential embodiment of a user interface that could be implemented on an exemplary smartphone further illustrating the flexibility of one-time certificate functionality combined with a federated wallet. .
9C and 9D add an issuer's ability to communicate directly with users to obtain information that is often too sensitive (eg, "know your customer" and CVV) information that entities do not want to share data with. Another potential embodiment of a user interface that can be implemented in the illustrative portable communication device is illustrated.
10 is a block diagram of one potential implementation of a system for fundamental granting of permissions for a one-time payment app to view, select and/or change secure data stored in the payment subsystem.
11A is a block diagram illustrating information flow between a portable communication device and the rest of the payment ecosystem in relation to an embodiment of the temporary dynamic credential process illustrated in connection with FIGS. 11B and 12 .
11B illustrates the communication flow for obtaining a temporary credential token in one potential embodiment of a process.
12 illustrates a payment communication flow using a temporary credential token in one potential embodiment of a process.
13 illustrates a cryptographic mechanism that may be used in one potential embodiment of a process for obtaining and using temporary electronic credentials.

The present invention will be described in more detail below with reference to the accompanying drawings which form a part of the present invention and which by way of example show specific embodiments in which the present 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 complete and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or apparatuses. Accordingly, the present invention and its components may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Accordingly, the following detailed description should not be taken in a limiting sense.

portable communication devices

Although the present invention includes PDAs, cellular phones, smartphones, laptops, tablet computers, and other mobile devices that include access to cellular voice and data services as well as preferably consumer downloadable applications, It provides a system and method that can be utilized with a variety of different, but not limited to, portable communication devices. One such portable communication device could be an iPhone, Motorola RAZR or DROID; The present invention is preferably platform and device independent. For example, the portable communication device technology platform may be Microsoft Windows Mobile, Microsoft Windows Phone 7, Palm OS, RIM Blackberry OS, Apple OS, Android OS, Symbian, Java, or any other technology platform. For the purposes of this disclosure, the present invention is generally described in terms of interfaces and features optimized for smartphones using a generalized platform, although all such features and interfaces may also be used by those skilled in the art. It will be appreciated that it may be used and adapted for any other platforms and devices.

The portable communication device preferably includes one or more short proximity electromagnetic communication devices, such as NFC, RFID, or Bluetooth transceivers. Peer-to-peer data exchange 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), reader-writer mode ) (i.e. harvesting information from NFC tags), and contactless card emulation (per NFC IP 1 and ISO/IEC 14443 standards), NFC Forum (www.nfc-forum.org) It is currently desirable to use NFC baseband that conforms to industry protocol standards such as those published by , and also conforms to the NFC IP 1 International Standard (ISO/IEC 18092). As will be appreciated by those skilled in the art having read this specification, drawings, and claims, the NFC IP 1 standard may be exported—in whole or in part—for use in connection with any other near field communications standard. , is simply a currently good example. It is further preferred that the portable communication device includes an RFID antenna or NFC antenna (according to NFC IP 1 and ISO 14443 standards and other payment card industry standards such as those promulgated by EMV Co) to enable short-range wireless communications. . However, as understood in the art, NFC as well as RFID communications can be used with a variety of non-conforming antennae and coil designs, potentially over even shorter ranges, albeit with varying communication reliability and other potential interoperability issues. can be achieved using

The portable communication device also includes a network interface for establishing and managing wireless communication with a mobile network operator. Network interfaces include global system for mobile communication (GSM), 3G, 4G, code division multiple access (CDMA), time division multiple access (TDMA), time division synchronous code division multiple access (TD-SCDMA), user datagram (UDP) protocol), TCP/IP (transmission control protocol/Internet protocol), SMS, GPRS (general packet radio service), WAP, UWB (ultra wide band), IEEE 802.11 (WiFi), WiMax (IEEE 802.16 Worldwide Interoperability for Microwave Access) , SIP/RTP, or any of a variety of other wireless communication protocols for communicating with a mobile network operator's mobile network. Accordingly, a mobile network interface may include a transceiver, transceiver device, or network interface card (NIC). As will be appreciated by those skilled in the art upon reading this specification, drawings, and claims, the mobile network interface and proximity electromagnetic communication device may be implemented as a hybrid or combination transceiver or transceiver device. can also be considered.

The portable communication device preferably further includes a location transceiver capable of determining the physical coordinates of the device, generally on earth's surface, as a function of its latitude, longitude and altitude. Since this location transceiver preferably uses GPS technology, it may be referred to herein as a GPS transceiver; The location transceiver may additionally (or alternatively) determine the physical location of the portable communication device relative to the ground by means of triangulation, assisted GPS (AGPS), GLONASS, E-OTD, CI, SAI, ETA, BSS or It should be understood that other geo-location mechanisms may be employed, including but not limited to the like. Altitude can be determined separately by other means, or it can be part of the GPS function. Additionally, position and elevation may be further optimized by a combination of various mechanisms. In selected embodiments, the mobile device's location is inferred or refined by a collection of network identities (eg, discoverable WiFi SSIDs, discoverable Bluetooth beacon IDs, access point MAC addresses). (refine) can be.

The portable communication device further includes a user interface that allows some means for a consumer to receive information as well as enter information or otherwise respond to received information. As currently understood (without intent to limit this disclosure), this user interface includes a microphone, audio speaker, haptic interface, graphical display, and keypad, keyboard, pointing device, and/or touch screen can do. The portable communication device will also include a microprocessor and mass memory. Mass memory may include ROM, flash memory, RAM, non-volatile RAM, as well as one or more removable memory cards. Mass memory provides storage for computer readable instructions and other data, including a basic input/output system (“BIOS”) and operating system for controlling the operation of portable communication devices.

The portable communication device will also include a device identification memory dedicated to identifying the device, such as an electronic serial number (ESN), mobile equipment ID (MEID), international mobile equipment identifier (IMEI). The portable communication device may also include a subscriber identity module, such as a SIM card, or Universal Integrated Circuit Card (UICC) having a SIM application present and configured for network access. As is generally understood, SIM cards contain a unique serial number, the identity of the issuing operator, an internationally unique number of the mobile user (IMSI), secure authentication and encryption information, and temporary information associated with the local network. information, a list of services the user accesses and two passwords (PIN for normal use and PUK for unlocking). As will be appreciated by those skilled in the art upon reading this specification, drawings, and claims, other information may be maintained in the device identification memory, depending on the type of device, its primary network type, home mobile network operator, etc. there is.

Portable communication devices can have two subsystems: (1) a “wireless subsystem” that enables communication and other data applications that are commonplace to cellular telephone users today, and (2) a “payment subsystem”. Also known as "secure transaction subsystem". The secure transaction subsystem includes a secure element and associated device software for communication to management and provisioning systems, as well as a customer-facing interface for use and management of secure data stored in the secure element. It is contemplated that this secure trading subsystem preferably includes secure elements similar (if not identical) to those described as part of Global Platform 2.1.X, 2.2 or 2.2.X (www.globalplatform.org). . The secure element is implemented as a specialized, separate physical memory used in the industry common practice of storing payment card tracking data used in point of sale; Additionally, other security credentials that may be stored in the secure element may include employment badge credentials (corporate access control), hotel and other card-based access systems, and transit credentials. Some portable communication devices may not have a secure transaction subsystem and may not particularly have a secure element.

mobile network operator

Each of the portable communication devices is connected to at least one mobile network operator. A mobile network operator generally provides a physical infrastructure supporting wireless communication services, data applications and a secure transaction subsystem through a plurality of cell towers communicating with a plurality of portable communication devices within each cell tower's associated cell. do. Eventually, cell towers are operable with a mobile network operator's logical network, POTS, and the Internet to deliver 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. could be communication. Mobile network operators typically use GSM (global system for mobile communication), 3G, 4G, CDMA (code division multiple access), TDMA (time division multiple access), UDP (user datagram protocol), TCP/IP (transmission control protocol/ Internet protocol), SMS, general packet radio service (GPRS), WAP, ultra wide band (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMax), SIP/RTP, or various other wide-area communication devices with portable communication devices. or short-range wireless communication protocols.

retail subsystem

The standard on the merchant side today is an Internet Protocol connected payment system that allows banks and merchant service providers to process transactions of debit, credit, prepaid, and futures products. By swiping a magnetic stripe enabled card in the magnetic reader of a point-of-sale (or point-of-purchase) terminal, card data is transmitted to the point-of-sale equipment to verify funds by the issuing bank. used These point-of-sale equipment are beginning to include contactless card readers as adjuncts that allow payment card data to be presented through an RF interface instead of a magnetic reader. Dedicated payment applications such as PayPass and Paywave, which transmit contactless card data from the card or from a mobile device that includes a payment subsystem, and data via an RF interface by the ISO/IEC 14443 standard is sent to the reader.

The retailer's point-of-sale device 75 may be connected to the merchant payment network via a wireless or wired connection. These point-of-sale networks can be connected to the Internet in addition to local area networks (LANs), wide area networks (WANs), direct connections such as through universal serial bus (USB) ports, other forms of computer-readable media, or combinations thereof. can include On an interconnected set of LANs, including those based on different architectures and protocols, a router acts as a link between the LANs, allowing messages to be sent from one side to the other. Also, while communication links within LANs typically include twisted pair or coaxial cable, communication links between networks may include analog telephone lines, fully or partially dedicated digital lines including T1, T2, T3 and T4, Integrated Services Digital Link (ISDN) Wireless links including Digital Networks), Digital Subscriber Lines (DSLs), satellite links, or other communication links known to those skilled in the art may be used. Also, remote computers and other associated electronic devices can be remotely connected to LANs or WANs via modems and temporary telephone links. In essence, a point-of-sale network connects point-of-sale devices and financial service providers for the purpose of validating, authorizing, and ultimately capturing financial transactions at the point-of-sale for payments through the same financial service providers. Any communication method that allows information to be moved may be used.

system management bag end

The system includes a system management back end. As shown in FIG. 1B , the system management back end 300 interfaces with the infrastructure of at least one mobile network operator to a retail subsystem (see point of sale device 75 ), a secure transaction subsystem (one or more financial configured as a service provider) 310, and connected to a plurality of portable communication devices 50. Systems management back end 300 includes a server in operative communication with one or more client devices. The server also operatively communicates with retail subsystem 75 , secure transaction subsystem 310 , and one or more portable communication devices 50 . In connection with the present invention, any type of voice channel may be used, including but not limited to VoIP.

The server of the system management back end 300 implements the procedures and functions necessary to run the system back office serially or in parallel on the same computer, or across a local or wide area network distributed on multiple computers. may include one or more general-purpose computers that implement it, and may even be hosted by a third-party service provider (a service hosting scheme known as “in the cloud”) on hardware connected via the Internet. The computer(s) including the server may be controlled by a Java® based operating system, named Linux, Windows®, Windows CE, Unix, or some popular server technology platforms, which may or may not be Can be controlled by dedicated programming. The system management back end server is operatively associated with a mass memory that stores program code and data. Data may include a knowledge base, one or more databases that may be configured to maintain and store user identifiers (phone number, email/IM address, billing information, etc.), text, spreadsheets, folders, files, etc. can

A system management back end server may support a case management system that provides call traffic connectivity and distribution across client computers in a customer care center. In a preferred approach using VoIP voice channel connectivity, the case management system is a contact/case management system distributed by Contactual, Inc., Redwood City, CA. A CRM system for use in providing a VoIP based customer care call center that also provides utility for handling cellular related care and care issues with simultaneous payments. Salesforce (Salesforce.com, Inc., San Francisco, Calif.) and Novo (Novo Solutions, Virginia Beach, Va.) are within the present invention, as will be understood by those skilled in the art upon reading the specification, drawings, and claims. , Inc.) may also be used.

The systems management back-end server also includes an issuing engine (2010), a user unique identification database (2011), a merchant-geolocation collation database (2012), and a predictive transaction module (2015). support These elements will be discussed later in the specification.

Each client computer associated with the system management back end server has a network interface device, graphical user interface, and voice communication capabilities that match the voice channel(s) supported by the client care center server, such as VoIP. Each client computer may request status of both the cellular and portable communication device's secure transaction subsystems. This state may include the contents of the soft memory and core performance of the portable communication device, NFC components: baseband, NFC antenna, secure element state and identification.

payment subsystem

As shown in FIG. 2, each portable communication device 50 includes a one-time payment wallet 160, payment libraries 110, NFC (or RF) baseband, payment subsystem 150 (i.e., security data storage 115 and secure element 120}, and diagnostic agent 170. One-time payment wallet 160 is associated with NFC/RF baseband that is downloaded to device 50 (preferably payment subsystem 150) for temporary use (e.g., card, coupon, access control and ticket data) is an application that allows any portable communication device to request and emulate it. The application can also be implemented on legacy feature phones (non-smartphones) using WAP, J2ME RTE and/or SMS channels instead of the smartphone application. As discussed fully further below in this specification, certificates are most preferably NFC-based, but they may be transacted by RFID or Bluetooth transmission, or may be represented by 2-D matrix codes, bar codes, or Arabic numerals. can

Payment libraries 110 manage secure element 120 (and perform housekeeping tasks) on device 50, interface with system management back end 300, and communicate data (including an SMS channel). Used by the one-time payment wallet 160 to perform over-the-air (OTA) provisioning through the transceiver. It is contemplated that OTA data communications are encrypted in some way and the encryption key is placed within a card service module operatively associated with portable communication device 50 and payment subsystem 150 . In one embodiment, the card services module is operatively coupled to the one-time payment wallet 160 and the payment subsystem 150 (deployed as a third-party application described below). The card service module generally enforces access control to data stored in payment subsystem 150 and controls the function(s) for each application to be performed by payment subsystem 150 . In one embodiment, the card services module verifies the author/issuer of each third party application it uses on the portable communication device to access the payment subsystem (as described generally below). Payment subsystem 150 may be used to store credentials such as temporary one-time payment cards in addition to other payment card(s), coupons, access control and ticket data (eg, transit ticket data, concert ticket data, etc.) there is. Some of these certificate types can be added to the payment subsystem and payment libraries depending on circumstances.

If included, secure data store 115 will provide secure storage on portable communication device 50 . Depending on the nature of the data for storage within the secure data store 115, various levels of security may be provided. For example, secure data store 115 may simply be password-protected at the operating system level of device 50 . As is known in these operating systems, the password may be a simple alphanumeric code stored somewhere on the device 50 or a hexadecimal representation of a binary code. Alternatively, data in secure data store 115 is preferably encrypted. However, more likely, the secure data repository 115 is filed on October 21, 2011, entitled "System and Method for Providing A Virtual Secure Element", which is incorporated herein by reference in its entirety. may be set up as a virtual secure element in the manner disclosed in co-pending US patent application Ser. No. 13/279,147 (owned by the assignee of the present application), which is “on a Portable Communication Device”.

Dynamic ad-hoc (e.g. one-time) payments via smartphone

Because some point-of-sale devices do not accept NFC payments and some users do not set up contactless-enabled payment accounts (eg MasterCard PayPass, Visa Paywave) , the present invention is intended to enable any portable communication device (including those with NFC capability but no secure element and devices without NFC capability) to accept contactless payments or bar code electronic payments through their existing point-of-sale equipment. Enables highly secure electronic payments on the part of merchants.

To use the system for dynamic temporary (eg, one-time) payments to a retailer, a consumer downloads a dynamic temporary (eg, one-time) payment wallet application and enters at least one existing account with a particular bank. will have The consumer must also register at least one account with the payment issuer 310 (which may be a particular bank). In addition, the consumer must also have mobile data service on their smartphone (or portable communication device 50).

A dynamic temporary (eg, one-time) payment wallet 160 can remove some of the complexity involved in storing, maintaining, and using credentials due to their ephemeral nature and combination with geolocation verification. Among the potential actions that can be controlled by payment wallet 160, the following are relevant:

a. {eg, set, reset or execute wallet passcodes; obtain the URL of the OTA server; over-the-air (OTA) registry provisioning; set payment timing; increase payment timing; set default card; List issuers, memory audit; determine the SE for storage of the certificate; } wallet management that updates wallet status;

b. {add the certificate; report certificate details; delete the certificate; activate the certificate (for redemption/payment); disable the certificate; lock/unlock the certificate; request passcode access; acquire a certificate image; setting access passcodes} certificate management; and

c. Applicant's co-pending patent application entitled "System and Method for Providing a Virtual Secure Element on a Portable Communication Device", filed on October 21, 2011, which is hereby incorporated by reference in its entirety. Secure Element (SE) management of physical and/or virtual secure element(s) for use by payment wallet 160 as disclosed in application Ser. No. 13/279,147 (eg, obtaining certificates; update the certificate; update metadata; delete the certificate; lock/unlock the wallet; lock/unlock the SE; Initialize/wipe/reset the SE}. In devices 50 that do not have a secure element, this SE management may use a variety of techniques to protect incoming dynamic certificates, including encryption of standard memory under the user's password.

3A and 3B show one potential embodiment for a process for obtaining and using a one-time (i.e., dynamic temporary) payment credential using a “one-time” payment wallet 160 (with a number of potential alternatives). ) are exemplified together. A consumer can enter a physical retail store with their smartphone (ie, portable communication device 50) and proceed as they normally do for their shopping experience. Using the one-time payment wallet 160 downloaded onto their smartphone 50, when a consumer prepares to check out of a physical retail store, the consumer uses their smartphone to open a solution-enabled smartphone application. By doing so, you can also pay with legacy systems.

3A and 3B, the consumer accesses the point-of-sale (POS) 75, opens the one-time payment wallet 160 on the smartphone 50, and the user on the one-time payment screen. Enter the consumer's password/passcode via the interface (see Fig. 5). The one-time payment wallet 160 sends the consumer's passcode and geolocation coordinates (as generated by the location identification service 165 in FIG. 2 ) to the issuance engine 2010 ( FIG. 4 ). In one embodiment, the one-time payment wallet 160 may also provide the consumer with the ability to communicate an estimate of the forthcoming payment to the issuance engine 2010 prior to the creation of the temporary payment card information. By incorporating information regarding the estimated amount of a one-time payment into the verification process, additional security for the one-time code can be provided.

In the embodiment of FIGS. 3A and 3B , issuance engine 2010 verifies the passcode (eg, using user unique identification database 2011 ). Receipt of a correct passcode indicates to the system that the consumer will be paid within a short predetermined period of time (on the order of minutes, which can be extended in certain circumstances). In some embodiments, issuance engine 2010 may also verify the digital signature of portable communication device 50 that transmitted the passcode. The digital signature consists of at least a portion of one of the larger numbers identified in paragraph [0034] stored in the device identification memory of each portable communication device 50. Publishing engine 2010 uses the geolocation coordinates received from portable communication device 50 to obtain the expected information in a database operatively associated with publishing engine 2010 (eg, vendor-geolocation collection database 2012). Determine the seller to be sold and investigate the details of the seller's point-of-sale management. In particular, based on the received geolocation information, issuance engine 2010 performs a database query to determine if a contactless point-of-sale terminal is installed (or likely to be installed) at the consumer's location. In a preferred embodiment, the portable communication device 50 may also display a list (eg, next top 5) of the next most likely retail outlets where the portable communication device 50 may be located (eg, next top 5). , see Fig. 6a). Based on the identified location and/or point-of-sale terminal, the card service module of the portable communication device 50 may look up in a database or otherwise infer the vendor or facility where the consumer is located, and the device 50 ) configures the payment system 150 with an optimal representation of this location and/or merchant specific data formats and other contactless point-of-sale or access data, or card, coupon, ticket or access control emulation, to be supported. . The system may also allow the consumer to identify new card products available for geolocation that have not yet been loaded into payment libraries 110 . In some embodiments, the system may load required libraries.

Issuance engine 2010 provides the merchant location, facility identity, merchant identification number used for electronic payments, payment methods accepted by each merchant location, and capabilities of each merchant location's point of sale management or access control equipment. database of supported access-controlled facilities and electronic-payment accepting merchants (eg, Vendor/Facility Geolocation Collection Database 2012), which may include capabilities. (See Table 1 below). Although vendor/facility geolocation collection database 2012 is described as being included within publishing engine 2010 or otherwise as part of publishing engine, vendor/facility geolocation collection database 2012 is portable communication device 50, publisher It is conceivable that 310 may be included in, part of, associated with, or individually hosted. Additionally, it is further contemplated that the vendor location may further include the vendor's elevation. It should be understood that vendor/facility geolocation can be expressed using map coordinates, but can effectively be expressed using street addresses or proprietary coordinates for a surveyed baseline or point. While the vendor/facility elevation may be expressed as a physical length measure or distance measure (eg feet, meters) with reference to recognized international map sources (eg WGS84), height above ground, number of floors, or It should be understood that it can be effectively expressed in relative terms, such as proprietary coordinates for the height reference being investigated.

Table 1 - Examples of merchants and one-time payment information seller name Merchant Location GPS (Latitude/Longitude) Merchant location address Legacy Merchant ID Number Legacy payment/access types equipment ability Grocery Land 37.48N;
122.24W 94065 Suite 400, City of Redwood, California
Marine Parkway 100 XQ24MZ122A barcode laser scanner Appliance Land 37.48N;
122.24W 94065 110 Marin Parkway, Redwood City, California YF234XY302 QR code Optical QR Code Reader Must Buy 37.48N;
122.24W 94065 120 Marin Parkway, Redwood City, California MN343D ISO/IEC 14443/NFC ISO/IEC 14443 contactless reader

Next, the issuing engine 2010 generates a one-time use temporary payment card and transmits the temporary payment card data and the identity of the expected seller to the portable communication device 50 over-the-air. Temporary payment card information includes personal account number, issuer identification number, ISO/ IEC 7812, ISO/IEC 7813 (relating to the data structure and content of magnetic stripe tracks used to initiate financial transactions), and ISO 8583 formatting (a business messaging protocol based on a proprietary standard). It can be formatted in real time using existing standards and practices.

In one preferred embodiment, the one-time payment wallet 160 formats the temporary payment card based on the capabilities of the merchant's point-of-sale equipment 75 as well as the capabilities of the portable communication device 50 . Temporary payment card information may also be formatted in a number of formats to provide consumers with options that may be presented to merchant cashiers. 7A and 7B illustrate two of the possible types of one-time payment codes that may be transmitted to the portable communication device 50. 7A shows the one-time payment code as a 1-D bar code. As will be understood by those skilled in the art, this bar code can be a 2-D matrix code or a stacked linear barcode (e.g., QR code, Datamatrix, EZCode, PDF417). }. Figure 7b shows the one-time payment code as a numeric code, which can be 16 digits as shown or can be of different lengths as desired.

One format in which temporary payment card information may be provided on a smartphone display is an ISO/IEC 7813 compliant number (ie, PAN) that is manually entered by an employee at the merchant into the merchant's point-of-sale. Other formats in which temporary payment card data can be presented on a smartphone display are barcodes (ISO/IEC 15426-1), 2-D barcodes (ISO/IEC 15426-2), QR codes (ISO/IEC 18004:2006 ) or similar methods such that ASCII, alphanumeric, or numeric data is transmitted and then captured by the optical scanner of the seller's point of sale. Another format in which temporary payment card data may be provided is NFC peer-to-peer mode (ISO/IEC 18092), NFC tag emulation {NDEF, ISO/IEC 14443, MIFARE, and Felica}, or NFC card emulation mode (ISO/IEC 14443 card emulation) or RFID mode. Further, another format in which temporary payment card data may be presented is using an acoustic or hypersonic audio carrier generated by a portable device speaker and received by an accessory appliance at the merchant's point-of-sale terminal.

Activated temporary payment card data expires after a short predetermined period, such as two (2) minutes, to provide additional security. This time may be extended as long as the issuer 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.

The portable communication device 50 receives temporary certificate data, an expected seller, and emulation information from the issuing engine 2010 . In the preferred embodiment, the portable communication device 50 verifies that the prospective seller has been correctly selected from the database 2012. In one approach illustrated in connection with FIG. 6, the portable communication device asks the user if they have confirmed the location. In the illustrated example, the user interface asks if the location is "Grocery Land"? As the consumer standing in Grocery Land is shown in FIG. 1A , the consumer should select the “yes” button in FIG. 6 . If the system selects the wrong retailer, the system may provide an alternative to verifying the correct retailer. For example, FIG. 6A shows potential proximate proximity of consumers in an example where a one-time certificate was required within what the issuance engine 2010 recognizes as a mall (or other densely grouped vendors). Indicates the preparation of a list of sellers. As will be appreciated by those skilled in the art upon reading this specification, drawings, and claims, the list of nearby vendors need not be limited to vendors within a single mall. Alternatively, it may be selected from other retailers that are geographically proximate to the geolocation received by the server. As may be further appreciated, by way of example, as a map overlay indicating the geographic location of each retailer, as a floor plan overlay such as used in a mall, plaza or building directory, or other context appropriate forms, full -Can be presented to the end user in the form of a pull-down menu or list.

In embodiments where the consumer uses the portable device 50 to verify the seller, the prospective seller's confirmation may be received by the issuing engine 2010 . If the expected seller is incorrectly identified, the publishing engine may issue new emulation information to the portable communication device 50 . If the prospective seller is known, the prediction transaction module 2015 of the issuance engine 2010 uses the ID for the prospective seller, the unique user ID associated with the portable communication device 50, and the one-time use token generated for the transaction. , and the expiration time are sent to the validation mapping gateway 2020.

Verification Mapping Gateway 2020 may be physically hosted by a bank, by an issuer 310, or by a payment processor network, installed in existing transaction processors, card methods, financial institutions, and other entities. It can be deployed as a service or as a subsystem that is integrated and integrated. Upon receiving data from the prediction transaction module 2015, the received data is stored in a database associated with the verification mapping gateway. If such data is provided, the temporary data may be associated with legacy card data previously associated with the unique user ID. To the extent that such an association exists, the mapping of legacy cards to unique user IDs is an electronic transaction directly between portable communication device 50 and verification mapping gateway 2020 organized by system management back end 300. may be generated by publishers 310 or even by consumers.

In a preferred embodiment, the prediction transaction module 2015 sends data to the verification mapping gateway 2020 at substantially the same time that the one-time use credential information is being transmitted to the portable communication device 50 . In this approach, verification mapping gateway 2020 may anticipate consumer transactions from merchant POS 75 via the merchant payment network. In particular, in such an embodiment, verification mapping gateway 2020 compares incoming data from predictive transaction module 2015 with retailer point-of-sale 75, from a large database, and (relative to access times from large databases). A comparison between the stored data and the data received from the merchant payment network and the time between receipt of the transaction to fetch the data stored in the memory may be used to provide faster access. In this approach, the addition of this additional verification step in verification mapping gateway 2020 is triggered by the need to locate and retrieve data for this comparison after receiving the transaction from POS 75. It will reduce the waiting time that may have been.

So back to the consumer, after the portable device 50 receives the temporary certificate and emulation information, the consumer taps the smartphone 50 on the NFC peer-to-peer enabled point-of-sale device 75 or otherwise. Otherwise, it can be activated, which causes the portable communication device to emulate a certificate with a one-time payment code using the emulation protocol provided by the server. It is understood that the code can be visually “emulated” on the screen of the portable communication device 50 . Because temporary payment card data may be provided in legacy formats, temporary payment card data may be accepted by existing merchant point of sale equipment 75 .

Next, the point-of-sale device 75 processes the temporary payment card data through a common merchant payment network as if it were a standard credit or debit credential. However, since the temporary payment card data uses issuer identification numbers (ISO/IEC7812) that are registered and mapped to the one-time payment system provider as an issuer, the data will be routed through the merchant payment network to the verification mapping gateway 2020 ( routed). If data is received by verifying mapping gateway 2020 prior to expiration of the expiration time for the temporary certificate, and from the predicted prospective seller, verifying mapping gateway 2020 may authorize the transaction. Verification Mapping Gateway 2020 also determines how temporary payment card data is entered into merchant point-of-sale device 75 (existing ISO8583 designated fields) and how temporary card data is provisioned for intended use on a mobile phone. methods (eg, numeric codes, barcodes, NFC) can be compared.

Again, if all desired characteristics support a low risk score (e.g., temp code, runtime, merchant ID, and emulation type), then the verification mapping gateway will send the authorization code via the merchant payment network or facility access network. can be used to return an acknowledgment to the seller. Merchant point-of-sale 75 receives authorization (i.e. confirmation of acceptance of payment by authorization code), prints receipt, allows consumer to leave their newly acquired items in storage or user access to controlled facility is granted

Alternatively, upon verification of the temporary payment card information (including timing and expected merchant ID), the system has the option of forwarding an equivalent payment transaction request to the issuer 310 to authorize the transaction. This is known as executing a back-to-back payment transaction. In this way, consumers and merchants will receive payment confirmation from the consumer's legacy bank credit or debit card account instead of a temporary card number. In particular, once a one-time payment transaction is verified, verification mapping gateway 2020 may use standard POS transaction information (e.g., merchant ID and transaction volume) and - in some embodiments - (to show an added measure of security). Replaces legacy card payment data in the transaction data, which is passed on issuer authentication systems 310 with an indication that the transaction used a verified one-time use credential. The issuer 310 will review the legacy card data and transaction information toward determining whether to authenticate the transaction, perhaps in a manner commonly known in the art, with information that the transaction has the added security described above. The issuer certificate is sent back to the merchant point of sale 75 via the usual existing processing channels.

This one-time (or temporary)-use certificate solution can be used for many different types of certificate verification scenarios, including: credit and debit card payments, gift cards, loyalty cards, coupons and offers, access Control, transit fare, event ticketing, and any other environment where consumers provide credentials for verification in a physical environment.

Although functionality may be integrated within the one-time payment wallet 160, the user interface may be provided by the wallet user interface, and over-the-air (OTA) provisioning and management of the secure payment subsystem and access to the card services may be provided. It is supported by the module's functionality. Based on the user interface, the card service module connects the appropriate issuer server (for the one-time payment wallet 160 being the issuance engine 2010) and the user's mobile device ( 50) using over-the-air (OTA) provisioning, secure element management, and direct key exchange between card service modules on

Validate a one-time payment application as a third-party application

As illustrated in FIGS. 8A and 8B , the one-time payment wallet 160 may be deployed as one of many trusted third party applications 200 . The card services module is a secure element 120 on the portable communication device 50 (or card image data and any, among others, card image data and any The trusted state of any application 200 is verified before allowing that application access to a secure data store 115 that stores embossed card data and even preferably a metadata store}. This verification may be accomplished by accessing a local authorization database of allowed or trusted applications. In a preferred approach, the local authorization database cooperates with a remote authorization database associated with one or more servers associated with the system management back end 300 . Applications can be created through a variety of means, including technology platform facilities such as strong assembly references, hash coding of an application's executable code or load file, an API key or Auth token of the app developer, and smart It may be identified using other means known to those skilled in the art of phone application development.

FIG. 10 is a block diagram of one potential implementation of a card service module, secure element 120, and one potential combination of local and remote authorization databases to enhance security of payment subsystem 150. As shown in FIG. 10, the user A/C registry (or user account registry) may be associated with a server (or alternatively located in the cloud). The user A/C registry may store the identification of the secure element 120 disposed on the portable device 50 of each user. Entries in the user account registry can be added for each user at any point in the process.

The "Issuer Registry" database is a database of approved issuers. The issuer ID is unique for each type of certificate. That is, if a bank has multiple types of certificates (e.g., debit, credit, affiliate, etc.), each certificate type has its own issuer ID (e.g., I-BofA-II). will have In a preferred approach, issuer IDs among multiple types of certificates will have some common element to indicate that the certificates are at least related (e.g., I-BofA-I). In this way, applications from the same publisher can share data with other applications from the same “extended” publisher. In a preferred approach, the card service module can be simplified by requiring even a wallet user interface to {"ship with the system"} with an issuer ID (as well as an application ID and compilation token).

The "Application Registry" is a database of pre-approved (mostly third party) applications by operating system providers. Like the User A/C Registry, the "Application Registry" and "Issuer Registry" databases are maintained server-side (or alternatively hosted by a third-party Internet-facing facility) in operably associated with a pay-per-time application. . As will be appreciated by those skilled in the art upon reading this specification, the various registries may be implemented in separate databases or in one integrated database. At the start of the wallet 160 and preferably at substantially regular time-intervals thereafter (eg, daily), data stored in the application registry of the one-time payment wallet 160 is stored locally in the wallet distributed to devices with

As shown in FIG. 10 , the application registry may include, among other information, an application ID (“app ID”), a publisher ID, and a compilation ID or token. A compile ID is a global constant generated for each application by one or more processes associated with a one-time payment wallet during the entitlement process for that particular application. After this is generated by a particular card service module on the native device 50, the compilation token is included or otherwise associated with the application. This compilation token is preferably generated by a pseudo-random number generator local to the device using a pre-determined seed, such as an application ID, a compilation ID, an issuer ID, or some combination thereof. .

When a user tries to entitle an application with the card service module on device 50, the compilation ID (digital token) and application ID (digital identifier) associated with the third-party application are stored on device 50. It can be matched with a pair of compilation ID and application ID stored in the registry (Card Services Registry) (see FIG. 10). As will be understood by those skilled in the art upon reading this specification, the same compilation and application ID pair is also transmitted to other devices 50 associated with the system. If a compilation ID/application ID pair matches one of the pairs stored in the card service registry on the device, a Secret Token ID is desired by a pseudo-random number generator (such as associated with secure element 120). After it is generated in the device 50, it is stored in association with the compilation ID/application ID pair in the card service registry on the device 50. In some examples, the compilation ID can be pre-selected and used to seed the random number generator. It should be appreciated that one or more pieces of other predetermined data associated with the card service registry may instead be pre-selected as a seed. The card service registry is preferably stored in secure memory (not secure element 120 since secure element 120 has a limited area) and the card service registry is preferably further encrypted using standard encryption techniques. The secret token ID is also embedded in or otherwise associated with the application 200 on the device 50, instead of the compiled ID distributed with the application.

After the one-time payment wallet 160 is loaded into the card service registry (and the secret token embedded in the application), the one-time payment wallet 160 is authenticated (or trusted) by the issuer-specific certificate required by the application. You can launch and remind users to participate in order to provide access to them. On each subsequent launch of the one-time payment wallet application 160, the embedded secret token and/or application ID is compared to 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 services module. In this way, it can be seen that the application 200 or wallet user interface may also be removed from the card service registry, and thus access to the payment subsystem and possibly the application may be disabled.

The card services module also preferably uses a trusted application verification step to determine the appropriate level of subsystem access allowed to 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, in which case other applications may only view data contained in payment subsystem 150. It can be authorized to access and display subsets. In another embodiment, an application may only be allowed to send payment or transaction requests to the one-time payment wallet 160, but may not be allowed to access any data contained in the payment subsystem 150. there is. In one approach, the assignment of permissions to applications can be viewed as shown in Table 2 below:

Reserved all certificates Extended Issuer Certificates own certificates reading 0 0 or 1 0 or 1 0 or 1 entry 0 0 or 1 0 or 1 0 or 1 delete 0 0 or 1 0 or 1 0 or 1 enable/disable 0 0 or 1 0 or 1 0 or 1 download certificate 0 0 or 1 0 or 1 0 or 1

These permissions can be used to form four hexadecimal digits in order from the most significant digit to the least significant digit. As shown in the exemplary card service registry of FIG. 10, the I-BofA-II issuer has permission level 11111, which can be thought of as extending to 0001 0001 0001 0001 0001. That is, an I-BofA-II application can read, write, delete, activate/deactivate, and download its own certificates, not even extended issuer certificates, let alone all certificates. If BofA had another issuer code (eg, I-BofA-I), this would be an extended issuer application. Thus, if the permission level of an application associated with issuer ID "I-BofA-II" is set to 0010 0001 0001 0010 0001 (or 21121 hexadecimal), the application can read and activate/deactivate certificates associated with both issuer IDs. will be able to disable it. In another example, the wallet user interface may be given a permission level of 44444 (ie 0100 0100 0100 0100 0100). That is, the wallet user interface can read, write, delete, activate/deactivate, and download all credentials. As will be appreciated by those skilled in the art, these are only examples of potential permissions that may be granted to applications, and other permissions are contemplated. For example, some applications may have the ability to read extended issuer certificates, but may write, delete, activate, and download only their own certificates (e.g. extended to 0010 0001 0001 0001 0001). 21111). In another example, an application may be given activation/deactivation and download permissions only (eg, hexadecimal 0000 0000 0000 0001 0001 or 00011). In another example, an application can be disabled - without being deleted from the trusted applications database or card service registry - by setting all permissions to zero.

In an embodiment where the one-time payment wallet application 160 is configured as one of the trusted third party applications, it will be registered to access the OpenWallet 100 (or even the Card Services module). The one-time payment wallet application 160 is developed by an issuer associated with the issuance engine 2010 . Additionally, the one-time payment wallet application 160 may emulate an NFC certificate. Therefore, the one-time payment wallet application 160 should be given permission level 11111, which can be considered as extending to 0001 0001 0001 0001 0001. That is, the one-time payment wallet application 160 can read, write, delete, enable/disable, and download its own certificate, but not extended issuer certificates or any other certificates.

The above description and figures refer 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 recognized that the one-time payment wallet 160 may instead consider the dynamic temporary wallet 160 and the one-time payment credentials/information and temporary payment card data may consider dynamic temporary credentials. do. As such, credentials can (1) be “recycled” and reused within the system by other users; (2) may have a predetermined time to live longer than the "short" predetermined period, and (3) such certificates may be used for more simple-to-purchase products. Although the above description and figures refer primarily to a point of sale device 75 associated with a vendor, the foregoing description, drawings and embodiments refer to a variety of devices such as hotel room transceivers, office transceivers, rental car transceivers, etc. It is also contemplated that it may be applied to other electronic control points. For example, electronic control points may include any access point such as point-of-sale devices, RFID transceivers, barcode transceivers, NFC transceivers, and the like.

In particular, certificates generally must be “settled” by the issuer 310 or other organization within the larger merchant payment system as a whole. As such, systems may only have a limited number of certificates at their disposal. By using such certificates, only one-time transactions with a particular user can lead to unnecessary high costs compared to the system, where the payment certificates are recycled for use by multiple users at different times, preferably It is recycled at different geolocations to provide additional security against fraud. For example, the issuance engine 2010 sends expiry data associated with certificates and issuance thereof to a first user driving a first portable communication device 50 located in a first geolocation (eg, California). , and after that, tracking the expiry date and time of the certificates, and replaying the very same certificates to a second user driving a second portable communication device 50 located in a different second geolocation (eg, Florida). can be assigned

Similarly, certificates may have longer time to live periods to allow use of the certificates at various "point of sale" or other electronic control points. For example, referring to FIGS. 9A and 9B , a representative wallet user interface is illustrated on a portable communication device 50 . Wallet 160 may include and be associated with various payment cards (eg, MasterCharge, VISA, Charge-It, etc., as illustrated in FIG. 9A ), and may additionally be associated with various other non-payments. Includes and may be associated with applications (eg, room key at a hotel, office keycard, rental car FOB, etc., as illustrated in FIG. 9B ). While the "time to live" period is preferably short in the context of selling at a point of sale to provide enhanced security, when a wallet is associated with non-payment applications such as a room key in a hotel, the "time to live" may increase. It is contemplated that it could be significantly longer. In such an example, wallet 160 may be used to “open” or “lock” a user's room in a hotel. Therefore, the "living time" should be set to at least coexist with the user's stay in the hotel. Similarly, the time-to-live may be set to a period of time (infinite, if necessary) that allows a user of device 50 to use device 50 to access an office or rental car.

Accordingly, it is also contemplated that the system management back end 300 and issuer 310 may be associated with non-financial services to allow use of non-payment wallet applications. For example, system management back end 300 may include data related to non-financial services (eg, hotel location, office location, etc.), and issuer 310 may include non-payment entity (eg, hotel entities, office management entities, etc.).

An issuer of an electronic payment card may wish to support extended lifetime dynamic certificates, perhaps in certain select circumstances. For example, a user may want to make a purchase using a payment credential, but the point-of-sale terminal may not be connected to the payment network at the time of purchase. Such transactions may be referred to as "offline" transactions. For example, a user may make an in-flight purchase during an air flight at a point-of-sale terminal. Later, the point-of-sale terminal may communicate the received payment credential to the payment processing network to request payment from the customer's account. In other examples, users may desire temporary payment credentials for use from their home in connection with Internet-based (or other computer networked commerce) transactions. In still other examples, a user may simply prefer to obtain a temporary payment credential from the comfort of their home, to avoid the stress of queuing and obtaining a credential on time at checkout of a retail location.

11A, 11B and 12 together illustrate one potential communication flow for obtaining a temporary certificate and using the certificate for payment. In this potential embodiment, a user may initiate a registration process using their wallet application to obtain a temporary payment credential from the cloud. A user may have an account (eg, credit card account, debit account, etc.) with a bank (or other financial account provider) and, using their portable communication device 50, the user may pay with temporary payment credentials. You may want to sign up for a payment service offered by a bank that allows you to do this. For example, as illustrated in FIG. 9A, the user may use a temporary payment wallet application (preferably associated with FIG. 10 above) stored on the portable communication device 50 that has been previously verified as a trusted application. You can acquire a "Temp Pay" card from "Banc Two". When the temporary payment wallet application 160, embedded secret token and/or application ID is compared to data in the card service registry on the device, the local match will enable communication with the mobile banking platform or issuance engine 1102 ( see Figure 11a).

If the user is authenticated, the temporary dynamic wallet application 160 may generate tracking data based on the type of temporary payment credential, user data, and contextual data when the user requests the temporary credential. . This temporary payment card data preferably includes an individual account number, an issuer identification number, and an ISO/IEC (related to the identification of the issuer using an issuer identification number (IIN) to operate in international, inter-industry, and/or intra-industry exchanges). 7812, ISO/IEC 7813 (relating to the data structure and content of magnetic tracks used for initial financial transactions), and ISO 8583 (a business messaging protocol based on a proprietary standard) formatting. may be formatted using existing standards and practices of the payment industry. In some examples, the payment data may be arranged in a format similar to that of track 1 and track 2 data from a conventional credit card so that the payment data can be processed by a legacy point-of-sale terminal. In one example, payment data may include a block of data formatted with some or all of the following fields (32 digits): Account # (9 digits); IMEI (device identifier - 11 digits); expiration date (4 digits); random number(6); and sequence counter (2). A data block may also contain one or more padding characters.

11A illustrates an example communication flow allowing a user to sign up for and obtain a temporary payment credential in one potential embodiment of a process. The user can enable their portable communication device 50 to retrieve the wallet application from the mobile banking platform (or issuance engine) 1102 associated with the user's financial account provider, which can then be used to authenticate the user. You can create login information. At element 1110, if the user wishes to obtain a temporary payment credential, the user may cause the portable communication device 50 to open the wallet application and enter login information. Login information may be, for example, a user name and password. If the user has multiple accounts, the user may select a particular one to access the temporary payment system. In this embodiment, issuance engine 1102 may also receive geolocation coordinates received from portable communication device 50 upon this request for later use in association with a payment transaction.

At element 1110 , portable communication device 50 may communicate login information to mobile banking platform 1102 . In certain embodiments, the mobile banking platform 1102 may pass a communication link to the issuer 310 associated with the temporary payment application to ensure that the issuer recognizes the customer. As shown, in FIG. 11A , issuer 310 may have a Know Your Customer (KYC) engine that can communicate with portable communication device 50 without intervention of back end system 300 . In this way, only the publisher 310 and the end user are exposed to the end user's personal information at any time. In particular, the KYC engine can create a user interface on top of the ad hoc payment application 160 (see Fig. 9c), from which it can directly receive user input and verify the customer. As shown in FIG. 11A , in this embodiment, the KYC engine may send an authorization message to the issuing engine 1102 .

If the user is successfully authenticated, at block 1112, mobile banking platform 1102 may return an acknowledgment message indicating that the user has been authenticated. At element 1114, the user may make a request to subscribe to the temporary payment credential service using the wallet application. At element 1116 , mobile banking platform 1102 may generate a communication security token and legacy card number and communicate them to management back end 300 . Telecommunications Security Token is Applicant's co-pending patent application number 13/916,307 entitled "System and Method for Initially Establishing and Periodically Confirming Trust in a Software Application" filed on June 12, 2013, incorporated by reference. may be created and used according to the systems and methods disclosed in

At element 1118, mobile banking platform 1102 may communicate the token along with the network identifier to portable communication device 50. The network identifier may identify the network address of the management back end 300 for routing messages from the wallet application to the management back end 300 . In one example, the network identifier may be a uniform resource identifier (URI). At element 1120, portable communication device 50 may communicate the token to management back end 300 using the network identifier. In response, management back end 300 may determine if the user has generated a personal identification number (PIN) or other authentication sequence and, if not, at element 1122, send a generated PIN message to portable communication device 50. can communicate The PIN may be a secret shared by the portable communication device 50 and system management back end 300 for user authentication.

The user may enter the desired PIN into the wallet application, and the portable communication device 50 may communicate the generated PIN to the management back end 300 at element 1124 . At element 1126 , management back end 300 may complete registration of the user, and at element 1128 , may generate and communicate a success message to portable communication device 50 . A success message may include a provisional payment credential and one or more risk management parameters. The temporary payment credential may optionally include randomized card data with a lifetime value, for example. In an example, the temporary payment credential may include routing information, a temporary account identifier, and a checksum. In an example, the temporary payment credential may include: 6 digit International Organization for Standardization Bank Identification Number (ISO BIN) + 9 digit alternative account identifier + 1 digit Luhn check. The time-to-live value is configurable to conform to the business rules of the financial account provider. For example, a time-to-live value can have a configurable duration (eg, seconds, minutes, days, weeks, months, years, etc.), and/or can have a configurable frequency of use (eg, seconds, minutes, days, weeks, months, years, etc.) For example, it can be used up to 3 times).

At element 1130, management back end 300 may request the user's legacy credential data and issuer 310 may retrieve and respond to the user's actual credential data.

The portable communication device 50 may later use the temporary payment credential to make purchases, including storing the temporary payment credential for offline use at a later time. When paying for a sales transaction, the user selects a temporary payment credential (eg, Banc Two Temp Pay) from their wallet application. As discussed with respect to one-time authentication, the wallet application may communicate the track data and legacy bank BIN to the point-of-sale terminal, for example via an NFC tap or QR code scan. The point-of-sale terminal may process the bank BIN and route the track data to a payment processing network that may forward the track data to a third party Internet hosting service. Upon receiving the temporary identification, the third party internet hosting service may assess the risk, provide a score, and generate a requested payment authorization from the bank authorization system. If payment is approved, the cloud service may communicate an approval message to the point-of-sale terminal, thereby completing the sale.

12 illustrates a payment communication flow using temporary payment credentials in one potential embodiment of a process. Upon purchase, referring to element 1210, the user can launch the trusted wallet application and select which credential to use to make a payment. For example, a wallet application may provide access to multiple payment credentials, some of which may be temporary payment credentials, while others store legacy card data (e.g., actual payment account information). Certificates can be stored. The user may select a temporary payment credential and enter its corresponding PIN. At element 1212, the wallet application may generate payment data for the selected temporary payment credential, which is thereafter provided to merchant POS terminal 75 in the same manner as described above in connection with FIGS. 7A and 7B. The POS terminal 75 can verify whether the generated data corresponds to the predicted format. If not, POS terminal 75 may locally decline the transaction. If the format matches the predicted parameters but the POS terminal is not connected to the merchant payment network, the POS terminal will still approve the transaction offline and follow the next flow to complete the sale later through the merchant payment network.

If the format matches the predicted parameters and the terminal is connected to the merchant payment network, the POS terminal 75 communicates the parameters of the transaction to the merchant payment network via an authorization message. The authorization message may include Trackl/Track2 data, vendor ID (and preferably vendor's geolocation), and transaction volume. At element 1218, payment network system 1204 processes the authorization message, determines whether it contains data for routing to management back end 300, and reroute the authorization message to validation mapping gateway 2020. )can do.

In element 1220, verification mapping gateway 2020 preferably generates a risk score for the transaction based on information encoded in the temporary payment card data and using information stored in the mapping gateway database. The risk score may take into account (alone or in combination with each other) one or more of the following factors, for example:

(a) the time elapsed since the provisional certificate was issued;

(b) the difference between the geolocation of the seller and the geolocation of the device 50 when the temporary certificate was issued;

(c) the difference between the vendor's geolocation and the device's geolocation as known to the risk assessment system when the provisional certificate is redeemed;

(d) the date and time of reimbursement;

(e) current since the last use of the provisional certificate;

(f) volume of seller authorization requests;

(g) type of seller;

(h) the user's historical usage pattern; and

(i) Concurrent dynamic security policies, including tracked behavior, and current facility access policy.

For example, the age of a certificate can be compared to geolocation differences to provide an important risk assessment. In particular, if the certificate was issued earlier than an hour, but is geo-location hundreds of miles away from the current seller it is being offered for redemption, the transaction will be questionable. In this way, various parameters can be taken into account by the risk scoring engine to generate a risk score. This risk score, along with the legacy payment data, can be passed as a second authorization message to the issuer for authorization decision, step 1222 . The issuer 310 processes the second Track 1/Track 2 data to determine whether to authorize the transaction. If authorized, issuer 310 may respond to management back end 300 with an authorized message at element 1224 . The management back end 300 may map the second Track 1/Track 2 data back to the first Track 1/Track 2 data and forward the second authorized message to the payment network system 1204 . In some embodiments, information about the user's digital device signature may be received so that the publisher can communicate directly with the end user via device 50 to request entry of the CVV (see FIG. 9D ). The issuer can use that information to further verify the transaction.

At element 1230 , payment network system 1204 can optionally forward the second authorized message to POS terminal 1202 . In offline transactions, for example, the POS terminal will batch reconcile with the payment network system 1204 at the end of the day. In response, the POS terminal will collect all authorization messages as proof of transfer of responsibility to the issuing bank. For online transactions, POS terminal 1202 may optionally wait for the transaction to be approved until receipt of a second authorized message.

In this new method, geolocation data will be captured by the portable device payment wallet at the time of authorization rather than (or in addition to) the time of issuance. In this new method, geolocation data can also be encoded into a data format (eg, any data fields in a Track 1/Track 2 data format) to be redeemed at a POS or access point by a payment wallet. Next, back-end risk engines can score the risk associated with redemption of previously issued one-time tokens at a particular vendor or facility identified by the geolocation data. However, in this new method, the token can be issued well in advance of use and refreshed as policy requirements, thereby minimizing the threat of theft or abuse.

Dynamic credentials/payment tokens may also be limited to "one time" use in some embodiments. They will be used repeatedly within a specified date or time range (eg) subject to rate limits and other reimbursement policies. It is also contemplated that dynamic certificates may be redeemable only at certain merchants or only within certain redemption limits (amount, date, time). Not just payment, it should also be specific to supporting physical access applications (eg hotel door, campus building). These tokens will also be minted well prior to use.

The above description and drawings are only to explain and illustrate the present invention, and the present invention is not limited thereto. Although the specification has been described in relation to certain implementations or embodiments, many details are presented for purposes of illustration. Accordingly, the foregoing merely illustrates the principles of the present invention. For example, the present invention may take other specific forms without departing from its spirit or essential characteristics. The described arrangements are illustrative and not limiting. A person skilled in the art may add implementations or embodiments to the invention and may change significantly any of the details described herein without departing from the basic principles of the invention. Accordingly, it will be appreciated that those skilled in the art will be able to devise various arrangements embodying the principles of the present invention, although not explicitly described or illustrated herein, within the scope and spirit of the present invention.

Claims (11)

To a portable communication device for use in transacting with an electronic control point, the portable communication device having a service providing the current geo-location of the portable communication device. A system for issuing dynamic temporary credentials, comprising:
means in a centralized computer for receiving the current geolocation of the portable communication device;
means for transmitting the dynamic temporary certificate from the centralized computer to the portable communication device;
means for scoring the risk of authorizing a transaction associated with the electronic control point using the dynamic temporary certificate; and
A validation mapping gateway operatively connected to one or more issuers.
including,
The risk score for authorizing a transaction is a comparison of the difference between the geolocation of the portable communication device and the vendor's geolocation when the dynamic temporary certificate is redeemed and the time that has elapsed since the dynamic temporary certificate is issued. system determined based on. According to claim 1,
and means for authenticating an end user of the portable communication device, wherein the means for transmitting the dynamic temporary certificate is not functional until the end user authentication means authenticates the end user. According to claim 2,
and a user database providing associations between the end user name and passcode, wherein the authentication means is operatively associated with the user database and authenticates the end user by verifying the passcode. According to claim 3,
wherein the portable communication device has a unique digital signature, and the authentication means further authenticates the end user by verifying the authenticated end user and the unique digital signature in pairs. According to claim 4,
A system further comprising means for verifying the identity of a customer. According to claim 2,
wherein the portable communication device has a unique digital signature, and the authentication means further authenticates the end user by pairwise verifying the unique digital signature with the authenticated end user. delete delete delete According to claim 1,
wherein the means for scoring risk determines an increasing risk proportional to time elapsed since issuance of the dynamic temporary certificate. delete

Images