US20140279554A1 - Distributed authenticity verification for consumer payment transactions - Google Patents
Distributed authenticity verification for consumer payment transactions Download PDFInfo
- Publication number
- US20140279554A1 US20140279554A1 US13/797,287 US201313797287A US2014279554A1 US 20140279554 A1 US20140279554 A1 US 20140279554A1 US 201313797287 A US201313797287 A US 201313797287A US 2014279554 A1 US2014279554 A1 US 2014279554A1
- Authority
- US
- United States
- Prior art keywords
- token
- consumer
- transaction
- merchant
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
Definitions
- a token that identifies a source of funding.
- a credit card containing a magnetic strip is a token.
- Payment tokens usually contain static information, such as an account number, identifying a source of payment.
- the centralized payment processing system may verify whether the account exists and is active, whether the account can fund the transaction, or whether the transaction may be fraudulent.
- a physical token such as a credit card cannot be easily modified and, in the event that it is lost or stolen, the consumer must report the lost card and wait for a replacement to be mailed.
- the token cannot be used for payment without significant risk of fraud.
- Some merchants may copy (e.g., take a credit-card imprint) or otherwise save the consumer's account information or token, deliver goods to the consumer, and attempt to process the payment at a later time when the network is restored. But if the token is a fraud, the merchant will not get paid.
- the mere act of copying account information creates a risk of theft for the owner of the token.
- the present invention addresses these problems by encrypting a payment token for display on a consumer's mobile device with dynamic trust data (e.g., transaction history and/or token generation date) along with the financial account information.
- dynamic trust data e.g., transaction history and/or token generation date
- the invention pertains to a method of processing a transaction among a consumer, a merchant point-of-sale system and a transaction-processing entity.
- the method includes generating a token encrypted with data identifying a financial account of the consumer and trust data for the consumer; receiving and storing the token by a device of the consumer; reading and decrypting, by the merchant system, the token upon presentation thereof by the consumer's device in connection with the transaction; authorizing, by the merchant system, the transaction based on (i) successful decryption of the token and (ii) the trust level without communication with the transaction-processing entity; subsequent to authorization of the transaction by the merchant system, communicating, by the merchant to the transaction-processing entity, a record of the transaction and authorization thereof; and following the communication from the merchant system to the transaction-processing entity, completing the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- the authorized transaction may be completed upon approval by the transaction-processing entity of a basis for the
- the trust data contains at least a token generation time, a transaction history of the consumer, a spending limit of the consumer or, a home region of the consumer.
- the trust data may be a single trust-factor value.
- the token may be encrypted using public key cryptography. As an alternative to encryption, the token may be signed with a digital signature.
- the token may be displayed as a “Quick Response” (QR) code on the consumer device, and may be a one-time-use token.
- QR Quality of Response
- the method may additionally include generating and storing, on the consumer device, a plurality of tokens. Following a triggering event, such as expiration of a pre-set time period or presentation of the token, a first token may be marked for deletion and a second token may be marked for display on a subsequent presentation. The presentation of the first token may comprise receiving confirmation from the merchant system that the token was received. Additionally, the method may include generating a token to replace the token marked for deletion. In various embodiments, the token may not be marked for deletion until a deletion communication is received from the transaction-processing entity. Alternatively, following presentation of a first token, the first token may be marked for deletion and a second token is marked for display after a predetermined time period.
- the tokens may be used by removing them from the stack and used tokens are replaced with new tokens.
- the tokens may be stored in a stack for sequential access on a first in, first out basis.
- the tokens are stored in a stack for sequential access on a first in, last out basis.
- the consumer may be identified prior to generating the token.
- the invention in another aspect, relates to a system for processing a transaction among a consumer, a merchant and a transaction-processing entity.
- the system includes a token server for (i) generating a token encrypted with data identifying a financial account of the consumer and trust data for the consumer, and (ii) communicating the token to a device of the consumer; a point-of-sale system for reading and decrypting the token upon presentation thereof by the consumer in connection with the transaction, the point-of-sale system being configured to authorize the transaction based on (i) successful decryption of the token and (ii) the trust level without communication with the transaction-processing entity; and a transaction-processing server configured to (i) receive, from the point-of-sale system subsequent to transaction authorization, a record of the transaction and authorization thereof, and (ii) cause completion of the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- the point-of-sale system may be configured to authorize the transaction based at
- the token server may be configured to embed an expiration time in the generated token. Additionally, the token server may be configured to embed a creation time in the generated token. The token server may be configured to generate and communicate a series of tokens to the device. In various embodiments, the token server may be configured to verify the consumer's identity prior to token generation.
- the invention pertains to a method of processing a transaction among a consumer, a merchant point-of-sale system and a transaction-processing entity.
- the method includes generating a token with a digital signature, encrypted using a private key, with data identifying a financial account of the consumer and trust data for the consumer; receiving and storing the token and the signature by a device of the consumer; reading the token and decrypting the signature, by the merchant system, upon presentation of the token by the consumer's device in connection with the transaction; authorizing, by the merchant system, the transaction based on (i) successful verification of the signature and (ii) the trust level without communication with the transaction-processing entity; subsequent to authorization of the transaction by the merchant system, communicating, by the merchant to the transaction-processing entity, a record of the transaction and authorization thereof; and following the communication from the merchant system to the transaction-processing entity, completing the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- the invention in another aspect, relates to a system for processing a transaction among a consumer, a merchant and a transaction-processing entity.
- the system includes a token server for (i) generating a token with a digital signature, encrypted using a private key, with data identifying a financial account of the consumer and trust data for the consumer, and (ii) communicating the token to a device of the consumer; a point-of-sale system for reading and decrypting the signature upon presentation of the token by the consumer in connection with the transaction, the point-of-sale system being configured to authorize the transaction based on (i) successful verification of the signature and (ii) the trust level without communication with the transaction-processing entity; and a transaction-processing server configured to (i) receive, from the point-of-sale system subsequent to transaction authorization, a record of the transaction and authorization thereof, and (ii) cause completion of the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances.
- articles “a” and “an” as used in the subject specification and annexed drawings should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
- the terms like “consumer equipment,” “mobile station,” “mobile,” “communication device,” “access terminal,” “terminal,” “handset,” and similar terminology refer to a wireless device (e.g., cellular phone, smart phone, computer, PDA, set-top box, Internet Protocol Television (IPTV), electronic gaming device, printer, and so forth) utilized by a consumer of a wireless communication service to receive or convey data, control, voice, video, sound, gaming, or substantially any data-stream or signaling-stream.
- IPTV Internet Protocol Television
- the foregoing terms are utilized interchangeably in the subject specification and related drawings.
- the terms “component,” “system,” “platform,” “module,” and the like refer broadly to a computer-related entity or an entity related to an operational machine with one or more specific functionalities.
- Such entities can be hardware, a combination of hardware and software, software, or software in execution.
- a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
- an application running on a server and the server can be a component.
- One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon.
- the components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
- a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
- FIG. 1 is a block diagram of an exemplary network in accordance with an embodiment of the invention.
- FIGS. 2A , 2 B, and 2 C are block diagrams of an exemplary consumer device, token-generation server, and merchant system, respectively, in accordance with an embodiment of the invention
- FIG. 3 depicts an exemplary system for performing secure payment transactions in accordance with an embodiment of the invention.
- FIGS. 4A , 4 B, and 4 C are flowcharts illustrating performance of secure payment transactions in accordance with an embodiment of the invention.
- FIG. 1 depicts an exemplary mobile-payment transaction network 100 including a consumer device (e.g., a mobile device) 102 linked to a network 104 (e.g., a cellular telephone network, the Internet, or any wide-area network or combination of networks capable of supporting point-to-point data transfer and communication) that supports wired, wireless, or any two-way communication.
- the network 104 connects various devices, including a token-generation server 106 , one or more merchant systems (e.g., POS terminals) 108 , and a payment processor 110 utilizing, again, wired, wireless, or any two-way communications.
- the token-generation server 106 is responsible for generating encrypted, unique payment tokens associated with the consumer.
- Each merchant system 108 may be associated with a merchant who offers goods or services for sale to the consumer possessing the mobile device 102 .
- the merchant system 108 is a POS system (e.g., an electronic cash register) that connects to a code reader or scanner (hereafter “reader”) 112 .
- the reader 112 may be capable of reading and/or decoding a payment token, in the form of, for example, a barcode, a radio frequency identification (RFID) code, or a QR code, and/or receiving signals, such as NFC signals, acoustic signals, or infrared signals.
- the reader 112 may be mobile or physically associated with the merchant system 108 .
- the merchant system 108 may be responsible for decrypting the decoded payment token information and authenticating the payment transaction based on information provided therein.
- the payment processor 110 may be responsible for actually performing the payment transaction and, in some cases, for decrypting the payment token.
- a so-called “direct” payment processor represents the financial-processing backend provider to credit-card issuers and payment services such as PAYPAL.
- An “indirect” payment processor is an independent entity processing transactions for multiple payment services and maintains its own records and data.
- the payment processor 110 may also be configured to decrypt and authenticate the token as a second verification layer.
- the mobile device 102 acts as a gateway for transmitting the consumer's data to the network 104 .
- the mobile device 102 can support multiple communication channels for exchanging multimedia and other data with the server 106 and other devices using a Wi-Fi LAN (e.g., IEEE 802.11 standard) for Internet access, a short-range Bluetooth wireless connection for point-to-point access, and/or an NFC channel for close-proximity access.
- a Wi-Fi LAN e.g., IEEE 802.11 standard
- the mobile device 102 includes a conventional display screen 202 , a user interface 204 , a processor 206 , a transceiver 208 , and a memory 210 .
- the transceiver 208 may be a conventional component (e.g., a network interface or transceiver) designed to provide communications with a network, such as the Internet and/or any other land-based or wireless telecommunications network or system, and, through the network, with the token-generation server 106 .
- the memory 210 includes an operating system (OS) 212 , such as GOOGLE ANDROID, NOKIA SYMBIAN, BLACKBERRY RIM or MICROSOFT WINDOWS MOBILE, and a code process 214 that implements the device-side functions as further described below.
- OS operating system
- the term “mobile device” used for transacting a mobile payment refers to a “smart phone” or tablet with advanced computing ability that, generally, facilitates bi-directional communication and data transfer using a mobile telecommunication network, and is capable of executing locally stored applications and/or payment transactions.
- the memory 210 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and random access memory (RAM).
- ROM read only memory
- RAM random access memory
- BIOS basic input/output system
- BIOS basic routines that help to transfer information between elements, such as during start-up, is typically stored in ROM.
- BIOS basic input/output system
- RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit.
- the token-generation server 106 is a trusted system that generates encrypted payment tokens. In response to requests made by a registered user via the consumer device 102 , the server 106 generates tokens and transmits them to the consumer device 102 for presentation to complete a transaction.
- the token-generation server 106 includes a processor 222 and a memory 224 , which may include volatile and non-volatile portions.
- the memory 224 contains instructions, conceptually illustrated as a group of modules, that control the operation of the processor 222 and its interaction with hardware components.
- An operating system 226 directs the execution of low-level, basic system functions such as memory allocation, file management and operation of mass storage devices.
- a look-up module 228 performs the basis system functions described in greater detail below.
- the communication module 234 may be a conventional component (e.g., a network interface or transceiver) designed to provide communications with a network, such as the Internet and/or any other land-based or wireless telecommunications network or system, and, through the network, with the mobile device 102 , the merchant system 108 , and the payment processor 110 .
- the web-server block 236 enables web-based communication with the mobile device 102 , and can be a conventional web-server application executed by the processor 222 .
- a consumer database 240 may reside in a storage device 238 and/or an external mass-storage device 242 accessible to the token-generation server 106 ; the consumer database 240 stores, for example, a record associated with each registered consumer, or device, with associated trust data (e.g., transactional data).
- the database 240 is responsive to queries from lookup module 228 .
- the user operates an executable, interactive application (an “app”) on the mobile device 102 identifies himself to the server 106 , e.g., using a password or other strong form of authentication.
- the look-up module 228 obtains the user's account records from the database 240 and, using the PKI module 230 , generates an encrypted token for that user using a private key.
- the encrypted token contains information to uniquely identify the token or the user of the token, as well as trust data from the user's database record. Trust data may also reflect the time the token was generated, since more recently created tokens are considered more trustworthy (since the likelihood of fraudulent access or use increases over time). In general, trust data reflects a probability that the payment processor 110 will ultimately authorize the desired payment on the user's behalf.
- the trust data may specify how many transactions the consumer has processed in the past (in some embodiments, more recent transactions may receive a greater trust weight), the spending limit of the consumer, the home region of the consumer, the transaction history of the consumer (in some embodiments, transactions at merchants where the consumer has transacted previously may receive a greater trust weight), the age of the consumer's account (which may be correlated with the user's transaction history, but is a distinct piece of information which is much smaller to store), and other demographic information.
- Additional trust factors can include trust levels of other individuals with whom the user is somehow associated (e.g., social network “friends”), as well as trust levels associated with those individuals' friends and the number of funding sources the user has.
- a user with only a single funding source may be a higher risk than a user with multiple funding sources (e.g., one credit card or bank account on file, versus many different accounts on file). This may also be based on the institutions in which the accounts are held, as it is less likely for a user to close accounts across different institutions simultaneously.
- an aggregated “trust-factor” value is calculated that collapses all of these various metrics into a single value to be included in the token.
- the trust-factor value may be numeric or may simply be a coarse level, e.g., low, medium, or high.
- Trust data may be updated when the registered user initiates or completes a new transaction, e.g., when the server 106 receives a record of a new transaction from the payment processor 110 via the communication module 234 .
- the trust data is updated periodically in a predetermined time period. For example, the trust data may be updated at a set time each day based on transactions that the user has completed within the previous 24 hours. The trust data may also be updated continuously based on patterns from all transactions processed, including transactions not involving the particular user. Similarly, the trust data may be updated continuously based on the trust factor of that person's social network “friends.”
- the server 106 transmits the generated token back to the mobile device 102 via the communication module 234 .
- the token, encrypted using the private key may be decrypted using a public key; the latter is made available to merchant systems 108 to use in the course of transactions in accordance herewith.
- the private key and associated public key are reset periodically (e.g., in a predetermined period of time) for security purposes; the public key is communicated, via communication module 234 , to the merchant system 108 upon every reset.
- the private/public key pair is unchangeable.
- the token may be an authentication that is read directly by the merchant system 108 using, for example, NFC; may encode an optically readable “mature code” (e.g., a QR code or a bar code) that is displayed on the screen of the mobile device 102 ; or may be a “seed code” from which the mobile device 106 (via the app) can generate a mature code later.
- an optically readable “mature code” e.g., a QR code or a bar code
- the merchant system 108 includes a processor 252 , a memory 254 , an operating system 256 , a decision module 258 , a decryption module 260 , a web server block 264 , a communication module 266 , and a storage device 268 .
- the various functional modules are typically implemented as stored instructions that operate as running processes via the processor 252 .
- the merchant system 108 may be connected to or include the reader 112 , which is capable of reading payment tokens according to any suitable modality (optical, NFC, etc.) from a consumer's mobile device 102 .
- the decryption module 260 stores the public key and decrypts the token obtained by the reader 112 .
- the decision module 258 may, in some embodiments, further authenticate the token or the consumer if decryption is successful (e.g., by requesting a password or biometric indicium, such as a fingerprint, from the consumer).
- the decision module 258 decides, based on the decrypted trust data, whether to authorize the transaction as further described below. Accordingly, the merchant system 108 does not require continuous network access in order to authorize transactions. The transaction may be authorized based on the trust data and transactional information saved in storage device 268 for later transmission through the network 104 for processing on a back-end server (e.g., the payment processor 110 ).
- payment transactions in accordance herewith may involve different stages that need not take place in tandem or at specific times, but instead may occur whenever a network connection can be established: a token-generation stage 302 , a payment-initiation stage 304 , a payment-authorization stage 306 , a funds-transfer stage 308 , and a database-update stage 310 .
- the payment initiation stage 304 does not require a network connection when the encrypted token is read from the mobile device 102 by a POS merchant system 108 .
- the various stages are described in further detail below.
- FIGS. 4A , 4 B, and 4 C A representative method 400 for safely transacting a payment without continuous network access in accordance with embodiments of the current invention is shown in FIGS. 4A , 4 B, and 4 C (with additional reference to FIGS. 1 and 2 A- 2 C). Assuming the consumer is registered with the token-generation server 106 , the consumer, or an application acting on behalf of the consumer, can log in to the server 106 to retrieve a payment token.
- the consumer may download an app onto her mobile device 102 (step 402 ); the app, when executed on the mobile device 102 , communicates with the token-generation server 106 and allows the user to log in by supplying a proof of identify, such as a username/password pair (step 404 )—either to the app, which then transmits the log-in information to the server 106 , or to the server 106 directly via, for example, a web session—and request a token.
- This request is transmitted to the token-generation server 106 (step 406 ).
- the identifying information is verified (step 408 ), once again either by the app or by the token-generation server 106 , and the look-up module 228 of the token-generation server 106 looks up the consumer's account data stored in database 240 (step 410 ) and generates a token for the consumer.
- the token contains data that identifies the consumer and/or the token as well as trust data for the consumer.
- the token may contain actual financial account information of the consumer or may instead contain information (such as an email address, telephone number, or random unique data) that can be mapped to the consumer's account by the payment processor 110 .
- the token is encrypted using the private key (step 414 ).
- the encrypted token is then transmitted to the mobile device 102 (step 416 ).
- the present invention may be implemented using any asymmetric encryption method in which a secret key is known only to the token-generation server 106 .
- the private key may be used to digitally sign the token and successful verification of the signature proves the token's authenticity.
- Digital signatures utilize the public key infrastructure to ensure authenticity (i.e., that no one has tampered with the token in transit and that the token was indeed generated by the token-generation server 106 .)
- the client app running on the mobile device 102 receives and stores the encrypted token (step 418 ).
- the token-generation process may take place at any time after a consumer registers an account.
- the token may be delivered to the mobile device 102 at any time a network connection can be established. Generation of the token and delivery of the token may occur as two separate steps and may not happen at the same time.
- the device 102 need not be continuously connected to network 104 and sporadic connectivity is sufficient to gain the benefits of the present invention.
- the token can be rotated.
- the client app may be configured to check for network connectivity after a period of time, corresponding to the desired lifetime of a token, has elapsed since the token was received.
- the client app periodically checks until it detects a network connection.
- the client app may poll for connectivity, or the app may asynchronously monitor for connectivity changes.
- the operating system of the mobile device 102 may have facilities to notify apps asynchronously when network connectivity returns.
- the app may also be programmed wait for a triggering event before communicating with the server.
- this triggering event may be in the form of the user opening the app, the user clicking a button to refresh his token, or other triggers as determined by the app's programming. If two-way communication between the app and the merchant system 108 is possible, the app may rotate the token after communicating the previous token to the merchant system 108 .
- the app causes the mobile device 102 to communicate with the token-generation server 106 to obtain a replacement token.
- the app passively monitors for other network traffic on the device prior to communicating with the token-generation server 106 in order to optimize power consumption.
- the app causes the old one to be invalidated (so that the consumer uses only the newest token in a transaction).
- the rotation of tokens may be initiated by the payment processor 110 .
- the payment processor 110 may send a “push notification” message to the application, either periodically or after a triggering event. For example, the app may display a token but not know when that token has been successfully used to complete a transaction.
- the payment processor 110 may therefore send a push notification to the device to rotate the token.
- the token may be contained in the push notification or, instead, the push notification may simply be a “tickle” to cause the mobile device 102 to initiate a request to obtain a new token. If the mobile device 102 is offline when the push notification is sent, delivery of the push notification may be queued for delivery once the mobile device 102 comes online again.
- the process of networked code rotation is far more secure than simple static tokens.
- the token-generation server 106 may generate and deliver an encrypted, ordered stack—or “quiver”—of tokens for secure storage in the mobile device 102 . Whenever the consumer displays a token on the mobile device 102 (even if a payment transaction is not initiated), it is locally marked as displayed and the next token in the stack is marked for display. This process repeats each time a token is displayed.
- the app each time a token is displayed, the app causes the mobile device 102 to attempt to establish a network connection and, when the connection is established, commands the token-generation server 106 to mark the current token (i.e., the one on display) code for invalidation after a short period of time (e.g., in 60 minutes) and to invalidate all tokens preceding it in the stack (in case some had been displayed without a network connection).
- the current token which is assumed to have been displayed because a transaction is imminent—is invalidated within a reasonable time to prevent fraud, since a token is at particular risk for fraudulent acquisition and use when displayed.
- the token-generation server 106 may generate and transmit to the mobile device 102 enough new tokens to “refill” the quiver; the new tokens may be stored at the back end of the quiver so that older tokens are used on a first in, first out (FIFO) basis. FIFO operation ensures that the consumer always has newer tokens on hand. Alternatively, the new tokens may be stored at the front end of the quiver for last in, first out (LIFO) operation. While FIFO is preferred for extended periods of offline access, LIFO is generally better for security: newer tokens may have newer fraud information embedded in them, which benefits the payment network if they are used first.
- each token in a quiver is given a sequence number (e.g., the first token is sequence 1 , the last token is sequence 30 ). This sequence number may be embedded in the token itself, acting as a form of trust data. If the mobile device 102 goes a long period of time without connecting to the token-generation server 106 , the last token in the quiver may be used for a long period of time.
- the merchant system 108 is configured to reject the last token in a quiver when the mobile devices are operating in distributed mode and are not able to communicate with the payment processing system (e.g., the network is down).
- each token in the quiver has a different validity period embedded in its trust data, and not all of the tokens in the quiver are valid simultaneously. This reduces the likelihood that any given token in the quiver can be stolen and used fraudulently.
- a payment transaction is initiated when the consumer presents a token (e.g., in the form of a QR code) stored in the mobile device 102 to the merchant system 108 (step 420 ).
- the merchant system 108 may scan the code using the reader 112 (step 422 ), and thereupon decrypts the token using the public key (step 424 ). Any token that unsuccessfully decrypts is either fraudulent or corrupted, and the transaction is denied (step 426 ). Any token that successfully decrypts is guaranteed to have been created with private key, and is assumed to have come from the token-generation server 106 .
- the merchant system 108 may then attempt to transmit the token along with information about the transaction (the amount to be paid, in particular) and the merchant's own identity to the payment processor 110 , and await approval or denial. If a network connection cannot be established, however, the merchant system 108 can itself approve the transaction based on the trust data in the token using the decision module 258 (step 428 ). Although this does not guarantee that the payment processor 110 will ultimately authorize the transaction, if the token decrypts successfully and was generated within a certain amount of time, and the trust data is satisfactory, the risk may be acceptable to the merchant.
- the criteria applied in evaluating the trust data may be universal across the system 100 or may be specific to particular merchant systems 108 .
- a merchant may choose only to accept tokens from consumers whose home region is within a set distance of the POS; tokens from consumers who have transacted with the merchant previously; tokens that have been generated within a set time period; and/or trust data reflecting a transaction history success rate above a threshold percentage or number.
- the transaction history may be weighted in favor of more recent transactions in determining whether the threshold acceptability level is reached.
- the threshold acceptability level may vary with the amount of the transaction, and different criteria may receive different weights that themselves vary with the transaction amount.
- the trust criteria may be selected and combined in accordance with the priorities and preferences of the merchant and programmed into the decision module 258 , which scores each transaction accordingly. It should be emphasized that trust criteria can include any factors relevant to a risk score, e.g., the location of the merchant scored against local aggregated crime statistics from public databases.
- the merchant system 108 authorizes the transaction (step 430 ) and communicates the authorization along with the encrypted token and information about the transaction and the merchant's own identity to the payment processor 110 when a network connection is available (step 432 ); assuming the consumer's financial account is in good standing, the payment processor 110 will transfer funds to the merchant. Until a network connection can be established, the token and transaction information are saved to the local storage 268 in the merchant system 108 for transmission when network connectivity is available (step 434 ).
- a middle ground can be established between autonomous approval by the merchant system 108 and connectivity to the payment processor 110 .
- an “agent” of the payment processor 110 i.e., a program supplied by the payment processor 110 and executing as a running process on the merchant system 108 —provides the approval based on the trust data and the token.
- the approval criteria are supplied by the payment processor, not the merchant, so that upon transaction approval by the agent, the merchant is guaranteed to receive payment from the payment processor 110 .
- the agent is supplied as an executable file
- the criteria utilized by the payment processor 110 may be proprietary—i.e., hidden from merchants or other users of the executable file.
- the agent causes transaction data to be stored locally and sent to the payment processor 110 when network connectivity is available.
- the agent may be supplied to the merchant as a secure (hidden) executable file or, in some embodiments, as a separate physical component (e.g., a dongle) with security features that prevent unauthorized access and tampering.
- the agent may be a proxy for a payment processor that sits within the merchant's network. For example, consider a large merchant or a grocery store chain where each transaction may go through an internal network of the merchant, which connects to the internal payment processor.
- the payment may be sent to an “agent” which is a separate server (or software on an existing server owned by the merchant), which handles the communication with the actual payment processor 110 .
- this agent may act on behalf of the payment processor 110 to approve the transaction based on the encrypted information included in the payment token. This agent would the store the transaction and forward it once the payment processor 110 becomes available again. While several inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein.
- each of the processors described herein may be a general-purpose computer, but alternatively may be a CSIC (consumer-specific integrated circuit), ASIC (application-specific integrated circuit), a logic circuit, a digital signal processor, a programmable logic device, such as an FPGA (field-programmable gate array), PLD (programmable logic device), PLA (programmable logic array), RFID processor, smart chip, or any other device or arrangement of devices that is capable of implementing the steps of the processes of the invention.
- CSIC consumer-specific integrated circuit
- ASIC application-specific integrated circuit
- a logic circuit such as an FPGA (field-programmable gate array), PLD (programmable logic device), PLA (programmable logic array), RFID processor, smart chip, or any other device or arrangement of devices that is capable of implementing the steps of the processes of the invention.
- FPGA field-programmable gate array
- PLD programmable logic device
- PLA programmable logic array
- RFID processor smart chip, or any other device or arrangement of devices that is capable of implementing the steps of the processes
- implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof.
- ASICs application specific integrated circuits
- These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
- the various modules and apps described herein can include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language.
- machine-readable medium “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal.
- machine-readable signal refers to any signal used to provide machine instructions and/or data to a programmable processor.
Abstract
Description
- It is common practice for consumers to pay a merchant electronically for goods or services received. Electronic payments are typically made with a token that identifies a source of funding. For example, a credit card containing a magnetic strip is a token. Payment tokens usually contain static information, such as an account number, identifying a source of payment. When a credit card is swiped, the card number is transmitted to a centralized payment processing system. Before authorizing payment, the centralized payment processing system may verify whether the account exists and is active, whether the account can fund the transaction, or whether the transaction may be fraudulent. A physical token such as a credit card cannot be easily modified and, in the event that it is lost or stolen, the consumer must report the lost card and wait for a replacement to be mailed. As a result, systems that allow a consumer to pay for a transaction at the point of sale (POS), using a mobile device to display a token (usually in the form of a barcode or QR code), are becoming widely accepted. Similar to credit-card tokens, mobile device tokens typically contain static information that must be transmitted to a centralized payment processing system for authentication and payment authorization.
- If the centralized payment-processing system or the merchant system loses network access (e.g., a network problem, a system power outage, a system fire, a system bug, or the like), however, the token cannot be used for payment without significant risk of fraud. Some merchants may copy (e.g., take a credit-card imprint) or otherwise save the consumer's account information or token, deliver goods to the consumer, and attempt to process the payment at a later time when the network is restored. But if the token is a fraud, the merchant will not get paid. In addition, the mere act of copying account information creates a risk of theft for the owner of the token.
- Accordingly, a system that protects both the consumer and the merchant from the risk of fraud regardless of network availability is needed.
- The present invention addresses these problems by encrypting a payment token for display on a consumer's mobile device with dynamic trust data (e.g., transaction history and/or token generation date) along with the financial account information. This approach not only enables the merchant system to make an informed decision about whether to accept payment without communication with the central processing system, but also protects the consumer's account information from theft.
- Accordingly, in one aspect, the invention pertains to a method of processing a transaction among a consumer, a merchant point-of-sale system and a transaction-processing entity. In representative embodiments, the method includes generating a token encrypted with data identifying a financial account of the consumer and trust data for the consumer; receiving and storing the token by a device of the consumer; reading and decrypting, by the merchant system, the token upon presentation thereof by the consumer's device in connection with the transaction; authorizing, by the merchant system, the transaction based on (i) successful decryption of the token and (ii) the trust level without communication with the transaction-processing entity; subsequent to authorization of the transaction by the merchant system, communicating, by the merchant to the transaction-processing entity, a record of the transaction and authorization thereof; and following the communication from the merchant system to the transaction-processing entity, completing the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant. The authorized transaction may be completed upon approval by the transaction-processing entity of a basis for the authorization by the merchant system. Additionally, the approval by the merchant system may also be based on a time of generation of the token and a time of the reading.
- In various embodiments, the trust data contains at least a token generation time, a transaction history of the consumer, a spending limit of the consumer or, a home region of the consumer. The trust data may be a single trust-factor value. The token may be encrypted using public key cryptography. As an alternative to encryption, the token may be signed with a digital signature. The token may be displayed as a “Quick Response” (QR) code on the consumer device, and may be a one-time-use token.
- In various embodiments, the method may additionally include generating and storing, on the consumer device, a plurality of tokens. Following a triggering event, such as expiration of a pre-set time period or presentation of the token, a first token may be marked for deletion and a second token may be marked for display on a subsequent presentation. The presentation of the first token may comprise receiving confirmation from the merchant system that the token was received. Additionally, the method may include generating a token to replace the token marked for deletion. In various embodiments, the token may not be marked for deletion until a deletion communication is received from the transaction-processing entity. Alternatively, following presentation of a first token, the first token may be marked for deletion and a second token is marked for display after a predetermined time period. The tokens may be used by removing them from the stack and used tokens are replaced with new tokens. In various embodiments, the tokens may be stored in a stack for sequential access on a first in, first out basis. Alternatively, the tokens are stored in a stack for sequential access on a first in, last out basis.
- In various embodiments, the consumer may be identified prior to generating the token.
- In another aspect, the invention relates to a system for processing a transaction among a consumer, a merchant and a transaction-processing entity. In various embodiments the system includes a token server for (i) generating a token encrypted with data identifying a financial account of the consumer and trust data for the consumer, and (ii) communicating the token to a device of the consumer; a point-of-sale system for reading and decrypting the token upon presentation thereof by the consumer in connection with the transaction, the point-of-sale system being configured to authorize the transaction based on (i) successful decryption of the token and (ii) the trust level without communication with the transaction-processing entity; and a transaction-processing server configured to (i) receive, from the point-of-sale system subsequent to transaction authorization, a record of the transaction and authorization thereof, and (ii) cause completion of the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant. The point-of-sale system may be configured to authorize the transaction based at least in part on a time of generation of the token and a time of the reading. The token server may be configured to encrypt the token using private key cryptography.
- In various embodiments, the token server may be configured to embed an expiration time in the generated token. Additionally, the token server may be configured to embed a creation time in the generated token. The token server may be configured to generate and communicate a series of tokens to the device. In various embodiments, the token server may be configured to verify the consumer's identity prior to token generation.
- In another aspect, the invention pertains to a method of processing a transaction among a consumer, a merchant point-of-sale system and a transaction-processing entity. In representative embodiments, the method includes generating a token with a digital signature, encrypted using a private key, with data identifying a financial account of the consumer and trust data for the consumer; receiving and storing the token and the signature by a device of the consumer; reading the token and decrypting the signature, by the merchant system, upon presentation of the token by the consumer's device in connection with the transaction; authorizing, by the merchant system, the transaction based on (i) successful verification of the signature and (ii) the trust level without communication with the transaction-processing entity; subsequent to authorization of the transaction by the merchant system, communicating, by the merchant to the transaction-processing entity, a record of the transaction and authorization thereof; and following the communication from the merchant system to the transaction-processing entity, completing the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- In another aspect, the invention relates to a system for processing a transaction among a consumer, a merchant and a transaction-processing entity. In various embodiments the system includes a token server for (i) generating a token with a digital signature, encrypted using a private key, with data identifying a financial account of the consumer and trust data for the consumer, and (ii) communicating the token to a device of the consumer; a point-of-sale system for reading and decrypting the signature upon presentation of the token by the consumer in connection with the transaction, the point-of-sale system being configured to authorize the transaction based on (i) successful verification of the signature and (ii) the trust level without communication with the transaction-processing entity; and a transaction-processing server configured to (i) receive, from the point-of-sale system subsequent to transaction authorization, a record of the transaction and authorization thereof, and (ii) cause completion of the authorized transaction by causing funds to be transferred from the consumer's financial account to the merchant.
- As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. Moreover, articles “a” and “an” as used in the subject specification and annexed drawings should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. In addition, the terms like “consumer equipment,” “mobile station,” “mobile,” “communication device,” “access terminal,” “terminal,” “handset,” and similar terminology, refer to a wireless device (e.g., cellular phone, smart phone, computer, PDA, set-top box, Internet Protocol Television (IPTV), electronic gaming device, printer, and so forth) utilized by a consumer of a wireless communication service to receive or convey data, control, voice, video, sound, gaming, or substantially any data-stream or signaling-stream. The foregoing terms are utilized interchangeably in the subject specification and related drawings. The terms “component,” “system,” “platform,” “module,” and the like refer broadly to a computer-related entity or an entity related to an operational machine with one or more specific functionalities. Such entities can be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
- In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, with an emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments of the present invention are described with reference to the following drawings, in which:
-
FIG. 1 is a block diagram of an exemplary network in accordance with an embodiment of the invention; -
FIGS. 2A , 2B, and 2C are block diagrams of an exemplary consumer device, token-generation server, and merchant system, respectively, in accordance with an embodiment of the invention; -
FIG. 3 depicts an exemplary system for performing secure payment transactions in accordance with an embodiment of the invention; and -
FIGS. 4A , 4B, and 4C are flowcharts illustrating performance of secure payment transactions in accordance with an embodiment of the invention. - Refer first to
FIG. 1 , which depicts an exemplary mobile-payment transaction network 100 including a consumer device (e.g., a mobile device) 102 linked to a network 104 (e.g., a cellular telephone network, the Internet, or any wide-area network or combination of networks capable of supporting point-to-point data transfer and communication) that supports wired, wireless, or any two-way communication. Thenetwork 104 connects various devices, including a token-generation server 106, one or more merchant systems (e.g., POS terminals) 108, and apayment processor 110 utilizing, again, wired, wireless, or any two-way communications. The token-generation server 106 is responsible for generating encrypted, unique payment tokens associated with the consumer. Eachmerchant system 108 may be associated with a merchant who offers goods or services for sale to the consumer possessing themobile device 102. In one embodiment, themerchant system 108 is a POS system (e.g., an electronic cash register) that connects to a code reader or scanner (hereafter “reader”) 112. Thereader 112 may be capable of reading and/or decoding a payment token, in the form of, for example, a barcode, a radio frequency identification (RFID) code, or a QR code, and/or receiving signals, such as NFC signals, acoustic signals, or infrared signals. In addition, thereader 112 may be mobile or physically associated with themerchant system 108. Themerchant system 108 may be responsible for decrypting the decoded payment token information and authenticating the payment transaction based on information provided therein. Thepayment processor 110 may be responsible for actually performing the payment transaction and, in some cases, for decrypting the payment token. For example, a so-called “direct” payment processor represents the financial-processing backend provider to credit-card issuers and payment services such as PAYPAL. An “indirect” payment processor is an independent entity processing transactions for multiple payment services and maintains its own records and data. Thepayment processor 110 may also be configured to decrypt and authenticate the token as a second verification layer. - The
mobile device 102 acts as a gateway for transmitting the consumer's data to thenetwork 104. Themobile device 102 can support multiple communication channels for exchanging multimedia and other data with theserver 106 and other devices using a Wi-Fi LAN (e.g., IEEE 802.11 standard) for Internet access, a short-range Bluetooth wireless connection for point-to-point access, and/or an NFC channel for close-proximity access. Referring toFIG. 2A , in various embodiments, themobile device 102 includes aconventional display screen 202, auser interface 204, aprocessor 206, atransceiver 208, and amemory 210. Thetransceiver 208 may be a conventional component (e.g., a network interface or transceiver) designed to provide communications with a network, such as the Internet and/or any other land-based or wireless telecommunications network or system, and, through the network, with the token-generation server 106. Thememory 210 includes an operating system (OS) 212, such as GOOGLE ANDROID, NOKIA SYMBIAN, BLACKBERRY RIM or MICROSOFT WINDOWS MOBILE, and acode process 214 that implements the device-side functions as further described below. Additional transactional information may be embedded in thecode process 212 for transmission through thenetwork 104 for later processing on a back-end server (e.g., the token-generation server 106). As used herein, the term “mobile device” used for transacting a mobile payment refers to a “smart phone” or tablet with advanced computing ability that, generally, facilitates bi-directional communication and data transfer using a mobile telecommunication network, and is capable of executing locally stored applications and/or payment transactions. Mobile devices include, for example, IPHONES (available from Apple Inc., Cupertino, Calif.), BLACKBERRY devices (available from Research in Motion, Waterloo, Ontario, Canada), or any smart phones equipped with the ANDROID platform (available from Google Inc., Mountain View, Calif.), tablets, such as the IPAD and KINDLE FIRE, and personal digital assistants (PDAs). Thememory 210 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements, such as during start-up, is typically stored in ROM. RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit. - The token-
generation server 106 is a trusted system that generates encrypted payment tokens. In response to requests made by a registered user via theconsumer device 102, theserver 106 generates tokens and transmits them to theconsumer device 102 for presentation to complete a transaction. Referring toFIG. 2B , in various embodiments, the token-generation server 106 includes aprocessor 222 and a memory 224, which may include volatile and non-volatile portions. The memory 224 contains instructions, conceptually illustrated as a group of modules, that control the operation of theprocessor 222 and its interaction with hardware components. Anoperating system 226 directs the execution of low-level, basic system functions such as memory allocation, file management and operation of mass storage devices. At a higher level, a look-upmodule 228, aPKI module 230, aweb server block 234, and acommunication module 236 perform the basis system functions described in greater detail below. Thecommunication module 234 may be a conventional component (e.g., a network interface or transceiver) designed to provide communications with a network, such as the Internet and/or any other land-based or wireless telecommunications network or system, and, through the network, with themobile device 102, themerchant system 108, and thepayment processor 110. The web-server block 236 enables web-based communication with themobile device 102, and can be a conventional web-server application executed by theprocessor 222. - A
consumer database 240 may reside in astorage device 238 and/or an external mass-storage device 242 accessible to the token-generation server 106; theconsumer database 240 stores, for example, a record associated with each registered consumer, or device, with associated trust data (e.g., transactional data). Thedatabase 240 is responsive to queries fromlookup module 228. - In operation, the user operates an executable, interactive application (an “app”) on the
mobile device 102 identifies himself to theserver 106, e.g., using a password or other strong form of authentication. The look-upmodule 228 obtains the user's account records from thedatabase 240 and, using thePKI module 230, generates an encrypted token for that user using a private key. The encrypted token contains information to uniquely identify the token or the user of the token, as well as trust data from the user's database record. Trust data may also reflect the time the token was generated, since more recently created tokens are considered more trustworthy (since the likelihood of fraudulent access or use increases over time). In general, trust data reflects a probability that thepayment processor 110 will ultimately authorize the desired payment on the user's behalf. For example, the trust data may specify how many transactions the consumer has processed in the past (in some embodiments, more recent transactions may receive a greater trust weight), the spending limit of the consumer, the home region of the consumer, the transaction history of the consumer (in some embodiments, transactions at merchants where the consumer has transacted previously may receive a greater trust weight), the age of the consumer's account (which may be correlated with the user's transaction history, but is a distinct piece of information which is much smaller to store), and other demographic information. Additional trust factors can include trust levels of other individuals with whom the user is somehow associated (e.g., social network “friends”), as well as trust levels associated with those individuals' friends and the number of funding sources the user has. For example, a user with only a single funding source may be a higher risk than a user with multiple funding sources (e.g., one credit card or bank account on file, versus many different accounts on file). This may also be based on the institutions in which the accounts are held, as it is less likely for a user to close accounts across different institutions simultaneously. In some embodiments, an aggregated “trust-factor” value is calculated that collapses all of these various metrics into a single value to be included in the token. The trust-factor value may be numeric or may simply be a coarse level, e.g., low, medium, or high. - Trust data may be updated when the registered user initiates or completes a new transaction, e.g., when the
server 106 receives a record of a new transaction from thepayment processor 110 via thecommunication module 234. In another embodiment, the trust data is updated periodically in a predetermined time period. For example, the trust data may be updated at a set time each day based on transactions that the user has completed within the previous 24 hours. The trust data may also be updated continuously based on patterns from all transactions processed, including transactions not involving the particular user. Similarly, the trust data may be updated continuously based on the trust factor of that person's social network “friends.” - The
server 106 transmits the generated token back to themobile device 102 via thecommunication module 234. As is well understood in the art, the token, encrypted using the private key, may be decrypted using a public key; the latter is made available tomerchant systems 108 to use in the course of transactions in accordance herewith. In one embodiment, the private key and associated public key (the private/public key pair) are reset periodically (e.g., in a predetermined period of time) for security purposes; the public key is communicated, viacommunication module 234, to themerchant system 108 upon every reset. In another embodiment, the private/public key pair is unchangeable. The token may be an authentication that is read directly by themerchant system 108 using, for example, NFC; may encode an optically readable “mature code” (e.g., a QR code or a bar code) that is displayed on the screen of themobile device 102; or may be a “seed code” from which the mobile device 106 (via the app) can generate a mature code later. - Referring to
FIG. 2C , in various embodiments, themerchant system 108 includes aprocessor 252, amemory 254, anoperating system 256, adecision module 258, adecryption module 260, aweb server block 264, acommunication module 266, and astorage device 268. As described above, the various functional modules are typically implemented as stored instructions that operate as running processes via theprocessor 252. Themerchant system 108 may be connected to or include thereader 112, which is capable of reading payment tokens according to any suitable modality (optical, NFC, etc.) from a consumer'smobile device 102. Thedecryption module 260 stores the public key and decrypts the token obtained by thereader 112. If decryption is successful, thedecision module 258 may, in some embodiments, further authenticate the token or the consumer if decryption is successful (e.g., by requesting a password or biometric indicium, such as a fingerprint, from the consumer). In instances where themerchant system 108 does not or presently cannot communicate with thepayment processor 110, thedecision module 258 decides, based on the decrypted trust data, whether to authorize the transaction as further described below. Accordingly, themerchant system 108 does not require continuous network access in order to authorize transactions. The transaction may be authorized based on the trust data and transactional information saved instorage device 268 for later transmission through thenetwork 104 for processing on a back-end server (e.g., the payment processor 110). - As illustrated in
FIG. 3 , payment transactions in accordance herewith may involve different stages that need not take place in tandem or at specific times, but instead may occur whenever a network connection can be established: a token-generation stage 302, a payment-initiation stage 304, a payment-authorization stage 306, a funds-transfer stage 308, and a database-update stage 310. For example, thepayment initiation stage 304 does not require a network connection when the encrypted token is read from themobile device 102 by aPOS merchant system 108. The various stages are described in further detail below. - A
representative method 400 for safely transacting a payment without continuous network access in accordance with embodiments of the current invention is shown inFIGS. 4A , 4B, and 4C (with additional reference to FIGS. 1 and 2A-2C). Assuming the consumer is registered with the token-generation server 106, the consumer, or an application acting on behalf of the consumer, can log in to theserver 106 to retrieve a payment token. For example, the consumer may download an app onto her mobile device 102 (step 402); the app, when executed on themobile device 102, communicates with the token-generation server 106 and allows the user to log in by supplying a proof of identify, such as a username/password pair (step 404)—either to the app, which then transmits the log-in information to theserver 106, or to theserver 106 directly via, for example, a web session—and request a token. This request is transmitted to the token-generation server 106 (step 406). The identifying information is verified (step 408), once again either by the app or by the token-generation server 106, and the look-upmodule 228 of the token-generation server 106 looks up the consumer's account data stored in database 240 (step 410) and generates a token for the consumer. The token contains data that identifies the consumer and/or the token as well as trust data for the consumer. The token may contain actual financial account information of the consumer or may instead contain information (such as an email address, telephone number, or random unique data) that can be mapped to the consumer's account by thepayment processor 110. Before being sent, the token is encrypted using the private key (step 414). The encrypted token is then transmitted to the mobile device 102 (step 416). Although the discussion herein focuses on a private/public key pair method of encryption for purposes of illustration, the present invention may be implemented using any asymmetric encryption method in which a secret key is known only to the token-generation server 106. In other embodiments, the private key may be used to digitally sign the token and successful verification of the signature proves the token's authenticity. Digital signatures utilize the public key infrastructure to ensure authenticity (i.e., that no one has tampered with the token in transit and that the token was indeed generated by the token-generation server 106.) - The client app running on the
mobile device 102 receives and stores the encrypted token (step 418). The token-generation process may take place at any time after a consumer registers an account. The token may be delivered to themobile device 102 at any time a network connection can be established. Generation of the token and delivery of the token may occur as two separate steps and may not happen at the same time. Thedevice 102 need not be continuously connected to network 104 and sporadic connectivity is sufficient to gain the benefits of the present invention. In addition, to reduce the risk of tokens being stolen, the token can be rotated. For example, the client app may be configured to check for network connectivity after a period of time, corresponding to the desired lifetime of a token, has elapsed since the token was received. If network connectivity is unavailable, the client app periodically checks until it detects a network connection. The client app may poll for connectivity, or the app may asynchronously monitor for connectivity changes. For example, the operating system of themobile device 102 may have facilities to notify apps asynchronously when network connectivity returns. The app may also be programmed wait for a triggering event before communicating with the server. For example, this triggering event may be in the form of the user opening the app, the user clicking a button to refresh his token, or other triggers as determined by the app's programming. If two-way communication between the app and themerchant system 108 is possible, the app may rotate the token after communicating the previous token to themerchant system 108. At this point, without the involvement of the consumer, the app causes themobile device 102 to communicate with the token-generation server 106 to obtain a replacement token. In some embodiments, the app passively monitors for other network traffic on the device prior to communicating with the token-generation server 106 in order to optimize power consumption. When the new token is received, the app causes the old one to be invalidated (so that the consumer uses only the newest token in a transaction). Alternatively, the rotation of tokens may be initiated by thepayment processor 110. Thepayment processor 110 may send a “push notification” message to the application, either periodically or after a triggering event. For example, the app may display a token but not know when that token has been successfully used to complete a transaction. When a transaction has been completed, thepayment processor 110 may therefore send a push notification to the device to rotate the token. In accordance with this approach, the token may be contained in the push notification or, instead, the push notification may simply be a “tickle” to cause themobile device 102 to initiate a request to obtain a new token. If themobile device 102 is offline when the push notification is sent, delivery of the push notification may be queued for delivery once themobile device 102 comes online again. The process of networked code rotation is far more secure than simple static tokens. - Alternatively, in response to a token request, the token-
generation server 106 may generate and deliver an encrypted, ordered stack—or “quiver”—of tokens for secure storage in themobile device 102. Whenever the consumer displays a token on the mobile device 102 (even if a payment transaction is not initiated), it is locally marked as displayed and the next token in the stack is marked for display. This process repeats each time a token is displayed. In some embodiments, each time a token is displayed, the app causes themobile device 102 to attempt to establish a network connection and, when the connection is established, commands the token-generation server 106 to mark the current token (i.e., the one on display) code for invalidation after a short period of time (e.g., in 60 minutes) and to invalidate all tokens preceding it in the stack (in case some had been displayed without a network connection). In this way, the current token—which is assumed to have been displayed because a transaction is imminent—is invalidated within a reasonable time to prevent fraud, since a token is at particular risk for fraudulent acquisition and use when displayed. The token-generation server 106 may generate and transmit to themobile device 102 enough new tokens to “refill” the quiver; the new tokens may be stored at the back end of the quiver so that older tokens are used on a first in, first out (FIFO) basis. FIFO operation ensures that the consumer always has newer tokens on hand. Alternatively, the new tokens may be stored at the front end of the quiver for last in, first out (LIFO) operation. While FIFO is preferred for extended periods of offline access, LIFO is generally better for security: newer tokens may have newer fraud information embedded in them, which benefits the payment network if they are used first. Since most devices tend to establish a network connection on each transaction, a reasonable quiver size is 30 tokens, which minimizes the likelihood of running out of tokens from the quiver. However, if all tokens in the quiver have been displayed without a network connection having been established, the last token is not marked as invalid and themobile device 102 continues to display it. In some embodiments, each token in a quiver is given a sequence number (e.g., the first token is sequence 1, the last token is sequence 30). This sequence number may be embedded in the token itself, acting as a form of trust data. If themobile device 102 goes a long period of time without connecting to the token-generation server 106, the last token in the quiver may be used for a long period of time. In various embodiments, themerchant system 108 is configured to reject the last token in a quiver when the mobile devices are operating in distributed mode and are not able to communicate with the payment processing system (e.g., the network is down). In various embodiments, each token in the quiver has a different validity period embedded in its trust data, and not all of the tokens in the quiver are valid simultaneously. This reduces the likelihood that any given token in the quiver can be stolen and used fraudulently. - A payment transaction is initiated when the consumer presents a token (e.g., in the form of a QR code) stored in the
mobile device 102 to the merchant system 108 (step 420). Themerchant system 108 may scan the code using the reader 112 (step 422), and thereupon decrypts the token using the public key (step 424). Any token that unsuccessfully decrypts is either fraudulent or corrupted, and the transaction is denied (step 426). Any token that successfully decrypts is guaranteed to have been created with private key, and is assumed to have come from the token-generation server 106. Themerchant system 108 may then attempt to transmit the token along with information about the transaction (the amount to be paid, in particular) and the merchant's own identity to thepayment processor 110, and await approval or denial. If a network connection cannot be established, however, themerchant system 108 can itself approve the transaction based on the trust data in the token using the decision module 258 (step 428). Although this does not guarantee that thepayment processor 110 will ultimately authorize the transaction, if the token decrypts successfully and was generated within a certain amount of time, and the trust data is satisfactory, the risk may be acceptable to the merchant. - The criteria applied in evaluating the trust data may be universal across the
system 100 or may be specific toparticular merchant systems 108. For example, a merchant may choose only to accept tokens from consumers whose home region is within a set distance of the POS; tokens from consumers who have transacted with the merchant previously; tokens that have been generated within a set time period; and/or trust data reflecting a transaction history success rate above a threshold percentage or number. In the latter case, the transaction history may be weighted in favor of more recent transactions in determining whether the threshold acceptability level is reached. The threshold acceptability level may vary with the amount of the transaction, and different criteria may receive different weights that themselves vary with the transaction amount. The trust criteria may be selected and combined in accordance with the priorities and preferences of the merchant and programmed into thedecision module 258, which scores each transaction accordingly. It should be emphasized that trust criteria can include any factors relevant to a risk score, e.g., the location of the merchant scored against local aggregated crime statistics from public databases. - If the criteria are satisfied, the
merchant system 108 authorizes the transaction (step 430) and communicates the authorization along with the encrypted token and information about the transaction and the merchant's own identity to thepayment processor 110 when a network connection is available (step 432); assuming the consumer's financial account is in good standing, thepayment processor 110 will transfer funds to the merchant. Until a network connection can be established, the token and transaction information are saved to thelocal storage 268 in themerchant system 108 for transmission when network connectivity is available (step 434). - A middle ground can be established between autonomous approval by the
merchant system 108 and connectivity to thepayment processor 110. In some embodiments, an “agent” of thepayment processor 110—i.e., a program supplied by thepayment processor 110 and executing as a running process on themerchant system 108—provides the approval based on the trust data and the token. In other words, the approval criteria are supplied by the payment processor, not the merchant, so that upon transaction approval by the agent, the merchant is guaranteed to receive payment from thepayment processor 110. Particularly if the agent is supplied as an executable file, the criteria utilized by thepayment processor 110 may be proprietary—i.e., hidden from merchants or other users of the executable file. Following approval, the agent causes transaction data to be stored locally and sent to thepayment processor 110 when network connectivity is available. The agent may be supplied to the merchant as a secure (hidden) executable file or, in some embodiments, as a separate physical component (e.g., a dongle) with security features that prevent unauthorized access and tampering. In other embodiments, the agent may be a proxy for a payment processor that sits within the merchant's network. For example, consider a large merchant or a grocery store chain where each transaction may go through an internal network of the merchant, which connects to the internal payment processor. In some embodiments, the payment may be sent to an “agent” which is a separate server (or software on an existing server owned by the merchant), which handles the communication with theactual payment processor 110. If theactual payment processor 110 is unavailable, this agent may act on behalf of thepayment processor 110 to approve the transaction based on the encrypted information included in the payment token. This agent would the store the transaction and forward it once thepayment processor 110 becomes available again. While several inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein. For example, each of the processors described herein may be a general-purpose computer, but alternatively may be a CSIC (consumer-specific integrated circuit), ASIC (application-specific integrated circuit), a logic circuit, a digital signal processor, a programmable logic device, such as an FPGA (field-programmable gate array), PLD (programmable logic device), PLA (programmable logic array), RFID processor, smart chip, or any other device or arrangement of devices that is capable of implementing the steps of the processes of the invention. - Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
- The various modules and apps described herein can include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
- The terms and expressions employed herein are used as terms and expressions of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described or portions thereof. In addition, having described certain embodiments of the invention, it will be apparent to those of ordinary skill in the art that other embodiments incorporating the concepts disclosed herein may be used without departing from the spirit and scope of the invention. Accordingly, the described embodiments are to be considered in all respects as only illustrative and not restrictive.
Claims (27)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/797,287 US20140279554A1 (en) | 2013-03-12 | 2013-03-12 | Distributed authenticity verification for consumer payment transactions |
US13/925,158 US20140279556A1 (en) | 2013-03-12 | 2013-06-24 | Distributed authenticity verification for consumer payment transactions |
US13/960,260 US8694438B1 (en) | 2013-03-12 | 2013-08-06 | Distributed authenticity verification for consumer payment transactions |
US16/424,281 US11587057B2 (en) | 2013-03-12 | 2019-05-28 | Distributed authenticity verification for consumer payment transactions |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/797,287 US20140279554A1 (en) | 2013-03-12 | 2013-03-12 | Distributed authenticity verification for consumer payment transactions |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/925,158 Continuation US20140279556A1 (en) | 2013-03-12 | 2013-06-24 | Distributed authenticity verification for consumer payment transactions |
US13/960,260 Continuation-In-Part US8694438B1 (en) | 2013-03-12 | 2013-08-06 | Distributed authenticity verification for consumer payment transactions |
US16/424,281 Continuation US11587057B2 (en) | 2013-03-12 | 2019-05-28 | Distributed authenticity verification for consumer payment transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140279554A1 true US20140279554A1 (en) | 2014-09-18 |
Family
ID=51532709
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/797,287 Abandoned US20140279554A1 (en) | 2013-03-12 | 2013-03-12 | Distributed authenticity verification for consumer payment transactions |
US13/925,158 Abandoned US20140279556A1 (en) | 2013-03-12 | 2013-06-24 | Distributed authenticity verification for consumer payment transactions |
US16/424,281 Active 2034-09-15 US11587057B2 (en) | 2013-03-12 | 2019-05-28 | Distributed authenticity verification for consumer payment transactions |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/925,158 Abandoned US20140279556A1 (en) | 2013-03-12 | 2013-06-24 | Distributed authenticity verification for consumer payment transactions |
US16/424,281 Active 2034-09-15 US11587057B2 (en) | 2013-03-12 | 2019-05-28 | Distributed authenticity verification for consumer payment transactions |
Country Status (1)
Country | Link |
---|---|
US (3) | US20140279554A1 (en) |
Cited By (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150073999A1 (en) * | 2013-09-10 | 2015-03-12 | Mastercard Asia Pacific Pte. Ltd. | Method and system for conducting a payment transaction and corresponding devices |
US20150304260A1 (en) * | 2012-08-01 | 2015-10-22 | Netwave | Method of processing connection data of platform of an internet site |
US9406065B2 (en) | 2014-03-04 | 2016-08-02 | Bank Of America Corporation | Customer token preferences interface |
US9424572B2 (en) | 2014-03-04 | 2016-08-23 | Bank Of America Corporation | Online banking digital wallet management |
US20160283942A1 (en) * | 2015-03-27 | 2016-09-29 | Ca. Inc. | Payment de-tokenization with risk evaluation for secure transactions |
US9525685B2 (en) | 2014-02-07 | 2016-12-20 | Bank Of America Corporation | User authentication based on other applications |
US9530289B2 (en) | 2013-07-11 | 2016-12-27 | Scvngr, Inc. | Payment processing with automatic no-touch mode selection |
US9600817B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign exchange token |
US9600844B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign cross-issued token |
US9628495B2 (en) | 2014-02-07 | 2017-04-18 | Bank Of America Corporation | Self-selected user access based on specific authentication types |
US9639689B1 (en) * | 2013-12-23 | 2017-05-02 | EMC IP Holding Company LLC | User authentication |
US9647999B2 (en) | 2014-02-07 | 2017-05-09 | Bank Of America Corporation | Authentication level of function bucket based on circumstances |
US9721248B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | ATM token cash withdrawal |
US9721268B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | Providing offers associated with payment credentials authenticated in a specific digital wallet |
US9729536B2 (en) | 2015-10-30 | 2017-08-08 | Bank Of America Corporation | Tiered identification federated authentication network system |
US9819680B2 (en) | 2014-02-07 | 2017-11-14 | Bank Of America Corporation | Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location |
US9830597B2 (en) | 2014-03-04 | 2017-11-28 | Bank Of America Corporation | Formation and funding of a shared token |
US9965606B2 (en) | 2014-02-07 | 2018-05-08 | Bank Of America Corporation | Determining user authentication based on user/device interaction |
US10002352B2 (en) | 2014-03-04 | 2018-06-19 | Bank Of America Corporation | Digital wallet exposure reduction |
US10268635B2 (en) | 2016-06-17 | 2019-04-23 | Bank Of America Corporation | System for data rotation through tokenization |
US10313480B2 (en) | 2017-06-22 | 2019-06-04 | Bank Of America Corporation | Data transmission between networked resources |
US20190205865A1 (en) * | 2017-12-29 | 2019-07-04 | Paypal, Inc. | Secure qr code based data transfers |
US10453059B2 (en) | 2015-09-30 | 2019-10-22 | Bank Of America Corporation | Non-intrusive geo-location determination associated with transaction authorization |
US10460367B2 (en) | 2016-04-29 | 2019-10-29 | Bank Of America Corporation | System for user authentication based on linking a randomly generated number to the user and a physical item |
US10511692B2 (en) | 2017-06-22 | 2019-12-17 | Bank Of America Corporation | Data transmission to a networked resource based on contextual information |
US10515370B2 (en) * | 2013-10-09 | 2019-12-24 | The Toronto-Dominion Bank | Systems and methods for providing tokenized transaction accounts |
US10524165B2 (en) | 2017-06-22 | 2019-12-31 | Bank Of America Corporation | Dynamic utilization of alternative resources based on token association |
WO2020027959A1 (en) * | 2018-08-02 | 2020-02-06 | Mastercard International Incorporated | Methods and systems for facilitating a client-server communication using cyclic tokens |
US10607215B2 (en) | 2015-09-30 | 2020-03-31 | Bank Of America Corporation | Account tokenization for virtual currency resources |
US10839369B1 (en) * | 2019-07-22 | 2020-11-17 | Capital One Services, Llc | Dynamic electronic communication with variable messages using encrypted quick response codes |
US11017371B2 (en) * | 2015-03-19 | 2021-05-25 | Airbnb, Inc. | Multi-point authentication for payment transactions |
US11315137B1 (en) | 2016-12-29 | 2022-04-26 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11423395B1 (en) * | 2016-12-29 | 2022-08-23 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11481754B2 (en) | 2012-07-13 | 2022-10-25 | Scvngr, Inc. | Secure payment method and system |
US11587056B2 (en) * | 2016-01-05 | 2023-02-21 | Advanced New Technologies Co., Ltd. | Data interaction method and device, and offline credit payment method and device |
US11716290B1 (en) | 2022-05-12 | 2023-08-01 | Bank Of America Corporation | Electronic system for dynamic linking of resource data structures across distributed networks |
Families Citing this family (113)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9318108B2 (en) | 2010-01-18 | 2016-04-19 | Apple Inc. | Intelligent automated assistant |
CN101809581B (en) | 2007-09-24 | 2014-12-10 | 苹果公司 | Embedded authentication systems in an electronic device |
US8600120B2 (en) | 2008-01-03 | 2013-12-03 | Apple Inc. | Personal computing device control using face detection and recognition |
US10082892B2 (en) | 2011-01-10 | 2018-09-25 | Apple Inc. | Button functionality |
US9002322B2 (en) | 2011-09-29 | 2015-04-07 | Apple Inc. | Authentication with secondary approver |
US8769624B2 (en) | 2011-09-29 | 2014-07-01 | Apple Inc. | Access control utilizing indirect authentication |
US11334884B2 (en) * | 2012-05-04 | 2022-05-17 | Institutional Cash Distributors Technology, Llc | Encapsulated security tokens for electronic transactions |
US10097496B2 (en) | 2012-05-09 | 2018-10-09 | Apple Inc. | Electronic mail user interface |
US10649622B2 (en) | 2012-05-09 | 2020-05-12 | Apple Inc. | Electronic message user interface |
US10235014B2 (en) | 2012-05-09 | 2019-03-19 | Apple Inc. | Music user interface |
US9027102B2 (en) | 2012-05-11 | 2015-05-05 | Sprint Communications Company L.P. | Web server bypass of backend process on near field communications and secure element chips |
US9282898B2 (en) | 2012-06-25 | 2016-03-15 | Sprint Communications Company L.P. | End-to-end trusted communications infrastructure |
US9183412B2 (en) | 2012-08-10 | 2015-11-10 | Sprint Communications Company L.P. | Systems and methods for provisioning and using multiple trusted security zones on an electronic device |
US9578664B1 (en) | 2013-02-07 | 2017-02-21 | Sprint Communications Company L.P. | Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system |
US9613208B1 (en) | 2013-03-13 | 2017-04-04 | Sprint Communications Company L.P. | Trusted security zone enhanced with trusted hardware drivers |
US9324016B1 (en) | 2013-04-04 | 2016-04-26 | Sprint Communications Company L.P. | Digest of biographical information for an electronic device with static and dynamic portions |
US9838869B1 (en) | 2013-04-10 | 2017-12-05 | Sprint Communications Company L.P. | Delivering digital content to a mobile device via a digital rights clearing house |
US9560519B1 (en) | 2013-06-06 | 2017-01-31 | Sprint Communications Company L.P. | Mobile communication device profound identity brokering framework |
WO2014197336A1 (en) | 2013-06-07 | 2014-12-11 | Apple Inc. | System and method for detecting errors in interactions with a voice-based digital assistant |
US11037137B2 (en) * | 2013-06-13 | 2021-06-15 | Blackberry Limited | Mobile wireless communications device having digital wallet with multi-mode user card and related methods |
US20140372298A1 (en) | 2013-06-13 | 2014-12-18 | Research In Motion Limited | Communication system with digital wallet having blank user card and related methods |
US10001817B2 (en) | 2013-09-03 | 2018-06-19 | Apple Inc. | User interface for manipulating user interface objects with magnetic properties |
US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
EP3063608B1 (en) | 2013-10-30 | 2020-02-12 | Apple Inc. | Displaying relevant user interface objects |
US9397990B1 (en) * | 2013-11-08 | 2016-07-19 | Google Inc. | Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud |
US9589122B2 (en) * | 2013-11-19 | 2017-03-07 | Tencent Technology (Shenzhen) Company Limited | Operation processing method and device |
US11481781B2 (en) | 2013-12-18 | 2022-10-25 | PayRange Inc. | Processing interrupted transaction over non-persistent network connections |
US9875473B2 (en) | 2013-12-18 | 2018-01-23 | PayRange Inc. | Method and system for retrofitting an offline-payment operated machine to accept electronic payments |
US10019724B2 (en) | 2015-01-30 | 2018-07-10 | PayRange Inc. | Method and system for providing offers for automated retail machines via mobile devices |
US11475454B2 (en) | 2013-12-18 | 2022-10-18 | PayRange Inc. | Intermediary communications over non-persistent network connections |
US11074580B2 (en) | 2013-12-18 | 2021-07-27 | PayRange Inc. | Device and method for providing external access to multi-drop bus peripheral devices |
US11481780B2 (en) | 2013-12-18 | 2022-10-25 | PayRange Inc. | Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel |
US11205163B2 (en) | 2013-12-18 | 2021-12-21 | PayRange Inc. | Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options |
US8856045B1 (en) * | 2013-12-18 | 2014-10-07 | PayRange Inc. | Mobile-device-to-machine payment systems |
US9659296B2 (en) | 2013-12-18 | 2017-05-23 | PayRange Inc. | Method and system for presenting representations of payment accepting unit events |
US20150213443A1 (en) * | 2014-01-30 | 2015-07-30 | Apple Inc. | Tokenizing authorizations |
CN104836780B (en) * | 2014-02-12 | 2017-03-15 | 腾讯科技(深圳)有限公司 | Data interactive method, checking terminal, server and system |
AU2015255887A1 (en) | 2014-05-07 | 2016-10-13 | Visa International Service Association | Enhanced data interface for contactless communications |
US10043185B2 (en) | 2014-05-29 | 2018-08-07 | Apple Inc. | User interface for payments |
US9967401B2 (en) | 2014-05-30 | 2018-05-08 | Apple Inc. | User interface for phone call routing among devices |
US10313506B2 (en) | 2014-05-30 | 2019-06-04 | Apple Inc. | Wellness aggregator |
US10614445B1 (en) | 2014-06-04 | 2020-04-07 | Square, Inc. | Proximity-based payments |
GB2527603B (en) * | 2014-06-27 | 2016-08-10 | Ibm | Backup and invalidation of authentication credentials |
US10339293B2 (en) | 2014-08-15 | 2019-07-02 | Apple Inc. | Authenticated device used to unlock another device |
US10452253B2 (en) | 2014-08-15 | 2019-10-22 | Apple Inc. | Weather user interface |
WO2016036541A2 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | Phone user interface |
EP3189409B1 (en) | 2014-09-02 | 2020-01-29 | Apple Inc. | Reduced-size interfaces for managing alerts |
WO2016036552A1 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | User interactions for a mapping application |
US10254948B2 (en) | 2014-09-02 | 2019-04-09 | Apple Inc. | Reduced-size user interfaces for dynamically updated application overviews |
WO2016036413A1 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | Multi-dimensional object rearrangement |
WO2016036603A1 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | Reduced size configuration interface |
US20160071101A1 (en) * | 2014-09-09 | 2016-03-10 | Tyson York Winarski | Selfie financial security transaction system |
US10963868B1 (en) | 2014-09-09 | 2021-03-30 | Square, Inc. | Anonymous payment transactions |
WO2016049636A2 (en) * | 2014-09-26 | 2016-03-31 | Visa International Service Association | Remote server encrypted data provisioning system and methods |
US9473490B2 (en) * | 2014-10-13 | 2016-10-18 | Wells Fargo Bank, N.A. | Bidirectional authentication |
WO2016061349A1 (en) * | 2014-10-15 | 2016-04-21 | Mastercard International Incorporated | Bottom of the pyramid pay method and system |
US20160125370A1 (en) | 2014-10-31 | 2016-05-05 | Square, Inc. | Money transfer by use of a syntax |
US20160358163A1 (en) * | 2014-12-29 | 2016-12-08 | Ca, Inc. | Payment tokenization using format preserving encryption for secure transactions |
CN105825371A (en) * | 2015-01-07 | 2016-08-03 | 阿里巴巴集团控股有限公司 | Method and device for processing service |
US9779232B1 (en) * | 2015-01-14 | 2017-10-03 | Sprint Communications Company L.P. | Trusted code generation and verification to prevent fraud from maleficent external devices that capture data |
US9838868B1 (en) | 2015-01-26 | 2017-12-05 | Sprint Communications Company L.P. | Mated universal serial bus (USB) wireless dongles configured with destination addresses |
US20180268403A1 (en) * | 2015-01-27 | 2018-09-20 | Abhishek Guglani | Multiple protocol transaction encryption |
USD862501S1 (en) | 2015-01-30 | 2019-10-08 | PayRange Inc. | Display screen or portion thereof with a graphical user interface |
US20160224973A1 (en) | 2015-02-01 | 2016-08-04 | Apple Inc. | User interface for payments |
US9574896B2 (en) | 2015-02-13 | 2017-02-21 | Apple Inc. | Navigation user interface |
US10466883B2 (en) | 2015-03-02 | 2019-11-05 | Apple Inc. | Screenreader user interface |
CA2978461C (en) * | 2015-03-06 | 2020-10-27 | Mastercard International Incorporated | Secure mobile remote payments |
US9600819B2 (en) | 2015-03-06 | 2017-03-21 | Mastercard International Incorporated | Systems and methods for risk based decisioning |
US10055121B2 (en) | 2015-03-07 | 2018-08-21 | Apple Inc. | Activity based thresholds and feedbacks |
US10254911B2 (en) | 2015-03-08 | 2019-04-09 | Apple Inc. | Device configuration user interface |
US9473945B1 (en) | 2015-04-07 | 2016-10-18 | Sprint Communications Company L.P. | Infrastructure for secure short message transmission |
US9350556B1 (en) | 2015-04-20 | 2016-05-24 | Google Inc. | Security model for identification and authentication in encrypted communications using delegate certificate chain bound to third party key |
US10044718B2 (en) | 2015-05-27 | 2018-08-07 | Google Llc | Authorization in a distributed system using access control lists and groups |
US9940637B2 (en) | 2015-06-05 | 2018-04-10 | Apple Inc. | User interface for loyalty accounts and private label accounts |
US20160358133A1 (en) | 2015-06-05 | 2016-12-08 | Apple Inc. | User interface for loyalty accounts and private label accounts for a wearable device |
US9916075B2 (en) | 2015-06-05 | 2018-03-13 | Apple Inc. | Formatting content for a reduced-size user interface |
US9819679B1 (en) | 2015-09-14 | 2017-11-14 | Sprint Communications Company L.P. | Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers |
US11010782B2 (en) * | 2015-10-16 | 2021-05-18 | International Business Machines Corporation | Payment for a service utilizing information |
US10924473B2 (en) * | 2015-11-10 | 2021-02-16 | T Stamp Inc. | Trust stamp |
US10282719B1 (en) | 2015-11-12 | 2019-05-07 | Sprint Communications Company L.P. | Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit |
US9817992B1 (en) | 2015-11-20 | 2017-11-14 | Sprint Communications Company Lp. | System and method for secure USIM wireless network access |
AU2017235634A1 (en) * | 2016-03-17 | 2018-08-23 | Visa International Service Association | Enabling a secure card on file option for electronic merchant applications |
DK179186B1 (en) | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
DK201670622A1 (en) | 2016-06-12 | 2018-02-12 | Apple Inc | User interfaces for transactions |
US20180068313A1 (en) | 2016-09-06 | 2018-03-08 | Apple Inc. | User interfaces for stored-value accounts |
US10860199B2 (en) | 2016-09-23 | 2020-12-08 | Apple Inc. | Dynamically adjusting touch hysteresis based on contextual data |
US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
US10499249B1 (en) | 2017-07-11 | 2019-12-03 | Sprint Communications Company L.P. | Data link layer trust signaling in communication network |
KR102185854B1 (en) | 2017-09-09 | 2020-12-02 | 애플 인크. | Implementation of biometric authentication |
KR102301599B1 (en) | 2017-09-09 | 2021-09-10 | 애플 인크. | Implementation of biometric authentication |
US11855971B2 (en) * | 2018-01-11 | 2023-12-26 | Visa International Service Association | Offline authorization of interactions and controlled tasks |
WO2019204650A1 (en) | 2018-04-19 | 2019-10-24 | PIV Security LLC | Peer identity verification |
US11496315B1 (en) | 2018-05-08 | 2022-11-08 | T Stamp Inc. | Systems and methods for enhanced hash transforms |
US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
US11210652B2 (en) * | 2018-06-21 | 2021-12-28 | Celligence International Llc | Systems and methods for processing purchase transactions using a mobile device |
US10460221B1 (en) * | 2018-09-07 | 2019-10-29 | Ryan C. Tucker | Displaying a seeded, continuously updating identifier in a QR code |
US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
US11354613B2 (en) * | 2018-10-03 | 2022-06-07 | Visa International Service Association | System, method, and computer program product for generating location-based risk assessments of service provider transaction requests |
US11328352B2 (en) | 2019-03-24 | 2022-05-10 | Apple Inc. | User interfaces for managing an account |
US11301586B1 (en) | 2019-04-05 | 2022-04-12 | T Stamp Inc. | Systems and processes for lossy biometric representations |
US11477609B2 (en) | 2019-06-01 | 2022-10-18 | Apple Inc. | User interfaces for location-related communications |
US11481094B2 (en) | 2019-06-01 | 2022-10-25 | Apple Inc. | User interfaces for location-related communications |
US11501290B2 (en) * | 2019-07-08 | 2022-11-15 | International Business Machines Corporation | Digital currency transfer |
KR102608325B1 (en) * | 2019-08-13 | 2023-11-30 | 구글 엘엘씨 | Protect the integrity of communications on client devices |
SG10201908145UA (en) * | 2019-09-04 | 2021-04-29 | Mastercard International Inc | Methods and systems for performing an offline payment transaction in absence of network |
KR102602556B1 (en) | 2019-09-29 | 2023-11-14 | 애플 인크. | Account management user interfaces |
US11169830B2 (en) | 2019-09-29 | 2021-11-09 | Apple Inc. | Account management user interfaces |
US11171945B2 (en) * | 2019-10-16 | 2021-11-09 | Capital One Services, Llc | Time-based token trust depreciation |
DK202070633A1 (en) | 2020-04-10 | 2021-11-12 | Apple Inc | User interfaces for enabling an activity |
US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
US20230379318A1 (en) * | 2022-05-19 | 2023-11-23 | Lemon Inc. | Online data in a secure environment |
Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4680757A (en) * | 1985-04-15 | 1987-07-14 | Hitachi, Ltd. | Method of and apparatus for storing priority levels in token-ring network system |
US6000832A (en) * | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
WO2001077851A1 (en) * | 2000-04-06 | 2001-10-18 | Rensselaer Polytechnic Institute | Tcp-friendly system and method for marking scalable better best-effort services on the internet |
US20030028481A1 (en) * | 1998-03-25 | 2003-02-06 | Orbis Patents, Ltd. | Credit card system and method |
US20030200212A1 (en) * | 2002-04-23 | 2003-10-23 | International Business Machiness Corporation | Method, system, and program product for transaction management in a distributed content management application |
US20040073621A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Communication management using a token action log |
US20100125509A1 (en) * | 2008-11-14 | 2010-05-20 | Kranzley Arthur D | Methods and systems for secure mobile device initiated payments using generated image data |
US20100192210A1 (en) * | 2009-01-26 | 2010-07-29 | Apple Inc. | Method and system for verifying entitlement to access content by url validation |
US20110071986A1 (en) * | 2009-09-18 | 2011-03-24 | Software Ag | Method for mass-deleting data records of a database system |
US20110137789A1 (en) * | 2009-12-03 | 2011-06-09 | Venmo Inc. | Trust Based Transaction System |
US20110161233A1 (en) * | 2009-12-30 | 2011-06-30 | First Data Corporation | Secure transaction management |
US20120158589A1 (en) * | 2010-12-15 | 2012-06-21 | Edward Katzin | Social Media Payment Platform Apparatuses, Methods and Systems |
US20130054336A1 (en) * | 2011-04-05 | 2013-02-28 | Roam Data Inc | System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems |
US20130317923A1 (en) * | 2012-05-23 | 2013-11-28 | Paynearme, Inc. | System and Method for Facilitating Cash Payment Transactions Using a Mobile Device |
US20140025585A1 (en) * | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Distributing authorized tokens to conduct mobile transactions |
US8694438B1 (en) * | 2013-03-12 | 2014-04-08 | Scvngr | Distributed authenticity verification for consumer payment transactions |
US20140250006A1 (en) * | 2011-12-13 | 2014-09-04 | Oleg Makhotin | Integrated mobile trusted service manager |
Family Cites Families (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5619574A (en) * | 1995-02-13 | 1997-04-08 | Eta Technologies Corporation | Personal access management system |
DE19718103A1 (en) * | 1997-04-29 | 1998-06-04 | Kim Schmitz | Data transmission system authorise method e.g. for telebanking |
US7555460B1 (en) * | 2000-06-05 | 2009-06-30 | Diversinet Corp. | Payment system and method using tokens |
US7328189B2 (en) * | 2000-01-26 | 2008-02-05 | Paybyclick Corporation | Method and apparatus for conducting electronic commerce transactions using electronic tokens |
US6834270B1 (en) * | 2000-02-28 | 2004-12-21 | Carlo Pagani | Secured financial transaction system using single use codes |
ATE261160T1 (en) * | 2000-08-01 | 2004-03-15 | Mega Tel Ag | ELECTRONIC PAYMENTS WITH SMS |
US6938019B1 (en) * | 2000-08-29 | 2005-08-30 | Uzo Chijioke Chukwuemeka | Method and apparatus for making secure electronic payments |
DE10045924A1 (en) * | 2000-09-14 | 2002-04-04 | Giesecke & Devrient Gmbh | Process for securing a transaction on a computer network |
US7287009B1 (en) * | 2000-09-14 | 2007-10-23 | Raanan Liebermann | System and a method for carrying out personal and business transactions |
US7983976B2 (en) * | 2000-10-17 | 2011-07-19 | Hedgestreet, Inc. | Methods and apparatus for formulation, initial public or private offering, and secondary market trading of risk management contracts |
US20020131444A1 (en) * | 2001-03-13 | 2002-09-19 | Moodie Justin Charles | Communications system with database management |
US20060095369A1 (en) * | 2001-10-15 | 2006-05-04 | Eyal Hofi | Device, method and system for authorizing transactions |
US20030074317A1 (en) * | 2001-10-15 | 2003-04-17 | Eyal Hofi | Device, method and system for authorizing transactions |
US7917444B1 (en) * | 2001-10-29 | 2011-03-29 | Mcafee, Inc. | Secure single-use transaction numbers |
NO318746B1 (en) * | 2002-02-22 | 2005-05-02 | Vensafe Asa | Consumer goods sales system |
US20040107170A1 (en) * | 2002-08-08 | 2004-06-03 | Fujitsu Limited | Apparatuses for purchasing of goods and services |
US20050044385A1 (en) * | 2002-09-09 | 2005-02-24 | John Holdsworth | Systems and methods for secure authentication of electronic transactions |
US20040073688A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Electronic payment validation using Transaction Authorization Tokens |
US7870077B2 (en) * | 2002-10-02 | 2011-01-11 | Kt Corporation | System and method for buying goods and billing agency using short message service |
US20040133507A1 (en) * | 2003-01-02 | 2004-07-08 | Paul Barbour | Method and system for conducting financial transactions using single use credit card numbers |
US7264154B2 (en) * | 2004-07-12 | 2007-09-04 | Harris David N | System and method for securing a credit account |
US7287692B1 (en) * | 2004-07-28 | 2007-10-30 | Cisco Technology, Inc. | System and method for securing transactions in a contact center environment |
WO2006053191A2 (en) * | 2004-11-10 | 2006-05-18 | Mastercard International Incorporated | Method and system for performing a transaction using a dynamic authorization code |
EP1732034A1 (en) * | 2005-06-06 | 2006-12-13 | First Data Corporation | System and method for authorizing electronic payment transactions |
KR20080059617A (en) * | 2005-10-05 | 2008-06-30 | 프리바스피어 아게 | Method and devices for user authentication |
US20070130463A1 (en) * | 2005-12-06 | 2007-06-07 | Eric Chun Wah Law | Single one-time password token with single PIN for access to multiple providers |
US7978363B2 (en) * | 2006-02-15 | 2011-07-12 | Seiko Epson Corporation | Printing apparatus and printing method |
EP2074726A4 (en) * | 2006-10-11 | 2011-06-01 | Visa Int Service Ass | Method and system for processing micropayment transactions |
US8571996B2 (en) * | 2007-04-20 | 2013-10-29 | N.P. Johnson Family Limited Partnership | Apparatus and method for secured commercial transactions |
US8255696B2 (en) * | 2007-05-01 | 2012-08-28 | Microsoft Corporation | One-time password access to password-protected accounts |
DE602007012538D1 (en) * | 2007-07-27 | 2011-03-31 | Ntt Docomo Inc | Method and apparatus for performing delegated transactions |
CN101281630A (en) * | 2007-10-10 | 2008-10-08 | 北京大学 | System and method for counting digital content |
US7946502B2 (en) * | 2008-01-22 | 2011-05-24 | Visa Usa Inc. | Financial transaction token |
US8205797B2 (en) * | 2009-02-02 | 2012-06-26 | Xerox Corporation | Method and system for transmitting proof of payment for “pay-as-you-go” multi-function devices |
US20100250290A1 (en) * | 2009-03-27 | 2010-09-30 | Vegas.Com | System and method for token-based transactions |
US9471920B2 (en) * | 2009-05-15 | 2016-10-18 | Idm Global, Inc. | Transaction assessment and/or authentication |
US9092763B2 (en) * | 2009-12-30 | 2015-07-28 | Moneygram International, Inc. | Retail sale money transfer system |
KR101673233B1 (en) * | 2010-05-11 | 2016-11-17 | 삼성전자주식회사 | Transection splitting apparatus and method |
US20120028609A1 (en) * | 2010-07-27 | 2012-02-02 | John Hruska | Secure financial transaction system using a registered mobile device |
US8290876B1 (en) * | 2011-01-12 | 2012-10-16 | Steven Douglas Powell | Method and system for securing a third party payment electronic transaction |
US10089606B2 (en) * | 2011-02-11 | 2018-10-02 | Bytemark, Inc. | System and method for trusted mobile device payment |
US8494967B2 (en) * | 2011-03-11 | 2013-07-23 | Bytemark, Inc. | Method and system for distributing electronic tickets with visual display |
US10453062B2 (en) * | 2011-03-15 | 2019-10-22 | Capital One Services, Llc | Systems and methods for performing person-to-person transactions using active authentication |
US10380585B2 (en) * | 2011-06-02 | 2019-08-13 | Visa International Service Association | Local usage of electronic tokens in a transaction processing system |
EP2541478A1 (en) * | 2011-06-27 | 2013-01-02 | Accenture Global Services Limited | Dynamic electronic money |
US8555079B2 (en) * | 2011-12-06 | 2013-10-08 | Wwpass Corporation | Token management |
-
2013
- 2013-03-12 US US13/797,287 patent/US20140279554A1/en not_active Abandoned
- 2013-06-24 US US13/925,158 patent/US20140279556A1/en not_active Abandoned
-
2019
- 2019-05-28 US US16/424,281 patent/US11587057B2/en active Active
Patent Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4680757A (en) * | 1985-04-15 | 1987-07-14 | Hitachi, Ltd. | Method of and apparatus for storing priority levels in token-ring network system |
US6000832A (en) * | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
US20030028481A1 (en) * | 1998-03-25 | 2003-02-06 | Orbis Patents, Ltd. | Credit card system and method |
WO2001077851A1 (en) * | 2000-04-06 | 2001-10-18 | Rensselaer Polytechnic Institute | Tcp-friendly system and method for marking scalable better best-effort services on the internet |
US20030200212A1 (en) * | 2002-04-23 | 2003-10-23 | International Business Machiness Corporation | Method, system, and program product for transaction management in a distributed content management application |
US20040073621A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Communication management using a token action log |
US20100125509A1 (en) * | 2008-11-14 | 2010-05-20 | Kranzley Arthur D | Methods and systems for secure mobile device initiated payments using generated image data |
US20100192210A1 (en) * | 2009-01-26 | 2010-07-29 | Apple Inc. | Method and system for verifying entitlement to access content by url validation |
US20110071986A1 (en) * | 2009-09-18 | 2011-03-24 | Software Ag | Method for mass-deleting data records of a database system |
US20110137789A1 (en) * | 2009-12-03 | 2011-06-09 | Venmo Inc. | Trust Based Transaction System |
US20110161233A1 (en) * | 2009-12-30 | 2011-06-30 | First Data Corporation | Secure transaction management |
US20120158589A1 (en) * | 2010-12-15 | 2012-06-21 | Edward Katzin | Social Media Payment Platform Apparatuses, Methods and Systems |
US20130054336A1 (en) * | 2011-04-05 | 2013-02-28 | Roam Data Inc | System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems |
US20140250006A1 (en) * | 2011-12-13 | 2014-09-04 | Oleg Makhotin | Integrated mobile trusted service manager |
US20130317923A1 (en) * | 2012-05-23 | 2013-11-28 | Paynearme, Inc. | System and Method for Facilitating Cash Payment Transactions Using a Mobile Device |
US20140025585A1 (en) * | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Distributing authorized tokens to conduct mobile transactions |
US8694438B1 (en) * | 2013-03-12 | 2014-04-08 | Scvngr | Distributed authenticity verification for consumer payment transactions |
Cited By (56)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11481754B2 (en) | 2012-07-13 | 2022-10-25 | Scvngr, Inc. | Secure payment method and system |
US20150304260A1 (en) * | 2012-08-01 | 2015-10-22 | Netwave | Method of processing connection data of platform of an internet site |
US9729484B2 (en) * | 2012-08-01 | 2017-08-08 | Netwave | Method of processing connection data of platform of an internet site |
US9530289B2 (en) | 2013-07-11 | 2016-12-27 | Scvngr, Inc. | Payment processing with automatic no-touch mode selection |
US20150073999A1 (en) * | 2013-09-10 | 2015-03-12 | Mastercard Asia Pacific Pte. Ltd. | Method and system for conducting a payment transaction and corresponding devices |
US11301864B2 (en) * | 2013-10-09 | 2022-04-12 | The Toronto-Dominion Bank | Systems and methods for providing tokenized transaction accounts |
US10515370B2 (en) * | 2013-10-09 | 2019-12-24 | The Toronto-Dominion Bank | Systems and methods for providing tokenized transaction accounts |
US9639689B1 (en) * | 2013-12-23 | 2017-05-02 | EMC IP Holding Company LLC | User authentication |
US9647999B2 (en) | 2014-02-07 | 2017-05-09 | Bank Of America Corporation | Authentication level of function bucket based on circumstances |
US9525685B2 (en) | 2014-02-07 | 2016-12-20 | Bank Of America Corporation | User authentication based on other applications |
US10050962B2 (en) | 2014-02-07 | 2018-08-14 | Bank Of America Corporation | Determining user authentication requirements along a continuum based on a current state of the user and/or the attributes related to the function requiring authentication |
US9965606B2 (en) | 2014-02-07 | 2018-05-08 | Bank Of America Corporation | Determining user authentication based on user/device interaction |
US9819680B2 (en) | 2014-02-07 | 2017-11-14 | Bank Of America Corporation | Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location |
US9628495B2 (en) | 2014-02-07 | 2017-04-18 | Bank Of America Corporation | Self-selected user access based on specific authentication types |
US9424572B2 (en) | 2014-03-04 | 2016-08-23 | Bank Of America Corporation | Online banking digital wallet management |
US9721268B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | Providing offers associated with payment credentials authenticated in a specific digital wallet |
US9721248B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | ATM token cash withdrawal |
US9652764B2 (en) | 2014-03-04 | 2017-05-16 | Bank Of America Corporation | Online banking digital wallet management |
US9600817B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign exchange token |
US9830597B2 (en) | 2014-03-04 | 2017-11-28 | Bank Of America Corporation | Formation and funding of a shared token |
US9639836B2 (en) | 2014-03-04 | 2017-05-02 | Bank Of America Corporation | Online banking digital wallet management |
US9406065B2 (en) | 2014-03-04 | 2016-08-02 | Bank Of America Corporation | Customer token preferences interface |
US10762483B2 (en) | 2014-03-04 | 2020-09-01 | Bank Of America Corporation | ATM token cash withdrawal |
US10002352B2 (en) | 2014-03-04 | 2018-06-19 | Bank Of America Corporation | Digital wallet exposure reduction |
US9600844B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign cross-issued token |
US10134030B2 (en) | 2014-03-04 | 2018-11-20 | Bank Of America Corporation | Customer token preferences interface |
US10140610B2 (en) | 2014-03-04 | 2018-11-27 | Bank Of America Corporation | Customer token preferences interface |
US11017370B2 (en) * | 2015-03-19 | 2021-05-25 | Airbnb, Inc. | Multi-point authentication for payment transactions |
US11017371B2 (en) * | 2015-03-19 | 2021-05-25 | Airbnb, Inc. | Multi-point authentication for payment transactions |
US20160283942A1 (en) * | 2015-03-27 | 2016-09-29 | Ca. Inc. | Payment de-tokenization with risk evaluation for secure transactions |
US9984371B2 (en) * | 2015-03-27 | 2018-05-29 | Ca, Inc. | Payment de-tokenization with risk evaluation for secure transactions |
US10990971B2 (en) | 2015-09-30 | 2021-04-27 | Bank Of America Corporation | Non-intrusive geo-location determination associated with transaction authorization |
US10453059B2 (en) | 2015-09-30 | 2019-10-22 | Bank Of America Corporation | Non-intrusive geo-location determination associated with transaction authorization |
US11087312B2 (en) | 2015-09-30 | 2021-08-10 | Bank Of America Corporation | Account tokenization for virtual currency resources |
US10607215B2 (en) | 2015-09-30 | 2020-03-31 | Bank Of America Corporation | Account tokenization for virtual currency resources |
US9729536B2 (en) | 2015-10-30 | 2017-08-08 | Bank Of America Corporation | Tiered identification federated authentication network system |
US9965523B2 (en) | 2015-10-30 | 2018-05-08 | Bank Of America Corporation | Tiered identification federated authentication network system |
US11587056B2 (en) * | 2016-01-05 | 2023-02-21 | Advanced New Technologies Co., Ltd. | Data interaction method and device, and offline credit payment method and device |
US10460367B2 (en) | 2016-04-29 | 2019-10-29 | Bank Of America Corporation | System for user authentication based on linking a randomly generated number to the user and a physical item |
US10268635B2 (en) | 2016-06-17 | 2019-04-23 | Bank Of America Corporation | System for data rotation through tokenization |
US11823179B1 (en) | 2016-12-29 | 2023-11-21 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11823224B1 (en) | 2016-12-29 | 2023-11-21 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11315137B1 (en) | 2016-12-29 | 2022-04-26 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US11423395B1 (en) * | 2016-12-29 | 2022-08-23 | Wells Fargo Bank, N.A. | Pay with points virtual card |
US10986541B2 (en) | 2017-06-22 | 2021-04-20 | Bank Of America Corporation | Dynamic utilization of alternative resources based on token association |
US10313480B2 (en) | 2017-06-22 | 2019-06-04 | Bank Of America Corporation | Data transmission between networked resources |
US10524165B2 (en) | 2017-06-22 | 2019-12-31 | Bank Of America Corporation | Dynamic utilization of alternative resources based on token association |
US11190617B2 (en) | 2017-06-22 | 2021-11-30 | Bank Of America Corporation | Data transmission to a networked resource based on contextual information |
US10511692B2 (en) | 2017-06-22 | 2019-12-17 | Bank Of America Corporation | Data transmission to a networked resource based on contextual information |
US11238433B2 (en) * | 2017-12-29 | 2022-02-01 | Paypal, Inc. | Secure matrix barcode based data transfers |
US20190205865A1 (en) * | 2017-12-29 | 2019-07-04 | Paypal, Inc. | Secure qr code based data transfers |
WO2020027959A1 (en) * | 2018-08-02 | 2020-02-06 | Mastercard International Incorporated | Methods and systems for facilitating a client-server communication using cyclic tokens |
US10819829B2 (en) | 2018-08-02 | 2020-10-27 | Mastercard International Incorporated | Methods and systems for facilitating a client-server communication using cyclic tokens |
US11416843B2 (en) | 2019-07-22 | 2022-08-16 | Capital One Services, Llc | Dynamic electronic communication with variable messages using encrypted quick response codes |
US10839369B1 (en) * | 2019-07-22 | 2020-11-17 | Capital One Services, Llc | Dynamic electronic communication with variable messages using encrypted quick response codes |
US11716290B1 (en) | 2022-05-12 | 2023-08-01 | Bank Of America Corporation | Electronic system for dynamic linking of resource data structures across distributed networks |
Also Published As
Publication number | Publication date |
---|---|
US20200151698A1 (en) | 2020-05-14 |
US11587057B2 (en) | 2023-02-21 |
US20140279556A1 (en) | 2014-09-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11587057B2 (en) | Distributed authenticity verification for consumer payment transactions | |
US8694438B1 (en) | Distributed authenticity verification for consumer payment transactions | |
US11240219B2 (en) | Hybrid integration of software development kit with secure execution environment | |
US20210142312A1 (en) | Authentication systems and methods using location matching | |
CN108604989B (en) | System and method for code display and use | |
US11170379B2 (en) | Peer forward authorization of digital requests | |
US11461764B2 (en) | Systems and methods for performing a reissue of a contactless card | |
US20200314644A1 (en) | Encryption key exchange process using access device | |
US20130041831A1 (en) | Secure and shareable payment system using trusted personal device | |
US20140279555A1 (en) | Dynamically allocated security code system for smart debt and credit cards | |
US20110251962A1 (en) | Transaction method for secure electronic gift cards | |
US20080177668A1 (en) | Computerized person-to-person payment system and method without use of currency | |
KR20150026233A (en) | Payment system and method t based on digital card | |
CN103282923A (en) | Integration of verification tokens with portable computing devices | |
KR20140125449A (en) | Transaction processing system and method | |
US20210049614A1 (en) | Digital access code | |
US20220070617A1 (en) | Method and system for location-based resource access | |
US20200013045A1 (en) | Stake pool for a secure and trusted data communication system | |
CN112823368A (en) | Tokenized contactless transactions via cloud biometric identification and authentication | |
HU231086B1 (en) | Procedure to secure and initiate identified bankcard payment transaction, software for the said purpose and communication equipment containing such software | |
CN113169873A (en) | System and method for password authentication of contactless cards | |
US20140090018A1 (en) | Smart Device Lockout | |
US20230153800A1 (en) | Token processing for access interactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SCVNGR, MASSACHUSETTS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JERNIGAN, CHARLES CARTER;PRIEBATSCH, SETH;REEL/FRAME:029984/0832 Effective date: 20130226 |
|
AS | Assignment |
Owner name: VENTURE LENDING & LEASING VII, INC., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:033348/0471 Effective date: 20130819 Owner name: VENTURE LENDING & LEASING VI, INC., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:033348/0471 Effective date: 20130819 |
|
AS | Assignment |
Owner name: USB FOCUS FUND LEVELUP 1, LLC, MASSACHUSETTS Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:033549/0841 Effective date: 20140815 |
|
AS | Assignment |
Owner name: BRIDGE BANK, NATIONAL ASSOCIATION, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:034604/0149 Effective date: 20141223 |
|
AS | Assignment |
Owner name: CONTINENTAL INVESTORS FUND, LLC, ILLINOIS Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC. D/B/A LEVELUP;REEL/FRAME:034897/0091 Effective date: 20150107 |
|
AS | Assignment |
Owner name: USB FOCUS FUND LEVELUP 2B, LLC, MASSACHUSETTS Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:044332/0035 Effective date: 20170815 Owner name: USB FOCUS FUND LEVELUP 2A, LLC, MASSACHUSETTS Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:044332/0035 Effective date: 20170815 |
|
AS | Assignment |
Owner name: SCVNGR, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BRIDGE BANK, NATIONAL ASSOCIATION;REEL/FRAME:046829/0162 Effective date: 20180910 |
|
AS | Assignment |
Owner name: SCVNGR, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CONTINENTAL INVESTORS FUND, LLC;REEL/FRAME:046858/0051 Effective date: 20180910 Owner name: SCVNGR, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNORS:VENTURE LENDING & LEASING VI, INC.;VENTURE LENDING & LEASING VII, INC.;REEL/FRAME:047062/0877 Effective date: 20180912 |
|
AS | Assignment |
Owner name: SCVNGR, INC. D/B/A LEVELUP, MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:USB FOCUS FUND LEVELUP 1, LLC;REEL/FRAME:046891/0440 Effective date: 20180913 Owner name: SCVNGR, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNORS:USB FOCUS FUND LEVELUP 2A, LLC;USB FOCUS FUND LEVELUP 2B, LLC;REEL/FRAME:046892/0213 Effective date: 20180913 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., MASSACHUSETTS Free format text: SECURITY INTEREST;ASSIGNOR:SCVNGR, INC.;REEL/FRAME:047361/0313 Effective date: 20181026 |
|
STCV | Information on status: appeal procedure |
Free format text: BOARD OF APPEALS DECISION RENDERED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |
|
AS | Assignment |
Owner name: GRUBHUB HOLDINGS, INC., ILLINOIS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:056595/0957 Effective date: 20210614 Owner name: SCVNGR, INC., MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:056595/0957 Effective date: 20210614 |