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

Abstract

To a system for issuing dynamic temporary certificates to portable communication devices for use in transactions with electronic control points. The system receives the current geolocation of the portable communication device and sends the dynamic temporary certificate from the centralized computer to the portable communication device. The system also scales the risk of authorizing a transaction associated with an electronic control point using the issued dynamic temporary certificate. The system can prevent the transmission of the dynamic temporary certificate until the end user is authenticated. The system may further include a verification mapping gateway operatively connected to one or more publishers that replace the dynamic temporary certificate with legacy payment data in the payment transaction prior to sending the payment transaction with a risk score to a publisher associated with the legacy billing data have.

Description

[0001] SYSTEM AND METHOD FOR DYNAMIC TEMPORARY PAYMENT AUTHORIZATION IN A PORTABLE COMMUNICATION DEVICE [0002]

Cross-reference to related application

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

The present invention relates generally to the use of secure data for completing a wireless transaction, and more particularly to a system and method for processing a temporary electronic payment certificate for use in a portable communication device.

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

Smartphone penetration by consumers is also growing rapidly. There has been a challenge to how consumers can make electronic payments using their existing mobile phones. Near Field Communication technology in telephones with embedded security elements enables one potential solution for this challenge.

Near Field Communication (NFC) is another technology in which similar RFIDs use electromagnetic waves to exchange data. NFC is an open standard that specifies the modulation scheme, coding, transmission rate, and RF interface (see ISO / IEC 18092, for example). Unlike RFID, NFC transmission and reception relies on the electromagnetic coupling of the transmitter and the receiver rather than RF propagation. Thus, NFC communication is possible over only a short range (about several inches). There has been wider adoption of NFC as a communication platform because it is highly selective and therefore requires intentional physical gestures (e.g., shaking 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 may be tolerated for use in supporting financial transactions and access control.

NFC devices were already being used to pay for some point of sale devices. However, many mobile devices do not have Secure Element hardware, which is commonly used to securely store contactless payment certificates. Accordingly, the present invention seeks to provide a solution that allows any smartphone to make highly secure electronic payments to merchants accepting contactless electronic payments using existing point-of-sale management devices.

Another problem is the myriad of certificate types and communication protocols associated with the various and different point-of-sale terminals available. Thus, for example, one vendor may rely on bar code scanning, while other vendors may rely on non-contact NFC or low power Bluetooth. And the wireless protocol required to successfully communicate wirelessly with an IBM point-of-sale terminal may be very different from the wireless protocol required to communicate with the NCR terminal. Accordingly, some embodiments of the present invention may be used to determine in advance certain of the possible certificate types, point of sale management redemption methods, terminal device types and / or communication protocols present in a retail location located in the same location as a portable communication device I try to use geo-location data (if available) to try.

The ability of physical sellers to accept electronic forms of payment has grown considerably in developed countries and is also growing rapidly in developing countries. The financial industry has developed and deployed rigorous systems, methods and requirements for electronic transactions to mitigate and minimize fraud.

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 of ordinary skill in the art having access to this specification.

These and other objects and advantages of the present disclosure will also be apparent to those of ordinary skill in the art having access to these drawings, specification, and claims. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of this disclosure, and be protected by the accompanying claims.

For a better understanding of the present disclosure, non-limiting and non-exclusive embodiments are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various views unless otherwise specified.
1A illustrates an end user attempting to use his or her portable communication device to perform a secure payment transaction in point of sale management.
Figure IB illustrates operational interconnection between various subsystems including the end user's smartphone (i.e., portable communication device) and the 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.
Figures 3a and 3b together illustrate the flow in one potential embodiment of the process for a one-time (i.e., ad hoc) payment certificate.
FIG. 4 is a block diagram illustrating information flow between a portable communication device and the rest of a payment ecosystem in connection with the payment process illustrated in FIGS. 3A and 3B. FIG.
5, 6, and 6A are examples of exemplary wallet user interfaces that may be deployed in a typical portable communication device.
Figures 7A and 7B are examples of two potential embodiments of one-time payment certificates generated by a typical 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.
8B is a block diagram illustrating additional details of the "one payment wallet" block of FIG. 8A that may be associated with the present system.
Figures 9A and 9B together illustrate one potential embodiment of a user interface that may be implemented in an exemplary smartphone that further illustrates the flexibility of a one-time certificate functionality coupled with a federated wallet .
Figures 9c and 9d further illustrate the ability of an issuer to communicate directly with a user to obtain information that is often too sensitive (e.g., "customer awareness" and CVV) information that entities do not want to share data with ≪ / RTI > illustrates another potential embodiment of a user interface that may be implemented in the illustrated portable communication device.
10 is a block diagram of one potential implementation of the system for the fundamental authorization of permissions to view, select, and / or modify security data that a one-time payment application is stored in a payment subsystem.
Figure 11A is a block diagram illustrating information flow between a portable communication device and the rest of the payment ecosystem system in connection with an embodiment of a temporary dynamic credential process illustrated with respect to Figures 11B and 12;
11B illustrates a communication flow for obtaining a temporary credential token in one potential embodiment of the process.
Figure 12 illustrates a payment communication flow using a temporary certificate token in one potential embodiment of the process.
Figure 13 illustrates a cryptographic mechanism that may be used in one potential embodiment of the process of obtaining and utilizing a temporary electronic credential.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will now be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. However, the present invention may 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. Among other things, the invention may be embodied as methods or devices. Accordingly, the 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. The following detailed description is, therefore, not to be taken in a limiting sense.

Portable  Communication Devices

The present invention includes PDAs, cellular phones, smart phones, laptops, tablet computers, and other mobile devices including cellular voice and data services, as well as access to preferably consumer downloadable applications, Systems and methods that can be utilized in a variety of different and non-limiting portable communication devices. One such portable communication device may 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 purposes of this disclosure, the present invention is generally described in terms of smartphone-optimized interfaces and features that utilize a generalized platform, but those of ordinary skill in the art will also recognize all such features and interfaces as well And may be utilized and adapted for any other platform and devices.

The portable communication device preferably includes one or more short proximity electromagnetic communication devices, such as an NFC, RFID, or Bluetooth transceiver. Peer-to-peer data exchange, reader-writer mode when paired with security elements on a portable communication device and provided prior to a "contactless payment reader" The NFC Forum (www.nfc-forum.org), which provides standard functions such as (i.e., harvesting information from NFC tags), and non-contact card emulation (for NFC IP 1 and ISO / IEC 14443 standards) It is presently preferred to use an NFC baseband that complies with industry protocol standards such as those published by the International Organization for Standardization (ISO) and also complies with the NFC IP 1 International Standard (ISO / IEC 18092). As will be appreciated by one of ordinary skill in the art with reference to the specification, drawings, and claims, the NFC IP 1 standard may be exported in whole or in part for use in connection with any other proximity communication standard , It is merely a good example at present. It is further preferred that the portable communication device includes an RFID antenna or NFC antenna (to comply with 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 will be appreciated in the art, RFID communications as well as NFCs can have a variety of non-conforming antennae and coil designs over potentially even shorter ranges, where communication reliability changes and other potential interoperability issues exist. . ≪ / RTI >

The portable communication device also includes a network interface for establishing and managing wireless communication with a mobile network operator. The network interface may be a 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- WAP, Ultra Wide Band (UWB), 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. Thus, the mobile network interface may comprise a transceiver, a transceiving device, or a network interface card (NIC). As one of ordinary skill in the art will be familiar with the present specification, drawings, and claims, it will be appreciated that the mobile network interface and the proximity electromagnetic communication device may be implemented as a hybrid or combination transceiver or transceiving device I can think of something.

The portable communication device preferably further comprises a location transceiver, which can generally determine the physical coordinates of the device on the land as a function of its latitude, longitude and altitude. This position transceiver preferably utilizes GPS technology, and may be referred to herein as a GPS transceiver; The location transceiver may additionally (or alternatively) comprise a triangulation, assisted GPS (AGPS), GLONASS, E-OTD, CI, SAI, ETA, BSS, or GPS to determine the physical location of the portable communication device relative to the indicator It should be understood that other geo-localization mechanisms may be employed, including, but not limited to, similar. The altitude may be determined separately by other means, or it may be part of a GPS function. In addition, the position and altitude can be further optimized by a combination of various mechanisms. In selected embodiments, the location of the mobile device may be inferred by a collection of network identities (e.g., detectable WiFi SSIDs, discoverable Bluetooth beacon IDs, access point MAC addresses) and can be refined.

The portable communication device further includes a user interface for allowing some means for the consumer to receive information, as well as to enter information or otherwise respond to the received information. As is now understood, the user interface includes a microphone, an audio speaker, a haptic interface, a graphical display, and a keypad, keyboard, pointing device and / or touch screen (without intending to limit the disclosure) can do. The portable communication device will also include a microprocessor and a mass memory. The mass memory may include one or more removable memory cards as well as ROM, flash memory, RAM, non-volatile RAM, and the like. 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 may also include a device identification memory dedicated to identifying a device such as an electronic serial number (ESN), a mobile equipment identification (MEID), or an international mobile equipment identifier (IMEI). The portable communication device may also include a SIM card, or a subscriber identity module, such as a Universal Integrated Circuit Card (UICC), with a SIM application present and configured for network access. As is generally understood, SIM cards may include a unique serial number, an identity of the issuing operator, an internationally unique number of the mobile user (IMSI), security authentication and encryption information, Information, a list of services the user has access to, and two passwords (PIN for normal use and PUK for unlocking). As will be appreciated by one of ordinary skill in the art in the context of this specification, the drawings, and the claims, other information may be maintained in the device identification memory, depending on the type of device, its main network type, the home mobile network operator, have.

Portable communication devices can have two subsystems: (1) a "wireless subsystem" that enables communication and other data applications that are common today for cellular phone users, and (2) a "billing subsystem" Also known as a " secure transaction subsystem ". The secure trading subsystem includes a security element and associated device software for communication to management and provisioning systems as well as a customer facing interface for use and management of security data stored in the security element. It may be considered that this secure trading subsystem preferably includes security elements that are similar (if not identical) to those described as part of the global platform 2.1.X, 2.2 or 2.2.X (www.globalplatform.org) . The security element was implemented as a specialized, separate physical memory used in common practice in the industry to store payment card tracking data used in common point-of-sale management in the industry; Additionally, other security certificates that may be stored in the secure element may include employment badge credentials (enterprise access control), hotels and other card-based access systems, and pass-through certificates. Some portable communication devices may not have a secure trading subsystem and may not have a security element in particular.

Mobile network operator

Each of the portable communication devices is connected to at least one mobile network operator. The mobile network operator generally provides a physical infrastructure that supports wireless communication services, data applications, and secure trading subsystems through a plurality of cell towers in communication with a plurality of portable communication devices within an associated cell of each cell tower do. Eventually, the cell towers are operable 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 with other mobile network operators' Communication. Mobile network operators are generally referred to as GSM (Global System for Mobile Communications), 3G, 4G, code division multiple access (CDMA), time division multiple access (TDMA), user datagram protocol (UDP), transmission control protocol / Internet protocol), SMS, general packet radio service (GPRS), WAP, ultra wide band (UWB), WiMax (IEEE 802.16 Worldwide Interoperability for Microwave Access), SIP / RTP, One or more communication protocols and techniques, including, but not limited to, any of the wireless communication protocols.

Retail Subsystem

Today, the standard on the seller side is an Internet Protocol connected payment system that allows transactions of debit, credit, prepaid, and gift products of banks, and seller service providers. By swiping a magnetic stripe enabled card in the magnetic reader of the point-of-sale (or point-of-purchase) terminal, the card data is transferred to the point-of-sale management device to identify funds by the issuing bank . These point-of-sale management devices began to include contactless card readers as attachments that allowed payment card data to be provided via an RF interface instead of a magnetic reader. Dedicated payment applications, such as PayPass and Paywave, that transmit contactless card data from a card or from a mobile device that includes a payment subsystem, and data (e.g., data) via an RF interface by the ISO / IEC 14443 standard Is transmitted to the reader.

Retailer's point-of-sale management device 75 may be connected to the merchant payment network via a wireless or wired connection. The point-of-sale management network may be a direct connection, such as through local area networks (LANs), wide area networks (WANs), universal serial bus (USB) ports, . On interconnected sets of LANs, including those based on different architectures and protocols, routers act as links between LANs, allowing messages to be sent from one side to the other. Also, the communication links within the LANs typically include twisted pair or coaxial cables, but the communication links between the networks may be either full or partial dedicated digital lines, including analog telephone lines, T1, T2, T3 and T4, Digital Networks), Digital Subscriber Lines (DSL), wireless links including satellite links, or other communication links known to those of ordinary skill in the art. In addition, remote computers and other associated electronic devices may be remotely connected to LANs or WANs via modem and temporary telephone links. In essence, the point-of-sale management network is used between the point-of-sale management devices and the financial service providers for the purpose of validation identification, authorization, and ultimately capture of financial transactions at point-of-sale management for payment through the same financial service providers. Any communication method that allows information to be moved can be used.

System Management Bag End

The system includes a system management back end. 1B, the system management back end 300 may include a retail subsystem (see point of sale management device 75), a secure transaction subsystem (such as one or more financial A service provider) 310, and a plurality of portable communication devices 50. [ The system management back end 300 includes a server in operable communication with one or more client devices. The server also communicatively communicates with the retail store subsystem 75, secure trading 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 may be connected to the system back office 300 by means of the procedures and functions necessary to drive the system back office either serially or in parallel on the same computer or over a local or wide area network distributed on a plurality of computers , And may even be hosted by a third party service provider (known as "in the cloud") on hardware connected via the Internet. The computer (s) containing the server may be controlled by a Java 占 based operating system, referred to as Linux, Windows, Windows CE, Unix, or some of the most popular server technology platforms, Can be controlled by dedicated programming. The system management back end server is operatively associated with a large memory that stores program code and data. The data may include one or more databases, text, spreadsheets, folders, files, etc. that may be configured to maintain and store knowledge bases, user identifiers {phone number, email / IM address, billing information, .

The system management back-end server may support a case management system that provides call traffic connectivity and distribution across client computers within a customer care center. In a preferred approach utilizing VoIP voice channel connectivity, the case management system is a contact / case management system distributed by Contactual, Inc. of Redwood City, CA, USA. To a CRM system for use in providing VoIP-based customer care call centers that also provide usability for handling care issues and cellular-related care by simultaneous settlements. As can be appreciated by one of ordinary skill in the art with reference to the present specification, drawings, and claims, within the present invention, Salesforce (Salesforce.com, Inc., San Francisco, Calif.) And Novo (Novo Solutions, Virginia Beach, Va. , Inc. may be used.

The system management back-end server also includes an issuing engine 2010, a user unique identification database 2011, a merchant-geolocation collation database 2012, and a forecast transaction module 2015 Support. These elements will be described later in the specification.

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

Payment subsystem

2, each portable communication device 50 includes a one-time payment wallet 160, billing libraries 110, an NFC (or RF) baseband, a payment subsystem 150 Data store 115 and security element 120), and a diagnostic agent 170. [ The one-time payment purse 160 may include a certificate (e.g., a card, a coupon, an access certificate, etc.) in association with the NFC / RF baseband downloaded to the device 50 (preferably the payment subsystem 150) Control and ticket data) to any portable communication device. The application may also be implemented on legacy feature phones (non-smart phones) using WAP, J2ME RTE and / or SMS channels instead of smartphone applications. As will be discussed more fully herein below, certificates are most preferably NFC-based, but they may be traded by RFID or Bluetooth transmission, or may be represented by 2-D matrix codes, bar codes or Arabic numerals .

Billing libraries 110 manage the security element 120 (and perform housekeeping tasks), interfacing with the system management back end 300, and performing data communication (including SMS channels) Is used by a one-time payment purse 160 that performs over-the-air (OTA) provisioning via a transceiver. It may be contemplated that OTA data communications are encrypted in some manner and that the encryption key is located within a card service module that is operatively associated with the portable communication device 50 and the payment subsystem 150. In one embodiment, the card service module is operatively coupled to a one-time payment wallet 160 (which is disposed as a third party application described below) and a payment subsystem 150. The card service module generally controls access to data stored in the payment subsystem 150 and controls the function (s) that cause each application to be executed by the payment subsystem 150. In one embodiment, the card service module verifies the author / publisher of each third party application on the portable communication device to access the payment subsystem (as generally described below). The payment subsystem 150 may be used to store a certificate, such as a temporary one-time payment card, in addition to other payment card (s), coupon, access control and ticket data (e.g., transportation ticket data, concert ticket data, have. Some of these certificate types may be added to the payment subsystem and payment libraries depending on the circumstances.

If included, the secure data store 115 will provide secure storage on the portable communication device 50. Various security levels may be provided depending on the nature of the data for storage in the secure data store 115. [ For example, the secure data store 115 may simply be password-protected at the operating system level of the 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 the binary code. Alternatively, the data in secure data store 115 is preferably encrypted. More highly likely, however, the secure data store 115 is described in a patent application entitled " System and Method for Providing a Virtual Secure Element ", filed on October 21, 2011, pending U.S. Patent Application Serial No. 13 / 279,147 (owned by the assignee of the present application) which is "on a Portable Communication Device".

Dynamic temporary (for example, once) billing via smartphone

Some point-of-sale management devices do not accept NFC payments and some users do not set up non-contact-enabled payment accounts {e.g., MasterCard PayPass, Visa Paywave} , The present invention allows any portable communication device (including those that have NFC capabilities but no security elements and devices that do not have NFC capabilities) to accept non-contact payments or barcode electronic payments via their existing point-of- Enabling very secure electronic payments on the part of sellers.

To use the system for dynamic temporary (e.g., one time) payment to a retailer, the consumer downloads a dynamic temporary (e.g., one time) payment wallet application and uses at least one existing account . The consumer must also register at least one account by the payment publisher 310 (which may be a particular bank). In addition, the consumer must also have a mobile data service for their smartphone (or portable communication device 50).

The dynamic temporary (e.g., once) payment wallet 160 may remove some of the complexity associated with storing, maintaining, and using the certificate due to the combination of temporal attributes of the certificates and geolocation confirmation. Of the potential actions that can be controlled by the payment wallet 160, the following are associated:

a. {For example, set, reset or execute wallet passcodes; Obtain the URL of the OTA server; Over-the-air (OTA) registry provisioning; Set the payment timing; Increase payment timing; Set a default card; Publishers, list memory audits; Determining an SE for storing the certificate; Updating wallet status} Wallet management;

b. {Add the certificate; See the certificate details; Delete the certificate; Activate the certificate (for redemption / payment); Deactivate the certificate; Lock / unlock the certificate; Requesting passcode access; Obtain a certificate image; Set certificate access code} certificate management; And

c. 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 Management (SE) management of physical and / or virtual security element (s) for use by payment wallet 160 as disclosed in Application Serial No. 13 / 279,147 (e.g., obtaining a certificate; Update the certificate; Update the metadata; Delete the certificate; Lock / unlock wallet; Lock / unlock SE; Initialize / wipe / reset SE. In a device 50 that does not have a security element, the SE management may use various techniques to protect the received dynamic certificate, including encryption of standard memory under a user password.

Figures 3a and 3b show one potential embodiment (a variety of potential alternatives) for a process for obtaining and using a one-time (i.e., dynamic ad hoc) payment certificate using a "one-time" ) Together. Consumers can enter physical retail stores with their smart phones (i.e., portable communication devices 50) and roam for their shopping experience as usual. When a consumer prepares to check out a physical retail store using a one-time payment purse 160 downloaded on their smartphone 50, the consumer opens a solution-executable smartphone application using their smartphone This makes it possible to pay with a legacy system.

In the embodiment of FIGS. 3A and 3B, the consumer accesses a point-of-sale (POS) 75, opens a one-time payment purse 160 on the smartphone 50, The password / passcode of the consumer is entered via the interface (see FIG. 5). The one-time payment wallet 160 sends the customer's passcode and geolocation coordinates (as generated by the location identification service 165 in FIG. 2) to the issuing engine 2010 (FIG. 4). In one embodiment, the one-time payment purse 160 may also provide the consumer with the ability to communicate an estimate of the upcoming payment to the issuing engine 2010 prior to the generation of the temporary payment card information. By incorporating information related to estimates of one-time payments into the verification process, additional security for one-time code can be provided.

In the embodiment of Figures 3A and 3B, the issuing engine 2010 verifies the pass code (e.g., using the user unique identification database 2011). Receipt of the correct passcode indicates to the system that the consumer will be paid within a short predefined period of time (approximately a few minutes, which may extend in certain circumstances). In some embodiments, the publishing engine 2010 may also verify the digital signature of the 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 the paragraph stored in the device identification memory of each portable communication device 50. The publishing engine 2010 is predicted in a database (e.g., a seller-geolocation collection database 2012) operatively associated with the publication engine 2010 using geolocation coordinates received from the portable communication device 50 And determine the seller's point-of-sale management details. In particular, based on the received geolocation information, the issuing engine 2010 performs a database query to determine whether the non-contact point of sale point of sale terminal is installed (or is likely to be installed) at the consumer's location. In a preferred embodiment, the portable communication device 50 may also display a list of the next most likely retail locations where the portable communication device 50 can be located (e.g., the next top five) (e.g., , 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 be probed in the database, or otherwise infer the seller or facility where the consumer is located, and the device 50 Contact store management or access data that is different from the data formats that are specified for this location and / or the merchant to be supported, or the billing system 150 having an optimal representation of a card, coupon, ticket or access control emulation . The system may also allow the consumer to identify new card products available to the geolocation that have not yet been loaded into the payment libraries 110. In some embodiments, the system may load the requested libraries.

The issuing engine 2010 may be configured to determine the merchant location, the equipment identity, the merchant identification number used for electronic payments, the payment methods accepted by each merchant location, and the capabilities of the point-of-sale management of each merchant location, (E. G., Merchant / facility geo location collection database 2012), which may include < / RTI > (See Table 1 below). Although the seller / facility geo-location collection database 2012 is described as being included in the publication engine 2010 or otherwise as part of the publication engine, the seller / facility geo-location collection database 2012 includes a portable communication device 50, May be included in, part of, be associated with, or be hosted separately from host 310. In addition, it is further contemplated that the seller location may further include the seller's altitude. It should be appreciated that the seller / facility geo location can be represented using map coordinates, but can be effectively represented using street addresses or exclusive coordinates for the inspected baseline or point. The elevation of the seller / facility may be expressed as a physical length measure or a distance measure (e.g., feet, meters) with reference to a certified international map data (e.g., WGS84) It should be appreciated that the terms can be effectively expressed in relative terms, such as exclusive coordinates for the height reference to be investigated.

Table 1 - Examples of merchants and one-time payment information Seller name Seller location GPS (latitude / longitude) Seller location address Legacy Merchant ID Number Legacy Billing / Access Types Equipment capability Grocery Land 37.48N,
122.24 W Redwood City, Suite 400, California 94065
Marine Parkway 100 XQ24MZ122A barcode Laser Scanner Appliance Land 37.48N,
122.24 W Marine Parkway 110, Redwood City, CA 94065 YF234XY302 QR code Optical QR Code Reader Must Buy 37.48N,
122.24 W Marine Parkway 120, Redwood City, CA 94065 MN343D ISO / IEC 14443 / NFC ISO / IEC 14443 non-contact reader

Next, the issuing engine 2010 generates a one-time provisional payment card and transmits the temporary payment card data and the expected seller's identity to the portable communication device 50 over-the-air. The provisional payment card information includes personal account number, issuer identification number, {associated with issuer identification number (IIN) for international, inter-industry, and / or intra- IEC 7812, ISO / IEC 7813 (related to the data structure and content of magnetic stripe tracks used to initiate financial transactions), and ISO 8583 format (business messaging protocol based on proprietary standards). And can be formatted in real time using existing standards and practices.

In one preferred embodiment, the one-time payment purse 160 formats the temporary payment card based on the capabilities of the merchant's point-of-sale management device 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 the consumer with options that may be provided to the merchant cashier. Figs. 7A and 7B illustrate two of the possible types of one-time payment codes that can be transmitted to the portable communication device 50. Fig. 7A shows a one-time payment code as a 1-D bar code. As will be appreciated by one of ordinary skill in the art, the bar code may be a 2-D matrix code or a stacked linear barcode {e.g., QR code, Datamatrix, EZCode, PDF417 }. FIG. 7B shows a one-time payment code as a numeric code, which may be 16 digits as shown, or may be a different length as desired.

One format in which provisional payment card information can be provided on the smartphone display is an ISO / IEC 7813 compliant number (i.e., PAN) that an employee at a merchant manually enters into a seller's point of sale management. Another format in which provisional payment card data may be provided on the smartphone display is barcode (ISO / IEC 15426-1), 2-D barcode (ISO / IEC 15426-2), QR code (ISO / IEC 18004: 2006 ), Or similar methods that are transmitted by ASCII, alphanumeric, or numeric data and then captured by the optical scanner of the merchant ' s point-of-sale. Another format in which provisional 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) Mode (ISO / IEC 14443 card emulation) or RFID mode. Another format in which provisional payment card data may be provided is to use a sound wave or hypersonic audio carrier generated by a portable device speaker and received by an accessory appliance at a merchant's point-of-sale terminal.

The activated temporary payment card data expires after a short predetermined period of time, such as two (2) minutes to provide additional security. This time can be extended as long as the publisher wants. It is believed that less than 30 minutes, or even less than 20 minutes or even 10 minutes is desirable. Other expiration times may be utilized and / or programmed as desired.

The portable communication device 50 receives the temporary certificate data, the expected seller, and the emulation information from the issuing engine 2010. [ In the preferred embodiment, the portable communication device 50 confirms that the expected seller is correctly selected from the database 2012. [ In one approach, illustrated in connection with Figure 6, the portable communication device asks the user whether he has confirmed his location. In the illustrated example, the user interface queries whether the location is a "Grocery Land ". Consumers standing in the Grocery Land should select the "yes" button in FIG. 6, as shown in FIG. 1A. If the system chooses the wrong retailer, the system can provide an alternative to identify the correct retailer. For example, FIG. 6A illustrates a potential certificate that is adjacent to the proximity of consumers in an example where a certificate is required within one perceived by the issuing engine 2010 as a mall (or other closely packed sellers) Represents the preparation of a list of sellers. As will be appreciated by one of ordinary skill in the art to which this specification, the drawings, and the claims are concerned, the list of nearby sellers need not be limited to sellers within a single mall. Alternatively, it may be selected from other retailers geographically adjacent to geolocation received by the server. As further appreciated, as an example, a map overlay representing the geographic location of each retailer may be used as a topographic overlay, such as used in a mall, plaza, or building directory, - can be provided to the end user in the form of a pull-down menu or list.

In an embodiment where the consumer uses the portable device 50 to identify the seller, the expected seller's confirmation may be received by the issuing engine 2010. [ If the expected seller is incorrectly identified, the issuing engine may issue new emulation information to the portable communication device 50. [ If the anticipated seller is known, the forecasting transaction module 2015 of the issuing engine 2010 may include an ID for the expected seller, a unique user ID associated with the portable communication device 50, a one-time use token And the expiration time to a validation mapping gateway 2020. [

The verification mapping gateway 2020 may be physically hosted by the bank, by the publisher 310, or by the payment processor network and may be installed on existing transaction processors, card schemes, financial institutions, and other entities And may be deployed as a subsystem or as a service. Upon receiving the 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 that was previously associated with a unique user ID. To the extent that such an association exists, the mapping of the legacy card to the unique user ID is performed directly between the verification mapping gateway 2020 and the portable communication device 50 organized by the system management back end 300, By the publishers 310, or even by the consumer.

In a preferred embodiment, the predictive trading module 2015 sends data to the verification mapping gateway 2020 substantially simultaneously with the one-time use certificate information being transmitted to the portable communication device 50. [ In this approach, the verification mapping gateway 2020 can anticipate the consumer transaction from the merchant POS (75) via the merchant payment network. In particular, in such an embodiment, the verification mapping gateway 2020 receives data from the forecasting transaction module 2015 and from the retailer point of sale management 75, from a large database and (compared to the access time from a large database) A time between receipt of a transaction to fetch data stored in a memory providing faster access and a comparison between data received from the seller's payment network and stored data. In this approach, the addition of this additional verification step at the verification mapping gateway 2020 is triggered by the need to identify and retrieve the location of the data for this comparison after receiving the transaction from the POS 75 Will reduce the waiting time that could have been.

Returning to the consumer, after the portable device 50 receives the temporary certificate and the emulation information, the consumer may tap the smartphone 50 on the NFC peer-to-peer executive point-of-sale management device 75, , Which allows the portable communication device to emulate the certificate with a one-time payment code using the emulation protocol provided by the server. It is understood that the code may be "emulated " visually on the screen of the portable communication device 50. Since the temporary payment card data can be provided in legacy formats, the temporary payment card data can be accepted by the existing merchandise point-of-sale management equipment 75.

Next, the point-of-sale management device 75 processes the temporary payment card data through a general merchant payment network as if it were a standard credit or a debit credential. However, because the temporary payment card data uses the issuer identification numbers (ISO / IEC7812) that are registered and mapped to the one-time payment system provider as the publisher, the data will be routed through the merchant payment network to the verification mapping gateway 2020 routed. The verification mapping gateway 2020 may authorize the transaction if the data is received by the verification mapping gateway 2020 prior to expiration of the expiration time for the temporary certificate, and from the anticipated expected seller. The verification mapping gateway 2020 is also responsible for how the temporary payment card data is entered into the merchant point of sale management device 75 (the existing ISO 8583 designated field) and provisioned card data provisioned for the intended use in the mobile phone. You can compare methods (for example, numeric codes, bar codes, NFC).

Again, if all desired attributes support a low risk score (e.g., ad hoc code, run time, merchant ID, and emulation type), then the verification mapping gateway may send an authorization code Can be used to return confirmation to the seller. The merchant point-of-sale management 75 receives the authentication (i.e., confirmation of payment acceptance by the authorization code), prints the receipt, the consumer leaves their newly acquired items in the store, or the user accesses the controlled facility .

Alternatively, upon validation of the temporary payment card information (including timing and expected merchant ID), the system has the option to forward the equivalent payment transaction request to the publisher 310 to approve the transaction. This is known as executing a back-to-back payment transaction. In this manner, the consumer and the seller will receive a payment confirmation from the consumer's legacy bank credit card or debit card account instead of the temporary card number. In particular, once the one-time payment transaction is verified, the verification mapping gateway 2020 sends standard POS transaction information (e.g., merchant ID and transaction amount) and, in some embodiments, (to illustrate the added measure of security) Replaces the legacy card payment data in the transaction data that is passed on the issuer authentication systems 310 with an indication that the transaction used the verified one time use certificate. The publisher 310 will review the legacy card data and transaction information to determine whether the transaction will authenticate the transaction in a manner generally known in the art, perhaps by information that the transaction has the added security described above. The issuer certificate is sent back to the seller point of sale (75) via a common existing processing channel.

This one-time (or ad hoc) -use certificate solution can be used in many different types of certificate validation scenarios, including: credit and debit card payments, gift cards, loyalty cards, coupons and offers, access Control, transit fare, event ticketing, and any other environment in which the consumer provides a certificate for verification in a physical environment.

Although the functionality may be integrated within the one-time payment wallet 160, the user interface may be provided by a wallet user interface, and over-the-air provisioning and management and access to the secure payment subsystem may be provided by the card service It is supported by the functionality of the module. Based on the user interface, the card service module may be configured to communicate with an appropriate publisher server (e.g., for a one-time payment purse 160 that is a publishing engine 2010) in an encrypted manner as previously known in the art, 50), over-the-air (OTA) provisioning, security element management, and direct key exchange between card service modules on the network.

Verifying your one-time billing application as a third-party application

As illustrated in FIGS. 8A and 8B, a one-time payment purse 160 may be deployed as one of many trusted third-party applications 200. The card service module may be configured to store the card image data and any of the card image data, among other things, the security element 120 (or other, among others) on the portable communication device 50 to view, select, and / Verifies the trusted state of any application 200 before the application allows access to the secure data store 115 and even preferably the metadata store, which stores embossed card data. This verification can be accomplished by accessing a local authorization database of permitted 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 include various means including strong assembly references, technology executable code or hash coding of load files, API keys of an app developer, or technical platform facilities such as Auth tokens, May be identified using other means known to those of ordinary skill in the art of phone application development.

10 is a block diagram of a potential implementation of one potential combination of a card service module, a security element 120, and a local and remote authorization database to enhance the security of the payment subsystem 150. [ As shown in FIG. 10, the user A / C registry (or user account registry) may be associated with the server (or otherwise placed in the cloud). The user A / C registry can store an identification of the security element 120 that is placed in 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 authorized publishers. The issuer ID is unique for each type of certificate. That is, if the bank has multiple types of certificates (e.g., debit cards, credit cards, affiliate cards, etc.), then each certificate type has its own issuer ID (e.g., I-BofA-II) . In a preferred approach, the issuer ID between multiple types of certificates will have some common elements (e.g., I-BofA-I) to indicate that the certificate is at least relevant. In this way, applications from the same publisher can share data with other applications of the same "extended" publisher. In a preferred approach, the card service module may be simplified by requiring a wallet user interface (e.g., "ship with the system") with an issuer ID (as well as an application ID and a compilation token).

An "Application Registry" is a database of applications (mostly third party) preapproved by the operating system provider. As with the user A / C registry, the "application registry" and "publisher registry" databases are maintained on the server side in operative association with the one-time payment application (or otherwise hosted by a third party Internet access facility) . As one of ordinary skill in the art will appreciate, the various registries may be implemented in separate databases or in one integrated database. The data stored in the application registry of the one-time payment purse 160 at the beginning of the purse 160, and preferably at substantially regular time-intervals thereafter (e.g., daily), is stored locally And distributed to the devices.

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

The compilation ID (digital token) and the application ID (digital identifier) associated with the third party application are stored in the card service module 50 that is stored on the device 50 when the user attempts to entitle the application to the card service module on the device 50. [ And may be matched with a compilation ID and an application ID pair stored in the registry (Card Services Registry) (see FIG. 10). As one of ordinary skill in the art will appreciate, the same compilation and application ID pair is also transmitted to another device 50 associated with the system. If the compiled ID / application ID pair is matched with one of the pairs stored in the card service registry on the device, a Secret Token ID is preferred by the pseudo-random number generator (such as associated with secure element 120) Is generated in the device 50 and stored in association with the compiled ID / application ID pair in the card service registry on the device 50. In some instances, the compile ID may be preselected and used to seed the random number generator. It should be appreciated that one or more fragments of other predefined data associated with the card service registry may instead be preselected as a seed. The card service registry is preferably stored in a secure memory (rather than the security element 120 because the security 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.

Once 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 be placed in a publisher-specific certificate required for the verified (or trusted) And may launch and remind the user to participate in providing access. At each subsequent launch of the one-time payment wallet application 160, the embedded secret token and / or application ID are 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 via the card service module. In this way, it can be seen that the application 200 or the wallet user interface may also be removed from the card service registry, thereby disabling access to the payment subsystem and possibly the application.

The card service module also preferably uses a trusted application verification step to determine the appropriate level of subsystem access allowed for the one-time payment wallet 160. [ For example, in one embodiment, an application may be authorized to access and display all of the data contained in the payment subsystem 150, in which case the other application may only be authorized to display the data contained in the payment subsystem 150 Lt; / RTI > and may be authorized to access and display the subset. In another embodiment, the application may only be allowed to send a payment or transaction request to the one-time payment purse 160, but it may not be allowed to access any data contained in the payment subsystem 150 have. In one approach, the assignment of permissions to an application can be viewed as in Table 2 below:

Reserved All certificates Extended Publisher Certificates Your 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 the certificate 0 0 or 1 0 or 1 0 or 1

These usage rights can be used to form four hexadecimal numbers in order from the largest significant digit to the smallest significant digit. As shown in the exemplary card service registry of FIG. 10, the I-BofA-II publisher has a usage rights level 11111, which can be thought of as extending to 0001 0001 0001 0001 0001. That is, the I-BofA-II application can read, write, delete, activate / deactivate, and download its certificate, rather than the extended issuer certificate, rather than all certificates. If BofA had another issuer code (for example, I-BofA-I), this would be an extended publisher application. Thus, if the permission level of the application associated with the issuer ID "I-BofA-II" is set to 0010 0001 0001 0010 0001 (or hex 21121), then the application can read and activate the certificate associated with both issuer IDs, It will be disabled. In yet another example, the wallet user interface may be given a permission level of 44444 (i.e., 0100 0100 0100 0100 0100). That is, the wallet user interface can read, write, delete, activate / deactivate, and download all certificates. As one of ordinary skill in the art will appreciate, these are merely examples of potential use rights that may be granted to applications, and other usage rights may be contemplated. For example, some applications may have the ability to read an extended issuer certificate, but may only write, delete, activate, and download the application's own certificate (e.g., expand to 0010 0001 0001 0001 0001) 21111). In yet another example, an application may only be granted activation / deactivation and download usage rights (e.g., 0000 0000 0000 0001 0001 or 00011 in hexadecimal). In yet another example, an application may be disabled by setting all permissions to zero - not deleted from a trusted application database or card service registry.

In an embodiment in which 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 service module). The one time payment wallet application 160 has been developed by a publisher associated with the issuing engine 2010. In addition, the one-time payment wallet application 160 may emulate an NFC certificate. Thus, the one-time payment wallet application 160 should be given a usage rights level 11111, which can be thought of as extending to 0001 0001 0001 0001 0001. That is, the one-time payment wallet application 160 can read, write, delete, activate / deactivate, and download its own certificate, but not for extended issuer certificates or any other certificates.

The above description and drawings refer to the one-time payment purse 160 and the one-time payment certificates or information or the temporary payment card data that expires after a short predetermined period of time. However, the one-time payment wallet 160 may consider dynamic temporary wallet 160 instead, and it is recognized that one-time payment certificates / information and temporary payment card data may consider dynamic temporary credentials do. As such, certificates can (1) be "recycled" and reused in the system by other users; (2) have a predetermined time-to-live that is longer than a "short" predetermined period of time, and (3) those certificates are available for more simply purchased merchandise. While the above description and drawings primarily refer to a point-of-sale device 75 associated with a merchant, the above description, drawings and embodiments are not intended to be construed in a wide variety of other manners, such as hotel room transceivers, office transceivers, rental car transceivers, It is also contemplated that it can be applied to other electronic control points. For example, the electronic control points may include any access point, such as point-of-sale devices, RFID transceivers, barcode transceivers, NFC transceivers, and so on.

In particular, certificates generally must be "paid" by the publisher 310 or other organization within the larger merchant payment system. As such, systems can only have a limited number of certificates at the time of disposal. By using such certificates, only a single transaction with a particular user can lead to unnecessarily high costs relative to the system, where payment certificates are recycled for use by multiple users at different times, It is recycled in different geo-locations to provide additional security against fraud. For example, the issuing engine 2010 may be configured to issue expiration data associated with certificates to a first user running a first portable communication device 50 located in a first geolocation (e.g., California) Traces the expiration date of the certificates thereafter and sends very similar certificates to the second user driving the second portable communication device 50 located in another second geography (e.g., Florida) Can be assigned.

Similarly, certificates may have longer time to live periods to allow use of 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 a variety of payment cards (e.g., MasterCharge, VISA, Charge-It, etc. as illustrated in FIG. 9A) Applications (e.g., room keys at a hotel, office key cards, rental car FOB, etc., as illustrated in Figure 9B) and may be associated therewith. While the "lifetime" period is preferably short in the context of selling at point-of-sale to provide enhanced security, a "survival time" It can be remarkably longer. In such an example, the purse 160 may be used to "open" or "lock" a user's room at a hotel. Thus, the "lifetime" should be set to coexist at least with the user's stay in the hotel. Similarly, the lifetime can be set to a period (infinite, if necessary) that allows a user of the device 50 to use the device 50 to access an office or rental car.

It is also contemplated that the system management back end 300 and publisher 310 may be associated with non-financial services to allow use of non-payment wallet applications. For example, the system management back end 300 may include data (e.g., hotel location, office location, etc.) associated with non-financial services, and the publisher 310 may include non- (E. G., Hotel entities, office management entities, etc.). ≪ / RTI >

Publishers of electronic payment cards may wish to support extended lifetime dynamic certificates in certain selective environments. For example, a user may want to purchase using a payment certificate, but the point of sale management 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 in-flight purchases during an airline flight at a point-of-sale terminal. Later, the point-of-sale terminal may communicate the payment certificate received to the payment processing network to request payment from the customer's account. In other instances, users may want a temporary payment credential for use from their home in connection with Internet-based (or other computer networked, commerce) transactions. In other instances, the user may simply prefer to obtain a temporary payment certificate from the comfort of their home, in order to avoid the stress of having to queue in time at checkout of the retail establishment.

FIGS. 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, the user may initiate the registration process using their wallet application to obtain a temporary payment certificate from the cloud. A user may have an account (e.g., a credit card account, a debit account, etc.) in a bank (or other financial account provider) and use their portable communication device 50 to allow the user to make a payment You may want to subscribe to a payment service provided by a bank that allows you to do so. For example, as illustrated in FIG. 9A, a user may associate a temporary payment wallet application stored on a portable communication device 50 that has been previously verified as a trusted application (preferably, "Temp Pay" card from "Banc Two" by launching (in the manner illustrated). When the interim payment wallet application 160, the embedded secret token, and / or the application ID are compared with data in the card service registry on the device, the local matching will enable communication with the mobile banking platform or publishing engine 1102 11A).

If the user is authenticated, the temporary dynamic wallet application 160 may generate the tracking data based on the type of temporary payment certificate, user data, and contextual data when the user requests a temporary certificate . This temporary payment card data preferably includes a personal account number, an issuer identification number, an ISO / IEC (International Organization for Standardization) IEC (related to identification of issuers using an issuer identification number (IIN) 7812, a legacy electronic payment system, including ISO / IEC 7813 (related to the data structure and content of magnetic tracks used in early financial transactions), and ISO 8583 format (a business messaging protocol based on proprietary standards) the payment industry can be formatted using existing standards and practices. In some instances, 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 payment data can be processed by a legacy point-of-sale terminal. In one example, the payment data may include a data block formatted with some or all of the following fields (32 digits): account # (9 digits); IMEI (11 digits of device identifier); Expiration date (4 digits); Random number 6; And a sequence counter (2). The data block may also include one or more padding characters.

11A illustrates an exemplary communication flow that allows a user to subscribe to and obtain a temporary payment certificate in one potential embodiment of the process. A user may enable their portable communication device 50 to retrieve a wallet application from a mobile banking platform (or publishing engine) 1102 associated with a user's financial account provider and may be used to authenticate a user Login information can be generated. In element 1110, if the user desires to obtain a temporary payment certificate, the user can have the portable communication device 50 open a wallet application and enter login information. The login information may be, for example, a user name and a password. If the user has multiple accounts, the user can select a particular one to access the temporary payment system. In this embodiment, the publishing engine 1102 may also receive geolocation coordinates received from the portable communication device 50 at this request for later use in connection with a payment transaction.

At element 1110, the portable communication device 50 may communicate login information to the mobile banking platform 1102. [ In some embodiments, the mobile banking platform 1102 may pass a communication link to the originator 310 associated with the temporary billing application to ensure that the issuer recognizes the customer. As shown, in FIG. 11A, the publisher 310 may have a KYC (Know Your Customer) engine capable of communicating with the portable communication device 50 without the intervention of the 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 at the top of the temporary payment application 160 (see FIG. 9C) and receive user input directly from it and verify the customer. As shown in FIG. 11A, in this embodiment, the KYC engine may send an authorization message to issuing engine 1102.

If the user is successfully authenticated, at block 1112, the mobile banking platform 1102 may return an acknowledgment message indicating that the user has been authenticated. The user may request, at element 1114, to subscribe to the temporary payment certificate service using the wallet application. In element 1116, the mobile banking platform 1102 may generate communication security tokens and legacy card numbers and communicate them to the management back end 300. The communication security token is described in co-pending patent application No. 13 / 916,307, entitled " System and Method for Initially Establishing and Periodically Confirming Trust in a Software Application, " filed June 12, 2013, May be generated and used in accordance with the systems and methods disclosed in U.S. Pat.

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

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

In element 1130, the management back end 300 may request the user's legacy certificate data and the publisher 310 may retrieve and respond to the user's actual certificate data.

The portable communication device 50 may subsequently use the temporary payment certificate for purchase, which may include storing the temporary payment certificate for later use offline. When making a payment for a sales transaction, the user selects a temporary payment certificate (e.g., Banc Two Temp Pay) from their Wallet application. As discussed in connection with the one-time certificate, the wallet application can communicate track data and legacy bank BIN to a point-of-sale terminal, for example via an NFC tab or QR code scan. The point-of-sale terminal can process the bank BIN to route track data to a payment processing network that can forward track data to a third party Internet hosting service. Upon receipt of the temporary identification, the third party Internet hosting service may assess the risk, provide a score, and generate a request payment authorization from the bank authorization system. Once the payment is approved, the cloud service can communicate the approval message to the point-of-sale terminal and complete the sale accordingly.

Figure 12 illustrates a payment communication flow with a temporary payment certificate in one potential embodiment of the process. When purchasing, referring to element 1210, a user may launch a trusted wallet application and select which certificate to use for payment. For example, the Wallet application may provide access to multiple payment certificates, some of which may be temporary payment certificates, others may include payment for storing legacy card data (e.g., actual billing account information) Certificates can be stored. The user can select a temporary payment certificate and enter his or her corresponding PIN. In element 1212, the wallet application may generate payment data for the selected temporary payment certificate, which is then provided to the 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. Otherwise, the POS terminal 75 may reject the transaction locally. 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 will complete the sale later, via the seller's payment network, according to the following flow.

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 the authorization message. The authorization message may include Trackl / Track2 data, merchant ID (and preferably seller's geolocation), and transaction volume. In element 1218, the payment network system 1204 processes the authorization message, determines whether it contains data for routing to the management backend 300, and reroutes the authorization message to the verification mapping gateway 2020 )can do.

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

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

(b) the difference between the seller's geolocation and the geolocation of the device (50) when a temporary certificate is issued;

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

(d) the date of repayment;

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

(f) Amount of seller authorization request;

(g) the type of seller;

(h) a user's historical usage pattern; And

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

For example, the age of a certificate can be compared to the difference in geolocation to provide a critical risk assessment. In particular, if the certificate was issued earlier than one hour but is in geolocation hundreds of miles away from the current seller it is being offered for repayment, the transaction will be doubtful. In this way, various parameters can be considered by the risk scoring engine to generate a risk score. This risk score, along with legacy payment data, can be passed to the issuer for authorization decision as a second authorization message, which is step 1222. The publisher 310 processes the second Track 1 / Track 2 data to determine whether to authorize the transaction. Once authorized, the publisher 310 may respond to the management back end 300 with the authorization message in the element 1224. The management back end 300 may remap the second Track 1 / Track 2 data to the first Track 1 / Track 2 data and forward the second authorized message to the payment network system 1204. In some embodiments, a publisher may receive information about the user's digital device signature so that the publisher can communicate directly with the end user via device 50 to request input of the CVV (see Figure 9d). The publisher can use this information to further validate the transaction.

In element 1230, the payment network system 1204 may optionally forward a second authorized message to the POS terminal 1202. In an offline transaction, 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 a proof of accountability transfer to the issuing bank. In the case of online transactions, the POS terminal 1202 may optionally wait for a transaction to be approved until receipt of the second authorized message.

In this new method, the geolocation data will be captured by the portable device payment wallet, rather than (or in addition to) being issued, upon authorization. In this new method, the geolocation data can also be encoded by the payment wallet into a data format (e.g., any data fields of the Track 1 / Track 2 data format) to be redeemed at the POS or access point. Next, the back-end risk engines may score the risk associated with the reimbursement of a single token previously issued at a particular vendor or facility identified by geolocation data. However, in this new method, the token can be well-issued prior to use and can be refreshed as policy requirements, thus minimizing the threat of theft or exploitation.

Dynamic certificates / 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 (for example) for a rate limit and other reimbursement policies. It is also contemplated that dynamic certificates may only be redeemable within certain vendors or within certain redemption restrictions (volume, date, time of day). This is not just payment, it should be specific to supporting physical access applications (eg, hotel doors, campus buildings). These tokens will also be issued well in advance of use.

The above description and drawings are only for illustrating and illustrating the present invention, and the present invention is not limited thereto. While the specification has been described in connection with certain implementations or embodiments, many details are presented for the purpose of illustration. Accordingly, the foregoing merely illustrates the principles of the present invention. For example, the invention may have other specific forms without departing from its spirit or essential characteristics. The described arrangements are illustrative and not limiting. Those of ordinary skill in the art can add implementations or embodiments to the present invention, and any of the details described in the present application can be significantly modified without departing from the underlying principles of the present invention. Thus, those of ordinary skill in the art will appreciate that, although not explicitly described or illustrated herein, various arrangements may be devised to implement the principles of the invention within the scope and spirit of the invention.

Claims (11)

CLAIMS What is claimed is: 1. A portable communication device for use in a transaction with an electronic control point, the portable communication device having a service for providing a current geo-location of the portable communication device, A system for issuing a dynamic temporary credential, the system comprising:
Means within the centralized computer for receiving the current geolocation of the portable communication device;
- means for sending the dynamic temporary certificate from the centralized computer to the portable communication device; And
Means for scoring the risk of authorizing a transaction associated with the electronic control point using the dynamic temporary certificate;
≪ / RTI > The method according to claim 1,
Further comprising means for authenticating an end user of the portable communication device, wherein the means for transmitting the dynamic temporary certificate does not function until the end user authentication means authenticates the end user. 3. The method of claim 2,
Further comprising a user database providing associations between the end user name and the passcode, wherein the authenticating means is operatively associated with the user database and authenticating the end user by verifying the passcode. The method of claim 3,
Wherein the portable communication device has a unique digital signature and the authentication means further authenticates the end user by pairing the authenticated end user with the unique digital signature. 5. The method of claim 4,
Further comprising means for identifying an identity of a customer. 3. The method of claim 2,
Wherein the portable communication device has a unique digital signature and the authentication means further authenticates the end user by paired with the authenticated end user and the unique digital signature. The method according to claim 1,
Further comprising a validation mapping gateway operatively connected to one or more issuers, wherein the system is operable to issue a payment to the issuer associated with the legacy payment data, along with a risk score, Further comprising means associated with the verification mapping gateway for replacing the dynamic temporary certificate with the legacy payment data in the payment transaction prior to dispatching a payment transaction. 8. The method of claim 7,
Wherein the means for scoring the risk determines the distance between when the dynamic temporary certificate is issued and the geographic location of the portable communication device at the time of the transaction. 8. The method of claim 7,
Wherein the means for scoring the risk is based on the geolocation of the portable communication device at the time of the transaction and the geographical location of the portable communication device depending on the consistency of the geographical location of the merchant included in the transaction authorization message, To determine the system. 8. The method of claim 7,
Wherein the means for scoring the risk determines to increase the risk associated with the increasing time since issuance of the dynamic temporary certificate. 8. The method of claim 7,
The means for scoring the risk may include determining the consistency of the seller ID with the seller type and / or the seller type predicted when the dynamic temporary certificate is issued and / or the seller ID predicted by the management back end , system.

Images